UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería de la Computación Pregrado en Ingeniería de la Computación

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería de la Computación Pregrado en Ingeniería de la Computación PROPUESTA DE UNA HERRAMIENTA PARA EL ANÁLISIS Y DISEÑO DE SISTEMAS DESARROLLADA EN SOFTWARE LIBRE Trabajo de Grado presentado a la Universidad Simón Bolívar por Orlando Rafael Alfonzo Subero Como requisito parcial para optar por el grado de Ingeniería de la Computación Realizado con la tutoría del Profesor Kenyer Piadaktay Domínguez Martínez Enero 2008

2 2

3 Dedicatoria A mis padres y mi hermana, porque sus sonrisas de satisfacción por este logro, hacen que valga la pena el esfuerzo. 3

4 AGRADECIMIENTOS GRACIAS a Dios, por regalarme una vida tan maravillosa, por acompañarme siempre, por brindarme un abrazo caluroso todas las noches y por rodearme de seres humanos únicos que me motivan a luchar por un mundo diferente. GRACIAS a mis padres, por creer en mí, por orientarme, por enseñarme a defender lo que pienso, por no dejar que me rindiera, por hacerme la persona que soy. GRACIAS a Patricia, por reírse de mis locuras, por su apoyo y por motivarme a hacer las cosas correctas para convertirme en el ejemplo que ella merece. GRACIAS a mi abuela Milena, por su ejemplo de perseverancia, positivismo y lucha. Por su eterno amor y por regalarme una familia excepcional. GRACIA a Miriam, por su amor, su amistad, su paciencia inagotable, su testimonio de vida y su apoyo incondicional. Por soportar mis locuras y reír conmigo. GRACIAS a January, por su acompañamiento, por su visión y corazón cristianos, por sus consejos, sus regaños, su comprensión y su apoyo. GRACIAS a mis tíos y tías, por el cariño y el orgullo que siempre han sentido por mí. Por darme ejemplo de que en la diversidad de pensamientos se encuentra la riqueza de la sociedad. GRACIAS infinitas a la CVX, por darme calor de familia, por enseñarme que un hombre sí puede hacer la diferencia, por mostrarme la calidad de seres humanos que podemos llegar a ser todos. Por comprometerme con quien realmente lo necesita y por permitirme entrar en sus tierras sagradas. GRACIAS a mis amigos de toda la vida, por ser tantos y tan constantes. Especialmente a Mario, por acompañarme siempre en los momentos más especiales y por formar parte de mis mejores recuerdos; a Johan, por su amistad incondicional y por ser para mí un ejemplo contemporáneo de enteraza, esfuerzo, nobleza e idealismo; a Darwin, por su amistad, por su buen humor y sus ganas de sonreír y hacer las cosas más sencillas, por su ejemplo de determinación y su cariño y por darme una sobrina tan hermosa a quien también le doy las gracias. A Rosa, Lisangel, Isina, Yéseri, Amira y sus familias, por su respeto y cariño. GRACIAS eternas a Jaime, por abrirme las puertas de un mundo mágico y mostrarme mi verdadera pasión de vida, el teatro. Por su amistad y sincera compañía. Por sus ganas de soñar y hacer realidad esos sueños. Por escucharme cuando lo necesité, apoyarme y tener a la mano un consejo y una idea fresca. Por permitirme contar entre mis hermanos a un ser humano admirable. 4

5 GRACIAS a la familia Feliu por abrirme siempre la puerta de su casa, por recibirme con tanto cariño y por hacerme sentir uno más de la familia. GRACIAS a mi querido Amarillo #5. Sin ti no sería posible dar hoy estas gracias. Por liberarme de ataduras psicológicas y emocionales, por enseñarme lo que es entregarse en corazón y mente a un sueño. Por lo aplausos. Por las hermosas amistades que me diste. Por esa mano que me dio fuerzas para continuar. GRACIAS a mi amado HORUS TEATRO, por mantener la llama viva, por esa energía creadora y emprendedora que me hace sentir niño de nuevo y hacerme creer que puedo lograr cualquier cosa. GRACIAS a mis tutores. A Kenyer Domínguez por su dedicación, paciencia, apoyo y respuesta oportuna. A la profesora María Angelica Ovalles, por su profesionalismo e invalorable aporte académico. Al profesor Luis Mendoza por su capacidad de ver siempre la pieza que falta. A la profesora Maryoly Ortega por su consejo y visión integral del proyecto. Al profesor Lornel Rivas por su constancia y atención. GRACIAS a la profesora Sandra Rodríguez, por devolverme la fe en mi mismo, mostrarme que si podía lograrlo y recordarme que soy capaz de hacer grandes cosas. GRACIAS a la UCV, a mis profesores y amigos de Comunicación Social, por convertirse en el motor que me impulsó en la recta final. 5

6 INDICE 1. Introducción Planteamiento del problema Problema...11 Delimitaciones Objetivos del proyecto...12 Objetivo General...12 Objetivos específicos Justificación Marco Teórico Análisis y Diseño de sistemas Análisis de sistemas Diseño de sistemas Vistas del diseño AyD en los modelos de procesos Ciclo de vida clásico Construcción de prototipos El modelo en espiral Modelo orientado a la reutilización AyD en los enfoques de desarrollo Enfoque estructurado Enfoque orientado a objetos Enfoque Web Enfoque orientado a componentes Enfoque orientado a aspectos AyD en distintas metodologías de desarrollo Unified Process (UP) Rational Unified Process (RUP) OpenUP y EPF Extreme Programming (XP) Scrum Feature Driven Development (FDD) Dynamic System Development Method (DSDM) Microsoft Solutions Framework (MFS) WATCH El Lenguaje Unificado de Modelación (UML) Herramientas CASE Definición y objetivos de las herramientas CASE Clasificación de herramientas CASE

7 3.3. Free Libre Open Source Software (FLOSS) El Modelo de Proceso de Desarrollo para Software Libre FLOSS y el Constructivismo Análisis de antecedentes Modelo Sistémico de Calidad (MOSCA) Marco Metodológico Framework metodológico Enfoque basado en Objetivos, Preguntas y Métricas GQM Propuesta de instanciación de MOSCA Modelo conceptual Resumen de las características de MOSCA tomadas para la instanciación Instanciación de MOSCA Aplicación de la instanciación Herramientas sujetas a evaluación Resultados de la aplicación Análisis de resultados y selección de la herramienta Implementación de las nuevas funcionalidades para StarUML Descripción del proceso de desarrollo de mejoras para StarUML Conclusiones, recomendaciones y logros adicionales...96 Referencias Bibliográficas...98 ANEXO I. Aplicación de la instanciación de MOSCA a 8 herramientas evaluadas ANEXO II. Módulos implementados ANEXO III. AyD de Sistemas según los Modelos de Proceso, Enfoques y Metodologías de Desarrollo, Orientados a Desarrollos en Software Libre. Resumen del trabajo presentado en la LVII Convención Anual AsoVAC ANEXO IV. Quality Measurement Model for Analysis and Design Tools based on FLOSS. Artículo aceptado por la 19th Australian Software Engineering Conference (ASWEC 2008) ANEXO V. Taxonomía de los Diagramas en UML ANEXO VI. Modelo Sistémico de Calidad MOSCA

8 ÍNDICE DE TABLAS Tabla nº 1. Vistas de diseño propuestas por la IEEE (2004)...17 Tabla nº 2. Descripción y actividades básicas de las vistas de diseño...19 Tabla nº 3. AyD en los modelos de proceso...23 Tabla nº 4. AyD en los enfoques de desarrollo...28 Tabla nº 5. Pasos para el AyD en los enfoques de desarrollo...28 Tabla nº 6. AyD en las metodologías de desarrollo...35 Tabla nº 7. Artefactos y roles de AyD en las metodologías de desarrollo...36 Tabla nº 8. Tipos de licencia FLOSS...42 Tabla nº 9. Similitudes entre modelos consolidados para el desarrollo de software y el proceso de desarrollo para FLOSS...44 Tabla nº 10. Modelos económicos de Software Libre propuestos por Ubuntu...45 Tabla nº 11. Puntos de encuentro entre Constructivismo y FLOSS...47 Tabla nº 12. Categorías y características para medir la calidad sistémica del producto de software...50 Tabla nº 13. Fases de la metodología Investigación Acción propuesta...53 Tabla nº 14. Nuevas sub características y métricas de la categoría Funcionalidad...66 Tabla nº 15. Nuevas sub características y métricas de la categoría Usabilidad...68 Tabla nº 16. Nuevas sub características y métricas de la categoría Mantenibilidad..68 Tabla nº 17. Relación entre el modelo conceptual y las nuevas sub características..70 Tabla nº 18. Herramientas seleccionadas a evaluar...71 Tabla nº 19. Resultados de la evaluación...73 Tabla nº 20. Métricas de la sub - característica Diagramas...77 Tabla nº 21. Métricas de la sub - característica Interoperabilidad...78 Tabla nº 22. Métricas de la sub - característica Consistente...79 Tabla nº 23. Métricas de la sub - característica Capacidad de cambio...81 Tabla nº 24. Métricas de la sub - característica Estabilidad...81 Tabla nº 25. Criterios para evaluar el instrumento...88 Tabla nº 26. Cuestionario para evaluar el módulo StarUML-WAEClass...89 Tabla nº 27. Cuestionario para evaluar el módulo StarUML-WAESequence

9 ÍNDICE DE FIGURAS Figura nº 1. Modelo del ciclo de vida clásico...20 Figura nº 2. Modelo de creación de prototipos...21 Figura nº 3. Modelo en espiral...22 Figura nº 4. Desarrollo orientado a la reutilización...23 Figura nº 5. Niveles de contribución en las comunidades de desarrollo FLOSS...43 Figura nº 6. Matriz global sistémica de Callaos y Callaos...49 Figura nº 7. Framework metodológico para el trabajo de grado...52 Figura nº 8. Niveles del enfoque GQM...55 Figura nº 9. Modelo conceptual general...57 Figura nº 10. Modelo conceptual de AyD y modelos de proceso...58 Figura nº 11. Modelo conceptual de AyD y enfoques de desarrollo...59 Figura nº 12. Modelo conceptual de AyD y metodologías de desarrollo...60 Figura nº 13. Modelo conceptual de los tres niveles de abstracción...61 Figura nº 14. Instanciación de MOSCA para herramientas de AyD...65 Figura nº 15. Resultados de la evaluación de la categoría Funcionalidad...74 Figura nº 16. Resultados de la evaluación de la categoría Usabilidad...74 Figura nº 17. Resultados de la evaluación de la categoría Mantenibilidad...75 Figura nº 18. Sub características de Funcionalidad para StarUML...76 Figura nº 19. Sub características de Mantenibilidad para StarUML...80 Figura nº 20. Agregar un nuevo diagrama...85 Figura nº 21. Elaboración de diagrama WAE de clases con el nuevo módulo...86 Figura nº 22. Elaboración de diagrama WAE de secuencia con el nuevo módulo...87 Figura nº 23. Respuestas a la pregunta 1 del instrumento de evaluación para el módulo StarUML-WAEClass...90 Figura nº 24. Respuestas a la pregunta 2 del instrumento de evaluación para el módulo StarUML-WAEClass...90 Figura nº 25. Respuestas a la pregunta 3 del instrumento de evaluación para el módulo StarUML-WAEClass...91 Figura nº 26. Respuestas a la pregunta 4 del instrumento de evaluación para el módulo StarUML-WAEClass...91 Figura nº 27. Respuestas a la pregunta 5 del instrumento de evaluación para el módulo StarUML-WAEClass...92 Figura nº 28. Respuestas a la pregunta 1 del instrumento de evaluación para el módulo StarUML-WAESequence...92 Figura nº 29. Respuestas a la pregunta 2 del instrumento de evaluación para el módulo StarUML-WAESequence...93 Figura nº 30. Respuestas a la pregunta 3 del instrumento de evaluación para el módulo StarUML-WAESequence...93 Figura nº 31. Respuestas a la pregunta 4 del instrumento de evaluación para el módulo StarUML-WAESequence...94 Figura nº 32. Respuestas a la pregunta 5 del instrumento de evaluación para el módulo StarUML-WAESequence

10 CAPÍTULO 1. INTRODUCCIÓN A partir de 1980 se comenzó a utilizar el término era de la información para hacer referencia al período histórico comprendido entre el fin de la era industrial y el comienzo de la economía del conocimiento, fundamentada actualmente por las tecnologías de la información y la comunicación. Durante este período, administrar la información de manera eficiente y efectiva, se convirtió en un requisito ineludible, en principio para las grandes industrias y, ya en la actualidad, para la pequeña y mediana empresa. Este amplio rango de organizaciones se ha encontrado con la necesidad de aprender y aprehender nuevos recursos que les permitan adquirir y transformar información para generar conocimiento. Las empresas que producen software no están fuera de este rango, más aún, son estas organizaciones las que se enfrentan con mayor preocupación a la problemática de cómo sistematizar el proceso de construcción de software, que a su término les permitan a otras organizaciones, sistematizar sus procesos informáticos. Aquí radica la importancia de la ingeniería de software como área de estudio y campo de conocimiento. En tal sentido, lograr establecer un proceso de construcción de sistemas que culmine en un producto que satisfaga realmente las necesidades originarias de los clientes y usuarios, implica analizar un amplio conjunto de variables que hacen de este un problema complejo. Más aún, cuando el auge de tecnologías y de los desarrollos de Software Libre y de código abierto, construyen las bases de un mercado altamente competitivo en donde la calidad del software se convierte en una de las exigencias con mayor prioridad. El Análisis y Diseño (AyD) de sistemas, aparece en este panorama como una estrategia garante de la calidad de los productos de software, en tanto posibilita la construcción de aplicaciones de forma ordenada, paso a paso y orientada hacia un desarrollo de causas y efectos, suprimiendo las potenciales acciones fortuitas que caracterizaban a los procesos de desarrollo en los que la codificación era el primer paso. Son muchas las herramientas que soportan el AyD de sistemas, que existen en el mercado, tanto privadas como de libre acceso y distribución. Y cada día la tendencia es a buscar herramientas que a partir de un buen diseño y análisis, generen al menos, el cuerpo básico de las aplicaciones. Pero los procesos de desarrollo son variados y no se conoce una herramienta que tenga planteado cubrir, sino todas, buena parte de las variantes de procesos, enfoques, metodologías o lenguajes. De igual manera, tampoco se conoce la existencia de un modelo que permita evaluar la calidad de herramientas de AyD. Ante este desconocimiento y ante la importancia del AyD de sistemas, surge el presente proyecto de investigación acción. En las próximas páginas se presenta el producto de una investigación teórica en torno al AyD de sistemas, las herramientas que lo soportan, el Software Libre como filosofía constructivista de desarrollo y la evaluación de la calidad sistémica de algunas herramientas de Software Libre que soportan el AyD. Como producto de esa investigación teórica, se inicia la mejora de un software con estas características, que permita acercarnos a la herramienta ideal. 10

11 CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA En este primer capítulo, se exponen los aspectos que delimitan el presente proyecto. Se plantea el problema génesis de la investigación, seguido de sus limitaciones, el objetivo general y los objetivos específicos que se persiguen en este trabajo y, finalmente, la justificación Problema El Análisis y Diseño (AyD) de sistemas es parte del conjunto de actividades de la ingeniería de software y el modo de su ejecución depende de múltiples variables relativas a las características del proceso de desarrollo. En el mercado, existen herramientas privadas y de Software Libre que soportan el AyD de sistemas desarrollados según un modelo de proceso, enfoque, metodología, lenguaje de modelado, etc. No se conoce una herramienta que integre estas modalidades y permita realizar el AyD, independientemente de las características del proceso. Delimitaciones Son diversos los aspectos que caracterizan un proceso de desarrollo de software, y numerosas las herramientas que existen actualmente en el mercado para soportar el AyD de sistemas. Por esta razón es necesario delimitar el conjunto de características del proceso de desarrollo que serán tomadas en cuenta para estudiar el AyD, así como también especificar las características de las herramientas que se tomarán como referencia para elaborar la propuesta. En tal sentido, se presentan los límites de este trabajo de investigación: Las características del proceso de desarrollo que serán tomadas en cuenta para estudiar el AyD y para integrarlas en la propuesta, serán: el modelo de proceso, el enfoque de desarrollo y la metodología de desarrollo empleada. Para elaborar la propuesta, se trabajará sobre una herramienta disponible en el mercado y se modificará en función de los objetivos del trabajo de investigación y de los resultados obtenidos del proceso de evaluación de varias aplicaciones. Las herramientas candidatas a ser mejoradas serán herramientas basadas en Software Libre. La evaluación de las herramientas candidatas se realizará con el Modelo Sistémico de Calidad (MOSCA), fundamentado en el estándar ISO Será modificada la que resulte con mayor nivel de calidad. La propuesta resultante del trabajo de investigación soportará el AyD de sistemas, integrando algunos de los modelos de proceso, enfoques de desarrollo y/o metodologías de desarrollo. 11

12 2.2. Objetivos del proyecto Objetivo General Desarrollar una propuesta de herramienta que soporte el AyD de sistemas, a partir de herramientas basadas en Software Libre existentes actualmente y que dicha propuesta, recopile mejoras sobre las características de herramientas analizadas. Objetivos Específicos Realizar una investigación documental de tópicos y conceptos relacionados a AyD de sistemas, Software Libre, herramientas de desarrollo y metodologías. Producir un modelo conceptual que reúna los conceptos existentes en la literatura sobre AyD y su relación con los modelos de proceso, enfoques de desarrollo y metodologías de desarrollo. Generar una instanciación del Modelo Sistémico de Calidad (MOSCA) que permita evaluar la calidad de herramientas de Software Libre que soporten AyD de sistemas. Evaluar un conjunto de herramientas de Software Libre que soporten AyD de sistemas y seleccionar la que resulte con mayor nivel de calidad. Realizar aportes o mejoras funcionales a la herramienta seleccionada, a partir de las debilidades encontradas Justificación El AyD de sistemas constituye una de las disciplinas más importantes en la ingeniería de software. La experiencia de diversos desarrollos, han mostrado que la inversión de recursos en el análisis y el diseño de un software, garantiza una menor inversión durante las etapas de implementación y una mayor y mejor satisfacción de los requerimientos iniciales y, en consecuencia, de los clientes. Por otra parte, el Software Libre gana popularidad rápidamente entre los dueños de pequeñas y medianas empresas, para quienes la inversión en una plataforma tecnológica que agilice los procesos de producción, en este caso de software, es tan prioritario como costoso si se trabaja con software propietario. Las necesidades que motivan la construcción de software son cada vez más diversas, y exigen que los procesos de desarrollo se implementen según uno u otro modelo de proceso, enfoque o metodología. Además, el factor calidad se convierte en una exigencia prioritaria, en un mercado cada vez más competitivo. En el siguiente capítulo, se exponen los aspectos teóricos que son necesarios manejar, en torno al AyD de sistemas, a herramientas que soportan etapas del desarrollo de software y al Software Libre, para generar una propuesta que cumpla con los objetivos de este trabajo. 12

13 CAPÍTULO 3. MARCO TEÓRICO El Análisis y Diseño (AyD) de sistemas, como parte del conjunto de actividades, disciplinas y prácticas de la ingeniería de software (IS), dependen de las características del proceso de desarrollo, y su ejecución requiere, por parte de analistas y diseñadores, un compendio de recursos conceptuales que les permita tomar las decisiones correctas y orientar la construcción de los sistemas, hacia el logro de productos finales que cumplan con determinados estándares de calidad. De forma análoga, para desarrollar una herramienta que soporte el AyD, es necesario fundamentar este desarrollo con elaboraciones teóricas propuestas por algunos autores en torno a la IS. En tal sentido, se exponen a continuación los resultados de una investigación documental respecto del tema. En primer lugar, se ofrece una panorámica que muestra algunas definiciones generalizadas de conceptos que son necesarios manejar para comprender y justificar el enfoque que se ha dado a este marco teórico y su estructuración. Posteriormente, se comparan definiciones propuestas por distintos autores sobre el AyD de sistemas. Una vez descrito el contexto teórico básico que enmarca la investigación, se propone un estudio del AyD, abordándolos desde tres niveles de abstracción diferentes. En primera instancia se ubicará el AyD en los distintos modelos de proceso que orientan la ejecución en el tiempo del desarrollo de sistemas. En segundo lugar, se comparará la forma en que los distintos enfoques de desarrollo entienden y asumen el AyD. Finalmente, el tercer nivel, corresponde a las metodologías, es decir, se estudiará cómo distintas metodologías de desarrollo proponen llevar a cabo el AyD. Ahora bien, la herramienta que se pretende proponer con este proyecto coincide con las características de las herramientas CASE, por lo cual se hace necesario comprender qué es la ingeniería de software asistida por computadora, cuáles son los objetivos que se persiguen con estas herramientas, qué tipos de aplicaciones CASE existen y cuáles son las características básicas que deben tener para soportar un proceso de desarrollo que culmine en un producto de calidad. Este es el contenido de la segunda parte de esta fundamentación teórica. Se desea construir una herramienta que cumpla con determinados estándares de calidad, por lo cual también se estudiarán algunos modelos de calidad que permitan cumplir con este objetivo. Por último, serán expuestos algunos principios y definiciones de Software Libre y código abierto, puesto que el producto final del proyecto debe cumplir con estas características AyD de Sistemas El AyD se ha convertido en un conjunto fundamental de actividades para las primeras etapas del desarrollo de sistemas, en tanto tiene el propósito de analizar sistemáticamente la entrada o el flujo de datos, procesar o transformar datos, el almacenamiento de datos y la salida del sistema que se desee construir, modificar o mejorar (Kendall y Kendall, 2005). En la IS se ha hecho necesario contar con metodologías, métodos y herramientas que permitan definir conceptualmente el proyecto, para que la implementación de los sistemas 13

14 esté encaminada hacia la satisfacción de las necesidades que motivaron el proceso de construcción o reconstrucción del software. La tendencia en esta área de desarrollo, es hacia entender y asumir el AyD como una disciplina, es decir, realizar las actividades propias a esta etapa del desarrollo con rigurosidad, orden y siguiendo lineamientos y estándares técnicos, de lenguaje, etc., que formalicen el proceso de conceptualización inicial. Las actividades de esta disciplina no tienen que ser llevadas a cabo de manera secuencial, en general es posible que algunas se desarrollen simultáneamente, por eso suele abordarse la disciplina como un todo. Sin embargo, es posible estudiar por separado las actividades que corresponden al análisis y las que corresponden al diseño, y esta será la forma en que se profundizará en sus detalles. Por otra parte, durante la investigación documental tras esta exposición escrita, se han distinguido tres niveles en los que se puede estudiar el AyD. Estos son: AyD en los modelos de procesos, AyD en los enfoques de desarrollo y AyD según las metodologías de desarrollo. Una vez presentado el contexto, corresponde iniciar el estudio detallado de la disciplina de AyD. Como se indicó en la sección anterior, este estudio se realizará por separado; primero se expondrá el análisis de sistemas a partir de las definiciones ofrecidas por varios autores y posteriormente se utilizará la misma estrategia para discutir lo referente al diseño Análisis de sistemas La primera etapa de la disciplina que compete a este estudio, es la del análisis, en la cual se define el dominio del problema (Monarchi, 1992). A continuación se comparan varias definiciones, ofrecidas por distintos autores, sobre análisis de sistemas: El análisis de sistemas es una técnica de resolución de problemas que descompone un sistema en sus partes componentes, con el propósito de estudiar cómo deben trabajar e interactuar éstas partes en conjunto, para que el sistema cumpla con su propósito (Whitten et al., 2007). El análisis del sistema es una actividad que engloba la mayoría de las tareas que se han llamado colectivamente ingeniería de sistemas basados en computadora. Algunas veces se incurre en confusión porque el término se usa a menudo en un contexto que alude sólo a las actividades de análisis de los requisitos del software. El análisis se centra en todos los elementos del sistema (Pressman, 2005). Para Rational Unified Process, el propósito del análisis es la transformación de los requerimientos del sistema en un mapa que represente un conjunto de clases y subsistemas; en otras palabras, el análisis se enfoca en el manejo de los requerimientos funcionales del sistema (Kruchten, 2000). 14

15 Las tres definiciones citadas anteriormente coinciden en que el análisis de sistemas involucra el estudio de las partes que componen o compondrán el sistema que será modificado o construido como un todo integrado y funcional. Además de asumir que el insumo de este estudio son los resultados de una primera etapa de levantamiento de requerimientos; sin embargo, sólo en la definición ofrecida por Pressman (2005), se considera al análisis de requerimientos como parte de la disciplina de AyD. Esta idea, como veremos en la sección correspondiente a las metodologías, no está vigente para toda la comunidad especializada. Al comparar estas tres definiciones, se observa que al análisis se le ha entendido, en un caso como una técnica, en otro como una actividad y por último como un proceso de transformación. A la discusión se incluirán definiciones ofrecidas por Whitten (2007) y por Kendall y Kendall (2005), como parte de las ideas de metodología y ciclo de vida del desarrollo, respectivamente: Análisis de decisiones (Whitten et al., 2007): Dados los requerimientos del negocio, existen usualmente numerosos caminos alternativos para diseñar un nuevo sistema según esos requerimientos. El propósito de esta fase es identificar soluciones candidatas, analizarlas y recomendar un sistema candidato como la solución a ser diseñada. Los criterios para evaluar cada solución candidata son la factibilidad técnica, la factibilidad operacional, factibilidad económica, factibilidad de planificación y factibilidad de riesgos (Whitten et al., 2007). Análisis de las necesidades del sistema (Kendall y Kendall, 2005): involucra el uso de herramientas como los diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en forma estructurada, para facilitar la determinación de las condiciones, las alternativas de condición, las acciones y las reglas de acción. En este punto se prepara una propuesta de sistema, se proporciona un análisis de costo/beneficio de las alternativas y se ofrecen recomendaciones de lo que se debe hacer (Kendall y Kendall, 2005). Ambas definiciones coinciden en cuáles son los productos de la fase de análisis: una propuesta de sistema y una evaluación detallada de la factibilidad de su construcción. Ahora bien, existen distintas maneras de abordar el problema del análisis de los componentes, la identificación de las soluciones alternativas y la escogencia de una solución candidata como propuesta para el diseño. Esas maneras implican la aplicación de métodos bien específicos. La manera que compete considerar, según los objetivos de este proyecto, es aquella que aborde el análisis a través del modelado. El modelado consiste en diagramar una o más representaciones gráficas de un sistema. El desarrollo a través de modelos (MDD, Modeldriven development) es un conjunto de técnicas que se enfatizan en el diagrama de modelos que ayuden a visualizar y analizar problemas (Whitten et al., 2007). En secciones 15

16 posteriores se mostrarán cuáles modelos se utilizan para el análisis de sistemas, según el enfoque de desarrollo que se esté utilizando. En conclusión, las definiciones propuestas por los autores citados para análisis de sistemas, indiferentemente de que se le considere como etapa, técnica, etc., y los tipos de análisis propuestos particularmente por Whitten (de decisiones) y Kendall y Kendall (de necesidades), muestran aproximaciones teóricas diferentes pero objetivos fundamentales similares, resumidos en la obtención de un contexto bien definido de la problemática inicial que intenta resolver el desarrollo de un sistema y la elaboración de una propuesta de solución que permita iniciar el proceso de diseño del software. A continuación, se comparan distintas definiciones que se encontraron en la literatura para el diseño de sistemas Diseño de sistemas A diferencia del análisis, en el diseño de sistemas se define el dominio de la solución (Monarchi, 1992). Las siguientes, son construcciones teóricas sobre el diseño de sistemas, que han ofrecido varios autores: Es la especificación o construcción de una solución técnica basada en computadora, para los requerimientos del negocio especificados en la etapa de análisis (Whitten et al., 2007). Es el primer paso de la fase desarrollo de cualquier producto o sistema de ingeniería. Es el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realización física (Pressman, 2005). Es el proceso mediante el cuál se traducen los requerimientos, levantados en la fase de análisis del sistema, en una representación del software (Pressman, 2005). Es el proceso de definición de la arquitectura, los componentes, las interfaces y otras características de un sistema o componente, y el resultado de ese proceso (IEEE ). Visto como un proceso, el diseño de software es la actividad del ciclo de vida de la ingeniería de software en la cual los requerimientos son analizados, en función de producir una descripción de la estructura interna del software que servirá de base para su construcción. (IEEE - SWEBOK, 2004). Las definiciones citadas, consideran al diseño como una etapa o proceso en el que se especifica o representa un software, en función de los requerimientos que han sido recibidos previamente como insumo. Sin embargo, como en el caso del análisis, existen diferencias en tanto se le entiende, en el primer caso como una actividad, en el segundo como una fase, en el tercero como un proceso y en cuarto como proceso y producto a la vez. En este sentido se busca complementar la comparación, integrando las definiciones 16

17 que realizan de diseño, como una etapa, ya sea de la metodología de desarrollo en el caso de Whitten et al. (2007), o del ciclo de vida en el caso de Kendall y Kendall (2005). Diseño (Whitten et al., 2007): Una vez aprobado el sistema propuesto en la fase de análisis, se diseña el sistema. El propósito de esta fase es transformar los requerimientos de negocio en especificaciones de diseño para la construcción. Generalmente contempla tres vistas, la de datos, la de procesos y la de interfaces. Diseño del sistema recomendado (Kendall y Kendall, 2005): Se utiliza el resultado de las primeras fases para realizar el diseño lógico del sistema. La concepción de la interfaz de usuario forma parte del diseño lógico del sistema. Incluye también el diseño de archivos o bases de datos, los controles y procedimientos de respaldo que protejan al sistema y a los datos y producir paquetes de especificaciones de programa que contengan esquemas para la entrada y salida y detalles del procesamiento (Kendall y Kendall, 2005). Ambos grupos de autores coinciden en que el diseño contempla tres subconjuntos de actividades o tres diferentes vistas: datos, procesos e interfaces. Sin embargo se encontró en la literatura que autores como Pressman (2005) y Sommerville (2006) agregan una cuarta vista que corresponde al diseño arquitectónico. Estas cuatro vistas del diseño de sistemas son expuestas a continuación Vistas del diseño En SWEBOK, la IEEE (2004) afirma que se pueden describir y documentar diferentes facetas de alto nivel para el diseño de un software, y le llama a estas facetas vistas. Según la IEEE (2004) una vista representa un aspecto parcial de una arquitectura de software que demuestra características específicas de un sistema. Así algunos autores contemplan, en el diseño, las vistas lógica, de procesos, física y de desarrollo, mientras que otros consideran las vistas de comportamiento, funcional, estructural y de modelado de datos. Por esta razón la IEEE (2004) extiende la definición de diseño de sistemas, presentándolo como un artefacto de múltiples facetas, producto del proceso de diseño y compuesto por vistas relativamente independientes y ortogonales. En la tabla 1, se presentan las vistas que en particular propone la IEEE (2004), incluyendo las notaciones para la representación de los aspectos que contempla dentro de cada vista. Vista Estática: descripciones estructurales. Dinámica: descripciones de Notación Lenguajes de descripción de arquitectura. Diagramas de objeto y de clase. Tarjetas del colaborador de la responsabilidad de la clase Diagramas de despliegue Diagramas de Entidad Relación Lenguajes de descripción de interfaz Diagramas de Estructura de Jackson Cartas Estructuradas Diagramas de Actividad 17

18 comportamiento Diagramas de colaboración Diagramas de flujo de datos Diagramas y tablas de decisión Cartas de flujo y cartas de flujo estructuradas Diagramas de secuencia Diagramas de cartas de estado y transición de estados Lenguajes de especificación formal Lenguajes de diseño de programa y pseudo código. Tabla 1: Vistas de diseño propuestas por la IEEE (2004) Fuente: elaboración propia. Sin embargo, en la literatura se encontró, de forma más o menos generalizada, una división de las vistas del diseño que se presenta a continuación, como alternativa a la propuesta por la IEEE (2004). Esas vistas son las siguientes: Diseño de datos El proceso de diseño de datos ha sido resumido por Wasserman (1980): La actividad principal durante el diseño de datos es la selección de las representaciones lógicas de los objetos de datos (estructuras de datos), identificados durante la fase de definición y especificación de requisitos (Pressman, 2005). Diseño arquitectónico Los sistemas grandes siempre se descomponen en subsistemas que suministran algún conjunto relacionado de servicios. El proceso de diseño inicial para identificar esos subsistemas y establecer un marco de trabajo para el control y comunicación de los subsistemas se llama diseño arquitectónico y produce una descripción de la arquitectura del software (Sommerville, 2006). Los distintos modelos gráficos del sistema, muestran diferentes perspectivas de la arquitectura. Diseño procedimental El diseño procedimental se realiza después de que se ha establecido la estructura del programa y de los datos. En este proceso se deben especificar los detalles de los procedimientos sin ambigüedad (Pressman, 2005). El diagrama de flujo es la representación más ampliamente usada para el diseño procedimental. Sin embargo, UML propone una serie de diagramas que desglosan el comportamiento del sistema y muestran detalladamente cómo será la ejecución de los procedimientos. Diseño de la interfaz La interfaz hombre-máquina o interfaz de usuario es la puerta hacia aplicaciones interactivas. Su diseño requiere tanto de factores humanos como tecnológicos. Sin embargo, en la guía de SWEBOK de IEEE (2004), se señala que según el estándar IEEE/EIA para el ciclo de vida del desarrollo de software, el diseño consiste sólo de dos actividades que se ubican entre el análisis y la construcción del software. Esas actividades son: el diseño arquitectural del software, en donde se describe la estructura de alto nivel del software, su organización y se identifican sus componentes; y el diseño 18

19 detallado del software, en donde se describe cada componente suficientemente para su construcción. En la tabla 2, se resume la descripción y actividades básicas de cada una de las vistas de diseño expuestas anteriormente. Vista de diseño Descripción Actividades Básicas Diseño de datos Diseño arquitectónico Diseño procedimental Diseño de interfaz Selección de las representaciones lógicas de los objetos de datos Identificación de los subsistemas que componen el sistema más grande, sus mecanismos de control y de comunicación Especificación de los detalles de los procedimientos. Especificación de la interfaz de usuario Identificar las estructuras de datos y las operaciones que se pueden realizar sobre ellas Identificar las relaciones y las restricciones Elaborar un diccionario de datos Estructuración del sistema Modelado del control Descomposición modular Modelado del comportamiento del sistema Modelado de la ejecución de los procedimientos Modelado del usuario (identificación del perfil de los usuarios finales) Modelar la percepción del sistema o imagen mental que tienen los usuarios finales Modelar la imagen de la interfaz de usuario (pueden elaborarse prototipos) Tabla 2: Descripción y actividades básicas de las vistas de diseño. Fuente: elaboración propia. Análogo al análisis, el diseño también puede abordarse con MDD, más adelante serán expuestos los distintos modelos que soportan cada vista del diseño, según el enfoque de desarrollo que se utilice. Una vez enmarcada la investigación en el contexto del AyD de sistemas, se detallará la disciplina a través de tres aristas o niveles de abstracción, que permitirán profundizar el estudio. Seguidamente se hablará del AyD en los modelos de procesos, luego según los enfoques de desarrollo, y por último en distintas metodologías de desarrollo AyD en los modelos de procesos A partir de la idea de caracterizar el proceso de desarrollo a través del ciclo de vida, distintos autores han planteado diversos paradigmas desde los cuáles se puede abordar la construcción o reconstrucción de un software. Como producto de estos paradigmas se han puesto en discusión, teórica y pragmática, los modelos de procesos de desarrollo. Es de 19

20 interés para este proyecto ubicar la disciplina de AyD en distintos modelos de procesos, para obtener una visión general de la misma, que no se restrinja a una sola de las mencionadas abstracciones. Los modelos de proceso que se estudiarán, en su mayoría presentados por Pressman (2005), son el ciclo de vida clásico o modelo en cascada, la construcción de prototipos, el modelo en espiral y el modelo para desarrollos orientados a la reutilización, propuesto por Sommerville (2006). Para cada uno de los modelos se hará una descripción breve y se hará énfasis en las etapas del proceso que corresponden al AyD de sistemas Ciclo de vida clásico Algunas veces llamado modelo en cascada, exige un enfoque sistemático y secuencial del desarrollo, y contempla las 6 etapas que se observan en la figura 1. Define la etapa de análisis como la fase de análisis de los requerimientos del software (Pressman, 2005), integrando de esta manera actividades que, según otros acercamientos teóricos, corresponden a fases previas al análisis, como la recopilación específica de requerimientos para el software. Por otro lado, en este modelo se entiende al diseño como un proceso de múltiples pasos que se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. Este proceso traduce los requisitos en una representación del software (Pressman, 2005). Esta definición incorpora a la de los autores anteriores, la idea de una cuarta vista, la de la arquitectura del software. Ingeniería del sistema Análisis Diseño Codificación Prueba Mantenimiento Figura 1: Modelo del ciclo de vida clásico Fuente: Pressman, Construcción de prototipos Facilita la creación de un modelo del software a construir. Como se ilustra en la figura 2, no existe una fase de análisis entre la recolección de requerimientos y el diseño. Y se realiza un diseño rápido que se enfoca en la representación de los aspectos del 20

21 software visibles al usuario, conduce a la construcción de un prototipo que será evaluado con el usuario para obtener prototipos refinados (Pressman, 2005), podemos decir que el análisis ocurre a lo largo del desarrollo durante el proceso de continuos refinamientos de los prototipos. Comienzo Parada Recolección y refinamiento de requisitos Producto de ingeniería Diseño Rápido Refinamiento del producto Construcción del prototipo Evaluación del prototipo por el cliente Figura 2: Modelo de creación de prototipos Fuente: Pressman, El modelo en espiral Es otro modelo estudiado por Pressman en donde se cubren las mejores características del clásico y se utiliza la creación de prototipos. Los aportes de este paradigma es la concepción del desarrollo como proceso evolutivo incremental representado en forma de espiral y la inclusión del análisis de riesgos, en el cuál se analizan las alternativas. En el modelo no se detalla una etapa que reciba el nombre de diseño, sin embargo, cada vuelta alrededor del espiral requiere ingeniería, que se puede llevar a cabo mediante el enfoque del ciclo de vida clásico o de la creación de prototipos (Pressman, 2005). 21

22 PLANIFICACIÓN Determinar objetivos, alternativas y restricciones Costo acumulativo ANÁLISIS DE RIESGOS Identificar y resolver los riesgos Análisis de Riesgos Acercamiento para la siguiente iteración Resumen Partición Plan de la siguiente iteración EVALUACIÓN DEL CLIENTE INICIO Plan de requerimientos, plan del ciclo de vida Plan de desarrollo Integración y plan de pruebas Análisis de Riesgos Evaluar las Análisis de alternativas Riesgos Prototipo Operacional Análisis de Riesgos Prototipo 3 Prototipo 2 Prototipo 1 Concepto de operación Liberación Simulaciones Modelos Pruebas patrones Pruebas unitarias Integración y pruebas Pruebas de aceptación Figura 3: Modelo en espiral. Fuente: UM, 2007 Diseño detallado Código Desarrollar los entregables para la iteración y verificar que sean correctos INGENIERÍA Modelo orientado a la reutilización Otro autor, Sommerville, además de los modelos de ciclo de vida de sistemas expuestos anteriormente, ofrece uno con ciertas variaciones en las fases intermedias del proceso. Se trata del modelo para desarrollos orientados a la reutilización. Las fases se observan en la figura 4, y a continuación se definen las correspondientes a AyD: Análisis de componentes: dada la especificación de los requerimientos, se buscan los componentes para implementar esta especificación (Sommerville, 2006). Modificación de requerimientos: los requerimientos se analizan utilizando información acerca de los componentes que se van descubriendo. Entonces estos componentes se modifican para reflejar los componentes disponibles. Si las modificaciones no son posibles, la actividad de análisis de componentes se lleva a cabo nuevamente para buscar soluciones alternativas (Sommerville, 2006). Estas dos etapas corresponden a la parte de análisis de la disciplina de AyD. 22

23 Diseño de sistemas con reutilización: en esta fase se diseña o reutiliza un marco de trabajo para el sistema. Se toman en cuenta los componentes que se reutilizan y se organiza el marco de trabajo para que se ajuste a ellos. Si los componentes reutilizables no están disponibles, se diseña un nuevo software (Sommerville, 2006). Especificación de requerimientos Análisis de componentes Modificación de requerimientos Diseño de sistemas con reutilización Validación del sistema Desarrollo e integración Figura 4: Desarrollo orientado a la reutilización. Fuente: Sommerville, A modo de resumen, la tabla 3 compara los distintos modelos expuestos, en función de características relativas al AyD de sistemas dentro de cada modelo de proceso. Modelos del proceso Características Cascada Prototipaje Espiral Orientado a la reutilización Secuencial Estricto (Lineal) Evolutivo Incremental (Circular) Contempla una fase de análisis Análisis como conjunto de actividades, implícitas en otras fases del proceso Análisis incluye levantamiento de requerimientos Análisis incluye los riegos Evaluación del análisis antes de pasar a la siguiente fase Contempla una fase de diseño Diseño como conjunto de actividades, implícitas en otras fases del proceso Diseño incluye arquitectura detallada Diseño incluye interfaz detallada Diseño incluye estructura de datos detallada Diseño incluye especificación procedimental detallada Diseño rápido (aspectos del software visibles al usuario) Evaluación del diseño antes de pasar a la siguiente fase Tabla 3: AyD en los modelos de procesos. Fuente: elaboración propia. 23

24 Habiendo estudiado el AyD según se ubica en distintos modelos de procesos, corresponde considerar una segunda arista o nivel de abstracción, el de los enfoques de desarrollo de sistemas. Seguidamente se estudian distintos enfoques, en función del lugar que le dan al AyD de sistemas AyD según los enfoques de desarrollo La forma en que se oriente el desarrollo de un software, tiene relación directa con el lenguaje de programación que se utilizará durante la implementación y algunas características funcionales y no funcionales determinantes al momento de seleccionar la estrategia de construcción. Esta formas de orientar el proceso se tratarán en adelante con el nombre de enfoques de desarrollo. Esta sección pretende ubicar el análisis y el diseño en los siguientes enfoques de desarrollo: estructurado, orientado a objetos (OO), Web, orientado a componentes (OC) y orientado a aspectos (OA) Enfoque estructurado El enfoque estructurado aborda el desarrollo de sistemas desde el punto de vista de los procesos, entiende al sistema en construcción como una máquina a través de la cual fluye la información y ésta es modificada mediante una serie de procesos de transformación de ese flujo. En tal sentido, la abstracción que orienta el desarrollo mediante el enfoque estructurado, es la de flujo, y caracteriza la estrategia de modelado durante el AyD de sistemas. Los modelos utilizados para el AyD de sistemas con enfoque estructurado, son los diagramas de flujo de datos (DFD), tanto lógicos cómo físicos y de contexto. Análisis y diseño estructurado El análisis estructurado es una técnica centrada en procesos que se utiliza para analizar un sistema existente, definir requerimientos de negocio, o ambas. Como se desarrolla mediante modelado, en este caso los modelos son imágenes que ilustran las piezas componentes del sistema: procesos y sus entradas, salidas y archivos asociados. Introduce una herramienta de modelado llamado diagrama de flujo de datos (Whitten et al., 2007). Esta técnica permite modelar el flujo y el contenido de la información. Se representa el funcionamiento general del sistema como una única transformación de información (Pressman, 2005). Uno de sus objetivos es que los módulos resulten altamente cohesionados y poco acoplados. Al modelo de software derivado del diseño estructurado se le llama carta estructurada (Whitten et al., 2007) Enfoque orientado a objetos El enfoque orientado a objetos crea una representación del campo del problema del mundo real y la hace corresponder con el ámbito de la solución (Pressman, 2005). La abstracción que orienta el desarrollo a través de este enfoque, es la idea de objetos. Un objeto es aquello que tiene estado, comportamiento e identidad (Zabala, 2002). En general, el enfoque orientado a objetos persigue el desarrollo de sistemas en ambientes de cambios constantes, que requieren mantenimiento, adaptación y rediseño continuos. A continuación se especifican algunos detalles del análisis y el diseño en desarrollos orientados a objetos. 24

25 AyD orientado a objetos En lugar de examinar un problema mediante el modelo entrada proceso-salida o mediante un modelo derivado exclusivamente de estructuras jerárquicas de información, el análisis orientado a objetos (AOO), introduce la idea de objetos que quedan definidos por un conjunto de atributos y cuyo comportamiento queda definido por un conjunto de operaciones. Además, estos objetos pueden relacionarse entre sí, entre otras formas, manejando el concepto de herencia (Pressman, 2005). En este sentido, es una técnica que integra datos y procesos en esas construcciones llamadas objetos. En este caso los modelos son imágenes que ilustran los objetos del sistema desde varias perspectivas como estructura y comportamiento (Whitten et al., 2007). El análisis orientado a objetos, implica la ejecución de los siguientes pasos: Identificación de objetos: a partir de los conceptos que definen y describen el marco del problema. Es un primer intento de definir las clases de las que después se puedan instanciar objetos. Especificación de atributos: los que definen a cada objeto, aclaran su significado en el contexto del espacio del problema (Pressman, 2005). Definición de las operaciones: las operaciones cambian valores de uno o más atributos que están contenidos en el objeto. Pueden manipular los datos, realizar algún cálculo o monitorear un objeto (Pressman, 2005). Comunicación entre objetos: Se debe establecer un mecanismo de comunicación entre los objetos. Este mecanismo se denomina mensaje (Pressman, 2005). Fin de la definición del objeto: se definen las operaciones adicionales necesarias para la comunicación especificada entre los objetos (Pressman, 2005). El diseño orientado a objetos es, entonces, el conjunto de técnicas de diseño que extiende el AOO descrito anteriormente. Estas técnicas son utilizadas para refinar la definición de los objetos identificados en la fase de análisis y definir su diseño concreto. Los modelos, en este enfoque, representan a los objetos agrupados en clases óptimas para reutilizarse y darles mantenimiento. Estos objetos pueden mantener relaciones de herencia entre sí, lo cual da cabida al principio de polimorfismo o comportamientos alternativos de las clases derivadas. Esta idea de diseñar objetos altamente cohesionados y con baja (Kendall y Kendall, 2005). El modelo de análisis orientado a objetos está compuesto por tres modelos individuales: el modelo funcional, representado por casos de uso y escenarios, el modelo de análisis, representado por diagramas de clase y objeto, y el modelo dinámico, representado por diagramas de estado y diagramas de secuencia (Bruegge et al, 2002) Enfoque Web Es el enfoque utilizado para el desarrollo de aplicaciones que estarán disponibles en la World Wide Web y por tanto, accesibles a través de Internet. Los sistemas y aplicaciones basados en Web poseen atributos que los diferencian de sistemas de software tradicionales, como la concurrencia, el desempeño, la intensidad de red, la carga impredecible, inmediatez, seguridad, estética, evolución continua, sensibilidad al 25

26 contenido, disponibilidad, etc. (Pressman, 2005). La abstracción que orienta el desarrollo Web, es la página. Una página Web es un documento que contiene información específica de un tema particular, que está almacenado en un software conectado a Internet (IM, 2007). AyD de sistemas Web El análisis de sistemas Web está orientado a proponer una solución que cumpla, no sólo con las propiedades funcionales, también las no funcionales que fueron indicadas anteriormente como atributos característicos de este tipo de aplicaciones. En tal sentido, el proceso de análisis hace uso de algunos modelos utilizados en el enfoque orientado a objetos como los casos de uso, diagramas de interacción y diagramas de clase. Para soportar el AyD de aplicaciones Web se han propuesto los diagramas WAE, que permiten modelar la abstracción de páginas, sus relaciones y comportamiento dentro del sistema (Barrios, Mendoza, 2006). Pressman (2005) propone seis tipos de diseño que deben tener lugar cuando se desarrollan aplicaciones Web, estos son: Diseño de la interfaz: describe la estructura y organización del usuario. Diseño estético: o gráfico, que describe la apariencia de la aplicación. Diseño de contenido: define la plantilla, la estructura y el bosquejo de todo el contenido que se presenta como parte de la aplicación Web. Diseño de navegación: representa el flujo de navegación entre los objetos de contenido y para todas las funciones de la aplicación. Diseño arquitectónico: identifica la estructura hipermedia global para la aplicación Web. Diseño de componentes: desarrolla la lógica de procesamiento detallado que requiere para implementar componentes funcionales. En comparación con las cuatro vistas básicas del diseño, definidas en secciones anteriores (ver punto ) y aplicables para el desarrollo de aplicaciones independientemente del enfoque seleccionado, en el caso de sistemas Web se agregan el diseño estético o gráfico, el de navegación, el de componentes y uno de contenido que pudiera guardar relación con la vista de datos Enfoque orientado a componentes El enfoque de desarrollo orientado a componentes es una extensión de la orientación a objetos aplicable a sistemas abiertos, que trata de sentar las bases para el diseño y desarrollo de aplicaciones distribuidas, basadas en componentes de software reutilizables.. Se dice que un sistema es abierto si es concurrente, reactivo, independientemente extensible y permite a componentes heterogéneos ingresar o abandonar el sistema de forma dinámica. Y se entiende como un sistema independientemente extensible, a aquel que puede ser dinámicamente extendido y en donde pueden combinarse extensiones independientemente desarrolladas por distintas partes o entidades, sin conocimiento unas de otras (Fuentes et al., 2007). Szyperski (1998) señala que un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y 26

27 que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio. Entre los conceptos que son necesarios manejar para comprender los pasos que se llevan a cabo en un desarrollo orientado a componentes, está el marco de trabajo. Un marco de trabajo es un diseño reutilizable de todo o parte de un sistema, representado por un conjunto de clases abstractas y la forma en la cuál sus instancias interactúan, o bien puede entenderse como el esqueleto de una aplicación que debe ser adaptado a necesidades concretas por el programador de la aplicación (Fuentes et al., 2007). Una vez presentadas las ideas básicas del enfoque orientado a componentes, corresponde detallar cómo se realiza el AyD en los desarrollos que siguen esta línea paradigmática. AyD orientado a componentes El AyD orientado a componentes se enfoca en la identificación de los componentes que son necesarios construir y de las respectivas interfaces que cada componente debe publicar. Para cada componente deben ser identificadas y modeladas durante el AyD, dos interfaces: la interfaz que suministra, en la cual se definen los servicios que ofrece el componente, y la interfaz que solicita, la cuál especifica qué servicios deben estar disponibles, del sistema que utiliza el componente (Sommerville, 2006). Una meta de diseño en el desarrollo orientado a componentes es la reutilización, por lo que, en vez de diseñar y buscar los componentes reutilizables, este enfoque plantea que primero se busquen los componentes y luego se diseñe el sistema (Sommerville, 2006). Este enfoque utiliza como herramientas de diseño los diagramas de componentes y la infraestructura de despliegue para el modelado de datos. También utiliza el diagrama de interacción de componentes como herramienta para el modelado del comportamiento del sistema. (Griman, et al. 2005) Enfoque orientado a aspectos El enfoque orientado a aspectos ofrece mecanismos para abstraer y encapsular conceptos que no forman parte de la funcionalidad de los sistemas, por lo que se dice que está enfocado a las propiedades no funcionales. La abstracción manejada dentro de este enfoque es la de aspecto. Un aspecto es una propiedad que afecta el rendimiento o la semántica de los componentes, una unidad modular que se disemina por la estructura de otras propiedades funcionales, por ejemplo: seguridad de datos, patrones de acceso a memoria, persistencia, etc. (Quintero, 2000). Seguidamente se expondrán algunas características de la disciplina de AyD, llevada a cabo en un enfoque de aspectos. AyD orientado a aspectos El AyD de sistemas orientados a aspectos, reúnen un conjunto de técnicas que extienden las aplicadas para el desarrollo orientado a objetos, de modo que permitan encapsular en módulos separados los aspectos (Amaya et al., 2004). 27

28 En este enfoque el análisis se centra en determinar un criterio de descomposición del sistema y realizar dicha descomposición, en función de sus propiedades primarias. Los aspectos deben ser organizados en dimensiones y la integración de éstas conformará el sistema completo. Todas las dimensiones pueden ser tratadas de forma arbitraria, permitiendo el desarrollo independiente de los módulos que encapsulan los aspectos del mismo tipo; entendiendo como aspectos de un mismo tipo, a aquellas propiedades que descomponen el software atendiendo a un mismo criterio (Amaya et al., 2004). Como resultado del análisis resulta una propuesta de diseño construida sobre la descomposición seleccionada inicialmente, en donde las propiedades primadas queden como entidades bien definidas, independientes y ortogonales (Amaya et al., 2004). Corresponde entonces al diseño, la modelación de las relaciones entre los aspectos en que fue descompuesto el sistema durante el análisis. Existen diversas relaciones entre los aspectos de un determinado software. Están las relaciones semánticas, que como su nombre lo indica, reflejan asociaciones semánticas entre los aspectos. También existen las relaciones de contribución, las cuales implican que un aspecto puede afectar a otro positiva o negativamente. Y existen las relaciones de motivación, que abren la posibilidad de que un determinado aspecto proporcione una justificación para otro. Esta clasificación de relaciones no es cerrada ni excluyente, peden crearse nuevas relaciones en base a las necesidades de los aspectos que se estén modelando (Amaya et al., 2004). Como modelos que soporten diseños con estas características, aparece el llamado metamodelo para el aspecto, y la definición de una clase llamada tejedor. El tejedor de aspectos (weaver), es la unidad del programa que se encarga de combinar los lenguajes en tiempo de ejecución, logrando que un aspecto pueda cruzar transversalmente clases y componentes jerárquicas (Quintero, 2000). Hasta este punto se realizó una panorámica que ubicó al AyD de sistemas dentro de distintos enfoques de desarrollo. A modo de resumen, se presenta a continuación una tabla comparativa (tabla 4) de las características que identifican a cada uno de los enfoques descritos, en función de cómo asumen el AyD, y otra (tabla 5) en donde se listan los pasos para el AyD, en cada uno de los enfoques de desarrollo. Enfoques de Desarrollo Características Estructurado OO Web Componentes Aspectos Abstracción de flujos Abstracción de Objetos Abstracción de Componentes Abstracción de Aspectos Análisis centrado en procesos Análisis integra datos y procesos Análisis incluye modelado Diseño orientado a procesos 28

29 Diseño integra datos y procesos Diseño enfocado a propiedades funcionales Diseño enfocado a propiedades no funcionales AyD con alto nivel de abstracción Encapsulamiento Modularidad Herencia Polimorfismo Concurrencia Reutilización Mantenibilidad Tabla 4: AyD en los enfoques de desarrollo. Fuente: elaboración propia. Enfoques de desarrollo Estructurado Orientado a Objetos Web Orientado a Componentes Pasos para el AyD Creación de un modelo de flujo de datos Creación de un modelo de flujo de control Especificación de control Especificación de procesamiento Identificación de objetos Especificación de atributos Definición de las operaciones Comunicación entre objetos Fin de la definición del objeto Identificación de las páginas Diseño de la interfaz Diseño estético Diseño de contenido Diseño de navegación Diseño arquitectónico Diseño de componentes Análisis de componentes Búsqueda de componentes reutilizables Modificar requerimientos Diseño arquitectónico usando componentes encontrados Identificación de aspectos Descomposición aspectual (identificación, estructuración y Orientado a Aspectos especificación de concerns ) Diseño de la arquitectura Diseño de la recomposición aspectual Tabla 5: Pasos para el AyD, en los enfoques de desarrollo. Fuente: elaboración propia Al emprender un proceso de desarrollo de sistemas, no sólo se seleccionan fundamentos teóricos como el modelo de proceso a seguir y el paradigma según el cual se enfocará el desarrollo; también se toman decisiones pragmáticas como la selección de una 29

30 metodología. Por esta razón, se estudiará cómo varias metodologías de desarrollo afrontan el AyD AyD en distintas metodologías de desarrollo Las metodologías de desarrollo definen las etapas en las que se dividirá el proceso de elaboración de un software, establece la secuencia en que esas etapas se deben suceder para obtener el producto esperado, proponen una división del trabajo en disciplinas o conjuntos de actividades, determinan los productos intermedios que se deben obtener a lo largo del proceso y describen la interacción entre el equipo de desarrollo con dinámicas comunicativas o diferenciación de roles (Ortega, 2001). Algunos autores proponen clasificar las metodologías de desarrollo en planificadas y ágiles. Las metodologías planificadas tienen por objetivos principales predecir los cambios, procurar la estabilidad del proceso de desarrollo y asegurar la calidad del proceso y del producto; generalmente todas sus fases y actividades son documentadas y sus políticas de desarrollo tienden al orden. En general proponen una planificación detallada y documentada (Ortega, 2001). Por el contrario, las metodologías ágiles se caracterizan por responder a los cambios a medida que se presentan y su objetivo principal es obtener el valor del producto rápidamente. La documentación de los procedimientos es menor en comparación con las planificadas y el alto nivel de libertad que caracteriza al desarrollo, lo hace tender al caos (Ortega, 2001). En este nivel de estudio se comparará cómo algunas metodologías planificadas y algunas ágiles, asumen el AyD de los sistemas en desarrollo. Las metodologías estudiadas son: UP (Jacobson/Booch/Rumbaugh, s.f.), RUP (IBM, 2007), OpenUP (epfwiki, 2007), XP (programaciónextrema, 2007), Scrum (controlchaos, 2007), FDD (.featuredrivendevelopment, 2007), DSDM (dsdm, 2007), MFS (Microsoft, 2007) y WATCH (Montilva/Hamzan/Gharawi, 2000) Unified Process (UP) UP resulta de unificar las metodologías previas a su creación, por eso recibe el nombre de proceso unificado. Es una metodología centrada en la arquitectura que propone un desarrollo incremental, iterativo y orientado por casos de uso. Propone métodos para la mitigación de los riesgos, la retroalimentación con los usuarios y la documentación detallada de sus procedimientos usando la abstracción de artefactos entregables (Jacobson et al., s.f.). El proceso unificado se divide en 4 fases: inicio, elaboración, construcción y transición. En cada fase se pueden realizar tantas iteraciones como sean necesarias. Ahora bien, a lo largo de estas fases se llevan a cabo actividades en cinco niveles: requerimientos, análisis, diseño, implementación y prueba. Como se dijo anteriormente, el proceso unificado separa al análisis del diseño y los considera como dos de los 5 niveles en que se 30

31 desarrollan las fases. El modelo visual del software se realiza con UML (Jacobson et al., s.f.). Algunos artefactos que deben generarse en las fases de inicio y elaboración, contemplados en los niveles de AyD son, en la fase de inicio, el modelo de casos de uso y el (los) prototipo (s); y en la fase de elaboración, el modelo de diseño, el modelo de la arquitectura, y el modelo de datos (Jacobson et al., s.f.) Rational Unified Process (RUP) RUP (IBM, 2007), es la versión del proceso unificado ofrecida por Rational de IBM, por lo tanto está centrada en la arquitectura y orientada por casos de uso. Contempla las mismas cuatro fases de la metodología de la cual deriva (UP): inicio, elaboración, construcción y transición. Pero en lugar de cinco niveles, define un conjunto de disciplinas que se tiene lugar a los largo de las cuatro fases del ciclo. Estas disciplinas son: modelado del negocio, requerimientos, AyD, implementación, prueba, despliegue, manejo de la configuración y el cambio, manejo del proyecto, ambiente. El proceso unificado de Rational, considera al AyD como una disciplina integrada que tiene lugar entre los requerimientos y la implementación. Esta metodología utiliza los casos de uso para identificar un conjunto de objetos que serán refinados en clases, subsistemas y paquetes (Kruchten, 2000) OpenUP y EPF Es la versión Open Source del proceso unificado (UP) presentado por Eclipse Process Framework (EPF) 2005, un proyecto open source de Eclipse que sirve como base de un ecosistema de procesos, de modo que ofrece herramientas extensibles, un metamodelo unificado y contenidos ejemplares que pueden ser utilizados para una amplia variedad de procesos (Eclipse, 2007). OpenUP se caracteriza por el desarrollo iterativo, empleo de casos de uso y escenarios, administración de los riesgos y desarrollo basado en la arquitectura, que contemplan menos artefactos y en donde el AyD también es considerado una disciplina, adaptada según se implementen los procesos (Eclipse, 2007). En este sentido, EPF define a OpenUP como un proceso de desarrollo de software iterativo que es minimal, en tanto sólo el contenido fundamental es incluido, completo, puesto que puede ser considerado un proceso entero para construir un sistema, y extensible ya que puede usarse como una base (OpenUP/Basic), a cuyos procesos se agreguen contenidos según sea necesario (Eclipse, 2007) Extreme Programming (XP) XP es una metodología ágil que se fundamenta en cuatro principios: comunicación, simplicidad, retroalimentación y coraje (programacionextrema, 2007). Propone un desarrollo iterativo y asume el AyD como actividades que se llevan a cabo dentro de las iteraciones. Propone un diseño simple: se diseña la solución más simple y susceptible a ser implementada en el momento. Se definen la menor cantidad de clases posibles y se 31

32 minimizan diagramas y documentos. Distingue las siguientes 4 fases durante el desarrollo: exploración, planeamiento, liberación, productización. (Microsoft, 2007) Scrum Es una metodología definida como ágil, adaptativa, auto organizativa y con pocos tiempos muerto (Microsoft, 2007). Sin embargo, No se le considera como una metodología independiente sino complementaria de otras. Se preocupa en dividir las responsabilidades entre los actores del proceso: Scrum master, propietario del proyecto, equipo de Scrum, cliente y usuario (Microsoft, 2007). El ciclo de vida de Scrum contempla fases y grupos de iteraciones llamadas sprints. Entre las fases se encuentra el Pre juego (planeamiento), entre cuyas actividades está definir la arquitectura de alto nivel, diseño exploratorio y elaboración de prototipos. Otra fase es el Pre juego (montaje), entre cuyas actividades está la planificación, el diseño exploratorio y elaboración de prototipos. Los sprints son los siguientes: AyD, Codificación, Prueba y Entrega. En otras palabras, al AyD también se le considera como un conjunto de actividades dentro de las iteraciones, pero entendido desde la abstracción de sprint o grupo de iteraciones dedicadas a estas actividades Feature Driven Development (FDD) Es una metodología ágil, iterativa, adaptativa y orientada por características (o rasgos). Una característica es una función pequeña valorada por el cliente y equivale, en FDD, a los casos de uso en RUP (Ambler, 2003). FDD no cubre todo el ciclo de vida, sólo las etapas de diseño y construcción, por lo que se complementa con otras metodologías (featuredrivendevelopment, 2007). Las fases FDD son las siguientes: Desarrollo de un modelo general: el dominio general del sistema se subdivide en áreas más específicas. Se realizan modelos de objetos para cada área específica y un modelo general. El modelo de dominio consiste en diagramas de clases con clases, relaciones métodos y atributos (Microsoft, 2007). Construcción de la lista de características: se listan las características como ítem útiles para el cliente (Microsoft, 2007). Planeamiento por rasgo: se priorizan los rasgos listados y las secciones de la lista con igual prioridad, son llamadas paquetes de diseño (Microsoft, 2007). Diseño por rasgo y construcción por rasgo: se realiza el diseño por conjuntos de rasgos seleccionados, se codifican y se prueban por unidades (Microsoft, 2007). FDD ofrece un conjunto de artefactos para la planificación y control de los proyectos como: vistas de desarrollo, vistas de planificación, reportes de progreso, reportes de tendencia, etc. (Microsoft, 2007). 32

33 Dynamic System Development Method (DSDM) Es una metodología ágil, iterativa e incremental, que en lugar de ajustar tiempo y recursos para lograr la implementación de las funcionalidades, fija el tiempo y los recursos como constantes y ajusta las funcionalidades según criterio de selección de requerimientos, según los siguientes rasgos (DSDM, 2007): Debe tener: los requerimientos fundamentales del sistema que deben ser implementados en su totalidad. Debería tener: los requerimientos importantes a los que no se les da una respuesta inmediata pero si a corto plazo. Podría tener: los requerimientos que pueden quedar por fuera de la implementación. Se desea que tenga, pero no lo tendrá en esta vuelta: requerimientos valorados pero que pueden esperar. DSDM contempla 5 fases para el proceso de desarrollo: Estudio de la viabilidad, Estudio del negocio, Iteración del modelo funcional en donde se lleva a acabo el análisis, se construyen prototipos y en base a la experiencia se mejoran los modelos de análisis (DSDM, 2007), Iteración del diseño y construcción y Despliegue. En este caso, a diferencia de las metodologías anteriores, se definen fases específicamente para el análisis y para el diseño, y en el caso del diseño, está integrado con la construcción en una misma fase Microsoft Solutions Framework (MFS) Más que una metodología, MFS ha sido definido como un conjunto de principios, modelos, disciplinas, conceptos, lineamientos y prácticas probadas, elaborado por Microsoft. Es también entendido como un marco de trabajo fuertemente documentado, en donde la gestión de los riesgos y el manejo del proyecto se asumen como disciplinas (Microsoft, 2007). El proceso propuesto por MSF está dividido en cuatro fases que se exponen a continuación, detallándose aquellas que contemplan la ejecución de actividades relativas al AyD: Definición de la visión en la que se construye la visión del sistema, Planificación en donde se realizan completamente el diseño conceptual, las especificaciones de diseño y el plan de proyecto, Desarrollo y Estabilización. Puede afirmarse que MSF asume al análisis y al diseño como fases pues, la fase de definición de la visión está dedicada a actividades de análisis, y la fase de planificación, a actividades de AyD WATCH La metodología WATCH (2007), es un conjunto de métodos dirigidos al desarrollo de software basado en componentes. Surge en el año 2000 en la facultad de ingeniería de la Universidad de los Andes, en Venezuela. Integra dos elementos, el método 33

34 WATCH extendido utilizado para el desarrollo de aplicaciones Web basadas en componentes de software reutilizables y el método WATCH component, que describe el ciclo de vida de un componente de software reutilizable. Esta metodología defina tres modelos: el del producto, que corresponde a la descripción de los elementos comunes elaborados al final de aplicar el método, el modelo del proceso, utilizado para representar el desarrollo de la aplicación, y el modelo del grupo, en donde se especifican los roles de los participantes del proceso (WATCH, 2007). En el caso WATCH extendido (2007), se utiliza la metáfora del reloj para representar el modelo del proceso. El proceso de desarrollo general está dividido en dos partes: el proceso gerencial y el proceso de desarrollo. Este último, contempla 8 etapas que se suceden según el comportamiento de un reloj, entorno a los procesos gerenciales. Estas etapas son: modelado de negocios, definición y especificación de requerimientos, diseño arquitectural de la aplicación, especificación de componentes, aprovisionamiento de los componentes, ensamblaje de los componentes, pruebas de la aplicación Web y entrega de la aplicación. Adicionalmente se consideran procesos post desarrollo (WATCH, 2007). La metodología WATCH contempla una etapa para el diseño, pero no para el análisis, al menos explícitamente. Sin embargo, dentro de las etapas que preceden al ensamblaje de los componentes, se distinguen actividades que, por las definiciones expuestas en la sección y 2.1.2, pueden considerarse propias del análisis de sistemas. A continuación, la descripción de esas etapas según WATCH (2007), excluyendo la definición y especificación de requerimientos. Modelado del negocio: primera fase en ser ejecutada y en la cual se identifica y describe en detalle el dominio del negocio en el que se enmarca la aplicación Web. Produce un modelo del dominio del problema, elemento contemplado como parte del análisis de sistemas. Diseño arquitectural: esta fase tiene como principales productos la descripción de la arquitectura de la aplicación Web, la interfaz de usuario y las bases de datos que van a ser utilizadas por la aplicación. Especificación de los componentes: se especifican detalladamente los componentes que conforman la arquitectura de la aplicación y sus interacciones, así como también los marcos de despliegue que van a ser utilizados en la implementación de la aplicación. Nueve han sido las metodologías de desarrollo de sistemas presentadas en función de cómo asumen el AyD. Se observó que, dependiendo del enfoque de las metodologías, el AyD pueden estar orientados por casos de uso, por rasgos, etc. Pueden proponer estrategias de diseño simple o complejo según sean metodologías ágiles o planificadas, respectivamente. Y en general, la tendencia es orientar el AyD a través del modelado del software. Estos son algunos de los criterios utilizados en la tabla 6 para comparar todas las metodologías estudiadas. Esta tabla resume la información expuesta en esta sección. 34

35 Metodologías de Desarrollo Características UP RUP OpenUP XP Scrum FDD DSDM MFS WATCH Alto nivel de abstracción Centrada en la arquitectura Interacción continua con el cliente durante AyD Diseño simple Modelar el software Dirigido por casos de uso Dirigido por rasgos Análisis enfocado en los riesgos Define una fase para el análisis Define una fase para el diseño AyD como una disciplina AyD como actividades dentro de las iteraciones Tabla 6: AyD en las metodologías de desarrollo. Fuente: elaboración propia Adicionalmente, en la tabla 7, se listan los artefactos entregables y los roles involucrados en el proceso, durante el AyD, según lo propone cada metodología. Metodologías Artefactos de AyD Roles involucrados en el AyD UP RUP Modelo de casos de uso Prototipo Modelo de diseño Modelo de arquitectura Modelo de datos Modelo de casos de uso Prototipo Documento de arquitectura (modelo de arquitectura, de datos, de interfaz y de procesos) Modelo del caso de negocio Analista Arquitecto Desarrollador Stakeholders Analista del proceso de negocio Diseñador del negocio Analista de sistema Arquitecto de software Diseñador Diseñador de interfaz de usuario Diseñador de cápsulas Diseñador de base de datos Stakeholders 35

36 OpenUP XP Scrum FDD DSDM MFS WATCH Modelo de casos de uso Documento de arquitectura Dependen del desarrollo Dependen del desarrollo Modelo del dominio Lista de rasgos Modelo de rasgos Definición de la arquitectura Modelo Funcional Prototipo Documentador técnico Analista Arquitecto Desarrollador Stakeholders Programador Cliente Programadores (miembros del "equipo") Propietario del producto Scrum Master Arquitecto en jefe Redactor técnico Desarrollador Redactor o Escribano Representante de los usuarios Consejero del usuario Líder del proyecto Modelador del negocio Arquitecto de datos Gerente de programa Desarrollador Casos de uso Diseño físico Diseño conceptual Especificación funcional Usuario de experiencia Diseño lógico Modelo de dominio Líder del proyecto Modelo de Negocio Representante de los usuarios Modelo de la arquitectura Modelo de la base de datos Modelo de la interfaz de usuario Todos los desarrolladores Modelo funcional Modelo estructural Modelo dinámico Tabla 7: Artefactos y roles de AyD en las metodologías de desarrollo. Fuente: elaboración propia. A modo de resumen, el AyD puede ser entendido de varias maneras según el enfoque teórico con que se lleve a cabo el desarrollo, según el lenguaje de programación que se seleccione previamente para la implementación, según las exigencias de los usuarios finales en cuanto al tiempo en que es requerida la solución, según las características del problema que da origen al desarrollo, etc. En tal sentido, el AyD pueden asumirse como etapas diferentes o integradas, como una disciplina que tiene vida a lo largo del desarrollo, como actividades específicas o como fases completas. El análisis y el diseño pueden abocarse a construir abstracciones de los datos, de los procesos o de ambos, traducir requerimientos funcionales, no funcionales o ambos, en especificaciones de arquitectura, datos, procesos e interfaces a ser implementadas. 36

37 Sin embargo, modelos de proceso, enfoques y metodologías, coinciden en que orientar el análisis y el diseño con modelos o representaciones gráficas, es una estrategia de desarrollo que ofrece garantías de un producto fiel a los requerimientos iniciales, de una comunicación asertiva con los usuarios y de un proceso y un producto que sigan estándares de calidad establecidos. Ubicado este punto de encuentro entre las teorías estudiadas en esta sección, se presenta a continuación el lenguaje unificado, como conjunto de notaciones utilizado en varias de las metodologías y enfoques expuestos, para el AyD de sistemas El Lenguaje Unificado de Modelación (UML) El lenguaje unificado de modelación es un lenguaje que nos permite especificar, visualizar y documentar modelos de sistemas de software, incluyendo su estructura y diseño. Incluye diagramas que permiten a las personas visualizar la construcción del software, de manera similar a la forma en que un conjunto de planos permite a las personas visualizar la construcción de un edificio. La última versión del lenguaje unificado es UML y contempla una taxonomía de diagramas que se muestra en el anexo V. Jim Conallen desarrolló en 1998 una extensión de la notación UML denominada WAE "Web Application Extensión" que permite utilizar toda la gramática interna de UML para modelar aplicaciones con elementos específicos de la arquitectura de un entorno Web. Un diagrama WAE representa las páginas Web y otros elementos arquitectónicamente significativos, junto con las clases tradicionales y las interacciones entre estas (Conallen, 2002). A nivel estructural permite modelar páginas cliente y páginas servidor, relaciones de enlace, enlace dirigido, redirigir, construir y enviar; además de otros objetos, como formularios, propios de aplicaciones Web. Una vez expuesto el uso del UML como conjunto de notaciones que facilita la comunicación entre analistas, diseñadores, implementadores y usuarios, y la especificación y construcción ordenada y coherente del sistema en construcción, se hablará de las herramientas CASE, como un paso al frente en el enfoque sistemático e integrado del análisis, diseño, implementación, pruebas y soporte de sistemas. 37

38 3.2. Herramientas CASE Para que el desarrollo de sistemas, en cada una de sus etapas sea productivo, es necesario que los desarrolladores lleven a cabo sus actividades de forma organizada, con precisión y contemplando la mayor cantidad de detalles posible. Una respuesta a estas necesidades, es la ingeniería de software asistida por computadora o CASE (Computer- Aided Systems Engineering). En esta sección se define qué son las herramientas CASE, cuáles son las ventajas de su utilización y qué facilidades ofrece al desarrollo; se mostrará la clasificación de estas herramientas, en función de la etapa del ciclo de vida que soportan y se expondrá con detalle aquellas que son de mayor utilidad durante el AyD Definición y objetivos de herramientas CASE Whitten et al. (2007), presentan las herramientas CASE como programas de software que automatizan o soportan la representación gráfica y el análisis de modelos de sistemas y permiten la traducción de estos modelos de sistemas en aplicaciones. En otras palabras, se pueden entender como aplicaciones que son utilizadas para diseñar y construir otras aplicaciones. Por otra lado, Lundell y Lings (2004), hablan de tecnologías CASE, y las definen como un conjunto de herramientas computarizadas e ínter operables que apoya las tareas de actores involucrados en le desarrollo del software y los procesos que se llevan a cabo durante todo el ciclo de vida del desarrollo. En principio, pueden existir herramientas que automaticen un subconjunto particular del conjunto completo de actividades distribuidas a lo largo del ciclo de vida del desarrollo, de modo que pudiéramos contar en cada etapa con una herramienta CASE especializada. Por ejemplo, podemos contar con un programa que soporte el análisis de requerimientos, otro para el AyD, otra para la gestión de proyectos, otra para base de datos, otra para la documentación, etc. Sin embargo, es posible contar con herramientas integradas o I-CASE, que reúnan en el mismo software las funcionalidades que soporten todas o un subconjunto de estas etapas. Lundell y Lings (2004) exponen algunas percepciones sobre las herramientas CASE, entre las cuales está la de Fitzgerald (1999), quien se refiere a estas como herramientas tan avanzadas que deben ser capaces de producir automáticamente aplicaciones completas, a través de la generación de código; incorporar llamadas a bases de datos estándares y permitir la definición de interfaces de usuario gráficas, triggers de integridad referencial de la base de datos, etc. Con herramientas CASE de uno u otro tipo, lo que se busca es contar con un repositorio, donde se pueda almacenar toda la información generada durante el desarrollo (modelos del sistema, detalles, especificaciones) y que dicha información pueda ser accedida por todos los miembros del equipo desarrollador, en tanto sea necesario. Kendall y Kendall (2005) consideran que las cuatro razones más importantes para el uso de herramientas CASE son: el aumento en la productividad del analista, la mejora de la comunicación analista-usuario, la integración de las actividades del ciclo de vida (en la medida en que se proporciona continuidad de una fase a la siguiente) y la evaluación precisa del impacto de los cambios en el mantenimiento. 38

39 Clasificación de herramientas CASE Las herramientas de ingeniería asistida por computadoras pueden ser clasificadas según los siguientes criterios (Rivas, 2007): Según las funciones que la herramienta soporta. A partir de este criterio, Pressman (2005) habla de herramientas de gestión, de gestión de proyectos, de soporte, de programación, de integración y prueba, de creación de prototipos, de mantenimiento, de estructura y de AyD, éstas últimas son las que permiten crear un modelo del sistema que se va a construir. Según el actor que es apoyado por la herramienta. De acuerdo a este criterio pueden ser: de alto nivel, que ayudan a los analistas y diseñadores, permitiéndoles crear y modificar el sistema diseñado; o de bajo nivel, utilizadas por los programadores en tanto ayudan a generar código fuente. Kendall y Kendall (2005), además de estas dos, hablan de herramientas integradas, resultantes de combinar las de bajo y alto nivel. De acuerdo con el proceso. Este criterio toma en cuenta las posibilidades de soporte al proceso de desarrollo de sistemas y clasifica las CASE en (Fuggetta, 1993): o Herramientas: aquellas que soportan tareas individuales del proceso como verificar la consistencia de un diseño, compilar un programa, comparar pruebas, etc. Pueden ser de propósito general, autosuficientes o agruparse en el banco de trabajo. Persiguen propósitos puntuales. o Bancos de trabajo: aquellas que apoyan fases del proceso o actividades. Están conformados por un conjunto de herramientas con algún grado de integración e interacción. o Ambientes: aquellas que apoyan una parte sustancial del proceso de desarrollo. Incluyen bancos de trabajo integrados y soportan a los datos, al control y a la integración. Por su parte, Losavio (1997) las clasifica en herramientas interactivas, que soportan métodos de AyD, y herramientas no interactivas, que corresponden a los compiladores. De las distintas clasificaciones presentadas anteriormente, los tipos de herramientas CASE que apoyan el AyD son, según la funcionalidad, las de AyD, según el actor, las de alto nivel; de acuerdo al proceso, pueden ser cualquiera de los tres tipos y según la clasificación de Losavio (1997), las herramientas interactivas. Así, las CASE pueden entenderse como herramientas que implementan las actividades propias del AyD (entre las otras etapas del ciclo de vida), estudiadas anteriormente, y el último eslabón en la cadena de abstracciones que comienza con el modelo de proceso y pasa por el enfoque de desarrollo y la metodología seleccionada para el desarrollo de un sistema. La última sección de esta investigación documental se ocupa de estudiar los conceptos básicos relacionados con Software Libre y aplicaciones de código abierto, tópicos de interés para los objetivos de este trabajo, en tanto el producto final resultará de la modificación de una herramienta de Software Libre y código abierto. 39

40 3.3. Free Libre Open Source Software (FLOSS) Free/Libre Open Source Software (FLOSS) y Free and Open Source Software (F/OSS), son términos y siglas que hacen referencia a una filosofía de desarrollo de software que pudiera ser aplicada a cualquiera de los modelos de proceso y enfoques de desarrollo expuestos en las secciones anteriores, pero que albergan en su seno teórico, dos conceptos diferentes que se integran en dicha filosofía de trabajo. Estos conceptos son: Software Libre y código abierto. Comencemos por hablar del Software Libre. The Free Software Foundation (2007) dice en su página oficial, que el Software Libre es un tema de libertad y no de costo, referido a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software en cuestión y establecen cuatro tipos de libertad que deben tener los usuarios entorno a un software, para considerarlo libre: Libertad de ejecutar el programa para cualquier propósito. Libertad de estudiar cómo funciona el software y poder adaptarlo a sus necesidades. Libertad de redistribuir copias. Libertad de mejorar el programa y liberar al público las mejoras realizadas. The Free Software Foundation (2007) afirma que Software Libre no significa que sea no comercial, sólo que el desarrollo con fines comerciales de Software Libre no es usual. Por otra parte, la versión 1.9 de la definición de Open Source o código abierto (opensource, 2007), no se refiere únicamente a tener acceso al código fuente del software. En términos de distribución, hablar de código abierto implica considerar los siguientes criterios (Laurent, 2004) (opensource, 2007): Libre Redistribución: la licencia del software no restringirá la venta de alguna parte del programa, o la repartición del software como un componente agregado de un programa que contenga diferentes fuentes. La licencia de código abierto tampoco requerirá honorarios por concepto de estas ventas. Código abierto: el programa debe incluir el código fuente original, o al menos indicar una dirección en Internet en donde se pueda acceder gratuitamente al mismo, y debe permitir la distribución y modificación de este código y de su forma compilada. Trabajos derivados del original: la licencia del software debe permitir modificaciones y trabajos derivados del original, de modo que estos puedan ser distribuidos bajo los mismos términos o condiciones del software original. Integridad del código original del autor: la licencia puede restringir la distribución de modificaciones al código original en el caso de parches o pedazos de código agregados. La licencia debe permitir explícitamente este tipo de modificaciones. En estos casos la licencia puede requerir que las modificaciones sean identificadas con nombres o números de versión distintos a los originales. Esta parte de la definición es permisiva pero no obligatoria. Se contempla este criterio para proteger el trabajo y la reputación de los creadores del código original. Ninguna discriminación contra personas o grupos: la licencia del software no debe discriminar de su uso a ningún grupo o persona. 40

41 Ninguna discriminación contra campos de trabajo: la licencia no debe restringir el uso del software a ningún campo de trabajo específico, de modo que pueda ser utilizado desde un negocio hasta investigaciones genéticas. Distribución de la licencia: los derechos relativos al programa deben aplicarse a todo aquel a quien el programa es redistribuido, sin necesidad de generar una licencia adicional. La licencia no debe ser específica a un producto: los derechos relativos al programa no deben depender del software que es parte de una distribución de particular. Si el programa es extraído de aquella distribución y usado o distribuido dentro de los términos o condiciones de la licencia del programa, todos aquellos a quienes el programa es redistribuido, deberían tener los mismos derechos que aquellos que se conceden en la conjunción con la distribución de software original. La licencia no debe restringir otro software: la licencia no debe colocar restricciones contra otro software que es distribuido con el software autorizado. Por ejemplo, la licencia no debe insistir que todos los otros programas distribuidos sobre el mismo medio sean software abierto de la misma fuente. La licencia debe ser de tecnología neutral: Ninguna provisión de la licencia puede ser afirmada sobre cualquier tecnología individual o estilo de interfaz. Ahora bien, el FLOSS es más que software y código abierto (Hein, 2004), es una filosofía de trabajo que propone una dinámica de desarrollo constituida por cuatro elementos (AlMarzouq, 2005): La licencia: define a un software como FLOSS. La licencia establece los términos de distribución del software y de su uso por parte de cualquier individuo. En el contexto de FLOSS existen distintos tipos de licencias según las condiciones que establecen para el uso y distribución del software al que están vinculadas, en la tabla 8 se comparan algunas características de varios ejemplos de licencias creadas para productos de Microsoft, Sun, Mozilla, GNU, entre otros. 41

42 Tabla 8: Tipos de licencias FLOSS. (Goldman y Gabriel, 2005) Leyenda numérica de la tabla 5: 1. Sólo si el IP es requerido para una modificación que no obedece el estándar. 2. Todos los fallos (bugs) reparados deben ser publicados. 3. Si una modificación o nueva especificación de interfaz (API) es compartida, entonces debe ser publicada para que todos puedan verla. 4. Sólo los cambios que no cumplan con el estándar deben ser publicados. 5. Sólo los cambios a los archivos que contienen el código original o contribuciones de la comunidad, deben ser publicados. 6. La licencia incluye varias condiciones alternativas que, de ser encontradas, no requiere que modificaciones sean publicadas. 7. En algunas condiciones debe dar nombres fuera del estándar, ejecutables fuera del estándar y documentar claramente las diferencias en los manuales, junto con instrucciones sobre dónde conseguir la versión estándar. 8. Puede ser distribuido sólo a los que han firmado el SCSL. Diccionario de nombres de la tabla 5: Proprietary License: licencias que permiten colaboración, generalmente entre empresas privadas, a pesar de no tratarse de software de código abierto. SCSL: Sun Community Source License SISSL: Sun Industry Standards Source License MPL: Mozilla Public License SPL: Sun Public License CPL: IBM Common Public License GPL: GNU General Public License LGPL: Lesser General Public License Artistic License: Creada por Larry Wall en 1991 para que Perl pudiera ser usado en paquetes comerciales. 42

43 Apache: Licencia para productos de Apache Software Foundation. BSD: Berkley Software Disribution. MIT y X: Licencia para el X Window System, con derechos de autor para X Consortium. Public Domain: relativo a la falta de licencia, código abierto de dominio público o derechos de autor para cualquier persona. La comunidad: el grupo de personas que están involucrados en el desarrollo. Consiste de todos los desarrolladores y usuarios de FLOSS. Están dispersos en tiempo y espacio, por locuaz se apoyan en el uso de las tecnologías de Internet y software colaborativo. Esta comunidad tiene una estructura definida por niveles de contribución; en primer lugar está el nivel core, es el corazón de la comunidad en tanto reúne a los responsables de la mayor parte del desarrollo de código, el siguiente nivel es el de co desarrolladores, quienes colaboran ocasionalmente haciendo mejoras al software. Le sigue el nivel de los usuarios activos, que utilizan el software y proponen ideas para su mejora, y finalmente el nivel de usuarios pasivos, que simplemente descargan y usan el software sin realizar aportes a la comunidad. Figura 5: Niveles de contribución en las comunidades de desarrollo FLOSS Fuente: AlMarzouq, 2005 El proceso de desarrollo: en comparación con los modelos de proceso presentados en las secciones anteriores, se han distinguido cinco pasos básicos en el proceso de desarrollo de FLOSS: 1. Código: los potenciales contribuidores FLOSS dan el paso inicial de cargar su código. 2. Revisión: personas calificadas revisan el código que ha sido cargado para verificar su calidad. 3. Pruebas previas: los miembros de la comunidad que realizan contribuciones constantemente, prueban cada aporte cuidadosamente. 43

44 4. Liberación de desarrollo y eliminación paralela de fallos: si el módulo pasa las pruebas previas, se incorpora en la liberación del desarrollo. Se realizan los ajustes que se requieran. 5. Liberación del producto: la contribución es liberada. El software: como producto resultante del proceso de desarrollo. Por otra parte Goldman y Gabriel (2005), hablan de la existencia de una infraestructura necesaria para desarrollar un proyecto de código abierto. Esta infraestructura viene dada por los siguientes cinco elementos: un archivo público de código al que los miembros de la comunidad pueden acceder, una clara documentación del proyecto que incluya cómo usar y modificar el código, una lista de aspectos de discusión principales o noticias de grupo que incluyan anuncios, reportes de fallos, problemas encontrados y cómo resolverlos, asuntos pendientes de diseño y ofertas de futuros trabajos. También es necesaria una base de datos de los fallos encontrados y finalmente un sitio Web en donde se pueda tener acceso a todas las facilidades y recursos listados anteriormente. Goldman y Gabriel (2005) resaltan como razón principal para considerar el uso y desarrollo de software de código abierto, el potencial innovador que posee esta filosofía de desarrollo, en tanto implica la puesta en común de las ideas de distintos colaboradores, favoreciendo extender las potencialidades de un producto de software en beneficio de la comunidad involucrada El Modelo de Proceso de Desarrollo para Software Libre En la sección de este capítulo, fueron presentados un conjunto de modelos de procesos aplicables al desarrollo de sistemas según los distintos enfoques, también estudiados. Pero habiendo introducido el tema del Software Libre y de código abierto, cabe preguntarse si existe algún modelo para el desarrollo de Software Libre o si algún teórico ha presentado algún esquema para el ciclo de vida del desarrollo de FLOSS. A este respecto, no se encontró en la literatura un modelo de proceso definido con precisión en el que se distingan fases, actividades o procesos. Muffato (2006), afirma que la gran cantidad de características que determinan cómo trabaja la comunidad de Software Libre, entre las que señala la participación abierta y la organización bottom-up, hacen imposible un modelo de proceso de desarrollo de Software Libre y código abierto, que sea preciso y estandarizado. Sin embargo, Muffato (2006), compara varios de los modelos expuestos en la sección 2.1.3, con la dinámica de desarrollo implementada por la comunidad de Software Libre, y presenta una tabla comparativa (tabla 9) en la que expone las similitudes entre dichos modos de desarrollo de software. Modelo de proceso Construcción y Arreglo Cascada Iterativo Evolutivo Similitud con el desarrollo de FLOSS Se le otorga importancia a los recursos humanos y al conocimiento y habilidades de los programadores individuales. Enfocado en los requisitos del cliente y se reconoce la importancia de probar los productos con los clientes División del proyecto en sub - proyectos y desarrollo incremental de las funciones y características. Desarrollo concurrente de cada módulo y, al mismo tiempo, desarrollo paralelo de los diferentes módulos para acelerar el 44

45 proceso de desarrollo Elaboración de Prototipos Importancia de la retroalimentación para mejorar el entendimiento de los requerimientos del usuario y definir mejor las especificaciones. Espiral Síntesis de los puntos fuertes de los otros modelos. Tabla 9: Similitudes entre modelos consolidados para el desarrollo de software y el proceso de desarrollo para FLOSS. Fuente: Muffato (2006) Por otra parte, para la comunidad de desarrollo de Ubuntu (2005), existe una serie de modelos de referencia para el desarrollo de Software Libre, según la economía y sostenibilidad del proceso, que han denominado modelos económicos del Software Libre y están descritos en la tabla 10. Modelo Económico Liberador Artístico Académico Currículo Solidario Hobby Estandarizador Proveedor de Servicios Competitivo Reconversión Descripción Considera al software como una forma de conocimiento y se enfoca en liberar este conocimiento para ponerlo a disposición de la sociedad. Los desarrolladores se mueven por un impulso creativo y se sienten satisfechos cuando consiguen completar una obra concreta que partió de una idea abstracta. El dinero no les importa en absoluto y lo que quieren es que su entorno conozca su creación y reconozca sus méritos. Propio de los procesos de desarrollo de software en las universidades, como producto de la investigación, el espíritu innovador, proyectos de fin de carrera, doctorados, conferencias académicas, etc. Desarrollos ejecutados por particulares que buscan agregar experiencia a su currículo y dar muestras concretas de su trabajo. Desarrollos orientados a publicar aplicaciones libres que sean útiles para quienes no pueden pagar sus equivalentes comerciales y opten por la adquisición de software pirata. El ámbito educativo y las alternativas a las utilidades shareware son dos filones donde este modelo cuaja con frecuencia Desarrollos llevados a cabo por el puro placer de desarrollar libremente sin las restricciones relativas a la construcción de software propietario. El Software Libre se rige por estándares abiertos consensuados públicamente y por tanto resulta útil cuando diversas organizaciones deben cooperar en proyectos conjuntos a gran escala, a largo plazo y sobre un terreno neutral El más extendido en el ámbito empresarial. Se ofrecen servicios de consultoría, adaptación, soporte y formación alrededor de una sólida aplicación libre, o varias. A raíz de los encargos de los clientes van contribuyendo mejoras y nuevas funcionalidades a las aplicaciones en las que se especializan. Un grupo de desarrolladores se imponen ante su competencia con la producción de Software Libre. En ocasiones el 100% de los desarrollos son libres y en ocasiones una versión libre es un subproducto de otra no libre más potente, que es la punta de lanza de la oferta de la empresa. Variante del modelo competitivo. Una empresa de desarrollo de software propietario se acerca o llega a la quiebra, libera sus desarrollos y cambia por completo su estrategia comercial. Modelo implementado por las administraciones públicas, al dar apoyo y adoptar el Software Libre. Tabla 10: Modelos económicos de Software Libre propuestos por Ubuntu (2005). Fuente: elaboración propia Institucional 45

46 Finalmente puede concluirse que el modelo que siga un proceso de desarrollo de Software Libre, está determinado por las características específicas de la comunidad involucrada en el desarrollo, de modo que, como advierte Muffato (2006), parece no haber un modelo definido para este tipo de desarrollos. Sin embargo, sean cuales sean las características de las comunidades de desarrollo, parece existir un punto de encuentro en sus modos de trabajo, relacionado con la construcción colaborativa FLOSS y el constructivismo Desde la perspectiva más general de la filosofía sobre la cuál se realiza el desarrollo de FLOSS, pudiera identificarse una relación entre los modos de trabajo en el mundo del Software Libre y el código abierto, con teorías sobre la aproximación constructivista del conocimiento y el aprendizaje. Para darle sentido y coherencia a esta consideración, es necesario acercarse a las bases teóricas del constructivismo. En primer lugar, Arceo y Rojas (s.f.) afirman que no basta con hablar de constructivismo en singular, sino que hace falta aclarar el contexto y la aplicación del mismo. Visto de esta forma y dado que el constructivismo en sus orígenes surgió como una corriente epistemológica, preocupada por discernir los problemas de la formación del conocimiento en el ser humano, aplicar las teorías constructivitas para entender y explicar fenómenos sociales de acercamiento al conocimiento y al aprendizaje, como por ejemplo el desarrollo de software en comunidades, parece ser una posibilidad de investigación. En este orden de ideas, vale la pena destacar algunos debates que, según Arceo y Rojas (s.f.), actualmente se realizan entorno al constructivismo, como por ejemplo dar respuesta a las siguientes preguntas: el desarrollo es un proceso de autoorganización cognitiva o más bien de aprendizaje cultural dentro de una comunidad de práctica?, qué papel juega la interacción mediada por el lenguaje o interacción comunicativa en comparación con la actividad auto estructurante del individuo?. Según los autores, estos debates surgen a partir del encuentro de acepciones diferentes del constructivismo como las identificadas por Deval (1997) en la obra de Darwin, Vico, Kant y Marx, entre quienes existe la convicción de que el conocimiento se construye activamente por sujetos cognoscentes y no se recibe pasivamente del ambiente; o la corriente del constructivismo psicogenético de Piaget, centrado en el estudio del funcionamiento y contenido de la mente del individuo, frente al constructivismo social de Vigotsky, interesado en el desarrollo de dominios de origen social. Planteemos entonces acercamientos teóricos básicos sobre el constructivismo que permitan visualizar una posible relación entre el desarrollo colaborativo y en comunidades, propio de la filosofía de Software Libre y de código abierto. En primer lugar, Mario Carretero (1993) afirma que el constructivismo es la idea que mantiene que el individuo, tanto en los aspectos cognitivos y sociales como en los afectivos, no es un mero producto del ambiente ni un simple resultado de sus disposiciones internas, sino una construcción propia que se va produciendo día a día como resultado de la interacción de ambos aspectos. Y señala que el proceso de construcción depende de dos aspectos fundamentales: los conocimientos previos o representación que se tenga de la 46

47 nueva información o de la nueva actividad o tarea a realizar, y de la actividad interna o externa que el aprendiz realice al respecto. Así pues, según explica Rigo Lemini (1992), el constructivismo postula la existencia y prevalencia de procesos activos en la construcción del conocimiento, es decir, se habla de un sujeto aportante, que claramente rebasa a través de su labor constructiva lo que le ofrece su entorno. Por otro lado, aplicada específicamente al aprendizaje escolar, pero posiblemente extensible a niveles más generales de aprendizaje y construcción del conocimiento, Coll (1990) afirma que la concepción constructivista se organiza entorno a tres ideas fundamentales, de las cuáles se citarán las dos primeras: 1. El alumno es el responsable último de su propio proceso de aprendizaje, de modo que es él quien construye o reconstruye, los saberes de su grupo cultural (en el caso del desarrollo de software de código abierto, la comunidad), y éste puede ser un sujeto activo cuando manipula, explora, descubre o inventa, incluso cuando lee o escucha la exposición de los otros. 2. La actividad mental constructiva del alumno se aplica a contenidos que poseen ya un grado considerable de elaboración, es decir, el alumno no tiene en todo momento que inventar en un sentido literal todo el conocimiento, puesto que este es resultado de un proceso de construcción social. De esta manera queda enmarcado el proceso de desarrollo de Software Libre y de código abierto, en un contexto de trabajo colaborativo regulado a través de la figura de las licencias, y se ha hecho una aproximación a la teoría constructivista como posible fundamento teórico alternativo, que explique el proceso de desarrollo de software bajo esta filosofía y que justifique el valor académico, tecnológico y humano del FLOSS. A continuación, se muestra una tabla comparativa (tabla 11) que resume los puntos de encuentro encontrados entre el constructivismo y la filosofía de desarrollo de FLOSS. Constructivismo El proceso de construcción del conocimiento depende de los conocimientos previos del aprendiz. Filosofía FLOSS El proceso de construcción del software depende del conocimiento previo que el desarrollador tiene del software existente: lenguaje, código, experiencia de uso del software, fallas, necesidades funcionales, etc. El desarrollador construye o reconstruye a partir del trabajo realizado por la comunidad de desarrollo. El Software Libre es resultado de un proceso de construcción comunitaria. El sujeto a portante es el desarrollador que libera un sistema superior en algún sentido (versión nueva o corregida), al que le ofrecía su entorno (versiones anteriores). Tabla 11: Puntos de encuentro entre constructivismo y FLOSS. Fuente: elaboración propia El aprendiz construye o reconstruye los saberes de su grupo cultural El conocimiento es resultado de un proceso de construcción social. El sujeto aportante rebasa a través de su labor constructiva lo que le ofrece su entorno. A manera de resumen y cierre de este marco teórico, se tiene que el AyD puede entenderse desde lo conceptual, de diversas maneras, ya sea como una disciplina, como un conjunto de actividades o como una fase del proceso de desarrollo. Sin embargo, sea cuál sea su concepción, el modelado del sistema resulta esencial en cualquier enfoque de 47

48 desarrollo, modelo de proceso y metodología de desarrollo y el uso de herramientas CASE que soporten el análisis y el diseño, resultan también fundamentales para procurar la eficiencia y eficacia del AyD, en miras de lograr un sistema fiel a las necesidades que le dieron origen. Además, si estas herramientas son desarrolladas y distribuidas bajo la filosofía de Software Libre y de código abierto, las posibilidades de obtener aplicaciones de AyD que se adapten a los distintos modelos de procesos, enfoques de desarrollo y metodologías de desarrollo, se incrementan en la medida en que los miembros de las comunidades de desarrollo les incorporen mejoras, funcionalidades y adaptaciones de forma constructivista, según las necesidades de los procesos de desarrollo de software que requieran llevar a cabo. Esta investigación documental, en conjunto con el modelo conceptual presentado en el capítulo 5, fue enviado al jurado de la LVII Convención de la Asociación para el Avance de la Ciencia (AsoVAC 2007), el trabajo fue aprobado y posteriormente presentado en esta edición, en la Universidad Nacional Experimental de Táchira (UNET), en la ciudad de San Cristóbal, en diciembre de En el siguiente capítulo se exponen los antecedentes de este trabajo de investigación acción, en cuanto a la evaluación de la calidad sistémica de herramientas de software, analizando el Modelo Sistémico de Calidad (MOSCA). 48

49 CAPÍTULO 4. ANÁLISIS DE ANTECEDENTES El presente capítulo tiene por objeto presentar el análisis de los antecedentes del trabajo de investigación. En primer lugar se describe el Modelo Sistémico de Calidad (MOSCA) en su generalidad y luego en su perspectiva del producto; posteriormente se hará una revisión de las categorías y características propuestas por el modelo, para determinar cuáles de ellas serán tomadas en cuenta al elaborar una instanciación del MOSCA, que sea aplicable a herramientas de Software Libre que soporten el AyD de sistemas Modelo Sistémico de Calidad (MOSCA) MOSCA es un modelo de calidad, producido por el Laboratorio de Investigación en Sistemas de Información (LISI), de la Universidad Simón Bolívar en Venezuela, fundamentado, entre otras teorías, en la definición de calidad sistémica de software propuesta por Callaos y Callaos, la cual establece dos perspectivas de calidad asociadas a la visión del cliente y del usuario, obteniendo 8 dimensiones que originan la matriz global sistémica (Ortega, 2001) presentada en la figura 6. Figura 6: Matriz global sistémica de Callaos y Callaos (Ortega, 2001). La cuarta versión del MOSCA contempla tres perspectivas: la del producto, la del proceso y la humana. Para cada una de estas perspectivas, el modelo propone cuatro niveles que se detallan a continuación (Pérez, 2005). Nivel 0: corresponde al nivel de las dimensiones abarcadas en cada perspectiva. Estas son el aspecto contextual e interno del producto, del proceso y de lo humano. Nivel 1: corresponde al nivel de las categorías definidas para cada perspectiva. Estas son la funcionalidad (FUN), fiabilidad (FIA), usabilidad (USA), eficiencia (EFI), mantenibilidad (MAB) y portabilidad (POR), para la perspectiva del producto; cliente proveedor (CUS), ingeniería (ENG), soporte (SUP), gestión 49

50 (MAN) y organizacional (ORG), para la perspectiva del proceso, e individual (IND), equipo (EQU) y entorno empresarial (ENT), para la perspectiva humana. Nivel 2: corresponde al nivel de las características asociadas a cada categoría, las cuales definen las áreas claves a satisfacer para lograr, asegurar y controlar la calidad en las tres perspectivas. Son 56 características asociadas al producto, 27 al proceso de desarrollo y 15 a la parte humana. Nivel 3: corresponde a las métricas, utilizadas para medir la calidad sistémica. Son en total 715 métricas. En el anexo VI, se muestra como se integran estos niveles en el MOSCA. Se observa como las categorías definidas en el nivel 1 para la perspectiva del producto, coinciden con las características que el estándar ISO 9126, establece como obligatorias para garantizar la calidad del producto de software; de modo que el MOSCA evalúa el producto según estas normas internacionales. Dado que esta investigación está orientada a evaluar la calidad de herramientas libres que soporten el AyD de sistemas, es de interés trabajar con la dimensión del producto del MOSCA. A manera de resumen, en la tabla 12 se muestran las categorías y características propuesta por el Modelo Sistémico de Calidad para la dimensión del producto. Categorías Funcionalidad (FUN) Fiabilidad (FIA) Usabilidad (USA) Eficiencia (EFI) Mantenibilidad (MAB) Portabilidad (POR) FUN 1. Ajuste a los propósitos FUN 2. Precisión FUN 3. Interoperabilidad FUN 4. Seguridad FIA 1. Madurez FIA 2. Tolerancia a fallas FIA 3. Recuperación USA 1. Facilidad de Comprensión USA 2. Capacidad de Aprendizaje USA 3. Interfaz Gráfica USA 4. Operabilidad USA 5. Conformidad con los Estándares. EFI 1. Comportamiento del tiempo EFI 2. Utilización de recursos EFI 3. Efectivo MAB 1. Capacidad de Análisis MAB 2. Facilidad de Cambio MAB 3. Estabilidad MAB 4. Capacidad de Prueba MAB 5. Acoplamiento MAB 6. Cohesión MAB 7. Encapsulado POR 1. Adaptabilidad POR 2. Capacidad de Instalación POR 3. Co-existencia POR 4. Capacidad de Reemplazo POR 5. Consistente POR 6. Parametrizado POR 7. Encapsulado Características FUN 5. Correctitud FUN 6. Estructurado FUN 7. Encapsulado FUN 8. Especificado FIA 4. Correctitud FIA 5. Estructurado FIA 6. Encapsulado USA 6. Completo USA 7. Consistente USA 8. Efectivo USA 9. Especificado USA 10. Documentado USA 11. Auto-descriptivo EFI 4. No Redundante EFI 5. Directo EFI 6. Utilizado MAB 8. Madurez del Software MAB 9. Estructura de Control MAB 10. Estructura de Información MAB 11. Descriptivo MAB 12. Correctitud MAB 13. Estructural MAB 14. Modularidad POR 8. Cohesivo POR 9. Especificado POR 10. Documentado POR 11. Auto - descriptivo POR 12. No - Redundante POR 13. Auditoria POR 14. Manejo de la calidad Tabla 12: Categorías y características para medir la calidad sistémica del producto de software. Fuente: Ortega (2000). 50

51 Adicionalmente, Mendoza et. al, (2005) proponen el siguiente algoritmo para evaluar la calidad del software usando dicho modelo: 1. Estimar la calidad del producto. Siempre se debe medir primero la categoría Funcionalidad del producto. Si cumple con el 75% de las características necesarias que se proponen para esta categoría, entonces se procede a la segunda actividad. 2. Instanciación del sub modelo del producto. En esta actividad se seleccionan dos categorías más, de las restantes propuestas por el sub modelo del producto, aquellas que se considera el software a evaluar debe cumplir. Luego se deben evaluar las categorías seleccionadas. El algoritmo recomienda trabajar con un máximo de tres categorías, ya que si se seleccionan más de tres, estás podrían entrar en conflicto. 3. Estimación de calidad para cada categoría. Para las dos categorías seleccionadas previamente se debe: a. Aplicar las métricas propuestas en el sub modelo del producto para las categorías seleccionadas. b. Verificar que el 75% de las métricas se encuentran dentro de los valores óptimos (mayor o igual a 3), para cada una de sus características. c. Evaluar la categoría. Para que una categoría sea satisfecha, al menos el 75% de sus características son altamente satisfechas; de esta manera se garantiza coherencia y consistencia, en relación a los niveles de aceptabilidad, establecidos por el modelo. d. Estimar la calidad del producto, partiendo de las categorías evaluadas. Si no se satisface la categoría funcionalidad, el algoritmo finaliza, y la calidad del producto de software será nula. Si un producto de software cumple con los objetivos para los cuales fue creado (funcionalidad), este tendrá una calidad básica. Si satisface sólo una de las categorías seleccionadas, además de la funcionalidad, tendrá un nivel de calidad intermedio; mientras que si satisface todas las categorías seleccionadas, tendrá un nivel de calidad avanzado. En resumen, el MOSCA propone inicialmente una evaluación cuantitativa a partir de la aplicación de las métricas correspondientes a las características de cada categoría, y con la aplicación del algoritmo descrito, ofrece resultados cualitativos respecto del software en una escala de calidad nula, intermedia o avanzada. En el capítulo 5, se detallarán las categorías, características y métricas que serán seleccionadas para evaluar herramientas de Software Libre que soporten el AyD de sistemas. 51

52 CAPÍTULO 5. MARCO METODOLÓGICO El objetivo de este capítulo es describir el procedimiento utilizado para la evaluación y selección de la herramienta FLOSS que soporte AyD de sistemas y que será modificada y presentada como propuesta última de este proyecto. Para ello se realizará una instanciación del Modelo Sistémico de Calidad (MOSCA) (Mendoza et al., 2005), acorde con las características que, según se especifica en el marco teórico, deben cumplir un producto diseñado para tal fin Framework Metodológico Para formular un modelo de calidad, en este caso aplicable a herramientas de AyD de sistemas, se utilizará el Framework metodológico sistémico (Pérez et al., 2004), basada en el método Investigación Acción (Checkland, 1993, Baskerville 1999) y en la metodología DESMET (Kitchenham, 1996). El método investigación-acción se desarrolla en 5 fases: Diagnosticar, planificar la acción, tomar la acción, evaluar, especificar el aprendizaje. Dentro de estas 5 fases, el Framework metodológico del LISI (2004), propone 11 actividades adaptables a las características de la investigación. En la figura 7 se muestra el ciclo metodológico que implementa esas 11 actividades y en la tabla 13, se detallan cada una por separado, en el contexto de este proyecto investigativo. Figura 7: Framework Metodológico para el trabajo de grado. Fuente: Adaptado de Pérez et al. (2004) 52

53 Actividad 1. Investigación documental. 2. Análisis de antecedentes (MOSCA producto) 3. Formulación de los objetivos y el alcance de la investigación. 4. Formulación de la metodología de investigación: Adaptación de Investigación Acción. 5. Instanciación de MOSCA para herramientas FLOSS que soporten el AyD. 6. Análisis de Contexto. 7. Aplicación de la metodología DESMET. 8. Evaluación a través del método arrojado por DESMET. 9. Análisis de los resultados. 10. Definición del alcance de la siguiente iteración. Descripción Etapa de la fase de Diagnosticar, consiste en la revisión del material bibliográfico en torno al AyD de sistemas, estudiados desde tres niveles de abstracción (modelos de proceso, enfoques de desarrollo y metodologías de desarrollo), a las características de las herramientas que soportan alguna etapa del proceso de desarrollo de sistemas y al Software Libre y de código abierto. El resultado de esta revisión bibliográfica fue presentado en el Capítulo II (Marco Teórico). Etapa de la fase de Diagnosticar, consiste en el estudio de MOSCA y sus relaciones, a fin de evaluar la cobertura que posee actualmente de los aspectos propuestos por la disciplina de AyD. El resultado de esta actividad fue presentado en el capítulo III (Análisis de antecedentes). Etapa de la fase Planificar la Acción donde se definen claramente los objetivos de la investigación. El objetivo es delimitar el área de investigación. El resultado de esta actividad está reflejado en la Justificación del Problema y la especificación de los Objetivos del Trabajo de Grado, presentados al inicio de la presente investigación Etapa de la fase Planificar la Acción donde se elabora la adaptación, para esta investigación, del método Investigación - Acción. El objetivo es elaborar el marco metodológico que soporta el trabajo de investigación. El presente Capítulo es el resultado de esta actividad. Etapa de la fase Tomar la Acción donde se realizan las modificaciones y adaptaciones al MOSCA. El objetivo es obtener una nueva instanciación de MOSCA que cubra las características que debe cumplir una herramienta de Software Libre que soporte el AyD de sistemas. Etapa de la fase Tomar la Acción, donde se determinan las especificaciones y acuerdos necesarios para implementar la instanciación de MOSCA. El objetivo es preparar las herramientas y el contexto donde serán evaluadas las herramientas de AyD que posteriormente serán comparadas. Etapa de la fase Tomar la Acción, donde se ejecuta la metodología DESMET. Tomando en cuenta los criterios propuestos por DESMET, se selecciona uno de los métodos propuestos por la metodología, para evaluar las herramientas de AyD, mediante la instanciación del MOSCA, obtenida en el paso 5. Etapa de la fase Evaluar, que consiste en aplicar el método de evaluación. Etapa de la fase Evaluar, que consiste en estudiar los resultados a partir de los objetivos planteados en el trabajo de investigación, en términos de: el modelo de evaluación propuesto y los productos tangibles alcanzados. Al terminar esta fase se selecciona la herramienta que haya arrojado los resultados más satisfactorios. Etapa de la fase Especificar el Aprendizaje, consiste en delimitar el alcance de las modificaciones que se deben realizar a la herramienta seleccionada, según el estudio de resultados. 53

54 11. Conclusiones y Etapa de la fase Especificar el Aprendizaje, donde se establecen algunas recomendaciones. conclusiones relativas a la herramienta seleccionada y los resultados de su evaluación. Finalmente, se sugieren algunas recomendaciones para futuros refinamientos del modelo de evaluación propuesto y para investigaciones relacionadas. Tabla 13: Fases de la metodología de Investigación Acción propuesta. Fuente: Elaboración Propia Tal como se indica en la tabla anterior, en el paso 7 de la investigación-acción se aplica la metodología DESMET, por lo que será descrita a continuación, definiendo sus objetivos y los criterios que se utilizan para seleccionar el método de evaluación. Según Kitchenham, (1996) la metodología DESMET está compuesta por un conjunto de métodos con sus respectivas herramientas que pueden ser aplicadas o utilizadas según las particularidades del proyecto. Esta metodología, en el caso del presente trabajo de grado, será utilizada para planificar y evaluar posteriormente, de forma confiable, el modelo propuesto para evaluar herramientas que soporten el AyD de sistemas. El ciclo metodológico usado, soporta la investigación de problemas complejos, partiendo de prácticas exitosas y evaluando el modelo propuesto en versión Beta. Absorbe el aprendizaje y lo incorpora a una nueva propuesta mejorada. Este ciclo puede repetirse n veces, de modo que se incorporen en una propuesta mejorada, el aprendizaje obtenido en cada una de las repeticiones. Sin embargo, para efectos de esta investigación, se consideró una sola iteración, dado el alcance y las limitaciones de tiempo del proyecto de grado. Para complementar el método de evaluación seleccionado, en miras de obtener un conjunto de métricas significativas que produzcan los indicadores que se adecúen al interés de la investigación, se presenta a continuación un enfoque basado en objetivos, preguntas y métricas para evaluar características de calidad en sistemas de software Enfoque Basado en Objetivos, Preguntas y Métricas GQM Según Basili et al. (1994), el desarrollo de software, como cualquier disciplina de ingeniería, requiere un mecanismo de medición para su corrección y evaluación. Para que este mecanismo sea efectivo debe estar centrado en objetivos específicos; debe ser aplicado a todo el ciclo de vida de los productos, procesos y recursos y su interpretación debe estar basada en las caracterizaciones del contexto organizacional, ambiente y objetivos. En este sentido, estos autores han desarrollado un enfoque basado en objetivos, preguntas y métricas (GQM del inglés Goal Question Metric). Este enfoque, según Basili et al. (1994), posee tres niveles que pueden observarse en la figura 8 y que son descritos seguidamente. 54

55 Figura 8: Niveles del Enfoque GQM Fuente: Basili et al. (1994) Primer Nivel - Conceptual (OBJETIVO): Un objetivo es definido por un objeto, un conjunto de razones con respecto a varios modelos de calidad y puede tener varios puntos de vista e incluso es relativo a un ambiente particular. Los objetos medibles son productos, procesos y recursos. Segundo Nivel Operacional (PREGUNTA): Un conjunto de preguntas es utilizado para caracterizar la forma en que se alcanzará un objetivo específico. Las preguntas tratan de caracterizar el objeto de medición con respecto a un atributo de calidad seleccionado, para determinar su calidad desde un cierto punto de vista. Tercer Nivel Cuantitativo (METRICA): Un conjunto de datos es asociado con cada pregunta para responderla de forma cuantitativa. Los datos pueden ser objetivos (si dependen sólo del objeto medido) o subjetivos (si dependen del objeto medido y del punto de vista desde el cual son tomados). Según Basili et al. (1994), el objetivo se refina en varias preguntas y cada pregunta es refinada en varias métricas. Algunas métricas pueden ser utilizadas para responder varias preguntas de un mismo objetivo, incluso, varios modelos GQM pueden tener también preguntas y métricas en común, dado que las métricas pueden tener diferentes valores dependiendo del punto de vista tomado. El enfoque GQM se presenta como un mecanismo detallado para la definición y elaboración de objetivos mensurables, respondiendo a una de las principales inquietudes de este trabajo: cómo evaluar herramientas de Software Libre que soporten actividades de AyD de Sistemas?. Habiendo definido la metodología que orienta este proyecto y presentado el enfoque de la estrategia de evaluación que se utilizará sobre herramientas que soportan el AyD de sistemas, se procede a exponer en el siguiente capítulo, la propuesta de MOSCA adaptado a este tipo de herramientas. 55

56 CAPÍTULO 6. PROPUESTA DE INSTANCIACIÓN DE MOSCA En este capítulo se presenta la instanciación del MOSCA para evaluar herramientas de Software Libre que soportan el AyD de sistemas. Para ello serán seleccionarán 3 de las 6 categorías que propone el Modelo Sistémico de Calidad en la dimensión del producto. Para cada categoría se seleccionará un subconjunto de sus características, será seleccionado un subconjunto de métricas y otras nuevas serán agregadas. Los criterios para realizar esta selección, vienen dados por los aspectos teóricos presentados en el capítulo 2 de este trabajo de investigación, en el cuál se estudio el AyD desde tres niveles de abstracción: modelos de proceso, enfoques de desarrollo y metodologías de desarrollo Modelo conceptual Como resultado de la investigación bibliográfica que se desarrollo al inicio del proyecto, se obtuvo un modelo conceptual que resume y relaciona las acepciones teóricas relativas al AyD de sistemas, los modelos de proceso, los enfoques de desarrollo y las metodologías de desarrollo. El modelo conceptual fue construido con notación UML y dividido en cinco vistas que serán presentadas a continuación. En primer lugar, la figura 9 muestra el modelo más general, en donde se reúnen las construcciones conceptuales del análisis y el diseño de sistemas, aislados de los tres niveles de abstracción mencionados. 56

57 Figura 9: Modelo conceptual general (Conceptos de AyD de sistemas). Fuente: Elaboración propia. 57

58 En segundo lugar, la figura 10 muestra las relaciones del AyD de sistemas, con los distintos modelos de proceso descritos anteriormente: cascada o ciclo de vida clásico, orientado a la reutilización, espiral y orientado a prototipos. Figura 10: Modelo conceptual de AyD y modelos de proceso. Fuente: Elaboración propia. 58

59 La figura 11 muestra las relaciones del AyD con los conceptos relativos a los enfoques de desarrollo (estructurado, OO, Web, orientado a componentes y orientado a aspectos). Figura 11: Modelo conceptual de AyD y enfoques de desarrollo. Fuente: Elaboración propia. 59

60 La figura 12 muestra las relaciones del AyD con las metodologías de desarrollo (UP, RUP, OpenUP, WATCH, XP, Scrum, DSDM, MFS y FDD). Figura 12: Modelo conceptual de AyD y metodologías de desarrollo. Fuente: Elaboración propia. 60

61 Por último, se relacionan en el diagrama de la figura 13, los tres niveles de abstracción que han orientado esta investigación. Figura 13: Modelo conceptual de los tres niveles de abstracción. Fuente: Elaboración propia. 61

62 6.2. Resumen de las características de MOSCA tomadas para la instanciación Como se mostró en el análisis de antecedentes, el Modelo Sistémico de Calidad propone en su algoritmo de evaluación, trabajar con 3 de las 6 categorías de la dimensión producto, entre las que debe constarse la funcionalidad. En este sentido, presentamos las categorías y las características que fueron escogidas para instanciar el MOSCA para aplicaciones de Software Libre que soporten AyD. Siguiendo el algoritmo de MOSCA, se inicia con la Funcionalidad del producto. Según ISO 9126, la Funcionalidad es la capacidad del producto de software para proveer funciones que cumplan con necesidades específicas o implícitas, cuando el software es utilizado bajo condiciones específicas. Es básico y fundamental que una herramienta de AyD cumpla con los requerimientos funcionales que se esperan de un producto de software de esta naturaleza. Dentro de esta categoría, fueron consideradas las siguientes características: Ajuste a los propósitos: La capacidad del producto de software para proveer un conjunto de funciones apropiado según tareas y objetivos específicos del usuario (ISO 9126). Esta característica fue seleccionada, en tanto es fundamental que las funcionalidades del producto se ajusten al propósito soportar el AyD de sistemas. Precisión: Capacidad del producto de software para proveer los resultados correctos. Esto incluye el grado de precisión de los valores calculados (ISO 9126). Se consideró necesario que el producto permita realizar un diseño del sistema que se traduzca en una correcta implementación, en función de los requerimientos originales, y eso depende del nivel de precisión y exactitud de las funcionalidades. Interoperabilidad: Capacidad del producto de software para interactuar con uno o más sistemas especificados (ISO 9126). Como se estudió en el marco teórico de este proyecto, el AyD está ubicado, en los distintos modelos de procesos, en etapas intermedias del proceso de desarrollo, precedida generalmente por una etapa de manejo de requerimientos y seguida de la implementación; dado que existen herramientas que soportan las etapas previas o posteriores al AyD, es relevante conocer si el producto evaluado interactúa con alguna herramienta con estas u otras características. Por otro lado, en tanto el producto será modificado, es importante conocer si las nuevas funcionalidades requieren que se hagan modificaciones en módulos que integren al producto con otros sistemas. Correctitud: La Correctitud está dividida en tres categorías relacionadas con la capacidad de cómputo, completitud y consistencia. Alguna violación de una de estas propiedades puede significar que el software no tendrá la funcionalidad esperada (ISO 9126). Características como la completitud de los modelos y código fuente generados y la consistencia entre las distintas abstracciones producidas por la herramienta, son determinantes a la hora de realizar el diseño del sistema. Encapsulado: Las variables, las constantes y los tipos deben ser utilizados en el contexto en el que son definidos. La manera en que son utilizadas puede tener un impacto significativo sobre la Modularidad y por lo tanto sobre la calidad de los módulos y programas (ISO 9126). Se consideró que la capacidad funcional de mantener las variables relacionadas con las abstracciones utilizadas para el AyD, en 62

63 el contexto correspondiente, es relevante en tanto permite orientar el desarrollo con principios de diseño como la modularidad. En segundo lugar fue seleccionada la categoría Usabilidad. Según ISO 9126, la Usabilidad es la capacidad del producto de software para ser atractivo, entendido, aprendido y utilizado por el usuario bajo condiciones específicas. Como los productos a evaluar deben permitir la diagramación de distintos modelos del sistema y requiere poner a la mano del usuario diversas utilidades, que le permitan integrar los elementos necesarios para que la diagramación y el análisis sean correctos y consistentes, es fundamental que el producto cumpla con estándares mínimos de Usabilidad. Dentro de esta categoría fueron consideradas las siguientes características: Facilidad de comprensión: La capacidad que tiene el producto de software para facilitar al usuario el entender el software y la forma en que puede ser utilizado para efectuar diferentes tareas bajo condiciones específicas. Estas métricas deben ser capaces de evaluar el comportamiento de los usuarios sin previo conocimiento de la operación del software y medir la dificultad al entender las funciones, operaciones y conceptos del software (ISO 9126). Es importante que la herramienta que soporte AyD pueda utilizarse para desarrollos con distintos enfoques y que implementen distintas metodologías, sean ágiles o planificadas; en este sentido, el producto debe proveer las facilidades necesarias para que analistas y diseñadores puedan comprender rápidamente como utilizarlo según el contexto del desarrollo. Interfaz gráfica: Se refiere a la capacidad del producto de software para ser atractivo al usuario (ISO 9126). En tanto un amplio rango de las funcionalidades de este tipo de herramientas, están orientadas a la diagramación, la interfaz gráfica debe ser atractiva y fácil de usar para el usuario, de modo que permita realizar las actividades propias del AyD en un ambiente cómodo, adaptable y que agilice la interacción hombre sistema. Operabilidad: La capacidad del producto de software para habilitar al usuario a operarlo y controlarlo (ISO 9126). La importancia de considerar la operabilidad como una característica a evaluar en una herramienta de AyD, radica en la necesidad de que el usuario cuente con todas las ayudas posibles para operar el software, de modo que pueda controlar todas las variables que necesite para lograr el AyD esperado. Efectivo: Una forma estructural es efectiva cuando presenta sólo los elementos necesarios para definir e implementar la forma estructural (ISO 9126). Proveer los mecanismos para que el usuario le de un uso efectivo al producto, garantiza una mejor experiencia de interacción hombre sistema, en función de tiempo y resultados. Auto descriptivo: Una forma estructural es auto - descriptiva si su propósito es evidente en el nombre de los módulos y los identificadores tienen significado en el contexto de la aplicación (ISO 9126). Si la herramienta es auto descriptiva, la adecuada interacción del usuario con el sistema se logrará fácilmente. Finalmente, se seleccionó como tercera categoría la Mantenibilidad. Según ISO 9126, la Mantenibilidad es la capacidad del producto de software para ser modificado; las 63

64 modificaciones pueden incluir correcciones, mejoras o adaptaciones del software ante cambios del ambiente, en requerimientos y especificaciones funcionales. Una herramienta FLOSS debe estar construida de modo que su modificación y mantenimiento sean lo más sencillo posible y deben ofrecer la suficiente documentación para que la comunidad de desarrollo tenga fácil acceso a la información necesaria para el mantenimiento y mejora del software. Dentro de esta categoría se consideraron las siguientes características: Capacidad de Análisis: Es la capacidad del producto de software para ser diagnosticado por deficiencias o causas de fallas en el software, o por partes a ser modificadas (ISO 9126). Para el desarrollo de este proyecto es importante exigir que la herramienta a ser modificada sea de fácil diagnóstico, de ello dependerá su evaluación y la selección de las partes que serán mejoradas. Capacidad de Cambio: Es la capacidad del producto de software para facilitar una modificación específica a ser implementada (ISO 9126), característica fundamental para una herramienta FLOSS. Mientras mayor capacidad de cambio tenga una herramienta, mayor será su potencialidad para ser mejorada por los aportes de la comunidad de desarrollo. Estabilidad: Es la capacidad del producto de software para evitar efectos inesperados después de modificaciones en el software (ISO 9126). La calidad en el cumplimiento de los requerimientos funcionales y no funcionales de una herramienta inestable, puede perderse luego de una modificación que, a pesar de procurar la mejora del software, genere fallas sectores que funcionaban correctamente. Acoplamiento: Es una medida de la interconexión entre los módulos de una estructura de programa. El acoplamiento depende de la complejidad de la interfaz entre los módulos, el punto en que se entra o se hace referencia al módulo qué datos pasan a través de la interfaz. En el diseño de software, se intenta conseguir el menor nivel posible de acoplamiento (ISO 9126). El acoplamiento es una característica deseable en una herramienta a modificar, puesto que mientras más sencilla sea la conexión entre los módulos que integran un software, más fácil se entenderá su funcionamiento y la identificación de los sectores que deben modificarse para lograr los cambios deseados. Cohesión: Una forma estructural es cohesiva si todos sus elementos están enlazados estrechamente unos a los otros, y contribuyen a llevar a cabo un simple objetivo o función. Lo importante es lograr una alta cohesión y reconocer cuándo hay poca cohesión, para modificar el diseño del software y conseguir una mayor dependencia funcional (ISO 9126). Módulos cohesionados permitirán, durante un proceso de modificación, actualización o mantenimiento del software, concentrar los esfuerzos de la comunidad de desarrollo en las funcionalidades de interés. Atributos de Madurez del Software: Son definidos como las características físicas y medidas asociadas a la edad y uso del sistema de software objetivo (ISO 9126). Es de interés para este proyecto seleccionar una herramienta con la madurez suficiente para garantizar que futuras modificaciones tengan altas probabilidades de éxito. 64

65 Habiendo seleccionado las categorías y sus respectivas características, el siguiente paso es formular la instanciación completa de MOSCA, listando las métricas que permitirán medir el software en cada categoría Instanciación de MOSCA Para cada una de las características descritas, fueron seleccionadas las métricas que mejor aplican para este proceso de evaluación del producto. En algunos casos fueron creadas nuevas sub-características y nuevas métricas. En la figura 14 se muestra el subárbol de la dimensión del producto de MOSCA con las modificaciones realizadas. Figura 14: Instanciación de MOSCA para herramientas de AyD. Fuente: elaboración propia. 65

66 En la figura anterior, FUN 1.1, FUN 1.2 y FUN 1.3, corresponden a tres nuevas sub categorías de la Funcionalidad, llamadas Diagramas, Documentación y Vinculación entre AyD e implementación. Análogamente, MAB 2.1 corresponde a una nueva sub categoría de Mantenibilidad denominada Licencia. A continuación se resumen las características con métricas nuevas, todas ellas tienen vinculación con al menos uno de los conceptos tratados en el Marco Teórico. En primer lugar se detallan las que corresponde a Funcionalidad en la tabla 14. Característica Sub - característica Ajuste a los Diagramas propósitos (FUN 1.1) (FUN 1) Pregunta Formulación Dirigido a Permite realizar diagramas de 1 si - 0 no Usuario clase? Permite realizar diagramas de 1 si - 0 no Usuario estructura de composición? Permite realizar diagramas de 1 si - 0 no Usuario componentes? Permite realizar diagramas de 1 si - 0 no Usuario despliegue? Permite realizar diagramas de 1 si - 0 no Usuario objetos? Permite realizar diagramas de 1 si - 0 no Usuario paquetes? Permite realizar diagramas de 1 si - 0 no Usuario actividades? Permite realizar diagramas de 1 si - 0 no Usuario casos de uso? Permite realizar diagramas de 1 si - 0 no Usuario máquinas de estado? Permite realizar diagramas de 1 si - 0 no Usuario secuencia? Permite realizar diagramas de 1 si - 0 no Usuario comunicación? (diagramas de colaboración) Permite realizar diagramas de 1 si - 0 no Usuario revisión de interacción? Permite realizar diagramas de 1 si - 0 no Usuario tiempos? Permite realizar diagramas WAE? 1 si - 0 no Usuario Permite realizar diagramas para el 1 si - 0 no Usuario modelado del negocio? Permite realizar el diseño de 1 si - 0 no Usuario datos, diagramas ER y/o ER-E? Permite realizar diagramas de 1 si - 0 no Usuario flujo de datos (DFD)? Permite realizar diagramas de 1 si - 0 no Usuario flujo de control (DFC)? Permite realizar cartas 1 si - 0 no Usuario estructuradas? Permite realizar el diseño de la 1 si - 0 no Usuario interfaz? Permite realizar el diseño estético 1 si - 0 no Usuario para aplicaciones Web? Permite realizar el diseño de contenidos para aplicaciones Web? 1 si - 0 no Usuario Permite realizar el diseño de 1 si - 0 no Usuario navegación para aplicaciones Web? 66

67 Precisión (FUN 2) Correctitud (FUN 5) Documentación (FUN 1.2) Vinculación entre AyD e implementación (FUN 1.3) Detalles de abstracción (FUN 2.1) Completo (FUN 5.1) Consistente (FUN 5.2) Permite realizar el diseño arquitectónico de la estructura hipermedia para aplicaciones Web? Permite realizar metamodelos para aspectos (para aplicaciones desarrolladas con enfoque orientado a aspectos)? Permite modelar la descomposición y/o composición aspectual del dominio del problema (para el análisis de aplicaciones desarrolladas con enfoque orientado a aspectos)? Permite diseñar la recomposición de los aspectos a través de una clase tejedor (para aplicaciones desarrolladas con enfoque orientado a aspectos)? Permite convertir diagramas o generar unos a partir de otros? Permite exportar los diagramas a otros formatos? Permite generar documentación a partir de los diagramas elaborados? Permite realizar anotaciones sobre los diagramas? Permite generar código a partir de los diagramas elaborados? Permite realizar ingeniería de reversa? Permite especificar los nombres de las abstracciones? Permite caracterizar con detalle las abstracciones? (atributos con tipos de datos y valores iniciales en las clases, procedimientos con argumentos en las clases, argumentos de los estímulos en los diagramas de secuencia, cardinalidades de las asociaciones, etc.) Implementa las potencialidades expresivas de UML 2.1, en función de los tipos abstracciones y sus interrelaciones? Las abstracciones que pueden ser modeladas mantienen sus propiedades? El código generado es consistente con los diagramas originales? Los diagramas generados por ingeniería de reversa son consistentes con el código original? 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 si - 0 no Usuario 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente Usuario Usuario Desarrollador Usuario Desarrollador Usuario Usuario 67

68 Encapsulado (FUN 7) Taxonomía (FUN 7.1) Contexto de las abstracciones (FUN 7.2) Los diagramas generados a partir de otros, son consistentes con los originales? Maneja los diagramas agrupados por vistas, tipos, o alguna taxonomía conocida? (Diagramas de estructura, Diagramas de comportamiento, Diagramas de Interacción) Permite utilizar las abstracciones sólo dentro del contexto en que fueron creadas? (conflictos de nombre entre objetos creados en distintos diagramas) 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente Usuario Usuario Usuario Desarrollador Tabla 14: Nuevas sub características y métricas de la categoría Funcionalidad. Fuente: elaboración propia. Como se observa en la figura 14, la siguiente categoría en ser extendida con nuevas métricas, corresponde a la Usabilidad, y en la tabla 15 se muestran las nuevas métricas. Característica Sub - característica Facilidad de Comprensión (USA 1) Operabilidad (USA 4) Facilidad de comprensión Operabilidad Pregunta Formulación Dirigido a Son necesarios altos conocimientos de Software Libre para poder utilizar el sistema? Son necesarios altos conocimientos de Software Libre para poder instalar el sistema? 1 Siempre - 2 Casi siempre - 3 Algunas veces - 4 Pocas veces - 5 Nunca 1 Siempre - 2 Casi siempre - 3 Algunas veces - 4 Pocas veces - 5 Nunca Tabla 15: Nuevas métricas de la categoría Usabilidad. Fuente: elaboración propia. Usuario Usuario Finalmente, la tabla 16 muestra nuevas métricas agregadas a las características de la categoría Mantenibilidad. Característica Sub - característica Capacidad de Cambio (MAB 2) Licencia (MAB 2.1) Pregunta Formulación Dirigido a La licencia permite tener acceso al código? La licencia permite modificar el código? La licencia permite distribuir el código? La licencia permite distribuir el código modificado? La licencia permite utilizar el producto sin limitaciones de propósito tiempo y cantidad de equipos? La documentación del sistema está disponible 1 si - 0 no Líder 1 si - 0 no Líder 1 si - 0 no Líder 1 si - 0 no Líder 1 si - 0 no Líder 1 si - 0 no Líder 68

69 Estabilidad (MAB 3) Atributos de Madurez del Software (MAB 8) Estabilidad Atributos de Madurez del Software Porcentaje de parches de seguridad solucionados en relación a los encontrados por la comunidad Número de personas involucradas en el desarrollo Porcentaje 1 De cero a cinco - 2 De seis a diez - 3 De 11 a veinte - 4 decenas (más de veinte) - 5 centenas o miles Cantidad de descargas al año 1 De cero a cinco - 2 De seis a diez - 3 De 11 a veinte - 4 decenas (más de veinte) - 5 centenas o miles Líder Desarrollador Tabla 16: Nuevas sub características y métricas de la categoría Mantenibilidad. Fuente: elaboración propia. Líder Líder Las nuevas métricas de Funcionalidad permiten saber, por un lado, si una herramienta soporta el AyD de sistemas según lo proponen los distintos enfoques de desarrollo estudiados en el capítulo 1. Por esta razón se mide si la aplicación permite elaborar diagramas propios del enfoque estructurado, del enfoque OO, del enfoque orientado a aspectos y del orientado a componentes. Adicionalmente, en esas nuevas métricas agregadas a la subcategoría Diagramas, se evalúa si la herramienta permite llevar a cabo las distintas vistas del diseño propuestas por diferentes autores e ilustradas en el modelo conceptual presentado previamente en este trabajo. Por otro lado, al preguntar sobre las potencialidades de documentación, se evalúa si la herramienta genera artefactos requeridos cuando se trabaja con una metodología planificada o ágil. Las métricas añadidas en la subcategoría Vinculación entre AyD e implementación, permiten evaluar cuán capaz es la herramienta de ofrecer una visión trazable de todo el desarrollo, de modo que se adapte a las metodologías que lo requieran, y cuán capaz es de vincular distintas etapas o fases del proceso de desarrollo, de modo que el AyD se adapte a los distintos modelos de proceso que se estudiaron. Además de ofrecer una posible clasificación de la aplicación evaluada, como uno u otro tipo de ofrecer herramienta CASE (en caso de que encaje con alguna). Respecto a las métricas de la característica Correctitud, permiten medir la calidad del análisis y del diseño del sistema en construcción, que ofrecerá la herramienta. Finalmente, las métricas incluidas en la característica Encapsulado, están orientadas a evaluar cuánto ayudará la herramienta al usuario, a realizar un análisis granular, detallado y coherente. Las nuevas métricas agregadas en la categoría Usabilidad, permiten evaluar cuán dependiente es la herramienta de la filosofía de desarrollo FLOSS. En la medida en que el usuario necesite altos conocimiento de Software Libre para instalar o utilizar el sistema, mayor será la dependencia de la aplicación a dicha filosofía de trabajo, entrando en conflicto con los principios constructivistas, relacionados en este trabajo de investigación con el desarrollo en comunidades propio del Software Libre, en tanto se debe permitir que el usuario tenga una experiencia previa del software, para que sea posible su futura integración a la comunidad de desarrollo. 69

70 En último lugar, las nuevas métricas de la categoría Mantenibilidad, permiten definir aspectos contextuales de la herramienta, que facilitarán o no su modificación, como parte del trabajo colaborativo característico de los desarrollos de FLOSS. La información derivada de aplicar estás métricas a una herramienta, permitirá saber la cantidad y calidad de recursos humanos (miembros de la comunidad de desarrollo), legales y de documentación, que se tendrán a la mano a la hora de realizar modificaciones o agregar funcionalidades a la misma. Específicamente, medir la cantidad de descargas al año que se hacen del software, ofrece una idea de la popularidad y aceptación del software por parte de los usuarios. Para justificar la creación de estas nuevas métricas, se muestra a continuación una tabla que relaciona los conceptos ilustrados en el modelo conceptual de este proyecto, con las sub - características agregadas a MOSCA (tabla 17). Sub - características Diagramas (FUN 1.1) Documentación (FUN 1.2) Vinculación entre AyD e implementación (FUN 1.3) Detalles de abstracción (FUN 2.1) Completo (FUN 5.1) Consistente (FUN 5.2) Taxonomía (FUN 7.1) Contexto de las abstracciones (FUN 7.2) Licencia (MAB 2.1) Conceptos Diseño, vistas, datos, procedimental, arquitectónico, interfaz, MDD, diseño detallado del software, diseño arquitectónico del software, análisis, enfoque de desarrollo, estructurado, Web, OO, orientado a componentes, orientado a aspectos, tejedor, clase, diagrama, de casos de uso, de secuencia, de estados, de componentes, de interacción de componentes, WAE, UML, DFD, carta estructurada, diseño de navegación, diseño de contenidos, diseño estético, modelo, especificación. Análisis, dominio del problema, requerimiento, análisis de necesidades, metodología de desarrollo, M. Planificada, alta documentación, baja documentación, M. Ágil. Prototipos, diseño rápido, metodología de desarrollo, M. Ágil, producción rápida, modelo en espiral, modelo orientado a la reutilización, cascada, caos. Análisis, diseño detallado, especificación. UML, Diseño, especificación. Análisis, calidad. Análisis, diseño, vista, diagrama. Análisis Proceso (vinculado a conceptos de FLOSS) Tabla 17: Relación entre el modelo conceptual y las nuevas sub - características. Fuente: elaboración propia. En conclusión, se incorporó un conjunto de métricas que permiten valorar en qué medida las herramientas a estudiar, cumplen con características funcionales y propias a los proyectos de Software Libre, deseables en un software que soporte el AyD de sistemas; yendo desde tipos de diagramas disponibles, hasta especificaciones legales de la licencia del software. Seguidamente, se llevará a cabo otro paso de la etapa tomar la acción de la metodología empleada para el desarrollo de este trabajo, por lo que en el capítulo 6 se muestra la aplicación de esta instanciación de MOSCA 70

71 CAPÍTULO 7. APLICACIÓN DE LA INSTANCIACIÓN Una vez definida la instanciación de MOSCA diseñada para este proyecto, el paso siguiente es la aplicación de dicha instanciación a un conjunto de herramientas de Software Libre que soporten el AyD de sistemas. En este capítulo se describen las herramientas que fueron objeto de evaluación, los resultados de dicha aplicación y la selección de la herramienta que será modificada en función de esos resultados Herramientas sujetas a evaluación En total fueron evaluadas las siguientes 8 herramientas: StarUML, ArgoUML, BOUML, Fujaba, UMLet y Papyrus, que son herramientas para modelado UML; DIA, que es una herramienta que permite modelar distintos tipos de sistemas, con distintos tipos de lenguajes, entre los que se encuentra UML; y finalmente DBDesigner, software que permite modelar bases de datos. Todas estás herramientas son gratuitas y con licencias de Software Libre. En el mercado existe un amplio conjunto de herramientas de modelado UML, y se considera que las seis seleccionadas constituyen una muestra representativa, en tanto son producto, algunas de iniciativas particulares, otras de proyectos académicos y otras como alternativa análoga a herramientas comerciales. En el caso de DIA, fue seleccionada por su versatilidad y popularidad en el sector académico. Y DBDesigner, fue seleccionada para contemplar también herramientas que no fuesen exclusivamente de modelado UML y que permitieran el diseño de la base de datos, vista del software cuyo modelado no se contempla en el UML. A continuación se describen brevemente las herramientas seleccionadas, para luego mostrar el resultado de la aplicación de la instanciación de MOSCA, a cada una de ellas. Herramienta Descripción Versión Lenguaje OS Web Oficial StarUML Herramienta de modelado Delphi (mayormente) Windows UML 2.0. Proyecto multilingüe ArgoUML BOUML Fujaba UMLet Papyrus herramienta de modelado UML 1.4 herramienta de modelado UML 2 herramienta de modelado UML herramienta de modelado UML 2.0 herramienta de modelado UML 2.0, basada en 0.24 Java Cualquier plataforma C++, Java Windows, Unix/Linux y Mac OS X Java Windows, Linux y Mac OS X 7.1 Java Windows, Linux y Mac OS X Java Windows, Linux/gtkx86 en/ ads/index.html

72 DIA DBDesigner ambiente Eclipse herramienta de diagramación, incluido UML herramienta para modelar bases de datos Phyton Windows, Unix/Linux Beta Delphi Windows 2k/XP, Linux KDE/Gnome Tabla 18: Herramientas seleccionadas a evaluar. Fuente: elaboración propia. s/dia/ igner4/ 7.2. Resultados de la aplicación El MOSCA instanciado se aplicó a las 8 herramientas descritas anteriormente. Es relevante señalar, que para algunas métricas de la característica Atributos de Madurez del Software, en la categoría Mantenibilidad, no se encontró la información necesaria para calificar el software. En estos casos se le asignó la puntuación mínima. Para la métrica que mide el porcentaje de parches de seguridad solucionados por la comunidad, en la característica Estabilidad de la categoría Mantenibilidad, en los casos en que no se encontró registro de parches de seguridad, por ser la formulación una relación (parches solucionados / parches encontrados) expresada en porcentaje, se le puntuó con el 100%. La tabla 19 presenta un resumen de los resultados parciales de cada característica, los resultados globales de cada categoría y la evaluación final de calidad para cada herramienta evaluada; además de un promedio por renglón, que permite analizar el comportamiento de las herramientas en cada una de las características, con respecto al resto de las aplicaciones. Posteriormente, los gráficos presentados en las figuras 15, 16 y 17 comparan los resultados de evaluar las 8 herramientas seleccionadas, en las categorías Funcionalidad, Usabilidad y Mantenibilidad, respectivamente. 72

73 Tabla 19: Resultados de la evaluación. Fuente: elaboración propia. 73

74 Evaluación de Categoría: FUNCIONALIDAD 100,000% 88,889% 75,000% 66,667% 66,667% 71,429% Porcentaje 50,000% 33,333% 44,444% 33,333% 44,444% 25,000% 0,000% StarUML ArgoUML BOUML Fujaba Dia Papyrus UMLet DBDesigner Figura 15: Resultados de la evaluación en la categoría Funcionalidad Fuente: Elaboración propia. Evaluación de Categoría: USABILIDAD 100% 100% 100% 80% 80% 80% 80% 80,000% 75% Porcentaje 50% 40% 25% 0% StarUML ArgoUML BOUML Fujaba Dia Papyrus UMLet DBdesigner Figura 16: Resultados de la evaluación en la categoría Usabilidad Fuente: Elaboración propia. 74

75 Evaluación de Categoría: MANTENIBILIDAD 100,000% 85,714%85,714% 75,000% 71,429% Porcentaje 50,000% 42,857%42,857% 42,857% 53,571% 25,000% 14,286% 0,000% StarUML ArgoUML BOUML Fujaba Dia Papyrus UMLet DBDesigner Figura 17: Resultados de la evaluación en la categoría Mantenibilidad Fuente: Elaboración propia. Los datos detallados de la aplicación de MOSCA a las 8 herramientas pueden ser observados en el Anexo 1. Dando continuidad a la metodología utilizada, a continuación se realiza el Análisis de los resultados Análisis de resultados y selección de la herramienta En las figuras mostradas en la sección anterior se evidencia que StarUML es la herramienta que posee el porcentaje más alto en Funcionalidad, con una diferencia del 17,46% del segundo mejor (DBDesigner). Respecto a la Usabilidad, comparte el primer lugar con ArgoUML al obtener el 100%, y respecto a la Mantenibilidad, comparte el primer lugar con ArgoUML, habiendo obtenido un % de satisfacción. Según el algoritmo de MOSCA y en base a estos resultados, StarUML posee un nivel Avanzado de Calidad. Todas las demás herramientas poseen un porcentaje de Funcionalidad menor a 75% y por lo tanto tienen un nivel de calidad Nulo. Por estas razones, StarUML es la herramienta seleccionada. El próximo paso es detallar cuáles características y sub-características deben mejorarse, en función de los resultados obtenidos de la evaluación, de modo que se puedan determinar posteriormente los requerimientos a ser incorporados en la nueva versión de la herramienta seleccionada. Sólo Funcionalidad y Mantenibilidad no llegaron al 100% de satisfacción, por lo que seguidamente se detallarán los aspectos mejorables de StarUML en ambas categorías. 75

76 Sub-características mejorables de Funcionalidad para StarUML La figura 18, muestra un desglose de la Funcionalidad para StarUML, en donde se observan tres sub-características por debajo del 100% y corresponden a Diagramas, Interoperabilidad y Consistente. Comparación de las sub - características de FUNCIONALIDAD para STARUML 100,000% 100% 100% 100% 100% 100% 100% 75,000% 76,471% 75% Porcentaje 50,000% 25,000% 25% 0,000% Diagramas Vinculación entre A y D e Implementación Interoperabilidad Consistente Contexto de las abstracciones Documentación Detalles de abstracción Completo Taxonomía Figura 18: Comparación de las sub-características de Funcionalidad para StarUML. Fuente: Elaboración propia Comencemos por detallar las métricas de la sub-característica Diagramas. En la tabla 20 observamos que existen 4 tipos de diagramas, de los que la evalúa el MOSCA instanciado, que StarUML no realiza: diagramas de interacción, diagramas de tiempo, diagramas WAE y diagramas de modelado del negocio. Las métricas que no aplican (NA), es porque evalúan que la herramienta realice diagramas que no son UML. StarUML es un software diseñado para modelar con el Lenguaje Unificado, por lo que no se le exige realizar diagramas con otros lenguajes. Al incorporar la posibilidad de elaborar estos cuatro tipos de diagramas, dicha sub-categoría llegaría la 100% de satisfacción. 76

77 Métricas Rol Formulación Respuesta Líder Respuesta Desarrollador Respuesta usuario Permite realizar diagramas de clase? Usuario 1 si - 0 no 1 Permite realizar diagramas de estructura de composición? Usuario 1 si - 0 no 1 Permite realizar diagramas de componentes? Usuario 1 si - 0 no 1 Permite realizar diagramas de despliegue? Usuario 1 si - 0 no 1 Permite realizar diagramas de objetos? Usuario 1 si - 0 no 1 Permite realizar diagramas de paquetes? Usuario 1 si - 0 no 1 Permite realizar diagramas de actividades? Usuario 1 si - 0 no 1 Permite realizar diagramas de casos de uso? Usuario 1 si - 0 no 1 Permite realizar diagramas de máquinas de estado? Usuario 1 si - 0 no 1 Permite realizar diagramas de secuencia? Usuario 1 si - 0 no 1 Permite realizar diagramas de comunicación? (diagramas de colaboración) Usuario 1 si - 0 no 1 Permite realizar diagramas de revisión de interacción? Usuario 1 si - 0 no 0 Permite realizar diagramas de tiempos? Usuario 1 si - 0 no 0 Permite realizar diagramas WAE? Usuario 1 si - 0 no 0 Permite realizar diagramas para el modelado del negocio? Usuario 1 si - 0 no 0 Permite realizar el diseño de datos, diagramas ER y/o ER-E? Usuario 1 si - 0 no NA Permite realizar diagramas de flujo de datos (DFD)? Usuario 1 si - 0 no NA Permite realizar diagramas de flujo de control (DFC)? Usuario 1 si - 0 no NA Permite realizar cartas estructuradas? Usuario 1 si - 0 no NA Permite realizar el diseño de la interfaz? Usuario 1 si - 0 no NA Permite realizar el diseño estético para aplicaciones Web? Usuario 1 si - 0 no NA Permite realizar el diseño de contenidos para aplicaciones Web? Usuario 1 si - 0 no NA Permite realizar el diseño de navegación para aplicaciones Web? Usuario 1 si - 0 no NA Permite realizar el diseño arquitectónico de la estructura hipermedia para aplicaciones Web? Usuario 1 si - 0 no NA 77

78 Permite realizar metamodelos para aspectos (para aplicaciones desarrolladas con enfoque orientado a aspectos)? Usuario 1 si - 0 no NA Permite modelar la descomposición y/o composición aspectual del dominio del problema (para el análisis de aplicaciones desarrolladas con enfoque orientado a aspectos)? Usuario 1 si - 0 no NA Permite diseñar la recomposición de los aspectos a través de una clase tejedor (para aplicaciones desarrolladas con enfoque orientado a aspectos)? Usuario 1 si - 0 no NA Permite convertir diagramas o generar unos a partir de otros? Usuario 1 si - 0 no 1 Permite exportar los diagramas a otros formatos? Usuario 1 si - 0 no 1 Tabla 20: Métricas de la sub-característica Diagramas. Fuente: Elaboración propia A continuación detallemos las métricas satisfechas con menos de los 100%, referidas a la Interoperabilidad. Cómo vimos anteriormente, la Interoperabilidad sólo alcanzó un 25% de satisfacción, convirtiéndose en la categoría con puntuación más baja y esto se debe a que de 4 métricas que aplican a la herramienta, 3 obtuvieron puntuación cero (0), tal y como se observa en la tabla 21. En conjunto, estás métricas evalúan la capacidad de StarUML de operar en conjunto con otros sistemas, ya sea intercambiando funcionalidades o datos. StarUML no realiza alguna de estas funciones con otros sistemas. Las métricas que no aplican, es porque son dependientes de métricas anteriores en la misma subcategoría, es decir, sólo admiten evaluación en caso de que la respuesta a la anterior haya sido positiva. Por ejemplo, la proporción entre las funcionalidades que pertenecen a otros sistemas y el total de funcionalidades del producto, no aplica porque tales funcionalidades no existen. A diferencia de la sub-categoría anterior, no se puede afirmar que al desarrollar módulos para que StarUML se pueda comunicar con algún otro sistema (como una plataforma de desarrollo, una herramienta para manejo de requerimientos, entre otros), el porcentaje de satisfacción llegue al 100%. Esto se debe a que, en tal caso, habría que dar respuesta a las preguntas dependientes que actualmente no aplican. Métricas Rol Formulación Existen funcionalidades utilizadas por el producto, que pertenecen a otro sistema? Cuál es la proporción entre las funcionalidades que pertenecen a otros sistemas y el total de funcionalidades del producto? Existen funcionalidades utilizadas por otros sistemas, que pertenecen al producto? Respuesta Líder Respuesta Desarrollador Desarrollador 1 si - 0 no 0 Desarrollador Funcionalidades que pertenecen a otros sistemas / Funcionalidades del producto NA Respuesta usuario Usuario 1 si - 0 no 0 78

79 Existe intercambio de datos con otros sistemas? Existe consistencia con las interfaces de los otros sistemas? Cómo es la complejidad al pasar a una funcionalidad en otro sistema? Existen funcionalidades en otros sistemas que son necesarias? Desarrollador Usuario 1 si - 0 no 0 Desarrollador 1 si - 0 no NA Usuario Usuario Desarrollador 1 No tiene - 2 Básica - 3 Mediana - 4 Alta - 5 Muy Alta NA 1 si - 0 no 1 Tabla 21: Métricas de la sub-característica Interoperabilidad. Fuente: Elaboración propia Finalmente detallemos las métricas respecto a la Consistencia, que alcanzó sólo un 75%. En la tabla 22 se observa que de las 4 métricas de esta sub-categoría, sólo una dejó de satisfacerse y corresponde a la consistencia de los diagramas generados a partir de otros. StarUML ofrece la opción de convertir diagramas de secuencia en diagramas de colaboración y viceversa, sin embargo, al ejecutar esta funcionalidad el sistema arroja un error y no genera el diagrama requerido. Por eso la puntuación en esta métrica ha sido 1. De corregir esta falla, la subcategoría Consistente alcanzaría el 100% de satisfacción. Métricas Rol Formulación Las abstracciones que pueden ser modeladas mantienen sus propiedades? El código generado es consistente con los diagramas originales? Los diagramas generados por ingeniería de reversa son consistentes con el código original? Los diagramas generados a partir de otros, son consistentes con los originales? Usuario Desarrollador Usuario Usuario Usuario 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente 1 No - 2 Regular - 3 Bien - 4 Muy Bien - 5 Excelente Respuesta Líder Respuesta Desarrollador Tabla 22: Métricas de la sub-característica Consistente. Fuente: Elaboración propia Respuesta usuario Según los resultados de los anteriores son los aspectos de StarUML que deben mejorarse respecto a las características de Funcionalidad de la herramienta. Seguidamente se analizarán los aspectos mejorables respecto a la Mantenibilidad. Sub-características mejorables de Mantenibilidad para StarUML La figura 19, muestra un desglose de la Mantenibilidad para StarUML, en donde se observan dos sub-características por debajo del 100% y corresponden a Capacidad de cambio y Estabilidad. La primera con un 80% de satisfacción y la segunda con un 50%. 79

80 En primer lugar, analicemos con detalle las métricas, satisfechas con menos del 100%, que corresponden a la Capacidad de cambio de la herramienta. En la tabla 23 se observa que sólo una de las métricas contempladas en esta sub-característica, obtuvo una puntuación inferior a la requerida para considerarse aceptable y es la que evalúa si se identifican y manejan las mejoras a StarUML por concepto de cambios de tecnologías de acuerdo a las necesidades del usuario. En los mecanismos dispuestos por la comunidad de desarrollo, en el sitio Web oficial de StarUML, se tienen identificadas las mejoras a la herramienta e incluso se listan las solicitudes de los usuarios respecto a nuevas funcionalidades, sin embargo no se distinguen ni se identifican las posibles mejoras por cambios de tecnologías (no se encontraron ni solicitudes ni mejoras al respecto). Comparación de las sub - características de MANTENIBILIDAD para STARUML 100% 100% 80% 100% 100% 100% 100% 75% Porcentaje 50% 50% 25% 0% Capacidad de Análisis Licencia Acoplamiento Atributos de Madurez del Software Capacidad de Cambio Estabilidad Cohesión Figura 19: Comparación de las sub-características de Mantenibilidad para StarUML. Fuente: Elaboración propia En el caso de que la comunidad de desarrollo contemple hacer una distinción de las posibles mejoras por concepto de cambios de tecnología, las incluyan como necesidades funcionales o no funcionales (de existir) y las listen con el resto de los requerimientos por implementar, dicha métrica obtendría un puntaje satisfactorio y la sub-característica Capacidad de cambio llegaría al 100%. 80

81 Métricas Rol Formulación Son registrados los cambios en los módulos? Está la funcionalidad del software repartida en módulos diferentes? Existe un mecanismo para incorporar nuevos requerimientos del cliente? Se tienen identificadas y manejadas las mejoras por cambios de tecnologías de acuerdo a las necesidades del cliente? Existe consistencia entre los requerimientos, diseño del sistema, e implementación? Respuesta Líder Respuesta Desarrollador Desarrollador 1 si - 0 no 1 Desarrollador Desarrollador Líder Desarrollador Desarrollador 1 No - 2 Poco definidos - 3 Medianamente - 4 Casi todo - 5 Completamente 1 No están definidos - 2 Poco definidos - 3 Medianamente definidos - 4 Casi todos definidos - 5 Completamente definidos 1 No están definidos - 2 Poco definidos - 3 Medianamente definidos - 4 Casi todos definidos - 5 Completamente definidos 1 No están definidos - 2 Poco definidos - 3 Medianamente definidos - 4 Casi todos definidos - 5 Completamente definidos Tabla 23: Métricas de la sub-característica Capacidad de Cambio. Fuente: Elaboración propia Respuesta usuario En segundo lugar, estudiemos detalladamente la subcategoría Estabilidad, que ha sido satisfecha sólo en un 50%. Según se muestra en la tabla 24, de las dos métricas que evalúan la estabilidad de la herramienta, la que mide si la comunidad de desarrollo trabaja con una matriz de impacto obtuvo puntuación cero. La comunidad de desarrollo de StarUML no trabaja con una matriz que califique cuáles sectores o módulos, en caso de ser modificados, implican mayor o menor impacto en el sistema. Si la comunidad construye dicha matriz y la hace pública (por ejemplo, en su sitio Web oficial), la métrica obtendría un puntaje satisfactorio y la sub-característica alcanzaría el 100% de satisfacción. Métricas Rol Formulación Se trabaja con una matriz de impacto? Porcentaje de parches de seguridad solucionados en relación a los encontrados por la comunidad Respuesta Líder Respuesta Desarrollador Desarrollador 1 si - 0 no 0 Líder Desarrollador Porcentaje 100% Tabla 24: Métricas de la sub-característica Estabilidad. Fuente: Elaboración propia Respuesta usuario 81

82 Se han detallado todos los aspectos que la aplicación del MOSCA instanciado, para herramientas de Software Libre que soporten AyD, arrojó como mejorables en las categorías Funcionalidad y Mantenibilidad. La Usabilidad no fue necesario detallarla, en tanto se satisfizo en un 100%. En tal sentido, se obtuvieron 10 posibles mejoras a StarUML. En el capítulo siguiente, se describen y justifican cuáles de ellas serán llevadas a cabo y se especifica el proceso de desarrollo sobre StarUML, que implican incorporar estás mejoras. Es oportuno señalar que la metodología empleada para evaluar las herramientas, el diseño de la instanciación de MOSCA para herramientas FLOSS que soporten AyD de sistemas y los resultados de su aplicación a las 8 herramientas listadas, fueron insumos para la elaboración de un artículo titulado Quality Measurement Model for Analysis and Design Tools based on FLOSS, que fue sometido a la evaluación del jurado de la 19th Australian Software Engineering Conference (ASWEC 2008) y fue aprobado para presentarse en Marzo de 2008 en Perth, Western Australia. Además en el marco de dicha conferencia, los proceedings de la conferencia serán publicados por the IEEE Computer Society Press.. 82

83 CAPÍTULO 8: IMPLEMENTACIÓN DE LAS NUEVAS FUNCIONALIDADES PARA STARUML El objetivo de este capítulo es seleccionar, de la lista de aspectos mejorables obtenida en el capítulo anterior, aquellos que se traducirán en nuevas funcionalidades a implementar para StarUML y documentar dicho proceso de implementación. En cuanto a la Funcionalidad de la herramienta, específicamente lo concerniente a la sub-característica Diagramas, serán implementados los módulos de StarUML que permitan realizar los 4 tipos de diagramas que la aplicación no contempla: los diagramas WAE, los diagramas de modelado del negocio, diagramas de revisión de interacción y diagramas de tiempos. Para los primeros, se construirán dos módulos, uno que permita realizar diagramas WAE de clases y otro que permita realizar diagramas WAE de secuencia. Para los segundos, se construirán tres módulos, uno que permita realizar diagramas de casos de uso del negocio, otro que permita realizar diagramas de secuencia del negocio y un último módulo que permita realizar diagramas de modelo de objetos o análisis del negocio. Así, con los de revisión de interacción y de tiempos, suman 7 módulos de StarUML que mejoran la sub-característica Diagramas. En cuanto a la sub-característica Interoperabilidad, llevar a cabo la implementación de módulos que permitan conectar StarUML a alguna plataforma de desarrollo o herramienta de manejo de requerimientos, queda fuera del alcance de este proyecto de investigación acción, en tanto implicaría listar los sistemas con los cuáles StarUML pudiera comunicarse, diseñar una instanciación del MOSCA para evaluar estos sistemas, aplicar dicha instanciación a cada uno de la lista y seleccionar el que resulte de mayor calidad sistémica, estudiar la arquitectura de la aplicación seleccionada, identificar cuáles funcionalidades de StarUML pueden ser usadas por la otra herramienta (y viceversa), seleccionar de estas funcionalidades las que serán integradas para operar en conjunto y finalmente implementar los módulos necesarios para lograr la comunicación entre ambos sistemas. Este procedimiento corresponde a un proyecto de investigación-acción paralelo al presentado en este libro. Por último, en cuanto a Funcionalidad se refiere, se trabajará en la sub-característica Consistente, estudiando el módulo que permite realizar conversión de diagramas de secuencia en diagramas de colaboración, con miras a detectar sus fallas. Por limitaciones de tiempo no se contemplará dentro del alcance de la implementación la corrección de estas fallas. Las sub-características de Mantenibilidad que deben ser mejoradas, es decir, la capacidad de cambio y la estabilidad, dependen de la comunidad de desarrollo. Como se mostró en el capítulo anterior, las acciones necesarias para que las métricas respectivas aumenten su puntuación y la Mantenibilidad alcance un 100% de satisfacción, depende de que la comunidad de desarrollo de StarUML defina, básicamente, dos nuevas estrategias de trabajo: manejar una matriz de impacto y manejar posibles mejoras por cambios de tecnología, e incorporar estos mecanismos en el sitio Web oficial. Por lo tanto, escapa del alcance de este proyecto y su ejecutor, dar lugar a estas mejoras. Sin embargo, notificará a 83

84 los líderes desarrolladores de esta comunidad sobre la necesidad de estas estrategias de trabajo y las tomen en cuenta como sugerencias. En el capítulo 2, se presentaron las etapas que dan cuerpo al proceso de desarrollo de Software Libre y código abierto. A continuación se describe el proceso de desarrollo de las mejoras incorporadas a StarUML, siguiendo el modelo citado Descripción del proceso de desarrollo de mejoras para StarUML El modelo de proceso de desarrollo de FLOSS expuesto en el marco teórico, sugiere cinco etapas: código, revisión, pruebas previas, liberación de desarrollo y eliminación paralela de fallos y liberación del producto. A estas cinco, se agregará una etapa inicial cero (0), en donde se adquieran los conocimientos previos, de los que se habla en la teoría constructivista previamente comparada con la filosofía FLOSS, necesarios para iniciar la fase de codificación. Estos conocimientos incluyen una descripción de la arquitectura de la herramienta, un estudio de las estrategias que ofrece la comunidad de desarrollo para incorporar mejoras al sistema y una breve descripción de los estereotipos que se utilizan en los distintos tipos de diagramas a implementar. A continuación, la descripción de cada una de las fases: Fase 0. Adquisición de conocimientos previos (Resumen) StarUML es una plataforma de modelado de software que ofrece diversas estrategias de extensión de sus funcionalidades. Es una aplicación que está bajo una licencia GPL (Licencia Pública GNU. Ver características en la sección 2.3 del presente trabajo). Su arquitectura puede describirse en función de dos conjuntos. El primero de ellos es la plataforma MDA (Model Driven Architecture), los cimientos básicos de la aplicación y el segundo, compuesto por las partes extensibles. Las partes extensibles son las siguientes: Enfoques (approach): que definen el modelo del proyecto y la organización de los diagramas. Perfiles UML (Profiles) y extensiones de notación: que definen las extensiones a los modelos y diagramas de UML. Marcos de trabajo de modelos: estos marcos de trabajo permiten realizar modelos de software reutilizables. Add-Ins COM-Object: para agregar nuevas funcionalidades a la herramienta. Extensiones de menú: StarUML permite extender sus menús. Extensión de opciones: Permite agregar nuevas opciones según se incorporen nuevas funcionalidades. Suscripción de eventos: que permita manejar cualquier evento que pueda ocurrir durante la ejecución de StarUML. API externos: que permitan acceso a las funcionalidades y a la información. Para la implementar módulos que permitan realizar los diagramas WAE y de modelado del negocio, será necesario realizar un extensión de notación UML. Para ello se deben definir los perfiles correspondientes para cada tipo de diagrama y especificar la extensión 84

85 de notación, a partir de la definición de los estereotipos que se usan en cada tipo de diagrama. Los perfiles se definen en archivos.prf y se codifican en XML. Las extensiones de notación se definen en archivos.nxt y se codifican con el lenguaje de extensión de notación especificado en el sitio Web oficial de StarUML. Los perfiles creados deben incluirse en un nuevo módulo de StarUML y posteriormente agregar dicho módulo, el directorio modules. En los anexos, se muestra un descripción de los estereotipos utilizados en los diagramas WAE y en los diagramas de modelado del negocio. Fase 1. Código Se construyeron siete módulos que implementan extensiones de notación UML, utilizando la estrategia de desarrollo descrita anteriormente. Los módulos permiten realizar diagramas WAE, de modelado del negocio, de revisión interacción y de tiempos, agregando un nuevo diagrama del tipo correspondiente, a un proyecto creado previamente a partir del enfoque (approach) por defecto que ofrece StarUML. La figura 20 ilustra cómo el sistema ofrece ahora la opción para agregar estos tipos de diagrama, haciendo clic derecho en alguno de los modelos listados en el explorador de modelos. Figura 20: Agregar un nuevo diagrama. Fuente: Elaboración propia. 85

86 Luego de agregar un diagrama del tipo deseado, el sistema ofrece una paleta con todos los estereotipos propuestos por UML 2.1 y Conallen (en el caso de los diagramas WAE), para representar los distintos tipos de clases, objetos y relaciones correspondientes. Las figuras 21 y 22 muestran, como ejemplo, la elaboración de un diagrama WAE de clases con uno de los módulos agregados. Figura 21: Elaboración de un diagrama WAE de clases con el nuevo módulo. Fuente: Elaboración propia. 86

87 Figura 22: Elaboración de un diagrama WAE de secuencia con el nuevo módulo. Fuente: Elaboración propia. 87

88 Fase 2. Revisión La revisión del producto obtenido en la fase 1, estuvo a cargo de profesores del Laboratorio de Investigación en Sistemas de Información (LISI). De esa revisión se obtuvieron recomendaciones de mejoras en el aspecto gráfico de los diagramas, en cuanto a la completitud de especificación de los estereotipos dentro de los diagramas y la inserción de estereotipos propios de otros tipos de diagramas (por ejemplo: actores en los diagramas WAE de secuencia). Fase 3. Pruebas previas Las pruebas previas se realizaron en dos instancias. En primer lugar, estuvieron a cargo de los estudiantes de Ingeniería en Computación inscritos en el curso de Sistemas de Información II, ofrecido por el departamento de Procesos y Sistemas de la Universidad Simón Bolívar. En el marco del proyecto desarrollado por los alumnos en esta materia, se les hizo entrega de los módulos que permiten realizar diagramas WAE para que los usaran en el diseño de una aplicación Web. Adicionalmente, se diseñó un instrumento que evalúa su percepción sobre los módulos generados y sobre el instrumento mismo. Las instrucciones recibidas por los alumnos para evaluar los módulos, se presentan a continuación: 1. A la derecha de cada pregunta encontrará las opciones de respuesta: siempre, casi siempre, a veces, casi nunca, nunca. Para cada pregunte seleccione sólo una de estas posibles respuestas y marque una X en la casilla correspondiente. 2. Debajo de cada pregunta, encontrará cuatro casillas que permiten evaluar la pertinencia, factibilidad, profundidad y escala de dicha pregunta. Estas casillas deberán ser llenadas según los criterios descritos en la tabla 25. Pertinencia Factibilidad Nivel de profundidad Escala Se refiere a si una pregunta es adecuada para medir la existencia o no de la característica. Se refiere a si es factible medir la característica propuesta en la pregunta dentro del contexto de evaluación Se refiere a si la pregunta a verificar tiene el nivel de profundidad adecuado para que el resultado sea relevante Se refiere a si la escala propuesta es adecuada para medir la pregunta 1: significa que la pregunta es pertinente 0: significa que la pregunta no es pertinente 1: significa que la pregunta es factible 0: significa que la pregunta no es factible 1: significa que la pregunta tiene el nivel de profundidad adecuado 0: significa que se requiere una mayor profundidad en la pregunta 1: significa que la escala es adecuada 0: significa que la escala no es adecuada Tabla 25: Criterios para evaluar el instrumento. Fuente: Elaboración propia El cuestionario fue dividido en dos partes, una por módulo, que se presentan en las tablas 26 y

89 Pregunta Siempre Casi siempre La extensión de notación hecha sobre StarUML para realizar diagramas WAE de clase, respeta la notación propuesta por UML para aplicaciones Web? Pertinencia Factibilidad Profundidad Escala A veces Casi nunca Nunca El estilo gráfico de los diagramas WAE de clase, es consistente con el resto de la herramienta (StarUML)? Pertinencia Factibilidad Profundidad Escala Funciona correctamente la extensión de notación para diagramas WAE de clase? Pertinencia Factibilidad Profundidad Escala La extensión de notación para diagramas WAE de clase, satisface las necesidades del usuario? Pertinencia Factibilidad Profundidad Escala Es necesario tener conocimientos de Software Libre para instalar el módulo? Pertinencia Factibilidad Profundidad Escala Tabla 26: Cuestionario para evaluar el módulo StarUML-WAEClass. Fuente: Elaboración propia Pregunta Siempre Casi siempre La extensión de notación hecha sobre StarUML para realizar diagramas WAE de secuencia, respeta la notación propuesta por UML para aplicaciones Web? Pertinencia Factibilidad Profundidad Escala A veces Casi nunca Nunca El estilo gráfico de los diagramas WAE de secuencia, es consistente con el resto de la herramienta (StarUML)? Pertinencia Factibilidad Profundidad Escala Funciona correctamente la extensión de notación para diagramas WAE de secuencia? Pertinencia Factibilidad Profundidad Escala La extensión de notación para diagramas WAE de secuencia, satisface las necesidades del usuario? Pertinencia Factibilidad Profundidad Escala Es necesario tener conocimientos de Software Libre para instalar el módulo? Pertinencia Factibilidad Profundidad Escala Tabla 27: Cuestionario para evaluar el módulo StarUML-WAESequence. Fuente: Elaboración propia 89

90 Los gráficos que aparecen a continuación, muestran los resultados de aplicar este instrumento a 4 grupos de trabajo (de 6 personas c/u). La extensión de notación hecha sobre StarUML para realizar diagramas WAE de clase, respeta la notación propuesta por UML para aplicaciones Web? La extensión de notación hecha sobre StarUML para realizar diagramas WAE de clase, respeta la notación propuesta por UML para aplicaciones Web? , % Nº de respuestas afirmativas 2,5 2 1,5 1 2 Siempre A veces Nunca Casi siempre Casi nunca 0,5 0 Pertinencia Profundidad Factibilidad Escala Figura 23: Respuestas a la pregunta 1 del instrumento de evaluación para el módulo StarUML-WAEClass. Fuente: Elaboración propia. El estilo gráfico de los diagram as WAE de clase, es consistente con el resto de la herram ienta (StarUML)? El estilo gráfico de los diagramas WAE de clase, es consistente con el resto de la herramienta (StarUML)? , % N º de r e s pue s t a s a f i r ma t i v a s 2 1,5 1 0,5 0 Siem pre A veces Nunca Casi siem pre Casi nunca Pertinencia Profundidad Factibilidad Es cala Figura 24: Respuestas a la pregunta 2 del instrumento de evaluación para el módulo StarUML-WAEClass. Fuente: Elaboración propia. 90

91 Funciona correctamente la extensión de notación para diagramas WAE de clase? Funciona correctamente la extensión de notación para diagramas WAE de clase? ,5 N º de 2,5 r e s pue s t a s 2 a f i r ma t i v a s 1,5 1 0, Siem pre A veces Nunca 100% Casi siem pre Casi nunca Pertinencia Profundidad Factibilidad Escala Figura 25: Respuestas a la pregunta 3 del instrumento de evaluación para el módulo StarUML-WAEClass. Fuente: Elaboración propia. La extensión de notación para diagramas WAE de clase, satisface las necesidades del usuario? La extensión de notación para diagramas WAE de clase, satisface las necesidades del usuario? % 25% Nº de respuestas afirmativas 4 3,5 3 2,5 2 1,5 1 0, Siempre A veces Nunca Casi siempre Casi nunca Pertinencia Profundidad Factibilidad Escala Figura 26: Respuestas a la pregunta 4 del instrumento de evaluación para el módulo StarUML-WAEClass. Fuente: Elaboración propia. 91

92 Es necesario tener conocimientos de software libre para instalar el módulo? Es necesario tener conocimientos de software libre para instalar el módulo? 25% % 25% 2 1,8 1,6 1,4 1,2 Nº de respuestas 1 afirmativas 0,8 0,6 0,4 0, Siempre A veces Nunca Casi siempre Casi nunca Pertinencia Profundidad Factibilidad Escala Figura 27: Respuestas a la pregunta 5 del instrumento de evaluación para el módulo StarUML-WAEClass. Fuente: Elaboración propia. La extensión de notación hecha sobre StarUML para realizar diagramas WAE de secuencia, respeta la notación propuesta por UML para aplicaciones Web? La extensión de notación hecha sobre StarUML para realizar diagramas WAE de secuencia, respeta la notación propuesta por UML para aplicaciones Web? Nº de respuestas afirmativas % 0 Siempre A veces Nunca Casi siempre Casi nunca Pertinencia Profundidad Factibilidad Escala Figura 28: Respuestas a la pregunta 1 del instrumento de evaluación para el módulo StarUML-WAESequence. Fuente: Elaboración propia. 92

93 El estilo gráfico de los diagramas WAE de secuencia, es consistente con el resto de la herramienta (StarUML)? El e st i l o g r áf i c o d e l o s d i a g r a m a s WA E d e se c u e n c i a, e s c o n si st e n t e c o n e l r e st o d e l a h e r r a m i e n t a ( S t a r U M L )? 4 25% 4 3, % N º de r e s pue s t a s a f i r ma t i v a s 2,5 2 1,5 1 Siem pre A veces Nunca Casi siem pre Casi nunca 0,5 0 Pertinencia Factibilidad Prof undidad Escala Figura 29: Respuestas a la pregunta 2 del instrumento de evaluación para el módulo StarUML-WAESequence. Fuente: Elaboración propia. Funciona correctamente la extensión de notación para diagramas WAE de secuencia? Funciona correctamente la extensión de notación para diagramas WAE de secuencia? ,5 3 3 Nº de respuestas afirmativas 2,5 2 1, % 0,5 0 Siempre A veces Nunca Casi siempre Casi nunca Pertinencia Profundidad Factibilidad Escala Figura 30: Respuestas a la pregunta 3 del instrumento de evaluación para el módulo StarUML-WAESequence. Fuente: Elaboración propia. 93

94 La extensión de notación para diagramas WAE de secuencia, satisface las necesidades del usuario? La extensión de notación para diagramas WAE de secuencia, satisface las necesidades del usuario? , % 50% Nº de respuestas afirmativas 2,5 2 1,5 1 Siempre A veces Nunca Casi siempre Casi nunca 0,5 0 Pertinencia Profundidad Factibilidad Escala Figura 31: Respuestas a la pregunta 4 del instrumento de evaluación para el módulo StarUML-WAESequence. Fuente: Elaboración propia. Es necesario tener conocimientos de software libre para instalar el módulo? Es necesario tener conocimientos de software libre para instalar el módulo? % Siempre A veces Nunca 25% 25% Casi siempre Casi nunca 2 1,8 1,6 1,4 1,2 Nº de respuestas 1 afirmativas 0,8 0,6 0,4 0,2 0 1 Pertinencia Profundidad 1 Factibilidad Escala Figura 32: Respuestas a la pregunta 5 del instrumento de evaluación para el módulo StarUML-WAESequence. Fuente: Elaboración propia. Según estos resultados, los módulos implementados satisfacen las necesidades del usuario, funcionan correctamente y son consistentes con el resto de la herramienta, en niveles o porcentajes satisfactorios. Un alto porcentaje de los evaluadores considera que no es necesario tener conocimientos de Software Libre para instalar los módulos. Y el instrumento de evaluación fue bien calificado en cuanto a la pertinencia, factibilidad, profundidad y escala de evaluación de las preguntas; excepto la número 5, que fue 94

95 considerada por la mayoría como poco pertinente, para ambos módulos. Cabe destacar que sólo fueron sometidos a estas pruebas los módulos WAE, debido a que eran los únicos desarrollados completamente para el trimestre septiembre diciembre de 2007, los demás terminaron de implementarse una vez terminado dicho período académico, por lo que no se contaba con la disposición de los alumnos para aplicar los cuestionarios. La segunda instancia de prueba a la que fueron sometidos los módulos, estuvo a cargo de los líderes desarrolladores de la comunidad de StarUML. Los módulos fueron enviados a la comunidad de desarrollo de StarUML para su revisión. Los líderes desarrolladores recibieron y revisaron los módulos, pero no emitieron una calificación cuantitativa. De esta manera, los módulos WAE fueron evaluados interna (el código por parte de la comunidad StarUML) y externamente (la funcionalidad por parte de los alumnos de la materia PS6116, en el trimestre setiembre diciembre 2007). Fase 4. Liberación de desarrollo y eliminación paralela de fallos Se corrigieron los fallos y se incorporaron las recomendaciones hechas por los profesores de LISI, a los módulos implementados. Fase 5. Liberación del producto Los líderes desarrolladores de la comunidad de StarUML, una vez aprobados los módulos implementados y enviados durante la fase de revisión (aquellos permiten realizar diagramas WAE), procedieron a publicarlos en la página oficial de la herramienta. Los módulos WAE pueden obtenerse en la Web, desde la dirección específicamente en la sección de Módulos. El resto de los módulos implementados también fueron enviados a la comunidad de StarUML y aún al momento de redactar este libro, se espera su aprobación. Además de seguir el modelo de proceso de desarrollo para Software Libre, también puede afirmarse, que este proyecto cumple con algunas características de los modelos económicos de Software Libre, propuestos por Ubuntu (2005) y listados en el marco teórico. Específicamente, coincide con los modelos Liberador, Artístico y Académico. Finalmente se puede considerar que el proceso utilizado cumple con las características de un proceso constructivista, dado que partió de la adquisición de un conjunto de conocimientos previos y dependió del las actividades externas e internas (aprendizaje) del aprendiz o desarrollador. En este caso el autor del presente proyecto de investigación acción, ha sido el responsable último de su propio aprendizaje y la actividad mental constructiva del alumno, se aplicó a contenidos que ya poseen un grado considerable de elaboración (Coll, 1990). 95

96 CAPÍTULO 9. CONCLUSIONES, RECOMENDACIONES Y LOGROS ADICIONALES Como producto de este trabajo de investigación acción, y del análisis de los conocimientos y resultados obtenidos por parte del autor, se presentan las siguientes conclusiones: El AyD de sistemas puede entenderse a nivel teórico como fase del proceso de desarrollo o como conjunto de actividades, entre otras acepciones. Sin embargo, asumirlos como una disciplina integrada (definiendo qué, cómo, cuándo y quién) adaptable a diferentes modelos de procesos, enfoques de desarrollo y metodologías, podría garantizar la planificación y posterior implementación de un sistema de calidad, sin que se excluyan las implicaciones prácticas de las otras construcciones conceptuales (fase, actividad, etc.) y sin reñirse con ningún tipo de modelo, enfoque o metodología (incluso las ágiles). Se elaboró un modelo conceptual que reúne las construcciones teóricas relativas al AyD de sistemas, encontrados en la literatura. Este modelo conceptual constituye un aporte en el área del desarrollo de software puesto que el AyD fue estudiado desde tres niveles de abstracción: los modelos de proceso, los enfoques de desarrollo y las metodologías de desarrollo, de lo cuál no se encontró precedente en la literatura. Dadas las definiciones de AyD de sistemas, en sus distintas acepciones, se puede afirmar que no basta que un software permita diagramar para considerarlo una herramienta de AyD; es necesario que ofrezca funcionalidades que integren el proceso de análisis a la diagramación, que permitan vincular los diagramas y manejar sus relaciones, caracterizar con cierto nivel de detalle las abstracciones que conforman el diseño, manejar los diagramas en un ambiente en donde analistas y diseñadores puedan administrarlos individualmente y agrupados según las vistas de diseño y que de alguna manera facilite la verificación de la trazabilidad. Indiferentemente del modelo de proceso, enfoque o metodología, se encontró que el modelado del sistema, en menor o mayor medida, se considera indispensable en el desarrollo de software, por parte de los teóricos del área. Al comparar la dinámica de desarrollo de Software Libre, con la teoría constructivista del aprendizaje, se logró comprender parte de las estructuras cognitivas que hace del Software Libre una filosofía de desarrollo productiva, incluyente y cada vez más aceptada. Además, se incorporó al modelo típico de desarrollo de FLOSS una etapa inicial que formaliza la adquisición de los conocimientos previos para poder iniciar el desarrollo. Esta era una etapa que se llevaba a cabo, pero se mantenía implícita. Se diseño una instanciación del Modelo Sistémico de Calidad que cuenta con 105 métricas, de las cuales 53 son nuevas, que permiten medir la calidad de herramientas de Software Libre que soporten el AyD de sistemas. No existía un modelo de calidad específico para herramientas con estás características. Habiendo estudiado las posibilidades expresivas de UML y listado los diagramas que son necesarios para realizar un AyD completo, resultó que son pocas las 96

97 herramientas que satisfacen esas necesidades. De las 8 herramientas, 7 fueron calificadas con calidad nula. La extensión de notación realizada para StarUML, la constituye como una herramienta privilegiada, en tanto ahora soporta otro enfoque de desarrollo como lo es el Web, permitiendo realizar diagramas WAE de clase y de secuencia. También resulta privilegiada porque, a diferencia de las demás estudiadas, ahora ofrece la posibilidad de modelar el negocio (mediante casos de negocio, objetos del negocio y secuencia de los objetos del negocio), contemplando una nueva variable de los procesos de desarrollo. Además de permitir modelar la revisión y los tiempos de las interacciones. Las herramientas que soportan AyD buscan cada vez más integrar diferentes etapas del desarrollo, como por ejemplo la implementación a partir de la generación de código. Esto invita a que se reevalúe el rol del programador, en tanto se apunte a realizar un buen AyD y que la herramienta haga el resto. A partir de los resultados obtenidos, se han contemplado las siguientes recomendaciones para futuros trabajos relacionados con el actual: Extender la instanciación de MOSCA para evaluar otros aspectos de la Mantenibilidad de la herramienta, que arrojen mayor información acerca de la estabilidad y la capacidad de análisis. Profundizar la evaluación de los módulos de StarUML que permiten generar diagramas de colaboración a partir de los de secuencia y viceversa, hasta encontrar los errores y corregirlos. Se puede plantear otro trabajo de grado que evalúe cuáles herramientas pueden ínter operar con StarUML, realizar una instanciación de MOSCA producto que arroje la mejor herramienta y tomar las acciones de desarrollo pertinentes para elevar la puntuación obtenida por StarUML en la sub-característica Interoperabilidad. Finalmente, se consideran logros adicionales de este trabajo de grado, los siguientes: La aprobación de la investigación documental presentada en el marco teórico y el modelo conceptual presentado en el capítulo 5 de este proyecto, por parte de la Asociación Venezolana para el Avance de la Ciencia, al aceptar el trabajo titulado AyD de Sistemas según los Modelos de Proceso, Enfoques y Metodologías de Desarrollo, Orientados a Desarrollos en Software Libre, para ser presentado en la LVII Convención Anual de AsoVAC La aprobación de la metodología de evaluación presentada en el marco metodológico, así como el diseño y la aplicación de la instanciación del MOSCA, por parte del jurado de la 19th Australian Software Engineering Conference (ASWEC 2008), al aceptar el artículo Quality Measurement Model for Analysis and Design Tools based on FLOSS, que será presentado en Marzo de 2008 en Perth, Western Australia, en el marco de dicha conferencia. La publicación de los módulos implementados, en el sitio Web oficial de StarUML. 97

98 REFERENCIAS BIBLIOGRÁFICAS Amaya, P., Murillo, J., González, C. (2004). Un modelo de propiedades y dependencias para el análisis orientado a aspectos en MDA. Departamento de Informática. Universidad de Extremadura, España. Tomado de en junio de Ambler, S. (2003). Agile Modelling and Feature-Driven Development. Tomado de: en julio de Barrios, K., Mendoza, A. (2006). Especificación de calidad para productos de software, basada en enfoques de desarrollo. Trabajo final de pregrado, Escuela de Ingeniería de Sistemas, Universidad Metropolitana. Caracas, Venezuela. Bruegge, B., Dutoit, A. H. (2002). Ingeniería de Software Orientado a Objetos. Primera Edición. México: Pearson Educación. Conallen, J. (2002). Building Web Applications with UML. Segunda Edición. Addison Wesley. Controlchaos. Página Web oficial de Scrum. Disponible en: consultada en julio de DSDM. Página Web oficial de Dynamic System Development Method. Disponible en: consultada en julio de Echoes (2007). Microsoft Solutions Frameworks. Tomado de en junio de Eclipse (2007). Eclipse Process Framework Project (EPF). Tomado de en junio de Featuredrivendevelopment. Página oficial de Feature Driven Development. Disponible en: consultada en Julio de Goldman, R., Gabriel, R. (2005). Innovation Happens Elsewhere. Open source as Business Estrategy. Primera Edición. San Francisco: Morgan Kauffman. IBM (2007). The Rational Unified Process. Tomado de en junio de IEEE (2004). Software Engineering Body of Knowledge - Swebok. Versión ISO Estándar para la calidad del software. IM (2007). Diseño Web. Informática Milenium. México. Tomado en Junio de 2007 de Jacobson, Booch, Rumbaugh (s.f.). The Unified Process. Department of Computer Science. University of Bristol. Bristol, Inglatera. Tomado de f en junio de Kendall, K, Kendall, J. (2005). AyD de Sistemas. Sexta Edición. Pearson Educación. Kruchten, P. (2000). The Rational Unified Process, an Introduction. Segunda Edición. Addison Wesley. Laurent, Andrew M. (2004). Open Source & Free Software Licensing. Primera Edición. Sebastopol: O Reilly. Lundell, B., Lings, B. (2002). Changing perceptions of CASE technology. The Journal Systems and Software, Nº 72. Elsevier. Mendoza, L., Grimán, A. (2007). Consideraciones Generales sobre las herramientas CASE. Departamento de Procesos y Sistemas. Universidad Simón Bolívar, Venezuela. 98

99 Mendoza, L., Ovalles, M., Griman, A. (2005). Prototipo del Modelo Sistémico de Calidad (MOSCA) del Software. Computación y Sistemas. Vol. 8. México. Microsoft (2007). Métodos heterodoxos en desarrollo de software. Tomado de en junio de Microsoft Solutions Framework. [White Paper]. (2002). Tomado de: en julio de Monarchi, David E., Puhr, Gretchen I. (1992), A Research Typology for Object-Oriented Analysis and Design. Communications of the ACM. Vol. 35, Nº 9, pp Septiembre. Mosse, D., Farrington, J., Rew, A. (1998). Development As Process: Concepts and Methods for Working With Complexity. Routledge. Object Management Group (2007). What is UML. Tomado de: en julio de Ortega, M. (2001). Modelo de Calidad del Producto de Software con un Enfoque Sistémico. Tesis de Maestría en Ingeniería de Sistemas. Pérez, M. Grimán, A., Mendoza, L. and Rojas, T. (2004) A Systemic Methodological Framework for IS Research. Proceedings of the Tenth Americas Conference on Information Systems(AMCIS 2004), August, USA, Pressman, R. (2005). Ingeniería del Software. Un enfoque práctico. Sexta Edición. Mc Graw Hill. Programaciónextrema. Página Web en español de Extreme Programming. Disponible en: consultada en julio de Quintero, M. A. (2000). Visión General de la Programación Orientada a Aspectos. Universidad de Sevilla. Tomado de: en julio de Real Academia Española (2005). Diccionario de la lengua española. Espasa Calpe. Madrid. Rivas, L. (2007). Herramientas de Desarrollo de Software: hacia la construcción de una ontología. Margarita: Encuentro Venezolano sobre Tecnologías de la Información e Ingeniería de Software (EVETIS 2007). Rosen, Lawrence (2005). Open Source Licensing. Software Freedom and Intellectual Property Law. New Yersey: Prentice Hall. Schwaber, K. (1995). The Scrum Development Process. Tomado de en julio de Sommerville, I. (2006). Software Engineering. Octava Edición. Addison Wesley. Szyperski, C. (1998). Component Software. Beyond Object-Oriented Programming. Addison-Wesley. Valecillo, A., Troya, J., Flores, L. (s.f.). Desarrollo de Software basado en componentes. Lección 1. ETSI Informática. Universidad de Málaga, España. Tomado de en junio de WATCH (2007). Página Web oficial de la Metodología WATCH. Disponible en: Web/public_html/index.html. Wasserman, A. (1980). Principles of Systematic Data design and Implementation. Software Design Techniques (P. Freeman y A. Wasserman, eds.). 2d ed., IEEE Computer Society Press, 1980, pp

100 Whitten, J., Bentley, L. (2007).Systems Analysis and Design Methods. Séptima Edición. Mc. Graw-Hill. Zabala (2002). La Ingeniería de Software. Extracto de la Tesis de (Zabala, 2000). Tomado de: en julio de

101 ANEXO I APLICACIÓN DE LA INSTANCIACIÓN DE MOSCA A LAS 8 HERRAMIENTAS EVALUADAS A continuación se presentan los resultados de la aplicación de la instanciación del Modelo Sistémico de Calidad, diseñada en este proyecto, a las 8 herramientas seleccionadas para la evaluación. StarUML 101

102 102

103 103

104 104

105 105

106 ArgoUML 106

107 107

108 108

109 109

110 BOUML 110

111 111

112 112

113 113

114 Fujaba 114

115 115

116 116

117 117

118 DIA 118

119 119

120 120

121 121

122 Papyrus 122

123 123

124 124

125 125

126 UMLet 126

127 127

128 128

129 129

130 DBDesigner 130

131 131

132 132

133 133

134 ANEXO II MÓDULOS IMPLEMENTADOS A continuación se muestran pantallas de los módulos implementados, en donde pueden observarse los estereotipos creados para cada tipo de diagrama, las paletas que permiten agregar dichos estereotipos al diagrama en construcción y el explorador del modelo, donde se listan los elementos que han sido agregados al diagrama. Módulo StarUML-BusinessObjectModel Módulo StarUML-BusinessObjectSequence 134

135 Módulo satruml-businessusecase Módulo satruml-interactionoverview 135

136 Módulo StarUML-Timing Módulo StarUML-WAEClass 136

137 Módulo StarUML-WAESequence 137

138 ANEXO III Resumen del trabajo presentado en la LVII Convención Anual AsoVAC 2007 ANÁLISIS Y DISEÑO DE SISTEMAS SEGÚN LOS MODELOS DE PROCESO, ENFOQUES Y METODOLOGÍAS DE DESARROLLO, ORIENTADOS A DESARROLLOS EN SOFTWARE LIBRE (*) (Systems Analysis and Design According to Process Models, Approaches and Development Methodologies, oriented to Free Software Development) O. Alfonzo; K. Domínguez; M. Pérez; L. Mendoza; L. Rivas Universidad Simón Bolívar, Dpto. de Procesos y Sistemas, LISI oras14@gmail.com, {kdoming, movalles, lmendoza}@usb.ve, lornelr@gmail.com Iniciar un proceso de desarrollo de software implica determinar tres niveles de abstracción: el modelo de proceso que se seguirá, el enfoque con el cuál debe orientarse el producto esperado, y la metodología que gerencie los recursos disponibles y los requerimientos. Dependiendo de esta selección, el Análisis y Diseño (AyD), tendrá características específicas. El propósito de esta investigación es estudiar el AyD en estos tres niveles de abstracción para encontrar consenso o puntos de coincidencia sobre cuáles son las actividades, roles, artefactos y definiciones aplicables a AyD, cónsonas con la pequeña y mediana empresa con el objeto de precisar, en etapas futuras, orientaciones para la selección de herramientas de Software Libre en este sentido. Para alcanzar este objetivo se realizó una revisión bibliográfica que permitió conceptualizar los tópicos que engloban el AyD en el desarrollo de software y se diseñó, mediante el Framework Metodológico del LISI (Pérez et al., 2004), un modelo conceptual que intenta describir el estado del arte referente al AyD. Como resultados más importantes, se encontró que los modelos de proceso en cascada, espiral, creación de prototipos y orientado a la reutilización, asumen el AyD como fases separadas en algunos casos y como un conjunto de actividades diseminadas a lo largo del desarrollo, en otros. Por otra parte, seleccionar entre los enfoques estructurado, orientado a objetos, Web, orientado a aspectos u orientado a componentes, determina las abstracciones que guían el desarrollo (flujos, objetos, aspectos o componentes). Finalmente, se compararon las metodologías Unified Process (UP), Rational Unified Process (RUP), Open Unified Process (OpenUP), Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Dynamic System Development Method (DSDM), Microsoft Frameworks Solutions (MFS) y WATCH, en cuanto a cómo proponen llevar a cabo el AyD, encontrando que la mayoría de ellas involucran más al cliente que al propio desarrollador. Palabras Claves: Ingeniería de Software, Análisis y Diseño, Software Libre. (*) Financiado por el FONACIT y por el DID-USB, a través de los proyectos de investigación G y S1-IN- CAI , respectivamente. 138

139 ANEXO IV Artículo aceptado por la 19th Australian Software Engineering Conference (ASWEC 2008). 139

140 140

141 141

142 142

143 143

144 144

145 145

146 146

147 147

148 148