QUALIDADE DE SOFTWARE

1) Má-Qualidade de Software
Ocasiona perda de negócios, dados, tempo e dinheiro. Empresas podem sofrer com
os processos judiciais, custos, má-reputação e perda de clientes.
Um software sem qualidade causa projetos de software difíceis de planejar e
controlar, a funcionalidade dos programas nem sempre funcionam como planejado e podem
existir muitos defeitos nos sistemas.

2) Qualidade de Software
Resultam em prazos sob controle, satisfação dos usuários, diminuição de erros nos
projetos de software e melhora a posição competitiva da empresa.
Existem pontos de vistas diferentes em relação a qualidade de software, como:
- Melhor custo benefício,
- Características inerentes ao produto são melhores,
- Conformidade com as especificações,
- Atender as metas dos usuários
“Qualidade é o grau em que o sistema, componente ou processo atende os requisitos
especificados e as expectativas e necessidades do cliente ou do usuário.”

3) Dificuldades da Qualidade de Software

Os interesses dos stakeholders podem ser conflitantes, pode ser difícil identificar
corretamente todos os requisitos do sistema e alguns fatores podem afetar a qualidade
como a tecnologia de desenvolvimento, qualidade das pessoas envolvidas, gerência, custo,
tempo, cronograma e qualidade do processo.
 TESTE DE INTEGRAÇÃO

1) Testes de Componentes ou Testes de Integração

Nos testes de integração, o foco é em verificar como diferentes partes do software
interagem entre si, assim avaliam a comunicação e o funcionamento conjunto de vários
componentes.
Uma parte crítica dos testes de integração é garantir que as interfaces de
comunicação entre os módulos estejam funcionando corretamente.
Caso de testes devem ser projetados para testar a comunicação entre diferentes
componentes (Objetos, Módulos, Interfaces, etc).

2) Teste de Sistema
Busca testar o sistema completo, é uma interação entre todos os componentes até a
interface. É um processo coletivo, componentes desenvolvidos por partes diferentes já
devem ser integrados e pode ser realizado pela equipe de devs ou equipe de testes.
São testes baseados em casos de uso/história de usuário.

3) Desenvolvimento Dirigido à Teste (TDD)

Metodologia em que se intercalam o desenvolvimento de teste e o código e é um
desenvolvimento incremental. Passos:
- Escolha a funcionalidade a ser implementada
- Escreva primeiramente o teste automatizado
- Implementar a funcionalidade

● Vantagens: garante grande cobertura de testes; maior qualidade e entendimento da

funcionalidade; documentação mínima e teste de regressão.
● Desvantagens: maior tempo de desenvolvimento; toda a equipe deve realizar e
precisa de manutenção no código de testes
 4) Plano de Teste
Estabelece como o processo de teste será conduzido, utilizado no desenvolvimento
de grandes projetos de software.

5) Teste de Entrega ou Lançamento (release)

São testes de uma versão entregável do sistema que será acessível aos usuários,
não serão realizados pelos devs.
Ele confere a validade do sistema e geralmente é um teste caixa-preta(funcional).

6) Teste Baseado em Requisitos

Cada requisito deve ser testável, e é feito um teste de entrega com base no
documento de especificação de rastreabilidade.

7) Teste de Cenário
É feito baseando-se em cenários reais de uso típico do sistema e são testados
diferentes requisitos dentro de um mesmo cenário. As histórias de usuário e cenários
utilizados na elicitação de requisitos podem ser reutilizados para os testes.

8) Teste de Desempenho
São feitos uma série de testes em que se aumenta a carga progressivamente, assim
consegue identificar circunstâncias que sobrecarregam o sistema por meio de uma
combinação inesperada de eventos. Muito útil em sistemas distribuídos e baseado em
nuvem.

9) Teste de Usuário
É a etapa posterior ao teste de lançamento. São testes realizados por usuários finais
do sistema. Existem 3 tipos:
- Teste-alfa: pode ocorrer durante o desenvolvimento, e é selecionado um grupo de
usuários trabalhando em colaboração com a equipe de desenvolvimento.
- Teste-beta: teste de um lançamento inicial às vezes inacabado do sistema
- Teste de Aceitação: usuários finais testam o sistema com seus próprios dados e
definem se o sistema está pronto para entrega (aceito)
 10) Testes de Sistema Web
Os sistemas web possuem diferentes arquiteturas de desenvolvimento, muitas vezes
diferindo na forma como os testes são conduzidos. Podemos utilizar testes do modelo de
interface, unitários, de segurança, de desempenho e de usabilidade.

11) Testes de Aplicativos Móveis

Podemos utilizar os testes de experiência do usuário (usabilidade), de performance,
de compatibilidade com dispositivos, de conectividade, de segurança, de certificação e de
interface com usuário.
 EVOLUÇÃO, MANUTENÇÃO E REUSO DE SOFTWARE

1) Evolução do Software
Sua vida útil geralmente é bem longa, mas é necessário se adaptar a mudanças e evoluir
para permanecerem úteis. Em sistemas corporativos essa evolução pode ser custosa.

2) Modelo do Processo de Desenvolvimento e Evolução

Modelo baseado na entrega de versões e o tempo entre as versões está cada vez menor
juntamente com o pacote de mudanças. É aplicado quando a empresa desenvolvedora é a
mesma que mantém o software.

A maior diferença está entre a fase de evolução e de “em serviço”, na fase de evolução
acontecem grandes mudanças na arquitetura de adição de novas funcionalidades, já na
fase “em serviço” as mudanças são pequenas e essenciais.

3) Processo de Evolução de Software

Os processos não são únicos, pois podem variar quanto ao tipo de software, a cultura da
empresa, equipe e cliente.
● Processos Informais: são conversas com os stakeholders, novas ideias no time,
feedback dos usuários, relatório de defeitos. É um processo CÍCLICO

● Processos Formais: cada processo documentado e aprovado, e esta documentação

deve se manter atualizada.
 4) Processo de Mudança Emergencial
São mudanças que alteram o funcionamento normal e nem sempre é possível atualizar a
documentação, então a alteração precisa ser no código primeiro.

5) Sistemas Legados
São sistemas antigos que ainda estão em funcionamento e possivelmente desempenham
papel fundamental na operação dos códigos, possuem pouca manutenção e mudança.
“Por que as empresas não substituem por equivalentes modernos?”
Ele é eficiente e eficaz ao núcleo do negócio, custo para substituí-lo é maior do que
o da manutenção, não existe documentação, mudanças no software implicam mudanças
em processos, riscos em desenvolver um novo sistema.

6) Gerenciamento de Sistemas Legados

Existem 4 pontos estratégicos a se considerar:
i) Deixar o sistema intacto e continuar com a manutenção regular
ii) Reengenharia do sistema para melhorar sua manutenibilidade
iii) Substituição de todo ou parte do sistema por um novo
iv) Descartar completamente o sistema

7) Manutenção de Software
Existem 3 tipos diferentes de manutenção:
i) Reparo de defeitos: corrigir bugs, inconsistências, erros de código, dados, projeto
ii) Adaptação a novas plataformas e ambientes: mudança de dependência, SO, hardware
iii) Adição de novas funcionalidades: mudança nos requisitos

Segue um gráfico com os custos de acordo com o tipo de manutenção:

O motivo para o custo de adição de funcionalidades ser maior é porque o time de
manutenção pode ser diferente do time de desenvolvimento, então o time precisa entender
o programa que está sendo mantido, o trabalho de manutenção pode ser visto como menos
qualificado e com o tempo a estrutura do software se degrada se tornando mais difícil de
modificar.

8) Previsão de Manutenção
Para prever o número de pedidos de mudanças requer entender a relação entre o sistema e
o ambiente externo. Deve-se examinar a quantidade e complexidade de interfaces do
sistemas e também a quantidade de requisitos voláteis do sistema.
Quanto maior a complexidade de um sistema maior o custo de manutenção.

9) Métricas para Prever a Manutenibilidade

Quantidade de solicitações de manutenção corretiva, tempo médio para análise de impacto
da mudança e implementação de uma mudança, quantidade pendentes de solicitações de
mudanças.
 REENGENHARIA DE SOFTWARE

É o processo de entender o funcionamento de um sistema e alterá-lo. É preciso nova

documentação, refatoração da arquitetura do sistema, tradução para outras linguagens de
programação, modificação da estrutura de dados e valores, já as funcionalidades
geralmente se mantêm.

1) Modelo de Reengenharia de Software

● Tradução de código-fonte: tradução de uma linguagem para outra moderna ou uma

versão mais recente
● Engenharia Reversa: todo o sistema é analisado na busca por informações para
documentação e organização.
● Melhoria de Estrutura do Programa: é para facilitar o entendimento e possivelmente
permitir extensão e melhor desempenho.
● Modularização do Programa: partes relacionadas são agrupadas em
módulos/componentes removendo redundâncias.
● Reengenharia de Dados: estrutura de dados que pode ser alterada para refletir
mudanças.

2) Limitações da Reengenharia
Mudanças podem não ser possíveis. Ao realizar mudanças na estrutura dos dados pode
levar a perda de informação ou inconsistências, se não for bem feito a manutenibilidade
pode piorar.
 REUSO DE SOFTWARE - PARTE 1

1) Engenharia de Software Baseada em Reuso

- Reuso do Sistema: Sistemas completos que podem ser compostos de uma série de
programas de aplicação e usados em um sistema de sistemas.
- Reuso de Aplicações: Uma aplicação pode ser reusada ao ser incorporada sem
alterações a outros sistemas ou configurada para diferentes clientes.
- Reuso de Componentes: podem ser reutilizados componentes de uma aplicação,
módulos, conjunto de classes, etc
- Reuso de Objetos e Funções: componentes simples que podem implementar até
uma única função.

2) Reuso de Conceito
Nem todo componente com funcionalidades genéricas são reusáveis. Muitas vezes a
implementação de um software ou componente é muito específica sendo caro sua
modificação.
I) Vantagens: desenvolvimento acelerado, o reuso agrega o conhecimento dos
especialistas que o desenvolveram, maior confiabilidade, menores custos de
desenvolvimento, menos risco para o processo e possui conformidade com padrões.
II) Desvantagens: criar/manter/usar uma biblioteca de componentes,
encontrar/entender/adaptar os componentes, maior custo de manutenção, falta de suporte
da ferramenta.

É importante incorporar o processo de Reuso no processo de desenvolvimento de

software. O panorama de reuso mostra qual técnica é mais ideal:

Porém, vai depender de alguns fatores para determinar a técnica ideal, como
cronograma de desenvolvimento e tempo de vida previsto para o projeto.

3) Fatores para Reuso de Software

● Formação, habilidade e experiência da Equipe de Desenvolvimento
 ● Algumas certificações de softwares críticos pode inviabilizar o reuso de software
● Domínio da aplicação
● Plataforma de desenvolvimento

4) Frameworks de Aplicação
Framework é uma estrutura genérica que pode ser estendida para criar um
subsistema ou uma aplicação específica. Eles fornecem um esqueleto de arquitetura para a
aplicação e geralmente são flexíveis e configuráveis permitindo a adição de novos
componentes reusáveis.
Frameworks podem compor outros frameworks para formar um sistema, geralmente
isso acontece para implementação de parte isolada da aplicação. Os mais comuns são de
aplicativo web e em sua maioria segue o modelo MVC.

- Vantagens: permite reuso de diversos componentes e ainda permite uma

flexibilidade grande para customizar o software para as necessidades do cliente.
- Desvantagens: curva de aprendizagem é maior, eles podem ser complexos e podem
ficar obsoletos.
 REUSO DE SOFTWARE - PARTE 2

1) Linhas de Produto de Software

Muito útil para domínios específicos: sistemas logísticos, médicos, comerciais.
Servirá no caso de empresas que trabalham com produtos parecidos mas não idênticos, por
exemplo.
É possível a criação de um produto-base:
➔ produto genérico altamente customizável
➔ adaptável aos clientes ou dispositivos diferentes
➔ permite a implementação de novos componentes

- Componentes principais: não são modificáveis

- Componentes de aplicação configuráveis: podem ser modificados e não é
necessário alterar o código
- Componentes de aplicação especializados: específicos do domínio

2) Frameworks X Linhas de Produtos de Software

● Frameworks: têm código aberto, fornecem uma estrutura geral que pode ser
aplicada a qualquer problema e geralmente não incluem interação com hardware
● Linhas de Produto de Software: são geralmente proprietários e fechados, incorporam
informações de domínio e incluem interação com hardware.

3) Configuração de Linhas de Produtos de Software

Configuração em tempo de projeto => Empresa modifica o produto-base de uma linha de
produtos, seleciona, desenvolve e customiza os componentes, e por fim entrega para o
cliente

Configuração em tempo de implantação => Produto-base é entregue ao cliente, a

configuração é feita pelo próprio cliente e depois a adaptação é feita pela configuração do
produto-base.
 4) Sistema de Aplicação - Sistemas de Prateleira
Chamados de Sistemas Comerciais de Prateleira ou Software de Prateleira (COTS -
Commercial of the Shelf System). São softwares projetados para uso geral, sem pertencer a
um único cliente.Existem 2 tipos principais:
- Sistemas de Aplicação Configuráveis
Uma série de módulos para apoiar diferentes funções do negócio.
Modelo de processo de negócio associado a cada módulo
Utiliza banco de dados comum
Conjunto de regras de negócio comum a todo o banco

- Sistemas de Aplicação Integrados:

Incluem dois ou mais sistemas de aplicação
Sistemas podem ser compostos conectando a saída de um para a entrada de
outro ou compartilhando banco de dados
Sistemas também podem ser compostos por meio de APIs ou interfaces de
serviço

5) Reuso pela Abordagem Orientada à Serviços

Reuso de funcionalidades de sistemas de aplicação por meio de interfaces de serviço
padrão e destaca desafios como falta de controle sobre funcionalidade, perda de
desempenho e problema de interoperatividade.
 GARANTIA DA QUALIDADE DE SOFTWARE

1) Garantia e Controle da Qualidade

- Garantia da Qualidade:
Busca garantir se as cláusulas e padrões estão sendo atendidos e se o desenvolvimento de
software possui qualidade em todo processo.
- Controle de Qualidade
Busca garantir se os produtos estão sendo atendidos e se existe qualidade no produto
desenvolvido.

Algumas preocupações que envolvem na hora de garantir a qualidade de software:

● Padrões (os produtos precisam estar em conformidade com os padrões)

● Revisões e auditorias (objetivo de assegurar que as diretrizes de qualidade sejam

seguidas)

● Testes (usado para descobrir erros no código)

● Coletas e análise de erros (serve para melhor compreender como os erros são
introduzidos e qual atividade melhor se adequa para sua eliminação)

● Gerenciamento de mudanças (mudanças devem ser administradas apropriadamente

para não afetarem na qualidade)

● Educação (capacitar todos os envolvidos)

● Gerência dos fornecedores (escolha de bons fornecedores, assim teremos garantia

da qualidade)

● Administração da segurança (emprego de tecnologias apropriadas para ter

segurança de software)

● Proteção (proteção contra riscos de impacto de falhas)

● Administração de risco (estabelecer planos de contingência relacionados a riscos)

2) Tarefa de Garantia e Controle de Qualidade

É importante avaliar processos, produtos/serviços, gerenciar registros/relatórios de
qualidade, tratar incidentes e problemas.

3) Meta, Atributos e Métricas da Garantia da Qualidade

Existem diferentes metas e atributos de qualidade, como qualidade de requisitos, de projeto,
de código e eficácia do controle de qualidade.
 4) Confiabilidade de Software
É definido com a probabilidade de operação sem falhas de um programa de computador em
uma dado ambiente por um determinado tempo.

5) Plano de Garantia de Qualidade de Software (SQA)

É um roteiro para garantir a qualidade de software em um projeto. Deve conter:
● Propósito e escopo do plano
● Lista com todos os padrões e práticas que serão aplicadas
● Ações e tarefas da garantia de qualidade que serão executadas
● Lista de ferramentas que darão suporte às acções e tarefas da SQA
● O plano não pode ser o mesmo para todos os projetos
● Coletar informações sobre erros e defeitos
 REVISÃO E INTRODUÇÃO À TESE DE SOFTWARE

1) Revisão
Fazer uma revisão/análise de artefatos de software à procura de problemas. Tem como
objetivo melhorar a qualidade do software.

“Realizar revisões sistemáticas irá aumentar ou diminuir o tempo do projeto? E o esforço

será maior ou menor?”
As revisões sistemáticas podem inicialmente aumentar o tempo e o esforço devido à
sua implementação e à curva de aprendizado, elas tendem a proporcionar benefícios
significativos a longo prazo em termos de redução de defeitos, melhoria da qualidade e
eficiência do processo de desenvolvimento. É crucial avaliar o contexto e as necessidades
específicas do projeto para determinar se os benefícios superam os custos iniciais.

● Vantagens
- Diminui retrabalho
- Identificar vários defeitos de uma vez
- Treinamento da equipe
- Encontram defeitos que testes de unidade não encontram

● Desvantagens
- Algumas etapas tem custo maior de tempo e recurso
- Atividade a mais
- Não detecta todos os tipos de defeitos
- Dificuldade de medir o impacto

“Como realizar o processo de revisão?”

Existem os métodos formais e informais.
● Métodos Informais:
Não existe padronização ou documentação definida, sem agenda ou acompanhamento,
programação em pares, reuniões diárias/semanais/ao final da interação.
● Métodos Formais:
Planejamento do processo de revisão (pré-revisão), reunião com registros de comentários e
relatórios (revisão), acompanhamento dos problemas encontrados (pós-revisão). Existem as
revisões Gerenciais, Técnicas, Inspeção, Walkthrough e Auditoria.

2) Teste de Software
É o processo de executar um programa com o objetivo de encontrar erros. Tem
como objetivo demonstrar que o software atende aos requisitos e encontrar situações que o
software se comporta de modo incorreto.
Teste fazem parte das atividades V & V: Validação (Estamos construindo o software
certo?) e Verificação (Estamos construindo o software da maneira certa?)
Um conjunto bem definido de testes garante que o software irá funcionar
corretamente a maior parte do tempo, porém não estará livre de defeitos.
 TESTES AUTOMATIZADOS

1) Modelo do Processo de Teste de Software

● Caso de Teste: define as entradas para o teste e os resultados esperados

● Dados de Teste: são a entrada para o teste e podem ser definidos manualmente ou
automaticamente.

● Execução dos Testes: normalmente é otimizada e utiliza os dados de testes e obtém

o resultado.

● Comparação Resultado do Teste e Resultado Esperado: gera relatórios de testes

mostrando possíveis defeitos.

2) Tipos de Testes
Teste Caixa-Preta: - não se sabe nada a respeito da lógica sendo testada
- utiliza especificação de um sistema para realizar o teste
- FUNCIONAL

Teste Caixa-Branca: - lógica conhecida

- código pode ser examinado para definição dos casos de testes
- testes buscam exceções, loops e particularidades
- ESTRUTURAL

3) Estágios de Teste de Software

Um software passa por 3 estágios de teste:
● Teste de Desenvolvimento: são todas as atividades de testes executadas
pela equipe de desenvolvimento durante a codificação.

● Teste de Entregas (releases): são realizados antes de cada lançamento de

nova versão completa do sistema.

● Teste de Usuários: são realizados no ambiente do usuário, chamados

também de testes de aceitação

4) Teste Unitário ou Teste de Unidade

 Teste unitário é testar a unidade funcional de um software (método ou classe). Caso
teste as classes é recomendado testar os diferentes estados que um objeto pode ficar,
simular mudança de estado, testar métodos e validar atributos.
Teste automatizado tem três partes:
I) Configuração: parte de definição das entradas e saídas esperadas
II) Chamada: parte em que objeto ou método é testado
III) Asserção: comparar resultado obtido com o resultado esperado, se for
falso o teste falhou
 DUBLÊS E TESTE DE CAMINHOS

1) Escolhendo os Casos de Testes Unitários

Algumas estratégias comuns na definição dos casos de testes para encontrar defeitos:
- Teste de Partição: Identificação do grupo de entrada com características comuns
Escolher 1 exemplo de cada grupo para testar

- Teste Baseado em Diretriz: Representa a experiência prévia dos programadores

Testes dirigidos baseados em experiência prévia

2) Teste de Caminhos - Teste estrutural

Verificar os possíveis caminhos no código para planejamento do teste, podem existir
inúmeros caminhos.
Com o critério de fazer teste baseado em fluxos de controle e arestas são os pontos
de fluxo de controle
Caminhos possíveis: - Caso I: 1, 2, 4 6 7
- Caso II: 1, 2, 4, 5, 8
- Caso III: 1, 3, 9
Valores de entrada:
- Caso I:
valorCompra: <50
qtdItens: <=3

- Caso II:
valorCompra: <50
qtdItens: >3

- Caso III:
valorCompra: >=50
qtdItens: -

3) Isolamento em Teste Unitário

No teste unitário é interessante isolar a classe para testar exatamente o método de
interesse. Podem usar dublês, são objetos que vão fingir atuar como os verdadeiros com
um resultado já pré-definido.