www.uoc.eduU

Software libre

Proyecto web

Alberto Otero Garca

XP06/M2119/02156

David Megas Jimnez Jordi Mas

Coordinador Coordinador

Ingeniero en Informtica por la UAB.

Magster en Tcnicas Avanzadas de Automatizacin de Procesos por la UAB.

Doctor en Informtica por la UAB.

Profesor de los Estudios de Informtica y Multimedia de la UOC.

Coordinador general de Softcatal y desarrollador del procesador de textos libre Abiword.

Miembro fundador de Softcatal y de la red telemtica RedBBS.

En calidad de consultor, ha trabajadoen empresas como Menta, Telpolis, Vodafone, Lotus, eresMas, Amena y Terra Espaa.

Alberto Otero Garca

Autor

Ingeniero de Informtica por la Universidad Ramon Llull. Licenciado en Investigacin y Tcnicas de Mercado por la UOC. Socio fundador y jefe de proyectos de Cometa Technologies, empresa dedicada a dar soluciones en tecnologas de la informacin, basadas en el uso de estndares y herramientas de cdigo abierto.

Profesor titular de la asignatura Administracin de Sistemas Operativos en Enginyeria i Arquitectura La Salle y consultor del Master Internacional en Software Libre de la UOC.

Segunda edicin: febrero 2007 Fundaci per a la Universitat Oberta de CatalunyaAv. Tibidabo, 39-43, 08035 BarcelonaMaterial realizado por Eureca Media, SL Autor: Alberto Otero Garca

Se garantiza permiso para copiar, distribuir y modificar este documento segn los trminos de la GNU Free Documentation License,Version 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Se dispone de una copia de la licencia en el Apndice A.

3Proyecto web

AN

OTA

CIO

NES

FUOC XP06/M2119/02156

Agradecimientos ......................................................... 5

Introduccin ................................................................ 7

Objetivos ..................................................................... 9

1. Estudio de viabilidad .............................................. 111.1. Establecimiento del alcance del sistema ............... 121.2. Estudio de la situacin actual .............................. 151.3. Definicin de los requisitos del sistema ................ 181.4. Estudio de las alternativas de solucin ................. 211.5. Valoracin de las alternativas ............................. 231.6. Seleccin de la solucin ...................................... 26

2. Anlisis del sistema ................................................ 292.1. Definicin del sistema ........................................ 292.2. Establecimiento de requisitos .............................. 332.3. Definicin de interfaces de usuario ...................... 372.4. Especificacin del plan de pruebas ...................... 40

3. Diseo del sistema ................................................. 433.1. Arquitectura ....................................................... 44

3.1.1. Definicin de niveles de arquitectura ......... 443.1.2. Especificacin de estndares,

normas de diseo y construccin ............... 473.1.3. Identificacin de subsistemas .................... 49

3.2. Revisin de casos de uso .................................... 503.2.1. Revisin de los subsistemas segn los casos

de uso ..................................................... 513.2.2. Eleccin de alternativas de componentes

y licencias ms adecuadas ........................ 533.2.3. Especificaciones de desarrollo y pruebas .... 563.2.4. Requisitos de implantacin ........................ 59

ndice

4AN

OTA

CIO

NES

Software libre FUOC XP06/M2119/02156

4. Desarrollo .............................................................. 634.1. Planificacin de las actividades de desarrollo

e integracin de sistema .................................... 644.2. Desarrollo ......................................................... 674.3. Documentacin ................................................. 68

5. Implantacin .......................................................... 715.1. Formacin ........................................................ 725.2. Implantacin del sistema y pruebas .................... 725.3. Nivel de servicios ............................................... 745.4. Aceptacin del sistema ...................................... 74

6. Mantenimiento ....................................................... 75

Resumen ..................................................................... 77

Bibliografa ................................................................. 79

Appendix A. GNU Free Documentation License ........ 80

5Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Los autores agradecen a la Fundacin para la Universitat Oberta de

Catalunya (http://www.uoc.edu) la financiacin de la primera edi-

cin de esta obra, enmarcada en el Mster Internacional en Software

Libre ofrecido por la citada institucin.

Agradecimientos

7Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Para llevar a cabo un proyecto de tecnologas de la informacin ba-

sado en la utilizacin de herramientas de uso habitual en Internet

(como por ejemplo la World Wide Web), en entornos de software li-

bre, como en cualquier otro tipo de proyecto, es necesario seguir un

proceso que nos lleve desde la comprensin del alcance del pro-

blema que queremos solventar hasta la implantacin y manteni-

miento de la solucin que hayamos elegido.

En este curso se pretenden repasar aquellas fases que es necesario

seguir a lo largo de todo proyecto, tomando como referencia uno

que basar su funcionamiento en la utilizacin de la web como he-

rramienta principal.

Estas fases son las siguientes:

Estudio de viabilidad: se estudiar en lneas generales qu pro-

blemas se desean resolver, qu soluciones posibles existen y cul

de ellas es la ms adecuada.

Anlisis: se describir detalladamente el sistema que se desea

construir, qu requisitos debe cumplir y a qu usuarios debe sa-

tisfacer.

Diseo: se realizar el planteamiento tecnolgico de la solucin.

Desarrollo: se llevar a cabo la programacin, integracin, ins-

talacin, etc. de los diferentes subsistemas que compongan el

proyecto.

Implantacin: se pasar el sistema construido a produccin con

el fin de que los usuarios de ste empiecen a utilizarlo.

Mantenimiento: se realizarn tanto las correcciones de los posi-

bles errores que puedan surgir en el sistema implantado, como

las mejoras evolutivas que se consideren oportunas.

Introduccin

Software libre

8

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Estas fases estarn presentes, de una u otra forma, con estos nom-

bres o con otros, en cualquier proyecto web, desde los gestionados

mediante mtodos clsicos (por ejemplo, en fases seguidas se-

cuencialmente, en cascada, etc.), hasta los gestionados como sugie-

re el conjunto de metodologas conocidas como giles.

Figura 1. Fases de un proyecto web

A lo largo de todo el mate-rial del curso, se desarrollaun caso prctico con el fin deejemplificar las explicacio-nes dadas. Este caso prcti-co no constituye de ningnmodo un estudio exhaustivodel proyecto propuesto, sinoque simplemente sirve comomarco para ofrecer diferen-tes ejemplos de las partes deque se compone con finesnicamente didcticos.

Nota

9Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Los objetivos que el lector deber haber alcanzado al finalizar el cur-

so de Proyecto web son los siguientes:

Haber comprendido de manera global lo que representa llevar a

cabo un proyecto basado en tecnologas de Internet, especial-

mente web, en un entorno tecnolgico de software libre.

Haber asimilado qu fases integran un proyecto de tecnologas

de la informacin, y qu tareas se deben llevar a cabo en cada

una de ellas, especialmente desde el punto de vista del desarrollo

de soluciones basadas en web.

Haber reflexionado sobre qu herramientas de software libre

pueden ayudar en cada una de las fases de un proyecto web.

Haber aplicado a un caso prctico los conocimientos adquiridos

a lo largo de todo el mster en software libre.

Objetivos

11

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

El objetivo de la realizacin del estudio de viabilidad es el de, dado

un conjunto de necesidades planteadas, elegir aquella solucin que

mejor las cubra de entre todas las posibles (o descartarlas todas en

caso de que ninguna las satisfaga).

En el estudio de viabilidad se considerarn las diferentes soluciones

posibles, teniendo en cuenta:

El estado inicial del sistema.

La situacin actual.

Los requisitos planteados.

Cada una de las soluciones propuestas en el estudio de viabilidad

deber recoger los siguientes aspectos:

Econmicos: se deber incluir un estudio econmico preliminar

que contemple los costes asociados a cada una de las soluciones.

Tcnicos: se deber incluir un estudio tcnico preliminar de cada

una de las soluciones.

Legales: se deber incluir un estudio de aquellos aspectos legales

que puedan influir en la viabilidad de la solucin.

Operativos: se deber incluir un estudio previo de la operativa de

cada una de las soluciones propuestas.

Una vez planteadas cada una de las soluciones, se elegir la mejor

teniendo en cuenta:

El impacto en la organizacin.

La inversin que hay que realizar.

Los riesgos asociados.

Los siguientes apartados describen con ms detalle cada una de las ta-

reas que hay que llevar a cabo para realizar el estudio de viabilidad.

1. Estudio de viabilidad

Software libre

12

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

En esta fase del estudio de viabilidad se pretende estudiar el alcance

de las necesidades planteadas por el cliente (bien sean terceros, en

caso de tratarse de un proyecto web dirigido a otras organizaciones,

bien sean usuarios internos, en caso de tratarse de un proyecto para

la propia organizacin).

Lo primero que ser necesario hacer es la descripcin general de

las necesidades planteadas por el cliente. En esta descripcin ge-

neral se debern incluir los aspectos bsicos descritos en el anterior

apartado (econmicos, tcnicos, legales y operativos) que tengan

especial relevancia.

1.1. Establecimiento del alcance del sistema

Caso prctico

Sitio web corporativo de Soluciones Abiertas, S. A.

La empresa Soluciones Abiertas, S. A., se dedica a la pres-

tacin de servicios relacionados con el software que ellos

mismos desarrollan y que liberan en algunos casos bajo

licencias libres. Los ingresos de Soluciones Abiertas pro-

vienen principalmente de la facturacin realizada a sus

clientes en concepto de horas/hombre dedicadas a la

prestacin de dichos servicios.

Con el fin de hacer ms comprensible y atractiva su ofer-

ta, Soluciones Abiertas, S. A., ha decidido renovar su sitio

web corporativo, teniendo como principales objetivos:

Presentar la informacin del tipo presencial (p. ej.

Quines somos Qu ofrecemos) de forma vi-

sualmente ms atractiva que en la actualidad.

Implantar un nuevo sistema de comercializacin de pa-

quetes de horas de prestacin de servicios a travs de

comercio electrnico, haciendo posible la contratacin

completa y el pago de stos a travs de su sitio web.

Disfrutar de un sistema de gestin de contenidos (en

lo referente tanto a la parte presencial como a la

de comercio electrnico del sitio web), facilitando

su actualizacin y haciendo que sta pueda ser lle-

vada a cabo por personas no tcnicas.

13

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Asimismo, adems de describir de forma general el proyecto, se

debe tener en cuenta cmo afectar ste a:

Otros proyectos de tecnologas de la informacin ya en curso o

que se piensan poner en marcha.

Las diferentes unidades de la organizacin, teniendo en cuenta

quines son los responsables de stas y cul es su estructura.

Desde el punto de vista econmico, para que la renova-cin sea viable deber implicar el menor gasto posible,dado que el coste de este proyecto no estaba contempladoinicialmente en los presupuestos anuales de la empresa.

A nivel tcnico, las necesidades planteadas son muypoco restrictivas, ya que al ser Soluciones Abiertas unaempresa dedicada a las tecnologas de la informacin,se dispone de personal cualificado que afronta y disfru-ta cualquier reto tcnico sin mayores problemas.

Desde el punto de vista legal, se exige que las solucio-nes aportadas sean lo ms flexibles posibles, ya que sevalora muy negativamente el hecho de no disponer dela mxima libertad para copiar y/o modificar los siste-mas software que se implanten.

A nivel operativo, la nica necesidad planteada consisteen que en ningn caso se debe perder funcionalidad dela que en estos momentos ya se dispone en el sitio webde la empresa (p. ej. mostrar cualquier tipo de contenido,ordenarlo en secciones y subsecciones, posibilitar la des-carga de ficheros), sino en todo caso, ampliarla.

Figura 1-1. Descripcin general del sistema

Software libre

14

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Caso prctico

Alcance del proyecto

En el caso de Soluciones Abiertas, el proyecto de reno-vacin de su sitio web corporativo afectar a:

El proyecto de renovacin del hardware de la em-presa Soluciones Abiertas tiene en la actualidad unordenador dedicado a servir su sitio web corporati-vo, que estaba previsto renovar junto con otros de-dicados a otras funciones. Ser necesario coordinarambos proyectos para que el/los nuevo/s servidor/es web cumpla/n con las necesidades marcadas enel proyecto de renovacin.

El proyecto de digitalizacin total de los procesos de laempresa Soluciones Abiertas ha puesto en marcha unproyecto de organizacin sin papel, lo cual implicaque puede existir informacin que se desea compartiren el sitio web de la empresa (p. ej. los comentarios delas encuestas de satisfaccin de los clientes) y que antesno poda ser fcilmente incorporada a ste (p. ej. por-que se dispona de ella nicamente en formato papel).

Por otro lado, el proyecto de renovacin del sitio webde la empresa afectar a los siguientes departamentosde sta:

Marketing: la renovacin a nivel grfico y de conteni-dos del sitio web debe ser liderada por el equipo deldepartamento de marketing, ya que es ste el que seencarga de la comunicacin externa en la empresa.Adems se abre un nuevo canal de comercializacinde los servicios de la organizacin, con todo lo queello comporta (posible canibalizacin de otros cana-les, necesidad de unificacin y simplificacin de lastarifas de precios aplicados, etc.).

Administracin: la posibilidad de que los clientes con-traten los servicios ofrecidos por Soluciones Abiertasdirectamente a travs de su sitio web implica la nece-sidad de crear un nuevo canal de pago (adems de ladomiciliacin bancaria y la recepcin de transferen-cias), la emisin de facturas automticamente (mante-niendo la coherencia con las generadas a travs delprograma de contabilidad), etc.

15

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

En esta fase del estudio de viabilidad se pretende estudiar la situa-

cin en la que se encuentra el sistema de informacin de la em-

presa y realizar un diagnstico de ste, siempre en lo referente al

proyecto que nos ocupa.

La primera tarea que hay que realizar dentro del estudio de la situa-

cin actual es la de identificar aquellos sistemas que deben descri-

Atencin al cliente: las personas dedicadas a la aten-

cin al cliente debern poder solucionar nuevas con-

sultas, como las referentes a los mtodos de pago a

travs del sitio web, reclamaciones en referencia a s-

tos, dudas acerca de la contratacin directa en lugar

de a travs de un agente comercial, etc.

Produccin/Servicios: el hecho de ofrecer la contrata-

cin de servicios mediante Internet puede suponer que

el nmero de clientes extranjeros aumente, ya que la

oferta comercial de la empresa se har ms palpable

para este pblico. Este hecho implica que las personas

encargadas de la prestacin de los servicios a los

clientes deben estar preparadas para realizar su labor

dependiendo cada vez menos de su presencia fsica

(intervencin a travs de conexiones remotas, entrega

de informes por correo electrnico sin posibilidad de

realizar reuniones presenciales posteriores, etc.). Ade-

ms, a la hora de prestar el servicio se debern tener

en cuenta las prioridades marcadas por los tipos de

contrataciones disponibles en el nuevo sitio web (p. ej.

platinum, con respuesta y solucin en 12 h, gold,

con respuesta en 24 h y solucin silver en 48 h).

Se deber informar puntualmente e implicar a los res-

ponsables de cada uno de los departamentos de los

detalles y el alcance del proyecto, en la medida en que

se vean afectados.

1.2. Estudio de la situacin actual

Software libre

16

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

birse, esto es, de qu sistemas vamos a hacer el estudio debido a que

se ven afectados de alguna manera por el proyecto contemplado en

el estudio de viabilidad. Es interesante tambin fijar qu usuarios

participarn en el estudio de la situacin actual de cada uno de los

sistemas escogidos.

El siguiente paso dentro del estudio de la situacin actual ser el

de describir cada uno de los sistemas identificados en el paso

anterior. La descripcin se har teniendo en cuenta la informa-

cin recogida en las sesiones de trabajo con los usuarios seleccio-

nados como representativos, y deber alcanzar el nivel de detalle

suficiente como para poder realizar un diagnstico acertado del

estado real de cada uno de los sistemas estudiados. Asimismo, la

dedicacin de recursos en esta fase depender de la informacin

de partida de la cual se disponga (la descripcin de la situacin

actual puede ser trivial en algunos casos o tremendamente com-

plicada en otros).

Caso prctico

Identificacin de los sistemas actuales

Dado que el proyecto consiste en la renovacin y

ampliacin del sitio web corporativo de Soluciones

Abiertas, deberemos estudiar como mnimo la situa-

cin actual del sistema que deseamos renovar. En

este caso este sistema ser el del sitio web actual.

Con el fin de realizar un diagnstico lo ms completo

posible, hemos decidido trabajar junto con el perso-

nal de marketing, ya que es este departamento el

que hace un uso ms intensivo del mencionado sis-

tema.

Por otro lado, dado que el proyecto sobre el que se est

haciendo el estudio de viabilidad implica la comercia-

lizacin de servicios directamente a travs del sitio web

de la empresa, se ha decidido estudiar tambin el es-

tado de las aplicaciones de gestin con las cuales ste

se tendr que integrar (p. ej. la de contabilidad). Este

trabajo se har junto con el personal del departamento

de administracin.

17

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Para completar el estudio de la situacin actual de los sistemas,

se deber realizar un diagnstico de stos, es decir, analizar la

informacin obtenida detectando posibles problemas y puntos de

mejora.

Caso prctico

Descripcin de los sistemas actuales

A continuacin se describe la situacin actual de los sis-

temas de Soluciones Abiertas seleccionados con ante-

rioridad:

Sistema web: en la actualidad este sistema consiste

en una serie de pginas HTML que son gestionadas

a travs de un editor web. Este editor web debe ser

utilizado por una persona tcnica o bien por una

persona no tcnica con conocimientos amplios de

HTML, JavaScript y CSS.

Por otro lado, el sistema contiene tambin una peque-

a aplicacin que permite la introduccin de las nove-

dades y noticias que son mostradas en la pgina

principal del sitio.

Aplicaciones de gestin: en la actualidad estos siste-

mas contemplan las vas de pago y facturacin de

servicios que hasta ahora eran habituales, es decir,

la transferencia y domiciliacin bancarias y la emi-

sin de facturas de forma supervisada.

Figura 1-2. Descripcin sistema web actual

Software libre

18

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez descrita la situacin actual del sistema, y teniendo en cuenta

las opiniones de los diferentes usuarios implicados, se pasar a des-

cribir de forma general los requisitos que deber cumplir el pro-

yecto del cual se est estudiando la viabilidad.

La descripcin del conjunto de requisitos a cumplir por el proyecto

servir posteriormente para evaluar cada una de las posibles solu-

ciones alternativas existentes. Es por ello por lo que adems de la ci-

tada descripcin, es interesante incluir una calificacin de la

prioridad de cada uno de los requisitos, con el fin de tener presente

su importancia relativa respecto al resto.

Caso prctico

Diagnstico de los sistemas actuales

Una vez analizada la informacin obtenida en la des-cripcin de la situacin actual de los sistemas estudia-dos en la empresa Soluciones Abiertas, se ha llegado alas siguientes conclusiones:

Sistema web: se ha detectado que la posibilidad degestin del contenido del sitio web corporativo es muylimitada, ya que nicamente permite que la seccin denovedades y noticias sea verdaderamente dinmica ypor tanto se actualice cada cierto tiempo. Adems, losconocimientos necesarios para la gestin de los conte-nidos del sitio son demasiados, ya que esta labor de-bera poder ser llevada a cabo por personal expertoen comunicacin, no en tecnologa. El personal demarketing consultado ha dejado tambin patente lanecesidad de actualizar el sitio web a nivel visual.

Aplicaciones de gestin: se ha detectado la necesi-dad de incorporar a estas aplicaciones nuevas fun-cionalidades que permitan explotar las posibilidadesque brindan los mtodos de comercializacin que sepretenden poner en prctica. Estos cambios se po-drn incorporar al mantenimiento evolutivo del siste-ma que ya se est realizando, ya que ste est vivo yha venido cambiando junto con las necesidades de laempresa desde que se implant.

1.3. Definicin de los requisitos del sistema

19

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

La descripcin de cada requisito incluir una explicacin de ste, la

prioridad que se le asigna y una catalogacin dentro de un conjunto

de categoras definidas.

Caso prctico

Definicin general de requisitos del sistema

Mediante el estudio del sistema del sitio web actual, lospuntos de mejora y problemas detectados, y las entre-vistas con los usuarios de ste, se han identificado y ca-talogado los siguientes requisitos (la prioridad de cadauno de ellos est indicada como un nmero entre 0 y100, siendo 100 el prioritario).

Requisitos tcnicos:

(100) Arquitectura: el contenido del sitio web deberpoderse administrar mediante la utilizacin de cual-quier navegador.

(80) Arquitectura: el contenido del sitio web deberestar almacenado en un sistema gestor de bases dedatos relacionales, sobre el cual se puedan realizarfuturas consultas no previstas en la actualidad.

(80) Seguridad: el contenido del sitio web nica-mente podr ser modificado por aquellas personasautorizadas para ello.

(80) Seguridad: se podrn realizar copias de segu-ridad por separado y conjuntamente del contenidodel sitio web y de la forma en que ste se mostrar.

(80) Normativas y/o estndares: el sitio web debercumplir con los estndares marcados por el WorldWide Web Consortium (HTML, CSS, etc.).

(80) Normativas y/o estndares: el sitio web debercumplir con las normas de accesibilidad marcadaspor el World Wide Web Consortium (Web Accessibi-lity Initiative).

Requisitos operativos:

(100) Operativa: el sitio web deber ser visualmenteatractivo.

Software libre

20

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

(10) Operativa: el sitio web deber poder ser con-sultado, manteniendo sus caractersticas visuales, atravs de dispositivos diferentes a ordenadores per-sonales que posean conexin a Internet y un nave-gador web, tales como televisores, PDA (personaldigital assistant), etc.

(80) Operativa: el sitio web deber posibilitar la vi-sualizacin de cualquier tipo de contenido multime-dia (texto, grficos, vdeos, etc.).

(90) Operativa: el sitio web deber tener una estruc-tura clara, ordenando el contenido de ste en sec-ciones y subsecciones que abarquen cualquieraspecto de los que se quieran comunicar.

(100) Operativa: el sitio web deber permitir la con-tratacin de paquetes de horas a travs del pago destas con tarjeta de crdito, generndose la corres-pondiente factura, pedido, etc.

(100) Operativa: la gestin del contenido del sitioweb deber poder ser realizada por una persona notcnica, es decir, que no tenga conocimientos deHTML, JavaScript, etc., de forma fcil e intuitiva.

(40) Administracin: la administracin del sitio web(consulta de estadsticas, mantenimiento de cachs,etc.) deber poder realizarse a travs de un navega-dor web.

Requisitos legales:

(60) La licencia de uso del software de gestin decontenidos debe ser lo menos restrictiva posible.

(60) La licencia de uso del sistema operativo del ser-vidor web debe ser lo menos restrictiva posible.

Requisitos econmicos:

(80) En el caso de ser necesario un gasto en concep-to de licencia de uso del software de gestin de con-tenidos, ste deber ser lo ms pequeo posible.

(80) El gasto correspondiente al sistema operativodel servidor web debe ser lo ms pequeo posible.

En el resto del curso noscentraremos en el estudiodel sistema del sitio webcomo ejemplo particular delcaso prctico planteadohasta el momento. Para elsistema de aplicaciones degestin sera necesario se-guir el mismo proceso quese describir de este puntoen adelante.

Nota

21

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez expresados los requisitos que deber cumplir el proyecto so-

bre el que se est realizando el estudio de viabilidad, se pasar a

proponer varias soluciones alternativas que cumplan con stos. En

esta fase se tendr en consideracin, asimismo, toda la informacin

recogida hasta el momento: descripcin general, alcance, situacin

actual, etc.

Para cada alternativa se deber especificar en qu consiste,

tanto a nivel funcional como tcnico (estudiando en qu medi-

da se cubren los requisitos descritos previamente), si est basada

o no en algn producto ya existente en el mercado (en tal caso,

se estudiar ste, describiendo posibles costes de licencias, evo-

lucin prevista, estndares que cumple, etc.), y si supone o no la

necesidad de realizar algn desarrollo a medida (en tal caso, se

deber describir ste de tal modo que quede claro cul es su al-

cance).

1.4. Estudio de las alternativas de solucin

Caso prctico

Soluciones alternativas del sistema

Como ejemplo de alternativas al sistema web se propo-

nen tres soluciones posibles, las cuales tienen las si-

guientes caractersticas:

Microsoft Windows + aplicacin propietaria: en

este caso, el sistema operativo del servidor web

ser Microsoft Windows 2000, y la gestin de

contenidos se har mediante la adquisicin de un

software especfico dedicado a tal efecto, por

ejemplo HardCore Web Content Management

(http://www.hardcoreinternet.co.uk/). Se ha com-

probado que el software de gestin de contenidos

elegido cumple con los requisitos funcionales y

tcnicos definidos al respecto. En lo referente a los

requisitos legales y econmicos de la solucin

propuesta, el sistema operativo no cumple con lo

expresado, y el software de gestin de contenidos

slo lo hace en parte.

Software libre

22

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

GNU/Linux + aplicacin propietaria: en este caso el

sistema operativo del servidor web sera GNU/Linux

(en cualquiera de sus distribuciones), sin embargo el

software de gestin de contenidos sera propietario,

por ejemplo HardCore Web Content Management. Se

ha comprobado que el software de gestin de conte-

nidos elegido cumple con los requisitos funcionales y

tcnicos definidos al respecto. En lo referente a los re-

quisitos legales y econmicos, el sistema operativo

cumple con ellos (ya que no es necesario pagar ningu-

na licencia de uso, y adems se nos permite hasta es-

tudiar y modificar el cdigo fuente de ste), pero no as

el software de gestin de contenidos (ya que ste es

propietario y no los cumple en su totalidad).

GNU/Linux + aplicacin libre: en este caso tanto el

sistema operativo del servidor de web como el soft-

ware de gestin de contenidos seran libres (por

ejemplo ezPublish, http://www.ez.no/, Drupal,

http://www.drupal.org). Se ha comprobado que el

software de gestin de contenidos elegido cumple

con los requisitos funcionales y tcnicos definidos al

respecto, siendo su configuracin inicial ligeramen-

te ms complicada que la del software propietario

tomado como referencia en los anteriores puntos.

En cuanto a los requisitos legales y econmicos, se

cubren perfectamente, ya que las licencias son muy

flexibles y los costes de adquisicin son nulos.

En los tres casos ser necesaria la realizacin de un

mdulo de software que recoja la informacin genera-

da en el proceso de compra de paquetes de horas va

web (datos de cliente, datos de producto adquirido, tar-

jeta de crdito, etc.) y la incorpore al programa de ges-

tin administrativa de la empresa.

Sobre la base de la informacin obtenida por diferen-

tes canales (informes, foros de discusin, experiencia

del personal de la empresa, etc.), se ha considerado

que el coste de instalacin y mantenimiento de los

componentes es igual en los tres casos.

23

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez se han estudiado las soluciones alternativas dentro del pro-

yecto sobre el que se est haciendo el estudio de viabilidad, se debe

pasar a valorarlas considerando su viabilidad econmica (anlisis

costes/beneficios) y riesgos que comportan.

Para cada una de las posibles soluciones, se deber estudiar su via-

bilidad econmica, esto es, confeccionar un anlisis costes/benefi-

cios que deje patente el gasto que ser necesario realizar y lo que se

espera obtener a cambio (tanto de forma tangible como intangible).

1.5. Valoracin de las alternativas

Caso prctico

Anlisis costes/beneficios del sistema

Los costes de adquisicin imputados a cada una de lassoluciones son:

Microsoft Windows + aplicacin propietaria = = 550 + 2.000 = 2.550 .

GNU/Linux + aplicacin propietaria = = 0 + 2.000 = 2.000 .

GNU/Linux + aplicacin libre = = 0 + 0 = 0 .

Dado que consideramos que los costes de instalacin ymantenimiento son los mismos para los tres casos, s-tos no tendrn efecto en la comparacin que estamosrealizando (en un caso real podran tener mucha im-portancia, ya que no nicamente se compararan lasdiferentes soluciones, sino que se estudiara la viabili-dad econmica de elegir cualquiera de ellas).

En el caso de la tercera opcin, GNU/Linux + aplicacinlibre, debemos tener en cuenta el coste aadido asocia-do a la complejidad de su configuracin inicial, dadoque suponemos que sta no es tan fcil de realizar comola de la aplicacin propietaria. Suponemos que el hechode utilizar la aplicacin libre frente a la aplicacin pro-pietaria requerir 10 horas extra de dedicacin (a unprecio medio de 50 /hora) acerca de la utilizacin de laprimera. Es necesario sumar por tanto este coste al de ad-quisicin: 0 + 500 = 500 . Los beneficios de cadauna de las soluciones son los descritos en apartados an-teriores (requisitos, descripcin, etc.).

Los precios indicados sonficticios, utilizados nica-mente a modo de ejemplo.

Nota

Software libre

24

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Adems de estudiar la viabilidad econmica de las diferentes solu-

ciones, deberemos tener en cuenta los riesgos asociados a cada una

de ellas. Para cada una de las alternativas existentes, describiremos

qu incertidumbres, problemas potenciales, etc. existen.

Caso prctico

Riesgos en las alternativas del sistema

Los riesgos asociados a cada una de las soluciones al-ternativas son los siguientes:

Microsoft Windows + aplicacin propietaria: Sistema operativo: cambio en la estrategia de

negocio del fabricante, desapareciendo el sopor-te dado hasta el momento y hacindose necesa-ria una actualizacin.

Sistema operativo: fallos de seguridad detecta-dos pero no subsanados por el fabricante en unperiodo de tiempo razonable.

Aplicacin propietaria: desaparicin del fabri-cante del producto, o cambio de estrategia denegocio (dado que la licencia, aunque propieta-ria, permite disponer del cdigo fuente de laaplicacin, este hecho supondra que cualquiererror o problema debera ser subsanado por elequipo de Soluciones Abiertas).

GNU/Linux + aplicacin propietaria Sistema operativo: se podra dar la falta de so-

porte en determinados casos, ya que no existe unsolo fabricante que centralice el desarrollo delsistema operativo.

Aplicacin propietaria: desaparicin del fabricantedel producto, o cambio de estrategia de negocio(dado que la licencia, aunque propietaria, permitedisponer del cdigo fuente de la aplicacin, estehecho supondra que cualquier error o problemadebera ser subsanado por el equipo de SolucionesAbiertas).

GNU/Linux + aplicacin libre Sistema operativo: se podra dar la falta de so-

porte en determinados casos, ya que no existe unsolo fabricante que centralice el desarrollo delsistema operativo.

Aplicacin libre: desaparicin del equipo principalde desarrolladores que mantienen la aplicacin.

25

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Llegados a este punto, se deber realizar una propuesta de enfoque

con el fin de paliar en la medida de lo posible los riesgos antes

descritos. De este modo intentaremos reflejar si estos riesgos son sal-

vables, hacindose relevante su importancia relativa.

Caso prctico

Paliacin de riesgos en las alternativas del sistema

Los posibles enfoques con el fin de paliar los riesgos

asociados a cada una de las soluciones alternativas

son los siguientes:

Microsoft Windows + aplicacin propietaria:

Sistema operativo: firma de contrato de soportedel sistema operativo con el fabricante de stepor un periodo de tiempo igual al que estimemosser la vida del sistema web tal y como lo esta-mos estudiando. Esta solucin debe ser aceptadapor el fabricante para poder llevarse a cabo.

Sistema operativo: firma de contrato de soportecon indemnizaciones en caso de producirse fa-llos en la seguridad del sistema debido a proble-mas en el sistema operativo. Esta solucin debeser aceptada por el fabricante para poder llevar-se a cabo.

Aplicacin propietaria: firma de contrato en elcual el fabricante se comprometa a licenciar deforma libre el cdigo fuente de su aplicacin encaso de que cese su actividad.

GNU/Linux + aplicacin propietaria

Sistema operativo: puede contratarse el soportede una empresa externa que se comprometa acentralizar y resolver los posibles problemas quepuedan surgir.

Aplicacin propietaria: firma de contrato en elcual el fabricante se comprometa a licenciar deforma libre el cdigo fuente de su aplicacin encaso de que cese su actividad.

GNU/Linux + aplicacin libre

Sistema operativo: puede contratarse el soportede una empresa externa que se comprometa acentralizar y resolver los posibles problemas quepuedan surgir.

Software libre

26

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Para acabar con el estudio de viabilidad, se elegir una solucin de

entre las diferentes alternativas estudiadas.

La decisin sobre cul es la mejor solucin (o si ninguna lo es) se to-

mar teniendo en cuenta la informacin acumulada hasta el mo-

mento:

Descripcin general y alcance del proyecto.

Situacin actual del sistema.

Requisitos que deber cumplir la solucin adoptada.

Descripcin de las soluciones alternativas consideradas.

Anlisis de costes/beneficios de las diferentes soluciones y riesgos

asociados a cada una de ellas.

Aplicacin libre: se debe valorar la estabilidad yalcance de la comunidad formada en torno a laaplicacin, ya que en caso de que el equipo prin-cipal de desarrolladores desaparezca, la continui-dad de sta depender del nmero de personasque la utilizan y desarrollan espordicamente entodo el mundo.

1.6. Seleccin de la solucin

Caso prctico

Seleccin de la solucin adoptada en el sistema

Dada la descripcin general del sistema y la situacinactual de ste, se han considerado los siguientes facto-res con el fin de realizar la eleccin de la solucin:

Requisitos planteados y descripcin de cada una delas soluciones: todas las soluciones cubren en ma-yor o menor medida los requisitos bsicos a nivelfuncional y tcnico. En cuanto a los aspectos econ-micos y legales, la solucin GNU/Linux + aplica-cin libre es la ganadora.

27

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Anlisis costes/beneficios: este anlisis ha dadocomo resultado tres costes, entre los cuales la solu-cin GNU/Linux + aplicacin libre es la ms bara-ta. Dado que los beneficios aportados por cadasolucin son parecidos en trminos generales (des-de luego podran discutirse ciertos detalles en losque s que hay diferencias significativas, pero queno decantan definitivamente la balanza por una uotra solucin), se ha optado por valorar como mspositiva la solucin GNU/Linux + aplicacin libre.

Riesgos: se han detectado posibles problemas de di-ferentes tipos en cada una de las soluciones, siendolos de ms fcil solucin los relacionados con el sis-tema operativo GNU/Linux y la aplicacin de gestinde contenidos libre (precisamente por su carctermarcadamente abierto en comparacin con el resto).

Se decide por tanto que la solucin en GNU/Linux +aplicacin libre de copias de seguridad es la ms ade-cuada de entre todas las consideradas.

29

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

El objetivo de la realizacin del anlisis del sistema es el de, dada

la solucin escogida de entre las descritas en el estudio de viabilidad,

llevar a cabo una especificacin detallada de sta (orientada a fa-

cilitar el diseo del sistema, fase cubierta en el siguiente captulo).

Los siguientes apartados describen con ms detalle cada una de las

tareas que hay que llevar a cabo para realizar el anlisis del sistema.

En esta fase del anlisis se deber describir el sistema, establecer

cmo se comunicar con otros en caso de ser necesario y qu

usuarios sern representativos en el uso del mismo.

Como el lector recordar, ya en la fase de estudio de viabilidad se

procedi a describir el sistema genricamente, as como a definir

cmo afectaba ste al resto de sistemas ya existentes (o proyectos

que se pensaba llevar a cabo). El trabajo realizado en dicha fase ser-

vir como base de las tareas realizadas en el presente anlisis.

Utilizando como punto de partida la descripcin de los requisitos he-

cha en el estudio de viabilidad, se determinarn los requisitos exac-

tos del sistema. Asimismo, se estudiar cmo se comunica el

sistema con el resto de sistemas existentes (ya sea recibiendo o en-

viado informacin a stos).

2. Anlisis del sistema

2.1. Definicin del sistema

Caso prctico

Requisitos exactos del sistema web

El sistema web de Soluciones Abiertas deber cumplirlos siguientes requisitos:

La informacin deber ser presentada de formaatractiva, en consonancia con la imagen corporati-va de la empresa (colores, fuentes, logotipo, etc.).

Software libre

30

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

El contenido del sitio web deber ser administradomediante una herramienta que permita crearlo, ac-tualizarlo y borrarlo de forma fcil e intuitiva.

Debern poder almacenarse diferentes versionesdel contenido del sitio web, siendo una de stas lamarcada como publicada (ser por tanto la quese muestre a los visitantes del sitio web).

Deber poderse establecer un flujo de trabajo quemarque la evolucin del contenido creado. As, porejemplo, una persona podra crear cierto nuevocontenido, pero no publicarlo. Otra persona podranicamente editar aquel contenido ya existente,como el mencionado anteriormente. Finalmente,una tercera persona podra aprobarlo para su pu-blicacin y efectuar la publicacin de ste.

La edicin del contenido del sitio web deber ser loms fcil posible, evitando que las personas quedesempeen esta tarea deban conocer HTML, CSS,etc. Para ello, deber existir un editor WYSIWYG(what you see is what you get) que permita creartexto, subrayarlo, aadir negritas, crear tablas, in-sertar imgenes, etc.

La edicin del contenido del sitio web deber poderrealizarse mediante las versiones ms recientes decualquiera de los navegadores ms populares, espe-cialmente Microsoft Internet Explorer (versin 6.0 oposterior) y Mozilla Firefox (versin 1.0 o posterior).

nicamente aquellas personas autorizadas paraello podrn acceder al sistema de gestin de conte-nidos. Esta autorizacin consistir en que cada unade dichas personas poseer un nombre de usuarioy una contrasea vlidos en el sistema.

Debern poderse definir perfiles de usuarios del sis-tema de gestin de contenidos, que tengan relacincon las tareas que estn autorizados a realizar stos(relacionado con el requisito de existencia de flujosde trabajo).

El sitio web pblico deber cumplir el estndarHTML 4.01.

31

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

El sitio web pblico deber hacer un uso intensivo dehojas de estilo, siguiendo el estndar CSS (cascadingstyle sheets) 2.0 (teniendo en cuenta que algunosnavegadores no lo soportan en su totalidad).

El sitio web pblico deber seguir las recomenda-ciones marcadas en las Web Content AccessibilityGuidelines versin 1.0 del World Wide Web Con-sortium.

El contenido del sitio web deber poder ser ordena-do de forma jerrquica, es decir, en apartados ysubapartados. No existir ningn lmite tcnico encuanto a la posible adicin de nuevos apartados.

Los administradores del sitio web debern poderconsultar las estadsticas de acceso a ste, que reco-gern valores como el nmero de pginas vistasdiariamente, mensualmente y anualmente, nmerode visitas, pginas ms consultadas, navegadoresclientes ms habituales, etc.

El sitio web deber permitir la compra de paquetesde horas de prestacin de servicios, efectuando elpago de stos mediante tarjeta de dbito o crdito.

Las comunicaciones existentes entre el sistema web ycualquier otro sistema, especialmente el de las apli-caciones de gestin de sta, se realizarn mediantellamadas a servicios web. As, por ejemplo, el sistemaweb comunicar que se ha realizado una compra depaquete de horas a la aplicacin de gestin a travsde un servicio web ofrecido por esta ltima.

La licencia de uso del software de gestin de conte-nidos deber ser lo menos restrictiva posible, enconcreto deber ser de cdigo abierto o libre.

Las licencias de uso de las aplicaciones utilizadaspor el software de gestin de contenidos (sistemagestor de base de datos, intrprete de scripts, etc.)debern ser lo menos restrictivas posibles, en con-creto debern ser de cdigo abierto o libre.

La licencia de uso del sistema operativo del servidorweb ser la correspondiente a GNU/Linux, es decir,GNU General Public License.

Software libre

32

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

En la definicin del sistema tambin ser necesario definir el entorno

tecnolgico del proyecto, respecto del cual ya se incluy informacin

en el estudio de viabilidad.

Para completar la descripcin del sistema, ser necesario hacer re-

ferencia al conjunto de estndares y normas que hay que considerar

en la implementacin de ste.

Caso prctico

Entorno tecnolgico del sistema

El entorno tecnolgico del sistema web ser el siguiente:

Sistema operativo: GNU/Linux (distribucin por de-terminar).

Sistema de gestin de contenidos: deber poderejecutarse en el sistema operativo GNU/Linux y es-tar hecho en un lenguaje que el equipo de personasde Soluciones Abiertas conozca (p. ej., PHP, Perl,Python, Java).

Desarrollos a medida: en el caso de ser necesariorealizar algn tipo de desarrollo, se llevar a caboutilizando las tecnologas habituales en el proyectoque se est modificando (p. ej., PHP en caso de queel desarrollo est relacionado con el gestor de conte-nidos, C++ en caso de que el desarrollo est relacio-nado con la aplicacin de gestin de la empresa).

Caso prctico

Normas que cabe seguir en el sistema web

Las normas y estndares que hay que seguir en la im-plementacin del sistema web sern las siguientes:

En cuanto al sistema operativo, se seguir el proce-so documentado como Instalacin de servidoresGNU/Linux de Soluciones Abiertas, S. A.

El software de gestin de contenidos deber permitirel uso de los estndares web de facto y de jure mshabituales (HTML, CSS, JavaScript, etc.). Para msinformacin, podis consultar el apartado Requisi-tos exactos del sistema.

33

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez descrito el sistema, se proceder a identificar a aquellos

usuarios que intervendrn en la definicin de requisitos de ste y

en su aceptacin definitiva. Es especialmente importante contar con

la colaboracin de los usuarios a lo largo de todo el proceso de de-

sarrollo del sistema.

El objetivo de esta fase ser completar los requisitos definidos an-

teriormente, contando con la informacin suministrada por los

usuarios. En la medida de lo necesario, se dividir el sistema en

subsistemas que permitan su estudio por separado, con el fin de fa-

cilitar el anlisis de stos.

Los posibles desarrollos a medida seguirn las nor-mas internas de Soluciones Abiertas, S. A., es decir,las que se recogen en el documento Normas dedesarrollo de Soluciones Abiertas, S. A.. En este do-cumento quedan recogidas las normas que hay queseguir en el desarrollo de cualquier proyecto, talescomo utilizacin de diagramas UML, formato de do-cumentacin del cdigo, etc.

Caso prctico

Identificacin de usuarios del sistema web

El personal involucrado en la definicin de requisitos yaceptacin de la solucin final del sistema web de So-luciones Abiertas es:

El personal del departamento de marketing encar-gado de la creacin y actualizacin del contenidoque se muestra en el sitio web de la empresa.

El personal del departamento de administracin en-cargado de la facturacin de la empresa, gestin denuevos pedidos, etc.

Los administradores del sistema web, encargadosde que ste funcione en todo momento, as como elpersonal tcnico encargado del mantenimiento co-rrectivo y evolutivo del sistema web.

2.2. Establecimiento de requisitos

Software libre

34

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

La comparacin de la descripcin de cada uno de los requisitos ex-

presados en esta fase del proyecto con el diseo creado con poste-

rioridad nos permitir verificar la correccin de este ltimo.

El primer paso en el proceso de establecimiento de requisitos ser el

de obtener los requisitos a partir de la informacin suministrada

por los usuarios. Los requisitos recogidos en las reuniones manteni-

das con los usuarios elegidos en la fase anterior sern bsicamente

de los siguientes tipos:

Funcionales (p. ej., mediante el sistema de gestin de contenidos

se deber poder modificar cualquier pgina del web corporativo,

sea cual sea su contenido).

Rendimiento (p. ej., la carga de cualquier pgina del sitio web

corporativo, en condiciones normales de utilizacin de la red, no

puede tardar ms de 8 segundos).

Seguridad (p. ej., slo podrn modificar el contenido del sitio web

aquellas personas que estn autorizadas para ello).

Implantacin (p. ej., el servidor web estar alojado en un lugar

fsicamente seguro).

Disponibilidad (p. ej., el sistema web deber ser monitorizado cada

30 minutos con el fin de comprobar su correcto funcionamiento).

Caso prctico

Definicin del requisito compra de paquetes dehoras

Con relacin a la compra mediante el sitio web de la em-presa de paquetes de horas de prestacin de servicios,efectuando el pago de stos mediante tarjeta de dbito ocrdito, se han determinado los siguientes requisitos:

Junto con el personal del Departamento de Admi-nistracin se ha determinado que el pago de los pa-quetes de horas se realizar mediante la utilizacindel terminal punto de venta virtual ofrecido por laentidad bancaria con la que Soluciones Abiertas tra-baja habitualmente. De esta forma se obtendrnmejores condiciones econmicas por transaccin yse facilitar la operativa habitual.

35

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

De acuerdo con el personal del Departamento deMarketing se ha determinado qu datos sern losque los clientes debern suministrar para la correctarealizacin de la compra de paquetes de horas: da-tos personales (nombre y apellidos, telfono, direc-cin de correo electrnico, departamento dentro dela empresa), datos de la empresa (razn social, n-mero de identificacin fiscal, direccin postal, tel-fono, fax, direccin de correo electrnico). Junto conlos mencionados datos, se permitir tambin intro-ducir cualquier tipo de observacin sobre el pedidoque se est realizando.

A peticin del personal del Departamento de Mar-keting, y teniendo en cuenta la legislacin vigente,se ha decidido que la contratacin de paquetes dehoras mediante el sitio web debe ser lo ms seguraposible, evitando que los datos del cliente (domici-lio, nmero de tarjeta, etc.) puedan ser descubiertospor terceros (utilizacin de Secure Sockets Layer tan-to en el sitio web corporativo, como en el terminalpunto de venta virtual utilizado). El objetivo es ven-cer las posibles reticencias que los clientes tenganen cuanto a la seguridad a la hora de facilitar susdatos y realizar el pago mediante Internet.

El personal del departamento de marketing ha de-terminado que la contratacin de un paquete de ho-ras deber tener como resultado el envo por correoelectrnico de una factura a la direccin indicadapor el cliente. Los datos de esta factura (especial-mente el nmero de sta) sern obtenidos median-te la comunicacin con la aplicacin de gestin dela empresa (esta decisin ha sido contrastada con laopinin del departamento de administracin).

La contratacin de un paquete de horas tendr comoresultado la creacin de un pedido en la aplicacin degestin de la empresa. Este pedido servir para iden-tificar el servicio contratado de forma unvoca en cual-quier momento, cules son sus caractersticas y cul essu estado (tipo de servicio contratado, horas consumi-das hasta el momento, etc.). Esta informacin es laque habitualmente maneja el Departamento de Admi-nistracin, y que tambin sirve como referencia al deproduccin/servicios.

Software libre

36

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez descritos cada uno de los requisitos, se proceder a la espe-

cificacin de los casos de uso de cada uno de ellos. Los casos de uso,

adems de la descripcin en s del problema, incluirn cmo interac-

tuarn los usuarios con el sistema, qu interfaces utilizarn y cmo

se tratarn las condiciones de fallo.

Caso prctico

Caso de uso compra de paquetes de horas

Los usuarios del departamento de marketing actualiza-rn el contenido del sitio web corporativo para que enste figure la informacin ms actualizada sobre losservicios ofrecidos por Soluciones Abiertas, los honora-rios sobre stos, posibles promociones, etc. Los clienteso futuros clientes podrn acceder a esta informacin, yen caso de estar interesados realizar un pedido (lacompra de un paquete de horas de prestacin de ser-vicios).

La realizacin de un pedido comportar llevar a cabo lassiguientes tareas: introduccin de los datos personales yde la empresa que realiza la contratacin, realizacin dela compra a travs del terminal punto de venta virtual delbanco, introduciendo el correspondiente nmero de tarje-ta de crdito, y la creacin de un pedido y una facturaasociadas a la contratacin realizada. Estos dos ltimospasos se llevarn a cabo teniendo en cuenta que ambosdebern coordinarse con sistemas externos.

La navegacin a travs de la informacin del sitio webgenerar una serie de mensajes que se procesarn aposteriori para la realizacin de las estadsticas de ac-ceso a ste, que nicamente los administradores po-drn consultar.

Figura 2-1. Diagrama de caso de uso

37

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

A la vez que se describen los requisitos y sus casos de uso corres-

pondientes, se analizarn stos con el fin de detectar posibles in-

consistencias (dado que pueden intervenir diferentes usuarios con

diferentes necesidades), duplicidades, etc., y las posibles asocia-

ciones entre stos.

En esta fase del anlisis se especifican cmo sern las diferentes

interfaces que habr entre el sistema que estamos describiendo y

los usuarios de ste. Esta especificacin se har teniendo en cuenta

los diferentes perfiles de usuarios, flexibilidad necesaria, tipos de ac-

ciones que hay que llevar a cabo, etc.

El primer paso en la definicin de las interfaces de usuario ser el de

definir los perfiles de usuarios que utilizarn el sistema. De este

modo, se podr describir posteriormente a qu tipos de interfaces

acceder cada uno de ellos.

Caso prctico

Asociaciones de un caso de uso

El caso de uso referente a la compra de paquetes dehoras por parte de los clientes est directamente rela-cionado con los siguientes casos de uso:

El proceso y la informacin manejada al recoger losdatos de un cliente deben ser comunes o muy pare-cidos al de la seccin Pngase en contacto con no-sotros del sitio web, descrito en el caso de usoContacto.

El mtodo de actualizacin de la informacin acercade los servicios ofrecidos por Soluciones Abiertas debeser exactamente el mismo que el descrito en el casode uso ms general Actualizacin de contenido.

Las estadsticas almacenadas sobre el acceso a lacompra de paquetes de horas deben ser las mismasque las referidas en el caso de uso Estadsticas delsitio web.

2.3. Definicin de interfaces de usuario

Software libre

38

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

A continuacin, se debern especificar los principios generales de

la interfaz de usuario, por ejemplo, si se utilizarn interfaces de texto

o grficas, cmo se mostrarn los mensajes de error, cmo se ob-

tendr ayuda, etc.

Caso prctico

Perfiles de usuarios

La aplicacin de gestin de contenidos, que permitirmantener la informacin mostrada en el sitio web deSoluciones Abiertas, ser utilizada principalmente porlos usuarios del Departamento de Marketing, que engeneral tendrn las siguientes caractersticas:

Usuarios con un perfil no tcnico.

Usuarios acostumbrados a la utilizacin de progra-mas de edicin de documentos y hojas de clculo.

Usuarios acostumbrados a la utilizacin de progra-mas para la realizacin de presentaciones.

Usuarios no acostumbrados a la edicin de ficheros detexto, especialmente aquellos que contienen marcas,instrucciones, etc.

Caso prctico

Principios generales de la interfaz de usuario

La aplicacin de gestin de contenidos tendr las si-guientes caractersticas:

El acceso a la aplicacin y su uso se realizar a tra-vs de un navegador web.

La edicin de cualquier tipo de contenido se realiza-r a travs de formularios web en los que se mostrarla informacin ya existente para cambiarla o se in-troducir la nueva.

Existir un tipo de formulario especial, que servirpara introducir el grueso de la informacin del sitioweb, que dispondr de controles especiales quepermitan la edicin WYSIWYG.

Los mensajes de error sern mostrados en general porpantalla, en la medida de lo posible acompaados deun nmero que los identifique de forma unvoca.

39

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez identificadas las caractersticas generales de la interfaz de

usuario, se pasar a especificar sta para cada uno de los casos

de uso definidos en el apartado anterior.

Aquellos mensajes de error que no se puedanmostrar por pantalla de forma detallada a losusuarios de la aplicacin (p. ej., si se produce unerror cuando un cliente est realizando un pago atravs del mdulo de comercio electrnico), sernenviados por correo electrnico al administradordel sitio web.

La ayuda a nivel funcional de la aplicacin de ges-tin de contenidos estar integrada dentro de sta,formando parte de las pginas que permitan la edi-cin de la informacin o presentndose como enla-ces dentro de stas.

Ejemplo

Interfaz de usuario

El siguiente diagrama recoge cul deber ser la in-formacin ofrecida por la interfaz de usuario de laaplicacin de gestin de contenidos, y cul ser sudisposicin (en la medida de lo posible se intentarseguir este esquema, aunque est sujeto a posterio-res decisiones de diseo).

Figura 2-2. Esquema de interfaz de usuario

Software libre

40

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Para acabar con la fase de anlisis, se proceder a realizar la espe-

cificacin del plan de pruebas, que nos servir para establecer si el

sistema cumple con los requisitos establecidos por los usuarios.

Se podrn realizar pruebas del sistema a varios niveles:

Pruebas unitarias, con el fin de testar por separado cada uno de

los componentes que forman el sistema (p. ej., prueba de co-

nexin al terminal punto de venta virtual del banco elegido).

Pruebas de integracin, con el fin de testar el funcionamiento de

los componentes actuando de manera coordinada, es decir, tes-

tar cada uno de los subsistemas que forman el sistema (p. ej.,

prueba de creacin de un nuevo pedido en la aplicacin de ges-

tin de la empresa).

Pruebas de sistema, con el fin de testar el funcionamiento de los sub-

sistemas actuando de manera coordinada (p. ej., prueba de acceso

intensivo a los contenidos del sitio web de Soluciones Abiertas).

Pruebas de implantacin, con el fin de testar el funcionamiento del

sistema en el entorno de operacin de ste (p. ej., prueba de volcado

y recuperacin de la base de datos que alberga el contenido del sitio

web, una vez instalada en el/los servidor/es de produccin).

Pruebas de aceptacin, con el fin de que los usuarios del sistema

validen el correcto funcionamiento de ste (p. ej., realizacin de

una compra completa de un paquete de horas de servicio por

parte de un usuario del Departamento de Marketing). Este con-

junto de pruebas es crtico, ya que ser el que permitir validar el

sistema completo. Adems del correcto funcionamiento del siste-

ma, se debern tener en cuenta parmetros como la seguridad,

rendimiento, disponibilidad, etc.

Para cada una de las pruebas que hay que realizar, se deber definir

el alcance de stas (p. ej., usuarios implicados en las pruebas, pro-

ductos de las pruebas, criterios de aceptacin de las pruebas, etc.), y

los requisitos en el entorno de pruebas (hardware necesario, libre-

ras disponibles, configuracin de accesos, etc.).

2.4. Especificacin del plan de pruebas

41

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Caso prctico

Prueba de integracin

La prueba de integracin del sistema web con la apli-cacin de gestin de la empresa tendr las siguientescaractersticas:

Permitir al personal del departamento de adminis-tracin comprobar que las compras realizadas atravs del sistema web se integran de manera co-rrecta con la aplicacin de gestin utilizada habi-tualmente por ellos.

Como producto de la prueba se obtendr un nuevopedido con los datos introducidos a travs del siste-ma web (cliente que lo ha encargado, nmero dehoras contratadas, etc.). El nmero de este pedidodeber tener sentido dentro de la aplicacin (no es-tar repetido, ser consecutivo con respecto al ltimorealizado antes de l, etc.).

Como producto de la prueba tambin se obtendruna factura con los datos correspondientes al clienteque ha realizado el pedido. El nmero de esta fac-tura deber haberse asignado de forma consecutivaa la anterior a ella en el tiempo.

La prueba se dar por correcta cuando los usuariosde la aplicacin de gestin de la empresa hayan va-lidado el pedido y la factura generados, dedicandoespecial atencin a los nmeros de stos.

Con el fin de poder realizar la prueba, ser necesario:

Disponer del mdulo de comercio electrnico delsistema web completamente acabado, ejecutndo-se en un servidor alojado en la red sobre la cual seimplantar definitivamente.

Disponer de un acceso al terminal punto de ventade la entidad bancaria escogida, preferiblementeen modo de pruebas (aceptando pagos con tarjetasinexistentes).

Disponer del mdulo de atencin de peticiones re-motas desde el sistema web a la aplicacin de ges-tin, as como un usuario y contrasea vlidos paraacceder a ste.

43

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

El objetivo de la fase de diseo de un proyecto web es obtener los

modelos y especificaciones que lo definen a partir del anlisis rea-

lizado en la fase anterior. Las actividades que llevemos a cabo en

esta fase nos permitirn determinar las especificaciones de desarro-

llo e integracin, as como definir el entorno de pruebas e implanta-

cin necesarios para su correcto funcionamiento.

Concretamente, los resultados que deberemos obtener en esta fase

sern:

La definicin del modelo arquitectnico del sistema. Mediante la

identificacin de sus componentes, sus interacciones y la ayuda

de herramientas de modelado obtendremos un mapa de los sub-

sistemas y recursos que intervienen en todos los procesos.

Las especificaciones y estndares que se usarn tanto en esta mis-

ma fase como durante el desarrollo del sistema.

La identificacin de cada subsistema, sus requisitos de integra-

cin, licencia y funcionalidades cubiertas.

Los casos de uso aplicados de los subsistemas anteriormente

identificados, debidamente revisados para reflejar el modelo y es-

pecificaciones definidos.

Los componentes, clases o interfaces que deberemos construir en

la fase de desarrollo.

Los requisitos necesarios para proceder con xito a la implanta-

cin del sistema.

Como vemos, muchos conceptos y especificaciones van a determi-

narse en esta fase, y aunque algunas metodologas recientes acon-

sejan mezclarla con la fase de desarrollo en un ciclo combinado de

diseo y construccin iterativo, con el objetivo de obtener resultados

pronto o de identificar fallos en el diseo a tiempo, es obvio que las

decisiones en cuanto a especificaciones, estndares o subsistemas

que tomemos aqu van a facilitar todas las tareas futuras.

3. Diseo del sistema

Software libre

44

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Especialmente importante es la identificacin de los componentes

que hay que usar y sus licencias, ya que stos pueden determinar

parte de la funcionalidad, la necesidad de desarrollos internos de co-

municacin entre subsistemas o el tipo de licencia con que debere-

mos distribuir (si procede) el resultado de nuestro proyecto.

La definicin de la arquitectura del sistema es el primer paso para

identificar los componentes del mismo y da lugar a las siguientes

fases de diseo en las que profundizaremos en cada uno de ellos. El

objetivo es disponer de un conjunto de documentos y diagramas

completos y concisos que sean comprensibles para la direccin y a

la vez sirvan de base para profundizar en el diseo del sistema.

Antes de realizar el diseo ms detallado del sistema, ser necesario

definir las normas y estndares de diseo y construccin. Tambin

puede darse el caso de que estas normas y estndares hayan sido ya

definidas en anteriores proyectos, o sean comunes a todos los que

lleva a cabo la organizacin.

Una vez acordados los estndares de diseo, podremos ya profun-

dizar y determinar los subsistemas, repitiendo el mismo proceso que

seguimos con la arquitectura general del sistema, esta vez con mayor

granularidad en cada uno de ellos.

3.1.1. Definicin de niveles de arquitectura

Existen varias formas de ver o entender la arquitectura de un sistema:

Arquitectura conceptual: su propsito es dirigir la atencin sobre

los grandes bloques que forman el sistema, sin entrar en detalles,

e identificar las relaciones entre dichos bloques. Es muy til para

comunicar a la direccin o a departamentos no tcnicos una vi-

sin global del sistema.

Arquitectura lgica: aade detalle a la anterior e incorpora la de-

finicin de las interfaces de comunicaciones entre los componen-

3.1. Arquitectura

45

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

tes, lo que permitir a los desarrolladores de cada componente

trabajar sin dependencias entre ellos.

Como apoyo a los diagramas, podemos utilizar tarjetas CRC (class

responsibility collaborator), que tienen las siguientes caractersticas:

En la parte superior figura el nombre del componente.

En la columna izquierda deberemos reflejar todo lo que el com-

ponente sabe o hace acerca de l mismo. All se incluir todo

aquello que creemos que es de su responsabilidad y la informa-

cin que deber mantener.

En la parte derecha figurarn los componentes con que se rela-

ciona para poder llevar a cabo las responsabilidades de la parte

izquierda.

Estas tarjetas son muy utilizadas en las metodologas eXtreme Pro-

gramming y Agile, y permiten crear el diagrama de componentes

del sistema dinmicamente encima de una mesa simplemente si-

tuando las tarjetas prximas o lejanas entre s segn su grado de co-

municacin, para consensuar as una visin general de la

arquitectura lgica del sistema durante una reunin.

Caso prctico

Definicin de la arquitectura

Para expresar la arquitectura del proyecto del sistemaweb de Soluciones Abiertas, usamos la notacin UMLen los diagramas y tarjetas CRC (Clase-Responsabili-dad-Colaborador).

Figura 3-1. Diagrama UML de componentes

Software libre

46

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

En el diagrama anterior vemos los componentes del siste-ma web y los conectores que los unen. Estos conectoresindican que algn tipo de comunicacin se produce entreellos. Los diferentes componentes en este diagrama estnidentificados mediante los estereotipos que los acompa-an (, , etc.).

Una vez consensuada esta visin general del sistema,pasamos a profundizar en las interfaces de los compo-nentes para obtener la arquitectura lgica del sistema.Para ello, extendemos el diagrama de componentesanterior detallando los procesos de comunicacin.

Como apoyo a la generacin del diagrama anterior,utilizamos tarjetas CRC.

Figura 3-2. Diagrama UML de componentes con interfaces

Tabla 3-1. Ejemplo de tarjeta CRC

Gestin de contenidos

Permite administrar el contenido del sitio web.Muestra el contenido pblico del sitio web.Incorpora comercio electrnico al sitio web.Permite sincronizar los pedidos hechos mediante el sitio web con la gestin habitual de la empresa.Mantiene el registro de accesos realizados al sitio web.

Base de datos de contenidos.Aplicacin de gestin de la empresa.Aplicacin de terminal punto de venta virtual.Ficheros registro de accesos.

47

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

3.1.2. Especificacin de estndares, normas de diseoy construccin

Es importante acordar con las personas encargadas del diseo

del sistema y con los equipos que procedern a su construccin

unas normas que habr que seguir en la notacin de diagramas

y documentos. Estas normas pueden venir dadas por estndares

o por recomendaciones, o bien ser de uso y creacin interna. Ob-

viamente, siempre es recomendable apoyarse en estndares, ya

que va a facilitar la comunicacin, consistencia, reusabilidad y

comprensin por parte de entidades externas o recin incorpora-

das al equipo.

Deberemos definir:

Formato y plantilla de los documentos de diseo.

Notacin a usar en los diagramas de diseo.

Recomendaciones en cuanto al estilo, idioma y formato de la do-

cumentacin tcnica.

Caso prctico

Definicin del conjunto de normas y notaciones

Es conveniente que todos los documentos creados deahora en adelante, y que van a ser objeto de revisin porparte de equipos diferentes, compartan unas caracters-ticas y mantengan un formato coherente. Para ello, des-pus de estudiar los estndares y recomendacionessobre el tema, se llega a las siguientes conclusiones:

Documentos de diseo: estos documentos se de-ben poder consultar tanto por el personal tcnicoimplicado, como por personal no tcnico que pue-da revisarlo o consultarlo. Se acuerda que se tra-bajen en formato OpenDocument y que la versinms reciente est simultneamente en PDF para suconsulta. Se crear una plantilla que contenga enla primera pgina: Ttulo del documento. Responsable del documento. Lista de autores que han intervenido y la fecha de

su primera intervencin.

Software libre

48

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Lista resumida de cambios introducidos en el do-cumento a medida que se vayan produciendo(cambio, fecha y autor).

Diagramas de diseo: para los diagramas de dise-o se acuerda usar la notacin Unified ModelingLanguage, UML (http://www.omg.org/uml/) en suversin 1.5, definida por el Object ManagementGroup (www.omg.org).

Documentacin tcnica: la documentacin tcnicaser posiblemente la que ms revisiones sufrir y con-tendr tambin enlaces a documentaciones de las he-rramientas usadas, especificaciones de programacin(API), etc., por lo que se recomienda usar un forma-to lo ms flexible posible e integrable con las pro-pias herramientas de desarrollo que se usen. Paraello, se decide usar DocBook (www.docbook.org,http://www.oasis-open.org/docbook/), que nos per-mitir:

Particin de un documento en varios ficheros es-tructurados, susceptibles de ser revisados inde-pendientemente.

Fcil inclusin de referencias a otros documentos(enlaces http, figuras, etc.).

Fcil generacin de varios formatos para su vi-sualizacin (PDF, HTML) y con la posibilidad deseparar el contenido del documento de su for-mato.

Independencia de editor usado, ya que es unaimplementacin de XML y, por lo tanto, modifi-cable en cualquier editor de texto.

Incorporar documentacin contenida en el cdi-go fuente generado en la fase de desarrollo, deforma automtica en muchos casos.

Cabe destacar que al tomar las decisiones se ha dadoimportancia a la implantacin del formato o notacinen la industria y a la accesibilidad del mismo, es decir,a la disponibilidad de ejemplos y documentacin, ascomo a un amplio conjunto de herramientas que traba-jen con ellos.

49

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

3.1.3. Identificacin de subsistemas

Para reducir la complejidad que supondra disear al detalle todo el

sistema, ste deber dividirse en subsistemas para facilitar su com-

prensin, revisin y reutilizacin. Este tipo de divisiones se realizar

iterativamente hasta reducir significativamente la complejidad de las

funciones a realizar por los subsistemas resultado.

Para realizar esta divisin, podemos tener en cuenta varios aspectos

de los componentes:

Funcionalidad comn o relacionada por caractersticas de la eje-

cucin.

Gestin de datos, acceso a datos comunes.

Integracin en una interfaz de usuario comn.

Optimizacin de lneas de comunicaciones o recursos.

Caso prctico

Identificacin y diseo de subsistemas

Realizando una primera divisin por funcionalidad,identificamos claramente los siguientes subsistemasdentro del sistema web:

Subsistema gestor de contenidos (permitir adminis-trar y consultar todo el contenido del sitio web).

Subsistema aplicacin gestin de la empresa (per-mitir integrar los pedidos realizados a travs del si-tio web en la operativa normal de la empresa).

Subsistema de estadsticas (permitir consultar la in-formacin agregada de acceso al sitio web).

Como ejemplo de subdivisin, el subsistema gestor decontenidos estar compuesto a su vez por los siguientessubsistemas:

Subsistema de administracin de contenido (permi-tir modificar el contenido del sitio web).

Subsistema de web pblica (permitir mostrar elcontenido a los usuarios del sistema web).

Software libre

50

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Una vez identificados los subsistemas, es el turno de revisar los casos

de uso hechos en la fase de anlisis y determinar las operaciones

que debern implementar las interfaces de cada uno de ellos.

As pues, a partir de los escenarios recogidos en la fase de anlisis,

determinaremos qu subsistemas estn implicados en ellos y disea-

remos su funcionamiento teniendo en cuenta:

El entorno tecnolgico en el que se aplican.

Las excepciones que se produzcan en cada caso de uso.

Detalles relacionados con la implementacin que ya podamos

identificar en esta fase.

Restricciones o caractersticas de la interfaz de usuario.

Nuevos requisitos que podamos identificar.

Subsistema de comercio electrnico (permitir reali-zar pedidos de paquetes de horas de servicio a tra-vs del sitio web, utilizando el terminal punto deventa virtual seleccionado).

Subsistema de pedidos (permitir integrar la infor-macin de los pedidos realizados en la aplicacinde gestin de Soluciones Abiertas).

3.2. Revisin de casos de uso

Figura 3-3. Diagrama UML de componentes, subsistema de gestor de contenidos

51

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Si el sistema que estamos diseando est centrado en el desarrollo,

el estudio de los subsistemas deber incorporar la definicin de las

clases u objetos y por lo tanto los diagramas que obtengamos debe-

rn tambin representar la interaccin entre los mismos.

As pues, durante esta fase estableceremos las caractersticas, revisa-

remos los requisitos y disearemos las clases (con sus atributos, ope-

raciones y relaciones) de todo el sistema. De manera natural durante

el proceso, obtendremos tambin el diseo de las pruebas que ase-

gurarn el buen funcionamiento del sistema durante el desarrollo y

las condiciones de implantacin del mismo.

3.2.1. Revisin de los subsistemas segn los casosde uso

Para cada caso de uso deberemos definir:

Los subsistemas que intervienen en el mismo.

Cules sern los objetos que compongan cada subsistema, y qu

mensajes intercambiarn entre ellos.

La definicin de los mensajes nos servir para verificar y detallar las

interfaces de cada subsistema teniendo en cuenta todos los casos de

uso en que interviene y completar as la definicin de subsistemas

realizada en fases anteriores.

Caso prctico

Revisin de los subsistemas segn los casos de uso

El caso de uso referido a la realizacin de una comprade un paquete de horas de servicio a travs del sitioweb de Soluciones Abiertas est relacionado con los si-guientes subsistemas:

Subsistema de web pblico (se mostrar el conteni-do referente a los paquetes de horas comercializa-dos, sus caractersticas, etc.).

Subsistema de comercio electrnico (permitir larealizacin del pedido de paquetes de horas de ser-vicio, utilizando el terminal punto de venta virtual se-leccionado).

Software libre

52

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Subsistema de pedidos (permitir integrar la infor-macin del nuevo pedido en la aplicacin de ges-tin de Soluciones Abiertas).

El estudio detallado del caso de uso mencionado, y delos subsistemas que intervienen en l, da como resulta-do el cambio de algunos de estos ltimos, para que so-porten caractersticas como:

Carrito de la compra: el subsistema de web pblicoy de comercio electrnico debe permitir realizar unpedido que incluya ms de un paquete de horas deservicio.

Formas de pago: el subsistema de comercio electrni-co, junto con el terminal punto de venta virtual, debe-ra dar la posibilidad de realizar el pago mediantetarjeta de dbito, de crdito, o domiciliacin bancaria.

Resolucin de problemas de pago: el subsistema decomercio electrnico debe contemplar la posibili-dad de que el pago del producto contratado nopueda realizarse (debido, por ejemplo, a una faltade fondos en la tarjeta suministrada).

Los cambios propuestos implican cambios en las inter-faces existentes en los diferentes subsistemas, as comoen los mensajes que stos intercambian.

Adems de la introduccin de los cambios propuestosanteriormente, despus del estudio detallado de los ca-sos de usos y los subsistemas, se han confeccionado losdiagramas de clases relacionados con estos ltimos (enlos casos en los que se trata de subsistemas que impli-quen un desarrollo a medida).

Figura 3-4. Diagrama UML inicial de clases del subsistema de pedidos

53

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

3.2.2. Eleccin de alternativas de componentesy licencias ms adecuadas

El estudio detallado de los casos de uso del proyecto web que es-

temos realizando, junto con la identificacin de aquellas partes de

ste que necesariamente debamos desarrollar a medida, nos per-

mitir identificar los subsistemas candidatos a implementarse a

travs de la utilizacin de productos software ya existentes en el

mercado.

Caso prctico

Concretar alternativas de los componentes

Una vez realizada la revisin de los casos de uso delsistema web de Soluciones Abiertas, hemos identifica-do que nicamente los subsistemas relacionados con elterminal punto de venta virtual y con la aplicacin de laempresa debern ser desarrollados a medida. El restode subsistemas podrn ser desarrollados a partir deproductos software existentes en el mercado (ya en elestudio de viabilidad del proyecto se determin que es-tos productos debern estar licenciados como softwarelibre).

El estudio de las diferentes alternativas existentes en elmercado, junto con los casos de uso que se desean sa-tisfacer, han dado como resultado la siguiente tabla,que resume los principales componentes a utilizar en lafase de desarrollo.

Tabla 3-2 Principales componentes en la fase de desarrollo

Componente Paquete Versin prevista Licencia

Gestor de contenidos ezPublish 3.0 GPL

Base de datos MySQL 4.11 GPL

Sistema operativo

GNU/Linux 2.6.11 GPL

Servidor web Apache 2.0.48 Apache Software License

Intrprete de scripts PHP 4.3.11 PHP License

Software libre

54

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

Tanto si se trata de un proyecto web interno, como de un producto

que tenemos previsto comercializar, elegir la licencia del mismo o de

las partes que vamos a desarrollar antes del inicio del mismo es al-

tamente aconsejable. Ms an cuando estamos integrando compo-

nentes software o servicios, ya que su licencia puede condicionar los

trminos de la nuestra, u obligarnos a incluirla.

La licencia elegida va a tener algn efecto sobre:

Los ficheros de cdigo fuente de nuestro desarrollo. Deberemos

incluirla en todos y cada uno de ellos, y en determinados casos

hacer mencin de partes de cdigo o libreras que son propiedad

de otras organizaciones.

La documentacin y los materiales de formacin. Ah debe refle-

jarse la licencia escogida desde la primera versin del sistema.

Esto es especialmente importante en proyectos de cdigo libre

que vayan a ponerse a disposicin pblicamente, para evitar mal-

entendidos.

Los componentes elegidos. Si el desarrollo va a ser comercializa-

do bajo una licencia propietaria, debemos asegurarnos de que

los componentes que integremos nos lo permiten.

El cliente que recibe el producto. Debemos informar al cliente res-

pecto a qu derechos tiene sobre el producto y qu garantas le

proporcionan sus derechos.

El mantenimiento del mismo, y el soporte que vamos a ser capa-

ces de proporcionar al producto. En la fase de implantacin vere-

mos las estrategias de mantenimiento posibles segn el tipo de

licencia escogido.

Bsicamente, debemos concentrarnos en las incompatibilidades en-

tre los distintos modelos de licencias existentes, dentro de alguno de

estos escenarios:

Vamos a combinar cdigo propietario con el nuestro y distribuir-

lo bajo licencia comercial? Hemos adquirido estos derechos por

parte de los distribuidores del cdigo propietario?

Vamos a combinar cdigo libre (en alguna de sus variantes,

BSD, GPL, LPGL, etc.) con el nuestro y distribuirlo bajo licencia co-

55

Proyecto web

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

mercial? Nos lo permiten todas las licencias de los distintos com-

ponentes?

Vamos a combinar cdigo libre con el nuestro y distribuirlo bajo

licencia libre? Cul deber ser la licencia libre resultante? De-

seamos imponer alguna restriccin a nuestra licencia libre? Nos

interesa mantener el copyright? Dar garanta y soporte?

En todo caso, la respuesta a las preguntas que surgen en cada escenario

debern resolverse despus de una lectura detenida de las licencias de

los componentes y de un anlisis de nuestro modelo de negocio.

Caso prctico

Eleccin de la licencia de desarrollo

Los desarrollos que hay que realizar son para consumointerno, por lo que la licencia elegida no tendr efectossobre el modelo de negocio ni sobre su distribucin aclientes. Esto no evita que debamos incluir una licenciaen el cdigo que desarrollemos, y en este caso, tene-mos por ejemplo las siguientes alternativas:

Licencia propietaria: en nuestro sistema estamoscombinando diversas licencias de software libre. Sino vamos a redistribuir nuestro sistema, podemosdesarrollarlo bajo licencia propietaria.

Licencia estilo BSD: esta licencia nos permite mantenerel copyright sobre nuestro desarrollo, y es coherentecon las licencias del resto de componentes. No nosobliga a distribuir el cdigo fuente resultante, pero sque permite al destinatario del software su uso, copia,modificacin, redistribucin o venta del mismo. Tam-bin nos permitir su incorporacin futura a un pro-ducto comercializable bajo una licencia propietaria.

Licencia GPL: esta licencia nos permite mantener elcopyright sobre nuestro desarrollo, y es coherente conlas licencias del resto de componentes. Nos obliga adistribuir el cdigo fuente resultante e impide su futuracomercializacin bajo una licencia propietaria.

Una vez analizadas las alternativas, decidimos adoptarla licencia GPL para lo referido a la integracin de laherramienta de comercio electrnico y gestor de conte-nidos con el terminal punto de venta virtual de nuestraentidad bancaria.

Software libre

56

AN

OTA

CIO

NS

FUOC XP06/M2119/02156

3.2.3. Especificaciones de desarrollo y pruebas

Llegados a este punto, estaremos en condiciones de establecer las

condiciones y caractersticas del entorno de desarrollo en los siguien-

tes trminos:

Entorno tecnolgico: hardware, software y comunicaciones.

Herramientas de desarrollo: IDE, generadores de cdigo, compi-

ladores, etc.

Herramientas de documentacin.

Restricciones tcnicas.

Requisitos de seguridad del entorno.

Tambin deberemos ser capaces de definir las pruebas necesarias

que se debern realizar para asegurar el funcionamiento del sistema

una vez implantado. stas deberan definirse como pruebas unita-

rias, es decir, pruebas con el mnimo nivel posible de dependencia

entre ellas para permitir un desarrollo o una integracin software por

componentes, donde cada equipo pueda trabajar y probar indepen-

dientemente, dejando para la fase final las pruebas de integracin.

La especificacin de las pruebas unitarias se divide en pruebas de

caja blanca y pruebas de caja negra:

Caja negra: se considera el componente desde el punto de vista

funcional, analizando sus entradas y salidas, y comparando todas

sus posibilidades con los resultados esperados.

Caja blanca: se considera el componente como una estructura

con una secuencia lgica de eventos y se comprueba la validez de

sta, el cdigo no usado, comprobaciones contempladas, etc.

Normalmente, se usar una combinacin de los dos tipos de prue-

bas, segn el componente o su funcionalidad. Tradicionalmente, se

tiende a realizar las pruebas de los componentes una vez desarrolla-

dos. Las metodologas ms recientes recomiendan invertir este pro-

ceso, y justifican la realizacin de las pruebas previamente a las de

los propios componentes software por las siguientes razones:

Al disponer de la funcionalidad requerida de los componentes,

estamos en disposic