Metodologias

INTRODUCCION

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

DESCRIPCION DEL PROBLEMA

PROPUESTA

IMPACTO

FUNDAMENTACION (DE DONDE SURGE LA NECESIDAD )

ESTRUCTURA DEL ENSAYO (RELATAR EN QUE CONSISTE )

ESTADO DEL ARTE

METODOLOGIAS TRADICIONALES

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas podemos citar:

*RUP (Rational Unified Procces):

La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).

Figura 1: Historia de RUP

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado.

*MSF (Microsoft Solution Framework)

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 la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas. MSF es un compendio de las mejores prácticas en cuanto a administración de proyectos se refiere. Más que una metodología rígida de administración de proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto de tecnología de información.

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 soluciones basadas sobre cualquier tecnología. 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 Gestión del Riesgo, Modelo de Diseño de Proceso y finalmente el modelo de Aplicación.

Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a través del lanzamiento de versiones.

Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles.

Modelo de Proceso: Diseñado 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 liberación de versiones y explicando su relación con el Modelo de equipo.

Modelo de Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratégicas 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 Diseño del Proceso: Diseñado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eficiente y flexible a través de un enfoque iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores.

Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar 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.

*Win-Win Spiral Model

Con la variante trata de ajustarse más a la realidad de lo que es un proyecto de desarrollo de software, en el cual el resultado final no es exactamente la implementación del catálogo de requisitos, sino que una vez definido se renegocia el alcance del mismo, incluso en diversas partes del proyecto, entre cliente y proveedor con el objetivo de intentar que ambas partes queden satisfechas (aunque en la mayoría de los casos, cada parte solo se mire su ombligo).

La variante se basa en la inclusión de tres etapas o regiones al principio:

1.- Identificar las partes interesadas (stakeholders) para esta nueva iteración del producto: Es necesario definir los interlocutores que serán de áreas que se verán afectadas por el resultado final de la nueva versión. Estos interlocutores serán del área del cliente (puede haber más de uno) y del proveedor.

2.- Identificar las condiciones de victoria de las partes interesadas en el proyecto: Se concreta cuáles son las condiciones que requiere cada parte para que se sienta satisfecha una vez realizada esta versión.

3- Reunir las condiciones de victoria: Con las etapas anteriores se han definido unos objetivos generales para la versión y se obtiene conocimiento de los objetivos particulares de cada parte. Ahora toca negociar hasta dónde realmente se va a llegar y cómo, intentando llegar a una solución en la que todos ganen (cliente y proveedor).

Las siguientes etapas tienen una correspondencia con algunas variantes, con la versión inicial del ciclo de vida en espiral:

3- Establecer los objetivos, restricciones y alternativas del siguiente nivel: Teniendo en cuenta los objetivos y acuerdos de las fases anteriores, se definirían los requisitos de esta versión, además de especificarse diversas alternativas en el caso de que existan.

4.- Evaluar las alternativas del producto y del proceso y resolución de riesgos: Se realizaría el análisis del riesgo típico de los modelos en espiral.

5.- Definir el siguiente nivel del producto y del proceso, incluyendo particiones: Esta etapa completaría el proceso de análisis y realizaría el diseño y la construcción.

6.- Validar las definiciones del producto y del proceso: Comprendería la implantación y aceptación de la versión, verificándose si el resultado de la iteración satisface el alcance indicado.

7.- Revisión y comentarios: Tocaría hacer inventario, medir el nivel de satisfacción de las partes, el nivel de cumplimiento de objetivos con el objetivo sobre todo de intentar aprender de los errores para mejorar en versiones sucesivas y de detectar correcciones y mejoras a realizar en el producto.

Lo más interesante del modelo es que se especifique de forma explícita la necesidad de que las partes negocien para llegar a un acuerdo satisfactorio para todos, por eso esta variante recibe el nombre de Win Win. Aunque es complicado alcanzar un equilibrio en el que ambas partes ganen a un 50%, sí que es fundamental que independientemente de si uno es un poco más ganador que el otro, todas las partes estén convencidas en que el acuerdo es bueno.

En cualquier caso sigue sin ser absolutamente

...