10 + Puesta en marcha y pruebas. Durante esta fase se instalard el sis- tema y se realizarin pruebas de integridad antes de posarlo a pro- duccién, Esta fase puede generar que se deban realizar retoques enel desarrollo o en el disefio para solventar problemas que hayan surgido durante las pruebas, Una vuelta atris en el desarrollo es ceptable en la mayoria de los proyectos, pero se debe tener en cuenta que durante I fase de disefio es complicado y que la deci- sién debe ser meditada con cuidado. Posteriormente, si se da el vis- to bueno, se pasard el sistema a produccién con la finalidad de que los administradores y usuarios comiencen a ulilizarlo. + Manteni jento. Con la prictica, los usuarios encontrarén los errores que puedan surgir de sitaciones particulares y se anali- zardn las posibles mejoras (versiones evolutivas) de la aplicacién. Durante esta fase o la anterior, dependiendo del proyecto, se sue~ len incluir sesiones de formacién para los administradores/usua- rios para realizar la cesin gradual de responsabilidades desde el equipo del proyecto hacia los usuarios finales del sistema. Este as- peclo es importante para evitar la dependencia de un equipo con respecto al otro y la sobrecarga de trabajo, sobre todo si el equipo de proyecto perienece a la misma inslitucién/empresa Con la definicién anterior 6 bajo otros nombres/apartados, estas fa- ses estardn presentes en cualquier proyecto que involucre las tecno- logias de la informacidn y la comunicacién independientemente de la metodologia utiizada para su gestién (secuenciales, cascada, concurrentes, etc,). Con relacién a este documento-guia, se utilizard un caso préctico con el fin de aplicar los conocimientos tedricos, y para cada apartado se presentard un ejemplo (basado en el caso prictico) para mostrar as- pectos concretos de cémo se debe desarrollar por parte de los estu- diantes el punto en cuestibn (se identificaré con Caso préctco:...). Es necesario fener en cuenta que la solucién propuesta no es la nica posible a dicho proyecto y que sélo tiene come fin presentar una de las posibles alternativas en el desarrollo del mismo sirviendo como marco de referencia para su desarrollo. Durante la etapa de apren- dizaje, es conveniente trabajar por analogia, para, de esta manera, ejercitar todas las fases propuestas, aprender a resolver las dificullades que el mismo genera y seguir (durante este periodo de formacién) una metodologia adecuada en su consecucién.En el presente proyecto se considera que seré desarrollade por un equipo formado por un jefe de proyecto (responsable de todas las fa- ses) y un grupo de trabajo (analislas, disenadores, programadores, eic.). Dependerd del volumen del grupo de trabajo y la complejidad del proyecto la distribucién de responsabilidades entre el jefe de pro- yecto y su grupo. Normalmente, en funcién del proyecto, el jefe de proyecto define el grupo de trabajo y qué tareas/responsabilidades debe asumir cada uno de los miembros formanda une organizacién jerdrquica. En otros casos, el jefe de proyecto es un miembro més del grupo de onalistas/diseiadores/desarrolladores y ademds de la di- reccién del proyecto realiza olras lareas especificas. uHay una serie de objelivos que el estudiante debe conseguir al final del curso de Proyecto final en entornos de software libre para la edministracién de redes y sistemas operatives. Dentro de los mis: mos, se pueden enumerar los siguientes: + Asimilar los conocimientos en cuanto a la realizacién de proyectos en entornos de software libre, que si bien se puede aplicar una me- todologia general en el desarrollo de proyectos, presentan ciertas particularidades en cuanto a la tecnologia, la capacidad de deci- siény la bondad de la solucién. + Adquirir experiencia y conocimientos en determinar cudles son los puntos vilales en un proyecto de administracién de redes y sisle- mas operatives, adeplando a la siluacién parlicular las fases que se han definido anteriormente + Analizar, seleccionar y probar qué herramientas de software libre se ufilizardn para desarrollar el proyecto y cudles se ufilizarén para administrar las redes y los sistemas operativos, teniendo en cvenia elementos tales como el entorno, la capacitacién de los usuarios y la aulonomia que deberén tener los mismos cuando el proyecto haya finalizado, + Aplicar al caso propuesto no sélo la metodologia y los conoci- mientos adquiridos a lo largo de los diferentes médulos, sino vin- cular todos estos conocimientos en un proyecto que deberd ser desarrollado utilizando herramientas basadas en software libre, Asimismo, el proyecto (resultado del trabajo del estudiante) debe- 6 estar basado en el mismo tipo de herramientas. + Generar toda la documentacién y la informacién necesaria para que, una vez el proyecto se encuentre en produccién (aplicado a 13“ la empresa y con usuarios de la misma], permita resolver las ta- reas bésicas vinculadas al mismo como son la instalacién y con- figuracién, supervisién, adaptacién al entorno cambiante de una empresa 0 interpretacidn de los resultados. Esta informacién tam bién deberd incluir manuales de usuario para que éstos puedan oprender @ trabajar con la solucién propuesta sin la intervencién del equipo de proyectos.idad La importancia vital para cualquier proyecto dentro del ambito de administracién de redes y sistemas operativos es el estudio de via- bilided, yo que seré éste, a partir de unas necesidades planteadas, el que per itird escoger la mejor solucién que abarque las necesi- dades del cliente. Es importante, por lo tanto, que el estudiante asuma el rol del jefe de proyectos, ¢ interprete los requisitos y nece- sidades del enunciado del proyecto. En un caso real, el jefe de proyecto deberd mantener un didlogo en profundidad con los responsables de la empresa que encargan el proyecto para que le transmitan todos las necesidades, especificaciones y requisitos que deberd cumplir la solu- cién adoptada y evitar soluciones incompletas 0 anadidos a la solucién En el estudio de viabilidad, se debe comenzar considerando tres as- pectos basicos en toda solucin informatica + Elestado actual del sistema y su configuracién (hardware y software) + QUé problemas se deben solucionary cusles son los requisitos de dicha solucién, tanto estructurales como funcionales, sin descui- dar los particuloridades de quién trabajar (instalaré y configura~ r4, mantendré, utiizard, ...) con dicha solucién y su grado de formacién, + Cutiles son las restricciones al sistema, al cual se debe aplicar la solucién, ya que en general el jefe de proyectos se encontraré con un statu quo que no podré o le costaré mucho cambiar y que pue- de ir desde aspecios de comporlamiento social (los usuarios estén acostumbrados a...) hasta aspectos tecnolagicos (se utiliza/debe uilizar tal hardware, tal base de datos o la conexién es de X Mbps, El estudio de viabilidad debe considerar las diferentes propuestas para llegar a un acuerdo con el cliente que serd quien tomaré la de- 86 cisién final guiado por sus asesores y por el jefe de proyectos. Por lo tanto, este estudio, ademas de un resumen ejecutive, deberd incluir los siguientes aspectos + Econémicos: un informe detallado preliminar pero con un allo grado de detalle sobre el coste de lo solucién propuesta (0 de cada una de ellas si existon alternativas uv opciones). Este andlisis de costes debe ser riguroso e incluir todos los gastos previstos en la consecucién del proyecto, evitando la costumbre de incremen- tar los costes en un determinado porcentaje “por las dudas” o “por lo que pueda pasar”. En proyectos donde existen costes muy Jificiles de valorar en el momento del aniilisis de viabilidad, se fi jon los procedimientos (por contrato) mediante los cuales se pue= dan hacer frente econémicamente sin tener que redefinir todo el proyecto, + Técnicos: estos aspectos permitirdn tomar una decisién precisa sobre cudl de las propuestas es la més adecuada a las necesida- des, y que junto con el anélisis econémico permitieén la adecua- cién de la misma. Puede darse el caso de que las soluciones més adecuadas desde ol punto de vista tecnolégico signifiquen combiar lo arquitectura del sistema © formar a todo el personal transfor- mando esta opcién en inviable. Ante estas situaciones, se deberd tomar una solucién de compromiso. + Legales: dependiendo del tipo de instalacién y datos que maneje la empresa y dada las normativas legales (proteccién de datos, propiedad intelectual, confidencialidad, seguridad industrial, etc.) el estudio deberd incluir aspectos vinculados a estos temas y csmo la solucién propuesta los aborda + Aspectos de funcionamiento: se deberdin incluir los métodos y procedimientos operatives para cada uno de los diferentes aspec- tos contemplados en la solucién propuesta. En cuanto a la seleccién de la mejor solucién informética, podemos diferenciar dos escenarios posibles: + Proyecto final del curso. Durante el desarrollo del curso, el estu- diante deberé escoger la mejor solucién teniondo en cuenta tanto el impacto en la organizacién como en los diferentes miembros de la misma, el coste asociado, no sélo econémico sino en adap-tacién y estuerzo de los usuarios, ete, y los riegos asociados que implica la puesta en marcha de la solucién propuesta. Este ditimo aspecto debe tenerso especialmente en cuenta, ya que soré uno de los mas importantes en la empresa: no tiene que haber pérdi« do de la informacién y hay que tener en cuenta que se deben evie tar 0 minimizar (sin son inevitables) las interrupciones del servicio durante y después de la implantacién de la solucién + Proyecto en entorno real de la empresa. Si bien se pueden apli- car los mismos criterios del pdrrafo anterior se deben incluir los representantes de la empresa, a los cuales habré que explicar cudl es la balanza de beneficios-riogos de la solucién adoptada pora que, conjuntamente, se tome la decisién adecuada y la res: ponsabilidad no recaiga Gnicamente en el jefe de proyectos (o por lo menos que ésta sea delegada al jefe de proyectos con el con- sentimiento de la empresa). Los siguientes pérrafos presentan el problema y detallan, para el caso del ejemplo propuesto, cémo se lleva adelante el estudio de viabilidad 1. Necesidades y requisitos del cliente Como se mencioné anteriormente, ésta es una fase muy importante en la vida del proyecto: interpretar bien las especificaciones, requisi- tos y necesidades del cliente permitird disehar la solucién adecuada para este problema, Las necesidades pueden ser planteadas por un cliente exierno si tra- bajamos para una empresa que se dedica a desarrollar soluciones de estas caracteristicas, es decir el proyecto serd para otra organiza- cidn (en este caso es aconsejable dedicarle un tiempo a analizar la caracteristicas de la empresa, modelo de negocio, hdbitos y costum- bres, tecnologia uilizada, etc.), 0 la propia empresa dispone de un deporlamento de proyectos con un responsable y el proyecto es para otro departamento o unidad de la misma empresa. En este sttimo caso, el jefe de proyectos ya parte con un conocimiento base de céme funciona la empresa y las cuestiones vinculadas. Es recomendable para esta primera parte del estudio es hacer una anilisis “desde arriba hacia abajo" (top-down) comenzando por una "78 descripcién general e ir profundizando en detalles de los aspectos comentados en el parrafo anterior que tenga especial relevancia Es importante que el jefe de proyecto (estudiante en nuestro caso) ob- tenga una visién global del problema sin detenerse en detalles y a continuacién comience a desglosar cada uno de los aspecios men- cionados. Como caso prictico se viilizard una empresa que necesita actvalizar su sistema informético y un conjunto de servicios nuevos (ver recua- dros posteriores), El estudiante debe tener en cuenta que este ejem- plo se utiliza para explicar en forma aplicada los conceptos tedricos ¥ por lo tanto los detalles que se dan son énicamente a modo de am- pliacién de este caso especifico, pero que son itiles en la mayoria de proyectos de estas caracteristicas. Caso praciico: Sitvacion actual Proyecto de adecuacién y renovacién de red y servicios informéticos para la empresa NiEum S.A. La empresa NiEum es una empresa dedicada a la prestacién de servicios en el émbito editorial y cuenta con un sistema informdtico basado en soluciones pro- pielarias que ha tenido un crecimiento muy elevado en un periodo de tiempo corto y no planificado. La empresa ha pasado de un parque informético de 6 ordenadores basados en tecnologia Windows®98, au- fogestionada, con 6 usuarios en ofimatica, administra cidn y servicios a clientes externos (10 clientes) a un sistema basado en la misma tecnologia pero diferentes, versiones (Windows®98, Windows®2000) de 12 orde- nadores més 1 servidor (pagina web y datos internos) con 12 usuarios (empleados de la empresa) y 50 clien- tes externos, Esle cambio se ha producido en 6 afos y ha sido regido por las necesidades de la empresa sin planificacién ni renovacién tecnolégica (96!o con nue- vas adquisiciones)Figura 1-1. Pasado y presente de NiEum Caso practico: Proyecto Proyecto de adecuacién y renovacién de red y servicios informéticos para la empresa NiEum S.A. La empresa solicita un proyecto de renovacién, adap- tacién y crecimiento para hacer frente @ un conjunto de servicios no prestados en la actualidad, un aumento a 100 clientes externos, que integre parte del sistema in- formético actual (6 méquinas de usuarios con datos compartides e impresin en red), y que dicha solucién esté basada en software libre. El proyecto debe contemplar Ia integracién/sustitucién de los servicios actuales, ol soporte para los nuevos ser vicios y la formacién de los usuarios y administradores del sistema con la ampliacién a 20 usuarios (adi trativos/comerciales-emploados de la empresa) y 3 18c~ nicos (administradores y/o gestores del sistema informético -empleados de la empresa). La solucién adoptada debe permitir a la emprosa cumplir con toda la legalidad vigente, tener presencia en Internet a través de una plataforma de contratacién y gestion de servicios electrénico (e-services) y poder realizar la transferencia de informacién (productos y gestién) via canales de comunicacién seguros entre empresa y-cliente externo. 9Autor Autor Doster en fornctica y profeor Ingerere ssp 6 nferetico Compstadoreny Ssternas Operatives 7 Froceuomiene Perla po lo UAB. dle Uniersdad Anema de Proteor de Avautectuay Stem Bin Ree TNT Sumac eematoperivosyproyeardefinal Stecrar Opetvos dela UAB, secoree delelhgerate hforndicn CConsilor de or Eskoe de Tesi Suesia) wie ue To Infemiice 9 Mallets do 16 UOC. teeelgesialreties wi tcemren Beleewayelede rd Bapatom wd fords de cpt opertrisice, de Arqiva de Comattadoreny Sugund edie fabrar 2007 1 Fandacé per la Unveratet Obert de Catolunya ‘a. Thidobo, 39-48, 08085 Boreelone Mater relaade por Eweca Mada, SL {Autores Romo Supp Belo lost erbo eve Se nnn ter. nr oi Sti li etre ln Ui Deo Lt, Saas rtf Wale enn gear teeter let ean tte wren onc ntn20 Software libre EI nuevo sistema debe integrar los 6 ordenadores Windows®, debe prestar los siguientes servici ternos basados en soflware libre: acceso ‘nico (NIS), datos compartides (NFS, y datos Windows®), segun dad (zona de servidores y DMZ) impresién en red, servicio de web y mail, base de datos (clientes y per- sonal), y ofimatica, Ademés, para los clientes de la empresa debe proporcionar los siguientes servi WWW, mail, servicio de impresién en las méquinas de la empresa, FTP, foros, comercio electrénico, base de datos. Todos los servicios de datos deberén incluir politicas de resguardo -backup- adecuadas a sus caracteristicas. Es importante considerar que el cambio tecnolégico deberd ir acompanado de formacién (si bien se incor- poraré soporte técnico como empleados de la empre- sa), que toda la infraestructura afeciard al trabajo de la empresa y que este trabajo debe ser cuidadosamente planificadoindlisis de la situacién actual Después de la descripcién de necesidades y requisitos, es necesario hacer un anélisis de los sistemas de la empresa y realizar un diag- néstico lo més preciso posible haciendo una lista de taroas y activi- dades (checklist) para no descuidar ninguna (por evidente o minima que sea). Esta lista permitiré tener en mente la integracién del siste- ma actual con el nuevo y evitar improvisaciones cuando el proyecto esté on prucbas. Enel presente caso, se incluirdn: las caradleristicas técnicas de los orde- nadores (hardware, sistema operative y software) y las aplicaciones y servicios que deberdn inlegrarse en el nuevo sistema, Asimismo, es im porlanie fijar qué usuarios participardn en el estudio de la siluacion ac- tual para resolver cuesliones y/o tomar decisiones de disefio de la nueva infraesiructura. En nuestro ejemplo practic, seré necesario describir cada uno de los sistemas: ~ Ordenadores: tipo, SO, aplicaciones y servicios. — Impresoras:tipos y servicios — Red: tipo, estructura y caracteristicas de seguridad. ~ Datos compariidos: tipo de servicio, caracteristicas de seguridad. — Estructura fisiea: dénde se encuentran los equipos y dénde serén alojados los nuevos sistemas/usuarios/ personal tecnico, — Para los puntos que asi lo justifiquen (por ejemplo, los que esién vinculados a estructuras fisicas o légicas), se pueden incluir diagra- ‘mas para clarificar la estructura de los servicios 0 su dependencia, y del hardware Defi i6n de requisitos del sistema Con la descripcién del sistema {y teniendo en consideracién la opi- nién de los usuarios del mismo, sobre todo en la parte que se deberd integrar), se deben describir los requisitos que debe cumplir el pro- yeclo del cual se estudiard la viabilidad 22 Con ellos se podriin evaluar las alternativas posibles para solucionar el problema propuesto. Es necesario tener en cuenta que en esta des- cripcién debe incluirse una prioridad (p. ej, enire 1 y 10, siendo 10 la maxima prioridad) con el objetivo de tener una valoracién relative de cada uno. Asi, en la fase de diseno de la arquitectura so sabri cudintos recursos hay que asignarle. La forma més simple de elaborar esta lista de requisitos es sencillamente con una descripcién, una breve explica- cidn y la prioridad que se le asigna Caso practico En nuestro caso se deberd realizar una lista descriptive de los servicios que se necesilord inslolar para dimen- sionar, més adelante, la arquitectura del sistema y de- cidir cudl es el hardware que hay que comprar. En el caso del ejemplo preseniado, el detalle de los servicios, se puede enumerar como: + Acceso tnico (10): servicio de NIS y NFS para que cade usuario pueda acceder a los datos indepen dienlemente del terminal que se use. + Acceso controlado a web y mail seguro (10). + Base de datos de la empresa con datos sobre clien- tes y personal para la facturacién y néminas (10) (ceparadas) * Sistema de seguridad a través de cortafuegos y DMZ (10) + Impresién en red (9) + Servicio de acceso a publicar datos en el sistema web de la empresa (9). + Gestién de copias de respaldo e informacién de los sistemas (logs)(8). Para los clientes de la empresa se deben ofrecer los si- guientes servicios: + Portal web (8): informacién de servicios y punto de entrada a la compra de servicios por comercio electrénico. + Impresién remota (7): los clientes pueden enviar sus impresiones de alta calidad a los dispositivos de la empresa + Servicio de almacenamiento de archivos (7): los clier- es pueden alquilar un espacio de almacenamiento para mantener alli sus archivos parficulares (FTP en forma segura -SFTP-)..+ Foros de discusién, atencién al cliente y soporte (FAQ) (5) + Servicio de base de datos a los clientes (4). Los requisitos legales deben ser cubiertos por el control de seguridad y la separacién de datos con identificacién de los usuarios y seguimiento de la actividad en cada sorvie dor. En cuanto a licencias de software, deben basarse Giempre que sea posible) en soluciones de software libre y lo menos reslricivas posible. Los requisilos econémicos deben fundamentarse en el equilibrio entre el coste y el servicio que se debe dar (es importante contemplar si los servidores necesitan sistemas de 24 horas y 7 dias/sema- na de funcionamiento en cuanto al mantenimiento del hardware y a los sistemas de alimentacién interrumpida SAL). Los requisitos operativos pasan por la responsa- bilidad del personal técnico de la empresa para mante- ner fodos los servicios una vez configurados y puestos en marcha por el equipo de proyectos, Estudio de alternativas de solucién Con los requisitos que plantea el nuevo proyecto, se estudiardin diferen- tes soluciones, siempre y cuando sea posible, que cumplan con todos éstos, Para ello, es necesario contemplar toda Ia informacién recogida hasta el momento y para cade aliernativa se deberd especificar tanto su definicién funcional, como técnica, sus puntos fueries y sus puntos débie les, y describir el valor econdmico que supone tanto en costes directos {p. ¢i, icencias) como en costes derivados (p. ej. mejoras —updates-) Tampoco se debe descuidar la informacién acerca de estindares que cumple, implantacién en el mercado y soporte que ofrece, Caso practico En nuesiro ejemplo practico, uno de los requisitos es que la solucién se base en software Ii den analizarse diferentes opciones dentro de estas variantes re, pero pue- Licencia GPL -Gnu public license- (minimo coste): ser- vidores y méquinas de escritorio basadas en distribu- ciones como Fedora, Debian, etc. 23+ Parcialmente en licencia GPL: servidores en Fedo- 10, Debian o similares y escritorios en opciones con licencia GPL, como por ejemplo Linspire, SUSE, Mandrake, etc. + Licencia LGPL v ofras similares (mayor coste): servi- dores y escrilorio basades en distribuciones como Red Hat, Mandrake, SuSE, etc Se deben analizar cvidadosamente estas opciones teniendo en cuen- ta el coste derivado de las licencias que, en este proyecto, aparte del hardware, serd el mayor coste junto con el de personal. Se debe recordar que la definicién de cédigo abierlo es una especi= ficacién del tipo de eédigo y no es en si misma una licencia de soft- ware. Una de las licencias de este fipo més comunes es la GPL, y bajo ésta, el software puede ser copiado y modificado, pero las modifica- ciones han de hacerse piblicas bajo la misma licencia. La GPL se di- ferencia de la licencia LGPL, que es pricticamente igual, pero permite lo mezclo con software propietario. Existe una gran cantidad de software libre que incluye parte propietaria, como por ejemplo, MPL NPL (Mozilla public license y Netscape public license) en Mozi- lla, BSD en Apache, ete. Para contabilizar y facilitar el siguiente paso, es interesante confec- cionar una tabla que presente las caracteristicas posibles como la six guiente que se muestra a modo de ejemplo (el alumno deberé completar la informacién sobre el precio de las distribuciones y en la Ultima fila deberian incluirse las necesidades minimas para procesa- dor, memoria, disco y el precio resultante de este ordenador -no i cluidos en este ejemplo-}1-3. Comparacién entre los diferentes sistemas operativos ite. et ic, nodose Soa. Relacionado con este aspecto, y dependiendo del proyecto, es inte- resante calcular lo que se denomina TCO (total cost of ownership, coste total de la propiedad de un ordenador) que comporta las par tides siguientes: + Coste total del hardware y software + Mejoras previstas en hanware y software (ypdotes) + Mantenimiento + Soporte tecnico + Entrenamiento 0 aprendizaie ‘Se puede tomar como base para una estimacién de este coste 3-4 veces el costo de compra del PC y puede aportar informacién sobre la plataforma y/o arquitectura més adecuada a seleccionar. En nuss- tro caso, este célculo lo haremos de manera seporada para ver la influencia de los diferentes elementos que definen la inversién total {aproximada) del proyecto.26 Valoracién y eleccién de las po soluciones Con una lista de requisitos y caracteristicas écnicas de las posibles aliernativas, se debe escoger la solucién mas apropiada para el pro- yecto. En esta fase se tendré en consideracién toda la informacién recogida hasta el momento (descripcién general, alcance, siluacién actual, etc.) y para cada alternativa se deberd especificar en qué con- siste, tanto a nivel funcional como técnico, En nuestro caso, la tabla anterior sera de vital importoncia para la toma de decisiones. En esta tabla (aqui sélo hecha a modo de ejemplo y con datos figurativos) debe ompliarse para que incluya Una lista de todos los servicios que son necesarios para cada requi- sito y asi pueda facilitar la seleccién de la solucién més adecuada Esta tabla permitiré, aden 4s, poder hacer un informe ejecutivo de cada opcién. Caso practico Por ejemplo, para el punto 4 de las necesidades del caso practico propuesto: Sistema de seguridad a trovés de cortafuegos y DMZ (prioridad 10) * Debian: integrado y de alta confiabilidad y funciona- lidad (iptables). Configuracién muy técnica, Grado de adaptabilidad: 100%, + Mandrake: integrado (Shorewall). Versatilidad jada (es posible instalar iptables). Muy f4 figurar y controlar. + RedHat: andlogo a Debian. + Windows®: sélo en XP y 2003 con SP2. Limitado y configuracién aceptable Es necesario tener en cuenta que en el anélisis econémico se deben considerar los costes directos y los indirectos de cada solucién, tal y como ya se mencioné anteriormente, Ademés de estudiar la viabil dad econémica de las diferentes soluciones, se deberdin analizar los riesgos asociados a cada una de ellas.Para cada una de las altemativas existentes serd necesario describir qué incerfidumbres, problemas potenciales, etc. existen. Por ejemplo, se de- bord valorar come riesgo: seguridad, continuidad del SO, responsabili- dades legales, ciclo de mejoras estable (updates), ete. Para cada uno de los riesgos potenciales deteclados, se deben incluir las allernativas post bles para hacer frente a estas posibles amenazas y en qué forma pue- den afectar a la capacidad de funcionamiento del sistema Ademds, como toda la infraestructura debe ser aulénoma una vez instalada y configurada, no deben descartarse los costes asociados © la formacién de los usuarios y los técnicos de la empresa Existen proyectos en los que es posible contratar empresas dedicadas al mantenimiento y actualizacién de estos servicios (outsourcing) y los cuales fendran también unos costes asociados. En este sltimo caso, se debe realizar un contrato preciso que detalle todas las opciones y prestaciones que deben ser realizadas, asi como las penalizaciones que se deriven por incumplimiento de las condiciones. Caso practic Teniendo en cuenta todos los elementos de jvicio antes planteados, la solucién adoptada (una de las posibles) para nuestro sistema ejemplo sord * Sistema operativo: Fedora Core 3. + Acceso y administracion: NIS (acceso a los datos independiente del ordenador), Webmin, LinuxCont (administracién y configuracién) + Archivos e impresion: NFS (comparticién de archi vos), Samba (comparticién de archivos desde siste- mas Windows}, CUPS (servidor de impresin). + Red y seguridad: DHCP [servicio de informacién para, méquinas), NAT (franslacién de DNS [servicios de informacién de nombres), cciones de red), id (ervicio de conexiones seguro), SSH (servicios de co- nexién interactive seguro), Wu-FTP, SFTP (servicio de iransferencia de ficheros -normal y seguro-), Iptables (cortafvegos), Nmap, Nessus, Snort, Logcheck, Tripwire (herramientas de seguimiento, seguridad y conirol), Gnupg (gestién de firma digitales y en- criptacién). 2728 Servicios web, mail y news: Apache-Tomeat (servicio de www), Exim (servicio de correo), IMAP (servicio de correo a clientes), LealNode (servicio de noticias) + Servicio de base de datos: PostgreSQL Con toda esta informacién se procederd a generar un informe, que incluiré un presupuesto detallado de los costes del proyecto (tanto los costes directos come indirectos). El informe deberd ser aceptado y aprobado por ambas partes (clientes ~ grupo de proyectos). Depen- diendo de lo relacién entre cliente y grupo de proyecto, es decir, si es un cliente externo o si el proyecto es para la misma empresa, se fir mard un anexo al contrat que contenga los elementos necesarios que indiquen cusiles son las obligaciones/responsabilidades de cada uno de las partes.Agradecimientos Introduccién Objetivos Estudio de viebilidad «oo 1.1. Necesidades y requisitos del cliente 1.2. Anélisis de la situacién actual 1.8. Definicibn de requisitos del sistema 1.4, Estudio de alternativas de solucién 1.5. Valoracién y eleccién de las posibles soluciones 2.1. Definicién del sistema 2.2, Requisitos exactos del proyecto 2.3, Establecimiento de requisitos 2.4, Definicién de interfaces de usuario 2.5, Especificacién del plan de pruebas 3. Disefio del sistema 3.1, Arquitectura 3.2, Definicién de niveles de arquitectura 3.3, Especificacién de estindares, normas de disenio yconstruccién 3.4, Identificacién de subsistemas 3.5, Casos de usos reales 3.6, Revisién de casos de uso por subsistoma 3.7. Especificaciones de desarrollo y pruebas 3.8, Requisitos de implantacién Desarrollo 4.1, Planificacién de las actividades de integracién del sistema ia 15 7 21 2 23 26 30 30 31 35 37 38 a a2 a2 45 a7 48 49 50 55 60 6130 sistema Una vez definida la solucin que hay que adoptar en el estudio de Viabilidad, es necesario realizar una especificacién detallada de la misma con el objetivo de preparar su diseno y su arquitectura. Esta especificacién se realiza durante la fase de “ondlisis del sistema”, donde es muy importante la interaccién con los usuarios de éste para descartar la posibilidad de omisién y/o errores que lleven a disefios no adecuades. Definicién del sistema Como se verd en los parrafos siguientes, se debe describir el sistema con un alto grado de detalle, especificando no sélo la funcién de cada elemento, sino su comunicacién con los restantes componen- es. También deberd ser necesario especificar qué usuario serd el responsable de cada uno de estos componentes y hasta dénde lle- lad. gard su responsa esi Préctico propuesto, la descripcién se realizard toniendo en cuenta la ;portante destacar que en el presente apartado y para el caso de alto nivel realizada en el estudio de viabilidad del apariado ante- rior, pero que se hard con mayor profundidad. Cabe considerar que este anilisis debe servir para poder, mas adelante, hacer el disefio de la solucién adoptada Es por ello por lo que dentro de este apartado se utilizaré la enu- moracién de requisitos del estudio de viabilidad para establecer las necesidades exactas del mismo y cuél soré el intorcambio de infor- macién (si la hay) entre los diferentes componentes del sistema. Se debe remarcar la imporlancia de este apartado, ya que una defini cién inadecuada del sistema de intercambio de informacién puede dar lugar a un disefio que no contemple todas las necesidades de laempresa, Esta situacién implicaria vueltas atrds en el proyecto con los consabidos retrasos y costes afiadidos a la finalizacién del proyecto 2.2. Requisitos exactos del proyecto + Requisitos legales. Dado que la empresa procesaré datos relatives a cliente y empleados, se debe cumplir todas las normativas vigen- tes en proteccién de datos y acceso a la informacidn. Porello, el di- sefio deberd coniemplar los méiodos de identificacién y control de acceso a la informacién de acuerdo a la ley y con los mecanismos de cortificacidn, controV/cifrado adecuados para cumplir lo estable- cido legalmente. + Requisitos de propiedad intelectual y licencias. El proyecto debe bosarse en software libre y con licencias le menos restrilivas po- sible, teniendo en cuenta las inversiones necesarias, tanto en la ad= Quisicién inicial como en el servicio postenta de aclualizaciones y mantenimiento, + Requisitos de acceso Unico. Los datos de la empresa se centrali« zarén en un servicio distribuido (interno) de archivos mediante NFS. Esta opcién deberd contemplar los requisitos de seguridad para la aceptacién del servicio de las méquinas clientes y con los criterios adecuados en cuanto a los permisos de lectura-escritura para cada méquina cliente. También los datos de usvario de la red deberdn estar centralizados por un servicio de informacién distribuide (NIS), de modo que cada usuario tenga en la empresa una Gnica cuenta y una palabra clave para el acceso a los servi- cios desde todas las maquinas. Dada Ia existencia de maquinas Windows, ser necesario la integracién con un servidor Samba para el acceso unificado a los archivos desde estas maquinas. + Requisitos de acceso web, mail y grupos de noticias. Los servi- cios de acceso a paginos de informacién de la empresa deberén contemplar la posibilidad de acceso cifrado (hitps) mediante SSL, ya que el acceso a algunas partes de Ia informacién deberd ser confidencial para algunos clientes. Asimismo, deberd contemplar médolos de identificacién para el acceso personalizado a dicha informacién, Los servicios de correo electrénico también deberan ser cifrados a través de SSL, tanto si son mediante clientes IMAP 0 3132 POP (imaps y pops), como si lo es mediante webmail (hitps). Los servicios de correo deberdn contemplar Ia inclusién de recursos eniivirus y antispam, tanto para los mensajes de entrada como para los de salida, El acceso a los grupos de noticias podré ser abierto pero Ia inclusién de noticias deberd ser minimamente controlado, por ejemplo, a través de registro previo y con mode- radores para cada tema, ya que este sistema seré utilizado tanto pora las preguntas frecuentes (FAQ), como para la informacién de soporte Requisitos sobre la base de dates. La base de datos de la em- presa deberd ser s6lo accesible a las méquinas de la Intranet, ya que contendré informacién sensible sobre clientes, facturacién y néminas, Esta base de datos podrd accederse a través de peticiones SQL desde servicios web (p. ej. a fravés de paginas web con PHP) 0 inleractivamente, pero siempre con palabra clave en ambos casos. Requisitos del sistema de seguridad. El sistema informatico de la ‘empresa (servidores y méquinas clientes) deberd tener un diseno basado on un cortefuegos institucional con una definicién clara de zonas (DMZ), con direcciones privadas y traslacién (p. ej. tra- vas de NAT). Elsistema deberd contar con las herramientas de de- teccién y andlisis adecuadas que permitan o los adminisiradores realizar un control adecuado del sistema informético. La organi zacién interna de le red se basaré en un sistema de distribucién de direcciones IP auiomético (DHCP) y un servidor de nombres se- cundario interno (DNS). Deberd tenerse en cuenta la posibilidad de que cada usuario posea un cerlificado digital interno (GnuPG) gostionado « través de una unidad certificadora local (CA). Requisitos de impresién en red, Desde cada maquina de la em- prose se podré acceder a un servicio de impresién centralizado mediante colas (CUPS), donde cada maquina cliente deberd ser identificada y contabilizado el trabajo de impresién realizado. Requisitos de servicio de acceso para publicar datos en el sis- tema web de la empresa, La empresa dispondré de un sistema de acceso a Ia informacién via un servicio de web, y los usuarios del sistema (empleados de la empresa) podran publicar y/o ac- tualizar informacién de la empresa, siendo ellos mismos respon- sables de dicha publicacién, todo lo cual deberd roalizarse mediante métodos de identificacién adecuados. Habré que imple- mentar un control de acceso para este servicio y un registro de mo=dificaciones. Asimismo, se deberé habilitar un sistema de registro de actividad de servicio de web con el fin de tener informacién ana- ltica para la empresa (desde dénde se accede y a qué informacién) como desde el punto de vista del andlisis de seguridad + Requisitos de gestion de las copias de respaldo e informacién de los sistemas. El sistema informético deberd contar con un ser- vicio de copias de respaldo de la informacién planificada tenien- do en cuenta que ésias habran de cumplir unas condiciones de almacenamiento fisicas de seguridad cuando los datos fengan re- quisitos de confidencialidad. Asimismo, deben integrase todos los datos de seguridad (logs) en un sistema centralizado para que el andlisis sea efectivo y real del sistema en conjunto, no sélo de mé~ quinas particulares Para los clientes de la empresa, se ofrecerdin los siguientes servicios: + Requisitos del portal web. El portal de informacién de la empre- sa deberd admitir servicios complementarios como puede ser la compra de servicios ofrecidos por la empresa, impresiones remo= as en dispositivos de alta calidad u otros servicios con valor afa- dido. Para ello, se tendrdn en cuenta las posibilidades de peticién del servicio, identificacién del cliente, modo de entrega y pago del mismo. Deberdn establecerse modelos diferentes si son clientes registrados/habituales o clientes nuevos v ocasionales + Requisitos de servicio de almacenamiento de archivos. La em presa ofrecerd un servicio de almacenamiento de informacién a clientes registrados, por lo cual se deberd montar un servicio de gestion de espacio (cvotas) y acceso de clientes remotos a sus es- pacios de disco (conocido generalmente como FTP, pero que de- berd ser implementado como SFTP para evitar problemas de seguridad). Este servicio deberd ser fiable, por lo cual el sistema contard con copias de respaldo gestionadas por la empresa de manera separada a las copias de respaldo propias. + Requisitos de servicio de base de datos a los clientes. Los clien- tes podrdn contar con un servicio de base de datos con acceso re- moto. La empresa sélo proveerd un servicio de alojamiento y acceso seguro a la informacién de la base de datos del cliente, pero no serd responsable de la creacibn de la base ni de los datos 33