IceScrum

UPC
Trabajo de Sistemas Operativos
Profesor: Paul Rivas Galloso Seccin: SW4A

Integrantes: Kenneth Perleche Quintanilla Christie Chang Rojas

2012-2

Sistemas Operativos

2012-2

LISTA DE GRAFICOS

Fig. 1 Pantalla de iceScrum Fig. 2 Pantalla de Centos5 Fig.3 Creacin de nuevo directorio Fig.4 Direccionamiento de la nueva ruta Fig. 5 Desempaque del JDK Fig.6 Establecimiento de JAVA_HOME a la ruta jdk1.7.0_09 Fig.7 Aadir bash_profile Fig. 8 Acceder a share Fig. 9 Comprobacin de MD5 Fig. 10 Desempaque del archivo Fig.11 Cambio de directorio Fig.12 Creacin del script Fig.13 Establecer permisos para realizar secuencia. Fig.14 Chkconfig para arrancar Tomcat Fig.15 Verificacin de chkconfig Fig. 16 Iniciar Tomcat Fig.17 Detener Tomcat Fig.18 Reiniciar Tomcat Fig.19 Verificamos que no existan errores Fig.20 Pgina de inicio de Tomcat Fig.21 Definicin del rol manager-gui Fig.22 Memoria de CATALINA.sh Fig.23 Modificacin a CATALINA.sh Fig.24 Creacin de grupo tomcat Fig.25 Creacin de usuario tomcat Fig. 26 Cambio de propiedades de archivos tomcat Fig. 27 Ajuste de servicios iniciar/detener Fig. 28 Ejecutar Tomcat en puerto 80 Fig. 29 VHOST con mod_proxy Fig. 30 VHOST con AJP conectado con mod_proxy Fig. 31 VHOST con reescritura 28

17 18 18 19 19 19 19 20 20 20 20 21 21 21 21 22 22 22 22 23 24 24 24 25 25 25 26 26 27 28 28

Desarrollo gil de Software - IceScrum

Pgina 3

Sistemas Operativos
INDICE 1.

2012-2

2. Bibliografia.30

1. Marco Terico
1.1 Visin General 1.1.1 Introduccin

ctualmente, con el avance de la tecnologa y con el propsito de acelerar y automatizar los procesos en el desarrollo de software, nos vemos en la necesidad de implantar metodologas para el desarrollo de software, las cuales nos proveen de una direccin a seguir para la correcta aplicacin de los dems elementos. En primer lugar, explicaremos el concepto de metodologa dentro del mbito de la ingeniera de software. Una metodologa de desarrollo es un marco de trabajo usado para estructurar, planificar y controlar un proceso de desarrollo de sistemas de software. Todo esto engloba un enfoque de un proceso de desarrollo de software y un conjunto de herramientas, modelos y tcnicas para desarrollar software de buena calidad. Existen diversas propuestas de metodologa para desarrollar software. Las metodologas tradicionales se centran en el control del Desarrollo gil de Software - IceScrum Pgina 4

Sistemas Operativos

2012-2 proceso, estableciendo rigurosamente las actividades, herramientas y notaciones al respecto, dado estas reglas estas metodologas se caracterizan por ser estrictas y guiadas por la documentacin que se genera en cada una de las actividades desarrolladas. Este enfoque no resulta ser el ms indicado para muchos de los proyectos donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. En contraparte, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico. Los mtodos giles permiten un desarrollo iterativo y adaptable que permite la integracin de nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el cliente como el desarrollador queden satisfechos porque el producto final tiene una calidad adecuada.

1.1.2 Definicin del Desarrollo de Metodologas giles

principios de los aos 90 surgi un movimiento reaccionario contra los mtodos de desarrollo de software establecidos. Esta revolucin tena fuertes motivos ya que los fracasos de los mtodos tradicionales de desarrollo lineal y en cascada eran cada vez ms evidentes. La propuesta de modelos de desarrollo iterativo, incremental y adaptativos iba totalmente en contra de la metodologa tradicional. Los revolucionarios rechazaban la posibilidad de que los modelos predictivos fueran capaces de dar la flexibilidad necesaria al proceso de desarrollo. Esta nueva metodologa est basada en una filosofa de desarrollo incremental (ciclos cortos de entregas de software), en equipo (usuarios y desarrolladores trabajan juntos), adaptativo y simple. En el lado opuesto se encuentran los modelos tradicionales que se basan en ir cerrando etapas en el desarrollo las cuales no pueden volverse a abrir, en los que el usuario no habla con los desarrolladores si no es a travs de un documento. Despus de algunos aos y a pesar de algunas crticas, exactamente Desarrollo gil de Software - IceScrum Pgina 5

Sistemas Operativos

2012-2 en febrero de 2001, tras una reunin realizada en Utah-EEUU, nace el trmino "gil" aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser inflexibles. Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida fue el Manifiesto gil, un documento que resume la filosofa gil.

1.1.3 El manifiesto gil

l Manifiesto gil comienza enumerando los principales valores del desarrollo gil. Segn el Manifiesto se valora:

1. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software, ya que sin personas con conocimiento tcnico y actitud adecuada no se lograrn alcanzar los resultados establecidos. 2. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental. 3. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la Desarrollo gil de Software - IceScrum Pgina 6

Sistemas Operativos que marque la marcha del proyecto y asegure su xito.

2012-2

4. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta. Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. Los principios son: 1. La principal prioridad es satisfacer al cliente a travs de la entrega temprana y continua de software de valor. 2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos giles se doblegan al cambio como ventaja competitiva para el cliente. 3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. 4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a travs del proyecto. 5. Construccin de proyectos en torno a individuos motivados, dndoles la oportunidad y el respaldo que necesitan y procurndoles confianza para que realicen la tarea. 6. La forma ms eficiente y efectiva de comunicar informacin de ida y vuelta dentro de un equipo de desarrollo es mediante la conversacin cara a cara. 7. El software que funciona es la principal medida del progreso. 8. Los procesos giles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. 9. La atencin continua a la excelencia tcnica enaltece la agilidad.

Desarrollo gil de Software - IceScrum

Pgina 7

Sistemas Operativos

2012-2 10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial. 11. Las mejores arquitecturas, requisitos y diseos emergen de equipos que se auto-organizan. 12. En intervalos regulares, el equipo reflexiona sobre la forma de ser ms efectivo y ajusta su conducta en consecuencia.

1.1.4 Caractersticas principales

e los principios en los que se basa el manifiesto gil, se extraen las actividades y formas de desarrollo que caracterizan a este tipo de metodologas.

Debido a que el objetivo principal es la creacin de un software que satisfaga al cliente, todo el trabajo que desempee el equipo de desarrollo estar destinado a crear, mejorar o implementar funcionalidad del software. Con relacin al punto anterior, el cliente debe ser implicado en el proceso de desarrollo. Para ello se promueve la creacin de prototipos, los cuales puedan ser evaluados por los clientes. No slo se tratar de encontrar errores, sino que se pueden sugerir mejoras o aadir funcionalidades. Para que la inclusin de la opinin del cliente sea posible durante el desarrollo, ste deber ser incremental e iterativo. Los incrementos renen la realizacin de un conjunto de tareas con la mnima planificacin necesaria. Las iteraciones consistirn en periodos cortos de tiempo (entre una y cuatro semanas) en los cuales se repetir el ciclo de desarrollo clsico: anlisis de requisitos, diseo, codificacin, pruebas y valoracin. Cada iteracin debe aadir algo de funcionalidad a la anterior, pero logrando que su producto final tenga los menores errores posibles. En cuanto al equipo de desarrollo, ste cuenta con autonoma para la toma de decisiones, lo cual influye positivamente en el clima de trabajo, ya que el equipo trabajar conjuntamente para vencer las adversidades. Se promueven las reuniones en las cuales se comenten y discutan las tareas realizadas, destacando tanto los aciertos como los fallos, con el fin de aprender de la experiencia. La frecuencia de estas reuniones puede llegar a ser diaria, de forma que se comente el trabajo del da anterior y se programe el de ese da. Adems, se puede incorporar a representantes del cliente e interesados como observadores. De esta forma se fomenta la comunicacin cara a cara, en lugar de la creacin de documentos cuyos destinatarios sean el propio equipo de desarrollo. 1.1.5 Ventajas Desarrollo gil de Software - IceScrum Pgina 8

Sistemas Operativos

2012-2

Las metodologas giles presentan diversas ventajas como:

1. Rpida respuesta a cambios de requisitos a lo largo del desarrollo. 2. Entrega continua y en plazos cortos de software funcional. 3. Trabajo conjunto entre el cliente y el equipo de desarrollo. 4. Minimiza los costos frente a cambios. 5. Importancia de la simplicidad, al eliminar el trabajo innecesario. 6. Atencin continua a la excelencia tcnica y al buen diseo. 7. Mejora continua de los procesos y el equipo de desarrollo. 8. Evita malentendidos de requerimientos entre el cliente y el equipo.

9. El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones innecesariamente generales y complejas que en realidad no son un requisito del cliente. 10. Cada componente del producto final ha sido probado y satisface los requerimientos.

1.1.6 Desventajas

omo en cualquiera otra metodologa, tambin hay desventajas y problemas que surgen a la hora de implementarlas:

1. Falta de documentacin del diseo. El cdigo no puede tomarse como una documentacin. En sistemas de gran tamao se necesita leer los cientos o miles de pginas del listado de cdigo fuente. 2. Problemas derivados de la comunicacin oral. Este tipo de comunicacin resulta difcil de preservar cuando pasa el tiempo y est sujeta a muchas ambigedades. 3. Falta de calidad. Probar el cdigo de forma constante no genera Desarrollo gil de Software - IceScrum Pgina 9

Sistemas Operativos productos de calidad, slo revela falta de anlisis y diseo.

2012-2

4. Fuerte dependencia de las personas. Como se evita en lo posible la documentacin y los diseos convencionales, los proyectos giles dependen crticamente de las personas. 5. Falta de procesos de revisin del cdigo. Con mtodos como el PSP o TSP se han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La programacin en parejas tiene resultados del 20 al 40%, que no es mucho frente al 10 y el 25% de un programador. 6. Falta de reusabilidad. La falta de documentacin hacen difcil que pueda reutilizarse el cdigo gil. 7. Sobre costos y retrasos derivados de la refactorizacin continua. Para un sistema de ciertas proporciones, los costos y retrasos derivados de la refactorizacin no pueden despreciarse. 8. Restricciones en cuanto a tamao de los proyectos abordables.

9. Rigidez. Algunos mtodos giles son muy rgidos: deben cumplirse muchas reglas de una forma estricta para garantizar el xito del proyecto. Por ejemplo XP exige en realidad mucho esfuerzo, concentracin y orden. 10. Cambios. Los modelos de datos son pesados y no pueden cambiarse as como as solo porque el cliente quiera incorporar ms funciones al sistema. 11. Problemas derivados del fracaso de los proyectos giles. Si un proyecto gil fracasa no hay documentacin o hay muy poca; lo mismo ocurre con el diseo. La comprensin del sistema se queda en las mentes de los desarrolladores. 1.1.7 Diferencias entre las Metodologas Tradicionales y las Metodologas giles

continuacin, mostraremos una tabla con las principales diferencias que existen entre las metodologas tradicionales y las metodologas giles. Estas diferencias afectan no slo al proceso en s, sino que tambin al contexto del equipo as como a su organizacin.

Desarrollo gil de Software - IceScrum

Pgina 10

Sistemas Operativos

2012-2

Aunque los creadores e impulsores de las metodologas giles ms populares coinciden con los principios enunciados anteriormente, cada metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms especficos. Scrum surge en 1986, de un artculo de la Harvard Business Review titulado The New New Product Development Game de Hirotaka Takeuchi e Ikujiro Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente innovadoras. A partir de ah Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995. Scrum es una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo. Reduce al mximo la burocracia y actividades no orientadas a producir software que funcione y produce resultados en periodos muy breves de tiempo. Como mtodo, Scrum enfatiza valores y prcticas de gestin, sin pronunciarse sobre requerimientos, prcticas de desarrollo, implementacin y dems cuestiones tcnicas. Ms bien delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo ms productivos posibles.

Desarrollo gil de Software - IceScrum

Pgina 11

Sistemas Operativos 1.2 IceScrum Software Libre 1.2.1 Introduccin

2012-2

crum es un proceso en donde se aplica el conjunto de habilidades para laborar en equipo y obtener como resultado un proyecto de calidad. Las habilidades se complementan una a otra y; asimismo, poseen su origen en la formacin de equipos de trabajos prominentemente productivos. En Scrum se prioriza el provecho que va a obtener el beneficiario del proyecto, por lo cual se realizan entregas parciales y organizados del producto finiquitado. Para proyectos que se necesitan resultados inmediatos se aplica Scrum; debido a que los requisitos varan o poseen poca definicin, donde privilegia la innovacin, la competitividad, la flexibilidad y la productividad.

1.2.2 Definicin

ceScrum es una aplicacin web que fue diseado para Scrum, manteniendo la idea del trabajo cooperativo. Esta herramienta ofrece todo lo que es Scrum, la administracin de funciones, la gestin de cartera de producto de con caractersticas avanzadas para enfatizar historias, ciclo de vida de Scrum, planificacin de lanzamiento, cartera de Sprint, gestin de los obstculos, produccin grfica, tablas de velocidad. Asimismo, ofrece otras prcticas giles como las historias de usuario, pruebas de aceptacin asociadas a las historias, las funciones de usuario y planificacin.

1.2.3 Estructura

I
Roles:

ceScrum es una herramienta de Scrum, por lo tanto, posee la misma estructura que esta ltima.

Desarrollo gil de Software - IceScrum

Pgina 12

Sistemas Operativos 1. El dueo del producto : Cliente 2. El Scrum Master : Persona con vocacin para ayudar 3. El equipo : Equipo de desarrollo

2012-2

Artefactos: 1. Visin del sistema 2. El Backlog del producto: Lista de requerimientos funcionales y no funcionales del software. Slo lo maneja el dueo del producto y lo va a modificar constantemente. 3. El Backlog del Sprint: Es la sntesis del Backlog del producto y se hace cada periodo iterativo. Es presentado por el dueo del producto al equipo de desarrollo.

Reuniones: 1. Planificacin 2. Reunin diaria: Son 15 minutos diarios donde el Scrum master con cada uno de los miembros del equipo y les pregunta bsicamente qu es lo que hicieron el da anterior, qu es lo que van a hacer actualmente y si encontraron algn impedimento y si lo encontraron el Scrum Master va a tratar de resolverlo. 3. Revisin: El equipo de desarrollo presenta al dueo del producto todo lo que se desarroll durante el sprint. 4. Retrospectiva: Se renen el Scrum Master, el dueo del producto y el equipo y analizan lo que se hizo antes para ver que se puede modificar con referencia a la forma de proceder de quienes participaron del proyecto.

1.2.4 Caractersticas Principales C ada proyecto cuenta con un Backlog Global. El Backlog por Sprint viene a ser Desarrollo gil de Software - IceScrum Pgina 13

Sistemas Operativos

2012-2

una lista de las historias de usuario asignadas a ese Sprint. Por tanto, cuenta con una pizarra visual (vista por defecto del proyecto) por Sprint. Se puede poner en modo de pantalla completa. Desde aqu se puede ver el Burn Down Chart y el Sprint Burn Up aunque no estn visibles por defecto. El Burn Down Chart se muestra desde el comienzo del Sprint hasta el da actual (aunque queden das para terminar) y se va refrescando. Funciona el Drag and Drop para pasar las tareas de un estado a otro. Parece que los estados no son modificables, siendo: Story, Waiting, Locked y Done. Tambin cuenta con un roadmap del producto que subdivide el proyecto en: Release (s): Versin del producto creado desde el roadmap. Se trata de un marco temporal (fechas), donde se establece el nmero de das que tienen cada Sprint. Tiene un campo llamado velocidad, que parece ser la capacidad en puntos de cada Sprint. No sabemos si posiblemente limita el nmero de puntos por Sprint en base a esto o simplemente es un indicativo. Sprint (s): Se crean desde el release. Asigna las fechas de manera automtica y consecutiva en funcin de configuracin la marcada en el release. Tiene la opcin tambin de generar todos los Sprints de forma automtica.

La unidad bsica son las historias de usuario, creadas desde el Backlog global de un proyecto. No parecen tener asignacin de prioridad. Estas historias de usuario tiene la siguiente tipologa: Historias de usuarios propiamente dichas Requerimiento tcnico Funcionalidad Defecto (bug)

Se estiman en unos puntos aunque desde proyecto se puede establecer la poltica de los mismos, pudiendo elegir entre: Nmero de Fibonacci Nmeros naturales

Estas historias de usuarios se asocian al Sprint desde un release. Tambin permite una auto-planificacin: auto asignar historias a los Sprints. No sabemos la manera en que lo hace, pero posiblemente sea en funcin de los puntos de cada historia y de la capacidad de cada Sprint. Desarrollo gil de Software - IceScrum Pgina 14

Sistemas Operativos

2012-2 Por otro lado, tambin emplea caractersticas. Estas vienen a ser requerimientos a los que se les asignan diferentes colores para su identificacin visual. Se les puede asignar un valor que no est claro si es valor de negocio, punto o prioridad (los valores son los mismos que los puntos de una historia de usuario). Estas caractersticas se pueden asociar a las historias de usuario existentes, de modo que estas historias de usuario adquieren su color.

1.2.5 Ventajas y Desventajas Algunas de las ventajas que presenta IceScrum son: Interfaz de usuario sensible Buenos grficos Buenos proyectos, comunicados, concepto de apoyo sprints Arrastrar y soltar para el tablero de tareas y estimaciones Comunicados/Sprints lnea de tiempo

Algunas de las desventajas que presenta la herramienta son: Problemas de usabilidad Manera contundente de hacer las cosas Trabajo slo para pequeos grupos, no compatible para mltiples proyectos

Desarrollo gil de Software - IceScrum

Pgina 15

Sistemas Operativos

2012-2

INSTALACIN Y CONFIGURACIN
1.3 Introduccin La herramienta web iceScrum es aquella que permitir ver una vista grfica del ciclo de vida de los productos, los indicadores ms importantes del proyecto, un seguimiento conjunto de las tareas visuales y la creacin de post- it virtuales ; lo cual permitir una planificacin grupal y automtica basndose en la capacidad del equipo. Vamos a utilizar como plataforma el sistema operativo Centos5 para desarrollar la aplicacin web. Las recomendaciones para poder instalar es que la memoria de la web tenga al menos 512 MB. Asimismo, se debe agregar los siguientes ajustes : JVM (JAVA_OPTS) -Duser.timezone=UTC . : -Xmx512M -XX:MaxPermSize=512M

Desarrollo gil de Software - IceScrum

Pgina 16

Sistemas Operativos

2012-2

Fig. 1 Pantalla de iceScrum

Fig. 2 Pantalla de Centos5

Desarrollo gil de Software - IceScrum

Pgina 17

Sistemas Operativos

2012-2

1.4 INSTALACIN DE REQUISITOS

1.4.1 Requerimientos

mnimos de iceScrum

Para desarrollar la aplicacin iceScrum, se necesita tener preinstalado el Java Development Kit (JDK) , Mozilla Firefox y Apache Tomcat 7. 1.4.2 Instalacin de Java Development Kit Primero descargar JDK en la siguiente direccin : http://www.oracle.com/technetwork/java/javase/downloads/index.ht ml Seleccionar la plataforma que vamos a instalar, en este caso el sistema operativo de Linuxx86 . Descargar jdk-7u9-linuxi586.tar.gz . Creamos una direccin
Fig.3 Creacin de nuevo directorio

Nos dirigimos a la direccin que hemos creado

Fig.4 Direccionamiento de la nueva ruta

Colocamos el paquete descargado (jdk-7u9-linux-i586.tar.gz ) a la carpeta java . Desempaquetamos el archivo

Fig. 5 Desempaque del JDK

Ahora se ha creado el directorio /usr/java/jdk1.7.0_09 Establecemos JAVA_HOME en la ruta de que se ha creado.

Desarrollo gil de Software - IceScrum

Pgina 18

Sistemas Operativos

2012-2

Fig.6Establecimiento de JAVA_HOME a la ruta jdk1.7.0_09

A continuacin se aade el bash_profile

Fig.7 Aadir bash_profile

1.4.3 Instalacin de Firefox Descarga Firefox : http://www.mozilla.org/es-ES/firefox/fx/ Abre un Terminal y ve a tu directorio de inicio: cd ~ Extrae el contenido del archivo descargado: tar xjf firefox*.tar.bz2 Cierra Firefox si est abierto. Para iniciar Firefox, ejecuta el script Firefox en la carpeta Firefox.

1.4.4 Instalacin de Tomcat 7 Descargamos el paquete de la siguiente direccin: http://tomcat.apache.org/download-70.cgi

Accedemos a la ruta share

Fig. 8 Acceder a share

Comprobamos MD5 para realizar la descarga de Tomcat

Fig. 9 Comprobacin de MD5

Desempaque del archivo con tar-xzf

Desarrollo gil de Software - IceScrum

Pgina 19

Sistemas Operativos

2012-2

Fig. 10 Desempaque del archivo

Se crear el directorio /usr/share/apache-tomcat-7.0.29 1.4.4.1 Configuracin de Tomcat como Service Se va a ejecutar Tomcat como un Service, y crear un inicio simple Start/Stop/Restart script. Cambie al directorio /etc/init.d y crear un script denominado Tomcat .

Fig.11 Cambio de directorio

Emplear el siguiente script

Desarrollo gil de Software - IceScrum

Pgina 20

Sistemas Operativos

2012-2

Fig.12 Creacin del script

CATALINA_HOME es la ruta inicial de Tomcat (/usr/share/apache-tomcat-7.0.29). Ahora estableceremos los permisos para la secuencia.

Fig.13 Establecer permisos para realizar secuencia.

Ahora emplearemos la utilidad chkconfig para que inicie Tomcat.

Fig.14 Chkconfig para arrancar Tomcat

Verificamos

Fig.15 Verificacin de chkconfig

Desarrollo gil de Software - IceScrum

Pgina 21

Sistemas Operativos

2012-2 Vamos a comprobar nuestro script. Arrancamos Tomcat

Fig. 16 Iniciar Tomcat

Detenemos Tomcat

Fig.17 Detener Tomcat

Reiniciamos Tomcat

Fig.18 Reiniciar Tomcat

Comprobamos que no existan errores; revisamos catalina.out ( /usr/share/apache-tomcat7.0.29/logs/catalina.out )

Fig.19 Verificamos que no existan errores

Desarrollo gil de Software - IceScrum

Pgina 22

Sistemas Operativos

2012-2

Ahora podemos acceder al administrador de Tomcat en : http://yourdomain.com:8080 o http://yourIPaddress:8080. Podemos acceder a la pgina de inicio de Tomcat.

Fig.20 Pgina de inicio de Tomcat

1.4.4.2 Configuracin de Tomcat como Manager Access

Tomcat 7 posee varios cambios, lo cual ofrece finer-grain. Asimismo, por seguridad ningn usuario ni contrasea se crean en el gestor de funciones de Tomcat. Siempre es mejor remover la aplicacin Manager para obtener un despliegue de produccin. Para definir roles, nombre de usuario (s) y contrasea (s), tenemos que configurar el archivo tomcat-users.xml ubicado en $ CATALINA_HOME / conf / tomcat-users.xml. En el caso de nuestra instalacin, $ CATALINA_HOME se encuentra en / usr/share/apache-tomcat-7.0.29. Por defecto, el Tomcat 7 tomcat-users.xml tendr los elementos entre el y sus etiquetas comentadas. Las siguientes funciones disponibles son: manager-gui manager-status manager-jmx manager-script admin-gu admin-script.

Desarrollo gil de Software - IceScrum

Pgina 23

Sistemas Operativos

2012-2

Definimos el rol manager-gui de la siguiente manera:

Fig.21 Definicin del rol manager-gui

1.4.4.3 Administracin de Memoria JAVA_OPTS

La obtencin de los valores de la memoria dinmica de almacenamiento para su instalacin depender de un nmero de factores. En sntensis, vamos a configurar nuestro tamao de la pila inital, Xms y nuestro tamao mximo de almacenamiento dinmico, Xmx, con el mismo valor de 128 Mb Simliarly, hay varios enfoques que puede tomar en cuanto a dnde y cmo establecer sus JAVA_OPTS

Abrimos el archivo Catalina.sh que se ubica en la ruta /usr/share/apache-tomcat-7.0.29/bin. Como estamos utilizando 128 mb de memoria , aadimos la siguiente lnea :

Fig.22 Memoria de CATALINA.sh

Solo aadimos en la segunda lnea, se tiene que mostrar as.

Fig.23 Modificacin a CATALINA.sh

Desarrollo gil de Software - IceScrum

Pgina 24

Sistemas Operativos

2012-2 1.4.4.4 Ejecutar Tomcat utilizando Privileged User (Usuario no root) En la configuracin anterior, se est ejecutando Tomcat como root. Por seguridad, se debe correr los servicios solo con los permisos necesarios. En algunos casos, cometen errores que no requieren. Siempre es bueno equivocarse para aprender. Para ejecutar Tomcat como usuario no root, hay que hacer lo siguiente: Creamos grupo tomcat

Fig.24 Creacin de grupo tomcat

Creamos un usuario tomcat y lo agregamos al grupo que hemos creado.

Fig.25 Creacin de usuario tomcat

Se crear una ruta principal para el usuario tomcat en home . Por defecto : /home/tomcat. Cambie las propiedades de los archivos tomcat para el usuario tomcat que hemos creado.
Fig. 26 Cambio de propiedades de archivos tomcat

Desarrollo gil de Software - IceScrum

Pgina 25

Sistemas Operativos

2012-2 Ajustamos iniciar/detener servicio de script que hemos creado.

Fig. 27 Ajuste de servicios iniciar/detener

1.4.4.5 Ejecutar Tomcat en Puerto 80 como usuario Lo siguiente se debe aplicar cuando Tomcat se encuentra en modo stand alone con los mnimos privilegios de usuario Tomcat que hemos creado en los pasos anteriores. Aadimos lo siguiente a las tablas IP, para ejecutar bajo los servicios del puerto 1024.

Fig. 28 Ejecutar Tomcat en puerto 80

Desarrollo gil de Software - IceScrum

Pgina 26

Sistemas Operativos 1.4.4.6 Ejecutar Tomcat detrs de Apache

2012-2

Como otra solucin de arranque de Tomcat en el puerto 80, si se posee Apache en frente Apache. Puede utilizar mod_proxy as como AJP conectar al map del dominio donde se encuentra la aplicacin Tomcat usando Apache. En la configuracin de Apache, asegrese de establecer KeepAlive en on. VHOST con mod_proxy

Fig. 29 VHOST con mod_proxy

Desarrollo gil de Software - IceScrum

Pgina 27

Sistemas Operativos VHOST con AJP conectado con mod_proxy

2012-2

Fig. 30 VHOST con AJP conectado con mod_proxy

VHOST con reescritura

Fig. 31 VHOST con reescritura

Desarrollo gil de Software - IceScrum

Pgina 28

Sistemas Operativos

2012-2

1.5 INSTALACIN DE ICESCRUM Descargue el WAR de la siguiente direccin : http://www.icescrum.org/en/download-en/ Copie el WAR en la ruta root <web-apps> En los archivos config.properties , cambie :
grails.serverURL = http://[url_to_icescrum]/[context_name] (http://localhost:8080/icescrum)

Para el servidor Tomcat, cambie el archivo server.xml para conectar con catalina. La configuracin es la siguiente :
<Connector port=8080 protocol=org.apache.coyote.http11.Http11NioProtocol connectionTimeout=2000 maxThreads=500 URIEncoding=UTF-8/>

En algunos casos, puede estar includo las bibliotecas suministradas en el WAR. En este caso, borre los siguientes archivos en el WAR :
el-ri.jar, el-api.jar, jsf-api.jar, jsf-impl.jar, myfaces-api.jar, myfaces-impl.jar

Ejecuta el server En el explorador web, dirjase al siguiente URL:

http://[host_adress]/[web-app] (http://localhost:8080/icescrum).

Finalmente, click en Registrar.

Desarrollo gil de Software - IceScrum

Pgina 29

Sistemas Operativos

2012-2

Bibliografa

http://es.scribd.com/doc/92070428/Gestion-de-proyectos-agil-con-herramientas-open-source http://es.scribd.com/doc/92070428/Gestion-de-proyectos-agil-con-herramientas-open-source http://santiagogomez5784ita.blogspot.com/2011/01/pasos-para-hacer-el-desarrollo-de-una.html http://metodosagiles.blogspot.com/ http://revista.info.unlp.edu.ar/tesinas/tesis88.pdf http://www.seccperu.org/files/Metodologias%20Agiles.pdf http://www.qualitrain.com.mx/Metodologias-Agiles-de-Desarrollo-de-Software-PrimeraParte.html http://backupjavcasta.files.wordpress.com/2009/09/centos5_actualizado.jpg http://www.icescrum.org/wp-content/gallery/screenshots/icescrum-5.png http://www.davidghedini.com/pg/entry/install_tomcat_7_on_centos http://www.icescrum.org/en/installing-on-a-server/

Desarrollo gil de Software - IceScrum

Pgina 30