Aula 5 GP

Prévia do material em texto

Gestão de Projetos em Tecnologia da Informação
Aula 05
Software Extension to the PMBOK® Guide
Objetivos Específicos
• Correlacionar os elementos propostos pelo Software Extension com os do 
Guia PMBOK®.
Temas
Introdução
1 Características e aspectos gerais de projetos de desenvolvimento de software
2 Software extension to the PMBOK® Guide
Considerações finais
Referências
André Luis Fonseca Ricardi
Professor
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
2
Introdução
Nesta aula será apresentado o conteúdo do Software Extension, que complementa o Guia 
PMBOK® – Um Guia de Conhecimento em Gerenciamento de Projetos (PMI, PMBOK, 2013). 
O Guia PMBOK® tem extensões (extensions) que contêm aquilo que seria aplicável a 
projetos de áreas específicas, identificando como estes elementos se associam àqueles 
que seriam aplicáveis a qualquer tipo de projeto, conteúdo primário do Guia PMBOK®. São 
manuais complementares com a finalidade de atender aos projetos de áreas específicas.
O Software Extension não tinha tradução oficial para o português quando este material foi 
desenvolvido. Será apresentado a você aquilo que consideramos mais importante conhecer 
sobre esta publicação, mas certamente não conseguiríamos tratar aqui da totalidade de uma 
referência com quase 300 páginas. 
O fato é que você não deveria desprezar a possibilidade de aplicar algo que milhares de 
profissionais ao redor de todo o mundo entendem ser aplicável à maioria dos projetos de 
desenvolvimento de software. 
Na área de desenvolvimento de software é comum ouvirmos que algo é impossível de 
se aplicar em projetos, quando na verdade as pessoas estão acomodadas e não querem se 
esforçar para aumentar as chances de sucesso de seus projetos. 
Você entende que está bom assim, ou acredita que pode melhorar o desempenho 
de seus projetos? Responda esta pergunta com a certeza de que é preciso mudar, pois a 
concorrência melhora diariamente, tanto no aspecto empresarial quanto no pessoal. Se você 
e sua empresa ficarem acomodados, provavelmente terão dificuldades no futuro.
Como profissional de TI não tenho receio em afirmar que muito pode ser melhorado, 
e de fato isso tem ocorrido. Aumenta de forma exponencial o percentual de empresas e 
profissionais que se preocupam em melhorar o desempenho dos projetos, pois como já foi 
dito, não se trata de opção, mas sim de sobrevivência.
1 Características e aspectos gerais de projetos de 
desenvolvimento de software
O gerenciamento de projetos pode ser extremamente útil quando se fala sobre 
desenvolvimento de software, em especial por conta de características intangíveis que 
podem estar associadas ao produto. A concepção de um software pode terminar com uma 
visão muito diferente do que era no seu início, o que dificulta sobremaneira gerenciar o seu 
desenvolvimento (PMI, Software Extension, 2013).
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
3
É comum o cliente não ter certeza sobre os requisitos que o software precisará atender, 
e sem requisitos e critérios de aceitação consistentes fica quase impossível medir o sucesso 
de um projeto. Assim sendo, coletar os requisitos é um processo vital para desenvolver 
software e, além disso, mantê-los consistentes talvez seja tão difícil quanto coletá-los. Muitas 
vezes ocorre displicência em manter os requisitos atualizados, o que pode ter consequências 
catastróficas, por exemplo, quando se consulta os envolvidos somente no início e no final do 
processo de desenvolvimento. Os cenários podem se alterar neste intervalo, e os requisitos 
são modificados sem que os solicitantes sejam consultados; então, a validação ocorre somente 
durante a homologação, e o índice de retrabalho pode se tornar alto. 
Ainda, algumas equipes técnicas impõem limites aos seus clientes/usuários com base 
em seu conhecimento (domínio da tecnologia) ou na deficiência de recursos tecnológicos 
restritos ou obsoletos. Na verdade, buscar novas tecnologias e conhecimento adicional pode 
ajudá-lo a obter sucesso e atender melhor ao seu cliente/usuário. Não restrinja o atendimento 
de requisitos considerando apenas aspectos técnicos. Saia da zona de conforto. Busque novas 
alternativas, analisando primeiro as necessidades do cliente/usuário, para depois analisar 
a aderência e capacidade da tecnologia. Desde que dentro de limites aceitáveis de risco, 
inovação, na maioria das vezes, é eficiente e traz excelentes resultados.
Houve um tempo em que os profissionais de TI se consideravam os “donos” do software, 
e o cliente/ usuário precisava se adaptar. Não há mais espaço para isso. É preciso atender 
às necessidades de expectativas das partes interessadas da melhor forma possível; isso não 
significa restringir o atendimento dos requisitos por conta da tecnologia disponível, ou da 
falta de conhecimento da equipe técnica.
Cronogramas irreais e impossíveis de atender são quase uma regra em projetos de 
desenvolvimento de software. Confesso que é algo que me intriga, pois se todos sabem que 
o cronograma não reflete a realidade, para que usá-lo? É insano e insalubre criar documentos 
apenas por criar. O documento mais importante a ser atualizado e que deve estar condizente 
com a realidade é o cronograma, pois ele é a principal referência para a execução das atividades 
do projeto. Assim sendo, por que acreditar que “forçar a barra” em um cronograma pode de 
alguma forma ser benéfico à gestão? Relatórios de acompanhamento e de status de projetos 
não podem apresentar algo diferente do que a verdadeira situação do que está ocorrendo. 
Planejar e construir um cronograma realista aumenta significativamente as chances de 
sucesso de um projeto. Para desenvolvimento de software isso não é diferente, muito pelo 
contrário (RICARDI, 2014).
Poderíamos ter aqui uma lista quase interminável de problemas que ocorrem em 
projetos de desenvolvimento de software. O fato é que ter uma referência pensada, testada e 
comprovada por milhares de profissionais, como o Software Extension, pode lhe guiar por um 
caminho mais curto e menos traumático para o sucesso, evitando erros e indicando caminhos 
mais adequados. 
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
4
2 Software extension to the PMBOK® Guide
Esta extensão pode auxiliar tanto empresas que têm como atividade principal o 
desenvolvimento de software como aquelas onde existe uma área interna de Tecnologia 
da Informação (TI), que supre as demais áreas da empresa com o desenvolvimento 
interno de software. Ele pode ser utilizado como referência tanto pelos profissionais que 
desenvolvem diretamente o software como por aqueles que trabalham em áreas de suporte 
ao desenvolvimento. Dependendo do tipo de usuário final (cliente), eles também podem se 
beneficiar do uso desta extensão.
Você pode identificar diretamente no Software Extension o que é complementar e 
diferente do Guia PMBOK®. Elementos novos são mostrados em itálico e negrito. Elementos 
modificados são mostrados em itálico. Os demais que estão iguais ao Guia PMBOK® estão em 
texto normal. Na Figura 1 a seguir você pode verificar como isso é representado.
 Figura 1 – Identificação de Entradas, Ferramentas e Técnicas, e Saídas revisadas
Fonte: PMI, Software Extension (2013, p. 18).
Cada um dos capítulos do Software Extension, assim como no Guia PMBOK®, e a partir 
do capítulo 4, corresponde às áreas de conhecimento do gerenciamento de projetos. No 
início de cada um destes capítulos você encontra uma figura com todos os processos desta 
área de conhecimento, com seus respectivos elementos: entradas, ferramentas e técnicas, e 
saídas. Nestas figuras estão identificadas alterações e o que foi incluído especificamente para 
gerenciamento de projetos de software, conforme a figura anterior.
A seguir estão identificadas as diferenças a destacar (alterações e inclusões) em cada 
processo específico, e agrupados poráreas de conhecimento (PMI, Software Extension, 
2013). Os processos e elementos que porventura não estiverem citados são iguais ao Guia 
PMBOK®, ou não foram considerados como passíveis de destaque.
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
5
2.1 Processos de integração
Para o processo Desenvolver o Termo de Abertura do Projeto:
• Entradas: o Business Case pode incluir custos operacionais e de manutenção, pois 
isso é comum para se analisar o custo/benefício do desenvolvimento de software.
• Ferramentas e técnicas: a Opinião Especializada é fator a destacar para projetos de 
desenvolvimento de software. Dada a dificuldade de definição do escopo, já citada, 
conhecer aspectos relevantes de projetos similares desenvolvidos no passado pode 
ser fator crítico para o sucesso.
Para o processo Desenvolver o Plano de Gerenciamento do Projeto:
• Entradas: modelos e lições aprendidas de projetos similares são de extrema 
importância para projetos de desenvolvimento de software. 
• Ferramentas e técnicas: ferramentas para estimativas são importantes para aumentar 
a precisão no planejamento, dada a dificuldade em entender e definir o escopo.
• Saídas: destaque para planos de testes. Envolva o cliente/ usuário e as áreas de 
suporte no planejamento de testes e homologação.
Para o processo Orientar e Gerenciar o Trabalho do Projeto:
• Ferramentas e técnicas: a disseminação da informação é importante para o sucesso 
do projeto, pela característica intangível do produto. A informação inadequada e/ou 
no tempo inadequado pode prejudicar substancialmente o sucesso do projeto.
• Saídas: demonstrações de trabalho são o indicador mais importante do progresso 
tangível para projetos de software, pois se não ficar comprovado que de fato está 
funcionando de acordo com os requisitos, podemos considerar que foi apenas 
codificado, e nada mais.
Para o processo Monitorar e Controlar o Trabalho do Projeto:
• Saídas: os relatórios de desempenho do trabalho devem ser detalhados e específicos 
da área, considerando métricas de produto e de desempenho, bem como 
informações do que ficou para backlog e relatórios de gerenciamento de configuração 
(versionamento das entregas).
Para o processo Realizar o Controle Integrado de Mudanças:
• Saídas: os relatórios de desempenho do trabalho devem ser detalhados e específicos 
da área, considerando métricas de produto e de desempenho, bem como 
informações do que ficou para backlog e relatórios de gerenciamento de configuração 
(versionamento das entregas).
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
6
Para o processo Encerrar o Projeto ou a Fase:
• Saídas: o código fonte, dados sobre desempenho e a documentação do projeto e das 
lições aprendidas são importantes para projetos de software.
2.2 Processos de escopo
Para o processo Planejar o Gerenciamento do Escopo:
• Entradas: como o desenvolvimento de software permite entregas parciais, é 
importante analisar como entrada para este processo se é aplicável para cada projeto 
específico, ou se será tudo entregue em um mesmo momento.
Para o processo Coletar os Requisitos:
• Ferramentas e Técnicas: as entrevistas são essenciais para um bom desenvolvimento 
de software, pois a equipe não tem como adivinhar detalhes que são de conhecimento 
de outras partes interessadas. O uso de protótipos e casos de uso também se aplica 
para validar requisitos durante o processo de coleta destes requisitos. 
O Guia PMBOK® cita o Business Analysis Body of Knowledge (BABOK) (IIBA, 
2011) como uma referência importante para quem precisa coletar requisitos de 
negócios junto a usuários finais. Se você precisa coletar requisitos recomendo 
que você consulte o BABOK. Procure mais informações em International 
Institute of Business Analysis (IIBA).
• Saídas: a documentação dos requisitos e a matriz de rastreabilidade dos requisitos 
são especialmente importantes, principalmente se você considerar que podem 
ocorrer entregas parciais ou futuras, e que você precisa ter controle absoluto sobre 
o que está sendo entregue em cada momento, inclusive o que eventualmente possa 
ficar como backlog para projetos futuros. 
Para o processo Criar a EAP:
• Ferramentas e Técnicas: analise com atenção a proposta do uso de EAPs (Estrutura 
Analítica do Projeto) orientadas às atividades, elaboração de EAP em ondas sucessivas 
e planejamento em ondas sucessivas para projetos com ciclo de vida adaptativo. Sua 
EAP deve ser atualizada de acordo com a evolução do entendimento do que será 
entregue, e neste caso pode utilizar atividades em sua estrutura, se for cabível. 
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
7
Para o processo Validar o Escopo:
• Entradas: considerando mais uma vez que as entregas podem ser parciais, assim 
como o atendimento dos requisitos, controlar o que será validado em cada momento 
é importante, principalmente se você estiver utilizando ciclo de vida adaptativo 
(também conhecido como interativo ou incremental), que é utilizado frequentemente 
quando se aplicam métodos ágeis. 
2.3 Processos de tempo
Para o processo Definir as Atividades:
• Entradas: atenção com ativos de processos organizacionais relacionados a documentos 
de governança corporativa e também do próprio projeto. Você não pode executar 
seus projetos sem entender e seguir as diretrizes, bem como sem analisar o que está 
acontecendo a sua volta.
• Ferramentas e Técnicas: diagramas de casos de uso são utilizados em larga escala no 
desenvolvimento de software, e têm sucesso comprovado. Se você não os conhece 
nem utiliza, procure se aprofundar no assunto, pois eles podem resolver vários 
problemas que você eventualmente tem encontrado.
• Saídas: não se esqueça de incluir em sua lista de atividades aquelas que não são 
executadas pela sua equipe, mas que podem ter impacto no desempenho do projeto.
Para o processo Sequenciar as Atividades:
• Ferramentas e Técnicas: não se esqueça de considerar acordos de nível de serviço 
(ANS) quando estiver sequenciando suas atividades.
Para o processo Controlar o Cronograma:
• Ferramentas e Técnicas: tenha evidências de que as atividades foram concluídas. Não basta 
atualizar o cronograma para indicar avanço nos relatórios de desempenho. Relatórios de 
Burndown são uma excelente ferramenta para controlar o avanço do projeto.
2.4 Processos de custos
Para o processo Planejar o Gerenciamento dos Custos:
• Entradas: atenção com ativos de processos organizacionais relacionados às diretrizes de 
custos, infraestrutura disponível, políticas de governança e gerenciamento de portfólios.
• Saídas: destaque para a precisão das estimativas e a confiabilidade dos dados que 
serão utilizados como parâmetro para estas estimativas.
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
8
Para o processo Estimar os Custos:
• Entradas: medir o tamanho de um software é uma tarefa árdua, notadamente no início 
do planejamento, quando possivelmente ainda não se tem detalhes suficientes para 
uma estimativa precisa. Métodos como Análise por Pontos de Função (APF) auxiliam, 
mas não se aplicam se não houver um histórico confiável para utilizar como referência.
Para o processo Controlar os Custos:
• o Ferramentas e Técnicas: Gerenciamento de Valor Agregado (GVA) ou Earned Value 
Management (EVM) (PMI, 2011) é uma técnica que tem conquistado muitas empresas 
e muitos gerentes de projetos pelo mundo. Ela está baseada no controle do 
desempenho do projeto com base na comparação entre o custo relativo do que foi 
agregado (efetivamente entregue) e o que foi planejado. Este valor agregado serve de 
base para se avaliar o desempenho com relação a custos e a prazo. 
Para se aprofundar em GVA, consulte o manual específico publicado pelo 
PMI®: Practice Standard for Earned Value Management. (PMI, 2011). Se você já 
se associou ao PMI® poderealizar o download de sua cópia deste manual. 
2.5 Processos de qualidade
Para o processo Controlar a Qualidade:
• Entradas: para controlar a qualidade em projetos de desenvolvimento de software é 
importante ter planejado o uso de métricas adequadas, dependendo do ciclo de vida 
adotado e do tipo de plataforma que está sendo utilizada. São utilizados com frequência 
critérios de desempenho, quantidade de linhas de código, tempo de desenvolvimento, 
checklists de qualidade e avaliação dos usuários finais durante os testes.
2.6 Processos de recursos humanos
Para o processo Planejar o Gerenciamento dos Recursos Humanos:
• Saídas: considere no planejamento do gerenciamento dos recursos humanos 
fatores específicos que motivam equipes de desenvolvimento de software, como 
a oportunidade de aprender novas tecnologias, perspectiva de participação na 
construção de um software inovador e desenvolvimento de habilidades técnicas 
individuais. Normalmente as equipes apresentam melhor desempenho se o controle 
não for excessivo, e quando a colaboração mútua é incentivada e recompensada.
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
9
Para o processo Desenvolver a Equipe do Projeto:
• Ferramentas e Técnicas: algumas técnicas apresentam resultados expressivos, como 
programação em pares, desenvolvimento orientado a testes, coalocação e construção 
de ambiente colaborativo e sinérgico.
2.7 Processos de comunicações
Para o processo Gerenciar as Comunicações:
• Entradas: quando se utilizam métodos ágeis podem ser criados planos para cada versão. 
• Ferramentas e Técnicas: profissionais de TI normalmente têm facilidade no uso 
de ferramentas colaborativas. Considere o uso de redes sociais e outros recursos, 
principalmente se você estiver trabalhando com uma equipe virtual, localizada 
geograficamente em locais diferentes.
2.8 Processos de riscos
Para o processo Planejar as Respostas aos Riscos:
• Entradas: o plano de gerenciamento dos riscos define como os riscos serão 
gerenciados. Não confunda isso com o planejamento das respostas aos riscos, que 
é o objetivo deste processo. As respostas aos riscos normalmente são individuais e 
específicas para cada risco identificado. 
• Saídas: após a identificação, análise e planejamento das respostas aos riscos, é 
possível que o projeto seja abortado, pois o risco ao qual ele está exposto pode estar 
acima dos limites aceitáveis para este projeto e para a organização. É essencial dosar 
o otimismo para não executar um projeto que pode perder o controle no futuro. 
2.9 Processos de aquisições
Para o processo Planejar o Gerenciamento das Aquisições:
• Entradas: é importante analisar a capacidade de desenvolvimento interno, se a sua 
organização tem uma área interna de desenvolvimento, em relação aos fornecedores 
disponíveis. Pode ser mais interessante contratar o projeto todo externamente, se 
você não tem capacidade interna para atender, ou mesmo se tiver disponibilidade de 
fornecedores qualificados e comprovadamente eficientes. 
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
10
2.10 Processos de partes interessadas
Para o processo Planejar o Gerenciamento das Partes Interessadas:
• Entradas: não há dúvida de que uma das maiores dificuldades em projetos de 
TI é conciliar a disponibilidade das partes interessadas com as necessidades do 
projeto. O agendamento de atividades, cotidianas ou relacionadas a projetos 
mudam constantemente, em especial por conta de atividades urgentes que surgem 
constantemente. O impacto da não participação de uma parte interessada chave em 
determinado momento do projeto pode ser catastrófico para o cronograma. Desta 
forma, é essencial planejar com extremo cuidado e zelo como estas situações serão 
gerenciadas. Consulte cada parte interessada e valide a sua disponibilidade, tanto 
durante o planejamento quanto durante a execução do projeto.
Para o processo Gerenciar o Engajamento das Partes Interessadas:
• Ferramentas e Técnicas: a adoção do termo “engajamento” foi muito feliz, pois é 
exatamente este tipo de atitude que falta em boa parte dos projetos. As pessoas 
acreditam que o desempenho do projeto não é problema delas, pois têm alguém a 
quem culpar por um eventual atraso: o gerente do projeto. Culpar alguém não resolve 
o problema ou atende às necessidade relacionadas ao projeto. Se você está alocado em 
atividades de projetos, com certeza o seu engajamento efetivo será visto com bons 
olhos, independentemente de qual é a sua função neste projeto (RICARDI, 2014).
Reforço a recomendação para que você se associe ao PMI®, pois assim 
terá acesso ao Software Extension to The PMBOK® Guide (PMI, 2013), e poderá 
consultar em detalhes o que se aplica a cada processo. 
Consulte também:
o Capability Maturity Model Integration (SEI);
o ISO/IEC/IEEE 12207: Systems and software engineering-Software project 
life cycle processes (IEEE, 2008).
Senac São Paulo - Todos os Direitos Reservados
Gestão de Projetos em Tecnologia da Informação
11
Considerações finais
Certamente você notou que não há como abordarmos todo o conteúdo do Software 
Extension durante este curso, assim como não é possível com relação ao Guia PMBOK®. Se de fato 
você está interessado em melhorar o seu desempenho nos seus projetos de desenvolvimento 
de software, independentemente da função que desempenha, considero essencial que você 
conheça estes dois Guias em detalhes, os entenda, e saiba utilizá-los na prática.
É um esforço que tem recompensa certa, pois quem participa de projetos de TI sabe que 
eles podem se tornar traumáticos, com consequências incontroláveis. 
Se você trabalha em projetos para grandes corporações, seja como funcionário ou 
como prestador de serviços contratado, não deixe que o “dinheiro fácil” sirva de maquiagem 
para resultados inconsistentes. É comum empresas que têm grande capacidade financeira 
“camuflarem” sua ineficiência com aportes financeiros para “socorrer” projetos ineficientes, 
e até mesmo fadados a serem cancelados.
A concorrência está se especializando, tanto na esfera corporativa quanto na esfera 
individual, e se você continuar conduzindo seus projetos como tem feito pode não ser 
suficiente para mantê-lo onde está. Pense a respeito.
Referências
IEEE. Computer Society. ISO/IEC/IEEE 12207: systems and software engineering-software 
project life cycle processes. 2. ed. Geneva: ISO, 2008.
IIBA. Um guia para o corpo de conhecimento de análise de negócios (TM) (Guia BABOK(R)). 
versão 2.0. Toronto: IIBA, 2011.
IIBA. International Institute of Business Analysis. Disponível em: http://www.iiba.org.br/. Acesso 
em: 30 abr. 2014.
PMI. PROJECT MANAGEMENT INSTITUTE. Practice standard for earned value management. 
Pensilvânia: Project Management Institute, 2011.
PMI. PROJECT MANAGEMENT INSTITUTE. Software extension to the PMBOK guide fifth 
edition. Pensilvânia: Project Management Institute, 2013.
PMI. PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de 
projetos: guia PMBOK. Pensilvânia: Project Management Institute, 2013.
RICARDI, André L. F. EasyBOK: um guia de sobrevivência para o gerente de projetos. BRASIL: 
Campus Elsevier, 2014.
SEI. Software Engeneering Institute. Capability maturity model integration (CMMI). Disponível 
em: http://www.sei.cmu.edu/cmmi/. Acesso em: 30 abr. 2014.
 http://www.iiba.org.br/
http://www.sei.cmu.edu/cmmi/
	Introdução
	1 Características e aspectos gerais de projetos de desenvolvimento de software
	2 Software extension to the PMBOK® Guide
	Considerações finais
	Referências