PDF generado usando el kit de herramientas de fuente abierta mwlib. Ver http://code.pediapress.com/ para mayor informacin.

PDF generated at: Tue, 19 Aug 2014 06:53:29 UTC

DESARROLLO ITERATIVO
Y CRECIENTE
Investigacion
Contenidos
Artculos
Desarrollo iterativo y creciente 1
Framework 5
Proceso Unificado de Rational 9
Mtodo de desarrollo de sistemas dinmicos 14
Programacin extrema 16
Iteracin 20
Desarrollo en cascada 22
Scrum 25
Referencias
Fuentes y contribuyentes del artculo 31
Fuentes de imagen, Licencias y contribuyentes 32
Licencias de artculos
Licencia 33
Desarrollo iterativo y creciente
1
Desarrollo iterativo y creciente
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software creado en respuesta a las
debilidades del modelo tradicional de cascada.
Bsicamente este modelo de desarrollo, que no es ms que un conjunto de tareas agrupadas en pequeas etapas
repetitivas (iteraciones),
[1]
es uno de los ms utilizados en los ltimos tiempos ya que, como se relaciona con
novedosas estrategias de desarrollo de software y una programacin extrema, es empleado en metodologas diversas.
El modelo consta de diversas etapas de desarrollo en cada incremento, las cuales inician con el anlisis y finalizan
con la instauracin y aprobacin del sistema.
[2]
Concepto de desarrollo iterativo y creciente
Se planifica un proyecto en distintos bloques temporales que se le denominan iteracin. En una iteracin se repite un
determinado proceso de trabajo que brinda un resultado ms completo para un producto final, de forma de que quien
lo utilice reciba beneficios de este proyecto de manera creciente.
Para llegar a lograr esto, cada requerimiento debe tener un completo desarrollo en una nica iteracin que debe de
incluir pruebas y una documentacin para que el equipo pueda cumplir con todos los objetivos que sean necesarios y
est listo para ser dado al cliente. As se evita tener riesgosas actividades en el proyecto finalizado.
Lo que se busca es que en cada iteracin los componentes logren evolucionar el producto dependiendo de los
completados de las iteraciones antecesoras, agregando ms opciones de requisitos y logrando as un mejoramiento
mucho ms completo.
Una manera muy primordial para dirigir al proceso iterativo incremental es la de priorizar los objetivos y
requerimientos en funcin del valor que ofrece el cliente.
[3]
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de
los cuales los dos ms famosos son el Rational Unified Process y el Dynamic Systems Development Method. El
desarrollo incremental e iterativo es tambin una parte esencial de un tipo de programacin conocido como Extreme
Programming y los dems frameworks de desarrollo rpido de software.
Ciclo de vida
La idea principal detrs de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental,
permitindole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior,
incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y
su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una implementacin simple de los
requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema
completo est implementado. En cada iteracin, se realizan cambios en el diseo y se agregan nuevas
funcionalidades y capacidades al sistema.
Bsicamente este modelo se basa en dos premisas:
Los usuarios nunca saben bien que es lo que necesitan para satisfacer sus necesidades.
En el desarrollo, los procesos tienden a cambiar.
[4]
El proceso en s mismo consiste de:
Etapa de inicializacin
Etapa de iteracin
Lista de control de proyecto
Desarrollo iterativo y creciente
2
Consideraciones sobre el momento de aplicacion
Para integrar la usabilidad en un proceso de desarrollo, no es suficiente con asignar tcnicas de usabilidad a
actividades de desarrollo, puesto que no todas las tcnicas de usabilidad son aplicables en cualquier momento de un
desarrollo iterativo. Por ejemplo, las tcnicas para desarrollar el concepto del producto estn concebidas para su
aplicacin en en los primeros esfuerzos del desarrollo, cuando las necesidades se identifican y el esquema general del
sistema se establece. Aunque es aconsejable aplicarles tambin ms tarde, para refinar el concepto, su principal
esfuerzo de aplicacin esta en las tareas iniciales de desarrollo.
[5]
Etapa de inicializacin
Se crea una versin del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y
por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una
solucin lo suficientemente simple para ser comprendida e implementada fcilmente. Para guiar el proceso de
iteracin se crea una lista de control de proyecto, que contiene un historial de todas las tareas que necesitan ser
realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y areas de rediseo de la solucin
ya existente. Esta lista de control se revisa peridica y constantemente como resultado de la fase de anlisis.
Etapa de iteracin
Esta etapa involucra el rediseo e implementacin de una tarea de la lista de control de proyecto, y el anlisis de la
versin ms reciente del sistema. La meta del diseo e implementacin de cualquier iteracin es ser simple, directa y
modular, para poder soportar el rediseo de la etapa o como una tarea aadida a la lista de control de proyecto. El
cdigo puede, en ciertos casos, representar la mayor fuente de documentacin del sistema. El anlisis de una
iteracin se basa en la retroalimentacin del usuario y en el anlisis de las funcionalidades disponibles del programa.
Involucra el anlisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las
metas). La lista de control del proyecto se modifica bajo la luz de los resultados del anlisis.
Las guas primarias que guan la implementacin y el anlisis incluyen:
Cualquier dificultad en el diseo, codificacin y prueba de una modificacin debera apuntar a la necesidad de
redisear o recodificar.
Las modificaciones deben ajustarse fcilmente a los mdulos fciles de encontrar y a los aislados. Si no es as,
entonces se requiere algn grado de rediseo.
Las modificaciones a las tablas deben ser especialmente fciles de realizar. Si dicha modificacin no ocurre
rpidamente, se debe aplicar algo de rediseo.
Las modificaciones deben ser ms fciles de hacer conforme avanzan las iteraciones. Si no es as, hay un
problema primordial usualmente encontrado en un diseo dbil o en la proliferacin excesiva de parches al
sistema.
Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el
rediseo durante una fase de implementacin.
La implementacin existente debe ser analizada frecuentemente para determinar qu tal se ajusta a las metas del
proyecto.
Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el anlisis de
implementaciones parciales.
La opinin del usuario debe ser solicitada y analizada para indicar deficiencias en la implementacin referida por
l.
Desarrollo iterativo y creciente
3
Caso prctico
La mejora iterativa fue exitosamente aplicada al desarrollo de una familia extensa de compiladores para una familia
de lenguajes de programacin en una gama de arquitecturas de hardware. Un conjunto de 17 versiones del sistema se
desarrollaron en un lugar, generando 17 mil lneas de cdigo fuente de lenguaje de alto nivel (6500 de cdigo
ejecutable). El sistema posteriormente fue desarrollado en dos sitios diferentes, llegando a dos versiones diferentes
del lenguaje base: una versin esencialmente se enfocaba en aplicaciones matemticas, aadiendo nmeros reales y
varias funciones matemticas, y la otra se centr en aadir capacidades para escribir del compilador. Cada iteracin
fue analizada del punto de vista de los usuarios (las capacidades del lenguaje fueron determinadas en parte por las
necesidades del usuario) y el punto de vista del desarrollador (el diseo del compilador evolucion para ser ms
fcilmente modificable, por ejemplo, para aadir nuevos tipos de datos). Mediciones tales como acoplamiento y
modularizacin fueron seguidas sobre mltiples versiones.
Caractersticas
Usando anlisis y mediciones como guas para el proceso de mejora es una diferencia mayor entre las mejoras
iterativas y el desarrollo rpido de aplicaciones, principalmente por dos razones:
Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto.
Permite estudiar y despus mejorar y ajustar el proceso para el ambiente en particular.
Estas mediciones y actividades de anlisis pueden ser aadidas a los mtodos de desarrollo rpido existentes.
De hecho, el contexto de iteraciones mltiples conlleva ventajas en el uso de mediciones. Las medidas a veces son
difciles de comprender en lo absoluto, aunque en los cambios relativos en las medidas a travs de la evolucin del
sistema puede ser muy informativo porque proveen una base de comparacin. Por ejemplo, un vector de medidas
m1, m2,..., mn puede ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el
esfuerzo total realizado, los cambios, los defectos, los atributos lgico, fsico y dinmico, consideraciones del
entorno, etctera. As el observador puede decir como las caractersticas del producto como el tamao, la
complejidad, el acoplamiento y la cohesin incrementan o disminuyen en el tiempo. Tambin puede monitorearse el
cambio relativo de varios aspectos de un producto o pueden proveer los lmites de las medidas para apuntar a
problemas potenciales y anomalas.
Ventajas del desarrollo incremental
En este modelo los usuarios no tienen que esperar hasta que el sistema completo se entregue para hacer uso de l.
El primer incremento cumple los requerimientos ms importantes de tal forma que pueden utilizar el software al
instante.
Los usuarios pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los
requerimientos de los incrementos posteriores del sistema.
Existe muy pocas probabilidades de riesgo en el sistema. Aunque se pueden encontrar problemas en algunos
incrementos, lo normal es que el sistema se entregue sin inconvenientes al usuario.
Ya que los sistemas de ms alta prioridad se entregan primero, y los incrementos posteriores se integran entre
ellos, es muy poco probable que los sistemas ms importantes sean a los que se les hagan ms pruebas. Esto
quiere decir que es menos probable que los usuarios encuentren fallas de funcionamiento del software en las
partes ms importantes del sistema.
[6]
Desarrollo iterativo y creciente
4
Ventajas del desarrollo iterativo
En el desarrollo de este modelo se da la retroalimentacin muy temprano a los usuarios.
Permite separar la complejidad del proyecto, gracias a su desarrollo por parte de cada iteracin o bloque.
El producto es consistente y puntual en el desarrollo.
Los productos desarrollados con este modelo tienen una menor probabilidad de fallar.
Se obtiene un aprendizaje en cada iteracin que es aplicado en el desarrollo del producto y aumenta las
experiencias para prximos proyectos.
[7]
Debilidades de este modelo de desarrollo
La entrega temprana de los proyectos produce la creacin de sistemas demasiados simples que a veces se ven un
poco montonos a los ojos del personal que lo recibe.
[6]
La mayora de los incrementos se harn en base de las necesidades de los usuarios. Los incrementos en si ya son
estipulados desde antes de la entrega del proyecto, sin embargo hay que ver cmo se maneja el producto para ver
si necesita otros cambios adems de los estipulados antes de la entrega del proyecto. Este problema no se ve
frecuentemente ya que la mayora de las veces los incrementos estipulados suplen satisfactoriamente al usuario.
Los incrementos no deben constar de muchas lneas de cdigo ya que la idea de los incrementos es agregar
accesorios al programa principal (o funcional), para que este tenga una y mil formas de desenvolverse en su tarea;
llenar los incrementos de muchas lneas de cdigo provocara que se perdiera la objetividad o base de lo que se
trata el desarrollo incremental.
Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que simplemente no estarn
dispuestos a invertir el tiempo necesario.
El trato con el cliente debe basarse en principios ticos y colaboracin mutua, ms que trabajar cada parte
independientemente, defendiendo slo su propio beneficio.
[8]
La entrega de un programa que es parcial pero funcional puede hacer vulnerable al programa debido a la falta de
robustez en su sistema, provocando que agentes ajenos puedan interferir con el correcto funcionamiento del
programa en s.
Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente, requiriendo de
profesionales sobre el promedio.
Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos estn previamente definidos, o para
proyectos "todo/nada" en los cuales se requiere que se completen en un 100% el producto para ser implementado
(por ejemplo, licitaciones) otro punto muy importante es asegurarnos de que el trabajo se pueda cumplir tomando
en cuenta los costos que podamos usar en nuestros propios recursos.
Referencias
[1] |Proceso de Desarrollo Iterativo| http:/ / fernandosoriano. com. ar/ ?p=13
[2] |Desarrollo de software. Ciclo de vida iterativo incremental| https:/ / jummp. wordpress. com/ 2011/ 03/ 31/
desarrollo-de-software-ciclo-de-vida-iterativo-incremental/
[3] |Desarrollo iterativo e incremental| http:/ / www. proyectosagiles. org/ desarrollo-iterativo-incremental
[4] |Modelo Iterativo| http:/ / procesosoftware. wikispaces.com/ Modelo+ Iterativo
[5] [5] Constantine, L. L., Lockwood, L. A. D.: Software for Use: A Practical Guide to the Models and Methods of Usage - Centred Design. Addison
- Wesley ( 1999)
[6] [6] Ian Sommerville (2005). Entrega Incremental. Ingeniera del Software, Sptima edicin edicin... Espaa: Pearson.
[7] |Proceso de Desarrollo Iterativo| http:/ / fernandosoriano. com. ar/ ?p=13
[8] |Desarrollo iterativo e incremental| http:/ / www. proyectosagiles. org/ desarrollo-iterativo-incremental
Framework
5
Framework
La palabra inglesa "framework" (marco de trabajo) define, en trminos generales, un conjunto estandarizado de
conceptos, prcticas y criterios para enfocar un tipo de problemtica particular que sirve como referencia, para
enfrentar y resolver nuevos problemas de ndole similar.
En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnolgica de
soporte definido, normalmente con artefactos o mdulos de software concretos, que puede servir de base para la
organizacin y desarrollo de software. Tpicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje
interpretado, entre otras herramientas, para as ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio, y provee
una estructura y una especial metodologa de trabajo, la cual extiende o utiliza las aplicaciones del dominio.
Introduccin
Los frameworks tienen como objetivo ofrecer una funcionalidad definida, auto contenida, siendo construidos usando
patrones de diseo, y su caracterstica principal es su alta cohesin y bajo acoplamiento. Para acceder a esa
funcionalidad, se construyen piezas, objetos, llamados objetos calientes, que vinculan las necesidades del sistema
con la funcionalidad que este presta. Esta funcionalidad, esta constituida por objetos llamados fros, que sufren poco
o ningn cambio en la vida del framework, permitiendo la portabilidad entre distintos sistemas. Frameworks
conocidos que se pueden mencionar por ejemplo son Spring Framework, Hibernate, donde lo esencial para ser
denominados frameworks es estar constituidos por objetos casi estticos con funcionalidad definida a nivel grupo de
objetos y no como parte constitutiva de estos, por ejemplo en sus mtodos, en cuyo caso se habla de un API o
librera. Algunas caractersticas notables que se pueden observar:
Lainversin de control: En un frame, a diferencia de las bibliotecas, el flujo de control no es dictado por el
programa que llama, sino por el mismo.
La funcionalidad o comportamiento predeterminado: Un marco tiene un comportamiento predeterminado. Este
comportamiento por defecto debe ser un comportamiento til, definido e identificable.
Su extensibilidad : Un marco puede ser ampliado para proporcionar una funcionalidad especfica. El frame, en
general, no se supone que deba ser modificado, excepto en cuanto a extensibilidad. Los usuarios pueden ampliar
sus caractersticas, pero no deben ni necesitan modificar su cdigo.
Bsicos
No es ms que una base de programacin que atiende a sus descendientes (manejado de una forma estructural y/o en
cascada), posibilitando cualquier respuesta ante las necesidades de sus miembros, o en secciones de una aplicacin
(web), satisfaciendo as las necesidades ms comunes del programador.
Arquitectura
Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador => Modelo => Vista), ya que debemos
fragmentar nuestra programacin. Tenemos que contemplar estos aspectos bsicos en cuanto a la implementacin de
nuestro sistema:
Modelo
Este miembro del controlador maneja las operaciones lgicas, y de manejo de informacin (previamente
enviada por su ancestro), para resultar de una forma explicable y sin titubeos. Cada miembro debe ser
meticulosamente llamado, con su correcto nombre y en principio, con su verdadera naturaleza: el manejo de
informacin, su complementacin directa.
Framework
6
Vista
Al final, a este miembro de la familia le corresponde dibujar, o expresar la ltima forma de los datos: la
interfaz grfica que interacta con el usuario final del programa (GUI). Despus de todo, a este miembro le
toca evidenciar la informacin obtenida hasta hacerla llegar al controlador. Solo (e inicialmente), nos espera
demostrar la informacin.
Controlador
Con este apartado podemos controlar el acceso (incluso todo) a nuestra aplicacin, y esto puede incluir:
archivos, scripts, y/o programas; cualquier tipo de informacin que permita la interfaz. As, podremos
diversificar nuestro contenido de forma dinmica, y esttica (a la vez); pues, slo debemos controlar ciertos
aspectos (como se ha mencionado antes).
Estructura
Dentro del controlador, modelo o vista podemos manejar lo siguiente: datos. Depende de nosotros como interpretar y
manejar estos 'datos'. Ahora, sabemos que el nico dato de una direccin esttica web es: conseguir un archivo fsico
en el disco duro o de Internet, etc. e interpretado o no, el servidor responde.si o no y luego se va
El modelo, al igual que el controlador y la vista, maneja todos los datos que se relacionen consigo (solo es el proceso
medio de la separacin por capas que ofrece la arquitectura MVC). Y slo la vista, puede demostrar dicha
informacin. Con lo cual ya hemos generado la jerarqua de nuestro programa: Controlador, Modelo y Vista.
Lgica
Al parecer, debemos inyectar ciertos objetos dentro de sus parientes en esta aplicacin, solo as compartirn herencia
y coherencia en su aplicacin.
Rpidamente, para una aplicacin web sencilla debemos establecer estos objetos:
Una base (MVC)
Controlador: ste debe ser capaz de manejar rutas, archivos, clases, mtodos y funciones.
Modelo: es como un script habitual en el servidor, solo que agrupado bajo un 'modelo' reutilizable.
Vista: como incluyendo cualquier archivo en nuestra ejecucin, muy simple.
Un sistema
Ruteador: con l podemos dividir nuestras peticiones sin tantas condicionales.
Cargador
Ejemplos
// Index.php
// -----
// ------ Clases ------
class Base {}
class Controller extends Base {
function load($name) {
require_

$this->$name =& new $name();
}
}
Framework
7
class Model extends Controller {
function view($name, $data) {
extract($data);

include "app/view/" . $name . ".php";
}
}
// ------ Router & Loader ------
function _route($controller, $model) {
if (is_file("app/$controller.php")) {
require_once "app/" . $controller . ".php";
$object = new $controller();

$object->$model();
}
}
// ----- Rutina -----
_route($_GET['section'], $_GET['name']);
Esto cumple con algunas necesidades de simpleza informtica. Ahora solo nos basta controlar estos procesos,
ampliarlos y complementarles con algunos scripts mas.
Aplicar
Si nuestro archivo se llama Foo (clase), y nuestro otro archivo, bar (mtodo) tenemos que crear el siguiente archivo
dentro de la carpeta app/.
// app/Foo.php
// -----
class Foo extends Controller {
function foo() {
$this->load('test');
}

function bar() {
echo '<b>Testing</b>';
echo $this->test->does();
}
}
Como resultado al solicitar (por ejemplo, ?section=foo&name=bar), deberamos ver el siguiente texto:
Testing
Framework
8
Extender
Podremos extender nuestro sistema con clases, o funciones propias o de algn 'plugin' o librera ajena. Solo que
queremos extenderles sobre nuestro sistema actual, nuestro objeto bsico.
// app/model/Test.php
// -----
class Test extends Model {
function does() {
echo '<ins>Hecho esta!</ins>';
echo $this->view('look', array('my_var' =>
'my_value'));
}
}
Entonces, debemos usar la siguiente sentencia dentro de nuestro programa Foo:
$this->load($this, 'test') o _load($this, 'test')
Ya con esto, podremos utilizar las llamadas a $this->test->does() dentro del objeto o clase Foo.
Ver
Para mostrar los resultados de todo nuestro computo necesitamos de vistas, o archivos de inclusin: plantillas,
bloques o scripts. Suponiendo que ya ha sido todo, debemos de visualizarlo:
// app/view/Look.php
// -----
echo 'Variable: ' . $my_var;
Para poder ejecutar esto, se debe llamar a esta sentencia: $this->view('look', array ('my_var' =>
'my_value')) obteniendo como resultado:
Variable: my_value
Referencias
Proceso Unificado de Rational
9
Proceso Unificado de Rational
El Proceso Unificado Racional (Rational Unified Process en ingls, habitualmente resumido como RUP) es un
proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM.
Junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el
anlisis, diseo, 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.
Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que incluye informacin
entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method
Composer (RMC), que permite la personalizacin de acuerdo con las necesidades.
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...
Principios de desarrollo
El RUP est basado en 6 principios clave 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. 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 subnormal.
prueba
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. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y
soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por
Proceso Unificado de Rational
10
ejemplo con el lenguaje UML.
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.
Ciclo de vida
Esfuerzo en actividades segn fase del proyecto.
El ciclo de vida RUP es una implementacin
del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias
semi-ordenadas. El ciclo de vida organiza
las tareas en fases e iteraciones.
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
[1]
(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.
Proceso Unificado de Rational
11
Principales caractersticas
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).
Fases
Establece oportunidad y alcance
Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:
'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: En esta parte nos encontramos con las siguientes etapas:
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno
La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y
en esta parte se ven inmersas las 4 fases descritas anteriormente:
Inicio (tambin llamado Incepcin o Concepcin).
Elaboracin.
Desarrollo (tambin llamado Implementacin, Construccin).
Cierre (tambin llamado Transicin).
Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores,
identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y
producir el plan de las fases y el de iteraciones posteriores.
Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura
base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el
primer anlisis del dominio del problema, se disea la solucin preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar
los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se
Proceso Unificado de Rational
12
realizan las mejoras para el proyecto.
Fase de Transicin: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte
tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas
involucradas en el 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
Diagramas de caso de uso
Especificacin de Requisitos
Diagrama de Requisitos
Elaboracin:
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lgica
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)
Vista de Implementacin
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin
Vista Conceptual
Modelo de dominio
Vista fsica
Mapa de comportamiento a nivel de hardware.
Diseo y desarrollo de casos de uso, o flujos de casos de uso arquitectnicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde
adecuadamente a requerimientos funcionales y no funcionales.
Construccin:
Especificacin de requisitos faltantes
Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresin segn sea el caso
Transicin:
Pruebas finales de aceptacin
Puesta en produccin
Estabilizacin
Proceso Unificado de Rational
13
Un poco de historia
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los
contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software compr una
compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a
los mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de
Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el
Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en
jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado "The Unified Software Development Process (ISBN
0-201-57169-2)" El Proceso Unificado de Desarrollo de Software (ISBN 0-201-57169-2), y publicado en 1999 por
Ivar Jacobson, Grady Booch y James Rumbaugh.
Comentarios sobre Metodo
Por otro lado, en lo que se refiere a la metodologa esta comprende tres principios claves: Dirigido por los casos de
uso, centrado en la arquitectura, iterativo e incremental.
En lo referente a dirigido por los casos de uso, significa que los requerimientos estn enfocado a dar valor al cliente
y que el proceso debe garantizar que todo el desarrollo, pruebas, planeacin, documentacin etc, est orientado a
cubrir estas expectativas del cliente y asegurar que los requerimientos de valor se ponen en produccin.
En lo referente a centrado en arquitectura, significa que hay un nfasis a disear una arquitectura de calidad, y es la
arquitectura tambin la que gua la forma cmo se debe planear y hacer el desarrollo.
En lo referente a iterativo e incremental, significa que el proyecto se divide en varios ciclos de vida (llamadas
iteraciones) que deben dar como resultado un ejecutable. Por cada una de las iteraciones se va agregando
requerimientos y sobre todo valor al cliente; por este motivo es incremental.
Enlaces externos
Recursos RUP en Wordpress
[2]
(en espaol)
Referencias
[1] http:/ / esl. proz. com/ kudoz/ english_to_spanish/ international_org_dev_coop/ 2221427-baseline. html
[2] http:/ / es. wordpress.com/ tag/ rup/
Mtodo de desarrollo de sistemas dinmicos
14
Mtodo de desarrollo de sistemas dinmicos
El mtodo de desarrollo de sistemas dinmicos (en ingls Dynamic Systems Development Method o DSDM) es un
mtodo que provee un framework para el desarrollo gil de software, apoyado por su continua implicacin del
usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un
sistema que reuna las necesidades de la empresa en tiempo y presupuesto. Es uno de un nmero de mtodos de
desarrollo gil de software y forma parte del alianza gil.
DSDM fue desarrollado en el Reino Unido en los aos 90 por un consorcio de proveedores y de expertos en la
materia del desarrollo de sistemas de informacin (IS), el consorcio de DSDM, combinando sus experiencias de
mejores prcticas. El consorcio de DSDM es una organizacin no lucrativa y proveedor independiente, que posee y
administra el framework. La primera versin fue terminada en enero de 1995 y publicada en febrero de 1995. La
versin actualmente en uso (abril de 2006) es la versin 4.2: El framework para el Negocio Centralizado
Desarrollado lanzado en mayo de 2003.
Como extensin del Desarrollo rpido de aplicaciones (RAD), DSDM se centra en los proyectos de sistemas de
informacin que son caracterizados por presupuestos y agendas apretadas. DSDM trata los problemas que ocurren
con frecuencia en el desarrollo de los sistemas de informacin en lo que respecta a pasar sobre tiempo y presupuesto
y otras razones comunes para la falta en el proyecto tal como falta de implicacin del usuario y de la comisin
superior de la gerencia.
DSDM consiste en 3 fases: fase del pre-proyecto, fase del ciclo de vida del proyecto, y fase del post-proyecto. La
fase del ciclo de vida del proyecto se subdivide en 5 etapas:
1. 1. estudio de viabilidad,
2. 2. estudio de la empresa,
3. 3. iteracin del modelo funcional,
4. 4. diseo e iteracin de la estructura, e
5. 5. implementacin.
DSDM reconoce que los proyectos son limitados por el tiempo y los recursos, y los planes acorde a las necesidades
de la empresa. Para alcanzar estas metas, DSDM promueve el uso del RAD con el consecuente peligro que
demasiadas esquinas estn cortadas. DSDM aplica algunos principios, roles, y tcnicas.
En algunas circunstancias, hay posibilidades para integrar contenido de otros mtodos, tal como el Proceso
Unificado de Rational (RUP), Programacin Extrema (XP), y Proyectos en ambientes controlados (PRINCE2), para
complementar el DSDM en la realizacin de un proyecto. Otro mtodo gil que tiene semejanzas proceso y concepto
con DSDM es Scrum.
Principios del DSDM
Hay 9 principios subyacentes al DSDM consistentes en cuatro fundamentos y cinco puntos de partida para la
estructura del mtodo. Estos principios forman los pilares del desarrollo mediante DSDM.
Involucrar al cliente es la clave para llevar un proyecto eficiente y efectivo, donde ambos, cliente y
desarrolladores, comparten un entorno de trabajo para que las decisiones puedan ser tomadas con precisin.
El equipo del proyecto debe tener el poder para tomar decisiones que son importantes para el progreso del
proyecto, sin esperar aprobacin de niveles superiores.
DSDM se centra en la entrega frecuente de productos, asumiendo que entregar algo temprano es siempre mejor
que entregar todo al final. Al entregar el producto frecuentemente desde una etapa temprana del proyecto, el
producto puede ser verificado y revisado all donde la documentacin de registro y revisin puede ser tenida en
cuenta en la siguiente fase o iteracin.
Mtodo de desarrollo de sistemas dinmicos
15
El principal criterio de aceptacin de entregables en DSDM reside en entregar un sistema que satisface las
actuales necesidades de negocio. No est dirigida tanto a proporcionar un sistema perfecto que resuelva todas las
necesidades posibles del negocio, si no que centra sus esfuerzos en aquellas funcionalidades crticas para alcanzar
las metas establecidas en el proyecto/negocio.
El desarrollo es iterativo e incremental, guiado por la realimentacin de los usuarios para converger en una
solucin de negocio precisa.
Todos los cambios durante el desarrollo son reversibles.
El alcance de alto nivel y los requerimientos deberan ser base-lined antes de que comience el proyecto.
Las pruebas son realizadas durante todo el ciclo vital del proyecto. Esto tiene que hacerse para evitar un caro
coste extraordinario en arreglos y mantenimiento del sistema despus de la entrega.
La comunicacin y cooperacin entre todas las partes interesadas en el proyecto es un prerrequisito
importante para llevar un proyecto efectivo y eficiente.
DSDM tambin se apoya en otros principios (tambin llamadas asunciones).
Ningn sistema es construido a la perfeccin en el primer intento (El principio de pareto - regla 80/20). En el
proceso de desarrollar un sistema de informacin, el 80% del beneficio de la empresa proviene del 20% de los
requisitos del sistema, as DSDM comienza implementando primero este 20% de requisitos para cumplir con el
80% de las necesidades de la empresa, lo que es suficientemente bueno tanto en cuanto los usuarios estn
nitmamente involucrados en el proceso de desarrollo y en una posicin de asegurar que el 20% restante no
causar serias consecuencias al negocio. Implementar la totalidad de requerimientos a menudo causa que un
proyecto supere plazos y presupuestos, as la mayora de las veces es innecesario construir la solucin perfecta.
La entrega del proyecto debera ser a tiempo, respetando presupuestos y con buena calidad.
DSDM solo requiere que cada paso del desarrollo se complete lo suficiente como para que empiece el
siguiente paso. De este modo una nueva iteracin del proyecto puede comenzar sin tener que esperar a que la
previa se complete enteramente. Y con cada nueva iteracin el sistema se mejora incrementalmente. Recurdese
que las necesidades del negocio cambian constantemente y a cualquier ritmo con el tiempo.
Ambas tcnicas de Desarrollo y Gestin del proyectos estn incluidas en DSDM.
Adems de desarrollar nuevos SI, DSDM puede ser usado tambin en proyectos de ampliacin de sistemas TI
actuales o incluso en proyectos de cambio no relacionados con las TI.
La Evaluacin de riesgos debiera centrarse en entregar funcin de negocio, no en el proceso de construccin.
La gestin recompensa la entrega de productos ms que la consecucin de tareas.
La Estimacin debera estar basada en la funcionalidad del negocio en lugar de lneas de cdigo.
Referencias
The DSDM Consortium
[1]
Coleman and Verbruggen: A quality software process for rapid application development, Software Quality
Journal 7, p. 107-1222 (1998)
Beynon-Davies and Williams: The diffusion of information systems development methods, Journal of Strategic
Information Systems 12 p. 29-46 (2003)
Brinkkemper, Saeki and Harmsen: Assembly Techniques for Method Engineering, Advanced Information Systems
Engineering, Proceedings of CaiSE'98, Springer Verlag (1998)
Abrahamsson, Salo, Ronkainen, Warsta Agile Software Development Methods: Review and Analysis, VTT
Publications 478, p. 61-68 (2002)
Tuffs, Stapleton, West, Eason Inter-operability of DSDM with the Rational Unified Process, DSDM Consortium,
Issue 1, p. 1-29 (1999)
Rietmann DSDM in a birds eye view, DSDM Consortium, p. 3-8 (2001)
iSDLC
[2]
integrated Systems Development Life Cycle
Mtodo de desarrollo de sistemas dinmicos
16
Referencias
[1] http:/ / www. dsdm. org
[2] http:/ / sdlc. bobstewart. com
Programacin extrema
La programacin extrema o eXtreme Programming (de ahora en adelante, XP) es una metodologa de desarrollo de
la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming
Explained: Embrace Change (1999). Es el ms destacado de los procesos giles de desarrollo de software. Al igual
que stos, la programacin extrema se diferencia de las metodologas tradicionales principalmente en que pone ms
nfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen
que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una
aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir
esfuerzos despus en controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de
acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida
del software.
Valores
Los valores originales de la programacin extrema son: simplicidad, comunicacin, retroalimentacin (feedback) y
coraje. Un quinto valor, respeto, fue aadido en la segunda edicin de Extreme Programming Explained. Los cinco
valores se detallan a continuacin:
Simplicidad
La simplicidad es la base de la programacin extrema. Se simplifica el diseo para agilizar el desarrollo y facilitar el
mantenimiento. Un diseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes
desarrolladores hacen que la complejidad aumente exponencialmente.
Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo
simple a medida que crece.
Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida,
intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las
variables, mtodos y clases. Los nombres largos no decrementan la eficiencia del cdigo ni el tiempo de desarrollo
gracias a las herramientas de autocompletado y refactorizacin que existen actualmente.
Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que
cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo.
Programacin extrema
17
Comunicacin
La comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms
simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo autodocumentado es ms
fiable que los comentarios ya que stos ltimos pronto quedan desfasados con el cdigo a medida que es modificado.
Debe comentarse slo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un
mtodo.
Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al
mostrar ejemplos concretos de como utilizar su funcionalidad. Los programadores se comunican constantemente
gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del
equipo de desarrollo. El cliente decide qu caractersticas tienen prioridad y siempre debe estar disponible para
solucionar dudas.
Realimentacin (feedback)
Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyecto se conoce en tiempo real.
Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no
cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es ms importante.
Considrense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda
debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El cdigo tambin
es una fuente de retroalimentacin gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias
informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos
debidos a cambios recientes en el cdigo.
Coraje o valenta
Muchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para hoy y no para maana.
Esto es un esfuerzo para evitar empantanarse en el diseo y requerir demasiado tiempo y trabajo para implementar el
resto del proyecto. La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo
cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se
implementaran mas fcilmente. Otro ejemplo de valenta es saber cuando desechar un cdigo: valenta para quitar
cdigo fuente obsoleto, sin importar cuanto esfuerzo y tiempo se invirti en crear ese cdigo. Adems, valenta
significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un da entero, y
luego lo resolver rpidamente al da siguiente, slo si es persistente.
Respeto
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los
programadores no pueden realizar cambios que hacen que las pruebas existentes fallen o que demore el trabajo de
sus compaeros. Los miembros respetan su trabajo porque siempre estn luchando por la alta calidad en el producto
y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo. Los miembros
del equipo respetan el trabajo del resto no haciendo menos a otros, una mejor autoestima en el equipo eleva su ritmo
de produccin.
Programacin extrema
18
Caractersticas fundamentales
Las caractersticas fundamentales del mtodo son:
Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresin. Se
aconseja escribir el cdigo de la prueba antes de la codificacin. Vase, por ejemplo, las herramientas de prueba
JUnit orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o PHPUnit para PHP. Estas tres
ltimas inspiradas en JUnit, la cual, a su vez, se insipir en SUnit, el primer framework orientado a realizar tests,
realizado para el lenguaje de programacin Smalltalk.
Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. La mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y discutido mientras se
escribe- es ms importante que la posible prdida de productividad inmediata.
Frecuente integracin del equipo de programacin con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin no
se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en
grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier
parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr aadir
funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y tener un
poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms
fcil identificar qu se debe y qu no se debe hacer. Cuanto ms simple es el sistema, menos tendr que comunicar
sobre ste, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de
programadores.
Roles
Programador
Escribe las pruebas unitarias y produce el cdigo del sistema.
Cliente
Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Asigna la prioridad a las
historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar el mayor valor de
negocio.
Tester
Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo
y es responsable de las herramientas de soporte para pruebas.
Programacin extrema
19
Tracker
Es el encargado de seguimiento. Proporciona realimentacin al equipo. Debe verificar el grado de acierto entre las
estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones.
Entrenador (coach)
Responsable del proceso global. Gua a los miembros del equipo para seguir el proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Ayuda
al equipo a resolver un problema especfico.
Gestor (Big boss)
Es el dueo de la tienda y el vinculo entre clientes y programadores. Su labor esencial es la coordinacin.
Enlaces externos
Sitio dedicado a la divulgacin de la programacin extrema
[1]
(en espaol)
Sitio dedicado a la divulgacin de la programacin extrema
[2]
(en ingls)
Foro Yahoo Group creado para discutir XP en Espanol (200 miembros)
[3]
Resumen de programacin extrema
[4]
Referencias
[1] http:/ / www. programacionextrema.org/
[2] http:/ / www. extremeprogramming.org/
[3] http:/ / tech. groups. yahoo.com/ group/ xpspanish/
[4] http:/ / www. chuidiang.com/ ood/ metodologia/ extrema. php
Iteracin
20
Iteracin
Iteracin significa el acto de repetir un proceso con el objetivo de alcanzar una meta deseada, objetivo o resultado.
Cada repeticin del proceso tambin se le denomina una "iteracin", y los resultados de una iteracin se utilizan
como punto de partida para la siguiente iteracin.
Matemtica
Un pentgono iterativo. Conectando esquinas alternas
de un pentgono regular se produce un pentagrama que
encierra un pequeo pentgono invertido. Iterando el
proceso genera una secuencia de pentgonos y
pentagramas anidados.
La Iteracin, en matemtica, se refiere al proceso de iteracin de
una funcin, es decir aplicando la funcin repetidamente, usando
la salida de una iteracin como la entrada a la siguiente. La
iteracin de funciones aparentemente simples pueden producir
comportamientos complejos y problemas difciles - por ejemplo,
ver la conjetura de Collatz y las secuencias del malabarista.
Otro uso de la iteracin en matemticas es en mtodos iterativos
que se usan para producir soluciones numricas aproximadas a
ciertos problemas matemticos. El mtodo de Newton es un
ejemplo de un mtodo iterativo.
Programacin
En programacin, Iteracin es la repeticin de un proceso
dentro de un programa de computadora. Puede usarse tanto
como un trmino genrico (como sinnimo de repeticin) as
como para describir una forma especfica de repeticin con un
estado mutable.
Cuando se usa en el primer sentido, la recursividad es un ejemplo de iteracin, pero que usa su propia notacin
(notacin recursiva), que no es el caso de iteracin.
Sin embargo, cuando se usa en el segundo sentido (caso ms restringido), la iteracin describe el estilo de
programacin usado en lenguajes de programacin imperativa. Esto est en contraposicin de la recursividad, la cual
tiene un enfoque ms declarativo.
He aqu un ejemplo de iteracin basndose en asignacin destructiva, en pseudocdigo imperativo:
var i=0, a := 0 // inicializo a antes de comenzar la iteracin
for i from 1 to 3 { // ciclo 3 veces
a := a + i // incremento a con el valor actual de i
print a // se imprime el nmero 6
}
En este fragmento de programa, el valor de la variable i cambia a medida que la ejecucin del programa progresa,
tomando los valores 1, 2 y 3. Este cambio de valor o estado mutable es caracterstico de una iteracin.
La iteracin puede aproximarse por medio de tcnicas recursivas en lenguages de programacin funcional. El
ejemplo que sigue est escrito en Scheme. Ntese que es un cdigo recursivo (un caso especial de iteracin), pues la
definicin de "cmo iterar", la funcin iter, se llama a s misma de manera de solucionar la instancia del problema.
Especficamente, usa recursin al final de la cola, la cual est presente en lenguajes como Scheme para que no se
requiera usar grandes cantidades de espacio del stack.
Iteracin
21
;; sum : number -> number
;; to sum the first n natural numbers
(define (sum n)
(if (and (integer? n) (> n 0))
(let iter ([n n] [i 1])
(if (= n 1)
i
(iter (- n 1) (+ n i))))
((assertion-violation
'sum "invalid argument" n))))
Un iterador es un objeto que engloba la iteracin.
Tambin, la iteracin se realiza usando una hoja de clculo, o mediante el uso de solucionadores o funciones
predefinidas disponibles en Excel. Muchas ecuaciones implcitas, como por ejemplo la ecuacin Colebrook, se
pueden resolver en la comodidad de una hoja de clculo, mediante el diseo de algoritmos adecuados de clculo.
Muchos de los problemas de ingeniera como la resolucin de ecuaciones de Colebrook llegan a 8 dgitos de
precisin con tan solo 12 repeticiones y es suficiente un mximo de 100 iteraciones para alcanzar un resultado
preciso de 15 dgitos.
Gestin de proyectos
Iteraciones en gestin de proyectos giles
Iteraciones en el contexto de un proyecto se refieren a la tcnica de
desarrollar y entregar componentes incrementales de funcionalidades
de un negocio. Esto est comnmente asociado al desarrollo gil de
software, pero podra referirse a cualquier material. Una iteracin
resulta en uno o ms paquetes atmicos y completos del trabajo del
proyecto que pueda realizar alguna funcin tangible del negocio.
Mltiples iteraciones contribuyen a crear un producto completamente
integrado. A esto se lo compara comnmente con el enfoque de
desarrollo en cascada.
Referencias
Desarrollo en cascada
22
Desarrollo en cascada
En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada (denominado as por la
posicin de las fases en el desarrollo de esta, que parecen caer en cascada por gravedad hacia las siguientes fases),
es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal
forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.
[1]
Al final de cada etapa, el
modelo est diseado para llevar a cabo una revisin final, que se encarga de determinar si el proyecto est listo para
avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los dems modelos de
ciclo de vida.
La versin original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en
1980 e Ian Sommerville en 1985.
[2]
Un ejemplo de una metodologa de desarrollo en cascada es:
1. 1. Anlisis de requisitos.
2. 2. Diseo del Sistema.
3. 3. Diseo del Programa.
4. 4. Codificacin.
5. 5. Pruebas.
6. 6. Verificacin.
7. 7. Mantenimiento.
De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva
programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la
metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de
un proyecto.
Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria
[citarequerida]
, sigue siendo el
paradigma ms seguido al da de hoy.
Desarrollo en cascada
23
Fases del modelo.
El "modelo cascada" sin modificar. El progreso fluye de arriba haca abajo, como una
cascada.
Anlisis de requisitos
En esta fase se analizan las
necesidades de los usuarios
finales del software para
determinar qu objetivos debe
cubrir. De esta fase surge una
memoria llamada SRD
(documento de especificacin de
requisitos), que contiene la
especificacin completa de lo
que debe hacer el sistema sin
entrar en detalles internos.
Es importante sealar que en
esta etapa se debe consensuar
todo lo que se requiere del
sistema y ser aquello lo que
seguir en las siguientes etapas,
no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software de una manera.
Diseo del Sistema
Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las
ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que
contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer
cada una de sus partes, as como la manera en que se combinan unas con otras.
Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos
tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema)
identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se
define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del
cdigo para comenzar la implementacin...
Diseo del Programa
Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del
usuario as como tambin los anlisis necesarios para saber qu herramientas usar en la etapa de Codificacin
Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos
para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables
dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido.
Desarrollo en cascada
24
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona
correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.
Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron
exhaustivas pruebas para comprobar que el sistema no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo.
Mantenimiento
Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya
que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.
para el software
Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se
establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de
fallos.
Otros ejemplos de variantes del modelo en cascada son el modelo en cascada con fases solapadas, cascada con
subproyectos, y cascada con reduccin de riesgos.
[3]
Ventajas
Realiza un buen funcionamiento en equipos dbiles y productos maduros, por lo que se requiere de menos
capital y herramientas para hacerlo funcionar de manera ptima.
Es un modelo fcil de implementar y entender.
Est orientado a documentos.
Es un modelo conocido y utilizado con frecuencia.
Promueve una metodologa de trabajo efectiva: Definir antes que disear, disear antes que codificar.
[4]
Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del
modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta
que el software no est completo no se opera. Esto es la base para que funcione bien.
Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva
programacin del cdigo afectado, aumentando los costos del desarrollo.
Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa
anterior.
Desarrollo en cascada
25
Referencias
[1] [1] S. Pressman, Roger. Ingeniera del Software: Un enfoque prctico, 3. Edicin, Pag. 26-30.
[2] (http:/ / www.iidia.com.ar/ rgm/ comunicaciones/ c-icie99-ingenieriasoftwareeducativo. pdf), Ingenieria De Software Educativo, Cataldi,
Z., Lage, F., Pessacq, R. y Garca Martnez, R..
[3] (http:/ / fsi201lsca. blogspot. com/ 2011/ 02/ modelos-del-ciclo-de-vida-de-software. html), Patricia Arieta Melgarejo, Modelos del ciclo de
vida de software.
[4] (http:/ / sistemas.uniandes.edu.co/ ~isis2603/ dokuwiki/ lib/ exe/ fetch. php?media=principal:isis2603-modelosciclosdevida. pdf), Ruby
Casallas, Andrs Yie, Ingeniera de Software: Ciclos de Vida y Metodologas.
Enlaces externos
Ciclo de vida del software (http:/ / www. ia. uned. es/ ia/ asignaturas/ adms/ GuiaDidADMS/ node10. html)
Scrum
Ciclos de desarrollo.
Ficha sinptica
Marco de Trabajo SCRUM
Scrum es un modelo de desarrollo gil caracterizado por:
Adoptar una estrategia de desarrollo incremental, en lugar de la
planificacin y ejecucin completa del producto.
Basar la calidad del resultado ms en el conocimiento tcito de las
personas en equipos autoorganizados, que en la calidad de los
procesos empleados.
Solapamiento de las diferentes fases del desarrollo, en lugar de
realizar una tras otra en un ciclo secuencial o de cascada.
Historia
Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka
Takeuchi a principios de los 80, al analizar cmo desarrollaban los
nuevos productos las principales empresas de manufactura tecnolgica:
Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y
Hewlett-Packard (Nonaka & Takeuchi, The New New Product
Development Game, 1986)
En su estudio, Nonaka y Takeuchi compararon la nueva forma de
trabajo en equipo, con el avance en formacin de scrum de los
jugadores de Rugby, a raz de lo cual qued acuado el trmino
scrum para referirse a ella.
Aunque esta forma de trabajo surgi en empresas de productos
tecnolgicos, es apropiada para proyectos con requisitos inestables y
para los que requieren rapidez y flexibilidad, situaciones frecuentes en
el desarrollo de determinados sistemas de software.
En 1995 Ken Schwaber present Scrum Development Process en
OOPSLA 95 (Object-Oriented Programming Systems & Applications
conference)(SCRUM Development Process), un marco de reglas para desarrollo de software, basado en los
principios de scrum, y que l haba empleado en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel
Corporation (compaa que en los macrojuegos de compras y fusiones, se integrara en VMARK, y luego en
Informix y finalmente en Ascential Software Corporation)
Scrum
26
Caractersticas de Scrum
SCRUM es un modelo de referencia que define un conjunto de prcticas 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 caractersticas 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 reunin
de Sprint Planning. Durante esta reunin, 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.
[1]
Durante el sprint, nadie puede cambiar el Sprint
Backlog, lo que significa que los requisitos estn congelados durante el sprint.
Scrum permite la creacin de equipos autoorganizados impulsando la co-localizacin de todos los miembros del
equipo, y la comunicacin 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 desafos impredecibles no
pueden ser fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una
aproximacin pragmtica, aceptando que el problema no puede ser completamente entendido o definido, y
centrndose en maximizar la capacidad del equipo de entregar rpidamente y responder a requisitos emergentes.
Las caractersticas ms marcadas que se logran notar en Scrum seran: gestin regular de las expectativas del cliente,
resultados anticipados, flexibilidad y adaptacin, retorno de inversin, mitigacin de riesgos, productividad y
calidad, alineamiento entre cliente y equipo, por ltimo equipo motivado. Cada uno de estos puntos mencionados
hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prcticas para el trabajo en equipo y de
esa manera obtener resultados posibles.
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 fcil 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 trabaje 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 obstculos que impiden que
el equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del equipo (porque ellos se
auto-organizan), sino que acta como una proteccin 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
Scrum
27
El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 3 a 9 personas con las
habilidades transversales necesarias para realizar el trabajo (anlisis, diseo, desarrollo, pruebas,
documentacin, 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
aproximacin gil es la prctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados
(stakeholders). Es importante que esa gente participe y entregue retroalimentacin 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 produccin. Slo participan directamente durante las revisiones del sprint.
Administradores (Managers)
Es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum o Stand-up meeting
Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llama daily standup o Stand-up
meeting. El scrum tiene unas guas especficas:
La reunin comienza puntualmente a su hora.
Todos son bienvenidos, pero slo los involucrados en el proyecto pueden hablar.
La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del equipo.
La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das.
Durante la reunin, cada miembro del equipo contesta a tres preguntas:
[2]
Qu has hecho desde ayer?
Qu es lo que hars hasta la reunin de maana?
Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar
estos impedimentos).
Scrum de Scrum
Cada da normalmente despus del Daily Scrum:
Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocndose especialmente en reas de
solapamiento e integracin.
Asiste una persona asignada por cada equipo.
La agenda ser la misma que la del Daily Scrum, aadiendo adems las siguientes cuatro preguntas:
Qu ha hecho tu equipo desde nuestra ltima reunin?
Qu har tu equipo antes que nos volvamos a reunir?
Hay algo que demora o estorba a tu equipo?
Ests a punto de poner algo en el camino del otro equipo?
Scrum
28
Reunin de Planificacin del Sprint (Sprint Planning Meeting)
Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de Planificacin del Sprint se lleva a cabo.
Seleccionar qu trabajo se har
Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomar hacer el trabajo.
Identificar y comunicar cunto del trabajo es probable que se realice durante el actual Sprint
Ocho horas como lmite
Al final del ciclo Sprint, dos reuniones se llevarn a cabo: la Reunin de Revisin del Sprint y la Retrospectiva del
Sprint
Reunin de Revisin del Sprint (Sprint Review Meeting)
Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (alias demo)
El trabajo incompleto no puede ser demostrado
Cuatro horas como lmite
Retrospectiva del Sprint (Sprint Retrospective)
Despus 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 recin superado. El propsito de la retrospectiva es realizar una mejora continua del
proceso. Esta reunin tiene un tiempo fijo de cuatro horas.
Sprint
El Sprint es el perodo en el cual se lleva a cabo el trabajo en s. Es recomendado que la duracin de los sprints sea
constante y definida por el equipo con base en su propia experiencia. Se puede comenzar con una duracin de sprint
en particular (2 o 3 semanas) e ir ajustndolo con base en el ritmo del equipo, aunque sin relajarlo demasiado. Al
final de cada sprint, el equipo deber presentar los avances logrados, y el resultado obtenido es un producto
potencialmente entregable al cliente. Asimismo, se recomienda no agregar objetivos al sprint o sprint backlog a
menos que la falta de estos objetivos amenace al xito del proyecto. La constancia permite la concentracin y mejora
la productividad del equipo de trabajo.
Beneficios de Scrum
Flexibilidad a cambios. Gran capacidad de reaccin ante los cambiantes requerimientos generados por las
necesidades del cliente o la evolucin del mercado. El marco de trabajo est diseado para adecuarse a las
nuevas exigencias que implican proyectos complejos.
Reduccin del Time to Market. El cliente puede empezar a utilizar las caractersticas ms importantes del
proyecto antes de que est completamente terminado.
Mayor calidad del software. El trabajo metdico y la necesidad de obtener una versin de trabajo funcional
despus de cada iteracin, ayuda a la obtencin de un software de alta calidad.
Mayor productividad. Se logra, entre otras razones, debido a la eliminacin de la burocracia y la motivacin
del equipo proporcionado por el hecho de que pueden estructurarse de manera autnoma.
Maximiza el retorno de la inversin (ROI). Creacin de software solamente con las prestaciones que
contribuyen a un mayor valor de negocio gracias a la priorizacin por retorno de inversin.
Predicciones de tiempos. A travs de este marco de trabajo se conoce la velocidad media del equipo por
sprint, con lo que es posible estimar de manera fcil cuando se podr hacer uso de una determinada
funcionalidad que todava est en el Backlog.
Scrum
29
Reduccin de riesgos El hecho de llevar a cabo las funcionalidades de mayor valor en primer lugar y de saber
la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente de manera
anticipada.
[3]
Documentos
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genricas de todos
los requisitos, funcionalidades deseables, etc. priorizadas segn su retorno sobre la inversin (ROI) . Es el qu va a
ser construido. Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones realizadas a
grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimacin ayuda al
product owner a ajustar la lnea temporal(KEV) y, de manera limitada, la prioridad de las diferentes tareas. Por
ejemplo, si dos caractersticas tienen el mismo valor de negocio la que requiera menor tiempo de desarrollo tendr
probablemente ms prioridad, debido a que su ROI ser ms alto.
Sprint backlog
El sprint backlog es un documento detallado donde se describe el cmo el equipo va a implementar los requisitos
durante el siguiente sprint. Las tareas se dividen en horas pero ninguna tarea con una duracin superior a 16 horas.
Si una tarea es mayor de 16 horas, deber ser dividida en otras menores. Las tareas en el sprint backlog nunca son
asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno.
Burn down chart
La burn down chart es una grfica mostrada pblicamente que mide la cantidad de requisitos en el Backlog del
proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte los puntos de todos los Sprints
completados, podremos ver el progreso del proyecto. Lo normal es que esta lnea sea descendente (en casos en que
todo va bien en el sentido de que los requisitos estn bien definidos desde el principio y no varan nunca) hasta llegar
al eje horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes de ser
completados en el Backlog). Si durante el proceso se aaden nuevos requisitos la recta tendr pendiente ascendente
en determinados segmentos, y si se modifican algunos requisitos la pendiente variar o incluso valdr cero en
algunos tramos.
Notas
[1] Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN 0-7356-1993-X
[2] [2] page 135
[3] http:/ / www. proyectosagiles. org/ beneficios-de-scrum
Referencias
(PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams (http:/ /
members. cox. net/ risingl1/ Articles/ IEEEScrum. pdf) Retrieved March 15, 2007
(PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process (http:/ / jeffsutherland.
com/ scrumpapers. pdf) Retrieved July 01, 2010
(video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google (http:/ / www.
youtube. com/ watch?v=9y10Jvruc_Q) Retrieved 2007-12-15
(video) Ken Schwaber in Scrum et al. (http:/ / www. youtube. com/ watch?v=IyNPeTn8fpo) Retrieved
2008-01-19
Scrum
30
Enlaces externos
Comunidades o grupos de usuarios
Asociacin Agile-Spain (http:/ / www. agile-spain. org) : la comunidad agilista en Espaa
giles (http:/ / agiles. org) : la comunidad agilista latinoamericana
ScrumManager (http:/ / www. scrummanager. net/ ok) : Plataforma profesional de conocimiento libre
Comunidad gil Colombia (http:/ / www. agilespin. com) : Comunidad agilista Colombia
Comunidad agilmtica (http:/ / comunidad. agilmatica. com/ )
Libros originales o traducciones al espaol
Libro gratuito sobre Scrum (http:/ / www. navegapolis. net/ content/ view/ 694/ 61/ )
Traduccin de "The Scrum Primer" (http:/ / scrumtraininginstitute. com/ library)
"Scrum y XP desde las trincheras", traduccin de "Scrum and XP from the trenches" por Henrik Kniberg (http:/ /
www. proyectalis. com/ 2008/ 02/ 26/ scrum-y-xp-desde-las-trincheras/ )
Portales temticos y blogs
Scrum Manager: Comunidad gil de habla hispana. Cursos online gratuitos (http:/ / www. scrummanager. net)
proyectosAgiles.org: base de conocimiento gratuita de Scrum en espaol (http:/ / www. proyectosagiles. org)
Metodologa de gestin de proyectos basada en Scrum (http:/ / navegapolis. metocube. com/ )
Artculos sobre Scrum de Rodrigo Corral (http:/ / geeks. ms/ blogs/ rcorral/ archive/ tags/ Scrum/ default. aspx)
Thinking-in-process (http:/ / b-efficient. blogspot. com. es) Blog sobre procesos, gestin de proyectos y Scrum
Artculos y otros recursos
Hoja Excel para grficos de progreso scrum (http:/ / www. navegapolis. net/ index. php?option=com_content&
task=view& id=268& Itemid=84)
Artculo de introduccin a Scrum (http:/ / www. chuidiang. com/ ood/ metodologia/ scrum. php)
Explicando Scrum a mi abuela por Jorge Serrano (http:/ / geeks. ms/ blogs/ jorge/ archive/ 2007/ 05/ 09/
explicando-scrum-a-mi-abuela. aspx)
Artculo sobre Scrum en Espaol (http:/ / swsaber. com/ scrum/ )
PPT reutilizable de introduccin a Scrum, original de Mike Cohn, traduccin de Ernesto Grafeuille (http:/ / www.
mountaingoatsoftware. com/ system/ asset/ file/ 66/ SpanishRedistributableIntroToScrum. ppt)
Sencillo generador online de grficas burndown (http:/ / www. burndowngenerator. com/ )
Herramientas y Software para Scrum (http:/ / www. unbugalavez. net/ 2008/ 03/ herramientas-para-scrum. html)
Notas de Scrum (http:/ / sedici. unlp. edu. ar/ handle/ 10915/ 5519)
Una comparacin entre Scrum y DevOps (http:/ / b-efficient. blogspot. com. es/ 2012/ 09/
introduccion-devops-el-siguiente-paso. html)
Scrum en 1 pgina (http:/ / www. scribd. com/ doc/ 134880180/ SCRUM-La-guia-de-1-pagina)
Scrum Teora revolucionara, Amortizando los errores para controlarlos Analizarlos y solucionarlo al momento <3
Fuentes y contribuyentes del artculo
31
Fuentes y contribuyentes del artculo
Desarrollo iterativo y creciente Fuente: http://es.wikipedia.org/w/index.php?oldid=75965980 Contribuyentes: BlackBeast, Bloomy, Corvocativo, Davidarturo21, Diegusjaimes, Dominic1593,
Elnico2787, Farnhey, Foundling, Jose figueredo, LeinaD natipaC, LinkYanela, Martingala, Nathy2893, Osepu, Redjhawk, Technopat, UA31, Vanbasten 23, Varano, 39 ediciones annimas
Framework Fuente: http://es.wikipedia.org/w/index.php?oldid=76067773 Contribuyentes: Acratta, Addsmgt, Afrasiab, Alalou, Aliman5040, Aloriel, AnselmiJuan, Antonio V. G., Antonorsi,
Armando.Mejia, Asereware, Bibliofilotranstornado, Carmin, Christianikolai, David Jos Valenzuela, Davidangelleoacedo, Diegusjaimes, Digigalos, Eaco, Edub, El Moska, Elabra sanchez,
Eliurkis, Emilioar 2000, Ensada, Fernando Estel, Gacpro, GermanX, Globalpegasus, Grillitus, Helmy oved, Humberto, Isha, Jag2k4, Javierpaniza, Jkbw, Jonik, Jorge 2701, Josexu32, Julian
Mendez, Jynus, Kalith, Klohn, Laura Fiorucci, Leugim1972, Linnk, LordT, Luciano peti, Maldoror, Mansoncc, Mapa-uv, Matdrodes, Matute, Millars, Minterior, Mushii, Octaviocortes, Osepu,
Pablo323, Paporrubio, Pateketrueke, Ppazos, Qwertyytrewqqwerty, Robert77, Rodrigouy7, Serverex, Shooke, Solucionexacta, SuperBraulio13, Taty2007, Tirithel, Tomatejc, Tostadora, UA31,
Vanbasten 23, VeroSantillanRoldan, Waeswaes, Wikiseldon, Wilfredor, Yrithinnd, 197 ediciones annimas
Proceso Unificado de Rational Fuente: http://es.wikipedia.org/w/index.php?oldid=75774542 Contribuyentes: Airunp, Alvaro qc, Anassesduses, Angeldx7, Antonorsi, Antur, Ascnder,
Asereware, Banfield, Belgrano, Beosman, Cad, Ctrl Z, Daliatru, Desormais, Diegusjaimes, Diesil, Dorieo, El loko, Elfrasco, Elwikipedista, Emosqueira, Enrique Cordero, Fjpatonnoblejas, Galio,
GermanX, Gizmo II, Grillitus, HUB, Hari Seldon, Humberto, Jcgarcianaranjo, Jkbw, Jonpagecr, Kaiser998, Klndrcht, Komputisto, Krlts, Lasneyx, Laura Fiorucci, Leonpolanco, LordT, Magister
Mathematicae, Maido155, Maldoror, Manuelt15, Manw, MarcoAurelio, Marcoantoniop, Marttott, Matdrodes, Mleger45, Mnemoc, Oscarvf99, Poco a poco, Plux, Raulshc, Retama, RuLf,
Rge, Sabbut, Scarsix06d, SuperBraulio13, Tano4595, Tirithel, UA31, Vitamine, Waeswaes, Xjres, Yaokizki, Yonelbys, 415 ediciones annimas
Mtodo de desarrollo de sistemas dinmicos Fuente: http://es.wikipedia.org/w/index.php?oldid=64960273 Contribuyentes: Avicentegil, Bigsus, Daniel G., Diegusjaimes, Dodo, Elwikipedista,
Grillitus, Jonpagecr, Jose casal, Matdrodes, Poco a poco, Roberto Fiadone, Rosarinagazo, 10 ediciones annimas
Programacin extrema Fuente: http://es.wikipedia.org/w/index.php?oldid=75614160 Contribuyentes: Asierra, AtaraxioJ, Balles2601, Bucephala, Camilo, Camoralesm, Danidsaster, Frutoseco,
GermanX, Gonxoz, Guille.hoardings, Idatacubo, Isha, J.delanoy, JCX, Jacm, Jaguar080, JavierCantero, Jmbeas, JorgeBerjano, Jorgechp, Juan.palacio, Jucapac, Kaizen2007, Kekkyojin,
Lastmasta, Maciek, ManuelGR, Mardolf, Martingala, Miguel.lima, Mikel Gmez, Moriel, Murphy era un optimista, PabloCastellano, Pieter, Poco a poco, Porao, Rahkso, Richard Lyon,
Rodrigo.pina, STANHMAL, Sabbut, Srgank, Tano4595, Technopat, Tute, Viko, Voise, Youssefsan, 113 ediciones annimas
Iteracin Fuente: http://es.wikipedia.org/w/index.php?oldid=73894270 Contribuyentes: Acratta, Alejandrocaro35, Cobalttempest, Ignacioerrico, Jkbw, Juan Mayordomo, Mercenario97,
Resped, Santga, Technopat, 48 ediciones annimas
Desarrollo en cascada Fuente: http://es.wikipedia.org/w/index.php?oldid=76178988 Contribuyentes: Adribeex, Alexandermark, Alhen, Almogo, Axxgreazz, Ayaita, Barteik, Bethan 182,
Bolivarista, Bordierrez, DJ Nietzsche, Decorrea, Diegusjaimes, Edub, Ejmeza, Ejrrjs, FAR, Feperozpo, Fsd141, Gacpro, GermanX, Greek, Harpagornis, Humberto, Icvav, Infovoro, Irtusb, Isha,
JRGL, Jedijor14, Jesua3005, Jkbw, Jonpagecr, Jose figueredo, Jossue130987, Julianromera, Lcsrns, Luckas Blade, Mahadeva, Markoszarrate, Matdrodes, Melgar22, Milestones, Osepu,
Penyaskito, Ppedrodom, Plux, Renciw, Richy, Roinpa, Rotlink, SuperBraulio13, Superzerocool, Technopat, Tremal Naik, UA31, Unf, Vitamine, Yrithinnd, 280 ediciones annimas
Scrum Fuente: http://es.wikipedia.org/w/index.php?oldid=76316717 Contribuyentes: Adelpine, Alex of Bcn, Alexav8, Aquileaaquilea, Arturo.Van, Balles2601, C lamarque, Caskete,
Diamondland, Dieguen, Diegusjaimes, Dodo, EGA Futura, Ecelan, Edc.Edc, Fpablos, Fran.naranjo, Fritz11, Hcquinteroz, Henaldog, Hernaldo, Hhiroshi, Hprmedina, J.M.Domingo, Jacorream,
Jago84, Jdemarcos, Jgalgarra, Jkbw, Jmbeas, Jmdmmx, Juan.palacio, Julie, Kamusclown, Kijote, Leoparra86, Mac1800, Maldoror, Mansoft, Martingala, Maxie Ayala, Mescalier, Mhidalgolache,
Miguel Visuete, Moises003, Mpeinadopa, Mushii, N.garbezza, Obed.mx, Oscar ., Osepu, Parlamento, Penelopina, Poco a poco, Qwertyytrewqqwerty, RNL89, Raggha, Ralgis, Ray iceman,
Rosarino, Saloca, Santiagobas, Saulnoelm, Savh, Sindestino, Solde, Susibel, Technopat, Tokvo, Treiscort, Vegafernando, Xavier Albaladejo, Ynnek, 231 ediciones annimas
Fuentes de imagen, Licencias y contribuyentes
32
Fuentes de imagen, Licencias y contribuyentes
Archivo:Rup espanol.gif Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Rup_espanol.gif Licencia: Creative Commons Attribution-ShareAlike 3.0 Unported Contribuyentes:
Angeldx7
Archivo:Pentagon iteration.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Pentagon_iteration.svg Licencia: Creative Commons Attribution-ShareAlike 3.0 Unported
Contribuyentes: Cronholm144
File:Agile Project Management by Planbox.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Agile_Project_Management_by_Planbox.png Licencia: Creative Commons
Attribution-Sharealike 3.0 Contribuyentes: User:Fongamanda
Archivo:El modelo de desarrollo en cascada.svg Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:El_modelo_de_desarrollo_en_cascada.svg Licencia: Creative Commons
Attribution 3.0 Contribuyentes: Achuter, Torsch
Archivo:Ciclos de desarrollo.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Ciclos_de_desarrollo.png Licencia: Creative Commons Attribution-ShareAlike 3.0 Unported
Contribuyentes: Juan.palacio, WikipediaMaster
Archivo:Ficha scrum.png Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Ficha_scrum.png Licencia: Creative Commons Attribution-Sharealike 2.5 Contribuyentes: Juan.palacio,
KTo288
File:Scrumm.PNG Fuente: http://es.wikipedia.org/w/index.php?title=Archivo:Scrumm.PNG Licencia: Creative Commons Attribution-Sharealike 3.0 Contribuyentes: User:Maxie Ayala
Licencia
33
Licencia
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/