Padrões IEEE. Prolozova N.O., Nazarova O.B., Davletkireeva L.Z.

A manutenção sempre foi reconhecida como uma das principais etapas do ciclo de vida do software. Já em meados da década de 70, era reconhecido que a manutenção é uma etapa que representa mais de 50% dos custos de desenvolvimento e implementação de uma ferramenta de software.

A continuidade dos processos de negócio e a segurança das informações corporativas necessárias à vida das empresas dependem da eficácia do trabalho na fase de suporte e manutenção.

Para sistemas de software complexos que requerem uso e manutenção a longo prazo de múltiplas versões, há uma necessidade urgente de regular o seu ciclo de vida, formalizar e aplicar perfis padrão e certificação de qualidade do programa.

A utilização de documentos regulatórios e normativos torna o ciclo de vida do software mais definido, previsível em estrutura, conteúdo, qualidade e custo. A documentação, o conteúdo da informação e a compreensibilidade determinam a composição e a qualidade da documentação de suporte.

Para organizar de forma correta e eficaz a etapa mais longa e importante do ciclo de vida do software - Manutenção do software, que exige o maior dispêndio de tempo, mão-de-obra e recursos materiais, é necessário considerar as recomendações constantes das normas internacionais e nacionais normas contendo disposições para a organização ideal desta fase.

Primeiramente, é necessário analisar a interpretação do estágio de suporte em diversas normas.

A manutenção de software é definida pelo Padrão IEEE para Manutenção de Software (IEEE 1219) como a modificação de um produto de software após o lançamento em serviço para eliminar falhas, melhorar o desempenho e/ou outras características (atributos) do produto, ou adaptar o produto para uso. em um ambiente modificado. É interessante que esta norma também aborde questões de preparação para manutenção antes de o sistema ser colocado em operação, no entanto, estruturalmente isto é feito ao nível da aplicação de informação correspondente incluída na norma.

Por sua vez, a norma de ciclo de vida 12207 (IEEE, ISO/IEC, GOST R ISO/IEC) posiciona a manutenção como um dos principais processos do ciclo de vida. Esta norma descreve manutenção como o processo de modificação de um produto de software em termos de seu código e documentação para resolver problemas que surgem durante a operação ou para perceber a necessidade de melhorar determinadas características do produto. O desafio é modificar o produto mantendo sua integridade.

A norma internacional ISO/IEC 14764 (Norma para Engenharia de Software – Manutenção de Software) define a manutenção de software nos mesmos termos da norma 12207, enfatizando o trabalho de preparação para atividades de manutenção antes do sistema entrar em operação, como questões de planejamento, regulamentações e operações de suporte.

Após a entrada em operação da subestação, há necessidade de manter seu desempenho no nível dos requisitos estabelecidos nas especificações técnicas. Esta tarefa inclui a eliminação de falhas e erros de software e possivelmente o aumento da funcionalidade. Para organizar estes trabalhos, é necessário consultar as disposições especificadas nas normas.

Diversas fontes, em particular a norma IEEE 1216, definem três categorias de trabalhos de manutenção: ajuste, adaptação e melhoria. Esta classificação foi atualizada na ISO/IEC 14764 com a introdução de um quarto componente.

Assim, hoje falamos de quatro categorias de apoio:

1. Suporte corretivo envolve mudanças causadas pela necessidade de eliminar (corrigir) erros reais no produto de software. O suporte corretivo é realizado caso o produto de software não atenda aos requisitos estabelecidos.

2. Suporte adaptativo associado à necessidade de adaptar o produto de software ao ambiente (condições) alterado. Estas alterações estão relacionadas com a implementação de novos requisitos para a interface do sistema, para o próprio sistema ou para meios técnicos.

3. Apoio total determina mudanças para melhorar as características de desempenho do software e sua manutenibilidade. Essas alterações podem resultar no fornecimento de novas funcionalidades aos usuários, na revisão da tecnologia de desenvolvimento de documentos de acompanhamento ou em alterações nos próprios documentos.

4. Apoio preventivo visa mudanças causadas pela necessidade de eliminar (corrigir) erros potenciais (ocultos) em um produto de software. A manutenção preventiva geralmente é realizada em produtos de software relacionados à garantia ou proteção da vida humana.

A manutenibilidade é um dos indicadores de qualidade de software, bem como uma característica importante para o cliente, fornecedor e usuário.

A manutenibilidade ou manutenibilidade de um sistema de software é definida, por exemplo, pelo IEEE 610.12-90 Standard Glossary for Software Engineering Terminology, Update 2002) como a facilidade de manutenção, extensão, adaptação e ajuste para atender a requisitos especificados. A norma ISO/IEC 9126-01 (Engenharia de Software - Qualidade do Produto - Parte 1: Modelo de Qualidade, 2001) considera a manutenibilidade como uma das características da qualidade.

A manutenibilidade deve ser determinada antes do desenvolvimento do software, ou seja, um acordo apropriado foi preparado entre o cliente e o fornecedor como parte do trabalho de “preparação” do processo de pedido de acordo com (ISO/IEC, #M12291 1200009075 GOST R ISO/ IEC) 12207#S. O desenvolvedor cria um plano de suporte, que deve refletir métodos específicos para garantir a manutenção do software, recursos apropriados e um algoritmo para execução do trabalho.

A qualidade de uma ferramenta de software é um aspecto importante da manutenção do produto de software. Os mantenedores devem ter um programa de garantia de qualidade de software que cubra as seis características de qualidade definidas na ISO/IEC 9126. Os mantenedores de software devem ter um processo apropriado para definir, descrever, selecionar, aplicar e melhorar metodologias para avaliar (medir) as características do software. .

Para reduzir o custo de suporte adicional, ao longo do processo de desenvolvimento é necessário especificar, avaliar e controlar as características que afetam a manutenibilidade. A implementação regular desse tipo de trabalho facilita a manutenção adicional, aumentando sua manutenibilidade (como uma característica de qualidade), o que é bastante difícil de conseguir, uma vez que tais características são frequentemente ignoradas durante o desenvolvimento.

Conforme discutido anteriormente, a manutenção de software é uma etapa dispendiosa do ciclo de vida, para otimizar seu trabalho é necessário aplicar diversos métodos de estimativa do custo de manutenção.

O custo do trabalho de suporte é influenciado por muitos fatores diferentes. A ISO/IEC 14764 afirma que “existem dois métodos mais populares para estimar o custo de manutenção: – o modelo paramétrico e o uso da experiência”. Na maioria das vezes, ambas as abordagens são combinadas para melhorar a precisão da avaliação.

Existem vários métodos para avaliar internamente a produtividade do pessoal de apoio para comparar o desempenho de diferentes grupos de apoio. A organização de manutenção deve determinar as métricas pelas quais o trabalho relevante será avaliado. Os padrões IEEE 1219 e ISO/IEC 9126-01 (Engenharia de Software - Qualidade do Produto - Parte 1: Modelo de Qualidade, 2001) oferecem métricas especializadas focadas especificamente em questões de manutenção e programas relacionados.

Os trabalhos de manutenção devem ser rigorosamente regulamentados e descritos, contendo entradas e saídas detalhadas do processo. Esses processos são cobertos por padrões IEEE 1219 e ISO/IEC 14764.

O processo de manutenção começa de acordo com o padrão IEEE 1219 a partir do momento em que o software é colocado em operação e diz respeito a questões como o planejamento das atividades de manutenção.

A norma ISO/IEC 14764 esclarece as disposições da norma de ciclo de vida 12207 relacionadas ao processo de manutenção. O trabalho de manutenção descrito nesta norma é semelhante ao trabalho na IEEE 1219, exceto que está agrupado de forma ligeiramente diferente.

Vamos dar uma olhada mais de perto nos trechos da norma GOST R ISO/IEC 14764-2002, que contém o texto completo e autêntico da norma internacional ISO/IEC 14764.

De acordo com GOST R ISO/IEC 14764-2002, que descreve o processo de manutenção de software, os detalhes do processo de manutenção de software devem ser documentados para que o pessoal de suporte atue dentro de um único processo. O sistema de indicadores de qualidade (métricas) deverá facilitar a implementação do processo de manutenção e contribuir para a melhoria (modernização) deste software.

O mantenedor deverá (5.5.2.1 GOST R ISO/IEC 12207) analisar o relatório do problema ou a proposta de modificação quanto ao seu impacto nas questões organizacionais, no sistema existente e nas conexões de interface com outros sistemas.

Com base na análise, o mantenedor deve (5.5.2.3 GOST R ISO/IEC 12207) desenvolver opções para implementar a mudança. Antes de fazer alterações no sistema, o mantenedor deve (ver 5.5.2.5 GOST R ISO/IEC 12207) obter aprovação para a opção de alteração selecionada de acordo com o contrato e confirmação de que a alteração feita satisfaz os requisitos estabelecidos no contrato (ver 5.5 .4.2 GOST R ISO/IEC 12207). O mantenedor deve (5.5.2.4 GOST R ISO/IEC 12207) documentar: um relatório do problema ou proposta de modificação, os resultados de sua análise e opções para implementar as mudanças.

Para controlar adequadamente a transferência do sistema, um plano de transferência para a instalação deve ser desenvolvido, documentado e executado (5.5.5.2 GOST R ISO/IEC 12207). Os usuários devem estar envolvidos no trabalho planejado.

Para atividades de apoio, há uma série de trabalhos e práticas únicas que devem ser consideradas ao organizar o apoio. SWEBOK (Software Engineering Body of Knowledge) fornece os seguintes exemplos desse tipo de características únicas.

Transmissão:a atividade controlada e coordenada de transferência de software dos desenvolvedores para o grupo, serviço ou organização responsável pelo suporte adicional.

Aceitar/rejeitar solicitações de modificação : Os pedidos de alterações podem ser aceites e transferidos para trabalho, ou rejeitados por vários motivos justificados - o volume e/ou complexidade das alterações necessárias, bem como o esforço necessário para tal. As decisões apropriadas também podem ser tomadas com base na prioridade, avaliação de viabilidade, falta de recursos (incluindo a falta de capacidade de envolver os desenvolvedores na resolução de tarefas de modificação, se houver uma necessidade real para isso), planejamento aprovado para implementação no próximo lançamento, etc.

Meios para notificar o pessoal de manutenção e rastrear o status das solicitações de modificação e relatórios de bugs : Uma função de suporte ao usuário final que inicia esforços para avaliar a necessidade, a prioridade e o custo das modificações associadas a uma solicitação ou problema relatado.

Análise de impacto:análise das possíveis consequências das alterações introduzidas no sistema existente.

Suporte de software: trabalho de consulta aos usuários, realizado em resposta às suas solicitações de informações, por exemplo, sobre regras de negócios relevantes, verificação, conteúdo de dados e dúvidas específicas dos usuários e seus relatos de problemas (erros, falhas, comportamento inesperado, mal-entendidos de aspectos do trabalho com o sistema, etc.); P.).

Contratos e obrigações: Estes incluem o clássico acordo de nível de serviço (SLA), bem como outros aspectos contratuais, com base nos quais o grupo/serviço/organização de suporte executa o trabalho relevante.

Além disso, existem atividades adicionais que apoiam o processo de manutenção, descritas pela SWEBOK como atividades do pessoal de manutenção que não envolvem interação explícita com os utilizadores, mas são necessárias para realizar as atividades relacionadas. Esse trabalho inclui: planejamento de manutenção, gerenciamento de configuração, verificação e certificação, avaliação de qualidade de software, diversos aspectos de revisão, análise e avaliação, auditoria e treinamento de usuários. Esse trabalho especial (interno) também inclui o treinamento de pessoal de apoio.

A Tabela 1 abaixo fornece uma breve visão geral dos principais padrões utilizados na organização da manutenção de sistemas de informação.

Tabela 1. Normas na área de manutenção de sistemas de informação

Além das normas internacionais e nacionais que regulam o processo de manutenção dos sistemas de informação discutidos acima, existem vários documentos que regem e normas intra-empresas (corporativas), cuja base são as normas internacionais. Neste caso, é dada especial atenção à qualidade da documentação, que determina em grande parte a competitividade do software. Ao criar produtos de software complexos e garantir o seu ciclo de vida, é necessário selecionar os padrões necessários e criar todo o conjunto de documentos, ou seja, um perfil que garanta a regulação de todas as etapas e trabalhos de manutenção.

Consideremos a aplicação de padrões para manutenção de sistemas de informação usando um exemplo específico.O funcionamento de alta qualidade do sistema requer adaptação constante às mudanças nos processos de negócios da organização, bem como uma resposta rápida a falhas e solução de problemas. Neste sentido, a direção da ZAO Firm SoftInCom decidiu sobre a necessidade de celebrar um acordo com os desenvolvedores do sistema de informação corporativa (CIS) Orient Express para atualização e manutenção do sistema.

A manutenção do Eastern Express CIS inclui suporte de vários tipos (de acordo com GOST R ISO IEC 14764-2002). Ou seja, suporte corretivo, que está associado a alterações causadas pela necessidade de eliminar (corrigir) erros reais no produto de software. O suporte corretivo é realizado caso o produto de software não atenda aos requisitos estabelecidos. Bem como suporte adaptativo e completo que moderniza o produto de software.

A necessidade de suporte corretivo surge quando ocorrem erros do sistema, bem como erros causados ​​pelo usuário. Os erros causados ​​pelo usuário incluem, por exemplo, a exclusão acidental de dados importantes, o que leva à necessidade de utilizar um backup do sistema. Erros de sistema ocorrem com bastante frequência, principalmente após a instalação de novos lançamentos, pois novos lançamentos implicam mudanças bastante sérias nas tecnologias de processamento de dados existentes e na inclusão de novos módulos.

A necessidade de apoio adaptativo surge quando há alterações no funcionamento de algum processo de negócio (realização de uma promoção, alteração de impressos externos, encomendas da sede, etc.), ou quando a realização de alguma operação é inconveniente, o que exige alterações na interface do sistema.

O suporte total é fornecido com muito menos frequência do que outros tipos de suporte. É realizado quando surgem muitos incidentes, solicitações e desejos semelhantes dos usuários, bem como após os projetistas do CIS terem analisado as capacidades do sistema.

O trabalho de apoio pode ser dividido em quatro etapas: análise de defeitos e modificações, implementação de modificações, avaliação e aceitação dos resultados do suporte, transferência para outra plataforma. Cada uma dessas etapas contém entradas e saídas específicas e deve ser documentada.

A Tabela 2 mostra as principais etapas do suporte e os resultados no parágrafo da documentação anexa.

Tabela 2. Etapas do processo de manutenção do sistema de informação

De acordo com 5.5.2.1 do GOST R ISO/IEC 12207, o mantenedor deve analisar os relatórios do usuário sobre o problema. Para automatizar o registro e registro de solicitações de usuários do Orient Express CIS, é utilizado o sistema de registro de incidentes MantisBT. Com base nos dados cadastrados no sistema O MantisBT gera um documento “Relatório de defeitos identificados pelos usuários” contendo os seguintes campos: número do incidente, data de criação, categoria, essência do incidente, solução proposta.

Com base na análise, o mantenedor deve (5.5.2.3 GOST R ISO/IEC 12207) desenvolver opções para implementar as mudanças. Para tanto, está sendo desenvolvido o documento “Diário de ajustes preparados e aprovados à nova versão básica do CIS”, contendo os seguintes dados: categoria, defeito identificado pela organização apoiadora, defeito identificado pelos usuários do CIS, ajuste.

A seguir, o mantenedor deve (5.5.4.2 GOST R ISO/IEC 12207) obter a confirmação de que a alteração realizada satisfaz os requisitos estabelecidos no contrato. Para estes fins, é gerado um documento “Notificação aos usuários sobre o lançamento de uma nova versão do CIS” e espera-se a confirmação do consentimento para instalação da nova versão.

Para controlar adequadamente a transferência do sistema, deve haver

A estrutura do ciclo de vida do software de acordo com a norma ISO/IEC 12207 é baseada em três grupos de processos (Fig. 1):

· principais processos do ciclo de vida de software (compra, entrega, desenvolvimento, operação, suporte);

· processos auxiliares que garantem a implementação dos processos principais (documentação, gestão de configuração, garantia de qualidade, verificação, certificação, avaliação, auditoria, resolução de problemas);

· processos organizacionais (gestão de projetos, criação de infraestrutura de projetos, definição, avaliação e melhoria do próprio ciclo de vida, formação).

Arroz. 1. Processos do ciclo de vida de software.

Processo de aquisição(processo de aquisição). Consiste em ações

e tarefas do cliente que adquire o software. Este processo abrange as seguintes etapas:

1) início da aquisição;

2) preparação de propostas de licitação;

3) elaboração e adequação do contrato;

4) supervisão das atividades do fornecedor;

5) aceitação e conclusão do trabalho.

Processo de entrega(processo de fornecimento). Abrange as atividades e tarefas executadas pelo fornecedor que fornece ao cliente um produto ou serviço de software. Este processo inclui as seguintes etapas:

1) início do parto;

2) preparar resposta às propostas de licitação;

3) elaboração do contrato;

4) planejamento;

5) execução e controle;

6) fiscalização e avaliação;

7) entrega e conclusão da obra.

Processo de desenvolvimento(processo de desenvolvimento). Dispõe sobre as ações e tarefas executadas pelo desenvolvedor e abrange a criação de software e seus componentes de acordo com requisitos especificados, incluindo a preparação de documentação de projeto e operacional, a preparação de materiais necessários para testar a funcionalidade e a qualidade adequada do software. produtos, materiais necessários para organizar o treinamento de pessoal, etc.

O processo de desenvolvimento inclui as seguintes etapas:

1) análise dos requisitos do sistema;

2) desenho da arquitetura do sistema;

3) análise de requisitos de software;

4) projeto de arquitetura de software;

5) projeto detalhado de software;

6) codificação e teste de software;

7) integração de software;

8) testes de qualificação de software;

9) integração de sistemas;

10) testes de qualificação do sistema;

11) instalação de software;

12) aceitação de software.

Processo de operação(processo de operação). Abrange as ações e tarefas do operador - a organização que opera o sistema. Este processo inclui as seguintes etapas:

1) testes operacionais;

2) operação do sistema;

3) suporte ao usuário.

Processo de manutenção(processo de manutenção). Dispõe sobre as ações e tarefas desempenhadas pela organização acompanhante (serviço de acompanhantes). Este processo é ativado quando alterações (modificações) do produto de software e documentação relacionada são causadas por problemas ou necessidades de modernização ou adaptação do software. De acordo com o padrão IEEE-90, manutenção refere-se a fazer alterações no software para corrigir erros, melhorar o desempenho ou adaptar-se a alterações nas condições operacionais ou

requisitos. As alterações feitas no software existente não devem violar

sua integridade. O processo de manutenção inclui a transferência do software para outro ambiente (migração) e termina com o descomissionamento do software.

O processo de manutenção abrange as seguintes ações:

1) análise de problemas e solicitações de modificação de software;

2) modificação de software;

3) inspeção e aceitação;

4) transferência de software para outro ambiente;

5) descomissionamento do software.

O grupo de processos auxiliares inclui:

Documentação;

Gerenciamento de configurações; Garantia da Qualidade;

Verificação; certificação;

Avaliação participativa;

Resolução do problema.

Processo de documentação(processo de documentação). Ele fornece uma descrição formalizada das informações criadas durante o ciclo de vida do software. O processo de documentação inclui as seguintes etapas:

1) projeto e desenvolvimento;

2) liberação de documentação;

3) suporte de documentação.

Processo de gerenciamento de configuração(processo de gerenciamento de configuração). Envolve o uso de procedimentos administrativos e técnicos ao longo do ciclo de vida do software para determinar o status dos componentes de software no sistema, gerenciar modificações de software, descrever e preparar relatórios sobre o status dos componentes de software e solicitações de modificação, garantir integridade, compatibilidade e correção de componentes de software, gerencie o armazenamento e a entrega POR. De acordo com a norma IEEE-90, configuração de software é entendida como a totalidade de suas características funcionais e físicas.

características estabelecidas na documentação técnica e implementadas no software.

O gerenciamento de configuração permite organizar, levar em consideração e controlar sistematicamente as alterações no software em todas as fases do ciclo de vida. Os princípios gerais e recomendações para o gerenciamento de configuração de software estão refletidos no projeto da norma ISO/I EC CD 12207-2: 1995 "Tecnologia da Informação - Processos do Ciclo de Vida de Software. Parte 2.

Gerenciamento de configuração para software". O processo de gerenciamento de configuração inclui as seguintes ações:

1) identificação da configuração;

2) controle de configuração;

3) contabilização do status da configuração;

4) avaliação de configuração;

5) gerenciamento e entrega de liberação.

Processo de Garantia de Qualidade(processo de garantia de qualidade). Fornece garantia adequada de que o software e seus processos de ciclo de vida atendem aos requisitos especificados e aos planos aprovados. Qualidade de software é entendida como um conjunto de propriedades que caracterizam a capacidade do software em satisfazer requisitos específicos. Para obter avaliações fiáveis ​​do software que está a ser criado, o processo de garantia da sua qualidade deve ocorrer independentemente das entidades diretamente relacionadas com o desenvolvimento do software. Podem ser utilizados os resultados de outros processos de apoio, como verificação, validação, avaliação conjunta, auditoria e resolução de problemas. O processo de garantia de qualidade inclui as seguintes atividades:

1) garantir a qualidade do produto;

2) garantir a qualidade do processo;

3) garantir outros indicadores de qualidade do sistema.

Processo de verificação(processo de verificação). Consiste em determinar se os produtos de software resultantes de alguma ação satisfazem plenamente os requisitos ou condições determinados por ações anteriores (verificação no sentido estrito significa prova formal da correção do software).

Processo de atestado(processo de validação). Envolve determinar a integridade da conformidade dos requisitos especificados e do sistema ou produto de software criado com sua finalidade funcional específica. A certificação geralmente se refere à confirmação e avaliação da confiabilidade dos testes de software.

Processo de avaliação participativa(processo de revisão conjunta). Pretende-se avaliar o estado dos trabalhos do projeto e do software criado durante a execução desses trabalhos (ações). Ele se concentra principalmente no controle do planejamento e gerenciamento dos recursos, pessoal, equipamentos e ferramentas do projeto.

Processo de Auditoria(processo de auditoria). É uma determinação do cumprimento dos requisitos, planos e termos do contrato.

Processo de resolução de problemas(processo de resolução de problemas). Envolve a análise e resolução de problemas (incluindo inconsistências detectadas) independentemente da sua origem ou fonte, que são descobertos durante o desenvolvimento, operação, manutenção ou outros processos. Cada problema detectado deve ser identificado, descrito, analisado e resolvido.

O grupo de processos organizacionais do ciclo de vida do software inclui:

Ao controle;

Criação de infraestrutura;

Melhoria;

Lançamento de novas versões;

Educação.

Processo de gestão(processo de gestão). Consiste em atividades e tarefas que podem ser executadas por qualquer parte que gerencie seus processos. Esta parte (gerente) é responsável pelo gerenciamento de lançamento de produtos, gerenciamento de projetos e gerenciamento de tarefas de processos relacionados, como aquisição, entrega, desenvolvimento, operação, manutenção, etc.

Processo de criação de infraestrutura(processo de infraestrutura). Abrange a seleção e suporte (manutenção) de tecnologia, padrões e ferramentas, seleção e instalação de hardware e software utilizados para desenvolvimento, operação ou manutenção de software. A infraestrutura deve ser modificada e mantida de acordo com as alterações nos requisitos dos processos relevantes. A infraestrutura, por sua vez, é um dos objetos do gerenciamento de configuração.

Processo de melhoria(processo de melhoria). Ele prevê a avaliação, medição, controle e melhoria dos processos do ciclo de vida do software. A melhoria dos processos do ciclo de vida do software visa aumentar a produtividade de todos os especialistas neles envolvidos, melhorando a tecnologia utilizada, os métodos de gestão, a seleção de ferramentas e a formação.

pessoal.

Processo de aprendizado(processo de treinamento). Abrange a formação inicial e o subsequente desenvolvimento contínuo do pessoal.

Na área de TI, os padrões mais práticos são publicados pelas seguintes organizações:

• Instituto de Engenheiros Elétricos e Eletrônicos(IEEE, www.ieee.org) é uma organização científica e técnica líder há muitos anos, inclusive na criação de padrões de documentação de software. A maioria dos padrões é desenvolvida por vários comitês compostos por engenheiros profissionais experientes e responsáveis. Alguns dos padrões IEEE também se tornaram padrões ANSI (American National Standards Institute). Principalmente os padrões IEEE formaram a base para a preparação de MU para CP. Schmidt M. Implementando os Padrões de Engenharia de Software IEEE.
• Organização Internacional de Normalização (ISO) tem enorme influência em todo o mundo, especialmente entre organizações de produtores que lidam com a União Europeia (UE). Atualmente, praticamente todos os padrões modernos de TI traduzidos e adotados na Federação Russa são padrões preparados pela ISO em conjunto com a Comissão Eletrotécnica Internacional - IEC. Você sabe que é dada especial atenção às questões de garantia da qualidade do produto em nível internacional, portanto, de acordo com o Decreto do Governo Russo nº 113 de 02/02/1998, o cumprimento dos requisitos da ISO 9000 (uma série de normas que regulam a gestão da qualidade nas empresas) é um pré-requisito para a obtenção de ordem governamental.
• Instituto de Tecnologias de Engenharia de Software(Instituto de Engenharia de Software - SEI, sei.cmu.edu - mais de 1.000 artigos) foi criado pelo Departamento de Defesa dos EUA na Universidade Carnegie Mellon para elevar o nível de tecnologia de software entre os contratantes do Departamento de Defesa. O trabalho da SEI também foi adotado por muitas empresas comerciais que consideram a melhoria do processo de desenvolvimento de software um objetivo corporativo estratégico. Veremos um dos padrões desenvolvidos pela SEI chamado Capability Maturity Model (CMM).
• Consórcio de tecnologia de manipulação de objetos(Object Management Group, www.omg.org) é uma organização sem fins lucrativos com aproximadamente 700 empresas membros. OMG estabelece padrões para computação distribuída orientada a objetos. Deve-se observar que a OMG utiliza a linguagem de modelagem unificada UML como padrão para descrição de projetos. Estudaremos UML detalhadamente, porque... o uso desta linguagem em conjunto com o processo unificado do Rational é a base para o desenvolvimento do núcleo do projeto do curso.

Conceito de ciclo de vida do sistema

A necessidade de padronização do desenvolvimento de software é melhor descrita na introdução do padrão GOST R ISO/IEC 12207-99 “Tecnologia da informação. Processos do ciclo de vida do software": “O software é parte integrante da tecnologia da informação e dos sistemas tradicionais, como transporte, militar, médico e financeiro. Existem muitos padrões, procedimentos, métodos, ferramentas e tipos de ambientes operacionais diferentes para desenvolver e gerenciar software. Esta diversidade cria desafios na concepção e gestão de software, especialmente quando se combinam produtos e serviços de software. A estratégia de desenvolvimento de software exige passar desta multiplicidade para uma ordem comum que permitirá aos profissionais de software “falar a mesma língua” ao desenvolver e gerir software. Este padrão internacional fornece essa ordem geral.”

Norma GOST R ISO/IEC 12207-99 define o conceito básico de um sistema de software - “ciclo de vida” (GOST R ISO/IEC TO 15271-2002 “Tecnologia da informação. Diretrizes para a aplicação de GOST R ISO/IEC 12207”).

GOSTR ISO/IEC 12207-99 introduz o conceito de modelo de ciclo de vida como uma estrutura composta por processos que abrange a vida de um sistema desde o estabelecimento de requisitos para o mesmo até o final de sua utilização. Propõe-se corrigir esta definição e dividi-la em duas definições:

1. vida útil– um conjunto de processos divididos em trabalhos e tarefas, e incluindo o desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema desde o estabelecimento de requisitos para o mesmo até à cessação da sua utilização.
2. modelo de ciclo de vida– uma estrutura que determina a sequência de processos, trabalhos e tarefas executadas ao longo do ciclo de vida de um sistema de software, bem como as relações entre eles.

Os processos do ciclo de vida são divididos em três grupos: principal, auxiliar e organizacional.

O grupo de processos principais inclui: aquisição, fornecimento, desenvolvimento, operação e suporte. Os principais processos do ciclo de vida são implementados sob o controle das principais partes envolvidas no ciclo de vida do software. A parte principal é uma daquelas organizações que inicia ou executa o desenvolvimento, operação ou manutenção de produtos de software. As principais partes são o cliente, fornecedor, desenvolvedor, operador e pessoal de suporte de software.

Figura - Principais processos do ciclo de vida do SI

O grupo de processos auxiliares inclui processos que garantem a execução dos processos principais:

• documentação;
• gerenciamento de configurações;
• Garantia da Qualidade;
• verificação;
• certificação;
• nota;
• auditoria;
• Solução de problemas.

O grupo de processos organizacionais inclui os processos:

• gerenciamento de projetos;
• criação de infraestrutura de projeto;
• definir, avaliar e melhorar o próprio ciclo de vida;
• Educação.

No texto do GOST 12207-99 O trabalho que faz parte dos processos principais, auxiliares e organizacionais é caracterizado de forma muito geral, na verdade, apenas suas direções são delineadas, portanto, para iniciar o design, serão necessárias normas e literatura adicional que revelem o conteúdo de cada processo individual ou, melhor ainda, trabalho individual.
Do grupo de processos principais, o processo de desenvolvimento é o de maior interesse.
Deve-se notar que GOST 34.601-90 “Sistemas automatizados. Etapas de criação" o processo de criação de um sistema automatizado é dividido nas seguintes etapas:

• formação de requisitos para alto-falantes,
• desenvolvimento do conceito AC,
• tarefa técnica,
• design preliminar,
• projeto técnico,
• documentação de trabalho,
• comissionamento,
• acompanhamento.

As etapas são divididas em etapas, cujo conteúdo se sobrepõe ao conteúdo de uma série de tarefas descritas no GOST 12207-99.

Processo de desenvolvimento

processo de desenvolvimento dispõe sobre ações e tarefas executadas pelo desenvolvedor e abrange trabalhos de criação do software e seus componentes de acordo com requisitos especificados, incluindo a preparação de documentação de projeto e operacional; preparação de materiais necessários para testar o desempenho e a qualidade adequada dos produtos de software, materiais necessários para organizar o treinamento de pessoal, etc.

Figura - Estrutura do processo de desenvolvimento

Trabalho preparatório

começa com a seleção de um modelo de ciclo de vida de PS que corresponda à escala, importância e complexidade do projeto. As atividades e tarefas do processo de desenvolvimento devem corresponder ao modelo escolhido. O desenvolvedor deverá selecionar, adequar-se às condições do projeto e utilizar padrões, métodos e ferramentas de desenvolvimento acordados com o cliente, bem como elaborar um plano de execução da obra.

Análise de requisitos

A análise dos requisitos de software envolve a determinação das seguintes características para cada componente de software:

• funcionalidade, incluindo características de desempenho e ambiente operacional do componente;
• interfaces externas;
• especificações de confiabilidade e segurança;
• requisitos ergonômicos;
• requisitos para os dados utilizados;
• requisitos de instalação e aceitação;
• requisitos para documentação do usuário;
• requisitos de operação e manutenção.

Projeto de arquitetura

sistema em alto nível é determinar os componentes de seus equipamentos, software e operações executadas pelo pessoal que opera o sistema. A arquitetura do sistema deve estar em conformidade com os requisitos do sistema e com os padrões e práticas de projeto aceitos.
Projetar uma arquitetura de software inclui as seguintes tarefas (para cada componente de software):

• transformação dos requisitos do software em uma arquitetura que defina em alto nível a estrutura do software e a composição de seus componentes;
• desenvolvimento e documentação de interfaces de software para sistemas de software e bases de dados;
• desenvolvimento de uma versão preliminar da documentação do usuário;
• desenvolvimento e documentação de requisitos de teste preliminares e um plano de integração de software.

Projeto detalhado

O PS inclui as seguintes tarefas:

• descrição dos componentes de software e interfaces entre eles em um nível inferior, suficiente para sua posterior codificação e teste independentes;
• desenvolver e documentar um projeto detalhado de banco de dados;
• desenvolvimento e documentação de requisitos de teste e plano de teste para componentes de software;

Codificação e teste

O PS cobre as seguintes tarefas:

• desenvolvimento (codificação) e documentação de cada componente de software e banco de dados, bem como um conjunto de procedimentos de teste e dados para testá-los;
• testar cada componente de software e banco de dados quanto à conformidade com os requisitos para eles. Os resultados dos testes dos componentes devem ser documentados;
• atualizar (se necessário) a documentação do usuário;
• atualização do plano de integração do PS.

Para cada um dos componentes agregados, conjuntos de testes e procedimentos de teste são desenvolvidos para verificar cada um dos requisitos de qualificação durante os testes de qualificação subsequentes. Um requisito de qualificação é um conjunto de critérios ou condições que devem ser atendidos para qualificar um produto de software como atendendo às suas especificações e pronto para uso em campo.

GOST R ISO/IEC 12119-2000 “Tecnologia da informação. Pacotes de software. Requisitos de qualidade e testes" contém instruções que determinam o procedimento para testar um produto quanto à conformidade com seus requisitos de qualidade. O teste é um processo trabalhoso. Segundo alguns especialistas, a percentagem
A distribuição do tempo entre os processos de design – desenvolvimento – teste está na proporção 40-20-40. Nesse sentido, os sistemas de automação de testes estão se difundindo. O padrão IEEE 1209-1992, “Práticas Recomendadas para Avaliação e Seleção de Ferramentas CASE”, estabelece requisitos gerais para a funcionalidade de ferramentas de automação de testes.

Integração de sistema

consiste na montagem de todos os seus componentes, incluindo subestações e equipamentos. Após a integração, o sistema, por sua vez, passa por testes de qualificação para atendimento a um conjunto de requisitos para o mesmo. Ao mesmo tempo, também é preparado e verificado um conjunto completo de documentação do sistema.

Instalação do sistema

realizado pelo desenvolvedor de acordo com o plano no ambiente e nos equipamentos previstos no contrato. Durante o processo de instalação, a funcionalidade do software e dos bancos de dados é verificada.

Aceitação do sistema

prevê a avaliação dos resultados dos testes de qualificação do software e sistema e a documentação dos resultados da avaliação, que são realizados pelo cliente com o auxílio do desenvolvedor. O desenvolvedor realiza a transferência final do software ao cliente de acordo com o contrato, ao mesmo tempo que fornece o treinamento e suporte necessários. Nosso curso tem como objetivo principal um exame detalhado das quatro primeiras obras do processo de desenvolvimento de software. Cada um desses trabalhos será dedicado a uma seção separada, e agora para posterior apresentação é necessário dizer algumas palavras sobre os modelos de ciclo de vida do PS.

Modelos de ciclo de vida de software

Modelo de ciclo de vida– uma estrutura que determina a sequência de processos, trabalhos e tarefas executadas ao longo do ciclo de vida de um sistema de informação, bem como as relações entre eles.

Até o momento, dois modelos principais de ciclo de vida tornaram-se mais difundidos:

• modelo em cascata (cascata);
• modelo espiral.

Modelo cascata

Modelo cascata demonstra uma abordagem clássica para o desenvolvimento de vários sistemas em diversas áreas de aplicação. Para o desenvolvimento de sistemas de informação, este modelo foi amplamente utilizado na década de 70 e na primeira metade da década de 80. É o modelo em cascata que forma a base da série GOST 34.xxx e do padrão DOD-STD-2167A do Departamento de Defesa dos EUA. Processa GOST 12207-99 em GOST 34.601-90 “Sistemas automatizados. Etapas da criação" são chamados de estágios e diferem ligeiramente na composição.
O modelo em cascata prevê a organização sequencial dos processos. Além disso, a transição para o próximo processo ocorre somente após todo o trabalho no anterior estar completamente concluído. Cada processo termina com a liberação de um conjunto completo de documentação, suficiente para que o trabalho possa ser continuado por outra equipe de desenvolvimento.

A principal desvantagem do modelo em cascata é que erros e deficiências em qualquer etapa aparecem, via de regra, nas etapas subsequentes da obra, o que leva à necessidade de retrocesso. Segundo a consultoria The Standish Group, em 1998, nos Estados Unidos, mais de 28% dos projetos de sistemas de informação corporativos (projetos de TI) terminaram em fracasso; quase 46% dos projetos de TI foram concluídos acima do orçamento (uma média de 189%); e apenas 26% dos projetos se enquadram no prazo e no orçamento atribuídos.

Além disso, as desvantagens do modelo em cascata incluem:

• dificuldade em paralelizar o trabalho;
• complexidade do gerenciamento de projetos;
• alto nível de risco e investimento pouco confiável (o retorno às etapas anteriores pode estar associado não apenas a erros, mas também a alterações ocorridas na área temática ou nos requisitos do cliente durante o desenvolvimento. Além disso, devolver o projeto para revisão por esses motivos não significa garantir que a área temática não mudará novamente quando a próxima versão do projeto estiver pronta. Na verdade, isso significa que existe a possibilidade de o processo de desenvolvimento “andar em ciclos” e o sistema nunca chegar ao ponto de comissionamento. Os custos do projeto aumentarão constantemente e o prazo de entrega do produto acabado será constantemente atrasado).

Modelo espiral

Ao contrário da cascata, envolve um processo iterativo de desenvolvimento de um sistema de informação. O modelo espiral foi proposto em meados da década de 1980 por Barry Boehm. Cada volta da espiral corresponde à criação de um fragmento ou versão de um produto de software, onde são esclarecidos os objetivos e características do projeto, determinada sua qualidade e planejado o trabalho para a próxima volta da espiral. A cada iteração, os detalhes do projeto são aprofundados e especificados de forma consistente, e dados métricos são coletados, que são usados ​​para otimizar as iterações subsequentes. Contudo, os mecanismos para garantir a integridade da documentação tornam-se mais complicados (quando um determinado requisito ou definição é dado no texto apenas uma vez), o que requer a utilização de ferramentas especiais.
Principais características do modelo espiral:

• recusa em fixar requisitos e atribuir prioridades aos requisitos do usuário;
• desenvolver uma sequência de protótipos começando pelos requisitos de maior prioridade;
• identificação e análise de risco em cada iteração;
• Avaliar os resultados ao final de cada iteração e planejar a próxima iteração.

Desenvolvimento de Aplicação Rápida

Na década de 90 do século 20, uma tecnologia prática chamada “desenvolvimento rápido de aplicações” - RAD (Rapid Application Development) foi fundada com base no modelo espiral. Neste caso, o ciclo de vida consistiu em quatro etapas:

• análise e planejamento de requisitos,
• projeto,
• implementação,
• implementação.

Princípios básicos do RAD:

• desenvolvimento de aplicações em iterações;
• a conclusão opcional do trabalho em cada etapa do ciclo de vida do software;
• envolvimento obrigatório dos usuários no processo de desenvolvimento;
• a utilização de ferramentas de gerenciamento de configuração que facilitam a realização de alterações no projeto e a manutenção do sistema finalizado;
• o uso de prototipagem para melhor compreender e satisfazer as necessidades dos usuários;
• teste e desenvolvimento do projeto, realizados simultaneamente ao desenvolvimento;
• desenvolvimento por uma equipe pequena e bem gerenciada de profissionais;
• gestão competente do desenvolvimento de sistemas, planejamento claro e controle da execução dos trabalhos.

No início de 2001, vários especialistas líderes na área de engenharia de software (Martin Fowler, Kent Beck, etc.) formaram um grupo chamado Agile Alliance para apoiar e desenvolver uma nova abordagem de design - “desenvolvimento rápido de software” (Agile Software Desenvolvimento). Uma implementação dessa abordagem é Extreme Programming (XP).

Os princípios da Extreme Programming são os seguintes:

1. A equipe consiste de três a dez programadores. Um ou mais clientes devem ser capazes de fornecer continuamente conhecimento especializado.
2. Os programas são desenvolvidos em iterações de três semanas. Cada iteração produz código funcional e testado que pode ser usado imediatamente pelos clientes. O sistema completo é enviado aos usuários finais no final de cada período de lançamento, o que pode levar de duas a cinco iterações.
3. A unidade de requisitos de software coletada é uma “história de usuário”, escrita em uma ficha, que descreve a funcionalidade do ponto de vista do usuário que pode ser desenvolvida em uma única iteração. Clientes e programadores planejam o trabalho para a próxima iteração desta forma:
   • os programadores estimam o tempo para completar cada cartão;
   • os clientes definem prioridades, alteram-nas e revisam-nas conforme necessário. O desenvolvimento de uma história começa com a discussão entre os programadores e o especialista do cliente.
4. Os programadores trabalham em pares e seguem padrões de codificação rígidos definidos no início do projeto. Eles criam testes de unidade para tudo o que escrevem e garantem que esses testes sejam executados sempre que o código for submetido ao controle de versão e gerenciamento de configuração obrigatórios.
5. Enquanto os programadores trabalham, os clientes visitam os programadores para esclarecer ideias, escrever testes de aceitação do sistema para serem executados durante a iteração e, no final da iteração, selecionar histórias para implementar na próxima iteração.
6. Todos os dias, a equipe realiza reuniões operacionais onde os programadores falam sobre o que estão fazendo, o que está indo bem e o que precisa de ajuda. Ao final de cada iteração, há outra reunião onde avaliam o que deu certo e o que precisa ser trabalhado na próxima vez. Esta lista é publicada para que todos possam ver enquanto trabalham na próxima iteração.
7. Uma pessoa da equipe é designada como “mentor”. Juntamente com os membros da equipe, ele avalia o uso de técnicas básicas: programação e teste em pares, rotação de pares, manutenção simples de soluções de design, comunicação, etc. com o propósito de melhoria contínua do processo de desenvolvimento.

A abordagem de desenvolvimento rápido de software não é universal e é aplicável apenas a projetos de uma determinada classe. Para caracterizar tais projetos, Alistair Coburn introduziu dois parâmetros – criticidade e escala.
A criticidade é determinada pelas consequências causadas por defeitos no software e pode ter um de quatro níveis:

• C – defeitos causam perda de comodidade;
• D – defeitos causam perda de recursos recuperáveis ​​(materiais ou financeiros);
• E – defeitos causam perda de fundos insubstituíveis;
• L – os defeitos representam uma ameaça à vida humana.

A escala é determinada pelo número de desenvolvedores participantes do projeto:

• de 1 a 6 pessoas – pequeno porte;
• de 6 a 20 pessoas – porte médio;
• mais de 20 pessoas – grande escala.

Segundo Coburn, o desenvolvimento rápido de software só é aplicável a projetos de pequeno e médio porte com baixa criticidade (C ou D). Isso significa que as tecnologias RAD e XP são mais adequadas para projetos relativamente pequenos desenvolvidos para um cliente específico, e não são aplicáveis ​​à construção de programas de cálculo complexos, sistemas operacionais ou programas para gerenciamento de objetos complexos em tempo real, bem como sistemas dos quais a segurança depende. de pessoas.

Processo unificado de desenvolvimento de software

Atualmente, o trabalho continua para criar algum tipo de processo universal de desenvolvimento de SI. Em 1999 Os funcionários da Rational Ivar Jacobson, Gradi Booch e James Rumbaugh publicaram o livro Unified Software Development Process, que foi traduzido para o russo e publicado pela editora Peter em 2002. O Processo Unificado é uma tentativa de combinar modelos em cascata e iterativos J C.

Ao mesmo tempo, o ciclo de vida é dividido em 4 fases:

1. Começo:é realizada uma avaliação inicial do projeto.
   • é criado um modelo simplificado de casos de uso contendo os casos de uso mais críticos do ponto de vista de implementação;
   • é criada uma versão de teste da arquitetura contendo os subsistemas mais importantes;
   • os riscos são identificados e priorizados;
   • a fase de projeto está planejada;
   • todo o projeto como um todo é avaliado aproximadamente;
2. esclarecimento (elaboração): a maioria dos casos de uso é descrita detalhadamente e a arquitetura do sistema é desenvolvida. No final da fase de design, o gerente de projeto calcula os recursos necessários para concluir o projeto. É necessário responder à questão: os casos de uso, a arquitetura e o plano estão suficientemente desenvolvidos para que seja possível dar obrigações contratuais à execução do trabalho e proceder à preparação e assinatura das “Especificações Técnicas”?;
3. construção– criação de produtos. Ao final desta fase, o produto inclui todos os casos de uso que os desenvolvedores e o cliente decidiram incluir na versão atual;
4. implementação (transição)- lançamento do produto. A versão beta do produto é testada pelo departamento de testes da empresa e ao mesmo tempo é organizada a operação experimental do sistema pelos usuários. Os desenvolvedores então corrigem quaisquer bugs que encontrarem e incorporam algumas das melhorias sugeridas em uma versão principal que está pronta para ampla distribuição.

Cada fase do USDP pode incluir uma ou mais iterações, dependendo do tamanho do projeto. Durante cada iteração, 5 threads de trabalho principais e vários threads de trabalho adicionais podem ser executados.
Os principais fluxos de trabalho no USDP incluem:

• definição de requisitos (RD);
• análise (A);
• projeto (P);
• implementação (P);
• teste (T).

Tópicos de trabalho adicionais podem incluir:

• trabalho de garantia de qualidade (K),
• documentação (D),
• gerenciamento de projetos (P),
• gerenciamento de configuração (CM),
• criação e gestão de infraestrutura (I)
• e outros.

Figura - Modelo de ciclo de vida de acordo com o processo unificado de desenvolvimento de software

A escolha do modelo de ciclo de vida depende em grande parte do tipo e escala do sistema que está sendo desenvolvido. Para o desenvolvimento da maioria dos sistemas de controle automatizados com tempo livre, o modelo de ciclo de vida iterativo é aplicável, enquanto o modelo em cascata é mais adequado para sistemas de tempo real. Durante as palestras, ao estudar questões de design de SI, daremos atenção especial ao uso da Linguagem de Modelagem Unificada (UML), e como seus criadores são Grady Booch e James Rumbaugh, também nos voltaremos para a ideologia do Processo de Desenvolvimento Unificado.

Figura - Documentos normativos que acompanham o processo de desenvolvimento

Apoiando processos de ciclo de vida

Processo de Garantia de Qualidade

Processo de garantia de qualidade fornece garantias apropriadas de que o sistema de software e seus processos de ciclo de vida atendem aos requisitos especificados e aos planos aprovados. A qualidade do software é entendida como um conjunto de propriedades que caracterizam a capacidade do software em satisfazer requisitos especificados.

Figura - Estrutura dos processos auxiliares do ciclo de vida

No contexto do GOST R ISO/IEC 9126-93. "Tecnologia da Informação. Avaliação de produtos de software. Características de qualidade e diretrizes para seu uso" característica de qualidade é entendida como "um conjunto de propriedades (atributos) de um produto de software pelo qual sua qualidade é descrita e avaliada".

A norma define seis características abrangentes que descrevem a qualidade do software com duplicação mínima:

• funcionalidade– um conjunto de atributos relacionados com a essência do conjunto de funções e suas propriedades específicas. Funções são aquelas que realizam necessidades declaradas ou antecipadas;
• confiabilidade– um conjunto de atributos relacionados com a capacidade do software para manter o seu nível de desempenho sob condições específicas durante um período de tempo especificado;
• praticidade– um conjunto de atributos relacionados com o âmbito do trabalho necessário para a utilização e a avaliação individual dessa utilização por um grupo específico ou pretendido de utilizadores;
• eficiência– um conjunto de atributos relacionados à relação entre o nível de qualidade da operação do software e a quantidade de recursos utilizados sob condições especificadas
• manutenibilidade– um conjunto de atributos relacionados ao escopo do trabalho necessário para realizar mudanças (modificações) específicas;
• mobilidade– um conjunto de atributos relacionados à capacidade do software de ser transferido de um ambiente para outro.

GOST 28195-89 “Avaliação da qualidade do software. Disposições gerais" no primeiro nível superior, identifica 6 indicadores - fatores de qualidade: confiabilidade, correção, facilidade de uso, eficiência, versatilidade e facilidade de manutenção. Estes factores são detalhados colectivamente por 19 critérios de qualidade no segundo nível. O detalhamento adicional dos indicadores de qualidade é representado por métricas e elementos de avaliação, dos quais existem cerca de 240. Recomenda-se que cada um deles seja avaliado por especialistas variando de 0 a 1. Propõe-se que a composição dos fatores, critérios e métricas utilizados seja selecionada. dependendo da finalidade, funções e estágios do ciclo de vida do software.

O padrão GOST 28806-90 “Qualidade de software. Termos e definições" são formalizados os conceitos gerais de programa, ferramenta de software, produto de software e sua qualidade. São fornecidas definições dos 18 termos mais comumente usados ​​associados à avaliação das características do programa. Os conceitos de indicadores básicos de qualidade fornecidos no GOST 28195-89 foram esclarecidos.
A questão de garantir a qualidade do software requer atenção especial, pois de acordo com o Governo da Federação Russa nº 113 de 02/02/1998, o cumprimento dos requisitos da norma internacional de garantia e gestão de qualidade ISO 9000 é um pré-requisito para receber uma ordem governamental.
Na fase actual, não basta ter apenas métodos de avaliação da qualidade do software produzido e utilizado (controlo de produção); é necessário poder planear a qualidade, medi-la em todas as fases do ciclo de vida do software e ajustar o processo de produção de software para melhorar a qualidade.

A série de normas ISO 9000 é muito genérica. Cada empresa que produz software e deseja implementar um sistema de gestão de qualidade eficaz baseado nos padrões da série ISO 9000 deve levar em consideração as especificidades de sua indústria e desenvolver um sistema de indicadores de qualidade que reflita o impacto real dos fatores de qualidade no produto de software. Para este fim, muitas organizações estabeleceram um processo de verificação separado, sistemático e abrangente – Garantia de Qualidade – que começa com o lançamento do projeto, envolve inspeção e testes e é idealmente conduzido por alguma organização independente. Na realidade, na maioria das vezes, o controle de qualidade é realizado por um grupo de colegas do autor da obra.
O objetivo da inspeção é verificar se há defeitos em partes do projeto:

• documentação,
• requisitos,
• resultados da análise,
• projeto,
• listagens, etc.

A relevância da inspeção é demonstrada pela comparação do custo e pela detecção e correção de um defeito durante a inspeção e durante a integração, de acordo com Fagin, M., “Design and Code Inspections to Reduce Erros in Program Development”, IBM Systems Journal. Alguns autores consideram estes dados muito subestimados.

A questão de encontrar defeitos começou a ser levada muito mais a sério depois que um satélite americano no valor de vários bilhões de dólares, enviado a Vênus, perdeu o controle devido a um erro de digitação na sub-rotina de correção de trajetória - foi inserido um ponto e vírgula em vez de uma vírgula.
A avaliação e melhoria da qualidade são realizadas por meio de métricas - características quantitativas de determinados indicadores de processo.

Para realizar uma inspeção, são necessárias as seguintes etapas:

1. O processo de inspeção começa com o planejamento. Uma classificação de defeitos por descrição, gravidade e tipo está sendo desenvolvida. São realizadas a seleção das métricas pelas quais será realizada a fiscalização, a seleção das ferramentas de coleta e análise dos dados obtidos, bem como a distribuição de funções entre os fiscais:
   • O líder é responsável pela correta condução da fiscalização.
   • O revisor é responsável pelas atividades da equipe e as direciona na direção certa. O revisor participa da inspeção.
   • O registrador é responsável por registrar a descrição e classificação dos defeitos, como é de praxe na equipe. O registrador também participa da fiscalização.
   • Um inspetor especializado é um especialista em uma determinada área restrita à qual pertence o fragmento inspecionado.
2. Se necessário, pode ser organizado um workshop de revisão para melhor compreender o tema da inspeção.
3. Realizando uma inspeção. Os inspetores verificam todo o trabalho nos seus locais de trabalho (por exemplo, verificando se o código do programa inspecionado corresponde ao projeto detalhado). Os inspetores normalmente registram todos os defeitos em um banco de dados (por exemplo, acessível através de uma rede), juntamente com descrições e classificações. As partes inspecionadas do sistema devem estar logicamente completas.
4. É realizada uma reunião de fiscalização durante a qual os participantes apresentam seus resultados.
5. O autor corrige defeitos (fase de revisão).
6. Na reunião final após a conclusão do trabalho, o revisor e o autor certificam-se de que todos os defeitos foram corrigidos. No entanto, isso não implica uma revisão detalhada de todo o trabalho por um revisor. Todas as correções ficam a cargo do autor, que é responsável pelo seu trabalho.
7. Tal como acontece com outros processos, o grupo reúne-se para discutir o próprio processo de inspeção e decidir como pode ser melhorado.

A empresa mantém registros do tempo gasto em inspeções e da quantidade de trabalho inspecionado para uso posterior na avaliação de inspeções futuras. Sob condições de rigorosas restrições de tempo, os chamados um sistema de “tutela” em que cada membro da equipe é cuidado por seu colega.
Para levar em conta todos os fatores de controle de qualidade, é conveniente utilizar listas de verificação. Essas listas contêm itens que precisam ser verificados sequencialmente.
Por exemplo, o Plano de Garantia de Qualidade de Software (SQAP) de acordo com o padrão IEEE 739-1989 especifica:

• quem será o responsável pela qualidade – um indivíduo, um gestor, um grupo, uma organização, etc.;
• qual documentação é necessária;
• quais métodos serão utilizados para garantir a qualidade – inspeção, testes, etc.;
• quais atividades devem ser realizadas durante a gestão de processos – reuniões, auditorias, revisões, etc.

Confiabilidade e segurança

Uma das características mais significativas incluídas no conceito de qualidade é a propriedade de confiabilidade.
De acordo com a definição estabelecida em GOST 13377-75 “Confiabilidade em tecnologia. Termos e definições”, confiabilidade é propriedade de um objeto de desempenhar funções específicas, mantendo ao longo do tempo os valores dos indicadores operacionais estabelecidos dentro de limites especificados correspondentes a modos e condições especificados de uso, manutenção, reparo, armazenamento e transporte. Assim, a confiabilidade é uma propriedade interna do sistema, inerente durante sua criação e que se manifesta ao longo do tempo durante a operação e operação.
A confiabilidade da operação de uma subestação é mais amplamente caracterizada pela estabilidade, ou pela capacidade de operar sem falhas, e pela capacidade de restauração de um estado operacional após a ocorrência de falhas ou falhas.
O monitoramento da confiabilidade e segurança dos programas criados e modificados deve acompanhar todo o ciclo de vida do software por meio de um sistema tecnológico eficaz especialmente organizado para garantir sua qualidade. A verificação e confirmação da qualidade de software complexo e crítico devem ser asseguradas pela certificação por laboratórios certificados e orientados para problemas.

Os padrões de segurança da informação são divididos em dois grupos:

• padrões de avaliação projetados para avaliar e classificar equipamentos IP e de segurança de acordo com requisitos de segurança - o padrão do Departamento de Defesa dos EUA “Critérios para avaliação de sistemas de computador confiáveis”, “Critérios harmonizados de países europeus”, o padrão internacional “Critérios para avaliar a segurança de tecnologias de informação”, Documentos orientadores da Comissão Técnica Estatal da Rússia;
• especificações que regem vários aspectos da implementação e uso de ferramentas e técnicas de segurança, publicadas pela Internet Engineering Task Force (IETF) e suas subdivisões, o Grupo de Trabalho de Segurança.

Os padrões de avaliação mais significativos incluem:

• Comissão Técnica Estadual da Rússia. Documento orientador. Instalações informáticas. Firewalls. Proteção contra acesso não autorizado às informações. Indicadores de segurança contra acesso não autorizado à informação. – Moscou, 1997 – classifica os firewalls de acordo com o nível de filtragem do fluxo de dados do modelo de referência de sete níveis.
• ISO/IEC 15408:1999 Critérios para avaliar a segurança da tecnologia da informação.

O segundo grupo inclui os seguintes documentos:

• X.800 “Arquitetura de segurança para interconexão de sistemas abertos.” Destacam-se os principais serviços de segurança de redes: autenticação, controle de acesso, garantia de confidencialidade e/ou integridade dos dados. Para implementar os serviços, são fornecidos os seguintes mecanismos de segurança de rede e suas combinações: criptografia, assinatura digital eletrônica, controle de acesso, controle de integridade de dados, autenticação, adição de tráfego, controle de roteamento, notarização.
• A especificação da Internet Community RFC 1510, Kerberos Network Authentication Service (V5), aborda o problema de autenticação em um ambiente distribuído heterogêneo com suporte para o conceito de logon único na rede;
• X.500 "Serviços de diretório: uma visão geral de conceitos, modelos e serviços", X.509 "Serviços de diretório: estruturas de certificados de chave pública e atributos".

Processos de verificação, certificação e auditoria

Verificação, qualificação e auditoria são parte integrante do plano de controle de qualidade SQAP IEEE 739-1989.
A verificação responde à pergunta: “Estamos fazendo o que planejamos nesta fase?” A certificação e a auditoria respondem à pergunta: “A instalação em construção atende às necessidades do cliente?”
O padrão IEEE 1012-1986 Software Verification and Validation Plan (SVVP) combina os processos de certificação e auditoria chamados validação e define como eles são realizados.

Durante o processo de verificação, as seguintes condições são verificadas:

• consistência dos requisitos do sistema e o grau em que as necessidades dos utilizadores são tidas em conta;
• a capacidade do fornecedor de atender aos requisitos especificados;
• conformidade dos processos do ciclo de vida do PS selecionados com os termos do contrato;
• adequação de padrões, procedimentos e ambiente de desenvolvimento aos processos do ciclo de vida do PS;
• conformidade das especificações de projeto da subestação com os requisitos especificados;
• correção da descrição nas especificações de projeto dos dados de entrada e saída, sequência de eventos, interfaces, lógica, etc.;
• conformidade do código com especificações e requisitos de projeto;
• testabilidade e exatidão do código, sua conformidade com os padrões de codificação aceitos;
• integração correta de componentes de software no sistema;
• adequação, integridade e consistência da documentação.

Processo de revisão conjunta

Processo de revisão conjunta tem como objetivo avaliar o estado dos trabalhos de um projeto e tem como foco principal o monitoramento do planejamento e gerenciamento de recursos, pessoal, equipamentos e ferramentas do projeto.
A avaliação é aplicada tanto durante a gestão do projeto como durante a execução técnica do projeto e é realizada durante toda a duração do contrato. Este processo pode ser realizado por quaisquer duas partes envolvidas no contrato, com uma parte verificando a outra.

Processo de resolução de problemas

Processo de resolução de problemas envolve a análise e resolução de problemas (incluindo inconsistências detectadas) independentemente da sua origem ou fonte, que são descobertos durante o desenvolvimento, operação, manutenção ou outros processos. O processo de resolução de problemas está intimamente relacionado ao gerenciamento de riscos. Os fatores que levam ao fracasso do projeto manifestam-se na forma de riscos. A gestão de riscos consiste em identificação, planejamento de eliminação, priorização, eliminação (ou mitigação).

As razões para o surgimento de riscos podem ser as seguintes:

1. Formulação de requisitos pouco clara e/ou incompleta;
2. Envolvimento insuficiente das partes interessadas no projeto;
3. Mau planeamento – falta de gestão de projetos competente;
4. Mudanças frequentes nos requisitos causadas por mudanças no escopo, objetivos do projeto e outros motivos;
5. Imperfeição da tecnologia de design utilizada;
6. Falta de conhecimento ou habilidades entre os artistas.

Existem duas maneiras de prevenir riscos:

1. fazer alterações nos requisitos do projeto que eliminem a causa do risco;
2. desenvolvimento de tecnologias que resolvam o problema associado ao surgimento de riscos.

Durante o processo de gerenciamento do projeto, o gerente deve, de tempos em tempos, iniciar o processo de identificação de riscos em diversas partes do projeto, a fim de compilar uma lista de riscos que aguardam tratamento. Para cada risco são determinados três valores: a probabilidade de ocorrência do risco; danos causados ​​ao projeto por esse risco, caso ele ocorra; estimar o custo de eliminar o risco. Todos os valores usam a mesma escala, por exemplo 1 – 10.

Processo de gerenciamento de documentação e configuração

“Gerenciar a documentação do projeto de software requer esforços organizacionais significativos, porque... a documentação é um sistema complexo, sujeito a constantes alterações que podem ser feitas simultaneamente por muitas pessoas" (E. Braude)

O processo de documentação prevê uma descrição formalizada das informações criadas durante o ciclo de vida do PS. Este processo consiste em um conjunto de atividades que planejam, projetam, desenvolvem, produzem, editam, distribuem e mantêm documentos necessários a todas as partes interessadas (gestores, especialistas técnicos e usuários do sistema).

GOST R ISO/IEC 9294-93. "Tecnologia da Informação. Guia de gerenciamento de documentação de software" estabelece recomendações para o gerenciamento eficaz da documentação de software. O objetivo da norma é auxiliar na definição de uma estratégia para documentação de software; escolha de padrões de documentação; escolha de procedimentos de documentação; determinar os recursos necessários; elaboração de planos de documentação.

Gerenciamento de documento significa mantê-lo completo e consistente (alguns autores incluem aqui o gerenciamento de configuração).

Completude da documentação caracterizado pela quantidade de padrões e documentos regulatórios que formam a base do conjunto de documentação que acompanha um determinado processo no ciclo de vida do software.
Consistência da Documentação significa que o conjunto de documentos não contém contradições internas. Isto é conseguido colocando cada especificação em apenas um lugar – isso é chamado de documentação holística. A integridade da documentação é garantida através da utilização de hiperlinks.

Cada requisito deve ser rastreável Para conseguir isso, cada requisito recebe um número exclusivo, que é então referenciado durante o desenvolvimento do conceito, design e até listagens de métodos.

• //requisito 4.3
• //autor
• // versão
• // argumentos
• ...lista de métodos...

As partes do projeto incluem não apenas o código-fonte dos programas, mas também toda a documentação, incluindo o plano do projeto. Durante sua vida, os projetos passam por mudanças em duas direções:

• Em primeiro lugar, trata-se da aquisição de novas peças,
• Em segundo lugar, obter novas versões de peças existentes. Para rastrear corretamente essas alterações, é utilizado um conjunto especialmente organizado de procedimentos administrativos e técnicos relacionados ao processo de gerenciamento de configuração.

Para acompanhar partes de um projeto, é necessário definir seus limites e identificar itens de configuração (Itens de Configuração - ICs). Os elementos de configuração podem ser classes, menos frequentemente funções, conjuntos de dados significativos - tabelas globais, documentação. A contabilização do estado da configuração é realizada registrando o estado dos componentes de software, preparando relatórios sobre todas as modificações implementadas e rejeitadas de versões dos componentes de software. Um conjunto de relatórios proporciona uma reflexão inequívoca do estado atual do sistema e dos seus componentes, bem como mantém um histórico de modificações.
Existem ferramentas de software especiais para gerenciamento de configuração (por exemplo, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion, etc.).

Normalmente, os sistemas de gerenciamento de configuração atendem aos seguintes requisitos mínimos:

• a capacidade de definir elementos de configuração;
• armazenar no banco de dados de gerenciamento de configuração cronologias completas de versões de cada objeto criado ou alterado durante o processo de desenvolvimento do sistema (isso inclui código-fonte do programa, bibliotecas, programas executáveis, modelos, documentação, testes, páginas web e diretórios);
• suporte para equipes de desenvolvimento geograficamente remotas;
• negação de direitos de modificação para impedir que mais de uma pessoa trabalhe em um item de configuração ao mesmo tempo;
• controle das alterações feitas em todos os objetos do sistema;
• montagem de versões de software a partir de componentes do projeto.

IEEE desenvolveu o padrão IEEE 828-1990“Plano de gerenciamento de configuração de software (SCMP).” O título do padrão e um exemplo de Plano de Gerenciamento de Configuração são fornecidos no livro de Eric Braude.

Figura - Documentos regulatórios dos processos auxiliares do ciclo de vida

Processos do ciclo de vida organizacional

Os processos organizacionais do ciclo de vida incluem: o processo de criação de infraestrutura, o processo de melhoria, o processo de formação, o processo de gestão.

Figura - Estrutura dos processos do ciclo de vida organizacional

Processo de criação de infraestrutura

é o processo de estabelecimento e fornecimento (manutenção) de infraestrutura, que pode conter hardware e software, ferramentas, metodologias, padrões e condições para desenvolvimento, operação ou manutenção. Na 1ª fase de criação da infraestrutura é feita a escolha de um sistema de apoio ao projeto CASE, a escolha de uma linguagem de programação e de um SGBD; organização de serviços de suporte - administradores de sistema, administradores de rede, administradores de banco de dados, secretárias, etc.
Ao resolver o problema de seleção por meio de fontes literárias, é necessário analisar as capacidades dos sistemas instrumentais mais comuns para construir uma classificação e, a seguir, dentro de um determinado grupo de classificação, determinar os parâmetros pelos quais a seleção será feita.
O próprio procedimento de seleção inclui as seguintes etapas:

1. São identificados os indicadores básicos do sistema selecionado, que são significativos na concepção de um determinado ACS, tendo em conta as suas características, limitações, recursos, etc.
2. Todos os indicadores estão resumidos em uma tabela (ver Tabela 5), ​​na qual, com base nas avaliações de especialistas, é atribuído a cada indicador um coeficiente de peso Vi (por exemplo, de 1 a 10), que caracteriza a significância deste indicador em relação aos demais. A soma dos valores de todos os coeficientes de ponderação deve ser igual ao limite superior do coeficiente de ponderação (por exemplo, 10).
3. Utilizando dados obtidos de fontes literárias e/ou de especialistas, para cada i-ésimo indicador de cada j-ésimo sistema, é determinado o grau de utilidade Ui,j (de 1 - mínimo, a 10 - máximo). Por exemplo, um sistema de gerenciamento de configuração relativamente caro pode ter uma classificação de utilidade 1, enquanto um sistema disponível gratuitamente teria uma classificação de utilidade 10.
4. Para cada j-ésimo sistema comparado, o valor da função de avaliação é calculado usando a fórmula: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Com base no valor da função de avaliação, conclui-se sobre a conveniência de utilizar um determinado sistema num determinado projeto, tendo em conta os critérios selecionados e as restrições especificadas. O sistema para o qual o valor da função de avaliação é maior é o melhor em termos de escolha entre as alternativas comparadas.

Processo de aprendizado

é o processo de fornecer treinamento inicial e contínuo ao pessoal. O pedido, entrega, desenvolvimento, operação e manutenção de produtos de software dependem em grande parte das qualificações do pessoal. Portanto, o treinamento do pessoal deve ser planejado e realizado com antecedência, a fim de prepará-lo para o trabalho de encomenda, fornecimento, desenvolvimento, operação ou manutenção de um projeto de software.

Processo de melhoria

é o processo de estabelecer, avaliar, medir, controlar e melhorar qualquer processo do ciclo de vida de software. Na prática da engenharia, no desenvolvimento de SI, são utilizadas métricas - características quantitativas de determinados indicadores.

As métricas mais comumente usadas são:

• a quantidade de trabalho executado, medida em unidades físicas (por exemplo, o número de linhas de código);
• tempo gasto no trabalho;
• taxa de defeitos (por exemplo, número de defeitos por 1.000 linhas de código, número de defeitos por página de documentação, etc.).

Os valores métricos preliminares ou desejados são previstos antecipadamente e depois comparados com os resultados obtidos.
Como as métricas relacionadas à defeituosidade desempenham um papel especial, listamos algumas delas:

1. O número de defeitos por mil linhas de código de software identificadas dentro de 12 semanas após a entrega do projeto.
2. Desvios no cronograma em cada fase: (Duração real - Duração prevista) / Duração prevista.
3. Desvios de custo: (Custo real - Custo planejado) / Custo planejado.
4. Tempo total de design / Tempo total de programação (de acordo com algumas estimativas, deve ser de pelo menos 50%).
5. O grau em que os defeitos aparecem e são detectados em algum estágio é uma das métricas mais simples.

Quando os resultados da detecção de defeitos são comparados com os padrões da organização, todo o processo de criação do sistema como um todo é avaliado, e não apenas um projeto específico. Os dados acumulados sobre defeitos em cada etapa são tabulados conforme mostrado, por exemplo, na tabela.

Análise da etapa “Formação de Requisitos” mostra que o grau de detecção de defeitos é menor que o normal em todas as fases do projeto. Mais defeitos de projeto foram encontrados imediatamente na fase em que foram produzidos e menos defeitos foram encontrados em fases posteriores. Normalmente, isso é conseguido através de inspeção.

A sequência de ações que precisam ser tomadas ao longo do ciclo de vida do projeto para melhorá-lo poderia, por exemplo, ser assim:

1. Identificar e definir métricas que serão utilizadas pela equipe em cada fase, incluindo:
   • tempo gasto em pesquisa, implementação e análise de resultados;
   • tamanho (por exemplo, número de linhas de código);
   • o número de defeitos detectados no módulo (por exemplo, número de linhas de código) e a fonte da detecção do defeito;
   • classificação de qualidade em uma escala de 1 a 10.
2. Documente as informações recebidas no SQAP.
3. Colete estatísticas em cada fase.
4. Designe desenvolvedores responsáveis ​​pela coleta de dados em cada fase, por exemplo, “oficial de qualidade”.
5. Planeje revisões de dados métricos que serão úteis no futuro. É preciso decidir antecipadamente quais podem ser e quais deveriam ser os valores das métricas. Os dados obtidos servirão de base para a criação de um banco de dados de projetos da empresa.

Modelo de maturidade de capacidade organizacional

O processo de melhoria da tecnologia de criação de software reflete-se nos planos estratégicos da organização, na sua estrutura, nas tecnologias utilizadas, na cultura social geral e no sistema de gestão.
No início da década de 1990, o American Software Engineering Institute (SEI da Carnegie Mellon University (Pittsburgh, Pensilvânia, EUA)) formou um modelo de maturidade tecnológica das organizações CMM (Capability Maturity Model). Atualmente, no Ocidente, uma empresa de desenvolvimento enfrenta dificuldades significativas para obter um pedido se não for certificada pelo CMM.
CMM é um material metodológico que define as regras para a formação de um sistema de gestão para criação e manutenção de softwares e métodos para melhoria gradual e contínua da cultura produtiva. O objetivo do CMM é fornecer às organizações de desenvolvimento as instruções necessárias para a escolha de uma estratégia de melhoria da qualidade dos processos, analisando o grau de sua maturidade tecnológica e os fatores que mais influenciam a qualidade dos produtos. Em cada nível do SMM são estabelecidos requisitos cujo cumprimento garante a estabilização dos indicadores de processo mais significativos.

Processo de gestão

O gerenciamento de projetos trata de alcançar um equilíbrio entre custo, capacidades, qualidade e cronograma. Existem vários aspectos associados ao processo de gerenciamento de projetos: gerenciamento de pessoal, cronograma, estimativa de custos do projeto.

Gestão de Pessoal

Sabe-se que dados empíricos determinam o número ideal de membros da equipe.

Figura - Dependência da eficácia da equipe de desenvolvimento de sua composição

Esta dependência leva à necessidade de utilização de estruturas hierárquicas de gestão

Figura - Estrutura hierárquica de gestão

Apesar de o número de ligações de cada funcionário ser satisfatório, eles não participam da formulação do problema, o que viola um dos principais requisitos da análise de sistemas - o máximo número possível de stakeholders deve participar da discussão do problema.
Um esquema alternativo para organizar uma equipe de funcionários é chamado de “equipe de iguais”. Neste caso, todos os membros da equipe estão no mesmo nível da hierarquia e as funções são distribuídas entre eles. Além disso, a distribuição de funções pode mudar após um determinado período de tempo. O problema de aumentar o número de comunicações em um grande projeto, neste caso, é resolvido destacando o papel do responsável pelas comunicações externas.

No conceito de programação extrema proposto por Kent Beck. a ênfase está no relacionamento contínuo entre os desenvolvedores e o cliente (e o cliente passa a ser um dos participantes do desenvolvimento), o desejo de simplificar radicalmente o processo de desenvolvimento do sistema e a programação em pares. Além disso, com a programação em pares, os desenvolvedores trabalham juntos apenas em um computador, revezando-se. Isso implementa uma forma de inspeção contínua.

Preparando um cronograma

Existem muitos padrões que descrevem a criação e manutenção de planos de gerenciamento de projetos de software. Recomenda-se usar o Plano de Gerenciamento de Projetos de Software (SPMP) IEEE 1058.1-1987. O SPMP fornece um cronograma que define como e quando as diversas etapas do projeto devem ser concluídas. Após a conclusão de cada etapa subsequente do projeto, o cronograma precisa ser complementado e ajustado. A forma mais comum de apresentar o cronograma do projeto é um gráfico de Gantt.

Figura - Visão aproximada de um gráfico de Gantt

Recomenda-se que o plano inclua períodos de buffer quando nenhum processo estiver programado para execução. Um cronograma na forma de gráfico de Gantt é, na maioria dos casos, criado usando o Microsoft Office Project.
O processo de planejamento do trabalho de implementação de um projeto em particular e de gerenciamento de projetos em geral está associado à estimativa do custo e da duração do projeto. Esta informação é fornecida na seção 5.4. A “alocação de orçamento e recursos” do SPMP e, adicionalmente, uma avaliação preliminar do custo do projeto podem afetar a versão final do contrato entre o cliente e o empreiteiro e, portanto, devem ser realizadas antes da assinatura dos termos de referência.

Estimativa de custos para criação de um PS

O processo de estimativa da intensidade de trabalho, via de regra, começa simultaneamente com o início do projeto e continua ainda na fase de escrita do código do programa.

Entre os métodos mais comuns para avaliar a intensidade do trabalho estão os seguintes:

• Modelagem algorítmica. O método é baseado na análise de dados estatísticos de projetos concluídos anteriormente, e é determinada a dependência da intensidade de trabalho do projeto em algum indicador quantitativo do produto de software (geralmente o tamanho do código do programa). Este indicador é avaliado para um determinado projeto, após o qual os custos futuros são previstos através do modelo.
• Avaliações de especialistas.É realizada uma pesquisa com vários especialistas em tecnologia de desenvolvimento de software que conhecem o escopo de aplicação do produto de software que está sendo criado. Cada um deles dá sua própria avaliação da intensidade de mão de obra do projeto. Em seguida, todas as estimativas são comparadas e discutidas.
• Avaliação por analogia. Este método é utilizado caso projetos semelhantes já tenham sido implementados em uma determinada área de aplicação do software que está sendo criado. O método baseia-se na comparação do projeto planejado com projetos anteriores que possuem características semelhantes. Ele usa dados de especialistas ou dados de projetos armazenados. Os especialistas calculam uma estimativa de esforço alto, baixo e mais provável com base nas diferenças entre o novo projeto e os projetos anteriores.

Cada método de avaliação tem os seus pontos fortes e fracos, pelo que atualmente são utilizadas abordagens que combinam diferentes métodos.

O procedimento de avaliação da intensidade de trabalho no desenvolvimento de software consiste nas seguintes etapas:

1. estimar o tamanho do produto que está sendo desenvolvido;
2. avaliação da intensidade de trabalho em homem-mês ou homem-hora;
3. estimativa da duração do projeto em meses civis;
4. estimativa de custos do projeto.

As principais unidades de medição de tamanho de software são:

• número de linhas de código (LOC – Lines of Code);
• pontos de função (FP – Pontos de Função).

Metodologia para avaliação do tamanho funcional

Metodologia para avaliação do tamanho funcional (PF – Pontos Funcionais)é medir uniformemente todos os recursos de um aplicativo e expressar o tamanho do aplicativo como um único número. Esse número pode então ser usado para estimar o número de linhas de código, custo e cronograma do projeto.
Para calcular o tamanho funcional, a classificação e a complexidade são determinadas para cada característica de informação do sistema. O Grupo Internacional de Usuários de Pontos de Função (IFPUG, www.ifpug.org) publicou critérios para identificação de características de informação, que são divididos em cinco grupos:

• – um grupo de dados logicamente relacionados, reconhecido pelo usuário, localizado dentro da aplicação e servido por meio de entradas externas.

• – um grupo de dados logicamente relacionados, reconhecível pelo usuário, localizado e mantido por outra aplicação. O arquivo externo de um determinado aplicativo é um arquivo lógico interno em outro aplicativo.

• – um processo elementar que move dados do ambiente externo para a aplicação. Os dados podem vir através de canais de comunicação, do usuário em uma tela de entrada ou de outro aplicativo. Os dados podem ser usados ​​para atualizar arquivos lógicos internos e podem conter informações de gerenciamento e de negócios. Os dados de controle não devem modificar o arquivo lógico interno (por exemplo, campos de entrada de dados, mensagens de erro, valores calculados, botões).

• – um processo elementar que move dados calculados em uma aplicação para o ambiente externo. Além disso, arquivos lógicos internos podem ser atualizados durante esse processo. Os dados criam relatórios ou arquivos de saída que são enviados para outros aplicativos. Relatórios e arquivos são criados com base em arquivos lógicos internos e arquivos de interface externa. Além disso, esse processo pode usar dados de entrada que incluem critérios e parâmetros de pesquisa que não são suportados pelos arquivos lógicos internos. Os dados de entrada vêm de fora, mas são temporários e não são armazenados em um arquivo lógico interno (por exemplo, campos de dados em relatórios, valores calculados, mensagens de erro).

• – um processo elementar que funciona tanto com dados de entrada como de saída, consistindo numa combinação pedido-resposta, mas não associado ao cálculo de dados derivados ou à atualização do ALI. Seu resultado são dados retornados de arquivos lógicos internos e arquivos de interface externa. A parte de entrada do processo não modifica arquivos lógicos internos e a parte de saída não carrega dados calculados pela aplicação (esta é a diferença entre uma solicitação e uma saída). Por exemplo: elementos de entrada - campo utilizado para pesquisa, clique do mouse; elementos exibidos – campos exibidos na tela.

GOST R 56376-2015/IEEE C37.92(2005)

PADRÃO NACIONAL DA FEDERAÇÃO RUSSA

Conversores de medição elétrica

ENTRADAS ANALÓGICAS DE RELÉS DE PROTEÇÃO DE CONVERSORES ELETRÔNICOS DE TENSÃO E CORRENTE

Transdutores elétricos. Entradas analógicas para relés de proteção de transdutores eletrônicos de tensão e corrente

OK 17.020

Data de introdução 01/01/2016

Prefácio

Prefácio

1 PREPARADO pela Empresa Unitária do Estado Federal "Instituto de Pesquisa de Serviço Metrológico de Toda a Rússia" (FSUE "VNIIMS") com base em sua própria tradução para o russo da versão em inglês da norma especificada no parágrafo 4

2 APRESENTADO pela Comissão Técnica de Normalização TC 445 “Metrologia de uma Economia Energeticamente Eficiente”

3 APROVADO E ENTRADO EM VIGOR por Despacho da Agência Federal de Regulação Técnica e Metrologia de 27 de março de 2015 N 192-st

4 Este padrão é idêntico ao padrão internacional Padrão IEEE C37.92(2005)* “Padrão IEEE para entradas analógicas para relés de proteção” de transdutores eletrônicos de tensão e corrente", IDT).
________________
* O acesso aos documentos internacionais e estrangeiros mencionados no texto poderá ser obtido contactando o Apoio ao Cliente. - Nota do fabricante do banco de dados.


O nome deste padrão foi alterado em relação ao nome do padrão internacional especificado para torná-lo compatível com GOST R 1.5-2012 (cláusula 3.5).

Na aplicação desta norma, recomenda-se utilizar, em vez de normas internacionais de referência, as normas nacionais correspondentes, cuja informação se encontra no apêndice adicional SIM

5INTRODUZIDO PELA PRIMEIRA VEZ

6 REPUBLICAÇÃO. Abril de 2019

As regras para aplicação desta norma estão estabelecidas em Artigo 26 da Lei Federal de 29 de junho de 2015 N 162-FZ "Sobre Padronização na Federação Russa" . As informações sobre as alterações nesta norma são publicadas no índice de informações anual (a partir de 1º de janeiro do ano em curso) "National Standards", e o texto oficial das alterações e alterações é publicado no índice de informações mensal "National Standards". Em caso de revisão (substituição) ou cancelamento desta norma, o aviso correspondente será publicado na próxima edição do índice informativo mensal “Normas Nacionais”. Informações, avisos e textos relevantes também são divulgados no sistema de informação pública - no site oficial da Agência Federal de Regulação Técnica e Metrologia na Internet (www.gost.ru)

1 área de uso

1.1 Disposições gerais

Esta norma especifica as características de interface entre sistemas de medição de tensão ou corrente, sensores ópticos com saídas analógicas e relés de proteção especialmente projetados ou outros equipamentos de medição de subestações. Esses sistemas de medição produzem formas de onda proporcionais às correntes e tensões na rede elétrica.

Esta norma também especifica os requisitos para combinadores intermediários adicionais ou amplificadores de escala necessários para adicionar ou subtrair sinais das saídas de mais de um sensor de medição óptico ao medir com um único relé ou dispositivo de medição.

1.2 Metas

O sinal de medição normalizado entre o sistema de medição e os sistemas de proteção do relé é um sinal elétrico analógico com amplitude máxima de ±11,3 V e potência máxima de 3,2 mW.

Um exemplo de sistema de medição com saída eletrônica analógica é um sistema óptico de transformadores de tensão ou corrente com interface óptico-eletrônica. A Figura 1 mostra uma configuração típica de elementos de um sistema óptico de medição de corrente em uma subestação de alta tensão. Nesta configuração, os sensores ópticos dos transformadores de corrente estão localizados no barramento de alto potencial. Em outros casos, os sensores podem ser montados dentro de um transformador de potência ou isolador. Os sinais ópticos são transmitidos através de cabos de fibra óptica até o potencial de terra, onde são convertidos em sinais elétricos escalonados e normalizados utilizados por relés de proteção e outros dispositivos eletrônicos inteligentes (IEDs).

O módulo de conversão óptico-eletrônico geralmente está localizado na sala de controle geral da subestação, mas também pode estar localizado próximo ao IED no quadro de manobra. Esta norma especifica as características dos sinais elétricos entre um módulo de conversão óptico-eletrônico e um relé de proteção ou outro IED que utilize estes sinais. A interface entre os sensores ópticos e o módulo de conversão é uma solução técnica proprietária para a construção de um sistema de medição de um fabricante específico, que não está sujeito a padronização. Para a correta interação com equipamentos externos, é necessário normalizar as características da saída do módulo de conversão, da entrada dos terminais de proteção do relé e de uma série de outras funções de medição.

A área marcada na Figura 1 mostra a localização das interfaces definidas por este padrão.

Figura 1 - Sistema óptico de medição de corrente com interface analógica padronizada

2 Referências normativas

Esta norma utiliza referências normativas às seguintes normas. Para referências datadas, aplica-se apenas a edição citada. Para aqueles sem data, a edição mais recente (incluindo todas as alterações e alterações).

IEEE Std 525™, Guia IEEE para Projeto e Instalação de Sistemas de Cabos em Subestações
_______________
As publicações do IEEE podem ser adquiridas no Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, EUA (http://standards.ieee.org/).


IEEE Std 1050™, Guia IEEE para aterramento de equipamentos de instrumentação e controle em estações geradoras

IEEE Std C37.90™, Padrão IEEE para Relés e Sistemas de Relés Associados a Aparelhos de Energia Elétrica (Relés e sistemas de relés usados ​​para proteger e controlar dispositivos de energia)

IEEE Std C37.90.1™, Testes padrão IEEE de capacidade de resistência a surtos (SWC) para relés e sistemas de relés associados a aparelhos de energia elétrica (testes para resistência a surtos de relés e sistemas de relés usados ​​para proteger e controlar aparelhos de energia)

IEEE Std C37.90.2™, padrão IEEE para capacidade de resistência de sistemas de relé à interferência eletromagnética irradiada de transceptores

IEEE Std C57.13™, Requisitos padrão IEEE para transformadores de instrumentos. As publicações do IEEE estão disponíveis no Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, EUA (http://standards.ieee.org/) (Requisitos do transformador de instrumento)

3 Termos e definições

Os seguintes termos e definições são adotados nesta norma. Termos não apresentados nesta norma podem ser encontrados no The Authoritative Dictionary of IEEE Standards, Sétima Edição.

3.1 uma unidade relativa um por unidade (abreviado: 1 p.u.): O valor de saída medido ou saída de um sistema de medição que corresponde ao valor nominal primário rms medido de tensão ou corrente no circuito de medição.

3.2 entrada de relé(entrada de relé): A entrada eletrônica analógica de qualquer terminal de relé, medidor, dispositivo de medição ou controle ou dispositivo eletrônico inteligente que esteja em conformidade com esta norma.

3.3 sistema de medição(sistema de detecção): Sensor eletrônico, dispositivo, interface óptico-eletrônica ou fonte de sinal analógico que gera valores medidos de tensão ou corrente em uma rede elétrica, cuja saída atende a esta norma.

4 Requisitos gerais

4.1 Dispositivos de conexão

A saída do sistema de medição e a entrada do relé devem ser equipadas com conectores padrão comumente disponíveis que possam suportar surtos de alto potencial de acordo com os requisitos de 4.4. Os conectores devem ser projetados para permitir fácil conexão e terminação de cabos. Terminais de parafuso são a solução preferida. Cada entrada ou saída inclui um par de terminais de sinal, rotulados de acordo com 4.3. O fornecedor do equipamento deverá fornecer terminais não aterrados adicionais ou meios para conectar blindagens de acordo com a cláusula 7.

4.2 Isolamento galvânico da terra

Ambos os terminais de saída do sistema de medição e qualquer entrada de relé devem ser isolados do aterramento de proteção ou do aterramento da estrutura quando expostos a sinais de CC ou de frequência de alimentação. A capacitância permitida entre qualquer terminal e o terra não deve exceder 0,01 µF.

4.3 Marcações de polaridade e resistência à inversão de polaridade

As interfaces devem ter marcações de polaridade compostas pelos tradicionais “cts” e “vts”. Consulte IEEE Padrão C57.13.
_______________
As informações do link são fornecidas na seção 2.


Para uma saída desequilibrada de um sistema de medição, o terminal de saída do sinal deve ser marcado com a marca de polaridade apropriada ou como o terminal secundário X1 de um transformador de medição tradicional.

Quando a corrente primária da rede elétrica é convertida em tensão na saída do sistema de medição, então o valor positivo da tensão no terminal com o sinal de polaridade correspondente deve corresponder à direção da corrente no terminal primário com o correspondente polaridade sinal.

Cada sistema de medição e cada relé devem ter uma etiqueta do fabricante informando que ele está disponível apenas em polaridade não reversível ou que pode ser usado em polaridade reversa.

Polaridade reversível refere-se a uma entrada ou saída totalmente isolada ou balanceada que pode ser conectada em qualquer polaridade conforme especificado.

Polaridade não reversível refere-se a uma entrada ou saída de fio único ou não balanceada (onde um condutor é usado para transportar o sinal e o outro condutor serve como condutor de aterramento, como um cabo coaxial), que envolve conectar o condutor de sinal apenas para o terminal de sinal e o condutor comum apenas ao terminal comum.

Normalmente, um único sinal na saída de um sistema de medição é ramificado em vários relés ou dispositivos que utilizam este sinal. Ao fazer esta conexão, deve-se levar em consideração o seguinte:

- se uma ou mais entradas de vários relés tiverem polaridade irreversível, nem sempre o usuário conseguirá obter a conexão de polaridade necessária para todos os dispositivos, mesmo que a fonte tenha polaridade reversa.

Nota - As configurações internas ou de software de um determinado relé de proteção podem alterar a polaridade da entrada;


- se for utilizada polaridade reversível para cada entrada de vários relés, então cada relé pode ser conectado com a polaridade necessária, mesmo que a saída da fonte não seja irreversível.

Isso aumenta a flexibilidade de utilização de relés e outros dispositivos com entradas de polaridade reversa utilizando as saídas analógicas do sistema eletrônico de medição.

Os terminais de saída simétricos ou reversíveis devem ser simétricos em relação ao terra.

4.4 Saídas adicionais de sistemas de medição

4.4.1 Saída de aviso

Este é um sinal adicional destinado a sinalizar qualquer problema no sistema de medição, que deverá notificar qualquer mau funcionamento, falha ou degradação de características, ou seja, notificar sobre a necessidade de manutenção ou reparo. Por exemplo, uma fonte de alimentação defeituosa para o sistema de medição pode resultar em tal sinal.

Esta saída deverá ser um contato tipo “C”, livre de potencial e especificada pelo fabricante do sistema de medição. Em condições normais de operação, o enrolamento do relé (bobina) deve estar sempre energizado para gerar um alarme em caso de perda de energia, bem como em caso de falha no sistema de medição.

4.4.2 Sinal de saída da exatidão dos dados transmitidos

Este é um sinal obrigatório que deve refletir os resultados de todas as verificações internas durante o autodiagnóstico da eletrônica do sistema de medição, cuja presença significa que há um problema com o sinal de saída analógico e isso pode levar ao funcionamento incorreto do relés conectados. Também é utilizado para indicação durante a ligação e/ou desligamento, durante os quais o sinal de saída do sistema de medição apresenta grandes erros. Os relés conectados podem usar erroneamente este sinal para inibir o trip.

Essa saída pode assumir uma ou ambas as seguintes formas:

- contato tipo “A”, livre de potencial e especificado pelo fabricante do sistema de medição. Sob condições normais e corretas de operação, o enrolamento do relé (bobina) deve estar sempre energizado para fornecer um sinal ou fornecer uma trava de segurança para um sinal de saída incorreto. O contato deve ser feito de acordo com IEEE Std C37.90. O atraso de bloqueio da saída em caso de efeito de disparo (ressalto de contato) não deve exceder 12 ms;

- O nível lógico TTL (0 a 5 V) tem uma resposta de 1 ms ou mais rápida (ver 5.8). Neste caso, o nível lógico (5 V) significa a exatidão dos dados transmitidos.

4.5 Teste de compatibilidade eletromagnética

Os seguintes tipos de testes são usados ​​para verificar as saídas do sistema de medição, entradas e saídas de relés eletrônicos analógicos compatíveis que sinalizam uma falha do sistema de medição e a exatidão dos dados transmitidos, bem como para verificar as entradas do relé e dispositivos intermediários descritos em cláusula 6. Este teste é adicional a outros testes sobre a capacidade dos relés e da eletrônica do sistema de medição para suportar as condições do ambiente eletromagnético circundante, cujos requisitos são fornecidos nas normas relevantes.

4.5.1 Testes dielétricos

Esses testes devem ser conduzidos de acordo com os métodos de teste dielétrico descritos na IEEE Std C37.90. A tensão de teste é aplicada somente em modo comum entre cada par de terminais de entrada ou saída e o aterramento de proteção ou aterramento da estrutura. Circuitos de sinal de até 50 V são testados na tensão de teste dielétrica mais baixa de acordo com IEEE Std C37.90.

5.1.1 Descrição do sinal para sistema de medição de corrente

Faixa dinâmica: 0,05 a 40 vezes nominal;

Nível nominal de saída (ou 1 p.u.): 200 mV (rms);

Valor instantâneo máximo: 0,200x40x1,414 = 11,3 V (pico).

Os erros de amplitude e fase são o desvio máximo do valor real do sinal primário escalonado em 50 ou 60 Hz.

Tabela 1 - Descrição do sinal do sistema de medição de corrente

O valor total do fator de distorção não linear deve ser menor ou igual ao erro de amplitude.

A relação sinal-ruído deve ser maior ou igual a 54 dB com sinal maior que 0,1 p.u. A medição deve ser realizada em um sinal de frequência de potência e a largura de banda de medição de ruído deve estar dentro de 120 Hz.

O sistema de medição de corrente pode ser fornecido com uma saída adicional nominal de 2 Vrms a 1 p.u., com valor máximo de saída de 4 p.u. Esta saída destina-se às aplicações onde a precisão de medição necessária é superior à geralmente aceita. Para aplicações de transferência de custódia, o fabricante do sensor deve demonstrar separadamente a conformidade com um padrão de precisão apropriado, como IEEE Std C57.13 ou partes dele.

5.1.2 Descrição do sinal para sistemas de medição de tensão

Faixa dinâmica de 0,05 a 2,0 vezes o valor nominal.

Nível de saída nominal (ou 1 p.u.): 4 V (rms).

Saída máxima: 4,0 x 2,0 x 1,414 = 11,3 V (pico).

Os erros de amplitude e fase são o desvio máximo do valor do sinal primário escalado real em 50 ou 60 Hz.

Tabela 2 - Descrição do sinal do sistema de medição de tensão

O valor total do fator de distorção não linear deve ser menor ou igual ao valor do erro.

A relação sinal-ruído deve ser maior ou igual a 70 dB com sinal maior que 0,85 p.u. As medições devem ser feitas utilizando um sinal de frequência de potência e uma largura de banda de medição de ruído de pelo menos 120 Hz.

Isto se aplica a relés de proteção ou aplicações de medição para as quais a precisão indicada acima é aceitável.

Para aplicações de transferência de custódia, o fabricante do sensor deve demonstrar separadamente a conformidade com os padrões de precisão relevantes, como IEEE Std C57.13 ou partes deles.

5.2 Correção de fase

Para obter maior precisão, o fabricante do sistema de medição pode especificar um valor de correção de fase na frequência de potência, cujo valor é inserido como uma correção para todos os valores para obter maior precisão do que o especificado acima.

NOTA Isto não elimina a necessidade do sistema de medição cumprir os erros angulares mencionados acima.

5.3 Carga nominal

A precisão do sistema de medição deve atender aos requisitos desta norma ao conectar uma carga de cerca de 5 kOhm e uma carga capacitiva de até 5 nF. Uma saída de um sistema de medição pode ser conectada a vários relés ou outros dispositivos de medição em paralelo. O relé ou outro dispositivo conectado deve ter uma impedância de entrada de pelo menos 50 kOhm, mas não superior a 200 kOhm.

5.4 Redução do Modo Comum

A atenuação de modo comum para as entradas e saídas de medição deve ser superior a 86 dB a 50 ou 60 Hz para um sinal de modo comum de até ±50 V. Este valor é especificado para distúrbios de tensão de 20 V na entrada do sistema de medição de corrente. . no qual o valor atual é 0,5 p.u. e quando o ruído do tipo comum é inferior a 10% do nível do sinal medido.

5.5 Desvio do sinal de saída da zona zero

O desvio em estado estacionário do sinal de saída da zona zero (deslocamento do componente DC do sinal de saída) deve ser inferior a 3 mV. Isto se refere aos requisitos para eletrônica DC na saída do amplificador, mas não se aplica ao decaimento exponencial de "offset DC" dos sinais de corrente de falha.

O desvio em estado estacionário do sinal de saída da zona zero do amplificador deve ser inferior a 3 mV. Isto se refere às características eletrônicas com um componente de corrente CC longo na saída do amplificador, mas não está relacionado ao decaimento exponencial do "deslocamento do sinal CC" para sinais de corrente de curto-circuito.

5.6 Largura de banda e resposta transitória

O fornecedor do sistema de medição deve especificar a resposta em frequência. O desvio da frequência de alimentação (frequência de rede) especificado em 5.1 deve estar entre 45 e 65 Hz. A resposta deve ser de pelo menos 0 a -1 dB até 3 kHz e 0 a -3 dB até 5 kHz. A frequência de corte mais baixa (se presente) deve ser definida de forma que o sistema possa atender ao seguinte requisito para uma resposta de desvio de sinal constante.

Para compensar totalmente a resposta de decaimento exponencial da corrente primária ("deslocamento de sinal constante") com um valor de 20 p.u. O erro do fator de escala instantâneo não deve exceder 10% para qualquer constante de tempo até 100 ms.

Para a tensão primária, a resposta transitória é determinada pela resposta a um pulso escalonado, ou seja, alterando o valor da forma do pulso dentro da faixa para zero, enquanto o sinal na saída do sistema de medição deve diminuir para um nível inferior a 10% de seu valor inicial dentro de um tempo de 4 ms e cair abaixo de 10% somente após desta vez.

Alguns clientes podem exigir a operação do sistema para frequências na faixa de 65 a 75 Hz com requisitos de precisão reduzidos. Recomenda-se que o fornecedor do sistema de medição defina os requisitos para as características técnicas de sua operação nesta faixa de frequência.

5.7 Configurando a detecção de sinal de erro

A saída da interface do sistema de medição deve ser zerada quando uma falha interna for detectada para evitar causar problemas sérios ou alarmes falsos. Isto é garantido pela fonte de alimentação de reserva para o sistema de medição ou pelo desligamento durante condições transitórias. O tempo entre a identificação de um problema e sua correção não deve ser superior a 0,2 ms.

Normalmente, a identificação do problema é realizada utilizando o mesmo método de detecção de erros, como é feito durante a verificação de exatidão da transmissão dos dados da saída, descrita em 4.4.2.

5.8 Descrição do sinal para correção dos dados transmitidos

O sinal opcional que transmite informações de validade de dados 4.4.2 deve ser um sinal de nível TTL (0 ou 5 V), isolado do terra de proteção, e destinado a ser transmitido usando o mesmo método de conexão usado para a transmissão de sinais do sistema de medição analógico (ver Seção 7). Uma unidade lógica de 3,0 a 5,5 V informa sobre a presença de dados corretos na saída do sistema de medição. Um zero lógico na faixa de 0 a 0,5 V deve indicar um erro de dados na saída do sistema de medição. A saída deste sinal opcional deve ser capaz de fornecer tensões dentro das especificações especificadas em impedâncias de carga de 200 ohms ou superiores. O atraso entre o evento de disparo e a mudança no estado de saída não deve exceder 1 ms.

Os circuitos de entrada no relé de proteção para receber este sinal devem ser isolados do aterramento de proteção e ter uma resistência de entrada superior a 2 kOhm. Neste caso, apenas sinais com nível acima de 2,5 V devem ser percebidos como uma unidade lógica.

6 dispositivos intermediários

6.1 Finalidade

Dispositivos intermediários podem ser usados ​​para criar a soma ou diferença de saídas individuais de sistemas de medição. Eles também podem ser usados ​​para isolar as entradas de diferentes tipos de relés ou medidores conectados a uma única saída do sistema de medição. Dispositivos intermediários podem ter ganho unitário ou podem incluir escalonamento de entradas individuais para alterar o ganho do sistema de medição.

Dispositivos intermediários também podem ser usados ​​para combinar as saídas de transformadores de instrumentos tradicionais com as saídas de um sistema eletrônico de medição. Os requisitos operacionais definidos nesta seção aplicam-se apenas a dispositivos intermediários com saídas eletrônicas analógicas.

6.2 Requisitos de desempenho para dispositivos intermediários

A precisão, a largura de banda e a relação sinal-ruído dos dispositivos intermediários devem ser muito melhores do que os próprios sistemas de medição. Abaixo estão os requisitos para dispositivos intermediários.

Tabela 3 – Requisitos de desempenho de dispositivos intermediários

Os requisitos de desempenho do amplificador devem ser atendidos em conjunto com os conectores de entrada e saída. Os requisitos de desempenho devem ser determinados com ganho unitário. O fabricante deve especificar as características de desempenho com ganho não unitário.

6.3 Outros requisitos para dispositivos intermediários

Os dispositivos intermediários devem atender a todos os outros requisitos das seções 4 e 5, mas não aos especificados em 6.2. Eles devem atender aos requisitos dentro da faixa de condições de operação, transporte e armazenamento especificadas na IEEE Std C37.90.

7 Instruções de instalação para dispositivos intermediários

As Figuras 2, 3 e 4 mostram exemplos de conexão para fontes e cargas únicas e múltiplas. Eles são apresentados para ilustrar conexões apropriadas para distâncias inferiores a 50 m entre o sistema de medição e a entrada do relé mais distante. Condutores de par trançado blindado são geralmente instalados dentro do centro de controle geral da subestação, onde a diferença entre os potenciais zero dos sistemas conectados quando ocorre um curto-circuito não excede 20 V. Condutores com seção transversal de 24 AWG e maiores são bastante aceitável para esses fins. Se vários pares trançados estiverem incluídos em uma blindagem comum, a influência mútua entre os canais durante a conexão diferencial não deve exceder 70 dB.

Você deve prestar atenção às seguintes características principais, comuns a todos os desenhos:

- a conexão com fio pressupõe que o equipamento passou no teste de rejeição de modo comum, conforme especificado na Seção 4, e a taxa de rejeição de modo comum, conforme especificado na Seção 5, é conhecida;

- nenhum dos condutores de sinal torcidos está aterrado em nenhum ponto;

- apenas uma extremidade da blindagem, geralmente o lado do relé ou a extremidade receptora da conexão, está diretamente aterrada. Para sistemas de medição múltiplos e/ou instalações de relés múltiplos, é definido um único ponto de aterramento da blindagem. Este aterramento fornece apenas blindagem eletrostática, e não blindagem magnética na frequência de potência. Para fornecer apenas um ponto de aterramento para vários relés, as blindagens podem ser encadeadas em série enquanto fornecem um único ponto de aterramento;

- observe que qualquer sistema de medição ou relé com polaridade unidirecional ou irreversível que tenha uma conexão interna à saída comum ou não polarizada da interface de aterramento de segurança pode causar problemas de sinal ou comprometer a segurança do isolamento de outros dispositivos;

Figura 2 – Um sistema de medição e uma entrada de relé

Figura 3 – Um sistema de medição com múltiplas entradas de relé

Figura 4 - Múltiplos sistemas de medição e dispositivo intermediário

- Para fornecer melhor blindagem eletromagnética de alta frequência, capacitores de disco cerâmico adicionais de 10 nF podem ser instalados entre a blindagem e o aterramento em cada ponto de conexão da blindagem não aterrada. Podem ser instalados pelo usuário ou localizados dentro dos equipamentos dos fabricantes. Observe que a instalação de tais capacitores é geralmente aceitável para cabos de controle curtos, mas representa um problema para a blindagem de alta frequência em cabos de controle mais longos.

Para conectar equipamentos de manobra localizados em quadro externo, onde não existam condições favoráveis ​​​​para blindagem eletromagnética de alta frequência de alta qualidade, o cliente deve estudar mais cuidadosamente os esquemas de blindagem, aterramento das blindagens e isolamento dos elementos. Consulte IEEE Padrão 525.

Neste caso, é necessária uma blindagem externa adicional confiável, aterrada em ambas as extremidades, para eliminar a influência das correntes induzidas por campos magnéticos e eletromagnéticos de frequência industrial em blindagens de par trançado em sinais de medição de baixo nível. Neste caso, a fonte do sinal eletrônico precisará ser isolada do potencial de terra.

Apêndice A (para referência). Uso seguro

Apêndice A
(informativo)

Existem diferenças significativas na operação entre os modernos sistemas de medição eletrônicos analógicos e os sistemas de medição passivos tradicionais com transformadores de instrumentos.

Novos e especialmente importantes para sua aplicação são características na região de baixa frequência, processos transitórios ao ligar e desligar o sistema, resposta às condições transitórias da rede elétrica, atrasos de fase, resposta às condições transitórias da rede elétrica, atrasos de fase, saída capacidade de carga, falhas e sinais de emergência, calibração. O contraste entre interfaces analógicas e digitais está em discussão.

A.1 Resposta amplitude-frequência na região de baixa frequência

Os conversores tradicionais de núcleo de ferro respondem a baixas frequências até que o dispositivo esteja saturado com corrente alternada além de um certo limite de volts por hertz. Ou seja, tais conversores reproduzem apenas níveis de sinal muito baixos sem distorção em baixas frequências. A saturação ocorre abruptamente durante o meio ciclo atual, com o sinal de saída desaparecendo completa e repentinamente até que a polaridade seja invertida. Os sistemas de medição eletrônicos analógicos especificados nesta norma, por outro lado, podem ter um roll-off de baixa frequência ou podem perder totalmente o componente DC do sinal. A inclusão de um filtro passa-baixa pode levar a vários transientes imprevisíveis para os quais os relés e outros sistemas de medição de alta velocidade não foram projetados. Os fenômenos específicos incluem: mudança do ponto de referência, resposta imprecisa a características transitórias de decaimento exponencial (aparecimento de uma tensão de polarização constante) e processo oscilatório amortecido de baixa frequência como resposta às características transitórias de entrada.

Os projetistas de relés devem avaliar o efeito dos componentes de baixa frequência nos algoritmos de medição, especialmente aqueles que são projetados especificamente para operação em desvios CC frequentemente encontrados em correntes de falta. A precisão especificada em 5.6 inclui o requisito para operação com polarização CC.

A.3 Resposta ao passo

O modo transitório ou resposta transitória pode variar significativamente dependendo da largura de banda de frequência, embora esteja intimamente relacionado às características de filtragem passa-alta correspondentes na eletrônica do sistema de medição. Curtos-circuitos e comutação resultam em overshoot de saída positivo ou negativo e possivelmente amortecimento de oscilações de alta frequência.

O usuário deve verificar a resposta do relé a estas distorções. Esteja ciente de que surtos positivos ou negativos podem fazer com que os relés de alta velocidade operem incorretamente.

Também é necessário saber que em circuitos diferenciais de banda larga de alta velocidade existem diferenças nas características de transferência de sistemas de medição de diferentes gerações, de diferentes fabricantes, o que também pode levar a valores de saída incorretos e diferentes e levar à redução da confiabilidade ou até mesmo falsos positivos.

Os problemas podem não surgir se a frequência de corte do filtro anti-aliasing (filtro anti-aliasing - para eliminar efeitos de aliasing (durante a amostragem) do relé de proteção do microprocessador conectado for três ou mais vezes menor que a largura de banda do sistema de medição e as distorções de frequência existentes .

Deve-se notar que 5.6 inclui as características transitórias do sistema de medição, determinadas pela resposta a um pulso degrau.

A.4 Atraso de fase

O atraso do valor primário medido na rede elétrica antes que o sistema de medição apresente esse valor aos sistemas de relé conectados pode ser curto em comparação com o intervalo de tempo de medição e, à primeira vista, insignificante. Contudo, isto pode ser um problema sério para qualquer relé ou sistema de medição que compare duas grandezas provenientes de dois tipos diferentes de sistemas de medição. A comparação de corrente diferencial é um bom exemplo de onde os circuitos de alta velocidade são sensíveis à diferença nos atrasos de fase entre dois sistemas de medição. Os relés direcionais e de distância, e os medidores de energia comerciais em particular, podem até ter problemas porque devem corresponder com precisão às relações entre tensões e correntes.

Os sistemas de medição de tensão usam métodos diferentes dos de medição de corrente, sem garantir que os atrasos na medição dos sinais primários de corrente e tensão sejam idênticos.

A seção 5.2 descreve uma opção adicional para seleção da correção de fase fornecida pelo fabricante.

A.5 Capacidade de carga

O modo de saída de tensão do sistema de medição deve ser capaz de fornecer corrente para toda a carga conectada, considerada como um grupo paralelo de entradas. O aumento da carga pode levar à deterioração na precisão da geração do sinal e é determinado pela impedância da fonte, mas os sinais de saída ainda podem ser usados ​​em muitas aplicações. Um paralelo pode ser traçado com a influência das cargas nos transformadores de corrente e tensão tradicionais (TCs e TPs).

A.6 Falhas e alarmes

Os projetistas devem ser capazes de determinar o modo de falha de componentes eletrônicos em particular e avaliar o impacto de eventos como danos, quebras ou rachaduras no cabo de fibra óptica. É impossível evitar todos os problemas, mas existem medidas de segurança adicionais para prevenir alguns deles.

Neste sentido, o projetista pode ajudar fornecendo dados sobre o alto desempenho de sistemas de automonitoramento que podem detectar amortecimento ou supressão do sinal de saída. Observe que o sinal de saída amortecido pode interferir no relé de proteção diferencial, o que pode resultar em falso trip, a menos que um sinal adicional de dados inválidos seja usado para inibir o trip. A perda de tensão no relé remoto causará operação falsa ou provocará perda de lógica de potencial (se for usada), o que limitará bastante as capacidades de proteção.

A capacidade de um sistema de medição autodiagnosticar problemas menores e emitir alarmes não emergenciais, sem supressão ou bloqueio, dá ao pessoal de manutenção a perspectiva de resolver um problema antes que ele cause consequências negativas. Uma porta de comunicação de dados que pode relatar diagnósticos específicos por meio de um modem ou porta WAN aumenta a probabilidade de os técnicos de reparo chegarem com as peças e equipamentos corretos.

A.7 Calibração

O fornecedor é obrigado a treinar o usuário nos métodos pelos quais a calibração inicial do sistema de medição é realizada e posteriormente mantida. Em particular, certifique-se de que o IED fornecido possui as características que podem ser necessárias para realizar o procedimento de calibração.

O fornecedor do sistema de medição deve instruir o cliente sobre o que fazer com a calibração do sistema ao substituir um módulo de conversão eletrônica com defeito.

A.8 Interfaces digitais

Este padrão cobre apenas interfaces analógicas de baixo nível, incluindo aquelas incorporadas em grandes sistemas que possuem interfaces de dados digitais e onde a interoperabilidade das interfaces analógicas é importante tanto para fabricantes quanto para usuários.

As interfaces digitais requerem especificação de processos de amostragem, desempenho e camadas de protocolo de comunicação multicamadas para comunicação entre o sistema de medição e o relé. Interfaces de dados digitais para fornecer informações de rede elétrica são fornecidas em IEC 61850-9-1, IEC 61850-9-2, IEC 60044-7 e IEC 60044-8.

Apêndice SIM (obrigatório). Informações sobre a conformidade das normas internacionais de referência com as normas nacionais

Aplicação SIM
(obrigatório)

Tabela DA.1

Bibliografia

IEEE P1331 Draft 8.3, abril de 1999: Padrão de uso de teste para entradas de sinal analógico de baixa energia para relés de proteção

Texto de documento eletrônico
preparado por Kodeks JSC e verificado em relação a:
publicação oficial
M.: Standartinform, 2019

Aula 3

Ciclo de vida do software

Conceitos básicos envolvidos na definição do ciclo de vida

Processo de desenvolvimento

Processo de desenvolvimento

10. Análise dos requisitos do sistema

11. Análise de requisitos de software

12. Projeto de arquitetura de software

13. Projeto detalhado de software (plano de trabalho de desenvolvimento de software)

14. A codificação e o teste de software envolvem a resolução das seguintes tarefas:

15. Integração de sistemas

16. Teste de qualificação de software

17. Instalação e aceitação de software

18. Operação de software

19. Manutenção de software (de acordo com a norma IEEE – 90)

20. Processos de apoio ao ciclo de vida do software

21. Processo de documentação

22. Gerenciamento de configuração

23. Processo de Garantia de Qualidade

24. Verificação

25. Certificação

26. Processos organizacionais do ciclo de vida do software

27. Grupos de padrões ESPD

28. Lista de documentos ESPD

29. Vantagens da utilização das normas ESPD

30. Desvantagens dos padrões ESPD

31. Padrão GOST 34.601-90: etapas e etapas de criação de um sistema automatizado

32.