El Ciclo De Vida Del Proyecto De Software

El Ciclo De Vida Del Proyecto De Software

Resumen

Diseñar un software y hacerlo funcional es una tarea difícil de lograr, sin una metodología rigurosamente aplicada durante el ciclo de vida del proyecto de software, la ingeniería de software nos permite seguir un estándar que lleva como objetivo el correcto análisis de requerimientos, diseño exacto del software deseado, pruebas e implementación. En este documento se presenta una vista rápida de los elementos involucrados en el ciclo de vida del proyecto de software, se señalan los problemas más comunes que enfrenta el ingeniero de software, se describe y critica la fase de diseño y fase de implementación, finalmente se presentan conclusiones sobre el tema discutido.

Introducción

Los proyectos de software se componen de múltiples elementos que se pueden discutir largamente desde diferentes puntos de vista con objetivos diferentes tales como la comparación con diferentes métodos de análisis y diseño usadas en otras disciplinas de la ingeniería, criticas sobre los métodos usados para el análisis y diseño de productos de software, análisis de los componentes del diseño de software, etc.

Al abordar el tema del análisis de requerimientos y diseño de software en este documento se pretende exponer el punto de vista del autor, sobre el tema, considerando las experiencias adquiridas y la documentación bibliográfica consultada, con el objetivo de analizar los elementos del ciclo de vida del desarrollo de software y criticar los resultados obtenidos, así como ofrecer una recomendación sobre las consideraciones necesarias para lograr un análisis y diseño del software efectivo. No se pretende establecer una metodología o guía para hacer eficiente el desarrollo de software, sino exponer un punto de vista.

Los Requerimientos

Descripción y especificación de requerimientos de software

Cuando se habla de la especificación de requerimientos de software, nos referimos a los detalles que puede expresar el usuario del software que se diseñara y posteriormente codificara, los cuales serán tomados de las definiciones que el usuario expresara acerca de lo que necesita que sea automatizado en un sistema ya sea para procesar datos o para interactuar de maneras predefinidas ante eventos exteriores. Estos requerimientos padecen de defectos que pueden ser enumerados fácilmente y que el ingeniero que se encarga de tomar dichas especificaciones debe considerar a la hora de escribir los requerimientos que posteriormente serán analizados, para producir un diseño adecuado, eficiente y los más exacto posible a los requerimientos brindados por los usuarios.

Entre los defectos que se pueden encontrar en los documentos de especificación de requerimientos están los requerimientos con poco detalle debido a que el ingeniero asume que interpreta correctamente o que en base a su experiencia puede completar las ideas del usuario, sin consultar si sus suposiciones son correctas respecto a la interpretación que tiene de las especificaciones de requerimientos recibidas. Se puede señalar también que la especificación de requerimientos adolece de que en este punto del ciclo de vida del proyecto de software es difícil saber con exactitud que parte de los requerimientos quedaran para ser parte del hardware que será necesario para la ejecución del software y que parte será la que se diseñara como líneas de código a escribir, lo que nos lleva a la necesidad de ser exactos en la toma de requerimientos, pues, facilitara posteriormente el diseño del hardware y software, a su vez facilitará la integración posterior de los componentes diseñados por separado.

Un punto importante en la descripción de requerimientos y las especificaciones de requerimientos es que se debe dejar bien claro lo que no se desea del software, normalmente esto es algo que el ingeniero encargado de tomar los requerimientos y elaborar las especiaciones de requerimientos olvida anotar, y se asume lo que no se desea del software en lugar de recibir esta información del usuario del sistema a construir, esta situación deja un posible punto de falla que podría repercutir en un diseño inexacto del software y la consecuente insatisfacción del usuario final.

Finalmente es indispensable anotar que muchos problemas se pueden evitar en el diseño de un software si se sigue un estándar para la creación de cada documento de especificación y diseño, el cual debe contener información suficiente para hacer referencia cruzada y dibujar un mapa de concordancia entre los diferentes documentos a fin de facilitar al analista, diseñador y programador la posibilidad de revisar y revalidar especificaciones, evitando de este modo incluir errores tanto en el diseño como en la programación del código del software.

El Diseño

El diseño del software como parte del ciclo de vida del desarrollo de sistemas, no debe dejarse sin importancia o verse como una actividad en el ciclo de vida que puede ser sustituida por otra actividad subsiguiente. En muchos de los proyectos de software, el diseño es sustituido por la programación del código del software, olvidando lo importante que es diseñar y probar diseños antes de fabricar el producto deseado, este proceso de diseño es algo que no se puede olvidar en otras disciplinas de la ingeniería, como por ejemplo en la construcción de un complejo habitacional, se crean modelos a escala de los edificios y se prueba su resistencia al ambiente, terremotos y otras posibles catástrofes que pueden suceder en el ambiente circundante. Todo este conjunto de pruebas antes de iniciar la fabricación del producto hace que los errores incluidos en el producto final sean mínimos y la exactitud del producto construido sea aceptable para los usuarios.

De la misma manera el diseño del software a partir de la descripción requerimientos y la especificación de requerimientos, debe producir un prototipo capaz de resistir pruebas en un ambiente controlado, y su comportamiento ante las pruebas debe ser casi exacto a las pruebas que deberá pasar en el ambiente de producción, una vez que haya sido implementado. Este diseño le dirá al programador exactamente que hacer, tal como el diseño de un vehículo le dice al operador de ensamblaje las medidas exactas de los componentes a utilizar para la construcción del automotor.

Aunque el diseño del software este escrito en papel en forma de diagramas de flujo y descripción de cada función, librería, procedimiento y pantalla a crear, este debe ser capaz de resistir y aprobar las pruebas de funcionalidad, exactitud y satisfacción del usuario, analistas,

...