You are on page 1of 154

Proceedings Latin American Congress on Requirements Engineering & Software Testing

LACREST MEDELLÍN 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

Edición, Julio de 2012 ISBN 978-958-46-0577-1

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

Medellín – Antioquia – Colombia

LACREST MEDELLÍN 2012
COMITÉ ORGANIZADOR
Edgar Serna M. Miguel Buitrago B. William A. Arévalo C. Luis Fernando Vargas C. Fernando Arango I. Rosalba Rios Galvis Director General LACREST Instituto Antioqueño de Investigación - IAI Director Ejecutivo LACREST MEDELLÍN 2012 Centro de Ingeniería de Software - CEIS Director I+D LACREST MEDELLÍN 2012 Centro de Investigación y desarrollo de Nuevas Tecnologías - CIDENET Director LACREST MEDELLÍN 2012 Universidad Cooperativa de Colombia Director Científico LACREST MEDELLÍN 2012 Universidad Nacional de Colombia Directora Académica LACREST MEDELLÍN 2012 Corporación Universitaria Remington

COMITÉ CIENTÍFICO
Dr. Gustavo Rodríguez G. Dr. Miguel Buitrago B. Dr. Javier Jesús Gutiérrez R. Dr. Libardo A. Londoño C. Dra. María 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 López Dr. José Antonio Pow-Sang P. Dr. Ljubo Vlacic Dra. Ana M. Moreno Dr. Jonás A. Montilva C. Dr. Ramón García-Martínez Dr. Jaime Navon Cohen Dr. Éric Adrien Filiol Dr. Oscar Dieste Dr. Jovani A. Jiménez 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 Astrofísica, Óptica y Electrónica, México. CEO Sequal S.A., Colombia. Universidad de Sevilla, España. Politécnico Colombiano Jaime Isaza Cadavid, Colombia. Universidad de Sevilla, España. Universidad Tecnológica de Panamá, Panamá. United Nations University, Argentina. Universidad de los Andes, Colombia. Universidad Tecnológica de Panamá, Panamá. Universidad Tecnológica Nacional, Argentina. Universidad Nacional de Colombia sede Medellín, Colombia. Universidad Politécnica de Valencia, España. Pontificia Universidad Católica del Perú, Perú. Griffith University, Australia. Universidad Politécnica de Madrid, España. Universidad de Los Andes, Venezuela. Universidad Nacional de Lanús, Argentina. Pontificia Universidad Católica de Chile, Chile. École Supérieure d'informatique, électronique et automatique, Francia. Universidad Politécnica de Madrid, España. Universidad Nacional de Colombia sede Medellín, Colombia. Universidad Politécnica de Madrid, España. City University London, United Kingdom. CasodePrueba, Colombia. Universidad de Medellín, Colombia. Universidad Eafit, Colombia.

POR LA PROFESIONALIZACIÓN DEL DESARROLLO DE SOFTWARE

CONTENIDO
PRESENTACIÓN PONENCIAS Los procesos de gestión en la Ingeniería de Requisitos según la guía 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

Conceptualización de Requerimientos: Propuesta de Proceso y Técnicas Asociadas Variabilidad del Comportamiento de Agrupamiento e Inducción Basado en las Características del Dominio

Alejandro Hossian, Ramón García-Martínez, Oscar Dieste Marcelo López N., Ramón García-Martínez

Comparación de Métricas de Estimación para Proyectos de Explotación de Información Modelo de proceso para elicitación de requerimientos en proyectos de explotación de información

Pablo Pytel, Ramón García-Martínez, Paola Britos

Diego Mansilla, Florencia Pollo-Cattaneo, Ramón García-Martínez, Paola Britos, Patricia Pesado

Un Modelo de Procesos para Proyectos de Explotación de Información

Juan A. Vanrell, Ramón García-Martínez, Rodolfo Bertone Juan B. Quintero, Diana M. Hernández, Pamela Rucinque

Catálogo de anti-patrones al especificar requisitos funcionales usando casos de uso

Heydi Menéndez A., Yanetsi Millet L., Aniubis Rodríguez 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 ejecución de pruebas funcionales

Metodología para enseñar a asegurar la calidad del software a través de técnicas de verificación y validación

Gabriela Salazar B.

Integración de Redmine y Subversion en la construcción 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 Liberación de Productos Software Una experiencia de aseguramiento de la calidad en una Unidad de Sistemas Elicitación de requisitos desde la perspectiva del diseño de producto Metodología de Ejecución del Plan de Pruebas de Software basado en la guía PMBOK
Marcelo Jenkins, Alexandra Martínez, Gustavo López

Heney Díaz P., Daira Pérez S.

Ricardo Mejía G., Alejandro Cálad A., Daniel Zuluaga H. Luz E. Valencia, Jorge L. Suarez, Angélica M. Cardona

Comparativo para la fase de análisis de requisitos entre un método de desarrollo de software tradicional vs la incorporación de BPM
Luis Merchán P., Diego A. Gómez M., Eunice Borja O., María E. Flórez O., Paola A. Torres L.

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

Luis E. Meléndez C.

CONFERENCIAS Usabilidad y Métodos Ágiles: Debate y Vías de Integración Participación de Agentes en los Procesos de Ingeniería, determinada por RNFs

Ana M. Moreno

Germán Urrego G., Gloria L. Giraldo G.

De Requisitos a Código: Desarrollo de Software Dirigido por Modelos en Práctica Reusing Formal Proofs Through Isomorphisms

Óscar Pastor López, Marcela Ruiz, Sergio España Mauricio Ayala-Rincón

Verificación y Validación independiente para asegurar mayor confianza en el software que controla sistemas críticos
Patricia Rodríguez Dapena

5

PRESENTACIÓN
En un entorno altamente interactivo como Internet, los temas de investigación en Ingeniería de Requisitos y Software Testing varían en función del desarrollo de nuevas tecnologías y modos de interacción en la comunidad del conocimiento, el cual, debido al progreso de las tecnologías móviles y la Web 2.0, es mucho más rápido de transferir, almacenar y recuperar. Esas tecnologías y modos cada vez son más diversos, al mismo tiempo que los tipos de comunidades en línea con altos niveles de interacción son cada vez más multidimensionales. Para optimizar el rendimiento organizacional y para promover aún más la innovación y la gestión del conocimiento alrededor de estas dos áreas, se requieren estrategias nuevas y más amplias para intercambiar saberes dentro y entre esas comunidades. En años recientes, ha habido nuevos y sorprendentes aportes y descubrimientos que soportan las teorías, los métodos y los modelos de la Ingeniería de Requisitos y del Software Testing. Igualmente, se han presentado tecnologías y herramientas innovadoras relacionadas con la gestión 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 Información y del Conocimiento; además, esos estudios amplían cada vez más su influencia en aplicaciones multidisciplinares. Pero, dado el dinamismo de la investigación se espera más y mejores progresos para los años venideros. Comprender, aportar y difundir estos temas de investigación ayudará al desarrollo de nuevas aplicaciones desde lo académico y lo práctico que soportarán y darán mayor valor al principio de la “profesionalización 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 MEDELLÍN 2012, en la ciudad de Medellín Colombia. Esperamos que proporcione información relevante sobre las tendencias de la investigación de la comunidad y que se pueda integrar de forma novedosa al conocimiento existente. El objetivo es que la información que contiene sirva como un importante recurso para investigadores, profesores y estudiantes y que promueva el trabajo académico y el desarrollo de nuevas prácticas en los campos de la Ingeniería de requisitos y del Software Testing.
Director General LACREST

Edgar Serna M.

6

PONENCIAS

7

Management processes in the Requirements Engineering as the PMBOK® guide Los procesos de gestión en la Ingeniería de Requisitos según la guía del PMBOK®
Luis A. Esteban V.1, William M. Rojas C.2
1

Universidad de Pamplona, Grupo de Investigación 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 artículo se presenta un análisis de los procesos de gestión definidos en la cuarta versión de la guía del PMBOK®, relacionados con la ingeniería de requisitos y adaptados a proyectos de desarrollo de software.

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo: Recibido: 30/03/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Guía del PMBOK®, recolección de requisitos, procesos de gestión. Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Tools. General Terms Software Engineering, Requirements Engineering. Keywords PMBOK® guide, requirement elicitation, management processes.

1. INTRODUCCIÓN La guía del PMBOK® [9] diseñada por el PMI®, ha sido de gran importancia para la gestión de todo tipo de proyectos, por lo cual también puede ser adaptada para proyectos de desarrollo de software. De otro lado las metodologías de desarrollo de software plantean actividades de gestión, pero se pueden complementar o sustituir dichas actividades por las definidas en los procesos de gestión de la guía del PMBOK®, agregando valor al proceso de desarrollo [7]. Dentro de los cambios significativos realizados a la guía entre la tercera y cuarta versión [9], están los procesos relacionados con la gestión de requisitos, incluyendo como nuevos procesos, la identificación de los stakeholders y la recolección de requisitos. Esto puede ser interpretado como un reconocimiento a la Ingeniería de Requisitos como clave en el desarrollo de proyectos. En este artículo se hace un análisis de los procesos de gestión de la guía del PMBOK® relacionados directamente con los conceptos del área de conocimiento de Requisitos de Software [4] dentro de la guía para el cuerpo de conocimiento de la Ingeniería del software (Guía para el SWEBOK®) [10]. En la primera parte se presentan algunos conceptos generales sobre la guía del PMBOK®, haciendo una interpretación de su estructura y describiendo un posible orden en la ejecución de los procesos según los

cinco grupos de procesos. La segunda parte resalta los procesos de la guía que tienen que ver directamente con la captura, análisis, documentación y seguimiento de requisitos. La tercera parte presenta algunas conclusiones relacionadas con la importancia de las actividades de gestión de requisitos, dentro de los procesos de desarrollo de software. 2. LA GUÍA DEL PMBOK® El cuerpo de conocimiento BOK —Body Of Knowledge — de una ciencia o una disciplina, está conformado por toda la información existente alrededor de dicho dominio, esto incluye libros, artículos, investigaciones, publicaciones en eventos y cualquier otro tipo de contenedor de información al respecto. Esto supone que cualquier cuerpo de conocimiento dispone de grandes volúmenes de información, distribuida en todo el mundo y producida por profesionales que tienen su interés en dicha disciplina. Algunos organismos líderes mundiales en algunas disciplinas, entre las cuales se encuentra la Ingeniería del software y la gestión de proyectos, han dedicado gran esfuerzo en la recopilación de información que permita estructurar estos grandes volúmenes de información de una disciplina, en guías para el cuerpo de conocimiento (Figura 1), los cuales son documentos relativamente breves que intentan recopilar los conceptos comúnmente aceptados en la disciplina y organizados por áreas de conocimiento.

8

Guía para el BOK

Estructura el

Área n

Necesidades

Libros Artículos Documentales Experiencias Investigaciones Guías

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 prácticas prá comúnmente 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

Ejecución
G Gi Gi Gj Gj

Gi Gm

A diferencia de otras guías para el cuerpo de conocimiento, la guía para el PMBOK®, tiene dos enfoques: El primer enfoque es el típico en otras guías 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 información. El segundo enfoque, que no tienen las demás guías, es como metodología de gestión de proyectos, para lo cual organiza los procesos de dirección en cinco grupos de procesos y cuarenta y dos procesos organizados en dichos grupos.
Por áreas de Conocimiento
PMBOK®
• • • • • • • • • Gestión de Integración Gestión de Alcance Gestión de Tiempos Gestión de Costes Gestión de Calidad Gestión de Recursos Humanos Gestión Comunicaciones Gestión de Riesgos Gestión de Adquisiciones

G

8 procesos de Ejecución

10 procesos de Seguimiento y control del proyecto

20 procesos de Planificación 2 procesos de inicio

Guía para el PMBOK® V4

2 procesos de cierre

Fig. 4: Procesos de Gestión organizados por grupos

a Guí

Por grupos de Procesos
• • • • • Procesos de Inicio Procesos de Planificación Procesos de Ejecución Procesos de Seguimiento y control Procesos de Cierre

Estos procesos de gestión dentro de proyectos de desarrollo de software son pertinentes dentro de los alcances de la Ingeniería del software [2, 10], por lo que pueden ser estudiados como métodos, herramientas y técnicas para proyectos de desarrollo de software. Si se utiliza la guía del PMBOK®, como metodología para la dirección del proyecto, se combinan de manera organizada las actividades técnicas y de gestión en una sola estructura organizada para el proyecto, como se muestra en la Figura 5.
Procesos de la guía del PMBOK®
Procesos Iniciales Procesos de Planificación

Procesos Propios del desarrollo de software como producto del proyecto

Fig. 2: Los dos enfoques de la guía PMBOK®

Un proyecto es definido en esta guía 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 (tecnología), para generar artefactos (producto) propios de la gestión y elaboración 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 Gestión (representadas con la letra “G”) y Actividades Técnicas (representadas con la letra “T”). Separando las actividades de gestión de las actividades técnicas en un proyecto, la guía del PMBOK® organiza estas actividades de gestión 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 ejecución

Procesos de cierre

Fig. 5: Procesos de Gestión y técnicos en un proyecto

Visto de manera integrada se puede representar como se muestra en la Figura 6. Las actividades de gestión son determinadas y organizadas según la guía del PMBOK®, mientras que las actividades Técnicas en el desarrollo de software son guiadas por la metodología de desarrollo de software utilizada en el proyecto.

Producto o servicio Único

La gestión de proyectos como disciplina, tiene su guía para el cuerpo de conocimiento, elaborada por el PMI®, y ampliamente utilizada como herramienta para la dirección de proyectos de cualquier tipo, por lo que se puede adaptar a proyectos de desarrollo de software, complementando o sustituyendo las actividades de gestión propuestas por cada una de las metodologías de desarrollo de software [7].

Tecnología
Tiempo

Fig. 3: Estructura de un Proyecto
Inicio de proyecto una vez aprobado Organización y preparación del trabajo Terminación del proyecto

Realización del trabajo

inicio

Seguimiento y control Planificación
G Gi Gi Gi Gi

Cierre

9

inicio

Seguimiento y control Planificación
G G G Gi Gi Gi Gi

Cierre

Ejecución
Gi Gi Gj Gj

Necesidades

G0 G G

Gm

T

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 Ejecución  Dirigir y Gestionar la Ejecución del Proyecto  Realizar Aseguramiento de Calidad  Adquirir el Equipo del Proyecto  Desarrollar el Equipo del Proyecto  Dirigir el Equipo del Proyecto  Distribuir la Información  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 Desempeño  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 podría llamar la gestión de las actividades técnicas de la ingeniería de requisitos en proyectos de desarrollo de software. 3.1 Desarrollar el Project Charter La guía del SWEBOK® [10], define dentro del área de conocimiento de requisitos de software, las siguientes fuentes de requisitos:  Stakeholders.  El ambiente operacional.  Objetivos (factores críticos de éxito) se refiere a los objetivos de alto nivel del software.  Conocimiento del dominio de aplicación.  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 información, entre la cual se pueden resaltar los objetivos del producto software a desarrollar, el contexto de la aplicación (dominio), un listado inicial de stakeholders y las características del sistema en el cual estará inmerso el producto a desarrollar. Los objetivos de un proyecto pueden definirse en términos de las cuatro variables típicas de un proyecto: Costo, Calidad, Alcance y Tiempos, como se observa en la Figura 7. Aunque los objetivos del proyecto relacionados con requisitos están concentrados en el factor de Alcance, es también 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 metodología de desarrollo de software

Fig. 6: Los procesos de gestión y técnicos 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 gestión, con en las actividades técnicas. En este artículo se hace un análisis de los procesos de gestión que están relacionados con los conceptos técnicos de requisitos, en proyectos de desarrollo de software. 3. PROCESOS DE GESTIÓN RELACIONADOS CON REQUISITOS Para proyectos de desarrollo de software, existen metodologías propias para su gestión, incluida la gestión ágiles de proyectos de desarrollo de software [3], sin embargo en este artículo se hace énfasis en la utilización de la guía del PMBOK como metodología de gestión de proyectos. La guía del PMBOK® en su cuarta edición, 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 Planificación  Recolectar Requisitos  Definir el Alcance  Crear la EDT (estructura de desglose de trabajo)  Definir las Actividades  Secuenciar las Actividades  Estimar la Duración 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 Gestión de Riesgos  Identificar Riesgos  Realizar Análisis Cualitativo de Riesgos  Planificar la Respuesta a los Riesgos  Realizar Análisis Cuantitativos de Riesgos  Planificar las Adquisiciones  Planificar la Calidad  Planificar las Comunicaciones  Desarrollar el Plan de Gestión del Proyecto

10

Pesos, dolares, etc

Costo

S1

Impacto

Alto

Alto

S6

Poder

+

Bajo

Bajo

Los requerimientos hacen parte de la definición 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

+
Años, meses, días

S2

S9

S7

Tiempo

Interés

Fig. 7: Cuatro Variables típicas en todo proyecto

Normal

S1 S3 S8 S6

Un prototipo de Project charter para un proyecto de software puede tener la siguiente estructura:              Descripción del proyecto. Definición del producto del proyecto. Definición de requisitos del proyecto. Objetivos del proyecto. Finalidad del proyecto. Justificación del proyecto. Designación 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: Análisis 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 preocupación o conveniencia sobre los requisitos del producto. Estas formas de clasificación permiten la definición de estrategias para facilitar la captura de los requisitos y la gestión de expectativas durante el desarrollo técnico de la captura, análisis, especificación y validación 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: Identificación (nombre, empresa, ubicación, rol, información de contacto), evaluación (requisitos, influencia potencial) y clasificación (interno-externo, apoyo-neutral-opositor). La lista por roles debe estar estructurada con el rol y la instancia del rol que lo va a desempeñar. 3.3 Recolectar requisitos Este proceso aunque en proyectos de desarrollo de software es considerado un proceso técnico (para el cual existen técnicas de captura), y que casi siempre es iterativo durante todo el proyecto, la guía del PMBOK® lo define como el primero de los procesos de planificación del proyecto y consiste en recoger la información 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 técnicas de captura, análisis, especificación y validación 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 organización 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 guía 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 según la Guía del PMBOK®. En proyectos de desarrollo de software este listado de involucrados puede ser construido utilizando como criterio, quienes tienen algún requisito de software como necesidad a satisfacer. Si una persona u organización tiene algún requisito del producto a desarrollar, esta pasa directamente a ser parte de los stakeholders del proyecto. Cada uno debe ser registrado con alguna información complementaria como: rol que desempeñara en el proyecto, requisitos primordiales, expectativas principales, influencia potencial, fase del proyecto de mayor interés, clasificación según sea interno o externo, de apoyo o neutral u opositor. Esta información facilita realizar análisis sobre los involucrados mediante su clasificación desde diversos factores como los representados en la Figura 8.

11

técnicas propias del desarrollo de software, durante varias veces (de manera iterativa) dentro del proyecto y no solo en la fase de planificación. Sin embargo este proceso de gestión es de relevante importancia en la medida que permite identificar las características 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 descripción del requisito entre los cuales están: sustento de su inclusión, propietario, fuente, prioridad, versión, estado actual (activo, cancelado, diferido, adicionado, aprobado) fecha de cumplimiento, nivel de estabilidad (alto, medio, bajo) grado de complejidad (alta, media, baja), criterio de aceptación, entre otros que pueden ser considerados relevantes para el proyecto. Este proceso de gestión facilita la trazabilidad del requisito durante la etapa de ejecución, seguimiento y control. La clasificación de stakeholders anteriormente descrita, permitirá aquí, definir técnicas 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 solución 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 aceptación Impacto en otras dependencias internas y externas Supuestos y restricciones

3.5 Crear la estructura de división del trabajo (EDT) La recolección de requisitos en una fase inicial de planificación de un proyecto software y complementado con el proceso de definición de alcance, son la principal entrada para el proceso de crear el EDT. Este EDT organiza las actividades técnicas en paquetes de trabajo, de tal manera que se pueda ver una descomposición jerárquica del producto, en subproductos o en fases de construcción del producto con el fin de disminuir el nivel de complejidad y facilitar la asignación de paquetes a grupos pequeños de desarrolladores. En el artículo [7] se muestra algunos EDT’s típicos para algunas metodologías de desarrollo de software, derivados del proceso definido por cada metodología y de los requisitos capturados y organizados, sobre los cuales se centrarán cada una de las iteraciones, entregas, o fases según establece la metodología. La Figura 9 representa la estructura de desglose de trabajo del desarrollo de un producto software, integrado con los procesos de gestión del PMBOK®. Donde la estructura de desglose de trabajo se observa en el paquete de trabajo denominado “Desarrollo con RUP” que corresponde a la organización de actividades técnicas 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 entregarán como parte del producto final del proyecto. El alcance en un proyecto de desarrollo de software, puede definirse en términos de los requisitos que debe satisfacer cada subproducto software. Gran parte de las metodologías 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 definición de alcance por lo tanto organiza los requisitos y plantea posibles formas de configurar los procesos de las actividades técnicas según la metodología de desarrollo seleccionada. Este proceso genera el scope statement:     Alcance del producto (requisitos, características). Criterios de aceptación del producto. Artefactos del proyecto. Exclusiones, restricciones y supuestos del proyecto.

Fig. 9: Estructura de un proyecto software con RUP y dirigido con la guía del PMBOK®

3.6 Gestionar las expectativas de los interesados Este proceso dentro del grupo de procesos de ejecución, contiene las actividades de planificación iterativa durante el desarrollo del producto de las actividades de captura de requisitos, pues del continuo intercambio de información sobre el avance del proyecto a cada uno de los stakehoders, se puede obtener la retroalimentación 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 términos de aceptación por parte de quien los recibe (en algunas

12

metodologías es el usuario del software) y por lo tanto se debe constar el cumplimiento de requisitos, según han sido definidos y traducidos en términos de productos entregables pro el proceso de definición de alcance. Dentro del proceso se considera la modificación de la matriz de rastreabilidad de requisitos — Artefacto de gestión, construido inicialmente en la definición del alcance—, pues es mediante esta, que se permite registrar la culminación 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 verificación de alcance, en el sentido de que una vez detectadas variaciones respecto a lo planeado en la definición de alcance, se toman medidas que permitan mantener el proyecto dentro de los límites de costo, calidad, tiempo y alcance. Este proceso implica probablemente cambios en requisitos, o adición de nuevos requisitos, producto de las medidas de control definidas para cada una de las situaciones. 3.9 Informar el desempeño Este proceso consiste en recopilar y distribuir la información 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 términos de los requisitos satisfechos hasta el momento del informe, y las proyecciones en términos de tiempos de los requisitos restantes. 4. CONCLUSIONES La guía del PMBOK® como herramienta para la dirección de proyectos, brinda el necesario y suficiente soporte para gestionar los requisitos durante todo el proceso de desarrollo de software, independiente de la metodología de desarrollo seleccionada. La Figura 10 muestra los procesos relacionados directamente con la ingeniería de requisitos, definidos por la guía del PMBOK® y su interacción.
1. Desarrollar el Project Charter 3. Recolección de requisitos 7. Verificar Alcance 8. Controlar Alcance

Otros procesos de gestión definidos por la guía del PMBOK®, también tienen alguna relación con los proceso técnicos de requisitos, y no son analizados en este artículo, pues corresponden a otras áreas de conocimiento diferente a la de los requisitos de software, según la guía 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 investigación en Ciencias Computacionales de la Universidad de Pamplona que apoya el programa de Maestría en Gestión de proyectos Informáticos, dentro de la cual la guía del PMBOK® es estudiada y discutida junto con docentes y estudiantes del programa.
[1] Beck, K. 2002. Una explicación de la programación 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 manager´s guide. Addison Wesley. [7] Rojas, C. M.; Esteban, V. L. A. & Orjuela, D. A. 2011. Modelo de integración de las actividades de gestión de la guía del PMBOK®, con las actividades de ingeniería, en proyectos de desarrollo de software. Avances en Sistemas e Informática, 8(2), 97-105. [8] McConnell, S. 1997. Desarrollo y gestión de proyectos informáticos. McGraw Hill. [9] PMI. 2009. Guía de los fundamentos para la dirección de proyectos (Guía 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 Planificación

Necesidades

G G1 G

Ejecución
G

2. Identificar los Stakeholders

5. Definición de Alcance 5. Crear EDT

9. Informar Desempeño 6. Gestionar las expectativas de los Stakeholders

Fig. 10: Procesos de gestión directamente relacionados con los requisitos

Producto o servicio Único

G

Gi

Gi

Gj

Cierre

13

Conceptualization of Requirements: Proposal of Process and Associated Techniques Conceptualización de Requerimientos: Propuesta de Proceso y Técnicas Asociadas
Alejandro Hossian1, Oscar Dieste2, Ramón García-Martínez3
1

Programa de Doctorado en Ciencias Informáticas. UNLP y Grupo de Investigación en Sistemas Inteligentes en Ingeniería. UTN-FRN, Neuquén, Argentina. alejandrohossian@yahoo.com.ar. 2 Grupo de Ingeniería de Software Empírica. Facultad de Informática. Universidad Politécnica de Madrid. Madrid, España. odieste@fi.upm.es. 3 Grupo de Investigación en Sistemas de Información. Departamento de Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. 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 conceptualización de requisitos. Se propone un proceso de conceptualización de requisitos que se estructura en dos fases: (a) Análisis 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) Análisis de Orientado al Producto: cuyo objetivo es obtener las funcionalidades que el usuario espera del producto de software a desarrollar, teniendo en cuenta la relación de estas con la realidad expresada por el usuario en su discurso. Se proponen seis técnicas que articulan cada una de las tareas que componen las fases de proceso propuesto.

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo Recibido: 23/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Requerimientos, proceso, técnicas. conceptualización,

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

Keywords Requirements, conceptualization, process, techniques.

1. INTRODUCCIÓN El proceso de educción de requisitos, cuyo objetivo central consiste en dar a luz a los requisitos, no solo constituye un proceso de carácter técnico para construir un determinado sistema, sino también 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 realización de dicho proceso de educción [2]. Asimismo, con respecto a los stakeholders cabe aclarar que dicho término 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 interactúan con el sistema, así como también a demás 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 función 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 mayoría de los casos los stakeholders desconocen lo que desean obtener del sistema informático, resultándoles difícil 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 implícito 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 construcción del sistema posean diferentes requisitos, los cuales pueden ser expresados de varias formas distintas. Por consiguiente, los ingenieros deben tener en consideración todas las posibles fuentes potenciales de requisitos y hallar coincidencias y conflictos.  También es posible que factores de carácter político 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 organización. Continuando en esta línea, por las razones expuestas se puede afirmar que el proceso de educción es difícil de llevar a cabo. En este sentido, conforme a [4] y con idea de complementar los problemas expresados anteriormente, se estima conveniente añadir las siguientes consideraciones:  Mucha información importante para la construcción del producto software no llega a ser verbalizada, quedando así plasmados importantes huecos en la información capturada.  En la mayoría de los casos el proceso de educción se lleva a cabo en forma pasiva en relación 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 mención Sommerville [1] y Christel [4], propias del proceso de educción, 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 educción, se infiere que el eje de la misma se focaliza en la comunicación que se establece entre el usuario y el Ingeniero de Requisitos (IR). Este, cuando desarrolla su trabajo de educción, debe capturar y modelar una realidad que enmarca una problemática, y cuya solución, debe ser abordada a través de un producto software. Siendo esta realidad un elemento intangible y, por lo general también compleja, es que también resulta difícil su captura. Ahora bien, la captura de esta realidad junto con su problemática 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 educción 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 análisis de requisitos. Estos inconvenientes, propios del proceso de educción, hacen que se dificulte la elaboración del universo de

discurso por parte del IR, así como también la construcción de modelos conceptuales adecuados [6, 7]; es decir que estos problemas, que comienzan a manifestarse en el proceso de educción de requisitos y a partir de la comunicación entre el usuario y el IR, seguramente se propagarán en la actividad de construcción de los modelos conceptuales. Estos inconvenientes, confluirán de manera inexorable, hacia la obtención de un software de baja calidad [8]. En este contexto, se describe el problema abordado (sección 2), se propone un proceso de conceptualización de requisitos (sección 3) y las técnicas asociadas (sección 4), se dan conclusiones y se señalan las futuras líneas de trabajo (sección 5). 2. DESCRIPCIÓN DEL PROBLEMA El problema abierto que se identifica en la presente sección, consiste en la necesidad de estructurar y categorizar la masa de información proveniente del proceso de educción a los efectos de facilitar la comprensión del problema manifestado por el usuario [9, 10, 11]. En otros términos, 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 construcción de los modelos conceptuales a partir de la información recogida en el proceso de educción y plasmada en el discurso de usuario. Asimismo cabe resaltar, que dichas dificultades dotan al proceso de Análisis de un grado tal de inmadurez que hace que sea difícil llevar a cabo en forma efectiva esta actividad, al mismo tiempo que dificulta la adopción 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 transición de un proceso (Educción 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 construcción de los modelos conceptuales, con el objeto de reducir la complejidad mencionada y favorecer la comprensión del problema planteado por el usuario, contribuyendo así a la obtención de Modelos Conceptuales de mayor calidad [6, 19]. Asimismo, es importante señalar la muy escasa cantidad de trabajos referidos a la elaboración de representaciones intermedias de los caudales de información obtenidos por el IR en el proceso de educción. En otras palabras, trabajos que estén orientados a la búsqueda de reducción de la complejidad de la realidad y su problemática expresada por el usuario en su discurso. En este sentido, se pueden citar algunos principios fundamentales de estructuración de la información —Partición, Abstracción y Proyección— los cuáles proporcionan una

15

estructura de conocimiento a fin de contribuir a una visión simplificada de la realidad y su problemática [9]. Si bien estos principios ofrecen su aporte a los efectos de precisar un mejor entendimiento de sus requisitos, son de carácter muy general y de poco nivel de detalle. 3. PROPUESTA PROCESO DE CONCEPTUALIZACIÓN DE REQUISITOS La solución que se propone en este trabajo, consiste en la inserción de una actividad de “Conceptualización de Requisitos”, la cual tiene como finalidad actuar a modo de puente o enlace (“link”) entre las actividades de educción de requisitos y las actividades de modelado conceptual, facilitando de esta manera la comprensión del problema manifestado por el usuario y, en consecuencia, la obtención de Modelos Conceptuales de mayor calidad [2, 6, 9, 17, 19]. A partir de la implementación de esta actividad de conceptualización de requisitos es posible la consecución de un conjunto de Representaciones Intermedias de los Requisitos de Usuario (RIRU), a partir de las cuales es posible “caracterizar” la información 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 más sencillo su procesamiento para la construcción de los modelos conceptuales. Estas

representaciones intermedias estarán conformadas por un conjunto de representaciones gráficas: los Escenarios de Usuario Refinados (EUR), los cuales enlazados en forma adecuada a través del Mapa Unificado de Escenarios de Usuario (MUEU) permiten caracterizar el discurso del usuario en una forma alternativa al lenguaje natural clásico. 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 aprobación definitiva. El proceso de conceptualización de requisitos propuesto se lleva a cabo por medio de un proceso dual llamado Proceso de Conceptualización de Requisitos el cual se estructura en dos fases: (a) Análisis Orientado al Problema: cuyo objetivo es la comprensión del problema planteado por el usuario en el dominio en el cual este tiene lugar; y (b) Análisis Orientado al Producto: cuyo objetivo es la obtención de las funcionalidades que el usuario pretende obtener del producto software a desarrollar, teniendo en cuenta la vinculación de estas funcionalidades con la realidad manifestada por el usuario en su discurso. La Figura 1 representa el proceso de conceptualización de requisitos propuesto destacando la interdependencia conceptual entre las fases, tareas y productos.

Fig. 1: Proceso de conceptualización de requisitos detallando fases, tareas y productos

La fase de Análisis Orientado al Problema se estructura en tres tareas: (a) “Segmentación del Discurso de Usuario”; (b) “Análisis Cognitivo de los Segmentos de Texto”; (c) “Construcción 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 “Segmentación del Discurso de Usuario” que produce como resultado los “Segmentos de Texto” correspondientes a dicho discurso. Estos segmentos serán el material a partir del cual mediante la tarea “Análisis 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 “Construcción del Espacio Problema en Escenarios de Usuario” que derivará en “Espacio Problema en Escenarios de Usuario”. La fase de Análisis Orientado al Producto se estructura en tres tareas: (a) “Construcción de Escenarios de Usuario”; (b) “Refinamiento de Escenarios de Usuario”; y (c) “Construcción 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 Análisis Orientado al Problema) constituyen las entradas para la tarea

16

“Construcción de Escenarios de Usuario” que produce como resultado los “Escenarios de Usuario”. Estos escenarios junto con el “Discurso de Usuario” respectivo, serán 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 “Construcción del Mapa Unificado de Escenarios de Usuario” que derivará en el “Mapa Unificado de Escenarios de Usuario”. Las técnicas utilizadas y representaciones de las tareas se resumen en la Figura 2.

Fig. 2: Fases, tareas y productos

4. TÉCNICAS PROPUESTAS PARA FASE ANÁLISIS ORIENTADO AL PROBLEMA En esta sección se presentan las técnicas correspondientes a la fase de Análisis Orientado al Problema, que son: Técnica de Segmentación del Discurso de Usuario (TS–DU) para la implementación de la tarea Segmentación del Discurso de Usuario (SDU) (sección 4.1), Técnicas Cognitivas de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI–CFPCA) para la implementación de la tarea Análisis Cognitivo de los Segmentos de Texto (ACST) (sección 4.2) y Técnica de Construcción del Diagrama de Espacio Problema de Escenarios de Usuario (TCD–EPEU) para la implementación de la tarea Construcción del Espacio Problema de Escenarios de Usuario (CEPEU) (sección 4.3). 4.1 Técnica de Segmentación del Discurso de Usuario (TS–DU) Por medio de esta técnica se implementa la primera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Segmentación del Discurso de Usuario (SDU). Para la aplicación de la TS– DU el IR cuenta con el Discurso de Usuario (DU) en lenguaje natural como producto de entrada, y comienza por una segmentación 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 técnica, la cual se resume en la Tabla 1. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 3.
Tabla 1. Técnica TS–DU
Técnica: Entradas: Salidas: Paso 1. Paso 2. Paso 3. Segmentación del Discurso de Usuario (TS–DU) Discurso de Usuario (DU) ST Asociados a los EU Segmentación del DU Frase por Frase Integración de las Frases en ST Asociación de los ST a EU

Fig. 3: Esquema y subproductos de TS–DU

17

4.2 Técnica Cognitiva de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI–CFPCA) Por medio de esta técnica se implementa la segunda tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Análisis Cognitivo de los Segmentos de Texto (ACST). Para la aplicación de la TCI–CFPCA el IR dispone como producto de entrada de cada uno de los ST asociados a los EU que fueron obtenidos a partir de la aplicación de la técnica anterior (TS–DU); 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 carácter netamente personal y que tienen lugar en determinados contextos [9]. Para comenzar a aplicar la TCI – CFPCA el IR comienza por la identificación de TC Contextual en los ST, para luego continuar con los TC Factual, Procedural y de Asociación. 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 técnica, la cual se resume en la Tabla 2. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 4.

4.3 Técnica de Construcción del Diagrama de Espacio Problema en Escenarios de Usuario (TCD–EPEU) Por medio de esta técnica se implementa la tercera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Problema, denominada Construcción del Espacio Problema en Escenarios de Usuario (CEPEU). Para la aplicación de la TCD–EPEU el IR dispone como productos de entrada de cada uno de los ST asociados a los EU obtenidos a partir de la aplicación de la técnica TS–DU, y de los TC identificados en cada uno de los ST obtenidos a partir de la aplicación de la técnica TCI– CFPCA. Para comenzar a aplicar la TCD–EPEU el IR procede a hacer uso de los TC identificados en cada ST (dejando el TC de Asociación para la Fase de Análisis Orientado al Producto) para poder obtener los distintos elementos que componen los EPEU, los cuales son: Actores, Relaciones, Atributos, Acciones e Interacciones. A continuación, el IR procede a identificar el Marco Contextual Base (MCB) en el que se desenvolverán los actores en el EPEU construyéndose 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 técnica, la cual se resume en la Tabla 3. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 5.
Tabla 3. Técnica TCD–EPEU
Técnica: Entradas: Salidas: Paso 1. Construcción del Diagrama de Espacio Problema en Escenarios de Usuario (TCD–EPEU) ST Asociados a los EU y Tabla de ST–TC Diagramas de EPEU Uso de los TC para la identificación de los elementos de EPEU 1.1. Uso de TC Factual 1.2. Uso de TC Procedural 1.3. Uso de TC Contextual Construcción del Diagrama de EPEU correspondiente al MCB 2.1. Incorporación de Actores al Diagrama de MCB 2.2. Incorporación de Relaciones al Diagrama de MCB Construcción de los restantes Diagramas de EPEU 3.1. Incorporación de Actores al Diagrama 3.1.1. Incorporación de Atributos de actores al Diagrama 3.1.2. Incorporación de valores de Atributos de actores al Diagrama 3.2. Incorporación de Relaciones al Diagrama 3.3. Incorporación de Acciones al Diagrama 3.3.1. Incorporación de Atributos de acciones al Diagrama 3.3.2. Incorporación de valores de Atributos de acciones al Diagrama 3.4. Incorporación de Interacciones al Diagrama 3.4.1. Incorporación de Atributos de interacciones al Diagrama 3.4.2. Incorporación de valores de Atributos de interacciones al Diagrama

Paso 2.

Paso 3.

Fig. 4: Esquema y subproductos de TCI–CFPCA Tabla 2. Técnica TCI–CFPCA
Técnica: Entradas: Salidas: Paso 1. Cognitiva de Identificación de Conocimientos Factuales, Procedurales, Contextuales y de Asociación (TCI-CFPCA) ST Asociados a los EU TC Identificados en los ST Identificación de TC en los ST 1.1. Identificación de TC Contextual en los ST 1.2. Identificación de TC Factual en los ST 1.3. Identificación de TC Procedural en los ST 1.4. Identificación de TC de Asociación en los ST Integración entre los ST y TC

Paso 2.

18

obtenidos a partir de la aplicación de la técnica TCD– EPEU. Para comenzar a aplicar la TCD–EU el IR procede a hacer uso de los ST con TC de Asociación que le permiten obtener las “Funcionalidades” del problema planteado por el usuario, así como también 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 asociación a los efectos de obtener los vínculos 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 técnica, la cual se resume en la Tabla 4. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 6.
Tabla 4. Técnica TCD–EU
Técnica: Entradas: Salidas: Paso 1. Construcción del Diagrama de Escenarios de Usuario (TCD–EU) ST con TC de Asociación (de la Tabla ST–TC) y Diagramas de EPEU Diagramas de EU Uso del TC de Asociación 1.1. Identificación de Funcionalidades 1.2. Identificación de Actores necesarios para realizar las funcionalidades Construcción de los Diagramas de EPrEU para cada EPEU Vinculación de los elementos de los bloques de EPEU y EPrEU para cada EU

Paso 2.

Fig. 5: Esquema y subproductos de TCD–EPEU

Paso 3.

5. TÉCNICAS APLICADAS EN LA FASE DE ANÁLISIS ORIENTADO AL PRODUCTO En esta sección se presentan las técnicas correspondientes a la fase de Análisis Orientado al Producto, que son: Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD–EU) para la implementación de la tarea Construcción de Escenarios de Usuario (CEU), Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD–EU) para la implementación de la tarea Refinamiento de Escenarios de Usuario (REU) y Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario (TCD–MUEU) para la implementación de la tarea Construcción del Mapa Unificado de Escenarios de Usuario (CMUEU). 5.1 Técnica de Construcción del Diagrama de Escenarios de Usuario (TCD–EU) Por medio de esta técnica, se implementa la primera tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Producto, denominada Construcción de Escenarios de Usuario (CEU). Para la aplicación de la TCD–EU el IR dispone como productos de entrada de aquellos ST asociados a los EU que contienen TC de Asociación, obtenidos a partir de la aplicación de la técnica TS–DU, y de cada uno de los Diagramas de EPEU

Fig. 6: Esquema y subproductos de TCD–EU

5.2 Técnica de Refinamiento del Diagrama de Escenarios de Usuario (TRD–EU) Por medio de esta técnica se implementa la segunda tarea que debe llevar a cabo el IR en la fase de Análisis

19

Orientado al Producto, denominada Refinamiento de Escenarios de Usuario (REU). La TRD–EU 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 aplicación de TRD–EU incluye revisión conjunta (Usuario e IR) del DU original, el cual se lleva a cabo en base a un Análisis 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 validación y depuración 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 validación de los diagramas de EU para obtener los diagramas de EUR. Finalmente, Usuario e IR efectúan una revisión final de los EUR; si ambos otorgan conformidad para los EUR obtenidos culmina la aplicación de la técnica, caso contrario, se vuelve al paso 1 para comenzar a aplicarla nuevamente. En este sentido y en virtud de la importancia que reviste la implementación con éxito de la presente técnica, 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 implementación consiste en la puesta en práctica 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 técnica, la cual se resume en la Tabla 5. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 7.
Tabla 5. Técnica TRD–EU
Técnica: Entradas: Salidas: Paso 1. Refinamiento del Diagrama de Escenarios de Usuario (TRD – EU) Discurso de Usuario (DU) y Diagramas de EU Diagramas de EUR Análisis de Consistencia del DU 1.1. Validación y Depuración Incompletitudes del DU 1.2. Validación y Depuración Contradicciones del DU 1.3. Validación y Depuración del DU Validación y Depuración de los ST y TC Validación y Depuración de los EU Revisión Final de los EUR

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

Fig. 7: Esquema y subproductos de TRD–EU

Paso 2. Paso 3. Paso 4.

El diagrama de MUEU representa una secuencia espacio–temporal acerca de cómo el usuario entiende el problema a resolver y la realidad en la que se encuadra dicho problema. El sub-paso de aplicación de TCD– MUEU incluye un Análisis de Transición 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 vínculos entre EU que le conducen al Diagrama de MUEU. El diagrama correspondiente al MUEU constituye el producto de salida que proporciona esta técnica, la cual se resume en la Tabla 6. La técnica propuesta y los subproductos que se obtienen se pueden visualizar en Figura 8.
Tabla 6. Técnica TCD–MUEU
Técnica: Entradas: Salidas: Paso 1. Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario (TCD–MUEU) Segmentos de Texto Asociados a los EU y Diagramas de EUR Diagrama de MUEU Análisis de Transición de EU 1.1. Identificación de Cambio de Contexto 1.2. Identificación de Cambio de Estado en Actores 1.3. Identificación de Nuevos Actores Construcción del Diagrama de MUEU

5.3 Técnica de Construcción del Diagrama del Mapa Unificado de Escenarios de Usuario (TCD– MUEU) Por medio de esta técnica se implementa la tercera y última tarea que debe llevar a cabo el IR en la fase de Análisis Orientado al Producto, denominada Construcción del Mapa Unificado de Escenarios de Usuario (CMUEU). Para la aplicación de la TCD–MUEU el IR dispone como productos de entrada de cada uno de ST asociados a los EU y de los EUR obtenidos de la aplicación de la técnica anterior. Como producto de

Paso 2.

20

de control, (b) la validación empírica de las técnicas propuestas en un conjunto amplio y representativo de dominios de aplicación, (c) la validación empírica del proceso de conceptualización de requisitos mediante la incorporación de otros discursos de usuario que aporten una visión diferente acerca del mismo producto software que se pretende desarrollar. 7. AGRADECIMIENTOS Las investigaciones que se reportan en este artículo han sido financiadas parcialmente por el Proyecto de Investigación 33A105 de la Secretaria de Ciencia y Técnica y del Departamento de Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús y por el proyecto CCG10-UPM/TIC-5694 del Gobierno Autónomo de Madrid. 8. REFERENCIAS
[1] [2] Fig. 8: Esquema y subproductos de TCD–MUEU Sommerville, I. 2005. Ingeniería 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 contribución de este artículo es la presentación de un proceso metodológico llamado “Conceptualización de Requisitos”, el cual se estructura en dos fases llamadas Análisis Orientado al Problema y Análisis Orientado al Producto y cuyo objetivo consiste en estructurar y caracterizar la masa de información proveniente de la actividad de educción y contenida en el discurso del usuario. Complementariamente se proponen seis técnicas para operacionalizar las actividades asociadas a las fases del modelo de proceso de conceptualización de requisitos propuesto. Para cada técnica se identifican, mediante esquemas, el flujo de trabajo con detalle de los insumos y los producidos intermedios y finales. Asimismo, cabe destacar la aplicación de técnicas pertenecientes a otros campos disciplinares, tales como la técnica de Análisis de Protocolo (AP) [20] proveniente de la Ingeniería del Conocimiento y cuya aplicación ha sido de gran utilidad en el desarrollo de la primera tarea de Segmentación del Discurso de Usuario (SDU); y la técnica de Análisis Cognitivo del DU proveniente de las Teorías Cognitivas de la Educación, las cuales basan su potencial en la identificación y uso de los diferentes Tipos de Conocimiento (TC) que se encuentran embebidos en los distintos segmentos de texto del DU. La aplicación de la técnica de Análisis Cognitivo del DU ha contribuido al desarrollo de las tareas segunda y tercera del proceso (Análisis Cognitivo de los Segmentos de Texto (ACST) y Construcción del Espacio Problema en Escenarios de Usuario (CEPEU)). Se prevé como siguientes pasos de esta investigación: (a) la validación empírica del proceso de conceptualización de requisitos mediante la técnica 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. Método Formal de Modelización Conceptual para Sistemas Software. Tesis Doctoral Universidad Politécnica de Madrid, España.

[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 Metodología Orientada al Conocimiento para la Educción de Requisitos en Ingeniería 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 Inducción Basado en las Características del Dominio
Programa de Magister en Ingeniería en Sistemas de información. Escuela de Posgrado. Facultad Regional Buenos Aires. Universidad Tecnológica Nacional. Buenos Aires, Argentina. zappapet@yahoo.com. 2 Grupo de Investigación en Sistemas de Información. Departamento de Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Buenos Aires, Argentina. rgarcia@unla.edu.ar.
1

Marcelo López N.1, Ramón Garcia-Martinez2

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo: Recibido: 23/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Explotación de Información, caracterización de dominios, agrupamiento, inducción, generación 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 explotación de información utilizan distintos algoritmos de minería de datos para obtener patrones de conocimiento a partir de los ejemplos (instancias) que se tienen sobre el dominio de problema Una de las hipótesis con las que trabajan estos algoritmos es que la complejidad del dominio sobre cuya información se trabaja, no incide sobre la calidad de los patrones obtenidos. Uno de los procesos de explotación de información de interés es el de descubrimiento de reglas de pertenencia a grupos que utiliza algoritmos de agrupamiento (clustering) y algoritmos de inducción. En este trabajo se caracteriza la complejidad de los dominios en términos de las piezas de conocimiento que los describen y que los procesos de explotación de información 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 función de los algoritmos que se utilizan en el proceso y de la complejidad de los dominios al cual aplican.

1. INTRODUCCIÓN Varios autores [1-5] han señalado la necesidad de disponer de procesos de explotación de información que permitan obtener conocimiento a partir de las grandes masas de información disponible, su caracterización y tecnologías involucradas. En [6] se han definido cinco procesos de explotación de información: descubrimiento de reglas de comportamiento, descubrimiento de grupos, descubrimiento de atributos significativos, descubrimiento de reglas de pertenencia a grupos y ponderación de reglas de comportamiento o de pertenencia a grupos. Los procesos de explotación de información utilizan distintos algoritmos de minería 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 hipótesis implícitas con las que trabajan estos algoritmos es que fijados los algoritmos para el proceso de explotación de información, la complejidad del dominio sobre cuya información 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 términos de las piezas

de conocimiento que los describen y que los procesos de explotación de información 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 explotación de información descubrimiento de reglas de pertenencia a grupos, la calidad de los patrones que se obtiene difiere en función 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 artículo se caracterizan los distintos tipos de complejidad de dominios (sección 2), las preguntas de investigación 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 términos 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 clasificación enunciados y el protocolo de clasificación de dominios propuesto en [8] se pueden clasificar los dominios en función 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 demás 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 número 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 número 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 explotación de información de interés es el de descubrimiento de reglas de pertenencia a grupos que utiliza algoritmos de agrupamiento (clustering) y algoritmos de inducción. El proceso de descubrimiento de reglas de pertenencia a grupos aplica cuando se requiere identificar cuáles son las condiciones de pertenencia a cada una de las clases en una partición desconocida “a priori”, pero presente en la masa de información disponible sobre el dominio de problema. Son ejemplos de problemas que requieren este proceso: tipología de perfiles de clientes y caracterización de cada tipología, distribución y estructura de los datos de un website, segmentación etaria de estudiantes y comportamiento de cada segmento, clases de llamadas telefónicas en una región y caracterización de cada clase, entre otros [10]. Este proceso y sus subproductos pueden ser visualizados gráficamente en la Figura 1.
Fig. 1: Esquema y subproductos resultantes de Agrupamiento e Inducción

El proceso se puede describir de la siguiente manera [6]: en primer lugar se identifican todas las fuentes de información (bases de datos, archivos planos, entre otras), se integran entre sí formando una sola fuente de información a la que se llamará datos integrados. Con base en los datos integrados se aplica Agrupamiento. Como resultado de la aplicación de Agrupamiento se obtiene una partición 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, constituyéndose este en un archivo con atributo clase identificado (GR). Se aplica Inducción 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 INVESTIGACIÓN En este proyecto se han planteado las siguientes preguntas de investigación:  ¿Es correcta la suposición que la performance de los algoritmos utilizados para agrupamiento e inducción es independiente de la complejidad del dominio?  En caso de falseamiento de la suposición previa: ¿Cuál es el par <algoritmo de agrupamiento, algoritmo de inducción> que mejor performance proporciona dada la complejidad del dominio? 5. DISEÑO EXPERIMENTAL Se consideraron de interés para el estudio los siguientes dominios: Dominios de Complejidad Mediana, Dominios Oscilantes, Dominios Complejos, Dominios Hipercomplejos. En orden a dar respuesta las preguntas de investigación se ha diseñado un experimento estructurado en tres pasos. El primer paso consiste en la preparación del experimento e involucra: (a) generación del dominio, basado sobre la generación de las clases y reglas que indican la pertenencia a cada clase y (b) generación 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 ejecución 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 inducción 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 comparación entre el conjunto de reglas de clasificación 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 representación se muestra en la Figura 2.

(e) aplicación de inducción a los grupos obtenidos, (g) generación de reglas descubiertas y (f) comparación 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 inducción: 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. Descripción de los distintos tipos de escenarios utilizados en la experimentación
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 experimentación se utiliza entonces el banco de pruebas para la generación de dominios en condiciones de laboratorio, la generación de ejemplos en dichas condiciones, el agrupamiento por parte de diversos algoritmos de agrupamiento, la inducción de reglas sobre el conjunto de grupos de ejemplos, la obtención de reglas de pertenencia a grupos por parte de los distintos algoritmos de inducción, y finalmente la contrastación 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 dinámica de trabajo que tiene el banco de pruebas puede ser descrita entonces de la siguiente manera: (a) generación de clases, (b) generación de reglas de pertenencia a cada clase, (c) generación 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

NÙMERO 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 inducción> 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 inducción>.

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 términos de Diagramas de Kiviat

Como resultado del análisis sobre los resultados de la experimentación emergieron las siguientes proposiciones experimentales: 1. Proposición Experimental 1: Para dominios de tipo mediano (pertenecientes al grupo A), se verificó experimentalmente que la combinación 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 Proposición Experimental 1. 2. Proposición Experimental 2: Para dominios de tipo hipercomplejo (pertenecientes al grupo B), se verificó experimentalmente que la combinación que ofrece mejor cubrimiento de reglas es también SOM VS AQ15,, pero con un rendimiento más bajo, cercano al 65 por ciento en promedio. Esto verifica la Proposición Experimental 2. 3. Proposición Experimental 3: Para dominios de tipo complejo (pertenecientes al grupo C), se verificó experimentalmente que la combinación que ofrece mejor cubrimiento de reglas es SOM VS AQ15, con 49 por ciento como valor promedio. Esto verifica la Proposición Experimental 3.

4. Proposición Experimental 4: Para dominios de tipo oscilante (pertenecientes al grupo D), se verificó experimentalmente que la combinación que ofrece mejor cubrimiento de reglas es SOM VS M5, con 60 por ciento en promedio. Esto verifica la Proposición Experimental 4. 5. Proposición Experimental 5: Se observa y se determina experimentalmente que las características del dominio subyacente tienen influencia sobre el resultado experimental obtenido. 6. Proposición General: Se observa también que los valores obtenidos experimentalmente se ajustan sobremanera a lo que se postuló a priori en la clasificación teórica realizada a los distintos dominios según su complejidad. 7. En relación al rendimiento en términos de cubrimiento de reglas de los algoritmos de agrupamiento e inducción combinados se han obtenidos resultados que falsean la suposición que la performance de los algoritmos utilizados para agrupamiento e inducción es independiente de la complejidad del dominio.

26

La Tabla 2 muestra los resultados para los Dominios Medianos, resultando la mejor combinación (con más 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 empíricamente que la suposición sobre que la performance de los algoritmos utilizados para agrupamiento e inducción es independiente de la complejidad del dominio es falsa. Se ha encontrado que: [a] para Dominios Medianos, Complejos e Hipercomplejos la combinación de algoritmos con más cubrimiento es la de AQ15 y SOM; y [b] para Dominios Oscilantes la combinación de algoritmos con más cubrimiento es la de M5 y SOM. Con lo expuesto se logra identificar el par <algoritmo de agrupamiento, algoritmo de inducción> que mejor performance proporciona dada la complejidad del dominio. Se observa que con independencia del algoritmo de agrupamiento, el algoritmo de inducción M5 es el que mejor funciona para Dominios Oscilantes y el algoritmo CN2 es el que mejor funciona para Dominios Complejos. Como futuras líneas de investigación se prevé extender en una primera etapa estos estudios a la combinación de otros algoritmos de agrupamiento e inducción; y en una segunda etapa a otros procesos de explotación de información. 8. AGRADECIMIENTOS Las investigaciones que se reportan en este artículo han sido financiadas parcialmente por los proyectos UNLa 33A105 y UNLa 33B102 de la Universidad Nacional de Lanús. 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 explotación de información basados sobre sistemas inteligentes. Tesis presentada para obtener el grado de Doctor en Ciencias Informáticas, Facultad de Informática, Universidad Nacional de La Plata, Argentina. [7] Britos, P. & García-Martínez, R. 2009. Propuesta de Procesos de Explotación de Información. Proceedings XV Congreso Argentino de Ciencias de la Computación. Workshop de Base de Datos y Minería de Datos, 10411050.

La Tabla 3 muestra los resultados para los Dominios Complejos, resultando la mejor combinación (con más 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 combinación (con más 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 combinación (con más 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 combinación de los algoritmos estudiados que mejor resulta (reglas generadas con mayor cubrimiento) en función de la complejidad de cada dominio.
Tabla 6. Rendimiento de los algoritmos en términos 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 Caracterización Empírica de Dominios para Uso en Explotación de Información. Proceedings XVII Congreso Argentino de Ciencias de la Computación, pp. 1047-1055. [9] Rancan, C.; Pesado, P. & García-Martínez, 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. Minería de Datos Basada en Sistemas Inteligentes. Editorial Nueva Librería. [11] Kogan, A. et al. 2007. Algunos resultados experimentales de la integración de agrupamiento e inducción como método de descubrimiento de conocimiento. Proceedings IX Workshop de Investigadores en Ciencias de la Computación, 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), 69–90. [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 Comparación de Métricas de Estimación para Proyectos de Explotación de Información
Programa de Doctorado en Ciencias Informáticas. Facultad de Informática. Universidad Nacional de La Plata. Argentina. ppytel@gmail.com 2 Grupo de Investigación en Explotación de Información. Laboratorio de Informática Aplicada. Universidad Nacional de Río Negro. Argentina. paobritos@gmail.com 3 Grupo Investigación en Sistemas de Información. Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Argentina. rgarcia@unla.edu.ar
1

Pablo Pytel1, Paola Britos2, Ramón García-Martínez3

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo Recibido: 23/04/2012 Correcciones: 29/05/2012 Aceptado: 31/05/2012 Palabras clave Aseguramiento de calidad, métricas métodos de estimación de esfuerzo, explotación de información, ingeniería 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 protección” que se aplica a lo largo de todo el proceso de ingeniería software incluyendo entre otros los mecanismos de medición sobre métricas del producto y del proyecto. Por otro lado, para mejorar los procesos correspondientes al desarrollo de Proyectos de Explotación de Información se identifica la necesidad de registrar métricas 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 métodos de estimación existentes para Proyectos de Explotación de Información, uno orientado a proyectos con tamaño relativamente grande y otro orientado a proyectos pequeños que son los normalmente requeridos por las Pequeñas y Medianas Empresas (PyMEs).

1. INTRODUCCIÓN El Aseguramiento de la Calidad del Software (SQA) es una “actividad de protección” que se aplica a lo largo de todo el proceso de ingeniería software [1] incluyendo entre otros los mecanismos de medición sobre métricas del producto y del proyecto. Estas métricas comprenden un amplio rango de actividades que incluyen el aseguramiento y control de calidad, modelos de fiabilidad, modelos para evaluación de ejecución 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 Explotación de Información es una subdisciplina de la informática relativamente nueva y vinculada a la Inteligencia de Negocio [3]. Esta disciplina engloba un conjunto de técnicas encaminadas a la extracción de conocimiento procesable, implícito en el almacén de datos de la organización. Dicho conocimiento es previamente desconocido y puede resultar útil para algún proceso [4, 5]. Al intentar llevar adelante diferentes Proyectos de Explotación de Información con un alto grado de previsibilidad y

calidad se utilizan distintos modelos de producción y metodologías [6]. Esto incluye el registro de métricas para suministrar información relevante a tiempo y para intentar mejorar tanto los procesos como los productos. Dentro de las métricas a utilizar se destaca la medición 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 finalización. De esta manera se destaca la necesidad de contar con métodos de estimación de esfuerzo confiables para Proyectos de Explotación de Información. Dada las diferencias que existen entre un proyecto convencional de construcción de software y un proyecto de explotación de información, los métodos usuales de estimación no son aplicables ya que los parámetros a ser utilizados son de naturalezas diferentes. Por ejemplo, las herramientas de estimación de software convencional como COCOMO II [7] o PRICE-S [8] utilizan como parámetros la cantidad de líneas de código, la experiencia del equipo de trabajo, características de la plataforma de desarrollo, entre otras. Sin embargo, en

29

proyectos de explotación de información existen otras características que deben ser consideradas para la estimación, como por ejemplo, cantidad de fuentes de información, nivel de integración de los datos, el tipo de problema a ser resueltos, entre las más representativas de este tipo de proyectos. Por otro lado, en [9] se propone un método analítico de estimación para proyectos de explotación de información el cual se denomina Matemático Paramétrico de Estimación para Proyectos de Data Mining (en inglés Data Mining Cost Model, o DMCoMo). Pero según sus autores este método se puede considerar confiable en un rango de esfuerzo muy superior al de los proyectos pequeños que son los que usualmente requieren las Pequeñas y Medianas Empresas [10]. Por lo tanto, en este contexto este trabajo tiene el objetivo de analizar dos métodos de estimación existentes para Proyectos de Explotación de Información. Para ello primero se realiza un análisis del método de estimación DMCoMo (sección 2), luego se describe un nuevo método de estimación orientado a las Pequeñas y Medianas Empresas (PyMEs) propuesto por los autores (sección 3) realizando una comparación de ambos métodos utilizando datos de proyectos reales (sección 4). Finalmente se indican algunas conclusiones y las futuras líneas de trabajo (sección 5). 2. ANÁLISIS DEL MÉTODO DMCoMo En esta sección se realiza el análisis del método de estimación Matemático Paramétrico de Estimación para Proyectos de Data Mining (en inglés Data Mining Cost Model, o DMCoMo). Primero se realiza una breve descripción del método (sección 2.1) se delimita el problema detectado (sección 2.2) y se presentan los resultados del análisis realizado (2.3) con sus conclusiones (2.4). 2.1 Descripción del Método DMCoMo El método DMCoMo [9] es un modelo analítico de estimación de la familia de COCOMO [7] que permite estimar los meses/hombre que serán necesarios para desarrollar un proyecto de explotación de información desde su concepción hasta su puesta en marcha. Los modelos de estimación analíticos se definen a través de la aplicación de métodos de regresión en datos históricos para obtener relaciones matemáticas entre las variables (también llamadas factores de costo) representadas en ecuaciones matemáticas. DMCoMo define 23 factores de costo los cuales están vinculados a las características más importantes de los proyectos de explotación de información. Estos factores de costo se clasifican en seis categorías que se indican en la Tabla 1. Una vez que los valores de los factores de costo son definidos, se ingresan en las ecuaciones matemáticas suministradas por el método. DMCoMo dispone de dos fórmulas (Tabla 2), una que utiliza 23 factores de costo como variables (fórmula denominada como MM23) que puede ser utilizada cuando el proyecto está bien definido y otra de 8 factores de costo como variables

(fórmula MM8) que puede utilizarse cuando no todos los datos del proyecto se encuentran definidos. Como resultado de ingresar los valores a la ecuación correspondiente, se obtiene la cantidad de meses/hombre correspondiente al proyecto.
Tabla 1. Categorías y Factores de Costo de DMCoMo
CATEGORÍA FACTOR DE COSTO  Cantidad de Tablas (NTAB)  Cantidad de Tuplas de las Tablas (NTUP)  Cantidad de Atributos de las Tablas (NATR)  Grado de Dispersión de los Datos (DISP)  Porcentaje de valores NULL (PNUL)  Grado de Documentación de las Fuentes de Información  Grado de Integración 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 Técnicas Disponibles para cada Modelo
(MTEC) Relacionados al Desarrollo de la Plataforma Relacionados a las Técnicas y Herramientas (DMOD)

Relacionados a los Datos

Relacionados a los Modelos

 Cantidad y Tipo de Fuentes de Información Disponibles  Distancia y Medio de Comunicación entre Servidores de
Datos (SCOM) (NFUN)

 Herramientas Disponibles para ser Usadas (TOOL)  Grado de Compatibilidad de las Herramientas con Otros  Nivel de Formación 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 Documentación que es necesario generar (DOCU)  Cantidad de Sitios donde se realizará el Desarrollo y su
Grado de Comunicación (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. Fórmulas 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 Método DMCoMo El problema identificado es motivado por la propia limitación señalada en [9] debido a las características de los 15 proyectos utilizados para la validación del método. Los autores declaran que DMCoMo se considera confiable para estimar el esfuerzo de proyectos de explotación de información que se encuentren en el rango de esfuerzo de 90 a 185 meses/hombre (es decir 7,5 a 15,42 años/hombre). Si el esfuerzo del proyecto se encuentra fuera de este rango, el comportamiento del método es desconocido. Sin embargo, por experiencia se conoce que los proyectos de explotación de información utilizados en las PyMEs poseen un esfuerzo mucho menor a los 90 meses/hombre. Para realizar una revisión inicial del comportamiento de DMCoMo se ha utilizado un proyecto de tamaño pequeño.

30

A partir de las características del proyecto, se definen los valores de los factores de costo y se calculan los esfuerzos correspondientes a las fórmulas (ver Tabla 3). El objetivo del proyecto era la detección de evidencias de causalidad entre Satisfacción 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 método DMCoMo sobreestima el esfuerzo requerido para el proyecto en aproximadamente un 630%, con un error para la fórmula MM23 de 64,56 meses/hombre, y de 63,86 meses/hombre para MM8.
Tabla 3. Revisión inicial de DMCoMo
Factor de Costo
ADIR COMP DEXT DISP DMOD DOCU KDAT MATRn MATRt MFAM MTEC MTUP

Para realizar un análisis más detallado del comportamiento de las fórmulas por tamaño de proyecto se utilizan gráficos Boxplot (ver Tabla 5). Estos gráficos permiten ver en un único gráfico los datos correspondientes a los límites superior e inferior (valores máximo y mínimo), el desvío máximo (media más la desviación estándar) y mínimo (media menos la desviación estándar) y la media de los resultados obtenidos en el experimento.
Tabla 5. Gráficos Boxplot por fórmula
Fórmula

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 focalización en proyectos pequeños. Para ello se ha utilizado el método de simulación Monte Carlo [11] generando en forma pseudo-aleatoria un banco de pruebas con los datos de 30.000 proyectos de explotación de información (distribuidos en forma equitativa en tres rangos de tamaño: Proyectos Pequeños, Medianos y Grandes). Luego se han aplicado las fórmulas MM23 y MM8 definidas por DMCoMo para calcular los esfuerzos estimados (Datos disponibles en http://tinyurl.com/DMCoMoData). 2.3 Resultados del Análisis Realizado para DMCoMo A partir del banco de prueba con los proyectos generados en forma pseudo-aleatoria se procede a realizar un análisis estadístico de los mismos. En la Tabla 4 se indica la media estadística obtenida por cada una de las fórmulas de DMCoMo y tamaño de proyecto. De esta tabla se puede ver que la media de la fórmula MM23 en proyectos medianos es un 52% más grande que la de proyectos pequeños y la media de los proyectos grandes es un 42% más grande que los proyectos medianos (o sea un 117% con respecto a los proyectos pequeños). Por otro lado, la fórmula MM8 posee un crecimiento menor por escalones de aproximadamente el 22% con respecto al tamaño anterior.
Tabla 4. Media por fórmula y tamaño de proyecto
MEDIA (en meses/hombre) Proyectos Pequeños Proyectos Medianos Proyectos Grandes MM23 84,41 128,89 183,45 MM8 102,59 126,30 148,51

Al realizar la primera observación de estos gráficos, se nota que los costos de ambas fórmulas poseen un solapamiento entre sí, siendo mayor para la fórmula de 8 factores de costo (variable MM8) que la de 23 factores de costo (MM23). Además se puede observar que los valores de MM23 poseen costos estimados dispersos entre 33,16 meses/hombre (valor mínimo para proyectos pequeños) y 234,14 meses/hombre (valor máximo 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 tamaño del proyecto la fórmula MM23 crece aproximadamente el doble con respecto a MM8, se puede decir que es más conservadora. Al observar en los gráficos el desvío estándar donde están contenidos la mayor cantidad de los proyectos (más 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 análisis realizados se puede indicar que para los proyectos medianos el costo estimado por ambas fórmulas es muy similar (casi idéntico en algunos casos), pero esto no sucede en los otros tamaños de proyectos. En los proyectos pequeños los valores estimados por la fórmula MM8 siempre son superiores a los estimados por MM23, mientras que en los proyectos grandes sucede lo contrario. En todos los casos los mínimos 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 podría aplicar para proyectos medianos y grandes, el método no es recomendable para proyectos pequeños. 3. MÉTODO DE ESTIMACIÓN PARA PyMEs Debido a la necesidad detectada de contar con un método de estimación fiable para proyectos de tamaño pequeño, los autores han propuesto un nuevo método de estimación analítico con énfasis en las características de las PyMEs. Para ello primero se identifican y describen las principales características de los proyectos en PyMEs que son utilizadas para identificar los factores de costo del método propuesto y luego se procede a especificar la fórmula mediante regresión Tanto para la definición del método propuesto y su posterior validación se ha utilizado información de 44 proyectos reales de explotación de información (http://tinyurl.com/proy-PYMES) que fueron recolectados por investigadores del Grupo de Investigación en Sistemas de Información del Departamento de Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús (GISI-DDPyTUNLa), investigadores del Grupo de Estudio en Metodologías de Ingeniería de Software de la Facultad Regional Buenos Aires de la Universidad Tecnológica Nacional (GEMIS-FRBA-UTN), e investigadores del Grupo de Investigación en Explotación de Información de la Sede Andina (El Bolsón) de la Universidad Nacional de Río Negro (SAEB-UNRN). Debe notarse que todos estos proyectos fueron realizados utilizando la metodología CRISP-DM [12], por lo que el método propuesto se considera confiable para proyectos de explotación de información a ser desarrollados con dicha metodología. 3.1 Principales Características de Proyectos de Explotación de Información en PyMEs Según el informe de las PyMEs y el reporte de espíritu empresarial [13] de la Organización para la Cooperación y el Desarrollo Económico (OCDE) “las PyMEs constituyen la forma dominante de organización empresarial en todos los países de todo el mundo, representando más del 95% y hasta el 99% de la población de empresas según el país”. Sin embargo, a pesar de que es conocida la importancia de las PyMEs, no existe un criterio universal para identificarlas. Dependiendo de cada país y región se utilizan diferentes criterios cuantitativos y cualitativos para reconocer a una organización como PyME. De esta forma, en Latinoamérica cada país tiene una definición diferente [14]: Argentina identifica como PyME a las empresas autónomas que poseen una facturación menor a US$ 20.000 por año (monto máximo que depende de la actividad realizada); Brasil incluye a todas las compañías 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 Organización Internacional para la Estandarización

(más conocida como International Organization for Standardization o ISO) ha reconocido la necesidad de especificar definir los perfiles de ciclos de vida para proyectos de ingeniería en software en pequeñas entidades (denominadas en inglés ‘Very Small Entities’ o VSE) y se encuentra trabajando en el estándar ISO/IEC 29110 [15]. El término VSE fue definido por el grupo de trabajo 24 de SO/IEC JTC1/SC7 como cualquier “empresa, organización, departamento o proyecto que cuenta con a lo más 25 personas” [16]. A partir de estas definiciones y nuestra propia experiencia, en este trabajo contempla que un proyecto de explotación de información 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 extraído de las bases de datos disponibles para resolver un problema de negocio específico, 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 máximo de 25 personas (incluyendo tanto los consultores subcontratados y al personal de la empresa involucrada) para realizar el proyecto en menos de un año. Las primeras tareas de un proyecto de explotación de información 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 organización. Pero, en estos proyectos, además se necesita conocer las fuentes de información disponibles en la organización por lo que es preciso relevar los repositorios existentes junto con su estructura. Como estos repositorios suelen no estar correctamente documentados, es necesario entrevistar también a los expertos en datos de la organización. Ya que estos expertos son escasos y con poca disponibilidad, será necesario entonces requerir a su buena disposición (y la de sus jefes) para que participen en las sesiones de educción para identificar las características de la organización y de los repositorios a ser utilizados. Por otro lado, la infraestructura de la Tecnologías de la Información y la Comunicación (TIC) de las PyMEs es analizada. En [17] se indica que en Latinoamérica más del 70% de las PyMEs cuentan con una infraestructura informática, pero sólo 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 cálculo y de documentos) para registrar la información comercial y operativa. Esto significa que los repositorios a ser utilizados en el proyecto estarán implementados en diferentes formatos y tecnologías. Aunque estos repositorios no suelen ser grandes (normalmente no superan el millón de registros), las tareas de

32

preparación de datos (es decir, limpieza, formateo e integración de los datos) tendrán 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 específico para realizarlas. 3.2 Identificación de los Factores de Costo del Método de Estimación Propuesto para PyMEs Teniendo en cuenta las características de los proyectos de Explotación de Información para PyMEs que se indican en la sección 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 método de estimación es preferible ignorar muchos de los datos no significativos para evitar que el modelo sea demasiado complejo y por lo tanto poco práctico. De esta manera se busca eliminar las variables tanto irrelevantes como dependientes, y además reducir la varianza y el ruido. Los factores de costo han sido seleccionados teniendo en cuanta las tareas más críticas de la metodología CRISP-DM: en [19] se indica que actualmente la construcción de los modelos de minería de datos y buscar los patrones es bastante simple, pero el 90% de los esfuerzos del proyecto están incluidos en el pre-procesamiento de los datos (es decir la fase de ‘Preparación de los Datos’ de CRISP-DM). A partir de nuestra experiencia, las otras tareas críticas se relacionan con la fase de ‘Comprensión del Negocio’ (entre las que se destacan el entendimiento del negocio y la identificación 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 explotación de información (OBTY). Este factor de costo analiza el objetivo del proyecto de Explotación de Información considerando el tipo de proceso a ser aplicado para obtenerlo de acuerdo a la definición 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 explotación de información 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

Descripción
Tanto los directivos como el personal poseen buena disposición para colaborar en el proyecto. Sólo los directivos poseen buena disposición para colaborar en el proyecto mientras que el personal es indiferente al proyecto. Sólo la alta gerencia posee buena disposición para colaborar en el proyecto mientras que la gerencia media y el personal es indiferente. Sólo la alta gerencia posee buena disposición 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 cálculos, documentos entre otros). En este caso interesa saber tanto la cantidad de repositorios disponibles (públicos o privados de la organización) como la tecnología en que se encuentran implementadas. No interesa conocer la cantidad de tablas que posee cada repositorio dado que se entiende que la integración 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 tecnología, la complejidad de las tareas de integración de los datos puede ser mayor o menor. Criterios recomendados:  Si todos los repositorios están implementados con la misma tecnología, entonces se consideran como compatibles para la integración.  Si todos los repositorios permiten exportar los datos en un formato común, entonces pueden ser considerados como compatibles para la integración al realizar la integración con estos datos exportados.  Por otro lado, si existen repositorios que no están en forma digital (es decir impreso en papel) se considera que la tecnología será no compatible pero el método de estimación no puede predecir el tiempo requerido para realizar la digitalización de esta información 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

Descripción
Se desea conocer los atributos que caracterizan el comportamiento o la descripción de una clase ya conocida. Se desea dividir los datos disponibles en grupos sin poseer una clasificación conocida previamente. Se desea conocer los atributos que caracterizan a grupos sin poseer una clasificación conocida previamente. Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre un comportamiento o la identificación de una clase conocida. Se desea conocer los atributos que poseen mayor frecuencia de incidencia sobre la identificación de una clase desconocida previamente.

 Grado de apoyo de los miembros de la organización (LECO). El grado de apoyo y participación de los miembros de la organización se analiza viendo si la alta gerencia (normalmente los dueños de la PyME), la gerencia media (supervisores y/o jefes de área) y/o el resto del personal están dispuestos a ayudar al equipo de trabajo para comprender el negocio y los

Descripción
Sólo 1 repositorio disponible Entre 2 y 4 repositorios con tecnología compatible para integración Entre 2 y 4 repositorios con tecnología no compatible para integración Más de 5 repositorios con tecnología compatible para integración Más de 5 repositorios con tecnología no compatible para integración 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 minería 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

Descripción
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 Más de 5.000.000 tuplas en la tabla principal

tener un mínimo conocimiento y experiencia en el desarrollo de proyectos de explotación de información. 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

Descripción
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 información a la tabla principal (como es la tabla que define las características 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

Descripción
No se utilizan tablas auxiliares Hasta 1.000 tuplas en las tablas auxiliares Entre 1.001 y 50.000 tuplas en las tablas auxiliares Más de 50.000 tuplas en las tablas auxiliares

 Funcionalidad de las herramientas disponibles (TOOL). Finamente, este factor de costo evalúa las características de las herramientas disponibles para realizar el proyecto. Para ello se analiza tanto las funcionalidades de preparación de los datos como los algoritmos de minería 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 documentación existente sobre los repositorios de datos. Es decir, se analiza si existe un documento donde se indique la tecnología en que están 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 información no se encuentre, será necesario realizar reuniones con los expertos (encargados de la administración 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

Descripción
La herramienta posee funciones tanto para el formateo e integración de los datos (permitiendo importar más de una tabla de datos) como para aplicar las técnicas de minería de datos. La herramienta posee funciones tanto para el formateo como para aplicar las técnicas de minería de datos, y permite importar más de una tabla de datos en forma independiente. La herramienta posee funciones tanto para el formateo como para aplicar las técnicas de minería de datos, pero sólo permite importar una tabla de datos. La herramienta posee funciones sólo para aplicar las técnicas de minería de datos, y permite importar más de una tabla de datos. La herramienta posee funciones sólo para aplicar las técnicas de minería de datos y sólo permite importar una tabla de datos.

Descripción
Todas las tablas y repositorios están correctamente documentados Más del 50% de las tablas y repositorios están correctamente documentados y existen expertos en los datos disponibles para explicarlos Menos del 50% de las tablas y repositorios están correctamente documentados pero existen expertos en los datos disponibles para explicarlos Las tablas y repositorios no están documentadas pero existen expertos en los datos disponibles para explicarlos Las tablas y repositorios no están documentados y existen expertos en los datos pero no están disponibles para explicarlos Las tablas y repositorios no están documentados y no existen expertos en los datos para explicarlos

3.3 Especificación de la Ecuación del Método de Estimación Propuesto para PyMEs Una vez que los factores de costo fueron definidos, se han utilizado para caracterizar 34 proyectos reales de explotación de información recolectados junto con su esfuerzo real (provistos por colegas como se ha indicado anteriormente). Un método de regresión lineal multivariante [21] fue aplicado sobre estos datos para obtener una ecuación lineal de la forma utilizada por los métodos de la familia COCOMO. Como resultado del proceso de regresión se obtiene la fórmula indicada en la Tabla 14.
Tabla 14. Fórmula del método 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 método de estimación 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. COMPARACIÓN DE LOS MÉTODOS Para comparar el comportamiento del método DMCoMo (descripto en la sección 2) y el método de estimación orientado para PyMEs (descripto en la sección 3) se utiliza la información de otros 10 proyectos reales recolectados (provistos por colegas como se ha indicado anteriormente). Con esta información primero se ha calculado los esfuerzos por el método DMCoMo mediante la definición de cada uno de los factores de costo y su aplicación en las fórmulas MM23 y MM8. De la misma manera, se realiza el mismo procedimiento para calcular el esfuerzo para el método propuesto para PyMEs con fórmula PEM definida en la sección 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 método DMCoMo (MM8 y MM23) y por el método propuesto para PyMEs (PEM) indicando también los errores absolutos (es decir la diferencia entre el esfuerzo real y el calculado por cada método) y los errores relativos (ErRel que es calculado como el error absoluto dividido por el esfuerzo real del proyecto).

Para mayor claridad, esta comparación se refleja en un gráfico boxplot (Figura 1) donde el comportamiento del esfuerzo real y los calculados se muestran indicando los valores mínimos y máximos, el rango del desvío estándar y el valor medio para cada uno.

Fig. 1: Comportamiento del Esfuerzo Real, el método DMCoMo y el Método de Estimación

Tabla 15. Comparación 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 Método 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 años/hombre, para ambas fórmulas) con un desvío estándar 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 proporción mayor al 590% (menor diferencia para el proyecto #6 y fórmula MM8). Por otro lado, al analizar los resultados del método de estimación para PyMEs (PEM) en la tabla 15, se puede observar que produce un error promedio de aproximadamente 1,46 meses/hombre con un desvío estándar para el error de aproximadamente ± 2 meses/hombre. Para poder analizar en forma más detallada este método se muestra en la Figura 2 un gráfico boxplot mostrando el comportamiento del esfuerzo real y el calculado por PEM. De este segundo gráfico se nota que el método 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 método propuesto es de 4,51 meses/hombre).

Fig. 2: comportamiento del Esfuerzo Real y el Método de Estimación

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 método 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 máximo 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 máximo a un mes/hombre (proyecto #2).

estimaciones poseen un error relativo menor al 10%. Estos errores se podrían deben a la existencia de factores que están afectando el cálculo del esfuerzo que no han sido considerados por el método de estimación. 6. AGRADECIMIENTOS El trabajo de investigación presentado en este artículo ha sido parcialmente financiado por los proyectos 33A105 and 33B102 de la Universidad Nacional de Lanús, por los proyectos 40B133 y 40B065 de la Universidad Nacional de Río Negro, y el proyecto EIUTIBA11211 de la Universidad Tecnológica Nacional Facultad Regional Buenos Aires. Además, los autores desean agradecer a los investigadores que han provisto la información de proyectos reales en PyMEs utilizados en este trabajo. 7. REFERENCIAS
[1] [2] Pressman, R. 2005. Ingeniería de Software: Un enfoque práctico. 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 García-Martínez, 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 Medellín, 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. Marbán, O.; Menasalvas, E. & Fernández-Baizán, C. 2008. A cost model to estimate the effort of data mining projects (DMCoMo). Information Systems, 33(1), 133150. García-Martínez, R.; Lelli, R. & Merlino, H. 2011. Ingeniería de Proyectos de Explotación de Información para PYMES. Proceedings XIII Workshop de Investigadores en Ciencias de la Computación, 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. & Durán, J. 2009. Manual de la Micro, Pequeña y Mediana Empresa. Una contribución a la mejora de los sistemas de información y el desarrollo de las políticas públicas. 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: Comparación del EfR y el estimado

5. CONCLUSIONES Dentro de los mecanismos de Aseguramiento de Calidad se incluyen las métricas. Entre ellas se incluyen los modelos para evaluar la productividad del proyecto que permiten establecer objetivos de mejora. Los Proyectos de Explotación de Información 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 finalización. De esta manera se destaca la necesidad de contar con métodos de estimación de esfuerzo confiables para Proyectos de Explotación de Información de tamaño pequeño. Este trabajo describe y analiza dos métodos de estimación existentes para Proyectos de Explotación de Información: el método de estimación DMCoMo y el otro un método de estimación orientado a las PyMEs. Del estudio del método DMCoMo se puede ver que este método genera estimaciones superiores a los 5 años/hombres, umbral de esfuerzo muy superior al real vinculado a proyectos de PyMEs. Al comparar este método con los esfuerzos de proyectos pequeños se puede ver que tiende a sobrestimar el esfuerzo en casi seis veces más el real. Por lo tanto se puede indicar que este método sólo puede ser utilizado para proyectos con tamaño grande. Por otro lado, el método de estimación orientado a PyMEs produce resultados más precisos que DMCoMo para proyectos pequeños. Aunque el comportamiento general de este método tiende a ser similar al de los proyectos reales, tiene una leve inclinación 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 validación 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] Ríos, M. D. 2006. El Pequeño Empresario en ALC, las TIC y el Comercio Electrónico. 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] García-Martínez, 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 elicitación de requerimientos en proyectos de explotación de información
Diego Mansilla1, Florencia Pollo-Cattaneo2, Paola Britos3, Patricia Pesado2, Ramón GarcíaMartínez 4
1

Grupo de Estudio en Metodologías de Ingeniería de Software. Facultad Regional Buenos Aires. Universidad Tecnológica Nacional. Buenos Aires, Argentina. dmansilla@educ.ar. 2 Programa de doctorado en Ciencias informáticas. Facultad e Informática. Universidad Nacional de La Plata. La Plata. Buenos Aires. Argentina. fpollo@posgrado.frba.utn.edu.ar. 3 Grupo de Investigación en Explotación de información. Sede Andina. Universidad Nacional de Río Negro. Argentina. paobritos@gmail.com. 4 Grupo Investigación en Sistemas de Información. Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Lanús, Argentina. rgarcia@unla.edu.ar. INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo: Recibido: 30/03/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Proceso, elicitación, requerimientos, proyecto explotación de información. 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 problemática abordada en los proyectos de explotación de información se basa en transformar la información existente de una organización en conocimiento útil para la toma de decisiones. Los modelos tradicionales de educción de requisitos, al enfocarse en el producto, no pueden ser utilizados para obtener la información requerida para los procesos de explotación de información. En este contexto, se presenta un proceso para elicitación de requerimientos en proyectos de explotación de información haciendo énfasis en las fases de: conceptualización, definición de negocio e identificación de procesos de explotación de información.

1. INTRODUCCIÓN La Ingeniería de Software tradicional ofrece una serie de herramientas y procesos para la elicitación de requerimientos software que son utilizadas en proyectos de creación de sistemas de información automatizados. Se entiende por requerimientos a “la especificación de lo que debe ser implementado. Ellos son descripciones de cómo debe comportarse el sistema” [1]. Los requerimientos suelen clasificarse de diferentes formas, siendo una de las clasificaciones más consensuada la organización de acuerdo al nivel del requerimiento, dividiéndose en requerimientos de negocio, requerimientos de usuario, requerimientos funcionales y requerimientos de sistema [2]. Las herramientas de elicitación de la Ingeniería de Software se enfocan en la descripción de los diferentes tipos de requerimientos, haciendo hincapié en las características 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 gráficamente los procesos de negocio relevado y son utilizados como herramientas para la validación 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 cómo hacerlo. Además, la recopilación de la información está orientada a los datos de entradas y salidas de los productos a desarrollar y cómo esa información será transformada por el sistema. En etapas posteriores del proyecto, se trabaja en el cómo hacer para que el producto software satisfaga las necesidades planteadas por el negocio y en la construcción del mismo. El producto obtenido es, entonces, un sistema software que cumple con las características esperadas para el contexto en que será utilizado.

38

A diferencia de los proyectos de desarrollo de software, la problemática abordada en los proyectos de inteligencia de negocio se basa en transformar la información existente en una organización en conocimiento útil para la toma de decisiones, mediante el uso de herramientas analíticas [4]. Los modelos de elicitación de requerimientos y de gestión de proyectos, al enfocarse en el producto software a construir, no pueden ser utilizados para obtener la información requerida por los procesos de explotación de información. En este contexto, se hace necesario transformar la experiencia existente en el uso de las herramientas de elicitación 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 explotación de información [5-7]. En este trabajo se describirá el problema (sección 2), se presentará un proceso para elicitación de requerimientos en proyectos de explotación de información (sección 3), haciendo énfasis en la fase de conceptualización (sección 3.1), en la fase de definición de negocio (sección 3.2) y en la identificación de procesos de explotación de información (sección 3.3). Luego se propone el estudio de un caso (sección 4) y se proponen algunas conclusiones y futuras líneas de trabajo (sección 5). 2. DESCRIPCIÓN DEL PROBLEMA Actualmente, diversas disciplinas se han estandarizado para poder incorporar buenas prácticas provenientes de las experiencias adquiridas y de la incorporación de nuevos descubrimientos. La disciplina de gestión de proyectos, por ejemplo, generó un cuerpo de conocimiento donde definen las diferentes áreas del proceso de gestión de proyectos. La Ingeniería en software definió diferentes metodologías de desarrollo de sistemas, entre las cuales se establece el proceso de Desarrollo de requerimientos, donde definen las etapas de Elicitación, Análisis, Especificación y Validación 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 metodología para el desarrollo de sistemas de explotación de información, CRISP-DM [8], P3TQ [9] y SEMMA[10]. En el campo de la explotación de información 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, sólo 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 metodologías de trabajo asociadas a los proyectos de explotación de información y no adaptan las técnicas de elicitación de requerimientos tradicionales de la Ingeniería en Software a las necesidades requeridas por los procesos de explotación de información. Ante esta situación, es necesario comprender qué pasos se deberían llevar a cabo y, qué técnicas de elicitación tradicionales podrían adaptarse en proyectos de explotación de información. 3. PROCESO DE ELICITACIÓN 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 metodología CRISP-DM, que puede ser utilizada en la definición de requerimientos de negocio del ciclo de vida de Kimball. El modelo de proceso propuesto descompone la problemática de la elicitación de requerimientos para proyectos de explotación de información en diferentes fases, que irán transformando el conocimiento adquirido en cada fase previa. Para cada fase del proceso se identifican qué técnicas de elicitación de requerimientos pueden ser utilizadas para resolver la problemática presentada para cada fase. Este modelo de proceso se contextualiza dentro del concepto de proyecto que, según el Project Management Institute, es un “emprendimiento temporario para crear un producto, resultado o servicio único” [14]. Para los proyectos de explotación de información, el objetivo planteado es identificar requerimientos de información y utilizar dicha información en la toma de decisiones. En [15] se plantea una propuesta operativa sobre la ejecución de proyectos de explotación de información, pero sin entrar en el detalle de qué técnicas de elicitación pueden utilizarse en el proyecto. Se debe comenzar definiendo diferentes capas dentro de un proyecto de explotación de información. Cada una de estas capas tendrá un objetivo y una serie de actividades a realizar, y a su vez, podrá seguir descomponiéndose en capas más específicas. Para cada actividad se plantea una adaptación de una técnica tradicional de elicitación de requerimientos.
Gestión de Proyecto

Comprensión del Negocio

Entendimiento de los datos

Preparación de datos

Modelado

Evaluación

Implantación

Conceptualización del dominio de negocio

Definición del Negocio

Identificación de Procesos de Explotación de Información

Fig. 1: Fases propuestas

La Figura 1 refleja las fases estratégicas de un proyecto de explotación de información, enfocándose en las actividades de elicitación de requerimientos propuestas. La capa de gestión de proyecto se encarga de la coordinación de las diferentes actividades necesarias para alcanzar los objetivos planteados, es “la aplicación

39

del conocimiento, habilidades y herramientas para alcanzar los requerimientos planteados” [14]. La disciplina de gestión de proyectos está definida por el Project Management Institute [14] pero dichas actividades están fuera del alcance de este proceso. Este trabajo identifica las actividades relacionadas con el proceso expuesto en [12], las que pueden utilizarse como guía de las actividades a realizar dentro de un proyecto de Explotación de Información. El primer paso de dicho proceso es la fase de Conceptualización del Negocio. Su objetivo es identificar el vocabulario de negocio y los procesos del mismo, con el fin de poder establecer un lenguaje común entre el equipo de proyecto y el interlocutor del negocio. La necesidad de establecer este vocabulario radica en que las metodologías de DM-BI han tenido dificultades con el grupo de usuarios respecto del léxico utilizado por los equipos de DM-BI [15]. Esta fase generará los casos de uso del negocio en estudio. Una vez concluida la Conceptualización del Negocio, comenzará la fase de Definición del Negocio cuyo objetivo es definir los conceptos, datos y repositorios de información 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 comunicación entre los interlocutores del negocio y los analistas de DM-BI y el modelo conceptual del mismo. También se identificarán los diferentes repositorios de información que posee la organización, los que almacenan datos relacionados con los conceptos identificados. La fase de Identificación de Procesos comienza una vez formalizadas las definiciones asociadas al negocio e identificados los repositorios de información. Su objetivo es definir la lista de problemas de información a resolver y los procesos de explotación de información que deberán ser utilizados para cada problema de inteligencia de información encontrado. 3.1 Fase de Conceptualización La Conceptualización es la fase del proceso de elicitación que será utilizada por el analista para comprender el lenguaje de la organización y los vocabularios específicos del negocio. Esta fase es crucial en el proyecto, ya que la información recopilada y las decisiones que se establezcan como resultado de esta fase afectarán al alcance del proyecto y a las soluciones que serán construidas por el mismo [12]. Los proyectos se inician con la identificación 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 serán los beneficiados por el proyecto. La Figura 2 refleja las diferentes actividades y productos de la fase de conceptualización y la Tabla 1 resume las principales entradas y salidas de la misma.

Lista de usuarios a relevar Comprensión del Negocio Relevamiento de Procesos

Documentación de Relevamiento Elaboración de Modelos

Modelo de Casos de Uso

Fig. 2: Fase de Conceptualización Tabla 1. Entradas y salidas de Fase de Conceptualización
Productos Entrada Fase Tarea Entrada Comprensión del Negocio Conceptualización Relevamiento de procesos Elaboración de modelos Formalización de proyecto Lista de usuarios a relevar Informe de relevamiento Representación Documento de Inicio de Proyecto Plantilla de lista de usuarios Plantilla de Informe de Relevamiento Técnica de Transformación a utilizar Análisis de sponsors de proyecto Entrevistas Workshops Otros. Análisis de relevamiento Productos de salida Salida Lista de usuarios a relevar Informe de relevamiento Documento de Casos de Uso Representación 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 información que administra el negocio, las visiones estratégicas de la organización, los problemas de operatoria en los procesos de negocio, entre otros. Dependerá principalmente quién es el patrocinador del proyecto y qué problemáticas de información se tratarán de resolver. Inicialmente, se comenzará con un grupo reducido de personas que tengan una visión estratégica del negocio y luego en diferentes iteraciones se podrá ir profundizando en niveles más operativos. La actividad debe generar un listado de usuarios que serán 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 utilización del negocio por parte de un cliente y cómo 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 técnicas de elicitación de requerimientos software tradicionales pueden ser de utilidad para la recopilación de datos relacionados con el funcionamiento del negocio. Si bien estas técnicas son necesarias para el desarrollo del software a construir, no satisfacen las necesidades de los proyectos de Explotación de Información, ya que éstos requieren definir problemáticas del negocio en cuanto a información existente y disponible en la organización, y no las características que deben tener los sistemas software que almacenan dicha información. Las técnicas de elicitación de proyectos de desarrollo software enfocan su atención 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 técnicas tradicionales para recopilación de información podemos mencionar: las entrevistas, la observación y los talleres de dominio [3]. La información 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 técnicas enfocadas a obtener información de negocio y no de producto, pueden utilizarse en los proyectos de explotación de información. En la Elicitación de Requerimientos de Software se establece el concepto de “Usuario de Producto campeón”. Es la persona que sirve de interlocutor entre los diferentes usuarios y el analista de requerimientos. Es quien tiene una visión clara de lo que el nuevo sistema software hará [2]. En proyectos de Explotación de Información se deben identificar estos usuarios campeones, pero en vez de ser interlocutores, serán 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 Elicitación, el analista de negocio deberá enfocarse en la descripción 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 también las palabras específicas utilizadas en el negocio con el fin de obtener tanto una descripción de las diferentes tareas que se realizan en cada función, como así también la terminología utilizada en cada caso. Esta actividad podrá ser documentada mediante la descripción de los casos de uso, donde el caso corresponderá a la definición 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 interacción 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 sería el cliente del negocio. La tarea del modelado de casos de uso utiliza la información obtenida de los relevamientos de negocio y genera en la última actividad de la fase, la elaboración de modelos. 3.2 Fase de Definición de Negocio Concluida la actividad de identificación de los conceptos asociados al negocio en estudio, se comienza a definirlo en términos de relación de conceptos, vocabulario y fuentes de información que dan soporte a los procesos de negocio. La fase de Definición de Negocio requiere como entrada los casos de uso definidos en la fase de Conceptualización. 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 Definición de Negocio
Productos Entrada Fase Tarea Entrada Elaborar Diccionario Relacionar Definición de Negocio Elaborar Mapa de Repositorios Mapa de Conceptos Plantillas de Mapas de conceptos Análisis de relevamiento Mapa de Repositorios Conceptos Documento de Casos de Uso Diccionario de conceptos Representación Modelo de Casos de Uso Estructura de Concepto Técnica de Transformación a utilizar Análisis del Caso de Uso Modelo de clases Productos de salida Salida Diccionario de conceptos Mapa de Conceptos Representación 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 metodologías estructuradas para la definición 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 Conceptualización. 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 Definición Estructura de datos Relaciones Procesos Descripción Término que se desea definir. Descripción del significado del concepto. Definición 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 podrán identificar las diferentes entidades que forman parte del proceso de negocio. Otras representaciones han sido propuestas para poder documentar la información relevada [10]. Como objetivo secundario de esta actividad se encuentra el descubrimiento de sinónimos de conceptos. Los procesos de negocio hacen uso de un mismo concepto pero cada uno de ellos puede considerar características 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 aún no tenga servicios y, en el segundo caso sea cliente sólo aquella persona que ya ha adquirido un servicio. Estas diferencias en condiciones y características 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 técnicas de modelado de clases y de Entidad/Relación pueden ser utilizadas como base del modelo. El objetivo es abstraerse de la implementación en software de dichos conceptos y focalizarse en su relación a nivel negocio. El analista trabajará sobre la vinculación que existe entre los diferentes conceptos definidos en el diccionario, con los

Fig. 3: Fase de Definición 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 información de la organización. Aquí se requiere de la participación de diferentes personas (roles) de la organización. Podemos mencionar a: los analistas de software, los administradores de base de datos y los responsables de las metodologías y procesos de negocio. Para obtener los datos requeridos por los procesos de Explotación de Información, en caso de existir modelos estructurados de análisis de los sistemas de información existentes en la organización, la identificación de donde se encuentran las implementaciones físicas del concepto de demora puede ser base del descubrimiento. Otra opción puede ser la identificación de sistemas de información (tanto software como manuales) que den soporte de información a los procesos de negocio. Es importante obtener el volumen de información de dichos repositorios, ya que son necesarios para poder definir qué procesos de Explotación de Información pueden ser aplicados en el proyecto. Con la información 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 relación puede ser utilizada como base por cualquiera de las técnicas de procesos de Explotación de Información. 3.3 Fase de Identificación de procesos de Explotación de Información La fase de Identificación de Procesos de explotación de Información tiene como objetivo definir qué procesos de explotación de información resolverán 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) Ponderación de interdependencia de atributos (PIA) Descubrimiento de reglas de pertenencia al Grupo (DRPG)  Ponderación 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 Conceptualización del dominio. Incluso, durante la actividad de relevamiento de procesos, se podrá realizar la actividad de identificación 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 Explotación Seleccionar proceso de explotación

Tabla 4. Entradas y salidas de la fase de Definición
Productos Entrada Fase Tarea Entrada Identificar problemas de Identificación de Procesos de Seleccionar Explotación de proceso de Información explotación de conceptos información a utilizar diccionario información Diccionario de Plantilla de de Problemas problemas del lenguaje explotación negocio Lista de Formalización de proyecto Representación Documento de Inicio de Proyecto Plantilla de Léxico Extendido Técnica de Transformación a utilizar Análisis de documentación Salida Lista de Problemas de negocio Proceso de Representación Plantilla de problemas de negocio Productos de salida

Para poder definir qué técnica utilizar, se comienza con el relevamiento de los problemas que el usuario detecta en su negocio y se utiliza la información generada en las fases previas como fuente de información para la aplicación de las técnicas mencionadas. Al igual que en la fase de Conceptualización, pueden utilizarse las técnicas tradicionales de recopilación de información, enfocando la problemática en las necesidades de información 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 más importantes según 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 podrían 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 análisis de los mismos. Este análisis se realiza mediante la utilización del modelo de Léxico Extendido del Lenguaje (LEL) [20]. El modelo LEL se obtiene del dominio del negocio, aplicando un conjunto de reglas para su construcción. Se han realizado trabajos sobre el enfoque LEL en el análisis 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 símbolos presentados en el modelo LEL. El modelo presenta 4 tipos generales de símbolos, símbolo sujeto, símbolo objeto, símbolo verbo y símbolo estado. Para poder definir qué técnica puede ser utilizada, se propone una tabla de decisión que analice las estructuras LEL, los conceptos identificados en la fase de Conceptualización, los repositorios de información existentes y las acciones que se desean resolver y en función de esa información, ofrecer qué técnica de explotación sería la más adecuada para el proyecto en cuestión. La Tabla 5 muestra qué condiciones se evalúan y las reglas que fueron identificadas como base para este trabajo. Como observaciones, se entiende como descubrimiento de conceptos sujeto a la búsqueda 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 Definición de Negocio

42

Tabla 5. Selección de proceso de Explotación
Condiciones ¿Existen los conceptos identificados como objeto en algún repositorio de Información del negocio? ¿Existen conceptos identificados como Objeto que no se encuentren en ningún repositorio? La acción 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 información existente en los repositorios? La acción 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 tasación del inmueble ofrecido. Se presenta dicha tasación 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 interés en comprar una casa, los vendedores completan una planilla con los datos de la persona y las características 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 están consultando por los inmuebles ofertados o están buscando inmuebles para comprar. Si los interesados acuerdan la compra de un inmueble, serán clientes de la inmobiliaria y se da comienzo al proceso de compra de inmuebles. La información de los clientes e inmuebles se almacena en un archivo Excel. El tercer paso implica el análisis de la información relevada y su modelado en casos de uso. Con la información relevada podríamos identificar los siguientes casos de uso de negocio:  Vender Inmuebles, que refleja la acción de venta del inmueble por parte de una persona y gestionada por la inmobiliaria  Comprar Inmuebles, que refleja la acción de compra por parte de una persona de un inmueble ofrecido por la inmobiliaria  Ofrecer Inmuebles, que refleja la acción de mostrar los inmuebles que dispone para venta la inmobiliaria a los interesados. Este es un breve análisis de los casos de uso identificados. Un trabajo más exhaustivo detallaría más la información de cada caso de uso. Fase de Definición de Negocio: El cuarto paso consiste en la elaboración del diccionario de conceptos del negocio. Del relevamiento, podemos identificar los conceptos indicados en la Tabla 6.
Tabla 6. Conceptos identificados en la definición
Cliente Vendedor Persona que ofrece un inmueble para la venta Estructura: Nombre y Apellido Documento Identidad Información de Contacto Relaciones: Inmueble Tasación Procesos : Vender Inmueble Tasación Valuación del inmueble para su venta Estructura: Valor Tasación (Numérico) Identificador de Inmueble Moneda Tasación

Esta tabla tiene como objetivo poder decidir, mediante el análisis de la información obtenida acerca del negocio en estudio, qué proceso de Explotación de Información puede aplicarse en el proyecto. Es importante destacar que esta tabla de decisión incorporará nuevos conocimientos y nuevas reglas, con el fin de mejorar el criterio de selección de la técnica. Con la incorporación de más proyectos y más experiencia, se pueden refinar las reglas de las tablas y así lograr una mejor selección del proceso. Con la fase de Identificación del Proceso de Explotación de Información, se concluye la fase y el proceso. Las tareas posteriores dependerán del proceso definido y de las actividades establecidas en el proyecto. 4. PRUEBA DE CONCEPTO 4.1 Descripción del negocio Inmobiliaria del distrito federal Buenos Aires que trabaja en zonas residenciales de la ciudad. Dirigida por dos socios, dueños 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 construcción 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 trámites y asesores de compra/venta. 4.2 Implementación del proceso Fase de Conceptualización: El primer paso del proceso es identificar interesados del proyecto y armar la lista de interesados que serán relevados. De este paso, con el breve conocimiento que tenemos de la empresa, podemos definir 3 interesados: los dueños 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 relación de los conceptos definidos. La Figura 5 muestra brevemente las relaciones existentes entre los conceptos identificados.

Con el análisis LEL obtenido y la información de los repositorios y conceptos, determinamos qué proceso de Explotación de Información se puede aplicar. Para ello, se utiliza como guía la Tabla 5 y se analiza la regla obtenida. El resultado del análisis se ve en la Tabla 8.
Tabla 8. Resultado del análisis LEL
Condiciones Regla ¿Existen los conceptos identificados como objeto en algún SI repositorio de Información del negocio? ¿Existen conceptos identificados como Objeto que no se NO encuentren en ningún repositorio? La acción 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 información 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 séptimo paso es la identificación de problemas de negocio. Esta identificación 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 podrían estar interesados en ella. La lista puede tener varios problemas. Cada problema debe ser priorizado y estar identificado unívocamente. Con los problemas identificados, se continúa con el octavo paso, el análisis LEL de los problemas. En este caso, el análisis identifica (entre otros) los símbolos expresados en la Tabla 7.
Tabla 7. Símbolos asociados al problema de la inmobiliaria
Inmueble [Objeto] Noción - Es el objeto que vende la inmobiliaria Impacto - Lo vende un cliente de la inmobiliaria Ofrecer una casa [Verbo] Noción - Es la acción de presentarle una casa en venta a un cliente Impacto - La casa debe satisfacer los criterios de los interesados Cliente [Sujeto] Noción - 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] Noción

Los factores requeridos, ¿Se encuentran identificados? Los factores identificados, ¿Pueden deducirse de la información existente en los repositorios? La acción 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 elicitación de requerimientos en proyectos de Explotación de Información y cómo utilizar técnicas existentes de elicitación de requerimientos, pero adaptándolas dichos proyectos. El proceso se descompone en 3 fases, donde se analiza el negocio en estudio (Fase de Conceptualización), se trata de armar un modelo del negocio y definirlo para poder comprender el alcance del mismo y la información que administra (Fase de Definición de Negocio) y por último, los problemas que los usuarios del negocio identifican y conociendo los conceptos y repositorios de información que administran, se presenta una herramienta para poder establecer qué técnica de explotación de información puede ser aplicada para un proyecto de explotación de información (Fase de Identificación de Procesos de Explotación de Información). Como futuras líneas de trabajo se están identificando diferentes casos para la contrastación empírica del proceso propuesto con énfasis en la validación de la tabla de decisión referida en la sección 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 Educción de Requisitos en Proyectos de Explotación de Información. En Aguilar R. et al (Eds.), Ingeniería de Software e

44

[5]

[6]

[7] [8]

[9] [10]

[11]

[12] [13]

Ingeniería del Conocimiento: Tendencias de Investigación e Innovación Tecnológica en Iberoamérica, 01-11. Alfaomega. Pollo-Cattaneo, F. et al. 2010. Ingeniería de Proyectos de Explotación de Información. Proceedings XII Workshop de Investigadores en Ciencias de la Computación, 172176. Pytel, P. et al. 2011. Ingeniería de Requisitos Basada en Técnicas de Ingeniería 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. García-Martínez, 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. Metodología para Especificación de Requisitos en Proyectos de Explotación de Información. Proceedings XI WICC, 333-335. Kimball, R. et al. 2011. The Data Warehouse Lifecycle Toolkit. Wiley & Sons. Vanrell, J.; Bertone, R. & García-Martínez, R. 2010. Modelo de Proceso de Operación para Proyectos de Explotación de Información. Proceedings XVI Congreso argentino de ciencias de la computación, 674-682.

[14] William, R. 1996. A Guide to the Project Management Body of Knowledge. PMI Publishing. [15] Britos, P.; Dieste, O. & García-Martínez, 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] García-Martínez, 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 Medellín. [19] Pollo-Cattaneo, F. et al. 2010. Ingeniería de Procesos de Explotación de Información. En Aguilar, R.; Díaz, J. & Gómez, G. (Eds.), Ingeniería de Software e Ingeniería del Conocimiento: Tendencias de Investigación e Innovación Tecnológica en Iberoamérica, 252-263. Alfaomega. [20] Leite, J. C. S. P. 1994. Notas de Aula. Material del curso de Ingeniería de Requisitos. [21] Fresno, M. et al. 1998. Derivación 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 Explotación de Información
Escuela de Postgrado, Universidad Tecnológica Nacional. Ciudad Autónoma de Buenos Aires, Argentina. javanrell@gmail.com. Facultad de Informática. Universidad Nacional de La Plata. La Plata, Argentina. pbertone@lidi.info.unlp.edu.ar 3 Grupo de Investigación en Sistemas de Información. Departamento de Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Remedios de Escalada, Argentina. rgarcia@unla.edu.ar.
1 2

Juan A. Vanrell1, Rodolfo Bertone2, Ramón García-Martínez3

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo: Recibido: 23/04/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Explotación de información, 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 explotación de información poseen características muy distintas a las de los proyectos de desarrollo de software tradicionales. Las clásicas etapas de análisis, diseño, desarrollo, integración 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 explotación de información para PyMEs siguiendo los lineamientos del modelo de procesos para la industria de software (COMPETISOFT).

1. INTRODUCCIÓN 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 versión actual CMMI [1], MoProSoft [2] o su versión iberoamericana COMPETISOFT [3]. Todos estos son modelos genéricos por lo cual pueden ser utilizados para la ejecución de cualquier tipo de proyecto [4-5]. Dentro de los distintos proyectos que son llevados a cabo por empresas dedicadas al área de tecnologías de la información se encuentra un conjunto denominado proyectos de explotación de información. Como todo conjunto posee características propias que lo hacen diferenciarse del resto. Se considera que estas características son lo suficientemente significativas como para justificar la construcción 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 definición de un modelo que pueda ser utilizado por pequeñas y medianas empresas (Pymes) que serán: fácil de entender, fácil de aplicar y relativamente económicos en su implementación, se decidió crear un modelo de procesos de explotación de información orientado a Pymes tomando como base el modelo COMPETISOFT y adecuándolo a los procesos utilizados para los proyectos de explotación de información.

En este contexto haremos a continuación una introducción a COMPETISOFT y CRISP-DM (sección 2), para luego presentar los problemas encontrados (sección 3), la solución propuesta (sección 4) y un caso de estudio (sección 5) incluyendo las principales conclusiones sobre este trabajo (sección 6). 2. COMPETISOFT Y CRISP-DM En esta sección se introduce el modelo de procesos COMPETISOFT (sección 2.1) y la metodología de explotación de información CRISP (sección 2.2). 2.1 Competisoft COMPETISOFT es la proyección a nivel iberoamericano del modelo de procesos para el desarrollo de software MoProSoft creado por encargo de la Secretaría de Economía 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 países, se le incorporó el modelo de evaluación EvalProSoft [7] y se definieron niveles de madurez. Su propósito es fomentar la estandarización de las operaciones de pequeñas y medianas empresas o departamentos internos de desarrollo, a través de la incorporación de las mejores prácticas en gestión e ingeniería de software, esperando “elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad”. El modelo busca ser fácil de entender, fácil de aprender, no

46

costoso en su adopción 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, ajustándolo 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. Además de definir procesos COMPETISOFT define un patrón que debe ser utilizado para documentar aquellos procesos que una empresa requiere agregar a los existentes en el modelo o para documentar la adecuación de los que ya se encuentra en el mismo. Dicho patrón se encuentra constituido por tres partes: Definición general del proceso, Prácticas y Guías de ajuste. El modelo a desarrollar pretende seguir este patrón para la documentación de los procesos de explotación de información. La estructura del modelo se encuentra dividida en tres categorías: Alta Dirección (DIR), Gerencia (GER) y Operaciones (OPE) reflejando la estructura de una organización. Estas categorías contienen los procesos de gestión de negocio (DIR), gestión de procesos, gestión de proyectos y gestión de recursos (GER) y administración de un proyecto específico, desarrollo de software y mantenimiento de software (OPE). En palabras de los creadores de COMPETISOFT la categoría de Alta Dirección es la “categoría de procesos que aborda las prácticas de Alta Dirección relacionadas con la gestión del negocio” y “proporciona los lineamientos a los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos”, la categoría de gerencia es la “categoría de procesos que aborda las prácticas de gestión de procesos, proyectos y recursos en función de los lineamientos establecidos en la Categoría de Alta Dirección”, además “proporciona los elementos para el funcionamiento de los procesos de la Categoría de Operación, recibe y evalúa la información generada por éstos y comunica los resultados a la Categoría de Alta Dirección” y la Categoría de Operación es la “categoría de procesos que aborda las prácticas de los proyectos de desarrollo y mantenimiento de software”, además “esta categoría realiza las actividades de acuerdo a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos generados”. 2.2 CRISP-DM La metodología CRISP-DM [8] se encuentra definida en base a un modelo jerárquico de procesos. El foco se pondrá en los procesos del nivel superior que son lo suficientemente genéricos como para cubrir todas las posibles aplicaciones de explotación de información. Esta metodología define un ciclo de vida de los proyectos de explotación de información que define las principales fases de un proyecto de este tipo. Estas fases

son: Entendimiento de Negocios, Entendimiento de los Datos, Preparación de los Datos, Modelado, Evaluación y Despliegue. Claramente estas fases difieren de las fases definidas para un proyecto de desarrollo de software clásico (inicio, requerimientos, análisis y diseño, construcción, integración y pruebas y cierre). A continuación 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 definición de un problema de explotación de información y diseñar un plan preliminar para lograr dichos objetivos. El Entendimiento de los Datos comienza con la recolección 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 hipótesis de información oculta. La fase de Preparación 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 selección de tablas, registros y atributos como transformación y limpieza de datos para herramientas de modelado. El Modelado incluye la selección de técnicas de modelado y la calibración de sus parámetros a los valores óptimos, suelen existir distintas técnicas para un mismo problema de explotación de información y cada una de ellas suele tener ciertos requisitos sobre los datos, muchas veces es necesario volver a la fase de preparación de los datos. La Evaluación requiere la construcción de uno o varios modelos que aparentan tener la mayor calidad desde una perspectiva de análisis, requiere la evaluación del modelo y revisión de los pasos ejecutados para la construcción del modelo para asegurarnos de lograr los objetivos de negocio, al final de esta fase se debería poder tomar una decisión respecto de la utilización 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 explotación de información repetible a través de toda la empresa. 3. PROBLEMA Al desarrollar diferentes proyectos de explotación de la información con un alto grado de previsibilidad y calidad se utilizan distintos modelos de producción y metodologías. 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 producción en si misma, sino

47

también las tareas relacionadas a la gestión de un proyecto y de la empresa que lo desarrolla. En el caso de proyectos clásicos 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 más testeado). Sin embargo, se considera que estos modelos no son adecuados para empresas que se dedican a llevar a cabo proyectos de explotación de información. Por otro lado existen metodologías que acompañan el desarrollo de proyectos de explotación de información entre las cuales destacamos a CRISP-DM, P³TQ 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 gestión de proyectos y de empresa. Aceptando que los proyectos de desarrollo de software tradicional poseen características muy distintas a los proyectos de explotación de información, sobre todo en la parte operativa de un proyecto [9], una lectura rápida a la documentación del modelo de procesos de desarrollo de software, COMPETISOFT, muestra grandes diferencias en cuanto a los procesos naturales de los proyectos de explotación de información. La diferencia más 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, Análisis y Diseño, Construcción, Integración, Pruebas y Cierre no resultan naturales en un proyecto de explotación de información. En la misma línea, al evaluar las principales metodologías existentes para los proyectos de explotación de información mencionados anteriormente, se observa la falta de herramientas que permitan soportar de forma completa la fase de administración de proyectos. Esta fase se encuentra bien definida y agrupada en el proceso de “Administración de Proyectos Específicos” dentro de la metodología COMPETISOFT. Sin embargo se encuentran algunas definiciones de tareas o actividades que pertenecen a este proceso como puede ser la construcción 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 categoría de operación definidos en COMPETISOFT con los procesos requeridos por los proyectos de explotación ya sea adecuando las fases definidas en COMPETISOFT a las necesarias para los proyectos de explotación de información, eliminando las fases que no son adecuadas o proponiendo nuevas fases en su reemplazo. En este trabajo se utiliza como metodología de referencia a CRISP-DM dado que, al comparar las tres metodologías

mencionadas anteriormente [10], se pudo observar que esta última contenía todos los elementos a nivel operación de las otras. 4. SOLUCIÓN PROPUESTA Se propone como solución a los problemas mencionados en la sección anterior, mantener los procesos de la categoría de Operación definidos en COMPETISOFT, como Administración de Proyectos y Desarrollo de Proyectos readecuándolos a los proyectos de explotación de información. Las categorías de Alta Dirección y Gerencia se mantienen invariables basándose en el modelo COMPETISOFT dado que se definen a un nivel empresarial y no a un nivel de producción con lo cual pueden ser adecuadas para cualquier tipo de proyecto. Como se menciona anteriormente la metodología CRISPDM no hace distinción entre procesos sino que posee un único proceso en el cual se definen todas las tareas dividiéndolas en fases, ya sea las relacionadas con la administración como las relacionadas con el desarrollo. Esta división 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 administración del proyecto para controlar su avance, realizar correcciones y recolectar datos para futuros proyectos. La reestructuración de estos dos procesos en el desarrollo de proyectos de Explotación de Información brindará mayor claridad a las tareas de administración ya que, como se menciona anteriormente, las tareas de administración que se encuentran mencionadas en las metodologías evaluadas se encuentran dentro de un mismo proceso de desarrollo. Esta división no se limita a separar las tareas existentes en las metodologías sino que se construye el nuevo proceso basándose en el proceso de administración utilizado para el desarrollo de software clásico, específicamente el definido en el modelo COMPETISOFT, lo cual enriquece el proceso de administración de proyectos. A este proceso se lo adecuó para responder a las exigencias de los proyectos de Explotación de Información. La incorporación del proceso de administración del proyecto, y su concepción como un proceso distinguible del de desarrollo, constituye una aportación a la gestión de los proyectos de Explotación de Información, ya que ninguna de las metodologías evaluadas, incluyendo a CRISP-DM, hace una separación clara entre las tareas que se deben llevar a cabo para la administración 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 administración, estas tareas

48

son las de “Determinar los objetivos del Negocio” que se encuentra relacionada con la elicitación de requerimientos y “Evaluación de la Situación”, ambas ubicadas en el subproceso de “Planificación / 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 administración pertenecen a COMPETISOFT. Junto con esta reestructuración de tareas se agregaron actividades para llevar a cabo cada una de las etapas definidas en el proceso de administración, para aquellos casos en los que no existía ya un conjunto de actividades definidas, como puede observarse en las tareas. Se definieron al mismo tiempo técnicas que pueden ser aplicadas como recomendación para llevar a cabo las actividades que se mencionan en el proceso de administración 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 capítulo anterior, las fases de
SUBPROCESO TAREA Entendimiento del negocio Definir el proceso específico basado en la descripción 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 descripción del proyecto y en el proceso específico Determinar tiempo estimado para cada actividad Elaborar plan de adquisiciones y capacitación Establecer el equipo de trabajo Establecer el calendario de actividades Calcular el costo estimado del proyecto

desarrollo de los proyectos de Explotación de Información no coinciden naturalmente con las fases mediante las cuales se desarrollan los proyectos de software clásicos. Si bien se mantuvo la estructura utilizada por COMPETISOFT, tanto la división 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 metodología CRISP-DM. Se agregaron actividades faltantes para obtener un proceso coherente y detallado y se incorporaron a este proceso recomendaciones de las técnicas a utilizar para cada una de las tareas definidas en los subprocesos del proceso de desarrollo del proyecto. El resultado de esta solución puede verse en las Tablas 1 y 2, en las que se omite, por falta de espacio, la descripción de las actividades necesarias para realizar cada tarea y las técnicas sugeridas.

Tabla 1. Proceso de Administración 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 Capacitación 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) Terminología Costos y beneficios Plan de Proyecto, incluye ciclos y actividades, tiempo estimado, plan de adquisiciones y capacitación, equipo de trabajo, costo estimado, calendario, plan de manejo de riesgos y protocolo de entrega Plan de Desarrollo (incluye descripción del producto y entregables, proceso específico, equipo de trabajo y calendario) Lista inicial de técnicas y herramientas

Planificación / Entendimiento del negocio

Evaluación de la situación

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 distribución de información Revisar con el responsable la descripción del producto, el equipo de trabajo y el calendario Revisar cumplimiento del plan de adquisiciones y capacitación 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 terminación 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

Realización

 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 aceptación

Evaluación 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 técnica de modelado Generar el diseño de test Modelado Construir el modelo Evaluar el modelo Evaluar resultados Evaluación Revisar el proceso Determinar próximos pasos Entrega Producir un reporte final SALIDA  Metas del Data Mining  Criterios de éxito del Data Mining  Reporte de datos iniciales  Reporte de descripción de datos  Reporte de exploración de datos  Reporte de calidad de los datos  Datasets  Descripción de los Datasets  Justificación de inclusión / exclusión  Reporte de limpieza de datos  Atributos derivados  Registros generados  Datos combinados (combinación de tablas y agregaciones)  Datos formateados  Técnica de modelado  Suposiciones de modelado  Diseño de test  Establecimiento de parámetros  Modelos  Descripción del modelo  Evaluación del modelo  Revisión de los parámetros establecidos  Evaluación de los resultados de Data Mining respecto a los criterios de éxito

Entendimiento de los datos

Preparación de los datos

     

Modelos aprobados Revisión del proceso Lista de posibles decisiones Decisiones Reporte final Presentación final

5. CASO DE ESTUDIO En su Tesis de Maestría, Flores [11] desarrolla un proyecto de explotación de información para detectar patrones en la producción de daños y/o averías en la cadena de distribución de la industria automotriz. Para llevar a cabo su trabajo el autor optó por el uso de la metodología de desarrollo a CRISP-DM basándose en la independencia de esta metodología con respecto a las herramientas tecnológicas a utilizar en la explotación de datos. Por ser ésta de libre acceso, orientada al negocio y finalmente debido a ser la más completa de las metodologías evaluadas ya que incluye, además de los procesos de desarrollo, una fase preliminar dedicada al entendimiento del negocio que no es contemplada por el resto de las metodologías evaluadas. Se utilizó el trabajo de Flores para realizar una comparación entre el uso de CRISP-DM y el uso del Modelo de Procesos propuesto como solución de esta Tesis, destacando similitudes, diferencias y las ventajas que provee el nuevo modelo. Se dividió esta comparación basándose 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, Ejecución y Fin. Esta comparación 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 deberían ser realizadas en caso de utilizar el nuevo modelo. 6. CONCLUSIONES Durante la investigación documental se encontraron diferencias importantes entre las PyMEs y las grandes empresas que justifican la creación de un modelo de

procesos diferenciado y se reconocieron las diferencias entre el modelo COMPETISOFT y las metodologías para proyectos de explotación de información. Se detectaron carencias en lo referente a la gestión de proyectos y de la empresa en las metodologías utilizadas para proyectos de explotación de información, así como algunas herramientas básicas de gestión 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 clásico para llevar a cavo proyectos de explotación de información. Como solución a estos problemas se propuso el uso de COMPETISOFT como punto de partida para la construcción 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 administración 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 administración las actividades necesarias para la realización de cada tarea y se propusieron herramientas para llevarlas a cabo. En la evaluación de un caso de estudio se reconoció la falta de información histórica al ejecutar proyectos con CRISP-DM lo cual es solucionado en el modelo propuesto a través del proceso de Administración de Proyectos.

50

Tabla 3. Resumen de la Comparación
CATEGORÍA Alta Dirección Gerencia PROCESO Todos Todos SUB-PROCESO Todos Todos CRISP-DM No se contempla No se contempla Descripción de los objetivos de negocio. Descripción del estado actual. Plantea-miento de objetivos generales y criterios de éxito. Requerimientos, presunciones y restricciones. Plan de desarrollo. Evaluación de riesgos. Planificación de entregas. Plan de entrega. MODELO DE PROCESOS PARA PROYECTOS DE EXPLOTACIÓN DE INFORMACIÓN Introduce los procesos definidos por Competisoft Introduce los procesos definidos por Competisoft Tareas propuestas por CRISP-DM + Definición de ciclos de desarrollo. Evaluación de tiempos (uso de PERT). Desarrollo del calendario de actividades. Plan de adquisición y capacitación de personal (uso de Diagramas de Gantt). Estimación de costos (DM-COMO o Técnicas empíricas). Identificación de beneficios. Planificación de planes de riesgos y contingencias. Planificación de entregas. Plan de Proyecto. Formalización del inicio de cada ciclo Acordar tareas con el equipo de trabajo. Acordar la distribución de información. Revisar con el responsable la descripción del producto, el equipo de trabajo y el calendario. Revisar cumplimiento del plan de adquisiciones y capacitación. 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 Explotación de Información Tareas propuestas por CRISP-DM + Formalizar la terminación del proyecto o ciclo. Llevar a cabo el cierre del contrato con subcontratistas Tareas propuestas por CRISP-DM + Ejecución de tareas de administración en un proceso aparte. Se sigue una guía de actividades para cumplir con las tareas. Técnicas propuestas Tareas propuestas por CRISP-DM + Técnicas propuestas Tareas propuestas por CRISP-DM + Se sigue una guía de actividades para cumplir con las tareas. Técnicas propuestas Tareas propuestas por CRISP-DM + Técnicas propuestas Tareas propuestas por CRISP-DM + Se sigue una guía de actividades para cumplir con las tareas. Técnicas propuestas Tareas propuestas por CRISP-DM + Las tareas de administración se ejecutan en un proceso aparte. Se sigue una guía de actividades para cumplir con las tareas. Técnicas propuestas

Planificación/ Entendimiento del negocio

Operación

Administración del Proyecto Realización No se contempla

Evaluación y control Proceso Administración de Proyectos (cont.) Subproceso Cierre / Entrega Entendimiento del negocio Entendimiento de los datos Categoría Desarrollo del Proyecto / Fases Incluidas en CRISP-DM Preparación de los datos Modelado Evaluación

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 administración 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-tración 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 ejecución permitiendo que el éxito de un proyecto se base en el ajuste constante del proceso de desarrollo basado en experiencias pasadas. Como futura línea de investigación y desarrollo se prevé trabajar en un análisis de los resultados de aplicación del modelo de procesos propuesto con el objetivo de evaluar ventajas y desventajas del mismo al momento de considerar su puesta en producción. 7. AGRADECIMIENTOS Las investigaciones que se reportan en este artículo han sido financiadas parcialmente por el Proyecto de Investigación 33A105 del Departamento de Desarrollo Productivo y Tecnológico de la Universidad Nacional de Lanús. 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. Secretaría de Economía de México. [3] Oktaba, H. et al. 2008. Competisoft, Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos. Ra-Ma. [4] Vanrell, J. A. et al. 2010. Un Modelo de Procesos de Explotación de Información. Proceedings XII Workshop de Investigadores en Ciencias de la Computación, 167171. [5] García-Martínez, 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 Medellín. [6] Vanrell, J. A. 2009. Elementos para un Modelo de Procesos de Explotación de Información para PyMES. Trabajo de Especialidad en Ingeniería en Sistemas de Información. Escuela de Posgrado. Facultad Regional Buenos Aires. Universidad Tecnológica Nacional. [7] Oktaba, H. et al. 2004. Método de Evaluación de Procesos para la Industria de Software. Secretaría de Economía de México. [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 Operación para Proyectos de Explotación de Información. Anales del XVI Congreso Argentino de Ciencias de la Computación, 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. Detección de Patrones de Daños y Averías en la Industria Automotriz. Tesis de Maestría en Ingeniería en Sistemas de Información. Universidad Tecnológica Nacional. Facultad Regional Buenos Aires.

52

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

Arquitecto en ABC-Flex Ltda. Docente en Universidad de Antioquia y Universidad EAFIT. Medellín, Colombia. jbq@abcflex.net. Analista de Requisitos en ABC-Flex Ltda. Medellín, Colombia. dianahdez@abcflex.net. 3 Analista de Desarrollo en PSL. Medellín, Colombia. prucinque@psl.com.co. INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo: 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 especificación 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 más problemas que los que solucionan. Este artículo presenta un catálogo de antipatrones para evitar las malas prácticas que estos siguieren en la especificación 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. INTRODUCCIÓN A pesar del surgimiento de nuevas técnicas en desarrollo de software y estrategias de gestión de proyectos, los factores por los que falla un proyecto de desarrollo, todavía se encuentran muy relacionados con la gestión de requisitos. El prestigioso reporte caos, pone en evidencia esta situación, que se ha presentado durante las últimas décadas, 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 atención en el análisis de los requisitos. Los casos de uso constituyen unas de las técnicas más usadas para la especificación de requisitos, es por esto que resulta de gran importancia conocer las buenas y malas prácticas al respecto, para mejorar los posibles resultados. En este sentido las buenas prácticas están dadas por los patrones para definir casos de uso efectivos, mientras que las malas prácticas se plantean en los antipatrones para la especificación 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 artículo presenta un resumen de un reconocido catálogo de patrones para casos de uso efectivos detallado en el libro [2].

Por otro lado, el catálogo de antipatrones que se presenta en este artículo, proviene de un cuidadoso análisis de los autores, acerca de los proyectos en los que han participado durante los últimos años, en los cuales los casos de uso han sido la técnica de especificación de casos de uso imperante. La labor docente de algunos de los autores, ha motivado la revisión de las situaciones que atentan contra el buen desempeño de un proyecto de software, a partir de las fallas en la especificación de los casos de uso; la recopilación de la información derivada de esta situación fundamenta el desarrollo del catálogo de antipatrones para la especificación de requisitos funcionales con casos de uso, planteado en este artículo. Para la presentación del catálogo de antipatrones, este artículo se estructura de la siguiente forma: en el capítulo 2 se revisa la disciplina del análisis de requisitos y su relación con los casos de uso, el capítulo 3 presenta información de los patrones y los antipatrones, el capítulo 4 resume el catálogo de patrones para casos de uso efectivos, el capítulo 5 plantea el catálogo de antipatrones para especificar requisitos funcionales usando casos de uso, y el capítulo 6 expone unas conclusiones al respecto.. 2. CASOS DE USO Y ANÁLISIS DE REQUISITOS El análisis de requisitos es una disciplina o flujo de trabajo, posterior al modelado de negocio y previa al

53

análisis y diseño, según el proceso unificado de desarrollo también llamado RUP (por la sigla inglesa de Rational Unified Process) [3]. El principal artefacto a construir en este flujo es el documento de especificación 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 características 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 también 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 análisis de las buenas y malas prácticas en este sentido. Un caso de uso se define como “una colección 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 específica de acciones e interacción entre el usuario y el sistema bajo discusión” [4]. Los elementos que se utilizan en la construcción de modelos de casos de uso, definen las categorías de los antipatrones en el catálogo planteado. Cabe aclarar que RUP también propone casos de uso de negocio los cuales se construyen en la disciplina de modelado de negocio, pero el catálogo de patrones planteado aquí se centra en los de requisitos. 3. LOS PATRONES Y LOS ANTI-PATRONES Un patrón presenta un esquema genérico de solución probada, a un problema recurrente que surge en contextos específicos. El esquema de la solución describe un conjunto de componentes, sus responsabilidades, las relaciones entre estos, y la forma en que dichos componentes colaboran entre sí [5]. Existen diversos catálogos de patrones que tienen como propósito definir buenas prácticas en los diferentes frentes del desarrollo de software; el más famoso es el catálogo GoF que define un conjunto de patrones para tratar problemas de diseño [6]. En contraposición los antipatrones son soluciones negativas que presentan más problemas que los que resuelven; extienden y complementan los patrones de forma natural. El estudio de los antipatrones permite conocer los errores más 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 fáciles de recordar, los nombres pueden aludir con algún 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 específico de los antipatrones para especificar requisitos con caso de uso, se debe tener en cuenta que corresponden a la disciplina de análisis de requisitos y adicionalmente considerar que un buen anti-patrón explica por qué la solución original parece atractiva, por qué se vuelve negativa y cómo recuperarse de los problemas que ésta genera [8]. Con base en estos aspectos, se definen los siguientes ítems para la plantilla de documentación de los antipatrones:
     

Nombre: que ilustre con un toque de humor la situación problemática que se presenta. Nombre alterno: sinónimo para el nombre que motive su recordación. Causas: situación que motiva la aplicación de la solución negativa. Descripción: explicación del problema que se presenta. Factores que motivan su uso: situación que hace que la solución negativa parezca atractiva. Ejemplo y/o posible solución: ejemplo para aclarar el problema de la solución negativa y de su solución, o en caso de que la situación problemática sea evidente, solo se plantea un posible esquema de solución.

4. CATÁLOGO DE PATRONES EN LA ESPECIFICACIÓN DE CASOS DE USO Para definir un catálogo de antipatrones que presenta malas prácticas alrededor de los casos de uso, es fundamental conocer detalladamente las buenas prácticas y los catálogos de patrones acerca de casos de uso. Las buenas prácticas para escribir casos de uso efectivos, se compendiaron en el libro “Writing effective use cases” [9]; luego se formalizaron en el catálogo presentado en “Patterns for Effective Use Cases” [2]. La tabla 1 ilustra las categorías y patrones presentados en este catálogo:
Tabla 1. Catálogo de Patrones para Casos de Uso [2]
Categoría Team Nombre del Patrón 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 comprensión de los patrones para casos de uso efectivos, presentados en el catálogo, a continuación se hace un breve resumen de cada categoría con el conjunto de patrones que le corresponden. 4.1 El Equipo El tamaño del equipo, la retroalimentación que reciben e incluso el background y personalidad de sus miembros son aspectos fundamentales en la conformación de equipos de elicitación de casos de uso ideales. Un equipo ideal sería aquel que no exceda el tamaño 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 número 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 visión general de la aplicación resulta más beneficioso que dedicarle tiempo a los detalles en una etapa temprana del proceso (BreadthBeforeDepth); una vez se conoce la aplicación 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 más 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 comprensión. Finalmente, las revisiones deben ser en dos etapas: Detalladas, revisando forma y fondo, por un grupo interno y pequeño y luego la funcionalidad del caso de uso por parte de los demás 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 visión clara del proyecto por parte de todos los involucrados. Para empezar, la visión del proyecto debe apoyar la misión de la organización (SharedClearVision), y se debe establecer claramente cuáles son sus límites (VisibleBoundary), una aplicación no lo puede resolver todo, debe ser enfocada en resolver lo que realmente es de alto valor para los usuarios (UserValuedTransactions) y tener claro quiénes 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 recordación, y ser en voz activa, un verbo en infinitivo seguido de un sustantivo y de ser necesario un corto complemento (VerbPhraseName); además, 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). También se deben crear campos en las plantillas que permitan incluir datos significativos que no distraigan de la descripción del escenario (Adornments). 4.5 Escenarios y Pasos El caso de uso, al ser una historia, debe generar interés en el lector; que con cada paso escrito en forma simple, logre avanzar (ForwardProgress); describiendo claramente quien ejecuta la acción y cuál es su intención (ActorIntentAccomplished). Combinar condiciones que concluyan en la misma acción (DetectableConditions) y mantener el mismo nivel de abstracción en la descripción 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 tecnología 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 condición 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 también 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 prácticas, pueden resultar en errores de implementación. Es posible que un caso de uso largo en pasos, generalmente más de nueve, tenga más de un objetivo y sea candidato a dividirse (RedistributeTheWealth). Opuesto a esto, casos de uso pequeños 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 añaden valor al negocio o ya no serán tenidos en consideración, deben ser eliminados para evitar distracciones de quien revisa el conjunto de casos de uso (CleanHouse). 5. CATÁLOGO DE ANTIPATRONES EN LA ESPECIFICACIÓN DE CASOS DE USO Teniendo en cuenta que ya existe un catálogo de patrones para especificar casos de uso efectivos; este

55

artículo no pretende ilustrar los antipatrones como la no aplicación de estos patrones; en contraposición pretende estudiar las situaciones que recurrentemente atentan contra una buena especificación 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 aplicación de un patrón. Para la definición de un catálogo de anti-patrones, es necesario revisar tanto las buenas prácticas como las malas prácticas que han sido estudiadas previamente por otros autores. En este frente nos encontramos con diversos trabajos: En [11] se hace un detallado análisis 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 prácticas en la especificación de requisitos usando casos de uso. En [16] se hace un análisis de un asunto puntual pero muy recurrente en el análisis de requisitos: “¿Por qué los casos de uso nos son funciones?”. El estudio de los referentes anteriores, y la experiencia derivada de la participación en proyectos de software por parte de los autores, sirven de fundamentación para el planteamiento de los anti-patrones propuestos en este catálogo, cuyos nombres se ilustran en la Tabla 1, clasificados en cuatro categorías, de acuerdo con el frente en particular donde se suelen presentar:
Tabla 1. Catálogo de Antipatrones en Casos de Uso [2]
Categoría 1: en los conjunto de casos de uso PuntoDeEntrada (EntryPoint) ModeladoDesordenado (MessyModeling) Categoría 2: en los casos de uso NombreConfuso (ConfusingName) AlcanceMezclado (MixedUpScope) GranularidadFueraDeLugar (MisplacedGranularity) CasoDeUsoImperativo (ImperativeUseCase) Categoría 3: en los escenarios y pasos TiposDeFlujoIndeterminados (IndeterminateFlowTypes) EstiloDeEscrituraIndefinido (UndefinedWritingStyle) DesempoderamientoFuncional (FunctionalDisempowerment) Categoría 4: en las relaciones RelacionesEnmarañadas (TangledRelationships) RelacionesRedundantes (RedundantRelationships) RelacionesIncorrectas (WrongRelationships)

denominación que le dan a la ilustración de este problema en [2]. Factores que motivan su uso: La necesidad de modelar el flujo de la interface de usuario y la navegación, 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 solución: Para resolver este tipo de situaciones, el caso de uso director pasa a ser parte del título del límite del sistema o paquete y el actor se relaciona directamente con los demás casos de uso, esto evita el modelado de la navegación 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-patrón y la forma en que se resuelve.

Fig. 1: PuntoDeEntrada y su solución

5.1 Categoría 1: En los conjuntos de casos de uso Esta categoría 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. Descripción: Se presenta cuando el actor principal se relaciona con solo un caso de uso, el cual tiene relaciones de dependencia con los demás 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. Descripción: Se presenta cuando los diagramas quedan desordenados, bien porque tienen muchos casos de uso o porque no se pone el límite del sistema o módulo; esto dificulta su comprensión, realización e implementación. Factores que motivan su uso: La necesidad de representar lo que requiere el usuario por más extenso o confuso que resulte, sin hacer un ejercicio de modularización que conduzca a una vista conceptual de la arquitectura con los paquetes relativos al usuario. Ejemplo y/o posible solución: Para resolver la situación de la falta de límite y el desorden, a nivel del equipo de trabajo, se pueden hacer acuerdos en cuanto al modelado para usar el límite del sistema o paquete y un número de casos de uso por diagrama. La Figura 2 ilustra un diagrama en el que se presenta este caso en el anti-patrón y la forma en que se resuelve.

Fig. 2: Caso 1 de ModeladoDesordenado y su solución

Para resolver la situación de muchos casos de uso en el mismo diagrama, a nivel de arquitectura, se puede hacer una modularización en paquetes y hacer un diagrama de

56

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

casos de uso. El modelo y la especificación textual se vuelven confusos, ya que el conjunto de interacciones del cliente de negocio es diferente al de los actores del sistema informático [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 solución: 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-patrón y la forma en que se resuelve.

Fig. 3: Caso 2 de ModeladoDesordenado y su solución

5.2 Categoría 2: En los casos de uso Esta categoría 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 gestión del equipo de trabajo. Descripción: 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 denominación, ó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 acción. 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 solución: Ejemplo de esta situación podría ser un caso de uso llamado “Matrícula Estudiante” en una institución educativa que permite a los estudiantes realizar la matrícula en línea por Internet; primero su nombre se orienta más al sistema que al actor, segundo no está en voz activa y por ende no indica una acción en sí; en este caso lo correcto sería por ejemplo un caso de uso llamado “Realizar Matrícula”. Alcance Mezclado Nombre: AlcanceMezclado (MixedUpScope) Nombre alterno: NegocioOSistemaDeInformacion (BusinessOrComputerSystem) Causas: Desorganización y falta de niveles de abstracción en el modelado. Descripción: Se presenta cuando los modeladores tratan de mostrar tanto a los actores de la empresa como a los usuarios del sistema informático en el mismo modelo de

Fig. 4: AlcanceMezclado y su solución

Granularidad Fuera de Lugar Nombre: GranularidadFueraDeLugar (MisplacedGranularity) Nombre alterno: ObjetivoDeNegocioOAcciónIncidental (BusinessGoalOrIncidentalAction) Causas: Descuido y falta de niveles de abstracción en el modelado. Descripción: Se presenta cuando los casos de uso constituyen procesos muy generales con granularidad muy gruesa, en este caso corresponden más a objetivos en el modelado de negocio, que a requisitos en el análisis. También se presenta cuando los casos de uso constituyen operaciones muy puntuales con granularidad muy fina, en este caso corresponden más a acciones incidentales en el diseño del sistema, que a requisitos en el análisis. El término “acciones incidentales” proviene de la denominación que le dan a la ilustración de este problema en [11]. Factores que motivan su uso: La necesidad de que los casos de uso documenten completamente la empresa o cómo se implementarán funcionalidades muy puntuales, sin diferenciar lo que quieren los actores del sistema de información. Ejemplo y/o posible solución: Los casos de uso en el análisis 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 situación en una institución educativa podría ser, “Mejorar la Calidad de la Educación” como objetivo de negocio, “Seleccionar Curso” como acción 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: CasosDeUsoEnDiseño (UseCaseInDesign) Causas: Desconocimiento y modelado desde la perspectiva del desarrollo. Descripción: Se presenta cuando los casos de uso se centran más en el “Cómo” que en el “Qué”. Los casos de uso hacen parte fundamental del análisis de requisitos, por tanto son por naturaleza declarativos (se enfoca mayoritariamente en el “Qué” o el espacio del problema), mientras que el diseño es imperativo (se enfoca mayoritariamente en el “Cómo” o el espacio de la solución), por tanto los modelos de casos de uso no deben invadir el diseño. Factores que motivan su uso: La necesidad de que los casos de uso documenten y representen bien cómo se implementarán, en lugar de representar lo que requiere el usuario. Ejemplo y/o posible solución: 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 más en el diseño que en el análisis, por tanto más que hacer un caso de uso por cada operación, se debería hacer un caso de uso que agrupe este conjunto de operaciones, generalmente denominado “Gestionar [Nombre de la Entidad Implicada]”. Dicha regla podría tener una excepción, cuando la labor de creación de una instancia de la entidad implicada es muy compleja, justificando la definición 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, podría ser “Gestionar Estudiante” en una institución educativa, el cual podría enmascarar el proceso de “Matricular Estudiante”. 5.3 Categoría 3: En los escenarios y pasos Esta categoría se centra en los anti-patrones que se presentan en la especificación 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 gestión del proyecto o del equipo de trabajo. Descripción: Cuando se especifican los casos de uso, se hace especial énfasis en la documentación del flujo de eventos principales, los cuales definen la colección de escenarios que suceden regularmente (o como es llamado en ocasiones: “Happy Path”); mientras que en algunos casos los demás 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 compensación, o sea devolver el sistema al estado en el que estaba antes de la ejecución del caso de uso, mientras que los flujos alternativos no sugieren esta labor. Al no hacer un análisis separado de estas situaciones, se dificulta la realización de pruebas apropiadas para cada situación, 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 capacitación del personal, la definición de acuerdos y las pruebas sean labores que pueden retrasar la agenda de los proyectos. Ejemplo y/o posible solución: Para resolver este tipo de situaciones, se deben definir acuerdos tendientes a diferenciar estos tipos de flujos en la especificación 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 gestión del equipo de trabajo. Descripción: Existen varias características que pueden afectar la redacción de los flujos de trabajo, entre ellos se destacan: (a) escenarios muy largos o con redacción 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 tecnológica, en la descripción 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 más en el espacio de la solución que del problema. Ejemplo y/o posible solución: 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 términos del domino y definir una granularidad apropiada y un estilo determinado.

58

Desempoderamiento Funcional Nombre: DesempoderamientoFuncional (FunctionalDisempowerment) Nombre alterno: EmpoderamientoPerdido (LostEntitlements) Causas: Desorganización y falta de acuerdos para el modelado. Descripción: Se presenta cuando un caso de uso que involucra dos o más 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 común que estos realizan, aunque ello conlleve a artificiosas especificaciones de los casos de uso. Ejemplo y/o posible solución: 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 situación en una institución educativa podría 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 acción 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 situación se debe dividir en dos casos de uso, inclusive buscando un nombre más 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 acción sobre la oferta de cursos al Directivo. La Figura 5 ilustra un diagrama en el que se presenta este anti-patrón 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 comprensión del diagrama. Ejemplo y/o posible solución: Para resolver este tipo de situaciones, se debe buscar un super-tipo en los actores para construir una jerarquía 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: RelacionesEnmarañadas y su solución

Relaciones Redundantes Nombre: RelacionesRedundantes (RedundantRelationships) Nombre alterno: RelacionesSobrantes (WastedRelationships) Causas: Desconocimiento y falta de acuerdos para el modelado. Descripción: Se presenta cuando un caso de uso tiene relaciones de dependencia con otro, y al actor involucrado se le pone asociación con ambos casos de uso. En estas situaciones solo es necesario que los actores estén 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 solución: Para resolver este tipo de situaciones, se deben eliminar la relación redundante. La Figura 7 ilustra un diagrama en el que se presenta este anti-patrón y la forma en que se resuelve.

Fig. 5: DesempoderamientoFuncional y su solución

5.4 Categoría 4: En las relaciones Esta categoría se centra en los anti-patrones que se presentan en la especificación de relaciones entre los casos de uso, o entre estos y los actores. Relaciones Enmarañadas Nombre: RelacionesEnmarañadas (TangledRelationships) Nombre alterno: RelacionesDeTelaraña (SpiderwebRelationships) Causas: Descuido, desconocimiento y falta de acuerdos para el modelado. Descripción: 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 comprensión del modelo.
Fig. 7: RelacionesRedundantes y su solución

Relaciones Incorrectas Nombre: RelacionesIncorrectas (WrongRelationships) Nombre alterno: RelacionesErradas (MisusedRelationships) Causas: Descuido, desconocimiento y falta de acuerdos para el modelado. Descripción: Se presenta cuando la dirección o la semántica de las relaciones de inclusión o extensión son mal utilizadas, al igual que la generalización entre casos.

59

Factores que motivan su uso: La necesidad de dejar clara la relación entre todos los casos de uso implicados, sin considerar la semántica de las relaciones. Ejemplo y/o posible solución: Para resolver esta situación, se debe revisar la semántica y la dirección de las relaciones de dependencia y generalización, esto evita modelar la navegación 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 situación en una institución 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 atención en la especificación de requisitos usando casos de uso. En otros casos, los conocimientos del equipo de trabajo en áreas como el desarrollo, los lenguajes de programación y la tecnología; en lugar de favorecer un buen modelo de casos de uso, juega en contra de éste al terminar incluyendo detalles propios del diseño o la implementación. Las malas prácticas 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 consultoría como de desarrollo. En dichos proyectos se inició la construcción del material que sirvió de base para la definición de este catálogo de antipatrones al especificar requisitos funcionales usando casos de uso. Varias de las empresas para las que se realizaron estos proyectos, han realizado retroalimentación con respecto a lo útil que les resulta el material en el hallazgo de malas prácticas en requisitos, este es uno de los factores que nos hace pensar que el artículo 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 prácticas en especificación de requisitos con casos de uso, formalizar estas experiencias para escribir este catálogo 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 solución que sean entendibles y fáciles de aplicar. Los trabajos futuros alrededor de este catálogo 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 dirección 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 dirección queda de la siguiente forma:
 En el caso de la inclusión (include):

El caso de uso base incluye el caso de uso incluido. La dirección va desde base hacia el incluido.  En el caso de la extensión (extend):  El caso de uso extensor extiende el caso de uso base.  La dirección va desde el extensor hacia base.
 

En cuanto a la semántica de las relaciones entre casos de uso, la diferenciación de las relaciones entre casos de uso está determinada por la comparación de sus objetivos, a continuación se describen las principales condiciones que estas deben cumplir:  En el caso de la inclusión (include):  Objetivo incluido es obligatorio  Objetivo base = Objetivo incluido + ∆  Objetivo base ≠ Objetivo incluido → ∆ es grande  En el caso de la extensión (extend):  Objetivo extensor es opcional  Objetivo extensor = Objetivo base + ∆  Objetivo base ≈ Objetivo extensor → ∆ es pequeño  En el caso de la herencia o generalización:  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 también redefinir o enriquecer con nuevos escenarios, operaciones ya existentes en el caso de uso padre [17]. 6. CONCLUSIONES Y TRABAJO FUTURO Un buen análisis de requisitos y particularmente un buen modelo de casos de uso, resulta fundamental para

Complementar los antipatrones del catálogo para presentar otras malas prácticas experimentadas o propias de un dominio específico. Encontrar y formalizar relaciones de causalidad entre los antipatrones en el análisis de requisitos con otras malas prácticas o antipatrones en diferentes disciplinas del proceso como el modelado de negocio, el análisis y diseño, o las pruebas. Integrar el catálogo de antipatrones en herramientas y nuevos enfoques de construcción de sistemas de información como el desarrollo de software dirigido por modelos [14], buscando por ejemplo que los antipatrones sean detectados automáticamente en un modelo de casos de uso, y se le den recomendaciones al modelador para que corrija la situación 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 introducción al análisis y diseño 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 Introducción. 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] Völter, M. & Stahl, T. 2006. Model-Driven Software Development. Technology, Engineering, Management. Wiley Software Patterns Series. [15] Pow-Sang, J. A. 2003. La Especificación de Requisitos con Casos de Uso: Buenas y Malas Prácticas. 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 Informáticas. La Habana, Cuba. hmenendez@uci.cu Universidad de las Ciencias Informáticas. La Habana, Cuba. ymillet@uci.cu 3 Universidad de las Ciencias Informáticas. La Habana, Cuba. arbatista@uci.cu
1 2

Heydi Menéndez A.1, Yanetsi Millet L.2, Aniubis Rodríguez B.3

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo 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 Gestión de Riesgos es un proceso complejo que conduce al planeamiento y aplicación de políticas, estrategias, instrumentos y medidas orientadas a impedir, reducir, prever y controlar los efectos adversos de fenómenos peligrosos sobre el proyecto; por lo que se llevan acciones integradas de reducción de riesgos a través de actividades de prevención, mitigación, preparación y atención de emergencias. Este proceso ha adquirido gran importancia en los últimos años, 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 técnicas de pruebas basadas en riesgos, haciendo un análisis de estas para proporcionar una guía que homogenice su aplicación en los proyectos productivos de la universidad y que permitan establecer mecanismos de detección oportuna de riesgos que amenacen la calidad del producto final.

1. INTRODUCCIÓN Con frecuencia los proyectos productivos de la Universidad de las Ciencias Informáticas (UCI) sufren afectaciones en su cronograma, en la calidad del producto, en el presupuesto y en la formación de los estudiantes. Una variable significativa en la Gestión de Proyectos es la Gestión de Riesgos y se considera que el nivel de calidad de todo proyecto depende de la minimización del número de riesgos al que se enfrenta el mismo. Actualmente, en el diseño de las pruebas únicamente se tiene en cuenta los requisitos funcionales y los casos de uso derivados de estos. La gestión de riesgos no pasa de ser una simple tarea que se resuelve sin que sus resultados repercutan positiva o negativamente en el desempeño del software construido. Esto trae como efecto la detección de errores en etapas tardías como son las pruebas de liberación y aceptación, donde elementos de peso aparentemente insignificante se muestran tomando gran importancia, pudiéndose haber evitado con un buena captura de los riesgos a la calidad del sistema, y posteriormente con un buen análisis y tratamiento de los mismos. Dichos riesgos que afectan a la calidad se presentan a diario en todas las pruebas de liberación 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 técnicas de análisis de riesgos para efectuar pruebas al software, así como enunciar mediante un ejemplo la técnica propuesta para los proyectos de la UCI que servirá de base para la construcción de un sistema que permita automatizar de algún modo el proceso de análisis 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 específicos a la calidad del sistema.  Evaluar y asignar el nivel de riesgo a cada riesgo, basándose en la probabilidad de ocurrencia (a consideración técnica) y el impacto (consideraciones del negocio).  Asignar el esfuerzo de prueba y priorizar la ejecución de las pruebas basadas en riesgo [7].  Revisar el análisis de riesgo a intervalos regulares en el proyecto incluyendo el después de las pruebas de la primera construcción. 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 podría hacer que el sistema fallara en encontrar las expectativas razonables de

62

calidad. Los riesgos se agrupan u organizan por categorías como son: funcionalidad, performance, seguridad, etc. Los riesgos están 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 número de participantes, esfuerzo, presupuesto y duración. Las probabilidades de fracaso de un proyecto de software están en los límites del 2% al 85%. Las malas pruebas son consideradas como una de las cuatro causas fundamentales del fracaso junto con la estimación pobre, la mala planificación y el mal seguimiento del proyecto (tracking). La gestión de riesgos clásica dice de mitigar estos utilizando ambos métodos, proactivo (entrenamiento cruzado del personal) y reactivo (codificación de componentes redundantes) (reutilización) [12]. Los riesgos a la calidad del sistema pueden ser mitigados empleando como método proactivo las revisiones y como reactivo las pruebas. El análisis de riesgos de la calidad es un proceso para la identificación, el análisis, la categorización 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 Técnicas para analizar el riesgo Informal quality risk analysis Proporcionar un modo fácil para comenzar el análisis de riesgos de la calidad. Uno probablemente omite algunas áreas importantes de riesgo, sobre todo durante tempranos análisis de riesgos, pero esta técnica 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 análisis [3]. ISO 9126 quality risk analysis Para la presente técnica de análisis de riesgo se deben usar las características y sub-características descritas en la ISO 9126 como sistema estándar de categorías para el análisis de riesgos. Las principales son [10]:       Funcionalidad Fiabilidad Usabilidad Eficacia Mantenibilidad Portabilidad

asociadas a varios riesgos? y ¿cuánto se debe gastar en reducir esos riesgos? Una pérdida esperada es el producto de la probabilidad de la pérdida multiplicada por el costo de la misma [4]:
Pérdida esperada = Probabilidad de la pérdida * Costo de la pérdida

Dicha técnica permite al equipo de gestión del proyecto tomar una decisión económica sobre las pruebas. Para que la misma funcione bien, el equipo de análisis debe ser capaz de estimar con exactitud las probabilidades y los gastos de varias pérdidas. Failure mode and effect analysis El método de análisis de modo de fallos y efecto va más allá de la discusión sobre riesgos [5]. Empleando esta técnica el equipo de análisis de riesgo trata de identificar los aspectos en los que el sistema podría fallar, y todos los posibles efectos que estas fallas puedan traer, en los clientes, en el negocio y en la sociedad. Es una técnica bien detallada, puede producir una prueba finamente cargada, pero también una tonelada de papeleo y trabajo administrativo y mucho tiempo invertido en las mismas. Hazard analysis Esta técnica comparte ciertos criterios con la técnica de modo de falla y análisis de efecto, pero se realiza a la inversa. Comienza por el análisis de los efectos para de esta forma identificar las causas de los mismos. Durante el trabajo se van haciendo más claras las probabilidades de esas causas. En algunos casos, aunque existen muchas causas de diferentes tipos de malos comportamientos, esta técnica tiende a funcionar mejor en sistemas pequeños (ver Tabla 1).
Tabla 1. Comparación de las técnicas de análisis de riesgo
Técnica En resumen Informal Basada en historial, experiencias y listas de chequeo. Fácil, de peso ligero, flexible. Dependiente del personal participante, abierta, imprecisa. De riesgo ágiles. bajo o ISO 9126 Siguiendo las características de calidad según el estándar industrial. Predefinida, exhaustiva, común. Potencialmente sobre estimada, sobre regimentada. Comprometido con los estándares. Muy inusuales o de estructura intolerante. Costo de exposición Estimación del costo de prueba contra el costo de no probar.

Fortalezas

Balanceada, singular, tradicional. Intensivo información, exclusivamente monetaria. Financiero. de

Debilidades

En cada categoría existe una o más sub-características de la ISO 9126, esto provee un acercamiento más estructurado y reduce la probabilidad de omitir algunos elementos de riesgo que son importantes [11]. Cost of exposure quality risk analysis La técnica de costo de exposición se enfoca en la siguiente pregunta: ¿Cuáles son las pérdidas esperadas,

Adecuada para proyectos Evitar en proyectos

Críticos o regulados en cuanto a seguridad.

De seguridad crítica.

Técnica En resumen

Modo de fallas/análisis de efectos Identifica los errores

Análisis de amenazas Analiza causas de

63

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

amenazas (fuentes riesgo). Exacta, sistemática. Fácilmente abrumarse complejidad.

de

prudente, puede por su

Prolongada, pesada documentación, difícil de aprender. De alto riesgo conservativos. o

 Analizar y perfeccionar el listado de riesgos de calidad.  Alineación de las pruebas con los riesgos de calidad.  Ejecución de las pruebas basadas en riesgos.  Evaluación del grado de beneficios y lecciones obtenidas. 2.6 Ejemplo práctico 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 capacitación:  Principios básicos de las pruebas y el por qué basarlas en riesgos.  Comprensión de las categorías de riesgos de calidad (funcionalidad, rendimiento, fiabilidad, usabilidad, etc.).  ¿Cómo realizar un análisis de riesgos de calidad y alinear las pruebas con niveles de riesgo?  ¿Cómo documentar los riesgos a la calidad?  ¿Cómo monitorear los riesgos de calidad durante la ejecución de la prueba e informar resultados de las pruebas basadas en riesgos? Sesión de análisis de riesgos a la calidad La sesión de análisis de riesgos a la calidad consta de dos sub-sesiones. En la primera se identificaron la mayor cantidad de riesgos posibles usando la técnica de tormenta de ideas. En la segunda se definieron varios equipos para determinar la probabilidad de ocurrencia de los riesgos y el impacto que podrían 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

Médico o embebido.

Caóticos, rápidamente Impredecibles o cambiantes o ligados a complejos. prototipos. Tomado de Quality Risk Analysis

2.4 Proceso de análisis de riesgos a la calidad Sin importar la técnica escogida, el camino a seguir para el proceso de análisis debe ser el siguiente:  Identificar el equipo de analistas de riesgos a la calidad [11].  Seleccionar una técnica.  Identificar los riesgos, priorizarlos, seleccionar acciones de mitigación idóneas (Brainstorm) [11].  Si el equipo detecta problemas en los requerimientos o en otro artefacto, deben reportarse inmediatamente para su resolución.  Revisar, repasar y finalizar el documento de análisis de riesgos a la calidad.  Comprobar el documento de análisis 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 información del proyecto, se debe repasar y actualizar el análisis 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 ejecución rápida y eficiente de las pruebas [9].  La formación de los principales involucrados en las pruebas basadas en riesgos.  Realización de una sesión de análisis de riesgos de calidad.

Muy probable: muy cercano a pasar. Probable: Más 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 Corrección inmediata Corrección programada Debe corregirse Sería bueno corregirlo No corregir Valor 1 2 3 4 5

64

Corrección inmediata: Prioridad uno. Corrección programada: Programación en cronograma para su corrección lo antes posible. Debe corregirse: No debe recibir atención mientras las otras dos categorías superiores no se hayan cubierto totalmente. Sería bueno corregirlo: Algo que el cliente tomaría positivamente si se arreglara pero no atenta contra el funcionamiento. No corregir: Ningún esfuerzo para solucionar este problema.
Tabla 4. Listado de riesgos resultado de la sesión
Riesgo Existen comandos de la librería de datos que no funcionan 3 2 6 Incompatibilid ad con la versión 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 números de riesgos a sus especificaciones.  Asociar números 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 número de prioridad podemos añadir 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

Análisis y refinamiento del listado de riesgos A partir de la probabilidad y el impacto asignados a cada riesgo se determina un número 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 análisis un gráfico con las prioridades de los mismos basándose en la cantidad de riesgos que presentan igual número 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 visión más objetiva cada impacto y probabilidad asignado a los riesgos de manera que esto permita asignarles un número de prioridad más ajustado (Figura 2 y Tabla 5).

Extenso: Ejecutar un número grande de pruebas de forma general y profunda, ejercitando combinaciones y variaciones de condiciones diferentes para las pruebas. General: Ejecutar un número mediano de pruebas que ejerciten muchas condiciones diferentes de la prueba. Superficial: Ejecutar pocas pruebas que ejemplifiquen las condiciones más probables del sistema. Oportuno: Favorecer otras actividades o realizar una prueba o dos de una condición interesante, pero sólo si se trata de una inversión muy pequeña de tiempo y esfuerzo, y sólo 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 especificación de requerimientos asociado al mismo. Preparación de las pruebas Pasando a la actividad central del tema, será mucho más fácil comenzar a probar aquellos requerimientos del software que más atención requieren luego de los análisis realizados con anterioridad. Evaluación del grado de beneficio y lecciones obtenidas Luego de una reunión con los stakeholders se llegó a la conclusión 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. Además de haber aprendido otras lecciones importantes sobre probar guiado por los riesgos y sobre el análisis de riesgos, de las cuales la más importante fue involucrar los usuarios del negocio lo cual le da una

Alineación de los riesgos a la calidad a las pruebas Una vez completado el análisis se procede a alinear las pruebas a los niveles de riesgo. Para esta acción se deben tener en cuenta los siguientes puntos:

65

visión más cercana a los problemas que puede dar un sistema desde el punto de vista práctico y no técnico como podría verlo en este caso el programador. 2.7 Valoración económica y aporte social En la universidad no se ha presentado este procedimiento con anterioridad donde además de abordar las técnicas de análisis de riesgos ya diseñadas por empresas internacionales, se pretende proponer un modelo para las pruebas de los proyectos de la universidad evitando así la detección de errores en etapas tardías y elevando así la eficiencia, productividad y sobre todo la calidad de los productos desarrollados en la universidad. La construcción del procedimiento para pruebas basadas en riesgo para la UCI incluye un análisis más pro-fundo de las tendencias actuales en la producción de software en los diferentes centros y una construcción a partir de dichos elementos de un sistema que permita en un principio registrar los riesgos más probables a ocurrir en las aplicaciones con las características de las que se producen y de esta forma asociar cada riesgo posible a los requerimientos reales de cada producto para luego pasar al análisis detallado de los riesgos y la priorización de los mismos para las pruebas futuras. El sistema propuesto permitiría a partir de la entrada de los niveles de probabilidad y de impacto por el usuario quien se encargaría de cotejar cada riesgo con su especificación correspondiente, determinar el alcance de la prueba empleando para la toma de decisiones una base de casos ya resueltos con anterioridad. Dicho alcance estaría asociado al esfuerzo asignado a la misma (Probadores, Tiempo, Recursos). 3. CONCLUSIONES En el trabajo se enunciaron las técnicas definidas en el mundo actual para el análisis de riesgos a la calidad de los sistemas. Además se propone mediante un ejemplo la técnica más 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 producción.

Además, se propone la continuidad de la investigación con el desarrollo de un sistema que permita automatizar el análisis anterior a las pruebas de software basadas en riesgos. 4. RECOMENDACIONES  Completar progresivamente el análisis de los beneficios que reporta la incorporación de las técnicas de análisis de riesgos para la organización en general y sus servicios.  Implementar una herramienta que gestione la información de los artefactos propuestos y que permita brindar los reportes de manera automatizada.  Investigar y profundizar sobre los temas de análisis de riesgos del proyecto y su influencia en el análisis 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 salvación, un proceso sin utilidad, trivial, simplemente una moda? XXVII Salón de la Informática 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 ejecución 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 INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Calidad, función, 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 función, que tienen como objetivo comprobar que el software cumpla con los requisitos establecidos; tarea que va cobrando cada día mayor importancia. El Departamento de Pruebas de Software (DPSW), perteneciente a CALISOFT (Centro Nacional de Calidad de Software) adscrito al Ministerio de la Informática y las Comunicaciones de Cuba, define una estrategia para desarrollar las pruebas de función garantizando así que la aplicación informática que se pruebe cumpla con la característica 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 técnicas y herramientas a ser usadas.

Keywords Quality, functionality, testing, strategy.

1. INTRODUCCIÓN La calidad del software se define como la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas 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 Ingeniería de Software. Una estrategia de prueba proporciona una guía para el responsable del desarrollo del software y para la organización de control de calidad debido a que debe describir los pasos a desarrollar. Por tanto, cualquier estrategia de prueba debe incorporar la planificación y el diseño y ejecución de casos de prueba. La prueba de función está centrada en validar los requisitos establecidos basándose directamente en los casos de uso, requisitos o historias de usuarios. En esta investigación se presenta las pruebas de función empleando caja negra, es decir, verificar la aplicación — y sus procesos internos— mediante la interacción con la interfaz del sistema y analizar la salida —resultados—. Para la ejecución de pruebas de función se ejecuta cada caso de uso, flujo de caso de uso o función, usando datos válidos e inválidos, para verificar: (1) que los resultados

esperados ocurran cuando se usen datos válidos y (2) que sean desplegados los mensajes apropiados de error y precaución cuando se usan datos inválidos. Las pruebas de función que se realizan en el DPSW se ejecutan con el objetivo de comprobar si el producto que se prueba cumple con la característica de funcionalidad descrita en la norma NC-ISO-IEC 9126-1. Esta norma es un estándar internacional para la evaluación del software y está dividida en cuatro partes: modelo de calidad, métricas externas, métricas internas y calidad en las métricas de uso. El modelo de calidad establecido en la primera parte del estándar clasifica la calidad del software en un conjunto estructurado de características: 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 implícitas cuando el software se usa bajo las condiciones especificadas [2]. 2. ESTRATEGIA DE PRUEBAS El DPSW ha definido dentro de la característica de funcionalidad tres tipos de prueba a realizar: de función, 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 gestión, portales, etc. A continuación se describen los objetivos de la estrategia:

67

 Definir los niveles de prueba que se ejecutarán en cada proceso de prueba del DPSW y las herramientas a ser utilizadas.  Planificar las pruebas necesarias incluyendo las pruebas de unidad, de integración y de sistema.  Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar y cómo 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: planificación, diseño y ejecución de pruebas. Planificación de las pruebas. En esta etapa se determinan las personas involucradas en el proceso y todos los recursos que intervienen, teniendo en cuenta el propósito principal de la prueba; además, 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 ejecución 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 propósito de la prueba de función.  Identificar los requerimientos que se van aprobar.  Planificar el orden para realizar las pruebas. Diseño de las pruebas. En esta etapa se diseñan las pruebas que guiarán el proceso planificado, a partir de la revisión a la documentación y al diseño de los casos de pruebas documentando, la secuencia de pasos para ejecutar cada caso de prueba y los resultados esperados.  Diseñar los casos de pruebas.  Configurar el ambiente de prueba.  Seleccionar la herramienta a utilizar. Ejecución de las pruebas. Etapa en la que se ejecutan las pruebas diseñadas con el fin de probar los requerimientos y determinar si se cumplen. En esta etapa se realizan las siguientes actividades:  Ejecutar las pruebas diseñadas.  Analizar y registrar las No Conformidades encontradas.  Evaluar el proceso de pruebas y sus resultados. 2.2 Niveles de pruebas de función definidos Los niveles de prueba definen los escenarios o niveles de trabajo, en los que es posible realizar el tipo de prueba de función en cuanto al nivel de trabajo en el que se realiza; se ejecuta la prueba independiente, es decir, aquella que es diseñada 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 liberación como pruebas independientes. Además, se realizan las

pruebas de aceptación 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 módulos independientes del sistema; luego se realizan las pruebas de integración para asegurar que esos módulos se integren correctamente cuando se combinen para ejecutar un caso de uso. A continuación se realiza una propuesta de cómo realizar las pruebas en el nivel de integración. Pruebas de Integración Las pruebas de integración tienen como objetivo detectar las fallas de interacción entre las diferentes clases que componen el sistema y verificar el correcto funcionamiento de dos o más módulos. La necesidad de realizarlas se debe al hecho de que los módulos 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 módulos críticos. De acuerdo con Pressman [3], los principales problemas cuando se realizan las pruebas de integración son: los datos se pueden perder en una interfaz; un módulo puede tener un efecto adverso e inadvertido sobre otro; cuando se combinan las sub-funciones pueden no producir la función principal deseada; la imprecisión aceptada individualmente puede crecer hasta niveles inaceptables y las estructuras de datos globales pueden presentar problemas. Para la realización de estas pruebas se cuenta con dos estrategias de integración incremental diferentes: la ascendente y la descendente. La selección de una de ellas depende de las características del software y de la planificación 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 módulos moviéndose hacia abajo por la jerarquía de control y comenzando por el módulo principal; los módulos 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 más común se da cuando se requiere un proceso de los niveles más bajos de la jerarquía para probar adecuadamente los niveles superiores. Al principio de esta prueba, los módulos de bajo nivel se reemplazan por resguardos, por lo que no pueden fluir datos significativos hacia arriba por la estructura del sistema. Este método 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 número de módulos ficticios subordinados, resulta difícil introducir los casos de pruebas si no se han incorporados los módulos de entrada y salida o los

68

juegos de datos de prueba pueden resultar difíciles o imposibles de generar e induce a diferir la terminación de la prueba en ciertos casos. La integración ascendente empieza por construir y probar los módulos de los niveles más bajos de la estructura del sistema. Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos 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 más fáciles de crear, porque los módulos inferiores suelen tener funciones más específicas, es más fácil la observación de los resultados de las pruebas, debido a que se elaboran en los módulos inferiores, además, se pueden resolver primero los errores de los módulos inferiores que son los que tienen el procesamiento más complejo, para luego nutrir de datos al resto del sistema. Entre sus principales desventajas se tiene que se requieren módulos impulsores, que se deben desarrollar especialmente y que el sistema como entidad no existe hasta que se agregue el último módulo. Después de conocer las estrategias de integración y las ventajas y desventajas brindadas por ambas, se determinó poner en práctica la integración ascendente. En la Tabla 1 se muestra el diseño de casos de prueba para la integración ascendente de cada uno de los módulos del sistema bajo prueba.
Tabla 1. Diseño de casos de prueba de integración
Nombre del Módulo
Funcionalidad Condiciones de Ejecución Escenario de interacción Resultado Previsto Resultado Real

 Basado en la técnica 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 descripción 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 diseños son los requisitos del software, los casos de uso o las historias de usuario y dependen de la metodología que se use para el desarrollo del software. Un buen diseño de un caso de prueba de caja negra depende de la información que brinde el caso de uso o requisito. En el caso de los equipos que por la metodología de desarrollo o por otras razones diseñen los casos de prueba basados en requisitos, se debe garantizar que sus especificaciones estén lo más completas posibles, porque para los casos de pruebas es necesario identificar todos los escenarios posibles que se presentan en una descripción de casos de uso pero, generalmente, estos aspectos no se llegan a identificar en los requisitos. La parte más 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 básico y los flujos alternativos. Un escenario de un caso de uso es un camino completo a través del mismo. Los usuarios finales pueden seguir muchos caminos cuando ejecutan la funcionalidad especificada en el caso de uso. A continuación 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 ejecución para cada escenario.  Identificar los valores de los datos con los cuales se hará la prueba para cada caso de prueba. Además de plasmar en el caso de prueba los escenarios presentes en la descripción de requisitos o casos de uso, se deben tener presente otras consideraciones de escenarios que quizás falten en la descripción, que el diseñador de casos de prueba debe incluir en sus diseños:  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 más, 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 módulo que dependen de los servicios que ofrece otro.  Condiciones de ejecución: deben estar creadas en el sistema antes de ejecutar la funcionalidad.  Escenarios de interacción: se identifican los posibles escenarios de interacción 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 realización de pruebas de función se propone la utilización de dos herramientas, los diseños de casos de prueba como herramienta manual y apoyo a la ejecución de las pruebas y como herramienta automatizada el Selenium IDE para agilizar la ejecución según las características del sistema bajo prueba. Diseño de Casos de prueba de función Una herramienta necesaria para la ejecución de las pruebas de función son los casos de prueba, los cuales especifican las entradas con datos de prueba, las condiciones de ejecución y los resultados esperados. El DPSW define un diseño de casos de prueba con las siguientes características:

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 años. En la Tabla 2 se muestra un diseño de caso de prueba para una determinada sección de un caso de uso, donde las variables son los datos de entrada al sistema que toman valores válidos (V), Inválidos (I) o No Aplica (NA), dependiendo del escenario, con sus respectivos valores reales.
Tabla 2. Diseño de Casos de Prueba de función
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 aplicación a la cual se le van a realizar las pruebas y abrir el IDE.  Habilitar el botón 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 acción.  Desactivar el botón grabar del IDE. La utilización del Selenium no debe sustituir el diseño de casos de prueba para realizar las pruebas de función manualmente y su puesta en práctica depende de la experiencia de los probadores y las condiciones en la que se ejecuta la prueba, además de las características 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 básicamente permite resolver un problema mediante el empleo de problemas resueltos similares al planteado. El RBC es una manera de razonar haciendo analogías, no sólo es un método 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 producción 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 también es aplicable en la calidad de software, para lograr la calidad requerida por los usuarios finales, se pueden realizar varias pruebas, una de las más usadas son las pruebas funcionales o pruebas de función, como se explicó anteriormente. Usar RBC no es más que hacer propuestas para la planificación y reutilización 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 información y solicitar su recuperación son los principales pasos.

Entre los principales errores que se detectan aplicando pruebas de caja negra y el diseño de casos de prueba definido están 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 inicialización y terminación. Utilizando una herramienta para la automatización de este proceso se logra disminuir los costos en recursos y en tiempo destinados a su realización. Selenium IDE para automatizar las pruebas La generación automática 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 función, sobre todo si se trata de probar el funcionamiento de varios formularios varias veces seguidas. Las pruebas que realiza son como las que haría cualquier usuario desde un navegador, con la ventaja de que las hace mucho más rápido 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, además, la extensión tiene un modo de reproducción paso a paso que puede ayudar a determinar la causa de un problema. A continuación se describen algunas de sus características:      Multiplataforma y software libre. Ejecución en varios navegadores. Facilidad de registro y ejecución 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 utilización del RBC para pruebas funcionales se puede realizar con base en las características particulares de cada proyecto. En el DPSW se aplica en las pruebas funcionales. El departamento recibe solicitudes de pruebas de varios centros de producción de software, los cuales tienen en sus proyectos funciones semejantes entre sí y, con base a esa semejanza, se almacena información para luego reutilizar. Se pueden abarcar los siguientes pasos: 1. Definir la característica o sub-característica 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 información necesaria. 4. Verificar si la información recuperada es aplicable y realizar el plan de pruebas funcionales. 5. Trabajar en las pruebas funcionales con base en dicha información. Es importante aclarar que en las pruebas funcionales no es necesario trabajar con toda la información recuperada sino con las más priorizada, es decir, la que más reiteración tenga en la base de casos. Todo esto es necesario para poder aplicar un buen. Un ejemplo concreto para detectar No Conformidades de Validación es la siguiente: Según la Figura 1, existen dos momentos importantes: (a) almacenar información y (b) solicitar recuperación de la información. El primer momento se divide en registro del proyecto y registro de resultados. Registro del Proyecto. Los parámetros a introducir dependen de las características 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.  Características: 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: Validación, Opciones que no funcionan, Excepciones o Funcionalidad. En esta investigación sólo se aborda la opción Validación. Existen dos formas de registrar esta información: 1. Seleccionar de cada Acción de campos que tiene y de cada campo los tipos de campos que existen. 2. Seleccionar de cada Acción los tipos de campos que tiene y por cada campo escoger la cantidad.

Los tipos de campos son:  Campos obligados.  Campos alfanuméricos.  Campos alfabético.  Campos numéricos.  Campos con caracteres especiales.  Campos con números 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 Opción Validación: En este caso específico se verá sólo Validación.  Listar cada campo introducido: este caso sólo es válido si escogió la opción 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 más fácil realizar las comparaciones pertinentes para seleccionar los posibles errores en proyectos con características semejantes. Solicitar Recuperación de la información. 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 más semejanzas presentan, teniendo en cuenta una cantidad mínima de coincidencia.  Devuelve los posibles errores, es decir, registrar el resultado de la prueba. 4. RESULTADOS OBTENIDOS  Con la utilización de los casos de prueba se detectaron más No Conformidades que con la utilización de cualquier otra herramienta. La mayoría son de Funcionalidad, Validación y Excepciones con un promedio de más de 3.000 detectadas en los procesos de prueba, en un periodo de tiempo de dos años.  Esta estrategia permitió una mayor organización para la ejecución de este tipo de pruebas.  Se tiene ya una experiencia de más de cinco años con el uso de los diseños de casos de prueba propuestos, aunque se han ido refinando.  La mayoría de los proyectos en la universidad utilizan los diseños de casos de prueba para sus pruebas funcionales internas.

71

5. CONCLUSIONES  La característica de funcionalidad de la Norma ISO 9126 se puede garantizar mediante la realización de pruebas de función, las cuales tienen como objetivo verificar la correspondencia de los requisitos funcionales con lo implementado.  Es necesario planificar, diseñar e implementar las pruebas de función definiendo la estrategia a seguir. La estrategia propuesta le ha permitido al DPSW una mayor organización para la ejecución de este tipo de pruebas.  La definición de los casos de pruebas de función, junto con la utilización de una herramienta automatizada, permite abarcar todos los escenarios de prueba posibles

 La utilización de RBC permite realizar las pruebas funcionales con base en las realizadas a proyectos similares. 6. REFERENCIAS
[1] Pressman, R. S. 2005. Ingeniería de Software: Un enfoque práctico. Félix 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 Metodología para enseñar a asegurar la calidad del software a través de técnicas de verificación y validación
Gabriela Salazar B.
Escuela de Ciencias de Computación e Informática. Universidad de Costa Rica, San José, Costa Rica. gabriela.salazar@ecci.ucr.ac.cr ABSTRACT INFORMACIÓN DEL ARTÍCULO The main objective of this article is to describe the experience of teaching the Tipo de artículo: Reflexión 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 artículo 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 Verificación, validación, aseguramiento instructors who wish to develop software engineers in the area of software quality. de la calidad del software, revisión técnica formal, pruebas. RESUMEN El objetivo principal de este artículo es describir la experiencia de enseñar a los Categories and Subject Descriptors estudiantes del curso de Ingeniería de Software del Programa de Bachillerato en F.3.1 [Specifying and Verifying and Computación e Informática en la Universidad de Costa Rica, a aplicar pruebas de Reasoning about Programs] verificación y validación del software. El propósito es extender la cultura de aseguramiento de calidad del software, facilitando y estimulando el uso de General Terms metodologías 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. Específicamente se describe el procedimiento en la ejecución de estas pruebas, los Keywords formularios utilizados, las herramientas de software y los participantes del proceso. Verification, validation, software Los puntos descritos en este artículo 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. INTRODUCCIÓN El aseguramiento de la calidad es en la actualidad uno de los tópicos de investigación más importantes dentro del área de ingeniería 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 múltiples metodologías, técnicas y herramientas modernas de ingeniería de software que permiten mejorar la calidad de los productos de software desarrollados. Algunas de ellas son: el Programa de Certificación de Pruebas de Software —CSTE por sus siglas en inglés— [19], los estándares de ingeniería de software del IEEE [10], el Modelo de Capacidad/Madurez —CMM por sus siglas en inglés— [16-20] y el estándar ISO 9001 [11]. Las instituciones y las empresas nacionales que desarrollan o adquieren software requieren un apoyo importante en el proceso de introducir metodologías de aseguramiento de la calidad del software. Estimular a los estudiantes en el uso de metodologías de alcance mundial les facilita su entrada al mercado laboral y se convierte en un apoyo importante para la industria desarrolladora de software del país. En la próxima sección se describe el marco teórico de las metodologías que fueron aplicadas. En la sección tres se describe brevemente el curso de Ingeniería de Software utilizado en esta experiencia. En la sección

cuatro se explica cómo se aplicaron dichas metodologías y finalmente, en la sección cinco, se describen las conclusiones. 2. MARCO TEÓRICO 2.1 Aseguramiento de la Calidad del Software La ingeniería de software es la disciplina que desarrolla y utiliza metodologías, métodos 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 sistemático de actividades que aseguran que el proceso y los productos cumplen con los requerimientos técnicos 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, explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo producto desarrollado profesionalmente [14-19]. De acuerdo con IEEE [7] un componente importante del ACS son las actividades de verificación y validación 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 evaluación

73

objetiva de los productos y del proceso desarrollados durante el ciclo de vida del software. Esta evaluación demuestra que los requerimientos del software y del sistema son correctos, completos, precisos, consistentes y fáciles de probar. Otros objetivos de V&V son:  Facilitar la detección y corrección temprana de errores.  Mejorar la administración 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 estándares, prácticas y convenciones durante el proceso de desarrollo.  Establecen una base para evaluar cada actividad del ciclo de vida para iniciar la siguiente actividad. Una técnica importante de V&V son las revisiones técnicas 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 duración del ciclo de vida, porque lo que se persigue es disminuir los costos de prueba y de integración y un menor número de cambios en las primeras versiones del producto. Además, 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 diseñadas para evaluar la calidad de los productos desarrollados. Por otro lado Myers [14] define las pruebas del software como las actividades de planificar, diseñar, desarrollar, administrar y ejecutar pruebas, incluyendo además a las actividades de Verificación y Validación. A continuación se describen las actividades en un proceso de pruebas. Planificación. Con base en la especificación funcional y la información del proyecto se elabora un plan de pruebas que incluye: objetivos, estrategias, recursos, administración de riesgos y cronograma. Algunos aspectos que se consideran dentro de la estrategia son: fase y tipo de prueba, técnica, herramientas y criterios de completitud. Diseño. Se refina la estrategia de pruebas definida, se definen procedimientos de pruebas y se especifican los casos de prueba y los criterios de aceptación. 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 validación de requerimientos. Ejecución. Se ejecutan las pruebas y se registran los hallazgos; posteriormente se prepara una bitácora de pruebas y un reporte de defectos. Evaluación de resultados. Se revisan los reportes y se genera un resumen de métricas, de cobertura de pruebas y de análisis 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. Refiérase a la Figura 1.
Necesidades operativas
Verificar necesid.operativas

Validar

Pruebas de aceptación

Validar necesid. operativas

Definición de requerimientos

Verificar requerimientos

Validar

Pruebas del sistema

Validar requerimientos

Ejecución Pruebas (Estática)

Diseño del sistema Verificar diseño

Validar

Pruebas de integración

Validar diseño

Validar
Construcción del sistema Verificar construcción Pruebas Unitarias

Ejecución Pruebas (Dinámica)

Validar construcción

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

En la Figura 1 se puede observar también que, desde el inicio del desarrollo, se aplican pruebas estáticas sobre los entregables y, una vez el código se encuentra en un estado ejecutable, se realizan pruebas dinámicas para verificar que los requerimientos especificados se están alcanzando. La secuencia en que ocurren las pruebas está representada por los siguientes tipos: (a) de verificación, (b) unitarias, (c) de integración, (d) del sistema y (e) de aceptación. Pruebas de verificación. Son pruebas estáticas sobre entregables intermedios, que se producen durante el ciclo de vida del proyecto. Aseguran que el sistema cumpla con los estándares y procesos de la organización. Utilizan técnicas como revisiones, caminatas o inspecciones, que no requieren ejecutar el código.

74

Pruebas unitarias. Consisten en probar piezas de software pequeñas y a nivel de secciones, procedimientos, funciones y módulos. Se utilizan para asegurar el correcto funcionamiento de secciones de código, mucho más reducidas que el conjunto y que tienen funciones concretas con cierto grado de independencia. Utilizan técnicas que ejercitan rutas específicas, en una estructura de control de componentes, para asegurar una cobertura completa y la máxima detección de errores. Pruebas de integración. 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 técnicas de diseño de casos de pruebas que se enfocan en entradas y salidas, aunque también se pueden aplicar técnicas que ejerciten rutas de programas específicos para asegurar la cobertura de las principales rutas de control. Pruebas de regresión. Se enfoca en una nueva ejecución de algún 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 especificación documentada de los requerimientos del software proporciona la base para el proceso de validación. Pruebas de aceptación. Estas pruebas las realiza el cliente y básicamente son pruebas funcionales sobre el sistema completo con las que se busca una cobertura a la especificación de requerimientos y al manual del usuario. Estas pruebas no se realizan durante el desarrollo, sino una vez pasadas las pruebas de integración por parte del desarrollador. 3. DESCRIPCIÓN DEL CURSO En el Programa de Bachillerato de Computación e Informática en la Universidad de Costa Rica la Ingeniería de Software se imparte a través de dos cursos y sus respectivos laboratorios. Refiérase 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 duración aproximada de 16 semanas lectivas. Específicamente, son cursos teóricos donde se trabajan metodologías, técnicas y herramientas de Ingeniería de Software. Se imparten en cuatro horas lectivas semanales y con un peso de cuatro créditos cada uno. Por otro lado, en los cursos de laboratorio los estudiantes aplican los conocimientos teóricos; se ofrecen en dos horas lectivas semanales y con un peso de un crédito cada uno. Durante los dos semestres que dura el curso los estudiantes desarrollan una aplicación, comenzando de una pequeña especificación. Al inicio del año reciben una definición básica de los requerimientos, la cual deben completar y mejorar a través de entrevistas y otras técnicas, como construcción de programas usando prototipos. Esto hace que cada proyecto, aunque parta de una misma definición, varíe tanto en el diseño 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 tamaño de las aplicaciones de acuerdo con el equipo que la desarrolla. Las características de los proyectos son muy similares: el mismo problema a resolver, en plataforma operativa Microsoft .NET, lenguaje de programación ASP.NET y C#, sistema administrador de base de datos SQL Server, herramienta de análisis y diseño para el modelado UML Rational Rose o StarUML, herramienta para administrar el proyecto Microsoft Project y para administrar las versiones de software Subversion. Como metodología de desarrollo aplican el Proceso Unificado Racional —RUP por sus siglas en inglés—, combinado con prácticas de metodologías ágiles como Extreme Programming y Scrum. El enfoque de administración iterativa de este último permite organizar el desarrollo del proyecto a través de pequeñas iteraciones y con una duración 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 iteración se siguen prácticas de calidad en cada fase. La aplicación de XP mejora la construcción de los componentes, garantizando el cumplimiento de los requerimientos y la satisfacción del usuario. Cada una de cinco fases genéricas del RUP es guiada por un estándar adaptado a las características del curso, pero siguiendo las prácticas internacionales recomendadas por el IEEE [10] y por PMBOK Guide [18]. En la Tabla 1 se presentan las guías que utilizan los estudiantes para el desarrollo, el estándar internacional que se usó para diseñarlas y la fase en que se aplica. Cada una de las guías cuenta con su propia plantilla en formato electrónico para facilitar el proceso de documentación.

Ingeniería de Laboratorio Software I Ingeniería de Software I

CI-1430

4

CI-1431

1 Sétimo semestre

Ingeniería de Software II

Laboratorio Ingeniería de Software II

Fig. 2: La IS en el Programa de estudios

75

Tabla 1. Plantillas de desarrollo
Nombre de la plantilla Guía para elaborar la Descripción Conceptual del Proyecto. Elaborada con base en [18]. Guía para elaborar planes de administración de proyectos de software. Elaborado con base en [1-10]. Guía para especificar los requerimientos del software. Elaborado con base en [6]. Guía para especificar el diseño del software. Elaborado con base en [4]. Las guías de la fase de pruebas son las indicadas en la sección 4.2.2 y fueron elaboradas con base en [5-9]. Fase en la que se aplica Comunicación Planificación Análisis Diseño Pruebas

4. PROCESO DE APLICACIÓN DE LAS TÉCNICAS 4.1 Pruebas de verificación Participantes. Los roles de los estudiantes en las revisiones técnicas formales son los siguientes: Equipo de revisión. 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 organización. Uno de los miembros debe asumir el rol de líder. 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 revisión debe contar como mínimo con la siguiente información:  Enunciado de objetivos de la revisión.

 Especificación del elemento del software que se evaluará.  Elemento del software a revisar.  Planes, estándares o guías que servirán para revisar el elemento software.  Listas de verificación o cotejo para asegurar que el elemento software cumple con los requerimientos mínimos. Procedimiento. Las reuniones para realizar este tipo de revisión se llevan a cabo cuando así lo establezca el calendario del curso o cuando se determine adecuada la revisión del elemento software por su disponibilidad. El procedimiento a seguir se presenta en la Tabla 2. Al finalizar la revisión, el profesor evalúa 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 evaluación al producto ya corregido.

Tabla 2. Procedimiento para llevar a cabo una revisión técnica formal
Pasos 1. Planificación 2. Vistazo (opcional) 3. Preparación Descripción Líder verifica los criterios de entrada, establece el calendario, identifica y convoca al equipo de revisores y reparte los materiales. Si el líder lo considera necesario, convoca a los participantes a una reunión breve en una fecha y hora específica. Cada revisor estudia el material en forma individual. Durante la revisión el equipo realiza lo siguiente: 1. Revisar el elemento de software contra estándares y guías. 2. Discutir las alternativas o recomendaciones en pro del mejoramiento del elemento de software. 3. Asignar responsabilidades para la solución 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 líder). 4. Documentar los aspectos técnicos, las recomendaciones y al responsable de resolverlos. 5. Cuando los defectos son numerosos o críticos, el líder debe recomendar un proceso de revisión adicional (retrabajo). Autor revisa y corrige el producto atendiendo la lista de recomendaciones. Líder comprueba la solución de los problemas realizados por el autor y otros responsables, además de determinar si se necesita realizar otra revisión.

4. Reunión

5. Re-trabajo 6. Seguimiento

4.2 Pruebas de validación Participantes del proceso de pruebas. Los roles de los estudiantes en el proceso de pruebas son los siguientes: Líder de pruebas. Es el responsable del proceso y de su planificación, pero también participa del diseño y ejecución 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 diseñadas con base en [5-9]:  Plan de pruebas. Permite registrar la planificación del plan de pruebas y contiene el resumen de los elementos y características que se probarán y las que no se probarán, 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.  Diseño de pruebas. Tiene dos partes: (a) especificar la estrategia de pruebas y (b) registrar los resultados de las pruebas después de ejecutadas. En la primera parte del formulario se registra información como: el propósito de la prueba, el tipo, las herramientas, los procedimientos, los datos de entrada y los criterios de aceptación. En la segunda parte se registran las No Conformidades —NC— con su correspondiente descripción, el estado de la prueba, el responsable, la fecha de ejecución 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 descripción de las variables que se referencian en el caso de prueba.  Reporte de No Conformidades. Permite registrarlas por su tipo y descripción, por su ubicación, clasificación de importancia, historial, respuesta del equipo de desarrollo y el responsable.  Reporte de métricas. Permite registrar las métricas obtenidas en el proceso de pruebas y calcular los indicadores de métricas. Las métricas 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 código 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 investigación se utilizaron las dos primeras.  Selenium IDE. Funciona como un complemento del navegador Mozilla Firefox y, gracias a esta simbiosis, permite grabar toda interacción del usuario con un sitio Web, en scripts de casos de prueba que luego pueden ser reproducidos.  Selenium RC. Además de proveer la capacidad de ejecutar casos de prueba producidos por Selenium IDE, no sólo 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 ejecución de pruebas de unidad, específicamente en aplicaciones desarrolladas en alguno de los lenguajes de programación 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. Planificación. Antes de realizar las actividades de validación de requerimientos funcionales, el líder de pruebas verifica la disponibilidad de los elementos de prueba y de la documentación 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. Diseño de las pruebas. El encargado de pruebas, de cada funcionalidad o módulo, diseña el proceso de pruebas y utiliza los formularios de diseño de pruebas y casos de prueba. Una vez completados ambos documentos el líder de pruebas los envía, junto con el plan de pruebas, al profesor del curso para su revisión. En caso de que los documentos necesiten correcciones, el profesor se lo regresa al líder 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 físico, hardware, software. Si las condiciones no fueran óptimas el líder de pruebas informa al asistente del curso para que se corrija el problema. Esta información se actualiza en el plan de pruebas. 4. Ejecución de las pruebas. El encargado de pruebas procede a ejecutarlas de acuerdo con el diseño de y durante la ejecución registra los resultados en el formulario diseño de pruebas, incluyendo la imagen que comprueba las NC. 5. Elaboración de reportes de las pruebas. Cuando concluye el proceso de pruebas se completan los formularios del reporte de no-conformidades y el de métricas. Este trabajo lo realiza todo el equipo. 6. Evaluación de las pruebas. Posteriormente, el líder 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 documentación correspondiente para la nueva ejecución. 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, evalúa los resultados para asegurar que efectivamente se cumplen los requerimientos establecidos y para analizar los defectos y las métricas reportados.
Documentos de entrada al proceso de pruebas 1. Planificación 2. Diseño de pruebas 3. Desarrollo del ambiente de pruebas

De 2 a 3 ciclos de pruebas

4. Ejecución de pruebas 5. Elaboración de reportes 6. Evaluación de resultados

Elemento de software con errores

Elemento de software probado

Fig. 3: Procedimiento de pruebas

5. ANALISIS DE RESULTADOS Durante el año 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 están las siguientes:

77

 Administrar la información básica del recurso humano que tiene acceso al sistema: administrador, cliente, desarrollador.  Administrar la seguridad de la aplicación, restringiendo el acceso a la información de acuerdo con rol del usuario.  Administrar la información básica de un proyecto, permitiendo además 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 ―quién, cuándo, qué y por qué― y, a partir de una línea 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 electrónicos correspondientes.  Administrar el proceso de verificación y validación de la calidad de los entregables del proyecto.  Realizar consultas, por ejemplo, un árbol jerárquico 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 aplicación. 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 aplicación a evaluar; el segundo corresponde a una RTF en la que un equipo externo evalúa en forma objetiva una aplicación 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 ejecución 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 continuación se analizan los resultados de las tres métricas recogidas. 5.1 Métrica 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 líneas de código implementadas de la aplicación (LDC), en la tercera, la cuarta y la quinta el número de fallas detectado en los tres ciclos de pruebas correspondientemente y en la sexta, séptima 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 aplicación, se logra detectar un mayor número 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.
Gráfico de Densidades
0.016 0.014 0.012

sólo 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, sólo 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 Distribución de índice de NC por tipo En la Tabla 5 se presentan los resultados de distribución 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 categorías: 1. Funcionalidad. Al realizar una acción determinada el resultado que se muestra no es el esperado. 2. Validación. Existen errores relativos a la falta de validación.

Fig. 4: Gráfico 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 métricas: la de clases y la de requisitos. En la de clases

78

3. Opciones que no funcionan. Al realizar una acción 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 títulos mostrados con reales. 5. Excepciones. El sistema muestra un mensaje señalando 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 aplicación informática y lo que está documentado al respecto.
Tabla 5. Distribución de NC por tipo
Opciones Implementado no que no corresponde con lo Tipos de Fallas Funcionales Validación 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 Distribución porcentual 37% 24% 27% 8% 5%

 Un aspecto que hay que considerar en el proceso de adopción de estándares para el curso es la necesidad de revisar las exigencias de los estándares IEEE, porque son muy específicos y detallados en algunos puntos, lo que los vuelve poco prácticos y difíciles de implementar. Por esto es necesario analizar con cuidado el estándar en forma general y posteriormente hacer una selección de las partes más relevantes para el curso.  La experiencia de utilizar estándares internacionales en forma sistemática brinda diversos beneficios:  Mejora la calidad de los productos que desarrollan los estudiantes.  Capacita y disciplina a los estudiantes en buenas prácticas.  Proveen una excelente regla para medir la calidad de los entregables implementados en las diferentes fases del ciclo de vida.  Las revisiones técnicas realizadas entre equipos de trabajo resultan muy productivas:  El equipo revisor actúa con tal rigurosidad y objetividad que detecta errores que generalmente el equipo revisado no encuentra.  La retroalimentación que recibe el equipo revisado le permite obtener un producto final más depurado y de mayor calidad.  Comparten experiencias, aprenden y/o aclaran aspectos técnicos que no habían considerado en sus proyectos o que no tenían claros.  Impartir el curso de esta manera no es una tarea fácil, porque abarca una amplia variedad de temas de Ingeniería de Software, sin embargo, en general los estudiantes manifiestan mucho interés y satisfacción al aprender y trabajar de forma práctica.  Las métricas 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 Ingeniería de Software del año 2011 su colaboración en esta labor de investigación, porque su trabajo permitió probar estas metodologías. 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 débil validación de las interfaces. No se graficaron las NC del tipo opciones que no funcionan porque de los 143 NC de este tipo, 133 correspondían solamente un equipo de trabajo que entregó la aplicación incompleta.
Distribución de NC de acuerdo al tipo
Funcionales 4% 8% Validación

37%

Opciones que no funcionan Usabilidad

27%

Excepciones

24%

Implementado no corresponde con lo especificado

Fig. 5: Gráfico de NC por tipo

6. CONCLUSIONES Con la metodología propuesta se pueden concluir:  La enseñanza de técnicas de aseguramiento de calidad de software es un área que no debería omitirse en los cursos de Ingeniería 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 metodología utilizada fue positiva porque los estudiantes aprendieron conceptos teóricos de aseguramiento de la calidad del software mediante un enfoque muy práctico.

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. Ingeniería de Software: Un enfoque práctico. Séptima edición, 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), Versión 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

Integración de Redmine y Subversion en la construcción 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 década, 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 año se creó en la Universidad de Costa Rica (UCR) el Centro de Investigaciones en Tecnologías de la Información y Comunicación (CITIC). Dentro de su estructura se propuso constituir Unidades de Investigación, y una de ellas es el Laboratorio de Aseguramiento de la Calidad del Software (LACSOFT) que está en proceso de creación y para la cual se trabaja en la definición de herramientas que permita dar soporte a la gestión de sus procesos administrativos [2]. Este artículo describe los resultados de una investigación de dos herramientas de software libre (Redmine y Subversion) que integradas, pudieran ser incorporadas en LACSFOT para facilitar la administración de sus proyectos de verificación y validación de software.

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo Recibido: 30/03/2012 Correcciones: 19/06/2012 Aceptado: 30/06/2012 Palabras clave Redmine, Subversion, administración 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. INTRODUCCIÓN Hoy día poseer una administración efectiva de la información es un elemento crítico para el éxito de cualquier proyecto. La creciente dependencia de la información y los sistemas que la proporcionan han convertido a los sistemas de información en activos muy valiosos dentro de las empresas. Sin embargo, se ha vuelto común 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 década, común denominador entre la industria y la academia. Se espera que uno de estos puntos de confluencia sea LACSOFT, laboratorio creado con el propósito de: desarrollar y extender la cultura del aseguramiento de la calidad del software, así como promover, facilitar y estimular el uso de metodologías de alcance mundial o regional para mejorar la competitividad de las empresas. Para lograrlo, LACSOFT trata temas de investigación básica y aplicada relacionados con la mejora y la certificación de la calidad de procesos, productos y proyectos que realiza

una organización, considerando las pruebas funcionales del software como el primer servicio que brindará. Por otro lado, LACSOFT como institución universitaria tiene la responsabilidad de asegurar un ámbito adecuado, i.e. un laboratorio bien equipado, para la práctica profesional necesaria en carreras tanto de grado como de posgrado, de manera que los egresados contribuyan de forma inmediata al crecimiento productivo, económico y social basados en nuevas tecnologías 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 verificación y validación (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 investigación 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 sección se describen brevemente las características que hicieron de Redmine, herramienta candidata para la investigación. Posteriormente se mencionan algunas de las ventajas de utilizar Subversion como manejador de versiones de un proyecto. Posteriormente se explica cómo se configuró Redmine para funcionar como plataforma de pruebas de software. Se especifican también los complementos instalados para incrementar la funcionalidad de Redmine y cómo se logró su integración con Subversion. Adicionalmente se describe la experiencia al poner a prueba la plataforma, con estudiantes del curso de Ingeniería de Software, en un proceso de validación de requerimientos funcionales, simulando un ambiente real de trabajo. Finalmente, se exponen los problemas encontrados y las conclusiones obtenidas. 2. MARCO TEÓRICO 2.1 Redmine Es una herramienta web dedicada a la administración de proyectos y al seguimiento de errores, desarrollada con el framework Ruby on Rails. Para su instalación 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 sólo requiere una conexión 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, versión 1.2.1, fue lanzado el 11 de julio del 2011) y se distribuye bajo la licencia General Public License GNU [3]. La principal característica que convirtió a Redmine en una herramienta atractiva para la presente investigación es su enorme flexibilidad. Si bien es cierto, la aplicación fue pensada para el ámbito empresarial, su facilidad de configuración permite utilizarla en la administración de cualquier proyecto, independientemente del área en la que se desarrolle. Además, la coordinación de tareas, comunicación entre los participantes y la integración con sistemas de versiones, terminan por inclinar la balanza al comparársele con otras herramientas para la gestión de proyectos [4]. Específicamente para la administración de proyectos, resultó beneficioso para esta investigación, el hecho de que Redmine permite que cada proyecto posea una configuración propia. Es posible activar o desactivar los módulos para noticias, peticiones, control del tiempo, documentos, y además agregarles campos personalizados (de variedad de formatos: texto, lista, numérico, fecha) que le confieren una identidad propia a cada proyecto. Además un mismo usuario puede ocupar un rol distinto en cada proyecto. La funcionalidad con la que más se identifica a Redmine es la forma en que se le da seguimiento a las tareas y

actividades. Dentro de un proyecto, la asignación y visualización de las responsabilidades se logra a través de “peticiones”. Estas “peticiones” son asignadas a un miembro del proyecto y en su definición contienen: fechas de inicio y fin de la tarea, tipo de petición, porcentaje de realización, prioridad y descripción. Los miembros del proyecto reciben notificaciones acerca de las actividades a las que han sido vinculados, tanto en su página personal de Redmine como por correo electrónico. Además, si así se desea, estas peticiones pueden observarse a través del calendario del proyecto o mediante un diagrama de Gantt. A continuación se resumen algunas de las funcionalidades que posee Redmine y que lo convierten en una herramienta útil para la administración de proyectos [4]:  Integración con repositorios: permite establecer un canal de comunicación directo con un repositorio para el control de versiones de cada proyecto. Entre los tipos de repositorios compatibles están: Subversion, Git, CVS.  Disposición de una página personal: construye una página específica para cada usuario donde se le muestra la información sobre los proyectos en los que participa. Se muestran las tareas que ha asignado, cuáles le han sido asignadas y la actividad reciente del proyecto.  Utilización de filtros: permite realizar consultas sobre las peticiones existentes, tanto por campos predeterminados como por aquellos creados por el usuario.  Administración de archivos y documentos: se cuenta con una sección donde se pueden adjuntar los documentos relacionados al proyecto.  Extensión de sus características: contiene en su sitio web una larga lista de plug-ins para ampliar las funcionalidades de la herramienta. Las extensiones van desde la generación de gráficos, hasta crear salas de chat. De todas ellas se ofrece una descripción breve, las versiones de Redmine para las que es compatible y algunos detalles sobre su instalación. 2.2 Subversion Es una herramienta de software libre utilizada para implementar un sistema de control de versiones. A través de ella es posible realizar de forma automática tareas como: guardar, descargar, y mezclar las distintas versiones que a través 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 inclusión de su código tanto en software libre como comercial. La primera versión de la herramienta fue lanzada en octubre del año 2000 y desde octubre del presente año se encuentra disponible para la descarga gratuita la versión 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 administración de los archivos versionados, Subversion maneja los conceptos de “repositorio” y “copia de trabajo”. Por repositorio se entiende aquel espacio, común 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 periódicamente sincronizarse con el repositorio. Esta sincronización se traduce en las tres operaciones básicas de la herramienta: 1. Importar (Checkout): a través 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 versión o versiones más antiguas. 2. Actualizar (Update): esta operación permite descargar únicamente aquellas modificaciones realizadas al repositorio, ocurridas desde la última sincronización con la copia de trabajo. 3. Confirmar (Commit): esta operación ocurre en vía inversa a las dos anteriores, ya que permite actualizar el contenido del repositorio con los cambios realizados en la copia de trabajo. Esta operación se ejecutará correctamente si no hay conflicto con alguno de los archivos del repositorio, es decir, no habrá sincronización si alguien más, ha modificado el mismo elemento en forma paralela. Para una mejor organización de las versiones, Subversion permite la creación de Tags y Branches dentro del repositorio. La creación de un Tag, técnicamente congela una versión, alejándola del “tronco” (Trunk) de desarrollo principal del proyecto. Por otro lado, la creación de Branches permite la evolución 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 integración [5]. A continuación se listan una serie de características que hacen de Subversion elegible y ventajoso en comparación con otros sistemas y estrategias no automatizadas para el manejo de versiones [6]:  Los directorios también se encuentran versionados, no sólo los archivos.  El estado general del repositorio posee asignado un único número de versión, y no cada archivo.

 Permite adjuntar metadatos a los archivos o directorios versionados.  Las operaciones sobre el repositorio son atómicas, lo que significa que ninguna tiene efecto parcialmente. Ej: un commit concluye hasta que todo él haya ocurrido exitosamente.  Posee una bitácora 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 automática que maneja el flujo en los cambios de líneas de código, lo cual es muy útil para la resolución de conflictos al mezclar archivos.  Permite el bloqueo selectivo de archivos.  Permite conocer los cambios realizados en el repositorio, cuándo, y por quién.  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 sección a continuación, se detalla sobre el procedimiento de pruebas definido para la presente investigación. 3. METODOLOGÍA El objetivo principal de esta investigación es la construcción de una plataforma que apoye y sistematice las actividades de verificación y validación de software. Para ello se decidió aprovechar las conocidas funcionalidades de herramientas como Redmine y Subversion e integrarlas en una única plataforma. El “híbrido” 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 debería garantizar la total separación entre la información a la que tiene acceso el equipo revisado y la que ve el equipo revisor. Para satisfacer estos objetivos, se inició la configuración de Redmine con la definición de una estructura de proyectos y sub-proyectos, y la especificación 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 ejecución de las pruebas de software, se necesita de alguna manera estandarizar la forma en la que la plataforma recopila la información concerniente a los resultados de las pruebas. Para esto, se tomó como modelo el estándar de la IEEE para Revisiones y Auditorías del Software (IEEEStd. 1012-1987) y se agregaron nuevos campos y nuevos tipos de peticiones en Redmine. Otro objetivo de la presente investigación 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 también acceder a los entregables a evaluar, sin abandonar el contexto de ejecución. Dicha integración debe conferirle total independencia a la plataforma, de manera que no sea necesaria la utilización de otras herramientas, para la creación o para la alteración 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 creación del procedimiento de pruebas de pruebas “ideal”, luego de enfrentarlo con actores reales, situaciones y problemas “reales”. Esto se logró a través de la interacción con la docencia, incorporando el proceso de validación de requerimientos funcionales dentro del curso de pregrado Ingeniería de Software I y su correspondiente laboratorio de la Escuela de Ciencias de la Computación e Informática de la UCR. En el siguiente apartado se describe detalladamente el proceso a través del cual se configuró Redmine para convertirla en una herramienta apta para las actividades de validación y verificación de software. 4. CONFIGURACIÓN DE REDMINE Al comenzar la presente investigación, se contaba con la versión 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 sólo la estructura de proyectos, sino también nuevos roles, campos y peticiones. El paso siguiente fue, hacer efectiva la integración entre Redmine y Subversion, creando repositorios y accediendo a ellos desde la plataforma. Finalmente debía comprobarse la efectividad de los enlaces Redmine para direccionar revisiones y archivos específicos en un repositorio asociado a algún proyecto. 4.1 Estructura de proyectos El proceso de personalización de Redmine, comenzó con la creación de la estructura de proyectos necesaria para que la plataforma resultara apta tanto para el desarrollo, como para la administración de las pruebas al software desarrollado. La estructura se planeó en forma jerárquica: un proyecto “padre” y dentro de él tres sub-proyectos “hijos”. Estos sub-proyectos servirían 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 específicos, tipos peticiones y roles de usuario. 4.2 Personalización 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.  Iteración: de tipo numérico, en él se especifica la iteración del ciclo de vida en la que se encuentra el proyecto.  Versión: de tipo versión, en él se indica la versión 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: conceptualización del proyecto, plan del proyecto, cronograma, especificación de requisitos, casos de uso, casos de prueba, prototipo, modelos de diseño, código, manual de usuario y manual de instalación.

Fig. 2: Módulo para la creación de nuevos campos

En la Figura 2 se observa el módulo de Redmine para la generación 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 documentación: de tipo lista, en él se elige el tipo de error de documentación identificado. Estos errores pueden ser: de correspondencia con otra documentación, de formato, de idioma, de ortografía, de redacción, técnico y otros.  Error de aplicación: de tipo lista, en él se elige el tipo de error de aplicación encontrado. Este error puede ser de: correspondencia con lo documentado, de interfaz, de excepciones, de funcionalidad, de idioma, de opciones que no funcionan, de ortografía, de redacción y de validación),  Tipo de entregable: de tipo lista, en él se elige el tipo de entregable sobre el que se está trabajando. Los entregables pueden ser: conceptualización del proyecto, plan del proyecto, cronograma, especificación de requisitos, casos de uso, casos de

Fig. 1: Estructura de proyectos definida

84

     

prueba, prototipo, modelos de diseño, código, manual de usuario y manual de instalación. También fue necesario definir en los sub-proyectos de prueba una serie de peticiones nuevas. Específicamente: Liberar entregable: petición utilizada para informarle al Coordinador sobre la disponibilidad de un entregable para su revisión. Asignar entregable: petición utilizada para asignarle el entregable a un Revisor. No conformidad documentación: petición utilizada a manera de registro, sobre el hallazgo de un error de documentación. No conformidad aplicación: petición utilizada a manera de registro, sobre el hallazgo de un error de aplicación. Liberar resultado: petición mediante la cual se informa sobre la conclusión y resultados del proceso de pruebas.

pueden ver peticiones, añadir peticiones, modificar peticiones, hojear repositorio, ver cambios en repositorio, acceso de escritura al repositorio y actualizar el repositorio. En las siguientes secciones se explica cómo fueron cubiertas las necesidades del proceso de pruebas, mediante la instalación de extensiones y el aprovechamiento de las características propias de Redmine. 4.4 Integración con Subversion Una de las propiedades de Redmine, fundamental para lograr la consecución del objetivo principal de esta investigación, es su capacidad de integración con repositorios de versiones, específicamente Subversion. La herramienta cuenta con un módulo llamado “Repositorio” el cual debe ser habilitado primero y posteriormente configurado. La configuración es: 1. En la pantalla de “Configuración de Proyecto” habilitar el módulo “Repositorio”, seleccionando la caja de chequeo correspondiente. 2. En el módulo “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 contraseña para el repositorio, se deben ingresar los mismos en los campos correspondientes. Para este caso en particular debió realizarse una configuración adicional: la habilitación del acceso WebDAV (extensión 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 institución. Una vez realizada la configuración del módulo “Repositorio”, se comprobó que a través de Redmine era posible visualizar el historial de revisiones y descargar los archivos del repositorio Subversion (Figura 3), sin embargo, no se permitía modificación alguna sobre el mismo. En otras palabras, las operaciones disponibles eran solamente de lectura y parte de los objetivos de la investigación 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 razón se procedió a buscar, instalar y configurar una extensión (plug-in) que satisficiera este requerimiento.

4.3 Perfiles Según la definición 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 más importantes están: asignar tareas a los desarrolladores y vigilar por el cumplimiento de la ruta crítica del proyecto. Posee todos los permisos a excepción de aquellos de carácter administrativo: administrar el repositorio, administrar categorías de peticiones, borrar peticiones, mover peticiones y crear y modificar proyecto, seleccionar módulos, crear sub-proyectos y administrar versiones.  Desarrollador: integrantes del grupo desarrollador. Sus responsabilidades son más que variadas pues se encargan de diseñar, 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 módulos, crear sub-proyectos y administrar versiones), administrar categorías de peticiones, administrar relación con otras peticiones, modificar notas, mover peticiones, borrar peticiones, administrar consultas públicas, 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, añadir peticiones, modificar peticiones, administrar relación con otras peticiones, gestionar sub-tareas, borrar peticiones, hojear repositorio y ver los cambios del repositorio.  Revisado: son los miembros dueños de su subproyecto de pruebas. Los usuarios con este perfil,

Fig. 3: Módulo 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 módulo “Repositorio”, a saber: subir archivo, crear carpeta y borrar carpeta. Además, se agrega al módulo de configuración de roles (Figura 4), un nuevo permiso sobre actualización del repositorio, es decir, permite definir qué usuarios pueden modificar el repositorio y cuáles únicamente consultarlo.

4.6 Links entre proyectos Para concluir la configuración 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 petición. Estos links le permitirían 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 versión instalada (1.1.0), satisfacía la funcionalidad anteriormente descrita. Estos “links entre proyectos” fueron agregados a la herramienta a partir de la versión 1.2.0, bajo el nombre de “cross-project links”. Por lo tanto, se procedió a actualizar la plataforma a la versión 1.2.1 de Redmine. Luego de la actualización 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 ubicación específica del archivo que se desea referenciar. Estos enlaces pueden utilizarse para direccionar tanto a archivos específicos, como a toda una revisión del repositorio. 5. EJECUCIÓN DEL PROCEDIMIENTO Una vez finalizada la configuración de la herramienta para soportar el procedimiento, se puso a prueba utilizando el curso de Ingeniería de Software y su laboratorio. La experiencia se realizó durante el desarrollo del proyecto práctico del curso. Se intentó simular un ambiente real de trabajo, donde los estudiantes pudieran aplicar revisiones técnicas entre grupos revisores y grupos revisados, permitiéndole a cada uno de los grupos (cuatro en total) evaluar la calidad del software producido por otro grupo de compañeros. Se dedicaron una serie de laboratorios para capacitar en la utilización 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 petición del tipo “No Conformidad”, pudieran clasificar y registrar el tipo de error encontrado. También 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 jerarquía en el momento de crear peticiones del tipo “No Conformidad”, sino que todas debían ser hijas (sub-tareas) de la petición original de tipo “Asignar Entregable”.

Fig. 4: Pantalla para definir privilegios

Como detalle importante debe aclararse que si durante la configuración del repositorio se especificó un usuario y una contraseña, los cambios realizados al estado del repositorio quedarán a nombre de dicho usuario, por lo tanto, para que la autoría de estas modificaciones vaya acorde con el usuario identificado en la plataforma, los campos de usuario y contraseña deben dejarse en blanco. 4.5 Creación automática de repositorios desde Redmine Una vez lograda la actualización de los repositorios desde la plataforma, se consideró la posibilidad de que éstos fuesen creados también 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” permitía dicha funcionalidad. Luego de su instalación, debe configurarse la ruta del directorio donde serán creados y otorgarle permisos de lectura, ejecución y escritura al usuario dueño de dicho directorio (código 0755). Cuando el plug-in es instalado correctamente, se puede ver en el módulo “Repositorio”, junto al campo para digitar el URL, un botón (Figura 5) a través del cual se crea el repositorio automáticamente. [8].

Fig. 5: Botón para crear automáticamente el repositorio

86

6. PROBLEMAS ENCONTRADOS El primer problema experimentado fue el hecho de que la versión instalada de Redmine no disponía de la funcionalidad conocida como “cross-project links”. Estos enlaces representaban una mejora a los enlaces que ya proveía Redmine y permiten referenciar archivos en un repositorio, revisiones enteras o incluso documentos adjuntos pertenecientes a un proyecto distinto. Sin embargo, la actualización mencionada en la sección anterior, requirió instalar también la versión 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 tránsito 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 página, la acción ejecutada antes del bloqueo, se repetía, produciendo la duplicación 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 términos de configuración a la que hubo que hacer frente, fue la política 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 sólo sí, el usuario que los definía era miembro de ambos proyectos. Esta limitación afectó la definición original de los roles en el proceso de pruebas, pues se deseaba una total separación entre los equipos. La solución óptima fue que los revisores no tuvieran acceso más que a la descarga directa del entregable en el repositorio del equipo revisado, sin embargo, para utilizar los links debieron hacerse también miembros del proyecto de pruebas. La solución fue crear un perfil bastante limitado para estos revisores, de manera que sólo tuvieran acceso de lectura al repositorio y acceso denegado a todos los demás módulos del proyecto revisado. Si bien los estudiantes recibieron toda la inducción necesaria para la utilización 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 inclinación 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 sesión de capacitación sobre el uso de la herramienta, donde se atendieron las dudas de los estudiantes y se explicó paso a paso el procedimiento de pruebas. Además por la irregular asistencia de los estudiantes a los laboratorios, quedó evidenciada en la definición de roles, una fuerte dependencia sobre el líder de proyecto, ya que sólo él podía modificar o borrar las peticiones

realizadas, lo cual restaba fluidez al trabajo de los desarrolladores. La solución fue flexibilizar la definición de los roles de usuario, otorgando a los desarrolladores mayores permisos sobre las peticiones. 7. CONCLUSIONES Y TRABAJO FUTURO Como herramienta para la administración de proyectos, Redmine satisface todas las necesidades en cuanto a seguimiento de tareas y comunicación entre los participantes. Esto sumado a su integración con Subversion para administrar repositorios de versiones, terminan por convertirla en una plataforma más que funcional para el desarrollo de proyectos de software. La gran flexibilidad y facilidad para la personalización que posee Redmine, representaron características claves durante la investigación, ya que extienden el campo de acción de la herramienta, permitiéndole ajustarse a proyectos de la más 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 específicas, 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 investigación no hubiera podido llegar a buen término 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 aplicación, le confirieron a la plataforma cierta autonomía que en un inicio no se creía posible. Los laboratorios con los estudiantes representaron una gran fuente de retroalimentación sobre el procedimiento de pruebas definido. También, la utilización 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 introducción en las revisiones técnicas formales y por supuesto el señalamiento de carencias o errores en el diseño 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 configuración estuvieron: el comportamiento inconstante de los enlaces entre proyectos, la inestabilidad de la plataforma posterior a su actualización y la escasa capacitación que recibieron los estudiantes sobre la utilización 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 utilización como plataforma de un proceso de pruebas

87

de software bajo una modalidad de equipos. Su completa integración con Subversion, permite el “intercambio” de entregables para su respectiva evaluación y su naturaleza web, permite el registro, envío y acceso de los resultados de las pruebas, rápida y fácilmente. Se espera que el éxito de la presente investigación no culmine con los resultados ya obtenidos, sino que impulse otros trabajos en los que se experimente la integración de Redmine con otros repositorios como Git, o Mercurial. Actualmente se está trabajando en la inclusión de nuevos campos para la obtención de métricas de pruebas y la generación de reportes de incidencias. Posterior a esta experiencia, se concluye que en proyectos sucesivos sobre integración de herramientas, es vital que desde un inicio se elijan aquellas que demuestren una complementariedad natural, ya sea por la existencia de módulos dedicados a compartir su información a través de servicios web o la exportación de datos. Esto permitiría que la integración suceda de manera rápida y transparente. Otra característica importante es la afinidad temática de las herramientas.

Finalmente como proyecto a futuro siempre en el ámbito de las pruebas de software, se considera la integración de NUnit y Selenium para una agilización de las actividades de validación y verificación en aplicaciones web. 8. REFERENCIAS
[1] [2] [3] [4] [5] [6] [7] [8] Cámara Costarricense de Tecnología de Información y Comunicación. 2010. Sobre nosotros. Online [Mar. 2011] Consejo Nacional para la Calidad de Calidad Costa Rica. 2006. Online [Mar. 2011]. Organización Redmine. 2011. Online [Marc. 2011]. Centro de excelencia de software libre de Castilla La Mancha. Análisis de aplicación: Redmine. 2010. Online [Marc. 2011]. Organización Apache. 2011. Apache Subversion. Onlilne [Apr. 2011]. Gómez, E. S. 2010. Buenas prácticas de gestión 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 Liberación de Productos Software
Heney Díaz P.1, Daira Pérez 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 Planificación 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 Informáticas. 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 artículo se presenta una propuesta de solución para inferir el tiempo de duración de una iteración de pruebas de liberación. Se parte de la descripción del procedimiento de pruebas del Laboratorio Industrial de Pruebas de Software de la Universidad de las Ciencias Informáticas, para luego realizar una conceptualización del término Iteración estudiando la metodología de pruebas de algunas organizaciones. A partir de la observación participante y definida la técnica 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 duración de las pruebas. La base de casos tendrá en cuenta el comportamiento histórico del proceso de pruebas de liberación. Con esta propuesta se dispone de elementos válidos para estimar el tiempo que dura una prueba de liberación. De esta manera se podrá trazar un plan ajustado a la realidad, para dar respuesta a todas las solicitudes de liberación de productos de software.

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión. Historia del artículo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 12/06/2012 Palabras clave Base de casos, iteración, prueba de liberación. Categories and Subject Descriptors D.2.4 [Software Engineering]: Software/Program Verification. General Terms Verification. Keywords Base case, iteration, release testing.

1. INTRODUCCIÓN Según Myers [1], una organización desarrolladora debiera evitar probar sus propios sistemas. Bajo este principio se perfila toda una industria de prueba de software constituida en los países desarrollados por una buena cantidad de profesionales especializados, proveedores de servicios y herramientas, congresos, publicaciones periódicas e innumerables alternativas de capacitación y certificación, el nivel de especialización 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 ejecución de pruebas en función de los servicios que provee. Internacionalmente Cuba tiene poca imagen como país 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 Convención y Feria Internacional Informática 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

través de la discusión de temas afines. Ese mismo año se crea la Dirección de Calidad de Software de la Universidad de las Ciencias Informáticas 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 Ingeniería 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 ejecución de las mismas sobrepasa, en la mayoría de los casos, al tiempo planificado y pactado entre las partes involucradas. Muchos son los factores que dan al traste con esta situación y que provocan fuertes retrasos de los compromisos de entrega de los productos de software a los clientes. Entre estos factores se pueden señalar, el hecho de que los probadores y hasta los desarrolladores en muchos casos son estudiantes de pregrado en formación, 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: ¿Cómo lograr que el tiempo de duración de una iteración de pruebas se corresponda con el tiempo planificado y pactado inicialmente entre las partes

89

involucradas? Para darle respuesta se plantea el objetivo de diseñar una base de casos que permita inferir el tiempo de duración de una iteración de pruebas a partir del razonamiento basado en casos. 2. LAS PRUEBAS DE LIBERACIÓN 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 instalación en el ambiente del cliente. Un paso previo a la instalación 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 liberación, 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 liberación se realizan evaluaciones estáticas y dinámicas, 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 definición de sus procesos, infraestructura, herramientas ―fundamentalmente automatizadas― y técnicas. Se conoce que realizan estas definiciones para desarrollar su actividad pero no se pudo constatar cómo se implementaban dichos procesos, en qué consistían las estrategias de pruebas. A continuación, se define el proceso de pruebas de liberación desarrollado por el DPSW y se asocia una de sus actividades con el área de procesos de administración de acuerdo con proveedores, establecida por CMMI, en función de elevar la eficiencia en la prestación del servicio de pruebas y satisfacer las necesidades del cliente. 2.1 Procedimiento de Pruebas de Liberación. Laboratorio Industrial de Pruebas de Software En el Departamento de Pruebas de Software de la UCI existe un grupo de especialistas capacitados en la ejecución de pruebas de liberación y aceptación de productos de software antes de la entrega pactada con el cliente. Es en el Laboratorio Industrial de Pruebas de Software LIPS, a través 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 través de ella, los proyectos solicitan al laboratorio la liberación de diversos artefactos, reflejando básicamente 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 estén 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 gestión de la prueba. Dicho especialista es el encargado además de elaborar un pre-plan de pruebas donde recoge todos los elementos a tener en cuenta para la satisfactoria ejecución de la liberación del artefacto o de los artefactos en cuestión. Entre estos elementos, uno muy importante lo constituye la propuesta de cronograma de ejecución del procedimiento de pruebas de liberación. Dicho cronograma se discutirá posteriormente en la reunión de inicio, previo a la ejecución de las pruebas. La reunión 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 además, el cronograma inicialmente propuesto y se aprueba entonces el Plan de Pruebas que guía todo el proceso de liberación. Luego de efectuada la reunión de inicio ya las partes involucradas están de acuerdo en el procedimiento a seguir. Faltaría puntualizar algunos detalles para comenzar con las pruebas. Es momento entonces de refinar la batería 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 simultánea. 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, ¿cómo optimizar los recursos a la hora de efectuar las pruebas? Es con las pruebas exploratorias que se disminuye el gasto de tiempo, recursos humanos, tecnología, esfuerzo, etc., ya que proporcionan rápidamente información sobre el artefacto que se va a probar y garantizan un mínimo de calidad para que el artefacto pase a la fase de pruebas. Entonces, posterior a la preparación 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 están listos para entrar al LIPS.

90

Las pruebas comienzan entonces con la ejecución de las iteraciones. En cada una de ellas se ejecuta la batería 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 análisis por parte del especialista al frente de la prueba con la dirección del Departamento de Pruebas de Software, se procede a la liberación de los artefactos y al cierre de las pruebas. Se emite entonces un acta de liberación, se entregan los artefactos liberados y se efectúa una evaluación de las pruebas. Por último, se almacena la versión liberada de cada artefacto de modo que esté disponible para efectuar las pruebas de aceptación con el cliente. Del procedimiento de pruebas de liberación descrito hasta este momento, la actividad que más influye en el tiempo de duración de la prueba es justamente la de ejecución de las iteraciones. 2.2 Iteraciones de Pruebas Al Según se define en la vigésima segunda edición del Diccionario de la Lengua Española de la RAE, el término iteración proviene del latín iteratio y significa: Acción y efecto de iterar. Por su parte, el término iterar significa repetir, volver a hacer lo que se había hecho. Una iteración se refiere a la acción de repetir una serie de pasos un cierto número de veces. Desde el punto de vista matemático, una iteración se refiere al proceso de iteración de una función o a las técnicas que se usan en métodos iterativos para la resolución de problemas numéricos. En programación, la iteración es la repetición de una serie de instrucciones en un programa. Desde el punto de vista de la gestión de proyectos informáticos, las iteraciones se refieren a la técnica de desarrollar y entregar componentes incrementales de funcionalidades de un negocio. La organización GreenSQA de Parquesoft en Colombia, recoge en su metodología de pruebas de software a las iteraciones de pruebas como parte del proceso de ejecución de las mismas, como se observa en la Figura 1. Básicamente define a la iteración como las actividades requeridas para ejecutar los requerimientos de prueba identificados en la fase de diseño de pruebas, reportar los hallazgos y asegurar su corrección por parte del equipo de desarrollo de software [6]. El Centro de Ensayos de Software de Uruguay, en su estrategia de gestión 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 versión determinada del producto. El proyecto de prueba es guiado por los ciclos de prueba y cada ciclo está asociado a una versión 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 planificación.

Fig. 1: Metodología de Pruebas de Software de GreenSQA

Como parte del ciclo también se tiene en cuenta la configuración del entorno y el diseño de los casos de prueba a partir de la especificación del producto; se contempla la ejecución 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: Metodología de Pruebas de Software del CES

Partiendo de las diferentes definiciones de iteración, dadas las particularidades del proceso de desarrollo de software en la UCI y del propio procedimiento de pruebas de software del LIPS, el término se conceptualizó como se manifiesta a continuación. Una iteración no es más que la revisión completa de un determinado artefacto, dígase de tipo documentación o aplicación, con el empleo de determinadas herramientas según 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 iteración, se ejecuta la batería de pruebas completamente, se informan las No Conformidades detectadas y se entregan al equipo de desarrollo. Posteriormente se realizan pruebas de regresión y se preparan las condiciones para la siguiente iteración o para el término de las pruebas con la liberación final del artefacto.

91

Fig. 3: Mapa Conceptual. Iteración

3. RAZONAMIENTO BASADO EN CASOS El Razonamiento Basado en Casos RBC surge en la década del 80 como un nuevo paradigma de la Inteligencia Artificial. Sus raíces parten del trabajo de Roger Schank [8] y su modelo de memoria dinámica. Schank planteó que esta forma de razonamiento resuelve nuevos problemas adaptando soluciones utilizadas en problemas anteriores. Entre las diversas definiciones existentes se encuentra también 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 máquinas las utilicen. Aamodt & Plaza [10] enuncian por su parte que constituye una reciente aproximación para la resolución de problemas y para el aprendizaje. En este sentido, el razonamiento basado en casos es una técnica de Inteligencia Artificial que se basa en la utilización de experiencias previas para resolver nuevos problemas mediante la hipótesis 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 solución al problema actual. Este mecanismo de razonamiento es utilizado por los humanos en múltiples problemas de la vida cotidiana y permite que sea un sistema de fácil comprensión. El RBC involucra toda una metodología con un ciclo de actividades que además 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 más similares de la base de casos, partiendo de que un caso es un problema anterior con su solución.  Reutilizar: Extraer la solución del caso seleccionado para utilizarla. Esto puede implicar adaptar la solución a la nueva situación.  Revisar: Se debe analizar si la nueva solución es aceptable y si es necesario revisarla.  Retener: Después de haber aplicado la solución con éxito, se debe almacenar la experiencia como un nuevo caso en la base de casos.

Fig. 4: El ciclo del RBC según la Unidad de Desarrollo Tecnológico 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 solución. 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 solución para estimar el tiempo de duración de una iteración, se parte de aplicar el método de observación participativa. Cada uno de los rasgos identificados, son resultado de la experiencia de un grupo de especialistas del LIPS, en estrecha relación con el procedimiento de pruebas de software y las peculiaridades en el proceso de desarrollo. Todos los artefactos que se someten a pruebas de liberación en el laboratorio, se pueden clasificar en dos categorías fundamentales. Pueden ser artefactos de tipo documentación o aplicación. 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 liberación. En este caso, dentro de las aplicaciones entran todos los sistemas informáticos, desde sistemas de gestión, multimedia, aplicaciones web, portales, hasta juegos. La revisión de los artefactos de tipo documentación, siempre van a requerir menos esfuerzo y empleo de recursos que los artefactos de tipo aplicación. Por esto, constituyen factores determinantes en la duración de una iteración, 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 también la duración de la prueba. Los tipos de prueba pueden ser de funcionalidad, seguridad, volumen, contención, carga, estrés, rendimiento, configuración, instalación o simplemente revisión técnica de la documentación [1].

92

¿Cómo 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 función del tipo de pruebas a realizar y poseen diferentes niveles de complejidad que van a influir también en el tiempo de duración de la iteración. Las herramientas constituyen otro rasgo de la base de casos propuesta. El esfuerzo para la ejecución de una iteración corre a cargo del especialista de pruebas al frente de la prueba y de los estudiantes que se desempeñan como probadores. Por tal motivo, la cantidad de probadores y de especialistas de que se disponga va a influir de modo significativo en la duración de una iteración. 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 desempeño de una prueba de liberación. 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 filosofía del artefacto en cuestión. 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 comprensión mientras se enfrenta la prueba. El rasgo que se va a inferir con esta propuesta, es el tiempo de duración de la iteración.
Tabla 1. Base de Casos Propuesta

liberación con un nivel de precisión basado en la experiencia acumulada. Esto les permitirá realizar planificaciones y estimaciones de recursos y esfuerzo más reales, con mayor nivel de certeza, para lograr un desarrollo eficiente del proceso. De esta manera, los tiempos de ejecución de las pruebas se ajustarán 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 propósito general, desarrollado para la evaluación de bases de casos, permitiendo crear expertos de cualquiera de ellas. Para obtener una solución, 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 más cercanos de manera gráfica 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 investigación se encuentra terminada y está siendo utilizada al mismo tiempo, para el análisis, diseño e implementación de un sistema inteligente, de propósito específico, que base su funcionamiento en la definición de un peso por cada rasgo y de una función de inferencia bien estudiada y documentada y no en la implementación de algoritmos de propósito general. 6. CONCLUSIONES Con la realización de esta investigación 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 ejecución de pruebas de liberación a los artefactos que se producen en los Centros de Desarrollo, de la Universidad de las Ciencias Informáticas. Su establecimiento y mejora permitirá afrontar nuevos compromisos con el resto de las organizaciones de desarrollo de software y su inserción en el mercado internacional.  La definición del término de iteración, a partir de las metodologías 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 solución.  La identificación de los principales elementos a tener en cuenta para aplicar la técnica de Inteligencia Artificial de Razonamiento Basado en Casos,

En la Tabla 1 se realiza una representación de los datos que contendrá la base de casos propuesta. En la misma se recogen los rasgos que la compondrán, los posibles valores que pueden asumir cada uno de los rasgos y se especifica si puede existir multi-selección, es decir, si se puede seleccionar más de un valor para cada rasgo. 5. RESULTADOS ESPERADOS La calidad de los resultados de la aplicación 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 también, 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 técnica para la definición de una base de casos con los rasgos que caracterizan el comportamiento de una prueba de liberación de productos de software.  El diseño de la estructura de una base de casos para inferir el tiempo de ejecución de una iteración de pruebas de liberación, en el Laboratorio Industrial de Pruebas de Software, favorecerá la implementación de una herramienta que permita realizar un conjunto de estimaciones para mejorar el proceso de pruebas y aumentar la satisfacción del cliente con la prestación 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 capacitación de los especialistas de pruebas de sistemas de software. Actas de Talleres de Ingeniería del Software y Bases de Datos, 1(4), 31-36. [6] Roca, M. J. 2006. Proyectos de Gestión de Calidad: una primera vista desde el enfoque de la guía del PMBOK. Online [Sep. 2011]. [7] Lamancha, P. B. 2007. Estrategia de gestión 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. Automatización y gestión de las pruebas funcionales usando herramientas Open Source. Proceedings XIII Congreso Argentino de Ciencias de la Computación (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 Martínez2, Gustavo López3
12 2

Esc. de Ciencias de la Computación e Informática, 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 Tecnologías de Información y Comunicación, Universidad de Costa Rica, San José, Costa Rica gustavo.lopez_h@.ucr.ac.cr. INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación. Historia del artículo 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 artículo es un reporte de la experiencia de llevar a cabo un proyecto de mejoramiento del proceso de una unidad de desarrollo de software pequeña con base en el modelo CMMI-DEV 1.3. Específicamente, 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 artículo puede interesar a organizaciones de software que desean mejorar su proceso con base en algún estándar internacional.

1. INTRODUCCIÓN El aseguramiento de la calidad ―QA, por sus siglas en inglés― es un conjunto de actividades planificado y sistemático que proporciona confianza en que los productos y servicios cumplirán los requerimientos especificados y las necesidades del usuario [11]. En el caso del software, QA establece y evalúa los procesos que producen los productos de software. Por ejemplo, las actividades de QA en un ambiente de TI determinarían la necesidad de: metodologías de desarrollo de sistemas, procesos de estimación, procesos de mantenimiento de sistemas, procesos de definición de requerimientos, y procesos de pruebas y estándares. Una vez implantados, QA mediría estos procesos para identificar debilidades y luego corregiría esas debilidades para mejorar continuamente el proceso [17]. El software es uno de los artefactos más variables y complejos que se diseñan regularmente. El costo de la verificación del software sobrepasa la mitad del costo total del desarrollo y mantenimiento, y aún estamos lejos de poder producir software libre de defectos [15]. Escoger la combinación apropiada de técnicas 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 Verificación y Validación 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 ejecución de las pruebas al final del ciclo de desarrollo es sólo una pequeña parte de todo el proceso de V&V. Las actividades de verificación controlan la calidad de los artefactos intermedios y del producto final, de manera que satisfagan los requerimientos. Las actividades de validación 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 investigación técnica que se realiza para suministrar a un actor información relacionada con la calidad de un producto de software. Aquí un ‘actor’ es cualquier persona que tenga un interés 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 prácticas 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 versión 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 ―PA´s― distribuidas en cuatro categorías (según la representación continua): Gestión de Proyectos, Soporte, Ingeniería, y Gestión de Procesos. De acuerdo con la representación 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 prácticas específicas y genéricas que la organización puede ejecutar, estableciendo así una trayectoria predeterminada de mejora desde el nivel 1 hasta el nivel 5. Este artículo reporta nuestra experiencia implementando prácticas de aseguramiento de la calidad en una Unidad de Sistemas que desarrolla software interno para nuestra universidad. El resto del artículo está organizado de la siguiente manera. La sección 2 presenta trabajos relacionados a la presente investigación, la sección 3 presenta la metodología utilizada. Las secciones 4 y 5 discuten los resultados obtenidos, la sección 6 presenta las conclusiones. 2. TRABAJO RELACIONADO Existen múltiples estudios relacionados con el mejoramiento de procesos de software y las pruebas de software en pequeñas 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 aplicación 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 compañía TIC alcance el nivel 3 de madurez CMMI. Este estudio lo realizaron en una compañía de consultoría TIC de Nueva Zelanda. Los autores recomiendan que para implementar un modelo de proceso de negocio de forma exitosa y eficiente se necesita mucha planificación, herramientas apropiadas, y métodos 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 organización. Ekdahl et al [5] presentan la experiencia que ha tenido el Centro de Investigación 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 organización, facilitan la logística.  Las entrevistas abiertas y honestas requieren de comunicación e integridad.  Buenas herramientas ayudan en el proceso.  No pierda la oportunidad de realizar alguna capacitación. Durante el desarrollo de nuestro proyecto, se aplicaron la mayoría 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 evaluación y las pruebas. La inclusión de estos representantes locales nos permitió desarrollar cierta confianza, que a su vez facilitó una comunicación fluida y sencilla. Utilizamos herramientas fácilmente integrables a los ambientes de desarrollo y pruebas de la Unidad de Sistemas. Por último, tenemos planeada una capacitación 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 Tecnologías de Información y Comunicación CiTIC, cursos de capacitación que ayuden a la Unidad de Sistemas a mejorar sus procesos de desarrollo y pruebas de software. Huang y Zhang [6] exponen los problemas más comunes que se han encontrado al implementar CMMI en empresas pequeñas y medianas en China. También ofrecen soluciones y un marco de mejora de proceso, que incluye los siguientes aspectos clave:  La implementación del CMMI debe estar integrada con el plan estratégico de desarrollo de la organización.  Realizar un análisis costo-beneficio de la implementación del CMMI.  Hacer una reducción razonable en la implementación del CMMI.  Uso de herramientas adecuadas de apoyo en la implementación del CMMI. Monteiro et al [14] proponen conciliar el nivel de madurez 2 del CMMI con las prácticas de verificación y validación ―que están en el nivel 3― mediante la adopción del estándar ISO/IEC 29119. Staples y Niazi [21] describen dos casos de estudio de empresas australianas pequeñas que adoptaron CMMI para mejorar su proceso de software, ambas con motivaciones y preparación organizacional distintas. De la comparación concluyen que tener metas claras dentro de la organización puede ayudar a posicionar mejor la organización en su preparación 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 metodología para realizar proyectos de mejora del proceso de software en organizaciones de TI, la cual se ha probado en 20 organizaciones y 6 países diferentes a lo largo de 10 años. Esta metodología consiste de 17 pasos agrupados en cuatro fases. La siguiente sección muestra la metodología de trabajo que seguimos en nuestro estudio, tanto para realizar las pruebas a las aplicaciones como para realizar la evaluación de los procesos de software de la Unidad de Sistemas. 3. METODOLOGÍA 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 organización grande y compleja ―de hecho, es la universidad más grande del país―, de ahí que posea varias unidades gestoras de tecnologías de la información, algunas de las cuales desarrollan software para uso interno de la institución. La Unidad en la cual desarrollamos nuestro trabajo tiene un portafolio amplio de proyectos, la mayoría de los cuales son sistemas de información web conectados a bases de datos institucionales. Está conformada actualmente por un equipo de 10 personas. La intervención en aseguramiento de la calidad realizada en esta Unidad tuvo dos componentes: un servicio parcial de pruebas a dos de sus sistemas, y una evaluación parcial de su proceso de desarrollo de software. A continuación de describen en más detalle cada uno de estos componentes. 3.1 Servicio de Pruebas a Dos Aplicaciones El primer componente de la intervención 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 sólo ciertos módulos y ciertas características, por limitaciones de tiempo y personal. Debe aclararse también que nuestra intervención a nivel de pruebas no contempló un acompañamiento desde el inicio del ciclo de vida de las aplicaciones ―es decir, actividades de verificación 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 ―código 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 autenticación de usuarios. Infraestructura de Pruebas. Debido a que este proyecto fue uno de los primeros proyectos auspiciados por el CiTIC de nuestra universidad, no contábamos con una infraestructura tecnológica establecida para la gestión del proceso de pruebas. Así que una de las primeras labores de nuestro proyecto fue diseñar, instalar y probar la infraestructura de hardware, software, y comunicación que permitiera gestionar el proceso de pruebas que se iba a implementar. La infraestructura diseñada y utilizada se muestra en la Figura 1.

Fig. 1: Infraestructura para la gestión 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 aplicación para pruebas Microsoft Test Manager 2010, dado que la Unidad de Sistemas utiliza preferencialmente tecnología Microsoft para desarrollar sus sistemas. El hecho de utilizar la misma plataforma de software facilitó la comunicación e interacción 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 utilización de VS2010 nos permitirá en el futuro cercano realizar pruebas de caja blanca de forma natural y directa sobre el código de las aplicaciones desarrolladas por esta Unidad, las cuales están escritas en su mayoría en .NET. A nivel de hardware, se instaló un servidor de TFS2010 sobre Windows Server 2008. También 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 través del TFS con el equipo de desarrollo de la Unidad de Sistemas, teníamos que ser capaces de ver ambas redes simultáneamente. Por otro lado, la aplicación 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 aplicación.

97

Entregables. El proyecto contempló la entrega de los siguientes artefactos a la Unidad de sistemas:  Plan de Pruebas  Especificación de Diseño de las Pruebas  Reporte de Ejecución de las Pruebas e Incidentes Para la confección del Plan de Pruebas, se utilizó como base el estándar IEEE 829 [7], con algunas adaptaciones para nuestro contexto. Este documento fue entregado físicamente al director de la Unidad de y se solicitó su aprobación para proceder con las siguientes etapas. La Especificación de Diseño 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 “colección de equipo” ―team collection en el argot de Microsoft― del servidor TFS2010. Para diseñar las pruebas únicamente se utilizaron técnicas de caja negra, específicamente análisis de clases de equivalencia, análisis de valores frontera, cobertura de casos de uso, e intuición y experiencia. La ejecución de las pruebas se realizó de forma manual, pero se almacenó una bitácora de ejecución 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 tenían acceso de lectura al servidor TFS, de manera que ellos podían observar las pruebas que se estaban diseñando, así como monitorear el avance de la ejecución de las mismas. Esto evitó tener que crear otro documento de texto con la especificación de los casos de prueba, y agilizó bastante el proceso. El Reporte de la Ejecución de las Pruebas y el Reporte de Incidentes se consolidaron en un solo documento que resumía las pruebas ejecutadas, las configuraciones utilizadas, y los resultados obtenidos al ejecutar las pruebas así como los incidentes ―defectos― encontrados durante la ejecución de las pruebas. Los incidentes de agruparon por módulo y por severidad. Una gran parte de la información incluida en este reporte fue obtenida y procesada con las herramientas VS2010 y TM2010. 3.2 Evaluación del Proceso de Desarrollo de Software Además de llevar a cabo el proceso de pruebas descrito en la sección 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 constelación CMMI-DEV 1.3 [2], al tratarse de una unidad de desarrollo y mantenimiento de software interno de nuestra institución. En particular, nos enfocamos en evaluar las categorías de Ingeniería y Administración de Proyectos del CMMI-DEV V1.3, que contienen un total de doce áreas de proceso. Método de evaluación. Los resultados de la evaluación SCAMPI tipo C [19] fueron documentados utilizando una

serie de workbooks de CMMI V1.3. La documentación de los resultados le ayuda a la organización a identificar las brechas que se deben cerrar para lograr un mayor nivel de capacidad según 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 participación 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 método 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 organización apenas está iniciando su proceso de mejora y el objetivo de esta primera evaluación era obtener un vistazo rápido 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 documentación del proceso de software con respecto a las prácticas de las áreas de proceso del CMMI. En ese sentido, es una evaluación tipo “análisis de brechas”, pero también verifica la implementación de tales prácticas en los proyectos y procesos de la organización. El método de evaluación empleado es simple pero efectivo, y lo hemos utilizado anteriormente en diversas organizaciones de software con buenos resultados [4, 5]. La evaluación se hizo mediante tres instrumentos: 1. Revisión de la documentación existente, tanto impresa como digital. Para esto se tomó en cuenta toda la documentación 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 documentación de procesos. 3. Revisión de la evidencia, tanto impresa como digital, de los proyectos y procesos en ejecución para verificar la implementación (uso) de los procedimientos, plantillas y otros artefactos descritos en la documentación. Como resultado se obtuvo lo siguiente: 1. La lista de brechas (gaps) existentes en el proceso con respecto a las prácticas propuestas en el CMMI. Las brechas se clasifican según su severidad en dos tipos:  Amarilla: brecha leve, generalmente causada por falta de implementación.  Roja: brecha seria, generalmente causada por falta de documentación o implementación. 2. Grado de cubrimiento de cada una de las prácticas del CMMI.

98

Para la cuantificación del grado de cubrimiento de cada práctica, definimos una escala de evaluación de tres niveles para determinar el grado de cubrimiento de las metas y prácticas tanto específicas como genéricas del CMMI, como se describe a continuación:  Rojo: práctica no cubierta del todo → valor 0  Amarillo: práctica parcialmente cubierta → valor 1  Verde: práctica 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 número de prácticas cubiertas ―verde― ponderadas con un factor de 2 y el número de prácticas parcialmente cubiertas ―amarillo― ponderadas con un factor de 1. Luego esa suma se divide entre el número total de prácticas 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 prácticas del PA * 2

Tabla 2. Cantidad de pruebas diseñadas aplicación 2 Módulo A B C Total Cantidad de pruebas diseñadas 21 21 27 69 Cantidad de pruebas ejecutadas 21 21 9 51

Para calcular el porcentaje total de cubrimiento de un grupo de PA´s del CMMI ―por ejemplo, el grupo de PA´s de una categoría del CMMI o de un nivel del CMMI― en la organización, se suman el número de prácticas cubiertas ―verde― ponderadas por un factor de 2 y el número de prácticas parcialmente cubiertas ―amarillo― ponderadas por un factor de 1, para todas las PA´s del grupo. Luego el resultado de esa suma se divide entre el número total de prácticas ―del grupo de PA´s― ponderadas por un factor de 2, y así se obtiene el porcentaje de cubrimiento del grupo de PA´s:
%Cubr. PAs = (#Rojas*0)+(#Amarillas*1)+(#Verdes*2) X 100% # total de prácticas CMMI evaluadas* 2

De las Tablas 1 y 2 se observa que se probaron más módulos y se realizaron más pruebas sobre la primera aplicación que sobre la segunda. Esto se debió a varios factores: (1) se contó con más tiempo para el proceso de pruebas de la primera aplicación que para el de la segunda, (2) la primera aplicación era conceptualmente más sencilla y fue mucho más fácil 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 cómo éstos se reflejaban en la interfaz de usuario y (i3) para la primera aplicación se utilizaron tres configuraciones distintas de pruebas ―variando el sistema operativo y el navegador―, mientras que para la segunda aplicación sólo se utilizó una configuración. Las configuraciones bajo las cuales se probó la primera aplicación 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 más pruebas ejecutadas que diseñadas, debido a que se trató de ejecutar la mayoría de las pruebas en las tres configuraciones. En la Tabla 2 se reportan menos pruebas ejecutadas que diseñadas 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, específicamente en el módulo C. Las Tablas 3 y 4 muestran tanto el número de pruebas que pasaron como el número de pruebas que fallaron, por módulo, para cada una de las aplicaciones en estudio. En resumen, de las 398 pruebas ejecutadas sobre la primera aplicación 72% pasaron y 28% fallaron; mientras que de las 51 pruebas ejecutadas sobre la segunda aplicación 61% pasaron y 39% fallaron. En la primera aplicación, una gran parte de las pruebas, entre 68% y 84%, pasó en todos los módulos. En la segunda aplicación, más del 60% de las pruebas fallaron para uno de sus módulos, lo cual evidentemente generó un mayor número de incidentes reportados en dicho módulo (ver Tabla 6).
Tabla 3. Resultado de las pruebas aplicación 1 Módulo 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 número de pruebas diseñadas como el número de pruebas ejecutadas, para cada una de las aplicaciones en estudio. En estas tablas se muestra la cantidad de pruebas, agrupadas por módulo, donde cada módulo corresponde a lo que la Unidad de Sistemas denomina un “caso de uso de análisis” ―es decir, la separación se realizó con base en la documentación de la aplicación suministrada por la Unidad, pero también se verificó que a nivel de interfaz, la separación modular fuera conveniente―. Los nombres las aplicaciones y sus módulos se omiten por razones de confidencialidad.
Tabla 1. Cantidad de pruebas diseñadas aplicación 1
Módulo A B C D E Total Cantidad de pruebas diseñadas 44 32 24 20 19 139 Cantidad de pruebas ejecutadas 130 94 70 47 57 398

99

Tabla 4. Resultado de las pruebas aplicación 2
Módulo 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. Distribución de incidentes por módulo y severidad aplicación 2
Módulo 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 número de incidentes, por módulo y por severidad, para cada una de las aplicaciones en estudio. Como se puede observar en estas tablas, la mayoría de los incidentes encontrados fueron de mediana severidad. En la primea aplicación se encontraron algunos de alta severidad, no así en la segunda aplicación ―no se muestra la columna correspondiente a severidad 2 en la Tabla 6 ya que no hubo incidentes en esta categoría―. Ambas aplicaciones exhibieron pocos incidentes de baja severidad.
Tabla 5. Distribución de incidentes por módulo y severidad aplicación 1
Módulo 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 EVALUACIÓN DEL PROCESO DE DESARROLLO A continuación presentamos los resultados de las evaluaciones SCAMPI tipo C efectuadas en la Unidad de Sistemas. Las áreas de proceso contempladas en la evaluación fueron las cinco PA´s de Ingeniería más las siete PA´s de Administración de Proyectos del CMMI-DEV V1.3. La Tabla 7 muestra las PA´s evaluadas, su categoría y nivel de madurez. Al lado de cada PA se indica su acrónimo en inglés. La Tabla 8 resume los resultados de nuestra evaluación de las cinco PA´s de Ingeniería. Para cada PA, se muestran la cantidad total de prácticas evaluadas, la cantidad de prácticas por grado de cubrimiento: verde, cubierta, amarillo, parcialmente cubierta y rojo, no cubierta y el porcentaje de cubrimiento de la PA calculado según la fórmula “%Cubrimiento PA”. La última fila muestra los totales así como el porcentaje total de cubrimiento para todas las PA´s de Ingeniería (calculado según la fórmula “%Cubr.Gupo PAs”.

Tabla 2. Áreas de proceso evaluadas Área de Proceso 1. Verificación (VER) 2. Validación (VAL) 3. Solución Técnica (TS) 4. Integración del Producto (PI) 5. Desarrollo de Requerimientos (RD) 6. Planificación de Proyectos (PP) 7. Seguimiento y Control de Proyectos (PMC) 8. Administración del Riesgo (RSKM) 9. Administración Integrada de Proyectos (IPM) 10. Administración Cuantitativa de Proyectos (QPM) 11. Administración de Requerimientos (REQM) 12. Administración de Contratación de Proveedores (SAM) Tabla 8. Cubrimiento de las áreas proceso de Ingeniería
Área de proceso 1. VER 2. VAL 3. ST 4. PI 5. RD Cubrim. Ing. Prácticas 8 5 9 9 8 39 Cant. prácticas 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%

Categoría Ingeniería Ingeniería Ingeniería Ingeniería Ingeniería 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 información recolectada y los aspectos evaluados en cada sesión se introdujeron en formularios a partir de los cuales se generaron gráficos que resumen el porcentaje de cumplimiento de las prácticas asociadas a cada área de proceso evaluada. La Figura 2 muestra el gráfico resumen del porcentaje de cubrimiento para las PA´s de Ingeniería evaluadas.

Fig. 2: Cubrimiento de las 5 áreas de proceso de Ingeniería

Los resultados del análisis de brechas fueron documentados utilizando los workbooks del CMMI-DEV V1.3, desarrollados para tal efecto con base en las prácticas del modelo. Precisamente uno de los aportes más 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 evaluación de las prácticas y metas específicas del área de proceso de Verificación. 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 prácticas de verificación que están siendo implementadas, pero en algunos casos no están debidamente documentadas. Algunas prácticas sugeridas por el CMMI no están del todo contempladas en el proceso actual que ejecuta la organización. Finalmente, las brechas encontradas en cada área de proceso se documentan y clasifican según 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 Verificación. De un total de 10 brechas, 8 se consideraron leves ―amarillo― y 2 serias ―rojo―.
Tabla 3. Evaluación de las prácticas de Verificación
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 PA´s de Administración de Proyectos.
Tabla 4. Brechas del área de proceso de Verificación
Brecha 1. No existe un procedimiento documentado para realizar verificaciones de productos de software. 2. Los métodos de verificación disponibles para productos de software específicos no están documentados. 3. Los costos de R.H. encargados de la verificación de productos (QA y usuarios) no están cargados a los proyectos de desarrollo 4. La descripción de los ambientes de pruebas y el procedimiento de paso de artefactos de un ambiente a otro no están documentados. 5. Los procedimientos para verificación de artefactos de software no están documentados. 6. No se están realizando actualmente revisiones de colegas de código fuente. 7. Los procedimientos para realizar revisiones de colegas de artefactos de software no están documentados. 8. No existe una base de datos digital en línea con los resultados de las verificaciones de los artefactos de software (todo está en papel). 9. No existen métricas de calidad resultado de las verificaciones de los productos de software. 10. No se realiza un análisis 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-ción de Proyectos
Área de Proceso 1. PP 2. PMC 3. RSKM 4. IPM 5. QPM 6. REQM 7. SAM Cubrim. Admon. Proyecto Cant. de prácticas 14 9 7 13 8 5 8 64 Cant. prácticas 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 organización identificar los aspectos específicos que debe mejorar en su proceso de desarrollo de software. En este ejemplo específico, las dos brechas más importantes claramente especifican que la organización debe iniciar la aplicación de métricas de calidad y productividad a las actividades de verificación de productos de software que se realizan, incluyendo las pruebas, e implementar un proceso de análisis de los resultados de las verificaciones para mejorar el proceso de software. Las demás brechas se consideran leves ya que no son causadas por la inexistencia de la práctica sino por la falta de documentación de la misma. Por otro lado, también se evaluaron las áreas de proceso de la categoría de Administración de Proyectos del modelo CMMI-DEV V1.3. La Tabla 11 resume los resultados de nuestra evaluación de las siete PA´s de Administración de Proyectos. Para cada PA, se muestran la cantidad total de prácticas evaluadas, la cantidad de prácticas 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 Administración de Proyectos

La Figura 3 muestra el gráfico resumen del porcentaje de cubrimiento para las PA´s de Administración de Proyectos evaluadas. En este caso, claramente se refleja que las áreas de proceso de Administración Integrada de Proyectos IPM y Administración Cuantitativa de Proyectos QPM son particularmente débiles debido a que la organización no cuenta con un sistema de métricas de desempeño para los proyectos. Adicionalmente, las áreas de proceso de Seguimiento y

101

Control de Proyectos PMC y Administración de Contratación de Proveedores SAM también se deben mejorar. La Figura 4 muestra el resumen final de la evaluación realizada, donde cada barra representa el porcentaje de cubrimiento para las categorías de Ingeniería y Administración de Proyectos, respectivamente, del CMMI-DEV V1.3. De esta figura se observa que el cubrimiento general para las áreas de proceso de Ingeniería fue del 44%, mientras que para las áreas de proceso de Administración de Proyectos fue de 32%. Este resultado se debe principalmente a la falta de documentación y evidencia de la ejecución de muchas prácticas que, aunque en algunos casos se implementan en los proyectos, no están debidamente documentadas en la definición del proceso o no existe evidencia de su realización. En ambos casos, tales falencias se identificaron como brechas del proceso actual que deben ser mejoradas. Estos resultados también reflejan que existen grandes oportunidades de mejora que se pueden incorporar al proceso de desarrollo de software que efectúa la Unidad de Sistemas.

unidades de desarrollo de software dentro de nuestra universidad que están 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 organización de software pequeña como la descrita en este artículo es cómo 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 inversión se justifica. En se sentido, estamos actualmente orientando a la organización 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 evaluación 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 González, Eric Rojas, Mauricio Barrientos y Francisco Cocozza. Este proyecto fue apoyado por el Centro de Investigaciones en Tecnologías de la Información y Comunicación y por la Escuela de Ciencias de la Computación e Informática. 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 categorías de Ingeniería y Administración de Proyectos del CMMI-DEV V1.3

6. CONCLUSIONES La ejecución 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 serán priorizados y tomados en cuenta en una segunda versión de las aplicaciones, mejorando así la calidad de dichos sistemas. Adicionalmente esperamos que la metodología seguida para desarrollar el proceso de pruebas así como las herramientas utilizadas para su gestión, sirvan como ejemplo de buenas prácticas 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 evaluación SCAMPI tipo C de doce áreas de proceso de Ingeniería y Administración 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 están actualmente en proceso de implementación. 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 Elicitación de requisitos desde la perspectiva del diseño de producto
Ricardo Mejía G.1, Alejandro Cálad A.2, Daniel Zuluaga H.3
Universidad EAFIT. Medellín, Colombia. 1 rmejiag@eafit.edu.co 2 acaladal@eafit.edu.co 3 dzulua19@eafit.edu.co INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 10/06/2012 Palabras clave Ingeniería de Requisitos, diseño 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 artículo busca comparar los procesos relacionados con el diseño de producto y el desarrollo de software; específicamente la identificación de necesidades en el desarrollo de producto y la ingeniería de requisitos en el desarrollo de software. La investigación presenta una revisión y comparación de métodos, la obtención de aspectos similares y cómo este resultado puede justificar una posible mejora al desarrollo de software en la fase de elicitación de requerimientos mediante la implementación de de métodos adaptados de la teoría de ingeniería 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 problem–solving 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 product’s 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 1990’s 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. It’s 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. Löwgren, 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]

Mejía, G. R. 2009. Modelos y Mejores prácticas para el diseño globalizado. Correa, V. S. (Ed.), El libro azul: Apuntes de Ingeniería y Diseño, 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 Metodología de Ejecución del Plan de Pruebas de Software basado en la guía PMBOK
Docente Universidad Tecnológica de Pereira. Pereira, Colombia. levayala@utp.edu.co. Estudiante Universidad Tecnológica de Pereira. Pereira, Colombia. jorgesuarezch@gmail.com. 3 Estudiante Universidad Tecnológica de Pereira. Pereira, Colombia. angelytocardona@gmail.com.
1 2

Luz E. Valencia1, Jorge L. Suarez2, Angélica M. Cardona3

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo 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 están consignadas las pruebas a realizar de un software, tal como un mapa. Sin embargo, en múltiples ocasiones se tiene problemas a la hora de cumplir con este plan. Es por esto que se pensó en mirar la ejecución de este como un proyecto y aplicarlo con un estándar reconocido y probado que ha brindado buenos resultados, el PMBOK (Project Management Body of Knowledge). En este documento se especifica cómo aplicarlo a la ejecución del plan de pruebas.

1. INTRODUCCIÓN La utilización de la guía del PMBOK [4] a la ejecución del plan de pruebas, surge del grupo de investigación Grande de la Universidad Tecnológica 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 propósito del laboratorio es encaminar a las pequeñas y medianas empresas de la región, dedicadas al desarrollo de software, hacia el desarrollo de software con calidad. Con el fin de obtener un buen desempeño este centro de aseguramiento de calidad para los productos de software, se requiere tener agilidad, rendimiento y organización al momento de administrar los proyectos. Se considera proyecto todo aplicativo con la documentación respectiva que llega al laboratorio para ser probado. Lo mínimo que se espera en la documentación del software es: el documento de requerimientos y un diseño del aplicativo, de tal forma que se conozcan los resultados que se esperan de la aplicación. Inicialmente se debe firmar un acta de constitución para el proyecto, en la cual se estipula que el laboratorio va a realizar específicamente ciertos tipos de pruebas, sobre

un determinado software en proceso de desarrollo. Luego viene la etapa de planeación, que consiste en escribir el plan de pruebas para más tarde diseñar 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 metodología 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 metodología debe estar soportada en un aplicativo que se construirá una vez probada y validada la metodología. 2. EL PLAN DE PRUEBAS El plan de pruebas es un documento especificado en la IEEE 829 [2], los ítems presentados a continuación presentan una ligera modificación respecto al estándar, 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é función cumplen dentro de éste, es decir, configuración, requisitos, condiciones mínimas, entre otros: Documentos y Programa o módulos.  Estrategia. Se especifican técnicas, patrones y herramientas para diseñar casos de prueba así como grado de automatización y número mínimo de casos de prueba.  Características. Se debe especificar cuáles características se prueban y cuáles características no se prueban.  Categorización de la configuración. 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 función 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 demás de la información de quien presenta el reporte, y la información 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 características, el tiempo y el para qué se necesita. También se debe señalar cuando se requieran recursos especiales, como por ejemplo un especialista en un tema específico.  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. También debe existir un responsable general del cronograma y los hitos deben verse resaltados.  Manejo de riesgos. Cada riesgo consignado debe tener una acción mitigante (prevención), y una acción de contingencia (corrección). Los riesgos deben tomarse en cuenta por su alto impacto o por su alta probabilidad de ocurrencia. 3. LA METODOLOGÍA 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 evaluación. Se describe a continuación cada una de las etapas.

3.1 Planeación La etapa de planificación 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 construcción de un plan de pruebas exitoso, por tal motivo el laboratorio le debe dar una alta prioridad a las tareas de verificación y validación 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 aprobación por parte del cliente del plan de pruebas. Esta etapa se representa en Figura 1.

Fig. 1: Etapa de Planificación

La EDT es una descomposición jerárquica 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 más niveles tiene un árbol, más detalle hay en las especificaciones de las actividades para conseguir dicho entregable. El hecho de saber cuáles son los entregables del proyecto, facilita al laboratorio, determinar las actividades para cada entregable y asignar los tiempos de duración de dichas actividades; de esta forma se construye un cronograma mucho más ajustado a la realidad, en términos de tiempo y recursos. Se considera, que el laboratorio de pruebas de software requiere como máximo el tercer nivel de profundidad, debido a la naturaleza técnica 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 diseño. 3.2 Diseño Luego se realizar la etapa de planeación se debe continuar con la etapa de diseño, 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 Diseño

Fig. 3: Formato Casos de Prueba

Un caso de prueba, según la IEEE 610 [1], se define como un conjunto de entradas, precondiciones de ejecución, resultados esperados y post-condiciones de ejecución, desarrollados para un objetivo particular o condición de prueba, en otras palabras, son un conjunto de condiciones o variables bajo las cuáles se determina si un requisito es parcial o completamente satisfactorio. El objetivo principal en esta etapa, es diseñar los casos de prueba y la matriz de trazabilidad. Los casos de prueba se van a diseñar 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 método 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 relación matemática 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 través del análisis que debe hacer el tester al diseñar 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.  Descripción paso a paso: listado y numeración de pasos para ejecutar la prueba.  Entradas: V, cuando el dato a ingresar debe ser válido; y NV, cuando el dato a ingresar debe ser inválido.  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 más 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 características 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 características 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 ejecución).  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 elección de datos es uno de los aspectos más importantes del diseño de un caso de prueba, pues con una selección cuidadosa de los datos es posible lograr mejor cobertura con los casos de prueba a diseñar y brindar más confianza en el desempeño 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 mínimo con tres características, como se especifica en SWEBOK [3]:  Amplitud: es la cantidad de datos que serán utilizados para realizar la prueba.  Alcance: variación 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 diseñar 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 cuáles requisitos están por fuera de los casos de prueba. Además, 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 ampliarán en la etapa de ejecución. Cuando en el plan se especifiquen pruebas automatizadas, es necesario que además de los casos de prueba, se diseñen los scripts para las pruebas automatizadas. Estos scripts deben respetar todas las especificaciones dadas en el plan para la automatización, en grado de automatización, técnicas y herramientas a utilizar, y demás. Finalmente se obtienen los casos de prueba para ejecutarlos en la siguiente etapa y la matriz de trazabilidad como mecanismo de control. 3.3 Ejecución Consiste en ejecutar los casos de prueba diseñados 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 aplicación, los casos de prueba diseñados, 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 simultánea la ejecución de las pruebas y la consignación de las fallas encontradas.

 Severidad: ¿Qué tan difícil es solucionar el error? (Alto, Medio, Bajo, No Establecida)  Prioridad: ¿Es urgente? (Crítica, Alta, Media, Baja)  Tipo:  Consideración: debe ser tomado en cuenta.  Sugerencia: No es necesario solucionarlo.  Error: Es necesario solucionarlo.  Hallazgo: No se esperaba encontrarlo.  Naturaleza (Documentación, Ambiente, Desarrollo)  Estado:  Abierto: No se ha solucionado.  Cerrado: fue solucionado satisfactoriamente.  Reabierto: se había corregido y volvió a aparecer.  Retroalimentación: la solución no fue satisfactoria.  Reproducible ¿Se repite? (Siempre, A veces, Nunca)  Resolución ¿Cuándo se va a solucionar? (Siguiente Versión, No Resuelto, Para Diseñar)

Fig. 6: Formato Bugtracker

Cuando una falla es encontrada al software es posible que esta detenga la ejecución de las pruebas, según la categorización de la configuración, especificado en el plan de pruebas. Las fallas y/o errores encontrados además de quedar consignadas en el bugtracker, darán 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 información completa y clara de la falla y/o error encontrado. Existen dos causas por las que se podría 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 prolongación de las actividades por realizar y posiblemente impacto sobre el costo del proyecto. La primera causa va a ser manejada a través de la gestión el tiempo, que consiste en ‘pausar el cronometro del proyecto’ e iniciar el ‘cronometro de espera por solución’ hasta que el cliente devuelva las correcciones correspondientes. Una vez estén en el laboratorio los ejecutables corregidos se ‘continúa el cronometro del proyecto’, y se vuelve a la etapa de ejecución, se debe comprobar que las fallas encontradas son resueltas satisfactoriamente y que los otros requisitos continúan funcionando correctamente. Es aquí donde cobra importancia el estado en el bugtracker (abierto, cerrado, reabierto o retroalimentación) porque si una falla es

Fig. 5: Etapa de Ejecución

En cada línea del formato bugtracker, queda consignada una falla encontrada, de esta se debe especificar:  Identificador del caso de prueba.  Descripción: ¿Cuál 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 gestión de cambios, soportados en la matriz de trazabilidad realizada en la etapa de diseño, que permite saber cuáles 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 diseño, rediseñando los casos de prueba afectados directa e indirectamente y el proyecto volverse a ejecutar, comprobándose que los cambios fueron implementados debidamente. Podría suceder que se presenten las dos causas simultáneamente, en tal caso se debe parar el cronometro del proyecto y luego: 1. Verificar que los requisitos nuevos cumplan con las características mínimas. 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 había mencionado ambas causas pueden producir, la modificación 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 ejecución 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 ejecución. 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 comunicación con el cliente, que debe permitir agilizar las actividades a realizar, se propone utilizar herramientas de video conferencias; y que la metodología debe aplicarse a través de un sistema de información (software) pues de otro modo sería tedioso y muy difícil llevar a cabo el proceso de pruebas. Finalmente, se obtiene la información 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 Evaluación Esta etapa inicia cuando se ha definido el estado de la resolución 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 Evaluación

El informe final, también incluye los indicadores que se le toman a la empresa desarrolladora, esos indicadores son: número de fallas encontradas en la aplicación, numero de errores encontrados en la documentación y el tiempo tomado por los desarrolladores para solucionar las fallas. Lo que permite que el empresario conozca el desempeño real de su organización, evalúe su empresa, encuentre sus falencias en el proceso de desarrollo, y trace políticas 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 también se debe expedir un certificado que puede ser: de aceptación, condicionada o de no certificación. La certificación de aceptación se expide cuando el software cumple con los requerimientos de calidad y las fallas encontradas fueron solucionadas satisfactoriamente [6]. La certificación condicionada se expide cuando existen fallas y/o errores sin ser solucionados satisfactoriamente y la no certificación 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 definición 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 culminación del contrato. 4. BENEFICIOS DE EJECUTAR EL PLAN DE PRUEBAS A TRAVÉS DE LA METODOLOGÍA 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 través de los estadísticos entregados por el laboratorio de pruebas.  Obtener indicadores estadísticos confiables en cada proyecto, lo cual permitirá a los clientes mejorar sus procesos.  Optimizar el tiempo de duración de un proyecto en el laboratorio de pruebas.  Tener un sistema de información homogéneo y estándar para el laboratorio de pruebas, de tal forma que obtener información de éste sea más fácil. 5. CONCLUSIONES  La metodología hace más eficiente la ejecución del plan de pruebas utilizando herramientas de la guía PMBOK, de tal forma que considera en sí las pruebas de un software en construcción un proyecto a realizar.  El plan de pruebas constituye la base para la etapa de planeación del proyecto, mientras que la EDT es la base para ajustar el proyecto en recursos y tiempo dentro del cronograma.

 La etapa de diseño 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 más confiables, mediante la selección cuidadosa de los datos.  La etapa de ejecución se centra en realizar las pruebas diseñadas, 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 modificación del alcance consignado en el plan de pruebas, causa la modificación del contrato entre el cliente y el laboratorio.  La gestión de tiempos esta orientada a identificar cual de las partes ocasiona la mayoría de retrasos en el proyecto.  La etapa de evaluación 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 dirección de proyectos: Guía 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] Corporación 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 análisis de requisitos entre un método de desarrollo de software tradicional vs la incorporación de BPM
Luis Merchán P.1, Diego A. Gómez M.2, Eunice Borja O.3, María E. Flórez 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 Especialización en Procesos para el Desarrollo de Software, USB Cali. Eunice_borja@eficacia.com.co. 4 Egresada Especialización en Procesos para el Desarrollo de Software, USB Cali. meflorez2000@yahoo.com. 5 Egresada Especialización en Procesos para el Desarrollo de Software, USB Cali. paotole@gmail.com. INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 30/04/2012 Correcciones: 24/05/2012 Aceptado: 30/05/2012 Palabras clave Gestión de procesos elicitación 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 análisis de requisitos constituye sin lugar a dudas el mecanismo a partir del cual se establecen las condiciones bajo las cuales se adelantarán las diferentes fases del ciclo de vida de desarrollo de software. Una buena interrelación 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 método de análisis de requisitos contemplado bajo la óptica del rediseño de procesos mediante BPM (Business Process Management) el cual en su aplicación para un caso de estudio muestra indicadores de resultado halagadores frente al método tradicional de análisis 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. INTRODUCCIÓN 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 implementación 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 optimización de procesos con miras a que las organizaciones sean más eficaces, eficientes y ágiles; en otras palabras, más competitivas con el fin de responder a los grandes retos que en su momento los mercados e industria exigen. BPM no ha sido la excepción y las empresas están asumiendo procesos de implementación bajo diferentes perspectivas debido a la incertidumbre conceptual sobre su contexto, beneficios y retos: unas asumen los proyectos como implementación tecnológica y otras como un proceso de rediseño 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 método que incorpore a BPM en la fase de análisis del

ciclo de vida de desarrollo de software que conduzca a unos requisitos más sólidos, pertinentes y coherentes con el modelo de negocio. Para el desarrollo del tema que nos ocupa, este artículo primero presenta una justificación de este enfoque desde la perspectiva de los procesos de negocios y el desarrollo de software; posteriormente presenta una breve descripción del contexto del caso de estudio, la metodología 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 científica, las conclusiones y trabajos futuros. 2. JUSTIFICACIÓN DE LA INCORPORACIÓN DE BPM EN EL DESARROLLO DE SOFTWARE Uno de los principales retos que se plantean los responsables de Tecnologías de Información 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 razón, la implementación de BPM es de gran importancia ya que permitirá administrar de manera

116

unificada las personas, los procesos y la información de una organización así como los productos que del mismo se puedan desprender como: (1) agilización del trabajo de los usuarios, (2) la posibilidad de integrar tanto a empleados, clientes, proveedores y colaboradores, logrando una mayor trazabilidad y un menor número de errores en la información que manipulan y (3) mejor identificación de necesidades y expectativas para el software que los soporta. Se parte del supuesto de que un buen diseño de procesos impactará favorablemente los fases de análisis y definición de requisitos lo que de hecho redundará en las siguientes fases del ciclo de desarrollo de software y es así como la elaboración de un comparativo entre el método tradicional de desarrollo de software en la fase de análisis vs el análisis bajo BPM permitirá determinar y validar las ventajas de su incorporación 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 consultoría integral en gestión de recursos humanos y outsourcing con 19 oficinas en Colombia y dos en Ecuador. Se tomó el proceso el de selección de personal por ser el de mayor impacto dentro de la organización y porque administra más de 20.000 puestos de trabajo y los subprocesos administración y gestión de hojas de vida. 4. MÉTODO TRADICIONAL La empresa en la cual se adelantó el comparativo presenta como método de desarrollo de software en su fase de análisis de requisitos las siguientes etapas:  Fase de levantamiento: La inicia el usuario del proceso escribiendo la necesidad o problemática en una plantilla estándar. Para el caso de estudio participaron los roles de líder de talento humano y analista de talento humano dado el contexto organizacional del software a ser desarrollado.  Fase de aclaración: El ingeniero de gestión y requisitos recibe de parte del usuario líder del proceso, el requisito detallado en la plantilla. Analiza el documento y solicita una reunión para aclarar la necesidad, esto en el caso que se identifique que hay ambigüedad o se detecte que no está completo. Una vez aclarado el requisito se pasa a la fase siguiente.  Fase de análisis: El analista de desarrollo software asignado para administrar el requisito se reúne con el ingeniero de gestión y requisitos para hacer la entrega formal y analizar en conjunto la necesidad y así determinar si se recibe a satisfacción o si es necesario que se complemente. Una vez recibido a satisfacción 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 análisis 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 análisis detallado, el cual debe quedar escrito en un documento definido ―diseño funcional y documentación―. 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 construcción.  Fase de validación: Finalizado el análisis se convoca a reunión al ingeniero de gestión de requisitos, el usuario líder del requisito y el analista de desarrollo de software. En la reunión se hace la presentación de la(s) alternativa(s) de solución y entre todos se selecciona una de ellas. El usuario líder da el visto bueno de la propuesta seleccionada y se inicia la fase de diseño y construcción. 5. MÉTODO CON BPM Para la gestión de análisis de requisitos incorporando a BPM [6, 7] se estructuraron las siguientes fases: 1. Fase descubrimiento de procesos: Tiene como propósito el entendimiento de los procesos de negocios por el equipo del proyecto. 2. Fase modelamiento flujo de procesos: Tiene como propósito el modelamiento del proceso para análisis de eficiencia y efectividad. 3. Fase definición de reglas de negocio: Tiene como propósito definir las reglas de negocio que determinan la automatización y estandarización del proceso. 4. Fase de mejoramiento de flujo de proceso: Tiene como propósito proponer a partir de indicadores y simulaciones el proceso más 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 gestión y requisitos, (2) líder de talento humano, (3) analista de talento humano y (4) analista de productividad y desarrollo. 6. RESULTADOS Y ANÁLISIS Se presentan a continuación los resultados de aplicar ambos métodos 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 análisis funcional y detallado de la solución entregada con el método tradicional y el método con una herramienta BPM. Al comparar las actividades realizadas y la cantidad de horas invertidas en cada uno de los métodos, se puede ver claramente la diferencia tanto en cantidad de actividades como el número de horas totales. El método tradicional requirió de seis actividades con un total de

117

53 horas y con el método BPM las actividades se redujeron a cuatro y la inversión en horas a 35. Lo anterior nos lleva a concluir que la productividad con el método BPM se incrementa en este caso, en 18 horas y se disminuye en dos actividades y lo más importante es que la calidad del análisis se mantiene.

6.3 Esfuerzo en días Siendo consecuentes con la observación anterior con respecto al tiempo por rol, en la proyección en días para la etapa de análisis del proyecto se puede observar un mayor esfuerzo en el método tradicional, 53 días, a diferencia del método BPM, 33 días, como lo muestra la Figura 3.

Fig. 3: Comparativo de tiempos del proyecto

Fig. 1: Comparativo de tiempos invertidos por método

6.2 Tiempos invertidos por rol Uno de los recursos más importantes en la planeación 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 análisis:       Ingeniero de gestión y requisitos Líder de talento humano Analista de talento humano Analista de productividad y desarrollo Analista de desarrollo Coordinador de procesos de desarrollo

6.4 Número de personas Validando el tema de cantidad de recurso en cuanto a personas en el proyecto, aplicando el método tradicional se tiene en principio una persona por rol es decir, se destina en total, un número de seis personas que intervienen en la etapa de análisis. Siendo consecuentes con esta forma de asignación de las tareas, aplicando el método BPM sólo se requerirían 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 concentración de actividades en los roles de Ingeniero de gestión de requisitos y de analista de productividad, para los cuales es posible asignar más personas que cumplan estos roles, evitando la sobrecarga y rutas críticas, sin aumentar la cantidad de horas asignadas para cumplir con las actividades a realizar; en consecuencia, se conseguiría no alargar el tiempo total del proyecto aplicando el método BPM.

Al realizar el análisis comparativo de la Figura 2 se puede observar que aplicando el método 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 función dentro del proyecto. También observamos la variación en cuanto a la cantidad de horas trabajadas por rol en cada método, concluyendo que en la aplicación del método BPM se consumen menos horas en total pero se concentran más actividades en los roles de analista de productividad y el de ingeniero de gestión y requisitos. Se aprecia que el rol de analista de talento humano que corresponde al área cliente tiene una mayor participación.

Fig. 4: Comparativo de recursos en # de personas

6.5 Costos del recurso Tanto en el método tradicional como en el método 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 información presentada en los puntos anteriores, se puede visualizar en la Figura 5 un mayor costo presupuestado para el desarrollo de la etapa de análisis con el método tradicional: una diferencia de $9.737.762 con respecto al del método BPM. 6.6 Tareas Críticas Con el método tradicional. La ruta crítica 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 sólo 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 gestión 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 métodos.
Tabla 1. Resultados del comparativo entre los métodos Tradicional Las fases de análisis y diseño son independientes Un enfoque muy orientado a las gestión de datos La fase de análisis requiere mayor número de actividades Se requiere mayor cantidad de personas para llevar a cabo las fases de análisis y diseño La participación 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 gestión de procesos Se reducen las actividades de análisis Las fases de análisis y diseño se realizan bajo un mismo rol Existe mayor participación y continuidad del usuario final con el proceso Permite actividades paralelas para una mejor ruta crítica

Fig. 5: Comparativo de costos

Fig. 6: Ruta crítica con el método tradicional

Con BPM. La ruta crítica solo se encuentra en el rol de ingeniero de gestión 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 estructuración de un framework para la implementación 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. Informática Económica, 13(4), 63-74. [4] Computerworld. 2011. BPM: Innovación y Competitividad en Latinoamérica. 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 crítica con el método 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 fácilmente 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. Meléndez C.
Fundación Universitaria Tecnológico Comfenalco. Cartagena, Colombia. lmelendez@tecnologicocomfenalco.edu.co. INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Reflexión Historia del artículo Recibido: 30/04/2012 Correcciones: 30/05/2012 Aceptado: 05/06/2012 Palabras clave Pruebas, seguridad informática, marco, metodologías. 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 informática 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 producción. 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 artículo 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. INTRODUCCIÓN 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 años 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 técnica como en tecnologías, además 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 artículo se busca dar un vistazo a los diferentes instrumentos — metodologías, pruebas y herramientas— que brinda el Open Source para llevar a cabo este proceso. En el capítulo 2 se tocarán los conceptos básicos que rodean la prueba de seguridad en aplicaciones web, en el capítulo 3 los distintos tipos de prueba de seguridad que se pueden llevar a cabo, en el capítulo 4 se explicarán los detalles de la metodología más completa para llevar a cabo la prueba seguridad, en el capítulo 5 se compararán dos de las herramientas para la automatización de las tareas asociadas y por último se finaliza con las conclusiones obtenidas al desarrollar este trabajo.

2. BASES TEÓRICAS 2.1 Aplicaciones Web Una Aplicación Web puede ser vista como un software basado en arquitectura cliente/servidor creado para operar en un entorno Web, que usa como canal de comunicación protocolo HTTP [2] y se visualiza a través de un Navegador. En la Figura 1 se observa la interacción de los distintos componentes que una aplicación web puede poseer.

Fig. 1: Aplicación Web - Componentes

Son desarrolladas en lenguajes de programación de última generación tales como ASP, ASP.Net, Python, Perl, JAVA, PHP, entre otros, siendo PHP y JAVA los más usados en la actualidad [3]. La aplicación es diseñada utilizando patrones arquitectónicos basados en un modelo Cliente/Servidor, uno de los más usados es el MVC o Modelo Vista-Control [4], también conocido como Modelo de 3 Capas, el cual divide la aplicación en tres componentes operativos con funciones distintas — modelo de datos, interfaz gráfica y lógica de negocio—. En la Figura 2 se puede ver la manera en que opera el patrón arquitectónico MVC.

120

cual se publican y buscan los Servicios Web. Este servicio ha permitido estandarizar los servicios de localización, ubicación y publicidad de los Servicios Web dando orden a estos procesos que carecían de una estructura normalizada entre ellos.

Fig. 2: Arquitectura MVC o Modelo Vista–Control

Algunas ventajas de este tipo de aplicaciones son:  Elimina las barreras de acceso a la aplicación, ya que al basarse en tecnologías Web es posible acceder a ella desde cualquier parte a través de la Internet, siempre y cuando la configuración de seguridad lo permita.  Es totalmente multiplataforma, lo cual permite que la aplicación pueda ser accedida desde cualquier sistema operativo a través de un navegador Web.  El consumo de recursos por parte del cliente que accede a la aplicación es bastante bajo en comparación con aplicaciones stand-alone.  El tiempo de desarrollo y puesta en producción de este tipo de aplicaciones es menor que el de aplicaciones stand-alone. 2.2 Servicios Web Según el World Wide Web Consortium [5], un Servicio Web, es un sistema software identificado por una URI cuyos interfaces públicos están definidos y descritos por XML. Esta definición puede ser accedida por otros sistemas software, los cuales pueden interactuar con el Servicio Web en la forma prescrita en su definición, 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 heterogéneas (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 través del protocolo XML y transportados sobre protocolos de uso común en la Internet como HTTP o HTTPS. La arquitectura de los Servicios Web consta de tres elementos básicos: 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 características necesarias para que se dé el consumo del servicio web (su localización, los métodos, parámetros 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 cómo se intercambiaran objetos entre procesos heterogéneos usando para ello mensajes estructurados y estrictamente formateados en protocolo XML. En la Figura 4 se puede observar como interactúan 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 término vulnerabilidad es descrito por Richard Bejtlich [9] como la debilidad existente en un bien que podría dar lugar a su explotación, lo que terminaría impactando negativamente sobre la integridad, confidencialidad o disponibilidad del bien afectado. Un concepto más 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 información. Otra definición interesante es la suministrada por el Centro de Respuesta ante Incidentes del Instituto Nacional de Tecnologías de las Comunicaciones INTECO en España

121

[11], que la definen como aquellos fallos de seguridad que pueden provocar que nuestro sistema informático sea susceptible de sufrir un ataque por una mala programación del mismo o una configuración errónea. 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 diseño, la implementación o en la administración de un bien informático. Existen diferentes tipologías para la clasificación de las vulnerabilidades en sistemas informáticos; la de mayor aceptación es la del Forum of Incident Response and Security Teams FIRST [12], que plantea un modelo tipológico basado en métricas para la clasificación y cualificación de las vulnerabilidades, usando para ello tres grupos básicos de métricas cualitativas, métricas base, métricas temporales y métricas del entorno. En la Tabla 1 se pueden observar las métricas pertenecientes a cada grupo.
Tabla 1. Tipología Basada en Métricas para clasificar vulnerabilidades Grupos Métricas
Vector de Acceso Complejidad de Acceso Métricas Base Autenticación Impacto en la Confidencialidad Impacto en la Integridad Impacto en la Disponibilidad Explotabilidad Métricas Temporales Facilidad de Corrección Fiabilidad del Informe de Vulnerabilidad Métricas del Entorno Daños Colaterales Distribución de Equipos Vulnerables Requisitos de Seguridad                     

Tipos
Locales Red Local Remotos Alta … Baja Simple Múltiple Ninguna Alta … Baja Alta … Baja Alta … Baja Explotable No Explotable Corrección Fácil Corrección Compleja No Existe Corrección Identificada y Confirmada Identificada sin Confirmar Sin Fuentes Alta … Baja Alta … Baja Alta … Baja

Fig. 5: Resumen de OWASP Top 10 – 2010

Desde el año 2007 el proyecto OWASP ha generado una clasificación documentada de las vulnerabilidades más predominantes y críticas en las aplicaciones y servicios web el cual se conoce como el OWASP Top 10 [13], la versión más reciente de esta clasificación data del año 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 tecnológico 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 término Prueba de Seguridad, se mencionará apartes del proceso del que hace parte, la prueba de software. La prueba de software consiste en la verificación dinámica del comportamiento de un programa sobre un conjunto finito de casos de prueba, apropiadamente seleccionados a partir del dominio de ejecución que usualmente es infinito, en relación con el comportamiento esperado [15]. Esta definición hace énfasis en la relación de las características y limitaciones propias de la prueba, número 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 años esta fase ha cobrado vital importancia, lo que ha llevado a formalizar y estandarizar muchos de sus procesos o tareas embebidos, por ejemplo la normalización iniciada en el año 2007 por el comité ISO/IEC JTC1/SC7 para la creación del estándar ISO/IEC 29119 [18], el cual normaliza las mejores prácticas tomadas de estándares 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 estándar 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 exposición y riesgo inherente a este tipo de programas; esta afirmación se respalda en estudios realizados por la firma Gartnet Inc. [1], los cuales concluyen que aproximadamente el 75% de los ataques informáticos 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 producción, en este punto es donde aparece el Testing de Seguridad.

alcanzar este adjetivo cuando se hace referencia a proyectos de mediano y gran tamaño, esto se debe a la gran cantidad de tiempo que el probador debe invertir para revisar la totalidad de líneas 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, además, es posible que entre tantas líneas de código y sin poder ejecutar la aplicación en un entorno de prueba, el probador pierda el control de la evaluación y no se logren los resultados esperados. Por otra parte a pesar de que es viable identificar muchas vulnerabilidades a nivel de código, sin la ejecución de un probe of concept no es posible establecer su nivel exacto de explotabilidad e impacto sobre la aplicación o el servicio web y la información que maneja. Además, esta prueba requiere conocimientos específicos, capacidad de reflexión analítica 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 sólo a la aplicación o al servicio web sin ningún 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 Penetración, esto debido a el enfoque real de las pruebas Blackbox el tester posee el mismo nivel de conocimiento sobre la aplicación 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 aplicación o a la información que ella maneja, también a alterarla o borrarla y, de ser posible, tomar control del host anfitrión. Entre sus principales características se encuentra la sencillez de las tareas para llevarla a cabo, los reducidos tiempos de prueba en comparación con el método anterior y su total orientación a la seguridad de la aplicación [24, 27]. No es útil para verificar el uso de estándares de programación segura, además, no detecta vulnerabilidades asociadas con prácticas poco éticas en el desarrollo, como bombas lógicas, puertas traseras, entre otras, sólo se limita a la identificación de fallas basadas en puntos de acceso o de intercambio de datos a través de la realización de ataques informáticos contra ellos y no cubre la posible totalidad de defectos existentes; en estos puntos de evaluación suelen aparecer especulaciones por parte del probador lo cual reduce la objetividad de la evaluación. 3.3 Whitebox Testing También se conoce como Glassbox-Test. El tester posee acceso al código fuente de la aplicación, manuales de usuario, credenciales validas del sistema, configuración del servidor Web y acceso a la aplicación 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 ejecución a través de un pre-testing controlado y analizar la sección de código que las generan; además, al

Fig. 6: Resultados Webapp Security Investigation

Este tipo de prueba se enfoca a identificar y corregir defectos, más conocidos en el argot de la seguridad informática como vulnerabilidades, que pongan en riesgo la seguridad de la información que los programas manejan o de las plataformas sobre las que operan. 3. TIPOS DE PRUEBAS DE SEGURIDAD 3.1 Análisis Estático de Código Este tipo de prueba es el más básico y riguroso de todos, y es el proceso de evaluar un software sin ejecutarlo [23]; lo que implica una revisión línea a línea del código fuente de la aplicación o el servicio web —este proceso puede ser parcial/totalmente manual o automático a través de una herramienta de análisis— y no tiene la posibilidad de ejecutarse en un entorno para identificar y corregir posibles defectos de programación que desencadenen en vulnerabilidades que pongan en riesgo la seguridad de la misma. Este tipo de Prueba de Seguridad, en teoría, permite identificar gran cantidad de defectos de programación, eliminando las suposiciones que se pueden generar en otros tipos de pruebas porque todo es verificable en el código fuente [23]; además, es útil al momento de comprobar el uso de estándares de programación segura por parte de los desarrolladores. A pesar de ser una técnica que por sus características podría considerarse como muy efectiva, no logra

123

tener acceso al código fuente es posible establecer los niveles de cumplimiento de los estándares de programación. Posee las siguientes falencias [27]:  Puede generar gran número de falsos positivos si el analizador de código fuente no se encuentra calibrado de forma adecuada.  Proporciona poca retroalimentación de los componentes del entorno que pueden comprometer la seguridad de la aplicación.  Está orientada más al dominio de desarrollo que al de la seguridad, a diferencia del Blackbox.  A pesar que el tiempo de ejecución es inferior al análisis estático de código, sigue siendo mayor al necesario para llevar a cabo un Blackbox. 4. OWASP TESTING METHODOLOGY A pesar de estar definido dentro de diferentes metodologías 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 sólo 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 través del sitio del proyecto. OWASP una iniciativa liderada por la OWASP Foundation, organización sin ánimo de lucro de carácter internacional que financia sus actividades a través del cobro de membresías 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, además, plantear guías de buenas prácticas tanto para la prueba como para el desarrollo de software seguro. Dentro de los resultados publicados por OWASP en los últimos años se encuentra una guía metodológica y de buenas prácticas que se han convertido en un estándar de facto para llevar a cabo Pruebas de Seguridad en aplicaciones web, el OWASP Testing Guide [32] trabaja actualmente en el desarrollo de la versión 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 aplicación, a comprender su lógica y a identificar posibles puntos de acceso.
Tabla 2. Controles Fase Modo Pasivo Categoría
Recolección de Información

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 Categoría Pruebas
                                                                   Pruebas SSL/TLS Prueba de DB Listener Prueba de Gestión de Configuración de Infraestructura Prueba de Gestión de Configuración de Aplicación Prueba del Gestor de Extensión de Ficheros Antiguo, backup y ficheros no referenciados Interface de Administración de Aplicación e Infraestructura Prueba de métodos HTTP y XST Transporte de Credenciales sobre canal cifrado Enumeración de usuarios Prueba de detección de Cuentas de Usuario Adivinables Prueba de Fuerza Bruta Prueba para evitar el esquemas de autenticación Recordatorio de contraseña y restablecimiento Cierre de Sesión y Gestión de Cache de Navegación Prueba de CAPTCHA Prueba de Autenticación de Múltiple Factores Prueba de Condiciones de Carrera Prueba del Esquema de Gestión de Sesión Prueba de atributos de Cookies Prueba de Fijación de Sesión Prueba de Variables de Sesión Expuestas Prueba de CSRF Prueba de Ruta Transversal Prueba para Evitar Esquema de Autorización Prueba de escalada de Privilegios Prueba de Lógica de Negocio Prueba de XSS Reflejado Prueba de XSS Almacenado Prueba de XSS basado en DOM Prueba de XSS basado en Flash Inyección SQL Inyección LDAP Inyección ORM Inyección XML Inyección SSI Inyección XPath Inyección IMAP/SMTP Inyección de Código Inyección de Ordenes del Sistema Operativo Desbordamiento de buffer Prueba de Vulnerabilidad incubada Prueba de HTTP Splitting/Smuggling Prueba de Ataques a través de Comodines SQL Bloqueo de Cuentas de Usuarios Pruebas de DoS mediante Desbordamiento de Buffer Asignación 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 Recopilación de Información de WS Prueba de WSDL Prueba en la Estructura del XML Prueba del XML a nivel de contenido Prueba de REST/parámetros HTTP GET Adjuntos SOAP maliciosos WS SOAP Prueba de Repetición Vulnerabilidades Ajax Pruebas Ajax

Pruebas de Gestión de Configuración

Pruebas de Autenticación

Pruebas de Gestión de Sesiones

Pruebas de Autorización Prueba de Lógica de Negocio

Pruebas de validación de datos

Pruebas de denegación de Servicio

Pruebas de Servicios Web

Pruebas de AJAX

Pruebas
 Spiders, Robots y Crawlers  Descubrimiento/Reconocimiento mediante motores de búsqueda  Identificación de puntos de entrada de la aplicación  Pruebas de firma digital de Aplicaciones Web  Descubrimiento de Aplicaciones  Análisis de Códigos de Errores

5. HERRAMIENTAS PARA AUTOMATIZACIÓN Una metodología de Prueba de Seguridad como la propuesta por OWASP, exige gran cantidad de pruebas, que si bien podrían realizarse de forma manual, el tiempo necesario para completarlas sería bastante prolongado y ocasionaría serios retrasos en la puesta en

124

producción del aplicativo. Esta situación fue aprovechada por investigadores y empresas del campo de la seguridad informática para desarrollar herramientas que permitieran automatizar las tareas o pruebas asociadas, lo que permite ahorrar tiempo en la realización de las pruebas, aunque tienden a incurrir en la generación 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 mayoría 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 solución al problema se encentra en el Software Libre. Investigadores del área de la seguridad informática 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 identificación de vulnerabilidades en entornos web, con características 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 código 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 fácilmente extensible. Esta arquitectura se basa en dos secciones o componentes operacionales: (1) el núcleo 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 según su categoría [23, 40, 42]. A la fecha ofrece plugins para detectar más 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 fácilmente extensible [42].  Posee dualidad de interfaces de usuario, consola y gráfica, lo que le permite operar sin inconvenientes en entornos gráficos o de línea de comando.  Su interfaz gráfica es bastante intuitiva, lo que permite que el manejo de la herramienta sea sencillo.

 Brinda la posibilidad de crear perfiles, los cuales cargan una colección 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 instalación, entre los que se destaca el OWASP Top 10, que se enfoca exclusivamente en realizar pruebas de identificación de vulnerabilidades asociadas a este escalafón.  Posee una amplia base de datos de plugins, la cual es periódicamente 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 verificación manual de resultados.
Tabla 4. Tipología de Plugins W3AF [40, 43]
Plugin
Discovery Audit Bruteforce Grep Evasion Output Mangle

Descripción
Descubren la superficie de análisis de la aplicación objetivo. Intentan detectar una vulnerabilidad específica en el sitio Web Realizan ataques de fuerza bruta contra módulos de autenticación. Buscan información en el contenido de las páginas del sitio. Modifican las peticiones para evadir filtros de seguridad. Definen el formato de salida de la información generada. Permiten que el usuario modifique secciones de las peticiones realizadas

Desventajas:  A pesar de poseer una interfaz de fácil uso, la configuración de la herramienta exige buen conocimiento en seguridad, lo que restringe su uso a un grupo específico de profesionales.  La calidad gráfica de los reportes generados es baja.  El consumo de recursos es elevado en comparación con otras.  Tiende a generar un numero alto de falsos positivos, por lo que se recomienda la verificación manual de resultados. 5.2 Arachni Es un proyecto Open Source desarrollado en lenguaje Ruby orientado a operar a través de interfaces Web. Se inicio como un ejercicio educativo y se ha convertido en uno de los proyectos más prometedores en el área de la detección de vulnerabilidades en ambientes Web. Posee características como una arquitectura 100% modular y distribuida, habilidades analíticas y meta-analíticas que le permite correlacionar y sacar conclusiones con base en resultados obtenidos y opera en ambientes de computación en malla lo que repercute en un aumento considerable en el rendimiento de la herramienta. En la Tabla 5 se describen sus módulos.
Tabla 5. Módulos y Pruebas Disponibles en Arachni Módulos 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

Recolección de Información 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 todavía 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 intérprete que soporte estas tecnologías.  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 través del OWASP Top 10.  A pesar de implementar métodos que disminuyen la aparición de fasos positivos, siguen apareciendo aunque en un menor número, por lo que se recomienda complementar el trabajo de identificación de vulnerabilidades automatizado con una verificación manual.  No posee muchas pruebas para evaluar Web Services.  Los periodos de actualización de la herramienta a pesar de ser periódicos son muy largos. En la Tabla 6 se ofrece un análisis 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 Módulos y Plugins Patrones de detección 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 Más de Plugins 180

Ventajas:  Es un proyecto Open Source.  Fue creado para operar sobre sistemas operativos Linux, pero es posible ejecutarlo en Windows a través del emulador de consola Linux Cygwin.  Posee la capacidad de razonar y sacar conclusiones a través de un proceso de correlación 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 evaluación, lo que ayuda a que pueda incorporar nuevo conocimiento durante el proceso de prueba ―descubrir vectores de ataque ocultos, implementar variantes de ataque, adaptar técnicas o PoC al entorno que se evalúa…,―.  Para optimizar el consumo de ancho de banda utiliza peticiones HTTP asíncronas 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 más de 40 módulos de auditoría y recolección de información, compuestos por cientos de PoC que permiten identificar desde fallas críticas como code injection, XSS o SQL injection hasta recuperar información expuesta como direcciones de e-mail, directorios sin protección o comentarios en el código del cliente.  Permite ejecución de pruebas de forma distribuida o en entornos de Grid Computing a través de la implementación de un API RPC, lo que aumentar el rendimiento y disminuye los tiempos de duración de la prueba. Desventajas:  Poca información acerca de su uso y configuración.  El número de pruebas que puede realizar es menor en comparación con W3AF.

Arachni
Ruby Basada en Modulos Medio Si (CygWin) Si Si Si Web y Consola Media 40 Módulos (Auditoria y Reconocimiento) No Limitado en número 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 Generación de Falsos Positivos Dificultad en el Uso Dificultad en la Configuración del Testing Estabilidad de la Versiones Liberadas Periodicidad de Actualización 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 realización como por los resultados ofrecidos.

126

 El trabajo en el desarrollo de metodologías para pruebas de seguridad en aplicaciones web se incrementa cada día.  La metodología propuesta por OWASP para probar aplicaciones web es una de las mejores opciones para llevar a cabo esta tarea, se podría considerar como la más 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 través de una verificación manual.  La formación de los programadores debe incluir sólidas bases en seguridad informática para evitar que comentan errores en el desarrollo o la configuración que desemboquen en vulnerabilidades críticas que pongan en riesgo la aplicación, 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. Model–View–Controller (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. O’Reilly 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] Grendel–Scan 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 Tecnologías de la Información. [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 Métodos Ágiles: Debate y Vías de Integración
Universidad Politécnica 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 presentación tiene pretende contribuir al debate existente en la comunidad de Ingeniería del Software acerca de la integración de prácticas de usabilidad y UEX en el desarrollo ágil. Se presentarán los puntos comunes y diferencias entre ambas aproximaciones así como los principales enfoques de integración entre ambas disciplinas que están 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, métodos á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 Participación de Agentes en los Procesos de Ingeniería, determinada por RNFs
Universidad de Antioquia. Medellín, 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

Germán Urrego G.

Universidad Nacional sede Medellín. Medellín, Colombia glgiraldog@unal.edu.co

Gloria L. Giraldo G.

producto, dando un tratamiento separado y posterior a los atributos de calidad. La progresiva irrupción de las tecnologías de la información y las comunicaciones permite la masiva participación de agentes interesados en soluciones informáticas que cubren prácticamente todas las áreas de intervención de los seres humanos, pone de manifiesto la importancia de los requisitos Nofuncionales, como lo presentan, entre otros, [8, 9, 16], convirtiéndolos, en muchos casos, en los factores prioritarios y dominantes en la construcción de los productos [15, 23]. Nuestra investigación en este campo, nos conduce a la obtención de requisitos No-funcionales que nos permitan la conceptualización y aplicación de diferentes enfoques participativos en la ingeniería, como es el caso del trabajo cooperativo, la ingeniería multidisciplinaria y concurrente, la ingeniería concurrente colaborativa, entre otros, con aplicación a productos de diferentes campos. Por ejemplo, la elaboración de una propuesta curricular de un programa en ingeniería con un enfoque multidisciplinar y concurrente [11], la incorporación del concepto de desarrollo sostenible en currículos de ingeniería [20], la elaboración de una ontología de conceptos referidos al conocimiento necesario para la construcción de currículos de un programa de ingeniería [21], la elaboración de un modelo de identificación, prevención y corrección de riesgos en la innovación de productos y servicios. La consideración de Requisitos No-funcionales en las mencionadas aplicaciones será explicada en la sección 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 ingeniería. Igualmente se constata la escasez de modelos que definan las formas de participación de los agentes interesados y la realización de los procesos a partir de los RNF de los productos. Como una contribución a la mencionada deficiencia adoptamos una representación del modelo de procesos que resalta las interacciones entre los agentes implicados. Allí se muestra cómo sobre este modelo se pueden aprovechar enfoques de ingeniería orientados hacia la innovación de productos y servicios, como por ejemplo la co-creación, reafirmando los RNFs de estos enfoques. Esto constituye el objeto del presente artículo. Luego de la introducción, el artículo describe en Sección 2 las experiencias de la explotación de los RNFs para la elaboración del modelo conceptual de un producto. En

RESUMEN En general las metodologías para definir y elaborar el modelo conceptual de un servicio o un producto intangible, como los sistemas de información centran su accionar en el proceso más que el producto, más en el problema que en la solución. En este artículo mostramos cómo, trabajando con orientación al producto, se puede obtener, a partir de sus Requisitos Nofuncionales, un modelo de representación de procesos que soporte el enfoque de la Ingeniería concurrente (IC). En el modelo de proceso se hace explícita la forma como participan los agentes bajo dicho enfoque. Palabras clave Requisitos No-funcionales, modelo de procesos, enfoque orientado al producto.

1. INTRODUCCIÓN Los Requisitos No-funcionales (RNF) establecen el marco de restricciones que determinan el desarrollo y aprovechamiento de los productos. La ingeniería 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 científico y tecnológico. De esta manera se establece una relación entre los atributos de los productos y sus procesos con los enfoques de ingeniería que los soportan. Este desafío impulsa el desarrollo de la Ingeniería de Requisitos. En el campo de la Ingeniería de Software, trabajos pioneros como los desarrollados por [1, 4, 19], captan la dependencia que tiene la calidad del producto respecto a la especificación de sus requisitos. Muchos métodos de análisis y diseño de sistemas, considerando el tratamiento de los requisitos, que surgieron en los años 90, han evolucionado, y aún tienen vigencia, por ejemplo los trabajos de [2, 6, 10, 13, 17, 18, 24]. Desde sus orígenes se advierte la presencia de los atributos no directamente operacionales o No-funcionales, por ejemplo en [5], pero el desarrollo de las soluciones estaba más centrado en las funcionalidades del

130

Sección 3 se introduce el concepto de Ingeniería Concurrente (IC) y la adopción de un modelo de procesos para este enfoque con base en los RNFs de dicho modelo. La conclusión y los trabajaos futuros son tratados en Sección 4. Los reconocimientos y las referencias constituyen las dos últimas secciones. 2. EXPLOTACIÓN DE LOS RNFs EN ELABORACIÓN DE PRODUTOS El estudio de requisitos es inherente al desarrollo de cualquier tipo de producto en todos los sectores de la economía. Los conceptos del desarrollo industrial se trasladan a productos con menos contenido material como son los productos de la Ingeniería 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 Líneas de Productos o Familias de Aplicaciones desarrollados en la Ingeniería de Software constituyen hoy en día un campo de desarrollo conjunto con los sectores empresariales. En la Ingeniería de Software, la elaboración de productos con base en el ciclo de vida considera en la fase de conceptualización dos etapas: la definición y el análisis del producto. En la etapa de análisis se parte del estudio de requisitos para llegar al modelado lógico del producto, centrando el estudio de requisitos en el proceso. Algunos métodos propuestos en [14, 25], entre otros, basan su estrategia de obtención 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 características del producto. Las primeras utilizan los modelos de dominio, como son, de una parte, los enfoques que emplean modelos jerárquicos de conceptos del dominio, como son las ontologías [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-Asociación [7]. Las segundas, que ya se reconocen en algunos enfoques arquitectónicos, constituyen un campo en cual se requieren mayores esfuerzos de investigación. Si bien, los requisitos No-funcionales se consideran en muchas metodologías, no se toman en general junto con el modelo del producto como el punto de partida para construir el modelo lógico de la solución. En la presente investigación se elaboraron algunos modelos para la construcción de soluciones en diversos campos, tales como el manejo de conocimiento en currículos de ingeniería y el tratamiento de riesgos en los procesos de la cadena de innovación de productos. En el manejo de conocimiento académico se describen a continuación dos experiencias.

2.1 Modelo de Conocimiento para Construcción y Evolución de un Currículo El modelo de conocimiento para soportar la construcción y evolución de un currículo debe plasmar en éste las características que se espera tenga el programa de formación 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 currículo de ingeniería. La construcción y evolución de un currículo es un proceso en el cual existen las etapas de entrada, de transformación y de salida. La caracterización del modelo de construcción y evolución del currículo 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 evolución de un currículo de ingeniería a partir de los RNFs de dicho currículo. Se concibe el proceso en tres etapas: entrada, transformación, y salida. Se adopta para el proceso un modelo lingüístico, donde la entrada está constituida por causas o antecedentes determinados por la expresión ¿Por qué? La transformación o realización responde a las expresiones ¿Qué? y ¿Cómo? La salida o consecuencia está determinada por la expresión ¿Para qué? Al aplicar estas preguntas al modelo de conocimiento del currículo, 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 evolución de un currículo con los atributos enunciados en dicha tabla. Estos conceptos están representados en la Figura 1.
Tabla 1. Requisitos de un modelo de conocimiento para construcción y evolución de un currículo de Ingeniería

A manera de ejemplo, el requisito 1 guía el descubrimiento de los conceptos modelo curricular y propósitos de formación. Las necesidades sociales y los problemas que dan origen al programa son identificados mediante el Requisito 2. El Requisito 3 determina el concepto conocimiento extraacadémico. Los Requisitos 3, 4, y 9 dan origen a los conceptos áreas generales de conocimiento, áreas de conocimiento específico, unidades temáticas, estrategias didácticas. El concepto de

131

competencias personales proviene del Requisito 7. El Requisito 8 determina el concepto dimensiones de formación. Los Requisitos 5, 6, 10 y 11 contribuyen al concepto conocimiento académico externo, y al concepto conocimiento extra-académico.
Es fuente de

Los conceptos de la Figura 1 condensan el conocimiento que debe manejarse en la construcción y evolución de currículos de ingeniería basados en problemas y orientados por competencias.

Sociedad
Fundamentación Epistemológica, Pedagógica, Filosófica, Psicológica
Áreas del conocimiento

Conocimiento extraacadémico
Permite definir

Conocimiento académico Interno y Externo
Aportan

Estructura
Poseen Aporta

Método
Requieren Caracterizan Permiten afrontar

Aporta Nutren

Dimensiones de formación: ser, saber, hacer, comportarse

Problemas
Generan

Áreas temáticas de referentes (ACM, IEEE, ECAES, ACOFI, ING-UDEA, Asociaciones, Universidades)
Se sintetizan en

Nutren

Orientan

Competencias por UOC y dimensión de formación
Definen Desarrollan

Satisfacen

Soporta

Unidades de Organización Curricular (UOC)
Se concretan en

Determinan Conforman

Propósitos de formación con dimensiones de formación

Modelo pedagógico

Unidades Temáticas y Estrategias didácticas

Áreas Temáticas Profesionales propias, su relación con los propósitos y dimensiones de formación , los conceptos requeridos de cada Área

Fig. 1: Conceptos para la Construcción y evolución de un Currículo de Ingeniería

2.2 Introducción del Concepto de Sostenibilidad en un Currículo La adaptabilidad de los currículos debe permitir la incorporación de nuevos conceptos en los currículos existentes. La introducción en la propuesta de “desarrollo sostenible” en currículos de ingeniería, parte de la adopción de una taxonomía de requisitos Nofuncionales que el currículo 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, económica, y del medio natural. En la Tabla 2 aparecen las categorías de Requisitos Nofuncionales adoptadas para el descubrimiento de los nuevos conceptos que tendrían que introducirse o precisarse en el modelo curricular de la Figura 1, para orientar los currículos hacia el desarrollo sostenible. Los requisitos dieron lugar a la incorporación de nuevas situaciones dentro de los problemas. En torno a los problemas surgieron nuevas preguntas que debía 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 propósitos de formación a partir de los cuales se determinan y organizan los contenidos curriculares y las competencias.
Tabla 2. Taxonomía de Requisitos de Sostenibilidad

2.3 Introducción de los Conceptos Multi-disciplina, Concurrencia y Colaboración en un Currículo Para la elaboración de un currículo de ingeniería que incorpore los conceptos de la Ingeniería Multidisciplinaria Concurrente y Colaborativa se estableció un modelo de RNFs descrito en la Tabla 3. Tres categorías de RNFs componen el modelo: aspectos técnicos, intervención humana, y ciclo de vida. En la primera se identifican los requisitos: independencia del lugar y de la plataforma, tiempo real, facilidades de comunicación y de medios. En la categoría de intervención humana se encuentran accesibilidad, pensamiento sistémico y trabajo en equipo. En relación con el ciclo de vida del producto se consideran los requisitos: multiplicidad de métodos y modelos, evolución de modelos, integración e interrelación de procesos actividades y decisiones.
Tabla 3. Requisitos de un Modelo Curricular de Ingeniería que incorpore Conceptos de Multi-disciplina, Concurrencia y Colaboración

132

Dentro de varias estrategias para la incorporación de nuevos conceptos en un currículo 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 amplían los problemas originalmente identificados para ser atendidos por el programa de ingeniería. En torno a los problemas se formulan preguntas sobre cómo 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 ingeniería debe responder en términos de sus propósitos de formación. En esas preguntas se introducen los nuevos conceptos que se quieren incorporar al currículo: multi-disciplina, concurrencia y colaboración. 3. MODELO DE REPRESENTACIÓN DE PROCESOS DE LA INGENIERÍA CONCURRENTE (IC) Las exigencias para el modelado de los procesos bajo el enfoque de la Ingeniería Concurrente parten de la definición de esta forma de afrontar la realización 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-innovación de productos y en el análisis y tratamiento de los riesgos en estos procesos definimos la Ingeniería Concurrente como un enfoque de gestión orientado a la obtención oportuna de productos de calidad, en una configuración integral, y dinámica de procesos, actividades, y acciones interrelacionados, secuenciales y/o no-secuenciales, simultáneos y/o diferidos, paralelos y/o convergentes, expresados a diversos niveles de abstracción; y considerando responsabilidades, objetivos, decisiones, y operaciones de agentes internos y/o externos. La Tabla 4 contiene las características (RNFs) esperadas de un modelo de procesos de la Ingeniería Concurrente de acuerdo con la definición precedente de este enfoque.
Tabla 4. Requisitos de un modelo de representación de procesos para la Ingeniería Concurrente

Para satisfacer los mencionados RNFs es preciso adoptar un modelo de procesos que los haga visibles y logrables. Del análisis de los RNFs se observa que el modelo de representación de procesos debe centrarse en agentes interactuantes, y, expresar y soportar dinámicamente las operaciones para las cuales se aplica este modelo. Determinar la participación de los agentes en los enfoques de ingeniería, en este caso en la Ingeniería 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 modificación 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 ejecución en procesos, actividades, y acciones, (d) la priorización y armonización de decisiones y objetivos generales, así como también de decisiones y metas particulares de los agentes, (e) desagregación de servicios, procesos, y actividades, (f) reconfiguración 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 operación de entrada, de la (b) a la (f) son de transformación, y la (g) y la (h) son operaciones de salida.

Fig. 2: Modelo de representación de procesos de IC

Estas capacidades del modelo se aprecian en la Figura 2. En efecto, los nodos en línea continua representan agentes internos a una organización, en tanto que los nodos en línea punteada son externos. Una entidad es considerada un agente al ejercer como responsable en una intervención. Las intervenciones son acciones o interacciones. Un agente es el responsable de una acción autónoma o de una interacción con otro agente. Las múltiples trayectorias entre nodos son intervenciones de agentes que van desde el agente responsable de la intervención hacia el agente interactuante. Las

133

intervenciones de agentes pueden expresar acciones, actividades, procesos, o servicios, los cuales constituyen cuatro niveles de abstracción. En el nivel de abstracción mayor la intervención del agente expresa un servicio, en el nivel siguiente expresa un proceso, en el que sigue expresa una actividad, y en el nivel de abstracción más bajo expresa una acción. La acción la realiza un agente autónomo, que no admite agente interactuante, sobre un objeto del más bajo nivel, en una estructura jerárquica 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 abstracción, la libertad de inicio y terminación, la simultaneidad, el paralelismo, la repetición de las intervenciones de los agentes; la disponibilidad espacio temporal de los agentes, sus decisiones, situaciones y los medios que utilicen son características 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 elaboración y entrega oportuna de un producto novedoso de alta calidad. La exteriorización de la participación de los agentes en los procesos de la Ingeniería Concurrente, expresada en las ocho operaciones de entrada, transformación, 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 participación de los agentes en un enfoque de ingeniería a partir de los RNFs que lo caracterizan. El producto que en este caso buscamos, es un modelo ajustado a las características de la IC, expresadas en los RNFs, en el cual se hace explícita la forma de participación de los agentes. 4. DISCUSIÓN En los casos descritos en las dos secciones anteriores se le da preponderancia a los RNFs, en busca de un modelo lógico del producto que se quiere desarrollar. En los objetos tangibles, estos RNFs aparecen más explícitos y directamente conectados con sus funcionalidades, un poco diferente a lo que ocurre con los objetos intangibles donde su manifestación 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 carácter más simbólico y aparecen múltiples opciones de objetos con las mismas funcionalidades, diferenciándose 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 irrupción de la tecnología 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 Ingeniería 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 tecnologías de la información y las comunicaciones, la globalización de la economía, y el crecimiento demográfico, se crea un contexto en el cual la innovación 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 métodos tradicionales que conducen a la elaboración del modelo lógico y al de diseño con base principalmente en los Requisitos Funcionales. En la actualidad se evidencian otros caminos para el surgimiento de los productos y servicios, como la invención o descubrimiento de objetos mediante la percepción de una oportunidad o mediante elaboraciones mentales conducentes a la definición de un producto o servicio sin haber establecido de antemano una necesidad. Esta aproximación al producto centra la atención en los RNFs. Otra aproximación al producto se basa en la identificación 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 están orientadas a la solución en vez de centrarse en el problema como hacen los métodos tradicionales: Los enfoques basados en el producto constituyen una vía alterna a la del proceso para llegar a las funcionalidades. Esto nos posibilitó elaborar modelos conceptuales por cada una las vías o combinando ambas, así como también proponer modelos para probar y validar soluciones obtenidas por vías alternas. Por otro lado, las vías alternas para las soluciones tienen vigencia cuando no es factible tener simultáneamente el conocimiento completo del producto y del proceso. Cada una de estas vías es una opción cierta para construir la solución, dando lugar a métodos ágiles fundados en un conocimiento pertinente, estructurado, y referido a la totalidad de la solución. Esto constituye un avance respecto a la forma como se establece el conocimiento inicial para la aplicación de un método ágil. Sobre estas bases es posible proponer nuevos métodos ágiles orientados al manejo de conocimientos más estructurado. Las investigaciones sobre los RNFs contribuyen a fortalecer la opción de desarrollar métodos y obtener objetos actuando más en función de la solución que del problema. 5. CONCLUSIÓN Y TRABAJO FUTURO En estas elaboraciones sobre los RNFs como punto de partida para la construcción de un producto se muestra

134

el carácter activo y determinante que tienen estos requisitos. Los métodos que se ocupan de la elaboración del modelo conceptual, y de diseño de un producto tangible, por su carácter concreto aprovechan de forma la directa visibilidad y expresividad de la orientación hacia el producto. El carácter más abstracto de los servicios y dentro de estos los sistemas informáticos han dado lugar al empleo de métodos orientados al proceso. Otros métodos combinan ambas orientaciones, así como también los productos involucran elementos tangibles e intangibles. Las máquinas e instrumentos modernos, por ejemplo, cada vez incorporan más elementos que implementan funciones lógicas. Nuevos métodos son requeridos para el análisis y el diseño de estos productos. La ingeniería de requisitos, estimulada desde la Ingeniería del Software, se extiende hacia los productos mixtos e influencia los métodos empleados en la industria. En los métodos empleados en la Ingeniería de Software predomina la orientación al proceso y con estos se ha desarrollado la Ingeniería 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 más amplio para aplicar convenientemente la orientación al proceso y al producto. Es necesario más trabajo de investigación en los métodos orientados al producto y a la combinación de ambas orientaciones. Mucho trabajo se realiza actualmente en modelos y métodos relacionados con RNFs como una de las vertientes de la orientación producto. En este campo se ubica el presente trabajo. Algunos enfoques de ingeniería, por ejemplo, la Ingeniería Concurrente combina las miradas del proceso y del producto en busca de una colocación rápida de los productos novedosos en manos de los consumidores. En los ejemplos descritos en la Sección 2 y en la propuesta de un modelo de representación de procesos, en la Sección 3, se muestran las grandes posibilidades que ofrece la orientación al producto, particularmente la consideración de los RNFs. En todos los casos, con diferentes medios se completó la caracterización del producto en términos de los RNFs, con los servicios que el producto ofrece, su razón 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 introducción de nuevos conceptos en un currículo de ingeniería, basados en problemas de los contextos social y organizacional, se optó por ampliar los problemas para cubrir las demandas implicadas por la introducción de los RNFs asociados a los nuevos conceptos adicionados. Frente a los problemas surgieron nuevas preguntas sobre cómo el currículo los puede atender considerando los nuevos

conceptos. Las respuestas aportaban a los propósitos de formación del programa, que son los servicios que el currículo se propone lograr con estudiantes. En los otros dos casos relacionados con la elaboración 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 currículo de ingeniería, se utilizó un modelo lingüístico expresando la entrada del proceso en términos de causas (¿Por qué?), la transformación o realización (¿Qué?, ¿Cómo?), y la salida en términos de efectos o consecuencias (¿Para qué?). En el caso del modelo de representación de procesos de la Ingeniería Concurrente se formularon directamente, a partir de los RNFs del modelo de representación de procesos de la IC, las operaciones de entrada, de transformación, y de salida que soporta el modelo propuesto. La doble vía, 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 aplicación eficaz de métodos ágiles para el análisis y el diseño, así como la evolución de modelos en las fases de análisis y de diseño. Estos trabajos se continuarán en las fases de la cadena de innovación de productos y en el análisis y tratamiento de riegos en esa cadena, bajo diferentes enfoques de ingeniería. Los trabajos de modelado del dominio, considerando los RNFs del producto y los servicios que éste soporta, se continuarán en el marco de las Líneas 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 (REFSQ’03), 2003. Dowson, M. & Fernström, 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 ICSE’2002, 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. Evolución de currículos de Ingeniería hacia la sostenibilidad. XXXIX Conferencia Nacional de Ingeniería: la educación en ingeniería para el desarrollo sustentable. Irapuato. México, 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 aproximación al concepto de ontología. Tecnológicas, 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 metaontología para la educción de requisitos. Revista Chilena de Ingeniería, 18(1), 26-37, 2010.

136

From Requirements to Code: Model-Driven Software Development in Practice De Requisitos a Código: Desarrollo de Software Dirigido por Modelos en Práctica
Óscar Pastor López
Centro de Investigación PROS, Universitat Politècnica de València. Valencia, España 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 España

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 servirán para la generación automática de software, permitiendo así una fácil adopción de metodologías de requisitos en un entorno industrial. De este modo, el diseño y/o adaptación de métodos de requisitos en entornos de DSDM le da un papel más activo a los modelos de requisitos dentro del proceso de desarrollo de software, más allá de ser solo parte de la documentación del sistema. Esta presentación tiene como objetivo principal generar un debate en torno a los retos que envuelve el desarrollo de software dirigido por modelos en la práctica. En el Centro de Investigación PROS se ha desarrollado una propuesta que busca unir técnicas avanzadas de ingeniería de requisitos y modelado conceptual. Como caso práctico, la integración de Análisis de Comunicaciones —un método de modelado de procesos de negocio orientado a la comunicación— y OO-Method —un método de desarrollo de software dirigido por modelos orientado a objetos— es un aporte que ilustra el uso de métodos y herramientas. De este modo el marco aprovecha herramientas para el soporte de modelado como Eclipse y se emplean técnicas de meta-modelado y transformación de modelos que en la actualidad es promulgado por la academia y la comunidad de ingeniería de software. Palabras clave Desarrollo de software dirigido por modelos, análisis de comunicaciones, OO-Method, reingeniería de procesos de negocio, modelado de procesos de negocio. General Terms Management, documentation, languages, design.

1. INTRODUCCIÓN Los sistemas organizacionales requieren métodos de especificación de requisitos para identificar las necesidades y características de los procesos de negocio. Las prácticas de ingeniería de requisitos han permitido involucrar a los usuarios en el proceso de desarrollo de software, lo cual permite la corrección temprana de errores y el índice de aceptación del producto final se ve incrementado [1]. Incorporar técnicas avanzadas de ingeniería de requisitos en la industria ha sido un reto que la comunidad de ingeniería de software reconoce, y en el cual diversos grupos de investigación se han dedicado a proponer soluciones y estrategias para afrontar la dificultad de transferencia tecnológica a entornos de producción 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 generación de productos software de forma automática 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 técnicas de ingeniería de requisitos a la industria. En la práctica 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 especificación de necesidades y requerimientos del sistema, pueden ser usados para derivar de ellos los modelos conceptuales enfocados al diseño del software. Los modelos conceptuales resaltan e incrementan la importancia de los modelos de requisitos en un entorno industrial. De este modo, la especificación 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 código del software es trazable con los modelos del sistema [2]. De este modo, para llevar a la práctica el uso de técnicas avanzadas de ingeniería de requisitos en ámbitos industriales, la academia debe diseñar y/o adaptar los métodos de ingeniería de requisitos para que éstos sean compatibles con entornos de DSDM. Un marco genérico para adaptar métodos de ingeniería de requisitos existentes en ambientes de DSDM ha sido desarrollado

137

en el Centro de Investigación PROS [3]. Como caso práctico, se han realizado todos los pasos del marco para integrar Análisis de Comunicaciones —un método de modelado de procesos de negocios orientado a la comunicación— [4] y OO-Method —Un método 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 integración de requisitos a código. Durante la presentación, se discutirán las ventajas del uso de métodos como Análisis de Comunicaciones en entornos de DSDM y su integración con OO-Method. Adicionalmente, se discutirá la importancia del uso de meta-modelos para dar soporte a la integración de dichos métodos en entornos de DSDM y otras aplicaciones prácticas como el mantenimiento de sistemas legados, reingeniería y evolución de modelos. 2. ANÁLISIS DE COMUNICACIONES Y OO-METHOD: DE REQUISITOS A CÓDIGO Los sistemas organizacionales requieren métodos de captura y especificación de requisitos para identificar las necesidades y características intrínsecas de sus procesos de negocio. Analizar el Sistema de Información desde una perspectiva comunicativa es necesario, debido a que los procesos y actores del sistema son observados en un mismo nivel de abstracción. Adicionalmente, las perspectivas comunicativas permiten analizar el sistema de información desde un punto de vista centrado en el cómo se comunica la información, como ésta es intercambiada, cómo evoluciona y es enriquecida. Análisis de Comunicaciones es un método de ingeniería 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 información. OO-Method es un método de DSDM, cuyos modelos conceptuales se encuentran soportados por Integranova, un compilador de modelos que permite la generación automática de código ejecutable [6]. La unión de los modelos de requisitos de Análisis de Comunicaciones y los modelos conceptuales de OOMethod se encuentra guiada a través de un alineamiento ontológico entre ambos métodos y una serie de reglas de transformación de modelos. Dicha integración metodológica se encuentra descrita en [7]. Proporcionando herramientas de modelado y motores de transformación de modelos, el paso de requisitos a código es automático. 3. TÉCNICAS DE METAMODELADO Y HERRAMIENTAS Los modelos de requisitos de Análisis de Comunicaciones se encuentran conformados por el Communicative Event Diagrams (CED) y las Message Structures (MS). CED es una técnica de modelado de procesos de negocio a través de la cual es posible especificar aspectos dinámicos y estáticos del sistema

de información. MS es una técnica de análisis y diseño de las interacciones comunicativas de sistemas de información. Teniendo en cuenta los conceptos de los modelos de CED y MS, la sintaxis abstracta es definida mediante técnicas de meta-modelado. Siguiendo una aproximación de arquitectura dirigida por modelos (ADM) [8] y teniendo en cuenta que un meta-modelo es un modelo, la aproximación de ADM puede ser tenida en cuenta para la especificación de conceptos de métodos de requisitos. De este modo, un meta-modelo independiente de plataforma (PIM) para los modelos de requisitos de Análisis de Comunicaciones es adecuado para la especificación de conceptos y relaciones sin tener en cuenta el soporte tecnológico de los modelos del método. La principal ventaja de mantener un meta-modelo PIM para el método, es brindar la posibilidad de análisis de la especificación del método con expertos y diseñadores los cuales pueden modificar y evolucionar el método a nivel de modelos sin necesidad de tener en cuenta aspectos tecnológicos. 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 tecnológicos y de la plataforma destino sean tenidos en cuenta. Para el caso particular de Análisis de Comunicaciones, la plataforma de desarrollo de Eclipse ha sido tenida en cuenta [9]. Tecnologías como EMF, GMF y ATL han sido las plataformas sobre las cuales han podido ser implementados los modeladores gráficos para CED y MS. Las reglas de transformación de modelos de Análisis de Comunicaciones a los modelos de OO-Method es soportado a través de la plataforma ATL de Eclipse.

METAMODELO PIM 1.0 CONCEPCIÓN EJEMPLOS ILUSTRATIVOS time

VALIDACIÓN INTERNA

METAMODELO PIM 2.0

VALIDACIÓN EXTERNA

METAMODELO PIM 3.0

2 EJEMPLOS DE LABORATORIO ENTREVISTAS CON EXPERTOS EN AMBOS MÉTODOS

EJERCICIO DE EVALUACIÓN DE USABILIDAD (UPV) EN HERRAMIENTA DE MODELADO EJERCICIO DE EVALUACIÓN DE EXPRESIVIDAD (UPV)

METAMODELO PIM 1.0 METAMODELO BÁSICO CON CONCEPTOS, ATRIBUTOS, RELACIONES Y CARDINALIDADES

METAMODELO PIM 2.0 NUEVOS CONCEPTOS Y RELACIONES, CORRECCIÓN DE ERRORES Y CONFLICTOS DEFINICIÓN DE REGLAS OCL PARA REPRESENTACIÓN DE RESTRICCIONES

METAMODELO PIM 3.0 CONCEPTOS Y RELACIONES REESTRUCTURADAS. SOPORTE PARA MS MEDIANTE EDITOR TEXTUAL Y ÁRBOL JERÁRQUICO

Fig. 1: Línea de tiempo de desarrollo del meta-modelo PIM para los modelos de requisitos de Análisis de Comunicaciones

La Figura 1 representa la línea de tiempo de desarrollo del meta-modelo PIM de los modelos de requisitos de Análisis de Comunicaciones. Una primera versión fue desarrollada donde los conceptos principales del método fueron tenidos en cuenta y una serie de ejemplos ilustrativos fueron desarrollados. Una validación interna fue llevada a cabo con expertos de ambos métodos para evaluar que los conceptos, relaciones, atributos y cardinalidades representen las características de cada aproximación. Finalmente, se llevó a cabo una validación externa con un grupo de estudiantes de máster de la Universitat

138

Politècnica de València. Dichos estudiantes tienen un perfil cercano a un analista de sistemas de información. Los resultados de la evaluación permitieron la mejora y desarrollo de nuevos conceptos y relaciones que dieron lugar a una versión 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 módulos de modelado y motor de transformación de modelos. 4. CONCLUSIONES La posibilidad de integrar métodos de ingeniería de requisitos en ambientes de DSDM ha motivado diferentes líneas de investigación en el área de ingeniería de software. Por esta razón, el debate alrededor de posibles soluciones para involucrar la especificación de requisitos en el proceso de desarrollo de software abre diversas ventanas de discusión. Análisis de Comunicaciones es un método de ingeniería de requisitos que ofrece una perspectiva para analizar sistemas de información desde el punto de vista comunicativo, permitiendo observar el sistema desde un punto de vista estático y dinámico. Debido a la diversa cantidad de información que puede ser analizada y diseñada siguiendo las guías de uso del método, le convierte en un método de especificación de requisitos potencialmente adaptable en un entorno DSDM. Por este motivo, como caso práctico se ha llevado a cabo la integración, y un soporte tecnológico con herramientas tecnológicas que son idóneas para el desarrollo de entornos de modelado y transformación de modelos. En la actualidad, se está explorando la posibilidad de incorporar técnicas de reingeniería organizacional dirigida por modelos para dar soporte a la evolución de los modelos de requisitos. Dicha evolución 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 Informáticos y Computación (DSIC), Universitat Politècnica de València, València, 2011. [4] España, 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] España, S. Methodological integration of Communication Analysis into a Model-Driven software development framework. PhD. Computer Science, Departamento de Sistemas Iformáticos y Computación (DSIC), Universitat Politècnica de València, 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 Brasília Brasília D.F., Brazil

Mauricio Ayala-Rincón 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 verification 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 specification in order to verify that an improved version of the originally given specification is also correct requires a great deal of effort 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 specifications that are obtained basically changing data structures. The case of study is a specification of the well-known Dolev-Yao cryptographic model in which the characterization of security was formalized in the proof assistant PVS. The given formalized specification was based on the representation of sequences of cryptographic operators via a data structure of finite sequences. The “improvement” consists of a specification in which lists will be used instead finite 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 modified, usually requires rebuilding proofs from scratch. As an example, consider the following specification 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]: Specification techniques; F.4.1 [Mathematical Logic]: Proof theory; D.2.4 [Software/Program Verification]: Formal methods

Keywords
Specification and verification, 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) = l‘length 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 specification and verification 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 specification of lemma search_works since the function nth is typed as nth : [l: list[nat], j: below[l‘length]] -> 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(x−1 ) = − 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 × x−1 = 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 suffix and array trees. Consequently, adopting other data structure will imply the development of new specialized formalizations according to the chosen data structure of the modified specification. Here, a formal discipline based on construction of isomorphism functors is proposed in order to reuse formalizations when different 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 specification, 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 specifier is able to reuse formalizations previously constructed for the specification based on the original data structure.

2.

BACKGROUND

Mathematically, isomorphisms are defined 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 × x−1 = exp ◦ ln(x × x−1 ), by Lemma isomorphism 2; 2. exp ◦ ln(x × x−1 ) = exp(ln(x) + ln(x−1 )), 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 specificities 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 specifications 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 definition 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 finite family of sorts, say {τ1 , . . . , τn }; F is a finite 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 finite 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 define 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 definition of isomorphism can be stablished. Definition (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 specifies 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 first step of

142

A, F , R A∈A f ∈F

ı x → ıA (x) f → fı

/ B, G, P /B∈B / fı ∈ G

ı(f (x1 , . . . , xm )) = f ı (ı(x1 ), . . . , ı(xm )) p∈R
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 specification 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 finite sequences. A finite 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 specified 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 s‘length = 0 THEN null ELSE cons(s‘seq(0), ı(s(1, s‘length - 1)) ENDIF MEASURE seq‘length 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 first 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) s‘length = 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 finite sequence, say s. This is done through calls of the form s‘seq(k). By the elaborated typing discipline of the PVS specification language, whenever the type of k is different from [0..length-1], the term s‘seq(k) is ill-typed. The question of arises, from several algorithmic perspectives and different programer’s point of views, whether this is the better style to specify chains of cryptographic operators. And according to the efficiency necessities (e.g., either reducing running time or space) and different programming styles, alternative data structures can be chosen instead finite sequences. For instance, instead finite sequences, ADTs as lists of CryOp can be used. list[CryOp] In the PVS specification 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

s‘length → length(ı(s))

s‘seq → λ(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 ı(s‘length) = length(ı(s)) Lemma A2 ı(s‘seq) = λ(i:[1,s‘length]) .nth(i, ı(s)) Lemma A3 ı(s‘seq(k)) = (λ(i:[1,s‘length]) .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,s‘length]) .nth(i, ı(s)))ı(k) →β (λ(i:[1,s‘length]) .nth(i, ı(s)))(k + 1) →β nth(k + 1, ı(s)), thus, by lemma A3, ı(s‘seq(k)) = nth(k + 1, ı(s)). On the other side, lists are isomorphically transformed into sequences through the following specified 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 s‘length = 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 first 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 finite 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 specification of the Dolev-Yao model over lists. In general, the availability in a proof assistant of several libraries about isomorphisms between different alternative data structures is of great usability in order to adapt specifications to other data structures, different 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 definitions; 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 suffix trees and suffix 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):198–208, 1983. [2] R. Nogueira, F. de Moura, A. Nascimento, and M. Ayala-Rinc´n. 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 Verification System. In D. Kapur, editor, 11thInt. Conf. on Automated Deduction (CADE), volume 607 of LNAI, pages 748–752, 1992. Springer. [4] Y. Rˆgo and M. Ayala-Rinc´n. 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 Verificación y Validación independiente para asegurar mayor confianza en el software que controla sistemas críticos
Patricia Rodríguez Dapena1
1

Softwcare S.L.. Vigo, España. rodriguezdapena@softwcare.com. RESUMEN Cada vez son más los productos software que son críticos (incluyendo el software que controla sistemas críticos) y de los que depende nuestro día a día, e incluso que si fallan podría 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 más estrictos cuanto más crítico sea el producto software. La verificación y validación independiente del producto software (ISVV) (que es complementaria a sendos procesos que realiza el desarrollador del software) se identifica como método a ser utilizado para ayudar también al aseguramiento de la confianza en el producto software crítico, aunque no es todavía un ‘método’ muy extendido en los diferentes sectores. Este artículo presentará las características más importantes de los procesos de ISVV, además de resultados de experiencias y medidas de la efectividad de este ‘método’ en el sector espacial europeo.

INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación: ___ Reflexión: _X__ Revisión: ___ Historia del artículo: 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. INTRODUCCIÓN Cada vez son más los productos software que son críticos (incluyendo el software que controla sistemas críticos). Es decir, de los que nuestro día a día depende, e incluso que si fallan, nos pueden matar. No sólo el software que controla el ABS o la dirección asistida en un automóvil, ni el software de control en aviones o trenes, si no el software de los teléfonos móviles, de sistemas de comunicación pueden llegar a ser críticos cuando se utilicen para, por ejemplo, un S.O.S. o una cirugía 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 máximo no tener fallos que sean la causa de efectos catastróficos o críticos. 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 más estrictos cuanto más crítico 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 más o menos rigor según la criticidad del producto a ser desarrollado: a) Se requiere que la gestión 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 estándares 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 después de que implemente, se verifican estas implementaciones. Esto se exige, por ejemplo, en el sector de la automoción, a través de la aplicación de la norma ISO/IEC 26262 [2] para la seguridad funcional (léase ‘functional safety’) de los vehículos rodados. También se exige en casi todas las demás normas en otros sectores, por ejemplo, la IEC 62304 [8] para los procesos de ciclo de vida del software para dispositivos médicos, o para el software de control en aviones según 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 señalización de trenes (EN50128 [4]), etc. b) Se requiere que ciertas actividades se realicen independientemente, sobretodo actividades de calidad, de safety, de verificación y validación (pruebas). Cuanta más criticidad, más actividades serán realizadas con independencia. Por ejemplo, las tareas de análisis de seguridad en cada etapa del desarrollo se debe realizar independientemente para el software crítico para el sector de la automoción, la señalización de trenes, sistemas espaciales, etc. Las tareas de verificación y pruebas se deben realizar independientemente en el sector del software crítico para la señalización de trenes [4], el software de control en aviones [3], etc. c) Se requiere la verificación de la cobertura estructural y de requisitos de las pruebas que se realicen al producto crítico, y, por ejemplo, se exige el 100% de cobertura de todas las sentencias, y de todas las decisiones que haya en el código fuente del producto software crítico. Esto se exige en el sector del software crítico para la señalización de trenes [4], el software de control en aviones [3], para el

software en automoción [2], en sistemas espaciales [6] [7], etc. d) Se requiere el uso de métodos para el desarrollo, verificación, pruebas, etc. del producto más exigente cuanto más crítico sea el producto. Una tabla ejemplo de estas exigencias es la siguiente:
Tabla 1 — Methods for the verification of requirements
Métodos ASIL ASIL ASIL ASIL A B C D 1a Verificación Informal a través de ++ + 0 0 ‘walkthrough’ 1b Verificación Informal a través de + ++ ++ ++ inspección 1c Verificación Semi-formala + + ++ ++ 1d Verificación Formal 0 + + + a El método 1c se puede ayudar por modelos ejecutables. ISO/IEC 26262-6 [2]

La tabla anterior proviene de la normativa en el sector automoción (donde ASIL D es el nivel más crítico y es para el que se exige utilizar métodos más rigurosos - ++ ‘highly recommended’). Existen tablas y requisitos similares en todos los demás sectores: software crítico para la señalización de trenes, el software de control en aviones, para el software en sistemas espaciales, etc. e) Se requiere el uso de métodos para definir e insertar en el diseño 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 verificación y validación independiente del producto software se identifica como método a ser utilizado para ayudar también al aseguramiento de la confianza en el producto software crítico, aunque no es todavía un ‘método’ 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 realización de las actividades de verificación y validación independientemente, sino que se trata de la realización de actividades de verificación y validación extras y complementarias, que estresen el producto, y realizadas por una organización independiente ‘no contaminada’ por los desarrolladores originales. A continuación se presentará una introducción de estas actividades y sus objetivos en el sector espacial europeo. Después se presentarán casos reales de realización, de los cuales se podrá deducir directamente el beneficio de este tipo de ‘métodos’, aunque, ‘a priori’, parezca caro y que complica la gestión del proyecto. 2. VERIFICACIÓN Y VALIDACIÓN INDEPENDIENTE DE SOFTWARE (ISVV) Como con cualquier actividad de verificación y validación, el objetivo de ISVV es encontrar fallos y aumentar la confianza en el producto software. ISVV debe aportar un valor añadido sobre la verificación y validación llevada a cabo por el desarrollador de software. Tiene que ser complementaria, por lo que deberá tener diferentes: - Los objetivos, - Procesos, - Los métodos, - 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 dedicarán especial atención a las actividades manuales de verificación y validación del proveedor de SW (por ejemplo, el realizados del ISVV también podría realizar verificaciones automáticas de código utilizando herramientas diferentes a las utilizadas por el proveedor del SW). En la Figura 1 se presentan los procesos de ISVV:
MAN. Gestión MAN.PM. Proceso de Gestión de ISVV MAN.VV. Definición del Nivel de ISVV IVE. Verificación Independente IVE.TA.Análisis de Requisitos Software IVE.DA.Análisis del Diseño IVE.CA. Análisis de Código IVA. Validación Independiente IVA.Validación

roles, responsabilidades, planificación, presupuesto y estimaciones, comunicación, 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 Gestión de ISVV

El proceso de definición del nivel de ISVV (MAN.VV) es de apoyo al de Gestión y tiene como objetivo limitar el alcance, sobretodo en el uso de los métodos propuestos para realizar los diferentes procesos de verificación y de validación. ISVVL 0 significa que para ese producto no se requiere ISVV, y ISVVL 2 es el más estricto. El nivel de ISVV se identifica combinando la criticidad del software (cuanto más criticidad –SCC- mayor nivel de ISVV) y otros factores del desarrollo que pueden influencias la introducción 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 diseño y tecnologías del producto a ser desarrollado, el tamaño y (des-)localización del equipo de desarrollo, la complejidad del producto, etc.). A mayor ‘potencial de error’ mayor Nivel de ISVV.
Tabla 3. Tabla de definición 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 Gestión del proceso de ISVV (MAN.PM) se ocupa de cuestiones tales como la identificación de los

148

estas tareas (TAR) por parte del cliente del ISVV, donde puede filtrar, re-clasificar o aclarar los ‘findings’ encontrados en esta verificación. • Análisis de Diseño (IVE.DA), que es la verificación del diseño de software de arquitectura, del diseño detallado de software, y del Manual de usuario. La actividad finaliza con una revisión de estas tareas de verificación (DAR).
Tiempo
Desarrollo de software

• Análisis de código (IVE.CA), que es la verificación del código fuente del software, junto a la verificación de las pruebas unitarias y de integración del software realizadas por el desarrollador del software. La actividad finaliza con una revisión de estas tareas (CAR). El proceso de Validación >Independiente (IVA) consiste en probar del software para estresar que la aplicación cumple con las especificaciones técnicas de una manera robusta y que se conocen los límites del comportamiento del mismo y que si falla ante los mismos, se conocen los efectos y están 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 revisión de los resultados de esta validación independiente (IVR).

SRR

PDR

CDR

QR

Requisitos y Arquitectura Diseño detallado e implementación Validation Verification Entrega y aceptación

TA
ISVV

DA CA
Validación 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 verificación del código (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 métodos 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 Guía de ISVV [1]. Se identifican cuáles 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). Además, en los ejemplos de la tabla 5, la Guía [1] menciona los métodos a ser utilizados para cada una de las sub-tareas, identificando cuáles utilizar para los diferentes niveles de ISVV. En la tabla 5, el uso del método de Ingeniería Inversa sólo se utilizará para realizar las sub-tareas IVE.CA.T1.S4 (para verificar la consistencia de los interfaces entre las diferentes unidades/módulos del código) y la IVE.CA.T1.S5 (para verificar la correctitud del código fuente respecto a los requisitos y diseños) Los resultados de la realización de las actividades de ISVV, como de las actividades de verificación y validación 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 cómo se transmiten estos ‘findings’ normalmente en proyectos espaciales: 3. EXPERIENCIAS Y CASOS REALES 3.1 Definición de la efectividad del ISVV El ISVV es un ‘método’ de obligado cumplimiento para el desarrollo de software crítico (niveles A – máximo nivel- y B) en sistemas espaciales, tanto en Europa como en NASA. A priori parece costoso, introduce complejidad en la organización y gestión del proyecto y su efectividad resulta difícil medir. La organización de estos proyectos suele ser más compleja, más cara pues hay que contratar a otro proveedor para realizarlas, además de que los ‘findings’ y comentarios del ISVV llegan al proveedor del software ya avanzado el proyecto de desarrollo, refiriéndose a correcciones de resultados de fases ya pasadas y que repercutirán además en cambios en toda la cadena de resultados posteriores (ej. ‘findings’ en los requisitos, supone cambios posibles en el diseño y en el código que ya se están desarrollado). Hasta el momento, la efectividad de la utilización de este método no se ha cuestionado pues: se compensa nada más encontrar y corregir un sólo fallo severo que ya no cause un efecto catastrófico o crítico durante el uso del sistema (pues esto sí resultaría de un costo incalculable). Encontrar inconsistencias en los tipos de datos de interfaz entre componentes críticos (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 razón del ISVV en los proyectos. Pero, tras la realización de bastantes proyectos de ISVV en diferentes proyectos espaciales, se ha querido medir cuantitativamente la efectividad de los mismos. Por tanto, se contrató la realización de un proceso de medidas y su análisis 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 verificación 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 debían de recolectar para medir la efectividad, tras analizarse que sólo se podía estudiar la efectividad de los procesos de verificación independiente. No se podrían obtener datos comparables de los procesos de validación de los diferentes proyectos (asunto a ser corregido en el futuro en los proyectos ISVV). Además, tampoco se iban a poder obtener datos de esfuerzos ni costes dedicados a los diferentes procesos y tareas, por lo que los análisis a ser obtenidos sería solamente basados en el número de ‘findings’ y en su tipología y eficiencia. Se recolectaron y analizaron datos de 15 proyectos ISVV, de sendos 15 productos software críticos 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 habían finalizado hace años) por lo que el análisis 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%

verificación y validación, siempre es mejor poder utilizar herramientas (maduras) que soporten el análisis y las inspecciones, pues además de ayudar a realizar las tareas y actividades más rápidamente, 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 sólo estos totales per sé no proporcionan ninguna información acerca la efectividad de las tareas de ISVV. Había que analizar los ‘findings’ que tuvieran un efecto de cambio y corrección en el software crítico: estos son los efectivos. La figura siguiente muestra que la mayoría de los ‘findings’ encontrados originaron una necesidad de corrección en el software crítico. Incluso se comparó cuál era esta proporción respecto al tamaño del producto (productos grandes, medianos o pequeños) o al tipo de producto (producto de tipo aplicación o tipo sistema operativo o SW de bajo nivel), y siempre la mayoría 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 semiautomáticamente 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 Guía 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. Más aspectos identificados en este proyecto de medida de la eficiencia de los procesos ISVV es la identificación de subtareas de las que no se han identificado ningún ‘finding’ en ninguno de los proyectos evaluados. Como consecuencia, en caso de tener que reducir en número de sub-tareas a realizarse, esas serían las primeras a descartarse. Además, puede que la razón de no encontrarse ningún ‘finding’ sea por que la Guía no la defina adecuadamente o que sea difícil de realizar. 4. CONCLUSIONES Y TRABAJOS FUTUROS Tras analizarse diferentes aspectos sobre la eficiencia de los procesos de ISVV en los proyectos, la conclusión 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 realización de estos procesos de ISVV. Además, se ha demostrado que no importando el tipo de producto, el proyecto, el tamaño, 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 habían recolectado como tales durante su realización). Para ello se deberá utilizar la plantilla fija e idéntica para todos los proyectos a ser proporcionada por el Cliente del proyecto ISVV). - Sí es importante corregir el hecho de que sólo para el 3% de ‘findings’ se utilizaron herramientas (especialmente en

Figura 7. ‘Findings’ efectivos [9]

Pero de nuevo surge la necesidad de ahondar más en cuál 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 número de ‘findings’ por tipo de severidad, y cuáles 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 según su severidad [9]

Aunque la mayoría de ‘findings’ de cada tipo han sido efectivos, la figura 8 anterior nos muestra que la mayoría de ‘findings’ efectivos es de tipo ‘menor’, o sea, fallos que no presentan un problema importante aunque deberían ser corregidos (ver la Tabla 6 anterior). De todos modos, la cantidad de fallos clasificados como importantes (‘major’) era también 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 Análisis de código CA). Se debe revisar la Guía [1] para aclarar mejor la posibilidad del uso de herramientas para la realización de las diferentes tareas, y no sólo recomendar los métodos 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 Guía [1] para aclarar mejor estas sub-tareas. 5. AGRADECIMIENTOS Este trabajo de medición 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. Rodríguez-Dapena. Final Presentation. ISVV Metrication Analysis. 2011. ISVV cost effectiveness Metrication project.

153

MEDELLÍN 2012