V e n t a j

Metodologas de desarrollo de software XP, ICONIX, RUP.

Yandry Ramirez Saritama
Universidad Nacional de Loja Loja, Ecuador yampier07@gmail.com

Abstract Este documento es una introduccin a las 3 metodologas mas utilizadas por los desarrolladores de software. Rescatando aspectos mas importantes de cada una de ellas, y as mismo explicando las respectivas diferencias que estas tienen.

I. INTRODUCCIN

El cliente en el sitio: Se le dar poder para determinar los requerimientos, definir la funcionalidad, sealar las prioridades y responder las preguntas de los programadores. Esta fuerte interaccin cara a cara con el programador disminuye el tiempo de comunicacin y la cantidad de documentacin, junto con los altos costes de su creacin y mantenimiento. Este representante del cliente estar con el equipo de trabajo durante toda la realizacin del proyecto. Programacin en parejas: uno de los principios ms radicales y en el que la mayora de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su cdigo en parejas, compartiendo una sola mquina. De acuerdo con los experimentos, este principio puede producir aplicaciones ms buenas, de manera consistente, a iguales o menores costes.

El desarrollo de software implica conocer sobre algunas metodologas que nos conllevan a este proceso de desarrollo de software, las principales metodologas de las que voy a explicar son las siguientes: XP, ICONIX, RUP. Cada una de ellas tienen sus propias caractersticas y tcnicas que se aplican en diferentes proyectos de desarrollo de software.

2) Proceso continuo en lugar de por lotes II. METODOLOGIA XP

software Integracin continua: Permite al equipo hacer un rpido progreso implementando las nuevas caractersticas del software. En lugar de crear versiones estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema varias veces al da. Esto reduce los problemas de integracin comunes en proyectos largos y estilo cascada. Refactorizacin: Permite a los equipos de programadores XP mejorar el diseo del sistema a travs de todo el proceso de desarrollo. Los programadores evalan continuamente el diseo y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimizacin del cdigo duplicado y/o ineficiente. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como mximo.

Metodologa para un gil desarrollo de

Programacin basada en los deseos del cliente. El equipo lo conforman los jefes de proyecto, desarrolladores y el cliente.

A. Principios bsicos. 1) Retroalimentacin a escala fina

El principio de pruebas: Se tiene que establecer un perodo de pruebas de aceptacin del programa (llamado tambin perodo de caja negra) donde se definirn las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Proceso de planificacin: En esta fase, el usuario tendr que escribir sus necesidades, definiendo las actividades que realizar el sistema. Se crear un documento llamado Historias del usuario. Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberacin, el cual define de forma especfica los tiempos de entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por regla general, cada una de las Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones peridicas durante esta fase de planificacin. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y sealar aquellos puntos a los que se les ha de dar ms importancia por su dificultad o por su punto crtico.

3) Entendimiento compartido
Diseo simple: Se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que cumpla los requerimientos. El Diseo Simple se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma sencilla. Metfora: Desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML. La metfora expresa la visin evolutiva del proyecto que define el

alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas). Propiedad colectiva del cdigo: Un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando en una pieza, menos errores aparecern. Estndar de codificacin: Define la propiedad del cdigo compartido as como las reglas para escribir y documentar el cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona.

Programacin organizada. Menor taza de errores. Satisfaccin del programador

2) Desventajas.
Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar. [2]

III. METODOLOGIA ICONIX

Es una metodologa que consiste en un lenguaje de modelamiento y un proceso de desarrollo de software prctico. Es un proceso dirigido, como RUP , relativamente pequeo y ligero, como XP. Proceso simplificado en comparacin con otros procesos ms tradicionales, que unifica un conjunto de mtodos de orientacin a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto.

4) Bienestar del programador.

La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad. [1]

A. Metodologa gil
Los desarrolladores: necesitamos obtener aplicaciones en menor tiempo, ms vistosas y de menor costo. Los usuarios: exigen calidad, sistemas fciles de mantener, extender y modificar. La realidad de la industria del software de gestin impone la adopcin de procesos giles de desarrollo para lograr competitividad. El objetivo principal de un mtodo gil es minimizar la documentacin de desarrollo emplendola fundamentalmente como vehculo de comprensin de problemas dentro del grupo de trabajo y de comunicacin con los usuarios.

A. Valores XP 1) Comunicacin.
Crear software requiere de sistemas comunicados.

2) Simplicidad.
Empezar con lo necesario y requerido y trabajar desde ah.

3) Retroalimentacin.
Del sistema, del cliente, y del equipo.

4) Valenta.
Programa para hoy y no para maana.

5) Respeto.
El equipo debe trabajar como uno, sin hacer decisiones repentinas.

B. Actividades 1) Codificacin.
La parte mas importante de XP.

B. Caractersticas
1) Iterativo e incremental. Suceden iteraciones entre el desarrollo de modelo del dominio y la identificacin de los casos de uso. El modelo esttico es incrementalmente refinado por los modelos dinmicos. 2) Trazabilidad. Cada paso est referenciado por algn requisito. Se debe considerar a la trazabilidad como la capacidad de seguir una relacin entre los diferentes artefactos producidos.

2) Pruebas.
Nunca se puede estar seguro de algo hasta haberlo probado.

3) Escuchar.
Escuchar los requisitos del cliente acerca del sistema a crear.

4) Diseo.
Crear una estructura del diseo para evitar problemas.

D. Ventajas y Desventajas 1) Ventajas.

3) Dinmica del UML.

Uso dinmico de UML en los diagramas de caso de uso, diagramas de secuencia y de colaboracin.

C. Tareas 1) Anlisis de requisitos.

Modelo de dominio Prototipacin rpida Modelo de casos de uso

2) Anlisis y diseo preliminar.

Descripcin de casos de uso Diagrama de robustez

3) Diseo.
Diagrama de secuencia Completar el modelo esttico

4) Implementacin.
Utilizar un diagrama de componentes Escribir / Generar cdigo Realizacin de pruebas. [3]

Durante la fase de inicio las iteraciones hacen ponen mayor nfasis en actividades modelado del negocio y de requisitos. Modelado del negocio. En esta fase el equipo se familiarizar ms al funcionamiento de la empresa, sobre conocer sus procesos. Entender la estructura y la dinmica de la organizacin para la cual el sistema va ser desarrollado. Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras. Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn de la organizacin objetivo. Requisitos. En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos. Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo que el sistema podra hacer. Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. Definir el mbito del sistema. Proveer una base para estimar costos y tiempo de desarrollo del sistema. Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

C. Fase de elaboracin. 1) Anlisis y Diseo.

En esta actividad se especifican los requerimientos y se describen sobre como se van a implementar en el sistemas. Transformar los requisitos al diseo del sistema.

IV. METODOLOGIA RUP

RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cmo, cundo y qu debe hacerse en el proyecto . Como 3 caractersticas esenciales est dirigido por los Casos de Uso, que orientan el proyecto a la importancia para el usuario y lo que este quiere, est centrado en la arquitectura que Relaciona la toma de decisiones que indican cmo tiene que ser construido el sistema y en qu orden, y es iterativo e incremental, donde divide el proyecto en mini proyectos donde los casos de uso y la arquitectura cumplen sus objetivos de manera ms depurada.

Desarrollar una arquitectura para el sistema. Adaptar el diseo para que sea consistente
implementacin.

con el entorno de

D. Fase de construccin. 1) Implementacin.

Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El resultado final es un sistema ejecutable. Planificar qu subsistemas deben ser implementados y en que orden deben ser integrados, formando el Plan de Integracin. Cada implementador decide en que orden implementa los elementos del subsistema. Si encuentra errores de diseo, los notifica. Se integra el sistema siguiendo el plan.

A. El ciclo de vida de RUP

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades.

1) Inicio.
Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto

2) Pruebas.
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo,sino que debe ir integrado en todo el ciclo de vida. Encontrar y documentar defectos en la calidad del software. Generalmente asesora sobre la calidad del software percibida. Provee la validacin de los supuestos realizados en el diseo y especificacin de requisitos por medio de demostraciones concretas. Verificar las funciones del producto de software segn lo diseado. Verificar que los requisitos tengan su apropiada implementacin.

2) Elaboracin.
Se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos.

3) Construccin.
Se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario.

4) Transicin.
Se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.

3) Despliegue.
Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen: Probar el producto en su entorno de ejecucin final. Empaquetar el software para su distribucin.

B. Descripcin de actividades. 1) Fase Inicio.

 Distribuir el software. Instalar el software. Proveer asistencia y ayuda a los usuarios. Formar a los usuarios y al cuerpo de ventas. Migrar el software existente o convertir bases de datos

Es una alternativa para la comunidad informtica dedicada al desarrollo de sistemas de gestin pequeos y medianos, que favorece la participacin de los usuarios finales y la documentacin de todo el proceso. RUP ufqwohruqwirhiqueufhuwe regiyerhbgiqkrea rengijkerbgeqr

E. Roles de RUP. 1) Analistas.

Analista de procesos de negocio. Diseador del negocio. Analista de sistema. Especificador de requisitos

4) Desarrolladores.
Arquitecto de software. Diseador Diseador de interfaz de usuario Diseador de cpsulas. Diseador de base de datos. Implementador. Integrador

RECONOCIMIENTOS
ufqwohruqwirhiqueufhuwe regiyerhbgiqkrea rengijkerbgeqr

5) Gestores.
Jefe de proyecto Jefe de control de cambios. Jefe de configuracin. Jefe de pruebas Jefe de despliegue Ingeniero de procesos Revisor de gestin del proyecto Gestor de pruebas

REFERENCIAS
[1] Internet: Metodologa XP, http://procesosdesoftware.wikispaces.com/METODOLOGIA+XP [2] Internet: Metodologa XP, http://www.slideshare.netCrisCobol/metodologia-xp-6697221 [3] Internet: Metodologa ICONIX, http://informatica-viconix.blogspot.-com/2011/08/normal-0-21-false-false-false-es-xnone.html [4] Internet: Metodologa RUP, http://es.scribd.com/doc/297224/RUP

5) Apoyo.
Documentador tcnico Administrador de sistema Especialista en herramientas Desarrollador de cursos Artista grfico

6) Especialista en pruebas.
Especialista en Pruebas (tester) Analista de pruebas Diseador de pruebas

7) Otros Roles.
Stakeholders Revisor Coordinacin de revisiones Revisor tcnico Cualquier rol. [4]

V. CONCLUSIONES
XP ufqwohruqwirhiqueufhuwe regiyerhbgiqkrea rengijkerbgeqr ICONIX Lo original de la metodologa es la definicin de un proceso gil para obtener la especificacin de requerimientos y modelar el comportamiento de sistemas, utilizando el lenguaje de modelamiento unificado (UML).