UNIDAD III – PROTAGONISTAS DE LOS SISTEMAS

UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
CAMBIOS EN EL ANALISIS DE SISTEMAS............................2
EL MOVIMIENTO HACIA EL ANALISIS
ESTRUCUTRADO ...................................................2
EL SURGIMIENTO DE LAS HERRAMIENTAS
AUTOMATIZADAS DE ANALISIS ...........................3
EL USO DE PROTOTIPOS ...............................3
ENFOQUE PARA EL DESARROLLO DE
PROTOTIPOS .............................................5
HERRAMIENTAS DE MODELADO ..........................................9
DIAGRAMA DE FLUJO DE DATOS ..............................11
EL DICCIONARIO DE DATOS .......................................12
ESPECIFICACIONES DE PROCESO ............................15
LENGUAJE ESTRUCTURADO .............................15
PRE/POST CONDICIONES ....................................16
TABLAS DE DECISION .........................................17
DIAGRAMA DE ENTIDAD RELACION ..........................18
DIAGRAMA DE TRANSICION DE ESTADOS ...............19
BALANCEO DE MODELOS ...........................................22
HERRAMIENTAS ADICIONALES DE MODELADO ................24
INGENIERIA DE SOFTWARE ..................................................26
HERRAMIENTAS CASE ..........................................................32
1
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
CAMBIOS EN EL ANALISIS DE SISTEMAS
EL MOVIMIENTO HACIA EL ANALISIS ESTRUCTURADO
Hasta fines de los años 70, el analista escribía lo que entendía de los
requerimientos del usuario en un enorme documento que consistía
primariamente en una narrativa. Los primeros autores de textos de
análisis estructurado señalaron que estos pesados tomos (a menudo
conocidos como especificación funcional) se veían afectados por
diversos problemas importantes:
Eran monolíticos: había que leer completamente la especificación, de
principio a fin, para poder entenderla. Es una falla importante, pues
existen muchas situaciones en las que el analista quisiera leer y
comprender una parte de la especificación sin tener que leer
necesariamente las demás.
Eran redundantes: a menudo se repetía la misma información en
diversas partes del documento. El problema con esto es que si se
tenían que hacer cambios en los aspectos de los requerimientos, el
cambio debía reflejarse en varias partes del documento (hoy sería un
problema mucho menor).
Eran ambiguas: el reporte detallado de los requerimientos podía ser (y
a menudo era) interpretado de diferente manera por el usuario, el
analista, el diseñador y el programador.
Eran imposibles de mantener: por todas las razones descriptas
anteriormente, la especificación funcional era casi obsoleta para
cuando llegaba el final del proceso de desarrollo del sistema (es decir
cuando el sistema se ponía en operación), y a menudo era obsoleto
para el final de la fase de análisis. Esto significa que la mayoría de los
sistemas que se desarrollaron durante décadas pasadas no tienen
definiciones actualizadas de las políticas de negocios que se supone
que llevan a cabo.
Mientras se debatían todos estos problemas, ya se estaba adaptando
un conjunto complementario de ideas en el área de programación y
diseño, normalmente conocidas como diseño y programación
estructurados, que prometían grandes mejoras en la organización,
codificación, prueba y mantenimiento de los programas de
computadora.
Como resultado ha habido un movimiento gradual (ya que aceptarlo le
ha llevado a la profesión de desarrollo de sistema varios años)
tendiente a hacer especificaciones funcionales que sean:
Gráficas: compuestas de una variedad de diagramas, apoyadas con
material textual detallado que sirve de referencia más que como
cuerpo principal de la especificación.
Particionadas: de tal manera que se puedan leer independientemente
porciones individuales de la especificación.
2
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Mínimamente redundantes: de tal manera que los cambios en los
requerimientos del usuario puedan incorporarse normalmente en sólo
una parte de la especificación.
Este enfoque que se conoce como estructurado, se utiliza ahora en la
mayoría de las organizaciones de desarrollo de sistemas orientados a
los negocios, al igual que en gran número de las orientadas hacia la
ingeniería.
EL SURGIMIENTO DE HERRAMIENTAS AUTOMATIZADAS DE
ANÁLISIS
En un sistema muy grande puede haber 50, 100 o más diagramas de
flujo de datos, diversos diagramas de entidad-relación y,
potencialmente, varios diagramas de transición de estados; por lo que
la cantidad de trabajo manual puede ser en verdad intimidante.
Además del trabajo que se necesita para crear y mantener los
diagramas, el análisis estructurado clásico requiere de una gran
cantidad de trabajos para verificar los diagramas con el fin de asegurar
que sean consistentes y estén completos; debido a que esta labor es
detallada y aburrida, tiende a estar plagada de errores. En
consecuencia, no se encontraban muchos de los errores de
especificación que se debieran haber encontrado. Muchos de estos
problemas se pueden resolver con apoyo automatizado adecuado.
Esto era bien conocido aun desde que por primera vez se introdujo el
análisis estructurado clásico, pero el costo de la automatización estaba
por encima de las posibilidades económicas de la mayoría de las
organizaciones. Sin embargo, el desarrollo de poderosas estaciones
de trabajo gráficas llevó a que varios proveedores ofrezcan productos
(normalmente basados en PC) que dibujan diagramas de flujo de
datos y otros, además de llevar a cabo una variedad de labores de
revisión de errores.
Esto lleva primordialmente a un nivel más elevado de calidad en los
modelos de sistemas producidos. También, de manera secundaria,
hará a modelos gráficos del sistema visualmente más atractivos. En la
medida en que los conceptos de revisión de errores sean
automatizados, podrán eliminar problemas de productividad,
confiabilidad y en la medida en que las herramientas de Ingeniería de
software auxiliada por computadora (CASE) comiencen a generar
programas directamente desde las especificaciones, también incluso
se reducirá la necesidad de programadores.
EL USO DE PROTOTIPOS
Algunos usuarios tienen dificultades al tratar con los modelos gráficos
del análisis estructurado y prefieren alguna otra forma de modelar los
requerimientos y comportamientos del sistema. Las herramientas de
generación de prototipos se han considerado como una alternativa al
análisis estructurado para tales usuarios.
Existe otra razón de la popularidad de los prototipos, y es que se
considera que el análisis estructurado clásico consume demasiado
3
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
tiempo; para cuando concluye la fase de análisis, el usuario habrá
olvidado para qué quería en un principio el sistema. Esto suele ser
resultado de alguno de los siguientes problemas:
El equipo encargado del proyecto tardó demasiado en desarrollar
modelos del sistema actual y luego se tuvo que tardar aún más
modelando el nuevo.
La organización invirtió previamente poco o nada de tiempo, en hacer
análisis, pues prefirió codificar lo antes posible. El trabajo de análisis
pudiere parecerles improductivo.
Los primeros proyectos que se han realizado utilizando el análisis
estructurado pudieron consumir más tiempo de lo normal, pues los
analistas están aprendiendo nuevas técnicas y discutiendo respecto a
la mejor forma de aplicar dichas técnicas.
Las herramientas de generación de prototipos (herramientas de
software que permiten al analista construir un simulacro del sistema)
se ven por ello como una solución efectiva a estos problemas.
También el uso de prototipos tiende a concentrarse en el aspecto de la
interfaz humana en los proyectos de desarrollo de sistemas.
El desarrollo de prototipos es una metodología valiosa para identificar
con rapidez, las necesidades particulares de información del usuario.
Existen cuatro enfoques en el desarrollo de prototipos. El desarrollo
efectivo de prototipos debería efectuarse en las primeras etapas del
ciclo de vida del desarrollo de sistemas, durante la fase de
establecimiento de los requerimientos de información. Sin embargo, el
desarrollo de prototipos es una técnica compleja que requiere del
conocimiento cabal del ciclo de vida del desarrollo de sistemas antes
de llegar a implantarlo con éxito.
El desarrollo de prototipos es muy relevante como técnica de
obtención de información. Cuando se piensa de ésta manera en el
desarrollo de prototipos, el analista de sistemas tiene la posibilidad de
detectar las reacciones iniciales de los usuarios y de la gerencia hacia
el prototipo; las sugerencias del usuario sobre las modificaciones al
sistema bajo desarrollo o depuración si éste ya fue presentado; las
posibles innovaciones para él, y los planes de revisión para aquellas
áreas del sistema que quieran implantarse primero o las áreas de la
organización que deberán considerarse próximamente.
Reacciones iniciales del usuario
De manera simultánea a la presentación del prototipo de un sistema
de información que hace como analista de sistemas, también estará
interesado en enterarse de las reacciones de los usuarios y de la
gerencia ante este prototipo. Le interesará saber con detalle, cómo
reaccionan al trabajar con el prototipo, y qué tan inconveniente es el
acoplamiento entre las necesidades planteadas, y las características
modeladas en el sistema. Estas reacciones se obtienen por medio de
la observación, la evaluación y las hojas de retroalimentación. Cada
una de ellas plasmará la opinión de las personas acerca del prototipo,
4
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
conforme se relacionan con él. A través de la recopilación de tales
reacciones, el analista irá descubriendo nuevas perspectivas del
prototipo, incluso si los usuarios se encuentran satisfechos con él y si
habrá dificultades para vender o implantar el sistema.
Sugerencias del usuario
Al presentar un prototipo, el analista también se encuentra interesado
en las sugerencias de los usuarios y de la gerencia acerca de su
refinamiento o modificación. Conforme vayan trabajando en el
prototipo, por un período específico, se irán recopilando sus
sugerencias. El tiempo y dedicación que el usuario otorga al prototipo,
indica su interés hacia el proyecto de sistemas.
Las sugerencias son fruto de la relación de los usuarios con el
prototipo, asimismo, el reflejo de ellos sobre la misma. Las
sugerencias que aporta el usuario deben indicar al analista por qué
caminos dirigirse para refinar el prototipo, modificarlo o depurarlo, de
forma tal que satisfaga mejor las necesidades de los usuarios.
Innovaciones
Las innovaciones del prototipo forman parte de la información que se
encuentra indagando el equipo de analistas de sistemas. Las
innovaciones son aquellas características nuevas del sistema, que no
fueron contempladas previamente a la interacción con el prototipo.
Van más allá de las características que fueron consideradas para el
prototipo actual, al incorporarle algo más que es innovador.
Planes de revisión
Los prototipos prevén el sistema futuro. Los planes de revisión
permiten identificar las prioridades que deberán considerarse
próximamente para el desarrollo del prototipo. En las situaciones
donde se encuentran involucradas muchas áreas de la organización,
los planes de revisión permiten determinar cuáles serán las siguientes
áreas a considerar.
La información que se obtiene con el uso de prototipos permite al
analista establecer prioridades y reorientar sus planes de una manera
menos costosa y con un mínimo de contratiempos. Por ello es que van
de la mano el desarrollo de prototipos y la planificación.
ENFOQUE PARA EL DESARROLLO DE LOS PROTOTIPOS
Tipos de prototipos
La palabra prototipo se utiliza de muchas maneras diferentes. Antes
de intentar sintetizar todas éstas connotaciones en una sola definición,
o tratar de establecer un solo enfoque correcto para el tópico
controvertido del desarrollo de prototipos, trataremos de ilustrar la
manera por la cual las diferentes concepciones del prototipo pueden
aplicarse de manera práctica a situaciones particulares.
5
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Consideraremos las cuatro definiciones que son más comunes para el
desarrollo de prototipos.
Prototipos de remiendo
La primera clase de prototipos tiene que ver con la construcción de un
sistema que si bien funciona, se encuentra remendado o parchado. En
ingeniería a éste concepto se lo denomina tableta de prototipo, en
donde se desarrolla un circuito integrado mediante un modelo
operable de elementos sobrepuestos aún no definitivos.
Un ejemplo en los sistemas de información es la creación de un
modelo operable, el cual cuenta con todas sus características
necesarias aunque pudiera ser ineficiente. En éste caso de prototipos,
los usuarios se relacionan con el sistema, adaptándose a las
interfases y a los tipos de salidas disponibles. Sin embargo, los
procesos de recuperación y almacenamiento de información son
ineficientes, ya que los programas se escribieron de manera
apresurada con el fin exclusivo de que fueran operativos, aunque no
eficientes.
Otro tipo de prototipos para sobreponer, podría ser aquel sistema de
información que cuente con todas las características propuestas, pero
que en realidad sea un modelo básico, que eventualmente será
perfeccionado.
Modelo a escala no funcional
La segunda concepción que consideramos en el desarrollo de
prototipos es la de aquellos modelos no funcionales que se construyen
a escala, con el objeto de evaluar ciertos aspectos de diseño. Un
ejemplo de ello sería la construcción de un modelo de un automóvil a
escala para evaluarlo en túneles de viento. Si bien el tamaño y la
forma del auto es preciso, el vehículo no funciona. En éste caso sólo
se incluyen las características esenciales del automóvil para la
realización de las pruebas particulares.
Un modelo no funcional de un sistema de información a escala podría
ser aquel en el cual la codificación que se requiere es extensa en
cantidad; y más bien, podría lograrse una idea de la utilidad del
sistema, si en el prototipo funcionan únicamente los procesos de
entrada y salida. En éste caso el procesamiento de información no es
contemplado, por ser en sí costoso y requerir de tiempo. Sin embargo,
la evaluación sobre la utilidad del sistema puede realizarse con base
en el prototipo de las entradas y salidas.
Primer modelo a escala completa
Una tercera concepción en el desarrollo de prototipos implica crear un
primer sistema a escala completa, llamado con frecuencia “piloto”. Un
ejemplo de ello sería el desarrollo del prototipo del primer aeroplano
de una serie. El prototipo es completamente funcional y es realización
de lo que según el diseñador será una serie de aeroplanos con
características idénticas a éste.
Este tipo de prototipos es útil cuando se planea implantar el mismo
sistema de información en varias instalaciones. Un modelo funcional a
escala total permite una interacción realista con el sistema, reduciendo
los costos de solución de cualquier problema que emerja con el nuevo
sistema.
6
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Por ejemplo, cuando una cadena de tiendas de autoservicio piensa
utilizar el mismo sistema computarizado para el control de envío de
sus vendedores en todas sus sucursales, deberá instalarse un primer
modelo a escala en uno de los almacenes, con el fin de solucionar
cualquier problema que se presente, antes de implantarlo en las
demás tiendas.
Otro ejemplo típico lo tenemos en las instalaciones bancarias con la
transferencia electrónica de fondos. En una o dos localidades se
instalaría primero un modelo a escala completa del prototipo, y si
tuviera éxito, se implantaría en todas las sucursales, con base en el
patrón de uso y en otros elementos fundamentales.
Un tercer ejemplo de éste tipo de prototipos sería un sistema regional
de inventarios de sangre, el cual, al concluirse intentará administrar
siete hospitales del área. Sin embargo, el prototipo es un modelo
operativo a gran escala que se implanta a discreción en uno de los
hospitales de la región, con miras a instalarlo en los hospitales
restantes, una vez transcurrido el período de evaluación y verificación.
Un modelo que cuenta con ciertas características esenciales
Una cuarta concepción del prototipo contempla la construcción de un
modelo funcional que incluya algunas, pero no todas las
características que tendrá el sistema final. Una analogía sería un
centro comercial inconcluso que abre provisionalmente sus puertas.
En un centro comercial de éste tipo, se tienen las funciones
esenciales, tales como la posibilidad de adquirir ciertos artículos, la
existencia de restoranes de comida preparada y el estacionamiento;
aunque no se ha ocupado por completo, ni se ofrecen todos los
artículos que eventualmente se ofrecerán en la apertura formal. Con
una visita inicial al centro comercial inconcluso es posible imaginar lo
que éste tendrá en el futuro.
Cuando los prototipos se desarrollan de ésta manera, se contemplan
ciertas características esenciales, mas no todas. Por ejemplo, el menú
que presentará un sistema en la pantalla, puede enumerar seis
características: agregar un registro, actualizar un registro, eliminar un
registro, búsqueda de un registro con base en una palabra clave,
enumerar registros y otras clases de búsquedas. Sin embargo, en el
prototipo, el usuario sólo dispone de tres de las seis funciones, de tal
forma que él puede agregar un registro (característica 1), eliminarlo
(característica 3), o desplegarlos (característica 5).
Cuando se desarrollan éstos tipos de prototipos, el sistema se planifica
con base en módulos, de tal forma que aquellas características que se
aprobarán en el prototipo podrían incorporarse en un sistema final
mayor, sin requerir de gran esfuerzo durante la conexión. Los
prototipos desarrollados de ésta manera, operan como parte de
sistemas actuales y no son sólo un parche como los hemos
considerado en la primera definición de prototipos.
Los prototipos como alternativa en el ciclo de vida del desarrollo
de sistemas
Ciertos analistas afirman que el desarrollo de prototipos debería
considerarse como una alternativa en el ciclo de vida del desarrollo de
sistemas.
7
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Las reservas que se tienen respecto al ciclo de desarrollo de sistemas
se centra en dos preocupaciones relacionadas entre sí. La primera se
debe al extenso tiempo que transcurre a lo largo del SDLC. Conforme
el analista invierte más tiempo, el costo del sistema desarrollado se
incrementa proporcionalmente.
La segunda preocupación es que los requerimientos del usuario se
van modificando a lo largo del tiempo. Estos evolucionan desde el
momento en que se realiza el análisis de las necesidades del usuario
hasta el momento que se concluye y se entrega el sistema. Debido a
tal duración del ciclo, el sistema que resulte puede no llegar a
satisfacer adecuadamente las necesidades de información del usuario.
Tales preocupaciones se encuentran relacionadas, pues ambas se
basan en el tiempo que se requiere para concluir el SDLC y en el
problema que implica alejarse de las necesidades del usuario, durante
las etapas subsecuentes del desarrollo. Si un sistema se desarrolla de
manera aislada de los usuarios, puede no satisfacer sus expectativas.
Como corolario al problema de distanciarse de los requerimientos
evolutivos de información del usuario, se tiene que algunos no saben
en realidad lo que quieren, sino hasta que ven algo tangible. Con
frecuencia, en un SDLC tradicional es demasiado tarde para modificar
un sistema no deseado, una vez que se ha entregado.
Para resolver éstos inconvenientes, algunos analistas proponen que el
desarrollo de prototipos sea una alternativa al SDLC. Cuando los
prototipos se desarrollan de ésta manera, el analista reduce
efectivamente el período que transcurre entre la indagación de los
requerimientos de información y la entrega de un sistema funcional.
Además, al diseñar prototipos, en lugar de apegarse al ciclo formal de
desarrollo, pueden evitarse ciertos problemas concernientes a la
identificación precisa de los requerimientos de información del usuario.
Con un prototipo, el usuario puede ver en realidad lo que llegará a ser
posible; y asimismo, cómo se traducen sus necesidades en hardware y
software.
Entre los inconvenientes de suplantar el SDLC con el desarrollo de
prototipos se tiene que el S.I. puede conformarse de manera
prematura. El uso de prototipos como alternativa puede inducir que
ciertos grupos de usuarios lo acepten, a pesar de ser inadecuado para
las necesidades globales del sistema.
Los prototipos como complemento del ciclo de vida del desarrollo
de sistemas
Este enfoque consiste en desarrollar prototipos como parte del SDLC.
Aquí se considera al desarrollo de prototipos como un método
especializado para solucionar ciertos requerimientos de información
del usuario.
Los prototipos nos permiten hacer planteamientos de necesidades de
información más allá de los verbales entregados por los usuarios.
Cuando se hace uso de ellos, complementando las otras técnicas de
recopilación de información, reforzamos el compromiso del analista
para relacionarse con el usuario en cada una de las etapas de análisis
y diseño de sistemas.
8
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
La determinación de los requerimientos de información puede
satisfacerse con el desarrollo de prototipos, cuando éstos se
incorporan al SDLC. El analista puede incorporar de manera activa al
usuario en la determinación de sus requerimientos.
Cuando el desarrollo de prototipos se añade al ciclo de desarrollo de
sistemas, en lugar de desarrollarse en etapas discretas, cada una de
las fases del SDLC se llevan a cabo en varias interacciones hasta que
el analista y los usuarios acuerdan que el sistema está completo.
Desventajas de los prototipos
Como cualquier otra técnica de recopilación de información, los
prototipos cuentan con varias desventajas. La primera es que su
administración llega a ser difícil como un proyecto de desarrollo de
prototipos, dentro de un gran esfuerzo de sistemas. Otra desventaja es
que tanto los usuarios como los analistas pueden considerar el
prototipo como un sistema concluido, cuando de hecho no lo es, y
nunca se planteó como un sistema final.
El analista necesita ponderar éstos inconvenientes contra las ventajas
conocidas, al decidir si hace uso de los prototipos, cuándo
desarrollarlos, y qué proporción del sistema será desarrollada como
prototipo.
HERRAMIENTAS DE MODELADO
Importancia del uso de Herramientas de modelado.
Gran parte de la labor del Analista involucra el Modelado del Sistema
que desea el Usuario. Los Modelos del Análisis de Sistemas son
“Modelos en Papel” del futuro sistema, es decir representaciones
abstractas de lo que al final será una combinación de hardware y
software de computadora.
El término “Modelo” pudiera parecer algo formal y atemorizante pero
representa un concepto que se maneja cotidianamente. Por ejemplo:
Los mapas: Son modelos bidimensionales de nuestro mundo.
Los globos terráqueos: Son modelos tridimensionales.
Ahora ¿por qué construimos Modelos?. ¿Por qué no se construye
simplemente el sistema mismo?. Las razones por las cuales el Analista
hace uso de herramientas de Modelado son:
Para concentrarse en las propiedades importantes del Sistema y al
mismo tiempo restar atención a otras menos importantes.
Para discutir cambios y correcciones de los requerimientos del
Usuario, a bajo costo y con el riesgo mínimo; ya que si el Analista se
da cuenta de que su comprensión de los requerimientos del Usuario
no fue la correcta (o de que el Usuario cambió de parecer acerca de
sus requerimientos) puede hacer cambios en el Modelo o desecharlo
y hacer uno nuevo de ser necesario.
Para verificar que el Analista comprende correctamente el ambiente
del Usuario que lo haya respaldado con información documental para
9
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
que los diseñadores de Sistemas y los Programadores puedan
construir el Sistema.
Sin embargo, no todas las herramientas de Modelado cumplen con
estos propósitos por ejemplo: una descripción narrativa de 500
páginas de los requerimientos del Usuario podría:
• Contribuir a obscurecer todas las propiedades del Sistema.
• Costar más en su elaboración que el Sistema mismo.
• No verificar si el Analista comprendió o no las necesidades
reales del Usuario.
Cualquier herramienta de modelado que use debe tener las siguientes
características:
DEBE SER GRÁFICA, CON DETALLES TEXTUALES DE APOYO APROPIADOS: no
es requisito usar gráficas, pero hay que tener en cuenta que “una
imagen vale más que mil palabras”, una imagen bien escogida puede
transmitir de manera concisa y compacta una gran cantidad de
información. Se utilizan para identificar los componentes de un sistema
y su interfaz, todos los demás detalles se presentan en documentos
textuales de apoyo, especificaciones de proceso y el diccionario de
datos.
DEBE
PERMITIR QUE EL SISTEMA SEA VISTO EN SEGMENTOS, EN FORMA
DESCENDENTE: deben permitir mostrar partes individuales del sistema
de manera independiente, junto con una forma sencilla de moverse de
una parte a otra del modelo del sistema, de manera descendente un
sistema de información proporciona un mecanismo conveniente para
pasar tranquilamente de un nivel alto a uno bajo.
DEBE TENER REDUNDANCIA MÍNIMA: importa esto porque es deseable
mantenerlo en forma actualizada y precisa. Si el sistema cambia,
entonces debe cambiar el modelo, si ha de tenerse actualizado, si
cambia un aspecto local del sistema, preferiríamos cambiar sólo un
aspecto local del modelo sin tener que cambiar algún otro.
DEBE AYUDAR AL LECTOR A PREDECIR EL COMPORTAMIENTO DEL SISTEMA.
DEBE SER TRANSPARENTE PARA EL LECTOR: un buen modelo debe ser tan
fácil de leer que el lector no tenga que detenerse a pensar siquiera
que se trata de la representación de un sistema y no del sistema
mismo.
Principales Tipos de Herramientas de Modelado:
Existen varias herramientas de Modelado de Sistemas pero las mas
importantes son las siguientes:
• El Diagrama de Flujo de Datos.
• El Diagrama de Entidad - Relación.
• El Diagrama de Transición de Estados.
10
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
DIAGRAMA DE FLUJO DE DATOS
Es una herramienta que permite visualizar un sistema como una red
de procesos funcionales, conectados entre si por conductos y tanques
de almacenamiento de datos.
Componentes del DFD:
PROCESO: Es equivalente a una FUNCIÓN o
TRANSFORMACIÓN. Muestra una parte del sistema
que convierte entradas en salidas. Se nombran mediante
frases VERBO + OBJETO. Ej: VALIDAR PEDIDO.
FLUJO: Describen el movimiento de paquetes o bloques
de información de una parte del sistema a otra.
Representan datos en Movimiento ( a diferencia de los Almacenes).
Pueden representar también Materiales Físicos.
ALMACÉN: Modela una colección de datos en reposo.
Generalmente se nombran con el plural de las etiquetas
de los paquetes que entran o salen de ellos.
TERMINADOR: Representan entidades externas con las
cuales el sistema se comunica. Suelen ser personas,
grupos u otros departamentos de la empresa. Son
externos al sistema que se está modelando. Las
relaciones entre los terminadores no se muestran en el modelo del
DFD.
Guía para la construcción de un DFD:
Reglas que ayudarán para no elaborar un DFD incompleto o
lógicamente inconsistente y que se dibuje un DFD grato a la vista:
• Escoger nombres con significado para los procesos, flujos,
almacenes y terminadores: es importante etiquetar con precisión
el proceso, de modo que quienes leen el DFD puedan confirmar
que se trata de un modelo preciso. Si el proceso lo hace una
sola persona se recomienda identificar el papel o función que la
persona está representando y no su identidad o nombre (podría
ser reemplazado, podría realizar diversas tareas en el sistema o
puede atraer la atención hacia la manera en la que realiza la
labor dada).
• Numerar los procesos: es una forma conveniente de referirse a
los procesos, no importa mucho cómo se haga esto, mientras
haya constancia en la forma de aplicar los números. El modelo
de DFD es una red asincrónica que se intercomunican. Pues se
numeran los procesos para hacer referencia a los procesos de
manera mas conveniente cuando se discute sobre un DFD (
decir burbuja 1 es más fácil que EDITAR TRANSACCIONES Y
REPORTAR ERRORES), y es más importante el hecho de que los
11
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
números se convierten en base para la numeración jerárquica
cuando se introduzcan los diagramas de flujo por niveles.
• Redibujar el DFD tantas veces como sea necesario
estéticamente: tendrá que dibujarse y volverse a dibujar, a
menudo hasta 10 veces o más antes de ser técnicamente
correcto, ser aceptable para el usuario y estar lo suficientemente
bien dibujado como para que no sea embarazoso mostrarlo a la
dirección de la organización.
• Evite los DFD excesivamente complejos: esto significa que el
diagrama debe ser fácilmente entendido, asimilado y placentero
a la vista, una regla principal es que el DFD debe caber
cómodamente en una hoja normal.
• Asegurarse de que el DFD sea internamente consistente y que
también lo sea con cualesquiera DFD relacionado con él: evitar
burbujas que tengan entradas pero no salidas, evitar burbujas de
generación espontánea, que tienen salidas sin tener entradas,
tenga cuidado con los flujos y procesos no etiquetados, tenga
cuidado con los almacenes de solo lectura o solo escritura
(deben tener entrada tanto como salida, excepto los externos
que sirven de interfaz entre el sistema y algún terminador
externo).
DFD por niveles:
Es organizar el DFD global en una serie de niveles de modo que cada
uno proporcione sucesivamente más detalles sobre una porción de l
nivel anterior.
El DFD del primer nivel consta sólo de una burbuja, que representa el
sistema completo, los flujos de datos muestran las interfaces entre el
sistema y los terminadores externos, junto con los almacenes externos
que puedan haber. El DFD que sigue del diagrama de contexto se
conoce como la figura 0, representa la vista de más alto nivel de las
principales funciones del sistema, al igual que sus principales
interfaces, cada una de estas burbujas debiera numerarse para una
referencia conveniente, los números también sirven como una manera
adecuada de relacionar una burbuja con el siguiente nivel del DFD
que la describe más a fondo.
Extensiones del DFD para sistemas de tiempo real:
Se necesita alguna manera de modelar flujos de control, es decir
señales o interrupciones, y se requiere una manera de mostrar
procesos de control, este es, burbujas cuya única labor es coordinar y
sincronizar las actividades de otras burbujas del DFD. Se muestran
gráficamente con líneas punteadas en el DFD.
EL DICCIONARIO DE DATOS
El diccionario de datos es un listado organizado de todos los datos
pertinentes al sistema, con definiciones precisas y rigurosas para que
tanto el usuario como el análisis tengan un entendimiento común de
12
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
todas las entradas, salidas, componentes de almacenes y cálculos
intermedios.
• Define datos haciendo lo siguiente:
• Describe el significado de los flujos y almacenes que se
muestran en los DFD.
• Describe la composición de agregados de paquetes de datos
que se mueven a lo largo de los flujos, es decir paquetes
complejos (domicilio de un cliente) que pueden descomponerse
en unidades más elementales (ciudad, estado y código postal).
• Describen la composición de los paquetes de datos en los
almacenes.
• Especifica los valores y unidades relevantes de piezas
elementales de información en los flujos de datos y en los
almacenes de datos.
• Describe los detalles de las relaciones entre almacenes que se
enfatizan en un diagrama de entedad-relación.
La necesidad de la notación en el diccionario de datos:
En la mayoría de los sistemas en los que se trabaja, los paquetes de
datos o elementos de datos, serán lo suficientemente complejos como
para necesitar describirlos en términos de otras cosas. Los elementos
complejos de datos se definen en términos de elementos más
sencillos, y los sencillos en términos de los valores y unidades
legítimos que pueden asumir. Se vuelve algo tedioso describir la
composición de los elementos de datos en una forma narrativa.
Necesitamos una notación concisa y compacta (como los diccionarios
normales de palabras ordinarias).
Notación del diccionario de datos:
Existen muchos esquemas, uno de los más comunes y que
utiliza varios símbolos sencillos es:
está compuesto de
=
y
+
( ) optativo (puede estar presente o ausente)
{ } iteración
[ ] seleccionar una de varias alternativas
* * comentario
@ identificador (campo clave) para un almacén
separa opciones alternativas en la construcción
|
Ejemplos:
nombre = titulo de cortesía + nombre + (segundo nombre) +
apellido
titulo de cortesía =
[ Sr. | Srita. | Sra. | Dr. | Profesor ]
nombre =
{ caracter legal}
segundo nombre =
{ caracter legal}
apellido =
{caracter legal}
caracter legal = [ A - Z | a - z | 0 - 9 | ‘ | - | | ]
13
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Para definir un dato se introduce con el símbolo = , y se lee se
“define como o significa”. Por ejemplo: A= A+B, para definir por
completo un dato, debe incluir el significado del dato dentro del
contexto de la aplicación del este usuario, usando la notación * * ;
debe incluir la composición del dato, si se compone de partes
elementales con significado; también los valores que puede tomar el
dato. Por ejemplo:
peso =
*peso del paciente al ser admitido al hospital*
*unidades: Kilogramos; gama 1-200*
estatura = *estatura del paciente al ser admitido al hospital*
*unidades: centímetros; escala: 20-200*
Hay términos que se definen solos, es decir , cuyos significado
es universal para todos los sistemas de información, o que no se
necesitan aclarar más, en estos casos no se necesita un comentario
narrativo, se puede usar la notación * * para indicar sin comentarios
cuando estos datos se definan solos. Por ejemplo:
peso actual =
**
*unidades: libras; escala: 1-400*
sexo =
**
*valores: [ M | F ]*
La notación de iteración se usa para indicar la ocurrencia de un
componente de un dato, se lee como cero o más ocurrencias de , en
muchas ocasiones se querrá indicar los límites inferior y superior de la
iteración. Es correcto especificar sólo el límite inferior, sólo el superior,
ambos, o ninguno, esto se puede indicar así:
a = 1 {b} ; a = {b} 10 ; a = 1 {b} 10 ; a = {b} .
Otro ejemplo:
solicitud = nombre del cliente + domicilio de envío + 1 { artículos } 10
El alias, es una alternativa de nombre para un dato, cuando se insiste
en utilizar nombres distintos para decir lo mismo, el alias se incluye en
el diccionario de datos para que esté completo, y se relaciona con
nombres primarios u oficial del dato. Por ejemplo:
comprador =
* alias de cliente *
Como mostrar el diccionario de datos:
El diccionario de datos lo crea el analista durante el desarrollo del
modelo del sistema, pero el usuario debe ser capaz del leerlo y
entenderlo para poder verificar el modelo.
“CONSTRUIR UN DICCIONARIO DE DATOS ES UNA DE LAS LABORES MÁS
TEDIOSAS, Y LARGAS, DEL ANALISIS DE SISTEMAS. PERO TAMBIÉN ES UNA DE
LAS MÁS IMPORTANTES: SIN UN DICCIONARIO FORMAL QUE DEFINA EL
SIGNIFICADO DE LOS TÉRMINOS, NO SE PUEDE ESPERAR PRECISIÓN”.
14
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
ESPECIFICACIONES DE PROCESO
Es la descripción de qué sucede en cada burbuja primitiva de nivel
más bajo en un diagrama de flujo de datos. Define lo que debe
hacerse para transformar entradas en salidas, es una descripción
detallada de política de negocios del usuario que cada burbuja lleva a
cabo.
Existe una variedad de herramientas que podemos utilizar para
producir una especificación de proceso: tablas de decisiones, lenguaje
estructurado (español, inglés, etc.), pre/post - condiciones, diagramas
de flujo, diagramas de Nasse / Shneiderman, etc. Se puede usar
cualquier método mientras cumpla dos requisitos cruciales:
La especificación del proceso debe expresarse de una manera que
puedan verificar tanto el usuario como el analista. (razón pro la cual se
evita el lenguaje narrativo ya que es ambiguo).
El proceso debe especificarse en una forma que pueda ser
comunicada efectivamente al público amplio que esté involucrado.
Se puede agregar esta tercera : No debe imponer o implicar
decisiones de diseño e implantación arbitrarias. El trabajo como
analista consiste en destilar de esto la esencia de lo que se trate una
política y no cómo se lleva a cabo hoy en día.
Las especificaciones de proceso sólo se desarrollan para los procesos
de más bajo nivel en un conjunto de diagramas por niveles en un DFD.
Las tres herramientas principales de especificación de proceso son:
Lenguaje estructurado (español, inglés, etc.)
Pre/post condiciones
Tablas de decisión
Lenguaje estructurado:
Es un subconjunto de todo el idioma con importantes restricciones
sobre el tipo de frases que pueden utilizarse y la manera en que
pueden juntarse dichas frases. Su propósito es hacer un balance
razonable entre la precisión del lenguaje formal de programación y la
informalidad del lenguaje cotidiano. Por ejemplo, una frase puede ser
una ecuación algebraica como X = ( Y*Z ) / ( Q + 14 ) o una frase
imperativa que consista en un verbo y un objeto como por ejemplo
CALCULAR X = ( Y * Z ) / ( Q + 14 ).
El lenguaje estructurado permite que se combinen frases en unas
cuantas formas limitadas que se toman de las construcciones
acostumbradas de la programación estructurada.
La construcción SI-ENTONCES-OTRO se utiliza para describir frases
alternativas que se deben realizar según el resultado de la decisión
binaria. Ejemplo:
SI condición-1
SI edad-del-cliente es mayor que 65 frase-1
OTRO
fijar cuota a cuota-ancianos
frase-2
OTRO
FIN SI
fijar cuota a cuota-normal
FIN SI
15
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
La construcción CASO se utiliza par describir frases alternativas que
se efectuarán basándose en los resultados de una decisión
multivaluada. Ejemplo:
HACER CASO
HACER CASO
CASO variable = valor-1
CASO edad-del-cliente < 13
frase-1
fijar cuota a cuota-niños
CASO edad-del-cliente >12 y edad-del-cliente < 20 CASO variable = valor-n
fijar cuota a cuota-adolescente
CASO edad-del-cliente > 19 y edad-del-cliente < 65frase-n
OTRO
fijar cuota a cuota-adultos
frase-n+1
OTRO
fijar cuota a cuota-ancianos
FIN CASO
FIN CASO
La construcción HACER-MIENTRAS se usa para describir una frase
que deberá llevarse a cabo repetitivamente hasta que alguna
condición booleana se haga verdadera. Ejemplo:
HACER-MIENTRAS haya más artículos en el pedido-del-cliente
precio-extendido = precio-unitario * cantidad-de-unidades
FIN HACER
HACER -MIENTRAS condición-1
frase-1
FIN HACER
Otra estructura es REPITE-HASTA , que ejecuta una frase
especificada por lo menos una vez antes de hacer una prueba para
ver si debe repetirse.
Ejemplo:
REPITE
frase-1
HASTA condición-
Se pueden construir frases compuestas a partir de combinaciones de
frases sencillas y las estructuras sencillas que se presentaron
anteriormente.
Pre/post condiciones:
Son una manera conveniente de describir la función que debe realizar
el proceso, sin decir mucho acerca del algoritmo o procedimiento que
se utilizará, es un enfoque útil cuando:
El usuario tiene tendencia a expresar la política llevada a cabo por la
burbuja en términos de un algoritmo particular que ha estado utilizando
durante décadas.
El analista está razonablemente seguro de que existen muchos
algoritmos distintos que podrían usarse.
16
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
El analista desea que el programador explore varios de estos
algoritmos pero no quiere involucrarse personalmente con tales
detalles y, sobre todo, no quiere enredarse en discusiones con el
usuario acerca del mérito relativo de cada uno.
Un ejemplo de especificaciones de proceso escritas con este enfoque
es:
ESPECIFICACIONES DE PROCESO 3.5: CALCULAR EL IMPUESTO
SOBRE VENTAS
Precondición 1
Ocurre DATOS-VENTA con TIPO-ITEM que corresponde con
CATEGORIA-ITEM en CATEGORIAS-IMPUESTO
Postcondición 1
IMPUESTO-SOBRE-VENTA se hace igual a MONTO-VENTA *
IMPUESTO
Precondición 2
Ocurre DATOS-VENTA con TIPO-ITEM que no concuerde con
CATEGORÍA-ITEM en CATEGORIA-IMPUESTO
Postcondición 2
Se genera MENSAJE-ERROR
Las precondiciones describen todas las cosas, si hay, que deben
darse antes de que el proceso pueda comenzar a ejecutarse.
Describen lo siguiente:
Qué entradas se encuentran disponibles
Qué relación debe existir entre las entradas
Qué relaciones deben existir entre entradas y almacenes de datos
Qué relaciones deben existir entre almacenes o dentro de un almacén
dado
Las postcondiciones describen que debe darse cuando el proceso ha
concluido. Describen lo siguientes:
Las salidas que generará o producirá el proceso
Las relaciones que existirán entre los valores de salida y los valores
originales de entrada
Las relaciones que existirán entre valores de salida y los valores en
uno o varios de los almacenes
Los cambios que se hayan dado en los almacenes
Tablas de decisión:
Si el proceso debe producir alguna salida o tomar alguna acción
basada en decisiones complejas es preferible una tabla de decisiones,
si las decisiones se basan en diversas variables distintas, por ejemplo:
datos de entrada, y si dichas variables pueden tomar diversos valores,
entonces la lógica expresada por el lenguaje estructurado o por las
pre/post condiciones probablemente sea tan compleja que el usuario
no la comprenderá.
Una tabla de decisiones se crea listando todas las variables relevantes
o entradas y todas las acciones relevantes en su lado izquierdo, las
variables y acciones están separadas por una línea horizontal gruesa,
a continuación se lista en columnas separadas cada combinación
posible de valores de las variables, cada columna usualmente se
17
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
conoce como regla. Una regla describe una acción o acciones que
deben llevarse a cabo para una combinación específica de valores de
las variables.
Edad > 21
Sexo
Peso < 100
Medicamento 1
Medicamento 2
Medicamento 3
Ningún medicamento
1
Y
M
Y
X
2
Y
M
N
3
Y
F
Y
4
Y
F
N
X
X
5
N
M
Y
X
X
6
N
M
N
7
N
F
Y
X
X
8
N
F
N
X
X
X
Deben discutirse cada regla con el usuario para asegurarse que se ha
identificado la acción o acciones correctas para cada combinación de
variables. La ventaja del enfoque de la tabla de decisiones es que el
analista se puede concentrar en una regla a la vez, y también la tabla
de decisiones tiene la ventaja de que no implica ninguna forma
particular de implantación, o sea hay una tremenda libertad de
elección en términos de estrategia de implantación.
DIAGRAMAS DE ENTIDAD-RELACIÓN
Es un modelo de red que describe con un alto nivel de abstracción la
distribución de datos almacenados en un sistema. Es importante
modelar los datos de un sistema porque las estructuras de datos y las
relaciones pueden ser tan complejas que se deseara enfatizarlas y
examinarlas independientemente del proceso que se llevará a cabo.
Esto se da si mostramos el modelo del sistema a los usuarios
ejecutivos de mayor nivel en una organización, quienes podrían no
estar interesados en los detalles funcionales cotidianos del sistema,
tales usuarios a menudo se preocupan más por los datos que se
requieren para manejar su negocio, quién los tiene y quién tiene
acceso a ellos.
Los componentes de un DER:
TIPOS DE OBJETOS: Representa una colección o
conjunto de cosas cuyos miembros individuales: pueden
identificarse de una manera única por algún medio;
juegan un papel necesario dentro del sistema, pueden describirse por
uno o mas datos. El objeto es algo material y el tipo de objeto es su
representación en el sistema. Se denotan usando un Sustantivo
Singular Ej: CLIENTE, COMPRA, ARTICULO, etc.
RELACIONES: Representan conjunto de conexiones
entre objetos. Cada instancia de la relación representa
una asociación entre cero o más ocurrencias de un
objeto y cero o más ocurrencias del otro. Una relación puede conectar
dos o más instancias del mismo objeto.
18
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Ejemplo:
CLIENTE
Coloca
PEDIDO
Recibe
FACTURA
Genera
EDITOR
ORDEN
DE
COMPRA
Recibe
DIAGRAMA DE TRANSICIÓN DE ESTADOS
Es el que enfatiza el comportamiento dependiente del tiempo del
sistema (sistemas de tiempo-real).
Notación de los DTE:
Los principales componentes son Estados y Flechas que representan
los Cambios de Estado.
ESTADOS del sistema:
Cada rectángulo representa un estado en el que se puede encontrar el
sistema, un estado es un conjunto de circunstancias o atributos que
caracterizan a una persona o cosas en un tiempo dado, forma de ser,
condición.
Los cambios de estados válidos se muestran conectando pares
relevantes de estados con una flecha. Cualquier estado puede llevar
un número arbitrario de estados sucesores.
La mayoría de los sistemas tienen un estado inicial reconocible y un
estado final reconocible. El estado inicial típicamente suele se el que
se dibuja en la parte superior del diagrama (no es obligatorio que así
sea) lo identifica la flecha “desnuda” no conectada a otro estado, el
estado final suele ser el que se dibuja en la parte inferior pero tampoco
eso es obligatorio, lo que lo identifica es la ausencia de una flecha que
salga de él. Un sistema puede tener un solo estado inicial pero puede
tener múltiples estados finales.
Las condiciones que causan un cambio de estado y las acciones que
el sistema toma cuando cambia se muestran junto a la flecha que
conecta dos estados relacionados.
Diagramas particionados:
En un sistema complejo pueden haber docenas de estados distintos
del sistema, tratar de ponerlos todos en un mismo diagrama sería
difícil, si no imposible. Por lo tanto se puede usar las particiones con
los DTE.
19
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Construcción del diagrama de transición de estados:
Puede seguirse dos enfoques:
• Se puede comenzar por identificar todos los posibles estados del
sistema y representar cada uno por separado en una hoja de
papel y luego se pueden explorar todas las conexiones con
significado entre las cajas (cambios de estados).
• Se puede comenzar por el estado inicial y luego metódicamente
ir siguiendo un camino hasta el o los restantes, luego del o los
estados secundarios, proseguir a los terciarios, etc.
Cuando termine de construir el DTE preliminar deben seguirse las
siguientes reglas de para verificar la consistencia:
• ¿Se han definido todos los estados?
• ¿Se pueden alcanzar todos los estados? ¿Se han definido
estados que no tengan cominos que lleven a ellos?
• ¿Se puede salir de todos los estados? no los finales pero todos
los demás estados deben tener un sucesor.
• En cada estado ¿el sistema responde adecuadamente a todas
las condiciones posibles? ocurren condiciones normales,
condiciones inesperadas.
Ejemplo:
Tarjeta Ingresada
ESPERANDO
TARJETA
Solicita “Contraseña”
Contraseña Ingresada
ESPERANDO
PASSWORD
Cancela o Contraseña Erronea
Solicita Selección Función
Selección Extraccion
Expulsion de Tarjeta
ESPERANDO
ELECCION
Cancela
Expulsion de Tarjeta
EXTRACCION
CONSULTAS
DEPOSITOS
Solicita Importe
ESPERANDO
IMPORTE
Importe Ingresado
Mensaje “Esperar”
Cancela Operación
DANDO
EFECTIVO
Borrado de Pantalla
Efectivo Disponible
Mensaje “Retirar” ESPERANDO EL
RETIRO
Ejectivo Retirado
Borrado de Pantalla
20
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Relación del DTE con los demás componentes del modelo:
El DTE puede usarse por si solo como herramienta de modelado. Sin
embargo puede y en general debiera ser utilizado en conjunto con
otras herramientas. El DTE representa una especificación de proceso
para una burbuja de control en un DFD.
El Diagrama de Estructuras
El Analista de Sistema debe estar al tanto de que se utilizan muchas
herramientas de modelado adicionales durante la creación de un
sistema complejo. Por ejemplo, los diseñadores de Sistema suelen
utilizar:
•
•
•
•
•
Diagramas de Flujo de Datos
Diccionarios de Datos
Especificaciones de Procesos
Diagramas de Entidad – Relación y
Diagramas de transición de Estados,
Creados por el Analista para crear una arquitectura de software, es
decir, una jerarquía de Módulos (los que a veces se conocen como
subrutinas o procedimientos) para realizar los requerimientos del
Sistema.
Una herramienta gráfica de Modelado comúnmente utilizada
para representar tal jerarquía de software es el Diagrama de
Estructuras.
En este diagrama, cada rectángulo representa un Módulo (por ejemplo
una subrutina de FORTRAN, un procedimiento de Pascal o un párrafo
o subprograma de Cobol).
Las flechas que conectan los rectángulos representan las
invocaciones de Módulos (por ejemplo, llamados de subrutinas o
llamados de procedimientos).
El Diagrama también muestra los parámetros de entrada que se le dan
a cada módulo invocado y los parámetros de salida devueltos por cada
módulo cuando termina su labor y le devuelve el control al que lo
llama.
A pesar de que el Diagrama de Estructuras es una herramienta
excelente para los diseñadores de Sistemas, no es el tipo de modelo
que normalmente se mostraría al Usuario, pues modela un aspecto de
la implantación del Sistema, no de sus requerimientos.
Dado que algunos Usuarios saben más que otros de computadoras, y
algunos Usuarios desempeñan un papel más activo en los Proyectos
de Desarrollo de Sistemas que otros. Si está trabajando con un
Usuario que es miembro de tiempo completo del equipo del Proyecto,
o tal vez incluso si es el jefe de Proyecto, y si es conocedor del diseño
de Sistemas, no hay razón por la que no deba mostrarle un Diagrama
de Estructuras.
21
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Sin embargo si el usuario sólo se interesa por describir qué tiene que
hacer el Sistema, probablemente no le interese ver un diagrama que
describa la organización de las subrutinas de FORTRAN que cubrirán
dichos requisitos.
BALANCEO DE MODELOS
Una especificación estructurada se dice que está balanceada cuando
todas las herramientas se han verificado entre si para asegurar su
consistencia.
Balanceo del DFD y el DD
Las reglas son:
• Cada flujo de datos (flechas del DFD) y cada almacén de datos
deben estar definidos en el diccionario de datos.
• De manera inversa, cada dato y cada almacén que se define en
el diccionario de datos debe aparecer en alguna parte del DFD,
si no es un fantasma (algo definido que no se usa).
Esto significa desde luego que el analista debe revisar tanto el DFD
como el diccionario cuidadosamente para asegurarse de que estén
balanceados.
Balanceo del DFD y la ESPECIFICACIÓN DE PROCESO
Las reglas son:
• Cada burbuja del DFD debe asociarse con un DFD de nivel
inferior o con una especificación de procesos, pero no ambos, ya
que el modelo sería innecesario, redundante.
• Cada especificación de proceso debe tener una burbuja de nivel
inferior asociada en el DFD.
• Las entradas y salidas deben coincidir. En DFD y deben ser
evidentes en las especificaciones de procesos.
Estos comentarios se aplican específicamente a las burbujas de
proceso, para las burbujas de control en un DFD corresponden los
DTE.
Balanceo de ESPECIFICACIONES DE PROCESO CON EL DFD y
el DD
Cada referencia de un dato en las especificaciones de proceso debe
seguir una de las siguientes reglas:
• Coincide con el nombre de un flujo de datos o almacén
conectado a la burbuja descripta por la especificación de
procesos, o
• Es un terminador local, definido explícitamente en la
especificación de proceso, o
• Aparece como componente en una entrada del diccionario de
datos par un flujo o almacén conectado con la burbuja.
22
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Balanceo del DD con el DFD y las ESPECIFICACIONES DEL
PROCESO
El DD es consistente si obedece la siguiente regla:
• Cada entrada del diccionario de datos debe tener referencias en
una especificación de proceso, un DFD, u otro DD.
Balanceo del DER con el DFD y las ESPECIFICACIONES DE
PROCESO
El DER tiene una visión muy distinta que el DFD, pero deben darse
una serie de relaciones para que el sistema sea global, completo,
correcto y consistente:
• Cada almacén del DFD debe corresponder con un tipo de objeto,
una relación o una combinación de un tipo y una relación, es
decir un tipo asociativo de objeto, en el DER.
• Los nombres de objetos en el DER y los nombres de almacenes
de datos en el DFD deben coincidir.
• Las entradas del diccionario de datos deben aplicarse tanto al
modelo del DFD como al de DER.
Las reglas que aseguran que el DER sea consistente con la porción de
especificaciones de proceso del modelo orientado a las funciones son:
que el conjunto combinado de todas las especificaciones de proceso
deben en su totalidad:
Crear y eliminar instancias de cada tipo de objeto y relación que se
muestra en el DER.
Alguna burbuja del DFD define valores para cada dato asignado a
cada instancia de cada tipo de objeto, y de algún proceso del DFD usa
o lee valores de cada dato.
Balanceo del DFD y el DTE
Las reglas son:
• Cada burbuja de control del DFD se asocia con un DTE como su
especificación de proceso, de manera similar cada DTE en el
modelo global del sistema debe asociarse con una burbuja o
proceso de control del DFD.
• Cada condición del DTE debe corresponder con un flujo de datos
de entrada al proceso de control asociado con el DTE. (y al
revés).
• Cada acción en el DTE debe corresponder con un flujo de
control de salida del proceso de control asociado con dicho
diagrama. (y al revés).
23
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
HERRAMIENTAS ADICIONALES DE MODELADO
Las herramientas de modelado deben ser suficientes para cualquier
proyecto en el que trabaje. Sin embargo, debe también familiarizarse
con algunas herramientas adicionales, que pueden ser las siguientes:
•
•
•
•
•
Diagrama de flujo y sus variantes.
Diagrama de flujo de sistema.
Diagramas HIPO y diagramas de estructura.
Variantes de los diagramas de flujo de datos.
Variantes de los diagramas de entidad-relación.
Diagrama de flujo y sus variantes
El diagrama clásico de flujo
Es una de las primeras y más
conocidas de las herramientas.
Este tiene componentes como:
El cuadro, que representa una
instrucción ejecutable o una
secuencia
contigua
de
instrucciones de la computadora.
El rombo representa una decisión.
Las flechas que conectan los
cuadros representan los flujos de
control.
Como puede verse, el diagrama de flujo permite representar
gráficamente la lógica de procedimiento de un programa de
computadora.
Variantes de los diagramas de flujo
Existen variantes que se deben conocer:
•
•
•
•
Diagrama de Nassi-Shneiderman
Diagrama de Ferstl
Diagrama de Hamilton-Zeldin
Diagrama de análisis de problemas
Diagramas de Nassi-Shneiderman (diagramas de Chapin)
Se introdujeron como forma de obligar a un enfoque estricto de
programación estructurada. Es fácil de leer. Se podría argumentar que
los diagramas de Nassi-Shneiderman son sólo declaraciones del
lenguaje estructurado encerradas en cuadros.
24
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Obtener registro maestro
Obtener registro de transacciones
HACER MIENTRAS haya más transacciones
O haya más registros maestros
¿maestro=transacción?
Verdadero
Falso
Actualizar maestro
Maestro < transacción
Escribir maestro
verdadero
Falso
Obtener nuevo maestro
Escribir
Imprimir error
maestro
Obtener
nuevas Obtener
Obtener
transacciones
maestro
transacciones
Cerrar archivo maestro
Cerrar archivo de transacciones
Diagrama de Ferstl
En él se proporciona una descripción completa. Además de mostrar la
lógica normal y secuencial del programa, el diagrama de Ferstl puede
Intercambiar
usarse para mostrar procesos en paralelo
ARTÍCULOS
NEXCH=NEXCH+1
NEXCH=0
ARTÍCULO (I)
>ARTÍCULO (I+1)
Ordenar
arreglos de
artículos
NEXCH=0
I=número
De
ARTÍCULOS
Menos 1
Diagrama de Hamilton-Zeldin
Los rectángulos tienen el mismo significado que los diagramas de flujo
ANSI: una declaración ejecutable o un grupo de declaraciones
ejecutables contiguas. Un pentágono alargado se usa para mostrar
tanto las declaraciones SI como las iteraciones HACER-MIENTRAS/
REPITE-HASTA.
Diagramas de análisis de problemas (PAD)
Son una representación bidimensional y arborescente de la lógica de
programas. Los PAD se leen de arriba abajo, y las construcciones SI
se muestran de izquierda a derecha. Un PAD también puede mostrar
procesos en paralelo, también usa una combinación de despliegue
vertical de flujo secuencial con despliegue horizontal de niveles.
25
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
INGENIERÍA DEL SOFTWARE
El desarrollo de sistemas de software complejos no es una actividad
trivial, que pueda abordarse sin una preparación previa. El considerar
que un proyecto de desarrollo de software podía abordarse como
cualquier otro ha llevado a una serie de problemas que limitan nuestra
capacidad de aprovechar los recursos que el hardware pone a nuestra
disposición.
Los problemas tradicionales en el desarrollo de software no van a
desaparecer de la noche a la mañana, pero identificarlos y conocer
sus causas es el único método que nos puede llevar hacia su solución.
No existe una fórmula mágica para solucionar estos problemas, pero
combinando métodos aplicables a cada una de las fases del desarrollo
de software, construyendo herramientas para automatizar estos
métodos, utilizando técnicas para garantizar la calidad de los
productos desarrollados y coordinando todas las personas
involucradas en el desarrollo de un proyecto, podremos avanzar
mucho en la solución de estos problemas. De ello se encarga la
disciplina llamada Ingeniería del Software.
Una de las primeras definiciones que se dio de la ingeniería del
software es la siguiente: El establecimiento y uso de principios de
ingeniería robustos, orientados a obtener software económico, que sea
fiable y funcione de manera eficiente sobre máquinas reales.
La ingeniería del software abarca un conjunto de tres elementos clave:
métodos, herramientas y procedimientos, que faciliten al gestor el
control el proceso de desarrollo y suministren a los implementadores
bases para construir de forma productiva software de alta calidad.
Los métodos indican cómo construir técnicamente el software, y
abarcan una amplia serie de tareas que incluyen la planificación y
estimación de proyectos, el análisis de requisitos, el diseño de
estructuras de datos, programas y procedimientos, la codificación, las
pruebas y el mantenimiento. Los métodos introducen frecuentemente
una notación específica para la tarea en cuestión y una serie de
criterios de calidad.
Las herramientas proporcionan un soporte automático o
semiautomático para utilizar los métodos. Existen herramientas
automatizadas para cada una de las fases vistas anteriormente, y
sistemas que integran las herramientas de cada fase de forma que
sirven para todo el proceso de desarrollo. Estas herramientas se
denominan CASE (Computer Assisted Software Engineering).
Los procedimientos definen la secuencia en que se aplican los
métodos, los documentos que se requieren, los controles que permiten
asegurar la calidad y las directrices que permiten a los gestores
evaluar los progresos.
26
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Concepto de ciclo de vida.
Por ciclo de vida, se entiende la sucesión de etapas por las que pasa
el software desde que un nuevo proyecto es concebido hasta que se
deja de usar.
Cada una de estas etapas lleva asociada una serie de tareas que
deben realizarse, y una serie de documentos (en sentido amplio:
software) que serán la salida de cada una de estas fases y servirán de
entrada en la fase siguiente.
Existen diversos modelos de ciclo de vida, es decir, diversas formas de
ver el proceso de desarrollo de software, y cada uno de ellos va
asociado a un paradigma de la ingeniería del software, es decir, a una
serie de métodos, herramientas y procedimientos que debemos usar a
lo largo de un proyecto. En este tema veremos algunos de los
principales modelos de ciclo de vida.
La elección de un paradigma u otro se realiza de acuerdo con la
naturaleza del proyecto y de la aplicación, los métodos a usar y los
controles y entregas requeridos.
El ciclo de vida en cascada (o ciclo de vida clásico).
Este paradigma es el más antiguo de los empleados en la IS y se
desarrolló a partir del ciclo convencional de una ingeniería. No hay que
olvidar que la IS surgió como copia de otras ingenierías,
especialmente de las del hardware, para dar solución a los problemas
más comunes que aparecían al desarrollar sistemas de software
complejos.
Es un ciclo de vida en sentido amplio, que incluye no sólo las etapas
de ingeniería sino toda la vida del producto: las pruebas, el uso (la vida
útil del software) y el mantenimiento, hasta que llega el momento de
sustituirlo.
27
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Ingeniería del
Sistema
Análisis
Diseño
Codificación
Prueba
Utilización
Mantenimiento
Sustitución
El ciclo de vida en cascada exige un enfoque sistemático y secuencial
del desarrollo de software, que comienza en el nivel de la ingeniería de
sistemas y avanza a través de fases secuenciales sucesivas.
Estas fases son las siguientes:
Ingeniería y análisis del sistema.
El software es siempre parte de un sistema mayor, por lo que siempre
va a interrelacionarse con otros elementos, ya sea hardware,
máquinas o personas. Por esto, el primer paso del ciclo de vida de un
proyecto consiste en un análisis de las características y el
comportamiento del sistema del cual el software va a formar parte. En
el caso de que queramos construir un sistema nuevo, por ejemplo un
sistema de control, deberemos analizar cuáles son los requisitos y la
función del sistema, y luego asignaremos un subconjunto de estos
requisitos al software. En el caso de un sistema ya existente
(supongamos, por ejemplo, que queremos informatizar una empresa)
deberemos analizar el funcionamiento de la misma, - las operaciones
que se llevan a cabo en ella -, y asignaremos al software aquellas
funciones que vamos a automatizar.
La ingeniería del sistema comprende, por tanto, los requisitos globales
a nivel del sistema, así como una cierta cantidad de análisis y de
diseño a nivel superior, es decir sin entrar en mucho detalle.
Análisis de requisitos del software.
El análisis de requisitos debe ser más detallado para aquellos
componentes del sistema que vamos a implementar mediante
software. El ingeniero del software debe comprender cuáles son los
datos que se van a manejar, cuál va a ser la función que tiene que
cumplir el software, cuáles son los interfaces requeridos y cuál es el
rendimiento que se espera lograr.
Los requisitos, tanto del sistema como del software deben
documentarse y revisarse con el cliente.
28
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Diseño.
El diseño se aplica a cuatro características distintas del software: la
estructura de los datos, la arquitectura de las aplicaciones, la
estructura interna de los programas y las interfaces.
El diseño es el proceso que traduce los requisitos en una
representación del software de forma que pueda conocerse la
arquitectura, funcionalidad e incluso la calidad del mismo antes de
comenzar la codificación.
Al igual que el análisis, el diseño debe documentarse y forma parte de
la configuración del software (el control de configuraciones es lo que
nos permite realizar cambios en el software de forma controlada y no
traumática para el cliente).
Codificación.
La codificación consiste en la traducción del diseño a un formato que
sea legible para la máquina. Si el diseño es lo suficientemente
detallado, la codificación es relativamente sencilla, y puede hacerse al menos en parte - de forma automática, usando generadores de
código.
Podemos observar que estas primeras fases del ciclo de vida
consisten básicamente en una traducción: en el análisis del sistema,
los requisitos, la función y la estructura de este se traducen a un
documento: el análisis del sistema que está formado en parte por
diagramas y en parte por descripciones en lenguaje natural. En el
análisis de requisitos se profundiza en el estudio del componente
software del sistema y esto se traduce a un documento, también
formado por diagramas y descripciones en lenguaje natural. En el
diseño, los requisitos del software se traducen a una serie de
diagramas que representan la estructura del sistema software, de sus
datos, de sus programas y de sus interfaces. Por último, en la
codificación se traducen estos diagramas de diseño a un lenguaje
fuente, que luego se traduce - se compila - para obtener un programa
ejecutable.
Prueba.
Una vez que ya tenemos el programa ejecutable, comienza la fase de
pruebas. El objetivo es comprobar que no se hayan producido errores
en alguna de las fases de traducción anteriores, especialmente en la
codificación. Para ello deben probarse todas las sentencias, no sólo
los casos normales y todos los módulos que forman parte del sistema.
Utilización.
Una vez superada la fase de pruebas, el software se entrega al cliente
y comienza la vida útil del mismo. La fase de utilización se solapa con
las posteriores - el mantenimiento y la sustitución - y dura hasta que el
software, ya reemplazado por otro, deje de utilizarse.
Mantenimiento.
El software sufrirá cambios a lo largo de su vida útil. Estos cambios
pueden ser debidos a tres causas:
Que, durante la utilización, el cliente detecte errores en el software: los
errores latentes.
29
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Que se produzcan cambios en alguno de los componentes del sistema
informático: por ejemplo cambios en la máquina, en el sistema
operativo o en los periféricos.
Que el cliente requiera modificaciones funcionales (normalmente
ampliaciones) no contempladas en el proyecto.
En cualquier caso, el mantenimiento supone volver atrás en el ciclo de
vida, a las etapas de codificación, diseño o análisis dependiendo de la
magnitud del cambio.
El modelo en cascada, a pesar de ser lineal, contiene flujos que
permiten la vuelta atrás. Así, desde el mantenimiento se vuelve al
análisis, el diseño o la codificación, y también desde cualquier fase se
puede volver a la anterior si se detectan fallos. Estas vueltas atrás no
son controladas, ni quedan explícitas en el modelo, y este es uno de
los problemas que presenta este paradigma
Sustitución.
La vida del software no es ilimitada y cualquier aplicación, por buena
que sea, acaba por ser sustituida por otra más amplia, más rápida o
más bonita y fácil de usar.
La sustitución de un software que está funcionando por otro que acaba
de ser desarrollado es una tarea que hay que planificar
cuidadosamente y que hay que llevar a cabo de forma organizada. Es
conveniente realizarla por fases, si esto es posible, no sustituyendo
todas las aplicaciones de golpe, puesto que la sustitución conlleva
normalmente un aumento de trabajo para los usuarios, que tienen que
acostumbrarse a las nuevas aplicaciones, y también para los
implementadores, que tienen que corregir los errores que aparecen.
Es necesario hacer un trasvase de la información que maneja el
sistema viejo a la estructura y el formato requeridos por el nuevo.
Además, es conveniente mantener los dos sistemas funcionando en
paralelo durante algún tiempo para comprobar que el sistema nuevo
funcione correctamente y para asegurarnos el funcionamiento normal
de la empresa aún en el caso de que el sistema nuevo falle y tenga
que volver a alguna de las fases de desarrollo.
La sustitución implica el desarrollo de programas para la interconexión
de ambos sistemas, el viejo y el nuevo, y para trasvasar la información
entre ambos, evitando la duplicación del trabajo de las personas
encargadas del proceso de datos, durante el tiempo en que ambos
sistemas funcionen en paralelo.
El ciclo de vida en cascada es el paradigma más antiguo, más
conocido y más ampliamente usado en la IS. No obstante, ha sufrido
diversas críticas, debido a los problemas que se plantean al intentar
aplicarlo a determinadas situaciones. Entre estos problemas están:
En realidad los proyectos no siguen un ciclo de vida estrictamente
secuencial como propone el modelo. Siempre hay iteraciones. El
ejemplo más típico es la fase de mantenimiento, que implica siempre
volver a alguna de las fases anteriores, pero también es muy frecuente
en que una fase, por ejemplo el diseño, se detecten errores que
obliguen a volver a la fase anterior, el análisis.
Es difícil que se puedan establecer inicialmente todos los requisitos del
sistema. Normalmente los clientes no tienen conocimiento de la
30
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
importancia de la fase de análisis o bien no han pensado en todo
detalle que es lo que quieren que haga el software. Los requisitos se
van aclarando y refinando a lo largo de todo el proyecto, según se
plantean dudas concretas en el diseño o la codificación. Sin embargo,
el ciclo de vida clásico requiere la definición inicial de todos los
requisitos y no es fácil acomodar en él las incertidumbres que suelen
existir al comienzo de todos los proyectos.
Hasta que se llega a la fase final del desarrollo: la codificación, no se
dispone de una versión operativa del programa. Como la mayor parte
de los errores se detectan cuando el cliente puede probar el programa
no se detectan hasta el final del proyecto, cuando son más costosos
de corregir y más prisa (y más presiones) hay por que el programa se
ponga definitivamente en marcha.
Todos estos problemas son reales, pero de todas formas es mucho
mejor desarrollar software siguiendo el modelo de ciclo de vida en
cascada que hacerlo sin ningún tipo de guías. Además, este modelo
describe una serie de pasos genéricos que son aplicables a cualquier
otro paradigma, refiriéndose la mayor parte de las críticas que recibe a
su carácter secuencial.
31
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
HERRAMIENTAS CASE
Para el desarrollo de sistemas, es decir: análisis, diseño e
implementación de los sistemas de información los analistas de
sistemas deben ser organizados, precisos y completar todo aquello
que realicen. Para ello, en los últimos años han comenzado a utilizar
herramientas de productividad creadas específicamente para mejorar
sus tareas de rutina.
A estos elementos se los denominan: “Tecnologías de Ambientes
Integrados” también conocidos como Instrumentos C.A.S.E.
(Computer Aided Software Engineering Tools).
Los tres principales objetivos que el analista sigue al adoptar las
tecnologías de ambiente integrados son:
• Incrementar la productividad.
• Comunicarse con mayor eficacia con los usuarios.
• Integrar las actividades del Ciclo de Vida de Desarrollo de
Sistemas, desde el principio hasta el final del ciclo.
Incrementar la Productividad:
Medir la productividad de un analista no es sencilla, en especial a
corto plazo. Entonces mientras que las actividades del ciclo de vida se
encuentren en progreso, puede medirse la productividad de los
analistas examinando y comparando el tiempo requerido o
programado para cada conjunto de actividades de un proyecto con el
tiempo que realmente está invirtiendo el analista a través de la
utilización de herramientas C.A.S.E.
En consecuencia, cuando hablamos de la productividad, estamos
hablando de una mejora medible en cantidad y calidad de los
resultados que obtiene el analista con la ayuda de nuevas tecnologías,
comparada con lo que pudiera haber ocurrido posiblemente con
métodos alternativos.
Por ejemplo, el Excelerator permite que el analista (o quien lo use)
dibuje y modifique con facilidad los diagramas. Así el analista puede
ser más productivo reduciendo el tiempo de dibujo manual como las
repetidas correcciones que se realizan a los diagramas.
Por otro lado, un paquete de instrumentos tal como el Excelerator
también mejora la productividad de grupo, ya que permite que los
analistas compartan sin contratiempos el trabajo con otros miembros
del grupo.
Los Instrumentos C.A.S.E. facilitan la interacción entre los miembros
del grupo al permitir que la elaboración de diagramas sea un proceso
dinámico e imperativo y proveen un registro del cambio de opinión de
los grupos, con base en los diagramas de flujo.
32
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Mejoramiento de la Comunicación Analista-Usuario:
Con el fin de que el sistema propuesto llegue a utilizarse, es esencial
que exista una comunicación excelente entre analistas y los usuarios a
lo largo del ciclo de desarrollo de sistemas. Y la forma en que los
analistas pueden mejorar su comunicación con los usuarios es
mediante el uso de diagramas generados por computadoras. Con el
uso de pantallas los clientes pueden ver cómo los DFD u otros
diagramas fueron concebidos o creados. Al observarlos pueden
solicitar correcciones o cambios. Esto último podría requerir mucho
más tiempo que por medio de un sistema manual porque las tareas
manuales de dibujar, reproducir y distribuir toman mucho menos
tiempo, pero tal forma no puede compartirse abiertamente con los
usuarios.
Integración de las Actividades del Ciclo de Vida:
Las actividades de integración son importantes porque capacitan el
analista para que pueda comprender lo que se encuentra dentro de la
perspectiva del sistema. Esto le ayuda a asimilar adecuadamente un
problema, como así también auxiliarlo a percatarse el impacto que
genere cualquier cambio en el desarrollo del sistema.
Las Herramientas C.A.S.E. son especialmente útiles cuando hay la
necesidad de realizar iteraciones o repeticiones de retroalimentación y
modificación a lo largo de una etapa particular del ciclo de vida.
Etapas del Ciclo de Desarrollo de Instrumento CASE en cada una
Sistemas.
de las Etapas.
Identificación
de problemas,
oportunidades y objetivos.
Determinación
de
los
requerimientos de información
Inicio de la elaboración
de
diagramas del plan de proyecto.
Organiza las actividades de
captura de datos mediante el uso
de prototipos.
Análisis de las necesidades del Dibuja diagramas de flujo de
sistema.
datos, desarrollo del diccionario
de datos.
Diseño
del
Sistema Elabora pantallas e informes.
recomendado.
Desarrollo y documentación de Construye
diagramas
de
software.
estructuras y transfiere datos del
diccionario de datos al código del
programador.
Pruebas y mantenimiento del Genera datos de prueba y
sistema.
verifica los datos de las pruebas.
Implementación y evaluación del Uso
de
software
de
sistema.
administración de proyectos para
la evaluación.
33
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
El compromiso del usuario es sumamente importante durante todas
las etapas. La integración de actividades a través del uso de las
tecnologías de ambiente integrado también mejora la comprensión de
los usuarios sobre cómo se encuentran relacionadas cada una de las
etapas del ciclo de vida, así como su interdependencia.
COMPONENTES DE CASE
En general, las herramientas de tipo CASE incluyen los siguientes
cinco componentes: herramientas pata diagramación, un depósito de
información, generadores de interfases, generadores de código y
herramientas de administración. Las actividades de alto nivel reciben
la mayor importancia, aunque ya están apareciendo generadores de
código de bajo nivel.
Herramientas Para Diagramación.
Las herramientas para diagramación dan soporte al análisis y
documentación de los requerimientos de una aplicación. Por lo
general, incluyen facilidades para producir diagramas de flujo de
datos. Como el lector ya sabe, estas herramientas de alto nivel son
esenciales para brindar apoyo a la metodología de análisis
estructurado. Las herramientas CASE incorporan, de manera extensa,
métodos propios del análisis estructurado.
Estas herramientas ofrecen la capacidad de dibujar diagramas y
cartas, además de guardar los detalles en forma interna. Cuando es
necesario realizar cambios, la naturaleza de éstos se describe en el
sistema, el cual puede entonces volver a dibujar todo el diagrama de
manera automática. La capacidad para cambiar y volver a dibujar
elimina una actividad que los analistas encuentran tediosa y poco
deseable.
Depósito Centralizado De Información.
La captura, análisis, procesamiento y distribución de todos los
sistemas de información es asistida por un depósito de información
centralizado o diccionario de datos.(Se hará un uso intercambiable de
los términos depósito de información y diccionario de datos, aunque
los vendedores quizá utilicen uno u otro cuando anuncian sus
productos.) El diccionario contiene detalles sobre los componentes del
sistema, tales como datos, flujo de datos y procesos; asimismo,
también incluye información que describe el volumen y frecuencia de
cada una de las actividades.
Aunque los diccionarios son diseñados para que el acceso a la
información sea sencillo, también incluyen controles y medidas de
protección que preservan la exactitud y consistencia de los detalles del
sistema. El uso de:
• Niveles de autorización,
• Validación de procesos y
• Procedimientos para verificar la consistencia de las
descripciones, asegura que el acceso a las definiciones y las
revisiones hechas a ellas en el depósito de información, ocurran
34
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
en forma apropiada
establecidos.
y
acorde
con
procedimientos
ya
• Generador de Interfases.
Las interfases con el sistema son los medios que permiten a los
usuarios interactuar con una aplicación, ya sea para dar entrada a
información y datos o para recibir información. Los generadores de
interfases ofrecen la capacidad para preparar imitaciones y prototipos
para las interfases con los usuarios. Por lo general, soportan la rápida
creación de menús de demostración para el sistema, de pantallas de
presentación y del formato de los informes.
Los generadores de interfases son un elemento importante para el
desarrollo de prototipos de aplicación, aunque también son de utilidad
para los demás métodos de desarrollo.
Generadores de Código.
Los generadores de código automatizan la preparación de software.
Estos incorporan métodos que permiten convertir las especificaciones
del sistema en código ejecutable.
La generación de código aún no ha sido perfeccionada. Los mejores
generadores de código producen aproximadamente el 75% del código
fuente de una aplicación. El resto debe ser escrito por los
programadores. La codificación manual, que es el nombre que recibe
este proceso, sigue siendo necesaria.
Dado que las herramientas CASE son de propósito general, es decir
no están limitadas a ciertas áreas especificas de aplicación como el
control de procesos de manufactura, análisis de portafolios de
Inversiones o administración de cuentas, resulta que el desafío le
automatizar el proceso de generación de software es sustancial.
Los mayores beneficios se obtienen cuando los generadores de
código se encuentran integrados con un depósito central de
información. Esta combinación alcanza el objetivo de crear un código
que pueda volverse a emplear. Cuando las especificaciones cambian,
se puede volver a generar el código al alimentar los detalles del
diccionario de datos a través del generador de código. El contenido del
diccionario puede emplearse de nuevo para preparar el código
ejecutable.
Herramientas de Administración.
Los sistemas CASE también ayudan a los gerentes de proyecto a
mantener la efectividad y eficiencia de todo el proceso de desarrollo de
una aplicación.
Este componente de CASE ayuda a los gerentes de desarrollo a
calendarizar las actividades de análisis y diseño así como la
asignación de recursos alas diferentes actividades del proyecto. Por
ejemplo, algunos sistemas CASE soportan el seguimiento de los
tiempos de desarrollo de un proyecto y los comparan con los ya
planificados; también realizan la misma labor con la asignación de
35
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
tareas específicas al personal. Los calendarios e informes pueden
preparase utilizando para ello los detalles contenidos en el diccionario
de datos. Algunas herramientas CASE para administración permiten
que los gerentes de proyecto especifiquen elementos de su propia
elección. Por ejemplo, ellos pueden seleccionar los símbolos gráficos
que desean para describir procesos, personas, departamentos, etc.
Otros permiten definir metodologías de desarrollo propias, incluyendo
las reglas de validación y los estándares para datos y nombres de
procedimientos. Sin embargo, la mayor parte de los sistemas CASE
depende en gran medida de la notación, principios y prácticas del
método de análisis estructurado.
Como cualquier tecnología nueva, la adopción de las herramientas
C.A.S.E. tiene Ventajas y Desventajas.
Beneficios de Usar Herramientas CASE.
Facilidad para la revisión de aplicaciones: La experiencia muestra que
una vez que las aplicaciones se implantan, se emplean por mucho
tiempo. Las herramientas CASE proporcionan un beneficio substancial
para las organizaciones al facilitar la revisión de las aplicaciones.
Contar con un depósito central, agiliza el proceso de revisión ya que
éste proporciona bases para las definiciones y estándares para los
datos. Las capacidades de generación interna, si se encuentran
presentes, contribuyen a modificar el sistema por medio de cambios en
las especificaciones más que por ajustes al código fuente.
Soporte para el desarrollo de prototipos de sistemas: En general, el
desarrollo de prototipos de aplicaciones toma varias formas. En
ocasiones se desarrollan diseños para pantallas y reportes con la
finalidad de mostrar la organización y composición de datos,
encabezados y mensajes.
Los ajustes necesarios al diseño se hacen con rapidez para alterar la
presentación y las características de la interaface. Sin embargo, no se
prepara el código fuente, de naturaleza orientada hacia
procedimientos, como una parte del prototipo. Como disyuntiva, el
desarrollo de prototipos puede producir un sistema que funcione. Las
características de entrada y salida son desarrollados junto con el
código orientado hacia los procedimientos y los archivos de datos.
Muchas herramientas CASE soportan las primeras etapas del
desarrollo de un prototipo. Muy pocas brindan apoyo durante todo el
proceso de desarrollo del prototipo. Las que proporcionan la capacidad
para generar el código soportan de hecho todo el proceso, ya que el
código puede ser generado al inducir la actividad de generación
después de cambiar las especificaciones o requerimientos.
Generación de Código: Como ya se mencionó, algunas herramientas
CASE tienen la capacidad de producir el código fuente. La ventaja
más visible de esta característica es la disminución del tiempo
necesario para preparar un programa. Sin embargo, la generación del
código también asegura una estructura estándar y consistente para el
36
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
programa (lo que tiene gran influencia en el mantenimiento) y
disminuye la ocurrencia de varios tipos de errores, mejorando de esta
manera la calidad. Las características de la generación del código
permiten volver a utilizar el software y las estructuras estándares para
generar dicho código, así como el cambio de una especificación
modular, lo que significa volver a generar el código y los enlaces con
otros módulos. Ninguna de las herramientas que existen en el
presente es capaz de generar un código completo en todos los
dominios.
Mejora en la habilidad para satisfacer los requerimientos del
usuario: Es bien conocida la importancia de 'satisfacer los
requerimientos del usuario, ya que esto guarda relación con el éxito
del sistema. De manera similar, tener los requerimientos correctos
mejora la calidad de las prácticas de desarrollo. Parece ser que las
herramientas CASE disminuyen el tiempo de desarrollo, una
característica que es importante para los usuarios. Las herramientas
afectan la naturaleza y cantidad de interacción entre los encargados
del desarrollo y el usuario. Las descripciones gráficas y los diagramas,
así como los prototipos de reportes y la composición de las pantallas,
contribuyen a un intercambio de ideas más efectivo.
Soporte iterativo para el proceso de desarrollo: La experiencia ha
demostrado que el desarrollo de sistemas es un proceso iterativo. Las
herramientas CASE soportan pasos iterativos al eliminar el tedio
manual de dibujar diagramas, elaborar catálogos y clasificar. Como
resultado de esto, se anticipa que los analistas repasarán y revisarán
los detalles del sistema con mayor frecuencia y en forma más
consistente.
Alcanzar una Ventaja Competitiva: Las Herramientas C.A.S.E.
pueden proporcionar un nivel competitivo sobre otros que no los
hubieran adoptado o que no hayan capitalizado por completo su
potencial en productividad. Es decir, ganarles contratos de proyectos
d sistemas a la competencia al demostrar que se tiene una mayor
productividad.
Estandarización de métodos internos y externos: A través de la
estandarización en la elaboración de diagramas, los nuevos analistas
de grupo se encuentran capacitados para comprender con rapidez el
trabajo que se ha realizado en el sistema. Esto eliminará la necesidad
de establecer primero qué técnica de elaboración de diagramas se
empleó antes de llegar al contenido. También tienen una ventaja
externa, ya que un analista que ha tenido experiencia en el uso de
ciertos paquetes de Herramientas C.A.S.E., permitirá que el cliente
cuente con una manera fácil de comunicarse.
Viendo problemas viejos de nuevas maneras: Una ventaja de la
utilización de las Herramientas C.A.S.E. es que crean un nuevo
contexto para problemas viejos de tal forma que se estimula la
creación de nuevas ideas. Por ejemplo: Cuando los diagramas de
flujo pueden elaborarse con rapidez y luego corregirse, es más fácil
comparar la conceptualización de los flujos de datos que se tenían con
37
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
anterioridad. Este tipo de tormenta de ideas gráficas sirve como
catalizador para la creación de nuevas ideas.
Adopción de la automatización como rutina: Cuando los analistas
adoptan las Herramientas C.A.S.E. dan una gran paso hacia el
mejoramiento de su credibilidad con sus clientes, ya que el analista
muestra con su ejemplo que la automatización le confiere beneficios a
los usuarios. E l uso de las Herramientas C.A.S.E. también sensibiliza
a los analistas sobre los problemas que enfrentan los usuarios al tratar
de utilizar instrumentos automatizados.
Desventajas.
Las herramientas CASE tienen puntos débiles significativos, que van
desde la contabilidad en los métodos estructurados hasta su alcance
limitado, los cuales amenazan con minar los beneficios potenciales
descritos con anterioridad.
Confiabilidad en los métodos estructurados.
Muchas herramientas CASE están construidas teniendo corno base
las metodologías del análisis estructurado y del ciclo de vida de
desarrollo de sistemas. Por si sola, esta característica puede
convertirse en la principal limitante ya que no todas las organizaciones
emplean métodos de análisis estructurado.
Los métodos estructurados, introducidos en la década de los setentas,
fueron muy elogiados por su habilidad para mejorar la exactitud de los
requerimientos específicos de las aplicaciones. El nivel de
conocimiento de los métodos estructurados es alto entre los
profesionales de sistemas de información de acuerdo con algunas
estimaciones (Yourdon), casi el 90% de todos los analistas está
familiarizado con estos métodos. Aproximadamente la mitad de todas
las organizaciones en Estados Unidos han utilizado alguna vez estos
métodos. A pesar de lo anterior, si la organización o el analista no
utilizan los métodos propios del análisis estructurado y tampoco
desean considerar su uso, entonces el valor de CASE disminuye. En
algunos casos, los analistas evitan del todo emplear herramientas
CASE.
Falta de niveles estándar para el soporte de la metodología.
Aún no aparece un conjunto "estándar" de herramientas CASE, Por
tanto, se debe tener precaución al seleccionar una herramienta de
este tipo. Existen dos significados para las palabras "soporte de la
metodología". Una herramienta puede
1)dar soporte a los diagramas que emplea una metodología o
2) soportarlos e imponer la metodología, sus reglas y sus procesos.
38
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Las herramientas CASE que existen en el presente, tienen una de las
siguientes características:
• Son independientes de la metodología
• Permiten que los usuarios definas sus propias metodologías,
reglas y estándares
• Soportan una metodología
• Soportan las metodologías más diseminadas
En todas ellas existen ciertos compromisos. Las herramientas que son
independientes de la metodología, no pueden fomentar el uso de las
reglas y estándares de la misma. Estas herramientas quizá
proporcionen los componentes de una metodología (por ejemplo,
diagramas de flujo de datos, un diccionario de datos y facilidades para
la descripción de procesos), pero no el marco de referencia, reglas y
procedimientos que en realidad constituyen el núcleo de la
metodología.
Aunque se pueden llevar a cabo acciones básicas para la validación
de diseños y diagramas para detectar componentes faltantes, éstas
son sólo funciones mecánicas. Por otra parte, esta clase de
herramientas no puede proporcionar ayuda metodológica o pedir al
usuario que realice tareas necesarias para la metodología que aún
están sin terminar. Estas herramientas mejoran la productividad al
efectuar tareas tediosas y de documentación, aunque ellas no puedan
asegurar buenos resultados. Desde el punto de vista funcional, las
capacidades que brindan para garantizar la calidad son mínimas.
Las herramientas que proporcionan un soporte limitado a una sola
metodología pueden forzar el uso riguroso de reglas, procedimientos y
estándares de ésta; además brindan ayuda sensible al contexto y
bases de conocimiento que ofrecen asistencia experta. Sin embargo,
entre más metodologías soporte una herramienta, existe la posibilidad
cada vez mayor de que la seguridad y ayuda que ésta ofrece sea
menor.
Conflictos en el uso de los diagramas.
Las herramientas difieren en el uso que hacen de los diagramas.
Algunas son herramientas exclusivamente para gráficas, que se
abocan al dibujo de diagramas para el análisis de entrada y salida de
datos. Este tipo de herramientas pueden restringir ya sea el proceso
de desarrollo normal seguido por una organización o el estilo particular
de trabajo de los analistas.
Otros vendedores de herramientas consideran los diagramas como
documentación y aceptan entradas por medio de formas o lenguajes
de especificación y, en ocasiones, en forma gráfica. Por tanto, se debe
tener cuidado cuando se selecciona una herramienta para apoyar los
métodos existentes dentro de una organización.
39
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
Diagramas no utilizados.
En general, los productos CASE emplean gráficas para modelar y
generar informes sobre el análisis y desarrollo durante todo el proceso
de desarrollo de sistemas. Una de las afirmaciones de los vendedores
de herramientas es que las presentaciones gráficas y la
documentación mejoran la comunicación entre los miembros del
equipo de desarrollo, propician una calidad mayor de la entrada
proporcionada por el cliente y mejoran la productividad de desarrollo
de software. Sin embargo, los investigadores han encontrado que, en
algunos casos, las herramientas gráficas, automatizados o manuales,
no se emplean del todo. 0 tal vez no se utilicen en la forma en que
deberían emplearse.
Por otra parte, algunos analistas prefieren para algunas tareas un
lenguaje estructurado o descriptivo. Muchos profesionales de los
sistemas de información no hacen uso de herramientas gráficas en el
desarrollo de software; más bien las emplean para automatizar la
producción de informes y documentación del sistema, como los
diagramas de flujo utilizados por los programadores para documentar
un programa una vez terminado éste.
Función limitada.
Aunque una herramienta puede apoyar varias fases del ciclo de vida
de desarrollo de sistemas o adaptarse a diferentes metodologías de
desarrollo, por lo general su enfoque primario está dirigido hacia una
fase o método específico. Por ejemplo, los encargados de desarrollar
un nuevo producto pueden afirmar que éste apoya todo el proceso de
análisis y diseño. Sin embargo, las capacidades de comprobación y
verificación de errores del producto quizá sean más rigurosas ya sea
en el área de análisis o en la de diseño, pero no en ambas. Algunos
productos están dirigidos hacia el diseño de bases de datos para la
organización y al desarrollo de aplicaciones que giren en torno a la
base de datos, omitiendo el soporte para pantallas de presentación
visual, los informes sobre requerimientos o las necesidades de
seguridad. Algunos productos capaces de generar el código hacen
mayor hincapié en el desarrollo de prototipos como el principal método
de desarrollo de sistemas de información. Muchas herramientas para
la fase de desarrollo recalcan el mantenimiento y la reestructuración
del código, pero ofrecen un soporte débil durante la fase de análisis
para la determinación y especificación de requerimientos.
Alcance limitado.
Aunque muchas herramientas basadas en computadora incluyen la
capacidad de verificar las especificaciones para determinar su
completez o consistencia, virtualmente no llevan a cabo ningún
análisis de los requerimientos de la aplicación. Por tanto, el alcance de
las actividades de desarrollo asociado con las herramientas existentes
es bastante limitado.
La mayor parte de productos CASE describe (documenta) pero no
analiza. De poca ayuda es proporcionar una regla de inclusión en los
40
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
mejores enfoques y una regla de exclusión para los que son poco
satisfactorios. No ofrecen o evalúan soluciones potenciales para los
problemas relacionados con sistemas. Y tampoco existe una garantía
clara para que dos analistas que utilicen los mismos métodos
aplicados a información idéntica, formulen recomendaciones
igualmente aceptables.
Las tareas humanas siguen siendo criticas.
La tecnología CASE ofrece herramientas que soportan las funciones
de modelado, verificación, manejo de datos y de utilería que son
necesarias para mejorar la productividad del desarrollo. Sin embargo,
las herramientas deben estar en manos de personas con experiencia y
deben "adaptarse" a la arquitectura de la información así como a las
metodologías de desarrollo utilizadas por la organización. Por otra
parte, las actividades criticas no son el desarrollo de gráficas que
documenten al sistema existente sino que son aquellas tareas donde
las personas interactuan entre sí: determinación y verificación de
requerimientos con el usuario. A medida que sean automatizados las
funciones de modelado y búsqueda de errores, la responsabilidad del
éxito en un sistema de información caerá cada vez más sobre aquellos
que especifican los requerimientos de información. Obtener y
comprender los requerimientos son tareas realizadas por los seres
humanos, y lo más probable es que se continúe de tal forma.
Adaptación debido al rezago de integración.
Una de las desventajas de la utilización de Instrumentos C.A.S.E. es
que el ser relativamente nuevos, en ocasiones quedan cortos en las
expectativas que crean. Esto es evidente en su incapacidad para
auxiliar a los analistas para cubrir plenamente todas las actividades del
ciclo de vida.
Al decidir comprar un paquete comercial de
automatización la decisión debe incluir la aceptación de que con el fin
de integrarlo será necesario un buen esfuerzo de adaptación.
Superación de puntos ciegos del desarrollador.
Quienes desarrollan este tipo de tecnologías, tienen lagunas en
términos de comprender con precisión lo que un analista o
programador quisieran al utilizar el software. Por ejemplo: aunque el
COBOL es el lenguaje de programación de mayor difusión en los
negocios, los instrumentos C.A.S.E. no pueden producir estructuras
utilizables por los programadores en COBOL.
Cambios de métodos de trabajo.
El cambio de tecnología implica también un cambio de los métodos de
trabajo. Como se ha visto que la resistencia al cambio es pare de la
naturaleza humana, nunca será fácil dejar atrás un antiguo método de
trabajo por otro nuevo, incluso si los beneficios son claros a un nivel
intelectual.
41
UNIDAD VI – METODOLOGIA ESTRUCTURADA DE DESARROLLO DE
SISTEMAS
La inversión en paquetes comerciales costosos.
Los costos iniciales del software C.A.S.E. pueden ser significativos. Si
es empleado por una empresa pequeña u otra que tiene dificultades
para obtener utilidades, los costos iniciales de las Herramientas
C.A.S.E. le harán reconsiderar su adquisición. Debe ponderarse los
incrementos en productividad y para comunicarse mejor con otros
analistas y usuarios finales.
En general, las herramientas se clasifican en herramientas de alto
nivel o “Upper Case”, que hacen referencia a las tareas de análisis y
diseño, y herramientas de bajo nivel o “Lower Case”, que son aquellas
que apoyan la conversión de los diseños en código para computadora.
Las herramientas automatizadas se agrupan en tres categorías:
herramientas de tipo front-end, herramientas de tipo back-end y
herramientas integrales. Las herramientas de tipo front-end
automatizan las primeras tareas del proceso de desarrollo de
sistemas, incluidas el análisis de requerimientos y el diseño lógico. A
menudo estas herramientas soportan la preparación de modelos
gráficos, como diagramas de flujo de datos, que documentan procesos
y actividades.
Las herramientas de tipo back-end brindan apoyo en la formulación de
la lógica del programa, de algoritmos de procesamiento y otros
detalles relacionados con el procesamiento por computadora.
En algunas ocasiones, estas herramientas se conocen como
herramientas de programación asistidas por computadora, ya que
ayudan a preparar el software para la computadora y el código del
programa.
Las herramientas integrales buscan enlazar las actividades de análisis
y desarrollo en una forma que automatice todo el proceso de
desarrollo de sistemas y, relacionado con esto, la vida de la aplicación.
Las especificaciones de alto y bajo nivel clasifican la información
recuperada durante las actividades de análisis y diseño. Dado que es
común que exista una laguna entre las dos categorías de
herramientas, el analista debe enlazar en forma manual las dos
actividades.
42