de obtener de forma automatizada una gran cantidad de by HC120704141152

VIEWS: 5 PAGES: 64

									                                                                            Memoria
                                                                        del Proyecto




                                  INDICE

1. Introducción ...................................................................... 2

2. Estado actual del sistema .................................................. 11

3. Estudio y selección de alternativas ..................................... 15

4. Viabilidad del proyecto ...................................................... 29

5. Estudio técnico ................................................................ 34

6. Ingeniería de calidad ........................................................ 46

7. Programación temporal. .................................................... 51

8. Normas para la explotación del nuevo sistema ..................... 55

9. Presupuesto y estudio económico ....................................... 59




                                                                                           1 / 64
                                                              Memoria
                                                          del Proyecto




1. Introducción.
1.1 Objeto.
   La finalidad de nuestro proyecto consiste en el desarrollo de una
agenda corporativa universitaria, con acceso autenticado contra el
LDAP de la UMU (radius). Debemos partir de alguna de las agendas
de software libre que hay actualmente, personalizando el idioma, y
ciertas particularidades de nuestra Universidad, de modo que se
puedan proponer convocatorias de reuniones a PAS o PDI de
cualquier sitio, con opción a saber si están libres o no, y con
integración con e-mail.

   Nosotros nos encargaremos de desarrollar el software necesario
para generar la agenda corporativa a partir de la implementación de
alguna otra agenda de libre distribución.

    El alcance de este proyecto se presenta ilimitado ya que el sistema
podrá ser actualizado a nuevas tecnologías y funciones futuras. Por
ello, el desarrollo de nuestro sistema será lo más extensible posible.

   El objeto consistirá en todas las funciones que incorporará nuestro
sistema final en base a la agenda corporativa elegida como punto de
partida para nuestro proyecto.

1.2 Promotor del proyecto. Encargado de proyecto.
   El promotor del proyecto será la empresa ATICA, empresa
localizada en el campus de Espinado (Murcia), que se comunica con
nuestra empresa RevolutioNet mediante Tomás Jiménez García, el
jefe del área Tecnologías e Informática en ATICA.

   La empresa encargada de realizar el proyecto es RevolutioNet,
cuya plantilla esta constituida por los siguientes profesionales:
Fernando Torres Pascual, Moisés Hernández Fernández, Gonzalo
Ruipérez García, Iván Lorca Lázaro, Mario Losantos Albacete, Jesús
Ruiz Nicolás, Mariano Madrigal Arqués y Juan Eduardo Ramírez
Monreal.

   Los clientes finales serán el conjunto de personal de
administración y servicios de la universidad, así como el personal
docente de investigación.




                                                                          2 / 64
                                                                Memoria
                                                            del Proyecto

1.3 Antecedentes.
   Tradicionalmente, la comunicación entre el conjunto de personal
de toda organización se realizaba mediante conversación humana (los
superiores citan a sus empleados) llamamientos de personal en
tablones, o mediante notificaciones telefónicas, vía fax o e-mail (las
más recientes); tras la notificación, cada individuo debía ser
responsable de recordar la cita, confirmar su asistencia a la misma e
incluso de guardar cualquier información de interés relacionada.
Desde luego alguien debía encargarse de coordinar las agendas de
todo el personal, establecer la comunicación y almacenar todos los
datos de interés.

      La agenda corporativa nos ayudará con todas estas tareas, ya
que facilitará la convocatoria de reuniones al conjunto del personal
deseado, comprobando si todos los convocados están libres o no, y
avisándoles con alertas vía e-mail; así mismo, todas estas actividades
quedarán registradas y almacenadas en una base de datos común
para facilitar su posterior consulta, con lo que, en definitiva, se
automatizará y centralizará la gestión del tiempo de la empresa, lo
cual resulta muy práctico debido al ahorro de trabajo y tiempo que
supone y a la mejor organización que ofrece al conjunto de usuarios
de la misma.


1.4 Bases del proyecto.
   Como hemos comentado en apartados anteriores, la base sobre la
que se asienta el proyecto, es la creación de la agenda electrónica
universitaria, partiendo de la necesidad por parte de los usuarios
finales, de un producto que les proporcione una total organización de
su tiempo, actividades, contactos, etc.

   Para todo ello el condicionante básico que impondría el promotor
del proyecto sería el acoplamiento entre nuestro sistema y el de la
empresa en cuestión (ATICA). Otros condicionantes impuestos por el
promotor son:
       Desarrollo de la agenda electrónica.
       Entrega del producto dentro del periodo establecido
       Funcionamiento correcto de la aplicación.
       Implementación de la aplicación con         vistas   a   posibles
       reediciones por cambios en el entorno.




                                                                           3 / 64
                                                              Memoria
                                                          del Proyecto

1.5 Relación de normas y reglamentos.
   Dado el carácter de la aplicación que se pide que desarrollemos
habrá que tratar con todos los aspectos derivados de los datos que se
manejan, cumpliendo en todo momento con la Ley Orgánica de
Protección de Datos.

   La Ley Orgánica 15/1999, de 13/XII, de Protección de Datos de
Carácter Personal (LOPD), y el R.D. 994/1999, de 11/VI, por el que
se aprueba el Reglamento de Medidas de Seguridad de los ficheros
automatizados que contengan datos de carácter personal
(Reglamento), son las dos disposiciones básicas que conforman el
marco legislativo de obligado cumplimiento para todas las empresas y
profesionales que, en el desarrollo de su actividad, traten datos de
carácter personal.

   La LOPD tiene un ámbito de aplicación más amplio que la LORTAD,
ya que no se limita al soporte digital exclusivamente, sino a todo tipo
de soportes físicos en los que se puedan almacenar ficheros de datos.
La LOPD se divide en siete títulos y una parte final compuesta por:
seis disposiciones adicionales, tres disposiciones transitorias, una
disposición derogatoria y tres disposiciones finales.


1.6 Metodología general.
   Nuestro      trabajo    consistirá  en   estudiar    las   posibles
implementaciones existentes de agendas corporativas de libre
distribución, eligiendo la que mas apropiada para nuestros propósitos,
tras lo cual implementaremos sobre ella las funcionalidades
necesarias para adaptarla a los requerimientos de nuestro cliente y
realizando las tareas de documentación necesaria.

   Debido a la naturaleza y complejidad del proyecto, se ha optado
por el modelo de desarrollo de software clásico, si bien se ha tenido a
bien adaptar el ciclo de desarrollo a las necesidades particulares del
proyecto, permitiendo optimizar recursos en cada fase. Las fases que
se realizarán son las clásicas, pero modificándolas para mantener la
coherencia del proyecto. Se realizan etapas (que se solapan) de
estudio de normativas, de análisis y especificación de requisitos y se
estudia el diseño de las agendas, pero prácticamente se pierde la fase
de implementación. Las últimas fases también son clásicas, aunque
siempre en el ciclo de desarrollo se mantiene la posibilidad de
realimentación: pruebas, instalación, mantenimiento...

   Teniendo en cuenta la duración del proyecto y el control de las
funcionalidades, esta sería la mejor elección.



                                                                          4 / 64
                                                             Memoria
                                                         del Proyecto

1.7 Plan del proyecto. Estructura documental.

  1. Introducción
  2. Estado actual del sistema
  3. Estudio y selección de alternativas
  4. Viabilidad del proyecto
  5. Estudio técnico
  6. Ingeniería de calidad
  7. Programación temporal.
  8. Normas para la explotación del nuevo sistema
  9. Presupuesto y estudio económico




1.8 Definiciones y nomenclatura.
  SMTP: Simple Mail Transfer Protocol. Protocolo utilizado para
enviar y recibir correo electrónico.


   HTTP: Hypertext transfer protocol. Protocolo para la transferencia
de páginas web.


   Software: Termino general que designa los diversos tipos de
programas usados en computación.


  W3C: World Wide Web Consortium.


   CSS: Las hojas de estilo en cascada (Cascading Style Sheets,
CSS) son un lenguaje formal usado para definir la presentación de un
documento estructurado escrito en HTML o XML (y por extensión en
XHTML). El W3C (World Wide Web Consortium) es el encargado de
formular la especificación de las hojas de estilo que servirá de
estándar para los agentes de usuario o navegadores. La idea que se
encuentra detrás del desarrollo de CSS es separar la estructura de un
documento de su presentación.


   Página Web: Resultado en hipertexto o hipermedia que
proporciona un navegador del WWW después de obtener la
información solicitada. Su contenido puede ir desde un texto corto a




                                                                        5 / 64
                                                               Memoria
                                                           del Proyecto

un voluminoso conjunto      de   textos,   gráficos   estáticos   o   en
movimiento, sonido, etc.


   Correo Electrónico (e-mail): El e-mail, o correo electrónico, es
uno de los servicios más usados en Internet, que permite el
intercambio de mensajes entre las personas conectadas a la red de
manera similar al correo tradicional.


   Servidor: un servidor es una combinación de equipo informático y
software que ofrece algún tipo de servicio a otros equipos que se
denominan clientes. Así, por ejemplo, un servidor puede ofrecen una
página web (servidor web) o el contenido de una base de datos
(servidor de base de datos).


   LDAP: LDAP son las siglas de Lightweight Directory Access
Protocol. Como su propio nombre indica, es un protocolo ligero para
acceder al servicio de directorio, especialmente al basado en X.500.
LDAP se ejecuta sobre TCP/IP o sobre otros servicios de transferencia
orientado a conexión.


   PHP: PHP (acrónimo recursivo de "PHP: Hypertext Preprocessor",
originado inicialmente del nombre PHP Tools, o Personal Home Page
Tools) es un lenguaje de programación interpretado, con licencia
OpenSource.


   Ingeniería Inversa: El objetivo de la ingeniería inversa es
obtener información técnica a partir de un producto accesible al
público, con el fin de determinar de qué está hecho, qué lo hace
funcionar y cómo fue fabricado.


   POP3: Tercera versión del protocolo diseñado para la gestión, el
acceso y la transferencia de mensajes de protocolo entre dos
máquinas, habitualmente un servidor y una máquina de usuario.


   WEBMAIL: Webmail, correo electrónico de sitio Web, correo
basado en Web o correo Web, es un servicio que permite acceder a tu
cuenta de correo electrónico a través de una página Web utilizando
un navegador y sin descargar los mensajes al propio ordenador.


   KERBEROS: Kerberos es un protocolo de autenticación de redes
de ordenador que permite a dos comunicantes en una red insegura
demostrarse su identidad mutuamente de manera segura.


                                                                           6 / 64
                                                             Memoria
                                                         del Proyecto

    El Instituto Tecnológico de Massachusetts (MIT) desarrolló
Kerberos para proteger los servicios de red proporcionados por el
proyecto Athena. El MIT distribuye una implementación de Kerberos
libremente bajo una licencia similar a la de BSD.


   Apache: El servidor HTTP Apache es un servidor HTTP de código
abierto para plataformas Unix (BSD, GNU/Linux, etcétera), Windows
y otras, que implementa el protocolo HTTP/1.1 (RFC 2616) y la
noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se
basó inicialmente en código del popular NCSA HTTPd 1.3, pero más
tarde fue reescrito por completo. Su nombre se debe a que
originalmente Apache consistía solamente en un conjunto de parches
a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un
servidor parcheado).

   El servidor Apache se desarrolla dentro del proyecto HTTP Server
(httpd) de la Apache Software Foundation.

   Apache presenta entre otras características mensajes de error
altamente configurables, bases de datos de autenticación y negociado
de contenido, pero fue criticado por la falta de una interfaz gráfica
que ayude en su configuración.

   En la actualidad (2005), Apache es el servidor HTTP más usado,
siendo el servidor HTTP del 70% de los sitios web en el mundo y
creciendo aún su cuota de mercado (estadísticas históricas y de uso
diario proporcionadas por Netcraft).

   Autenticación: Verificación de la identidad de una persona o de
un proceso en orden de acceder a un recurso o poder realizar una
determinada actividad. También se aplica a la verificación de
identidad de origen de un mensaje.


  PAS: Personal de Administración y Servicio.


  PDI: Personal Docente de Investigación.


   Aplicación web: En ingeniería del software una aplicación web es
aquella que los usuarios usan desde un servidor web a través de
Internet o de una intranet. Las aplicaciones web son populares debido
a la practicidad del navegador web como cliente ligero, La habilidad
para actualizar y mantener aplicaciones web sin distribuir e instalar
software en miles de potenciales clientes es otra razón de su
popularidad. Aplicaciones como los webmails, wikis, weblogs,



                                                                        7 / 64
                                                              Memoria
                                                          del Proyecto

MMORPGs, tiendas en línea y la wikipedia misma son ejemplos bien
conocidos de aplicaciones web.


   Página web dinámica: Página web cuyo contenido y forma varía
en función de su interacción con el cliente. La dinamización se puede
dar tanto de parte del servidor, que envía una página web
personalizada al cliente, como por parte del cliente, que una vez
recibida se adecua en el navegador.


   Oracle: Oracle es un sistema de administración de base de datos
(o RDBMS por el acrónimo en inglés de Relational Data Base
Management System), fabricado por Oracle Corporation. Se considera
a Oracle como uno de los sistemas de bases de datos más completos,
destacando su:


      Soporte de transacciones.

      Estabilidad.

      Escalabilidad.

      Es multiplataforma.


    Su mayor defecto es su enorme precio, que es de varios miles de
euros (según versiones y licencias). Otro aspecto que ha sido
criticado por algunos especialistas es la seguridad de la plataforma, y
las políticas de suministro de parches de seguridad, modificadas a
comienzos de 2005 y que incrementan el nivel de exposición de los
usuarios. En los parches de actualización provistos durante el primer
semestre     de   2005    fueron    corregidas    22   vulnerabilidades
públicamente conocidas, algunas de ellas con una antigüedad de más
de 2 años.


   Aunque su dominio en el mercado de servidores empresariales ha
sido casi total hasta hace poco, recientemente sufre la competencia
del Microsoft SQL Server de Microsoft y de la oferta de otros RDBMS
con licencia libre como PostgreSQL, MySql o Firebird. Las últimas
versiones de Oracle han sido certificadas para poder trabajar bajo
Linux.


   Groupware: es un conjunto de herramientas que permiten la
coordinación de grandes grupos de personas que trabajan en una
misma organización. La finalidad de esta familia de aplicaciones es la
de facilitar la compartición de información y la planificación de


                                                                          8 / 64
                                                              Memoria
                                                          del Proyecto

reuniones y eventos colectivos, así como de la gestión de los recursos
necesarios para los mismos.


  El concepto de groupware puede ser dividido en tres categorías
dependiendo del nivel de colaboración: Herramientas           de
comunicación, herramientas de conferencia y herramientas de
administración de colaboración.

   Herramientas de comunicación electrónicas envían mensajes,
archivos, datos o documentos entre personas y sirven para facilitar la
compartición de información. Ejemplos incluyen:

        e-mail
        fax
        mensajes de voz
        publicación en la web

   Herramientas de conferencia también facilitan la compartición
de información pero lo hacen de manera mucho más interactiva.
Ejemplos incluyen:

        conferencias de datos (ordenadores en red que tienen una
        pizarra común que cada usuario puede modificar)
        conferencias de voz (los teléfonos permiten a los usuarios
        interaccionar)
        conferencias de video (y de audio) (ordenadores en read
        pueden compartir señales de audio y vídeo)
        foros de Internet (también conocidos como pizarras de
        mensajes o foros de discusión) (plataformas de discusión
        que facilitan y administran mensajes de texto)
        salas de conversación (una plataforma virtual de discusión
        para facilitar y administrar mensajes de texto en tiempo
        real)
        sistemas de reunión electrónicos (Electronic Meeting
        Systems) (un sistema de conferencia construido en una
        habitación. La habitación de propósito general contendrá un
        proyector conectado a varios PCs.)

  Herramientas de administración de colaboración facilitan y
administran actividades en grupo. Ejemplos incluyen:

        calendarios electrónicos (también llamados software de
        administración    de    tiempo)  Planifica eventos   y

                                                                         9 / 64
                                                             Memoria
                                                         del Proyecto

        automáticamente notifica y realiza recordatorios a los
        miembros del grupo
        sistemas de administración de proyectos (planifica, registra
        y almacena información acerca de los pasos en un proyecto
        mientras se lleva a cabo)
        sistemas de flujo de trabajo (administración de colaboración
        de tareas y documentos dentro de un proceso de negocio
        basado en el conocimiento)
        sistemas de administración del conocimiento (obtiene,
        organiza, administra y comparte varias formas de
        información)
        sistemas de extrared (también conocidos como proyectos de
        extrared) (obtiene, organiza, administra y comparte
        información asociada con llevar a cabo un proyecto (por
        ejemplo: la construcción de un edificio)
        sistemas de software social (organiza las relaciones sociales
        de grupos de individuos)

  El software de colaboración puede ser tanto basado en web (como
UseModWiky o Scoop), o aplicaciones de escritorio (como CVS o
RCS).




                                                                    10 / 64
                                                              Memoria
                                                          del Proyecto


2. Estado actual del sistema.
2.1. La empresa:

   La empresa Ática (Área de Tecnologías de la Información y las
Comunicaciones Aplicadas), representa el Servicio de Informática de
la Universidad de Murcia.

   Está avalada por más de 30 proyectos externos en los últimos tres
años, y desarrollos innovadores alrededor de soluciones tecnológicas
avanzadas. Con esta carta de presentación, no es muy difícil
imaginarse que cuenta con una buenísima infraestructura y un S.I.
muy eficiente, al que ahora quieren añadirle una agenda corporativa
universitaria, proyecto que ha sido asignado a nuestra empresa
RevolutioNet.



2.2. Personal de la empresa:

   La empresa Ática la integran 53 personas y cuenta con una
persona al cargo de la dirección, se encuentra estructurada en:


      Servicio de Desarrollo, Aplicaciones y Metodologías:
Este servicio es el encargado del análisis, desarrollo y mantenimiento
de aplicaciones que se realizan en ATICA de la Universidad de Murcia,
del establecimiento de estándares y normativa del área y de la
gestión, garantía y control de calidad del software desarrollado y los
servicios prestados.


     Sección de Seguridad y Sistemas:
Dedicada a intentar que los sistemas se comporten como los usuarios
esperan de ellos.


     Servicio de Redes y Comunicaciones:
Se encarga de:
  La instalación y mantenimiento de su infraestructura de red
  (Cuenta con 3 Campus, 37 edificios y 5400 nodos de red).

  Instalación y Mantenimiento de los servicios telemáticos de
  Comunicaciones, como las cuentas de correo electrónico
  corporativo @um.es de todos los miembros de la Universidad.


                                                                     11 / 64
                                                              Memoria
                                                          del Proyecto

  Mantenimiento y Gestión del servidor de información www.um.es.

  Directorio LDAP, para búsqueda de datos sobre miembros de la
  Universidad o de otras instituciones. También centraliza los
  mecanismos de autenticación convirtiéndose en un repositorio
  central de cuentas de usuarios.

  Carga de datos desde Bases de Datos corporativas de la
  Universidad (Personal y Gestión Académica).

  Servidor proxy/caché con acceso priorizado, para mejorar los
  accesos externos.



NOTA: Aquí se han citado los componentes físicos de los que dispone
Ática, no se han citado los diversos equipos informáticos de los que
dispone.


     Sección de Soporte a Usuarios:
Se encarga de:
     Atención al usuario: Sistema DUMBO para la gestión de
     solicitudes e incidencias de la Universidad.
     Mantenimiento de las Aulas de Informática para el Alumnado.
     Servicios para el Alumnado: Correo electrónico, Fátima
     (Formación Avanzada en Tecnologías de la Información).



     Otros:
  Aquí se incluyen los miembros del personal de Ática.



2.3. Aplicaciones desarrolladas:

   A continuación mencionamos las aplicaciones, desarrolladas en el
marco de las autopistas de información, que facilitan la accesibilidad
y el manejo del S.I. de la organización:


     SUMA: consiste en poner al alcance información desde
     Internet, para todos los miembros pertenecientes a la
     Universidad, para facilitar la realización remota de tareas




                                                                     12 / 64
                                                             Memoria
                                                         del Proyecto

     administrativas y extracurriculares, así como lugar de subida y
     descarga de información para uso de la docencia.

     CARNET INTELIGENTE: permite el acceso a toda la
     información de       forma segura, sirve      para: Servicios
     universitarios, Control de accesos, Biblioteca universitaria,
     Secretaría Virtual, Info en web, Monedero electrónico y Tarjeta
     financiera.

     ECU: programa informático capaz de obtener de forma
     automatizada una gran cantidad de datos directamente de las
     bases de datos de la Universidad, para la realización anual de
     una evaluación de la calidad de diferentes centros, titulaciones,
     departamentos, áreas y servicios.

     GIPI: (Gestión Integrada de Proyectos Informáticos), se define
     una normalización de la gestión de todos los proyectos
     informáticos, para lo cual se harán marcando unos objetivos:

     1. Establecer una metodología de trabajo común a todos los
        proyectos de ÁTICA.

     2. Estandarizar la documentación que se desprenda de ella.

     3. Organizar dicha documentación de forma que sea totalmente
        accesible.

     4. Determinar el soporte informático más idóneo para ello.

   A la hora de establecer la mejor metodología de trabajo y al
mismo tiempo la mejor estandarización de la documentación, se ha
decidido utilizar la herramienta Requisite Pro de Rational que, entre
otros documentos, genera los de Visión, Casos de Uso, Requisitos de
Software, Test de Pruebas, Glosario, etc.

   Toda la documentación de los proyectos informáticos se pondrá en
un soporte informático adecuado (CD-ROM, página Web, etc) para
que cualquier usuario la pueda consultar. Además el usuario debe
disponer de ayuda en línea rápida y fácil de manejar para las
herramientas realizadas.

   En cuanto a la elección del soporte informático adecuado para la
generación y mantenimiento de la documentación, hasta ahora se
viene desarrollando con las herramientas Requisite Pro de Rational,
Developer, Designer, etc., lo único que se pretende es que todo lo
documentado sea transparente a la hora de cambiar de sistemas de
programación o a la hora de cambiar de hardware, así como la




                                                                     13 / 64
                                                           Memoria
                                                       del Proyecto

integración de dicha documentación en cualquier tipo de sistema
dentro de esta universidad o de cualquier otra.

   Así se consigue la estandarización de los métodos de
documentación y custodia de todos los proyectos informáticos que se
generen en la Universidad de Murcia.




                                                                  14 / 64
                                                              Memoria
                                                          del Proyecto


3. Estudio y selección de alternativas.
3.1. Introducción.
   Puesto que nuestro proyecto se trata de partir de una agenda
corporativa ya existente y adaptarla a las necesidades del cliente, en
este apartado llevamos a cabo un estudio sobre las distintas
plataformas groupware en el mundo del software libre, y evaluamos
cuál de ellas se acerca más a los requisitos expresados por el cliente.
La selección consistirá en evaluar la más apropiada de acuerdo a una
serie de criterios que describiremos a continuación.

      Adaptabilidad: consiste en la capacidad de la plataforma para
      ser modificada para alcanzar todos los requerimientos
      contratados por el cliente.

      Modularidad: característica del software que permite modificar
      partes del mismo sin afectar a otras partes. Una alta
      modularidad contribuye a una fácil adaptabilidad.

      Cercanía funcional: Se dará mayor prioridad a aquellas
      plataformas que cumplan un mayor número de requisitos
      reclamados por el cliente.

      Calidad funcional: Evaluaremos la manera en la que se
      proporciona la funcionalidad, esto es, adecuación a la necesidad
      exacta del cliente.

      Requerimientos de la propia plataforma: Estudiaremos
      cuáles son los requerimientos de la plataforma, como sistemas
      gestores de bases de datos que admitan, tecnología sobre la
      que se sustentan (ej.: servidor web sobre el que ejecutan, PHP,
      JSP, etc.).

      Simplicidad: se dará prioridad a aquellas plataformas que
      proporcionen un servicio a través de interfaces simples, este
      término se conoce como facilidad de uso.


3.2. Definición de la plataforma.
   Groupware: es un conjunto de herramientas que permiten la
coordinación de grandes grupos de personas que trabajan en una
misma organización. La finalidad de esta familia de aplicaciones es la
de facilitar la compartición de información y la planificación de
reuniones y eventos colectivos, así como de la gestión de los recursos
necesarios para los mismos. Las plataformas con esta tecnología
ofrecen como servicios a sus usuarios las siguientes características:



                                                                      15 / 64
                                                               Memoria
                                                           del Proyecto


     Sistema de gestión de eventos (reuniones): La plataforma
     proporciona un sistema para poder convocar a un grupo de
     usuarios a una cita un día determinado, mediante una
     notificación al correo electrónico o a través de otra aplicación.
     Agenda: La plataforma proporciona una agenda en la que
     planificar el tiempo de cada usuario. En ella se guardará
     constancia de las reuniones y citas de cada usuario.
     Sistema de gestión de contactos: La plataforma proporciona
     un sistema de almacenamiento de la información sobre los
     contactos del trabajo de sus usuarios, y proporciona un sistema
     para poder compartir dicha información de manera selectiva a
     otros usuarios.
     Sistema de gestión de usuarios y grupos: La plataforma
     proporciona perfiles de usuarios y grupos en los que
     englobarlos, de esta manera cada usuario tendrá acceso a su
     propia información y podrá compartir parte de ésta con su
     grupo, o selectivamente con otros usuarios si así lo desea.
     Sistema de gestión de proyectos: Determinadas plataformas
     que se engloban en este grupo proporcionan un sistema para
     almacenar información acerca del estado de un determinado
     proyecto, quién estuvo trabajando en él y durante cuanto
     tiempo. Esta información puede servir como información en la
     que basarse cuando se quiera elaborar un informe sobre un
     proyecto, o elaborar una factura del mismo.



3.3. Tecnologías en las que construir la plataforma.
   De entre todas las tecnologías entre las que podríamos basarnos
para el desarrollo de una agenda corporativa optamos por tecnologías
web. La principal razón para usar tecnologías web es que se basan en
HTTP sobre TCP en el puerto 80. Muchas empresas se protegen
mediante firewalls que filtran y bloquean gran parte del tráfico de
Internet. Por ello se cierran casi todos los puertos salvo el 80, porque
es el que usan los navegadores. Las aplicaciones web se realizan por
este puerto y ello las hace muy convenientes.

   Una segunda razón por la que la tecnología Web es muy práctica
es que puede aportar un débil acoplamiento entre la aplicación cliente
(normalmente un navegador) y la propia aplicación web. De esta
forma los cambios que cada uno realice con el tiempo no deben
afectar al otro. Esta flexibilidad será cada vez más importante, dado
que la tendencia a construir las aplicaciones grandes a partir de
componentes distribuidos más pequeños es cada día mayor. Este
hecho y la amplia difusión y desarrollo de aplicaciones Web, nos


                                                                       16 / 64
                                                              Memoria
                                                          del Proyecto

permiten que un usuario acceda a la aplicación desde un ordenador,
móvil o PDA, ejecutando un sistema operativo u otro, con cualquier
tipo de navegador que soporte los estándares actuales sin necesidad
de ninguna consideración respectiva al cliente final.

   Dentro de las tecnologías web, se elegirá una tecnología para
crear páginas web dinámicas en la parte del servidor. Una página web
dinámica es una página tal, que es capaz de interactuar con el cliente
y adaptar su contenido según tal interacción. Esta característica se
consigue mediante el establecimiento de la lógica de control de la
interacción con el usuario en el servidor web. El servidor web genera
cierto código HTML y lo envía al cliente por medio del protocolo HTTP.
Esta es la base tecnológica general para el desarrollo de las llamadas
aplicaciones web.

   Como se ha dicho, el servidor genera código HTML, acrónimo
inglés de Hypertext Markup Language (lenguaje de formato de
documentos de hipertexto), es un lenguaje de marcas diseñado para
estructurar textos y presentarlos en forma de hipertexto, que es el
formato estándar de las páginas web. Gracias a Internet y a los
navegadores del tipo Explorer, Mozilla, Opera, Firefox o Netscape,
HTML se ha convertido en uno de los formatos más populares que
existen para la construcción de documentos.

  HTML es hijo de SGML, aunque hay unas versiones de HTML como
XHTML que son descendientes de XML (otro hijo de SGML) y exigen
que se escriba mucho más para facilitar la vida a los navegadores,
que son aquellos programas que nos muestran información en
pantalla.

   Así, la información que los navegadores reciben estará en formato
HTML, lenguaje estándar en el que se expresa el contenido y forma
de una página web.


3.4. Tecnologías de creación de páginas web dinámicas.
3.4.1. Alternativas
   Existen varias alternativas tecnológicas para crear páginas web
dinámicas. Lamentablemente, la opción final vendrá posiblemente
determinada en mayor medida por la elección del software de partida
que se seleccione para ser modificado y adaptado para el cliente. No
obstante, será un factor muy importante a la hora de seleccionar el
software de partida, y por ello se describen a continuación las
posibles alternativas.




                                                                     17 / 64
                                                            Memoria
                                                        del Proyecto

PHP (acrónimo recursivo de "PHP: Hypertext Preprocessor",
originado inicialmente del nombre PHP Tools, o Personal Home
Page Tools) es un lenguaje de programación interpretado, con
licencia OpenSource.
El fácil uso y la similaridad con los más comunes lenguajes de
programación estructurada, como C y Perl, permiten a la mayoría
de los programadores experimentados crear aplicaciones
complejas con una curva aprendizaje muy suave. También les
permite envolverse con aplicaciones de contenido dinámico sin
tener que aprender todo un nuevo grupo de funciones y prácticas.
Debido al diseño de PHP, también es posible crear aplicaciones con
una interfaz gráfica para el usuario o GUI, utilizando la PHP-GTK.
También puede ser usado desde la Línea de comandos, como Perl
o Python.


Su interpretación y ejecución se da en el servidor en el cual se
encuentra almacenada la página y el cliente solo recibe el
resultado de la ejecución. Cuando el cliente hace una petición al
servidor para que le envíe una página web, enriquecida con código
PHP, el servidor interpretará las instrucciones mezcladas en el
cuerpo de la página y las sustituirá con el resultado de la ejecución
antes de enviar el resultado a la computadora del cliente. Además
es posible utilizarlo para generar archivos PDF, Flash o JPG, entre
otros.


Permite la conexión a numerosas bases de datos de forma nativa
tales como MySQL, Postgres, Oracle, ODBC, IBM DB2, Microsoft
SQL Server y SQLite, lo cual permite la creación de Aplicaciones
web muy robustas.


PHP tiene la capacidad de ser ejecutado en la mayoría de los
sistemas operativos tales como UNIX, Linux, Windows y Mac OS X,
y puede interactuar con los servidores de web más populares.



ASP (Active Server Pages) es una tecnología del lado servidor de
Microsoft para páginas web generadas dinámicamente, que ha sido
comercializada como un anexo a Internet Information Server
(IIS).


ASP ha pasado por cuatro iteraciones mayores, ASP 1.0
(distribuido con IIS 3.0), ASP 2.0 (distribuido con IIS 4.0), ASP
3.0 (distribuido con IIS 5.0) y ASP.NET (parte de la plataforma


                                                                    18 / 64
                                                            Memoria
                                                        del Proyecto

.NET de Microsoft). Las versiones pre-.NET         se   denominan
actualmente (desde 2002) como ASP clásico.


En el último ASP clásico, ASP 3.0, hay seis objetos integrados
disponibles para el programador, Application, ASPError, Request,
Response, Server y Session. Cada objeto corresponde a un grupo
de funcionalidades frecuentemente usadas y útiles para crear
páginas web dinámicas.


Las páginas pueden ser generadas mezclando código de scripts del
lado del servidor (incluyendo acceso a base de datos) con HTML y
código del lado del servidor


JSP (java Server Pages) es la tecnología para generar páginas
web de forma dinámica en el servidor, desarrollado por Sun
Microsystems, basado en scripts que utilizan una variante del
lenguaje java.

La tecnología JSP, o de JavaServer Pages, es una tecnología Java
que permite a los programadores generar dinámicamente HTML,
XML o algún otro tipo de página web. Esta tecnología permite al
código Java y a algunas acciones predefinidas ser embebidas en el
contenido estático. En las jsp, se escribe el texto que va a ser
devuelto en la salida (normalmente código HTML) incluyendo
código java dentro de él para poder modificar o generar contenido
dinámicamente. El código java se incluye dentro de las marcas de
etiqueta <% y %>.


En una posterior especificación, se incluyeron taglib; esto es, la
posibilidad de definir etiquetas nuevas que ejecuten código de
clases java. La asociación de las etiquetas con las clases java se
declaran en archivos de configuración en XML.


La principal ventaja de JSP frente a otros lenguajes es que permite
integrarse con clases Java (.class) lo que permite separar en
niveles las aplicaciones web, almacenando en clases java las
partes que consumen más recursos así como las que requieren
más seguridad, y dejando la parte encargada de formatear el
documento html en el archivo jsp.




                                                                  19 / 64
                                                             Memoria
                                                         del Proyecto

  Además Java se caracteriza por ser un lenguaje que puede
  ejecutarse en cualquier sistema, lo que sumado a jsp le da mucha
  versatilidad.


  Sin embargo JSP no se puede considerar un script al 100% ya que
  antes de ejecutarse el servidor web compila el script y genera un
  servlet, por lo tanto se puede decir que aunque este proceso sea
  transparente para el programador no deja de ser una aplicacion
  compilada. La ventaja de esto es algo más de rapidez y disponer
  del API de Java en su totalidad.


  Debido a esto la tecnología JSP, así como Java, está teniendo
  mucho peso en el desarrollo web profesional (sobre todo en
  intranets).



3.4.2. Conclusión.

   Debido a su amplia difusión, simplicidad, documentación y la
amplia difusión entre los profesionales del sector. Debido a que su
soporte esta muy extendido por parte de los servidores web, y debido
a que es el más utilizado para crear aplicaciones groupware,
escogeremos como tecnología de generación de aplicaciones web,
PHP.


3.5. ESTUDIO DE ALTERNATIVAS GROUPWARE.
   En esta sección estudiamos diferentes aplicaciones enmarcadas
dentro de la familia groupware con el objetivo de seleccionar aquella
que permita una convergencia más rápida hacia el objetivo
contratado con el cliente (ATICA). Tales alternativas se estudiarán
desde los diversos ángulos especificados en la introducción del
apartado Estudio y selección de alternativas.


3.5.1. Alternativa 1 : TUTOS.

Tutos: (The Ultimate Team Organization Software)

Versión 1.3 beta (4 septiembre de 2005)

   Tutos es una herramienta para administrar las necesidades de la
empresa en pequeños grupos, equipos o departamentos. Para ello
proporciona algunas herramientas basadas en web.



                                                                    20 / 64
                                                              Memoria
                                                          del Proyecto

Herramientas:
  Un calendario para grupos y usuarios.
  Un administrador de direcciones para personas, compañías y
  departamentos.
  Un repositorio de productos/proyectos con administrador de
  tareas, administrador de documentación y administrador de
  instalación.
  Un sistema de establecimiento de reuniones con reserva de
  materiales.
  Un registro avanzado y detallado de proyectos, material e
  incidencias.
  Un gestor de correo webmail, que soporta IMAP y POP3.
  Un sistema de alertas mediante correos acerca de proyectos e
  incidencias.
  Un sistema para coordinar equipos que están distribuidos en
  diferentes zonas horarias.
  Un sistema de temas y capas que permite cambiar la apariencia
  con facilidad.
  Un sistema de permisos a nivel de usuario y grupo.
  Un sistema de autenticación contra una base de datos propia, un
  servidor LDAP, o PAM (requiere de la adecuada configuración de
  Apache).



Otras características relevantes:
  Se encuentra traducido a varios idiomas, incluido el castellano.

   Es un proyecto en continuo desarrollo, se espera nuevas
funcionalidades y corrección de posibles errores que en la actualidad
la plataforma posee.

   Existe un proyecto paralelo para proporcionar nuevas extensiones
a esta plaforma. Este proyecto es administrado desde el sitio web:
http://www.tutosportal.com Las nuevas extensiones se alejan del
producto buscado, pues sirven para manejar procesos de venta de
productos, como promociones, marketing, análisis de competidores y
otros. Aún así pueden servir como muestra de la facilidad para poder
extender esta plataforma y adaptarla para cubrir nuevas necesidades
que puedan surgir.

Requisitos:
  1. Servidor HTTP: Apache.


                                                                     21 / 64
                                                              Memoria
                                                          del Proyecto

   2. Sistema gestor de bases de datos, cualquiera de los siguientes:
   PostgreSQL, MySQL, Oracle o Borland Interbase 5.
   3. Versión de PHP: 4.2.0 o 5.0


Instalación:
  La guía de la instalación es accesible mediante la siguiente página
web: http://www.tutos.org/homepage/install_easy.html

   Información        para      una      correcta       configuración:
http://wiki.tutos.org/index.php/Config.php

   En el archivo config.php se almacena la información acerca del tipo
de base de datos que se utilizará con la plataforma, la información
acerca del servidor LDAP contra el que se efectuará la autenticación y
otras variables importantes a tener en cuenta en el sistema.

Personalización:
   Para cambiar el logo que aparece en la página del login habrá que
modificar dos variables del archivo config.php: ($tutos[logo] y
$tutos[logolink]). Tras haber realizado el login, la información acerca
del logo se obtiene de la base de datos, para cambiar esto se ha de
entrar en la página de administración, seleccionar la base de datos,
seleccionar modificar y cambiar los enlaces.

   Para activar los recordatorios vía email es necesario planificar un
proceso que periódicamente acceda a la web http://[nombre-
servidor]/tutos/php/check.php (Más información en la página web:
http://www.tutos.org/homepage/install_faq.html ).

   Para cambiar el mensaje del día que aparece en la web de
autenticación    hay    que    modificar    el   archivo   [directorio-
tutos]/html/motd.html. En caso de que quiera desactivarse bastará
con renombrar dicho archivo. También se permite que la salida de un
programa sea el mensaje del día, para conseguir este objetivo es
necesario realizar un enlace simbólico a dicho archivo con el comando
“ln –fs [rutaAlEjecutable] [directorio-tutos]/html/motd.html]”, de las
distribuciones Linux y Unix.

   Para hacer uso de autenticación frente a LDAP, es necesario seguir
las instrucciones del archivo [directorio-tutos]/README.ldap En él se
explica cómo conseguir dicha funcionalidad.

   Conclusión: Esta plataforma ofrece a los usuarios una completa
serie de servicios. El problema es que es quizás demasiado
sobrecargada y compleja debido a esto mismo, y se hace difícil su



                                                                      22 / 64
                                                             Memoria
                                                         del Proyecto

estudio para poder adaptarla a las necesidades de un cliente, que no
necesita muchos de los servicios que ofrece.



3.5.2. Alternativa 2 : PHProjekt.

PHProjekt.

Versión 5.0.1 (29 septiembre de 2005)


Introducción.
   Esta puede ser una buena alternativa, ya que posee casi todas las
cualidades necesarias. Es sencilla, su volumen en comparación con
otras agendas corporativas es relativamente pequeño. Tiene pocas
herramientas pero esta característica debe ser vista en este caso
como una ventaja, ya que posee la práctica totalidad de las
características deseables. La escasez de elementos añadidos a los
deseados beneficia la navegabilidad y el aprendizaje. Está
implementada en PHP, tecnología web muy extendida, por lo que no
es difícil encontrar desarrolladores para modificar y extender su
código.

Interfaz gráfica.
   PHProjekt ofrece la posibilidad de establecer distintas pieles para
adecuar la estética de la agenda. Las pieles no tienen un gran poder a
la hora de introducir navegabilidad en la web, pero sí son útiles para
adaptar la estética. Se pueden crear nuevas pieles mediante la
creación de un nuevo directorio dentro del directorio /layout del
lenguaje fuente. La piel adoptará el nombre del directorio creado.
Este directorio debe contener una serie de ficheros de código php de
estructura bastante sencilla de cara a los desarrolladores. Además,
permite establecer el logo de la organización durante la instalación,
de modo que no es estrictamente necesario la manipulación del
código para personalizar esta parte.

Idioma.
   Un apunte importante respectivo a la interfaz gráfica es el idioma.
En PHProjekt se puede establecer el español como idioma. Sin
embargo, gran parte de la herramienta queda en inglés y además
existen obvias imprecisiones en la parte en español. Este hecho
supone una seria carencia.

Agenda y calendarios.



                                                                     23 / 64
                                                              Memoria
                                                          del Proyecto

    PHProjekt está muy centrado en el uso del calendario y los
eventos. Un usuario puede crear eventos de calendario. Cada evento
tiene una descripción, un horario, una serie de usuarios a los que son
convocados y algunas características más. Los usuarios convocados
pueden aceptar o rechazar los eventos. Además, los usuarios se
organizan en grupos, cualidad que ayuda a la gestión de usuarios,
convocatorias... Las convocatorias pueden o no enviarse a través de
correo electrónico. Esta es una cualidad necesaria. Aunque en la
documentación on-line de PHProjekt aparece un breve apartado
respectivo a la gestión de material (resources en la documentación),
que según esta permite la reserva del material y alarmas cuando no
está disponible, esta cualidad no está disponible al menos aún, en las
últimas versiones de manera directa.

   PHProjekt permite la visualización de los calendarios de otros
usuarios según determinadas políticas de privacidad, esta es otra
cualidad muy importante

   En cuanto a la facilidad de uso se puede calificar como media. A su
favor encontramos la escasez de elementos añadidos que introduzcan
complejidad a la hora de extraer la funcionalidad deseada, además
dispone de manuales de uso y documentación añadida on-line, pero
estos están bastante cojos en algunos puntos. En contra tiene la
pobre traducción al español, carencias a la hora de presentar una
interfaz intuitiva en algunos puntos (como ejemplo: la visualización
de los calendarios de otros usuarios), así como las citadas carencias
de documentación.

Autenticación.
   El nivel normal de autenticación es básico y se basa en la base de
datos. Sin embargo, PHProjekt presenta la posibilidad de
autenticación mediante LDAP. La implementación de esta
característica reside en los siguientes ficheros [directorio-
PHProjekt]/lib/ldap.php,      [directorio-PHProjekt]/lib/ldap_auth.php,
[directorio-PHProjekt]/lib/ldap_config.php, siendo éste último de gran
importancia pues contiene los parámetros de acceso al servidor LDAP.
En cuanto al uso de Kerberos, PHProjekt no posee mecanismo alguno
para el uso de éste, y para su implantación se hace necesaria la
implementación de módulos específicos y una más que probable
revisión de otros muchos.

Adaptabilidad al sistema actual.
   PHPProjekt necesita de un servidor web con PHP 4 para su
instalación. El sistema gestor de base de datos puede ser uno
cualquiera de entre una amplia gama soportada (MySQL, PostgreSQL,
Oracle, Informix y MSSQL). Es muy importante remarcar que soporta


                                                                      24 / 64
                                                             Memoria
                                                         del Proyecto

de manera directa bases de datos Oracle. Además, la adaptación a
cualquier otro sistema gestor no soportado se hace relativamente
sencilla al estar el acceso a datos concentrado en un solo módulo. Los
módulos controladores del acceso a datos se encuentran en
[directorio-PHProjekt]/lib/db/ y cada sistema gestor precisa el uso de
uno de ellos.

Características adicionales.
   Una característica interesante que ofrece PHProjekt es la oferta de
algunas herramientas de acceso a la agenda corporativa mediante
otros dispositivos o programas (como MS Outlook). El número
ofertado a fecha de hoy no es sin embargo muy elevado presentando
unos pocos para MS Outlook.

Conclusiones.
   En conclusión esta herramienta es una alternativa válida aunque
presenta carencias importantes en navegabilidad, estética y
herramientas de gestión de eventos, recursos y privilegios.


3.5.3 Alternativa 3 : Group-Office.

Group-Office

Versión 2.1.14

   Group-Office es una suite groupware compuesta por un sistema
base y diferentes módulos. Los módulos están diseñados de tal
manera que distintos grupos de personas puedan colaborar en línea.
Agendas compartidas, libros de direcciones, proyectos, archivos y
correo electrónico son las características claves del proyecto. Los
usuarios pueden utilizar su navegador web favorito para acceder a su
plataforma groupware.

   Group-Office está disponible en dos tipos de versiones: la versión
Professional y la versión Community. La primera de ellas es de pago
a cambio de una versión con mayor número de características y
servicio de soporte oficial. También es posible adquirir la versión
Professional sin soporte, por un precio de 199€, por instalación en el
servidor (sín límite de usuarios). La versión Community se distribuye
bajo licencia GNU. Se espera que en febrero de 2006 esté disponible
la versión estable 2.15 de la plataforma.




                                                                     25 / 64
                                                               Memoria
                                                           del Proyecto

Características más relevantes:
   Agenda (Calendario), en la que almacenar información acerca de
reuniones y eventos de los usuarios. Dicha información sirve para
poder establecer reuniones entre grupos de usuarios. El sistema
permite conocer si otro usuario con el que se espera reunirse tiene ya
un evento programado para esa hora, y poder así adecuarlo al
horario de todos los usuarios. Un defecto a tener en cuenta respecto
a los requisitos de la plataforma deseada es que no alerta por email
de nuevos eventos organizados, simplemente los muestra en su
correspondiente agenda. Tampoco contiene un sistema para gestión
de materiales en las reuniones.

   Libreta de direcciones: base de datos en la que se almacena
información acerca de los contactos de un usuario, dicha información
es relativa a la dirección de correo electrónico, número de teléfono de
contacto, dirección, compañía para la que trabaja y demás datos
personales.

   Sistema de gestión de proyectos: Sirve para llevar un control
acerca del estado de los proyectos del trabajo e información útil
relativa a los mismos.

   Sistema de webmail: con el que se permite el envío y recepción
de emails mediante un navegador conectado a la aplicación. Soporta
IMAP y POP3.

   Sistema de notas en el que guardar constancia de elementos de
interés para los usuarios.

   Sistema de almacenamiento de archivos en el servidor, para su
posterior compartición con otros usuarios o envío por correo
electrónico.

   Permite sincronización con agendas PDA y con el programa
ofimático MS Outlook.

   Traducción al español muy deficiente.

   Soporte aún en desarrollo de autenticación mediante LDAP (más
información en el archivo [directorio-groupoffice]/README.ldap.

   Personalización de la estética de la aplicación mediante el uso de
temas, en la actualidad la versión que se descarga cuenta con seis
temas distintos.

   Sistemas gestores    de   bases   de    datos   soportados:   MySQL,
PostgreSQL y Oracle.


                                                                      26 / 64
                                                              Memoria
                                                          del Proyecto

   Estructura del sistema muy modular, lo que permite un alto nivel
de extensibilidad.


3.4.4. Alternativa 4 : eGroupWare

eGroupWare

(Versión 1.2 RC.6 22 de enero de 2006)

   eGroupWare es una suite groupware multiusuario basada en web,
desarrollada con un conjunto de APIs basadas en PHP. Los módulos
disponibles en la actualidad incluyen: correo electrónico, libreta de
direcciones, calendario, panel de información (notas, llamadas
telefónicas), administrador de contenidos, foro, favoritos y wiki.


Características más relevantes:
   Administración de eventos y citas del calendario. Permite
convocar citas entre distintos usuarios y acceder a información acerca
de la disponibilidad de los mismos. Como característica remarcable
está la de la notificación por email de estos nuevos eventos, uno de
los requisitos deseados por los clientes de la plataforma.

   Gestión de recursos en reuniones. En efecto, la plataforma
proporciona un mecanismo para llevar un control del uso de los
recursos necesarios para las reuniones, como salas, proyectores,
ordenadores y otros dispositivos e instalaciones.

   Gestión de privilegios. Sirve para poder gestionar qué usuarios
tienen la capacidad de acceder, modificar o eliminar la información
almacenada en el sistema.

   Gestión de usuarios/grupos. La plataforma tiene un sistema
que permite agrupar usuarios dentro de entidades llamadas grupos,
para facilitar la comunicación de los mismos. Se puede asignar ciertos
privilegios a nivel de grupo y cualquier usuario que pertenezca al
grupo disfrutará de esos privilegios.

   Gestión de archivos compartidos. La compartición de
información es la finalidad de este tipo de plataformas, y los archivos
son una forma más de información. La plataforma permite almacenar
archivos en un sistema de archivos virtual, desde el cual los usuarios
podrán subir archivos al servidor, renombrarlos, copiarlos, moverlos,
eliminarlos, crear y editar archivos de texto, y compartirlos
selectivamente al resto de usuarios. La herramienta también posee



                                                                      27 / 64
                                                              Memoria
                                                          del Proyecto

un sistema de log, en el que se guarda quien realizó cambios sobre
los ficheros.

    Traducido al castellano. La plataforma se encuentra traducida al
castellano, lo que resulta importante en una comparativa con otras
plataformas del mismo tipo. De hecho el castellano es el segundo
idioma al que más traducido está.

   Soporta un sistema de autenticación basado en LDAP. Uno de los
requisitos solicitados por el cliente es el de poder autenticar
obteniendo información del servidor LDAP del que ya disponen.

   Sistema de acceso a sistema gestor de bases de datos
transparente. Debido a que la plataforma usa una capa de
persistencia abstracta llamada “ADOdb Library for PHP”, se permite
almacenar las tablas en un sistema gestor de bases de datos
ORACLE, que era otro de los requisitos dados por el cliente.

   Sistema gráfico basado en skins. Permite a cada usuario
especificar el skin que más se adapte a los gustos de cada usuario.



3.5. Conclusiones groupware.
   Varias son las alternativas con suficientes puntos a favor como
para utilizarlas como punto de partida para generar la aplicación del
proyecto Agenda Corporativa. Sin embargo, existe una de ellas, que
por su potencia y adecuación constituye sin duda, la opción más
destacada. Se trata de eGroupWare. Esta alternativa tiene casi la
totalidad de la funcionalidad requerida por el cliente y la adaptación
se centrará en la adecuación de la estética a la imagen corporativa de
la Universidad de Murcia, aunque presenta otros pocos puntos en los
que se requerirá alguna adaptación.




                                                                     28 / 64
                                                                  Memoria
                                                              del Proyecto

4. Viabilidad del proyecto.
4.1. Viabilidad técnica.
   La plataforma que ATICA ha encargado a RevolutioNet se enmarca
en el dominio de las aplicaciones de tipo groupware. Esta delimitación
tan precisa, representa para RevolutioNet un marco de trabajo bien
definido    que    además     está    ampliamente       documentado       y
ejemplarizado. Hay disponibles una importante cantidad de
plataformas que se engloban dentro de este grupo, de entre las
cuales se dispone además de numerosas opciones de carácter libre,
que suponen un punto de partida fácil, así como una documentación
excelente. La tecnología utilizada para el desarrollo de este tipo de
aplicaciones, y que RevolutioNet ha asumido como la correcta es la
tecnología de las aplicaciones web. Esta tecnología dispone de una
amplia aceptación, existe multitud de personal formado en el área y
constituye una de las materias sobre las que más se ha estudiado en
el campo de la ingeniería del software. Todo ello contribuye a que la
realización del proyecto sea desde el punto de vista tecnológico
calificada con trivialmente viable. No obstante, existen numerosos
puntos a discutir a la hora de realizar un juicio final sobre la viabilidad
técnica del proyecto. RevolutioNet ha estudiado estos puntos para
determinar en que grado es viable el proyecto. Relatamos a
continuación los puntos de discusión sobre los que ha versado la
reflexión de esta empresa.

    Soporte para datos sobre gestores de bases de datos
Oracle. El cliente, ATICA, pide como requisito deseable (no
obligatorio), la posibilidad de utilizar como soporte para datos un
servidor Oracle. El estudio de RevolutioNet se ha centrado en la
búsqueda de drivers que permitiesen el acceso a Oracle utilizando
como lenguaje de programación PHP. Efectivamente, y como hacía
presagiar la importancia de ambas, PHP y Oracle, existen diversas
opciones para acceso a datos que permiten la utilización de sistemas
gestores de base de datos Oracle desde PHP. Por fin, encontramos
además, opciones de software libre, como eGroupWare, que soportan
tal alternativa para datos.

    Autenticación LDAP. RevolutioNet ha concluido que la
autenticación basada en LDAP es absolutamente factible. De hecho,
PHP proporciona un conjunto de funcionalidades especialmente
dirigidas a tal efecto. Por otra parte, y dado que este requisito es
muy demandado por parte del tipo de clientes que nos ocupa,
muchas de las opciones de software libre disponibles contienen este
servicio.




                                                                          29 / 64
                                                               Memoria
                                                           del Proyecto

   Adaptabilidad estética de la plataforma tomada como punto
de partida. Aunque existía cierto grado de incertidumbre respecto a
este punto, se ha encontrado que la amplia mayoría de las
aplicaciones de esta familia otorgan cierta facilidad para adaptar esta
característica mediante el uso de pieles. Sin embargo, la alternativa
tomada como punto de partida provee de un mecanismo de pieles
notablemente más complejo que otras muchas, pero a la vez más
potente.

   Soporte para kerberos. Este ha sido el punto más peligroso de
cara a la viabilidad. El uso de kerberos se presenta poco viable. Sin
embargo, RevolutioNet presenta una opción viable para el uso del
mismo mediante la implantación del uso de kerberos no a nivel de la
aplicación Agenda Corporativa, sino a nivel del servidor Web.


4.2. Viabilidad legal.
   En cuanto a la viabilidad legal de nuestro proyecto, debemos
atenernos al cumplimiento de las leyes de acuerdo a la legislación
española vigente, y que tienen relación con aspectos referentes al
proyecto desarrollado, como la privacidad de los datos, seguridad,
etc. Concretamente, el proyecto cumplirá con las siguientes leyes:


4.2.1. LORTAD:
    La LORTAD es una ley orgánica (5/1992), es decir, un mandato
constitucional que limita el uso de la informática con la intención de
proteger y garantizar el honor, la intimidad personal y familiar de los
ciudadanos y el legítimo ejercicio de sus derechos. En nuestro caso
afecta directamente a las bases de datos, realizando una distinción de
responsabilidades. Es obligación nuestra dar un tratamiento
confidencial a los datos de nuestros clientes, así como garantizar que
estos no serán expuestos a terceras personas ajenas a la empresa.
Como única excepción, los datos podrán ser expuestos a terceras
personas siempre con el consentimiento de nuestro cliente y en
presencia del mismo. Asimismo, el uso de dichos se llevará a cabo
única y exclusivamente dentro del entorno de trabajo del sistema, de
acuerdo al modelo de negocio, teniendo en cuenta la ley y facilitando
al cliente su derecho de acceso, rectificación, cancelación y oposición.


4.2.2. Ley Orgánica de Protección de Datos:
    La presente Ley Orgánica tiene por objeto garantizar y proteger,
en lo que concierne al tratamiento de los datos personales, las
libertades públicas y los derechos fundamentales de las personas
físicas, y especialmente de su honor e intimidad personal y familiar.
La Ley será de aplicación a los datos de carácter personal registrados


                                                                       30 / 64
                                                              Memoria
                                                          del Proyecto

en soporte físico que los haga susceptibles de tratamiento, y a toda
modalidad de uso posterior de estos datos por los sectores público y
privado. De dicha Ley se debe entender por:

  Datos de carácter personal: Cualquier información concerniente a
  personas físicas identificadas o identificables.

  Tratamiento de datos: Operaciones y procedimientos técnicos de
  carácter automatizado o no, que permitan la recogida, grabación,
  conservación, elaboración, modificación, bloqueo y cancelación, así
  como las cesiones de datos que resulten de comunicaciones,
  consultas, interconexiones y transferencias.

4.2.3. Ley de ordenación de las Comunicaciones:
    La Ley sienta las bases para el futuro de las telecomunicaciones,
regulándolas, de acuerdo a su importancia dentro del desarrollo
tecnológico y económico del país. De acuerdo a estos objetivos,
legisla sobre las características obligatorias para la prestación de
servicios de telecomunicación en un marco abierto a la libre
concurrencia y a la incorporación de nuevos servicios. Como principio
general, la Ley clasifica las telecomunicaciones como servicios
esenciales de titularidad estatal reservados al sector público,
definiendo el dominio público radioeléctrico y ordenando su
utilización, estableciendo, al mismo tiempo, la exclusión de
determinados servicios de dicho régimen. Asimismo, también clasifica
los servicios de telecomunicación en diversos grupos, destinando a
cada uno de ellos artículos específicos, al efecto de diferenciar el
servicio que recibe el usuario en cada caso y el tratamiento legal que
se da a unos y otros. La Ley introduce en la prestación de los
servicios el régimen de libre adquisición de los terminales por el
usuario siempre que los equipos terminales que se conecten a los
puntos correspondientes hayan obtenido los certificados de
homologación y de cumplimiento de las especificaciones técnicas
oportunas. La novedad más destacable de esta Ley es la regulación
de los servicios de valor añadido, que están encaminados a satisfacer
las    nuevas     necesidades      específicas  de    telecomunicación,
singularmente conectando con los sistemas de tratamiento de la
información, lo que facilitará la expansión de este nuevo mercado.


4.2.4. Ley de Seguridad en Servicios Informáticos:
    La finalidad de esta Ley es consolidar el uso de las técnicas
telemáticas en el desarrollo de actividades profesionales y
empresariales, así como dotar a estas actividades de las necesarias
garantías frente a los consumidores de los servicios de la sociedad de
la información. El objeto de estas normas es regular cualquier tipo de


                                                                      31 / 64
                                                             Memoria
                                                         del Proyecto

actividad que se realice a través de la Red. El concepto material en
torno al que gira su ámbito de aplicación se denomina “servicios de la
sociedad de la información”. Todo el que preste un “servicio de la
sociedad de la información” se convierte automáticamente en
prestador de servicios de la sociedad de la información y,
consecuentemente, cae dentro del ámbito de aplicación de la Ley.


4.3. Viabilidad operativa.
    Uno de los puntos a los que se ha prestado mayor atención ha sido
la facilidad de uso de que debe constar el sistema. Puesto que va a
convertirse en un elemento clave de la empresa cliente, pues será
utilizado para concertar reuniones y administrar recursos
continuamente, tenemos la necesidad por un lado y la obligación por
otro de que el sistema pueda ser utilizado empleando todo su
potencial por parte de cualquier empleado con los mínimos
conocimientos informáticos.

   Al tratarse de una aplicación web, puede ser ejecutada bajo un
sistema operativo Windows, ampliamente extendido y conocido por la
mayoría de los usuarios, aunque también será posible su ejecución en
Linux. Así mismo, es posible su uso desde múltiples navegadores de
Internet, como Internet Explorer, Mozilla, Netscape...

   Por la misma razón se presenta un conjunto de vistas de cara al
usuario donde los contenidos se muestran de modo amigable,
sencillo, intuitivo y accesible.

   No obstante, para la correcta asimilación de los procedimientos de
uso del sistema, se impartirá un seminario con el que los usuarios
podrán familiarizarse con el sistema completamente. Éste tendrá
lugar probablemente cuando la fase de desarrollo haya concluido y
además el sistema haya sido instalado. Es posible además hacer uso
del manual de usuario que se provee y que va integrado en el propio
sistema como un módulo más.

   Por otra parte, el sistema se acompaña de un período de garantía
y una fase de mantenimiento y soporte técnico de la que la empresa
se puede beneficiar ampliamente.

4.4. Viabilidad presupuestaria.
    El desarrollo de la agenda corporativa y su implantación no
contempla un gran gasto económico ni por parte de la empresa
desarrolladora RevolutioNet, ni por parte del cliente que hará uso de
ella. El cliente no necesitará un gran esfuerzo económico para poder
implantar la agenda en su sistema y a cambio obtendrá beneficios
con esta aplicación que hacen que su compra sea rentable. En cuanto


                                                                     32 / 64
                                                                Memoria
                                                            del Proyecto

a gastos necesarios por parte del cliente, no tendrá que hacer
desembolso en equipos, pues Ática ya dispone más que de sobra de
los equipos necesarios Por tanto lo normal es que el gasto de
implantar la aplicación sea nulo, sin contemplar, claro está el
desembolso del coste de la aplicación.

      En cuanto a la empresa desarrolladora de la agenda,
RevolutioNet, no necesita ningún coste económico para desarrollar la
aplicación, ya que el software utilizado es de libre distribución y las
mejoras sobre él se realizan en equipos de los que ya se disponía con
antelación a este proyecto.


4.5. Viabilidad financiera.
   Dado que la empresa desarrolladora no tiene ningún gasto en el
desarrollo de la aplicación, no debemos preocuparnos demasiado por
que la empresa se quede sin dinero efectivo durante el desarrollo de
la agenda.

   No obstante, y para mantener la seguridad de que el cliente que
ha solicitado el desarrollo de la aplicación nos va a abonar la cantidad
estimada en el presupuesto, se realizará un pago previo antes del
comienzo del desarrollo. Este pago previo será el 30 % del coste total
de la aplicación. Una vez finalizada la aplicación, en la misma semana
de la entrega se exigirá que el cliente pague el 50 % del coste total
de la aplicación. El 20 % restante del coste, se dejará que el cliente lo
pague en los dos primeros meses desde la entrega de la aplicación.
De esta manera conseguimos dos objetivos, por un lado que el cliente
tenga mayor facilidad de pago en cuanto al desembolso de la
cantidad a pagar, y por otro lado, que el cliente se sienta seguro al
comprar la aplicación porque no ha abonado el coste total, y en caso
de que no funcione correctamente, no abonará el total del coste hasta
que la aplicación no sea totalmente correcta.




                                                                        33 / 64
                                                                Memoria
                                                            del Proyecto


5. Estudio técnico.
5.1. Introducción.
   Para documentar el proceso de análisis de la arquitectura
seleccionada, llevaremos a cabo una descripción cronológica del
mismo. El proyecto Agenda Corporativa parte, por contrato con
ATICA, de una opción de software libre para adaptarla para incluir
todas aquellas características deseables que no posea inicialmente,
así como para personalizar otras facetas y funcionalidades. Este
hecho, implica una importante labor de ingeniería inversa a partir de
la alternativa groupware seleccionada. Se comenzará con proceso de
ingeniería inversa que constará de una análisis de características
técnicas ya disponibles, así como una detección de aquellas no
disponibles o que deban ser modificadas. Se realizará una
documentación de las características existentes citadas mediante
casos de uso. A continuación ser realizará un estudio de la estructura
interna de la alternativa groupware seleccionada (eGroupWare) con el
objetivo de preparar el análisis de las funcionalidades a modificar o
añadir. Tras lo cual se realizará, por ingeniería directa, un análisis de
las características a incluir en software.

5.2. Estado Actual de la plataforma.
  Esta sección documenta el proceso de análisis de software
mediante ingeniería inversa, del sistema a modificar.

5.2.1. Introducción:

   Esta plataforma surgió como una nueva plataforma basada en
phpGroupWare. Los fundadores de la nueva plataforma se desligaron
de la anterior porque los líderes del anterior proyecto llevaban mucho
tiempo inactivos y ralentizaban el desarrollo del mismo. La
plataforma se encuentra bajo licencias GPL/LGPL. Información más
detallada acerca de las implicaciones de esas licencias se puede
obtener en: http://www.gnu.org/licenses/licenses.es.html

   La suite de aplicaciones eGroupWare está construida sobre un
conjunto flexible de APIs referidas como phpwapi. eGroupWare es
una de las agendas corporativas más extendidas. Su éxito radica en
su enorme cantidad de características soportadas por el mismo, así
como en su continuo desarrollo.


5.2.2. Requisitos para su implantación:

http://www.egroupware.org/requirements



                                                                        34 / 64
                                                             Memoria
                                                         del Proyecto

  Requisitos para su funcionamiento:
    Al estar implementado en PHP eGroupWare puede ser implantado
en cualquier sistema operativo siempre y cuando disponga de un
servidor web con un módulo para interpretar PHP. El servidor web a
utilizar dependerá del sistema operativo sobre el que se ejecute, pero
están soportados: IIS, Apache 1.3x, 2.x y Roxen. El sistema gestor
de bases de datos a utilizar junto con el conjunto de aplicaciones
puede variar, están soportados los sistemas gestores más utilizados
en la actualidad: MySQL, PostgreSQL, Oracle y MSSQL.

  Requisitos a nivel de red:
   eGroupWare necesita que los puertos 80 (HTTP), 443 (HTTPS), y
22 (SSH) estén abiertos, En el caso de que se planee utilizar el
servidor eGroupWare como servidor de correo electrónico también
deberán estar abiertos los puertos 25 (SMTP), 465 (SMTPS), 110
(POP3), 993 (IMAPS), 143 (IMAP), y 995 (POP3 sobre SSL).



5.2.3. Estudio avanzado de sus características:

  Sistema gestor de bases de datos:
   La información acerca de los datos que los usuarios almacenan en
el sistema, como sus contactos, sus reuniones, proyectos,
preferencias y demás información necesita ser almacenada en una
base de datos. La plataforma eGroupWare fue diseñada con
independencia a cuál fuera la elección del sistema gestor destino.
Esta independencia del gestor de la base de datos se consigue a
través de: “ADOdb Library for PHP”. Esta librería proporciona al
programador una capa de abstracción sobre el sistema de
persistencia utilizado. Es ampliamente utilizada y es un proceso muy
activo de desarrollo desde el inicio de su desarrollo en agosto de
2000. Tiene licencia BSD y GPL. La documentación de esta librería
también se encuentra ampliamente traducida al castellano
(http://www.lacorona.com.mx/fortiz/adodb/docs-adodb-es.htm).
Información más detallada acerca de esta librería puede encontrarse
en http://adodb.sourceforge.net/


  Interfaz Gráfica:
   eGroupWare proporciona con mucho la interfaz de usuario más
funcional y la más agradable estéticamente de las alternativas
estudiadas. Proporciona varios skins, entre ellos la nueva versión
proporciona un nuevo y revolucionario skin, que proporciona a la
plataforma de un aspecto de escritorio virtual sobre la web. Respecto


                                                                     35 / 64
                                                             Memoria
                                                         del Proyecto

al nivel de adaptación al aspecto corporativo de la empresa que debe
tener la plataforma, se puede cambiar la configuración de la misma
para que utilice el logotipo de la empresa en las páginas web que
muestre a los usuarios.



5.2.4. Aplicaciones que proporciona:

  eGWOSync (versión 0.3 22 de enero de 2006) : Herramienta de
  sincronización con el programa ofimático MS Outlook y (a través
  del mismo) con agendas electrónicas o PDAs. En la actualidad tan
  sólo sincroniza calendario y contactos. Está diseñado como un
  programa aparte, no integrado en MS Outlook. Para su correcto
  funcionamiento requiere una versión de MS Outlook superior a la
  2000, y del entorno de ejecución Microsoft .NET 1.1 Framework.

  SiteMgr: Esta aplicación genera un sitio web dinámico con varias
  secciones que algunos usuarios de eGroupWare pueden editar si el
  administrador le da permiso para ello. En efecto, el sitio web
  generado puede tener secciones a las que departamentos
  independientes      tienen    asignado     su   mantenimiento.    El
  administrador del sitio puede elegir un tema y crear cabeceras,
  partes inferiores de la web, y barras de desplazamiento comunes
  para forzar la misma apariencia de todo el sitio web. Las secciones
  del sitio web pueden ser vistas por el público en general o privadas
  (sólo visibles por específicos usuarios y grupos).

  Jinn: Jinn para eGroupWare es una base de datos entre distintos
  sitios web y está diseñada para multiusuarios. Esta base de datos
  está diseñada para ser parte de la plataforma eGroupWare.
  Permite tener múltiples bases de datos moderadas por distintas
  personas en un único sistema. Los privilegios de acceso son
  asignados a nivel de tabla y cada sitio web puede tener uno o más
  administradores del mismo.

  eTemplate: eTemplate es un componente y una aplicación a
  modo de asistente que sirve para diseñar nuevas aplicaciones para
  utilizar con eGroupWare.




                                                                     36 / 64
                                                               Memoria
                                                           del Proyecto

5.3. Análisis de requisitos del software.
   Esta sección contiene los casos de uso que suponen los requisitos
del documento de requisitos funcionales del proyecto Agenda
Corporativa más importantes e interesantes desde el punto de vista
del cliente en su fase de análisis (mediante ingeniería inversa) del
sistema actual.

   Los casos de uso presentados en esta sección se corresponden con
los obtenidos del estudio mediante ingeniería inversa de la agenda
corporativa eGroupWare. Estos casos de uso deben servir como base
de estudio de adaptabilidad para que se cumplan los requisitos
especificados con el cliente.


5.3.1. Caso de uso : Autenticación LDAP.
Actor principal: Usuario.
Actores involucrados:

  Usuario: quiere acceder al sistema, para llevar a cabo las tareas
  que crea oportunas. Lo hace a través de un navegador, por lo que
  este actor hace referencia al navegador con el cual interactúa el
  sistema, y detrás del cual está la persona usuario.
  Servidor LDAP: concede información personal de PAS y PDI, su
  acceso requiere identificación.
  Administrado: gestiona la configuración del sistema, y recibe
  notificaciones en caso de existir problemas de cualquier índole.

Escenario principal de éxito.
    1. El usuario se conecta al sistema a través de un navegador,
       tecleando la dirección del sistema en Internet.
    2. El sistema presenta una sugerencia para que el usuario
       introduzca login y contraseña.
    3. El usuario introduce login y contraseña
    4. El sistema se conecta al Servidor LDAP presentando el login
       y contraseña de la aplicación (no los del usuario).
    5. El Servidor LDAP informa al sistema de la corrección de los
       datos de identificación.
    6. El sistema pide al Servidor LDAP información sobre el
       usuario, aportando el login del mismo.
    7. El Servidor   LDAP    devuelve   la   información   relativa   al
       usuario.
    8. El sistema intenta conectarse con el UID obtenido de la


                                                                      37 / 64
                                                                  Memoria
                                                              del Proyecto

      información devuelta por el Servidor LDAP y la contraseña
      introducida por el usuario.
    9. El Servidor LDAP informa de la corrección de los datos de
       autenticación y queda conectado.
    10.    El sistema informa al usuario de la autenticación positiva
      y da acceso presentando la página principal del sistema.

Extensiones (Flujos Alternativos)
 *a. En el punto 5 el Servidor LDAP devuelve una respuesta
     indicando que los argumentos de conexión del sistema no son
     válidos.
  6. El sistema informa al usuario de la imposibilidad de acceso al
     sistema por causas ajenas al propio usuario e impide el acceso.
  7. El sistema envía una notificación vía mail al Administrador.
 *b. En el punto 8 el Servidor LDAP deniega la conexión por
     considerar erróneos los datos de identificación.
  9. El sistema informa al usuario de la imposibilidad de acceso al
     sistema porque la información aportada no es correcta, y da la
     oportunidad de volver a intentarlo.



5.3.2. Caso de uso : Convocar una reunión.
Actor principal: Usuario.
Actores involucrados:

  Usuario: quiere introducir un evento en el calendario, esto es
  convocar una reunión convocando a otros usuarios y reservando
  determinados materiales.

Escenario principal de éxito.
   1. El sistema muestra al usuario una página en la que ofrece las
     distintas posibilidades de operaciones a realizar
   2. El usuario elige la opción de gestión del calendario.
   3. El sistema muestra al usuario una página sobre las distintas
     opciones y operaciones sobre el calendario
   4. El usuario indica (mediante un clic) que desea convocar una
     reunión.
   5. El sistema muestra una página para introducir los datos de la
     reunión.
   6. El usuario introduce la fecha de inicio, la fecha de fin, el
     nombre de la reunión, los usuarios convocados de forma



                                                                     38 / 64
                                                                Memoria
                                                            del Proyecto

     individual o por grupos, si desea avisar vía correo electrónico, y
     los materiales a reservar. Todo mediante asistentes que
     monitorizan y facilitan la introducción de datos.
   7. El sistema registra la reunión y la hace visible a los usuarios.
   8. El sistema envía notificaciones a los convocados.
   9. El sistema muestra al usuario la sección de gestión de
     calendario.

Extensiones (Flujos Alternativos)
    *a. Antes de 7, antes de registrar la reunión, el sistema detecta
    incompatibilidades de horarios de reuniones para alguno de los
    convocados y/o. detecta indisponibilidad de materiales.
    8. El sistema da a elegir al usuario entre seguir con la
    convocatoria o bien abortar la operación
    9. El usuario introduce su elección.
    *a.1. En el punto 9 de *a se selecciona abortar
    10. El sistema muestra la sección de creación de reunión con los
    datos actuales por si el usuario desea modificarlos para corregir.
    *a.2. En el punto 9 de *a se selecciona seguir
    10. El sistema va al paso 7 de a



5.3.3. Caso de uso : Observar Calendario.
Actor principal: Usuario.
Actores involucrados:

  Usuario: Quiere ver los eventos planificados durante cierto
  periodo, así como las tareas a las que se le convoca y que aún no
  han sido confirmadas.

Escenario principal de éxito.
    1. El sistema muestra al usuario una página en la que ofrece
       las distintas posibilidades de operaciones a realizar
    2. El usuario elige la opción de gestión del calendario.
    3. El sistema muestra al usuario una página de vista del
       calendario y selección de las distintas opciones del calendario,
       como son vista de un día, vista semanal y mensual. El sistema
       elige por defecto el último modo de vista utilizado por el
       usuario. La página de calendario muestra información de
       resumen de cada reunión como son nombre, y estado de
       aceptación de tal reunión (aceptada, rechazada, por


                                                                         39 / 64
                                                                Memoria
                                                            del Proyecto

      confirmar).
    4. El usuario especifica en su caso el modo de vista.
    5. El sistema adecua su modo de visión a lo especificado por el
       usuario, y lo pone en el día, semana o mes actuales. También
       ofrece al usuario operaciones para establecer el calendario en
       cierta fecha que interese.
    6. El usuario selecciona la fecha que desea ver
    7. El sistema muestra la planificación según vista y fecha
       seleccionadas.

Extensiones (Flujos Alternativos)
    *a. Entre los pasos 3 a 7, el usuario elige selecciona una
    reunión.

    [3-7]+1. El usuario selecciona una reunión para ver detalles.

    [3-7]+2. El sistema muestra los detalles de la reunión.
    Descripción, título, convocador, estado de cada uno de los
    usuarios asistentes para dicha convocatoria, fechas y horas de
    inicio y fin y estado de aceptación del propio usuario.
           [3-7]+2.1 Si el estado propio es "por confirmar", el
           sistema provee además de un aviso para que el usuario
           vea que debe confirmar el evento.
    [3-7]+3.
           [3-7]+3.1. El usuario introduce nuevo estado respecto a
           la reunión. y el sistema registra tal estado.
           [3-7]+3.2. El usuario va al paso [3-7]+4.

    [3-7]+4. El usuario cierra la sección de detalles.
    [3-7]+5. El sistema vuelve a la sección [3-7] previa a la
    selección de detalles.



5.3.4. Caso de uso Añadir un nuevo contacto.
Actor principal: Usuario.
Actores involucrados:

  Usuario: Quiere añadir la información acerca de un nuevo
  contacto a su libreta de direcciones (contactos).

Escenario principal de éxito.




                                                                    40 / 64
                                                               Memoria
                                                           del Proyecto

   1. El sistema muestra al usuario una página en la que ofrece las
      distintas posibilidades de operaciones a realizar
   2. El usuario elige la opción de gestión de la libreta de
      direcciones.
   3. El sistema muestra al usuario una página con información
      acerca de los contactos del usuario (Nombre completo, Primer
      nombre, Apellido, Prefijo, Nombre de la empresa, Ciudad de
      trabajo, Teléfono de trabajo, Teléfono de voz, Teléfono de fax,
      Teléfono móvil) y un menú para poder añadir nuevos contactos,
      buscar un contacto mediante una búsqueda alfabética,
      visualizar los detalles de un contacto existente, editar sus datos
      o eliminar un contacto.
   4. El usuario elige la opción de Añadir un nuevo contacto.
   5. El sistema le muestra una ventana con los campos que puede
      almacenar sobre un contacto.
   6. El usuario introduce los campos relativos al contacto que desea
      almacenar y pide al sistema que los almacene.
   8. El sistema añade el nuevo contacto a la lista de contactos y
      vuelve a mostrar la lista inicial de contactos.

Extensiones (Flujos Alternativos)

     Este caso de uso carece de flujo alternativo.


5.3.5. Caso de uso Añadir un nuevo recurso.
Actor principal: Usuario.
Actores involucrados:

  Usuario: quiere añadir la información acerca de un nuevo recurso
  disponible para su reserva en reuniones con otros usuarios del
  sistema.

Escenario principal de éxito.

   1. El sistema muestra al usuario una página en la que ofrece las
      distintas posibilidades de operaciones a realizar
   2. El usuario elige la opción de gestión de recursos.
   3. El sistema muestra al usuario una página con información
      acerca de los recursos de los que almacena información
      (Imagen representativa, Nombre y breve descripción, número
      de elementos de ese tipo disponibles, Categoría y Ubicación) y
      un menú para poder añadir nuevos recursos, buscar un recurso,


                                                                       41 / 64
                                                             Memoria
                                                         del Proyecto

     visualizar los detalles de un recurso existente, editar sus datos
     o eliminar un recurso.
   4. El usuario elige la opción de Añadir un nuevo recurso.
   5. El sistema le muestra una ventana con los campos que puede
      almacenar sobre un recurso.
   6. El usuario introduce los campos relativos al recurso que desea
      almacenar y pide al sistema que los almacene.
   7. El sistema añade el nuevo recurso a la lista de recursos y
      vuelve a mostrar la lista inicial de recursos.

Extensiones (Flujos Alternativos)

     Este caso de uso carece de flujo alternativo.



5.4. Adaptación a los requisitos del cliente:
   eGroupWare proporciona la casi totalidad de los requisitos
especificados por el cliente. Las adaptaciones que se realizarán serán
a nivel de interfaz gráfica sobre todo. Un requisito que no se ha
implementado por su nula viabilidad es la implantación de kerberos.
Para suplir tal contratiempo, RevolutioNet aporta una solución
equivalente situando kerberos al nivel del servidor web.


5.4.1. Adaptar la Interfaz Gráfica a la identidad de la
empresa:
    El problema que posee esta plataforma para poder generar nuevos
skins es que requiere de información acerca del mismo en cada uno
de los módulos que interaccionan con el usuario en los que se divide.
No obstante, una forma de conseguir una personalización aceptable
sería la de modificar los colores o imágenes de algún skin ya
existente. Para ello habría que acceder al archivo CSS (Cascading
Style Sheets) correspondiente y modificar las referencias a los
archivos de imágenes. Este proceso es relativamente sencillo, y
aunque no es excesivamente potente, podría servir en muchos casos
para implementar un skin con la identidad de la empresa cliente
aceptable. Este será el método que emplearemos, pues basta con ello
para cumplir ampliamente los requerimientos del cliente.
Modificaremos en concreto el archivo de estilos con nombre
egroupware\phpgwapi\templates\idots\css\idots.css. Se creará la
estética corporativa de la universidad a partir de la modificación de
esta hoja de estilos, sobre todo los colores e imágenes de fondo, con
el fin de adaptarlos a tal efecto.



                                                                     42 / 64
                                                                  Memoria
                                                              del Proyecto

   Se ha elegido el skin idots porque proporciona una navegabilidad
simple y natural. No se ha precisado con el cliente si se ha de
eliminar la posibilidad de establecer otros skins, pero llegado el caso,
solo habrá que eliminar la especificación del skin de cada módulo y
del cargador de los mismos.


5.4.2. Proceso de autenticación:
   eGroupWare proporciona varios métodos de autenticación.
Proporciona autenticación basada en la información que contiene en
su propia base de datos o autenticación frente a un servidor LDAP.
Pasos para poder configurar el acceso al servidor LDAP:

    1. Instalar el esquema LDAP        tal   y   como   se   muestra      en
       phpgwapi/doc/ldap/REAME.
    2. Configurar eGroupWare para utilizar autenticación y cuentas
       de LDAP.
    3. Configurar un host LDAP válido, un contexto de cuentas LDAP,
       un contexto de grupos, un usuario root y su contraseña para
       autenticarse en el LDAP. Le nombre de usuario root y su
       contraseña pueden coincidir con el del root del servidor o ser
       otro usuario con permisos para escribir datos en cualquier
       entrada del contexto en el que almacenan las cuentas y
       grupos.
    4. Asegurarse de que también se ha configurado un tipo de
       encriptación LDAP válido.



5.4.3. Kerberos
   Ante la no viabilidad del la inclusión de kerberos como parte de la
aplicación Agenda Corporativa, en este apartado se propone una
solución para operar con Kerberos y se dan algunos problemas y
ventajas al respecto. RevolutioNet aconseja el uso de kerberos
estableciéndolo en el nivel del servidor web. Apache es el servidor
web más usado en la actualidad. Se propone la instalación de un
servidor Apache o cualquier otro con soporte para Kerberos. En
concreto, para Apache encontramos Mod_auth_kerb, módulo para
apache de libre distribución que se puede descargar desde
http://sourceforge.net/projects/modauthkerb.

Ventajas: disminuye el coste de desarrollar             e    investigar   la
introducción de kerberos en Agenda Corporativa.

Inconvenientes: Kerberos a nivel de servidor web implica que el
navegador deba soportar kerberos, y no todos lo hacen, aunque cada



                                                                           43 / 64
                                                               Memoria
                                                           del Proyecto

vez más soportan esta cualidad. El servidor web debe ofrecer esta
posibilidad, ya sea de manera directa o mediante la inclusión de un
módulo destinado al efecto.



5.5. Estructura interna eGroupWare
   El siguiente diagrama muestra la arquitectura de la plataforma
eGroupWare. En este diagrama se refleja las interacciones entre las
distintas tecnologías que combina para ofrecer servicios a sus
usuarios.




5.6. Enlaces de interés:

Manual de instalación y de seguridad:
http://heanet.dl.sourceforge.net/sourceforge/egwsec/How_to_install_
and_secure_eGroupWare_05.pdf

Manual del usuario en versión electrónica, formato HTML:
http://www.egroupware.org/Spanish-Manual

Coding Standards for egroupware:


                                                                  44 / 64
                                                      Memoria
                                                  del Proyecto

http://www.egroupware.org/index.php?page_name=&category_id=3
8&wikipage=CodingStandards

Idiomas a los que está traducido el eGroupWare:
http://www.egroupware.org/languages




                                                               45 / 64
                                                              Memoria
                                                          del Proyecto


6. Ingeniería de calidad.

   El aseguramiento de la calidad pretende dar confianza en que el
producto reúne las características necesarias para satisfacer todos los
requisitos del Sistema de Información.

   Para la realización del proyecto con un cierto grado de calidad nos
basaremos en las indicaciones que se especifican en la guía de
desarrollo de software MÉTRICA v3, sin obviar que Métrica versión 3
puede ser utilizada libremente con la única restricción de citar la
fuente de su propiedad intelectual, concretamente, el Consejo
Superior de Informática del Ministerio para las Administraciones
Públicas

   Para el desarrollo de nuestro proyecto vamos a incluir un conjunto
de tareas en todas las etapas del ciclo de vida, con las que se
intentará asegurar la realización de un sistema con calidad.



6.1 Estudio y viabilidad de alternativas
    El propósito de este proceso es analizar un conjunto concreto de
necesidades, con la idea de proponer una solución a corto plazo. Los
criterios con los que se hace esta propuesta no serán estratégicos
sino tácticos y relacionados con aspectos económicos, técnicos,
legales y operativos.

   Los resultados del Estudio de Viabilidad del Sistema constituirán la
base para tomar la decisión de seguir adelante o abandonar.

    Las distintas etapas que vamos a describir a continuación, deben
situarse durante el proceso de estudio de las distintas alternativas
propuestas para la realización del proyecto. La introducción de estas
tareas, relacionadas con la calidad en la etapa de estudio de
alternativas, provocan cambios tanto en la planificación como en los
costes de cada alternativa, lo que hace necesario que deban ser
tenidas en cuenta a la hora de la elección de una alternativa para el
desarrollo final del proyecto.


      Determinación de las propiedades de calidad de cada una
      de las alternativas
   La realización de esta etapa tendría lugar justo después de la
   obtención de las distintas propuestas (alternativas) del proyecto,
   antes de que éstas sean valoradas.



                                                                      46 / 64
                                                             Memoria
                                                         del Proyecto

  Para cada una de las alternativas propuestas, se debe determinar
  cuales van a ser los elementos de éstas sobre las que se va a
  realizar un seguimiento de su calidad. También será necesario
  definir cuales serán las propiedades (eficiencia, portabilidad,...) y
  métricas que nos indiquen el cumplimiento o no de la calidad en
  cada uno de estos elementos.

  Una vez realizada esta parte obtendremos un documento con las
  necesidades de calidad de las distintas alternativas, así como de
  las propiedades de cada una de ellas.


     Alcance del plan de aseguramiento de calidad
  Esta etapa se enmarca durante la valoración de las distintas
  alternativas. Antes de realizar esta valoración se debe obtener,
  para cada alternativa, que alcance debe tener un plan de
  aseguramiento de la calidad. Esto nos indica cómo planificar estas
  alternativas de modo que se cumplan las propiedades definidas
  para cada una de ellas en el apartado anterior.

  Una vez definido el alcance del plan de aseguramiento de calidad,
  se debe establecer el coste adicional asociado a cada sistema de
  información en las alternativas propuestas, con el fin de aportar
  esta información al coste total del sistema y en consecuencia
  determinar su viabilidad económica. Este coste aporta la
  información necesaria para poder valorar globalmente cada
  alternativa de solución y determinar su viabilidad.

  Una vez seleccionada una alternativa de desarrollo del proyecto,
  obtendremos el plan de aseguramiento de calidad para esta
  alternativa.


6.2 La calidad en la fase de Análisis del proyecto
El propósito de este proceso es conseguir la especificación detallada
del sistema de información, a través de un catálogo de requisitos y
una serie de modelos, que cubran las necesidades de información de
los usuarios para los que se desarrollará el sistema de información y
que serán la entrada para el proceso de Diseño del Sistema de
Información.


     Creación del Plan de Aseguramiento de Calidad
  Para la creación de un plan de aseguramiento de calidad para
  nuestro proyecto debemos tener en cuenta:




                                                                    47 / 64
                                                              Memoria
                                                          del Proyecto

          Estándares y normas a aplicar durante el proceso de
          desarrollo.

          Procedimientos para informar, hacer seguimiento y
          resolver errores, identificando los responsables de llevarlos
          a cabo.

          Mecanismos de modificación de productos estableciendo
          cómo se van a gestionar dichas modificaciones y el modo
          de comunicarlo a los implicados.

          Modo de valorar las propiedades de calidad.


  Estos puntos nos ofrecerán aspectos generales sobre como
  gestionar la calidad en nuestro proyecto.

  Una vez que están claros estos aspectos generales, el plan de
  calidad debe completarse incluyendo:


          Actividades y tareas a realizar en cuanto al aseguramiento
          de calidad y su emplazamiento a lo largo del proceso de
          desarrollo.

          Descripción de cada uno de los productos obtenidos en el
          proceso de desarrollo, como por ejemplo catálogo de
          requisitos, casos de uso, diagramas de clases, etc.

          Revisiones a realizar, definir los criterios que se deben
          seguir durante la revisión.

          Calendario para la ejecución de estas actividades,
          incluyendo los recursos humanos y materiales necesarios
          para llevarlo a cabo.

  Una vez definido el plan de calidad, toda la información resultante
  de las actividades llevadas a cabo se podrá incluir como un anexo
  de calidad, que formará parte de la memoria del proyecto.




6.3 La calidad en la fase de Diseño del proyecto

   El propósito del Diseño del Sistema de Información es obtener la
definición de la arquitectura del sistema y del entorno tecnológico,


                                                                      48 / 64
                                                              Memoria
                                                          del Proyecto

junto con la especificación detallada de los componentes del sistema
de información. A partir de dicha información, se generan todas las
especificaciones de construcción relativas al propio sistema, así como
la especificación técnica del plan de pruebas, la definición de los
requisitos de implantación y el diseño de los procedimientos de
migración y carga inicial.



     Revisión de los requisitos
  Esta fase estaría situada una vez que se ha terminado la tarea 1
  de la fase de diseño. Aquí deberíamos comprobar la consistencia
  entre las interfaces gráficas y lo especificado en el catálogo de
  requisitos.




6.4 La calidad en la fase de Desarrollo del proyecto
   Estas etapas se enmarcan dentro de la fase que consiste en el
desarrollo de la aplicación, así como instalación y pruebas del
proyecto.


     Revisión de la realización de pruebas
  Esta tarea se debe llevar a cabo durante toda esta etapa y
  consiste en realizar las pruebas especificadas en el plan de
  pruebas que ha sido creado durante el análisis. Esta comprobación
  se realizará para todas las versiones que se vayan entregando del
  sistema.


     Revisión de la implantación
  Se debe comprobar que se cumplen los plazos tanto en la
  instalación como en las pruebas que se han especificado para cada
  uno de los entregables.



6.5 La calidad en la fase de Mantenimiento del proyecto
   El grupo de aseguramiento de calidad intervendrá durante el
mantenimiento, efectuando revisiones de seguimiento periódicas,
más o menos frecuentes según los casos, que sirvan para constatar
que el mantenimiento establecido para el sistema de información se
realiza de forma correcta.




                                                                     49 / 64
                                                          Memoria
                                                      del Proyecto

  Revisión del mantenimiento
Se comprueba que se ha formalizado un plan de mantenimiento
para al sistema de información, entre el cliente/usuario y el
responsable de mantenimiento.

Si se considera conveniente, se estudiará la necesidad de llevar a
cabo un seguimiento y control de la calidad en los sistemas de
información, una vez se encuentren en el entorno de producción.
Así mismo, se revisa que el usuario acepta o rechaza la solución
propuesta para dar respuesta a su petición y que aprueba
formalmente el cierre de la petición.




                                                                 50 / 64
                                                              Memoria
                                                          del Proyecto

7. Programación temporal.
7.1. Introducción

   El propósito de este apartado es detallar el conjunto de fases y
tareas de las que se compone el presente proyecto, mostrando una
estimación precisa de la duración de cada una.

    La planificación propuesta se ha elaborado atendiendo a diversos
parámetros influyentes. Así, se ha optado por optimizar el
paralelismo en el desarrollo de distintas tareas, así como los recursos
físicos y humanos de que consta nuestra empresa.

   Entre las áreas de trabajo planificadas, se encuentran a grandes
rasgos, el análisis detallado de las necesidades del sistema, el diseño
de una solución, el estudio de las distintas alternativas de productos
existentes, la instalación del sistema, así como la formación y el
mantenimiento. Se obtiene una estimación real del tiempo
transcurrido entre el inicio del proyecto y su entrega final.



7.2. Estudio de la normativa vigente

   En esta fase se ha desarrollado la investigación de aquellas
normas que pudieran influir en el desarrollo del proyecto. Se han
tenido en cuenta, tanto las leyes actuales de los gobiernos
autonómico y nacional, como las directivas europeas y la normativa
de la propia universidad; así, se trata de normas sobre la jerarquía
universitaria, la descripción y atribuciones de los diferentes gremios
de trabajadores, leyes de protección de datos, etc.

  Las tareas de estudio de la legislación vigente y su propuesta al
equipo del proyecto han ocupado a dos personas durante 3 días.



7.3. Análisis detallado de las necesidades del sistema

   Con esta fase se pretende dilucidar con la máxima precisión
posible, cuáles son las necesidades básicas del sistema en una
primera fase. Se han de distinguir cuáles son las partes de que
constará el sistema final, esto es, la implantación de una base de
datos o no, el tipo de aplicación y la estructura general del sistema.




                                                                      51 / 64
                                                               Memoria
                                                           del Proyecto

   Posteriormente se procede al desarrollo de documentos de
requisitos para fijar con precisión las características y necesidades
reales del sistema, pudiendo elaborar a partir de ellas un correcto
diseño de la solución.

   Esta fase se ha elaborado durante tres días por tres personas.


7.4. Estudio de las alternativas

    La fase que nos ocupa cubre todos los aspectos relacionados con
la selección de los productos software que requiere el proyecto. Así,
uno de los factores más importantes es la elección del cliente de
agenda electrónica más completo y adaptable a las necesidades de
nuestro proyecto. A ello se debe dedicar gran parte de nuestro
esfuerzo, pues el cliente debe ser adaptado, y quizá modificado o
desarrollado a base de módulos o pluggins por el equipo de trabajo,
por lo que una selección idónea es vital. En esta fase se lleva a cabo
un estudio de todas las opciones que pueden escogerse como
agendas corporativas, así como un análisis detallado de cada una de
ellas, que serán determinantes para escoger la alternativa correcta.

   Esta fase es desarrollada por dos personas durante un período de
seis días, en el que se estudian las principales agendas corporativas
del mercado. Se trata de esclarecer los principales aspectos de cada
una, recoger información, solicitar documentos a los creadores del
software, etc, y realizar con todo ello un documento que recoja una
primera selección de candidatos.




7.5. Estudio y preparación de la alternativa seleccionada

   El estudio, el análisis y la preparación en profundidad de la agenda
corporativa se lleva a cabo durante esta fase. Se debe profundizar en
su estudio, pero también preparar su skin para acceder directamente
a los requisitos del proyecto, y preparar el funcionamiento del servicio
Kerberos. Además, se elaboran informes que recojan la información
obtenida hasta ahora y enseñen cómo adaptar el cliente al uso de
Oracle, así como su instalación.

   Paralelamente se actualizan los documentos de requisitos si lo
requiriesen, y se elaboran documentos internos, como manuales de
usuario.

   Esta fase se desarrolla durante cinco personas, una de las cuales
participa dos días y el resto seis.


                                                                       52 / 64
                                                               Memoria
                                                           del Proyecto



7.6. Pruebas

    La fase de pruebas del sistema es esencial para detectar errores y
verificar funcionalidades, y ha revelado la corrección del trabajo
realizado. Se incluye aquí también la fase de pruebas realizadas tras
la instalación de la herramienta en el lugar de trabajo de los usuarios.
La modificación de detalles menores y la elaboración de las pruebas
del software ocuparon las siguientes tareas:

   Pruebas durante el desarrollo del proyecto: 2 personas durante 2
   días.
   Pruebas post instalación: 2 personas durante 1 día.



7.7. Suministro e instalación

   Una vez que se ha concluido el proyecto se procede a la
instalación del hardware necesario para el funcionamiento del sistema
en su totalidad. Además se instalará el sistema y las aplicaciones, así
como el software requerido por éstos. Esta fase se completa en un
día y será llevada a cabo por dos personas

7.8. Formación

   La formación del personal se realizará mediante un seminario
impartido por RevolutioNET. Un profesional de nuestra empresa
impartirá un seminario de formación en el lugar de trabajo de los
usuarios, donde éstos tendrán oportunidad de realizar un tutorial
pormenorizado con demostraciones paso a paso.

   Esta fase consta de las siguientes tareas:


      Seminario sobre el manejo de la aplicación: 1 persona durante
      2 días.

      Simulación de un escenario de trabajo habitual: 2 personas
      durante 1 día.



7.9. Mantenimiento y soporte técnico



                                                                       53 / 64
                                                             Memoria
                                                         del Proyecto

   Cuando el sistema se encuentra en funcionamiento, se realizan
labores de mantenimiento y soporte técnico durante el período de
garantía, que es de 12 meses. Más allá del período de garantía, esta
actividad estará supeditada a la contratación por parte del cliente.


7.10. Planificación temporal

   A continuación se muestra una gráfica con la planificación del
proyecto para ilustrar su duración en el tiempo así como las distintas
fases de que ha constado y el modo en que se han afrontado. El
gráfico muestra los días hábiles de desarrollo.




                                                                     54 / 64
                                                               Memoria
                                                           del Proyecto


8. Normas para             la    explotación         del    nuevo
   sistema.
8.1 Introducción

   La fase de explotación de un sistema consiste en la implantación
del sistema en el lugar de trabajo, comprobar su correcto
funcionamiento, realizar la formación de los usuarios y el
mantenimiento.

    Describiremos cuál será el proceso para poner en funcionamiento
el sistema y cómo conseguir la adaptación de la organización al
nuevo entorno de trabajo. Las aplicaciones desarrolladas han de ser
utilizadas únicamente por el personal que, habiendo recibido
formación, esté cualificado para ello.



8.2 Implantación del sistema

   La instalación del hardware y el software será realizada
exclusivamente por técnicos pertenecientes a nuestra empresa.



8.3 Formación

   Los usuarios finales aprenderán a utilizar el sistema de forma
correcta y sencilla, fomentando el ánimo del usuario para su posterior
uso y un uso amigable de la interfaz de la aplicación. Creamos un
plan de formación para instruir al usuario final de la aplicación.

   Para asegurar la correcta formación del personal, RevolutioNet
impartirá seminarios que expliquen el modo de empleo de la
aplicación. En estos seminarios se presentará el modo más eficiente
de realizar cada tarea y se enseñará a consultar el manual de la
aplicación, de cara a resolver dudas futuras personales por cuenta
propia. Antes de los seminarios, se repartirán manuales de uso y
textos guía para el seminario.

   Existirán distintos seminarios, en función de las capacidades y
tareas de los diferentes usuarios que vayan a usar el sistema.
Preferiblemente los seminarios se impartirán en el propio puesto de
trabajo de la empresa del cliente, con el objetivo de que se
familiaricen con la aplicación en su entorno de explotación real.


                                                                     55 / 64
                                                             Memoria
                                                         del Proyecto


8.4 Normas de uso del sistema

   La empresa RevolutioNet, desarrolladora de la aplicación, dispone
de los derechos de explotación y distribución del producto.

   La aplicación desarrollada se entrega con licencia de uso, en
ningún caso se permitirá la cesión, venta o préstamo, quedando
prohibido cualquier uso fuera del ámbito para el que ha sido
implantado.

   Cualquier modificación externa en el proyecto que no cuente con
la aprobación pertinente de RevolutioNet conllevará a la anulación de
la garantía establecida.


8.5 Garantía del producto

   La empresa se compromete a proporcionar un periodo de garantía
de doce meses a partir de la fecha de entrega-aceptación del
proyecto. Dentro de este periodo de garantía, realizará cualquier tipo
de mantenimiento correctivo que sea necesario para el
funcionamiento satisfactorio del sistema. Además la empresa
desarrolladora proporcionará un servicio de atención al cliente, por
teléfono o por Internet.

  Distinguimos tres tipos de mantenimiento:

  Mantenimiento correctivo: fallos que se pueden encontrar en el
  sistema debido a que algún requisito no se cumple o se ha
  implementado de manera incorrecta. Este mantenimiento es el
  único que está incluido dentro de la garantía del producto.

  Mantenimiento evolutivo: son los cambios que serán necesarios
  aplicar al sistema debido a los cambios producidos en las
  necesidades de la empresa con el paso del tiempo.

  Mantenimiento adaptativo: son los cambios que será necesario
  realizar debido a modificaciones producidas en el entorno de
  funcionamiento del sistema. Estas modificaciones pueden ser de
  tipo hardware o software, y pueden incluir cambios en las
  plataformas en la que se ejecuta el sistema, cambios en los
  sistemas operativos, cambios en las bases de datos usadas, etc.




                                                                     56 / 64
                                                                Memoria
                                                            del Proyecto

   Finalizado el plazo de garantía, se podrá seguir contando con
nuestro servicio de mantenimiento mediante un nuevo contrato. En
este nuevo contrato se fijará una cuota que deberá pagarse de forma
anual, y se abonarán independientemente los gastos relativos a la
resolución de la incidencia.



8.6 Mantenimiento
   RevolutioNet proporciona un servicio de mantenimiento de las
distintas áreas del sistema. La empresa aportará las soluciones
necesarias a cada uno de los fallos que se produzcan durante la
explotación del sistema.
   En el caso de fallos sobre el hardware en el que corre la aplicación,
la garantía en vigor será la proporcionada por los proveedores del
material; la empresa también ofrece la posibilidad de gestionar y
proceder a resolverlos.

   El soporte técnico podrá solicitarse mediante asistencia telefónica,
fax o correo electrónico.

    En caso de que surjan averías RevolutioNet ofrecerá en primera
instancia una ayuda vía telefónica para la resolución del problema, y
en caso de que ésta no pudiera ser resuelta a través de los medios
citados, ni mediante administración remota del equipo, se presentará
un técnico en sus instalaciones para llevar a cabo la resolución.

   El servicio de atención al cliente consistirá en un teléfono de
asistencia (disponible en horario de oficina) y el servicio de asistencia
presencial mediante un técnico (con garantía de presentación en
menos de 24 horas).

   El tiempo máximo de restablecimiento del sistema en caso de fallo
dependerá de la gravedad que revista el problema, pero se
garantizará el restablecimiento del sistema en un máximo de 48
horas tras la presentación de los técnicos.

   El servicio de soporte técnico incluye la resolución de dudas
específicas, formación de nuevos equipos y de usuarios que hayan
cambiado de actividad, hasta procesos de reparación de fallos.



8.7 Normas y mecanismos de seguridad
   Los requisitos de seguridad deseables en nuestra aplicación son
principalmente: autenticación, confidencialidad, control de acceso,
integridad y no repudio.


                                                                        57 / 64
                                                              Memoria
                                                          del Proyecto

    Una de las primeras fases del sistema consiste en integrar las
normativas y la legislación sobre seguridad en el diseño del proyecto,
junto con el Plan de Seguridad acordado para la Implementación.
Para ello, en los seminarios de formación detallados anteriormente,
se instruirá a los usuarios responsables sobre cómo realizar las tareas
ligadas con la seguridad.




                                                                      58 / 64
                                                              Memoria
                                                          del Proyecto


9. Presupuesto y estudio económico.
   En esta sección se va a especificar el presupuesto del desarrollo de
la aplicación desarrollada, es decir, el desarrollo de la agenda
corporativa.

    En relación al hardware necesario, servidor, impresoras,
contrataciones de líneas de Internet, así como a las licencias del
software para el sistema operativo, antivirus, o de la base de datos
quedan fuera del ámbito de este presupuesto y correrán a cuenta del
cliente. En caso de que lo requieran, nuestra empresa puede
facilitárselos imponiendo la tarifa que está impuesta para esta clase
de productos.

   Este presupuesto está basado en el tiempo dedicado al desarrollo
de dicha aplicación por parte de los expertos dedicados al mismo. Se
tendrá en cuenta los siguientes estudios y desarrollos necesarios:
estudio de las normativas y leyes, el análisis detallado de las
necesidades del sistema, el estudio de las distintas alternativas de
productos existentes, el estudio de la alternativa escogida, las
pruebas de calidad, la instalación del sistema, la formación del
personal y el mantenimiento. Para calcular el presupuesto, se ha
estimado un precio de coste por cada hora de desarrollo en cada una
de las necesidades del sistema.

   Al finalizar la explicación de los diferentes estudios y desarrollos
que se han hecho sobre la aplicación, se adjunta una tabla que
contiene el resumen del presupuesto.

   Para estimar el precio por hora de cada uno de los estudios y
desarrollos que se han llevado a cabo, se ha tenido en cuenta que
una persona puede desempeñar tres tipos de actuaciones respecto al
trabajo que realiza en ese momento. Estos tres tipos son:

       Analista
       Diseñador
       Programador

   Cada uno de los cargos que realiza una persona tiene estimado un
precio diferente. Hay que tener en cuenta que una persona dedicada
a desarrollar el proyecto, no tiene porque actuar siempre con la
misma función, es decir, puede actuar en un momento dado como
analista y en días posteriores como programador, suponiendo
siempre que está cualificado para desempeñar estas funciones. El
precio por hora de cada uno de los cargos desempeñados es el
siguiente:


                                                                      59 / 64
                                                                   Memoria
                                                               del Proyecto

         Analista                      25 € / Hora
         Diseñador                     30 € / Hora
         Programador                   20 € / Hora
         Profesional Seminario         18 € / Hora




9.1. ESTUDIO DE LAS NORMATIVAS Y LEYES.

En primer lugar, es necesario realizar un estudio de las normativas y
leyes que influyen en el proyecto. Este estudio será realizado por dos
miembros que actuarán como analistas. Para hacer este estudio han
sido necesarias 2 horas al día durante un periodo de tres días, lo que
hace que cada analista haya trabajado durante 6 horas. Por lo tanto
el precio de este estudio es:

 Estudio Leyes      Analista 1    6 Horas      25 € / Hora         150 €
 Estudio Leyes      Analista 2    6 Horas      25 € / Hora         150 €
    TOTAL                                                          300 €




9.2. ANALISIS DETALLADO DE LAS NECESIDADES DEL
     SISTEMA.

A continuación se ha realizado un análisis de las necesidades del
sistema para saber las partes de las que constará el sistema final y
cuales son las necesidades del sistema. También se ha realizado en
esta fase un estudio de los requisitos para saber las características y
necesidades del sistema. Todo esto se ha realizado con el fin de
elaborar un diseño correcto de la aplicación final y se procede al
desarrollo de documentos de requisitos. El análisis será realizado por
tres miembros que actuarán como analistas. Para hacer este análisis
han sido necesarias ocho horas al día durante un periodo de tres días,
lo que hace que cada analista haya trabajado durante veinticuatro
horas. Por lo tanto el precio de este estudio es:


Análisis Necesidades      Analista 1   24 Horas      25 € / Hora     600 €
Análisis Necesidades      Analista 2   24 Horas      25 € / Hora     600 €
Análisis Necesidades      Analista 3   24 Horas      25 € / Hora     600 €
       TOTAL                                                        1800 €




                                                                           60 / 64
                                                                      Memoria
                                                                  del Proyecto


9.3. ESTUDIO DE LAS DISTINTAS ALTERNATIVAS DE
     PRODUCTOS EXISTENTES.

El siguiente estudio que hemos realizado, es un estudio sobre las
alternativas posibles para alcanzar la solución al desarrollo de la
agenda corporativa. En este estudio se realiza la elección de los
productos software que se requieren, así como la elección del cliente
de agenda que mejor cumpla las necesidades. En el estudio se
elabora un informe con todas las soluciones posibles al proyecto y se
realiza la selección de una alternativa. Este estudio ha requerido del
trabajo de dos miembros que actúan como analistas durante seis
días, teniendo una dedicación de ocho horas diarias. Cada analista ha
dedicado cuarenta y ocho horas de trabajo. El presupuesto de este
estudio es el siguiente:

 Estudio Alternativas   Analista 1   48 Horas   25 € / Hora         1200 €
 Estudio Alternativas   Analista 2   48 Horas   25 € / Hora         1200 €
       TOTAL                                                        2400 €




9.4. ESTUDIO DE LA AGENDA ESCOGIDA, SU
     PREPARACIÓN Y MODIFICACIÓN

A continuación se realizó un estudio y una preparación de la
alternativa seleccionada. Aquí se estudia la agenda, se prepara para
hacer que funcione el servicio Kerberos, se prepara el skin para
acceder directamente a los requisitos del proyecto y se elabora el
informe que enseñe al cliente adaptarlo a Oracle en la universidad e
instalarlo .El estudio, análisis y preparación de la agenda corporativa
se ha realizado por parte de un diseñador dedicado dos días durante
ocho horas, dos analistas dedicados seis días durante ocho horas y
dos programadores dedicados seis días durante ocho horas. El
diseñador trabajó en esta sección dieciséis horas, los analistas
durante cuarenta y ocho horas y los programadores emplearon
también cuarenta y ocho horas:


   Prep.   Agenda     Diseñador 1      16   Horas   30   €   /   Hora    480 €
   Prep.   Agenda      Analista 1      48   Horas   25   €   /   Hora   1200 €
   Prep.   Agenda      Analista 2      48   Horas   25   €   /   Hora   1200 €
   Prep.   Agenda    Programador 1     48   Horas   20   €   /   Hora    960 €
   Prep.   Agenda    Programador 2     48   Horas   20   €   /   Hora    960 €


                                                                             61 / 64
                                                                 Memoria
                                                             del Proyecto

     TOTAL                                                          4800 €



9.5. PRUEBAS DE CALIDAD

Antes de la entrega del producto final, se deben de realizar las
pruebas necesarias para comprobar el correcto funcionamiento de la
aplicación. Estas pruebas se llevan a cabo por parte de dos analistas
durante dos días de trabajo. Cada día de trabajo les llevará cinco
horas de dedicación, por lo que cada analista hará una dedicación de
diez horas:

   Pruebas Desarrollo       Analista 1     10 Horas     25 € / Hora    250 €
   Pruebas Desarrollo       Analista 1     10 Horas     25 € / Hora    250 €
        TOTAL                                                          500 €



9.6. INSTALACIÓN DEL SISTEMA

Cuando este totalmente finalizado el proyecto se llevará a cabo la
instalación del software requerido para el uso de la aplicación. Esta
instalación se llevará a cabo en un único día por parte de dos
programadores. La duración de la instalación se estima que lleve todo
el día, es decir ocho horas de trabajo por parte de cada programador:

Instalación Software    Programador 1      8 Horas      20 € / Hora    160 €
Instalación Software    Programador 2      8 Horas      20 € / Hora    160 €
       TOTAL                                                           320 €



9.7. PRUEBAS DE CALIDAD

Una vez instalado el software en el lugar de trabajo de los usuarios,
se realizarán de nuevo pruebas para confirmar el correcto
funcionamiento. Estas pruebas las llevarán a cabo un programador y
un analista en un único día, dedicando seis horas para realizarlas:

 Pruebas Instalación    Programador      6 Horas      20 € / Hora     120 €
 Pruebas Instalación      Analista       6 Horas      25 € / Hora     150 €
      TOTAL                                                           270 €




                                                                         62 / 64
                                                                Memoria
                                                            del Proyecto

9.8. FORMACIÓN DEL PERSONAL

Se realizará un curso de formación de personal mediante un
seminario por parte de un profesional de la empresa RevolutioNET
dedicado a los usuarios finales de la agenda corporativa. Un
profesional estará dedicado durante dos días para impartir un
seminario sobre el manejo de la aplicación con una duración de
cuatro horas al día. Este profesional cobrará un gasto de dieciocho
euros la hora y en total el curso durará ocho horas:

 Seminario Manejo     Profesional      8 Horas     18 € / Hora    144 €
     TOTAL                                                        144 €

Una vez impartido este seminario, se impartirá otro curso mediante
un seminario de simulación de un escenario de trabajo habitual. Este
seminario será impartido por parte de dos profesionales que cobrarán
un gasto de dieciocho euros la hora. El seminario se realizará en un
único día y tendrá una duración de cinco horas:

Seminario Escenario    Profesional 1     5 Horas    18 € / Hora    90 €
Seminario Escenario    Profesional 2     5 Horas    18 € / Hora    90 €
     TOTAL                                                        180 €



9.9. MANTENIMIENTO

Cuando el sistema se encuentra en funcionamiento, se realizan
labores de mantenimiento y soporte técnico durante el período de
garantía, que es de 12 meses. Más allá del período de garantía, esta
actividad estará supeditada a la contratación por parte del cliente y
tendrá un coste de 20 € / Hora por cada profesional contratado.




                                                                          63 / 64
                                                      Memoria
                                                  del Proyecto

9.10. TABLA RESUMEN

       Estudio Leyes                                300 €
    Análisis Necesidades                           1800 €
    Estudio Alternativas                            2400
  Estudio Agenda Escogida                           4800
      Pruebas Calidad
                            Pruebas Desarrollo      500 €
                            Pruebas Instalación     270 €
   Instalación Software                             320 €
    Formación Personal
                             Seminario Manejo       144 €
                            Seminario Escenario     180 €

          TOTAL                                    10714 €




                                                             64 / 64

								
To top