El desarrollo de especificaciones técnicas de acuerdo con GOST 34 es simple y fácil

A menudo escuchas la opinión de que la preparación de los Términos de Referencia de acuerdo con GOST 34 (TK) no solo es laboriosa, sino que también es extremadamente molesta, porque tienes que escribir muchos tipos de agua sin sentido. Pero piénselo: institutos de investigación enteros participaron en el desarrollo de este GOST, fue un proyecto a nivel estatal, se resumió la experiencia de cientos de proyectos de automatización, proyectos complejos. ¿Podrían realmente escribir tonterías?

De hecho, con un enfoque competente, GOST ayuda enormemente no solo en el desarrollo de especificaciones técnicas, sino también durante la implementación del proyecto de automatización en su conjunto (y no solo en los contratos estatales, sino también para el desarrollo comercial). Las personas alfabetizadas lo escribieron. Pero para aprovechar los frutos de su trabajo, uno debe entender un poco el concepto no solo de los conocimientos tradicionales, sino también del GOST 34 en su conjunto.

En este artículo, analizaremos punto por punto todos los requisitos de GOST e intentaremos hacer que el desarrollo de TK de acuerdo con GOST 34 no sea una carga, sino una gran ayuda en el proyecto.

1. ¿De qué trata el artículo?

A menudo escuchas la opinión de que la preparación de los Términos de Referencia de acuerdo con GOST 34 (TK) no solo es laboriosa, sino que también es extremadamente molesta, porque tienes que escribir muchos tipos de agua sin sentido. Pero piénselo: institutos de investigación enteros participaron en el desarrollo de este GOST, fue un proyecto a nivel estatal, la experiencia de cientos de proyectos de automatización, proyectos complejos se generalizó. ¿Podrían realmente escribir tonterías?

De hecho, con un enfoque competente, GOST ayuda enormemente no solo en el desarrollo de especificaciones técnicas, sino también durante la implementación del proyecto de automatización en su conjunto (y no solo en los contratos estatales, sino también para el desarrollo comercial). Las personas alfabetizadas lo escribieron. Pero para aprovechar los frutos de su trabajo, uno debe entender un poco el concepto no solo de los conocimientos tradicionales, sino también del GOST 34 en su conjunto.

Por cierto, TK no es el primer documento que se está desarrollando durante el proyecto de automatización. Esto se afirma expresamente en el párrafo 1.5. GOST 34.602-89: "Los conocimientos tradicionales en la central nuclear se desarrollan sobre la base de los datos iniciales, incluidos los contenidos en la documentación final de la etapa" Investigación y justificación de la creación de la central nuclear "". Para más detalles, vea mi artículo Encuesta previa al diseño durante el desarrollo de un sistema de información .

ATENCIÓN: EL PROPÓSITO DE ESTE ARTÍCULO NO ES REEMPLAZAR GOST Y EXPLICAR ALGUNAS DISPOSICIONES.

2. Características características de las especificaciones técnicas de acuerdo con GOST 34

2.1. ¿Con qué estándar se compila el ToR?

El nombre completo del estándar para TK según GOST 34 es el siguiente: GOST 34.602-89 “Tecnología de la información (IT). Un conjunto de estándares para sistemas automatizados. Los términos de referencia para la creación de un sistema automatizado ".

El estándar en sí está impreso en solo 15 páginas (sí, bastante). El idioma es ruso, realmente ruso, y no está escrito en el alfabeto cirílico. Es decir, si no maneja en su cabeza de antemano que ni los textos de GOST, ni las leyes federales, ni las disertaciones son accesibles para la comprensión de un simple mortal, entonces es bastante posible leer y penetrar, aunque a menudo no es la primera vez.

De hecho, el estándar utiliza muchos términos oscuros. ¿Qué, por ejemplo, se entiende por apoyo lingüístico? Para aclarar los conceptos utilizados, uno debe recurrir a GOST 34.003-90 “Tecnología de la información (TI). Un conjunto de estándares para sistemas automatizados. Sistemas automatizados. Términos y definiciones ".

2.2. ¿Por qué necesita GOST para los Términos de referencia?

Probablemente, cuando necesite componer algún documento nuevo para usted, esté buscando una plantilla para dicho documento en Internet o solicítela a sus colegas. Entonces, CUALQUIER estándar para documentos o procesos es una plantilla. Además, la plantilla simplifica enormemente el desarrollo del documento: la estructura y el contenido ya han sido pensados ​​para usted, además, dicha plantilla tiene en cuenta los momentos que no habría recordado.

2.3. ¿Qué papel juegan los Términos de Referencia en el proyecto?

Según el párrafo 1.7 de la norma RD 50-682-89, "los términos de referencia son el documento principal de acuerdo con el cual se lleva a cabo la creación de la UA y la aceptación por parte del cliente". Y este es realmente el documento principal. Debe describir todo lo necesario para el desarrollo e implementación del sistema.

TOR establece la apariencia general del sistema, la cantidad de trabajo (marco de desarrollo), así como el procedimiento de desarrollo y aceptación. Todo comienza con TK y todo termina con él. Este documento es ideal para que su cliente comprenda la importancia y la complejidad de la tarea y por qué paga dinero.

Además, las especificaciones técnicas se compilan tanto para el contratista como para el cliente, ya que el proyecto de automatización lo llevan a cabo equipos de ambos lados. En cualquier proyecto de TI, hay una gran cantidad de actividades organizativas, cuya implementación es imposible sin la participación activa del cliente. Explique esto a los clientes en cada oportunidad, de lo contrario tienen la impresión de que solo tienen que pagar dinero y sentarse derecho: los empleados contratados harán todo. Y luego el proyecto falla y comienza el enfrentamiento. En general, sin un equipo real, por otro lado, no vale la pena comenzar un proyecto.

No formule TK formalmente. Si no sabe qué escribir, significa que es demasiado pronto para desarrollar TK, no tiene una comprensión del sistema, el proceso automatizado en sí mismo, el objeto de automatización, aún no se entiende. Debería elaborar un concepto del sistema , hablamos de esto al principio del artículo.

2.4. ¿Qué edad tienen GOST 34.602-89 y hay estándares más nuevos?

No tan anticuado. Casi no pude encontrar ninguna cosa no esencial. Y ninguno de los que afirman que GOST 34 está obsoleto no puede dar un solo ejemplo (¿probablemente no tenía los requisitos para leerlo?) El hecho es que GOST describe un enfoque general del proyecto de automatización, no habla de programación, GOST 34 no se trata de eso.

Bueno, si hablamos de comparación con otros estándares, entonces no hay nada especial con qué comparar. GOST 34 ofrece una visión tan amplia del proyecto de automatización que otros estándares no son adecuados para la suela externa (en mi opinión). Sí, son más simples (por lo tanto, más populares), pero la profundidad no es la misma. Aquí hay una lista de estándares con los que debe familiarizarse al desarrollar sus propios estándares para un proyecto de automatización:

• IEEE 830-1998. Metodología para compilar especificaciones para requisitos de software.
• GOST R ISO / IEC 12207-2010. Tecnología de la información. Ingeniería de sistemas y software. Procesos del ciclo de vida del software.
• ISO / IEC / IEEE 29148-2011. Ingeniería de sistemas y software. Procesos del ciclo de vida. Ingeniería de requisitos.
• GOST R 54869-2011. Gestión de proyectos. Requisitos de gestión del proyecto.
• Especificaciones estándar del pozo y del estado 34 series.

3. Principios generales para la preparación de especificaciones técnicas de conformidad con GOST 34

3.1. ¿Qué especialista debe redactar los Términos de referencia de acuerdo con GOST 34?

A menudo, los desarrolladores juran mucho al redactar TK según GOST 34. ¿Por qué? Sí, porque no es asunto de programadores. Los términos de referencia de acuerdo con GOST 34 generalmente no se pueden mostrar a los programadores. Hay documentos técnicos del proyecto para esto. Términos de referencia: un documento acordado con el cliente, que está constantemente sobre la mesa en el gerente del proyecto. TK responde dos preguntas: QUÉ debe hacer el sistema y CÓMO debe crearse. El proyecto técnico responde a la pregunta: ¿CÓMO deben cumplirse los requisitos de los TdR? Por ejemplo, en TK prescribe que debe haber autorización por inicio de sesión y contraseña, y en TP proporciona diseños de la interfaz, los scripts y la estructura de la base de datos. Por qué hay una división en diferentes etapas y por qué no debe hacer inmediatamente la tarea para los programadores, vea en mis artículos los secretos del diseño exitoso de IP (sistema de información) sobre el ejemplo de la construcción de un hospital y una encuesta previa al diseño al desarrollar un sistema de información .

Los términos de referencia deben ser elaborados por un analista de negocios, porque él es un "traductor" entre el cliente y el equipo de desarrollo. La tarea de un analista de negocios es comprender lo que el cliente necesita y expresarlo de manera clara para el equipo. Y expresarlo en forma de especificaciones técnicas. Además, se requiere que un analista de negocios no solo escuche al cliente y a sus empleados, sino que descubra lo que no dijo (y esto generalmente es más del 50%). Por lo tanto, el analista debe tener un buen conocimiento de los procesos que se están automatizando y, debido a su conocimiento, llenar los vacíos que quedaron en los resultados de la encuesta.

3.2. ¿De qué lado deben estar los Términos de Referencia?

Básicamente, ¿los términos de referencia son compilados por el contratista? Por qué

No solo porque se recomienda en el Apéndice 1 de GOST 34-602-89. De hecho, el cliente, por regla general, no tiene los especialistas adecuados. Pero TK es necesariamente desarrollado y acordado por el cliente. Y aquí es necesario asegurarse de que el acuerdo no sea formal. Siempre trato de insistir en que, junto con el cliente, analicemos cada artículo en detalle. Su objetivo es involucrar al cliente en el proyecto. De lo contrario, no formará sus expectativas sobre el sistema, lo que significa que, en primer lugar, no estará satisfecho con ningún resultado y, en segundo lugar, no podrá llevar a cabo las medidas organizativas necesarias.

3.3. ¿Hasta dónde puede ir desde GOST 34?

Cualquier plantilla también tiene un inconveniente significativo: esta es una plantilla. Es decir, un paso hacia la derecha y hacia la izquierda es la medida más alta de protección social (como se llamó antes a la pena de muerte).

De hecho, esto no es así. Cualquier estándar de proceso (es decir, un estándar no para salchichas, sino para alguna actividad) da solo indicaciones generales, resumen. Fue creado para ayudar a no olvidar algo importante, para transmitirle la experiencia de generaciones y no para llevarlo detrás de las banderas.

No lo creo? Luego lea la cláusula 2.2 de GOST 34.602-89 (por cierto, los números después del guión son el año de publicación del estándar o su edición): "Dependiendo del tipo, propósito, características específicas del objeto de automatización y las condiciones del funcionamiento del sistema, se permite elaborar secciones de TK en forma de aplicaciones, introducir adicional, excluir o fusionar subsecciones de conocimientos tradicionales ". También en el párrafo 1.2. El RD 34.698-90 establece: “El contenido de los documentos es común a todos los tipos de AS y, si es necesario, puede ser complementado por el desarrollador de los documentos dependiendo de las características del AS creado. Se permite incluir secciones e información adicionales en los documentos, para combinar y excluir secciones ".

En general, si solo puede citar frases generales, para todo lo bueno, contra todo lo malo, no escriba nada. De lo contrario, el especialista que lea el documento, que haya cumplido dichos pasajes, dejará de tomarlo en serio y se perderán puntos importantes. ¡No hagas que leer un documento sea una tortura!

3.4. ¿Por qué TK según GOST 34 describe tantos requisitos que no están directamente relacionados con las funciones del sistema?

De hecho, en un TOR de 30 páginas, solo 7-10 páginas pueden dedicarse a funciones. Esto tiene una explicación. El hecho es que los desarrolladores de GOST 34 miraron el proyecto de automatización de una manera completamente diferente a la nuestra. Y se veían más correctamente, de manera más integral.

En primer lugar , en la primera mitad de los conocimientos tradicionales, no solo se presenta información general sobre el sistema y los requisitos generales. Necesitamos entender por qué se crea el sistema, qué procesos automatiza, qué debe hacerse para que el sistema funcione, qué tipo de sistema tiene el sistema. Parece que son cosas comunes, pero sin ellas, los miembros del equipo comprenderán de manera diferente el objetivo del trabajo y los medios para lograrlo. Es muy importante para nosotros asegurarnos de que todos los participantes estén sintonizados con la misma ola, y no como un cisne, cáncer y lucio.

En segundo lugar , los compiladores de GOST 34 vieron el sistema principalmente como personas, y luego como un complejo de hardware y software. Así es como GOST 34.003-90 define un sistema automatizado: "Un sistema compuesto por personal y un conjunto de herramientas de automatización para sus actividades que implementa tecnología de la información para realizar funciones establecidas". Por lo tanto, un sistema de información es un personal capacitado, complejo de software y hardware, todos juntos. De hecho, quitar las computadoras a los contadores, son difíciles, pero podrán hacer su trabajo, aunque con registros en papel. Pero 1C no funcionará independientemente sin un contador. De ahí las numerosas secciones de los conocimientos tradicionales sobre medidas organizativas. Como dicen, un sistema de TI es 20% de TI, todo lo demás son medidas organizativas. Es decir, TK es un documento que detalla todo lo necesario para la implementación del sistema, de la A a la Z.

En tercer lugar , preste atención al nombre de GOST 34.602-89: "Términos de referencia para la creación de un sistema automatizado". TK no es para el sistema, sino para la creación del sistema. Cual es la diferencia La diferencia es que el TdR establece no solo los requisitos para el sistema en sí, sino que también regula el proceso de su creación, es decir, el documento contiene requisitos para todas las medidas organizativas, cuya implementación es necesaria para lograr el resultado. De hecho, al implementar un proyecto de automatización, a menudo necesita reestructurar una serie de procesos, capacitar al personal y preparar el hardware.

Cuarto , los términos de referencia son un documento mediante el cual puede marcar: ¿hemos tenido en cuenta este requisito o no? Tal vez pones 10 ticks limpiamente automáticamente, porque estas serán soluciones estándar. Pero la marca de verificación número 11 revelará un problema muy grande, y si omite este problema ahora, aparecerá en algún lugar del proceso de implementación, cuando todos los plazos y presupuestos ya estén definidos.

Quinto , como dijimos anteriormente, se pueden excluir subsecciones innecesarias, esto está permitido. Por ejemplo, si sabe con certeza que nada puede ser patentado en sus diseños, entonces ¿por qué presentar requisitos de pureza de patentes? Este no es el caso cuando no hay agua ni sídoles sin agua.

3.5. ¿Por qué las diferentes secciones dicen lo mismo?

De hecho, en TK hay subsecciones que repiten en gran medida el contenido de otras subsecciones. Por ejemplo, existen requisitos para el apoyo organizacional y para el número y las calificaciones del personal. En ambos párrafos estamos hablando del personal.Pero en el primer caso, proporcionamos información sobre la estructura organizativa: qué departamentos deberían ser, cómo debería establecerse la interacción con otros departamentos. De acuerdo, esto no es lo mismo que simplemente los requisitos para el número y las calificaciones del personal.

Pero para sistemas pequeños, solo se requieren uno o dos administradores y un par de moderadores. En este caso, simplemente no tenemos nada que describir en dos secciones completas. Luego omita algunas secciones y, en la otra, proporcione una declaración completa de los requisitos.

3.6. ¿Necesito emitir TK de manera de calidad?

Aunque los requisitos para el diseño de los conocimientos tradicionales se dan en el párrafo 3 de GOST 34.602-89, digamos algunas palabras sobre este aspecto.

Por supuesto, el contenido principal. Pero, en primer lugar, son recibidos por la ropa y, en segundo lugar, es difícil leer textos analfabetos con una fuente omitida. Los lectores se distraerán con un diseño de baja calidad y les será más difícil profundizar en el contenido. Por lo tanto, se acepta un contenido técnico estricto y una terminología limitada en los documentos técnicos, sin expresiones coloridas: el lector debe centrarse en la esencia y no en los giros artísticos.

Aquí hay algunas sugerencias para la ejecución de documentos grandes, como TK.

En primer lugar, es imprescindible usar estilos en un documento grande y, excepto para subrayar o resaltar dentro de un párrafo, no cambie la configuración de fuente y párrafo para un solo fragmento. Si cambias, entonces el estilo.

En segundo lugar , no debemos olvidar elementos tan obligatorios como una tabla de contenido de autocompletar, una lista de términos y abreviaturas (bueno, no es divertido adivinar qué significa esto con una u otra abreviatura), página de título. También es aconsejable proporcionar una lista de versiones del documento, una lista de cambios: es muy fácil rastrear más tarde las fechas en que se envió una versión en particular.

Cuarto, cada requisito individual debe establecerse en un párrafo numerado por separado. Si hay 2-3 requisitos en un fragmento, solo se lee el primero y nuestro cerebro se salta el resto. TK es un documento en el que, frente a cada párrafo, puede verificar si se cumple el requisito o no.

Quinto , no escatime en la colocación de enlaces. A veces, lees un párrafo donde se menciona alguna función o requisito, y no entiendes, esto es del mismo documento o de otro. Si de esto, entonces en qué sección. Por lo tanto, intente consultar otras secciones si se mencionan en el texto actual. Naturalmente, los enlaces deben ser automáticos.

Tenga en cuenta que, de acuerdo con reglas estrictas, la declaración de trabajo se redacta sin marco (esto se indica en el párrafo 3), pero el resto de los documentos están enmarcados. Esto se establece en GOST 24.301-80 "Sistema de documentación técnica para ACS. Requisitos generales para la implementación de documentos de texto (como Enmendado No. 1, 2) ". Esta norma establece las reglas para la ejecución de todos los documentos, excepto los conocimientos tradicionales y los documentos creados en las etapas previas al diseño. Aunque personalmente no me gusta el marco en ningún documento.

4. Sección 1. “Información general” / p. 2.3 GOST 34.602-89 /

La mayoría de la información presentada en esta sección no necesita comentarios, por lo que nos centraremos solo en algunas subsecciones.

Por lo tanto, por "lista de documentos en base a los cuales se crea el sistema" nos referimos a leyes, órdenes o un acuerdo. Además, dicho documento puede ser otro TK, si desarrollamos TK para el subsistema. En general, hay varias secciones en los Términos de Referencia que contienen una lista de documentos, y uno debe entender muy claramente las diferencias entre el propósito de estas partes de la tarea técnica.

En la subsección "Procedimiento para procesar y presentar al cliente los resultados del trabajo en la creación del sistema (sus partes), en la fabricación y puesta en marcha de herramientas individuales (hardware, software, información) y complejos de sistemas de software y hardware (software y metodológicos)" se proporciona información general sobre la aceptación del trabajo. Por ejemplo, el hecho de que transferimos documentación y realizamos una serie de pruebas del sistema. Aquí solo mencionamos el procedimiento para transferir los resultados del trabajo y, a continuación, en otras secciones, este tema se describe en detalle.

5. Sección 2. “Propósito y objetivos de crear (desarrollar) el sistema” / p. 2.4 GOST 34.602-89 /

Aquí necesitamos entender la diferencia entre el propósito y el propósito de crear un sistema. Muy a menudo, estos conceptos son confusos. Por ejemplo, escriben que el propósito del sistema es la automatización de su cuenta personal, y el objetivo es crear una cuenta personal. El petróleo es el petróleo. En algunos casos, estos conceptos realmente coinciden, luego escriba solo la cita.

Con el propósito, todo está claro: damos exactamente el tipo (s) de actividad automatizada. Por ejemplo, si creamos un sistema para la contabilidad de producción, entonces vale la pena citar tipos automatizados de contabilidad, operaciones automatizadas, así como objetos cuya automatización se supone.

Con el objetivo, todo es diferente. El objetivo es para lo que estamos planeando un proyecto. Puedes llamarlo objetivos comerciales. Destaco los siguientes objetivos posibles para proyectos de automatización:

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

El GOST también dice que es necesario proporcionar criterios para evaluar el logro de la meta, es decir, indicadores específicos. Por ejemplo, tenemos 3 personas que recolectan un total de 20 pedidos por día. Y después de la implementación del sistema, queremos que todos recopilen 20 pedidos, es decir, tres veces más. Si se conocen tales indicadores allí, los presentamos en este párrafo.

6. Sección 3. "Características del objeto de automatización" / p. 2.5 GOST 34.602-89 /

Una sección muy importante, ya menudo a menudo descrita formalmente. Aunque, en mi opinión, esta es la sección más importante de TK, sin ella simplemente no entendemos sobre qué se está creando el sistema.

Primero definamos qué es un "objeto de automatización". Si automatizamos un almacén o una planta, un departamento de contabilidad, entonces todo está claro. Y si, por ejemplo, creamos una nueva red social, entonces el objeto, por así decirlo, no existe. Pero, de hecho, es más probable que un objeto signifique procesos automatizados. E incluso en el caso de un almacén, no automatizamos el almacén en sí (¿cómo se puede automatizar el almacenamiento de cajas?), Sino que los procesos de almacén.

Si lleva a cabo esta sección formalmente, será muy similar a la descripción del propósito del sistema, y ​​aparecerá otro lago de agua en los TOR, pero no estará claro qué debe hacer el sistema.

Esta sección debe incluir:

1. Descripción del cliente: actividades del cliente, número de sucursales, empleados. Por supuesto, debe caracterizar al cliente en esa parte que se relaciona directamente con el sistema que se está creando.
2. Información sobre los usuarios del sistema: tipos de usuarios, qué papel juega el sistema para diferentes usuarios.
3. Descripción de objetos automatizados. Por ejemplo, si automatizamos un almacén, debemos describir cuánta área tiene, cuántos pasillos, qué ancho de pasillos, qué estantes, si hay un área de montaje separada, cuántas personas trabajan y qué responsabilidades tienen. Entonces entenderemos que estamos automatizando específicamente el aspecto del proceso de almacén y qué equipo se está utilizando.
4. Descripción de procesos automatizados. Por supuesto, no es necesario describir los procesos en detalle en TK. Pero se requieren escenarios comunes. Solo entonces nos queda claro qué funciones deberían estar disponibles.
5. Una lista de documentos que proporcionan una descripción detallada del objeto de automatización.

He tenido casos en los que la descripción de esta sección tomó más de la mitad del desarrollo de los conocimientos tradicionales, porque lleva mucho tiempo y meticulosamente recopilar información diferente, analizarla y describirla cuidadosamente.

7. Sección 4 "Requisitos del sistema"

En TK según GOST 34 hay una sección gigantesca: la sección 4 "Requisitos del sistema". Tiene tres subsecciones:

• Requisitos para el sistema en su conjunto.
• Requisitos para las funciones (tareas) realizadas por el sistema.
• Requisitos para tipos de garantías.

Consideraremos estas subsecciones por separado.

7.1. Subsección 4.1. "Requisitos para el sistema en su conjunto" / p. 2.6.1 GOST 34.602-89 /

En la subsección 4.1 “Requisitos para el sistema en su conjunto”, se describen los llamados requisitos generales no funcionales que describen el sistema que se está creando desde diferentes ángulos.

Por cierto, como ya hemos mencionado, se pueden agregar y omitir subsecciones. Por lo tanto, la numeración dada aquí es aproximada, sirve de orientación dentro del artículo.

7.1.1 Cláusula 4.1.1. "Requisitos para la estructura y funcionamiento del sistema" / p. 2.6.1.1 GOST 34.602-89 /

Este elemento es bastante extenso, debe dar una idea general de la arquitectura del sistema. Analizaremos estos requisitos con más detalle.

1. La lista de subsistemas, su propósito y características principales, requisitos para el número de niveles de jerarquía y el grado de centralización del sistema.

En este párrafo, generalmente cito:

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

Si está planeando una arquitectura de microservicio, entonces tiene sentido enumerar y describir la funcionalidad de los servicios.

Para mayor claridad, es conveniente adjuntar un diagrama estructural del sistema con la designación de sus partes y sistemas relacionados, como se muestra en los ejemplos a continuación.



... más o menos:



2. Requisitos para los 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 la relación del sistema creado con los sistemas relacionados, requisitos para su compatibilidad, incluidas las instrucciones sobre cómo intercambiar información (automáticamente, envío de documentos, por teléfono, etc.)

En condiciones modernas, la mayoría de las interacciones se realizan utilizando el protocolo HTTP (S). Parece que, además de esto, no hay nada que escribir. Sin embargo, estos elementos pueden ser tan grandes que se envían a la aplicación. Deben proporcionar la siguiente información:

• una lista de información transmitida, al menos una descripción general, para comprender en general por qué nos estamos integrando con un sistema específico;
• descripción del protocolo (o enlaces de descripción), especialmente en el caso de conexión de dispositivo;
• estructura de red local;
• velocidad de datos requerida;
• uso de Internet móvil o WiFi;
• Descripción de métodos de transmisión de datos no automatizados.

4. Requisitos para los modos de funcionamiento del sistema.
Los modos de operación pueden tener varias clasificaciones:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• Visibilidad de la aplicación: diálogo o fondo
• sobre el posible impacto en el sistema: regular, entrenamiento, modos de prueba.

5. Requisitos para diagnosticar el sistema.

Deben establecerse requisitos para el diagnóstico continuo o periódico para sistemas basados ​​en arquitectura de microservicio (espaciado), sistemas que incluyen equipos: sensores, sistemas de control, terminales, etc. Por supuesto, si solo se desarrolla un software que se ejecute en un único servidor, estos requisitos son superfluos: descubrirá si algo deja de funcionar.

6. Perspectivas para el desarrollo, modernización del sistema.

Parece, ¿cuáles son las perspectivas para el desarrollo del sistema en la subsección "Requisitos para la estructura y funcionamiento del sistema"? Pero imagine, ahora está creando una versión alfa para 100 personas, y en un año desea obtener más de un millón de usuarios que trabajan simultáneamente en diferentes partes del mundo. Luego, en la etapa de creación, inmediatamente debe proporcionar una arquitectura de clúster.

O ahora está trabajando desde una organización, y en seis meses habrá varias, lo que significa que debe prever la posibilidad de expansión.

En otras palabras, en esta sección puede anotar todas las perspectivas de modernización, pero especialmente las que definitivamente afectarán la arquitectura.

7.1.2. Cláusula 4.1.2. "Requisitos para el número y las calificaciones del personal" / p. 2.6.1.2 GOST 34.602-89 /

Como mencionamos anteriormente, cualquier sistema automatizado consiste en "personal y un conjunto de herramientas de automatización para sus actividades". Por lo tanto, los requisitos para el personal y sus calificaciones se indican en los TOR.

Si automatiza una línea de producción específica, entonces sabe la cantidad de personal. Pero en muchos casos, depende de la cantidad de trabajo realizado. Por lo tanto, indique los puestos, el horario de trabajo, la descripción de las actividades (para asignar derechos de acceso) y las calificaciones aproximadas. Como mínimo, necesita un administrador y operador del sistema, a menudo un moderador. Es posible que deba proporcionar varios tipos de operadores con diferentes niveles de acceso.

Está claro que los requisitos para el personal a menudo son establecidos por el cliente, ¿por qué entonces traerlos? Pero, en primer lugar, ya hemos dicho que las especificaciones técnicas están redactadas para ambas partes y, en segundo lugar, el contratista estará protegido: no se cumple la condición de selección de personal, ¿qué quiere el cliente si el sistema no está implementado?

7.1.3. Cláusula 4.1.3. "Requisitos para los indicadores de rendimiento" / p. 2.6.1.3 GOST 34.602-89 /

En esta subsección, a menudo se escribe lo que le gusta, ya que la lista de posibles indicadores falta en el texto GOST, y es casi imposible encontrarlos en fuentes abiertas. Tenga en cuenta que el "grado de adaptabilidad", los "límites de modernización" y las "características de tiempo de probabilidad" dados en GOST están, en primer lugar, indicados para ACS (sistema de control automatizado) y, en segundo lugar, son bastante difíciles de medir. Por lo tanto, estas características no siempre son adecuadas.

Sin embargo, en el texto mismo, los "indicadores de nombramiento" se definen como "parámetros que caracterizan el grado de cumplimiento del sistema con su propósito". En los sistemas informáticos modernos, los valores cuantitativos que caracterizan este sistema se relacionan principalmente con el rendimiento y el volumen de almacenamiento de datos.

Los indicadores de destino incluyen:

• la cantidad de usuarios que trabajan simultáneamente en el sistema;
• el número de solicitudes ejecutadas simultáneamente al servidor;
• el número de transacciones (registradas) por unidad de tiempo de transacciones;
• tiempo de respuesta para un número diferente de solicitudes únicas y usuarios que trabajan, para una cantidad diferente de datos procesados ​​(especialmente al buscar y agregar informes);
• cantidad de datos almacenados (en particular, imágenes y videos);
• tiempo de conexión para potencia informática adicional cuando se alcanza la carga máxima;
• tiempo de conexión de capacidades adicionales con un aumento significativo en el volumen de datos almacenados.

Todas estas características afectan la elección del hardware del servidor, el servidor de aplicaciones y la arquitectura DBMS, DBMS relacionales o no relacionales, microservicios, etc.

7.1.4. Cláusula 4.1.4. "Requisitos de fiabilidad" / p. 2.6.1.4 GOST 34.602-89 /

El texto de GOST describe con suficiente detalle lo que debe indicarse en los requisitos de confiabilidad. Sin embargo, para comprender el enfoque para garantizar la confiabilidad inherente a este estándar, debe estudiar los GOST de la serie 27. Para comenzar, debe familiarizarse con la terminología: esto será suficiente para comprender el concepto mismo de confiabilidad, cómo se mide y cómo se proporciona. Por lo tanto, consulte GOST 27.002-89. “Fiabilidad en tecnología. Conceptos basicos. Términos y definiciones ".

El concepto básico que se puede aplicar a los sistemas automatizados es el factor de disponibilidad: 99%, 99,9%, 99,99%. Cada número de "nueves" es proporcionado por ciertas medidas.

¿Qué soluciones técnicas pueden afectar estos requisitos? Este es el número de capacidades de reserva (varían), y la disponibilidad de personal técnico en el terreno, y el uso no solo de fuentes de alimentación ininterrumpida, sino también generadores diésel, así como la conexión desde dos fuentes independientes (conexión a redes eléctricas de acuerdo con las categorías de confiabilidad I o II).

7.1.5. Cláusula 4.1.5. "Requisitos de seguridad" / p. 2.6.1.5 GOST 34.602-89 /

Esta subsección describe los requisitos de seguridad para el manejo de equipos (instalación, puesta en marcha y operación). Ahora, estos requisitos se denominan protección laboral y están contenidos en los GOST de la 12ª serie (SSBT - el sistema de normas de seguridad laboral). En TK, es suficiente dar una lista de estas secciones, de nuevo, si alguien va a comprometerse seriamente con la seguridad.

7.1.6. Cláusula 4.1.6. "Requisitos de ergonomía y estética técnica" / p. 2.6.1.6 GOST 34.602-89 /

Damos los requisitos de GOST: "Los requisitos de ergonomía y estética técnica incluyen indicadores de CA que especifican la calidad necesaria de la interacción humana con la máquina y la comodidad de las condiciones de trabajo del personal".

Por lo general, en este párrafo se escribe que el sistema debe tener una interfaz conveniente y hermosa. ¿Pero cómo medir la conveniencia y la belleza? Por lo tanto, omitimos este requisito, o decimos que la interfaz corresponderá a un proyecto de diseño desarrollado más tarde, o proporcionamos estándares, por ejemplo, las llamadas "pautas" para desarrollar aplicaciones móviles: Diseño de materiales para Android y Pautas de interfaz humana para iOS.

También puede proporcionar el número máximo de transiciones (clics) al implementar ciertas funciones que son especialmente importantes para nosotros, la velocidad promedio de búsqueda de datos, etc.

7.1.7. Cláusula 4.1.7. "Requisitos de transportabilidad para altavoces móviles" / p. 2.6.1.7 GOST 34.602-89 /

Decir algún requisito obsoleto. Ahora los servidores en camiones, como las computadoras grandes antes, no llevan. Sin embargo, imagine que tiene algún tipo de superprotección, un circuito interno detrás de la DMZ y ... la necesidad de trabajar a distancia a través de una computadora portátil. Sí, una VPN está configurada en cualquier momento, pero es mejor si se refleja en la Guía de administración, y la posibilidad en sí misma está prevista en la configuración de la red.

7.1.8. Cláusula 4.1.8. "Requisitos de operación, mantenimiento, reparación y almacenamiento" / p. 2.6.1.8 GOST 34.602-89 /

Estos requisitos se relacionan con el mantenimiento de un complejo de medios técnicos (servidores, firewalls, conmutadores, estaciones de trabajo, etc.) Si el equipo requiere algún mantenimiento especial, es necesario describir esto en esta sección. Por ejemplo, tiene un dispositivo especial que necesita calibrarse una vez al mes.

7.1.9. Cláusula 4.1.9. "Requisitos para la protección de la información contra el acceso no autorizado" / p. 2.6.1.9 GOST 34.602-89 /

El tema de proteger la información del acceso no autorizado es bastante extenso, al igual que las medidas para garantizarlo. Por supuesto, si estamos hablando del acceso a la cuenta personal del sitio web y al panel de administración de este sitio web, entonces hay suficientes requisitos para la autorización, la complejidad de la contraseña y el modelo de acceso a roles. Pero si se crea un sistema financiero o un sistema para las necesidades del estado, entonces aparecen requisitos especiales.

Es importante tener en cuenta que en esta subsección se dan no solo las medidas que deben aplicarse durante el desarrollo del sistema, sino también su funcionamiento.

Por lo tanto, para los sistemas financieros, debe utilizar el "Estándar de seguridad de datos de la industria de tarjetas de pago" (PCI DSS). Para los sistemas en los que se almacenan datos personales, - Decreto del Gobierno de la Federación de Rusia de fecha 01.11.2012 No. 1119 "Sobre la aprobación de los requisitos para la protección de datos personales durante su procesamiento en sistemas de información de datos personales". Puede haber otros estándares en su área temática.

En general, el equipo de protección se puede dividir en los siguientes tipos:

1. Medios proporcionados por el producto de software creado.
2. Medidas proporcionadas por el administrador del sistema.
3. Medidas de protección física.
4. Medidas organizativas generales.
5. Medidas tomadas durante el proceso de desarrollo de software.

1. Medidas de seguridad proporcionadas por el producto de software creado:

• Requisito de contraseña para usuarios, especialmente para usuarios con el rol de administrador.
• Implementación de un modelo de acceso basado en roles.
• El requisito de utilizar claves de firma electrónica para realizar operaciones críticas.
• Eliminar componentes de software responsables de interactuar con sistemas externos a la DMZ.
• Proporcionar registro de eventos y acciones del usuario.

2. Medidas proporcionadas por el administrador del sistema:

• El uso de firewalls (firewalls).
• Documentar y monitorear los servicios y protocolos utilizados.
• Configuración de zona desmilitarizada (DMZ).
• Monitorear la implementación de las reglas para usar computadoras portátiles: conectarse a una red interna, usar firewalls.
• Deshabilitar cuentas predeterminadas antes de conectar equipos y sistemas a la red.
• Configurar dispositivos de acceso inalámbrico: establezca contraseñas y cambie la configuración de acceso predeterminada.
• Instale actualizaciones que resuelvan vulnerabilidades identificadas de hardware y software.
• Proporcionar seguridad para el acceso remoto al sistema (por ejemplo, usando una VPN).
• Instalación, actualización y monitoreo de software antivirus.
• Realice escaneos y escaneos periódicos de la red después de realizar cambios importantes.
• Asignación de una cuenta única a cada empleado, comprobaciones periódicas de la presencia de cuentas eliminadas de empleados despedidos, cambio de contraseñas. Emisión y contabilidad de tokens de firma electrónica.
• Configurar restricciones de acceso a la base de datos.
• Control de sincronización horaria en todos los servidores y estaciones de trabajo (para garantizar la exactitud del tiempo registrado en los registros de eventos).
• Configurar registros de eventos.
• Inventario periódico de puntos de acceso inalámbricos y otros equipos con software instalado.

3. Medidas de protección física:

• Acceso restringido a salas críticas.
• Desconecte los conectores de red en lugares públicos.
• Instalación de cámaras de CCTV para locales críticos.

4. Medidas organizativas generales:

• Adopción de una política de seguridad y capacitación periódica del personal en normas de seguridad de la información.
• Implementar procedimientos de respuesta a incidentes de seguridad.
• Verificación de pantalla o informes de datos confidenciales.
• Emitir insignias a todos los visitantes, escoltar a los visitantes mientras se encuentran en áreas críticas.
• Revisión integral de empleados contratados.
• Brindar seguridad por parte de las organizaciones-proveedores de servicios relacionados con software y hardware.

5. Medidas tomadas durante el proceso de desarrollo de software:

• Las personas responsables controlan la realización de cambios en el código del programa, verificando que el código cumpla con las reglas de seguridad de la información (control de desbordamiento del búfer, manejo correcto de errores, verificación de scripts de crossite, errores del mecanismo de acceso, etc.)
• El uso de criptografía fuerte.
• Aplicación de normas de seguridad para aplicaciones web públicas.
• Desarrolle un procedimiento de cancelación para cada cambio.
• Documentación de cambios.

7.1.10. Cláusula 4.1.10. "Requisitos para la seguridad de la información en caso de accidente" / p. 2.6.1.10 GOST 34.602-89 /

Esta sección proporciona una lista de posibles accidentes y fallas en los que se debe garantizar la seguridad de la información. Dichos eventos pueden incluir:

• pérdida de nutrición;
• falla del servidor;
• falla del dispositivo de almacenamiento (disco duro).

7.1.11. Cláusula 4.1.11. "Requisitos para la protección contra la influencia de influencias externas" / p. 2.6.1.11 GOST 34.602-89 /

Esta sección será útil en el caso de servidores, estaciones de trabajo y otros equipos en un almacén frío o, por el contrario, en locales industriales con temperaturas elevadas, en lugares polvorientos o lugares con alta humedad. A veces también vale la pena considerar la vibración, la radiación u otras influencias.

7.1.12. Subsección 4.1.12. "Requisitos para la pureza de la patente" / p. 2.6.1.12 GOST 34.602-89 /

Si sospecha que utilizará cualquier tecnología patentada en otros países (o en nuestro país) y el titular de la patente puede presentar una demanda contra el propietario del sistema, este párrafo indica la lista de países en los que desea verificar para pureza de patente.

7.1.13. Cláusula 4.1.13. "Requisitos de estandarización y unificación" / p. 2.6.1.13 GOST 34.602-89 /

Este artículo rara vez se incluye en los Términos de referencia con respecto al software específicamente. Indica tanto los requisitos para el uso de tecnologías específicas como las formas estandarizadas de documentos y clasificadores.

Esta descripción es especialmente importante si tiene requisitos específicos para los marcos utilizados, complementos, protocolos, dispositivos, algoritmos matemáticos, software de terceros, etc. Simplemente no olvide indicar en qué parte y para qué propósito deben usarse estas herramientas.

Además, a veces en los sistemas de algunas clases se acostumbra usar ciertos protocolos de intercambio de datos. Por ejemplo, los estándares OCG se usan para intercambiar datos entre sistemas de información geográfica, y OCPP se usa para controlar estaciones de carga para vehículos eléctricos.

7.1.14. Cláusula 4.1.14. "Requisitos adicionales" / p. 2.6.1.14 GOST 34.602-89 /

Este párrafo debe encontrarse en el texto de GOST. No necesita comentarios.

7.2. Subsección 4.2. “Requisitos para las funciones (tareas) realizadas por el sistema” / p. 2.6.2 GOST 34.602-89 /

Esta sección es fundamental para los sistemas informáticos modernos. En realidad, el sistema está creado para el desempeño de ciertas funciones. A menudo, los conocimientos tradicionales, creados sobre la base de normas extranjeras y generalmente sin normas, contienen solo esta sección.

7.2.1 Estructura de descripción funcional

Primero, consideramos la estructura de los requisitos funcionales para el sistema: subsistema - conjunto de funciones - función - tarea. Una tarea es parte de una función, y la tarea se puede describir como una función separada. Por ejemplo, para la función de inicio de sesión, introducimos una contraseña como una de las tareas. Y podemos describir el procedimiento de ingreso de contraseña como una función separada: verificación de corrección, recuperación de contraseña, visualización de mensajes, etc. Un complejo es lo que une funciones. Por ejemplo, "Contabilización de información básica", "Celebración de una subasta", etc. El complejo tiene dos o más funciones.

Si su sistema consta de varios subsistemas, básicamente TK debería proporcionar una lista de funciones para subsistemas, y ya describir en detalle los requisitos funcionales para subsistemas en TK individuales para subsistemas (a menudo se les llama CTZ ahora, una tarea técnica privada).

7.2.2 Tipos de funciones en términos de su implementación.

De hecho, todas las funciones (o sus tareas; varias tareas pueden estar presentes en una función a la vez) se pueden dividir en los siguientes tipos:

• Ingresando información. En ocasiones se denomina "información contable".
• Salida de información.
• Procesamiento automático de información.

7.2.3 Tipos de funciones en función de su función.

Las funciones pueden ser generales y especiales. Las funciones comunes, por ejemplo, incluyen trabajar con listas de objetos, trabajar con una tarjeta de objetos y trabajar con un mapa interactivo. Estas funciones pueden aplicarse a todas las funciones especiales o partes de funciones especiales.

7.2.4 Requisito, no script

No olvide que el ToR contiene requisitos para el sistema y el proceso de su creación. No guiones. TK responde a la pregunta QUÉ debe hacer el sistema. A la pregunta CÓMO responde el diseño técnico. Si comienza a describir en detalle la implementación técnica, sumérjase en los detalles y no brinde una lista completa de requisitos: nuestro cerebro no puede trabajar simultáneamente en modos de cobertura amplia y consideración de detalles.

La estructura de las funciones de los TOR y el proyecto técnico pueden diferir enormemente: en un escenario se pueden implementar varias funciones, y viceversa.

7.2.5 Requisitos funcionales

Aquí hay algunas recomendaciones sobre cómo elaborar una descripción de funciones:

1. Los requisitos para las funciones y tareas generalmente deben hacerse a la aplicación. Por lo tanto, el documento se divide orgánicamente en partes no funcionales y funcionales. Además, la aplicación siempre se puede imprimir y ver por separado.
2. Evitar párrafos grandes. Es mejor si los requisitos se dividen en párrafos y subpárrafos: es más fácil percibirlos y controlar su implementación (marque las casillas). Si se proporciona una lista de requisitos o información, déjelo en una lista numerada o con viñetas.
3. Para funciones cuyo propósito no es obvio por su nombre, es necesario indicar el propósito y el problema a resolver. De lo contrario, incluso el compilador de TK corre el riesgo de olvidar por qué describió esta o aquella funcionalidad.

7.2.6. Función Descripción Ejemplo

5.6. Registro de un vehículo en el Sistema

Se presentan los siguientes requisitos:

1) El sistema debe permitir tener en cuenta la siguiente información general:

• marca de registro estatal (GRNZ);
• Nombre del dueño;
• dirección del dueño;
• datos del servicio de adquisición de datos del vehículo (ver cláusula 3.3, Apéndice B);
• nota

2) El sistema debe permitir tener en cuenta la siguiente información relacionada con el pago de la tarifa (la información especificada es de naturaleza informativa, no se requiere la posibilidad de cambiarla directamente en la tarjeta de registro del vehículo):

• clase de vehículo actual (ver cláusula 3.3, Apéndice A);
• tarifa actual (véase la cláusula 5.1, Apéndice A);
• contrato actual (ver cláusula 5.5, Apéndice A);
• clase de vehículo según información del Ministerio del Interior de la República de Kazajstán;
• información sobre la cuenta personal y su estado (ver cláusula 3.6, Apéndice A);
• información sobre estar en el registro de vehículos con tarifa reducida (ver cláusula 3.5, Apéndice A).

3) El sistema debe permitir registrar y cambiar la información sobre el vehículo de las siguientes maneras:

• manualmente por el operador;
• al recibir información del sistema de registro de etiquetas RFID (ver cláusula 1.1, Apéndice B);
• al identificar el vehículo con la cámara GRNZ.

4) Al registrar un nuevo vehículo en el sistema, el sistema debe solicitar datos sobre el vehículo al servicio para recibir datos sobre el vehículo (consulte el párrafo 3.3, Apéndice B). Debería ser posible actualizar la información especificada de un vehículo individual.

7.3. Subsección 4.3. "Requisitos para los tipos de seguridad" / p. 2.6.3 GOST 34.602-89 /

La sección de requisitos para los tipos de soporte generalmente se cita a menudo como un ejemplo del exceso de volumen de TK según GOST. Cuando se trata de si se deben dar todas las secciones y subsecciones, recuerdan el software, para lo cual en la mayoría de los casos simplemente no hay nada que escribir.

De hecho, esta es una subsección muy importante, aunque no todos entienden su propósito. Describe las condiciones sin las cuales es imposible implementar el desarrollo o la puesta en marcha. Estas condiciones se describen como "colateral".

Al leer esta subsección, uno se pregunta qué querían decir los redactores del estándar por "software", "software lingüístico", "software de información", etc. Se deben buscar respuestas en GOST 34.003-90, donde se descifran todos estos términos.

7.3.1. Cláusula 4.3.1 "Software" / p. 2.6.3.1 GOST 34.602-89 /

Imagine la situación que necesita para crear un sistema en el que desea implementar el cálculo automático de la ruta óptima. El botón "Calcular ruta" puede parecer simple, pero pueden estar detrás de él algoritmos y cálculos matemáticos muy complejos. Está claro que no vale la pena emprender el desarrollo de tales algoritmos; los matemáticos profesionales se dedican a esto. Si tales algoritmos están disponibles, también se escriben los requisitos para su desarrollo o el uso de los preparados.

7.3.2. Cláusula 4.3.2 "Soporte de información" / p. 2.6.3.2 GOST 34.602-89 /

Al leer la descripción de este requisito en el texto GOST, parece que esto es una repetición de lo que se ha dicho en otras secciones. Por ejemplo, ¿por qué describir nuevamente los requisitos para "composición, estructura y métodos de organización de datos en el sistema" y "para el intercambio de información entre los componentes del sistema"? Pero nuevamente olvidamos que los compiladores de GOST bajo el sistema no solo tenían software, sino también todo el conjunto de medidas organizativas.

Al presentarlo, se encuentra con una situación tal que el cliente, por su parte, no ha proporcionado un operador que ingresará ningún dato en el sistema, y ​​al mismo tiempo declara que el sistema no funciona. ¿Una situación familiar? Pero si el requisito de proporcionar esta información se especifica en la declaración de trabajo, entonces sería posible pinchar directamente al cliente en este punto. O necesita acceso a un clasificador de direcciones específico para el trabajo, pero el cliente no se lo proporciona.

Por lo tanto, en este párrafo tiene sentido especificar los requisitos para la información entrante y la información transmitida de un componente a otro del sistema de manera no automatizada. El procesamiento automatizado de la información, el uso de DBMS, el intercambio de información dentro del sistema se describen detalladamente en otras secciones.

7.3.3. Cláusula 4.3.3 "Apoyo lingüístico" / p. 2.6.3.3 GOST 34.602-89 /

Este párrafo proporciona:

• requisitos para el uso de lenguajes de programación (si hay preferencias específicas);
• idioma de la interfaz (qué idiomas, interfaz multilingüe);
• lenguaje para la comunicación entre equipos de proyecto, requisitos de traducción;
• otras características de entrada y salida de datos, si están disponibles: cifrado, métodos no estándar de interacción del usuario con el sistema.

7.3.4. Cláusula 4.3.4 "Software" / p. 2.6.3.4 GOST 34.602-89 /

Este párrafo proporciona una lista de software comprado, si se identifican en la etapa de desarrollo de los Términos de Referencia.

7.3.5. Cláusula 4.3.5 "Soporte técnico" / p. 2.6.3.5 GOST 34.602-89 /

Cualquier sistema de información no puede funcionar sin hardware, servidores, redes, etc. Por lo general, se recomienda determinar las características específicas de los equipos en un diseño técnico, pero se puede proporcionar una composición aproximada en la declaración de trabajo para que el cliente tenga una idea de los costos futuros.

7.3.6. Cláusula 4.3.6 "Apoyo metrológico" / p. 2.6.3.6 GOST 34.602-89 /

Si se planea recibir datos de sensores en el sistema, entonces es necesario comprender qué instrumentos de medición se utilizarán, qué instrumentos de medición de precisión deben proporcionar, si estas herramientas deben certificarse y certificarse.

7.3.7. Cláusula 4.3.7 "Apoyo organizativo" / p. 2.6.3.7 GOST 34.602-89 /

Imagine que está creando un sistema desde cero. Por ejemplo, este es un sistema de gestión de almacenes para un nuevo complejo logístico. En otras palabras, solo hay paredes. O está actualizando el sistema y para implementar los cambios necesita modificar la estructura organizativa. En tales casos, debe especificar las condiciones con respecto a la organización de los procesos bajo los cuales el sistema suministrado por usted realmente funcionará.

7.3.8. Cláusula 4.3.8 "Apoyo metodológico" / p. 2.6.3.8 GOST 34.602-89 /

Algunas veces, para administrar el sistema, se requiere personal con competencias especiales. En este caso, se debe proporcionar una lista de métodos, normas y estándares en los TOR, con los cuales los empleados que interactúan con el sistema deben familiarizarse.

7.3.9. Otros tipos de garantías

Al desarrollar cada nuevo TK, debe considerar lo que necesitará para una puesta en marcha exitosa. Por ejemplo, a menudo escribo requisitos para el soporte legal, cuando el marco legal utilizado no está completamente definido y su desarrollo puede afectar la implementación. Aunque estos problemas se resuelven mejor antes de redactar los términos de referencia .

8. Sección 5 “Composición y contenido del trabajo sobre la creación (desarrollo) del sistema” / p. 2.7 GOST 34.602-89 /

Esta sección es organizativa y a menudo se incluye en el contrato. Sin embargo, esta información en los ToR puede especificarse.

En esencia, este es un plan corto para el desarrollo y la implementación. Al compilarlo, generalmente doy una tabla que enumera todas o algunas de las siguientes columnas:

• El nombre de la etapa (sub-etapa).
• Contenido del trabajo (breve descripción, lista de tareas).
• El resultado del trabajo (documentos aprobados, soluciones desarrolladas y presentadas).
• Diseño, trabajo o documentación de informes.
• Responsable (quién realiza este trabajo: cliente, contratista u otra persona). Si ambas partes deben dar un resultado conjunto, se indican los roles.
• Duración (fechas, fechas, inicio del tiempo).

Un ejemplo del contenido de esta sección se da en la tabla a continuación.

9. Sección 6 “Procedimiento para el monitoreo y aceptación del sistema” / p. 2.8 GOST 34.602-89 /

Esta sección describe en detalle el proceso de aceptación del sistema por parte del cliente: qué pruebas deben llevarse a cabo, qué se incluirá en estas pruebas, de acuerdo con qué documentos se probarán, cómo se harán y eliminarán los comentarios.

9.1. Subsección 6.1. "Tipos, composición, volumen y métodos de prueba del sistema y sus componentes" / p. 2.8.1 GOST 34.602-89 /

Por lo general, aquí indico la lista de pruebas y menciono que los métodos de prueba se darán en el documento "Programa y metodología de prueba", que es una descripción de los principales casos de prueba, guiones de prueba.

Detengámonos en los tipos de pruebas. Los tipos de pruebas, su composición, los requisitos para los documentos están establecidos por GOST 34.603-92 “Tecnología de la información. Tipos de pruebas de sistemas automatizados ". Por lo tanto, al desarrollar esta sección y proyecto técnico, asegúrese de consultar esta norma, aquí explicaremos solo los puntos principales.

Tratemos de comprender qué tipo de pruebas son:

1. Las pruebas se dividen en los siguientes tipos:

• Preliminar
• Operación de prueba.
• Aceptación

2. Las pruebas preliminares (y de aceptación parcial) se dividen a su vez en:

• ( ).
• ( ).

¿Por qué las pruebas se dividen en diferentes etapas? En primer lugar, debido a que GOST 34.603-92 no distingue entre aceptación interna y externa, parte de las pruebas pueden llevarse a cabo sin un cliente. En segundo lugar, se describe un proceso de prueba secuencial, parte por parte, y luego todo se integra.

Tratemos de describir el proceso de prueba en palabras simples:

1. Pruebas autónomas preliminares de partes del sistema. Partes del sistema se prueban individualmente si hay varios subsistemas o módulos grandes en la composición. Típicamente, tales pruebas se llevan a cabo de forma autónoma, es decir, sin integración con sistemas adyacentes. Si el sistema es simple, este paso se puede omitir de forma segura.

2. Pruebas autónomas preliminares del sistema en su conjunto.Todo el sistema se prueba en un complejo en modo autónomo, es decir, sin integración con sistemas adyacentes. Las funciones asociadas con los sistemas adyacentes no se prueban. En un caso extremo, se colocan "stubs" (emulación de integración) o la base de datos se rellena previamente con datos que deben provenir de fuentes externas.

3. Pruebas preliminares integrales. El sistema se prueba de manera integrada, es decir, en interacción con sistemas adyacentes. De esta forma, el sistema se transfiere al cliente para la operación de prueba.

4. Operación piloto.MA puede tener lugar en diferentes modos. Lo mejor es la explotación de datos reales, con usuarios reales y con tareas reales. Solo este tipo de prueba asegurará que el sistema esté realmente operativo. Durante la operación de prueba, se eliminan las desventajas.

5. Pruebas de aceptación. Este es el último tipo de verificación. Dime, ¿por qué la operación de prueba después de eliminar todas las deficiencias no entrará sin problemas en la industria? Entonces suele suceder. Pero los tíos altos necesitan ver que el sistema realmente funciona, para "sentirlo". Las pruebas de aceptación están destinadas a ellos, para una alta comisión. Por lo tanto, las pruebas de aceptación difieren de las pruebas preliminares principalmente en el estado de la comisión.

También en este párrafo se indican los documentos en los que se darán los métodos de prueba:

• « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
• « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .

9.2. Subsección 6.2. "Requisitos generales para la aceptación del trabajo por etapas" / p. 2.8.2 GOST 34.602-89 /

En esta sección, generalmente indico:

1. En qué territorio y en qué equipo se realizarán las pruebas: el cliente o el contratista.
2. Una descripción general de cómo se llevarán a cabo las pruebas (por ejemplo, que los documentos serán verificados, la presencia de elementos de la interfaz de usuario, los scripts se resuelven).
3. Listado de participantes.
4. La lista de documentos que elaboran el resultado de la prueba:
   
   
   • Para las pruebas preliminares y de aceptación, este es un informe de prueba que proporciona una lista de verificaciones y sus resultados.
   • Para la operación de prueba: un diario de operaciones de prueba.

10. Sección 7 "Requisitos para la composición y el contenido del trabajo sobre la preparación del objeto de automatización para poner el sistema en funcionamiento" / p. 2.9 GOST 34.602-89 /

El proceso descrito en esta sección a menudo se denomina implementación. Tenga en cuenta que estos trabajos también se dan en la sección 5 "Composición y contenido del trabajo sobre la creación (desarrollo) del sistema" . Pero, en la sección 5, solo se mencionan brevemente, y aquí se proporciona una descripción detallada.

Al preparar un objeto, como regla general, se debe realizar el siguiente trabajo:

1. Reorganización, contratación de nuevo personal, si es necesario.
2. Entrenamiento del personal.
3. Para aplicaciones web: desarrollo de secciones comunes del sitio y acuerdo de usuario (consentimiento para el procesamiento de datos personales).
4. Llenar directorios y otra información de fondo.
5. Transfiera datos del sistema anterior.
6. Implementar sistema en servidores industriales.
7. Configurar la integración con sistemas adyacentes.
8. Configurar un sistema de acceso y crear cuentas.

Algunos de estos puntos deben describirse con gran detalle, especialmente con respecto a la transferencia de datos y el llenado de directorios.

11. Sección 8 “Requisitos de documentación” / p. 2.10 GOST 34.602-89 /

No vale la pena se refiere a los documentos formalmente. Documentos: esto es gestión de proyectos, flujo de trabajo del proyecto. No tendrá todo en su cabeza, y el éxito del proyecto depende de la disponibilidad y calidad de los documentos. Por supuesto, hay documentos "para el peso", y deben tratarse en consecuencia, pero sin un documento en un modo tranquilo y ordenado, el proyecto no puede implementarse.

La documentación del proyecto de automatización de acuerdo con GOST 34 está regulada por los siguientes estándares:

• GOST 34.201-89 Tipos, integridad y designación de documentos al crear sistemas automatizados.
• RD 50-34.698-90 Directrices. Tecnología de la información. Un conjunto de estándares y pautas para sistemas automatizados. Sistemas automatizados. Requisitos para el contenido de los documentos.
• Para los Términos de referencia - GOST 34.602-89, que estamos discutiendo ahora.

El primer estándar (GOST 34.201-89) proporciona una lista y estructura de documentación. En el segundo, RD 50-34.698-90, se indica el contenido de los siguientes documentos:

• Documentos de diseño preliminar y proyectos técnicos.
• Documentos desarrollados en las etapas previas al diseño.
• Documentos organizacionales y administrativos (actos, protocolos, etc.)

11.1 Características de la estructura de documentación.

Al compilar una lista de documentos necesarios, generalmente miran RD 50-34.698-90 y seleccionan los requeridos. Al mismo tiempo, se cometen muchos errores, ya que la documentación tiene una estructura bastante complicada, que se describe en GOST 34.201-89.

Intentemos identificar algunas reglas que ayudarán a compilar una lista de documentos.

1. Cada etapa tiene su propio conjunto de documentación.

Cada etapa tiene su propio conjunto de documentación. Esto es muy importante de entender. No es necesario prescribir el desarrollo de documentos operativos en las etapas de diseño y viceversa. Resulta papel puramente formal, que pasará un tiempo considerable. Y si la "Guía del usuario" hasta el final del desarrollo del sistema, por lo general, nadie se recupera (aunque he conocido tales cifras), entonces la "Descripción de las funciones automatizadas", en la que generalmente se proporcionan los scripts para programadores, se elabora constantemente una vez que se completa el desarrollo. Además, al leer RD 50-34.698-90, uno puede tener la impresión de que algunos documentos tienen contenido superpuesto: esto también se debe al hecho de que los documentos están destinados a diferentes etapas.

Dado que algunos documentos se pueden desarrollar en una u otra etapa, GOST 34.201-89, para evitar la repetición, proporciona por separado, por ejemplo, una lista de documentos que pueden emitirse tanto en la etapa de diseño técnico como en la documentación de trabajo, y por separado, listas de documentos para cada una de estas etapas por separado. Por lo tanto, al compilar una lista de documentos para una de las etapas, debe consultar las listas de documentos en varias secciones del estándar.

Para no confundirme, compilé una hoja de cálculo de Excel en la que, utilizando filtros, puede mostrar de inmediato una lista completa de documentos para una etapa en particular.

2. Los documentos se dividen en temas (partes del proyecto).

GOST 34 contiene documentos que describen soluciones para todo el sistema, así como soporte organizativo, técnico, matemático, de software y de información (hablamos sobre los tipos de soporte anteriores ). En RD 50-34.698-90, estos documentos se dan precisamente con un desglose por partes del proyecto (temas). Siempre debe prestar atención a esto para determinar el propósito del documento.

3. Los documentos se pueden combinar.

GOST 34.201-89 indica directamente en qué casos se incluye un documento en otro. Esto se hace para que no queden documentos degenerados, con una o dos páginas. Si es necesario describir algo, pero el volumen es muy pequeño, es mejor incluir el texto en otro documento. En la mayoría de los casos, hay un documento como "Nota explicativa del diseño técnico", en el que puede agregar secciones.

4. Las estimaciones operativas y de diseño se destacan por separado.

Los compiladores de GOST 34.201-89 en columnas separadas de la tabla con una lista de documentos indicados que pertenecen a las estimaciones operativas y de diseño.

Las estimaciones de diseño incluyen documentos que rigen la construcción y el trabajo eléctrico: estimaciones, planes de adquisición, dibujos y diagramas eléctricos.

Los documentos operativos incluyen los documentos que guían el uso y mantenimiento del sistema: manuales e instrucciones, listas de materiales y datos, documentos que contienen información sobre violaciones durante la operación.

11.2 Características del diseño de la lista de documentos.

Como señaló anteriormente, al describir las etapas de trabajo en la sección 5, “Composición y contenido del trabajo para crear (desarrollar) un sistema” , también se proporciona una lista de documentación. Se proporciona una lista doble de documentos por una razón simple: no es suficiente indicar el nombre del documento, aún es necesario explicar su propósito y proporcionar un breve resumen (por supuesto, para la "Guía del usuario" no tiene sentido indicar el contenido). De lo contrario, no podrá determinar qué importancia tiene un documento en particular en la gestión de proyectos. GOST es un invitado, y en cada proyecto el contenido y la función de los documentos pueden diferir. Además, la lista puede contener documentos que no están regulados por GOST 34, que deben aclararse sin falta.

En las reglas de documentación, generalmente doy una tabla con las siguientes columnas:

• Etapa.
• El nombre del documento.
• Nota: indica el estándar de desarrollo, propósito, resumen y características principales del documento.

11.3 Ejemplo de lista de documentación

Para que un proyecto grande implemente un sistema complejo, se puede requerir una lista bastante grande de documentación. Damos un ejemplo de dicha lista en la tabla a continuación.

12. 9 « » /. 2.11 34.602-89/

Parece ser una sección formal, pero muy útil. Imagine una situación en la que recuerda que durante el desarrollo de TK leyó un artículo y, por alguna razón, necesita encontrarlo, por ejemplo, para aclarar algo o justificar sus decisiones. Pero absolutamente no recuerdas ni su nombre ni dónde estaba contenido. Por lo tanto, cuando uso materiales útiles, asegúrese de incluirlos en la lista. Y en el texto pongo una nota al pie que indica la fuente.

Si hay muchas fuentes, deberían dividirse en subsecciones, por ejemplo:

• Materiales que describen análogos (prototipos) del sistema desarrollado.
• Materiales que describen la idea general del sistema. A menudo, estos documentos se compilan en las etapas previas al diseño, y generalmente se hace referencia a ellos en la sección "Características del objeto de automatización".
• Materiales de desarrollo del proyecto: lista de GOST usados ​​de la serie 34, estándares usados ​​para la gestión de proyectos.
• Materiales relacionados con la implementación del proceso principal: una lista de leyes, estándares, regulaciones internas y órdenes que establecen las reglas para la implementación de procesos automatizados.
• Materiales y normas que contienen requisitos de seguridad general y de información.

Conclusión

Por supuesto, la preparación de los Términos de Referencia de acuerdo con GOST 34 no se puede llamar fácil y simple. Y no porque GOST sea malo, sino que GOST solo te hace pensar en todo el proyecto, pintar todas las pequeñas cosas. Pero un TOR bien escrito es la mitad del éxito del proyecto.

Escriba en los comentarios si considera necesario aclarar o complementar algo. Asegúrese de hacer cambios al artículo.

Lea otros artículos del autor:

• .
• ( ) .
• .