Metodologias agiles xp vs iso 12207

| |2009 | | |UNIVERSIDAD NACIONAL DE INGENIERIA – FIIS | | | | | |Amancio Castro, Marcos | | |Castillo Bruno, Jesus | |[Analisis comparativo entre la NTP ISO-12207 y programacion extrema] | |El presente trabajo contiene una breve descripcion de las metodologias mencionadas y establece una serie de criterios para su | evaluacion. Es asi que presenta un analisis basado en ello. | Indice INTRODUCCION 4 1. CONCEPTOS PRELIMINARES 5 a. Metodos Agiles. 5 b. Otros Tipos de Metodologias (Para el desarrollo de software) 6 2. NORMA TECNICA PERUANA ISO – 12207 7 a. ?Que es la NTP ISO/IEC 12207? 7 b. PROCESOS PRINCIPALES DEL CICLO DE VIDA 9 1. Proceso de adquisicion 10 2. Proceso de suministro 10 3. Proceso de desarrollo 11 4. Proceso de operacion 12 5. Proceso de mantenimiento 12 c. PROCESOS DE APOYO DEL CICLO DE VIDA 13 1. Proceso de documentacion 13 2. Proceso de gestion de la configuracion 13 3.

Proceso de aseguramiento de la calidad 14 4. Proceso de verificacion 14 5. Proceso de validacion 15 6. Proceso de revision conjunta 15 7. Proceso de auditoria 15 8. Proceso de solucion de problemas 16 d. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA 16 1. Proceso de gestion 16 2. Proceso de infraestructura. 16 3. Proceso de mejora de proceso 17 4. Proceso de recursos

Lo sentimos, pero las muestras de ensayos completos están disponibles solo para usuarios registrados

Elija un plan de membresía
humanos 17 3. PROGRAMACION EXTREMA (XP) 17 a. Principales problemas en el desarrollo de software. 18 b. Objetivos de la programacion extrema. 18 c. Los Cuatro Valores 18 d. Roles en el XP 19 e. Procesos del XP 20 f. Ciclo de vida ideal de XP 21 . Las 12 practicas del XP 23 4. CRITERIOS DE COMPARACION 24 5. ANALISIS COMPARATIVO DE METODOS 25 6. CONCLUSIONES 30 7. BIBLIOGRAFIA 30 INTRODUCCION El software es una parte esencial de sistemas convencionales y de tecnologias de la informacion, tales como sistemas de transporte, militares, medicos y financieros. Hay una proliferacion de normas, procedimientos, metodos, herramienta y entornos para desarrollar y gestionar el software. Esta proliferacion ha creado dificultades en la gestion y en la ingenieria de software, especialmente en la integracion de productos y servicios.

La disciplina del software necesita evolucionar desde esta proliferacion, hacia un marco de referencia comun que pueda ser usado por los profesionales del software para «hablar el mismo lenguaje», a la hora de crear y gestionar el software. Esta Norma Tecnica Peruana proporciona ese marco de referencia comun. Este marco de referencia cubre el ciclo de vida del software desde la conceptualizacion de ideas hasta su retirada y consta de procesos para adquirir y suministrar productos y servicios software. Cubre ademas el control y la mejora de estos procesos.

Los procesos que hay en esta Norma Tecnica Peruana forman un conjunto completo. Una organizacion, dependiendo de sus necesidades, puede seleccionar un sub-conjunto apropiado para satisfacer dichas necesidades. Esta Norma Tecnica Peruana esta, asi pues, disenada para ser adaptada a una organizacion, proyecto o aplicacion concreta. Esta tambien disenada para ser usada cuando el software es una entidad independiente, esta integrado o es parte integral del sistema total. 1. CONCEPTOS PRELIMINARES a. Metodos Agiles. En una reunion celebrada en febrero de 2001 en Utah-EEUU, nace el termino “agil” aplicado al desarrollo de software.

En esta reunion participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologias de software. Su objetivo fue esbozar los valores y principios que deberian permitir a los equipos desarrollar software rapidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendia ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rigidos y dirigidos por la documentacion que se genera en cada una de las actividades desarrolladas.

Varias de las denominadas metodologias agiles ya estaban siendo utilizadas con exito en proyectos reales, pero les faltaba una mayor difusion y reconocimiento. [1] Tras esta reunion se creo The Agile Alliance3, una organizacion, sin animo de lucro, dedicada a promover los conceptos relacionados con el desarrollo agil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto Agil, un documento que resume la filosofia “agil”. i. El Manifiesto Agil: Principales valores del desarrollo agil. . Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas 2. Desarrollar software que funciona mas que conseguir una buena documentacion. 3. La colaboracion con el cliente mas que la negociacion de un contrato. 4. Responder a los cambios mas que seguir estrictamente un plan. ii. Estos valores inspiran los doce principios del manifiesto agil 1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. 2.

Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. 6.

El dialogo cara a cara es el metodo mas eficiente y efectivo para comunicar informacion dentro de un equipo de desarrollo. 7. El software que funciona es la medida principal de progreso. 8. Los procesos agiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberian ser capaces de mantener una paz constante. 9. La atencion continua a la calidad tecnica y al buen diseno mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y disenos surgen de los equipos organizados por si mismos. 12.

En intervalos regulares, el equipo reflexiona respecto a como llegar a ser mas efectivo, y segun esto ajusta su comportamiento. b. Otros Tipos de Metodologias (Para el desarrollo de software) Empezaremos enumerando las principales diferencias respecto a las metodologias tradicionales. El siguiente cuadro presenta no solo diferencias en el proceso sino tambien al contexto de quipo y organizacion que es mas favorable para cada una de estas filosofias de proceso de desarrollo de software. [pic] Ilustracion 1 Diferencias entre metodologias agiles y no agiles. [2] 2. NORMA TECNICA PERUANA ISO – 12207

Objetivo: Este estandar tiene como objetivo principal proporcionar una estructura comun para que los usuarios, compradores, proveedores, desarrolladores, personal de mantenimiento, operadores, gestores y tecnicos involucrados en el desarrollo de software usen un lenguaje comun. Este lenguaje comun se establece en forma de procesos bien definidos. a. ?Que es la NTP ISO/IEC 12207? NTP ISO/IEC 12207 es la traduccion de la norma internacional ISO/IEC 12207. Con su promulgacion se busca definir un marco y lenguaje comun para los procesos software. En la siguiente figura podemos apreciar las relaciones principales de los procesos de la ISO 12207. Ver Figura 1) [pic] Ilustracion 2 Principales de los procesos de la ISO 12207[3] ISO 12207 es un estandar organizada en tres categorias de procesos. Principales, de Apoyo y Organizativos. ISO 12207 posee una gran riqueza dado que permite alinear a toda la organizacion para apoyar en el logro de sus objetivos estrategicos. Dependiendo de cada organizacion los procesos de ISO 12207 se pueden organizar de acuerdo a la cadena de valor de Porter. (Ver Figura 2) [pic] Ilustracion 3 ISO 12207 se pueden organizar de acuerdo a la cadena de valor de Porter[4] i.

Campo de Aplicacion de la NTP ISO 12207 Esta NTP es aplicable a la adquisicion de sistemas, productos y servicios software, al suministro, desarrollo, operacion y mantenimiento de productos software y a la parte software del firmware, independientemente de que sea hecho interna o externamente a una organizacion. Incluye tambien aquellos aspectos de la definicion de sistema necesarios para proporcionar el contexto de los productos y servicios software. Esta NTP esta orientada para ser usada en situaciones en las que haya dos partes incluido el caso en que estas dos partes ertenezcan a la misma organizacion. La situacion puede ir desde un acuerdo informal, hasta un contrato con responsabilidades legales. Esta NTP puede ser usada por una sola parte como una autoimposicion. Este apartado no impide el uso de la NTP a los proveedores o desarrolladores de software empaquetado. Esta NTP esta escrita para adquirientes de sistemas y productos y servicios software y para proveedores, desarrolladores, operadores, responsables de mantenimiento, administradores, responsables de aseguramiento de calidad y usuarios de productos software. Haber implementado la NTP ISO 12207 en base a un modelo de gestion de tres niveles nos ha permitido priorizar y ejecutar los proyectos que estan relacionados a los objetivos del FMV. La alta direccion esta comprometida y sentir su apoyo y compromiso es importante para todos. [5] • Implementar la NTP 12207 siguiendo una metodologia de mejora de procesos nos ha permitido encontrar situaciones y tomar acciones de mejora. Por otra parte, sabiendo que se implementara siguiendo un modelo de madurez nos da la seguridad de hacerlo de manera natural y efectiva. Todos aprenderemos y maduraremos con los procesos que se vayan implementando. 6] ii. Limitaciones Esta NTP describe la arquitectura de los procesos del ciclo de vida del software, pero no especifica los detalles de como implementar o llevar a cabo las actividades y tareas incluidas en los procesos. Esta NTP no pretende establecer el nombre, el formato o el contenido explicito de la documentacion que se genere. Si bien esta NTP puede requerir la elaboracion de diversos documentos de tipo o clase similares (un ejemplo son los distintos tipos de planes), esto no implica que dichos documentos se desarrollen, agrupen o mantengan separados de alguna manera.

Estas decisiones se dejan para el usuario de esta NTP. Esta NTP no establece un modelo de ciclo de vida concreto para el desarrollo del software. En esta NTP las partes son las responsables de seleccionar un modelo de ciclo de vida para el proyecto software y de elaborar una correspondencia entre los procesos, actividades y tareas de esta NTP y los de dicho modelo. Las partes son tambien responsables de seleccionar y aplicar los metodos de desarrollo de software y de llevar a cabo las actividades y tareas adecuadas para el proyecto software.

Esta NTP no pretende entrar en conflicto con las politicas, normas o procedimientos actualmente en vigor en ninguna organizacion. Sin embargo, es necesario resolver cualquier conflicto que surja, documentando por escrito en forma de excepcion cualquier incumplimiento de esta NTP autorizado por las partes. b. PROCESOS PRINCIPALES DEL CICLO DE VIDA Se define los siguientes procesos principales del ciclo de vida: 1. Proceso de adquisicion. 2. Proceso de suministro. 3.

Proceso de desarrollo. 4. Proceso de operacion. 5. Proceso de mantenimiento. Las actividades y tareas en un proceso primario son responsabilidad de la organizacion que lo inicia y ejecuta. Esta organizacion asegura que ese proceso existe y es operativo. 1. Proceso de adquisicion El proceso de adquisicion contiene las actividades y las tareas del adquiriente. El proceso comienza con la identificacion de la necesidad de adquirir un sistema, un producto software o un servicio software.

El proceso continua con la preparacion y publicacion de una solicitud de propuestas, la seleccion de un proveedor y la gestion del proceso de adquisicion hasta la aceptacion del sistema, del producto software o del servicio software. La organizacion concreta que tiene la necesidad puede ser llamada el propietario. El propietario puede contratar todas o parte de las actividades de la adquisicion a un tercero que ejecutara por su parte estas actividades, de acuerdo con el proceso de adquisicion. En este apartado el adquiriente puede ser tanto el propietario como el tercero.

El adquiriente gestiona el proceso de adquisicion al nivel del proyecto siguiendo el proceso de gestion, que se emplea en este proceso; establece una infraestructura basada en el proceso que se sigue en el proceso de infraestructura; adapta el proceso al proyecto siguiendo el proceso de adaptacion (Anexo A); y gestiona el proceso al nivel de organizacion siguiendo el proceso de la mejora de proceso y el proceso de recursos humanos. Lista de actividades: Este proceso consiste en las siguientes actividades: a) Inicio. ) Preparacion de la solicitud de propuestas. c) Preparacion y actualizacion del contrato. d) Seguimiento del proveedor. e) Aceptacion y finalizacion. 2. Proceso de suministro El proceso de suministro contiene las actividades y tareas del proveedor. El proceso se puede iniciar ya sea por la decision de preparar una oferta para contestar a una solicitud de propuestas de un adquiriente, o por la firma e inicio de un contrato con el adquiriente para proporcionarle un sistema, producto software o servicio software.

El proceso continua con la determinacion de los procedimientos y recursos necesarios para gestionar ty asegurar el proyecto, incluyendo la preparacion y ejecucion de los planes del proyecto hasta la entrega al adquiriente del sistema, producto o servicio software. El proveedor gestiona el proceso de suministro a nivel de proyecto siguiendo el proceso de gestion, que se emplea en este proceso; establece una infraestructura basada en el proceso que se sigue en el proceso de infraestructura; dapta el proceso al proyecto siguiendo el proceso de adaptacion; y gestiona el proceso a nivel de organizacion siguiendo el proceso de mejora de proceso y el proceso de recursos humanos. Lista de actividades: Este proceso consta de las siguientes actividades: a) Inicio. b) Preparacion de la respuesta. c) Contrato. d) Planificacion. e) Ejecucion y control. f) Revision y evaluacion. g) Entrega y finalizacion. 3. Proceso de desarrollo

El proceso de desarrollo contiene las actividades y tareas del desarrollador. El proceso contiene las actividades para el analisis de los requerimientos, diseno, codificacion, integracion, pruebas e instalacion y aceptacion relacionadas con los productos software. Puede contener actividades a nivel de sistema si se estipula en el contrato. El desarrollador lleva a cabo o soporta las actividades de este proceso de acuerdo con el contrato.

El desarrollador gestiona el proceso de desarrollo al nivel de proyecto siguiendo el proceso de gestion, que se emplea en este proceso; establece una infraestructura basado en el proceso que se sigue en el proceso de infraestructura, adapta el proceso al proyecto siguiendo el proceso de adaptacion (Anexo A); y gestiona el proceso a nivel de organizacion siguiendo el proceso de mejora de proceso y el proceso de recursos humanos.

Cuando el desarrollador es el proveedor del producto software desarrollado, el desarrollador lleva a cabo el proceso de suministro. Lista de actividades: Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Analisis de los requerimientos del sistema. c) Diseno de la arquitectura del sistema. d) Analisis de los requerimientos software. e) Diseno de la arquitectura del software. f) Diseno detallado del software. g) Codificacion y pruebas del software. h) Integracion del software. ) Pruebas de calificacion del software. j) Integracion del sistema. k) Pruebas de calificacion del sistema. l) Instalacion del software. m) Apoyo a la aceptacion del software. 4. Proceso de operacion El proceso de operacion contiene las actividades y tareas del operador. El proceso cubre la operacion del producto software y el apoyo a la operacion de los usuarios. Ya que la operacion del producto software esta integrada a la operacion del sistema, las actividades y tareas de este proceso hacen referencia al sistema.

El operador gestiona el proceso de operacion a nivel de proyecto usando el proceso de gestion, que se emplea en este proceso; establece una infraestructura basada en el proceso que se sigue en el proceso de infraestructura; adapta el proceso al proyecto siguiendo el proceso de adaptacion (Anexo A); y gestiona el proceso al nivel de organizacion siguiendo el proceso de mejora de proceso y el proceso de recursos humanos. Cuando el operador es el proveedor del servicio de operacion, el operador lleva a cabo proceso de suministro.

Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Pruebas de operacion. c) Operacion del sistema. d) Soporte al usuario. 5. Proceso de mantenimiento El proceso de mantenimiento contiene las actividades y tareas del responsable de mantenimiento. Este proceso se inicia cuando el producto software sufre modificaciones en el codigo y la documentacion asociada, debido a un problema o a la necesidad de mejora o adaptacion.

El objetivo es modificar el producto software existente preservando su integridad. Este proceso incluye la migracion y retirada del producto software. El proceso termina con la retirada del producto software. Las actividades proporcionadas por esta area son especificas del proceso de mantenimiento; sin embargo, el proceso puede utilizar otros procesos de esta NTP. Si se usa el proceso de desarrollo, el termino desarrollador se debera interpretar en el como el responsable de mantenimiento.

El responsable de mantenimiento gestiona el proceso de mantenimiento a nivel de proyecto siguiendo el proceso de gestion, que se emplea en este proceso; establece una infraestructura basada en el proceso que se sigue en el proceso de infraestructura: adapta el proceso para el proyecto siguiendo el proceso de adaptacion (Anexo A); y gestiona el proceso a nivel de organizacion siguiendo el proceso de mejora de proceso y el proceso de recursos humanos. Cuando el responsable de mantenimiento es el proveedor del servicio de mantenimiento, el responsable de mantenimiento lleva a cabo el proceso de suministro. Lista de actividades.

Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Analisis de problemas y modificaciones. c) Implementacion de las modificaciones. d) Revision/aceptacion del mantenimiento. e) Migracion. f) Retirada del software. c. PROCESOS DE APOYO DEL CICLO DE VIDA Se define los siguientes procesos de apoyo del ciclo de vida: a) Proceso de documentacion. b) Proceso de gestion de la configuracion. c) Proceso de aseguramiento de la calidad. d) Proceso de verificacion. e) Proceso de validacion. f) Proceso de revision conjunta. g) Proceso de auditoria. h) Proceso de solucion de problemas.

Las actividades y tareas en un proceso de apoyo son responsabilidad de la organizacion que lleva a cabo dicho proceso. Esta organizacion se asegura que el proceso existe y esta operativo. La organizacion que emplea y lleva a cabo un proceso de apoyo lo gestiona a nivel de proyecto siguiendo el proceso de gestion; establece una infraestructura basada en el proceso que se sigue en el proceso de infraestructura; adapta el proceso al proyecto siguiendo el proceso de adaptacion (Anexo A); y gestiona el proceso a nivel de organizacion siguiendo el proceso de mejora de proceso y el proceso de recursos humanos.

Se pueden emplear revisiones conjuntas, auditorias, verificacion y validacion como tecnicas de aseguramiento de la calidad. 1. Proceso de documentacion El proceso de documentacion es un proceso para registrar la documentacion producida por un proceso o actividad del ciclo de vida. El proceso contiene el conjunto de actividades para planificar, disenar, desarrollar, producir, editar, distribuir y mantener aquellos documentos que necesitan todos los involucrados tales como gerentes, ingenieros y usuarios del sistema o producto software. Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. ) Diseno y desarrollo. c) Produccion. d) Mantenimiento. 2. Proceso de gestion de la configuracion El proceso de gestion de la configuracion es el proceso de aplicar procedimientos tecnicos y administrativos a lo largo del ciclo de vida del software para: identificar, definir y establecer la linea base de los elementos software en un sistema; controlar modificaciones y releases de los elementos; registrar e informar del estado de los elementos y peticiones de modificacion; asegurar la completitud, consistencia y correccion de los elementos; y controlar el almacenamiento, manipulacion y entrega de los elementos.

Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Identificacion de la configuracion. c) Control de la configuracion. d) Determinacion del estado de la configuracion. e) Evaluacion de la configuracion. f) Gestion de releases y entrega. 3. Proceso de aseguramiento de la calidad El proceso de aseguramiento de la calidad es un proceso para proporcionar la seguridad apropiada de que los productos y procesos software del ciclo de vida del proyecto son conformes con sus requerimientos especificados y se adhieren a los planes establecidos.

Para ser imparcial, el aseguramiento de la calidad necesita libertad organizativa y autoridad respecto a las personas directamente responsables el desarrollo del producto software, o que ejecutan el proceso del proyecto. El aseguramiento de la calidad puede ser interno o externo, dependiendo de si la evidencia de la calidad del producto o proceso se le demuestra a los gerentes del proveedor o del adquiriente. El aseguramiento de la calidad puede hacer uso del resultado de otros procesos de apoyo, tales como verificacion, validacion, revision conjunta, auditoria y solucion de problemas. Lista de actividades.

Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Aseguramiento del producto. c) Aseguramiento del proceso. d) Aseguramiento del sistema de calidad. 4. Proceso de verificacion El proceso de verificacion es un proceso para determinar si los productos software de una actividad cumplen con los requerimientos o condiciones que tienen impuestas por las actividades precedentes. Por motivos de efectividad en costo y rendimiento, se deberia integrar, lo antes posible, la verificacion, en los procesos (tales como los de suministro, desarrollo, operacion o mantenimiento) que la emplean.

Estos procesos pueden incluir analisis, revision y prueba. Este proceso se puede ejecutar con diversos grados de independencia. El grado de independencia puede fluctuar desde la misma persona o diferente persona dentro de la misma organizacion, hasta una persona en distinta organizacion con un grado de separacion variable. En el caso en que el proceso se ejecute por una organizacion independiente del proveedor, desarrollador, operador o responsable de mantenimiento, se llama proceso de verificacion independiente. Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. ) Verificacion. 5. Proceso de validacion El proceso de validacion es un proceso para determinar si los requerimientos y el sistema o producto software, tal como se ha construido, cumplen con su uso especifico previsto. La validacion se puede llevar a cabo en etapas tempranas. Este proceso se puede llevar a cabo como parte del apoyo a la aceptacion del producto. Este proceso se puede ejecutar con diversos grados de independencia. El grado de independencia puede variar desde la misma persona o diferente persona dentro de la misma organizacion, hasta una persona en distinta organizacion con un grado de separacion variable.

En el caso en que el proceso se ejecute por una organizacion independiente del proveedor, desarrollador, operador o responsable de mantenimiento, se llama proceso de validacion independiente. Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Validacion. 6. Proceso de revision conjunta El proceso de revision conjunta es un proceso para evaluar el estado y los productos de una actividad de un proyecto, segun sea adecuado. Las revisiones conjuntas estan a nivel tanto de gestion del proyecto como tecnico y se mantienen a lo largo de la vida del contrato.

Este proceso puede ser empleada por cualesquiera de las dos partes, donde una de ellas (la revisora) revisa a la otra parte (la revisada). Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Revisiones de la gestion del proyecto. c) Revisiones tecnicas. 7. Proceso de auditoria El proceso de auditoria es un proceso para determinar el cumplimiento con los requerimientos, planes y contrato, segun aplique. Este proceso puede ser empleado por cualquiera de las dos partes, donde una de ellas (la auditora) audita los productos software o actividades de la otra parte (la auditada).

Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Auditoria. 8. Proceso de solucion de problemas El proceso de solucion de problemas es un proceso para analizar y resolver problemas (incluidas las no conformidades), cualquiera que sea su naturaleza u origen, que se descubran durante la ejecucion de los procesos de desarrollo (5. 3), operacion (5. 4), mantenimiento (5. 5) u otros. El objetivo es el proporcionar un mecanismo que responsable, documentariamente y a tiempo asegure que todos los problemas descubiertos se analizan y resuelven y se reconozcan las tendencias.

Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Solucion de problemas. d. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA Se define los siguientes procesos organizativos del ciclo de vida: 1. Proceso de gestion. 2. Proceso de infraestructura. 3. Proceso de mejora. 4. Proceso de recursos humanos. Las actividades y tareas en un proceso organizativo son responsabilidad de la organizacion que usa dicho proceso. Esta organizacion se asegura de que el proceso exista y este operativo. 1. Proceso de gestion

El proceso de gestion contiene las actividades genericas y tareas que pueden ser empleadas por cualquier parte que tenga que gestionar sus respectivos procesos. El gerente es responsable de la gestion del producto, gestion del proyecto y gestion de las tareas de los procesos aplicables, tales como el de adquisicion, suministro, desarrollo, operacion, mantenimiento o soporte. Lista de actividades. Este proceso consta de las siguientes actividades: a) Inicio y definicion del alcance. b) Planificacion. c) Ejecucion y control. d) Revision y evaluacion. ) Finalizacion. 2. Proceso de infraestructura. El Proceso de Infraestructura es un proceso para establecer y mantener la infraestructura que necesita cualquier otro proceso. La infraestructura puede incluir hardware, software, herramientas, tecnicas, normas e instalaciones para el desarrollo, operacion o mantenimiento. Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Establecimiento de la infraestructura. c) Mantenimiento de la infraestructura. 3. Proceso de mejora de proceso

El proceso de mejora de proceso es un proceso para establecer, evaluar, medir, controlar y mejorar un proceso del ciclo de vida del software. Lista de actividades. Este proceso consta de las siguientes actividades: a) Establecimiento del proceso. b) Evaluacion del proceso. c) Mejora del proceso. 4. Proceso de recursos humanos El proceso de recursos humanos es un proceso para proporcionar y mantener personal capacitado. La adquisicion, suministro, desarrollo, operacion o mantenimiento de los productos software depende en gran medida de personal entendido y competente.

Por ejemplo el personal de desarrollo debera tener formacion basica en ingenieria y gestion del software. Es asi pues imprescindible que la formacion del personal este planificada e implementada de manera temprana, para que este disponible personal capacitado en el momento en que el producto software se adquiera, suministra, desarrolla, opera o mantiene. Lista de actividades. Este proceso consta de las siguientes actividades: a) Implementacion del proceso. b) Desarrollo del material de formacion. c) Implementacion del plan de formacion. 3. PROGRAMACION EXTREMA (XP)

XP (eXtreme Programing) nace como nueva disciplina de desarrollo de software hace aproximadamente unos doce anos, y ha causado un gran revuelo entre el colectivo de programadores del mundo. Kent Beck, su autor, es un programador que ha trabajado en multiples empresas y que actualmente lo hace como programador en la conocida empresa automovilistica DaimlerChrysler. Con sus teorias ha conseguido el respaldo de gran parte de la industria del software y el rechazo de otra parte. [7] La programacion extrema se basa en la simplicidad, la comunicacion y el reciclado continuo de codigo, para algunos no es mas que aplicar una pura logica. . Principales problemas en el desarrollo de software. • Retrasos en la planificacion: llegada la fecha de entregar el software este no esta disponible. • Sistemas deteriorados: el software se ha creado pero despues de un par de ano el coste de su mantenimiento es tan complicado que definitivamente se abandona su produccion. • Tasa de defectos: el software se pone en produccion pero los defectos son tantos que nadie lo usa. • Requisitos mal comprendidos: el software no resuelve los requisitos planificados inicialmente. • Cambios de negocio: el problema que resolvia nuestro software ha cambiado y nuestro software no se ha adaptado. Falsa riqueza: el software hace muchas cosas tecnicamente muy interesantes y divertidas, pero no resuelven el problema de nuestro cliente, ni hace que este gane mas dinero. • Cambios de personal: despues de unos anos de trabajo los programadores comienzan a odiar el proyecto y lo abandonan. 1 Objetivos de la programacion extrema. Los objetivos de XP son muy simples: la satisfaccion del cliente. Esta metodologia trata de dar al cliente el software que el necesita y cuando lo necesita. Por tanto, debemos responder muy rapido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programacion.

El segundo objetivo es potenciar al maximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estan involucrados en el desarrollo del software. 2 Los Cuatro Valores Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iniciales. Estos cuatro valores son: o Comunicacion o Sencillez o Retroalimentacion o Valentia Comunicacion. Cuantas veces hemos tenido problema en nuestro equipo de desarrollo por falta de comunicacion, por no comentar un cambio critico en el diseno, por no preguntar lo que pensamos al cliente.

La mala comunicacion no surge por casualidad y hay circunstancias que conducen a la ruptura de la comunicacion, como aquel jefe de proyecto que abronca al programador cuando este lo comunica que hay un fallo en el diseno. XP ayuda mediante sus practicas a fomentar la comunicacion. Sencillez. Siempre debemos hacernos esta pregunta ? Que es lo mas simple que pueda funcionar? Lograr la sencillez no es facil. Tenemos cierta tendencia a pensar en que programaremos manana, la proxima semana y el proximo mes.

XP nos ensena a apostar, apuesta por hacer una cosa sencilla hoy y pagar un poco mas para manana, si es necesario, que hacer una cosa complicada hoy y no utilizarla despues. La sencillez y la comunicacion se complementan, cuanto mas simple es tu sistema menos tienes que comunicar de el. Retroalimentacion. “No me preguntes a mi, preguntale al sistema”, es la primera clave de la retroalimentacion, por medio de pruebas funcionales a nuestro software este nos mantendra informado del grado de fiabilidad de nuestro sistema, esta informacion realmente no tiene precio.

Los clientes y las personas que escriben pruebas tienen una retroalimentacion real de su sistema. La retroalimentacion actua junto con la sencillez y la comunicacion, cuanto mayor retroalimentacion mas facil es la comunicacion. Cuanto mas simple un sistema mas facil de probar. Escribir pruebas nos orienta como simplificar un sistema, hasta que las pruebas funcionen, cuando las pruebas funcionen tendra mucho echo. Valentia. Asumir retos, ser valientes antes los problemas y afrontarlos.

Cuando no afrontas el problema y se modifica un codigo que positivamente sabes que esta mal acabas odiando el sistema, y cada manana cuando vas a la oficina en el coche te entra dolor de barriga. Cuando vayas hacia el trabajo y se te revuelva el estomago piensa en cambiar de trabajo. 3 Roles en el XP Aunque en otras fuentes de informacion aparecen algunas variaciones y extensiones de roles XP, en este apartado describiremos los roles de acuerdo con la propuesta original de Beck. Programador El programador escribe las pruebas unitarias y produce el codigo del sistema.

Debe existir una comunicacion y coordinacion adecuada entre los programadores y otros miembros del equipo. Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacion. Ademas, asigna la prioridad a las historias de usuario y decide cuales se implementan en cada iteracion centrandose en aportar mayor valor al negocio. El cliente es solo uno dentro del proyecto pero puede corresponder a un interlocutor que esta representando a varias personas que se veran afectadas por el sistema.

Encargado de pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker) El encargado de seguimiento proporciona realimentacion al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.

Tambien realiza el seguimiento del progreso de cada iteracion y evalua si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cuando es necesario realizar algun cambio para lograr los objetivos de cada iteracion. Entrenador (Coach) Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guias a los miembros del equipo de forma que se apliquen las practicas XP y se siga el proceso correctamente. Consultor Es un miembro externo del equipo con un conocimiento especifico en algun tema necesario para el proyecto.

Guia al equipo para resolver un problema especifico. Gestor (Big boss) Es el vinculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacion. 4 Procesos del XP Procesos del XP basicamente contiene los siguientes pasos. 1) El cliente define el valor de negocio a implementar. 2) El programador estima el esfuerzo necesario para su implementacion. 3) El cliente selecciona que construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4) El programador construye ese valor de negocio. 5) Vuelve al paso 1. . Ciclo de vida ideal de XP El ciclo de vida ideal de XP consiste de seis fases: Exploracion, Planificacion de la entrega (Relegase), Iteraciones, Produccion, Mantenimiento y Muerte del Proyecto. Fase I: Exploracion En esta fase, los clientes plantean a grandes rasgos las historias de usuario que son de interes para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologias y practicas que se utilizaran en el proyecto. Se prueba la tecnologia y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo.

La fase de exploracion toma de pocas semanas a pocos meses, dependiendo del tamano y familiaridad que tengan los programadores con la tecnologia. Fase II: Planificacion de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimacion del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. Una entrega deberia obtenerse en no mas de tres meses. Esta fase dura unos pocos dias.

Las estimaciones de esfuerzo asociado a la implementacion de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programacion. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteracion, basandose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la ultima iteracion. La planificacion se puede realizar basandose en el tiempo o el alcance.

La velocidad del proyecto es utilizada para establecer cuantas historias se pueden implementar antes de una fecha determinada o cuanto tiempo tomara implementar un conjunto de historias. Al planificar por tiempo, se multiplica el numero de iteraciones por la velocidad del proyecto, determinandose cuantos puntos se pueden completar. Al planificar segun alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el numero de iteraciones necesarias para su implementacion.

Fase III: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega esta compuesto por iteraciones de no mas de tres semanas. En la primera iteracion se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacion de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide que historias se implementaran en cada iteracion (para maximizar el valor de negocio).

Al final de la ultima iteracion el sistema estara listo para entrar en produccion. Los elementos que deben tomarse en cuenta durante la elaboracion del Plan de la Iteracion son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacion no superadas en la iteracion anterior y tareas no terminadas en la iteracion anterior. Todo el trabajo de la iteracion es expresado en tareas de programacion, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores.

Wake en [18] proporciona algunas guias utiles para realizar la planificacion de la entrega y de cada iteracion. Fase IV: Produccion La fase de produccion requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusion de nuevas caracteristicas a la version actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteracion, de tres a una semana.

Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacion (por ejemplo, durante la fase de mantenimiento). Fase V: Mantenimiento Mientras la primera version se encuentra en produccion, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar despues de la puesta del sistema en produccion.

La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. Fase VI: Muerte del Proyecto Es cuando el cliente no tiene mas historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacion final del sistema y no se realizan mas cambios en la arquitectura. La muerte del proyecto tambien ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. . Las 12 practicas del XP XP no es un modelo de procesos ni un marco de trabajo sino un conjunto de practicas que se complementan unas a otras y deben implementarse en un entorno de desarrollo cuya cultura se base en los cuatro valores antes mencionados. [pic] [pic] [pic] [pic] Ilustracion 4 Las Practicas se refuerzan entre si mismas. 4. CRITERIOS DE COMPARACION Nivel de Colaboracion: Se refiere al grado de interaccion entre el cliente y el equipo de desarrollo. Esta colaboracion entre ambos sera la que marque la marcha del proyecto y asegure su exito.

Simplicidad: Se refiere a la sencillez tanto en su aprendizaje como en su aplicacion, reduciendose asi los costos de implantacion en un equipo de desarrollo, logrando que las cosas puedan funcionar (relacionado al proceso y la codificacion). Nivel de Documentacion: Referida a la cantidad de documentacion que se genera en cada proceso, actividad o tarea durante la ejecucion del ciclo de vida del software. Adaptabilidad: Capacidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologia, en el equipo, etc. ) determina tambien el exito o fracaso del mismo.

Por lo tanto, la planificacion no debe ser estricta sino flexible y abierta. Predictibilidad: Capacidad de la metodologia a utilizar, que en base a su historial de eventos, se puede tener un conocimiento detallado de los procesos y por ende saber el comportamiento del mismo, y poder planificar y actuar. Tipologia del Proceso de desarrollo: Referida a la forma del avance del proceso de desarrollo del software, considerados en las etapas, fases, de cada metodologia. Estructura: Se refiere al esquema e interrelaciones de los procesos o fases que ofrece cada metodologia. 5. ANALISIS COMPARATIVO DE METODOS Criterios |NTP IEC 12207 |Xtreme Programming (XP) | |Nivel de Colaboracion |La norma establece un marcado nivel de jerarquias y |Da una gran importancia al trabajo en equipo durante el desarrollo del| | |responsabilidades para cada uno de sus integrantes, los |software, dado a que permite una mayor agilidad en el desarrollo y | | |cuales no necesariamente deben interactuar.

El cliente |compromiso por parte de todos sus integrantes. La participacion del | | |casi no interviene, salvo en la primera parte del |cliente es importante, ya que es quien definira lo que se va a | | |desarrollo del software, en donde se establecen los |desarrollar, con las caracteristicas y funcionalidades que | | |requerimientos del sistema, en donde tambien podrian |satisfaceran sus requerimientos. | |especificarse los criterios para realizar las pruebas | | | |funcionales. | | |Simplicidad |Es un proceso bastante complejo, con pasos, procesos, |Es uno de sus principios, caracteristica que permite que sus | | |actividades y tareas bien definidas, los cuales solo unos|participantes entiendan el desarrollo de la metodologia y que labores | |cuantos participantes pueden entender, para realizar |realizar, ademas de desarrollar codificacion entendible y relacionada | | |adecuadamente coordinaciones que se tengan que realizar, |directamente con lo que actualmente se requiere, dejando pendiente | | |se debe terminar con un proceso para pasar al siguiente y|posibles adaptaciones ante futuros cambios en los requerimientos. | | |pensar en todas las posibilidades de fallo. | |Nivel de Documentacion |Cada proceso o actividad genera una determinada |Presenta un bajo nivel de documentacion, el proceso de desarrollo no | | |documentacion, la cual servira para poder realizar |toma como punto de partida documentacion alguna, sino el codigo | | |Procesos de Mejora y el aseguramiento de la Calidad. Por |funcionando.

La documentacion se genera en la ultima fase del ciclo de| | |tal motivo esta norma presenta un alto nivel de |vida ideal del XP, que es la muerte del proyecto, esto implica que el | | |documentacion, lo que a la vez favorece a una mayor |cliente no tiene mas requerimientos a satisfacer. | | |calidad en sus procesos y que sirve de punto de partida | | | |para otros procesos. | |Adaptabilidad |Muestra cierta resistencia al cambio, un cambio puede ser|Presenta una alta adaptabilidad frente a cambios en los requerimientos| | |realizado, pero debe ser solicitado en ciertas etapas del|de los clientes, ya que este criterio es un medio que emplea para | | |ciclo de vida y esto implica una reprogramacion o cambios|incrementar las posibilidades de exito de un proyecto. | |en el diseno o arquitectura, lo cual incrementa sus | | | |costos. | | |Tipologia del Proceso de Desarrollo |Por lotes, se considera que un proceso activa el inicio |Continua, el proceso de desarrollo esta basado en la interaccion entre| | |de otro proceso, siguiendo ciertas normas y politicas |el desarrollador y el cliente, la cual se realiza de manera iterativa. | |definidas en la primera etapa. | | |Estructura |Cuenta con Proceso bien definidos, los cuales estan |Basada en la interacciones de las 12 practicas que conforman el XP, en| | |divididos en actividades, que se llevan a cabo mediante |contraste con la NTP ISO 12207, el desarrollo y la responsabilidad es | | |una seria de tareas.

Presenta caracteristicas de |compartida por todo el equipo y los clientes comprometidos. | | |Modularidad y Responsabilidad. | | |Proceso de Operacion |Se da a traves de un conjunto de actividades bien |Debido a que el XP se base en un proceso iterativo de la fase de | | |definidas como: la implementacion del procesos, pruebas |desarrollo de software, el XP no abarca el proceso de operacion, salvo| |de operacion, operacion del sistema y soporte al usuario,|en los momentos en que se producen pruebas al software en la cual hay | | |los cuales se dan luego de que se ha terminado con el |que hacer funcionar el software, condicionando su duracion al tiempo | | |proceso de desarrollo del Software. |en que durara la fase de pruebas. | Proceso de Mantenimiento |Este proceso inicia cuando el producto software sufre |XP no incluye el proceso de mantenimiento, al solo abarcar la fase de | | |modificaciones en el codigo y la documentacion asociada, |desarrollo. Se puede decir que el mantenimiento del software se da a | | |debido a un problema a la necesidad de una mejora o |cada momento en que el programador modifica el software, cuando el | | |adaptacion, preservando su integridad.

Este proceso |cliente lo requiere y cambia sus requerimientos. | | |incluye la migracion y termina con la retirada del | | | |software. | | |Retrasos en la planificacion: |Esta norma establece una programacion y planificacion de |El XP genera una seria de entregables a lo largo de todo su proceso, a| |actividades a realizar, con una serie de procesos y |lo cual el cliente observa el avance de lo que requiere y debido a | | |generacion de documentacion que garanticen el |fuerte interaccion entre los involucrados y centrarse en del | | |aseguramiento de la calidad del producto, pero que debido|desarrollo del software y a su alta especializacion, dejando en su | |a las exigencias que presentan estos procesos, es posible|segundo plano la documentacion, pueden avanzar rapidamente con lo | | |que no se puedan llegar a cumplir con los plazos |encomendado y cumplir con los plazos establecidos. | | |establecidos, Su proposito no es la entrega del producto | | |en el plazo establecido, sino la entrega de un producto | | | |que presente la conformidad con los requisitos que esta | | | |norma. | | |Sistemas Deteriorados |Esta norma establece una serie de procesos bien |Con XP se incurre en el riesgo de desarrollar sistemas deteriorados, | |definidos, que garantizan la posibilidad de realizar |debido a la rapidez con que se elaboran y no contemplar una serie de | | |mantenimientos al producto, para ello la norma abarca las|recomendaciones, como la documentacion de cada actividad o tarea y no | | |posibles modificaciones que se puedan realizar, debido a |ofrecer una fase en la cual se especifiquen las acciones a tomar para | | |la deteccion de fallas y poder realizar mejoras, todo |el mantenimiento del software.

El desarrollo es tanto | | |ello gracias a la documentacion que se genera y a la |responsabilidades de los programadores como de los clientes. Sin | | |trazabilidad que es posible durante el proceso de |embargo la interaccion con los clientes posibilita el facil | | |desarrollo, y a los lineamientos que se dan en el proceso|entendimiento y operacion del producto, ya que intervienen en su | |de mantenimiento, que tambien incluye el proceso de |desarrollo. | | |migracion o en todo caso la posible retirada del | | | |producto. | | |Alta Tasa de Defectos: |Con el Aseguramiento de la Calidad que garantiza esta |XP requiere de personal altamente especializado y capacitado, para | |norma, en el caso de cumplir correctamente con |llevar a cabo con exito cada una de las fases de la metodologia, de lo| | |lineamientos que exige, reduce en gran medida los |contrario se mantendria alta la tasa de defectos del producto, ante | | |defectos del producto, para ello tambien ofrece procesos |ello esta metodologia contempla el trabajo en equipo que permite tener| |de apoyo, que de manera periodica y con el historial |altos niveles de sinergia entre todos los involucrados, los cuales | | |documentario que se maneja, se pueden detectar los |mejoran el rendimiento y la productividad durante el desarrollo y por | | |posibles problemas que se presenten |ende la reduccion de los defectos. | |Requisitos al comprendidos |Es posible que los requerimientos no sean comprendidos |Con XP se tiene un mayor nivel de comprension de los requerimientos de| | |por el personal que desarrollara el producto, debido a |sistemas, ya que el cliente interactua con los involucrados en el | | |que solo se contempla la obtencion de requerimientos |desarrollo del software (el tester) para poder obtener adecuadamente | |hasta la actividad de Analisis de requerimientos de |los requerimientos funcionales, y de manera constante, para poder | | |Sistema del proceso de desarrollo, despues se pierde el |detectar posibles fallas o realizar cambios en los requerimientos. | | |contacto con el cliente, el cual no podra seguir, ni | | | |intervenir en el avance del desarrollo del producto.

Por | | | |tal motivo satisfaccion del cliente con el producto se ve| | | |condicionada a la capacidad de analisis y entendimiento | | | |los desarrolladores, pero sin embargo, la norma establece| | |las recomendaciones del caso para realizar un adecuado | | | |analisis y diseno. | | |Cambios en el Negocio |No podemos decir que la norma 12207 no soporta cambios en|Bueno el modelo ha sido disenado para que se realicen cambios durante | | |el negocio porque si lo tiene y al igual que las |la marcha del proyecto con la finalidad de acercarse cada vez a lo que| |diferentes metodologias busca la satisfaccion del |el cliente requiere con mayor inmediatez. Y brindandole tambien un | | |cliente. La diferencia radica en la manera en que cumple |producto de calidad. | | |esto debido a que los cambios tienen q darse en ciertos | | | |periodos luego de revisar normas y contratos establecidos| | |en etapas iniciales lo cual incremente su costo. | | 6. CONCLUSIONES < La NTP ISO-12207 y el XP son metodos que tienen un distinto ambito de aplicacion, las cuales buscan satisfacer las necesidades del cliente de formas distintas. < No existe una metodologia universal para hacer frente con exito a cualquier proyecto de desarrollo de software. Toda metodologia debe ser adaptada al contexto del proyecto. < La norma ISO 12207 abarca todos los procesos del ciclo de vida del esarrollo del software, desde su concepcion hasta su retirada, en cambio el XP solo abarca el proceso de desarrollo del software, incluyendose de manera implicita algunas actividades propias de los procesos de operacion y mantenimiento. 7. BIBLIOGRAFIA Metodologias agiles para el desarrollo de software: eXtreme Programming (XP) Patricio Letelier y M? Carmen Penades - Universidad Politecnica de Valencia Una explicacion de la programacion extrema (XP) - V Encuentro usuarios xBase 2003 MADRID - Manuel Calero Solis. Programacion Extrema y Software Libre - Alejandro Aguilar Sierra

Octubre 2002 Programacion eXtrema y Software Libre – Gregorio Robles Universidad Politecnica de Madrid Kent Beck. Extreme Programming Explained. Addison-Wesley, 1999. Martin Fowler. Refactoring (Improving the Design of Existing Code). Addison-Wesley, 1999. Erich Gamma et al. Design Patterns (Elements of Reusable OO Software). Addison Wesley, 1994. NTP ISO-12207. TECNOLOGIA DE LA INFORMACION. Procesos del ciclo de vida del software. 2da edicion 2006-07-13 M&T Consulting http://www. mytconsulting. com/principal/Imp_12207. php ———————– [1] Jose H. Canos.

Patricio Letelier y M? Carmen Penades. Metodologias Agiles en el Desarrollo de Software . DSIC -Universidad Politecnica de Valencia. [2] Patricio Letelier. Metodologias agiles para el desarrollo de software: eXtreme Programming. Universidad Politecnica de Valencia. [3] M&T Consulting. http://www. mytconsulting. com/principal/Imp_12207. php [4] M&T Consulting. [5] Carlos Osorio D. Jefe de la Oficina de Tecnologias de la Informacion. Fondo MIVIVIENDA S. A. [6] Martin Vidalon. Jefe de Informatica y Sistemas. OSIPTEL. [7] Manuel Calero Solis – V Encuentro usuarios xBase 2003 MADRID.