DISEO E IMPLEMENTACION DE UN SISTEMA DE ADMINISTRACION PARA LA ACTIVACION Y SEGUIMIENTO DE CLIENTES DE HOSTING Y DOMINIOS PARA IMAGINAMOS.

COM

PRESENTADO POR: JAIRO ENRIQUE CELIS CARRILLO

UNIVERSIDAD DISTRITAL FRANCISCO JOS DE CALDAS FACULTAD DE INGENIERA PROYECTO CURRICULAR DE SISTEMAS BOGOT D.C. 2011

DISEO E IMPLEMENTACION DE UN SISTEMA DE ADMINISTRACION PARA LA ACTIVACION Y SEGUIMIENTO DE CLIENTES DE HOSTING Y DOMINIOS PARA IMAGINAMOS.COM

Presentado Por: JAIRO ENRIQUE CELIS CARRILLO COD 20022020160

Proyecto de pasanta

FERNANDO MARTINEZ RODRIGUEZ Director Interno JOSE JAIR BONILLA Director Externo

UNIVERSIDAD DISTRITAL FRANCISCO JOS DE CALDAS FACULTAD DE INGENIERA PROYECTO CURRICULAR DE SISTEMAS BOGOT D.C. 2011

TABLA DE CONTENIDO

INTRODUCCION.........................................................................................9 CAPITULO I PROBLEMA DE INVESTIGACION.....................................11 1. FORMULACION DEL PROBLEMA.....................................................11 1.1. DESCRIPCION DEL PROBLEMA....................................................12 1.2. FORMULACION DEL PROBLEMA..................................................12 2. JUSTIFICACION...................................................................................14 3. OBJETIVOS..........................................................................................16 3.1. OBJETIVO GENERAL......................................................................16 3.2. OBJETIVOS ESPECIFICOS..............................................................16 4. ALCANCES Y LIMITACIONES............................................................17 4.1. ALCANCE..........................................................................................17 4.2. LIMITACIONES.................................................................................17 5. FACTORES DIFERENCIALES O DE VALOR AGREGADOS DE LA PROPUESTA.............................................................................................19 CAPITULO II MARCO TEORICO DEL PROBLEMA A INVESTIGAR.....20 6. ASPECTO GENERALES.....................................................................20

7. MARCO REFERENCIAL......................................................................22 8. MARCO TEORICO...............................................................................26 8.1. SERVICIOS WEB..............................................................................26 8.2 SERVIDOR WEB................................................................................30 8.3. APACHE............................................................................................31 8.4. MySQL...............................................................................................33 8.5. PHP....................................................................................................34 8.6. SOFTWARE LIBRE...........................................................................35 8.7. METODOLOGIA DE PROGRAMACION XP....................................36 9. MARCO METODOLOGICO.................................................................40 9.1. TIPO DE ESTUDIO............................................................................40 9.2. METODO Y/O DISEO DE LA INVESTIGACION............................41 9.3. PARTICIPANTES..............................................................................43 9.4. RECURSOS.......................................................................................44 9.5. INSTRUMENTOS Y EQUIPOS.........................................................45 9.6. INGENIERIA DEL PROYECTO.........................................................45

10. RESULTADOS OBTENIDOS.............................................................51 10.1. FASE DE PLANIFICACION.............................................................51 10.2. FASE DE DISEO............................................................................54 10.3. FASE DE DESARROLLO................................................................57 10.4. FASE DE PRUEBAS........................................................................58 11. RECOMENDACIONES PARA PROYECTOS FUTUROS..................63 12. CONCLUSIONES................................................................................64 13. BIBLIOGRAFIA..................................................................................65 13.1. REFERENCIAS ELECTRONICAS...................................................65 ANEXOS....................................................................................................68

ANEXOS

ANEXO A: Mockups de diseo. ANEXO B: Formato de revisin de cdigo. ANEXO C: Formato de prueba Beta y pruebas de funcionalidad. ANEXO D: Manual de Usuario.

LISTA DE TABLAS

TABLA 1. Recurso Tecnolgico.................................................................45 TABLA 2. Formato Revisin de Cdigo.....................................................61 TABLA 3. Formato Prueba Beta................................................................63 TABLA 4. Formato de Pruebas de Funcionalidad.....................................63

LISTA DE FIGURAS

INTRODUCCION

La compaa Imaginamos.com es una empresa de diseo y desarrollo de sitios web, y aplicaciones en lnea, con su sede principal en Bogot D.C (Colombia), ampliando su plan de negocios a Estados Unidos y Espaa.

Debido al alto grado de publicidad y marketing que la Gerencia General implemento durante el ltimo ao, y el reconocimiento como consecuencia directa de este plan ha logrado que las ventas en hosting y registro de dominios crezcan en un 300% desde finales de 2008 y principios de 20101, por esta razn la creacin de un Departamento de Soporte Hosting y Dominios fue necesario como reaccin de manera anticipada a los cambios que en su interior han surgido.

El Departamento de Soporte Hosting y Dominios est encargado de brindar ayuda a los clientes en la compra, activacin e implementacin de su espacio de hosting y registro de dominios, brindando una plataforma solida de tecnologas de informacin enfocadas al usuario final.

En la actualidad se hace necesario que de la misma forma como la compaa en general est enfocando sus esfuerzos en la organizacin de los procesos, el Departamento de Soporte Hosting y Dominios est en la misma lnea, por esta razn el fin primordial del desarrollo de este trabajo de pasanta es el diseo e
1

Gerencia General Imaginamos.com

implementacin de un sistema de administracin para la activacin y seguimiento de clientes de hosting y dominios que reemplace al actual y cree una lnea de comunicacin ms directa con los usuarios, a travs del aprovechamiento de la infraestructura tecnolgica que tiene Imaginamos.com.

La metodologa utilizada para la elaboracin de este proyecto est basada en la metodologa XP, donde su principal beneficio es contar con el usuario final dentro del equipo de trabajo, adems de partir de sus recomendaciones para las buenas prcticas de desarrollo de software, con lo cual se logra brindar una solucin dinmica y flexible al problema del sistema de administracin actualmente utilizado en la organizacin.

10

Captulo I PROBLEMA DE INVESTIGACIN FORMULACIN DEL PROBLEMA

1.1 Descripcin del problema A causa del crecimiento en el nmero de clientes en poco tiempo, se origin un caos en la administracin de los clientes de hosting y registro de dominios, atencin de los requerimientos de los usuarios, el tiempo de respuesta hacia los clientes se incremento y el manejo de estadsticas en el acuerdo de nivel de servicio2 se hizo difcil de consolidar, dificultando la tarea de los colaboradores y siendo una de las razones para cometer errores en las soluciones a usuario final.

Actualmente para llevar el registro y administracin de la activacin de hosting y registro de dominio se cre una base primaria en Microsoft Access, donde la persona encargada debe llenar algunos datos acerca de la activacin y el cliente como Fecha de activacin, fecha de pago, Nombre de Dominio, Referencia de Pago, Nota, Dominio, Hosting (Plan de hosting que activa), Servidor (Se cuenta con 5 servidores, se especifica donde se activa), NIT CC, Empresa o Razn Social, Telfono 1, Telfono 2, Direccion, Ciudad, Cliente Encargado, E-mail 1, Email2; esta forma de llevar registro de la informacin genera entre otros problemas:

Acuerdo de Nivel de servicio: SLA por sus siglas en ingles es una parte de un contrato de servicio donde el nivel de servicio formalmente es definido. http://en.wikipedia.org/wiki/Service_level_agreement [Citado el: 3 de Abril de 2010]

11

* Errores en la entrada de los datos: Mala precisin principalmente de los datos de contacto del cliente. * Errores de precisin en el vencimiento: En ocasiones se le informa al cliente una fecha de vencimiento de sus servicios y se registra una fecha diferente, ocasionando malestar entre los clientes. * Errores de formato de fecha: El formato de fecha establecido en la bitcora est basado en DD-MM-AAA, lo que origina que en ocasiones se digite la fecha en otros formatos creando inconsistencias. * Demora en la actualizacin de la base: Debido a que constantemente se estn atendiendo activaciones, en algunos casos la persona encargada de la actualizacin de la base no digita a tiempo, ocasionando que en un momento dado no se tenga la informacin actualizada de las activaciones de hosting y registro de dominios.3 Lo anterior lleva a tener problemas en la consolidacin de estadsticas de servicio, pues son errores que no permiten tener una informacin oportuna, veraz y creble, que pueda ser presentada a la Gerencia General, y demostrar la seriedad y responsabilidad del Departamento de Soporte Hosting y Dominios.

1.2 Formulacin del problema El Departamento de Soporte Hosting y Dominios actualmente tiene a su cargo alrededor de 1500 Clientes a nivel nacional e internacional y esta cifra cada da crece, por otro lado semanalmente se debe entregar informes a Gerencia General de las activaciones y renovaciones de clientes en los diferentes servicios que
3

Anlisis por parte de Simon Borrero Gerente General Imaginamos.com

12

ofrece Imaginamos.com, sin una organizacin en la base de clientes este informe se convierte en algo tedioso y difcil de consolidar, generando errores en la informacin enviada a Gerencia y dificultando la tarea de la actualizacin de la base de clientes.

El envo de mensajes recordatorios de renovacin a los clientes que se les ha cumplido el tiempo adquirido con la compaa en sus servicios, se hace de forma manual, ocasionando que por la falta de informacin de contacto de algunos clientes, debido a que no se tiene un orden en el registro de las diferentes activaciones, no se les pueda notificar de su vencimiento, ocasionando de esta manera que algunos clientes vean su sitio suspendido y por ende se molesten por no ser contactados a tiempo para evitar este tipo de inconvenientes

Cmo disear e implementar un sistema informtico que logre consolidar todos los registros de las activaciones de hosting y registro de dominios hechos por los usuarios sin importar el lugar geogrfico, que permita obtener mayor control, seguimiento e informacin de los clientes?

13

1. JUSTIFICACIN

El Departamento de Soporte Hosting y Dominios, debe presentar regularmente estadsticas de servicio, renovacin y, activacin de hosting y registro de dominios, por esta razn debe existir un mecanismo claro y preciso que permita beneficiar a todos los involucrados, esto es un Sistema de Administracin va web, de esta forma todos logran mayor beneficio, los usuarios al tener una respuesta inmediata a sus requerimientos e inquietudes, el Departamento de Soporte Hosting y Dominios al poder llevar de forma precisa un sistema de administracin de clientes, en el cual se conozca de forma precisa las activaciones de los servicios de los cliente, y la Gerencia General de la compaa al tener informes reales y claros que evidencian la responsabilidad del Departamento Soporte Hosting y Dominios.

Para alcanzar esta meta fue necesario implementar un Sistema de Administracin va Web, donde se poda tener mayor organizacin en las diferentes activaciones de hosting y registro de dominio, envo de informes semanales y datos de contacto de los clientes del Departamento de Soporte Hosting y dominios.

Con esta solucin el Departamento de Soporte Hosting y Dominios se organiz y logr dar un nivel de servicio muy alto, donde los clientes lograron obtener soluciones rpidas y efectivas, la Gerencia General logr obtener informes reales y a tiempo; por otro lado el ambiente en el Departamento de Soporte Hosting y

14

Dominios mejor al disminuir los niveles de presin que se ocasionaban por la mala administracin de las activaciones, as como los problemas originados por la falta de datos de contacto de los clientes que ocasionaban la suspensin de los servicios.

15

OBJETIVOS 3.1 OBJETIVO GENERAL Disear e implementar un sistema web de administracin, para la activacin y seguimiento de clientes de hosting y dominios para Imaginamos.com, que permita obtener mayor control, seguimiento e informacin de los clientes y las estadsticas de activacin y renovacin de los servicios. 3.2 OBJETIVOS ESPECFICOS Disear un modulo que genere reportes, los cuales permitan el anlisis de sus servicios en la activacin de servicios de hosting y dominios, para la toma de decisiones en marketing, dirigidos a aumentar el nmero semanal de activaciones. Disear una interfaz de manejo intuitivo y amigable, donde se lleve un orden en las activaciones de los clientes, datos de contacto e informacin importante para el Departamento de Soporte Hosting y Dominios. Definir una arquitectura de informacin ordenada y con diferentes formas de acceso, poniendo nfasis en la usabilidad y el uso estndares internacionales de desarrollo web. Reforzar el rea de informacin contingente (activaciones y datos de contacto) con reportes, envo de ventanas de mantenimiento, de acuerdo a la comunicacin con los clientes.

16

2. ALCANCES Y LIMITACIONES 4.1 ALCANCE El sistema de administracin para la activacin y seguimiento de clientes de hosting y dominios para Imaginamos.com brinda la informacin necesaria en aspectos como: Fecha de Activacin, Fecha de Pago, Nombre del dominio, Referencia de Pago, Plan de Hosting, Servidor de activacin, Nit CC, Nombre o Razn Social, Telfono 1, Direccion, Ciudad, Cliente encargado, E-Mail. El proyecto se entrega con el cdigo fuente, el cual posee licencia GNU GPL, esto quiere decir que El autor conserva los derechos de autor (copyleft), y permite la redistribucin y modificacin bajo trminos diseados para asegurarse de que todas las versiones modificadas del software permanecen bajo los mismos trminos4; manual de usuario, actas de aprobacin firmadas al momento de las pruebas por parte del usuario final. El sistema resultante se mont en el Hosting de la compaa y all queda bajo la administracin del Departamento de Soporte Hosting y Dominios5.

4.2 LIMITACIONES Las limitaciones que se encontraron en el momento del desarrollo de este proyecto de pasanta fueron las siguientes:

La visualizacin correcta de la aplicacin depende de las versiones de los navegadores, aunque esto fue independiente de la plataforma de Sistema

http://es.wikipedia.org/wiki/C%C3%B3digo_libre#Licencias_GPL [Citado el: 3 de Abril de 2010] SOFTWARE LIBRE 5 http://www.imaginamos.com/sacgydo/ [Citado el: 8 de Mayo de 2011] DISEO DE PAGINAS WEB Y SOFTWARE WEB DESDE COLOMBIA

17

Operativo donde estn montadas, se sugiri que se utilizara las ltimas versiones de los navegadores actuales. La disponibilidad de tiempo del Departamento de Soporte Hosting y Dominios, quienes por su trabajo habitual demoraron el desarrollo, las pruebas y aceptacin del sistema implementado. Se dependi de la informacin inicial de contacto que los clientes brindaban en el momento de su activacin, por lo que en ocasiones la informacin no era completa y era necesario contactarlos de nuevo para complementar esta informacin.

18

3. FACTORES DIFERENCIALES O DE VALOR AGREGADO DE LA PROPUESTA

Esta implementacin de un sistema de administracin para la activacin y seguimiento de clientes de hosting y dominios, fue una puesta en prctica de lineamientos bien definidos para lograr que los tiempos de activacin fuesen ms cortos, el conocimientos de los clientes de Imaginamos.com pudiera ser ms amplio y se lograra el objetivo de aumentar el nivel de servicio.

Por ser un desarrollo a la medida logr diferenciarse de software genricos, que limitaban, por su cantidad de herramientas llegar a la informacin importante, adems que esta herramienta es modular, lo que permiti que en el futuro, de ser necesario pueda seguir puntualizndose hacia los requerimientos del

Departamento de Soporte Hosting y Dominios, y la compaa en General.

19

Captulo II MARCO TEORICO DEL PROBLEMA A INVESTIGAR 4. ASPECTOS GENERALES

Imaginamos.com nace de la iniciativa de su actual Gerente General, Simon Borrero Posada, quien es graduado de Administracin de Empresas de la Universidad de los Andes.

Su anhelo de construir una empresa solida dirigida hacia servicios de internet hace que en el ao 2007 inicie labores Imaginamos.com, su enfoque fue hacia el diseo y desarrollo de pginas web, enfocado en empresas de reconocimiento nacional entre las que se puede contar, Alcalda de Palmira, Alcalda Menor de Tunjuelito, Meals de Colombia, Frito Lay, Hoteles Dann Carlton, Teletn Colombia, entre otros.

A finales del ao 2008 se comenz la comercializacin de servicio de hosting y dominios, logrando que en un ao se logre la cifra de cerca de 800 clientes satisfechos6 en estos servicios, no se tena en Abril de 2009 un Departamento que se encargara de las activaciones y seguimiento de los clientes, lo que impulso la necesidad de crear un Departamento especializado en este tema.

http://www.imaginamos.com [Citado el: 28 de Abril de 2010] DISEO PAGINAS WEB A LA MEDIDA

20

En este momento uno de los principales motivos que tiene el Departamento de Soporte Hosting y Dominio, es fidelizar a sus clientes y aumentar el nmero de activaciones nuevas en hosting y dominio, para lo cual se buscaba consolidar herramientas que facilitaran esta tarea.

21

5. MARCO REFERENCIAL Actualmente, las organizaciones empresariales de servicios ven la necesidad de construir medios, a travs de los cuales puedan evidenciar de forma clara las necesidades y opiniones de sus usuarios, la tecnologa les est dando da a da mecanismos en los cuales basarse y conseguir este objetivo.

Dentro del servicio al cliente se encuentran los niveles de servicio que la empresa debe alcanzar y en los cuales todos sus esfuerzos se enfocan, de esta manera encontramos diversos medios de conseguir la comunicacin desde y hacia los usuarios, que permitan conocer de forma clara las expectativas y conclusiones de los principales clientes. Las empresas privadas, ms que las del estado en

nuestro pas, toman muy en serio la forma como los usuarios se sienten con el servicio que ellas ofrecen, para estas empresas una parte de la publicidad se basa en dar buen servicio al cliente, segn la filosofa existente en este aspecto, un usuario satisfecho trae consigo muchos usuarios mas; sin embargo un usuario molesto con el servicio puede llevarse consigo muchos ms potenciales usuarios, por esta razn el enfoque es darse a conocer como empresas que consiguen satisfacer las necesidades y expectativas.

Las empresas de servicios son las que ms buscan tener un registro de todas las incidencias, su solucin y tiempo invertido, adems de llevar una evaluacin por parte del usuario de la respuesta dada, a partir de datos como estos logran

22

consolidar estadsticas de servicio y compararlas con la curva de Nivel de Servicio establecida, de esta forma reorientan sus actividades e idean nuevos mtodos de respuesta para aumentar la buena imagen hacia los usuarios; sin embargo, se encuentra que la mayora de las empresas colocan en manos de terceros esta responsabilidad, debido a que segn las cifras es mejor pagar un outsourcing que tener un departamento interno dedicado por completo a resolver incidencias.

En el pasado el Departamento de Soporte Hosting y Dominios, manejaba su registro de activaciones de hosting y dominios, de forma manual, esto era una tabla de Access similar a un hoja de clculo en Excel, donde se registraba cada activacin de hosting que se realizaba en el da y el registro del dominio, no exista una metodologa y procedimiento en el registro de estas activaciones, la mayora de las ocasiones al finalizar el da no se contaba con la totalidad de los datos de contacto de los clientes, as como se haca difcil el envo de notificaciones a los clientes del vencimiento de sus servicios con la compaa, por la falta de consolidacin de datos de contacto de los clientes.

Actualmente en el mercado existen mltiples soluciones para registrar y tener seguimiento de sus clientes, incluso algunas empresas han desarrollado sus propias soluciones, y por ende son soluciones privativas, costosas y poco adaptadas a las necesidades propias de la empresa, son las empresas en este caso quienes se deben adaptar a estas aplicaciones, por este motivo no se conoce el funcionamiento, los mdulos que pueden tener y la flexibilidad con que

23

se desarroll, por esta razn, una documentacin libre que pueda dar alguna direccin no existe, solo con el comienzo de la acogida del software libre se est intentando iniciar la documentacin propia del tema en esta rea en particular.

Podemos encontrar, que en el mercado existen muchas opciones de software basado en relacin con los clientes (CRM, Customer Relationship Management, por sus siglas en Ingles), entre las cuales podemos encontrar por ejemplo PeopleSoft, el cual segn las caractersticas descritas permite llevar registro de los clientes e identificar a los clientes que realmente estn interesados en interactuar con la compaa y cules no desean hacerlo7. Sin embargo esta solucin solo est encaminada a la relacin con los clientes, desde un enfoque de mercadotecnia, lo cual no es el objetivo del desarrollo que se desea, sin contar con la licencia que se debe pagara Oracle por la utilizacin de esta aplicacin. Dentro de las herramientas de cdigo libre, se encuentra SugarCRM 8, sta herramienta se enfoca en el seguimiento de clientes pero se aleja de los propsitos del Departamento de Soporte Hosting, debido a que es una herramienta desde el punto de vista del Departamento Comercial y se maneja para llevar el registro de ventas potenciales, esta herramienta presenta un desarrollo en cdigo abierto bastante robusto y esto hace que la parametrizacin a las necesidades propias de las empresas no se pueda realizar de buena forma, por lo que son stas ltimas quienes deben seguir los parmetros de esta
7

http://www.oracle.com/global/lad/applications/peoplesoft-enterprise.html [Citado el: 9 de Marzo de 2010] PEOPLESOFT ENTERPRISE 8 http://www.sugarcrm.com/crm/ [Citado el: 9 de Marzo de 2010] SUGARCRM COMMERCIALOPEN SOURCE CRM

24

herramienta, tienen un foro para la comunidad donde se expresan dudas y a partir de la experiencia de los usuarios son ellos mismos los que responden las incertidumbres de los dems, si se solicita soporte oficial por parte de SugarCRM, ste soporte tiene un costo.

Como se observa, las anteriores aplicaciones daban un buen campo de anlisis y desarrollo de nuevas aplicaciones para sistema de incidencias IT.

25

6. MARCO TERICO Toda la informacin disponible para cualquier persona, en cualquier lugar, a travs de cualquier dispositivo.9 Para el desarrollo del proyecto se tomaron aspectos y referencias claras de las herramientas que se utilizarn para lograr el fin establecido, el diseo e implementacin de un sistema de administracin para la activacin y seguimiento de clientes de hosting y dominios para Imaginamos.com

6.1 SERVICIOS WEB Se debe tener un concepto claro a trabajar y es Servicio Web, que segn la W3C 10 lo define como un sistema de software diseado para soportar interaccin interoperable mquina a mquina sobre una red11 basndose en el protocolo http12; la importancia de este concepto hoy en da, est basado en la potente masificacin que ha tenido internet y en el impacto que las tecnologas de informacin estn causando en la forma de vida de las personas, en el comercio y en las comunicaciones, cambindolas de forma rotunda, bajo este escenario, es cada vez mayor la necesidad de poder integrar y compartir informacin entre diferentes plataformas de software y hardware, originando de esta forma los actualmente llamados servicios Web.
9

http://www.desarrolloweb.com/articulos/1535.php [Citado el: 3 de Abril de 2010] SERVICIOS WEB EN PLATAFORMA .NET 10 W3C:World Wide Consortium, por sus siglas en ingles. 11 W3C Consortium. Web Services Architecture. [En lnea] 11 de Febrero de 2004. [Citado el: 28 de Marzo de 2010.] http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis. 12 HTTP. HyperText Transfer Protocol, por sus siglas en ingls.

26

Los Servicios Web implementan algunos estndares establecidos firmemente hoy da, por nombrar algunos: Web Services Protocol Stack: As se denomina al conjunto de servicios y protocolos de los servicios Web. XML (Extensible Markup Language): Es el formato estndar para los datos que se vayan a intercambiar. SOAP (Simple Object Access Protocol) o XML-RPC (XML Remote Procedure Call): Protocolos sobre los que se establece el intercambio.13

La profundizacin en estos estndares, va mas all del objetivo de este proyecto, por lo que se toman a concepto de consulta.

En el grafico siguiente se observa un ejemplo del funcionamiento de los Servicios Web, y la forma de interaccin de los estndares anteriormente mencionados.

13

http://es.wikipedia.org/wiki/Servicio_Web [Citado el: 28 de Marzo de 2010] SERVICIO WEB

27

Figura 1. Los Servicios Web en funcionamiento

Segn el ejemplo del grafico, contextualizndolo a este proyecto, un usuario (que juega el papel de cliente de los Servicios Web), a travs de una aplicacin, solicita informacin sobre un cliente al cual debe contactar haciendo una peticin a un sistema de registro de activaciones de hosting y dominios que ofrece sus servicios a travs de Internet. El sistema de registro de activaciones de hosting y dominios ofrece a su cliente (usuario) la informacin requerida. Para proporcionar al cliente la informacin que necesita, este sistema solicita a su vez informacin a otros recursos (otros Servicios Web) en relacin con el nmero y tipo de activaciones, los datos del cliente, valor pagado, etc. El sistema de registro obtiene informacin de estos recursos, lo que la convierte a su vez en cliente de esos otros Servicios Web que le proporcionan la informacin solicitada sobre el nmero y tipo de activaciones, los datos del cliente, etc. Por ltimo, el usuario puede que solicite informacin acerca del pago realizado en lnea, ste sistema sirve de intermediario entre el usuario y el servicio Web que gestiono el pago. 14

Las ventajas identificadas al utilizar Servicios Web en el desarrollo del proyecto es la gran interoperabilidad entre las aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen 15 debido a que trabaja sobre estndares libres que permiten la flexibilidad; al apoyarse sobre
14

http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb [Citado el: 28 de Marzo de 2010] GUIA BREVE DE SERVICIOS WEB - COMO FUNCIONAN? 15 http://es.wikipedia.org/wiki/Servicio_Web [Citado el: 28 de Septiembre de 2008] SERVICIO WEB

28

HTTP permiten salir por el puerto 80 y de esta forma no se deben cambiar las reglas de filtrado del firewall
16

aprovechando al mximo la seguridad que esto

puede brindar a la organizacin; algo importante es que permiten que servicios y software de diferentes compaas ubicadas en diferentes lugares geogrficos puedan ser combinados fcilmente para proveer servicios integrados debido a los protocolos estndar y abiertos, definidos por la W3C.
17

esto

Ahora, se aprecia que los servicios Web son muy prcticos debido a que aportan gran independencia entre la aplicacin que usa el Servicio Web y el propio servicio en s, de esta forma, los cambios que se hagan a travs del tiempo no afectan al otro directamente, hacindolo flexible en la construccin de grandes aplicaciones, adems, en la actualidad la tendencia es a construir estas aplicaciones a travs de componentes distribuidos ms pequeos que puedan ser fcilmente modificados, obteniendo ms calidad y funcionalidad de las aplicaciones construidas bajo este panorama. 18

6.2 SERVIDOR WEB Cuando se habla de Servicios Web, es necesario hablar tambin de Servidor Web, quien es el primer actor. Se define al Servidor Web como un programa que implementa el protocolo HTTP (o HTTPS, la versin cifrada y autenticada), este protocolo pertenece a la capa de aplicacin del modelo OSI y est diseado para
16 17

IBID IBID 18 http://es.wikipedia.org/wiki/Servicio_Web [Citado el: 28 de Marzo de 2010] RAZONES PARA CREAR SERVICIOS WEB

29

atender y responder a las diferentes peticiones de los navegadores a travs de los Servicios Web, proporcionando los recursos que soliciten 19.

Un servidor Web bsico cuenta con un esquema de funcionamiento muy simple, basado en ejecutar infinitamente el siguiente bucle:
Recibe peticin. Espera peticiones en el puerto TCP indicado (el estndar por defecto para HTTP es el 80). Busca recurso. el una

Enva el recurso utilizando la misma conexin por la que recibi la peticin.

Figura 2. Bucle bsico de un servidor Web La figura anterior muestra la funcionalidad bsica y principal del Servidor Web, sin embargo debemos considerar que de ste parten diferentes aplicaciones Web, que son porciones de cdigo que se ejecutan cuando se realizan algunas peticiones o respuestas HTTP definidas, dentro de estas aplicaciones estn:

Aplicaciones en el lado del cliente: El cliente Web es el encargado de ejecutarlas en la maquina del usuario. Son las aplicaciones tipo Java o JavaScript, el servidor proporciona el cdigo de las aplicaciones al cliente y este, mediante el navegador las ejecuta.

19

http://www.cibernetia.com/manuales/instalacion_servidor_web/1_conceptos_basicos.php [Citado el 28 de Marzo de 2010] CONCEPTOS BASICOS DEL SERVIDOR WEB

30

Aplicaciones en el lado del servidor: El servidor Web ejecuta la aplicacin; esta, una vez ejecutada, genera cierto cdigo HTML; el servidor toma este cdigo recin creado y lo enva al cliente por medio del protocolo HTTP. 20

Lo anterior demuestra, que en muchas ocasiones la mejor alternativa es conseguir que las aplicaciones sean en el lado del servidor, debido a que el cliente no debe tener capacidades aadidas para poder interactuar con la aplicacin solicitada.

6.3 APACHE Cuando se habla de aplicaciones en el lado del servidor, viene a nuestra mente PHP, debido a que es un software servidor HTTP de cdigo abierto para diferentes plataformas 21 lo hace bastante utilizado y modular, por ser de cdigo abierto, cualquier vulnerabilidad encontrada es rpidamente solucionada por la comunidad, adems es muy liviana en las transacciones realizadas por ste convirtindolo en el principal socio de las actuales aplicaciones que estn basadas en los Servicios Web.

Algunas ventajas encontradas en este servidor son:

20 21

Modular Open Source22

http://es.wikipedia.org/wiki/Servidor_web [Citado el 28 de Marzo de 2010] SERVIDOR WEB http://es.wikipedia.org/wiki/Apache_http_server [Citado el: 28 de Marzo de 2010] SERVIDOR HTTP APACHE 22 Open Source: Cdigo libre

31

Multi-plataforma Extensible Popular (fcil conseguir ayuda/soporte) Gratuito

Debido a su modularidad se basa en una seccin core que es el ncleo principal donde se encuentra la funcionalidad bsica de cualquier Servidor Web, y de all se compone de diferentes modulo que le aporta funcionalidad a este ncleo, con el solo hecho de configurar algunas directivas del modulo en particular y sin necesidad de volver a instalar el software. Los mdulos del Apache se pueden clasificar en tres categoras: mdulos Base: Modulo con las funciones bsicas del Apache. mdulos Multiproceso: Son los responsables de la unin con los puertos de la maquina, aceptando peticiones y enviando a los hijos a atender a las peticiones. mdulos Adicionales: Cualquier otro modulo que le aada una funcionalidad al servidor23.

6.4 MySQL Dentro del proyecto a realizar se utilizo MySQL como motor de base de datos relacional, multihilo y multiusuario. MySQL es un sistema de gestin de base de
23

http://es.wikipedia.org/wiki/Apache_http_server [Citado el: 28 de Marzo de 2010] SERVIDOR HTTP APACHE

32

datos con licenciamiento GNU GPL, lo que significa que es libre en algunas partes del cdigo, sin embargo la compaa Sun Mycrosystems posee el copyright.

La popularidad como aplicacin Web est muy ligada a PHP, que a menudo aparece en combinacin con MySQL 24, lo que hace que est presente en muchas aplicaciones Web transaccionales, debido a que en estos entornos hay baja concurrencia en la modificacin de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones 25.

6.5 PHP El objetivo del proyecto era lograr tener una aplicacin dinmica va Web, y es en este punto donde se pens en PHP como lenguaje de programacin, la razn primordial es que PHP es un lenguaje de programacin interpretado, diseado originalmente para la creacin de pginas Web dinmicas. Es usado

principalmente en interpretacin del lado del servidor (Server-side scripting) 26.

PHP es un acrnimo recursivo que significa PHP Hypertext Pre-processor

27

diseado primordialmente para desarrollo Web y que se complementa con HTML, debido a que se toma el cdigo PHP como entrada y se crea pginas Web como
24 25

http://es.wikipedia.org/wiki/MySQL [Citado el: 28 de Marzo de 2010] MySQL IBID 26 http://es.wikipedia.org/wiki/.php [Citado el: 3 de Abril de 2010] PHP 27 IBID

33

salida; adems puede ser utilizado en la mayora de los sistemas operativos y plataformas sin costo alguno, debido a su licencia PHP License, que es considerada software libre por la Free Software Foundation, mximo organismo del software libre.

Algunas ventajas a resaltar de este lenguaje de programacin es que, como se menciona anteriormente, es multiplataforma, la capacidad de conexin con los gestores de bases de datos del mercado es alta, y aun mas, destaca la facilidad de conectividad con MySQL, su documentacin es amplia lo que facilita su implementacin, permite las tcnicas de Programacin Orientada a Objetos, que es considerada la mejor tcnica en la actualidad para el desarrollo de software. 28 Sin embargo, tambin se encuentra que una de las falencias mximas encontradas es que permite la creacin de cdigo desordenado y complejo de mantener, si no se lleva una tcnica definida por parte del programador.

6.6 SOFTWARE LIBRE Uno de los factores que las compaas toman en cuenta en el desarrollo de los proyectos, es el tiempo que se va a invertir y el dinero necesario para sacar adelante el proyecto, por esta razn uno de los factores a tener en cuenta son las bondades que brinda el software libre, al eliminar el pago de licencias y en enfocar los esfuerzos en las aplicaciones y plataformas necesarias en el proyecto a realizar.
28

IBID

34

El Software Libre es un asunto de libertad, no de precio.

Para entender el

concepto debes pensar en libre como en libertad de expresin, no como en cerveza gratis [N. del T.: en ingles una misma palabra (free) significa tanto libre como gratis, lo que ha dado lugar a cierta confusin].29

Software libre es la definicin del software que le brinda a los usuario la libertad de usar el producto como ellos dispongan, cuando lo adquieren pueden usarlo, copiarlos, estudiarlo, modificarlo y distribuirlo libremente, sin cobrar patentes o licencias, el nico costo que se puede, o no, tener en cuenta es aquel relacionado con el medio de distribucin (medios magnticos, medios digitales o medios pticos, entre otros).

LIBERTADES DEL SOFTWARE LIBRE De acuerdo con tal definicin, el software es libre si garantiza las siguientes libertades: Libertad 0 Ejecutar el programa con cualquier propsito (privado, educativo, publico, comercial, militar, etc.)
29

Libertad 1 Estudiar y modificar el programa (para lo cual es necesario acceder al cdigo fuente)

Libertad2 Copiar el programa de manera que se pueda ayudar al vecino o a cualquiera.

Libertad 3

Mejorar el programa y publicar las mejoras.

http://www.gnu.org/philosophy/free-sw.es.html [Citado el: 3 de Abril de 2010] LA DEFINICION DE SOFTWARE LIBRE

35

Es importante sealar que las libertades 1 y 3 obligan a que se tenga acceso al cdigo fuente. La libertad 2 hace referencia a la libertad de modificar y redistribuir el software libremente licenciado bajo algn tipo de licencia de software libre que beneficie a la comunidad. Figura 3. Libertades del Software Libre 6.7 METODOLOGIA DE PROGRAMACION XP Para el desarrollo del proyecto la base fue la metodologa Extreme Programming XP (Programacin Extrema) que bsicamente consiste en la simplicidad, la comunicacin y la realimentacin o reutilizacin del cdigo desarrollado 30, la cual consta de 4 fases que son: Fase de Planificacin. Fase de Diseo. Fase de Desarrollo. Fase de Pruebas. FASE DE PLANIFICACION Su objetivo es determinar las causas, efectos, el porqu y cmo del proyecto, se escriben los relatos de los usuarios, esto es la forma como ellos ven las necesidades del sistema, cumple la misma finalidad que los casos de uso, con la diferencia que los escriben los usuarios de forma precisa y con un lenguaje no

30

http://www.info-ab.uclm.es/asignaturas/42551/trabajosAnteriores/Presentacion-XP.pdf [Citado el: 3 de Abril de 2010] INTRODUCCION A EXTREME PROGRAMMING

36

tcnico, se utiliza en la fase de pruebas para determinar si el programa cumple con lo que especifica el usuario. En esta fase tambin se busca el plan de publicaciones (release planning) donde se indiquen las historias de usuario que se crearan para cada versin del programa, de esta forma se establecen los tiempos de implementacin y la prioridad de las historias implementadas. Se busca la forma de establecer las iteraciones, por regla general cada iteracin tendr una duracin aproximada de 3 semanas y depende del plan de publicaciones para la implementacin de las historias que no pasaron el test por parte de los usuarios. Se hace necesario de las reuniones diarias donde se expongan los problemas, soluciones e ideas de forma conjunta. Estas reuniones deben ser fluidas y todo el mundo debe tener voz y voto. FASE DE DESARROLLO En esta etapa se define el cdigo a implementar, durante todas las etapas de la metodologa se cuenta con el usuario, en esta etapa su presencia es aun ms importante porque es quien define la manera de implementar su historia de usuario. El objetivo de esta fase es realizar la codificacin y compilacin de la estructura del aplicativo, de acuerdo a las especificaciones funcionales definidas en la etapa anterior.

37

Una vez los programas sean modificados, se debe comenzar con la ltima fase. FASE DE PRUEBAS Uno de los pilares de la metodologa XP es el uso de test para comprobar el funcionamiento de los cdigos que vayamos implementando. El uso de los test en X.P es el siguiente. Hay que someter a test las distintas clases del sistema omitiendo los mtodos las triviales. El uso de test es el mtodo de garantizar la refactorizacin, porque el cambio en el cdigo no tiene que significar el cambio en su funcionamiento. Los diversos test se deben subir al repositorio con el cdigo, no se debe subir un cdigo sin que haya sido evaluado y aprobado su respectivo test.

38

7. MARCO METODOLOGICO

7.1 TIPO DE ESTUDIO La metodologa de investigacin aplicada en el presente proyecto de pasanta se baso en un estudio de tipo desarrollo tecnolgico, donde se pretenda aplicar los conocimientos adquiridos durante la formacin profesional propia de la Ingeniera de Sistemas, para dar como resultado un producto tecnolgico para solucionar un problema que se encontraba presente en el ambiente de aplicacin.

El presente trabajo es de corte transversal, debido a que toda la informacin se recopilo en un tiempo especfico, para lograr, a partir de esta informacin, desarrollar la solucin implantada y de esta manera dar respuesta a las expectativas del Departamento de Soporte Hosting y Dominios.

El sector que afect el presente trabajo son los usuarios que requieren el soporte en las tecnologas de informacin brindado por el Departamento de Soporte Hosting y Dominios. La variable a que se estudi, fueron las activaciones hechas por el Departamento de Soporte Hosting y Dominios, donde se determinaron los puntos crticos para facilitar la atencin brindada. Este proyecto se desarroll a travs de seis meses, en los cuales se cumplieron las etapas establecidas en el cronograma de trabajo, para facilitar el desarrollo de la solucin a implantar y lograr consolidar los objetivos planteados. Toda la informacin, estudio y

desarrollo del proyecto se desarroll en Bogot D.C Colombia, sin embargo su

39

impacto se vio reflejado en todos los clientes que maneja la compaa a nivel mundial.

7.2 METODO Y/O DISEO DE LA INVESTIGACION El diseo de la investigacin se bas en un diseo cualitativo, donde se estructur formalmente y se especific las caractersticas del diseo a implantar en la solucin al problema planteado; tomando las variables de investigacin: tipos de datos cliente, tipo de activacin (hosting, dominio),

Adems dentro de la investigacin se pudo evidenciar que se estaba manejando un sistema de registro basado en Hojas de registro en Access para la consignacin de los datos necesarios en el manejo de las activaciones de Dominio y Hosting, lo cual llevaba a que la informacin no fuera correctamente consignada, cometiendo errores en digitacin, falta de informacin del cliente, segn clculo del Gerente General, cerca del 15% de los cliente registrados que haban hecho activacin no se detallaban en las hojas de registro, y cerca del 60% de los que se registraban no tienen la informacin completa, faltando por ejemplo nombre de la razn social, nombre de la persona de contacto, nmero telefnico de contacto, correo electrnico para notificaciones, etc31. De esta forma segn las encuestas de satisfaccin que se haban realizado por parte de la compaa a los usuarios, se

31

Segn Simon Borrero, Gerente General Imaginamos.com

40

encontraba que el Departamento de Soporte Hosting y Dominios tena una imagen negativa entre los usuarios32.

Se encontr que muchos clientes no eran correctamente contactados para recordar su renovacin, a causa del escenario anteriormente descrito, en ocasiones estos clientes no tenan datos de contacto y hasta el momento en que su servicio era suspendido se lograba encontrar la forma de que hicieran su renovacin, generando malestar y una psima imagen de servicio posventa.

En el pasado la empresa intento utilizar un sistema de CRM para este tipo de registro pero segn el gerente de la compaa este sistema contaba con herramientas que no se estaban utilizando y generaba que la informacin no fuera fcilmente localizada, por esta razn decidieron suspender este CRM y comenzar a utilizar la hoja de registro en Access, que aunque no fue una muy buena decisin para ellos logr dar algunas soluciones como el hecho de poder tener un poco mas fcil la informacin, conocer y realizar la verificacin del servicio de algunos clientes que se comunicaban para obtener informacin de su servicio activo.

En algn momento se evalu la posibilidad de utilizar un software propietario llamado WHCMS33, sin embargo la empresa encontr que este sistema aun

32 33

Dato suministrado por Simon Borrero, Gerente General de Imaginamos.com http://www.whmcs.com/features/ [Citado el: 20 de Noviembre de 2011] FEATURES-WHCMS

41

cuando ofreca algunas alternativas de organizar la informacin, su costo/beneficio no era el mejor para la compaa, Simon Borrero, gerente de la empresa, manifest que la licencia mensual era excesiva y algunos mdulos eran confusos para el manejo por parte de los usuarios del Departamento de Soporte, segn la informacin que se haba brindado se uso por dos meses, encontrando que el beneficio era muy bajo por lo que se desecho.

Sin embargo, algunos mdulos que el software descrito tenia, se reciclaron para el desarrollo final, tales como Datos de contacto del cliente, registro de servidores de hosting disponibles, fecha de activacin y prximo vencimiento, reporte de activaciones.

7.3 PARTICIPANTES Estuvo conformado por los ingenieros que conforman el Departamento de Soporte Hosting y Dominios Imaginamos.com, quienes son los directos responsables de atender a los clientes y registrar las activaciones que se hacen, adems de garantizar que toda la infraestructura de tecnologa funcione sin inconvenientes, los usuarios quienes activan sus servicios con la compaa y que en ocasiones solicitan sus datos de acceso a la administracin de su hosting, por esta razn requieren la informacin de forma casi inmediata, quienes no tienen mucho conocimiento en los problemas comunes de la infraestructura de sistemas y a quienes con este proyecto se alcanz y se evit que sus registros de activacin y

42

sus datos de contacto no estuvieran completos o no pudiesen ser ubicamos rpidamente.

7.4 RECURSOS Analista, Programador, diseador y desarrollador de aplicaciones especficas Jairo Enrique Celis Carrillo, estudiante de Ingeniera de Sistemas, Universidad Distrital Francisco Jos de Caldas. Asesores Jose Jair Bonilla, Director de Desarrollo Imaginamos.com Fernando Martnez Rodrguez, Docente de la Universidad Distrital Francisco Jos de Caldas. RECURSO TECNOLGICO Recurso Procesamiento Computador Elementos de Red Elementos de oficina Otros Pentium IV 2.80 Ghz Descripcin Memoria RAM 1 GB Referencia HP DX2200

1 Router Linksys de 8 puertos Escritorio, Esferos, tijeras, marcadores Pantalla auxiliar para conectar al porttil personal TABLA 1. RECURSO TECNOLOGICO

7.5 INSTRUMENTOS Y EQUIPOS

43

La recoleccin de la informacin se hizo a travs de entrevistas y listas de chequeo con el Director de Desarrollo, a partir de los requerimientos que surgieron de las reuniones, se estableci los puntos claros a implementar en la solucin planteada.

7.6 INGENIERIA DEL PROYECTO La metodologa utilizada en el proyecto se baso en la metodologa de Ingeniera de Software XP, debido a que es la metodologa utilizada en la empresa y brinda mayor control y agilidad en el desarrollo del sistema planteado. Antes de ejecutar como cada una de las fases propias de la metodologa XP, se considero necesario hacer algunas reuniones preliminares, dentro de stas se estableci a grandes rasgos las historias de usuario que son de inters para el director del Departamento de Soporte Hosting y Dominios, al mismo tiempo el equipo de desarrollo se familiarizo con las herramientas, tecnologas y prcticas que se utilizaron en el proyecto, por otro lado se conoci formalmente los requerimientos para el sistema implementado. Por recomendacin del Gerente General de la compaa, se hizo necesario conocer algunos procesos internos de la empresa, adems de conocer la directriz del negocio y las personas encargadas de cada una de las reas de la compaa.

44

A continuacin se explica cada una de las fases para posteriormente introducir los resultados obtenidos de acuerdo a cada una de las fases cumplidas en el ciclo de vida de la Programacin Extrema. FASE DE PLANIFICACION En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacin del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. En esta etapa de planificacin se hizo una estimacin del tiempo dedicado a cada fase del desarrollo, tomando como base la cantidad de requerimientos que los usuarios determinaron para el sistema a implementar (esto es los integrantes del Departamento de Soporte Hosting y Dominios), adems del manejo de la informacin (actualizacin, cambio de datos fuente, cantidad de registros por procesar, entre otros), se estudio la concurrencia y recurrencia a los datos a manejar en el sistema para evitar retrasos en la informacin y cadas eventuales del sistema; por otro lado se establecieron las prioridades de las funcionalidades a desarrollar segn las historias de usuario entregadas, generando un plan de entregas para acercarse al desarrollo deseado. Esta etapa ayudo a conocer la forma de abordar la solucin planteada, las expectativas de la empresa con respecto al sistema de desarrollo planteado, aterriz cada uno de los requerimientos planteados.

45

FASE DE DISEO En sta etapa se estableci la forma de emplear los relatos o historias de usuario, de acuerdo a las prioridades dadas a cada uno de los relatos que fueron entregados se hicieron los prototipos del sistema de incidencias, stos ayudaron a establecer la funcionalidad de los mdulos a implementar en el proyecto. Estos prototipos permitieron mostrar al Departamento de Soporte Hosting y Dominios un acercamiento a la funcionalidad del sistema, de sta manera se poda comprender los pasos que sigue el sistema de incidencias y las pantallas que el usuario observa en cada momento, ayudando a conocer la visin y requerimiento de los usuarios. En la fase de diseo se le permiti a los usuarios un acercamiento inicial no funcional al sistema, se recogieron comentarios del sistema y permiti hacer ajustes finales al diseo planteado, para llegar a obtener finalmente el sistema visual deseado. FASE DE DESARROLLO En esta etapa se desarrollo el cdigo que se implementa para el sistema de incidencias, de acuerdo a los prototipos realizados en la fase anterior se parametriz el sistema para que cumpla con los requerimientos y observaciones por parte del Departamento de Soporte Hosting y Dominios, adems se implemento las historias de usuario con base en las prioridades establecidas. El

46

Director de Desarrollo de Imaginamos.com, estuvo presente en toda esta etapa para establecer que el desarrollo implementado cumpliera con las expectativas del proyecto y se ajustara a las historias de usuario entregadas. Por cada sugerencia por parte del Director de Desarrollo, se hizo la modificacin a los cdigos pertinentes, de esta forma se ajustaron los prototipos realizados llevando a mejoras del sistema final funcional. FASE DE PRUEBAS Recordando que uno de los pilares de la metodologa XP es el uso de test para comprobar el funcionamiento de los cdigos que vayamos implementando. Cuando, se establece que el desarrollo cumpli con los ajustes solicitados al sistema de incidencias, se pas a la etapa de pruebas; esta etapa nos dio los puntos principales en los cuales el sistema implementado no estaba cumpliendo con lo esperado como producto final, se elaborarn diferentes pruebas: Pruebas al cdigo fuente, esta prueba se realiz para limpiar el cdigo fuente de instrucciones que no sirven de nada, en ocasiones algunas instrucciones se comentan debido a los cambios en el cdigo lo que origina que algunas instrucciones que realmente no funcionan queden all, adems se verifico que las funcionalidades del sistema de incidencias se ejecutaban como se desea.

47

Figura 4. Revisin de cdigo34 Se hizo una prueba alfa, esta prueba consista en que los usuarios finales elegidos por el Director de Desarrollo, hacan pruebas de funcionalidad y realizaban preguntas acerca del sistema de registro para lograr registrar las activaciones y hacer seguimiento de las mismas, durante esta etapa todos contaron con la presencia del programador, para despejar dudas y responder a las sugerencias hechas por los usuarios. Se hizo una prueba beta, esta prueba consista en que los usuarios definidos tenan la oportunidad de verificar el sistema, esta vez sin la presencia del programador, donde se evaluaba la disposicin de la informacin, la facilidad para registrar su incidencia, la visualizacin del seguimiento que se le hace a la incidencia, y pasaron por escrito en un formato como el siguiente, los errores encontrados al sistema.

34

http://www.willydev.net/descargas/oguzman-diseno_pruebas.pdf [Citado el: 3 de Abril de 2010]

48

Figura 5. Anotaciones Usuario Prueba Beta35

35

http://www.willydev.net/descargas/oguzman-diseno_pruebas.pdf [Citado el: 3 de Abril de 2010]

49

8. RESULTADOS OBTENIDOS Durante el desarrollo del proyecto se utilizo la metodologa de programacin XP, donde se implementaron las fases que la componen, obteniendo los resultados a continuacin descritos en cada una de las fases. 8.1 FASE DE PLANIFICACION REQUERIMIENTOS PROYECTO SISTEMA DE ADMINISTRACION PARA LA ACTIVACION Y SEGUIMIENTO DE CLIENTES DE HOSTING Y DOMINIOS A travs del siguiente documento se establecen los requerimientos o funcionalidades que el sistema debe cumplir a satisfaccin: 1. 2. instante. 3. 4. 5. Ofrecer la posibilidad de obtener resultados en poco tiempo, esto es Ofrecer una herramienta sencilla para registrar activaciones o Permitir mostrar informacin primordial para el Departamento de informes semanales, mensuales o en fechas especificas. renovaciones de clientes, brindando por ende orden y estructura de los datos. Soporte, tales como: Clientes vencidos, clientes por vencer, clientes potenciales, clientes a llamar antes de 3 meses. Se crean diagramas iniciales de cmo podra ser la aplicacin. Tener acceso desde cualquier navegador a la aplicacin web Lograr organizar la informacin de clientes actuales y futuros

garantizando disponibilidad 24/7/365. permitiendo disponibilidad de informacin detallada de cada uno en cualquier

Historias de Usuario

50

Dentro de la planeacin se estableci la forma como se deba mostrar la informacin, aspectos que eran importantes para la funcionalidad del sistema y como los datos a mostrar en principio se deban mostrar. Para esto se crearon unos diagramas iniciales de las vistas de diseo como punto de partida, a continuacin adjunto vistas realizadas preliminarmente:

Figura 6. Historia de usuario ingreso

Figura 7. Historia de usuario pagina inicial

51

Figura 8. Historia de usuario adicin de activacin

Figura 9. Historia de usuario edicin de activacin

Figura 10. Historia de usuario detalle de activacin

52

Figura 11. Historia de usuario generacin de informes

8.2 FASE DE DISEO Se determino con el Director de Desarrollo crear diagramas iniciales de cmo podra ser el diseo de la aplicacin a nivel de usuario final, es decir se crearon pantallas del sistema de acuerdo a la informacin que se requera y como se deba mostrar, adems fue un punto de partida para el staff de diseadores y desarrolladores, estableciendo parmetros de vista con los cuales regirse. A diferencia de los diagramas de la fase de planeacin, estas vistas se orientaban ms hacia la disposicin final, vistas reales y secuencia especifica de la aplicacin, fueron diseos que en la empresa se llaman "mockups de vistas de diseo", metodologa propia de la compaa. Ver Anexo A.

53

Estas vistas fueron entregadas al staff de diseo para ser diseadas en HTML y ser maquetadas finalmente, para posterior desarrollo por parte del staff de desarrolladores. Igualmente se entregaron al staff de desarrollo para que junto con la maquetacin del diseo HTML se tuviera en cuenta la secuencia de vistas de acuerdo a las opciones y se constituyo en un prototipo del desarrollo. Antes de pasar a la etapa de Desarrollo se construyo el modelo de la base de datos, para establecer los parmetros iniciales del desarrollo, luego de verificar los distintos modelos de la entidad relacin se estableci como el modelo final el siguiente modelo, de esta forma se disea la estructura de la base de datos.

Figura 12. Modelo Entidad Relacin Base de datos del sistema Como finalizacin del diseo se logro obtener los resultados esperados para el usuario final, a continuacin se presentan algunos pantallazos del sistema desarrollado donde se observa el diseo planteado:

54

Figura 13. Pantallas del sistema desarrollado

55

8.3 FASE DE DESARROLLO Al tener los requerimientos iniciales, las historias de usuario y el prototipo del sistema, se estableci la fase de desarrollo, donde se desarrollaron los cdigos correspondientes a cada parte del diseo estableci en HTML y la estructura de la base de datos. Se utilizo un desarrollo orientado a objetos, donde se establece la capa de aplicacin que es finalmente lo que el usuario final observa e interacta con l, de establecen DAOs que son los objetos establecidos en el cdigo del proyecto y desarrollados a travs de entidades, este tipo de desarrollo y la metodologa de programacin XP es una prctica implementada por la empresa en todos sus proyectos de aplicacin. Dentro de la codificacin por ejemplo podemos encontrar un ejemplo muy sencillo para conectarse a la base de datos: Archivo daoConnection.php
<?php session_start();?> <?php if( isset($_SESSION['admin']) ){ header("location: ./../../admin/menuAdmin.php"); exit; } include '../dao/daoConnection.php'; include '../dao/usersDAO.php'; include '../entities/user.php'; $login = $_POST['usuario']; $pass = $_POST['pass']; $location = "location: ./../../admin/index.php?"; if($login == "" || $pass == ""){ header($location."&errorL1"); exit; }

56

$userDAO = new userDAO; $thisUser = $userDAO->getUserByLogin($login); if( $thisUser == null){ header($location."&errorL2"); exit; } $passCrypt = mhash(MHASH_MD5, $pass); if($thisUser->getPass() != $passCrypt){ header($location."&errorL3"); exit; } //everything fine! $_SESSION['admin'] = serialize($thisUser); header("location: ./../../admin/menuAdmin.php"); exit; ?>

Donde se puede observar de forma muy sencilla como se crean los objetos y se trabaja con las entidades. Este tipo de metodologa de programacin nos permiti poder desarrollar el sistema de forma rpida, buscando una mejora continua de las diferentes interacciones y logrando obtener resultados que nos llevan al cumplimiento de los diferentes objetivos finales.

8.4 FASE DE PRUEBAS Dentro de la fase de pruebas se hizo una prueba o revisin al cdigo fuente desarrollado, esto nos ayudo a quitar lneas de cdigo que se haban comentado, ordenar el cdigo para ser fcilmente interpretado por un desarrollador a futuro, como finalidad se limpio el cdigo fuente. Una de las pruebas que se realizo estuvo establecida por el siguiente formato:

57

REVISION DEL CODIGO FORMATO DE REVISION DEL CODIGO Fecha: ______________________ Reporte:__________________ Descripcin: ____________________ Analista: __________________ Revisor: _______________________ REVISION DEL CODIGO Actividad Se he hecho revisin por pares? Se ha realizado el proceso de afinamiento sql? Est la mayor cantidad de cdigo en la base de datos? El cdigo cumple con los estndares de la compaa? El cdigo est organizado de tal forma que pueda ser interpretado? La relacin de lo que ejecuta el cdigo y la salida obtenida, es la esperada? TABLA 2. FORMATO REVISION DE CODIGO El formato nos ayuda a hacer una revisin al cdigo enfocndonos en el registro de las mejoras que se deben establecer en el desarrollo del sistema, cuando se detecta una falla o se establece una recomendacin se llena el formato en la Si No No Aplica Informacin Adicional

58

seccin de Informacin adicional, logrando que se puedan hacer mejoras en el cdigo fuente final. Al final se hizo una prueba de Usuario Prueba Beta, donde algunos usuarios seleccionados escribieron los errores u observaciones encontradas en el sistema: REVISION PRUEBA BETA FORMATO DE PRUEBA BETA Fecha: ______________________ Revisor:______________________ _______________________ Tabla de tipos estndar de defectos Cdigo Nombre Descripcin 10 Documentacin Comentarios, mensajes 20 Sintaxis Ortografa de los comandos, puntuacin, errores de tecleo, formato de las instrucciones Manejo de cambios, libreras, control de versiones Declaraciones, identificadores duplicados, alcance y lmites de los mismos Llamadas y referencias a procedimientos, I/O, interfaz de usuario Mensajes de error, validaciones incorrectas Estructuras, contenidos, inicializaciones 70 80 90 Datos Funciones Sistema Defectos de lgica, puntero, ciclos, recursividad, clculo y funcionamiento Configuracin, memoria, tiempo de respuesta Prueba No:

30 40 50 60

Manejo de Versiones Asignacin Interfaces Validacin

59

100

Entorno

Problemas de diseo, compilacin, pruebas del ambiente de desarrollo

Listado de defectos encontrados Cdigo Localizacin Descripcin del defecto encontrado Defecto

TABLA 3. FORMATO PRUEBA BETA

El anterior formato se ha complementado con un formato de pruebas de funcionalidad: FORMATO DE PRUEBAS DE FUNCIONALIDAD Analista: Fecha: Descripcin/observaciones/reportes Ejecucin Aprobado 1 2 3 4 5

Pantallas:

60

TABLA 4. FORMATO DE PRUEBAS DE FUNCIONALIDAD

Esto ayudo a conseguir que los posibles errores encontrados cuando los usuarios interactan con el sistema se lograran subsanar de forma rpida y ayudar a conseguir los objetivos planteados del sistema.

61

9. RECOMENDACINES PARA PROYECTOS FUTUROS Dentro de las recomendaciones para futuros proyectos podemos encontrar algunos aspectos que considero importantes: Como mejora del sistema se recomienda que se complemente el sistema empleado para utilizacin en otros aspectos en los que se registren servicios cuyo pago sea regularmente en tiempos largos (mes, semestre, ao). Para futuros proyectos de esta rama se recomienda utilizar ms iteraciones en las fases de la metodologa de programacin XP, para obtener sistemas ms robustos sin dejar de lado las libertades que ofrece este tipo de metodologa. Variar los mdulos que se emplearon tales como clientes, servicios, renovacin de servicios, llamadas a clientes, registro de soporte, etc, esto ayudara a obtener un sistema a la medida de forma sencilla, pero dejando libertad de poder obtener resultados a la medida.

62

10. CONCLUSIONES Se diseo en implemento un sistema web de administracin que ha permitido la activacin y seguimiento de clientes de hosting y dominios para imaginamos.com, permitiendo obtener mayor control, seguimiento e informacin de los clientes y las estadsticas de activacin y renovacin de los servicios. Se implement un modulo de reportes, el cual permite analizar los servicios en la activacin de los servicios de hosting y dominios, ayudando en la toma de decisiones de marketing, dirigidos a aumentar el nmero de activaciones semanales. Se implemento un modulo de registros de activaciones, clientes, servicios, permitiendo de forma rpida y sencilla llevar los registros correspondientes de las activaciones y organizando la forma de realizar esta operacin por parte del Departamento de Soporte. Se diseo una interfaz intuitiva y amigable, ayudando a obtener orden en las activaciones de los clientes, datos de contacto e informacin relevante para el Departamento de Soporte Hosting y Dominios. Se logro conseguir que el departamento de Soporte obtuviera una visin amplia de las activaciones realizadas, organizando el proceso de obtener los datos de los clientes y dar de alta el servicio, as como lograr tener la informacin de forma ms rpida y sencilla.

63

11. BIBLIOGRAFIA PRESSMAN, Roger S. Ingeniera del software, 6 edicin. McGraw-Hill, Espaa, 2005. SOMMERVILLE, Ian. Ingeniera de Software, 7 Edicin. Ed. Pearson Educacin, Espaa, 2005. SILBERSCHATZ, Abraham. Fundamentos de Bases de Datos, 5 Edicin. McGraw-Hill, Espaa, 2006.

11.1 REFERENCIAS ELECTRNICAS Imaginamos.com Diseo Pginas Web A La Medida http.//www.imaginamos.com Service Level Agreement http://en.wikipedia.org/wiki/Service_level_agreement Servicios Web en plataforma .NET http://www.desarrolloweb.com/articulos/1535.php Gua Breve de Servicios Web http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb W3C Consortium. Web Services Architecture. [En lnea] http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#whatis. Servicio Web http://es.wikipedia.org/wiki/Servicio_Web

64

Conceptos bsicos del servidor Web http://www.cibernetia.com/manuales/instalacion_servidor_web/1_conceptos_basic os.php

Servidor HTTP Apache http://es.wikipedia.org/wiki/Apache_http_server RFC 2616 http://www.ietf.org/rfc/rfc2616.txt

NETCRAFT http://news.netcraft.com/

Arquitectura del servidor Apache http://www.desarrolloweb.com/articulos/1112.php

MySQL http://es.wikipedia.org/wiki/MySQL

MySQL :: Dispelling the myths http://dev.mysql.com/tech-resources/articles/dispelling-the-myths.html

La definicin del software libre http://www.gnu.org/philosophy/free-sw.es.html

Software Libre http://es.wikipedia.org/wiki/C%C3%B3digo_libre

Free Software Foundation http://es.wikipedia.org/wiki/FSF

PHP http://es.wikipedia.org/wiki/.php

65

Sitio web official de PHP http://www.php.net/

Manual de referencia de PHP http://es.php.net/manual/es/

66

ANEXOS

67