Ebook 3 Qualidade de Software

Prévia do material em texto

E-book 3
QUALIDADE DE 
SOFTWARE
Lucia Tavares
Neste E-Book:
INTRODUÇÃO ����������������������������������������������������������� 3
GESTÃO DA QUALIDADE DE SOFTWARE �������4
Processos ����������������������������������������������������������������������������������4
Medidas de Qualidade ������������������������������������������������������������12
Boas Práticas em Qualidade de Software �����������������������������16
Personal Software Process ����������������������������������������������������26
Team Software Process ���������������������������������������������������������30
Information Technology Infrastructure Library ���������������������32
CONSIDERAÇÕES FINAIS �����������������������������������38
SÍNTESE ��������������������������������������������������������������������39
2
INTRODUÇÃO
Neste módulo, vamos estudar a Gestão de Qualidade 
de Software e as boas práticas aplicadas à Qualidade 
de Software� Com isso, entenderemos o conceito de 
Processo de Software, uma vez que é necessário 
montar os indicadores no período de desenvolvimen-
to do software, bem como pelo fato de o software 
ter um ciclo de vida�
Estudaremos, ainda, de que modo diminuir erros 
visando a diminuir os custos, uma medida que só 
é possível com a adoção de uma gestão eficiente 
e de qualidade� Na sequência, passaremos pelos 
modelos de desenvolvimento e pelas metodologias 
que facilitam a vida do desenvolvedor�
Por fim, discutiremos as melhores práticas para con-
duzir esses processos� Vamos iniciar?
3
GESTÃO DA QUALIDADE 
DE SOFTWARE
Processos
Antes de iniciarmos esta discussão, precisamos com-
preender o que é um processo de software� Um pro-
cesso não é só a sequência de ações, mas pode ser 
ainda uma sequência de tarefas que sofre impacto 
de algumas variáveis, por exemplo:
 ● Responsabilidade: Quem executa as tarefas?
 ● Métrica: Medir o processo e criar indicadores�
 ● Indicadores: Números que demonstram como o 
processo está, se atinge o resultado necessário�
 ● Previsibilidade: Estimativas baseadas em indica-
dores criados a partir das métricas�
 ● Controle: Acompanhamento e correção dos desvios 
que aparecem nos indicadores�
Com base nessas variáveis, entendemos que um 
processo com qualidade de software deve ser trata-
do com a finalidade de atender às expectativas dos 
clientes� O envolvimento de todos que participam do 
processo de software é um ponto nevrálgico para o 
seu sucesso�
A existência de mudanças nos processos sempre 
resulta em resistência, sobretudo a resistência na 
cultura organizacional da empresa� Então, como tra-
4
balhar com o processo de qualidade de software? 
Simples de falar, complexo para executar� A execução 
coordena todos os processos e etapas envolvidos, 
como o acompanhamento, os indicadores, os riscos, 
a eliminação dos riscos e a prevenção� Isso depende 
das fases elaboradoras, revistas e que tenham como 
resultado um processo de melhoria contínua�
Para atingir esse patamar, os processos de qualidade 
de software precisam de quatro fases:
 ● Concepção�
 ● Elaboração�
 ● Construção�
 ● Transição�
Essas fases acontecem para que o processo tenha, 
naturalmente, um nível de acerto alto e a diminuição 
do nível de falhas� Todas essas falhas aparecem nos 
testes que ocorrem no meio do processo e no final 
para atingir um resultado de qualidade� 
Com isso, gera-se uma enorme economia, pois os 
acertos feitos durante o processo de desenvolvimen-
to custam muito menos que acertos no final. Então, 
deduzimos que a qualidade custa menos do que os 
problemas�
Por que adotar os processos de gestão de qualidade 
de software?
Podemos apresentar diversas razões, mas vamos 
atacar a que mais incomoda os clientes: o custo� O 
Standish Group realizou uma pesquisa em 2012 e 
5
constatou que mais de 80% dos projetos de softwa-
re não são entregues porque excedem o limite de 
orçamento e prazo, bem como por não atenderem 
aos requisitos� Assim, uma condução equivocada 
de projetos de software resulta em 30% de cancela-
mentos antes da sua finalização.
Tal cenários fez com que os projetos também mu-
dassem� Nesse sentido, o Manifesto Ágil trouxe uma 
nova concepção de como tratar os projetos de de-
senvolvimento de software (Figura 1):
Figura 1: Manifesto ágil. Fonte : Wiki
A qualidade tem, hoje, uma vital importância no to-
cante à vantagem competitiva para empresas, mui-
to embora alguns líderes custem a enxergar isso� 
Softwares sem qualidade geram erros comprome-
tedores, e o mercado atualmente tem um grande 
gargalo nas softwarehouses: a manutenção e a 
6
http://wiki.supel.ro.gov.br/index.php/Arquivo:Imagem1.jpg
descontinuidade de produtos que exigem muitas 
correções e manutenção de software�
O cliente se coloca no centro do desenvolvimento, 
e o produto somente é aprovado se estiver em con-
formidade com o que foi encomendado. A fim de 
entender melhor essa relação, vamos estudar alguns 
itens que impactam na qualidade de um software:
Investimento e custo com qualidade
Pensar em qualidade é pensar em perfeição� Porém, 
esse pensamento é capcioso, pois a perfeição não 
existe� Quando pensamos em um bom produto de 
software, pensamos em um nível de qualidade que 
atenda aos clientes� Nesse nível, calculamos o cus-
to e o investimento que o cliente quer fazer� Assim, 
tratamos como investimento o que foi empregado e 
que vai trazer retorno; o custo, por sua vez, tratamos 
como as falhas, a prevenção e a avaliação�
Controle de qualidade
O controle é a base de toda a qualidade, revisões, tes-
tes e inspeções durante o desenvolvimento garantem 
que os procedimentos e normas sejam aplicados� 
Nessa metodologia, são identificados a partir des-
ses procedimentos as inconformidades, dentro dos 
requisitos funcionais ou não funcionais, que foram 
levantados no projeto, direcionados pelo usuário�
Esses procedimentos implicam duas abordagens que 
são fundamentais para que o controle aconteça de 
maneira prática: revisões e avaliações�
7
Em revisões, temos a documentação e os processos 
utilizados, cujo papel é muito importante� Funcionam 
da seguinte maneira: um grupo operacional e outro 
do projeto são direcionados para revisar toda a do-
cumentação e, com isso, verificar todo o processo, a 
fim de dar conformidade ao que foi documentado e 
feito, dentro dos padrões utilizados pela metodologia 
de desenvolvimento�
O que está fora do padrão retorna à origem e é en-
viado à hierarquia superior, isto é, os stakeholders e 
a gerência do projeto, que tomam as providências 
necessárias e acompanham o processo até que tudo 
esteja refeito de modo condizente com o padrão 
preestabelecido�
A revisão constitui-se de três tipos básicos:
 ● Tipo 1: inspeções relativas ao projeto, àqueles 
erros que não condizem com os requisitos, seja no 
processo seja no código de desenvolvimento�
 ● Tipo 2: apanhado geral do projeto, é o que orienta 
as reuniões com os stakeholders e que dá transpa-
rência ao projeto com um todo, ou seja, faz o acom-
panhamento dos prazos, planos e custos�
 ● Tipo 3: refere-se à análise técnica da documenta-
ção do produto, no qual se apontam as inconsistên-
cias de todo o projeto, dentro da documentação (de 
código, erros dentro dos documentos produzidos e 
erros nos códigos), ou seja, trata-se de um pente fino 
por todas as fases e todos os processos do projeto�
8
As revisões são saudáveis e benéficas ao projeto, 
pois cada erro corrigido antes do fim do projeto eco-
nomiza tempo e dinheiro� Por sua vez, as avaliações 
automáticas são realizadas segundo o acompanha-
mento de indicadores quantitativos no processo de 
desenvolvimento�
No controle de qualidade de software, as revisões 
têm como foco corrigir e excluir os erros antes da 
entrega final do produto. Por exemplo, podemos 
recorrer às inspeções de software com base nos 
critérios de entrada e saída do sistema�
O que é gerência de qualidade de 
software?
Não há como atender ao cliente de forma desorgani-
zada� É preciso atender aos padrões de desenvolvi-
mento e qualidade,por isso, a ISO criou as normas de 
qualidade� A área de gestão de qualidade de software 
integra todos os itens de gestão para conduzir o de-
senvolvimento do produto� Geralmente, esses itens 
seguem os modelos de gestão de projetos do Project 
Management Body of Knowledge (PMBOK), e pode 
usar também metodologias ágeis, como o Scrum�
A adoção de metodologias em projetos traz vários 
benefícios, como:
 ● Garantia no atendimento total a requisitos de de-
sempenho e funcionais�
 ● Garantia de que os processos de desenvolvimento 
serão realizados conforme os padrões estabelecidos�
9
 ● Garantia da diminuição de erros durante o projeto�
 ● Garantia da diminuição de erros durante as etapas 
de desenvolvimento�
 ● Garantia da diminuição e extinção de atrasos na 
entrega do produto�
 ● Garantia da prevenção e do controle dos riscos�
 ● Garantia da manutenção do produto�
O gerenciamento na qualidade de software traz be-
nefícios como:
 ● Diminuição e exclusão de defeitos: o controle de 
qualidade de software, quando aplicado e gerido 
corretamente, tem o objetivo de diminuir os resul-
tados negativos de um produto� Com isso, as fases 
do projeto de desenvolvimento de software têm seu 
cronograma cumprido em tempo correto, com se-
gurança e sem falhas de grau de criticidade alto, 
tanto para o negócio do cliente quanto para a so-
brevivência do sistema� A falta de gerenciamento 
e gestão de projetos gera a corrida contra o tempo 
e retrabalho, que consiste em corrigir os erros para 
manter o sistema em pé, ou seja, acabando gerando 
prejuízos� A falta de controle dentro de um projeto 
coloca todos os esforços de projeto e operacionais 
para evitar o caos�
 ● Confiabilidade: testes e diminuição das falhas 
geram um sentimento de satisfação dos clientes, 
criando assim um laço de confiança quanto à utiliza-
ção das aplicações� Uma vez testado e suas falhas 
10
diminuídas, controladas e excluídas, o sistema criado 
chegou ao seu objetivo� Os testes contribuem com 
muita confiabilidade no produto, pois quanto mais 
se testa, mais falhas são encontradas e corrigidas 
antes de entrar em produção�
 ● Redução de custos: conforme estudamos anterior-
mente, a adoção de qualidade, metodologia, normas, 
testes e controle diminui o custo do projeto�
 ● Maior produtividade: enquanto as falhas atrapa-
lham a vida de todos envolvidos em um projeto de 
desenvolvimento de software, a produtividade é a 
chave do sucesso� Observe, porém, que não exis-
te produtividade sem comprometimento de toda a 
equipe. Um grupo eficiente tem de se envolver e ser 
gerido de forma que funcione como uma orquestra� A 
gestão de qualidade de software visa a fazer com que 
a equipe trabalhe dessa maneira� Seguir as normas 
e a metodologia escolhida, controlar, evitar defeitos, 
respeitar as fases, os ciclos de vidas e os processos 
facilitam a condução do projeto e a geração de um 
produto de qualidade�
 ● Satisfação dos clientes: qualidade de software visa 
a entregar software sem problemas para os clientes� 
Quando isso ocorre, o cliente passa a confiar tanto 
no produto quanto na empresa que o produziu� Um 
cliente insatisfeito não contrata novamente a empre-
sa que falhou com ele na primeira chance� Portanto, 
uma boa gestão gera um bom produto e um cliente 
satisfeito� Pense nisso!
Na Figura 2, temos o mapa mental da ISO 25000, que 
trata da qualidade do produto de software:
11
Qualidade em uso
SQuaRe
Efetividade Eficiência
• Utilidade
• Confiança
• Prazer
• Conforto
Satisfação
• Completude do 
contexto
• Flexibilidade
Cobertura do contexto
• Mitigação do risco 
econômico
• Mitigação dos riscos 
de saúde e segurança
• Mitigação do risco 
ambiental
Ausência de Risco
Figura 2: Qualidade do software. Fonte: Elaboração Própria.
Medidas de Qualidade
Como podemos garantir um produto quando não há 
possibilidade de medir a qualidade? Como sabemos 
se o que fizemos foi bem feito?
Medir é essencial e medir os processos está direta-
mente relacionado ao resultado� Essa máxima serve 
para qualquer área, sendo assim, na engenharia de 
software não podia ser diferente�
Descobrir problemas ou encontrar falhas é o cerne 
da busca por melhorias no processo de desenvolvi-
mento, não importando precisamente o modelo a ser 
seguido� Só é possível corrigir falhas se os processos 
forem medidos. E as métricas podem ser classifi-
cadas como de controle ou preditivas (PRESSMAN; 
MAXIM, 2016)�
As métricas de controle são atreladas ao processo 
de software; por sua vez, as métricas preditivas são 
atreladas ao produto de software� No entanto, am-
12
bas influenciam na tomada de decisão da gestão e 
possibilitam a indicação de um produto de qualidade, 
pois medem a produtividade de pessoas, a eficácia 
do processo de desenvolvimento, os benefícios do 
produto, além de gerarem indicadores que vão nos 
mostrar se o caminho tomado é o certo ou errado�
Segundo Humphrey (1999), as decisões tomadas 
com base em indicadores confiáveis, geram quali-
dade e confiabilidade. Basicamente, os indicadores 
giram em torno de produtividade e qualidade� Esses 
dois tópicos acabam por gerar os indicadores de 
melhoria do produto� Podemos dizer que esses in-
dicadores de qualidade de softwares determinam:
 ● A qualidade do produto�
 ● A produtividade dos desenvolvedores�
 ● A eficácia da metodologia adotada.
Com isso, somos capazes de dividir as métricas de 
desenvolvimento de software em duas categorias: 
as medidas diretas e as indiretas� Por exemplo, nas 
medidas diretas temos o esforço, o custo, a veloci-
dade de execução, a memória, o número de erros e 
a complexidade condicional� Nas medidas indiretas, 
temos a funcionalidade, a qualidade, a complexidade, 
a eficácia, a confiabilidade e a manutenibilidade.
REFLITA
O que não se mede não se gerencia�
Essa máxima fez sucesso por conta de Peter 
Drucker, mas na verdade ela foi proferida por W� 
13
Edwards Deming, que realmente faz parte das 
organizações em todo o mundo� Uma empresa 
que não trabalha com indicadores não existe, e 
isso é muito forte. Ter indicadores significa ter 
um diferencial no mercado, pois a empresa tem 
que entender os momentos por que passa, como 
estão suas finanças e como é seu diferencial no 
mercado�
Se não existem métricas, indicadores ou acom-
panhamento para isso, a empresa fica para trás. 
O mesmo acontece com os projetos de desenvol-
vimento, que têm um começo, um meio e um fim, 
além de como fazer tudo isso acontecer�
Qualidade estrutural
Temos de ter cuidado com a estrutura do programa, 
pois não basta escrever um código de programa à 
revelia� É preciso criar uma estrutura lógica, para 
isso, necessita de modularização, usabilidade e con-
tinuidade, que são fundamentais para garantir que 
um código programado seja útil, fácil de entender e 
de manutenção acessível — que o torna interessante 
por ser possível integrar com outros programas ou 
que possa ser melhorado por outras funcionalidades 
sem prejudicar suas funções básicas�
Nesse aspecto, é fundamental trabalhar com desen-
volvedores profissionais e especialistas de negócio, 
visto que um bom código, escalável e limpo, só se 
produz quando condiz com as regras do negócio�
14
Para atestar a qualidade dos softwares com qualida-
de estrutural, é necessário que o código seja testável, 
que tenha funções claras e limpas e que cumpram 
os requisitos do sistema� Um código produzido que 
não tenha tais condições de teste pode comprometer 
a qualidade funcional de um software�
Qualidade funcional
Com seu foco no desenvolvimento, no que diz respei-
to à programação, a qualidade funcional visa a esta-
belecer a qualidade no código de programa gerado, 
bem como verificar o quão eficaz ele se torna na apli-
cação. Os usuários são os que mais se beneficiam 
com a qualidade funcional, pois medirão usabilidade, 
performance e confiabilidade do sistema.
Para que um software atinja o objetivo de sua cria-
ção, é fundamental que esteja em consonância com 
o que foi encomendado pelo cliente, emtodas as 
fases de desenvolvimento do projeto�
 Além da garantia de cumprimento dos requisitos, 
é preciso que a performance do software fique de 
acordo e que o produto seja confiável. Em outras pa-
lavras, que o software tenha o mínimo de erros e uma 
garantia de conserto� Não é necessário citar interface 
amigável, programação modular e código produzido 
de forma que tenha continuidade por muito tempo�
Qualidade de processo
Neste tópico, a metodologia é realmente aplicada, 
visto que o processo deve ser o mais conciso e equi-
15
librado possível para que o projeto caminhe tran-
quilamente� O impacto das falhas no projeto afeta 
diretamente o prazo de entrega, nesse sentido, são 
os clientes os mais prejudicados� 
Os prazos de entrega impactam diretamente na parte 
financeira do projeto e causam um desapontamento 
enorme no cliente, porque, além de pagar mais, não 
receberá no prazo que contratou�
A comunicação durante o projeto exerce um papel 
primordial, pois a sinergia entre a equipe de projeto 
e o cliente deve ser clara, concisa, sem ruídos e em 
tempo total� A gestão de qualidade de software tra-
balha de maneira bem contundente, pois, de acordo 
com que acontece, é possível negociar um prazo 
adequado para cada fase e para cada correção, quan-
do houver�
A entrega é o ponto crucial para a qualidade de pro-
cesso� Não basta entregar, mas a entrega precisa 
ser firme, ter qualidade e atender à solicitação do 
cliente� Mudanças podem ocorrer no meio do proje-
to, mas é necessário que a gestão de processos de 
qualidade de software saiba trabalhar com prazos 
e com processos para que o cliente fique satisfeito 
e não seja prejudicado no final.
Boas Práticas em Qualidade de 
Software
A fim de resumir o processo, podemos dizer que o 
desenvolvimento de um software funciona assim: 
16
estruturar um código, desenvolver, testar, validar, cor-
rigir erros e entregar� Melhorar o código, adicionar 
artefatos, incrementar rotinas e dar vida extra ao 
software� Seria fácil se não houvesse outros itens e 
cenários que não contribuem para a implementação 
e continuidade de um software�
Portanto, além de promover um bom desenvolvi-
mento, um produto de qualidade precisa trabalhar 
com boas práticas na condução de um projeto de 
software�
Acesse o Podcast 1 em módulos
Desenvolvimento iterativo de software
A base de um desenvolvimento iterativo e incremen-
tal é recente, visto que surgiu no contexto das meto-
dologias ágeis� Diferentemente do Modelo Waterfall 
(ou modelo em cascata) de gerenciamento de proje-
tos, as fases do projeto podem acontecer simultanea-
mente� Pensemos em um projeto de desenvolvimento 
de software para web�
Vamos pensar no modelo cascata� Primeiro, inicia-
-se o desenvolvimento depois de especificar tudo 
que você quer nesse software, pois a metodologia 
preconiza que a sequência das fases de um software 
são definição de requisitos, detalhamento e especi-
ficação, codificação, teste e produção.
Agora, vamos pensar no modelo iterativo, cujo ciclo 
de vida do projeto é diminuído ao menor número 
17
possível, porque as fases são fatiadas e conduzidas 
concomitantemente, ou seja, ao mesmo tempo�
Quanto à documentação de software, temos novi-
dades no modelo iterativo, pois não há regra de do-
cumentação, é estruturada e aperfeiçoada ao longo 
do projeto� Mas a documentação precisa de três 
elementos primordiais:
 ● Contextualização de problema: cada problema 
deve ser relatado, não importando o tamanho ou o 
impacto no projeto�
 ● Contextualização de solução: toda solução dada 
deve ser detalhada, do mesmo modo que toda mo-
dificação no código deve ser explicada. As fases 
servem para alimentar umas às outras�
 ● Detalhes técnicos: referem-se aos responsáveis 
por partes do desenvolvimento, sobre o que foi feito, 
quando foi feito e de que modo foi feito� Esse docu-
mento precisa ser lido por várias áreas, as quais têm 
de especificar o que fizeram (arquitetura de software, 
desenvolvimento e programação etc�)�
Documentar é parte primordial do processo de desen-
volvimento� Por essa razão, elaboramos dicas para 
que você desenvolva um processo de documentação 
eficiente:
1. É preciso criar estrutura e suporte para esses 
documentos: A princípio, é preciso encontrar uma 
maneira de preparar e guardar os documentos, mes-
mo antes de o projeto acontecer� O ideal é encontrar 
meios automatizados e com graus de hierarquia para 
18
fazer esse documento transitar pelos níveis em que 
vai ser usado�
2. Defina papéis e responsabilidades: Coloque to-
dos em seus respectivos lugares, os desenvolvedores 
vão escrever sobre os frameworks, o arquiteto de 
softwares vai escrever sobre a arquitetura do projeto 
e, assim, acontece com todos os outros funcionários 
alocados no projeto�
3. Escolha a ferramenta correta para documenta-
ção: É primordial para economizar tempo� Pastas 
dentro de pastas sem definição acabam com qual-
quer projeto� As Wikis são um excelente recurso 
para organizar documentação� Os serviços Trello e 
Jira racionalizam o backlog e criam sprint e fases de 
fácil entendimento�
4. Guarde as informações com lógica adequada: 
Quando do uso da nuvem para armazenamento, é 
fundamental que o controle de acesso seja bem feito 
e tenha backup de toda a documentação�
5. Use a documentação: É um conselho meio óbvio, 
mas há muita documentação de sistema que não 
é bem aproveitada� É um recurso para pesquisas e 
ajustes de modo acertado, histórico de desenvolvi-
mento, artifícios para as reuniões sobre o desenvol-
vimento de uma aplicação�
6. Tenha um bom ambiente dentro da equipe: A siner-
gia e o bom entrosamento de uma equipe é o que faz 
do projeto ser bem-sucedido ou não� Uma boa docu-
mentação melhora muito os processos, mas isso só 
19
vai acontecer se toda a equipe estiver comprometida 
em manter o processo de documentação em dia�
SAIBA MAIS
Saiba mais sobre tudo que não podemos fazer 
no desenvolvimento de um software, assistindo a 
https://www.youtube.com/watch?v=QPiR8jTMLdI�
Por que usar validação de software?
Precisamos entender, antes, o que é validação de 
software� Trata-se do processo que prova que a do-
cumentação bate com o que foi entregue em termos 
de sistemas. Ou seja, é o processo que verifica se 
o produto entregue cumpre com as especificações 
dos requisitos, se tem garantia de funcionamento e 
rastreabilidade das informações�
É importante optar pelo processo de validação e ado-
tar as boas práticas para evitar danos aos clientes, 
assim como à imagem da empresa� Podemos citar 
o caso do seguimento de medicamentos, no qual 
alguns sistemas são validados com vistas a garantir 
sua função� Isso pode acontecer em qualquer segui-
mento de negócio� Quanto à área de medicamentos, 
o órgão regulador tem um guia que ajuda a indicar o 
que um sistema precisa e o que ele precisa validar�
O mesmo processo ocorre com bancos ou siste-
mas de saúde, os quais têm condições próprias do 
seguimento de atuação para que o software valide 
20
https://www.youtube.com/watch?v=QPiR8jTMLdI
informações, como normas para que o uso e a ras-
treabilidade sejam requisitos desses sistemas e que 
funcionem de maneira eficaz.
Como fazer a validação de software?
A verdade é que não existe um modelo próprio para 
a validação de software� Cada empresa recorre a um 
plano de validação de acordo com as suas políticas� 
Ainda assim, mesmo sem um plano de validação, 
alguns documentos são citados em algumas normas 
ISO e podem fazer parte do plano de validação de 
qualquer empresa:
 ● User Requirement Specification (URS).
 ● Functional Requirement Specification (FRS).
 ● Installation Qualification (IQ).
 ● Operational Qualification (OQ).
 ● Performance Qualification (PQ).
Para entender a validação dos sistemas, é importante 
que se entenda o ciclo de vida de um sistema com 
quatro fases:
 ● Conceito�
 ● Projeto�
 ● Operação�
 ● Descontinuidade�
O ciclo de vida é o esqueleto de um projeto de sof-
tware, pois é a estrutura que detalha as atividadesque os processos contêm, as tarefas envolvidas nes-
sas atividades, o detalhe das tarefas, o impacto na 
21
operação, a implantação e os resultados, é um mapa 
da vida do sistema da sua criação até a sua opera-
cionalização� Trata-se, portanto, de dar corpo à ideia 
do software depois do levantamento de requisitos�
É o modelo que vai definir como trabalhar e entregar 
ao cliente aquilo que se propôs a fazer, por isso, o 
processo de software consiste em um grupo de ativi-
dades e compõe um sistema computacional� Essas 
atividades também são compostas de fases como 
definição de requisitos, análise, projeto, desenvol-
vimento, teste e implantação� Cada fase divide-se 
conforme as atividades, profissionais responsáveis 
e produtos esperados�
Com a evolução da tecnologia e a crescente neces-
sidade de softwares pelo mercado, as práticas posi-
tivas passaram a ser replicadas e transformaram-se 
em modelos de ciclo de vida� Tais fases nada mais 
são do que as estruturas predefinidas em que en-
quadramos as fases do processo�
Conforme preconiza a ISO/IEC 12207:1998, define-
-se o ciclo de vida como a estrutura de todo projeto 
de software, que engloba tudo desde a criação ao 
término de uso� Para entendermos melhor o ciclo de 
vida de um sistema, a Figura 3 ilustra o processo� 
Note, contudo, que não se deve confundir ciclo de 
vida com método de desenvolvimento de software�
22
Ciclo de vida
do produto
Ciclo de vida 
do projeto
Operações e 
disposição
Plano de 
negócio
Produto
Ideia
Início
Execulção
Operação
Final
Atualização
Figura 3: Ciclo de vida do projeto. Fonte: Wikimedia
Há uma maneira de comportamento nos ciclos de vida:
 ● Sequencial: as fases têm uma determinada ordem�
 ● Incremental: as fases são fatiadas�
 ● Iterativa: é a retroalimentação de fases�
 ● Evolutiva: o software é melhorado� 
Temos como modelos os seguintes ciclos de vida:
 ● Cascata�
 ● Modelo em V�
 ● Incremental�
 ● Evolutivo�
 ● RAD�
 ● Prototipagem�
 ● Espiral�
 ● Modelo de Ciclo de Vida Associado ao RUP�
23
https://commons.wikimedia.org/wiki/File:Ciclo_de_vida.png
Contudo, abordaremos os três mais usados:
 ● Modelo Cascata: criado em 1966 e normatizado 
em 1979, é um dos modelos mais tradicionais que 
temos, pois usa fases sequenciais e só termina quan-
do todas as fases terminam� Só é possível passar 
de fase quando a atual for concluída� É um processo 
dinâmico porque não tem fases retroativas, o que 
impacta no tempo do projeto� Como benefício, po-
demos citar a facilidade de gestão, porque tem uma 
ordem, e as fases são feitas uma a uma (Figura 4)�
Projeto de sistemas e 
de software
Integração e teste 
de sistemas
Implementação e teste
de unidade
Análise e definição 
de requisitos
Operação e
manutenção
Figura 4: Funcionamento do modelo cascata. Fonte: Elaboração própria.
 ● Modelo Evolutivo: é um modelo aberto a mudanças 
e inovações, que busca melhorar o produto durante 
a criação� Seu foco é o cliente, portanto, a interação 
com o cliente é considerável� Seu ponto negativo é 
o limite do projeto que pode aumentar quando as 
mudanças são muitas (Figura 5)�
24
Descrição do
esboço
Versão
inicial
Versão
final
Versões
intermediárias
Especificação
Desenvolvimento
Validação
Figura 5: Processo do modelo evolutivo. Fonte: Elaboração própria.
 ● Modelo Incremental: é a evolução da modelo cas-
cata� Neste, o projeto é dividido em etapas até o 
final. Serve bem para casos em que os requisitos 
não estejam totalmente claros e alinhados� Se há 
falhas no caminho, o último incremento é descartado� 
A entrega também é feita por incrementos, muitas 
vezes disponibiliza antes do prazo as entregas aos 
clientes (Figura 6)�
Definir 
esboço dos 
requisitos
Projetos 
arquitetura 
do sistema
Projetos 
arquitetura 
do sistema
Atribuir 
requisitos 
aos 
incrementos
Validar
incremento
Integrar
incremento
Validar
sistema
Sistema
final
Figura 6: Processo modelo incremental. Fonte: Elaboração própria.
25
Personal Software Process
Personal Software Process, mais conhecido como 
PSP, pode ser definido como aquilo que foi projetado 
para o desenvolvimento de software individual, para 
engenheiros de softwares, para criação de projetos 
individuais (HUMPHREY, 1995)�
Por ter sido criado para projetos individuais, seu foco 
recai sobre os pequenos projetos com qualidade� 
Assim, tem sido aproveitado em outras áreas além 
da engenharia de software, em algumas áreas como 
requisição de software, testes e especificação, ou 
seja, é um processo mais aberto�
Foi projetado para ser aplicado em sistemas peque-
nos, mas pode ser usado na construção de módulos 
de projetos maiores� Funciona como uma alça do 
CMMI e tem por premissa a revisão contínua de cada 
fase de desenvolvimento� Enquanto o CMMI visa à 
melhoria da organização, o PSP volta-se ao desen-
volvedor individual (HUMPHREY, 1997)�
Com isso, é dedicado a melhorar os prazos e trabalho 
para o desenvolvimento, melhorar o acompanha-
mento e planejamento do cronograma, acabar com 
o excesso de pressão dos prazos, criar no desenvol-
vedor comprometimento com a melhoria contínua e 
a qualidade, melhorar a capacidade de organização 
do desenvolvedor de maneira que cause impacto na 
organização�
Em síntese, temos os itens que são foco do PSP:
26
 ● Melhorar o planejamento e o acompanhamento 
de cronogramas�
 ● Evitar o excesso de compromissos�
 ● Criar um comprometimento pessoal com a quali-
dade e com a melhoria contínua do processo�
Por ser uma parte do CMMI, é constituído também 
de níveis, de qualidades próprias (Tabela 1):
Nível Nome Atividades
PSP0
Medição 
pessoal
Registro de tempo
PSP0�1 Registro de defeitos
Padrão de tipos de defeitos
Padrão de codificação
Medida de tamanho
Proposta de melhoramento do 
processo
PSP1
Planejamento 
pessoal
Estimativa de tamanho
PSP1�1 Relatório de testes
Planejamento de tarefas
Cronogramas
PSP2
Qualidade 
pessoal
Revisões de código
PSP2�1 Revisões de projeto
Padrões de projeto
PSP3 Processo 
cíclico 
pessoal
Desenvolvimento cíclico
Tabela 1: Fonte: Elaboração própria.
 ● Medição pessoal: momento em que se mede e 
registra o tempo utilizado em cada etapa do ciclo 
do desenvolvimento, mas também são apontadas 
as falhas encontradas�
27
 ● PSP0.1: tem o uso do padrão de codificação, medi-
das padronizadas e uma proposta de melhoramento 
do processo (formulário)�
 ● Planejamento pessoal: organização é a palavra-
-chave� Trata-se de um planejamento por meio do 
qual será possível estimar o tempo de cada tarefa 
segundo os indicadores anteriores de tarefas seme-
lhantes� Neste tópico, os compromissos ganham 
forma e prazo para acontecer�
 ● PSP1.1: se, no planejamento pessoal, a palavra-
-chave é organizar, neste módulo a palavra-chave é 
organizar e distribuir� A distribuição ocorre por meio 
do planejamento das tarefas, e a distribuição dos 
prazos nos cronogramas�
 ● Qualidade pessoal: tópico em que encaramos os 
erros; é necessário pelo menos entender e saber 
quantos erros existem em cada fase do ciclo de de-
senvolvimento e providenciar as correções� A ideia 
do PSP é que os erros sejam evitados desde sua 
origem� Portanto, se há erros, um checklist deve ser 
feito com a finalidade de ser utilizado nas revisões 
do projeto e do código de desenvolvimento�
 ● PSP2.1: entramos a criação de padrão de projeto, 
metodologia de análise e prevenção de defeitos�
 ● Processo cíclico pessoal: saímos do desenvolvimen-
to dos pequenos projetos e fomos para os projetos 
maiores, mesmo que em um nível modular e pessoal� 
Trata-se da última etapa do PSP, na qual dividimos o 
projeto grande em pequenos projetos que são tratados 
no PSP2� Todo processo agora é incremental�
28
Entregas a caminho, é hora de treinar o pessoal� 
O treinamento do PSP é feito em 10 exercícios de 
desenvolvimento de programas� São pequenos uti-
litários que funcionam como exemplos de desen-
volvimento e, por isso, ajudam a medir objetos no 
programa, calcular desvios, prever intervalos etc�
Esse processode desenvolvimento nos traz algumas 
lições:
 ● Lição 1. A estratégia tem como base definir, men-
surar e monitorar seu próprio trabalho de maneira 
possível e prática, com ferramentas e critérios à 
disposição� O desenvolvedor vai aprender com as 
próprias experiências�
 ● Lição 2� Conhecimento e experiência geraram 
métodos e práticas para próximos projetos� Logo, 
ganhará habilidades e empregabilidade�
Essas lições são possíveis graças a alguns princípios 
do PSP:
 ● Melhoria do trabalho por meio de processo definido 
e estruturado�
 ● Ajustes de lições aprendidas por meio de proces-
sos individuais, os quais podem se transformar em 
habilidades e agregar facilidades em outros projetos 
similares�
 ● Envolvimento do profissional desde a concepção 
do software� Os processos evoluem e, juntamente 
com eles, as habilidades e facilidades profissionais.
 ● Feedback para promover a melhoria contínua� 
29
 ● Quanto à produtividade, observou-se que houve 
uma baixa de produtividade no começo, pois havia 
tarefas não utilizadas na programação, mas durante 
a evolução do projeto a produtividade melhorou, em 
conformidade com o tamanho do desenvolvimento�
Team Software Process
O intuito da criação dessa estrutura é auxiliar as equi-
pes de projetos a organizar e produzir softwares� O 
Team Software Process (TSP) foi criado para direcio-
nar o planejamento e o desenvolvimento de pequenos 
softwares ou módulos de grandes programas, mas 
pode também ser adequado a outras tarefas�
Seu foco principal é melhorar a qualidade e a pro-
dutividade de projeto de acordo com os níveis de 
maturidade do desenvolvimento, para que os custos e 
os compromissos sejam cumpridos da melhor forma 
possível� Em outras palavras, é o marco inicial para 
que sistemas sejam criados a partir de premissas 
de qualidade dentro dos prazos�
O trabalho em equipe é o centro de tudo, embora 
não seja uma tarefa fácil criar e gerir uma equipe 
de ponta, eficiente e produtiva (FERNANDES, 2004). 
O Software Engineering Institute (SEI) criou o mo-
delo, por não existir nenhum direcionado a equipes 
de desenvolvimento� Nesse sentido, o TSP e o PSP 
caminham juntos para orientar o trabalho individu-
al dos desenvolvedores de software, com métricas 
30
do seu trabalho e melhoria de desempenho de suas 
atividades�
 Segundo Humphrey (1999), TSP é um framework 
de trabalho em equipe que enfatiza o processo e o 
produto, priorizando o planejamento e o gerencia-
mento de projetos� Para isso, o TSP usa o modelo 
espiral para o desenvolvimento e divide o processo 
em ciclos (SOMMERVILLE, 2018)�
Os métodos estão prontos como modelos, basta 
utilizá-los� Eles podem ser utilizados novamente 
em outros ciclos, diminuindo o tempo do projeto� 
De acordo com Humphrey (1999), oito fases com-
põem o ciclo de desenvolvimento do TSP:
1. Lançamento
2. Desenvolvimento de estratégia
3. Planejamento
4. Requisitos
5. Projeto
6. Implementação
7. Testes
8. Avaliação
Quanto à documentação, existem muitos padrões 
prontos de documentos para qualquer fase e ciclo 
de desenvolvimento do projeto, assim como para o 
projeto em si, como para performance dos desen-
volvedores, e essa documentação serve para fun-
damentar todo o projeto e tirar as melhores lições�
31
Quanto aos indicadores, há também uma padroniza-
ção de scripts de processos e formulários� Inclusive, 
há padronização e um formulário para o plano de 
qualidade, ou seja, o TSP veio organizar e facilitar o 
pequeno projeto do time que vai desenvolvê-lo�
Information Technology 
Infrastructure Library
Para compreender, é preciso saber o seu signifi-
cado, bem como o fato de que ele nasceu como 
uma biblioteca e evoluiu para uma metodologia� O 
Information Technology Infrastructure Library (ITIL) 
é uma Biblioteca de Infraestrutura de Tecnologia da 
Informação� Em Tecnologia da Informação, biblioteca 
nos remete à programação� Porém, no ITIL o sentido 
é literal, ou seja, trata-se de uma coleção de livros�
Esses livros referem-se a um conjunto de normas, 
maneiras e boas práticas para a otimização da ges-
tão de serviços de TI� Assim, é uma estratégia que 
traz vantagens competitivas, pois sua implantação 
tem os seguintes resultados:
 ● Redução de custos 
 ● Autonomia e agilidade nos processos
 ● Racionalização de processos
 ● Alinhamento com os negócios da empresa
São sete livros que trazem a receita da gestão perfei-
ta da TI, com os quais o ITIL se tornou um diferencial 
de mercado para os profissionais que se especializa-
32
ram nessa metodologia� A detentora da metodologia 
é a AXELOS, a maior referência em ITIL no mercado 
e a responsável por sua certificação.
Os livros do ITIL se dividem em blocos de melhores 
práticas segundo o serviço implantado dentro da 
TI, ou seja, são um conjunto de melhores práticas e 
podem ser implantados por áreas dentro da TI, por 
exemplo:
 ● Service Support (suporte a serviços)
 ● Service Delivery (entrega de serviços)
 ● Infrastructure Management (gerenciamento de 
infraestrutura)
 ● Planning to implement ITSM (planejamento de im-
plementação do gerenciamento)
 ● Business Perspective (perspectivas de negócio)
 ● Application Management (gerenciamento de 
aplicação)
 ● Security Management (gerenciamento da 
segurança)
Visto que sua adoção leva a profundas mudanças 
na TI, há mudanças culturais muito grandes no que 
tange à TI, portanto, a metodologia deixa claro que 
a alta direção tem de patrocinar o projeto e comprar 
a ideia�
Muitas pessoas saem de suas zonas de conforto, 
com isso, problemas podem surgir� Se a alta direção 
não comprar a ideia, a implantação pode não ocorrer 
ou ainda, se for implantado, corre o risco de fracasso 
ao longo do tempo�
33
É importante esclarecer que ITIL e Gestão de Projetos 
não são a mesma coisa� O ITIL traz um novo conceito 
de trabalho para área de TI; a Gestão de Projetos trata 
de projetos pontuais, com um começo, meio e fim.
E qual é o impacto do ITIL dentro de qualidade de 
software, se seu foco não é a criação de produtos?
A metodologia cria um ambiente propício para o 
desenvolvimento de sucesso, pois a aplicação das 
melhores práticas para o fornecimento de serviço 
organiza a empresa, a gestão e o desenvolvimento 
fluem com mais facilidade, pois há processos esta-
bilizados de gerenciamento�
Acesse o Podcast 2 em módulos
Cobit
O Cobit é um framework criado pela Associação 
de Auditoria e Controle de Sistemas de Informação 
(Isaca), que aproxima a Gestão de TI e Governança 
Corporativa� Note que o conceito de TI aqui já não é 
mais de suporte, e sim de área estratégica de negócio, 
tal qual a Governança Corporativa traz os conceitos de 
transparência, equidade, responsabilidade e prestação 
de contas, a TI passa a ter Governança de TI, adotando 
assim os conceitos da Governança Corporativa�
Esse conceito representa os processos dentro do 
trabalho realizado pela TI, enquanto o ITIL foca no 
gerenciamento dos processos de negócio dentro da 
TI, unindo a parte operacional com a parte de negó-
34
cios� Toda a metodologia é permeada de controles� 
Portanto, na TI os controles se interligam aos pro-
cessos de TI, isto é, Governança de TI� Os principais 
componentes do Cobit são:
 ● Framework TI: direciona o foco da Governança de 
TI nos processos da TI atrelados aos processos e 
requisitos de negócio da empresa�
 ● Descrições de processo: na empresa, funcionam 
como referência de descrição dos processos; inse-
rem-se nesse contexto o planejamento, a construção, 
a execução e o monitoramento dos processos de TI�
 ● Objetivos de controle: é praticamente um mapa 
para os controles de gerenciamento de TI�
 ● Modelos de maturidade: são modelos para a me-
lhoria de processo�
 ● Diretrizes de gerenciamento: são diretrizes para a 
atribuição de responsabilidades, como fazer e das 
melhorias contínuas�
Resumindo, o Cobit funciona como um integrador 
que trabalha para suprir as deficiências relativas aos 
requisitos de controle, questões técnicas e ricos de 
negócio, promovendouma maior interação entre 
áreas� Como é baseado em Governança, as suas 
políticas e boas práticas são tanto para as empresas 
em geral quanto para os departamentos de TI� Tem a 
vantagem da integração e harmonização com outros 
padrões e guias, com ISO, ITIL, CMMI�
A sua estrutura de processos e o foco de um outro 
patamar aos negócios dão uma visão global da TI; 
são fatores que contribuem nas tomadas de decisão, 
35
portanto, há vantagens de usá-lo como um modelo 
de governança de TI� Tal processo inclui:
 ● Aceitação e concordância com órgãos reguladores 
e terceiros
 ● Alinhamento com o negócio 
 ● Entrosamento e transparência entre as áreas 
interessadas
 ● Mudança da visão da TI dentro da empresa e 
diretoria 
 ● Uma divisão transparente de tarefas e atribuições 
de acordo com as responsabilidades de cada função
 ● Cumprimento dos requisitos do Committe 
of Sponsoring Organisations of the Treadway 
Commission’s Internal Control – Integrated 
Framework para controle do ambiente de TI� 
O Cobit tem vários componentes, quatro domínios e 
34 processos de TI referentes a essa metodologia� 
Com isso, os domínios podem ser definidos como as 
áreas direcionadas para planejar, construir, executar 
e monitorar, provendo um panorama total da área de 
TI. Podemos defini-los como:
 ● Planejar e organizar� Dá o objetivo para a entrega 
de soluções, (AI) e entrega de serviços (DS) recebem 
as soluções e as adaptam de acordo com os usuários 
finais. Trabalha-se com a definição do planejamento 
estratégico da TI, ou seja, com a arquitetura, investi-
mentos, riscos, projetos e qualidade�
 ● Aquisição e implementação� Gera soluções e as 
direciona ao público correto, entrega serviços e é 
36
responsável por automatizar ou reaproveitar proces-
sos dentro da organização, manutenção de sistema 
e infraestrutura, mapeamento de desenvolvimento de 
procedimentos para sistemas, instalação e gerência 
de mudanças�
 ● Entregar e suportar. Definição dos níveis de ser-
viços, hierarquia de usuários finais, treinamento e 
repasse de informações a usuários finais. Garantia 
de continuidade, desempenho e segurança de sis-
temas, alocação de custos problemas e incidentes�
 ● Monitoramento/monitorar� É responsável pelo mo-
nitoramento de todos os controles da TI em conso-
nância com a organização�
O Cobit fornece à Tecnologia da Informação o lugar 
estratégico na empresa pois tem como base os pen-
samentos e as técnicas de governança corporativa, 
isto é, usa princípios, práticas, ferramentas analíticas 
e modelos aceitos globalmente para ajudar a aumen-
tar a confiança e o valor dos sistemas de informação.
37
CONSIDERAÇÕES FINAIS
A Qualidade de Software depende de algumas va-
riáveis para se fazer valer� Entender o processo, o 
ciclo de vida e as metodologias faz parte da gestão 
da qualidade de software, que busca entregar o me-
lhor produto, com custo acordado e dentro do prazo 
determinado�
Para isso, no entanto, é necessário o uso de boas 
práticas, não só no ambiente de desenvolvimento, 
mas também em toda a empresa para que o projeto 
flua e obtenha o sucesso almejado.
Nesse sentido, além de colaborar com o fluxo de de-
senvolvimento, devido à toda padronização proposta, 
metodologias como PSP, TSP, ITIL e Cobit também 
colaboram com o ambiente das organizações, crian-
do meios, controles e processos sólidos que facilitam 
um bom desenvolvimento e um excelente resultado�
38
SÍNTESE
ITIL
COBIT
TEAM SOFTWARE PROCESS
• Investimento e custo com qualidade 
• Controle de Qualidade
• O que é gerência de qualidade de software?
• Desenvolvimento iterativo de software
• Por que usar validação de software?
• Como fazer a validação de software?
MEDIDAS DE QUALIDADE:
BOAS PRÁTICAS DE 
QUALIDADE DE SOFTWARE
 
QUALIDADE DE 
SOFTWARE
• Qualidade estrutural
• Qualidade funcional 
• Qualidade de processo
PROCESSOS DE GESTÃO DA QUALIDADE DE SOFTWARE:
BOAS PRÁTICAS EM QUALIDADE DE SOFTWARE
PERSONAL SOFTWARE PROCESS
Referências Bibliográficas 
& Consultadas
ABNT� ASSOCIAÇÃO BRASILEIRA DE NORMAS 
TÉCNICAS� Disponível em: http://www.abnt.org.br� 
Acesso em: 22 out� 2019�
BRAGA, P� H� C� (Org�) Testes de Software� 
São Paulo: Pearson Education do Brasil, 2016 
[Biblioteca Virtual]� 
CMMI INSTITUITE� Disponível em https://cmmiins-
titute.com/� Acesso em: 22 out� 2019�
COBIT� Disponível em: http://www.isaca.org/COBIT/
Pages/COBIT-5-Portuguese.aspx� Acesso em: 01 
nov� 2019�
FERNANDES, A� A� Fábrica de Software: implanta-
ção e gestão de operações� São Paulo: Atlas, 2004�
GALLOTTI, G� M� A� (Org�)� Qualidade de Software� 
São Paulo: Pearson Education do Brasil, 2016 
[Biblioteca Virtual]� 
GOTH, G� The team software process: a quiet quali-
ty revolution� IEEE software, 2000
HUMPHREY, W� S� A discipline for software engi-
neering� Massachusetts: Addison-Wesley, 1995�
http://www.abnt.org.br
HUMPHREY, W� S� Introduction to the personal sof-
tware process� Massachusetts: Addison-Wesley, 1997�
HUMPHREY, W� S� Introduction to the team softwa-
re process� Massachusetts: Addison-Wesley, 1999� 
ITIL� Disponivel em https://www.axelos.com/best-
-practice-solutions/itil, acesso em 02/11/2019�
PAULA FILHO, W� P� Engenharia de Software: 
fundamentos, métodos e padrões� 3� ed� Rio de 
Janeiro: LTC, 2009 [Minha Biblioteca]� 
PFLEEGER, S� L� Engenharia de Software: teoria 
e prática� 2� ed� São Paulo: Prentice Hall, 2004 
[Biblioteca Virtual]�
PRESSMAN, R� S�; MAXIM, B� R� Engenharia de 
Software: uma abordagem profissional� 8� ed� 
Porto Alegre: AMGH, 2016 [Minha Biblioteca]� 
SCHACH, S� R� Engenharia de Software: os para-
digmas clássico e orientado a objetos� 7� ed� Porto 
Alegre: AMGH, 2010 [Minha Biblioteca]� 
SOMMERVILLE, I� Engenharia de software� 10� 
ed� São Paulo: Pearson Education do Brasil, 2018 
[Biblioteca Virtual]�
WINDER, R� ROBERTS, G� Desenvolvendo Software 
em Java� 3� ed� Rio de Janeiro: LTC, 2009 [Minha 
Biblioteca]�
	INTRODUÇÃO
	Gestão da qualidade de software
	Processos
	Medidas de Qualidade
	Boas Práticas em Qualidade de Software
	Personal Software Process
	Team Software Process
	Information Technology Infrastructure Library
	CONSIDERAÇÕES FINAIS
	Síntese