Modelo SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental 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.

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 (interesados externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (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.2 Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint.

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.

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

Roles Principales

Product Owner

El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

ScrumMaster (o Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.

Equipo de desarrollo

El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).

Roles Auxiliares

Los roles auxiliares en los "equipos Scrum" son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

Stakeholders (Clientes, Proveedores, Vendedores, etc)

   Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint.

Administradores (Managers)

Es la gente que establece el ambiente para el desarrollo del producto.

Para más información sigue estos enlaces: http://es.wikipedia.org/wiki/Scrum

http://www.slideshare.net/ivanduga/la-esencia-de-scrum

Proceso Unificado de Rational RUP

RUP es un Proceso de Ingeniería de Software que describe quien hace que, cuando y como en un proyecto de desarrollo y despliegue de software. Esto tiene las características de manejar casos de uso, arquitectura céntrica, conducir riesgos y ser iterativo.

 

La mitigación de los riesgos más importantes de los elementos conduce a la definición del alcance de las iteraciones tempranas de su ciclo de vida. Y finalmente, RUP divide el ciclo de vida de desarrollo de software en iteraciones incrementales que producen versiones de la aplicación ejecutable.

RUP implementa las siguientes Buenas Practicas en la Ingeniería de Software:

1. Desarrollo Iterativo

2. Manejo de requerimientos.

3. Usar componentes de arquitectura

4. Modelo Visual

5. Verificación Continua de la Calidad

5. Manejo del Cambio

Las disciplinas de RUP están claramente relacionadas a las 6 mejores Prácticas, pero mas de cerca representa roles de los miembros o subgrupos  dentro del equipo de desarrollo completo. Estas disciplinas son:

1.    Modelado del negocio

2.    Requerimientos.

3.    Análisis y Diseño

4.    Implementación

5.    Prueba

6.    Despliegue

7.    Manejo de Proyecto

8.    Ambiente

9.    Configuración y Manejo del Cambio

Dentro de RUP, cada disciplina es expresado en termino de roles (quien realiza la tarea), actividades (Como ellos realizan estas tareas), y artefactos (que alcanza la actividad). Un rol define el comportamiento y responsabilidad de un individuo, responsable de actividades y artefactos. Una actividad es una tarea de lo cual un rol es responsable y quizás pueda ser consultado para realizarlo. Esto describe los pasos requeridos para crear o actualizar uno o más artefactos. Un artefacto es una entrada  y/o una salida de una actividad. Otros elementos suplen a estos tres elementos principales, tales como Concepto, pautas de Trabajo, informes, pautas de artefactos, plantillas y puntos de comprobación.

Según lo observado anteriormente, el Ciclo de Vida en RUP es iterativo, y la dimensión de este ciclo d vida se divide en 4 fases:

1.    Inicio

2.    Elaboración

3.    Construcción

4.    Transición

Cada fase tiene un conjunto claramente definido de objetivos y fines con un hito principal. Los hitos al final de cada fase son:

1.    Objetivo del Ciclo de Vida al final del Inicio.

2.    Arquitectura del Ciclo de Vida al final de la Elaboración.

3.    Capacidad Operacional al final de la Construcción.

4.    Lanzamiento del producto al final de la Transición.

La meta del inicio es definir el alcance del proyecto. La meta de la elaboración es construir una arquitectura ejecutable para la aplicación. La meta de la construcción esta en el cuerpo fuera del esqueleto arquitectónico con la mayoría de las capacidades de la Aplicación. Y finalmente, la meta de la transición es la transición de la Aplicación a la comunidad de usuarios finales.

Diagrama de Secuencia

El Diagrama de Secuencia de UML muestra la forma en el que los objetos se comuncan entre si al transcurrir el tiempo. El diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos.
Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interacción de objetos, se utilizan con frecuencia para validar los casos de uso.

Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

 Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas:

• De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
• Genérico: describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.

 

Diagrama de Clases

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de software orientados a objetos.

Definiciones

Propiedades también llamados atributos o características, son valores que corresponden a un objeto, como color, material, cantidad, ubicación. Generalmente se conoce como la información detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades serían: la marca, tamaño, color y peso.

Operaciones comúnmente llamados métodos, son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operación se escribe con minúsculas si consta de una sola palabra. Si el nombre contiene más de una palabra, cada palabra será unida a la anterior y comenzará con una letra mayúscula, a excepción de la primera palabra que comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mínimos del objeto. Hace referencia a polimorfismo.

Herencia se define como la reutilización de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos básicos como una persona, pero además cada uno tendrá información adicional que depende del tipo de persona, como saldo del cliente, total de inversión del accionista, salario del empleado, etc.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto real, como una persona, un transporte, un documento o un paquete. Estos ejemplos de clases de objetos reales, es sobre lo que un sistema se diseña. Durante el proceso del diseño de las clases se toman las propiedades que identifican como único al objeto y otras propiedades adicionales como datos que corresponden al objeto. 

En esta Página encontraras un programa para realizar tus Diagrama de Clases: http://www.argouml.tigris.org/