Ver el código de «Metodologias de desarrollo de Software»


{{Definición
|nombre= Metodologías de Desarrollo de Software
|imagen=480px-Software_development_methodologies.jpg
|tamaño=
|concepto=
}}
'''Metodologías de desarrollo de Software.''' Lograr la construcción de un sistema informático eficiente, que cumpla con los requerimientos planteados, es una tarea realmente intensa y sobre todo difícil de cumplir. Las metodologías para el desarrollo del software imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Una metodología de desarrollo de software tiene como principal objetivo aumentar la calidad del software que se produce en todas y cada una de sus fases de desarrollo. No existe una metodología de software universal, ya que toda metodología debe ser adaptada a las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigiéndose así que el proceso sea configurable. Las metodologías de desarrollo se pueden dividir en dos grupos de acuerdo con sus características y los objetivos que persiguen: ágiles y robustas.
== Las metodologías ágiles == 
Se caracterizan por hacer énfasis en la comunicación cara a cara, es decir, se basan en una fuerte y constante interacción, donde clientes desarrolladores y desarrolladores trabajan constantemente juntos, estableciéndose así una estrecha comunicación. Estas metodologías están orientadas al resultado del producto y no a la documentación; exige que el proceso sea adaptable, permitiendo realizar cambios de último momento. Se puede hacer mención dentro de las metodologías ágiles a: XP (por sus siglas en inglés Extreme Programming), Scrum y Crystal Methodologies. 
=== Extreme Programming (XP) ===
Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de [[software]], promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. [[Kent Beck]], el padre de XP, describe la filosofía de XP sin cubrir los detalles técnicos y de implantación de las prácticas. Posteriormente, otras publicaciones de experiencias se han encargado de dicha tarea. A continuación presentaremos las características esenciales de XP organizadas en los tres apartados siguientes: historias de usuario, roles, proceso y prácticas.
=== Scrum === 
Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, especialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.
=== Crystal Methodologies === 
Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Cristal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).
== Las metodologías robustas o tradicionales ==
Están guiadas por una fuerte planificación. Centran su atención en llevar una documentación exhaustiva de todo el proceso de desarrollo y en cumplir con un plan de proyecto, definido en la fase inicial del mismo. Entre las metodologías robustas se encuentran: MSF (por sus siglas en inglés Microsoft Solution Framework), MÉTRICA 3 y RUP (siglas de Rational Unified Process). 
=== 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 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. Dentro de sus principales características se tiene que es:
* 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. La Metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.
=== Métrica 3 ===
MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistemas de información. Ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:
* Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.
* Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.
* Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
* Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
* Facilitar la operación, mantenimiento y uso de los productos software obtenido.
Esta metodología tiene un enfoque orientado al proceso, ya que la tendencia general en los estándares se encamina en este sentido y por ello, se ha enmarcado dentro de la norma ISO 12.207, que se centra en la clasificación y definición de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma, MÉTRICA Versión 3 cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Información. MÉTRICA Versión 3 ha sido concebida para abarcar el desarrollo completo de Sistemas de Información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto.
=== Proceso Unificado de Desarrollo (RUP) ===
RUP es un proceso para el desarrollo de un proyecto de software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. La versión de RUP que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este proceso de desarrollo. Dicho proceso tiene tres características fundamentales. La primera es que está dirigido por casos de uso, es decir, que en el proyecto se orientan a la importancia que tiene para el usuario lo que el producto debe hacer. También es un proceso centrado en la arquitectura ya que relaciona la toma de decisiones que indican cómo tiene que ser constituido el sistema y en qué orden se debe hacer. Es iterativo e incremental, divide el proyecto en mini proyectos donde los casos de usos y la arquitectura cumplen sus objetivos de manera más depurada.
RUP se encarga de unificar todo el equipo de desarrollo de software, además de optimizar su comunicación. Para esto provee a cada miembro del proyecto una aproximación al desarrollo de software con una base de conocimiento de acuerdo con las necesidades específicas del proyecto. No es simplemente un proceso, sino que es un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. Generalmente es aplicado a grandes proyectos de desarrollo de software. Dentro de sus disciplinas gestiona el control de cambios, que permite mantener al equipo trabajando en los mismos artefactos, en cualquier momento del desarrollo del producto. RUP define como sus principales elementos a los trabajadores, las actividades, los artefactos y los flujos de actividades. Los trabajadores son los propietarios de elementos o artefactos y se encargan de realizar las actividades, las cuales se describen cómo una tarea que es realizada por un trabajador. Los artefactos constituyen los productos tangibles del proyecto que son producidos, modificados y usados por las actividades. El flujo de actividades se describe cuando estas son realizadas por trabajadores y produce un resultado de valor observable. 
=== Recomendación ===
Se recomienda la utilización de RUP como metodología de desarrollo de software para guiar el proceso de desarrollo cuándo se está en presencia de proyectos complejos y de larga duración. Además cuándo el equipo de desarrollo del proyecto tiene experiencia en su aplicación, se obtienen resultados positivos con su uso. También se recomienda cuando se cuenta con un cliente que no mantiene una relación directa con el equipo de desarrollo. Al ser RUP una metodología eficaz que se adapta a las características propias del software que se desarrolla, se pueden eliminar los riesgos que podrían presentarse durante el desarrollo del mismo. Permitiendo así enfocarse en trabajar de forma organizada, donde se controla y documenta todo lo relacionado con el proyecto. Con la utilización de RUP se genera la documentación que es imprescindible para desarrollar el proyecto o para presentárselo al cliente. En esencia, esta metodología genera los artefactos necesarios y lo que no se necesitan no se generan. 
== No son Metodologías de Desarrollo de Software: ==
La "Programación estructurada" o la "Programación Orientada a Objetos" son paradigmas o modelos de programación. Indican pautas de comportamiento en los sistemas de programación. No tienen que ver con el ciclo de vida del software ni la manera en la que debe realizarse cada tarea para un proyecto concreto, así pues NO SON METODOLOGÍAS.
Los términos "Ciclo de vida en espiral", "Incremental", en "Cascada", con "prototipo", etc., indican esquemas generales de organización en las tareas del ciclo de vida, unas con respecto a otras y con respecto a otros aspectos como el tiempo, los requisitos o el riesgo. Actualmente se denominan "PATRONES" del ciclo de vida del software, aunque antaño fueron denominados simplemente distintos "Ciclos de vida". Indican ideas estructurales sencillas en el proceso de desarrollo, y no la manera en la que debe realizarse cada tarea del ciclo para un proyecto concreto, así pues, NO SON METODOLOGÍAS.
El lenguaje UML (Unified Modeling Languaje) es un gran logro de la ingeniería. Aún con sus carencias, es algo muy importante: un lenguaje común para que todos los profesionales del desarrollo de sistemas -de software o no expresen sus ideas, pero UML no le indica a nadie la manera de realizar las tareas en un proyecto concreto: tan solo es una herramienta para expresar ideas, así pues NO ES UNA METODOLOGÍA. Sin embargo, algunas metodologías de las que hemos comentado, como RUP o METRICA hacen referencia a UML como lenguaje de modelado para expresar ideas.
==Véase también==
*[[RUP]]
*[[Agile_Unified_Process|AUP]]
==Fuentes==
* Taller sobre Metodologías Ágiles en el Desarrollo de Software. 2003.
* [http://es.scribd.com/doc/8255409/ Metodologias-para-la-geston-y-desarrollo-de-Software.]
* [http://www.rational.com.ar/herramientas/rup.html/ Rational]
* Jacobson, Ivar, Booch, Grady y Rumbaugh, James. El Proceso Unificado de Desarrollo de Software. España
* Pressman, Roger S. "Ingeniería del Software: Un Enfoque Práctico". Quinta Edición.
[[Category:Ciencias_informáticas]]