METODOLOGIA

ESTABILIDAD
No es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin.

FLEXIBILIDAD
Constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

RENDIMIENTO
Aumenta la productividad de los desarrolladores mediante acceso a: Base de conocimiento, plantillas y herramientas. Se centra en la produccin y mantenimiento de modelos del sistema ms que en producir documentos. RUP es una gua de cmo usar UML de la forma ms efectiva. Existen herramientas de Apoyo a todo el proceso: Moldeamiento visual, programacin y pruebas. Reunin diaria de todo el equipo. Tiene que hacerse de la siguiente forma: - La reunin es diaria y se hace siempre a una hora predefinida, normalmente por la maana. Es importante que todos los miembros del equipo acudan puntuales. - La reunin debe durar alrededor de 15 minutos y se realiza de pie, para

REQUERIMIENTOS DISEO
Obtener los requerimientos, Organizarlos, Documentar requerimientos de funcionalidad y restricciones - Rastrear y documentar decisiones Captar y comunicar requerimientos del negocio - Los casos de uso y los escenarios indicados por el proceso han probado ser una buena forma de captar requerimientos y guiar el diseo, la implementacin y las pruebas. Se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.

IMPLEMENTACION PRUEBA
Completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.

RUP

SCRUM

-Se puede utilizar como complemento a prcticas de desarrollo ya existente. - Los equipos se autogestionan. -El cliente participa y dirige el proyecto. - Las prioridades se establecen en funcin del valor de negocio que aportan. Cuenta con certificacin oficial.

Incorpora cambios con rapidez y en cualquier fase del proyecto.

Si el sistema desarrollar es uno nuevo, esta fase consiste en la definicin de los conceptos y anlisis del sistema. Si por el contrario el sistema es uno existente, esta fase consiste en un anlisis limitado.

Se indican cmo se van implementar los tems de la lista del backlog. En esta fase se debe realizar un esbozo de la arquitectura a alto nivel.

Es donde se desarrollan las nuevas funcionalidades del sistema, siempre respetando las variables de tiempo, requisitos, calidad, coste y competitividad. La interaccin con estas variables define el resultado de esta fase. Existen varios sprints de desarrollo iterativos, que son usados para evolucionar el sistema hacia su completitud.

Se realizan las preparaciones para la entrega, que incluye la documentacin final, los resultados de las fases de test y finalmente el entregable.

mantener mximo concentracin atencin.

el de y

OPENUP

-Documentacin y
guas exhaustivas. - Fases del proceso, roles, tareas y deliverables claramente definidos.

Esta metodologa puede ser aplicada en cualquier proyecto de desarrollo, aunque no hay datos concretos en cuanto a tamao del equipo, limitaciones tecnolgicas o de cultura de empresa,

Una de sus fortalezas radica en su extensibilidad, siempre que sea necesario aadir ms elementos a la metodologa.

Las necesidades de cada participante del proyecto son tenidas en cuenta y son plasmadas en objetivos del proyecto. Se deben definir el mbito del proyecto, los lmites del mismo y el criterio de aceptacin del proyecto. Los casos de uso crticos, aquellos que dirigen la funcionalidad del sistema, son definidos en esta fase, as como una estimacin inicial del coste del proyecto y un boceto de la planificacin.

Se deben establecer unos requisitos y arquitectura estables. Por otro lado el proceso de desarrollo, las herramientas, la infraestructura a utilizar y el entorno de desarrollo tambin se especifican en detalle en esta fase. Al final de la fase se debe tener una definicin clara y precisa de los casos de uso, los actores, la arquitectura del sistema y un prototipo ejecutable de la misma.

Todos los componentes y funcionalidades del sistema que falten por implementar son realizados, testeados e integrados en esta fase. Los resultados obtenidos en forma de incrementos ejecutables deben ser desarrollados de la forma ms rpida posible sin dejar de lado la calidad de lo desarrollado.

MERINDE

Los proyectos de software en MeRinde mientras ms grandes sean requerirn un mayor control para asegurar que se cumplan con los objetivos del mismo y que no existan desviaciones.

Es un marco de desarrollo ajustable que tiene como objetivo mantener la agilidad durante el proceso de desarrollo, establecer planes con representacin realista, y estimaciones conforme a las condiciones del proyecto y durante todo el ciclo de vida del proyecto. MeRinde propicia a

-Adaptar el proceso de desarrollo -Alto nivel de abstraccin -Centrarse en la arquitectura -Cdigo estndar -Colaboracin entre equipo -Demostrar resultados iterativamente e

Su propsito general es establecer los objetivos para el ciclo de vida del producto. Durante esta fase se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y casos de uso. Se desarrolla, un plan de negocio para determinar qu recursos deben ser asignados al proyecto.

Se construye un modelo de la arquitectura, que se desarrolla en iteraciones sucesivas hasta obtener el producto final, este prototipo debe contener los casos de uso crticos que fueron identificados en la fase de inicio. En esta fase se realiza la captura de la mayor parte de los requerimientos

Alcanzar la capacidad operacional del producto de forma incremental a travs de las sucesivas iteraciones. En esta fase todas las caractersticas, componentes, y requerimientos deben ser integrados, implementados, y probados en su totalidad, obteniendo una versin aceptable del producto comnmente llamada

Cuando el producto est lo suficientemente maduro (algo que es establecido por ejemplo en funcin del nmero de peticiones de cambio por parte de los clientes) como para ser introducido en la comunidad de usuarios, el proyecto se encuentra en esta fase. Las fases de la transicin constan de subfases de testeo de versiones beta, pilotaje y capacitacin de los usuarios finales y de los encargados del mantenimiento del sistema. En funcin de la respuesta obtenida por los usuarios. Se entrega el producto funcional en manos de los usuarios finales una vez realizadas las pruebas de aceptacin por un grupo especial de usuarios, para lo que se requerir desarrollar nuevas versiones actualizadas del producto, entrenar a los usuarios en el manejo del sistema,

que los planificadores de los proyectos ajusten el proceso de desarrollo a sus necesidades ya que no tiene como objetivo ser prescriptiva.

incrementalmente -Dirigido por Casos de Uso -Diseo simple -Enfoque continuo en la calidad -Enfoque en los riesgos -Fomento del aprendizaje de experiencias -Interaccin contina con cliente -Modelar el software -Permanecer gil y esperar los cambios

funcionales, manejando los riesgos que interfieran con los objetivos del sistema, acumulando la informacin necesaria para el plan de construccin y obteniendo suficiente informacin para hacer realizable el caso del negocio.

versin beta.

completar

WATCH

Est slidamente fundamentado, posee una base conceptual y metodolgica muy bien sustentada. El mtodo descansa en conceptos bien establecidos que se derivan de la Ingeniera de Software y los Sistemas de Informacin Empresarial. En concreto, el mtodo emplea una arquitectura de dominio de tres capas que define los elementos principales de las aplicaciones empresariales

Es flexible y adaptable, si bien el mtodo est dirigido al desarrollo de aplicaciones especializadas (aplicaciones de software empresarial), sus tres componentes pueden ser adaptados, con relativa facilidad, a otros tipos de productos de software. Esta labor, sin embargo, debe ser hecha por expertos en Ingeniera de Procesos de Software, para asegurar la correcta y efectiva adaptacin a

-Incremental iterativo.

-De propsito especifico. -Flexible adaptable. y

-Integra los procesos de gestin con los procesos tcnicos y de soporte.

Es aqu donde el analista se pone en contacto con el cliente para ver cules son sus necesidades o requerimientos y as poder realizar un anlisis del mismo y posteriormente realizar los diagramas con todo lo que debe llevar para realizar el sistema.

Aqu es donde entran las pantallas, base de datos, colores, tamao de botones etc.

Es aqu donde desarrolla codificacin.

se la

Es aqu donde se pone a prueba y se corrigen los posibles errores que se generan en el sistema para luego proceder a la instalacin del mismo para su uso correspondiente.

modernas. Metodolgicamente, el modelo ha sido elaborado tomando como referencia modelos de procesos bien conocidos o bien fundamentados, tales como el modelo RUP-Rational Unified Process (Krutchen, 2000) y versiones anteriores del mtodo WATCH (Montilva y Barrios, 2004b).

otros tipos aplicaciones.

de

XP

Practicas a nivel tecnolgico fuertes. - El cliente es el que indica las funcionalidades del producto, el desarrollador es el que indica las estimaciones. -Feedback continuo, tanto por parte del cliente como del desarrollador. - Es el enfoque gil ms conocido y adoptado.

XP es gil por estar alineado con el principio de agilidad del Agile Manifesto, es adaptativo porque todo el equipo adapta el proceso de desarrollo para mejorar los resultados. Los detalles de un proyecto difieren de otro, pero los principios de XP se mantienen inalterados en ambos, se adapta el proceso para que se ajuste al proyecto en concreto. Las buenas prcticas recogidas en XP promueven la cooperacin entre los miembros del equipo y se enfocan a reducir el coste que se deriva de cualquier cambio

-Desarrollo iterativo e incremental. -Pruebas unitarias continuas, frecuentemente repetidas y automticas. -Programacin parejas. en

-Frecuentemente interaccin del equipo de programacin con el cliente o usuario. -Correccin de todos los errores antes de aadir nueva funcionalidad. -Hacer entregas frecuentes. -Refactorizacin del cdigo.

Durante este tiempo, el equipo se familiariza con las tecnologas, herramientas y prcticas que debern usar durante la realizacin del proyecto. Se realiza un prototipo del sistema con el fin de obtener un posible boceto de la arquitectura del sistema. Esta fase puede durar entre pocas semanas a varios meses, dependiendo del grado de familiarizacin de los integrantes del equipo con el dominio y tecnologas a utilizar.

Los programadores hacen una estimacin de los esfuerzos necesarios para cada historia y se realiza una planificacin. Esta fase no suele durar ms de un par de das, y la entrega de la primera fase no debe demorarse ms de un par de meses.

En esta fase se realizan diversas iteraciones hasta la realizacin del primer entregable. Cada una de las cuales suele durar entre una a cuatro semanas. En la primera iteracin se debe realizar un esbozo de la arquitectura de todo el sistema. Para el resto de iteraciones el cliente elige que historias de se debe implementar en cada una de ellas. Los tests funcionales creados por el cliente son ejecutados al final de cada iteracin.

Se realizan fases de testeo y chequeo del sistema en general antes de su entrega al cliente. Es posible que en esta fase aparezca la necesidad de implantar nuevos cambios que habr que decidir si se implementan en esta iteracin o en la siguiente.

introducido.

-Propiedad del cdigo compartida: promueve el que todo personal pueda corregir y extender cualquier parte del Proyecto. - Simplicidad en el cdigo

UP

FDD

Gua a los equipos de proyecto en cmo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. No cubre todo el ciclo de vida, sino diseo y construccin Se considera apto para proyectos mayores o de misin crtica. La parte iterativa soporta desarrollo gil con rpidas adaptaciones a

Proceso de desarrollo de software configurable que se adapta a proyectos que varan en tamao y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa de objetos en el desarrollo de software de misin crtica en una variedad de industrias. Uno de los componentes clave es el UML.

Se puede utilizar por s mismo o con otras herramientas y tcnicas como el Proceso Rational para planear, construir y administrar el desarrollo de soluciones de negocio a la medida

Define el alcance y factibilidad del proyecto.

Planifica el proyecto, especifica las caractersticas y la arquitectura base.

Construye el proyecto.

Una vez realizadas las pruebas se procede a entregar el producto a los usuarios.

A diferencia de otros -Incremental: Liberaciones pequeas procesos giles no cubre todo el ciclo de vida y ciclos rpidos. sino slo las fases de diseo y construccin. -Cooperativo: Clientes y desarrolladores No requiere un modelo trabajando juntos. especfico de proceso y se complementa con -Simple y Directo: otras metodologas. El mtodo es fcil de aprender y modificar.

El modelo global de dominio es elaborado por expertos del dominio y desarrolladores; El modelo de dominio consiste en diagramas de clases con clases, relaciones, mtodos y atributos. Los mtodos no reflejan

Los ensayos, modelos de objeto y documentacin de requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos son pequeos tems tiles a los ojos del cliente. La lista de rasgos es revisada

cambios en -Adaptativo: Enfatiza cuestiones de requerimientos y Es posible realizar calidad y define necesidades del cambios de ltimo claramente entregas negocio. momento. tangibles y formas de evaluacin del progreso. Cada fase del proceso tiene un Se basa en un proceso criterio de entrada, iterativo con iteraciones tareas, pruebas y un cortas que producen un software funcional que criterio de salida. el cliente y la direccin de la empresa pueden ver y monitorizar.

conveniencias de programacin sino rasgos funcionales. Cuando comienza el desarrollo, los expertos de dominio estn al tanto de la visn, el contexto y los requerimientos del sistema a construir. A esta altura se espera que existan requerimientos tales como casos de uso o especificaciones funcionales.

por los usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que requieran de ms de diez das se descomponen en otros ms pequeos.