-
Notifications
You must be signed in to change notification settings - Fork 0
5 Gestão de Qualidade
Citando a própria MPS, "O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos".
Dados o que a Gerência de Requisitos se propõe, existem resultados que se espere que se atinja. Dado o que se espera, nosso projeto utilizou dos seguintes GQA:
-
GQA 3 - Os problemas e as não-conformidades são identificados, registrados e comunicados;
-
GQA 4 - Ações corretivas para as não-conformidades são estabelecidas e acompanhadas até as suas efetivas conclusões. Quando necessário, o escalamento das ações corretivas para níveis superiores é realizado, de forma a garantir sua solução;
Em relação aos atributos RAP são eles:
-
RAP 4: Medidas são planejadas e coletadas para monitoração da execução do processo e ajustes são realizados;
-
RAP 14: Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades.
Em um artigo, intitulado "Diretrizes: Teste Unitário" e publicado pela Universidade Federal do Paraná - UFPR, o Teste Unitário é descrito como sendo "uma implementação com base no menor elemento testável (unidades) do software e implica em testar a estrutura interna (como fluxo lógico e de dados), a função da unidade e os comportamentos observáveis. O design e a implementação de testes com ênfase na estrutura interna de uma unidade se baseiam no conhecimento da implementação da unidade (abordagem caixa branca). No entanto, o design e a implementação de testes com a finalidade de verificar os comportamentos observáveis e as funções da unidade não se baseiam no conhecimento da implementação; por isso, são conhecidas como abordagem caixa preta.".
O BDD (Behavior-Driven Development) foi proposto como forma de auxiliar o desenvolvedor a criar testes e integrar regras de negócio com a linguagem de programação, mantendo o foco no comportamento do software (North 2006). Sua aplicação é baseada no modelo de entradas-eventos-saídas (given-when-then) que tem como objetivo capturar cenários que reflitam os critérios de validação de um comportamento esperado para o software.
Desta forma, é possível atender aos requisitos, realizar testes automatizados nos mais diversos cenários, reduzindo assim o número de defeitos encontrados. Neste sentido, a utilização de técnicas como o BDD durante o processo de desenvolvimento de software tende a aumentar a qualidade do produto final (Gerbaldo 2014).
O TDD é um estilo de desenvolvimento de software ágil derivado do método Extreme Programming (XP) (Beck 2000) e do Agile Manifesto (Agile Alliance 2000). A prática envolve a implementação de um sistema começando pelos casos de teste de um objeto. Escrevendo casos de teste e implementando estes objetos e métodos, surge a necessidade de outros métodos e objetos (Borges 2006).
Em seu artigo Eduardo N. Borges salienta que no TDD, desenvolvedores usam testes para guiar o projeto do sistema durante o desenvolvimento. Através dos resultados (falhas ou sucessos) julgam o progresso do desenvolvimento. Os programadores fazem continuamente pequenas decisões aumentando as funcionalidades do software a uma taxa relativamente constante. Todos estes casos de teste devem ser realizados com sucesso sucessivamente antes de o novo código ser considerado totalmente implementado.
No livro Clean Code (Martin 2008), Robert Martin entrevistou grandes especialistas em desenvolvimento de software como Ward Cunningham (colaborador na criação do Fit, do Wiki e da Programação Extrema (Beck 2000)) e Dave Thomas (fundador da OTI - Object Technology International - e muito envolvido no Projeto Eclipse) questionando-os quanto a uma definição para código limpo. No livro de Robert Martin ele diz que que cada um dos entrevistados elaborou respostas diferentes, destacando características subjetivas, como elegância, facilidade de alteração e simplicidade, e outras puramente técnicas, incluindo a falta de duplicações, presença de testes de unidade e de aceitação e a minimização do numero de entidades.
Segundo Robert Martin um código limpo esta inserido em um estilo de programação que busca a proximidade a três valores: expressividade, simplicidade e flexibilidade. Tais termos também são utilizados por Kent Beck no livro Implementation Patterns (Beck 2007) que estão em conformidade com a unidade de pensamento que permeia as respostas dos especialistas. Um importante aspecto quanto o desenvolvimento de um código limpo é o reconhecimento de que ele não será obtido em uma primeira tentativa. Robert Martin ressalta que as versões iniciais de um método, classe e outras estruturas nunca são exatamente uma boa solução. E necessário tempo e preocupação com cada elemento desde o nome escolhido para uma variável até uma hierarquia de classes.
Em seu artigo, publicado em 2016, Joao Machini diz que o desejável é não teremos empecilhos para as refatorações. E saliente que um caminho para isso é concentrar a atenção no desenvolvimento de um código limpo. Por exemplo, se as variáveis estiverem devidamente nomeadas, não precisaremos criar um comentário para explica-las. Se os métodos estiverem bem nomeados e possuírem uma unica tarefa, não será necessário documentar o que são os parâmetros e o valor de retorno.
O próprio site do SonarQube se define como sendo uma plataforma de código aberto para gerenciamento da qualidade do código fonte, dedicada a analisar e medir continuamente a qualidade técnica a partir de um portfólio de projetos.
A Plataforma avalia a qualidade do código fonte de acordo com sete eixos: Arquitetura e Projeto, Comentários, Regras de Codificação, Erros Potenciais, Complexidade, Testes Unitários e Duplicações. Ela integra ainda outras ferramentas de análise estática para avaliação do código fonte e posterior extração das métricas de software.
O GitHub será atrelado ao Travis. O Travis CI é um serviço de Integração Contínua na nuvem que pode ser conectado a repositórios no GitHub. Ele é gratuito para repositórios públicos e pago para repositórios privados.
A característica mais importante do CI está seu reporting. O fato de que é possível ver se um commit foi feito, teste estão falharam, quem fez o quê, quando e como, tudo isso é notificado por e-mail, essas coisas fazem do Travis uma ferramenta valiosa no conjunto de ferramentas de um projeto.
Toda vez que dermos um push no nosso repositório do GitHub, o Travis irá executar os seguintes passos:
- Criar uma máquina virtual em branco
- Pegar o código-fonte no GitHub
- Fazer o deploy da aplicação
- Rodar os testes
- Notificar o usuário (via e-mail, por exemplo, mas no nosso caso será via Slack)