Entorno Colaborativo para la Administración de Proyectos de Software (ECAPS)

Transcripción

1 Entorno Colaborativo para la Administración de Proyectos de Software (ECAPS) Gustavo Armagno, Rolando Larrainci, Andrey Luján Taller de Sistemas de Información 2 Facultad de Ingeniería, Universidad de la República Montevideo, Uruguay gustavoa@gmail.com, rlarrainci@adinet.com.uy, andreylujan@gmail.com Abstracto Este documento analiza una posible solución al problema de administrar, desarrollar y poner en producción proyectos de software a través de Internet, propuesto por los docentes de la asignatura Taller de Sistemas de Información 2. I. INTRODUCCIÓN A. Problemática Administrar un proyecto de software significa hacer uso de los recursos existentes de forma eficaz y eficiente con el objetivo de lograr la puesta en producción del producto en desarrollo. Los recursos pueden dividirse en laborales (personas), materiales duros (estaciones de trabajo, proyectores, escritorios, etc.) y materiales blandos (espacio en disco, tiempo de procesamiento, ancho de banda del servidor, etc.). El rol de administrador debe asignar tareas a los recursos laborales, los cuales invertirán esfuerzo propio y consumirán recursos materiales asignados, para cumplir con sus responsabilidades. La factibilidad de realización de un proyecto puede verse comprometida por varios factores, entre ellos el número de personas y el entorno de desarrollo. Si el equipo aumenta en número, entonces la comunicación se volverá cada vez más crítica, podría aumentar el número de licencias de software, etc. Un entorno de desarrollo inapropiado podría restringir tanto el número de personas como la posibilidad de trabajar en forma distribuida. Se plantea entonces la necesidad de contar con una aplicación que permita administrar proyectos de software, disponga de la infraestructura necesaria para desarrollar proyectos, proporcione canales de comunicación entre los recursos laborales asignados al proyecto, logre -mediante un entorno de colaboración apropiado- facilitar la distribución de los recursos laborales, y además de todo esto, que sea segura, flexible, configurable, extensible y escalable. B. Solución propuesta La solución propuesta es ECAPS (Entorno Colaborativo para la Administración de Proyectos de Software), una aplicación que, a través de Internet y mediante la utilización de una interfaz Webbased y la publicación de Web Services, brinda herramientas que permiten resolver la problemática planteada. Vale la pena recalcar que el único requerimiento para que el usuario haga uso de la aplicación, es contar con conexión a Internet y acceso al protocolo HTTP.

2 El núcleo de ECAPS cuenta con módulos de seguridad (autenticación de usuarios, administración de roles), módulos para el desarrollo (sistema de archivos, granja de compiladores, sistemas de versionado, facilidades para compartir y publicar archivos), módulos de administración de recursos laborales y materiales (creación y asignación de tareas, seguimiento del plan de proyecto) y módulos de comunicación (foros, comunicación interna). La publicación de servicios a través de Web Services permitirá entre otras cosas- que el núcleo de ECAPS pueda integrarse en un futuro con múltiples IDE. C. Consideraciones Por tratarse de un proyecto de índole académica, la elección de las herramientas de desarrollo corrió por parte de la Universidad. Entre otras tecnologías, fue utilizado el entorno de Microsoft.Net Framework para desarrollo; Microsoft SQL Server 2000 como base de datos; Microsoft Internet Information Server 6.0 como servidor de aplicaciones. Dentro de los lenguajes de programación que ofrece Microsoft.Net, se eligió C#. II. TECNOLOGÍAS UTILIZADAS A. Microsoft.Net Framework Microsoft.Net Framework es el modelo de programación de la plataforma.net para crear, implementar y ejecutar aplicaciones Web, aplicaciones de cliente inteligente y Web Services. Administra gran parte de los detalles de infraestructura, permitiendo a los desarrolladores centrarse en escribir el código de la lógica empresarial para sus aplicaciones. El Framework.NET incluye Common Language Runtime, el cual permite independizarlo del lenguaje escogido, y facilitando de este modo el diseño de componentes y aplicaciones cuyos objetos interactúan con distintos lenguajes. B. Microsoft SQL Server 2000 Como servidor de base de datos, se utilizó Microsoft SQL Server 2000, el cual es accedido a través de la tecnología ADO.Net. C. Microsoft Visual Source Safe (VSS) Microsoft VSS ayuda a mantener el control de versionado de los proyectos. Permite almacenar cualquier tipo de archivo (archivos de texto y binarios) guardándolos en un repositorio de datos. Cuando se agrega un archivo a VSS, se hace una copia de seguridad del archivo en la base de datos, el cual quedará disponible para los demás usuarios. Los cambios que se hagan en el archivo se guardan de forma que se pueda recuperar una versión anterior en cualquier momento.

3 D. Microsoft Internet Information Server Como servidor de aplicaciones se utilizó Microsoft Internet Information Server (IIS) 6.0. La fuerte integración existente entre la plataforma.net y los servicios de Microsoft Internet Information Server dejan poco margen de maniobrabilidad para elegir otros servidores. E. Lenguaje de programación Visual C# Visual C# es uno de los lenguajes de programación que brinda la plataforma.net. La elección del mismo como lenguaje para codificar la aplicación se basó en su similitud con Java y en su gran facilidad de aprendizaje. F. Remoting Remoting permite instanciar objetos remotos y realizar llamadas a sus métodos. Al igual que el mecanismo de Java-RMI, los objetos pueden ser pasados por valor o por referencia. Si son pasados por valor, el objeto entero se serializa viajando de la máquina servidor al cliente, donde los métodos serán invocados localmente. La segunda opción permite que los métodos sean procesados por el servidor. A través de remoting, los distintos componentes de un sistema pueden distribuirse fácilmente, ya sea dentro de la misma computadora, o en sitios remotos. G. ASP.NET ASP.NET es una plataforma de desarrollo Web unificada, que provee los servicios necesarios para construir soluciones empresariales. Al crear una aplicación ASP.NET, se pueden utilizar tanto formularios Web como Web Services, e incluso combinarlos de acuerdo a las necesidades del producto. H. Web Services Un Web Service es una unidad programable que puede ser accedida a través de Internet y utilizada remotamente. Al igual que con remoting, un Web Service puede ser utilizado internamente por una aplicación, o ser publicado en Internet y usado por múltiples aplicaciones. La ventaja del concepto de Web Service es que, al hacer uso de un protocolo estándar de comunicación (SOAP), puede conectar sistemas heterogéneos y hacerlos trabajar en conjunto como si fueran uno.

4 III. ASPECTOS NO FUNCIONALES DE LA SOLUCIÓN El verdadero valor de la aplicación ECAPS radica en su diseño, ya que éste le permite atacar requerimientos no funcionales como ser la flexibilidad, extensibilidad, mantenibilidad, configurabilidad y escalablilidad. A. Núcleo El núcleo fue concebido para trabajar como un subsistema y en forma modular. Esto significa que todas las funcionalidades de la aplicación son accedidas a través de una interfaz, denominada Manejador de Proyectos, la cual se encarga de distribuirlas entre distintos componentes. Este encapsulamiento de funcionalidades permite el desarrollo relativamente sencillo y rápido de Web Services, los cuales habilitarán la creación de nuevas y variadas interfaces gráficas. Actualmente, la solución publica un Web Service que permite al usuario trabajar en su carpeta de trabajo sin utilizar la interfaz Web-based. B. Sistema de versionado Dada la variedad de sistemas de versionado existentes (VSS, CVS, etc.), y como forma de contemplar las necesidades de cada usuario, el módulo de versionado (ECAPSVS) también fue diseñado para trabajar como un subsistema. Esto abre la posibilidad de sustituir un sistema de versionado por otro sin necesidad de actualizar el resto del núcleo. Incluso, podría existir la posibilidad de realizar la sustitución en forma dinámica. C. Compilación Uno de los puntos débiles que debe enfrentar una aplicación de esta índole, es el problema de escalabilidad de los servicios de compilación. Si el número de usuarios aumenta, también lo hará el número de solicitudes de compilación. Si no se cuenta con los recursos apropiados, los servicios de compilación podrían saturarse y posponer las solicitudes demasiado tiempo. El problema de los recursos puede solucionarse si el sistema cuenta con una granja de compiladores que pueda distribuir la carga de solicitudes. Debe existir un director que analice las solicitudes y la carga de cada servidor con la finalidad de lograr una distribución eficiente. Asimismo, la solución debe contemplar la posibilidad de ampliar fácilmente esta granja de compiladores, en caso de que el número de usuarios y por consiguiente, el número de solicitudes de compilación- aumente. Una manera de controlar el número de solicitudes es no permitir que cualquier usuario del sistema pueda compilar. Las opciones de a qué usuario elegir son infinitas, aunque no todas son igual de justas: sólo a los administradores de los proyectos, a los usuarios con determinado rol asignado, a aquellos cuyo historial de compilación indica que tienen una baja tasa de errores, etc. La solución propuesta por SourceForge corre en este sentido. Los usuarios de SourceForge deben realizar una propuesta de compilación, la cual es aceptada o rechazada por los administradores del sitio. En caso de ser aceptada, SourceForge habilita una cuenta de compilación, un espacio en disco de unos 256 Mb, y una conexión vía SSH a la carpeta de trabajo asignada. No hay posibilidad de que el usuario copie el contenido de su proyecto a la carpeta de trabajo. El usuario debe descargar

5 su proyecto desde el servidor a su computador y luego subirlo a la carpeta de trabajo asignada. La gran ventaja de SourceForge es la variedad de plataformas operativas y arquitecturas de hardware presentadas. Por más información ver [1]. Ilustración 1 Esquema del mecanismo de compilación propuesto por SourceForge. En (1), el usuario envía una solicitud de compilación a los administradores. En la fase (2), los administradores han aceptado la solicitud y se le proporciona un servidor de compilación al usuario. El enfoque de ECAPS es parcialmente distinto. La aplicación cuenta con una infraestructura que permite conectar el núcleo con una granja de compiladores, la cual potencialmente podrá ser ampliada. Las solicitudes de compilación de los usuarios son recibidas inicialmente por el núcleo de ECAPS, y son enviadas, vía remoting, a un Módulo de Compilación remoto (ECAPSCS). El encargado de recibir las solicitudes de compilación en ECAPSCS es el director de compilación. En la versión actual de la solución, el director selecciona el compilador dependiendo del lenguaje que el usuario quiere compilar. En versiones futuras, el director podrá distribuir las solicitudes no sólo en base al lenguaje, sino también en base a la carga de cada compilador.

6 Ilustración 2 Esquema de compilación propuesto por ECAPS. En (1), el usuario envía la solicitud al núcleo, la cual es transferida al servicio de compilación. La solicitud es dirigida al compilador apropiado, y el resultado es depositado en la carpeta de trabajo del usuario (2). El diseño de esta solución fuertemente basada en componentes, sumado al hecho de que la comunicación del núcleo con ECAPSCS se realiza a través de remoting, permite la reutilización y el desacoplamiento entre las partes. En versiones futuras, por ejemplo, todo el módulo ECAPSCS podría ser rediseñado sin necesidad de retocar el núcleo. El núcleo de ECAPS puede configurarse fácilmente, habilitando la reubicación del módulo de compilación donde más convenga. D. Comunicación Buscar un mecanismo de comunicación entre el núcleo y los usuarios no es trivial, dada la diversidad de medios proporcionados por el mercado: correo electrónico, Microsoft Messenger, Yahoo! Messenger, ICQ, AOL, mirc, etc. El módulo de comunicación de la aplicación (ECAPSCOMM) independiza el usuario del medio. Esto significa que el núcleo no tiene por qué conocer el medio por el cual será enviado un determinado mensaje al usuario. Por ejemplo, un mensaje podría estar configurado para ser enviado a través de correo electrónico y Microsoft Messenger; el núcleo simplemente le indica a ECAPSCOMM que envíe el mensaje a un usuario determinado y ECAPSCOMM resolverá por qué medio hacerlo. IV. ADMINISTRACIÓN DE PROYECTOS La administración de proyectos de software involucra, entre otros aspectos, la necesidad de predecir muchas cosas: el esfuerzo y el cronograma, el número de defectos de software, la confiabilidad de un nuevo sistema, etc. (Para más información ver [2].) Existen en el mercado muchos productos que ayudan a la administración de proyectos de software, pero en general, cada uno aborda el problema desde un ángulo distinto. Algunos ayudan a extraer datos de las planillas de horas, otros a detectar corrimientos de esfuerzo y calendario a partir del cronograma de tareas y el plan de proyecto, otros a predecir la confiabilidad en base a datos

7 obtenidos en la fase de verificación, etc. Incluso los más completos están divorciados de los datos reales y se basan en datos ingresados por los administradores. La tecnología de hoy en día permite vincular distintas aplicaciones para colaborar como una unidad única. Los datos que se extraen de la compilación de un proyecto, podrían tomarse como datos de entrada en una aplicación que realiza predicciones en base al número de defectos de software. La cantidad de descargas y la evaluación de los usuarios podrían tomarse como indicador de la confiabilidad de un producto. A los ojos del usuario, existiría un único sistema que le permite desarrollar software, llevar un control de sus actividades y obtener datos que le ayuden a administrar sus proyectos... todo a través de Internet. Aunque ECAPS apenas acaricia tímidamente todos estos conceptos, se dirige hacia ellos. Una pieza importante de la aplicación es la infraestructura necesaria que permite al usuario administrar proyectos de software. La solución cuenta con módulos para administrar roles, recursos laborales, tareas y facilitar el seguimiento del proyecto. Se deja a consideración futura el acoplamiento de reglas de negocio que posibiliten el manejo de recursos materiales.

8 A. Recursos laborales y materiales Dentro de los límites de la aplicación, se define recurso laboral como todo usuario asignado a un determinado proyecto. Un usuario pasa a ser recurso laboral de un proyecto cuando el administrador lo asigna al mismo. Esta primera versión está estructurada para trabajar con un subconjunto de los recursos materiales blandos : archivos y tiempo de compilación. Todo recurso laboral debe tener por lo menos un rol asignado. Esto permite limitar el acceso de los usuarios a determinadas funcionalidades. Vale la pena recalcar que el alcance de los roles es a nivel de proyecto, es decir que los roles asociados a un usuario para un determinado proyecto dejan de tener validez para otros proyectos. B. Asignación de tareas Los recursos laborales son responsables del cumplimiento de diversas tareas. El éxito o el fracaso de dicho cumplimiento será el determinante del éxito del proyecto. C. Seguimiento Esta primera versión de la aplicación permite realizar el seguimiento del avance de las tareas y la dedicación diaria de los recursos laborales. Esto permite controlar el estado de avance del proyecto, así como detectar corrimientos de esfuerzo y calendario. V. DESARROLLO DE PROYECTOS A. Carpetas de trabajo y sistema de versionado Cada recurso laboral cuenta con una carpeta de trabajo por proyecto. En esta carpeta, el usuario podrá subir archivos, crear directorios, borrar información, editar documentos y código, compilar fuentes, etc. Esto permite que cada recurso pueda trabajar de manera independiente, sin afectar el contenido del proyecto en desarrollo. El proyecto está guardado a salvo en un repositorio, el cual es accedido por el sistema de versionado. De esta forma, cuando el usuario necesite trabajar en un determinado archivo, primero deberá realizar el check-out del archivo en el repositorio. Posteriormente, podrá bajarlo a la carpeta de trabajo para realizar las modificaciones pertinentes, y al finalizar deberá hacer un check-in del archivo, para permitir que otros recursos laborales puedan trabajar en él.

9 Ilustración 3 Diagrama de cómo se distribuyen las carpetas de trabajo en cada proyecto B. Colaboración entre proyectos Los trabajos desarrollados en los distintos proyectos pueden ser compartidos, para permitir la colaboración entre los equipos de desarrollo. Por ejemplo, un equipo podría estar desarrollando la capa lógica y otro la interfaz Web. Cada vez que el primer equipo disponga de una versión estable, podrá compartirla y será utilizada por el otro como insumo de su producto. Al igual que otros productos que cuentan con facilidades para desarrollar proyectos, ECAPS permite que el resultado del trabajo sea publicado y compartido con la comunidad. C. Módulo de compilación El manejador de compilación es quien recibe las solicitudes de compilación del módulo. Las solicitudes de compilación poseen una directriz que indica qué lenguaje debe compilarse, la dirección donde se encuentran los fuentes y los parámetros del compilador. Una vez determinado el lenguaje, el manejador envía la solicitud al compilador apropiado. Los compiladores no aceptan directamente los parámetros de compilación. El sistema registra qué parámetros serán aceptados, en qué orden y los verifica y pre-parsea en caso de ser necesario. D. Módulo de comunicación El módulo de comunicación está diseñado para registrar diversos medios de comunicación para flexibilizar la comunicación entre la aplicación y los usuarios registrados. Los mensajes que el núcleo envía a los usuarios son almacenados en la base de datos. Cada mensaje posee información sobre los medios por los cuales será enviado. El mecanismo de envío de mensajes se resume a continuación: - El núcleo solicita al módulo de comunicación que envíe un determinado mensaje a un grupo usuarios.

10 - El módulo obtiene de la base el mensaje a enviar y prepara los medios de comunicación asociados. Inmediatamente, envía el mensaje a cada medio, mencionando el destinatario (alias del usuario). - Cada uno de los medios hace corresponder el destinatario con la dirección real y finalmente se envía el mensaje. VI. ARQUITECTURA El sistema está dividido en siete componentes: el núcleo (ECAPSCORE) donde se concentra la mayor parte de la lógica del negocio, la interfaz Web (ECAPSUI), el módulo de comunicación (ECAPSCOMM), el módulo de persistencia (ECAPSDATA), los Web Services (WebServices) el subsistema de versionado (ECAPSVS), y los servicios de compilación (ECAPSCS). Los primeros seis componentes están distribuidos en el mismo nodo, mientras que el último es remoto. Dada la modularidad del diseño, y la facilidad de implementar llamadas a procedimientos remotos, es posible distribuir aún más los componentes. Ilustración 4 Arquitectura dividida en componentes El componente del modulo de compilación puede distribuirse a otra máquina, siempre y cuando ésta pertenezca a una red compatible con la funcionalidad de compartir archivos para redes Microsoft, y por supuesto, que tenga acceso a los datos que se desean compilar. La arquitectura de la solución puede verse como el trabajo colaborativo de tres capas: presentación, lógica de negocio y persistenacia. Los componentes ECAPSUI y WebServices forman la capa de presentación. La capa de negocio está compuesta por los módulos ECAPSCORE, ECAPSVS, ECAPSCOMM y ECAPSDATA. La capa de persistencia está integrada por la base de

11 datos, el repositorio del sistema de versionado y el sistema de archivos del Sistema Operativo, donde se almacenan las carpetas de trabajo de los usuarios, entre otra información. Ilustración 5 Arquitectura dividida en capas A. Presentación Para elaborar las páginas que componen la interfaz Web, se utilizó la tecnología ASP.Net, la cual permite al desarrollador enfocarse en el problema concreto y no distraerse con detalles técnicos. La variedad de componentes proporcionados por ASP.Net, sumado a la posibilidad de extender los ya existentes o crear nuevos, permiten reducir los tiempos de desarrollo. ASP.Net también se encarga del manejo de la sesión. El Web Service desarrollado publica parte de la funcionalidad de manejo de la carpeta de trabajo. B. Lógica Los mensajes provenientes de la capa de presentación son recibidos por la interfaz de manejo de proyectos. La lógica de casos de uso se encarga de la seguridad, el manejo de tareas, recursos laborales, manejo de la carpeta de trabajo, publicación de archivos, etc. La comunicación con la base de datos se realiza a través del módulo de acceso a datos, que utiliza ADO.Net. Entre otras ventajas, ADO.Net automáticamente guarda las conexiones a la base en un pool de conexiones, lo cual mejora la performance del sistema. El módulo de versionado conecta la lógica con el repositorio donde se guarda el proyecto. Para almacenar los archivos provenientes del repositorio en la carpeta de trabajo del usuario, el sistema se comunica con el File System, utilizando las funcionalidades del Sistema Operativo.

12 La aplicación envía las solicitudes de compilación a través de un Proxy, el cual se encarga de redirigirlas vía remoting- a la granja de compiladores. C. Persistencia La comunicación entre la lógica de casos de uso y el SQL Server es realizada a través de un intermediario, utilizando XML como protocolo de comunicación. Este mecanismo logra evitar que las consultas a la base sean escritas en el código fuente de la aplicación, permitiendo una independencia absoluta entre la lógica y la persistencia, favoreciendo posibles instancias de migración. Las consultas se almacenan en documentos XML denominados diccionarios de consulta, los cuales, además de contener las consultas SQL, poseen la cadena de conexión a la base. Esto permite que el traslado de la base a un lugar remoto sea extremadamente sencillo. El repositorio del sistema de versionado también puede ser trasladado remotamente, lo cual puede ser una gran ventaja en materia de seguridad. Lo mismo ocurre con las carpetas de trabajo. En ambos casos, los nodos que los alojen deberán ser compatibles con la red de Microsoft. VII. OTROS ASPECTOS DE LA SOLUCIÓN A. Interfaces alternativas Como se ha mencionado, el desarrollo de Web Services permiten que la aplicación pueda contar con múltiples IDE. A modo de ejemplo, esta primera versión de ECAPS publica un Web Service con algunas funcionalidades vinculadas con la carpeta de trabajo. Asimismo, se incluye una aplicación de consola que utiliza este Web Service permitiendo que el usuario se autentique en el sistema, se conecte a un proyecto y realice tareas de mantenimiento sobre su carpeta de trabajo (subida y descarga de archivos, cambio de directorio, etc.). B. Comandos Un comando ECAPS (ECapsCommand) es una abstracción de la línea de comandos de cualquier sistema operativo. Se trata de un objeto que posee un nombre del comando a ejecutar, y una serie de parámetros. Su objetivo es independizar el proceso de análisis y ejecución del comando, de las múltiples formas que puede adoptar en distintas interfaces gráficas. Actualmente el módulo de compilación recibe un comando ECAPS dentro de la solicitud. Si bien el comando pudo haberse armado a partir de una línea de comandos, de un archivo XML, etc., el módulo de compilación sólo debe recorrer el objeto en busca de los parámetros. C. Variables de entorno El sistema almacena un conjunto de variables de entorno por usuario, las cuales pueden ser accedidas desde cualquier parte. Dichas variables tienen un nivel determinado: variables globales, de proyecto y de usuario. Por cada usuario que se autentica en el sistema, se crea un conjunto de variables de entorno divididas en niveles. Existe una jerarquía entre los niveles; en caso de que dos variables con el mismo nombre pertenezcan a niveles distintos, el sistema escogerá la aquella que se

13 encuentre en el nivel más bajo. El nivel más alto es el global, luego está el de proyecto y finalmente el de usuario. El objetivo de este diseño es que, por un lado, cualquier módulo del sistema pueda acceder su propia configuración de una manera sencilla. Por otro lado, la idea es que al estar todas centralizadas en un mismo lugar, las variables de entorno puedan ser referenciadas desde los comandos ECAPS. Originalmente, este concepto fue desarrollado para satisfacer la necesidad de crear descriptores de proyectos que faciliten la labor de compilación de los usuarios. Un descriptor de proyecto podría ser un archivo XML con información sobre cómo compilar el proyecto. Esta información no sería otra cosa que el propio comando de compilación, donde los datos concretos son sustituidos por referencias a variables de entorno. Antes de enviar a compilar, las variables serían sustituidas por su valor real. Un ejemplo de descriptor de proyectos podría ser el siguiente: <ECapsCommand> <name>compile</name> <paramlist> <param id= input >%MAIN_CLASS%</param> <param id= libs >%LIB_PATH%;/lib/</param> <param id= out >%OUTPUT_FILE%</param> </paramlist> </ECapsCommand> Si el sistema tiene almacenado los valores Main.cs, /;/xerceslib/ y Main.exe para las variables MAIN_CLASS, LIB_PATH y OUTPUT_FILE, respectivamente, entonces el resultado de parsear el descriptor sería: <ECapsCommand> <name>compile</name> <paramlist> <param id= input >Main.cs</param> <param id= libs >/;/xerceslib/;/lib/</param> <param id= out >Main.exe</param> </paramlist> </ECapsCommand> Esta solución no fue implementada en la versión actual de la aplicación. D. Configuración La aplicación fue diseñada para que sus módulos sean configurables. Variables como la ubicación de las carpetas de trabajo, del repositorio del sistema de versionado, de las variables de entorno, de los documentos compartidos y públicos, entre otras, son guardadas en un único archivo de configuración. Este archivo puede ser modificado por el implantador del sistema, para adecuarlo a sus necesidades.

14 VIII. MEJORAS PROPUESTAS A. Mejoras al módulo de compilación En esta primer versión de la aplicación, el módulo de compilación cuanta con un único servicio de compilación. Si bien ECAPS cuenta con la infraestructura necesaria para aumentar el número de lenguajes que pueden ser compilados, no es capaz de nivelar la carga de solicitudes de compilación. Para implementar una mejora de esta naturaleza, habría que empezar por rediseñar el módulo de compilación. Un cambio en el mismo no debería repercutir en el núcleo del sistema e incluso, en virtud de tratarse de un módulo remoto, el cambio podría realizarse en tiempo de ejecución, sin necesidad de reiniciar la aplicación. B. Publicación de más funcionalidades Se sugiere continuar con la publicación de funcionalidades del núcleo a través de Web Services, con el objetivo de generar nuevas interfaces de usuario que sacar provecho de las posibilidades que brinda contar con un cliente grueso. Por ejemplo, la carpeta de trabajo de los recursos laborales podría trasladarse al cliente, dejando a la que queda en el servidor como intermediaria entre los archivos y el repositorio del sistema de versionado. Una solución del estilo, alivianaría el espacio en disco que ocupan los archivos de los usuarios. C. Autenticación Quedó pendiente para próximas versiones la utilización Microsoft Passport para autenticar a los usuarios de la aplicación. D. Seguridad Si bien ECAPS cuenta con toda la estructura necesaria para el manejo de roles y permisos, actualmente sólo se están utilizando de manera informativa. Queda como trabajo futuro la implementación del módulo de seguridad, que restrinja el acceso de recursos laborales a funcionalidades restringidas. E. Ampliación del sistema de versionado Actualmente el administrador de la aplicación podría cambiar manualmente un sistema de versionado por otro, tarea que probablemente le resulte demasiado engorrosa. Queda pendiente la implementación de un módulo que permita agregar nuevos sistemas de versionados en tiempo de ejecución. F. Configuración del sistema de mensajería

15 Sería interesante que el sistema de mensajería contara con una interfaz que permita configurar los destinos a los cuales será enviado el mensaje. IX. TECNOLOGÍAS A INVESTIGAR En el inicio de la investigación actual quedaron muchas cosas que no se pudieron investigar a fondo. Existen muchas tecnologías que podrían mejorar las funcionalidades de ECAPS. Profundizar en temas como el registro de errores, administración y seguimiento del proyecto, seguridad de archivos, versionado no solo a nivel de archivos sino a nivel de objetos (clases, métodos, etc.). La inclusión de tecnologías como MS Project Server, Log4Net y WSE 2.0 surgen como una posibilidad para mejorar el producto. A. Administración Para ampliar la funcionalidad de administración de ECAPS, se deberían tener en cuenta aspectos de coordinación, administración, estandarización y calidad en la gestión del proyecto. Se propone investigar la solución Enterprise Project Managment (EPM), enfocada a organizaciones que necesiten un alto nivel de coordinación y estandarización entre proyectos y administradores de proyectos, administración centralizada de los recursos o un mayor nivel de creación de informes acerca de los proyectos y los recursos. Por otro lado, Microsoft provee una familia de productos vinculados con las tareas de administración: Microsoft Office Project Standard 2003, Microsoft Office Project Professional 2003, Microsoft Office Project Server 2003 y Microsoft Office Project Web Access. En particular, Project Server 2003 expone características importantes para la gestión de proyectos. Todos estos productos utilizan estándares de comunicación como XML y SOAP. B. Web Service Enhancements Microsoft Web Service Enhancements (WSE 2.0) brinda un modelo de objetos basado en mensajes que soporta múltiples transportes, incluyendo TCP y HTTP, así como comunicaciones sincrónicas y asincrónicas. Esta capacidad asincrónica es particularmente útil para operaciones largas que pueden tomar horas. WSE Implementa las más recientes especificaciones del protocolo de Web Services, garantizando compatibilidad con diferentes plataformas. C. Application block Microsoft provee diferentes application blocks, los cuales son implementados para garantizar y maximizar la performance en los puntos críticos de la aplicación. Entre ellos, se cuentan el Exception Management Application Block, el Data Access Application Block y el Caching Application Block. X. CONCLUSIONES Uno de los objetivos de la solución fue hacer hincapié en la parte de administración de proyectos de software. El sistema está estructurado para poder manejar recursos laborales y materiales, tareas,

16 roles, privilegios, registro de horas de trabajo, etc. Si bien las capas inferiores están casi totalmente preparadas para hacer uso de estas funcionalidades, aún faltan publicar muchas funciones en la interfaz del manejador de proyectos. Contar con un manejo adecuado de la seguridad de roles, asignar recursos materiales a tareas y controlar la forma en que estos son utilizados por los recursos laborales, son ejemplos del trabajo que sería interesante continuar. Si bien queda mucho camino por recorrer, siempre se intentó encontrar un diseño extensible para que la aplicación pueda ser ampliada en el futuro. Un ejemplo concreto de esta búsqueda es el diseño del módulo de comunicación, que permite agregar tantos canales de comunicación como sean necesarios. El bajo acoplamiento entre los distintos módulos, sumado a la alta modularidad del diseño, facilita la mantenibilidad del sistema. Si el usuario programador quisiera reestructurar la solución, para que todo el sistema de archivos sea almacenado en la base de datos, no habría necesidad de reprogramar mucho más que el módulo FileSystem. Queda todavía por mejorar el módulo de compilación, que permita una distribución de la carga según el grado de saturación de los servicios de compilación, como forma de aumentar la escalabilidad del sistema. Esta fue una de las razones por las cuales se decidió separar el núcleo del sistema del módulo de compilación: la implementación de una mejora tendría un impacto nulo en el núcleo e incluso podrían intercambiarse dinámicamente la versión vieja con la versión corregida. Con respecto a las tecnologías utilizadas, y dejando de lado comentarios respecto a la poca libertad que otorga la plataforma para trabajar con productos de terceros, cabe destacar que la utilización de.net Framework logra reducir los tiempos de desarrollo, al permitir salvo algunas excepciones producto del proceso natural de aprendizaje- que el desarrollador se concentre en la solución y no en detalles técnicos de implementación. XI. REFERENCIAS [1] SourceForge.net: Compile Farm [2] Shari Lawrence Pfleeger (2002), Ingeniería de Software, Teoría y Práctica (Software Engineering: Therory and Practice),