Necesidad de una Metodología - Necesidad de una Metodología

Necesidad de una Metodología

Serie: Ciclo de Vida del Software

En mi camino de desarrollo profesional existen diversos temas, que como analista y desarrollador de software, debo manejar e incorporar para tener éxito en mis proyectos. El desarrollo de software contempla una gran gama de conceptos y herramientas que debemos dominar. La elección correcta de estas herramientas son las que definirán el éxito o fracaso de nuestro sistema.

Hoy daremos inicio a un tema primordial en la Ingeniería de Software: El Ciclo de Vida del Software. Debido a la importancia y cantidad de información que se maneja en este tema, eh dividido el mismo en una serie de 10 puntos, organizados de la siguiente forma:

  • Necesidad de una Metodología.
  • Definición de Metodología.
  • ¿Cuál es el costo de un Software?
  • Costos ocultos y consecuencias de las fallas del Software.
  • Sobrecostos, retrasos y cancelaciones en los Sistemas de Software.
  • Complejidad del Software.
  • El Modelo Cascada.
  • El Modelo Espiral.
  • Modelo de Prototipos Agiles y Rápidos.
  • Método de desarrollo de Sistemas Dinámicos (DSDM)

Conocidos los temas, entremos en materia…

El Ciclo de Vida de un Software viene definido según la metodología que se utilice para el desarrollo del mismo. Lo que se busca con una metodología es el tener a disposición herramientas que nos permitan, de manera detallada y minuciosa, el desarrollo extenso y estandarizado, facilidad de corrección y sobre todo control en cada etapa de desarrollo del programa. Esto será lo que nos permitirá desarrollar un programa estandarizado, acabado y libre de errores.

Necesidad de una Metodología

Desde el momento en el que nació la necesidad del mercado de Sistemas Informáticos, el programador realizaba un levantamiento de las solicitudes del cliente y con los requerimientos a mano se iniciaba el desarrollo de la aplicación. Este comportamiento no es administrable, supervisado o gestionado de ninguna manera, razón por la cual los errores se corregían al mismo tiempo que se surgían, tantos errores de lógicos de programación, errores de codificación y requerimientos solicitados por el cliente o usuario final.

El comportamiento descrito en el párrafo anterior corresponde a una técnica muy utilizada anteriormente de nombre “code & fix” y que actualmente denotamos como obsoleta. Esta técnica se basa en requerimientos ambiguos y sin especificaciones puntuales. Al no seguir reglas para el desarrollo del proyecto, el cliente o usuario final solo da a conocer especificaciones muy generales del producto final. Por esta razón, el ciclo de vida de este tipo de proyectos finaliza cuando se satisfacen todas las especificaciones, no solo las primeras especificaciones, sino también todas aquellas que nacen en el desarrollo del mismo.

Esta técnica tiene ventajas de no gastar recursos en análisis, planificación, gestión de recursos, documentación, entre otros. Otra ventaja no menos importante es su comodidad. Al ser una técnica ágil para la etapa de desarrollo, es muchas veces recomendable cuando se conoce de antemano que el proyecto a realizar es pequeño y cuanta con un equipo no menor de 2 programadores.

Pero como observamos, esta técnica es solo aplicable para proyectos pequeños, soluciones inmediatas de poca envergadura o procesos repetitivos de corto alcance. Pero, ¿podremos utilizar esta técnica para proyectos de mayor envergadura? Este tipo de técnica aumentaría el costo del proyecto, dado a que costo de recursos será mayor al presupuesto; aumentado en el tiempo de desarrollo y dudas en la calidad del producto (Mala utilización o inexistencia de estándares de codificación).

Artículos Relacionados

Artículos Relacionados - Externos