Livro - Qualidade e Usabilidade de Software

Prévia do material em texto

QUALIDADE E USABILIDADE 
DE SOFTWARE
Christina Paula de Camargo Curcio
Te
cn
o
lo
g
ia
Q
U
A
L
ID
A
D
E
 E
 U
S
A
B
IL
ID
A
D
E
 
D
E
 S
O
F
T
W
A
R
E
C
hr
is
tin
a 
P
au
la
 d
e 
C
am
ar
g
o 
C
ur
ci
o
Neste livro vamos apresentar os conceitos fundamentais relacionados à quali-
dade de software, métricas, normas e orientações sobre a gestão da qualida-
de. Após este estudo, esperamos que você tenha facilidade para reconhecer 
a qualidade e usabilidade dos softwares disponíveis no mercado e gerir seus 
próprios projetos, identificando os requisitos necessários para o desenvolvi-
mento de um software com qualidade.
Fundação Biblioteca Nacional
ISBN 978-85-387-6296-6
9 788538 762966
CAPA_Qualidade e Usabilidade de Software.indd 1 17/08/2017 10:09:01
Christina Paula de Camargo Curcio
IESDE BRASIL S/A
Curitiba
2017
Qualidade e 
Usabilidade de 
Software
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
C984q Curcio, Christina Paula de Camargo
Qualidade e usabilidade de software / Christina Paula de Camargo 
Curcio. - 1. ed. - Curitiba, PR : IESDE Brasil 2017.
184 p. : il. 
Inclui bibliografia
ISBN 978-85-387-6296-6
1. Engenharia de software. 2. Software - Desenvolvimento. I. Título.
17-43661 CDD: 005.1
 CDU: 004.41
Direitos desta edição reservados à Fael.
É proibida a reprodução total ou parcial desta obra sem autorização expressa da Fael.
© 2017 – IESDE Brasil S/A. É proibida a reprodução, mesmo parcial, por qualquer 
processo, sem autorização por escrito da autora e do detentor dos direitos autorais.
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
Produção
FAEL
Direção Acadêmica Francisco Carlos Sardo
Coordenação Editorial Raquel Andrade Lorenz
Revisão IESDE
Projeto Gráfico Sandro Niemicz
Capa Vitor Bernardo Backes Lopes
Imagem Capa David M G/Shutterstock.com
Arte-Final Evelyn Caroline dos Santos Betim
Sumário
Carta ao Aluno | 5
1. Qualidade de software | 7
2. Normas e padrões | 27
3. Influência dos requisitos na qualidade do software | 47
4. Processo de desenvolvimento de software | 65
5. Gerência da qualidade de software | 89
6. Fundamentos da interação homem-computador (IHC) | 107
7. Usabilidade de software | 127
8. Acessibilidade e inclusão digital | 145
Gabarito | 165
Referências | 175 
Carta ao Aluno
No mercado atual existe uma diversidade de softwares para 
uso empresarial ou informal.
Os sistemas podem auxiliar bastante os processos de uma 
empresa e otimizar o tempo de trabalho; para isso, necessitam ser de 
fácil uso, com uma interface amigável ao usuário e, principalmente, 
ter qualidade. O que é necessário um software ter de qualidade?
A usabilidade de um software deve ser cuidadosamente 
estudada, pois compreender a interação do homem com o compu-
tador pode definir o sucesso ou o fracasso de uma aplicação. Além 
dos aspectos de usabilidade, se faz necessário reconhecer outros 
aspectos importantes que garantem a qualidade do software, assim 
como as etapas de planejamento e produção que devem ser rigo-
rosamente seguidas.
– 6 –
Qualidade e Usabilidade de Software
Neste livro vamos apresentar os conceitos fundamentais relacionados à 
qualidade de software, métricas, normas e a gestão da qualidade de software. 
Após este estudo, esperamos que você tenha facilidade para gerir e reconhecer 
a qualidade e usabilidade dos softwares disponíveis no mercado e identificar os 
requisitos necessários para o desenvolvimento de um software com qualidade.
Esperamos que seu estudo não termine por aqui. Com base neste mate-
rial, realize as atividades propostas, leia os textos indicados e faça você mesmo 
a sua pesquisa para aprofundar os conhecimentos aqui apresentados.
Bom estudo!
Qualidade de software
Introdução
O dia a dia das organizações demonstra como é frustrante a 
realidade do desenvolvimento de software: produtos mais caros do 
que deveriam ser, gastos desnecessários, cronogramas estourados, 
estresse no trabalho, desenvolvedores desmotivados, erros recorren-
tes nos projetos etc. Todos na organização saem perdendo com isso, 
sem exceção.
Para que os problemas enfrentados pelas organizações pro-
dutoras de software possam ser resolvidos, faz-se necessária uma 
conscientização de que, para desenvolver softwares, é preciso muita 
disciplina, pois somente com um processo ou um modelo de quali-
dade é possível construir sistemas de computação adequados. Desse 
modo, o objetivo deste capítulo é apresentar uma reflexão sobre a 
qualidade de software (conceito, fundamentos e processo), emba-
sada em pesquisa bibliográfica da área.
1
Qualidade e Usabilidade de Software
– 8 –
1.1 A qualidade de software
Qualidade é a capacidade de um produto ou serviço para atender às neces-
sidades do usuário (BEYON, 2011). No desenvolvimento de software, a qua-
lidade do projeto acompanha os requisitos de qualidade, as especificações e o 
design do sistema. Ela está focada principalmente no aspecto de implementa-
ção, em que é observado se a execução segue o design planejado e se o sistema 
resultante está cumprindo com os objetivos e requisitos de desempenho.
Para garantir a qualidade do software são necessários: envolvimento de 
pessoas, definição de requisitos do software, integração e melhoria contínua 
dos processos, ferramentas atualizadas e métodos de trabalho, conforme 
observado na Figura 1:
Figura 1 – Qualidade do software.
Métodos
Pessoas e 
definição de requisitos
Ferramentas
Integração e 
melhoria contínua
Garantia da 
qualidade de software
Fonte: Elaborada pela autora.
De acordo com a Figura 1, para se garantir a qualidade de um soft-
ware é preciso pessoas (analistas, programadores, webdesigners, gestores etc.) 
que tenham não apenas conhecimento da área, mas que saibam trabalhar em 
equipe e tenham disciplina e comprometimento com a organização. Elas têm 
de ter em mente os objetivos e as restrições do sistema a ser desenvolvido, de 
modo a definir suas propriedades e seus requisitos.
Os requisitos de um software, também chamados de requerimentos de 
software ou de requisitos funcionais de um sistema, podem ser compreendi-
dos como “as funções ou atividades que o software ou sistema faz (quando 
pronto) ou fará (quando em desenvolvimento)” e “condições ou capacita-
ções que devem ser contempladas pelo software, solicitadas pelo cliente ou 
– 9 –
Qualidade de software
usuário para resolver um problema ou alcançar um objetivo” (REZENDE, 
2005, p. 123).
Para se atingir a qualidade de software, ela deve ser incorporada à inte-
gração de todas as funções e recursos de uma empresa, desde a alta admi-
nistração. Essa integração deve estar aliada à melhoria contínua e à revisão 
dos processos.
Por último, o uso de ferramentas adequadas para o monitoramento da 
qualidade de software auxilia a corporação na mensuração da qualidade. Esse 
monitoramento pode ser feito por meio de métodos estatísticos que são cada 
vez mais indispensáveis no controle da qualidade. Tais métodos são recursos 
de verificação e validação da qualidade do software e controlam se o software 
foi desenvolvido de acordo com as especificações desejadas, de maneira cor-
reta, e garantem que o software atenda aos propósitos desejados.
1.1.1 Fundamentos da qualidade de software
Originalmente, a qualidade de um programa ou sistema era avaliada de 
acordo com o número de defeitos a cada mil linhas de código. Atualmente, 
com a evolução do conceito, outros fatores determinam a qualidade do 
software (BENYON, 2011):
 2 Operações de produtos: ascaracterísticas operacionais.
 2 Correção: grau em que um programa atende sua especificação e 
atinge os objetivos definidos pelo usuário.
 2 Confiabilidade: nível de execução esperada de um software para 
realizar as funções com precisão.
 2 Eficiência: número de computadores e recursos exigidos pelo pro-
grama para executar suas funções com o tempo de resposta adequado.
 2 Integridade: medida em que pode ser controlado o acesso ao software 
ou dados por usuários não autorizados.
 2 Facilidade de uso: esforço necessário para aprender, usar e interpre-
tar a funcionalidade do sistema.
 2 Revisão do produto: capacidade de resistir a mudanças de tecnologia.
Qualidade e Usabilidade de Software
– 10 –
 2 Facilidade de manutenção: necessária para localizar e corrigir um 
bug no sistema.
 2 Flexibilidade: esforço necessário para modificar um programa.
 2 Facilidade de teste: condição necessária para testar um programa, 
de modo a assegurar que a função desejada não exija esforço.
 2 Transição do produto: capacidade de adaptação a novos ambientes.
 2 Portabilidade: necessária para transferir um programa de um 
ambiente de hardware ou software a outra tecnologia.
 2 Reutilização: grau em que um componente de programa ou 
 software pode ser reutilizado em outras aplicações.
 2 Interoperabilidade: integração entre sistemas e outros aplicativos.
O CMM (Capability Maturity Model) é um modelo de qualidade de 
 software que classifica as empresas em níveis de maturidade, ou seja, determina 
a maturidade dos processos realizados para produzir cada software. De acordo o 
CMM, as organizações podem ser classificadas em cinco níveis de maturidade:
No nível 1 (inicial), o das organizações mais imaturas, não há 
nenhuma metodologia implementada e tudo ocorre de forma desor-
ganizada: por sua vez, no nível 5 (otimizado), o das organizações mais 
maduras, cada detalhe do processo de desenvolvimento está definido, 
quantificado e acompanhado. Assim, a organização consegue até 
absorver mudanças no processo sem prejudicar o desenvolvimento do 
software. (RESENDE, 2005, p. 137).
Para atingir um nível maduro de produção, métodos específicos devem 
ser implementados (WEBER, 2012):
 2 Gerenciamento de requisitos: é o processo contínuo de análise e 
documentação dos requisitos do software. Ocorre durante o pro-
jeto de desenvolvimento de software e envolve os usuários-chave 
ou stakeholders.
 2 Planejamento de projeto: busca refinar e detalhar os objetivos do 
projeto e planejar o trabalho necessário para alcançá-los.
– 11 –
Qualidade de software
 2 Monitoramento e controle de projetos: consiste em medir e coletar 
informações sobre o desempenho do projeto, assim como informar 
os envolvidos.
 2 Gestão de fornecedores: é o processo de adoção de boas práticas e 
de controle e gestão dos fornecedores.
 2 Garantia de qualidade: consiste no acompanhamento do projeto e 
na avaliação de seus diferentes aspectos para garantir que os padrões 
de qualidade sejam seguidos.
1.1.2 Aspectos no desenvolvimento 
do software com qualidade
A engenharia de software procura auxiliar a produção de programas e 
sistemas de boa qualidade, com baixo custo e dentro do prazo programado. 
Ela visa à melhoria de desenvolvimento de software ao longo do tempo, 
considerando que as tarefas relativas ao processo podem ser aprimoradas, 
controladas e medidas. Um dos principais benefícios de um processo de 
desenvolvimento de software definido e disciplinado é a melhoria de sua 
visibilidade, ou seja, as atividades desse processo são gerenciáveis e, por isso, 
seus prazos e custos expressam melhor a realidade.
Aqui, a engenharia de software será discutida de duas formas: a conven-
cional, que detalha os aspectos principais desse ramo, e outra, mais específica, 
que detalha o uso da orientação por objeto.
A engenharia de software procura atender uma necessidade humana, 
da mesma forma que outras ramificações da engenharia tratam de assuntos 
relacionados à mineração, agricultura, moradia e tantos outros que justifi-
cam a utilização de algum conhecimento científico específico. Ela traz bene-
fícios por meio dos recursos tecnológicos disponíveis para o tratamento 
de informações.
Uma parte dos métodos da engenharia de software vem da ciência da 
computação e a outra da experiência adquirida pelo usuário. A engenharia de 
software é composta por um conjunto de disciplinas específicas relacionadas 
à ciência da computação e utiliza as abstrações dessa área, como algoritmos 
e estruturas de dados, para criar sistemas de computador que atendam às 
Qualidade e Usabilidade de Software
– 12 –
necessidades do usuário, usando, para isso, um processo definido e discipli-
nado, por meio da tecnologia existente.
Existem três conceitos muito importantes na engenharia de software, 
que se relacionam intrinsecamente:
 2 Processo: trata-se de um conjunto de passos ordenados usado para 
atingir um fim específico, sendo composto por atividades, méto-
dos, práticas e transformações.
 2 Projeto: é o que concretiza um processo.
 2 Produto: é o objetivo do processo.
Esses conceitos podem ser relacionados da seguinte maneira: um pro-
jeto tem um escopo delimitado por datas de início e de fim, com pontos de 
controle, chamados de marcos de projeto, para que possa ser acompanhado e 
gerido. O escopo do projeto é um processo constituído de documentação que 
detalha o que é feito, quando e por quem, tendo por meta a concretização do 
produto especificado.
De modo geral, um produto tem um ciclo de vida em que é concebido, 
desenvolvido, entra em operação e sai de operação. Um produto de software 
é criado a partir do momento em que se percebe a necessidade de sua existên-
cia, e, assim, um conjunto de requisitos é determinado e desenvolvido para 
que seja posto em operação. Quando o produto não é mais necessário ou se 
torna obsoleto, seu ciclo de vida termina e ele é retirado de operação.
A literatura disponível varia muito ao definir as disciplinas da engenha-
ria de software, a qual se configura como uma área interdisciplinar que se 
baseia nos fundamentos de várias disciplinas (RESENDE, 2005). Elas podem 
ser distribuídas entre os aspectos de requisitos, planejamento de projetos e 
qualidade, conforme se discutirá a seguir.
1.1.2.1 Engenharia dos requisitos
Os requisitos descrevem ou expressam as características de um dado 
produto de software, podendo ser funcionais ou não funcionais. Requisitos 
funcionais são aqueles que determinam o comportamento do produto de 
– 13 –
Qualidade de software
software de acordo com uma situação específica, enquanto os requisitos não 
funcionais quantificam aspectos desse produto, como, por exemplo, desem-
penho, disponibilidade ou portabilidade.
Os requisitos precisam ser especificados em um documento, devendo-se 
detalhar e distinguir os explícitos e os normativos. Os requisitos explícitos são 
aqueles levantados por desenvolvedores com base nas informações dos usuários 
e os requisitos normativos são os provenientes de leis e normas aplicados ao 
produto de software (PRESSMAN; MAXIM, 2016).
Existem, ainda, os requisitos de expectativa do usuário, os quais não estão 
documentados. Eles são chamados de requisitos implícitos e são totalmente 
indesejados, porém podem ser minimizados por meio de uma boa especifi-
cação de requisitos, ou seja, detalhando-se bem os explícitos e normativos.
Para obter uma boa especificação de requisitos, faz-se necessário o uso 
de técnicas de levantamento, documentação e análise; constitui-se, assim, a 
engenharia dos requisitos, uma disciplina da engenharia de software.
Uma boa engenharia de requisitos aumenta a compreensão do produto 
para o seu público-alvo e também diminui a instabilidade dos requisitos, ou 
seja, a alteração dos requisitos constantes no documento de especificação.A instabilidade onera o projeto de várias formas, como, por exemplo, no 
aumento de prazos e custos. Porém, essa alteração de requisitos também pode 
acontecer devido a mudanças em requisitos normativos, sendo inevitável a 
variação do contexto do produto. O controle dos requisitos precisa ser, então, 
submetido a algum tipo de gestão, pois eles podem ser alterados mesmo à 
revelia do usuário. Isso constitui a gestão de requisitos, outra disciplina da 
engenharia de software.
1.1.2.2 Engenharia de gestão de requisitos
Além de especificar corretamente os requisitos, gerentes de projetos devem 
estar atentos a outros dois fatores, os prazos e os custos, pois estes, juntamente 
com os requisitos, determinam o sucesso ou o fracasso do projeto de software. 
Um produto de software deve atender aos requisitos e às necessidades dos usuá-
rios e também deve ser construído dentro do prazo e do custo estimados.
Qualidade e Usabilidade de Software
– 14 –
O aumento ou a alteração de requisitos acarreta aumentos de prazos e/
ou de custos. No caso da redução de requisitos, os prazos e os custos tam-
bém podem sofrer alteração, mas isso não é regra. O bom planejamento de 
projetos tenta equilibrar os componentes dos vértices desse triângulo crítico 
(requisitos, prazos e custos), com base em uma boa especificação de requisitos 
e com técnicas de estimativa e análise de tamanho, esforços, prazos e riscos. O 
planejamento de projetos é a disciplina da engenharia de software que trata 
desses aspectos.
O planejamento de projetos tem uma disciplina complementar, cha-
mada de controle de projetos, cujo objetivo é acompanhar o progresso dos pro-
jetos, comparando o previsto com o realizado. Busca solucionar os problemas 
detectados, replanejar os projetos, quando houver necessidade, e renegociar 
os compromissos assumidos.
Também diz respeito à gestão de requisitos a gestão de contratos. As 
organizações que terceirizam a produção de software devem estar capacitadas 
nessa gestão, porque precisam especificar corretamente todos os requisitos 
do produto, selecionar os candidatos mais qualificados, ter proficiência no 
acompanhamento do projeto para intervir quando necessário e verificar os 
critérios para a aceitação do produto (BENYON, 2011).
1.1.2.3 Engenharia de gestão de configurações
Para gerir com qualidade todos os artefatos produzidos no processo de 
desenvolvimento, a engenharia de software tem a disciplina de gestão de con-
figurações – gerência de configuração, ou, ainda, gestão de configuração de 
software, uma área responsável por fornecer o apoio para o desenvolvimento 
de software. Suas principais atribuições são o controle de versão, o controle 
de mudança e a auditoria das configurações.
Um grupo de pessoas deve ser designado para controlar esses artefatos de 
software, porque todos são passíveis de alterações. Em caso de organizações 
pequenas que não disponham de pessoal suficiente, um membro da equipe 
de desenvolvedores pode ser designado para essa função. Essa é uma disci-
plina em que é fortemente recomendado o uso de ferramentas automatizadas, 
devido ao grande volume de artefatos e de versões destes que são geradas 
durante todo o processo de desenvolvimento (WEBER, 2012).
– 15 –
Qualidade de software
1.2 Processos em qualidade de software
Para falar sobre qualidade em software, é preciso introduzir uma dis-
cussão sobre os erros aos quais um processo de desenvolvimento de software 
está sujeito. As disciplinas da engenharia de software que regem a garantia da 
qualidade dizem respeito ao impacto causado por esses erros.
1.2.1 Erros que devem ser evitados
A qualidade de um produto é definida pelo grau de conformidade com 
os seus requisitos e está diretamente relacionada à qualidade do processo uti-
lizado em sua construção. Pode-se afirmar, então, que a qualidade é uma 
relação construída com base em processos, pessoas e tecnologia envolvidos 
na construção de um produto. Esses três elementos formam o segundo triân-
gulo crítico da engenharia de software e indicam os fatores da produção 
(BENYON, 2011).
Os defeitos ocorrem em um produto de software em todas as suas fases 
de desenvolvimento. Eles são encontrados de diversas formas, como no 
desempenho aquém do desejado, nas funções que não são executadas correta-
mente ou na dificuldade para utilização do sofware. Assim, os defeitos estão 
relacionados à não conformidade com os requisitos explícitos, os normativos 
e os implícitos.
Os erros relativos ao produto estão vinculados a algum desses fatores 
e são defeitos de definição de requisitos ou defeitos introduzidos ao longo do 
projeto. Os mais comuns são a introdução de características desnecessárias 
aos requisitos, alteração dos requisitos sem uma análise de impacto e erro no 
foco do desenvolvimento, quando ele é voltado para a pesquisa e não para a 
produção em si.
Os erros relativos ao processo estão relacionados com processos 
informais ou processos oficiais rígidos e burocráticos. Os mais comuns são 
(WEBER, 2012):
 2 desperdício de tempo antes do início do projeto;
 2 pressões por prazos otimistas e o não cumprimento destes por 
serem impossíveis;
Qualidade e Usabilidade de Software
– 16 –
 2 falha no planejamento de projetos em que se omitem as estimativas 
de atividades, como as de garantia da qualidade e a omissão da 
análise de riscos;
 2 falha no método de gerir o projeto;
 2 pressa para começar a etapa de codificação;
 2 falha na subcontratação de serviços; e
 2 entrega do produto sem estar totalmente pronto ou testado.
Entre os requisitos e a codificação existe o projeto, presente em todas as 
fases do processo. Os defeitos de projeto são tão graves como os defeitos pro-
venientes de requisitos. Eles se caracterizam por dificuldade para utilização do 
software, desempenho ruim, defeitos aleatórios de difícil reprodução e dados 
inconsistentes que comprometem a manutenibilidade e a extensão. Um bom 
projeto deve ser também documentado.
Como todas as fases do desenvolvimento do projeto são passíveis de 
injetar erros no produto, é preciso haver atividades como testes, revisões for-
mais e informais e auditorias, que visem garantir a qualidade do software, 
detectando precocemente cada erro. Estudos já demonstraram que o aumento 
da qualidade reduz o tempo de desenvolvimento, devido ao refinamento na 
detecção e eliminação precoce de defeitos, o que é bem mais barato que corri-
gir o defeito em um estágio avançado do processo (BENYON, 2011).
Os métodos de garantia de qualidade devem levar em consideração 
o fator humano: é mais fácil detectar erros dos outros do que os próprios. 
Assim, revisões, testes e auditorias devem ser realizados por pessoas diferentes 
daquelas que desenvolveram o produto. Por fim, a garantia da qualidade deve 
ser gerida por um grupo de pessoas independente dos desenvolvedores e que 
não mantenha nível hierárquico com estes ou com o gerente do projeto e 
tenha acesso à alta gerência da organização.
Já os erros relativos a pessoas podem ocorrer por: falta de patrocínio 
para o projeto; ausência de participação dos interessados no produto, como 
os usuários e desenvolvedores; atritos entre as partes envolvidas; defeitos na 
formação da equipe do projeto, como a falha na contratação de pessoas; falta 
de entrosamento entre funcionários e dependência em relação a determinadas 
– 17 –
Qualidade de software
pessoas; ambiente inadequado ao trabalho, com muito barulho, pouco 
espaço e fatores ergonômicos inapropriados, e falta de motivação do pessoal 
(BENYON, 2011).
Os erros relativos à tecnologia podem ocorrer por uma estimativa oti-
mista de que muitos problemas podem ser resolvidos por meio de alta tecno-
logia, esquecendo-se de que para utilizá-la em profundidade é necessário trei-
namento e experiência. Assim, pode haver falha na análise para mudançade 
tecnologia e a substituição desta no meio de um projeto, falta de automação 
de atividades como as de gestão de configurações, ausência de ferramenta de 
modelagem e automação de atividades de testes.
1.2.2 Modelos de ciclo de vida
Para a existência de um processo de desenvolvimento de software, é pre-
ciso ter definido o seu modelo de ciclo de vida. Existem vários tipos de mode-
los, que se diferenciam principalmente pelo grau de controle aplicado sobre 
o processo em questão e sua visibilidade para o cliente no seu decorrer, como 
especificado a seguir.
 2 Codifica-Remenda: é o pior de todos os modelos de ciclo de vida 
aqui apresentados e, provavelmente, o mais utilizado. Com base em 
um problema existente, e não um problema modelado ou especifi-
cado, mas sim definido de uma forma qualquer, passa-se imediata-
mente à codificação. Os erros encontrados são corrigidos conforme 
a demanda, daí o termo remenda. Muitas vezes não existe um pro-
cesso definido ou, se existe, ele não é seguido, é impossível de ser 
gerido e, portanto, não se pode assumir compromissos confiáveis.
 2 Cascata: esse modelo de ciclo de vida tem a vantagem de apresen-
tar pontos de controle que permitem demarcar as fases do processo, 
facilitando a sua gestão. Porém, ele é rígido e burocrático, porque 
não permite a correção de erros nas fases anteriores e tem baixa 
visibilidade para o cliente, pois este não recebe feedback nos pontos 
de controle existentes, assim o único resultado que o cliente vê é o 
final. Ele apresenta uma variante que permite a realimentação entre 
fases, porém esta dificulta a gestão de projetos.
Qualidade e Usabilidade de Software
– 18 –
 2 Espiral: modelo de ciclo de vida em que um produto é desen-
volvido em diversas iterações (repetições). Uma iteração nova 
representa uma volta na espiral. Sua vantagem é que permite a 
construção de produtos com prazos curtos e a desvantagem é que 
é difícil de ser gerido.
 2 Prototipagem evolutiva: utiliza o modelo de ciclo de vida em espi-
ral para construir o produto em protótipos, cobrindo progressiva-
mente os requisitos até a finalização. Sua vantagem é que apresenta 
visibilidade e alta flexibilidade para o cliente. Como desvantagem, 
ele precisa de equipes disciplinadas e experientes; o projeto deve ser 
robusto para que a estrutura do produto permaneça confiável ao 
longo dos protótipos, além disso, ele é também difícil de ser gerido.
 2 Entrega evolutiva: esse modelo de ciclo de vida é uma combinação 
dos modelos cascata e prototipagem evolutiva. Apresenta a vantagem 
de ter alta visibilidade para os clientes e facilidade de gestão, por 
apresentar pontos de controle bem definidos. Sua desvantagem é a 
necessidade de um projeto que seja robusto para que a estrutura do 
produto permaneça confiável ao longo das liberações programadas.
 2 Dirigido por prazo: um conjunto de requisitos essenciais é defi-
nido e entregue no prazo programado nesse modelo de ciclo de 
vida. O produto final é, na verdade, um produto parcial e o res-
tante é desenvolvido em processos posteriores, geralmente cha-
mados de manutenção.
 2 Dirigido por ferramenta: utiliza-se um processo proposto por 
uma ferramenta CASE1 e podem ser adequados a um determinado 
tipo de produto, porém fica restrito ao domínio da aplicação.
Mesmo que uma organização decida por não desenvolver, mas adquirir 
um produto de software, ela tem de ter competência para gerir os processos de 
aquisição, implantação, adaptação e integração com outros sistemas e a orga-
nização. Isso pode sair mais caro do que o processo de desenvolvimento em si.
1 Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que 
abrange todos os programas (as “ferramentas”) que auxiliam os analistas nas atividades de en-
genharia de software, desde análise de requisitos e modelagem, até a programação e os testes.
– 19 –
Qualidade de software
1.2.3 Processos de desenvolvimento de software
Para que a organização possa ser considerada madura, ela precisa ter pro-
cessos de desenvolvimento formalmente definidos e que possam ser melhora-
dos continuamente, como os processos apresentados a seguir.
Processo pessoal de software – PSP: utiliza o modelo de ciclo de vida 
em entrega evolutiva e não há tratamento específico para requisitos. Na 
fase de planejamento do PSP, executam-se as atividades de estimativas de 
tamanho (com base em modelo de orientação a objetos), esforços, crono-
gramas e defeitos. O projeto é rigoroso tanto para concepção quanto para 
verificação e é realizado utilizando-se orientação a objetos, síntese lógica e 
máquinas sequenciais.
Processo de software para times – TSP: utilizando um modelo de ciclo 
de vida em espiral, esse processo é uma sequência do PSP. O TSP cobre a 
área de gestão de requisitos, planejamento e controle de projetos, garantia da 
qualidade e gestão de configurações não cobertas pelo PSP.
Processo unificado: esse processo é dirigido a casos de uso, centrado na 
arquitetura, sendo iterativo e incremental, e usa a UML (Unified Modeling 
Language) como notação para os modelos que o compõe. Ele utiliza um 
modelo de ciclo de vida em espiral e é dividido em fases e fluxos de trabalho. 
Cada fase representa um marco gerencial do projeto e cada fluxo de trabalho 
trata de um tema técnico específico. O RUP (Rational Unified Process) e o 
EUP (Enterprise Unified Process) são baseados no processo unificado.
Práxis: é um processo com fins didáticos e baseado em tecnologia de 
orientação a objetos e sua notação de análise e projeto também é UML. 
Apresenta elementos do processo unificado, mas com influência do PSP e 
do TSP. Da mesma forma que o processo unificado, o práxis abrange fases e 
fluxos: uma fase é dividida em uma ou mais iterações, e um fluxo é dividido 
em uma ou mais atividades.
Um dos objetivos de um processo de desenvolvimento de software é 
capacitar uma organização a identificar rapidamente e solucionar facilmente 
os problemas. Ora, para isso ela necessita de maturidade. Uma organização 
imatura é ruim aos profissionais desenvolvedores e gerentes, clientes e usuá-
rios. Para os profissionais, é ruim porque o ambiente de trabalho é pouco 
Qualidade e Usabilidade de Software
– 20 –
adequado, estressante, o grau de motivação é baixo e os processos são difíceis 
de gerir. Já para os clientes e usuários, é ruim porque a qualidade do produto 
final não é boa ou porque foram entregues fora do prazo e do custo estimado. 
Todos esses problemas podem ser minimizados, e até mesmo resolvidos, pela 
definição formal de um processo de desenvolvimento de software.
O processo precisa ser definido de forma a auxiliar a organização a pro-
duzir produtos melhores, com baixo custo e dentro do prazo estimado, e 
uma consequência inerente ao refinamento do processo é que os produtos 
são produzidos mais rapidamente. Por outro lado, se a organização erra defi-
nindo um processo rígido e burocrático, ele servirá apenas para formalizar 
uma situação e não será efetivamente usado na prática.
Um software é baseado em abstrações lógicas, e não em princípios físicos 
estáveis. Como consequência, a disciplina para gerir um processo desse tipo 
deve ser mais rígida que de costume. Assim, um processo de desenvolvimento 
de software ruim não vai conduzir a um produto de qualidade satisfatória.
É um erro imaginar que a qualidade de um software não pode ser 
medida; ela pode e deve ser medida por meio da produtividade ou do número 
de defeitos encontrados, por exemplo. As métricas devem ser coletadas, anali-
sadas e normatizadas para que o processo possa ser gerido e melhorado.
Outro erro muito comum em organizações é acreditar que os problemas 
da produção são mais técnicos que gerenciais. Com um processo de negócio 
ruim, pouco adianta a tecnologia e esta não tem retorno; sem processos de 
negócio mapeadose robustos, um projeto de desenvolvimento de software 
inicia de forma incorreta, já que aqueles são a base deste. O mesmo se aplica 
quando a gestão é deficiente. Mais uma vez, os indicadores dos problemas 
da produção recaem nos problemas gerados por um processo mal definido. 
As pessoas erram porque a informação chega até elas de forma incorreta, 
incompleta ou confusa, os recursos disponíveis não são adequados ou não são 
suficientes, o processo é mal definido ou difícil de seguir e falta treinamento 
da área de negócio nos processos e tecnologias utilizados (BENYON, 2011).
Infelizmente, a tendência é acreditar que os erros são do corpo técnico, 
por falta de comprometimento e treinamento, e não devido a processos 
– 21 –
Qualidade de software
inadequados ou uma gerência de projetos despreparada. Os gerentes podem 
não conhecer totalmente o domínio da aplicação e precisam ser treinados 
em gestão de pessoal. Também precisam estar comprometidos com o projeto 
para se abstrair de paixões pessoais e evitar competições internas que sem-
pre existem dentro das organizações, procurando levar ao conhecimento dos 
desenvolvedores as informações corretas, completas e precisas.
A conclusão extraída é óbvia: fatores de produção, pessoas, tecnologia 
e processos são muito dependentes uns dos outros. Não basta ter tecnolo-
gia se não há um corpo técnico com capacidade de operá-la, e isso requer 
treinamento e experiência. Não basta ter tecnologia e um corpo técnico 
altamente capacitado se os gerentes acreditam que isso resolverá todos os 
problemas e eles terão o produto desejado dentro do prazo e custo estima-
dos. Para tudo isso, é preciso um processo definido.
Para a realização da melhoria de processos, faz-se necessária uma análise 
em que os problemas relativos a eles são de responsabilidade dos gerentes 
de projetos. Ora, isso porque os gerentes possuem um universo de variá-
veis envolvidas, estando capacitados a procurar e encontrar as deficiências 
do processo para interferir quando for preciso. A atuação de um gerente de 
projeto deve ser de forma a estimular melhorias sem procurar efetivamente 
os culpados, porque isso leva ao ocultamento dos problemas reais. De outra 
forma, o processo fatalmente não funcionará. É tarefa do gerente promover 
aperfeiçoamentos, reduzindo o desgaste no ambiente de trabalho, a fim de 
aumentar a produção. Mas, para isso, é preciso que ele conheça o processo 
para poder agir eficazmente, ter o apoio da alta administração, que deve estar 
ciente do investimento a ser feito, envolver o corpo técnico e, por último, 
mas não menos importante, ele tem de ter em mente que a capacitação no 
processo não é conseguida da noite para o dia – ela é realizada em etapas, com 
marcos para pontos de controle bem definidos.
Assim, os processos de qualidade de software englobam fases que bus-
cam aumentar a eficiência e a eficácia dos softwares produzidos, conforme 
pode ser observado na Figura 2. O processo de melhoria contínua envolve os 
procedimentos de planejamento, controle e garantia da qualidade, em que as 
Qualidade e Usabilidade de Software
– 22 –
revisões devem ser contínuas ao longo de todo o projeto de desenvolvimento 
do software.
Figura 2 – Processos de qualidade do software.
Qualidade do software – 
Gestão da qualidade do software – 
conjunto de caracterísiticas de um sistema para atender os requisitos das partes interessadas.
direção e coordenação das atividade de qualidade de software
Melhoria da qualidade do software – processo de melhoria contínua
 2 Estabelecer os 
objetivos, pro-
cessos e recursos
Revisão dos 
processos de 
qualidade
 2 Cumprir os obje-
tivos e requisitos 
de qualidade
 2 Garantir que os re-
quisitos de qualidade 
sejam cumpridos
Planejamento 
da qualidade
Controle da 
qualidade
Garantia da 
qualidade
Fonte: Elaborada pela autora.
A Figura 2 resume o que foi visto até aqui: o processo de melhoria da 
qualidade do software deve ser contínuo e revisado em todos as etapas. Num 
primeiro momento é feito o planejamento, em que se estabelecem os obje-
tivos, processos e recursos. Durante o desenvolvimento, o controle de quali-
dade deve estar sempre presente, buscando-se cumprir os objetivos e atender 
aos requisitos de qualidade. A garantia de qualidade é uma etapa final, em 
que é feita uma última avaliação do produto, no entanto, para que ela seja 
eficaz, também precisa estar presente em todas as etapas anteriores, num ciclo 
de melhoria contínua.
– 23 –
Qualidade de software
1.3 Reflexões sobre a qualidade dos softwares
Para que o software tenha qualidade, ele deve ter usabilidade, funciona-
lidade, confiabilidade, manutenibilidade e desempenho. Para que essas carac-
terísticas de qualidade de software sejam atendidas é importante que sejam 
respondidas questões como: O software satisfaz a necessidade do usuário ou 
da empresa? Ele é confiável? Tem um bom desempenho? É fácil de usar? Pode 
ser corrigido com facilidade? Pode ser reutilizado em outro projeto?
O software deve satisfazer a necessidade do cliente em relação à fun-
cionalidade. Para isso, deve se propor a fazer o que é apropriado, de forma 
correta, ser capaz de interagir com os sistemas especificados, estar de acordo 
com as normas de qualidade de sofware e da organização e deve ser protegido 
para evitar acessos não autorizados.
Com relação à confiabilidade o sistema deve ser imune a falhas e ser 
capaz de recuperar dados em caso de falhas. Além disso, deve ser fácil de usar 
(com navegação intuitiva) para atender o critério de usabilidade, ou seja, o 
sistema deve ter um nível fácil de operação para o usuário e ser de fácil com-
preensão, pois se for muito complicado exigirá vários treinamentos, o que 
dificultará seu emprego.
Por último, o software deve ser de fácil modificação, adaptação e valida-
ção. A eficiência do software é outro item de qualidade a ser verificada pois 
deve ser enxuto, com bom tempo de resposta e de processamento na execução 
de suas funções, utilizando recursos e tempo aceitáveis pelo usuário.
No contexto da engenharia de software, o processo de gestão de quali-
dade é aquele que estabelece o comportamento essencial de um sistema, o qual 
pode ser mantido, independentemente de como o sistema é implementado.
Um modelo de análise deve ser confeccionado visando às abstrações que 
indicam o que o sistema vai fazer. Assim, pressupõe-se que uma tecnologia 
perfeita esteja disponível e o analista considere que não haverá restrições de 
capacidade de memória; a comunicação entre os objetos será realizada na 
velocidade ideal; a adequação do sistema à plataforma de computador não 
será um empecilho; não acontecerão erros e outras questões relacionadas às 
abstrações de como fazer o sistema (BENYON, 2011).
Qualidade e Usabilidade de Software
– 24 –
O modelo AOO (análise orientada a objetos) serve para formalizar a 
visão do mundo real no contexto do sistema de computador, estabelecendo os 
principais objetos que representam o domínio de uma aplicação e as estrutu-
ras organizacionais impostas a tais objetos, bem como a colaboração existente 
entre eles, ou seja, as conexões de mensagens que mostram a forma de comu-
nicação dos objetos com os demais (WEBER, 2012).
Os benefícios trazidos pela melhoria dos processos são muitos. Os prin-
cipais deles são (BENYON, 2011):
 2 Engenharia de requisitos e gestão de requisitos: são práticas que 
produzem um retorno de investimento mais significativo porque 
é mais barato captar o requisito certo do que alterá-lo em fases 
posteriores do processo.
 2 Projeto: menos significativo que o anterior, mas que não deixa de 
produzir impacto no retorno de investimento.
 2 Garantia da qualidade: as atividades de garantia da qualidade – as 
que mais sofrem devido à pressa para entrega de um produto – dão 
retornoquando as necessidades de se refazer as etapas iniciais de 
um processo tendem a diminuir.
 2 Prevenção de defeitos: aqui vale o ditado popular “é melhor preve-
nir que remediar”. Entre as atividades de garantia da qualidade, as 
de prevenção de defeitos dão mais retorno do que as de correção.
Ampliando seus conhecimentos
O texto a seguir trata sobre a importância do trabalho do analista 
de requisitos no desenvolvimento de um software e as princi-
pais dificuldades enfrentadas por esse profissional, cujo traba-
lho muitas vezes é desvalorizado ou incompreendido pelos 
outros colaboradores e até mesmo gestores da organização.
(FAGUNDES, 2011, p. 4-5)
– 25 –
Qualidade de software
Quando se trabalha algum tempo com requisitos de software, 
percebe-se o quão ingrata é a atividade. Não por ser mais 
ou menos complexa que as outras, mas pela forma como 
é tratada pelos pares. O Analista de Requisitos é tomado 
na maioria das vezes como um documentador (até mesmo 
pelos próprios trabalhadores de requisitos), corrompendo o 
bem-fazer da atividade e provocando prejuízo aos projetos e 
degradando ainda mais a forma como se percebe a engenharia 
de requisitos.
A percepção geral que se tem é que os analistas de requi-
sitos entram em ação para atrasar os projetos e que a docu-
mentação gerada é extensiva e de pouca valia. Às vezes 
parte dessa percepção é correta, mas a razão imputada é, na 
maioria das vezes, distorcida, apontando para uma origem 
incorreta. Muito mais vezes os problemas de requisitos se 
dão pela falta de preparação dos analistas, seu perfil e por 
uma fraca postura na relação com o cliente, em vez da len-
dária mão invisível do processo.
Como resultado desses fatores reais para uma construção ade-
quada de requisitos, constrói-se uma escala de retrabalho que 
a equipe não entende exatamente por quê. Por várias vezes 
durante um projeto há questionamentos sobre a forma dos 
requisitos serem especificados ou se a proposta é adequada 
ou não, desviando o foco da atividade em voga no anda-
mento do projeto.
Para, então, corrigir o prumo e trabalhar requisitos é premente 
que se faça uma revisão de propósitos, motivações, formação, 
discurso e perfis, para que as pessoas corretas estejam aloca-
das corretamente para realizar a atividade de maneira eficaz 
e eficiente. A adoção de novos processos e técnicas não 
surtirão efeito sem essa revisão.
Qualidade e Usabilidade de Software
– 26 –
Atividades
1. Para se avaliar a qualidade do software, é fundamental medir e moni-
torar todo o ciclo de seu desenvolvimento. Por quê?
2. O que são requisitos de software e como devem ser documentados?
3. Com relação aos processos de qualidade de software, quais são os 
principais erros encontrados?
4. Por que o modelo ciclo de vida codifica-remenda é o mais utilizado e 
o menos recomendado?
Normas e padrões
Introdução
No Brasil, existe um corpo de normas nacionais baseadas 
em normas internacionais, que buscam garantir a proteção do con-
sumidor por meio de produtos e serviços adequados. A adoção de 
padrões internacionais leva a melhores oportunidades de comércio 
global e reduz a produção de itens de baixa qualidade.
Para os sistemas de gestão, a normalização também ajuda as 
organizações e as partes interessadas em suas atividades, em dife-
rentes níveis, com seus próprios fins. Esse é um pré-requisito para a 
evolução de uma cultura de qualidade.
A seguir, são apresentadas e discutidas diferentes padroniza-
ções, suas aplicações e sua importância para ordenações em diversos 
contextos, incluindo o da qualidade de software.
2
– 28 –
Qualidade e Usabilidade de Software
2.1 Normas e seus organismos normativos
A normalização é o processo de desenvolvimento, implementação e 
melhoria dos padrões que se aplicam a ordens científica, industrial e eco-
nômica diferentes, para organizar suas atividades. A Associação Americana 
de Teste de Materiais define padronização como o processo de formulação e 
implementação de regras, numa abordagem ordenada para atividades especí-
ficas, visando a benefícios e com a cooperação de todos os envolvidos (CYBIS 
et al., 2015). As grandes somas de dinheiro que os países desenvolvidos inves-
tem em organizações nacionais e internacionais de normalização são uma 
prova da importância dada à padronização (VALERIANO, 2005).
A ISO (International Organization for Standardization) desenvolve nor-
mas internacionais para diversos campos da tecnologia, exceto o eletrotécnico, 
coberto pela IEC (International Electrotechnical Comission), e as telecomu-
nicações, abrangidas pela UIT (União Internacional de Telecomunicações).
De acordo com a ISO, padronização é a atividade que visa estabelecer os 
problemas reais ou potenciais, provisões para uso comum e repetido, a fim 
de obter um nível ótimo de ordenação em um dado contexto, que pode ser 
tecnológico, político ou econômico (WEBER, 2012).
A normalização envolve um conjunto de regras convencionais destina-
das a simplificar, unificar e especificar produtos (WAZLAWICK, 2013):
 2 Simplificar – procura manter apenas o estritamente necessário, seja 
em documentos, processos, orientações etc. As próprias normas 
também são simplificadas para serem facilmente assimiladas.
 2 Unificar – a ideia é criar um padrão para os produtos, utilizado em 
todas as partes do mundo para permitir trocas internacionais.
 2 Especificar – procura, por meio de uma linguagem clara e pre-
cisa, identificar os produtos, definindo-os, categorizando-os, 
catalogando-os e detalhando suas características, de modo a 
orientar o consumidor.
– 29 –
Normas e padrões
Em relação às normas técnicas, é importante conhecer os Organismos 
Nacionais de Normalização (NSB, do inglês National Standards Body) dos paí-
ses de interesse, que, em geral, possuem um centro de informação sobre nor-
mas. Os NSB têm um arquivo próprio de padronizações de organismos nacio-
nais, regionais e internacionais, tais como as do British Standards Institution 
(BSI, ou Instituto Britânico de Normalização) e da Association Française de 
Normalisation (AFNOR – Associação Francesa de Normalização). No Brasil, 
o organismo responsável pela elaboração de normas técnicas é a Associação 
Brasileira de Normas Técnicas (ABNT).
O papel dos NSB tem evoluído nas últimas décadas, com melhorias 
na infraestrutura física e econômica, avanços na tecnologia da informação, 
implantação de melhores práticas de fabricação, automação, transporte e 
mudanças em muitos aspectos que afetam o comércio e a indústria, levando 
a um aumento acelerado no volume de transações comerciais entre os países 
(SOMMERVILLE, 2011).
Com a globalização, a média das áreas das organizações consideradas 
sob padronização foi estendida para incluir sistemas de gestão, indústrias de 
serviços e novas tecnologias que não existiam até a segunda metade do século 
XX (PRESSMAN; MAXIM, 2016).
Os padrões são utilizados cada vez mais para apoiar os regulamentos 
técnicos, e mais direcionados para tecnologias convergentes e de rápido 
desenvolvimento, direcionados a uma ampla gama de partes interessadas 
(PFLEEGER, 2004). Novos produtos reguladores, com períodos mais curtos 
de desenvolvimento, são uma tentativa, por parte da comunidade normativa, 
para responder às exigências de governos, empresas e consumidores em todo 
o mundo (LAUDON; LAUDON, 2004).
Assim, as atividades de padronização tornaram-se mais complexas e 
mais importantes para o desenvolvimento nacional e internacional. A criação 
da Organização Mundial do Comércio (OMC), em 1995, levou ao desen-
volvimento de vários acordos na área, em especial o Acordo sobre Barreiras 
– 30 –
Qualidade e Usabilidade de Software
Técnicas ao Comércio e o Acordo sobre a Aplicação de Medidas Sanitárias e 
Fitossanitárias, ao qual todos os membros da OMC devem aderir (CAIÇARAJR., 2007). Esses acordos são uma tentativa de reduzir o impacto das normas 
e regulamentações usadas como barreiras técnicas ao comércio entre os países 
(CYBIS et al., 2015).
2.2 Normas ISO e modelos CCMI
2.2.1 ISO
As normas ISO são amplamente respeitadas e aceitas internacio-
nalmente pelos setores público e privado (CAIÇARA JR., 2007). A 
International Organization for Standardization, ou ISO, é uma organização 
não governamental, uma federação de organismos nacionais de normaliza-
ção de todas as regiões do mundo, incluindo países desenvolvidos e países 
em desenvolvimento (MARSHALL JR. et al., 2012).
Cada membro da ISO possui uma agência principal de normalização em 
seu próprio país. Os países-membros propõem as novas normas, envolvem-se 
em seu desenvolvimento e prestam apoio, divididos em grupos técnicos, em 
conjunto com a Secretaria Geral da ISO, localizada em Genebra, na Suíça 
(PRESSMAN; MAXIM, 2016).
O termo ISO tem raiz grega, significando igual, igualdade, o qual dá 
nome à organização, que também coincide com sua sigla. Esse é um signifi-
cado muito adequado a essa entidade, uma federação internacional indepen-
dente com o propósito de proporcionar sistemas uniformes de segurança, 
qualidade e eficiência do trabalho para trocas simples, entre países e regiões, 
de bens e serviços produzidos (PRESSMAN; MAXIM, 2016).
O ano de 1945 foi fundamental para a história da entidade, pois os 
delegados do Comitê Coordenador de Padronização das Nações Unidas 
(UNSCC) se reuniram em Nova Iorque para tentar criar uma organização 
de padrões, fundando as bases para a ISO (PRESSMAN; MAXIM, 2016). 
Ela foi estabelecida em 1946, com a participação de 64 delegados, de 25 
– 31 –
Normas e padrões
países, em Londres, Inglaterra, na sede do Instituto de Engenheiros Civis. 
Essas pessoas decidiram aventurar-se no projeto de uma organização cujo 
objetivo seria facilitar a industrialização e as regras de unificação e melhoria 
da coordenação internacional das empresas (CAIÇARA JR., 2007).
Em 27 de fevereiro de 1947, a ISO foi finalmente oficializada e inicia-
ram-se suas operações. Naquele ano, mais de 19.500 normas foram criadas 
para todos os setores de produção, incluindo o setor da saúde, a indústria de 
alimentos, a de tecnologia etc. (PRESSMAN; MAXIM, 2016).
Em 1987, surge a norma ISO 9000, com a finalidade básica de faci-
litar ainda mais o comércio global. Para chegar a um consenso sobre essa 
legislação, foi necessário o apoio de 75% dos países que a compõem. Essa 
política baseia-se em dois pilares: melhoria e desempenho, enraizada em 
princípios, incluindo mercados, regulação, melhorias, responsabilidade, 
desenvolvimento do intelecto etc. A partir de 1994, foi implementada a 
versão ISO 9001, quando ela se tornou mais interessante para as empresas 
(CAIÇARA JR., 2007).
A norma passou por um enorme crescimento desde então. A norma de 
1994 era especificamente dirigida a empresas com processos de produção e, 
portanto, na revisão de 2000 (ABNT, 2000), ela foi simplificada e tornou-se 
aplicável a todos os tipos de empresas, públicas ou privadas.
A versão atual do padrão é datada de 2015 – a ISO 9001:2015 
(ABNT, 2015), um aperfeiçoamento de sua edição anterior, de 2008 – ISO 
9001:2008 (ABNT, 2008). A fim de validar a implementação dessa norma, 
faz-se necessária uma auditoria de certificação e aplicação das regras de quali-
dade, e, se a conformidade for constatada, é emitido um certificado à empresa 
(MARSHALL JR. et al., 2012).
Em relação à engenharia de software, a NBR ISO/IEC 9126-1 é a 
atual padronização mundial de qualidade de produtos, propondo métricas 
e atributos para os produtos de software (ABNT, 2003). Sob o título geral 
Engenharia de Software – qualidade do produto, essa norma abrange, em suas 
três partes, o modelo de qualidade a ser adotado, as métricas internas e a as 
métricas externas – características e subcaracterísticas do produto de software.
– 32 –
Qualidade e Usabilidade de Software
2.2.2 CMMI
O Capability Maturity Model Integration (CMMI) foi criado pelo SEI 
(Software Engineering Institute), um órgão de pesquisa da universidade norte-
-americana Carnegie Mellon, e consiste em um modelo de garantia de quali-
dade com enfoque voltado para a capacidade de maturidade de processos de 
software nas empresas.
Em 1984, o SEI começou a pesquisa para desenvolver um quadro de 
melhoria e avaliação da qualidade das empresas de desenvolvimento de software 
que fornecem serviços para o Departamento de Defesa dos Estados Unidos. O 
resultado da investigação foi chamado de Capability Maturity Model Software 
(SW-CMM), um modelo de maturidade de capacidades desenvolvido para 
processos relacionados com a produção e manutenção de sistemas de software, 
que teve sua versão 1.0 publicada em agosto de 1991 (MARSHALL JR. et al., 
2012). Posteriormente, como resultado do feedback gerado pela comunidade 
de software, novas versões alteraram e acrescentaram uma série de elementos na 
CMM, principalmente em relação a sua institucionalização nas organizações. 
Assim, o SW-CMM pode ser usado para dois fins (CAIÇARA JR., 2007):
 2 Melhorar os processos relacionados com a produção e manutenção 
de software;
 2 Definir critérios para a determinação do nível de maturidade de 
uma organização que produz e mantém software.
Com o passar do tempo e a evolução do modelo CMM, estabelece-se 
o CMMI, que teve como um de seus propósitos unir vários modelos usa-
dos em conjunto dentro de organizações, em prol de melhorias de processo 
(CAIÇARA JR., 2007), como modelos de desenvolvimento de software 
(SW-CMM), sistemas de engenharia (SECM) e desenvolvimento de produ-
tos integrados (IPD-CMM). O CMMI serve como um guia que auxilia as 
empresas a gerenciar, mensurar e monitorar produtos e serviços e contém as 
práticas ligadas à gestão de projetos e de processos, à engenharia e ao suporte.
Assim, o modelo CMMI busca a melhoria contínua dos processos 
organizacionais, por meio da análise e redesign, fornecendo, de acordo com 
Caiçara Júnior (2007):
– 33 –
Normas e padrões
 2 Uma maneira de integrar os elementos funcionais de uma organização;
 2 Um conjunto de melhores práticas com base em histórias de 
sucesso, comprovadas por organizações com experiência em práti-
cas de melhoria de processos;
 2 Uma ajuda para identificação de metas e prioridades para a melho-
ria dos processos, dependendo dos pontos fortes e fracos da organi-
zação, obtidos por um método de avaliação;
 2 Um suporte às empresas em atividades produtivas complexas para 
coordenar as suas atividades;
 2 Uma referência para avaliar os processos atuais da organização.
O CMMI for Services fornece orientação para a prestação de serviços 
aos clientes internos e externos da organização. Em 2000, foi desenvolvido 
e publicado o método Requisitos de avaliação para o CMMI, que define os 
elementos considerados essenciais para avaliar o CMMI em uma empresa, 
e o Padrão de avaliação CMMI para melhoria de processos. Esses dois docu-
mentos também foram atualizados como resultado do feedback da comuni-
dade envolvida em CMMI, gerando a versão mais recente 1.2 do SCAMPI1 e 
ARC2, ambos publicados em 2006 (CAIÇARA JR., 2007).
2.2.2.1 Níveis de maturidade e capacidade
O CMMI está dividido em cinco níveis de maturidade, que atestam 
o grau de evolução de uma organização em determinado momento e tem 
como objetivo principal guiar a melhoria de processos das empresas. Com ele 
é possível gerenciar o desenvolvimento e a produção de software, com base 
em prazos e custos estabelecidos e com mais qualidade. Esses níveis estão 
demonstrados na Figura 3:
1 Métodos de avaliação SCAMPI (Standard CMMI Appraisal Method for Process Improvement) 
são os métodos geralmente aceitos para avaliar organizações perante os modelos CMMI (ISD 
BRASIL, 2017).
2 O documento deavaliação por áreas de resultado-chave ARC (Appraisal Requirements for 
CMMI) descreve requisitos para diferentes tipos de avaliação, buscando uma uniformidade 
entre os métodos (CARNEGIE MELLON UNIVERSITY, 2006).
– 34 –
Qualidade e Usabilidade de Software
Figura 3 – Níveis de maturidade do CMMI.
1 - Inicial
Processo im-
previsível e sem 
controle
2 - Repetível
Processo disci-
plinado
3 - Definido
Processo 
consistente e 
padronizado
4 - Gerenciado
Processo previ-
sível e contro-
lado
5 - Otimizado
Processo con-
tinuamente 
melhorado
Fonte: Elaborada pela autora, com base em CMMI INSTITUTE, 2017.
Esses níveis de maturidade de processos de uma organização são defini-
dos a seguir (PRESSMAN; MAXIM, 2016):
Nível 1: Inicial
No nível 1 de maturidade, a maioria dos processos são ad-hoc e caóticos 
e a organização geralmente não fornece um ambiente estável para apoiá-los. 
Sucessos nesse caso ocorrem devido aos esforços para superar a concorrência 
e de pessoas competentes dentro da organização, e não do uso de proces-
sos comprovados. Apesar desse caos, as organizações pertencentes ao nível 
1 frequentemente produzem os produtos e serviços que disponibilizam; no 
entanto, frequentemente excedem seus orçamentos e não cumprem os seus 
planos. Essas empresas têm como características a tendência a não honrar os 
seus compromissos, a abandonar processos em tempos de crise e a incapaci-
dade de repetir seus sucessos. Ainda, nesse nível os trabalhos são executados 
de modo redundante por pessoas que não compartilham seus métodos de 
trabalho com toda a organização.
Nível 2: Repetível (Gerenciado)
No nível 2, o caos passa a ser ordenado, e as organizações se concentram 
em tarefas diárias relacionadas com a administração. Cada projeto tem uma 
série de processos planejados e executados em conformidade com as políticas 
– 35 –
Normas e padrões
estabelecidas. São utilizadas pessoas qualificadas, que têm os recursos para 
produzir saídas controladas.
A disciplina de processo refletida pelo nível 2 de maturidade ajuda a 
garantir práticas e projetos de acordo com planos documentados e tanto a 
produção como a prestação de serviços são definidos. Os contratos são esta-
belecidos entre as partes interessadas e também revistos quando necessário. 
Artefatos e serviços são devidamente controlados, satisfazendo suas descrições 
específicas, padrões e procedimentos.
Nível 3: Definido
No nível 3 de maturidade, os processos são descritos em normas, proce-
dimentos, ferramentas e métodos. O conjunto de processos padrão da orga-
nização é estabelecido e continuamente melhorado, de modo consistente para 
toda a empresa. Os projetos são estabelecidos por meio da adaptação desse 
conjunto de procedimentos e normas de acordo com diretrizes específicas.
Uma diferença importante entre os níveis 2 e 3 de maturidade é o escopo 
das normas: a descrição de processos e procedimentos. No nível 2, as nor-
mas podem ser um pouco diferentes em cada instância específica do processo 
(por exemplo, em um projeto particular). No nível 3, padrões, descrições de 
processos e procedimentos em um projeto são adaptados com base em um 
conjunto de processos padrão da organização para determinado projeto ou 
unidade organizacional e, portanto, são mais consistentes.
Outra distinção importante é que no nível de maturidade 3 os proces-
sos são geralmente descritos de forma mais rigorosa do que no nível 2. Um 
processo definido apresenta claramente sua finalidade, insumos, critérios de 
entrada, atividades, papéis, medidas, etapas de verificação, saídas e critérios 
de saída. No nível 3, os procedimentos são geridos de forma mais proativa, 
compreendendo as inter-relações de atividades e medidas detalhadas do pro-
cesso, seus artefatos e serviços.
Nível 4: Gerenciado quantitativamente
No nível 4, a organização e os projetos estabelecem metas quantitativas 
para medir a qualidade e o desempenho dos processos, as quais são utilizadas 
– 36 –
Qualidade e Usabilidade de Software
como critérios na gestão. Os objetivos quantitativos são definidos com base 
nas necessidades de clientes, usuários finais, organização, processos e atores. 
A qualidade e o desempenho das atividades são compreendidos em termos 
estatísticos e tratados em todo o processo de ciclo de vida. Para subprocessos 
selecionados, são recolhidas e analisadas estatisticamente medidas sobre pro-
cessos de execução, as quais são incorporadas nas métricas de repositório da 
organização, para apoiar a tomada de decisão.
As variações dos processos, quando ocorrem, devem ser identificadas 
e corrigidas na causa raiz para prevenir futuras ocorrências de mudanças 
de processos.
Uma diferença importante entre os níveis 3 e 4 é a previsibilidade do 
desempenho do processo. No nível 4 de maturidade, esse desempenho é con-
trolado usando-se técnicas estatísticas e quantitativas, e o processo é quantita-
tivamente previsível; por outro lado, no nível 3 o desempenho do processo é 
previsível apenas qualitativamente.
Nível 5: Otimizado
No nível 5 de maturidade, uma organização melhora continuamente 
seus processos com base no conhecimento das causas comuns de variação 
inerente a processos. Trata-se de melhorias contínuas, incrementais e tecnoló-
gicas. Os objetivos de melhoria de processos quantitativos para a organização 
são estabelecidos e continuamente revisados, sendo utilizados como critério 
de qualidade em processos.
Uma diferença importante entre os níveis 4 e 5 é o foco da variação do 
processo. No nível 4 de maturidade, a organização direciona-se para encontrar 
as causas especiais de variação e fornecer uma previsão estatística dos resultados. 
No entanto, os resultados podem ser insuficientes para alcançar as metas esta-
belecidas. No nível 5, a organização está focada nas causas comuns de variação 
de processo e modifica os procedimentos afetados para melhorar o desempenho 
deles e atingir os objetivos quantitativos de melhoria de processos.
– 37 –
Normas e padrões
O quadro a seguir explica resumidamente o que acontece em cada um 
desses níveis.
Quadro 1 – Características dos níveis de maturidade das organizações.
Nível Características
Inicial
 2 Basicamente nenhuma prática forma de gerenciamento de enge-
nharia de software está implantada na organização.
 2 Tudo é feito à medida em que vão surgindo as necessidades.
 2 O padrão usual é o não cumprimento de prazos e orçamentos estabelecidos.
 2 A maioria das atividades são respostas a crises e não a tarefas pré-planejadas.
 2 O processo de software é imprevisível e depende totalmente da equipe atual.
 2 É impossível prever com precisão o tempo necessário para 
desenvolver um produto ou o seu custo.
Repetível
 2 Já estão implantadas práticas básicas de gerenciamento 
de projetos de software.
 2 As técnicas de planejamento e gerenciamento se baseiam em expe-
riências com produtos similares (daí o termo repetível).
 2 Há o acompanhamento meticuloso dos cronogramas 
de prazo e da planilha de custos.
 2 Os gerentes identificam problemas à medida que eles vão surgindo e tomam 
ações corretivas imediatas para evitar que eles se transformem em crises.
 2 Medidas tomadas durante um projeto podem ser usadas para elaborar 
cronogramas e orçamentos realistas para projetos futuros.
Definido
 2 O processo para a produção de software é completamente documentado;
 2 Tanto aspectos técnicos quanto gerenciais do 
processo são claramente definidos.
 2 São feitos esforços contínuos para melhorar o processo onde for possível.
 2 São usadas revisões para atingir as metas de qualidade de software.
 2 Há a introdução de novas tecnologias, como as ferramentas CASE 
para aumentar a produtividade.
– 38 –
Qualidade e Usabilidade de Software
Nível Características
Gerenciado
 2 A organização estabelecemetas de qualidade 
e produtividade para cada projeto.
 2 A qualidade e a produtividade são medidas continuamente.
 2 Ações corretivas são tomadas quando ocorrem desvios inaceitáveis das metas.
 2 Controles estatísticos de qualidade são implantados para a gerência 
ser capaz de distinguir o desvio esporádico de um problema 
significativo nos padrões de qualidade ou produtividade.
Otimizado
 2 Há aperfeiçoamento contínuo do processo.
 2 São usadas técnicas de controle estatístico de processos 
e qualidade para orientar a organização.
 2 O conhecimento adquirido em cada projeto é utilizado em projetos futuros.
 2 O processo incorpora uma curva de realimentação positiva, resultando 
em uma melhoria contínua na produtividade e na qualidade.
Fonte: Elaborado pela autora, com base em SCHACH, 2010, p. 93-94.
Dependendo do modelo de representação usada em CMMI, existem 
duas maneiras de realizar a melhoria de processos. Uma delas é utilizando 
a representação contínua e a outra é melhorando toda a organização, de 
acordo com os processos definidos. A representação contínua se concentra em 
melhorar um procedimento de modo que a organização possa ser certificada 
para uma área de processo, em um determinado nível de capacidade. Existem 
seis níveis de capacidade ao longo dos quais os processos são associados em 
uma área (Quadro 2), e cada um deles é construído sobre o nível anterior – 
ou seja, um processo, para chegar a determinado nível de capacidade, deve 
necessariamente ter atingido um nível anterior (CAIÇARA JR., 2007).
– 39 –
Normas e padrões
Quadro 2 – Níveis de representação contínua e escalonada.
Representação contínua Representação escalonada
Nível de capacidade Nível de maturidade
Nível 0 Incompleto
Nível 1 Realizado Inicial
Nível 2 Manejado Manejado (repetível)
Nível 3 Definido Definido
Nível 4 Manejado quantitativamente Manejado quantitativamente (gerenciado)
Nível 5 Otimizado Otimizado
Fonte: CYBIS et al., 2015. Adaptado.
Nos processos de representação contínua, os níveis de capacidade são 
delimitados da seguinte forma:
 2 Nível 0 – Incompleto – um processo é chamado de incompleto 
quando um ou mais objetivos da área de processo não estão 
em conformidade.
 2 Nível 1 – Realizado – é chamado de feito ou realizado o processo 
que satisfaz todas as metas específicas da área de processo.
 2 Nível 2 – Manejado (produzido) – é designado processo de gestão 
quando o projeto apresenta a infraestrutura para suportá-lo. O pro-
cesso é planejado e executado de acordo com a política da empresa, 
envolvendo as partes interessadas, e emprega pessoas qualificadas 
– 40 –
Qualidade e Usabilidade de Software
que tenham recursos adequados para produzir saídas controladas. 
É monitorado, controlado, revisto e avaliado de acordo com sua 
descrição específica.
 2 Nível 3 – Definido – é uma adaptação do conjunto de normas 
da organização, de acordo com as diretrizes da empresa, e fornece 
dispositivos, medidas e outras informações para melhorar os ativos 
da organização.
 2 Nível 4 – Manejado (gerenciado) quantitativamente – é contro-
lado usando-se técnicas quantitativas estatísticas e outras. Metas 
quantitativas para a qualidade e o desempenho do processo são 
estabelecidas e utilizadas como critérios para sua gestão.
 2 Nível 5 – Otimizado – otimização é a melhoria contínua do pro-
cesso, com base no entendimento de causas comuns de variação de 
processo. Esse processo é realizado por meio de aperfeiçoamentos 
incrementais e usando-se a inovação tecnológica.
Na representação escalonada, um método de melhoria de processo 
estruturado e sistemático, também envolve uma graduação em estágios ou 
níveis. Para atingir determinado nível, a organização precisa ter uma infraes-
trutura robusta, em termos de processos, para se qualificar para o próximo 
nível. Por isso, a empresa pode ser classificada pelo seu nível de maturidade, 
de 1 a 5, os quais são compostos por áreas de processo em que os objeti-
vos devem ser cumpridos a fim de que a organização possa ser certificada 
(Quadro 3) (PRESSMAN; MAXIM, 2016).
Quadro 3 – Modelo de classificação de áreas de processos organizacionais 
em níveis de maturidade.
Área de processo Categoria Nível de maturidade
Análise e resolução das causas Suporte 5
Análise e resolução das decisões Suporte 3
– 41 –
Normas e padrões
Área de processo Categoria Nível de maturidade
Assegurando a qualidade dos processos e produtos Suporte 2
Definição de produtos organizacionais 
+IPPD (OPD +IPPD) Gestão de processos 3
Desenvolvimento de requerimentos Engenharia 3
Treinamento organizacional Gestão de processos 3
Administração quantitativa de projetos Gestão de projetos 3
Administração de acordo com provedores Engenharia 2
Administração de requerimentos Gestão de projetos 3
Administração de riscos Suporte 2
Administração de configuração Gestão de projetos 3
Administração integral do projeto Gestão de projetos 3
Inovação e desenvolvimento organizacional Gestão de processos 5
Integração de produto Engenharia 3
Medição e análise Suporte 2
Monitoração e controle do projeto Gestão de projetos 2
Planejamento do projeto Gestão de projetos 2
Processos orientados às organizações Gestão de processos 3
Rendimento de processos organizacionais Gestão de processos 4
Solução técnica Engenharia 3
Validação Engenharia 3
Verificação Engenharia 3
Fonte: CYBIS et al., 2015. Adaptado.
– 42 –
Qualidade e Usabilidade de Software
2.3 Métricas de qualidade de software
As métricas de qualidade fornecem uma indicação de que o software 
está em conformidade com as exigências implícitas e explícitas dos clientes. 
O principal objetivo da engenharia de software é produzir com uma alta qua-
lidade. A fim de atingir esse objetivo, os engenheiros de software devem usar 
medições técnicas, de modo objetivo, para avaliar a qualidade dos modelos de 
análise, o código-fonte e casos de teste que foram criados por meio da aplica-
ção de engenharia de software (MARSHALL JR. et al., 2012).
O primeiro objetivo da equipe de projeto é o de medir os erros e defeitos. 
As métricas que vêm do resultado dessas medidas fornecem uma indicação 
da eficácia das atividades de controle e garantia de qualidade (PRESSMAN; 
MAXIM, 2016).
De acordo com Marshall Junior et al. (2012), as métricas de qualidade 
de software englobam: o resumo dos fatores que afetam a qualidade, a medida 
de qualidade e a eliminação dos defeitos.
2.3.1 Resumo dos fatores que afetam a qualidade
Marshall Jr. et al. (2012), define um conjunto de fatores de qualidade 
que avaliam o software sob três pontos de vista diferentes:
 2 operação do produto (usá-lo);
 2 revisão do produto (alterando-o);
 2 transição do produto (modificando-o para trabalhar em um 
ambiente diferente).
Assim, se fornece um mecanismo para o operador do produto – ou seja, 
a pessoa responsável pelo desenvolvimento do software – identificar se ele 
atende os requisitos de qualidade pré-estabelecidos.
– 43 –
Normas e padrões
2.3.2 Medida de qualidade
Exatidão, facilidade de manutenção, integridade e facilidade de utiliza-
ção são medidas de qualidade que fornecem indicadores úteis para a equipe 
do projeto (MARSHALL JR. et al., 2012) e devem ser avaliadas pela equipe 
de produção e pelos gestores:
 2 Exatidão: é o grau em que o software executa a sua função.
 2 Manutenção: é a facilidade com que um programa pode ser corrigido 
se um erro de sistema, seja de código ou de requisitos, for encontrado.
 2 Integridade: mede a capacidade de um sistema para resistir a ata-
ques (acidentais e intencionais) à sua segurança. Os ataques podem 
ser executados em qualquer um dos três componentes de software 
– programa, dados e documentos3.
	 Para medir a integridade, é preciso definir dois atributos adicionais:ameaça e segurança. Ameaça é a probabilidade de que um ataque 
dê certo em determinado momento. Já a segurança é a probabili-
dade que o sistema tem de repelir um ataque de certo tipo.
 2 Facilidade de uso: é uma tentativa de quantificar o quão amigável 
pode ser o programa para o usuário.
2.3.3 Eliminação dos defeitos
É o entendimento dos principais defeitos presentes nos projetos de 
software – como erros na gestão, prazos curtos, erros de código –, com o obje-
tivo de avaliá-los e eliminá-los, de modo a garantir o controle de qualidade 
em todas as atividades do processo (MARSHALL JR. et al., 2012).
3 A documentação de software consiste em manuais gerais e técnicos ou mesmo relatórios que 
explicam o funcionamento do programa ou sistema e acompanham o produto, explicando ao 
cliente como utilizá-lo e suas características.
– 44 –
Qualidade e Usabilidade de Software
As métricas de qualidade, portanto, são fundamentais nos processos de 
desenvolvimento de softwares, pois auxiliam no monitoramento e no con-
trole da qualidade, por meio de testes que ajudam a prever erros e a corrigir 
defeitos que, por ventura, possam surgir.
Ampliando seus conhecimentos
O texto a seguir trata sobre a importância de as empresas 
de desenvolvimento de software terem certificações na área 
de tecnologia, pois estas não apenas garantem qualidade de 
processos e produtos, como também atraem clientes.
Gestão da qualidade
(SILVA; AZEVÊDO, 2015, p. 100-101)
A gestão da qualidade de software tem como objetivo nor-
matizar e rever periodicamente os conceitos e métodos uti-
lizados por uma empresa, garantindo melhoria e correções 
nos processos de desenvolvimento, com base em estudos e 
estatísticas minuciosas. A área acompanha todos os processos 
de construção dos softwares: modelagem de negócio, e lici-
tação de requisitos, análise e designer do projeto, implemen-
tação, testes, implantação, gerenciamento de configuração e 
mudança, gerenciamento de projeto e ambiente.
A área da qualidade trabalha de acordo com as normas da 
ISO 9001, ISO 9002 e ISO 9003. Apesar de muitos acha-
rem que o procedimento de certificação de uma empresa de 
tecnologia é muito diferente das empresas industriais, os pro-
fissionais vêm mostrando que não. As fábricas de softwares 
são os grandes exemplos disso, pois as mesmas têm se preo-
cupado com a focalização nos clientes, abordagem dos pro-
cessos, envolvimento dos stakeholders, comprometimento da 
– 45 –
Normas e padrões
liderança, relação com os fornecedores e a melhoria contínua 
dos processos.
Muitos clientes que prezam por mais confiabilidade nos con-
tratados buscam empresas que sejam certificadas na área. Hoje 
são diversas as certificações, onde cada uma atende necessi-
dades específicas do negócio.
As mais conhecidas da área de tecnologia são: CMMI e 
MPS.BR. Para se certificar, a empresa precisa atender algumas 
exigências e demonstrar maturidade nos processos de produ-
ção. Essas certificações além de darem um peso maior ao cur-
rículo da empresa, atraem clientes que buscam por parceiros 
com maior qualidade nos processos.
A área da qualidade se responsabiliza pela garantia do cumpri-
mento dos processos e pela melhoria dos mesmos — melho-
ria contínua. O produto é visto como consequência da exe-
cução desses processos. Apesar dos esforços serem voltados 
para o processo, o principal objetivo é garantir um produto 
final que satisfaça o cliente.
[...]
Atividades
1. Explique em que as normas para os sistemas de informações auxiliam 
os processos e como é seu uso.
2. O que é SW-CMM e como ele pode ser usado?
3. Como é possível avaliar os fatores que afetam a qualidade de software?
4. Quais são os cinco níveis de maturidade de uma organização?
Influência dos requisitos 
na qualidade do software
Introdução
O processo de análise e verificação das necessidades de um 
cliente/usuário1 para o desenvolvimento de um sistema é chamado 
de engenharia de requisitos. O objetivo da engenharia de requisitos é 
entregar um software correto e completo, de acordo com especifica-
ções predeterminadas.
Os requisitos são a peça fundamental para um projeto de 
desenvolvimento de software com qualidade, que exige planeja-
mento e recursos. Os líderes do projeto utilizam os requisitos de 
base para estimar os recursos necessários à criação de um software.
1 Em alguns casos, cliente e usuário são a mesma pessoa, mas também podem ser 
pessoas diferentes. Cliente é a pessoa ou grupo que requisita o software a ser desen-
volvido e fornece os requisitos básicos do produto, além de coordenar os recursos 
financeiros para o projeto. Já usuário é uma pessoa ou grupo que vai realmente usar 
o software construído (PRESSMAN; MAXIM, 2016, p. 111).
3
Qualidade e Usabilidade de Software
– 48 –
Assim, os requisitos são a base para a decisão sobre como um produto 
será executado, ou seja, a base do ciclo de vida de um projeto. Disso decorre 
a sua importância na definição e gestão de processos.
3.1 Processos de negócio
As empresas se diferenciam entre si pela sua capacidade de organização 
e de processos de negócio. Cada empresa utiliza um procedimento especí-
fico para chegar ao resultado desejado, relacionando-o ao produto-fim da 
empresa. Para um desenvolvimento de software, por exemplo, é fundamental 
o levantamento dos processos do negócio da empresa para que, no futuro, 
sejam desenvolvidas tecnologias que auxiliem em sua gestão.
Um processo de negócio consiste em um conjunto de tarefas ou ativida-
des que são executadas de acordo com certas regras relacionadas a determina-
dos objetivos. Trata-se de uma série de tarefas individuais, e cada uma delas é 
executada em uma ordem específica.
Para entender a importância do processo de negócio para a construção 
de um software, é importante primeiro avaliar com o cliente a sua necessi-
dade, saber exatamente o que ele deseja no produto solicitado para se ter uma 
ideia aproximada das funções que o software deverá apresentar (WEBER, 
2006). Com essa informação, os analistas preparam um estudo detalhado 
sobre a viabilidade do sistema desejado e avaliam a possibilidade de desenvol-
vê-lo (VALERIANO, 2005).
Esse estudo de viabilidade centra-se no objetivo do projeto, pois analisa 
os requisitos do software para a sua implementação, a contribuição do projeto 
para a organização e os limites de custo, sempre de acordo com os valores da 
empresa (VALERIANO, 2005).
Se esse estudo de viabilidade for positivo, a próxima fase começa com 
a coleta detalhada dos requisitos, por meio de uma entrevista com o cliente/
usuário. Analistas e engenheiros comunicam-se com os clientes/usuários para 
conhecer as ideias destes sobre os resultados que o software deve fornecer e 
quais as características que devem ser incluídas (VALERIANO, 2005).
– 49 –
Influência dos requisitos na qualidade do software
3.1.1 Requisitos de software
Como visto no Capítulo 1, os requisitos incluem necessidades quantificadas 
e documentadas, desejos e expectativas do patrocinador, dos stakeholders2 e dos 
clientes (VASQUEZ; SIMÕES, 2016) em relação ao software encomendado.
De acordo com a definição do glossário do IEEE3, os requisitos do 
software são (VASQUEZ; SIMÕES, 2016, p. 18):
1. Uma condição ou capacidade do sistema, solicitada por um 
usuário, para resolver um problema ou atingir um objetivo.
2. Uma condição ou capacidade que deve ser atendida por uma 
solução para satisfazer um contrato, especificação, padrão ou 
quaisquer outros documentos formais impostos.
3. Documentação da representação das condições ou capacidades 
apresentadas nos dois itens anteriores.
4. Uma condição ou capacidade que deve ser alcançada ou pos-
suída por um sistema, produto, serviço, resultado ou compo-
nente para satisfazer um contrato, padrão, especificação ou outro 
documento