Embed Size (px)
Citation preview
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO
PUC-SP
Rommel Gabriel Gonçalves Ramos
Gestão de Projetos: O Monitoramento e Controle nos Processos de Desenvolvimento de Software
MESTRADO EM TECNOLOGIAS DA INTELIGÊNCIA E DESIGN DIGITAL
SÃO PAULO
2014
Rommel Gabriel Gonçalves Ramos
Gestão de Projetos: O Monitoramento e Controle nos Processos de Desenvolvimento de Software
MESTRADO EM TECNOLOGIAS DA INTELIGÊNCIA E DESIGN DIGITAL
Dissertação apresentada à Banca Examinadora da Pontifícia Universidade Católica de São Paulo, como exigência parcial para obtenção do título de MESTRE em Tecnologias da Inteligência e Design Digital, sob a orientação do Professor Doutor Daniel Couto Gatti.
SÃO PAULO - SP
2014
Banca Examinadora
____________________________
____________________________
____________________________
A Deus, acima de tudo.
AGRADECIMENTOS
Agradeço em primeiro lugar a Deus, pela oportunidade de viver e ter me
concedido várias experiências espirituais e intelectuais.
À minha família e amigos pelas palavras de incentivo e motivação, e que durante
o mestrado deixei de compartilhar de momentos, mas que certamente serão
compensados.
Ao meu orientador, Professor Doutor Daniel Couto Gatti pela sua dedicação,
empenho e ensinamentos durante este tempo de convivência, e aos professores
do TIDD e da banca examinadora pela contribuição acadêmica.
Aos colaboradores da PUC-SP, que sempre me acolheram, em especial a Sra.
Edna que demonstrou dedicação e carinho pelo seu ofício e deu a devida
atenção, oferecendo-me o suporte necessário durante o curso.
Aos colegas de trabalho da CEDES/SP da Caixa Econômica Federal, pela
colaboração, aprendizado e conhecimento, em especial ao Sr. André Carlos, que
sempre me deu o suporte nas atividades a serem desenvolvidas.
Aos meus alunos de graduação tecnológica da FMU, por fazer com que os
assuntos e momentos em sala de aula fossem sempre presentes ao tema
escolhido nesta dissertação.
RESUMO
O propósito desta pesquisa é investigar a dificuldade existente na aplicação da
atividade de monitoramento e controle nos processos de desenvolvimento de
software, apresentando ferramentas e indicadores que podem auxiliar a sua
utilização constante. Apesar dos processos de desenvolvimentos de software
indicar atividades ligadas ao monitoramento e controle, na gestão de projetos
ainda há uma carência no uso efetivo dessas atividades. No estudo de caso será
abordado o monitoramento e controle sobre os processos de desenvolvimento de
software, destacando a utilização de indicadores de produtividade de uma
empresa, realizando uma mensuração quanto ao desempenho das atividades de
entregas realizadas na produção de software.
Palavras-chave: Gestão de Projetos, Processos de Software, Monitoramento e
Controle, Métricas de Software.
ABSTRACT
The purpose of this research is to investigate the existing difficulty in applying the
activity of monitoring and control in the processes of software development,
presenting tools and indicators that can help to their constant use.
Although the processes of software developments indicate activities related to
monitoring and control in project management are still lacking in the effective use
of these activities. In the case study will address the monitoring and control over
the processes of software development, emphasizing the use of indicators of
productivity of a company by performing a measurement on the performance of
deliveries in software production activities.
Keywords: Project Management, Software Processes, Monitoring and Control
Software Metrics.
LISTA DE FIGURAS
FIGURA 1 Processo Cascata............................................................................35
FIGURA 2 Processo Iterativo e Incremental......................................................37
FIGURA 3 Processo de Prototipação................................................................38
FIGURA 4 Processo Unificado RUP..................................................................42
FIGURA 5 Monitoramento e Controle no RUP..................................................52
FIGURA 6 Monitoramento e Controle no PMBOK.............................................54
FIGURA 7 Monitoramento e Controle na MGCP...............................................61
FIGURA 8 Fases e Atividades na MGCP.........................................................62
FIGURA 9 Modelo de Medição da ISO/IEC 15939...........................................74
FIGURA 10 Organograma da Estrutura de Tecnologia da Informação...............82
FIGURA 11 Fluxo dos Controles Institucionais....................................................83
FIGURA 12 Modelo de Desenvolvimento............................................................87
FIGURA 13 Demandas Previstas para a Implantação........................................94
FIGURA 14 Demandas Replanejadas.................................................................94
FIGURA 15 Demandas Implantadas...................................................................95
FIGURA 16 Sistemas sem o item de Portfólio.....................................................95
FIGURA 17 Projetos sem o item de Portfólio......................................................96
LISTA DE TABELAS
TABELA 1 Comparação dos Processos de Software........................................40
LISTA DE ABREVIATURA E SIGLAS
APF Análise de Pontos de Função
ALM Application Lifecycle Management
BSC Balanced Scorecard
COBOL Common Business Oriented Language
GE Gerência Executiva
GN Gerência Nacional
GQM Goal Question Metric
IBM International Business Machine
IDE Integrated Development Environment
IEC International Electrotechnical Commission
ISO International Organization for Standardization
MGCP Metodologia de Gerenciamento de Projetos
PE Projeto Evolutivo
PHP Personal Home Page
PN Projeto Novo
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
PSM Practical Software Measurement
QFD Quality Function Deployment
RGB Rummler Brache Group
RTC Rational Team Concert
RUP Rational Unified Process
TI Tecnologia da Informação
UML Unified Modeling Language
WEB World Wide Web
SUMÁRIO
1. INTRODUÇÃO ...................................................................................................... 13
1.1 Problema ........................................................................................................ 15 1.2 Justificativa ..................................................................................................... 17 1.3 Objetivos da Pesquisa .................................................................................... 22 1.4 Metodologia .................................................................................................... 23 1.5 Estrutura do Trabalho ..................................................................................... 25
2. FUNDAMENTAÇÃO TEÓRICA ............................................................................ 27
2.2. Gestão de Projetos de Software .................................................................... 27 2.2.1. Planejamento ....................................................................................... 29 2.2.2. Riscos .................................................................................................. 30 2.2.3. Monitoramento e Controle ................................................................... 31
2.3. Processos de Software .................................................................................. 32 2.3.1 Ciclo de Vida ......................................................................................... 34 2.3.2 Tipos de Processos de Software .......................................................... 35
2.4. Medidas e Métricas do Software .................................................................... 43
3. O MONITORAMENTO E CONTROLE NOS PROCESSOS DE
DESENVOLVIMENTO DE SOFTWARE ................................................................... 45
3.1 Monitoramento e Controle na Análise Estruturada ......................................... 47 3.2 Monitoramento e Controle no RUP ................................................................. 47 3.3 Monitoramento e Controle no PMBOK ........................................................... 53 3.4 Monitoramento e Controle na MGCP .............................................................. 60 3.5 Ferramentas para o Monitoramento e Controle .............................................. 64
3.5.1 Ms Project ............................................................................................. 67 3.5.2 DotProject ............................................................................................. 68 3.5.3 RTC ...................................................................................................... 70
3.6 Indicadores para o Monitoramento e Controle ................................................ 72
4. ESTUDO DE CASO .............................................................................................. 77
4.1 Descrição da Empresa ................................................................................... 81 4.1.1 Área de Tecnologia da Informação ....................................................... 81 4.1.1.1 Processo Padrão de Desenvolvimento de Sistemas ......................... 83 4.1.1.2 Unidades de Desenvolvimento de Sistemas ...................................... 87 4.1.1.3 Tipos de Projetos ............................................................................... 88 4.1.1.4 Indicadores de Produtividade ............................................................ 89
4.2 Coleta de Dados ............................................................................................. 91 4.2 Análise de Dados ............................................................................................ 97 4.3 Análise dos Resultados .................................................................................. 98
5. CONSIDERAÇÕES FINAIS ................................................................................ 101
6. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................... 106
13 1. Introdução
A gestão de projetos de software tem se fortalecido ao longo dos anos em
razão da necessidade de garantir a qualidade e o sucesso dos projetos de
software.
Aliada aos conceitos clássicos da área da administração, tais como
planejar, coordenar e controlar, com os elementos específicos da engenharia de
software em relação aos processos de software consegue integrar os aspectos
tanto organizacionais quanto técnicos.
As atividades organizacionais atribuídas à gestão de projetos de software
vão desde o atendimento às necessidades do cliente em relação a um produto
e/ou serviço, até o relacionamento com os envolvidos em todo o ciclo de vida do
projeto, já que as atividades técnicas englobam desde as metodologias de
desenvolvimento de software até a implantação propriamente dita do software.
Segundo Humphrey (1989 p.125):
A ausência de práticas administrativas no desenvolvimento de software é a principal causa de sérios problemas enfrentados pelas organizações, tais como: atrasos em cronogramas, custo maior do que o esperado e presença de defeitos, ocasionando uma série de inconveniências para os usuários e enorme perda de tempo e de recursos.
Decidir sobre a utilização de um instrumento para aplicar as práticas
administrativas principalmente em relação à gestão projetos de software torna-se
adequado, pois, os ganhos que são obtidos com essa iniciativa acrescentam o
aperfeiçoamento dos processos, mas existem fatores que devem ser observados.
Conforme Sommerville (2007, p.62), alguns fatores tornam a gestão de
projetos de software mais complexa como:
• intangibilidade do produto: dificuldade de avaliar o progresso do projeto,
já que o produto de software não é visível;
14
• incompatibilidade dos processos de software: variam drasticamente de
uma organização para a outra, e mesmo toda a evolução nesta área,
ainda há dificuldade de prever problemas no desenvolvimento;
• unicidade dos projetos de software de grande porte: esse tipo de
projeto geralmente é diferente dos anteriores e mesmo com experiência
da equipe não consegue prever os problemas.
O trabalho da gestão de projetos de software é tentar cumprir o que foi
planejado. Muitos projetos fracassam em seus objetivos ou não os alcançam
plenamente devido a diversos desvios ou falhas que não foram identificados no
seu planejamento. Para obter mais qualidade, não só no software, mas em todo o
seu processo, deve-se realizar um planejamento minucioso.
O planejamento diz como e onde a equipe deveria estar em determinado
momento. O monitoramento e controle, por sua vez, consistem em acompanhar
as atividades não planejadas com a finalidade de identificar possíveis problemas
ou desvios e deflagrar eventuais ajustes que possam ser necessários para fazer
o projeto de volta ao seu caminho original. (MARTINS, 2007 p. 102)
Nesta dissertação será abordada a contribuição do monitoramento e
controle aos processos de desenvolvimento de software, para auxiliar a gestão de
projetos a conduzir as suas atividades, o que pode melhorar a maneira de
acompanhamento dos seus processos.
Monitorar e Controlar é definido pelo o PMI (2008, p. 369) como “coletar os
dados do projeto referente ao plano de gerenciamento, produzindo medições de
desempenho e divulgando essas informações por meio de relatórios”. Dessa
forma, podem ser tomadas ações corretivas quando desvios forem identificados,
garantindo o atendimento dos objetivos do projeto.
15 Analisando monitoramento e o controle, pode-se dizer que enquanto no
monitoramento estão às atividades envolvendo o acompanhamento e a coleta de
dados a respeito do andamento, no controle consiste na tomada de ações frente
aos desvios encontrados no monitoramento, e por isso é necessário que haja
uma medição e a apuração de indicadores com as informações que serão
reportadas a gestão de projetos de software.
1.1 Problema
Na acepção científica, “problema é qualquer questão que é objeto de
discussão, em qualquer domínio do conhecimento” (Gil, 1999, p. 49). Problema,
para Kerlinger (1980, p. 35): “é uma questão que mostra uma situação
necessitada de discussão, investigação, decisão ou solução”. Sintetizando,
problema é uma questão que a pesquisa pretende responder.
Nesta dissertação o problema está ligado com a dificuldade em fazer o
monitoramento e controle nos processos de desenvolvimento de software que
pode-se relacionar aos seguintes pontos:
1. A forma de utilização do monitoramento e controle nos processos de
desenvolvimento de software.
Nem sempre os processos e metodologias de desenvolvimento de
software deixam explícito como deve ser feito o monitoramento e controle.
E normalmente cada metodologia aborda o processo de software
buscando a execução das suas fases e atividades sem nenhum tipo de
monitoramento e controle.
16
Quando o processo de desenvolvimento de software for estabelecido,
pode-se iniciar a monitoração e controle no aspecto da gestão de projetos,
e que para Pressman (1995, p.59):
Cada tarefa anotada é então rastreada pelo gerente de projetos. Ele pode usar uma ferramenta de planejamento automatizada para determinar o impacto do não cumprimento dos prazos sobre os marcos de referência. Recursos podem ser redirecionados, tarefas reordenadas, compromissos de entrega modificados para acompanhar o problema que foi descoberto.
2. As ferramentas não são suficientes para o suporte das atividades de
monitoramento e controle nos processos de desenvolvimento de
software.
Algumas ferramentas disponíveis no mercado como o MsProject,
DotProject, Rational Team Concert (RTC - IBM) dentre outras, que são
utilizadas como suporte a gestão de projetos de software não oferecem
opções suficientes para realizar o monitoramento e controle no
acompanhamento das fases e/ou atividades no processo de
desenvolvimento de software, pois, devem apresentar alguns pontos e ter
opções que permitam:
• selecionar projetos de software com alinhamento às estratégias
corporativas, analisando os seus impactos e riscos;
• gerenciar os recursos envolvidos em vários projetos de software,
compartilhando as suas informações de tempo, custo e qualidade.
• gerenciar o retorno de investimento em pequenos, grandes e
complexos projetos de software.
• gerenciar o ciclo de vida dos projetos promovendo melhorias
contínuas no processo de software.
17
3. Existem falhas no papel dos gerentes de projetos em relação ao
monitoramento e controle nos processos de desenvolvimento de
software.
O monitoramento e controle fornecem insumos importantes para que o
processo de desenvolvimento de software possa ser melhorado nas suas
fases e/ou atividades, mas, a atuação gerencial precisa ser mais eficaz e
eficiente em relação às ações preventivas e/ou corretivas, pois, de nada
adianta ter instrumentos que auxiliam este processo se não existe uma
atuação assertiva.
4. A tomada de decisão da gestão de projetos sem considerar os
indicadores e relatórios de produtividade, fornecidos pelo
monitoramento e controle nos processos de desenvolvimento de
software.
Os relatórios de desempenho extraídos dos indicadores devem estar
alinhados ao monitoramento e controle sendo uma maneira de trazer mais
visibilidade aos gestores de projetos.
Ainda que eles não sejam utilizados na sua totalidade, devem ser
considerados em ações a serem tomadas não somente pelo conhecimento
empírico, mas em informações consolidadas e confiáveis em relação aos
problemas identificados nos processos de desenvolvimento de software.
1.2 Justificativa
Segundo Brooks (1987), existem dificuldades inerentes às atividades da
engenharia de software que podem ser dividas entre as de essência e as de
acidentes. As de essência são classificadas utilizando quatro itens: A
18
complexidade do software, conformidade, mutabilidade e invisibilidade. Quanto à
sua complexidade, pode-se entender que o crescimento de um software é
diretamente proporcional à mesma.
A complexidade trata-se de uma propriedade inerente a um sistema de
software, devido ao fato de possuir um grande número de estados diferentes, o
que leva a concepção, descrição e teste de todos estes estados em uma tarefa,
principalmente pelo grande número de entidades, componentes, funções e tipos
de dados que se relacionam dentro de um sistema de software, o que leva a um
aumento de complexidade do software de maneira não linear devido ao aumento
destes relacionamentos. Ainda com relação à complexidade, Brooks (1987)
afirma que ela não está presente apenas nos sistemas de software, mas também
nos processos gerenciais e nas pessoas que estão envolvidas no
desenvolvimento de um software.
Quanto à sua conformidade, a falta dela é por conta das diversas
finalidades e aplicabilidades que um software possui, variando de um contexto
para outro e do objetivo destinado a um software. Grande parte da complexidade
com a qual o desenvolvedor deve lidar é crescente. Ela é imposta sobre ele por
instituições e sistemas humanos, com os quais o software precisa estar em
conformidade. Tal conformidade é dinâmica, visto que os sistemas humanos
mudam com o tempo, as pessoas mudam e o software deve ser modificado para
se adequar a novas realidades.
Quanto à sua mutabilidade, um software deve atender a diversas regras e
funcionalidades para atingir a um objetivo específico, sendo assim, o software
deve acompanhar as mudanças que ocorrem no ambiente em que está inserido,
para que se mantenha útil e alinhado aos seus propósitos, fazendo com que um
software esteja em constante mudança para atender a todas as necessidades a
19 que é endereçado, mantendo-se em constante evolução. Esta constante
evolução definida por Brooks (1987) como a mutabilidade de um software, é um
dos pontos que mais influenciam na sua complexidade, por conta do aumento
dos componentes envolvidos e das relações que são criadas.
Quanto à sua invisibilidade, Brooks (1987) acredita que, embora tenha
havido avanços no sentido de simplificar as estruturas de software, elas
continuam sendo praticamente impossíveis de serem visualizadas. Por isso, a
representação de um software prende-se apenas a interpretação de uma pessoa,
o que implica no bloqueio e defasagem da comunicação quanto ao seu
entendimento da forma de um software.
Nas dificuldades acidentais os ganhos não previstos ou desejados
interferem no desenvolvimento de um software. As linguagens de alto nível e as
técnicas de compartilhamento de tempo contribuíram para diminuir
substancialmente a complexidade acidental causada por estes proventos
indesejados, assim como para o aumento da produtividade e qualidade do
produto final.
Alguns avanços técnicos podem levar melhores condições para o
tratamento das dificuldades de acidente, ou evitar alguns deles, caso sejam
seguidos de forma linear. O compartilhamento público de boas práticas para
utilização de algoritmos de inteligência artificial, a maior variedade de linguagens
de alto nível, sistemas especialistas, linguagem de programação orientada a
objeto, entre outros itens, podem ser considerados para minimizar tais problemas.
Um item considerado essencial sobre os problemas acidentais é a
contratação de gerentes qualificados na utilização de menos recursos e esforços
20
e se concentrando principalmente nos problemas acidentais, mas buscando de
alguma forma os quase inevitáveis problemas de essência.
Essas dificuldades acidentais e essenciais podem ser monitoradas e
controladas nos processos de desenvolvimento de software, sendo demonstradas
em relatórios e indicadores para saber o desempenho na produção de software,
tornando esse acompanhamento adequado à gestão de projetos.
O guia de gerenciamento de projetos (PMBOK, 2008) traz a referência dos
processos de monitoramento e controle descrevendo o que deve ser utilizado,
através de entradas e saídas, em áreas de conhecimento de gerenciamento
como: escopo, tempo, custos, qualidade, recursos humanos, comunicação, riscos
e aquisição.
Uma pesquisa do PMI (Instituto de Gerenciamento de Projetos) realizada
em 2012, revelou a frequência com que as empresas brasileiras adotam
atividades de monitoramento e controle em seus projetos. Nesta pesquisa
identificou que:
• 22% sempre adotam.
• 54% adotam na maioria das vezes;
• 24% nunca adotaram
Com a análise desses dados, identificamos que 76% das empresas de
certa forma adotam alguma forma de acompanhamento das fases e/ou atividades
dos projetos, porém, 24% das empresas não se preocupam em fazer nenhum
monitoramento e controle. Esses dados não se diferem do cenário quanto aos
problemas mais frequentes enfrentados pelas empresas em relação aos seus
projetos atribuídos a prazo (65,7%), escopo (61,7%) e custo (41,3%).
21 Neste estudo, 18,4% dos problemas está relacionado à falta de uma
ferramenta para o monitoramento e controle, indicando que 24,5% dos softwares
mais utilizados são desenvolvidos internamente por opção da empresa, o que
mostra que as empresas não conseguem encontrar uma ferramenta adequada
devido as necessidades e particularidades internas (PMI, 2012).
Cabe destacar que, habitualmente, o monitoramento e controle é
considerado pelo nível operacional como uma ação de auditoria, em que são
tratadas as inconformidades das atividades e dos processos. Esse pensamento
dificulta a sua abordagem do que deve ser entendido, pois não é apenas uma
tarefa externa que verifica como o processo está sendo conduzido, mas se ele é
realmente entendido pela equipe e principalmente se gera valor aos envolvidos e
responsáveis pelo processo.
O monitoramento e controle nos projetos de software deve ser
acompanhado por meio de relatórios que possam fornecer informações para
responder algumas perguntas:
• Qual a estabilidade dos requisitos do projeto?
• Qual o grau de previsibilidade que está sendo conseguindo, quanto às
estimativas de esforços e prazos?
• Qual tem sido o esforço de replanejamento do projeto? os
replanejamentos têm trazido maior previsibilidade?
• Quais riscos previstos e concretizados?
• Quais atividades/fases estão sendo realizadas e qual o impacto delas
nos projetos de software? e quais os recursos necessários?
Os resultados obtidos quando respondemos essas perguntas devem ser
apurados e analisados, podendo-se definir métricas e/ou indicadores, ou seja,
22
medir o desempenho que implica principalmente na tomada de decisão, que nos
dá oportunidade de exercer o trabalho da gestão de projetos de forma síncrona
nos processos de desenvolvimento de software.
1.2 Objetivos da Pesquisa
Os objetivos desta pesquisa ajudaram a delimitar as questões relacionadas
com a gestão de projetos e os processos de desenvolvimento de software, cujas
atividades de monitoramento e controle serão discutidas e tratadas, isto é, as
questões relacionadas com:
a) a forma de trabalho dos envolvidos no desenvolvimento de software;
b) a qualidade do produto resultante do desenvolvimento;
c) a melhoria dos processos
Portanto, segue abaixo os objetivos específicos desta pesquisa.
1) identificar como o monitoramento e controle são tratados nos
processos de desenvolvimento de software, e como são
relacionadas com a gestão de projetos;
2) investigar a influência dos indicadores nas atividades de
monitoramento e controle;
3) investigar e descrever as ferramentas comumente utilizadas nas
atividades de monitoramento e controle;
4) realizar um estudo de caso numa empresa para identificar como são
tratadas as atividades de monitoramento e controle.
23 1.4 Metodologia
A pesquisa é um conjunto de ações que são propostas para encontrar
soluções a um determinado problema, baseada em procedimentos racionais e
sistemáticos, segundo Silva e Menezes (2005).
A metodologia de pesquisa tem como objetivo convidar a ciência a
especular e convidar a filosofia a interessar-se pelos problemas práticos, ou seja,
o objetivo da metodologia é ajudar a compreender, nos mais amplos termos, não
os produtos da pesquisa, mas o próprio processo (BARBARÁN, 1999).
Esta dissertação adotará como metodologia o estudo de caso. Esse tipo de
pesquisa seleciona um objeto de pesquisa restrito, com o objetivo de aprofundar o
conhecimento de seus aspectos característicos. O foco do estudo de caso pode
ser um indivíduo, um grupo social específico, uma comunidade ou uma
organização.
Existem duas abordagens possíveis para a condução das pesquisas:
qualitativa e quantitativa. A pesquisa utilizada nesta dissertação é a qualitativa
que segundo Bryman (1989, p.67):
“O pesquisador observa os fatos sob a ótica de alguém interno à organização, buscando uma profunda compreensão do contexto da situação, enfatizando o processo dos acontecimentos, isto é, a sequência dos fatos ao longo do tempo, onde o enfoque da pesquisa é mais desestruturado, não tendo hipóteses fortes no seu início, tornando a pesquisa bastante flexível”.
A abordagem qualitativa busca obter a perspectiva e as interpretações do
entrevistado dentro de seu ambiente de trabalho, através de uma profunda
investigação.
Exige uma maior proximidade do pesquisador às circunstâncias nas quais
a empresa está introduzida, procurando aprofundar-se no contexto da
organização (BARBARÁN, 1999).
24
As ações propostas para resolver os problemas apresentados na pesquisa
são:
1) disseminar a importância do conhecimento teórico do monitoramento e
controle nos processos de desenvolvimento de software aplicados à
gestão de projetos de software, que inclusive esta dissertação torna-se
um instrumento para realizar esta ação;
2) relatar as melhorias que devem ser realizadas nas ferramentas de
software para auxiliar no monitoramento de controle nos processos de
desenvolvimento de software;
3) fornecer argumentos, nesta pesquisa, como insumos necessários para
que a gestão de projetos possa melhorar a sua forma de atuação
quanto ao monitoramento e controle, identificando nos processos de
software as deficiências quanto à aplicação desta atividade;
4) abordar o estudo de caso com a iniciativa de poder realizar o
monitoramento e controle nos processos de desenvolvimento de
software de forma que a gestão de projetos de software da organização
possa obter indicadores de produtividade para a tomada de decisão
quanto aos seus projetos e sistemas.
Pode-se dizer que um projeto de pesquisa que envolva o estudo de caso
envolve três fases distintas (YIN, 2001, pp 40-77):
1) a escolha do referencial teórico sobre o qual se pretende trabalhar. A
seleção dos casos e o desenvolvimento de protocolos para a coleta de
dados;
2) a condução do estudo de caso, com a coleta e análise de dados,
culminando com o relatório do caso;
25
3) a análise dos dados obtidos à luz da teoria selecionada, interpretando
os resultados.
A abordagem adotada nesta pesquisa é um estudo de caso que envolve o
monitoramento e controle em relação aos processos de desenvolvimento de
software de uma organização. Enquadra-se como uma abordagem qualitativa e é
utilizado para os estudos organizacionais.
O processo metodológico desta pesquisa considerou as etapas descritas
conforme abaixo:
1) realização de pesquisas, leituras de artigos e livros para a elaboração
da fundamentação teórica;
2) pesquisas, leituras para elaboração e conceituação do monitoramento e
controle aplicado aos processos de desenvolvimento de software;
3) levantamento de ferramentas de software utilizadas para o
monitoramento e controle atrelado aos processos de desenvolvimento
de software;
4) levantamento de informações para elaborar o estudo de caso baseado
no monitoramento e controle nos processos de desenvolvimento de
software de uma empresa.
1.5 Estrutura do Trabalho
Este trabalho está estruturado em 4 capítulos:
• O Capítulo 1 introduz o tema e apresenta à justificativa, os objetivos, a
metodologia e a estrutura do trabalho.
26
• O Capítulo 2 apresenta a base conceitual do trabalho através da
fundamentação da gestão de projetos de software, processos de software
monitoramento e controle e métricas de software.
• No Capítulo 3, será abordado o monitoramento e controle nos processos
de desenvolvimento de software, além das ferramentas e indicadores que
podem ser utilizados para auxiliar esta atividade na gestão de projetos.
• No Capítulo 4, é apresentando um estudo de caso abordando o problema
de monitoramento e controle nos processos de desenvolvimento de
software de uma empresa, realizando a coleta de dados, analisando os
resultados com o auxílio de indicadores, finalizando a pesquisa com
sugestão e propostas de trabalhos futuros.
27 2. Fundamentação Teórica
Neste capítulo são definidos conceitos-chave fundamentais para a
pesquisa: Gestão de Projetos de Software, Monitoramento e Controle, Processos
de Software, Medidas e Métricas de Software.
2.2. Gestão de Projetos de Software
Para Pressman (1995, p.55) “a gestão de projetos é a primeira camada do
processo de engenharia de software. Ele chama de camada, em vez de etapa ou
atividade, porque ela abrange todo o processo de desenvolvimento de software
do começo ao fim”.
A gestão de projetos de software compreende atividades que visam
assegurar que o sistema ou produto de software seja entregue ao cliente no prazo
pré-definido e esteja de acordo com os requisitos estabelecidos.
A necessidade da gestão de projetos de software deve ser ao fato do
desenvolvimento de software estar sujeito às restrições de qualidade, tempo e
orçamento.
Cada vez mais a gestão de projetos é reconhecida no mundo empresarial
como afirma Kerzner (2001, p.17): “... percebe-se que o mundo empresarial
passou a reconhecer a importância da gestão de projetos, tanto para o futuro
quanto no presente”.
28
A meta da gestão de projetos é conseguir exceder as necessidades e
expectativas dos stakeholders1. Todavia, satisfazer ou exceder estas
necessidades envolvem várias demandas em relação aos itens abaixo:
• Escopo, tempo, custo e qualidade (objetivos do projeto);
• Stakeholders com necessidades e expectativas diferenciadas;
• Requisitos identificados (necessidades) e requisitos não
identificados (expectativas).
Em Kerzner (2001, p. 29), lê-se o seguinte:
Desde o começo da década de 1990, a corrida pela excelência na gestão de projetos tem assumido uma importância cada vez maior. Os benefícios da gestão de projetos são óbvios hoje tanto para os clientes quanto para os fornecedores. De fato, a excelência em gestão de projetos se tornou uma arma competitiva que atrai novos negócios e mantém os clientes tradicionais.
A gestão de projetos tem sido aprimorada nos últimos anos no sentido de
obtenção de um entendimento comum por parte dos profissionais e organizações
e que segundo Kerzner (2006, p. 82):
Quanto mais a gestão de projetos continuar crescendo e se consolidando, maior será o número de aliados. No século XXI, nações do Segundo e Terceiro Mundo passarão a reconhecer os benefícios e a importância da gestão de projetos definindo assim padrões.
A empresa que pretende alcançar a excelência em gestão de projetos
necessariamente terá de desenvolver um processo de implantação bem sucedido.
A velocidade dessa implantação irá definir a rapidez da concretização dos
objetivos e benefícios da gestão de projetos (KERZNER, 2006 p. 82).
1 Stakeholders: partes interessadas a partir da identificação de todas as pessoas ou organizações que possam ser afetadas pelo projeto e de documentação das informações relevantes relacionadas aos seus interesses, envolvimento e impacto no sucesso do projeto (PMBOK, 2008 p.311).
29 2.2.1. Planejamento
O planejamento é o momento em que se definem as atividades e sua
sequência de execução. Conforme o dicionário Aurélio, planejar é elaborar, por
etapas, planos e programas com objetivos definidos, segundo roteiro e métodos
determinados. O planejamento potencializa o trabalho em grupo, impulsionando a
participação e comprometimento.
Por ser uma atividade multidisciplinar, o planejamento agrega vários
pontos de vista, inclusive em diversas áreas de conhecimento, pois, possibilita o
gerenciamento do projeto.
Antes que um projeto possa ser planejado, os objetivos e o escopo devem
ser estabelecidos, soluções alternativas devem ser consideradas e as restrições
administrativas e técnicas, identificadas.
Sem essas informações, é impossível definir estimativas de custo
razoáveis (e precisas), uma divisão realística das tarefas do projeto ou uma
programação de projeto administrável que ofereça indícios significativos de
progresso (PRESSMAN, 1995 p.56).
Muitos projetos de software são realizados sem um planejamento de como
o levantamento de requisitos e as necessidades dos clientes podem ser
transformadas em produto.
Os gerentes de projeto de software não conseguem estimar, e quando
estimam, costumam basear-se em estimativas passadas, mesmo sabendo que
elas podem estar incorretas.
Devido à dificuldade de estabelecer uma estimativa, existe uma barreira na
sua elaboração por julgar perda de tempo ou correr o risco de obter resultados
incorretos e, portanto, estar desperdiçando tempo.
30
As estimativas de custo, esforço e prazo no projeto de software requerem
um processo ordenado que defina a utilização de métricas, métodos e
ferramentas de estimativa.
Quando fazemos a estimativa do esforço dos recursos, identificamos a
nossa capacidade produtiva de atuação nas atividades inerentes ao projeto de
software, da mesma maneira, aplicamos a estimativa de custo e tempo onde
saberemos quanto devemos investir e quanto tempo irá gastar para realizar um
projeto.
Estimar, medir e controlar um projeto de software são tarefas pertinentes
ao desenvolvimento de software com muitas variáveis envolvidas (como
metodologias, modelos, técnicas, ferramentas, tecnologias, recursos e atividades
diversas). A definição de todas essas variáveis é a base para definir pontos de
verificação permitindo o acompanhamento do projeto, que envolve também a
mitigação dos riscos.
2.2.2. Riscos
Gerenciar projetos de software também envolve gerenciar riscos. Segundo
o dicionário Aurélio, risco é uma situação em que há probabilidades mais ou
menos previsíveis de perda ou ganho.
O gerenciamento de riscos deve permitir a identificação de quais as
probabilidades de atrapalhar o projeto venham a ocorrer. Ele deve ser capaz de
identificar, analisar, planejar, monitorar, controlar e comunicar o nível de risco do
projeto.
31 O gerenciamento contínuo de riscos faz parte da essência do
gerenciamento de projetos e é uma atividade que se estende ao longo de todo o
projeto
Segundo Somerville (2011, p.69), existem três principais tipos de riscos:
• riscos de projeto: afetam o cronograma ou os recursos do projeto;
• riscos de produto: afetam a qualidade ou o desempenho do software;
• riscos de negócio: afetam a organização que desenvolve ou adquire o
software.
O gerenciamento dos riscos nos projetos de software são importantes
devido às dúvidas surgidas e originadas de requisitos mal definidos, dificuldades
na estimativa de prazos e recursos necessários para o desenvolvimento de
software e as mudanças de requisitos devido às mudanças nas necessidades dos
clientes.
Por isso, planos de riscos devem ser elaborados para evitar, gerenciar ou
lidar com os prováveis efeitos dos riscos quando foram mitigados e se
ocorreram. No ato de acompanhar e gerenciar os riscos, uma atividade pertinente
à gestão de projetos de software é o monitoramento e controle.
2.2.3. Monitoramento e Controle
O monitoramento e controle nos projetos de software busca garantir a
verificação do que deve ser realizado no projeto, ou seja, acompanhar os
processos que são executados com as suas atividades, identificando ações
corretivas e preventivas, estabelecendo assim maneiras de tomada de decisão na
gestão de projetos de software.
32
Se na execução do projeto tem como objetivo entregar produtos e/ou
serviços planejados, o monitoramento e controle envolve o acompanhamento
destes resultados para garantir que estejam de acordo com o planejado e que o
projeto continue seguindo o plano de gerenciamento do projeto.
O monitoramento e controle fornecem subsídios para as atividades nos
processos de software. Com essas informações disponíveis aos gerentes de
projetos tem se a possibilidade de atuação constante ao que deve ser
desenvolvido e entregue por sua equipe, proporcionando melhorias em relação à
condução do projeto de forma assertiva.
O ciclo constante de planejar, executar, controlar e tomar ações corretivas
está na base do monitoramento e controle, recebendo o acrônimo de ciclo PDCA
(em inglês plan = planejar, do = fazer, check = verificar e act = atuar),
desenvolvido por W. Edward Deming para ambientes de operação e utilizado com
uma das melhores práticas em gestão de projetos.
2.3. Processos de Software
Por algum motivo, os livros de engenharia de software quase sempre
iniciam com o tema “crise de software”. Essa expressão vem dos anos 70. Mas o
que é isso afinal? O software está em crise? Parece que não, visto que hoje o
software está presente em quase todas as atividades humanas. Mas as pessoas
que desenvolvem software estão em crise há décadas e, em alguns casos parece
impotentes para sair dela (WAZLAWICK, 2011, p.14).
Em grande parte, parece haver desorientação em relação a como planejar
e conduzir o processo de desenvolvimento de software. Muitos desenvolvedores
concordam que não utilizam um processo adequado e que deveriam investir em
33 algum, mas ao mesmo tempo dizem que não têm tempo ou recursos financeiros
para fazê-lo. Essa história se repete há décadas. (WAZLAWICK, 2011 p.14).
Para Pressman (2006, p.17)
Os processos de software formam a base para o controle gerencial de projetos de software e estabelecem o contexto no qual os métodos técnicos são aplicados, os produtos de trabalho (modelos, documentos, dados, relatórios, formulários, etc.) são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas.
O processo de software possui, em geral, cinco macros estágios (Argila,
2000):
• análise - Consiste na análise e desenvolvimento dos requisitos de sistema
de software.
• design (Projeto) - Consiste no projeto de software com base nos requisitos.
O projeto pode conter: a definição da arquitetura de software a ser utilizada
bem como ferramentas e hardware necessário para a implementação do
sistema.
• implementação - Consiste na programação do sistema de software com
base nos documentos gerados na análise e no Design.
• testes - testes de unidade, integração, de sistema do software, que está
sendo construído. O objetivo é encontrar falhas antes da entrega ao
cliente.
• implantação - Consiste na entrega do produto de software ao cliente. Esta
fase pode envolver a instalação do produto (software).
Os processos de software são importantes, pois, estabelecem para os
membros da equipe de projeto uma diretriz de o que deve ser feito para atender
34
aos objetivos do software, ou seja, eles definem quais são as atividades que
permitem obter o produto de software. (HIRAMA, 2011, p.02).
2.3.1 Ciclo de Vida
Normalmente um software tem um ciclo de vida curto, de no máximo cinco
anos, quando não sofre implementações. Tem-se que partir do conceito de que
não existe software ‘pronto e acabado’, pois, ao longo de sua vida exigirá
manutenção, correções, melhorias ou implementações. (REZENDE, 2005 p.04).
O ciclo de vida de um software segundo Rezende (2005 p. 04) abrange
basicamente as fases:
• concepção (nascimento do sistema ou software);
• construção (análise e programação);
• Implantação (testes e disponibilização aos clientes e usuários);
• implementações (pequenos ajustes pós-implantação);
• maturidade e utilização plena (software sedimentado);
• declínio (dificuldade de comunicação);
• manutenção (tentativa de sobrevivência);
• morte (descontinuidade do sistema ou software)
As fases do ciclo de vida são utilizadas para descrever como um software
deve ser desenvolvido. Basicamente definem a ordem das atividades em um
contexto de projeto de software e propõe uma estratégia que pode ser aplicada a
um determinado contexto.
35 Normalmente os ciclos de vida são vagos nas descrições de detalhes nas
condições de término e início de uma atividade, recursos utilizados, artefatos
consumidos ou produzidos e papéis desempenhados.
2.3.2 Tipos de Processos de Software
Um dos primeiros processos de software existente foi o modelo cascata.
Este processo proposto por Royce (1970 p.329) é dividido em fases, que não se
repetiam ao longo do ciclo de vida conforme a figura 1 abaixo.
Figura 1 - Processo Cascata (Royce, 1970 p.329)
O processo cascata tornou-se conhecido na década de 70 e é referenciado
na maioria dos livros de engenharia de software. As atividades são estruturadas
numa cascata onde a saída de uma é a entrada para a próxima.
É criticado por ser linear, rígido e monolítico. Inspirados em modelos de
outras atividades de engenharia, este processo argumenta que cada atividade
apenas deve ser iniciada quando a outra estiver terminada e verificada.
36
Ele é considerado monolítico por não introduzir a participação de clientes e
usuário durante as atividades do desenvolvimento, mas apenas o software ter
sido implementado e entregue. Não existe como o cliente verificar
antecipadamente qual o produto final para detectar eventuais problemas.
A versão original foi melhorada e retocada ao longo do tempo e continua
sendo muito utilizada hoje em dia. Grande parte do sucesso do cascata está no
fato dele ser orientado para a documentação.
No entanto, considerando o monitoramento e controle neste processo de
software, não apresenta nenhuma atividade para retratar que estamos
desenvolvendo de forma correta o software e se a gestão de projetos neste
sentido está sendo aplicada.
Uma evolução do processo cascata foi o processo espiral, pois, repetia as
fases ao longo do ciclo de vida. O grande número de fases do processo em
espiral inviabilizou o seu uso na prática, pois, necessitava de um tempo para
manter o processo longo sem ter a entrega do produto de software.
O processo iterativo e incremental é uma extensão do espiral que foi
proposto por Boehm em 1988, como forma de integrar os diversos modelos
existentes à época, eliminando suas dificuldades e explorando seus pontos fortes,
sendo que foi desenvolvido para abranger as melhores características tanto do
cascata como o prototipação que será visto posteriormente.
Segundo essa abordagem iterativo e incremental, o processo divide o
desenvolvimento de um produto de software em ciclos. Em cada ciclo de
desenvolvimento, podem ser identificadas às fases de análise, projeto,
implementação e testes em contraste com a abordagem clássica, na qual as
fases de análise, projeto, implementação e testes são realizados uma única vez.
37
Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo
de desenvolvimento. No próximo ciclo, outro subconjunto dos requisitos é
considerado para ser desenvolvido, o que produz um novo incremento do sistema
que contém extensões e refinamentos sobre o incremento anterior.
Assim, o desenvolvimento evolui em versões, através da construção
incremental e iterativa de novas funcionalidades até o sistema completo esteja
construído.
Esta abordagem incremental e iterativa incentiva à participação do usuário
nas atividades de desenvolvimento de software, o que diminui em muito a
probabilidade de interpretações erradas em relação aos requisitos levantados
com a vantagem de que os riscos do projeto podem ser bem gerenciados
conforme a figura 2 abaixo.
Figura 2 - Processo Iterativo e Incremental (Bezerra, 2002 p.37)
O processo de software baseado na prototipação procura suprir as
limitações do modelo cascata, ou seja, ao invés de manter inalterado o requisito
durante o projeto e codificação, um protótipo é desenvolvido para ajudar no
entendimento dos requisitos.
38
Este desenvolvimento passa por um projeto, codificação e teste, sendo que
cada uma destas fases não é executada formalmente. Usando assim os
protótipos, o cliente pode entender melhor os requisitos do sistema.
O protótipo é desenvolvido com uma versão inicial do documento de
especificação dos requisitos. Depois de pronto, o cliente verifica e o utiliza
indicando quando algo estiver faltando, e o que não é preciso.
Então o protótipo é modificado incorporando as sugestões de mudança e o
cliente usa o protótipo novamente repetindo o processo até que o mesmo seja
válido em termos de custo e tempo.
No final os requisitos iniciais são alterados para produzir a especificação
final dos requisitos. A sequência de eventos para o processo de prototipação é
ilustrada na figura 3. Como todas as abordagens ao desenvolvimento de software,
o de protótipos inicia-se com a obtenção dos requisitos.
Figura 3 - Processo de Prototipação (Pressman, 1995, p.36)
Para Pressman (1995 p.37), este modelo pode trazer alguns benefícios:
1. é um paradigma eficiente da engenharia de software;
39
2. a chave é definir as regras do jogo logo no começo, ou seja, o cliente e
o desenvolvedor devem concordar que o protótipo seja construído,
servindo com a finalidade de definir os requisitos;
3. a prototipação é um processo que capacita o desenvolvedor a criar um
software que será implementado
4. ele será depois descartado (pelo menos em parte) e o software real
será projetado, levando-se em conta a qualidade e a manutenibilidade.
5. a escolha de um processo deve considerar as características do
contexto de projeto ao qual será aplicado.
Considerando as diferenças entre os processos de software, McConnel
(1996, p. 154), apresenta diversas questões que devem ser respondidas ao
selecionar um:
1. Qual o nível de compreensão dos usuários e desenvolvedores em relação
aos requisitos no início do projeto?
2. É provável que a compreensão mude significativamente durante o
desenvolvimento do projeto?
3. Qual o nível de compreensão dos desenvolvedores em relação à
arquitetura do sistema?
4. É provável que mudanças na arquitetura do sistema ocorram no meio do
caminho?
5. Qual nível de confiança é necessário?
6. O quanto é necessário planejar e projetar durante o projeto prevendo
mudanças em versões futuras?
7. Qual o nível de riscos implícitos no projeto?
8. Pode ser limitado em um cronograma?
9. É necessário habilidade para realizar correções no meio do projeto?
40
10. É necessário mostrar ao cliente o progresso durante o projeto?
11. É necessário demonstrar ao usuário aspetos gerenciais durante o projeto?
Para auxiliar nas respostas a essas questões, McConnel (1996) apresenta
uma tabela na qual são apresentadas as vantagens e desvantagens, utilizando
uma escala para classificá-los que varia entre “deficiente”, “bom” e “excelente”,
em relação às questões apresentadas acima.
Capacidade do Processo Cascata Iterativo
Prototipação
Trabalha com a compreensão deficiente
dos requisitos Deficiente Excelente Excelente
Trabalha com a compreensão deficiente
da arquitetura Deficiente Excelente
Deficiente para
bom
Produz sistemas de alta confiança Excelente Excelente Bom
É fácil modificar o sistema em versões
futuras Excelente Excelente Excelente
Gerencia riscos Deficiente Excelente Bom
Pode ser limitado em um cronograma
predefinido Bom Deficiente Deficiente
Permite correções no meio do projeto Deficiente Bom Excelente
Possibilita ao cliente visibilidade do
progresso Deficiente Excelente Excelente
Possibilita ao cliente visibilidade do
progresso do gerenciamento Bom Excelente Bom
Requer pouca gerência ou experiência
para usá-lo Bom Bom Deficiente
Tabela 1 - Comparação dos Processos de Software (McCONNEL, 1996)
Identificamos nestas respostas se o monitoramento e controle está
atribuído aos processos de software, e constatamos que de certa forma ele é
aplicado, porém, em algumas respostas existem situações em que os processos
possuem algum item deficiente.
41
O processo de software unificado é um conjunto de atividades executadas
para transformar um conjunto de requisitos do cliente em um sistema de software.
Entretanto, o processo unificado também é uma estrutura genérica de
processo que pode ser customizado adicionando ou removendo atividades com
base nas necessidades específicas e nos recursos disponíveis para o projeto
(SCOTT, 2003, p.19).
O processo unificado da Rational (RUP) é um exemplo da versão
especializada do processo unificado que adiciona elementos à estrutura genérica.
O RUP foi desenvolvido por Ivar Jacobson, Grady Booch e James Rumbaugh,
com a intenção de ser um “conjunto de filosofias e práticas para o
desenvolvimento de software bem sucedido”.
Na prática, o RUP é um processo proprietário da empresa IBM2 bastante
conhecido e normalmente aplicado em médias e grandes organizações.
(Jacobson et al, 2007)
O RUP utiliza a abordagem iterativo e incremental sendo personalizável
de acordo com as necessidades específicas do desenvolvimento de software.
Baseado no paradigma de desenvolvimento orientado a objetos, com
especificação utilizando a notação UML - Unified Modeling Language (Linguagem
Unificada de Modelagem). O RUP implementa as práticas de engenharia de
software através de uma abordagem em duas dimensões conforme a figura 4.
A dimensão horizontal representa o tempo e divide o ciclo de vida de
desenvolvimento em quatro fases: Concepção, Elaboração, Construção e
Transição.
2 International Business Machines (IBM) é uma empresa dos Estados Unidos voltada para a área de informática. Um das poucas da área de Tecnologia da Informação (TI) com uma história contínua que remonta ao século XIX. A IBM fabrica e vende Hardware e Software, oferece serviços de infra-estrutura, serviços de hospedagem e serviços de consultoria nas áreas que vão desde computadores de grande porte até a nanotecnologia.
42
Figura 4 - Processo Unificado RUP (2007)
A dimensão vertical representa as disciplinas: Modelagem de Negócio,
Requisitos, Análise e Design, Implementação, Testes, Implantação,
Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e
Ambiente.
As disciplinas definem o que deve ser feito pelos responsáveis em termos
de atividades e artefatos3. Uma facilidade que o RUP apresenta é o fornecimento
de modelos (templates) para cada artefato e roteiros (guidelines) para o
cumprimento das atividades.
3 Artefatos são códigos executáveis, códigos fonte, especificação de interfaces, documentações, diagramas e planos que são produzidos ao longo das diferentes fases do processo de desenvolvimento de software (Oliveira e Elias, 2008).
43 2.4. Medidas e Métricas do Software
As medidas de um software são as atividades ligadas à mensuração para
coletar informações relativas ao desempenho do seu desenvolvimento.
Segundo Pressman, as razões para se medir um software estão
relacionadas com:
1) indicar a qualidade do produto;
2) avaliar a produtividade das pessoas que produzem o produto;
3) avaliar os benefícios (em termos de produtividade e qualidade)
derivados de novos métodos e ferramentas de software;
4) formar uma linha básica para estimativas.
Pressman (1995, p.61) traz uma divisão de medidas em duas categorias,
sendo medidas diretas e indiretas. Nas medidas diretas estão relacionadas os
valores relativos ao processo, ao custo, ao esforço de desenvolvimento e ao
número de linhas de código. Já nas medidas indiretas relacionamos com o
número de funcionalidades, indicadores de qualidade, de complexidade, de
eficiência, de confiabilidade e de manutenabilidade.
As medidas são coletas em diversas etapas do desenvolvimento do
software, isto favorece a construção de um conjunto de indicadores que poderão
ser utilizados conforme indica Pressman na qualidade do produto, na avaliação
da produtividade, na avaliação dos benefícios e no favorecimento da criação da
formação de uma linha básica para estimativas.
Martins (2007, p.25) relaciona alguns exemplos de indicadores que
“...incluem quantidade de erros descobertos antes da entrega do software;
defeitos entregues aos usuários finais; produtos de trabalho entregues; esforço
humano despendido e tempo gasto”.
44
Como pode ser visto as medidas definem o que precisamos verificar,
enquanto as métricas apuram o que foi medido. As métricas utilizadas no
desenvolvimento de um software podem estar atribuídas ao processo, ao projeto
e ao produto.
As métricas de projeto de software, por sua vez, permitem avaliar a
performance de um projeto, o estado do projeto, a situação dos riscos, as
tendências, o fluxo de trabalho e a capacidade da equipe.
A aplicação destas métricas de projeto ocorre durante a fase de
planejamento, quando vários elementos precisam ser estimados como: tempo,
esforço, riscos, dentre outros.
As métricas utilizadas para medir o produto de software, que envolvem as
medidas indiretas pode apresentar a qualidade do software desenvolvido, como
por exemplo, podemos saber quantidade de defeitos, falhas e erros identificados
na sua produção, assim como o retrabalho da equipe para as correções.
As métricas de software tornaram-se uma ferramenta fundamental para o
acompanhamento dos projetos, sendo considerada uma das atividades mais
importantes do processo de desenvolvimento de software.
São utilizadas para derivar uma base de estimativas, acompanhar o
progresso do projeto, determinar complexidade, ajudar a determinar quando o
estado aceitável de qualidade foi atingido.
Podemos considerar que a utilização das métricas de software no
monitoramento e controle tanto nos processos, projetos e produtos de software de
forma direta ou indireta nos ajuda a tomar decisões mais conscientes, pois,
poderemos interpretar estas informações fornecidas para a gestão de projetos.
45 3. O Monitoramento e Controle nos Processos de Desenvolvimento de
Software
Normalmente quando a data de entrega de um produto de software se
aproxima, cresce o interesse pelo status do andamento do projeto de software e a
pergunta mais comum é: como está o andamento do projeto?
Para responder a esta questão temos várias respostas possíveis como:
1) as atividades do projeto estão sendo concluídas;
2) os riscos do projeto estão sendo acompanhados;
3) não existe sublocação de recursos nas atividades;
4) o projeto está dentro do custo previstos x planejados;
Acompanhar o andamento de um projeto, de forma geral, não é uma tarefa
simples, pois, envolve a realização de um conjunto de atividades, dentre elas
estão: o processo de acompanhamento, a revisão e a regulação do progresso
para atender aos objetivos de desempenho definidos no plano de gerenciamento
do projeto (PMBOK, 2008 p. 314).
Segundo Rainner (2012 p. 341): “[...] A finalidade do monitoramento e
controle é determinar se o projeto está prosseguindo conforme planejado. Essa
fase consiste em três etapas”:
1) monitoramento das atividades contínuas do projeto (onde estamos);
2) comparação das variáveis do projeto (custo, esforço, tempo, recursos,
etc.) com o plano real (onde deveríamos estar);
3) identificação de ações corretivas (como voltamos ao caminho certo).
O monitoramento e controle de acordo com Martins (2007, p.102) é
monitorar e controlar o trabalho do projeto abordando os seguintes itens:
46
• comparação do desempenho real do projeto contra o previsto no plano
de gerenciamento e avaliar se é necessário deflagrar alguma ação
corretiva ou preventiva;
• acompanhamento e análise dos riscos do projeto para garantir que o
plano de resposta a riscos está sendo executado de forma adequada;
• fornecimento de informações para elaboração de relatórios de
desempenho e progresso;
• acompanhamento do custo e do cronograma;
• monitoramento da implementação de mudanças.
Os resultados destas atividades são recomendações e mudanças para
realizar o monitoramento e controle do projeto que são avaliadas, aprovadas ou
rejeitadas no processo para realizar controle integrado de mudanças, que
conforme Martins (2010, p.80) “tem o objetivo de gerenciar as alterações no
planejamento do projeto à medida que ocorrerem”.
Um dos principais elementos utilizados para deflagar estas alterações no
projeto é o relatório de desempenho, que é uma ferramenta de controle de tempo
e custo.
O monitoramento e controle consistem basicamente na identificação de
desvios que aparecem durante a execução. Este processo é executado durante
todo o ciclo de vida do projeto determinando segundo Martins (2007, p. 117):
• se os planos de ação para respostas as riscos, custos e tempo
foram implementados conforme planejados, e se as ações de
respostas são eficazes ou se precisam ser replanejadas;
• se a exposição do projeto aos riscos, custos e tempo aumentou ou
diminuiu ou se apareceram novos que não haviam sido identificados
inicialmente.
47
• se os responsáveis pela gestão de projetos relatam periodicamente
aos gerentes de projetos a eficácia dos planos, além da ocorrência
de eventos inesperados que requerem alguma ação não planejada.
Nos próximos itens deste capítulo, iremos abordar como o monitoramento
e controle é utilizado nos processos de desenvolvimento de software,
identificando as atividades e etapas que são atribuídas.
3.1 Monitoramento e Controle na Análise Estruturada
Identificamos que na análise estruturada a sua concepção está baseada no
processo de software cascata, que por sua vez estabelece fases bem definidas
tornando o monitoramento e controle como um conjunto de atividades aplicáveis.
Pode ocorrer uma sobreposição conceitual de monitoramento e controle
com o término de cada fase do processo de software cascata, haja vista que os
marcos podem ser concomitantemente realizados.
Portanto, no monitoramento e controle utilizando o processo de software
cascata teremos que definir atividades para realizar este acompanhamento,
quanto aos resultados esperados ao término de cada fase.
3.2 Monitoramento e Controle no RUP
Na disciplina de gerenciamento de projetos do RUP (JACOBSON et al,
2007), encontramos uma tarefa “definir monitoramento e processos de controle”,
que tem o objetivo de definir as informações e os processos que serão utilizados
para monitorar e controlar o progresso, a qualidade e os riscos do projeto nas
seguintes etapas:
48
• Definir indicadores do projeto: são informações de projeto que dão
uma idéia do funcionamento e do progresso do projeto em relação ao
plano de desenvolvimento de software.
Em geral um gerente de projeto está interessado nos indicadores que
se aplicam ao escopo do trabalho, ao orçamento, à qualidade e aos
riscos do projeto. A medida que um projeto avança, o coordenador do
projeto monitora esses indicadores e estimula ações corretivas quando
ultrapassam as condições predefinidas.
Esses indicadores de projeto podem incluir:
o despesas totais versus orçamento;
o escopo revisado (trabalho realizado mais estimativas de
conclusão) versus escopo planejado;
o densidade de defeitos versus objetivos da qualidade;
o indicadores de riscos (situações que apontam a presença de um
risco)
A definição desses indicadores é estabelecida de acordo com o custo,
qualidade e o planejamento do projeto.
• Definir origens para indicadores do projeto: em geral os indicadores
do projeto são medidas do projeto consolidadas, calculadas a partir de
métricas primitivas mais granulares, que são relatadas regularmente
pela equipe do projeto.
A forma como essas métricas primitivas devem ser capturadas e o
processo para usá-las, a fim de calcular os indicadores do projeto, são
definidos no plano de métricas do projeto.
Outros indicadores (especialmente os indicadores de risco) podem ser
apenas o status da ocorrência ou não de uma situação específica.
49
Nesses casos, basta identificar a origem das informações no status do
indicador.
• Definir o procedimento e elaboração dos relatórios de status da
equipe e do projeto: após a definição das métricas primitivas e dos
indicadores do projeto, deverá definir o procedimento que os membros
da equipe de projeto devem adotar para relatar o status e a frequência
com que vão elaborar os relatórios.
Esse procedimento descreve o processo para registrar o tempo com
base em atividades, elaborando relatórios sobre a conclusão de tarefas,
para atingir os marcos do projeto e relatando problemas.
Para garantir um fluxo de informações consistente, convém definir
gabaritos padrão para quadros de horários e relatórios de status de
membros da equipe.
• Definir limites de procedimentos para ação corretiva: para manter o
controle eficaz do projeto, o coordenador de projeto define
valores/condições-limite para cada indicador definido no projeto. Essas
condições de limite são registradas no controle e monitoração do plano
de desenvolvimento de software.
Quando os limites forem ultrapassados, o coordenador de projetos
deverá realizar uma ação corretiva para retormar o controle do projeto.
Dependendo da gravidade da condição, ele poderá resolver o problema
com sua própria autoridade (emitindo as ordens de trabalho
apropriadas).
Se o problema estiver além da sua autoridade, ele precisará emitir um
controle de mudanças e ativar o processo de controle de mudanças do
projeto.
50
• Definir o procedimento para elaboração de relatórios de status do
projeto: esse procedimento descreve quando e onde as revisões
programas e não-programadas deverão ocorrer e quais informações
serão incluídas na avaliação do status.
O coordenador de projeto usará a lista de problemas para registrar e
controlar problemas continuamente (que não sejam abordados por
algum outro instrumento de controle de gerenciamento, como controle
de mudanças ou lista de riscos), nos períodos entre a realização de
avaliações de status.
Uma outra tarefa referente ao gerenciamento de projetos segundo o (RUP,
2007) é “monitorar status do projeto” que captura o trabalho diário e contínuo,
incluindo monitoramento de status do projeto, relatório para envolvidos lidando
com as situações atuais e os problemas detectados nas seguintes etapas:
• Capturar o status do trabalho: coleta as informações do projeto e a
qualidade sobre o projeto para avaliar o status atual. O gerente de
projeto captura as métricas primitivas sobre o andamento do projeto e a
qualidade do produto.
Os métodos a serem usados para capturar essas métricas são
descritos no plano de métricas do projeto. Geralmente, os membros da
equipe de projeto enviam relatórios de andamento periódicos ao
gerente do projeto, fornecendo as informações de:
o esforço registrado com base nas atividades;
o esforço estimado para concluir cada atividade pela qual eles são
responsáveis;
o tarefas concluídas;
o produtos liberados publicados;
51
o os problemas que requerem atenção do gerenciamento para
atenção e controle adicionais.
• Derivar indicadores de progresso: para avaliar corretamente o
progresso do projeto em relação aos planos, o gerente de projetos
reúne as métricas primitivas reportadas pela equipe do projeto para
fornecer um panorama geral do progresso do projeto.
O plano de medida do projeto descreve como essas métricas derivadas
(os “indicadores de progresso”) são calculadas.
• Derivar indicadores de qualidade: além de monitorar o progresso do
trabalho, o gerente de projetos também monitora a qualidade dos
produtos de trabalho do projeto.
As métricas de qualidade (conforme definidas no plano de métricas do
projeto) são consolidadas para fornecer um panorama geral do status
do projeto com base nos objetos de qualidade especificados.
• Avaliar indicadores versus planos: após derivar os indicadores de
andamento do projeto e de qualidade do projeto, o gerente de projetos
os compara com o estado esperado do projeto, conforme definido pelo
plano de desenvolvimento de software e os planos de iteração. Neste
ponto, o gerente de projetos avaliará o seguinte:
o todas as tarefas planejadas foram concluídas?
o todos os produtos de trabalho foram publicados conforme
planejado?
o o esforço estimado para concluir tarefas “em andamento” está de
acordo com o plano?
o as métricas de qualidade (por exemplo, contagens de defeitos
não corrigidos) estão dentro das tolerâncias planejadas?
52
O gerente de projeto também revisará os indicadores de risco
identificados para cada item da lista de riscos, a fim de decidir se
quaisquer estratégias de diminuição de riscos devem ser ativadas neste
momento.
No RUP na disciplina de gerenciamento de projeto conforme a figura 5
abaixo, o monitorar e controlar o projeto permeia todas as tarefas essenciais até a
finalização do projeto.
Figura 5: Monitoramento e Controle no RUP (RUP, 2007)
53
No RUP com a utilização destas etapas e atividades podemos aplicar o
monitoramento e controle para que o projeto tenha os resultados esperados e
definidos na sua concepção até a transição, buscando abordar todas as suas
disciplinas e aplicando indicadores que possam ajudar a gestão de projetos de
software por meio de ações corretivas e preventivas.
Portanto, pode se observar que ao utilizar o RUP, o processo de
monitoramento e controle encontra-se adequado ao processo de desenvolvimento
de software.
3.3 Monitoramento e Controle no PMBOK
O monitoramento e controle de projetos segundo o PMBOK (2008 p. 58)
têm o benefício de observar e mensurar o desempenho do projeto de forma
periódica e uniforme para identificar variações em relação ao plano de
gerenciamento do projeto definido que inclui:
• controlar as mudanças e recomendar ações preventivas em
antecipação a possíveis problemas;
• monitorar as atividades do projeto em relação ao plano de
gerenciamento e a linha de base de desempenho do mesmo;
• influenciar os fatores que poderiam impedir o controle integrado de
mudanças, para que somente as mudanças aprovadas sejam
implementadas.
Este monitoramento contínuo oferece à equipe do projeto uma visão
melhor sobre a saúde do mesmo e identifica quaisquer áreas que requeiram
atenção adicional. Não apenas monitora e controla o trabalho que está sendo
feito durante um grupo de processos, mas também monitora e controla o projeto
inteiro (PMBOK, 2008 p.58).
54
Conforme pode ser visualizado na figura 6 o monitoramento e controle
incluem os seguintes processos (PMBOK, 2008 p.59):
Figura 6: Monitoramento e Controle no PMBOK (PMI, 2008)
• Monitorar e controlar o trabalho no projeto: processo de acompanhamento,
avaliação e regulação do progresso para atender aos objetivos de
desempenho definidos no plano de gerenciamento do projeto.
O monitoramento inclui relatórios de status, medições do progresso e
previsões. Os relatórios de desempenho fornecem informações sobre o
desempenho do projeto com relação ao escopo, cronograma, custo, recursos,
qualidade e risco, que podem ser usadas como entradas para outros
processos.
55
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o relatórios de desempenho;
o fatores ambientais da empresa e ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento do projeto;
o atualizações dos documentos do projeto.
• Realizar o controle integrado de mudanças: processo de avaliação de
todas as solicitações de mudanças, aprovação de mudanças e gerenciamento
das mesmas em entregas, ativos de processos organizacionais, documentos e
plano de gerenciamento do projeto.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o informações sobre o desempenho do trabalho;
o solicitações de mudança, fatores ambientais da empresa;
o ativos de processos organizacionais;
o atualização do andamento das solicitações de mudança;
o atualizações do plano de gerenciamento do projeto;
o atualizações dos documentos do projeto.
• Verificar o escopo: processo de formalização da aceitação das entregas
terminadas no projeto.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o documentação dos requisitos;
o matriz de rastreabilidade dos requisitos;
o entregas validadas;
56
o entregas aceitas;
o solicitações de mudança;
o atualizações dos documentos do projeto.
• Controlar o escopo: processo de monitoramento do andamento do escopo
do projeto e do produto e gerenciamento das mudanças feitas na linha de
base do escopo.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o informações sobre o desempenho do trabalho;
o documentação dos requisitos;
o matriz de rastreabilidade dos requisitos;
o ativos dos processos organizacionais;
o medições de desempenho do trabalho;
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento de projeto;
o atualizações dos documentos do projeto.
• Controlar o cronograma: processo de monitoramento do andamento do
projeto para atualização do seu progresso e gerenciamento de mudanças
feitas na linha de base do cronograma. Neste processo os artefatos que
podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o cronograma do projeto;
o informações sobre o desempenho do trabalho;
o ativos de processos organizacionais;
o medições de desempenho do trabalho;
57
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento de projeto;
o atualizações dos documentos do projeto.
• Controlar os custos: processo de monitoramento do andamento do projeto
para a atualização do seu orçamento e gerenciamento de mudanças feitas na
linha de base dos custos.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o requisitos de recursos financeiros do projeto;
o informações sobre o desempenho do trabalho;
o ativos de processos organizacionais;
o medições de desempenho do trabalho;
o previsões do orçamento;
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento de projeto;
o atualizações dos documentos do projeto.
• Realizar o controle da qualidade: processo de monitoramento e registro dos
resultados da execução das atividades de qualidade para avaliar o
desempenho e recomendar as mudanças necessárias.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o métricas de qualidade;
o listas de verificação da qualidade;
o medições de desempenho do trabalho;
58
o solicitações de mudança aprovadas;
o entregas;
o ativos dos processos organizacionais;
o medições do controle da qualidade;
o alterações validadas;
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento do projeto;
o atualizações dos documentos do projeto.
• Reportar o desempenho: processo de coleta e distribuição de informações
sobre o desempenho, inclusive relatórios de andamento, medições do
progresso e previsões.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
o plano de gerenciamento do projeto;
o informações sobre o desempenho do trabalho;
o medições de desempenho do trabalho;
o previsões do orçamento;
o ativos dos processos organizacionais;
o relatórios de desempenho;
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança.
• Monitorar e controlar os riscos: processo de implementação de planos de
respostas aos riscos, acompanhamento dos riscos identificados,
monitoramento dos riscos residuais, identificação de novos riscos e avaliação
do processo de risco durante todo o projeto.
Neste processo os artefatos que podem ser gerados e/ou atualizados são:
59
o registro dos riscos;
o plano de gerenciamento do projeto;
o informações sobre o desempenho do trabalho;
o relatórios de desempenho;
o atualizações do registro dos riscos;
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento do projeto;
o atualizações dos documentos do projeto.
• Administrar as requisições: é o processo de gerenciamento das aquisições
e monitoramento dos desempenhos dos contratos, fazendo mudanças e
correções conforme necessário. Neste processo os artefatos que podem ser
gerados e/ou atualizados são:
o documentos de aquisição;
o plano de gerenciamento de projeto;
o contrato;
o relatório de desempenho;
o solicitações de mudança aprovadas;
o informações sobre o desempenho do trabalho;
o documentos de aquisição;
o atualizações dos ativos de processos organizacionais;
o solicitações de mudança;
o atualizações do plano de gerenciamento do projeto.
A utilização do PMBOK no monitoramento e controle nos processos de
software explicita uma documentação em todas as áreas, tornando esta atividade
aderente ao que deseja a gestão de projetos de software.
60
3.4 Monitoramento e Controle na MGCP
A MGCP é uma metodologia de gerenciamento de projetos criada pela
área responsável pela gestão de projetos de software da empresa objeto do
estudo de caso desta dissertação.
O objetivo desta metodologia é auxiliar o processo de gerenciamento de
projetos, de modo a garantir que os projetos estejam alinhados e sejam
conduzidos de forma organizada e padronizada, estabelecendo procedimentos a
serem cumpridos para os projetos em todas as fases de seu desenvolvimento
como: (iniciação, planejamento, execução, monitoramento e controle e
encerramento).
Além das fases, ela busca garantir conformidade do processo de
gerenciamento de projetos para o processo de desenvolvimento de software,
trazendo consequentemente controle sobre o andamento dos projetos,
principalmente para o monitoramento e controle de projetos.
A MCGP utiliza o PMBOK (2004) como o principal referencial teórico para o
seu desenvolvimento. Entretanto, para compor esta metodologia foram extraídas
outras metodologias como: RGB4 – Rummler Brache Group, BSC5 – Balanced
Scored Card e QFD6 – Quality Function Deployment.
A figura 12 ilustra a ordem em que às fases do gerenciamento de projetos
se interagem segundo a MGCP.
4 A RBG foi criada no início da década de 90 pelos consultores Alan P. Brache e Geary A. Rummler com objetivo de melhorar radicalmente o desempenho da organização. Sua abordagem fundamenta-se em identificar e redefinir os processos interfuncionais críticos que têm impacto sobre o desempenho da organização (BRACHE et RUMMLER, 1995). 5 O BSC é um método que auxilia os gestores a desenvolver bem uma estratégia do princípio ao fim e depois fazer com que cada um na organização esteja envolvido a implementá-la (Kaplan e Norton, 2001). 6 O QFD (Desdobramento da Função Qualidade) é uma das ferramentas da qualidade que foi criada na década de 60 pelo japonês Yoji Akao e que tem como objetivo principal permitir que a equipe de desenvolvimento do produto incorpore as reais necessidades do cliente em seus projetos de melhoria.
61
Cada fase do projeto é marcada pela conclusão de um ou mais produtos
da fase (entregáveis ou saídas da fase), entendendo-se como produto o resultado
do trabalho da equipe de projeto, tangível e verificável.
Figura 7 – Monitoramento e Controle na MGCP
Fonte: Empresa financeira
Esse resultado é baseado em um conjunto de modelos de artefatos que
permitem uma revisão e avaliação do desempenho do projeto, de maneira que se
possa indicar sua continuidade ou identificar a necessidade de correção de
desvios, evitando a elevação dos custos/prazos com correções em fases mais
avançadas.
O objetivo do monitoramento e controle na MGCP é do aprimoramento no
gerenciamento do projeto, da medição e monitoramento do progresso do projeto
para identificar variações em relação ao plano de gerenciamento do projeto.
A MCGP no monitoramento e controle aborda em conjunto as fases de:
Levantamento; Detalhamento Execução; Fechamento. Para garantir as
avaliações e acompanhamento do projeto e permitir o fechamento do projeto em
tempo oportuno. A figura 8 ilustra a composição entre fases e processos.
Projeto Priorizado
Registros do
Projeto
Entregas do
Projeto
Usuários Finais
Ativos de
Processos
Limites do Projeto
Entradas do
Projeto
Pré-Projeto
Iniciação
Processo de Monitoração e Controle
Processo de Planejamento
Processo de Execução
Fechamento Gestor do
Projeto
62
Figura 8 - Fases e Processos da MCGP
Fonte: Empresa Financeira
Fase de Pré-Projeto
Processos de Seleção e Priorização
1. Elaborar proposta de projeto2. Aplicar critério de priorização3. Obter aprovação do projeto4. Obter designação de Coordenador de projeto5. Obter designação da equipe para a Fase de
Levantamento
Fase de Levantamento
Processos de Iniciação
1. Elaborar Termo de Abertura do Projeto2. Elaborar o Quadro Lógico3. Elaborar a EAP Preliminar4. Realizar análise de riscos5. Elaborar Plano de Projeto6. Relatar o desempenho da fase7. Obter aprovação da fase8. Obter designação da equipe para a Fase de
Detalhamento
Fase de Detalhamento
Processos de Planejamento
1. Revisar Quadro Lógico2. Detalhar Escopo do Projeto3. Detalhar EAP4. Elaborar Dicionário completo da EAP5. Elaborar lista de atividades6. Seqüenciar atividades7. Estimar duração das atividades8. Fazer detalhamento do tempo9. Estimar recursos10. Elaborar Plano de Alocação de RH11. Elaborar Organagrama do projeto12. Elaborar Plano de Gerenciamento de Tempo13. Elaborar Plano de Gerenciamento de Mudança de
Escopo14. Atualizar análise dos Riscos15. Elaborar Plano de Gerenciamento de Risco16. Elaborar Plano de Gerenciamento da Comunicação17. Elaborar Plano de Gerenciamento de Aquisição18. Elaborar Plano de Gerenciamento de Qualidade19. Elaborar o Orçamento20. Atualizar Plano de Projeto21. Fazer o gerenciamento da mudança de escopo22. Relatar o desempenho da fase23. Obter aprovação da fase24. Obter designação da equipe para a Fase de
Execução
Fase de Execução
Processos de Execução
1. Executar o Plano de Projeto2. Distribuir as informações3. Desenvolver a equipe de projeto4. Utilizar Sala de Projeto5. Relatar desempenho do projeto6. Obter aprovação da fase7. Obter designção da equipe para a Fase de
Fechamento
Processos de Controle e Monitoramento
1. Monitorar ocorrência de riscos2. Desenvolver a equipe3. Controlar aquisições4. Distribuir informações5. Registrar mudanças6. Monitorar mudanças de escopo e de tempo7. Relatar desempenho do projeto8. Elaborar Relatório de Atividades do Projeto9. Monitorar Diagrama de Marcos10. Relatar Lições Aprendidas
Fase de Fechamento
Processos de Encerramento
1. Avaliar resultados2. Relatar Lições Aprendidas3. Reunir documentos do projeto4. Arquivar documentos do projeto5. Obter aprovação da fase6. Liberar equipe do projeto7. Relatar o desempenho da fase
Fase de Pré-Projeto
Processos de Seleção e Priorização
1. Elaborar proposta de projeto2. Aplicar critério de priorização3. Obter aprovação do projeto4. Obter designação de Coordenador de projeto5. Obter designação da equipe para a Fase de
Levantamento
Fase de Pré-Projeto
Processos de Seleção e Priorização
1. Elaborar proposta de projeto2. Aplicar critério de priorização3. Obter aprovação do projeto4. Obter designação de Coordenador de projeto5. Obter designação da equipe para a Fase de
Levantamento
Fase de Levantamento
Processos de Iniciação
1. Elaborar Termo de Abertura do Projeto2. Elaborar o Quadro Lógico3. Elaborar a EAP Preliminar4. Realizar análise de riscos5. Elaborar Plano de Projeto6. Relatar o desempenho da fase7. Obter aprovação da fase8. Obter designação da equipe para a Fase de
Detalhamento
Fase de Levantamento
Processos de Iniciação
1. Elaborar Termo de Abertura do Projeto2. Elaborar o Quadro Lógico3. Elaborar a EAP Preliminar4. Realizar análise de riscos5. Elaborar Plano de Projeto6. Relatar o desempenho da fase7. Obter aprovação da fase8. Obter designação da equipe para a Fase de
Detalhamento
Fase de Detalhamento
Processos de Planejamento
1. Revisar Quadro Lógico2. Detalhar Escopo do Projeto3. Detalhar EAP4. Elaborar Dicionário completo da EAP5. Elaborar lista de atividades6. Seqüenciar atividades7. Estimar duração das atividades8. Fazer detalhamento do tempo9. Estimar recursos10. Elaborar Plano de Alocação de RH11. Elaborar Organagrama do projeto12. Elaborar Plano de Gerenciamento de Tempo13. Elaborar Plano de Gerenciamento de Mudança de
Escopo14. Atualizar análise dos Riscos15. Elaborar Plano de Gerenciamento de Risco16. Elaborar Plano de Gerenciamento da Comunicação17. Elaborar Plano de Gerenciamento de Aquisição18. Elaborar Plano de Gerenciamento de Qualidade19. Elaborar o Orçamento20. Atualizar Plano de Projeto21. Fazer o gerenciamento da mudança de escopo22. Relatar o desempenho da fase23. Obter aprovação da fase24. Obter designação da equipe para a Fase de
Execução
Fase de Detalhamento
Processos de Planejamento
1. Revisar Quadro Lógico2. Detalhar Escopo do Projeto3. Detalhar EAP4. Elaborar Dicionário completo da EAP5. Elaborar lista de atividades6. Seqüenciar atividades7. Estimar duração das atividades8. Fazer detalhamento do tempo9. Estimar recursos10. Elaborar Plano de Alocação de RH11. Elaborar Organagrama do projeto12. Elaborar Plano de Gerenciamento de Tempo13. Elaborar Plano de Gerenciamento de Mudança de
Escopo14. Atualizar análise dos Riscos15. Elaborar Plano de Gerenciamento de Risco16. Elaborar Plano de Gerenciamento da Comunicação17. Elaborar Plano de Gerenciamento de Aquisição18. Elaborar Plano de Gerenciamento de Qualidade19. Elaborar o Orçamento20. Atualizar Plano de Projeto21. Fazer o gerenciamento da mudança de escopo22. Relatar o desempenho da fase23. Obter aprovação da fase24. Obter designação da equipe para a Fase de
Execução
Fase de Execução
Processos de Execução
1. Executar o Plano de Projeto2. Distribuir as informações3. Desenvolver a equipe de projeto4. Utilizar Sala de Projeto5. Relatar desempenho do projeto6. Obter aprovação da fase7. Obter designção da equipe para a Fase de
Fechamento
Fase de Execução
Processos de Execução
1. Executar o Plano de Projeto2. Distribuir as informações3. Desenvolver a equipe de projeto4. Utilizar Sala de Projeto5. Relatar desempenho do projeto6. Obter aprovação da fase7. Obter designção da equipe para a Fase de
Fechamento
Processos de Controle e Monitoramento
1. Monitorar ocorrência de riscos2. Desenvolver a equipe3. Controlar aquisições4. Distribuir informações5. Registrar mudanças6. Monitorar mudanças de escopo e de tempo7. Relatar desempenho do projeto8. Elaborar Relatório de Atividades do Projeto9. Monitorar Diagrama de Marcos10. Relatar Lições Aprendidas
Processos de Controle e Monitoramento
1. Monitorar ocorrência de riscos2. Desenvolver a equipe3. Controlar aquisições4. Distribuir informações5. Registrar mudanças6. Monitorar mudanças de escopo e de tempo7. Relatar desempenho do projeto8. Elaborar Relatório de Atividades do Projeto9. Monitorar Diagrama de Marcos10. Relatar Lições Aprendidas
Fase de Fechamento
Processos de Encerramento
1. Avaliar resultados2. Relatar Lições Aprendidas3. Reunir documentos do projeto4. Arquivar documentos do projeto5. Obter aprovação da fase6. Liberar equipe do projeto7. Relatar o desempenho da fase
Fase de Fechamento
Processos de Encerramento
1. Avaliar resultados2. Relatar Lições Aprendidas3. Reunir documentos do projeto4. Arquivar documentos do projeto5. Obter aprovação da fase6. Liberar equipe do projeto7. Relatar o desempenho da fase
63
A MCGP não se propõe a substituir o PMBOK (2008), porém, apresenta
insumos necessários ao gerenciamento de projeto quanto ao monitoramento e
controle dos projetos.
Além disso, ela fornece uma sequência para os seus processos, apoiando
o processo de desenvolvimento de software em relação às atividades de:
• monitorar a ocorrência dos riscos;
• desenvolver a equipe;
• controlar aquisições;
• distribuir informações;
• registrar mudanças;
• monitorar mudanças de escopo e tempo;
• relatar desempenho do projeto;
• elaborar relatório de atividades do projeto;
• monitorar diagrama de marcos;
• relatar lições aprendidas.
Estas atividades preconizam o que já foi dito anteriormente pelos autores
Rainner (2012) e Martins (2010) em relação ao monitoramento e controle dos
projetos, sendo uma maneira que a empresa objeto de estudo de caso encontra
para fazer este acompanhamento no processo de desenvolvimento de software.
Esta metodologia tem sido aplicada independentemente do processo de
software que foi escolhido pela equipe, pois, ela pode se vincular e tornar-se uma
ferramenta adequada para as empresas que desenvolvem software, sendo
também iniciativa que poderia ser adotada para realizar o monitoramento e
controle, atendendo ao que preconiza a gestão de projetos de software.
64
3.5 Ferramentas para o Monitoramento e Controle
Os softwares para o gerenciamento de projetos são ferramentas que
auxiliam principalmente o gerente do projeto. São usados com diversos fins como:
planejar, monitorar, controlar, relatar e comunicar a situação dos projetos.
Existem softwares com diferentes custos, funcionalidades e usabilidades.
Kerzner (2001, p.706) define uma lista das principais funções oferecidas por eles,
onde os recursos mais comuns fornecidos são para o planejamento,
monitoramento e controle das tarefas, recursos e custos do projeto.
Dessa forma, é fácil visualizar as tarefas e suas características como seu
tempo de início e fim, seus recursos alocados e seus custos. Também é possível
acompanhar a situação do projeto e compará-lo com o que foi planejado
inicialmente.
Os usuários podem modificar ou criar relatórios padronizados. Esses
relatórios incluem uma série de diagramas (Gantt, Rede), sumários tabulares e
gráficos de negócio. Kerzner (2001, p.707) cita alguns exemplos de relatórios:
• relatório do custo orçado do trabalho planejado;
• relatório do custo do trabalho realizado;
• relatório dos gastos reais versus planejados;
• análise do valor agregado entre outros.
Um software de monitoramento e controle segundo (Gray et. al 2009,
p.419) “implica determinar quais dados coletar, como, quando e quem irá coletá-
los, analisa-los e relatar o progresso alcançado”. Gray et al (2009 p.420) aborda
algumas questões pertinentes à estrutura do software para o monitoramento e
controle:
65 a) Quais dados são coletados. Dados coletados são determinados por qual
sistema de medição será usado para o controle do projeto.
Uma vez que o sistema foca questões de custo/cronograma é crucial prover o
gerente de projetos e as partes interessadas que respondam perguntas como:
• Qual é o estado atual do projeto em relação a programa e custo?
• Quanto custará completar o projeto?
• Quando o projeto será concluído?
• Existem problemas potenciais que precisam ser relatados agora?
• Em quê, em quem e onde estão as causas para o excedente de
custo ou prazo?
• O que obtivemos em troca do dinheiro gasto?
• Se houver um custo excedente em um projeto em andamento, será
que podemos prever esse excesso no momento da sua conclusão?
As medições do desempenho que se precisa coletar deveriam ajudar a
responder a estas perguntas.
b) Coletar dados e fazer análise. Com a determinação de quais dados são
coletados, o próximo passo é estabelecer por quem, quando e como os dados
serão agregados.
Eles serão coletados pela equipe de projeto, pelo contratado, por terceiros
especializados, pelo gerente de projetos? Ou os dados serão derivados
eletronicamente de algum tipo de dados substitutos, como fluxo de caixa, horas
de máquina, horas de mão-de-obra ou materiais utilizados? O período relatado
deveria ser uma hora, um dia, uma semana ou qual? Há um repositório central
para os dados coletados e há alguém responsável por sua divulgação?
66
c) Relatórios e o modo de reportar. Quem recebe os relatórios de
desempenho? As partes interessadas e gerentes necessitam de diferentes tipos
de informação relacionadas ao projeto.
O interesse principal da direção superior é: “Estamos no prazo e dentro do
orçamento? Se não, que ação corretiva está sendo providenciada?”.
Do mesmo modo, um gerente que trabalhe no projeto se preocupa principalmente
com as entregas de seus pacotes de trabalho específicos. Os relatórios deveriam
ser voltados para o público certo.
Especificamente, os relatórios de progresso do projeto são planejados e
comunicados de forma escrita ou verbal e tem um formato comum em tópicos,
para relatórios de progresso:
• Progresso depois do último relatório
• Status atual do projeto
1. Programa
2. Custo
3. Escopo
• Tendências previstas
• Problemas e assuntos depois do último relatório
1. Ações e resoluções relacionadas a problemas anteriores
2. Novas variações e problemas identificados
• Ação corretiva planejada
Segundo Gray et. al (2009. p.421) “...deve comparar no relatório de
progresso o desempenho real com o que foi planejado para identificar
divergências, avaliar possíveis alternativas de ações e aplicar a ação corretiva
apropriada”. Ele define os passos do controle de projeto, para medir e avaliar seu
desempenho conforme abaixo:
67
1. estabelecer um plano de linha de base;
2. medir o progresso e o desempenho;
3. comparar o planejado com o status atual;
4. entrar em ação.
A importância dos softwares no monitoramento e controle de projetos
fornecem insumos essenciais para o processo de desenvolvimento de software
quanto aos projetos de software que são desenvolvidos, e, portanto, as
informações que são coletadas, analisadas e disponibilizadas ajudam a tomada
de decisão quanto ao que precisa ser apurado durante as etapas e atividades
previstas e concluídas em um projeto.
Conforme abordamos em relação aos problemas de monitoramento e
controle nos processos de desenvolvimento de software, as ferramentas deveriam
oferecer mais opções que foram relatadas para dar um suporte adequado às
necessidades da gestão de projetos de software, a fim de que possa abordar
todas as questões que foram levantadas quanto ao que deve contemplar uma
ferramenta para o monitoramento e controle.
A seguir iremos detalhar algumas ferramentas que foram elencadas no
problema do monitoramento e controle quanto ao processo de desenvolvimento
de software, apesar de existirem outras disponíveis no mercado, porém, estas
que apresentaremos são as mais utilizadas na empresa objeto do estudo de caso.
3.5.1 Ms Project
Segundo Pimentel (2008) o MS Project é um software de gestão de
projetos, sendo uma ferramenta muito exigida no mercado e bastante utilizada
nos mais variados segmentos de projetos e aplicações. Sua primeira versão foi
68
lançada em 1985. Desde então, além de contar com interface gráfica e amigável
aparência, vem passando por melhorias e dispondo de novos recursos, estando
disponível nas versões Standard, Professional, Server e Web Access.
As principais funções do MS Project como software para a gestão de
projetos são:
• criar, editar e controlar um projeto;
• personalização para diferentes metodologias e produtividade;
• criar gráficos, relatórios e diagramas profissionais;
• permitir tarefas recorrentes;
• maior controle de informações, finanças e prazos;
• acesso rápido às informações desejadas.
Algumas destas funcionalidades atendem ao monitoramento e controle nos
processos de desenvolvimento software, porém, se não houver outras
ferramentas que possam integrá-la, pela sua limitação não consegue atender a
algumas questões apresentadas quanto a uma ferramenta para o monitoramento
e controle, tornando-se inviável se for utilizada separadamente das demais.
3.5.2 DotProject
É uma ferramenta open source de gestão de projeto que pode ser utilizada
em todos os seus projetos, compartilhada com a equipe e clientes. Apresenta um
conjunto de funcionalidades para atender às necessidades dos projetos, sendo
uma aplicação web, escrita em PHP e com banco de dados MySQL, que busca
unificar as informações importantes do projeto, apresentando uma visão geral das
tarefas e responsáveis.
69
De acordo com Jordan (2007, p.12) o dotProject é uma boa escolha para
organizações que precisam de um software para o gerenciamento de projetos que
“não tenha taxas, tenha uma generosa licença de uso, seja estável, funcione nos
grandes browsers, tenha uma comunidade que preste suporte, tenha permissões
granulares, e seja escalável”.
Pode ser aplicado em diversos ambientes como escritórios, gerenciamento
pessoal, empresas e escolas. As principais características são:
• informações das empresas e os seus projetos;
• tarefas necessárias para a execução de cada projeto;
• monitoramento do andamento das tarefas;
• diagrama de gantt para ilustrar o avanço das etapas do projeto;
• informações sobre usuários e colaboradores de cada tarefa;
• lista de contatos;
• lembrete sobre prazos e calendários;
• fóruns sobre os projetos;
• repositório de arquivos relacionados a projetos.
Este software se enquadra no que é chamado de arquitetura “LAMP” -
Linux, Apache, MySQL e PHP. Tal arquitetura é indicada como preferencial,
podendo ser utilizadas alternativas para serem feitas implementações, ou seja,
apesar da sua limitação principalmente quanto aos processos de
desenvolvimento de software, podem ser realizadas alterações para atender a
adaptação destas fases e/ou atividades.
Por ser uma ferramenta conhecida como software livre, tem a vantagem de
não ter nenhum custo para a sua utilização, porém, em caso de utilização na
quantidade maior de projetos existe a limitação de desempenho, e até mesmo de
recursos que estão disponíveis em outros softwares proprietários e pagos, mas
70
ainda assim se torna atrativa para realizar o monitoramento e controle nos
processos de desenvolvimento pelos fatores que foram abordados.
3.5.3 RTC
O Rational Team Concert (RTC) é uma ferramenta da empresa IBM7 para
gestão do ciclo de vida de aplicações (ALM - Application Lifecycle Management).
Desenvolvida utilizando como base a plataforma Jazz (IBM, 2013). O jazz é um
projeto e plataforma de código aberto para transformar como as pessoas
trabalham juntas visando entregar maior valor e desempenho em seus projetos de
software.
Disponibiliza serviços que dão suporte a colaboração, tais como: painéis
de informação, Registro de projetos e equipes; busca; segurança; notificações de
eventos e integração com IDE’s Eclipse, Visual Studio e Web (IBM, 2011).
O RTC foi a primeira ferramenta desenvolvida utilizando a estrutura de
plataforma Jazz, implementando a disciplina de Gerência de Configuração,
possibilitando o desenvolvimento distribuído e controle de versão dos artefatos do
projeto bem como as atividades dos envolvidos.
As principais funcionalidades são:
• criação, acompanhamento, planejamento, administração de itens de
trabalho;
• painel de controle, versionamento de artefatos, gestão de baselines,
definição, execução e registro de builds realizados;
7 International Business Machines (IBM) é uma empresa dos Estados Unidos voltada para a área de informática. Um das poucas da área de Tecnologia da Informação (TI) com uma história contínua que remonta ao século XIX. A IBM fabrica e vende Hardware e Software, oferece serviços de infra-estrutura, serviços de hospedagem e serviços de consultoria nas áreas que vão desde computadores de grande porte até a nanotecnologia.
71
• gestão de projetos, colaboração entre os membros da equipe de
projetos e a publicação dos projetos.
Estas funcionalidades ajudam a coletar as informações necessárias,
podendo realizar diariamente o monitoramento e controle dos projetos com as
equipes, através de relatórios, consultas e painéis (dashboard), mostrando o
desempenho de cada projeto ou de todos os colaboradores no processo de
desenvolvimento de software.
Podemos citar algumas características que são atendidas pelo RTC:
• modelos e fluxos prontos de processos para começar a trabalhar a
partir da instalação, inclusive para o desenvolvimento de software;
• colaboração real através de ferramentas de mensageria com
documentação automática, que informa os colaboradores sobre o
andamento dos itens de trabalho, atividades e/ou tarefas;
• relatórios que permitem a visualização do status dos projetos de
desenvolvimento para os stakeholders;
Esta ferramenta tem sido a mais utilizada na empresa objeto estudo de
caso, porém, mesmo atendendo a todos os fatores que foram abordados quanto
ao que seria adequado para o monitoramento e controle nos processos de
desenvolvimento de software, temos um fator que não podemos desconsiderar
que são “as pessoas”, ou seja, a mudança de ferramenta no ambiente
organizacional traz mudanças significativas para a adaptação de um ambiente
para outro e essas alterações não acontecem da noite para o dia.
Por isso, é necessário mais investimento e treinamento nas equipes de
projeto de maneira que possam ser preparadas e alinhadas aos propósitos
estabelecidos pelo próprio processo de desenvolvimento de software, seguindo
72
as diretrizes e recomendações da gestão de projetos de software quanto à
atividade de monitoramento e controle.
Outro aspecto que devemos levantar em relação a isso, e que está
atrelado também aos problemas desta dissertação quanto ao papel do gerente de
projetos, é a sua atuação frente às informações que estas ferramentas oferecem,
e quais os “gaps” que elas apresentam para que possa haver melhoria quanto às
condutas a serem tomadas com efetividade nas ações corretivas e preventivas.
Uma maneira de atuar para o apoio quanto a esse problema e aos demais
apresentados nesta dissertação, seria a utilização de indicadores que poderia dar
uma direção do que seria necessário para melhorar o processo de
desenvolvimento de software e como estes indicadores auxiliariam a tomada de
decisão quanto à gestão de projetos de software.
3.6 Indicadores para o Monitoramento e Controle
De acordo com Mendonça (2002, p.24):
Indicadores são normalmente constituídos por duas unidades de medida correlacionadas. Servem para medir o desempenho de uma determinada atividade ou rotina, para saber se o que está sendo feito está dentro dos parâmetros exigidos, ou seja, se está de acordo com o que foi planejado.
Eles são compostos por variáveis representativas de um processo, que
permitem quantificá-lo. “Precisam ser bem definidos e acompanhados
sistematicamente” (MENDONÇA, 2002 p.25). Os indicadores servem
principalmente para os gestores na tomada de decisão. Para se analisar e
melhorar um processo é necessário conhecer o histórico dos indicadores de
desempenho.
73
Com a análise do comportamento dos indicadores no passar do tempo,
pode-se identificar os problemas do processo e propor melhorias. De acordo com
Kiyan (2001, p.38) “uma das formas de se classificar os indicadores de
desempenho é considerar a natureza da informação a ser produzida, podendo ser
objetiva ou subjetiva”.
As informações objetivas envolvem métodos numéricos (quantitativos),
enquanto as subjetivas resultam de métodos descritivos (qualitativos). A
subjetividade insere nos resultados um grau de imprecisão e incerteza, pois ela
se apóia em valores pessoais, percepção da realidade, costumes, gostos e
interesses. Apesar disso, medidas subjetivas são de grande valia para se avaliar
aspectos intangíveis do negócio (KIYAN, 2001).
Podemos perceber, então, certa resistência em se medir os processos de
desenvolvimento de software através de indicadores de desempenho. Um dos
motivos dessa resistência é a dificuldade de se identificar indicadores que
realmente ajudem na produção de informações importantes.
Será descrito a seguir alguns conceitos referentes à medição, métrica,
medidas e indicador segundo algumas referências.
• medição: é o conjunto de operações com o objetivo de determinar um
valor a uma medida (ISO/IEC 15939).
• métrica: é um atributo de uma entidade que pode ser avaliado. Por
exemplo, o esforço do projeto é uma avaliação (ou seja, métrica) do
tamanho do projeto (RUP, 2007).
• medidas: podem ser definidas em termos de um atributo e um método
para quantificá-lo e são independentes de outras medidas. (ISO/IEC
15939).
74
• indicador: é uma medida ou uma combinação de medidas,
normalmente apresentado na forma de gráfico ou tabela, que provê
entendimento a respeito de uma questão ou conceito de software
(ISO/IEC 15939).
A métrica de software proposto pela norma ISO/IEC 15939 esta orientado
às necessidades da informação de uma empresa. Para cada necessidade o
processo gera um produto de informação, a fim de satisfazer a informação
identificada.
Para isso, o processo de medição considera um modelo de informação de
medição que estabelece a ligação entre medidas definidas e as necessidades da
informação identificadas. A figura 9 apresenta este modelo definido na ISO/IEC
15939.
Figura 9 - Modelo de Medição da ISO/IEC 15939
Fonte: ISO/IEC 15939
75
De acordo com o modelo de informação de medição da ISO 15939, as
necessidades da informação são atendidas por conceitos mensuráveis definidos
em relação às entidades que podem ser medidas.
Essas entidades possuem atributos aos quais são aplicados métodos de
medição para obter medidas base que são associadas através de funções de
medição para compor medidas derivadas, ou seja, medidas que tem a função de
duas ou mais medidas.
As medidas são analisadas por modelos de análise e fornecem indicadores
cuja interpretação representa produtos de informação que atendem as
necessidades da informação inicialmente identificada.
Ressalta-se outras abordagens de métricas de software estão disponíveis
como:
• GQM: (Goal Question Metric) foi proposto na primeira metade da
década de 90 e tem sido utilizado para proporcionar métricas de
acordo com as necessidades de informação a respeito de produtos,
processos e recursos utilizados, estabelecendo bases para
comparações com trabalhos futuros (Basili, 1993).
• PSM: (Practical Software Measurement) parte do princípio de que é
necessário que a organização identifique suas necessidades de
informações mensuráveis para, a partir dos conceitos mensuráveis,
estabelecer e manter um conjunto de medições alinhadas às suas
necessidades (McGarry, 2001).
Estas definições quanto às métricas de software e indicadores nos ajudam
a responder outra questão problema definida nesta dissertação quanto ao
monitoramento e controle nos processos de software, onde os indicadores
deveria ser considerados na tomada de decisão na gestão de projetos.
76
Apesar de termos a possibilidade de utilizar estes indicadores de forma
favorável em ações para melhorar os processos de desenvolvimento de software,
a gestão de projetos continua no “achismo” e no seu “feeling8”, e esse não é o
caso, pois, existem métricas e informações que não estão sendo consideradas.
No desenvolvimento de software podemos aplicar três tipos de indicadores
que segundo Mendonça (2002) “são os mais utilizados para medir o desempenho
dos processos organizacionais”:
• indicador de qualidade: relação entre o que é produzido (certo ou
errado) pelo total produzido;
• indicador de produtividade: relação entre o total produzido sobre os
recursos consumidos;
• indicador de capacidade: mede a produção em um espaço de tempo
(capacidade da produção).
A utilização desses indicadores no monitoramento e controle, considerando
a sua documentação como os artefatos requeridos, deve atentar para:
• indicador de qualidade: total de artefatos que voltaram para o
retrabalho dividido pelo total de artefatos entregues;
• indicador de produtividade: total de artefatos entregues dividido pelo
total de funcionários trabalhando no projeto;
• indicador de capacidade: total de artefatos entregues dividido pelo
tempo total do projeto.
No estudo de caso desta dissertação iremos apresentar os indicadores de
produtividade que são utilizados e como essas informações são úteis para a
gestão de projetos de software quando são monitoradas e controladas nos
processos de desenvolvimento de software.
8 Feeling segundo o dicionário online de português é ter visão, enxergar uma boa oportunidade. Disponível em http://www.dicionarioinformal.com.br/feeling/ acessado em 19/01/2013.
77 4. Estudo de Caso
O estudo de caso, de acordo com Yin (2001, p.32), é “uma investigação
empírica de um fenômeno contemporâneo dentro de seu contexto da vida real,
especialmente quando os limites entre o fenômeno e o contexto não estão
claramente definidos”, onde a prática precede a teoria.
Segundo Yin (2001, p.40-77), um projeto de pesquisa que envolva o
estudo de caso envolve três fases distintas:
1) a escolha do referencial teórico sobre o qual se pretende trabalhar;
2) a condução do estudo de caso, com a coleta e análise de dados;
3) a análise dos dados obtidos à luz da teoria selecionada,
interpretando os resultados.
A escolha do referencial teórico utilizado nesta pesquisa trouxe assuntos
pertinentes como gestão de projetos, monitoramento e controle, processos de
software e métricas de software como contribuições para contextualizar e
esclarecer o uso dos termos durante a toda a pesquisa, inclusive ao estudo de
caso.
A coleta de dados é a etapa em que se inicia a aplicação dos instrumentos
elaborados e das técnicas selecionadas e, segundo Lakatos e Marconi (2001,
p.165) “é uma tarefa que exige do pesquisador um cuidadoso registro dos dados
e de um bom preparo anterior das informações que serão apresentadas”.
Na condução da coleta e análise de dados, as informações relevantes ao
propósito do estudo de caso desta pesquisa serão interpretadas para relacionar a
teoria discutida no capítulo 2 com a prática, que será a realidade da empresa
objeto deste estudo de caso.
78
O estudo de caso dessa dissertação é composto por uma investigação
realizada em uma empresa financeira que está em evidência no mercado pela
divulgação dos seus produtos e serviços e na sua estrutura organizacional tem
uma área de tecnologia da informação9.
A escolha por esta empresa foi motivada pela forma como os processos de
desenvolvimento de software são aplicados e os resultados que eles fornecem
para a gestão de projetos, concomitantemente ao tema proposto na vertente de
monitoramento e controle.
Os problemas relacionados e abordados ao tema desta pesquisa
descrevem as situações vivenciadas nesta área de tecnologia da informação e
não se difere dos encontrados em outras empresas quanto aos processos de
desenvolvimento de software, porém, as soluções encontradas para sanar essas
dificuldades podem ser as mesmas que foram discutidas nesta dissertação.
As situações problemas identificadas na área de tecnologia relacionadas
ao tema são:
• a gestão de projetos não ter mecanismos para utilizar de forma
assertiva o monitoramento e controle nos processos de software, ou
seja, não sensibilizar os gerentes de projetos da importância em
realizar esta atividade;
• a gestão de projetos não ter uma equipe de gerente de projetos com
o conhecimento quanto aos indicadores de desempenho para os
projetos e/ou sistemas, ou de ter gerentes que devido as suas
atribuições emergenciais não conseguem ter um olhar gerencial
para os indicadores de produtividade estabelecidos pela empresa;
9 Tecnologia da Informação em geral é a coleção de sistemas de computação usada para uma organização (TURBAN, 2005, p.04)
79
• a gestão de projetos utiliza várias ferramentas para o processo de
software sem a preocupação em fazer corretamente o
monitoramento e controle em relação aos seus projetos e sistemas,
ainda que este processo esteja presente na sua metodologia;
• a gestão de projetos não utiliza corretamente os indicadores de
desempenho para fazer a tomada de decisão a partir de ações
corretivas e preventivas, fazendo com que as ações sejam sempre
emergenciais em detrimento de um problema já conhecido por todos
na empresa, só que sem uma atuação constante da sua resolução.
Cabe ressaltar que estes problemas não são comuns somente a esta
empresa e nem sempre são evidenciados em eventos, workshops, seminários e
congressos voltados para a gestão de projetos, que na maioria dos casos
abordam conteúdos sobre inovação em processos e produtos de software.
Outra tentativa de minimizar estes problemas abordados na empresa tem
sido a contratação de empresas de consultoria de desenvolvimento de software,
que atualmente participam de todas as fases até a produção do software.
Esta alternativa de aumentar o processo produtivo de software se deu pela
crescente demanda por software com maior qualidade, atrelada a necessidade de
uma produção em um curto intervalo de tempo para atender aos processos de
negócio que necessitam de intervenções e alterações constantes.
Para Turban et. al (2002, p.477) a tecnologia da informação representa
atualmente uma parte vital de quase todas as empresas e desempenha um papel
importante de apoio na maioria das funções. No entanto, esse não é o objetivo
básico do negócio de muitas empresas.
Suas competências básicas, as coisas que elas fazem melhor e que
representam suas forças competitivas, são produção, varejo ou serviços, ou
80
alguma outra função. Por isso, algumas empresas decidiram usar fornecedores
externos ao invés de unidades internas como sua principal fonte de serviços de
TI, uma vez que a TI é complexa, com alto custo e está em constante evolução,
sendo difícil administrar a TI, mesmo para aquelas empresas com habilidades
gerenciais acima da média.
A idéia de terceirizar em si não é nova. As empresas sempre tiveram a
opção de comprar produtos e serviços de fora ou produzi-los internamente. Essa
decisão normalmente leva em conta dois fatores: 1) qual fonte é menos cara? e 2)
qual o nível de monitoramento e controle necessário? Nos últimos anos, tornou-se
comum a terceirização do desenvolvimento de software. Cerca de um terço das
500 maiores empresas listadas pela revista Fortune passaram a terceirizar o
desenvolvimento de software (TURBAN et. al., 2007 p.478).
A empresa financeira objeto deste estudo de caso conta com essa
prestação de serviço terceirizado para o desenvolvimento de seus softwares,
inclusive será descrita a seguir a sua estrutura na área de tecnologia da
informação de acordo com os seguintes itens:
• Descrição da Empresa;
a. Área de Tecnologia da Informação;
i. processo padrão de desenvolvimento de sistemas;
ii. unidades de desenvolvimento de sistemas;
iii. tipos de projetos;
iv. indicadores de produtividade;
81 4.1 Descrição da Empresa
Por se tratar de informações protegidas por sigilo através de normativos
internos da organização, fizemos algumas adaptações de modo que fosse
possível relatar a sua estrutura e os resultados, sem revelar aspectos que
pudessem comprometer as informações coletadas.
Algumas informações específicas da empresa não serão apresentadas. Ao
invés disso, utilizaremos pseudônimos como “empresa financeira” com o objetivo
de descrever as características da organização.
A empresa financeira não tem como atividade final o desenvolvimento de
software, mas mantém uma área de tecnologia da informação para desenvolver
e/ou adquirir produtos de software para os seus processos de negócio.
4.1.1 Área de Tecnologia da Informação
A área de tecnologia da informação conta aproximadamente com três mil
colaboradores e mantém contratos de serviços terceirizados especializados com
fornecedores de software, seja para realizar a manutenção dos sistemas
existentes e/ou construir novos projetos de software.
Representamos abaixo o organograma da empresa financeira, na área de
tecnologia da informação conforme a figura 10.
82
Figura 10: Organograma da Estrutura de Tecnologia da Informação
Fonte: “Empresa Financeira”
Neste organograma as estruturas que desenvolvem software são
conhecidas como: GE Demandas e GN Serviços Regionais de TI, mais
comumente conhecidas como unidades centralizadas e descentralizadas de
desenvolvimento de sistemas que iremos abordar posteriormente neste estudo de
caso.
Está área de tecnologia de informação da empresa financeira foi criada há
13 anos, com o propósito de fornecer uma estrutura adequada para o
processamento dos dados e informações dos clientes, trazendo melhorias e
agregando aos seus produtos e serviços.
83
4.1.1.1 Processo Padrão de Desenvolvimento de Sistemas
Com a concepção e formalização da área de tecnologia da informação, o
processo padrão de desenvolvimento de sistemas foi institucionalizado,
estabelecendo um conjunto de elementos fundamentais a ser seguido por todas
as equipes envolvidas em projetos e manutenções de sistemas,
independentemente das características dos produtos de software e das técnicas a
serem utilizadas.
Para realizar a conformidade deste processo padrão de desenvolvimento
de software houve a criação de um controle institucional que torna obrigatório a
entrega de artefatos ao final de cada fase/atividade, independente do processo de
software escolhido conforme o fluxo da figura 11 abaixo.
Figura 11 - Fluxo dos Controles Institucionais
Fonte: “Empresa Financeira”
84
O controle institucional estabelece algumas fases/atividades que são
realizadas pelas equipes, na verificação do que está sendo feito, tanto no
planejamento quanto na execução de um projeto e/ou manutenção de software
dentro do processo padrão de desenvolvimento de sistemas.
Além destes controles institucionais, no processo padrão de
desenvolvimento de sistemas utiliza-se de alguns cenários que representam os
processos de software como:
• estruturado: utilizado com a metodologia de análise estruturada
linguagem estruturada de programação Cobol e ambiente Mainframe de
alta plataforma.
• unificado: utilizado com a metodologia de processo unificado (RUP),
orientados a objetos com linguagem Java em ambientes de baixa
plataforma Linux, Windows etc.
• método ágil10: utiliza esta metodologia para dar maior agilidade quanto
ao gerenciamento do projeto em relação às entregas de projetos e/ou
manutenção baseado no Scrum11.
Os cenários contêm papéis, atividades, disciplinas, artefatos e guias que
auxiliam uma equipe no momento de dar manutenção em algum sistema, ou
desenvolver um novo projeto.
A atuação nestes cenários depende da capacitação de cada colaborador,
pois, os assuntos que são abordados neles são utilizados tanto no contexto
acadêmico quanto no profissional, sendo boas práticas de como conduzir o
processo padrão de desenvolvimento de sistemas.
10 O Método Ágil: tem como características a aceitação de mudanças nos seus requisitos, foco na colaboração entre clientes e desenvolvedores e apoio na entrega antecipada do produto de software (HIRAMA, 2012, p.198) 11 Scrum é um framework para gerenciamento de projetos ágeis muito utilizado na área de desenvolvimento de software de qualquer produto, principalmente por utilizar o processo de software iterativo e incremental. (CRUZ, 2013, p.31).
85
Nestes cenários as fases voltadas para o gerenciamento de projeto são:
• base corporativa de projetos: identifica os projetos e sistemas que
compõem as informações e tecnologias utilizadas pelos cenários.
• proposta de solução: apresenta uma proposta do projeto que será
desenvolvido por este cenário;
• acordo com os envolvidos: define quais serão as áreas que serão
envolvidas para este projeto;
• análise de impacto de mudança/desvio: informa os impactos que
este projeto terá nos demais sistemas, principalmente em relação as
suas integrações;
• evidência de aprovação de escopo: são as aprovações realizadas
pelas áreas envolvidas de que o escopo do projeto foi definido, e
deverá ser agora conduzido por uma equipe.
• plano do projeto: todo o planejamento do projeto com as informações
relevantes ao seu desenvolvimento como custo, prazo e equipe
envolvida;
• cronograma: fases e atribuições dos envolvidos com os marcos
principais do projeto;
• matriz de recursos: recursos envolvidos nos projetos e os perfis dos
usuários que serão beneficiados pelo projeto;
• estimativa de tamanho, recurso, duração e custo: apresentado para
a área gestora do que é necessário para que este projeto seja
desenvolvido;
• termo de liberação: aprovação final do projeto para que possa entrar
no ambiente de produção.
86
Todos os colaboradores da área de tecnologia da informação têm atuação
e formação no processo padrão de desenvolvimento de sistemas, sendo
estendido também aos fornecedores de software, trazendo situações reais que
possam ser simuladas pelos colaboradores e fornecedores.
O modelo de desenvolvimento utilizado pelo processo padrão de
desenvolvimento exemplifica a estrutura adotada pelas unidades de
desenvolvimento de sistemas, e contém três focos conforme figura 12.
• preservação define a utilização de regras e controles institucionais
para os produtos de software;
• inovação são técnicas/ tecnologias utilizadas, tendo como definição a
utilização dos cenários;
• orientação são padrões e procedimentos das melhores práticas
aplicadas aos cenários;
Este modelo de desenvolvimento utilizado pela área de tecnologia da
informação apresenta o que é “obrigatório” pelo foco de preservação e o que é
“recomendado” pelo foco de inovação e orientação, servindo como ponto de
partida para o desenvolvimento de projetos e sistemas, inclusive verificado pela
área de auditoria interna, e até mesmo pelas equipes internas de qualidade do
processo.
87
Figura 12 - Modelo de Desenvolvimento
Fonte: Empresa Financeira
4.1.1.2 Unidades de Desenvolvimento de Sistemas
Todos os sistemas e projetos são desenvolvidos e mantidos pela área de
tecnologia da informação de forma centralizada e descentralizada através de
unidades de desenvolvimento de sistemas em diversas capitais e grandes centros
do Brasil, onde estão inseridos colaboradores da empresa e os seus
terceirizados.
As unidades de desenvolvimento centralizadas são conhecidas pelo
volume de projetos e sistemas que possuem, ou seja, tem uma capacidade
produtiva com um número maior de colaboradores e estão situadas em três
capitais no Brasil (Brasília, Rio de Janeiro e São Paulo), desenvolvendo sistemas
para a área bancária em processos de negócios essenciais para a “empresa
financeira”.
88
As unidades de desenvolvimento descentralizadas têm a particularidade de
desenvolver sistemas departamentais utilizados pela “empresa financeira”, e,
portanto, sua capacidade produtiva apresenta uma quantidade reduzida de
colaboradores, porém, com um grau de importância relevante aos processos de
negócio.
O propósito destas unidades para a área de tecnologia da informação é dar
atendimento aos gestores em relação aos seus processos de negócios quanto
aos projetos e sistemas, tendo uma similaridade ao desenvolvimento distribuído
de software (DDS) que segundo Carmel (1999 p.269) “em muitas organizações
encontram uma alternativa de experimentar o desenvolvimento de software com
equipes geograficamente distantes, devido à escassez de recursos capacitados”.
Além das unidades de desenvolvimento de sistemas, a área de tecnologia
da informação da “empresa financeira” possui unidades que fornecem subsídios e
suporte para que seja acompanhado o trabalho realizado pelas unidades de
desenvolvimento de sistemas, como a área de operações (produção), área de
suporte tecnológico, datacenter e área da matriz.
4.1.1.3 Tipos de Projetos
Os projetos da área de tecnologia da informação da empresa financeira
são classificados como projetos novos e/ou projetos evolutivos de acordo com a
necessidade e adequação das áreas de negócio, conduzidos pelas unidades de
desenvolvimento de sistemas.
Os projetos novos (PN) são concebidos para a criação de um novo sistema
e/ou software que não existe, atendendo aos processos de negócio com seus
novos produtos e serviços.
89
Os projetos evolutivos (PE) são concebidos através de melhorias ou
evoluções de um sistema que já está em produção com seus produtos e serviços,
e que são adequados a um determinado processo de negócio, buscando atender,
regras, leis, até mesmo as adequações tecnológicas nestes sistemas.
As demandas12 que atendem a esses projetos (PN) e (PE) são registradas
também em cada fase e/ou atividade do projeto, sendo implantadas de acordo
com a definição do cronograma estabelecido nas unidades de desenvolvimento
e/ou produção.
4.1.1.4 Indicadores de Produtividade
Para verificar a capacidade produtiva das unidades de desenvolvimento de
sistemas, a diretoria de tecnologia da informação da empresa financeira
desenvolveu indicadores de produtividade medindo a produção, mas não com o
intuito de monitorar e controlar o processo padrão de desenvolvimento de
software.
São disponibilizados através de um Painel (Dashboard13) conforme abaixo:
• Indicador de Demandas Implantadas no Prazo:
Este indicador informa a quantidade de demandas que foram implantadas
e previstas no mês e entregues tanto em projetos quanto de manutenções.
Um exemplo deste indicador seria uma unidade de desenvolvimento de
sistemas ter previsto no mês 300 demandas e 225 foram implantadas no
prazo refletindo um percentual de 75% de produtividade que estaria abaixo
da meta estabelecida que é de 78%.
12 A Demanda significa a quantidade de um bem ou serviço que os consumidores desejam adquirir por um preço definido em um mercado. A demanda pode ser interpretada como procura, mas não necessariamente como consumo, uma vez que é possível querer e não consumir um bem ou serviço, por diversos motivos. (www.significados.com.br/demandas acessado em 14/12/3013) 13 Dashboard é um dos principais instrumentos para a gestão de desempenho para os executivos (Fernandes, 2008 p.155)
90
• Indicador de Demandas Implantadas por Ponto de Função14 (APF):
Este indicador informa a quantidade de demandas que foram implantadas
no mês com a quantidade de pontos de função e entregues tanto de
projetos quanto de manutenções. Como no exemplo anterior, as 225
demandas implantadas representam um quantitativo de 10.000 PF
entregues no mês, representando a sua produtividade.
• Indicador de Defeito nas Aplicações/Projetos:
Este indicador informa a quantidade de demandas de defeitos que foram
resolvidas no mês e entregues tanto de projetos quanto de manutenções.
No exemplo anterior destas 225 demandas implantadas identificou-se uma
quantidade de 66 demandas de defeito representando um percentual de
29,33%. de erros encontrados nos projetos/sistemas entregues.
• Indicador de Satisfação da Área Gestora:
Este indicador informa as demandas classificadas pelos gestores de
negócio como (bom, muito bom e ótimo). Das 225 demandas implantadas
os gestores disseram que 25 foram boas, 170 muito bom e 30 ótimo.
• Indicador de Entregas Estratégicas:
Este indicador apresenta as demandas classificadas como entregas
estratégicas pelos gestores de negócio. Das 225 demandas implantadas
72 delas foram entregas estratégicas representando 32% de produtividade.
Os indicadores são acompanhados diariamente com as equipes de projeto
contemplando tanto os projetos novos e evolutivos ou sistemas acometidos de
manutenções, através das demandas de:
a) manutenção de sistemas: são as demandas evolutivas e adaptativas
aos sistemas;
14 Análise de Pontos de Função expressa à funcionalidade de um sistema de informação em termos de funções de dados e funções de transação reconhecida por um usuário (Analise de Pontos de Função para Melhoria de Software versão 2.2.1 - NESMA).
91
b) novo desenvolvimento de sistemas: são demandas que contemplam
novos projetos;
c) defeitos: são demandas de manutenções corretivas, que são
originadas dos projetos e sistemas;
d) serviços técnicos especializados: são demandas de suportes
previstos em contrato para o atendimento e entendimento aos diversos
tipos de demandas (manutenção, novo desenvolvimento e defeitos),
sendo uma solicitação para a empresa de software contratada.
“O que não se pode medir não se pode gerenciar”. Esta frase de Peter
Drucker traduz a principal necessidade dos gestores de projetos e que segundo
Mansur (2007, p.159) “as metodologias e indicadores permitem estabelecer
objetivos, monitorar os resultados e verificar de forma objetiva como e se as
metas propostas foram atingidas”.
O acompanhamento destes indicadores é realizado diariamente pelo
escritório de projetos15 que reporta as divergências para a gestão de projetos
quando os índices estão abaixo da meta estabelecida para a tomada de decisão
em relação ao processo de desenvolvimento de software.
4.2 Coleta de Dados
A coleta realizada para o estudo de caso dessa dissertação contempla as
informações dos indicadores da empresa, como forma de abordar o
monitoramento e controle nos processos de desenvolvimento de software, sendo
que os dados foram coletados do sistema de painel de indicadores da área de
tecnologia da informação. 15 O Escritório de Projetos ou Project Management Office (PMO) de acordo com (Trentim, 2011 p.19) é uma estrutura organizacional responsável pelo gerenciamento de projeto na organização ou em um departamento
92
As informações dos indicadores de produtividade foram disponibilizas por
meio de relatórios específicos disponibilizados pela empresa, onde constam as
informações do período de 01/09/2013 a 30/11/2013 da área de tecnologia da
informação de uma de suas unidades situada na cidade de São Paulo.
Apesar de termos as informações de todos estes indicadores de
produtividade disponibilizadas pela empresa o que será detalhado e abordado
neste estudo de caso são outros dois indicadores criados pelo escritório de
projetos considerando os dados dos projetos e sistemas, com um quantitativo 19
projetos novos e evolutivos e 155 sistemas em manutenção, fazendo uma
comparação com os outros indicadores.
Terribili (2010 p. 301) nos mostra como criar um novo indicador:
“O primeiro passo a ser tomado é identificar o que se quer medir. Posteriormente, um nome único é dado ao indicador. Depois é necessário identificar onde estão as fontes de informação, qual o tamanho da amostra e a periodicidade para a captura dos dados”.
Os indicadores criados pelo escritório de projetos seguindo essa premissa
foram:
a) demandas replanejadas: verificam as demandas que foram
replanejadas pelos gerentes de projetos a partir das demandas previstas
no mês, que são demonstradas pelo indicador de demandas implantadas
no prazo informado anteriormente. A periodicidade da captura dos dados é
realizada semanalmente, sendo consolidado somente no mês corrente.
b) demandas sem o campo item de “portfólio”: verificam as demandas
que foram implantadas e estão sem este campo preenchido e não estão
sendo apresentadas no painel de indicadores (dashboard).
Neste indicador as demandas foram implantadas, porém, não são
apresentadas no painel (dashboard). A periodicidade da captura dos dados
é realizada semanalmente, sendo consolidado somente no mês corrente.
93
No indicador de demandas replanejadas, o escritório de projetos faz o
levantamento e a coleta das demandas previstas, e verifica com as equipes se
estas demandas serão implantadas ou não, partindo do pressuposto da data no
mês. A partir deste levantamento as demandas que não serão implantadas no
mês serão replanejadas, porém, o gerente de projetos não sabe qual a nova data
prevista para a sua implantação.
No indicador de demandas sem o item do portfólio, o escritório de projeto
constata que não houve a entrega, não entanto, essa constatação é falha, pois
houve a entrega. Ocorre que o campo “item de portfólio16” da demanda que é
apurado neste indicador deveria estar preenchido, inclusive no momento em que
os colaboradores realizam o fechamento destas demandas, mas isso não
acontece na maioria das vezes.
Todos os dados que foram coletados são informações que fornecem
subsídios para o monitoramento e controle para o processo de desenvolvimento
de software que segundo Terribili (2010 p.311) “os indicadores surgem como
auxiliares no processo no qual se fundamentam as argumentações mediante o
fornecimento de informações (ou métricas) dos processos”.
Conforme Terribili (2010 p. 301) “para realizar a implantação de um
indicador é preciso realizar os testes de preferência com situações já ocorridas,
para conseguir avaliar a aderência do indicador ao objetivo pretendido”.
Para o indicador de demandas replanejadas, verificamos inicialmente as
demandas que estavam previstas conforme a figura 13, que totalizam 759
demandas no período de 01/09/2013 à 30/11/2013, que no mês de setembro
tiveram 278, em outubro 181 e novembro 300.
16 Segundo (Trentim, 2011 p.18) o “portfólio” são conjuntos de programas e projetos que suportam determinados objetivos estratégicos de negócio de uma unidade departamental ou de toda a organização, ou seja, o portfólio é um agrupamento de esforços (programas e projetos) para atingir um determinado objetivo estratégico.
94
Figura 13: Demandas previstas para a Implantação
Fonte: Sistema de Painel de Indicadores
Estas demandas foram verificadas através de um relatório semanal de
demandas, também utilizado para o indicador de demandas implantadas no
prazo. Destas 756 demandas previstas para a implantação, 70,86% (196) foram
replanejadas no mês de setembro, 42,54% (77) em outubro e 65,33% (197) em
novembro, conforme a figura 14, ou seja, 470 demandas replanejadas que
representam 59,58% na média dos meses.
Figura 14: Demandas Replanejadas
Fonte: Sistema de Painel de Indicadores
Destas 756 demandas previstas para a implantação, 29,14% (81) foram
implantadas no mês de setembro, 57,46% (104) em outubro e 34,67% (104) em
novembro conforme a figura 15, totalizando 289 demandas que representam uma
média de 40,42% de produtividade de entregas.
95
Figura 15: Demandas Implantadas
Fonte: Sistema de Painel de Indicadores
Para o indicador de demandas sem o item de portfólio a coleta realizada
totalizaram 3.646 demandas atualizadas no período de 01/09/2013 à 30/11/2013,
nos meses de setembro, outubro e novembro, considerando 155 sistemas
verificados, onde 113 foram atualizados, representando 73% conforme a figura
16.
Figura 16: Sistemas sem o item de portfólio
Fonte: Sistema de Painel de Indicadores
Este indicador para o portfólio aborda o gerenciamento de projetos, e que
segundo Terribili (2010 p. 319):
96
É, na atualidade, indispensável para o efetivo acompanhamento. A não utilização seria o mesmo que monitorar a febre de alguém sem utilizar um termômetro, usando apenas o contato físico ou a aparência da pessoa para efetuar a avaliação”.
Para os projetos novos e evolutivos foram totalizadas 997 demandas
considerando 19 projetos verificados, sendo 9 projetos atualizados e 10 não
atualizados, representando 47% que estavam sem o campo item de portfólio
preenchido conforme a figura 17.
Figura 17: Projetos sem o item de portfólio
Fonte: Sistema de Painel de Indicadores
Em projetos e sistemas temos devemos contextualizar a utilização dos
indicadores que conforme Terribili (2010 p.319) “como se fossem fotografias
instantâneas, mas que indicam tendências”.
Aconselha-se utilizar aqueles que considerarem os mais adequados ao
contexto, aqueles que foram criados na própria empresa, ou os mais usuais do
mercado.
97 4.2 Análise de Dados
Para analisar os dados coletados nesta pesquisa em relação aos
indicadores será utilizada a técnica de análise de cruzamento de tabelas
(crosstabs), com o propósito de permitir um estudo mais aprofundado dos
resultados obtidos.
A tabela cruzada segundo Malhotra (2001, p.408) é uma “técnica
estatística que descreve duas ou mais variáveis simultaneamente, e origina
tabelas que refletem a distribuição conjunta de duas ou mais variáveis com um
número limitado de categorias ou valores distintos”.
Constatamos que o indicador de demandas replanejadas está diretamente
ligado ao indicador de demandas implantadas no prazo, pois este indicador traz o
quantitativo de demandas que foram alteradas pelo gerente de projetos tendo em
visto o número de demandas previstas menos as demandas implantadas.
Se tivermos um constante replanejamento em relação às demandas,
significa que o nosso desempenho será comprometido. Neste sentido este
indicador reflete o desempenho da área de tecnologia da informação da empresa
financeira e que segundo Terribili (2010 p. 312):
O indicador de desempenho da demanda mede a evolução do escopo do projeto realizado em comparação ao planejado. A fórmula para realizar o cálculo é: “percentual global concluído do trabalho realizado + percentual global concluído do trabalho planejado, considerando-se a linha de base”.
As variações possíveis para este indicador conforme Terribili (2010 p.312)
são:
• demanda em dia: desvio de 10%; 1.00 > IDD >= 0.90 ou 1.10 >=
IDD>1,00
• demanda atrasada: desvio de 10% a 20%; 0,90 > IDD>= 0,80 ou
1.20>IDD>1.10
98
• demanda replanejada: desvio superior a 20%;0,80>IDD ou
IDD>1.20
Considerando essas variações apresentadas o quantitativo de demandas
replanejadas representa 59,58%, que significa um desvio superior ao desejado,
ou seja, um volume expressivo que sinaliza que não há um bom planejamento
para a previsão de implantação das demandas pelos gerentes de projetos.
Portanto, ações como o acordo entre os envolvidos pelos projetos e
sistemas devem ser monitoradas e controladas, para que haja uma entrega maior
das demandas que precisam ser avaliadas antes mesmo de fazer a previsão para
a sua implantação.
Em relação o indicador de demandas sem o item de portfólio a análise e
que fazemos da coleta de dados é que o volume de atualização é alto tanto para
sistemas e projetos, isso significa que as equipes de projetos não tem se
interessado pelo acompanhamento que é realizado pela gestão de projetos.
Não é uma novidade para a gestão de projetos saber que o dia-a-dia das
equipes sobrecarrega as atividades que elas devem realizar, mas ainda assim é
algo que deve ser monitorado e controle, pois, como iremos apresentar a nossa
produtividade se não existir a preocupação em manter as informações atualizadas
nos devidos repositórios. É necessário criar iniciativas de motivação e incentivo
para as equipes a fim de que possam se comprometer constantemente.
4.3 Análise dos Resultados
Identificamos que o monitoramento e controle atrelado aos indicadores
propostos trouxeram uma visibilidade para a gestão de projetos quanto às
99 informações para o seu planejamento e as deficiências existentes no processo de
desenvolvimento de software.
As ações que foram realizadas para a análise destes indicadores foram:
• relatório semanal de demandas com datas previstas de
implantação. Com este relatório podemos monitorar e controlar os
projetos e sistemas quanto às entregas que serão realizadas
verificando se existirá a possibilidade replanejamento.
• relatório semanal de demandas sem o campo item de portfólio.
Com este relatório podemos verifica as demandas que foram
implantadas e que não estão sensibilizando os indicadores de
produtividade devido à falta de preenchimento do campo.
• acompanhamento diário pelo escritório de projetos dos indicadores
através do monitoramento e controle de demandas replanejadas e
sem o item de portfólio, para o sistema painel de indicadores
mantenha atualizado as informações fidedignas.
• reuniões de acompanhamento entre o escritório de projetos com
as equipes de projeto que tiverem problemas quanto ao
replanejamento das demandas de forma a não deixar essa situação
ser rotineira e nem criar um Backlog17 para a unidade de
desenvolvimento de sistemas
Atendendo as premissas referentes ao monitoramento e controle, quando
temos ações de analisar indicadores de produtividade estamos na verdade
verificando onde estamos, onde deveríamos estar e o que fazemos para que
possamos voltar ao caminho.
17 Backlog: refere-se a um log (resumo histórico) de acumulação de trabalho num determinado período de tempo. Disponível em http://pt.wikipedia.org/wiki/Backlog acesso em 22/01/2014.
100
Os resultados obtidos com estes indicadores aprofundam o conhecimento
acerca dos problemas relatados, onde torna a resolução possível quando se tem
uma metodologia definida para realizar este acompanhamento da atividade de
monitoramento e controle nos processos de desenvolvimento de software.
O que abordamos neste estudo de caso fortalece a atividade de
monitoramento e controle, porém, a maneira como este processo é conduzido
sinaliza mudanças a serem realizadas, ou seja, ter apenas uma metodologia que
enfatiza este processo e não ser utilizada não acrescenta em nada ao trabalho.
Os relatórios de desempenho que hoje são apurados pelos indicadores no
estudo de caso, simplificam o trabalho sendo um alvo a ser perseguido pela área
de tecnologia da informação da empresa financeira quanto ao seu processo
padrão de desenvolvimento de sistemas.
Diante disso, essa análise dos resultados para o estudo de caso serve
como base para o processo de desenvolvimento de software principalmente em
relação à gestão de projetos, que torna-se alvo de críticas na empresa quando
não apresenta os resultados em relação as suas entregas, principalmente quando
algum processo está deficiente como foi retratado neste estudo.
Se não houver uma estrutura que possa apoiar estas atividades abordadas
neste estudo de caso, isso pode comprometer o trabalho e segundo Martins
(2010 p.103) uma estrutura permite identificar a necessidade de deflagrar ações
corretivas e preventivas para manter a conformidade do planejamento, ou
também pode ser identificada a necessidade de fazer algum replanejamento.
101 5. Considerações Finais
Esta pesquisa apresenta contribuições para as atividades relacionadas ao
monitoramento e controle no processo de desenvolvimento de software, tanto
pela sua fundamentação teórica quanto pela realização do estudo de caso como
uma possibilidade de realizar esta prática.
A gestão de projetos de software tem procurado desempenhar o seu papel
e atuação em relação aos seus projetos, as suas metodologias e ferramentas,
mas ainda assim, os resultados obtidos com as entregas fora do prazo, custos
acima dos previstos e produtos com baixa qualidade são constantes.
O monitoramento e controle que está diretamente ligado à gestão de
projetos por sua vez não têm sido utilizado na sua totalidade, como verificado na
pesquisa realizada pelo PMI (2012), onde 24% não adotam esta atividade em
seus projetos. Mas nesta pesquisa não evidência a sua utilização quanto aos
processos de software
Considerando esta atividade em relação aos processos de
desenvolvimento de software podemos citar o RUP (2007), que possui uma
estrutura com tarefas para sua utilização, porém, temos a barreira da capacitação
dos recursos para atuar nesta atividade, que deveria ser analisado pela gestão de
projetos no sentido de ter o uso mais efetivo desta atribuição.
A escolha desta atividade no processo de software pode aumentar a
velocidade do desenvolvimento, melhorar a qualidade, facilitar o
acompanhamento, minimizar os riscos e melhorar a relação com o cliente, porém,
caso não haja a escolha no processo de software pode gerar baixa produtividade,
retrabalho, insatisfação do cliente e realização de atividades desnecessárias
(McCONNEL, 1996).
102
A definição do processo de software torna-se um fator a ser considerado
pela gestão de projetos, pois, as dificuldades apresentadas por Brooks (1987)
como essenciais (pertinentes à natureza do software) e acidentais (pertinentes a
sua produção) quando monitoradas e controladas podem detectar
antecipadamente problemas e serem transformados em indicadores de
produtividade.
Quando a gestão de projetos considera a utilização do monitoramento e
controle nos processos de desenvolvimento de software e consegue evidenciar
estas atividades por meio das informações com indicadores de desempenho eles
se tornam mecanismos e subsídios na tomada de decisão, minimizando os
problemas encontrados na produção de software.
Pressman (1995, p.23) destaca que os problemas estão relacionados às
estimativas de prazo e de custos serem frequentemente imprecisas, ou seja, a
demanda de software ser superior à capacidade da produção das pessoas,
impactando na qualidade dos softwares produzidos serem aquém da esperada.
Para Beck e Andres (2000 p. 10), os problemas são os elevados custos
com a manutenção e modificação de softwares e os defeitos existentes que não
foram detectados previamente, mas que poderiam ser levantados se em uma das
suas atividades no processo de software estivessem presente o monitoramento e
controle.
As ferramentas que fornecem apoio aos processos e projetos de software
normalmente estão ligadas a gestão de projetos, e elas contribuem para que as
atividades de monitoramento e controle possam ser realizadas. Porém, conforme
abordamos no capítulo 3, estas ferramentas precisam ter atributos e
funcionalidades que possam agregar valor à gestão de projetos, como por
exemplo, informações para as métricas e indicadores.
103
No estudo de caso objeto da pesquisa trouxe a confirmação prática por
meio dos indicadores de produtividade acompanhados pelo monitoramento e
controle, utilizado para sustentar dados e informações estratégicas para a área de
tecnologia da informação, assim como evidências de ganhos com sua utilização
nos processos de software.
Neste sentido os indicadores definidos pela empresa objeto do estudo de
caso apresentaram maneiras de medir e apurar as informações da produtividade
do processo de software, medindo as demandas entregues no prazo e/ou atraso,
a quantidade de pontos de função destas demandas, os defeitos apurados, as
entregas mais importantes para o negócio e o grau de satisfação da área gestora.
Além desses indicadores utilizados, o monitoramento e controle aplicado
aos processos de software pelo escritório de projetos trouxeram mais dois
indicadores que foram criados e tiveram uma importância singular, abordando o
planejamento das demandas dos projetos e sistemas e mapeando todas as
informações das demandas que não eram disponibilizadas no sistema painel de
indicadores da área de tecnologia da informação da empresa financeira.
Os ganhos com a existência destes novos indicadores, verificados no
processo de desenvolvimento de software na abordagem de monitoramento e
controle traz uma reflexão de que poderiam ser criados mais indicadores que
pudessem auxiliar as suas atividades como, por exemplo:
• indicador de acompanhamento de atividade(s) dos recurso(s);
• indicador de desempenho dos recurso(s);
• indicador de retrabalho dos recurso(s);
• indicador da equipe por fase(s) no processo de software;
• indicador da qualidade do(s) artefato(s);
• indicador do(s) processo(s) de software;
104
• indicador de fase(s) do projeto;
• indicador de alteração do escopo do projeto;
• indicador de alteração do(s) requisito(s);
• indicador de conformidade da(s) atividades(s) x não conformidades
Ter estes indicadores atribuídos à gestão de projetos para os processos de
software reforça o que Pressman (1995) quando diz que eles nos ajudam a:
• ter um visão melhor do processo de desenvolvimento de software;
• identificar os riscos;
• identificar e resolver os problemas antes que se tornem críticos;
• melhorar a comunicação da equipe com a organização
• avaliar o desempenho do projeto;
• tomar decisões;
A aplicação do monitoramento e controle no processo de desenvolvimento
de software contribuiu e serviu como um mecanismo de aproximação entre as
áreas gerenciais e técnicas, gerando dados e indicadores que tornam mais
previsíveis e assertivos os planejamentos para a tomada de decisão na gestão de
projetos de software.
Cabe ressaltar que o monitoramento e controle está intrinsecamente
relacionado aos projetos e não aos processos, apesar de que no capítulo 3 desta
pesquisa procuramos abordar a relação entre processos de software com o
monitoramento e controle contemplando atividades, tarefas e processos que
realizam esta atividade.
Portanto, nesta pesquisa, o seu estudo de caso trouxe ganhos que
podemos levar em consideração quanto aos processos de desenvolvimento de
software para o monitoramento e controle no aspecto da gestão de projetos, com
as seguintes contribuições:
105
• A atividade de monitoramento e controle quando realizada nos processos
de software deve estabelecer processos, atividades e tarefas que possam
direcionar a sua utilização;
• As ferramentas que o monitoramento e controle utilizam para o processo
de software podem direcionar ações corretivas e preventivas, que devem
ser informadas a gestão de projetos para as devidas providências
necessárias ao trabalho realizado pelo gerente de projetos e sua equipe.
• A atuação gerencial tendo como uma das suas premissas a execução da
atividade de monitoramento e controle nos processos de software como
ferramenta diária de trabalho para acompanhar os projetos e sistemas de
uma organização;
• Os indicadores de produtividade atrelados ao monitoramento e controle
nos processos de desenvolvimento de software são subsídios fornecidos
que podem ter dados, informações atualizadas e consistentes para a
tomada de decisão na gestão de projetos, portanto, é necessário que
possam ser diversificados de acordo com a realidade da organização;
O material pesquisado em relação às referências bibliográficas tanto os
livros, os artigos e as publicações trouxeram um embasamento para sustentar
teoricamente o estudo de caso objeto desta pesquisa procurando enfatizar o
monitoramento e controle nos processos de desenvolvimento de software.
Como sugestão de trabalhos futuros seria interessante investigar e
construir referências (livros, artigos e publicações) para enfatizar mais o
monitoramento e controle voltado para os processos de software, principalmente
aos que não foram abordados nesta pesquisa. Neste sentido a conclusão final
desta pesquisa procura acrescentar a relevância deste assunto, que aos olhos do
pesquisador deve ser abordado com mais periodicidade nas organizações.
106
6. Referências Bibliográficas
ARGILA, Carl. A., Jones, Capers., Martin, Johannes.J. Software Engineering. The
Electrical Engineering Handbook. Ed. Richard C. Dorf. Boca Raton: CRC Press
LLC, 2000.
BARBARÁN, GABRIELA M. C. Indicadores de Desempenho para Avaliação do
Desenvolvimento de Projetos nas Indústrias de Software. Tese de mestrado da
USP - Universidade de São Paulo, 1999
BASILI V. R., CALDIERA, G., ROMBACH, H. D., “The Goal Question Metric
Approach”, University of Maryland, 1993.
BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: Embrace
Change, Addison Wesley Professional, 2000.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML.
Campus. 2ª ed. 2007.
BOOCH, G.; RUMBAUGH, J; JACOBSON, I. The Unified Modelling Language
User Guide, Massachusetts: Addison Wesley, 1999.
BOOCH Grady; RUMBAUGH, James; JACOBSON, Ivar. UML 2.0: guia do
usuário. Rio de Janeiro: Campus, 2005.
BROOKS, F.P. No silver bullet: essences and accidents of software Engineering.
IEEE. Computer, v. 20, n. 4, 1987.
107
BRYMAN, A. Research Methods and Organization Studies. London: Unwin
Hyman, 1989.
CARMEL, E. Global Software Teams – Collaborating Across Borders and Time-
Zones. Prentice Hall, USA, 1999.
CRUZ, Fábio. Scrum e Guia PMBOK unidos no gerenciamento de projetos. Rio
de Janeiro: Brasport, 2013.
FERNANDES, Aguinaldo Aragon. Implantando a governança de TI: da gestão à
gestão de processos e serviços / Aguinaldo Aragon Fernandes, Vladimir Ferraz
de Abreu. 2 ed. – Rio de Janeiro: Brasport, 2008.
GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. São Paulo: Atlas,
1999.
GRAY, Clifford F., Erik W. Larson: Gerenciamento de Projetos: O Processo
Gerencial; Tradução Dulce Cattunda, Frederico Fernandes – 4 ed. Porto Alegre:
AMGH, 2010.
HIRAMA, Keichi. Engenharia de Software: qualidade e produtividade com
tecnologia. Rio de Janeiro: Elsevier, 2012.
HUMPHREY, W. S. Managing the Software Process, Addison Wesley Longman
Inc, 1989
108
IBM - Rational Team Concert Features. Disponível em http://jazz.net/
projects/rational-team-concert/features acesso em Dezembro 2013.
ISO 15939. International Standard ISO/IEC FDIS 15939, “Software Engineering -
Software Measurement Process”, 2002.
JORDAN, Lee. Project Management with dotProject: Implement, Configure,
Customize, and Maintain your dotProject Installation. Birmingham: Packt
publishing, 2007.
KERLINGER, Fred N. Metodologia da pesquisa em ciências sociais: um
tratamento conceitual. São Paulo: EPU, 1980.
KERZNER, H. Project Management - A System Approach to Planning,Scheduling,
and Controlling, 7º ed., New York, John Wiley & Sons Inc.,2001.
KIYAN, Fábio Makita. Proposta para desenvolvimento de indicadores de
desempenho como suporte estratégico. Dissertação apresentada à escola de
Engenharia de São Carlos da Universidade de São Paulo. 2001.
LAKATOS Eva Maria. Fundamentos de metodologia científica./ Marina de
Andrade MARCONI, Eva Maria Lakatos 5. ed. São Paulo: Atlas, 2003.
MALHOTRA, N. Pesquisa de marketing: uma orientação aplicada. 3ª edição.
Porto Alegre: Bookman, 2001. 720 p
109 MANSUR, Ricardo. Governança de TI: metodologia, frameworks e melhores
práticas. Rio de Janeiro: Brasport, 2007.
MARTINS, José Carlos Cordeiro. Técnicas para gerenciamento de projetos de
software – Rio de Janeiro: Brasport, 2007.
MARTINS, José Carlos Cordeiro. Gerenciamento de projetos de software com
PMI, RUP e UML, Colaboração de Fabrício Ramirez, 5 ed.-– Rio de Janeiro:
Brasport, 2010.
MCGARRY, John et al. Practical Software and Measurement Objective
Information For Decision Makers. Addison Wesley, 2001.
MENDONÇA, Mauro. TAM – Técnicas para Análise e Melhoria de Processos.
Curso em Fita de Vídeo, LinkQuality, 2002.
MCCONNEL, Steve. Rapid development. Redmond, WA: Microsoft Press, 1996.
OLIVEIRA, J. P. F.; ELIAS, G.: Um Relato de Experiência com uma Infra-estrutura
para desenvolvimento Distribuído de Software. In: Simpósio Brasileiro de
Engenharia de Software. II Workshop de Desenvolvimento Distribuído de
Software. Campinas – SP, 2008.
PIMENTEL, Alex. Gerência de Projetos. São Paulo: Digerati Books, 2008. 128 p.
110
PMI-Project Management Institute. Pesquisa PMSURVEY.ORG 2012: PMI. 2012.
Disponível em: <http://www.pmsurvey.org/>. Acesso em: 01 novembro. 2013.
PMBOK. A Guide to the Proiject Management Body of Knowledge, PMI-Project
Management Institute, Newtown Square, Pennsylvania, USA, 2008.
PRESSMAN, Roger. Software Engineering: A Practitioner's Approach. McGraw-
Hill, 3ª ed., 1995.
PRESSMAN, Roger. Software Engineering: A Practitioner's Approach, McGraw-
Hill, 5ª ed., 1999.
RAINER, R. Kelly (Rex Kelly). Introdução a Sistemas de Informação [recurso
eletrônico] /R. Kelly Rainer Jr e Casey G. Cegielski: [tradução Multinet Produtos] –
3 ed. – Rio de Janeiro: Elsevier, 2012.
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informação 3ª-
edição rev. e ampl. Rio de Janeiro: Brasport, 2005.
RUP, Rational Software Corporation. RUP - Rational Unified Process: Versão
2002.05.00.
SCOTT, Kendall. O Processo Unificado Explicado. Bookman, 2003.
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São Paulo: Pearson Prentice
Hall, 2011.
111
SOMMERVILLE, Ian; Engenharia de Software. Editora Pearson, 8ª edição 2007.
SILVA, Edna Lúcia, MENEZES, Estera Muszkat Metodologia da pesquisa e
elaboração de dissertação. – 4. ed. rev. atual. – Florianópolis: UFSC, 2005. 138p.
TERRIBILI, Armando Filho. Indicadores de gerenciamento de projetos:
monitoração contínua. M.Books, 2010.
TRENTIM, Mário Henrique. Gerenciamento de projetos: guia para as certificações
CAPM e PMP – São Paulo: Atlas, 2011.
TURBAN, Efraim. Administração de tecnologia da informação: teoria e
prática/Efraim Turban, R.Kelly Rainner, Richard E. Potter; tradução de Daniel
Vieira. Rio de Janeiro: Elsevier, 2005.
TURBAN, Efraim; JAMES, C. Vertherbe; EPHRAIM, Mclean. Tecnologia da
Informação para a Gestão/Transformando os Negócios da Economia Digital. 3 ed.
Bookman, 2007.
YIN, Robert K. Estudo de caso - planejamento e métodos. 2Ed. Porto Alegre:
Bookman, 2001.
WAZLAWICK, Raul Sidnei. Engenharia de Software: conceitos e práticas. Rio de
Janeiro: Elsevier, 2013.
![Hospital Universitário Virgen de las Nieves · Bibliografia ... Farmacêutico Hospitalar, encontram-se esquematizadas na figura 3. [1,2] Figura 2. Organograma dos Serviços Integrantes](https://img.document.onl/doc/110x75/5bf64d0309d3f2fc338d2c6a/hospital-universitario-virgen-de-las-nieves-bibliografia-farmaceutico.jpg)
