Unidade 2 Construção de Sistemas com Qualidade

Prévia do material em texto

Conteudista: Prof. Me. Artur Marques
Revisão Textual: Prof.ª Dra. Luciene Oliveira da Costa Granadeiro
Material Teórico
Material Complementar
Referências
Construção de Sistemas com Qualidade
Antes de iniciar um projeto de software, é essencial determinar as tarefas a serem executadas e
gerenciar adequadamente a alocação de tarefas entre os indivíduos envolvidos no
desenvolvimento do software. Portanto, o planejamento é importante, pois resulta em um
desenvolvimento de software e�caz.
Ao iniciar qualquer projeto de desenvolvimento de novos sistemas, é importante de�nir o
escopo do projeto e planejar como ele será desenvolvido, testado e mantido. Isso geralmente é
chamado de ciclo de vida de desenvolvimento de sistemas.
Embora existam variações de qual modelo seguir em um projeto de desenvolvimento, em
cascata, espiral, incremental, uni�cado, ágil ou lean, todos exigem muita re�exão e
investimento em planejamento.
Essa é a fase mais importante de qualquer projeto de desenvolvimento de software. Durante
esse estágio, você decidirá e avaliará exatamente o que deseja fazer e se um novo sistema é
1 / 3
Material Teórico
 Objetivo da Unidade:
Manter construções de software consistentes.
necessário como resultado ou se melhorias podem ser feitas caso esteja trabalhando em um
sistema existente. O que a maioria dos pro�ssionais entrantes na área não reconhece é que
essa é sempre uma fase longa, que requer muita análise e avaliação, além disso,
compartilhamento e tomada de decisão de forma coletiva.
Uma quantidade signi�cativa de tempo será gasta considerando o que o usuário �nal deseja
alcançar, quem usará o sistema, o que precisa ser inserido para obter a saída necessária e
entre outras coisas.
Todos os requisitos devem ser cuidadosamente documentados, incluindo as expectativas do
usuário �nal para garantir que todos os que trabalham no projeto tenham uma visão clara do
que desejam que o produto acabado faça. Isso é verdadeiro inclusive para projetos sob
qualquer framework ágil. Portanto, não siga a falácia da não necessidade de documentação
porque o desenvolvimento é ágil.
Pense da seguinte forma: quaisquer discrepâncias que não sejam explicadas ou de�nidas
nesse estágio podem ter repercussões em qualquer outro estágio posterior e podem adicionar
custos imprevistos que podem ameaçar qualquer projeto de desenvolvimento e, claro, ameaçar
o seu emprego, a�nal qual stakeholder – parte interessada – gosta de desperdiçar recursos e
dinheiro?
Uma estimativa sobre recursos internos e externos necessários e custos totais do projeto deve
ser fornecida para garantir que a melhor solução tenha sido escolhida. Portanto, de�na
claramente os objetivos para o projeto, estabeleça quais recursos e orçamento estão
disponíveis de forma honesta para todos, principalmente para sua equipe e, por �m, avalie
sempre soluções alternativas para garantir que a melhor proposta seja feita. Isso quer dizer
que você deverá ter o plano A, mas também o B, C, D etc.
Vamos falar um pouco disso agora.
Projeto e Manutenção de Software
É óbvio que, ao falar sobre design de software, surge uma pergunta: o que é esse design de
software a�nal? 
O design de software é basicamente um mecanismo de preparação de um plano, um layout para
estruturar o código de seu aplicativo de software. 
É algo simples de de�nir e difícil de executar com certeza!
O design de software é um conceito de vários estágios. O software em si é em si, algo
multicamadas e multidimensional e, portanto, seu design tem várias etapas intermediárias em
seus diferentes níveis.
Então, em linhas gerais, de que níveis nos referimos quando falamos de design de software?
Projeto de arquitetura: é a primeira etapa do projeto em nível de software. Trata-se da
construção de uma estrutura de software aplicativo para que haja a correta interconexão de
cada elemento do código de acordo com a função exigida. Portanto, usamos muito UML, qual
padrão de arquitetura se GoF, MVC, DAO, Camadas ou Cliente Servidor, também qual
framework, qual a linguagem, entre outros.
Projeto de alto nível: é a segunda etapa no projeto. Nessa etapa, o designer divide os conceitos
teóricos em várias entidades e garante que suas funções estejam inter-relacionadas para obter
um resultado ideal. Esse módulo identi�ca uma estrutura modular de diferentes entidades e
cria um design para interconectar todos os módulos para uma saída especí�ca. Usamos
diagramas de pacotes, interfaces em diagramas de classes, tipos de repositórios para
aproveitarmos reúso de módulos e funcionalidades por exemplo.
Projeto detalhado: é a terceira e última etapa. Envolve a compilação de todas as saídas
modulares e a disposição ou reorganização dos módulos funcionais para o resultado. Esse
nível de design de software determina mais de uma estrutura lógica de módulos construídos. A
parte de realização do resultado do software é o motivo do nível de design detalhado do
software. Aqui entram a escolha de componentes, diagrama de classes de persistência,
diagramas expandidos de caso de uso, diagramas de sequência e outros comportamentais. Por
�m, codi�ca-se, testa-se, corrige-se e integra-se até o término. 
Sabemos que, no desenvolvimento atual de software, sempre existe algum software para
reutilizar. Os componentes reutilizáveis são elementos que podem fornecer funcionalidade
especí�ca para o sistema que será produzido. Essa abordagem orientada para a reutilização se
baseia em uma grande base de componentes de software reutilizáveis e em alguma estrutura
de integração para esses componentes. 
As etapas do processo de software baseado em componentes são:
Análise de componentes: com base na especi�cação de requisitos, é feita uma busca por
componentes que possam implementar a especi�cação dada. Normalmente, não há
correspondência exata e os componentes que podem ser usados fornecem apenas algumas
das funcionalidades necessárias.
Modi�cação de requisitos: os requisitos são analisados a partir de informações sobre os novos
componentes. Os requisitos são então modi�cados para re�etir os serviços dos componentes
disponíveis.
Projeto de sistema com reutilização: a estrutura do sistema é projetada ou uma estrutura
existente é reutilizada. Os projetistas levam em consideração os componentes que são
reutilizados. Algum novo software pode ter que ser projetado se componentes reutilizáveis não
estiverem disponíveis.
Desenvolvimento e integração: o software que não pode ser adquirido externamente é
desenvolvido e os componentes e sistemas reutilizáveis são integrados para criar o sistema.
A engenharia de software baseada em componentes tem a vantagem óbvia de reduzir a
quantidade de software a ser desenvolvido e, assim, reduzir custos e riscos. Geralmente,
também leva a uma entrega mais rápida do software. No entanto, o comprometimento de
requisitos é inevitável e isso pode levar a um sistema que não atenda às necessidades reais dos
usuários.
Geralmente, as alterações são inevitáveis em todos os grandes projetos de software. Os
requisitos do sistema mudam à medida que a organização responde continuamente às
mudanças no ambiente e nas condições. 
As prioridades de gerenciamento podem mudar. Devido ao rápido progresso nas tecnologias,
os projetos e a implementação serão alterados. Isso signi�ca que as atividades do processo
são repetidas regularmente à medida que o sistema é retrabalhado em resposta aos requisitos
de mudança.
Os processos convencionais de desenvolvimento de software que são baseados na
especi�cação completa dos requisitos e, em seguida, projetar, construir e testar o sistema não
são aplicáveis ao desenvolvimento rápido de software. 
Conforme os requisitos mudam, o design ou implementação do sistema deve ser retrabalhado
e testado novamente. Como consequência, o processo de desenvolvimento costuma atrasar e
o software �nal é entregue ao cliente muito depois de ter sido originalmente especi�cado. Em
alguns casos, o motivo originalpara o desenvolvimento de software pode ter mudado tão
radicalmente que o software se torna efetivamente inútil quando é entregue. Portanto, os
processos de desenvolvimento, especialmente no caso de sistemas de negócios, devem se
concentrar no rápido desenvolvimento e entrega de software.
Veri�cação, Validação e Testes
O processo de teste geral começa com o teste de unidade de programa individuais, como
funções ou objetos. O objetivo do teste de componente é descobrir defeitos testando
componentes individuais do programa. 
Os componentes são geralmente integrados para formar subsistemas e, �nalmente, para o
sistema completo. O teste do sistema se concentra em estabelecer se o subsistema ou o
sistema completo atende aos seus requisitos funcionais e não funcionais e não se comporta
de maneiras inesperadas. O teste de componentes por desenvolvedores é baseado na
compreensão de como os componentes devem operar usando dados de teste. No entanto, o
teste de sistema é rigorosamente baseado em especi�cações de sistema escritas.
O processo de teste de software tem os seguintes objetivos principais:
Demonstrar que o software atende aos seus requisitos. Isso signi�ca que deve haver pelo
menos um teste para cada usuário e requisitos de sistema;
Descobrir falhas ou defeitos no software. O objetivo do teste de defeitos é a exploração e
eliminação de todos os tipos de comportamento indesejável do sistema, como
travamentos do sistema, interações indesejadas com outros sistemas, cálculos incorretos
e corrupção de dados.
O primeiro objetivo é chamado de teste de validação. Nesse caso, o sistema é testado por um
determinado conjunto de casos de teste que re�etem o uso esperado do sistema. Para o teste
de validação, um teste é considerado bem-sucedido se o sistema funcionar corretamente. 
O segundo objetivo leva ao teste de defeitos, no qual os casos de teste são projetados para
expor defeitos. Nesse caso, um teste bem-sucedido é aquele que expõe um defeito que faz com
que o sistema funcione incorretamente. Os casos de teste são especi�cações das entradas
para o teste, a saída esperada do sistema e uma declaração do que está sendo testado. Os
dados de teste são as entradas criadas para testar o sistema. O teste é baseado em um
subconjunto de casos de teste possíveis.   
Figura 1 – Modelo geral do processo de teste 
Vamos falar dos tipos de teste importantes.
Teste Unitário: é uma forma de testar a menor parte do código que pode ser isolada
logicamente em um sistema. Na maioria das linguagens de programação, isso é uma função,
uma sub-rotina, um método ou propriedade. Versões modernas de teste de unidade podem
ser encontradas em estruturas como JUnit ou ferramentas de teste como TestComplete,
lembre-se, automatize seus testes, pois, atualmente, é impossível fazer testes manuais com o
grau e complexidade que o software atingiu. Há, não se esqueça, o teste de unidade é feito
durante o desenvolvimento, ou seja, fase de codi�cação, de um aplicativo pelos
desenvolvedores. Ele garante que todo o código atenda aos padrões de qualidade antes de ser
implantado. Isso garante um ambiente de engenharia con�ável onde a qualidade é
fundamental. Ao longo do ciclo de vida de desenvolvimento do produto, o teste de unidade
economiza tempo e dinheiro e ajuda os desenvolvedores a escrever um código melhor e com
mais e�ciência.
Teste de Interface: em um sistema de software, muitos componentes não são funções ou
objetos simples, mas são componentes compostos que consistem em vários objetos em
interação. A funcionalidade desses componentes pode ser acessada por meio de sua interface
de�nida. O teste desses componentes compostos preocupa-se principalmente com o teste da
interface do componente composto criado pela combinação desses componentes. O teste de
interface é importante para o desenvolvimento orientado a objetos e baseado em
componentes. Objetos e componentes são de�nidos por suas interfaces e podem ser
reutilizados em combinação com outros componentes em diferentes sistemas.
Teste de Integração: Fowler (2018), um dos signatários do manifesto ágil, coloca esse tipo de
teste como os que determinam se as unidades de software desenvolvidas de forma
independente funcionam corretamente quando estão conectadas umas às outras. Muitas
pessoas presumem que os testes de integração são necessariamente amplos em escopo,
embora possam ser realizados de forma mais e�caz com um escopo mais restrito.
“Como costuma acontecer com essas coisas, é melhor começar com um pouco de história.
Quando aprendi sobre testes de integração, foi na década de 1980 e a cachoeira foi a in�uência
dominante do pensamento de desenvolvimento de software. Em um projeto maior, teríamos
uma fase de design que especi�caria a interface e o comportamento dos vários módulos do
sistema. Os módulos seriam então atribuídos aos desenvolvedores para programar. Não era
incomum para um programador ser responsável por um único módulo, mas isso seria grande
o su�ciente para levar meses para construí-lo. Todo esse trabalho foi feito isoladamente e,
quando o programador acreditasse que estava concluído, ele o entregaria ao controle de
qualidade para teste.
A primeira parte do teste seria o teste de unidade, que testaria aquele módulo por conta
própria, em relação à especi�cação que havia sido feita na fase de design. Depois de concluído,
passamos para o teste de integração, onde os vários módulos são combinados em todo o
sistema ou em subsistemas signi�cativos.
O objetivo do teste de integração, como o nome sugere, é testar se muitos módulos
desenvolvidos separadamente funcionam juntos conforme o esperado. Ele foi executado
ativando vários módulos e executando testes de nível superior em todos eles para garantir que
funcionassem juntos. Esses módulos podem ser partes de um único executável ou separados. 
O problema é que temos (pelo menos) duas noções diferentes do que constitui um teste de
integração.
Testes de integração estreitos: exercer apenas a parte do código em meu serviço que se
comunica com um serviço separado usa duplas de teste desses serviços, em processo ou
remotos, portanto, consistem em muitos testes de escopo restrito, muitas vezes não maiores
em escopo do que um teste de unidade (e geralmente executados com a mesma estrutura de
teste que é usada para testes de unidade)
Testes de integração amplos: exigem versões ao vivo de todos os serviços, exigindo um
ambiente de teste substancial e acesso à rede exercitar caminhos de código em todos os
serviços, não apenas no código responsável pelas interações. E há uma grande população de
desenvolvedores de software para os quais “teste de integração” signi�ca apenas “testes de
Teste Funcional: bem, começamos determinando qual é o comportamento aceitável para
“funcional” e o que não é. Portanto, isso está feito na própria especi�cação funcional ou nos
requisitos. Ali, veja bem, deveria estar escrito o que o usuário ou ator do sistema tem
“permissão” para fazer, assim podemos falar se algo está ou não em conformidade. Quais
cenários as premissas são verdadeiras, quais são falsas?
Podemos realizar testes de funcionalidade por dois meios:
Teste com base em requisitos: contém todas as especi�cações funcionais que formam a
base para todos os testes a serem realizados;
Teste com base em cenários de negócios: contém as informações sobre como o sistema
será percebido a partir de uma perspectiva de processos de negócios.
Teste e garantia de qualidade são uma grande parte do processo ciclo de vida do
desenvolvimento de software. Precisamos estar cientes de todos os tipos de teste, mesmo que
não estejamos diretamente envolvidos com eles diariamente.
Mas vamos entender que, quando falamos de teste de funcionalidade ou de funcionamento:
Teste de regressão: também faz parte da família de teste funcionais, é realizado para garantir
que a adição de novo código, melhorias, correção de bugs não está quebrando a
funcionalidade existente ou causandoqualquer instabilidade e ainda funciona de acordo com
- FOWLER, 2018, p. 2
integração amplos”, o que causa muita confusão quando se depara com pessoas que usam a
abordagem restrita.
Se seus únicos testes de integração forem amplos, você deve considerar explorar o estilo
restrito, pois é provável que melhore signi�cativamente a velocidade do teste, a facilidade de
uso e a resiliência. Como os testes de integração estreitos são limitados em escopo, eles
geralmente são executados muito rapidamente.”
as especi�cações. Os testes de regressão não precisam ser tão extensos quanto os testes
funcionais reais, mas devem garantir apenas a quantidade de cobertura para certi�car que a
funcionalidade é estável.
Teste de usabilidade: também é conhecido como o famoso Beta Teste ou teste de versão Beta
onde o produto é exposto ao cliente real em uma produção como um ambiente e eles testam o
produto. O conforto do usuário é derivado disso e o feedback é obtido. Isso é semelhante ao
teste de aceitação do usuário.
Portanto, quando criamos testes, pensamos nos mais diversos tipos de cenários, porém,
devemos entender que realizar todos os tipos de teste possíveis não vai garantir que o sistema
não tenha erros, mas podemos garantir que vai sair caro o su�ciente para assustar até o mais
experiente gerente de projeto ou agilista. Portanto, é imponderável realizar isso, mas é
importante para você saber qual é o esqueleto ou estrutura de um caso de teste:
Resumo do teste;
Pré-requisitos;
Etapas de teste;
Resultados esperados.
Re�ita 
A esta altura, você deve perguntar: “mas como é um caso de teste
funcional?”. Aqui você encontrará uma leitura bastante interessante.
Caso não consiga ler em inglês, poderá utilizar o Google Translator para
ler. Trata-se de leitura fácil e rápida. É importante você ler.
Selenium: popular ferramenta de teste funcional de código aberto – disponível em:
GURU99. Como escrever casos de teste: modelo de amostra com
exemplos. 2020. Disponível em: 
How to Write Test Cases: Sample Template with
Examples
A TEST CASE is a set of actions executed to verify a particular feature or functionality
of your software application. A Test Case contains test steps, test data, precondition,
postcondition developed for speci�c test scenario to verify any requirement.
LEIA MAIS GURU99 
Saiba Mais 
Aqui, temos algumas ferramentas para testes:
https://www.guru99.com/test-case.html
https://www.guru99.com/test-case.html
https://www.guru99.com/test-case.html
QTP: ferramenta de teste funcional muito amigável da HP – disponível em:
SELENIUM
Downloads
The Internet Explorer Driver Server This is required if you want to make use
of the latest and greatest features of the WebDriver InternetExplorerDriver.
Please make sure that this is available on your %PATH% in order for the IE
Driver to work as expected.
LEIA MAIS SELENIUM 
AUTOMATIONREPOSITORY
Download QTP Latest Version (v12.53) from HP -
XX - XX
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares × Quick
Test Professional 12.53 can be downloaded from HP website. The trial version
of QTP is available as "UFT 12.53". The trail period for the software is 30 days.
1. Open this link.
https://www.selenium.dev/
https://www.selenium.dev/downloads/
https://www.selenium.dev/downloads/
http://www.automationrepository.com/
http://www.automationrepository.com/2011/08/download-qtp-11-trial-version-from-hp/
http://www.automationrepository.com/2011/08/download-qtp-11-trial-version-from-hp/
JUnit: usado principalmente para aplicativos Java e pode ser usado em testes de unidade e
sistema – disponível em:
soapUI: esta é uma ferramenta de teste funcional de código aberto, usada principalmente
para teste de serviço da web. Ele oferece suporte a vários protocolos, como HTTP, SOAP e
JDBC – disponível em: 
LEIA MAIS AUTOMATIONREPOSITORY 
SOURCEFORGE
JUnit
Download JUnit for free. We are deprecating our SourceForge installation. For
the latest information, downloads, and opportunities to contribute, please
visit http://junit.org.
LEIA MAIS SOURCEFORGE 
SOAPUI
Download REST & SOAP Automated API Testing
Tool | Open Source | SoapUI
Get the most advanced functional testing tool for REST, SOAP and GraphQL
APIs.
http://www.automationrepository.com/2011/08/download-qtp-11-trial-version-from-hp/
https://sourceforge.net/
https://sourceforge.net/projects/junit/
https://sourceforge.net/projects/junit/
https://sourceforge.net/projects/junit/
https://www.soapui.org/
https://www.soapui.org/downloads/soapui/
Watir: esta é uma ferramenta de teste funcional para aplicativos da web. Ele suporta
testes executados no navegador da web e usa uma linguagem de script Ruby – disponível
em: 
Garantia da Qualidade, Medição e Melhoria
Antes de iniciar um projeto de software, é essencial determinar as tarefas a serem executadas e
gerenciar adequadamente a alocação de tarefas entre os indivíduos envolvidos no
desenvolvimento do software. Portanto, o planejamento é importante, pois resulta em um
desenvolvimento de software e�caz.
LEIA MAIS SOAPUI 
WATIR
Watir Project
Watir 7.0.0.beta3 is now available on RubyGems. This update includes bug
�xes and things that were intended for the last release for Capabilities but
overlooked. Continue Reading... Watir 7.0.0.beta2 is now available on
RubyGems. This is all the additions and optimizations that were dependent on
removing the deprecated code in Beta 1.
LEIA MAIS WATIR 
https://www.soapui.org/downloads/soapui/
http://watir.com/
http://watir.com/
http://watir.com/
Para um planejamento de projeto e�caz, alguns princípios são seguidos:
O planejamento é necessário: o planejamento deve ser feito antes do início do projeto.
Para um planejamento e�caz, os objetivos e cronogramas devem ser claros e
compreensíveis;
Análise de risco: antes de iniciar o projeto, a alta administração e a equipe de
gerenciamento do projeto devem considerar os riscos que podem afetar o projeto. Por
exemplo, o usuário pode desejar mudanças nos requisitos enquanto o projeto está em
andamento. Nesse caso, a estimativa de tempo e custo deve ser feita de acordo com esses
requisitos (novos requisitos);
Acompanhamento do plano do projeto: uma vez que o plano do projeto é preparado, ele
deve ser rastreado e modi�cado de acordo;
Atender aos padrões de qualidade e produzir resultados de qualidade: o plano do projeto
deve identi�car os processos pelos quais a equipe de gerenciamento do projeto pode
garantir a qualidade do software. Com base no processo selecionado para garantir a
qualidade, estima-se o tempo e o custo do projeto;
Descrição da �exibilidade para acomodar mudanças: o resultado do planejamento do
projeto é registrado na forma de um plano do projeto, que deve permitir que novas
mudanças sejam acomodadas quando o projeto estiver em andamento.
Vamos descrever com maiores minúcias os  dois últimos, postos em evidência.
Quanto ao plano de garantia da qualidade, Thakur (2018) descreve a necessidade descritiva
dos métodos e estratégias que deverão ser seguidas para atingir os objetivos como manter “as
coisas” do projeto de software organizadas, garantir as entregas com o padrão de qualidade
padrão da empresa antes de serem entregues ao usuário. 
Isso envolve também os processos de veri�cação e validação cujos componentes de teste em
veri�cação foram expostos no subtítulo anterior e que envolvem:
Plano e procedimentos de teste do sistema: fornece informações sobre a estratégia de teste do
sistema, integração do banco de dados e integração do sistema da plataforma. Fornece uma
visão geral dos componentes necessários para a integração do banco de dados e garante que o
aplicativo seja executado em pelo menos duas plataformas especí�cas. O procedimento de
integração do banco de dados descreve como o banco de dados é conectado à Interface
Grá�ca do Usuário. O procedimento de integração do sistema de plataforma é executado em
diferentes sistemas operacionais para testar a validade da plataforma.Teste de aceitação e preparação para entrega: descreve como o teste de aceitação deve ser
executado no software para veri�car sua usabilidade, conforme necessário. Os critérios de
aceitação descrevem que o software será aceito apenas se todos os componentes, recursos e
funções forem testados, incluindo o teste de integração do sistema. Além disso, os critérios de
aceitação veri�cam se o software atende às expectativas do usuário. O procedimento de
instalação descreve as etapas de instalação do software de acordo com o sistema operacional
usado e as especi�cações mínimas de hardware necessárias.
Plano de Gerenciamento de Con�guração: de�ne o processo, que é usado para fazer mudanças
no escopo do projeto. Geralmente, o plano de gerenciamento da con�guração se preocupa
com a rede�nição dos objetivos existentes do projeto e das entregas que nada mais são que os
produtos de software que são entregues ao usuário/cliente após a conclusão do
desenvolvimento.
Quando falamos em modelos de qualidade de software, precisamos obrigatoriamente falar da
ISO – International Organization for Standardization, ou Organização Internacional para
Padronização.
O padrão ISO 9126 descreve um modelo de qualidade de software que a categoriza a em 6
características que são subdivididas em sub características. As características se manifestam
externamente quando o software é usado como consequência dos atributos internos
do software. Os atributos internos do software são medidos por meio de métricas internas, por
exemplo, monitoramento do desenvolvimento do software antes da entrega.
As características de qualidade são medidas externamente por meio de métricas externas.
Vejamos como são as subdivisões conforme a ISO para qualidade de software.
Quadro 1 – Itens do padrão ISO de qualidade de software
Funcionalidade
Aptidão;
Precisão;
Interoperabilidade;
Segurança;
Conformidade.
Con�abilidade 
Maturidade;
Tolerância ao erro;
Recuperabilidade;
Conformidade.
Usabilidade 
Compreensibilidade;
Aprendizagem;
Operabilidade;
Atratividade;
Conformidade.
Reutilização 
Compreensibilidade para
Reutilização;
Aprendizagem para
reutilização;
Operabilidade para
Reutilização –
Programação;
Atratividade para
Reutilização;
Conformidade para
Reutilização.
E�ciência 
Comportamento de
tempo;
Utilização de recursos;
Conformidade.
Capacidade de
Manutenção 
Analisabilidade;
Mutabilidade;
Estabilidade;
Testabilidade;
Conformidade.
Portabilidade 
Adaptabilidade;
Instalabilidade;
Coexistência;
Substitutibilidade;
Conformidade.
Fonte: Adaptado de RUGGIERI
Nos escritos de Anjos e Moura (2020), os aspectos técnicos para avaliação da qualidade do
produto de software estão alicerçados em três Normas:
ISO/IEC 9126: Características de Qualidade de Software como NBR-13596;
ISO/IEC 14598: Guias para Avaliação de Produto de Software como ISO-14598;
ISO/IEC 12119: Requisitos de Qualidade e Testes de Pacotes de Software como NBR-12119.
Especi�camente, a ISO 9126 possuI um conjunto de medidas e é apresentada em 4
documentos:
ISO/IEC 9126-1:2001 – Part 1: Modelo de Qualidade;
ISO/IEC TR 9126-2:2003 – Part 2: Métricas externas;
ISO/IEC TR 9126-3:2003 – Part 3: Métricas Internas.
ISO/IEC FDTR 9126-4:2004 – Part 4: Métricas de qualidade em uso
Leitura 
Nosso intuito, é que você conheça como elas são e como aplicá-las, é
um texto curto, mas de grande relevância, por isso é importante que
você leia como parte desTa unidade a seguinte leitura: 
ANJOS, L. A. M.; MOURA, H. P. Um Modelo para Avaliação de Produtos
de Software. 2020. Disponível em:
DOCPLAYER
https://docplayer.com.br/
Mas como garantir a qualidade?
A garantia de qualidade de software – SQA: Software Quality Assurance é um processo que
garante que todos os processos, métodos, atividades e itens de trabalho da engenharia de
software sejam monitorados e cumpram os padrões de�nidos.
O SQA incorpora todos os processos de desenvolvimento de software, desde a de�nição dos
requisitos até a codi�cação até o lançamento. Seu principal objetivo é garantir a qualidade.
Planejamento é tudo, por isso precisamos do plano de garantia de qualidade de software,
exatamente porque ele compreende os procedimentos, técnicas e ferramentas que são
empregadas para garantir que um produto ou serviço esteja alinhado com os requisitos
de�nidos na especi�cação de requisito de software. Ele identi�ca as responsabilidades da
equipe responsável pelo SQA, lista as áreas que precisam ser revisadas e auditadas, também
identi�ca os produtos de trabalho da qualidade.
Um Modelo para Avaliação de Produtos de
Software - PDF Download grátis
1 Um Modelo para Avaliação de Produtos de Software Lúcio André Mendonça
dos Anjos, Hermano Perrelli de Moura Centro de Informática - Universidade
Federal de Pernambuco (UFPE) Caixa Postal Recife PE Brazil Abstract. This
paper proposes a new evaluation model for software products, based on ISO
standards, standard software products evaluation process and usual
evaluation model of the market of software.
LEIA MAIS DOCPLAYER 
https://docplayer.com.br/2862875-Um-modelo-para-avaliacao-de-produtos-de-software.html
https://docplayer.com.br/2862875-Um-modelo-para-avaliacao-de-produtos-de-software.html
https://docplayer.com.br/2862875-Um-modelo-para-avaliacao-de-produtos-de-software.html
 O documento do SQA consiste nos seguintes itens:
Seção de propósito;
Seção de referência;
Seção de gerenciamento de con�guração de software;
Relatório de problemas e seção de ação corretiva;
Seção de ferramentas, tecnologias e metodologias;
Seção de controle de código;
Registros: seção de coleta, manutenção e retenção;
Metodologia de teste.
 Como podemos garantir a qualidade usando o SQA? Numa sequência de etapas:
“Criação de um Plano de Gerenciamento SQA: A atividade principal inclui estabelecer um plano
adequado sobre como o SQA será executado em seu projeto. Junto com a abordagem de SQA
que você vai seguir, quais atividades de engenharia serão realizadas, e inclui a garantia de que
você tenha uma combinação certa de talentos em sua equipe.
De�nir os pontos de veri�cação: A equipe SQA estabelece diferentes pontos de veri�cação de
acordo com os quais avalia a qualidade das atividades do projeto em cada ponto de
veri�cação/estágio do projeto. Isso garante inspeção de qualidade regular e funcionamento de
acordo com o cronograma.
Aplicar técnicas de engenharia de software: A aplicação de algumas técnicas de engenharia de
software ajuda um designer de software a obter especi�cações de alta qualidade. Para coletar
informações, um designer pode usar técnicas como entrevistas e FAST (Functional Analysis
System Technique). Posteriormente, com base nas informações coletadas, o designer de
software pode preparar a estimativa do projeto usando técnicas como WBS (estrutura analítica
do projeto), SLOC (linha de código de origem) e estimativa de FP (pontos de função).
Execução de revisões técnicas formais: Uma RTF é feito para avaliar a qualidade e o design do
protótipo. Nesse processo, é realizada uma reunião com a equipe técnica para discutir os reais
requisitos de qualidade do software e a qualidade do projeto do protótipo. Essa atividade ajuda
a detectar erros na fase inicial do SDLC e reduz o esforço de retrabalho nas fases posteriores.
Ter uma estratégia de multitestes: Por estratégia de multitestes, queremos dizer que não se
deve con�ar em nenhuma abordagem de teste única; em vez disso, vários tipos de teste
devem ser realizados para que o produto de software possa ser bem testado de todos os
ângulos para garantir melhor qualidade.
Reforçando a adesão ao processo: Esta atividade insiste na necessidade de aderência ao
processo durante o processo de desenvolvimento de software. O processo de desenvolvimento
também deve seguir os procedimentos de�nidos. Esta atividade é uma mistura de duas
subatividades que são explicadas em detalhes a seguir:
Avaliação do Produto: Esta atividade con�rma que o produto desoftware está
atendendo aos requisitos descobertos no plano de gerenciamento do projeto. Ele
garante que os padrões de�nidos para o projeto sejam seguidos corretamente;
Monitoramento de Processo: Esta atividade veri�ca se as etapas corretas foram
realizadas durante o desenvolvimento do software. Isso é feito comparando as
etapas realmente executadas com as etapas documentadas.
Mudança de controle: Nesta atividade, usamos uma combinação de procedimentos manuais e
ferramentas automatizadas para ter um mecanismo de controle de alterações. Ao validar as
solicitações de mudança, avaliando a natureza da mudança e controlando o efeito da mudança,
é garantido que a qualidade do software seja mantida durante as fases de desenvolvimento e
manutenção.
Medir o impacto da mudança: Se qualquer defeito for relatado pela equipe de SQA, a equipe em
questão corrigirá o defeito. Depois disso, a equipe de SQA deve determinar o impacto da
mudança trazida por essa correção de defeito. Eles precisam testar não apenas se a mudança
corrigiu o defeito, mas também se a mudança é compatível com todo o projeto. Para isso,
utilizamos métricas de qualidade de software que permitem aos gerentes e desenvolvedores
observar as atividades e mudanças propostas desde o início até o �nal do SDLC e iniciar ações
corretivas sempre que necessário.
Para que a SQA seja realizada, levamos em consideração 10 elementos, a saber: 
Padrões de engenharia de software;
Revisões técnicas e auditorias;
Teste de software para controle de qualidade;
Coleta e análise de erros;
Mudar a gestão;
Programas educacionais;
Gestão de fornecedores;
Gerenciamento de segurança;
Segurança;
Gerenciamento de riscos.
- STH, 2021, p. 6-7
Realização de auditorias SQA: A auditoria SQA inspeciona todo o processo SDLC real seguido
por compará-lo com o processo estabelecido. Também veri�ca se o que foi relatado pela
equipe nos relatórios de status foi realmente executado ou não. Esta atividade também expõe
quaisquer problemas de não conformidade.
Manutenção de registros e relatórios: É crucial manter a documentação necessária relacionada
ao SQA e compartilhar as informações necessárias do SQA com as partes interessadas. Os
resultados dos testes, resultados da auditoria, relatórios de revisão, documentação de
solicitações de mudança etc. devem ser mantidos para referência futura.
Gerenciar boas relações: Na verdade, é muito importante manter a harmonia entre o controle
de qualidade e a equipe de desenvolvimento. Frequentemente ouvimos que testadores e
desenvolvedores geralmente se sentem superiores uns aos outros. Isso deve ser evitado, pois
pode afetar a qualidade geral do projeto.”
 Além de todos os tipos de teste e auditorias, temos a �gura de garantia da qualidade chamada
inspeção de projeto de software e ela leva em consideração:
Requisitos gerais e design;
Especi�cações funcionais e de interface;
Convenções;
Rastreabilidade de requisitos;
Estruturas e interfaces;
Lógica;
Desempenho;
Tratamento e recuperação de erros;
Testabilidade, extensibilidade;
Acoplamento e coesão.
 É aqui que voltamos ao nosso ponto de páginas anteriores de nossa disciplina onde foi
escrito que há necessidade cada vez maior de documentação de software, essencial e
necessária.
Porque:
Os softwares estão cada vez mais complexos;
Os softwares não são feitos por uma só pessoa, mas diversas pessoas;
Os softwares não são mais desenvolvidos somente em seu país de origem, mas em
fábricas de software em locais muito distantes, muitas vezes, em outros continentes.
Como há múltiplas pessoas de locais e países diferentes falando idiomas diferentes, é
óbvio que devemos usar e dominar, por exemplo, a linguagem universal de especi�cação
e nesse caso é a UML.
Entende como a falácia da não necessidade de documentação, principalmente em métodos
ágeis, leva uma empresa ou um projeto de software à ruína ou então caso o software entre em
produção à perda de histórico e consequentemente a memória?
Essa é a importância da documentação!
Já imaginou você recebendo uma visita de seu cliente e ele pede os itens da listagem de 10
itens acima e você talvez, por sorte, tenha uma ou outra? Pois bem, você acabou de colocar o
contrato em risco.
Se você trabalha para uma organização que produz software, a qualidade do software que você
produz pode determinar algumas coisas importantes:
A receita da empresa para a qual você trabalha;
A prioridade do projeto ou produto no qual você está trabalhando dentro da organização;
A probabilidade de você ser promovido a um cargo sênior, rebaixado ou até demitido;
Seu salário.
Por �m, eis alguns exemplos atributos e métricas para qualidade e de que forma você pode
medi-la em um projeto de software. Nesse caso, dois aspectos que pesam muito para os
usuários (Con�abilidade e Desempenho):
Con�abilidade: ela é importante para reduzir e prevenir avarias ou interrupções graves e erros
que podem afetar os usuários e diminuir a sua satisfação. O software é melhor se falhar com
menos frequência e se recupera facilmente da falha quando ela acontece. Percebeu que
usamos o termo “falhar com menos frequência”? Sim, porque ele vai falhar! Como você pode
medir a con�abilidade?
Incidentes de produção: uma boa medida da con�abilidade de um sistema é o número de
bugs de alta prioridade identi�cados na produção;
Teste de con�abilidade: os tipos comuns de teste de con�abilidade são o teste de carga,
que veri�ca como o software funciona sob altas cargas, e o teste de regressão, que
veri�ca quantos novos defeitos são introduzidos quando o software passa por alterações.
Os resultados agregados desses testes ao longo do tempo podem ser uma medida da
resiliência do software;
Avaliação de con�abilidade: um teste aprofundado conduzido por especialistas que
constroem um ambiente operacional simulando o ambiente real no qual o software será
executado. Nesse ambiente simulado, eles testam como o software funciona em um
estado estável e com certo crescimento esperado (por exemplo, mais usuários ou maior
rendimento);
Taxa média de falha: mede o número médio de falhas por período, por unidade
implantada ou usuário do software;
Tempo médio entre falhas: uma métrica usada para medir o tempo de atividade ou a
quantidade de tempo que o software deve funcionar corretamente até a próxima falha
principal.
Desempenho: esse aspecto é conhecido como e�ciência. Normalmente, os elementos mais
importantes que contribuem para o desempenho de um aplicativo são como seu código-fonte
é escrito, sua arquitetura de software e os componentes dentro dessa arquitetura: bancos de
dados, servidores web etc. A escalabilidade também é fundamental para o desempenho:
sistemas que podem ser escalados para cima e para baixo podem se adaptar a diferentes níveis
de desempenho exigido. O desempenho é especialmente importante em campos, como
processamento algorítmico ou transacional, onde grandes quantidades de dados precisam ser
processadas muito rapidamente e até mesmo uma pequena latência pode causar problemas
signi�cativos. Mas hoje o desempenho está se tornando universalmente importante, pois os
usuários de aplicativos móveis e da web exigem alto desempenho e �cam rapidamente
frustrados se um sistema não responde rapidamente. Como você pode medir o desempenho?
Teste de carga: conduzido para entender o comportamento do sistema sob uma determinada
carga, por exemplo, com 1.000 usuários simultâneos.
Teste de estresse: compreender o limite superior de capacidade do sistema.
Teste de absorção: veri�ca se o sistema pode suportar uma determinada carga por um período
prolongado e quando o desempenho começa a diminuir.
Monitoramento de desempenho de aplicativos: esta é uma nova categoria de software que pode
fornecer métricas detalhadas de desempenho da perspectiva do usuário.
Indicações para saber mais sobre os assuntos abordados
nesta Unidade:
Sites
Técnicas de VV&T – Validação, Veri�cação e Teste 
Vamos apresentar os principais conceitosrelacionados à atividade de VV&T – Validação,
Veri�cação e Teste – enfatizando as técnicas de Leitura de Código, Teste Funcional, Teste
Estrutural e Baseada em Erros. 
FELIZARDO, K. R. Técnicas de VV&T - Validação, Veri�cação e Teste. 2012. Disponível em: 
2 / 3
Material Complementar
LINHADECODIGO
Técnicas de VV&T - Validação, Veri�cação e Teste
1 INTRODUÇÃO Engenheiros de software buscam qualidade (e desenvolvem
atividades de garantia de qualidade e de controle de qualidade) aplicando
métodos e medidas técnicas sólidas, conduzindo revisões técnicas formais e
efetuando teste de software bem planejado [Pressman, 2002]. A de�nição de
VV&T - Validação, Veri�cação e Teste - abrange muitas das atividades
relacionadas com a Garantia da Qualidade de Software, ou GQS.
LEIA MAIS LINHADECODIGO 
http://www.linhadecodigo.com.br/
http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-validacao-verificacao-e-teste.aspx
http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-validacao-verificacao-e-teste.aspx
http://www.linhadecodigo.com.br/artigo/492/tecnicas-de-vvampt-validacao-verificacao-e-teste.aspx
Vídeos
Software Testing Explained: How QA is Done Today 
Historicamente, o teste não era uma prioridade. Que tal hoje? Os testes tornaram-se mais do
que uma tarefa rotineira, merecendo o título de Garantia da Qualidade, que também abrange
planejamento, monitoramento e controle. E quanto às áreas de crescimento mais rápido em
controle de qualidade hoje?
Teste de Software – Plano de Teste
YOUTUBE
Software Testing Explained: How QA is Done Today
Historically, testing hadn't been a priority.In the 1960s, IBM introduced System/360, a
legendary mainframe computer built speci�cally to be modular and com...
VEJA EM YOUTUBE 
Software Testing Explained: How QA is Done Today
https://www.youtube.com/
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FoLc9gVM8FBM%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DoLc9gVM8FBM&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FoLc9gVM8FBM%2Fhqdefault.jpg&key=40cb30655a7f4a46adaaf18efb05db21&type=text%2Fhtml&schema=youtube
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FoLc9gVM8FBM%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DoLc9gVM8FBM&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FoLc9gVM8FBM%2Fhqdefault.jpg&key=40cb30655a7f4a46adaaf18efb05db21&type=text%2Fhtml&schema=youtube
https://www.youtube.com/watch?v=oLc9gVM8FBM
[Web.br 2016] Behaviour Driven Development, e eu com isso? 
Promovida pelo escritório brasileiro do World Wide Web Consortium (W3C Brasil) e realizada pelo
Núcleo de Informação e Coordenação do Ponto BR (NIC.br), a Conferência Web.br 2016
ocorreu em São Paulo, nos dias 13 e 14 de outubro, no Centro de Convenções Rebouças, sob a
temática Internet das Coisas na Web (IoTw). NICBRVIDEOS.
YOUTUBE
Teste de Software - Plano de Teste
Teste de Software - Plano de Teste
VEJA EM YOUTUBE 
Teste de Software - Plano de Teste
YOUTUBE
[Web.br 2016] Behaviour Driven Development, e eu com is…
http://youtube.com/
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FoMzCQkPN3Ug&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DoMzCQkPN3Ug&image=http%3A%2F%2Fi.ytimg.com%2Fvi%2FoMzCQkPN3Ug%2Fhqdefault.jpg&key=40cb30655a7f4a46adaaf18efb05db21&type=text%2Fhtml&schema=youtube
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FoMzCQkPN3Ug&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DoMzCQkPN3Ug&image=http%3A%2F%2Fi.ytimg.com%2Fvi%2FoMzCQkPN3Ug%2Fhqdefault.jpg&key=40cb30655a7f4a46adaaf18efb05db21&type=text%2Fhtml&schema=youtube
https://www.youtube.com/watch?v=oMzCQkPN3Ug
https://www.youtube.com/
https://www.youtube.com/watch?v=xpYe7Nj_gAY
[Web.br 2016] Behaviour Driven Development, e
eu com isso?
Palestra "Behaviour Driven Development, e eu com isso?" com Glaucimar
Aguiar.Promovida pelo escritório brasileiro do World Wide Web Consortium
(W3C Brasil) e...
VEJA EM YOUTUBE 
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FxpYe7Nj_gAY%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DxpYe7Nj_gAY&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FxpYe7Nj_gAY%2Fhqdefault.jpg&key=40cb30655a7f4a46adaaf18efb05db21&type=text%2Fhtml&schema=youtube
https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FxpYe7Nj_gAY%3Ffeature%3Doembed&display_name=YouTube&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DxpYe7Nj_gAY&image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FxpYe7Nj_gAY%2Fhqdefault.jpg&key=40cb30655a7f4a46adaaf18efb05db21&type=text%2Fhtml&schema=youtube
3 / 3
Referências
ANJOS, L. A. M.; MOURA, H. P. Um Modelo para Avaliação de Produtos
de Software. 2020. Disponível em:
<https://www.cin.ufpe.br/hermano/laps/download/laps-um-modelo-
para-avaliacao-de-produtos-de-software.pdf>. Acesso em: 29/03/2021.
FOWLER, M. Teste de Integração. 2018. Disponível em:
<https://martinfowler.com/bliki/IntegrationTest.html>. Acesso em:
29/03/2021.
 STH. O Que é Software Quality Assurance (SQA). 2021. Disponível em:
<https://www.softwaretestinghelp.com/software-quality-assurance/>
Acesso em: 29/03/2021.
 THAKUR, D. Planejamento de Projetos em Engenharia de Software.
2018. Disponível em: <https://ecomputernotes.com/software-
engineering/project-planning> Acesso em: 29/03/2021.
 RUGGIERI, R. Análise sobre a ISSO 9126 – NBR 13596. 2016. Disponível
em: <https://www.tiespecialistas.com.br/analise-sobre-iso-9126-nbr-
13596/>  Acesso em: 29/03/202