EAPIS

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

INTRODUCCIÓN Desarrollar un buen software depende de un sinnúmero de actividades y etapas, donde el impacto de elegir la mejor metodología para un equipo, en un determinado proyecto es trascendental para el éxito del producto. el papel preponderante de las metodologías es sin duda esencial en un proyecto y en el paso inicial, que debe encajar en el equipo, guiar y organizar actividades que conlleven a las metas trazadas en el grupo. en el presente trabajo se detallan los dos grandes enfoques, tanto metodologías tradici nales y metodologías o ágiles, se verán diferencias, ventajas, desventajas y cual puede encajar en un proyecto de software, es por ello que, ofrecemos una guía dejando libertad de elección para el lector el poder juzgar y elegir la mejor metodología que se adapte a su equipo de desarrollo. Palabras claves€ metodología, rup, msf aup, scrum, metodología tradicional, metodología ágil El éxito del producto depende en gran parte de la metodología escogida por el equipo, ya sea tradicional o ágil, donde los equipos maximicen su potencial, aumenten la calidad del producto con los recursos y tiempos establecidos.

METODOLOGÍA TRADICIONAL Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que importarse la concepción y fundamentos de metodologías existentes en otras áreas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptación contenía el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software. Entre las principales metodologías tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atención en llevar una documentación exhaustiva de todo el proyecto y centran su atención en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las características importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solución para proyectos donde el entorno es volátil. Las metodologías tradicionales (formales) se focalizan en documentación, planificación y procesos. (Plantillas, técnicas de administración, revisiones, etc.), a continuación se detalla RUP uno de los métodos más usados dentro de los métodos tradicionales

Universidad Nacional De Cajamarca

Página 1

E EAP S li . C t i t i .P t . tili RATI AL I IE PROCESS (RUP) i t i li lt ©¨ i t ti f ll t l i ti Po 987 6 V ntajas y y y y T T T UT T g T T g e Up aYa a Y` X Y` XY Y ` V XY ` dT g dT gddT Tdgq T T g dT g U g Tc g Up U Ti g Y r a Y aY` Y` a a Y VYX a S X a a a Y aY b VXYa a T g g igdc T g Uh XW V S XX Y` a VY XY XY f X VX g g g eT ed c U T T T TU T S a S Y f Y` a f VY Y Y b Ya ` V XY XW V ASES sventajas y l i y E y E t t y N ” ‡€ ‡ €w ‡„‰ wƒ w€ v€ v y „vƒ„‡€v ’ ‚ ‚ ‚ „wƒ‡‰ v„v‰ w v wƒwƒ wx v„ y v „wƒ w w „ „€… wƒ wƒ –v‰v€ „w… „w wƒ w w € ‡„ …wy ‚‚ †‚ ‚ ‚ ’ ‘ ‚ • ‘ ” v„v‰ vƒ‡ € y „w… wƒwy‰ wy  €vy … v y w w w € ‡„ … wy v ‡ƒ w ‡‰ …‡ v … ˆ ‚ ’ ˆ “‚ ‚ ‚ ‚ ‚ ‚ ‚ ˆ …‡ €w ‡„‰ …‡ y v v„v‰ ƒvƒ w vx …w€ ’ ‚ † ‘ v w ‰ ‡€ …w …‡ …w „ wƒ  €vy vxw vu ˆ † ‚ Uni s t R @ rsi t f y C y El y C y T E S E i nal De Cajamar a l i l i l i i t i i i i ill . j ti i i it l i l ti l i l i l l i j t . i t i ti l f I URA1. it i i . i t .B C PB I G F B CCQI PB A F B C I F G AHG B CEDCB A F         ¨  ©   ¨ ©¨©  © 4 5¤ $     3 #               !  ¨ &   ¨ ¨ ¨ 4 § ¨  ¨  ! © ¨ © ©   ( $ #   '    $ #             2   ©  © ¨ ¨ &    ¨ ©¨ ©¨¨ © ¨ © ©  ¨ ¨ !                        ¨© ¨ ¨ © ¨ ¨ ¨     ¨ ©¨ ! ¨ %    ©¨ ¦ ¨ ©   ) (    1    '    0       ¦      ¨ ©¨ ©¨ !     ¨ ©¨ ©¨  ©  © © ¨ © ¨ ¨ &¨ © © ©¨ &         $        "       $ #         ¨ ¨ % © ¨      ¨© ©¨  ¨  ©¨ ¨      ¨  ¨  "                     ©  ©¨ ! © ¨   ©   © ¨ ¨  ¨¨   ©¨   ©¨ §¦ ¥ £ ¤¢ ¡ ¢   P t f i l: P i t i i li i ll . t ll ft ll l ft l. S j ti i i t l i fi l t l S ft . t i t t l ti f l i l t l it t . P ina 2 i . . o Unificado Rational t i i it i t . i i t i ili i li t l fl i i i t ll i l f i t l t : l t li t l j i l.

t l l l i . El i t t i ti t . Modelo de Equipo de MSF ti l l i . t t i i l l l l i t t t il t l l ll l i i . FI URA 2. S j ti li l i t .ˆ † † ˆ ˆ Œ† ‡ ‡ ‰ † † ‘ † ˆ ˆ Œ ™“† † Ž ˆ† Œ † †™ˆ † ˆ ‘ † ˆ ‘ † † ˆ ˆ Œˆ Œ‹ Ž† ™† ˆ • ‡ ‡  ‡ ›  ‡ ‡   ‡  ‡ ‡ ‡ •‡  ‡ ‰ ˆ † † ˆ †‰ˆ Œ† – ‘ ‘ † ˆ ˆ ‘ †™† Œ… š † † †ˆ ˆ ˆ ‰ ˆ ‰‘š †™“ˆ Œ Ÿ‘š ‹Ž ‘“‘Ž Œ‹ Ž† Œˆ“ Ž‘  ‰ ‰  ‡ ‰ ‰  ˜  ›  ‰ • ‡  ‡ ‰ • ‰ ‘ Œ† ˆ ŒˆŒ‘ “‘Ž ‘ ˆ Œ‹ ŽŽ Œ‘ Ž † ˆ ˆ † ‘ †“ † ˆ Ž †ˆ ‘ ’ˆ ˆ ˆ † † ˆ ˆ Œ†  ‡ • ‡  •    • ‡ ‡  ‰ ‰ ž ‡ ‘ Žˆ ‘ ˆ ˆ ™†šˆ Œˆ ˆ Œˆ ˆ ‘ ˆ †“† š‘Œ‘ Ž ‘ ‘Ž ˆ ˆŒ‘ Ž†“ ˆ  • ‰ ‡  ‡  ‰‡   ‡ ‡ ‡ ‰‡ ‰‡ ‘ †™† ˆ ˆŒ† ‘ † † ˆ Œ‹ Ž ‘ † ˆ ‘ ˆ ˆ ‘ ˆŽ‘ ˆ † †ˆ ˆ †Œ‘ ŽŒ ˆŒ‘ Ž†Ž Žˆ ˆ †  ‡ ›  ‡  ‰‡ •‡  • •  ‡‰ ‰ ‡ •  ‡ •‡ ‡ ‰ † † ˆ ‘ ’ˆ † †Œ “ ˆ ˆ ‘ Žˆ ‘ ˆ † † Œ‹ Ž†ˆŒ† † ˆ ˆ † ‘ †“ † ‘ Œ† Ž ˆ ˆ † † ˆ Œˆ  •  • • •   ‡  • • ‡ ‡ ‡ ‰ ‰  •  ‰  ‡ ‘ Žˆ ‘ ˆ ‘š ˆ ˆ † Ž Œ Œ‹ Ž† †Šˆ  • ‰ ‡ ‡  ‰  † † †ˆ ˆ Œˆ ‘ Žˆ ‘ † ˆ ˆ Œˆ™ ˆ ˆ †“ † ˆ † Œ† Ž † † †‘ ˆ Œ‹ Ž Žˆ ˆ † ˆ Œ† › ‡  • ‰   ‡  ‰ ‰ •‡  ‰  ‰ ‡ ‡ ˜ ‡ ‡  › † ‘Š ˆ ™‘ † ˆ“ † Œ†Ž Œˆ ˆ ˆ Œˆ“ †Œ‘ Ž † ‘ Žˆ ‘ ˆ ˆ ™† Œ ‘ ˆ ˆ ˆ ‘ ŒˆŒ ˆ  •  ‡ ‡ ‡ ‡ ‡ •‡   ‡  ‰ ‡ ‰ ‰ ‰ ‡ ‰ ˆ ˆ Œˆ Ž † ‘ ’ˆ ˆ ‘ ‘ † Œ” †Š ‘“ ˆ ’ ‘Œ “ Œˆ ‘ †Ž Œ ˆ † †Ž ˆ ˆ Œˆ Ž ˆ † † † š‘  •  ‡  –  ‰  ‡   •   ‰ ‰ › • † ˆ ’ ˆ ’ ‘ ˆ † † Ž Œ‹ Š †Œ ˆŒˆ ˆ™ˆ ‘ ’ˆ Œ “‘ Ž Œ‹ Š †Œ ˆ ” ˆ ‘ ’ˆ ˆ Œ‹ Ž†Ž Œ     ‰ ‡  ‰ •   ‡ ‡ ‡ ‰  ‰ • ˜ ‰ † ‘ Žˆ ‘ ˆ † † ˆ † Œˆ“† Œ ”“ ‘ ’ˆ ‘ ˆ ‘Œ † † ˆŽŒ†Ž † Œ‹ Š ˆ ˆ † † ˆ ‘ —  • ‰    • ‡ ‡ ‡  ‡  ‡ ‡ – ‰  ‡ ‰ ‰ ‡ … „ x z{ x{ ƒ‚ w x z{ {v w €  ~~{v |} x z{z x{ w v zx{z x v y w | i r l i fn u i f fn fs fh h jo pk o kk j k j kpm p to j f n fnfh fh fn l fn f f ih f e fs fn ir i ln fn n u u n fl ih o gpo mo o m t gk k p go g jop g o o po kk k o d gk j kpm fh f f f f fs fn ir i ln i h if f fl fn nif l ih f e t gqd p p g gk j kpm jop g ook o j goj jqpm g pk go k m kj g d ˜ EAP S — Visión y Alcances: ™ E l Todo proyecto es separado en cinco principales fases: Uni ersi ad Naci nal De Cajamarca Planificación: l l esarrollo: escripción S t ti fi f ifi l l y y y y y i li t t i t i i i Vi i Pl ifi Al i . l . l fi t l l t . t lt l l l . t t t tifi t . El l it t . t œ . l i i l li t . l if i it f . l l i i t l t i f l t l i i i i j t l t i . P ina 3 t t t t ll j . l li li i i i i l t t . t f ifi t i t f i i l l i l li t lí t lti i i i l i t i l i í f t . í i f t i t l i t i . i l l MICROSOFT SOLUTION FRAME ORK (MSF) j i i t i í i f t t l . i . i i l t t l j i l l l t t . ll . t i i t li S ñ t l l . E t ili I l t i .

a continuación se describe el contenido de cada una de las fases y. Documentación.Estrategia Y Alcance En esta fase deberían tener lugar los siguientes trabajos: y Elaboración y aprobación del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participación del mayor número de agentes implicados en el proyecto. Implantaci n: Durante esta fase el equipo implanta la tecnología base y los componentes relacionados. El proyecto ejemplo se trata de una implantación de infraestructuras. y Elaboración del Plan de rabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. en los cuales os miembros l comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que están desarrollando. traspasa el proyecto al personal soporte y operaciones. Logística y oordinación. las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. Los mecanismos y protocolos de intercambio de información y coordinación deben quedar suficientemente bien establecidos y consensuados.EAPIS Estabilizaci En esta fase se conducen pruebas sobre la solución. y obtiene la aprobación final del cliente. en la medida de lo posible. migración a Windows 2000 de una red de servidores. y Formación del Equipo de rabajo y distribución de competencias y responsabilidades: generalmente se definen como áreas principales la de Dise o de Arquitectura. con óvalos del mismo tama o para todos los roles. La comunicación se pone en el centro del círculo para mostrar que está integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicación efectiva y es esencial para el funcionamiento del mismo Ejempl De Met d l gía Msf Aplicada omo ejemplo de una aplicación de metodología MSF a un proyecto. Pruebas de Laboratorio. El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento. número de personas implicadas y perfil de las mismas. ineludiblemente. y Elaboración de la matriz de Riesgos y Plan de ontingencia: los principales riesgos detectados deben tener un plan de mitigación y actuación y revisarse con periodicidad. en concreto. ninguno puede ser l omitido. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas de proyecto. En este documento quedarán definitivamente reflejadas las funcionalidades y servicios que. un detalle de acciones concretas y estimación de carga de trabajo en términos de jornadas. con altos estándares de calidad y deseos de aprender. muestra que no es un modelo jerárquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. la estructura circular del modelo. FASE 1 . M del de r les El modelo de equipos de MSF (MSF team model) fue desarrollado para compensar algunas de las desventajas impuestas por las estructuras jerárquicas de los equipos en los proyectos tradicionales. debe ofrecer la solución a implantar. ada rol puede estar compuestos por una o más personas. omparten una visión común del proyecto y se enfocan en implementar la solución. § ¨ ¨ ¨ ¦ ¦ ££ £ £ ¥ ¤ ¥ ¤ ¥ £ £ £   Universidad Nacional De Cajamarca ¢¡  Página 4 . Para un proyecto de migración a Windows 2000 podría estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervención de un onsultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner. Los equipos organizados bajo este modelo son peque os y multidisciplinarios. estabiliza la instalación.

Es un documento dinámico. al menos en sus líneas principales. y que debe ser revisado y acordado por todas las partes: El cómputo de jornadas para la relación de actividades descritas (que como se observa sólo recogenlas relativas a la Planificación y Dise o. en las propuestas de preventa no se pueden indicar con precisión parámetros como el esfuerzo técnico. supone el principal documento del Proyecto y la culminación de los trabajos de dise o. aprobado por consenso.Planificaci n Y Pr eba De C ncept . el control de incidencias y las métricas de calidad son objetivos a cubrir en este documento. que. y deja aparte las necesarias para elaborar el plan de Migración). tiempo o coste definitivo que puede suponer esta fase. Esta selección se recomienda que se haga atendiendo a la mayor variedad posible de casos. y supone la directriz última de todos los trabajos técnicos. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos. 4 meses)  Jornadas / técnico del PAR ER: 150 jornadas (2 personas)  Jornadas / técnico del LIE E: 110 jornadas (Max. se deberá hacer por acuerdo y conocimiento de todo el equipo de trabajo y se llevará un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones. a partir de ese momento. consultas) y de resolución de problemas y documentación de los mismos (versionado de la plataforma). de atención al usuario (formación. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia. de manera que puedan aflorar el máximo de incidentes potenciales en el menor tiempo posible. el éxito de la prueba piloto dependerá de que se forme un sistema de recogida de incidentes (helpdesk o similar). Los hitos y objetivos fundamentales de esta fase son: ´´ µ ´ ´ ³ ² ¯° °¯ ­ ± y Universidad Nacional De Cajamarca Página 5 » ¹ ¹º ¼ · ¹ ¸ » · y ¶ y Selecci n del ent rn de pr eba pil t : se acordará la composición y ubicación del conjunto de máquinas y usuarios que entrarán en la prueba. 2 personas) FASE 3 ± Estabilizaci n La solución implantada en la maqueta se pasa a un entorno real de explotación. La dimensión de la muestra tiene también que calcularse.EAPIS Deben alcanzarse los siguientes objetivos e hitos: y Documento de Planificación y Dise o de Arquitectura: es el documento principal. y su grado de estabilidad y rendimiento es considerado como "suficiente".Prueba de oncepto: la descripción del contenido del laboratorio de prueba de concepto. sin perder de vista que la prueba piloto no es el despliegue propiamente. los criterios de validez. ¬ ­ ¬ « ª FASE © . deben ser consistentes con esta Guía. De otras experiencias anteriores se puede obtener una relación de trabajos sólo a título orientativo. Habitualmente. sino una fase de observación en la que es absolutamente crítico establecer unos cauces efectivo de tratamiento de s los errores. Este documento se considerará definitivo cuando la solución puesta en marcha se muestre estable y el número de incidencias graves (de intervención o de resolución) sea nulo y la cantidad de las consideradas leves quede por debajo de un límite establecido en las Métricas de alidad. donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. restringido en número de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situación. La aprobación de este documento es el hito principal de esta fase. en el que se recoge la idea y la experiencia práctica al llevarla a cabo en entorno controlado y aislado. Gesti n de Incidencias: aunque esta labor se habrá iniciado en la fase anterior. ofrecería este resultado:  Jornadas totales: 80 (aprox. El documento final. los diversos escenarios a simular. Revisi n de la d c mentaci n final de Ar itect ra: el documento de Planificación y Dise o de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. ® y Documento de Plan de Laboratorio .

las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos. rectificación de errores y obtención de los documentos de formación definitivos. en este caso. funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma. y Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope. a menudo con restricciones no técnicas. con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidas. sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio). estrategia de implantación. además de los obvios (implantación de la plataforma. À ¾ ½ Ã Â ¾ ¿ ½ ¾ Á Ã ½ y y y El tiempo necesario para abordar esta fase es variable y depende en parte de factores ajenos a la complejidad de la propia solución. la complejidad del proceso de migración. Elaboraci n del Plan de Formaci n: con anterioridad al despliegue definitivo. fechas. procedimientos de validación y método de control de incidencias. Ä Ä FASE 4 ± Desplieg e Se llevarán a cabo en esta fase los planes dise a dos en la anterior. incluyendo mejoras aportadas por los fabricantes de s oftware (nuevas versiones o Service Packs. Los factores más relevantes en el cálculo suelen ser la dispersión o concentración geográfica. no puede establecerse a priori. y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue. entrega del Proyecto y cierre del mismo. por ejemplo) y Revisión de las Guías y manuales de usuario. de Administración. y Finalmente. clasificación. formación a los usuarios y administradores). En el Plan deben identificarse las fases. en esta fase deben elaborarse las Guías de Usuario. puesta en servicio de todas las funciones. y otros cuyos contenidos deben acordarse previamente. la experiencia y nivel de los técnicos que realizan la operación y condicionantes de calendario. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad política o de negocio) que pueden retardar o acelerar la conclusión. como es la adecuada selección del entorno de prueba y el momento del a o en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo críticas como Fin de A o). Los principales trabajos e hitos a conseguir son. principalmente el de despliegue y el de formación. y las condiciones de calidad que debe cumplir la solución final para iniciar el despliegue. Ä Æ Å Universidad Nacional De Cajamarca Página 6 . tareas a realizar. y Revisión (si procede) de la matriz de riesgos. puesto que debe planificarse. las "paso-a-paso". resolución y distribución de faxes o intervención on-site. En proyectos de similar envergadura se ha llegado al momento "Error Free Versión" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios. La experiencia demuestra que no hay una relación directa entre número de máquinas y tiempo necesario para el despliegue. Elaboraci n del Plan de Desplieg e: se debe consensuar la fecha de finalización de la fase Piloto. debe haberse aprobado el Plan de Formación orientado a usuarios finales y ad ministradores.EAPIS Elab raci n de la d c mentaci n de F r maci n Operaciones: con vistas al soporte post proyecto y los programas de formación a usuarios y administradores. los siguientes: y ontinuación con las labores de recepción de incidencias. y Registro de mejoras y sugerencias. La duración fase de despliegue. el grado de automatización alcanzado. tratamiento.

AUP entre otras. Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. Iconix. Reduce el número de cambios necesario en el proyecto. Ë Ê Retrasar las decisiones Planificaci n Adaptativa Es el eje en cual gira la metodología ágil. el retrasar las decisiones y la planificación adaptativa. estaremos transformando el proyecto en un conjunto de proyectos peque os. métodos ágiles. os lo proponen porque para muchos clientes esta flexibilidad será una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste. lo cual permite siempre mantener una satisfacción en el cliente y por ende el éxito del producto. La capacidad de respuesta ante un cambio es más importante que el seguimiento estricto de un plan. además hacer una planificación adaptatva consiste en tomar decisiones a lo largo del i proyecto. Ç omo resultado de esta nueva teoría se crea un Manifiesto Ágil cuyas principales ideas son: y y y y Los individuos y las interacciones entre ellos son más importantes que las herramientas y los procesos empleados. ristal Methods. Esta planificación a corto plazo nos permitirá tener software disponible para nuestros clientes y además ir aprendiendo del feedback para hacer nuestra planificación más sensible. La colaboración con el cliente debe prevalecer sobre la negociación de contratos. A continuación se detalla el XP que es el más aceptado dentro del desarrollo de SW Ì Universidad Nacional De Cajamarca É Página 7 . Luego de varias opiniones tanto a favor como en contra de las metodologías tradicionales se genera un nuevo enfoque denominado. Scrum. las principales ventajas de retrasar las decisiones son:    Reduce el número de decisiones de alta inversión que se toman. Reduce el coste del cambio La planificación adaptativa permite estar preparados para el cambio ya que lo hemos introducido en nuestro proceso de desarrollo. È Entre los principales métodos ágiles tenemos el XP (eXtreme Programming). permitiendo potencia aún más el desarrollo de software a gran escala. Es más importante crear un producto software que funcione que escribir documentación exhaustiva.EAPIS METODOLOGÍAS ÁGILES. el retrasar las decisiones tan como sea posible de manera responsable será ventajoso tanto para el cliente como para la empresa. que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales. sea ante inconvenientes que aceleren o retrasen nuestro producto.

EAP S Í EXTREME PROGRAMMING (XP) E E EXT E E P Þ Þ Úï ã æì Þ Þ Þ ÚÚ Û ß â Û çß ß Û Û çí î îÛ âÛ Û Û çß ÚÝ á æì ã Ú á Þ ã Ú äá áÞá Ú Þ ã Þ Ú ãë ê ãäáã Ü ßç â ß çß ß çßÜ Ûâ àç â ß Ûç à Û Û ßÜ Û ß Û àçß ß ß ÛÜß ß ç àÛÜÛ â é è ãá Þ æ ãá áÚ Þ á áãã Ú Þ Þ Ú äÝ Ú áÚ áã Ú á Þ Þ Ú Þ ÚÝ Ú ã Û àß çß â Û Û Ü ß Û ß ß ß ßà â ß Û ÛàÛ ß Ü Û ß Ûå E l t l il f i i l t if i l t i t ili l i i ili ll l Úá Ú æì ã Úá ß Úá Úá ã áã á Ú æ Ú Þ Úáòã æ Ú ã ã ï á ñ áã Þ áò á Úá Ú æì ã Úá ÚáÞá ã Þ çß Û ç à çß í â ß ß ß ß ç ß àß â ß çß Ü à Û ß ç ß îÜÛ à ã æì Ú ã ÚÝ ñ ãá ê ë áã æÚ á ñáã Þ Þï Þ á æ ã æì æ Úá Ú æì ã Þ Û çß ç ß Û Ûß Ü ßÜ ç àÛÜ âÛ Ûç ß àß â ß Û Û ß ç â ß Û à çß ß ß Úá Úá Úã Þ Þ ò ã Ú æì ã Úá ñáã Þ á áãã Ú Þ Þ Ú Þ áÚæ ï Û ß Û âÛ Û ß Û âÛ à ß ß çßß àß â ß Û ß ß ß îÛ ß ß àç ß ß îÛ ßç îÜÛà ãæ á Ú æ áÚ ð ã ã áÚ Úá Ú æì ã Þ Úá Úá æ ì ã ÞÚ á Þ Ú ãáÚ Þ Úáé Û Ûç àß â Û ç ç Û à ÛÜ Û ß î ß ß ß çÛ ß ç à ß ß çß ß îÜÛ à f XP l i l i l it l i i it l l l fi i t l i it . Pro ramación por parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. i i l t . acer entregas frecuentes. Se supone que la mayor calidad del código escrito de esta manera el código es revisado y discutido mientras se escribe es más importante que la posible pérdida de productividad inmediata. i it l t t l. as pruebas an de garanti ar que en la refactori ación no se a introducido ningún fallo. Corrección de todos los errores antes de añadir nueva funcionalidad. Se aconseja escribir el código de la prueba antes de la codificación. unas t as t a s. reescribir ciertas par del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. a programación extrema apuesta que en más sencillo acer algo simple y tener un poco de trabajo extra para ca mbiarlo si se requiere. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Cuando todo funcione se podrá añadir funcionalidad si es necesario. es decir. t . i i it t l i l l i y y y y y Uni ersidad Naci nal De Cajamarca P ina 8 ÿ ¤ £   ¢ ¦ ¥ £ ¡ ¤ þ y ü ÷ û ÷ ú ø y y t í ti f t l l t : Desarrollo iterativo e incremental: pequeñ ej . tes Refactori ación del código.C ti t l i t i i j t i f t l li t l i t t i § . Simplicidad en el código: es la mejor manera de que las cosas funcionen. A IN Ó Õ Ô Ö ÕÔ ÞÚ Þ æ Ú Úã ã Ú é ß Û çßÜÛ ç Ûà ß àÛ Û à Û íÜ ß l í ll t i i ft l f l K t B . que realizar algo complicado y quizás nunca utilizarlo. Propiedad del código compartida en vez de dividir la responsabil dad en el desarrollo de cada : i módulo en grupos de trabajo distintos. incluyendo pruebas de regresi n. Frecuente interacción del equipo de programación con el cliente o usuario. ö ù ø ÷ ôó ö õ ôó ç áÚ áÞá ý Ù ØØ ×ÙÔ× Ø × ÑÐ Î Ò Ï I A . este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Pruebas unitarias continuas. as frecuentes pruebas de regresión garantizan que los posibles errores serán detectados. f ecuentemente epeti as aut mati adas.

lo que lleva a una comunicación más completa.EAP S a simplicidad y la comunicación son extraordinariamente complementarias. significa reducir su coste. a presión esta a lo largo de todo el proyecto y no en una entrega final y Desventajas y elimitar el alcance del proyecto con nuestro cliente y y y Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en laexperiencia. Esquema de trabajo A P El A P es un acercamiento aerodinámico a desarrollo del soft are basado en el Proceso nificado ational de IB P . menos tendrá que comunicar sobre este. basado en disciplinas y entregables incrementalescon el tiempo. especialmente si se puede reducir el equipo de programadores. Vital para su negocio y Permitirá definir en cada iteración cuales son los objetivos de la siguiente y Permite tener realimentación de los usuarios muy útil. as disciplinas de Aup son: y odelado y Implementación y Prueba y espliegue y Administración de la configuración y Administración o gerencia del Proyecto y Entorno Uni ersidad Naci nal De Cajamarca P ina 9 ¨  %        $ !# " &  '   ! © . Planificación más transparente para nuestros clientes. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe acer. AUP (AGIL UNIFIED PROCESS) I A . Ventajas Apropiado paraentornosvolátiles Estar preparados para el cambio. conocen las fechas de entrega de funcionalidades. i entrasmás simple es el sistema. El ciclo de vida en proyectos grandes es serial mientras que en los pequeños es iterativo.

Por otro lado. los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo. En Scrum. por ejemplo en un mercado de alta competitividad. maximizando la utilidad de lo que se construye y el retorno de invers ión. as iteraciones en general tienen una duración entre y semanas. auto-gestión e innovación. Se busca que los equipos sean lo más efectivos y productivos posible. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteración a iteración y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. adaptación. qué no y en qué orden) y en remover cualquier obstácul que pudiera entorpecer la o tarea del equipo de desarrollo. el equipo se focaliza en una única cosa: construir soft are de calidad. e es forma se puede adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. la gestión de un proyecto Scrum se focaliza en definir cuales son las características que debe tener el producto a construir qué construir. Esquema de trabajo SC ( A@ 6 3 21 0 ) 5 7 5 6 . Cada ciclo o iteración termina con una pieza de soft are ejecutable que incorpora nueva iliza como funcionalidad. aumentando la satisfacción del cliente. El desarrollo se realiza en forma iterativa e incremental una iteración es un ciclo corto de construcción repetitivo). os requerimientos y las ta prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. Scrum se ut marco para otras prácticas de ingeniería de soft are como P o Extreme Programming. Por el otro lado. Se busca entregar soft are que realmente resuelva las necesidades. Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua. Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio. Uni ersidad Naci nal De Cajamarca P ina 10 5 B 7 9 8 5 5 4 12 I A . Está diseñado especialmente para adaptarse a los cambios en los requerimientos.EAP S SCRUM Scrum es un proceso ágil y liviano que sirve para administrar y controlar el desarrollo de soft are.

a i gura 6 muestra el cuadro del proceso. el proceso se queda igual a la visión original de acobson del manejo de casos de uso. También es relativamente pequeño y firme. que incluye un juego mínimo de diagramas de y algunas valiosas técnicas que se toman de los casos del uso para codificar rápida y eficazmente. El enfoque es flexible y abierto. Uni ersidad Naci nal De Cajamarca P ina 11 HGF C FE V U H S FE RQ P I HGF T HGF D . El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del soft are. pero le falta mucho para llegar al nivel del P. específico y casos de uso fácilmente entendible.EAP S ICONIX El proceso de IC NIX maneja casos de uso. Este proceso también hace uso aerodinámico del mientras guarda un enfoque afilado en el seguimiento de requisitos. siempre se puede seleccionar de los otros aspectos del para complementar los materiales básicos. I A 6. como el P. como XP. que un equipo de unproyecto puede usar para conducir el esfuerzo hacia un desarrollo real. pero no desecha el análisis y diseño que hace XP. Esquema de trabajo IC NIX Y. esto produce un resultado concreto.

TABLA 2.EAPIS Diferencias: Metodologías Tradicionales Metodologías Agiles Basadas en normas provenientes de estándares Basadas en heurísticas provenientes de prácticas seguidos por el entorno de desarrollo de producción de código ierta resistencia a los cambios Especialmente preparados para cambios durante el proyecto Impuestas externamente Impuestas internamente (por el equipo) Proceso mucho más controlado. con numerosas Proceso menos controlado. con pocos principios. XW XW IO ALES Y ÁGILES ` Y los MODELOS AGILES Página 12 .olaboración: empoderamiento +auto-organización odificación Pruebas Puesta en Producción Universidad Nacional De Cajamarca Y ` W DIFERE IAS POR ETAPAS Y E FOQUE METODOLOGI O Planificación adpatativa:Entregas frecuentes + colaboración del cliente X ` ` a Y W DIFERE IAS E T RE METODOLOGÍA TRADI W X TABLA 1. políticas/normas El cliente interactúa con el equipo de desarrollo El cliente es parte del equipo de desarrollo mediante reuniones Más artefactos Pocos artefactos Más roles Pocos roles Grupos grandes y posiblemente distribuidos Grupos peque os (<10 integrantes) y trabajando en el mismo sitio La arquitectura del software es esencial y se Menos énfasis en la arquitectura del software expresa mediante modelos Existe un contrato prefijado o existe contrato tradicional o al menos es bastante flexible Ofrecemos una comparativa entre cada uno de las etapas más comunes del desarrollo de SW y enfoques de metodologías revisados. ETAPA Análisis de requerimientos Planificación predictiva y ³aislada´ Planificación Dise o flexible y Extensible + modelos + Documentación exhaustiva Desarrollo individual con Roles y responsabilidades estrictas Actividades de control]: Orientado a los hitos + Gestión miniproyectos Dise o MODELOS RIGUROSOS Dise o Simple: Documentación Mínima + Focalizado en la comunicación Transferencia de conocimiento: Programación en pares + conocimiento colectivo Liderazgo.

donde los requisitos no se conocen con exactitud. mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.EAPIS Además presentamos un cuadro de comparación por cada aspecto analizado y lo ponemos a consideración:  Por las características del Proyecto RUP I O IX XP Medio / Extenso Peque o / Medio Medio / Extenso Peque o / Medio Peque o / Medio Medio / Alto Medio / Alto S RUM Pe eño / Medio Pe En este cuadro se presenta una comparativa de las modelos de proceso en cuanto a lascaracterísticas del proyecto. facilitando aplicar con mayor efectividad esta metodología. altamente motivados y con gran innovación Las metodologías ágiles permiten disminuir costos y brindar flexibilidad a los proyectos de software donde la incertidumbre está presente El uso de metodologías tradicionales es esencial al inicio en un equipo de desarrollo de software Las metodologías ágiles se deberían aplicar en proye ctos donde exista mucha incertidumbre donde el entorno es volátil. ya que la experiencia es la que predomina en los mementos cruciales del proyecto. permitiendo aprovecharla al máximo C ONCLUSIONES y y El retrasar las decisiones en un proyecto de software permite potenciar el valor del producto tanto para el cliente como al equipo o empresa que desarrolla Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia trabajando con metodologías tradicionales.  Por la curva de Aprendizaje on respecto a la curva de aprendizaje. ya que aún no hay sido explotadas a gran escala como lo es RUP que posee alto soporte y herramientas integrales que nos guían a través del mismo. analizamos el tama o del proceso. nos ofrecen una mayor ventaja pero con ciertas limitaciones. y y y Universidad Nacional De Cajamarca g g RUP I O IX XP S RUM Lenta Rápida Rápida Rápida Alto Soporte Algún Soporte Disponible o mencionado o mencionado e d Modelo de Proceso C rva de aprendizaje b ih ih c b ih ih Pe eño / Medio Pe eño eño Herramienta de integraci n r ih modelo de Proceso Tamaño del Proceso Tamaño del E ipo Complejidad del Problema Medio / Alto r r q p g f p f Soporte Externo Alto Soporte Algún Soporte Disponible Algún Soporte Disponible Algún Soporte Disponible f Página 13 . Podemos resaltar que: con un peque o equipo de desarrollo se puede realizar grandes proyectos. de alta complejidad. además debe tener la capacidad de ser equipos auto -gestionados. vemos que los modelos ágiles. es el caso de XP y S RUM. del equipo y la complejidad del problema para cada uno de los modelos.

com I O IX (En línea). Disponible en: www.com/msf. (en línea).pdf Metodologías ágiles (En línea) .pdf Extreme Programming Refactored: The ase Against XP.agile-spain.org/wpcontent/metodologiasagiles_01.XProgramming. MATT Stephens and DOUG Rosenberg.asp?p=16790 &rl=1 www.EAPIS BIBLIOGRAFÍA        Metodologías Ágiles: La ventaja competitiva de estar preparado para tomar decisiones lo más tarde posible y cambiarlas en cualquier momento.org/wp-content/ICONIX. (En línea). Disponible en: www.com/articles/article.aspx Universidad Nacional De Cajamarca v u t s Página 14 . disponible en http://www. Disponible en Formato chm Introducción a Iconix (En línea).spinec.com Microsoft Solution Framework.Disponible en:http://www.Disponibleen: http://www.gpicr.spinec.informit.

Sign up to vote on this title
UsefulNot useful