INTRODUCCIN

Desarrollar un software significa construirlo simplemente mediante su descripcin. Est es una muy buena razn para considerar la actividad de desarrollo de software como una ingeniera. En un nivel ms general, la relacin existente entre un software y su entorno es clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos en el mismo. Aquellas partes del mundo que afectarn al software y que sern afectadas por l ser el Dominio de Aplicacin. Es all donde los usuarios o clientes observarn si el desarrollo del software ha cumplido su propsito. Una de las mayores deficiencias en la prctica de construccin de software es la poca atencin que se presta a la discusin del problema. En general los desarrolladores se centran en la solucin dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solucin. Esta aproximacin orientada a la solucin puede funcionar en campos donde todos los problemas son bien conocidos, clasificados e investigados, donde la innovacin se ve en la deteccin de nuevas soluciones a viejos problemas. Pero el desarrollo de software no es un campo con tales caractersticas. La versatilidad de las computadoras y su rpida evolucin hace que exista un repertorio de problemas en constante cambio y cuya solucin software sea de enorme importancia.

CAPITULO 1
1. PROCESO DEL SOFTWARE los modelos de evaluacin y mejora de procesos de software permiten calcular la capacidad o madurez de todos los procesos que intervienen en el ciclo de vida del software, detectar los puntos fuertes y los dbiles de cada uno y proponer un conjunto de actividades o tareas orientadas de guiar la organizacin hacia una mejora gradual y continua de cada uno de estos procesos. Concluyendo con la idea anterior, los procesos del software sern muy importantes para la mejora de ste. De tal manera que su funcionamiento sea ptimo con respecto a versiones o modelos anteriores. 1.1 MODELO DE PROCESO DE SOFTWARE Un modelo de proceso de software especifica la solucin que ser aplicada para problemticas o incertidumbres que se presenten durante el desarrollo del sistema de software. un modelo de procesos del software es una descripcin simplificada de un proceso del software que presenta una visin de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniera del software. 1.1.1 ARQUITECTURA DE SOFTWARE una arquitectura de software define la estructura general de un sistema. Las arquitecturas varan de acuerdo con el tipo de sistema a desarrollarse.la seleccin de una arquitectura afecta aspectos como la extensibilidad del sistema (qu tan fcil es extenderlo en el futuro para incorporar ms funcionalidad o mayor capacidad). Por lo tanto, la seleccin de la arquitectura a utilizarse debe de ser de tal manera que se encargue de minimizar los efectos que pudiecen producir cambios en un futuro dentro del sistema. 1.1.2 ACTIVIDADES Segn Weitzenfeld (2005), en el proceso de software las actividades definen los pasos necesarios para lograr las metas y los objetivos; por ejemplo, especificar los requisitos del sistema. Las actividades deben: ser fciles de definir y seguir, simplificar la comprensin del sistema; y ofrecer flexibilidad, presin y extensibilidad. Es de suma importancia tener en cuenta el objetivo que realizar un sistema, de software en este caso. Por ello, las actividades dentro de un proceso de software se convierten en un requisito indispensable para un desarrollo ptimo de ste. 1.1.3 MTODOS Y METODOLOGAS Los mtodos sern quienes definan las pautas para modificaciones internas de las acciones, mientras que las metodologas sern quienes definen el acumulado o conjunto de mtodos. un mtodo es un procedimiento que define tareas o acciones a realizar, donde cada tarea incluye condiciones de entrada y de salida que se deben satisfacer antes de realizarse y

despus de completarse. Las diferentes metodologas varan en el alcance del apoyo que proporcionan el desarrollo de software. 1.1.3.1 METODOLOGAS ESTRUCTURADAS las metodologas tradicionales o metodologas estructuradas se enfocan principalmente en la descomposicin funcional de un sistema. El objetivo es lograr una definicin completa del sistema en trmino de funciones estableciendo los datos de entrada y de salida correspondientes a cada funcin que debe cumplir el sistema. En sntesis, las metodologas estructuradas abarcan un funcionamiento amplio dentro de un sistema, ya que tiene un enfoque global de funcionamiento respecto a los datos de entrada y salida.

1.1.3.2 METODOLOGAS ORIENTADAS A OBJETOS las metodologas orientadas a objetos se enfocan principalmente en el modelado de un sistema en trmino de los objetos (y clases de objetos) que va a manipular. A diferencia de las metodologas estructuradas, inicialmente se identifican los objetos del sistema, para luego especificar su comportamiento (funciones). En conclusin, las metodologas orientadas a objetos a diferencia de las metodologas estructuradas, sern ms especficas en sus procesos para determinados objetos ya que esta tcnica no seguir el mismo flujo de datos que la anterior. 1.1.4 ESTRATEGIAS Las estrategias afectan aspectos como la arquitectura del sistema, el orden en que se llevan a cabo las actividades del proceso y las metodologas a utilizarse. En sntesis, es importante definir una estrategia dentro del proceso de un software, ya que existen diversos modelos para su desarrollo. Las estrategias ayudaran a definir dicho modelo segn sea su funcionalidad y finalidad del proyecto.

1.1.5 HERRAMIENTAS las herramientas son aplicaciones que apoyan diversos aspectos en la administracin del proceso de software. Cuyo objetivo es asistir al desarrollador durante las diferentes actividades del ciclo de vida del proceso de software. Las herramientas sern indispensables dentro del proceso del software, asimismo, para la eleccin de herramientas se debe de tener en cuenta el apoyo a las metodologas en uso. 1.2 MODELOS CLSICOS los modelos de proceso dependen de las opiniones o creencias de las personas involucradas en un proyecto. Para que un proceso tenga xito es importante evaluar y administrar el riesgo y la entrega de etapas intermedias bien definidas aumenta la confianza que se tiene en el resultado final. Por ello se puede inferir que a partir de las creencias acerca del tipo de modelos clsicos se crearan paradigmas respecto a su rendimiento. Por ello ser importante conocer el modelo a elegir para que este se adecue al proyecto requerido.

1.2.1 MODELO CASCADA considera las actividades fundamentales del proceso de especificacin, desarrollo validacin y evolucin, presentndolas como faces separadas del proceso. (Ver Anexo 1) 1.2.2 MODELO ESPIRAL se basa en una estrategia para reducir el riesgo del proyecto en reas de incertidumbre. El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al siguiente ciclo. (Ver Anexo 2) 1.2.3 MODELO EVOLUTIVO este enfoque entrelaza las actividades de especificacin, desarrollo y validacin. (Ver Anexo 3) 1.2.4 MODELO INCREMENTAL consiste de un desarrollo inicial de la arquitectura completa del sistema, seguida de incrementos y versiones parciales de ste. (Ver Anexo 4) 1.3 MODELOS NUEVOS En esta seccin se describen algunos modelos de procesos nuevos que surgieron despus de los clsicos. 1.3.1 MODELO GANAR-GANAR se establecen las reglas para definir el proceso de desarrollo del proyecto, tomando en cuenta todas las partes implicadas. 1.3.2 MODELO UNIFICADO (UP) se basa principalmente en la especificacin de requerimientos de un sistema mediante casos de uso [] considerando las cuatro P del desarrollo de software: personas, proyecto, producto y proceso. (Ver Anexo 5) 1.4 PROCESO PERSONAL Y DE EQUIPO PARA EL DESARROLLO DE SOFTWARE En el caso del desarrollo de software de alta calidad, se espera que responda a las expectativas de los usuarios. Para ello es fundamental definir procesos tanto personales como para el trabajo en equipo. Entre los ms importantes tenemos: 1.4.1 PSP (Personal software process) consiste en especificar la secuencia de pasos requeridos por un programador para desarrollar o mantener software. 1.4.2 TSP (Team software process) proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad.

1.4.3 XP (Extrem programing) este modelo toma los principios y prcticas aceptadas, y las lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida del software mediante grupos de desarrollo pequeos. (Ver Anexo 6) En sntesis, los modelos para los procesos de software varan de acuerdo a los objetivos y finalidades que plantean cada uno. El modelo a elegir depender de la finalidad de su uso.

CAPITULO 2
2. MEJORES PRCTICAS PARA EL DESARROLLO DE SOFTWARE Las mejores prcticas para el desarrollo de un software determinado, depender de la finalidad de su posterior uso. La organizacin que requiera de un sistema de software tendr que acoplar sus necesidades hacia el modelo ms adecuado para optimizar su funcionamiento y rendimiento. Se considerar de igual manera las caractersticas del modelo del proceso de software, para que de esa manera se pueda tener una visin clara respecto a su calidad y de su posterior funcionamiento. Es decir, por lo anteriormente argumentado, no existe un modelo de proceso de software estndar que se adecue para cualquier tipo de requerimiento. Pero se puede denotar las ms populares con respecto a su uso en la actualidad. 2.1 EXTREM PROGRAMING (XP) Las siglas XP significan (extreme programing) que traducido al castellano significa (programacin extrema), es una metodologa que se utiliza para desarrollar un software de alta calidad de la manera ms rpida posible, cualidad a la cual se deriva el nombre de dicha metodologa. Caracterizada tambin por brindarle un mayor beneficio al cliente. se caracteriza por tener ciclos de desarrollo extremadamente breves, integracin constante, retroalimentacin continua por parte del cliente, pruebas automatizadas regulares y enfoque de equipo. En sntesis, XP se va a caracterizar principalmente por tener en cuenta al factor humano como componente clave en su desarrollo. XP tambin se caracteriza por tomar en cuenta todas las posibles desventajas en el desarrollo de software y genera prctias para vencerlas o disminuir sus consecuencias. 2.1.1 LAS VARIABLES DE XP Las variables que existen dentro de la metodologa XP tienen un valor muy importante durante su ciclo de vida, ya que la interaccin entre estas variables y el control de las mismas son indispensables para el xito del proyecto. XP es un modelo de desarrollo de software en la que hay cuatro variables que juegan un papel fundamental: costo, tiempo, calidad y alcance. El control de estas variables es llevado a cabo por los programadores, administradores y clientes. 2.1.2 PRINCIPIOS BSICOS DE XP Los principios bsicos que ofrecen medios mas conretos para aplicarlos son: retroalimentacin rpida, simplicidad, cambios incrementales, cambios sin alterar lo ya desarrollado y trabajo de calidad. 2.1.2.1 RETROALIMENTACIN RPIDA Se aplica una retroalimentacin en relacin al mismo sistema. Todo lo aprendido respecto con la experiencia del sistema se debe aplicar dicho sistema cuanto antes. 2.1.2.2 SIMPLICIDAD XP promueve soluciones simples que se adecuen hacia necesidades actuales, eso en vez de

dedicar empeo en tratar de buscar una solucin estndar. 2.1.2.3 CAMBIOS INCREMENTALES Consiste en hacer mnimos cambios, que en conjunto sirvan para dar solucin a un problema. 2.1.2.4 CAMBIOS SIN ALTERAR LO YA DESARROLLADO Cada cambio realizado servir para aumentar las funcionalidades que se encuentran resueltas, ms no para remplazarlas. 2.1.2.5 TRABAJO DE CALIDAD Sirve esencialmente para evitar el fracaso en el proyecto. Se basa en que todos los miembros del equipo comparten el mismo objetivo para un desarrollo ptimo. 2.1.3 LAS PRCTICAS DE XP Considerando los principios bsicos anteriormente presentados, se plantean las prcticas requeridas para usar una metodologa XP en el desarrollo de software de alta calidad. 2.1.3.1 PLANEACIN Se debe de considerar las prioridades del negocio como al igual que las estimaciones tcnicas. 2.1.3.2 ALCANZE PEQUEO XP plantea que se realicen planes para periodos cortos como pudieran ser uno o dos meses aproximadamente. 2.1.3.3 METFORA Permitir identificar los elementos ms relevantes del sistema y la relacin existente entre ellos. 2.1.3.4 DISEO SENCILLO El diseo hacia la solucin de problemas deber de incluir solamente los elementos que sean necesarios para resguardar los requerimientos actuales. 2.1.3.5 PRUEBAS XP lleva este concepto al extremo, por lo que sostiene que cualquier funcin de un programa que no sea provada no existe. 2.1.2.6 REESTRUCTURACIN Se buscar simplificar el programa despus de habrsele agregado nuevas funcionalidades. 2.1.3.7 PROGRAMACIN DE PARES La programacin se asigna hacia dos personas. uno se concentra en buscar la mejor manera de implementar el mtodo, mientras que el otro analiza el problema ms globalmente. 2.1.3.8 PROPIEDAD COLECTIVA Todos los integrantes del equipo son propietarios del sistema, por ello todos tienen la posibilidad de modificar la codificacin en indeterminado instante. 2.1.3.9 INTEGRACIN CONTINUA se debe ir integrando y probando el cdigo de manera continua. El cdigo integrado deber pasar todas las pruebas definidas. 2.1.3.10 CODIFICACIN ESTANDAR Se requiere establecer un estilo comn de codificacin. [] XP propone que el estndar sea lo ms sencillo posible.

En sntesis, la metodologa XP (programacin extrema) es actualmente una de las ms populares por su fcil accesibilidad de uso. Sus propiedades se adecuan ms hacia un modelo estndar. El factor humano que interviene en el desarrollo de esta metodologa es una pieza clave para la evolucin del proyecto. Considera conceptos bsicos de un sistema dentro de sus prcticas. Pues la constante evolucin de su sistema garantiza un mejoramiento seguro de l. 2.2 METODOLOGA RUP 2.2.1 INTRODUCCIN A LA METODOLOGA RUP Consideramos a la metodologa RUP como una de las ms importantes o grandes prcticas que hay en el mundo del software; esto debido a los ciclos iterativos, a su vez divididas en grandes fases o etapas, se pueden adaptar al contexto o cualquier necesidad de una empresa. Las caractersticas principales de esta metodologa son, bsicamente, la de ser un proceso cclico, iterativo e incremental; adems de estar dirigidos a los Casos de Uso y arquitectura del software requerido. La metodologa RUP, tambin consta de 4 grandes fases para lograr un ptimo desarrollo del software; entre las cuales se tiene a la fase de inicio, elaboracin, construccin y transicin. Una de las causas del porqu elegir la metodologa RUP, se inicia cuando una institucin o empresa piensa en grande; es ah donde se toma como modelo de referencia a esta metodologa. Teniendo como base la idea de que cada fase es una iteracin larga, constante y dinmica. Esto explica el largo tiempo de vida del software una vez adaptado a esta metodologa. Como gran consecuencia de un rato de espera se obtiene un ptimo resultado. 2.2.2 DEFINICIN DE METODOLOGA RUP el Proceso Unificado Racional (Rational Unified Process en ingls, conocido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. Est basada en una integracin de forma unificada, cohesiva y adaptable del desarrollo de sistemas de software. Por tal razn es que este sistema no est del todo definido; sino que, como ya se mencion, se adaptan al contexto y necesidad de cada organizacin. 2.2.3 CARACTERSTICAS FUNDAMENTALES Se destaca que el proceso de software en esta metodologa tiene 3 caractersticas fundamentales las cuales son: Casos de Uso, Arquitectura e Iteracin e Incremento. 2.2.3.1 CASOS DE USO los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que seria [sic] bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema

que proporciona al usuario un valor aadido. Los Casos de Uso representan los requisitos funcionales del sistema. Los Casos de Uso, entonces, se refiere a las necesidades que el software requiere como parte para su posterior desarrollo. El encargado de verificar estos requisitos es el usuario quien se dispone a pensar qu es lo fundamental para que el software pueda tener todo lo indispensable. Todo lo que tiene ver con la implementacin, prueba y gua del diseo del producto del software tambin es verificada por los Casos de Uso. No son slo los que inician el proceso de desarrollo sino que proporcionan una secuencia organizada, estableciendo as el diseo entre las fases que son producidas en las distintas realizaciones del proceso de desarrollo del software. En sntesis, se puede decir que implantar los Casos de Uso en esta metodologa RUP constituir en el proceso, un elemento conciliador o integrador y una gran gua del trabajo para la elaboracin del software. 2.2.3.2 ARQUITECTURA La metodologa RUP adems de utilizar los Casos de Uso para guiar el proceso, tambin da especial atencin al temprano establecimiento de una buena arquitectura para que no se vea muy impactada ante posteriores cambios durante la construccin y el mantenimiento del software. El proceso busca entender los aspectos estticos y dinmicos ms resaltantes en trminos de arquitectura de software. La arquitectura va a depender de las necesidades de los usuarios y se precisa a partir de los Casos de Uso. La arquitectura de un sistema es la organizacin o estructura de sus partes ms importantes, permite tener una visin usual entre todos los desarrolladores y usuarios; y una perspectiva notable del sistema completo, necesaria para controlar el desarrollo. Debe tomar en cuenta elementos de calidad del sistema, reutilizacin, rendimiento y capacidad de evolucin por lo que debe ser flexible durante todo el proceso. Existe una interaccin entre la arquitectura y los Casos de Uso, estos ltimos deben ajustarse en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso necesarios, actuales y posteriores. En pocas palabras, tanto la arquitectura como los Casos de Uso deben evolucionar en paralelo durante todo el proceso de desarrollo de software. 2.2.3.3 ITERATIVO E INCREMENTAL la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes ms pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteracin del cual se obtiene un incremento que produce un crecimiento en el producto. Esto quiere decirnos que, el proceso reconoce que es conveniente dividir grandes proyectos en otros ms pequeos o mini-proyectos. Cada mini-proyecto alcanza una iteracin que resulta en un incremento. Las iteraciones son planeadas en base a los Casos de Uso.

Una iteracin puede darse por medio de una cascada a menor escala. Se pasa por los flujos fundamentales: Requisitos, Anlisis, Diseo, Implementacin y Pruebas. Tambin existe una planificacin de la iteracin, un anlisis de la iteracin y algunas actividades especficas de la iteracin. Al finalizar se realiza una integracin de los resultados con lo obtenido de las iteraciones anteriores.

CONCLUSIONES

1. En conclusin con el primer captulo, es importante tener en cuenta el concepto claro de software y de sus objetivos como herramienta. 2. Los objetivos del software nos permitirn tener una visin clara respecto a su posterior funcionamiento para una determinada finalidad, por ello es importante tenerlos en cuenta. 3. Para desarrollar un producto de software se requiere de todo un proceso. El cual esta predefinido por una diversidad de modelos. Es elemental tener en cuenta los modelos que se adapten para un proyecto requerido, para obtener como producto de ello una funcionalidad ptima del producto. 4. Existen diversos modelos dentro del proceso del software, as mismo, existen diversas metodologas y tipos de modelos para desarrollar un software. Producto de ello cada metodologa tendr un modelo de proceso para su desarrollo, el cual se adecua respecto con las necesidades de un proyecto. 5. Las mejores prcticas para un desarrollo de software se encontraran ligadas hacia la finalidad del proyecto que requiera de dicho producto. 6. En sntesis, se puede derivar por lo anteriormente argumentado, que no existe un modelo estndar que se adecue ante la diversidad de finalidades que en la actualidad se exige. 7. La metodologa RUP, cuya caracterstica principal es la de ser iterativa e incremental consta de varias fases; cada fase es una iteracin comprendida. Todas las actividades realizadas en estas etapas tienen una complejidad enorme que al pasar del tiempo, el desarrollo del software tendr un final ptimo. 8. En conclusin, esta metodologa se adapta mejor para proyectos grandes, ya que para cada iteracin en la elaboracin de software depender de la economa que est a nuestro alcance. Es por ello que al final del producto se logran grandes resultados. De lo contrario, con ausencia de economa, el tiempo de vida del software no durar y terminar siendo un total fracaso. REFERENCIAS BIBLIOGRFICAS - BECK, Kent y ANDRES, Cynthia. Extreme Programming Explained: Embrace Change. 2a. ed. EE.UU: Paperback, 2004. 224 p. ISBN: 0321278658 - BOEHM, Barry y TURNER, Richard. Metodologa RUP. En su: Balancing agility and discipline: a guide for the perplexed. Boston: Pearson Education, 2004. pp 179-180. ISBN: 0321186125 - BORRERO, Luca. Tecnologas de la informacin en internet: gua de las mejores direcciones en la web. Colombia, norma: 2004. 19 p. ISBN: 9580471975 - CAMPDERRICH Falgueras, Benet. Ingeniera de software. Madrid: UOC, 2005. 260 p. ISBN: 8483189976

- CERRADA, Jos, COLLADO, Manuel, GMEZ, Sebastian y ESTVIARIS Lpez, Jos Flix. Fundamentos de programacin. Madrid: Centro de estudios Ramn Areces, 2004. 466p. ISBN: 8480045152 - CORTS Morales, Roberto. Introduccin al anlisis de sistemas y la ingeniera de software. 2006. 102 p. ISBN: 9977649618 - GMEZ, Andrs y ANIA Briseo, Ignacio de Jess. Introduccin a la computacin. Mxico: Cordinadores editoriales, 2008. 552 p. ISBN: 139789706867681 - MINGUET y Hernndez, Juan Francisco. La calidad del software y su medida. Madrid: Centro de estudios Ramn Cceres, 2004. 42 p. ISBN: 8480046112 - ROGER, Pressman. Ingeniera del software: un enfoque prctico 6a ed. Madrid: Concepcin Fernndez, 2004. 640 p. ISBN: 8448132149 - SOMERVILLE, Ian. Ingeniera del software 7a ed. Madrid: Rivera de Loira, 2005. 165 p. ISBN: 8478290745 - TUYA, Javier, RAMOS, Isabel y DOLADO Cosn Javier. Tcnicas cuantitativas para la gestin en la ingeniera del software. Madrid: Mara Martnez, 2007. 367 p. ISBN: 9788497452045 - WEITZENFELD, Alfredo. Ingeniera de software orientada a objetos con UML, Java e Internet. 1ra ed. Mxico, Publimex: 2005. 704 p. ISBN: 9706861904

ANEXOS

ANEXO 1: MODELO EN CASCADA

Leyenda: Diagrama de flujo en el modelo cascada. Fuente: Ingeniera de software. Ciclo de vida del software. [Fecha de consulta: 14 octubre de 2009]. Disponible en: http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3

ANEXO 2: MODELO EN ESPIRAL

Leyenda: Diagrama del ciclo de vida del modelo en espiral. Fuente: Modelo en espiral. Paradigmas del modelo espiral. [Fecha de consulta: 14 octubre de 2009]. Disponible en: http://148.202.148.5/cursos/cc321/fundamentos/unidad1/espiral.htm

ANEXO 3: MODELO EVOLUTIVO

Leyenda: Diagrama de flujo del ciclo de vida del modelo evolutivo. Fuente: Ingeniera de software. Ciclo de desarrollo. [Fecha de consulta: 14 octubre de 2009]. Disponible en: http://www.wikilearning.com/curso_gratis/ingenieria_del_software-ciclo_de_desarrollo/3616-3

ANEXO 4: MODELO INCREMENTAL

Leyenda: Diagrama de flujo del ciclo de vida del modelo incremental Fuente: Ingeniera de software. Modelo incremental. [Fecha de consulta: 14 octubre de 2009]. Disponible en: http://img2.pict.com/72/50/22/1303628/0/800/modincremental.png

ANEXO 5: MODELO UP (Unified Process)

Leyenda: Diagrama de flujo del ciclo de vida del modelo UP Fuente: Fabrica de software - Proceso.E&LB. 2006. <http://www.espilebarbier.com/fabrica.php?sub=1&sel=1>

ANEXO 6: MODELO XP (Extreme Programing)

Leyenda: Diagrama de flujo del ciclo de vida del modelo XP Fuente: Nota por una metodologa de sntesis. Ciclo de planificacin de procesos en programacin extrema (XP). [Fecha de consulta: 14 octubre de 2009]. Disponible en: http://vc-on.blogspot.com/2007_09_01_archive.html