EL DESARROLLO RPIDO DE APLICACIONES (RAD) Es una metodologa de desarrollo de software, que implica el desarrollo iterativo y la construccin de prototipos.

El desarrollo rpido de aplicaciones es un trmino originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991 METODOLOGAS DE DESARROLLO ORIENTADO A OBJETOS, Diseo orientado a objetos (OOD) de Grady Booch, tambin conocido como Anlisis y Diseo Orientado a Objetos (OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transicin, la interaccin, mdulo, y el proceso. MTODO DE DESARROLLO DE SISTEMAS DINMICOS Dynamic Systems Development Method o DSDM) es un mtodo que provee un framework para el desarrollo gil de software, apoyado por su continua implicacin del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema que reuna las necesidades de la empresa en tiempo y presupuesto. Es uno de un nmero de mtodos de desarrollo gil de software y forma parte del alianza gil. DSDM fue desarrollado en el Reino Unido en los aos 90 por un consorcio de proveedores y de expertos en la materia del desarrollo de sistemas de informacin (IS), el consorcio de DSDM, combinando sus experiencias de mejores prcticas. El consorcio de DSDM es una organizacin no lucrativa y proveedor independiente, que posee y administra el framework. La primera versin fue terminada en enero de 1995 y publicada en febrero de 1995. La versin actualmente en uso (abril de 2006) es la versin 4.2: El framework para el Negocio Centralizado Desarrollado lanzado en mayo de 2003. Como extensin del Desarrollo rpido de aplicaciones (RAD), DSDM se centra en los proyectos de sistemas de informacin que son caracterizados por presupuestos y agendas apretadas. DSDM trata los problemas que ocurren con frecuencia en el desarrollo de los sistemas de informacin en lo que respecta a pasar sobre tiempo y presupuesto y otras razones comunes para la falta en el proyecto tal como falta de implicacin del usuario y de la comisin superior de la gerencia. DSDM consiste en 3 fases: fase del pre-proyecto, fase del ciclo de vida del proyecto, y fase del post-proyecto. La fase del ciclo de vida del proyecto se subdivide en 5 etapas: 1. estudio de viabilidad, 2. estudio de la empresa, 3. iteracin del modelo funcional, 4. diseo e iteracin de la estructura, e 5. implementacin. SCRUM Es un marco de trabajo para la gestin y desarrollo de software basada en un proceso iterativo e incremental utilizado comnmente en entornos basados en el desarrollo gil de software. Aunque Scrum estaba enfocado a la gestin de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximacin de gestin de programas: Scrum de Scrums. Caractersticas de Scrum Scrum es un modelo de referencia que define un conjunto de prcticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutar durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de

caractersticas que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunin de Sprint Planning. Durante esta reunin, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos estn congelados durante el sprint. Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos los miembros del equipo, y la comunicacin verbal entre todos los miembros y disciplinas involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. RUP es un proceso que define claramente quien, cmo, cundo y qu debe hacerse; este aporta herramientas como los casos de uso, que definen los requerimientos adems de permitir la ejecucin iterativa del proyecto y del control de riesgos. Caractersticas principales del proceso RUP. Guiado por los Casos de Uso Centrado en la Arquitectura Guiado por los Riesgos Iterativo DESARROLLO MANEJADO POR RASGOS (FDD) El Desarrollo Manejado por Rasgos (FDD por sus siglas en ingls) fue desarrollado por Jeff De Luca y el viejo gur de la OO Peter Coad. Como las otras metodologas adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos semanas. Procesos de la metodologa FDD. El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto. Desarrollar un Modelo Global Construir una Lista de los Rasgos Planear por Rasgo Disear por Rasgo Construir por Rasgo MICROSOFT SOLUTIONS FRAMEWORK (MSF) Es una flexible e interrelacionada serie de conceptos, modelos y prcticas de uso que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas. Originalmente creado en 1994 para conseguir resolver los problemas a los que se enfrentaban las empresas en sus respectivos proyectos, se ha convertido posteriormente en un modelo prctico que facilita el xito de los proyectos tecnolgico Caractersticas de MSF.

Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar. Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnologa. TOP-DOWN PROGRAMMING Evolucionado en la dcada de 1970 por el investigador de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado. PROGRAMACIN EXTREMA (XP) es un enfoque de la ingeniera de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. Caractersticas fundamentales Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. AGILE UNIFIED PROCESS (AUP) Es una versin simplificada del IBM Rational Unified Process (RUP), desarrollado por Scott Ambler. En l se describe un mtodo sencillo, fcil de entender para el desarrollo de software de aplicaciones empresariales utilizando tcnicas giles y conceptos y an as se mantiene fiel el RUP.

El AUP se aplica tcnicas giles como Test Driven Development (TDD), Agile Modeling , gestin del cambio gil y refactorizacin de base de datos para mejorar la productividad. A diferencia de la RUP, el PUA tiene slo siete disciplinas: 1. Modelo. Entender el negocio de la organizacin, el dominio del problema que se aborda el proyecto, e identificar una solucin viable para hacer frente al dominio del problema. 2. Implementacin. Transformar el modelo (s) en cdigo ejecutable y realizar un nivel bsico de las pruebas, en particular, las pruebas unitarias . 3. Prueba. Realizar una evaluacin objetiva para asegurar la calidad. Esto incluye encontrar defectos, validar que el sistema funcione como est diseado, y verificar que se cumplen los requisitos. 4. Implementacin. Planificar para la entrega del sistema y para ejecutar el plan para hacer que el sistema de disposicin de los usuarios finales. 5. Gestin de la Configuracin. Administrar el acceso a los artefactos del proyecto. Esto incluye no slo el seguimiento de versiones de artefactos a travs del tiempo, sino tambin el control y la gestin de los cambios a los mismos. 6. Gestin de Proyectos . Dirigir las actividades que se realizan dentro del proyecto. Esto incluye la gestin de riesgos, las personas que dirigen (la asignacin de tareas, seguimiento de los progresos, etc), y la coordinacin con las personas y los sistemas fuera del alcance del proyecto para asegurarse de que se entregue a tiempo y dentro del presupuesto. 7. Medio Ambiente. Apoyar el resto del esfuerzo, garantizando que el proceso de orientacin adecuada, (normas y directrices), y las herramientas (hardware, software, etc) estn disponibles para el equipo segn sea necesario. EL PROCESO UNIFICADO EMPRESARIAL (EUP) Es una variante extendida del Rational Unified Process y fue desarrollado por Scott W. Ambler y Larry Constantino en el ao 2000, con el tiempo reelaborado en 2005 por Ambler, Nalbone John y Michael Vizdos EUP fue introducido para superar la escasez de algunos de RUP, es decir, la falta de apoyo al sistema y eventual retiro de un sistema de software. Por lo tanto dos fases y varias nuevas disciplinas se han aadido a las RUP. EUP ve el desarrollo de software, no como una actividad independiente, sino integrada en el ciclo de vida del sistema (que se construir o mejorado o sustituido), el ciclo de vida de la empresa y el ciclo de vida de la organizacin / negocio de la empresa en s misma. LA METODOLOGA DE DISEO DE CONSTRUCCIONISTA (MDL) Fue desarrollado por la inteligencia artificial (IA) investigador Kristinn R. Thorisson y sus estudiantes en la Universidad de Columbia y la Universidad de Reykjavik para su uso en el desarrollo de la robtica cognitiva , comunicativas humanoides y amplios sistemas de nteligencia artificial. La creacin de tales sistemas requiere la integracin de un gran nmero de funcionalidades que deben ser cuidadosamente coordinados para alcanzar el comportamiento del sistema coherente. MDL se basa en pasos iterativos de diseo que conducen a la creacin de una red de mdulos que interactan con nombre, comunicando a travs de corrientes de tipo explcito y mensajes discretos. MDL ha sido utilizado en la creacin de muchos sistemas, incluyendo la robtica, animacin facial, de la simulacin a gran escala y los seres humanos virtuales. Uno de los primeros sistemas era MIRAGE, un ser humano simulado en un entorno de realidad aumentada que puedan interactuar con las personas a travs del habla y el gesto.