UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN PROPUESTA DE AMBIENTE DE UN WORKBENCH PARA LAS DISCIPLINAS DE INGENIERÍA DE SOFTWARE. Por: José Félix Rivas Hernández PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Computación Sartenejas, Septiembre de 2010

2 2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN PROPUESTA DE AMBIENTE DE UN WORKBENCH PARA LAS DISCIPLINAS DE INGENIERÍA DE SOFTWARE. Por: José Félix Rivas Hernández Realizado con la asesoría de: Edumilis Mendez PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero de Computación Sartenejas, Septiembre de 2010

3 3

4 PROPUESTA DE AMBIENTE DE UN WORKBENCH PARA LAS DISCIPLINAS DE INGENIERÍA DE SOFTWARE. 4 POR JOSÉ FÉLIX RIVAS HERNANDEZ RESUMEN La tendencia de las Herramientas de Software (HS) en términos tecnológicos es la integración de aplicaciones ya que aún cuando se pueden obtener beneficios a partir de las HS por separado, su verdadera potencia se logra a través de su integración. De allí surge la idea de un workbench o banco de trabajo, que es un conjunto de herramientas que apoyan a una determinada fase del proceso del software, como el diseño, implementación o prueba. La ventaja de agrupar las HS en un banco de trabajo es que permite que las aplicaciones puedan trabajar juntas para proporcionar un apoyo más amplio que con una sola herramienta. El actual proyecto consiste en la creación de un ambiente workbench para las disciplinas de ingeniería de software. El problema se reduce a la integración de una herramienta de ingeniería de requerimientos llamada UseCaseMaker (UCM) y una herramienta de Análisis y Diseño llamada StarUML. La importancia de la solución planteada radica en que las aplicaciones anteriores puedan utilizarse en conjunto y proporcionar un apoyo más amplio a los usuarios que con una sola herramienta. Este workbench de Ingeniería de Requerimientos y Análisis y Diseño permite la creación de sistemas de mejor calidad que proporciona a los usuarios aplicaciones con información unificada, y mejora la toma de decisiones y consistencia entre las aplicaciones. El trabajo se realizó mediante una investigación bibliográfica y un framework metodológico.

5 INDICE GENERAL 5 Introducción.. 1 Capitulo I MARCO TEÓRICO Herramientas de Software Clasificación de Herramientas de Software Características deseables de las Herramientas de Software Workbench Tipos de Workbench Workbench de Ingeniería de Requerimientos Workbench de Análisis y Diseño Integración de Software Herramientas de Software Integradas Requisitos de Herramientas de Software Integradas Opciones de Integración Disciplinas de Ingeniería de Software Software Libre, Software Open Source y FLOSS Software Libre Software Open Source Software Libre Vs Software Open Source FLOSS...26 Capitulo II MARCO METODOLÓGICO Framework Metodológico 29 Capitulo III DESARROLLO DE LA SOLUCIÓN Modelo Conceptual Antecedentes: Herramientas a integrar Desarrollo del Primer Módulo Actividades Ejecutadas Detalles de implementación Desarrollo del Segundo Módulo Actividades Ejecutadas Detalles de implementación Aplicación a un caso de estudio Instrucciones de operación Estado actual 51

6 Conclusiones y Recomendaciones..52 Referencias Bibliográficas..54 Anexo A. Documento de Arquitectura del Software

7 7 ÍNDICE DE TABLAS Tabla 1: Tipos de licencias FLOSS Tabla 2: Fases de la metodología de Investigación Acción propuesta..30

8 8 ÍNDICE DE FIGURAS Figura 1: Framework metodológico para el trabajo de grado...29 Figura 2: Modelo Conceptual 32 Figura 3: Ventana de documentación de StarUML...36 Figura 4: UMLoriginal.uml diagrama de casos de uso original realizado en StarUML.45 Figura 5: Primer módulo de Workbench UML-UCM..46 Figura 6: UCMtransformado.ucm transformación del UML original...47 Figura 7: UCMcambiado modificación del archivo UCM transformado..48 Figura 8: Segundo módulo de Workbench UML-UCM...49 Figura 9: UMLtransformado.uml diagrama de casos de uso realizado en StarUML con la documentación hecha en UCM...50 Figura 10: Instrucciones de operación de Workbench UML-UCM..51

9 INTRODUCCIÓN 9 La Ingeniería de Software es un área de la Ciencia de la Computación cuyo objetivo de estudio es la construcción de grandes y complejos Sistemas de Software de alta calidad. Para ello es necesario un conjunto de disciplinas de Ingeniería de Software que hacen posible el proceso y desarrollo de estos grandes sistemas. Estas disciplinas son apoyadas por Herramientas de Software (Kruchten, 2004). En el pasado las Herramientas de Software (HS) eran llamadas herramientas CASE (por sus siglas en inglés, Ingeniería del Software Asistida por Computadora), que son piezas fundamentales para los ingenieros de software ya que permiten la automatización de los aspectos claves de todo el proceso de desarrollo de un sistema: el análisis de requerimientos, diseño, construcción y prueba, entre otros. La tendencia de las herramientas de software en términos tecnológicos es la integración de aplicaciones con la expectativa de lograr en lo posible el soporte automatizado total a un método de desarrollo de software. Aún cuando se pueden obtener beneficios a partir de las HS por separado, su verdadera potencia se logra a través de la integración (Sommerville, 2005). De allí surge la idea de un workbench o banco de trabajo, que es un conjunto de herramientas que apoyan a una determinada fase del proceso del software, como el diseño, implementación o prueba. La ventaja de agrupar las HS en un banco de trabajo es que permite que las aplicaciones puedan trabajar juntas para proporcionar un apoyo más amplio en un ambiente integrado. El proceso de integrar HS consiste en tomar los subsistemas desarrollados de forma independiente y unirlos para crear un sistema completo. Por tanto, la importancia de la integración y la realización de este proyecto de grado es: 1. Presentar a los usuarios las aplicaciones con información unificada. 2. Ayudar a la mejor toma de decisiones. 3. Lograr consistencia entre sistemas cruzados.

10 10 El problema planteado se reduce a la integración de una herramienta de ingeniería de requerimientos llamada UseCaseMaker (UCM) y una herramienta de Análisis y Diseño llamada StarUML. StarUML es una herramienta que tiene como objetivo la creación del diseño visual de los elementos de un sistema; ella permite exportar una serie de plantillas de documentación que se generan a partir de los diagramas creados en la herramienta. Pero a pesar de esto, StarUML no permite la creación de una documentación extensa y óptima. Para ello se utilizará la próxima herramienta: UseCaseMaker. UseCaseMaker es una herramienta que permite la automatización del diseño del modelo de casos de uso de un sistema. Esta herramienta no posee características de visualización de diagramas sino la posibilidad de una completa documentación que complementa las funcionalidades de StarUML. Y ese es en el fondo el motivo para querer integrar StarUML y UCM a través de Workbench UML-UCM que será el nombre del ambiente workbench final. Por consecuencia, el objetivo general del trabajo es: - Integrar herramientas de software hacia la creación de un workbench para las disciplinas de ingeniería de software: Ingeniería de Requerimientos y Análisis y Diseño. Los objetivos específicos del proyecto son: - Establecer las bases conceptuales para los tópicos: Herramientas de Software, Workbench, Integración de Software, Disciplinas de Ingeniería de Software y Software Libre. - Proponer escenarios de integración de las herramientas de software. - Integrar las HS para lograr un ambiente Workbench: o Exportar actores, casos de uso, asociaciones y documentación de cada uno de ellos de StarUML a UCM (transformar los archivos.uml a.ucm). o Exportar bidireccionalmente, es decir, además de transformar los archivos.uml a.ucm, realizar el trabajo inverso: transformar los archivos.ucm a.uml (sin agregar o eliminar casos de uso, actores ni asociaciones en UCM). o Controlar los cambios, es decir, alertar cuando hayan ocurrido cambios en la documentación en UCM (sin agregar o eliminar casos de uso, actores ni asociaciones en UCM).

11 11 A continuación se presenta el cuerpo del trabajo que muestra de manera lógica los aspectos y etapas llevadas a cabo en el proyecto. En primer lugar, se presenta el marco teórico que describe los conceptos básicos que fundamentan el trabajo actual: Herramientas de Software, Workbench, Integración de Software, Disciplinas de Ingeniería de Software y Software Libre. Posteriormente, se encuentra el marco metodológico que muestra la forma en que se realizó el proyecto en su totalidad y luego se muestra el desarrollo de la solución, es decir, los módulos realizados para el cumplimiento de la integración con las respectivas actividades ejecutadas y detalles de implementación.

12 CAPÍTULO I 12 MARCO TEÓRICO El presente capítulo tiene por objetivo presentar las definiciones y conceptos que permitan llevar a cabo la realización de este proyecto, en las áreas de Herramientas de Software, Bancos de Trabajo, Integración de Software, Disciplinas de Ingeniería de Software y Software Libre. Para comenzar, se describe el concepto de herramientas de software (HS), su clasificación y las características deseables de estas herramientas. A continuación se expone lo que son los bancos de trabajo o workbench y los tipos de bancos de trabajo más importantes para la presente investigación. Seguidamente se presenta el tema de Integración de Software, donde se da su definición, se amplía el concepto y los requisitos de una herramienta de software integrada y se exhiben las tecnologías u opciones de integración más importantes. Para finalizar, se ofrece las definiciones de disciplinas de Ingeniería de Software, al igual que Software Libre, software de código abierto y FLOSS (Free Libre Open Source Software). Todo esto con el fin de proporcionar los elementos teóricos necesarios para sustentar la integración de herramientas de software para la creación de un workbench para las disciplinas de Ingeniería de Software. 1.1 HERRAMIENTAS DE SOFTWARE Las Herramientas de Software (HS), antes llamadas herramientas CASE (por sus siglas en inglés, Ingeniería del Software Asistida por Computadora) son piezas fundamentales para los ingenieros del software ya que permiten la automatización de los aspectos claves de todo el proceso de desarrollo de un sistema: análisis de requerimientos, diseño, construcción y prueba (Pressman, 2002). De acuerdo con Pressman (2002) las HS son aquellas que proporcionan al ingeniero la capacidad de automatizar las actividades manuales y de mejorar su enfoque de trabajo. Las HS proporcionan un conjunto de herramientas semiautomatizadas y automatizadas que están

13 13 desarrollando una cultura de ingeniería nueva para muchas empresas. Las HS ayudan a los gestores y practicantes de la Ingeniería del Software en todas las actividades asociadas a análisis, diseño y codificación. Según Lundell & Lings (2002) las tecnologías de HS se definen como un conjunto de herramientas interoperables y computarizadas diseñadas para brindar soporte a los stakeholders en sus actividades y procesos, a través del ciclo de vida completo de los sistemas. Para Kendall y Kendall (2007) las HS sirven para automatizar o apoyar una o más fases del ciclo de vida y desarrollo de los sistemas. Por su parte, Sommerville (2005) señala que las HS son herramientas de soporte automatizado para los ingenieros de software, que conduce a mejoras en la productividad de los procesos de ingeniería de software, como la ingeniería de requerimientos, el diseño, el desarrollo de programas y las pruebas. Igualmente, expresa que la tecnología de HS está disponible para la mayoría de las actividades rutinarias en el proceso del software y que actualmente se encuentra ya con madurez por la gran cantidad de herramientas y bancos de trabajo (workbenches) de un amplio rango de proveedores. Como se puede observar todas estas definiciones concuerdan en que las HS se utilizan para apoyar los procesos de ingeniería de software y son herramientas automatizadas y computarizadas. El concepto fundamental se ha mantenido en el tiempo y se observa poco evolución en sus definiciones. Para la presente investigación, HS se referirá a cada una de las aplicaciones que permiten la automatización de los aspectos claves de todo el proceso de desarrollo de un sistema. Sommerville (2005), señala que los primeros partidarios de las HS sugirieron que se tendría una mejora mayor si se utilizaran HS integradas, éstas y los mencionados bancos de trabajo serán aspectos a desarrollar posteriormente ya que son la base del presente trabajo de investigación. A continuación se presentará la clasificación de las herramientas de software de acuerdo a distintos criterios.

14 1.1.1 CLASIFICACIÓN DE HERRAMIENTAS DE SOFTWARE 14 Existen diferentes formas de clasificar las HS entre las cuales se tienen según Sommerville (2005) las siguientes: 1. Una perspectiva funcional donde las herramientas se clasifican según su función específica. 2. Una perspectiva de proceso donde las herramientas se clasifican de acuerdo a las actividades del proceso que ayudan, por ejemplo: herramientas de diseño, programación, mantenimiento, etc. 3. Una perspectiva de integración donde las herramientas se clasifican de acuerdo con la forma en que están organizadas, en unidades integradas que proporcionan ayuda a una o más actividades del proceso. Por otra parte, Rivas (2007) clasifica las HS de la siguiente manera: 1. De acuerdo con las funciones que la herramienta soporta: en esta perspectiva las HS se clasifican según su función específica dentro del proceso de desarrollo. Rivas (2007), identifica hasta 22 tipos de herramientas clasificadas funcionalmente. Estas clasificaciones tienen una intención orientadora, apuntan a mostrar la amplitud de las herramientas y sus aportes a distintas etapas del desarrollo, más que a establecer taxonomías rigurosas. 2. De acuerdo con el actor que es soportado por la herramienta: esta perspectiva se basa en el sujeto a quien soporta la herramienta, y las define como: a) De Alto nivel, que ayudan principalmente a los analistas y diseñadores, permitiéndoles crear y modificar el sistema; y, b) De Bajo nivel, utilizadas por programadores y trabajadores quienes deben implementar los sistemas diseñados. 3. De acuerdo con el proceso: en esta clasificación se definen tres categorías: a) las Herramientas, que ayudan a tareas puntuales y se utilizan a discreción del ingeniero de software; b) los Bancos de trabajo, que agrupan herramientas que mantienen algún grado de integración y soportan a un método que incluye un modelo del proceso; y, c) los Ambientes, que apoyan a los procesos de software, incluyen bancos de trabajo integrados y soportan a los datos, al control y a la integración. 4. Tópicos de las herramientas, como subárea de conocimiento de la IS: en esta clasificación existe un conjunto de herramientas dentro de cada tópico, cuyo campo de

15 15 acción se asocia no sólo con las actividades propias de cada uno de estos, sino también se considera el caso de herramientas que prestan soporte con un carácter transversal, como el caso de las herramientas misceláneas. Por otro lado, Fuggetta (citado por Sommerville, 2005) clasifica las HS de la siguiente manera: 1. Las herramientas ayudan a las tareas individuales del proceso como la verificación de la consistencia de un diseño, la compilación de un programa y la comparación de los resultados de las pruebas. Las herramientas pueden ser de propósitos generales, independientes o agrupadas en bancos de trabajo. 2. Los bancos de trabajo ayudan a las fases o actividades del proceso como la especificación, el diseño, etc. Normalmente consisten en un conjunto de herramientas con algún mayor o menor grado de integración. 3. Los entornos o ambientes ayudan a todos los procesos del software, o al menos a una parte sustancial de estos. Normalmente incluyen varios bancos de trabajo integrados. Analizando estas clasificaciones se observa que existe una gran similitud entre ellas, se complementan unas a otras y se puede llegar a la conclusión de que las HS se clasifican a nivel general por las funciones que soportan, los procesos en los que ayudan y el nivel de integración que ellas posean. De igual manera, examinando las clasificaciones anteriores se observa que la clasificación que hace Rivas de acuerdo al proceso es la misma clasificación que hace Fuggeta, por tanto en la presente investigación se utilizará la clasificación que propone Fuggetta y se abordará en posteriores secciones los bancos de trabajo o workbenches. A continuación se describirán las características deseables para cualquier herramienta de software CARACTERÍSTICAS DESEABLES DE LAS HERRAMIENTAS DE SOFTWARE Con la revisión de las distintas literaturas (Pressman 2002, Sommerville 2005, Rivas 2007) se puede concluir que las principales características de una HS efectiva y eficiente son:

16 16 1. La herramienta debe proporcionar facilidades de construcción sea cual fuera la actividad del proceso de desarrollo de software en la que se encuentre. 2. La herramienta debe ser multiplataforma. 3. La herramienta debe ser capaz de rendimiento en tiempos de corrida. 4. La herramienta debe reconocer y ser consistente en las versiones de software que se están creando. 5. Las herramientas deben ser capaces de controlar un gran número de tipos de objetos incluyendo texto, gráficos, mapas de bits, documentos complejos y objetos únicos, tales como definiciones de pantallas y de informes, archivos de objetos y datos de prueba. 6. La herramienta debe permitir que varios diseñadores trabajen en una aplicación simultáneamente. Debe gestionarse los accesos concurrentes a la base de datos por diferentes usuarios, mediante el arbitrio y bloqueos de accesos a nivel de archivo o de registro. 7. La herramienta debe proporcionar mecanismos para controlar el acceso y las modificaciones a los que contiene. La herramienta debe, al menos, mantener contraseñas y permisos de acceso en distintos niveles para cada usuario. También debe facilitar la realización automática de copias de seguridad y recuperaciones de las mismas, así como el almacenamiento de grupos de información determinados, por ejemplo, por proyecto o aplicaciones. 8. Deben permitir que grupos de programadores trabajen en un proyecto común, con repositorios de librerías compartidas. 9. Gestionar y controlar el acceso multiusuario a los datos y bloquear los objetos para evitar que se pierdan modificaciones inadvertidamente cuando se realizan simultáneamente. Para el presente trabajo las características más deseables para un workbench serían la consistencia de versiones e información y el control de los cambios. En efecto, luego de describir las principales características que debe tener una HS se abordará a continuación un tipo especial de estas herramientas: bancos de trabajo o workbench. 1.2 WORKBENCH En la presente sección se desarrollará uno de los tipos de HS más comunes, como lo son los workbench, que como se dijo anteriormente son conjuntos integrados de herramientas que dan

17 17 soporte a la automatización del proceso completo de desarrollo del sistema informático. A continuación, se ampliará su definición formal, los tipos de workbench que existen y dos tipos de workbench específicos que apoyan el ciclo de vida del software, como son: workbench de ingeniería de requerimientos y workbench de análisis y diseño. Según Sommerville (2005), un workbench o banco de trabajo es un conjunto de herramientas que apoyan a una determinada fase del proceso del software, como el diseño, implementación o pruebas. La ventaja de agrupar las HS en un banco de trabajo es que permite que las aplicaciones puedan trabajar juntas para proporcionar un apoyo más amplio que con una sola herramienta. Los servicios comunes se pueden implementar y ser llamados por todas las demás herramientas. Los workbench están disponibles para apoyar la mayoría de las actividades del proceso de software (especialmente análisis y diseño, programación y prueba). Los bancos de trabajo para apoyar estas actividades son ampliamente utilizados en la industria, tienen una relativa madurez y generalización a través de distintas aplicaciones. (Sommerville, 2005). Ello no implica que éstos sean los únicos bancos de trabajo necesarios para apoyar el desarrollo de software. Dependiendo del tipo de software y las aplicaciones desarrolladas, Sommerville (2005) señala que otros tipos de banco de trabajo pueden ser utilizados, por ejemplo: Workbench de desarrollo, workbench de gestión de configuración y workbench de documentación. Para el objetivo del actual proyecto es de vital importancia el conocimiento de los workbench de Ingeniería de Requerimientos y Análisis y Diseño estos serán descritos posteriormente en esta sección. Resumidamente, los bancos de trabajo son un conjunto de HS destinadas a apoyar una fase del proceso del software tales como el diseño del sistema o un conjunto de actividades de los procesos interrelacionados de software tales como gestión de la configuración. Evidentemente, estas actividades varían significativamente de un dominio de aplicación a otra y de una organización a otra. Por tanto, es deseable que los bancos de trabajo sean sistemas abiertos; éste es un tipo de workbench, y se describirá a continuación.

18 1.2.1 TIPOS DE WORKBENCH 18 La única tipología encontrada en la bibliografía se refiere a la clasificación de Sommerville (2005), este clasifica los workbenches en abiertos y cerrados. Un workbench abierto es un sistema donde los mecanismos de integración de control, programación y protocolos de integración de datos son públicos y no de propiedad. Según Sommerville (2005), las ventajas de los bancos de trabajo abiertos son: 1. Nuevas herramientas especializadas que responden a las necesidades particulares de una organización se pueden añadir a las herramientas existentes o los bancos de trabajo podrán ser sustituidos por alternativas más adecuadas. 2. Los resultados de las herramientas son archivos que pueden ser gestionados por un sistema de gestión de configuración. 3. Es posible la introducción y evolución de los workbench. Una organización puede introducir la tecnología de HS usando un banco de trabajo con unas pocas y fáciles herramientas. Las nuevas herramientas se pueden agregar al sistema. Las herramientas iniciales podrán ser sustituidas por sistemas más potentes a medida que la demanda aumenta. 4. Las organizaciones no necesitan depender de un proveedor de workbench individual, pero pueden comprar herramientas de una serie de proveedores distintos. Esta diversidad de la oferta es importante. Si un proveedor de herramientas retira su herramienta de apoyo, esto sólo afectará a parte del workbench. El resto de las herramientas podrán seguir en uso. Aunque son preferibles los workbench abiertos, los vendedores de herramientas de software han tomado la decisión de ofrecer sistemas cerrados. Los workbenches cerrados son aquellos donde los protocolos de integración son propiedad del proveedor del workbench. El banco de trabajo se le presenta al usuario como un todo unificado más que como una caja de herramientas diferentes. La adición de herramientas en estos workbenches es por lo general imposible de realizar. (Sommerville, 2005) Debido a esto, en el presente proyecto se realizará un banco de trabajo abierto, que reduzca los costos de programación y facilite la integración de herramientas posteriores.

19 19 A continuación, se describirán dos de los bancos de trabajo más importantes en el desarrollo de cualquier programa o sistema software, como son: workbench de Ingeniería de Requerimiento y workbench de Análisis y Diseño que son las herramientas básicas para el desarrollo de este proyecto WORKBENCH DE INGENIERÍA DE REQUERIMIENTOS Los bancos de trabajo de ingeniería de requerimientos como su nombre lo indica están diseñados para apoyar actividades de ingeniería de requerimientos, es decir, crear y mantener un documento de requerimientos del sistema. Estos pueden incluir herramientas para llevar la evaluación de la viabilidad, obtención, análisis, especificación y validación de requerimientos. (Sommerville, 2005) Los bancos de trabajo de ingeniería de requerimientos son herramientas de gestión dirigidas a todos los involucrados en el proyecto, que facilita de una manera automatizada el control de la viabilidad, obtención, análisis, especificación y validación de los requerimientos del sistema. Con ello, se consigue una mejora en la disciplina de requisitos del software ya que se perfeccionan los procesos de gestión de requerimientos y la síntesis de los servicios necesarios para el proyecto. Según la literatura consultada (Sommerville 2005 y Swebok 2004), un buen banco de trabajo de Ingeniería de Requerimientos debería contemplar al menos los siguientes puntos: 1. Estudios de viabilidad, la entrada es un conjunto de requerimientos de negocio preliminares, una descripción resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece la pena o no seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema. 2. Obtención y análisis de requerimientos, el workbench debería almacenar y manejar el dominio de la aplicación, los servicios que debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones de hardware, etc. Igualmente, debería organizar, clasificar, priorizar y documentar los requerimientos. 3. La validación de requerimientos, el workbench debe mostrar qué requerimientos definen el sistema que el cliente desea.

20 20 Como se puede observar, la progresiva complejidad del desarrollo de software de las empresas de hoy en día hace imprescindible la necesidad de disponer de un departamento que desarrolle, controle y supervise los requerimientos que el sistema a desarrollar necesita, esto a través de una herramienta. En fin, es evidente la exigencia de este tipo de productos en las compañías ya que se hacen esenciales para el logro de los proyectos y los objetivos. De igual manera, así como la ingeniería de requerimientos es vital para el desarrollo de cualquier sistema de información, lo es aún más el análisis y el diseño del mismo. Equivalentemente, existen bancos de trabajo que ayudan esta disciplina de la ingeniería del software y se describirá a continuación WORKBENCH DE ANÁLISIS Y DISEÑO Los workbench de Análisis y Diseño como su nombre lo indica están diseñados para apoyar las etapas de análisis y diseño del proceso de software, en el que se crean modelos del sistema (como un modelo de flujo de datos, un modelo entidad relación entre otros). Estos workbenches generalmente están centrados en el apoyo de la notación gráfica usada en los métodos de diseño. Los workbenches diseñados para apoyar el análisis y diseño se denominan a veces HS superior. (Sommerville, 2005) Estos workbenches pueden apoyar un diseño específico o un método de análisis, tales como DSJ u análisis orientado a objeto. Las herramientas que se pueden incluir en un workbench de análisis y diseño se integran normalmente a través de un repositorio compartido, cuya estructura es propiedad del proveedor del banco de trabajo. Workbench de análisis y diseño son por lo general sistemas cerrados. Esto hace difícil para los usuarios añadir sus propias herramientas o modificar las herramientas que se le proporcionan. (Sommerville, 2005) Las dificultades prácticas que surgen con los workbenches de análisis y diseño son sobre todo una consecuencia del hecho de que por lo general son ambientes cerrados. (Sommerville, 2005) Es por esta razón que en el presente proyecto se utilizarán bancos de trabajo de análisis y diseño abiertos que faciliten la integración de herramientas para la creación de un ambiente workbench completo. A continuación se desarrollará y describirá lo referido a la integración de software que es el aspecto mediante el cual las HS adquieren su verdadero potencial.

21 1.3 INTEGRACIÓN DE SOFTWARE 21 La tendencia de las herramientas de software en términos tecnológicos es la integración de aplicaciones con la expectativa de lograr en lo posible el soporte automatizado total a un método de desarrollo de software. Aún cuando se pueden obtener beneficios a partir de las HS por separado, su verdadera potencia se logra a través de la integración. A continuación se presentarán aspectos de la integración del software, como su definición formal y lo que son las herramientas de software integradas: su definición, requisitos para la integración y las opciones de integración de software más destacadas. Se puede comenzar refiriéndose a la definición que proporciona Sommerville (2005). El proceso de integrar sistemas software consiste en tomar los subsistemas desarrollados de forma independiente y unirlos para crear un sistema completo. La integración del software significa mucho más que simplemente colocar todas las aplicaciones sobre una misma plataforma para lograr conectividad. Es necesario evitar que los datos se solapen y que haya redundancia en la información, esto con el fin de lograr integridad de los datos. Estos problemas hacen de la integración del software todo un reto (Sommerville, 2005). Por su parte, Brown (2002) señala que el corazón de la integración del software es la combinación del software, hardware y componentes necesarios de red, para entregar una solución completa. De estas definiciones se puede concluir que la integración es más que una actividad simple de unir partes, la integración debe permitir que esas partes se unan de forma coherente. De las diversas literaturas consultadas (Sommerville, 2005; Pressman 2002) se puede concluir que las principales razones que motivan la integración son: 1. Para presentar a los usuarios las aplicaciones con una vista de información unificada. 2. Para ayudar a la mejor toma de decisiones. 3. Para lograr consistencia entre sistemas cruzados.

22 22 Con esto se hace claro que para cualquier usuario o programador, es importante contar con un software integrado que combine las funciones de varios programas con una sola interfaz que agilice el trabajo y permita el buen desempeño de los proyectos involucrados. La arquitectura del ambiente, compuesta por la plataforma, el hardware y el software del sistema operativo (incluida la red y la gestión de la base de datos) constituye la base de un ambiente workbench. Sin embargo, aún cuando se pueden obtener beneficios a partir de las herramientas de software aisladas, su verdadera potencia se logra a través de la integración o lo que llamamos herramientas de software integradas, que es el siguiente punto a describir HERRAMIENTAS DE SOFTWARE INTEGRADAS Según Pressman (2002), las HS integradas son una combinación de herramientas y diferentes elementos de información, de tal forma que permite el cierre de la comunicación entre herramientas, entre gente y a lo largo de todo el proceso de ingeniería del software. Las herramientas se integran con el fin de que la información esté disponible para todas aquellas que lo necesiten; su utilización está integrada para que todas tengan un mismo formato de presentación. Probablemente la característica más importante buscada por los compradores de HS es el grado en que ellas están integradas. La integración se refiere a la cantidad de información que se comparte entre las funciones del ambiente y los servicios que el ambiente ejecuta automáticamente. De acuerdo a Pressman (2002), del uso de herramientas aisladas que realizan determinadas labores de la ingeniería del software se obtienen beneficios, pero el potencial real de las HS sólo se puede conseguir a través de la integración. Según Pressman (2002) los beneficios de las HS integradas incluyen: 1. La transferencia fluida de información (modelos, programas, documentos, datos) entre herramientas y entre etapas de la ingeniería del software. 2. La reducción del esfuerzo requerido para realizar actividades de soporte como la gestión de la configuración del software, el control de calidad y la generación de documentos. 3. Un aumento en el control de los proyectos que se consigue mediante una mejor planificación, monitorización y comunicación.

23 4. Mejora de la coordinación entre los miembros del equipo que trabajan en un proyecto grande de software. 23 Con todo esto se observa el potencial de las HS integradas, este tipo de ambiente ha pasado a ser un componente estratégico y de desarrollo vital para las organizaciones. Igualmente, las HS integradas también presentan retos significativos. La integración exige representaciones consistentes de la información, interfaces estandarizadas, ejecución sobre distintas plataformas hardware y sistemas operativos. Para lograr esto las HS integradas deben cumplir con algunos requisitos principales, que se describirán en la siguiente sección REQUISITOS DE HERRAMIENTAS DE SOFTWARE INTEGRADAS Según Forte (citado en Pressman, 2002) un entorno de HS integradas debe: 1. Suministrar un mecanismo para que todas las herramientas contenidas en el entorno compartan la información. 2. Permitir que los cambios en un elemento de información sea comunicado a otros elementos relacionados. 3. Proporcionar un control de versiones y una gestión global de la configuración para toda la información del sistema. 4. Permitir el acceso directo, no secuencial, a cualquier herramienta contenida en el entorno. 5. Establecer un soporte automático para un contexto procedimental de trabajo de ingeniería del software que integre herramientas y datos en una estructura estándar. 6. Permitir que los usuarios de cada herramienta tengan una visión consistente de la interfaz hombre-máquina. 7. Permitir la comunicación entre distintos ingenieros. 8. Recoger medidas técnicas y de gestión que puedan ser utilizadas para mejorar el proceso y el producto. Para el caso de esta investigación se tomó muy en cuenta el compartimiento de la información, comunicación de los cambios, consistencia de la información y de la interfaz gráfica porque son los requisitos fundamentales de un workbench.

24 24 En fin, analizando los requisitos anteriores se puede decir que un entorno de HS integradas debe tener mecanismos que permitan compartir, modificar, controlar y eliminar información, esto se puede llevar a cabo a través de distintas maneras, que veremos a continuación OPCIONES DE INTEGRACIÓN Para Pressman (2002) pocas herramientas de software se utilizan de forma aislada, y se suele disponer de las siguientes opciones de integración: 1. Solución puntual: consiste en una herramienta individual que se utiliza para prestar apoyo en una actividad de ingeniería del software concreta (por ejemplo, modelado de análisis), pero esta herramienta no se comunica directamente con otras, no está unida a una base de datos del proyecto y no forma parte de un entorno integrado. Es decir, no tienen manera de recibir información más que la que proporcione el usuario al momento de utilizarlas, y la que den los proyectos creados anteriormente con tal herramienta. 2. Intercambio de datos: cuando las herramientas individuales proporcionan servicios para el intercambio de datos, el nivel de integración mejora ligeramente. Estas herramientas producen su salida en un formato estándar que deberá ser compatible con otras herramientas que sean capaces de leer ese formato. En algunos casos los constructores de herramientas de software complementarias trabajan juntos para formar un puente entre las herramientas. Mediante la utilización de este enfoque, la sinergia entre herramientas puede producir unos resultados finales que serían difíciles de crear empleando cada una de las herramientas por separado. La ventaja de este enfoque es que el traspaso de información suele ser transparente entre las herramientas. 3. Fuente única: se produce cuando un único vendedor de herramientas de software integra una cierta cantidad de herramientas distintas y las vende en forma de paquete. Aunque este enfoque es bastante eficiente, la arquitectura cerrada de la mayoría de los entornos de fuente única evita añadir fácilmente herramientas procedentes de otros fabricantes.

25 25 4. Entorno de apoyo a proyectos integrados (EAPI): se construye mediante estándares de traspaso de información y metadatos alrededor de un depósito de datos, lo cual permite añadir herramientas que se ajusten a los estándares, aunque sean de distintos proveedores, con las ventajas que proporcionan las bases de datos. Como se puede observar, un entorno integrado provee una simplificación en la transferencia de datos entre herramientas, con una consecuente mejora en el proceso del flujo de información. Esto brinda una reducción en el esfuerzo para realizar actividades de control de los proyectos, equipos y software, e incluso proporciona mejor control y coordinación de las actividades del personal de desarrollo. Esto permite deducir que no es fácil decidir cuál debe ser la tecnología más apropiada para conectar estas aplicaciones o herramientas sobre todo porque en el mercado existe una amplia gama de estas tecnologías. El proyecto actual se basará en la integración mediante intercambio de datos. Con estas opciones de integración se puede decir que a medida que se desean integrar más herramientas en un proyecto, el número de dificultades e inconvenientes aumentan imposibilitando el mantenimiento de la integridad de las aplicaciones, los datos y la información. A pesar de ello, es clara la necesidad de implementación de estas herramientas de software integradas ya que facilitan y potencian el trabajo del ingeniero de software en las distintas disciplinas de ingeniería o en el ciclo de desarrollo de un sistema informático, que será el punto a describir a continuación. 1.4 DISCIPLINAS DE INGENIERÍA DE SOFTWARE La Ingeniería de Software es un área de la Ciencia de la Computación cuyo objetivo de estudio es la construcción de grandes y complejos Sistemas de Software de alta calidad. Para esta construcción es necesario un conjunto de disciplinas de ingeniería de software que hacen posible el proceso y desarrollo de estos grandes sistemas. UP (Proceso Unificado) es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos. (Kruchten, 2004)

26 26 UP provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. Según Kruchten (2004) el Proceso Unificado tiene dos dimensiones: 1. Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento 2. Un eje vertical que representa las disciplinas o flujo de trabajo, los cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza. UP se organiza en disciplinas o flujos de trabajo. Un flujo de trabajo o disciplina es un conjunto de actividades realizadas en un área determinada. Las actividades producen artefactos. Un artefacto es un término general empleado para referirse a cualquier resultado del trabajo, ya sea un texto, un diagrama, una página web, código en lenguaje de programación u otro. (Kruchten, 2004) Es decir, una disciplina de ingeniería del software es cada una de las actividades o eventos de ingeniería del software involucrados en el desarrollo y mantenimiento de un programa o sistema de información que produce un resultado. Las disciplinas o flujo de trabajo que presenta el UP son: modelado de negocio, requisitos de software, análisis y diseño, implementación, pruebas, implantación, gestión de la configuración, gestión de proyectos y ambiente. (Kruchten, 2004) A continuación se describirá brevemente las que son de interés para el presente proyecto de grado. 1. Requisitos de software: este es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que se construya. En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que se especifiquen. Los objetivos del flujo de datos requisitos son:

27 1. Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podría hacer Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. 3. Definir el ámbito del sistema. 4. Proveer una base para la planeación de los contenidos técnicos de las iteraciones. 5. Proveer una base para estimar costos y tiempo de desarrollo del sistema. 6. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario. Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad específica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc. (Kruchten, 2004) Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no sólo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos. En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se diseña la interfaz gráfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz gráfica de usuario que se contrastan con el usuario final. (Kruchten, 2004). 2. Análisis y Diseño: el objetivo de este flujo de trabajo es traducir los requisitos a una especificación que describe cómo implementar el sistema. Los objetivos del análisis y diseño son: 1. Transformar los requisitos al diseño del futuro sistema. 2. Desarrollar una arquitectura para el sistema.

28 3. Adaptar el diseño para que sea consistente con el entorno de implementación, diseñando para el rendimiento. 28 El análisis consiste en obtener una visión del sistema que se preocupa de ver qué hace, de modo que sólo se interesa por los requisitos funcionales. Por otro lado el diseño es un refinamiento del análisis que tiene en cuenta los requisitos no funcionales, en definitiva cómo cumple el sistema sus objetivos. (Kruchten, 2004) Al principio de la fase de elaboración hay que definir una arquitectura candidata: crear un esquema inicial de la arquitectura del sistema, identificar clases de análisis y actualizar las realizaciones de los Casos de Uso con las interacciones de las clases de análisis. Durante la fase de elaboración se va refinando esta arquitectura hasta llegar a su forma definitiva. En cada iteración hay que analizar el comportamiento para diseñar componentes. Además si el sistema usará una base de datos, habrá que diseñarla también, obteniendo un modelo de datos. (Kruchten, 2004) El resultado final más importante de este flujo de trabajo será el modelo de diseño. Consiste en colaboraciones de clases, que pueden ser agregadas en paquetes y subsistemas. Otro producto importante de este flujo es la documentación de la arquitectura de software, que captura varias vistas arquitectónicas del sistema. (Kruchten, 2004). En fin, el presente proyecto de integración de herramientas de software para la creación de un workbench apoyará las disciplinas de Requerimientos y Análisis y Diseño. Para esto se utilizarán herramientas y workbenches FLOSS (Free Libre Open Source Software) que será el último punto a desarrollar en esta sección. 1.5 SOFTWARE LIBRE, SOFTWARE OPEN SOURCE Y FLOSS En esta última sección se desarrollarán las definiciones de Software Libre, software Open Source, las diferencias y semejanzas entre ambos términos y una combinación entre los dos como lo es el FLOSS. FLOSS son las siglas en inglés que identifican al término "Free/Libre Open Source Software", a continuación se definirán cada uno de estos conceptos para establecer diferencias

29 y puntos claros de lo que es un Software Libre, un Software de código abierto y la combinación de ambos, esto para evitar cualquier tipo de confusión SOFTWARE LIBRE Según la Free Software Foundation (2007), organización que encabeza el movimiento de Software Libre, un programa es considerado Software Libre si cumple con los siguientes cuatro tipo de libertades: 1. La libertad para ejecutar el programa para cualquier propósito (Libertad 0). 2. La libertad para estudiar cómo funciona el programa y adaptarlo a sus necesidades (Libertad 1). Tener acceso al código fuente es una condición para esto. 3. La libertad para redistribuir copias y así ayudar al vecino (Libertad 2). 4. La libertad para mejorar el programa y luego publicarlo para beneficio de toda la comunidad (Libertad 3). Tener acceso al código fuente es una condición para esto. De esta definición se concluye que Software Libre es aquel que puede ser utilizado, estudiado, copiado, modificado y redistribuido libremente. Esta noción de libertad se refiere al derecho que tiene el usuario de poder decidir el uso que le dará al software sin tener que notificarlo a ningún ente en particular. El tiempo ha demostrado que el Software Libre ofrece sistemas de bajos costos, seguros, basados en estándares abiertos; favoreciendo esto al trabajo colaborativo, aumentando la capacidad tecnológica, reduciendo la dependencia de proveedores y fomentando el desarrollo de la organización local. Feltrero (2004), establece que las cuatro libertades pueden relacionarse con cuatro ventajas: 1. Ventajas cognitivas: El usuario puede leer y entender el funcionamiento de un programa debido a que el código fuentes es incluido junto con la versión ejecutable. De este modo se promueve la experimentación que conlleva a la innovación en la búsqueda de mejores soluciones.

30 30 2. Ventajas técnicas: La difusión de las copias del programa y la publicación de mejoras realizadas a la versión original del Software cuenta con un mayor número de programadores que velan por la eficiencia y buen funcionamiento del programa. 3. Ventajas sociales: Las libertades 2 y 3, fomentan la colaboración entre usuarios, quienes al compartir libremente el conocimiento benefician la sociedad. 4. Ventajas éticas: El Software Libre se encuentra al alcance de todos por igual. Analizando estas ventajas se puede decir que el Software Libre es un movimiento social (Stallman, 2004) que incentiva el conocimiento, la experimentación y la participación de todos los usuarios. Stallman (2004), aclara que es un error frecuente pensar que el Software Libre es gratuito por la ambigüedad existente con la palabra inglesa free. El software libre es una cuestión de libertad no de precio. Es decir, éste puede ser utilizado para obtener remuneración económica. Debido a las diversas interpretaciones que pueden darse al término Software Libre, a partir de 1998 comenzó a llamársele Open Source Software (Goldman, & Gabriel, 2005) SOFTWARE OPEN SOURCE De acuerdo a la OSI (Open Source Initiative, 2006), Software Open Source es aquél cuyo código fuente puede ser accedido libremente y su distribución y desarrollo se fundamenta en diez principios: 1. Libre distribución: La licencia no restringirá en ninguna parte el vender o dar gratuitamente el software como componente de una distribución que contiene programas de varias fuentes. Las licencias no requerirán derechos u otros honorarios para la venta. 2. Código fuente: El programa debe incluir el código fuente y debe permitir la libre distribución en código fuente así como en forma compilada. Cuando una cierta forma del producto no se distribuya con el código fuente, deben existir medios bien publicados de los cuales se pueda obtener el código fuente por no más de un costo razonable de reproducción, preferiblemente que sea descargado a través de Internet sin cargo. El código fuente debe ser preferiblemente en la forma en la cual el programador pueda modificar el programa. No se permite código fuente deliberadamente

31 31 ininteligible. No se permiten formas intermedias como la salida de un pre-procesador o traductor. 3. Trabajos derivados: Las licencias deben permitir modificaciones y trabajos derivados, los cuales deben ser distribuidos bajos los mismos términos de la licencia del software original. 4. Integridad del código fuente del autor: Las licencias pueden restringir que el código fuente sea distribuido para ser modificado sólo si la licencia permite la distribución de los parches con el código fuente con el propósito de modificar el programa en tiempo de ejecución. La licencia debe permitir explícitamente la distribución de software ejecutable del código fuente modificado. La licencia puede requerir trabajos derivados que lleven un nombre o número de versión diferente al software original. 5. Sin discriminación contra personas o grupos: La licencia no debe discriminar a ninguna persona o grupo de personas. 6. Sin discriminación contra áreas de iniciativa: La licencia no debe restringir a alguien por hacer uso de un programa sea cual sea la iniciativa. 7. Distribución de la licencia: Los derechos adjuntos al programa deben aplicarse a todos aquellos a los que el programa es redistribuido sin necesidad de la ejecución de una licencia adicional para esas partes. 8. La licencia no debe ser específica de un producto: Los derechos adjuntos al programa no deben depender del programa que es parte de una distribución particular del software. Si el programa es extraído de una distribución y usado para ser distribuido dentro de los términos de la licencia del programa, todos aquellos a los que el programa es redistribuido deben tener los mismos derechos que los que se conceden conjuntamente con la versión de software original. 9. La licencia no debe restringir otro software: La licencia no debe hacer restricciones con otro software que es distribuido con licencia de software. Por ejemplo: la licencia no debe insistir que todos los otros programas distribuidos en el mismo medio deban ser software open source. 10. Las licencias deben ser tecnología neutral: Ninguna licencia debe ser predicada sobre una tecnología individual o estilo de interfaz. Por su parte, Rosen (2005) resume parte de estos diez principios en cinco aspectos: 1. Las licencias son libres de usar Software Open Source sea cual sea el propósito.