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.
jair@celepar.gov.br
mucke@celepar.gov.br
prosa@celepar.gov.br
bonfim@celepar.gov.br
