SISTEMA DE SEGUIMIENTO DE PROYECTOS

ISC-2003-1-31 Sistema de seguimiento de proyectos

Andrés Mora EcheverryJuan Carlos Uribe Silva

1

SISTEMA DE SEGUIMIENTO DE PROYECTOS

JUAN CARLOS URIBE SILVAANDRÉS MORA ECHEVERRY

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERIA

DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

BOGOTA D.C.

2003



2

SISTEMA DE SEGUIMIENTO DE PROYECTOS

JUAN CARLOS URIBE SILVAANDRÉS MORA ECHEVERRY

Proyecto dirigido para optar al título deIngeniero de Sistemas y Computación

AsesorJUAN PABLO QUIROGA GONZALEZ

Ingeniero de Sistemas

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERIA

DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

BOGOTA D.C.

2003



3

CONTENIDO

INTRODUCCIÓN.............................................................................................................................................................. 4

OBJETIVOS........................................................................................................................................................................ 5

MARCO TEORICO.......................................................................................................................................................... 7

DESCRIPCIÓN DE LA APLICACIÓN....................................................................................................................17

CONCLUSIONES............................................................................................................................................................46

ANEXOS.............................................................................................................................................................................48

BIBLIOGRAFIA..............................................................................................................................................................58



4

INTRODUCCIÓN

En el campo del software para el seguimiento de proyectos, se evidencia una escasez de

aplicaciones computacionales, que vayan más allá de funciones básicas y difíciles de usar;

y que representen una utilidad real, que pueda ser aprovechada por profesores y gerentes de

proyectos. Las herramientas para el seguimiento de proyectos, aunque usadas, no son

aprovechadas por la dificultad en su uso y la poca interacción con el usuario.

Apoyándonos en el amplio uso de las redes de computadores y basados en la necesidad de

la creación de un software que permitiera administrar y monitorear proyectos de Ingeniería

de software, es decir administrar los grupos de trabajo, las fases y los entregables de cada

una de ellas; y tener un control sobre los documentos entregados, de manera sencilla y

amable para los usuarios del software, este proyecto propone una metodología que apoya

el monitoreo de proyectos, que soporte el control y seguimiento eficaz de los documentos

que componen a estos.

El resultado final, se validará con la instalación del software en un ambiente real, en este

caso la red de la Universidad de los Andes. Se desarrollará una aplicación multiplataforma,

en el lenguaje de programación PHP 1, soportado sobre XML-RPC2, y usando como base de

datos MySQL3, todos de distribución y uso libre, para satisfacer las necesidades educativas.

El documento está organizado con las siguientes temáticas:

Marco teórico sobre la tecnología y herramientas usadas para el desarrollo de la aplicación;

y sobre el software que existe actualmente en el mercado, posteriormente la presentación

del análisis, diseño e implementación de la aplicación y finalmente las conclusiones de la

metodología y los manuales respectivos, para el buen uso de la herramienta.

1 PHP: ( Hypertext Preprocessor) es un lenguaje "open source" interpretado de alto nivel embebido en páginasHTML y ejecutado en el servidor.2 XML-RPC: (Extensible Markup Language - Remote Procedure Call) es una especificación eimplementación que permite a una aplicación invocar procesos remotos sobre internet.3 MySQL: Base de datos.



5

OBJETIVOS

Objetivo General

Desarrollar una aplicación para el seguimiento de proyectos universitarios, fácil de manejar

y con una interfaz sobre Internet, de fácil aprendizaje para los usuarios, que además permita

a los estudiantes delegar funciones a los demás integrantes del grupo dependiendo de los

roles. Por otro lado el software debe permitir enviar documentos al profesor o monitor, con

el fin de que este los revise y analice; y luego se genere un proceso de retroalimentación

hacia los estudiantes, enviándoles comentarios y correcciones, para que mejoren los

entregables de cada fase. Usando el software, mediante un navegador estándar de web, el

administrador de la aplicación puede crear proyectos, con sus respectivas fases, al igual que

adicionar estudiantes estos, definiendo los roles y la distribución de estos en el conjunto

total del curso.

Objetivos específicos

Desarrollar una aplicación para el seguimiento y monitoreo de proyectos.

Proveer de una plataforma gratuita, para el uso universitario, y en general para fines

educativos; para lo cual vamos a usar herramientas de libre uso, como: php y MySql.

Mantener un ambiente seguro, para el envío de documentos, anticipándonos a posibles

ataques y huecos de seguridad; para este fin, usamos sockets seguros y manejamos números

de sesión, cada vez que un usuario ingresa al sistema.

Facilitar la interacción profesor – estudiante, apoyándonos en el uso de la Internet; que es

de fácil acceso para los dos usuarios de la aplicación, y permite enviar los documentos en

formato digital, y obtener un feedback de manera ágil y pronta, para mantener los

cronogramas de desarrollo al día y evitar retrasos.

Crear una aplicación que sirva como repositorio de mensajes, y que por medio de la

Internet se pueda acceder a todas las correcciones y comentarios que se hagan, durante el



6

proceso de desarrollo de software; permitiendo a los estudiantes y al profesor hacer un

seguimiento de cada una de las fases que tienen los proyectos.

Ofrecer al profesor y a los estudiantes, una interfaz fácil de aprender y sencilla de utilizar,

con el fin de que se genere un canal de comunicación entre los dos usuarios del sistema.



7

MARCO TEORICO

Introducción

El marco teórico tiene como objetivo aclarar y explicar los términos referentes a un Web

service XML-RPC y explicar el funcionamiento de de este, de una manera general,

viéndolo como una herramienta para realizar procedimientos remotos a través de una red.

Además durante este capitulo se estudiaremos la arquitectura del web service y un detallado

análisis a lo que es XML-RPC como protocolo para procedimientos remotos.

Por último se analizarán las ventajas como las desventajas de la herramienta Bugzilla, la

cual tiene como objetivo el seguimiento y corrección de errores en proyectos, la cual fue

utilizada como base para esta aplicación.

Web service

WEB SERVICE es hoy en día uno de los grandes avances en desarrollo de software que

existe; ya que esta basado en estándares de Internet y permite ser distribuido por los mas

conocidos sistemas operativos. Un web service, es un programa que permite realizar acceso

remoto a procedimientos a través de una red, este es independiente del lenguaje en que esta

escrito y el sistema operativo en que este funcionando, teniendo como sistema de

comunicación (protocolo de comunicación) especificaciones basadas en XML, tales como

XML-RPC o SOAP4. Este tipo de aplicaciones son auto-descriptivas y pueden determinar

que funciones están activas y como se debe acceder a ellas.

Las características más llamativas de estas aplicaciones son su capacidad de integrar varios

sistemas, su bajo costo, facilidad y orientación a herramientas tipo web; lo que se convierte

en una gran ventaja cuando se tiene software empresarial, ya que cumple dos de los grandes

objetivos empresariales, bajo costo e integración.. Hoy en día las empresas optan por este

tipo de desarrollo orientado a solucionar requerimientos internos, integración entre

aplicaciones, programas para socios de ventas y desarrollos en las cadenas de proveedores,

4 SOAP: (Simple Object Access Protocol), es un protocolo basado en XML para el acceso remoto de objetossobre una red.



8

aprovechando desarrollos anteriores estables y funcionales, por más viejos que estos sean.

La importancia de los web services, dentro de estos desarrollos radica en la disminución de

costos, ya que se convierten en una solución barata, segura y estable, para creación de

aplicaciones de envío de información.

Basados en lo anterior, los web services son vistos como una importante herramienta en el

portafolio de negocios que se tiene para las empresas de hoy en día, aunque se discute

todavía el problema de que los protocolos basados en XML consumen demasiados recursos

en el envío y generan bajos tiempos de respuesta con respecto a protocolos planos que

tienen sus propios estándares menos pesados.

A continuación describiremos la arquitectura que tiene los web service, y las características

que los rodean:

• Capacidad de intercambiar mensajes.

• Autodescripción del web service.

• Implementación de las descripciones de cada web service.

Esta arquitectura define la interacción de tres agentes: el proveedor del servicio, la agencia

de descubrimiento del servicio y el solicitante del servicio, la interacción involucra las

operaciones de publicación, descubrimiento y enlace.

Los componentes de esta arquitectura son:

• El servicio: Es un módulo del software desplegado en una plataforma cualquiera

que debe ser accesible por la red y proporcionado por el proveedor de servicio,

existe para ser invocado o para interactuar con un solicitante del servicio, puede

también funcionar como un solicitante, usando otros servicios en su puesta en

práctica.



9

• La descripción del servicio: Contiene detalles de la interface y la implementación

del servicio, esto incluye tipo de datos, operaciones, información de enlace y

localización en red. La descripción del servicio puede ser publicada al solicitante

del servicio directamente o a través de una agencia de descubrimiento del servicio.

Los roles que interactúan en esta arquitectura:

• El proveedor del servicio: Desde la perspectiva de negocios, este es el dueño del

servicio, desde la arquitectura es la plataforma que tiene el acceso del servicio. En el

rol cliente-servidor de intercambio de mensajes seria el servidor.

• El solicitante del servicio: Desde la perspectiva de negocios, este seria el negocio

que requiere una función para satisfacer una necesidad y desde el punto de vista de

arquitectura es la aplicación que esta buscando invocar o interactuar con un

servicio. Este rol puede ser interpretado por una persona o por un programa sin

interfaz de usuario (otro web service). En el rol cliente-servidor de intercambio de

mensajes seria el cliente.

• Agencia de descubrimiento del servicio: Este es un conjunto de descripciones del

servicio, que se pueden encontrar fácilmente en la red y son publicados por el

proveedor del servicio. Pueden ser centralizados o distribuidos.

Las operaciones que tiene esta arquitectura:

• Publicación: Para poder ser accesible, el servicio necesita publicar su descripción de

servicios con el fin de que el solicitante del servicio pueda utilizar el web service.

• Búsqueda: El solicitante del servicio requiere la descripción del servicio

directamente o busca en la agencia de descubrimiento del servicio los servicios

disponibles para su uso.



10

• Interacción: Eventualmente el servicio necesita ser invocado en la interacción con el

solicitante del servicio, necesita invocar o iniciar una interacción con el servicio.

ARQUITECTURA ORIENTADA A SERVICIO

Figura 1.[Los rectángulos significan equipos o computadores, los óvalos significan una aplicación y las flechas significan acciones]



11

La idea es que es proveedor del servicio defina la descripción de los servicios y la publique

en la agencia de descubrimiento del servicio, el solicitante del servicio busca las funciones

dentro de la agencia de descubrimiento del servicio y se enlaza con la implementación del

proveedor del servicio, invocando o interactuando con el, esto con ayuda de la descripción

del servicio encontrada en el registro o repositorio de la agencia de descubrimiento del

servicio.

XML-RPC

XML-RPC es un protocolo que permite realizar llamados de procedimientos remotos

(Remote Procedure Calling) usando HTTP como transporte y XML como codificación.

Este puede ser usado por varios lenguajes tales como PHP, C, C++, Perl, Java, Python y

otros. Existen implementaciones sobre sistemas operativos tan diversos como Windows,

Unix y Macintosh.

Este protocolo fue creado por Dave Winer , después de salir del proyecto de SOAP en el

cual estaba trabajando con Don Box , Bob Atkinson y Mohsen Al-Ghosein en Microsoft,

esto sucedió ha comienzos de 1998 y esta es la razón por la cual los dos protocolos son en

cierta medida muy parecidos y tienen los mismos objetivos.

XML-RPC tiene como característica principal la implementación de los mínimos

requerimientos, para realizar un llamado remoto a un procedimiento; ya que es claro que el

uso de XML tiene un costo en el desempeño de la red, adicional a su facilidad de

implementación y sencillez.

Esta implementación tiene ciertas limitaciones, entre ellas, que no se puede pasar objetos

por los parámetros, de los llamados a las funciones; no se puede especificar cual porción

del mensaje se recibe; las estructuras de los arreglos son siempre anónimas, pero es claro



12

que este es el costo que se tiene que pagar por lograr un protocolo que busca la sencillez y

facilidad de uso.

Pero miremos cuales son las ventajas y desventajas que se tiene sobre los otros protocolos

de llamados remotos, por ejemplo CORBA5 que este esta muy bien construido para las

aplicaciones orientadas a objetos y tiene un gran desarrollo en aplicaciones empresariales,

las cuales han demostrado ser estables, pero es muy complejo y su curva de aprendizaje es

alta, adicionalmente se necesita un gran esfuerzo de implementación, al contrario de XML-

RPC que es muy fácil y sencillo de usar.

Si se mira el protocolo DCOM6 de Microsoft que nació como respuesta a CORBA, el cual

tiene un buen desempeño a través de los componentes COM7, pero que tiene como clara

desventaja la incompatibilidad con sistemas NO- Microsoft.

Y Por ultimo tenemos SOAP el cual es muy parecido a XML-RPC pero con muchas mas

características ya que maneja XML Schemas, enumerations, híbrido entre

structuras_arreglos, y tipos personalizados. Pero actualmente muchos aspectos de este

protocolo están por definir.

ESPECIFICACION TECNICA

Cada mensaje de XML-RPC es un mensaje de petición en HTTP-POST, en el cual el

cuerpo del mensaje esta en XML, para luego de ser procesado, el llamado remoto del

servidor retorna también un mensaje en formato XML. (Ver anexo 3).

5 CORBA: son las siglas para “Common Object Request Broker Architecture” y en la practica es unaarquitectura y infraestructura que permite la integración de diferentes aplicaciones sobre una red en común.6 DCOM: (Distributed Component Object Model) es un protocolo que permite que los componentes de lasaplicaciones se comuniquen.7 COM: (Component Object Model) es una arquitectura que permite a aplicaciones ser creadas desde basebinaria.



13

Los tipos de datos que se pueden manejar a través de este protocolo son:

Nombre Tipo Ejemplo

<i4> or <int> Entero con signo de 4 bytes -12

<boolean> 0 (falso) or 1 (Verdadero) 1

<string> Cadena ASCII HOLA

<double> Numero flotante con doble

precisión y signo

-12.214

<dateTime.iso8601> Fecha/Tiempo 19980717T14:08:55

<base64> base64-encoded binario eW91IGNhbid0IHJlYWQgdGhpcyE=

Adicionalmente XML-RPC permite la creación de estructuras y arreglos con los anteriores

datos, su especificación es <struct> y <array> respectivamente. (Ver Anexo 3).

HERRAMIENTAS PARA EL MANEJO DE ERRRORES

Las herramientas para el manejo de errores sirven para reportar bugs y errores de software

y proyectos en los cuales están trabajando varias personas simultáneamente, con el fin de

tener un control sobre ellos, además de reportarlos ante la comunidad de desarrolladores,

para que puedan solucionarlos y tenerlos encuentra cuando uno de ellos los este afectando.

BUGZILLA

Bugzilla es un programa para el seguimiento de errores dentro de un sistema determinado,

este permite que un grupo de desarrolladores le sigan la pista a los errores que se generan

dentro de la elaboración de un proyecto determinado.



14

Bugzilla fue creado por Terry Weissman y escrito en el lenguaje de programación TCL ,

con el propósito de remplazar la base de datos de errores (Bugs) usada internamente en

Netscape Communications. Luego este programa fue escrito por Weissman en Perl,

lenguaje de programación en el cual permanece escrito hoy.

Bugzilla es uno de los más conocidos y favoritos por los programadores a nivel mundial,

para el manejo de proyectos orientado al seguimiento de errores en el proyecto. Gracias a

que Bugzilla hace parte de la enorme cantidad de software libre, es ampliamente utilizado

para una gran variedad de proyectos. Adicionalmente se ha generado un proyecto de código

abierto Mozilla, en el cual la comunidad de software libre esta participando para mejorar y

ampliar el funcionamiento de Bugzilla. Para esto se creo www.mozilla.org en 1998, este es

hoy día manejado por Dave Miller.

Para dar un ejemplo sobre las capacidades del programa podemos mencionar las más

importantes características que tiene este:

• Integración de un esquema de seguridad.

• Dependencia entre los errores y entre las graficas de las dependencias.

• Capacidades avanzadas de reportes.

• Extensos modos de configurar el programa.

• Un claro y entendible protocolo para resolver los errores.

• APIs para email, XML, consola y HTTP

• Permite integración con programas como CVS 8 y Perforce.

Actualmente se esta trabajando para que el programa tenga una instalación mucho mas

fácil, soporte mas bases de datos y en mejorar las posibilidades de habilitar y deshabilitar

características del programa, esto como base del proyecto de Mozilla.

8 CVS:( Concurrent Versions System) es una aplicación diseñada para controlar versiones de aplicaciones.



15

Pero para realizar estos cambios se tienen que mantener los principios del diseño que se

quiere tengan los programas realizados a través de Mozilla:

• Estos programas tiene que ser escritos en herramientas de software libre y su código

tendrá que ser abierto, con posibilidades de obtener fácilmente el código fuente del

programa.

• Se tendrá soporte para versiones comerciales de bases de datos, herramientas y

sistemas operativos.

• Se mantendrá a cualquier costo la velocidad y eficiencia

• Los llamados a la base de datos y los tipos de datos tiene que ser ANSI SQL9

• La interfaz grafica e interacción con el usuario será a través de HTML.

Problemas

Como es un programa realizado por la comunidad Mundial tiene una velocidad de

desarrollo lenta y aunque es una herramienta útil, tiene varios errores por corregir en el

manejo de interfaz ya que el número de dependencias en el árbol de errores es limitado y

algunas se pierden o no son claras, la búsqueda de errores en algunas ocasiones genera

problemas en la fecha, adicionalmente existen errores en la instalación, ya que el parser de

XML no se instala correctamente, y muchos mas errores de implementación que desvirtúan

un poco la utilidad de esta herramienta.

Pero bugzilla adicionalmente a que tiene errores en la implementación, tiene deficiencias en

su arquitectura ya que no es una herramienta que esta actualizada constantemente en los

cambios que existen dentro de la base de datos de errores, además no permite la creación

dinámica de reporte de errores, y no cuenta, hoy en día, con una instalación fácil y

amigable para el usuario.

En conclusión la herramienta está hecha para ingenieros de sistemas con un alto grado de

conocimientos técnicos y no para usuarios normales.

9 ANSI SQL: lenguaje de base de datos.



16



17

DESCRIPCIÓN DE LA APLICACIÓN

Esta es un aplicación que funciona sobre Internet, permitiendo acceder a ella con un

navegador estándar, y que su funcionalidad principal es la de facilitar a los usuarios, la

comunicación de correcciones y comentarios que se hagan, entre ellos; con el fin de agilizar

los procesos de envío de documentos, relacionados con un proyecto determinado, de esta

manera un estudiante puede recibir, las correcciones que se deban hacer, y dependiendo de

su rol en el grupo de trabajo, delegar la responsabilidad de arreglarlas a otro compañero de

su grupo. El profesor, en su rol de usuario, puede crear los grupos y los proyectos que crea

pertinentes y adicionar a estos lo estudiantes, de manera que el, al recibir un documento le

haga le haga los diferentes comentarios, e inmediatamente los estudiantes se enteren y lo

corrijan.

• Para entrar al sistema, el usuario debe registrarse, para verificar su identidad y los

permisos que tiene.

• Luego de ingresar al sistema dependiendo de los privilegios que tenga el usuario, es

decir si es profesor o estudiante, se muestra un menú.



18

Ejemplo menu estudiante:

Ejemplo menú del profesor:

• El usuario puede escoger cualquiera de las opciones que se muestran, y

dependiendo de la que elija, el pantallaso tendrá diversas opciones.



19

Análisis

Usuarios del sistema:

Administrador:



20

Persona encargada de la creación y administración de los perfiles de los estudiantes en el

sistema.

Profesor:

Persona encargada de asignar los proyectos, y hacer anotaciones en los documentos

entregados.

Estudiante:

Persona que pertenece a un grupo, y que tiene un rol dentro de este, encargada de enviar

determinados documentos.

Diagrama de casos de uso

Crear Proyecto Eliminar Proyecto Modificar Proyecto

Ver Proyecto Ver Proyectos

Revisar documento

Profesor



21

Agregar usuarios

Administrador

Buscar Usuario

Agregar usuarioModificar usuario

Eliminar usuario

Consultar usuarios

Cambiar claveAutenticar

Asignar documentos a corregir

Enviar documento Ver Proyecto

Estudiante

Requerimientos funcionales

Casos de uso:

ID del Caso cu1

Nombre Crear Proyecto

Nombre de los Autores

Fecha Octubre 30 de 2002



22

Actores Profesor

Descripción Crear los proyectos, a los cuales van a pertenecer losestudiantes

Curso Básico de Eventos

Procedimiento 2.1. Curso Básico de Eventos

Ingreso al sistema: El profesor se identifica ante el sistema,con su login y password.

El sistema muestra el menú con los privilegios y opciones delprofesor.

El profesor escoge la opción de crear proyecto.

Ingreso de datos: El profesor ingresa los datos de losproyectos. Nombre y estado.

El sistema verifica que los datos coincidan con el tipo de labase de datos.

El sistema confirma la creación del proyecto.

Etapas en el Camino deExcepción

Procedimiento 2.2. Etapas en el Camino de Excepción

Los datos están incompletos

El profesor no ingresa los datos completos del proyecto

El tipo de los datos es erróneo

Al ingresar los datos, estos no coinciden con el tipo en la basede datos.

Puntos de extensiónProcedimiento 2.3. Puntos de extensión

Precondición

Poscondición

Frecuencia de Uso

Prioridad alta



23

ID del Caso cu2

Nombre Eliminar Proyecto



Actores Profesor

Descripción El profesor puede eliminar proyectos que ya no seannecesarios.





El profesor escoge la opción de eliminar proyecto.

El profesor digita el nombre del proyecto.

El sistema pregunta si realmente quiere eliminar este proyecto.

El profesor acepta el borrar el proyecto.

El sistema confirma la eliminación exitosa del proyecto.



El proyecto no existe.

Al digitar el nombre del proyecto, este no existe en la base dedatos.


Precondición

Poscondición

Frecuencia de Uso



24

Prioridad alta

ID del Caso cu3

Nombre Modificar Proyecto



Actores Profesor

Descripción El profesor puede modificar proyectos para cambiarle el estadoo el nombre.





El profesor escoge la opción de modificar proyecto.


El sistema muestra los campos que pueden ser modificados.

El profesor realiza los cambios necesarios y los envía.

El sistema confirma la las modificaciones hechas.






Precondición



25

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso cu4

Nombre Ver Proyecto



Actores Profesor

Descripción El profesor puede ver los datos de determinado proyecto.





El profesor escoge la opción de ver proyecto.


El sistema muestra todos los datos de este proyecto.






Precondición



26

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso cu5

Nombre Ver Proyectos



Actores Profesor

Descripción El profesor puede ver los nombres y el ID de todos losproyectos.





El profesor escoge la opción de ver proyectos.

El sistema muestra un listado de todos los proyectos y sus ID.



Ninguno.


Precondición

Poscondición

Frecuencia de Uso



27

Prioridad alta

ID del Caso cu6

Nombre Revisar Documento



Actores Profesor

Descripción El profesor puede revisar los documentos que le envían losestudiantes.



Ingreso al sistema: El profesor se identifica ante el sistema, consu login y password.


El profesor escoge la opción de revisar documento.

El sistema muestra los documentos pendientes por revisar y lafecha de ingreso del mismo.

El profesor escoge que documento quiere revisar.

El sistema descarga del documento en el PC del profesor.

El profesor revisa el documento y se los envía de nuevo al grupocon las anotaciones correspondientes.



Ninguno.


Precondición



28

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso cu7

Nombre Ver proyecto



Actores Estudiante

Descripción El estudiante puede ver los datos del proyecto al cual pertenece.



Ingreso al sistema: El estudiante se identifica ante el sistema, consu login y password.

El sistema muestra el menú con los privilegios y opciones delestudiante.

El estudiante escoge la opción de ver proyecto.

El sistema muestra los datos, fechas y fases de todos losproyectos a los cuales pertenece el estudiante.



Ninguno.


Precondición

Poscondición

Frecuencia de Uso



29

Prioridad alta

ID del Caso cu8

Nombre Enviar documento



Actores Estudiante

Descripción El estudiante envía los documentos de cada fase, cada vez queestén listos.



Ingreso al sistema: El estudiante se identifica ante el sistema,con su login y password.


El estudiante escoge la opción de enviar documento proyecto.

El sistema muestra los proyectos a los cuales pertenece elestudiante.

El estudiante escoge el proyecto, al cual pertenece el documentoque va a enviar.

El sistema solicita el documento que se va a enviar.

El estudiante busca en su PC el documento que va a enviar yescoge la fase a la cual pertenece.

El sistema confirma que el envió del documento fue exitoso



Error en el envió del documento.

Al intentar enviar el documento se produce un error en laconexión.



30


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso cu9

Nombre Asignar documentos a corregir



Actores Estudiante

Descripción El estudiante asigna los documentos que tienen anotaciones alos demás integrantes del grupo.



Ingreso al sistema: El estudiante se identifica ante el sistema,con su login y password.


El estudiante escoge la opción de asignar documentos.

El sistema muestra los documentos que están pendientes decorregir.

El estudiante escoge alguno de estos documentos.

El sistema muestra los miembros del grupo a los que se lespuede asignar el documento.

El estudiante escoge a uno de los miembros del grupo y le



31

asigna el documento.

El sistema confirma que la asignación fue exitosa.



Ninguno.


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso cu10

Nombre Buscar Usuario


Fecha Septiembre 3 de 2002

Actores Administrador

Descripción Buscar un usuario por tres posibles opciones.



El administrador ingresa login y clave para entrar al sistema.

El sistema muestra el menú con las opciones y privilegios deladministrador.

El administrador escoge la opción de buscar usuario.

El sistema muestra las opciones por las cuales puede buscar, queson login y nombre del usuario.

El administrador ingresa uno de los datos para hacer la



32

búsqueda.

El sistema realiza la búsqueda en la base de datos.

Resultados: El sistema muestra el usuario encontrado con todossus datos.



El usuario no esta en la base de datos

La búsqueda no arroja coincidencias de los datos


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu11

Nombre Agregar usuario




Descripción Ingresar nuevos usuarios al sistema





El administrador escoge la opción de agregar usuario.



33

El sistema muestra el formulario para llenar los datos (nombre,apellidos, login y password).

El administrador llena los datos y los envía

El sistema realiza el instert en la base de datos

El sistema notifica al administrador que el nuevo usuario fuecreado con éxito.



Los datos están incompletos

El sistema detecta que faltan por llenar campos del formulario

Los datos no corresponden al tipo de datos esperados por la basede datos

El sistema compara los datos ingresados y detecta que el tipo esdistinto al esperado por la base de datos


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu12

Nombre Modificar Usuario


Fecha


Descripción Cambiar los datos de un usuario



34





El administrador escoge la opción de modificar usuario.

El sistema muestra el formulario para llenar los datos.

El administrador modifica cualquiera de los datos del usuario(nombre, apellidos, login o password)

El sistema realiza el update en la base de datos

El sistema notifica al administrador que el cambio fue realizadocon éxito.



Los datos no corresponden al tipo de datos esperados por la basede datos

El sistema compara los datos ingresados y detecta que el tipo esdistinto al esperado por la base de datos


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu13

Nombre Eliminar Usuario




35



Descripción Cambia el estado del usuario a inactivo





El administrador escoge la opción de eliminar usuario.

El sistema pide el login del usuario a eliminar.

El administrador ingresa el login

El sistema cambia el estado del usuario en la base de datos ainactivo

El sistema notifica al administrador que el usuario fueeliminado.



El login no existe

El sistema busca en la base de datos al usuario y no loencuentra


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu14



36

Nombre Consultar Usuarios




Descripción Muestra la lista de usuarios activos en el sistema





El administrador escoge la opción de Consultar usuarios.

El sistema muestra el listado de usuarios activos.



ninguno


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu15

Nombre Agregar Usuarios





37


Descripción Se insertan varios usuarios, cargados desde un archivo XML





El administrador escoge la opción de Agregar usuarios.

El sistema pide el archivo en XML.

El administrador busca el archivo en el computador y loenvía.

El sistema confirma que se ingresaron los usuarios.



ninguno


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu16

Nombre Autenticar





38

Actores Estudiante

Descripción El usuario ingresa al sistema



El estudiante ingresa al sistema.

El sistema pide el login y la clave.

El usuario ingresa la clave y el login.

El sistema verifica los datos en la base de datos.

El usuario ingresa al menú con sus opciones y privilegios.



El login o la clave no son correctos

El sistema verifica en la base de datos y la clave y/o el loginno coinciden


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta

ID del Caso Cu17

Nombre Cambiar clave



Actores Estudiante



39

Descripción El usuario cambia su clave



El usuario ingresa al sistema con su login y password.

El sistema pide la clave antigua, la nueva y la confirmación de lanueva.

El usuario ingresa los datos que pide el sistema.

El sistema confirma el cambio de clave.



La confirmación de la clave no coincide

El sistema compara la nueva clave y la confirmación y nocoinciden

La nueva clave no cumple con las especificaciones de clave

El campo de la clave debe cumplir ciertas especificaciones, si nolas cumple el sistema avisa al usuario


Precondición

Poscondición

Frecuencia de Uso

Prioridad alta



40

Requerimientos No Funcionales

Nombre Descripción Criterio de Aceptación Tipo Escritico?

Mysql

La base de datos sobre la quedebe correr el sistema debeser gratuita como: Mysql oPostgres

La respuesta a lasconsultas debe serrápida, 3 segundos.Máximo.

necesario si

Comunicación alservidor

El sistema debe usar unprotocolo de comunicaciónbasado en XML

La comunicación debeser rápida y segura necesario si

SeguridadEl envío de datos a través dela red, hacerse de manerasegura

La aplicación debe usarsockets seguros. necesario si

PHP

La aplicación debe serdesarrollada sobre PHP, yaque es un leguaje estable yde libre uso.

El lenguaje debepermitir que los socketssean seguros, es decirSSL

necesario si

Diseño

Diseño de la aplicación

Para la implementación de la aplicación el desarrollo lo dividimos en dos partes, una de

administración, mediante el cual se crean los proyectos y los estudiantes se ingresan al

sistema con sus respectivas claves; y la otra es la que tiene toda la funcionalidad del sistema

de seguimiento de proyectos, que incluye el envío de entregables, la revisión de los mismos

y la asignación de tareas a corregir por parte del líder y los demás integrantes de los grupos.

Con el fin de desarrollar una aplicación altamente escalable, creamos tres módulos: uno de

presentación, otro de comunicación y el último de base de datos.



41

Módulo de presentación: Este módulo se encarga de la interacción con el usuario,

mostrando los distintos pantallazas de navegación y la información que el usuario solicita al

sistema.

Módulo de XML-RPC: Este módulo es el encargado de comunicar los módulos de

persentación y de Kernel, es decir envía la información al cliente para que sea mostrada a

los distintos usuarios, y cuando un usuario está haciendo uso de la aplicación, y solicita

datos o envía consultas, este módulo es el encargado de crear el mensaje y pasarlo al

módulo de Kernel.

Módulo de Kernel: Este módulo tiene como función hacer los llamados al módulo de base

de datos, para que este realice las consultas, solicitadas y devuelva la respuesta. Cuando la

base de datos responde a las solicitudes de información, el kernel, por medio del módulo de

comunicaón, envia al de presentación, para que este muestre el resultado al usuario.

Modulo de base datos: Este modulo es el encargado directo de conectarse y comunicarse

con la base de datos y responder al modulo de comunicación la consultas que este el envía,

para este modulo creamos una librería, que es la encargada de hacer las inserciones,

búsquedas y actualizaciones, en Mysql o en cualquier otro administrador de bases de datos,

16 en total: para lo cual creamos una consulta genérica, que dependiendo de la variable

base, realiza los cambios necesarios, adecuándola al lenguaje especializado de cada

administrador.

Cada vez que se hace el envío de un mensaje con un servicio requerido, entre los módulos,

el sistema para mantener la seguridad también para por parámetro un número de sesión que

se genera al ingresar al sistema con el login y password.



42

A continuación la figura de los tres módulos:

El procedimiento normal que seguiría cualquier instrucción en el diseño que planteamos

para el funcionamiento de la aplicación, y basados en el modelo anterior seria el siguiente:

Presentación

XML-RPC

Kernel

Base de datos

Módulo desarrollado en HTML yPHP, que se encarga deinteractuar con el usuario

En este punto, se realiza lacreación de los mensajes xml-rpc,para enviarlos de un módulo a otro

El kernel hace el llamado alarchivo de BD, para que este hagalas consultas a la BD.

Este módulo contiene las consultasgenéricas, para cualquier base dedatos, y se conecta con la BD.



43

Presentacion:

XML-RPC:

Kernel:

Base de datos:

BD:

Solicitud de Información Envío de mensaje xml-rpc Llamado a la consulta respectivaEnvio de Query

Respuesta

Respuesta en un String

Respuesta en mensaje xml-rpc

Información para mostrar

Diseño de la base de datos

Para la implementación de la aplicación a la cual hacemos referencia en este documento

utilizamos la base de datos Mysql; la cual escogimos por que es de libre uso para desarrollo

de herramientas. Para mantener la escalabilidad del sistema que desarrollamos, el software

fue desarrollado, de manera que se pueda utilizar varios tipos de administradores de bases

de datos, tales como Oracle, Sql, Postgres, etc., simplemente cambiando una variable global

del programa.

El diseño de la base de datos que utilizamos, para tener un rendimiento adecuado de la

aplicación, y para cumplir los requerimientos definidos, es el siguiente:



44

Usuario

#loginnombreapellidospasswordestadopermisos

Grupo

#gruponombre

Proyecto

#idnombrenumero_fasesestado

Entregable

#idnombreultimo_plazofecha_entregaversion

1

1..*1

1..*

11..*

1

1..*1

1..*

Implementación

Para la implementación del software de seguimiento de proyectos, usamos como lenguaje

de programación base PHP, el cual es software libre, es hoy en día uno de los lenguajes

modernos mas utilizados y su estabilidad sobre la red es bastante confiable, además del

crecimiento exponencial que ha tenido el desarrollo sobre este lenguaje.

El lenguaje de comunicación es XML-RPC, que es una tecnología nueva, para web services

desarrollados sobre PHP; el cual maneja sockets seguros, apoyándose en el webserver

apache que en su ultima versión ya implementa esta funcionalidad de seguridad, la

escogencia de esta nueva tecnología, además nos inclinamos por este protocolo; por que

otros lenguajes como soap, aun su especificación no esta totalmente definida, las

especificaciones del mismo aun no están estandarizadas y el manejo de los datos es

complejo; ya que tiene implementados objetos, schemas y otros, que son estructuras que no

necesitamos para las necesidades de la aplicación.

La base de datos usada fue Mysql, la cual es gratuita, y tiene la capacidad necesaria para

soportar una gran cantidad de información, sin disminuir su rendimiento, lo cual se ajusta a



45

los requerimientos universitarios, para lo cual fue diseñada la aplicación, agregando que su

instalación es sencilla, tanto en ambientes Windows como linux.



46

CONCLUSIONES

Logramos establecer un protocolo de comunicación para web services, el cual no depende

de la plataforma sobre la que corre, por lo tanto funciona sobre windows y linux. También

se logro, que el lenguaje sobre el que esta escrita la aplicación, no afectara los servicios que

este tiene y que la base de datos fuera totalmente independiente del desarrollo, permitiendo

el uso de casi cualquier base de datos, incluyendo las mas conocidas y comerciales que hay

en el mercado.

Para fines educativos, creamos un producto totalmente libre, excepto por los derechos de

autor; ya que fue montado totalmente con herramientas de uso libre, como: php, mysql,

xml-rpc, montado sobre Internet, lo que demuestra que no es necesario grandes inversiones

de dinero, para la creación de software de calidad y de alta funcionalidad.

Exploramos en nuevas tecnologías, para la creación de web services, desarrollando un web

service en php, lo cual es un campo poco explorado, con muy pocas aplicaciones, que

tengan la documentación adecuada, avanzando en este campo de manera significativa,

dejando una base para futuras aplicaciones.

Basados en la actualidad que esta viviendo el mundo, la globalización y la era de la

información, creamos un producto que se adecua a las necesidades actuales, de estudiantes

y de profesores; el cual funciona sobre Internet, proporcionando inmensas facilidades de

uso y de acceso desde cualquier lugar del mundo, además de tener una interfaz grafica

amable, incursionando en nuevos campos de la programación basada en html, explotando

todas las funcionalidades que este medio y leguaje nos proporciona.

El desarrollo de nuevas aplicaciones implican un alto grado de escalabilidad, ya que

siempre es necesario dejar abierto el software a la posibilidad de agregar nuevas

funcionalidades, lo cual se logra mediante la creación de módulos y capas de desarrollo.

También es importante que esta escalabilidad sea tan poderosa, en caso de que las versiones

del lenguaje sobre el que esta creado cambie, es decir, si decidimos cambiar la versión del

interpretador de PHP de nuestro servidor, el cambio en el software no sea dramático, sino



47

que la complejidad del mismo sea la de reemplazar una variable, lo cual aplica de igual

manera para el manejador de la base de datos o la base de datos en si.

Por ultimo es importante que el software que uno desarrolle se pueda integrar con otras

aplicaciones, con el fin de que varios ingenieros puedan trabajar en distintos módulos de

una aplicación grande, y luego la integración de estos no sea un procedimiento traumático,

incluyendo el caso en que estos estén desarrollados en lenguajes diferentes.

Para la aplicación que desarrollamos queda faltando la integración de otros módulos, como

el de envío de documentos, el cual puede ser adicionado facilmente, gracias al diseño de la

herramienta.



48

ANEXOS

Anexo 1.

Manual de instalación

Prerrequisitos básicos para la instalación

Intel x86 procesador, 200 Mhz (o mas rápidos).

Sistema operativo windows 95 (o versiones avanzadas) o Linux Versión Red Hat 8.0 (o

mejor) o otras versiones con el mismo Kernel.

45 MB libres en disco duro.

Instalado el servidor de HTTP APACHE versión 2.0.42.

Instalado PHP versión 4.2.3.

Instalación de la base de datos MySQL versión 3.23.53

Instalación del programa SISPRO.

Instalación del programa SISPRO:

1. Copiar en la carpeta de /htdocs del apache (Windows) o www/html (linux) , la

carpeta del programa completo.

2. Antes de utilizar el programa SISPRO, el usuario debe tener en cuenta que tiene

que tener funcionado la base de datos y el apache para lograr acceder al programa

debidamente.

3. Asegurarse que el apache este configurado para correr como localhost , y luego

abrir en el explorador la siguiente pagina:

http://localhost/SISPRO/setup.php

En donde se creara la base de datos y sus datos iniciales, tales como el usuario

administrador. Si se quiere mirar cuales son los scripts que son necesarios para

correr dentro de la base de datos se puede mirar el archivo:



49

Carpeta de htmls del apache/SISPRO/sql.sql

4. Abrir en el explorador de la pagina del proyecto, para utilizar el programa.

http://localhost/SISPRO1.0.9/cliente/main.php

para comodidad del usuario se le sugiere que esta pagina sea incluida en favoritos

para su mejor uso.

Instalación del servidor de HTTP APACHE versión 2.0.42

1. Lo primero es tener los instaladores de la aplicación que se puede acceder en la

dirección:

http://www.php.net/get_download.php?df=php-4.2.2-Win32.zip

2. Durante la instalación el programa preguntara por la información del servidor donde

se debe completar lo siguiente:

Server Name: localhost

3. Luego terminar la instalación normal del programa, teniendo en cuenta que para su

mínima instalación se requiere 28 MB en disco duro.

Instalación de PHP

1. Lo primero es tener los instaladores de la aplicación que se puede acceder en la

dirección:

http://www.php.net/get_download.php?df=php-4.2.3-Win32.zip

http://www.php.net/get_download.php?df=php-4.2.3-installer.exe



50

2. Correr el instalador de la aplicación y tener en cuenta que se deben realizar cambios

en el php.ini, los cuales están explicados y documentados en el readme.txt de la

aplicación.

Instalación de MySQL

Lo primero es tener los instaladores de la aplicación que se puede acceder en la dirección:

http://www.mysql.com/Downloads/MySQL-3.23/mysql-3.23.53-win.zip(13.3) MB

Y seguir todos los pasos de la instalación en el cual hay que tener en cuenta para luego

saber cuales son los cambios que son pertinentes en el php.ini, para que php puede utilizar

la base de datos.

PHPTRIAD

Una opción para instalar los programas adicionales que se requieren para que funcione

SISPRO, es instalar el programa phptriad versión 2.11 el cual instala y configura

automáticamente todas estas herramientas. Este programa se encuentra en la siguiente

dirección:

http://prdownloads.sourceforge.net/phptriad/phptriadsetup2-11.exe



51

Anexo 2

Manual del usuario

La idea es separar en tres roles de usuario a los usuarios en general del programa, primero

hay un administrador el cual crea las cuentas que usaran los usuarios (Profesor y alumnos)

y este a su vez puede crear cuentas de administrador.

Para iniciar el programa se debe ejecutar en el explorador el siguiente URL en el cual se

entrara a la pagina principal de programa:

http://localhost/SISPRO1.0.9/cliente/main.php

NOTA: Para que el programa funciona se debe tener ejecutando el APACHE y MySQL.

El usuario que será el administrador debe entrar al sistema con los siguientes datos:

Usuario : admin

Password : admin

Crear las cuentas de todos los usuarios del programa y definir a cada uno el rol que tiene

como usuario para el sistema. Para realizar esta actividad el administrador cuenta con las

siguientes opciones:

• Agregar Usuario

• Eliminar Usuario

• Modificar Usuario

• Mostrar Usuario

• Buscar Usuario

• Cambiar Clave



52

Es recomendable cambiar la clave del administrador por seguridad del sistema.

El usuario con el rol de profesor podrá ingresar con su a su cuenta y tendrá las opciones:

• Crear un proyecto

• Asignar grupo de trabajo a un proyecto

• Mostrar estado de proyecto

• Mostrar datos de un proyecto

• Realizar revisiones pendientes

Con las cuales podrá realizar el seguimiento de los proyecto que tiene a cargo.

El usuario con el rol de estudiante podrá ingresar con su cuenta y tendrá las siguientes

opciones:

• Ver datos del proyecto

• Mostrar estado del proyecto

• Realizar entrega de documento

Con las cuales podrá realizar el desarrollo de un proyecto, recibir las notificaciones y

comentarios a sus entregas realizadas. Adicionalmente si es director del proyecto tendrá la

opción de definir quien del grupo debe responder las correcciones determinas por el

profesor.



53

Anexo 3.

Ejemplo XML-RPC:

Request

La siguiente descripción realiza un pedido por parte del cliente al web service “examples” y

cuya función requerida es “getStateName”, a la cual se le envía el parámetro entero 41.

Esto es solo un ejemplo sencillo sobre como se realiza un requerimiento a un web service a

una función especifica con parámetros, por medio del protocolo XML-RPC por parte del

cliente.

<i4> significa valor entero

POST /RPC2 HTTP/1.0

User-Agent: Frontier/5.1.2 (WinNT)

Host: betty.userland.com

Content-Type: text/xml

Content-length: 181

<?xml version="1.0"?> //**Versión de XML que se esta usando

<methodCall> //**Inicio del llamado

<methodName>examples.getStateName</methodName> //** Nombre del método

<params>

<param>

<value>

<i4>41</i4> //**Valor entero = 41

</value>

</param>

</params>



54

</methodCall>

La primera línea puede ir vacía solo especificada por un slash, pero esto es solo cuando el

servidor únicamente esta manejando request en XML-RPC, lo cual se especifica cuando el

servidor esta configurado para manejar varios tipos de request.

Respuesta normal

HTTP/1.1 200 OK //**Respuesta del servidor normal

Connection: close

Content-Length: 158


Date: Fri, 17 Jul 1998 19:55:08 GMT

Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?>

<methodResponse> //**Inicio de la respuesta

<params>

<param>

<value><string>Valor ingresado correctamente</string></value>

</param>

</params>

</methodResponse>

Ha menos de que exista un error de bajo nivel simpre retornara HTTP/1.1 200 OK



55

Respuesta anormal

HTTP/1.1 200 OK

Connection: close

Content-Length: 426


Date: Fri, 17 Jul 1998 19:55:02 GMT

Server: UserLand Frontier/5.1.2-WinNT

<?xml version="1.0"?>

<methodResponse>

<fault> //** Inicio de la respuesta anormal del servidor

<value>

<struct>

<member>

<name>faultCode</name>

<value><int>4</int></value>

</member>

<member>

<name>faultString</name>

<value><string>Too many parameters.</string></value>

</member>

</struct>

</value>

</fault>

</methodResponse>



56

Anexo 4.

Funcionamiento de la aplicación

La aplicación tiene como objetivo el seguimiento de proyectos en red, de manera que en la

primera etapa el profesor pueda crear proyectos y además adicionar las fases que este

tendrá, adicionalmente el profesor tiene que seleccionar o aceptar los estudiantes a trabajar

en el proyecto durante el semestre.

La aplicación después de su “configuración” permite dos funcionalidades básicas que son:

entregas de los documentos por parte de los estudiantes y entregas de las correcciones por

parte del profesor, por otro lado lleva un monitoreo de todas las actividades para mantener

un nivel de control y seguridad.

Uno de los puntos mas amigables para los usuarios de la aplicación es que cuando se

realizan entregas, la aplicación genera un mensaje por correo a los interesados sobre la

actividad que se realizó, y adicionalmente en la pagina principal de cada usuario son

publicadas las actividades por realizar y el estado del proyecto.

Anexo 5.

COMO SE PUBLICAN LOS SERVICIOS

La publicación de los servicios se realiza a través de la función xmlrpc_server de XML-

RPC y la cual es explicada a continuación:

Primero se genera una variable con la documentación del servicio que en el ejemplo es

autenticar:

• $autenticar_doc=' Autentica dentro del sistema a un usuario, teniendo como

parametros de entrada login , password y si son validos retorna un numero de

sesión';



57

• Luego es generada la variable que contiene el arreglo de los servicios del web

service y en esta se especifica el nombre de la función dentro de la aplicación que

atenderá los requerimientos del servicio y la documentación del servicio en

particular:

o $map = array ("autenticar" => array( "function" => "autenticar", "docstring"

=> $autenticar_doc))

• Por ultimo se crea el web service con la función xmlrpc_server en donde entra como

parámetros el arreglo de los servicios del web service:

o $s=new xmlrpc_server( $map );



58

BIBLIOGRAFIA

XML-RPC

XML-RPC.ORG. XML-RPC Specification. [en linea]. Tue, Jun 15, 1999; by Dave Winer. <http://www.xmlrpc.org/spec>

[Octubre 2002]

Dave Winer. XML-RPC for Newbies. [en linea]. Tue, Jul 14, 1998; by Dave Winer.

<http://davenet.userland.com/1998/07/14/xmlRpcForNewbies>. [Agosto 2002]

Eric Kidd. XML-RPC HOWTO. [en linea]. 2001 by Eric Kidd <http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-

howto.html>. [Agosto 2002]

Kate Rhodes. XML-RPC vs. SOAP. [en linea]. 2001 by kate rhodes <http://weblog.masukomi.org/writings/xml-

rpc_vs_soap.htm>. [Septiembre 2002]

WEB SERVICE

W3C. Web Services Architecture. [en linea]. 14 November 2002. <http://www.w3.org/TR/2002/WD-ws-arch-

20021114/>. [Diciembre 2002]

W3C. Web Services Architecture. [en linea]. 14 November 2002. <http://www.w3.org/TR/2002/WD-ws-gloss-

20021114/>. [Diciembre 2002]

Sahil Gambhir and Michael W. Muchmore . Secret Services. [en linea]. November 13, 2001. PC Magazine.

<http://www.pcmag.com/article2/0,4149,154702,00.asp>. [Noviembre 2002]

Sarah L. Roberts-Witt. Web Services Warm Up [en linea]. June 30, 2002. PC Magazine.

<http://www.pcmag.com/article2/0,4149,22251,00.asp>. [Diciembre 2002]

BUGZILLA

Mozilla.org. What is Bugzilla?. [en linea]. Last modified Agosto, 2002

<http://www.mozilla.org/projects/bugzilla/about.html>. [Agosto 2002]

Mozilla.org. Bugzilla Development Roadmap. [en linea]. Agosto, 2002.

<http://www.mozilla.org/projects/bugzilla/roadmap.html>. [Septiembre 2002]

XML-RPC y PHP



59

Vikram Vaswani, XML and PHP, 1st edition (July 15, 2002), Que .

Luis Argerich, Chris Lea, Ken Egervari, Matt Anton, Chris Hubbard , James Fuller, Charlie Killian, Professional PHP4XML, 1st edition (June 2002), Wrox Press Inc

SISTEMA DE SEGUIMIENTO DE PROYECTOS

Documents

Transcript of SISTEMA DE SEGUIMIENTO DE PROYECTOS