Algoritmos Numéricos de Busca em Otimização - UNICAMP

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.
net/publication/299534437
GERENCIAMENTO DA QUALIDADE EM PROJETOS DE DESENVOLVIMENTO

DE SOFTWARE EMBARCADO
Thesis · December 2012

DOI: 10.13140/RG.2.1.1162.6641
CITATIONS READS
0 461
1 author:
Lucas Pereira Dos Santos

National Institute for Space Research, Brazil
3 PUBLICATIONS 0 CITATIONS
SEE PROFILE
All content following this page was uploaded by Lucas Pereira Dos Santos on 01 April 2016.
The user has requested enhancement of the downloaded ﬁle.

FUNDAÇÃO ARMANDO ALVARES PENTEADO
FAAP PÓS-GRADUAÇÃO
TRABALHO DE CONCLUSÃO DE CURSO
7ª Turma do Curso de Pós-Graduação Lato-Sensu em

GESTÃO ESTRATÉGICA DE PROJETOS
GERENCIAMENTO DA QUALIDADE EM PROJETOS DE

DESENVOLVIMENTO DE SOFTWARE EMBARCADO
Lucas Pereira dos Santos
Coordenador do Curso: Prof. MSc. Marcos Alberto de Oliveira

Orientador de Conteúdo: Prof. MSc. Marcos Alberto de Oliveira
Orientador de Metodologia: Profª Drª Ana Maria Irene Bartolomeu Ayrosa
São José dos Campos

2012

Monografia apresentada ao Curso de Pós-

Graduação Lato-Sensu em Gestão
Estratégica de Projetos da Fundação
Armando Alvares Penteado como parte dos
requisitos para a aprovação no curso.
Coordenador do Curso: Prof. MSc. Marcos Alberto de Oliveira

Orientador: Prof. MSc. Marcos Alberto de Oliveira
Orientador de Metodologia: Profª Drª Ana Maria Irene Bartolomeu Ayrosa
São José dos Campos

2012

Data de Aprovação: ___/___/___
Nota Final: ________
Banca Examinadora:
______________________________________
Prof. MSc. Marcos Alberto de Oliveira
Orientador e Coordenador do Curso
Fundação Armando Alvares Penteado
______________________________________
Profª Drª Ana Maria I. B. Ayrosa
Orientadora Metodológica
______________________________________
Prof. Evandro Monteiro Olivier
Professor convidado
À Embraer, por ser uma empresa motivo
de orgulho de todo povo brasileiro.
AGRADECIMENTOS
Ao Prof. MSc. Marcos Alberto de Oliveira pelo constante incentivo e orientação

durante o curso.
À Profª Drª Ana Maria I. B. Ayrosa pelos diversos e-mails esclarecedores

respondidos, que muito contribuíram na estruturação deste trabalho.
Aos colegas Fabrício José Pontes, Arturo Bittencourt Fernandez e Marília

Vidigal da Costa Souza que compartilharam seus conhecimentos e
experiências na pesquisa desta monografia.
A todos os professores do curso de Gerenciamento Estratégico de Projetos da

FAAP, pela generosidade em compartilhar seus conhecimentos.
"Ser o homem mais rico do cemitério
não importa para mim. Ir para a
cama à noite, dizendo que fizemos
algo maravilhoso... É isso que
importa para mim.”
Steve Jobs
RESUMO
A rápida evolução tecnológica vem aumentando consideravelmente a demanda

por softwares. Atualmente o grande diferencial dos produtos é a sua
inteligência por de trás do hardware. Na indústria aeronáutica não é diferente.
Com a globalização e a fusão de diversas empresas do setor, os fabricantes de
avião possuem hoje basicamente os mesmos fornecedores de hardware,
tornando assim o software o grande diferencial dos produtos.
Neste contexto, o desenvolvimento de softwares com qualidade, dentro do

prazo e do custo é fundamental para o sucesso do produto. Este trabalho
apresenta inicialmente uma pesquisa literária sobre gerenciamento da
qualidade em projetos de desenvolvimento de software, em seguida um estudo
de caso em uma empresa de desenvolvimento de software para o setor
aeronáutico, explorando seu atual processo de Gerenciamento de Qualidade e
propondo melhorias para ampliar sua abrangência.
Finalmente, são apresentadas a discussão e a conclusão, fornecendo ao leitor

a oportunidade de analisar uma comparação da literatura com um caso prático,
concluindo-se finalmente que a área de conhecimento do Gerenciamento da
Qualidade pode contribuir com o atual processo de gerenciamento de projetos
da empresa objeto deste estudo de caso.
Palavras chave: Gerenciamento de projetos. Gerenciamento da qualidade.

Desenvolvimento de software. Qualidade de software. Engenharia de software.
ABSTRACT
The technological improvement has considerably increased the software

demand. Nowadays, what differs one product from another is the intelligence
running behind the hardware. In the aeronautical industry it is not different.
Considering the globalization and the merging of several companies, all of the
big aircraft manufacturers have basically the same hardware suppliers, thus
making the software the big difference of the products.
In this context, the development of high quality software, within deadline and
cost, is essential to the success of the product. This paper initially presents a
research about Quality Management on Software Development Projects, then a
case study in a software development company for the aviation industry,
exploring its current Quality Management process and proposing improvements
in order to expand its coverage.
Finally, a discussion and conclusion are presented, providing the reader with
the opportunity to analyze a comparison between literature and a practical case,
concluding that the knowledge area of Quality Management can contribute to
the ongoing process of project management at the company studied.
Keywords: Project Management. Quality Management. Software Development.

Software Quality. Software Engineering.
LISTA DE FIGURAS
Figura 1 – Grupos de processo de gerenciamento de projetos 19

Figura 2 – Sobreposição entre os grupos de processos. 20
Figura 3 – Visão analítica do gerenciamento da qualidade do projeto 25
Figura 4 – Planejar a qualidade: entradas, ferramentas e saídas. 26
Figura 5 – Estrutura típica da documentação do Sistema da Qualidade. 27
Figura 6 – Diagrama do Fluxo de dados do processo de Realizar a Garantia da Qualidade 28
Figura 7 – Realizar a Garantia da Qualidade: entradas, ferramentas e saídas 29
Figura 8 – Realizar o Controle da Qualidade: entradas, ferramentas e saídas 31
Figura 9 – Ciclo de Vida do Software 32
Figura 10 – Etapas do Modelo em Cascata 35
Figura 11 – Etapas do Modelo em V 35
Figura 12 – Valores, Princípios e Práticas do método Ágil 38
Figura 13 – Relação entre requisitos e características em conjunto com a qualidade 40
Figura 14 – Estrutura da Qualidade de Software 40
Figura 15 – As Três Dimensões Críticas do CMMI-DEV 41
Figura 16 – Gerenciamento da Qualidade no Processo de Desenvolvimento 50
Figura 17 – Loop Gerenciamento da Qualidade no Processo de Desenvolvimento 51
Figura 18 – Tomada de Decisão baseada em métricas 55
Figura 19 – Relacionamento entre atributos internos e externos 58
Figura 20 – Custo relativo para correção de defeitos de software 59
Figura 21 – Macro processo Desenvolver ou Modificar Produto 65
Figura 22 – Estrutura organizacional dos projetos de software na Empresa Y 66
LISTA DE TABELAS
Tabela 1 – Relação da Qualidade com a Quantidade de Defeitos no produto ..................... 76

Tabela 2 – Índice de Qualidade da Torre de Controle da Empresa Y ................................... 77
Tabela 3 – Exemplo de Medição do Indicador de Qualidade de Software ............................ 98
LISTA DE QUADROS
Quadro 1 – Mapeamento de grupos de processos e áreas de conhecimento 23

Quadro 2 – Relação dos Processos de Gerenciamento da Qualidade PMI x SWEBOK 44
Quadro 3 – Atributos de qualidade de software 46
Quadro 4 – Padrões de Produto e Processo 47
Quadro 5 – Principais modelos de maturidade 48
Quadro 6 – Tipos de Métricas de Software 57
Quadro 7 – Processos da Empresa Y relacionado com as áreas de conhecimento do PMI. 83
LISTA DE ABREVIATURAS E SIGLAS
CMMI Capability Maturity Model Integration
CMMI-DEV CMMI for Development
CTA Centro Técnico Aeroespacial
DIP Desenvolvimento Integrado do Produto
EADS European Aeronautic Defense and Space Company
FAB Força Aérea Brasileira
HH Homem Hora
IPD Instituto de Pesquisa e Desenvolvimento
ISO International Organization for Standardization
ITA Instituto Tecnológico de Aeronáutica
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
PR Problemas Reportados
SCCB Software Configuration Control Board
SWEBOK Software Engineering Body of Knowledge
V&V Verificação e Validação

SUMÁRIO
INTRODUÇÃO .......................................................................................13
1 FUNDAMENTAÇÃO TEÓRICA........................................................16
1.1 Conceitos Iniciais ....................................................................................... 16
1.1.1 Projeto ................................................................................................................. 16
1.1.2 Processo .............................................................................................................. 16
1.1.3 Produto ................................................................................................................ 17
1.2 Gerenciamento de Projetos ....................................................................... 17
1.2.1 Processos do Gerenciamento de Projetos .......................................................... 18
1.2.2 Áreas de Conhecimento do Gerenciamento de Projetos .................................... 21
1.2.3 Gerenciamento da qualidade do projeto.............................................................. 24
1.3 Projetos de Desenvolvimento de Software .............................................. 31
1.3.1 Ciclo de Vida do Projeto de Software .................................................................. 32
1.3.2 Metodologias de Desenvolvimento ...................................................................... 34
1.4 Gerenciamento da Qualidade em Projetos de Software ......................... 39
1.4.1 Planejamento da Qualidade em Projetos de Software ........................................ 44
1.4.2 Garantia da Qualidade em Projetos de Software ................................................ 46
1.4.3 Controle da Qualidade em Projetos de Software ................................................ 50
2 ESTUDO DE CASO ..........................................................................60
2.1 A Indústria Aeronáutica ............................................................................. 60
2.2 A Embraer ................................................................................................... 62
2.3 A Empresa Y ............................................................................................... 64
2.4 O Gerenciamento de Projetos de Desenvolvimento de Software .......... 64
2.4.1 Processo Planejar Projeto ................................................................................... 67
2.4.2 Processo Definir Requisitos................................................................................. 68
2.4.3 Processo Implementar Bloco ............................................................................... 69
2.4.4 Processo Liberar Software .................................................................................. 70
2.4.5 Processo Gerenciar Mudanças ........................................................................... 71
2.4.6 Processo Gerenciar Projeto................................................................................. 71
2.5 Torre de Controle ....................................................................................... 74
2.5.1 Índice de Qualidade da Torre de Controle........................................................... 75
3 DISCUSSÃO .....................................................................................79
3.1 Apresentação dos Entrevistados.............................................................. 79
3.2 Preparação da Entrevista .......................................................................... 80
3.3 Análise e Discussão da Entrevista ........................................................... 80
3.4 Análise e Discussão Final ......................................................................... 82
3.4.1 Proposta para o Planejamento da Qualidade ...................................................... 86
3.4.2 Proposta para a Realização da Garantia da Qualidade ...................................... 89
3.4.3 Proposta para a Realização do Controle da Qualidade ...................................... 91
CONCLUSÃO ......................................................................................100
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................103
13
INTRODUÇÃO
A indústria de desenvolvimento de software em geral vem aumentando seus

esforços de maneira considerável na disciplina de gerenciamento de projetos. É
cada vez mais comum testemunhar profissionais da área de software estudando a
gestão de projetos. Tal esforço se deve ao fato de que muitos projetos nessa área
falham, estouram em prazo e custo, consequentemente o valor do mau
gerenciamento é pago pelo cliente, na forma de encarecimento do produto, ou pelo
acionista, na forma de redução da margem de lucro.
O relatório produzido pela consultoria Standish Group e divulgado em 2009,

coleta informações sobre falhas de projetos nas indústrias de tecnologia. O resultado
mostra que apenas 32% desses projetos terminam com sucesso; 44% atrasaram,
estouraram o orçamento, e/ou reduziram escopo; e outros 24% foram cancelados ou
nunca foram utilizados. Na indústria aeronáutica o impacto desses números pode
ser ainda maior, por se tratar de um produto complexo e extremamente caro, sendo
que qualquer atraso ou falha pode significar além de alguns milhões de dólares, a
segurança de vidas humanas.
A monografia apresenta um estudo de caso em uma empresa do setor

aeronáutico, que por não ter autorizado a utilização de seu nome devido às
restrições internas de segurança da informação, será tratada como Empresa Y. O
desenvolvimento de software embarcado em sistemas aeronáuticos possui escopo e
prazo muito bem estabelecidos. O produto deve ficar pronto dentro de uma janela de
tempo única, sendo que qualquer atraso pode significar multas milionárias, queda da
qualidade ou mesmo torná-lo inviável economicamente. Por se tratar de um software
embarcado, crítico para a segurança de vidas humanas, um plano para garantia da
qualidade deste produto é algo fundamental para maximização da eficiência e da
segurança.
Diante desse contexto, torna-se importante o estudo do gerenciamento da

qualidade em projetos de desenvolvimento de software para a indústria aeronáutica,
além da identificação de um meio eficaz de se medir a qualidade do produto
desenvolvido.
14
O objetivo geral desta monografia é estudar como o gerenciamento da

qualidade pode contribuir para a Gestão de Projetos de desenvolvimento de
software, além de identificar e avaliar o método atualmente adotado pela Empresa Y
para o gerenciamento da qualidade em Projetos de desenvolvimento de software
embarcado em sistemas complexos. O objetivo final e mais específico é o de propor
um indicador quantitativo que possa ser adotado pela Empresa Y como meio de
medir a qualidade do software por ela desenvolvido.
A hipótese central desta monografia é que o gerenciamento da qualidade,

por meio de um plano da qualidade com a definição de itens de controle ao longo do
desenvolvimento do software, contribui com o aumento da qualidade final do produto
e com seu monitoramento através de um indicador de qualidade. Pode-se supor
ainda que o gerenciamento da qualidade contribua para a identificação da qualidade
do software apontando normas e procedimentos que devem ser seguidas a fim de
garantir a satisfação do cliente e determinar uma forma empírica de identificar a
qualidade do software.
Como hipótese secundária tem-se que o gerenciamento da qualidade pouco

pode contribuir na identificação de um indicador que traduza a qualidade do
software, uma vez que os parâmetros necessários são de complexa identificação e
muitas vezes podem não traduzir a real qualidade do software.
Por se tratar de um assunto extremamente amplo, o trabalho limita-se a

estudar o gerenciamento da qualidade aplicado no processo de desenvolvimento de
software já utilizado pela Empresa Y. Desta maneira, não é escopo apresentar todos
os processos de desenvolvimento de software e realizar uma possível proposta para
reformulação de toda a metodologia já utilizada pela empresa.
A monografia será desenvolvida através de um estudo de caso,

contemplando pesquisa bibliográfica e posterior pesquisa exploratória (levantamento
de informações). A etapa inicial deste projeto, de coleta de informações gerais sobre
as áreas específicas do conhecimento (tais como desenvolvimento de software
embarcado, a indústria aeronáutica, o gerenciamento da qualidade em projetos),
será realizada através de pesquisa descritiva. O levantamento de informações sobre
15
o gerenciamento da qualidade na Empresa Y será realizado por meio de um estudo

de caso, fazendo uso de entrevistas com funcionários relacionados a esta área de
conhecimento. Após a avaliação e comparação das informações levantadas, será
possível avaliar e discutir o modelo de gerenciamento da qualidade atualmente
adotado pela empresa em questão, e propor um modelo de gestão que possa ser
aplicado à mesma.
O trabalho está estruturado da seguinte maneira: a introdução apresenta e

justifica o tema, mencionando os objetivos gerais e específicos, além das hipóteses
adotadas sobre o assunto. O primeiro capítulo traz uma introdução à Gestão de
Projetos, mais especificamente sobre o tema de Gerenciamento da Qualidade. O
segundo capítulo é reservado ao estudo de caso sobre o processo de
desenvolvimento de software na Empresa Y, como é feito o gerenciamento da
qualidade atualmente e a metodologia de projeto utilizada, além de apresentar
também uma contextualização da indústria aeronáutica nacional e internacional,
citando em especial a Boeing e Airbus, como os maiores players internacionais e a
Embraer, como sendo a maior empresa nacional deste segmento. Os resultados do
estudo de caso, analisados e apurados, são apresentados no terceiro capítulo, no
qual se descreve ainda uma discussão sobre o assunto e apresenta-se o indicador
identificado para a medição da qualidade de software. Finalmente, a conclusão
encerra o trabalho analisando os resultados apresentados pelo estudo de caso e
realizando considerações finais.
16
1 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta uma pesquisa exploratória sobre os conceitos

utilizados neste trabalho. São descritos aqui os temas de gerenciamento de projetos,
com um enfoque mais detalhado no gerenciamento da qualidade, o contexto da
indústria aeronáutica e uma descrição básica dos processos de desenvolvimento de
software.
1.1 Conceitos Iniciais
Para descrever o gerenciamento de projetos é preciso antes defini-lo e

esclarecer os conceitos de projeto, processo e produto, conceitos que podem ser
facilmente confundidos por pessoas não envolvidas neste contexto.
1.1.1 Projeto
O PMI (2008) descreve projeto como sendo “um esforço temporário

empreendido para criar um produto, serviço ou resultado exclusivo”. O termo
“temporário” utilizado na definição indica que um projeto possui um começo, meio e
fim. Analogamente pode-se definir o começo como a fase de planejamento de um
projeto, o meio sua execução e o fim quando os objetivos definidos pelo projeto
forem alcançados, ou quando se chegar à conclusão de que esses objetivos são
impossíveis de ser alcançado, então o projeto é encerrado (PMI, 2008, p.5).
1.1.2 Processo
Por sua vez, um processo é definido pelo PMI (ibid) como “um esforço de
trabalho contínuo”, ou seja, não tem começo, meio e fim. Trata-se de um conjunto de
17
atividades estruturas e inter-relacionadas que transforma insumos (entradas) em

produtos (saídas) (PMI, 2008, p.5).
1.1.3 Produto
Por fim, um produto é definido como “um bem físico ou um serviço a ser
prestado” (MACHADO; TOLEDO, 2008, p. 2). Integrando os conceitos acima,
processo e produto, temos o Processo de Desenvolvimento de Produtos, que nada
mais é com conjunto de atividades planejadas e controladas com o objetivo de criar
um novo produto (MACHADO; TOLEDO, ibid).
1.2 Gerenciamento de Projetos
Posto esses conceitos e sabendo que um projeto pode ter como saída um
produto ou processo (PMI, 2008, p. 5), é preciso gerenciá-lo para que os requisitos
sejam atingidos de forma satisfatória. O PMI (2008) define então o Gerenciamento
de Projetos como sendo “a aplicação de conhecimento, habilidades, ferramentas e
técnicas às atividades do projeto a fim de atender aos seus requisitos” (PMI, 2008, p.
6).
A aplicação desses conhecimentos, técnicas e ferramentas no

gerenciamento de projetos não eram realizadas de forma consensual. Cada
empresa possuía seu próprio conjunto de ferramentas e praticas, foi quando em
1969 cinco pessoas de vanguarda, que já atuavam com gerenciamento de projetos e
entendiam do valor da troca de experiências e compartilhamento de informações, se
voluntariam e fundaram o PMI – Project Management Institute (PMI, 2012). Segundo
o site PMI (2012), “a meta principal do PMI é avançar na prática, na ciência e na
profissão de gerenciamento de projetos em todo o mundo, de uma maneira
consciente e pró-ativa, [...]”. Com esse objetivo, em 1987 o PMI lança o primeiro
Guia PMBOK – Project Management Body of Knowledge, que tem como objetivo
“identificar esse subconjunto do conhecimento em gerenciamento amplamente
18
reconhecido como boa prática” (PMI, 2008, p. 4). Ou seja, trata-se um guia contendo
todos os processos de gerenciamento de projetos, identificados pela comunidade
internacional como sendo as melhores práticas para o gerenciamento de projetos.
Ainda segundo o PMI (PMI, 2008, p. 6) são cinco os grupos de processos de

gerenciamento de projetos: iniciação; planejamento; execução; monitoramento e
controle e encerramento. Gerenciar um projeto inclui etapas de identificação dos
requisitos, adaptação das especificações conforme mudam as necessidades,
preocupações e expectativas das partes interessadas no projeto, e o balanceamento
das demandas conflitantes do projeto, que incluem escopo, prazo, qualidade,
orçamento, recursos e riscos.
1.2.1 Processos do Gerenciamento de Projetos
Conforme mencionado anteriormente, o gerenciamento de projetos é feito

por processos que são agrupados nas cinco categorias já descritas: iniciação;
planejamento; execução; monitoramento e controle e encerramento.
Shenhar e Dvir (2010) acrescentam aos processos de gerenciamento de

projetos a abordagem diamante, na qual busca a diferenciação dos projetos
conforme sua complexidade, tecnologia adotada, inovação e ritmo empregado ao
projeto. Kerzner (2002 apud MALVESTIO, 2010, p. 21) acrescenta ainda que a
cultura organizacional no processo de gerenciamento de projetos deve ser levada
em consideração.
Futrell, Shafer e Safer (2002) também estruturam o gerenciamento de

projetos de desenvolvimento de software em forma de processos.
Por ser um guia de boas práticas, o guia PMBOK (PMI, 2008, p. 39)
apresenta a definição dos cinco grupos de processos a seguir:
Grupo de processo de iniciação: são os processos que definem e

autorizam a iniciação do projeto ou de uma nova fase deste.
19
Grupo de processos de planejamento: nestes processos estão as

atividades que definem o escopo e os objetivos estratégicos do projeto,
além de o curso de ação necessário para alcançá-los.
Grupo de processos de execução: são os processos necessários para
realizar o trabalho definido no plano de gerenciamento do projeto.
Grupo de processos de monitoramento e controle: nestes processos se
identifica o progresso e desempenho do projeto, além de acompanhá-lo e
revisá-lo, identificando necessidades de mudanças correspondentes.
Grupo de processos de encerramento: são os processos que encerram o
projeto a fase deste de maneira formal, finalizando todas as atividades de
todos os outros grupos de processos.
Os grupos de processos de gerenciamento de projetos são bem definidos e

apresentados como elementos distintos pelo PMBOK (PMI, 2008, p. 39), porém na
prática eles interagem entre si e se sobrepõem. A Figura 1 mostra como os
processos interagem entre si e a Figura 2 ilustra a sobreposição dos grupos de
processo ao longo do clico de vida do projeto.
Figura 1 – Grupos de processo de gerenciamento de projetos
Fonte: PMI, 2008, p. 40

20
Figura 2 – Sobreposição entre os grupos de processos.
Fonte: PMI, 2008, p. 41
É importante ressaltar que os grupos de processo não são fases do projeto

(PMI, 2008, p. 41). Em projetos grandes e complexos, que seguem um processo de
desenvolvimento de produto bem definido, como o apresentado por Machado e
Toledo (2008), todos os grupos de processos são repetidos em cada uma dessas
fases (PMI, ibid).
Nestes cinco grupos de processos interativos, estão distribuídos 42

subprocessos mapeados em nove áreas de conhecimento que o PMI (2008)
descreve em seu guia como sendo:
1. Gerenciamento da integração do projeto.

2. Gerenciamento do escopo do projeto.
3. Gerenciamento de tempo do projeto.
4. Gerenciamento de custos do projeto.
5. Gerenciamento da qualidade do projeto.
6. Gerenciamento de recursos humanos do projeto.
7. Gerenciamento das comunicações do projeto.
8. Gerenciamento de riscos do projeto.
9. Gerenciamento das aquisições do projeto.
21
1.2.2 Áreas de Conhecimento do Gerenciamento de Projetos
As áreas de conhecimento apresentadas pelo PMI (2008, p. XXIII)

organizam os processos de gerenciamento de projetos, possuem entradas e saídas
bem definidas, além de possuírem técnicas e ferramentas apropriadas para cada
atividade, conforme colocado pelo PMBOK (PMI, 2008) são definidas como:
Gerenciamento da integração do projeto apresenta as atividades dos

processos que integram os elementos do gerenciamento de projetos,
abordando as atividades de desenvolvimento do termo de abertura do
projeto e do plano de gerenciamento do projeto, orienta e gerencia a
execução do projeto, monitora e controla o trabalho do projeto, realiza o
controle das mudanças e encerra o projeto ou a fase.
Gerenciamento do escopo do projeto se preocupa com os processos
que tratam da garantia de que o projeto contemple o trabalho necessário
para que este atinja seus objetivos e seja encerrado com sucesso. Estes
processos possuem as atividades de coleta dos requisitos, definição do
escopo, criação da estrutura analítica do projeto, verificação e controle do
escopo.
Gerenciamento do tempo do projeto define os processos referentes ao
encerramento do projeto dentro do prazo contratado. Nestes processos
são apresentadas as atividades de definição e sequenciamento das
tarefas, estimativa dos recursos necessários, estimativa das durações
das atividades, desenvolvimento e controle do cronograma.
Gerenciamento dos custos do projeto se concentra nos processos
relativos ao orçamento e controle de custos do projeto, de maneira que
este termine dentro do orçamento planejado. Nestes processos são
realizadas as atividades de estimativa dos custos, determinação do
orçamento e controle dos custos.
Gerenciamento da qualidade do projeto define os processos
envolvidos na satisfação dos requisitos de qualidade do projeto,
passando desde o planejamento da qualidade até o monitoramento e
controle da mesma. Nestes processos são realizadas as atividades de
planejamento da qualidade, garantia e controle da qualidade. Por ser
22
objeto de estudo deste trabalho, o gerenciamento da qualidade será

abordado de maneira mais detalhada no subcapítulo a seguir, mais
adiante será tratado também o gerenciamento da qualidade em projetos
de desenvolvimento de software.
Gerenciamento dos recursos humanos do projeto se concentra nos
processos relativos ao planejamento, contratação, desenvolvimento e
gerenciamento da equipe do projeto. Neste gerenciamento são
executadas as atividades de desenvolvimento do plano de recursos
humanos, mobilização e desenvolvimento da equipe, além do
gerenciamento desta.
Gerenciamento das comunicações do projeto descreve os processos
relativos à disseminação e compartilhamento das informações relevantes
do projeto de maneira apropriada e no momento certo. Nestes processos
estão as atividades de identificação das partes interessadas,
planejamento da comunicação, distribuição das informações,
gerenciamento das expectativas das partes interessadas e reporte de
desempenho.
Gerenciamento dos riscos do projeto define os processos referentes à
identificação, análise e controle dos riscos do projeto. Nesta área de
conhecimento estão as atividades de planejamento do gerenciamento
dos riscos, identificação dos riscos, análise qualitativa e quantitativa dos
riscos, planejamento de resposta aos riscos, monitoramento e controle
dos riscos.
Gerenciamento das aquisições do projeto, por sua vez, descreve os
processos envolvidos na compra de produtos, serviços ou qualquer tipo
de resultado para o projeto. Nestes processos estão as atividades de
planejamento e condução das aquisições, administração e encerramento
das aquisições.
O Quadro 1 reflete o mapeamento dos 42 subprocessos com sua

associação aos grupos de processos e distribuídos nestas nove áreas de
conhecimento.
23
Quadro 1 – Mapeamento de grupos de processos e áreas de conhecimento
Grupo de processo de gerenciamento de projetos

Áreas de
conhecimento Iniciação Planejamento Execução Monitoramento e Encerramento
Controle
Gerenciamento . Monitorar e
controlar o
da Integração . Desenvolver
. Desenvolver o . Orientar e
trabalho do
plano de gerenciar a . Encerrar o
termo de abertura projeto
gerenciamento do execução do projeto ou fase
do projeto. . Realizar o
projeto projeto
controle integrado
de mudanças
Gerenciamento . Coletar os . Verificar o
requisitos escopo
do Escopo . Definir o escopo . Controlar o
. Criar a EAP escopo
Gerenciamento . Definir as
atividades
do Tempo . Sequenciar as
atividades
.Estimar os
recursos das . Controlar o
atividades cronograma
. Estimar as
durações das
atividades
. Desenvolver o
cronograma
Gerenciamento .Estimar os
custos . Controlar os
dos Custos . Determinar o custos
orçamento
Gerenciamento . Planejar a
. Realizar a . Realizar o
garantia da controle da
da Qualidade qualidade
qualidade qualidade
Gerenciamento . Mobilizar a
equipe do projeto
dos . Desenvolver o
. Desenvolver a
plano de recursos
Recursos humanos
equipe do projeto
. Gerenciar a
Humanos equipe do projeto
Gerenciamento . Distribuir as
informações
das . Identificar as
. Planejar as . Gerenciar as . Reportar o
Comunicações partes
comunicações expectativas das desempenho
interessadas.
partes
interessadas
Gerenciamento . Planejar o
gerenciamento
dos Riscos dos riscos
. Identificar os
riscos
.Realizar a
análise qualitativa
. Monitorar e
dos riscos
controlar os riscos
. Realizar a
análise
quantitativa dos
riscos
Planejar as
respostas aos
riscos
Gerenciamento . Planejar as . Conduzir as . Administrar as .Encerrar as
das Aquisições aquisições aquisições aquisições aquisições
Fonte: Adaptado de PMI, 2008, p. 43.
24
1.2.3 Gerenciamento da qualidade do projeto
O gerenciamento da qualidade, conforme mencionado anteriormente, define

os processos envolvidos na garantia da satisfação dos requisitos de qualidade do
projeto. Porém, é preciso entender bem o conceito de qualidade para que se possa
primeiramente identificar tais requisitos e em seguida monitorá-los. Oliveira (2009)
diz que para se definir qualidade é necessário primeiro que se defina o referencial na
qual ela é observada. Segundo Prazeres (1996 apud OLIVEIRA, 2009, p. 47) a
palavra qualidade se origina do latim qualitas, qualitatis – “o que faz com que alguma
coisa seja tal como se considera”.
A disciplina da qualidade é tida como relativamente madura, porém ainda

não existe consenso claro sobre sua definição (FERNANDES, 1995). Deste modo, é
apresentada a seguir uma coletânea de definições de vários autores para que o
leitor possa comparar e criar seu próprio conceito.
Feigenbaum (1986 apud FERNANDES, 1995, p. 28) define qualidade como

a “composição total das características de marketing, engenharia, fabricação e
manutenção de um produto ou serviço, através das quais o mesmo produto ou
serviço, em uso, atenderá as expectativas do cliente”.
Crosby (2012) por sua vez, é mais sucinto e diz que “qualidade é o
cumprimento dos requisitos”.
Independente da definição adotada, Fernandes (ibid) salienta que quem

define a qualidade em termos de necessidades e expectativas é o cliente e que a
partir daí tem-se os requisitos identificados e os produtos, ou serviços, projetados e
realizados.
Definido o conceito de qualidade e identificado o papel fundamental do

cliente neste processo, o gerenciamento da qualidade do projeto nos apresenta um
conjunto de atividades, ferramentas e técnicas da organização executora de modo
que o projeto satisfaça às necessidades para as quais foi aprovado (PMI, 2008, p.
189). Os processos de gerenciamento da qualidade são: planejar a qualidade,
25
realizar a garantia da qualidade e realizar o controle da qualidade. A Figura 3 ilustra

uma visão analítica do Gerenciamento da Qualidade do Projeto.
Gerenciamento da
Qualidade do Projeto
Planejamento Garantia da Controle da

da Qualidade Qualidade Qualidade
Figura 3 – Visão analítica do gerenciamento da qualidade do projeto
Fonte: Adaptado de PMI, 2008,

2008, p. 191.
1.2.3.1 Planejamento da Qualidade
Planejar a qualidade é o processo de identificar os requisitos de qualidade

do projeto e do serviço ou produto, além de documentar e registrar a maneira com a
qual o projeto demonstrará
demonstrará conformidade (PMI, 2008, p. 189).
18
Ainda segundo o PMI (2008) existem diversas ferramentas e técnicas que

podem ser aplicadas nesse processo. Não é objeto deste
este trabalho detalhar cada
uma
a delas, porém a Figura 4 a apresenta
presenta as que são utilizadas com maior
frequência nos projetos.
26
Ferramentas
Entrada Saídas
e técnicas
. Linha de base do
escopo . Análise de Custo
benefício
. Registro das partes . Plano de
interessadas . Custo da Qualidade Gerenciamento da
. Linha de base do . Gráficos de controle Qualidade
desempenho dos custos . Benchmarking . Métricas da qualidade
. Linha de base do . Projeto de . Listas de Verificação
cronograma experimentos . Plano de melhorias do
. Registro dos riscos . Amostragem estatística processo
. Fatores ambientais da . Fluxogramas . Atualização dos
empresa . Procedimentos documentos do projeto
. Ativos de processos . Ferramentas adicionais
organizacionais
Figura 4 – Planejar a qualidade: entradas, ferramentas e saídas.
O Plano de Gerenciamento da Qualidade é uma das principais saídas deste

processo e inclui o controle e a garantia da qualidade, bem como as abordagens de
melhoria contínua dos processos no projeto (PMI, 2008, p. 200).
Neste plano devem constar todos os documentos e registros que serão

utilizados na garantia da qualidade do projeto. Segundo o padrão normativo ISO
9000, documento é “informação e o meio no qual está contido”. Registro, por sua
vez, é definido ainda pela ISO 9000 como um “documento que declara os resultados
atingidos ou fornece evidencia de atividades realizadas”.
Oliveira (2009) apresenta em seu livro a estrutura típica da documentação

do sistema da qualidade. Acrescenta ainda que todo o sistema da qualidade pode
estar documentado no Manual da Qualidade. Este manual é um documento muito
mais robusto que o Plano de Gerenciamento da Qualidade, pois traz todos os
requisitos da norma ISO 9001:2008 (OLIVEIRA, ibid). A Figura 5 apresenta a
27
estrutura do Manual da Qualidade e onde o Plano do Gerenciamento da Qualidade

está inserido.
Plano de
Gerenciamento da
Qualidade
Instruções de Trabalho
Formulários e documentos externos
Figura 5 – Estrutura típica da documentação do Sistema da Qualidade.
Fonte: Adaptado de OLIVEIRA, 2009, p. 85.
1.2.3.2 Realização da Garantia da Qualidade
Para ajudar o leitor a conectar os conceitos apresentados até o momento,

tem-se a seguinte recapitulação: os projetos possuem objetivos estratégicos e metas
para alcançar tais objetivos bem definidos. Oliveira (2009) cita que de nada adianta
a definição de tais metas se não forem implantados indicadores para o
acompanhamento dos resultados das ações tomadas para o atingimento destes
objetivos. Este é então o papel do processo de Garantia da Qualidade, definido pelo
PMBOK (PMI, 2008, p. 201) como “o processo de auditoria dos requisitos de
qualidade e dos resultados das medições do controle da qualidade para garantir que
sejam usados os padrões de qualidade e definições operacionais apropriadas”.
28
Como a própria definição diz, o processo de garantia da qualidade se utiliza

das medições geradas no Controle da Qualidade, que será abordado neste trabalho
no próximo subcapítulo. Deste modo, fica claro a interação entre esses dois
processos, conforme ilustrado na Figura 6.
Figura 6 – Diagrama do Fluxo de dados do processo de Realizar a Garantia da Qualidade
Fonte: PMI, 2008, p. 202
Ainda segundo o PMI (2008), o processo de Planejamento da Qualidade é

uma das entradas da garantia da qualidade, além das medições geradas no
Controle da Qualidade, conforme mencionado anteriormente. Conforme ilustra a
Figura 7, a realização de auditorias internas é uma das principais ferramentas para
realização da Garantia da Qualidade em um projeto.
29
Ferramentas
Entrada Saídas
e técnicas
. Atualizações dos
. Plano de
ativos de processos
Gerenciamento do
. Ferramentas e organizacionais
Projeto
técnicas de Planejar a . Solicitações de
. Métricas da qualidade e Realizar o mudanças
qualidade controle da qualidade
. Atualizações do plano
. Informações sobre o . Auditorias de de gerenciamento do
desempenho do qualidade projeto
trabalho
. Análise de Processos . Atualizações dos
. Medições do controle
documentos do
da qualidade
projeto
Figura 7 – Realizar a Garantia da Qualidade: entradas, ferramentas e saídas
Fonte: Adaptado de PMI, 2008, p. 202
A norma ISO 9000 define a auditoria como sendo “um processo sistemático,
independente e documentado para se obter evidência e avaliá-la objetivamente,
visando determinar a extensão na qual os critérios de auditoria são atendidos”.
Define ainda que critérios de auditoria são “o conjunto de políticas, procedimentos
ou requisitos usados como uma referência”.
O papel das auditorias no processo de Garantia da Qualidade é de tamanha

importância que Fernandes (1995, p. 30) afirma que “a qualidade é garantida através
de auditorias da qualidade, auditorias de produto, auditorias do desenvolvimento de
novos projetos, auditorias de processos e assim sucessivamente”.
Os objetivos finais da auditoria de qualidade são a identificação das boas

práticas que estão sendo praticadas pelo projeto para que sejam compartilhadas por
projetos semelhantes; identificação das deficiências; oferecer apoio na melhoria
continua dos processos; e por fim registrar no banco de lições aprendidas as
contribuições de cada auditoria (PMI, 2008, p. 204). Deste modo, atingindo tais
objetivos, as auditorias contribuem muito para que este processo gere as saídas
30
apontadas na Figura 7, gerando grandes melhorias nos processos executados pelo

projeto. Talvez devido a tais definições e resultados, Oliveira (2009, p. 125)
acrescenta que “auditoria é igual passeio de buggy nas dunas do Nordeste, tem de
ter emoção!”.
1.2.3.3 Realização do Controle da Qualidade
Conforme visto no processo de realização da Garantia da Qualidade, cabe a

este processo gerar um conjunto de métricas e medições da qualidade, por meio de
indicadores. O controle da qualidade é definido pela American Society for Quality
Control (1983 apud FERNANDES, 1995, p. 29) como “o conjunto de técnicas
operacionais e atividades que sustentam a qualidade do produto e serviço que
satisfará certas necessidades; também o uso de tais técnicas e atividades”.
Fernandes (ibid) define de modo mais prático que o controle da qualidade monitora o
processo para a eliminação das causas de desempenho abaixo do esperado,
visando maximizar a eficiência econômica do projeto.
Uniformizando os conceitos com a aplicação da definição do PMBOK (PMI,

2008, p. 206), a realização do controle da qualidade é o processo de monitoramento
das atividades da qualidade de modo a avaliar o desempenho e propor as melhorias
necessárias. Este monitoramento deve ser realizado durante todo o projeto, em
geral por um departamento específico (PMI, ibid).
Este processo, assim como os anteriores, possui entradas e saídas bem

definidas, além de algumas ferramentas propostas como melhores práticas, como
ilustra a Figura 8.
31
Ferramentas
Entrada Saídas
e técnicas
. Diagramas de causa e . Medições do controle da
. Plano de Gerenciamento efeito
do Projeto qualidade
. Gráficos de controle . Mudanças validadas
. Métricas da qualidade
. Fluxogramas . Entregas validadas
. Listas de verificação da
qualidade . Histogramas . Atualizações dos ativos de
. Medições de desempenho . Diagrama de Pareto processos organizacionais
do trabalho . Gráfico de execução . Solicitações de mudança
. Solicitações de mudança . Diagrama de dispersão . Atualizações do plano de
aprovadas gerenciamento do projeto
. Amostragem estatística
. Entregas . Atualizações dos
. Inspeção
. Ativos de processos documentos do projeto
organizacionais . Revisão das solicitações de
mudança aprovadas
Figura 8 – Realizar o Controle da Qualidade: entradas, ferramentas e saídas
Fonte: Adaptado de PMI, 2008, p. 206
1.3 Projetos de Desenvolvimento de Software
Os conceitos de Gerenciamento de Projetos apresentados anteriormente

podem ser aplicados a qualquer tipo de projeto, desde projetos de construção civil
até projetos de ordem pessoal, como realizar uma grande festa de casamento ou
uma viagem de férias por exemplo. Deste modo, o desenvolvimento de software
também é um dos grandes usuários desta disciplina. Desde 1994, quando o
Standish Group divulgou seu primeiro CHAOS Report divulgando bilhões de dólares
desperdiçado em projetos de desenvolvimento de software que falharam ou que
sequer foram concluídos, a necessidade de gerenciar tais projetos ficou ainda mais
evidente.
A globalização, equipes de desenvolvimento distribuídas, novos entrantes no

mercado, novos produtos e tecnologias, fazem com que todos busquem o menor
desperdício possível e a maior eficiência, caso contrário em pouco tempo estarão
fora do mercado. Adicionalmente, a fase em que vivemos atualmente, chamada Era
32
do Conhecimento, faz com que o desenvolvimento de projetos em geral, mas em

especial projetos complexos de alta tecnologia, como desenvolvimento de software,
sejam gerenciados, com informações compartilhadas, reutilizadas e que haja
constante troca de conhecimento e experiências. Todos esses fatores aceleraram a
utilização das áreas de conhecimento do Gerenciamento de Projetos em projetos de
desenvolvimento de software.
1.3.1 Ciclo de Vida do Projeto de Software
Para que se entenda melhor a aplicação das áreas de conhecimento de

Gerenciamento de Projetos em projetos de software, é necessário antes defini-lo.
Todo software é desenvolvido, independente da tecnologia, plataforma ou linguagem
de programação, segundo uma sequência básica de grandes atividades,
denominada Ciclo de Vida do produto Software (FERNANDES, 1995). A Figura 9
ilustra o ciclo de vida tradicional de desenvolvimento de software.
PROJETO PRODUTO
Definição
Análise do Projeto Projeto Testes e Manutenção
dos
Negócio Preliminar Detalhado implantação e Descarte
Requisitos
PROCESSO
Figura 9 – Ciclo de Vida do Software
Fonte: Adaptado de Fernandes, 1995, p. 18

33
1.3.1.1 Fase de Projeto
Ainda segundo Fernandes (1995), um projeto de software é um esforço no

sentido de desenvolver um produto, dentro das especificações, que atenda os
requisitos identificados pelos usuários (clientes) para que executem processos
operacionais e gerenciais do negócio. Como todo projeto, é um esforço finito, com
começo, meio e fim bem definidos. Uma característica deste produto é o
desenvolvimento de versões de software intermediárias, novas releases, também
podem ser considerados um projeto independente.
1.3.1.2 O Processo (Metodologia)
O processo de software, por sua vez, é definido por Fernandes (ibid) como
um conjunto de atividades em um sequência predeterminada, métodos e práticas
utilizadas no desenvolvimento, evolução e manutenção do produto software.
Completa ainda que um processo de software compreenda:
Políticas de desenvolvimento.
Procedimentos para o desenvolvimento.
Técnicas e padrões para o desenvolvimento do produto.
Padrões de apresentação dos produtos intermediários.
O processo define o modelo cujo projeto será executado e gerenciado. O

processo de software é o que é chamado de metodologia de desenvolvimento,
que será tratado mais adiante.
1.3.1.3 O Produto de Software
Finalmente, Fernandes (ibid) define o produto software como sendo o

resultado do processo de software, “um release que contém uma série de atributos
34
derivados dos requisitos e especificações a fim de atender necessidades implícitas e

explícitas dos usuários (clientes)”. O produto software pode sofrer alterações ao
longo de seu ciclo de vida, a fim de se introduzir novas funcionalidades, seja em
função de novos requisitos dos clientes ou da própria evolução tecnológica. Cada
alteração do produto pode ser tratada como um novo projeto, seguindo a mesma
metodologia de desenvolvimento e gerando ao final um novo produto, ou release.
1.3.2 Metodologias de Desenvolvimento
Existem diversos modelos de desenvolvimento de software atualmente.

Malvestio (2010) apresenta alguns destes modelos dividido em duas categorias,
métodos tradicionais e ágeis. Modelos Tradicionais surgiram no final da década de
60 e consiste na produção do software dividido em fases, por meio da utilização de
ferramentas e da documentação de tudo o que é produzido. Alguns dos modelos
tradicionais mais conhecidos são:
Modelo em Cascata
Modelo em V
Modelo Iterativo
Modelo em Espiral
A Modelo em Cascata apresentado na Figura 10 e o Modelo em V

apresentado na Figura 11, são dois dos modelos mais conhecidos da metodologia
tradicional.
35
Figura 10 – Etapas do Modelo em Cascata
Fonte: Malvestio, 2010, p. 20
Figura 11 – Etapas do Modelo em V
Fonte: Adaptado de Futrell, Shafer e Safer, 2002, p. 153
O Modelo em V é o mais comum na indústria de software e foi desenvolvido

para auxiliar a equipe de projeto no planejamento e desenvolvimento orientado a
36
testes de sistema. O modelo dá uma grande ênfase a atividades de verificação e

validação do produto. A atividade de desenvolvimento do plano de testes é
representada pelas linhas pontilhadas da figura anterior, conectando as fases
(retângulos) do modelo em V (FUTRELL; SHAFER; SAFER, 2002). Estes mesmos
autores descrevem cada uma destas fases conforme segue:
Planejamento do Projeto de Requisitos: Determina os requisitos do

projeto e como os recursos da empresa serão alocados de modo a
atendê-los.
Análise dos requisitos de produto e especificação: Inclui a análise do
problema em que o software solucionará e conclui com uma completa
especificação do comportamento esperado do sistema a ser
desenvolvido.
Arquitetura do sistema ou Projeto preliminar: Determina como serão
desenvolvidas as funções de software do projeto.
Projeto detalhado: Define e documenta todos os algoritmos de cada
componente de software identificado na fase anterior. Estes algoritmos
serão transformados em código de software na próxima fase.
Codificação: Transforma os algoritmos definidos no projeto detalhado em
linguagem de software.
Teste unitário: Testa cada unidade de software separadamente a procura
de erros.
Integração e Testes: Integra todas as unidades de software testadas na
fase anterior para garantir que funcionam exatamente como funcionavam
separadamente.
Testes de sistema e aceitação: Teste o sistema completamente
integrado, inclusive no hardware que será utilizado pelo cliente final,
também chamado de Target.
Produção, Operação e Manutenção: Inicia a operação do software pelos
usuários e a fase de melhorias e correções.
Métodos ágeis de desenvolvimento de softwares, por outro lado, surgiram

em meados dos anos 90 em função do desempenho insatisfatório da metodologia
37
tradicional que vigorava até então. Os Métodos Ágeis são definidos por Kong,
Kendall e Kendall (2012) como uma coletânea de diferentes valores, princípios e
práticas. Ainda segundo esses autores, os valores do método ágil são a filosofia que
está por trás de seus métodos, que são definidas e apoiadas pelos seus princípios e
práticas. Kong, Kendall e Kendall (ibid) esclarecem que ao invés de ver o
desenvolvimento de software como um processo de engenharia no qual otimização
e controle é necessário, a metodologia ágil vê o desenvolvimento de software como
um processo de inovação e aprendizado no qual a capacidade de resposta e
flexibilidade é obrigatória a fim de lidar com as incertezas e mudanças do projeto.
Malvestio (2010) apresenta alguns dos principais métodos ágeis de

desenvolvimento de software:
Extreme Programming (XP)

Scrum
Lean Development (LD)
Feature Driven Development (FDD)
Adaptative Software Development (ASD)
Dynamic System Development Method (DSDM)
Crystal Methods
Os valores, princípios e práticas do método ágil ficam mais claros na Figura

12 a seguir:
38
Valores Ágeis
Indivíduos e interações sobre processos e ferramentas.
Mais software menos documentação.
Colaboração do cliente mais que negociação de contrato.
Flexibilidade mais que seguir um plano.
Princípios Ágeis
Alcançar a satisfação do cliente mediante a entrega rápida de software valioso
Mudanças de requisitos são bem vindas, mesmo tarde no desenvolvimento
Entregar release de software funcionando frequentemente
Atividade de software é a principal medida de progresso
O desenvolvimento sustentável
A estreita colaboração entre as pessoas de negócios e desenvolvedores
Interações Face-to-face
Face
Os projetos são construídos em torno de indivíduos motivados
Atenção contínua à excelência técnica
Simplicidade
Equipes Auto-gerenciadas
Auto
Adaptação regular à evolução das circunstâncias
Práticas Ágeis
Práticas Extreme Programming (XP): Programação em par, Jogo Planejado,
Desenvolvimento orientado à testes, Equipe integrada, refactoring, pequenos
releases, padronização de código, design simples etc...
Práticas Scrum: Dono do produto, Scrum Master, equipe Scrum, reuniões de

planejamento de sprint, reunião matinal diária, Sprint Review, Sprint
Retrospective etc.
Figura 12 – Valores, Princípios e Práticas do método Ágil
Fonte: Adaptado de Kong, Kendall e Kendall, 2012, p. 3
Malvestio (2010
(2010)) apresenta ainda a influência dos métodos Ágeis de
desenvolvimento de software na disciplina de Gestão de Projetos, seja ele de
software ou
u não, “surgindo assim uma nova perspectiva de gerenciamento de
projetos – o Gerenciamento Ágil de Projetos” (MALVESTIO, 2010, p.41)
p.41). Por ser um
assunto de amplo conteúdo, esta nova perspectiva de gerenciamento de projetos
não será detalhada neste trabalho,
trabalho, porém foi citada para que fique claro tamanha
relevância dos Métodos Ágeis.
39
1.4 Gerenciamento da Qualidade em Projetos de Software
Como todo projeto, um projeto de desenvolvimento de software também

deve ter sua qualidade gerenciada. É preciso realizar o planejamento, garantia e
controle da qualidade, porém Fernandes (1995) define a área de desenvolvimento
de software como sendo uma das mais resistentes à implementação da qualidade.
Isso se deve pelo fato de software ser algo essencialmente complexo (PRESSMAN,
2005). Sommerville (2007) acrescenta inclusive que a noção clássica de qualidade
aplicada a produtos manufaturados, ou seja, sua conformidade com relação às
especificações, não pode ser do mesmo modo aplicada ao software. Segundo este
mesmo autor, a especificação deve ser feita orientada às características do produto
e aos desejos do cliente. Para software, no entanto, a arquitetura do
desenvolvimento também possui seus próprios requisitos que não estão incluídas na
especificação. Além disso, acrescenta ele, é muito complicado especificar certos
requisitos de qualidade, como manutenibilidade, por exemplo, de forma não
ambígua.
Sendo assim, Pressman (2005, p. 748) define qualidade de software como a
conformidade com os requisitos funcionais e de desempenho explicitamente

declarados, com padrões de desenvolvimento explicitamente documentados
e com características implícitas esperadas de todo software desenvolvido
profissionalmente.
Petrasch (1999), por sua vez, apresenta uma definição mais resumida do
assunto, como sendo “a existência de características do produto nas quais podem
ser associadas com os requisitos” (PETRASCH, 1999, p2). Segundo ele, a
existência de requisitos para cada característica do software torna possível a
definição da qualidade do produto. Essa relação é apresentada na Figura 13.
40
Figura 13 – Relação entre requisitos e características em conjunto com a qualidade
Fonte: Adaptado de Petrasch, 1999, p.2
O SWEBOK – Software Engineering Body of Knowledge (IEEE, 2004)

apresenta na Figura 14 algumas considerações e a estrutura da qualidade de
software, além de diversas técnicas para alcançá-la.
Figura 14 – Estrutura da Qualidade de Software
Fonte: Adaptado de IEEE, 2004, p.11-2

41
Segundo o SWEBOK (IEEE, 2004, p. 11-1), essas considerações

“transcendem o ciclo de vida do produto. Qualidade de software é uma preocupação
omnipresente em engenharia de software, deste modo está presente em diversas
áreas do conhecimento apresentada pelo guia SWEBOK”.
O CMMI for Development (SEI, 2010, p. 4), em suas pesquisas para ajudar
as organizações a desenvolver e manter produtos e serviços de qualidade identificou
três dimensões críticas que as organizações tipicamente focam seus esforços:
pessoas, processos e metodologias, e equipamentos e ferramentas. A Figura 15
ilustra tais dimensões.
Figura 15 – As Três Dimensões Críticas do CMMI-DEV
Fonte: Adaptado de SEI, 2010, p. 4
Nota-se uma relação entre as dimensões críticas apresentadas pelo CMMI

(SEI, 2010) e a estrutura da qualidade apresentada pelo SWEBOK (IEEE, 2004),
uma vez que neste último muito do que se vê são processos e ferramentas.
Finalmente, pode-se dizer que a qualidade do software está diretamente

relacionada com os seus requisitos e com o processo utilizado para o seu
desenvolvimento. Quando Petrasch (1999) diz que todo Produto de Software deve
42
atender aos seus requisitos, o SWEBOK (IEEE, 2004) vai ao encontro e introduz os
conceitos de Engenharia de Software e Verificação & Validação (V&V), que
procuram sempre rastrear toda funcionalidade de código com seu respectivo
requisitos (FUTRELL; SHAFER; SAFER, 2002). Em casos de software de sistemas
de críticos, que será detalhado um pouco mais adiante, existem normas que exigem
inclusive que todo o trecho de código fonte tenha um requisito associado (RTCA,
1992). São casos mais extremos, de softwares embarcados em sistemas que
oferecem risco a integridade humana, como por exemplo, equipamentos
hospitalares ou aeronaves. De qualquer forma, a relação entre produto e requisito é
ainda mais presente nestes casos.
Colocadas as diferenças entre os conceitos de qualidade e qualidade de

software, bem como as características exclusivas aos projetos de desenvolvimento
de software, a área de conhecimento do Gerenciamento da Qualidade apresentada
pelo PMBOK (PMI, 2008) sofre algumas alterações quando aplicadas em projetos de
desenvolvimento de software. Analogamente, os três processos do gerenciamento
da qualidade – planejamento, garantia e controle – também estão claramente
presentes, porém com características próprias e seguindo modelos dedicados para
projetos desta natureza.
Diante de diversas definições de qualidade de software, Pressman (2005, p.

744) apresenta alguns pontos interessantes sobre o gerenciamento da qualidade de
software:
Defina claramente o termo qualidade de software quando for dito.

Crie um conjunto de atividades auxiliares para que cada componente de
software seja desenvolvido com alta qualidade.
Realize atividades de garantia e controle da qualidade em todos os
projetos.
Utilize métricas e indicadores para traçar estratégias de melhoria do
processo de desenvolvimento de software, consequentemente do produto
final.
43
Definir claramente o termo qualidade de software é algo fundamental para

que possa ser iniciado o processo de gerenciamento da qualidade. É importante que
se saiba o que se deseja gerenciar, ou seja, assim como no projeto, definir o escopo
da qualidade de software e até que nível ela será gerenciada. Para isso existem
diversos modelos de desenvolvimento de software que auxiliam na identificação do
escopo a ser seguido no gerenciamento da qualidade, como por exemplo, o CMMI
(SEI, 2010). De qualquer modo, o próprio SWEBOK (IEEE, 2004, p. 8-2), a fim de
não duplicar conteúdo, faz referência ao PMBOK no que diz respeito às áreas de
conhecimento de Gerenciamento de Escopo, Gerenciamento do Tempo,
Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamento dos
Recursos Humanos, Gerenciamento das Comunicações e, por fim, Gerenciamento
da Integração.
O SWEBOK (IEEE, 2004, p. 11-3), no entanto, reforça que o gerenciamento

da qualidade deve ser responsável pelo quão bem o produto de software vai
satisfazer os requisitos dos stakeholders, prover valor ao cliente e qualidade de
software necessária para atender aos requisitos de software. Deste modo, o
gerenciamento da qualidade apresentado pelo SWEBOK (ibid) é definido pelos
seguintes processos:
Processo de Garantia da Qualidade

Processo de Verificação
Processo de Validação
Processo de Revisão
Processo de Auditoria
O Quadro 2 apresenta um possível relacionamento entre os processos de

gerenciamento da qualidade apresentados pelo PMBOK (PMI, 2008) com os
processos do SWEBOK (IEEE, 2004):
44
Quadro 2 – Relação dos Processos de Gerenciamento da Qualidade PMI x SWEBOK
PMI SWEBOK
Planejamento da Qualidade Idêntico ao PMBOK
Processo de Garantia da Qualidade de

Garantia da Qualidade
Software (Quality Software Assurance)
Processo de Verificação
Processo de Validação
Controle da Qualidade
Processo de Revisão
Processo de Auditoria
Fonte: Adaptado de PMBOK (PMI, 2008) e SWEBOK (IEEE, 2004)
Todos os processos de gerenciamento da qualidade apresentados pelo

SWEBOK (IEEE, 2004), entre outros, formam o processo de Gerenciamento da
Engenharia de Software, e é com base na Engenharia de Software que será
detalhado neste trabalho o gerenciamento da qualidade para Projetos de
Desenvolvimento de Software, que tem sua estrutura muito semelhante à estrutura
do gerenciamento da qualidade apresentada pelo PMBOK na Figura 3, porém com
entradas e saídas específicas para software.
1.4.1 Planejamento da Qualidade em Projetos de Software
O Plano de Gerenciamento da Qualidade, conforme apresentado na Figura 4,

é uma das principais saídas da fase de Planejamento da Qualidade. Para projetos
de desenvolvimento de software, este plano deve conter, além do que é apresentado
pelo PMBOK (PMI, 2008), a qualidade de software desejada e descrever como será
atingida. Sommerville (2007) acrescenta que, alinhado com Pressman (2005, p.
744), o plano deve definir claramente o que a frase “Software de Alta Qualidade”
realmente significa para o projeto e seus stakeholders. Sem essa definição clara,
continua o autor, os engenheiros de software podem assumir premissas diferentes, e
algumas vezes conflitantes, sobre quais atributos do produto podem ser otimizados.
45
O planejamento da qualidade segundo o SWEBOK (IEEE, 2004, p. 11-3)

“envolve a definição da qualidade do software desejada e os processos para atingir
tais requisitos de qualidade”.
Um bom Plano de Qualidade de Software, segundo Sommerville (2007, p.

652) deve conter:
Introdução do Produto: uma breve descrição do produto, o mercado a

que se destina e suas expectativas de qualidade.
Cronograma do Produto: as datas planejadas dos entregáveis críticos,
seus responsáveis e o plano de entrega e entrada em serviço.
Descrição do Processo: o processo de desenvolvimento que deverá ser
usado no desenvolvimento e gerenciamento do produto.
Metas de Qualidade: os objetivos e metas de qualidade, incluindo
identificação e justificativa dos atributos de qualidade dos produtos
críticos.
Riscos e Gerenciamento dos Riscos: os principais riscos que podem
afetar a qualidade do produto e as ações de mitigação dos mesmos.
Obviamente um plano da qualidade de software pode variar conforme

tamanho e complexidade do sistema que está sendo desenvolvido. De qualquer
modo, o importante é que ele seja enxuto e não muito extenso, pois caso seja muito
grande e de leitura demorada, as pessoas simplesmente não o lerão, o que
certamente afetará o seu próprio propósito de existência, a qualidade
(SOMMERVILLE, 2007).
O Quadro 3 apresenta uma série de atributos de qualidade de software que

devem ser considerados ao escrever um plano da qualidade. Claramente não é
possível endereçar todos esses atributos em um mesmo projeto, porém no plano de
qualidade devem estar definidos aqueles mais importantes para o sistema que está
sendo desenvolvido, além da definição de como será o processo de avaliação da
qualidade destes atributos.
46
Quadro 3 – Atributos de qualidade de software
Atributos
Segurança Adaptação para reutilização
Flexibilidade Robustez
Testabilidade e usabilidade Confiabilidade
Facilidade de aprendizagem Compreensibilidade
Proteção Eficiência da modularização

Fonte: Adaptado de Sommerville, 2007, p. 653
1.4.2 Garantia da Qualidade em Projetos de Software
Há certa confusão na literatura de Engenharia de Software sobre o termo

Garantia da Qualidade, ou Quality Assurance, como é mais utilizado em inglês.
Alguns autores tratam a garantia da qualidade como sendo todo o processo de
Gerenciamento da Qualidade. Outros autores tem o mesmo entendimento que o
PMBOK (PMI, 2008) e tratam a Garantia da Qualidade com um processo do
Gerenciamento da Qualidade, sendo então responsável pela avaliação dos
resultados das medições do controle da qualidade e das auditorias e revisões
realizadas.
Pressman (2005) acrescenta que o objetivo da Garantia da Qualidade é

prover aos gerentes do projeto dados necessários para serem informados sobre
qualidade do produto, ganhando assim uma visão e confiança que a qualidade
desejada do produto está sendo atingida.
O mesmo entendimento que o PMBOK (PMI, 2008) tem o CMMI-DEV (SEI,

2010, p. 301), que define o objetivo do processo de garantia da qualidade como
sendo o de “prover à equipe de gerenciamento com visões objetivas do processo e
os respectivos produtos de trabalho”.
47
Sommerville (2007, p. 645) acrescenta a importância da utilização de

normas no processo de garantia da qualidade. Segundo ele, dois tipos de normas
podem ser usados no processo de garantia da qualidade:
Normas de Produto: aplicam-se ao produto de software que se está

desenvolvendo. Incluem padrões de documentação, como estrutura de
requisitos, por exemplo, padrões de código, como estrutura de cabeçalho
de cada definição de classe ou padrões de linguagem de programação a
ser utilizada.
Normas de Processo: aplicam-se ao processo de desenvolvimento de
software que será seguido durante o desenvolvimento do produto. Inclui a
definição de especificações, processos de validação e descrição de
documentos que devem ser escritos ao longo do desenvolvimento do
produto.
O Quadro 4 apresenta exemplos de atividades que podem ser seguidas

utilizando normas ou modelos de produto ou processo:
Quadro 4 – Padrões de Produto e Processo
Produto Processo
Formulários de Revisão de Projeto Condução da Revisão de Projeto
Envio de documentos para controle de

Estrutura da documentação de requisitos
configuração
Formato do cabeçalho das classes e
Processo de emissão de nova versão
métodos
Padrão de Código Processo de aprovação do plano de projeto
Formato do Plano de Projeto Processo de Controle de Modificação
Formulário de solicitação de mudança Processo de registro dos testes

48
Schulmeyer (2008) apresenta alguns exemplos de normas de processo a

serem utilizadas no processo de garantia da qualidade:
Padrões ISO: ISO 9000: 2005; ISO 9001:2000.

IEEE Std 730-2002; IEEE Std 829-1998; IEEE Std 1028-1997.
COBIT - Control Objectives for Information and related Technology.
RTCA/DO-178B.
ANSI/EIA-748-A-1998
Além da utilização de normas, é muito comum adoção de modelos de

maturidade na condução de projetos. Souza, Salomon e Silva (2012) apresentam os
principais modelos de maturidade em gerenciamento de projetos com destaque na
literatura e no mercado, conforme o Quadro 5.
Quadro 5 – Principais modelos de maturidade
Modelo Autor
CMMI CMU-SEI (1984)
ESI ESI (1996)
BERKELEY Kwak e Ibbs (2001)
PMMM PM (2002)
PRADO Prado (2002)
OPM3 PMI (2003)
PRINCE2 OGC (2004)
C2S Souza (2011)

Fonte: Adaptado de Souza, Salomon e Silva, 2012, p. 53
O CMMI – Capability Maturity Model Integration – é o modelo mais popular

na indústria e sua versão CMMI-DEV (CMMI for Development) é aplicada a indústria
de desenvolvimento de software (MCKINNEY, 2005).
49
Ainda segundo Sommerville (2007), o uso de normas no processo de

gerenciamento da qualidade é importante por uma série de motivos, como por
exemplo: as normas são desenvolvidas baseadas no conhecimento de diversas
empresas, bem como em experiências de sucesso da própria indústria de software e
em melhores práticas; fornecem um modelo encapsulado como gerenciar a
qualidade do projeto; por fim tornam o processo capaz de ser executado por
qualquer pessoa, sem que o conhecimento fique restrito a um único membro do
time.
Pressman (2005) diz que o papel principal do processo de garantia da

qualidade é o de suportar a equipe do projeto em alcançar o produto final de alta
qualidade. Segundo ele, esse papel é mais bem executado se for conduzido por
uma equipe independente, executando as respectivas tarefas do gerenciamento da
qualidade. O CMMI (SEI, 2010, p. 301) apresenta as seguintes tarefas como parte
do processo de gerenciamento da qualidade:
Realizar auditorias no processo que está sendo seguido e nos produtos

que estão sendo entregues verificando conformidade com aquilo que
estava planejado e descrito nos procedimentos.
Identificar e documentos todos os itens não conformes.
Prover feedback para a equipe do projeto e gerentes sobre os resultados
das atividades de garantia da qualidade.
Garantir que os itens não conformes estão sendo tratados.
Pressman (2005) acrescenta que a equipe responsável pela garantia da

qualidade de software deve coordenar a gestão da mudança no projeto, auxiliando
na coleta e analise das métricas de software. Schulmeyer (2008) completa ainda que
o engenheiro de qualidade de software deva participar de atividades chave no
processo de desenvolvimento, como por exemplo, reuniões da equipe de
desenvolvimento integrado do produto (DIP), revisões pontuais de produtos de
software, revisões técnicas de requisitos, projetos, implementação e testes, além de
conduzir o grupo de controle de modificação, ponto também ressaltado por
Pressman (2005).
50
1.4.3 Controle da Qualidade em Projetos de Software
O processo de Controle da Qualidade aplicado a projetos de

desenvolvimento de software é exatamente como em qualquer outro projeto e a
literatura apresenta a mesma definição que o PMBOK (IEEE, 2004; SCHULMEYER,
2008; PRESSMAN, 2005; SOMMERVILLE, 2007; FUTRELL; SHAFER; SAFER,
2002). A principal diferença neste ponto são as ferramentas e técnicas utilizadas,
bem como suas respectivas saídas.
Pressman (2005) diz que o controle da qualidade sob a ótica da Engenharia

de Software deve envolver uma série de inspeções, revisões e testes através do
processo de desenvolvimento de software para garantir que o produto está
atendendo aos requisitos. Mais do que isso, o autor reforça que o controle da
qualidade deve incluir um loop de retorno no processo de desenvolvimento do
produto, permitindo ações de correção ao longo do processo e não apenas após sua
conclusão.
Sommerville (2007) compartilha o mesmo conceito apresentado por

Pressman (2005) e reforça dizendo que todo o componente de software entregue
deve passar pelas rotinas de revisão e testes, conforme apresentado na Figura 16.
Figura 16 – Gerenciamento da Qualidade no Processo de Desenvolvimento

51
Unificando as duas visões apresentadas por Pressman (2005) e Sommerville

(2007), o Gerenciamento da Qualidade no processo de Desenvolvimento de
Software pode ser ilustrado conforme a Figura 17.
Figura 17 – Loop Gerenciamento da Qualidade no Processo de Desenvolvimento
Fonte: Adaptado de Sommerville, 2007, p. 643; Pressman, 2005, p. 747
Pressman (2005), porém, saliente que para que o processo de Controle da

Qualidade seja executado corretamente e, de fato, minimize os defeitos, todos os
entregáveis do processo devem ter especificações mensuráveis muito bem definidas
para que possam ser comparadas com a saída de cada processo.
Deste modo, concluí-se que o processo de Controle da Qualidade em

projetos de desenvolvimento de software é, na prática, um conjunto de técnicas e
ferramentas que avaliam o processo e o produto ao longo do seu desenvolvimento.
Podemos listar como principais técnicas identificadas na literatura:
Verificação e Validação (V&V – Verification and Validation);

Revisões software (Software Reviews);
Métricas de software (Software Metrics).
52
1.4.3.1 Verificação e Validação
Apesar de o termo apresentar dois verbos, o processo de Verificação e

Validação é sempre tratado de forma única. De maneira simples, trata-se de garantir
que o software que está sendo desenvolvido irá satisfazer os requisitos identificados
(validação) e que cada passo no processo de desenvolvimento está gerando o
produto correto, ou seja, resolvendo o problema ao qual foi criado para (verificação)
(FUTRELL; SHAFER; SAFER, 2002).
Segundo SWEBOK (IEEE, 2004, p. 11-5) ambas as atividades são iniciadas

juntamente com o processo de desenvolvimento e fornece uma análise das
características chave do produto com relação tanto a fase anterior de
desenvolvimento como com as especificações que devem ser atingidas. Para Futrell,
Shafer e Safer (ibid) A Verificação deve responder a pergunta: “estamos fazendo
certo o sistema?”, ao passo que a Validação deve responder: “estamos fazendo o
sistema certo?”.
A principal atividade deste processo é a realização de testes no produto,

rastreando-o contra seus requisitos e especificações, o que o produto deve e não
deve fazer. Obviamente a literatura traz algumas variações na definição deste
processo, bem como o melhor momento de realizá-lo ou suas principais ferramentas.
Os conceitos aqui apresentados são de fontes consagradas da Engenharia de
Software, não sendo escopo deste trabalho o detalhamento deste processo no que
diz respeito à Engenharia de Software.
1.4.3.2 Revisões de Software
Revisões de código é a técnica mais amplamente utilizada pela indústria de

desenvolvimento de software para a validação da qualidade de um processo de
desenvolvimento (SOMMERVILLE, 2007). Esta técnica pode envolver um grupo de
pessoas examinando parte ou todo o processo de desenvolvimento de software, o
sistema em si ou sua documentação relacionada. Outra técnica simples é bastante
53
utilizada é a simples revisão do código fonte sendo realizada por outro

desenvolvedor, em um sistema cruzado onde o desenvolver A examina o código
elaborado pelo B, que examina do C e assim por diante. Existem diversas técnicas
de revisão da qualidade de software, conforme apresentado pelo SWEBOK (IEEE,
2004, p. 11-5):
Revisões de Gerenciamento: essas revisões têm o objetivo de

monitorar o progresso do desenvolvimento, determinar seu status atual,
confirmar os requisitos identificados e já atendidos, bem como avaliar a
efetividade do gerenciamento feito até o momento.
Revisões Técnicas: estas revisões têm o objetivo de avaliar o produto
de software, identificando possíveis desvios com relação à especificação
e seus padrões. O resultado devem ser evidências para a gestão do
projeto que o produto atende (ou não) os requisitos, além de endereçar
as necessidades de correções identificadas.
Inspeções: as inspeções de software têm o objetivo de identificar
anomalias no produto de software. Dois importantes pontos diferenciam
inspeções de revisões: i) um individuo com posição de liderança sobre
qualquer outro membro do time de inspeção não deve participar desta
etapa e ii) a inspeção deve ser conduzida por um facilitador imparcial,
treinado para técnicas de inspeção. Além disso, a inspeção sempre
envolve o desenvolver do produto, enquanto a revisão nem sempre.
Walk-throughs (Passo a Passo): a análise passo a passo tem o objetivo
de avaliar o produto de software, principalmente no que diz respeito a
treinar as pessoas com relação a um determinado produto. Os principais
resultados desta atividade são: encontrar anomalias; melhor o produto
final; considerar alternativas de implementações mais simples; avaliar o
produto conforme seus requisitos e especificações. Esta análise é muito
similar a inspeção, porém com um nível menor de formalidade.
Auditorias: o principal propósito das auditorias de software é gerar uma
avaliação independente de conformidade do processo de
desenvolvimento e do produto de software, além de seus planos,
procedimentos, regulamentações etc. As auditorias são geralmente
aplicadas por áreas ou pessoas que não participaram do processo de
54
desenvolvimento do produto, muitas vezes são realizadas inclusive por

outras empresas ou instituições governamentais.
Pressman (2005) reforça ainda que o processo de revisão da qualidade sirva

também para promover substitutos e a continuidade do desenvolvimento, uma vez
que diversas pessoas passam a se familiarizar com partes do software que talvez
nunca tenham visto.
Cabe salientar que alguns autores descrevem as técnicas de Revisão de

Software como sendo atividades do processo de Verificação e Validação. Com o
objetivo de ser breve na descrição das principais técnicas e atividades do processo
de Controle da Qualidade foi adotado basicamente o entendimento do SWEBOK
(IEEE, 2004).
1.4.3.3 Métricas de Software
Uma métrica é uma medida numérica de produto de software, processo ou

projeto que está sendo diretamente observado, calculado ou previsto, cujo objetivo
final é prover informação necessária para a tomada de decisão ao longo do
desenvolvimento (FUTRELL; SHAFER; SAFER, 2002).
Sommerville (2007) completa que uma métrica de software é qualquer tipo

de medida relacionada com o sistema do software, com o processo ou com a
documentação relacionada, como por exemplo, a medida do tamanho do software
em quantidade de linhas de código.
O resultado dos processos de revisão ou inspeção de código apresentados

anteriormente também são exemplos de métricas de software, como por exemplo,
quantidade de problemas reportados durante uma revisão. Porém, são dispendiosos
em termos de consumo de tempo e inevitavelmente atrasam a conclusão do
desenvolvimento do sistema. Idealmente seria interessante acelerar esse processo
por meio de ferramentas automáticas, que acessam o código fonte e geram métricas
55
para a qualidade do software. Esse tipo de abordagem é muito comum na indústria e

utilizado por grandes empresas, como Hewlett-Packard, AT&T e Nokia
(SOMMERVILLE, 2007).
A definição das métricas de software e quais atributos serão utilizados para

sua identificação e medição são informações de entrada para a liderança de o
projeto tomar decisões sobre possíveis melhorias do produto, treinamento de
pessoal, investimento em cursos e capacitação de pessoas etc. A Figura 18
apresenta o ciclo de tomada de decisão com base nas métricas de software.
Figura 18 – Tomada de Decisão baseada em métricas
Futrell; Shafer; Safer (2002) classificam as métricas de software em métricas

de processo, projeto, produto e recursos.
Processo: métricas que medem a eficiência do processo, ou seja, de um

conjunto de atividades de software relacionadas.
Projeto: métricas financeiras ou de prazo do projeto, já identificadas pelo
Plano da Qualidade do Projeto.
Produto: métricas obtidas a partir do produto de software, podendo ser
qualquer componente ou artefato de software gerado ao longo do
processo.
56
Recurso: métricas geradas a partir de recursos necessários ao longo do

processo de desenvolvimento, principalmente pessoas, ou seja, sua
satisfação, nível de produtividade etc.
Sommerville (2007, p. 656) ressalta que “normalmente é impossível medir

atributos de qualidade de software diretamente”, como por exemplo, usabilidade,
mantenabilidade, facilidade de aprendizado etc., pelo simples fato de que são
atributos relacionados com como o desenvolvedor ou o usuário enxergam o produto.
Esses atributos são afetados por diversos fatores, não sendo simples sua medição.
Deste modo, muitas vezes é preciso medir uma série de atributos internos do
software e assumir que a relação entre eles mede exatamente o que está sendo
procurado.
Por este motivo, Futrell; Shafer; Safer (2002) afiram que as métricas podem
ser “diretamente observadas”, ou seja, medições observadas em um único atributo,
sem qualquer correção com algum outro; “estimadas”, ou seja, métricas geradas a
partir de atributos desconhecidos, que tenham sido obtidos por modelos
matemáticos por interpretações; e por fim métricas “calculadas ou indiretas”, que são
medições obtidas por meio de cálculos envolvendo no mínimo dois atributos. O
Quadro 6 apresenta alguns tipos de métricas de software como exemplo ao leitor.
57
Quadro 6 – Tipos de Métricas de Software
Diretamente
Estimadas Calculadas ou indiretas
observadas
Produto Número de linhas de Número de linhas de código; Eficiência – comportamento do

código; sistema pelo tempo.
Qualidade de Software;
Número de casos de Eficiência – recurso do sistema;
testes; Ocorrências de defeitos de
software; Complexidade psicológica;
Número de problemas
reportados por clientes Distribuição e características Densidade de defeitos =
não resolvidos; dos defeitos restantes (com defeitos/mil linhas de código;
base em dados de
Cobertura de testes; avaliações pelos pares e / ou Medidas de Confiabilidade (ex:
testes); tempo médio entre falhas)
Número de defeitos por
severidade Confiabilidade;
Número de itens de ação; Número de defeitos por
severidade;
Número de componentes
do sistema;
Métrica de acoplamento
de componentes.
Processo Aderência ao processo Nível SEI; Precisão da estimativa = previsto

(sim ou não) / real (meta é 1);
Nível SEI Produtividade = Linhas de
código/equipe - mensal;
Cobertura e eficiência de
avaliações pelos pares; Cobertura das revises;
Eficácia dos treinamentos Cobertura dos testes e
verificações;
Taxa de fechamento de itens de
ação;
Eficácia dos formadores;
Risco – probabilidade;
Métricas de Revisão;
Análise dos requisitos;
Métricas de Manutenção;
Projeto Custo do Projeto; Duração do Projeto; Aderência à previsão = valor

agregado (por exemplo, custo
Tempo de Custo do Projeto; real do trabalho realizado /
desenvolvimento do orçado custo do trabalho
produto; realizado);
Consumo de recursos que SPI = Schedule performance
não sejam pessoas; index
Pessoas Tamanho da equipe, em Carga dos recursos; Produtividade = Linhas de Código

ou outros número de pessoas; / mês;
Esforço;
recursos Lista de habilidades, Disponibilidade do Hardware;
esforço;
Confiabilidade do Hardware;
Experiência de
programação;
Fonte: Adaptado de Futrell; Shafer; Safer, 2002, p. 818
58
Além da classificação das métricas, Futrell; Shafer; Safer (2002) classificam

ainda os atributos de software, que podem ser internos ou externos.
Internos: atributos que podem ser medidos de forma isolada e maneira

independente do seu comportamento, como por exemplo, quantidade de
linhas de código, modularidade etc.
Externos: atributos externos são medidos com relação a como software
interage com o ambiente, como por exemplo, tempo de execução,
usabilidade etc.
Um exemplo de métricas geradas a partir de relacionamentos de atributos

conforme apontado por Sommerville (2007) é apresentado na Figura 19. O Quadro 3
também apresenta exemplos de atributos da qualidade que devem estar presentes
em um plano da qualidade de projeto.
Figura 19 – Relacionamento entre atributos internos e externos

59
Deste modo, fica claro que o Controle da Qualidade é um processo

fundamental para o Gerenciamento da Qualidade do Projeto. O objetivo final de todo
este controle, revisões, levantamento de métricas etc., é obviamente aumentar a
qualidade do produto reduzindo o número de defeitos, principalmente na fase final
do desenvolvimento do produto. Pressman (2005) apresenta na Figura 20 um estudo
sobre o aumento do custo relativo para a correção de problemas conforme a
evolução do projeto.
Figura 20 – Custo relativo para correção de defeitos de software
Fonte: Adaptado de Pressman, 2005, p. 748
É comum engenheiros de software reclamarem de atividades relacionados

ao plano da qualidade, principalmente quando envolve o preenchimento de
formulários ou execução de atividades de revisão ou monitoramento, porém a Figura
20 deixa claro a importância do controle da qualidade na eficiência do projeto, tanto
na qualidade em si como na redução dos custos.
Por fim, após a exposição da fundamentação teórica sobre o assunto

abordado nesta monografia, espera-se que este trabalho traga esclarecimentos
sobre a importância do gerenciamento da qualidade na gestão de projetos. O
próximo capítulo apresenta o estudo de caso sobre como é feito o gerenciamento de
projetos na Empresa Y.
60
2 ESTUDO DE CASO
Relata-se neste capítulo um caso de aplicação do processo de

gerenciamento de projeto de desenvolvimento de software em uma empresa do
setor aeronáutico. Inicia-se pela contextualização da indústria aeronáutica, ambiente
no qual o estudo de caso é realizado, passando pela indústria internacional e
nacional, com um subcapítulo especial sobre a EMBRAER, por ser a maior empresa
deste setor no Brasil. São discutidos também os processos de gerenciamento de
projeto de software adotados pela Empresa Y, objeto deste estudo de caso, bem
como o atual indicador de qualidade utilizado para acompanhamento dos projetos
por ela desenvolvidos. Finalmente apresentam-se os principais problemas do atual
indicador da qualidade utilizado e as expectativas de um bom indicador que reflita da
melhor maneira o resultado final obtido pelo produto desenvolvido. Propor um novo
indicador da qualidade e suas metas é o principal objetivo do estudo de caso.
2.1 A Indústria Aeronáutica
Historicamente poucos países no mundo dominam o processo completo de

fabricação de aeronaves. A Segunda Guerra Mundial foi o grande propulsor desta
indústria, acelerando o desenvolvimento de tecnologia e os processos de fabricação.
Não por caso, até a primeira metade do século XX os principais fabricantes
encontravam-se, basicamente, na Europa e Estados Unidos. Neste momento da
história a aviação militar era quase que a totalidade da indústria. Com o término da
segunda guerra mundial a aviação civil se desenvolveu paralelamente à aviação
militar, dividindo então a indústria em dois grandes ramos, o militar e o civil
(MIRANDA, 2007).
Atualmente menos de 20 países dominam o ciclo completo de

desenvolvimento de um avião e, entre eles, está o Brasil. Os Estados Unidos são os
maiores fabricantes de aviões do mundo, tanto no segmente militar quanto civil.
Miranda (2007) apresenta que das quatro empresas líderes na aviação militar, três
61
são norte-americanas. São elas a Boeing, Lockheed e Northrop. A quarta empresa

desta lista é a europeia EADS (European Aeronautic Defense and Space Company).
Na aviação civil a competição é mais acirrada, tendo sua liderança sendo alterada a
cada ano. Os Estados Unidos, com a Boeing, disputam tal liderança com a Europa
(Alemanha, França, Reino Unido e Espanha), representada pela Airbus. Hoje essas
duas empresas dividem quase que sozinhas o mercado de aviões acima de 120
lugares, tendo suas aeronaves voando em países de todo o mundo.
A disputa por mercado entre Boeing e Airbus é tão grande que muitas vezes,
para vencer a concorrência de uma grande venda, são concedidos descontos de até
30% no valor do produto. Não é raro que uma venda seja feita com margem zero de
lucro, tamanho é o desconto concedido. A vantagem em vender produtos sem lucro
e aumentar a fatia de mercado é garantir no futuro o fornecimento de peças de
reposição, uma grande fonte de receita dessas empresas e o momento em que o
lucro retorna. Além disso, o “prejuízo” de uma venda de um determinado produto
também pode ser compensado pela venda de produtos de sucesso, que dominam o
mercado mundial e garantem a receita dessas empresas, como é o caso do 737
para a Boeing, e do A-320 da Airbus. O sucesso desses dois produtos e quantidade
de vendas garantidas permitem que essas se deem ao luxo de vender outros
produtos com margem zero ou até negativa, com o único objetivo de ganhar fatia de
mercado e fidelizar mais um cliente (NEWHOUSE, 2008).
O mercado de aviação regional, ou seja, para aparelhos de até 120 lugares,

é dividido basicamente pela canadense Bombardier e pela brasileira Embraer, hoje
líder deste segmento. Porém, esse mercado possui também fabricantes de menores
como a francesa ATR, além de já possuir novos entrantes, como os chineses com a
COMAC, os japoneses com a Mitsubishi e os russos com a Sukhoi.
Nota-se que, com exceção da Embraer, todas as demais empresas estão

em países desenvolvidos e tidos de primeiro mundo, ou seja, dispõem de uma
infraestrutura mais moderna, governos mais ricos que fazem grandes encomendas,
mão de obra especializada e em abundância, além de melhor acesso a recursos
financeiros e tecnológicos. Mesmo em um cenário bastante adverso e em
desvantagem com relação a seus competidores, a Embraer conseguiu consolidar-se
62
no cenário internacional e ocupar hoje o posto de terceira maior fabricante de aviões

do mundo, liderando o mercado de aviação regional (MIRANDA, 2007).
2.2 A Embraer
A história da indústria aeronáutica brasileira confunde-se em muito com a

própria história da Embraer. A empresa foi criada oficialmente em 19 de agosto de
1969, porém sua história teve início mesmo no final da década de 30 do século XX,
quando se iniciou as primeiras experiências públicas e privadas de produção de
aviões, com o objetivo de abastecer a FAB – Força Aérea Brasileira – e o mercado
interno. Nas primeiras experiências realizadas no Brasil, foi grande a participação do
Estado, visando obter o domínio da tecnologia aeronáutica (MIRANDA, 2007).
A criação do CTA – Centro Técnico Aeroespacial – em 1945, que o projeto

de uma indústria aeronáutica nacional tomou força. Como primeira instituição criada
pelo CTA, o ITA – Instituto Tecnológico de Aeronáutica – foi o grande responsável
por geração de mão de obra especializada. Miranda (2007) afirma que nele formou-
se na graduação e pós-graduação “parte substantiva do quadro profissional para a
indústria aeronáutica”. No IPD – Instituto de Pesquisa e Desenvolvimento – por sua
vez, outro braço do CTA, nasceram os primeiros projetos desenvolvidos com
tecnologia nacional.
Miranda (ibid) reforça que o papel do Estado foi fundamental na formação de

mão de obra especializada. Além de contratar profissionais especializados do
exterior, financiou um grande número de cursos para engenheiros brasileiros em
institutos de excelência fora do país, sendo que nos anos 60 “os brasileiros
constituíam o maior grupo de estrangeiros estudando engenharia aeronáutica na
França”. Universidades dos Estados Unidos também foi o destino de alguns desses
engenheiros, entre eles estava Ozires Silva, futuro presidente da Embraer
(FISCHETTI, 2011).
63
Na década de 60 o CTA já contava com diversos projetos de aviões

nacionais, como o avião agrícola Ipanema, o planador Urupema e o avião de
transporte de passageiros, Bandeirante. Com o fracasso do governo em tentar
transferir o desenvolvimento desses projetos para a iniciativa privada existente na
época, o debate passou a ser a construção de uma indústria aeronáutica estatal. A
saída encontrada foi a criação de uma sociedade econômica mista, com fundos
públicos e privados. Foi então que em dezembro de 1969 foi criada a Empresa
Brasileira de Aeronáutica – Embraer. Com o apoio de importantes iniciativas
implementadas pelo Estado, a empresa iria “transformar ciência e tecnologia em
engenharia e capacidade industrial” (MIRANDA, 2007; EMBRAER, 2012).
O principal projeto que marcou o início da história da Embraer foi o

Bandeirante. A transferência deste projeto para a empresa garantiu ganhos
substanciais, afirma Miranda (2007), uma vez que os custos de concepção e
desenvolvimento já haviam sido efetuados pelo CTA. Outros projetos também foram
importantes para o início da Embraer, como o avião de treinamento Tucano, o jato
de treinamento avançado e ataque ao solo EMB 326 Xavante e, mais futuramente, o
programa AMX, em cooperação com as empresas Aeritalia (hoje Alenia) e
Aermacchi – que permitiu que a empresa alçasse a um novo patamar tecnológico e
industrial (EMBRAER, 2012).
Atualmente a empresa é líder mundial no segmento de aviação regional e,

na área de aviação executiva, vem investindo forte desde a década passada,
criando um portfólio de produtos que atendem a todas as categorias deste mercado.
No segmento de Defesa e Segurança, em 2011 a empresa criou a Embraer Defesa
& Segurança, uma divisão com foco específico neste mercado. Entre os principais
projetos da Embraer Defesa e Segurança está o cargueiro militar KC-390, com
conclusão prevista para 2014. No portfólio da empresa figuram também projetos já
consagrados, como o avião de treinamento e ataque leve Super Tucano, além de
projetos de modernização e revitalização, como o A1-M, modernização do caça
bombardeiro AMX; e o AF1-M, projeto de modernização dos caças A-4 Skyhowk da
Marinha do Brasil.
64
Todo esse histórico de sucesso, um grande esforço do governo e novos

projetos inovadores permitiram que hoje a Embraer fosse hoje a terceira força
mundial na fabricação de aviões, ficando atrás apenas de Boeing e Airbus. Segundo
o site oficial da Embraer (2012), atualmente a empresa emprega mais de 17 mil
pessoas, com quase US$ 13 bilhões em pedidos firmes em carteira e com uma
receita bruta de mais de US$ 5 bilhões ao ano, além de possuir quase 20 sites e
escritórios espalhados pelo mundo.
2.3 A Empresa Y
A Empresa Y possui mais de 20 anos no mercado de desenvolvimento de

softwares no Brasil e se especializou em softwares embarcados em sistemas de
missão para aeronaves de defesa. Desde sua fundação vem crescendo
exponencialmente e atualmente possui cerca de cem funcionários, tendo como
principal cliente a própria Embraer, que subcontrata seus serviços nos projetos de
defesa realizados pela Marinha, Exército e Aeronáutica.
Além de software embarcado, completam o portfólio da empresa sistemas

de simulação e softwares desktop para o planejamento e debriefing de missões
táticas realizadas pelas forças armadas.
2.4 O Gerenciamento de Projetos de Desenvolvimento de Software
Relata-se neste subcapítulo o estudo de caso sobre o gerenciamento de

projetos de desenvolvimento de software realizado na Empresa Y, mais
especificamente na área de desenvolvimento de softwares para o mercado de
Defesa, fornecendo diretamente para a Embraer Defesa e Segurança.
O processo de gerenciamento de projetos apresentado a seguir refere-se

aos projetos de desenvolvimento de software para sistemas embarcados em
65
aeronaves de defesa. A Figura 21 a seguir apresenta o macro processo Desenvolver

ou Modificar Produto.
Figura 21 – Macro processo Desenvolver ou Modificar Produto
Fonte: Adaptado de documentação interna da Empresa Y.
Este macro processo compreende os processos relacionados com o

desenvolvimento de um novo projeto ou modificação de um produto existente. Faz-
se necessário também apresentar os principais atores deste macro processo, bem
como sua disposição na estrutura organizacional da empresa. A Figura 22 ilustra tal
estrutura.
66
Figura 22 – Estrutura organizacional dos projetos de software na Empresa Y
Fonte: Adaptado de documentação interna da Empresa Y.
A supervisão funcional de software está vinculada a uma gerência de

sistemas, como por exemplo, sistemas aviônicos, sistemas aerotáticos etc. Além do
próprio supervisor, possui um líder de projeto para cada projeto de software em
execução. A área funcional, tanto gerência como supervisão, fornecem mão de obra
para os respectivos programas em andamento. Cada programa possui seu gerente,
responsável pelo acompanhamento técnico e administrativo de todos os projetos
relacionados com o respectivo programa, por exemplo, o projeto de desenvolvimento
de software.
Nesta estrutura, os trabalhos são divididos em pequenos “pacotes de

trabalho” e cada responsável pelo pacote atua como um legítimo Gerente de Projeto.
O líder de projeto de software, por exemplo, é o Gerente do Projeto de
desenvolvimento de software, atuando em todas as nove disciplinadas apresentadas
pelo PMBOK. Porém, o desenvolvimento de software é apenas uma atividade do
projeto completo de modernização do sistema aviônico de uma determinada
aeronave, que por sua vez é apenas uma atividade do projeto completo de
modernização do avião como um todo. Aqui é interessante o leitor notar que uma
67
atividade para um gerente de projeto pode ser um projeto completo para o

responsável por ela. Esse conceito é amplamente utilizado nos projetos de
desenvolvimento e modernização de aeronaves na Empresa Y.
Os processos apresentados a seguir são executados exclusivamente pelo

líder do projeto de software e sua equipe, sendo estes acompanhados pelo
supervisor funcional da área de software.
2.4.1 Processo Planejar Projeto
Este processo tem o objetivo de estabelecer o processo de desenvolvimento

de software que será utilizado no projeto em questão, bem como as ferramentas a
serem utilizadas, as linguagens de programação adotadas e o processo de
configuração e controle que será utilizado durante o ciclo de desenvolvimento do
produto.
Com base no Manual de Gestão adotado pela empresa como um todo, neste
processo as seguintes disciplinas devem ser planejadas: Gerenciamento do Escopo,
Gerenciamento do Tempo, Gerenciamento dos Custos, Gerenciamento da
Comunicação, Gerenciamento dos Recursos, Riscos e Aquisições. Além destas
disciplinas, todas as atividades de desenvolvimento de software, tais como processo
de ação corretiva, gerenciamento de requisitos e outros também devem ser
planejados nesta fase.
2.4.1.1 Indicador do Processo Planejar Projeto
Neste indicador a empresa mede a qualidade do processo por meio do

índice de aderência ao mesmo. O indicador trata da aderência média dos
planejamentos realizados no período, medida por questionário preenchido ao final
de cada planejamento. Trata-se de verificar com o responsável pelo projeto se ele
seguiu todas as atividades previstas no processo. A meta do indicador é que seja
68
sempre próximo de um, ou seja, que 100% das atividades previstas sejam
executadas. O método de cálculo do indicador é exibido na Equação 1.

Aderência = 100 (%) (1)

2.4.2 Processo Definir Requisitos
Neste processo temos as atividades relacionadas com a definição ou

alteração dos requisitos funcionais ou operacionais do software. Estes requisitos
serão utilizados na definição do escopo do projeto de Software. Conforme
apresentado por Sommerville (2007), não se trata apenas de identificar os requisitos
e especificações do produto, como é feito para produtos manufaturados, mas neste
momento também se identificam os requisitos referentes à arquitetura e projeto do
sistema.
No entanto, o que é percebido neste processo é que a definição de

requisitos passa muito mais por um processo de elicitação, onde tais requisitos são
levantados a partir de entrevistas com pilotos e engenheiros de sistema. Muitas
vezes o piloto sabe como quer operar a aeronave, porém não sabe traduzir esse
sentimento em forma de requisito. Por este motivo, os requisitos são identificados a
partir de reuniões entre o piloto e engenheiro de software. Do mesmo modo ocorre
com os requisitos funcionais, que são identificados, por sua vez, com entrevistas
juntamente com o engenheiro de sistema responsável pelo mesmo.
2.4.2.1 Indicador do Processo Definir Requisitos
Neste processo a empresa mede a razão entre o número de problemas

reportados (PR) durante a fase de desenvolvimento do software com origem em
falha na identificação dos requisitos pelo número de total de problemas identificados
com outras origens identificadas no período da medição.
69
A medição é feita a cada mês e a cada 50 problemas reportados no período.

O método de cálculo é apresentado na Equação 2.
& ' ()* )+* * ,- )

!"#$!$% = 100 (%) (2)
& ' ()* )- )+.
2.4.3 Processo Implementar Bloco
Implementar Bloco é o processo responsável por desenvolver software que

atenda aos requisitos funcionais e operacionais identificados no processo anterior,
incluindo os requisitos referentes à arquitetura do software. Ele é composto de
atividades de projeto, codificação, testes unitários, revisão de código e tarefas
adicionais. A conclusão deste processo é realizada mediante a comunicação para
todos os stakeholders que um novo release de software foi liberado, contendo
determinadas novas funcionalidades ou correções de problemas reportados.
2.4.3.1 Indicadores do Processo Implementar Bloco
Este processo possui dois indicadores para monitoramento, o a) Índice de

Qualidade do Bloco e b) Índice de Completude do Bloco.
a) Índice de Qualidade do Bloco
O objetivo deste indicador é avaliar a proporção de problemas relacionados

a um bloco relativamente à quantidade de requisitos implementados do mesmo.
Trata-se de monitorar o número de problemas abertos em relação ao número de
requisitos implementados. Deste modo, valores mais altos indicam maior qualidade.
A Equação 3 apresenta o método de cálculo do indicador.
& '
!"#$!$% = 1 − 0 2 (3)
& ,- ) *1*. )
70
b) Índice de Completude do Bloco
Este indicador tem como objetivo medir a proporção dos requisitos

planejados para o bloco que foi realmente implementada pela equipe de
desenvolvimento. Ele fornece subsídios para indicar se a capacidade da equipe está
suficiente para a carga de trabalho prevista. Trata-se de medir a razão entre o
número de requisitos efetivamente declarados como implementados pelo time
desenvolvimento após conclusão do bloco e o número de requisitos planejados para
o bloco. Portanto, valores mais altos deste índice indicam que a equipe está dando a
adequada "vazão" para implementar os requisitos definidos. A Equação 4 apresenta
o método de cálculo do indicador.
& ,- ) *1*. )

3456"%7 $% = 100 (%) (4)
& ) ,- ) 1 )
2.4.4 Processo Liberar Software
Liberar Software é um processo que abriga todas as atividades e tarefas

relacionadas com a entrega formal do software desenvolvido, bem como com sua
documentação oficial, incluindo o documento que descreve a versão atual liberada,
chamado VDD - Version Description Document. O objetivo deste processo é
formalizar a entrega de uma versão de software para instalação no produto final,
seja para ensaio em voo ou entrega final.
2.4.4.1 Indicador do Processo Liberar Software
O cliente final deste processo é outra área da empresa, responsável pela

execução dos ensaios em voo ou em solo do produto, além de realizar a entrega
final para o cliente. Deste modo, o indicador deste processo refere-se à qualidade do
mesmo, tendo como o conceito de qualidade a percepção do cliente que recebe o
produto, ou seja, esta outra área interna mencionada acima. Quando o cliente fica
71
insatisfeito com o produto, há um mecanismo interno de reporte de problema, seja

técnico, não aderência ao processo ou mesmo uma oportunidade de melhoria. Deste
modo, o índice de qualidade mede a quantidade de reclamações abertas pelo cliente
interno relacionada ao release de software. Obviamente a meta é zero, ou seja, não
é desejável qualquer tipo de reclamação por parte do cliente.
2.4.5 Processo Gerenciar Mudanças
Gerenciar Mudanças é o processo responsável por gerenciar as mudanças

de produtos, seja por erros de implementação, requisitos modificados ou novos
requisitos. O objetivo deste processo é garantir a qualidade na priorização, avaliação
e resolução das alterações de produto geradas a partir dos novos requisitos,
requisitos modificados ou erros de implementação. Este processo realimente
diretamente o escopo do projeto, avaliando de determinada alteração é conflitante
com algum requisito já aprovado anteriormente, se faz parte do que foi contratado
pelo cliente ou definido pelo piloto.
A principal atividade deste processo é a coordenação de um board para

análise e aprovação das mudanças de produto. Esta atividade é realizada mediante
reunião de SCCB – Software Configuration Control Board – que é conduzida pelo
líder do projeto em questão, no qual avalia as mudanças propostas, debate com
todos os envolvidos e a aprova ou recomenda alguma alteração.
Por ser um processo recém-implantado pela empresa, ainda não possui um

indicador de controle.
2.4.6 Processo Gerenciar Projeto
Gerenciar Projeto é o processo que abriga todas as atividades de gestão

relacionadas ao processo de desenvolvimento de software como um todo. Este
processo é baseado no modelo de gestão de projeto adotado pela empresa em
72
geral. Basicamente, preocupa-se com as disciplinas de gestão: DIP –

Desenvolvimento Integrado do Produto – gestão das interfaces com outras áreas do
desenvolvimento, escopo, cronograma, recursos, comunicação, riscos e aquisições
de serviços de terceiros.
O objetivo deste processo é garantir a realização das metas acordadas em

relação ao planejado, com relação ao uso de homens-horas, identificar a demanda
de recursos e fornecer visibilidade do status do projeto para o gerente.
2.4.6.1 Indicador do Processo Gerenciar Projeto
Este processo possui três indicadores para monitoramento, o a) índice de

prazo; b) índice de custo; e c) índice de comunicação.
a) Índice de Prazo
Este indicador mede diferença entre a soma dos pesos percentuais

atribuídos a cada entrega pactuada com o gerente do projeto e a soma dos pesos
percentuais efetivamente entregues pela equipe de desenvolvimento ao longo do
ano. O indicador é medido separadamente para cada projeto em andamento.
O objetivo deste indicador é medir o desvio de prazo das entregas

pactuadas entre a equipe de desenvolvimento e área responsável por realizar a
gestão do DIP com relação ao que foi efetivamente cumprido pela ao longo do ano.
A meta é que fique acima de 99%. A Equação 5 apresenta o método de cálculo do
indicador.
Í8$#9% $% :;!<4 = 100 − 100 × >?@:3(#) − (:3(#) × :3(#))AD (%) (5)

BC
Onde:
73
# representa a “i-ésima” meta pactuada entre gerente do programa e o

gerente do projeto vencida até o momento de medição.
:3(#) é o Percentual de Cumprimento da meta em questão. Será 0 se a
entrega em questão não foi realizada no prazo. Será 1 se a entrega foi
feita no prazo e cumpriu o total do escopo pactuado. Será um valor entre
0 e 1 proporcional ao percentual do escopo entregue na data pactuada,
alinhado entre o Líder de Desenvolvimento de Software e o cliente, em
caso de entrega parcial.
:F(#) é o Peso da Meta em questão. Os pesos de cada meta são
atribuídos em conjunto com a equipe do projeto, conforme os objetivos
estratégicos da empresa.
b) Índice de Custo
Este indicador tem como objetivo medir a diferença prevista entre o

engajamento e o orçamento em HH (Homem Hora) ao final do ano corrente. Uma
diferença fora das especificações indica a necessidade de atuação por parte da
gestão para correção do problema. Trata-se de medir o percentual da soma do HH
efetivo de janeiro até o mês corrente com a soma do HH planejado do mês seguinte
até dezembro, dividido pelo total de HH orçado para o ano todo na última revisão de
base do projeto. A situação ótima corresponde a um valor igual a 100%, indicando
não haver diferença entre o orçamento alocado e a estratégia de efetivo no ano.
c) Índice de Comunicação
Este indicador tem o objetivo de comunicar em tempo hábil aos clientes

(DIP) e demais stakeholders sobre a possibilidade de não cumprimento de metas
pactuadas, de modo a tornar possível a tomada de ações de recuperação.
Basicamente, cada líder de projeto de software reporta a possibilidade de não
cumprimento de metas pactuada no sistema de comunicação utilizado pela
empresa, baseadas em sites na intranet referentes a cada projeto. Todas as metas
devem são reportas, inclusive as que estão com tendência de cumprimento. Deste
modo, de todas as metas em questão será possível indicar quais possuem tendência
de atraso ou não.
74
O indicador é calculado pela razão entre o número de metas atualizadas

para o semestre corrente pelo número total de metas. A meta é sempre 100%, ou
seja, todas as metas do semestre tiveram sua tendência de conclusão indicada no
site.
2.5 Torre de Controle
Além de todos os indicadores de cada um dos processos apresentados, a

área de desenvolvimento de software possui indicadores macro, que apresentam
dados consolidados de todos os projetos em execução. Esses indicadores são
apresentados na chamada Torre de Controle, um painel físico exposto na parede
principal da área onde está localizada a equipe. Além deste painel, há também sua
versão eletrônica no site da área de software na intranet da empresa. A Torre de
Controle apresenta os seguintes indicadores da área:
Acidentes de trabalho: apresenta o número de acidentes de trabalho

com afastamentos ocorridos no mês.
Satisfação do cliente interno: apresenta o resultado de pesquisas de
satisfação realizadas com clientes internos dos processos corporativos
da área de desenvolvimento de software.
Índice de Qualidade: este é um dos principais indicadores da Torre de
Controle e, por ser objeto de estudo deste trabalho, será detalhado no
subcapítulo a seguir.
Índice de Entregas: este indicador tem o objetivo de medir a quantidade
de entregas realizadas no mês em relação ao que estava planejado. Esta
medição é feita por produto e apresentada em percentual conforme o
previsto versus planejado.
Índice Financeiro: apresenta o índice atual do custo de desenvolvimento
do produto versus o custo que foi orçado durante o planejamento. Esta
medição também é feita por produto e apresentada em percentual
conforme o previsto versus planejado.
75
Índice do Clima Organizacional: apresenta o percentual de

avançamento do plano de melhoria do clima organizacional realizado
pela área em questão. Trata-se do acompanhamento de pequenas ações
para que o clima organizacional seja satisfatório, conforme metas
estabelecidas pela alta gestão da empresa.
2.5.1 Índice de Qualidade da Torre de Controle
O indicador da qualidade da Torre de Controle é um índice baseado no

número de reclamações abertas pelo cliente final para um determinado produto. Seu
objetivo é acompanhar a qualidade dos produtos entregues do ponto de vista do
cliente, deste modo a principal entrada deste indicador é o número de reclamações
abertas após a entrega do produto. Seu cálculo é feito conforme Equação 6.
Í8$#9% = HIJ × IKL ÷ NOI: (6)
Onde:
Índice é o valor compilado de reclamações por número de requisitos de

todos os produtos.
SRA – Soma das Reclamações Abertas – é a soma das reclamações
abertas por cliente para todos os produtos.
REF é um valor de referência baseado em dados históricos, obtidos de
um projeto do passado cuja aceitação do cliente foi excelente. Neste
projeto houve três reclamações do cliente para cada 8005 requisitos, com
isso o valor de referência é de 2668 requisitos por reclamação. Este dado
é considerado bom, uma vez que o cliente é totalmente satisfeito com o
produto e este, por sua vez, atende a todos os requisitos operacionais e
funcionais, sendo um case de sucesso e vendido para quase 10 países
em todo mundo.
NTRP é a soma do número total de requisitos dos produtos.
76
O índice compilado consiste na soma das reclamações abertas de todos os

produtos, dividido pela soma dos requisitos implementados de todos os produtos,
vezes o valor de referência. Este valor entra como input na Equação 7 resultando no
Indicador de Qualidade compilado da área de Desenvolvimento de Software.
W() = −10 + 100 (%) (7)
Deste modo, é possível observar que um projeto com zero defeito terá uma
qualidade de 100% e um projeto com três defeitos e 8005 requisitos, terá um índice
de qualidade igual a 90%. Observa-se também que o índice está diretamente
vinculado com a quantidade total de requisitos do produto, o que caracteriza sua
complexidade e justificaria um número maior de reclamações, mantendo o valor da
qualidade percentualmente igual. A Tabela 1 evidencia a relação direta entre a
quantidade de defeitos nos produtos e o Índice de Qualidade dos Projetos.
Tabela 1 – Relação da Qualidade com a Quantidade de Defeitos no produto
SRA Índice de Qualidade

0 100%
3 90%
6 80%
9 70%
12 60%
15 50%
18 40%
21 30%
24 20%
27 10%
30 ou mais 0%
Fonte: Material Interno da Empresa Y.
O projeto utilizado como referência para obtenção do cálculo foi selecionado

em comum acordo entre os membros da área de Desenvolvimento de Software. O
valor de 3 reclamações para cada 8005 requisitos foi considerado satisfatório, porém
77
não o ponto ideal ainda. Sendo assim, foi consenso que tal referência não deve ser
um padrão de qualidade total a ser perseguida pela área, mas sim que projetos com
esse desempenho tenham sua qualidade considerada como sendo 90% do ideal.
Obviamente a meta é de 100%, ou seja, que não haja reclamações dos clientes uma
vez que o produto foi entregue.
A Tabela 2 apresenta os valores do Índice de Qualidade da Torre de

Controle da Empresa Y dos últimos seis meses. Os valores são referentes a todos
os produtos de software embarcado consolidados.
Tabela 2 – Índice de Qualidade da Torre de Controle da Empresa Y
Mês (2012) Índice de Qualidade

ABRIL 94,9%
MAIO 93,5%
JUNHO 92,0%
JULHO 94,3%
AGOSTO 93,5%
SETEMBRO 93,5%
Fonte: Material Interno da Empresa Y.
O valor de 93,5% de Índice de Qualidade do mês de setembro, por exemplo,

significa que neste mês houve 0,65 reclamações para cada 1000 requisitos de
produto. Conforme a Equação (7), este valor substitui a incógnita x, gerando então o
valor do Índice de Qualidade. Note que neste mês o desempenho dos projetos em
andamento é considerado satisfatório, pois está acima da marca de referência de
90%.
Para se ter uma ideia do grau de complexidade dos projetos envolvidos, no

mês de Setembro/2012 o Índice de Qualidade da Torre de Controle foi formado pela
consolidação dos valores de 4 projetos, que juntos somavam aproximadamente
40.000 requisitos. Trata-se de uma média de dez mil requisitos por projeto. Somente
um dentre esses quatro projetos trata-se de um software com mais de 555.000
linhas de código, desprezando linhas exclusivas de comentários.
78
A grande quantidade de requisitos por si só pode ser fonte de erros no

projeto. Um estudo realizado em um projeto da Força Área Americana mostrou que
os requisitos foram responsáveis por 41% dos erros do projeto se comparado com
todos os erros encontrados, entre eles erros de projeto de software (logic design),
interface, dados, ambiente, fatores humanos, documentação e outros (HOOD et al.,
2008, p. 13).
Ao contrário do Índice de Qualidade da Torre de Controle, que consolida a

informação de todos os projetos, o Processo Implementar Bloco, apresentado no
item 2.4.3, é executado por todos os projetos e apresenta o seu próprio indicador da
qualidade para cada projeto. Este indicador, por sua vez, está relacionado
diretamente com os problemas reportados internamente pela área de testes da
Empresa Y. Com isso, quanto maior o número de problemas identificados neste
momento, menor a probabilidade de tal problema ser identificado pela cliente ao
receber o produto.
Deste modo, com os processos internos sendo executados pelos projetos e

com a Torre de Controle gerenciando a qualidade do ponto de vista do cliente, a
área de desenvolvimento de software gerencia todo o ciclo de desenvolvimento do
ponto de vista da qualidade, analisando os problemas reportados internamente, por
meio do Processo Implementar Bloco, e os problemas reportados pelo próprio
cliente, por meio da Torre de Controle. No próximo capítulo serão discutidos os
problemas de cada medição e as necessidades apontadas por profissionais da
Empresa Y com relação à medição da qualidade de seus produtos.
Finalmente, depois de apresentar o estudo de caso da Empresa Y, mostrar

como são os processos e indicadores atuais, espera-se que o conteúdo apresentado
nesse capítulo sirva como guia para o capítulo seguinte, Discussão, no qual será
feito uma análise dos processos atuais apresentados e interligados com a base
teórica desenvolvida na primeira parte desta monografia.
79
3 DISCUSSÃO
A partir do levantamento bibliográfico realizado no capítulo de

Fundamentação Teórica, apresentado anteriormente, e do estudo de caso realizado
na Empresa Y, apresenta-se neste capítulo uma discussão sobre os processos
adotados pela empresa estudada confrontando-os com as informações levantadas
na primeira etapa desta monografia, apresentando as práticas que estão alinhadas
com a literatura e possíveis pontos de melhoria a serem propostos para implantação
na empresa.
Para análise do estudo de caso realizado, foram consultados dois

profissionais da Empresa Y a fim de se validar o estudo realizado e levantar os
principais problemas dos atuais processos e indicadores no que diz respeito ao
gerenciamento da qualidade.
3.1 Apresentação dos Entrevistados
Devido às normas internas vigentes na Empresa Y sobre propriedade

intelectual e segurança da informação, a mesma restrição em divulgar o nome real
da empresa ocorre na divulgação do nome dos entrevistados. Deste modo, os
profissionais entrevistados são apresentados com letras de identificação, sendo
então chamados de “Entrevistado A” e “Entrevistados B”.
Entrevistado A – Atua como Engenheiro de Desenvolvimento de

Software Embarcado na Empresa Y há mais de 15 anos, tendo
participado em todos os principais projetos já realizados pela empresa
nesse período. Atualmente ocupa uma posição de liderança técnica,
sendo consultado por todos os demais profissionais da empresa, além de
ser o atual responsável pelo Processo Gerenciar Projeto, apresentado no
subcapítulo 2.4.6.
80
Entrevistado B – Começou a carreira na Empresa Y por meio de um

programa de trainee, tendo acumulado muita experiência na área de
desenvolvimento de software para estações de solo em projetos da área
de defesa. Atualmente ocupa uma posição de liderança, sendo a
supervisora da área de desenvolvimento de software da Empresa Y.
3.2 Preparação da Entrevista
Para a preparação da entrevista realizada com os profissionais escolhidos,

tomou-se como base os próprios processos internos da empresa e o estudo de caso
realizado, comparando-o com o que apresenta a fundamentação teórica desta
monografia.
Durante a entrevista tentou-se abordar as principais áreas que formam o

conjunto de conhecimentos da disciplina Gestão de Projetos e, ao mesmo tempo, os
processos internos utilizados na empresa. O autor, no papel de entrevistador,
realizou perguntas a fim de obter dos entrevistados quais seriam, na visão deles, as
principais deficiências dos processos de gerenciamento, bem como dos atuais
indicadores de qualidade, sempre respeitando o escopo de estudo desta
monografia. Além disso, perguntou-se também que tipo de indicador da qualidade os
entrevistados sentem falta e acreditam que haveria um ganho de qualidade no
produto se tal indicador fosse elaborado.
O resultado da entrevista foi documentado em ATA e aquilo que foi permitido

pela Empresa Y em ser publicado é apresentado no próximo subcapítulo.
3.3 Análise e Discussão da Entrevista
Foi realizada apenas uma entrevista com os dois entrevistados

simultaneamente, de modo a obter a percepção e unir as ideias de ambos em um
mesmo momento.
81
A entrevista durou pouco mais de uma hora e o resultado vai ao encontro da

hipótese central desta monografia, pois ambos acreditam que o processo de
Gerenciamento da Qualidade pode contribuir para evolução e manutenção da
qualidade do produto e, além disso, para a criação de um indicador da qualidade
interno, diferente dos atuais já utilizados.
O Entrevistado A comentou que o processo Implementar Bloco é o processo

responsável pelas atividades do desenvolvimento de software e que seu indicador
da qualidade monitora o número de problemas identificados no bloco. O produto final
de cada projeto é formado por diversos blocos, variando conforme o tamanho e
complexidade do produto1. Sendo assim, o indicador de qualidade deste processo se
torna um vetor de blocos, cada um com seu índice de qualidade. Ainda segundo ele,
essa abordagem torna o indicador difícil de ser medido, uma vez que leva em
consideração a quantidade de PR’s abertos para àquele bloco. Muitas vezes, um
bloco é testado pela equipe de testes bem depois de seu release, fazendo com que
a identificação de um PR neste momento afetará o índice de qualidade de um bloco
antigo, contribuindo em nada para a melhoria da qualidade do mesmo, uma vez que
já foi inclusive finalizado. Além disso, atualmente não é executada pela Empresa Y a
análise de causa raiz de um PR, ou seja, nada é feito para que um mesmo problema
não venha a ocorrer novamente no futuro.
A Entrevistada B endossa o que foi comentado pelo Entrevistado A e

completa ainda que o segundo mecanismo de monitoramento da qualidade
existente, o Índice de Qualidade da Torre de Controle, é medido com base nas
reclamações abertas pelo cliente final sobre o produto como um tudo, não tendo
qualquer vínculo com um bloco específico.
Ambos reforçam que o indicador da qualidade do processo Implementar

Bloco é de difícil monitoramento e que, mesmo com todos os dados identificados,
sua informação não permite uma rápida reação e tomada de decisão para correção
de problemas e melhoria do processo. Seus números são informações importantes
de visibilidade, porém não indicam uma tendência de melhoria ou perda da
1
Em média, ao longo do ciclo completo de um projeto de desenvolvimento de software na Empresa
Y, são gerados entre três e vinte blocos.
82
qualidade do produto. Além disso, é consenso também entre os entrevistados que o

Índice de Qualidade da Torre de Controle traz uma informação importante, a
qualidade do ponto de vista do cliente, porém nenhum dos indicadores dos
processos atuais existentes está vinculado com este, ou seja, não há um meio de se
obter uma tendência de que o Índice de Qualidade vai melhorar ou piorar, isto é,
com a melhoria do processo de desenvolvimento obtida através de tais ações e
demonstrada por tais indicadores, o cliente consequentemente detectará menos
problemas e o Índice de Qualidade tende a subir a níveis cada vez melhores.
Esse tipo de visão sistêmica do processo é uma necessidade apontada pela

liderança e compartilhada pela Entrevistada B, que como líder da área de
desenvolvimento de software sente necessidade de tal visibilidade.
Por fim, após a elaboração do estudo de caso e do registro da percepção de

profissionais envolvidos nos processos estudados, dar-se-á início no próximo
subcapítulo a uma análise completa de todas as informações obtidas e da discussão
final sobre os resultados desta monografia.
3.4 Análise e Discussão Final
Pode-se observar durante a elaboração deste estudo de caso que a

Empresa Y faz uso de diversas áreas do conhecimento da disciplina de Gestão de
Projetos. No Processo Planejar Projeto, por exemplo, há a preocupação com as
disciplinas de Gerenciamento do Escopo, Gerenciamento do Tempo, Gerenciamento
dos Custos, Gerenciamento da Comunicação, Gerenciamento dos Recursos, Riscos
e Aquisições. A coleta de requisitos, uma das principais atividades do
Gerenciamento do Escopo segundo o PMBOK (PMI, 2008), é de responsabilidade
do processo interno Definir Requisitos. Algumas das principais atividades da área de
conhecimento do Gerenciamento de Escopo, por sua vez, são refletidas no processo
Gerenciar Mudanças, na qual ocorrem reuniões de um board para análise a
aprovação das mudanças, disparando assim diversas ações para atualização de
toda documentação envolvida. Por fim, o processo interno da Empresa Y, chamado
83
Gerenciar Projeto, se apresenta como um grande guarda-chuva contendo atividades

de todas as áreas do conhecimento durante a fase de execução, em especial o
Gerenciamento da Integração do Projeto (PMI, 2008).
O Quadro 7 apresenta o relacionado dos processos internos da Empresa Y

com as áreas do conhecimento apresentadas pelo PMBOK (PMI, 2008).
Quadro 7 – Processos da Empresa Y relacionado com as áreas de conhecimento do PMI.
Grupo de processo de gerenciamento de projetos

Execução,
Iniciação Planejamento Monitoramento e Encerramento
Controle
Áreas de
conhecimento
Requisitos
Requisitos
Requisitos
Requisitos
Mudanças
Mudanças
Mudanças
Mudanças
Gerenciar
Gerenciar
Gerenciar
Gerenciar
Gerenciar
Gerenciar
Gerenciar
Gerenciar
Software
Planejar
Planejar
Planejar
Planejar
Projeto
Projeto
Projeto
Projeto
Projeto
Projeto
Projeto
Projeto
Liberar
Definir
Definir
Definir
Definir
Gerenciamento da
X X X X X
Integração
Gerenciamento do
X X X X X X X X
Escopo
Gerenciamento do
X X X X
Tempo
Gerenciamento
X X X X
dos Custos
Gerenciamento da
2
X
Qualidade
Gerenciamento
dos Recursos X X X X
Humanos
Gerenciamento
X X X X
das Comunicações
Gerenciamento
X X X X
dos Riscos
Gerenciamento
X X X X
das Aquisições
Nota-se claramente que quase todas as áreas do conhecimento estão

refletidas nos processos internos da Empresa Y de alguma maneira, mesmo que
todos os 42 subprocessos previstos no PMI não sejam executados em sua
2
Não há evidência do Gerenciamento da Qualidade na fase de Monitoramento e Controle do Projeto,
apenas na fase de Execução, por meio do processo Gerenciar Mudanças.
84
totalidade, ficou evidenciado neste estudo de caso que a Empresa Y de fato segue
as práticas do PMBOK em sua gestão de projetos (PMI, 2008). No entanto, o Quadro
7 evidência que uma das áreas do conhecimento não está completamente refletida
nos processos internos, o Gerenciamento da Qualidade. Embora o processo
Gerenciar Mudanças demonstre preocupação com a Realização da Garantia da
Qualidade, uma vez que realiza o Controle Integrado de Mudanças, prática citada no
subcapitulo 1.2.3.2, as demais ferramentas propostas pelo PMBOK (PMI, 2008) não
são executadas, tornando até mesmo o processo de Garantia da Qualidade
incompleto. Além disso, não há evidências da execução do Planejamento e do
Controle da Qualidade, que ocorre respectivamente nas fases de Planejamento e
Monitoramento e Controle do Projeto.
De qualquer forma, pode-se afirmar, contudo, que há de fato uma

preocupação com o Gerenciamento da Qualidade por parte da Empresa Y, uma vez
que existem dois indicadores específicos sobre o assunto, ambos denominados
Índice de Qualidade, sendo o primeiro apresentado no processo Implementar Bloco
e o segundo na Torre de Controle. Além destes indicadores mais específicos, outros
indicadores de aderência dos processos contribuem para medição da qualidade,
como por exemplo, o Indicador do processo Planejar Projeto. Nestes casos, a
empresa assume que o processo desenhado é a melhor maneira de se obter a
qualidade esperada pelo cliente, deste modo segui-lo seria uma maneira garantir a
qualidade, ou seja, um indicador de aderência ao processo indiretamente mede a
qualidade do produto final.
Posto isso, faz-se pensar que área de conhecimento Gerenciamento da

Qualidade estaria refletida nesses indicadores apresentados, porém, conforme
apresentado na primeira etapa desta monografia e muito claramente exposto pelos
profissionais entrevistados, os indicadores atuais não são suficientes para medir a
Qualidade do Produto, uma vez que não estão sendo gerados e monitorados sob as
práticas do Gerenciamento da Qualidade. O indicador da qualidade do processo
Implementar Bloco, por exemplo, mede a qualidade da versão de software liberada,
porém sua aquisição ocorre posteriormente ao processo executado e muitas vezes
não há mais tempo de reação, ou seja, o indicador apenas apresenta uma foto do
passado. Já o indicador da Torre de Controle, como seu objetivo é demonstrar a
85
evolução dos resultados da área como um todo, com foco nas metas da Empresa e
das partes interessadas, o indicador da qualidade apresentado não é por projeto,
mas sim consolidado entre todos os projetos conforme já citado anteriormente.
Embora seja possível visualizar o valor específico de cada projeto em outras
planilhas de controle, na Torre em si é apresentado apenas o valor consolidado.
Essa abordagem é excelente para o monitoramento da área em geral, porém a boa
qualidade de um projeto pode mascarar o mal resultado de outro. Além disso, seu
efeito é tardio, pois é calculado com base nas reclamações abertas pelo cliente final,
ou seja, o erro já passou por todas as etapas do desenvolvimento e foi detectado
apenas na operação. Além disso, conforme comentado pelo Entrevistado A, não há
análise de causa raiz dos problemas abertas, possibilitando assim que o mesmo
problema venha a ocorrer.
Segundo Terribili Filho (2010, p. 26), um indicador deve atender a dois

requisitos: “permitir comparações históricas para se avaliar as variações ocorridas e
permitir estabelecer prognósticos (projeções)”. Terribili Filho completa ainda que um
indicador represente o projeto “naquele dado momento”. Essas características são
encontradas apenas no Índice de Qualidade da Torre de Controle, porém não no
indicador de qualidade do processo Implementar Bloco. Cabe ressaltar, no entanto
que este indicador não é falho, muito menos que o autor sugere que o mesmo deixe
de ser monitorado. Trata-se de um indicador importante para aquilo que ele foi
criado, ou seja, monitorar a qualidade do bloco desenvolvido. O que se pretende
com este trabalho e o que foi observado durante a entrevista com os profissionais é
que tais indicadores não atendem a expectativa da liderança por não permitir ações
para correções de rumo antes de o problema ser detectado pelo cliente final, o que
causa um desgaste da imagem da empresa além de custos de retrabalho.
O Índice de Qualidade da Torre de Controle é exatamente um exemplo do

desgaste e do custo gerado por problemas detectados pelo cliente. A Figura 20
apresenta o custo relativo para correções de software e, segundo Pressman (2005),
problemas detectados na operação apresentam um custo de correção entre 40 e
1000 vezes maior do que se fosse identificado na fase de projeto e codificação, por
exemplo.
86
Como o objetivo geral desta monografia é estudar como o gerenciamento da

qualidade pode contribuir para a Gestão de Projetos de desenvolvimento de
software, umas das soluções para a redução deste custo da não qualidade é a
aplicação não só da própria gestão da qualidade apresentada pelo PMBOK (PMI,
2008), mas também dos pontos apresentados por Pressman (2005, p. 744) sobre o
gerenciamento da qualidade de software, pontos estes muito direcionados para a
atual necessidade da Empresa Y. O primeiro deles é a definição clara do termo
Qualidade de Software. O que é entendido sobre o termo dentro da Empresa Y?
Este primeiro ponto é ratificado inclusive por Sommerville (2007). O segundo ponto
apresentado por ele é a criação de um conjunto de atividades auxiliares para que o
software seja desenvolvido com alta qualidade. O terceiro é a realização destas
atividades, bem como seus controles. Finalmente, o quarto ponto é a utilização de
métricas que auxiliem na tomada de decisão estratégica da empresa.
Para que cada um desses pontos seja abordado no ciclo de

desenvolvimento de produto da Empresa Y, sugere-se neste trabalho que seja
criado um processo interno específico para o Gerenciamento da Qualidade. Outra
abordagem seria que os atuais processos internos da empresa sejam alterados de
modo a refletir os conceitos do Planejamento da Qualidade, Garantia da Qualidade e
Controle da Qualidade.
3.4.1 Proposta para o Planejamento da Qualidade
Conforme mencionado anteriormente, definir claramente o termo qualidade

de software é algo fundamental para que possa ser iniciado o processo de
gerenciamento da qualidade. É preciso estabelecer o escopo da qualidade de
software e até que nível ela será gerenciada.
Conforme apresentado no Quadro 2, para SWEBOK (IEEE, 2004) o processo

de Planejamento da Qualidade deve ser aplicado exatamente como apresentado
pelo PMBOK (PMI, 2008). Com isso, sugere que a definição do termo qualidade de
software, apontada por Pressman (2005) seja realizada durante o Planejamento da
87
Qualidade e que o processo interno Planejar Projeto, apresentado no item 2.4.1,

tenha como saída, além das atuais, as saídas propostas pelo PMBOK no
planejamento da qualidade, conforme apresentado na Figura 4.
Não é escopo deste trabalho criar um Plano de Gerenciamento da Qualidade

para a Empresa Y, uma vez que isto seria assunto suficiente para um futuro trabalho
específico, porém sugere-se que das Ferramentas e Técnicas apresentadas pelo
PMBOK, o Plano da Qualidade a ser desenvolvido contenha, além dos itens
propostos por Sommerville (2007, p. 652) e apresentados no subcapitulo 1.4.1, ao
menos as seguintes:
Gráficos de Controle – O PMBOK (PMI, 2008) apresenta os gráficos de

controle como sendo uma ferramenta para determinar se um processo é
estável ou se apresenta uma previsibilidade. Sugere-se então que a
evolução do cumprimento dos requisitos seja acompanhada pela equipe
do projeto por meio de gráficos, sendo divulgados e de fácil acesso a
todos os membros. Essa ferramenta permitiria então monitorar o ritmo de
desenvolvimento do grupo, quantos requisitos por mês são
implementados em média, além de permitir a extração de outras
métricas, ajudando nas estimativas de esforço e prazo que
eventualmente serão necessárias ao longo do desenvolvimento.
Amostragem estatística – O PMBOK (PMI, 2008) afirma que a técnica
de amostragem estatística envolve a escolha de parte de uma população
de interesse para inspeção, cuja frequência e tamanho da amostra
devem ser determinados durante o processo de planejamento da
qualidade. Sugere-se então que no processo Planejar Projeto seja
definido pontos para Verificação e Validação do produto de software.
O PMBOK (ibid) sugere ainda que sejam adotados metodologias

proprietárias de gerenciamento da qualidade como Ferramentas e Técnicas do
Planejamento da Qualidade. Sugere-se então que para as atividades de Verificação
e Validação sejam incluídas técnicas apresentadas pelo SWEBOK (IEEE, 2004) e
pelo CMMI-DEV (SEI, 2010).
88
Segundo o CMMI-DEV (SEI, 2010) a Validação deve demonstrar que o

produto ou componente atende ao uso pretendido quando instalado no ambiente em
que foi proposto, ou seja, sugere-se que a cada Bloco gerado no processo
Implementar Blocos sejam realizados testes de validação no ambiente real em que o
produto será instalado. Esses testes devem ser formais, tendo seus resultados
registrados em relatórios e o processo realimentado conforme necessidade. Caso
necessário o processo Gerenciar Mudanças pode ser acionado para que um
problema encontrado durante a validação seja corrigido. O processo de Verificação,
por sua vez, segundo CMMI-DEV (ibid) tem o objetivo de garantir que o produto
atende os requisitos da maneira correta. Dentre as atividades de verificação
apresentadas pelo CMMI-DEV (ibid) e SWEBOK (IEEE, 2004), sugere que a
Empresa Y planeje ao longo do ciclo de desenvolvimento de software atividades de
Revisões Técnicas e Inspeção de Software.
Revisão Técnica – Conforme apresentado no subcapitulo 1.4.3.2, as

revisões de software devem ser feitas seguindo um procedimento
específico e sugere que seja realizada de duas maneiras: 1) Todo
desenvolver de software deve revisar seu próprio pacote de trabalho
antes de integrá-lo ao produto final, realizando uma revisão menos
rigorosa e com auxílio de ferramentas que automatizem o processo,
evitando assim um aumento do ciclo de desenvolvimento; e 2) ao longo
do ciclo de desenvolvimento de software devem ser planejadas revisões
técnicas formais, que segundo o CMMI-DEV (SEI, 2010, p. 408) devem
ser realizadas por pessoas que não produziram o trabalho a ser revisado.
Essas revisões devem ser registradas e seus resultados controlados e
analisados. Ao final de cada revisão formal de software, sugere-se que o
líder do projeto em questão realize um evento de comunicação,
informando a todos da equipe do projeto o resultado da revisão,
apresentando informações sobre quantos problemas foram identificados,
quantos potenciais problemas que seriam identificados somente em fases
posteriores foram identificados nesta revisão, ou seja, momento onde a
correção é muito mais barata. Além disso, estimar o ganho produzido
pela revisão seja em termos financeiros ou em HH.
89
Inspeção – A Inspeção de Software, por ser uma atividade mais

complexa e consumidora de tempo, deve ser bem planejada e sugere-se
que seja executada apenas em partes complexas do produto e que
podem gerar a falhas catastróficas. Para esta atividade devem ser
selecionadas pessoas com maior experiência sobre o produto a ser
inspecionado e, juntamente com o desenvolvedor, deve ser analisado o
modo como está sendo cumprido determinado requisito e como está de
fato codificado. O objetivo é identificar possíveis anomalias de software o
mais cedo possível.
Conforme apresentado na Figura 17, os relatórios obtidos nessas atividades

de qualidade devem ser analisados e, caso se julgue necessário, deve realimentar o
processo de desenvolvimento para que os mesmos problemas não venham a
ocorrer novamente.
Faz-se importante ressaltar que a literatura apresenta diversas formas e

definições de Inspeções de Software e Revisões Técnicas. Sugere-se nesta
monografia que a seja adotado os padrões do SWEBOK (IEEE, 2004) e do CMMI-
DEV (SEI, 2010), por se apresentar aderente a realidade da Empresa Y. Além
destes, Fernandes (2005, p. 163) também apresenta um processo de inspeção
interessante, que também pode ser avaliado pela Empresa Y para adoção caso seja
considerado viável.
3.4.2 Proposta para a Realização da Garantia da Qualidade
O processo de Garantia da Qualidade em projetos de desenvolvimento de

software é chamado de Software Quality Assurance pela disciplina de Engenharia de
Software. Segundo o CMMI-DEV (SEI, 2010) o papel da Garantia da Qualidade é
fornecer à equipe do projeto e, principalmente, à gestão uma visão para
acompanhamento dos resultados das ações tomadas para se atingir os objetivos do
projeto. Trata-se de verificar que os requisitos de qualidade estão sendo atendidos e
90
que as medições do Controle da Qualidade estão dentro de valores esperados e

satisfatórios. A principal atividade do processo de Garantia de Qualidade, conforme
apresentado no capítulo inicial deste trabalho, é a realização de Auditorias de
Processo.
Sugere-se então que as auditorias sejam realizadas contra os processos

adotados pelo projeto ao longo de seu ciclo de desenvolvimento. Para projetos
longos, com mais de dois anos, por exemplo, sugere-se que sejam realizados três
pontos de auditoria, uma no início, uma no meio e outra próximo ao release final do
produto. O objetivo da auditoria seria identificar falhas nos processos de controle de
configuração do projeto e no gerenciamento de requisitos. Um exemplo de auditoria
a ser executada seria: por meio de um Bloco entregue, rastrear de trás para frente o
que motivou o release do mesmo, onde está o registro da PR ou da aprovação da
solicitação de mudança. Caso seja um PR, verificar a realização da análise de causa
raiz. Selecionar um dos requisitos relacionados e procurar evidências da Verificação
e Validação do mesmo. Onde no código fonte o requisito está sendo cumprido, como
e quando foi testado, etc. Resumidamente, a auditoria procura evidências de que
todo o processo foi executado.
A própria execução da auditoria atende um anseio colocado pelo

Entrevistado A durante sua entrevista, na qual foi relatada por ele a falta de análise
de causa dos problemas reportados. Embora esta atividade esteja refletida no
Processo Gerenciar Mudanças, não vem ocorrendo de fato nos projetos executados
atualmente. A realização da auditoria identificaria tais falhas no processo,
registrando ações corretivas e impactando nos indicadores finais que serão
detalhados mais adiante, no subcapitulo 3.4.3.
Sugere-se que o processo de auditoria deva ser executado por um membro

externo, ou seja, que não faça parte do grupo do projeto em questão. Para a
Empresa Y, essa atividade pode ser realizada de maneira simples, uma vez que no
grupo de Desenvolvimento de Software são executados em geral de 4 a 5 projetos
simultaneamente. Deste modo, a proposta é que a auditoria seja feita de maneira
cruzada, isto é, um momento de Projeto A audita o Projeto B e assim por diante.
91
As auditorias devem ser registradas e seu resultado divulgado e analisado

pelo líder do projeto. Para os pontos onde a auditoria identificou falhas, devem ser
abertos itens de solicitação de mudanças no produto ou no processo, conforme item
auditado. Para a execução podem ser utilizados simples check-lists de modo a se
verificar se todos os processos estão sendo executados e, se executados, da
maneira correta, além disso, se todas as atividades de Verificação e Validação estão
sendo executadas e registradas. Ao final da auditoria deve ser gerado um Indicador
de Aderência à Qualidade, que será detalhado no subcapitulo 3.4.3.3, sendo um
percentual dos itens que passaram com sucesso na auditoria.
Para que o processo de Realização da Garantia da Qualidade seja

executado pelos projetos em andamento, é sugerido que tais atividades estejam
refletidas no atual processo Gerenciar Projeto da área de desenvolvimento de
software, apresentado no subcapitulo 2.4.6 desta monografia.
Deste modo, o processo de garantia da qualidade oferece o suporte para

que sejam entregues produtos de alta qualidade oferecendo à gestão do projeto
visibilidade e realimentação ao longo do ciclo de vida do projeto.
3.4.3 Proposta para a Realização do Controle da Qualidade
Conforme apresentado anteriormente, o Controle da Qualidade é o conjunto

de técnicas operacionais e atividades que sustentam a qualidade do produto.
Propõe-se que essas técnicas sejam planejadas no processo Planejar Projeto,
conforme proposto no Planejamento da Qualidade. Deste modo, a realização do
controle da qualidade é simplesmente a execução daquilo que foi Planejada para a
Qualidade do projeto, de modo a avaliar o desempenho e propor as melhorias
necessárias. Segundo o PMBOK (PMI, 2008), esse monitoramento deve ocorrer
durante todo o projeto.
Deste modo, sugere-se então que a Realização do Controle da Qualidade

esteja refletida também no processo interno da Empresa Y, chamado Gerenciar
92
Projeto. Sendo assim, seria papel deste processo garantir que tudo o que foi
planejado seja de fato executado, além de garantir a medição do resultado de tais
ações da qualidade. O líder do projeto de software deve executar o processo de
gerenciamento de projeto e definir quando e como tais atividades planejadas serão
executadas.
Além da execução das atividades de qualidade planejadas, o Processo de

Controle da Qualidade deve gerar métricas de software a fim de prover informação
necessária para a tomada de decisão ao longo do desenvolvimento. Das métricas
apresentadas no subcapitulo 1.4.3.3 desta monografia, sugere-se que sejam
adotadas pela Empresa Y as seguintes:
Densidade de Defeitos em Função dos Requisitos.

Cobertura do Processo de V&V.
Aderência à Qualidade.
Densidade de Defeitos de Verificação.
Eficiência da Remoção de Defeitos do Processo de Verificação.
Índice de Qualidade de Software.
As principais saídas deste processo, conforme apontado pelo PMBOK (PMI,

2008) deve ser: medições do controle da qualidade, registro de não conformidades,
solicitações de mudanças e atualizações da documentação do projeto conforme
necessário.
3.4.3.1 Densidade de Defeitos em Função dos Requisitos
Fernandes (2005) define que o objetivo do monitoramento da densidade de

defeitos do produto tem o objetivo de verificar o estágio atual da qualidade do
mesmo, bem como permitir que seja inferido tendências de densidade de defeitos.
A literatura apresenta o conceito de Densidade de Defeitos como sendo o

número de defeitos encontrados dividido pelo número de linhas de código,
93
geralmente normalizado por 1000 linhas de código (FUTRELL; SHAFER; SAFER,

2002; SEI, 2010). No entanto, o atual processo de gestão da Empresa Y utiliza como
abordagem principal a quantidade total de requisitos de software, uma vez permite
uma melhor estimativa de esforço e complexidade. Sendo assim, a densidade de
defeitos sugerida leva em consideração a quantidade total de requisitos, sendo
calculada conforme Equação 8.
&-. '

Z%8[#$!$% $% Z%W%#74[ = (8)
\) ,- )
O principal problema da abordagem por requisitos é dificuldade em

encontrar valores de referência na literatura, uma vez que abordagem mais utilizada
é por meio de linhas de código. Deste modo, sugere-se como meta desta indicador
valores de referência baseado em projetos de sucesso já realizados pela empresa.
Sugere-se ainda que este indicador seja medido a cada Bloco liberado e que seja
plotado em um gráfico cujo eixo X seja o número do bloco e a data da liberação do
mesmo (FERNANDES, 1995).
Vale ressaltar que os PR’s utilizados neste indicador são PR’s internos,
gerados pelo processo da Validação da área de software ou pelos testes de
integração realizados pela equipe de testes da Empresa Y.
Por fim, sugere-se também que este mesmo indicador seja calculado em
forma de percentual, semelhante ao atual Índice de Qualidade da Torre de Controle.
Este valor percentual será entrada para o Índice de Qualidade de Software, descrito
no subcapitulo 3.4.3.6.
3.4.3.2 Cobertura do Processo de V&V
A cobertura do processo de V&V é um indicador proposto por Futrell; Shafer;

Safer (2002) e classificado por estes autores como um indicador de processo. Trata-
se de verificar a real aplicação das ferramentas de V&V propostas pelo Processo
Planejar Projeto.
94
Considerando os testes formais previstos na atividade de Validação, sugere-

se que seja monitorado o seguinte índice, conforme Equação 9.
,- ) \ )

34]%;7 ;! ^!"#$!çã4 = 100 @%A (9)
\) ,- )
Cabe reforçar que os requisitos testados referenciados na Equação 9 são

referentes aos testes de Validação e não dos Testes de Integração realizados pela
equipe de testes.
Considerando as revisões técnicas e inspeções de software propostas como

atividades de Verificação, sugere-se que seja monitorado o índice conforme
Equação 10.
abcd ef(
34]%;7 ;! ^%;#W#9!çã4 = 100 @%A (10)
abcd 1 1 f(çã)
Onde:
ghi3 ^%;#W#9!$![ : Quantidade de linhas de código na qual foram

realizadas atividades de Validação, normalizada por 1000.
ghi3 :;%j#[7![: Quantidade de linhas de código nas quais se planejou
realizar atividades de Validação, normalizada por 1000.
Dados esses dois índices acima, sugere-se então que o Indicador de

Cobertura do Processo de V&V seja a média aritmética simples destes dois índices,
conforme apresentado na Equação 11.
eçã)l ef(çã)
34]%;7 ;! ^&^ = @%A (11)
m
Com esta abordagem, qualquer umas das atividades de V&V que não for
executada impactará diretamente neste indicador, gerando um ponto de atenção
para o líder do projeto.
95
3.4.3.3 Indicador de Aderência à Qualidade
Similar ao indicador de aderência ao prazo, conhecido como Earned Value,

propõem-se que este indicador apresente nível de aderência às atividades da
Qualidade do projeto em questão (FUTRELL; SHAFER; SAFER, 2002, p. 819). Sua
fonte de dados deve ser o relatório gerado durante a auditoria realizada pelo
Processo de Garantia da Qualidade, sob responsabilidade do Processo Gerenciar
Projeto. Seu método de cálculo deve ser simplesmente baseado no resultado da
auditoria e calculado conforme Equação 12:
n . 1)) . - )

100 @%A (12)
&-. ) . - )
Ou seja, de todos os itens selecionados para serem auditados, em quantos o

projeto obteve resultado satisfatório.
3.4.3.4 Densidade de Defeitos de Verificação
Segundo Fernandes (1995, p. 184) este indicador tem o objetivo de verificar

o desempenho das inspeções, além de avaliar a melhoria deste próprio processo.
Considerando que esta monografia sugere basicamente suas atividades de
verificação, Revisões Técnicas e Inspeção de Software, sugere-se também que este
indicador seja calculado individualmente, ou seja, considerando cada uma das
atividades separadamente.
O método de cálculo é basicamente o número de Defeitos Identificados

dividido pelo Número de Linhas de Código do Material Inspecionado. Fernandes
(ibid) propõem esta relação seja normalizada por 1000 linhas. Para isso basta utilizar
a regra de três. Por exemplo: 40 defeitos encontrados em 400 linhas inspecionadas
significa uma densidade de 100 defeitos por 1000 linhas de código. Seu cálculo deve
ser feito conforme a Equação 13:
oº qf ) n. f() r Csss

Z%8[#$!$% = (13)
oú*) .u .1().
96
Este mesmo indicador, assim como a densidade de defeitos, também pode

ser calculada em função do número de requisitos ao invés do número de linhas de
código. Porém, identificar a quantidade de requisitos específicos de um trecho de
código a ser inspecionado pode não ser tarefa fácil. Deste modo, sugere-se que seja
utilizado o número de linhas de código, porém durante a implantação fica a cargo
dos responsáveis na Empresa Y decidirem qual a melhor abordagem.
Para analisar o desempenho das inspeções, Fernandes (1995, p. 184)

propõem que seja utilizado gráfico de controle estatístico. Essa ferramenta, segundo
ele, permite comparar a variação da densidade dentro de limites aceitáveis.
O gráfico sugerido por Fernandes (ibid) é o de “Número de Não-

Conformidades por Unidade (u)”, ou seja, “várias não conformidades independentes
(defeitos) podem ocorrer em uma unidade de Produto” (requisitos ou linhas de
código). Valores acima do limite superior indicam produtos “propensos a erros” e
valores abaixo do limite inferior indicam produtos “mal inspecionados”.
Semelhante ao indicador de Densidade de Defeitos em Função dos

Requisitos relatado no subcapitulo 3.4.3.1, sugere-se este também seja calculado de
maneira percentual, seguindo os mesmos padrões do formato já utilizado para a
Torre de Controle. Ou seja, deve ser adotado um valor de referência baseado em
projetos passados, literatura ou benchmark.
3.4.3.5 Eficiência da Remoção de Defeitos do Processo de Verificação
O objetivo deste indicador, segundo Fernandes (1995, p. 189) é o de medir a

eficiência do processo de verificação (inspeção e revisão) até a fase de teste
integrado. Seu cálculo deve ser realizado conforme apresentado na Equação 14:
∑ qnw\
KW#9#ê89#! = ∑ @%A (14)
qnw\l ∑ qnqw\
Onde:
97
ZxJLO Significa Defeitos Identificados até a Fase de Testes Integrados.

ZxZLO Significa Defeitos Identificados Durante a Fase de Testes
Integrados.
Ainda segundo Fernandes (1995, p. 189), considera-se como baixa

eficiência valores abaixo de 70%. Caso isso ocorra, o líder do projeto deve procurar
indícios de mudanças de requisitos não registradas, porém incorporadas no produto
sem devida comunicação. Outra ação gerencial a ser tomada seria reforçar os
recursos para a inspeção, de modo a ser executada com o tempo necessário e pelas
pessoas mais indicadas. Além disso, devem ser selecionados para inspeção os
módulos de software com maior propensão a erros. Fernandes (ibid) completa ainda
que segundo estatística, cerca de 12% dos módulos de um sistema representam
50% do esforço de manutenção.
3.4.3.6 Índice de Qualidade de Software
O objetivo final e mais específico desta monografia é o de propor um

indicador de qualidade de software a ser adotado pela Empresa Y. Sendo assim,
sugere-se que este indicador seja um compilado dos demais indicadores de
qualidade apresentados anteriormente. Trata-se de um indicador que pondere as
ações de qualidade realizadas ao longo do processo de desenvolvimento e dos
problemas reportados durante este processo.
Sugere-se que para cada indicador seja atribuído um peso, em função de

sua relevância para aquele determinado projeto. Considerando o peso e valor de
cada indicador, ter-se-á o resultado do indicador compilado.
Segundo Terribili Filho (2010, p. 26), um indicador deve permitir

comparações históricas e apresentar tendência de futuro. Deste modo, sugere-se
que este indicador seja calculado a cada Bloco liberado, com isso mesmo que em
um determinado bloco não haja atividades de inspeção, por exemplo, o indicador
98
será impactado por outras fontes, como quantidade de PR’s identificadas ou número
de requisitos testados. A Tabela 3 apresenta um exemplo de cálculo deste indicador.
Tabela 3 – Exemplo de Medição do Indicador de Qualidade de Software
Mês (2012) I1 I2 I3 I4 I5 Índice de Qualidade

ABRIL 99% 89% 80% 90% 95% 92,07%
MAIO 98% 88% 78% 88% 93% 90,50%
JUNHO 95% 85% 75% 85% 90% 87,50%
JULHO 92% 82% 72% 82% 87% 84,50%
AGOSTO 93% 83% 73% 83% 88% 85,50%
SETEMBRO 99% 89% 79% 89% 94% 91,50%
Onde:
I1 é o Indicador de “Densidade de Defeitos em Função dos Requisitos”,

cujo peso neste exemplo é 5.
I2 é o Indicador de “Cobertura do Processo de V&V”, cujo peso neste
exemplo é 1.
I3 é o Indicador de “Aderência à Qualidade”, cujo peso é 3.
I4 é o Indicador de “Densidade de Defeitos de Verificação”, cujo peso é 2.
I5 é o Indicador de “Eficiência da Remoção de Defeitos do Processo de
Verificação”, cujo peso neste exemplo é 3.
Com a definição de pesos aos indicadores pretende-se flexibilizar o

processo e permitir a diminuição do efeito no valor final de indicadores menos
importantes em determinadas fases do projeto. Deste modo sugere-se que o peso
seja atribuído a cada medição, ou seja, a cada bloco liberado. Além disso, essa
abordagem permite ainda eliminar completamente um determinado indicador do
cálculo da qualidade, apenas atribuindo o peso zero. Isso será necessário, por
exemplo, em projetos menores e mais rápidos, onde não será possível talvez a
realizações de inspeções de software.
A atribuição de uma meta para este indicador não é tarefa fácil, pois se trata
de um indicador novo, não encontrado na literatura e muito menos executado em
99
projetos passados realizados na Empresa Y. Porém, todos os dados utilizados para

o cálculo deste indicador são de fácil levantamento, mesmo em projetos passados.
Neste caso, seria possível levantar tais informações de dados históricos, obter o
valor de cada um desses indicadores e obter um valor de referência baseado a partir
de um projeto consagrado e considerado por todos um caso de sucesso. Com isso,
a meta inicial poderia ser baseada no valor identificado para este projeto e, com o
tempo, caso a meta seja facilmente atingida, poderá ser reavaliada para valores
mais ambiciosos.
Com esta abordagem, pretende-se obter um indicador que permita tomada

de decisão para reação antes de o produto chegar ao cliente final. Caso em um
determinado mês se obtenha valores muito abaixo do esperado, é possível realizar
ações de Verificação e Validação a fim de aumentar a qualidade do produto,
procurar a causa raiz do valor baixo do Índice e atuar sobre ela, evitando que o
primeiro a identificar alguma anomalia no produto de software seja o próprio cliente.
Consequentemente, deverá ser notada uma queda no número de problemas
reportados pelo cliente conforme o aumento do índice de Qualidade de Software,
pois se supõem que com a execução do processo de Gerenciamento da Qualidade,
todos os defeitos (ou a grande maioria deles) sejam identificados e corrigidos antes
da liberação final do produto.
100
CONCLUSÃO
Este trabalho procurou estudar a área de conhecimento do Gerenciamento

da Qualidade, referente à da disciplina de Gerenciamento de Projetos, focando
exclusivamente em projetos de desenvolvimento de software, uma área
extremamente dinâmica e sujeita a muitas alterações de escopo. Este fato
influenciou na escolha do tema deste trabalho, uma vez que o gerenciamento de
projetos deste tipo tem se mostrado muito desafiador, até mesmo para gerentes de
projetos muito experientes.
Esta monografia apresentou um estudo de caso de uma empresa do setor

aeronáutico, especializada no desenvolvimento de software de missões críticas
embarcado em sistemas de tempo-real. O trabalho teve como objetivo principal
avaliar como a área de conhecimento do Gerenciamento da Qualidade, apresentada
pela PMBOK, poderia contribuir com o atual processo de Gerenciamento de Projetos
realizado na Empresa Y. Como objetivo secundário buscou-se estabelecer um
indicador de fácil medição e que pudesse quantificar a qualidade do software
desenvolvido.
Os dados coletados para realização do estudo de caso, análise e discussão

foram obtidos através de consulta à documentação interna da empresa e entrevistas
com profissionais especializados da equipe de software, que contribuíram com seu
tempo e conhecimento no desenvolvimento deste trabalho. Por meio do estudo de
caso, pôde-se averiguar que a Empresa Y está alinhada com a metodologia
proposta pelo PMBOK e pratica em grande parte os processos por ele sugeridos.
Por outro lado, percebeu-se que o Gerenciamento da Qualidade praticado pela
empresa possui excelentes oportunidades de melhoria, indicando que o atual
produto, já muito bem aceito pelo mercado, possui margem para se tornar ainda
melhor e mais rentável.
Deste modo, este trabalho concluiu, com base na fundamentação teórica e

na opinião de especialistas, que a modificação de alguns processos internos já
praticados pela Empresa Y, a fim de se refletir as técnicas e ferramentas do
101
Gerenciamento da Qualidade, podem contribuir com a evolução da qualidade do

produto final. A adoção de revisões técnicas de software e auditorias da qualidade,
por exemplo, minimiza a possibilidade de defeitos de software ser detectados
apenas em operação pelo cliente final, o que causa um impacto negativo em custo e
na imagem da empresa.
Esta constatação ratifica a hipótese central desta monografia, a qual julga

que o gerenciamento da qualidade, por meio de um Plano da Qualidade definido na
fase de planejamento e técnicas de garantia e controle da qualidade, possa
contribuir com o aumento da qualidade do produto.
A adoção do processo de Planejamento da Qualidade, por exemplo, logo no

início da fase de Planejamento do Projeto, contribui para o estabelecimento de
atividades de controle da qualidade, com a definição prévia do que deverá ser feito,
quando e quantas vezes. Além disso, a ação de gráficos de controle e a execução
das atividades por amostragem estatística favorecem o nivelamento de
conhecimento entre os membros da equipe, permitindo que uns aprendam com os
demais a cada atividade de inspeção ou revisão de código. Com isso, concluí-se
ainda que o gerenciamento da qualidade como um todo colabora não apenas com a
qualidade em si, mas também com a difusão do conhecimento entre a equipe e com
o compartilhamento de lições aprendidas.
A Realização da Garantia da Qualidade, por sua vez, mostra-se como outro

exemplo de processo do Gerenciamento da Qualidade que contribui com todos os
demais processos da empresa. A técnica de auditoria de processo proposta nesta
monografia, além de verificar se os requisitos da qualidade estão sendo atendidos,
contribui também de certificar que projetos estão seguindo todos os demais
processos estabelecidos, oferecendo assim o suporte necessário para detecção e
correção de desvios durante o processo.
Por fim, o Controle da Qualidade coloca em prática todas as atividades

planejadas na fase de Planejamento da Qualidade, gerando indicadores para serem
analisados pelo processo de Garantia da Qualidade, tornando a evolução da
102
maturidade do produto visível a todos os membros da equipe, proporcionando

inclusive uma visão de tendência e comparação com o histórico.
Finalmente, com a constatação da hipótese central apresentada nesta

monografia, conclui-se consequentemente que a hipótese secundária não seja
verdadeira, uma vez que o processo de Controle da Qualidade pode sim contribuir
com a identificação de um indicador que traduza a qualidade do produto de software,
conforme apresentado na proposta realizada para o Controle da Qualidade. É
essencial, porém, destacar que as propostas de inclusão do Gerenciamento da
Qualidade nos processos internos da Empresa Y foram apenas realizadas com o
embasamento teórico, devendo ser analisadas e testadas na prática em um possível
trabalho futuro, pois as mesmas podem afetar o lead-time do ciclo de
desenvolvimento de software.
103
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT - Associação Brasileira De Normas Técnicas. NBR ISO 9000: Sistemas de

Gestão da Qualidade – Fundamentos e Vocabulário. Rio de Janeiro, 2000.
CROSBY, Philip B. Philip Crosby fala da utilidade de ISO 9000:2000. Disponível

em: <http://www.philipcrosby.com.br/pca/artigos/PhilISO.htm>. Acesso em: 28 jul.
2012.
EMBRAER (Brasil). Site Oficial da Embraer S/A. Disponível em:

<http://www.embraer.com.br>. Acesso em: 1 set. 2012.
FERNANDES, Aguinaldo Aragon. Gerência de Software através de Métricas:

Garantindo a qualidade do projeto, processo e produto. São Paulo: Atlas, 1995. 421
p.
FISCHETTI, Decio. Um Líder da Inovação. Biografia do Criador da Embraer. São

Paulo: Bizz, 2011. 278 p.
FUTRELL, Robert T.; SHAFER, Donald F.; SAFER, Linda I.. Quality Software
Project Management. Upper Saddle River: Prentice Hall Ptr, 2002. 1677 p.
HOOD, Colin et al. Requirements Management: The Interface Between

Requirements Development and All Other Systems Engineering Processes.
Oberhaching: Springer, 2008. 275 p.
IEEE (Ed.). SWEBOK: Guide to the Software Engineering Body of Knowledge. Los
Alamitos: IEEE Computer Society, 2004.
KONG, Sue; KENDALL, Julie E; KENDALL, Kenneth E. Project Contexts and Use of
Agile Software Development Methodology In Practice: A Case Study. Journal of the
Academy of Business & Economics, Kutztown, p. 1-15. mar. 2012. Disponível em:
<Business Source Complete, EBSCOhost>. Acesso em: 16 jul. 2012.
MACHADO, Marcio Cardoso; TOLEDO, Nilton Nunes. Gestão do Processo de

Desenvolvimento de Produtos: Uma abordagem baseada na criação de valor. São
Paulo: Atlas, 2008. 147 p.
MALVESTIO, Rafael César Arruda. O uso das metodologias ágeis no

gerenciamento de projetos de desenvolvimento de softwares. 2010. 96 f.
Monografia (Especialização em Gestão Estratégica de Projetos) - Curso de Pós-
graduação em Gestão Estratégicas de Projetos, FAAP, São Paulo, 2010.
MCKINNEY, Charles. Capability Maturity Models and Outsourcing: A Case for

Sourcing Risk Management. Information Systems Control Journal: The Source
for IT Governance Professionals, Rolling Meadows, set. 2005. Disponível em:
<http://www.isaca.org/Journal/Past-Issues/2005/Volume-5/Pages/default.aspx>.
Acesso em: 29 jul. 2012.
104
MIRANDA, Zil. O Voo da Embraer: a competitividade brasileira na indústria de alta

tecnologia. São Paulo: Papagaio, 2007. 196 p.
NEWHOUSE, John. Boeing versus Airbus: The Inside Story of the Greatest
International Competition in Business. New York: Vintage, 2008. 254 p.
OLIVEIRA, Marcos Alberto de. Em Busca da Excelência Empresarial. 2. ed. São

Paulo: DVS, 2009. 216 p.
PETRASCH, Roland. The Definition of Software Quality: A Practical Approach. In:

ISSRE - International Symposium on Software Reliability Engineering.
Proceedings... . Mysuru: IEEE, 1999. p. 1 - 2. Disponível em:
<http://www.chillarege.com/fastabstracts/issre99/99124.pdf>. Acesso em: 12 fev.
2012.
PMI – Project Management Institute. Guia de Conhecimentos em Gerenciamento

de Projetos – PMBOK. 4.ed. Newton Square: PMI/Global Standard, 2008.
PMI (Brasil) (Org.). Sobre o PMI. Disponível em: <http://www.pmi.org.br/>. Acesso

em: 07 abr. 2012.
PRESSMAN, Roger S. Software Engineering: A Practitioner's Approach. 6. ed.

New York: Mcgraw-Hill Higher Education, 2005. 912 p.
RTCA - Radio Technical Commission for Aeronautics. DO-178B: Software

Considerations in Airborne Systems and Equipment Certification. Washington, 1992.
SCHULMEYER, G. Gordon (Ed.). Handbook of Software Quality Assurance. 4th

ed. Norwood: Artech House, Inc., 2008. 465 p.
SEI - SOFTWARE ENGINEERING INSTITUTE (Estados Unidos). Carnegie Mellon

University. CMMI for Development: Version 1.3. Pittsburgh, 2010. 468 p.
SHENHAR, Aaron J.; DVIR, Dov. Reinventando Gerenciamento de Projetos: A

ABORDAGEM DIAMANTE AO CRESCIMENTO E INOVAÇÃO BEM-SUCEDIDOS.
São Paulo: M.Books, 2010. 260 p.
SOMMERVILLE, Ian. Software Engineering. 8. ed. Harlow: Pearson Education

Limited, 2007. 840 p.
SOUZA, Helder José Celani de; SALOMON, Valério Antônio Pamplona; SILVA,
Carlos Eduardo Sanches da. Variáveis Influentes na Maturidade em Gerenciamento
de Projetos. Mundo Project Management, Curitiba, v. 8, n. 43, p.52-57, mar. 2012.
Bimestral.
TERRIBILI FILHO, Armando. Indicadores de Gerenciamento de Projetos.

Monitoração Contínua. São Paulo: M.Books, 2010. 136 p.
View publication stats

Algoritmos Numéricos de Busca em Otimização - UNICAMP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Algoritmos Numéricos de Busca em Otimização - UNICAMP

Enviado por

Direitos autorais:

Formatos disponíveis

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.

GERENCIAMENTO DA QUALIDADE EM PROJETOS DE DESENVOLVIMENTO

Thesis · December 2012

Lucas Pereira Dos Santos

The user has requested enhancement of the downloaded ﬁle.

TRABALHO DE CONCLUSÃO DE CURSO

7ª Turma do Curso de Pós-Graduação Lato-Sensu em

GERENCIAMENTO DA QUALIDADE EM PROJETOS DE

Lucas Pereira dos Santos

Coordenador do Curso: Prof. MSc. Marcos Alberto de Oliveira

São José dos Campos

GERENCIAMENTO DA QUALIDADE EM PROJETOS DE

Monografia apresentada ao Curso de Pós-

Coordenador do Curso: Prof. MSc. Marcos Alberto de Oliveira

São José dos Campos

GERENCIAMENTO DA QUALIDADE EM PROJETOS DE

Data de Aprovação: ___/___/___

Nota Final: ________

Ao Prof. MSc. Marcos Alberto de Oliveira pelo constante incentivo e orientação

À Profª Drª Ana Maria I. B. Ayrosa pelos diversos e-mails esclarecedores

Aos colegas Fabrício José Pontes, Arturo Bittencourt Fernandez e Marília

A todos os professores do curso de Gerenciamento Estratégico de Projetos da

A rápida evolução tecnológica vem aumentando consideravelmente a demanda

Neste contexto, o desenvolvimento de softwares com qualidade, dentro do

Finalmente, são apresentadas a discussão e a conclusão, fornecendo ao leitor

Palavras chave: Gerenciamento de projetos. Gerenciamento da qualidade.

The technological improvement has considerably increased the software

Keywords: Project Management. Quality Management. Software Development.

Figura 1 – Grupos de processo de gerenciamento de projetos 19

Tabela 1 – Relação da Qualidade com a Quantidade de Defeitos no produto ..................... 76

Quadro 1 – Mapeamento de grupos de processos e áreas de conhecimento 23

CMMI Capability Maturity Model Integration

CMMI-DEV CMMI for Development

CTA Centro Técnico Aeroespacial

DIP Desenvolvimento Integrado do Produto

EADS European Aeronautic Defense and Space Company

FAB Força Aérea Brasileira

IPD Instituto de Pesquisa e Desenvolvimento

ISO International Organization for Standardization

ITA Instituto Tecnológico de Aeronáutica

PMBOK Project Management Body of Knowledge

PMI Project Management Institute

SCCB Software Configuration Control Board

SWEBOK Software Engineering Body of Knowledge

V&V Verificação e Validação

A indústria de desenvolvimento de software em geral vem aumentando seus

O relatório produzido pela consultoria Standish Group e divulgado em 2009,

A monografia apresenta um estudo de caso em uma empresa do setor

Diante desse contexto, torna-se importante o estudo do gerenciamento da

O objetivo geral desta monografia é estudar como o gerenciamento da

A hipótese central desta monografia é que o gerenciamento da qualidade,

Como hipótese secundária tem-se que o gerenciamento da qualidade pouco

Por se tratar de um assunto extremamente amplo, o trabalho limita-se a

A monografia será desenvolvida através de um estudo de caso,

o gerenciamento da qualidade na Empresa Y será realizado por meio de um estudo

O trabalho está estruturado da seguinte maneira: a introdução apresenta e

Este capítulo apresenta uma pesquisa exploratória sobre os conceitos

1.1 Conceitos Iniciais

Para descrever o gerenciamento de projetos é preciso antes defini-lo e

O PMI (2008) descreve projeto como sendo “um esforço temporário

atividades estruturas e inter-relacionadas que transforma insumos (entradas) em

1.2 Gerenciamento de Projetos

A aplicação desses conhecimentos, técnicas e ferramentas no

Data de Aprovação: _/_/___