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 siguiente |