UNIVERSIDAD DE LAS AMERICASFACULTAD DE CIENCIAS DE LA INFORMATICA

DISEO DE SISTEMA DE ALTA DISPONIBILIDAD EN SERVIDOR DE BASE DE DATOS SQL SERVER Y APLICACIN CREADA EN LENGUAJE .NET

JOSE FELIPE MONDACA MEJIAS 2011

UNIVERSIDAD DE LAS AMERICASFACULTAD DE CIENCIAS DE LA INFORMATICA

DISEO DE SISTEMA DE ALTA DISPONIBILIDAD EN SERVIDOR DE BASE DE DATOS SQL SERVER Y APLICACIN CREADA EN LENGUAJE .NET Trabajo de titulacin presentado en conformidad a los requisitos para obtener el ttulo de Ingeniero de ejecucin en Informtica

Profesor gua: Sr. Rene Galarce Godoy

JOSE FELIPE MONDACA MEJIAS 2011

RESUMEN El presente proyecto, se orienta al diseo y la implementacin de un sistema de alta disponibilidad tolerante a fallos en servidores de base de datos con Microsoft SQL Server, y en servidores de aplicacin implementado en un sistema de ambiente WEB. La tolerancia a fallos tal como se conoce actualmente se basa fundamentalmente en el concepto de redundancia. Una de las mejores maneras de asegurar la disponibilidad de los equipos, y con ellos tambin los servicios que estos prestan, de manera fiable y sin interrupciones las 24 horas durante los 7 das de la semana, es la duplicacin de todos los elementos crticos, tales como discos duros, fuentes de poder, tarjetas de red, etc., y la disposicin de software que permita que estos elementos redundantes acten de manera cooperativa y correcta. Estos elementos pueden funcionar de manera Activa-Activa o de manera Activa-Pasiva, sin embargo independiente de como interacten estos elementos y la cantidad de elementos redundantes que podamos tener, todo este proceso y toda esta configuracin debe funcionar de manera transparente para el usuario final. En el presente proyecto se revisar los principales elementos de riesgo en un sistema informtico y se plantearan maneras de evitar los riesgos o reducirlos, y sern aplicados en un caso real.

i

SUMMARY This project targets to high availability database servers design and implementation with Microsoft SQL Server, and application servers implemented in a Web environment. Fault tolerance, as is currently known, is mainly based on redundancy concept. One of the best ways to ensure equipment availability, and with them the services they provide, reliably and with no interruption 24/7, is to duplicate all critical elements, such as hard drives, power supplies, network cards, etc., and providing a software that allows these redundant elements to work cooperative and correctly. These elements may work in an Active-Active or Active-Passive way, but regardless of how these elements interact and redundant elements quantity that might have the whole process and all these settings must be made in a transparent way to the end-user. This project will review the main risk elements in a computer system and will suggest ways to avoid or reduce them, and apply all this in a real case.

ii

INDICE INTRODUCCIN. 1 CAPITULO I 1.1 OBJETIVOS DEL TRABAJO.. 3 1.1.1 Objetivo general.... 3 1.1.2 Objetivos especficos..... 3 1.2 ANTECEDENTES DE LA EMPRESA.... 4 1.2.1 Descripcin de la empresa..... 4 1.2.2 Visin..... 4 1.2.3 Misin.... 4 1.2.4 Valores....... 4 1.2.5 Estructura....... 5 1.2.6 Organigrama....... 5 1.3 SITUACION ACTUAL..... 6 1.3.1 Sucursales....... 6 1.3.2 Enlace de datos....... 6 1.3.3 Datacenter...... 7 1.3.4 Suministro elctrico... 8 1.3.5 Climatizacin..... 9 1.4 DESCRIPCIN DEL REA DEL PROBLEMA... 10 1.4.1 Definicin especifica de los problemas... 10 1.5 ESTADO DEL ARTE...... 11 1.5.1 Servidor de Aplicacin..... 11 1.5.1.1 RRDNS... 11 1.5.1.2 Load Balancing Switch... 12 1.5.1.3 Microsoft NLB.... 13 1.5.2 Servidor de Base de datos.... 13 1.5.2.1 Log Shipping... 13 1.5.2.2 Database Mirroring..... 14 1.5.2.3 Server clustering...... 17 1.5.3 Monitoreo Sala de servidores... 18 1.5.3.1 Hardware de monitoreo... 18 1.5.3.2 UPS..... 19 1.6 SOLUCIN PROPUESTA...... 20 1.6.1 Beneficios esperados.... 20 1.6.2 Alcances y Limitaciones...... 20

iii

CAPITULO II 2.1 METODOLOGAS...... 22 2.1.1 Metodologas en la ingeniera de software... 22 2.1.2 Tipos de Metodologas..... 22 2.1.3 Metodologas Tradicionales..... 23 2.1.4 Metodologas giles.... 23 2.2 SELECCIN DE LA METODOLOGA..... 26 2.2.1 Metodologas giles.... 26 2.2.1.1 XP, Extreme Programming..... 26 2.2.1.2 SCRUM... 27 2.2.1.3 Crystal..... 27 2.2.1.4 DSDM, Dynamic System Development Method.... 28 2.2.1.5 FDD, Feature Driven Development.... 28 2.2.1.6 ASD, Adaptive Software Development...... 29 2.2.1.7 XBreed.... 30 2.2.2 Metodologa a usar en el proyecto... 30 2.2.2.1 Mayor presencia en Internet.... 30 2.2.2.2 Metodologa mejor documentada.... 32 2.2.2.3 Comparativo de metodologas..... 33 2.2.2.4 Metodologa seleccionada... 33

CAPITULO III 3.1 FACTIBILIDAD TCNICA... 35 3.1.1 Hardware...... 35 3.1.1.1 Servidor de base de datos.... 35 3.1.1.2 Servidor de aplicacin..... 36 3.1.1.3 Monitoreo ambiental... 37 3.1.2 Software....... 38 3.1.2.1 Base de datos... 38 3.1.2.2 Aplicacin....... 38 3.1.2.3 Monitor ambiental... 38 3.2 FACTIBILIDAD ECONMICA..... 40 3.2.1 Equipo de trabajo..... 40 3.2.2 Hardware requerido...... 41 3.2.2.1 Base de datos... 41 3.2.2.2 Aplicacin... 41 3.2.2.3 Monitor ambiental... 42 3.2.3 Software requerido... 42 3.2.3.1 Base de datos... 42 3.2.3.2 Aplicacin... 43 3.2.3.3 Monitor ambiental... 43 3.2.4 Costo total del proyecto... 43iv

3.3 FACTIBILIDAD LEGAL.... 45 3.4 FACTIBILIDAD OPERATIVA...... 47 3.4.1 Rechazo al cambio... 47

CAPITULO IV 4.1 CICLO DE VIDA DE SCRUM... 48 4.1.1 Planificacin del Sprint.... 48 4.1.2 Desarrollo del Sprint.... 49 4.1.3 Revisin del Sprint... 49 4.2 ROLES Y RESPONSABILIDAD... 50 4.2.1 Dueo del producto...... 50 4.2.2 Scrum Master... 50 4.2.3 Equipo de trabajo..... 50 4.3 PRCTICAS.... 51 4.3.1 Product Backlog....... 51 4.3.2 Sprint Backlog...... 51 4.3.3 Estimacin de esfuerzo.... 51 4.3.4 Grfico Burn-down...... 51 4.3.5 Grfico Burn-up... 52 4.3.6 Planing Poker o estimacin de poker... 52 4.4 DESARROLLO DEL PROYECTO.... 53 4.4.1 Equipo de trabajo..... 53 4.4.2 Product Backlog... 53 4.4.3 Carta Gantt del proyecto...... 54 4.4.4 Sprint 0..... 54 4.4.4.1 Estimacin de historias... 56 4.4.4.2 Sprint Backlog.... 56 4.4.4.3 Diagrama de horas de esfuerzo... 59 4.4.4.4 Software de administracin de Scrum.... 60 4.4.5 Sprint 1..... 61 4.4.5.1 Gantt del Sprint 1 61 4.4.5.2 Sprint Backlog. 61 4.4.5.3 Diagrama de horas de esfuerzo... 62 4.4.5.4 Reunin diaria. 63 4.4.5.5 Reunin de revisin. 63 4.4.6 Sprint 2..... 67 4.4.6.1 Gantt del Sprint 1 67 4.4.6.2 Sprint Backlog. 67 4.4.6.3 Diagrama de horas de esfuerzo... 68v

4.4.6.4 Reunin diaria. 69 4.4.6.5 Reunin de revisin. 70 4.4.7 Sprint 3..... 72 4.4.7.1 Gantt del Sprint 1 72 4.4.7.2 Sprint Backlog. 72 4.4.7.3 Diagrama de horas de esfuerzo... 73 4.4.7.4 Reunin diaria. 74 4.4.7.5 Reunin de revisin. 75

CAPITULO V 5.1 CONCLUSIONES..... 77 5.1.1 Monitoreo ambiental.. 77 5.1.2 Alta disponibilidad de aplicacin.. 77 5.1.3 Alta disponibilidad en base de datos. 78 5.1.4 En resumen 78 REFERENCIAS..... 79 ANEXOS 80

vi

INDICE DE IMGENES

CAPITULO I 1.1 Organigrama de la empresa EPYSA IMPLEMENTOS. 5 1.2 Esquema del enlace de datos actual... 7 1.3 Esquema actual de servidores.... 8 1.4 Granja de servidores Web.... 11 1.5 Base de datos reflejada. 15 1.6 Base de datos reflejada con servidor testigo 16 1.7 Cluster de SQL. 17 1.8 Monitor ambiental para sala de servidores....... 19

CAPITULO II 2.1 Metodologas con mayor presencia en Internet... 31 2.2 Metodologas mejor documentadas. 32

CAPITULO IV 4.1 Fases de Scrum 48 4.2 Grfico Burn-Down. 51 4.3 Grfico Burn-Up.. 52 4.4 Gantt del proyecto completo.... 54 4.5 Sprint 0. 55 4.6 Sprint 1 con sus correspondientes tareas y plazos definidos... 57 4.7 Sprint 2 con sus correspondientes tareas y plazos definidos... 57 4.8 Sprint 3 con sus correspondientes tareas y plazos definidos... 58 4.9 Tarjeta de historia de Scrum.... 58 4.10 Tabln del Sprint en donde se van organizando las tareas e historias... 60 4.11 Sprint 1... 61 4.12 Grfico de Burn-down del Sprint 1.... 62 4.13 Grfico de temperaturas del monitor ambiental. 64 4.14 Hoja de configuracin de humedad del monitor ambiental... 64 4.15 Hoja de configuracin de temperatura del monitor ambiental... 65 4.16 Correo de alerta del monitor ambiental.. 65 4.17 Sprint 2... 67 4.18 Grfico de Burn-down del Sprint 2.... 69 4.19 Granja de servidores EPYSA. 70 4.20 IP virtual del cluster de servidores Web.... 71 4.21 Sprint 3... 72 4.22 Grfico de Burn-down del Sprint 3.... 74 4.23 Propiedades de la base de datos reflejada.. 75vii

INDICE DE TABLAS

CAPITULO II 2.1 Tabla comparativa de metodologas giles y tradicionales.. 25 2.2 Tabla comparativa de metodologas giles.. 33

CAPITULO III 3.1 Comparativo de servidores HP Proliant DL de gama media... 36 3.2 Comparativa de servidores HP Proliant de gama baja. 37 3.3 Comparativo de equipos de monitoreo ambiental 37 3.4 Costo del equipo de trabajo.. 40 3.5 Valor del servidor de base de datos.. 41 3.6 Valor del servidor de aplicacin.. 41 3.7 Valor del monitor ambiental.... 42 3.8 Valor de licencias requeridas para servidor de base de datos.. 42 3.9 Valor de licencias requeridas para servidor testigo de base de datos.. 43 3.10 Valor de licencia requerida para el servidor de aplicacin 43 3.11 Costo total del proyecto. 44

CAPITULO IV 4.1 Equipo de trabajo y sus capacidades 53 4.2 Producto Backlog del proyecto 54 4.3 Backlog con Sprint y estimacin de esfuerzo indicado... 55 4.4 Estimacin de horas requeridas en cada Sprint... 59 4.5 Backlog Sprint 1.. 61 4.6 Programacin de esfuerzo en el Sprint 1..... 62 4.7 Backlog Sprint 2.. 67 4.8 Programacin de esfuerzo en el Sprint 2..... 68 4.9 Backlog Sprint 3.. 72 4.10 Programacin de esfuerzo en el Sprint 3... 73

viii

INTRODUCCION El tiempo es oro, versa un popular dicho para indicar la importancia de no perder tiempo, y para reafirmar el hecho que cada segundo que pasa es dinero perdido. Las empresas tienen esto muy claro y entienden que cada minuto sin acceso a la informacin significa muchas veces varios millones en prdidas y una muy mala imagen ante sus clientes. En el mundo actual, cada vez ms tecnolgico, el uso de los sistemas informticos para almacenar, administrar y mantener la informacin, lleg para quedarse. Desde los dispositivos de bolsillo, hasta los grandes centros de datos de las grandes compaas, todas tienen como finalidad, almacenar informacin importante para las personas y para las compaas y mantener esa informacin accesible cuando el usuario lo requiera sin importar el lugar en el cual se encuentre. Las empresas invierten importantes sumas de dinero en proteger esta informacin, existiendo sistemas desde los ms simples, como las copias de seguridad en medios pticos y/o magnticos, hasta los ms complejos, como los grandes Datacenter compuestos de mltiples y costosos servidores. La gama de opciones y posibilidades es enorme, variando en complejidad y en costos de implementacin y mantencin, todo esto para asegurar la disponibilidad y la integridad de los datos. Un sistema de informacin ideal supone estar disponible en todo momento y ser accesible desde cualquier lugar, pero para lograr llegar a este ideal existen muchos factores que interactan los cuales deben funcionar correctamente. Sin embargo, algunos de estos factores escapan al control y al manejo de los administradores de sistemas, es por esto que los sistemas ideales no existen y las vulnerabilidades y riesgos siempre estn presentes. Lo nico que los administradores pueden hacer es minimizar los riesgos al mximo, pero nunca podrn eliminarlos totalmente. Para poder minimizar los riesgos, es necesario primero identificar las vulnerabilidades y los riesgos existentes. Estos riesgos varan dependiendo de cada caso y cada escenario, y debido a que los escenarios son tan variados y distintos cada caso requiere un anlisis de riesgos independiente. Una vez identificados los riesgos, los administradores pueden anticiparse a los potenciales fallos creando planes de contingencia con los cuales se puede llegar a manejar y administrar el riesgo minimizndolo tanto como sea posible, manteniendo intacta la confiabilidad de los datos. En el presente documento, se har un anlisis de los riesgos presentes en el ambiente informtico de la empresa EPYSA, identificando las potenciales vulnerabilidades existentes y se implementar un sistema de alta disponibilidad para los servicios de Base de datos y de publicacin Web. Ambos servicios permiten el funcionamiento de los sistemas de venta y facturacin de la empresa. La necesidad nace debido a un fallo producido en el servidor de base de datos de la empresa, el cual dej a todas las sucursales de la compaa sin sistema para poder vender y1

facturar por un periodo de varias horas. Esto trajo como consecuencia millonarias prdidas para la empresa. Si bien actualmente la empresa cuenta con sistemas de respaldo para las aplicaciones y para las bases de datos, estos respaldos se realizan principalmente en cintas magnticas, sin embargo la deficiencia de este sistema es que no tiene la capacidad de recuperar los datos en un corto periodo de tiempo. La dificultad se genera debido a que la contingencia ante un fallo como el antes descrito se torna demasiado lenta al momento de hacer una restauracin de datos desde los sistemas de respaldo, y lo que se necesita es mantener la continuidad operativa del negocio. La empresa tampoco cuenta con hardware de respaldo para sus actuales equipos. Ante el fallo fsico de alguno de los servidores, ya sea el de base de datos o el de aplicaciones, el actual plan de contingencia contempla la preparacin de un nuevo hardware desde cero. Por otro lado no se cuenta con un hardware equivalente en capacidad, lo que trae como consecuencia una degradacin de los servicios prestados, debido a las limitantes que tiene dicho hardware. Con la vulnerabilidad identificada, se pretende reestructurar el sistema de hardware informtico actual, y se pretende generar un sistema de alta disponibilidad de hardware, en el cual, ante un fallo de cualquiera de los servidores, ya sea en el de base de datos o en el de aplicacin, se pueda asegurar la disponibilidad del sistema de ventas y facturacin sin que se genere una interrupcin del servicio para el usuario final Tambin se har una revisin del actual estado de los equipos y servidores que conforman la sala de servidores, la revisin incluye el sistema de refrigeracin y los sistemas de monitoreo actuales. Esta revisin tiene una gran importancia, debido a que el personal de informtica no trabaja con un sistema de turnos. El horario laboral es de lunes a viernes en horario de oficina, el resto del tiempo, la sala de servidores no cuenta con personal presente en el lugar fsico, y las oficinas permanecen cerradas, dependiendo de la jefatura de administracin para cualquier acceso fuera del horario normal, por lo que ante cualquier fallo, si no se cuenta con un sistema de monitoreo adecuado, el personal de informtica no tiene como enterarse de la falla, y en consecuencia la aplicacin de cualquier plan de contingencia se ve demorado y el tiempo sin servicio es mucho mayor.

2

CAPITULO I 1.1 OBJETIVOS DEL TRABAJO

1.1.1 OBJETIVO GENERAL Disear un sistema de alta disponibilidad para los sistemas de ventas y facturacin de la empresa.

1.1.2 OBJETIVOS ESPECIFICOS Implementar un sistema de alta disponibilidad para bases de datos SQL. Implementar un sistema de alta disponibilidad para aplicaciones Web. Implementar un sistema de monitoreo ambiental para sala de servidores.

3

1.2 ANTECEDENTES DE LA EMPRESA

1.2.1 DESCRIPCION DE LA EMPRESA EPYSA es un holding de empresas dedicadas al transporte. Desde su fundacin, en 1976 por don German Novion Aguirre, comercializa buses, semirremolques, adems de insumos y repuestos para el transporte, creando valor mediante estrategias que impulsan el crecimiento sano y sostenible. EPYSA ha sido por los ltimos 35 aos representante exclusivo para Chile de dos de los grupos industriales ms importantes, exitosos y destacados del Brasil: la fbrica de semirremolques RANDON y la de carroceras de buses MARCOPOLO. EPYSA es hoy en da, la empresa de transportes ms grande de Chile, con 25 sucursales propias, y con los mejores profesionales del mercado.

1.2.2 VISION Ser el principal proveedor de soluciones innovadoras, seguras y confiables para la industria del trasporte a nivel nacional.

1.2.3 MISION Proveer a nuestros clientes de soluciones a sus requerimientos de buses, equipos, partes y piezas, brindndoles una cobertura y presencia a lo largo de todo el territorio nacional, entregndoles una atencin personalizada que satisfaga completamente todas sus expectativas.

1.2.4 VALORES Integridad: Trabajamos juntos para crear con nuestras acciones una atmosfera de confianza entre todos nosotros y aquellos a quienes servimos. Nos responsabilizamos por el cumplimiento de nuestros compromisos. Trabajo en equipo y respeto: Promovemos y resaltamos el trabajo en equipo, respetndonos en todo momento y valorando la contribucin individual. Bsqueda de la excelencia: Buscamos el desarrollo personal y permitimos que los otros hagan lo mismo. Alentamos el aprendizaje, la creatividad y las buenas ideas. Nos ayudamos unos a otros para identificar y resolver problemas.

4

1.2.5 ESTRUCTURA La empresa ha ido incorporando nuevos productos y servicios para lo cual se ha dividido en sub-empresas que apuntan a nichos especficos del mundo del transporte, por lo que hoy EPYSA se divide en: EPYSA BUSES: empresa dedicada a la comercializacin de buses y minibuses siendo el representante exclusivo de las marcas MARCOPOLO y VOLARE. EPYSA EQUIPOS: empresa dedicada a la comercializacin de remolques y semirremolques, siendo representante exclusivo para la marca RANDON. EPYSA IMPLEMENTOS: empresa dedicada a la comercializacin de repuestos, partes y piezas para el transporte de carga y de pasajeros. BUSMARKET: empresa dedicada a la compra y venta de buses usados.

-

-

-

El rea de informtica es la nica rea que presta servicio a todas las empresas de manera transversal. Esto hace que cualquier implementacin y mejora que se haga en la plataforma informtica beneficia a todas las empresas, permitiendo adems mantener una administracin centralizada de todos los recursos informticos. Para el anlisis del presente proyecto se trabajara especficamente con los recursos y sistemas de la empresa EPYSA IMPLEMENTOS. 1.2.6 ORGANIGRAMA

1.1 Organigrama de la empresa EPYSA IMPLEMENTOS

5

1.3 SITUACION ACTUAL

1.3.1 SUCURSALES La empresa cuenta actualmente con dos casas matriz ubicadas en Santiago y separadas geogrficamente. Una se encuentra en la comuna de Huechuraba y la otra en San Bernardo. Cuenta adems con veintitres sucursales en Chile, ubicadas en las principales ciudades que van desde Arica hasta Puerto Montt. De todas estas sucursales, cinco de ellas se encuentran ubicadas en las ciudades ms grandes, las que cuentan con oficinas ms grandes y con un promedio de unos quince a veinte usuarios por cada una. El resto de las sucursales son puntos de venta con oficinas ms pequeas y con un promedio de cinco usuarios por cada una.

1.3.2 ENLACE DE DATOS La red est compuesta de un enlace dedicado MPLS/IP1, en cada una de las sucursales, y que dependiendo de la cantidad de usuarios con los que cuente la sucursal, vara en su ancho de banda y en el tipo de acceso. A travs de este mismo enlace de datos se instalaron tambin anexos de voz extendidos, lo que permite realizar comunicaciones telefnicas con las sucursales a costo cero. En el caso de las dos casas matriz, el enlace se realiza con un acceso a travs de fibra ptica y tiene un ancho de banda de 100Mbps. Para las cinco sucursales ms grandes, el enlace tambin se realiza con un acceso a travs de fibra ptica y tienen un ancho de banda de 10Mbps. Para el resto de las sucursales, el enlace se realiza con un acceso a travs de cableado de cobre y tiene un ancho de banda de solamente 4Mbps. Adems las dos casas matrices cuentan con enlaces dedicados para el acceso a Internet. Estos enlaces son de 10Mbps tanto para el acceso de subida como de bajada. Cada enlace tiene adems seis direcciones IP pblicas asociadas lo que permite realizar la publicacin de servicios en Internet. El tener los enlaces a Internet centralizados permite controlar y limitar los accesos de los usuarios. De esta manera la poltica es que se da solo acceso a las pginas necesarias para que el usuario pueda realizar su trabajo, evitando la descarga e instalacin de software no autorizado, y los contagios de virus que se encuentran en Internet. Este servicio de enlace dedicado de red es provisto por la empresa Movistar Empresas, siendo ellos los responsables de dar el soporte ante fallos y/o cadas de enlace.

1

Del ingles MultiProtocol Label Switching / Internet Protocol que es un mecanismo de transporte de datos estndar que funciona sobre el protocolo Internet.

6

1.2 Esquema del enlace de datos actual

1.3.3 DATACENTER La empresa cuenta con un datacenter, o sala de servidores, en la casa matriz, compuesto por varios servidores, unidad de respaldo de energa (UPS), enlaces de datos privados y hacia Internet. La plataforma completa de sistemas operativos, tanto para los servidores como para los equipos clientes, es de Microsoft, as tambin las herramientas de ofimtica. La red est compuesta por un dominio nico de AD1, independiente de las empresas. Esto permite tener una administracin centralizada y simple por parte del rea de informtica. La aplicacin principal para la venta, facturacin y contabilidad, fue desarrollada por el rea de desarrollo de la empresa, quienes usaron Microsoft Visual Studio .NET para el desarrollo y la implementacin. Esta aplicacin se encuentra publicada a travs del servicio IIS2, que es parte de los servicios presentes en Windows Server 2003, en un servidor dedicado que tiene las siguientes caractersticas de hardware: 1

Servidor HP Proliant DL380 G4 Doble procesador Intel Xeon 2Ghz.

Active Directory, es el termino que usa Microsoft para referirse a su implementacin de servicio de directorio en una red de computadores. 2 Internet Information Services, es un servicio del sistema operativo Windows Server de Microsoft para la publicacin, mantencin y gestin de pginas Web.

7

-

4Gb de memoria RAM

La base de datos utilizada esta implementada en un servidor tambin dedicado que tiene instalado el software Microsoft SQL Server 2005, y que tiene las siguientes caractersticas: - Servidor HP Proliant DL 360 G6 - Doble procesador Quad Intel Xeon 2,6Ghz. - 12Gb de memoria RAM

1.3 Esquema actual de servidores

1.3.4 SUMINISTRO ELECTRICO La casa matriz cuenta con un circuito elctrico especfico e independiente para el suministro de energa de los equipos computacionales. La instalacin elctrica cuenta con dos mallas de puesta a tierra de proteccin, siendo una de estas de uso exclusivo para el circuito computacional. Debido a que la casa matriz se encuentra rodeada de variadas empresas del rubro industrial, es comn que en la lnea elctrica se produzcan picos de tensin y variaciones de voltaje.8

Estos picos de tensin son altamente peligrosos para los equipos informticos, y son adems muy difciles de controlar y casi imposibles de eliminar. Para minimizar el riesgo producido por los picos de tensin, en los tableros elctricos generales de cada uno de los edificios se encuentran instalados supresores de transientes1, que son dispositivos de proteccin que detectan esto picos de tensin y los minimizan, evitando que estos alcancen los equipos instalados en todo el circuito elctrico. Adems, la sala de servidores se encuentra provista de un sistema de respaldo de energa, tambin llamado UPS2. Estos equipos UPS cuentan con sistemas de deteccin de picos de tensin, y un sistema de estabilizacin de voltaje, lo que permite proteger los equipos ante posibles subidas o bajadas en la tensin presente en la lnea elctrica proporcionando un suministro de tensin constante.

1.2.5 CLIMATIZACION En todo equipo elctrico y/o electrnico se produce un aumento de temperatura como consecuencia del normal funcionamiento. Este aumento de temperatura es completamente normal mientras no sobrepase ciertos niveles. Los equipos computacionales por ser equipos compuestos por componentes electrnicos no estn ajenos a este fenmeno de aumento de temperatura. La temperatura adecuada para un dispositivo informtico es de entre 20 y 25 C (68 y 77 F), con una humedad relativa de entre 40 y 55%. Para mantener esta temperatura ideal se usan sistemas de refrigeracin y de aire acondicionado que permiten mantener controlados los niveles de temperatura en los equipos informticos y en las salas de servidores. La empresa cuenta con un sistema de refrigeracin para la sala de servidores, la cual mantiene la temperatura normal entre 20 y 22 en todo momento. Aunque cabe destacar que la sala de servidores carece de un sistema de monitoreo de temperatura o de humedad, por lo que si se produce una falla en el sistema de refrigeracin, los administradores no tienen un sistema de alerta.

1 2

Transiente es una elevacin violenta del nivel de tensin que puede aparecer en la lnea elctrica UPS, del ingls Uninterruptible Power Supply, llamados en espaol como SAI o Sistema de Alimentacin Ininterrumpida.

9

1.4 DESCRIPCION DEL REA DEL PROBLEMA Actualmente la sala de servidores no cuenta con ningn sistema de monitoreo ambiental. Tampoco se cuenta con servidores de respaldo para el remplazo ante un posible fallo de los que estn prestando los actuales servicios de red y de la aplicacin de facturacin y ventas de la compaa. Si bien es cierto existe un plan de contingencia formal que implement la compaa hace algunos aos, este se encuentra desactualizado, e identifica problemticas que ya no son vlidas para el escenario actual de la plataforma informtica. El plan de contingencia tampoco permite realizar una recuperacin en un corto periodo de tiempo ante un desastre.

1.4.1 DEFINICION ESPECFICA DE LOS PROBLEMAS No existe un sistema de monitoreo ambiental que mida la humedad y la temperatura presente en las sala de servidores. No existe ningn servidor de respaldo en caso de fallo de hardware de los servidores actuales. El tiempo de recuperacin y restauracin de datos es muy extenso. La aplicacin web de toda la empresa est alojada en solo una mquina, y si esta mquina falla todos los usuarios quedan sin acceso al sistema de ventas y facturacin. Lo mismo ocurre con el servidor de base de datos de la aplicacin.

10

1.5 ESTADO DEL ARTE 1.5.1 SERVIDOR DE APLICACIN La estrategia utilizada ms comnmente para generar alta disponibilidad en aplicaciones de ambiente Web, es la que se denomina como granja de servidores o por su nombre en ingls, Web farm, y que cuente con algn sistema de balanceo de carga entre los servidores que componen la granja. Con ello se consigue, aparte de una alta disponibilidad, tambin un sistema fcilmente escalable, pudiendo agregar y/o quitar servidores de la granja. Mediante el sistema de balanceo de carga las peticiones entrantes de los distintos clientes son repartidas de distintas formas, segn el mtodo que se utilice, entre los servidores que componen la granja.

1.4 Granja de servidores Web

Existen varias formas de implementar esta distribucin de carga, tres de las ms utilizadas son: Round Robin DNS o RRDNS Load balancing switches Microsoft Network Load Balancing o NLB

1.5.1.1 RRDNS [1] Round Robin DNS es el mtodo ms simple y econmico de implementar. Sirve como balanceo de carga para cualquier servicio basado en TCP/IP, que es una caracterstica base11

de los sistemas operativos ms populares. RRDNS permite que un grupo de servidores aparezca ante los clientes como si se tratara de uno solo, distribuyndose el trfico de estos entre todos los servidores que componen el grupo. El funcionamiento es muy simple: cuando un cliente consulta un servidor DNS buscando un determinado servicio, este le devuelve la direccin IP del servidor que lo proporciona. En una implementacin RRDNS, el servidor DNS cuenta con una lista de direcciones IP diferentes, y ante una consulta, este proporciona una direccin IP diferente cada vez que es consultado por un cliente. Estas direcciones IP son las de los servidores que componen nuestra granja. Cada direccin IP pertenece a un servidor diferente capaz de gestionar estas peticiones, de manera que la carga de trabajo es repartida entre las diferentes maquinas proporcionndonos un mtodo primitivo de balanceo de carga. La principal ventaja de este mtodo es su bajo costo, no requiere hardware especializado ni software adicional. No obstante presenta varias grandes desventajas que se deben tener en cuenta. En primer lugar los clientes hacen una consulta inicial al servidor DNS, y luego mantienen un sistema de cache para la resolucin de nombres de las consultas posteriores. Este cache puede deshabilitarse, pero esto hara bajar el rendimiento de nuestro servidor DNS ya que se vera obligado a resolver una cantidad mayor de peticiones. En segundo lugar, el servidor DNS no recibe en ningn momento informacin del estado de los servidores de la granja, de manera que si alguno de ellos se ve sobrecargado de trabajo, el servidor DNS seguir enviado peticiones de servicio hasta saturarlo, aun cuando el resto de los servidores pudieran estar libres. Finalmente si alguno de los servidores falla quedando fuera de servicio y no es eliminado manualmente del servidor DNS, este seguir envindole peticiones con el correspondiente error para el cliente al no ser capaz de encontrar el servidor. Debido a que este sistema no cuenta con un mtodo de verificacin del estado de los servidores que pertenecen a la granja, y a que esta deficiencia podra dejar a gran parte de los usuarios sin servicio ante la posibilidad de un fallo, o la saturacin de un servidor, se descarta esta alternativa para ser implementada en el presente proyecto.

1.5.1.2 LOAD BALANCING SWITCH [2] Load balancing switch o Switch de balanceo de carga es una solucin de hardware proporcionada por diferentes fabricantes, tales como CISCO o Alteon Websystems entre otros. Es una solucin robusta y muy escalable pero de alto costo. Los switch se instalan entre la conexin a la red y la granja de servidores. Todas las peticiones de los clientes llegan al switch usando la misma direccin IP y es ste, en base a diferentes algoritmos implementados en l, es quien dirige el requerimiento de servicio a uno de los servidores de la granja. El switch enva peridicamente un ping a cada uno de los servidores que componen la granja para verificar en todo momento cuales estn activos y cules no. Asimismo, utiliza el tiempo de respuesta de los mismos para determinar la carga de trabajo de cada uno y utiliza este parmetro en sus algoritmos de enrutamiento proporcionando de esta forma un balanceo de carga inteligente. Su principal inconveniente, es el elevado costo de estos equipos. Adems, si se pretende construir un sistema de alta disponibilidad confiable, no es suficiente la instalacin de un solo equipo, se debe considerar la instalacin de al menos dos de estos equipos, lo que conlleva un aumento considerable en el costo de la solucin.12

El costo es la principal razn por la cual se descarta esta solucin del presente proyecto, la empresa cuenta con un presupuesto definido y la implementacin de esta solucin se escapa de dicho presupuesto.

1.5.1.3 MICROSOFT NLB [3] NLB es una solucin propietaria de la empresa Microsoft disponible en los sistemas operativos de servidor desde la versin de Windows NT 4.0 en adelante. Lleva varios aos de funcionamiento en entornos de produccin en todo tipo de empresas demostrando la estabilidad y confiabilidad del sistema. Este sistema utiliza una direccin IP virtual para formar un Cluster1 de servidores, distribuyendo de forma transparente para los clientes la carga de las peticiones de los clientes entre los servidores fsicos, denominados nodos. NLB funciona como un controlador de dispositivo (driver), que es posible vincular y configurar sobre las tarjetas de red que se desee, utilizando un algoritmo distribuido para realizar el enrutamiento de las conexiones entrantes (es decir, el balanceo de carga de la red), permitiendo que cada nodo del cluster pueda realizar rpida e independientemente la decisin del balanceo de carga para cada peticin entrante. Resulta especialmente eficaz cuando los clientes realizan muchas peticiones, cada una muy pequea, como es el caso de las aplicaciones Web.

1.5.2 SERVIDOR DE BASE DE DATOS El cliente ya utiliza actualmente el motor Microsoft SQL Server 2005 como servidor de base de datos. Explcitamente el cliente solicita que se mantenga la plataforma Microsoft por poltica de desarrollo. Una solucin de alta disponibilidad enmascara los efectos de un error de hardware o de software y mantiene la disponibilidad de las aplicaciones a fin de minimizar el tiempo de inactividad que perciben los usuarios. Microsoft SQL Server 2005 ofrece varias opciones para crear una alta disponibilidad para un servidor o para una base de datos. Entre las alternativas que ofrece Microsoft SQL Server 2005 podemos citar: Log Shipping Reflejos de base de datos (Database Mirroring) Server Clustering

1.5.2.1 LOG SHIPPING [4] Log Shipping, o trasvase de registros permite enviar automticamente copias de seguridad del registro de transacciones desde una base de datos principal de una instancia del servidor principal a una o varias bases de datos secundarias en instancias independientes del1

Cluster, se denomina a un conjunto de computadores que pueden compartir hardware y que se comportan ante los clientes como su fueran una nica maquina.

13

servidor secundario. Las copias del registro de transacciones se aplican a cada una de las bases de datos secundarias de forma individual. Log Shipping consta de 3 operaciones: 1. Copia de seguridad del registro de transacciones en el servidor principal 2. Copia el archivo de registro de transacciones en el servidor secundario 3. Restaura la copia de seguridad de registros en el servidor secundario El registro se puede aplicar en varias instancias del servidor secundario o en varios servidores secundarios. En ese caso, las operaciones 2 y 3 se repiten para cada instancia de cada servidor secundario. Log Shipping no permite que el servidor secundario acte como servidor primario debido a que las bases de datos que se estn replicando se encuentran en modo NORECOVERY o en modo STANDBY. Esto evita que el servidor secundario sea utilizado para modificar datos en la base replicada mientras que el servidor principal se encuentre activo. La ventaja que tiene este sistema es la sencillez que presenta al momento de instalarlo y administrarlo. Las desventajas que tiene este sistema son en primer lugar, que no es una solucin de alta disponibilidad en tiempo real, est limitado por las programaciones de tiempo entre una copia del registro de transacciones y la siguiente. Adems requiere que ante un fallo, el cambio de rol de servidor secundario a servidor primario debe ser hecho manualmente, adems se debe re direccionar las aplicaciones al servidor que ha comenzado a realizar la funcin de servidor principal.

1.5.2.2 DATABASE MIRRORING [5] Database Mirroring o reflejo de base de datos es una solucin de software usada principalmente para aumentar la disponibilidad de una base de datos. La creacin del reflejo se implementa en cada una de las bases de datos a las cuales se quiere dar disponibilidad. La creacin de reflejos de base de datos mantiene dos copias de una base de datos en diferentes instancias de Microsoft SQL Server. Generalmente estas instancias se encuentran en equipos diferentes que pueden estar en diferentes ubicaciones. Una de las instancias funciona como servidor principal prestando servicio a los clientes que se conectan a ella, la otra instancia funciona como servidor en estado de espera activa, o servidor secundario, que es el servidor que mantiene el reflejo de la base de datos.

14

1.5 Base de datos reflejada

Los dos servidores, el principal y el secundario, se comunican para mantener una copia de la base de datos reflejada, y que adems se actualiza en cada modificacin que pueda sufrir la base de datos del servidor principal. El reflejo de la base de datos implica replicar cada operacin de insercin, actualizacin o eliminacin que se produce en la base de datos principal lo ms rpido posible. Para hacer esta operacin, se enva cada secuencia del registro de transacciones del servidor principal al servidor secundario, quien aplica los cambios a la base de datos reflejada del servidor secundario. Una sesin de creacin de reflejo de base de datos puede ejecutarse en modo sincrnico y en modo asincrnico. En el modo asincrnico, las transacciones se confirman sin esperar que el servidor reflejado escriba el registro en el disco, lo que maximiza el rendimiento. Por otro lado en el modo sincrnico, una transaccin se confirma en ambos servidores, pero a costa de aumentar la latencia de las transacciones. La conmutacin ante errores debe ser hecha de manera manual, aunque existe tambin la posibilidad de hacer una conmutacin automtica ante una falla en el servidor principal. Para implementar la conmutacin automtica de servidores, adems del servidor principal y el servidor secundario, el sistema de reflejo requiere un tercer servidor que acta como testigo (witness), el cual ante un fallo en el servidor principal permite activar la base de datos del servidor secundario.

15

1.6 Base de dato reflejada con servidor testigo Database Mirroring ofrece tres modos de funcionamiento: Modo de alta disponibilidad (sincrnico con testigo) Modo de alta proteccin (sincrnico sin testigo) Modo de alto rendimiento (asincrnico sin testigo) En el modo de alta disponibilidad las transacciones son aplicadas de forma sincrnica a la base de dato principal y a la base reflejada. Requiere de un servidor testigo instalado en un tercer servidor (que no sea el servidor principal ni el secundario), gracias al cual es posible la recuperacin automtica ante fallos, o conmutacin automtica de roles. En caso de fallo del servidor principal durante el envo de transacciones, el servidor secundario tiene que terminar las transacciones pendientes antes de poder cambiar su estado como servidor principal. Por supuesto tambin es posible realizar la recuperacin de manera manual ante fallos, o la conmutacin manual de roles. En caso de una cada o prdida del servidor secundario, la base de datos principal se mantiene activa. En el modo de alta proteccin las transacciones son aplicadas de forma sincrnica a las bases de datos principal y reflejada. Sin embargo, no existe un servidor testigo. En este modo de funcionamiento, no existe perdida de datos, pero la recuperacin ante fallos debe ser realizada en forma manual. En caso de cada o prdida del servidor secundario, la base de datos principal deja de estar activa al ocurrir la prdida del qurum. En el modo de alto rendimiento las transacciones son aplicadas de manera asincrnica a la base de datos reflejada, ofreciendo un mejor rendimiento que los anteriores modos de16

funcionamiento, pero con el riesgo de posibles prdidas de transacciones, y en consecuencia, potenciales perdidas de datos. Evidentemente, la recuperacin ante fallos debe ser realizada en forma manual. En caso de cada o prdida del servidor secundario, la base de datos principal se mantiene activa.

1.5.2.3 SERVER CLUSTERING [6] Un cluster proporciona alta disponibilidad a una instancia completa de SQL Server, a diferencia de Database Mirroring, que solo proporciona disponibilidad sobre bases de datos especficas. Un cluster de conmutacin por error es una combinacin de dos o ms servidores, denominados nodos. Los nodos comparten una unidad de almacenamiento que en la mayora de los casos es un servidor SAN1. Los nodos junto al servidor de almacenamiento conforman un servidor virtual el cual para los clientes se comporta como un nico servidor. La combinacin de un grupo de recursos, junto con su nombre de red, y una direccin IP, que constituye la aplicacin o servidor agrupado, se denomina cluster de conmutacin por error o instancia de cluster de conmutacin por error. Una instancia de cluster de conmutacin por error de SQL Server aparece en la red como un equipo individual, pero ofrece funciones para la conmutacin por error entre nodos si el nodo actual deja de estar disponible. Un cluster de conmutacin por error no implica proteccin ante errores de disco. Puede utilizar el cluster de conmutacin por error para reducir el tiempo de inactividad del sistema y garantizar una mayor disponibilidad de la aplicacin.

1

SAN (storage area network), es un servidor de almacenamiento compuesto de matrices de discos y libreras de soporte

17

1.7 Cluster de SQL

1.5.3 MONITOREO SALA DE SERVIDORES Todos los fabricantes importantes de equipos informticos y servidores (IBM, HP, Dell, Intel, Cisco, etc.), indican que nunca se debe utilizar un equipo informtico en un entorno donde la temperatura sea superior a 30C (85F). Esta regla es conocida en la industria como la lnea azul, una vez atravesada, comienzan los daos ms costosos para los equipos informticos, y con esto tambin aumenta el tiempo promedio de fallas en los equipos. Teniendo en cuenta el consumo de energa promedio en una sala de servidores (datacenter), al suspenderse el enfriamiento de la temperatura, esta aumentara por encima del estndar de la industria de 20C (68F), a ms de 30C (85F), en aproximadamente 8.6 minutos. Segn el Uptime Institute ( http://www.uptimeinstitute.org ), consorcio dedicado a proveer a sus miembros las mejores prcticas y benchmarks1 para mejorar la planificacin y gerenciamiento de datacenters, por cada 7C (18F), que aumente la temperatura por sobre los 20C (68F), los servidores pierden aproximadamente el 50% de su fiabilidad. Tambin indic que el consumo de energa elctrica utilizada por las salas de servidores tpicas, aumento en un 39% entre 1999 y 2005. La falla de la unidad principal o secundaria de aire acondicionado es la mayor amenaza en cualquier sala de servidores. Es la causa nmero 1 de sobrecalentamientos y tiempos de inactividad causados por el medio ambiente. Para mejorar la confiabilidad y aumentar la vida de los componentes electrnicos, el Uptime Institute sugiere que los equipos deben funcionar entre los rangos de temperatura de 20C (68F) y 25C (77F), y que el rango de humedad ambiental debe ser de entre 40% y 50%.

1.5.3.1 HARDWARE DE MONITOREO Existen actualmente mltiples equipos y servidores para el monitoreo del ambiente de las salas de servidores, pudiendo encontrarse equipos desde los ms pequeos para el monitoreo de gabinetes y racks hasta los ms complejos, compuestos de mltiples sensores para el monitoreo de grandes salas de servidores. Estos equipos de monitoreo, miden las condiciones ambientales como temperatura, humedad, presencia de lquido, movimiento, intrusin, vibraciones, fallas del suministro elctrico, etc. Cuando un sensor se sale de rango, de un umbral configurable, ya sea bajo y sobre lo establecido, el sistema puede notificar a travs de un correo electrnico, un mensaje de texto al telfono mvil, por medio de una baliza de alarma o inclusive por una sirena.

1

El Benchmakr es una tcnica utilizada para medir el rendimiento de un sistema o componente del mismo.

18

1.8 Monitor Ambiental para salas de servidores

1.5.3.2 UPS Existen actualmente equipos UPS1, que adems de proporcionar un respaldo de la energa, integran tambin sistemas de monitoreo ambiental. En general las UPS solo integran sistemas de monitoreo para la temperatura y la humedad, los cuales pueden ser de mucha utilidad en ambientes ms bien pequeos. Por otro lado, el costo de los equipos UPS que integran sistemas de monitoreo ambiental es mucho mayor al de un equipo de monitoreo, y tambin es mayor que el de un equipo UPS de similares capacidades pero que no cuenta con un sistema de monitoreo ambiental. En el caso del presente anlisis, y como se vio anteriormente, la compaa ya cuenta con un sistema de respaldo de energa, por lo que no es necesario la instalacin de otro sistema de respaldo solo con la intensin de instalar un sistema de monitoreo ambiental, por lo que se descarta la posibilidad de esta solucin para el monitoreo ambiental de la sala de servidores.

1

UPS, del ingls Uninterruptible Power Supply, llamados en espaol como SAI o Sistema de Alimentacin Ininterrumpida.

19

1.6 SOLUCION PROPUESTA Implementar un sistema de balanceo de carga para la aplicacin web utilizando la herramienta de Microsoft NLB. De esta manera las pginas web que conforman el sistema de la empresa se encontraran alojadas al menos en dos servidores de aplicacin. Implementar un sistema de reflejo de bases de dato en un segundo servidor utilizando la herramienta Database Mirroring de SQL Server 2005. Implementar un sistema de monitoreo ambiental, instalando un equipo que comprobar constantemente la temperatura y la humedad ambiental presente en la sala de servidores. Este sistema adems contar con un sistema de envo de alertas al personal de informtica en el caso que se produzca algn tipo de fallo.

1.6.1 BENEFICIOS ESPERADOS Aumentar el tiempo de disponibilidad del sistema mediante la implementacin de hardware y software que permita mejorar el rendimiento actual. En caso que se produzca algn tipo de fallo, se espera no afectar la disponibilidad del sistema. Tener un sistema de monitoreo del ambiente de la sala de servidores el cual sea capaz de enviar alertas en tiempo real, que permitan anticiparse a fallos en los equipos.

1.6.2 ALCANCES Y LIMITACIONES El presente proyecto considera: Instalacin y configuracin del software SQL Server2005 Standard. Instalacin y configuracin de servicios adicionales en servidores con sistema operativo Microsoft Windows Server 2008 R2 necesarios para la implementacin del proyecto. Configurar sistema de balanceo de carga en los servidores que tendrn instalada la aplicacin. Recomendacin al cliente sobre que hardware y/o software necesita adquirir para la implementacin del proyecto. Configuracin de equipos y hardware de red necesarios para la implementacin del proyecto. Evaluacin del estado fsico actual de la sala de servidores del cliente referente a la seguridad y al monitoreo del ambiente. Monitoreo por 6 meses del funcionamiento correcto del sistema implementado. El presente proyecto No considera

20

Instalacin de sistema operativo en servidores y/o equipos, esto debe ser provisto por el cliente. Compra y/o instalacin de hardware, la compra, instalacin y configuracin de hardware debe ser hecha por el cliente previamente a la implementacin del proyecto. Instalaciones y/o modificaciones en el sistema elctrico para la instalacin fsica de servidores o de cualquier otro equipo que sea necesario para la implementacin del proyecto. Instalacin y/o modificaciones en la instalacin fsica de la red de rea local de datos. Configurar los equipos y/o servidores en el dominio de red del cliente, esto debe ser hecho por el cliente previamente a la implementacin del proyecto.

21

CAPITULO II 2.1 METODOLOGAS 2.1.1 METODOLOGAS EN LA INGENIERA DE SOFTWARE En la construccin y desarrollo de proyectos es necesario aplicar mtodos y tcnicas para resolver problemas. La informtica aporta herramientas y procedimientos en los que se apoya la ingeniera de software con el fin de mejorar la calidad de los productos de software, aumentar la productividad en el trabajo de los ingenieros del software, facilitar el control del proceso de desarrollo de software y entregar a los desarrolladores las bases para crear software de calidad y en forma eficiente. La ingeniera de software, como trmino, comenz a utilizarse a fines de la dcada de los sesenta, para referirse al rea de conocimiento que se estaba desarrollando en torno a las problemticas que ofreca el software. En esa poca, el gran crecimiento en la demanda de sistemas computacionales, sumado adems a la inmadurez del sector informtico y a la falta de mtodos y procedimientos produjo lo que se lleg a conocer como la crisis del software. Durante esa poca muchos proyectos superaban con creces los presupuestos y las fechas estimadas. Desde 1985 hasta el presente, han ido apareciendo herramientas, metodologas y tecnologas que se presentaban como la solucin definitiva a los problemas de planificacin, costos y calidad en el desarrollo de software. La dificultad propia del desarrollo de software y su impacto en el negocio, han puesto de manifiesto las ventajas, y en muchos casos la necesidad, de aplicar una metodologa formal para llevar a cabo los proyectos de este tipo. El objetivo es convertir el desarrollo de software en un proceso formal, con resultados predecibles que permitan un producto de calidad, que satisfaga las necesidades y expectativas del cliente. Con la aplicacin de metodologas, queda atrs la forma de trabajo artesanal, que muchas veces requiere un gran esfuerzo para obtener un resultado, con los consecuentes desfases de fechas y altos costos, sumado al desgaste tanto personal como del equipo que compone el proyecto. [7] Debido a todo esto, el utilizar las metodologas implica mejoras en el proceso de desarrollo, mejoras en el producto y finalmente en la satisfaccin del cliente.

2.1.2 TIPOS DE METODOLOGAS La comparacin y clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, de informacin disponible y al alcance de cada una de ellas. Si se toma como criterio la filosofa de desarrollo, se puede diferencia dos tipos de metodologas, las tradicionales y las giles. Ambas metodologas aplican mtodos y tcnicas diferentes y dan nfasis en distintas reas, sin embargo, tienen la misma finalidad, el lograr que el resultado del proyecto sea exitoso y se mantenga dentro de los costos y los plazos planificados.22

2.1.3 METODOLOGAS TRADICIONALES Estas metodologas ponen un mayor nfasis en la planificacin y el control del proyecto, en una especificacin ms precisa de requisitos y en el modelado. Son tambin conocidas como Metodologas Pesadas. Estas han demostrado ser ideales para proyectos de gran tamao y con una gran complejidad y donde, por lo general, se exige un alto grado de rigidez en el proceso. Imponen una disciplina de trabajo sobre el proceso de desarrollo del proyecto, con el fin de conseguir un resultado ms eficiente. Para lograr esto se pone el mayor nfasis en la planificacin total del trabajo que se debe realizar y solo una vez que esta todo detallado se comienza con el ciclo de desarrollo del producto. Se centran especialmente en el control del proceso, mediante una acabada y rigurosa definicin de roles, actividades, herramientas a utilizar y la creacin de documentacin detallada. [8] Las metodologas tradicionales tienen como desventaja el no adaptarse adecuadamente a los cambios, esto hace que no sea el mtodo ms adecuado cuando se trabaja en un entorno donde los requisitos no pueden predecirse o puedan tener muchas variaciones. Entre todas las metodologas tradicionales existentes podemos mencionar: RUP (Rational Unifed Procces) MSF (Microsoft Solution Framework) Win-Win Spiral Model Iconix Watherfall

2.1.4 METODOLOGAS GILES El termino gil nace como consecuencia de una reunin que tuvo lugar en Utah EEUU en febrero de 2001, en donde participaron 17 expertos de la industria del software, entre los que se encontraban algunos de los creadores o impulsores de metodologas de software. El objetivo de esta reunin era buscar alternativas a los procesos de desarrollo de software tradicionales, los cuales se caracterizan por ser rgidos y dirigidos por la documentacin que se genera en las distintas actividades del proceso. Como consecuencia de esta reunin, se creo el Manifiesto gil, un documento que resume en doce principios la filosofa gil. [9] Adems, se creo una organizacin sin fines de lucro llamada Agile Alliance, la cual se dedica a promover los conceptos relacionados con el desarrollo gil de software, ayudando a que las organizaciones adopten dichos conceptos. [10] Los doce principios del manifiesto gil son:23

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardas del desarrollo. Los procesos giles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo mas corto posible. 4. Los responsables del negocio y los desarrolladores trabajan juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecucin del trabajo. 6. El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre sus miembros es la conversacin cara a cara. 7. El software funcionando es la medida principal de progreso. 8. Los procesos giles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida. 9. La atencin continua a la excelencia tcnica y al buen diseo mejora la agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseos emergen de equipos auto organizados. 12. A intervalos regulares el equipo reflexiona sobre como ser ms efectivo para a continuacin ajustar y perfeccionar su comportamiento en consecuencia. Aunque los creadores e impulsores de las distintas metodologas giles estn de acuerdo con el manifiesto gil, cada metodologa tiene caractersticas propias y refuerza aspectos ms especficos de los principios de la filosofa gil. Algunas de las Metodologas giles, las cuales en su mayora ya son usadas con gran xito en proyectos reales, son: XP (Extreme Programming) Scrum Crystal DSDM (Dynamic Systems Development Method) FDD (Feature Driven Development) ASD (Adaptive Software Development) XBreed Extreme Modeling

En la tabla 2.1, se nuestra una comparacin de la caractersticas mas relevantes entre las Metodologas Tradicionales y las giles.24

METODOLOGAS GILES METODOLOGAS TRADICIONALES Basadas en heursticas provenientes de Basada en normas provenientes de prcticas de produccin de cdigo estndares seguidos por el entorno de desarrollo Especialmente preparados para cambios Cierta resistencia al cambio durante el proyecto Metodologas impuestas internamente Metodologas impuestas externamente Proceso menos controlado, con pocos Proceso mucho ms controlado, con principios numerosas polticas y normas El cliente es parte del equipo de El cliente interacta con el equipo de desarrollo desarrollo mediante reuniones Grupos pequeos (