7. Diccionario de
datos.
Contiene las características lógicas de los
sitios donde se almacenan los datos del
sistema,
incluyendo nombre, descripción, alias, contenido y
organización. Identifica los procesos donde
se emplean los datos y los sitios donde se necesita el acceso
inmediato a la información, se desarrolla durante el
análisis de flujo de datos y auxilia a los
analistas que participan en la determinación de los
requerimientos del sistema, su contenido también se emplea
durante el diseño.
Razones para su utilización:
Los sistemas al sufrir cambios continuos, es muy
difícil manejar todos los detalles. Por eso se
registra la información, ya sea sobre hoja de papel o
usando procesadores
de texto. Los analistas mas organizados usan el diccionario de datos automatizados
diseñados específicamente para el
análisis y diseño de software.- Para manejar los detalles en sistemas
muy grandes, ya que tienen enormes cantidades de datos, aun
en los sistemas mas chicos hay gran cantidad de
datos.Los diccionarios de datos proporcionan asistencia
para asegurar significados comunes para los elementos y
actividades del sistema y registrando detalles adicionales
relacionadas con el flujo de datos en el sistema, de tal
manera que todo pueda localizarse con rapidez. - Para asignarle un solo significado a cada uno de los
elementos y actividades del sistema. - Para documentar las características del sistema,
incluyendo partes o componentes así como los aspectos
que los distinguen. Tambien es necesario saber bajo que
circunstancias se lleva a cabo cada proceso y
con que frecuencia ocurren. Produciendo una comprensión
mas completa. Una vez que las características
están articuladas y registradas, todos los participantes
en el proyecto
tendrán una fuente común de información
con respecto al sistema. - Para facilitar el análisis de los detalles con la
finalidad de evaluar las características y determinar
donde efectuar cambios en el sistema.
Determina si son necesarias nuevas características
o si están en orden los cambios de cualquier
tipo.
Se abordan las características:
* Naturaleza de
las transacciones: las actividades de la empresa que
se llevan a cabo mientras se emplea el sistema.
* Preguntas: solicitudes para la recuperación o
procesamiento de información para generar una respuesta
especifica.
* Archivos y
bases de datos:
detalles de las transacciones y registros
maestros que son de interés
para la
organización.
* Capacidad del sistema: Habilidad del sistema para
aceptar, procesar y almacenar transacciones y datos
5- Localizar errores y omisiones en el sistema, detectan
dificultades, y las presentan en un informe. Aun en
los manuales, se
revelan errores.
Contenido de un registro del
diccionario
El diccionario tiene dos tipos de descripciones para el
flujo de datos del sistema, son los elementos datos y estructura de
datos.
Elemento dato: son los bloques básicos para todos
los demás datos del sistema, por si mismos no le dan un
significado suficiente al usuario. Se agrupan para formar una
estructura de
datos.
Descripción: Cada entrada en el diccionario consiste
de un conjunto de detalles que describen los datos utilizados o
producidos por el sistema.
Cada uno esta identificado con:
Un nombre: para distinguir un dato de otro.
Descripción: indica lo que representa en el
sistema.
Alias: porque un dato puede recibir varios nombres,
dependiendo de quien uso este dato.
Longitud: porque es de importancia de saber la cantidad de
espacio necesario para cada dato.
Valores de los datos: porque en algunos procesos solo son
permitidos valores muy
específicos para los datos. Si los valores de
los datos están restringidos a un intervalo especifico,
esto debe estar en la entrada del diccionario.
Estructura de datos: es un grupo de datos
que están relacionados con otros y que en conjunto
describen un componente del sistema.
Descripción:
Se construyen sobre cuatro relaciones de componentes. Se
pueden utilizar las siguientes combinaciones ya sea
individualmente o en conjunción con alguna otra.
Relación secuencial: define los componentes que
siempre se incluyen en una estructura de datos.
Relación de selección: (uno u otro), define
las alternativas para datos o estructuras de
datos incluidos en una estructura de datos.
Relación de iteración: (repetitiva), define
la repetición de un componente.
Relación opcional: los datos pueden o no estar
incluidos, o sea, una o ninguna iteración.
Notación
Los analistas usan símbolos especiales con la
finalidad de no usar demasiada cantidad de texto para la
descripción de las relaciones entre datos y mostrar con
claridad las relaciones estructurales. En algunos casos se
emplean términos diferentes para describir la misma
entidad (alias) estos se representan con un signo igual (=) que
vincula los datos.
8. Diagrama de
estructura de datos
Es una descripción de la relación entre
entidades (personas, lugares, eventos y
objetos) de un sistema y el conjunto de información
relacionado con la entidad.
Finalidades:
- Verificar los requerimientos de información.
- Describir los datos asociados con las entidades.
- Mostrar la relación entre entidades.
- Comunicar los requerimientos de datos a un diseñador
de archivos o administrador
de la base de
datos.
Notación
Una común se usa al preparar los diagramas de
estructura de datos. Las entidades se representan mediante
rectángulos, con el nombre de la entidad en la parte de
arriba y una lista de atributos que describan la entidad. Cada
entidad se puede identificar mediante un atributo llave.
Uso en el diseño de archivo.
El uso de los diagramas de estructura de datos requiere que el
analista haga preguntas importantes acerca de la entidad a
describir. La llave de registro, identifica de una forma
única a la cuenta. Los demás detalles son los
atributos.
Además de los componentes básicos existen dos
elementos adicionales esenciales:
* Apuntadores atributos: enlazan dos entidades mediante la
información común, usualmente un atributo llave en
uno y un atributo (no llave) en el otro.
* Apuntadores lógicos: identifican las relaciones entre
las entidades, sirven para obtener acceso inmediato a la
información en una entidad, definiendo un atributo llave
en otra entidad.
Usualmente se indican en la parte inferior del diagrama, son
los enlaces con las demás entidades incluidas en el
diagrama.
Compartir datos entre las aplicaciones.
Cada sistema se puede desarrollar por separado, guardando los
datos de los estados de cuenta aparte de los datos del inventario. Al
desarrollar mas sistemas y crecer su utilidad, muy
seguido existe la necesidad de integrar los sistemas para
permitir que la información sea compartida por mas de un
sistema.
Redundancia e integridad:
Si cada sistema se desarrolla en forma independiente, la
información puede ser almacenada al menos una vez en cada
sistema, éste además de requerir espacio de
almacenamiento
extra, esta duplicación es llamada redundancia, para
reducir la integridad de la información; cuando se duplica
información es muy probable de que los detalles no
coincidan o que no todos sean actualizados. Resultando la perdida
de integridad en los datos, pudiendo ser corregido mejorando los
procedimientos.
Se puede evitar del todo disminuyendo la redundancia de datos
en los archivos.
Muestra con símbolos la relación entre los
módulos de procesamiento y el software de la
computadora. Describen la jerarquía de los
módulos componentes y los datos que serán
transmitidos entre ellos. Incluye el análisis de las
transformaciones entrada-salida y el análisis de
transacción.
Las flechas con una circunferencia indican datos, mientras que
las que tienen un circulo representa información de
control de
programa,
tales como notas o condiciones de error.
Diagrama de contexto
Se pueden usar diagramas de flujos de datos para representar
el sistema a cualquier nivel de abstracción. El diagrama de flujo
de dato de nivel 0 se llama diagrama de contexto y en él
el sistema esta representado por un solo proceso, que identifica
cual es la función principal del sistema, mostrando
además, los flujos de información que lo relacionan
con otros sistemas: las entidades externas. El diagrama de
contexto tiene una gran importancia puesto que resume el
requisito principal del sistema de recibir ciertas entradas,
procesarlas de acuerdo con determinada función y generar
ciertas salidas. A partir del diagrama de contexto se puede ir
construyendo nuevos diagramas que vayan definiendo con mayor
nivel de detalle lo flujos de datos y procesos de
transformación que ocurren en el sistema, de forma que al
final obtenemos una jerarquía de diagramas.
Método del desarrollo por
prototipos
Los sistemas pueden desarrollarse con métodos y
lenguajes de
programación convencionales, aunque no tengan todas
las características y toques finales de un sistema
terminado. Quizás los informes no
tengan encabezados, logos, etc., falten controles de entradas y
procesamiento. Lo importante es el ensayo, y
hallar los requerimientos.
Los generadores de aplicaciones, son programas que
sirven para hacer otros programas, son un apoyo en la construcción de prototipos, permitiendo
definir la estructura visual de las pantallas, los registros de
entrada y el formato de los informes.
En algunos casos donde el sistema no será utilizado
frecuentemente, puede convertirse el prototipo en el sistema
terminado, o bien, cuando no son muchos los beneficios que se
obtienen.
Razones para desarrollar prototipos de sistemas
Los requerimientos de información no siempre
están bien definidos, pueden ser demasiados vagos
aún al formular el diseño. En otros casos, es
probable que una investigación de sistemas bien llevada, de
como resultado un conjunto muy amplio de requerimientos de
sistemas, pero construir un sistema que satisfaga a todos ellos
quizás necesite del desarrollo de nueva tecnología.
Los prototipos permiten evaluar situaciones extraordinarias
donde los encargados de diseñar e implantar sistemas no
tienen información ni experiencia, o también donde
existen situaciones de riesgo y costos elevados,
y aquellas donde el diseño propuesto es novedoso y
aún no ha sido probada.
La información obtenida con su uso se aplica en un
nuevo diseño que se emplea, otra vez, como prototipo y que
revela más información valiosa sobre diseño.
El proceso se repite las veces que sea necesario para revelar los
requerimientos esenciales del diseño.
Maquetas
Cuando se comienza el desarrollo, tiene por objetivo
presentar a los usuarios y/o clientes la
apariencia del sistema final. Los usuarios pueden manifestar su
opinión.
Ambos métodos son muy útiles para establecer la
viabilidad del proyecto y definir acuerdos sobre los objetivos y
resultados esperados.
10. Etapas del método de
prototipos
1- Identificación de requerimientos conocido.
La determinación de los requerimientos de una
aplicación es tan importante para el método de
desarrollo de prototipo como lo es para los métodos del
ciclo clásico de desarrollo de sistemas o análisis
estructurado (aunque las tácticas son diferentes). Por
consiguiente, antes de crear el prototipo, los analistas y
usuarios deben trabajar juntos para identificar los
requerimientos conocidos que tiene que satisfacerse. Para hacerlo
determinan los fines para lo que servirá el sistema y el
alcance de sus capacidades.
2- Desarrollo de un modelo de
trabajo
Es útil comenzar el proceso de construcción del
prototipo con el desarrollo de un plan general que
permita a las personas conocer lo que se espera de ellas y del
proceso de desarrollo. Es difícil, y en ocasiones
imposibles, fijar una fecha tentativa de terminación. La
experiencia con el sistema es la que determina eventualmente
cuando en sistema esta terminado.
Para comenzar la primera iteración, usuarios y
analistas identifican de manera conjunta los datos que son
necesarios para el sistema y especifican la salida que debe
producir la aplicación.
Las decisiones de diseño necesarias para desarrollar la
salida del sistema cambian muy poco en relación con las
tomadas en otros métodos de desarrollo. Sin embargo, con
un prototipo, se espera que las especificaciones iniciales
estén incompletas.
En el desarrollo de un prototipo se preparan los siguientes
componentes:
*El lenguaje
para el diálogo o conversación entre el usuario y
el sistema
*Pantallas y formato para la entrada de datos
*módulos esenciales de procesamiento
*Salida del sistema
Al construir el prototipo se deben seguir los
estándares para datos que emplea la
organización.
En esta etapa es más importante la rapidez con que se
construye el prototipo que la eficiencia de
operación. Es por esto que el analista no intenta
optimizar la velocidad de
operación del sistema
Durante la evaluación
los analistas de sistemas desean capturar 3)El prototipo y el
usuario
Es responsabilidad del usuario trabajar con prototipo
y evaluar su característica y operación. La
experiencia con el sistema bajo condiciones permite obtener la
familiaridad indispensable para determinar los cambios o mejoras
que sean necesarios así como la eliminación de
características inadecuadas o innecesarias.
4)Revisión del prototipo
información sobre los que les gusta y los que les
desagrada a los usuarios. La información obtenida
tendrá influencia sobre las características de la
siguiente versión de la aplicación.
Los cambios al prototipo son planificados con los usuarios
antes de llevarlos a cabo. El analista es el responsable de
realizar las modificaciones.
5) Repetición del proceso las veces que sea
necesario.
El proceso finaliza cuando los usuarios y analistas
están de acuerdo en que el sistema ha evolucionado lo
suficiente como para incluir todas las características
necesarias o cuando ya es evidente que no se obtendrá
mayor beneficio.
6) El abandono o dejarlo como esta:
Cuando se verifica de que no es posible desarrollar el sistema
para satisfacer los objetivos deseados, ya sea por la
tecnología existente o por el factor economico.
11. Coordinación y
Gestión
del proyecto.
La gestión del proyecto presupone establecer
condiciones para el desarrollo del mismo. Involucra actividades
de: planificación, estimación de
recursos,
seguimiento y control y evaluación del proyecto.
- La planificación de proyectos se
define como la predicción de la duración de las
actividades y tareas a nivel individual. - La estimación se define como la predicción de
personal,
esfuerzo y costo que se
requerirá para terminar todas las actividades y productos
conocidos asociados con el proyecto. El tamaño del
producto a
desarrollar es una de las primeras tareas en la gestión
del proyecto. El tamaño se define como la cantidad de
código fuente, especificaciones, casos de prueba,
documentación del usuario y otros productos tangibles
que son salida del proyecto, éste se basa principalmente
en la experiencia de proyecto anteriores. - El seguimiento de proyectos es la recolección de
datos y su acumulación sobre recursos consumidos, costos
generados asociados con un proyecto. La medición en los
proyectos de desarrollo de software es una actividad
fundamental para la mejora de la productividad,
el costo y la calidad del
producto final.
Proceso de Iniciación del Proyecto.
Abarca aquellas actividades de creación de la
estructura del proyecto. Durante este ciclo se define el ciclo de vida
del software para este proyecto y se establecen en los planes
para su gestión. Se estiman y asignan los recursos
necesarios a fin de ejecutar las distintas tareas que demanda el
proyecto. Se identifican y seleccionan estándares,
metodologías y herramientas
para la gestión y ejecución del mismo y, por
último, se prepara y establece un plan para su
implementación adecuada y oportuna. El plan de
Gestión del Proyecto Software que conducirá el
desarrollo se produce como culminación de este
proceso.
El software al ser intangible, no tener peso, ni volumen, ni
superficie, etc. se mide a través de diversos aspectos
clave en el desarrollo. La medición determina cuales son
los aspectos y proporcionan métodos para medirlos.
La medición y estimación atacan los tres
problemas
claves de la ingeniería del software:
- Estimar costos y recursos en un proyecto software
- Garantizar la calidad del producto final
- Mejorar la productividad del ingeniero de software durante
el desarrollo.
Teniendo en cuenta estos objetivos, las métricas se
centran en cuatro aspectos:
Para estimar los recursos es necesario tener en cuenta una
serie de factores de riesgo que influyen sustancialmente en la
precisión de las estimaciones de los recursos
humanos necesarios para la realización del proyecto.
Los mas importantes son:
*Complejidad de la tarea.
*Modificaciones permitidas a lo largo del desarrollo
*Experiencia previa de los desarrolladores
*Duración fijada del proyecto.
*Estructuración del problema y de las tareas.
*Disponibilidad de datos e información suministrada por
el usuario.
*Disponibilidad y facilidad de comunicación con el usuario.
Además de las fases estándar del desarrollo, hay
que tener en cuenta la coordinación y seguimiento del
proyecto que suponen una importante carga de trabajo y que son
olvidadas durante la planificación o no se le dedica
mucho.
El costo global se compone de las partidas de viajes,
hardware (nuevo o
actualización), software (en caso de comprar algún
paquete para el desarrollo), gastos comunes, y
personal que es el mas influyente, ya que el costo de un proyecto
es directamente proporcional a los recursos humanos.
El proceso engloba todas las actividades y fases que se llevan
a cabo durante la realización del proyecto. Se persigue
determinar si en cada fase los resultados producidos se
corresponden con los esperados y en establecer un control sobre
los recursos estimados para cada una de las fases.
El producto incluye cualquier documento o software
desarrollado que se genere durante el proceso completo. En las
medidas de productos software existen medidas directas (costo del
proyecto, esfuerzo empleado, líneas de código
implementadas, etc.) y medidas indirectas
( funcionalidad, fiabilidad, eficiencia, facilidad de mantenimiento,
etc.).
Herramientas para el desarrollo de sistemas
Las herramientas son cualquier dispositivo que,
empleándose adecuadamente, mejora el desempeño del
desarrollo de sistemas de
información.
Se agrupan en las tres siguientes herramientas
automatizadas:
Herramientas de tipo Front-end
Automatizan las primeras actividades del proceso de desarrollo
de sistemas.
Esta herramienta proporciona soporte para el desarrollo de
modelos
gráficos de sistemas y procesos
Los diagramas de
flujo son representativos de este tipo de herramientas.
Herramientas para análisis
Éstas herramientas ayudan a los especialistas en
sistemas a documentar un sistema existente, ya sea manual o
automatizado. También sirve para determinar los
requerimientos de una nueva aplicación. Incluye:
– Herramientas para recolección de datos: capturan
detalles que describen sistemas y procedimientos en uso.
Documentan procesos y actividades de decisión, se utilizan
para apoyar la tarea de identificar requerimientos.
– Herramientas para diagramación: crean
representaciones gráficas de sistemas y actividades.
Apoyan el dibujo y
revisión de diagramas de flujos de datos e iconos
asociados con el análisis estructurado. Incluyen programas
para representación en diagramas de flujo.
– Herramientas para el diccionario: registran y mantienen
descripciones de los elementos del sistema, como grupo de datos,
procesos, alimentos de
datos, etc. Frecuentemente proporcionan la capacidad de examinar
las descripciones del sistema, para decidir si son incompletas o
inconsistentes.
Herramientas para diseño
Apoyan el proceso de formular las características que
el sistema debe tener para satisfacer los requerimientos deseados
durante las actividades de análisis. Incluye:
– Herramienta de especificación: apoyan el proceso de
formular las características, como por ejemplo deben tener
una aplicación como entradas, salidas, procesamientos
específicos de control.
– Herramienta para presentación: se utilizan para
describir la posición de datos, mensajes, y encabezados
sobre las pantallas de las terminales, informes y otros medios de
entradas y salidas.
Los analistas utilizan las herramientas para el diseño de
sistemas desde el inicio de la era de las computadoras.
Ahora a las herramientas se le están dando un nuevo
significado en el diseño de software.
Herramientas de tipo back-end
Su finalidad es ayudar al analista a formular la lógica
del programa, los algoritmos de
procesamiento y la descripción física de datos.
Tambien ayudan a la intersección con los dispositivos
(para entrada y salida). Estas actividades convierten los
diseños lógicos del software en un código de
programación; este es que da existencia a
la aplicación.
Herramientas para el desarrollo
Ayudan al analista a trasladar los diseños en
aplicaciones funcionales. Incluye:
– Herramientas para ingeniería Software: apoyan el
proceso de formular diseños de software, incluyendo
procesamientos y controles.
– Generadores de códigos: producen el código
fuente y las aplicaciones a partir de especificaciones
funcionales bien articuladas
– Herramientas para pruebas:
apoyan la fase evaluación de un sistema. Incluyen
facilidades para examinar la correcta operación del
sistema.
Herramientas integrales
Proporcionan un ambiente que
automatiza tareas claves a lo largo del proceso de desarrollo.
Estas herramientas facilitan el diseño, administración y mantenimiento del
código. Brinda un ambiente eficiente para crear,
almacenar, manipular y documentar sistemas.
13. Reingeniería e ingeniería
inversa
Los conceptos de reingeniería e ingeniería
inversa están ligados al desarrollo de software a gran
escala, donde una
mejora en proceso de este desarrollo supone un aumento en la
competitividad
de la empresa.
Aunque hay que tener en cuenta que esta mejora es, en general
a largo plazo (normalmente de uno a dos años) ambas
actividades, están orientadas a automatizar el
mantenimiento de aplicaciones. Esta es una tarea que consume gran
cantidad de recursos, por lo que cualquier reducción en el
tiempo y
recursos empleados en ella supone una importante mejora en la
productividad del proceso. Este es el principal objetivo de la
reingeniería. Se trata, de analizar el código o el
diseño actual y modificarlo con la ayuda de herramientas
automáticas para traducirlos a códigos mas
estructurados, y más eficientes.
Dentro de la reingeniería, el proceso de pasar del
código a una descripción de mas alto nivel es lo
que se denomina:
Ingeniería inversa.
La reingeniería e ingeniería inversa prolongan
la vida del software.
Dado que es una labor estratégica, es conveniente
conocer cuando conviene realizar la tarea de reingeniería
para una aplicación y cuándo es más rentable
sustituirla e implementar una nueva. Las aplicaciones para el
primer paso, son aquellas en la que se produce las siguientes
situaciones:
- Fallos frecuentes, que son difíciles de
localizar - Son poco eficientes, pero realizan la función
esperada - Dificultades en la integración con otros sistemas
- Calidad pobre del software final
- Resistencia a introducir cambios
- Pocas personas capacitadas para realizar
modificaciones - Dificultades para realizar pruebas
- El mantenimiento consume muchos recursos
- Es necesario incluir nuevos requisitos, pero los
básicos se mantienen.
Desarrollo de software con y para reuso
El desarrollo de software con reúso consiste en
desarrollar una aplicación usando software ya existente.
Cualquier profesional lo utiliza
El desarrollo de software para reuso consiste en la
construcción de un sistema con la intención de
reutilizar partes de él en futuros desarrollos. Con
software a gran escala, un buen profesional con experiencia puede
desarrollarlo.
Estudios realizados determinan que la práctica de
reutilización del software en un proyecto aumenta la
productividad durante el desarrollo de dicho proyecto.
Sin embargo, la reutilización del software no cubre
solo el reuso de códigos, abarca todo un amplio de
posibilidades en los diferentes niveles, metodología, ciclos de vida, planes del
proyecto, especificaciones de requisitos, diseños,
arquitectura
software, planes de validación, juegos de
prueba y documentación.
Autor:
Solange Galáz
1ro. de Analista de Sistemas, C. Del U. Entre Ríos,
Argentina
 Página anterior | Volver al principio del trabajo | Página siguiente  |