O desenvolvimento de especificações técnicas de acordo com GOST 34 é simples e fácil

Frequentemente você ouve a opinião de que a preparação dos Termos de Referência de acordo com o GOST 34 (TK) não é apenas trabalhosa, mas também extremamente irritante, porque você precisa escrever muitos tipos de água sem sentido. Mas pense bem: institutos de pesquisa inteiros estavam envolvidos no desenvolvimento deste GOST, era um projeto no nível estadual, a experiência de centenas de projetos de automação, projetos complexos foi resumida. Eles poderiam realmente escrever bobagens?

De fato, com uma abordagem competente, o GOST ajuda muito não apenas no desenvolvimento de especificações técnicas, mas também durante a implementação do projeto de automação como um todo (e não apenas nos contratos estaduais, mas também no desenvolvimento comercial). Pessoas alfabetizadas escreveram. Mas, para tirar proveito dos frutos de seu trabalho, é preciso entender um pouco o conceito de não apenas TK, mas também de GOST 34 como um todo.

Neste artigo, analisaremos ponto a ponto todos os requisitos do GOST e tentaremos tornar o desenvolvimento do TK de acordo com o GOST 34 não um fardo, mas uma grande ajuda no projeto.

1. Sobre o que é o artigo?

Frequentemente você ouve a opinião de que a preparação dos Termos de Referência de acordo com o GOST 34 (TK) não é apenas trabalhosa, mas também extremamente irritante, porque você precisa escrever muitos tipos de água sem sentido. Mas pense bem: institutos de pesquisa inteiros estavam envolvidos no desenvolvimento deste GOST, era um projeto no nível estadual, a experiência de centenas de projetos de automação, projetos complexos foi generalizada. Eles poderiam realmente escrever bobagens?

De fato, com uma abordagem competente, o GOST ajuda muito não apenas no desenvolvimento de especificações técnicas, mas também durante a implementação do projeto de automação (e não apenas nos contratos estaduais, mas também no desenvolvimento comercial). Pessoas alfabetizadas escreveram. Mas, para tirar proveito dos frutos de seu trabalho, é preciso entender um pouco o conceito de não apenas TK, mas também de GOST 34 como um todo.

A propósito, o TK não é o primeiro documento que está sendo desenvolvido durante o projeto de automação. Isto é expressamente indicado no parágrafo 1.5. GOST 34.602-89: “A CT na NPP é desenvolvida com base nos dados iniciais, incluindo aqueles contidos na documentação final do estágio“ Pesquisa e justificativa da criação da NPP ”. Para obter mais detalhes, consulte o meu artigo Pesquisa pré-design durante o desenvolvimento de um sistema de informação .

ATENÇÃO: O OBJETIVO DESTE ARTIGO NÃO É SUBSTITUIR GOST E EXPLICAR ALGUMAS SUAS DISPOSIÇÕES.

2. Características características das especificações técnicas de acordo com GOST 34

2.1 Por qual padrão o ToR é compilado?

O nome completo do padrão para TK de acordo com o GOST 34 é o seguinte: GOST 34.602-89 “Tecnologia da Informação (TI). Um conjunto de padrões para sistemas automatizados. Os termos de referência para a criação de um sistema automatizado ".

O padrão em si é impresso em apenas 15 páginas (sim, bastante). O idioma é russo, realmente russo, e não é alienígena no alfabeto cirílico. Ou seja, se você não pensa antecipadamente que nem os textos dos GOSTs, nem as leis federais, nem as dissertações são acessíveis para a compreensão de um mero mortal, é bem possível ler e penetrar, embora muitas vezes não seja a primeira vez.

De fato, o padrão usa muitos termos obscuros. O que, por exemplo, se entende por suporte linguístico? Para esclarecer os conceitos utilizados, deve-se recorrer ao GOST 34.003-90 “Tecnologia da Informação (TI). Um conjunto de padrões para sistemas automatizados. Sistemas automatizados. Termos e definições ".

2.2 Por que você precisa do GOST para os Termos de Referência?

Provavelmente, quando você precisar redigir um novo documento para você, procure um modelo para esse documento na Internet ou solicite a colegas. Portanto, QUALQUER padrão para documentos ou processos é um modelo. Além disso, o modelo simplifica bastante o desenvolvimento do documento: a estrutura e o conteúdo já foram pensados ​​para você. Além disso, esse modelo leva em consideração momentos que você não lembraria.

2.3 Qual o papel dos Termos de Referência no projeto?

De acordo com o parágrafo 1.7 da norma RD 50-682-89, "os termos de referência são o documento principal segundo o qual a criação da UA e a aceitação pelo cliente são realizadas". E este é realmente o documento principal. Ele deve descrever tudo o que é necessário para o desenvolvimento e implementação do sistema.

O TOR estabelece a aparência geral do sistema, a quantidade de trabalho (estrutura de desenvolvimento), bem como o procedimento de desenvolvimento e aceitação. Tudo começa com TK e tudo termina com ele. Este documento é ideal para o seu cliente entender a importância e a complexidade da tarefa e por que ele paga dinheiro.

Além disso, as especificações técnicas são compiladas para o contratado e o cliente, uma vez que o projeto de automação é realizado por equipes de ambos os lados. Em qualquer projeto de TI, há um grande número de atividades organizacionais, cuja implementação é impossível sem a participação ativa do cliente. Explique isso aos clientes em todas as oportunidades, caso contrário, eles têm a impressão de que só precisam pagar dinheiro e se manter em linha reta: os contratados farão tudo. E então o projeto falha e o confronto começa. Em geral, sem uma equipe real, por outro lado, não vale a pena iniciar um projeto.

Não formule TK formalmente. Se você não sabe o que escrever, significa que é muito cedo para desenvolver a TK, você não tem um entendimento do sistema, o próprio processo automatizado, o objeto de automação, ainda não são compreendidos. Você deve elaborar um conceito do sistema , falamos sobre isso no início do artigo.

2.4 Qual a idade dos GOST 34.602-89 e existem padrões mais recentes?

Não é tão desatualizado. Eu quase não consegui encontrar nada que não fosse essencial. E nenhum dos que afirmam que o GOST 34 é obsoleto não pode dar um único exemplo (provavelmente não tinha as qualificações para lê-lo?) O fato é que o GOST descreve uma abordagem geral do projeto de automação, não fala sobre programação, GOST 34 não é sobre isso.

Bem, se falamos de comparação com outros padrões, não há nada de especial para comparar. O GOST 34 fornece uma visão tão ampla do projeto de automação que outros padrões não são adequados para a sola (na minha opinião). Sim, eles são mais simples (portanto, mais populares), mas a profundidade não é a mesma. Aqui está uma lista de padrões com os quais você deve se familiarizar ao desenvolver seus próprios padrões para um projeto de automação:

• IEEE 830-1998. Metodologia para compilar especificações para requisitos de software.
• GOST R ISO / IEC 12207-2010. Tecnologia da informação. Engenharia de sistemas e software. Processos de ciclo de vida de software.
• ISO / IEC / IEEE 29148-2011. Engenharia de sistemas e software - Processos do ciclo de vida - Engenharia de requisitos.
• GOST R 54869-2011. Gerenciamento de projetos. Requisitos de gerenciamento de projetos.
• Poço e estado padrão especificações 34 séries.

3. Princípios gerais para a preparação de especificações técnicas de acordo com GOST 34

3.1 Qual especialista deve elaborar os Termos de Referência de acordo com o GOST 34?

Frequentemente, os desenvolvedores juram muito ao elaborar TK de acordo com o GOST 34. Por que? Sim, porque não é da conta de programadores. Termos de referência de acordo com GOST 34 geralmente não podem ser mostrados aos programadores. Existem documentos técnicos do projeto para isso. Termos de Referência - um documento que é acordado com o cliente, que está constantemente em cima da mesa no gerente de projetos. TK responde a duas perguntas: O que o sistema deve fazer e COMO deve ser criado. O projeto técnico responde à pergunta: COMO os requisitos do ToR devem ser atendidos. Por exemplo, no TK você prescreve que deve haver autorização por login e senha e no TP fornece layouts da interface, scripts e estrutura do banco de dados. Por que há uma divisão em diferentes estágios e por que você não deve executar imediatamente a tarefa dos programadores, veja em meus artigos os Segredos do design bem-sucedido de IP (sistema de informação) no exemplo da construção de um hospital e pesquisa pré-design ao desenvolver um sistema de informação .

Os termos de referência devem ser feitos por um analista de negócios, porque ele é um "tradutor" entre o cliente e a equipe de desenvolvimento. A tarefa de um analista de negócios é entender o que o cliente precisa e expressá-lo de uma maneira que seja clara para a equipe. E expresse-o na forma de especificações técnicas. Além disso, um analista de negócios é obrigado não apenas a ouvir o cliente e seus funcionários, mas a descobrir o que eles não disseram (e isso geralmente é superior a 50%). Portanto, o analista deve ter um bom conhecimento dos processos que estão sendo automatizados e, devido ao seu conhecimento, preencher as lacunas que permaneceram nos resultados da pesquisa.

3.2 Qual lado deve ser o Termos de Referência?

Basicamente, os Termos de Referência são compilados pelo contratado? Porque

Não apenas porque é recomendado no Apêndice 1 ao GOST 34-602-89. De fato, o cliente, em regra, não possui os especialistas apropriados. Mas a TK é necessariamente desenvolvida e acordada pelo cliente. E aqui é necessário garantir que o acordo não seja formal. Eu sempre tento insistir que, juntamente com o cliente, analisemos cada item em detalhes. Seu objetivo é envolver o cliente no projeto. Caso contrário, ele não formará suas expectativas em relação ao sistema, o que significa que, em primeiro lugar, ele ficará insatisfeito com qualquer resultado e, em segundo lugar, ele não será capaz de executar as medidas organizacionais necessárias.

3.3 Quão longe você pode ir do GOST 34?

Qualquer modelo também tem uma desvantagem significativa - este é um modelo. Ou seja, um passo para a direita e para a esquerda é a medida mais alta de proteção social (como a pena de morte era chamada anteriormente).

De fato, não é assim. Qualquer padrão de processo (isto é, um padrão não para lingüiça, mas para alguma atividade) fornece apenas indicações gerais, descrição. Foi criado para ajudar a não esquecer algo importante, transmitir-lhe a experiência de gerações e não deixá-lo atrás das bandeiras.

Não acredita? Em seguida, leia a cláusula 2.2 do GOST 34.602-89 (a propósito, os números após o hífen são o ano de publicação do padrão ou de sua edição): "Dependendo do tipo, finalidade, recursos específicos do objeto de automação e das condições de funcionamento do sistema, é permitido criar seções de TK na forma de aplicativos, introduzir adicionais, excluir ou mesclar subseções de TK ". Também no parágrafo 1.2. RD 34.698-90 declara: “O conteúdo dos documentos é comum a todos os tipos de AS e, se necessário, pode ser complementado pelo desenvolvedor dos documentos, dependendo dos recursos do AS criado. É permitido incluir seções e informações adicionais nos documentos, para combinar e excluir seções. ”

Em geral, se você só pode citar frases gerais, para tudo de bom, contra tudo de ruim, não escreva nada. Caso contrário, o especialista que ler o documento, tendo cumprido essas passagens, deixará de levar o documento a sério, e pontos importantes serão perdidos. Não faça da leitura de um documento uma tortura!

3.4 Por que o TK de acordo com o GOST 34 descreve tantos requisitos que não estão diretamente relacionados às funções do sistema?

De fato, em um TOR de 30 páginas, apenas 7 a 10 páginas podem ser dedicadas a funções. Isto tem uma explicação. O fato é que os desenvolvedores do GOST 34 analisaram o projeto de automação de uma maneira completamente diferente da nossa. E eles pareciam mais corretamente, de forma mais abrangente.

Em primeiro lugar , na primeira metade do TK, informações gerais sobre o sistema e requisitos gerais não são apenas apresentadas. Precisamos entender por que o sistema é criado, quais processos ele automatiza, o que precisa ser feito para que o sistema funcione, que tipo de sistema o sistema possui. Parece coisas comuns, mas sem elas, os membros da equipe entenderão diferentemente o objetivo do trabalho e os meios para alcançá-lo. É muito importante garantir que todos os participantes estejam sintonizados na mesma onda, e não como um cisne, câncer e lúcio.

Em segundo lugar , os compiladores do GOST 34 viam o sistema principalmente como pessoas e depois como um complexo de hardware e software. É assim que o GOST 34.003-90 define um sistema automatizado: "Um sistema que consiste em pessoal e um conjunto de ferramentas de automação para suas atividades que implementa a tecnologia da informação para executar funções estabelecidas". Assim, um sistema de informação é um pessoal treinado, complexo de software e hardware, todos juntos. De fato, retire os computadores dos contadores, eles são difíceis, mas serão capazes de fazer seu trabalho, embora com registros em papel. Mas 1C não funcionará independentemente sem um contador. Daí as muitas seções do TK sobre medidas organizacionais. Como se costuma dizer, um sistema de TI é 20% de TI, todo o resto são medidas organizacionais. Ou seja, TK é um documento que explica tudo o que é necessário para a implementação do sistema, de A a Z.

Em terceiro lugar , preste atenção ao nome do GOST 34.602-89: "Termos de Referência para a criação de um sistema automatizado". TK não é para o sistema, mas para a criação do sistema. Qual a diferença? A diferença é que o ToR estabelece não apenas os requisitos para o próprio sistema, mas também regula o processo de sua criação, ou seja, o documento contém requisitos para todas as medidas organizacionais, cuja implementação é necessária para alcançar o resultado. De fato, durante a implementação de um projeto de automação, muitas vezes é necessário reestruturar vários processos, treinar pessoal e preparar o hardware.

Quarto , o ToR é um documento pelo qual você pode marcar: levamos em conta esse requisito ou não. Talvez você coloque 10 carrapatos de forma limpa automaticamente, porque essas serão soluções padrão. Mas a marca de seleção número 11 revelará um problema muito grande e, se você pular esse problema agora, ele aparecerá em algum lugar do processo de implementação, quando todos os prazos e orçamentos já estiverem definidos.

Quinto , como dissemos acima, subseções desnecessárias podem ser excluídas, isso é permitido. Por exemplo, se você tem certeza de que nada pode ser patenteado em seus projetos, por que trazer requisitos de pureza de patente? Este não é o caso quando não há água e nenhum xarope sem água.

3.5 Por que as diferentes seções dizem a mesma coisa?

De fato, em TK existem subseções que repetem amplamente o conteúdo de outras subseções. Por exemplo, existem requisitos para suporte organizacional e para o número e qualificações do pessoal. Nos dois parágrafos, estamos falando de funcionários.Mas, no primeiro caso, fornecemos informações sobre a estrutura organizacional: quais departamentos devem ser, como a interação com outros departamentos deve ser estabelecida. Concordo que isso não é o mesmo que simplesmente os requisitos para o número e qualificações do pessoal.

Mas, para sistemas pequenos, apenas um ou dois administradores e alguns moderadores são necessários. Nesse caso, simplesmente não temos nada a descrever em duas seções inteiras. Em seguida, omita algumas seções e, na outra, forneça uma declaração completa dos requisitos.

3.6 Preciso emitir o TK de maneira de qualidade?

Embora os requisitos para o design do TK sejam dados no parágrafo 3 do GOST 34.602-89, digamos algumas palavras sobre esse aspecto.

Claro, o conteúdo principal. Mas, primeiro, eles são recebidos com roupas e, segundo, é difícil ler texto analfabeto com uma fonte de salto. Os leitores se distrairão com o design de baixa qualidade e será mais difícil para eles se aprofundarem no conteúdo. Portanto, conteúdo técnico estrito e terminologia limitada são aceitos em documentos técnicos, sem expressões coloridas: o leitor deve se concentrar na essência e não nas curvas artísticas.

Aqui estão algumas sugestões para a execução de documentos grandes, como o TK.

Em primeiro lugar, é imperativo usar estilos em um documento grande e, exceto para sublinhar ou realçar dentro de um parágrafo, não altere as configurações de fonte e parágrafo para apenas um fragmento. Se você mudar, então o estilo.

Em segundo lugar , não devemos esquecer elementos obrigatórios como um índice de preenchimento automático, uma lista de termos e abreviações (bem, não há alegria em adivinhar o que isso significa com uma ou outra abreviação), página de título. Também é aconselhável fornecer uma lista de versões do documento, uma lista de alterações: é muito fácil rastrear posteriormente quais datas uma versão específica foi enviada.

Quarto, cada requisito individual deve ser definido em um parágrafo numerado separado. Se houver 2-3 requisitos em um fragmento, apenas o primeiro será lido e nosso cérebro pulará o resto. TK é um documento no qual, na frente de cada parágrafo, você pode verificar se o requisito foi atendido ou não.

Quinto , não economize na colocação de links. Às vezes, você lê um parágrafo em que alguma função ou requisito é mencionada e não entende que isso é do mesmo documento ou de outro. Se a partir disso, em que seção. Portanto, tente consultar outras seções se elas forem mencionadas no texto atual. Naturalmente, os links devem ser automáticos.

Observe que, de acordo com regras estritas, a declaração de trabalho é elaborada sem moldura (isso é indicado no parágrafo 3), mas o restante dos documentos com moldura. Isso é estabelecido no GOST 24.301-80 “Sistema de documentação técnica para ACS. Requisitos gerais para a implementação de documentos de texto (como emendados nº 1, 2). ” Esta norma estabelece as regras para a execução de todos os documentos, exceto TK e documentos criados nos estágios de pré-design. Embora eu pessoalmente não goste da moldura em nenhum documento.

4. Seção 1. “Informações gerais” / p. 2.3 GOST 34.602-89 /

A maioria das informações apresentadas nesta seção não precisa de comentários, portanto, focaremos apenas algumas subseções.

Portanto, por “lista de documentos com base nos quais o sistema é criado”, entendemos leis, ordens ou acordos. Além disso, esse documento pode ser outro TK, se desenvolvermos o TK para o subsistema. Em geral, existem várias seções no ToR que contêm uma lista de documentos e é preciso entender muito claramente as diferenças entre a finalidade dessas partes da tarefa técnica.

Na subseção "Procedimento para processar e apresentar ao cliente os resultados do trabalho sobre a criação do sistema (suas partes), sobre a fabricação e o comissionamento de ferramentas individuais (hardware, software, informações) e complexos de sistemas de software e hardware (software e metodológicos)" fornece informações gerais sobre a aceitação do trabalho. Por exemplo, o fato de transferirmos a documentação e realizar uma série de testes do sistema. Aqui mencionamos apenas o procedimento para transferir os resultados do trabalho e, abaixo, em outras seções, este tópico é divulgado em detalhes.

5. Seção 2. “Propósito e objetivos de criar (desenvolver) o sistema” / p. 2.4 GOST 34.602-89 /

Aqui precisamos entender a diferença entre o propósito e o objetivo de criar um sistema. Muitas vezes, esses conceitos são confusos. Por exemplo, eles escrevem que o objetivo do sistema é a automação da sua conta pessoal e o objetivo é criar uma conta pessoal. Óleo é óleo. Em alguns casos, esses conceitos realmente coincidem, depois escreva apenas o compromisso.

Com esse objetivo, tudo fica claro: fornecemos exatamente o (s) tipo (s) de atividade automatizada. Por exemplo, se criarmos um sistema para contabilidade de produção, vale a pena citar tipos automatizados de contabilidade, operações automatizadas e objetos cuja automação é suposta.

Com o objetivo, tudo é diferente. O objetivo é para o qual estamos planejando um projeto. Você pode chamar isso de objetivos de negócios. Destaco os seguintes objetivos possíveis para projetos de automação:

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

O GOST também afirma que é necessário fornecer critérios para avaliar a consecução do objetivo, ou seja, indicadores específicos. Por exemplo, temos 3 pessoas que coletam um total de 20 pedidos por dia. E após a implementação do sistema, queremos que todos coletem 20 pedidos, ou seja, três vezes mais. Se tais indicadores forem conhecidos, apresentamos-os neste parágrafo.

6. Seção 3. "Características do objeto de automação" / p. 2.5 GOST 34.602-89 /

Uma seção muito importante e frequentemente descrita formalmente. Embora, na minha opinião, essa seja a seção mais importante do TK, sem ela simplesmente não entendemos sobre o que o sistema está sendo criado.

Vamos primeiro definir o que é um "objeto de automação". Se automatizarmos um armazém ou uma fábrica, um departamento de contabilidade, tudo ficará claro. E se, por exemplo, criarmos uma nova rede social, o objeto, por assim dizer, não existe. Mas, de fato, é mais provável que um objeto signifique processos automatizados. E mesmo no caso de um armazém, não automatizamos o próprio armazém (como o armazenamento de caixas pode ser automatizado?), Mas o processo é processado.

Se você executar esta seção formalmente, será muito semelhante à descrição do objetivo do sistema, e outro lago de água aparecerá no TOR, mas não ficará claro o que o sistema deve fazer.

Esta seção deve incluir:

1. Descrição do cliente: atividades do cliente, número de filiais, funcionários. Obviamente, você precisa caracterizar o cliente na parte diretamente relacionada ao sistema que está sendo criado.
2. Informações sobre usuários do sistema: tipos de usuários, qual papel o sistema desempenha para diferentes usuários.
3. Descrição de objetos automatizados. Por exemplo, se automatizarmos um armazém, devemos descrever quanto é, quantas passarelas, qual largura de passarelas, quais racks, se existe uma área de montagem separada, quantas pessoas trabalham e quais responsabilidades elas têm. Então entenderemos que estamos automatizando especificamente como deve ser o processo do armazém e que equipamento está sendo usado.
4. Descrição de processos automatizados. Obviamente, não é necessário descrever os processos em detalhes no TK. Mas cenários comuns são necessários. Só então fica claro para nós quais funções devem estar disponíveis.
5. Uma lista de documentos que fornecem uma descrição detalhada do objeto de automação.

Eu tive casos em que a descrição desta seção levou mais da metade do desenvolvimento do TK, porque leva muito tempo e meticulosamente para coletar várias informações, analisá-las e descrevê-las cuidadosamente.

7. Seção 4 “Requisitos do sistema”

No TK, de acordo com o GOST 34, há uma seção gigantesca: seção 4 “Requisitos do sistema”. Possui três subseções:

• Requisitos para o sistema como um todo.
• Requisitos para as funções (tarefas) executadas pelo sistema.
• Requisitos para os tipos de garantias.

Consideraremos essas subseções separadamente.

7.1 Subseção 4.1. "Requisitos para o sistema como um todo" / p. 2.6.1 GOST 34.602-89 /

Na subseção 4.1 “Requisitos para o sistema como um todo”, são descritos os chamados requisitos gerais não funcionais que descrevem o sistema que está sendo criado sob diferentes ângulos.

A propósito, como já mencionamos, as subseções podem ser adicionadas e omitidas. Portanto, a numeração fornecida aqui é aproximada, serve para orientação no artigo.

7.1.1 Cláusula 4.1.1. "Requisitos para a estrutura e funcionamento do sistema" / p. 2.6.1.1 GOST 34.602-89 /

Este item é bastante extenso, deve fornecer uma idéia geral da arquitetura do sistema. Analisaremos esses requisitos com mais detalhes.

1. A lista de subsistemas, seus objetivos e principais características, requisitos para o número de níveis hierárquicos e o grau de centralização do sistema.

Neste parágrafo, costumo citar:

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

Se você estiver planejando uma arquitetura de microsserviço, faz sentido listar e descrever a funcionalidade dos serviços.

Para maior clareza, é desejável anexar um diagrama estrutural do sistema com a designação de suas partes e sistemas relacionados, conforme mostrado nos exemplos abaixo.



... mais ou menos:



2. Requisitos para métodos de comunicação e meios para troca de informações entre componentes do sistema.

3. Requisitos para as características do relacionamento do sistema criado com sistemas relacionados, requisitos para sua compatibilidade, incluindo instruções sobre como trocar informações (automaticamente, envio de documentos por telefone, etc.)

Em condições modernas, a maioria das interações é realizada usando o protocolo HTTP (S). Parece que, além disso, não há nada para escrever. No entanto, esses itens podem ser tão grandes que são enviados ao aplicativo. Eles devem fornecer as seguintes informações:

• uma lista de informações transmitidas, pelo menos uma descrição geral, para entender geralmente por que estamos nos integrando a um sistema específico;
• descrição do protocolo (ou links de descrição), especialmente no caso de conexão do dispositivo;
• estrutura de rede local;
• taxa de dados necessária;
• uso de Internet móvel ou Wi-Fi;
• Descrição de métodos de transmissão de dados não automatizados.

4. Requisitos para os modos de operação do sistema.
Os modos de operação podem ter várias classificações:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• Visibilidade do aplicativo: caixa de diálogo ou plano de fundo
• sobre o possível impacto no sistema: regular, treinamento, modos de teste.

5. Requisitos para diagnosticar o sistema.

Os requisitos para diagnóstico contínuo ou periódico devem ser feitos para sistemas baseados na arquitetura de microsserviços (espaçados), sistemas que incluem equipamentos: sensores, sistemas de controle, terminais, etc. Obviamente, se apenas um software for desenvolvido em um único servidor, esses requisitos serão supérfluos: você descobrirá se algo para de funcionar.

6. Perspectivas para o desenvolvimento, modernização do sistema.

Parece, quais são as perspectivas para o desenvolvimento do sistema na subseção “Requisitos para a estrutura e funcionamento do sistema”? Mas imagine, agora você está criando uma versão alfa para 100 pessoas e, em um ano, deseja obter mais de um milhão de usuários trabalhando simultaneamente em diferentes partes do mundo. Então, no estágio de criação, você precisa fornecer imediatamente uma arquitetura de cluster.

Ou agora você está trabalhando em uma organização e em seis meses haverá várias, o que significa que você deve prever a possibilidade de expansão.

Em outras palavras, nesta seção, você pode anotar todas as perspectivas de modernização, mas observe especialmente as que afetarão definitivamente a arquitetura.

7.1.2 Cláusula 4.1.2. "Requisitos para o número e qualificações do pessoal" / p. 2.6.1.2 GOST 34.602-89 /

Como mencionamos anteriormente, qualquer sistema automatizado consiste em "pessoal e um conjunto de ferramentas de automação para suas atividades". Portanto, os requisitos para o pessoal e suas qualificações são indicados no TOR.

Se você automatizar uma linha de produção específica, saberá o número de funcionários. Mas, em muitos casos, isso depende da quantidade de trabalho realizado. Portanto, indique os cargos, horário de trabalho, descrição das atividades (para atribuição de direitos de acesso) e qualificações aproximadas. No mínimo, você precisa de um administrador e operador do sistema, geralmente um moderador. É possível que você precise fornecer vários tipos de operadores com diferentes níveis de acesso.

É claro que os requisitos para o pessoal são frequentemente definidos pelo cliente, por que trazê-los? Mas, em primeiro lugar, já dissemos que as especificações técnicas são elaboradas para os dois lados e, em segundo lugar, o contratado será protegido: a condição de seleção da equipe não é atendida, o que o cliente deseja se o sistema não for implementado?

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

Nesta subseção, muitas vezes está escrito o que você gosta, pois a lista de possíveis indicadores está ausente no texto GOST e é quase impossível encontrá-los em fontes abertas. Observe que o "grau de adaptabilidade", "limites de modernização" e "características de probabilidade-tempo" fornecidas no GOST são, em primeiro lugar, indicados para o ACS (sistema de controle automatizado) e, em segundo lugar, são bastante difíceis de medir. Assim, essas características nem sempre são adequadas.

No entanto, no próprio texto, “indicadores de nomeação” são definidos como “parâmetros que caracterizam o grau de conformidade do sistema com sua finalidade”. Nos sistemas modernos de computadores, os valores quantitativos que caracterizam esse sistema referem-se principalmente ao desempenho e ao volume de armazenamento de dados.

Os indicadores de destino incluem:

• o número de usuários trabalhando simultaneamente no sistema;
• o número de solicitações executadas simultaneamente ao servidor;
• o número de transações (registradas) por unidade de tempo das transações;
• tempo de resposta para um número diferente de solicitações únicas e usuários que trabalham, para uma quantidade diferente de dados processados ​​(especialmente ao pesquisar e agregar relatórios);
• quantidade de dados armazenados (em particular, imagens e vídeos);
• tempo de conexão para poder adicional de computação ao atingir a carga máxima;
• tempo de conexão de capacidades adicionais com um aumento significativo no volume de dados armazenados.

Todas essas características afetam a escolha do hardware do servidor, servidor de aplicativos e arquitetura DBMS, DBMS relacional ou não relacional, microsserviços, etc.

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

O texto do GOST descreve em detalhes suficientes o que precisa ser indicado nos requisitos de confiabilidade. No entanto, para entender a abordagem para garantir a confiabilidade inerente a esse padrão, você deve estudar os GOSTs da série 27. Para começar, familiarize-se com a terminologia: isso será suficiente para entender o próprio conceito de confiabilidade, como é medido e como é fornecido. Portanto, consulte GOST 27.002-89. “Confiabilidade em tecnologia. Conceitos básicos. Termos e definições ".

O conceito básico que pode ser aplicado aos sistemas automatizados é o fator de disponibilidade: 99%, 99,9%, 99,99%. Cada número de "noves" é fornecido por determinadas medidas.

Quais soluções técnicas esses requisitos podem afetar? Esse é o número de capacidades de reserva (elas variam), a disponibilidade de pessoal técnico em terra e o uso não apenas de fontes de alimentação ininterruptas, mas também de geradores a diesel, bem como a conexão de duas fontes independentes (conexão às redes de energia de acordo com a categoria de confiabilidade I ou II).

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

Esta subseção descreve os requisitos de segurança para o manuseio de equipamentos (instalação, comissionamento e operação). Agora, esses requisitos são chamados de proteção ao trabalho e estão contidos nos GOSTs da 12ª série (SSBT - o sistema de normas de segurança do trabalho). No TK, basta fornecer uma lista dessas seções, novamente, se alguém se envolver seriamente em segurança.

7.1.6 Cláusula 4.1.6. "Requisitos para ergonomia e estética técnica" / p. 2.6.1.6 GOST 34.602-89 /

Fornecemos os requisitos do GOST: "Os requisitos de ergonomia e estética técnica incluem indicadores de CA que especificam a qualidade necessária da interação humana com a máquina e o conforto das condições de trabalho da equipe".

Geralmente neste parágrafo está escrito que o sistema deve ter uma interface conveniente e bonita. Mas como medir a conveniência e a beleza? Portanto, omitimos esse requisito ou dizemos que a interface corresponderá a um projeto de design desenvolvido posteriormente, ou forneceremos padrões, por exemplo, as chamadas "diretrizes" para o desenvolvimento de aplicativos móveis: Design de material para Android e Diretrizes de interface humana para iOS.

Você também pode fornecer o número máximo de transições (cliques) ao implementar determinadas funções que são especialmente importantes para nós, a velocidade média da pesquisa de dados etc.

7.1.7 Cláusula 4.1.7. "Requisitos de transportabilidade para alto-falantes móveis" / p. 2.6.1.7 GOST 34.602-89 /

Diga algum requisito obsoleto. Agora, os servidores em caminhões, como computadores grandes antes, não são transportados. No entanto, imagine que você tenha algum tipo de superproteção, um circuito interno por trás da DMZ e ... a necessidade de trabalho remoto via laptop. Sim, uma VPN está configurada a qualquer momento, mas é melhor se estiver refletida no Guia de Administração e a possibilidade em si for fornecida pela configuração de rede.

7.1.8 Cláusula 4.1.8. "Requisitos para operação, manutenção, reparo e armazenamento" / p. 2.6.1.8 GOST 34.602-89 /

Esses requisitos estão relacionados à manutenção de um complexo de meios técnicos (servidores, firewalls, comutadores, estações de trabalho etc.) Se o equipamento precisar de manutenção especial, é necessário descrevê-lo nesta seção. Por exemplo, você tem um dispositivo especial que precisa ser calibrado uma vez por mês.

7.1.9 Cláusula 4.1.9. "Requisitos para a proteção de informações contra acesso não autorizado" / p. 2.6.1.9 GOST 34.602-89 /

O tópico de proteção de informações contra acesso não autorizado é bastante extenso, assim como as medidas para garantir isso. Obviamente, se estamos falando de acesso à conta pessoal do site e ao painel de administração deste site, existem requisitos suficientes para autorização, complexidade de senha e modelo de acesso a funções. Mas se um sistema financeiro ou um sistema for criado para as necessidades do estado, requisitos especiais aparecerão.

É importante observar que nesta subseção são fornecidas não apenas as medidas que precisam ser aplicadas durante o desenvolvimento do sistema, mas também sua operação.

Portanto, para sistemas financeiros, você deve usar o "Padrão de segurança de dados do setor de cartões de pagamento" (PCI DSS). Para sistemas em que os dados pessoais são armazenados, - Decreto do Governo da Federação Russa de 11.11.2012, nº 1119, “Aprovação dos requisitos para a proteção de dados pessoais durante o processamento em sistemas de informação de dados pessoais”. Pode haver outros padrões na sua área de assunto.

Em geral, o equipamento de proteção pode ser dividido nos seguintes tipos:

1. Meios fornecidos pelo produto de software criado.
2. Medidas fornecidas pelo administrador do sistema.
3. Medidas de proteção física.
4. Medidas organizacionais gerais.
5. Medidas tomadas durante o processo de desenvolvimento de software.

1. Medidas de segurança fornecidas pelo produto de software criado:

• Requisito de senha para usuários, especialmente para usuários com a função de administrador.
• Implementando um modelo de acesso baseado em função.
• O requisito de usar chaves de assinatura eletrônica para executar operações críticas.
• Remoção de componentes de software responsáveis ​​pela interação com sistemas externos na DMZ.
• Fornecendo registro de eventos e ações do usuário.

2. Medidas fornecidas pelo administrador do sistema:

• O uso de firewalls (firewalls).
• Documentar e monitorar os serviços e protocolos utilizados.
• Configuração da zona desmilitarizada (DMZ).
• Monitorando a implementação das regras de uso de laptops: conectando-se a uma rede interna, usando firewalls.
• Desativando contas padrão antes de conectar equipamentos e sistemas à rede.
• Configurar dispositivos de acesso sem fio: defina senhas e altere as configurações de acesso padrão.
• Instale atualizações que resolvam as vulnerabilidades identificadas de hardware e software.
• Fornecendo segurança para acesso remoto ao sistema (por exemplo, usando uma VPN).
• Instalação, atualização e monitoramento de software antivírus.
• Execute verificações e verificações periódicas na rede após fazer alterações importantes.
• Designação de uma conta exclusiva para cada funcionário, verificações periódicas da presença de contas excluídas de funcionários demitidos, alteração de senhas. Emissão e contabilidade de tokens de assinatura eletrônica.
• Configure restrições de acesso ao banco de dados.
• Controle de sincronização de horário em todos os servidores e estações de trabalho (para garantir a correção do tempo registrado nos logs de eventos).
• Configure logs de eventos.
• Inventário periódico de pontos de acesso sem fio e outro software instalado no equipamento.

3. Medidas de proteção física:

• Acesso restrito a salas críticas.
• Desconecte os conectores de rede em locais públicos.
• Instalação de câmeras de CFTV para instalações críticas.

4. Medidas organizacionais gerais:

• Adoção de uma política de segurança e treinamento periódico de pessoal em regras de segurança da informação.
• Implemente procedimentos de resposta a incidentes de segurança.
• Verificação de tela ou relatórios de dados confidenciais.
• Emissão de crachás para todos os visitantes, acompanhando os visitantes em áreas críticas.
• Revisão abrangente de funcionários contratados.
• Fornecer segurança por parte das organizações fornecedoras de serviços relacionados a software e hardware.

5. Medidas tomadas durante o processo de desenvolvimento de software:

• Controle de pessoas responsáveis ​​por fazer alterações no código do programa, verificando se o código está em conformidade com as regras de segurança da informação (controle de estouro de buffer, manuseio correto de erros, verificação de scripts cruzados, erros de mecanismo de acesso etc.)
• O uso de criptografia forte.
• Aplicação de regras de segurança para aplicativos da web públicos.
• Desenvolva um procedimento de cancelamento para cada alteração.
• Documentação de alterações.

7.1.10 Cláusula 4.1.10. "Requisitos para a segurança da informação em caso de acidente" / p. 2.6.1.10 GOST 34.602-89 /

Esta seção fornece uma lista de possíveis acidentes e falhas nas quais a segurança das informações deve ser garantida. Tais eventos podem incluir:

• perda de nutrição;
• falha no servidor;
• falha do dispositivo de armazenamento (disco rígido).

7.1.11 Cláusula 4.1.11. "Requisitos para proteção contra a influência de influências externas" / p. 2.6.1.11 GOST 34.602-89 /

Esta seção será útil se servidores, estações de trabalho e outros equipamentos estiverem localizados em um armazém frio ou, inversamente, em instalações industriais com temperaturas elevadas, em locais empoeirados ou em locais com alta umidade. Também às vezes vale a pena considerar vibração, radiação ou outras influências.

7.1.12 Subseção 4.1.12. "Requisitos para pureza de patente" / p. 2.6.1.12 GOST 34.602-89 /

Se você suspeitar que usará qualquer tecnologia patenteada em outros países (ou em nosso país) e o detentor da patente poderá entrar com uma ação contra o proprietário do sistema, este parágrafo indica a lista de países nos quais você deseja verificar para pureza de patente.

7.1.13 Cláusula 4.1.13. "Requisitos para padronização e unificação" / p. 2.6.1.13 GOST 34.602-89 /

Este item também raramente está contido nos Termos de Referência com relação ao software especificamente. Indica os requisitos para o uso de tecnologias específicas e formas padronizadas de documentos e classificadores.

Essa descrição é especialmente importante se você tiver requisitos específicos para estruturas, plugins, protocolos, dispositivos, algoritmos matemáticos, software de terceiros, etc. Não se esqueça de indicar em qual parte e para qual finalidade essas ferramentas devem ser usadas.

Além disso, às vezes nos sistemas de algumas classes, é habitual usar certos protocolos de troca de dados. Por exemplo, os padrões OCG são usados ​​para trocar dados entre sistemas de informações geográficas e o OCPP é usado para controlar estações de carregamento de veículos elétricos.

7.1.14 Cláusula 4.1.14. “Requisitos adicionais” / p. 2.6.1.14 GOST 34.602-89 /

Este parágrafo deve ser encontrado no texto do GOST. Ele não precisa de comentários.

7.2 Subseção 4.2. “Requisitos para as funções (tarefas) executadas pelo sistema” / p. 2.6.2 GOST 34.602-89 /

Esta seção é central para os sistemas de computadores modernos. Na verdade, o sistema é criado para o desempenho de certas funções. Frequentemente, o TK, criado com base em padrões estrangeiros e geralmente sem padrões, contém apenas esta seção.

7.2.1 Estrutura de descrição funcional

Primeiro, consideramos a estrutura dos requisitos funcionais do sistema: subsistema - conjunto de funções - função - tarefa. Uma tarefa faz parte de uma função e pode ser descrita como uma função separada. Por exemplo, para a função de login, introduzimos uma senha como uma das tarefas. E podemos descrever o procedimento de entrada de senha como uma função separada: verificação de correção, recuperação de senha, exibição de avisos etc. Um complexo é o que une funções. Por exemplo, “Contabilizando informações básicas”, “Realizando um leilão” etc. O complexo possui duas ou mais funções.

Se o seu sistema consiste em vários subsistemas, basicamente o TK deve fornecer uma lista de funções para os subsistemas e já descrever detalhadamente os requisitos funcionais para os subsistemas no TK individual dos subsistemas (eles agora são chamados CTZ agora - uma tarefa técnica privada).

7.2.2 Tipos de funções em termos de implementação

De fato, todas as funções (ou suas tarefas; várias tarefas podem estar presentes em uma função ao mesmo tempo) podem ser divididas nos seguintes tipos:

• Inserindo informações. Às vezes referido como "informações contábeis".
• Saída de informação.
• Processamento automático de informações.

7.2.3 Tipos de funções em termos de seu papel

As funções podem ser gerais e especiais. Funções comuns, por exemplo, incluem trabalhar com listas de objetos, trabalhar com um cartão de objeto e trabalhar com um mapa interativo. Essas funções podem ser aplicadas a todas as funções especiais ou partes de funções especiais.

7.2.4 Requisito, não script

Não esqueça que o ToR contém requisitos para o sistema e o processo de sua criação. Não scripts. TK responde à pergunta O QUE O sistema deve fazer. Para a pergunta COMO o projeto técnico responde. Se você começar a descrever em detalhes a implementação técnica, mergulhe nos detalhes e deixe de fornecer uma lista completa de requisitos: nosso cérebro não pode trabalhar simultaneamente em modos de ampla cobertura e consideração de detalhes.

A estrutura das funções do TOR e do projeto técnico pode diferir bastante: em um cenário, várias funções podem ser implementadas e vice-versa.

7.2.5 Requisitos funcionais

Aqui estão algumas recomendações sobre como elaborar uma descrição das funções:

1. Os requisitos para funções e tarefas geralmente devem ser feitos no aplicativo. Assim, o documento é dividido organicamente em partes não funcionais e funcionais. Além disso, o aplicativo sempre pode ser impresso e visualizado separadamente.
2. Evite parágrafos grandes. É melhor que os requisitos sejam divididos em parágrafos e parágrafos: é mais fácil percebê-los e controlar sua implementação (marque as caixas). Se uma lista de requisitos ou informações for fornecida, deixe que seja fornecida por uma lista numerada ou com marcadores.
3. Para funções cujo objetivo não é óbvio em seu nome, é necessário indicar o objetivo e o problema a ser resolvido. Caso contrário, até o compilador TK corre o risco de esquecer por que ele descreveu essa ou aquela funcionalidade.

7.2.6 Função Descrição Exemplo

5.6 Matrícula de um veículo no Sistema

Os seguintes requisitos são apresentados:

1) O sistema deve permitir que as seguintes informações gerais sejam levadas em consideração:

• marca de registro estadual (GRNZ);
• Nome do proprietário;
• endereço do proprietário;
• Dados do serviço de aquisição de dados do veículo (ver secção 3.3, apêndice B);
• nota.

2) O sistema deve permitir levar em consideração as seguintes informações relacionadas ao pagamento da tarifa (as informações especificadas são de natureza informativa, não é necessária a possibilidade de alterá-las diretamente no cartão de registro do veículo):

• classe de veículo atual (ver seção 3.3, apêndice A);
• tarifa atual (ver seção 5.1, Apêndice A);
• contrato atual (ver seção 5.5, apêndice A);
• classe de veículo de acordo com informações do Ministério da Administração Interna da República do Cazaquistão;
• informações sobre a conta pessoal e suas condições (consulte a seção 3.6, apêndice A);
• informações sobre estar no registro de veículos com tarifa reduzida (consulte a seção 3.5, apêndice A).

3) O sistema deve permitir registrar e alterar informações sobre o veículo das seguintes maneiras:

• manualmente pelo operador;
• após o recebimento de informações do sistema de registro de etiquetas RFID (consulte a cláusula 1.1, apêndice B);
• ao identificar o veículo usando a câmera GRNZ.

4) Ao registrar um novo veículo no sistema, o sistema deve solicitar ao serviço dados sobre o veículo para receber dados sobre o veículo (consulte o parágrafo 3.3, apêndice B). Deve ser possível atualizar as informações especificadas de um veículo individual.

7.3 Subseção 4.3. "Requisitos para tipos de segurança" / p. 2.6.3 GOST 34.602-89 /

A seção de requisitos para tipos de suporte geralmente é citada como um exemplo do volume excessivo de TK de acordo com o GOST. Quando se trata de se todas as seções e subseções devem ser fornecidas, elas lembram o software, para o qual na maioria dos casos simplesmente não há nada a ser escrito.

De fato, esta é uma subseção muito importante, embora nem todos entendam seu propósito. Ele descreve as condições sem as quais é impossível implementar desenvolvimento ou comissionamento. Essas condições são descritas como "colaterais".

Ao ler esta subseção, pergunta-se o que os redatores do padrão queriam dizer com "software", "software linguístico", "software de informação" etc. As respostas devem ser buscadas no GOST 34.003-90, onde todos esses termos são decifrados.

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

Imagine a situação em que você precisa criar um sistema no qual deseja implementar o cálculo automático da rota ideal. O botão "Calcular rota" pode parecer simples, mas algoritmos e cálculos matemáticos muito complexos podem estar por trás dele. É claro que não vale a pena empreender o desenvolvimento de tais algoritmos; matemáticos profissionais estão envolvidos nisso. Se tais algoritmos estiverem disponíveis, também serão escritos os requisitos para o seu desenvolvimento ou o uso dos já prontos.

7.3.2 Cláusula 4.3.2 “Suporte à informação” / p. 2.6.3.2 GOST 34.602-89 /

Ao ler a descrição desse requisito no texto GOST, parece que isso é uma repetição do que foi dito em outras seções. Por exemplo, por que descrever novamente os requisitos para “composição, estrutura e métodos de organização de dados no sistema” e “para troca de informações entre os componentes do sistema”? Mas, novamente, esquecemos que os compiladores do GOST no sistema tinham não apenas software, mas também todo o conjunto de medidas organizacionais.

Ao apresentá-lo, você encontra uma situação em que o cliente, por sua vez, não forneceu um operador que insira dados no sistema e, ao mesmo tempo, afirma que o sistema não funciona. Uma situação familiar? Mas se o requisito de fornecer essa entrada for explicitado na declaração de trabalho, seria possível cutucar diretamente o cliente neste momento. Ou você precisa acessar um classificador de endereço específico para o trabalho, mas o cliente não o fornece.

Assim, neste parágrafo, faz sentido especificar os requisitos para as informações recebidas e as informações transmitidas de componente para componente do sistema de maneira não automatizada. O processamento automatizado de informações, o uso do DBMS, a troca de informações dentro do sistema são totalmente descritos em outras seções.

7.3.3 Cláusula 4.3.3 “Suporte linguístico” / p. 2.6.3.3 GOST 34.602-89 /

Este parágrafo fornece:

• requisitos para o uso de linguagens de programação (se houver preferências específicas);
• idioma da interface (quais idiomas, interface multilíngue);
• idioma para comunicação entre as equipes do projeto, requisitos de tradução;
• outros recursos de entrada e saída de dados, se disponíveis: criptografia, métodos não padrão de interação do usuário com o sistema.

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

Este parágrafo fornece uma lista dos softwares adquiridos, se eles forem identificados no estágio de desenvolvimento do ToR.

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

Qualquer sistema de informação não pode funcionar sem hardware, servidores, redes, etc. Geralmente, é aconselhável determinar as características específicas do equipamento para incluir em um projeto técnico, mas uma composição aproximada pode ser fornecida na declaração de trabalho para que o cliente tenha uma idéia dos custos futuros.

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

Se for planejado receber dados de sensores no sistema, é necessário entender quais instrumentos de medição serão utilizados, quais instrumentos de medição de precisão devem fornecer, se essas ferramentas devem ser certificadas e certificadas.

7.3.7 Cláusula 4.3.7 "Suporte organizacional" / p. 2.6.3.7 GOST 34.602-89 /

Imagine que você está criando um sistema do zero. Por exemplo, este é um sistema de gerenciamento de armazém para um novo complexo logístico. Em outras palavras, existem apenas paredes. Ou você está atualizando o sistema e para implementar as alterações necessárias para modificar a estrutura organizacional. Nesses casos, você deve especificar as condições relativas à organização dos processos sob os quais o sistema fornecido por você realmente funcionará.

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

Às vezes, para gerenciar o sistema, é necessário pessoal com quaisquer competências especiais. Nesse caso, uma lista de métodos, normas e padrões deve ser fornecida no TOR, com o qual os funcionários que interagem com o sistema devem estar familiarizados.

7.3.9 Outros tipos de garantias

Ao desenvolver cada novo TK, considere o que será necessário para um comissionamento bem-sucedido. Por exemplo, muitas vezes escrevo requisitos de suporte jurídico, quando a estrutura jurídica usada não está totalmente definida e seu desenvolvimento pode afetar a implementação. Embora essas questões sejam melhor resolvidas antes da redação dos termos de referência .

8. Seção 5 “Composição e conteúdo do trabalho sobre a criação (desenvolvimento) do sistema” / p. 2.7 GOST 34.602-89 /

Esta seção é organizacional e é frequentemente incluída no contrato. No entanto, essas informações no ToR podem ser especificadas.

Em essência, este é um plano curto para desenvolvimento e implementação. Ao compilá-lo, geralmente dou uma tabela que lista todas ou algumas das seguintes colunas:

• O nome do estágio (subestágio).
• Conteúdo do trabalho (breve descrição, lista de tarefas).
• O resultado do trabalho (documentos aprovados, soluções desenvolvidas e enviadas).
• Design, trabalho ou documentação de relatórios.
• Responsável (quem executa este trabalho: cliente, contratado ou outra pessoa). Se ambas as partes devem fornecer um resultado conjunto, as funções são indicadas.
• Duração (datas, datas, início do tempo).

Um exemplo do conteúdo desta seção é dado na tabela abaixo.

9. Seção 6 “Procedimento para monitoramento e aceitação do sistema” / p. 2.8 GOST 34.602-89 /

Esta seção descreve em detalhes o processo de aceitação do sistema pelo cliente: quais testes devem ser realizados, o que será incluído nos dados do teste, de acordo com quais documentos serão testados, como os comentários serão feitos e eliminados.

9.1 Subseção 6.1. “Tipos, composição, volume e métodos de teste do sistema e seus componentes” / p. 2.8.1 GOST 34.602-89 /

Geralmente, aqui eu indico a lista de testes e menciono que os métodos de teste serão fornecidos no documento "Programa e metodologia de testes", que é uma descrição dos principais casos de teste, scripts de teste.

Vamos nos debruçar sobre os tipos de testes. Tipos de testes, sua composição, requisitos para documentos são estabelecidos pelo GOST 34.603-92 “Tecnologia da Informação. Tipos de testes de sistemas automatizados ". Portanto, ao desenvolver esta seção e projeto técnico, não deixe de se referir a este padrão, aqui explicaremos apenas os pontos principais.

Vamos tentar entender que tipo de testes são:

1. Os testes são divididos nos seguintes tipos:

• Preliminar.
• Operação de teste.
• Aceitação.

2. Os testes preliminares (e parcialmente aceitos) são divididos em:

• ( ).
• ( ).

Por que os testes são divididos em diferentes estágios? Em primeiro lugar, como o GOST 34.603-92 não faz distinção entre aceitação interna e externa, parte dos testes pode ser realizada sem um cliente. Em segundo lugar, um processo de teste seqüencial é descrito, parte por parte, e então tudo é integrado.

Vamos tentar descrever o processo de teste em palavras simples:

1. Testes autônomos preliminares de partes do sistema. Partes do sistema são testadas individualmente se houver vários subsistemas ou módulos grandes na composição. Normalmente, esses testes são realizados de forma autônoma, ou seja, sem integração com sistemas adjacentes. Se o sistema for simples, esta etapa poderá ser pulada com segurança.

2. Testes autônomos preliminares do sistema como um todo.Todo o sistema é testado em um complexo de modo autônomo, ou seja, sem integração com sistemas adjacentes. As funções associadas a sistemas adjacentes não são testadas. Em um caso extremo, são colocados "stubs" (emulação de integração) ou o banco de dados é preenchido previamente com dados que devem vir de fontes externas.

3. Testes abrangentes preliminares. O sistema é testado de maneira integrada, ou seja, em interação com sistemas adjacentes. Nesta forma, o sistema é transferido para o cliente para operação experimental.

4. Operação piloto.O MA pode ocorrer em modos diferentes. O melhor é explorar dados reais, com usuários reais e com tarefas reais. Somente esse tipo de teste garantirá que o sistema esteja realmente operacional. Durante a operação de teste, as desvantagens são eliminadas.

5. Testes de aceitação. Este é o último tipo de verificação. Diga-me, por que a operação de teste depois de eliminar todas as deficiências não entra suavemente na indústria? Então geralmente acontece. Mas os tios altos precisam ver que o sistema realmente funciona, para "senti-lo". Os testes de aceitação são destinados a eles, para uma alta comissão. Assim, os testes de aceitação diferem dos testes preliminares, principalmente no status da comissão.

Também neste parágrafo são indicados documentos em que métodos de teste serão fornecidos:

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

9.2 Subseção 6.2. "Requisitos gerais para aceitação do trabalho por etapas" / p. 2.8.2 GOST 34.602-89 /

Nesta seção, eu normalmente indico:

1. Em cujo território e em quais equipamentos os testes serão realizados: o cliente ou o contratado.
2. Uma descrição geral de como os testes serão conduzidos (por exemplo, que documentos serão verificados, presença de elementos da interface do usuário, scripts são elaborados).
3. Lista de participantes.
4. A lista de documentos que elaboram o resultado do teste:
   
   
   • Para testes preliminares e de aceitação, este é um relatório de teste que fornece uma lista de verificações e seus resultados.
   • Para operação de teste - um diário de operação de teste.

10. Seção 7 “Requisitos para a composição e o conteúdo do trabalho de preparação do objeto de automação para colocar o sistema em operação” / p. 2.9 GOST 34.602-89 /

O processo descrito nesta seção é frequentemente chamado de implementação. Observe que esses trabalhos também são apresentados na seção 5 “Composição e conteúdo do trabalho sobre a criação (desenvolvimento) do sistema” . Mas, na seção 5, eles são mencionados apenas brevemente, e uma descrição detalhada é fornecida aqui.

Ao preparar um objeto, como regra, o seguinte trabalho deve ser realizado:

1. Reorganização, recrutamento de novos funcionários, se necessário.
2. Treinamento de pessoal.
3. Para aplicativos da Web: desenvolvimento de seções comuns do site e contrato do usuário (consentimento para o processamento de dados pessoais).
4. Preenchendo diretórios e outras informações básicas.
5. Transfira dados do sistema antigo.
6. Implante o sistema em servidores industriais.
7. Configure a integração com sistemas adjacentes.
8. Configurando um sistema de acesso e criando contas.

Alguns desses pontos devem ser descritos detalhadamente, principalmente no que diz respeito à transferência de dados e ao preenchimento de diretórios.

11. Seção 8 “Requisitos de documentação” / p. 2.10 GOST 34.602-89 /

Não vale a pena refere-se aos documentos formalmente. Documentos - trata-se de gerenciamento de projetos, fluxo de trabalho do projeto. Você não terá tudo em mente, e o sucesso do projeto depende da disponibilidade e da qualidade dos documentos. Obviamente, existem documentos "por peso", e eles devem ser tratados de acordo, mas sem um documento de maneira calma e ordenada, o projeto não pode ser implementado.

A documentação do projeto de automação de acordo com o GOST 34 é regulada pelos seguintes padrões:

• GOST 34.201-89 Tipos, integridade e designação de documentos ao criar sistemas automatizados.
• RD 50-34.698-90 Diretrizes. Tecnologia da informação. Um conjunto de padrões e diretrizes para sistemas automatizados. Sistemas automatizados. Requisitos para o conteúdo dos documentos.
• Para os Termos de Referência - GOST 34.602-89, que estamos discutindo agora.

O primeiro padrão (GOST 34.201-89) fornece uma lista e estrutura da documentação. No segundo - RD 50-34.698-90 - é indicado o conteúdo dos seguintes documentos:

• Documentos de projeto preliminar e projetos técnicos.
• Documentos desenvolvidos nas etapas de pré-design.
• Documentos organizacionais e administrativos (atos, protocolos, etc.)

11.1 Recursos da estrutura da documentação

Ao compilar uma lista de documentos necessários, eles geralmente consultam RD 50-34.698-90 e selecionam os necessários. Ao mesmo tempo, muitos erros são cometidos, uma vez que a documentação possui uma estrutura bastante complicada, descrita em GOST 34.201-89.

Vamos tentar identificar algumas regras que ajudarão na compilação de uma lista de documentos.

1. Cada estágio tem seu próprio conjunto de documentação.

Cada estágio tem seu próprio conjunto de documentação. Isso é muito importante para entender. Não é necessário prescrever o desenvolvimento de documentos operacionais nas etapas de projeto e vice-versa. Acontece papel puramente formal, que você passará um tempo considerável. E se o “Guia do Usuário” até o final do desenvolvimento do sistema, normalmente ninguém compõe (embora eu tenha conhecido esses números), então a “Descrição das Funções Automatizadas”, na qual geralmente são fornecidos scripts para programadores, é constantemente elaborada após a conclusão do desenvolvimento. Além disso, ao ler RD 50-34.698-90, pode-se ter a impressão de que alguns documentos têm conteúdo sobreposto: isso também se deve ao fato de os documentos serem destinados a diferentes estágios.

Como alguns documentos podem ser desenvolvidos em um ou outro estágio, GOST 34.201-89, para evitar repetições, fornece separadamente, por exemplo, uma lista de documentos que podem ser emitidos no estágio de um projeto técnico e documentação de trabalho e, separadamente, listas de documentos para cada um desses estágios separadamente. Assim, ao compilar uma lista de documentos para um dos estágios, é necessário examinar as listas de documentos em várias seções da norma.

Para não ficar confuso, compilei uma planilha do Excel na qual, usando filtros, você pode exibir imediatamente uma lista completa de documentos para um estágio específico.

2. Os documentos são divididos em tópicos (partes do projeto).

O GOST 34 contém documentos que descrevem soluções para todo o sistema, bem como suporte organizacional, técnico, matemático, software e informações (falamos sobre os tipos de suporte acima ). No RD 50-34.698-90, esses documentos são fornecidos precisamente com uma divisão por partes do projeto (tópicos). Você deve sempre prestar atenção a isso para determinar a finalidade do documento.

3. Os documentos podem ser combinados.

GOST 34.201-89 indica diretamente em quais casos um documento está incluído em outro. Isso é feito para que não haja documentos degenerados, com uma ou duas páginas. Se algo precisar ser descrito, mas o volume for muito pequeno, é melhor incluir o texto em outro documento. Na maioria dos casos, há um documento como "Nota explicativa ao projeto técnico", no qual você pode adicionar seções.

4. As estimativas operacionais e de projeto são destacadas separadamente.

Os compiladores do GOST 34.201-89 em colunas separadas da tabela com uma lista de documentos indicados pertencentes às estimativas operacionais e de design.

As estimativas de projeto incluem documentos que regem a construção e o trabalho elétrico: estimativas, planos de compras, desenhos e diagramas elétricos.

Os documentos operacionais incluem os documentos que orientam o uso e a manutenção do sistema: manuais e instruções, listas de materiais e dados, documentos que contêm informações sobre violações durante a operação.

11.2 Características do desenho da lista de documentos

Como você observou anteriormente, ao descrever as etapas do trabalho na seção 5, “Composição e conteúdo do trabalho para criar (desenvolver) um sistema” , também é fornecida uma lista de documentação. Uma lista dupla de documentos é fornecida por um motivo simples: não basta indicar o nome do documento, ainda é necessário explicar sua finalidade e fornecer um breve resumo (é claro, para o “Guia do Usuário” não faz sentido indicar o conteúdo). Caso contrário, não será capaz de determinar qual o significado de um documento específico no gerenciamento de projetos. O GOST é um convidado e, em cada projeto, o conteúdo e a função dos documentos podem ser diferentes. Além disso, a lista pode conter documentos que não são regulamentados pelo GOST 34, que precisam ser esclarecidos sem falhas.

Nas regras de documentação, geralmente dou uma tabela com as seguintes colunas:

• Stage.
• O nome do documento.
• Nota: indica o padrão de desenvolvimento, objetivo, resumo e principais características do documento.

11.3 Exemplo de lista de documentação

Para um projeto grande implementar um sistema complexo, pode ser necessária uma lista bastante grande de documentação. Damos um exemplo dessa lista na tabela abaixo.

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

Parece ser uma seção formal, mas muito útil. Imagine uma situação em que você se lembre de que, durante o desenvolvimento do TK, você leu um artigo e, por algum motivo, precisa encontrá-lo, por exemplo, para esclarecer algo ou justificar suas decisões. Mas você absolutamente não se lembra do nome ou do local em que estava. Portanto, quando eu usar materiais úteis, não deixe de colocá-los na lista. E no texto eu coloquei uma nota de rodapé indicando a fonte.

Se houver muitas fontes, elas deverão ser divididas em subseções, por exemplo:

• Materiais que descrevem análogos (protótipos) do sistema desenvolvido.
• Materiais que descrevem a ideia geral do sistema. Freqüentemente, esses documentos são compilados nos estágios de pré-design e geralmente são referenciados na seção "Características do objeto de automação".
• Materiais de desenvolvimento do projeto: lista de GOSTs usados ​​da série 34, padrões usados ​​para gerenciamento de projetos.
• Materiais relacionados à implementação do processo principal: uma lista de leis, normas, regulamentos internos e ordens que estabelecem as regras para a implementação de processos automatizados.
• Materiais e normas que contêm requisitos para segurança geral e da informação.

Conclusão

Obviamente, a preparação dos Termos de Referência de acordo com o GOST 34 não pode ser considerada fácil e simples. E não porque GOST é ruim, mas GOST apenas faz você pensar em todo o projeto, pintar todas as pequenas coisas. Mas um TOR bem escrito é metade do sucesso do projeto.

Escreva nos comentários se achar necessário esclarecer ou complementar algo. Certifique-se de fazer alterações no artigo.

Leia outros artigos do autor:

• .
• ( ) .
• .