Академический Документы
Профессиональный Документы
Культура Документы
INGENIERIA DE SOFTWARE
DESARROLLO AGIL
Alumnos: Lic. Ral Enrquez Chvez Lic. Alfredo Garca Corpus
NDICE
ndice
1. Metodologa gil 2. Programacin Extrema (XP; Extreme Programming) a. Definicin b. Proceso de Desarrollo 3. SCRUM, Ciclos de desarrollo. a. Caractersticas b. Proceso 4. Metodologa Crystal a. Qu es Crystal Clear? b. Caractersticas c. Tcnicas 5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) a. Fases b. Nueve Principios del DSDM 6. Desarrollo de Sistemas Adaptivos (ASD) a. Definicin b. Ciclo de Vida Especular-ColaborarAprender c. Fases del Proyecto 7. Desarrollo basado en Funcionalidades (FDD) a. Definicin b. Ciclo de Vida c. Ventajas 8. Desarrollo Lean (LD) a. Fundamentos b. 7 Principios del desarrollo Lean 9. Conclusiones
1. Metodologa gil La historia de las Metodologas giles y su apreciacin como tales en la comunidad de la ingeniera de software tiene sus inicios en la creacin de una de las metodologas utilizada como arquetipo: XP - eXtreme Programming. XP surge de la mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham, y utilizando conceptos como el de Chief Programmer creado por IBM en la dcada de los 70. A principios de la dcada del 90, surgi un enfoque que fue bastante revolucionario para su momento ya que iba en contra de la creencia de que mediante procesos altamente definidos se iba a lograr obtener software en tiempo, costo y con la requerida calidad.
1. Metodologa gil El enfoque fue planteado por primera vez por [Martin, 1991] y se dio a conocer en la comunidad de ingeniera de software con el mismo nombre que su libro, RAD o Rapid Application Development. RAD consista en un entorno de desarrollo altamente productivo, en el que participaban grupos pequeos de programadores utilizando herramientas que generaban cdigo en forma automtica tomando como entradas sintaxis de alto nivel. En general, se considera que este fue uno de los primeros hitos en pos de la agilidad en los procesos de desarrollo
1. Metodologa gil Estamos poniendo al descubierto mejores mtodos para desarrollar software, hacindolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interaccin por encima El software que funciona La colaboracin con el cliente La respuesta al cambio por encima por encima por encima
de los procesos y las herramientas de la documentacin exhaustiva la negociacin contractual seguimiento de un plan
1. Metodologa gil Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo fundamental.
1. Metodologa gil La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.
1. Metodologa gil
1. Metodologa gil
La programacin extrema es una metodologa de desarrollo ligera (o gil) basada en una serie de valores y de prcticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programacin se basa en una serie de metodologas de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programacin.
Cliente en el lugar de Desarrollo: Incluir un cliente real en el equipo, disponible de forma full-time para responder preguntas.
Estndares de Codificacin: Los programadores escriben todo el cdigo de acuerdo con reglas que enfatizan la comunicacin a travs del mismo.
2. Programacin Extrema (XP; Extreme Programming) Conclusin: Extreme Programming es una disciplina de desarrollo de software basado en los valores de la simplicidad, la comunicacin, la retroalimentacin y valenta. Funciona al llevar todo el equipo reunido en la presencia de prcticas simples, con suficiente informacin para que el equipo para ver dnde estn y para ajustar las prcticas a su situacin particular.
3. SCRUM, Ciclos de desarrollo. a: Caractersticas Scrum define un proceso emprico, iterativo e incremental de desarrollo que intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos, etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la utilizacin de prcticas tendientes a manejar la impredictibilidad y el riesgo a niveles aceptables. El mismo surge de un artculo de 1986 de la Harvard Business Review titulado The New New Product Development Game de Takeuchi y Nonaka, que introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995.
Conclusiones: La intencin de Scrum es la de maximizar la realimentacin sobre el desarrollo pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se est extendiendo cada vez ms dentro de la comunidad de Metodologas giles, siendo combinado con otras como XP para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna prctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework gil de administracin de proyectos que puede ser combinado con cualquiera de las metodologas mencionadas.
http://www.youtube.com/watch?v=EF-duw7-nOY&feature=related
4. Metodologa Crystal a. Qu es Crystal Clear? En los inicios de 1990, en un estudio realizado en IBM se lleg a los siguientes acuerdos (Cockburn, 2001). Los equipos exitosos enfatizaban que no haban seguido mtodos formales ni herramientas CASE y que haban estimulado la comunicacin y los test. Los equipos con problemas no entendan sus fallas o si haban cumplido con los mtodos formales. Crystal Clear no es una metodologa en si misma sino una familia de metodologas con un cdigo gentico comn. El nombre Crystal deriva de la caracterizacin de los proyectos segn 2 dimensiones, tamao y complejidad (como en los minerales, color y dureza).
4. Metodologa Crystal
b. Caractersticas Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus puntos de estudio son: Aspecto humano del equipo Tamao de un equipo (nmero de componentes) Comunicacin entre los componentes Distintas polticas a seguir Espacio fsico de trabajo
4. Metodologa Crystal
b. Caractersticas Crystal Clear se corresponde con el color Blanco en la codificacin de colores de Crystal 3 8 personas
Crystal Orange se corresponde con el color Naranja en la codificacin de colores de Crystal 25 50 personas
3-8
10-20
25-50
800+
4. Metodologa Crystal
4. Metodologa Crystal b. Caractersticas 1) Entrega frecuente. Consiste en entregar software a los clientes con
2) frecuencia, no solamente en compilar el cdigo. La frecuencia depender del proyecto, pero puede ser diaria, semanal o mensual. Comunicacin osmtica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un experto diseador senior y discutir respecto del tema que se trate. Mejora reexiva. Tomarse un pequeo tiempo (unas pocas horas cada o una vez al mes) para pensar bien qu se est haciendo, cotejar notas, reexionar, discutir. Seguridad personal. Hablar con los compaeros cuando algo molesta dentro del grupo. Foco. Saber lo que se est haciendo y tener la tranquilidad y el tiempo para hacerlo. Fcil acceso a usuarios expertos. Tener alguna comunicacin con expertos desarrolladores.
3)
4) 5) 6)
DSDM se centra en la entrega de la solucin de negocio, y no slo la actividad del equipo. Tiene las medidas necesarias para garantizar el sentido de viabilidad y de negocios de un proyecto antes de que se crea. Hace hincapi en la cooperacin y colaboracin entre todas las partes interesadas. DSDM hace un uso intensivo de creacin de prototipos para asegurarse de que las partes interesadas tengan una imagen clara de todos los aspectos del sistema.
5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Las 5 Fases del DSDM 1. Estudio de Factibilidad - Averiguar si y cmo el proyecto se
resolver.
Se puede hacer dentro de las limitaciones de tiempo y recursos? Esta fase se lleva a cabo lo ms rpidamente posible, porque DSDM es la mejor opcin donde el tiempo es corto, y por lo tanto, el producto debe ser entregado rpidamente.
5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Las 5 Fases del DSDM 3. Modelo Funcional
En esta etapa, los prototipos funcionales del sistema se hacen y se revisan. Un prototipo funcional es un prototipo de las funciones que el sistema debe realizar y cmo debe llevarlas a cabo. Prototipos cubren diferentes aspectos del sistema: Empresas Usabilidad - qu tan fcil es usarlo? El rendimiento y la capacidad - puede manejar el volumen y frecuencia de uso que va a recibir? Tcnica - Cul es la mejor manera de ocuparse de resolver el problema?
4. Disear y Construir.
En esta etapa, el producto es diseado y desarrollado en las iteraciones. En cada iteracin una parte del modelo de diseo se estn desarrollando, y luego se codifica y revisa.
5. Mtodo de Desarrollo de Sistemas Dinmicos (DSDM) Las 5 Fases del DSDM 5. Implementar y Mantener
En la ltima fase, el producto se implementa, se escribe la documentacin y se elabora un documento de revisin comparando los requisitos con lo cumplido con en el producto. Los usuarios son capacitados en el uso del sistema y los usuarios dan su aprobacin al sistema. Despus de que el producto es creado, el mantenimiento, inevitablemente, tendr que llevarse a cabo. Este mantenimiento se hace generalmente en un ciclo similar al utilizado para desarrollar el producto.
1. Eliminar el desperdicio
Brindar un liderazgo tcnico y de mercado - la organizacin puede ser exitosa si produce productos innovadores y tecnolgicamente avanzados, pero es importante comprender lo que valoran nuestros clientes y conocer la tecnologa que se est usando.
Crear solamente cosas de valor - debemos ser cuidados con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos son tiles y estn enfocados en crear valor.
Escribir menos cdigo - mientras ms cdigo se tenga, ms pruebas se van a necesitar, por lo que se necesitar ms trabajo. Si escribiramos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.
2. Crear conocimiento
Crear equipos de diseo y construccin - el lder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los insite a buscar respuestas y volver lo ms pronto posible con los problemas que surgen, o con las soluciones inventadas.
Mantener una cultura de mejora continua - crear un ambiente en donde las personas estn mejorando continuamente en lo que trabajan - deben saber que no son y no deben ser perfectas - y que siempre tienen algn rea que pueden mejorar.
Ensear mtodos de resolucin de problemas - los equipos de desarrollo deberan comportarse como pequeos centros de investigacin, estableciendo hiptesis y realizando varios experimentos rpidos para verificar su validez.
3. Construir la calidad
Sincronizar - para lograr una alta calidad en el software nos debemos empezar a ocupar de l antes de empezar a escribir una sola lnea de cdigo. Automatizar - automatizar las pruebas, la construccin, las instalacionoes, y cualquier cosa que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualqueir cosa que quieran sin preocuparse por si el cambio hace que las cosas dejen de funcionar. Refactor - eliminar la duplicacin de cdigo a CERO - cada vez que aparezca la oportunidad, realizar el refactor del cdigo, de las pruebas y de la documentacin para minimizar la complejidad.
4. Postergar el compromiso
Agendar las decisiones irreversibles hasta el ltimo momento responsable debemos saber hacia donde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo da a da - lo ms importante es mantener la direccin correcta. Romper con las dependencias - los componentes deben estar lo ms desacoplados posible para que puedan implementarse en cualquier orden. Mantener opciones - desarrollar mltiples soluciones para todas las decisiones crticas y ver cuales funcionan mejor.
5. Optimizar el total
Enfocarse en el flujo completo de valor - enfocarse en ganar la carrera completa (que es el software). No hay que gastar esfuerzo en optimizar ineficiencias locales, sino en ver el todo y optimizar a la organizacin en su totalidad.
Entregar un producto completo - los equipos necesitan tener buenos lderes, y tambin buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.
9. CONCLUSIONES Las metodologas giles surgen como respuesta a problemas reales. Se basan en el sentido comn, pero rompen con creencias arraigadas. Pero la metodologa perfecta no existe. Se estn extendiendo con rapidez. Son aplicables al mundo del software libre? Se enfocan en la colaboracin y en el aprendizaje.