caracteristicas breves de rup, xp, msf.pdf

5
http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C. informatizate(at) informatizate(dot)net Junio 7 del 2004. ¿Qué metodología debo usar para el desarrollo de un Software? Todos en algún 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 difícil de controlar, pero si no llevamos una metodología de por medio, lo que obtenemos es clientes insatisfechos con el resultado y desarrolladores aún más insatisfechos. Sin embargo, muchas veces no se toma en cuenta el utilizar una metodología adecuada, sobre todo cuando se trata de proyectos pequeños de dos o tres meses. Lo que se hace con este tipo de proyectos es separar rápidamente el aplicativo en procesos, cada proceso en funciones, y por cada función 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 metodología de desarrollo, y empezamos a buscar cual sería la más apropiada para nuestro caso. Lo cierto es que muchas veces no encontramos la más adecuada y terminamos por hacer o diseñar nuestra propia metodología, algo que por supuesto no esta mal, siempre y cuando cumpla con el objetivo. Muchas veces realizamos el diseño de nuestro software de manera rígida, 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 difícil realizarlo, pues si lo hacemos, altera muchas cosas que no habíamos 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 modificación no perjudique al desarrollo del mismo. Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosas que dejaron de mencionar, recién 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é metodología podemos utilizar y cual se adapta más a nuestro medio, mencionaré tres de ellas de las que considero las más importantes, tal como: RUP, XP y MSF.

Upload: vladesf

Post on 13-Dec-2014

47 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: caracteristicas breves de RUP, XP, MSF.pdf

http://www.informatizate.net

Metodologías De Desarrollo De Software

María A. Mendoza Sanchez

Ing. Informático - UNTMicrosoft Certified Professional - MCPAnalísta y Desarrolladora - TeamSoftPerú S.A.C.

informatizate(at)informatizate(dot)netJunio 7 del 2004.

¿Qué metodología debo usar para el desarrollo de un Software?

Todos en algún momento nos hemos hecho esta pregunta, cuando hemos tenido quedesarrollar un software. Y de hecho esta pregunta se torna muy importante, puescomo arquitectos de Software, debemos tener un plano en que apoyarnos.

Todo desarrollo de software es riesgoso y difícil de controlar, pero si nollevamos una metodología de por medio, lo que obtenemos es clientesinsatisfechos con el resultado y desarrolladores aún más insatisfechos.

Sin embargo, muchas veces no se toma en cuenta el utilizar una metodologíaadecuada, sobre todo cuando se trata de proyectos pequeños de dos o tres meses.Lo que se hace con este tipo de proyectos es separar rápidamente el aplicativoen procesos, cada proceso en funciones, y por cada función determinar un tiempoaproximado de desarrollo.

Cuando los proyectos que se van a desarrollar son de mayor envergadura, ahí sitoma sentido el basarnos en una metodología de desarrollo, y empezamos a buscarcual sería la más apropiada para nuestro caso. Lo cierto es que muchas veces noencontramos la más adecuada y terminamos por hacer o diseñar nuestra propiametodología, algo que por supuesto no esta mal, siempre y cuando cumpla con elobjetivo.

Muchas veces realizamos el diseño de nuestro software de manera rígida, con losrequerimientos que el cliente nos solicitó, de tal manera que cuando el clienteen la etapa final (etapa de prueba), solicita un cambio se nos hace muy difícilrealizarlo, pues si lo hacemos, altera muchas cosas que no habíamos previsto, yes justo éste, uno de los factores que ocasiona un atraso en el proyecto y portanto la incomodidad del desarrollador por no cumplir con el cambio solicitado yel malestar por parte del cliente por no tomar en cuenta su pedido. Obviamentepara evitar estos incidentes debemos haber llegado a un acuerdo formal con elcliente, al inicio del proyecto, de tal manera que cada cambio o modificación noperjudique al desarrollo del mismo.

Por experiencia, muchas veces los usuarios finales, se dan cuenta de las cosasque dejaron de mencionar, recién en la etapa final del proyecto, pese a que seles mostró un prototipo del software en la etapa inicial del proyecto.

Los proyectos en problemas son los que salen del presupuesto, tienen importantesretrasos, o simplemente no cumplen con las expectativas del cliente.

Para dar una idea de qué metodología podemos utilizar y cual se adapta más anuestro medio, mencionaré tres de ellas de las que considero las másimportantes, tal como: RUP, XP y MSF.

Page 2: caracteristicas breves de RUP, XP, MSF.pdf

Rational Unified Process (RUP)

La metodología RUP, llamada así por sus siglas en inglés Rational UnifiedProcess, divide en 4 fases el desarrollo del software:

• Inicio, El Objetivo en esta etapa es determinar la visión del proyecto. • Elaboración, En esta etapa el objetivo es determinar la arquitectura

óptima. • Construcción, En esta etapa el objetivo es llevar a obtener la capacidad

operacional inicial. • Transmisión, El objetivo es llegar a obtener el release del proyecto.

Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, lacual consiste en reproducir el ciclo de vida en cascada a menor escala. LosObjetivos de una iteración se establecen en función de la evaluación de lasiteraciones precedentes.

Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, esllevada bajo dos disciplinas:

Disciplina de Desarrollo

• Ingeniería de Negocios: Entendiendo las necesidades del negocio.

• Requerimientos: Trasladando las necesidades del negocio a un sistemaautomatizado.

• Análisis y Diseño: Trasladando los requerimientos dentro de laarquitectura de software.

• Implementación: Creando software que se ajuste a la arquitectura y quetenga el comportamiento deseado.

• Pruebas: Asegurándose que el comportamiento requerido es el correcto y quetodo los solicitado esta presente.

Disciplina de Soporte

• Configuración y administración del cambio: Guardando todas las versionesdel proyecto.

• Administrando el proyecto: Administrando horarios y recursos.

• Ambiente: Administrando el ambiente de desarrollo.

Distribución: Hacer todo lo necesario para la salida del proyecto

Figura 1: Fases e Iteraciones de la Metodología RUP

Page 3: caracteristicas breves de RUP, XP, MSF.pdf

Es recomendable que a cada una de estas iteraciones se les clasifique y ordenesegún su prioridad, y que cada una se convierte luego en un entregable alcliente. Esto trae como beneficio la retroalimentación que se tendría en cadaentregable o en cada iteración.

Los elementos del RUP son:

• Actividades, Son los procesos que se llegan a determinar en cadaiteración.

• Trabajadores, Vienen hacer las personas o entes involucrados en cadaproceso.

• Artefactos, Un artefacto puede ser un documento, un modelo, o un elementode modelo.

Una particularidad de esta metodología es que, en cada ciclo de iteración, sehace exigente el uso de artefactos, siendo por este motivo, una de lasmetodologías más importantes para alcanzar un grado de certificación en eldesarrollo del software.

Extreme Programing (XP)

Es una de las metodologías de desarrollo de software más exitosas en laactualidad utilizadas para proyectos de corto plazo, corto equipo y cuyo plazode entrega era ayer. La metodología consiste en una programación rápida oextrema, 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: Metodología Extreme Programing

Características de XP, la metodología se basa en:

• Pruebas Unitarias: se basa en las pruebas realizadas a los principalesprocesos, de tal manera que adelantándonos en algo hacia el futuro,podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nosadelantáramos a obtener los posibles errores.

• Refabricación: se basa en la reutilización de código, para lo cual secrean patrones o modelos estándares, siendo más flexible al cambio.

• Programación en pares: una particularidad de esta metodología es quepropone la programación en pares, la cual consiste en que dosdesarrolladores participen en un proyecto en una misma estación detrabajo. Cada miembro lleva a cabo la acción que el otro no está haciendoen ese momento. Es como el chofer y el copiloto: mientras uno conduce, elotro consulta el mapa.

Page 4: caracteristicas breves de RUP, XP, MSF.pdf

¿Qué es lo que propone XP?

• Empieza en pequeño y añade funcionalidad con retroalimentación 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 • Añadir, cambiar o quitar requerimientos en cualquier momento • Obtener lo máximo 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 metodología es:

• La comunicación, entre los usuarios y los desarrolladores

• La simplicidad, al desarrollar y codificar los módulos delsistema

• La retroalimentación, concreta y frecuente del equipo dedesarrollo, el cliente y los usuarios finales

Microsoft Solution Framework (MSF)

Esta es una metodología flexible e interrelacionada con una serie de conceptos,modelos y prácticas de uso, que controlan la planificación, el desarrollo y lagestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y deequipo dejando en un segundo plano las elecciones tecnológicas.

Figura 3: Metodología MSF

MSF tiene las siguientes características:

• Adaptable: es parecido a un compás, usado en cualquier parte como un mapa,del cual su uso es limitado a un específico lugar.

• Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, asícomo también, proyectos que requieren 50 personas a más.

• Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.

• Tecnología Agnóstica: porque puede ser usada para desarrollar solucionesbasadas sobre cualquier tecnología.

Page 5: caracteristicas breves de RUP, XP, MSF.pdf

MSF se compone de varios modelos encargados de planificar las diferentes partesimplicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo deDiseño de Proceso y finalmente el modelo de Aplicación.

Copyright © 2002-2004 Grupo Informatizate. Reservados todos los derechos. Prohibida la reproducción total o parcial en cualquier formato sin previa autorización.

On-line desde el 27 de Noviembre del 2002