El diseño de sistemas de información es un proceso de múltiples etapas de su creación y/o modernización mediante la aplicación 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 garanticen la ejecución de consultas de datos,
- dar cuenta del funcionamiento de un entorno particular (tecnología).
Si destacamos la etapa de diseño de los sistemas de información como una etapa separada, entonces puede ubicarse entre las etapas de análisis y desarrollo. Sin embargo, en la práctica, una división clara en etapas, como regla, es difícil o imposible, ya que el diseño, comenzando formalmente con la definición objetivos del proyecto, a menudo continúa a través de las etapas de prueba e implementación.
Objetivo del diseño del sistema de información y conceptos relacionados
Los líderes modernos de las 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 general, los objetivos de los proyectos de creación de sistemas de información se reducen a proporcionar las condiciones que permitan recibir, procesar y utilizar esta información creando un sistema funcional a prueba de fallas con suficiente:
- nivel de adaptabilidad a las 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 un conjunto 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 también incluyen métodos para detectar, recopilar, procesar, almacenar, difundir información y métodos que permiten implementar estos métodos. gestión de la información todo 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 solo concepto específico.
Organización del diseño de SI
La organización del diseño de SI se suele dividir en 2 tipos:
- El diseño canónico refleja las características tecnológicas del proceso original (individual).
- El diseño típico, que se caracteriza por una solución de diseño estándar (TPR), se replica y es adecuado para un uso repetido.
El diseño canónico se distingue por el reflejo de la tecnología de diseño manual, la implementación a nivel de los artistas y el uso de herramientas de soporte informático universales.
El diseño canónico se usa 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 ocurre solo a través de la reprogramación de los módulos de software. 
El diseño canónico se organiza utilizando el modelo de ciclo de vida en cascada. Esto implica dividir el proceso en los siguientes pasos y etapas:
- Etapa de anteproyecto. Elaboración y compilación de especificaciones técnicas. Es decir, se forman los requisitos para IP, se desarrolla su concepto, se elabora un estudio de viabilidad y se escriben especificaciones técnicas.
- La etapa del proyecto prevé la preparación de proyectos y diseños técnicos, el desarrollo de la documentación de trabajo.
- La etapa posterior al proyecto da lugar a actividades para la implementación de SI, capacitación del personal y análisis de los resultados de las pruebas. Parte de esta etapa es el mantenimiento del SI y la eliminación de las deficiencias identificadas.
Las etapas, si es necesario, pueden ampliarse o detallarse: combine etapas sucesivas, excluya las "adicionales", comience la siguiente etapa antes de completar la anterior.
El método de diseño típico se distingue por la posibilidad de descomponer el IS diseñado con división en componentes, que incluyen módulos de programa, subsistemas, complejos de tareas, etc. Para implementar los componentes, puede usar soluciones estándar que ya existen en el mercado y personalizarlos para las necesidades de una organización en particular. Al mismo tiempo, el diseño típico supone la disponibilidad obligatoria de documentación que describa en detalle los procedimientos de ajuste y TPR.
La descomposición puede tener varios niveles, lo que permite singularizar las clases de la 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 posibilidad de implementar un enfoque modular se considera una ventaja del TPR elemental. Sin embargo, en caso de incompatibilidad de diferentes elementos, el proceso de combinación de los mismos conduce a un aumento de los costes. El subsistema TPR, además de implementar un enfoque modular, permite realizar ajustes paramétricos a objetos de diferentes niveles de control. Los problemas de consolidación surgen cuando se trata de un producto de varios proveedores 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 objetos TPR, en comparación con las clases anteriores, tienen una gran cantidad de ventajas:
- escalabilidad, que permite utilizar configuraciones IS para un número diferente de trabajos,
- 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 paramétricos y orientados a modelos.
Metodologías básicas de diseño de circuitos integrados
Las particularidades del proceso de diseño permiten singularizar metodologías basadas en diferentes principios. Entre las principales metodologías modernas de diseño de SI se encuentran las siguientes:
- SADT. La metodología de modelado funcional del trabajo, que se basa en el análisis estructural y representación grafica organización como un sistema de funciones. Destacan aquí los modelos funcional, informacional y dinámico. La metodología se conoce actualmente como la notación IDEF0 (estándar). El proceso analizado se representa gráficamente en forma de cuadrilátero, donde se muestran arriba las acciones de regulación y control, abajo los objetos de control, a la izquierda los datos de entrada y a la derecha los datos de salida.
- RAD. Metodología de desarrollo rápido de aplicaciones. En RAD, el desarrollo rápido de aplicaciones es posible mediante el uso del diseño orientado a componentes. La metodología se utiliza en proyectos con un presupuesto limitado, requisitos de IP confusos y plazos ajustados. 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 (incremental). El sistema se construye sobre la base de la arquitectura del sistema de información, y la planificación y la gestión de proyectos se basan en los requisitos funcionales para SI. El desarrollo de un sistema de información común tiene lugar en iteraciones, como un complejo de pequeños proyectos separados con sus propios planes y tareas. El ciclo iterativo se caracteriza por la retroalimentación periódica y la adaptación al núcleo de SI.
Existen varias clasificaciones de metodologías: según el uso de TPR, según el uso de herramientas de automatización, etc. Por ejemplo, según el grado de adaptabilidad se distinguen reconstrucciones (cuando se reprograman módulos), parametrizaciones (cuando se modifica un parámetros implica la generación de una solución de diseño), reestructuración (cuando un cambio en el modelo del área del problema acompañado de la generación automática de la solución de diseño).
Centro de servicio: una organización dedicada a la prestación de servicios de soporte y mantenimiento de maquinaria, equipo y otros productos. Las actividades de los centros de servicio incluyen preventa, garantía y reparaciones posventa.
Empresa IP Mikhailov A.O. se ocupa de la reparación y el mantenimiento electrodomésticos y electrónica, así como computadoras, teléfonos y tabletas que los clientes llevan a la oficina, así como recarga de cartuchos e instalación de redes y centralitas. Si no es posible entregar el equipo por el propio cliente, se realiza una visita al lugar, y en caso de ser necesario se entrega por centro de servicio. Cuando el cliente se pone en contacto con el centro de servicio, el despachador elabora una solicitud de aceptación del pedido. Se lleva a cabo un análisis del objeto, como resultado de lo cual se llega a una conclusión sobre si el equipo será reparado o no. El departamento de ingeniería elabora una lista de precios para la reparación y mantenimiento de equipos, ya que trabaja con proveedores de repuestos y dispositivos para la reparación de equipos. Reparaciones a realizar equipamiento especial siguiendo las normas de seguridad. La empresa también vende periféricos para teléfonos, tabletas y computadoras. La empresa se ocupa de las compras de la maquinaria de segunda mano y la maquinaria que ha fallado.
la empresa esta trabajando especialistas calificados con muchos años de experiencia. El director supervisa todo el funcionamiento de la empresa.
Dirección de la empresa:
Territorio de Perm, Kungur, st. Lenina 66
Modo de trabajo:
Lun-Vie: 10 - 19 sin almuerzo
Sol: día libre.
Al estructurar la lista de servicios, la empresa puede aumentar sus ganancias, ampliar los límites de la empresa o abrir otro centro de servicios en otro lugar, la calidad de los servicios prestados también puede aumentar y la cantidad de clientes puede aumentar.
El análisis realizado del área temática proporciona una descripción completa del área temática de la empresa IP Mikhailov A.O. para crear un sistema de información viable para esta empresa. Se da una descripción del trabajo del centro de servicio, indicando el trabajo del departamento de ingeniería. También se creó la estructura organizativa de la empresa, que muestra la interacción del director y los subordinados.
Formación de documentos básicos para la gestión de un proyecto de sistema de información.
Un proyecto es un conjunto de tareas o actividades relacionadas con la consecución de un objetivo planificado, que suele ser único y no repetitivo.
Gestión de proyectos: el uso de conocimientos, habilidades, métodos, herramientas y tecnologías en la implementación del proyecto para lograr o superar las expectativas de los participantes del proyecto.
Para gestionar correctamente un proyecto de sistema de información, es necesario generar documentos básicos de gestión de proyectos. Los documentos básicos serán el Acta Constitutiva y el Plan de Gestión del Proyecto.
Carta del proyecto
El acta de constitución del proyecto es el instrumento que autoriza formalmente el proyecto y es el vínculo que conecta el próximo proyecto con trabajo actual organizaciones
Un acta de constitución del proyecto documenta los requisitos iniciales de un proyecto que satisface las necesidades y expectativas de las partes interesadas.
Hay una carta del proyecto.
Este documento generalmente refleja la situación por parte de la organización cliente, lo emite un líder externo al proyecto y designa al gerente del proyecto, otorgándole la autoridad para utilizar los recursos de la organización en el proyecto.
El acta de constitución del proyecto debe contener la siguiente información:
Requisitos para el proyecto y el producto del proyecto, en forma bastante general;
Objetivo del proyecto;
Información sobre el director del proyecto designado y el nivel de su autoridad;
Calendario de eventos de control;
Relaciones entre los participantes del proyecto;
Organizaciones funcionales y su participación;
Supuestos sobre la organización y el entorno, así como supuestos externos;
Restricciones relativas a la organización y el medio ambiente, así como restricciones externas;
Un caso de negocio real que sirva de justificación del proyecto con datos de retorno de la inversión;
Presupuesto del proyecto.
Un acta de constitución del proyecto aumenta la probabilidad de que el proyecto se complete con éxito. Documenta las intenciones de los participantes del proyecto desde el comienzo mismo del proyecto y puede servir como un punto fundamental de resolución de disputas entre los miembros del equipo del proyecto y la organización ejecutora.
Durante la redacción del estatuto del proyecto, se llevó a cabo el estatuto de las reglas para organizar el trabajo del proyecto con la ayuda de documentación, estrategias, objetivos, metodología del proyecto, funciones de rol y reglas del proyecto necesarias para lograr los objetivos comerciales del proyecto. . Se han identificado los responsables de la gestión y ejecución.
Desarrollar una carta toma una cantidad significativa de tiempo. Al crear el próximo proyecto, la carta desarrollada se puede usar como plantilla, de modo que el desarrollo de la carta tome menos tiempo. Una carta de proyecto ayuda con la gestión de proyectos porque se requiere cierta información para trabajar en MS Project.
Plan de gestión de proyectos
Plan de gestión del proyecto: un conjunto de documentos formales aprobados que especifican cómo se ejecutará el proyecto y cómo se supervisará y gestionará el proyecto. El plan puede ser resumido o detallado y puede incluir uno o más planes de manejo subsidiarios y otros documentos de planificación.
El proceso de desarrollo del plan para la dirección del proyecto es el proceso de documentar las actividades necesarias para definir, preparar, integrar y coordinar todos los planes de apoyo. Un plan de gestión de proyectos bien redactado es la principal fuente de información sobre cómo se planificará, evaluará, controlará y cerrará el proyecto. El plan de gestión del proyecto se actualiza y edita como parte del proceso integrado de gestión de cambios del proyecto.
1 Apoyar los planes de gestión de proyectos, que incluyen:
Plan de Gestión del Alcance del Proyecto;
Plan de gestión del cronograma del proyecto;
plan de gestión de costos del proyecto;
plan de gestión de la calidad del proyecto;
plan de gestión de personal;
plan de gestión de las comunicaciones del proyecto;
plan de gestión de riesgos del proyecto;
Plan de gestión de la configuración.
2 Línea base del proyecto, compuesta por:
Cronograma básico del proyecto;
Plan básico de costo;
Plan básico de calidad;
Plan básico de configuración;
Registro de riesgo.
3 Resultados del análisis realizado por el equipo del proyecto en cuanto al contenido, alcance y tiempo del proyecto.
Para el proyecto del sistema de información “Contabilidad de los servicios prestados”, se elaboró un plan de gestión del proyecto. (Apéndice B)
El primer párrafo del plan para la dirección del proyecto indica el nombre del proyecto. El nombre del proyecto no se puede cambiar a lo largo de la vida del proyecto.
El segundo párrafo define las metas y objetivos del proyecto. Los objetivos se forman en función de los requisitos del cliente, que consisten en automatizar los principales procesos comerciales de la empresa. Se establecieron objetivos, como la captación de clientes y el aumento de las ganancias, mejorando la calidad de los servicios prestados.
El tercer párrafo define los requisitos para la solución de diseño y los resultados del proyecto. Esta sección es un elemento del contenido básico del proyecto. Para proporcionar un vínculo entre los requisitos del cliente y los resultados del proyecto, se recomienda utilizar la función de calidad.
El cuarto punto define los límites del proyecto. Este es el elemento básico del contenido del proyecto. El alcance del proyecto describe lo que se incluye en el proyecto para garantizar que un participante del proyecto no considere erróneamente un producto, servicio o resultado como parte del proyecto.
El quinto párrafo define las herramientas y tecnologías para la implementación de la gestión de proyectos.
En el sexto párrafo, hay una estructura de trabajo jerárquica, un modelo que revela el proyecto nivel por nivel con tal grado de detalle que es necesario para una planificación y un control efectivos del proyecto.
El séptimo punto describe la necesidad de recursos. Está determinado por la complejidad del trabajo reflejado en el IBS previamente desarrollado.
El octavo punto del Plan muestra una ampliación plan de calendario. Se desarrolla en base a hitos, información del Project Charter e información de la metodología de gestión de proyectos utilizada.
El noveno punto son los factores críticos de éxito. Describe las condiciones, cuya provisión en el proyecto puede ser la clave del éxito.
Los párrafos décimo y undécimo reflejan los supuestos y restricciones por parte del ejecutante. A medida que avanza el proyecto, las restricciones pueden cambiar.
El duodécimo punto son los riesgos originalmente formulados. Se indican los riesgos ya conocidos y las principales categorías de riesgos potenciales.
La gestión de riesgos son los procesos asociados a la identificación, análisis de riesgos y toma de decisiones, que incluyen maximizar las consecuencias positivas y minimizar las negativas de la ocurrencia de eventos de riesgo.
Planificación de la gestión de riesgos: el proceso de toma de decisiones para aplicar y planificar la gestión de riesgos para un proyecto específico. Este proceso puede incluir decisiones sobre la organización, la dotación de personal para los procedimientos de gestión de riesgos del proyecto, la selección de la metodología preferida, las fuentes de datos para la identificación de riesgos, el marco de tiempo para el análisis de la situación.
Planificación de la gestión de riesgos: selección de enfoques y actividades de planificación para la gestión de riesgos del proyecto.
1 Identificación de riesgos: identificar los riesgos que pueden afectar el proyecto y documentar sus características.
2 Evaluación cualitativa de riesgos: un análisis cualitativo de los riesgos y sus condiciones de ocurrencia para determinar su impacto en el éxito del proyecto.
3 Cuantificación - análisis cuantitativo la probabilidad de ocurrencia y el impacto de las consecuencias de los riesgos en el proyecto.
4 Planificación de la respuesta al riesgo: determinación de procedimientos y métodos para mitigar las consecuencias negativas de los eventos de riesgo y utilizar los posibles beneficios.
5 Seguimiento y control de riesgos: seguimiento de los riesgos, identificación de los riesgos restantes, implementación del plan de gestión de riesgos del proyecto y evaluación de la eficacia de las acciones de mitigación de riesgos.
Se presenta el plan de gestión de riesgos. (Apéndice B)
El plan de gestión del proyecto del sistema de información "Contabilidad de los servicios prestados" permitió crear documentos y describir las características y los límites del proyecto, los servicios asociados con él, así como los métodos de aceptación y gestión de contenido. La declaración del alcance permitió evaluar el resultado deseado y sirvió como base para un plan de alcance de línea de base a seguir para todas las actividades del proyecto.
El desarrollo de la documentación básica para la gestión de proyectos del sistema de información "Contabilidad de los servicios prestados" permitió describir algunos de los documentos para la implementación exitosa y de alta calidad de la gestión de proyectos en MS Project. La clave del éxito es comprender la necesidad de estos documentos en el proceso de gestión de proyectos. El resultado de este trabajo fue el acta de constitución del proyecto y el plan de gestión del proyecto desarrollados, que se utilizarán en trabajos posteriores.
El resultado de la primera sección fue la estructuración del proyecto IS "Contabilidad de los servicios prestados" para la empresa IP Mikhailov A.O., también se desarrollaron los estatutos del proyecto y el plan de gestión del proyecto, que se utilizaron en trabajos posteriores sobre la gestión de proyectos. . El proceso de generación de documentos básicos es la parte más importante de la gestión de proyectos, ya que afecta la calidad, la duración y el éxito del proyecto.
Introducción
Conclusión
Literatura
Introducción
Desarrollo Varias áreas actividad humana en la etapa actual es imposible sin un uso generalizado Ciencias de la Computación y creación de sistemas de información de varias direcciones. El procesamiento de información en dichos sistemas se ha convertido en una dirección científica y técnica independiente.
Después de la fase de construcción modelo de información comienza el diseño del sistema. En esta etapa, la elección soluciones tecnológicas sobre la base de los cuales se construirá el sistema de información.
Información en mundo moderno se ha convertido en uno de los recursos más importantes, y los sistemas de información (SI) se han convertido Herramienta esencial en casi todas las áreas de actividad.
En condiciones reales, el diseño es una búsqueda de una forma que satisfaga los requisitos de funcionalidad del sistema por medio de las tecnologías disponibles, teniendo en cuenta las restricciones dadas.
La variedad de tareas resueltas con la ayuda de SI ha llevado a la aparición de muchos tipos diferentes de sistemas que difieren en los principios de construcción y las reglas de procesamiento de información incrustadas en ellos.
apuntar trabajo de control es - considerar paso a paso, el proceso de creación de sistemas de información.
Los objetivos de este trabajo son averiguar el propósito principal del diseño, así como el propósito de crear sistemas de información.
1. Diseño de sistemas de información
El diseño de sistemas de información siempre comienza con la definición del propósito del proyecto. La tarea principal de cualquier proyecto exitoso es asegurar que en el momento del lanzamiento del sistema y durante todo el período de su funcionamiento sea posible proporcionar:
la funcionalidad requerida del sistema y el grado de adaptación a las condiciones cambiantes de su funcionamiento;
el rendimiento requerido del sistema;
el tiempo de respuesta requerido del sistema a una solicitud;
· funcionamiento sin problemas del sistema en el modo requerido, en otras palabras, la preparación y disponibilidad del sistema para procesar las solicitudes de los usuarios;
facilidad de operación y soporte del sistema;
seguridad necesaria.
El rendimiento es el principal factor que determina la eficiencia de un sistema. Un buen diseño es la base de un sistema de alto rendimiento.
El diseño de sistemas de información 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 aseguren 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 (archivo-servidor o cliente-servidor), procesamiento en paralelo, procesamiento de datos distribuidos, etc.
De acuerdo con la metodología moderna, el proceso de creación de un IS es un proceso de construcción y transformación secuencial de una serie de modelos consistentes en todas las etapas del ciclo de vida (LC) de un IS. En cada etapa del ciclo de vida, se crean modelos específicos: organizaciones, requisitos de PI, PI de proyectos, requisitos de aplicaciones, 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 provisión para uso colectivo se lleva a cabo utilizando herramientas de software especiales: herramientas CASE.
El proceso de creación de una IP se divide en una serie de etapas (etapas), limitadas por ciertos períodos de tiempo y que finalizan con el lanzamiento de un producto específico (modelos, productos de software, documentación, etc.).
Por lo general, se distinguen las siguientes etapas de la creación de un SI: la formación de los requisitos del sistema, el diseño, la implementación, las pruebas, la puesta en servicio, la operación y el mantenimiento.
La etapa inicial del proceso de creación de un SI es el modelado de los procesos de negocio que tienen lugar en una organización y la implementación de sus metas y objetivos. El modelo de organización, descrito en términos de procesos comerciales y funciones comerciales, nos permite formular los requisitos básicos para SI. Esta posición fundamental de la metodología proporciona objetividad en el desarrollo de requisitos para el diseño del sistema. El conjunto de modelos para describir los requisitos de SI se convierte luego en un sistema de modelos que describen el diseño conceptual de SI. Modelos de arquitectura SI, requerimientos de software (SW) y soporte de información(Y SOBRE). Luego se forma el software y la arquitectura IO, se identifican las bases de datos corporativas y las aplicaciones individuales, se forman los modelos de requisitos de la aplicación y se lleva a cabo su desarrollo, prueba e integración.
El propósito de las etapas iniciales de la creación de IS, realizadas en la etapa de análisis de las actividades de la organización, es la formación de requisitos para IS que reflejen de manera correcta y precisa las metas y objetivos de la organización del cliente. Para especificar el proceso de creación de un SI que satisfaga las necesidades de la organización, debe averiguar y articular claramente cuáles son estas necesidades. Para ello, es necesario determinar los requisitos de los clientes para SI y plasmarlos en el lenguaje de modelos en los requisitos para el desarrollo de un proyecto de SI de tal forma que se asegure el cumplimiento de las metas y objetivos de la organización.
La tarea de formar requisitos para la PI es una de las más responsables, difíciles de formalizar y la más costosa y difícil de corregir en caso de error. Las herramientas y los productos de software modernos le permiten crear rápidamente IS de acuerdo con los requisitos ya preparados. Pero a menudo estos sistemas no satisfacen a los clientes, requieren numerosas mejoras, lo que conduce a un fuerte aumento en el costo real de IS. La razón principal de esta situación es la definición incorrecta, inexacta o incompleta de los requisitos de PI en la etapa de análisis.
En la etapa de diseño, en primer lugar, se forman modelos de datos. Los diseñadores reciben los resultados del análisis como información inicial. La construcción de modelos de datos lógicos y físicos es una parte importante del diseño de bases de datos. El modelo de información obtenido durante el 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 realiza el diseño de procesos con el fin de obtener especificaciones (descripciones) de todos los módulos del SI. Ambos procesos de diseño están estrechamente relacionados porque parte de la lógica comercial generalmente se implementa en la base de datos (restricciones, activadores, procedimientos almacenados). El objetivo principal del diseño de procesos es mapear las funciones obtenidas en la etapa de análisis en los módulos del sistema de información. Al diseñar módulos, se definen 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:
esquema de base de datos (basado en el modelo ER desarrollado en la etapa de análisis);
Un conjunto de especificaciones para los módulos del sistema (se construyen sobre la base de modelos de funciones).
Además, en la etapa de diseño también se lleva a cabo el desarrollo de la arquitectura SI, incluyendo la elección de plataforma (plataformas) y sistema operativo ( sistemas operativos). En un SI heterogéneo, varias computadoras pueden operar en diferentes plataformas de hardware y ejecutar diferentes sistemas operativos. Además de la elección de la plataforma, durante la fase de diseño se determinan las siguientes características de la arquitectura:
si será una arquitectura de "archivo-servidor" o "cliente-servidor";
¿Será una arquitectura de 3 niveles con las siguientes capas: servidor, middleware (servidor de aplicaciones), software de cliente;
Si la base de datos será centralizada o distribuida. Si la base de datos está distribuida, qué mecanismos se utilizarán para mantener la consistencia y relevancia de los datos;
• si la base de datos será homogénea, es decir, si todos los servidores de bases de datos serán del mismo fabricante (por ejemplo, todos los servidores solo de Oracle o todos los servidores solo de DB2 UDB). Si la base de datos no es homogénea, entonces qué software se utilizará para intercambiar datos entre DBMS de diferentes fabricantes (ya existentes o desarrollados específicamente como parte del proyecto);
· si se utilizarán servidores de bases de datos paralelos (por ejemplo, Oracle Parallel Server, DB2 UDB) para lograr un rendimiento adecuado.
La etapa de diseño finaliza con el desarrollo de un diseño técnico del SI. Durante la fase de implementación, la creación software documentación operativa.
Una vez que se completa el desarrollo de un solo módulo del sistema, se realiza una prueba autónoma, que tiene dos objetivos principales:
detección de fallas de módulos (fallas duras);
Cumplimiento del módulo con la especificación (la presencia de todas las funciones necesarias, la ausencia de funciones innecesarias).
Una vez que 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 enlace, que deberían rastrear su influencia mutua.
A continuación, se prueba la confiabilidad de un grupo de módulos, es decir, pasan, en primer lugar, pruebas de simulación de fallas del sistema y, en segundo lugar, pruebas de tiempo entre fallas. El primer grupo de pruebas muestra qué tan bien se recupera el sistema de fallas de software, fallas de hardware. El segundo grupo de pruebas determina el grado de estabilidad del sistema durante el funcionamiento normal y le permite evaluar el tiempo de actividad del sistema. El conjunto de pruebas de estabilidad debe incluir pruebas que simulen la carga máxima en el sistema.
Luego, todo el conjunto de módulos pasa una prueba del sistema, una prueba de aceptación interna del producto, que muestra el nivel de su calidad. Esto incluye pruebas de funcionalidad y pruebas de confiabilidad del sistema.
La última prueba del sistema de información es la prueba de aceptación. 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 que la implementación cumple con los requisitos del cliente.
1El artículo está dedicado a los problemas de construcción de un sistema de información diseñado para analizar proyectos de inversión que se someten a estructuras administrativas para obtener apoyo financiero. La estructura de dicho sistema es un complejo de información que consta de un módulo externo y el sistema principal. El módulo externo está diseñado para preparar la información inicial del proyecto y está ubicado en la empresa participante en el concurso. El sistema principal analiza los proyectos y está ubicado en el órgano de control administrativo. La estructura del sistema principal tiene como objetivo implementar las características del análisis de proyectos de inversión. El documento también propone los principios básicos y la metodología para evaluar proyectos de inversión. Para evaluar el proyecto, un conjunto de indicadores iniciales se dividen en grupos que caracterizan a las partes individuales condición financiera organizaciones También se incluyen indicadores adicionales que son importantes para el desarrollo social, cultural y otros del territorio. En este sentido, la metodología presentada permite, en el proceso de toma de decisiones sobre la asignación de préstamos, clasificar los proyectos de inversión no solo por indicadores financieros, sino también tener en cuenta las prioridades de la administración estructura organizativa no está directamente relacionado con la condición financiera de la organización que participa en la competencia.
Sistema de informacion
estructura
técnica
proyecto de inversión
estructura administrativa
1. Brykin I.M., Beklemishev A.V. Evaluación, selección y análisis de proyectos de inversión. - M .: LLC "International Media Group", 2011. - 47 p.
2. Bailey D.V., Sharp UF, Alexander G.D. Inversiones. – M.: INFRA-M, 2012. – 1028 p.
3. Vilensky P.L., Livshits V.N., Smolyak S.A. Evaluación de la eficacia de los proyectos de inversión. Teoría y práctica: Proc. Beneficio. – M.: Delo, 2008. – 888 p.
4. Kravchenko T.K., Presnyakov V.F. Tecnologías de infocomunicación de gestión empresarial - M.: Escuela Superior de Economía de la Universidad Estatal, 2003. - 272 p.
5. Lipsits I.V., Kossov V.V. Análisis de inversiones. Preparación y evaluación de inversiones en activos reales. – M.: INFRA-M, 2014. – 320 p.
6. Svetlov N.M., Svetlova G.N. Tecnologías de la información gestión de proyectos - M.: INFRA-M, 2012. - 144 p.
7. Shuremov E. Análisis de negocios por computadora. // Mundo PC. - 1998. - Nº 1. - P. 80–83.
Eficiencia de aceptación las decisiones de gestión para la provisión de inversiones en el campo de la pequeña empresa en condiciones de mercado depende en gran medida de las herramientas utilizadas para analizar las actividades financieras y económicas de las empresas. La elección de herramientas de análisis para estructuras organizativas administrativas es especialmente importante, cuando la decisión de prestar a un proyecto debe estar influenciada no solo por el desempeño financiero de la empresa, sino también por las prioridades de la entidad administrativa que está bajo el control de este. estructura organizativa.
Los problemas considerados en el artículo están relacionados con el desarrollo de sistemas para analizar las actividades de una empresa. organizaciones externas y órganos de dirección y control. El propósito de los sistemas no es solo evaluar la condición financiera y económica de la empresa, sino también las posibilidades y perspectivas de interacción o colaboración con ella. La base de información del análisis está compuesta por indicadores obtenidos de una u otra forma de la contabilidad estándar, informes estadísticos y fuentes abiertas.
Entre los sistemas financieros y analíticos existentes, se pueden destacar los desarrollos de firmas como Expert Systems, Galaktika, INEK, Alt-Invest, sin embargo, su uso efectivo sin modificaciones por parte de las estructuras organizativas administrativas es problemático, ya que estos sistemas no resuelven los problemas de evaluación del proyecto en relación con los parámetros que son prioritarios para estructura administrativa pero no de carácter financiero.
Estructura del sistema de información
La necesidad y pertinencia de un análisis cualitativo del flujo de proyectos de inversión y las diferencias existentes en los intereses de un inversionista común y un inversionista en forma de estructura organizacional administrativa trasladan el problema de elegir un instrumento al plano de su desarrollo. Al mismo tiempo, es recomendable asignar las siguientes tareas al sistema desarrollado:
Análisis de la situación financiera de la empresa, incluso en dinámica;
Análisis de la parte financiera del plan de negocios del proyecto;
Análisis del impacto del crédito en la situación financiera de la empresa;
Tener en cuenta las prioridades de la ciudad en el proceso de análisis de proyectos;
Análisis comparativo de proyectos de varias empresas;
Pronóstico del desarrollo de la empresa y el retorno de los préstamos.
En base a las características y la naturaleza de las tareas establecidas, se ha desarrollado un diagrama de bloques del sistema de análisis, que se muestra en la figura.
El módulo externo del sistema es un programa autónomo que está diseñado para preparar la información inicial necesaria para tomar una decisión sobre la asignación de un préstamo para financiar el proyecto propuesto:
Balance y documentos adicionales del balance;
Parte financiera del plan de negocios del proyecto;
Información adicional requerida para tener en cuenta las prioridades de la autoridad administrativa.
El módulo proporciona tanto la entrada directa de información mediante el teclado como el trabajo en el modo de importación de datos de otros sistemas. Al mismo tiempo, el módulo externo verifica la exactitud de la información ingresada para excluir errores no intencionales.
La estructura de la parte principal del sistema tiene como objetivo implementar las características del análisis de proyectos de inversión.
El papel clave lo desempeña el "Módulo para configurar el entorno de trabajo y el sistema experto". Este módulo genera diferentes escenarios análisis, definición reglas adicionales y criterios que reflejen los intereses de la ciudad y de la administración, fijando valores críticos de ratios financieros.
"Módulo para el cálculo de indicadores financieros" calcula ratios financieros.
Diagrama estructural del sistema de información para el análisis de proyectos de inversión
El "Módulo de visualización de resultados y análisis de proyectos" presenta los resultados del análisis de forma analítica, gráfica y tabular.
El "módulo de generación de informes" está asociado con el estándar herramientas de software y está destinado a la preparación de materiales informativos.
El sistema experto está diseñado para ayudar en el análisis de los resultados obtenidos.
Metodología para el análisis de proyectos de inversión
La metodología para el análisis de proyectos de inversión consiste en un análisis integral de la situación financiera de una empresa, junto con una evaluación del proyecto de inversión en sí mismo y la determinación de la calificación del proyecto para la posterior toma de decisiones sobre la asignación de préstamos.
Hay muchos indicadores iniciales, que se dividen en grupos que caracterizan ciertos aspectos de la situación financiera de la organización. Estos grupos de indicadores se concentran en documentos separados, por ejemplo, un informe contable, etc.
Por lo tanto, hay L-grupos de indicadores iniciales, donde y L-grupos de indicadores relativos, donde l es el número del grupo y kl es el número ordinal del indicador en el grupo.
Con base en los indicadores primarios, se forman grupos Q de indicadores secundarios, donde q = 1, Q, y mq es el número ordinal del indicador en el grupo q-ésimo. A estos indicadores los llamamos coeficientes.
Sobre la base de indicadores e indicadores de la dinámica de su cambio se forman en unidades absolutas y relativas del tipo.
donde j - caracteriza el número de mediciones del indicador o coeficiente.
Cada indicador y coeficiente se fija en un número de puntos de tiempo. Los valores obtenidos nos permiten identificar la dinámica de cambios en indicadores y coeficientes a lo largo del tiempo:
Entonces yo = J + 1.
Se establecen condiciones para los coeficientes. La correspondencia de los coeficientes con las condiciones muestra que el estado de las características generalizadas de la situación financiera de la empresa, que está determinado por este coeficiente, es normal.
En el proceso de análisis de un proyecto emprendedor se resuelven al menos tres tareas fundamentales:
a) evaluación de la posibilidad de reembolso del préstamo por parte de la empresa en cuestión y, en consecuencia, la decisión de incluirla en la lista de potencialmente aptos para el préstamo;
b) evaluación de la posibilidad de préstamo, con base en las prioridades de la administración;
Estas tareas se resuelven en el marco de un análisis multinivel de coeficientes e indicadores.
El análisis se realiza con el cálculo de coeficientes y evaluación de condiciones. Los coeficientes se dividen dentro de los grupos en subgrupos de más y menos importantes. El primer nivel de análisis está asociado a la evaluación del cumplimiento de condiciones para los subgrupos de coeficientes seleccionados y resuelve principalmente el problema
a) En el segundo nivel y subsiguientes se analizan otros coeficientes e indicadores, así como la dinámica de su cambio.
Los resultados del análisis se redactan en forma de documentos separados, que caracterizan los diversos aspectos de la empresa y el proyecto propuesto.
En la siguiente etapa, se forma una evaluación del proyecto de acuerdo con el elemento
b) Para tener en cuenta los intereses de la administración, se introduce un grupo adicional de indicadores (fh) y condiciones (χh), donde h = 1,H. Estos indicadores pueden ser calculados o presentados por la empresa. Si una empresa no cumple con los criterios, se la excluye del grupo de empresas potencialmente acreditadas.
a) se forman opciones para determinar la calificación de los proyectos de inversión, enfocados en la evaluación dentro de cualquier dirección, por ejemplo, en el campo de la producción productos alimenticios etc. Las principales diferencias entre las opciones, o llamémoslas escenarios, son que:
En los grupos de indicadores y coeficientes relativos, se distinguen elementos separados, que se tendrán en cuenta al determinar la calificación del proyecto en este escenario, es decir.
donde ζ es el número de escenario;
Para indicadores y coeficientes seleccionados, se establecen ponderaciones que caracterizan el impacto de este indicador en la calificación en este grupo, es decir, respectivamente
Asimismo, se determinan los pesos para los grupos de indicadores y coeficientes que participan en la calificación, es decir. , donde d ζ es el número del grupo, y D ζ es el número total de grupos que participan en la evaluación;
Los pesos son menores que 1, la suma de los pesos de cada conjunto sobre toda la muestra es 1.
b) se forma la versión de la mejor empresa para el conjunto de proyectos evaluados. La versión de la mejor empresa es un conjunto de indicadores previamente seleccionados con los mejores valores sobre todo el conjunto, es decir. los valores de estos indicadores pueden pertenecer a diferentes empresas. Esta versión no está asociada con un objeto real y se utiliza con fines de calificación. Todas las relaciones adicionales para la evaluación de la calificación se dan solo para los coeficientes. Se construyen fórmulas similares para los parámetros y fh.
Así, se forma un conjunto de indicadores, donde, si cuanto más alto, mejor, y en caso contrario. Aquí s es el número de la empresa en la lista y es el valor del coeficiente para la s-ésima empresa.
donde, si el crecimiento del coeficiente caracteriza la mejora en la condición financiera de la empresa y
e) cuanto mayor sea R ζ s, mayor será la calificación de la empresa s-ésima en el escenario de evaluación ζ-ésima.
Al normalizar (R ζ s) por , es posible ordenar las empresas en orden ascendente o descendente de su calificación. La calificación por indicadores , y fh se puede realizar por separado.
Conclusión
La metodología presentada permite, en el proceso de tomar una decisión sobre la asignación de préstamos, clasificar los proyectos de inversión no solo por indicadores financieros, sino también tener en cuenta las prioridades de la estructura organizativa administrativa que no están directamente relacionadas con la condición financiera de la organización participante en el concurso.
Así, el sistema de información, una vez implantado, será una potente herramienta que incorpore mecanismos eficaces de apoyo a la decisión en el ámbito de la actividad inversora y que esté orientado a proporcionar un análisis tanto de la situación financiera de las empresas como de los proyectos de inversión presentados a concurso.
Enlace bibliográfico
Klevtsov SI, Klevtsova AB MODELO DE SISTEMA DE INFORMACIÓN PARA ANÁLISIS DE PROYECTOS DE INVERSIÓN PARA ESTRUCTURAS ADMINISTRATIVAS // Investigación básica. - 2016. - Nº 12-1. - pág. 58-61;URL: http://fundamental-research.ru/ru/article/view?id=41046 (fecha de acceso: 26/04/2019). Traemos a su atención las revistas publicadas por la editorial "Academia de Historia Natural"
Diseño de sistemas de información
Parte 1. Etapas del desarrollo del proyecto: estrategia y análisis.
Introducción "Cascada" - esquema de desarrollo del proyecto Estrategia Análisis diagramas ER arcos Normalización diagramas de flujo de datos Algunos principios para comprobar la calidad y la exhaustividad del modelo de información calidad de la entidad Calidad del atributo Calidad de conexión Funciones del sistema Refinamiento de la estrategia
Introducción
El diseño de sistemas de información siempre comienza con la definición del propósito del proyecto. La tarea principal de cualquier proyecto exitoso es garantizar que en el momento del lanzamiento del sistema y durante todo el período de su operación sea posible proporcionar:
la funcionalidad requerida del sistema y el grado de adaptación a las condiciones cambiantes de su funcionamiento;
rendimiento requerido del sistema;
el tiempo de respuesta requerido del sistema a una solicitud;
funcionamiento sin problemas del sistema en el modo requerido, en otras palabras, la preparación y disponibilidad del sistema para procesar las solicitudes de los usuarios;
facilidad de operación y soporte del sistema;
la seguridad necesaria.
El rendimiento es el principal factor que determina la eficiencia de un sistema. Un buen diseño es la base de un sistema de alto rendimiento.
El diseño de sistemas de información cubre tres áreas principales:
diseñar objetos de datos para ser implementados en la base de datos;
diseñar programas, formularios de pantalla, informes que aseguren 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 (archivo-servidor o cliente-servidor), procesamiento en paralelo, procesamiento de datos distribuidos, etc.
En condiciones reales, el diseño es una búsqueda de una forma que satisfaga los requisitos de funcionalidad del sistema por medio de las tecnologías disponibles, teniendo en cuenta las restricciones dadas.
Cualquier proyecto está sujeto a una serie de requisitos absolutos, por ejemplo, el tiempo máximo de desarrollo del proyecto, la inversión financiera máxima en el proyecto, etc. Una de las dificultades del diseño es que no está tan estructurado como el análisis de los requisitos del proyecto o la implementación de una solución de diseño particular.
Se cree que un sistema complejo no se puede describir en principio. Esto, en particular, se refiere a los sistemas de gestión empresarial. Uno de los principales argumentos es un cambio en las condiciones de funcionamiento del sistema, por ejemplo, un cambio de directiva en ciertos flujos de información por parte de la nueva dirigencia. Otro argumento es el alcance de los términos de referencia, que para un proyecto grande puede tener cientos de páginas, mientras que el proyecto técnico puede contener errores. Surge la pregunta: tal vez sea mejor no realizar encuestas ni realizar ningún proyecto técnico, sino escribir el sistema "desde cero" con la esperanza de que haya una coincidencia milagrosa del deseo del cliente con lo que escribieron los programadores, y también que todo esto funcionará de manera estable?
Si lo observa, ¿el desarrollo del sistema es realmente tan impredecible y es realmente imposible obtener información al respecto? Es probable que a través de seminarios se pueda obtener una idea del sistema en su conjunto y de las formas (gestión) previstas para su desarrollo. Después de eso, divida el sistema complejo en componentes más simples, simplifique las conexiones entre los componentes, prevea la independencia de los componentes y describa las interfaces entre ellos (para que un cambio en un componente no implique automáticamente un cambio significativo en otro componente) , así como la posibilidad de ampliar el sistema y los "stubs" por irrealizables en una u otra versión del sistema de funciones. Con base en consideraciones tan elementales, la descripción de lo que se supone que debe implementarse en el sistema de información ya no parece tan irreal. Puede seguir los enfoques clásicos para el desarrollo de sistemas de información, uno de los cuales es el esquema de "cascada" ( arroz. 1) se describe a continuación. También se considerarán brevemente algunos otros enfoques para el desarrollo de sistemas de información, donde el uso de los elementos descritos en el esquema de "cascada" también es aceptable. Qué enfoque de los que se describen a continuación seguir (y si tiene sentido idear su propio enfoque) es, hasta cierto punto, una cuestión de gusto y circunstancias.
Arroz. 1. Esquema de cascada
El ciclo de vida del software es un modelo para su creación y uso. El modelo refleja sus diversos estados, comenzando desde el momento en que surge la necesidad de este software y terminando en el momento en que está completamente fuera de uso para todos los usuarios. Se conocen los siguientes modelos de ciclo de vida:
modelo en cascada. La transición a la siguiente etapa significa la finalización completa del trabajo en la etapa anterior.
Modelo por etapas con control intermedio. El desarrollo de software se lleva a cabo en iteraciones con ciclos. comentario entre etapas. Los ajustes entre etapas pueden reducir la complejidad del proceso de desarrollo en comparación con el modelo en cascada; el tiempo de vida de cada una de las etapas se extiende durante todo el período de desarrollo.
modelo en espiral. Atención especial se da a las etapas iniciales de desarrollo - desarrollo, análisis y diseño de estrategias, donde se comprueba y justifica la viabilidad de determinadas soluciones técnicas mediante la creación de prototipos (prototyping). Cada vuelta de la espiral implica la creación de una determinada versión del producto o de alguno de sus componentes, mientras se especifican las características y objetivos del proyecto, se determina su calidad y se planifica el trabajo de la siguiente vuelta de la espiral.
A continuación consideraremos algunos de los esquemas de desarrollo del proyecto.
al principio
"Cascada" - esquema de desarrollo del proyecto
Muy a menudo, el diseño se describe como una etapa separada del desarrollo del proyecto entre el análisis y el desarrollo. Sin embargo, en realidad, no existe una división clara de las etapas de desarrollo del proyecto: el diseño, por regla general, no tiene un principio y un final claramente definidos y, a menudo, continúa en las etapas de prueba e implementación. Hablando de la etapa de prueba, también se debe tener en cuenta que tanto la etapa de análisis como la etapa de diseño contienen elementos del trabajo de los probadores, por ejemplo, para obtener una justificación experimental para elegir una solución en particular, así como para evaluar los criterios de calidad. del sistema resultante. En la etapa de operación, es apropiado hablar sobre el mantenimiento del sistema.
A continuación consideraremos cada una de las etapas, deteniéndonos con más detalle en la etapa de diseño.
al principio
Estrategia
Definir una estrategia implica examinar el sistema. La tarea principal de la encuesta es evaluar el alcance real del proyecto, sus metas y objetivos, así como obtener definiciones de entidades y funciones a un alto nivel.
En esta etapa se involucran analistas de negocios altamente calificados, quienes tienen acceso constante a la gestión de la empresa; la etapa implica una estrecha interacción con los principales usuarios del sistema y expertos del negocio. La tarea principal de la interacción es obtener la información más completa posible sobre el sistema (una comprensión completa e inequívoca de los requisitos del cliente) y transferir esta información de forma formal a los analistas del sistema para la etapa de análisis posterior. Por regla general, la información sobre el sistema se puede obtener como resultado de conversaciones o seminarios con la dirección, los expertos y los usuarios. Por lo tanto, se determina la esencia de este negocio, las perspectivas para su desarrollo y los requisitos para el sistema.
Una vez completada la etapa principal de la encuesta del sistema, los técnicos formulan enfoques técnicos probables y estiman los costos de hardware, software comprado y desarrollo de nuevo software (que, de hecho, es asumido por el proyecto).
El resultado de la etapa de definición de la estrategia es un documento que establece claramente lo que recibirá el cliente si acepta financiar el proyecto; cuando recibe el producto terminado (horario de trabajo); cuánto costará (para proyectos grandes, se debe elaborar un cronograma de financiamiento en diferentes etapas del trabajo). El documento debe reflejar no solo los costos, sino también los beneficios, por ejemplo, el tiempo de recuperación del proyecto, el efecto económico esperado (si se puede estimar).
El documento debe describir:
restricciones, riesgos, factores críticos que afectan el éxito del proyecto, por ejemplo, el tiempo de respuesta del sistema a una solicitud es una limitación determinada y no un factor deseable;
un conjunto de condiciones bajo las cuales se supone que operará el futuro sistema: arquitectura del sistema, hardware y recursos de software provisto al sistema, las condiciones externas para su funcionamiento, la composición de personas y obras que aseguren el buen funcionamiento del sistema;
plazos para la realización de las etapas individuales, la forma de entrega del trabajo, los recursos involucrados en el proceso de desarrollo del proyecto, las medidas para proteger la información;
descripción de las funciones realizadas por el sistema;
requisitos futuros para el sistema en caso de su desarrollo, por ejemplo, la capacidad del usuario para trabajar con el sistema a través de Internet, etc.;
entidades necesarias para realizar las funciones del sistema;
interfaces y distribución de funciones entre una persona y un sistema;
requisitos para el software y los componentes de información del software, requisitos para el DBMS (si se supone que el proyecto se implementará para varios DBMS, entonces los requisitos para cada uno de ellos, o Requerimientos generales a un DBMS abstracto y una lista de los recomendados para este proyecto DBMS que satisfacen las condiciones especificadas);
que no se implementará en el marco del proyecto.
Hecho en este escenario El trabajo permite responder a la pregunta de si vale la pena continuar con este proyecto y qué requisitos del cliente se pueden cumplir bajo ciertas condiciones. Puede resultar que el proyecto no tenga sentido continuar, por ejemplo, porque ciertos requisitos no pueden ser satisfechos por algunas razones objetivas. Si se toma la decisión de continuar con el proyecto, entonces ya está disponible una idea del alcance del proyecto y la estimación de costos para la siguiente etapa del análisis.
Cabe señalar que en la etapa de elección de una estrategia, y en la etapa de análisis, y durante el diseño, independientemente del método utilizado en el desarrollo del proyecto, siempre se deben clasificar las funciones planificadas del sistema en orden de importancia. . Clegg, Dai y Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994, propusieron un posible formato para representar dicha clasificación, MoSCoW.
Esta abreviatura significa: Debe tener - funciones necesarias; Debería tener - funciones deseables; Podría tener - posibles funciones; Won "t have - funciones faltantes.
La implementación de las funciones de la segunda y tercera categoría está limitada por el marco temporal y financiero: desarrollamos lo que se necesita, así como el máximo número posible de funciones de la segunda y tercera categoría en orden de prioridad.
al principio
Análisis
La etapa de análisis involucra un estudio detallado de los procesos de negocio (funciones definidas en la etapa de selección de la estrategia) y la información necesaria para su implementación (entidades, sus atributos y relaciones (relaciones)). En esta etapa, se crea un modelo de información y, en la siguiente etapa de diseño, se crea un modelo de datos.
Toda la información sobre el sistema recopilada en la etapa de definición de la estrategia se formaliza y refina en la etapa de análisis. Se debe prestar especial atención a la integridad de la información transmitida, el análisis de la información para la ausencia de contradicciones, así como la búsqueda de información que no se utiliza en absoluto o se duplica. Como regla general, el cliente no forma inmediatamente los requisitos para el sistema como un todo, sino que formula los requisitos para sus componentes individuales. Preste atención a la consistencia de estos componentes.
Los analistas recopilan y registran información en dos formas interrelacionadas:
funciones: información sobre eventos y procesos que ocurren en los negocios;
entidades: información sobre cosas que son importantes para la organización y sobre las cuales se sabe algo.
Los dos resultados clásicos del análisis son:
una jerarquía de funciones que descomponga el procesamiento en sus partes componentes (lo que se hace y en qué consiste);
modelo entidad-relación (Modelo de relación de entrada, modelo ER), que describe las entidades, sus atributos y las conexiones (relaciones) entre ellas.
Estos resultados son necesarios pero no suficientes. Los resultados suficientes incluyen diagramas de flujo de datos y diagramas ciclos de vida entidades. Muy a menudo, se producen errores de análisis al intentar mostrar el ciclo de vida de una entidad en un diagrama ER.
A continuación repasaremos las tres metodologías de análisis estructural más utilizadas:
Diagramas de entidad-relación (ERD), que sirven para formalizar información sobre entidades y sus relaciones;
diagramas de flujo de datos (Data Flow Diagrams, DFD), que sirven para formalizar la representación de las funciones del sistema;
diagramas de transición de estado (State Transition Diagrams, STD), que reflejan el comportamiento del sistema, en función del tiempo; Los diagramas de ciclo de vida de la entidad pertenecen a esta clase de diagramas.
al principio
diagramas ER
diagramas ER ( arroz. 2) se utilizan para diseñar datos y son una forma estándar de definir datos y relaciones entre ellos. Así, se lleva a cabo el desglose de los almacenes de datos. El diagrama ER contiene información sobre las entidades del sistema y cómo interactúan, incluye la identificación de objetos que son importantes para el área temática (entidades), las propiedades de estos objetos (atributos) y sus relaciones con otros objetos (enlaces). En muchos casos, el modelo de información es muy complejo y contiene muchos objetos.
Arroz. 2. Un ejemplo de un diagrama ER
Una entidad se muestra como un rectángulo con el nombre de la entidad en la parte superior (por ejemplo, TÍTULOS). El cuadro puede enumerar los atributos de una entidad; los atributos de los diagramas ER, escritos en negrita, son clave (por lo que la Identidad del título es un atributo clave de la entidad TÍTULOS, otros atributos no son clave).
Una relación se representa mediante una línea entre dos entidades (líneas azules en la figura).
Una sola línea a la derecha ( arroz. 3) significa "uno", "pata de pájaro", a la izquierda es "muchos", y la relación se lee a lo largo de la línea, como "uno a muchos". Una barra vertical significa "requerido", un círculo - "opcional", por ejemplo, para cada publicación en TÍTULO, se debe indicar un editor en EDITORES, y un editor en EDITORES puede publicar varios títulos en TÍTULOS. Cabe señalar que los enlaces siempre se comentan (una inscripción en la línea que representa el enlace).
Arroz. 3. elemento del diagrama ER
También damos un ejemplo ( arroz. 4) imágenes de la relación reflexiva "empleado", donde un empleado puede supervisar a varios subordinados y así sucesivamente en la jerarquía de puestos.
Arroz. 4. Diagrama ER de una relación reflexiva
Tenga en cuenta que tal relación siempre es opcional, de lo contrario sería una jerarquía infinita.
Los atributos de la entidad pueden ser clave: están en negrita; obligatorio: están precedidos por el signo "*", es decir, su valor siempre se conoce, opcional (opcional): están precedidos por O, es decir, los valores de este atributo en algún momento pueden ser ausente o indefinido.
al principio
arcos
Si una entidad tiene un conjunto de relaciones mutuamente excluyentes con otras entidades, se dice que tales relaciones están en un arco. Por ejemplo, se puede emitir una cuenta bancaria para una persona jurídica o para individual. Un fragmento del diagrama ER para este tipo de relación se muestra en arroz. 5.
Arroz. 5. Arco
En este caso, el atributo PROPIETARIO de la entidad CUENTA tiene un significado especial para esta entidad: la entidad se divide en tipos por categorías: "para un individuo" y "para entidad legal". Las entidades resultantes se denominan subtipos, y la entidad original se convierte en un supertipo. Para comprender si se necesita un supertipo o no, es necesario establecer cuántas propiedades iguales tienen diferentes subtipos. Cabe señalar que el abuso de subtipos y supertipos es un error bastante común, como se muestra en arroz. 6.
Arroz. 6. Subtipos (derecha) y supertipo (izquierda)
al principio
Normalización
Para evitar anomalías en el procesamiento de datos, se utiliza la normalización. Los principios de normalización para los objetos del modelo de información son exactamente los mismos que para los modelos de datos.
Tipos de enlaces permitidos. En un examen más detenido, las relaciones uno a uno ( arroz. 7) casi siempre resulta que A y B son en realidad diferentes subconjuntos de la misma cosa o diferentes puntos de vista sobre ella, solo que tienen nombres diferentes y relaciones y atributos descritos de manera diferente.
Arroz. 7. Relaciones uno a uno
Las relaciones de muchos a uno se muestran en arroz. 8.
Arroz. 8. Relaciones de muchos a uno
I es una construcción lo suficientemente fuerte como para que no se pueda crear una entrada de la entidad B sin crear simultáneamente al menos una entrada asociada de la entidad A.
II es la forma más común de comunicación. Asume que todas y cada una de las ocurrencias de la entidad A pueden existir solo en el contexto de una (y solo una) ocurrencia de la entidad B. A su vez, las ocurrencias de B pueden existir tanto en conexión con las ocurrencias de A como sin ella.
III - raramente usado. Tanto A como B pueden existir sin una conexión entre ellos.
Las relaciones de muchos a muchos se muestran en arroz. 9.
Arroz. 9. Relaciones de muchos a muchos
I: tal construcción a menudo tiene lugar al comienzo de la etapa de análisis y significa una conexión, ya sea que no se entienda completamente y requiera un permiso adicional, o que refleje una relación colectiva simple: una lista doblemente vinculada.
II - raramente usado. Dichos enlaces siempre están sujetos a más detalles.
Considere ahora los enlaces recursivos ( arroz. 10).
Arroz. 10. Enlaces recursivos
I - raro, pero ocurre. Refleja enlaces de un tipo alternativo.
II - muy a menudo se utiliza para describir jerarquías con cualquier número de niveles.
III - se lleva a cabo en las primeras etapas. A menudo refleja la estructura de la "lista de materiales" (anidamiento mutuo de componentes). Ejemplo: cada COMPONENTE puede constar de uno o más (otros) COMPONENTES y cada COMPONENTE puede utilizarse en uno o más (otros) COMPONENTES.
Tipos de enlace no válidos. Entre los tipos de relación no válidos se incluyen los siguientes: Relación obligatoria de muchos a muchos ( arroz. once) y una serie de enlaces recursivos ( arroz. 12).
Arroz. 11. Relaciones de muchos a muchos no válidas
Arroz. 12. Enlaces recursivos no válidos
Una relación obligatoria de muchos a muchos es básicamente imposible. Tal relación significaría que ninguna de las ocurrencias de A podría existir sin B, y viceversa. De hecho, cada construcción de este tipo siempre resulta ser errónea.
al principio
diagramas de flujo de datos
DFD lógico ( arroz. 13) muestra fuentes y sumideros (destinos) de datos externos al sistema, identifica funciones lógicas (procesos) y grupos de elementos de datos que conectan una función con otra (flujos), y también identifica almacenamientos de datos (acumuladores) a los que se accede. Las estructuras de flujo de datos y las definiciones de sus componentes se almacenan y analizan en el diccionario de datos. Cada función lógica (proceso) se puede detallar utilizando el DFD de nivel inferior; cuando ya no es útil más detalles, se pasa a expresar la lógica de la función utilizando una especificación de proceso (mini-especificación). El contenido de cada tienda también se almacena en un diccionario de datos y el modelo de datos de la tienda se expone mediante diagramas ER.
Arroz. 13. Ejemplo de DFD
En particular, el DFD no muestra los procesos que controlan el flujo de datos real y no distingue entre rutas válidas e inválidas. Los DFD contienen mucha información útil y, además:
permitirle presentar el sistema en términos de datos;
ilustrar mecanismos de alimentación de datos externos que requerirían interfaces especiales;
permitir representar procesos tanto automatizados como manuales del sistema;
realizar particiones orientadas a datos de todo el sistema.
Los flujos de datos se utilizan para modelar la transferencia de información (o incluso componentes físicos) de una parte de un sistema a otra. Los flujos en los diagramas están representados por flechas con nombre, las flechas indican la dirección del flujo de información. A veces, la información puede moverse en una dirección, procesarse y devolverse a su fuente. Tal situación puede ser modelada por dos flujos diferentes o por uno bidireccional.
Un proceso transforma un flujo de entrada en un flujo de salida según la acción especificada por el nombre del proceso. Cada proceso debe tener un número único para referenciarlo dentro del diagrama. Este número se puede utilizar junto con el número de diagrama para proporcionar un índice de proceso único en todo el modelo.
El almacenamiento de datos (data storage) le permite definir datos en una serie de áreas que se almacenarán en la memoria entre procesos. De hecho, el almacenamiento representa "porciones" de flujos de datos en el tiempo. La información que contiene se puede utilizar en cualquier momento después de definirla y los datos se pueden elegir en cualquier orden. El nombre del repositorio debe identificar su contenido. En caso de que el flujo de datos entre (salga) hacia (desde) el almacenamiento y su estructura corresponda a la estructura del almacenamiento, debe tener el mismo nombre, que no necesita reflejarse en el diagrama.
Una entidad externa (terminador) representa una entidad fuera del contexto del sistema, que es la fuente o el receptor de los datos del sistema. Su nombre debe contener un sustantivo, como "Cliente". Se supone que los objetos representados por dichos nodos no deben participar en ningún procesamiento.
al principio
Diagramas de transición de estado de STD
El ciclo de vida de una entidad pertenece a la clase de diagramas STD ( arroz. 14). Este diagrama refleja el cambio en el estado de un objeto a lo largo del tiempo. Por ejemplo, considere el estado de un producto en un almacén: un producto puede pedirse a un proveedor, entregarse en un almacén, almacenarse en un almacén, someterse a control de calidad, venderse, rechazarse o devolverse a un proveedor. Las flechas en el diagrama muestran los cambios de estado permitidos.
Figura 14. ejemplo DFD
Hay varias opciones diferentes para mostrar dichos diagramas, la figura muestra solo una de ellas.
al principio
Algunos principios para comprobar la calidad y la integridad de un modelo de información (fuente: Richard Barker, Case Method: Entity Relationship Modeling, Addison-Wesley, 1990)
Si desea crear un modelo de alta calidad, deberá recurrir a la ayuda de analistas que conocen bien la tecnología CASE. Sin embargo, esto no significa que sólo los analistas deban estar involucrados en la construcción y control del modelo de información. La ayuda de los colegas también puede ser muy útil. Implicarlos en la comprobación del objetivo y en el estudio detallado del modelo construido, tanto en términos lógicos como en la consideración de aspectos del área temática. A la mayoría de las personas les resulta más fácil encontrar fallas en el trabajo de otra persona.
Presente regularmente su modelo de información o sus fragmentos individuales sobre los que tiene dudas para la aprobación de los usuarios. Preste especial atención a las excepciones a las reglas y restricciones.
al principio
calidad de la entidad
La principal garantía de la calidad de una entidad es la respuesta a la pregunta de si el objeto es realmente una entidad, es decir, un objeto o fenómeno importante, cuya información debe almacenarse en la base de datos.
Lista de preguntas de verificación para la entidad:
¿El nombre de una entidad refleja la esencia de este objeto?
¿Hay intersección con otras entidades?
¿Hay al menos dos atributos?
¿No hay más de ocho atributos en total?
¿Existen sinónimos/homónimos para esta entidad?
¿La entidad está completamente definida?
¿Existe un identificador único?
¿Hay al menos una conexión?
¿Hay al menos una función para crear, buscar, actualizar, eliminar, archivar y usar un valor de entidad?
¿Existe un historial de cambios?
¿Se cumplen los principios de normalización de datos?
¿Existe la misma entidad en otro sistema de aplicación, quizás con un nombre diferente?
¿Es la esencia demasiado general?
¿Es suficiente el nivel de generalización incorporado en él?
Lista de preguntas de cribado para el subtipo:
¿Existen superposiciones con otros subtipos?
¿El subtipo tiene atributos y/o relaciones?
¿Tienen todos sus propios identificadores únicos o todos heredan uno del supertipo?
¿Existe un conjunto exhaustivo de subtipos?
¿No es un subtipo un ejemplo de ocurrencia de una entidad?
¿Conoce algún atributo, relación y condición que distinga este subtipo de los demás?
al principio
Calidad del atributo
Es necesario averiguar si estos son realmente atributos, es decir, si describen de una forma u otra a esta entidad.
Lista de preguntas de seguridad para un atributo:
¿Es el nombre de un atributo un sustantivo singular que refleja la esencia de la propiedad denotada por el atributo?
¿El nombre del atributo no incluye el nombre de la entidad (no debería)?
¿El atributo solo tiene un valor a la vez?
¿Faltan valores duplicados (o grupos)?
¿Se describen el formato, la longitud, los valores válidos, el algoritmo de derivación, etc.?
¿Podría este atributo ser una entidad omitida que sería útil para otro sistema de aplicación (existente o propuesto)?
¿Podría ser un enlace perdido?
¿Es necesario un historial de cambios?
¿Su valor depende sólo de la entidad dada?
Si se requiere el valor de un atributo, ¿siempre se conoce?
¿Es necesario crear un dominio para este y otros atributos similares?
¿Su valor depende solo de alguna parte del identificador único?
¿Su valor depende de los valores de algunos atributos no incluidos en el identificador único?
