Metodologías Tradicionales vs. Agiles PDF

Pantalla METODOLOGÍAS TRADICIONALES VS. METODOLOGÍAS ÁGILES Roberth G. Figueroa1, Camilo J. Solís2 Armando A. Cabrera3 Universidad Técnica Particular de Loja, Escuela de C...

Pantalla METODOLOGÍAS TRADICIONALES VS. METODOLOGÍAS ÁGILES Roberth G. Figueroa1, Camilo J. Solís2 Armando A. Cabrera3 Universidad Técnica Particular de Loja, Escuela de Ciencias en Computación Resumen  Desarrollar un buen software depende de un sinnúmero de actividades y etapas, donde el impacto de Dentro del desarrollo de software y a la altiva necesidad elegir la mejor metodología para un equipo, en un de que los proyectos lleguen al éxito y obtener un determinado proyecto es trascendental para el éxito del producto de gran valor para nuestros clientes, generan producto. El papel preponderante de las metodologías es grandes cambios en las metodologías adoptadas por los sin duda esencial en un proyecto y en el paso inicial, que equipos para cumplir sus objetivos, puesto que, unas se debe encajar en el equipo, guiar y organizar actividades adaptan mejor que otras, al contexto del proyecto que conlleven a las metas trazadas en el grupo. brindando mejores ventajas. En el presente trabajo se detallan los dos grandes enfoques, tanto metodologías tradicionales y metodologías Es por eso de la importancia de una metodología robusta ágiles, las primeras están pensadas para el uso exhaustivo que ajustada en un equipo cumpla con sus metas, y de documentación durante todo el ciclo del proyecto satisfaga mas allá de las necesidades definidas al inicio del mientras que las segundas ponen vital importancia en la proyecto. capacidad de respuesta a los cambios, la confianza en las habilidades del equipo y al mantener una buena relación con el cliente. Se verán diferencias, ventajas, desventajas y cual puede encajar en un proyecto de software, es por El éxito del producto depende en gran parte de la ello que, ofrecemos una guía dejando libertad de elección metodología escogida por el equipo, ya sea tradicional o para el lector el poder juzgar y elegir la mejor ágil, donde los equipos maximicen su potencial, aumenten metodología que se adapte a su equipo de desarrollo. la calidad del producto con los recursos y tiempos establecidos. Palabras Claves  Metodología, RUP, MSF AUP, Scrum, Metodología Tradicional, Metodología Ágil METODOLOGÍA TRADICIONAL INTRODUCCIÓN 1 Roberth G. Figueroa, UTPL, Loja, [email protected] 2 Camilo J. Solís, UTPL, Loja, [email protected] 3 Armando Cabrera S,Docente-Investigador UTPL,Loja, [email protected] 1 Al inicio el desarrollo de software era artesanal en su (Customización). Es guiado por casos de uso y centrado en totalidad, la fuerte necesidad de mejorar el proceso y la arquitectura, y utiliza UML como lenguaje de notación. llevar los proyectos a la meta deseada, tuvieron que importarse la concepción y fundamentos de metodologías Fases existentes en otras áreas y adaptarlas al desarrollo de Las cuatro fases del ciclo de vida son: software. Esta nueva etapa de adaptación contenía el  Concepción desarrollo dividido en etapas de manera secuencial que de  Elaboración algo mejoraba la necesidad latente en el campo del  Construcción software.  Transición Entre las principales metodologías tradicionales tenemos Ventajas los ya tan conocidos RUP y MSF entre otros, que centran  Evaluación en cada fase que permite cambios su atención en llevar una documentación exhaustiva de de objetivos todo el proyecto y centran su atención en cumplir con un  Funciona bien en proyectos de innovación. plan de proyecto, definido todo esto, en la fase inicial del  Es sencillo, ya que sigue los pasos intuitivos desarrollo del proyecto. necesarios a la hora de desarrollar el software. Otra de las características importantes dentro de este  Seguimiento detallado en cada una de las enfoque tenemos los altos costos al implementar un fases. cambio y al no ofrecer una buena solución para proyectos donde el entorno es volátil. Desventajas  La evaluación de riesgos es compleja Las metodologías tradicionales (formales) se focalizan en  Excesiva flexibilidad para algunos proyectos documentación, planificación y procesos. (Plantillas,  Estamos poniendo a nuestro cliente en una técnicas de administración, revisiones, etc.), a situación que puede ser muy incómoda para él. continuación se detalla RUP uno de los métodos más  Nuestro cliente deberá ser capaz de describir y usados dentro de los métodos tradicionales entender a un gran nivel de detalle para poder acordar un alcance del proyecto con él. RATIONAL UNIFIED PROCESS (RUP) MICROSOFT SOLUTION FRAMEWORK (MSF)4 FIGURA1. PROCESO UNIFICADO RATIONAL Descripción MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información. Todo proyecto es separado en cinco principales fases:  Visión y Alcances.  Planificación.  Desarrollo.  Estabilización.  Implantación. RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro FIGURA 2. de una organización de desarrollo. Su objetivo es asegurar MODELO DE EQUIPO DE MSF la producción de software de alta calidad que satisfaga los requerimientos de los usuarios finales (respetando cronograma y presupuesto). Fue desarrollado por Rational Software, y está integrado con toda la suite Rational de herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la organización que lo adopte. 4 Microsoft Solution Framework, (en línea), disponible en http://www.gpicr.com/msf.aspx 2  Modelo de roles 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. Los equipos organizados bajo este modelo son pequeños y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que están desarrollando. Comparten una visión común del proyecto y se enfocan en implementar la solución, con altos estándares de calidad y deseos de aprender. Visión y Alcances: El modelo de equipos de MSF tiene seis roles que La fase de visión y alcances trata uno de los requisitos más corresponden a las metas principales de un proyecto y son fundamentales para el éxito del proyecto, la unificación del responsables por las mismas. Cada rol puede estar equipo detrás de una visión común. El equipo debe tener compuestos por una o más personas, la estructura circular una visión clara de lo que quisiera lograr para el cliente y del modelo, con óvalos del mismo tamaño para todos los ser capaz de indicarlo en términos que motivarán a todo el roles, muestra que no es un modelo jerárquico y que cada equipo y al cliente. Se definen los líderes y responsables todos los roles son igualmente importantes en su aporte al del proyecto, adicionalmente se identifican las metas y proyecto. Aunque los roles pueden tener diferentes niveles objetivos a alcanzar; estas últimas se deben respetar de actividad durante las diversas etapas del proyecto, durante la ejecución del proyecto en su totalidad, y se ninguno puede ser omitido. realiza la evaluación inicial de riesgos del proyecto. La comunicación se pone en el centro del círculo para Planificación: mostrar que está integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicación efectiva y Es en esta fase es cuando la mayor parte de la planeación es esencial para el funcionamiento del mismo para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, Ejemplo de metodología MSF aplicada estimaciones de costos y cronogramas de los diferentes entregables del proyecto. Como ejemplo de una aplicación de metodología MSF a un proyecto, a continuación se describe el contenido de Desarrollo: cada una de las fases y, en la medida de lo posible, un detalle de acciones concretas y estimación de carga de Durante esta fase el equipo realice la mayor parte de la trabajo en términos de jornadas, número de personas construcción de los componentes (tanto documentación implicadas y perfil de las mismas. El proyecto ejemplo se como código), sin embargo, se puede realizar algún trata de una implantación de infraestructuras, en concreto, trabajo de desarrollo durante la etapa de estabilización en migración a Windows 2000 de una red de servidores. respuesta a los resultados de las pruebas. La infraestructura también es desarrollada durante esta fase. Fase 1 - Estrategia y alcance Estabilización: En esta fase deberían tener lugar los siguientes trabajos:  Elaboración y aprobación del Documento de En esta fase se conducen pruebas sobre la solución, las Alcance y Estrategia definitivo: debe ser un pruebas de esta etapa enfatizan el uso y operación bajo documento de consenso con la participación del condiciones realistas. El equipo se enfoca en priorizar y mayor número de agentes implicados en el resolver errores y preparar la solución para el lanzamiento. proyecto. En este documento quedarán definitivamente reflejadas las funcionalidades y Implantación: servicios que, ineludiblemente, debe ofrecer la solución a implantar. Durante esta fase el equipo implanta la tecnología base y  Formación del Equipo de Trabajo y distribución los componentes relacionados, estabiliza la instalación, de competencias y responsabilidades: traspasa el proyecto al personal soporte y operaciones, y generalmente se definen como áreas principales la obtiene la aprobación final del cliente. de Diseño de Arquitectura, Pruebas de 3  Laboratorio, Documentación, Logística y El cómputo de jornadas para la relación de actividades Coordinación. descritas (que como se observa sólo recogen las relativas a  Elaboración del Plan de Trabajo: deben marcarse la Planificación y Diseño, y deja aparte las necesarias para fechas y contenidos para esta fase y las elaborar el plan de Migración), ofrecería este resultado: siguientes. Los mecanismos y protocolos de Jornadas totales: 80 (aprox. 4 meses) intercambio de información y coordinación deben Jornadas / técnico del PARTNER: 150 jornadas (2 quedar suficientemente bien establecidos y personas) consensuados. Jornadas / técnico del CLIENTE: 110 jornadas (Max. 2  Elaboración de la matriz de Riesgos y Plan de personas) Contingencia: los principales riesgos detectados deben tener un plan de mitigación y actuación y Fase 3 – Estabilización revisarse con periodicidad. Para un proyecto de migración a Windows 2000 podría La solución implantada en la maqueta se pasa a un entorno estimarse que los trabajos indicados pueden requerir en real de explotación, restringido en número de usuarios y torno a 20 jornadas de trabajo y la intervención de un en condiciones tales que se pueda llevar un control Consultor de Microsoft junto con el equipo de trabajo que efectivo de la situación. Los hitos y objetivos formen El cliente y el Partner. fundamentales de esta fase son: Fase 2 - Planificación y Prueba de Concepto  Selección del entorno de prueba piloto: se acordará la composición y ubicación del conjunto Deben alcanzarse los siguientes objetivos e hitos: de máquinas y usuarios que entrarán en la prueba.  Documento de Planificación y Diseño de Esta selección se recomienda que se haga Arquitectura: es el documento principal, donde se atendiendo a la mayor variedad posible de casos, describen en detalle los aspectos funcionales y de manera que puedan aflorar el máximo de operativos de la nueva plataforma. La aprobación incidentes potenciales en el menor tiempo de este documento es el hito principal de esta posible. La dimensión de la muestra tiene fase, y supone la directriz última de todos los también que calcularse, sin perder de vista que la trabajos técnicos, que, a partir de ese momento, prueba piloto no es el despliegue propiamente, deben ser consistentes con esta Guía. Si en el sino una fase de observación en la que es curso de las fases sucesivas fuera necesario absolutamente crítico establecer unos cauces revisar estos contenidos, se deberá hacer por efectivos de tratamiento de los errores. acuerdo y conocimiento de todo el equipo de  Gestión de Incidencias: aunque esta labor se trabajo y se llevará un registro de versiones que habrá iniciado en la fase anterior, el éxito de la permita hacer un seguimiento adecuado de estas prueba piloto dependerá de que se forme un revisiones. sistema de recogida de incidentes (helpdesk o  Documento de Plan de Laboratorio - Prueba de similar), de atención al usuario (formación, Concepto: la descripción del contenido del consultas) y de resolución de problemas y laboratorio de prueba de concepto, los diversos documentación de los mismos (versionado de la escenarios a simular, los criterios de validez, el plataforma). control de incidencias y las métricas de calidad  Revisión de la documentación final de son objetivos a cubrir en este documento. Es un Arquitectura: el documento de Planificación y documento dinámico, en el que se recoge la idea Diseño de Arquitectura se puede ver alterado y la experiencia práctica al llevarla a cabo en parcialmente como resultado de esta fase. El entorno controlado y aislado. La etapa de prueba documento final, aprobado por consenso, supone de laboratorio concluye cuando la maqueta ofrece el principal documento del Proyecto y la todos los servicios y funciones descritos en el culminación de los trabajos de diseño, al menos Documento de Alcance y Estrategia, y su grado en sus líneas principales. Este documento se de estabilidad y rendimiento es considerado como considerará definitivo cuando la solución puesta "suficiente". en marcha se muestre estable y el número de incidencias graves (de intervención o de Habitualmente, en las propuestas de preventa no se pueden resolución) sea nulo y la cantidad de las indicar con precisión parámetros como el esfuerzo técnico, consideradas leves quede por debajo de un límite tiempo o coste definitivo que puede suponer esta fase. De establecido en las Métricas de Calidad. otras experiencias anteriores se puede obtener una relación  Elaboración de la documentación de de trabajos sólo a título orientativo, y que debe ser Formación y Operaciones: con vistas al soporte revisado y acordado por todas las partes: post proyecto y los programas de formación a usuarios y administradores, en esta fase deben elaborarse las Guías de Usuario, de 4  Administración, las "paso-a-paso", y otros cuyos La duración fase de despliegue, puesto que debe contenidos deben acordarse previamente. planificarse, no puede establecerse a priori. Depende de  Elaboración del Plan de Despliegue: se debe numerosos factores externos al propio proyecto consensuar la fecha de finalización de la fase (incluyendo factores de oportunidad política o de negocio) Piloto, y las condiciones de calidad que debe que pueden retardar o acelerar la conclusión. cumplir la solución final para iniciar el La experiencia demuestra que no hay una relación directa despliegue. En el Plan deben identificarse las entre número de máquinas y tiempo necesario para el fases, estrategia de implantación, fechas, tareas a despliegue. Los factores más relevantes en el cálculo realizar, procedimientos de validación y método suelen ser la dispersión o concentración geográfica, la de control de incidencias. complejidad del proceso de migración, el grado de  Elaboración del Plan de Formación: con automatización alcanzado, la experiencia y nivel de los anterioridad al despliegue definitivo, debe técnicos que realizan la operación y condicionantes de haberse aprobado el Plan de Formación orientado calendario, a menudo con restricciones no técnicas, sino a usuarios finales y administradores, y debe de otros tipos (las fechas-objetivo suelen marcarse por hacerse compatible con los ritmos acordados en criterios de oportunidad de negocio). el Plan de Despliegue. El tiempo necesario para abordar esta fase es variable y depende en parte de factores ajenos a la complejidad de la METODOLOGÍAS ÁGILES. propia solución, como es la adecuada selección del entorno de prueba y el momento del año en que tenga Luego de varias opiniones tanto a favor como en contra de lugar (evitando que coincida con periodos de vacaciones o las metodologías tradicionales se genera un nuevo puntas de trabajo críticas como Fin de Año). En proyectos enfoque denominado, métodos ágiles, que nace como de similar envergadura se ha llegado al momento "Error respuesta a los problemas detallados anteriormente y se Free Versión" en 30 jornadas de trabajo (aproximadamente basa en dos aspectos puntuales, el retrasar las decisiones y mes y medio) con una muestra de 50 usuarios. la planificación adaptativa; permitiendo potencia aún más el desarrollo de software a gran escala. Fase 4 – Despliegue Como resultado de esta nueva teoría se crea un Manifiesto Se llevarán a cabo en esta fase los planes diseñados en la Ágil5 cuyas principales ideas son: anterior, principalmente el de despliegue y el de formación. Los principales trabajos e hitos a conseguir  Los individuos y las interacciones entre ellos son son, en este caso, además de los obvios (implantación de más importantes que las herramientas y los la plataforma, puesta en servicio de todas las funciones, procesos empleados. formación a los usuarios y administradores), los  Es más importante crear un producto software siguientes: que funcione que escribir documentación  Continuación con las labores de recepción de exhaustiva. incidencias, clasificación, tratamiento, resolución  La colaboración con el cliente debe prevalecer y distribución de faxes o intervención on-site. sobre la negociación de contratos.  Registro de mejoras y sugerencias,  La capacidad de respuesta ante un cambio es más funcionalidades no cubiertas y novedades a importante que el seguimiento estricto de un plan. incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas por los Entre los principales métodos ágiles tenemos el XP fabricantes de software (nuevas versiones o (eXtreme Programming), Scrum, Iconix, Cristal Methods, Service Packs, por ejemplo) AUP entre otras.  Revisión de las Guías y manuales de usuario, rectificación de errores y obtención de los Estas metodologías ponen de relevancia que la capacidad documentos de formación definitivos. de respuesta a un cambio es más importante que el  Entrega de los documentos definitivos acordados seguimiento estricto de un plan. Nos lo proponen porque como "deliverables" en la fase de Vision Scope. para muchos clientes esta flexibilidad será una ventaja  Revisión (si procede) de la matriz de riesgos, las competitiva y porque estar preparados para el cambio métricas de calidad y establecimiento de los significar reducir su coste. estándares de calidad y SLA definitivos.  Finalmente, entrega del Proyecto y cierre del Retrasar las decisiones y Planificación Adaptativa mismo, con o sin apertura de nuevo proyecto en base a la información y experiencia obtenidas. Es el eje en cual gira la metodología ágil, el retrasar las decisiones tan como sea posible de manera responsable 5 Pires, Donald, “Manifiesto Ágil”, UCLA, (en línea), disponible en http://www.manifiestoagile.com 5 será ventajoso tanto para el cliente como para la empresa, Creen que ser capaz de adaptarse a los cambios de lo cual permite siempre mantener una satisfacción en el requisitos en cualquier punto de la vida del proyecto es cliente y por ende el éxito del producto, las principales una aproximación mejor y más realista que intentar definir ventajas de retrasar las decisiones son: todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los  Reduce el número de decisiones de alta requisitos. inversión que se toman.  Reduce el número de cambios necesario Las características fundamentales del método son: en el proyecto.  Desarrollo iterativo e incremental: pequeñas  Reduce el coste del cambio mejoras, unas tras otras.  Pruebas unitarias continuas, frecuentemente La planificación adaptativa permite estar preparados para repetidas y automatizadas, incluyendo pruebas de el cambio ya que lo hemos introducido en nuestro proceso regresión. Se aconseja escribir el código de la de desarrollo, además hacer una planificación adaptativa prueba antes de la codificación. consiste en tomar decisiones a lo largo del proyecto,  Programación por parejas: se recomienda que estaremos transformando el proyecto en un conjunto de las tareas de desarrollo se lleven a cabo por dos proyectos pequeños. personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera - Esta planificación a corto plazo nos permitirá tener el código es revisado y discutido mientras se software disponible para nuestros clientes y además ir escribe- es más importante que la posible pérdida aprendiendo del feedback para hacer nuestra planificación de productividad inmediata. más sensible, sea ante inconvenientes que aceleren o  Frecuente interacción del equipo de retrasen nuestro producto. A continuación se detalla el XP programación con el cliente o usuario. Se que es el más aceptado dentro del desarrollo de SW recomienda que un representante del cliente trabaje junto al equipo de desarrollo. EXTREME PROGRAMMING (XP)  Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes. FIGURA 36.  Refactorización del código, es decir, reescribir MODELO DE EXTREME PROGRAMMING ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.  Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.  Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que en más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que Es la más destacada de los procesos ágiles de desarrollo de realizar algo complicado y quizás nunca software formulada por Kent Beck. La programación utilizarlo. extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la La simplicidad y la comunicación son extraordinariamente adaptabilidad que en la previsibilidad. complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras Los defensores de XP consideran que los cambios de más simple es el sistema, menos tendrá que comunicar requisitos sobre la marcha son un aspecto natural, sobre este, lo que lleva a una comunicación más completa, inevitable e incluso deseable del desarrollo de proyectos. 6 Extrem Porgramming(XP). Disponible en www.XProgramming.com 6 especialmente si se puede reducir el equipo de ESQUEMA DE TRABAJO SCRUM programadores. Ventajas  Apropiado para entornos volátiles  Estar preparados para el cambio, significa reducir su coste.  Planificación más transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades. Vital para su negocio  Permitirá definir en cada iteración cuales son los objetivos de la siguiente  Permite tener realimentación de los usuarios muy útil.  La presión esta a lo largo de todo el proyecto y no en una entrega final Scrum es un proceso ágil y liviano que sirve para Desventajas administrar y controlar el desarrollo de software. El  Delimitar el alcance del proyecto con nuestro desarrollo se realiza en forma iterativa e incremental (una cliente iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software Para mitigar esta desventaja se plantea definir un alcance a ejecutable que incorpora nueva funcionalidad. Las alto nivel basado en la experiencia. iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme AUP (AGIL UNIFIED PROCESS) Programming. FIGURA 4. Scrum se focaliza en priorizar el trabajo en función del ESQUEMA DE TRABAJO AUP valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversión. Está diseñado especialmente para adaptarse a los cambios en los requerimientos, por ejemplo en un mercado de alta competitividad. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta forma se puede adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfacción del cliente. En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por el otro lado, la gestión El AUP es un acercamiento aerodinámico a desarrollo de un proyecto Scrum se focaliza en definir cuales son las del software basado en el Proceso Unificado Rational características que debe tener el producto a construir (qué de IBM (RUP), basado en disciplinas y entregables construir, qué no y en qué orden) y en remover cualquier incrementales con el tiempo. El ciclo de vida en obstáculo que pudiera entorpecer la tarea del equipo de proyectos grandes es serial mientras que en los desarrollo. Se busca que los equipos sean lo más efectivos pequeños es iterativo. Las disciplinas de Aup son: y productivos posible.  Modelado  Implementación Scrum tiene un conjunto de reglas muy pequeño y muy  Prueba simple y está basado en los principios de inspección  Despliegue continua, adaptación, auto-gestión e innovación. El cliente  Administración de la configuración se entusiasma y se compromete con el proyecto dado que  Administración o gerencia del Proyecto ve crecer el producto iteración a iteración y encuentra las  Entorno herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. SCRUM FIGURA 5. 7 Por otro lado, los desarrolladores encuentran un ámbito seguidos por el entorno de producción de código propicio para desarrollar sus capacidades profesionales y desarrollo Cierta resistencia a los Especialmente preparados para esto resulta en un incremento en la motivación de los cambios cambios durante el proyecto integrantes del equipo. Impuestas externamente Impuestas internamente (por el equipo) Proceso mucho más Proceso menos controlado, ICONIX controlado, con numerosas con pocos principios. políticas/normas El proceso de ICONIX maneja casos de uso, como el El cliente interactúa con el El cliente es parte del equipo equipo de desarrollo mediante de desarrollo RUP, pero le falta mucho para llegar al nivel del RUP. reuniones También es relativamente pequeño y firme, como XP, pero Más artefactos Pocos artefactos no desecha el análisis y diseño que hace XP. Este proceso Más roles Pocos roles también hace uso aerodinámico del UML mientras guarda Grupos grandes y Grupos pequeños (