Métodos y diseño de sistemas de información. Fundamentos de la metodología de diseño de sistemas de información. Los productos finales de la fase de diseño son

Diseño sistemas de información es un proceso de múltiples etapas de su creación y/o modernización mediante el uso de un conjunto ordenado de metodologías y herramientas. El diseño (a diferencia del modelado) implica trabajar con un objeto inexistente y tiene como objetivo crear un sistema de información en el campo de:

• procesar objetos de la futura base de datos,
• escribir programas (incluidos informes y formularios de pantalla) que aseguren la ejecución de consultas a datos,
• teniendo en cuenta el funcionamiento de un entorno específico (tecnología).

Si identificamos la etapa de diseño de sistemas de información como una etapa separada, entonces se puede ubicar entre las etapas de análisis y desarrollo. Sin embargo, en la práctica, una división clara en etapas suele ser difícil o imposible, ya que el diseño, que comienza formalmente con la definición del objetivo del proyecto, a menudo continúa en las etapas de prueba e implementación.

Objetivo de diseño del sistema de información y conceptos relacionados.

Los directivos modernos de organizaciones públicas y privadas son conscientes de que la velocidad de procesamiento de la información, que cambia constantemente y crece en volumen, es una cuestión de supervivencia de la empresa en el mercado y ventaja competitiva. EN vista general Los objetivos de los proyectos para la creación de sistemas de información se reducen a proporcionar condiciones que permitan recibir, procesar y utilizar esta información mediante la creación de un sistema funcional a prueba de fallos con suficiente:

• nivel de adaptabilidad a condiciones cambiantes,
• rendimiento,
• tiempo de respuesta del sistema a una solicitud,
• nivel de seguridad,
• grado de facilidad de uso.

Un sistema de información (SI) es una colección de información contenida en una base de datos y tecnologías (así como herramientas técnicas) que permiten el procesamiento de la información. En este caso, las tecnologías incluyen métodos para detectar, recopilar, procesar, almacenar, distribuir información y métodos que permiten implementar estos métodos. Gestión de la información esto se reduce al uso de estos métodos para controlar los procesos de planificación, diseño, operación y análisis de SI. La tecnología de diseño se basa en la metodología elegida para una tarea específica como un conjunto de principios expresados ​​en un concepto único y definido.

Organización del diseño de IP.

La organización del diseño de circuitos integrados suele dividirse en 2 tipos:

1. El diseño canónico refleja las características tecnológicas del proceso original (individual).
2. El diseño estándar, que se caracteriza por una solución de diseño estándar (TDS), se replica y es adecuado para un uso repetido.

El diseño canónico distingue la reflexión. tecnología de mano diseño, implementación a nivel ejecutante, uso de herramientas informáticas universales de soporte.

El diseño canónico se utiliza principalmente para circuitos integrados locales y relativamente pequeños con un uso mínimo de soluciones estándar. La adaptación de las soluciones de diseño se produce únicamente mediante la reprogramación de módulos de software.

El diseño canónico se organiza mediante un modelo de ciclo de vida en cascada. Esto implica dividir el proceso en las siguientes etapas y pasos:

1. Etapa de anteproyecto. Se realiza un análisis previo al proyecto y se elabora una especificación técnica. Es decir, se forman los requisitos para el sistema de información, se desarrolla su concepto, se elabora un estudio de viabilidad y se redactan las especificaciones técnicas.
2. La etapa de diseño implica la preparación de diseños preliminares y técnicos, desarrollo de documentación de trabajo.
3. En la etapa de posproyecto se inician las actividades de implementación del SI, capacitación del personal y análisis de resultados de pruebas. Parte de esta etapa es el mantenimiento de la IP y la eliminación de las deficiencias identificadas.

Las etapas, si es necesario, se pueden ampliar o detallar: combinar etapas sucesivas, eliminar las "innecesarias", comenzar la siguiente etapa antes de completar la anterior.

El método de diseño estándar se distingue por la posibilidad de descomponer la IP diseñada en componentes, que incluyen módulos de software, subsistemas, conjuntos de tareas, etc. Para implementar componentes, puede utilizar soluciones estándar que ya existen en el mercado y personalizarlas según sus necesidades. necesidades organización específica. En este caso, el diseño estándar requiere la disponibilidad obligatoria de documentación que describa en detalle el TPR y los procedimientos de configuración.

La descomposición puede tener varios niveles, lo que permite distinguir clases de TPR:

• elemental – para una tarea separada (elemento),
• subsistema - para subsistemas individuales,
• objeto: soluciones de diseño estándar de la industria que contienen el conjunto completo de subsistemas.

La capacidad de implementar un enfoque modular se considera una ventaja de los TPR elementales. Sin embargo, en caso de incompatibilidad diferentes elementos el proceso de combinarlos conduce a mayores costos. El subsistema TPR, además de implementar un enfoque modular, permite realizar configuraciones paramétricas para objetos en diferentes niveles de control. Los problemas con la consolidación surgen cuando se trata de productos de varios fabricantes de software diferentes. Además, la adaptabilidad del TPR desde el punto de vista de la reingeniería continua de procesos se considera insuficiente. Los TPR de objetos, en comparación con las clases anteriores, tienen una gran cantidad de ventajas:

• escalabilidad, lo que hace posible utilizar configuraciones de IC para diferentes numeros lugares de trabajo,
• unidad metodológica de componentes,
• compatibilidad de componentes IC,
• apertura de la arquitectura: la capacidad de implementar soluciones de diseño en plataformas de varios tipos,
• Configurabilidad: la capacidad de utilizar el subconjunto deseado de componentes IS.

Durante la implementación del diseño estándar, se utilizan enfoques orientados a parámetros y orientados a modelos.

Metodologías básicas de diseño de circuitos integrados

Las características específicas del proceso de diseño permiten distinguir metodologías basadas en diferentes principios. Entre las principales metodologías modernas de diseño de circuitos integrados se encuentran las siguientes:

• TDAA. Una metodología para el modelado funcional del trabajo, que se basa en el análisis estructural y la representación gráfica de la organización como un sistema de funciones. Aquí lo funcional, informativo y modelo dinámico. La metodología se conoce actualmente como notación IDEF0 (estándar). El proceso analizado se representa gráficamente en forma de cuadrilátero, donde las influencias regulatorias y de control se representan en la parte superior, los objetos de control en la parte inferior, los datos de entrada a la izquierda y los datos de salida a la derecha.
• RAD. Metodología de desarrollo rápido de aplicaciones. RAD permite el desarrollo rápido de aplicaciones mediante el uso de diseño basado en componentes. La metodología se utiliza en proyectos con presupuesto limitado, requisitos poco claros para la propiedad intelectual, con plazos cortos para su implementación. Se utiliza si la interfaz de usuario se puede demostrar en un prototipo y el proyecto se puede dividir en elementos funcionales.
• RUP. La metodología RUP implementa enfoques iterativos e incrementales. El sistema se construye sobre la base de la arquitectura del sistema de información, y la planificación y gestión del proyecto se basan en los requisitos funcionales del sistema de información. El desarrollo de un sistema de información general se produce en iteraciones, como un complejo de pequeños proyectos individuales con sus propios planes y tareas. El ciclo iterativo se caracteriza por retroalimentación periódica y adaptación al núcleo de SI.

Existen varias clasificaciones de metodologías: para el uso de TPR, para el uso de herramientas de automatización, etc. Por ejemplo, según el grado de adaptabilidad, reconstrucciones (cuando se reprograman módulos), parametrización (cuando el cambio de parámetros conlleva la generación de un solución de diseño), se distinguen la reestructuración (al cambiar el modelo) área problemática acompañado de la generación automática de una solución de diseño).

Conceptos básicos de la metodología de diseño de circuitos integrados.

1. Ciclo de vida de la propiedad intelectual

Uno de los conceptos básicos de la metodología de diseño de SI es el concepto de su ciclo de vida del software (ciclo de vida del SW). El ciclo de vida del software es un proceso continuo que comienza desde el momento en que se toma la decisión sobre la necesidad de crear software y finaliza en el momento en que se retira por completo del servicio.

El principal documento normativo que regula el ciclo de vida del software es la norma internacional ISO/IEC 12207 (ISO – Organización Internacional de Normalización, IEC – Comisión Electrotécnica Internacional). Define la estructura del ciclo de vida que contiene los procesos, actividades y tareas que deben realizarse durante la creación del software.

La estructura del ciclo de vida del software según la norma ISO/IEC 12207 se basa en tres grupos de procesos:

principales procesos del ciclo de vida del software (compra, suministro, desarrollo, operación, soporte);

procesos auxiliares que aseguran la implementación de los procesos principales (documentación, gestión de configuración, aseguramiento de la calidad, verificación, certificación, evaluación, auditoría, resolución de problemas);

procesos organizativos (gestión de proyectos, creación de infraestructura del proyecto, definición, evaluación y mejora del propio ciclo de vida, formación).

El desarrollo cubre todo el trabajo sobre la creación de software y sus componentes (análisis, diseño y programación) de acuerdo con los requisitos especificados, incluida la preparación de la documentación operativa y de diseño, la preparación de los materiales necesarios para probar la funcionalidad y calidad de los productos de software, los materiales necesarios. para organizar la formación del personal, etc.

La operación incluye el trabajo de implementación de componentes de software, incluida la configuración de la base de datos y las estaciones de trabajo de los usuarios, el suministro de documentación operativa, la capacitación del personal, etc., y la operación directa, incluida la localización de problemas y la eliminación de las causas de su aparición, la modificación del software dentro de las regulaciones establecidas. , elaboración de propuestas de mejora, desarrollo y modernización del sistema.

La gestión de proyectos está asociada con cuestiones de planificación y organización del trabajo, creación de equipos de desarrollo y seguimiento de los plazos y la calidad del trabajo realizado. El soporte técnico y organizativo del proyecto incluye la selección de métodos y herramientas para la implementación del proyecto, determinación de métodos y herramientas para las pruebas de software, capacitación del personal, etc. Garantizar la calidad del proyecto está asociado con problemas de verificación, verificación y prueba del software. La verificación es el proceso de determinar si el estado actual de desarrollo alcanzado en una etapa determinada cumple con los requisitos de esa etapa. La verificación le permite evaluar el desarrollo para verificar el cumplimiento de sus parámetros con los requisitos iniciales. La verificación se superpone con las pruebas, que se ocupan de identificar diferencias entre los resultados reales y esperados y evaluar si las características del software cumplen con los requisitos originales. Durante la implementación del proyecto lugar importante Se ocupa de la identificación, descripción y control de los requisitos de configuración de componentes individuales y de todo el sistema en su conjunto.

La gestión de la configuración es uno de los procesos auxiliares que soportan los principales procesos del ciclo de vida del software, principalmente los procesos de desarrollo y mantenimiento de software. Al crear proyectos SI complejos que constan de muchos componentes, cada uno de los cuales puede tener variedades o versiones, surge el problema de tener en cuenta sus conexiones y funciones, crear una estructura unificada y asegurar el desarrollo de todo el sistema. La gestión de la configuración le permite organizar, tener en cuenta sistemáticamente y controlar los cambios en el software en todas las etapas del ciclo de vida. Los principios y recomendaciones generales para la contabilidad de la configuración, la planificación y la gestión de la configuración del software se reflejan en el borrador de la norma ISO/IEC 12207-2.

Cada proceso se caracteriza por determinadas tareas y métodos para su resolución, datos iniciales obtenidos en la etapa anterior y resultados. Los resultados del análisis son, en particular, modelos funcionales, modelos de información y los diagramas correspondientes. El ciclo de vida del software es de naturaleza iterativa: los resultados de la siguiente etapa a menudo provocan cambios en las soluciones de diseño desarrolladas en etapas anteriores.

2. Modelos de ciclo de vida del software

El estándar ISO/IEC 12207 no ofrece modelo específico Ciclo de vida y métodos de desarrollo de software. Su normativa es común a cualquier modelo de ciclo de vida, metodologías y tecnologías de desarrollo. El estándar ISO/IEC 12207 describe la estructura de los procesos del ciclo de vida del software, pero no especifica en detalle cómo implementar o realizar las actividades y tareas incluidas en estos procesos.

Un modelo de ciclo de vida se entiende como una estructura que define la secuencia de ejecución y las relaciones entre procesos, acciones y tareas a lo largo del ciclo de vida. El modelo de ciclo de vida depende de las características específicas del SI y de las condiciones específicas en las que se crea y opera el sistema. Hasta la fecha, los dos modelos principales de ciclo de vida siguientes son los más difundidos: el modelo en cascada (1970-1985) y el modelo en espiral (1986-1990).

En las aplicaciones de SI homogéneas que existían inicialmente eran un todo único. Para desarrollar este tipo de aplicaciones se utilizó el método de cascada. Su característica principal es la división de todo el desarrollo en etapas, y la transición de una etapa a la siguiente ocurre solo después de que se completa por completo el trabajo en la actual (Fig. 1.1)

Cada etapa culmina con la publicación de un conjunto completo de documentación suficiente para permitir que otro equipo de desarrollo continúe el desarrollo.

Las ventajas de utilizar el método en cascada son las siguientes:

en cada etapa, se genera un conjunto completo de documentación de diseño que cumple con los criterios de integridad y coherencia;

Las etapas de trabajo realizadas en una secuencia lógica permiten planificar el tiempo de finalización de todos los trabajos y los costos correspondientes.

El enfoque en cascada ha demostrado su eficacia en la construcción de sistemas de información, para los cuales, al comienzo del desarrollo, todos los requisitos pueden formularse con bastante precisión y de manera completa para brindar al desarrollador la libertad de implementarlos técnicamente de la mejor manera posible. . Esta categoría incluye sistemas de cálculo complejos, sistemas en tiempo real, etc.

Al mismo tiempo, este enfoque tiene una serie de desventajas, causadas principalmente por el hecho de que el proceso real de creación de software nunca encaja completamente en un esquema tan rígido; había una necesidad constante de volver a etapas anteriores y aclarar al revisar decisiones tomadas anteriormente; . Como resultado, el proceso de creación de software real tomó la forma que se muestra en la Fig. 1.2.

La principal desventaja del enfoque en cascada es el retraso significativo en la obtención de resultados. La coordinación de los resultados con los usuarios se lleva a cabo únicamente en los puntos planificados después de la finalización de cada etapa del trabajo; los requisitos para el SI están "congelados" en forma de especificaciones técnicas durante todo el tiempo de su creación. Por lo tanto, los usuarios pueden hacer sus comentarios sólo después de que el trabajo en el sistema esté completamente completado. Si los requisitos no se establecen con precisión o cambian durante un largo período de desarrollo de software, los usuarios terminan con un sistema que no satisface sus necesidades. Los modelos (tanto funcionales como informativos) del objeto automatizado pueden quedar obsoletos simultáneamente con su aprobación.

Para superar estos problemas, se propuso un modelo de ciclo de vida en espiral (Fig. 1.3.), que pone énfasis en las etapas iniciales del ciclo de vida, análisis y diseño. En estas etapas la viabilidad soluciones tecnicas verificado mediante la creación de prototipos. Cada vuelta de la espiral corresponde a la creación de un fragmento o versión del software, donde se aclaran los objetivos y características del proyecto, se determina su calidad y se planifica el trabajo de la siguiente vuelta de la espiral. De esta manera, los detalles del proyecto se profundizan y se especifican consistentemente, y como resultado, se selecciona una opción razonable, que se lleva a la implementación.

El desarrollo por iteraciones refleja el ciclo espiral objetivamente existente de creación de un sistema. La finalización incompleta del trabajo en cada etapa le permite pasar a la siguiente etapa sin esperar la finalización completa del trabajo en la actual. Con un método de desarrollo iterativo, el trabajo faltante se puede completar en la siguiente iteración. La tarea principal es mostrar a los usuarios del sistema un proyecto viable lo más rápido posible, activando así el proceso de clarificación y complementación de requisitos.

El principal problema del ciclo en espiral es determinar el momento de transición a la siguiente etapa. Para solucionarlo es necesario introducir restricciones temporales para cada una de las etapas del ciclo de vida. La transición avanza según lo planeado, incluso si no se completa todo el trabajo planificado. El plan se elabora a partir de datos estadísticos obtenidos en proyectos anteriores y la experiencia personal de los desarrolladores.

3. Metodologías y tecnologías para el diseño de SI

3.1 Requisitos generales de metodología y tecnología.

Metodologías, tecnologías y herramientas de diseño (CASE - herramientas) forman la base de cualquier proyecto de SI. La metodología se implementa a través de tecnologías específicas y soporta sus estándares, métodos y herramientas que aseguran la implementación de los procesos del ciclo de vida.

La tecnología de diseño se define como una combinación de tres componentes:

procedimiento paso a paso que define la secuencia de operaciones de diseño tecnológico (Fig. 1.4);

criterios y reglas utilizados para evaluar los resultados de las operaciones tecnológicas;

Clasificación de los sistemas de información por la naturaleza del uso de la información.

Clasificación de sistemas de información por grado de automatización.

Conceptos básicos de tecnología de diseño.

Conferencia número 1

DISEÑO DE SISTEMAS DE INFORMACIÓN

Conferencias sobre el tema.sistemas de información (SI)

Sistema de información (SI) es un sistema diseñado para mantener un modelo de información, con mayor frecuencia de cualquier área de la actividad humana. Este sistema debe proporcionar los medios para que se produzcan procesos de información:

· almacenamiento

Sistemas, que almacenan y procesan información se denominan sistemas informáticos de información. Los datos ingresan al sistema de información desde la fuente de información. Estos datos se envían para su almacenamiento o se someten a algún procesamiento en el sistema y luego se transfieren al consumidor.

Se puede establecer retroalimentación entre el consumidor y el propio sistema de información. En este caso, el sistema de información se llama cerrado. Un canal de retroalimentación es necesario cuando es necesario tener en cuenta la reacción del consumidor ante la información recibida.

El sistema de información consta de:

o fuente de información,

o Hardware IC,

o parte del software del SI,

o consumidor de información.

• Los sistemas de información manuales se caracterizan por la falta de tecnología moderna. medios tecnicos procesar información y realizar todas las operaciones por parte de humanos. Por ejemplo, de las actividades de un directivo en una empresa donde no hay ordenadores, podemos decir que trabaja con un SI manual.
• Los sistemas de información automatizados (AIS) son la clase más popular de sistemas de información. Suponen la participación tanto de medios humanos como técnicos en el proceso de procesamiento de la información, asignando el papel principal al ordenador.
• Los sistemas de información automáticos realizan todas las operaciones de procesamiento de información sin intervención humana, varios robots. Un ejemplo de sistemas de información automáticos son algunos motores de búsqueda de Internet, por ejemplo Google, donde un robot de búsqueda recopila automáticamente la información sobre los sitios y el factor humano no afecta la clasificación de los resultados de búsqueda.

• Los sistemas de recuperación de información son un sistema de software para almacenar, buscar y mostrar información de interés para el usuario.
• Los sistemas analíticos de información son una clase de sistemas de información diseñados para el procesamiento de datos analíticos.
• Los sistemas de decisión de información son sistemas que procesan información de acuerdo con un algoritmo específico.
• gerentes
• asesorando
• Centros de situación (complejos de información y análisis)

Desde el punto de vista de la implementación de software y hardware, se pueden distinguir varias arquitecturas IS típicas:

1. Tradicional soluciones arquitectónicas se basan en el uso de servidores de archivos dedicados (File-server) o servidores de bases de datos (Cliente-servidor).

2. Sistemas de información corporativos, estan basados ​​en tecnologías de internet(Aplicaciones de intranet).

3. "DataWarehouse" - integrado entornos de información, incluyendo diversos recursos de información.

4. Arquitectura para la integración de componentes de información y computación basada en un enfoque orientado a objetos, que se utilizan para construir aplicaciones de información distribuida global (arquitectura Orientada a Servicios SOA).

Industria del desarrollo Los sistemas automatizados de gestión de la información se originaron en las décadas de 1950 y 1960 y, a finales de siglo, habían adquirido formas completamente terminadas. En la primera etapa, el enfoque principal para el diseño de SI fue el método "de abajo hacia arriba", cuando el sistema se creaba como un conjunto de aplicaciones que eran las más importantes en ese momento para respaldar las actividades de la empresa. El objetivo principal de estos proyectos no era crear productos replicables, sino satisfacer las necesidades actuales de una institución en particular. Este enfoque continúa hasta cierto punto en la actualidad. En el marco de la "automatización de mosaicos", el soporte para funciones individuales se proporciona bastante bien, pero casi no existe una estrategia para el desarrollo de un sistema de automatización integrado, y la integración de subsistemas funcionales se convierte en un problema independiente y bastante complejo.

Creando tus propios departamentos y la gestión de la automatización, las empresas intentaron “asentarse” por sí mismas. Sin embargo, los cambios periódicos en las tecnologías de trabajo y las descripciones de los puestos de trabajo, las dificultades asociadas con las diferentes percepciones de los usuarios sobre los mismos datos, llevaron a mejoras continuas en los productos de software para satisfacer cada vez más deseos nuevos de los trabajadores individuales. Como resultado, tanto el trabajo de los programadores como los sistemas de información creados provocaron descontento entre los administradores y usuarios del sistema.

La siguiente etapa está relacionada con la conciencia de que existe la necesidad de herramientas de software bastante estándar para automatizar las actividades de diversas instituciones y empresas. De toda la gama de problemas, los desarrolladores identificaron el más notable: la automatización de los procesos contables, analíticos y tecnológicos. Los sistemas comenzaron a diseñarse “de arriba a abajo”, es decir. bajo el supuesto de que un programa debe satisfacer las necesidades de muchos usuarios.

La idea misma de usar un programa universal impone restricciones significativas a la capacidad de los desarrolladores para crear una estructura de base de datos, formularios de pantalla y seleccionar algoritmos de cálculo. El marco rígido establecido "desde arriba" no permite adaptar de manera flexible el sistema a las características específicas de las actividades de una empresa en particular: tener en cuenta la profundidad necesaria de la contabilidad analítica y tecnológica de producción, incluir los datos necesarios procedimientos de procesamiento, para proporcionar una interfaz para cada lugar de trabajo teniendo en cuenta las funciones y la tecnología de un usuario específico. Resolver estos problemas requiere importantes mejoras en el sistema. Por lo tanto, los costos de material y tiempo para implementar el sistema y ajustarlo para cumplir con los requisitos del cliente generalmente exceden significativamente los indicadores planificados.

Según las estadísticas, recopilados por Standish Group (EE.UU.), de 8380 proyectos estudiados en EE.UU. en 1994, más del 30% de los proyectos no tuvieron éxito, coste total que superó los 80 mil millones de dólares. Al mismo tiempo, sólo el 16% del número total de proyectos se completaron a tiempo y los sobrecostos ascendieron al 189% del presupuesto previsto.

Al mismo tiempo, los clientes de IS comenzaron a plantear cada vez más demandas destinadas a garantizar la posibilidad de un uso integrado de los datos corporativos en la gestión y planificación de sus actividades.

Por tanto, surgió una necesidad urgente de formular una nueva metodología para construir sistemas de información.

Metodología de diseño Los sistemas de información describen el proceso de creación y mantenimiento de sistemas en forma de ciclo de vida de SI (LC), presentándolo como una determinada secuencia de etapas y procesos que se realizan en ellos. Para cada etapa se determina la composición y secuencia del trabajo realizado, los resultados obtenidos, los métodos y medios necesarios para completar el trabajo, los roles y responsabilidades de los participantes, etc. Una descripción tan formal del ciclo de vida de un sistema de información permite planificar y organizar el proceso de desarrollo colectivo y garantizar la gestión de este proceso.

El propósito de crear una metodología para construir sistemas de información es regular el proceso de diseño del SI y asegurar la gestión de este proceso para garantizar el cumplimiento de los requisitos tanto del propio SI como de las características del proceso de desarrollo.

Las principales tareas que la metodología de diseño de SI debería ayudar a resolver son las siguientes:

• asegurar la creación de sistemas de información corporativos que cumplan con las metas y objetivos de la organización, así como los requisitos para la automatización de los procesos comerciales del cliente;
• garantizar la creación de un sistema con una determinada calidad en un plazo determinado y dentro del presupuesto del proyecto establecido;
• mantener una disciplina conveniente para mantener, modificar y ampliar el sistema;
• asegurar la continuidad del desarrollo, es decir uso de la infraestructura de información existente de la organización (antecedentes en el campo de la tecnología de la información) en el SI desarrollado.

Implementación de la metodología. debería conducir a una reducción de la complejidad del proceso de creación de propiedad intelectual mediante una descripción completa y precisa de este proceso, así como el uso de métodos y tecnologías modernos para la creación de propiedad intelectual a lo largo de todo el ciclo de vida de la propiedad intelectual, desde el concepto hasta la implementación.

El ciclo de vida de un sistema de información se puede representar como una serie de eventos que ocurren con el sistema durante el proceso de su creación y uso. El modelo de ciclo de vida refleja varios estados sistemas, desde el momento en que surge la necesidad de este sistema de información hasta el momento de su total obsolescencia.

Actualmente se conocen y utilizan los siguientes modelos de ciclo de vida:

• modelo en cascada prevé la implementación secuencial de todas las etapas del proyecto en un orden estrictamente fijo. La transición a la siguiente etapa significa la finalización completa del trabajo en la etapa anterior.

• Modelo paso a paso con control intermedio. Implica desarrollar un SI en iteraciones con ciclos de retroalimentación entre etapas. Los ajustes entre etapas permiten tener en cuenta la influencia mutua real de los resultados del desarrollo en varias etapas; La vida útil de cada etapa se extiende a lo largo de todo el período de desarrollo.

• modelo espiral En cada vuelta de la espiral, se crea la siguiente versión del producto, se especifican los requisitos del proyecto, se determina su calidad y se planifica el trabajo de la siguiente vuelta.

En la práctica, dos modelos principales de ciclo de vida son los más utilizados:

• modelo en cascada (típico del período 1970-1985);
• modelo en espiral (típico del período posterior a 1986).

En los primeros proyectos de SI bastante simple, cada aplicación era un bloque único, funcional e informativamente independiente. El método en cascada ha demostrado ser eficaz para desarrollar este tipo de aplicaciones. Cada etapa se completó después de completar y documentar todo el trabajo requerido.

Se pueden distinguir los siguientes lados positivos aplicación del enfoque en cascada:

• en cada etapa, se genera un conjunto completo de documentación de diseño que cumple con los criterios de integridad y coherencia;
• Las etapas de trabajo realizadas en una secuencia lógica permiten planificar el tiempo de finalización de todo el trabajo y los costos correspondientes.

Enfoque en cascada ha demostrado su eficacia en la construcción de circuitos integrados relativamente simples, cuando al comienzo del desarrollo es posible formular con bastante precisión y completamente todos los requisitos para el sistema. La principal desventaja de este enfoque es que el proceso real de creación de un sistema nunca encaja completamente en un esquema tan rígido, siempre es necesario volver a etapas anteriores y aclarar o revisar decisiones tomadas anteriormente; Como resultado, el proceso real de creación de un SI corresponde a un modelo paso a paso con control intermedio.

Sin embargo, este esquema no nos permite tener en cuenta rápidamente los cambios emergentes y la aclaración de los requisitos del sistema. La coordinación de los resultados del desarrollo con los usuarios se lleva a cabo solo en los puntos planificados después de la finalización de cada etapa del trabajo, y los requisitos generales para el SI se registran en forma de especificaciones técnicas durante todo el tiempo de su creación. Por tanto, los usuarios suelen acabar con un sistema que no satisface sus necesidades reales.

Para superar estos problemas se propuso el modelo de ciclo de vida en espiral. En las etapas de análisis y diseño se verifica la viabilidad de las soluciones técnicas y el grado de satisfacción de las necesidades del cliente mediante la creación de prototipos. Cada vuelta de la espiral corresponde a la creación de un fragmento o versión viable del sistema. Esto le permite aclarar los requisitos, objetivos y características del proyecto, determinar la calidad del desarrollo y planificar el trabajo de la siguiente vuelta de la espiral. De esta manera, los detalles del proyecto se profundizan y se especifican consistentemente y, como resultado, se selecciona una opción razonable que satisfaga los requisitos reales del cliente y se lleva a la implementación.

El desarrollo iterativo refleja el ciclo espiral objetivamente existente de creación de sistemas complejos. Le permite pasar a la siguiente etapa sin esperar a que se complete por completo el trabajo en la actual y resolver la tarea principal: mostrar a los usuarios del sistema un producto funcional lo más rápido posible, activando así el proceso de aclaración y complementación de requisitos. .

La metodología de diseño de circuitos integrados cubre tres áreas principales:

• diseñar objetos de datos que se implementarán en la base de datos;
• diseñar programas, formularios de pantalla, informes que asegurarán la ejecución de consultas de datos;
• teniendo en cuenta un entorno o tecnología específica, a saber: topología de red, configuración de hardware, arquitectura utilizada (servidor de archivos o cliente-servidor), procesamiento paralelo, procesamiento distribuido de datos, etc.

El diseño de sistemas de información siempre comienza con la definición del propósito del proyecto.

El objetivo del proyecto se puede definir como la resolución de una serie de problemas interrelacionados, incluidos los siguientes puntos:

• implementación de la funcionalidad requerida del sistema y el nivel de su adaptabilidad a las condiciones operativas cambiantes;
• implementación de la capacidad requerida del sistema;
• implementación del tiempo de respuesta requerido del sistema a una solicitud;
• implementación del funcionamiento sin problemas del sistema;
• implementación del nivel de seguridad requerido;
• implementación de facilidad de operación y soporte del sistema.

Según la metodología de diseño moderna, el proceso de creación de un empresario individual se divide en las siguientes etapas (etapas)::

1. Formación de requisitos del sistema: La tarea de formar requisitos para los sistemas de información es una de las más importantes, difíciles de formalizar y la más costosa y difícil de corregir en caso de error. En esta etapa se lleva a cabo el modelado de los procesos de negocio que ocurren en la organización y la consecución de sus metas y objetivos. Para hacer esto, es necesario determinar los requisitos del cliente para SI y mapearlos en lenguaje modelo en los requisitos para desarrollar un proyecto de SI para garantizar el cumplimiento de las metas y objetivos de la organización. Al final de la etapa, obtenemos un modelo de la organización, descrito en términos de procesos de negocio y funciones de negocio.

2. Diseño: En la etapa de diseño, se forman modelos de datos. Los diseñadores reciben los resultados de un análisis de los requisitos de SI como información inicial. La construcción de modelos de datos lógicos y físicos es una parte fundamental del diseño de bases de datos. El modelo de información obtenido durante el proceso de análisis se convierte primero en un modelo de datos lógico y luego en uno físico. Paralelamente al diseño del esquema de la base de datos, se lleva a cabo el diseño del proceso para obtener especificaciones (descripciones) de todos los módulos IS. Al diseñar módulos, se determinan las interfaces del programa: diseño del menú, apariencia de la ventana, teclas de acceso rápido y llamadas relacionadas.

Los productos finales de la fase de diseño son:

· diagrama de la base de datos (basado en el modelo ER desarrollado en la etapa de análisis);

· un conjunto de especificaciones de los módulos del sistema (se construyen sobre la base de modelos funcionales).

· Diseño técnico del SI (especificaciones técnicas), anteproyecto, documentación de trabajo.

3. Implementación: En la etapa de implementación, se crea el software del sistema, se instala el hardware y se desarrolla la documentación operativa.

4. Pruebas: Suele aparecer distribuido en el tiempo. Después de completar el desarrollo de un módulo de sistema separado, realice prueba fuera de línea, que tiene dos objetivos principales:

• detección de fallas del módulo (fallas duras);
• cumplimiento del módulo con la especificación (presencia de todas las funciones necesarias, ausencia de funciones innecesarias).

Después la prueba autónoma pasa con éxito, el módulo se incluye en la parte desarrollada del sistema y el grupo de módulos generados pasa las pruebas de conexión que deben rastrear su influencia mutua.

A continuación, se prueba un grupo de módulos. para la confiabilidad operativa, es decir, se someten, en primer lugar, a pruebas que simulan fallas del sistema y, en segundo lugar, a pruebas entre fallas. El primer grupo de pruebas muestra qué tan bien se recupera el sistema de fallas de software y hardware. El segundo grupo de pruebas determina el grado de estabilidad del sistema durante el funcionamiento normal y le permite estimar el tiempo de actividad del sistema. El conjunto de pruebas de robustez debe incluir pruebas que simulen la carga máxima en el sistema.

Luego, todo el conjunto de módulos se somete a una prueba del sistema, una prueba interna de aceptación del producto, que muestra el nivel de calidad. Esto incluye pruebas de funcionalidad y pruebas de confiabilidad del sistema.

Última prueba del sistema de información.- prueba de aceptacion. Dicha prueba implica mostrar el sistema de información al cliente y debe contener un grupo de pruebas que simulen procesos comerciales reales para demostrar el cumplimiento de la implementación con los requisitos del cliente.

La metodología forma la base de cualquier diseño de sistema de información. La metodología se implementa a través de tecnologías específicas y los estándares, métodos y herramientas que las soportan, que posibilitan la realización de todos los procesos del ciclo de vida.

Hay dos metodologías de diseño principales:

Metodología de diseño estructural;

Metodología de diseño orientada a objetos.

Enfoque estructural. La esencia del enfoque estructural para el desarrollo de SI radica en su descomposición (desglose) en funciones automatizadas: el sistema se divide en subsistemas funcionales, que a su vez se dividen en subfunciones, se subdividen en tareas, etc. El proceso de partición continúa hasta llegar a procedimientos específicos. Al mismo tiempo, el sistema automatizado mantiene una visión holística en la que todos los componentes están interconectados. Al desarrollar un sistema "de abajo hacia arriba", desde tareas individuales hasta todo el sistema, se pierde la integridad y surgen problemas en la conexión de la información de los componentes individuales.

Todos los componentes del sistema de información están interconectados, el sistema se desarrolla de arriba a abajo. Al desarrollar un sistema de abajo hacia arriba, se pierde integridad y surgen problemas con la unión de componentes.

Los modelos más comunes del enfoque estructural son:

SADT (Técnicas de diseño y análisis estructurado): describe modelos y diagramas funcionales;

DFD - Diagramas de flujo de datos - diagramas de flujo de datos;

ERD - Diagramas entidad-relación - diagramas “entidad-relación”.

En la etapa de diseño del SI, los modelos se amplían, perfeccionan y complementan con diagramas que reflejan la estructura del software: arquitectura del software, diagramas de bloques programas y diagramas de pantalla.

Los modelos listados juntos dan Descripción completa IP independientemente de si es existente o recientemente desarrollada. La composición de los diagramas en cada caso específico depende de la integridad requerida de la descripción del sistema.

Enfoque orientado a objetos. El concepto central del enfoque de diseño orientado a objetos es la clase. Una clase es una selección del mundo circundante de una determinada entidad para la cual se definen atributos (propiedades) y operaciones (acciones que la entidad realiza sobre los objetos circundantes).

Un objeto es una implementación específica de alguna entidad. Un objeto encapsula alguna parte de la aplicación, que puede ser un proceso, un grupo de datos o alguna entidad más compleja.

Se eligió un enfoque orientado a objetos para implementar el proyecto debido a los siguientes factores:

Posibilidad de reutilización de código;

Mejorar la seguridad del código mediante la encapsulación;

Flexibilidad a la hora de modificar y ampliar el sistema;

No es necesario desarrollar clases desde cero debido a la herencia;

El enfoque general de la tecnología orientada a objetos en el desarrollo de sistemas de información, como clase de software, etc.

Informática, cibernética y programación.

En general, el objetivo del proyecto puede definirse como la resolución de una serie de tareas interrelacionadas, incluida la garantía en el momento del lanzamiento del sistema y durante su funcionamiento: la funcionalidad requerida del sistema y el nivel de su adaptabilidad a las condiciones operativas cambiantes; rendimiento requerido del sistema; tiempo de respuesta requerido del sistema a una solicitud; funcionamiento sin problemas del sistema; nivel de seguridad requerido; facilidad de operación y soporte del sistema. Los productos finales de la etapa de diseño son: diagrama base...

1. Conceptos básicos de la metodología de diseño de circuitos integrados.

El diseño de circuitos integrados cubre tres áreas principales:

1. diseñar objetos de datos que se implementarán en la base de datos;
2. diseñar programas, formularios de pantalla, informes que asegurarán la ejecución de consultas de datos;
3. teniendo en cuenta un entorno o tecnología específica, a saber: topología de red, configuración de hardware, arquitectura utilizada (servidor de archivos o cliente-servidor), procesamiento paralelo, procesamiento distribuido de datos, etc.

El diseño de sistemas de información siempre comienza con la definición del propósito del proyecto. En términos generales, el objetivo del proyecto se puede definir como la resolución de una serie de tareas interrelacionadas, incluida la garantía en el momento del lanzamiento del sistema y durante todo el período de su funcionamiento:

1. la funcionalidad requerida del sistema y el nivel de su adaptabilidad a las condiciones operativas cambiantes;
2. rendimiento requerido del sistema;
3. tiempo de respuesta requerido del sistema a una solicitud;
4. funcionamiento sin problemas del sistema;
5. nivel de seguridad requerido;
6. facilidad de operación y soporte del sistema.

Según la metodología moderna, el proceso de creación de un SI es un proceso de construcción y transformación secuencial de una serie de modelos coordinados en todas las etapas del ciclo de vida (LC) del SI. En cada etapa del ciclo de vida, se crean modelos específicos: organización, requisitos de SI, proyecto de SI, requisitos de aplicación, etc. Los modelos están formados por grupos de trabajo del equipo del proyecto, guardados y acumulados en el repositorio del proyecto. La creación de modelos, su control, transformación y puesta a disposición para uso colectivo se realiza mediante medios especiales. herramientas de software- Herramientas CASE.

Los productos finales de la fase de diseño son:

1. diagrama de base de datos (basado en el modelo ER desarrollado en la etapa de análisis);
2. un conjunto de especificaciones de los módulos del sistema (se construyen sobre la base de modelos funcionales).

La etapa de diseño finaliza con el desarrollo de un diseño técnico del IP.

En la etapa de implementación, se crea el software del sistema, se instala el hardware y se desarrolla la documentación operativa.

La fase de prueba suele distribuirse en el tiempo.

Después de completar el desarrollo de un módulo de sistema individual, se realiza una prueba independiente, que tiene dos objetivos principales:

1. detección de fallas del módulo (fallas duras);
2. cumplimiento del módulo con la especificación (presencia de todas las funciones necesarias, ausencia de funciones innecesarias).
3. ciclo de vida de la propiedad intelectual

El concepto de ciclo de vida es uno de los básicos en ingeniería de software. El ciclo de vida del software se define como un período de tiempo que comienza desde el momento en que se toma la decisión sobre la necesidad de crear software y finaliza en el momento en que se retira completamente del servicio (IEEE Std 610.12 - 1990).

El principal documento normativo que regula la composición de los procesos del ciclo de vida del software es la norma internacional ISO/IEC 12207: 1995. De acuerdo con esta norma, todos los procesos del ciclo de vida del software se dividen en tres grupos:

Cinco procesos principales (compra, suministro, desarrollo, operación, soporte);

Ocho procesos de soporte que respaldan la ejecución de procesos centrales (documentación, gestión de configuración, aseguramiento de la calidad, verificación, certificación, evaluación conjunta, auditoría, resolución de problemas);

Cuatro procesos organizacionales (gestión, creación de infraestructura, mejora, capacitación).

Procesos básicos

1. Proceso de adquisiciónConsiste en las acciones y tareas del cliente que compra el software.

2. Proceso de entregacubre las actividades y tareas realizadas por el proveedor que suministra al cliente un producto o servicio de software.

3. Proceso de desarrolloImplica las acciones y tareas realizadas por el desarrollador y cubre el trabajo de creación de software.

4. Proceso de operaciónCubre las actividades y tareas de la organización que opera el sistema.

5. Proceso de mantenimientoprevé acciones y tareas realizadas por el servicio de mantenimiento al cambiar o adaptar el software.

Procesos auxiliares

1. Proceso de documentacionProporciona una descripción formalizada de la información creada durante el ciclo de vida del software.

2. Proceso de gestión de configuraciónle permite tener en cuenta y controlar los cambios en el software en todas las etapas del ciclo de vida.

3. Proceso de garantía de calidadproporciona garantías adecuadas de que el software y sus procesos de ciclo de vida cumplen con los requisitos especificados y los planes aprobados.

4. Proceso de verificaciónes determinar la corrección del software.

5. Proceso de atestaciónprevé determinar la integridad del cumplimiento de los requisitos especificados y el sistema creado con su propósito funcional específico.

6. Proceso de evaluación participativadiseñado para evaluar el estado del trabajo en el proyecto.

7. Proceso de auditoría representa una determinación del cumplimiento de los requisitos, planos y términos del contrato.

8. Proceso de resolución de problemasImplica el análisis y resolución de problemas que se descubren durante el desarrollo, operación, mantenimiento u otros procesos, independientemente de su origen o fuente.

Procesos organizacionales

1. Proceso de gestiónConsiste en acciones y tareas que puede realizar cualquier parte que gestione sus procesos (compra, entrega, etc.).

2. Proceso de creación de infraestructuracubre la selección y soporte de tecnología, estándares y herramientas, la selección e instalación de hardware y software utilizados para desarrollar, operar o mantener software.

3. Proceso de mejoraproporciona evaluación, medición, control y mejora de los procesos del ciclo de vida del software.

4. Proceso de aprendizajecubre la formación inicial y el posterior desarrollo profesional continuo del personal.

Relación entre procesos

Los procesos del ciclo de vida del software regulados por ISO/IEC 12207 pueden ser utilizados por diferentes organizaciones en proyectos específicos de diversas maneras. Sin embargo, el estándar proporciona un conjunto básico de relaciones entre procesos desde diferentes perspectivas (o aspectos), como se muestra en la Fig. 2.1. Estos aspectos son:

Aspecto contractual;

Aspecto de gestión;

Aspecto operativo;

Aspecto de ingeniería;

Aspecto de soporte.

3. Modelos de ciclo de vida del software.

Bajo el modelo del ciclo de vida. entiende la estructura que determina la secuencia de ejecución y las relaciones entre procesos, acciones y tareas a lo largo del ciclo de vida.

El estándar ISO/IEC 12207 no proporciona un modelo de ciclo de vida específico ni métodos de desarrollo de software. Sus disposiciones son comunes a cualquier modelo de ciclo de vida, métodos y tecnologías de desarrollo de software. El modelo de ciclo de vida es un conjunto de trabajos ordenados en el tiempo, interconectados y combinados en etapas.

El ciclo de vida del software generalmente incluyepróximas etapas:

1. Formación de requisitos de software.
   1. Diseño.
      1. Implementación.
      2. Pruebas.
      3. Puesta en servicio.
      4. Operación y mantenimiento.
      5. Desmantelamiento.

En cada etapa se pueden realizar varios procesos definidos en la norma. ISO/CEI 12207 y, a la inversa, el mismo proceso se puede realizar en diferentes etapas.

Hasta la fecha, los modelos del ciclo de vida del software en cascada (1970 - 1985) y en espiral (1986 - 1990) se han generalizado.

La característica fundamental del modelo de ciclo de vida en cascada (Fig. 2.2) es que la transición a la siguiente etapa se lleva a cabo solo después de que el trabajo en la etapa actual se completa por completo y no se proporcionan retornos a las etapas completadas. Cada etapa finaliza con la decadencia de algunos resultados, que sirven como datos enigmáticos para la siguiente etapa.

Cada etapa culmina con la publicación de un conjunto completo de documentación suficiente para permitir que otro equipo de desarrollo continúe el desarrollo.

Arroz. 2.2. Esquema de desarrollo de software en cascada.

Las ventajas de utilizar el método en cascada son las siguientes:

1. en cada etapa se genera un conjunto completo de documentación de diseño;
2. conviene planificar las fechas de finalización de todos los trabajos y los costes correspondientes.

La desventaja del diseño en cascada es que el proceso real de creación de software nunca encaja completamente en un patrón tan rígido. Este proceso, por regla general, es de naturaleza iterativa, es decir. Los resultados de la siguiente etapa a menudo provocan cambios en las soluciones de diseño desarrolladas en etapas anteriores. Como resultado, el proceso real de creación de software adquiere una forma diferente (Fig. 2.3). Esto provoca un retraso en la obtención de resultados. Como resultado, aumenta el riesgo de crear un sistema que no satisfaga las necesidades cambiantes de los usuarios.

Por lo general, en la etapa inicial de un proyecto, no es posible formular de manera completa y precisa todos los requisitos para el futuro sistema. Esto se debe a dos razones:

1. Los usuarios no pueden expresar todos sus requisitos a la vez y no pueden prever cómo cambiarán durante el desarrollo;
2. Durante el desarrollo, pueden ocurrir cambios en el entorno externo que afectarán los requisitos del sistema.

Arroz. 2.3. Proceso de desarrollo de software real

Para superar estos problemas a mediados de los años 80. Se propuso un modelo de ciclo de vida en espiral (Fig. 2.4). Su característica fundamental es que el software no se crea inmediatamente, como en el caso del método en cascada, sino por partes, utilizando el método de creación de prototipos. Se entiende por prototipo un componente de software funcional que implementa funciones individuales e interfaces externas del software que se está desarrollando. La creación de prototipos se lleva a cabo en varias iteraciones o giros en espiral. Cada iteración corresponde a la creación de una versión del software, donde se aclaran los objetivos y características del proyecto, se evalúa la calidad de los resultados obtenidos y se planifica el trabajo de la siguiente iteración.

El modelo en espiral libera a los usuarios y desarrolladores de software de la necesidad de formular de forma completa y precisa los requisitos del sistema en la etapa inicial, ya que se perfeccionan en cada iteración.

El modelo en espiral no excluye el uso de un enfoque en cascada en las etapas finales del proyecto en los casos en que los requisitos para el sistema estén completamente definidos.

El principal problema del ciclo en espiral es determinar el momento de transición a la siguiente etapa.

Arroz. 2.4. Modelo en espiral del software del ciclo de vida.

4. Requisitos generales de metodología y tecnología.

Metodologías, tecnologías y herramientas de diseño (herramientas CASE) forman la base de cualquier proyecto de SI. La metodología se implementa a través de tecnologías específicas y estándares, métodos y herramientas de soporte que aseguran la implementación de los procesos del ciclo de vida.

La tecnología de diseño se define como una combinación de tres componentes:

1. procedimiento paso a paso que define la secuencia de operaciones de diseño tecnológico (Fig. 1.4);
2. criterios y reglas utilizados para evaluar los resultados de las operaciones tecnológicas;
3. notaciones (medios gráficos y textuales) utilizadas para describir el sistema que se está diseñando.

Arroz. 1.4. Representación de la operación de diseño tecnológico.

Instrucciones tecnológicas, que constituye el contenido principal de la tecnología, debe consistir en una descripción de la secuencia de operaciones tecnológicas, las condiciones según las cuales se realiza una u otra operación y descripciones de las operaciones mismas.

La tecnología para el diseño, desarrollo y mantenimiento de SI debe cumplir los siguientes requisitos generales:

1. la tecnología debe soportar el ciclo de vida completo del software;
2. La tecnología debe garantizar el logro de los objetivos de desarrollo de SI con una calidad determinada y en fijar tiempo;
3. la tecnología debe proporcionar la capacidad de implementar grandes proyectos en forma de subsistemas (es decir, la capacidad de descomponer el proyecto en componentes desarrollados por grupos de artistas limitados con su posterior integración). componentes). La experiencia en el desarrollo de SI a gran escala muestra que para aumentar la eficiencia del trabajo, es necesario dividir el proyecto en subsistemas separados que están débilmente conectados en términos de datos y funciones. La implementación de subsistemas debe realizarse grupos separados especialistas. Al mismo tiempo, es necesario garantizar la coordinación proyecto común y eliminar la duplicación de trabajo de cada grupo de proyecto que pueda surgir debido a la presencia de datos y funciones comunes;
4. la tecnología debe proporcionar la capacidad de realizar trabajos de diseño de subsistemas individuales en grupos pequeños (3-7 personas). Esto se debe a los principios de gestión de equipos y al aumento de la productividad minimizando el número. relaciones Externas;
5. la tecnología debe garantizar el tiempo mínimo para obtener un SI funcional. Se trata de no se trata del momento de preparación de todo el SI, sino del momento de implementación de los subsistemas individuales. La implementación de un SI en su conjunto en poco tiempo puede requerir la participación de una gran cantidad de desarrolladores, y el efecto puede ser menor que cuando los subsistemas individuales son implementados en un tiempo más corto por un número menor de desarrolladores. La práctica demuestra que incluso con un proyecto completamente completado, la implementación se realiza de forma secuencial en todos los subsistemas individuales;
6. la tecnología debe brindar la capacidad de gestionar la configuración del proyecto, mantener versiones del proyecto y sus componentes, la capacidad de publicar automáticamente la documentación del proyecto y sincronizar sus versiones con las versiones del proyecto;
7. la tecnología debe garantizar la independencia de las soluciones de diseño implementadas de las herramientas de implementación de SI (sistemas de gestión de bases de datos (DBMS), sistemas operativos, lenguajes y sistemas de programación);
8. la tecnología debe estar respaldada por un conjunto de herramientas CASE coordinadas que garanticen la automatización de los procesos realizados en todas las etapas del ciclo de vida. El enfoque general para la evaluación y selección de herramientas CASE se describe en la Sección 4, ejemplos de complejos de herramientas CASE se encuentran en la subsección 5.7.

La aplicación real de cualquier tecnología para el diseño, desarrollo y mantenimiento de sistemas de información en una organización específica y un proyecto específico es imposible sin el desarrollo de una serie de estándares (reglas, acuerdos) que deben ser observados por todos los participantes del proyecto. Estos estándares incluyen lo siguiente:

1. estándar de diseño;
2. estándar para documentación de diseño;
3. estándar de interfaz de usuario.

La norma de diseño debe establecer:

1. equipo modelos requeridos(diagramas) en cada etapa de diseño y el grado de detalle;
2. reglas para registrar decisiones de diseño en diagramas, que incluyen: reglas para nombrar objetos (incluidas convenciones terminológicas), un conjunto de atributos para todos los objetos y reglas para completarlos en cada etapa, reglas para diseñar diagramas, incluidos requisitos para la forma y el tamaño de objetos, etc.;
3. requisitos para la configuración de estaciones de trabajo de desarrolladores, incluida la configuración del sistema operativo, la configuración de la herramienta CASE, la configuración general del proyecto, etc.;
4. un mecanismo para garantizar la colaboración en un proyecto, que incluye: reglas para integrar los subsistemas del proyecto, reglas para mantener el proyecto en el mismo estado para todos los desarrolladores (regulaciones para el intercambio de información del proyecto, un mecanismo para registrar objetos comunes, etc.), reglas para comprobar la coherencia de las soluciones de diseño, etc. .d.

La norma de documentación de diseño debe establecer:

1. integridad, composición y estructura de la documentación en cada etapa de diseño;
2. requisitos para su diseño (incluidos requisitos para el contenido de secciones, subsecciones, párrafos, tablas, etc.),
3. reglas para la elaboración, revisión, coordinación y aprobación de la documentación, indicando plazos para cada etapa;
4. requisitos para configurar un sistema de publicación utilizado como herramienta incorporada de preparación de documentación;
5. Requisitos para la configuración de herramientas CASE que aseguren la preparación de la documentación de acuerdo con los requisitos establecidos.

El estándar de interfaz de usuario debe establecer:

1. reglas de diseño de pantalla (fuentes y paleta de colores), composición y disposición de ventanas y controles;
2. reglas para usar el teclado y el mouse;
3. reglas para formatear textos de ayuda;
4. lista de mensajes estándar;

reglas para procesar las reacciones de los usuarios.

5. Metodología RAD

Uno de los posibles enfoques para el desarrollo de software en el marco del modelo de ciclo de vida en espiral es la metodología recientemente difundida para el desarrollo rápido de aplicaciones. RAD (Desarrollo rápido de aplicaciones ). Este término suele referirse a un proceso de desarrollo de software que contiene 3 elementos:

un pequeño equipo de programadores (de 2 a 10 personas);

cronograma de producción breve pero cuidadosamente elaborado (de 2 a 6 meses);

un ciclo iterativo en el que los desarrolladores, a medida que la aplicación comienza a tomar forma, solicitan e implementan en el producto los requisitos recibidos a través de la interacción con el cliente.

El equipo de desarrollo debe ser un grupo de profesionales con experiencia en análisis, diseño, generación de código y pruebas de software utilizando CASO - medio Los miembros del equipo también deben poder traducir las sugerencias de los usuarios finales en prototipos funcionales.

Ciclo de vida del software según metodología. RAD consta de cuatro fases:

1. fase de análisis y planificación de requisitos;
2. fase de diseño;
3. fase de construcción;
4. fase de implementación.

Principios básicos de la metodología. RAD:

1. desarrollar aplicaciones en iteraciones;
2. la opción de completar el trabajo en cada etapa del ciclo de vida;
3. participación obligatoria de los usuarios en el proceso de desarrollo de SI;
4. solicitud requerida CASO - significa garantizar la integridad del proyecto;
5. Uso de herramientas de gestión de configuración para facilitar los cambios de diseño y el mantenimiento. sistema terminado;
6. uso necesario generadores de códigos;
7. el uso de prototipos para comprender y satisfacer mejor las necesidades del usuario final;
8. prueba y desarrollo del proyecto, realizado simultáneamente con el desarrollo;
9. desarrollo por un equipo pequeño y bien administrado de profesionales;

Gestión competente del desarrollo de sistemas, planificación clara y control de la ejecución del trabajo.

6. Enfoque estructural del diseño de SI

7. La esencia del enfoque estructural del diseño de SI

La esencia del enfoque estructural para el desarrollo de software de SI radica en su descomposición en funciones automatizadas: el sistema se divide en subsistemas funcionales, que, a su vez, se dividen en subfunciones y así sucesivamente en procedimientos específicos. Al mismo tiempo, el sistema conserva una representación oral en la que todos los componentes están interconectados.

Los principios básicos de un enfoque estructurado para el desarrollo de software de SI son:

1. El principio de “divide y vencerás”.
2. El principio de ordenamiento jerárquico es el principio de organizar los componentes de un sistema en estructuras de árbol jerárquicas con la adición de nuevos detalles en cada nivel.
3. El principio de abstracción es la selección de aspectos esenciales del sistema y la abstracción de los no esenciales.
4. El principio de coherencia es la validez y coherencia de los elementos del sistema.
5. El principio de estructuración de datos: los datos deben estar estructurados y organizados jerárquicamente.

El enfoque estructural utiliza principalmente dos grupos de herramientas:

1. Medios para la descripción estructura funcional sistemas.
2. Herramientas para describir relaciones entre datos.

Cada grupo de fondos corresponde a determinados tipos de modelos:

1. Modelos SADT (Técnica de Análisis y Diseño Estructurado) y diagramas funcionales correspondientes;
2. diagramas de flujo de datos DFD (Diagramas de flujo de datos);
3. ERD (diagramas entidad-relación) diagramas entidad-relación.

8. Metodología de modelado funcional SADT

La metodología SADT fue desarrollada por Douglas Ross. Sobre esta base se desarrolló la conocida metodología IDEF0 (Icam DEFinition). La metodología SADT es un conjunto de métodos, reglas y procedimientos diseñados para construir un modelo funcional de un objeto en cualquier área temática. El modelo funcional SADT refleja la estructura funcional de un objeto, es decir las acciones que realiza y las conexiones entre estas acciones. Los principales elementos de esta metodología se basan en los siguientes conceptos:

Representación gráfica del modelado de bloques. Los gráficos de bloque y arco del diagrama SADT muestran la función como un bloque, y las interfaces de entrada/salida están representadas por arcos que entran y salen del bloque, respectivamente. La interacción de los bloques entre sí se describe mediante arcos de interfaz que expresan "restricciones", que a su vez determinan cuándo y cómo se realizan y controlan las funciones;

Rigor y precisión. La implementación de las reglas SADT requiere suficiente rigor y precisión sin imponer restricciones indebidas a las acciones del analista.Las reglas SADT incluyen:

1. limitar el número de bloques en cada nivel de descomposición (regla 3-6 bloques);
2. conectividad de diagramas (números de bloque);
3. unicidad de etiquetas y nombres (sin nombres duplicados);
4. reglas sintácticas para gráficos (bloques y arcos);
5. separación de entradas y controles (regla para determinar el papel de los datos).
6. separación de la organización de la función, es decir eliminando la influencia de la estructura organizativa en el modelo funcional.

La metodología SADT se puede utilizar para modelar una amplia gama de sistemas y definir requisitos y funciones, y luego diseñar un sistema que satisfaga esos requisitos e implemente esas funciones. Para los sistemas existentes, SADT se puede utilizar para analizar las funciones realizadas por el sistema e indicar los mecanismos mediante los cuales se realizan.

9. Composición del modelo funcional

El resultado de aplicar la metodología SADT es un modelo que consta de diagramas, fragmentos de texto y un glosario que tienen enlaces entre sí. Los diagramas son los componentes principales del modelo; todas las funciones e interfaces de IS se presentan en ellos como bloques y arcos. La ubicación donde el arco se conecta al bloque determina el tipo de interfaz. La información de control ingresa al bloque en la parte superior, mientras que la información que se está procesando se muestra en el lado izquierdo del bloque y los resultados de salida se muestran en el lado derecho. El mecanismo (sistema humano o automatizado) que realiza la operación está representado por un arco que ingresa al bloque desde abajo (Fig. 1).

Una de las características más importantes de la metodología SADT es la introducción gradual de niveles cada vez mayores de detalle a medida que se crean diagramas que representan el modelo.

Figura 1. Bloque funcional y arcos de interfaz.

10. Jerarquía de diagramas

La construcción de un modelo SADT comienza con la representación de todo el sistema en forma del componente más simple: un bloque y arcos que representan interfaces con funciones fuera del sistema. Debido a que un solo bloque representa todo el sistema, el nombre especificado en el bloque es genérico. Esto también se aplica a los arcos de interfaz: también representan un conjunto completo interfaces externas sistemas en su conjunto.

El bloque que representa el sistema como un solo módulo se detalla luego en otro diagrama utilizando varios bloques conectados por arcos de interfaz. Estos bloques representan las principales subfunciones de la función original. Esta descomposición revela un conjunto completo de subfunciones, cada una de las cuales se representa como un bloque, cuyos límites están definidos por arcos de interfaz. Cada una de estas subfunciones se puede descomponer de manera similar para proporcionar una representación más detallada.

En todos los casos, cada subfunción puede contener sólo aquellos elementos que están incluidos en la función original. Además, el modelo no puede omitir ningún elemento, es decir, como ya se señaló, el bloque principal y sus interfaces proporcionan contexto. No se le puede agregar nada ni quitarle nada.

El modelo SADT es una serie de diagramas con documentación adjunta que descompone un objeto complejo en sus partes componentes, que se presentan como bloques. Los detalles de cada uno de los bloques principales se muestran como recuadros en los demás diagramas. Cada diagrama detallado es una descomposición de un bloque de un diagrama más general. En cada paso de descomposición, el diagrama más general se denomina diagrama principal del diagrama más detallado.

Arcos que entran y salen de un bloque en un diagrama nivel superior, son exactamente iguales que los arcos que entran y salen del diagrama de nivel inferior, porque el bloque y el diagrama representan la misma parte del sistema.

Algunos arcos están conectados a los bloques del diagrama en ambos extremos, mientras que otros tienen un extremo suelto. Los arcos no conectados corresponden a entradas, controles y salidas del bloque principal. El origen o destino de estos arcos de límite solo se puede encontrar en el diagrama principal. Los extremos sueltos deben coincidir con los arcos del diagrama original. Todos los arcos de límites deben continuar en el diagrama principal para que sea completo y coherente.

Los diagramas SADT no indican explícitamente ni secuencia ni tiempo. Las retroalimentación, las iteraciones, los procesos en curso y las funciones superpuestas (de tiempo) se pueden representar mediante arcos. La retroalimentación puede ser en forma de comentarios, observaciones, correcciones, etc. (Figura 5).

Como se señaló, los mecanismos (arcos en la parte inferior) muestran los medios por los cuales se realizan las funciones. El mecanismo puede ser una persona, una computadora o cualquier otro dispositivo que ayude a realizar una función determinada (Figura 6).

Cada bloque del diagrama tiene su propio número. Un bloque de cualquier diagrama se puede describir con más detalle mediante un diagrama de nivel inferior, que a su vez se puede detallar más con el número requerido de diagramas. De este modo se forma una jerarquía de diagramas.

Los números de gráfico se utilizan para indicar la posición de cualquier gráfico o bloque en la jerarquía. Por ejemplo, A21 es un diagrama que detalla el bloque 1 en el diagrama A2. De manera similar, A2 detalla el bloque 2 en el diagrama A0, que es el diagrama superior del modelo. La Figura 7 muestra un diagrama de árbol típico.

11. Tipos de conexiones entre funciones

Uno de puntos importantes Al diseñar un SI utilizando la metodología SADT, existe una coherencia precisa en los tipos de conexiones entre funciones. Hay al menos siete tipos de encuadernación:

Tipo de comunicación	Importancia relativa
Aleatorio
Lógico
Temporario
Procesal
Comunicación
Secuencial
Funcional

A continuación, cada tipo de comunicación se define e ilustra brevemente utilizando un ejemplo típico de SADT.

(0) Tipo de conectividad aleatoria: menos deseable.La conectividad aleatoria ocurre cuando hay poca o ninguna conexión específica entre funciones. Esto se refiere a la situación en la que los nombres de datos en los arcos SADT en el mismo diagrama tienen poca relación entre sí. Una versión extrema de este caso se muestra en la figura:

(1) Tipo de conectividad lógica. El acoplamiento lógico ocurre cuando datos y funciones se reúnen porque pertenecen a una clase o conjunto de elementos común, pero no se encuentran las relaciones funcionales necesarias entre ellos.

(2) Tipo de conectividad temporal. Los elementos relacionados con el tiempo surgen porque representan funciones que están relacionadas en el tiempo, cuando los datos se usan simultáneamente o las funciones se habilitan en paralelo en lugar de secuencialmente.

(3) Tipo de coherencia procesal. Los elementos relacionados procesalmente aparecen agrupados porque se ejecutan durante la misma parte del ciclo o proceso. En la figura se muestra un ejemplo de un diagrama relacionado con el procedimiento:

(4) Tipo de conectividad de comunicación. Los diagramas muestran relaciones de comunicación donde los bloques se agrupan porque utilizan las mismas entradas y/o producen las mismas salidas.

(5) Tipo de conectividad secuencial.En diagramas secuenciales, la salida de una función sirve como entrada para siguiente función. La conexión entre los elementos del diagrama es más estrecha que en los niveles conectivos discutidos anteriormente, ya que se modelan las dependencias de causa y efecto.

(6) Tipo de conectividad funcional. El diagrama refleja una conectividad funcional completa, en presencia de una dependencia total de una función de otra. Un diagrama que es puramente funcional no contiene elementos extraños pertenecientes al tipo de conectividad secuencial o más débil. Una forma de definir diagramas funcionalmente relacionados es considerar dos bloques conectados a través de arcos de control.

En términos matemáticos, la condición necesaria para el tipo más simple de conectividad funcional, que se muestra en la Figura 12, es la siguiente:

C = gramo(B) = gramo(f(A))

Significado	Tipo de conectividad	Para funciones	Para datos
	Aleatorio	Aleatorio	Aleatorio
	Lógico	Funciones del mismo conjunto o tipo (por ejemplo, "editar todas las entradas")	Datos del mismo conjunto o tipo
	Temporario	Funciones del mismo período de tiempo (p. ej.	"operaciones de inicialización")
	Procesal	Funciones que se ejecutan en la misma fase o iteración (por ejemplo, "primer paso del compilador")	Datos utilizados durante la misma fase o iteración.
	Comunicación	Funciones que utilizan los mismos datos.	Datos afectados por la misma actividad
	Secuencial	Funciones que realizan transformaciones secuenciales de los mismos datos.	Datos convertidos por funciones secuenciales.
	Funcional	Funciones combinadas para realizar una sola función.	Datos asociados con una función.

Es importante señalar que los niveles 4 a 6 establecen los tipos de conectividad que los desarrolladores consideran esenciales para producir diagramas de buena calidad.

12. Modelado de flujos de datos (procesos)

Esta metodología (la metodología Gane/Sarson) se basa en la construcción de un modelo del SI analizado, diseñado o realmente existente. De acuerdo con la metodología, el modelo del sistema se define como una jerarquía de diagramas de flujo de datos (DFD o DFD), que describen el proceso asincrónico de transformación de la información desde su entrada al sistema hasta su entrega al usuario. Los diagramas de los niveles superiores de la jerarquía (diagramas de contexto) definen los principales procesos o subsistemas del SI con entradas y salidas externas. Se detallan mediante diagramas de nivel inferior. Esta descomposición continúa, creando una jerarquía de diagramas de múltiples niveles, hasta que se alcanza tal nivel de descomposición en el que el proceso se vuelve elemental y es imposible detallarlos más.

Las fuentes de información (entidades externas) generan flujos de información (flujos de datos) que transfieren información a subsistemas o procesos. Éstos, a su vez, transforman la información y generan nuevos flujos que transfieren información a otros procesos o subsistemas, dispositivos de almacenamiento de datos o entidades externas: consumidores de información. Así, los principales componentes de los diagramas de flujo de datos son:

1. entidades externas;
2. sistemas/subsistemas;
3. procesos;
4. dispositivos de almacenamiento de datos;
5. flujos de datos.

Una entidad externa es un objeto material o individual, que representa una fuente o receptor de información, por ejemplo, clientes, personal, proveedores, clientes, almacén. Definir un objeto o sistema como una entidad externa indica que está fuera de los límites del SI analizado. Durante el proceso de análisis, algunas entidades externas pueden transferirse dentro del diagrama del SI analizado, si es necesario, o, por el contrario, parte de los procesos de SI pueden moverse fuera del diagrama y presentarse como una entidad externa.

Al construir un modelo de un SI complejo, se puede presentar en la forma más general en el llamado diagrama de contexto en forma de un sistema como un todo único, o se puede descomponer en varios subsistemas.

El número del subsistema sirve para identificarlo. En el campo de nombre, ingrese el nombre del subsistema en forma de oración con un sujeto y las definiciones y adiciones correspondientes.

El proceso consiste en la transformación de flujos de datos de entrada en flujos de salida de acuerdo con un algoritmo específico. Físicamente, el proceso se puede implementar de varias maneras: puede ser una división de la organización (departamento) que procesa documentos de entrada y emite informes, un programa, un dispositivo lógico implementado en hardware, etc.

El número de proceso sirve para identificarlo. En el campo de nombre, ingrese el nombre del proceso en forma de oración con un verbo activo e inequívoco en forma indefinida (calcular, calcular, verificar, determinar, crear, recibir), seguido de sustantivos en caso acusativo, por ejemplo:

1. "Ingrese la información del cliente";
2. "Proporcionar información sobre gastos actuales";
3. "Compruebe la solvencia del cliente".

El uso de verbos como “procesar”, “actualizar” o “editar” generalmente significa que el proceso no se comprende con suficiente profundidad y requiere un análisis más profundo.

La información en el campo de implementación física indica qué unidad organizativa, programa o dispositivo de hardware está ejecutando el proceso.

Una unidad de datos es un dispositivo abstracto para almacenar información que se puede colocar en la unidad en cualquier momento y recuperar después de un tiempo, y los métodos para colocar y recuperar pueden ser cualquiera.

El dispositivo de almacenamiento de datos se puede implementar físicamente en forma de microficha, caja en un archivador, tabla en RAM, archivo en soporte magnético, etc.

El dispositivo de almacenamiento de datos se identifica con la letra "D" y un número arbitrario. El nombre de la unidad se elige para que sea más informativo para el diseñador.

Un dispositivo de almacenamiento de datos, en general, es un prototipo de una futura base de datos, y la descripción de los datos almacenados en él debe estar vinculada al modelo de información.

Un flujo de datos define la información transmitida a través de alguna conexión desde un origen a un destino. El flujo de datos real puede ser información transmitida por un cable entre dos dispositivos, cartas enviadas por correo, cintas magnéticas o disquetes transferidos de una computadora a otra, etc.

El flujo de datos en un diagrama está representado por una línea que termina en una flecha que muestra la dirección del flujo. Cada flujo de datos tiene un nombre que refleja su contenido.

13. Construir una jerarquía de diagramas de flujo de datos.

El primer paso para construir una jerarquía DPD es construir diagramas de contexto. Normalmente, al diseñar circuitos integrados relativamente simples, se construye un diagrama de contexto único con una topología en estrella, en cuyo centro se encuentra el llamado proceso principal, conectado a los sumideros y fuentes de información a través de los cuales los usuarios y otros sistemas externos interactúan con el sistema.

Si por sistema complejo limítese a un solo diagrama de contexto, contendrá demasiadas fuentes y receptores de información que son difíciles de organizar en una hoja de papel de tamaño normal y, además, un solo proceso principal no revela la estructura. Sistema distribuido. Los signos de complejidad (en términos de contexto) pueden incluir:

la presencia de una gran cantidad de entidades externas (diez o más);

naturaleza distribuida del sistema;

multifuncionalidad del sistema con una agrupación de funciones ya establecida o identificada en subsistemas separados.

Para SI complejos, se construye una jerarquía de diagramas de contexto. Al mismo tiempo, el diagrama de contexto de nivel superior no contiene un solo proceso principal, sino un conjunto de subsistemas conectados por flujos de datos. El siguiente nivel de diagramas de contexto detalla el contexto y la estructura de los subsistemas.

La jerarquía de los diagramas de contexto determina la interacción de los principales subsistemas funcionales del SI diseñado tanto entre ellos como con flujos de datos externos de entrada y salida y objetos externos (fuentes y receptores de información) con los que interactúa el SI.

El desarrollo de diagramas de contexto resuelve el problema de definir estrictamente la estructura funcional de un SI en la etapa más temprana de su diseño, lo cual es especialmente importante para sistemas multifuncionales complejos en cuyo desarrollo participan diferentes organizaciones y equipos de desarrollo.

Después de construir diagramas de contexto, se debe verificar que el modelo resultante esté completo de los datos iniciales sobre los objetos del sistema y el aislamiento de los objetos (ausencia de conexiones de información con otros objetos).

Para cada subsistema presente en los diagramas de contexto, se detalla mediante DPD. Cada proceso en una DPD, a su vez, se puede detallar utilizando una DPD o una miniespecificación. Al detallar, se deben seguir las siguientes reglas:

1. regla de equilibrio: significa que al detallar un subsistema o proceso, el diagrama de detalle como fuentes/receptores de datos externos solo puede tener aquellos componentes (subsistemas, procesos, entidades externas, dispositivos de almacenamiento de datos) con los que el subsistema o proceso detallado en el diagrama principal tiene una conexión de información;
2. regla de numeración: significa que al detallar procesos, se debe mantener su numeración jerárquica. Por ejemplo, los procesos que detallan el proceso número 12 reciben los números 12.1, 12.2, 12.3, etc.

La mini-especificación (descripción de la lógica del proceso) debe formular sus funciones principales de tal manera que en el futuro el especialista que implementa el proyecto pueda llevarlas a cabo o desarrollar un programa adecuado.

La miniespecificación es la última cima de la jerarquía DPD. La decisión de completar el proceso detallando y utilizar la miniespecificación la toma el analista basándose en los siguientes criterios:

1. el proceso tiene una cantidad relativamente pequeña de flujos de datos de entrada y salida (2-3 flujos);
2. la capacidad de describir la transformación de datos mediante un proceso en forma de algoritmo secuencial;
3. el proceso realiza una única función lógica de convertir información de entrada en información de salida;
4. la capacidad de describir la lógica del proceso utilizando una pequeña mini-especificación (no más de 20-30 líneas).

Al construir una jerarquía DPD, debe proceder a detallar los procesos solo después de determinar el contenido de todos los flujos y unidades de datos, que se describe mediante estructuras de datos. Las estructuras de datos se construyen a partir de elementos de datos y pueden contener alternativas, ocurrencias condicionales e iteraciones. La ocurrencia condicional significa que un componente determinado puede no estar presente en la estructura. Alternativa significa que la estructura puede incluir uno de los elementos enumerados. Iteración significa ingresar cualquier número de elementos en un rango específico. Para cada elemento de datos, se puede especificar su tipo (datos continuos o discretos). Para datos continuos, se puede especificar la unidad de medida (kg, cm, etc.), el rango de valores, la precisión de la presentación y la forma de codificación física. Para datos discretos, se puede especificar una tabla de valores aceptables.

Después de construir un modelo de sistema completo, se debe verificar (verificar su integridad y coherencia). En un modelo completo, todos sus objetos (subsistemas, procesos, flujos de datos) deben estar descritos y detallados en detalle. Los objetos no detallados identificados deben detallarse volviendo a los pasos de desarrollo anteriores. En un modelo consistente, todos los flujos de datos y dispositivos de almacenamiento de datos deben seguir la regla de retención de información: todos los datos que llegan a algún lugar deben leerse y todos los datos leídos deben escribirse.

14. Modelado de datos

Una de las partes principales del soporte de información es la base de información. Una base de información (IB) es una colección de datos, organizados de una determinada manera y almacenados en la memoria de un sistema informático en forma de archivos, con cuya ayuda se satisfacen las necesidades de información de los procesos de gestión y las tareas a resolver. . El desarrollo de bases de datos se realiza mediante modelado de datos. El propósito del modelado de datos es proporcionar al desarrollador de SI un esquema conceptual de la base de datos en forma de uno o más modelos. modelos locales, que se puede asignar con relativa facilidad a cualquier sistema de base de datos. La herramienta de modelado de datos más común son los diagramas entidad-relación (ERD). Con la ayuda de ERD, se detalla el almacenamiento de datos del diagrama DFD y se documentan aspectos de información del sistema empresarial, incluida la identificación de objetos importantes para el área temática (entidades), las propiedades de estos objetos (atributos) y sus conexiones con otros. objetos (relaciones).

Modelos de teoría de conjuntos de UD: jerárquico, de red, relacional

15. Método del caso de Barker

El propósito del modelado de datos es proporcionar al desarrollador del sistema de información un diagrama de configuración de la base de datos en forma de modelos que puedan mostrado en todos los sistemas de bases de datos.

Las herramientas de modelado más comunes:

Diagramas ER P. Chen

Se utiliza para diseñar bases de datos relacionales.

Método de Barker: desarrollo del diagrama ER

Beneficios del método Barker:

Una entidad es un objeto real o imaginario que es importante para un área temática determinada, cuya información está sujeta a almacenamiento.

Propiedades de la entidad:

Tiene un nombre único

Tiene uno o más atributos que identifican de forma única cada instancia de entidad.

Puede tener cualquier número de conexiones con otras entidades.

Una relación es una asociación nombrada entre dos entidades que es importante para el dominio en consideración.

Los atributos son cualquier característica de una entidad que es significativa para un área temática determinada y que pretende calificar, identificar, clasificar, cuantificar o expresar el estado de la entidad.

# - atributo clave

Supertipos y subtipos

En el método de Barker, el subtipo se dibuja dentro del supertipo.

Un supertipo es una entidad que es un concepto generalizado para un grupo de entidades similares.

Relaciones mutuamente excluyentes

Cada instancia de entidad participa en una sola relación de un grupo de relaciones mutuamente excluyentes. T.

comunicación recursiva

Una entidad está conectada consigo misma.

Una relación inamovible es una instancia de una entidad que no puede ser movido de una instancia de comunicación a otra.

16. Metodología IDEF

Metodología IDEF - esta es quizás la metodología más desarrollada y extensa que le permite describir no solo los procesos de negocios, sino también bloques funcionales (por ejemplo, marketing o finanzas), varios objetos de la empresa y acciones sobre ellos (por ejemplo, todo complejo de procesamiento y cumplimiento del pedido de un cliente), así como el estado y la dinámica de desarrollo de las unidades de negocio de la empresa y de la empresa en su conjunto. La metodología IDEF consta de 14 componentes, los más importantes son:

1. IDEF0 (metodología de modelado de bloques funcionales);
   1. IDEF1 (metodología para modelar flujos de información en una empresa);
   2. IDEF2 (metodología para modelar la dinámica de desarrollo empresarial);
   3. IDEF3 (metodología para documentar procesos de negocio en una empresa);
   4. IDEF4 (metodología para describir diversos objetos de la empresa y acciones sobre ellos);
   5. IDEF5 (metodología para describir el estado actual de la empresa y tendencias en su cambio).

17. Enfoque orientado a objetos para el diseño de SI

18. La esencia del enfoque orientado a objetos.

En un enfoque estructurado para el desarrollo de SI, el riesgo de fracaso del proyecto sigue siendo alto en todas las etapas de la creación del sistema hasta la etapa de prueba, cuando se pueden detectar errores. Si se descubre un error, debe volver a la etapa de desarrollo en la que se cometió el error y pasar por las etapas posteriores nuevamente.

Los métodos de desarrollo de SI orientados a objetos se han convertido en una alternativa al enfoque estructural. Estos métodos utilizan la descomposición de objetos. La estructura del sistema se describe en términos de clases de objetos y relaciones entre ellos. El comportamiento del sistema se describe en términos del intercambio de mensajes entre objetos. La reducción del riesgo de fracaso del proyecto en los métodos de desarrollo de SI orientados a objetos se logra mediante la implementación de tecnología de desarrollo iterativo (espiral).

En la primera mitad de los años 90 se propuso el lenguaje de modelado de objetos UML (Unified Modeling Language), desarrollado sobre la base de los métodos orientados a objetos más populares. La notación UML (sintaxis del lenguaje) incluye una serie de diagramas gráficos.

UML se puede utilizar en modo de boceto, diseño o lenguaje de programación. En modo boceto, los desarrolladores utilizan UML para comunicar información sobre varios aspectos del sistema. En el modo de diseño, puede utilizar bocetos para ingeniería directa e inversa. En el desarrollo directo, los diagramas se dibujan antes de escribir el código, mientras que en la ingeniería inversa, los diagramas se dibujan basándose en el código para comprender mejor el código. Cuando se utiliza UML en modo de lenguaje de programación, los diagramas se compilan para código ejecutable, es decir. UML se convierte en código fuente.

19.Metodología de análisis y diseño orientado a objetos.

La necesidad de analizar el área temática antes de comenzar a escribir un programa se hizo evidente al desarrollar proyectos a gran escala. El proceso de creación de bases de datos es significativamente diferente de escribir código de programa para resolver un problema informático. Por lo tanto, al diseñar una base de datos, es necesario desarrollar previamente un diagrama o modelo conceptual que refleje las relaciones generales del área temática y las características de la organización de la información relevante.

El área temática (dominio) es una parte del mundo real que es esencial o está directamente relacionada con el proceso de funcionamiento del programa. En otras palabras, el área temática incluye solo aquellos objetos y las relaciones entre ellos que son necesarios para describir los requisitos y condiciones para resolver un problema específico.

Aislar los componentes iniciales o básicos de un área temática necesarios para resolver un problema particular no es, en general, un problema trivial. La complejidad de este problema se refleja en el carácter informal de los procedimientos o reglas que pueden aplicarse para este fin. Además, este trabajo debe realizarse en colaboración con especialistas o expertos que tengan buenos conocimientos en el área temática. Por ejemplo, si se está desarrollando una base de datos para atender a los pasajeros de un aeropuerto grande, entonces el personal del aeropuerto debería participar en el diseño conceptual de la base de datos. Estos empleados tienen un buen conocimiento de todo el proceso de servicio al pasajero o de un área temática determinada. La complejidad del modelado de dominios y el desarrollo de sistemas de información corporativos ha llevado al surgimiento de una nueva metodología: el análisis y diseño orientado a objetos.

El análisis y diseño orientado a objetos (OOAP, análisis/diseño orientado a objetos) es una tecnología para desarrollar sistemas de software basada en una metodología orientada a objetos para representar el área temática en forma de objetos que son instancias de las clases correspondientes.

La metodología OOAP está estrechamente relacionada con el concepto de desarrollo automatizado de software (Computer Aided Software Engineering, CASE). Las primeras herramientas CASE fueron tratadas con cierta cautela. Con el tiempo, aparecieron tanto críticas entusiastas sobre su uso como evaluaciones críticas de sus capacidades. Había varias razones para opiniones tan contradictorias. La primera es que las primeras herramientas CASE eran simplemente complementos de un sistema de gestión de bases de datos (DBMS). Visualizar el proceso de desarrollo de un diagrama de base de datos conceptual es de gran importancia, sin embargo, no resuelve los problemas de crear otro tipo de aplicaciones.

La segunda razón está relacionada con la notación gráfica implementada en la herramienta CASE. Si los lenguajes de programación tienen una sintaxis estricta, entonces se intenta proporcionar una sintaxis adecuada para representación visual Los esquemas conceptuales de la base de datos no se percibieron de manera inequívoca. En este contexto, el desarrollo y estandarización del lenguaje de modelado unificado UML causó entusiasmo entre toda la comunidad de programación empresarial.

En el marco de OOAP históricamente se han considerado tres notaciones gráficas:

1. diagramas "entidad - relación" "(Diagramas Entidad-Relación, ERD),
2. diagramas funcional modelado (Técnica de Análisis y Diseño Estructurado, SADT),
3. Diagramas de flujo de datos (DFD).

Los diagramas entidad-relación (ERD) están diseñados para representar gráficamente los modelos de datos de un sistema de software que se está desarrollando y proporcionar un conjunto de notaciones estándar para definir los datos y las relaciones entre ellos. Con este tipo de diagrama, puede describir los componentes individuales de un modelo de datos conceptual y el conjunto de relaciones entre ellos.

Los conceptos principales de esta notación son los conceptos de esencia y conexión. En este caso, se entiende por entidad un conjunto arbitrario de objetos reales o abstractos, cada uno de los cuales tiene las mismas propiedades y características. En este caso, cualquier objeto en cuestión puede ser una instancia de una y sólo una entidad, debe tener un nombre o identificador único y debe ser distinto de otras instancias de esa entidad.

La relación se define como una relación o asociación entre entidades distintas. Ejemplos de conexiones podrían ser relaciones familiares, en particular "padre-hijo" o producción - "superior-subordinado". Otro tipo de relación está dada por las relaciones “poseer” o “tener una propiedad”. Los diferentes tipos de enlaces se representan gráficamente en forma de rombo con el nombre correspondiente del enlace en cuestión.

El modelo de datos gráfico está construido de tal manera que las conexiones entre entidades individuales reflejan no solo la naturaleza semántica de la relación correspondiente, sino también aspectos adicionales relaciones obligatorias, así como la multiplicidad de instancias de entidad que participan en estas relaciones. La notación de diagrama (ERD) se implementa en varias herramientas de software. En se muestra un ejemplo de un diagrama ERD desarrollado utilizando la herramienta de modelado de procesos de negocio ARIS®.

Las limitaciones de los diagramas ERD aparecen cuando el modelo conceptual se concreta en una representación más detallada del sistema de software que se está modelando, que, además de las conexiones estáticas, debe contener información sobre el comportamiento o funcionamiento de sus componentes individuales.

En el marco de los diagramas de modelado funcional, se desarrollaron varios lenguajes de modelado gráfico, que recibieron los siguientes nombres:

1. Notación IDEF0: para documentar procesos de producción y mostrar información sobre el uso de recursos en cada etapa del diseño del sistema.
2. Notación IDEF1: para documentar información sobre el entorno de producción de los sistemas.
3. Notación IDEF2: para documentar el comportamiento del sistema a lo largo del tiempo

La notación IDEF2 nunca se implementó por completo. La notación IDEF1 se amplió y pasó a llamarse IDEF1X en 1985. La metodología IDEF se ha abierto camino en organizaciones gubernamentales y comerciales desde que surgió el estándar FIPS del gobierno de EE. UU. para dos tecnologías, IDEF0 e IDEF1X, en 1993. Durante los años siguientes, este estándar continuó desarrollándose activamente y sirvió como base para la implementación en varias herramientas CASE, la más famosa de las cuales es AllFusion Process Modeler® (nuevo nombre BPwin®) de Computer Associates.

El proceso de modelado IDEF es un conjunto de métodos, reglas y procedimientos diseñados para construir un modelo funcional de un sistema en cualquier área temática. El modelo funcional IDEF refleja la estructura de los procesos de funcionamiento del sistema y sus subsistemas individuales, es decir, las acciones que realizan y las conexiones entre estas acciones. Para ello se construyen modelos especiales que permiten en forma visual presentar una secuencia de determinadas acciones. Los componentes iniciales de cualquier modelo de notación de procesos IDEF0 son actividades y flechas.

Una de las características más importantes de la notación IDEF0 es la introducción gradual de representaciones cada vez más detalladas del modelo del sistema a medida que se desarrollan diagramas individuales. La construcción del modelo IDEF0 comienza con la representación de todo el sistema en forma de un diagrama simple, que consta de un bloque de proceso y flechas ICOM, que sirven para representar los principales tipos de interacción con objetos fuera del sistema. Dado que el proceso original representa el sistema completo como un todo, esta presentación es el más general y está sujeto a una mayor descomposición. En se muestra un ejemplo de un modelo general del proceso de solicitud de un préstamo en un banco, desarrollado utilizando la herramienta CASE AllFusion Process Modeler®.

En última instancia, el modelo IDEF0 es un conjunto de diagramas jerárquicamente interconectados con documentación adjunta que desglosa la representación original de un sistema complejo en sus componentes individuales. Los detalles de cada proceso principal se presentan en más procesos detallados en otros diagramas. En este caso, cada diagrama de nivel inferior es una descomposición del proceso a partir de un diagrama más general. Por lo tanto, en cada paso de descomposición, un diagrama más general se concreta en varios diagramas detallados.

La principal desventaja de esta metodología está asociada con la falta de medios explícitos para la representación orientada a objetos de modelos de sistemas complejos. Algunos analistas señalan la importancia de conocer y utilizar la notación IDEF0; sin embargo, la falta de capacidad para implementar los modelos gráficos correspondientes en el código de un programa orientado a objetos reduce significativamente la gama de problemas que se resuelven con su ayuda.

El modelado gráfico de sistemas de información utilizando diagramas de flujo de datos se basa en una tecnología especial para construir diagramas de flujo de datos DFD. En el desarrollo de la metodología DFD participaron muchos analistas, entre los que cabe destacar a E. Yordon. Es autor de una de las primeras notaciones gráficas DFD.

La desventaja de las notaciones consideradas está asociada con la falta de medios explícitos para la representación orientada a objetos de modelos de sistemas complejos, así como de algoritmos complejos de procesamiento de datos. Dado que los tipos de diagramas considerados no indican las características del tiempo de ejecución de los procesos individuales y la transferencia de datos entre procesos, los modelos de sistemas que implementan el procesamiento de datos sincrónicos no se pueden representar adecuadamente en estas notaciones. Todas estas características de los métodos de análisis de sistemas estructurales limitaron las posibilidades. aplicación amplia notaciones correspondientes y sirvió como base para el desarrollo del lenguaje de modelado unificado UML.

20. Metodología de análisis y modelado de sistemas.

El análisis de sistemas como dirección científica tiene una historia más larga que la POO y la OOAP, y su propio tema de investigación. El concepto central del análisis de sistemas es el concepto de sistema, el cual se entiende como un conjunto de objetos, componentes o elementos de naturaleza arbitraria que forman una determinada integridad. El requisito previo determinante para identificar una determinada colección como sistema es la aparición en ella de nuevas propiedades que sus elementos constituyentes no tienen. Hay muchos ejemplos de sistemas: una computadora personal, un automóvil, una persona, la biosfera, un programa, etc. Un punto de vista más ortodoxo supone que todos los objetos que nos rodean son sistemas.

Las características más importantes de cualquier sistema son su estructura y proceso de funcionamiento. La estructura de un sistema se entiende como un conjunto de relaciones estables en el tiempo entre sus elementos o componentes. Es la estructura que une todos los elementos y evita que el sistema se desintegre en componentes separados. La estructura de un sistema puede reflejar una variedad de relaciones, incluido el anidamiento de elementos de un sistema en otro. En este caso, se acostumbra llamar subsistema al sistema más pequeño o anidado y metasistema al más grande.

El proceso de funcionamiento del sistema está estrechamente relacionado con los cambios en sus propiedades o comportamiento a lo largo del tiempo. Donde característica importante de un sistema es su estado, entendido como un conjunto de propiedades o características que en cada momento reflejan los rasgos más significativos del comportamiento del sistema.

La metodología del análisis de sistemas sirve como base conceptual para una descomposición sistémica del área temática. En este caso, los componentes iniciales de la conceptualización son los sistemas y las relaciones entre ellos. Además, el concepto de sistema es más general que los conceptos de clases y objetos en OOAP. El resultado del análisis del sistema es la construcción de algún modelo del sistema o área temática.

21. Lenguaje de modelado unificado UML

UML es un lenguaje de modelado orientado a objetos con las siguientes características principales:

1. es un lenguaje de modelado visual que garantiza el desarrollo de modelos representativos para organizar la interacción entre el cliente y el desarrollador de SI y varios grupos de desarrolladores de SI;
2. Contiene mecanismos para ampliar y especializar los conceptos básicos de la lengua.

Diagrama de clase, Diagrama de clases Diagrama estructural estático que describe la estructura del sistema. Muestra las clases del sistema, sus atributos, métodos y dependencias entre clases.

Diagrama de componentes, Diagrama de componentes, diagrama estructural estático, muestra la división de un sistema de software en componentes estructurales y conexiones (dependencias) entre componentes. Los componentes físicos pueden ser archivos, bibliotecas, módulos, archivos ejecutables, paquetes, etc

Diagrama de estructura compuesta/compuesta, Diagrama de estructura compuesta, diagrama estructural estático, demuestra la estructura interna de las clases y, si es posible, la interacción de los elementos (partes) de la estructura interna de la clase.

Un subtipo de diagramas de estructura compuesta sondiagramas de cooperación(Diagrama de colaboración, introducido en UML 2.0), que muestra los roles e interacciones de las clases dentro del marco de la cooperación. Las colaboraciones son útiles para modelar patrones de diseño.

Los diagramas de estructura compuesta se pueden utilizar junto con los diagramas de clases.

Diagrama de implementaciónEl diagrama de implementación se utiliza para modelar los nodos de trabajo (hardware, nodo en inglés) y los artefactos implementados en ellos. En UML 2, los artefactos se implementan en nodos, mientras que en UML 1, los componentes se implementan en nodos. Se establece una dependencia de manifestación entre el artefacto y el elemento lógico (componente) que implementa.

Diagrama de objetos, El diagrama de objetos muestra una instantánea completa o parcial del sistema simulado en un momento dado. El diagrama de objetos muestra instancias de clases (objetos) del sistema, indicando los valores actuales de sus atributos y las relaciones entre los objetos.

Diagrama de paquete, Diagrama estructural del diagrama de paquete, cuyo contenido principal son los paquetes y las relaciones entre ellos. No existe una distinción estricta entre diferentes diagramas de estructura, por lo que este nombre se proporciona solo por conveniencia y no tiene significado semántico (los paquetes y los diagramas de paquetes pueden aparecer en otros diagramas de estructura). Los diagramas de paquetes sirven, en primer lugar, para organizar elementos en grupos según alguna característica con el fin de simplificar la estructura y organizar el trabajo con el modelo del sistema.

Diagrama de actividad, Diagrama de actividad Diagrama que muestra la descomposición de alguna actividad en sus partes componentes. La actividad es una especificación de comportamiento ejecutable en forma de secuencias coordinadas y ejecución paralela Elementos subordinados anidados en actividades y acciones individuales (en inglés Actions), interconectados por flujos que van desde las salidas de un nodo a las entradas de otro.

Los diagramas de actividad se utilizan en el modelado de procesos comerciales, procesos tecnológicos, computación secuencial y paralela.

diagrama de la máquina, Diagrama de máquina de estados (diagrama de máquina de estados, diagrama de estados) que muestra una máquina finita con estados simples, transiciones y estados compuestos.

La máquina de estados es una especificación de la secuencia de estados por la que pasa un objeto o interacción en respuesta a eventos de su vida, así como la respuesta del objeto a estos eventos. Una máquina de estados está adjunta a un elemento fuente (clase, colaboración o método) y sirve para definir el comportamiento de sus instancias.

Use el diagrama del casoDiagrama de casos de uso: diagrama que representa las relaciones que existen entre los actores y los casos de uso.

El objetivo principal es proporcionar una única herramienta que permita al cliente usuario final y el desarrollador discuten conjuntamente la funcionalidad y el comportamiento del sistema.

Diagramas de comunicación y secuenciainteracción transitiva, expresa, pero la muestra de diferentes maneras y puede transformarse de una a otra con un grado suficiente de precisión.

Diagrama de comunicación, Diagrama de comunicación (en UML 1.x, diagrama de colaboración, diagrama de colaboración) diagrama que representa las interacciones entre partes de una estructura compuesta o roles de colaboración. A diferencia de un diagrama de secuencia, un diagrama de comunicación indica explícitamente las relaciones entre elementos (objetos) y no utiliza el tiempo como una dimensión separada (se utilizan números de secuencia de llamadas).

Diagrama de secuencia, Diagrama de secuencia que representa la interacción de objetos ordenados en el tiempo. En particular, representa los objetos que participan en la interacción y la secuencia de mensajes que intercambian.

Diagrama general de interacción, Diagrama general de interacción: un tipo de diagrama de actividad que incluye fragmentos de un diagrama de secuencia y construcciones de flujo de control.

Diagrama de tiempo, Diagrama de tiempo Una representación alternativa de un diagrama de secuencia que muestra explícitamente los cambios de estado a lo largo de una línea de vida con una escala de tiempo determinada. Puede resultar útil en aplicaciones en tiempo real.

Ventajas de UML:

1. UML está orientado a objetos, por lo que los métodos para describir los resultados del análisis y el diseño son semánticamente cercanos a los métodos de programación en los lenguajes OO modernos;
2. UML le permite describir un sistema desde casi todos puntos posibles visión y diversos aspectos del comportamiento del sistema;
3. Los diagramas UML son relativamente fáciles de leer una vez que se familiariza con su sintaxis con bastante rapidez;
4. UML amplía y permite introducir sus propios estereotipos textuales y gráficos, lo que promueve su uso no solo en el campo de la ingeniería de software;
5. UML se ha generalizado y se está desarrollando dinámicamente.

22. Casos de uso de UML

23. Comparación y relación entre enfoques estructurales y orientados a objetos

Gradi Booch formuló la principal ventaja del enfoque orientado a objetos (POO) de la siguiente manera: los sistemas orientados a objetos son más abiertos y más fáciles de cambiar porque su diseño se basa en formas estables. Esto permite que el sistema se desarrolle gradualmente y no conduce a su rediseño completo, incluso en caso de cambios significativos en los requisitos originales.

Butch también destacó varias de las siguientes ventajas de la programación orientada a objetos:

1. La descomposición de objetos permite crear sistemas de software más pequeños mediante el uso de mecanismos comunes que proporcionan el ahorro necesario en medios expresivos. El uso de programación orientada a objetos aumenta significativamente el nivel de unificación del desarrollo y la reutilización no solo del software, sino también de los proyectos, lo que en última instancia conduce a la creación ensamblada de software. Los sistemas suelen ser más compactos que sus equivalentes no orientados a objetos, lo que significa no sólo una reducción en la cantidad de código de programa, sino también un proyecto más barato al utilizar desarrollos anteriores;
2. La descomposición de objetos reduce el riesgo de crear sistemas de software complejos, ya que asume un camino evolutivo de desarrollo de sistemas basado en subsistemas relativamente pequeños. El proceso de integración del sistema se extiende a lo largo de todo el período de desarrollo y no se convierte en un evento único;
3. El modelo de objeto es bastante natural, ya que se centra principalmente en la percepción humana del mundo, y no en implementación informática;
4. El modelo de objetos le permite aprovechar al máximo las capacidades expresivas de los lenguajes de programación orientados a objetos y de objetos.

Las desventajas de la programación orientada a objetos incluyen una ligera disminución en el rendimiento del software (que, sin embargo, se vuelve menos notoria a medida que aumenta el rendimiento de la computadora) y altos costos iniciales. La descomposición de objetos difiere significativamente de la descomposición funcional, por lo que la transición a una nueva tecnología está asociada tanto con la superación de dificultades psicológicas como con costos financieros adicionales. Al pasar de un enfoque estructural a uno de objetos, como ocurre con cualquier cambio tecnológico, es necesario invertir dinero en la adquisición de nuevas herramientas. Aquí debes tener en cuenta los costos de entrenar el método, medios instrumentales y lenguaje de programación. Para algunas organizaciones, estas circunstancias pueden plantear serios obstáculos.

El enfoque orientado a objetos no proporciona beneficios inmediatos. El efecto de su uso comienza a sentirse después del desarrollo de dos o tres proyectos y la acumulación de componentes reutilizables que reflejan soluciones de diseño estándar en esta área. La transición de una organización a la tecnología orientada a objetos es un cambio de visión del mundo, y no solo el aprendizaje de nuevas herramientas CASE y lenguajes de programación.

Por tanto, el enfoque estructural aún conserva su importancia y se utiliza bastante ampliamente en la práctica. Por ejemplo lenguaje UML se ve claramente que sus autores tomaron prestado lo racional que se podía tomar del enfoque estructural: elementos de descomposición funcional en diagramas de casos de uso, diagramas de estado, diagramas de actividad, etc. Evidentemente, en un proyecto específico de un sistema complejo es imposible arreglárselas con un solo método de descomposición. Puede comenzar la descomposición de una manera y luego usar los resultados para intentar ver el sistema desde un punto de vista diferente.

La base de la relación entre los enfoques estructural y orientado a objetos es la similitud de una serie de categorías y conceptos de ambos enfoques (proceso y caso de uso, entidad y clase, etc.). Esta relación puede manifestarse en diversas formas. Por tanto, una posible opción es utilizar el análisis estructural como base para el diseño orientado a objetos. Al mismo tiempo, el análisis estructural debe detenerse tan pronto como los modelos estructurales comiencen a reflejar no solo las actividades de la organización (procesos de negocio), sino también el sistema de software. Después de realizar el análisis estructural, puede comenzar a definir clases y objetos de varias maneras. Entonces, si tomamos cualquier diagrama de flujo de datos individual, los candidatos para clases pueden ser elementos de estructuras de datos.

Otra forma de manifestación de interconexión puede considerarse la integración de tecnologías objetuales y relacionales. Los DBMS relacionales son hoy en día el principal medio para implementar bases de datos y almacenes de datos a gran escala. Las razones son bastante obvias: la tecnología relacional se utiliza desde hace bastante tiempo, ha sido dominada por un gran número de usuarios y desarrolladores, se ha convertido en un estándar de la industria, se han invertido importantes fondos en ella y se han modificado muchas bases de datos corporativas. creado en una variedad de industrias, el modelo relacional es simple y tiene una base matemática estricta; Existe una amplia variedad de herramientas industriales para diseñar, implementar y operar bases de datos relacionales. Por ello, las bases de datos relacionales se utilizan principalmente para almacenar y recuperar objetos en los llamados sistemas relacionales de objetos.

La relación entre los enfoques estructurales y orientados a objetos es bastante visible en varios sistemas de software.

24. Herramientas auxiliares de soporte del ciclo de vida del software.

1. Herramientas de gestión de configuración

2. Herramientas de documentación

3. Herramientas de prueba

25. s r herramientas de gestión de configuración de software

El propósito de la gestión de la configuración (CM) es garantizar la capacidad de gestión y control de los procesos de desarrollo y mantenimiento de software. Esto requiere información precisa y confiable sobre el estado del software y sus componentes en cada momento, así como sobre todos los cambios propuestos y completados.

Para resolver problemas de CG, se utilizan métodos y medios para asegurar la identificación del estado de los componentes, teniendo en cuenta la nomenclatura de todos los componentes y modificaciones del sistema en su conjunto, control sobre los cambios realizados en los componentes, la estructura del sistema y sus funciones. , así como la gestión coordinada del desarrollo de funciones y mejora de las características del sistema.

La herramienta CG más común es PVCS de Intersolv (EE. UU.), que incluye varios productos independientes: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder y PVCS Notify.

26. Herramientas de documentación de software.

Para crear documentación en el proceso de desarrollo de SI, se utilizan una variedad de herramientas de informes, así como componentes de sistemas de publicación. Normalmente, las herramientas de documentación están integradas en herramientas CASE específicas. La excepción son algunos paquetes que brindan servicios de documentación adicionales. De ellos, SoDA (Software Document Automation) es el más utilizado.

El producto SoDA está diseñado para automatizar el desarrollo de documentación de diseño en todas las fases del ciclo de vida del software. Le permite extraer automáticamente una variedad de información obtenida en diferentes etapas del desarrollo del proyecto e incluirla en los documentos de salida.

27. Estimación de los costos de desarrollo de software.

28. Herramientas de prueba de software

Las pruebas se refieren al proceso de ejecutar un programa para detectar errores. Las pruebas de regresión son pruebas que se llevan a cabo después de mejorar las funciones de un programa o realizar cambios en él.

Una de las herramientas de pruebas de control de calidad más avanzadas (nuevo nombre: Quality Works) es un entorno multiplataforma integrado para desarrollar pruebas automatizadas de cualquier nivel, incluidas pruebas de regresión para aplicaciones con una interfaz gráfica de usuario.

El control de calidad le permite comenzar las pruebas en cualquier fase del ciclo de vida, planificar y gestionar el proceso de prueba, mostrar cambios en la aplicación y reutilizar pruebas para más de 25 plataformas diferentes.

29. Gestión de proyectos de software.

30. Ejemplos de complejos CASE-herramienta.

Así como otras obras que te pueden interesar
54490.			275KB
	Los estudiantes responden preguntas. Los estudiantes hacen preguntas a un estudiante cerca de la pizarra, el estudiante responde. Los estudiantes escuchan y responden preguntas. Los estudiantes trabajan en la pizarra y desde sus asientos.
54491.		El mágico mundo de la música.	34,5KB
	Es difícil imaginar nuestra vida sin música. Nos ayuda a vivir y relajarnos. Vamos a hablar de música porque juega un gran papel en nuestras vidas. La música está en todas partes: en las calles, en las tiendas, en los parques, en los televisores.
54492.		Géneros de la música folclórica ucraniana.	940KB
	Objetivo. Consolidar las ideas de los estudiantes sobre las características del género ucraniano. música folk. Repetir canciones de calendario, rituales, históricas, canciones de cuna y cómicas, los estudiantes deben demostrar conocimiento de los géneros de canciones; canción folk, sus rasgos, rasgos característicos. Desarrollar las habilidades vocales y corales, la experiencia emocional y sensitiva de los estudiantes. Cultivar el interés en canción folk y el respeto por las tradiciones populares. Cultivar el gusto estético de los estudiantes.
54493.		Acertijos sobre instrumentos musicales.	81,5KB
	INSTRUMENTOS DE PERCUSIÓN Vivo ritmo muerto Movimiento vivo y rugido muerto Tambor Residuos residuos Sobre la piel debajo de la misma En el medio hay vacío. Tambor Tomamos los palos en nuestras manos No queremos tocarlo Tram-tam-tam-tram-tam. Tambor A nadie le importa. Lo golpean con un palo. El tambor La voz vacía en sí es espesa, el tambor golpea a los niños y los levanta.
54494.		Música en unserem Leben	239,5KB
	Anne-Sophie Mutter es una Geigerin weltberühmte. Schon als Kind wusste sie, was sie wollte, und bald hat sie ihren Traum verwirklicht. Im Alter von 7 Jahren gewann sie den Wettbewerb „Jugend musiziert“. 1976 fiel sie dem bekannten österreichischen Dirigenten Herbert von Karajan auf. Ein Jahr später trat sie schon als Solistin seines Orchesters bei den Salzburger Konzerten auf. Este Zusammenarbeit öffnete der Geigerin die Tür zum internationalen Erfolg.
54495.		Música. Die größten Komponisten der Ukraine und Deutschlands	97,5KB
	Das Thema der heutigen Stunde lautet: Musik. Die größten Komponisten der Ukraine und Deutschlands. Lernziele sind: Wortschatz festigen und erweitern, Fragen stellen und beantworten, den Text lesen, Dialoge führen.
54496.		Música yak mova pochuttiv	54,5KB
	Meta de la lección: Consolidar los conocimientos sobre los compositores y su creatividad en el aula. Revelar la diversidad y comprensión de temas relacionados de la terminología musical. Con ejemplos concretos, mostramos la capacidad de la mística musical para expresar los diversos estados de ánimo y sensibilidades de las personas.
54497.		El problema de la elección en economía. Curva de posibilidades de producción	41,58KB
	En una economía de mercado, el fabricante se fija el objetivo de obtener los máximos ingresos posibles, seleccionando para la producción los bienes materiales más adecuados para este fin.
54498.		Un enfoque diferenciado para desbloquear el potencial creativo de los estudiantes en las lecciones de música.	50,5 KB
	Material sugerido, por supuesto. Como muchos de ustedes conocen, es posible que algunos de ustedes estén implementando un enfoque diferenciado de enseñanza en sus lecciones. Pero en pedagogía es muy difícil descubrir algo nuevo; basta con estudiar más profundamente la teoría, traducirla en el proceso de enseñanza, para que estos desarrollos prácticos se conviertan en material para el trabajo creativo en la categoría.