Caso Estudio Giga Quote

INFORME DEL CASO DE ESTUDIO: GIGA-QUOTE

Adrián Sánchez Vicent Baixauli

Noemí Grau

Caso de estudio: GIGA-QUOTE

Página 2 de 6 Adrián Sánchez Vicente Baixauli Noemí Grau

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 hubier ais 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.



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.



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.



¿Qué metodología de desarrollo sería la más conveni ente 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.



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.

Caso Estudio Giga Quote

Technology

Transcript of Caso Estudio Giga Quote