1. INFORME DEL CASO DE
ESTUDIO: GIGA-QUOTE
Adrián Sánchez
Vicent Baixauli
Noemí Grau
2. Caso de estudio: GIGA-QUOTE
INTRODUCCIÓN
Análisis de los errores de desarrollo del proyecto de Giga-Quote:
Vamos a tratar de hacer un breve informe acerca de lo ocurrido en el siguiente caso,
aquellos errores clásicos que se cometieron, y también aquellos que sucedieron durante su
desarrollo, vamos a analizar éstos y muchos otros y posteriormente, intentaremos ver de qué
manera se podía haber llevado a cabo este proyecto de desarrollo de una forma más adecua-
da, como prevenir esos errores clásicos y también como solventarlos, así pues, enumeraremos
una metodología a seguir y unas pautas de desarrollo correctas.
¿Qué errores clásicos se han cometido? ¿Cómo hubierais ac-
tuado en esa situación? ¿Por qué?
Se han cometido bastantes errores clásicos en la forma de abordar este proyecto.
Si nos referimos a errores que atañen a las personas, hemos podido encontrar los si-
guientes:
1. Expectativas poco realistas e ilusión en el hecho de que el trabajador que realiza la
propuesta de la aplicación para los comerciales de la empresa, no tiene la suficiente
experiencia en la dirección y coordinación de proyectos por lo que divide las activida-
des de forma poco práctica.
2. En este supuesto ha aparecido la figura del empleado problemático; el que tiene ro-
ces con los compañeros por culpa del carácter o bien por las excesivas horas de tra-
bajo.
3. Personal poco motivado o “deprimido” como aparece en el texto.
4. Hay un momento en la elaboración del software en la que los implicados no partici-
pan demasiado en él, ya que en la etapa en la que deben entregar el código parece
que faltan datos en los informes finales que devuelve la aplicación y no se interesan
demasiado.
5. Personal mediocre, en el momento en el que tienen que comenzar desde cero a pre-
pararlo todo, deben formar a lo programadores.
6. Añaden más personal al proyecto a mitad del mismo, como cuando contratan a un
asesor en ingeniería informática; al igual que no aparece la figura de un promotor
efectivo del proyecto, cuando comienza a preparar el proyecto no tiene apoyo de un
analista.
Página 2 de 6 Adrián Sánchez
Vicente Baixauli
Noemí Grau
3. Caso de estudio: GIGA-QUOTE
En el caso de errores sobre procesos:
1. Aparece un error no definido en la clasificación en la que nos estábamos basando,
que hace referencia a que en este caso, la empresa se reunió para tratar el tema de
la realización del proyecto sin contar con la presencia de la persona que lo había
propuesto, con lo que no existe un intercambio de opiniones con la persona que tiene
los conocimientos informáticos para desarrollarlo. Y, entonces, no pueden resolverse
ciertas dudas que surjan a los directivos sobre el por qué de ciertas tareas a realizar,
o tiempo a invertir, etc.
2. Se produce el efecto de planificación excesivamente optimista, e insuficiente, va liga-
da a no tener un analista encargado de guiar el proyecto.
3. La gestión de riesgos es insuficiente y se escatima en las actividades iniciales, se
realiza una estimación del tiempo que llevará la realización del proyecto, las líneas
de código que contendrá, sin cálculos verdaderos, sólo con estimaciones.
4. Se omitieron tareas necesarias en la estimación y se cayó en el error de ponerse a
programar a destajo.
5. Se escatimó en las tareas de control de calidad y en el momento de poner a prueba
el programa, aparecieron numerosos errores.
6. En varias ocasiones se plantean ponerse al día más adelante y se dan cuenta de que
el diseño que se eligió no es el adecuado, al ver que no llegan a tiempo a cumplir los
plazos de entrega, se dedican a programar casi sin descanso para poder llegar a
tiempo y recuperar lo perdido.
Sobre errores relacionados con el producto:
1. Podemos darnos cuenta de que se producen cambios en las prestaciones que tendrá
finalmente la aplicación por voluntad del departamento de comerciales, con lo que se
produce un exceso de requerimientos que afectarán a la planificación del proyecto en
sí.
2. En una ocasión uno de los desarrolladores se plantea hacer uso de una nueva tecno-
logía de la cual no tiene muchos conocimientos; se produce el efecto de estar reali-
zando un desarrollo orientado a la investigación.
3. Hay un momento de tiras y aflojas en la negociación durante el momento de tensión
que se produce con los informes de errores por parte del departamento de cali-
dad/pruebas. A raíz de esto aparece la figura del programador meticuloso que cree
que lo que le están reprochando no es tan serio como lo plantea la compañera que le
ha redactado el informe en contra.
Página 3 de 6 Adrián Sánchez
Vicente Baixauli
Noemí Grau
4. Caso de estudio: GIGA-QUOTE
Por último, errores relacionados con la tecnología:
1. Se han sobreestimado las ventajas de utilizar una tecnología como pueda ser realizar
el proyecto en C++ orientado a objetos; no por el echo de que sea una mala elección,
sino más bien porque plantea utilizar un programa que no sabemos si el resto del
equipo lo maneja con soltura o sí.
2. Podría decirse que también aparece el síndrome de la panacea ya que aunque so-
breestiman el hecho de codificar con C++ orientado a objetos, parece que creen que
con el uso de esta herramienta ya está todo resuelto.
Nosotros en este caso lo primero que habríamos hecho es consultar a un analista para
que nos diera las pautas necesarias para afrontar el desarrollo de la aplicación.
A continuación deberíamos hacer una reunión con el equipo de trabajo en la que se ex-
plicaría el reparto de tareas, los conocimientos que serán necesarios tener, y, en definitiva de
qué se va a encargar cada uno de los componentes del proyecto.
Se elegiría el diseño que va a tener el proyecto junto con el departamento al que va diri-
gido para que nos explique cómo va a querer ver la información una vez esté acabada la apli-
cación.
Se realizarán los cálculos que sean necesarios para estimar de la forma más “realista”
posible la cantidad de personas que harían falta para terminar, los requisitos de los equipos,
etc.; con el fin de averiguar el tiempo que puede costar realizar la aplicación y así, poder plani-
ficar en qué momento aproximadamente se pueden ir realizando pruebas para comprobar el
resultado del programa así como su calidad.
Por supuesto el equipo de trabajo tendría que estar compuesto por personas resueltas en
el tipo de programación que vaya a llevarse a cabo, de este modo, evitaremos tener que espe-
rar a que estén formadas o que tengan que ponerse al día en el lenguaje porque hace tiempo
que no lo usan; por ejemplo.
Se trabajará con controles automáticos del código fuente, con el fin de que si se produ-
cen cambios, pueda encontrarse más rápidamente, el módulo que contenga la codificación a
implementar; de este modo, evitaremos que haya desorden y seremos más eficaces.
Trataremos de que se hagan las pruebas que sean necesarias y que los comerciales (en
este caso), usen la herramienta para que nos digan si persiguen las expectativas que se per-
seguían.
Si todo va bien; entregaremos el producto en fecha y forma como se había previsto de
antemano.
Página 4 de 6 Adrián Sánchez
Vicente Baixauli
Noemí Grau
5. Caso de estudio: GIGA-QUOTE
¿Qué metodología de desarrollo sería la más conveniente para
este proyecto? ¿Por qué?
Pensamos que por el tamaño de la aplicación deseada hubiese sido más correcto
haberse basado en una metodología en espiral, tal vez híbrida entre una XP, ya que hubiese
sido necesario hacer una correcta evaluación de riesgos y como no, muy importante una eva-
luación por fases, de forma que el cliente podría advertir a los desarrolladores de aquellos erro-
res que tenían que ser corregidos, tanto en un primer prototipo del diseño como en cada una
de las funciones que debían ser implementadas mucho antes que dejarlas todos al mogollón o
lo que es lo mismo; evitar la famosa bola de nieve que se nos viene al final, al haber un único
prototipo que no ha sido correctamente testado y que nos puede llevar a rehacer casi comple-
tamente nuestro proyecto y que con ello nos asegura retrasos muy importantes.
Con los errores detectados previamente vamos a analizar detalladamente cómo hubié-
semos podido evitar la mayoría de los errores:
– Tener una constancia de cual va ser el diseño deseado para nuestro producto.
– Evitar a toda costa los conflictos internos entre los desarrolladores.
– Hacer pruebas conjuntas y por parejas.
– Realizar un correcto análisis y presentar un prototipo del diseño al cliente.
– Desarrollar por fases.
– Evitar hacer experimentos en medio del desarrollo.
– No acumular estrés en el equipo de trabajo.
Análisis En Profundidad:
-Realizar un diseño prototipo con un primer análisis de riesgos, posteriormente consul-
tar con el cliente.
-Una vez resueltos los problemas de Diseño, dividir el desarrollo por etapas pequeñas
de forma funcional, y una vez terminada una función determinante corregirla y pasar a la
siguiente.
-Preparar cada X etapas un nuevo prototipo y comprobar junto al cliente el funciona-
miento de las funciones antes de pasar a la siguiente.
-No probar a hacer trampas ni trucos que puedan llevar a más complicaciones posterio-
res, regirse por unos requisitos y llevarlos hasta su finalización el en menor tiempo posible.
Página 5 de 6 Adrián Sánchez
Vicente Baixauli
Noemí Grau
6. Caso de estudio: GIGA-QUOTE
Evaluación global de la gestión del proyecto.
En definitiva, la aplicación que se tenía que presentar en un tiempo concreto sufrió va-
rios retrasos a causa de los errores clásicos en los que cayó el equipo de programación asig-
nado a él, los cuales han sido analizados y detallados anteriormente, tales como una mala pla-
nificación inicial y prevención de riesgos; o la inexperiencia y desmotivación del equipo y la
metodología erróneamente escogida entre otros.
Si en este proyecto se hubiese utilizado una metodología más correcta, como la espiral
o la XP, ya que la programación por parejas es un método altamente efectivo y el modelo en
espiral te fuerza a efectuar determinadas pruebas con el fin de evitar posibles factores de ries-
go que pudieran llevar al fracaso del desarrollo de la aplicación; se hubiesen prevenido ade-
cuadamente gran parte de los riesgos asociados al proyecto, evitando así el efecto bola de
nieve, que al fin y al cabo, condujo a esta aplicación a un sinfín de retrasos y posiblemente a su
cancelación.
Página 6 de 6 Adrián Sánchez
Vicente Baixauli
Noemí Grau
