Caso prctico.

Seleccin de un modelo de ciclo de vida para Giga-Quote

Ejemplo 7.1

Los representantes de Giga-Safe estaban solicitando una actualizacin de Giga-Quote

1.0, tanto para corregir defectos como para solucionar fallos molestos en la interfaz de
usuario. Bill ha sido reelegido como jefe del proyecto Giga-Quote 1.11, despus de haber
sido destituido al final de GigaQuote 1.0, y se puso en contacto con Rafael para pedirle
consejo. Rafael es un consultor muy valorado que haba conocido en un bar.
Esto es lo que debes hacer, dijo Rafael. Tuviste muchos problemas de
planificacin la ltima vez, y por eso, esta vez necesitas organizar el proyecto para alcanzar
la mxima velocidad de desarrollo. El prototipo es el enfoque ms rpido, y por eso tu
equipo debe utilizarlo. Bill crey que era una buena idea, y por tanto, cuando se reuni
con el equipo ms tarde, les comunic que utilizaran el la tcnica de desarrollar un prototipo.
Miguel era el responsable tcnico del proyecto, y se sorprendi. Bill, no estoy de
acuerdo contigo, le dijo. Tenemos seis semanas para solucionar un montn de problemas
y realizar pequeas modificaciones en la interfaz de usuario. Para qu quieres utilizar la
tcnica del prototipo? Necesitamos un prototipo para acelerar el proyecto, contest Bill
malhumorado. El tcnica de construir un prototipo es el enfoque ms rpido y
novedoso, y esto es lo que quiero utilizar. Hay algn problema?
Mal asunto, pens Miguel De acuerdo, dijo, desarrollaremos un prototipo, si eso es
lo que quieres.
Miguel y una programadora, Sue, comenzaron a trabajar en el prototipo. Como era
casi idntico a su sistema actual, slo tardaron unos cuantos das en preparar el sistema
completo.
Al comienzo de la segunda semana, mostraron el prototipo al director de los
representantes, A. J. Maldicin, no puedo decirles a mis representantes que esto es todo
lo que vamos a tener!, exclam A. J. Esto hace poco ms de lo que realiza el programa
actual! Mis representantes no paran de decir que necesitan algo mejor. Tengo algunas
ideas para los nuevos informes. Os las mostrar. Miguel y Sue escucharon atentamente,
y despus de la reunin Miguel se reuni con Bill.
Le mostraremos el prototipo a A. J. Quiere aadir unos informes nuevos, y no acepta
un no por respuesta. Sin embargo, estamos totalmente ocupados con el trabajo que se
supone que tenemos que realizar ahora. No hay problema, coment Bill. l es el
director de los representantes y si dice que necesitan nuevos informes, es que necesitan
nuevos informes. Tenemos que encontrar la forma de tenerlos hechos a tiempo.
Lo intentar, le dijo Miguel. Pero tengo que decirte que solamente tenemos un 1
por 100 de posibilidades de terminar a tiempo si incluimos estos informes.
Bien, tienes que hacerlo, le coment Bill. Quizs el trabajo se puede realizar ms
rpido de lo que esperas, ahora que ests utilizando la tcnica del prototipo.
Dos das ms tarde, A. J. se detuvo en el despacho de Miguel. Le he echado un vistazo
al prototipo, y creo que necesitamos redisear tambin algunas de las pantallas de entrada.
Ayer les mostr a algunos de mis representantes el prototipo en nuestra reunin regional
de cada mes. Me comentaron que te llamaran para proporcionarte algunas ideas

adicionales. Les di tu nmero de telfono; espero que no te importe. Contina haciendo

un buen trabajo!
Gracias, le dijo Miguel escurrindose en su silla. Ms tarde, Miguel le pregunto a
Bill si iba a tratar de hablar con A. J. de las modificaciones, pero Bill le contest: No.
Al da siguiente, Miguel recibi dos llamadas de los representantes que haban asistido
a la reunin regional. Ambos queran realizar ms modificaciones en el sistema. Durante
las dos semanas siguientes, recibi llamadas todos los das, acumulndose la lista de
modificaciones.
En la cuarta semana de las seis que tiene el proyecto, Miguel y Sue estimaron que se
necesitaban seis meses para las modificaciones que tenan pensado tener en dos semanas.
Miguel se reuni con Bill de nuevo. Estoy decepcionado contigo, le coment Bill. Me
he comprometido con los representantes a que haras las modificaciones que te
propusieron. No le ests dando ninguna oportunidad al prototipo. Espera un poco y vers
como funciona.
Ya veo cmo funciona, pens Miguel. Y me van a echar. Pero Bill segua firme.
En la octava semana, Bill comenz a quejarse de que Miguel y Sue no estaban
trabajando lo suficiente. En la dcima semana, Bill comenz a pasar por sus despachos
dos veces al da para comprobar sus progresos. Al llegar la duodcima semana, los
representantes estaban quejndose, y Bill coment: Tenemos que presentar algo.
Entregar justo lo que tengis ahora. Como no se haban finalizado los nuevos informes
ni las pantallas de entrada, Miguel y Sue simplemente finalizaron el cdigo del desarrollo
Y entregaron una versin que consista principalmente en resolver y corregir fallos
molestos en la interfaz de usuario, en trminos generales, lo que haban planificado
desarrollar y entregar en primer lugar, pero necesitaron 12 semanas en lugar de 6.

Ejemplo 7.2.

Eduardo se ofreci voluntario para supervisar el desarrollo de un nuevo cdigo del

producto de Square-Tech, denominado Cube-It, un paquete grfico cientfico. Ernesto,
el consejero delegado, saba que Square-Calc les haba proporcionado la llave que
podran utilizar para convertirse en uno de los lderes en el campo de los paquetes
grficos cientficos.
Eduardo se reuni con los programadores Jorge y Julia para planificar el proyecto. Se
trata de un rea nueva para nosotros; por tanto, quiero minimizar el riesgo de la compaa
en este proyecto. Ernesto me coment que quera la especificacin preliminar del producto
terminada en un ao. No s si ser posible, por lo tanto quiero que se utilice un modelo de
ciclo de vida en espiral. Para la primera iteracin del modelo, necesitamos saber si la
especificacin preliminar es pura fantasa o podemos hacerla realidad.
Jorge y Julia trabajaron durante dos semanas y se reunieron con Eduardo para evaluar
las alternativas que haban identificado. Aqu est lo que hemos encontrado. Si el objetivo
del proyecto es construir el paquete grfico cientfico lder del mercado, existen dos
alternativas bsicas: ganar la competicin por las prestaciones o o ganarla por la facilidad
de uso. Ahora parece mejor alternativa la facilidad de uso.
Analizamos los riesgos para cada alternativa. Si seleccionamos la alternativa de todas
las prestaciones, necesitaremos un mnimo de 200 meses de trabajo del equipo para
desarrollar un producto lder del mercado. Tenemos la restriccin de disponer de un
mximo de un ao para crear un producto y un equipo mximo de ocho personas. No
podemos desarrollar el producto con todas las prestaciones con estas restricciones. S
seleccionamos la alternativa de la facilidad de uso, necesitaremos ms o menos 75 meses

de plantilla, Esto se ajusta ms a nuestras restricciones, y tendremos ms facilidad para

acceder al mercado.
Buen trabajo, coment Eduardo. Creo que a Ernesto le gustar. Eduardo se reuni
con Ernesto ms tarde ese mismo da, y estos se reunieron con Jorge y Julia a la maana
siguiente.
Ernesto seal que necesitamos formar algunos expertos en facilidad de uso, l crea
que era una buena estrategia desarrollar un producto cuya principal caracterstica fuera su
facilidad de uso, y por eso hizo el gesto con el pulgar hacia arriba que todo iba bien.
Ahora necesitamos planificar la siguiente iteracin de la espiral. Nuestro objetivo para
esta iteracin es refinar la especificacin del producto de forma que se minimice nuestro
tiempo de desarroll y se maximice la facilidad de uso,
Jorge y Julia tardaron cuatro semanas en llevar a cabo la iteracin, y posteriormente se
reunieron con Eduardo para revisar sus resultados. Hemos creado una lista de
requerimientos preliminares, inform Jorge. La lista est ordenada por la facilidad de
uso y a continuacin por el tiempo de desarrollo estimado. Hemos realizado la estimacin
para el mejor caso y el peor caso para cada una de las prestaciones. Puedes ver que existe
una gran variacin, y mucha de esta variacin tiene que ver con la forma en la que
definimos las especificaciones de cada prestacin. En otras palabras, tenemos controlado
muy bien el tiempo que se tarda en desarrollar el producto.
Tener la mxima facilidad de uso como objetivo claro y primordial permite realmente
que las decisiones sean fciles para nosotros. Muchas de las prestaciones que ms tiempo
de programacin consumen tambin podran ser las ms difciles de usar. Recomiendo la
eliminacin de algunas, debido a que ser lo mejor para la planificacin y el producto.
Esto es interesante, respondi Eduardo, Qu alternativas de alto nivel habis
encontrado?
Recomendamos cualquiera de las dos posibilidades, dijo Julia. Hemos conseguido
la versin "segura", que hace mucho hincapi en la utilidad, pero usa tecnologa probada.
Y hemos conseguido la versin "arriesgada", que mejora con los avances punteros la
facilidad de uso. Cualquiera de las dos debera ser la ms fcil de usar del mercado, La
versin arriesgada hara ms difcil que nos alcanzara la competencia sin embargo
supondra alrededor de 60 meses de trabajo, en comparacin con los 40 de la versin
segura. No es mucha la diferencia, pero en el peor de los casos la versin arriesgada
supone 120 meses, comparados con los 55 de la versin segura.
Vaya!,dijo Eduardo. Se trata de una buena informacin. Es posible construir la
versin segura excepto el diseo previo de forma que podamos presentar la tecnologa
punta en la versin 2?
Me alegra que preguntes esto, coment Julia. Estimamos que la versin segura con
el diseo previo para la versin 2 supondra unos 45 meses-persona de trabajo, con un
peor caso de 60.
Esto est claro, verdad?, dijo Eduardo. Nos quedan 10 meses y medio, y por esto
vamos a llevar a cabo la versin segura con el diseo previo para la versin 2. Mientras
vosotros estabais centrados en todos los riesgos de la planificacin tcnica, yo me he
centrado en los riesgos de la planificacin del personal, y he conseguido tres
programadores preparados. Ahora, los aadiremos al equipo y comenzaremos la siguiente
iteracin.
Jorge, t mencionaste que muchas de las modificaciones en la planificacin estn
relacionadas fundamentalmente con la forma de definir cada prestacin, verdad? Para la
siguiente iteracin de la espiral, necesitamos centrarnos en minimizar los riesgos de
nuestro diseo y programacin, y esto supone definir la mayora de las prestaciones para
que consuman el menor tiempo de programacin posible mientras se mantiene constante

nuestro objetivo de facilidad de uso. Tambin quiero que los nuevos programadores
revisen vuestras estimaciones para reducir el riesgo de cualquier error de estimacin.
Jorge y Julia estuvieron de acuerdo.
La siguiente iteracin, centrada en el diseo, tard 3 meses, con lo cual el proyecto se
situ en la marca de los 4 meses y medio. Sus revisiones les haban convencido de que su
diseo era firme, incluyendo el diseo previo para la versin 2. El trabajo de diseo les
haba permitido refinar sus estimaciones, y calcularon que el desarrollo restante
necesitara 30 meses-persona, siendo en el peor caso 40 meses. Eduardo pens que se
trataba de algo excepcional, puesto que en el peor de los casos entregaran el software
slo con un retraso de 2 semanas.
Al comienzo de la iteracin de codificacin, los programadores identificaron como
riesgos principales un cdigo de baja calidad y una mala visibilidad del estado. Para
minimizar esos riesgos, llevaron a cabo revisiones para detectar y corregir errores en la
codificacin, y utilizaron hitos para ofrecer una excelente visibilidad del estado.
Sus estimaciones no haban sido perfectas, y la iteracin final dur 2 semanas ms de
lo esperado. Entregaron la primera versin candidata a probar del sistema a los 11 meses
en lugar de los 10 meses y medio estimados. Sin embargo, la calidad del producto era
excelente, y slo quedaron dos candidatos para elegir un ganador, Cube-It 1.0 fue
entregado a tiempo.