Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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 concepcin y fundamentos de metodologas existentes en otras reas y adaptarlas al desarrollo de software. Esta nueva etapa de adaptacin contena el desarrollo dividido en etapas de manera secuencial que de algo mejoraba la necesidad latente en el campo del software. Entre las principales metodologas tradicionales tenemos los ya tan conocidos RUP y MSF entre otros, que centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y centran su atencin en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las caractersticas importantes dentro de este enfoque tenemos los altos costos al implementar un cambio y al no ofrecer una buena solucin para proyectos donde el entorno es voltil. Las metodologas tradicionales (formales) se focalizan en documentacin, planificacin y procesos. (Plantillas, tcnicas de administracin, revisiones, etc.), a continuacin se detalla RUP uno de los mtodos ms usados dentro de los mtodos tradicionales
INTRODUCCIN
Dentro del desarrollo de software y a la altiva necesidad de que los proyectos lleguen al xito y obtener un producto de gran valor para nuestros clientes, generan grandes cambios en las metodologas adoptadas por los equipos para cumplir sus objetivos, puesto que, unas se adaptan mejor que otras, al contexto del proyecto brindando mejores ventajas. Es por eso de la importancia de una metodologa robusta que ajustada en un equipo cumpla con sus metas, y satisfaga mas all de las necesidades definidas al inicio del proyecto.
El xito del producto depende en gran parte de la metodologa 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. RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar
METODOLOGA TRADICIONAL
1 2 3
Roberth G. Figueroa, UTPL, Loja, rgfigueroa@utpl.edu.ec Camilo J. Sols, UTPL, Loja, cjsolis@utpl.edu.ec Armando Cabrera S,Docente-Investigador UTPL,Loja, aacabrera@utpl.edu.ec
Visin y Alcances: La fase de visin y alcances trata uno de los requisitos ms fundamentales para el xito del proyecto, la unificacin del equipo detrs de una visin comn. El equipo debe tener una visin clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en trminos que motivarn a todo el equipo y al cliente. Se definen los lderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas ltimas se deben respetar durante la ejecucin del proyecto en su totalidad, y se realiza la evaluacin inicial de riesgos del proyecto. Planificacin: Es en esta fase es cuando la mayor parte de la planeacin para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseo de la solucin, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto. Desarrollo: Durante esta fase el equipo realice la mayor parte de la construccin de los componentes (tanto documentacin como cdigo), sin embargo, se puede realizar algn trabajo de desarrollo durante la etapa de estabilizacin en respuesta a los resultados de las pruebas. La infraestructura tambin es desarrollada durante esta fase. Estabilizacin:
Evaluacin en cada fase que permite cambios de objetivos Funciona bien en proyectos de innovacin. Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software. Seguimiento detallado en cada una de las fases.
Desventajas La evaluacin de riesgos es compleja Excesiva flexibilidad para algunos proyectos Estamos poniendo a nuestro cliente en una situacin que puede ser muy incmoda para l. Nuestro cliente deber ser capaz de describir y entender a un gran nivel de detalle para poder acordar un alcance del proyecto con l.
En esta fase se conducen pruebas sobre la solucin, las pruebas de esta etapa enfatizan el uso y operacin bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solucin para el lanzamiento. Implantacin: Durante esta fase el equipo implanta la tecnologa base y los componentes relacionados, estabiliza la instalacin,
Ejemplo de metodologa MSF aplicada Como ejemplo de una aplicacin de metodologa MSF a un proyecto, a continuacin se describe el contenido de cada una de las fases y, en la medida de lo posible, un detalle de acciones concretas y estimacin de carga de trabajo en trminos de jornadas, nmero de personas implicadas y perfil de las mismas. El proyecto ejemplo se trata de una implantacin de infraestructuras, en concreto, migracin a Windows 2000 de una red de servidores. Fase 1 - Estrategia y alcance En esta fase deberan tener lugar los siguientes trabajos: Elaboracin y aprobacin del Documento de Alcance y Estrategia definitivo: debe ser un documento de consenso con la participacin del mayor nmero de agentes implicados en el proyecto. En este documento quedarn definitivamente reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la solucin a implantar. Formacin del Equipo de Trabajo y distribucin de competencias y responsabilidades: generalmente se definen como reas principales la de Diseo de
El cmputo de jornadas para la relacin de actividades descritas (que como se observa slo recogen las relativas a la Planificacin y Diseo, y deja aparte las necesarias para elaborar el plan de Migracin), ofrecera este resultado: Jornadas totales: 80 (aprox. 4 meses) 3
METODOLOGAS GILES. Luego de varias opiniones tanto a favor como en contra de las metodologas tradicionales se genera un nuevo enfoque denominado, mtodos giles, que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificacin adaptativa; permitiendo potencia an ms el desarrollo de software a gran escala. Como resultado de esta nueva teora se crea un Manifiesto gil5 cuyas principales ideas son: Los individuos y las interacciones entre ellos son ms importantes que las herramientas y los procesos empleados. Es ms importante crear un producto software que funcione que escribir documentacin exhaustiva. La colaboracin con el cliente debe prevalecer sobre la negociacin de contratos. La capacidad de respuesta ante un cambio es ms importante que el seguimiento estricto de un plan.
Entre los principales mtodos giles tenemos el XP (eXtreme Programming), Scrum, Iconix, Cristal Methods, AUP entre otras. Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es ms importante que el seguimiento estricto de un plan. Nos lo proponen porque para muchos clientes esta flexibilidad ser una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste. Retrasar las decisiones y Planificacin Adaptativa Es el eje en cual gira la metodologa gil, el retrasar las decisiones tan como sea posible de manera responsable ser ventajoso tanto para el cliente como para la empresa, lo cual permite siempre mantener una satisfaccin en el cliente y por ende el xito del producto, las principales ventajas de retrasar las decisiones son: Reduce el nmero de decisiones de alta inversin que se toman. Reduce el nmero de cambios necesario en el proyecto. Reduce el coste del cambio Es la ms destacada de los procesos giles de desarrollo de software formulada por Kent Beck. La programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Las caractersticas fundamentales del mtodo son: Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras. Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la prueba antes de la codificacin. Programacin por parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la
6
La planificacin adaptativa permite estar preparados para el cambio ya que lo hemos introducido en nuestro proceso de desarrollo, adems hacer una planificacin adaptativa consiste en tomar decisiones a lo largo del proyecto,
Pires, Donald, Manifiesto gil, UCLA, (en lnea), disponible en http://www.manifiestoagile.com
5
La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe hacer. Mientras ms simple es el sistema, menos tendr que comunicar sobre este, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de programadores. Ventajas Apropiado para entornos voltiles Estar preparados para el cambio, significa reducir su coste. Planificacin ms transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades. Vital para su negocio Permitir definir en cada iteracin cuales son los objetivos de la siguiente Permite tener realimentacin de los usuarios muy til. La presin esta a lo largo de todo el proyecto y no en una entrega final
El AUP es un acercamiento aerodinmico a desarrollo del software basado en el Proceso Unificado Rational de IBM (RUP), basado en disciplinas y entregables incrementales con el tiempo. El ciclo de vida en proyectos grandes es serial mientras que en los pequeos es iterativo. Las disciplinas de Aup son: Modelado Implementacin Prueba Despliegue Administracin de la configuracin Administracin o gerencia del Proyecto Entorno
SCRUM
FIGURA 5.
ESQUEMA DE TRABAJO SCRUM
Desventajas Delimitar el alcance del proyecto con nuestro cliente Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la experiencia.
Scrum es un proceso gil y liviano que sirve para administrar y controlar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteracin es un ciclo corto de construccin repetitivo). Cada ciclo o iteracin termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duracin entre 2 y 4 semanas. Scrum se utiliza como marco para otras prcticas 6
Y, el proceso se queda igual a la visin original de Jacobson del manejo de casos de uso, esto produce un resultado concreto, especfico y casos de uso fcilmente entendible, que un equipo de un proyecto puede usar para conducir el esfuerzo hacia un desarrollo real. La Figura 6 muestra el cuadro del proceso. El diagrama retrata la esencia del enfoque aerodinmico al desarrollo del software, que incluye un juego mnimo de diagramas de UML y algunas valiosas tcnicas que se toman de los casos del uso para codificar rpida y eficazmente. El enfoque es flexible y abierto; siempre se puede seleccionar de los otros aspectos del UML para complementar los materiales bsicos. 1. Diferencias: TABLA 1.
DIFERENCIAS ENTRE METODOLOGA TRADICIONALES Y GILES
Metodologas Tradicionales
Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente Proceso mucho ms controlado, con numerosas polticas/normas El cliente interacta con el equipo de desarrollo mediante reuniones Ms artefactos Ms roles Grupos grandes y posiblemente distribuidos La arquitectura del software es esencial y se expresa mediante modelos Existe un contrato prefijado
Metodologas Agiles
Basadas en heursticas provenientes de prcticas de produccin de cdigo Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso menos controlado, con pocos principios. El cliente es parte del equipo de desarrollo Pocos artefactos Pocos roles Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio Menos nfasis en la arquitectura del software No existe contrato tradicional o al menos es bastante flexible
ICONIX
El proceso de ICONIX maneja casos de uso, como el RUP, pero le falta mucho para llegar al nivel del RUP. Tambin es relativamente pequeo y firme, como XP, pero no desecha el anlisis y diseo que hace XP. Este proceso tambin hace uso aerodinmico del UML mientras guarda un enfoque afilado en el seguimiento de requisitos.
Ofrecemos una comparativa entre cada uno de las etapas ms comunes del desarrollo de SW y los enfoques de metodologas revisados. TABLA 2. 7
MODELOS RIGUROSOS
ETAPA
Anlisis de requerimientos
MODELOS AGILES
Planificacin adpatativa:Entregas frecuentes + colaboracin del cliente
Modelo de Proceso
RUP ICONIX
Curva de aprendizaje
Lenta Rpida
Herramienta de integracin
Alto Soporte Algn Soporte Disponible No mencionado
Soporte Externo
Alto Soporte Algn Soporte Disponible Algn Soporte Disponible Algn Soporte Disponible
Planificacin predictiva y aislada Planificacin Diseo flexible y Extensible + modelos + Documentacin exhaustiva Desarrollo individual con Roles y responsabilidades estrictas Diseo
XP
Rpida
SCRUM
Diseo Simple: Documentacin Mnima + Focalizado en la comunicacin Transferencia de conocimiento: Programacin en pares + conocimiento colectivo LiderazgoColaboracin: empoderamiento +auto-organizacin
Rpida
No mencionado
Codificacin
Con respecto a la curva de aprendizaje, vemos que los modelos giles, nos ofrecen una mayor ventaja pero con ciertas limitaciones, ya que aun no hay sido explotadas a gran escala como lo es RUP que posee alto soporte y herramientas integrales que nos guan a travs del mismo, facilitando aplicar con mayor efectividad esta metodologa, permitiendo aprovecharla al mximo
CONCLUSIONES
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 metodologa gil debe poseer experiencia trabajando con metodologas tradicionales, ya que la experiencia es la que predomina en los mementos cruciales del proyecto, adems debe tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovacin Las metodologas giles permiten disminuir costos y brindar flexibilidad a los proyectos de software donde la incertidumbre est presente El uso de metodologas tradicionales es esencial al inicio en un equipo de desarrollo de software Las metodologas giles se deberan aplicar en proyectos donde exista mucha incertidumbre donde el entorno es voltil, donde los requisitos no se conocen con exactitud, mientras que las metodologas tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.
REFLEXIN Alguna recomendacin para los lectores de este Artculo?
Adems presentamos un cuadro de comparacin por cada aspecto analizado y lo ponemos a consideracin: Por las caractersticas del Proyecto Tamao del Proceso
Medio / Extenso Pequeo / Medio Pequeo / Medio Pequeo / Medio
Modelo de Proceso
RUP ICONIX XP SCRUM
Medio / Alto
En este cuadro se presenta una comparativa de las modelos de proceso en cuanto a las caractersticas del proyecto, analizamos el tamao del proceso, del equipo y la complejidad del problema para cada uno de los modelos. Podemos resaltar que: con un pequeo equipo de desarrollo se puede realizar grandes proyectos, de alta complejidad; es el caso de XP y SCRUM.
Primero, que conozcan y apliquen las tcnicas de ingeniera de software. Segundo, que se incorporen de lleno mtodos de calidad en sus procesos y que la forma ms eficiente y efectiva de hacer las cosas, es hacerlas bien a la primera vez y con ello daremos un
gran giro a la industria del software. Por ltimo, que entiendan la importancia de la gente. Con este fin voy a hacer una ltima 8
BIBLIOGRAFA
[ 1 ] Metodologas giles: La ventaja competitiva de estar preparado para tomar decisiones lo ms tarde posible y cambiarlas en cualquier momento. (En lnea), Disponible en: www.spinec.org/wpcontent/metodologiasagiles_01.pdf [ 2 ] Metodologas giles (En lnea) ,Disponible en: http://www.agile-spain.com [ 3 ] ICONIX (En lnea), Disponible en: www.spinec.org/wp-content/ICONIX.pdf [ 4 ] Extreme Programming Refactored: The Case Against XP, MATT Stephens and DOUG Rosenberg, Disponible en Formato chm [ 5 ] Introduccin a Iconix (En lnea), Disponible en: http://www.informit.com/articles/article.asp?p=1 67902&rl=1