El documento describe los errores clásicos cometidos en proyectos de desarrollo de software, incluyendo errores personales, de proceso, del producto y tecnológicos. También incluye las perspectivas de los ejecutivos y desarrolladores, y propone una metodología de entrega por etapas.

1. FLORIDA CICLOS FORMATIVOS
DESARROLLO DE APLICACIONES INFORMÁTICAS
INFORME GIGA QUOTE
GIGA SAFE
D.A.4.
Miércoles, 25 de marzo de 2009
Realizado por:
Álvaro Fito
Diego Yarza
Profesor:
Jose Luis Soler

2. Errores Clásicos Cometidos
Errores de tipo Personal:
- Hazañas
He pensado que puedo trampear un informe con un gráfico de barras
pasando el texto del informe como una leyenda del objeto gráfico de
barras. Realmente es una trampa, pero siempre puedo volver atrás y
reimplementarlo más claramente después de la primera versión.
[Página 4. Párrafo 1. Línea 6]
- Expectativas poco realistas
Pero querían que se pudiera transferir automáticamente las cuotas
locales al computador central. Y querían tener hecho el sistema antes de
que se hagan efectivas las nuevas cuotas del 1 de Enero.
[Página 1. Párrafo 5. Línea 5]
- Falta de participación de los implicados
Estaban 12 horas al día, pero empleaban mucho tiempo leyendo
revistas, pagando facturas y hablando por teléfono.
[Página 6. Párrafo 4. Línea 3]
- Ilusiones
Dijo que estaba seguro de que lo conseguirían
[Página 2. Párrafo 5. Línea 4]
Errores de tipo Proceso:
- Planificación excesivamente optimista
Adelantaron la fecha de finalización del software que propusiste del 1 de
marzo al 1 de noviembre con lo que se acortó el plan propuesto en 6
meses. El comité añadió requisitos de comunicaciones a gran escala y
ha acortado el plan de 12 a 6 meses
[Página 1. Párrafo 5 y 6. Líneas 7 y 4]
- Planificación insuficiente
El comité ejecutivo les había proporcionado una especificación
aproximada, y emplearon las siguientes dos semanas en completar las
lagunas.
[Página 2. Párrafo 6. Línea 2.]
- Diseño inadecuado
Para poner el gráfico a la derecha, tengo que reescribir ese informe
concreto desde el principio.
[Página 6. Párrafo 2. Línea 2]
- Control insuficiente de la directiva
No se aprecia en ningún momento de la lectura que haya un control de
la directiva.

3. - Programación a destajo
Acabaron el diseño el 15 de junio, adelantándose al plan, y comenzaron
a codificar como locos para llegar al objetivo de tener la primera versión
de prueba el 1 de septiembre.
[Página 3. Párrafo1. Línea 1.]
Errores de tipo Producto:
- Exceso de requerimientos
Pero querían que se pudiera transferir automáticamente las cuotas
locales al computador central. Y querían tener hecho el sistema antes de
que se hagan efectivas las nuevas cuotas del 1 de Enero.
[Página 1. Párrafo 5. Línea 5]
- Cambio de las prestaciones
El equipo descubrió que tenía que modificar completamente la estructura
para las nuevas tasas.
[Página 3. Párrafo 2. Línea 2]
Errores de tipo Tecnología:
- Sobreestimación de las ventajas del empleo de nuevas
herramientas
¿Por qué no usas C++ y diseño orientado a objetos?, serás más
productivo que con C, y el plan se acortará en uno o dos meses.
[Página 1. Párrafo 8. Línea 2]
- Falta de control automático del código fuente
No se ha nombrado ninguna tecnología que controle automáticamente el
código, y nosotros hemos notado que haría falta.

4. Nuestros puntos de vista
Desde el punto de vista del Ejecutivo.
Nosotros hubiéramos dado todo el tiempo necesario ya que es una
herramienta para nuestra empresa. Todos sabemos que hay invertido un dinero
que hay que recuperarlo cuando antes, pero tengo que matizar ya que es para
nuestra empresa, hay que esperar y aguantar al máximo, si no da dinero en
corto plazo en máximo pero se asegura que habrá una mejoría.
También hay que revisar el proyecto conjuntamente con el creador o
desarrollador del software por si hay alguna pregunta o algo que mejorar para
luego no añadir ningún requerimiento extra.
Para finalizar, hay que tener mucha comunicación entre los
desarrolladores y los ejecutivos, para tener un software de calidad y adaptado
totalmente a la empresa.
Desde el punto de vista del Desarrollador.
Desde el primer momento no hubiera cambiado de lenguaje ya que eso
implica que haya gente que lo domine, y que esté acostumbrado a trabajar con
ese entorno. Y si por el contrario no lo hay, ya perdemos tiempo inicial, ya que
hay que formar a los desarrolladores en dicho lenguaje.
Seguidamente, el equipo de desarrolladores debe estar formado, ya que
al añadir gente, perdemos tiempo en informar por donde estamos en el
proyecto, eso implica que el equipo debe ser el mismo y formarlo como equipo
en sí, para trabajar en todos los contexto. (Tranquilidad, agobio, etc...)
Un punto muy importante es la planificación, ya que hay que tener todo o
casi todo muy planificado, así hubieran entregado el software el día que habían
dicho.
Para terminar, siempre en un equipo alguien de este, tiene que tener el
mando, y efectuar los cambios oportunos así como mandar en el equipo. Todo
esto favorece el trabajo en equipo.

5. Metodología
Nosotros hemos elegido una metodología de entrega por etapas, ya que
pedían hacer casi todo el trabajo al principio y luego se van entregando poco a
poco una serie de versiones.
Aquí dejo un esquema las diferentes etapas del modelo entrega por etapas.
Entrega por etapas: Orientado al resultado. Se conoce de antemano los
resultados del proyecto
- Los resultados se van entregando por etapas
- Los resultados pueden ser parciales o el mismo con varios refinamientos
- Se adelantan en el tiempo los resultados
- Se obtienen resultados sin estar al 100% terminado
- Proporciona signos tangibles de progreso
- Requiere una gestión compleja

6. Evaluación global
El principio ya hubo unos cuantos fallos en la programación del proyecto,
si este instante ya los hubieran solucionado, no habría pasado el efecto “bola
de nieve”.
Este efecto lo que ha provocado es un total descontrol o caos, que no
conlleva a ningún sitio, ya que en la mitad el proyecto los desarrolladores ya
estaban de malos modos hacia los compañeros. Esto dificulta la calidad y el
buen trabajo en la sala.
También se vio influido por los clientes que en mitad del proyecto, les
entrego un cambio de las tasas, que por culpa de esto se vio influido la
duración del proyecto.
Finalmente, para solucionar todos estos problemas o errores, una
persona tuvo que coger las riendas del proyecto para que se terminase a
tiempo.
En resumen, un proyecto tiene que tener una programación y una
persona que lo lidera, para que no ocurran estos errores “típicos” en la
programación de un software.