1 - Qualidade e teste de software

Prévia do material em texto

introdução
Introdução
Aqui estamos em nosso primeiro encontro! Como de costume nestas ocasiões, na unidade que agora
iniciamos, serão desenvolvidos temas introdutórios relacionados à qualidade de um produto de software,
incluindo conceitos e processos afins. Devido o caráter estritamente objetivo da qualidade, deveremos
abordar também seus padrões mais importantes e seus meios de gerenciamento e manutenção. Por fim
trataremos das métricas aplicadas à qualidade, como meios de avaliar sua efetividade no processo de
criação de um software.
Esperamos que o domínio deste conteúdo funcione como boa base para seu aprofundamento nos assuntos
relacionados ao tema e que lhe sirva como meio de alcançar seu sucesso profissional. Caro aluno, prezada
QUALIDADE EQUALIDADE E
TESTE DE SOFTWARETESTE DE SOFTWARE
Me. Roque Mai t ino Neto
IN IC IAR
aluna, aceite nossas boas-vindas ao curso de Qualidade e Teste de Software!
É provável que você já tenha ouvido elogios bastante calorosos dirigidos a produtos mais antigos,
construídos há algumas décadas e que, por algum motivo, ainda estão em operação. Tomemos como
exemplo uma máquina de lavar roupas: seu material de construção resistente, seus comandos mais simples
e a sensação de robustez que se associa à suas formas são motivos suficientes para que alguns atribuam a
ela maior qualidade do que atribuem às atuais. Hoje, no entanto, sabemos que fatores como consumo de
energia elétrica, oferta de funções mais convenientes, baixo custo de manutenção e eletrônica confiável são
bastante importantes na composição daquilo que se considera uma boa máquina de lavar roupas.
Justamente pela transitoriedade do que se entende como um produto de qualidade (o que é bom hoje pode
não ser bom amanhã) e pela subjetividade envolvida nas avaliações (minha opinião sobre um produto pode
não ser a mesma que a sua) é que se procura padronizar conceitos, métodos e formas de avaliação da
qualidade, sempre visando dar feição objetiva àquilo que pode sofrer tanta influência de fatores subjetivos.
Com qualidade de software não é diferente. Pessoas e organizações que se importam com a excelência
dos produtos que fabricam e/ou usam devem se orientar por parâmetros objetivos em suas comparações e
medições de qualidade, o que certamente mitigará a interferência de fatores meramente subjetivos na difícil
tarefa de imprimir o rótulo de “Produto de Qualidade” em um software.
Antes de abordarmos algumas das boas definições de qualidade de software que a literatura nos oferece,
vale a colocação, desde já, da seguinte questão: o que é um software de qualidade? Shaffer (2013)
considera esta uma pergunta difícil de ser respondida de uma única maneira. Uma possível medida seria a
adequação do produto ao seu propósito, o que significa que o software funciona de acordo com o que foi
projetado para fazer.
A expressão "adequação ao propósito" pressupõe a existência de um registro da descrição das
funcionalidades do produto. No caso de um software, seu propósito está refletido em suas funções, que, por
sua vez, estão descritas na especificação de requisitos.
Uma outra medida é a qualidade do processo que gerou o software, item que abordaremos com mais
detalhes adiante. Numa relação direta entre valores, muitos creem que um bom procedimento de criação é
capaz de gerar um bom produto. Por fim, pessoas com raciocínio voltado à Engenharia de Software podem
considerar que ter qualidade é simplesmente estar em conformidade com as especificações previamente
definidas.
Entender qualidade, seus padrões e suas medições são os desafios centrais deste nosso encontro e
começaremos a superá-los pela abordagem de alguns conceitos básicos relacionados ao tema.
1.1 Qualidade do produto de software
Definir qualidade de um produto de software de forma universal e irretocável e ainda alcançar unanimidade
na comunidade de observadores é tarefa difícil. Muitos autores lançaram conceitos que, com o passar do
tempo, tornaram-se superados ou mostraram-se incompletos. De acordo com IEEE (2014), autores e
organizações já definiram, de formas diferentes, o termo qualidade. “Conformidade com os requisitos” e
“atingimento de excelentes níveis de adequação para o uso” foram definições comuns no passado. Uma
grande desenvolvedora relacionou qualidade como um valor de mercado, em que “o cliente é o árbitro final”.
tópico 1
tópico 1
Fundamentos da Qualidade de SoftwareFundamentos da Qualidade de Software
Mais recentemente a qualidade foi definida como a capacidade do produto de satisfazer requisitos explícitos
e implícitos, mediante condições específicas e como o grau em que um produto de software atende aos
requisitos estabelecidos, desde que tais requisitos representem com precisão as necessidades, desejos e
expectativas das partes interessadas (IEEE, 2014).
De qualquer forma, já podemos extrair dois fatos deste contexto: (i) as definições de qualidade baseiam-se
na premissa da conformidade com os requisitos. Em outras palavras, a qualidade é dependente das
necessidades que um software deve atender a fim de resolver algum problema no mundo real e (ii)
qualidade não significa perfeição, pois sempre será possível observar itens a serem melhorados em algo
que se reconhece como de boa qualidade.
Já que a perfeição em nossos produtos não é, via de regra, um estado atingível, uma boa ideia para se
atingir boa qualidade é o estabelecimento de níveis aceitáveis de excelência em características do nosso
software. Embora possam ser desdobradas em outros tantos, quesitos como a corretude, a eficiência e a
usabilidade são tidos como indicadores amplamente aceitos da qualidade do produto. Vejamos alguns deles
(MAITINO NETO, 2016):
#PraCegoVer: Apresenta quatro setas. Cada seta é composta por uma imagem à sua esquerda, um texto
centralizado e um número à sua direita. Estão dispostas de cima para baixo: a primeira seta possui como
cor de fundo o vermelho, na sua extremidade esquerda temos a imagem de um celular, no centro temos a
palavra corretude e à direita o número um. A segunda seta possui tom alaranjado como cor de fundo, na
sua extremidade esquerda a imagem de uma lâmpada, no centro a palavra eficiência e à direita o número
dois. A terceira seta tem tom verde água, na sua extremidade esquerda a imagem de um gráfico, no centro
a palavra usabilidade e à sua direita o número três. A quarta e última seta tem tom azul escuro, na sua
extremidade esquerda a imagem de uma seta acertando o centro de um alvo, no centro a palavra
Portabilidade e à sua direita o número quatro.
Conforme a figura 1.1 observa-se os seguintes indicadores: Corretude , trata-se da capacidade do software
em executar suas funcionalidades conforme elas foram definidas. Se pudéssemos resumir este item em
uma pergunta, ela seria próxima de: “o software faz aquilo que eu quero?”; Eficiência , relaciona-se com o
grau de adequação do programa aos recursos de hardware, tais como processador e memória. Com a
queda no custo do hardware, este quesito tem merecido menos atenção do que no passado, já que as
máquinas podem ser dimensionadas com mais recursos sem a necessidade de grandes investimentos
financeiros. Usabilidade , este fator está relacionado com a facilidade de uso do produto. Em outras
palavras, trata-se da medida da capacidade do público-alvo em obter valor do software por meio da sua
interface; e Portabilidad e, é possível usar o produto em outra plataforma? Trata-se da medida de
facilidade em mudar o software de uma plataforma para outra. A portabilidade entre Windows e Mac pode
ser usada como exemplo.
Para que nossa noção de qualidade de um produto de software esteja consolidada, falta-nos contato com
alguns conceitos mais objetivos. Observe o primeiro: “Qualidade é a totalidade das características de um
produto de software que lhe confere a capacidade de satisfazer necessidades implícitas e explícitas”
(ISO/IEC 9126-1, 2003, p. 17).
Observe que o autor relaciona qualidade às características do produto e à sua capacidade de desempenhar
o que se esperadele. Necessidades explícitas são aquelas objetivamente expostas por quem demandou o
produto. Por exemplo, o cliente determina que o sistema deverá ser capaz de emitir relatório de vendas por
região e por cliente. Já as necessidades implícitas são aquelas não ditas e que devem ser previstas pelo
profissional responsável pelo processamento dos requisitos. A compatibilidade do sistema ao hardware
disponível pode ser um exemplo neste caso.
Outra definição importante sobre 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). Nesta definição o autor relaciona qualidade a um
processo e não a uma providência ou ação isolada. Esta particularidade prepara nosso caminho para a
abordagem do processo de desenvolvimento de software. Sigamos adiante.
1.2 Qualidade do Processo de Desenvolvimento de Software
Relacionar diretamente a qualidade do produto à qualidade do processo que o criou é prática constante no
contexto da qualidade de software. Não é exagerada a afirmação de que apenas um bom processo de
desenvolvimento irá gerar bons produtos, tampouco é a ideia de que assegurar a qualidade de todas as
etapas da construção de um produto irá garantir sua qualidade global.
Neste sentido, a divisão da Engenharia de Software voltada à qualidade do produto criou uma série de
providências tomadas pela equipe durante o processo de desenvolvimento para assegurar a qualidade do
seu produto, de maneira vinculada ao processo que o cria. A estas providências foi dado o nome de SQA
(Garantia da Qualidade do Software, ou do inglês Software Quality Assurance ) e uma das suas definições
mais objetivas é expressa como "padrão planejado e sistemático de ações que são exigidas para garantir a
qualidade do software” (PRESSMAN, 1995, p. 733).
A garantia da qualidade não elege um único momento no processo de desenvolvimento para atuar. Ao
contrário, as atividades de SQA começam nas fases iniciais do projeto e seguem até a finalização do
software, o que nos faz supor que a responsabilidade das equipes do projeto e demais stakeholders
 também seja extensa.
A definição de SQA inclui a expressão “padrão planejado e sistemático de ações”, não é mesmo? Pois bem,
vamos então às ações (MAITINO NETO, 2016).
Assegurar a qualidade de um software envolve algumas tarefas e as três das mais importantes estão
descritas na sequência (PRESSMAN, 1995):
Aplicação de métodos técnicos: as providências associadas à SQA começam a ser aplicadas a
partir da especificação e do projeto do sistema. Uma especificação de requisitos imprecisa
certamente irá comprometer a qualidade do produto final. Tão logo uma especificação, um
protótipo ou um lançamento preliminar de um sistema tiver sido criado, será necessário avaliar
sua qualidade.
Realização de revisões técnicas formais: esta é a atividade central da avaliação da qualidade
de um produto. Uma revisão técnica formal é um encontro previsto na SQA no qual uma equipe
(de 3 a 5 pessoas, normalmente) destacada para o trabalho concentra-se na busca por
problemas de qualidade no produto ou, mais comumente, numa parte específica dele. Elas são
aplicadas em vários momentos do processo e são também, usualmente, referenciadas
como walkthrough (passo a passo) (MAITINO NETO, 2016).
Atividades de teste de software: embora seja tema a ser abordado adiante, vale registrar,
desde já, a criticidade da atividade de teste no contexto da qualidade. A técnica de criação de
software apurada, o talento da equipe e a precisão do método não são capazes de garantir a
ausência total de defeitos no código.
O teste é uma atividade desempenhada para avaliar a qualidade do produto e para sua melhoria, por meio
da identificação de defeitos e problemas. O teste de software consiste na verificação dinâmica do
comportamento de um programa em um conjunto finito de casos de teste, adequadamente selecionado a
partir de um número geralmente infinito de execuções do programa (IEEE, 2014).
Nas próximas unidades trataremos de teste de software de modo mais bem detalhado. Por ora,
abordaremos padrões de qualidade.
atividades
atividades
Embora possa não haver aceitação universal de uma única definição de software de
qualidade, existem algumas medidas que são geralmente aceitas. A exatidão é uma
delas; se um programa não conseguir adicionar uma coluna de números corretamente,
por exemplo, geralmente não é considerado de alta qualidade. Em relação às atividades
que compõem a garantia da qualidade de software (SQA), analise as afirmações que
seguem:
I – Para justificar sua aplicação, as atividades de SQA devem focar o sistema a partir do
momento em que ele for declarado implementado.
II – O teste de software integra as atividades de SQA e só pode ser aplicado se o
programa (ou parte dele) puder ser executado.
III - Uma revisão técnica formal integra as atividades de SQA e ocorre quando uma
equipe busca não-conformidades na qualidade do produto.
É verdadeiro o que se afirma apenas em:
a) Afirmativas I e II.
b) Afirmativas II e III.
c) Afirmativa III.
d) Afirmativa I.
e) Afirmativas II.
Em quais parâmetros podemos confiar na hora de escolhermos um modelo de qualidade? Existem
instituições que criam padrões de qualidade e os atualizam com regularidade? Há um padrão melhor que o
outro? Este segundo tópico da primeira unidade aborda essas questões e alguns dos mais bem-
conceituados modelos de qualidade, com destaque para seus pontos fortes e aplicações. Antes de nos
debruçarmos sobre eles, vale a pena sabermos um pouco mais sobre a organização que os cria e mantém.
A cidade de Genebra, na Suíça, abriga a sede da ISO, sigla da International Organization for
Standardization , órgão não vinculado ao governo e que, desde 1947, já publicou mais de 20.000 normas
internacionais que servem como padrão para atividades relacionadas à tecnologia, manufatura, agricultura,
saúde e outras tantas atividades humanas.
Devido a proliferação de diferentes siglas em línguas diferentes para o órgão, os fundadores resolveram
adotar ISO mundialmente, por se tratar de palavra derivada do grego isos , que significa igual (ISO, s.d.)
Dois dos principais padrões de qualidade utilizados mundo afora são:
2.1 ISO 9001 – Sistema de Gestão da Qualidade
Certamente que você já conhecia a norma 9001 da ISO por nome. Trata-se de um dos mais utilizados
padrões de qualidade do mundo. Ele fornece especificação para sistemas de gestão de qualidade, com
vistas às demandas do cliente em relação ao produto (SEAR, 2015).
Por ser tão conhecido e bem referenciado, sua implantação sinaliza que a organização é capaz de fornecer
produtos em consonância com os requisitos do cliente. Embora seja aplicável no processo de software, este
padrão pode ser implantado em qualquer organização, a despeito de seu tamanho e finalidade.
A ISO 9001:2015 (2015 indica o ano em que foi atualizada) adota uma abordagem de processo para
desenvolvimento, implementação e melhoria da eficácia de um sistema de gestão da qualidade, com o
objetivo de aumentar a satisfação do cliente com o produto. Ela se baseia em 7 princípios de gerenciamento
de qualidade: Foco no Cliente, Liderança, Engajamento de Pessoas, Abordagem de Processo, Melhoria,
Tomada de Decisão Baseada em Evidências, Gestão de Relacionamento (MAITINO NETO, 2016).
2.2 ISO/IEC 90003 – Orientações para Qualidade de Processo
de Software
Se a ISO 9001 aborda aspectos gerais da qualidade, falta-nos uma norma que forneça parâmetros para as
atividades relacionadas à qualidade de software. Esta norma existe e é conhecida por ISO/IEC
90003:2014. Ela endereça orientações para aplicação da ISO 9001 nos processos de aquisição,
fornecimento, desenvolvimento, operação e manutenção de um programa de computador e serviços de
suporte relacionados.
Sua aplicação é indicada em sentido amplo para transações de produtos de software entre organizações.
Especificamente é usada em processosde aquisição de produtos que darão suporte a um processo em
tópico 2
tópico 2
Padrões Relacionados com Qualidade dePadrões Relacionados com Qualidade de
SoftwareSoftware
uma empresa, produtos relacionados à um equipamento específico de hardware ou produtos relacionados à
um serviço de software.
atividades
atividades
Em quais parâmetros podemos confiar na hora de escolhermos um modelo de
qualidade? Existem instituições que criam padrões de qualidade e os atualizam com
regularidade? Há um padrão melhor que o outro? Considerando as características
gerais dos padrões de qualidade de software, analise as afirmativas a seguir:
I – Um padrão de qualidade sempre deve ser criado e mantido pela desenvolvedora do
software.
II – A adoção de um padrão de qualidade pode contribuir para que a desenvolvedora
que o adotou seja reconhecida como organização preocupada com a qualidade.
III – Os padrões de qualidade disponíveis referem-se apenas à qualidade do processo,
já que a qualidade do produto pode ser padronizada apenas pela sua desenvolvedora.
É verdadeiro o que se afirma apenas em:
a) Afirmativas I e II.
b) Afirmativas II e III.
c) Afirmativa III.
d) Afirmativa I.
e) Afirmativa II.
A gerência da qualidade de um software pode e deve ser entendida como um procedimento sistêmico,
idealmente, já incorporado na organização e que inclua processos, pessoas e ferramentas dirigidas à
obtenção da qualidade do produto.
Quando tomamos como exemplos ferramentas computacionais de gerenciamento financeiro ou de
gerenciamento de pessoas, espera-se que tais sistemas sejam partes integrantes da organização,
alinhados com necessidades particulares de finanças ou de gestão de pessoas.
De acordo com Moorthy (2013), um sistema de gestão de qualidade de software deve possuir 4 níveis: o
nível 1 é composto pelo manual de qualidade da empresa; o nível 2 refere-se aos métodos e processos
usados pela equipe para entregar suas tarefas; o nível 3 contém as linhas principais, os checklists e os
modelos, usados com bastante frequência no dia a dia e importantes na manutenção da consistência das
informações e, por fim, o nível 4 refere-se aos registros e documentos usados para fins de validação de um
produto, usados como evidências de uma atividade e úteis para referência futura. A figura a seguir mostra a
organização dos níveis de um sistema de gestão de qualidade.
#PraCegoVer: Apresenta uma pirâmide, dividida em quatro partes, cada uma com uma cor e uma
descrição. A base da pirâmide possui cor verde com a descrição: Registros e documentos que servem para
validar que os requisitos foram atendidos. O segundo nível da pirâmide, de baixo para cima possui a cor
azul claro com a descrição: Linhas principais, checklists e modelos. O terceiro nível da pirâmide, de baixo
para cima possui a cor azul escuro com a descrição: Métodos e processos. O topo da pirâmide, possui a cor
vermelha e a descrição: Manual de qualidade.
Nunca é demais ressaltar que, se quisermos conferir à qualidade o lugar que lhe é devido no processo de
criação de um produto de software, então também devemos tratá-la como a um processo, que deve
permear a criação. A busca pela qualidade deve definir os requisitos, os responsáveis por cada etapa, as
medições incluídas e o feedback. Em poucas linhas, o planejamento da qualidade envolve a definição do
produto no que se refere às suas características de qualidade e o planejamento dos recursos e atividades
para se obter o produto desejado.
tópico 3
tópico 3
Gerência de Qualidade de SoftwareGerência de Qualidade de Software
Pois bem, um processo específico de gestão de software é definido no padrão IEEE 12207.0-96 e inclui o
processo de garantia da qualidade, mais conhecido pela abreviatura SQA ( Software Quality Assurance ou
Garantia da Qualidade do Software). Como você bem se lembra, este processo foi abordado em nosso item
1.
Outro processo que visa conferir qualidade ao produto é o que chamamos de Verificação e Validação. Para
facilitar as referências ao tema, os termos verificação e validação são tratados como apenas um. De acordo
com IEEE (2014), trata-se de um processo bem estruturado para avaliar os produtos de software em todo o
seu ciclo de vida, do planejamento até sua efetiva entrega. Em resumo, retrata o esforço da equipe para
garantir que a qualidade está embutida no software e que ele reflete o desejo do usuário. A Verificação e
Validação (V&V), como também é conhecido esse processo, está interessada diretamente na qualidade do
produto.
O grupo revisões e auditorias inclui dois principais procedimentos (MAITINO NETO, 2016):
Revisões técnicas: o objetivo de uma revisão (ou análise) técnica é o de avaliar um produto de
software para determinar a sua adequação para a sua utilização pretendida. O objetivo é o de
identificar discrepâncias a partir das especificações e dos padrões aprovados. Os resultados
devem fornecer evidências que confirmem (ou não) que o produto atende às especificações;
Inspeções: o propósito de uma inspeção é detectar e identificar anomalias no software. Esta
prática se diferencia das revisões em dois aspectos: alguém que exerça cargo de gestão sobre
qualquer membro da equipe de inspeção não deverá participar desse processo, e uma inspeção
deve ser conduzida por um facilitador imparcial, treinado em técnicas de inspeção. As inspeções
incluem também um líder, um responsável pelos registros da seção e um número reduzido de
inspetores, comumente de 2 a 5 pessoas.
Abordados itens fundamentais da gestão da qualidade de um software, avançamos agora rumo aos meios
de se medir o produto.
atividades
atividades
A Inspeção de Software é um processo formal de verificação do software, que pode ser
aplicado para, praticamente, todos os artefatos gerados durante o ciclo de
desenvolvimento e que tem o custo mais alto de aplicar, mas também é o que produz o
melhor resultado. Considerando conteúdo relacionado à inspeção de software, assinale
a alternativa que contém a correta caracterização deste procedimento.
a) As inspeções não preveem a escolha de um líder para o procedimento.
b) Inspeções e revisões técnicas diferenciam-se apenas pela fase do processo
em que são executadas.
c) Numa inspeção não se admite a participação de alguém que exerça cargo de
gestão sobre qualquer membro da equipe de inspeção.
d) Nas inspeções, a quantidade de participantes varia de acordo com a
quantidade de defeitos que aqui imagina que o produto tenha.
e) É durante o processo de inspeção que a quantidade de participantes da
equipe de qualidade é discutida e revista.
É muito difícil concebermos uma atividade desempenhada profissionalmente que não inclua maneiras de se
medir o que é produzido. Essas medidas, sejam relacionadas ao tamanho físico, à complexidade funcional
ou ao desempenho, visam assegurar algo indispensável em um ambiente produtivo: o controle. Neste tópico
você terá contato com o conceito de métrica e medição, com algumas formas de medições de um produto
de software, além de revisões e inspeções. Com essas providências a equipe deverá garantir e manter a
qualidade de um software. Em frente!
4.1 Métrica e Medição
A medição é o processo pelo qual os números são atribuídos aos atributos de entidades do mundo real. Na
medição, atribui-se um valor numérico a uma grandeza física. Por exemplo, quando medimos a distância
entre dois pontos e obtemos 5 metros, estamos atribuindo o valor 5 à grandeza física chamada distância.
Usaremos o termo medição tanto para descrever um processo quanto um valor de atributo. A medição é
tipicamente uma quantificação direta, que envolve um único valor, ao passo que métrica é uma
quantificação indireta, que envolve o cálculo e o uso de mais de uma medida. Vamos a um exemplo de
métrica: considerando a medida de número de linhas de código de um programa e a medida de número de
defeitos encontrados em todo o programa, podemos estabelecer a métrica de quantidade de defeitos por
linha de código.
É desejável que as métricas sejam capazes de fornecer informação relevantepara a tomada de decisão e
para a comparação de desempenhos. É necessário que você tenha em mente um fato importante: existem
métricas referenciais, usadas normalmente de forma padronizada pelos desenvolvedores. No entanto, uma
métrica pode ser baseada no objetivo da organização e na sua necessidade de informação para a tomada
de uma decisão.
Devemos considerar também que uma métrica deve ser calculada com facilidade, que ela tenha condições
de ser repetida quantas vezes forem necessárias, que sua unidade seja compreensível e universal e que,
por fim, seu processamento possa ser automatizado.
Imagine que dois projetos de software – com alguma similaridade funcional entre eles – estejam em
construção. Se você quiser saber qual dos dois projetos está sendo mais produtivo, você deve realizar a
medição do tamanho do projeto e do esforço para produzi-lo. Contudo, sem uma métrica, a comparação
não seria viável, tampouco útil (MOORTHY, 2013).
Já sabemos que, feitas as medições, podemos (e devemos) utilizá-las para gerar as métricas. Para fins de
classificação, algumas métricas são geradas a partir de medidas obtidas diretamente, geralmente, por
contagem do atributo observado. Às métricas geradas damos o nome de métricas diretas. Outras métricas,
porém, são obtidas indiretamente. A elas damos o nome de métricas indiretas.
Para fins de averiguação da qualidade de um software é comum a aplicação de medidas em fatores que
caracterizam este software. Para isso, nada mais apropriado do que a busca por um modelo de qualidade
consagrado para definirmos as características desejáveis em um programa. O modelo de qualidade
ISO/IEC 25010:2011 estabelece um conjunto de oito características internas e externas de um software,
divididas em outras tantas subcaracterísticas. Para facilitar a compreensão global da norma e facilitar sua
síntese, o quadro 1.1 apresenta tais características de qualidade, separadas entre próprias do produto e
próprias do uso, conforme será́ explicado na sequência.
tópico 4
tópico 4
Métricas de Qualidade de SoftwareMétricas de Qualidade de Software
Quadro 1.1 - Modelo de qualidade da ISO 25010:2011.
Fonte: WAZLAWICK (2013, p. 233).
#PraCegoVer: Apresenta um quadro com fundo na cor cinza com três colunas, onde a primeira linha está
na cor azul-escuro contendo o título de cada coluna. As demais linhas alternam em tons de cinza-claro e
cinza-escuro.
A primeira coluna representa o tipo de característica de qualidade, sendo listados os seguintes tipos:
Características de Produto e Característica de Uso. Na segunda coluna são apresentadas as características
de cada tipo apresentado e na terceira coluna são apresentadas as subcaracterísticas de cada
característica.
No tipo características do produto, na primeira linha, temos como característica Adequação funcional e
como subcaracterística: Completude funcional, corretude funcional (acurácia) e funcionalidade apropriada.
Na segunda linha temos como característica Usabilidade e como subcaracterísticas: Maturidade,
disponibilidade, tolerância à falhas e recuperabilidade.
Na terceira linha temos como característica Usabilidade e como subcaracterísticas: Apropriação
reconhecível, inteligibilidade, operabilidade, proteção contra erro do usuário, estética de interface com o
usuário e acessibilidade.
Na quarta linha temos como característica Eficiência de desempenho e como subcaracterísticas:
Comportamento em relação ao tempo, utilização de recursos, capacidade.
Na quinta linha temos como característica Segurança e como subcaracterísticas: Confidencialidade,
integridade, não repúdio, rastreabilidade de uso e autenticidade.
Na sexta linha temos como característica Compatibilidade e como subcaracterísticas: Coexistência e
Interoperabilidade.
Na sétima linha temos como característica Capacidade de Manutenção e como subcaracterísticas:
Modularidade, reusabilidade, analisabilidade, modificabilidade, testabilidade.
Na oitava linha temos como característica Portabilidade e como subcaracterísticas: Adaptabilidade,
instalabilidade e substituibilidade.
Na nona linha temos como característica Efetividade e como subcaracterística: Efetividade.
Na décima linha temos como característica Eficiência como subcaracterística: Eficiência.
No tipo características de uso, na primeira linha temos como característica Satisfação e como
subcaracterísticas Utilidade, prazer, conforto e confiança.
Na segunda linha temos como característica Uso sem riscos e como subcaracterísticas: Mitigação de risco
econômico, mitigação de risco à saúde e segurança e mitigação de risco ambiental.
Na terceira linha temos como característica Cobertura de contexto e como subcaracterísticas: Completude
de contexto e flexibilidade.
Os parâmetros de qualidade, normalmente, são segmentados entre os que possuem mais afinidade com o
processo, com o produto percebido pelo usuário ou com o produto sob o ponto de vista da equipe. As
medidas de qualidade internas, por exemplo, servem para avaliar aspectos que usualmente são percebidos
apenas pelos desenvolvedores. A capacidade de manutenção e a facilidade em se aplicar testes são bons
exemplos dessas medidas.
As medidas de qualidade externa alcançam características avaliadas pela equipe do ponto de vista do
usuário. Por exemplo, a eficiência e capacidade de operação de um programa.
O modelo ISO/IEC 25010:2011, cujas características foram resumidas na tabela acima, agregou as
características internas e externas num único grupo e o chamou de características do produto. Elas podem
ser avaliadas no ambiente de desenvolvimento, ao passo que as características do software em uso podem
apenas ser avaliadas durante o efetivo uso do sistema.
Parece-nos bastante desafiador construir um produto que tenha boa adequação à todas essas
características e, por isso, vale conhecer melhor algumas das características de qualidade mencionadas no
quadro 1.1.
4.1.1 Adequação funcional
Antes conhecida como funcionalidade apenas; ela se refere à existência de um conjunto de funções que
satisfazem às necessidades previamente estabelecidas, quando o produto é usado sob condições
especificas. Duas de suas subcaracterísticas são a Completude Funcional (o software apresenta todas as
funções necessárias ao usuário?) e a Corretude Funcional ou Acurácia (o software gera dados e consultas
corretos segundo o que foi definido?) (WAZLAWICK, 2013).
4.1.2 Confiabilidade
Se um software é capaz de manter comportamento consistente com o que se espera dele ao longo do
tempo, então ele pode ser considerado confiável. A confiabilidade tem a ver com o funcionamento do
programa em situações incomuns. Ela pode ser medida diretamente e estimada usando-se dados históricos
e de desenvolvimento, ou seja, um computador poderá́ ser considerado livre de falhas quando não tiver
alguma incidência em um determinado ambiente e num determinado período (PRESSMAN, 1995). Desta
definição, o que ainda não temos claro é o que significa falha. Quando tratarmos de teste de software com
mais detalhes, esse conceito será abordado.
Vale aqui também destacar duas de suas subcaracterísticas: a Disponibilidade (avalia o quanto o software
está operacional e livre para uso quando necessário) e a Tolerância à Falhas (avalia a forma como o
software reage em situação anormal).
4.1.3 Usabilidade
De forma simplificada, podemos entender essa característica como a facilidade em se usar um programa,
do ponto de vista do usuário. Em linhas gerais, o programa é fácil de usar se ele é (REISS, 2012): Funcional
– ele realmente funciona?; Responsivo – ele me fornece respostas adequadas?; Ergonômico – eu posso
facilmente ver, clicar, arrastar e girar as coisas?; Conveniente – tudo está bem onde eu preciso que esteja?
“À prova de tolos” – o projetista me ajuda a não cometer erros ou quebrar coisas?
A usabilidade também apresenta subcaracterísticas, incluindo (WAZLAWICK, 2005): Operabilidade – o
produto é fácil de usar e controlar?; Proteção contra erro do usuário – o programa consegue evitar que o
usuário cometa erros?;e Acessibilidade – avalia o grau em que o produto foi projetado para atender
usuários com necessidades especiais.
4.1.4 Segurança
Se um programa consegue proteger os dados e as funções de acessos não autorizados, então ele tem um
bom nível de segurança. Algumas de suas subcaracterísticas devem ser destacadas. Entre elas:
Confidencialidade – mede o grau em que os dados e funções ficam disponíveis para quem, de fato, tem
autorização para acessá-los; Rastreabilidade de uso – mede o grau em que as ações realizadas por uma
pessoa ou por um sistema podem ser rastreadas de forma a ser efetivamente comprovado que, de fato, foi
essa pessoa ou sistema que realizou tais ações.
4.1.5 Capacidade de manutenção
Trata de uma característica que atrai interesse direto apenas da equipe de desenvolvimento, já que não
afeta a percepção do usuário em relação ao sistema. Como você certamente já inferiu, trata-se da
capacidade do sistema em passar por manutenção. Assim como todas as outras características
apresentadas, essa também conta com divisões. Vamos a elas: Modularidade – o sistema é bem dividido
em módulos? Mudanças em um dos módulos devem causar mínimo impacto nos outros; Reusabilidade – há
partes do sistema que podem ser usadas na construção de outro sistema?; Analisabilidade – o sistema
permite que se faça depuração com facilidade?
No âmbito das características de qualidade do software em uso, vale destacar (WAZLAWICK, 2013):
4.1.6 Efetividade
Capacidade que o produto tem de proporcionar ao cliente o atingimento de seus objetivos de negócio.
4.1.7 Satisfação
Capacidade que o produto tem de satisfazer o cliente em ambiente de uso. Pode ser dividida em Utilidade,
Prazer, Conforto e Confiança.
4.1.8 Uso sem riscos
O uso do software não pode implicar riscos para pessoas, negócios ou ambiente. Divide-se em mitigação do
risco econômico, mitigação do risco ambiental e mitigação do risco à saúde e segurança.
Outros parâmetros têm sua descrição disponível na literatura e podem ser usados como medidas para a
qualidade de um software. Como marco introdutório trataremos neste tópico apenas da ISO/IEC
25010:2011.
atividades
atividades
O modelo ISO/IEC 25010:2011, cujas características foram resumidas no Quadro 1.1 -
Modelo de qualidade da ISO 25010:2011, agregou as características internas e externas
num único grupo e o chamou de características do produto. Elas podem ser avaliadas
no ambiente de desenvolvimento, ao passo que as características do software em uso
podem apenas ser avaliadas durante o efetivo uso do sistema. Tendo como base os
parâmetros de qualidade considerados na avaliação de um produto, analise as
afirmações que seguem:
I) A confiabilidade de um software está relacionada ao grau de adequação da
metodologia que o criou às habilidades da equipe de qualidade.
II) A rastreabilidade de uso é uma subcaracterística da usabilidade e refere-se ao grau
em que as ações realizadas por uma pessoa ou por um sistema podem ser rastreadas.
III) A adequação funcional está relacionada ao grau em que as funções do sistema
satisfazem os requisitos previamente especificados.
É correto apenas o que se afirma em:
a) Afirmativa III.
b) Afirmativas II e III.
c) Afirmativas I e III.
d) Afirmativas I, II e III.
e) Afirmativa II.
indicações
Material Complementar
LIVRO
Engenharia de Software: Conceitos e Práticas
Raul Sidnei Wazlawick
Editora: Campus
ISBN: 978-85-352-6120-2
Comentário: O livro indicado trata a Engenharia da
Qualidade sob a ótica da qualidade, mesmo quando
aborda questões meramente procedimentais. Embora
tenha caráter genérico, o livro dedica três capítulos
exclusivamente para processos de qualidade, incluindo
ótimo tratamento para testes de software.
FILME
O Jogo da Imitação
Ano: 2014
 Comentário: O filme está ambientado na Segunda
Guerra Mundial e trata da atuação de Alan Turing na
criação de um artefato eletromecânico capaz de decifrar o
código dos nazistas para troca de mensagens entre o
comando de guerra e seus homens de campo.
conclusão
Conclusão
Chegamos ao final da primeira unidade do nosso curso e a diversidade de assuntos tratados, certamente,
foi uma das suas marcas. Analisamos diversas feições do que se entende por qualidade sob a ótica da
possibilidade de aprimoramento constante dos produtos e processos inseridos no contexto. Registramos
alguns conceitos formais sobre o tema para, então, tratarmos da qualidade do produto e da qualidade do
processo. Como a objetividade deve ser buscada nas avaliações de qualidade, propusemos visão geral de
duas importantes normas de qualidade. Na sequência, buscamos definir meio de se praticar a gerência da
qualidade e, por fim, abordamos algumas características de um software que podem ser usadas como
parâmetro de medição para sua qualidade.
Em nosso próximo encontro daremos mais um passo em busca da qualidade ao tratarmos de teste de
software. Bom estudo e até a próxima!
TRAILER
referências
Referências Bibliográfica
ALL About ISO . International Organization of Standardization. Disponível em:
< http://www.iso.org/iso/home/about.htm >. Acesso em: 14 mar. 2018.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 9126-1 : engenharia de software –
qualidade de produto – parte 1: modelo de qualidade. Rio de Janeiro: ABNT, 2003.
BARTIÉ, A. Garantia da qualidade de software: as melhores práticas de Engenharia de Software
aplicadas à sua empresa. 5. ed. São Paulo: Elsiever, 2002.
IEEE – INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. SWEBOK: Guide to the Software
Engineering Body of Knowledge. 3. ed. Piscataway: IEEE, 2014. Disponível em: < https://ieeecs-
media.computer.org/media/education/swebok/swebok-v3.pdf >. Acesso em: 03 abr. 2019.
MAITINO NETO, R. Engenharia de software . Londrina: Editora e Distribuidora Educacional S.A., 2016.
224 p.
MOORTHY, V. Jumpstart to software quality assurance. [S.I. : s.n.], 2013.
PRESSMAN, R. S. Engenharia de Software . São Paulo: Makron Books, 1995.
______. São Paulo: Pearson Prentice Hall, 2009. 1056 p.
REISS, E. Usable usability: simple steps for making stuff better. Indianapolis: John Wiley & Sons, 2012.
SEEAR, D. J. ISO 9001: 2015 Back to the future . A review of the new ISO Annex SL structure for
Certification Standards using the draft ISSO 9001: 2015 to explain the changes. USA: AuthorHouse, 2015.
SHAFFER, S. C. A brief introduction to software development and quality assurance
management. [S.l.: s.n.], 2013.
WAZLAWICK, R.S. Engenharia de Software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.
http://www.iso.org/iso/home/about.htm
https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf