jueves, 15 de octubre de 2009

SCRUM

Scrum

Scrum es un proceso de desarrollo de software iterativo y creciente utilizado comúnmente en entornos basados en el desarrollo ágil de software.
Aunque Scrum estaba enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software, o en una aproximación de gestión de programas: Scrum de Scrums.

Historia

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales.[1] Takeuchi y Nonaka comparan esta nueva aproximación holística, en la cual las fases se traslapan de manera intensa y el proceso completo es realizado por un equipo con funciones transversales, con el rugby, donde el equipo entero «actúa como un solo hombre para intentar llegar al otro lado del campo, pasando el balón de uno a otro».[cita requerida] Los casos de estudio provienen de las industrias automovilísticas, así como de fabricación de máquinas fotográficas, computadoras e impresoras.
En 1991 Peter DeGrace y Leslie Stahl en su libro Wicked Problems, Righteous Solutions (A problemas malvados, soluciones virtuosas),[2] se refirieron a esta aproximación como scrum (melé en inglés), un término propio del rugby mencionado en el artículo por Takeuchi y Nonaka.
A principios de los años 1990 Ken Schwaber empleó una aproximación que lo llevó a poner en práctica el scrum en su compañía, Advanced Development Methods.[cita requerida] Por aquel tiempo Jeff Sutherland desarrolló una aproximación similar en Easel Corporation y fue el primero en denominarla scrum.[3] En 1995 Sutherland y Schwaber, durante el OOPSLA '95 desarrollado en Austin, presentaron en paralelo una serie de artículos describiendo scrum, siendo ésta la primera aparición pública de la metodología.[cita requerida] Durante los años siguientes, Schwaber y Sutherland, colaboraron para consolidar los artículos antes mencionados, así como sus experiencias y el conjunto de mejores prácticas de la industria que conforman a lo que ahora se le conoce como scrum.[cita requerida] En 2001, Schwaber y Mike Beedle describieron la metodología en el libro Agile Software Development with Scrum.

Características de Scrum

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre 15 y 30 días (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint.[4] Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

Roles en Scrum

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. El nombre de los grupos están inspirados en el chiste sobre un cerdo y una gallina que se relata a continuación.
Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: "Hey, ¿por qué no abrimos un restaurante?" El cerdo mira a la gallina y le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La gallina piensa un poco y contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tú solamente estarías involucrada".
De esta forma, los cerdos están comprometidos a construir software de manera regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto pero realmente irrelevantes porque, si éste falla, no son un cerdo, es decir, no son los que se habían comprometido a sacarlo adelante. Las necesidades, deseos, ideas e influencias de los roles gallina se tienen en cuenta, pero no de forma que pueda afectar, distorsionar o entorpecer el proyecto Scrum.

Reuniones en Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:

-La reunión comienza puntualmente a su hora. A menudo hay castigos -decididos por el equipo- para quién llega tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plástico del cuello)
-Todos son bienvenidos, pero solo los "cerdos" pueden hablar
-La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo.
-Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta)
-La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días.
-Durante la reunión, cada miembro del equipo contesta a tres preguntas:

-¿Qué has hecho desde ayer?
-¿Qué es lo que estás planeando hacer hoy?
-¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos).

Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Esta reunión tiene un tiempo fijo de cuatro horas.
Scrum permite la creación de equipos autoorganizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes.

Scrum aplicado al desarrollo de software

Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance.

Metodologias Agiles de Desarrollo

Metodologías Ágiles de desarrollo de software

Este en esta primera parte se describen las principales características de de las metodologías ágiles, expresadas en el Manifiesto, sus ventajas y desventajas, así como algunos casos donde no conviene usar métodos ágiles.
Hoy en día con el auge de la tecnología, y con el objetivo de agilizar y automatizar los procesos en el desarrollo de software, nos vemos en la necesidad de implantar Metodologías de Desarrollo de Software que nos ayuden a entregar un producto de calidad en tiempo y costo estimados, las metodologías ágiles de desarrollo de software han despertado interés gracias a que proponen simplicidad y velocidad para crear sistemas. Las metodologías tradicionales no se adaptan a las nuevas necesidades o expectativas que tienen los usuarios hoy en día, en parte que los métodos usados no son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos cambios generalmente implican altos costos, demanda de tiempo y la reestructuración total del proyecto que se esté llevando; en contraparte, los métodos ágiles permiten un desarrollo iterativo y adaptable que permite la integración de nuevas funcionalidades a lo largo del desarrollo del proyecto; para que tanto el cliente como el desarrollador queden satisfechos porque el producto final tiene una calidad adecuada.
Un proceso es ágil cuando el desarrollo de software es:
- Incremental. Entregas pequeñas de software, con ciclos rápidos.
- Cooperativo. Cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación.
- Sencillo. El método en sí mismo es simple, fácil de aprender y modificar.
- Esta bien documentado y es adaptable. Permite realizar cambios de último momento).

Sus elementos claves son:

– Poca documentación
– Simplicidad
– Análisis como una actividad constante
– Diseño evolutivo
– Integraciones
– Testeos diarios


Cuando usar metodologías ágiles

No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema). Históricamente, las metodologías tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeños y con requisitos muy cambiantes. Las metodologías ágiles ofrecen una solución casi adecuada para una gran cantidad de proyectos. Sin embargo existen métodos más generales y con mejores resultados que otros. Saber qué reglas y metodologías aplicar en cada caso es más importante y útil que seguir ciegamente siempre las mismas.
Las propias prácticas de los métodos ágiles limitan o descartan su uso en algunos proyectos. A continuación se detallan algunos casos donde no conviene usar métodos ágiles.
Las propias prácticas de los métodos ágiles limitan o descartan su uso en algunos proyectos. A continuación se detallan algunos casos donde no conviene usar métodos ágiles.

-Aplicaciones distribuidas. Las pruebas unitarias son complicadas de aplicar entre componentes. Sería necesario construir una arquitectura de pruebas para probar directamente los componentes, que podría ser tan complicada como el sistema que se desea construir.
-Aplicaciones que requieren seguir un diseño estricto. Por ejemplo: sistemas operativos, software de telecomunicaciones.
-Aplicaciones que requieren una documentación exhaustiva. Por ejemplo: sistemas militares, médicos o industriales.
-Aplicaciones basadas fundamentalmente en interfaces gráficas de usuario: No es fácil aplicar pruebas unitarias a las interfaces gráficas.
-Aplicaciones con código heredado. Habría que reescribir todo el código heredado siguiendo los principios ágiles.
-Proyectos muy grandes. La comunicación entre los miembros del equipo es difícil de conseguir.
-Proyectos escritos en lenguajes no orientados a objetos. Lenguajes como C, Pascal, Cobol o Fortran hacen imposible técnicas como la refactorización.
-Aplicaciones donde la escalabilidad o la eficacia sean importantes. La escalabilidad o la eficacia no son características que se pueden añadir durante el proceso del desarrollo del software o que puedan obtenerse refactorizando: deben considerarse desde un principio.

Ventajas de las metodologías ágiles

Las metodologías ágiles presentan diversas ventajas como:

-Rápida respuesta a cambios de requisitos a lo largo del desarrollo.
-Entrega continua y en plazos cortos de software funcional.
-Trabajo conjunto entre el cliente y el equipo de desarrollo.
-Minimiza los costos frente a cambios.
-Importancia de la simplicidad, al eliminar el trabajo innecesario.
-Atención continua a la excelencia técnica y al buen diseño.
-Mejora continua de los procesos y el equipo de desarrollo.
-Evita malentendidos de requerimientos entre el cliente y el equipo.
-El equipo de desarrollo no malgasta el tiempo y dinero del cliente desarrollando soluciones innecesariamente generales y complejas que en realidad no son un requisito del cliente.
-Cada componente del producto final ha sido probado y satisface los requerimientos.

Problemas comunes a los métodos ágiles.

Como en cualquiera otra metodología, también hay desventajas y problemas que surgen a la hora de implementarlas:

-Falta de documentación del diseño. El código no puede tomarse como una documentación. En sistemas de tamaño grande se necesitar leer los cientos o miles de páginas del listado de código fuente.
-Problemas derivados de la comunicación oral. Este tipo de comunicación resulta difícil de preservar cuando pasa el tiempo y está sujeta a muchas ambigüedades.
-Falta de calidad. Probar el código de forma constante no genera productos de calidad, sólo revela falta de análisis y diseño.
-Fuerte dependencia de las personas. Como se evita en lo posible la documentación y los diseños convencionales, los proyectos ágiles dependen críticamente de las personas.
-Falta de procesos de revisión del código. Con métodos como el PSP o TSP se han conseguido reducciones de errores que oscilan entre el 60 y el 80%. La programación en parejas tiene resultados del 20 al 40%, que no es mucho frente al 10 y el 25% de un programador.
-Falta de reusabilidad. La falta de documentación hacen difícil que pueda reutilizarse el código ágil.
-Sobre costos y retrasos derivados de la refactorización continua. Para un sistema de ciertas proporciones, los costos y retrasos derivados de la refactorización no pueden despreciarse.
-Restricciones en cuanto a tamaño de los proyectos abordables.
-Rigidez. Algunos métodos ágiles son muy rígidos: deben cumplirse muchas reglas de una forma estricta para garantizar el éxito del proyecto. Por ejemplo XP exige en realidad mucho esfuerzo, concentración y orden.
-Cambios. Los modelos de datos son “pesados” y no pueden cambiarse así como así solo porque el cliente que ira incorporar más funciones al sistema.
-Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.

Manifiesto de las Metodologías Ágiles

A principios de 2001 se reunieron los representantes de cada una de las metodologías ágiles, había mucho en común entre estas metodologías, utilizando el término “Ágil” como definición común a todas ellas. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. De esta forma, crearon lo que acordaron en llamar: el manifiesto para desarrollo de software ágil.
El Manifiesto comienza enumerando los principales valores del desarrollo ágil.
1. Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Si se sigue un buen proceso de desarrollo, pero el equipo falla, el éxito no está asegurado; sin embargo, si el equipo funciona, es más fácil conseguir el objetivo final, aunque no se tenga un proceso bien definido.
2. Desarrollar software que funciona más que conseguir una buena documentación. Aunque se parte de la base de que el software sin documentación es un desastre, la regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.
3. La colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.
4. Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta. Para poder adaptarse a los cambios que puedan surgir.
El resultado es un Manifiesto para el Desarrollo de Software Ágil, una declaración de los principios y valores comunes de los procesos ágiles.
El manifiesto fue sólo eso, una publicación que actuó como un punto de partida para aquellos que compartían estas ideas básicas. Algunos de los principios más importantes definidos en este manifiesto son:
-Interacción personal de individuos por sobre los procesos y las herramientas.
-Trabajar con el código por sobre documentación escrita.
-La colaboración con el cliente debe prevalecer sobre la negociación de contratos.
-Responder al cambio antes que seguir y mantener un plan.
-La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor.
-Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente.
-La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
-La simplicidad es esencial.

Puntos de Funcion

Puntos de Función

Los Puntos de Función miden la aplicación desde una perspectiva del usuario, dejando de lado los detalles de codificación.
Es una técnica totalmente independiente de todas las consideraciones de lenguaje y ha sido aplicada en más de 250 lenguajes diferentes. Se supone que FPA evalúa con fiabilidad :

- el valor comercial de un sistema para el usuario
- tamaño del proyecto, coste y tiempo de desarrollo
- calidad y productividad del programador MIS
- esfuerzo de adaptación, modificación y mantenimiento
- posibilidad de desarrollo propio
- beneficios de implementación en 4GL.

Relaciones entre Usuarios, Aplicaciones y Funciones

Un Punto de Función se define como una función comercial de usuario final. De esta manera un programa que tenga
“x” PF’s entrega “x” funciones al usuario final. El mejor modo de trabajo es la interacción analista-usuario.
El proceso requiere dos etapas fundamentales:

1. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos (mejor en este orden)

- Salidas
- Consultas
- Entradas
- Ficheros
- Interfaces.

I. Salidas .

Se debe contar cada dato único de usuario o salida de control generado proceduralmente y que sale del límite de la aplicación. Esto incluye informes y mensajes a otras aplicaciones y usuarios.

Una salida se considera única si
1. tiene formato diferente
2. tiene el mismo formato que otra salida pero requiere diferente lógica de procesamiento.
Además de las pantallas y los listados (papel o pantalla), también pueden ser salidas:
• fichero de transacción enviado a otra aplicación
• facturas
• cheques
• fichas perforadas
• transacciones automáticas
• mensajes al usuario
• cintas
• gráficos
• ficheros back-up, etc.
No se deben contar como salidas:
• cabeceras de columna, títulos, número de página
• mensajes individuales (información, confirmación o respuestas a consultas de error)
• salida en igual formato y lógica que ya se hay contado para otro soporte.

II. Entradas .

Se debe contar cada dato único de usuario o entrada de control que se introduce en los límites de la aplicación y actualiza un fichero lógico interno, conjunto de datos, tabla o dato independiente. Esto incluye ficheros de entrada y transacciones recibidas de otras aplicaciones.
Una entrada se considera única si
1. tiene un formato diferente
2. tiene el mismo formato que otra entrada pero requiere una lógica diferente de procesamiento, o se modifica un fichero interno lógico diferente.

Supongamos que tenemos dos pantallas de entrada, cada una con el mismo formato pero con diferente lógica de procesamiento. Se cuenta cada pantalla como una entrada diferente; pero si tuvieran la misma lógica sólo se contaría una. Lo mismo sucede con la repetición de pantallas.
Supongamos que tenemos un pantalla cuya función es actualizar un fichero o un conjunto de datos. Puesto que cada una de las tres funciones de actualización (añadir, cambiar, borrar) requiere diferente lógica de procesamiento tendremos tres entradas, no una. Cada fichero tendrá tres entradas, así como una salida (el fichero formateado de salida) y una consulta.

Tipos de entradas pueden ser:
• el ratón
• documentos MICR
• transacciones de cintas
• pantallas sensitivas
• lectores de código de barras, etc.
III. Consultas .

Se debe contar cada combinación única de entrada/salida en la que la entrada on-line definida por el usuario genera una salida inmediata on-line. Las consultas se pueden proporcionar a/desde otra aplicación; por ejemplo, responder a otra aplicación que pregunta por el precio de un producto se contaría como una consulta. Una consulta se considera única si
1. tiene un formato diferente de otras bien en su entrada o salida
2. tiene el mismo formato, tanto entrada como salida, que otra consulta pero requiere diferente lógica de procesamiento en cualquiera de los dos.
Una consulta directa en una base de datos o fichero maestro es aquella que
1. utiliza claves simples para recuperar datos específicos -esto es, un registro simple o grupo de registros, no un rango-
2. requiere respuesta inmediata, y
3. no realiza funciones de actualización (aunque se pueden efectuar cálculos).
Las consultas pueden aparecer en:
• consulta de usuario/display sin actualización de fichero u otra entidad lógica
• fichero de transacción que sale del límite de la aplicación si está accesible al usuario on-line
• pantalla de selección de menú (todas las pantallas de menú cuentan como una consulta)
• mensaje de información o pantalla de ayuda.

IV. Ficheros

Se debe contar cada grupo lógico mayor de datos de usuario o de información de control mantenidos dentro de los límites de la aplicación. FPA distingue entre dos tipos de ficheros: ficheros con transacciones temporales y ficheros con registros lógicos de datos permanentes. Sólo los almacenamientos de datos permanentes se ven como ficheros lógicos. Cuando se mantienen dentro de la aplicación se clasifican como "ficheros internos lógicos". Si se comparten entre aplicaciones se clasifican como interfaces y cómo ficheros internos lógicos.
Las transacciones, por el contrario, se considera que son sucesos que desencadenan cambios en los ficheros lógicos internos; no se clasifican como ficheros. Un fichero transacción se puede clasificar como entrada si es leído para actualizar datos en un fichero lógico interno. Un fichero transacción puede ser un interface o una salida si trasfiere transacciones de actualización a otra aplicación.
Cuando se utiliza análisis estructurado cada almacenamiento de datos contendrá al menos un fichero lógico interno. Hay que enfatizar que hablamos de ficheros lógicos. Supongamos que un fichero físico contiene dos claves diferentes, entonces contaríamos dos ficheros lógicos internos, puesto que cada camino presenta diferente información. Del mismo modo, cada vista lógica del usuario en una base de datos se cuenta como un fichero.
Se pueden encontrar ficheros en :
• bases de datos: 1 por vista lógica o camino de acceso
• ficheros maestros: 1 por cada grupo de claves
• tablas mantenidas por los usuarios: estados, tarifas, mensajes, etc.
• fichero de procesamiento batch
• índices de referencias cruzadas

V. Interfaces.

Se debe contar como uno cada fichero lógico de otro grupo de datos ( o información de control) que se envía fuera de los límites de la aplicación, o se comparte o es recibido desde otra aplicación. Los ficheros que se comparten entre aplicaciones se cuentan como ficheros y como interfaces en cada aplicación en la que se utilizan; de otro modo sólo se puntuará como fichero en aquella aplicación que utilice o mantenga el fichero (la otra sólo recibirá puntos de interface). Esto es, cada fichero interface debe ser también un fichero interno lógico en esa aplicación, en otra o en ambas; o puede ser un fichero transacción o de impresión generado en la propia aplicación. Los interfaces presentan una de estas situaciones:

1. Datos o información de control se pasa del fichero A al fichero B. En A se puntúa fichero e interface y en B sólo interface
2. Datos o información de control se pasa del fichero B a A. En B se puntúa fichero e interface y en A sólo interface
3. Datos o información de control se comparte entre A y B. A y B reciben puntos de fichero e interface.

¿Que es RUP?

· Un proceso de ingeniería de software:

-Forma disciplinada de asignar tareas y responsabilidades en una organización de desarrollo.
· Objetivos:

-Asegurar la producción de software de calidad
-Dentro de plazos y presupuestos predecibles.
· Es también un producto:

-Desarrollado y mantenido por Rational,
-Actualizado constantemente para tener en cuenta las mejores práctica de acuerdo con la experiencia.

Gráfico: RUP

RUP es un proceso de desarrollo de software:
- Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo).

Objetivos:
- Asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones).

Es también un producto:
- Desarrollado y mantenido por Rational.
- Actualizado constantemente para tener en cuenta las mejores prácticas de acuerdo con la experiencia.

Aumenta la productividad de los desarrolladores mediante acceso a:
- Base de conocimiento
- Plantillas
- Herramientas

Se centra en la producción y mantenimiento de modelos del sistema más que en producir documentos.

RUP es una guía de cómo usar UML de la forma más efectiva.

¿Que es UML?

Definición de UML
(Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un popular lenguaje de modelado de sistemas de software. Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software. Entre otras palabras, UML se utiliza para definir un sistema de
software.UML es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos.

Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo modelar los procesos de negocios, funciones, esquemas de bases de datos, expresiones de lenguajes de programación, etc.

Herramientas UML

Pero volviendo a la definición de UML como "conjunto de herramientas", si nos imaginamos UML como una caja de herramientas con su martillo, destornillador, alicates, etc. Veamos qué contiene nuestra caja de herramientas:

Diagrama de casos de uso
Diagrama de clases
Diagrama de estados
Diagrama de secuencias
Diagrama de actividades
Diagrama de colaboraciones
Diagrama de componentes
Diagrama de distribución

Pero siguiendo con la analogía, si vamos a colgar un cuadro no usaremos todas las herramientas de nuestra caja, posiblemente sólo usemos el martillo para clavar el clavo.
Lo mismo pasa con UML, una vez que conozcamos las herramientas usaremos en cada momento las más adecuadas a nuestras necesidades. Nos os voy a decir que esto sea fácil, pues hay que saber para qué sirven y qué limitaciones tienen unas y otras para conocer su utilidad. Pero se puede alcanzar este conocimiento con un poco de práctica y sentido común.

¿Qué no es UML?

UML no es un método de desarrollo. No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.
UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.

¿Cómo nació UML?

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y diseño de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento.
Booch había escrito "Object-Oriented Analysis and Design with Applications " un libro de referencia en el análisis y diseño orientado a objetos desarrollando su propia notación.
Por su parte James Rumbaugh había desarrollado su propia notación de diseño orientado a objetos llamada OMT (Object Modeling Technique) en su libro "Object-Oriented Modeling and Design ".
Por otro lado Jacobson se había revelado como un visionario del análisis (padre de los casos de uso) y sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case Driven Approach ".
A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos.
En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se unía a ellos en Rational.
En 1997 salió a la luz la versión 1.0 de UML.