Este trabalho compila as diversas sugestões levantadas pelo grupo no que tange à confiabilidade de software. Representa o esforço de apreender alguns critérios que confiram ou intensifiquem a contabilidade dos produtos gerados pela CELEPAR. Baseia-se em um roteiro mínimo que permita contemplar ou almejar a confiabilidade do software produzido.

A fim de que este roteiro possa mapear algumas sugestões mínimas na busca de produtos mais confiáveis, tornou-se necessário delimitar as fronteiras de atuação da confiabilidade dentro das atividades de Projeto e manutenção de sistemas.

As seguintes premissas foram estabelecidas:

1 ) A confiabilidade deve agir apenas sobre o que está previamente definido. Solicitações implícitas (não escritas) que subjazem à especificação devem ser tratadas pela funcionalidade.

2) Se definirmos a representação esquemática de um sistema dentro dos itens que se seguem:

a) especificação de requisitos;

b) desenho da solução (projeto físico/lógico);

c) codificação;

d) testes;

e) implantação e operação;

f ) manutenção (que retorna ao item (a)).

O contexto do trabalho de confiabilidade limita-se aos itens (b), (c) e (d) deste esquema (que serão tratados individualmente no desenvolvimento do trabalho). Atividades que extrapolem estes limites devem ser tratadas pela funcionalidade.

2 CONCEITUAÇÃO

2.1 Qualidade de software

É a totalidade das características de um produto de software que lhe conferem capacidade de satisfazer necessidades explícitas e implícitas.

2.2 Características da qualidade de software

2.2.1 Confiabilidade

Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo determinado.

2.3 Subcaracterísticas de software (relativas à confiabilidade)

2.3.1 Maturidade

Atributos do software que evidenciam freqüência de falhas por defeitos no software.

2.3.2 Tolerância a falhas

Atributos do software que evidenciam sua capacidade de manter um nível de desempenho especificado nos casos de falhas no software ou de violação nas interfaces especificadas.

2.3.3 Recuperabilidade

Atributos do software que evidenciam sua capacidade de restabelecer seu nível de desempenho e recuperar os dados diretamente afetados em caso de falha. bem como o tempo e esforço dispendidos no processo.

(*) Segundo a NBR ISO/IEC (tradução de julho/ 94)

3 CRITÉRIOS DE CONFIABILIDADE APLICADOS AO DESENHO DA SOLUÇÃO (PROJETO FíSICO 1 LóGICO)

3.1 Premissa básica

O processo de confiabilidade deve iniciar-se através da avaliação do projeto lógico e físico do sistema.

A confiabilidade, nesta fase, pressupõe que a minimização de falhas está atrelada ao uso das ferramentas disponíveis na CELEPAR, que devem ser utilizadas em sua totalidade. Entre elas, a popularização do uso da MDS-CELEPAR, aplicada independentemente do nível, tamanho e complexidade do sistema em questão, e o mecanismo mais viável para se atingir elevado grau de confiabilidade

3.2 Propostas de efetivação

a) Adoção de um roteiro mínimo de passos da MDS nos sistemas de pequena complexidade (conforme sugerido no item 3.3). A não-observância deste roteiro implica que o sistema está fora dos parâmetros de qualidade aceitáveis pela CELEPAR.

b) Existência de mecanismos de verificação da correta utilização da MDS, através de um grupo designado para esta função, que cotejará o trabalho do projetista em métricas previamente estabelecidas, podendo aprová-lo ou rejeitá-lo. O4 aval do grupo ao projeto é pré-requisito indispensável para que se inicie a fase de construção do sistema. Desta forma, no desenvolvimento do projeto físico, o projetista, partindo do roteiro mínimo, obtém a certificação da confiabilidade de seu trabalho.

c) O projetista deve ter, à sua disposição, ferramentas de auxilio cuja utilização sirva de compasso no desenvolvimento de seu trabalho. Análise por pontos de função, Superproject (ou similar, para desenvolvimento de cronogramas), PC-Case (para desenvolvimento de DFDs) são algumas sugestões que podem ser disponibilizadas. A criação de um grupo de suporte para a correta utilização destas ferramentas também é uma sugestão que pode ser implementada.

d) Maximização da utilização de bibliotecas de funções, que permitirão alta confiabilidade no desempenho da aplicação.

e) Utilização efetiva da área de Administração de Dados, tanto na participação dos pontos de revisão como na estipulação de padrões para modelagem de dados. A área também deve se envolver com o suporte ao processo.

f) O comprometimento com prazos e recursos (tanto humanos quanto tecnológicos) deve ser endossado pelo gerente envolvido no processo.

3.3 Sugestão de roteiro mínimo da MDS

3.3.1 Pré-requisito

As fases de:

• planejamento global;

• investigação da situação problema:

• modelagem da essência da solução;

deverão estar desenvolvidas e consolidadas, permitindo ao projetista desenvolver em segurança os passos da fase seguinte.

3.3.2 Do projeto físico à implantação

3.3.2.1 Planejamento da fase

• Cronograma das atividades até a implantação.

• Relatório da aplicação de pontos de função, utilizando-o como base para desenvolvimento de cronogramas.
  
• Definição dos recursos (hardware, software, humanos), local e prazo da efetiva utilização dos mesmos.

3.3.2.2 Definição de hardware e software

• Determinação da plataforma que vai suportar o sistema em desenvolvimento.

• Na inexistência da plataforma, alertar gerência e clientes quanto aos prazos necessários para instalação.
  
• Considerar, no planejamento, o prazo e recursos necessários para sua disponibilização.

3.3.2.3 Desenho físico dos processos

• Geração de DFD detalhada.

• Fluxo das funções e/ou descrição detalhada das mesmas.

• Determinação das bibliotecas e funções já disponíveis a utilizar.

3.3.2.4 Desenho físico da base de dados

• Desenvolvimento de modelo de entidade-relacionamento no plano físico, demonstrando, claramente, o relacionamento entre as entidades e os atributos referentes a cada uma delas.
  
• Descrição do conteúdo de cada atributo e, quando possível, a identificação dos limites de faixas aceitáveis pelos mesmos (disponibilizados em dicionário de dados do sistema).

3.3.2.5 Projeto de interface homem-máquina

• Desenho das telas e definição dos defaults disponíveis ao usuário. Ex: Tecla de help, Linha de mensagens, Area de dados do usuário, Modelo do menu de opções, etc.

3.3.2.6 Planejamento da construção do sistema

• Definição básica de cada módulo/função/ programa do sisterna

3.3.2.7 Avaliação dos produtos da fase

• Aprovação pelo grupo ou mecanismo designado quanto à correta utilização da MDS.

3.3.2.8 Aprovação do cliente

• Apresentação ao cliente do trabalho desenvolvido até o momento.
  
• Obtenção da aprovação dos trabalhos pelo cliente.

Nota. esta aprovação poderá ser realizada por partes. Durante a obtenção da aprovação final do produto como um todo, a fase de construção do sistema dos segmentos já aprovados poderá estar em andamento.

3.4 Sugestões para viabilização da confiabilidade em aplicações

a) Desenvolvimento e utilização de bibliotecas de funções (unificadas por linguagem), bem como ampla divulgação das rotinas existentes e o modo de utilização das mesmas.

b) Treinamento contínuo no uso do MDS-CELEPAR,

c) Criação de grupo específico para dar suporte no desenvolvimento de sistemas, cujas funções abrangeriam:

• verificar a correta utilização da MDS;
  
• treinar os técnicos quanto ao uso da MDS (conforme exposto em (b));
  
• aprimorar a MDS;
  
• sistematizar bibliotecas de funções para diversas plataformas;
  
• desenvolver rotinas de uso comum, tais como o SNG e o GSM;
  
• incentivar o uso de técnicas e softwares de apoio (pontos de função, PC-Case, por exemplo);
  
• participar efetivamente dos grupos de revisão;
  
• agir em outras atividades voltadas à melhoria no desenvolvimento da qualidade de software.

4. CRITÉRIOS DE CONFIABILIDADE APLICADOS À CODIFICAÇÃO

4.1 Articulação teórica

4.1.1 Codificação estruturada

É um método de construir um programa de acordo com um conjunto de regras que requerem um formato com estilo preciso, uma estrutura de controle padronizada e um conjunto limitado de estruturas lógicas (Martin & NlacCIure).

4.2 Pressupostos teóricos

4.2.1 Primeiro pressuposto

Não existe, a rigor, métodos de codificação estruturada que atinjam integralmente seus objetivos. Não existe uma forma correta de aplicar os métodos. Não existe garantia de um resultado correto. As metodologias estruturadas são, na melhor das hipóteses, esboços grosseiros de metodologias precisas.

4.2.2 Segundo pressuposto

A aplicação correta das metodologias de codificação só é confirmada, efetivamente, durante os testes. A fase de teste é o único aval inquestionável para garantir a confiabilidade do produto codificado. Não há regras ou diretrizes que possam assegurar a confiabilidade de um produto, baseado unicamente em metodologias de codificação e/ou estruturação.

4.2.3 Terceiro pressuposto

Embora a codificação seja um processo heurístico, que necessita dos testes para se legitimar, certos mecanismos podem ser aplicados visando uma melhor compreensibilidade do produto codificado e uma integração mais natural ao sistema. Estes mecanismos, que isoladamente não conferem confiabilidade, permitem, no entanto, que se passe de uma forma menos traumática pelos inevitáveis testes aos quais o produto deverá ser submetido.

4.3 Mecanismos que contribuem para a confiabilidade

4.3.1 Padronização

Conjunto de regras que devem ser observadas durante a construção do programa, visando uma homogeneização dos diversos componentes que integram o sistema. A padronização confere estrutura e disciplina à forma, permitindo que a codificação de diversos programas se assemelhe. A padronização deve levar em conta as idiossincrasias da linguagem utilizada, sendo necessária a elaboração de regras diferenciadas para as diferentes linguagens tratadas.

4.3.2 Reutilização do código

Rotinas de uso repetitivo no sistema devem estar pré-codificadas em módulos específicos, que podem ser chamados constantemente para dentro do programa. Definições de layouts dos arquivos com maiores índices de referência no sistema, bem como definições dos cabeçalhos tomados como padrão para os relatórios e o conjunto de comandos para sua impressão, devem. também, ser disponibilizados em módulos de acesso geral. A utilização destes módulos, além de confiável em função de serem exaustivamente testados, permite que qualquer alteração neles seja imediatamente assimilada pelos programas que os compartilham, evitando divergências lógicas entre programas.

4.3.3 Modularização

É a organização de um programa em unidades independentes, cujo comportamento é controlado por um conjunto de regras. Suas metas são:

a) decompor um programa em partes independentes;

b) dividir um problema complexo em problemas menores e mais simples;

c) verificar a correção de um modulo de programa, independentemente de sua utilização como uma unidade em um sistema maior. Permite fácil detecção de erros, por isolá-los, e impede que o erro repercuta no programa como um todo.

A modularização de um programa deve ser construída tendo em vista a redução dos acoplamentos (interdependências) entre módulos e o aumento da coesão de seus elementos internos (quão fortemente os elementos dentro de um modulo relacionam-se).

4.4 Sugestões de incremento da confiabilidade na codificação

a) descrição do domínio dos conteúdos dos campos que permitam ter suas entradas pré-definidas;

b) comentários na abertura dos módulos do programa, descrevendo entradas permitidas e saídas esperadas;

c) sempre que possível, utilização de rotinas de tratamento de erros.

4.5 Aderido: Confiabilidade na migração de programas natural de teste para produção

Visando buscar maior confiabilidade na transferência de programas natural de teste para produção, via programa TRANS, foram encaminhadas sugestões para a GPT, através do Carga Rápida, contemplando os seguintes aspectos:

• verificar possíveis divergências entre as datas e horas do programa objeto e do programa fonte (data/hora objeto menor que data/hora fonte),
  
• não permitir que programas novos sejam transferidos no modo REPORT,
  
• verificar se existe limitação de registros nos comandos READ/FIND;
  
• verificar a existência de views de teste (-I) na versão final do programa;
  
• verificar se os comandos de atualização estão inibidos;
  
• em programas que montar JCL's, verificar se não há incompatibilidade entre os parâmetros ADA e LOGON.

Estas verificações serão feitas pelo programa TRANS, no momento de transferir programas de teste para produção. As verificações serão implementadas gradativamente e serão disponibilizadas à medida que forem sendo efetivadas pela GPT.

5. CRITÉRIOS DE CONFIABILIDADE
APLICADOS AOS TESTES

5.1 Articulação teórica

O processo de teste consiste em:

• selecionar um conjunto de dados de entrada com os quais se executará o programa;
  
• determinar a saída que se espera ser produzida:
  
• executar o programa;
  
• analisar os resultados produzidos pela execução do programa.

Um programa é exaustivamente testado se ele é executado com todos os possíveis conjuntos de dados de entrada.

O teste pode ser orientado da seguinte forma:

1 ) testar todos os comandos e todos os caminhos pelo menos uma vez;

2) testar minuciosamente as partes do programa mais importantes e mais intensamente usadas;

3) testar os módulos individualmente antes de serem combinados. Depois, testar as intersecções dos módulos;

4) organizar o teste de modo que ele progrida dos exemplos de teste mais simples aos mais complexos. Isto significa que os testes que envolvem lógica menos complexa (poucos laços e testes de condição) devem ser executados primeiro. Significa, também, que o processamento normal com entradas válidas deve ser testado antes do processamento excepcional ser checado;

5) calcular os resultados esperados do teste antes de ele ser executado.

5.2 Fases do teste

O teste tem sido formalizado como um procedimento de quatro fases:

1. Teste de unidade

2. Teste de integração

3. Teste de sistema

4. Teste de aceitação.

5.2.1 Teste de unidade

É o teste realizado a nível de modulo. Os módulos vão sendo codificados, integrados na estrutura de controle do programa e testados.

5.2.2 Teste de integração

É executado a nível de subsistema, em que um subsistema é uma hierarquia de módulos.

5.2.3 Teste de sistema

É uma atividade de validação usada para demonstrar que o software inteiro está correto. E um teste basicamente funcional.

5.2.4 Teste de aceitação

O programa ou sistema é tratado como uma caixa preta. Não é suposto nenhum conhecimento de sua estrutura interna e o teste é completamente fundamentado nos requisitos do usuário.

5.3 Diretrizes para testes confiáveis

• Os requisitos e as especificações funcionais do programa devem ser usados para construir os exemplos de teste.
  
• Os exemplos de teste devem ser preparados com os resultados esperados do teste, determinados antes de os testes serem executados.
  
• Os testes devem evoluir do mais simples para os mais complexos, usando primeiro dados de entrada construídos e depois dados efetivos.
  
• O teste do sistema deve ser executado em três etapas:

  1) testar casos normais:
  
  2) testar casos extremos;
  
  3) testar exceções.

• Quando possível. utilizar processamento em paralelo com o sistema corrente e comparar os resultados.

5.4 Dados de testes

5.4.1 Construção de dados de teste

• selecionar os dados de entrada para o teste;
  
• determinar a saída esperada.

5.4.2 Tipos de dados de testes

• dados construídos: dados construídos manualmente em um modo seletivo, campo por campo;

• dados reais modificados: dados reais que são modificados, manual ou automaticamente, para produzir certos resultados e executar certas partes do programa;

• dados reais: usados em teste de volume e processamentos paralelos.

O teste pode ser planejado, executando-o primeiro com dados corretos e, em seguida, com dados errados, forçando o programa a condições anormais e absurdas, que raramente ocorrem e que não foram previstos pelo sistema. Posteriormente, pode-se, ainda, utilizar dados mistos, que propiciam uma condição diferente das anteriores.

5.5 Exemplos de dados para testes:

5.5.1 Dados corretos

Geral

• arquivos com apenas um registro;
  
• arquivos sem registros;
  
• limites máximos e mínimos de conjunto de
  registros,
  
• registros de arquivos variáveis, com tamanho
  máximo, mínimo e intermediário.

Merge de arquivos

• identificações com condições de igualdade e
  desigualdade;
  
• um arquivo termina primeiro e vice-versa;
  
• todas as identificações de um arquivo iguais às
  do outro, bem como todas desiguais.

Consistência e compatibilidade

• todos os campos corretos;
  
• consistências cruzadas corretas:
  
• todos os fechamentos corretos.

Cálculo

• verificação do conteúdo e formato dos campos,
  bem como valores:
  
• máximos e mínimos;

Relatórios

• quantidade de registros que não preencham uma
  página:
  
• quantidade de registros que preencham mais de
  uma página;
  
• quantidade de registros que terminem
  exatamente no limite da página.

Tabelas

• registros que testem os limites dos indexadores
  do programa:
  
• registros que testem as tabelas internas do
  programa.

5.5.2 Dados errados

Geral

• ausência e duplicidade de headers, capa de lote,
  registro de fechamento;
  
• arquivos com apenas um registro;
  
• arquivos sem registros;
  
• erros de parâmetros informados.

Merge de arquivos

• condições de erros de combinação de
  identificações entre vários arquivos;
  
• identificação fora de seqüência.

Consistência e compatibilidade

• campos constituídos com os mais variados tipos
  de erro;
  
• consistências cruzadas incorretas;
  
• fechamentos incorretos.