Projeto de Qualidade de Software

Conceito

De acordo com o SWEBOK 3.0, documento criado sob o patrocínio da IEEE com a finalidade de servir de referência em assuntos considerados, de forma generalizada pela comunidade, como pertinentes a área de Engenharia de Software, a qualidade de software é uma área que pode se referir a: "as características desejadas de produtos de software, a extensão em que um produto de software em particular possui essas características e aos processos, ferramentas e técnicas que são usadas para garantir essas características".

Existem muitas definições de qualidade de software na literatura, entre elas as mais conhecidas são:

• Peters(2002): “Qualidade de software é avaliada em termos de atributos de alto nível chamados fatores, que são medidos em relação a atributos de baixo nível chamados de critérios”.
• Sanders(1994): “Um produto de software apresenta qualidade dependendo do grau de satisfação das necessidades dos clientes sob todos os aspectos do produto”.
• Pressman: “Qualidade de software é a conformidade a requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo software desenvolvido por profissionais”.
• ISO9126 (1994):“Qualidade é a totalidade de características e critérios de um produto ou serviço que exercem suas habilidades para satisfazer às necessidades declaradas ou envolvidas “.

É importante notar que todas as definições citadas enfatizam três pontos importantes, os requisitos funcionais do software, os padrões e os requisitos não funcionais.

1. Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de conformidade com os requisitos significa falta de qualidade;
2. Padrões especificados definem um conjunto de critérios de desenvolvimento que orientam a maneira segundo a qual o software passa pelo trabalho de engenharia. Se os critérios não forem seguidos, o resultado quase que seguramente será a falta de qualidade.
3. Existe um conjunto de requisitos implícitos que freqüentemente não são mencionados na especificação. Por exemplo, o desejo de uma boa Integridade no acesso ao Sistema.

Sendo assim, a busca constante pela qualidade não está ligada somente ao início ou final do projeto, mas sim e um processo que visa abranger toda a engenharia de software bem como a colaboração de todos os membros do time do projeto.

Uma possível definição mais abrangente e completa para qualidade de software seria a proposta por Bartié (2002): "Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos". (BARTIÉ, 2002, p. 16)

Há o que McCall e Cavano (1978) sugerem como métricas para qualidade de software. Conhecido como Fatores da Qualidade, estes fatores avaliam o software em três pontos distintos: Transição do Produto, Revisão do Produto e Operação do Produto.

Assim como o modelo proposto por McCall e Cavano (1978), "a HP desenvolveu também um modelo que referencia fatores da qualidade de software e que primeiramente publicado por Grady and Caswell (1987), denominado FURPS: Functionality, Usability, Reliability, Performance e Supportability. Estes fatores estabelecem as métricas de qualidade de software para cada fase do processo de engenharia de software". (PRESSMAN, 2005, p. 539)

Além desses modelos de métricas para qualidade de software, nota-se que a constante busca pela mesma se tornou uma atividade essencial dentro das empresas. Colocando-se todos esses conceitos dentro do contexto apresentado, podemos dizer que "qualidade não é uma fase do ciclo de desenvolvimento de software ... é parte de todas as fases".(BARTIÉ, 2002, p. 16)

Portanto, é necessário um planejamento adequado para que a qualidade de software seja atingida, conforme a definição de qualidade que deverá ser alcançada. Para isso são necessários modelos, padrões, procedimentos e técnicas para atingir essas metas de qualidade propostas. Para tanto, todas as etapas do ciclo de vida de engenharia de software devem ser contempladas com atividades que visam garantir a qualidade tanto do processo quanto do produto.

Metodologia

Um desenvolvimento organizado de software tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão definidos os passos necessários para chegar ao produto final esperado.

Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software espera-se um produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.

Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo.

Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.

Independente da metodologia de trabalho que empregue para o desenvolvimento de um software, para que se obtenha um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de software.

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugerido por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes, como por exemplo, os ”SW-CMM”, ”SE-CMM”, ”ISO 15504” e o mais conhecido ”CMMI”.

Outro fator com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e/ou financeiros.

Software

De acordo com tudo o que foi descrito fica nítido que a qualidade de um software é criada não só em sua fase inicial ou final, a qualidade do software faz parte de todo o processo de seu desenvolvimento desde a fase de análise de requisitos, desenvolvimento, testes e implantação. Dito isso será listado abaixo alguns softwares intimamente ligados à fase de testes do software, que constitui um dos pilares para a obtenção da qualidade.

Existem vários tipos de testes que podem ser realizados para um software, sendo destacados abaixo os 13 principais:

1. Teste de Configuração
   • Testa se o software funciona no hardware a ser instalado.
2. Teste de Instalação
   • Testa se o software instala como planejado, em diferentes hardwares e sob diferentes condições, como pouco espaço de memória, interrupções de rede, interrupções na instalação etc.
3. Teste de Integridade
   • Testa a resistência do software à falhas (robustez).
4. Teste de Segurança
   • Testa se o sistema e os dados são acessados de maneira segura, apenas pelo autor das ações.
5. Teste Funcional
   • Testa os requisitos funcionais, as funções e os casos de uso. “A aplicação faz o que deveria fazer?”
6. Teste de Unidade
   • Testa um componente isolado ou classe do sistema.
7. Teste de Integração
   • Testa se um ou mais componentes combinados funcionam de maneira satisfatória. Há quem diga que o teste de integração é composto por vários testes de unidade.
8. Teste de Volume
   • Testa o comportamento do sistema operando com o volume “normal” de dados e transações envolvendo o banco de dados durante um longo período de tempo.
9. Teste de Performance
   1. Teste de carga:
      • Testa o software sob as condições normais de uso. Ex.: tempo de resposta, número de transações por minuto, usuários simultâneos etc.
   2. Teste de stress
      • Testa o software sob condições extremas de uso. Grande volume de transações e usuários simultâneos. Picos excessivos de carga em curtos períodos de tempo.
   3. Teste de estabilidade
      • Testa se o sistema se mantém funcionando de maneira satisfatória após um período de uso.
10. Teste de Usabilidade
    • Teste focado na experiência do usuário, consistência da interface, layout, acesso às funcionalidades etc.
11. Testes de Caixa Branca e Caixa Preta
    • Basicamente, teste de caixa branca envolve o código e o de caixa-preta, não.
12. Teste de Regressão
    • Reteste de um sistema ou componente para verificar se alguma modificação recente causou algum efeito indesejado, além de, certificar se o sistema ainda atende os requisitos.
13. Teste de Manutenção
    • Testa se a mudança de ambiente não interferiu no funcionamento do sistema.

Porém não basta apenas realizar os testes, é necessário que exista uma documentação de tudo que foi realizado. Para isso, é apresentada a ferramenta de gerenciamento de testes , TestLink

O TestLink é uma ferramenta web gratuita criada para gerenciar e documentar os testes de requisitos de uma distribuição do software. Como é uma software de código livre foi criado e é mantido por várias equipes ao redor do globo. O software se encontra no link [http:/http://testlink.org/] para ser feito o download e imediatamente seu uso.

Dentre as funcionalidades do TestLink pode-se destacar:

• Criar um projeto do TestLink;
• Cadastrar requisitos;
• Especificar casos de teste;
• Vincular requisitos aos casos de teste;
• Criar um Plano de Teste e adicionar Casos de Teste a esse plano;
• Definir Projeto;
• Executar o teste;
• Arvore de dependências dos casos de testes x Mantis;
• Associar um bug do Mantis ao caso de teste;
• Resultados e Métrica

--> O Mantis é outro software semelhante ao TestLink porém nele são registrados apenas os bugs encontrados.

Segue telas de exemplo do TestLink:

Diagrama de Blocos

• Qualidade de Software segundo o SWEBOK

O SWEBOK (Software Engineering Body of Knowledge) versão 2004 do IEEE (Institute of Electrical and Electronics Engineers) apresenta em uma das suas KA´s (Knowledge Areas) a KA de Software Quality.

A qualidade é uma das áreas que contém maiores investimentos financeiros, de pessoal e tempo para ser atingida. Novamente de acordo com Bartié (2002), "Um dos maiores desafios a ser considerados é estabelecer um modelo de custos relacionados a implantação de um processo de garantia da qualidade de software." (BARTIÉ, 2002, p. 29)

• Qualidade de Software segundo a ISO 9126-1

Além da NBR ISO/IEC 9126-1, existem ainda outras normas da série 9126, as quais são:

1. ISO/IEC 9126-2 - Métricas Externas: Podem ser aplicadas para um produto não executável durante os estágios de desenvolvimento. Medem a qualidade de produtos intermediários e predizem a qualidade do produto final.
2. ISO/IEC 9126-3 - Métricas Internas: Utilizadas para medir a qualidade do software através do comportamento do sistema ou de parte dele. Só podem ser usadas durante a fase de testes do ciclo de vida e durante a operação do sistema.
3. ISO/IEC 9126-4 - Métricas da Qualidade do Uso: medem se o produto atende ou não as necessidades dos usuários, fazendo-os atingir seus objetivos com efetividade, produtividade, segurança e satisfação. Só podem ser usadas no ambiente real ou em uma aproximação do ambiente real.

• A Qualidade segundo o PMBOK do PMI

O PMBOK (Project Management Body Of knowledge) do PMI (Project Management Institute), na sua versão 2004 apresenta o gerenciamento da qualidade do projeto conforme:

Interações com as tecnologias

• Scrum: Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum. Site do Scrum

• Mantis: "MantisBT é um rastreador de problemas de código aberto que fornece um delicado equilíbrio entre simplicidade e poder. Os usuários podem começar em poucos minutos e começar a gerenciar seus projetos enquanto colaboram com seus colegas de equipe e clientes de forma eficaz. Uma vez que você começar a usá-lo, você nunca mais voltará!" Site do Mantis

• Modelos para condução de Projetos de Software: Alguns modelos foram desenvolvidos de forma a auxiliar a condução de atividades que envolvam projetos de software. O objetivo deste artigo é fornecer uma visão geral sobre dois destes modelos (CMMI e MPS-BR), baseando-se para isto em um conceito conhecido como “maturidade”. Artigo DevMedia

Referências bibliográficas

• Maturidade no desenvolvimento de software: CMMI e MPS-BR. DevMedia. Disponível em: http://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-e-mps-br/27010 Acesso em: 12 de out. 2017.

• Qualidade, Qualidade de Software e Garantia da Qualidade de Software são as mesmas coisas? Linha de Código. Disponível em: http://www.linhadecodigo.com.br/artigo/1712/qualidade-qualidade-de-software-e-garantia-da-qualidade-de-software-sao-as-mesmas-coisas.aspx Acesso em: 13 de out. 2017.

• Qualidade + Testes de Softwares = Qualidade de Software. TI Especialistas. Disponível em:https://www.tiespecialistas.com.br/2015/02/qualidade-testes-de-softwares-qualidade-de-software/ Acesso em: 12 de out. 2017.

• Qualidade de software. Wikipedia. Disponível em: https://pt.wikipedia.org/wiki/Qualidade_de_software. Acesso em: 13 de out. 2017.

• Qualidade de Software – Parte 01. DevMedia. Disponível em: http://www.devmedia.com.br/qualidade-de-software-parte-01/9408 Acesso em: 13 de out. 2017.

• Qualidade de Software: Uma questão de eficiência. DevMedia. Disponível em:http://www.devmedia.com.br/qualidade-de-software-uma-questao-de-eficiencia/17803 Acesso em: 13 de out. 2017.

• Qualidade de Software:Visão Geral. univasf. Disponível em:http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula05.pdf. Acesso em: 13 de out. 2017.