Modelos de Desarrollo de Software 2013

MODELO INCREMENTAL El Modelo Incremental para el desarrollo del software, consiste en crear funcionalidad por pequea que sea de modo que a partir de ella, las creaciones posteriores en base a la que primero fue creada, tendrn una caracterstica (o caractersticas) funcionales, lo cual hace que se constituya en base a elementos que funcionan y que va siendo cada vez ms compleja su funcionalidad. Los avances son entregados mediante fechas programadas, de modo que cada incremento posee nuevas funcionalidades a comparacin de un incremento anterior. Este modelo posee etapas tales como: 1. 2. 3. 4. 5. 6. 7. Definicin de requerimientos Asignar los requerimientos a los incrementos. Diseo del incremento a partir de los requerimientos. Desarrollo del incremento. Validar incrementos. Integrar incrementos. Validar funcionamiento.

Las ideologas del modelo incremental pretende dar pautas en la creacin del software mediante incrementos pequeos, permitiendo su fcil administracin, as como su sencilla comprensin y sus correspondientes pruebas, esto implica que el desarrollo inicial se logra ms temprano obteniendo resultados de inversin en poco tiempo, otro aspecto a considerar es que este modelo se presta a posibles cambios debido a que los incrementos de van adaptando de acuerdo a los requerimientos que se obtienen en base a las nuevas necesidades que van surgiendo. Modelos Incrementales Iterativos El modelo incremental combina elementos del modelo cascada (aplicado repetidamente) as como la filosofa iterativa del prototipado.

Modelos de Desarrollo de Software 2013

La parte inicial es el ncleo del producto (es la parte ms importante). Una nueva versin del producto surge cuando nuevas caractersticas han sido implementadas a medida que han sido sugeridas por el usuario. Este modelo es aplicable cuando es difcil establecer los requisitos iniciales de un proyecto y es ms apropiado para proyectos pequeos. Las nuevas versiones pueden ser planeadas de modo que los requisitos tcnicos puedan ser administrados. El objetivo es trabajar junto al usuario para descubrir sus requisitos de manera incremental antes de que el producto final sea obtenido. El modelo iterativo de desarrollo de software se basa en que antes de entregar el sistema de una vez, tanto el desarrollo como las entregas se dividen en incrementos. Los requisitos del usuario se priorizan y los requisitos de prioridad ms alta se incluyen en los incrementos ms tempranos. Cuando el desarrollo de un incremento comienza, sus requisitos son inamovibles, aunque los requisitos de incrementos posteriores pueden continuar desarrollndose. Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos ms crticos. Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos. Un grfico que muestra cual es el desarrollo de este proceso es el siguiente, que lo encontr en una pgina cuyo link esta al final de este artculo: PROGRAMACION EXTREMA XP HISTORIA La programacin extrema o eXtreme Programming (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. INTRODUCCION Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en

Modelos de Desarrollo de Software 2013

realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico.
MAPA CONCEPTUAL

QU

ES

PROGRAMACIN EXTREMA O XP? Metodologa liviana de desarrollo de software Conjunto de prcticas y reglas empleadas para desarrollar software Basada en diferentes ideas acerca de cmo enfrentar ambientes muy cambiantes Originada en el proyecto C3 para Chrysler En vez de planificar, analizar y disear para el futuro distante, hacer todo esto un poco cada vez, a travs de todo el proceso de desarrollo

OBJETIVOS. Establecer las mejores prcticas de Ingeniera de Software en los desarrollo de proyectos. Mejorar la productividad de los proyectos. Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

CONTEXTO XP Cliente bien definido Los requisitos pueden (y van a) cambiar Grupo pequeo y muy integrado (mximo 12 personas Equipo con formacin elevada y capacidad de aprender

Modelos de Desarrollo de Software 2013

CARACTERSTICAS XP Metodologa basada en prueba y error Fundamentada en Valores y Prcticas Expresada en forma de 12 PrcticasConjunto completoSe soportan unas a otrasSon conocidas desde hace tiempo. La novedad es juntarlas

VALORES XP Simplicidad XP propone el principio de hacer la cosa ms simple que pueda funcionar, en relacin al proceso y la codificacin. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo maana. Comunicacin Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algn momento. XP hace casi imposible la falta de comunicacin. Realimentacin Retroalimentacin concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente. Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si funcionamejralo)

EL ESTILO XP Est orientada hacia quien produce y usa el software Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema. Combina las que han demostrado ser las mejores practicas para desarrollar software, y las lleva al extremo.

PRCTICAS BSICAS DE LA PROGRAMACIN EXTREMA Para que todo esto funcione, la programacin extrema se basa en doce "prcticas bsicas" que deben seguirse al pie de la letra. Dichas prcticas estn definidas (en perfecto ingls) en www.xprogramming.com/xpmag/whatisxp.htm. Aqu tienes un pequeo resumen de ellas. Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto. Planificacin: Se hacen las historias de usuario y se planifica en qu orden se van a hacer y las mini-versiones. La planificacin se revisa continuamente. Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones. Versiones pequeas: Las mini-versiones deben ser lo suficientemente pequeas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo til al usuario final y no trozos de cdigo que no pueda ver funcionando. Diseo simple: Hacer siempre lo mnimo imprescindible de la forma ms sencilla posible. Mantener siempre sencillo el cdigo. Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).

Modelos de Desarrollo de Software 2013

Desarrollo guiado por las pruebas automticas: Se deben realizar programas de prueba automtica y deben ejecutarse con mucha frecuencia. Cuantas ms pruebas se hagan, mejor. Integracin continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequea funcionalidad, debe recompilarse y probarse. Es un error mantener una versin congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qu es lo que falla de todo lo que hemos metido. El cdigo es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del cdigo. Para eso se hacen las pruebas automticas. Normas de codificacin: Debe haber un estilo comn de codificacin (no importa cul), de forma que parezca que ha sido realizado por una nica persona. Metforas: Hay que buscar unas frases o nombres que definan cmo funcionan las distintas partes del programa, de forma que slo con los nombres se pueda uno hacer una idea de qu es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qu estamos hablando y que no haya mal entendidos. Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber das muertos en que no se sabe qu hacer y que no se deben hacer un exceso de horas otros das. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versin. VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING Ventajas: Programacin organizada. Menor taza de errores. Satisfaccin del programador.

Desventajas: Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar.

CONCLUSIONES Apostolado de metodologas exitosas Aporte de la experiencia prctica a los modelos tericos Enfoque de conjunto de prcticas como rompecabezas Tecnologa en expansin Importancia de revisitar las metodologas desde la experiencia prctica

Modelos de Desarrollo de Software 2013

MODELO DE DESARROLLO RPIDO DE APLICACIONES El Desarrollo Rpido de Aplicaciones o RAD (Rapid Application Development) es aquel mtodo que contempla un desarrollo de modo iterativo as como la realizacin de prototipos, su esencia se concentra en la usabilidad y utilidad as como la rapidez de ejecucin, forma parte al desarrollo lineal secuencial solo que la diferencia ms notable es que se lleva a cabo en ciclos cortos, el equipo que implementa esta metodologa realiza desarrollos en periodos cortos de tiempo. Esta metodologa est constituida por las siguientes etapas:

Figura 4 El modelo de Ciclo de Vida RAD

El modelo de ciclo de vida RAD se muestra en la Figura 4. Las limitaciones de tiempo impuestas en un proyecto RAD exigen que la aplicacin cumpla con el requisito de mbito en escalas, que indique que una aplicacin pueda modularse de forma que cada una de las funciones principales pueda completarse en menos de tres meses. Adems, cada una de las funciones puede ser afrontada por un equipo RAD separado e integrarse en un nico conjunto. Modelado de la gestin: Dentro de esta etapa, el objetivo es la solucin de las preguntas; por ejemplo: Qu informacin conduce el proceso de gestin?,Qu informacin se genera?, A dnde va a parar esa informacin?,etc. Modelado de datos: Contempla la definicin de las caractersticas de los objetos, as como la constitucin de los objetos y sus vnculos entre ellos. Modelado de proceso: Describe las metodologas que manipulan los objetos as como la comunicacin entre ellos. Generacin de aplicaciones: Permite la utilizacin de recursos que ya existen o crear componentes reutilizables. Pruebas de entrega: Prueba todos los componentes nuevos.

Modelos de Desarrollo de Software 2013

Inconvenientes: Este mtodo requiere de recursos suficientes, no es adecuado para riesgos tcnicos altos, por ejemplo cuando se quiere que haya integridad junto con programas existentes dentro de la maquina donde se quiera someter en operacin. Caractersticas Debe contener dentro de un equipo, personas que involucran tanto su desarrollo as como aquellos que analizan los requirimientos. Muestra mediante modelos que contemplen los factores que permitan dar nociones a la vida real. Ventajas Los entregables pueden ser fcilmente trasladados a otra plataforma. El desarrollo se realiza a un nivel de abstraccin mayor. Mayor flexibilidad. Menor codificacin manual. Mayor involucramiento de los usuarios. Posiblemente menos fallas. Ciclos de desarrollo ms pequeos. Interfaz grfica estndar.

Desventajas Comprar puede ser ms caro que construir. Costo de herramientas integradas y equipo necesario. Progreso ms difcil de medir. Menos eficiente. Riesgo de revertirse a las prcticas sin control de antao. Ms fallas (por sndrome de "codificar a lo bestia"). Prototipos pueden no escalar, un problema maysculo.

Bibliografa http://ingenexescom.blogspot.com/2012/02/modelo-incremental.html http://xherrera334.blogspot.es/1193789220/ http://ingenexescom.blogspot.com/2012/02/modelo-de-desarrollo-rapido-de.html http://ingenieriadesoftware.mex.tl/images/18149/PROGRAMACI%C3%93N%20EXTREMA.p df http://spanishpmo.com/index.php/ciclos-de-vida-desarrollo-rapido-de-aplicaciones/