PDF de programación - Unidad Nº I: Ciclo de Vida de Proyectos - Introducción al Diseño de Sistemas de Información

Introducción al Diseño de Sistemas de Información

Unidad Nº I: Ciclo de Vida de Proyectos

Facultad Regional Santa Fe Universidad Tecnológica Nacional

El ciclo de vida del proyecto
Para que un proceso de desarrollo de software pueda controlarse y asegurarse que construya
software de alta calidad de una forma productiva, es necesario proveedor de métodos,
herramientas y procedimientos.
Los métodos indican “cómo” construir técnicamente el software. Los métodos abarcan un
amplio espectro de tareas que incluyen: planificación y estimación de proyectos, análisis de los
requisitos del sistema y del software, diseño de estructura de datos, arquitectura de programas
y procedimientos algorítmicos, codificación, prueba y mantenimiento. Los métodos introducen
frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de
criterios para la calidad del software.
Las herramientas suministran un soporte automático o semiautomático para los métodos.
Existen herramientas para soportar cada uno de los métodos mencionados anteriormente.
Cuando se integran las herramientas de forma que la información creada por una herramienta
pueda ser usada por otra, se establece un sistema para el soporte de desarrollo del software,
llamado ingeniería del software asistida por computadora (CASE).
Los procedimientos son el pegamento que junta los métodos y las herramientas y facilita un
desarrollo racional y oportuno del software. Los procedimientos definen la secuencia en la que
se aplican los métodos, las entregas (documentos, informes, formas, etc.) que se requieren, los
controles que ayudan a asegurar la calidad y coordinar los cambios, y las directrices que
ayudan a los gestores del software a evaluar el progreso.
A su vez se definen una serie de pasos que abarcan los métodos, las herramientas y los
procedimientos. Estos pasos se denominan frecuentemente paradigmas de la ingeniería del
software o ciclos de vida de proyecto.
Ciclo de vida clásico
Este paradigma es llamado algunas veces ‘modelo en cascada’, el paradigma del ciclo de vida
exige un enfoque sistemático y secuencial del desarrollo del software que comienza en el nivel
del sistema y progresa a través del análisis, diseño, codificación, prueba y mantenimiento.

Ingeniería
del Sistema

Análisis

Diseño

Codificación

Prueba

Mantenimiento

Figura I. 1 - Ciclo de Vida Clásico

Modelizado a partir del ciclo convencional de una ingeniería, el paradigma del ciclo de vida
abarca las siguientes actividades:

Ingeniería y análisis del sistema. Debido a que el software es siempre parte de un sistema
mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del
sistema y luego asignando algún subconjunto de estos al software. Este planteamiento del
sistema es esencial cuando el software debe interrelacionarse con otros elementos, tales
como hardware, personas y bases de datos. La ingeniería y el análisis del sistema abarca


los requisitos globales a nivel del sistema con una pequeña cantidad de análisis y de
diseño a un nivel superior.
Análisis de los requisitos del software. El proceso de recopilación de los requisitos se
centra e intensifica especialmente para el software. Para comprender la naturaleza de los
programas que hay que construir, el analista debe comprender el ámbito de la información
del software, así como la función, el rendimiento y las interfaces requeridos. Los requisitos,
tanto del sistema como del software, se documentan y se revisan con el cliente.
Diseño. El diseño es realmente un proceso multipaso que se enfoca sobre cuatro atributos
distintos del programa: la estructura de los datos, la arquitectura del software, el detalle
procedimental y la caracterización de la interfaz. El proceso de diseño traduce los
requisitos en una representación del software que pueda ser establecida de forma que
obtenga la calidad requerida antes de que comience la codificación.
Codificación. El diseño debe traducirse en una forma legible para la máquina. El paso de
codificación realiza esta tarea. Si el diseño se realiza de una manera detallada, la
codificación puede realizarse mecánicamente.
Prueba. Una vez que se ha generado el código, comienza la prueba del programa. La
prueba se centra en la lógica interna del software, asegurando que todas las sentencias se
han probado, y en las funciones externas, realizando pruebas que aseguren que la
entrada definida produce los resultados que realmente se requieren.
Mantenimiento. El software, indudablemente, sufrirá cambios después de que se entregue
al cliente. Los cambios ocurrirán debido a que se hayan encontrado errores, a que el
software deba adaptarse a cambios del entorno externo (por ejemplo, un cambio solicitado
debido a que se tiene un nuevo sistema operativo o dispositivo periférico), o debido a que
el cliente requiera ampliaciones funcionales o de requerimientos. El mantenimiento del
software aplica cada uno de los pasos precedentes del ciclo de vida a un programa
existente en vez a uno nuevo.

El ciclo de vida clásico es el paradigma más antiguo y más ampliamente usado en la ingeniería
del software. Sin embargo, con el paso de unos cuantos años, se han producido críticas al
paradigma que cuestionan su aplicabilidad a todas las situaciones. Entre los problemas que se
presentan algunas veces, cuando se aplica este paradigma se encuentra:
1. Los proyectos raramente siguen el flujo secuencial que propone el modelo. Siempre hay

iteraciones y se crean problemas en la aplicación del paradigma.

2. Normalmente, es difícil para el cliente establecer explícitamente al principio todos los
requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles
incertidumbres que pueden existir al comienzo de muchos proyectos.

3. El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarrollo del proyecto,
no estará disponible una versión operativa del programa. Un error importante no detectado
hasta que el programa esté funcionando puede ser desastroso.

Cada uno de estos problemas es real. Sin embargo, el paradigma clásico del ciclo de vida tiene
un lugar definido e importante dentro del trabajo realizado en ingeniería del software.
Suministra una plantilla en la que pueden colocarse los métodos para el análisis, diseño,
codificación, prueba y mantenimiento. Y, a pesar de sus inconvenientes, es significativamente
mejor que desarrollar el software sin guías.
Construcción de prototipos
Normalmente un cliente define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el programador
puede no estar seguro de la eficiencia de un algoritmo, de la adaptabilidad de un sistema
operativo o de la forma en que debe realizarse la interacción hombre-máquina. En estas y
muchas otras situaciones, puede ser mejor método la construcción de un prototipo.
La construcción de prototipos es un proceso que facilita al programador la creación de un
modelo del software a construir. El modelo tomará una de las tres formas siguientes:

1. un prototipo en papel o un modelo basado en PC que describa la interacción
hombre-máquina, de forma que facilite al usuario la comprensión de cómo se
producirá tal interacción;

2. un prototipo que implemente algunos subconjuntos de a función requerida del

programa deseado, o

3. un programa existente que ejecute parte o toda la función deseada, pero que tenga

otras características que deban ser mejoradas en el nuevo trabajo de desarrollo.



En la Figura I.2 se muestra la secuencia de sucesos del paradigma de construcción de
prototipos.

Comienzo

Parada

Recolección y
refinamiento de

requisitos

Producto de
ingeniería

Refinamiento
del prototipo

Diseño
rápido

Construcción
de prototipo

Evaluación del
prototipo por el

cliente

Figura I. 2 – Ciclo de Construcción de Prototipos

Como en todos lo métodos de desarrollo de software, la construcción de prototipos comienza
con la recolección de los requisitos. El técnico y el cliente se reúnen y definen los objetivos
globales para el software, identifican todos los requisitos conocidos y perfilan las áreas en
donde será necesario una mayor definición. Luego se produce un “diseño rápido”. El diseño
rápido se enfoca sobre la representación de los aspectos del software visibles al usuario (por
ejemplo, métodos de entrada y formatos de salida). El diseño rápido conduce a la construcción
de un prototipo. El prototipo es evaluado por el cliente-usuario y se utiliza para refinar los
requisitos del software a desarrollar. Se produce un proceso interactivo en el que el prototipo es
“afinado” para que satisfaga las necesidades del cliente, al mismo tiempo que facilita al que lo
desarrolla una mejor comprensión de lo que hay que hacer.
Idealmente, el prototipo sirve como mecanismo para identificar los requisitos del software. Si se
va a construir un prototipo que funcione, el realizador intenta hacer uso de fragmentos de
programas existentes o aplica herramientas (generadores de informes, generadores de
interfaces de usuarios, etc.) que faciliten la generación de programas que funcionen.
Pero, ¿qué debemos hacer con el prototipo cuando ya ha servido para el propósito
establecido?. Brooks nos da una respuesta:

En la mayoría de los proyectos, el primer sistema construido apenas es utilizable. Puede
ser demasiado lento, demasiado grande, difícil de usar o las tres cosas. No hay más
al