Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Caso Estudio Giga Quote

1,462 views

Published on

Documento explicativo de errores clásicos cometidos por un equipo de desarrollo, su posible solución y conclusiones.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Caso Estudio Giga Quote

  1. 1. INFORME DEL CASO DE ESTUDIO: GIGA-QUOTE Adrián Sánchez Vicent Baixauli Noemí Grau
  2. 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. 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. 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. 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. 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

×