Acceso Acerca de

CRM Inteligente :: Documentación

Capítulo 3
Metodología de desarrollo

3.1. Ciclo de vida del sistema

Definimos el ciclo de vida de un sistema como el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de la idea hasta la entrega y el mantenimiento del sistema. Antes de escoger el tipo de ciclo de vida debemos especificar cuáles son las etapas por las que va a seguir la puesta en marcha del sistema. Las etapas por las que transcurre nuestro proyecto son las siguientes:

  1. Análisis: Construye un modelo de los requisitos
  2. Diseño: A partir del de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.
  3. Implementación: Construye el sistema. Se genera el código a ejecutar.
  4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
  5. Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.

Una vez descritas cada una de las etapas elegimos el estilo de ciclo de vida que usaremos para el desarrollo de nuestro proyecto. Todos los ciclos de vida tienen características positivas y negativas, los creadores del sistema deben elegirlo acorde con sus pretensiones. Debido a que un CRM-I es un sistema muy propenso a cambios en el diseño durante toda fase del ciclo de vida, elegimos un ciclo de vida en cascada. El diagrama que describe el funcionamiento de este modelo puede verse en la Figura 3.1


PIC


Figura 3.1: Modelo en cascada


Esta metodología elegida, de modelo en cascada, facilita una planificación sencilla. Podemos pasar por alto detalles concretos y después, en una nueva planificación, llevarlos a cabo. En nuestro caso, en una primera instancia nos ocupamos del funcionamiento básico de un CRM y más tarde, abordamos los aspectos más avanzados, como el módulo de inteligencia.

La calidad de este tipo de proyectos es muy alta dado que una vez terminada una versión puede mejorarse e incluso rediseñarse para que su funcionamiento sea más eficiente, fundamentalmente en las fases de interacción con el usuario del sistema y en la estructura del árbol de decisión.

Además, esta metodología estuvo bastante acertada, pues los requisitos no los tuvimos completados hasta casi la fase final. Además, dado el carácter del proyecto, principalmente descriptivo, no nos resultó muy traumático en el momento de hacer los cambios en la implementación.

3.2. Cronograma del proyecto

Tras acordar el proyecto con el profesor a finales de septiembre, coincidiendo con el comienzo del curso, nos pusimos manos a la obra. Inicialmente la planificación del proyecto tal como pensó el profesor sería:

Al principio del desarrollo discutimos cual sería la metodología de desarrollo para llevar a cabo el proyecto en nuestro grupo. Coincidimos con el profesor en la realización de reuniones semanales para la revisión del trabajo realizado durante la semana. En las reuniones exponíamos los documentos y trabajos pedidos por el profesor para su valoración y corrección. En algunas ocasiones los documentos precisaban ser corregidos y en otros ampliados. Además en cada reunión se proponían nuevos contenidos a añadir.

Las reuniones tenían la siguiente estructura:

  1. Exposición del trabajo realizado.
  2. Comentarios sobre lo anteriormente expuesto.
  3. Punto de vista por parte del profesor. Estableciendo un nuevo objetivo.
  4. Dudas y cuestiones generales.

Además se han establecido actas para cada reunión realizada, en cada una de las cuales constan los temas tratados, juntos con los contenidos presentados o cualquier cuestión relacionada con la orden día. Pueden consultarse en la sección de anexos. La figura 3.2 ilustra la dinámica de funcionamiento de las reuniones se trata de un comportamiento cíclico hasta la obtención de un nuevo objetivo para la siguiente reunión.


PIC

Figura 3.2: Ciclo de funcionamiento de las reuniones


Después de cada reunión nos dividíamos el trabajo para cumplir el objetivo. En numerosas ocasiones, y debido a las características del proyecto realizábamos trabajos equivalentes. Puede parecer redundante pero en ningún caso lo es ya que aporta diferentes puntos de vista a las soluciones posibles para abordar el objetivo. El trabajo realizado necesitaba modificaciones a fin de enriquecerse con las aportaciones de cada miembro.

Para organizar la documentación generada en las reuniones utilizamos una Wiki (http://si2008.wikispaces.com/). Nuestra Wiki está dividida en varias secciones, correspondientes a las actas generadas tras las reuniones, así como otra sección de la memoria. Cada página dispone de imágenes, diagramas y otros recursos que complementan su contenido. Además el uso de la Wiki nos proporciona grandes facilidades para realizar la documentación, especificaciones del proyecto, realización de la memoria, etc.

3.3. Tecnologías aplicadas en el desarrollo

3.3.1. Wiki

Una wiki es un sitio web cuyas páginas pueden ser editadas por distintos usuarios a través del navegador web. Los usuarios pueden crear, modificar o eliminar una página que comparten. Las páginas de la wiki tienen títulos únicos. Si se escribe el título de una ”página-wiki” en algún lugar de la wiki, esta palabra se convierte en un hipervínculo a la página web.

Características principales:

3.3.2. JSP y Servlets

JavaServer Pages (JSP) es una tecnología Java que permite generar contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo.

JSP permite crear aplicaciones web que se ejecutan en diversos servidores web, de múltiples plataformas, ya que Java es un lenguaje multiplataforma. Las páginas JSP están compuestas de código HTML/XML con etiquetas especiales para programar scripts de servidor en sintaxis Java. Por tanto, las JSP pueden desarrollarse con un editor HTML/XML habitual.

El motor de las páginas JSP está basado en los servlets de Java, programas en Java que se ejecutan en el servidor, aunque el número de desarrolladores que pueden afrontar la programación de JSP es mucho mayor, dado que resulta mucho más sencillo aprender que los servlets.

En JSP creamos páginas de manera parecida a como se crean en ASP o PHP -otras dos tecnologías de servidor-. Generamos archivos con extensión .jsp que incluyen, dentro de la estructura de etiquetas HTML, las sentencias Java a ejecutar en el servidor. Antes de que sean funcionales los archivos, el motor JSP lleva a cabo una fase de traducción de esa página en un servlet, implementado en un archivo class (Byte codes de Java). Esta fase de traducción se lleva a cabo habitualmente cuando se recibe la primera solicitud de la página .jsp, aunque existe la opción de compilar en código para evitar ese tiempo de espera la primera vez que un cliente solicita la página.

Para trabajar con JSP es necesario conocer HTML y JAVA como lenguaje de programación Orientado a Objetos por completo. También es recomendable tener una ligera idea sobre Servlets, lo que nos dará una mejor idea del funcionamiento interno del motor JSP.

Para que JSP pueda ser utilizado es necesario un servidor web. Tomcat, es el contenedor de servlets usado en la referencia oficial de implementación de JSP.

3.3.3. MYSQL

Es un gestor de bases de datos relacionales multiusuario y multihilo. Debido a su gran sencillez de instalación y uso optamos por la utilización de este sistema para realizar las pruebas. Su gran aceptación se debe en parte, a la existencia de numerosas librerías y herramientas que permiten su uso. Además dispone de soporte para gran cantidad de lenguajes de programación, y, en concreto para Java. Es fácil su instalación y configuración.

El servidor está disponible como un programa separado para usar en un entorno de red cliente/servidor. También está disponible como biblioteca y puede ser incrustado (linkado) en aplicaciones autónomas. Dichas aplicaciones pueden usarse por sí mismas o en entornos donde no hay red disponible.

Características

  1. Aprovecha la potencia de sistemas multiprocesador, gracias a su implementación multihilo.
  2. Soporta gran cantidad de tipos de datos para las columnas.
  3. Dispone de API’s en gran cantidad de lenguajes (C, C++, Java, PHP, etc).
  4. MySQL server tiene soporte para comandos SQL para chequear, optimizar, y reparar tablas. Estos comandos están disponibles a través de la línea de comandos y el cliente mysqlcheck. MySQL también incluye myisamchk, una utilidad de línea de comandos muy rápida para efectuar estas operaciones en tablas MyISAM.
  5. Soporte completo para operadores y funciones en las cláusulas de consultas SELECT y WHERE.
  6. Gran portabilidad entre sistemas.
  7. Soporta hasta 32 índices por tabla.
  8. Gestión de usuarios y contraseñas, manteniendo un muy buen nivel de seguridad en los datos.

3.3.4. JDBC

JDBC es un API (Application programming interface) que describe o define una librería estándar para acceso a fuentes de datos, principalmente orientado a Bases de Datos relacionales que usan SQL (Structured Query Language). JDBC es un interfaz para acceso a motores de bases de datos y también define una arquitectura estándar, para que los fabricantes puedan crear los drivers que permitan a las aplicaciones java el acceso a los datos.

Las características más importantes de JDBC son:

3.3.5. XHTML

XHTML (Lenguaje de Marcado de Hipertexto Extensible) es una versión más estricta y limpia de HTML. Empieza precisamente con el objetivo de remplazar a HTML ante su limitación de uso con las cada vez más abundantes herramientas basadas en XML. XHTML extiende HTML 4.0 combinando la sintaxis de HTML, diseñado para mostrar datos, con la de XML, diseñado para describir los datos. Ante la llegada al mercado de un gran número de dispositivos, XHTML surge como el lenguaje cuyo etiquetado, más estricto que HTML, va a permitir una correcta interpretación de la información independientemente del dispositivo desde el que se accede a ella. XHTML puede incluir otros lenguajes como MathML, SMIL o SVG, al contrario que HTML.

XHTML exige una serie de requisitos básicos a cumplir en lo que a código se refiere. Entre estos requisitos básicos se puede mencionar una estructuración coherente dentro del documento donde se incluirían elementos correctamente anidados, etiquetas en minúsculas, elementos cerrados correctamente, atributos de valores entrecomillados, etc.

Las ventajas más evidentes que ofrece el migrar a XHTML son:

3.3.6. CSS

El lenguaje HTML está limitado a la hora de aplicarle forma a un documento. En sus orígenes no se contempló estas opciones ya que estaba orientado a otros temas.

Para solucionar estos problemas los diseñadores han utilizado técnicas tales como la utilización de tablas imágenes transparentes para ajustarlas, utilización de etiquetas que no son estádares del HTML y otras. Estas ”trampas” han causado a menudo problemas en las páginas a la hora de su visualización en distintas plataformas.

Finalmente, otro antecedente que ha hecho necesario el desarrollo de esta tecnología consiste en que las páginas web tienen mezclado en su código HTML el contenido del documento con las etiquetas necesarias para darle forma. Esto tiene sus inconvenientes ya que la lectura del código HTML se hace pesada y difícil a la hora de buscar errores o depurar las páginas. Aunque, desde el punto de vista de la riqueza de la información y la utilidad de las páginas a la hora de almacenar su contenido, es un gran problema que estos textos estén mezclados con etiquetas incrustadas para dar forma a estos: se degrada su utilidad.

CSS u Hojas de Estilo en Cascada (Cascading Style Sheets), es una tecnología simple que describe cómo será mostrado un documento (normalmente páginas web) en los distintos medios soportados (pantalla, impresora, etc.) De esta forma se consigue el control total sobre estilo y formato de sus documentos.

CSS se utiliza para dar estilo a documentos HTML y XML, separando el contenido de la presentación. Los Estilos definen la forma de mostrar los elementos HTML y XML. CSS permite a los desarrolladores Web controlar el estilo y el formato de múltiples páginas Web al mismo tiempo. Cualquier cambio en el estilo marcado para un elemento en la CSS afectará a todas las páginas vinculadas a esa CSS en las que aparezca ese elemento.

CSS funciona a base de reglas, es decir, declaraciones sobre el estilo de uno o más elementos. Las hojas de estilo están compuestas por una o más de esas reglas aplicadas a un documento HTML o XML. La regla tiene dos partes: un selector y la declaración. A su vez la declaración está compuesta por una propiedad y el valor que se le asigne.

h1 {color: red;}

h1 es el selector

{color: red;} es la declaración

De esta forma todos los elementos de los documentos que incluyan dicha regla establecerán la propiedad color el valor red (rojo), de tal forma que se mostrarán los encabezados de nivel 1 en color rojo.

3.3.7. CVS

CVS es un sistema de control de versiones usado para mantenimiento de código fuente (grupos de ficheros en general) extraordinariamente útil para grupos de desarrolladores que trabajan cooperativamente usando alguna clase de red.

CVS permite a un grupo de desarrolladores trabajar y modificar concurrentemente ficheros organizados en proyectos. Por ello, dos o más personas pueden modificar un mismo fichero sin que se pierdan los trabajos de ninguna.

Como añadido a lo anterior, CVS guarda todas las versiones antiguas de los ficheros. Esto permite recuperar en cualquier momento versiones anteriores a la actual.

Dado que trabaja con ficheros ASCII es igual de útil para trabajar con código fuente de programas o con toda clase de documentos siempre que su formato sea completamente de texto, como pueden ser ficheros sgml/html/xml.

Conceptos:

Repositorio:
Jerarquía de directorios alojada en el servidor CVS que contiene diferentes módulos a disposición de los usuarios.
Módulo:
Árbol de directorios que forma parte del repositorio. Cuenta con un nombre identificador gracias al cual podremos trabajar con él de forma selectiva.

Se pueden visualizar los archivos del repositorio junto con sus correspondientes versiones en la siguiente URL http://cvs.berlios.de/cgi-bin/viewcvs.cgi/banderas/CRMI/