Gestión de proyectos AIS. AIS “Gestión de proyectos. Conceptos básicos de diseño AIS

Existen muchos métodos y opciones para desarrollar AIS, cuyo uso depende de varios factores, por ejemplo, el tamaño de las empresas y (o) su SI, los propósitos de crear un SI, los recursos disponibles, etc. Métodos y principios de diseño un SI se discuten en los capítulos anteriores.

El ciclo de vida del proyecto de software es un conjunto de etapas y etapas del desarrollo de software, desde el análisis del sistema y el desarrollo de los requisitos iniciales hasta su instalación (instalación) en una computadora.

La experiencia en el desarrollo e implementación de varias clases de AIS ha demostrado una alta eficiencia (incluida la económica) de su aplicación, especialmente en las grandes empresas. Se refleja en una buena organización del trabajo y la producción, un aumento en la precisión de la planificación y la implementación de las tareas establecidas, para garantizar el ritmo de la empresa, reducir la proporción de trabajo manual, soporte de información efectivo (incluido el operativo) para varios categorías de usuarios, etc. El período medio de recuperación de la inversión de estos sistemas no suele superar los dos años.

Al desarrollar SI, en la mayoría de los casos, se da preferencia a soluciones de diseño estándar, adaptadas a las condiciones y capacidades específicas del Cliente. Los proyectos individuales se desarrollan en ausencia de soluciones estándar o cuando los parámetros básicos de la organización difieren significativamente (en más del 10-15%) de las soluciones estándar. Esto generalmente se aplica a organizaciones grandes y grandes.

Ningún esquema de desarrollo de CI es absoluto. Son posibles varias opciones, dependiendo, por ejemplo, de las condiciones iniciales en las que se lleve a cabo el desarrollo: se está desarrollando un sistema completamente nuevo; ya se ha realizado un relevamiento de la empresa y existe un modelo de su actividad; la empresa ya tiene un SI que puede utilizarse como prototipo inicial o debe integrarse con el desarrollado.

El desarrollo detallado del proyecto AIS presupone la disponibilidad de un conjunto completo de documentación organizativa, de diseño, tecnológica y operativa.

El diseño de cualquier objeto se realiza con:

• a) determinar su propósito funcional (por qué es necesario, qué y cómo funciona el objeto diseñado),
• b) identificar conexiones lógicas (cómo el objeto diseñado cumple su propósito funcional, qué información se procesa y en qué secuencia),
• c) la elección de los medios materiales para la implementación del objeto diseñado: el aspecto funcional, tecnológico y técnico (medios, herramientas de procesamiento de datos, etc.),
• d) la ubicación espacial (territorial) de los medios materiales de venta en las áreas asignadas o posibles para su uso,
• e) formación de la estructura organizativa y de gestión del objeto diseñado (composición de departamentos, competencias y responsabilidades funcionales trabajadores)

Después de elegir el método de diseño AIS, es necesario planificar un conjunto de trabajos para crear un sistema de acuerdo con las etapas típicas de su desarrollo. El proyecto es revisado y aprobado por el Cliente. El diseño AIS implica la implementación de ciertas etapas y etapas.

Para la implementación exitosa del proyecto, es necesario establecer hitos reales con inicio y final claramente marcados. El desarrollo de un plan de trabajo detallado está asociado a una descripción de los procesos y su secuencia realizada en cada etapa, los especialistas, fondos y recursos necesarios. Este enfoque ayuda en mayor medida a evitar omisiones y errores. Es necesario para los empleados que implementan la implementación de un proyecto de automatización, y además tiene un impacto positivo en las personas que lo financian.

La implementación por fases efectiva del trabajo de diseño está asociada con la necesidad de desarrollar un cronograma para su implementación, incluidos los recursos y el tiempo (etapas) de su implementación (ver gráficos y figuras anteriores). Los recursos incluyen el personal, el hardware, el software, la financiación y la infraestructura necesarios. Al mismo tiempo, es mejor financiarlo por separado para cada tipo de obra (compra de fondos y software, instalación, capacitación, etapas de diseño individual, etc.).

Para la automatización diferentes tipos actividades (gestión, diseño, investigación, etc.), incluidas sus combinaciones, utilizan las disposiciones de GOST 34.601-90. Proporciona las siguientes etapas y etapas de diseño (tabla 1).

Tabla 2

El estándar también establece que:

• · Las etapas y etapas realizadas por las organizaciones que participan en la creación de la UA se establecen en contratos y Términos de Referencia basados ​​en esta norma.
• · Se permite excluir la etapa "Diseño preliminar" y etapas separadas de trabajo en todas las etapas, para combinar "Diseño técnico" y "Documentación de trabajo" en una etapa "Diseño técnico de trabajo". Dependiendo de las características específicas de los sistemas nucleares que se están creando y las condiciones para su creación, se permite realizar etapas individuales de trabajo antes de la finalización de las etapas anteriores, paralelamente en el tiempo de ejecución de las etapas de trabajo, la inclusión de nuevas etapas de trabajo. .

El proyecto técnico (diseño preliminar) contiene diagramas de circuito y documentación de diseño del objeto de desarrollo y sus componentes, una lista de herramientas de software listas para usar seleccionadas y apoyo técnico(incluidos tipos de computadoras, sistemas operativos, programas de aplicación, etc.), algoritmos para la resolución de problemas para el desarrollo de nuevas herramientas de software).

Diseño detallado: la etapa de diseño final, en general, que prevé el refinamiento y detalle de los resultados de las etapas anteriores, la creación y prueba de un prototipo del objeto de automatización, el desarrollo y prueba de productos de software, documentación tecnológica y operativa.

En la práctica moderna de diseñar sistemas de información automatizados (por ejemplo, AIPS, ASNTI, ACS, etc.), puede ser la etapa inicial de su implementación en el trabajo de una organización o servicio del Cliente del proyecto, o el jefe uno en una serie de otras organizaciones automatizadas, servicios, etc.

El desarrollo detallado del diseño del sistema presupone la disponibilidad de un conjunto completo de documentación organizativa, de diseño, tecnológica y operativa.

El estándar estatal GOST 19.102-77 establece las siguientes etapas de desarrollo de la documentación del software:

• 1. Términos de referencia;
• 2. Proyecto de proyecto;
• 3. Diseño técnico;
• 4. Borrador de trabajo;
• 5. Implementación.

Tenga en cuenta que para proyectos pequeños se puede reducir el número de etapas.

Como parte de la implementación de la primera etapa “Formación de requisitos para la AU”, se levanta el objeto y se justifica la necesidad de crear un AIS, teniendo en cuenta los requisitos del usuario para el AIS diseñado. Estos procedimientos de la primera etapa de diseño forman parte del estudio de anteproyecto. Esto también puede incluir los procedimientos de la segunda etapa de diseño: “Desarrollo del concepto de central nuclear”.

En el proceso de investigación de prediseño, se está llevando a cabo un estudio de viabilidad para la viabilidad de crear un AIS; desarrollo de requisitos generales para el desarrollo de AIS.

En el proceso de un estudio de prediseño para la implementación del trabajo de diseño necesario, se identifica lo siguiente:

• · recursos materiales,
• · recursos financieros,
• · recursos humanos,
• · Recursos temporales.

Actualmente, cualquier organización tiene a su disposición algunos recursos materiales, por regla general, de origen heterogéneo. Para garantizar la seguridad de estos recursos, es necesario llevar registros y designar personas responsables. La solución a este problema se puede llevar a cabo mediante diversas aplicaciones, como 1C: Enterprise, AVARD y muchas otras. Pero estos programas son muy costosos, tanto en compra como en mantenimiento. Requieren educación y capacitación especial del personal.

Bajo diseño Debe comprender el proceso de creación de un prototipo del objeto propuesto o posible.

La tecnología moderna para crear AIS es una combinación de herramientas y métodos de diseño efectivos que simplifican este proceso, reducen los costos, acortan el tiempo del calendario de diseño del sistema y mejoran la calidad del desarrollo debido a una amplia selección de soluciones de diseño avanzadas probadas.

A la principal herramientas de diseño puede ser atribuido:

Soluciones de diseño típicas (TPD) y paquetes de aplicación (PPP). TPR: un conjunto de elementos algorítmicos y de software que garantizan la implementación de tareas en una computadora con la ayuda de los medios técnicos apropiados;

Sistemas de diseño asistido por computadora (CAD), que implican el uso de computadoras en todas las etapas de la creación de AIS.

Requisitos generales para herramientas de diseño:

Cobertura completa de todo el proceso de creación de AIS;

Compatibilidad, es decir consistencia tanto en el proceso de creación de un sistema como en el proceso de su funcionamiento;

Versatilidad, es decir la posibilidad de utilizar las mismas herramientas para diferentes objetos;

Accesibilidad en el desarrollo y simplicidad (simplicidad) en la implementación;

La capacidad de organizar el proceso de diseño en el modo de interacción interactiva del desarrollador del sistema, el diseñador y la computadora;

Adaptabilidad y rentabilidad.

Entre métodos de diseño asignar:

Diseño original;

Diseño típico y sus tipos: elemental, subsistema, modular, grupo;

Diseño asistido por ordenador.

El método de diseño original es tradicional y se centra en una empresa específica. Característica distintiva Este método es el desarrollo de métodos originales de inspección de objetos y la creación de la documentación necesaria en forma de un proyecto individual. La ventaja de este método es el reflejo de las características específicas del objeto de automatización en el proyecto AIS. Las desventajas incluyen una intensidad de trabajo relativamente alta y un tiempo de desarrollo prolongado, un indicador bajo de confiabilidad funcional y adaptabilidad a las condiciones cambiantes. Los proyectos creados con el método original se prestan a la modernización, sin embargo forma pura este método rara vez se utiliza. Hoy, durante su implementación, se utilizan varias herramientas de diseño, y solo para ciertas partes del proyecto, se requieren soluciones de diseño originales. Esto suaviza un poco sus deficiencias. Sin embargo, este método sigue siendo relevante a la hora de automatizar objetos extraordinarios y complejos.

V condiciones modernas Por lo general, AIS no se construye desde cero. En la actualidad, en la economía, en casi todos los niveles de gestión y en todos los objetos económicos, operan sistemas automatizados de procesamiento de información. La creciente necesidad de información operativa, oportuna y de alta calidad requiere la creación de AIS sobre una nueva base técnica y tecnológica.

La búsqueda de formas racionales de diseño va en las siguientes direcciones:

1. Desarrollo de soluciones de diseño estándar implementadas en paquetes de software aplicado (PPP) para la resolución de problemas económicos con la posterior vinculación del PPP a las condiciones específicas de implementación y operación;

2. desarrollo de sistemas de diseño automatizados.

La primera de las formas es la capacidad de utilizar soluciones de diseño estándar incluidas en los paquetes de programas aplicados.

Diseño típico- un método industrial para crear AIS usando TPR y RFP. Este método se caracteriza por la presencia de herramientas de automatización de control de software, informáticas, organizativas-económicas, técnicas, informáticas y probadas, estándar y comprobadas. La aplicación de este método permite reducir la intensidad de la mano de obra, reducir los costos y acortar el tiempo de diseño y mejorar la calidad del diseño. El proceso de diseño típico consiste en la selección y vinculación de subsistemas de soporte de acuerdo con los requisitos de un AIS específico. La parte típica del AIS es un complejo de información, software y hardware. La naturaleza típica del soporte de información se logra mediante el estricto apego a la unidad de la estructura de la base de información, la composición de las matrices, las formas de los documentos de entrada y salida. La naturaleza típica del software se logra mediante el uso de PPP, y la naturaleza típica del soporte técnico se logra mediante el uso de computadoras del mismo tipo o de tipos combinados.

1. Una variación del método de diseño típico es el método diseño elemental, que se basa en TPR. Al desarrollar un proyecto, se utiliza una solución preparada con modificaciones menores y no se está desarrollando una nueva.

2. Al usar método modular Los TPR se crean de forma modular, cuando cada solución de diseño se divide en componentes separados, módulos que implementan una determinada parte de TPR. Esto le permite crear un proyecto para un nuevo sistema automatizado combinando módulos estándar individuales.

3. Al usar método de diseño del subsistema para cada subsistema, se crean proyectos de solución y paquetes de aplicaciones, para todo el sistema y funcionales. La asignación de subsistemas depende del objeto del proceso económico y productivo. Para cada uno de los subsistemas, se desarrollan su propia solución de diseño automatizado y PPP, que pueden ser funcionales o para todo el sistema. Los PPP de todo el sistema incluyen PPP de gestión de datos, PPP de procedimientos estándar de procesamiento de datos, métodos de estadística matemática y programación discreta, etc. PPP funcional incluye paquetes dirigidos a empresas industriales con producción discreta o continua, en el ámbito no industrial, y gestión sectorial .

Un requisito importante para RFP es la compatibilidad, ya que al diseñar AIS, es recomendable utilizar varios paquetes a la vez. El diseño de sistemas con el uso de PPP en realidad se reduce a vincular los paquetes seleccionados de acuerdo con ciertos parámetros a las condiciones específicas del objeto de automatización. Cualidades positivas Este enfoque del diseño se puede llamar: proceso menos laborioso, reducción del tiempo de diseño en comparación con el diseño original, implementación de métodos avanzados de procesamiento de datos, simplificación de la documentación del proyecto (ya que se utiliza la documentación del paquete), mayor confiabilidad del AIS diseñado.

4. Además, hay método de diseño de grupo... Su esencia radica en la selección preliminar de un grupo de objetos del mismo tipo en términos de características. Entre ellos, se selecciona un objeto básico, para el cual se está desarrollando el proyecto, y se pueden utilizar varios métodos y métodos de diseño. Lo principal aquí es garantizar una alta adaptabilidad del proyecto. El área principal de aplicación de este método es en instalaciones no industriales (por ejemplo, almacenes).

Las siguientes actividades se prestan más eficazmente a la automatización:

1. Contabilidad, incluida la gestión y financiera. El mayor número de solicitudes de propuestas se ha creado con fines contables. Entre ellos se encuentran "1C: Contabilidad", "Turbo-Contador", "Info-Contador", "Parus", "ABACUS", "Bambi +", etc.;

2.servicio de consultas e información actividad económica... Representada por las siguientes APP: "GARANT" (impuestos, contabilidad, auditoría, emprendimiento, banca, regulación cambiaria, control aduanero); "CONSULBTANT +" (impuestos, contabilidad, auditoría, emprendimiento, banca, regulación cambiaria, control aduanero).

3.económico y actividades financieras... Representado por la siguiente RFP:

a) "Análisis económico y previsión de las actividades de una empresa, organización" (empresa "INEK"), que desarrolla las funciones: análisis Economico actividades de una firma, empresa; elaboración de planes comerciales; estudio de viabilidad para el pago de préstamos; análisis y selección de opciones de actividades; previsión de saldos, flujos de caja y productos terminados.

b) Complejo de red multiusuario de plena automatización de la corporación Galaktika (JSC Novy Atlant), que incluye planificación, gestión operativa, contabilidad y control, análisis, además, permite en el marco del DSS asegurar la solución de planificación empresarial problemas al utilizar el Proyecto PPP- Experto.

4. organización del trabajo del director;

5. automatización del flujo de documentos;

6. formación.

Recientemente, las empresas y las firmas prefieren comprar paquetes y tecnologías prefabricados y, si es necesario, agregarles su propio software, ya que el desarrollo de su propio AIS está asociado con altos costos y riesgos. Como regla general, se desarrolla y propone un sistema básico, que se adapta de acuerdo con los deseos de los clientes individuales. Al mismo tiempo, los usuarios cuentan con consultas que ayudan a minimizar el tiempo de implementación de sistemas y tecnologías, utilizarlos de la manera más efectiva y mejorar la calificación del personal.

Sistemas de diseño asistido por computadora - la segunda forma de realizar el trabajo de diseño, que se está desarrollando rápidamente.

Entre los métodos de diseño asistido por computadora, los métodos de diseño de modelos ocupan un lugar especial. La creación y uso de sistemas CAD asegura un nivel suficientemente alto de confiabilidad funcional, una cobertura integral de todos los procesos tecnológicos y una disminución en la intensidad de trabajo del trabajo de diseño con la máxima consideración por los intereses del objeto de automatización. Sin embargo, este método es bastante caro y requiere desarrolladores altamente capacitados. El requisito clave para CAD es la capacidad de construir y mantener en el sistema de diseño en un estado adecuado algún modelo de información económica global del objeto de automatización. Un modelo es una visualización explícita de los componentes de información de un objeto de automatización y las relaciones entre ellos. El objetivo principal de la construcción de un modelo es crear un proyecto AIS correspondiente a este modelo, teniendo en cuenta y utilizando activamente todas las características del objeto. Dicho modelo debería contener en forma formalizada una descripción de los conjuntos de componentes de información y la relación entre ellos, incluidos los enlaces de información y la interacción algorítmica. Usando el método de diseño de modelos, enfoque de sistemas, que determina el uso de computadoras no solo en todas las etapas de la creación de un sistema, sino también en el proceso de análisis de los resultados de su operación industrial. El desarrollo y la aplicación de CAD predeterminaron la transición a la creación de proyectos individuales, pero a un nivel significativamente más alto que el método de diseño original.

En el campo de la automatización del diseño de IP y TI, se ha formado una nueva dirección en la última década: Tecnología de desarrollo de software asistido por computadora CASE(CASO - Ingeniería de Sistemas / Software Asistido por Computadora). La creciente complejidad de los sistemas de información, los crecientes requisitos para ellos, han llevado a la necesidad de industrializar las tecnologías para su creación.

Tecnología CASE es un conjunto de métodos de análisis, diseño, desarrollo y mantenimiento de SI, apoyado por un conjunto de herramientas de automatización interconectadas. CASE es un conjunto de herramientas para analistas de sistemas, desarrolladores y programadores que automatiza el proceso de diseño y desarrollo de un CI. Los sistemas CASE se utilizan como una herramienta poderosa para resolver problemas de investigación y diseño, como el análisis estructural del área temática, la implementación del proyecto utilizando la última generación de lenguajes de programación, la publicación de la documentación del proyecto, la implementación de pruebas del proyecto, la planificación y el control del desarrollo, el modelado. aplicaciones empresariales para la resolución de problemas operativos, planificación estratégica y gestión de recursos, etc.

El objetivo principal de CASE es automatizar el desarrollo y la operación de sistemas tanto como sea posible.

Cuando se utilizan tecnologías CASE, la tecnología de trabajo en todas las etapas del ciclo de vida de los sistemas automatizados cambia. En los sistemas CASE, el diseño se basa en métodos de desarrollo visual visual, mientras que los gráficos, diagramas, tablas, diagramas y explicaciones textuales de los mismos se utilizan para describir el modelo del SI diseñado. Dichas metodologías brindan una descripción rigurosa y descriptiva del sistema que se está diseñando, que comienza con un panorama general y luego detalla, adquiriendo una estructura jerárquica con un número creciente de niveles.

La automatización de la programación se basa en la generación automática de códigos de programa que contienen descripciones de datos, la lógica principal de su procesamiento, esquemas de base de datos, archivos de descripción de interfaz, etc. Los códigos se refinan y refinan aún más, pero en algunos casos la automatización alcanza el 90%. Además, la tecnología CASE genera la documentación necesaria del proyecto, lista para su uso.

Cuando se utiliza la tecnología CASE, se proporciona el apoyo de una única base de proyecto, es decir toda la información sobre el AIS desarrollado se coloca automáticamente en una única base de datos del proyecto. Esto mantiene la coherencia, la coherencia, la integridad y la redundancia mínima de los datos de diseño.

La tecnología CASE proporciona el trabajo en equipo de los equipos de desarrollo, porque Los diferentes grupos de especialistas cuentan con las herramientas adecuadas, así como con la capacidad de realizar cambios consistentes y correctos en el proyecto por parte de varios especialistas en tiempo real.

Las tecnologías CASE se utilizan con éxito para construir casi todos los tipos de AIS. CASE también se utiliza para crear modelos de sistemas que ayuden a las estructuras comerciales a resolver los problemas de planificación estratégica, gestión financiera, determinación de la política de la empresa, formación de personal, etc.

CASE tiene las siguientes ventajas principales:

Mejorar la calidad de los SI (TI) creados mediante el control automático (en primer lugar, el control del proyecto);

Permita en poco tiempo crear un prototipo de un futuro SI (TI), que le permite evaluar rápidamente, en una etapa temprana, el resultado esperado;

Acelerar el proceso de diseño y desarrollo del sistema;

Libere al desarrollador del trabajo rutinario, permitiéndole concentrarse por completo en la parte creativa del diseño;

Apoyan el desarrollo y mantenimiento de un SI que ya funciona.

A estas alturas, ha surgido una poderosa industria CASE, que reúne a cientos de firmas y empresas de diversas orientaciones. Entre ellos destacan:

Empresas-desarrolladoras de herramientas para análisis y diseño de IP y TI

Empresas que desarrollan herramientas especiales con un enfoque en áreas temáticas limitadas o en etapas separadas del ciclo de vida de la propiedad intelectual;

Empresas de formación que organizan seminarios y cursos de formación para especialistas;

Empresas consultoras que brindan asistencia práctica en el uso de paquetes CASE para el desarrollo de SI específicos;

Empresas especializadas en la publicación de revistas y boletines sobre tecnologías CASE.

Nbsp; Modelos de ciclo de vida AIS

Modelo de ciclo de vida AIS es una estructura que describe los procesos, acciones y tareas que se llevan a cabo y durante el desarrollo, operación y mantenimiento a lo largo de todo el ciclo de vida del sistema.

La elección de un modelo de ciclo de vida depende de las características específicas, la escala, la complejidad del proyecto y el conjunto de condiciones en las que se crea y opera el AIS.

El modelo de ciclo de vida AIS incluye:

Resultados del trabajo en cada etapa;

Eventos clave o puntos de finalización y toma de decisiones.

De acuerdo con los modelos conocidos del ciclo de vida del software, se determinan los modelos del ciclo de vida del AIS: cascada, iterativo, espiral.

I. Modelo de cascada describe el enfoque clásico para el desarrollo de sistemas en cualquier área temática; fue ampliamente utilizado en las décadas de 1970 y 1980.

El modelo en cascada prevé la organización secuencial del trabajo, y la característica principal del modelo es la división de todo el trabajo en etapas. La transición de la etapa anterior a la siguiente ocurre solo después de la finalización completa de todo el trabajo de la anterior.

Asignar cinco etapas estables de desarrollo, prácticamente independientes del área temática (Fig. 1.1).

Sobre primero En esta etapa, se realiza un estudio del área del problema, se formulan los requisitos del cliente. El resultado de esta etapa son los términos de referencia (asignación de desarrollo), acordados con todas las partes interesadas.

Durante segundo etapa, de acuerdo con los requisitos de la tarea técnica, se desarrollan ciertas soluciones de diseño. Como resultado, aparece un conjunto de documentación de diseño.

Tercera etapa - implementación del proyecto; en esencia, el desarrollo de software (codificación) de acuerdo con las decisiones de diseño de la etapa anterior. En este caso, los métodos de implementación no son de fundamental importancia. El resultado de esta etapa es un producto de software terminado.

Sobre cuatro En esta etapa, se verifica que el software recibido cumpla con los requisitos establecidos en los términos de referencia. La operación de prueba le permite identificar varios tipos de fallas ocultas que aparecen en las condiciones reales del AIS.

La última etapa es la rendición. proyecto terminado, y lo principal aquí es convencer al cliente de que todos sus requisitos se cumplen en su totalidad.

Figura 1.1 Modelo en cascada del ciclo de vida AIS

Las etapas de trabajo dentro del marco del modelo en cascada a menudo se denominan partes del ciclo de diseño AIS, ya que las etapas consisten en muchos procedimientos iterativos para aclarar los requisitos del sistema y las opciones de diseño. El ciclo de vida de AIS es mucho más complicado y más largo: puede incluir una cantidad arbitraria de ciclos de aclaración, cambios y adiciones a las soluciones de diseño ya adoptadas e implementadas. En estos ciclos tiene lugar el desarrollo del AIS y la modernización de sus componentes individuales.

Las ventajas del modelo en cascada:

1) en cada etapa, se forma un conjunto completo de documentación del proyecto que cumple con los criterios de integridad y coherencia. En las etapas finales, se desarrolla la documentación del usuario, que cubre todo tipo de soporte AIS proporcionado por los estándares (organizacional, informativo, software, técnico, etc.);

2) la implementación secuencial de las etapas de trabajo le permite planificar el tiempo de finalización y los costos correspondientes.

El modelo de cascada se desarrolló originalmente para resolver varios tipos de problemas de ingeniería y hasta ahora no ha perdido su importancia para el campo aplicado. Además, el enfoque en cascada es ideal para el desarrollo de AIS, ya que ya al comienzo del desarrollo, es posible formular todos los requisitos con suficiente precisión para proporcionar a los desarrolladores la libertad de implementación técnica. Dichos AIS, en particular, incluyen sistemas de liquidación complejos y sistemas en tiempo real.

Desventajas del modelo de cascada:

Retraso significativo en la obtención de resultados;

Los errores y las deficiencias en cualquier etapa aparecen, por regla general, en las etapas posteriores del trabajo, lo que conduce a la necesidad de regresar;

La complejidad del trabajo paralelo en el proyecto;

Sobresaturación de información excesiva de cada una de las etapas;

Complejidad de la gestión de proyectos;

Alto nivel de riesgo y falta de fiabilidad de las inversiones.

Retraso en la recepción de resultados se manifiesta en el hecho de que un enfoque coherente para el desarrollo del acuerdo de los resultados con las partes interesadas se lleva a cabo solo después de la finalización de la siguiente etapa del trabajo. Como resultado, puede resultar que el AIS desarrollado no cumpla con los requisitos, y tales inconsistencias pueden surgir en cualquier etapa de desarrollo; Además, tanto los diseñadores analíticos como los programadores pueden introducir errores de forma inadvertida, ya que no es necesario que estén bien versados ​​en las áreas temáticas para las que se está desarrollando el AIS.

Regrese a etapas anteriores. Este inconveniente es una de las manifestaciones del anterior: el trabajo secuencial paso a paso en un proyecto puede llevar al hecho de que los errores cometidos en etapas anteriores se descubran solo en etapas posteriores. Como resultado, el proyecto se devuelve a la etapa anterior, se reelabora y solo luego se transfiere al trabajo posterior. Esto puede provocar una interrupción en el horario y complicar la relación entre los grupos de desarrollo que realizan etapas individuales.

La peor opción es cuando los defectos de la etapa anterior se descubren no en la etapa siguiente, sino más tarde. Por ejemplo, en la etapa de operación de prueba, pueden aparecer errores en la descripción del área temática. Esto significa que parte del proyecto debe volver a la etapa inicial de trabajo.

Complejidad del trabajo paralelo conectado con la necesidad de coordinar las diferentes partes del proyecto. Cuanto más fuerte es la relación de las partes individuales del proyecto, más a menudo y más completa debe realizarse la sincronización, más dependientes entre sí los equipos de desarrollo. Como resultado, los beneficios del trabajo paralelo simplemente se pierden; la falta de paralelismo afecta negativamente a la organización del trabajo de todo el equipo.

Problema sobresaturación de información surge de fuertes dependencias entre diferentes grupos de desarrollo. El caso es que al realizar cambios en una de las partes del proyecto, es necesario notificar a aquellos desarrolladores que lo usaron (podrían usarlo) en su trabajo. Con una gran cantidad de subsistemas interconectados, la sincronización de la documentación interna se convierte en una tarea importante separada: los desarrolladores deben familiarizarse constantemente con los cambios y evaluar cómo estos cambios afectarán los resultados obtenidos.

Complejidad de la gestión de proyectos principalmente debido a la estricta secuencia de etapas de desarrollo y la presencia de relaciones complejas entre las diferentes partes del proyecto. La secuencia de trabajo regulada lleva a que algunos grupos de desarrollo tengan que esperar los resultados del trabajo de otros equipos, por lo que se requiere una intervención administrativa para acordar el momento y la composición de la documentación presentada.

Si se detectan errores en el trabajo, es necesario volver a las etapas anteriores; se interrumpe el trabajo actual de quienes cometieron un error. La consecuencia de esto suele ser un retraso en la finalización tanto del proyecto corregido como del nuevo.

Es posible simplificar la interacción entre desarrolladores y reducir la sobrecarga de información de la documentación al reducir el número de conexiones entre partes individuales del proyecto, pero no todos los AIS se pueden dividir en subsistemas poco acoplados.

Alto nivel de riesgo. Cuanto más complejo es el proyecto, más demora cada etapa de desarrollo y más complejas son las interconexiones entre las partes individuales del proyecto, cuyo número también aumenta. Además, los resultados del desarrollo se pueden ver y evaluar realmente solo en la etapa de prueba, es decir, después de completar las etapas de análisis, diseño y desarrollo, cuya implementación requiere una gran cantidad de tiempo y dinero.

La evaluación tardía crea serios problemas para identificar errores en el análisis y el diseño; requiere volver a etapas anteriores y repetir el proceso de desarrollo. Sin embargo, el regreso a etapas anteriores puede estar asociado no solo a errores, sino también a cambios que se han producido en el área temática o en los requerimientos del cliente durante el desarrollo. Al mismo tiempo, nadie garantiza que el área temática no volverá a cambiar para cuando la próxima versión del proyecto esté lista. De hecho, esto significa que existe la posibilidad de "bucle" en el proceso de desarrollo: los costos del proyecto crecerán constantemente y los plazos para la entrega del producto terminado se posponen constantemente.

II. Modelo iterativo Consiste en una serie de ciclos cortos (pasos) de planificación, implementación, estudio, acción.

La creación de AIS complejos implica la aprobación de soluciones de diseño obtenidas en la implementación de tareas individuales. El enfoque de diseño de abajo hacia arriba requiere tales iteraciones de retornos, cuando las soluciones de diseño para tareas individuales se combinan en soluciones sistémicas comunes. Al mismo tiempo, es necesario revisar los requisitos formados previamente.

Ventaja el modelo iterativo es que los ajustes entre etapas proporcionan un desarrollo menos intensivo en mano de obra en comparación con el modelo en cascada.

desventajas modelo iterativo:

· La vida útil de cada etapa se extiende a todo el período de trabajo;

· Debido a una gran cantidad de iteraciones, existen inconsistencias en la implementación de soluciones de diseño y documentación;

· La complejidad de la arquitectura;

· Las dificultades para utilizar la documentación de diseño en las etapas de implementación y operación requieren rediseñar todo el sistema.

III. Modelo espiral, a diferencia de la cascada, pero similar a la anterior, implica un proceso iterativo de desarrollo AIS. Al mismo tiempo, aumenta la importancia de las etapas iniciales, como el análisis y el diseño, en las que se comprueba y justifica la viabilidad de las soluciones técnicas mediante la creación de prototipos.

Cada iteración representa un ciclo de desarrollo completo que conduce al lanzamiento de una versión interna o externa de un producto (o un subconjunto del producto final), que se mejora de una iteración a otra para convertirse en un sistema completo (Figura 1.2).

Arroz. 1.2. Modelo en espiral del ciclo de vida AIS

Así, cada giro de la espiral corresponde a la creación de un fragmento o versión del producto de software, en él se especifican los objetivos y características del proyecto, se determina su calidad, se planifica el trabajo para el siguiente giro de la espiral. Cada iteración sirve para profundizar y concretar consistentemente los detalles del proyecto, como resultado de lo cual se selecciona una opción razonable para la implementación final.

El uso del modelo en espiral le permite pasar a la siguiente etapa del proyecto sin esperar a que se complete por completo el actual; el trabajo sin terminar se puede completar en la siguiente iteración. la tarea principal en cada iteración: cree un producto viable lo antes posible para demostrarlo a los usuarios. Por lo tanto, el proceso de realizar ajustes y adiciones al proyecto se simplifica enormemente.

El enfoque en espiral del desarrollo de software supera la mayoría de las deficiencias del modelo en cascada, además, proporciona una serie de capacidades adicionales, lo que hace que el proceso de desarrollo sea más flexible.

Ventajas enfoque iterativo:

El desarrollo iterativo simplifica enormemente la introducción de cambios en el proyecto cuando cambian los requisitos del cliente;

Cuando se utiliza el modelo en espiral, los elementos AIS individuales se integran gradualmente en un solo todo. Dado que la integración comienza con menos elementos, hay muchos menos problemas en su implementación;

Reducir el nivel de riesgos (consecuencia de la ventaja anterior, ya que los riesgos se detectan precisamente durante la integración). El nivel de riesgos es máximo al inicio del desarrollo del proyecto, a medida que avanza el desarrollo, disminuye;

El desarrollo iterativo proporciona una mayor flexibilidad en la gestión de proyectos al permitir que se realicen cambios tácticos en el producto que se está desarrollando. Por lo tanto, puede acortar el tiempo de desarrollo reduciendo la funcionalidad del sistema o utilizándolo como partes componentes productos de empresas de terceros en lugar de sus propios desarrollos (relevante en una economía de mercado, cuando es necesario resistir la promoción de productos de la competencia);

Un enfoque iterativo facilita la reutilización de componentes, ya que es mucho más fácil identificar (identificar) partes comunes del proyecto cuando ya están parcialmente desarrolladas que tratar de aislarlas al comienzo del proyecto. El análisis del proyecto después de varias iteraciones iniciales revela componentes reutilizables comunes que se mejorarán en iteraciones posteriores;

El modelo en espiral permite un sistema más confiable y estable. Esto se debe a que a medida que el sistema evoluciona, se descubren y corrigen errores y debilidades en cada iteración. Al mismo tiempo, se ajustan los parámetros de rendimiento críticos, que en el caso de un modelo en cascada está disponible solo antes de la implementación del sistema;

Un enfoque iterativo mejora el proceso
desarrollo: como resultado del análisis al final de cada iteración, se lleva a cabo una evaluación de los cambios en la organización de desarrollo; mejora en la siguiente iteración.

El principal problema del ciclo en espiral.- la dificultad de determinar el momento de la transición a la siguiente etapa. Para solucionarlo, es necesario introducir límites de tiempo para cada etapa del ciclo de vida. De lo contrario, el proceso de desarrollo puede convertirse en una mejora sin fin de lo que ya se ha hecho.

Involucrar a los usuarios en el proceso de diseño y copia de la aplicación le permite recibir comentarios y adiciones a los requisitos directamente en el proceso de diseño de la aplicación, reduciendo el tiempo de desarrollo. Los representantes del cliente pueden controlar el proceso de creación de un sistema e influir en su contenido funcional. El resultado es la puesta en servicio de un sistema que tiene en cuenta la mayoría de las necesidades de los clientes.

Las metodologías modernas y tecnologías de diseño AIS que las implementan se entregan a en formato electrónico junto con las herramientas CASE e incluyen bibliotecas de procesos, plantillas, métodos, modelos y otros componentes destinados a la construcción de software de la clase de sistemas a los que se centra la metodología. Las metodologías y tecnologías electrónicas forman el núcleo de un conjunto de instrumentos desarrollo de AIS. Las características de las soluciones metodológicas modernas para diseñar AIS no se pueden implementar sin ciertas tecnologías de diseño que se correspondan con la escala y las características específicas del proyecto.

Tecnología de diseño AIS es un conjunto de métodos y herramientas para diseñar AIS, así como métodos y herramientas para organizar el diseño (gestionar el proceso de creación y modernización de un proyecto AIS).

Según el diseño de TP, AIS es un conjunto de cadenas de acciones secuenciales-paralelas, conectadas y subordinadas, cada una de las cuales puede tener su propio sujeto. Las acciones que se realizan en el diseño de AIS pueden definirse como operaciones tecnológicas indivisibles o como subprocesos de operaciones tecnológicas. Todas las acciones pueden ser adecuadas diseño, que dan forma o modifican los resultados del diseño, y estimado, que se desarrollan de acuerdo con los criterios establecidos para evaluar los resultados del diseño.

Así, la tecnología de diseño está determinada por una secuencia regulada de operaciones tecnológicas realizadas en el proceso de creación de un proyecto basado en un método u otro.

El tema de la tecnología de diseño elegida debe ser el reflejo de procesos de diseño interrelacionados en todas las etapas del ciclo de vida del AIS.

Los principales requisitos para la tecnología de diseño elegida son los siguientes:

· El proyecto creado con la ayuda de esta tecnología debe cumplir con los requisitos del cliente;

· La tecnología debe reflejar tanto como sea posible todas las etapas del ciclo de vida del proyecto;

· La tecnología debe proporcionar costos mínimos de mano de obra y costos para el diseño y soporte del proyecto;

· La tecnología debe contribuir al crecimiento de la productividad de los diseñadores;

· La tecnología debe asegurar la confiabilidad del diseño y operación del proyecto;

· La tecnología debería facilitar el mantenimiento de la documentación del proyecto.

La tecnología de diseño AIS implementa una metodología de diseño específica. A su vez, la metodología de diseño asume la presencia de algún concepto, principios de diseño y se implementa mediante un conjunto de métodos y herramientas.

Los métodos de diseño AIS se pueden clasificar según el grado de uso de herramientas de automatización, soluciones de diseño típicas y adaptabilidad a los cambios anticipados.

Según el grado de automatización, se distinguen:

diseño manual, en el que el diseño de componentes AIS se lleva a cabo sin el uso de herramientas de software especiales; la programación se realiza en lenguajes algorítmicos;

Diseño de computadora, en el que la generación o configuración (tuning) de soluciones de diseño se lleva a cabo utilizando herramientas de software especiales.

Según el grado de uso de las soluciones de diseño típicas, se distinguen:

original (individual) diseño, cuando las soluciones de diseño se desarrollan "desde cero" de acuerdo con los requisitos de AIS;

diseño típico, asumiendo la configuración del AIS a partir de soluciones de diseño estándar listas para usar (módulos de software).

Diseño original AIS asume la máxima consideración de las características de una instalación automatizada.

Diseño típico realizado en base a soluciones listas para usar y es una generalización de la experiencia adquirida anteriormente en la creación de proyectos relacionados.

Por el grado de adaptabilidad de las soluciones de diseño. los siguientes métodos difieren:

reconstrucción- la adaptación de las soluciones de diseño se realiza procesando los componentes correspondientes (reprogramación de los módulos de software);

parametrización- las soluciones de diseño se ajustan de acuerdo con los parámetros especificados y variables;

reestructuración del modelo- el modelo del área temática cambia, lo que conduce a la reforma automática de las soluciones de diseño.

La combinación de varios signos de clasificación de métodos de diseño determina la naturaleza de la tecnología de diseño AIS utilizada. Hay dos clases principales de tecnología de diseño: canónico y industrial... La tecnología del diseño industrial se divide en dos subclases: automatizado(uso de tecnologías CASE) y típico Diseño (orientado paramétrico u orientado a modelos).

Cuadro 1.1.Características de las clases de tecnología de diseño.

Diseño AIS canónico se centra principalmente en el uso del modelo en cascada del ciclo de vida AIS.

Dependiendo de la complejidad del objeto de automatización y del conjunto de tareas que deben resolverse al crear un AIS específico, las etapas y etapas del trabajo pueden tener diferente intensidad de trabajo. Se permite combinar etapas sucesivas y excluir algunas de ellas en cualquier etapa del proyecto. También se permite comenzar el trabajo de la siguiente etapa antes del final de la anterior.

Las etapas y etapas de la creación de AIS, realizadas por las organizaciones participantes, están prescritas en los contratos y términos de referencia para la ejecución del trabajo.

Nivel 1. Formación de requisitos para AIS:

· Estudio de la instalación y justificación de la necesidad de crear AIS;

· Formación de requisitos de usuario para AIS;

· Elaboración de un informe sobre el trabajo realizado y un encargo táctico y técnico para su desarrollo.

Etapa 2. Desarrollo del concepto AIS:

· Estudio del objeto de automatización;

· Realización del trabajo de investigación necesario;

· Desarrollo de opciones para el concepto de AIS, satisfaciendo los requerimientos de los usuarios;

· Elaboración del informe y aprobación del concepto.

Etapa 3. Tarea técnica:

Desarrollo y aprobación de especificaciones técnicas para la creación de AIS.

Etapa 4. Diseño preliminar:

· Desarrollo de soluciones de diseño preliminar para el sistema y sus partes;

· Desarrollo de documentación esquemática para AIS y sus partes.

Etapa 5. Proyecto técnico:

· Desarrollo de soluciones de diseño para el sistema y sus partes;

· Desarrollo de documentación para AIS y sus partes;

· Desarrollo y ejecución de documentación para el suministro de componentes;

· Desarrollo de asignaciones de diseño en partes relacionadas del proyecto.

Etapa 6. Documentación de trabajo:

· Desarrollo de documentación de trabajo para AIS y sus partes;

· Desarrollo y adecuación de programas.

Etapa 7. Puesta en servicio:

· Preparación del objeto de automatización; la formación del personal;

· Conjunto completo de productos suministrados por AIS (software y hardware, complejos de software y hardware, productos de información);

· Trabajos de construcción e instalación; puesta en marcha de obras;

· Realización de pruebas preliminares;

· Realización de una operación de prueba;

· Realización de pruebas de aceptación.

Etapa 8. Escolta AIS:

· Realización del trabajo de acuerdo con las obligaciones de garantía;

· Servicio postgarantía.

Encuesta- es el estudio y análisis de la estructura organizativa de la empresa, sus actividades y el sistema existente procesamiento de información.

Los materiales obtenidos como resultado de la encuesta se utilizan para:

Justificación para el desarrollo e implementación gradual de sistemas;

Elaboración de especificaciones técnicas para el desarrollo de sistemas;

Desarrollo de proyectos técnicos y operativos de sistemas.

En la etapa de la encuesta, es aconsejable distinguir dos componentes: la definición de la estrategia de implementación del AIS y un análisis detallado de las actividades de la organización.

La tarea principal de la primera etapa de la encuesta es evaluar el volumen real del proyecto, sus metas y objetivos en función de las funciones identificadas y los elementos de información del objeto automatizado de alto nivel. Estas tareas pueden ser implementadas por el cliente de AIS de forma independiente o con la participación de organizaciones consultoras. Esta etapa implica una estrecha interacción con los principales usuarios potenciales del sistema y los expertos empresariales. La tarea principal de la interacción es obtener una comprensión completa e inequívoca de los requisitos del cliente. Normalmente, la información que necesita se puede obtener a través de entrevistas, conversaciones o talleres con la dirección, expertos y usuarios.

Una vez completada la etapa de la encuesta, es posible determinar los posibles enfoques técnicos para la creación del sistema y estimar los costos de su implementación (para el hardware, para el software comprado y para el desarrollo de nuevo software).

El resultado de la etapa de definición de la estrategia es un documento (estudio de factibilidad - estudio de factibilidad - proyecto), donde se formula claramente qué recibirá el cliente si acepta financiar el proyecto, cuándo recibe el producto terminado (cronograma de trabajo) y cómo Cuánto costará (para proyectos grandes, este es el cronograma de financiamiento en las diferentes etapas del trabajo). Es deseable reflejar en el documento no solo los costos, sino también los beneficios del proyecto, por ejemplo, el tiempo de recuperación del proyecto, esperado efecto economico(si se puede evaluar).

Limitaciones, riesgos, factores críticos que pueden afectar el éxito del proyecto;

El conjunto de condiciones bajo las cuales se supone que operará el sistema futuro: arquitectura del sistema, recursos de hardware y software, condiciones de operación, personal de servicio y usuarios del sistema;

Condiciones de finalización de las etapas individuales, la forma de aceptación / entrega del trabajo, los recursos involucrados, las medidas para proteger la información;

Descripción de las funciones realizadas por el sistema;

Oportunidades para el desarrollo y modernización del sistema;

Interfaces y distribución de funciones entre una persona y un sistema;

requisitos para los sistemas de gestión de software y bases de datos (DBMS).

En la etapa de un análisis detallado de las actividades de la organización, se estudian las actividades que aseguran la implementación de las funciones de gestión, estructura organizativa, personal y contenido del trabajo en la gestión empresarial, así como la naturaleza de la subordinación a los órganos superiores de dirección. Aquí es necesario delinear los materiales instructivo-metodológicos y directivos, sobre la base de los cuales se determinan la composición de los subsistemas y la lista de tareas, así como la posibilidad de utilizar nuevos métodos para resolver problemas.

Los analistas recopilan y registran información en dos formas interrelacionadas:

Funciones: información sobre eventos y procesos que ocurren en la organización automatizada;

Entidades: información sobre las clases de objetos que son relevantes para la organización y sobre qué datos se recopilan.

Al estudiar cada tarea de control funcional, se determina lo siguiente:

Nombre de la tarea; términos y frecuencia de su decisión;

El grado de formalización del problema;

Fuentes de información necesarias para resolver el problema;

Indicadores y sus características cuantitativas;

El procedimiento para corregir la información;

Algoritmos operativos para el cálculo de indicadores y posibles métodos de control;

Medios existentes de recopilación, transmisión y procesamiento de información;

Medios de comunicación existentes;

Exactitud aceptada de la solución del problema;

La complejidad de resolver el problema;

Formas existentes de presentación de datos iniciales y los resultados de su procesamiento en forma de documentos;

Consumidores de la información resultante sobre la tarea.

Una de las tareas de esta etapa que requieren más tiempo, aunque bien formalizadas, es la descripción del flujo de trabajo de la organización. Al examinar el flujo de trabajo, se elabora un diagrama de la ruta de movimiento de los documentos, que debe reflejar:

Número de documentos;

Lugar de formación de indicadores de documentos;

Interrelación de documentos durante su formación;

La ruta y duración del movimiento del documento;

Lugar de uso y almacenamiento de este documento;

Comunicaciones internas y externas;

El volumen del documento en signos.

A partir de los resultados de la encuesta se establece una lista de tareas de gestión a automatizar y la secuencia de su desarrollo.

Durante la fase de la encuesta, las funciones planificadas del sistema deben clasificarse de acuerdo con su importancia. Uno de los posibles formatos para presentar dicha clasificación es MuSCoW. Esta abreviatura significa: Debe tener - funciones requeridas; Debería tener - funciones deseadas; Podría tener - yo funciones posibles; No le faltarán funciones.

Las funciones de la primera categoría proporcionan críticas para I trabajo exitoso capacidades de los sistemas. La implementación de las funciones de la segunda y tercera categorías está limitada por el tiempo y el marco financiero: lo necesario, así como el máximo posible, en el orden de prioridad, el número de funciones de la segunda y tercera categorías. La última categoría de funciones es especialmente importante, ya que es necesario comprender claramente los límites del proyecto I y el conjunto de funciones que estarán ausentes en el sistema.

Los modelos de actividad organizativa se crean en dos tipos 1:

El modelo "tal cual" refleja los procesos comerciales existentes en la organización;

El modelo “to be” refleja los cambios necesarios en los procesos de negocio teniendo en cuenta la implementación de AIS. j

Ya en la etapa de análisis, es necesario involucrar al grupo de prueba en el trabajo para resolver las siguientes tareas:

Obtención de características comparativas de plataformas hardware, sistemas operativos, DBMS, etc.;

Desarrollo de un plan de trabajo para asegurar la confiabilidad del AIS y sus pruebas.

Involucrar a los evaluadores en las primeras etapas del desarrollo es una buena idea para cualquier proyecto. Cuanto más tarde se descubran errores en las soluciones de diseño, más costoso es corregirlos; el peor de los casos es su detección durante la fase de implementación. Por lo tanto, cuanto antes los equipos de prueba comiencen a identificar errores en el AIS, menor será el costo de trabajar en el sistema. El tiempo para probar el sistema y corregir los errores detectados debe proporcionarse no solo en la etapa de desarrollo, sino también en la etapa de diseño.

Los sistemas especiales de seguimiento de errores están diseñados para facilitar y aumentar la eficacia de las pruebas. Su uso le permite tener un único repositorio de errores, rastrear su recurrencia, controlar la velocidad y la eficiencia de la corrección de errores, ver los componentes del sistema más inestables y también mantener la comunicación entre el equipo de desarrollo y el equipo de pruebas.

Los resultados de la encuesta representan una base objetiva para la formación de especificaciones técnicas para el AIS.

Tarea técnica Es un documento que define los objetivos, requisitos y datos iniciales básicos necesarios para el desarrollo de un sistema de control automatizado.

Al desarrollar una asignación técnica (TOR), es necesario resolver las siguientes tareas:

· Establecer el propósito general de crear AIS;

· Establecer requisitos generales para el sistema diseñado;

· Desarrollar y fundamentar los requisitos de información, matemática, software, hardware y soporte tecnológico;

· Determinar la composición de subsistemas y tareas funcionales;

· Desarrollar y fundamentar los requisitos para subsistemas;

· Determinar las etapas de creación del sistema y el momento de su implementación;

Haga un cálculo preliminar de los costos de crear un sistema y determine el nivel eficiencia económica implementación;

· Determinar la composición de los artistas intérpretes o ejecutantes.

Los requisitos típicos para la composición y el contenido de las especificaciones técnicas se dan en la tabla. 1.6.

Tablitsa 1.6. La composición y el contenido de la tarea técnica (GOST 34.602-89)

Proyecto exclusivo prevé el desarrollo de soluciones de diseño preliminar para el sistema y sus partes. El diseño preliminar no es una etapa estrictamente obligatoria. Si las principales soluciones de diseño se definieron antes o son lo suficientemente obvias para un AIS específico y un objeto de automatización, entonces esta etapa puede excluirse de la secuencia general de trabajos.

Funciones AIS;

Funciones de los subsistemas, sus objetivos y el efecto esperado de la implementación;

Composición de conjuntos de tareas y tareas individuales;

Concepto de base de información y su estructura ampliada;

Funciones del sistema de gestión de bases de datos;

Composición de un sistema informático y otros medios técnicos;

Funciones y parámetros del software principal.

Sobre la base de los resultados del trabajo realizado, la documentación se elabora, acuerda y aprueba en la cantidad necesaria para describir el conjunto completo de decisiones de diseño adoptadas y suficiente para seguir trabajando en la creación del sistema.

De acuerdo con GOST 19.102-77, la etapa de diseño preliminar contiene dos etapas: desarrollo de un diseño preliminar; aprobación del anteproyecto.

La primera etapa de desarrollo consta de:

Desarrollo preliminar de la estructura de datos de entrada y salida;

Refinamiento de métodos para resolver el problema;

Desarrollo de una descripción general del algoritmo para la resolución del problema;

Desarrollo de un estudio de viabilidad;

Elaboración de una nota explicativa.

En este caso, se permite combinar y excluir algunas obras.

A continuación se muestra un conjunto de documentos que deben y pueden prepararse al final del diseño del boceto.

Documentos obligatorios:

1) términos de referencia actualizados para el diseño y desarrollo
trabajo de AIS;

2) especificación de los requisitos de calificación para AIS;

3) un conjunto de especificaciones de requisitos para componentes de software funcional y descripciones de datos;

4) especificación de los requisitos para las interfaces internas del componente y las interfaces con el entorno externo;

5) una descripción del sistema de gestión de la base de datos, estructura y distribución de software y objetos de información en la base de datos;

6) redactar directrices para la protección de la información y garantizar la fiabilidad del funcionamiento del AIS;

7) una versión preliminar del manual del administrador de AIS;

8) una versión preliminar del manual de usuario del AIS;

9) un plan revisado para la implementación del proyecto;

10) plan de gestión de garantía de calidad AIS perfeccionado;

11) nota explicativa del anteproyecto de AIS;

12) un contrato revisado (acuerdo) con el cliente para un detalle
nuevo diseño de AIS.

Documentos redactados por acuerdo con el cliente:

1) una descripción preliminar del funcionamiento del AIS;

2) un diagrama de flujos de datos entre los componentes funcionales del AIS;

3) un diagrama refinado de la arquitectura AIS, la interacción del software y los componentes de información, la organización del proceso de computación y la asignación de recursos;

4) una descripción de los indicadores de calidad de los componentes y los requisitos para ellos por etapas de desarrollo del AIS;

5) informar sobre indicadores técnicos y económicos, cronograma de ejecución del proyecto, asignación de recursos y presupuesto;

6) una tabla de distribución de especialistas por componentes y por etapas de trabajo;

7) certificados de desarrolladores para el derecho a utilizar tecnología y herramientas de automatización para el desarrollo de AIS;

8) una descripción de los requisitos para la composición y formas de los documentos resultantes por etapas de trabajo;

9) un plan para depurar componentes de software, proporcionándole métodos y herramientas de automatización de pruebas;

10) orientación preliminar para el diseño detallado
vaniya, programación y depuración de componentes AIS;

11) plan preliminar de venta e implementación;

12) una descripción de la estructura preliminar de la base de datos.

Proyecto tecnico Los sistemas son documentación técnica que contiene soluciones de diseño de todo el sistema, algoritmos para la resolución de problemas, así como una evaluación de la eficiencia económica de AIS. En esta etapa, se lleva a cabo un complejo de investigación y trabajo experimental para seleccionar las principales soluciones de diseño y calcular la eficiencia económica del sistema. Composición y contenido proyecto tecnico se dan en la tabla. 1,7

Cuadro 1.7. Contenido del proyecto técnico

En la etapa "Documentación de trabajo", se crea un producto de software y se desarrolla toda la documentación adjunta. La documentación debe contener toda la información necesaria y suficiente para asegurar el desempeño del trabajo en la puesta en servicio del AIS y su operación, así como para mantener el nivel de características operativas (calidad) del sistema. La documentación desarrollada debe estar debidamente redactada, consensuada y aprobada.

En la etapa de "Puesta en funcionamiento" del AIS, se establecen los siguientes tipos principales de pruebas: pruebas preliminares, prueba de funcionamiento y pruebas de aceptación. Si es necesario, se permite realizar adicionalmente otros tipos de pruebas del sistema y sus partes.

Dependiendo de la relación entre los componentes AIS y el objeto de automatización, las pruebas pueden ser autónomas y complejas. Los componentes del sistema están involucrados en pruebas autónomas. Se llevan a cabo tan pronto como las partes del sistema están listas para la puesta en servicio. Se realizan pruebas complejas para grupos de componentes interconectados (subsistemas) o para el sistema en su conjunto.

Para planificar la realización de todo tipo de pruebas, se está desarrollando el documento "Programa y Metodología de Pruebas". El desarrollador del documento se establece en el contrato o TK. Las pruebas o casos de prueba se pueden incluir en el documento como archivo adjunto.

La depuración es el proceso de diseño que consume más tiempo. Los errores ocultos a veces aparecen después de muchos años de funcionamiento del sistema. Es imposible evitar completamente los errores, lo que se debe a la astronómica cantidad de opciones para el funcionamiento del sistema. Es casi imposible verificar que todos funcionen correctamente en un futuro previsible.

El costo de identificar y eliminar errores en etapas posteriores de diseño aumenta aproximadamente exponencialmente (Figura 1.10).

Los investigadores cuentan 169 tipos de errores, resumidos en 19 grandes clases:

1) lógico;

2) errores de manipulación de datos;

3) errores de entrada-salida;

4) errores en los cálculos;

Arroz. 1.10. El costo relativo de detectar y corregir un solo error

5) errores en las interfaces de usuario;

6) errores en el sistema operativo y programas auxiliares;

7) errores de diseño;

8) errores en las interfaces de interprogramación;

9) errores en las interfaces "Programa - software del sistema";

10) errores al manipular dispositivos externos;

11) errores de interfaz con la base de datos (DB);

12) errores de inicialización de la base de datos;

13) errores de cambios a pedido desde el exterior;

14) errores relacionados con variables globales;

15) errores repetitivos;

16) errores en la documentación;

17) violación de los requisitos técnicos;

18) errores no reconocidos;

19) errores del operador.

No todos los errores provienen del desarrollador. Según diversos investigadores, del 6 al 19% de los errores se deben a errores en la documentación.

La relación entre el desarrollo y las pruebas en varias etapas del diseño AIS se muestra en la Fig. 1,11.

Esta cadena sólo se "estira" condicionalmente en una línea. Siempre hay bucles recurrentes en su interior. Para identificar errores, los desarrolladores crean pruebas especiales y realizan una etapa de depuración. Si no se encuentran errores, esto no significa que no haya ninguno; tal vez la prueba resultó ser demasiado débil.

Arroz. 1,11. Correlación entre desarrollo y prueba por etapas del diseño AIS

La técnica de depuración tiene en cuenta los síntomas de posibles errores:

Procesamiento incorrecto (respuesta incorrecta, resultado): hasta un 30%;

Transferencia de control incorrecta - 16%;

Incompatibilidad de los programas con los datos utilizados - 15%;

Incompatibilidad de programas para datos transmitidos: hasta un 9%.

Al desarrollar tareas de depuración, se resuelven las siguientes tareas:

Pruebas de escritura;

Selección de puntos, zonas y rutas de control;

Determinación de la lista de cantidades controladas y el procedimiento para fijar sus valores;

Establecer el orden de las pruebas;

Evaluación de la confiabilidad y complejidad de la depuración.

El programa que se está depurando debe trabajar al menos una vez a través de cada rama del algoritmo y al mismo tiempo asignar un número de valores a las variables, capturando los límites del rango, varios valores dentro de él, valores cero y puntos singulares (si los hay). Para sistemas especializados, se desarrollan lenguajes de depuración especiales. Pueden contener una cantidad relativamente pequeña de comandos (20-30) con parámetros de ajuste adicionales para resolver las siguientes tareas:

Control de abstinencia;

Modelar el proceso de ejecución del programa que se está depurando;

Emitir el estado de los componentes de la memoria durante la ejecución del programa;

Verificar las condiciones para alcanzar ciertos estados en el proceso de ejecución del programa;

Establecer valores de prueba de los datos iniciales;

Implementación de saltos condicionales en pruebas, dependiendo de los resultados de la ejecución de otras macros o varias pruebas;

Realización de operaciones de servicio para preparar el programa para la prueba.

El proceso de depuración no se puede clasificar como totalmente formalizado, por lo que existen recomendaciones empíricas para su realización, que se detallan a continuación.

1. Utilice un enfoque semántico y pensado previamente para la depuración, planifique el proceso de depuración y diseñe cuidadosamente conjuntos de datos de prueba a partir de las opciones más simples posibles, eliminando las fuentes de error más probables.

2. Recopile y analice información para agilizar el proceso de prueba:

Características y estadísticas de errores;

Sobre los detalles de los datos iniciales y la secuencia de variables cambiantes en el programa y su influencia mutua;

Sobre la estructura del algoritmo y las características de su implementación de software.

3. Busque solo un error a la vez.

Utilice los medios para registrar y mostrar información sobre errores, incluido el código de depuración especial del programa para imprimir valores de muestra de variables, mensajes sobre el final de secciones individuales del programa, seguimiento, condiciones lógicas, etc.

5. Estudie el resultado resultante con atención y compárelo con los resultados previos calculados.

6. Preste atención a los datos, analice cuidadosamente el funcionamiento del programa cuando use valores límite y cuando ingrese incorrectamente; controle los tipos de datos, rangos, tamaños de campo y precisión.

7. Utilizar análisis de flujo de datos y análisis de flujo de control para validar y establecer alcances de datos para diferentes rutas de ejecución del programa.

8. Utilice diferentes herramientas de depuración al mismo tiempo, sin detenerse en una posibilidad. Utilice herramientas automatizadas y depuración y pruebas manuales al mismo tiempo, verificando el rendimiento del código del programa, teniendo en cuenta los errores más probables.

9. Documente cualquier error encontrado y solucionado, sus diferencias, ubicación y tipo. Esta información será útil para prevenir errores futuros.

10. Mida la complejidad de los programas. En programas con alta complejidad, existe una alta probabilidad de errores de especificación y diseño, y con baja complejidad - errores de codificación y administrativos.

11. Incrementar la experiencia y práctica en la depuración de errores colocados artificialmente en programas. Después de un cierto período de depuración, el programador debe señalar los errores restantes que no encontró. Esta "siembra" se usa ampliamente para estimar el número de errores no detectados (si tanto los errores artificiales como los reales se detectan y corrigen uniformemente, entonces el porcentaje de errores introducidos introducidos y reales se puede usar para predecir cuántos de ellos quedan).

Se llevan a cabo pruebas preliminares para determinar la operatividad del sistema y resolver el problema de la posibilidad de su aceptación en la operación de prueba. Las pruebas preliminares deben llevarse a cabo después de que el desarrollador haya depurado y probado el software y hardware suministrados del sistema y haya presentado los documentos relevantes sobre su preparación para la prueba, así como después de familiarizar al personal AIS con la documentación operativa.

La operación de prueba del sistema se lleva a cabo para determinar los valores reales de las características cuantitativas y cualitativas del sistema y la preparación del personal para trabajar en las condiciones de su funcionamiento, así como para determinar la eficiencia real y ajustar , si es necesario, la documentación.

Se realizan pruebas de aceptación para determinar la conformidad del sistema con las especificaciones técnicas, evaluar la calidad de la operación de prueba y resolver el tema de la posibilidad de aceptar el sistema para operación permanente.

Enviar tu buen trabajo en la base de conocimientos es simple. Utilice el siguiente formulario

Los estudiantes, estudiantes de posgrado, jóvenes científicos que utilizan la base de conocimientos en sus estudios y trabajos le estarán muy agradecidos.

Publicado en http://www.allbest.ru/

Ministerio de Educación y Ciencia Federación Rusa

Presupuesto del Estado Federal institución educativa educación profesional superior

Universidad Estatal de Tecnología y Diseño de San Petersburgo

Trabajo del curso

Por disciplina: "Arquitectura de sistemas de información"

Sobre el tema: "Diseño de sistemas de información automatizados"

INTRODUCCIÓN

En la actualidad, la tecnología informática se está generalizando cada vez más tanto en la producción como en el flujo de trabajo de las empresas, y la lista de tareas que abarca es cada vez más amplia. El volumen y la complejidad de la información que se procesa crece constantemente; se requieren todos los nuevos tipos de presentación.

Estos son solo algunos de los beneficios de usar la informática para una organización:

* Posibilidad de control operativo sobre la exactitud de la información;

* Reducir el número de posibles errores al generar datos derivados;

* Capacidad para acceder rápidamente a cualquier dato;

* Capacidad para generar informes rápidamente;

* Ahorro de mano de obra y tiempo dedicado al procesamiento de la información.

Todas estas ventajas son actualmente apreciadas por muchas organizaciones, por lo que hoy existe un proceso de rápido desarrollo de sistemas de información automatizados y su implementación en el trabajo de diversas instituciones. En este sentido, el tema que he elegido es muy relevante en el momento actual.

La característica principal de la industria de los sistemas de automatización para diversas empresas e instituciones, caracterizada por una amplia gama de datos de entrada con varias rutas para procesar estos datos, es la concentración de complejidad en las etapas iniciales de análisis de requisitos y diseño de especificaciones del sistema con relativamente baja complejidad y laboriosidad de etapas posteriores. De hecho, aquí es donde tiene lugar la comprensión de lo que hará el sistema futuro y cómo funcionará para satisfacer las demandas que se le planteen. Es decir, la vaguedad e incompletitud de los requisitos del sistema, los problemas no resueltos y los errores cometidos en las etapas de análisis y diseño dan lugar a problemas difíciles, a menudo irresolubles, en las etapas posteriores y, en última instancia, conducen al fracaso de todo el trabajo en su conjunto. Una simple réplica, incluso de un muy buen sistema de gestión empresarial, nunca se adaptará completamente al cliente, ya que no puede tener en cuenta sus características específicas. Además, en este caso, surge el problema de elegir exactamente el sistema más adecuado para una empresa en particular. Y este problema se complica aún más por el hecho de que las palabras clave que caracterizan a varios sistemas de información son prácticamente las mismas:

* Entorno de información unificado de la empresa;

* Modo de tiempo real;

* Independencia de la legislación;

* Integración con otras aplicaciones (incluidos los sistemas que ya funcionan en la empresa);

* Implementación por fases, etc.

De hecho, el problema de la automatización compleja se ha vuelto relevante para todas las empresas. Y para realizar una automatización compleja, necesita conocimientos estructurados en esta área.

El propósito de este trabajo: Conocer el concepto de sistemas de información automatizados, considerar el proceso de diseño.

Para lograr el objetivo, es necesario resolver las siguientes tareas:

§ Formular definiciones de conceptos y términos básicos;

§ Considere las metas y objetivos del diseño;

§ Familiarizarse con las principales etapas del diseño;

§ Destacar las fases de desarrollo de los sistemas de información automatizados;

§ Considerar la composición y estructura del encargo técnico y proyecto técnico.

1. DEFINICIÓN DE CONCEPTOS SISTEMA DE INFORMACIÓN AUTOMATIZADO (AIS), SISTEMA DE INFORMACIÓN (SI), PROYECTO Y DISEÑO

Al estructurar procesos en el campo de la actividad humana, se utilizan diferentes métodos de aislamiento de componentes (subprocesos) y se obtienen diversos resultados, como investigación y desarrollo, análisis y síntesis, etc.

Es bastante aceptable considerar el diseño como un concepto generalizador para muchas tareas intelectuales que se resuelven en el proceso del pensamiento y se distinguen de diferentes formas.

La raíz de la palabra diseño enfatiza la conexión entre el proceso que tiene tal nombre y los principales resultados de este proceso, de la siguiente manera:

a) proyección: lo que se obtiene al analizar fenómenos complejos para obtener representaciones simplificadas, y

b) proyecto: lo que se obtiene al sintetizar representaciones complejas a partir de un conjunto de imágenes más simples.

Las dos razones anteriores sirvieron de fundamento para la actual elección de la palabra diseño como término que denota la esencia de la principal actividad que se lleva a cabo en la informática.

En el diseño de sistemas de información, los sistemas de información son los objetos del diseño, y esto es bastante natural para la informática (ya que los SI se consideran sus principales objetos).

Como saben, los sistemas de información son capaces de mostrar los fenómenos más diversos del universo y, por tanto, todos los fenómenos también resultan ser posibles objetos de diseño.

Los sistemas de información en muchos casos resultan ser sujetos de diseño, es decir, aquellos artistas intérpretes o ejecutantes que llevan a cabo el proceso de diseño en sí. Al estudiar el proceso de diseño, nos involucramos en gran medida en el estudio de los sistemas de información.

Se entiende por sistema cualquier objeto que se considere simultáneamente como un todo único y como un conjunto de elementos heterogéneos combinados en aras de la consecución de los objetivos marcados. Los sistemas difieren significativamente entre sí tanto en composición como en términos de sus principales objetivos.

En informática, el concepto de sistema está muy extendido y tiene muchos significados semánticos. La mayoría de las veces se utiliza en relación con un conjunto de hardware y software. La adición al concepto de sistema de información de palabras refleja el propósito de su creación y funcionamiento. Los sistemas de información proporcionan recopilación, almacenamiento, procesamiento, búsqueda y entrega de la información necesaria en el proceso de toma de decisiones sobre problemas de cualquier campo. Ayudan a analizar problemas y crear nuevos productos.

El sistema de información (SI) es un conjunto interconectado de herramientas, métodos y personal utilizado para almacenar, procesar y emitir información con el fin de lograr el objetivo establecido.

Las tecnologías de la información modernas proporcionan una amplia gama de métodos de implementación de IP, cuya elección se basa en los requisitos de los usuarios previstos, que, por regla general, cambian durante el proceso de desarrollo.

La adición del término "automatizado" al concepto de "sistema" refleja las formas de crear y funcionar tal sistema.

Sistema automático(según GOST) es un sistema que consta de un conjunto interconectado de unidades organizativas y un conjunto de herramientas de automatización de actividades que implementa funciones automatizadas para ciertos tipos ocupaciones.

Un sistema de información automatizado (AIS) es un complejo de software, medios técnicos, de información, lingüísticos, organizativos y tecnológicos y de personal, diseñado para resolver los problemas de los servicios de referencia e información y (o) soporte de información para los usuarios.

Un sistema de información automatizado es un conjunto de información, métodos y modelos económicos y matemáticos, herramientas técnicas, de software, tecnológicas y especialistas diseñados para procesar la información y tomar decisiones de gestión.

El objetivo principal de los sistemas de información automatizados no es solo recopilar y guardar recursos de información electrónica, sino también proporcionar a los usuarios acceso a ellos. Una de las características más importantes de AIS es la organización de la recuperación de datos en sus matrices de información (bases de datos).

Bajo el proyecto AIS nos referimos al diseño y documentación tecnológica, que proporciona una descripción de las soluciones de diseño para la creación y operación de SI en un entorno de software y hardware específico.

Se pueden distinguir las siguientes principales características diferenciadoras del proyecto como objeto de gestión:

· La limitación del objetivo final;

· Duración limitada;

· Presupuesto limitado;

· Se requieren recursos limitados;

· Novedad para la empresa para la que se está ejecutando el proyecto;

· Complejidad;

· Soporte legal y organizativo.

Teniendo en cuenta la planificación y gestión de proyectos, es necesario entender claramente que estamos hablando de la gestión de un determinado objeto dinámico. Por lo tanto, el sistema de gestión de proyectos debe ser lo suficientemente flexible para permitir la posibilidad de modificación sin cambios globales en programa de trabajo... La ejecución de las obras está asegurada por la disponibilidad de los recursos necesarios: materiales; equipo; recursos humanos. Desde el punto de vista de la teoría de los sistemas de control, el proyecto como objeto de control debe ser observable y manejable, es decir, se distinguen algunas características por las cuales se puede monitorear constantemente el avance del proyecto. Además, se necesitan mecanismos para influir en el progreso del proyecto de manera oportuna.

El diseño de AIS se entiende como el proceso de convertir información de entrada sobre un objeto, métodos y experiencia en el diseño de objetos de propósito similar de acuerdo con GOST en un proyecto de IS.

Desde este punto de vista, el diseño de AIS se reduce a la formalización secuencial de soluciones de diseño en varias etapas del ciclo de vida de AIS: planificación y análisis de requisitos, diseño técnico y detallado, implementación y operación de AIS.

La escala de los sistemas que se están desarrollando determina la composición y el número de participantes en el proceso de diseño. Con un gran volumen y plazos ajustados para la implementación del trabajo de diseño, varios equipos de diseño (organizaciones de desarrollo) pueden participar en el desarrollo del sistema. En este caso, se asigna la organización matriz, que coordina las actividades de todas las organizaciones coejecutoras.

La tecnología de diseño AIS es un conjunto de metodología y herramientas de diseño para AIS, así como métodos y medios de su organización (gestión del proceso de creación y modernización de un proyecto AIS).

La tecnología de diseño se basa en un proceso tecnológico que determina las acciones, su secuencia, la composición requerida de ejecutantes, medios y recursos.

El proceso tecnológico de diseño de AIS en su conjunto se divide en un conjunto de cadenas de acciones secuenciales-paralelas, conectadas y subordinadas, cada una de las cuales puede tener su propio tema. Por lo tanto, la tecnología de diseño se establece mediante una secuencia regulada de operaciones tecnológicas realizadas sobre la base de un método particular, como resultado de lo cual queda claro no solo qué se debe hacer para crear un proyecto, sino también cómo, por quién y en que secuencia.

El tema de cualquier tecnología de diseño elegida debe ser el reflejo de procesos de diseño interrelacionados en todas las etapas del ciclo de vida del AIS. Los principales requisitos para la tecnología de diseño seleccionada incluyen los siguientes:

· El proyecto creado debe cumplir con los requisitos del cliente;

· Máxima reflexión de todas las etapas del ciclo de vida del proyecto;

· Asegurar los costos mínimos de mano de obra y costos para el diseño y mantenimiento del proyecto;

· La tecnología debe ser la base para la comunicación entre el diseño y el apoyo al proyecto;

· Incremento de la productividad del diseñador;

· Fiabilidad del diseño y operación del proyecto;

· Mantenimiento sencillo de la documentación del proyecto.

La tecnología de diseño AIS se basa en la metodología que define la esencia, las principales características tecnológicas distintivas.

Una metodología de diseño asume la presencia de algún concepto, principios de diseño, implementados por un conjunto de métodos, los cuales, a su vez, deben ser apoyados por algún medio.

La organización del diseño implica la determinación de métodos de interacción entre diseñadores y con el cliente en el proceso de creación de un proyecto AIS, que también puede ser apoyado por un conjunto de herramientas específicas.

sistema de información de diseño asistido por computadora

2. FINALIDAD Y OBJETIVOS DEL DISEÑO

El diseño de sistemas de información siempre comienza con la definición del objetivo del proyecto. El propósito del diseño es la selección de soporte técnico y la formación de información, matemática, software y organizacional y legal.

La selección del soporte técnico debe ser tal que asegure la recopilación, el registro, la transferencia, el almacenamiento, el llenado y el procesamiento oportunos de la información.

El soporte de información debe permitir la creación y operación de un fondo de información único del sistema, representado por una variedad de matrices de información, un conjunto de datos o una base de datos.

La formación del soporte matemático de sistemas incluye un conjunto completo de métodos y algoritmos para resolver problemas funcionales. Al desarrollar sistemas de software, se presta especial atención a la creación de un conjunto de programas e instrucciones de usuario y a la elección de productos de software eficaces.

La tarea principal de cualquier proyecto exitoso es asegurar que en el momento del lanzamiento del sistema y durante todo su funcionamiento, sea posible asegurar:

· 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 la 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 determinante de la eficiencia del sistema. Una buena solución de diseño constituye la base de un sistema de alto rendimiento.

El diseño de sistemas de información automatizados cubre tres áreas principales:

· Diseño de objetos de datos que se implementarán en la base de datos;

· Diseño de programas, pantallas, informes que aseguren la ejecución de consultas a datos;

· Teniendo en cuenta un entorno o tecnología específicos, a saber: topología de red, configuración de hardware, arquitectura utilizada (archivo-servidor o cliente-servidor), procesamiento paralelo, procesamiento distribuido de datos, etc.

En condiciones reales, el diseño es la búsqueda de un método que cumpla con los requisitos de la funcionalidad del sistema mediante las tecnologías disponibles, teniendo en cuenta las limitaciones dadas.

Se imponen una serie de requisitos absolutos a cualquier proyecto, 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 es una tarea tan estructurada como analizar los requisitos de un proyecto o implementar una solución de diseño en particular.

3. ETAPAS DEL DISEÑO

El proceso de creación de AIS se divide en una serie de etapas (etapas), limitadas por un período de tiempo y terminando con el lanzamiento de un producto específico.

Cada proyecto, independientemente de la complejidad y volumen de trabajo requerido para su implementación, pasa por ciertos estados en su desarrollo. Desde el estado en el que “el proyecto aún no existe” hasta el estado en el que “el proyecto ya no existe”. El conjunto de etapas de desarrollo desde el surgimiento de una idea hasta la finalización completa del proyecto generalmente se divide en fases.

El propósito de las etapas iniciales de creación de AIS, que se llevan a cabo en la etapa de análisis de las actividades de la organización, es formular requisitos para AIS 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 AIS que satisfaga las necesidades de la organización, es necesario aclarar y articular claramente cuáles son estas necesidades. Para ello, es necesario determinar los requisitos de los clientes para AIS y mapearlos en el lenguaje de los modelos en los requisitos para el desarrollo del proyecto AIS a fin de garantizar el cumplimiento de las metas y objetivos de la organización.

Se pueden distinguir las siguientes fases de desarrollo de los sistemas de información automatizados:

3.1 Formación del concepto. Fase conceptual

Esto incluye:

· Formación de ideas;

· Formación de un equipo de proyecto clave;

· Estudio de las motivaciones y requerimientos del cliente y otros participantes;

· Recolección de datos iniciales y análisis del estado existente;

· Determinación de requisitos y restricciones básicos, recursos materiales, financieros y laborales requeridos;

· Evaluación comparativa de alternativas;

· Presentación de propuestas, su examen y aprobación.

La tarea de formar requisitos para AIS es una de las más responsables, difícil de formalizar y la más cara y difícil de corregir en caso de error. Las herramientas modernas y los productos de software le permiten crear rápidamente AIS de acuerdo con los requisitos preestablecidos. Pero a menudo estos sistemas no satisfacen a los clientes, requieren numerosas modificaciones, lo que conduce a un fuerte aumento en el costo del costo real de AIS. La principal razón de esta situación es la definición incorrecta, inexacta o incompleta de los requisitos para AIS en la etapa de análisis.

3.2 Elaboración de una propuesta técnica

§ desarrollo del contenido principal de la estructura básica del proyecto;

§ desarrollo y aprobación de especificaciones técnicas;

§ planificación, descomposición del modelo estructural básico del proyecto;

§ elaboración de presupuestos y presupuesto del proyecto;

§ desarrollo planes de calendario y horarios de trabajo ampliados;

§ firmar un contrato con un cliente;

§ poner en funcionamiento los medios de comunicación de los participantes del proyecto y los medios de seguimiento del avance de los trabajos.

3.3 Diseño

En la fase de diseño, se determinan los subsistemas, se seleccionan sus interrelaciones y las formas más efectivas de diseño y uso de recursos. Obras típicas de esta fase:

§ ejecución del trabajo de diseño básico;

§ desarrollo de especificaciones técnicas privadas;

§ implementación del diseño conceptual;

§ elaboración de especificaciones técnicas e instrucciones;

§ presentación del desarrollo, examen y aprobación del diseño.

En la etapa de diseño, primero se forman los modelos de datos. Los diseñadores reciben los resultados del análisis como entrada. La construcción de modelos de datos físicos y lógicos es una parte esencial del diseño de bases de datos. El modelo de información obtenido durante el análisis se transforma primero en un modelo de datos lógico y luego en uno físico.

3.4 Desarrollo

En la fase de desarrollo, se lleva a cabo la coordinación y el control operativo del trabajo del proyecto, se fabrican, combinan y prueban los subsistemas.

Una vez superada con éxito la prueba autónoma, el módulo se incluye en la parte desarrollada del sistema y un grupo de módulos generados se somete a pruebas de comunicación, que deben rastrear su influencia mutua.

Además, se prueba la confiabilidad de funcionamiento de un grupo de módulos, es decir, pasan, en primer lugar, pruebas para simular fallas del sistema y, en segundo lugar, pruebas de tiempo de funcionamiento 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 estimar 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 se somete a 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.

Última prueba automatizada sistema de informacion- 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.

3.5 Puesta en servicio del sistema

En la etapa de puesta en funcionamiento del sistema se realizan pruebas, se está probando el sistema en condiciones reales, se están negociando los resultados del proyecto y posibles nuevos contratos.

Principales tipos de trabajo:

§ pruebas complejas;

§ formación de personal para el funcionamiento del sistema que se está creando;

§ preparación de la documentación de trabajo, entrega del sistema al cliente y puesta en funcionamiento;

§ acompañamiento, apoyo, servicio;

§ evaluación de los resultados del proyecto y preparación de los documentos finales.

4. COMPOSICIÓN Y ESTRUCTURA DE LA TAREA TÉCNICA Y DISEÑO TÉCNICO

1. Disposiciones generales

1.1. Los términos de referencia (TOR) es el documento principal que define los requisitos y el procedimiento para la creación (desarrollo o modernización - posterior creación) del sistema de información, según el cual se lleva a cabo el desarrollo del SI y su aceptación en la puesta en servicio. .

1.2. TK está desarrollado para el sistema en su conjunto, diseñado para funcionar de forma independiente o como parte de otro sistema.

1.3. Los requisitos para SI en el volumen establecido por esta norma pueden incluirse en el encargo para el diseño de un objeto de informatización de nueva creación. En este caso, los conocimientos tradicionales no se desarrollan.

1.4. Los requisitos incluidos en los conocimientos tradicionales deben corresponder al nivel actual de desarrollo tecnologías de la información y no ceder a requisitos similares para las mejores contrapartes nacionales y extranjeras modernas. Los requisitos establecidos en los conocimientos tradicionales no deben restringir al desarrollador del sistema a encontrar e implementar las soluciones técnicas, técnicas, económicas y de otro tipo más efectivas.

1.5. Los conocimientos tradicionales incluyen solo aquellos requisitos que complementan los requisitos para sistemas de este tipo y están determinados por las características específicas de un objeto en particular para el que se está creando el sistema.

1.6. Los cambios en los conocimientos tradicionales se elaboran mediante una adición o un protocolo firmado por el cliente y el desarrollador. El suplemento o el protocolo especificado es una parte integral de los conocimientos tradicionales sobre IP. En la página de título del TK debería haber una entrada "Válido desde ...".

2. Composición y contenido

2.1. El TK contiene las siguientes secciones, que se pueden dividir en subsecciones:

1. Información General;

2) el propósito y los objetivos de la creación (desarrollo) del sistema;

3) características de los objetos;

4) requisitos del sistema;

5) la composición y contenido del trabajo sobre la creación del sistema;

6) el procedimiento de control y aceptación del sistema;

7) requisitos para la composición y contenido del trabajo sobre la preparación del objeto de desarrollo para poner en funcionamiento el sistema;

8) requisitos de documentación;

9) fuentes de desarrollo.

Los conocimientos tradicionales pueden incluir aplicaciones.

2.2. Dependiendo del tipo, propósito, características específicas del proyecto y las condiciones para el funcionamiento del sistema, se permite formalizar secciones de los CC.TT. en forma de solicitudes, introducir subsecciones adicionales, excluir o combinar subsecciones de los CC.TT.

Los CC.TT. de partes del sistema no incluyen secciones que dupliquen el contenido de las secciones de CC.TT. en su conjunto.

2.3. En el apartado "Información general" indicar:

1) el nombre completo del sistema y su símbolo;

2) el código del tema o el código (número) del contrato;

3) el nombre de las empresas del desarrollador y cliente (usuario) del sistema y sus datos;

4) una lista de documentos sobre la base de los cuales se crea el sistema, quién y cuándo se aprobaron estos documentos;

5) las fechas de inicio y finalización previstas para la creación del sistema;

6) información sobre las fuentes y el procedimiento para financiar la obra;

7) el procedimiento de registro y presentación al cliente de los resultados del trabajo sobre la creación del sistema (sus partes), sobre la fabricación y ajuste de los medios individuales (hardware, software, información) y software y hardware (software y metodológicos). ) sistemas del sistema.

2.4. La sección "Propósito y objetivos de la creación (desarrollo) del sistema" consta de subsecciones:

1) el propósito del sistema;

2) el propósito de crear el sistema.

2.4.1. En el apartado "Finalidad del sistema" indique el tipo de actividad del sistema (gestión, diseño, etc.) y la lista de objetos de informatización (objetos) sobre los que se supone que se utilizará.

2.4.2. En el inciso "Los objetivos de la creación de un sistema", se dan los nombres y valores requeridos de los indicadores técnicos, tecnológicos, productivos-económicos u otros del objeto de informatización, que deben lograrse como resultado de la creación de un SI. , y se indican los criterios para evaluar el logro de los objetivos de la creación de un sistema.

2.5. En el apartado "Características del objeto de informatización" dan:

1) breve información sobre el objeto de la informatización o enlaces a documentos que contengan dicha información;

2) información sobre las condiciones de funcionamiento del objeto de automatización.

2.6. La sección Requisitos del sistema consta de las siguientes subsecciones:

1) requisitos para el sistema en su conjunto;

2) requisitos para las funciones (tareas) realizadas por el sistema;

3) requisitos para los tipos de seguridad.

La composición de los requisitos del sistema, incluidos en esta sección de los CC.TT. para SI, se establece en función del tipo, finalidad, características específicas y condiciones para el funcionamiento de un sistema en particular.

2.6.1. En la subsección "Requisitos para el sistema en su conjunto" indique:

requisitos para la estructura y funcionamiento del sistema;

requisitos para el número y calificaciones del personal del sistema y el modo de su trabajo;

indicadores de destino;

requisitos de confiabilidad;

requerimientos de seguridad;

requisitos de ergonomía y estética técnica;

requisitos para la operación, mantenimiento, reparación y almacenamiento de componentes del sistema;

requisitos para la protección de la información contra el acceso no autorizado;

requisitos para la seguridad de la información en caso de accidentes;

requisitos de protección contra la influencia de influencias externas;

requisitos de pureza de la patente;

requisitos de normalización y unificación;

Requerimientos adicionales.

2.6.1.1. Los requisitos para la estructura y el funcionamiento del sistema incluyen:

1) una lista de subsistemas, su propósito y características básicas, requisitos para el número de niveles de jerarquía y el grado de centralización del sistema;

2) requisitos de métodos y medios de comunicación para el intercambio de información entre los componentes del sistema;

3) requisitos para las características de las interconexiones del sistema que se está creando con sistemas adyacentes, requisitos para su compatibilidad, incluidas instrucciones sobre cómo intercambiar información (automáticamente, mediante el envío de documentos, por teléfono, etc.);

4) requisitos para los modos de funcionamiento del sistema;

5) requisitos para diagnosticar el sistema;

6) perspectivas de desarrollo, modernización del sistema.

2.6.1.2. Los requisitos para el número y las calificaciones del personal de SI incluyen:

§ requisitos para el número de personal (usuarios) de SI;

§ requisitos para la calificación del personal, el procedimiento para su formación y control de conocimientos y habilidades;

§ el modo de operación requerido del personal de SI.

2.6.1.3. En los requisitos para los indicadores de propósito del SI se dan los valores de los parámetros que caracterizan el grado de cumplimiento del sistema con su propósito.

2.6.1.4. Los requisitos de confiabilidad incluyen:

1) la composición y los valores cuantitativos de los indicadores de confiabilidad para el sistema en su conjunto o sus subsistemas;

2) una lista de situaciones de emergencia para las que se deben regular los requisitos de confiabilidad y los valores de los indicadores correspondientes;

3) requisitos para la confiabilidad del hardware y software;

4) requisitos para los métodos de evaluación y seguimiento de los indicadores de confiabilidad en las diferentes etapas de la creación del sistema de acuerdo con los documentos reglamentarios y técnicos vigentes.

2.6.1.5. Los requisitos de seguridad incluyen requisitos para garantizar la seguridad durante la entrega, puesta en servicio, operación y mantenimiento del sistema.

2.6.1.6. Los requisitos de ergonomía y estética técnica incluyen indicadores de IP que establecen la calidad requerida de interacción hombre-máquina y la comodidad de las condiciones de trabajo del personal.

2.6.1.7. Los requisitos para proteger la información del acceso no autorizado incluyen los requisitos establecidos por la industria y el entorno de información del cliente.

2.6.1.8. En los requisitos para la seguridad de la información se da una lista de eventos: accidentes, fallas de los medios técnicos (incluida la pérdida de energía), etc., en los que se debe garantizar la seguridad de la información en el sistema.

2.6.1.9. Los requisitos para la pureza de la patente indican una lista de países respecto de los cuales debe garantizarse la pureza de la patente del sistema y sus partes.

2.6.1.10. Los requisitos adicionales incluyen requisitos especiales a discreción del desarrollador o cliente del sistema.

2.6.2. En la subsección "Requisitos para las funciones (tareas)" realizadas por el sistema, se da lo siguiente:

§ para cada subsistema, una lista de funciones, tareas o sus complejos (incluidos los que garantizan la interacción de las partes del sistema) a automatizar;

§ al crear un sistema en dos o más colas: una lista de subsistemas funcionales, funciones individuales o tareas que se ponen en funcionamiento en la primera fase y las siguientes;

§ cronograma de tiempo para la implementación de cada función, tarea (o conjunto de tareas);

§ requisitos para la calidad de implementación de cada función (tarea o complejo de tareas), para la forma de presentación de la información de salida, características de la precisión requerida y tiempo de ejecución, requisitos para el desempeño simultáneo de un grupo de funciones, la confiabilidad de Los resultados;

§ una lista y criterios de fallas para cada función para la que se establecen requisitos de confiabilidad.

2.6.3. En la subsección "Requisitos para los tipos de soporte", según el tipo de sistema, se dan los requisitos de soporte matemático, informativo, lingüístico, de software, técnico, metrológico, organizativo, metodológico y de otro tipo.

2.6.3.2. Para soporte de información del sistema, se dan los siguientes requisitos:

1) a la composición, estructura y métodos de organización de datos en el sistema;

2) al intercambio de información entre los componentes del sistema;

3) compatibilidad de la información con los sistemas relacionados;

4) sobre la aplicación de sistemas de gestión de bases de datos;

5) a la estructura del proceso de recopilación, procesamiento, transferencia de datos en el sistema y presentación de datos;

6) a la protección de datos;

7) control, almacenamiento, actualización y recuperación de datos;

2.6.3.3. Para el soporte lingüístico del sistema, se dan requisitos para el uso de lenguajes de programación de alto nivel en el sistema, lenguajes para la interacción entre usuarios y medios técnicos del sistema, así como requisitos para codificar y decodificar datos, para lenguajes de entrada-salida de datos, lenguajes de manipulación de datos, medios para describir el área temática, métodos para organizar un diálogo.

2.6.3.4. Para el software del sistema, se proporciona una lista del software comprado, así como los requisitos:

1) a la dependencia del software del entorno operativo;

2) a la calidad del software, así como a los métodos de su suministro y control;

2.6.3.5. Para el soporte técnico del sistema, se dan los siguientes requisitos:

1) a los tipos de medios técnicos, incluidos los tipos de complejos de medios técnicos, complejos de software y hardware y otros componentes admisibles para su uso en el sistema;

2) a las características funcionales, de diseño y operativas del soporte técnico del sistema.

2.6.3.6. Los requisitos para el apoyo metrológico incluyen:

1) una lista preliminar de canales de medición;

2) requisitos para la precisión de las mediciones de parámetros y (o) para las características metrológicas de los canales de medición;

3) requisitos de compatibilidad metrológica de los medios técnicos del sistema;

4) una lista de los canales de control y computación del sistema para los cuales es necesario evaluar las características de precisión;

5) requisitos para el soporte metrológico de hardware y software que forman parte de los canales de medición del sistema, medios, control incorporado, idoneidad metrológica de los canales de medición e instrumentos de medición utilizados en la configuración y prueba del sistema;

6) el tipo de certificación metrológica (estatal o departamental) con indicación del procedimiento para su implementación y las organizaciones que realizan la certificación.

2.6.3.7. Para el apoyo organizativo, se dan los requisitos:

1) a la estructura y funciones de las divisiones que participan en el funcionamiento del sistema o que proporcionan la operación;

2) a la organización del funcionamiento del sistema y el orden de interacción entre el personal de SI y el personal del objeto de informatización;

3) para proteger contra acciones erróneas del personal del sistema.

2.7. La sección "Composición y contenido del trabajo sobre la creación (desarrollo) del sistema" debe contener una lista de etapas y etapas del trabajo sobre la creación del sistema, el momento de su implementación, una lista de organizaciones - ejecutores del trabajo , enlaces a documentos que confirmen el consentimiento de estas organizaciones para participar en la creación del sistema, o un registro que identifique al responsable (cliente o desarrollador) de la realización de estos trabajos.

Esta sección también proporciona:

1) una lista de documentos presentados al final de las etapas y etapas de trabajo relevantes;

2) el tipo y procedimiento para el examen de la documentación técnica (etapa, etapa, volumen de documentación verificada, organización experta);

3) un programa de trabajo destinado a asegurar el nivel requerido de confiabilidad del sistema que se está desarrollando (si es necesario);

4) una lista de trabajos de soporte metrológico en todas las etapas de creación del sistema, indicando sus plazos y organizaciones ejecutoras (si es necesario).

2.8. En el apartado "Procedimiento de control y aceptación del sistema" indicar:

1) tipos, composición, alcance y métodos de prueba del sistema y sus componentes;

2) requisitos generales para la aceptación del trabajo por etapas, el procedimiento de coordinación y aprobación de la documentación de aceptación;

2.9. En la sección "Requisitos para la composición y contenido del trabajo sobre la preparación del objeto de automatización para la puesta en servicio del sistema", es necesario proporcionar una lista de las actividades principales y sus ejecutantes, que deben realizarse al preparar el proyecto. para la puesta en servicio del IS.

La lista de actividades principales incluye:

1) traer la información que ingresa al sistema (de acuerdo con los requisitos de información y apoyo lingüístico);

2) creación de condiciones para el funcionamiento del proyecto, bajo las cuales se garantice el cumplimiento del sistema creado con los requisitos contenidos en los TDR;

3) creación de subdivisiones y servicios necesarios para el funcionamiento del sistema;

4) el calendario y el procedimiento para la dotación de personal y la formación del personal.

2.10. En la sección "Requisitos para la documentación", se proporciona lo siguiente:

1) una lista de conjuntos y tipos de documentos a desarrollar, acordados por el desarrollador y el Cliente del sistema;

2) una lista de documentos emitidos en soportes de máquina;

3) en ausencia de estándares estatales que determinen los requisitos para documentar los elementos del sistema, incluir adicionalmente requisitos para la composición y contenido de dichos documentos.

2.11. La sección "Fuentes de desarrollo" debería enumerar los documentos y materiales de información sobre cuya base se desarrollaron los conocimientos tradicionales y que deberían utilizarse al crear el sistema.

3. Reglas de diseño.

3.1. Las secciones y subsecciones de los conocimientos tradicionales deben colocarse en el orden establecido en la sección. 2 de esta norma.

3.2. Los números de hojas (páginas) se anotan, comenzando por la primera hoja que sigue a la página del título, en la parte superior de la hoja (encima del texto, en el medio) después de la designación del código TK en la PI.

3.3. La portada contiene las firmas del cliente, desarrollador y empresas aprobantes, que están selladas. Si es necesario, la página de título se elabora en varias páginas. Las firmas de los desarrolladores de CC.TT. y de los funcionarios que participan en la aprobación y consideración del borrador de CC.TT. en el IP se colocan en la última hoja.

La forma de la página de título de los CC.TT. se da en el Apéndice 2. La forma de la última página de los CC.TT. se da en el Apéndice 3.

3.4. La portada del suplemento de los conocimientos tradicionales se redacta de la misma manera que la portada del trabajo técnico. En lugar del nombre "Términos de referencia", escriben "Suplemento No. ... a los TDR para AC ...".

3.5. En las hojas posteriores de la adición a los conocimientos tradicionales, se colocan la base del cambio, el contenido del cambio y los enlaces a los documentos, de acuerdo con los cuales se realizan estos cambios.

3.6. Al presentar el texto del suplemento de los CC.TT., deben indicarse los números de las cláusulas, subcláusulas, tablas de los CC.TT. principales, etc. pertinentes y las palabras “reemplazar”, “complementar”, “excluir”, “reformular”. " debería ser usado.

El procedimiento para el desarrollo, coordinación y aprobación de TK para SI.

1. El borrador de TK es desarrollado por la organización desarrolladora del sistema con la participación del cliente sobre la base de requisitos técnicos (aplicaciones, especificaciones tácticas y técnicas, etc.).

En la organización competitiva del trabajo, las opciones para el borrador de TK son consideradas por el cliente, quien elige la opción preferida, o sobre la base de un análisis comparativo prepara, con la participación del futuro desarrollador de SI, la versión final del TK para AC.

2. La necesidad de aprobación del borrador de CC.TT. con las autoridades estatales de supervisión y otras organizaciones interesadas la determinan conjuntamente el cliente del sistema y el desarrollador del borrador de CC.TT. en el SI.

El trabajo de aprobación del borrador de CC.TT. para el SI se lleva a cabo conjuntamente por el desarrollador de los CC.TT. y el cliente del sistema, cada uno en las organizaciones de su ministerio (departamento).

3. El plazo de aprobación del proyecto de CC.TT. en cada organización no debería exceder los 15 días a partir de la fecha de su recepción. Se recomienda enviar copias del borrador de los conocimientos tradicionales (copias) simultáneamente a todas las organizaciones (departamentos) para su aprobación.

4. Los comentarios sobre el borrador de los términos de referencia deben presentarse con una justificación técnica. Las decisiones sobre los comentarios deben ser tomadas por el desarrollador del borrador de TK y el cliente del sistema antes de la aprobación del TK en el SI.

5. Si, al llegar a un acuerdo sobre el borrador de CC.TT., surgen desacuerdos entre el desarrollador y el cliente (u otras organizaciones interesadas), entonces se elabora un protocolo de desacuerdos (de forma arbitraria) y se toma una decisión específica en orden establecido.

6. Se permite la aprobación del proyecto de CC.TT. para redactar un documento separado (carta). En este caso, bajo el título "Aceptado", haga una referencia a este documento.

7. La aprobación de los CC.TT. la llevan a cabo los jefes de las empresas del desarrollador y cliente del sistema.

8. El desarrollador de los conocimientos tradicionales envía copias de los conocimientos tradicionales aprobados dentro de los 10 días posteriores a la aprobación a los participantes en la creación del sistema.

9. La coordinación y aprobación de las adiciones a los CC.TT. se llevan a cabo de la manera prescrita para los CC.TT. en el SI.

10. No se permite la aprobación de cambios en los conocimientos tradicionales después de la presentación del sistema o su cola para las pruebas de aceptación.

La base para el desarrollo del proyecto técnico del sistema es el encargo técnico aprobado por el cliente.

El diseño técnico del sistema es la documentación técnica aprobada de la manera prescrita, que contiene soluciones de diseño de todo el sistema, un algoritmo para resolver problemas, así como una evaluación de la eficiencia económica de un sistema de control automatizado y una lista de medidas para preparar. la facilidad para la implementación.

El proyecto técnico se está desarrollando con el fin de determinar las principales soluciones de diseño para la creación del sistema. En esta etapa, se lleva a cabo un complejo de investigación y trabajo experimental para seleccionar mejores opciones soluciones, se realiza una verificación experimental de las principales soluciones de diseño y el cálculo de la eficiencia económica del sistema.

De hecho, el proyecto técnico contiene un complejo de modelos económicos, matemáticos y algorítmicos.

Un conjunto completo de diseño técnico para el sistema incluye 10 documentos:

1. Nota explicativa.

2. Estructura funcional y organizativa del sistema.

3. Enunciado del problema y algoritmo de solución.

4. Organización de la base de información.

5. Álbum de formularios de documentos.

6. Sistema de software.

7. El principio de construir un complejo de medios técnicos.

8. Cálculo de la eficiencia económica del sistema.

9. Medidas de preparación de la instalación para la implementación del sistema.

10. Lista de documentos.

De la lista anterior, se realiza el documento 3 "Enunciado de tareas y el algoritmo de resolución" para cada tarea individual incluida en el EIS, el resto de los documentos son comunes para todo el sistema. Además, los documentos 1, 2, 5, 8 y 9 se pueden desarrollar para subsistemas individuales.

Todos los documentos enumerados se pueden agrupar y presentar en forma de cuatro partes principales de un proyecto técnico: económico-organizativo, informativo, matemático, técnico.

La parte económica y organizativa del proyecto técnico contiene una nota explicativa que justifica el desarrollo del sistema, una lista de organizaciones de desarrolladores, una breve descripción del objeto indicando los principales indicadores técnicos y económicos de su funcionamiento y conexiones con otros objetos, breve información sobre las principales soluciones de diseño para las partes funcionales y de soporte del sistema.

En la sección del proyecto técnico dedicada a la estructura organizativa y funcional del sistema, se da lo siguiente: la justificación de los subsistemas asignados, su lista y propósito; una lista de tareas a resolver en cada subsistema, con una breve descripción de su contenido; un diagrama de enlaces de información entre subsistemas y entre tareas dentro de cada subsistema.

Para cada tarea incluida en el conjunto de tareas prioritarias se realiza su enunciado y el algoritmo para resolverlo. Esta sección del diseño técnico incluye:

§ la esencia organizativa y económica del problema (nombre, propósito de la solución, resumen, método, frecuencia y tiempo de resolución del problema, métodos de recopilación y transferencia de datos, vinculación del problema con otros problemas, naturaleza del uso de los resultados de la solución en la que se utilizan);

§ modelo económico y matemático del problema (forma de presentación estructural y detallada);

§ introducir información operativa (características de los indicadores, su importancia y rango de cambio, formas de presentación);

§ información de referencia normativa (NSI): contenido y formas de presentación;

§ información almacenada para la comunicación con otras tareas;

§ información acumulada para subsiguientes soluciones de este problema;

§ información sobre la realización de cambios (sistema para realizar cambios y una lista de información sujeta a cambios);

§ algoritmo para la resolución del problema (secuencia de etapas de cálculo, diagrama, fórmulas de cálculo);

§ caso de prueba (un conjunto de formularios de documentos de entrada llenos de datos, documentos condicionales con información acumulada y almacenada, formularios de documentos de salida completados en función de los resultados de la resolución de un problema económico y técnico y de acuerdo con el algoritmo de cálculo desarrollado).

El documento "Cálculo de la eficiencia económica del sistema" contiene una estimación resumida de los costos asociados con la operación de los sistemas, el cálculo de la eficiencia económica anual, cuyas fuentes son la optimización de la estructura de producción de la economía ( asociación), las decisiones de gestión.

El documento "Medidas para preparar la instalación para la implementación del sistema" contiene una lista de medidas organizativas para mejorar la estructura de gestión existente, una lista de trabajos sobre la implementación del sistema que deben realizarse en la etapa de diseño detallado, indicando el tiempo y las personas responsables.

La parte informativa del proyecto técnico une los documentos 4 y 5. El documento "Organización de la base de información" refleja: fuentes de información y métodos de su transmisión para resolver el complejo primario de tareas funcionales; un conjunto de indicadores utilizados en el sistema; composición de los documentos, plazos y frecuencia de su recepción; soluciones de diseño básico para la organización del fondo NSI; composición del INE, incluida la lista de detalles, su definición, importancia, rango de cambio y la lista de documentos del INE; lista de conjuntos de datos de datos de referencia, su volumen, orden y frecuencia de corrección de la información; propuestas para la unificación de la documentación, un caso de prueba para enmendar el INE; forma estructural de NSI con una descripción de la relación entre los elementos; requisitos para la tecnología de creación y mantenimiento de un fondo; métodos de almacenamiento, búsqueda, modificación y control, determinación de volúmenes y flujos de información de datos de referencia.

"Álbum de formularios de documentos" contiene formularios de datos de referencia.

La parte matemática del proyecto técnico contiene el fundamento de la estructura del software, el fundamento de la elección de un sistema de programación, incluida una lista de programas estándar.

La parte técnica del proyecto técnico incluye: descripción y justificación del diagrama del proceso de procesamiento de datos técnicos; justificación de los requisitos para el desarrollo de equipos no estándar; fundamentación y elección de la estructura del complejo de medios técnicos y sus grupos funcionales; un conjunto de medidas para garantizar la fiabilidad del funcionamiento de los medios técnicos.

CONCLUSIÓN

El desarrollo de un sistema de información, por regla general, se lleva a cabo durante bastante tiempo. una empresa específica... Los detalles de la actividad temática de la empresa, por supuesto, afectan la estructura del sistema de información, pero al mismo tiempo, las estructuras de las diferentes empresas son generalmente similares entre sí. Cada organización, independientemente de su tipo de actividad, consta de una serie de divisiones que realizan directamente uno u otro tipo de actividad empresarial, y esta situación es válida para casi todas las organizaciones, independientemente del tipo de actividad que desarrollen.

La introducción de tecnologías de la información modernas permite reducir el tiempo requerido para la preparación de proyectos específicos de comercialización y producción, reducir costos no productivos durante su implementación, eliminar la posibilidad de errores en la preparación de documentación contable, tecnológica y de otro tipo. , lo que le da a una empresa comercial un efecto económico directo.

Eso sí, para poder desvelar todas las posibilidades potenciales que conlleva el uso de ordenadores, es necesario utilizar en su trabajo un conjunto de herramientas software y hardware que mejor se adapte a las tareas planteadas. Por tanto, en la actualidad, existe una gran necesidad de empresas comerciales en programas de computador que apoyan la labor de gestión de la empresa, así como información sobre cómo aprovechar al máximo los equipos informáticos de la empresa.

La implementación del diseño AIS implica el uso de una determinada tecnología de diseño por parte de los diseñadores, correspondiente a la escala y características del proyecto que se está desarrollando.

LISTA DE LITERATURA UTILIZADA

1. Lineamientos para el estudio de la disciplina "Sistemas automatizados de información" [ Recurso electrónico]. - Moscú, 2006. - Modo de acceso:

http://www.e-biblio.ru/book/bib/01_informatika/sg.html - Título. desde la pantalla.

2. Wikipedia, la enciclopedia libre [Recurso electrónico] / Artículo "Sistema de información" - Modo de acceso: http://ru.wikipedia.org/wiki/Sistema de información.

3. Prensa informática: revista de Internet. - Electrón. Dan. - [B.m., 2001]. - Modo de acceso: http://compress.ru/article.aspx?id=12282.

4. Vendrov AM, "Diseño de software para sistemas de información económica" / А.М. Vendra. - M.: "Finanzas y estadísticas", 2000. - 364 p.

5. "Términos de referencia para la creación de un sistema automatizado" / - M.: GOST 34.602-89, 1990.

6. Grekul V.I. "Diseño de sistemas de información" / V.I. Grekul, G.N. Denischenko, N.L. Korovkin. - M.: Universidad de Tecnologías de la Información de Internet, 2008.

Publicado en Allbest.ru

Documentos similares

Desarrollo de sistemas de información. Mercado moderno software de aplicación financiera y económica. Ventajas y desventajas de implementar sistemas de información automatizados. Métodos para diseñar sistemas de información automatizados.

tesis, agregada 22/11/2015


Tipos de soporte de sistemas de información automatizados. Elaboración de especificaciones técnicas, desarrollo de un sistema de información, elaboración de un manual de usuario del programa. Herramientas de programación para sistemas de procesamiento de información distribuidos.

informe de práctica, agregado 16/04/2017


Ciclo de vida de los sistemas de información automatizados. Fundamentos de metodología para el diseño de sistemas automatizados basados ​​en tecnologías CASE. La fase de análisis y planificación, construcción e implementación de un sistema automatizado. Modelo de cascada y espiral.

trabajo de término agregado el 20/11/2010


El concepto de sistema de información, tipos de sistemas de información. Análisis de herramientas para el desarrollo de sistemas de información automatizados. Requisitos para el programa y producto de software. Desarrollo de formas de interfaz gráfica y bases de datos.

tesis, agregada el 23/06/2015


Los principios de organización de un sistema compuesto por personal y un conjunto de herramientas para automatizar sus actividades. Diseño de sistemas de información automatizados corporativos. Estructura, flujos de entrada y salida, limitaciones de los sistemas automatizados.

presentación agregada el 14/10/2013


Concepto de sistema de información. Etapas de desarrollo de los sistemas de información. Procesos en el sistema de información. Sistema de información para encontrar nichos de mercado, para reducir costos de producción. La estructura del sistema de información. Apoyo técnico.

resumen, agregado 17/11/2011


Organización, arquitectura y estructura del sistema de información. Indicadores de la efectividad de su trabajo. Metas y objetivos del análisis de ACS. Componentes de sistemas automatizados. Descripción del área temática, datos de entrada y salida. Construyendo un diagrama de casos de uso.

trabajo final agregado 11/04/2014


Creación y organización de sistemas de información automatizados (AIS). Principales componentes y procesos tecnológicos de AIS. Etapas y etapas de la creación de AIS desde el cargo de dirección de la organización. Desarrollo de complejos de soluciones de diseño para un sistema automatizado.

resumen agregado el 18/10/2012


Los principales factores que influyen en la historia del desarrollo de los sistemas de información automatizados corporativos. Su características generales y clasificación. Composición y estructura del AIS integrado. Los sistemas ERP como un tipo moderno de sistema de información empresarial.

presentación agregada el 14/10/2013


Análisis del área temática, etapas del diseño de sistemas de información automatizados. Sistemas de herramientas de desarrollo de software. El papel de las herramientas CASE en el diseño del modelo de información. El modelo lógico de la base de datos diseñada.

El 1 de diciembre de 2015 se llevó a cabo una defensa abierta del Sistema Automatizado de Información de Gestión de Proyectos (AIS PU) creado por orden del Ministerio de Industria y Comercio de Rusia. La defensa, presidida por el Primer Viceministro de Industria y Comercio de la Federación de Rusia, Gleb Nikitin, contó con la presencia de jefes de departamento del Ministerio, representantes del Ministerio. desarrollo economico y el Ministerio de Defensa de la Federación de Rusia.

El sistema automatizado de gestión de proyectos está diseñado para incrementar la eficiencia del Ministerio de Industria y Comercio de Rusia en términos de soporte, mantenimiento e implementación de proyectos dirigidos, entre otras cosas, a la sustitución de importaciones, aumento de exportaciones, desarrollo tecnológico de producción, creación y modernización de puestos de trabajo de alto rendimiento y desarrollo de infraestructura industrial (parques industriales, parques tecnológicos, centros de diseño e ingeniería industrial).

Los principales usuarios del sistema creado, junto con los líderes y empleados del ministerio, son responsables de la implementación de los programas estatales y federales. programas dirigidos, se convertirán en empresas industriales que implementen sus propios proyectos de inversión, organismos federales Poder ejecutivo que brinda apoyo estatal a empresas, bancos, inversionistas institucionales y otras instituciones financieras involucradas en la financiación de proyectos de inversión. empresas industriales y proyectos de desarrollo de infraestructura industrial.

El sistema fue creado por el integrador de sistemas ruso "Inline-Technologies" con la participación del desarrollador de software nacional "LM-Soft". AIS PU se desarrolló sobre la base de la plataforma rusa 1C utilizando software gratuito y software de su propio diseño.

Con base en los resultados del estudio de la funcionalidad del sistema, se recibió retroalimentación positiva tanto de los líderes y empleados del Ministerio de Industria y Comercio, como del Ministerio de Desarrollo Económico, que es responsable de la implementación de los mecanismos de gestión de proyectos en el gobierno. cuerpos. Además, las empresas industriales proporcionaron comentarios positivos sobre las capacidades de AIS PU que presentaron sus proyectos piloto como parte del desarrollo del sistema. En particular, representantes de FSUE "Krylov State Centro de ciencia", JSC" Corporación Científica y de Producción "Uralvagonzavod", Empresa del Estado Federal "Instituto de Investigaciones Científicas" Geodesia ". Cabe señalar también que los representantes de Garrison JSC, que se encuentra bajo la jurisdicción del Ministerio de Defensa, así como representantes de algunos bancos con participación estatal, mostraron gran interés en el sistema e interés en la cooperación conjunta en la implementación de la gestión de proyectos. .

“El sistema de gestión de proyectos creado no solo aumentará la eficiencia de los empleados del ministerio, sino que también permitirá organizar una interacción efectiva con los participantes en proyectos industriales de empresas industriales, organismos gubernamentales e instituciones de desarrollo e instituciones financieras. AIS PU trabaja bajo el principio de una “ventanilla única” con el máximo aprovechamiento de las tecnologías de gestión de documentos electrónicos ”, comentó Sergei Valuev, Director del Departamento de Tecnologías de la Información y Relaciones Públicas del Ministerio de Industria y Comercio, sobre la implementación de la sistema.

“El objetivo principal de introducir AIS PU es mejorar la calidad del control y la manejabilidad, facilitar la interacción entre autoridades y ejecutores de proyectos a gran escala. Al desarrollar el sistema, en primer lugar, se tuvieron en cuenta las normas de la industria, los decretos y órdenes del Gobierno, los decretos del Presidente y las órdenes del Ministro de Industria y Comercio, así como las mejores prácticas nacionales y extranjeras. Se han diseñado más de 600 componentes para el AIS PU, se han cargado más de 20.000 libros de referencia, diccionarios y clasificadores. Como parte del trabajo adicional en el desarrollo de AIS PU, se planea integrar el sistema como uno de los subsistemas del Sistema de Información Estatal de la Industria que actualmente está creando el Ministerio de Industria y Comercio de Rusia ”, dijo Sergey Valuev.

La introducción de métodos de gestión de proyectos se define como una de las principales herramientas para modernizar la administración pública y está consagrada en la nueva edición de las "Principales direcciones de actividades del Gobierno de la Federación de Rusia para el período hasta 2018", firmada por Prime Ministro Dmitry Medvedev.