Sie sind auf Seite 1von 5

Metodologas De Desarrollo De Software

Mara A. Mendoza Sanchez Ing. Informtico - UNT Microsoft Certified Professional - MCP Analsta y Desarrolladora - TeamSoft Per S.A.C.

informatizate(at)informatizate(dot)net Junio 7 del 2004.

Qu metodologa debo usar para el desarrollo de un Software? Todos en algn momento nos hemos hecho esta pregunta, cuando hemos tenido que desarrollar un software. Y de hecho esta pregunta se torna muy importante, pues como arquitectos de Software, debemos tener un plano en que apoyarnos. Todo desarrollo de software es riesgoso y difcil de controlar, pero si no llevamos una metodologa de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores an ms insatisfechos. Sin embargo, muchas veces no se toma en cuenta el utilizar una metodologa adecuada, sobre todo cuando se trata de proyectos pequeos de dos o tres meses. Lo que se hace con este tipo de proyectos es separar rpidamente el aplicativo en procesos, cada proceso en funciones, y por cada funcin determinar un tiempo aproximado de desarrollo. Cuando los proyectos que se van a desarrollar son de mayor envergadura, ah si toma sentido el basarnos en una metodologa de desarrollo, y empezamos a buscar cual sera la ms apropiada para nuestro caso. Lo cierto es que muchas veces no encontramos la ms adecuada y terminamos por hacer o disear nuestra propia metodologa, algo que por supuesto no esta mal, siempre y cuando cumpla con el objetivo. Muchas veces realizamos el diseo de nuestro software de manera rgida, con los requerimientos que el cliente nos solicit, de tal manera que cuando el cliente en la etapa final (etapa de prueba), solicita un cambio se nos hace muy difcil realizarlo, pues si lo hacemos, altera muchas cosas que no habamos previsto, y es justo ste, uno de los factores que ocasiona un atraso en el proyecto y por tanto la incomodidad del desarrollador por no cumplir con el cambio solicitado y el malestar por parte del cliente por no tomar en cuenta su pedido. Obviamente para evitar estos incidentes debemos haber llegado a un acuerdo formal con el cliente, al inicio del proyecto, de tal manera que cada cambio o modificacin no perjudique al desarrollo del mismo. Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de mencionar, recin en la etapa final del proyecto, pese a que se les mostr un prototipo del software en la etapa inicial del proyecto. Los proyectos en problemas son los que salen del presupuesto, tienen importantes retrasos, o simplemente no cumplen con las expectativas del cliente. Para dar una idea de qu metodologa podemos utilizar y cual se adapta ms a nuestro medio, mencionar tres de ellas de las que considero las ms importantes, tal como: RUP, XP y MSF.

Rational Unified Process (RUP) La metodologa RUP, llamada as por sus siglas en ingls Rational Unified Process, divide en 4 fases el desarrollo del software: Inicio, El Objetivo en esta etapa es determinar la visin del proyecto.

Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima. Construccin, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Transmisin, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteracin se establecen en funcin de la evaluacin de las iteraciones precedentes. Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada bajo dos disciplinas: Disciplina de Desarrollo Ingeniera de Negocios: Entendiendo las necesidades del negocio. Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado. Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de software. Implementacin: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado. Pruebas: Asegurndose que el comportamiento requerido es el correcto y que todo los solicitado esta presente.

Disciplina de Soporte Configuracin y administracin del cambio: Guardando todas las versiones del proyecto. Administrando el proyecto: Administrando horarios y recursos. Ambiente: Administrando el ambiente de desarrollo. Distribucin: Hacer todo lo necesario para la salida del proyecto

Figura 1: Fases e Iteraciones de la Metodologa RUP

Es recomendable que a cada una de estas iteraciones se les clasifique y ordene segn su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentacin que se tendra en cada entregable o en cada iteracin. Los elementos del RUP son:

Actividades, Son los procesos que se llegan a determinar en cada iteracin. Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso. Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms importantes para alcanzar un grado de certificacin en el desarrollo del software.

Extreme Programing (XP) Es una de las metodologas de desarrollo de software ms exitosas en la actualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega era ayer. La metodologa consiste en una programacin rpida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al xito del proyecto.

Figura 2: Metodologa Extreme Programing

Caractersticas de XP, la metodologa se basa en: Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantndonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantramos a obtener los posibles errores. Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean patrones o modelos estndares, siendo ms flexible al cambio. Programacin en pares: una particularidad de esta metodologa es que propone la programacin en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo la accin que el otro no est haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.

Qu es lo que propone XP? Empieza en pequeo y aade funcionalidad con retroalimentacin continua El manejo del cambio se convierte en parte sustantiva del proceso El costo del cambio no depende de la fase o etapa No introduce funcionalidades antes que sean necesarias El cliente o el usuario se convierte en miembro del equipo

Derechos del Cliente Decidir que se implementa Saber el estado real y el progreso del proyecto Aadir, cambiar o quitar requerimientos en cualquier momento Obtener lo mximo de cada semana de trabajo Obtener un sistema funcionando cada 3 o 4 meses

Derechos del Desarrollador Decidir como se implementan los procesos Crear el sistema con la mejor calidad posible Pedir al cliente en cualquier momento aclaraciones de los requerimientos Estimar el esfuerzo para implementar el sistema Cambiar los requerimientos en base a nuevos descubrimientos

Lo fundamental en este tipo de metodologa es: La comunicacin, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codificar los mdulos del sistema La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales

Microsoft Solution Framework (MSF) Esta es una metodologa flexible e interrelacionada con una serie de conceptos, modelos y prcticas de uso, que controlan la planificacin, el desarrollo y la gestin de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnolgicas.

Figura 3: Metodologa MSF

MSF tiene las siguientes caractersticas: Adaptable: es parecido a un comps, usado en cualquier parte como un mapa, del cual su uso es limitado a un especfico lugar. Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as como tambin, proyectos que requieren 50 personas a ms. Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente. Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones basadas sobre

cualquier tecnologa. MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de Diseo de Proceso y finalmente el modelo de Aplicacin.

Modelo de Arquitectura del Proyecto: Diseado para acortar la planificacin del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a travs del lanzamiento de versiones. Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamao del proyecto y del equipo de personas disponibles. Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberacin de versiones y explicando su relacin con el Modelo de equipo. Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratgicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar. Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseo eficiente y flexible a travs de un enfoque iterativo. Las fases de diseo conceptual, lgico y fsico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores. Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para disear y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores.

Conclusin: La Metodologa RUP es mas adaptable para proyectos de largo plazo. La Metodologa XP en cambio, se recomienda para proyectos de corto plazo. La Metodologa MSF se adapta a proyectos de cualquier dimensin y de cualquier tecnologa. Podemos concluir adems, que lo ms importante antes de elegir la metodologa que usars para la implementacin de tu software, es determinar el alcance que tendr y luego de ah ver cual es la que ms se acomoda en tu aplicacin.

Das könnte Ihnen auch gefallen