P. 1
METODOLOGÍAS DE DESARROLLO DE SOFTWARE

METODOLOGÍAS DE DESARROLLO DE SOFTWARE

|Views: 1.326|Likes:

More info:

Published by: Cristhian Gamboa Fernandez on Jan 18, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

07/26/2013

pdf

text

original

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

i t i ti l f I URA1. j ti i i it l i l ti l i l i l l i j t . P ina 2 i .E EAP S li .P t . o Unificado Rational t i i it i t . . C t i t i . S j ti i i t l i fi l t l S ft . t ll ft ll l ft l.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 . it i i . i 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 . 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 i t t l ti f l i l t l it t .

l fi t l l t . ll .ˆ † † ˆ ˆ Œ† ‡ ‡ ‰ † † ‘ † ˆ ˆ Œ ™“† † Ž ˆ† Œ † †™ˆ † ˆ ‘ † ˆ ‘ † † ˆ ˆ Œˆ Œ‹ Ž† ™† ˆ • ‡ ‡  ‡ ›  ‡ ‡   ‡  ‡ ‡ ‡ •‡  ‡ ‰ ˆ † † ˆ †‰ˆ Œ† – ‘ ‘ † ˆ ˆ ‘ †™† Œ… š † † †ˆ ˆ ˆ ‰ ˆ ‰‘š †™“ˆ Œ Ÿ‘š ‹Ž ‘“‘Ž Œ‹ Ž† Œˆ“ Ž‘  ‰ ‰  ‡ ‰ ‰  ˜  ›  ‰ • ‡  ‡ ‰ • ‰ ‘ Œ† ˆ ŒˆŒ‘ “‘Ž ‘ ˆ Œ‹ ŽŽ Œ‘ Ž † ˆ ˆ † ‘ †“ † ˆ Ž †ˆ ‘ ’ˆ ˆ ˆ † † ˆ ˆ Œ†  ‡ • ‡  •    • ‡ ‡  ‰ ‰ ž ‡ ‘ Žˆ ‘ ˆ ˆ ™†šˆ Œˆ ˆ Œˆ ˆ ‘ ˆ †“† š‘Œ‘ Ž ‘ ‘Ž ˆ ˆŒ‘ Ž†“ ˆ  • ‰ ‡  ‡  ‰‡   ‡ ‡ ‡ ‰‡ ‰‡ ‘ †™† ˆ ˆŒ† ‘ † † ˆ Œ‹ Ž ‘ † ˆ ‘ ˆ ˆ ‘ ˆŽ‘ ˆ † †ˆ ˆ †Œ‘ ŽŒ ˆŒ‘ Ž†Ž Žˆ ˆ †  ‡ ›  ‡  ‰‡ •‡  • •  ‡‰ ‰ ‡ •  ‡ •‡ ‡ ‰ † † ˆ ‘ ’ˆ † †Œ “ ˆ ˆ ‘ Žˆ ‘ ˆ † † Œ‹ Ž†ˆŒ† † ˆ ˆ † ‘ †“ † ‘ Œ† Ž ˆ ˆ † † ˆ Œˆ  •  • • •   ‡  • • ‡ ‡ ‡ ‰ ‰  •  ‰  ‡ ‘ Žˆ ‘ ˆ ‘š ˆ ˆ † Ž Œ Œ‹ Ž† †Šˆ  • ‰ ‡ ‡  ‰  † † †ˆ ˆ Œˆ ‘ Žˆ ‘ † ˆ ˆ Œˆ™ ˆ ˆ †“ † ˆ † Œ† Ž † † †‘ ˆ Œ‹ Ž Žˆ ˆ † ˆ Œ† › ‡  • ‰   ‡  ‰ ‰ •‡  ‰  ‰ ‡ ‡ ˜ ‡ ‡  › † ‘Š ˆ ™‘ † ˆ“ † Œ†Ž Œˆ ˆ ˆ Œˆ“ †Œ‘ Ž † ‘ Žˆ ‘ ˆ ˆ ™† Œ ‘ ˆ ˆ ˆ ‘ ŒˆŒ ˆ  •  ‡ ‡ ‡ ‡ ‡ •‡   ‡  ‰ ‡ ‰ ‰ ‰ ‡ ‰ ˆ ˆ Œˆ Ž † ‘ ’ˆ ˆ ‘ ‘ † Œ” †Š ‘“ ˆ ’ ‘Œ “ Œˆ ‘ †Ž Œ ˆ † †Ž ˆ ˆ Œˆ Ž ˆ † † † š‘  •  ‡  –  ‰  ‡   •   ‰ ‰ › • † ˆ ’ ˆ ’ ‘ ˆ † † Ž Œ‹ Š †Œ ˆŒˆ ˆ™ˆ ‘ ’ˆ Œ “‘ Ž Œ‹ Š †Œ ˆ ” ˆ ‘ ’ˆ ˆ Œ‹ Ž†Ž Œ     ‰ ‡  ‰ •   ‡ ‡ ‡ ‰  ‰ • ˜ ‰ † ‘ Žˆ ‘ ˆ † † ˆ † Œˆ“† Œ ”“ ‘ ’ˆ ‘ ˆ ‘Œ † † ˆŽŒ†Ž † Œ‹ Š ˆ ˆ † † ˆ ‘ —  • ‰    • ‡ ‡ ‡  ‡  ‡ ‡ – ‰  ‡ ‰ ‰ ‡ … „ 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 . t t i i l l l l i t t t il t l l ll l i i . l . t t t tifi t . t œ . l l i i t l t i f l t l i i i i j t l t i . t i i t li S ñ t l l . S j ti li l i t . t l l l i . i . E t ili I l t i . P ina 3 t t t t ll j . l if i it f . FI URA 2. í i f t i t l i t i . i i l t t l j i l l l t t . l i i l li t . t lt l l l . 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 l l MICROSOFT SOLUTION FRAME ORK (MSF) j i i t i í i f t t l . Modelo de Equipo de MSF ti l l i . El i t t i ti t . El l it t .

en la medida de lo posible. El proyecto ejemplo se trata de una implantación de infraestructuras. ninguno puede ser l omitido. la estructura circular del modelo. en concreto. FASE 1 . traspasa el proyecto al personal soporte y operaciones. En este documento quedarán definitivamente reflejadas las funcionalidades y servicios que. y obtiene la aprobación final del cliente. 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. a continuación se describe el contenido de cada una de las fases y.EAPIS Estabilizaci En esta fase se conducen pruebas sobre la solución. y Elaboración del Plan de rabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Logística y oordinación. omparten una visión común del proyecto y se enfocan en implementar la solución. La comunicación se pone en el centro del círculo para mostrar que está integrada en la estructura y fluye en todas direcciones. ineludiblemente. Pruebas de Laboratorio. Implantaci n: Durante esta fase el equipo implanta la tecnología base y los componentes relacionados. Los equipos organizados bajo este modelo son peque os y multidisciplinarios. 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. Documentación. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento. las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. 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. El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. número de personas implicadas y perfil de las mismas. muestra que no es un modelo jerárquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. con altos estándares de calidad y deseos de aprender. § ¨ ¨ ¨ ¦ ¦ ££ £ £ ¥ ¤ ¥ ¤ ¥ £ £ £   Universidad Nacional De Cajamarca ¢¡  Página 4 . debe ofrecer la solución a implantar. Los mecanismos y protocolos de intercambio de información y coordinación deben quedar suficientemente bien establecidos y consensuados. 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. migración a Windows 2000 de una red de servidores. estabiliza la instalación. con óvalos del mismo tama o para todos los roles.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. en los cuales os miembros l comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que están desarrollando. un detalle de acciones concretas y estimación de carga de trabajo en términos de jornadas. ada rol puede estar compuestos por una o más personas. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas de proyecto. 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.

Planificaci n Y Pr eba De C ncept . aprobado por consenso. sino una fase de observación en la que es absolutamente crítico establecer unos cauces efectivo de tratamiento de s los errores. y deja aparte las necesarias para elaborar el plan de Migración). tiempo o coste definitivo que puede suponer esta fase. La aprobación de este documento es el hito principal de esta fase. 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. el éxito de la prueba piloto dependerá de que se forme un sistema de recogida de incidentes (helpdesk o similar). 4 meses)  Jornadas / técnico del PAR ER: 150 jornadas (2 personas)  Jornadas / técnico del LIE E: 110 jornadas (Max. de atención al usuario (formación. supone el principal documento del Proyecto y la culminación de los trabajos de dise o. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia. Esta selección se recomienda que se haga atendiendo a la mayor variedad posible de casos. ofrecería este resultado:  Jornadas totales: 80 (aprox. de manera que puedan aflorar el máximo de incidentes potenciales en el menor tiempo posible. 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. restringido en número de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situación. Gesti n de Incidencias: aunque esta labor se habrá iniciado en la fase anterior.EAPIS Deben alcanzarse los siguientes objetivos e hitos: y Documento de Planificación y Dise o de Arquitectura: es el documento principal. ® y Documento de Plan de Laboratorio . al menos en sus líneas principales. el control de incidencias y las métricas de calidad son objetivos a cubrir en este documento. Habitualmente.Prueba de oncepto: la descripción del contenido del laboratorio de prueba de concepto. 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. 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. La dimensión de la muestra tiene también que calcularse. que. sin perder de vista que la prueba piloto no es el despliegue propiamente. Es un documento dinámico. consultas) y de resolución de problemas y documentación de los mismos (versionado de la plataforma). en el que se recoge la idea y la experiencia práctica al llevarla a cabo en entorno controlado y aislado. y supone la directriz última de todos los trabajos técnicos. ¬ ­ ¬ « ª FASE © . donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. y su grado de estabilidad y rendimiento es considerado como "suficiente". los diversos escenarios a simular. El documento final. 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. a partir de ese momento. 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. en las propuestas de preventa no se pueden indicar con precisión parámetros como el esfuerzo técnico. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos. los criterios de validez. 2 personas) FASE 3 ± Estabilizaci n La solución implantada en la maqueta se pasa a un entorno real de explotación.

La experiencia demuestra que no hay una relación directa entre número de máquinas y tiempo necesario para el despliegue. procedimientos de validación y método de control de incidencias. las métricas de calidad y establecimiento de los estándares de calidad y SLA definitivos. principalmente el de despliegue y el de formación. y otros cuyos contenidos deben acordarse previamente. 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. Elaboraci n del Plan de Formaci n: con anterioridad al despliegue definitivo. las "paso-a-paso". sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio). y debe hacerse compatible con los ritmos acordados en el Plan de Despliegue. y Revisión (si procede) de la matriz de riesgos. la experiencia y nivel de los técnicos que realizan la operación y condicionantes de calendario. la complejidad del proceso de migración. y Registro de mejoras y sugerencias. À ¾ ½ Ã Â ¾ ¿ ½ ¾ Á Ã ½ 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. y las condiciones de calidad que debe cumplir la solución final para iniciar el despliegue. formación a los usuarios y administradores). en este caso. y Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope. Ä Æ Å Universidad Nacional De Cajamarca Página 6 . puesto que debe planificarse. con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidas. fechas. tareas a realizar. de Administración. no puede establecerse a priori. además de los obvios (implantación de la plataforma. 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. tratamiento. el grado de automatización alcanzado. puesta en servicio de todas las funciones. incluyendo mejoras aportadas por los fabricantes de s oftware (nuevas versiones o Service Packs. debe haberse aprobado el Plan de Formación orientado a usuarios finales y ad ministradores. Ä Ä FASE 4 ± Desplieg e Se llevarán a cabo en esta fase los planes dise a dos en la anterior. en esta fase deben elaborarse las Guías de Usuario. Los factores más relevantes en el cálculo suelen ser la dispersión o concentración geográfica. 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). estrategia de implantación. resolución y distribución de faxes o intervención on-site.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. clasificación. entrega del Proyecto y cierre del mismo. por ejemplo) y Revisión de las Guías y manuales de usuario. a menudo con restricciones no técnicas. y Finalmente. La duración fase de despliegue. rectificación de errores y obtención de los documentos de formación definitivos. Elaboraci n del Plan de Desplieg e: se debe consensuar la fecha de finalización de la fase Piloto. funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma. Los principales trabajos e hitos a conseguir son. los siguientes: y ontinuación con las labores de recepción de incidencias. En el Plan deben identificarse las fases.

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. el retrasar las decisiones y la planificación adaptativa. sea ante inconvenientes que aceleren o retrasen nuestro producto. además hacer una planificación adaptatva consiste en tomar decisiones a lo largo del i proyecto. Es más importante crear un producto software que funcione que escribir documentación exhaustiva. que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales. Iconix. Ë Ê Retrasar las decisiones Planificaci n Adaptativa Es el eje en cual gira la metodología ágil. Ç 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. AUP entre otras. las principales ventajas de retrasar las decisiones son:    Reduce el número de decisiones de alta inversión que se toman. ristal Methods. 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. Reduce el número de cambios necesario en el proyecto. 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. os lo proponen porque para muchos clientes esta flexibilidad será una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste. La colaboración con el cliente debe prevalecer sobre la negociación de contratos. permitiendo potencia aún más el desarrollo de software a gran escala. el retrasar las decisiones tan como sea posible de manera responsable será ventajoso tanto para el cliente como para la empresa. estaremos transformando el proyecto en un conjunto de proyectos peque os. 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. 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.EAPIS METODOLOGÍAS ÁGILES. È Entre los principales métodos ágiles tenemos el XP (eXtreme Programming). Scrum. métodos ágiles.

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 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 . Pruebas unitarias continuas. f ecuentemente epeti as aut mati adas. Simplicidad en el código: es la mejor manera de que las cosas funcionen. 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. tes Refactori ación del código. i it l t t l.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 .C ti t l i t i i j t i f t l li t l i t t i § . A IN Ó Õ Ô Ö ÕÔ ÞÚ Þ æ Ú Úã ã Ú é ß Û çßÜÛ ç Ûà ß àÛ Û à Û íÜ ß l í ll t i i ft l f l K t B . acer entregas frecuentes. as frecuentes pruebas de regresión garantizan que los posibles errores serán detectados. Frecuente interacción del equipo de programación con el cliente o usuario. este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. i i l t . Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Corrección de todos los errores antes de añadir nueva funcionalidad. Cuando todo funcione se podrá añadir funcionalidad si es necesario. es decir. 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. 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. que realizar algo complicado y quizás nunca utilizarlo. ö ù ø ÷ ôó ö õ ôó ç áÚ áÞá ý Ù ØØ ×ÙÔ× Ø × ÑÐ Î Ò Ï I A . reescribir ciertas par del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. unas t as t a s. incluyendo pruebas de regresi n. t . as pruebas an de garanti ar que en la refactori ación no se a introducido ningún fallo. Se aconseja escribir el código de la prueba antes de la codificación.

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 ¨  %        $ !# " &  '   ! © . menos tendrá que comunicar sobre este. conocen las fechas de entrega de funcionalidades. basado en disciplinas y entregables incrementalescon el tiempo. 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. 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 . 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. lo que lleva a una comunicación más completa. AUP (AGIL UNIFIED PROCESS) I A . 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. significa reducir su coste. i entrasmás simple es el sistema. Ventajas Apropiado paraentornosvolátiles Estar preparados para el cambio.EAP S a simplicidad y la comunicación son extraordinariamente complementarias. especialmente si se puede reducir el equipo de programadores. El ciclo de vida en proyectos grandes es serial mientras que en los pequeños es iterativo.

e es forma se puede adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. En Scrum. auto-gestión e innovación. Scrum tiene un conjunto de reglas muy pequeño y muy simple y está basado en los principios de inspección continua. 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. adaptación. 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. as iteraciones en general tienen una duración entre y semanas. Uni ersidad Naci nal De Cajamarca P ina 10 5 B 7 9 8 5 5 4 12 I A . maximizando la utilidad de lo que se construye y el retorno de invers ión. Se busca entregar soft are que realmente resuelva las necesidades. Se busca que los equipos sean lo más efectivos y productivos posible. por ejemplo en un mercado de alta competitividad. 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. el equipo se focaliza en una única cosa: construir soft are de calidad. 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. Por el otro lado. El desarrollo se realiza en forma iterativa e incremental una iteración es un ciclo corto de construcción repetitivo). Scrum se ut marco para otras prácticas de ingeniería de soft are como P o Extreme Programming. Por otro lado. os requerimientos y las ta prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio. Esquema de trabajo SC ( A@ 6 3 21 0 ) 5 7 5 6 . qué no y en qué orden) y en remover cualquier obstácul que pudiera entorpecer la o tarea del equipo de desarrollo. 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.

I A 6. como el P. Esquema de trabajo IC NIX Y. pero le falta mucho para llegar al nivel del P. 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. que un equipo de unproyecto puede usar para conducir el esfuerzo hacia un desarrollo real. El diagrama retrata la esencia del enfoque aerodinámico al desarrollo del soft are. específico y casos de uso fácilmente entendible. El enfoque es flexible y abierto. como XP. pero no desecha el análisis y diseño que hace XP. a i gura 6 muestra el cuadro del proceso. siempre se puede seleccionar de los otros aspectos del para complementar los materiales básicos. Este proceso también hace uso aerodinámico del mientras guarda un enfoque afilado en el seguimiento de requisitos.EAP S ICONIX El proceso de IC NIX maneja casos de uso. 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. Uni ersidad Naci nal De Cajamarca P ina 11 HGF C FE V U H S FE RQ P I HGF T HGF D . esto produce un resultado concreto.

con numerosas Proceso menos controlado. 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. TABLA 2. 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.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 pocos principios.

mientras que las metodologías tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto. nos ofrecen una mayor ventaja pero con ciertas limitaciones. analizamos el tama o del proceso. de alta complejidad. facilitando aplicar con mayor efectividad esta metodología. además debe tener la capacidad de ser equipos auto -gestionados. 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. 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 . es el caso de XP y S RUM. vemos que los modelos ágiles. Podemos resaltar que: con un peque o equipo de desarrollo se puede realizar grandes proyectos. ya que la experiencia es la que predomina en los mementos cruciales del proyecto.  Por la curva de Aprendizaje on respecto a la curva de aprendizaje.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. 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. 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. del equipo y la complejidad del problema para cada uno de los modelos. donde los requisitos no se conocen con exactitud.

(en línea).asp?p=16790 &rl=1 www.org/wpcontent/metodologiasagiles_01. Disponible en Formato chm Introducción a Iconix (En línea).aspx Universidad Nacional De Cajamarca v u t s Página 14 .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.gpicr. Disponible en: www. (En línea).agile-spain.com Microsoft Solution Framework.com/msf.spinec.pdf Metodologías ágiles (En línea) .com I O IX (En línea).informit.Disponible en:http://www.spinec.XProgramming.Disponibleen: http://www. Disponible en: www.pdf Extreme Programming Refactored: The ase Against XP. MATT Stephens and DOUG Rosenberg. disponible en http://www.com/articles/article.org/wp-content/ICONIX.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->