Cmo fallar con el Rational Unified Process: Siete pasos para el dolor y el sufrimiento

Craig Larman Jefe Cientfico, Valtech EE.UU. craig@craiglarman.com Philippe Kruchten Fellow Racional, Rational Software Canad pbk@rational.com Kurt Bittner Gerencia General Manager, Procesos y Proyectos Unidad de Negocio, Rational Software kbittner@rational.com

Resumen: El Proceso Racional Unificado constituye un marco til para abordar el negocio del desarrollo de software. Como marco de referencia, sin embargo, debe adaptarse a las necesidades de cada equipo de proyecto y sus circ unstancias, sino que est destinada a ser aplicada en una luz y el estilo gil, y no se ha adoptado como un proceso de una sola talla para todos. Este artculo comparte una serie de errores comunes que experimentan los equipos que intentan adaptar el Rational Unified Process para sus ne cesidades, presentado con un poco de la lengua en la mejilla.

El Rational Unified Process (RUP ) [1] [2] se ha convertido en un popular estndar de facto desarrollo moderno de software de procesos que sentimos con buena razn. Combina las mejores prcticas reconocidas como de adaptaci n, iterativo y el desarrollo impulsado por riesgo, ha sido desarrollado por los lderes de clase mundial con experiencia tanto en el desarrollo de sistemas pequeos y grandes, es flexible en su aplicacin y ampliacin, y se h a documentado en forma coherente tanto impresin y el producto en lnea RUP. Sin embargo, hay factores que inhiben la adopcin exitosa de las RUP, dando lugar a mucho menos que los resultados ptimos. Hay patrones en estos fracasos si desea aprender de ellos, para lo cual, si su objetivo es el fracaso espectacular con el RUP, le recomendamos los siguientes pasos.

Paso 1: Superponer Waterfall Pensamiento

Su proceso de desarrollo de algo como esto? 1. 2. 3. 4. Trata de definir y estabilizar la mayor parte de los requisitos, el cierre de sesin en ell Hacer el diseo detallado, basado en los requisitos. Implementar, basado en el diseo. Integracin, pruebas del sistema, y el despliegue. os.

Copyright Valtech Technologies & Rational Software, 2001

1/14

Este es un ejemplo de una relacin lineal, secuencial cascada ciclo de vida, y es la primera estrategia, el mejor, y el ms comn para el fracaso RUP total. Si el proceso se siente algo como lo anterior, usted sabe que no s e han adoptado con xito el RUP. Se ha argumentado [3] que el ciclo de vida de cascada como se haba previsto no dara lugar al grado de fracaso que ha engendrado, y es ms bien debido a un malentendido que se ha aplicado torpemente. Buen punto, pero estamos hablando de la cascada como es comnmente aplicado o mal aplicado hoy. Con respecto a los niveles de falla, tenga en cuenta que un anlisis del xito del proyecto y el fracaso en 1994 [4], cuando la mayor parte del desarrollo fue puramente ad hoc o sobre la base de las prcticas Proceso en Casca da (como hoy, diramos), que se estima que slo el 70% del software proyectos fueron terminados, que ms del 50% del costo de por lo menos el doble de su estimacin original, y que 81 mil millones dlares EE.UU. se destinaron a proyectos cancelados en los EE.UU. solamente. Este es un tipo de problema extraordinario, lo de siempre no funciona. Para su crdito, el Departamento de Defensa de EE.UU., un importante contratista de servicios de desarrollo de software, que originalmente promovieron procesos de cascada y actitudes, al observar tanto fracaso con el enfoque, no slo ha cado este requisito (retirado en 1988 en STD-2167A) , pero en un informe de 1994 empez a animar activamente ms modernos ciclos de vida iterativos para reemplazar la cascada [5]. Sin embargo, la inercia es un problema y no queda superposicin de actitudes en cascada a los proyectos: Felicidades, el Departamento de Defensa se utilizar un proceso iterativo para este proyecto. Ahora, el primer paso: Por favor, enve los requisitos completos para que podamos firmar con ellos. Entonces vamos a concretar el diseo, ... Los procesos inspirados en cascada, eran una reaccin a la dcada de 1960 antes de enfoques ad hoc para el desarrollo de software. A diferencia de la anterior falta de estructura, fue una respuesta racional y, de hecho, los m todos de cascada de esta poca fueron llamados estructurada para enfatizar este punto. El enfoque se inspir, como suele ser el caso en las nuevas fronteras-de lo que fue conocido y familiar, es decir, fro m ingeniera y con struccin en otros mbitos, como la construccin-do con los requisitos, a continuacin, hacer el diseo, y luego construir. Lamentablemente, el enfoque fue adoptado y enseado sin la investigacin crtica sobre su idoneidad p ara el verdadero desarrollo de software, y varias generaciones de estudiantes y educadores simplemente aprende y repite el consejo. Algunas cosas deben ser construidas como edificios, como, bueno ... edificios. Sin embargo, resulta que el software no es generalmente uno de ellos . Hay un nmero de razones para esto. La ms convincente es la suposicin errnea de que la mayora de los requisitos se pueden definir en la primera fase del proyecto. La investigacin deconstruir el mito incluye obras de Cape rs Jones [6]. Como se ilustra en la Figura 1, en este estudio muy grande de 6.700 proyectos, arrastrndose los requisitos-no prev cerca de la puesta son un hecho muy importante de la vida de desarrollo de software, que van desde alrededor de 25% en proyectos de promedio de hasta 50% en las grandes . Boehm y Papaccio presentan similares basadas en la investigacin conclusiones en [7].

Copyright Valtech Technologies & Rational Software, 2001

2/14

60 50 40 30 20 1 0 10 100 1000 10000 100000

Tamao del proyecto en puntos de funcin

Figura 1 Requisitos cambiantes son la norma

Actitudes cascada, que lucha en contra (o, simplemente, negar) este hecho al asumir los requisitos y los diseos pueden-con el suficiente esfuerzo y habilidad-se ha especificado correctamente y congelados, son absolutamente i . Hay varias razones para esta falta de habilidad en el desarrollo de software de precisar los requisitos antes de diseo e implementacin. Ellos incluyen: o La flexibilidad sin precedentes y las opciones disponibles para el software ; fuerzas o psicolgicas y organizativas que impiden aprovechar en su totalidad, precisa y adecuada especulativamente definir un sistema de software (sin adaptacin ciclos de retroalimentacin), o Los idiomas imprecisas de espe ; o diseos imperfectos e implementaciones ; o que cambian rpidamente las fuerzas del mercado, que motivan cambios, etc . Cualesquiera que sean las razones, la respuesta no es hbil para combatir el cambio y esforzarse ms para precisar los requisitos abajo (al igual que la respuesta de cascada), sino ms bien, como Kent Beck ha sugestivamente lo expres [8], para aceptar el cambio como motor central en el proceso. Por consiguiente, en el RUP, el desarrollo procede lugar a travs de una serie de iteraciones, cada uno de los cuales es timeboxed para una duracin fija (por ejemplo, exactamente cuatro semanas), y que termina en una versi n estable interna de un subconjunto del sistema final. Timeboxing es un concepto clave en el desarrollo iterativo: se trata de fijar la fecha de finalizacin de la iteracin, y normalmente no permiten el deslizamiento de lafecha. Si todos los objetivos no se pueden cumplir, requisitos se eliminan de la iteracin, en lugar de ampliar la duracin de iteracin. Dentro de una iteracin, hay algo as como un miniwaterfall. Un pequeo conjunto de requisitos es elegido y analizado con ms detalle (tal vez priorizadas por riesgo alto valor o de negocios); unos das se gastan en diseo, y luego el equipo se enciende rpidamente implementacin, integracin y pruebas de sistema realista y el estrs de una parte de el sistema. Al final de cada iteracin los resultados en un sistema en
Copyright Valtech Technologies & Rational Software, 2001

3/14

ejecucin parcial, que gene ra retroalimentacin, que conduce a la adaptacin de los requisitos y de diseo en las versiones futuras. Con el tiempo, estos retroalimentacin adaptacin ciclos iterativos revelar una serie adecuada de las necesidades y un diseo robusto, probado y ejecucin. Tenga en cuenta que un enfoque en cascada secuencial se aplica a la escala de semanas, no meses o aos,

y que no existe un mecanismo integrado para la retroalimentacin y adaptacin. En la escala de tiempo de algunas semanas, un ciclo de vida secuencial puede trabajar, sin embargo, se descompone a medida que aumenta la longitud . Dado que la realidad es que los requerimientos cambian durante el diseo e implementacinsignificativamente-las pospone modelo de cascada que se ocupan de este riesgo importante (y por lo tanto la realidad) hasta el final de l ciclo de vida, a menudo hasta que es demasiado tarde para hacer algo al respecto. Un proyecto cascada ciclo de vida puede ser tan propenso a error ya que los anteriores enfoques ad hoc que reemplaz, pero va sobre l de una manera ms ordenada (el proyecto puede estar en el camino correcto hacia arriba hasta que un fallo catastrfico). Sin embargo, debido a la supuesta falta de una alternativa lgica, muchas personas han sentido que no han teni do ms remedio que seguir utilizando un modelo basado en suposiciones errneas. Las organizaciones se han habituado a la f obvio en cursoailures o dificultades en el desarrollo de software que se basa en los principios de laia son en primer lugar, hay empresas de consultora, directores, maestros y escritores que promueven el ciclo de vida de cascada o actitudes sulting companies, managers, teachers, and writers who promote the waterfall lifecycle or attitudes como hbil, lo cual es lamentable. Por lo tanto, el pensamiento cascada impregna nuestras creencias de desarrollo de manera sistmica y sutil a veces, y como consecuencia de ello, es especialmente comn entre los adoptantes RUP para superponer los valores y pr . Para ser claros sobre los valores cascada y prcticas comunes: o En primer lugar, la mayora de los requisitos, por lo que el supuesto implcito de que los requisitos pueden ser bien definidas por los usuarios de un producto que no han visto antes o Segundo, hacer el diseo detallado en el supuesto de que la solucin a un problema mal definido se puede definir con precisin . o Tercero, poner en prctica, aunque el diseo no est probada y con frecuencia no demostrable . o Cuarto, integrar, probar y desplegar . Dentro del alcance de estas actividades: o Trate a fondo el desarrollo de un artefacto, tales como los requisitos o el diseo, antes de seguir adelante. Trate difcil conseguir que completa y estable. Pulir cuidadosamente . o El posterior descubrimiento que obliga a un cambio significativo en los requisitos, modelos, o el diseo que se esforz por conseguir correcta, en primer lugar, es un signo de algn fracaso. La solucin consiste en esforzar se ms o ser ms hbil de uas ms intensamente en el futuro con el fin de obtener los requisitos o el diseo ms cerca de ser completa y correcta . o Es correcto esperar a ser capaz de entregar una estimacin creble y un plan para un nuevo sistema basado en la nueva tecnologa, muy al principio del proyecto. De lo contrario, es un signo de la falta de esqu ll. Muchos de nosotros fuimos enseados incorrectamente que las mencionadas prcticas y actitudes eran hbiles. Sin embargo, no se adopt en el RUP y otros procesos iterativos (como XP). Ellos no son rechazadas por el deseo perverso es contraria o una novela, sino por el reconocimiento de que la solucin no es luchar contra el cambio, pero para abrazarla, y que sea un conductor central en el proceso.
Copyright Valtech Technologies & Rational Software, 2001

5/14

El hecho de que estamos engaados por el enfoque de cascada en el aumento del riesgo de fracaso (en vez de reducirla) va en contra de nuestra educacin y la tradicin antigua de desarrollo de software. Pero no podemos mantene r a los clientes cambien los requisitos, exigindoles que sign-off de las especificaciones ms de lo que podemos alterar las leyes de la fsica. La realidad es que si los requisitos estn equivocados o los cambios en el neg ocio, tenemos que desarrollar el sistema de una manera flexible que nos permite aprender de la experiencia a medida que avanzamos. La superacin de la superposicin consciente o inconsciente de los valores de la cascada en el RUP y el desarrollo iterativo es uno de los mayores desafos que enfrentan un equipo de proyectos. El cambio ms significativo que verdaderamente adoptar el RUP no se encuentra en las habilidades tcnicas, como hacer casos ds los cuales son opcionales), pero en actitud fundamental y ajustes de expectativas relacionadas con el cascada fina ch are optional), but in fundamental attitude and expectation adjustments related to waterfall thinrey.

Las secciones siguientes describen cmo la superposicin de valores cascada y prcticas pueden aplicarse para ayudar a fallar con el RUP.

Superponer Fases Cascada en las fases de RUP

Un ciclo de desarrollo RUP consta de cuatro fases: concepcin, elaboracin, construccin y transicin. La estrategia ms comn para el fracaso RUP es de alguna manera consideran que su definicin lo ms similar a las fases de la cascada. Es decir, 1. Creacin de tareas mayora de los requisitos 2. Elaboracin de tareas el diseo detallado y modelos 3. Construccin de implementar 4. Transicin a la integracin, prueba del sistema, despliegue La descripcin anterior es bastante correcto, pero una mala interpretacin comn, ya sea consciente o inconscientemente-de las fases de RUP. No es difcil encontrar este error de interpretacin en diversos libros, artculos, presentaciones y consultora consejos en el RUP. Una seal de este tipo de error es ver los nombres de las fases convertidos en verbos (Are We Done incepting todava?) O estados de requisitos (se fueron todos los casos d ). Una explicacin detallada de las fases RUP no est dentro del alcance de este artculo, pero es una breve descripcin y ms precisa de las fases: 1. Creacin del fondo-el desarrollo del caso de negocio para el sistema, lo que nos obliga a explorar un conjunto pequeo pero significativo de los requisitos (tal vez 10%) con el fin de obtener un orden de magnitud sentido del alcance, los principales riesgos y decidir si se debe financiar la fase de elaboracin. 2. Elaboracin-iterativamente construir la arquitectura de ncleo y resolver los riesgos tcnicos del proyecto. Cuando hablamos de construir la arquitectura que queremos decir realmente programa, integrar, y prueba de ello, esto no es un documento ejercicio o prototipos desechables. Con el fin de hacer esto, puede tener que explorar iterativamente la mayor parte de los requisitos en detalle (quizs el 80%), mientras que en paralelo la aplicacin d e las partes centrales de riesgo del sistema. Los requisitos pueden cambiar considerablemente a lo largo de esta fase, a travs de los ciclos de adaptacin de retroalimentacin, en respuesta a la evaluacin regular de impleme ntaciones parciales. Ntese que en contraste con los clsicos cascada de estilo definicin de los requisitos, la mayora de los requisitos son refinados en paralelocon el desarrollo de la arquitectura de ncleo, e inform de with developing the core architecture, and informed from the feedback of that real development. We also need to make the decision whether to fund project completion. 3. Construccin-iterativamente construir los elementos no realizados en elaboracin; iterativo integracin y garanta de calidad, preparar para la implementacin. Requisitos cambiar menos en esta fase, ya que la mayora de la in estabilidad requisitos se aclar iterativamente en la fase de elaboracin antes. 4. Transicin completa de pruebas beta, resolver problemas e implementar el sistema. Definicin de Iteraciones demasiado largo o demasiado corto Sabemos de algunas organizaciones de adoptar el RUP, cuando se le pregunt acerca de su duracin prevista iteracin promedio, estn asesorando a seis o incluso doce meses para una iteracin. En la gran mayora de los casos,esto es, sin duda indeseable. Lo ideal sera que una iteracin debera abarcar desde
Copyright Valtech Technologies & Rational Software, 2001

7/14

dos a seis semanas es la regla de oro RUP. La esencia del desarrollo iterativo y el mtodo RUP es tomar pequeos pasos de compromiso de una aplicacin posiblemente imperfecta, rpidamente hacer la integracin, control de calidad y pruebas, obtener informacin rpidame nte, y luego adaptar los requisitos, el diseo y la ejecucin sobre la base de esa informacin. Pasos cortos, comentarios ,

y la adaptacin son las ideas clave. Iteraciones largas perder el punto, y as proporcionar una excelente estrategia para el fracaso con el Rijp . Por otro lado, un proyecto con 300 desarrolladores no se ejecutar sin problemas con iteraciones de dos semanas, debido a la sobrecarga de un gran equipo. Con el fin de lograr un rendimiento suficiente, la longitud de la iter acin tendr que ser tal vez incluso ocho o diez semanas. Tenga en cuenta que un menor, de manera temporal independiente, equipo subsistema podr dividir la iteracin del proyecto a nivel macro de ocho semanas en locales de m .

Pulir los requisitos de diseo antes de

Como se ha mencionado, la idea de que los requisitos se pueden significativamente definida y estable en la ausencia de retroalimentacin va en contra de desarrollo de software (y, de hecho, humano comn) experiencia. Piense e n comprar ropa de la manera en que el mtodo de cascada nos quieren comprar software: tendramos que describir exactamente lo que queremos sin ver lo que estamos recibiendo; ni siquiera pudimos probar la ropa en el primero en ver cmo se ve. Cada medicin tendra que especificarse con precisin, meses o aos antes de la hora actual cuando bamos a recibir la ropa. Que Dios nos ayude si cambiamos de opinin o ganado (o perdido) unas cuantas libr as. Sin embargo, esto es exactamente lo que el mtodo de cascada procede a especificar la mayora de los requisitos antes de hacer el diseo o implementacin. Si ni siquiera iba a comprar ropa de esta manera, lo que nos hace pensar en que funciona el software? La realidad es que estamos atados de incoherencia, una contradiccin constante de las necesidades y deseos, y la eleccin de lo que es correcto es a menudo un complejo equilibrio que nos obliga a probar enfoques diferentes pa ra ver cul funciona mejor. El camino ms rpido a la solucin suele ser uno que genera una serie de enfoques posibles y luego nos permite elegir entre estas alternativas razonables. Un enfoque iterativo permite este tipo de experimentacin dirigida y creatividad, enfoques cascada nos obligan a ser brillante en nuestro primer intento. Es contrario a la naturaleza humana y, ms puntualmente, software proyecto de investigacin .

Esperar Estimaciones crebles y Planes detallados cerca del inicio de un proyecto

Considere este escenario en el negocio del petrleo. Un ejecutivo petrolero que invita a su oficina y le dice: He odo que hay petrleo en FooBarKhan. Lo quiero! Por favor, regrese a su oficina y tomar una semana para escri bir un informe dicindome cunto petrleo est ah, cunto y por cunto tiempo se necesitar para configurar los campos petroleros, los recursos que se necesitan, as como un plan con hitos. En el negocio del petrleo, el escenario anterior sera considerada ridcula. Por qu es aceptable en la industria del software? Personas del petrleo, que trabajan de forma racional, sabemos que tales respuestas no se puede n suministrar sin una importante inversin en la perforacin exploratoria. Slo despus de una investigacin para descubrir la verdad (y originalmente oculta) la naturaleza de los depsitos y la geologa es una estimacin o u . Y, sin embargo, con la incertidumbre y complejidad similares muy alto, esperamos ser capaces de estimar y planificar proyectos de software sin invertir en realista de perforacin exploratoria. Si nunca has hecho algo antes, es difcil decir cunto tiempo tomar. A veces este hecho se utiliza como una razn para rechazar un enfoque iterativo, si usted est haciendo algo muy novedoso que es difcil saber cunto tiemp o tomar. Por temor a lo desconocido, la gente a veces retirarse a la cmoda ilusin de que el mtodo de cascada. Sin embargo, el hecho de que podemos hacer un plan que nos muestra el marchar adelante, completando hitos, eso no significa que realmente podemos hacerlo. Es fcil de poner fechas precisas en un horario en ausencia de informacin real acerca de la cantidad de trabajo por hacer, este es el problema clsico de la planificacin donde el plan se vuelve casi intil, tan pronto como se publique. Si la planificacin perfecta est obligado a entregar un proyecto, entonces
Copyright Valtech Technologies & Rational Software, 2001

9/14

nuestro fracaso est asegurado. El enfoque iterativo permite que aprendamos a medida que avanzamos, como iteraciones proceder tenemos ms informacin acerca de las necesidades reales, una mejor vista de los riesgos reales, y un mejor sentido de nuestras cap acidades para enfrentar los desafos del proyecto. En resumen, la experiencia nos hace mejores planificadores.

A veces, la existencia de un requisito de entrega de precio fijo se utiliza como justificacin para un enfoque en cascada, como si esto justifica la toma de decisiones en ausencia de informacin real. La realidad es que si us ted nunca ha hecho un proyecto de la clase en la que se le pide que entregar una oferta fija, que est dando palos de ciego. Si usted quiere tener xito es mejor que almohadilla sus estimaciones lo ms que puede, contratar ma yor nmero de personas con experiencia en el dominio del problema como sea posible, y esperar lo mejor. La toma de decisiones importantes en la ausencia de informacin es siempre arriesgado. Con un enfoque iterativo, podrs h acer nada mejor en la estimacin inicial, pero pronto lo sabremos qu tan bien est haciendo y usted puede sTarta de negociacin, el establecimiento de las expectativas, y la gestin de alcance mucho antes, cuando en realidadtart negotiating, setting expectations, and managing scope much earlier, when it may actually do some good. Un enfoque racional, propugnada por el RUP, a las ofertas de precio fijo y contratos es una estrategia de dos pasos. En el primer paso, el contrato por un perodo inicial corto (por ejemplo, cuatro semanas) de longitud fija, contrato de precio fijo para hacer investigacin bastante realista y la programacin de exploracin para generar un mbito de aplicacin ms perspicaz, el riesgo y especificacin de requisitos. Esta especificacin mejorada se utiliza a continuacin como base para hacer una oferta en el paso dos (el desarrollo completo). La inversin en el primer paso investigacin no se pierde, el resultado se reduce el esfuerzo para la segunda etapa, y conducir .

Paso 2: Aplicar el RUP como un proceso pesado, Predictive

Algun os metodlogos hablar de procesos que son pesados frente a la luz, o predictivo adaptativo frente. Un proceso pesado es un trmino peyorativo para sugerir una con las cualidades siguientes [9]: o rigidez y contro l o Las actividades y los artefactos se cr ean en un ambiente burocrtico o Los lotes de documentos o elaborada planificacin a largo plazo detallado o sobrecarga importante proceso en la parte superior de la obra esencial o orientado a los procesos en lugar de orientada a las personas, trata a las personas como piezas de acoplamiento activo en un mtodo mecnico o predictivo en lugar de adaptativa Un proceso predictivo es uno que intenta planificar y predecir las actividades y recursos (personas) asignaciones en detalle en un lapso de tiempo relativamente largo, como la mayora del proyecto. Tiende a ser implcitamente cascada en sus valores, haciendo hincapi en la definicin de los requisitos primero y un segundo diseo detallado, antes de la implementacin. Por el contrario, un proceso gil luz o quiere sugerir con las siguientes cualidades clara y directa.: o se le quita una sobrecarga innecesaria proceso burocrtico, eliminando de bajo valor o la creacin de documentos irreflexiva o se centra en la realidad de la naturaleza humana en el contexto del trabajo, burlndose de desarrollo de software, y o Es adaptable . Fomentar el fracaso con el RUP, aplicar estas prcticas pesados, predictivos: o Plan de la totalidad iterativo proyecto en detalle. Desde el principio, definir el nmero y fechas de todas las iteraciones, y especificar lo que ocurrir en cada . o Crear la mayora, o mejor an, de todos los artefactos de las
Copyright Valtech Technologies & Rational Software, 2001

11/14

RUP o Aadir un montn de proyectos y la ceremonia proceso formal, e incluso mejor, los comits de proyectos varios . o Fomentar un mecanicista, la sensacin de relojera en el proyecto, con la gente como dientes especializados en la maquinaria del proyecto . El RUP no se entenda por sus autores para ser pesado o predictivo, y es debido a la superposicin de las ideas de proceso incorrectas o mal entendimiento de las RUP, exacerbada por el gran conjunto de detalladas sobre el pro

documentacin que el producto proporciona RUP, que podra ser tan caracterizado errneamente o mal aplicadas. Los autores de las RUP prevista y fomentar que se aplique en una luz, gil, espritu proceso adaptativo. Algunos ej emplos de cmo se aplica esto: o Un conjunto mnimo de actividades RUP y los artefactos se deben crear, slo aquellos que agregan valor real. A medida que avanza el proyecto, si alguna actividad area proceso no agrega valor, se redujo . o No hay planes detallados para todas las iteraciones. Hay un plan de alto nivel (llamado el plan de eliminacin) que estima la fecha de finalizacin del proyecto y otros hitos importantes, pero no detalla la ruta exacta a es os hitos. Un plan detallado (llamado el plan de iteracin) slo planifica con mayor detalle una iteracin de antemano (por ejemplo, las siguientes dos semanas iteracin). La planificacin detallada se hace de forma adaptativa a partir de una iteracin a otra. Esto no quiere decir que es imposible asignar especulativamente algo de trabajo para futuras versiones, pero para apreciar que se trata de especulacin, que es cada vez menos fiable cuanto m s se proyectan hacia el futuro. Adaptacin del plan original no se ve como un fracaso en la planificacin o ejecucin, pero un ajuste razonable a la realidad del proyecto. Las fechas de los hitos a nivel macro y los objetivo as a failure in planning or execution, but a sensible adjustment to project realities. The macro-level milestone dates and objectives are known, but the path to each milestone is left to adaptively evolve.

Paso 3: Evite Habilidades objeto tecnolgico

El RUP tiene como objetivo desarrollar sistemas orientados a objetos, aunque la mayora de las prcticas son aplicables a otras tecnologas. A travs de los aos que hemos observado (de primera o de segunda mano) de objetos t ecnolgicos (OT) proyectos fracasan o se enfrentan a problemas graves, un hilo comn es no tener gente que es realmente hbil en pensar en los objetos, diseo de objetos, patrones de diseo, y programacin orientada a objetos desarrolladores, ninguna cantidad de proceso va a guardar el proyecto. La presencia de expertos desarrolladores OT es un factor primordial xito crtico, y la adopcin de la RUP (o cualquier otro proceso) es un elemento relat . Como Grady Booch ha dicho: Las personas son ms importantes que los procesos [10]. Del mismo modo, Alistair Cockburn, autor de Surviving Proyectos orientados a objetos, lo expres sucintamente como El proceso es un efecto Por lo tanto, no realmente con el RUP, ignorar tener o educar a las personas con habilidades de objetos profundos. Significativa educacin OT no significa un curso de una semana en Java? tecnologas seguida de un curso de una semana en el anlisis orientado a objetos y el diseo (que es claramente insuficiente para la disciplina amplia y profunda de OT), pero los ingenieros de software con algo as como ocho semanas de intensa dirigida por el pro fesor de educacin, repartidas en seis meses , seguido por doce meses de tutora cerca por un experto. Esto no es un llamado a los gurs de software o genios, sino el reconocimiento de que el desarrollo de habilidades de objetos tecnolgicos son muy no-trivial, y con xito el diseo y la programacin en objetos toma desarrolla dores bien educados y guiados, no novicias. La falta de reconocimiento de la gran inversin necesaria para desarrollar o contratar tcnicos especializados de objetos, o esquinas cortantes de esta inversin con las ilusiones de que podemos llegar a funcionar con menos i ngenieros calificados, es una excelente manera de garantizar el fracaso. Por ltimo, queremos hacer hincapi en la necesidad de una educacin intensiva y la habilidad en el diseo de objetos y patrones de diseo, no slo la programacin de objetos. Para citar a David Parnas [12]:
Copyright Valtech Technologies & Rational Software, 2001

13/14

En lugar de ensear a la gente que OO es un tipo de diseo, y dndoles diseo principios, la gente ha enseado que OO es el uso de una herramienta particular. Podemos escribir programas buenos o malos con cualquier herramienta. A menos que ensear a la gente cmo disear, el lenguaje importa muy poco. El resultado es que la gente hace malos diseos con estos lenguajes y obtener un valor muy poco de ellos.

Paso 4: Adaptacin infravalorar el desarrollo iterativo

Los documentos RUP introducir sus ideas clave y las mejores prcticas: o gestionar los requisitos o Desarrollar iterativamente o Los cambios de control o Verificar la calidad o Arquitectura y comp onent centrada en el diseo o ... Una nueva persona a un proceso iterativo y el RUP lee esta lista sin una idea del impacto relativo de estas ideas, se muestran los elementos ms o menos como tener el mismo peso. Sin embargo, en comparacin con las otras idea s del RUP, el desarrollo iterativo est en una liga propia en trminos de impacto profundo en nuestra forma de pensar acerca de la prctica y desarrollo de software. La lista debe leerse as: o gestionar los requisitos

o Desarrollar iterativamente
o Los cambios de control o Verificar la calidad o Arquitectura y diseo centrado en componentes o . . . Bien entendido, el desarrollo iterativo es como una revolucin, si una organizacin est pasando de valores cascada y prcticas. En efecto, si una organizacin est pasando de las del RUP, y no experimenta una transformacin profunda y traumtica tal vez a muchos niveles en la forma de pensar sobre el desarrollo de software, esto es probablemente una seal de que no pill el desarrollo iterativo y verdaderamente adoptar. Hay varias maneras de hacer caso omiso de las implicaciones de desarrollo iterativo, algunos una reiteracin de la superposicin de las actitudes cascada, y algunos con un nfasis diferente:

Abrazo actitudes rgidas y Predictivo

Es decir, tratar de congelar los requisitos y el diseo, en lugar de aceptar el cambio. Trate de planificar todas las iteraciones futuras, en lugar de ajustar adaptativamente . Cambio de una organizacin o proceso de un equipo es un gran cambio potencialmente perjudicial, potencialmente estimulante, pero siempre desafiante. No hay manera de facilitar en este tipo de cambios, hay que acercarse a ello s directamente y deliberadamente. El cambio est amenazando a algunas personas, y que activamente se resisten incluso cuando es bueno para ellos en el largo plazo. El cambio tambin cambia el equilibrio de fuerzas en un proye cto fuera de la situacin actual y hacia la cosa nueva. Como resultado, el cambio debe ser planeado y orquestado cuidadosamente . El modelo de cascada viene con sus propios retos especiales con respecto a los cambios. Dado que el modelo de cascada evolucion a partir de una respuesta al cambio incontrolado, viene con un sesgo contra el cambio extraordin ario. Hasta cierto punto, el enfoque en cascada todo puede ser visto como gran parte antagnica a cambiar una vez requisitos son aprobado (congelado), se requiere un acto de gran esfuerzo para hacer cambios a la obligacin, incluso cuando se ha comprobado que es incorrecta. Es como si el mtodo de cascada dice bueno, ya de acuerdo en que se trataba de los requisitos, as que es mejor estar callado y simplemente tomar lo que te dan. En la transicin a un ciclo de vida iterativo, el cambio debe ser abrazado a dos niveles: a nivel organizacional y el nivel de proyecto. A nivel organizativo, hay que abrazar el cambio a una nueva forma de hacer las cosas. A nivel de proyecto, se debe permitir la retroalimentacin y el aprendizaje
Copyright Valtech Technologies & Rational Software, 2001

15/14

continuo a decir que es aceptable hacer una respuesta meditada a la nueva informacin.

Pervert la Prctica de Desarrollo Iterativo

Cuando Andy Grove observ, lo que se mide se hace. Si se mide y recompensa para la gente Requisitos de congelacin, diseo de congelacin, y as sucesivamente, usted va a obtener un ciclo de vida cascada no importa lo q ue llaman las fases . Si usted no aceptar el cambio, ests practicando el mtodo de cascada no importa lo que usted dice . Los gerentes de proyecto parece que les gusta la certidumbre superficial del ciclo de vida de cascada, ya que tiene la aparente estabilidad y certeza: es posible decir El problema es que este tipo de declaraciones es delirant e es diciembre el segundo y hemos terminado de analizar todos los requisitos. -Ests diciendo solamente que haya terminado, pero usted sabe en algn nivel que esto no es cierto, ya que no se ha implementado todava, no hay forma real de estar seguro de que usted est realmente hecho. Es slo por probar que sus suposiciones acerca de que algo es verdadero o falso puede ser evaluado, es slo mediante la aplicacin de algo que usted sabe la cantid . En un proyecto, todos estamos jugando a un juego, hacemos suposiciones, tenemos presentimientos acerca de cmo sern las cosas y lo que la solucin debe ser similar, y pretendemos que estamos seguros de lo que estamos diciend o. Pero la verdad es que realmente no sabemos mucho de cierto, estamos mintiendo mucho y esperando lo mejor. Estamos actuando en informacin imperfecta, y los resultados muestran que a menudo . El director del proyecto sabio toma esto en cuenta, la construccin de puestos de control en los supuestos en que se pueden validar y realizacin de actividades para reunir ms informacin. El enfoque iterativo es perfecto para esto: permite que la informacin a ser recogida, mientras que todava se puede utilizar para mejorar nuestros planes y cambiar de direccin. Hay un dicho que ningn plan sobrevive al contacto con el enemigo intacto. El a dministrador sabio proyecto comprende esto y se basa en las oportunidades para ajustar los planes basndose en la nueva informacin. Probablemente el mayor fracaso del enfoque de cascada como popularmente se practica es que los planes se hacen en forma aislada de la realidad y luego no se debe actualizar la nueva informacin se recopila. Cambiar el plan sec onsidera un fracaso para prever el futuro. Pero nadie puede predecir el futuro, y ajustar el plan no es tanto una falla en las predicciones, ya que es una oportunidad para mejorar .

No educar a los interesados en las implicaciones del desarrollo iterativo

Los clientes y la gestin se han convertido en aculturados con el enfoque de cascada. Los clientes han llegado a esperar que puedan entregar los requisitos y se lavan las manos del proyecto hasta el producto terminado se entr. La direccin ha sido condicionados que deben ser capaces de esperar que los planes perfectos pueden formularse en el da 1 de un proyecto y luego ejecutado slo, y que las estimaciones confiables se puede generar con una inve stigacin mnima y prcticamente sin necesidad de programacin significativa exploratorio o prueba de conceptos. Si un proyecto fracasa, ellos piensan, no es porque el plan era malo, sino porque no se ha seguido, o porque los planificadores no hbiles o de estimadores. Este tipo de pensamiento es la misma clase de cosa que le da mala fama a la gestin . Para que el desarrollo iterativo al trabajo, el cliente debe participar. El corazn y el alma de desarrollo iterativo es la adaptacin basada en la retroalimentacin, en lugar de la especulacin. Si el cliente no est interes ado y participa activamente en asegurarse de que el sistema que ellos quieren y necesitan que se construye, entonces van a obtener exactamente lo que se merecen. Lo ms difcil de la construccin de software es la construcci n de lo correcto, encontrar las funciones y slidos usabilidad. Los desarrolladores son rara vez los expertos de dominio y necesitan ayuda para entender lo que se necesita para resolver el problema. Necesitan ayuda para construir el sistema correcto. El enfoque de cascada roba el equipo de la interaccin
Copyright Valtech Technologies & Rational Software, 2001

10/14

significativa entre el equipo de desarrollo y el cliente. Los clientes tienen que ser reeducados darse cuenta de que tienen que tomar un papel activo en la definicin de lo que debe ser desarrollado, y tienen que llegar a entender que hay una interaccin entre lo que un

sistema debe hacer y la inspiracin de las nuevas tecnologas. Tal vez se pregunte por algn tipo de sistema tradicional, sin darse cuenta de las posibilidades que los dispositivos inalmbricos y mviles en red podra traer a la visin. Lo que pasa es que la tecnologa cambia la naturaleza del problema. El Internet es un gran ejemplo de esto: nos permite abordar los problemas de nuevas maneras que no siempre son evidentes para las personas queestn inmersos en un proceso empresarial existente. El mtodo ideal es aquella en la que podemos empezar con una comprensin del problema que hay que resolver y explorar ese problema (sus retos y oportunidades) de manera evolutiva, en una asociacin entre los desarrolladores y los usuarios / clientes. Un enfoque iterativo permite el tipo de respuesta adaptativa que es esencial para este estilo de desarrollo.

El exceso de modelo y crear muchos artefactos de bajo valor

El Proceso Racional Unificado es un marco que resuelve muchos problemas diferentes. No es probable, sin embargo, que se encontrar con todos estos problemas. En consecuencia, es poco probable (e incluso deseable) que utilizar a todo el proceso unificado en su proyecto. Adems, la idea de desarrollo iterativo es para iniciar rpidamente la programacin, cuando slo parcial requisitos y diseos son desarrollados, con el fin de obtener informacin realista, en lugar de especular sobre los requ . Por lo tanto, un medio hbil para RUP fallecimiento e iterativo fracaso es crear todos los artefactos RUP, y tratar detalladamente, y con gran especificidad, detalle cada uno. Dibuja por lo menos veinte pginas de diagramas U ML antes de programar. El RUP es como un botiqun o una farmacia. La mayora de nosotros no se le ocurrira entrar en una farmacia, comprar uno de cada tipo de medicamento y despus de tomar estos medicamentos. Sabemos que nosotros se enferma (o ta l vez algo peor), hemos aprendido que slo debemos tomar lo que necesitamos, y luego a veces slo bajo el asesoramiento de un experto . Algunas personas sugieren que el RUP es demasiado grande, lo cual es como decir que hay demasiados medicamentos. Existen muchos medicamentos que no tienen que mucha gente necesita, aunque la mayora de las personas no necesit an medicamentos muy numerosos en absoluto (tal vez slo tenemos unos cuantos dolores y molestias de vez en cuando). El verdadero problema es que la gente necesita entender mejor la forma de saber lo que necesitan . Una buena manera de ver cmo gran parte de la RUP se debe utilizar es el uso de la mitigacin del riesgo como gua. o Existe el riesgo de que los desarrolladores no pueden entender lo que el sistema debe hacer? Es posible que desee utilizar un poco de gestin de requisitos. o Hay algn comportamiento que tiene un flujo de control complejo o difcil de entender? Es posible que desee utilizar casos de uso. o Es la solucin tcnica al nuevo sistema y complejo? Es posible que necesite arquitectura. Usted comenzar a ver cmo decidir qu elegir. Comprender los problemas que enfrenta, y luego elegir tcnicas (medicamentos) que le ayudarn a reducir estos problemas .

Paso 5: Evite mentores que entienden el desarrollo iterativo

No hay nada como la inexperiencia, la incomprensin y la ignorancia para ayudar a una nueva prctica realmente no espectacular. Por lo tanto, en su primer proyecto RUP iterativos, utilice nicamente un equipo que nunca ha hecho corto timeboxed adaptativa desarrollo iterativo antes-especialmente los responsables del proyecto. Busque personas casadas con cascada actitudes y prcticas. Como acotacin al margen, tambin es til
Copyright Valtech Technologies & Rational Software, 2001

11/14

para elegir un arquite cto para su primer proyecto de tecnologa Java que no es un experto en Java y no se puede hacer la programacin Java. Definitivamente evitar el contagio con un mentor que sabe hacer el desarrollo iterativo. Si un mentor experto desafortunadamente se une al proyecto, asegurarse de que tienen un papel sin influencia o liderazgo, y que sus cons ejos se debate, vistos con escepticismo, y finalmente rechazado por el proyecto

liderazgo. Ridiculizar el mentor. Si un mentor debe formar parte del equipo, busque uno que no entiende el RUP y sutilmente superpone actitudes cascada de prediccin, como pensar que la fase de elaboracin es clarificar los modelos que se aplican en la construccin, o que el trabajo para todas las iteraciones deben planearse y asigna cerca del comienzo del proyecto. Deben ser fciles de encontrar .

Paso 6: Adoptar el RUP en un Big Bang

Si es posible, presente el RUP para toda la organizacin de TI de un lunes, y exigir todos los proyectos que hacerlo antes del martes, pero no se lo digas a nadie los detalles. Si eso no es posible, y la educacin se ve obligado a la organizacin, educar slo a los desarrolladores (en lugar de los directivos o de los ejecutivos de TI). Es especialmente divertido si la administracin tiene actitudes cascada y expectativas, y el equipo de desarrollo se enseaba en lugar de dejar los hbitos waterfal. Si todo el mundo debe ser educado en un curso RUP, trate de hacerlo por lo menos con un retraso de seis meses antes de la adopcin RUP, por lo que ser completamente olvid ado, y lo convierten en uno de esos breves seminarios de un da de una RUP educador que superpone las ideas cascada. Si elAdopcin RUP debe aplicarse inmediatamente despus de la educacin, por lo menos que lo haga por toda iloto con un mentor experto usando un simple conjunto mnimo de prcticas de RUP, aprendiendo de la experiencia, de forma incremental que adoptar y mov mple minimal set of RUP practices, learning from the experience, incrementally adopting it, and movING a un segundo proyecto con la experiencia de la primera. Si alguien sugiere que las idea del fuego. A toda costa, no explican ni solicitar razones para adoptar el RUP-que racionalmente puede justificar el gasto y aliviar la incomodidad del cambio. Identificar las RUP / iterativo escpticos y los defensores cascada, y los puso a cargo del proyecto de adopcin .

Paso 7: Tome el consejo de Fuentes informados mal

Incluso entre los llamados expertos que hacen libros, artculos, enseanza, o discursos en el RUP, hay algunos que no tiene que conseguir el desarrollo iterativo y su rechazo fundamental de los valores de la cascada y las p rcticas de prediccin. El RUP informacin que presentan no es correcto, y por lo general oculta una mentalidad cascada subyacente. No tome nuestra palabra para ella. Estudiar los documentos originales RUP profunda y comple tamente, entender los verdaderos valores de desarrollo iterativo, y luego comparar por ti mismo. Recientemente hemos visto la desinformacin que pretende explicar el RUP, al menos en las siguientes fuentes: o Un libro sobre la gestin de proyectos orientada a objetos o Un libro sobre Java? Programacin en el servidor o Una charla en una conferencia de UML El signo tpico de la desinformacin es generalmente una cierta variacin de describir las cuatro fases siguientes: 1. 2. 3. 4. Creacin de tareas mayora de los requisitos Elaboracin de tareas el diseo detallado y modelos Construccin de implementar, traducir los modelos a cdigo Transicin a la integracin, control de calidad, la implementacin

Tambin hemos observado los llamados expertos RUP hacer declaraciones incorrectas, tales como:
Copyright Valtech Technologies & Rational Software, 2001

12/14

o En el RUP es importante para obtener el 100% de los requisitos definidos antes de iniciar el diseo. o Una buena longitud, tpico en la iteracin RUP debe estar alrededor de 6 meses. Para aumentar sus posibilidades de fallar con el RUP, le recomendamos que aceptar lo que lee o escucha acerca de la RUP sin discriminacin. Hay fuentes actualmente muchos que pueden ayudar a desinformar usted.

Usted sabe que usted no entendi las RUP Cuando...

Con el fin de garantizar la absoluta incomprensin y el fracaso en la adopcin RUP, le ofrecemos la siguiente lista de comprobacin o acta del encuentro. Por supuesto, ms puntos anot, ms xito del fracaso RUP . Usted sabe que no entenda el RUP cuando ... o Usted cree que su constitucin = requisitos, elaboracin = diseo, construccin y puesta en prctica = . o Usted cree que el propsito de elaboracin es definir con suma atencin los modelos, que se traducen a cdigo durante la construccin . o Crees que los prototipos se crean slo en elaboracin. En realidad, el ncleo de calidad de produccin de los elementos arquitectnicos de riesgo deben ser programados en la elaboracin . o Usted tratar de definir la mayor parte de los requisitos antes de iniciar el diseo o implementacin. Oh, ustedes tratan de definir la mayor parte del diseo antes de comenzar la ejecucin . o Un tiempo se dedica a hacer requerimientos o trabajos de diseo antes de la programacin se inicia . o Una organizacin considera que una longitud adecuada iteracin se mide en meses, en lugar de semanas . o Crees que la fase de pre-programacin de diagramas UML y las actividades de diseo es un tiempo para definir completamente y con precisin diseos y modelos con gran detalle, y de la programacin como una simple traslacin mecnica de estos en cdigo. o Usted tratar de planificar un proyecto en detalle desde el principio hasta el final, la distribucin del trabajo a cada iteracin, intenta especulativo predecir todas las iteraciones, y lo que va a pasar en cada uno . o Una organizacin quiere planes crebles y estimaciones para los proyectos antes de que hayan entrado en la fase de elaboracin . o Una organizacin considera que la adopcin de las RUP medios para hacer muchas de las posibles actividades y crear muchos documentos, y piensa o siente el RUP como un proceso formal con muchos pasos que se deben seguir .

Conclusin
Estamos seguros de que al seguir estos siete pasos, y aplicar la lista de verificacin de malentendidos, su adopcin del RUP y el desarrollo iterativo ser un lo espectacular .

Referencias
1. Kruchten, Philippe. El Proceso Racional Unificado-An Introduction, 2 ed. Reading, MA: AddisonWesley (2000). 2. Jacobson, I., Booch, G. y Rumbaugh, J. El Proceso Unificado de Desarrollo de Software. Reading, MA: Addison-Wesley .(1999)
Copyright Valtech Technologies & Rational Software, 2001

11/14

3. Royce, Walker. Software de Gestin de Proyectos, un marco unificado. Reading, MA: Addison Wesley (2000) 4. Johnson, Jim. Caos: Trazando los mares de Tecnologa de la Informacin. Publicado Informe. The Standish Group (fecha? ) 5. Druffel, Larry y Heilmeyer, George. Informe del Grupo de Trabajo de Ciencia de Defensa Consejo de Defensa de la adquisicin de software comercial. (EE.UU. Departamento de Defensa ) 6. Jones, Caper. Applied Measurement Software. Nueva York, Nueva York: McGraw-Hill.

Copyright Valtech Technologies & Rational Software, 2001

12/14

7. Boehm, B. y Papaccio, P. La comprensin y el control de costes de software, en IEEE Transactions on Engineering Software. Octubre 1988. 8. Beck, K. Extreme Programming Explained-Embrace Change. Reading, MA: Addison Wesley (2000) 9. .

Fowler, Martin Ponga su proceso en una dieta, en Desarrollo de Software. Diciembre 2000. CMP Media.

10. Booch, G. Soluciones del objeto: Gestin del Proyecto orientado a objetos. Reading, MA: Addison Wesley .(1996)

Copyright Valtech Technologies & Rational Software, 2001

13/14