Engenharia e Qualidade de Software

Prévia do material em texto

Engenharia e Qualidade de Software
Prof. Edson Moreno
Unidade II
Introdução
“A qualidade do software norteia todos os avanços da engenharia. O cliente é o foco das atenções no avanço da tecnologia. O cliente não quer mais só o software. Ele busca tecnologias atuais com qualidade, a um custo baixo e entrega dentro do prazo. A demanda de software aumenta sempre e os produtores de software têm que acompanhar tais mudanças. Consequentemente, as empresas empresas competem em inovações, melhorias e suporte ao cliente. Manter o software e adaptá-lo 
a novas tendências. Faz desta área uma das mais criativas”.
Prof. Ms. Edson Quedas Moreno
Conteúdo programático do Unidade 2 –
Qualidade, testes e manutenção do software
No módulo 2 serão abordados os seguintes itens:
 Capítulo 3 – Qualidade e produtividade de software: Fatores da qualidade; ISO 9126 / 25000; ISO 9001 / 90003; ISO 12207; CMMI; SPICE (ISO 15504).
 
 Capítulo 4 – Testes de software: Fundamentos; Verificação e Validação (V&V); Técnicas de testes de software.
 Capítulo 5 – Manutenção de software: Fundamentos; Tipos de manutenção; Procedimentos; Gerenciamento de mudanças; Gerenciamento de versões e releases. 
Capítulo 3 – Qualidade e produtividade de software
“A qualidade é importante, mas se o usuário não está satisfeito, nada mais realmente importa”.
 
3.1 Qualidade: uma abordagem da engenharia de software
Principais objetivos da qualidade: 
Reunir um conjunto de características, regras e procedimentos de modo que o software satisfaça às necessidades de seus usuários.
Levar menos tempo para fazer uma coisa correta do que explicar o porquê foi feito errado.
Garantir a qualidade mesmo depois de estar pronto o produto.
Estabelecer cronogramas e custos reais.
 
 
O PBQP (Programa Brasileiro da Qualidade e Produtividade) orienta e conduz uma estratégia para planejar a qualidade de software. Veja o livro “Qualidade e Produtividade no Setor de Software Brasileiro. Ministério da Ciência e Tecnologia, 2002”.
 
3.2 Fatores da qualidade de software:
processo de controle de qualidade do software
O controle de qualidade se refere à definição de processos e padrões a serem estabelecidos na produção. O objetivo é aplicar os processos e padrões, e consequentemente eliminar 
 produtos, que não atingiram o 
 nível de qualidade exigida.
 
 
3.2 Fatores da qualidade de software (continuação) 
Garantia de Qualidade de Software – GQS (Software Quality Assurance – SQA) 
O propósito da GQS é fornecer à gerência visibilidade da eficácia.
Determinar se há algum desvio com relação aos padrões, diretrizes, especificações, procedimentos e planos aprovados.
As revisões devem ser aplicadas em vários pontos de função durante o desenvolvimento.
 
 
Figura: Processo da Garantia da Qualidade de acordo com o PMI. Fonte: PMBOK, Project Management Body of Knowledge. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). – 4a ed. Atlanta, USA: Project Management Institute, Inc. 2010.
3.2 Fatores da qualidade de software (continuação)
Custo da qualidade
Custos de prevenção – Planejamento; revisões; ferramentas de diagnósticos e testes; e treinamento.
Custos de avaliação – Inspeção infra e interprocessos; precisão e manutenção dos equipamentos.
Custos de falha interna – Refazer; reparar; e análise do modo como a falha ocorreu.
Custos de falha externa – Solução das queixas; devolução e substituição do produto; manutenção da linha de suporte; e trabalho de garantia.
 
 
 Dados relatados por Kaplan, Clark e Tang em 1995, baseados no desenvolvimento de software da IBM”.
Fonte: Boehm, 2002.
 
 
3.2 Fatores da qualidade de software (continuação)
Fatores e métricas da qualidade
(Pressman, 2002) “Qualidade de software é uma mistura complexa de fatores que vão variar com cada aplicação diferente e com os clientes que as encomendam”.
O fator de qualidade determina a exigência da qualidade necessária. É composto por métricas da qualidade do software.
As métricas da qualidade são medidas quantitativas que permitem aos desenvolvedores ter ideia da eficácia do processo de software e dos produtos produzidos. 
 
 
 
 
	Exemplo de análise: Fatores x Métricas do software			
	Fator de qualidade	Métrica da qualidade		
		Confiabilidade	Eficiência	Reusabilidade
	Modularidade	X		X
	Operabilidade		X	X
	Instrumentação	X		
3.2 Fatores da qualidade de software (continuação)
Métricas de qualidade do software 
	Exemplo de algumas métricas de qualidade do software: (Fontes: Pressman, 2007; NBR 9126; NBR 12207) 	
	MÉTRICA	DEFINIÇÃO
	Auditabilidade	
		Facilidade no atendimento às normas que pode ser verificado.
	Capacidade	Capacidade do produto de software em ser instalado em ambiente especificado e atender aos requisitos de funcionamento.
	Mantenabilidade	Esforço necessário para localizar e corrigir erros num programa.
	Usabilidade	Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas.
3.3 Qualidade do produto da engenharia de software: 
ISO/IEC 9126
Fonte: NBR 9126-1 ABNT, 2003
O objetivo da ISO 9126 é descrever um modelo de qualidade do produto de software, composto de duas partes:
a) qualidade interna e qualidade externa; e 
b) qualidade em uso. 
 
3.3 Qualidade do produto da engenharia de software: 
ISO 25000
A ISO/IEC 25000 é também chamada de Square, que significa Software Product Quality Requirements and Evaluation (Requisitos de Qualidade e Avaliação de Produtos de Software).
A ISO 25000 é uma evolução das séries de normas ISO/IEC 9126 e ISO/IEC14598.
A reorganização da Norma ISO/IEC 25000 dividiu os assuntos em cinco tópicos (Veja a figura). Cada divisão é composta por um conjunto de documentos e trata de um assunto em particular: 
 
	Requisitos de Qualidade	Modelo de Qualidade	Avaliação
		Medições de Qualidade	
		Medições	
3.4 Sistemas da qualidade: 
ISO 9001
A ISO 9000 é definida como “Padrões para a Gerência da Qualidade e Garantia de Qualidade. Diretrizes para a Seleção e Uso”. A ISO 9000 orienta as organizações a desenhar seus sistemas de qualidade.
A ISO 9001 faz parte da série ISO 9000. A ISO 9001 estabelece o Modelo de Garantia de Qualidade em projeto, instalação, desenvolvimento, produção, arquitetura e serviço.
 
A ISO 9001 é usada para demonstrar capacidade de atender aos requisitos do cliente, os regulamentares e os da própria organização. Define um conjunto de requisitos para o SGQ – Sistema de Gestão da Qualidade da organização.
 
3.4 Sistemas da qualidade: 
ISO 90003
A ISO 90003 é uma evolução da norma ISO 9000-3:2000 (Modelo de Garantia de Qualidade em inspeção e ensaios finais (testes)), que descreve as diretrizes para a aplicação da ISO 9001. 
 
Principais pontos da ISO 90003:2004:
planejamento da realização do produto; 
processos relacionados ao cliente;
projeto de desenvolvimento;
aquisição; 
produção e fornecimento de serviço;
medição, análise e melhoria.
 
3.5 ISO 12207 – Processos do ciclo de vida do software
O objetivo da Norma NBR ISO 12207 - Processos do Ciclo de Vida do Software é o de fornecer uma estrutura comum para que os stakeholders, utilizem uma linguagem comum no desenvolvimento do software.
	1. Processos Fundamentais		2. Processos de Apoio
	1.1 Aquisição		2.1 Documentação
	1.2 Fornecimento		2.2 Gerência de configuração
	1.3 Desenvolvimento	1.4 Operação	2.3 Garantia da qualidade
			2.4 Verificação
			2.5 Validação
		1.5 Manutenção	2.6 Revisão conjunta
			2.7 Auditoria
			2.8 Resolução de problema
	3. Processos Organizacionais		
	3.1 Gerência		3.3 Infraestrutura
	3.2 Melhoria		3.4 Treinamento
3.6 Modelo de qualidade de software: 
Capability Maturity Model Integration – CMMI
O Modelo Integrado de Maturidade e Capacidade descreve uma estrutura de capacidade em cinco níveis.As práticas recomendadas são distribuídas em 22 Áreas-chaves de Processo (KPA – Key Process Area). 
 Fonte: CMMI Product Development Team – SEI, 2000.
3.6 Modelo de qualidade de software: 
SPICE – ISO 15504
A ISO/IEC 15504, conhecida como SPICE – Software Process Improvement & Capability dEtermination (Melhoria do Processo de Software e Determinação da Capacidade), é a norma que define as atividades para manter a qualidade de software e seu projeto se baseia nos modelos já existentes como ISO 9000 e CMMI. Ela é uma “evolução” da ISO/IEC 12207, que possui níveis de capacidade para cada processo. 
O framework da ISO 15504 inclui um modelo de referência que serve de base para o processo de avaliação. Um conjunto processos estabelecidos em duas dimensões: 
dimensão de processo; e 
dimensão de capacidade.
Interatividade
Leia o argumento: "Algumas empresas da área de TI, devido a uma alta demanda para o fornecimento de software, acabam por trabalhar no ritmo de apenas corrigir uma falha ou erro do software, sem nenhum registro nem sequer documentação apropriada, com o objetivo de acelerar o processo de entrega. Apesar de ser uma solução do tipo "apaga incêndio" é considerada como uma atividade eficiente". 
Em relação ao argumento para solucionar o problema de atender à demanda. Analise esse argumento e considere como correta uma das alternativas a seguir, como uma prática correta da engenharia de software.
O argumento é válido, sem questionamentos pela falta um planejamento. O mais importante é a solução imediata do problema para atender à demanda.
O argumento é válido porque acarretaria em um tempo e um custo dispendioso para a elaboração de um planejamento. Uma solução imediata é mais eficiente.
O argumento não é válido porque falta um planejamento para a resolução do problema. A falta deste planejamento acarreta em um tempo e um custo alto para a solução final do problema.
O argumento não é válido porque falta um planejamento para a resolução do problema. O planejamento garante um sistema sem falhas ou erros.
O argumento pode ou não ser válido. Tudo vai depender do tempo e custo disponíveis para resolver o problema.
Interatividade
Alternativa correta: C
Incorreto. Este argumento não é válido porque falta um planejamento para a resolução do problema. Um problema de software a ser corrigido, avalia se a mudança não vai impactar no ambiente operacional, o que pode levar a outros problemas. Um problema resolvido de imediato atende naquele instante, mas a falta de registros aumenta a complexidade para resolução de problemas futuros. 
Incorreto. (justificativa, idem a “a”)
CORRETO. O planejamento é necessário. Deve se considerar o tempo e custo total para a resolução do problema. O tempo e custo total são a soma do tempo e custo do planejamento e da manutenção. O valor tem de ser o menor possível. Quando se planeja, o tempo e custo total e o da manutenção são baixos. 
Incorreto. O planejamento é necessário (justificativa, idem a “c”). Contudo, não garante a isenção de falhas ou erros no sistema, é necessário monitoramento contínuo.
Incorreto. O argumento é inválido (justificativa, idem a “c”).
Capítulo 4 – Testes de software
4.1 Fundamentos dos testes de software
O teste do software é destinado a descobrir os defeitos do programa antes do uso.
A principal métrica do teste de software é a testabilidade.
Índice alto de testabilidade indica a facilidade do software de expor falhas que geram defeitos. 
Índice baixo de testabilidade indica a dificuldade de identificar falhas que geram defeitos.
O teste é uma parte ampla da engenharia de software e faz parte dos processos de validação e verificação (V&V). 
(Sommerville, 2011) “Quando se testa o software, o programa é executado usando dados fictícios. Os resultados do teste são verificados à procura de erros, anomalias ou informações sobre os atributos não funcionais do programa”. 
(Pressman, 2011) “O teste muitas vezes requer mais trabalho de projeto do que qualquer outra ação da engenharia de software”.
4.2 Verificação e validação (V&V)
Verificação é a ação de inspecionar o produto, por meio da análise, testes, diagnósticos e simulações, para assegurar que o que foi construído, foi construído da forma correta de acordo com as exigências. 
Validação demonstra conveniência satisfatória das partes interessadas no uso do produto, no ambiente operacional planejado. 
Objetivo da validação – demonstrar que um produto criado ou seus componentes satisfazem o objetivo quando são colocados ou testados no ambiente do cliente final.
4.2 Verificação e validação (V&V) (continuação)
A atividade de verificação inicia pelo código e consiste em confrontar o requisito do software com o resultado obtido pelo software, para garantir que o projetado foi construído de acordo. 
Na verificação do código fonte faz-se a depuração de falhas (debug), que é a atividade de limpeza ou exclusão de partes indesejáveis.
Atividade da depuração de falhas (debugging) 
consiste em quatro tarefas:
Reprodução (reproduce): rastrear e identificar o erro.
Diagnóstico (diagnose): avaliar o impacto do erro no produto.
Corrigir (fix): implementar correções necessárias.
Refletir (reflect): analisar o impacto da mudança no sistema.
4.2 Verificação e validação (V&V) (continuação)
A atividade de validação é a última fase do processo da engenharia de requisitos, responsável por autorizar o desenvolvimento do sistema/software. A figura apresenta o modelo do Processo da Engenharia de Requisitos do software/sistema.
Figura: Modelo do Processo da Engenharia de Requisitos do software / sistema. 
4.3 Técnicas de testes de software
Nível alto de testes – baseia-se nas opiniões do usuário em obter resultados que atendam as suas expectativas, bem como falhas ou omissões de requisitos. 
Nível baixo de testes – está fundamentado na codificação da lógica de processamento, que fornece o resultado desejado pelo algoritmo construído. No caso, a visão do desenvolvedor se baseia nas abordagens top-down e bottom-up, que veremos a seguir.
Quem desenvolve não testa e quem testa não desenvolve.
4.3 Técnicas de testes de software (continuação)
Abordagens top-down e bottom-up
A abordagem top-down (ver a figura) verifica a integração dos componentes de um sistema começando pelos níveis superiores (operações e interface com o usuário) e pode caminhar para os níveis inferiores incluindo testes do código. 
A abordagem bottom-up (ver a figura), começa pelos níveis inferiores (algoritmos, interface com usuário, interface com o hardware, drivers e instalação) e caminha para os níveis superiores.
4.3 Técnicas de testes de software (continuação)
Testes Alfa e Beta
No processo V&V, quando um software é construído especificamente para um cliente, é normal que ele passe por um teste de aceitação por parte do usuário. 
A melhor estratégia são as dos Testes Alfa e Beta. 
Teste Alfa – Os usuários são levados a testar o software desde seus estágios iniciais de instalação até a sua operação completa. Tudo realizado num ambiente especial, controlado pelos desenvolvedores.
Teste Beta – é acompanhado por uma versão release, realizado exclusivamente no habitat do usuário em ambiente descontrolado. Sem a presença do desenvolvedor, porém monitorados por estes, ao contrário do Teste Alfa. 
4.3 Técnicas de testes de software (continuação)
Testes Caixa-branca e Caixa-preta
Os testes Caixa-branca e Caixa-preta são guiados pelo código-fonte, respectivas métricas de software aplicáveis e se realmente estão atendendo aos requisitos com um bom desempenho e segurança.
O Teste Caixa-branca (teste estrutural) – É focado nos possíveis erros internos de estrutura dos componentes do software ou sistema.
Teste Caixa-preta (teste comportamental) – Visa identificar as falhas em seu comportamento externo, com foco nos requisitos funcionais e conduzidos na interface de software com o usuário e com o hardware.
4.3 Técnicas de testes de software (continuação)
Testes Caixa-branca e Caixa-preta (continuação)
Atécnica de maior aplicação no Teste Caixa-branca é chamada de Teste do Caminho Básico (ou grafo de fluxo). O grafo de fluxo pode ser construído com base em um fluxograma ou diagrama de atividades.
Capítulo 5 – Manutenção do software
5.1 Fundamentos da manutenção
O processo de mudança do software ocorre em todo o seu ciclo de vida. Adaptações a novos ambientes operacionais e interfaces, mudanças de requisitos, possíveis erros de projeto ou de codificação. Tudo para manter o software operacional e adaptado a novas tecnologias.
 
Leis de Lehman (1985). Duas destas leis se destacam: 
Mudança contínua: um programa utilizado em um ambiente do mundo real necessariamente tem de ser modificado ou se tornará de maneira progressiva menos útil nesse ambiente.
Aumento da complexidade: à medida que um programa em evolução se modifica, sua estrutura tende se tornar mais complexa. São necessários recursos extras para manter e simplificar a estrutura.
 
 
5.2 Tipos de manutenção / 5.3 Procedimentos de manutenção
Manutenção para reparar defeitos no software. 
Manutenção para adaptar o software a um ambiente operacional diferente. 
Manutenção para fazer acréscimos à funcionalidade do sistema ou modificá-la.
5.4 Gerenciamento de mudanças
O principal passo desse processo é a utilização do formulário de “Requisição de Mudança” (veja o modelo). Após a validação, ocorre à manutenção do software.
5.5 Gerenciamento de versões e releases
O gerenciamento de versões e releases identifica o desenvolvimento das diferentes versões e releases de um sistema. Este processo é chamado de versionamento.
O release é a versão do software autorizada para distribuir ao cliente. 
As versões são criadas para testes ou desenvolvimento interno. Não são liberadas para os clientes.
Interatividade
“A manutenção do software ocorre em todo o seu ciclo de vida útil. O software não se desgasta como o hardware, em que o componente é simplesmente trocado por um que funcione. A manutenção do software ocorre pelas mudanças neste, que são praticadas”. São considerados tipos de manutenção do software:
Fazer limpeza dos dados, remover redundâncias de algorítmos e de dados e adaptar uma nova estrutura de dados.
Modularizar, praticar mudanças e medir o desempenho do software.
Reparar os defeitos no software, adaptá-lo a um ambiente operacional diferente e fazer acrescimos à funcionalidade do sistema ou modificá-lo.
Reparar os defeitos no software, modularizá-lo e medir o seu desempenho.
Testar suas funcionalidades, modularizar e praticar mudanças do software.
Interatividade
Alternativa correta: C
Incorreto. A atividade de adaptar uma nova estrutura de dados é uma atividade de projeto.
Incorreto. Modularizar o software é uma atividade de projeto. Praticar mudanças do software é implementar novas alterações dos requisitos ou corrigir falhas no software, o que é válido. Medir o desempenho do software se refere ao controle de qualidade.
CORRETO. Todas as atividades são consideradas tipos de manutenção. 
Incorreto. Reparar os defeitos do software é válido. Modularizar o software é uma atividade de projeto. Medir o desempenho do software se refere ao controle de qualidade.
Incorreto. Testar suas funcionalidades é uma atividade de acompanhamento de testes dos requistos do software. Modularizar o software é uma atividade de projeto. Praticar mudanças do software é implementar novas alterações dos requisitos ou corrigir falhas no software, o que é válido.
ATÉ A PRÓXIMA!
Estudo da Viabilidade 
do sistema
Especificação
, 
Modelagem e 
Documentação
Elicitação e Análise de 
requisitos
Validação
Nova Iteração
Início
Desenvolvimento do 
Sistema
�
Estudo da Viabilidade do sistema
Especificação, Modelagem e Documentação
Elicitação e Análise de requisitos
Validação
Nova Iteração
Início
Desenvolvimento do Sistema