Your SlideShare is downloading. ×
  • Like
Metodologia
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Metodologia

  • 327 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
327
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
20
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Universidad Nacional de SanAntonio Abad del CuscoFacultad de Ciencias Químicas Físicas yMatemáticasCarrera Profesional de Ingeniería Informática yde SistemasMetodologías Ágilespara el Desarrollo del softwareALUMNO:HUAMANÑAHUI ZAVALA FRANCIS 090002DOCENTE:ING.GUZMAN TICONA PARÍ.CURSO:SISTEMAS DE INFORMACION ICusco – Perú2013
  • 2. Índice1. Introducción.................................................................................................. 32. Las Metodologías Ágiles ............................................................................ 42.1 ¿Por qué usar Metodologías Ágiles? ..................................................... 53. Metodologías Ágiles de Desarrollo de Software ..................................... 63.1 XP – eXtreme Programming................................................................... 74. Conclusiones.............................................................................................. 135. Referencias................................................................................................ 14
  • 3. Metodologías Ágiles1. IntroducciónPara asegurar el éxito durante el desarrollo de software no es suficiente contarcon notaciones de modelado y herramientas, hace falta un elemento importante: lametodología de desarrollo, la cual nos provee de una dirección a seguir para la correctaaplicación de los demás elementos.Generalmente el proceso de desarrollo llevaba asociado un marcado énfasis en elcontrol del proceso mediante una rigurosa definición de roles, actividades yartefactos, incluyendo modelado y documentación detallada. Este esquema"tradicional" para abordar el desarrollo de software ha demostrado ser efectivo ynecesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por logeneral se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque noresulta ser el más adecuado para muchos de los proyectos actuales donde elentorno del sistema es muy cambiante, y en donde se exige reducirdrásticamente los tiempos de desarrollo pero manteniendo una alta calidad.
  • 4. 2. Las Metodologías ÁgilesA principios de la década del ’90, surgió un enfoque que fue bastanterevolucionario para su momento ya que iba en contra de toda creencia de quemediante procesos altamente definidos se iba a lograr obtener software en tiempo,costo y con la requerida calidad. El enfoque fue planteado por primera vez porMartin y se dio a conocer en la comunidad de Ingeniería de Software con el nombre deRAD o Rapid Application Development. RAD consistía en un entorno dedesarrollo altamente productivo, en el que participaban grupos pequeños deprogramadores utilizando herramientas que generaban código en formaautomática tomando como entradas sintaxis de alto nivel. En general, se considera queeste fue uno de los primeros hitos en pos de la agilidad en los procesos dedesarrollo.La historia de las Metodologías Ágiles y su apreciación como tales en lacomunidad de la Ingeniería de Software tiene sus inicios en la creación de una delas metodologías utilizada como arquetipo: XP - eXtreme Programming, que nace dela mente de Kent Beck, tomando ideas recopiladas junto a Ward Cunningham.Durante 1996, Beck es llamado por Chrysler como asesor del proyecto ChryslerComprehensive Compensation (C3) payroll system. Dada la poca calidad del sistemaque se estaba desarrollando, Beck decide tirar todo el código y empezar de ceroutilizando las prácticas que él había ido definiendo a lo largo del tiempo. El sistema,que administra la liquidación de aproximadamente 10.000 empleados, y consiste de2.000 clases y 30.000 métodos, es puesto en operación en Mayo de 1997 casirespetando el calendario propuesto. Como consecuencia del éxito de dicho proyecto,Kent Beck dio origen a XP iniciando el movimiento de metodologías ágiles al que seanexarían otras metodologías surgidas mucho antes que el propio Beck fueraconvocado por Chrysler.Es así como que este tipo de metodologías fueron inicialmente llamadas“metodologías livianas”, sin embargo, aun no contaban con una aprobación pues se leconsideraba por muchos desarrolladores como meramente intuitiva. Luego, con el pasarde los años, en febrero de 2001, tras una reunión celebrada en Utah-EEUU, naceformalmente el término “ágil” aplicado al desarrollo de software. En esta mismareunión participan un grupo de 17 expertos de la industria del software, incluyendoalgunos de los creadores o impulsores de metodologías de software con el objetivode esbozar los valores y principios que deberían permitir a los equipos desarrollar
  • 5. software rápidamente y respondiendo a los cambios que puedan surgir a lo largo delproyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo desoftware tradicionales, caracterizados por ser rígidos y dirigidos por la documentaciónque se genera en cada una de las actividades desarrolladas.Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo delucro, dedicada a promover los conceptos relacionados con el desarrollo ágil desoftware y ayudar a las organizaciones para que adopten dichos conceptos. El puntode partida fue el Manifiesto Ágil, un documento que resume la filosofía “ágil”.2.1 ¿Por qué usar Metodologías Ágiles?Tomando las ideas de la Tabla Nº 1 podemos decir que las metodologíastradicionales presentan los siguientes problemas a la hora de abordar proyectos:-Existen unas costosas fases previas de especificación de requisitos, análisis ydiseño. La corrección durante el desarrollo de errores introducidos en estas fasesserá costosa, es decir, se pierde flexibilidad ante los cambios.-El proceso de desarrollo está encorsetado por documentosfirmados.-El desarrollo es más lento. Es difícil para los desarrolladores entender unsistema complejo en su globalidad.Las metodologías ágiles de desarrollo están especialmente indicadas en proyectoscon requisitos poco definidos o cambiantes. Estas metodologías se aplican bien enequipos pequeños que resuelven problemas concretos, lo que no está reñido con suaplicación en el desarrollo de grandes sistemas, ya que una correctamodularización de los mismos es fundamental para su exitosa implantación. Dividirel trabajo en módulos abordables minimiza los fallos y el coste. Las metodologíaságiles presentan diversas ventajas, entre las que podemos destacar:-Capacidad de respuesta a cambios de requisitos a lo largo del desarrollo.-Entrega continua y en plazos breves de software funcional.-Trabajo conjunto entre el cliente y el equipo de desarrollo. ----Importancia de la simplicidad, eliminado el trabajo.innecesario.-Atención continua a la excelencia técnica y al buen diseño.-Mejora continua de los procesos y el equipo de desarrollo.
  • 6. 3. Metodologías Ágiles de Desarrollo de SoftwareEn la Tabla Nº2 apreciamos las convergencias y divergencias en la definiciónde las metodologías ágiles más importantes.Metodología Acrónimo Creación Tipo demodeloCaracterísticaAdaptive SoftwareDevelopmentASDHighsmith 2000Prácticas + ciclode vidaInspirado en sistemasadaptativos complejosAgile ModelingAMAmbler 2002 Metodologíabasada en laprácticaSuministra modeladoágil a otros métodosCristal Methods CM Cockbum 1998Familia demetodologías Metodología ágil con énfasis enmodelo de ciclosAgile RUP dXBooch, Martin,Newkirk 1998Framework/Disciplina XP dado vuelta conartefactos RUPDynamic SolutionsDelivery Model DSDM Stapleton 1997Framework/modelo deciclodevidaCreado por 16 expertosen RADEvolutionaryProject Management EVOGilb 1976 FrameworkadaptativoPrimer método ágil existenteXtreme Programming XP Beck 1999 Disciplina enprácticas deingenieríaMétodo ágil radicalFeature-DrivenDevelopmentFDDDe Luca & Coad1998Palmer & Felsing2002MetodologíaMétodo ágil de diseño yconstrucciónLean DevelopmentLDCharette 2001,Mary y TomPoppendieckForma de pensar –modelo logísticoMetodología basada en procesosproductivosRapid DevelopmentRADMcConnell 1996 Survey detécnicas ymodelosSelección de best practices, nométodoMicrosoft SolutionsFrameworkMSFMicrosoft 1994 Lineamientos,disciplinas,prácticasFramework dedesarrollo de solucionesScrumScrumSutherland 1994Schwaber 1995Proceso –framework demanagementComplemento de otrosmétodos, ágiles o noTabla de convergencias y divergencias entre las principales metodologías ágiles.A continuación describiré brevemente algunas de las metodologías ágiles másdestacadas hasta el momento.
  • 7. 3.1 XP- eXtreme ProgrammingXP es la primera metodología ágil y la que le dio conciencia almovimiento actual de metodologías ágiles. De la mano de Kent Beck, XPha conformado un extenso grupo de seguidores en todo el mundo, disparandouna gran cantidad de libros a los que dio comienzo el mismo Beck . InclusiveAddison-Wesley ha creado una serie de libros denominada The XP Series.La imagen mental de Beck al crear XP era la de perillas en un tablero decontrol. Cada perilla representaba una práctica que de su experiencia sabía quetrabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para ver queocurría. Así fue como dio inicio a XP.Evolución de los largos ciclos de desarrollo en cascada (a) a ciclos iterativosmás cortos (b) y a la mezcla que hace XP.XP es una metodología ágil centrada en potenciar las relaciones interpersonalescomo clave para el éxito en el desarrollo de software, promoviendo el trabajo en equipo,preocupándose por el aprendizaje de los desarrolladores, y propiciando un buenclima de trabajo. XP se basa en realimentación continua entre el cliente y el equipode desarrollo, comunicación fluida entre todos los participantes, simplicidad en lassoluciones implementadas y coraje para enfrentar los cambios. XP se define comoespecialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, ydonde existe un alto riesgo técnico. A continuación presentaremos las característicasesenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles,proceso y prácticas.
  • 8. A. Las Historias de UsuarioSon la técnica utilizada para especificar los requisitos del software. Se trata detarjetas de papel en las cuales el cliente describe brevemente las características que elsistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento delas historias de usuario es muy dinámico y flexible. Cada historia de usuario es losuficientemente comprensible y delimitada para que los programadores puedanimplementarla en unas semanas. Beck en su libro [3] presenta un ejemplo de ficha(customer story and task card) en la cual pueden reconocerse los siguientes contenidos:fecha, tipo de actividad (nueva, corrección, mejora), prueba funcional, número dehistoria, prioridad técnica y del cliente, referencia a otra historia previa, riesgo,estimación técnica, descripción, notas y una lista de seguimiento con la fecha, estadocosas por terminar y comentarios. A efectos de planificación, las historias pueden ser deuna a tres semanas de tiempo de programación (para no superar el tamaño deuna iteración). Las historias de usuario son descompuestas en tareas de programación(task card) y asignadas a los programadores para ser implementadas durante unaiteración.B. Roles XPLos roles de acuerdo con la propuesta original de Beck son:- Programador. El programador escribe las pruebas unitarias y produce elcódigo del sistema.- Cliente. Escribe las historias de usuario y las pruebas funcionalespara validar su implementación. Además, asigna la prioridad a lashistorias de usuario y decide cuáles se implementan en cada iteracióncentrándose en aportar mayor valor al negocio.- Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebasfuncionales. Ejecuta las pruebas regularmente, difunde los resultados enel equipo y es responsable de las herramientas de soporte para pruebas.- Encargado de seguimiento (Tracker). Proporciona realimentación alequipo. Verifica el grado de acierto entre las estimaciones realizadas y eltiempo real dedicado, para mejorar futuras estimaciones. Realiza elseguimiento delprogreso de cada iteración.- Entrenador (Coach). Es responsable del proceso global. Debe proveer guíasal equipo de forma que se apliquen las prácticas XP y se siga el procesocorrectamente.- Consultor. Es un miembro externo del equipo con un conocimiento específicoen algún tema necesario para el proyecto, en el que puedan surgir problemas.
  • 9. - Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a queel equipo trabaje efectivamente creando las condiciones adecuadas. Su laboresencial es de coordinación.C. Proceso XPEl ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:1. El cliente define el valor de negocio a implementar.2. El programador estima el esfuerzo necesario para su implementación.3. El cliente selecciona qué construir, de acuerdo con sus prioridades y lasrestricciones de tiempo.4. El programador construye ese valor de negocio.5. Vuelve al paso 1.En todas las iteraciones de este ciclo tanto el cliente como el programadoraprenden. No se debe presionar al programador a realizar más trabajo que el estimado,ya que se perderá calidad en el software o no se cumplirán los plazos. De la mismaforma el cliente tiene la obligación de manejar el ámbito de entrega del producto,para asegurarse que el sistema tenga el mayor valor de negocio posible con cadaiteración.El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación dela Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.D. Prácticas XPLa principal suposición que se realiza en XP es la posibilidad de disminuirla mítica curva exponencial del costo del cambio a lo largo del proyecto, losuficiente para que el diseño evolutivo funcione.Esto se consigue gracias a las tecnologías disponibles para ayudar en el desarrollode software y a la aplicación disciplinada de las siguientes prácticas.El juego de la planificación. Hay una comunicación frecuente el clientey los programadores. El equipo técnico realiza una estimación del esfuerzorequerido para la implementación de las historias de usuario y los clientes decidensobre el ámbito y tiempo de las entregas y de cada iteración.
  • 10. Entregas pequeñas. Producir rápidamente versiones del sistema que seanoperativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versiónya constituye un resultado de valor para el negocio. Una entrega no debería tardarmás 3 meses.Metáfora. El sistema es definido mediante una metáfora o un conjunto demetáforas compartidas por el cliente y el equipo de desarrollo. Una metáfora esuna historia compartida que describe cómo debería funcionar el sistema (conjuntode nombres que actúen como vocabulario para hablar sobre el dominio delproblema , ayudando a la nomenclatura de clases y métodos del sistema).Diseño simple. Se debe diseñar la solución más simple que pueda funcionar y serimplementada en un momento determinado del proyecto.Pruebas. La producción de código está dirigida por las pruebas unitarias. Éstasson establecidas por el cliente antes de escribirse el código y son ejecutadasconstantemente ante cada modificación del sistema.Refactorización (Refactoring). Es una actividad constante de reestructuración del códigocon el objetivo de remover duplicación de código, mejorar su legibilidad, simplificarloy hacerlo más flexible para facilitar los posteriores cambios. Se mejora la estructurainterna del código sin alterar su comportamiento externo.Programación en parejas. Toda la producción de código debe realizarse contrabajo en parejas de programadores. Esto conlleva ventajas implícitas (menor tasade errores, mejor diseño, mayor satisfacción de los programadores, etc.).Propiedad colectiva del código. Cualquier programador puede cambiar cualquier partedel código en cualquier momento.Integración continua. Cada pieza de código es integrada en el sistema una vez que
  • 11. esté lista. Así, el sistema puede llegar a ser integrado y construido varias veces en unmismo día.40 horas por semana. Se debe trabajar un máximo de 40 horas por semana. No setrabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente estáocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo.Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo parael equipo. Éste es uno de los principales factores de éxito del proyecto XP. El clienteconduce constantemente el trabajo hacia lo que aportará mayor valor de negocio ylos programadores pueden resolver de manera inmediata cualquier duda asociada. Lacomunicación oral es más efectiva que la escrita.Estándares de programación. XP enfatiza que la comunicación de los programadoreses a través del código, con lo cual es indispensable que se sigan ciertosestándares de programación para mantener el código legible.Figura Nº2. Las prácticas se refuerzan entre sí.
  • 12. El mayor beneficio de las prácticas se consigue con su aplicación conjunta y equilibradapuesto que se apoyan unas en otras. Esto se ilustra en la Figura Nº 2, donde unalínea entre dos prácticas significa que las dos prácticas se refuerzan entre sí. Lamayoría de las prácticas propuestas por XP no son novedosas sino que en algunaforma ya habían sido propuestas en ingeniería del software e incluso demostradosu valor en la práctica El mérito de XP es integrarlas de una forma efectiva ycomplementarlas con otras ideas desde la perspectiva del negocio, los valores humanos yel trabajo en equipo.Si bien XP es la metodología ágil de más renombre en la actualidad, sediferencia de las demás metodologías que forman este grupo en unaspecto en particular: el alto nivel de disciplina de las personas que participan en elproyecto.Encuesta de IBM (octubre de 2000): ¿Qué opina de eXtreme Programming?
  • 13. 4. ConclusionesNo existe una metodología universal para hacer frente con éxito a cualquierproyecto de desarrollo de software.Las metodologías tradicionales históricamente han intentado abordar la mayorcantidad de situaciones del contexto del proyecto, exigiendo un esfuerzoconsiderable para ser adaptadas, sobre todo en proyectos pequeños y derequisitos cambiantes.Las metodologías ágiles ofrecen una solución casi a medida para una grancantidad de proyectos.Las metodologías ágiles se caracterizan por su sencillez, tanto en suaprendizaje como en su aplicación; sin embargo, gozan tanto de ventajas comode inconvenientes.Las metodologías ágiles permiten a los pequeños grupos de desarrolloconcentrarse en la tarea de construir software fomentando prácticas de fáciladopción y en un entorno ordenado que permiten que los proyectos finalicenexitosamente.Se pueden distinguir dos rangos distintos de conjuntos de metodologías ágiles.XP es una de las metodologías ágiles más extendidas y populares, además esconsiderada como una metodología posmoderna cuyas grandes capacidades segeneran a través de procesos emergentes.
  • 14. 5. Referencias[1]. Pérez S. Jesús, Metodologías Ágiles: La ventaja competitiva de estar preparadopara tomar decisiones lo más tarde posible y cambiarlas en cualquierDisponible en: http://www.spinec.org/wp-content/metodologiasagiles_01.pdf[2]. Acebal F.César, Cueva L. Juan, eXtreme Programming (XP): un nuevo métodode desarrollo de software, Articulo de Novática.Disponible en: http://www.ati.es/novatica/2002/156/156-8.pdf[3]. Letelier P., Penadés C., Metodologías ágiles para el desarrollo de Software:eXtreme Programming (XP), Universidad Politécnica de ValenciaDisponible en: http://www.willydev.net/descargas/masyxp.pdf[4]. Shenone M. Hernán, Diseño de una metodología Ágil de Desarrollo deSoftware, Tesis de Grado en Ingeniería en Informática, Universidad de BuenosAires. Disponible en:http://www.fi.uba.ar/materias/7500/schenonetesisdegradoingenieriainformatica.pdfNOTA: ESTA MONOGRAFIA FUE DESARROLLADA EN BASE A LACONFERENCIA REALIZADA EN ESPAÑA SOBRE METODOLOGIASAGILES EN EL DESARROLLO DEL SOFTWARE-12 de Noviembre de 2003