Metodologa Scrum

Qu

es?

Scrum es una metodologa gil y flexible para gestionar el desarrollo de software,

cuyo principal objetivo es maximizar el retorno de la inversin para su empresa
(ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y
en los principios de inspeccin continua, adaptacin, auto-gestin e innovacin.

Cundo

se

utiliza?

Con la metodologa Scrum el cliente se entusiasma y se compromete con el

proyecto dado que lo ve crecer iteracin a iteracin. Asimismo le permite en
cualquier momento realinear el software con los objetivos de negocio de su
empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de
cada

nueva

iteracin

sin

ningn

problema.

Esta metdica de trabajo promueve la innovacin, motivacin y compromiso del

equipo que forma parte del proyecto, por lo que los profesionales encuentran un
mbito propicio para desarrollar sus capacidades.
Beneficios

Cumplimento de expectativas: El cliente establece sus expectativas

indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los
estima y con esta informacin el Product Ownerestablece su prioridad. De manera
regular, en las demos de Sprint el Product Owner comprueba que efectivamente
los requisitos se han cumplido y transmite se feedback al equipo.

Flexibilidad a cambios: Alta capacidad de reaccin ante los cambios de

requerimientos generados por necesidades del cliente o evoluciones del mercado.

La metodologa est diseada para adaptarse a los cambios de requerimientos que
conllevan los proyectos complejos.

Reduccin del Time to Market: El cliente puede empezar a utilizar las

funcionalidades ms importantes del proyecto antes de que est finalizado por

completo.

Mayor calidad del software: La metdica de trabajo y la necesidad de

obtener una versin funcional despus de cada iteracin, ayuda a la obtencin de

un software de calidad superior.

Mayor productividad: Se consigue entre otras razones, gracias a la

eliminacin de la burocracia y a la motivacin del equipo que proporciona el hecho

de que sean autnomos para organizarse.

Maximiza el retorno de la inversin (ROI): Produccin de software

nicamente con las prestaciones que aportan mayor valor de negocio gracias a la
priorizacin por retorno de inversin.

Predicciones de tiempos: Mediante esta metodologa se conoce la

velocidad media del equipo por sprint (los llamados puntos historia), con lo que
consecuentemente, es posible estimar fcilmente para cuando se dispondr de una
determinada funcionalidad que todava est en el Backlog.

Reduccin de riesgos: El hecho de llevar a cabo las funcionalidades de

ms valor en primer lugar y de conocer la velocidad con que el equipo avanza en el

proyecto, permite despejar riesgos eficazmente de manera anticipada.

Programacin extrema: Metodologa para

desarrollo gil de aplicaciones
La programacin extrema, o Extreme Programming (XP), es una metodologa
de desarrollo gil, una de las ms exitosas en tiempo reciente. Su autor
principal es Kent Beck, quien eligi algunas caractersticas de otras
metodologas y las relacion de forma que cada una complementara a la otra.
As, la XP se puede definir como un conjunto de pasos de diversas
metodologas, acopladas de manera que sean pasos flexibles a seguir
utilizadas con el uso comn, para realizar un desarrollo ms agradable y
sencillo.
Esta metodologa tiene como base la simplicidad y como objetivo principal la
satisfaccin del cliente; para lograrlo se deben tomar en cuenta cuatro valores
fundamentales:
Comunicacin
Es muy importante que haya una comunicacin constante con el cliente y
dentro de todo el equipo de trabajo, de esto depender que el desarrollo se
lleve a cabo de una manera sencilla, entendible y que se entregue al cliente lo
que necesita.
Simplicidad
En la XP se refiere que ante todo y sin importar qu funcionalidad requiera el
usuario en su sistema, ste debe ser fcil. El diseo debe ser sencillo y
amigable al usuario, el cdigo debe ser simple y entendible, programando slo
lo necesario y lo que se utilizar.
Retroalimentacin
Es la comunicacin constante entre el desarrollador y el usuario.
Coraje
Se refiere a la valenta que se debe tener al modificar o eliminar el cdigo que
se realiz con tanto esfuerzo; el desarrollador debe saber cuando el cdigo que
desarroll no es til en el sistema y, por lo mismo, debe ser eliminado. Tambin
se refiere a tener la persistencia para resolver los errores en la programacin.
Dentro de la programacin extrema se tiene 12 principios que llevan o guan el
desarrollo con esta metodologa:
1. El principio de pruebas
2. Proceso de planificacin
3. El cliente en el lugar
4. Programacin en parejas
5. Integracin continua
6. Refactorizacin
7. Entregas pequeas
8. Diseo simple
9. Metfora
10. Propiedad colectiva del cdigo

11. Estndar de codificacin

12. La semana de 40 horas
Herramientas de la XP
Historias de usuarios
Son tarjetas fsicas en las cuales se anota una descripcin de una
funcionalidad del sistema, en una oracin, se le da un nmero y un ttulo para
ser identificada.
Casos de prueba de aceptacin
Son tarjetas que se elaboran para realizar las pruebas de cada historia de
usuario.
Tarea de ingeniera
Son tarjetas que se elaboran para ayudar y simplificar la programacin de una
historia de usuario.
Tarjetas CRC
Describen las clases utilizadas en la programacin de una historia.
Ventajas y desventajas
Una de las ventajas de la programacin extrema es que se adapta al desarrollo
de sistemas pequeos y grandes; optimiza el tiempo de desarrollo; permite
realizar el desarrollo del sistema en parejas para complementar los
conocimientos; el cdigo es sencillo y entendible, adems de la poca
documentacin a elaborar para el desarrollo del sistema.
Las desventajas son que no se tiene la definicin del costo y el tiempo de
desarrollo; el sistema va creciendo despus de cada entrega al cliente y nadie
puede decir que el cliente no querr una funcin ms; se necesita de la
presencia constante del usuario, lo cual en la realidad es muy difcil de lograr.
Otra desventaja es la programacin en parejas, algunos desarrolladores son
celosos del cdigo que escriben y no les es grato que alguien ms modifique
las funciones que realiz o que su cdigo sea desechado por no cubrir el
estndar.
Fuentes:
Beck, K. A. (2004). Extreme Programming Explained. Addison Wesley.
Martin, R., & Newkirk, J. (2002). La programacion extrema en la practica.
Pearson Addison-Wesley.
http://www.uv.mx/universo/486/infgral/infgral_15.html
Que es Metodologia Rup?
El Proceso Racional Unificado es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis,
implementacin y documentacin de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin. Originalmente se
dise un proceso genrico y de dominio pblico, el Proceso Unificado, y una especificacin
ms detallada, el Rational Unified Process, que se vendiera como producto independiente.

Proceso de Desarrollo del Software

El RUP est basado en 6 procesos que son los siguientes:
Adaptar el proceso:
El proceso deber adaptarse a las necesidades del cliente ya que es muy importante
interactuar con l. Las caractersticas propias del proyecto u organizacin. El tamao del
mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo
especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal.
Equilibrar prioridades:
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse
recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a
este equilibrio se podrn corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente:
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se refina
la direccin del proyecto as como tambin los riesgos involucrados.
Colaboracin entre equipos:
El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una
comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstraccin:
Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del
software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita
que los ingenieros de software vayan directamente de los requisitos a la codificacin de
software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor
manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del
cdigo.
Enfocarse en la calidad:
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de
la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un
grupo independiente.
Fundamentos del Enfoque orientado a Objetos

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo
desarrollo orientado a objetos. Estos principios son: la Abstraccin, el Encapsulamiento, la
Modularidad
y
la
Herencia.

Fundamento 1: Abstraccin:
Es el principio de ignorar aquellos aspectos de un fenmeno observado que no son relevantes,
con el objetivo de concentrarse en aquellos que si lo son. Una abstraccin denota las
caractersticas esenciales de un objeto (datos y operaciones), que lo distingue de otras clases
de objetos. Decidir el conjunto correcto de abstracciones de un determinado dominio, es el
problema central del diseo orientado a objetos.
Los mecanismos de abstraccin son usados en el EOO para extraer y definir del medio a
modelar, sus caractersticas y su comportamiento. Dentro del EOO son muy usados
mecanismos de abstraccin: la Generalizacin, la Agregacin y la clasificacin.
La generalizacin es el mecanismo de abstraccin mediante el cual un conjunto de clases de
objetos son agrupados en una clase de nivel superior (Superclase), donde las semejanzas de
las clases constituyentes (Subclases) son enfatizadas, y las diferencias entre ellas son
ignoradas. En consecuencia, a travs de la generalizacin, la superclase almacena datos
generales de las subclases, y las subclases almacenan slo datos particulares.La
especializacin es lo contrario de la generalizacin. Por ejemplo; La clase Mdico es una
especializacin de la clase Persona, y a su vez, la clase Pediatra es una especializacin de la
superclase
Mdico.
La agregacin es el mecanismo de abstraccin por el cual una clase de objeto es definida a
partir de sus partes (otras clases de objetos). Mediante agregacin se puede definir por ejemplo
un computador, por descomponerse en: la CPU, la ULA, la memoria y los dispositivos
perifricos.
El
contrario
de
agregacin
es
la
descomposicin.
La clasificacin consiste en la definicin de una clase a partir de un conjunto de objetos que
tienen un comportamiento similar. La ejemplificacin es lo contrario a la clasificacin, y
corresponde a la instanciacin de una clase, usando el ejemplo de un objeto en particular.
Fundamento 2: Encapsulamiento:
Es la propiedad del EOO que permite ocultar al mundo exterior la representacin interna del
objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo
no son conocidos fuera de l. La idea central del encapsulamiento es esconder los detalles y
mostrar lo relevante. Permite el ocultamiento de la informacin separando el aspecto
correspondiente a la especificacin de la implementacin; de esta forma, distingue el "qu
hacer" del "cmo hacer". La especificacin es visible al usuario, mientras que la
implementacin se le oculta.
Fundamento

3:

Modularidad:

Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La
modularidad consiste en dividir un programa en mdulos o partes, que pueden ser compilados
separadamente, pero que tienen conexiones con otros mdulos. En un mismo mdulo se suele
colocar clases y objetos que guarden una estrecha relacin. El sentido de modularidad est
muy
relacionado
con
el
ocultamiento
de
informacin.
Fundamento 4: Herencia:
Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra
clase que lo preceda en una jerarqua de clasificaciones. Permite la definicin de un nuevo
objeto a partir de otros, agregando las diferencias entre ellos (Programacin Diferencial),
evitando
repeticin
de
cdigo
y
permitiendo
la
reusabilidad.
Las clases heredan los datos y mtodos de la superclase. Un mtodo heredado puede ser

sustituido por uno propio si ambos tienen el mismo nombre. La herencia puede ser simple
(cada clase tiene slo una superclase) o mltiple (cada clase puede tener asociada varias
superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase
Persona (superclase, herencia simple). La clase Preparador (subclase) hereda propiedades de
la
clase
Docente
y
de
la
clase
Estudiante
(herencia
mltiple).
Fundamento 5: Polimorfismo:
Es una propiedad del EOO que permite que un mtodo tenga mltiples implementaciones, que
se seleccionan en base al tipo objeto indicado al solicitar la ejecucin del mtodo. El
polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual
nombre a diferentes clases o estn relacionados en trminos de inclusin. En este tipo de
polimorfismo, los mtodos son interpretados en el contexto del objeto particular, ya que los
mtodos con nombres comunes son implementados de diferente manera dependiendo de cada
clase.
Desarrollo de Componentes
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las
distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas
segn la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la
comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la
eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la
arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de
modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la
arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por medio de una
serie de iteraciones.
Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y se
procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se
realizan iteraciones hasta que se termine la implementacin de la nueva versin del producto.
En la fase de transicin, se pretende garantizar que se tiene un producto preparado para su
entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la
fase el esfuerzo dedicado a una disciplina vara.
Caracteristicas de Campo

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y

cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar
centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo
fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una
persona puede desempear distintos roles a lo largo del proceso).
Documentacin
Primer nivel de documentacin:
Especifica en trminos generales qu actividades debern integrar el Sistema de
Aseguramiento de Calidad, que ser implantado en la organizacin. Este nivel contiene los
siguientes elementos:
Declaracin de Visin: Proyecciones de la administracin sobre el lugar que ocupar la
organizacin en el futuro.
Declaracin de Misin: Compromiso de la administracin para alcanzar la Visin.
Poltica de Calidad: Posicin de la organizacin, en cuanto a la manera en que la calidad
afectar la manera de cumplir con la Misin.
Requerimientos de Calidad: Conjunto de actividades que la organizacin debe llevar a cabo,
para asegurar la calidad tanto del proceso como el producto que desarrolla
La Visin, Misin y Polticas de Calidad fueron desarrolladas a partir de los lineamientos
estratgicos del Departamento de Sistemas de Informacin.
El Requerimiento de Calidad se identifica en modelos de calidad como ISO 9000.
Segundo nivel de documentacin:
Este nivel incluye especificaciones detalladas, orientadas a la administracin, para explicar
cmo se llevarn a cabo las actividades que integran el Sistema de Aseguramiento de Calidad.
Este nivel est compuesto bsicamente por procedimientos Administrativos, que son
declaraciones de direcciones sistemticas, sobre cmo la organizacin debe llevar a cabo cada
uno de los Requerimientos de Calidad, definidos en el Primer Nivel de Documentacin.
Tercer nivel de documentacin:
Este nivel incluye especificaciones punto a punto, explcito y conciso para llevar a cabo
cualquier tarea en la organizacin. Est compuesto bsicamente por Procedimientos de
Operativos que describen cada paso que se debe realizar para concretar una tarea o actividad;
y Estndares que se utilizan con el fin de registrar datos o informacin de algo especfico. Estos
procedimientos y estndares han sido divididos en tres grupos:
1. Los relacionados con el desarrollo del curso Proyecto de Ttulo.
2. Los relacionados con el desarrollo de producto de software.
3. Los que guan la implantacin y mejoramiento del Sistema de Aseguramiento de Calidad.
Esta divisin facilita el uso y mantencin del sistema. Por ejemplo, si hay cambios en las
normas administrativas que afecten el desarrollo de los cursos en general, entonces slo se
vern afectados los procedimientos y estndares relacionados con el desarrollo del proyecto.
Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una serie de
artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre
otros). Estos artefactos (entre otros) son los siguientes:
Inicio:

Documento Visin

Especificacin de Requisitos

Elaboracin:
Diagramas de caso de uso

Construccin:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lgica
o

Diagrama de clases

Modelo E-R (Si el sistema as lo requiere)

Vista de Implementacin
o
Diagrama de Secuencia
o

Diagrama de estados

Diagrama de Colaboracin

Vista Conceptual
o
Modelo de dominio
Vista fsica
o

Mapa de comportamiento a nivel de hardware.

http://mtdologiarup.blogspot.mx/