Críticas a la madurez del desarrollo de Software.

Según estadísticas publicadas en los últimos años arrojan en general que cerca del 70% de los proyectos de software fracasan ya sea por el abandono del proyecto o porque el software terminado jamás se usa o no cumplieron con los requisitos del cliente.

De acuerdo con la información recopilada a través de internet e identificado a mi punto de vista 5 principales causas que potencializan el fracaso de los proyectos de software.

1. Requerimientos incompletos o mal especificados. Esta causa para mi es la más importante, porque las necesidades que dan lugar a que el cliente opte por el desarrollo de un software deben ser cubiertas con dicho producto de software, de lo contrario el software que se haya desarrollado no cumplirá con estos requerimientos y el software nunca cumplirá la función para la que fue desarrollado.

2. Cambios constantes en los requerimientos. Generalmente cuando el analista de software hace la recolección de requerimientos, casi siempre quedan pequeños detalles que modificar, pero a veces estas modificaciones no se documentan y esto involucra que las revisiones técnicas o los casos de prueba se diseñen de manera errónea y estas pruebas ya no sean aplicables o terminen estando mal diseñados.

3. Mal diseño del cronograma de actividades. Esto pasa frecuentemente en equipos de desarrollo de software que tienen poca experiencia y por lo mismo tienden a asignar el tiempo incorrecto a las diversas actividades por ejemplo, existen actividades que necesitan mucho tiempo, por ejemplo en el análisis de requerimientos pero no se le destinan los días u horas suficientes, esto puede causar dos errores, el primero es que los requerimientos queden documentados de forma muy simple y no lo suficientemente definidos y detallados ó el segundo, que se detallen de forma correcta los requerimientos, pero esto retrasa al equipo de trabajo con demasiado tiempo que el tiempo de realización del proyecto se sobre calendariza y se incumple en el tiempo de entrega del proyecto con el cliente.

4. Definición irreal del alcance del proyecto. Como en el punto anterior, la falta de inexperiencia de los equipos de desarrollo, les es muy complicado determinar los módulos funcionales y requerimientos que solicita el cliente que si está a su alcance cubrir con el sistema que se vaya desarrollar, por ejemplo, existen ocasiones que el cliente tiene la idea que cualquier cosa que soliciten en su sistema, es posible desarrollarse. Pero esto no es verdad, existen requerimientos que ya sea por falta de conocimientos del equipo de desarrollo o la falta del acceso a nueva tecnología, esto entre otras cosas similares causan que no se cumplan las expectativas del cliente, que le proyecto fracase y se pierda credibilidad ante nuestros clientes.

5. El mal uso de metodologías. Muchas veces en los equipos de desarrollo no se toma en cuenta el uso de metodologías y ciclos de vida para el desarrollo de software, esto principalmente es por la falta de conocimiento de dichas técnicas o simplemente la forma de pensar de los desarrolladores, muchos piensan que el hecho de hacer tanta documentación es una pérdida de tiempo que se podría utilizar en la programación del software. Debemos de tomar en cuenta que como en todo proceso, todas las actividades se deben de documentar con el fin de que si se requiere hacer un cambio, o se detecta algún error, sea más fácil la identificación de la etapa del ciclo de vida y la actividad en que se inyecto dicho error.

De todo esto mi conclusión es, que los equipos de desarrollo de software deben aplicar la metodología más adecuada al tipo de software que vayan a desarrollar ya que esto nos reduce de forma muy significativa el tener errores en nuestro proyecto y si los llegara a haber, tendríamos una forma eficaz y eficiente de poderlos encontrar y efectuar un plan de acción para la corrección y prevención de estos, es importante señalar que, a mi punto de vista no es recomendable seguir una metodología al pie de la letra, sino que debemos adecuar esta metodología a nuestro proyecto y no nuestro proyecto a la metodología, ya que ningún proyecto de software es igual a otro pero siempre llevando esta metodología como una guía efectiva para el desarrollo de nuestros proyectos y productos de software.

Elaborado por: Erik Alberto Custodio García.