You are on page 1of 16

Instituto Tecnolgico de Pachuca Ing.

Tecnologas de la Informacin y Comunicacin Tema: Metodologas Elena Yazmin Gonzlez Jaime 10200264

16/02/13

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.

METODOLOGA 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 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

RATIONAL UNIFIED PROCESS (RUP)

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin 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 organizacin que lo adopte. (Customizacin). Es guiado por casos de uso y centrado en la arquitectura, y utiliza UML como lenguaje de notacin. Fases Las cuatro fases del ciclo de vida son: Concepcin Elaboracin Construccin Transicin Ventajas

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.

MICROSOFT SOLUTION FRAMEWORK (MSF)1


Descripcin MSF es un compendio de las mejores prcticas en cuanto a administracin de proyectos se refiere. Ms que una metodologa rgida de administracin de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnologa de informacin. Todo proyecto es separado en cinco principales fases: Visin y Alcances. Planificacin. Desarrollo. Estabilizacin. Implantacin.

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: 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, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobacin final del cliente. Modelo de roles El modelo de equipos de MSF (MSF team model) fue desarrollado para compensar algunas de las desventajas impuestas por las estructuras jerrquicas de los equipos en los proyectos tradicionales. Los equipos organizados bajo este modelo son pequeos y multidisciplinarios, en los cuales los miembros comparten responsabilidades y balancean las destrezas del equipo para mantenerse enfocados en el proyecto que estn desarrollando. Comparten una visin comn del proyecto y se enfocan en implementar la solucin, con altos estndares de calidad y deseos de aprender. El modelo de equipos de MSF tiene seis roles que corresponden a las metas principales de un proyecto y son responsables por las mismas. Cada rol puede estar compuestos por una o ms personas, la estructura circular del modelo, con valos del mismo tamao para todos los roles, muestra que no es un modelo jerrquico y que cada todos los roles son igualmente importantes en su aporte al proyecto. Aunque los roles pueden tener diferentes niveles de actividad durante las diversas etapas del proyecto, ninguno puede ser omitido. La comunicacin se pone en el centro del crculo para mostrar que est integrada en la estructura y fluye en todas direcciones. El modelo apoya la comunicacin efectiva y es esencial para el funcionamiento del mismo

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 Arquitectura, Pruebas de Laboratorio, Documentacin, Logstica y Coordinacin. Elaboracin del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las siguientes. Los mecanismos y protocolos de intercambio de informacin y coordinacin deben quedar suficientemente bien establecidos y consensuados. Elaboracin de la matriz de Riesgos y Plan de Contingencia: los principales riesgos detectados deben tener un plan de mitigacin y actuacin y revisarse con periodicidad. Para un proyecto de migracin a Windows 2000 podra estimarse que los trabajos indicados pueden requerir en torno a 20 jornadas de trabajo y la intervencin de un Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner.

Fase 2 - Planificacin y Prueba de Concepto Deben alcanzarse los siguientes objetivos e hitos: Documento de Planificacin y Diseo de Arquitectura: es el documento principal, donde se describen en detalle los aspectos funcionales y operativos de la nueva plataforma. La aprobacin de este documento es el hito principal de esta fase, y supone la directriz ltima de todos los trabajos tcnicos, que, a partir de ese momento, deben ser consistentes con esta Gua. Si en el curso de las fases sucesivas fuera necesario revisar estos contenidos, 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. Documento de Plan de Laboratorio - Prueba de Concepto: la descripcin del contenido del laboratorio de prueba de concepto, los diversos escenarios a simular, los criterios de validez, el control de incidencias y las mtricas de calidad son objetivos a cubrir en este documento. Es un documento dinmico, en el que se recoge la idea y la experiencia prctica al llevarla a cabo en entorno controlado y aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su grado de estabilidad y rendimiento es considerado como "suficiente".

Habitualmente, en las propuestas de preventa no se pueden indicar con precisin parmetros como el esfuerzo tcnico, tiempo o coste definitivo que puede suponer esta fase. De otras experiencias anteriores se puede obtener una relacin de trabajos slo a ttulo orientativo, y que debe ser revisado y acordado por todas las partes:

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) Jornadas / tcnico del PARTNER: 150 jornadas (2 personas) Jornadas / tcnico del CLIENTE: 110 jornadas (Max. 2 personas) Fase 3 Estabilizacin La solucin implantada en la maqueta se pasa a un entorno real de explotacin, restringido en nmero de usuarios y en condiciones tales que se pueda llevar un control efectivo de la situacin. Los hitos y objetivos fundamentales de esta fase son: Seleccin del entorno de prueba piloto: se acordar la composicin y ubicacin del conjunto de mquinas y usuarios que entrarn en la prueba. Esta seleccin se recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera que puedan aflorar el mximo de incidentes potenciales en el menor tiempo posible. La dimensin de la muestra tiene tambin que calcularse, sin perder de vista que la prueba piloto no es el despliegue propiamente, sino una fase de observacin en la que es absolutamente crtico establecer unos cauces efectivos de tratamiento de los errores. Gestin de Incidencias: aunque esta labor se habr iniciado en la fase anterior, el xito de la prueba piloto depender de que se forme un sistema de recogida de incidentes (helpdesk o similar), de atencin al usuario (formacin, consultas) y de resolucin de problemas y documentacin de los mismos (versionado de la plataforma). Revisin de la documentacin final de Arquitectura: el documento de Planificacin y Diseo de Arquitectura se puede ver alterado parcialmente como resultado de esta fase. El documento final, aprobado por consenso, supone el principal documento del Proyecto y la culminacin de los trabajos de diseo, al menos en sus lneas principales. Este documento se considerar definitivo cuando la solucin puesta en marcha se muestre estable y el nmero de incidencias graves (de intervencin o de resolucin) sea nulo y la cantidad de las consideradas leves quede por debajo de un lmite establecido en las Mtricas de Calidad.

Elaboracin de la documentacin de Formacin y Operaciones: con vistas al soporte post proyecto y los programas de formacin a usuarios y administradores, en esta fase deben elaborarse las Guas de Usuario, de Administracin, las "paso-a-paso", y otros cuyos contenidos deben acordarse previamente. Elaboracin del Plan de Despliegue: se debe consensuar la fecha de finalizacin de la fase Piloto, y las condiciones de calidad que debe cumplir la solucin final para iniciar el despliegue. En el Plan deben identificarse las fases, estrategia de implantacin, fechas, tareas a realizar, procedimientos de validacin y mtodo de control de incidencias. Elaboracin del Plan de Formacin: con anterioridad al despliegue definitivo, debe haberse aprobado el Plan de Formacin orientado a usuarios finales y administradores, y debe hacerse compatible con los ritmos acordados en 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 propia solucin, como es la adecuada seleccin del entorno de prueba y el momento del ao en que tenga lugar (evitando que coincida con periodos de vacaciones o puntas de trabajo crticas como Fin de Ao). En proyectos de similar envergadura se ha llegado al momento "Error Free Versin" en 30 jornadas de trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios. Fase 4 Despliegue Se llevarn a cabo en esta fase los planes diseados en la anterior, principalmente el de despliegue y el de formacin. Los principales trabajos e hitos a conseguir son, en este caso, adems de los obvios (implantacin de la plataforma, puesta en servicio de todas las funciones, formacin a los usuarios y administradores), los siguientes: Continuacin con las labores de recepcin de incidencias, clasificacin, tratamiento, resolucin y distribucin de faxes o intervencin on-site. Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas por los fabricantes de software (nuevas versiones o Service Packs, por ejemplo) Revisin de las Guas y manuales de usuario, rectificacin de errores y obtencin de los documentos de formacin definitivos. Entrega de los documentos definitivos acordados como "deliverables" en la fase de Vision Scope. Revisin (si procede) de la matriz de riesgos, las mtricas de calidad y establecimiento de los estndares de calidad y SLA definitivos. Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo proyecto en base a la informacin y experiencia obtenidas. La duracin fase de despliegue, puesto que debe planificarse, no puede establecerse a priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores de oportunidad poltica o de negocio) que pueden retardar o acelerar la conclusin. La experiencia demuestra que no hay una relacin directa entre nmero de mquinas y tiempo necesario para el despliegue. Los factores ms relevantes en el clculo suelen ser la dispersin o concentracin geogrfica, la complejidad del proceso de migracin, el grado de automatizacin alcanzado, la experiencia y nivel de los tcnicos que realizan la operacin y condicionantes de calendario, a menudo con restricciones no tcnicas, sino de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de negocio).

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 gil2 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

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, estaremos transformando el proyecto en un conjunto de proyectos pequeos. Esta planificacin a corto plazo nos permitir tener software disponible para nuestros clientes y adems ir aprendiendo del feedback para hacer nuestra planificacin ms sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto. A continuacin se detalla el XP que es el ms aceptado dentro del desarrollo de SW

Pires, Donald, Manifiesto gil, UCLA, (en lnea), disponible en http://www.manifiestoagile.com

EXTREME PROGRAMMING (XP)

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 mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata. Frecuente interaccin del equipo de programacin con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes. Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no se ha introducido ningn fallo. Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados. Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir funcionalidad si es necesario. La programacin extrema apuesta que en ms sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.

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

Desventajas Delimitar el alcance del proyecto con nuestro cliente

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

Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la experiencia.

AUP (AGIL UNIFIED PROCESS)

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

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 de ingeniera de software como RUP o Extreme Programming. Scrum se focaliza en priorizar el trabajo en funcin del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de inversin. Est diseado 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 satisfaccin del cliente. En Scrum, el equipo se focaliza en una nica cosa: construir software de calidad. Por el otro lado, la gestin de un proyecto Scrum se focaliza en definir cuales son las caractersticas que debe tener el producto a construir (qu construir, qu no y en qu orden) y en remover cualquier obstculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo ms efectivos y productivos posible. Scrum tiene un conjunto de reglas muy pequeo y muy simple y est basado en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin. El cliente se entusiasma y se compromete con el proyecto dado que ve crecer el producto iteracin a iteracin y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. Por otro lado, los desarrolladores encuentran un mbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivacin de los integrantes del equipo.

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.

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:

DIFERENCIAS ENTRE METODOLOGA TRADICIONALES Y GILES Metodologas Tradicionales Metodologas Agiles

Basadas en normas provenientes de estndares Basadas en heursticas provenientes de prcticas seguidos por el entorno de desarrollo de produccin de cdigo Cierta resistencia a los cambios Especialmente preparados para cambios durante el proyecto Impuestas externamente Impuestas internamente (por el equipo) Proceso mucho ms controlado, con numerosas Proceso menos controlado, con pocos principios. 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 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

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 gil3 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

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, estaremos transformando el proyecto en un conjunto de proyectos pequeos. Esta planificacin a corto plazo nos permitir tener software disponible para nuestros clientes y adems ir aprendiendo del feedback para hacer nuestra planificacin ms sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto. A continuacin se detalla el XP que es el ms aceptado dentro del desarrollo de SW

Los Tipos de Metodologas de Desarrollo de Sistemas

Estructurada
Se maneja como proyecto Gran volumen de datos y transacciones Abarca varias reas organizativas de la empresa Tiempo de desarrollo largo Requiere que se cumplan todas las etapas, para poder cumplir las siguientes (progresin lineal y secuencial de una fase a la otra)

Evolutiva-Incremental
Se deriva de la estructurada Permite seguir secuencias ascendentes o descendentes en las etapas del desarrollo Permite cumplir etapas o fases en paralelo, por lo que es ms flexible que la estructurada

Prototipos
Desarrolla modelo en escala del sistema propuesto (sistema objetivo) En otras palabras, desarrolla un demo, que de ser aprobado por el usuario, se culmina con todas las funcionalidades. Se prueba y refina hasta que usuarios conformes Identifica necesidades de informacin Maneja principales procedimientos orientados a transacciones Produce informes crticos Permite consultas rudimentarias Complementa especificaciones imprecisas y/o incompletas de los usuarios

Orientada a Objetos
No modela la realidad, sino la forma en que las personas comprenden y procesan la realidad Es un proceso ascendente basado en una abstraccin de clases en aumento Se basa en identificacin de objetos, definicin y organizacin de libreras de clases, y creacin de macros para aplicaciones especficas Utiliza menor cantidad de cdigo

Es ms reutilizable

You might also like