Este documento presenta varios mitos comunes relacionados con el desarrollo de software. Se clasifican en mitos de gestión, del cliente y de los desarrolladores. Algunos ejemplos son que se puede añadir personal a un proyecto retrasado para acelerarlo, que solo se necesita hardware avanzado o que no es necesario planificar. Sin embargo, la realidad es que la planificación, comunicación con el cliente y uso de herramientas adecuadas son fundamentales para el éxito de un proyecto de software.

1. Universidad Laica
“Eloy Alfaro De Manabí”
Extensión el Carmen
Integrantes:
Lider Andrade
Rubén García
Juan Macas
Tema:
Mitos Del Software

2. MITOS DEL SOFTWARE
Muchas de las causas de las crisis del software se pueden encontrar
en una mitología que surge durante los primeros años del desarrollo
del software. Hoy, la mayoría de los profesionales competentes
consideran a los mitos por lo que son actitudes erróneas que han
causado serios problemas, tanto a los gestores como a los técnicos.
Sin embargo, las viejas actitudes y hábitos son difíciles de modificar, y
todavía se cree en algunos restos de los mitos del software.

3. Clasificación de los mitos:
Mitos de gestión.
Mitos del cliente.
Mitos de desarrollo.

4. Mitos De Gestión
Los gestores con responsabilidad sobre el
software, como los gestores en la mayoría de las
disciplinas, están normalmente bajo la presión de
cumplir los presupuestos, hacer que no se retrase
el proyecto y mejorar la calidad.

5. Mito.
Tenemos ya un libro que esta lleno de estándares y procedimientos
para construir software. ¿No le proporciona ya a mi gente todo lo que
necesita saber?.
Realidad.
Esta muy bien que el libro exista, pero ¿se usa?, ¿conocen los
trabajadores su existencia?, ¿refleja las prácticas modernas de
desarrollo de software?, ¿es completo?. En muchos casos, la
respuesta a todas estas preguntas es "no".
Mito.
Mi gente dispone de las herramientas de desarrollo de software más
avanzadas, después de todo, les compramos las computadoras más
modernas.
Realidad.
Se necesita mucho más que el último modelo de computadora
grande (o de PC) para hacer desarrollo de software de gran calidad.
Las herramientas de ingeniería del software asistida por computadora
(CASE), aunque la mayoría todavía no se usen, son más importantes
que el hardware para conseguir buena calidad y productividad.

6. Mito.
Si fallamos en la planificación, podemos añadir más programadores y
adelantar el tiempo perdido (el llamado algunas veces "concepto de
la horda mongoliana").
Realidad.
El desarrollo de software no es un proceso mecánico como la
fabricación. En palabras de Brooks [BRO75]: << ... añadir gente a un
proyecto de software retrasado lo retrasa aún más>>. Al principio,
esta declaración puede parecer un contra sentido. Sin embargo,
cuando se añaden nuevas personas, le necesidad de aprender y
comunicarse con el equipo puede y hace que se reduzca la
cantidad de tiempo gastado en el desarrollo productivo. Puede
añadirse gente, pero sólo de una manera planificada y bien
coordinada.

7. MITOS DEL CLIENTE
Un cliente que solicita una aplicación de software puede ser una
persona del despacho de al lado, un grupo técnico de la sala de
abajo, el departamento de ventas o una compañía exterior que
solicita un software bajo contrato. Los mitos conducen a que el cliente
se cree una falsa expectativa y finalmente, quede insatisfecho con el
que desarrolla el software.

8. Mito.
Una declaración general de los objetivos es suficiente para comenzar a
escribir los programes; podemos dar los detalles más adelante.
Realidad.
Una mala definición inicial es la principal causa del trabajo baldío en
software. Es esencial una descripción formal y detallada del ámbito de la
información, funciones, rendimiento, interfaces, ligaduras del diseño y criterios
de validación. Estas características pueden determinarse sólo después de una
exhaustiva comunicación entre el cliente y el analista.
Mito.
Los requisitos del proyecto cambian continuamente, pero os cambios pueden
acomodarse fácilmente, ya que el software es flexible.
Realidad.
Es verdad que los requisitos del software cambian, pero el impacto del
cambio varía según el momento en que se introduzca. Si se pone cuidado al
dar la definición inicial, los cambios solicitados al principio pueden
acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar
las modificaciones con relativamente poco impacto en el costo. Cuando los
cambios se solicitan durante el diseño del software, el impacto en el costo
crece rápidamente. Ya se han acordado los recursos a utilizar y se ha
establecido un esqueleto del diseño

9. Mitos de los desarrolladores.
Los mitos en los que aún creen muchos desarrolladores se han ido
fomentando durante cuatro décadas de cultura informática. Durante
los primeros días del desarrollo del software, la programación se veía
como un arte. Las viejas formas y actitudes tardan en morir.

10. Mito.
Hasta que no tengo el programa << ejecutándose >> realmente no tengo
forma de comprobar su calidad.
Realidad.
Desde el principio del proyecto se puede aplicar uno de los mecanismos más
efectivos para garantizar la calidad del software: la revisión técnica formal. La
revisión del software es un << filtro de calidad >> que se ha comprobado que
es más efectivo que la prueba, para encontrar ciertas clases de defectos en
el software.
Mito.
Lo único que se entrega al terminar el proyecto es el programa funcionando.
Realidad.
Un programa funcionando es sólo parte de una configuración del software
que incluye programas, documentos, y datos. La documentación es la base
de un buen desarrollo y, lo que es más importante, proporciona guías para la
tarea de mantenimiento del software.
Mucho profesionales del software reconocen la falacia de los mitos descritos
anteriormente. Lamentablemente, las actitudes y métodos habituales,
fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la
realidad dicta un método mejor. El reconocimiento de la s realidades del
software es el primer paso hacia la formulación de soluciones practicas para
su desarrollo.

11. Otros Tipos De Mitos

12. Un plan de proyecto es una lista de
mitos.
 Realidad: La planificación de proyectos de software contiene
varios componentes que definen el trabajo y cómo se hará.
Planificación lleva demasiado tiempo. El
tiempo estaría mejor invertirlo en
codificación y pruebas.
• Realidad: Tratar de ahorrar tiempo al no planificar se traduce en
retrasos, reproceso, y los aumentos de costos.

13. No puedo elaborar un plan de proyecto, ya que no
entendemos todo lo que hay que saber acerca del
proyecto.
 Realidad: Un plan es un documento vivo. La precisión se
incrementará con el tiempo y los detalles adicionales.
El desarrollo de software no se puede planificar porque es
“diferente” al de otras disciplinas de ingeniería.
Realidad: Los expertos en software dicen lo contrario.
Tenemos que identificar y asignar recursos. Nadie va a
pagar por un trabajo indefinido con objetivos poco claros!

14. Las estimaciones de software siempre
cambian la respuesta “correcta” de la
gestión.
 Realidad: Las estimaciones basadas en datos proporcionan
apalancamiento. La planificación ayuda a identificar el alcance
completo. La gestión ajusta la planificación de proyectos de software.
Esto se aplica a todos los demás,
pero mi proyecto es “diferente”.
Realidad: El plan del proyecto es flexible. Usted
identifica el modelo de proceso, tareas, riesgos, y los
recursos necesarios, los objetivos y las prioridades para
gestionar, están indicadas.

15. La planificación no se aplica a mí,
porque yo no desarrollo software.
 Realidad: Estas actividades suelen afectar otros ingenieros de
software. Es aún más importante para planificar los proyectos
“difusos”.
No hay buenas herramientas disponibles para
rastrear fácilmente las tareas y el calendario.
Realidad: Microsoft Project y otras herramientas están
disponibles. Las nuevas herramientas y técnicas
pueden ser adquiridas y aprendidas cuando sea
necesario.

16. No soy bueno en planificar. Es una tarea
administrativa que la debe hacer un
administrador.
 Realidad: La planificación es una competencia clave para todos
los ingenieros de software. “La planificación es un proceso natural.
Es mucho más divertido hacer algo planificado. Y lo bueno de no
planificar, es que el fracaso viene como una total sorpresa, que
suele estar precedida por un período de preocupación y
depresión”.
La planificación de Proyectos es la última
“moda” de procesos de software.
Realidad: La planificación es un área de proceso clave
del CMM Nivel 2. La planificación es básica y
obligatoria.