Proyecto de dirección de sistemas de información

8/14/2019 Proyecto de direccin de sistemas de informacin

1/98

Alberto Otero Garca

Software libre

Proyecto de

XP06/M2121/02158

direccin de sistemasde informacin

www.uoc .edu

U


2/98

Segunda edicin: febrero 2007 Fundaci per a la Universitat Oberta de Catalunya

Av. 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 laGNU Free Documentation License , Version 1.2 o cualquiera posterior publicada por laFree Software Foundation , sin secciones invariantes ni textos de cubierta delanterao trasera. Se dispone de una copia de la licencia en el apartado GNU Free Documentation License de este documento.

David Megas Jimnez Jordi Mas

Coordinador Coordinador

Ingeniero en Informtica por la UAB.Magster en Tcnicas Avanzadas de

Automatizacin de Procesos por laUAB.Doctor en Informtica por la UAB.Profesor de los Estudios de Informticay Multimedia de la UOC.

Ingeniero de software en la empresade cdigo abierto Ximian, dondetrabaja en la implementacin delproyecto libre Mono. Como voluntario,colabora en el desarrollo delprocesador de textos Abiwordy en la ingeniera de las versionesen cataln del proyecto Mozillay Gnome. Es tambin coordinadorgeneral de Softcatal. Como consultorha trabajado para empresas comoMenta, Telpolis, Vodafone, Lotus,eresMas, Amena y Terra Espaa.

Alberto Otero Garca

Autor

Ingeniero en Informtica por laUniversidad Ramon Llull. Profesortitular de la asignatura Administracinde Sistemas Operativos en Enginyeriai Arquitectura La Salle. Socio fundadory jefe de proyectos de CometaTechnologies, empresa dedicada a darsoluciones en tecnologas de lainformacin, basadas en el uso deestndares y herramientas de cdigo

abierto.


3/98

3

Proyecto de direccin de sistemas de informacin

A N O

T A C I O N E S

FUOC XP06/M2121/02158

ndice

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 requisitos del sistema......................... 191.4. Estudio de alternativas de solucin.......................... 211.5. Valoracin de las alternativas................................. 221.6. Seleccin de la solucin......................................... 26

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

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.2. Casos de uso reales............................................... 51

3.2.1. Revisin de casos de uso por subsistema....... 523.2.2.Especificaciones de desarrollo

y pruebas..................................................... 543.2.3. Requisitos de implantacin............................ 58

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

de sistema............................................................. 644.2. Elegir la licencia ms adecuada.............................. 674.3. Entorno de desarrollo............................................. 704.4. Documentacin..................................................... 71


4/98

Software libre

4

AN OT A C I ONE S

FUOC XP06/M2121/02158

5. Implantacin ............................................................... 735.1. Formacin............................................................. 745.2. Implantacin del sistema y pruebas......................... 745.3. Nivel de servicio..................................................... 765.4. Aceptacin del sistema........................................... 77

6. Mantenimiento ........................................................... 79

Resumen.......................................................................... 81

Bibliografa...................................................................... 83

GNU Free Documentation License ................................. 85


5/98

5


A N O

T A C I O N E S

FUOC XP06/M2121/02158

El autor agradece a la Fundacin para la Universitat Oberta de Ca-talunya (http://www.uoc.edu) la financiacin de la primera edicinde esta obra, enmarcada en el Mster Internacional en Software Libreofrecido por la citada institucin.

Agradecimientos


6/98

Software libre

6

AN OT A C I ONE S

FUOC XP06/M2121/02158


7/98

7


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Para llevar a cabo un proyecto de sistemas de informacin en entor-nos de software libre, como en cualquier otro tipo de proyecto, es ne-cesario seguir un proceso que nos lleve desde la comprensin delalcance del problema que queremos solventar hasta la implantaciny mantenimiento de la solucin que hayamos elegido.

Aunque el director de sistemas de informacin en entornos de soft-ware libre, o de un proyecto concreto basado en la utilizacin de soft-ware libre, no necesita conocer todas y cada una de las tcnicas y herramientas utilizadas a lo largo de los proyectos, s que necesitaconocer qu fases se debern seguir, qu productos se deben obte-ner al final de cada una de ellas y, a rasgos generales, cmo obte-nerlos, con el fin de poder:

Planificar. El director de proyecto debe planificar qu recursos hay que asignar a cada una de las fases del proyecto, estimar el tiem-po que llevar completarlas, su coste econmico, etc.

Organizar. El director de proyecto debe poder organizar los re-cursos de los que dispone de la forma ms ptima, coordinar elavance de dicho proyecto con el resto de proyectos de sistemas dela informacin y de la empresa, alinear los objetivos del proyecto

con los de la organizacin, conocer qu herramientas son las msindicadas para su uso, etc.

Controlar. El director de proyecto debe poder testar la buenamarcha del proyecto, comprobar la calidad de los resultados ob-tenidos, ofrecer ayuda a los integrantes del equipo en cualquierade las fases en caso de ser necesario, etc.

En este curso se pretenden repasar aquellas fases que es necesarioseguir a lo largo de todo proyecto de sistemas de la informacin, y que el director de proyecto deber supervisar.

Introduccin


8/98

Software libre

8

AN OT A C I ONE S

FUOC XP06/M2121/02158

Estas fases son las siguientes:

Estudio de viabilidad: se estudiar en lneas generales qu pro-blemas se desean resolver, qu soluciones posibles existen y culde ellas es la ms adecuada.

Anlisis: se describir detalladamente el sistema que se deseaconstruir, 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, insta-lacin, etc. de los diferentes subsistemas que compongan el pro-yecto.

Implantacin: se pasar el sistema construido a produccin conel 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, comolas mejoras evolutivas que se consideren oportunas.

Estas fases estarn presentes, de una u otra forma, con estos nom-bres o con otros, en cualquier proyecto de sistemas de informacin,desde los gestionados mediante el mtodo clsico (por ejemplo, enfases seguidas secuencialmente, en cascada, etc.), hasta los gestio-nados como sugiere el conjunto de metodologas conocidas como

giles.

Figura 1. Fases de un proyecto de sistemas de informacin

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


9/98

9


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Los objetivos que el lector deber alcanzar al finalizar el curso deProyecto de direccin de sistemas de informacin son los siguientes:

Haber comprendido de manera global lo que representa la direc-cin de un proyecto de sistemas de informacin, en especial enun entorno tecnolgico de software libre.

Haber asimilado qu fases integran un proyecto de sistemas deinformacin, y qu tareas se deben llevar a cabo en cada una deellas, especialmente desde el punto de vista de su direccin.

Haber reflexionado sobre qu herramientas de software librepueden ayudar en cada una de las fases de un proyecto de siste-mas de informacin.

Haber aplicado a un caso prctico los conocimientos adquiridos alo largo de todo el mster en direccin de sistemas de informacin.

Objetivos


10/98


11/98

11


A N O

T A C I O N E S

FUOC XP06/M2121/02158

El objetivo de la realizacin delestudio de viabilidad es el de, dadoun conjunto de necesidades planteadas, elegir aquella solucin quemejor las cubra de entre todas las posibles (o descartarlas todas encaso de que ninguna las satisfaga).

En el estudio de viabilidad se considerarn las diferentes solucionesposibles, teniendo en cuenta:

El estado inicial del sistema. La situacin actual. Los requisitos planteados.

Cada una de las soluciones propuestas en el estudio de viabilidaddeber recoger los siguientes aspectos:

Econmicos: se deber incluir un estudio econmico preliminarque contemple los costes asociados a cada una de las soluciones.

Tcnicos: se deber incluir un estudio tcnico preliminar de cadauna de las soluciones.

Legales: se deber incluir un estudio de aquellos aspectos legalesque 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 mejorteniendo 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 lastareas a llevar a cabo para realizar el estudio de viabilidad.

1. Estudio de viabilidad


12/98


13/98

13


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Sistema de control de versiones: en la actualidad no existe, y

sera utilizado por el personal tcnico con el fin de mantenerlas versiones, cambios entre stas, etc. del cdigo fuente delos diferentes productos software de la empresa.

Sistema de copias de seguridad: es el encargado de reali-zar losbackups totales e incrementales de la informacinque se considera ms valiosa en la empresa (la base de da-tos del sistema de gestin de proyectos, los ficheros deusuarios tcnicos y no tcnicos, y el cdigo almacenado enel sistema de control de versiones).

Desde el punto de vista econmico, para que la renovacin seaviable deber implicar el menor gasto posible, dado que la parti-da presupuestaria ms importante correspondiente a sistemas deinformacin se va a destinar a la renovacin del hardware. A niveltcnico, las necesidades planteadas son muy poco restrictivas, yaque al ser Soluciones Abiertas una empresa dedicada a las tecno-logas de la informacin, se dispone de personal cualificado queafronta y disfruta cualquier reto tcnico sin mayores problemas.Desde el punto de vista legal, se exige que las soluciones aporta-das sean lo ms flexibles posibles, ya que se valora muy negati-vamente el hecho de no disponer de la mxima libertad paracopiar y/o modificar los sistemas software que se implanten. A ni-vel operativo, la nica necesidad planteada consiste en que enningn caso se debe perder funcionalidad de la que en estos mo-mentos ya se dispone, sino en todo caso, ampliarla.

Figura 2. Descripcin general del sistema


14/98

Software libre

14

AN OT A C I ONE S

FUOC XP06/M2121/02158

Asimismo, adems de describir de forma general el proyecto, sedebe tener en cuentacmo afectar ste a:

Otros proyectos de tecnologas de la informacin ya en curso oque se piensan poner en marcha.

Las diferentes unidades de la organizacin, teniendo en cuentaquines son los responsables de stas y cul es su estructura.

Caso prctico

Alcance del proyecto de renovacin de lainfraestructura software de Soluciones Abiertas, S.A.

En el caso de Soluciones Abiertas, S.A., el proyecto de reno-vacin de la infraestructura software afectar a:

El proyecto de renovacin del hardware de la empresa.Segn el software de base escogido, ser ms apropiadoun hardware u otro, hacindose necesaria la coordina-cin de ambos proyectos.

El proyecto de renovacin de los entornos integrados de

programacin (IDEs) utilizados por el personal tcnico, yaque de manera ideal ste se debera integrar totalmentecon el sistema de control de versiones.

Por otro lado, el cambio de la infraestructura software de laempresa afectar a los siguientes departamentos de sta:

Direccin general, finanzas: estos departamentos se ve-rn afectados nicamente durante el proceso de migra-

cin a las nuevas plataformas, ya que en algn momentola disponibilidad del sistema de almacenamiento de fi-cheros puede verse afectada. Por lo dems, la influenciade la renovacin debera ser mnima.

Marketing: este departamento se ver afectado, al igualque direccin general y finanzas, por la renovacin delsistema de almacenamiento de ficheros. Adems, se ve-rn afectados por el cambio del sistema de gestin deproyectos, debido a que las personas de esta unidad dela empresa son las que gestionan el contacto con el clien-te y por tanto son usuarios habituales del mismo (ya que


15/98

15


A N O

T A C I O N E S

FUOC XP06/M2121/02158

En esta fase del estudio de viabilidad se pretendeestudiar 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 alproyecto que nos ocupa.

La primera tarea que hay que realizar dentro del estudio de la situacinactual es la deidentificar aquellos sistemas que deben describirse ,esto es, de qu sistemas vamos a hacer el estudio debido a que se ven

les permite introducir peticiones de mejora de los produc-

tos, descripciones debugs en ste, etc.). Produccin, investigacin y desarrollo (I+D): estos dos

departamentos sern los ms afectados por el cambio, yaque para ellos implica, adems de lo que se ha comenta-do para los anteriores departamentos, la incorporacinde la utilizacin del sistema de control de versiones en elproceso productivo y de investigacin.

Se deber informar puntualmente a los responsables de

cada uno de los departamentos de los detalles y el alcan-ce del proyecto, en la medida en que se vean afectados.

1.2. Estudio de la situacin actual

Figura 3. Descripcin general del sistema segndepartamentos de la empresa


16/98

Software libre

16

AN OT A C I ONE S

FUOC XP06/M2121/02158

afectados de alguna manera por el proyecto contemplado en el estudiode viabilidad. Es interesante tambin fijar qu usuarios participarn enel estudio de la situacin actual de cada uno de los sistemas escogidos.

El siguiente paso dentro del estudio de la situacin actual ser el dedescribir cada uno de los sistemas identificados en el paso ante-rior. La descripcin se har teniendo en cuenta la informacin reco-gida en las sesiones de trabajo con los usuarios seleccionados comorepresentativos, y deber alcanzar el nivel de detalle suficiente comopara poder realizar un diagnstico acertado del estado real de cadauno de los sistemas estudiados. Asimismo, la dedicacin de recursosen esta fase depender de la informacin de partida de la cual sedisponga (la descripcin de la situacin actual puede ser trivial en al-gunos casos o tremendamente complicada en otros).

Caso prctico

Identificacin de los sistemas actuales

Dado que el proyecto consiste en la renovacin y ampliacinde la infraestructura software de Soluciones Abiertas, S.A.,deberemos estudiar como mnimo la situacin actual de lossistemas que deseamos renovar. En este caso, como ya se ha

comentado, estos sistemas sern el de gestin de proyectos,control de versiones, almacenamiento de ficheros y copia deseguridad. Con el fin de realizar un diagnstico lo ms com-pleto posible, hemos decidido trabajar junto con usuarios delos departamentos de marketing y produccin (ya que son losusuarios ms intensivos de dichos sistemas). El sistema decontrol de versiones se obviar en esta fase del estudio deviabilidad, ya que en la actualidad la empresa carece de l.

Caso prctico

Descripcin de los sistemas actuales

A continuacin se describe la situacin actual de los sistemasde Soluciones Abiertas, S.A. seleccionados con anterioridad:

Sistema de gestin de proyectos: en la actualidad este sis-tema consiste en una intranet desarrollada por la propiaempresa. Esta intranet est alojada en un servidor con sis-tema operativo GNU/Linux, servidor web Apache y progra-


17/98

17


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Para completar el estudio de la situacin actual de los sistemas, sedeber realizar undiagnstico de stos, es decir, analizar la infor-macin obtenida detectando posibles problemas y puntos de mejora.

mada en PHP, apoyndose en el sistema gestor de base

de datos relacional (SGBDR) MySQL.

Sistema de almacenamiento y comparticin de ficheros:en la actualidad este sistema consiste en un servidor condirectorios compartidos, a los cuales puede acceder cual-quier persona de la empresa. Dicho servidor tiene comosistema operativo Microsoft Windows 2000, aprovechan-do la funcionalidad de comparticin de carpetas que steofrece.

Sistema de copias de seguridad: en la actualidad este sis-tema consiste en el volcado diario a cinta de todos los fi-cheros almacenados en el sistema de almacenamiento. Elservidor al cual est conectada la unidad lectora de cintastiene como sistema operativo Microsoft Windows NT, y lascopias se realizan mediante el software suministrado conel propio sistema operativo.

Figura 4. Descripcin generaldel sistema actual


18/98

Software libre

18

AN OT A C I ONE S

FUOC XP06/M2121/02158

Caso prctico

Diagnstico de los sistemas actuales

Una vez analizada la informacin obtenida en la descripcinde la situacin actual de los sistemas estudiados en la empre-sa Soluciones Abiertas, S.A., se ha llegado a las siguientesconclusiones:

Sistema de gestin de proyectos: se ha detectado que lafuncionalidad disponible es muy limitada, ya que cadanueva caracterstica que se desea aadir implica realizaruna programacin a medida (recordamos que este siste-ma ha sido desarrollado por la propia empresa). Este he-cho har que en el futuro o bien la herramienta quedeobsoleta o bien los costes de mantenimiento de sta seandemasiado elevados.

Sistema de almacenamiento y comparticin de fiche-ros: se hace patente la necesidad de crear un sistema

de usuarios y permisos que permita consultar ciertos fi-cheros nicamente a aquellas personas o grupos depersonas que estn autorizados para ello. Adems,existe cierta preocupacin por la escalabilidad de todoel sistema, ya que ltimamente se ha notado una ciertaralentizacin de ste debido a que cada vez es msusado (se guardan ms ficheros, se accede ms a l,soporta ms usuarios, etc.).

Sistema de copias de seguridad: se ha llegado a la con-clusin de que es necesario renovar la estrategia debackup , ya que en este momento se hacen siempre co-pias completas de todos los ficheros. Tambin se ha de-tectado la necesidad de empezar a hacer copias de datosque hasta ahora no se hacan y que residen en servidoresque no comparten directorios por ningn mtodo de loshabituales (p. ej., el servidor que alberga el sistema degestin de proyectos).


19/98

19


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Una vez descrita la situacin actual del sistema, y teniendo en cuentalas opiniones de los diferentes usuarios implicados, se pasar ades-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 proyectoservir 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 laprioridad de cada uno de los requisitos, con el fin de tener presentesu importancia relativa respecto al resto.

La descripcin de cada requisito incluir una explicacin de ste, laprioridad que se le asigna y una catalogacin dentro de un conjuntode categoras definidas.

1.3. Definicin de requisitos del sistema

Caso prctico

Definicin general de requisitos del sistemade copias de seguridad de Soluciones Abiertas, S.A.

Mediante el estudio del sistema de copias de seguridad actual,los puntos de mejora y problemas detectados, y las entrevistascon los usuarios, se han identificado y catalogado los siguientesrequisitos (la prioridad de cada uno de ellos est indicada comoun nmero entre 0 y 100, siendo 100 el prioritario):

Requisitos tcnicos

(100) Arquitectura: debern poder hacerse copias de ser-vidores remotos conectados mediante la red al servidorde copias de seguridad.

(100) Arquitectura: las copias de seguridad debern po-der hacerse de servidores con sistemas operativos igualeso diferentes al del servidor de copias de seguridad.

(80) Seguridad: las copias de seguridad deben residir enun servidor que sea seguro, dado que contendrn infor-macin muy relevante para la empresa.

En el resto de este apartadonos centraremos en el estu-dio del sistema de copias deseguridad como ejemploparticular del caso prcticoplanteado hasta el momen-to. Para el resto de sistemas(gestin de proyectos, alma-cenamiento y comparticinde ficheros, control de ver-siones), sera necesario se-guir el mismo proceso quese describir de este puntoen adelante con el sistemade copias de seguridad.

Nota


20/98

Software libre

20

AN OT A C I ONE S

FUOC XP06/M2121/02158

Caso prctico

(50) Normativas y/o estndares: las copias de seguridad debe-

rn almacenarse en un formato lo ms abierto posible. En lamedida de lo posible se intentar que dicho formato sea inde-pendiente de la plataforma sobre la cual se hagan las copias.

Requisitos operativos

(100) Operativa: deben poder realizarse copias de segu-ridad completas e incrementales.

(80) Operativa: deben poder restaurarse ficheros concre-

tos que residan dentro de cierta copia de seguridad, nosta entera.

(20) Configuracin: la interfaz de programacin de co-pias debe ser lo ms intuitiva y fcil de usar posible.

(50) Configuracin: la periodicidad de realizacin de lascopias de seguridad debe ser totalmente configurable.

(100) Soportes: el software de copias de seguridad debeser compatible con el hardware escogido como soporte

de almacenamiento (la unidad de cintas escogida). (60) Soportes: el software de copias de seguridad debe

ser compatible con el mximo nmero de soportes de al-macenamiento posibles.

Requisitos legales

(60) La licencia de uso del software de copias de seguri-dad debe ser lo menos restrictiva posible.

(60) La licencia de uso del sistema operativo del servidor decopias de seguridad debe ser lo menos restrictiva posible.

Requisitos econmicos

(80) En el caso de ser necesario un gasto en concepto delicencia de uso del software de copias de seguridad, stedebe ser lo ms pequeo posible.

(80) El gasto correspondiente al sistema operativo del ser-vidor de copias de seguridad debe ser lo ms pequeoposible.


21/98

21


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Una vez expresados los requisitos que deber cumplir el proyecto delcual se est realizando el estudio de viabilidad, se pasar apropo-ner varias soluciones alternativas que cumplan con stos. En estafase se tendr en consideracin, asimismo, toda la informacin re-cogida hasta el momento: descripcin general, alcance, situacinactual, etc.

Para cada alternativa se deber especificar en qu consiste, tanto a

nivel funcional como tcnico (estudiando en qu medida se cubrenlos requisitos descritos previamente), si est basada o no en algnproducto ya existente en el mercado (en tal caso se estudiar ste,describiendo posibles costes de licencias, evolucin prevista, estn-dares que cumple, etc.), y si supone o no la necesidad de realizar al-gn desarrollo a medida (en tal caso se deber describir ste de talmodo que quede claro cul es su alcance).

1.4. Estudio de alternativas de solucin

Caso prcticoSoluciones alternativas para el sistema de copiasde seguridad de Soluciones Abiertas, S.A.

Como ejemplo de alternativas al sistema de copias de segu-ridad se proponen tres soluciones posibles, las cuales tienenlas siguientes caractersticas:

Microsoft Windows + aplicacin propietaria: en estecaso el sistema operativo del servidor debackups serMicrosoft Windows 2000, y stas se harn mediantela adquisicin de un software especfico de realiza-cin de copias de seguridad, por ejemplo Arkeia(http://www.arkeia.com/). Se ha comprobado que elsoftware de copias de seguridad elegido cumple conlos requisitos funcionales y tcnicos definidos al res-pecto. En lo referente a los requisitos legales y econ-micos de la solucin propuesta, ni el sistemaoperativo ni el software de copias de seguridad cum-plen con lo expresado.


22/98

Software libre

22

AN OT A C I ONE S

FUOC XP06/M2121/02158

Una vez se han estudiado las soluciones alternativas dentro del pro-yecto del cual se est haciendo el estudio de viabilidad, se debe pa-

GNU/Linux + aplicacin propietaria: en este caso el sis-

tema operativo del servidor debackups sera GNU/Linux(en cualquiera de sus distribuciones), sin embargo, el soft-ware de copia de seguridad sera propietario, por ejem-plo Arkeia. Se ha comprobado que el software de copiasde seguridad elegido cumple con los requisitos funciona-les y tcnicos definidos al respecto. En lo referente a losrequisitos legales y econmicos, el sistema operativo cum-ple con ellos (ya que no es necesario pagar ninguna licen-cia de uso, y adems se nos permite hasta estudiar y

modificar el cdigo fuente de ste), pero no as el softwarede copias de seguridad (ya que ste es propietario).

GNU/Linux + aplicacin libre: en este caso, tanto el sis-tema operativo del servidor debackups como el softwarede copias de seguridad seran libres (por ejemplo, Aman-da, http://www.amanda.org/). Se ha comprobado que elsoftware de copias de seguridad elegido cumple con losrequisitos funcionales y tcnicos definidos al respecto, sal-vo el de ofrecer una interfaz de fcil utilizacin. En cuantoa los requisitos legales y econmicos, stos se cubren per-fectamente, ya que las licencias son muy flexibles y loscostes de adquisicin son nulos.

En los tres casos ser necesaria la realizacin de un mdulo desoftware que recoja la informacin almacenada en la base dedatos del sistema de gestin de proyectos y la almacene en fiche-ros que puedan ser copiados al sistema debackups .

Sobre la base de la informacin obtenida por diferentes canales(informes, foros de discusin, experiencia del personal de la em-presa, etc.) se ha considerado que el coste de instalacin y man-tenimiento de los componentes es igual en los tres casos.

1.5. Valoracin de las alternativas


23/98


24/98

Software libre

24

AN OT A C I ONE S

FUOC XP06/M2121/02158

Adems de estudiar la viabilidad econmica de las diferentes solu-ciones, deberemos tener en cuenta losriesgos asociados a cada unade ellas. Para cada una de las alternativas existentes describiremosqu incertidumbres, problemas potenciales, etc. existen.

Caso prctico

Riesgos en las alternativas del sistema de copiasde seguridad de Soluciones Abiertas, S.A.

Los riesgos asociados a cada una de las soluciones alterna-tivas son los siguientes:

Microsoft Windows + aplicacin propietaria :

Sistema operativo: cambio en la estrategia de negocio delfabricante, desapareciendo el soporte dado hasta el mo-mento y hacindose necesaria una actualizacin.

Sistema operativo: fallos de seguridad detectados pero no

subsanados por el fabricante en un periodo de tiempo ra-zonable.

Aplicacin propietaria: desaparicin del fabricante delproducto, o cambio de estrategia de negocio (dado queno se dispone del cdigo fuente de la aplicacin, este he-cho supondra que cualquier error o problema no podraser subsanado).

GNU/Linux + aplicacin propietaria:

Sistema operativo: se podra dar la falta de soporte en de-terminados casos, ya que no existe un slo fabricante quecentralice el desarrollo del sistema operativo.

Aplicacin propietaria: desaparicin del fabricante delproducto, o cambio de estrategia de negocio (dado queno se dispone del cdigo fuente de la aplicacin, este he-cho supondra que cualquier error o problema no podraser subsanado).


25/98

25


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Llegados a este punto, se deber realizar unapropuesta de enfoque

con el fin de paliar en la medida de lo posible los riesgos antesdescritos. De este modo intentaremos reflejar si estos riesgos son sal-vables, hacindose relevante su importancia relativa.

GNU/Linux + aplicacin libre:

Sistema operativo: se podra dar la falta de soporte en de-terminados casos, ya que no existe un solo fabricante quecentralice el desarrollo del sistema operativo.

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

Caso prctico

Paliacin de riesgos en las alternativas del sistemade copias de seguridad de Soluciones Abiertas, S.A.

Los posibles enfoques con el fin de paliar los riesgos asociadosa cada una de las soluciones alternativas son los siguientes:

Microsoft Windows + aplicacin propietaria :

Sistema operativo: firma de contrato de soporte del siste-ma operativo con el fabricante de ste por un periodo detiempo igual al que estimemos que ser la vida del siste-ma de seguridad tal y como lo estamos estudiando. Estasolucin debe ser aceptada por el fabricante para poderllevarse a cabo.

Sistema operativo: firma de contrato de soporte con in-demnizaciones en caso de producirse fallos en la seguri-dad del sistema debido a problemas en el sistemaoperativo. Esta solucin debe ser aceptada por el fabri-cante para poder llevarse a cabo.

Aplicacin propietaria: firma de contrato en el cual el fa-bricante se comprometa a suministrar al menos el cdigofuente de su aplicacin en caso de que cese su actividad.


26/98

Software libre

26

AN OT A C I ONE S

FUOC XP06/M2121/02158

Para acabar con el estudio de viabilidad, seelegir una solucin deentre las diferentes alternativas estudiadas .

La decisin sobre cul es la mejor solucin (o si ninguna lo es) se tomarteniendo en cuenta la informacin acumulada hasta el momento:

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 riesgosasociados a cada una de ellas.

GNU/Linux + aplicacin propietaria:

Sistema operativo: puede contratarse el soporte de unaempresa externa que se comprometa a centralizar y resol-ver los posibles problemas que puedan surgir.

Aplicacin propietaria: firma de contrato en el cual el fa-bricante se comprometa a suministrar al menos el cdigofuente de su aplicacin en caso de que cese su actividad.

GNU/Linux + aplicacin libre:

Sistema operativo: puede contratarse el soporte de unaempresa externa que se comprometa a centralizar y resol-ver los posibles problemas que puedan surgir.

Aplicacin propietaria: se debe valorar la estabilidad y al-cance de la comunidad formada en torno a la aplicacin,ya que en caso de que el equipo principal de desarrolla-dores desaparezca, la continuidad de sta depender delnmero de personas que la utilizan y desarrollan espor-dicamente en todo el mundo.

1.6. Seleccin de la solucin


27/98

27


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Caso prctico

Seleccin de la solucin adoptada en el sistema

de copias de seguridad de Soluciones Abiertas, S.A.

Dada la descripcin general del sistema y la situacin actualde ste, se han considerado los siguientes factores con el finde realizar la eleccin de la solucin:

Requisitos planteados y descripcin de cada una de lassoluciones: todas las soluciones cubren en mayor o menormedida los requisitos bsicos a nivel funcional y tcnico.

En cuanto a los aspectos econmicos y legales, la solucinGNU/Linux + aplicacin libre es la clara ganadora.

Anlisis costes/beneficios: este anlisis ha dado como re-sultado tres costes entre los cuales la solucin GNU/Linux+ aplicacin libre es la ms barata. Dado que los bene-ficios aportados por cada solucin son parecidos en tr-minos generales (desde luego podran discutirse ciertosdetalles en los que s hay diferencias significativas, peroque no decantan definitivamente la balanza por una uotra solucin), se ha optado por valorar como ms posi-tiva la solucin GNU/Linux + aplicacin libre.

Riesgos: se han detectado posibles problemas de diferen-tes tipos en cada una de las soluciones, siendo los de msfcil solucin los relacionados con el sistema operativoGNU/Linux y la aplicacin de copias de seguridad libre(precisamente por su carcter marcadamente abierto encomparacin con el resto).

Se decide por tanto que la solucin en GNU/Linux + aplica-cin libre de copias de seguridad es la ms adecuada de en-tre todas las consideradas.


28/98


29/98

29


A N O

T A C I O N E S

FUOC XP06/M2121/02158

El objetivo de la realizacin delanlisis del sistema es el de, dadala solucin escogida de entre las descritas en el estudio de viabi-lidad, llevar a cabo una especificacin detallada de sta (orienta-da a facilitar el diseo del sistema, fase cubierta en el siguientecaptulo).

Los siguientes apartados describen con ms detalle cada una delas tareas que cabe efectuar para realizar el anlisis del sistema.

En esta fase del anlisis se deberdescribir el sistema , establecercmo se comunicar con otros en caso de ser necesario y quusuarios sern representativos en el uso del mismo.

Como el lector recordar, ya en la fase de estudio de viabilidadse procedi a describir el sistema genricamente, as como a de-finir cmo afectaba ste al resto de sistemas ya existentes (o pro-yectos que se pensaba llevar a cabo). El trabajo realizado endicha fase servir como base de las tareas realizadas en el pre-sente anlisis.

Utilizando como punto de partida la descripcin de los requisitoshecha en el estudio de viabilidad, sedeterminarn los requisitosexactos del sistema . Asimismo, se estudiarcmo se comunica elsistema con el resto de sistemas existentes (ya sea recibiendo o en-viado informacin a stos).

2. Anlisis del sistema

2.1. Definicin del sistema


30/98

Software libre

30

AN OT A C I ONE S

FUOC XP06/M2121/02158

Caso prctico

Requisitos exactos del sistema de copias

de seguridad de Soluciones Abiertas, S.A.

El sistema de copias de seguridad de Soluciones Abiertas,S.A. deber cumplir los siguientes requisitos:

Debern poder hacerse copias de servidores remotos co-nectados mediante la red local de la empresa al servi-dor de copias de seguridad.

Las copias de seguridad debern poder hacerse de ser-vidores con sistemas operativos iguales (GNU/Linux) odiferentes al del servidor de copias de seguridad (otrosUNIX o Microsoft Windows).

Las copias de seguridad deben residir en un servidorque sea seguro, dado que contendrn informacin muy relevante para la empresa. Este servidor deber cum-plir las normas de seguridad fijadas para todos los ser-vidores de la empresa.

Las copias de seguridad debern almacenarse en unformato lo ms abierto posible. En la medida de lo po-sible, se intentar que dicho formato sea independientede la plataforma sobre la cual se hagan las copias.

Deben poder realizarse copias de seguridad completas(p. ej., una a la semana) e incrementales (p. ej., una alda).

La interfaz de programacin de copias debe ser lo msintuitiva y fcil de usar posible. Esta interfaz podra con-sistir en una serie de ficheros de texto modificables porlos administradores de las copias de seguridad.

Deben poder restaurarse ficheros concretos que residan

dentro de cierta copia de seguridad, no sta entera. Esteproceso se llevar a cabo mediante la interfaz del software


31/98

31


A N O

T A C I O N E S

FUOC XP06/M2121/02158

de copias de seguridad, eligiendo aquellos ficheros que

deseemos restaurar.

La periodicidad de realizacin de las copias de seguridaddebe ser totalmente configurable mediante la interfaz deprogramacin de copias de seguridad.

El software de copias de seguridad debe soportar el hard-ware elegido como soporte de almacenamiento (la uni-dad de cintas elegida ser la comprada en el proyecto derenovacin de hardware).

La licencia de uso del software de copias de seguridaddebe ser lo menos restrictiva posible, en concreto deberser de cdigo abierto o libre.

La licencia de uso del sistema operativo del servidor decopias de seguridad ser la correspondiente a GNU/Li-

nux, es decir, GNU General Public License.

El gasto en concepto de licencia de uso del software decopias de seguridad debe ser nulo.

El gasto correspondiente al sistema operativo del servidorde copias de seguridad debe ser nulo.

Las comunicaciones existentes con otros sistemas (alma-cenamiento y comparticin de ficheros, gestin de pro-yectos y control de versiones) consistirn en la recogida dela informacin de la cual se debe hacerbackup por partedel servidor de copias de seguridad. En el primer y tercercaso (sistema de almacenamiento y comparticin de fi-cheros, control de versiones), ser necesario indicar quarchivos se desean copiar y con qu periodicidad. En elsegundo caso (gestin de proyectos), el objetivo bsicoser realizar una copia de seguridad de la base de datos,con lo que ser necesario guardar sta como un archivoque pueda copiarse como el resto.


32/98

Software libre

32

AN OT A C I ONE S

FUOC XP06/M2121/02158

En la definicin del sistema tambin ser necesario definir elentornotecnolgico del proyecto, respecto del cual ya se incluy informacinen el estudio de viabilidad.

Caso prctico

Entorno tecnolgico del sistema de copiasde seguridad de Soluciones Abiertas, S.A.

El entorno tecnolgico del sistema de copias de seguridadser el siguiente:

Sistema operativo: GNU/Linux (distribucin por deter-

minar).

Sistema de copias de seguridad: deber poder ejecutarseen el sistema operativo GNU/Linux y estar hecha en unlenguaje que el equipo de personas de Soluciones Abier-tas, S.A. conozca (p. ej., C, C++, Perl, Python).

Desarrollos a medida: en el caso de ser necesario realizaralgn tipo de desarrollo, se llevar a cabo con tecnolo-

gas ampliamente disponibles en cualquier sistema ope-rativo UNIX (p. ej., shell scripts , Perl scripts , etc.).

Figura 5. Descripcin general del sistema de copiasde seguridad


33/98

33


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Para completar la descripcin del sistema, ser necesario hacer re-ferencia al conjunto deestndares y normas que hay que consideraren la implementacin de ste.

Una vez descrito el sistema, se proceder aidentificar aquellosusuarios que intervendrn en la definicin de requisitos de ste y

en su aceptacin definitiva . Es especialmente importante contar conla colaboracin de los usuarios a lo largo de todo el proceso de de-sarrollo del sistema.

Caso prctico

Normas a seguir en el sistema de copiasde seguridad de Soluciones Abiertas, S.A.

Las normas y estndares a seguir en la implementacin delsistema de copias de seguridad sern las siguientes:

En cuanto al sistema operativo, se seguir el proceso do-cumentado como Instalacin de servidores GNU/Linuxde Soluciones Abiertas, S.A.

El software de copias de seguridad deber cubrir los es-tndares implementados en las unidades de cinta utiliza-das (p. ej., DLT).

Los posibles desarrollos a medida seguirn las normas in-ternas de Soluciones Abiertas, S.A., es decir, las recogidas

en el documento Normas de desarrollo de Soluciones Abiertas, S.A.. En este documento quedan recogidas lasnormas que hay que seguir en el desarrollo de cualquierproyecto, tales como utilizacin de diagramas UML, for-mato de documentacin del cdigo, etc.

Caso prctico

Identificacin de usuarios del sistema de copiasde seguridad de Soluciones Abiertas, S.A.

El personal involucrado en la definicin de requisitos y acep-tacin de la solucin final del sistema de copias de seguridadde Soluciones Abiertas, S.A. es:


34/98

Software libre

34

AN OT A C I ONE S

FUOC XP06/M2121/02158

El objetivo de esta fase sercompletar los requisitos definidos an-teriormente , contando con la informacin suministrada por los

usuarios. En la medida de lo necesario,se dividir el sistema ensubsistemas que permitan su estudio por separado, con el fin de fa-cilitar el anlisis de stos.

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 suministradapor los usuarios . Los requisitos recogidos en las reuniones manteni-das con los usuarios elegidos en la fase anterior sern bsicamentelos siguientes tipos:

Funcionales (p. ej., mediante el sistema de copias de seguridad sedeber poder recuperar un fichero en concreto sin tener que des-hacer todo elbackup ).

Rendimiento (p. ej., el proceso de recuperacin de un fichero decualquierbackup de cualquier da de la semana no puede durarms de una hora de principio a fin).

Los jefes de cada uno de los departamentos de la empre-

sa ayudarn a establecer parmetros como la periodici-dad necesaria de realizacin de las copias de seguridadsegn su nivel de importancia, qu elementos se debencopiar, etc.

Los administradores del sistema sern aquellas personasque utilicen el sistema de copias de seguridad, tanto en laprogramacin de losbackups como en su recuperacin.Sern ellos los que debern aprobar los requisitos funcio-nales en cuanto a interfaz de uso, versatilidad de progra-macin, etc. y darn el visto bueno definitivo al sistema.

2.2. Establecimiento de requisitos


35/98

35


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Seguridad (p. ej., slo podrn recuperar ficheros delbackupaquellas personas que estn autorizadas para ello).

Implantacin (p. ej., las copias de seguridad se guardarn en unlugar fsicamente seguro).

Disponibilidad (p. ej., el sistema de copias de seguridad debe serutilizado al menos una vez a la semana con el fin de comprobarsu correcto funcionamiento).

Una vez descritos cada uno de los requisitos, se proceder a la espe-cificacin de loscasos de uso de cada uno de ellos. Los casos de uso,adems de la descripcin en s del problema, cubrirn cmo losusuarios interactuarn con el sistema, qu interfaces utilizarn y

cmo se tratarn las condiciones de fallo.

Caso prctico

Requisito periodicidad de backups del sistemade copias de seguridad de Soluciones Abiertas, S.A.

Junto con los jefes de departamento de Soluciones Abiertas,S.A., se ha determinado que se deber hacer una copia dia-ria de todos y cada uno de los archivos almacenados en elsistema de comparticin de ficheros y en el sistema de controlde versiones. Asimismo, se realizar una copia tambin dia-ria de la informacin almacenada en la base de datos delsistema de gestin de proyectos. Mediante entrevistas con losadministradores del sistema, se ha determinado que dichascopias de seguridad diarias se deben realizar de manera au-tomtica a una hora en la que la utilizacin de los recursosinformticos sea mnima, por ejemplo, de madrugada.

Caso prctico

Caso de uso de periodicidad de backups del sistemade copias de seguridad de Soluciones Abiertas, S.A.

La periodicidad de las copias de seguridad de los sistemas dealmacenamiento y comparticin de ficheros y de gestin deproyectos ser totalmente independiente de la utilizacin destos (los usuarios no tendrn que llevar a cabo ninguna ac-cin especial).


36/98

Software libre

36

AN OT A C I ONE S

FUOC XP06/M2121/02158

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

dientes, se analizarn stos con el fin dedetectar posibles inconsisten-cias (dado que pueden intervenir diferentes usuarios con diferentesnecesidades), duplicidades, etc.,y las posibles asociaciones entre stos.

La nica condicin que se deber dar para la realizacin de

las copias de seguridad es que los ficheros que se desea co-piar estn en los directorios de los cuales se har copia y quesern previamente determinados (uno de estos directorioscontendr el fichero con el volcado de las base de datos delsistema de gestin de ficheros).

Los administradores del sistema debern programar la he-rramienta de copias de seguridad para que se hagan losbackups con la periodicidad deseada (una vez al da) a la

hora determinada (de madrugada). Esta programacin serealizar mediante la interfaz de usuario de la herramientade copias de seguridad, que como ya se ha comentado an-teriormente, consistir en ficheros de texto modificables.

El software de copia de seguridad enviar por correo electr-nico un resumen de los resultados de la realizacin de losbackups , con lo cual, se advertir de los posibles errores quese hayan podido dar.

Figura 6. Descripcin configuracin del sistemade copias de seguridad


37/98

37


A N O

T A C I O N E S

FUOC XP06/M2121/02158

En esta fase del anlisisse especifican cmo sern las diferentesinterfaces que habr entre el sistema que estamos describiendo y

los usuarios de ste. Esta especificacin se har teniendo en cuentalos 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 estemodo, se podr describir posteriormente a qu tipos de interfacesaccedern cada uno de ellos.

Caso prctico

Asociaciones del caso de uso de periodicidad

en el sistema de copias de seguridad de Soluciones Abiertas, S.A.

El caso de uso que describe cmo se tratar la periodicidadde losbackups en el sistema est directamente relacionadocon el caso de uso que describe cmo se harn las copias deseguridad del sistema de gestin de proyectos.

La informacin del sistema de gestin de proyectos estaralmacenada en una base de datos de la cual se deber ha-

cer un volcado a fichero para poder copiarla. Dicho volca-do deber realizarse de acuerdo con la poltica deperiodicidades establecida en el caso de uso Periodicidadde backups . Adems, el fichero que contenga el volcadodeber grabarse peridicamente en un directorio del cualse hagan backups .

2.3. Definicin de interfaces de usuario

Caso prctico

Perfiles de usuarios de la utilidad de volcado debase de datos del sistema de copias de seguridadde Soluciones Abiertas, S.A.

La utilidad que realice el volcado a fichero de la base de da-tos del sistema de gestin de proyectos (con el fin de realizarsu copia de seguridad) ser utilizada por usuarios que cum-


38/98

Software libre

38

AN OT A C I ONE S

FUOC XP06/M2121/02158

A continuacin, se debernespecificar los principios generales dela interfaz de usuario , por ejemplo, si se utilizarn interfaces de textoo grficas, cmo se mostrarn los mensajes de error, cmo se ob-tendr ayuda, etc.

plan las funciones de administradores de sistema, con lo cualtendrn las siguientes caractersticas:

Usuarios con un perfil tcnico.

Usuarios acostumbrados a la utilizacin de programassobre terminales, mediante shells con interfaces textuales.

Usuarios acostumbrados a la utilizacin de ficheros deconfiguracin en formato texto.

Usuarios acostumbrados a la utilizacin de herramientas

en entornos UNIX.

Caso prctico

Principios generales de la interfaz de usuario dela utilidad de volcado de base de datos del sistemade copias de seguridad de Soluciones Abiertas, S.A.

La utilidad que realice el volcado a fichero de la base de da-tos del sistema de gestin de proyectos (con el fin de realizarsu copia de seguridad) tendr las siguientes caractersticas:

La programacin de la utilidad se har mediante ficherosde configuracin en formato texto.

El fichero de configuracin en formato texto seguir losestndares ms habituales utilizados en aplicacionesUNIX clsicas (p. ej., separacin de campos con el carc-ter :, continuacin de lneas con el carcter \, lista dedatos con el carcter ,, etc.).

Los mensajes de error sern mostrados por pantalla, conun cdigo numrico asociado, salvo aquellos que impli-quen que el volcado no se ha podido realizar (en este ca-so, el mensaje de error se enviar por correo electrnicoa una direccin indicada).


39/98

39


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Una vez identificadas las caractersticas generales de la interfaz deusuario, se pasar aespecificar sta para cada uno de los casosde uso definidos en el apartado anterior.

Para acabar con la fase de anlisis se proceder a realizar la espe-cificacin del plan de pruebas, que nosservir para establecer si elsistema cumple con los requisitos establecidos por los usuarios .

Los ficheros de configuracin permitirn la inclusin de l-

neas con comentarios. La ayuda del programa de volcado se obtendr por me-

dio de los canales habituales en la administracin de sis-temas (p. ej., utilidadman ).

Caso prctico

Interfaz de usuario de la utilidad de volcado debase de datos del sistema de copias de seguridadde Soluciones Abiertas, S.A.

La utilidad de volcado deber configurarse para que alma-cene el contenido de cierta base de datos en un determinadofichero. Para ello, habr que configurar mediante un ficherode texto datos como el usuario y la contrasea a utilizar paraacceder a la base de datos, en qu servidor reside, etc.

2.4. Especificacin del plan de pruebas

EjemploEjemplo de fichero de configuracin:

# Lnea con comentarios.user = usuario:contraseahost = projects.example.comdatabase = projectse-mail = [email protected],[email protected] = /var/local/dbDumpcompression = true


40/98

Software libre

40

AN OT A C I ONE S

FUOC XP06/M2121/02158

Se podrn realizarpruebas del sistemaa varios niveles :

Pruebas unitarias (p. ej., prueba de conexin a la base de datosdel sistema de gestin de proyectos).

Pruebas de integracin (p. ej., prueba de copia de seguridad delfichero producto del volcado de la base de datos del sistema degestin de proyectos).

Pruebas de sistema (p. ej., prueba de la copia incremental diariade los sistemas de almacenamiento de ficheros y del de gestin

de proyectos).

Pruebas de implantacin (p. ej., prueba de copia de seguridad so-bre la unidad de cintas de la que se dispone).

Pruebas de aceptacin (p. ej., copia completa del sistema que va-lidarn los usuarios correspondientes). Este conjunto de pruebases crtico, ya que ser el que permitir validar el sistema completo. Adems del correcto funcionamiento del sistema, deber tener en

cuenta parmetros como la seguridad, rendimiento, disponibili-dad, etc.

Para cada una de las pruebas que hay que realizar, se deber definirel 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.).

Caso prctico

Prueba de integracin del software de copiasde seguridad de Soluciones Abiertas, S.A.con la utilidad de volcado de la base de datosdel sistema de gestin de proyectos

La prueba tendr las siguientes caractersticas:

Permitir a los administradores del sistema comprobar quela copia del fichero del volcado de la base de datos del sis-tema de gestin de proyectos se ha realizado correctamente.


41/98

41


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Como producto de la prueba, obtendremos un fichero

con las diferencias existentes entre el archivo almacenadoen la copia de seguridad y el archivo producto del volcadode la base de datos.

La prueba se dar por correcta cuando el fichero de dife-rencias entre archivos est vaco.

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

Disponer de los servidores de copias de seguridad y desistema de gestin de proyectos.

Disponer de una base de datos de gestin de proyectoscon contenido real.

Disponer de un acceso remoto a la base de datos del sis-tema de gestin de proyectos.

Disponer de una unidad de cinta sobre la cual realizar lascopias de seguridad.


42/98


43/98

43


A N O

T A C I O N E S

FUOC XP06/M2121/02158

El objetivo de la fase dediseo de un sistema de informacin es ob-tener losmodelos y especificaciones que lo definen a partir del an-lisis realizado en la fase anterior. Las actividades que llevemos acabo en esta fase nos permitirn determinar las especificaciones dedesarrollo e integracin, as como definir el entorno de pruebas e im-plantacin necesarios para su correcto funcionamiento.

Concretamente, los resultados que deberemos obtener en esta fasesern:

La definicin del modelo arquitectnico del sistema. Mediante laidentificacin de sus componentes, sus interacciones y la ayudade 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 anteriormenteidentificados, debidamente revisados para reflejar el modelo y es-pecificaciones definidos.

Los componentes, clases o interfaces que deberemos construir enla 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

3. Diseo del sistema


44/98

Software libre

44

AN OT A C I ONE S

FUOC XP06/M2121/02158

diseo y construccin iterativo, con el objetivo de obtener resultadospronto o de identificar fallos en el diseo a tiempo, es obvio que to-das las decisiones en cuanto a especificaciones, estndares o subsis-temas que tomemos aqu van a facilitar todas las tareas futuras.

Especialmente importante es la identificacin de los componentesque hay que usar y sus licencias, ya que stos pueden determinarparte 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 laarquitectura del sistema es el primer paso paraidentificar los componentes del mismo y da lugar a las siguientesfases de diseo en las que profundizaremos en cada uno de ellos. Elobjetivo es disponer de un conjunto de documentos y diagramascompletos 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 necesariodefinir las normas y estndares de diseo y construccin.

Una vez acordados los estndares de diseo, podremos ya profun-dizar y determinar los subsistemas, repitiendo el mismo proceso queseguimos con la arquitectura general del sistema, esta vez con mayorgranularidad 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 sobrelos grandes bloques que forman el sistema, sin entrar en detalles,

e identificar las relaciones entre dichos bloques. Es muy til paracomunicar a la direccin o a departamentos no tcnicos una vi-sin global del sistema.

3.1. Arquitectura


45/98

45


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Arquitectura lgica: aade detalle a la anterior e incorpora la de-finicin de las interfaces de comunicaciones entre los componen-tes, lo que permitir a los desarrolladores de cada componentetrabajar sin dependencias entre ellos.

En el diagrama anterior vemos los componentes del sistema y losconectores que los unen. Estos conectores indican que algn tipo decomunicacin se produce entre ellos. Es positivo ya mezclar compo-

nentes de negocio y componentes tcnicos en este diagrama (que seidentificarn mediante los estereoptipos o u otros).

Caso prctico

Definicin de la arquitectura de la nuevainfraestructura software de Soluciones Abiertas, S.A.

Para expresar la arquitectura de la nueva infraestructura, usare-mos la notacin UML en los diagramas, y usaremos tarjetas

CRC (Clase-Responsabilidad-Colaborador) de apoyo.

Figura 7. Diagrama UML de componentes


46/98

Software libre

46

AN OT A C I ONE S

FUOC XP06/M2121/02158

Una vez consensuada esta visin general del sistema, pasaremosa profundizar en las interfaces de los componentes para obtenerla arquitectura lgica del sistema. Para ello, extenderemos eldiagrama de componentes anterior detallando los procesos decomunicacin.

Como apoyo a la generacin del diagrama anterior o para consen-suar las interfaces, podemos utilizar las tarjetas CRC.

En la parte superior figura el nombre del componente.

Figura 8. Diagrama UML de componentes con interfaces

Tabla 1.

Control de versiones

Proporciona versin de trabajoExtrae versiones anteriores y diferencias Almacena versiones y cambiosEtiqueta versionesConoce proyectos

Ficheros


47/98

47


A N O

T A C I O N E S

FUOC XP06/M2121/02158

En la columna izquierda deberemos reflejar todo lo que el com-ponente sabe o hace acerca de l mismo. All se incluir todoaquello 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 parteizquierda.

Estas tarjetas son muy utilizadas en las metodologas eXtremeProgramming y Agile, y permiten crear el diagrama de compo-nentes del sistema dinmicamente encima de una mesa simple-mente situando las tarjetas prximas o lejanas entre s segn sugrado de comunicacin, para consensuar as una visin generalde la arquitectura lgica del sistema durante una reunin.

3.1.2. Especificacin de estndares, normasde diseo y construccin

Es importante acordar con las personas encargadas del diseo delsistema y con los equipos que procedern a su construccin unasnormas a seguir en la notacin de diagramas y documentos. Estasnormas pueden venir dadas por estndares o por recomendaciones,o bien ser de uso y creacin interna. Obviamente, siempre es reco-

mendable apoyarse en estndares, ya que va a facilitar la comuni-cacin, reusabilidad y comprensin por parte de entidades externaso recin incorporadas al equipo.

Figura 9. Ejemplo de situacin de tarjetas CRC


48/98

Software libre

48

AN OT A C I ONE S

FUOC XP06/M2121/02158

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 notacionesde la nueva infraestructura software de Soluciones

Abiertas, S.A.

Es conveniente que todos los documentos creados de ahoraen adelante y que van a ser objeto de revisin por parte deequipos diferentes compartan unas caractersticas y manten-gan un formato coherente. Para ello, despus de estudiar losestndares y recomendaciones sobre el tema, se llega a lassiguientes conclusiones:

Documentos de diseo: estos documentos se deben poderconsultar tanto por el personal tcnico implicado, comopor personal no tcnico que pueda revisarlo o consultarlo.Se acuerda que se trabajen en formato RTF (rich text for-mat ) y que la versin ms reciente est simultneamenteen PDF para su consulta. Se crear una plantilla que con-tenga en la primera pgina:

Ttulo del documento.

Responsable del documento. Lista de autores que han intervenido y la fecha de su

primera intervencin. Lista resumida de cambios introducidos en el docu-

mento a medida que se vayan produciendo (cambio,fecha y autor).

Diagramas de diseo: para los diagramas de diseo seacuerda usar la notacin Unified Modeling Language UML (http://www.omg.org/uml/) en su versin 1.5, defi-nida por el Object Management Group (www.omg.org).


49/98

49


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Identificacin de subsistemas

Para reducir la complejidad que supondra disear al detalle todo elsistema, ste deber dividirse en subsistemas para facilitar su com-prensin, revisin y reutilizacin.

Documentacin tcnica: la documentacin tcnica ser

posiblemente la que ms revisiones sufrir y contendrtambin enlaces a documentaciones de las herramientasusadas, especificaciones de programacin (APIs), etc., porlo que se recomienda usar un formato lo ms flexible po-sible e integrable con las propias herramientas de desa-rrollo que se usen. Para ello, se decide usar DocBook(www.docbook.org, http://www.oasis-open.org/docbook/),que nos permitir:

Particin de un documento en varios ficheros estructu-rados, susceptibles de ser revisados independiente-mente.

Fcil inclusin de referencias a otros documentos (en-laces http, figuras, etc.)

Fcil generacin de varios formatos para su visualiza-cin (PDF, HTML) y con la posibilidad de separar elcontenido del documento de su formato.

Independencia de editor usado, ya que es una implemen-tacin de XML y, por lo tanto, modificable en cualquiereditor de texto.

Incorporar documentacin contenida en el cdigo fuentegenerado en la fase de desarrollo, de forma automticaen muchos casos.

Cabe destacar que al tomar las decisiones se ha dado im-portancia a la implantacin del formato o notacin en laindustria y a la accesibilidad del mismo, es decir, a la dis-ponibilidad de ejemplos y documentacin, as como de unamplio conjunto de herramientas que trabajen con ellos.


50/98

Software libre

50

AN OT A C I ONE S

FUOC XP06/M2121/02158

Para realizar esta divisin, podemos tener en cuenta varios aspectosde 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.

Aplicando el criterio de interfaz comn, en este caso sera posible in-cluir todos los subsistemas vistos en una interfaz integrada y obteneras un nico subsistema. As pues, este criterio no sirve para identifi-car subsistemas en este caso.

El criterio de optimizacin de recursos o lneas de comunicacin tam-poco es aplicable en este caso.

Caso prctico

Identificacin y diseo de los subsistemasde la nueva infraestructura software de Soluciones Abiertas, S.A.

Realizando una primera divisin por funcionalidad, identifi-camos claramente los siguientes subsistemas:

Subsistema de copias de seguridad Subsistema de gestin de ficheros Subsistema de gestin de proyectos Subsistema de control de desarrollo y versiones

Si aplicamos el criterio de acceso a datos en la identificacinde subsistemas:

Subsistema de produccin. Incluye las funcionalidades degestin de proyectos, desarrollo y versiones.

Subsistema de acceso documental. Incluye la funcionali-dad de acceso a ficheros compartidos y a la gestin deproyectos con sus documentos relacionados.

Segn este criterio, el subsistema de copias de seguridad nosera relevante, ya que accede a todos los datos sin aadirinformacin ni interpretarlos.


51/98

51


A N O

T A C I O N E S

FUOC XP06/M2121/02158

En este diagrama hemos utilizado el diagrama de componentes vistoanteriormente y hemos incorporado los distintos subsistemas identi-ficados en forma de paquetes que incluyen uno o varios componen-tes de la arquitectura del sistema.

Disponemos ahora de un mapa completo de la arquitectura globaldel sistema. Prximamente, deberemos profundizar en cada subsis-tema y sus componentes y la mejor forma de hacerlo ser mediantela revisin de los casos de uso vistos en el anlisis del sistema.

Una vez identificados los subsistemas, es el turno de revisar loscasosde uso hechos en la fase de anlisis y determinar las operacionesque debern implementar las interfaces de cada uno de ellos.

Figura 10. Diagrama UML de componentes

3.2. Casos de uso reales


52/98

Software libre

52

AN OT A C I ONE S

FUOC XP06/M2121/02158

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 podamosidentificar en esta fase.

Restricciones o caractersticas de la interfaz de usuario.

Nuevos requisitos que podamos identificar.

Si el sistema que estamos diseando est centrado en el desarro-llo, los casos de uso de los subsistemas debern incorporar la de-finicin de las clases u objetos y por lo tanto los diagramas queobtengamos debern tambin representar la interaccin entre losmismos.

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 duranteel 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 casos de uso por subsistema

Para cada caso de uso deberemos definir:

Subsistemas y actores que intervienen en el mismo.

Mensajes que intercambian los objetos.

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

interfaces de cada subsistema teniendo en cuenta todos los casos deuso en que interviene y as completar la definicin de subsistemasrealizada en fases anteriores.


53/98

53


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Caso prcticoRevisin de casos de uso del subsistema de copiasde seguridad de Soluciones Abiertas, S.A. A continuacin, completaremos la definicin de subsistemasrealizada con la revisin de los casos de uso implicados en lagestin de copias de seguridad.

A continuacin, enumeraremos los mensajes que intervienen enel volcado de la base de datos a fichero y los sistemas u objetoscon que se intercambian esos mensajes, lo que nos llevar haciael diagrama de clases del subsistema, donde se representan losobjetos que intervienen y sus atributos y mtodos.

Figura 11. Diagrama UML de revisin de caso de usocon componentes implicados

Figura 12. Diagrama UML de clases


54/98

Software libre

54

AN OT A C I ONE S

FUOC XP06/M2121/02158

3.2.2. 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: IDEs, generadores de cdigo, com-

piladores, etc. Herramientas de documentacin. Restricciones tcnicas. Requisitos de seguridad del entorno.

Tambin deberemos ser capaces de definir las pruebas necesariasque se debern realizar para asegurar el funcionamiento del sistemauna vez implantado. stas deberan definirse como pruebas unita-rias, es decir, pruebas con el mnimo nivel posible de dependenciaentre ellas para permitir un desarrollo o una integracin software porcomponentes, 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 decaja blanca y pruebas de caja negra:

Caja negra: se considera el componente desde el punto de vistafuncional, analizando sus entradas y salidas, y comparando todassus posibilidades con los resultados esperados.

Caja blanca: se considera el componente como una estructuracon una secuencia lgica de eventos y se comprueba la validez desta, 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, setiende 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 delos propios componentes software por las siguientes razones:

Al disponer de la funcionalidad requerida de los componentes,estamos en disposicin de disearlas.


55/98

55


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Desde el primer momento podremos probar que nuestros compo-nentes cumplen o van cumpliendo las funcionalidades.

Es mejor crear un componente con el objetivo de pasar las prue-bas diseadas, que crear uno que tenga la funcionalidad reque-rida. De este modo se evita que los programadores introduzcanefectos colaterales o crean que determinada funcionalidad tam-bin ser necesaria y la introduzcan.

Se ha demostrado que si las pruebas estn bien diseadas y soncompletas, los programadores tardarn igual o menos en crearun componente que cumpla las funcionalidades que uno que sim-

plemente pase los tests diseados.

Aunque tradicionalmente se dejan las pruebas para el final del de-sarrollo, stas son las que ms frecuentemente provocan retrasos enel proyecto. Este enfoque de pruebas unitarias mitiga estos retrasosy optimiza el desarrollo que ahora se enfoca directamente a obtenerresultados, entendidos como tests pasados satisfactoriamente.

Caso prctico

Definicin de las especificaciones de desarrollo y pruebas del subsistema de copias de seguridad deSoluciones Abiertas, S.A.

El subsistema de copias de seguridad debe ser capaz de co-piar y restaurar toda la informacin del resto de subsistemas. Algunos de los recursos donde se almacena la informacinpermiten su acceso y recuperacin directa, en un formato in-teligible por el sistema de copias. Otros exigirn un desarrollopara proporcionar sus datos en un formato susceptible de sercopiado y restaurado sin afectar a su integridad. Es el caso dela base de datos.

As pues, se deber desarrollar:

Una interfaz que permita el volcado de una imagen de la basede datos en un instante determinado. Esta interfaz deber poderfuncionar a peticin de un usuario o bien de forma desatendidacuando se realicen las copias de seguridad peridicamente.

Una interfaz que permita la sustitucin total o parcial de susdatos por otros provenientes de la copia de seguridad.


56/98

Software libre

56

AN OT A C I ONE S

FUOC XP06/M2121/02158

Al determinar el lenguaje elegido para el desarrollo, se con-

sideran las siguientes alternativas:

Perl (http://www.perl.org): lenguaje de script muy implan-tado en tareas administrativas. Muy flexible y verstil, dis-pone de multitud de libreras de apoyo y una comunidadde usuarios extensa. Permite orientacin a objetos.

Bash (http://www.gnu.org/software/bash/): lenguaje descript sobre el propio intrprete de comandos del sistema

operativo. Aunque muy potente, est muy condicionadopor el propio entorno de ejecucin (variables de entornodel usuario, etc.) y su funcionalidad es menor que la de unlenguaje de programacin clsico.

Python (http://www.python.org): lenguaje de script de usocada vez ms frecuente. Permite una fcil creacin de in-terfaces grficas, y dispone de multitud de libreras deapoyo. Su intrprete y el propio lenguaje no estn tan di-

fundidos como el resto de alternativas.

Por su amplia aceptacin y disponibilidad de libreras deapoyo, as como su integracin con el sistema operativo, So-luciones Abiertas, S.A. decide utilizar el lenguaje Perl.

Al determinar el entorno de desarrollo, se consideran las si-guientes alternativas:

Jedit (http://www.jedit.org): se trata de un entorno muy potente desarrollado en Java y por tanto multiplataforma,con un conjunto de plug-ins que proporcionan funcionali-dades adicionales como deteccin de sintaxis y navega-cin avanzada por el cdigo, integracin con sistemas decontrol de versiones, etc.

Vim (http://www.vim.org): se trata de una extensin deleditor 'vi' incluido en casi todos los sistemas Unix. Ha sidomejorado para facilitar su uso, y dispone de interfaz gr-fica e interfaz de texto.


57/98

57


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Emacs (http://www.gnu.org/software/emacs/): se trata de

una herramienta muy potente y compleja. En su origen esun intrprete de Lisp con funcionalidades de edicin detextos. Su curva de aprendizaje es muy pronunciada.

Por su facilidad de uso y potencia, con posibilidad de desa-rrollo de extensiones y de incorporacin de las muchas yaexistentes, se decide utilizar el entorno de desarrollo Jedit.

El resto de especificaciones de desarrollo provienen de las toma-das anteriormente, ya que el formato de documentacin, as como el marco de trabajo de las pruebas unitarias surgen deforma natural a partir del lenguaje de programacin escogido.

Marco de trabajo de pruebas unitarias: mdulo PerlTest::SimpleUnit

Documentacin del propio desarrollo: formato POD ( plainold documentation )

Documentacin tcnica de los interfaces y su uso: DocBook.

A continuacin, deberemos enumerar las pruebas unitarias,extradas de las funcionalidades e interfaces del subsistema:

Conexin y desconexin al gestor de base de datos.

Obtencin de las bases de datos a volcar.

Conexin y desconexin a cada base de datos a volcar.

Inicio y fin de transaccin con la base de datos para evitardatos corruptos durante el proceso de volcado.

Obtencin de los datos de estructura de cada tabla decada base de datos.

Obtencin de los datos de cada tabla de cada base de datos.

Compresin de los datos obtenidos para optimizar recursos.

Almacenamiento de los datos. Obtencin de los datos almacenados.


58/98

Software libre

58

AN OT A C I ONE S

FUOC XP06/M2121/02158

Para cada una de estas pruebas, deberemos definir sus posibles pa-rmetros o informacin de entrada, y sus posibles resultados o infor-macin de salida. Esto nos permitir ms adelante programar cadauno de los tests bajo el marco de trabajo de tests unitarios elegido.

3.2.3. Requisitos de implantacin

Los requisitos de implantacin sern los que tenga que cumplir cadacomponente o subsistema cuando trabaje en el entorno real conjun-tamente con el resto de subsistemas. Por entorno no entenderemos

nicamente entorno tecnolgico, sino que tendremos en cuenta tam-bin a los usuarios del subsistema.

As pues, la implantacin del subsistema tendr implicaciones paralos usuarios y habr que determinar si sus conocimientos actualesson suficientes para usar el nuevo subsistema, o bien deberemos de-sarrollar un plan de formacin.

De la misma manera, desde el punto de vista tecnolgico, debere-

mos determinar las condiciones del entorno donde implantaremos elsubsistema, la capacidad actual de sus recursos y sus condiciones defuncionamiento para verificar que nuestro nuevo subsistema no va aagotar los recursos existentes y no va a provocar cambos en los ni-veles de servicio del resto del sistema.

El documento que recoja los requisitos de implantacin deber con-templar:

Gestin de la documentacin. Quin tendr acceso a ella y enqu formato y condiciones. Formacin de los usuarios.

Descompresin de los datos almacenados.

Sustitucin de la estructura actual por la obtenida de losdatos almacenados.

Sustitucin de los datos actuales por los obtenidos de losdatos almacenados.

Comprobacin de la integridad de la base de datos.


59/98

59


A N O

T A C I O N E S

FUOC XP06/M2121/02158

Necesidades hardware y software. Necesidades de comunicaciones. Restricciones de rendimiento que tengan lugar en el entorno de

implantacin.

Este documento se tendr en cuenta en la fase de implantacin, y puede contemplar casos adicionales como la migracin del sistema,recuperacin frente a desastres, alternativas o posibles ampliacionesde algunos de los recursos ms crticos.

A su vez, este conjunto de requerimientos ser de gran utilidad paralas pruebas de implantacin e integracin del subsistema en su en-torno de funcionamiento.

Caso prctico

Definicin de los requisitos de implantacindel subsistema de copias de seguridadde Soluciones Abiertas, S.A.

Ya hemos visto que la implantacin deberemos realizarlabajo dos enfoques, el del usuario del subsistema y el tecnol-

gico y sus recursos.

Desde el punto de vista del usuario ser necesario definir unresponsable de la poltica de copias de seguridad de la em-presa. Esta figura tendr las siguientes responsabilidades:

Conocer el funcionamiento del subsistema, teniendo acce-so a su documentacin.

Disear la poltica de copias de seguridad y consensuarla

con los responsables del resto de subsistemas que gestionanlos recursos de los que se debe hacer copias de seguridad.

Comprobar y monitorizar el correcto funcionamiento delsubsistema.

Conocer los posibles riesgos y cmo subsanarlos e incor-porar estas actuaciones dentro de la poltica de copias deseguridad de la empresa.

Debido a la importancia que tiene este subsistema para el fun-cionamiento de la empresa, y a la urgencia con que suelen pre


60/98

Software libre

60

AN OT A C I ONE S

FUOC XP06/M2121/02158

sentarse algunos de sus casos de uso, sera conveniente nom-

brar un segundo responsable que conozca la poltica de copiasde seguridad y los procedimientos necesarios para suplantar alprimer responsable si ste no pudiera atender la incidencia.

Desde el punto de vista tecnolgico, la implantacin del sub-sistema de copias de seguridad tendr un impacto sobre to-dos los recursos de almacenamiento de la empresa.

El sistema de ficheros que almacena los documentos de la

empresa deber ser accesible por el servicio que realizalas copias de seguridad, sin que el proceso de copia lomodifique.

El subsistema de control de versiones deber ser accesiblepor el servicio que realiza las copias de seguridad, permi-tiendo el acceso histrico al mismo (a todas las versiones) y a la versin actual de todos los proyectos almacenados.

La base de datos de proyectos deber ser accesible por el

servicio que realiza las copias de seguridad, y los cambiosen su forma de acce

Documents

Proyecto de dirección de sistemas de información