Esta página está em construção.

Introdução

Este documento é o balizador do controle de qualidade de artefatos produzidos no 3PUP. Ele contém critérios de qualidade a serem seguidos para construção de interfaces de usuário, código-fonte e processo de testes do sistema a ser entregue.

Interface de Usuário

Esta seção cobre critérios de qualidade esperados para as interfaces de usuário do sistema. Como interface de usuário podem ser consideradas telas da aplicação, dispositivos de acionamento óptico, som, movimento ou qualquer outra interface de entrada ou saída de informação do sistema.

Telas do Sistema

O objetivo do controle de qualidade para as telas do sistema é manter uma aparência, comportamento e usabilidade consistentes ao longo de toda a aplicacao.

Os critérios para checagem de qualidade das telas do sistema são (1):

CHECKLIST 1: Checklist para verificação de telas de sistema

Código-Fonte

Esta seção apresenta os critérios de qualidade para o código-fonte e regras de compilação (ex. geração de warnings em código-fonte) do sistema.

Regras de Codificação

A Integrated Development Environment (IDE) para o ambiente é o EclipseIDE, na sua distribuição Juno. Opcionalmente, o JBoss Developer Studio e o SpringSource, ambas variantes do EclipseIDE são suportadas.

O objetivo do controle de qualidade para as regras de codificação no ambiente de desenvolvimento é fazer com que todos os envolvidos no desenvolvimento do sistema produzam código-fonte no mesmo formato e estrutura de escrita, de forma que exista uma isonomia do código-fonte ao longo de todo o processo de desenvolvimento e manutenção, a qual seja independente de preferências pessoais, vícios de programação, habilidades e experiência do desenvolvedor entre outros fatores comportamentais sucetíveis à gostos pessoais.

Independente da variante da IDE, as regras de configuração do ambiente de desenvolvimento devem seguir as premissas abaixo:

Compilação

As regras de configuração do compilador da IDE devem possuir as seguintes entradas:

Para ser consistente com o padrão de qualidade do projeto, as regras compilação da IDE do desenvolvedor devem seguir as configurações acima.

Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor devem ser idênticas às acima.

Limpeza de Código-Fonte (Clean Up)

A limpeza de código-fonte diz respeito aos padrões para eliminação de conteúdo desnecessário ou incorreto dentro do código-fonte do sistema, tais como espaços em branco, falta de modificadores final em variáveis, ausência ou uso incorreto de de anotações @Overide, @SupressWarings e outras, conversões desnecessárias, importações de dependências desnecessárias ou em nível de profundindade (*) desapropriados, linhas em branco, tabulações e identações incorretas, entre outros.

As regras de configuração para limpeza de código-fonte da IDE são assim definidas:

Para aplicar as regras de limpeza de código-fonte, deve ser realizada a importação do arquivo de configuração no ambiente de desenvolvimento, via menu Window > Preferences > Java > Code Style > Clean Up, opção Import. E, certifique-se que a opção Show profile selecction dialog for the 'Source > Clean Up' action na tela relacionada, conforme abaixo:

Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras limpeza de código-fonte da IDE do desenvolvedor devem seguir as configurações acima.

Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor devem ser idênticas às acima.

Modelos de Código-Fonte (Code Templates)

Modelos de código-fonte dizem respeito à padrões para estruturas como blocos de código-fonte, conteúdos padrões para métodos get e set, para construtores, para tratamento padrão de erros, entre outros. Também define padrões para escrita de comentários em código-fonte, como cabecalhos de arquivo, Javadoc para classes, variáveis, métodos, sobreescrita de métodos, delegação de chamadas, entre outros.

As regras de codificação para modelos de código-fonte, incluindo os comentários, são definidas no arquivo abaixo:

Para aplicar as regras de modelos de código-fonte, deve ser realizada a importação do arquivo de configuração no ambiente de desenvolvimento, no menu Window > Preferences > Java > Code Style > Code Templates, opção Import. E, certifique-se que a opção Automatically add comments for new methods and types na tela relacionada, conforme abaixo:

Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras modelos de código-fonte da IDE do desenvolvedor devem seguir as configurações acima.

Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor, bem como as estruturas finais geradas a partir destes modelos (ex. o conteúdo de um metoto getter) devem continuar consistentes com este padrão.

Formatação de Código-Fonte (Formatter)

As regras de formatação de código-fonte dizem respeito à padronização da estrutura de apresentação dos fontes do sistema. Enquanto as regras de limpeza de código discutidas anteriormente buscam ajustar o código-fonte em relação a um padrão, as regras de formatação definem este padrão. Regras como tamanho da linha de codigo-fonte, uso de espaços x tabulação, alinhamento de campos de classes, locais dos sinais de chaves de abertura de fechamento de blocos de código-fonte, uso de linhas em branco para espaçamento, identação, regras para declaração de comentários, entre várias outras.

As regras para formatação de código-fonte, incluindo os comentários, são definidas no arquivo abaixo:

Para aplicar as regras de formatação de código-fonte, deve ser realizada a importação do arquivo de configuração no ambiente de desenvolvimento, no menu Window > Preferences > Java > Code Style > Formatter, opção Import, conforme abaixo:

Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras formatação de código-fonte da IDE do desenvolvedor devem seguir as configurações acima.

Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor, bem como as estruturas finais geradas a partir desse formato (ex. identação) devem continuar consistentes com este padrão.

Organização de Dependências (Organize Imports)

A importação de dependências de pacotes e classes em Java é recurso imprescindível para o desenvolvimento de aplicações. Entretanto, a utilização incorreta de importações deriva para problemas de dependências no sistema, tais como uso de arquivos JAR desnecessários, verbosidade excessiva em código-fonte e alta acoplabilidade (pacotes que dependem indevidamente de outros pacotes) no sistema.

Com o intuito de evitar ao máximo tais problemas no projeto, as regras para organização de dependências (imports) de código-fonte, são definidas no arquivo abaixo:

Para ser consistente com o padrão de qualidade código-fonte do projeto, as regras organização de dependências da IDE do desenvolvedor devem seguir as configurações acima.

Para efeitos de teste de aceite, com o projeto aberto na IDE, as configurações em uso na IDE do desenvolvedor devem ser idênticas às acima.

Análise de Código-Fonte

Além das regras de codificação utlizadas na IDE, duas ferramentas extras são utilizadas para o processo de montagem (build) da aplicação. São elas o PMD e o Checkstyle.

PMD

O PMD é um analisador de código-fonte. Ele localiza falhas de programação como variávies não utilizadas, blocos de tratamento de erros vazios, criação desnecessária de objetos e uma gama de outros elementos. Ele tem suporte para linguagem Java e Javascript e formatos XML e XSL. Adicionalmente, inclui suporte para deteção de "copy-and-paste" (CPD) de código-fonte, uma prática que pode ser nociva também. O CPD está disponível para Java, C, C++, C#, PHP, Ruby, Fortran, JavaScript. O PMD é altamente configurável e pode ser integrado de diversas forms nos processos de desenvolvimento.

As regras de configuração da ferramenta PMD definidas para este projeto estão no arquivo de configuração da ferramenta, que pode ser acessado abaixo:

Estas regras precisam ser aplicadas nos três ramos integração contínua do projeto, Desenvolvimento, Homologação e Produção, via ferramenta de automação de build, e serem publicadas como artefato de construção.

Para ser considerado aprovado o código-fonte em relação ao PMD, nenhum erro deve ser reportado no relatório de análise.

Checkstyle

O Checkstyle é uma ferramenta de desenvolvimento que ajuda os programadores Java a produzirem código-fonte aderente a um determinado padrão de escrita. Regras como identação, tabulação, tamanho de linhas, sintaxe de variáveis e métodos e uma série de outros elementos podem ser definidas. Ele é altamente configurável e pode suportar diferentes padrões, como o Sun Code Conventions.

As regras de configuração da ferramenta Checkstyle definidas para este projeto estão no arquivo de configuração da ferramenta, que pode ser acessado abaixo:

Estas regras precisam ser aplicadas nos três ramos integração contínua do projeto, Desenvolvimento, Homologação e Produção, via ferramenta de automação de build, e serem publicadas como artefato de construção.

Para ser considerado aprovado o código-fonte em relação ao Chesktyle, nenhum erro deve ser reportado no relatório de análise.

Revisão de Código-Fonte

A revisão de código-fonte é parte da etapa de construção, ocorrendo imediateamnte após a programação e imediatamente antes do disparo dos testes.

O objetivo da revisão de código-fonte é fazer uma análise do que foi codificado para garantir que nada tenha passado despercebido antes de iniciar as baterias de teste, os quais seriam perdidos ou gerariam altos índices de falha caso tal processo não tenha sido realizado.

A revisão de código-fonte é uma atividade que deve ser desenvolvida obrigatoriamente por outra pessoa que não o codificador do programa. Pode ser outro desenvolvedor (conceito de programação em par) o mesmo o projetista ou arquiteto, dependendo da complexidade e outros fatores do artefato associado.

As verficações que devem ser efetuadas no processo de revisão de código-fonte são assim sumarizadas:

CHECKLIST 2: Checklist para Teste de Revisão de Código-Fonte.

Número	Artefato	Elemento	Item	Teste	Meio	Status
1	Arquivo de Classe	Método público	Javadoc do método	O método possui Javadoc associado ?	Aferição visual ou Checkstyle
2	Arquivo de Classe	Método público	Javadoc dos parâmetros	Se existentes, os parâmetros do método estão documentados no Javadoc ?	Aferição visual ou Checkstyle
3	Arquivo de Classe	Método público	Javadoc do retorno	Se existente, o retorno do método está documentado no Javadoc ?	Aferição visual ou Checkstyle
4	Arquivo de Classe	Método qualquer	Sintaxe do nome	O nome do método está em conformidade com o padrão 3PUP ?	Aferição visual
5	Arquivo de Classe	Método qualquer	Sintaxe dos parâmetros	Os nomes dos parâmetros estão em conformidade com o padrão 3PUP ?	Aferição visual
6	Arquivo de Classe	Método qualquer	Semântica do método	A semântica de execução do método está consistente com o seu nome e, se existente, com o Javadoc associado (ou seja ele faz o que diz fazer) ?	Aferição visual
7	Arquivo de Classe	Método qualquer	Semântica do parâmetros	As funcionalidades dos parâmetros estão consistentes com o seu nome e, se existentel, o Javadoc associado (ou seja eles fazem o que dizem fazer) ?	Aferição visual
8	Arquivo de Classe	Método qualquer	Semântica do retorno	Se aplivável, o método retorna as informações corretas, conforme o projeto técnico e, se existente, o Javadoc associado (ou seja, ele retorna o que diz retornar) ?	Aferição visual
9	Arquivo de Classe	Método qualquer	Validação de parâmetros	Se existente, o método realiza ou delega o tratamento de validação e de erros em caso de parâmetros inconsistentes ou nulos ?	Aferição visual
10	Arquivo de Classe	Método qualquer	Objetividade	O método realiza apenas as operações estritamente necessárias para sua funcionalidade de negócio, conforme projeto técnico ?	Aferição visual
11	Arquivo de Classe	Método qualquer	Desempenho	O método não possui nenhum statement que afete negativamente o desempenho do sistema ?	Aferição visual
12	Arquivo de Classe	Método qualquer	Segurança	O método não possui nenhum statement que implique em falhas ou violação da segurança do sistema ?	Aferição visual
13	Arquivo de Classe	Variável pública	Javadoc da variável	A variável possui Javadoc associado ?	Aferição visual ou Checkstyle
14	Arquivo de Classe	Variável qualquer	Sintaxe do nome	O nome da variável está em conformidade com o padrão 3PUP ?	Aferição visual
15	Arquivo de Classe	Variável qualquer	Semântica do nome	A semântica da variável está consistente com o seu nome e, se existente, com o Javadoc associado (ou seja ela faz o que diz fazer) ?	Aferição visual
16	Arquivo de Classe	Classe pública	Javadoc da classe	A classe possui Javadoc associado ?	Aferição visual ou Checkstyle
17	Arquivo de Classe	Classe qualquer	Sintaxe do nome	O nome da classe está em conformidade com o padrão 3PUP ?	Aferição visual
18	Arquivo de Classe	Classe qualquer	Conteúdo da classe	Os métodos e/ou outras classes contidas na classe  estão aderentes ao seu nome e, se existente, ao Javadoc associado (ou seja ela contém aquilo e somente aquilo que deveria conter) ?	Aferição visual
19	Arquivo de Pacote	Pacote	Javadoc do pacote	O pacote possui Javadoc via arquivo package-info.java associado ?	Aferição visual ou Checkstyle
20	Arquivo Pacote	Pacote	Sintaxe do nome	O nome do pacote está em conformidade com o padrão 3PUP (ex.: x.p.t.o.umPacoteQualquerComNomeExtenso.utils.x.y.z ) ?	Aferição visual
21	Pacote	Pacote	Conteúdo do pacote	As classes e enumerações contidas no pacote estão aderentes ao o seu nome e ao Javadoc associado (ou seja ele contém aquilo e somente aquilo que deveria conter) ?	Aferição visual
22	Arquivo com pacotes	Módulo	Sintaxe do nome	O nome do módulo (arquivo JAR, WAR ou outro) está em conformidade com o padrão 3PUP ?	Aferição visual
23	Arquivo com pacotes	Módulo	Conteúdo do módulo	O pacotes contidos no módulo estão aderentes ao seu nome e ao projeto técnico associado (ou seja ele contém aquilo e somente aquilo que deveria conter) ?	Aferição visual
24	Arquivo com módulos	Sistema	Sintaxe do nome	O nome do sistema (arquivo JAR, WAR, EAR ou outro) está em conformidade com o padrão 3PUP (não considerando o sufixo de numeração) ?	Aferição visual
25	Arquivo com módulos	Sistema	Conteúdo do sistema	Os módulos contidos no sistema estão aderentes ao seu nome e ao projeto técnico associado (ou seja, ele contém aquilo e somente aquilo que deveria conter) ?	Aferição visual

TODO: Pablo montar expressão regular no formato: obrigatório verbo seguido de opcional substantivo seguido de opcional adjetivo e substantivo, etc...

Testes

Testes para validar os critérios de aderência do sistema em relação aos seus requisitos são partes essenciais de um processo de controle de qualidade para desenvolvimento de sistemas.

Neste cenário, o Modelo V é uma referência de mercado, e é utilizado em conjuto com o Processo 3PUP da fábrica de software Redhat de Porto Alegre no seguinte formato:

Testes de Unidade

Os testes de unidade, também conhecidos testes unitários representam o menor elemento testável do sistema. Eles objetivam identificar erros em relação à codificação de classes, métodos e outros recursos mínimos da aplicação.

Os testes de unidade e seus valores de aceitação (ex. esqueletos de classes, métodos e valores) são definidos pelo projetista do módulo do sistema e são codificados pelo desenvolvedor atribuído à feature. E, para execução do teste unitário, necessariamente outro desenvolvedor, que não o codificador da classe/método/recurso deve ser o responsável, a fim de evitar vícios de trabalho.

Os seguintes elementos devem ser verificados em um teste de unidade:

CHECKLIST 4: Checlist para aprovação da construção:

Testes de Integração

A fazer.

Testes de Sistema (Funcionais)

A fazer.

Testes de Aceitação (realiado pelo Usuário)

A fazer.

Mais Informações

Nada consta.

Referências

Nada consta.

Anexos