Gerenciamento de Projetos e Metodologia de SW

FIAP – FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

ALAN LUIS G. DE OLIVEIRA LUIS CARLOS M. DA SILVEIRA WALDIR C. CASTRO JUNIOR

GERENCIAMENTO DE PROJETOS - PMI A GESTÃO DE PROJETOS ALINHADA À METODOLOGIA DE

DESENVOLVIMENTO DE SOFTWARE

SÃO PAULO 2008

FIAP – Faculdade de Informática e Administração Paulista – Gerenciamento de Projetos

2

ALAN LUIS G. DE OLIVEIRA LUIS CARLOS M. DA SILVEIRA WALDIR C. CASTRO JUNIOR

GERENCIAMENTO DE PROJETOS - PMI A GESTÃO DE PROJETOS ALINHADA À METODOLOGIA DE

DESENVOLVIMENTO DE SOFTWARE

Monografia de pós-graduação como requisito para conclusão de curso

Área de conhecimento:

Gerenciamento de Projetos

Orientador: Roberto Pallesi -Msc. -PMP

SÃO PAULO 2008


3

Autores: ALAN LUIS G. DE OLIVEIRA LUIS CARLOS M. DA SILVEIRA WALDIR C. CASTRO JUNIOR Título: Gerenciamento de Projetos - PMI A Gestão de Projetos alinhada à metodologia de desenvolvimento de software Orientador: Roberto Pallesi -Msc. –PMP Avaliação: Nota: Comentário:

São Paulo, 11 de Novembro de 2008


4

RESUMO Este trabalho irá apresentar, sob o ponto de vista gerencial, metodologias, técnicas e ferramentas voltadas ao Gerenciamento de Projetos de Sistemas alinhado às práticas do PMI. Primeiramente serão abordados os temas mais relevantes sobre problemas encontrados nas organizações voltadas para projetos de sistemas. Em seguida, uma breve explicação sobre assuntos a pesquisar, um artigo de introdução ao PMI/PMBOK e um capítulo sobre integração de gestão PMI com a Metodologia de Desenvolvimento de Software, abordando as disciplinas do PMBOK e ferramentas, metodologias e técnicas relacionadas. Uma pesquisa de mercado voltada a um Modelo de Maturidade é sugerida como uma forma de atingir um nível máximo de excelência em Gerenciamento de Projetos. Por fim serão apresentadas a Conclusão, Considerações Finais e Referências Bibliográficas. Palavras-chave: Gerenciamento de Projetos, PMI, Metodologia de Gerenciamento de Software, Técnicas, Ferramentas, Desenvolvimento de Sistemas, Projetos de Sistemas.


5

ABSTRACT This course conclusion work will introduce, from the managerial point of view, methodologies, techniques and tools geared to the Project Management Systems and aligned to PMI practices. Firstly, the most relevant themes about problems found in organizations aimed at systems projects will be approached. Secondly, a brief explanation about research subjects, a PMI/PMBOK introductory article and a chapter related to the integration of PMI management with the Software Development Methodology, emphasizing the PMBOK tools, subjects, methodologies and techniques. Conducting a market research focused on a Maturity Model is suggested as a way to achieve the maximum excellence level in a Project Management. Finally, the conclusion, final considerations and bibliographic references will be presented. Key words: Project Management, PMI, Software Management Methodology, Techniques, Tools, Systems Development, Systems Projects.


6

SUMÁRIO 1 Objetivo ....................................................................................................................... 10

2 Problema: ..................................................................................................................... 11

2.1 Empresas não têm ou não usam metodologia .......................................................... 11

2.2 Muitos projetos não são concluídos ou são concluídos fora do prazo, escopo, custo ou qualidade. .................................................................................................................... 11

2.3 Empresas não querem investir com ferramentas, metodologia ou treinamento. ....... 11

2.4 Falta de conhecimento de metodologia ................................................................... 12

2.5 Empresas consideram o uso de metodologia como um procedimento burocrático ... 12

2.6 A metodologia existe, mas não é seguida................................................................ 12

2.7 Falta de comunicação ............................................................................................. 13

3 Assuntos para pesquisar ................................................................................................ 14

3.1 A metodologia ....................................................................................................... 14

3.2 A Gestão de projetos .............................................................................................. 14

3.3 Ferramentas ........................................................................................................... 14

3.4 Técnicas ................................................................................................................. 15

3.5 Processos ............................................................................................................... 15

4 Sobre o PMI/PMBOK .................................................................................................. 16

5 Integrando gestão PMI com Metodologia de Desenvolvimento ..................................... 17

5.1 Escopo ................................................................................................................... 17

5.1.1 UML ............................................................................................................... 17

5.1.2 DFD ................................................................................................................ 18

5.1.3 Prototipação .................................................................................................... 19

5.1.4 EAP ................................................................................................................ 21

5.1.5 JAD ................................................................................................................ 22

5.1.6 RUP ................................................................................................................ 23

5.1.7 5W2H ............................................................................................................. 24

5.1.8 Brainstorming ................................................................................................. 26

5.2 Tempo .................................................................................................................... 28

5.2.1 Cronogramas ................................................................................................... 28

5.2.2 PERT .............................................................................................................. 28

5.2.3 Diagrama de Precedência ................................................................................ 28

5.3 Custo ..................................................................................................................... 29

5.3.1 Estimativa Bottom-Up .................................................................................... 30

5.3.2 Análise de pontos de função ............................................................................ 30

5.4 Qualidade ............................................................................................................... 31

5.4.1 6-Sigma .......................................................................................................... 31

5.4.2 CMMi ............................................................................................................. 32

5.4.3 Teste ............................................................................................................... 32

5.4.4 ISO ................................................................................................................. 34

5.4.5 Prototipagem ................................................................................................... 36

5.5 Recursos Humanos ................................................................................................. 36

5.5.1 Treinamento .................................................................................................... 37

5.5.2 Recrutamento e seleção ................................................................................... 38

5.5.3 Campanhas de incentivo .................................................................................. 38

5.5.4 Plano de carreira ............................................................................................. 38

5.5.5 Matriz de Responsabilidade ............................................................................ 39

5.6 Comunicações ........................................................................................................ 39

5.6.1 Intranet ........................................................................................................... 40


7

5.6.2 Comunicadores ............................................................................................... 40

5.6.3 Banners e Cartazes .......................................................................................... 40

5.6.4 Sistemas colaborativos – Wiki......................................................................... 40

5.7 Riscos .................................................................................................................... 41

5.7.1 Matriz de Risco/Probabilidade/Plano de resposta ............................................ 41

5.7.2 Segurança de sistemas ..................................................................................... 44

5.7.3 Rastreabilidade ............................................................................................... 44

5.7.4 Sistemas de Backup ........................................................................................ 46

5.7.5 Segurança no desenvolvimento ....................................................................... 46

5.8 Aquisições ............................................................................................................. 47

5.8.1 Hardware ........................................................................................................ 47

5.8.2 UML - Diagrama de Implantação .................................................................... 48

6 Sugestão de Pesquisa de Mercado ................................................................................. 50

6.1 O modelo OPM3 .................................................................................................... 50

6.2 Principais benefícios do OPM3: ............................................................................. 51

6.3 Pesquisa para análise .............................................................................................. 51

6.3.1 Introdução ....................................................................................................... 51

6.3.2 Dados gerais da Organização .......................................................................... 53

6.3.3 Estrutura de Gerenciamento de Projetos da Organização ................................. 54

6.3.4 Organization Project Management Maturity Model (OPM3) - PMI ................. 56

6.3.5 Análise crítica do resultado da aplicação dos modelos ..................................... 58

7 Considerações Finais .................................................................................................... 60

8 Conclusão ..................................................................................................................... 61

9 Anexos ......................................................................................................................... 62

9.1 Questionário OPM3 ............................................................................................... 62

10 Referências Bibliográficas ............................................................................................ 80


8

ÍNDICE DE ILUSTRAÇÕES Ilustração 5.1.1-1 – Diagrama de Casos de Uso .................................................................... 18

Ilustração 5.1.2-1 - Diagrama de Fluxo de Dados (DFD) ...................................................... 19

Ilustração 5.1.3-1 - Exemplo de tela gerada por Prototipação ................................................ 20

Ilustração 5.1.4-1 - Exemplo de EAP - Treinamento em Gerenciamento de Projetos............ 22

Ilustração 5.1.5-1 - Estrutura do JAD ................................................................................... 23

Ilustração 5.1.6-1 - Fases, disciplinas e iterações do RUP ..................................................... 24

Ilustração 5.1.8-1 - Brainstorming - Geração de idéias .......................................................... 26

Ilustração 5.1.8-2 - Diagrama "Espinha de Peixe" ................................................................. 27

Ilustração 5.2.3-1 - Diagrama de Precedência ....................................................................... 29

Ilustração 5.4.4-1 - ISO ........................................................................................................ 35

Ilustração 5.6.4-1 - Exemplo de software colaborativo ......................................................... 41

Ilustração 5.7.1-1 - Processo de gerenciamento de riscos ...................................................... 42

Ilustração 5.8.2-1 - Exemplo de Diagrama de Implantação ................................................... 49

Ilustração 6.3.2-1 - Organograma da Companhia de Seguros para análise OPM3.................. 54

Ilustração 6.3.3-1 - Divisão de Tecnologia de da Informação e Operações - Pesquisa OPM3 54

Ilustração 6.3.4-1 - Resultado Final OPM3 ........................................................................... 56

Ilustração 6.3.4-2 - Resultado PPP – Projeto / Programa / Portfolio ...................................... 57

Ilustração 6.3.4-3 - Resultado SMCI – Standardize / Measure / Control / Improve ................ 57

Ilustração 6.3.4-4 - Resultado Detalhado PPP e SMCI .......................................................... 58


9

ÍNDICE DE TABELAS Tabela 5.1.7-1 - Método 5W2H ............................................................................................ 25

Tabela 5.5.5-1 - Matriz de Responsabilidades ....................................................................... 39

Tabela 5.7.1-1- APP (Análise Preliminar de Perigos) para um Projeto de Software ............. 43

Tabela 5.7.3-1 - Tipos de rastreabilidade .............................................................................. 45


10

1 OBJETIVO Este trabalho irá abordar o Gerenciamento de Projetos voltado ao desenvolvimento de software, apresentando as técnicas, ferramentas e metodologias de gestão necessárias para planejar, organizar, monitorar e controlar projetos de software. Pessoas, processos, problemas, métricas, cronogramas, custo e qualidade são exemplos de problemas relacionados a qualquer projeto de software. Em geral, o ser humano busca formas de minimizá-los utilizando diversas técnicas que, em geral, são estabelecidas por consenso e consagradas devido aos seus resultados. O gerenciamento de projetos não é uma necessidade surgida recentemente, temos na estória, só para exemplificar, grandes obras que datam de muitos séculos atrás: pirâmides, pontes, cidades, etc. Porém, a competitividade e a globalização exigem uma constante busca por melhores práticas de Gerenciamento de Projetos. O Project Management Institute (PMI) é uma organização referência mundial em Gerenciamento de Projetos, com várias representações no mundo. O PMI divulga as boas práticas de gerenciamento de projetos através do documento denominado “A Guide to the Project Management Body of Knowledge” (PMBOK). O PMBOK divide o Gerenciamento de Projetos em fluxos de processos nas áreas de Escopo, Tempo, Recursos Humanos, Comunicações, Riscos, Aquisições e Qualidade. O PMBOK é considerado como um guia de melhores práticas, detalhando “o que” é necessário para gerenciar projetos, mas sem entrar no mérito de “como” realizar os processos, ou “quais” ferramentas ou metodologias devem ser usadas. Projetos na área de desenvolvimento de software são considerados peculiares, ou seja, existem características muito diferentes se relacionarmos com projetos de outras áreas. Este trabalho tem o objetivo de apresentar como diversas técnicas, ferramentas e metodologias podem apoiar o gerenciamento de projetos de software com base nas áreas de conhecimento do PMBOK.


11

2 PROBLEMA:

2.1 Empresas não têm ou não usam metodologia São muitas as empresas de desenvolvimento de software que não utilizam ou desenvolvem uma metodologia para seus projetos e imaginam não necessitar. Por outro lado, também, existem empresas que criam sua própria metodologia de desenvolvimento e a consideram adequada aos seus projetos, sem buscar conhecimento de novos conceitos consagrados no mercado. Outras empresas a possuem, porém, não utilizam. É claro que, se não houver planejamento específico, organização de tarefas, direção eficaz e o controle de tudo isso, o resultado final do sistema não será satisfatório, e a manutenção do software será dificilmente sustentável. Com isso, o desenvolvimento de software fica em crise. Os custos de hardware caem enquanto os de software sobem rapidamente. Novas técnicas e novos métodos fazem-se necessários para controlar a complexidade inerente aos grandes sistemas de software. As técnicas de engenharia de software não são, universalmente, utilizadas, infelizmente, pois para o cliente o que importa é visualizar a tela pronta. E um processo de desenvolvimento de software com qualidade requer tempo que, muitas vezes, o cliente não está disposto a esperar.

2.2 Muitos projetos não são concluídos ou são concluídos fora do prazo, escopo, custo ou qualidade.

A utilização de métricas é fundamental na estimativa de resultados de um projeto. Podemos exemplificar um Projeto de Engenharia Civil, onde podemos utilizar métricas baseadas em muitos projetos semelhantes, obtendo uma precisão significativa entre as estimativas e o resultado final. Infelizmente a área de Engenharia de Software ainda não possui uma precisão semelhante, e estamos falando de uma área extremamente nova em comparação com a Engenharia Civil. Não obstante, existem métricas que auxiliam as estimativas de prazo, escopo, custo e qualidade de software. O maior problema está na utilização correta de métricas em cada projeto. Medir um software é uma tarefa extremamente difícil se considerarmos as diferenças significantes de tamanho, requisitos, complexidade, segurança, etc. Em um projeto o produto final é intangível.

“O estabelecimento geral de objetivos é suficiente para iniciar a escrita de programas – podemos fornecer os detalhes posteriormente”

Mitos do Software – Roger S. Pressman Além disso, muitos softwares desenvolvidos possuem um nível muito baixo de qualidade. Por isso, torna-se necessário o uso de uma metodologia de desenvolvimento de software para ajudar a qualificar o produto final neste processo tão difícil. Cada projeto tem suas peculiaridades, por isso, é importante fazer um planejamento antes de começar a desenvolver qualquer software. Para isso, identifique quais são os requisitos do software e, depois, escolha uma metodologia de desenvolvimento que, com certeza, o seu projeto terá uma qualidade superior a aquela que o seu cliente está esperando.

2.3 Empresas não querem investir com ferramentas, metodologia ou treinamento.

Investimentos são vistos como custos desnecessários, principalmente quando o retorno não é imediato. Infelizmente existem muitas empresas que ainda não tem uma visão clara dos benefícios e retorno de investimento para instituição á médio e longo prazos. Muitas empresas acham que somente com o conhecimento técnico que analistas desenvolvedores possuem será


12

garantida a qualidade necessárias para desenvolver um sistema, mas a realidade é muito diferente, pois o conhecimento é muito importante, porém sem um entendimento do negócio, planejamento, análise de requisitos, projetos, implementação, treinamento e implantação com certeza o produto terá um nível inferior aos padrões de mercados.

2.4 Falta de conhecimento de metodologia O investimento em metodologia está relacionado aos gastos com treinamento, esforço e motivação. Um profissional preparado deve ser contratado para treinar equipes preparadas, portanto, o nível da metodologia deve estar relacionado com a maturidade do nível de conhecimento da equipe.

2.5 Empresas consideram o uso de metodologia como um procedimento burocrático

O tempo sempre foi uma questão de ênfase em projetos de software. Burocracia pode ser vista por muitos como tempo perdido. A pressão dos clientes pela rápida entrega de um produto gera um certo abandono ao seguir rigorosamente a metodologia, desencorajando o acompanhamento de fluxos de processos, divisão de tarefas, documentação e outros processos considerados burocráticos.

2.6 A metodologia existe, mas não é seguida Além do cliente, o fornecedor também sente a necessidade de ver os primeiros resultados do novo produto. A visão do produto de software é inadequadamente considerada por muitos como os primeiros códigos de programação ou as primeiras tabelas de banco de dados, gerando uma certa euforia em codificar software sem seguir a metodologia, mesmo que ela exista, pois muitos imaginam que não será necessária ou não trará benefícios. Em um estudo, o Standish Group International divulgou, em abril de 2002, que grande percentual dos mais de US$ 250 bilhões gastos anualmente no desenvolvimento de aplicações na área de TI é desperdiçado porque as empresas falham na utilização de efetivas práticas de gerenciamento de projetos. Especificamente:

• 31% de todos os projetos são cancelados antes do seu término; • 88% dos projetos ultrapassam seu prazo, orçamento, ou ambos; • Os projetos ultrapassam, em média, 189% dos custos originalmente estimados; • Os projetos ultrapassam, em média, 222% do prazo originalmente estimados;

Em pesquisa do Meta Group em 2003, com executivos da área de TI, apontou os seguintes resultados:

• Somente 35% dos entrevistados têm um consistente processo de gerenciamento de portfolio;

• Somente 25% fazem estudo de viabilidade (business case) para os projetos de TI selecionados;

• 20 a 33% dos projetos falham no atendimento das expectativas das partes interessadas no projeto (stakeholders);

• As empresas que vêm adotando o gerenciamento efetivo de portfolio têm registrado uma melhora contínua de seus projetos, reduzindo seus custos em até 30%.

Muitas empresas que surgiram na era da informação precisam melhorar suas práticas em gerenciamento de projetos passando por uma mudança estrutural na organização.


13

2.7 Falta de comunicação Projetos envolvem pessoas. Os processos de gerenciamento fornecem ligações críticas entre pessoas e informações. O gerente de projetos deve gastar um tempo excessivo com comunicações para garantir o bom andamento do projeto. Não obstante isto não ocorre em diversas empresas, e os processos, ferramentas e técnicas de comunicação não são adequados ou nem ao menos utilizados ou incentivados. A comunicação dever ser vista como ferramenta estratégica para alcance de resultados.

“De acordo com PMI, gerente de projetos gastam em torno de 90% do seu tempo adquirindo ou comunicando as informações do projeto. O GP deve servir como um ponto focal para assegurar uma comunicação real, e de mão dupla entre o time de projeto e o cliente.”

Project Management Institute (PMI)


14

3 ASSUNTOS PARA PESQUISAR

3.1 A metodologia É a explicação minuciosa, detalhada, rigorosa e exata de toda ação desenvolvida no método (caminho) do trabalho de pesquisa, ou então as etapas a seguir num determinado processo. Tem como finalidade captar e analisar as características dos vários métodos disponíveis, avaliar suas capacidades, potencialidades, limitações ou distorções e criticar os pressupostos ou as implicações de sua utilização. Além de ser uma disciplina que estuda os métodos, a metodologia é também considerada uma forma de conduzir a pesquisa ou um conjunto de regras para ensino de ciência e arte. É a explicação do tipo de pesquisa, do instrumental utilizado (questionários, entrevistas, etcs), do tempo previsto, da equipe de pesquisadores e da divisão do trabalho, das formas de tabulação e tratamento dos dados, enfim, de tudo aquilo que se utilizou no trabalho de pesquisa. Em Gestão de Projetos, existe a metodologia geral e a metodologia detalhada. A metodologia pode ser dividida em vários métodos até chegar num determinado objetivo.

3.2 A Gestão de projetos É a aplicação de metodologia, conhecimentos técnicos, habilidades e ferramentas na condução das atividades de projeto, a fim de satisfazer seus requisitos. É um termo cujo uso cresce continuamente nas empresas nos dias de hoje. Existem também alguns outros termos equivalentes: gerenciamento de projetos ou administração de projetos. Para sabermos o que significa esta expressão é necessário antes conhecer o significado da palavra projeto. O PMBOK (Project Management Body of Knowledge), editado pelo PMI (Project Management Institute), define “Projeto” da seguinte forma:

“Um projeto é um esforço temporário realizado para criar um produto ou serviço único.”

O Eng. Luís César Menezes de Moura, Área de Gestão de Projetos, define projeto de forma mais precisa:

“É um empreendimento com características próprias, com início e término definidos, que é conduzido por pessoas para atingir objetivos estabelecidos dentro dos parâmetros de prazo, custo e especificações fixadas.”

3.3 Ferramentas É um utensílio, ou dispositivo, ou mecanismo físico ou intelectual utilizado por trabalhadores das mais diversas áreas. Inicialmente o termo era utilizado para designar objetos para uso doméstico ou industrial, este era constituído de ferro ou outro material (Ex.: Nylon, plástico, madeira, etc.), com vistas a realizar algum trabalho ou executar alguma função.


15

Em função do disposto acima, uma ferramenta pode ser definida como: “um dispositivo que forneça uma vantagem mecânica ou mental para facilitar a realização de tarefas diversas”. Exemplos de ferramentas: Ferramentas tecnológicas

• Módulo de software, etc. • Equipamento de usinagem, robô, martelo pneumático, broca pneumática, chave de fenda pneumática, etc.

• Instrumentos de medição, paquímetro, micrômetro, galvanômetro, multímetro, etc.

3.4 Técnicas É o procedimento ou o conjunto de procedimentos que têm como objetivo obter um determinado resultado, seja no campo da Ciência, da Tecnologia, das Artes ou em outra atividade. Estes procedimentos não excluem a criatividade como fator importante da técnica, como os conhecimentos técnicos e a capacidade de improvisação. A técnica não é privativa do homem, pois também se manifesta na atividade de todo ser vivo e responde a uma necessidade de sobrevivência. No animal, a técnica é característica de cada espécie. No ser humano, a técnica surge de sua relação com o meio e se caracteriza por ser consciente, reflexiva, inventiva e fundamentalmente individual. O indivíduo a aprende e a faz progredir. Só os humanos são capazes de construir, com a imaginação, algo que logo podem concretizar na realidade. Campos de ação: o campo da técnica e da Tecnologia responde ao interesse e à vontade do homem de transformar seu ambiente, buscando novas e melhores formas de satisfazer suas necessidades ou desejos. Esta atividade humana e seu produto resultante é o que chamamos técnica e tecnologia.

3.5 Processos É o conjunto seqüencial e peculiar de ações que objetivam atingir uma meta. Uma série de ações que geram um resultado. É usado para criar, inventar, projetar, transformar, produzir, controlar, manter e usar produtos ou sistemas. Na Engenharia de Software, processo é um conjunto de passos parcialmente ordenados, cujo objetivo é atingir uma meta: entregar um produto de software de maneira eficiente, previsível e que atinja as necessidades de negócio. Geralmente inclui análise de requisitos, programação, testes, entre outras tarefas.


16

4 SOBRE O PMI/PMBOK Fundado em 1969 por cinco voluntários e com sede na Filadélfia, Pensilvânia EUA, o Project Management Institute (PMI) é uma entidade mundial voltada ao Gerenciamento de Projetos de qualquer natureza. Com um crescimento significativo de associados, seminários e publicações ao longo das décadas, o PMI se tornou a principal entidade mundial sem fins lucrativos voltada ao gerenciamento de projetos como ciência e arte. Hoje o PMI possui muitos Grupos de Interesses e uma série de programas educacionais em gerenciamento de projetos. O PMI busca reúne e publica as melhores práticas em Gestão de Projetos, e a sua maior publicação é o documento “A Guide to the Project Management Body of Knowledge” (PMBOK). O PMBOK é dividido em áreas de conhecimento (Escopo, Integração, Tempo, Custos, Recursos Humanos, Comunicações, Riscos, Aquisições e Qualidade) que serão abordadas no capítulo 5, junto com técnicas, ferramentas e metodologias que podem ser utilizadas em cada uma delas.


17

5 INTEGRANDO GESTÃO PMI COM METODOLOGIA DE

DESENVOLVIMENTO

5.1 Escopo Escopo, do latim escopu (alvo, mira, fim, propósito, intento, objetivo), em Gerenciamento de Projetos pode ser definido como Escopo do Produto (características e funções que descrevem um produto, serviço ou resultado) ou Escopo do Projeto (o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas). O PMBOK define Gerenciamento de Escopo como processos necessários para garantir que o projeto inclua todo e somente o trabalho necessário para terminar um projeto com sucesso, portanto, a principal função do gerenciamento do escopo do projeto é controlar o que está e o que não está incluído no projeto. Os processos de Gerenciamento de Escopo incluem Planejamento, Definição do Escopo, Criação de EAP, Verificação e Controle do Escopo. Este capítulo tem o objetivo de apresentar ferramentas, técnicas e metodologias para auxiliar o Gerenciamento de Escopo.

5.1.1 UML Em projeto de sistemas, a modelagem de uma especificação deve possuir semântica, ou seja, de significado e estudo inteligível em todos os sentidos, e desta forma sendo interpretável tanto por humanos quanto para máquinas. A Unified Modeling Language (UML) é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de Orientação a Objetos. UML se tornou uma linguagem padrão de modelagem adotada internacionalmente pela indústria de Engenharia de Software. A UML surgiu da união de três metodologias de modelagem: o método de Booch, o método Object Modeling Technique (OMT) de Jacobson, e o método Object-Oriented Software Engineering (OOSE) de Rumbaugh. A modelagem UML é feita visualmente através de diagramas com o objetivo de fornecer múltiplas visões do sistema a ser modelado, analisando-o e modelando-o sob diversos aspectos, tornando-o simples.

“Coisas simples devem ser simples, coisas complexas devem ser possíveis” Allan Kay, cientista norte-americano da Xerox Corporation

O diagrama de Casos de Uso é a principal fonte para os demais diagramas, assim como o escopo fornece a idéia inicial do projeto. No diagrama de Casos de Uso podemos inserir e descrever os principais atores (usuários, outros sistemas ou até mesmo um hardware) que utilizarão o software, bem como os serviços (casos de uso), ou seja, as opções que o sistema irá disponibilizar. As relações entre atores e casos de uso são feitas através de setas. A figura abaixo representa um diagrama de Casos de Uso de administração de um banco:


18

Ilustração 5.1.1-1 – Diagrama de Casos de Uso Através da UML, podemos apresentar uma linguagem simples e de fácil compreensão para todos os Stakeholders.

5.1.2 DFD O Diagrama de Fluxo de Dados (DFD) é uma das principais ferramentas utilizadas em um projeto de sistemas de informação. O DFD é amplamente utilizado e conhecido na representação de escopo de projetos de sistemas, tornando se uma ferramenta importante no seu gerenciamento. O DFD é um diagrama gráfico, baseado em apenas quatro símbolos, que podem mostrar a estrutura do sistema através de processos, relações entre processos, depósito de dados e entidades externas. O DFD define entrada, processamento e saída de dados, além do limite do que pertence ao sistema e o que está fora dele. Ele representa para todos os Stakeholders, de maneira clara, o que o sistema faz e não como é feito.


19

Ilustração 5.1.2-1 - Diagrama de Fluxo de Dados (DFD)

5.1.3 Prototipação Na definição do escopo de um sistema, o cliente freqüentemente define um conjunto de objetivos gerais para o software, mas não identifica detalhadamente requisitos de entrada, processamento ou saída. Em outros casos, o desenvolvedor pode estar inseguro da eficiência do algorítmo, da adaptalidade de um sistema operacional ou da forma que a iteração homem/máquina deve assumir. Nestas, e em muitas outras situações, um paradigma de prototipação pode oferecer a melhor abordagem. O paradigma de prototipação auxilia todos os stakeholders a entenderem melhor o que deve ser construído quando os requisitos de escopo estão confusos. A prototipagem inicia quando se entendem os objetivos gerais do software, com as necessidades e as áreas que mais precisam de definições. A primeira iteração da prototipagem ocorre com a modelagem de um “projeto rápido”, que se concentra na apresentação daqueles aspectos do software que estarão visíveis para o cliente (Ex: layout de interface humana ou formato de saída de telas):


20

Ilustração 5.1.3-1 - Exemplo de tela gerada por Prototipação O “projeto rápido” leva à construção de um protótipo, que é implementado e depois avaliado pelo cliente. Demais iterações são feitas à medida que o protótipo é ajustado para satisfazer a necessidade do cliente, ajudando o desenvolvedor a entender melhor o que está sendo feito

“Quando seu cliente tiver uma necessidade razoável mas não tiver noção dos detalhes, desenvolva um protótipo como primeiro passo.”

Roger S. Pressman O modelo de prototipagem 1. Comunicação 2. Plano Rápido 3. Modelagem do Projeto Rápido 4. Construção do protótipo 5. Implantação, entrega e feedback

O modelo pode ter diversas iterações. O protótipo pode servir como “o primeiro sistema”, que agrade tanto clientes como desenvolvedores, pois o usuário tem uma visão do sistema real e os desenvolvedores conseguem construir algo imediatamente, mas ainda assim, a prototipagem pode ser problemática pelas seguintes razões:


21

• O cliente vê o que parece ser uma versão final do produto, ignorando que o protótipo apenas funcione precariamente.

• O desenvolvedor se limita na implementação a fim de conseguir rapidamente um protótipo executável, correndo o risco de tornar um protótipo pobre em versão de produção.

Não obstante os problemas, a prototipação pode ser efetiva no Gerenciamento do Escopo do Projeto, bem como em outras áreas relacionadas. O importante é definir as regras do jogo no início, isto é, cliente e desenvolvedor devem esta de acordo que o protótipo é construído para servir como um mecanismo de definição dos requisitos. Depois ele será descartado (pelo menos em parte), e o software real será submetido à engenharia com um olho na qualidade.

5.1.4 EAP Segundo o PMBOK, a Estrutura Analítica do Projeto (EAP) é uma decomposição hierárquica orientada a entregas do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do projeto e criar entregas necessárias.

“A EAP organiza e define o escopo atual do projeto” PMBOK

A EAP divide e representa visualmente as diversas entregas do projeto, tornando-o mais simples e gerenciável. A decomposição hierárquica é feita por níveis de detalhamento: os níveis descendentes são mais detalhados, até chegar ao nível mais baixo, chamado pacote de trabalho. Em engenharia de sistemas, uma EAP de um projeto semelhante pode ser utilizado para um novo projeto, principalmente se a organização adota padronização no ciclo de vida, ferramentas e métodos para a maioria dos projetos. Dividir para conquistar A decomposição divide as entregas até chegar no pacote de trabalho. Neste nível fica muito mais fácil estimar custo e tempo. Muitas vezes não é possível decompor uma entrega até o nível de detalhamento necessário, nestes casos a equipe espera até que a entrega esteja esclarecida e desenvolve os detalhes da EAP. Esta técnica de trabalho é chamada de planejamento em ondas sucessivas. A figura abaixo representa uma EAP para um projeto de “Treinamento em Gerenciamento de Projetos”


22

Ilustração 5.1.4-1 - Exemplo de EAP - Treinamento em Gerenciamento de Projetos Não é necessário que a EAP seja simétrica, ou seja, que todos os subprodutos sejam decompostos até o mesmo nível.

5.1.5 JAD Joint Appication Development (JAD) é um processo de gerenciamento que ajuda desenvolvedores de sistemas a trabalharem efetivamente com usuários no desenvolvimento de soluções tecnológicas. O JAD tem a proposta de definir, desenhar e monitorar uma solução até que ela esteja completa. As principais idéias do JAD

• Pessoas que fazem o trabalho têm o melhor entendimento do que deve ser feito. • Pessoas treinadas em tecnologia da informação têm o melhor entendimento das possibilidades de tal tecnologia utilizada.

• Sistemas de Informação e Processos de Negócios nunca estão separados • Os melhores sistemas são desenhados quando todos estes elementos trabalham em conjunto

JAD foi criada pela IBM, no Canadá e adaptada para o Brasil em 1982 para moderação de discussão de brainstorming, acelerando e consolidando o desenvolvimento de aplicações. O JAD substitui as entrevistas individuais por reuniões de grupo, onde participam representantes dos usuários e os representantes da informática. Essas sessões de trabalho são intensivas e levam, tipicamente, de um a três dias. O JAD também é chamado de Método de Projeto Interativo, a definição que reflete melhor propósito deste método é a seguinte: Método destinado a extrair informações de alta qualidade dos usuários, em curto espaço de tempo, através de reuniões estruturadas que buscam decisões por consenso. Benefícios


23

• Maior produtividade: Estudos relatam aumentos de 20 a 60% na produtividade, em relação aos métodos tradicionais (entrevista/questionário).

• Major qualidade: A maior interação entre usuário e analista de sistema proporcionar um sistema de alta qualidade

• Trabalho em equipe: Promove senso de cooperação, entendimento e trabalho em equipe, entre vários grupos de usuários e analistas. Os usuários e analistas fazem, de fato, os projetos juntos e se tomam confiantes do sucesso do desenvolvimento do sistema.

• Custos mais baixos de desenvolvimento e manutenção: Possibilita uma grande economia durante as fases técnicas de desenvolvimento e após o sistema ser entregue. Proporciona um projeto correto, desde o inicio, eliminando as despesas com manutenção e correção dos erros de desenvolvimento.

Decisões baseadas em consenso A forma mais produtiva de decisão em grupo é aquela obtida por consenso. Entendemos consenso não como a unanimidade de opiniões, mas, sim, que cada membro concorda que a solução encontrada é a melhor para o grupo e que é possível conviver com ela sem ferir convicções ou valores essenciais. Conduzir o grupo para soluções de consenso é a tarefa número um do facilitador. É uma tarefa bastante difícil, exigindo que o facilitador desenvolva habilidades especificas para alcançar este objetivo. Os papéis do JAD Gerente do projeto (coordenador), Facilitador, Patrocinador, Documentador, Observador, Indicador de assunto, Representante de usuários e Especialista Estrutura do JAD

Ilustração 5.1.5-1 - Estrutura do JAD

5.1.6 RUP O Rational Unified Process (RUP) foi criado pela Rational Software Corporation, como um processo de engenharia de software. O RUP é baseado em atribuição de tarefas e responsabilidades, e recomendado para grandes projetos, não obstante, o RUP é totalmente customizável. O RUP é um produto de apoio à gerência de projetos, integrado com diversas ferramentas de desenvolvimento, desta forma, podemos considerar o RUP no apoio da definição e controle do Escopo, tanto do produto como do processo.


24

O RUP possui elementos e fases: Elementos do RUP Os elementos do RUP são Papéis (comportamento e responsabilidades), Atividades (unidade de trabalho), Artefatos (trecho de informação produzido ou alterado), Fluxos de trabalho (seqüência do desenvolvimento da atividade) e Disciplinas (atividades relacionadas em um contexto) Fases do RUP Concepção (o que fazer), Elaboração (como fazer), Construção (desenvolver uma versão beta do produto) e Transição (desenvolver e entregar a versão final do produto) Abordagem iterativa Uma das principais características do RUP é a Abordagem Iterativa: cada fase do RUP passa por uma ou mais iterações para alcançar seus objetivos. O gráfico abaixo ilustra as iterações em cada fase e o nível de desenvolvimento em cada disciplina.

Ilustração 5.1.6-1 - Fases, disciplinas e iterações do RUP O ciclo de desenvolvimento termina com uma versão completa do produto. As fases definem como está o projeto, e as fases são definidas por riscos que estão sendo mitigados ou questões que precisam ser respondidas. O RUP pode garantir sucesso no gerenciamento de Escopo do Projeto e, conseqüentemente, influenciar no resultado final.

5.1.7 5W2H 52WH é uma ferramenta auxiliar na utilização do Plan-Do-Check-Point (PDCA), principalmente na fase de planejamento. A recomendação do uso do 5W2H não é nova. O


25

mais antigo registro encontrado nesse sentido está no "Tratado sobre Oratória" escrito por Marcus Fabius Quintilianus (entre os anos 30 e 100 d.C.). Esse tratado se refere a textos para discursos. Quintilianus observava que, para se obter a compreensão do público sobre qualquer tema era necessária a utilização do hexágono de perguntas (e respostas) contido em seu tratado. As sete perguntas básicas a serem respondidas para o êxito da comunicação eram: o que, quem, quando, onde, quando, por quê, como e quanto custa.

Método dos 5W2H

5W

What O Que? Que ação será executada?

Who Quem? Quem irá executar/participar da ação?

Where Onde? Onde será executada a ação?

When Quando? Quando a ação será executada?

Why Por Quê? Por que a ação será executada?

2H How Como? Como será executada a ação?

How much Quanto custa?

Quanto custa para executar a ação?

Tabela 5.1.7-1 - Método 5W2H A planilha 5W2H é muito usada no Planejamento de empresas, especialmente no desdobramento da visão de futuro de longo alcance. Para transformar a visão em ações diretamente executáveis que transformam a visão em uma realidade aplica-se o método PDCA. Em escopo no desenvolvimento de software podemos utilizar o método 5W2H para fazer as perguntas necessárias ao cliente que é uma técnica baseada em estudos de gargalos em engenharia de processos. As mudanças não podem deixar de ocorrer só porque um projeto foi iniciado. Deve-se controlar o que mudou no projeto e em RUP utiliza-se a gerência de mudança unificada. Veja os 5 aspectos de um sistema de gerência de controle aplicado a desenvolvimento de software:

• Gerência de requisição de mudança • Rastreamento de mudança e versões (5W2H) • Relatórios de status de configuração • Produção do software • Gerência de configuração

Gerência de requisição de mudança Endereça ao pessoal responsável pelo produto, o impacto da mudança de um requerimento para o produto final. Trata do responsável pela mudança. Normalmente a responsabilidade de um staff de controladores de mudanças, como analistas de sistemas. Gerência de configuração As configurações, rotulações, versionamento de cada entidade do sistema, de forma a construir um produto coeso. Gerência de status de configuração


26

Mensuramento do controle de defeitos, falhas e correções de cada entidade do sistema. Este é um fator de grande influência na parte de métricas. Produção de Software Automatização da construção do release final: compilação, linkedição, testes sistêmicos, versionamento e empacotamento para distribuição. Rastreamento de mudanças e versões Define o que mudou (What), o por que da modificação (Why) e quando mudou (When). Trata da entidade que está mudando, e está ligado a gerência de requisição de mudança. Versionamento é o asseguramento que estão sendo selecionados as versões corretas de cada entidade para que a mudança requerida seja efetuada, de forma a manter um release estável.

5.1.8 Brainstorming Basicamente, é uma técnica que muitos profissionais usam, e podem até fazê-la diferente do proposto a seguir, mas com toda a certeza os princípios devem são mantidos. Brainstorm é uma palavra em inglês cuja tradução é “tempestade mental”. É uma metodologia de exploração de idéias, visando a obtenção das melhores soluções de um grupo de pessoas. O Brainstorm pode ser mencionado como “chuva de palpites”, mas ele é muito mais que isso. Falando de forma simplória, ele é um bate-papo direcionado, que pode favorecer ou não o surgimento de idéias novas, que ajudem na solução de problemas ou situações. O Brainstorm não é espontâneo. É uma técnica cujo princípio básico reside na ausência de julgamentos ou de autocríticas

Ilustração 5.1.8-1 - Brainstorming - Geração de idéias A partir do Brainstorm, chegamos à idéias de qualidade, ou até à solução de uma situação ou problema. Além disso, traz a vantagem de ter seu mérito distribuído, pois é o resultado do trabalho de toda uma equipe. Como aplicar o Brainstorm? Uma solução muito simples e eficaz é o diagrama de causa e efeito, ou se preferir “diagrama de espinha de peixe”. Ele é uma forma visual de levantamento de causas e efeitos, que combinados com os princípios do Brainstorm, tem ótimos resultados.


27

Ilustração 5.1.8-2 - Diagrama "Espinha de Peixe" Podemos organizar num quadro um diagrama como o de cima e, em seguida, um grupo de pessoas levanta quais são os fatores ou as espinhas do peixe que levam ao seu objetivo. Usando ainda a técnica do Brainstorm, elas levantam parâmetros que influenciam nessas espinhas de forma organizada e clara. Ao final, usando um quadro branco e alguns post-it’s, têm-se de forma visual todo um diagrama de causa e efeito. Tornando muito mais fácil trabalhar para alcançar os objetivos. Há três principais partes no brainstorming:

• Encontrar os fatos • Geração da idéia • Encontrar a solução

Da busca dos fatos na resolução de um problema existem duas sub partes:

• Definição do problema • Preparação.

Inicialmente, define-se o problema que poderá ser subdividido em várias partes. A técnica de Brainstorming funciona para problemas que têm muitas soluções possíveis tal como a geração de idéias para o seu desenho. Depois é necessário colher toda a informação que pode relacionar-se com o problema. “De acordo com Osborn, o humano é capaz tanto do julgamento como da criatividade. Embora, a maioria da educação nos ensine apenas a usar o julgamento. Nós apressamos o julgamento. Quando praticamos o atraso do julgamento, permitimo-nos a nós próprios usar a nossa mente criativa para gerar idéias sem as julgar. Primeiro, não parece natural, mas depois tem as suas recompensas.” Brainstorming é muito importante para reunir um colegiado e aplicar a técnica, podendo obter as informações necessárias na análise e gerência de requisitos para o desenvolvimento de software.


28

5.2 Tempo Projetos são empreendimentos temporários, portanto, a idéia de tempo é inerente à própria definição de um projeto. Um projeto pode durar pouco ou muito tempo, devido suas peculiaridades como tamanho e complexidade, não obstante, um projeto precisa ser finalizado. O tempo é um dos fatores mais críticos de um projeto, que pode gerar muitos conflitos e problemas durante o seu ciclo de vida. Para evitar problemas com atrasos, um bom planejamento do tempo do projeto melhora a previsão do seu término. “O gerenciamento de tempo do projeto inclui processos necessários para realizar o termino

do projeto no prazo” PMBOK

Em Gerenciamento de Tempo, o PMBOK define seis processos: Definição das atividades, seqüenciamento das atividades, estimativa de recursos das atividades, estimativa de duração das atividades, desenvolvimento de cronograma e controle do cronograma. Neste capítulo, o objetivo é fornecer uma visão das principais ferramentas e metodologias para o gerenciamento de tempo do projeto.

5.2.1 Cronogramas O cronograma é uma das principais ferramentas para gerenciamento de tempo do projeto. Com o escopo definido através de uma EAP, os pacotes de trabalho são analisados. Identificam-se então as atividades, suas dependências e recursos necessários. Analisando um pacote de trabalho podemos estimar sua duração de forma mais precisa e gerar um cronograma com prazos mais realistas. Um cronograma pode ser apresentado de diversas formas: Tabular, Diagrama de Rede, Gantt, Gráfico de Milestones.

5.2.2 PERT Program Evalution and Review Tecnique (PERT) é um esquema de apresentação das atividades do projeto e dos relacionamentos lógicos (dependências). O PERT foi originalmente introduzido pela marinha dos EUA em 1957 quando se desenvolvia o míssil balístico intercontinental Polaris. O método do PERT foi empregado para simulação do trabalho necessário para a conclusão do projeto através da criação de um diagrama de precedência e redes lógicas de seqüências de eventos dependentes. Qualquer que seja o diagrama de rede a ser utilizado, ele tenha a capacidade de apresentar todas as ligações necessárias para execução dos produtos e serviços parciais e totais, garantindo que toda atividade tenha sempre uma entidade predecessora e sempre uma entidade sucessora.

5.2.3 Diagrama de Precedência O método de diagramação de precedência é utilizado, nos dias atuais, pela maioria do programas de software de gerenciamento de projetos. Os diagramas de prioridades ligam as atividades com setas que apresentam as dependências entre as atividades. O método é chamado atividade em nó (AON – Activity On Node ). A informação da atividade é escrita nos nós, com as setas ligando os nós, ou atividades dependentes. Os nós são exibidos como retângulos, nos quais você pode inserir a quantidade necessária de informações sobre a atividade. A informação mínima resume-se no nome da atividade. Algumas vezes, os nós são exibidos com o nome da atividade, o número da atividade, datas de início e fim, datas de


29

vencimento, folga (margem de tempo) e outras informações. O Diagrama de Precedência usa apenas estimativa de tempo para especificar a duração.

Ilustração 5.2.3-1 - Diagrama de Precedência O Diagrama de Precedência é discriminado ainda mais por quatro tipos de relacionamentos lógicos, o PMBOK chama esses relacionamentos de dependências ou relações de prioridades. Essas relações são utilizadas no Microsoft Project ou qualquer outro software semelhante de gerenciamento de projetos. Existem quatros tipos de dependências:

• Fim-Início – Esse é o relacionamento lógico mais usado, em que a atividade independente, ou atividade de, deve ser terminar antes de iniciar a atividade dependente ou atividade até.

• Início-Fim – No relacionamento início-fim, a atividade independente deve iniciar antes de terminar a atividade dependente. Esse relacionamento lógico é usado ocasionalmente.

• Fim-Fim – Nesse relacionamento, a atividade independente deve terminar antes da dependente.

• Início-Início – Nesse relacionamento, a atividade independente deve iniciar antes da atividade dependente.

5.3 Custo Custo é a capacidade de capital necessária para realizar as atividades do projeto. O gerente de projetos utiliza processos, ferramentas e técnicas para planejar, estimar, orçamentar e controlar os custos. Custo é um dos fatores mais críticos do gerenciamento de projetos, determinante para o seu sucesso. O custo de uma atividade é calculado como a soma dos custos dos recursos envolvidos na atividade com os custos indiretos. “O esforço de planejamento de gerenciamento de custos ocorre no início do planejamento do projeto e define a estrutura de cada um dos processos de gerenciamento de custos, de forma

que o desempenho nos processos seja eficiente e coordenado.” PMBOK

Este capítulo tem o objetivo de fornecer uma visão sobre Estimativa Bottom-Up e Análise por Pontos de Função.


30

5.3.1 Estimativa Bottom-Up Com uma EAP bem estruturada, temos uma visão plena de pacote de trabalho e recursos relacionados em cada atividade. Ao consolidar os custos de cada pacote individual podemos estimar o custo total do projeto, através da multiplicação do custo do recurso pela quantidade necessária deste recurso em cada pacote de trabalho.

5.3.2 Análise de pontos de função Um dos maiores desafios dos gerentes de projetos é a medição de um sistema. Uma das técnicas de apoio à medição é a análise de pontos de função, que estabelece uma medida independente da linguagem de programação ou da tecnologia utilizada na implementação. Principais objetivos da Análise de Pontos de função:

• medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho e seu custo;

• medir projetos de desenvolvimento e manutenção de software, independentemente da tecnologia utilizada na implementação, de forma a acompanhar sua evolução;

• medir a funcionalidade recebida pelo usuário, após o projeto de software, de forma verificar seu tamanho e seu custo, comparando-os com o que foi originalmente estimado;

As organizações podem aplicar a Análise de Pontos por Função como:

• uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da contagem de todos os Pontos por Função incluídos no pacote;

• uma ferramenta para apoiar a análise da qualidade e da produtividade; • um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e manutenção de software;

• um fator de normalização para comparação de software. Pontos de função medem o tamanho do que o software faz, ao invés de como ele é desenvolvido e implementado. Neste conceito, a análise por pontos de função utiliza as seguintes características gerais do sistema: 1. Comunicação de Dados 2. Processamento Distribuído de Dados 3. Desempenho 4. Configuração Intensamente Utilizada 5. Taxa de Transação 6. Entrada de Dados On-Line 7. Eficiência do Usuário Final 8. Atualização On-Line 9. Processamento Complexo 10. Reutilização 11. Facilidade de Instalação 12. Facilidade de Operação 13. Múltiplas Localidades 14. Facilidade de Alteração

Em desenvolvimento de software com gerenciamento de projetos e necessário que seja analisada a redução de custos no desenvolvimento:


31

• Adequando os requisitos de sistema as necessidades dos envolvidos (stakeholders), delimitando o escopo de desenvolvimento.

• Medindo o impacto das alterações, gerando rastreabilidade no processo de desenvolvimento.

• Gerando insumos antecipados para as fases de planejamento, teste, documentação e treinamento.

• Identificando, controlando e gerenciando mudanças nos projetos de software. • Medição quantitativamente dos resultados. • Métricas de produtividade (horas-homem/FPA, Use-case point, KLOC). • Métricas de melhoria de processo (produtos não conforme, auditorias, verificações). • Métricas de qualidade (quantidade de erros, cobertura de teste, retrabalhos, etc.)

5.4 Qualidade No conceito de projetos de software, o principal significado de qualidade é “conformidade com as exigências do cliente”, “relação custo/benefício” e “adequação ao uso”. A qualidade de um produto ou serviço pode ser olhada de duas ópticas: a do fornecedor e a do cliente. Do ponto de vista do fornecedor, a qualidade se associa à concepção e produção de um produto que vá ao encontro das necessidades do cliente. Do ponto de vista do cliente, a qualidade está associada ao valor e à utilidade reconhecidas ao produto, estando em alguns casos ligada ao preço. Se um projeto é entregue dentro do custo e prazo, mas não possui os requisitos de qualidade exigidos pelo cliente, podemos considerar que o projeto não obteve sucesso.

“Os processos de gerenciamento de qualidade do projeto incluem todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização.”

PMBOK

O PMBOK define os processos de planejamento, garantia e controle da qualidade.

5.4.1 6-Sigma O 6 Sigma consiste na aplicação de métodos estatísticos a processos empresariais para eliminar defeitos. Originalmente definido pela Motorola, tem o objetivo de reduzir os níveis de defeitos abaixo de 3.4 defeitos por milhão de oportunidades. Benefícios do 6-Sigma:

• maior eficiência operacional; • redução de custos; • melhoria da qualidade; • aumento da satisfação dos clientes; • aumento da lucratividade;

Uma pesquisa de satisfação de qualidade do cliente é essencial para determinar a aplicação de 6-Sigma em uma organização, que deve ter uma estrutura e cultura de alta qualidade e estilo de gestão. Baseado no conhecimento selecionam-se e capacitam-se especialistas (masterblack-belts, black-belts, green-belts) que serão os agentes de mudanças responsáveis pela implantação junto com as equipes.


32

Qual é o principal trunfo do 6-Sigma? Para alguns, seu grande trunfo é estabelecer uma meta muito específica: 3,4 defeitos por milhão de oportunidades de ocorrerem defeitos. Para outros, como Michael Hammer, especialista em reengenharia e da gestão por processos, o grande trunfo do 6-Sigma está na disciplina que ele propõe, que permite lidar com a complexidade das operações comerciais. Diz Hammer: "Diversos fatores podem causar problemas de qualidade: uma máquina mal calibrada, matéria-prima fora das especificações, operadores que realizam a tarefa de forma incorreta. Em vez de propor soluções aleatórias, as empresas adeptas do 6-Sigma determinam a causa do problema e aplicam apenas aquelas soluções consideradas adequadas". Ele acrescenta que o 6-Sigma é mais gerenciável que outras ferramentas.

5.4.2 CMMi CMMI - Capability Maturity Model Integration é um modelo de qualidade mantido pelo SEI - Software Engineering Institute. Podemos fizer que o CMMI é um framework para melhoria de processos de software. Suas PA’s abrangem todo processo de desenvolvimento melhorando drasticamente a qualidade dos projetos. Ele diz o que fazer, mas não como fazer. Os processos (negócio) e o desenvolvimento de soluções com engenharia de software são o foco do CMMI. Pela sua estrutura e abrangência poderíamos até dizer que o CMMI “poderia” ser utilizado para outros negócios que não “Software”. Ou seja, várias de suas práticas podem ser utilizadas em projetos de construção civil, administração, marketing e diversos outros. O CMMI ajuda à organização aprimorar seus processos e se tornar mais madura e eficiente. Os modelos de capacidade e maturidade atingido em seus níveis ajudam a prever o comportamento de um determinado processo diante do cenário ao qual o projeto se encontra. Em resumo, da pra saber se o projeto vai ou não dar certo. Para a organização, ele ajuda a mesma a conhecer a si própria e sua performance. Desta forma podemos montar um plano de ação para atingir as metas da organização. Quando entendido e conhecido, o CMMI ajuda as pessoas a identificar o que realmente tem valor e focar. Com isso, otimizam-se os processos e melhora a rentabilidade da organização. Em resumo, o CMMI é um modelo para a melhoria contínua de processos que “amadurece” as organizações e torna-as mais competitivas.

5.4.3 Teste O teste de software é realizado de acordo com processo de software definido para o projeto. A técnica de controle de qualidade de software (checagem) implica na realização de uma comparação entre os resultados do teste e os resultados esperados. Os resultados esperados são determinados manualmente ou através de ferramentas de apoio aos testes, sempre a partir das especificações. Os termos associados a testes são verificação e validação. Verificação Refere-se à garantia da corretura dos resultados da fase com relação ao especificado para esta fase do ciclo de desenvolvimento de software. (ex. ortografia, sintaxe, semântica, consistência com outros artefatos. Validação Envolve em checar o software contra os seus requisitos de modo a assegurar que implementa exatamente todos os requisitos especificados.


33

É necessário que seja efetuado um plano de teste contendo:

• A abordagem geral de verificação e testes. • As responsabilidades da organização desenvolvedora, das contratadas, dos clientes e dos usuários finais, quando apropriado.

• Facilidades, equipamentos, ferramentas e requisitos de apoio aos testes • Critério de aceitação

São divididos em níveis de testes como:

• Teste de unidade • Teste de integração • Teste de desempenho, capacidade e carga • Teste de utilizabilidade • Teste de sistema • Teste de aceitação

Estratégias de testes são divididas em: • Funcional – caixa preta • Estrutural, estrutura do código – caixa branca ou caixa aberta • Estrutural, estrutura de dados • Auto-teste baseado em assertivas executáveis

Cobertura de teste são divididas em:

• Cobertura de comandos • Cobertura de caminhos • Cobertura de arestas de decisão • Cobertura de itens ( ex: mensagens, diálogos ícones, etc ) • Cobertura de interface do usuário • Perfis de uso

Medição e análise servem para determinar a funcionalidade e qualidade dos produtos de software como:

• Número, tipos e severidade dos defeitos identificados nos artefatos de software, acompanhados de forma cumulativa e por fases.

• Requisitos alocados, resumidos por categoria (por exemplo segurança, configuração de sistema, desempenho e confiabilidade) e rastreados em relação aos requisitos de software e aos casos de teste de sistemas.

A garantia de qualidade do Software revê e/ou audita as atividades e artefatos, bem como relata seus resultados. Os requisitos de software são revisados para garantir que são:

• Completos • Corretos • Consistentes • Adequados • Mensuráveis • Viáveis • Testáveis


34

• Os critérios de prontidão e conclusão para cada tarefa de engenharia de software são satisfeitos.

• Os produtos de software estão de acordo com os padrões e requisitos especificados • Os testes requeridos são realizados. • Os testes de sistemas e de aceitação do software são realizados de acordo com os planos e procedimentos documentados.

• Os testes satisfazem seus critérios de aceitação, tal como documentado no plano de teste de software.

• Os testes são completados e registrados satisfatoriamente. • Os problemas e defeitos detectados são documentados, acompanhados e abordados. • É realizado o rastreamento dos requisitos alocados, considerando os requisitos de software, o design, o código, a documentação externa e os casos teste.

• A documentação usada para operar e manter o software é confrontada com baseline do software e com quaisquer requisitos alocados aplicáveis, antes do artefato ser distribuído para os clientes e usuários finais.

Ferramentas de suporte ao testes

• Ferramentas de gerência de testes; • Geradores de casos de testes; • Controladores de teste (test-drivers); • Analisadores de perfis de teste; • Depuradores simbólicos; • Analisadores de cobertura de testes.

Produtos gerenciados e controlados

• Ferramentas usadas para desenvolver e manter os produtos de software; • Documentação de requisitos de software; • Documentação do design de software; • Código; • Documentação do design de software; e casos de teste; • Planos, procedimentos e caso de testes; • Resultados dos Testes; • Documentação de rastreamento dos requisitos alocados através dos requisitos de software, do design, do código, da documentação externa e dos casos de teste.

Em desenvolvimento de software com gerenciamento de projeto a prevenção de defeitos é fundamental para identificar a causa de defeitos e prevenir suas recorrências. Reduz-se assim o volume de defeitos acidentalmente inseridos nos artefatos de software. Isto contribui para a redução de re-trabalho e custos associados e contribui, ainda, para uma melhoria da produtividade e da qualidade efetiva dos produtos desenvolvidos.

5.4.4 ISO • Os conceitos envolvidos na série ISO 9000:2000 aplicam-se a organizações, de todos os tipos, tamanhos e segmentos.

• Ênfase na gestão da qualidade: “É melhor prevenir do que remediar”, ou seja, é melhor prevenir falhas e corrigir a causa dos problemas do que tratar seus sintomas.

• Objetivo: Implementação e operação de um Sistema de Gestão da Qualidade (SGQ) eficaz.


35

• 1987: 1a versão • 1994: primeira revisão, com o objetivo de melhorar os requisitos e enfatizar a natureza preventiva da garantia da qualidade.

• 2000: segunda revisão, detendo mais o foco no cliente e mais adequada aos princípios de Controle da Qualidade Total.

• 2005: revisões pontuais (apenas ISO 9000).

Para Fins de Gestão: • NBR ISO 9000-1 • NBR ISO 9000-2 • NBR ISO 9000-3 (Software)

Para Fins Contratuais • NBR ISO 9001 • NBR ISO 9002 • NBR ISO 9003

Ilustração 5.4.4-1 - ISO Princípios de Gestão da Qualidade

• Formam a base para as normas ISO 9000:2000. • Utilizados pela alta direção para conduzir a organização à melhoria do seu desempenho.

São eles: • Foco no cliente: Organizações dependem de seus clientes e, portanto, é recomendável que atendam às necessidade atuais e futuras do cliente, aos seus requisitos, e procurem exceder as suas expectativas.

• Liderança: Líderes estabelecem a unidade de propósito e o rumo da organização. Convém que criem e mantenham um ambiente interno, no qual as pessoas possam estar totalmente envolvidas no propósito de atingir os objetivos da organização.


36

• Envolvimento de pessoas: Pessoas de todos os níveis são a essência de uma organização e seu total envolvimento possibilita que as suas habilidades sejam usadas para o benefício da organização.

• Abordagem de processo: Um resultado desejado é alcançado mais eficientemente quando as atividades e os recursos relacionados são gerenciados como um processo.

• Abordagem sistêmica para a gestão: Identificar, entender e gerenciar os processos inter-relacionados como um sistema contribui para a eficácia e eficiência da organização no sentido desta atingir os seus objetivos.

• Melhoria contínua: Convém que a melhoria contínua do desempenho global da organização seja seu objetivo permanente.

• Abordagem factual para tomada de decisão: Decisões eficazes são baseadas na análise de dados e informações.

• Benefícios mútuos nas relações com os fornecedores: Uma organização e seus fornecedores são interdependentes e uma relação de benefícios mútuos aumenta a capacidade de ambos em agregar valor.

• Abordagem de SGQ: incentiva as organizações a analisar os requisitos do cliente, definir os processos que contribuem para a obtenção de um produto aceitável para o cliente e manter esses processos sob controle.

• Um SGQ fornece a confiança à organização e a seus clientes de que ela é capaz de fornecer produtos que atendam aos requisitos do cliente de forma consistente.

• Abordagem de SGQ incentiva as organizações a analisar os requisitos do cliente, definir os processos que contribuem para a obtenção de um produto aceitável para o cliente e manter esses processos sob controle.

• Um SGQ fornece a confiança à organização e a seus clientes de que ela é capaz de fornecer produtos que atendam aos requisitos do cliente de forma consistente.

5.4.5 Prototipagem Em projetos de sistemas, normalmente o cliente apenas vê o produto final ao término do desenvolvimento, e muitas vezes pode revelar algo que ele não esperava, pondo em risco a satisfação do cliente e jogando fora todo o trabalho anterior. Todo tipo de prévia nos ajuda a ter uma visão do resultado final antes de obtê-lo. Uma importante técnica iterativa de desenvolvimento é a prototipagem, que normalmente envolve a criação de um modelo ou versão preliminar de um grande sistema, ou uma versão reduzida ou em pequena escala do sistema completo. Um protótipo pode ser desenvolvido para apresentar formatos preliminares de relatórios e telas de entrada utilizando um programa gráfico. Depois de apresentados e revisados, eles servem de modelo para o desenvolvimento do sistema real. O primeiro modelo é criado para formar os modelos de segunda e terceira gerações, e assim por diante até que o sistema esteja desenvolvido. Etapas da técnica de prototipagem:

• Avaliar, analisar e definir o problema • Construir a versão inicial do protótipo do sistema • Colocar o protótipo em operação • Refinar e modificar o protótipo

5.5 Recursos Humanos


37

Gerenciar projetos é gerenciar equipes. Grande parte do tempo do gerenciamento é gasto coordenando pessoas. Toda a equipe de gerenciamento é responsável pelo sucesso ou fracasso do projeto assim como seus stakeholders. A equipe do projeto é composta por pessoas com funções e responsabilidades atribuídas para o término do projeto, portanto, o gerenciamento eficaz de Recursos Humanos no projeto traz benefícios em todas as outras áreas de conhecimento. “O envolvimento dos membros da equipe desde o início acrescenta especialização durante o

processo de planejamento e fortalece o compromisso com o projeto.” PMBOK

O PMBOK define os seguintes processos no gerenciamento de recursos humanos:

• Planejamento de Recursos Humanos • Contratar ou mobilizar a equipe do projeto • Desenvolver a equipe do projeto • Gerenciar a equipe do projeto

Neste sub-capítulo, são apresentadas algumas técnicas e ferramentas que podem beneficiar o gerenciamento de Recursos Humanos:

5.5.1 Treinamento Treinamento é um processo de assimilação cultural em curto prazo, que objetiva repassar ou reciclar conhecimentos, habilidades ou atitudes relacionados diretamente à execução de tarefas ou à sua otimização no trabalho. Qual o objetivo do Treinamento? O treinamento tem por finalidade ajudar a empresa a alcançar os objetivos, proporcionando oportunidade aos funcionários de todos os níveis para obterem o CHA (Conhecimentos, Habilidades e Atitudes), modificando a bagagem particular de cada um. Resultados esperados em um treinamento:

• Aumento da produtividade • Melhoria na qualidade dos resultados • Redução de custos, re-trabalho, etc. • Otimização da eficiência • Aumento das habilidades • Redução do índice de acidentes • Melhoria do clima organizacional • Aumento da motivação pessoal • Redução do absenteísmo • Redução do turn-over

Todos estes resultados influenciam fortemente em todos os tipos de projetos. Um ótimo planejamento de treinamentos pode ser um fator chave para o sucesso de um projeto de sistemas.


38

5.5.2 Recrutamento e seleção Obter recursos humanos para o término do projeto não é uma tarefa simples. Muitas vezes é necessário medir a quantidade de esforço em uma tarefa que não temos o pleno conhecimento. Contratar recursos em medidas erradas pode trazer riscos para o projeto: Muitos recursos para poucas atividades pode influenciar no estouro de orçamento, por outro lado, poucos recursos para muitas atividades, ou atividades muito complexas, pode significar em baixo desempenho ou estouro do prazo de entrega do projeto. É importante que a equipe de gerenciamento de projeto tenha controle sobre os membros da equipe selecionados para o projeto. Assim como todo projeto é único, o processo de recrutamento e seleção pode ser peculiar em cada projeto, mesmo em projetos similares ou no mesmo cliente. As peculiaridades podem envolver disponibilidade, horários, localização, experiência, nível de conhecimento, formação e outros fatores relacionados. Primeiro é feito um mapeamento de quais fatores são mais importantes para o projeto. Projetos grandes e de maior complexibilidade exigem muito mais sobre esses parâmetros, tornando complexo o processo de contratação. Também é exigida a capacidade de negociação. O gerente deve ter a capacidade de negociar recursos com os gerentes funcionais, garantindo que receberá adequadamente pessoas competentes no prazo necessário e que os membros da equipe do projeto poderão trabalhar no projeto até que as tarefas sob sua responsabilidade estejam terminadas. Um fator importante é a cultura da organização e seus recursos disponíveis. Muitas vezes gerentes de projetos contratam recursos de fora mesmo com a disponibilidade de recursos internos da organização. Boa comunicação e conhecimento da estrutura organizacional são fundamentais neste sentido.

5.5.3 Campanhas de incentivo Campanhas de incentivo são ações de motivação de equipe, que podem ser aplicadas em qualquer segmento da empresa ou do projeto, oferecendo recompensa e prêmios fortemente desejados. Os projetos podem estar divididos em metas ou marcos de projetos, ou seja, um determinado ponto para se alcançar, que determina passos no seu andamento. Atingir metas é fundamental. Recompensar um esforço pode aumentar significativamente o nível de satisfação da equipe do projeto, entre muitos outros benefícios. As metas podem ser definidas em números, tamanhos, valores, percentuais, etc. E podem estar divididas por equipes. Em um projeto com sub-equipes pode haver metas para cada uma delas, e valores de bônus para as equipes que conseguirem alcançar tais metas. Os bônus podem ser valores em dinheiro, recompensas com horas de trabalho, jantares, vale-presentes e até viagens. Vale ressaltar que a equipe de gerenciamento de projeto deve tomar cuidado para não transformar campanhas de incentivo em hostis “campos da batalha”, todas as medidas e processos devem ser feitos com o extremo cuidado e uma empresa de consultoria pode ser contratada como forma de apoio.

5.5.4 Plano de carreira O plano de carreira é a série de passos que você deve tomar para atingir uma meta de carreira que tenha proposto para si mesmo. Esses passos envolvem estratégia, e todas as metas de carreira para atingi-las são peculiares de um indivíduo para o outro. Podemos imaginar que estamos em um ponto “A” e queremos chegar no ponto “D”, e não imaginamos todas as pedras no caminho que estão nos pontos “B” e “C”, portanto, uma boa estratégia de plano de


39

carreira não pode partir de premissas imutáveis e precisa levar em conta todas as possibilidades. Um bom conhecimento do plano de carreira dos membros da equipe se torna fonte para direcionamento de projetos, tarefas, treinamentos, formação de equipe, recompensas, etc. Pode ser elaborado um sistema com variáveis de parametrização que podem auxiliar no processo de reconhecimento de visão de cada membro da equipe. Tais resultados podem influenciar na tomada de decisão sobre atribuição de responsabilidades para cada membro da equipe de projeto. Direcionar pessoas e influenciar no seu plano de carreira é de fundamental importância para o nível de satisfação da equipe, e com certeza irá refletir no sucesso do projeto.

5.5.5 Matriz de Responsabilidade Uma das principais responsabilidades do gerente do projeto é designar tarefas para as pessoas da equipe. Uma Matriz de Responsabilidades (MR) é utilizada para representar conexões entre tarefas e membros da equipe. Uma MR pode também representar equipes no lugar de pessoas se for utilizada em projetos grandes que podem exigir níveis mais abrangentes e outros mais detalhados. Uma MR também pode definir níveis de autoridade para atividades específicas. MR’s são construídas no formato matricial (ou tabela), de fácil entendimento e flexibilidade para alteração. No exemplo abaixo as atividades são relacionadas na coluna da esquerda, relacionadas através de responsabilidades com as pessoas ou grupos:

Pessoas

Atividade Roberto Aline João

Análise responsável reporta-se informa

Desenho informa responsável informa

Construção informa reporta-se responsável Tabela 5.5.5-1 - Matriz de Responsabilidades

5.6 Comunicações Segundo o PMBOK, o gerenciamento de comunicações do projeto fornece as ligações críticas entre pessoas e informações que são necessárias para comunicações bem sucedidas. Grande parte do trabalho do gerente de projetos é gasto com o gerenciamento de comunicações durante todo o projeto. Em projeto de sistemas é muito importante que a comunicação seja bem estabelecida principalmente na fase de levantamento de requisitos, sendo uma das maiores chaves para seu sucesso.

“O gerenciamento das comunicações do projeto é a área de conhecimento que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações sobre o projeto de forma oportuna e

adequada.” PMBOK


40

5.6.1 Intranet O conceito de intranet pode ser interpretado como "uma versão privada da Internet", ou uma mini-internet confinada a uma organização ou projeto. Na intranet podemos distribuir informações, tais como notícias, eventos, calendários, vídeos, fóruns, artigos, etc. Uma forma de promover a intranet é disponibilizando informações importantes do projeto, como andamento, prazo, equipes de destaque, medições de desempenho, informações sobre campanhas de incentivo, cursos, treinamentos, etc. O acesso pode ser controlado por níveis de conteúdo, facilitando ao gerente a distribuição correta das informações.

5.6.2 Comunicadores Existem grandes ferramentas que podem auxiliar o gerente de projetos no gerenciamento das comunicações. Softwares comunicadores são leves, de fácil instalação e entendimento. Já temos o e-mail como uma ferramenta muito difundida, mas o dinamismo e a necessidade de informações rápidas nos projetos levam organizações a buscarem outras ferramentas. O uso de comunicadores instantâneos pode ser uma ferramenta ideal se bem utilizada e controlada, existindo vários produtos no mercado e com opções corporativas. Em um projeto de grande escala, reuniões podem ser feitas por software de vídeo-conferência, oferecendo conforto e economia em viagens, gastos com jantares, diárias em hotéis, etc. No entanto, o controle do uso destas ferramentas pelo gerente de projetos é de grande importância. Facilitar a comunicação por texto, arquivos, vídeos e imagens pode ser uma fonte pra entrada de vírus, malwares e outros softwares mal intencionados. Também é importante controlar e verificar se ocorre má utilização dos serviços por parte da equipe do projeto ou até mesmo dos clientes.

5.6.3 Banners e Cartazes A divulgação de informações é uma das tarefas do gerente de projetos. Todo comunicado, campanha, evento, kick-off’s, gincanas, início de projetos, fechamentos, conquistas, percentual de desempenho, informações sobre bônus, próximos projetos, homenagens, etc., podem ser divulgados através de banners e cartazes em espaços estratégicos da organização. A motivação da equipe depende muito de como as informações são transmitidas. Um projeto pode ter sua própria marca e pode estilizar todo um ambiente com faixas, cartazes, etc., incentivando toda a equipe e criando um ambiente motivador e descontraído. Empresas especializadas podem ser contratadas para criar e aplicar esses temas no projeto ou na organização.

5.6.4 Sistemas colaborativos – Wiki A informação está em todos os lugares. Em um projeto de sistemas, todos os stakeholders possuem um nível de conhecimento pessoal sobre o projeto. Gerentes tem a visão de negócios, enquanto a equipe pode ter uma visão supervisora ou técnica. Independente do tipo de visão, ela pode conter informações importantes para todos os envolvidos nos projetos, e centralizar estas informações pode ser uma tarefa muito difícil, principalmente no processo de coleta de informações. Em um sistema colaborativo, qualquer pessoa pode se cadastrar e inserir artigos e informações sobre um determinado assunto dentro de uma área de atuação. Este sistema pode ser implantado para coletar e distribuir diversos tipos de informações sobre um projeto, por exemplo: Fases, detalhes dos produtos a serem entregues, normas, regras, informações de produtos da organização, campanhas internas, processos padronizados, históricos de outros


41

projetos, lições aprendidas, etc. Estes sistemas, normalmente chamados de “Wiki”, podem ser adquiridos e instalados sem custo algum, e possuem um sistema de cadastro de usuários e uma estrutura intuitiva para a organização, inclusão e alteração de dados por qualquer usuário que queira colaborar. Os artigos são organizados e podem ser explorados através de um sistema de busca. A imagem abaixo exibe um dos maiores exemplos de dados organizados por um sistema colaborativo: A Wikipédia – A Enciclopédia Livre

Ilustração 5.6.4-1 - Exemplo de software colaborativo

5.7 Riscos “Segundo o PMBOK Riscos do projeto é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade (ou seja, em que o objetivo de tempo do projeto é a entrega de acordo com o cronograma acordado; em que custo do projeto é a entrega de acordo com o custo acordado, etc.). Um risco pode ter uma ou mais causas e, se ocorrer, um ou mais impactos.”

5.7.1 Matriz de Risco/Probabilidade/Plano de resposta Análise de Riscos em projetos de desenvolvimento de software pode ser feita com as seguintes finalidades:

• Verificar a viabilidade de um projeto, quantificando o retorno das várias linhas de ação disponíveis para a sua execução;

• Comparar a viabilidade entre projetos distintos, a fim de subsidiar uma tomada de decisão, considerando que os recursos para aplicação são limitados e devem ser empregados no projeto que possibilite o maior retorno esperado ou que tenha o menor risco;


42

• Identificar e/ou quantificar os fatores que podem prejudicar um determinado projeto, no que se refere ao atendimento de seus requisitos de custo, prazo, escopo e qualidade;

• Quantificar o retorno esperado de um projeto ou de uma linha de ação; • Verificar qual a melhor linha de ação a seguir, entre linhas de ação viáveis; • Levantar quais os riscos que o projeto ou as suas várias linhas de ação possuem e definir estratégias mitigadoras para cada um destes riscos;

• Definir as fontes de recursos, prazos, ações a ser tomadas e responsabilidades de cada integrante do projeto em cada estratégia mitigadora levantada.

Ilustração 5.7.1-1 - Processo de gerenciamento de riscos Em linhas gerais para desenvolver um software o planejamento da análise de risco é importantíssimo, conforme abaixo:

• Equipe responsável e funções de cada participante • Cronograma da análise de risco, especificando interdependências e prazos; • Cronograma de reuniões para discutir o andamento da análise • Métodos qualitativos a serem usados na análise • Métodos quantitativos a serem usados na análise • Documentos a serem elaborados • Métodos de monitoração dos resultados e controle


43

• Prioridades entre objetivos conflitantes • Fatores limitantes da análise, tais como custo, prazo, e qualidade do projeto

Existem alguns métodos de identificação de riscos estruturados como a Análise Preliminar de Perigos (APP), a Análise de Modos de Falhas e Efeitos (AMFE ou FMEA – Failure Mode and Effect Analysis) e o HAZOP (Hazard and Operability Analysis). Nº- Perigo Causas Conseqüências Medidas Preventivas ou Corretivas

1 Alta rotatividade dos envolvidos nos projetos

Salário baixo Concorrência

Comportamento do prazo no desenvolvimento do projeto Vazamento de informações aos concorrentes

Proporcionar nível adequado de salário conforme o mercado Definir plano de carreira Desenvolver um banco de dados de profissionais a fim de permitir reposição de mão de obra, caso necessário

2 Versão ou Tecnologia diferente da utilizada pelo cliente

Análise de requisitos inadequada

Falta de adequação do produto final à tecnologia do cliente

Iniciar desenvolvimento somente após não haver dúvidas na fase de análise de requisitos Definir reuniões periódicas com o cliente

3 Custo real maior do que o orçado

Estimativas de custo incorretas Mudanças no escopo do projeto

Prejuízo financeiro Alterações no escopo

Definir o escopo em reuniões com o cliente Definir reuniões periódicas com o cliente Fazer três estimativas para cada cotação Usar métodos estatísticos de definição de custo Utilizar métodos de monitoração e controle adequado (exemplo: Eva)

Tabela 5.7.1-1- APP (Análise Preliminar de Perigos) para um Projeto de Software Existem dois tipos de análise:

• Análise qualitativa do risco que pode ser usada em processos de tomada de decisão em projetos para classificar os perigos identificados e reduzir os seus efeitos

• Análise quantitativa do risco permite estimar o valor esperado do retorno de cada linha de ação, possibilitando, desta forma determinar qual deve ser seguida, subsidiando o processo de tomada de decisão.

Os riscos podem ser divididos com as seguintes categorias: • Risco econômico

o Alto custo de desenvolvimento de um sistema operacional; o Existência de softwares similares livres (sem custo); o Existência de softwares similares que, embora de alto custo, tenham ampla aceitação no mercado;

o Análise de custos incompleta ou deficiente, subestimando ou purerestimando o custo do projeto.


44

• Risco técnico o Complexidade do desenvolvimento o Incompatibilidade com aplicativos utilizados em empresas; o Falta de capacitação técnica adequada; o Erros no software gerando desempenho fraco; o Necessidade de grande espaço de memória; o Lentidão no desempenho.

• Risco gerencial o Atraso o cronograma; o Qualidade do produto precária

5.7.2 Segurança de sistemas O gerente é responsável por todo o projeto. Projetos de software que envolvem tratamento da informação para captura, validação, armazenamento, recuperação, transmissão e manipulação de informações de diversos níveis de importância estratégica. A proteção contra destruição intencionada, mau uso dos recursos, vazamento, modificação acidental, etc., também é de responsabilidade do gerente de projetos. Características da segurança de sistemas de informação:

• Disponibilidade • Integridade • Confidencialidade • Autenticação • Não repúdio

É importante estabelecer normas de segurança de informação, como processos de backup e restauração, segurança física das instalações e equipamentos, proteção contra mídias removíveis, firewall, etc. Também é importante estabelecer uma política de segurança, divulgá-la e assegurar que todos os envolvidos a conheçam.

5.7.3 Rastreabilidade “Existem muitas relações entre requisitos e outros requisitos entre os requisitos e o projeto

do sistema. Há também elos entre os requisitos e as razões básicas da proposição desses requisitos”.

Sommerville, 2003, p. 120 Uma parte crítica do gerenciamento de alterações é a avaliação do impacto da mudança no restante do sistema. Se a mudança é proposta enquanto os requisitos estão sendo desenvolvidos, deve ser identificado como a alteração afeta outros requisitos. Se a alteração é proposta enquanto o sistema está em implementação, o impacto de alteração envolve verificar como a alteração afeta os requisitos, o design do sistema e sua implementação. Se a alteração é proposta depois que o sistema foi colocado em operação, deve haver também uma verificação adicional a fim de identificar como todos os stakeholders do sistema podem ser afetados pela alteração.

Marquioni (2004) define alguns tipos de rastreabilidade, conforme abaixo: Tipo de rastreabilidade Descrição Requisitos – Fontes Às pessoas ou documentos que especificaram o requisito


45

Requisitos – Razão Link do requisito com uma descrição de “porque” foi especificado. Pode ser uma destilação de informações de várias fontes.

Requisitos – Requisitos Link do requisito com outros requisitos que sejam, de alguma maneira, dependentes dele. Deve ser um link de “mão dupla” (“depende” e “é dependente de”)

Requisitos – Arquitetura Link do requisito com os subsistemas onde estes requisitos estão implementados. Particularmente importante se os subsistemas estiverem sendo desenvolvidos por subcontratados diferentes.

Requisitos – Design Link do requisito com hardware ou componentes de software específicos no sistema que são usados para implementar o requisito.

Requisitos – Interface Requisitos – Interface Link do requisito com as interfaces de sistemas externos que serão usados na provisão dos requisitos.

Tabela 5.7.3-1 - Tipos de rastreabilidade

Benefícios da rastreabilidade automática:

• Permitir realizar estudos de métricas • Gerar relatórios • Consultar requerimentos do projeto • Permite realizar estatísticas • Permite realizar estudos estatísticos • Permite análises de requerimentos X atributos de requerimentos • Permite análise de requerimentos X proficiência de equipe • Permite saber o status do projeto como um todo (um pacote de caso de uso se torna uma atividade no cronograma)

• Permite validar mudanças e instabilidades de requerimentos • Quantos requerimentos existem no projeto (tamanho do projeto em horas )? • Quais são os requerimentos críticos que não foram aprovados (pessoa/gargalo )? • Quais são os custos de impacto da mudança (Scope Creeping Cost )? • Quantas modificações ocorreram desde a versão original?

o Quem autorizou as mudanças? Esta pessoa sabia do impacto? o Quais são os impactos das mudanças nas outras iterações? o Estas mudanças são maiores ou menores desde a última modificação?

Porque usar a rastreabilidade?

• Segurança de qualidade • Análise de impacto de mudança ( Com relação a análise de impacto é o efeito cascata (aumento ou diminuição de tempo/custo) das atividades subseqüentes dos requerimentos do software

Estratégia de rastreabilidade pode “hierarquizar” as fases do ciclo do projeto:

• Rastrear os requerimentos em tempo de análise • Rastrear os requerimentos em tempo de design/modelagem • Rastrear os requerimentos em tempo de desenvolvimento • Rastrear os requerimentos em tempo de testes

Rastreamento ajuda a gerenciar a mudança – a grande dificuldade em se gerenciar a mudança é baseada no esforço, tempo e custo.


46

5.7.4 Sistemas de Backup Para que o sistema de uma empresa possa prover uma política de segurança e velocidade para os dados dos seus usuários é imprescindível um perfeito gerenciamento desses dados. Identificar onde e como cada dado deve ser armazenado, qual o volume de informações críticas existentes, quantos dados desprezíveis são armazenados, são questões importantes para se definirem regras de armazenamento e a necessidade ou não de expansão dos componentes de armazenamento. O maior desafio, porém, é desenvolver uma infra-estrutura capaz de operar sobre os padrões abertos e independentes de plataformas de hardware de armazenamento. Uma das soluções utilizadas para solucionar o problema do gerenciamento é a consolidação de "storage", onde diversos ambientes de armazenamento são centralizados em um único local, facilitando a administração e o gerenciamento dos dados armazenados. Falhas de projeto Diversos são os casos de implementações de backup que não conseguem suportar o alto crescimento do volume de dados e que, após um curto intervalo de tempo, requerem um novo projeto de storage. Uma infra-estrutura de hardware e software de backup deve ser flexível para suportar o maior número possível de sistemas operacionais, além de utilizar as interfaces e utilitários nativos das principais aplicações do mercado. Erros em procedimentos de backup O termo backup está diretamente associado à segurança de dados e deve receber uma atenção especial do administrador de rede. Qualquer descuido pode ser fatal para os dados mais importantes de um projeto. Manter mídias de backup em locais inadequados e sujeitos à umidade, influência de campos magnéticos e alta temperatura pode danificá-las. Utilizar um mesmo local de armazenamento tanto para pastas e arquivos de backup quanto para todos os dados em uso é outro fator de risco de perda de dados se algum simples problema acontecer. Estes são apenas exemplos simples de erros em procedimentos de backup, em que uma empresa ou consultor especializado pode ser contratado pela gerência do projeto, evitando transtornos e podendo influenciar fortemente no sucesso ou fracasso do projeto.

5.7.5 Segurança no desenvolvimento O desconhecimento em segurança técnica é uma ameaça muitas vezes maior que as próprias vulnerabilidades comuns aos componentes tecnológicos e ataques a sistemas. Quando os funcionários responsáveis pela administração de TI não têm noções de como proteger a sua empresa, eles podem se transformar no foco de novas ameaças que, por não serem tão óbvias, são muito mais difíceis de serem percebidas antes de efetivamente se transformarem na causa de um impacto negativo para os projetos e negócios. Identificar as vulnerabilidades em sua infra-estrutura de TI e implementar as melhorias recomendadas são etapas fundamentais na direção da gestão de riscos das informações da sua empresa. Porém, além das vulnerabilidades comuns a qualquer aplicação, o desconhecimento das técnicas de desenvolvimento de sistemas seguros pode resultar em vulnerabilidades nas aplicações e causar grandes prejuízos para as organizações. Entendemos que o modelo utilizado pelas empresas divide a administração dos controles de segurança de acordo com as competências pessoais e especialização técnica das pessoas responsáveis pela administração dos componentes da rede de dados e os desenvolvedores e administradores de aplicações. Focos de segurança no desenvolvimento de aplicações


47

• Lei do menor privilégio, evitando que um usuário tenha acesso àquilo que ele não precisa;

• Redundância na segurança, servindo como prevenção caso um dos níveis de segurança falhe;

• Quando seu sistema de segurança alertar sobre algo, estar preparado para conter e recuperar os danos de um ataque;

• Regras de senhas; • Proteção contra falha, ao codificar sempre pensar de forma pessimista; • Uso de memória, recurso que nem sempre estamos preocupados no dia a dia, quando se fala em segurança é extremamente importante;

5.8 Aquisições Contratos, pedidos de compras, terceirização, fornecedores, etc., são itens relacionados a gerenciamento de aquisições, que fornece processos para as compras de produtos, serviços ou resultados sob um contrato.

“Gerenciamento de Aquisições do Projetos inclui os processos para comprar ou adquirir produtos, serviços ou resultados necessários de fora da equipe do projeto para realizar o

trabalho.” PMBOK

5.8.1 Hardware Para fazer compra de hardware em projeto é necessário seguir alguns passos, como informações a baixo: Documentos utilizados

• Cronograma; • Escopo de contratação; • Análise de riscos e SWOT; • Análise de Business Case; • Plano de Gerenciamento de Aquisições.

Ferramentas e Técnicas utilizadas • Análise das restrições do orçamento. Esta análise inclui os custos diretos e indiretos; • Necessidade imediata • Estratégia de longo prazo, pois o sistema será utilizado até o término de seu ciclo de vida;

• Opinião especializada: o Área de compras; o Área jurídica; o Especialistas dos negócios; o Especialistas técnicos.

• Análise dos tipos de contratos “Preço Fixo” e “Custos Reembolsáveis – Custo mais remuneração Fixa”.

Exemplos de critérios de avaliação • A proposta do fornecedor deverá conter os itens da Declaração de Trabalho. • O preço deverá ser a média cobrada pelo mercado.


48

• A equipe do fornecedor deverá ter no mínimo um PMP e um consultor pleno em cada frente de trabalho.

• A metodologia do fornecedor deverá ser compatível com a do comprador. • O fornecedor deverá ser uma empresa atuante a mais de cinco anos no mercado de implementação e consultoria e que tenha know-how com hardware e tecnologias em TI.

• O fornecedor deverá emitir certificado de garantia fazendo referência ao produto fornecido de acordo com a especificação técnica da Declaração de Trabalho do Contrato.

• O fornecedor não deverá ter restrições de crédito e ter sua situação financeira estável no mercado atuante de implementação e consultoria.

Documentos utilizados • RFP (Solicitação de Proposta) - Após reuniões será gerado o documento RFP (Solicitação de Proposta) e enviado para os 3 fornecedores que se qualificaram.

• Minuta de Contrato. • Lista de intenção de contratação. • Declaração de escopo. • Acordo de serviço.

Ferramentas e Técnicas utilizadas • Desenvolvimento da lista de fornecedores qualificados com base em internet, eventos e associações locais de varejo.

• Reuniões individuais com os fornecedores qualificados com tratamento igual. Selecionado o fornecedor e assinado o contrato, então dever ser executado o serviço. Ativos de processos organizacionais (atualizações)

• Arquivo do contrato Todos os documentos referente ao projeto, ao contrato e ao documento de encerramento do contrato deverão ser arquivados. Aceitação da entrega Após uma auditoria de encerramento o gerente do projeto, os responsáveis de cada departamento envolvido e o departamento jurídico deverão emitir um documento formalizando o encerramento do contrato e a aceitação da entrega. Documentação das lições aprendidas As lições aprendidas documentadas ao longo do projeto serão arquivadas para consulta aos próximos projetos.

5.8.2 UML - Diagrama de Implantação “Um diagrama que mostra a configuração dos nós de processamento em tempo de execução

e os componentes, processos e objetos que neles vivem.” (tradução livre de UML v1.4, página B-7)

Um dos diagramas que acredito ser um dos mais importantes é também um dos menos vistos nos projetos de sistemas de informação. O diagrama de implantação representa como é realizada a distribuição do sistema através de nós de hardware, componentes e dependências de software e as suas devidas relações de comunicação. O diagrama de implantação pode ser


49

representado de duas formas: como descritor, onde mostra a configuração básica do hardware; ou como uma instância, onde mostra as reais características de configuração de hardware. Como exemplo podemos ver em seguida um simples diagrama. Ele mostra como uma máquina de um vendedor de uma loja se comunica com um servidor. E como a mesma máquina se comunica com um nó de hardware, no caso uma impressora qualquer, através de uma porta serial. O servidor de aplicações, identificado como sendo o Glassfish, troca informações com o banco de dados. Também podemos notar as relações de dependência do servidor de aplicações para com o banco de dados, e dos clientes para com o servidor de aplicações.

Ilustração 5.8.2-1 - Exemplo de Diagrama de Implantação Os diagramas de implantação são empregados para modelagem da visão estática de implantação de um sistema. Com essa visão podemos analisar qual a real necessidade do projeto para a aquisição, por exemplo, de máquinas e pacotes de softwares adicionais. Ou seja, a importância do diagrama de implantação não está somente na possibilidade de visualizar e especificar fisicamente os sistemas, mas sim como um auxílio no Gerenciamento de Aquisições em projetos sistemas de informação.


50

6 SUGESTÃO DE PESQUISA DE MERCADO

6.1 O modelo OPM3 Atualmente, empresas estão mais conscientes da importância do Gerenciamento de Projetos para alcançar suas estratégias. Atingir o nível máximo de excelência em projetos é o objetivo principal, e toda a estratégia para atingir este nível envolve um caminho de amadurecimento. Maturidade em Gerenciamento de Projetos é um assunto muito discutido em artigos, revistas especializadas e palestras. O modelo OPM3, ainda recente e em sua primeira edição – 2003 - apresenta-se em sua fase de homologação e de recebimento de sugestões e críticas para que, no final de 2008, venha ser lançada sua segunda versão. Seguindo seu tradicional método de trabalho compartilhado, o PMI, através do Knowledge Foundation, seguiu a seguinte base para a construção desse modelo:

• Pesquisa de 27 modelos de qualidade e maturidade incluindo (CMM, ISO, SPICE, outros);

• Desenvolvido pela comunidade mundial de gerentes de projetos; • Equipe de mais de 800 colaboradores em 35 países de diversos segmentos industriais; • Alinhado às práticas do PMBOK.

A aplicação do modelo OPM3 depende muito de uma estrutura onde tais competências possam ser multiplicadas, ou seja, de um PMO formalmente consolidado, pois o mesmo tem, e deve ser encarado como um Projeto. A partir dessa unidade ou entidade – caso tenha sido estabelecido “apenas” com este propósito, são quatro os passos a serem coordenados pelo PMO:

• Elaborar o Plano de Projeto de Implantação do Modelo OPM3 o Conhecimento

� Realizar estudo sobre o modelo; o Avaliação

� Definir o escopo de atuação dentro da organização; � Alinhar o questionário à área/organização; � Estudar o processo de avaliação; � Aplicar o questionário; � Apurar e avaliar os resultados;

o Melhoria � Identificar os pontos de melhoria; � Traçar metas para o processo de melhoria; � Implementar melhorias; � Repetir o processo de avaliação em intervalos pré-estabelecidos, para acompanhar o crescimento percentual da maturidade organizacional;

� Reavaliar e reestruturar as metas do processo de melhoria.


51

Segundo o PMI (2003), o significado do termo OPM3, ou Organizational Project Management Maturity Model pode ser definido da seguinte maneira: Organizacional: aumenta o domínio do trabalho em um único projeto; O uso da palavra maturidade implica que as capacidades devem crescer durante o tempo com o objetivo de produzir sucesso em gerenciamento de projeto repetidamente. No início do ano de 2003 foi definido o formato de complexidade do modelo e, em dezembro o produto OPM3 foi publicado.

6.2 Principais benefícios do OPM3:

• Articular o sucesso dos projetos; • Medir a performance dos projetos; • Fazer com que os resultados fornecidos pelos projetos sejam previstos com melhor sucesso;

• Ajudar o trabalho conjunto dos projetos ao invés de colocar um projeto contra outro em um ambiente multi-projetos.

Segundo Dinsmore (1998), um modelo de maturidade reflete o quanto uma organização progrediu em direção à incorporação do gerenciamento de projetos como forma de trabalho. A velocidade na qual uma empresa pode incorporar o gerenciamento de projetos à sua forma de fazer negócios depende de uma combinação de fatores:

• Pressões externas de mercado para trabalhar mais rápido, mais barato e melhor • Insatisfação interna com relação à organização, sistemas e procedimentos atuais • Grande compromisso dos principais participantes da organização • Uma visão clara e um plano de mudança para uma nova forma de fazer negócio

Em resumo, o nível de maturidade em gerenciamento de projetos mede a eficácia na entrega dos resultados gerados pelos mesmos e avalia o quanto uma organização progrediu em direção à incorporação do gerenciamento de projetos como uma forma eficaz de trabalho”. O que motiva a busca da maturidade em gerenciamento de projetos, por parte da maioria das organizações, é o aumento das expectativas dos clientes, o diferencial competitivo de mercado, a necessidade de alinhamento estratégico e a conquista de índices melhores de efetividade dos projetos.

• Maturidade do Gerenciamento de Projetos – diz respeito ao nível de padronização e aplicação das práticas de gerenciamento de projetos, e ao grau de maturidade da própria equipe de gestão.

• Maturidade Organizacional no Gerenciamento de Projetos – verifica o grau de utilização, pela organização, das “Melhores Práticas” recomendadas pelos modelos internacionais.

6.3 Pesquisa para análise

6.3.1 Introdução Vivemos um momento de constantes mudanças e desafios no ambiente de negócios.


52

A concorrência entre as empresas pela busca do mercado consumidor cada vez mais exigente tem forçado as organizações a se adaptarem às novas expectativas do mercado para sobreviverem. Toda a pressão vinda do mercado externo é refletida para o mercado interno, através de novos desafios e metas que passam a ser cobrados de cada departamento e setor. A redução das margens de lucro e dos prazos para a introdução de novos produtos, a pressão pela eliminação do desperdício e retrabalho, aliada à constante melhoria da qualidade e do controle dos produtos demandados pelo mercado, vem exigindo uma maior assertividade nos grupos de processos aplicados nos projetos: iniciação, planejamento, execução/controle e encerramento, por parte da organização. Neste cenário, as empresas vêm trabalhando cada vez mais com projetos. Um estudo realizado pela PricewaterhouseCoopers - PwC (2004), revela que 26% das empresas trabalham com mais de 100 projetos ao ano e a média geral gira em torno de 53 projetos ao ano com um custo médio por projeto de US$ 450.000,00. Entretanto PwC (2004) revela que apenas 2,5% dos projetos são entregues em sua totalidade dentro do prazo estipulado, dentro do custo orçado e dentro do escopo definido de modo a atender as expectativas do cliente e o retorno (financeiro ou estratégico) da organização. Segundo Kerzner(2001), a simples utilização do gerenciamento de projetos sem a avaliação do grau de padronização, do nível de eficiência e da eficácia de sua metodologia, mesmo que por um longo período de tempo não eleva o nível de excelência da empresa com relação ao gerenciamento de projetos. Ao invés disso, o resultado de sua aplicação sem controle e padronização pode ser representado por uma sucessão de erros e fracassos, fazendo com que a empresa passe por um lento e duro aprendizado através das ações de seus próprios erros e não através dos ensinamentos e das melhores práticas de outras empresas. É em um cenário como o descrito acima, que um modelo de maturidade em gerenciamento de projetos, busca fornecer suporte para que a empresa possa definir, avaliar e desenvolver seus processos de gerenciamento de projetos com o objetivo de atingir vantagens competitivas, através de um diferencial de seu desempenho em relação à concorrência. Com o passar dos tempos, os modelos de maturidade vem representando um papel cada vez maior nas organizações. Segundo Kerzner (2002),“os executivos perceberam que as organizações devem ser mais dinâmicas, ..., devem ser capazes de se reestruturar rapidamente conforme as necessidades do mercado.” Também segundo Carvalho & Rabechini Jr (2005), a estrutura organizacional deve ser dinâmica, acompanhando as alterações impostas pelo ambiente de negócios. A visão histórica de que a utilização do gerenciamento de projetos ao longo do tempo por si só tornaria as empresas melhores, é contestada por Kerzner. Em primeiro lugar esse paradigma possui duas falhas. A primeira delas diz respeito a que uma empresa não pode esperar décadas até se tornar boa no gerenciamento de projetos. A segunda é que a utilização do gerenciamento de projetos sem um plano de melhoria contínua em sua metodologia, abre caminho para a repetição de erros e falhas toleráveis dentro da hierarquia organizacional. Uma organização tida como imatura em termos de gerenciamento de projeto pode entregar projetos individuais que venham a produzir um excelente resultado ocasionalmente. Entretanto, os gerentes de projetos como os demais membros da equipe, estarão trabalhando sempre de uma forma reativa, focando apenas nos problemas imediatos (Harpham 2004). Os resultados positivos e esperados, advindos do crescimento e da maturidade da empresa, não virão apenas da aplicação imediata das técnicas, ferramentas e disseminação dos conceitos de gerenciamento de projetos. Os melhores resultados não devem ser esperados para o curto prazo. Kerzner afirma que “Todas as organizações passam por um processo de maturidade, e esse processo de maturidade deve preceder a excelência. A curva de aprendizado para a maturidade é medida em anos.”


53

Demonstraremos a seguir um estudo para aplicação do modelo de maturidade em gerenciamento de projetos com os métodos do PMI (OPM3), para medir o grau de maturidade em gerenciamento de projetos de uma companhia de Seguros. Obs.: O questionário e as respostas aplicadas nesta pesquisa estão no Anexo 1

6.3.2 Dados gerais da Organização Este é um modelo de pesquisa em uma Empresa de Seguros que poderá servir como sugestão para análises futuras. Presente há mais de um século no país, a seguradora possui grande capacidade de adaptação às características do mercado local e às aspirações dos consumidores brasileiros. Assim, o sucesso obtido no passado serve de estímulo para que esta Companhia de Seguros esteja sempre voltada para o futuro, buscando superar-se continuamente. Esta Companhia ocupa um lugar privilegiado no cenário empresarial brasileiro, pois combina vivência global e proximidade com a cultura regional. A Empresa mantém firmes suas raízes no Brasil ao mesmo tempo em que se alinha às melhores práticas internacionais, recebendo e exportando experiências e know how. Sempre sintonizada com o dinamismo da sociedade brasileira, é reconhecida no país pela alta qualidade de seus produtos, serviços e atendimento. Conta com 1.300 colaboradores, cerca de 60 filiais em todo o território nacional e o apoio de 10 mil corretores de seguros na comercialização de seus produtos. Também considerados clientes, os parceiros de distribuição recebem atendimento diferenciado, treinamentos específicos e têm à disposição ferramentas tecnológicas elaboradas sob medida para suas necessidades. Sua ambição em prosseguir sua expansão global de forma intensa, assim como os saltos de performance obtidos localmente, colocam o Brasil - um dos países emergentes com maior potencial de crescimento econômico em todo o planeta - em uma posição estratégica dentro do Grupo. A Companhia tem centrado esforços no crescimento contínuo e sustentável e, para tanto, desenvolveu um amplo e bem desenhado portfólio de produtos e serviços de seguro para pessoas e empresas. Buscando a excelência em cada ação e contando com o suporte de um dos maiores conglomerados seguradores do mundo, está totalmente focada em garantir a lealdade dos clientes atuais, conquistar novos negócios e contribuir para o desenvolvimento econômico e social do Brasil. Demonstramos a seguir a estrutura organizacional desta Companhia de Seguros através de seu organograma:


54

Presidência

Divisão ProdutosDivisão de TI e Operações

Divisão Comercial Divisão Comercial Divisão Saúde Recursos HumanosDiretoria Jurídico

Societário

RelaçõesInstitucionais

Comunicação

Auditoria

Divisão Financeira

MASSIFICADOS

ESTATÍSTICA E ATUARIAL

GRANDES RISCOS

AGRONEGÓCIOS

MULTIPRODUTOS

SINISTRO MATRIZ

SINISTROS CONTROLE

TRANSPORTES

JURÍDICO

SINISTROS GRANDES RISCOS

SISTEMAS CORPORATIVOS

QUALIDADE E GESTÃO OPERAC.

. . . .

INFRAESTRUTURA E SEG.

TECNOL. CANAIS E CLIENTES

.

CENTRAL EMISSÃO

PROJETOS COMERCIAIS

REGIONAL SP CAPITAL

REGIONAL SUL

GESTÃO DE NEGÓCIOS

REGIONAL RJ/NE/NO

Regional MG

AFFINITY

REGIONAL SÃO PAULO INTERIOR

FILIAL BANCOS

FILIAL BANKBOSTON

CONTABILIDADE

PATRIMÔNIO E COMPRAS

.

REPORTE INTERNACIONAL

GESTÃO DE CUSTOS

INFORM. GERENCIAIS

FILIAL CORPORATE

PROGRAMAS INTERNAC.

PROGRAMAS INTER.. EUROPA

PROGR. INTERNAC APOIO

LICITAÇÕES

TECNICO OPERACIONAL

INFORMATICA SAUDE

CARE

COMERCIAL SAUDE

CORPORATE SAUDE

GESTÃO RISCO

FATURAMENTO SAUDE

REMUNERAÇÃO E REL TRAB.

CAPTAÇÃO E DESENVOLV.

JURIDICO SOCIETARIO

RESSEGURO / COSSEGURO

DEPTO GESTÃO PROJ E PROC. REGIONAL MG / CENTRO OESTE

Presidência

Divisão ProdutosDivisão de TI e Operações

Divisão Comercial Divisão Comercial Divisão Saúde Recursos HumanosDiretoria Jurídico

Societário

RelaçõesInstitucionais

Comunicação

Auditoria

Divisão Financeira

MASSIFICADOS

ESTATÍSTICA E ATUARIAL

GRANDES RISCOS

AGRONEGÓCIOS

MULTIPRODUTOS

SINISTRO MATRIZ

SINISTROS CONTROLE

TRANSPORTES

JURÍDICO

SINISTROS GRANDES RISCOS

SISTEMAS CORPORATIVOS

QUALIDADE E GESTÃO OPERAC.

. . . .

INFRAESTRUTURA E SEG.

TECNOL. CANAIS E CLIENTES

.

CENTRAL EMISSÃO

PROJETOS COMERCIAIS

REGIONAL SP CAPITAL

REGIONAL SUL

GESTÃO DE NEGÓCIOS

REGIONAL RJ/NE/NO

Regional MG

AFFINITY

REGIONAL SÃO PAULO INTERIOR

FILIAL BANCOS

FILIAL BANKBOSTON

CONTABILIDADE

PATRIMÔNIO E COMPRAS

.

REPORTE INTERNACIONAL

GESTÃO DE CUSTOS

INFORM. GERENCIAIS

FILIAL CORPORATE

PROGRAMAS INTERNAC.

PROGRAMAS INTER.. EUROPA

PROGR. INTERNAC APOIO

LICITAÇÕES

TECNICO OPERACIONAL

INFORMATICA SAUDE

CARE

COMERCIAL SAUDE

CORPORATE SAUDE

GESTÃO RISCO

FATURAMENTO SAUDE

REMUNERAÇÃO E REL TRAB.

CAPTAÇÃO E DESENVOLV.

JURIDICO SOCIETARIO

RESSEGURO / COSSEGURO

DEPTO GESTÃO PROJ E PROC. REGIONAL MG / CENTRO OESTE

Ilustração 6.3.2-1 - Organograma da Companhia de Seguros para análise OPM3

6.3.3 Estrutura de Gerenciamento de Projetos da Organização Analisando a estrutura da organização, podemos categorizá-la como Matricial Fraca, pois os grupos de projetos utilizam as mesmas pessoas que pertencem aos setores funcionais. Estes passam a ter dois tipos de trabalho, um relacionado ao setor funcional e outro relativo ao projeto do qual estão participando. Portanto, os Gerentes funcionais possuem maior influência sobre os colaboradores envolvidos nos projetos do que o Gerente do projeto. Como demonstrado no organograma, a área responsável pelos projetos corporativos da companhia está localizada na Divisão de Tecnologia da Informação e Operações, dentro da superintendência de Gestão de Projetos e Processos.

PRESIDÊNCIA

DIVISÃO DE TI E OPERAÇÕES

GESTÃO DE PROJETOS E PROCESSOS

...

... ...

PRESIDÊNCIA

DIVISÃO DE TI E OPERAÇÕES

GESTÃO DE PROJETOS E PROCESSOS

...

... ...

Ilustração 6.3.3-1 - Divisão de Tecnologia de da Informação e Operações - Pesquisa OPM3 A implantação do Departamento de Gestão de Projetos e processos (DGPP) como Escritório de Projetos deu-se à aproximadamente 2 anos com o intuito de reduzir as perdas proporcionadas por um gerenciamento de projetos ineficiente e criar um cultura de projetos na organização. O Departamento de Gestão de Projetos e Processos (DGPP) é a área corporativa responsável pela avaliação, coordenação central, acompanhamento, revisão final e reporte de


55

todos os projetos da companhia, ou seja, qualquer tarefa fora das atividades regulares ou periódicas das Áreas de Negócio, que exija dedicação significativa de recursos durante um período de tempo estendido e obedeça a pelo menos um dos seguintes critérios:

• Custo de implantação estimado maior que 100.000 (cem mil) reais; • Alta complexidade de coordenação devido ao envolvimento de várias áreas da Companhia;

• Alta importância estratégica conforme definição do Comitê Executivo. A área é composta por sete colaboradores sendo: 1 Superintendente de Projetos e Processos, 1 Consultor de Processos, 4 Consultores de Projetos e 1 Estagiário. Relacionamos abaixo as principais responsabilidades do DGPP, bem como, das áreas envolvidas nos projetos:

• Cabe ao Departamento de Gestão de Projetos e Processos: o Prover suporte às áreas responsáveis pelo projeto para a definição do Projeto; o Avaliar propostas de Projeto com informações fornecidas pelas Áreas Responsáveis pelo Projeto, pela Divisão de Tecnologia, pela Divisão Financeira e outras áreas conforme necessidade do Projeto;

o Prover suporte às áreas responsáveis pelo Projeto no planejamento e desenvolvimento conceitual dos projetos;

o Selecionar junto com os Gestores das áreas Funcionais a equipe que será alocada para o projeto;

o Coordenar, acompanhar e dar suporte ao Projeto em implementação; o Prover informações e suporte às decisões do Comitê Executivo com relação ao desenvolvimento de projetos;

o Efetuar a revisão final do Projeto após implementação; o Centralizar e administrar toda a documentação referente ao Projeto;

• Cabe às Áreas Responsáveis pelo Projeto: o Iniciar e definir os projetos; o Prover as informações necessárias à área de Gestão de Projetos e Processos para análise e avaliação;

o Prover os recursos necessários aos projetos; o Planejar o Projeto aprovado pelo Comitê Executivo e realizar as especificações detalhadas;

o Efetuar os testes necessários e implementar o Projeto nas áreas envolvidas. • Cabe à Divisão de Tecnologia:

o Prover informações de tecnologia às áreas responsáveis pelo Projeto para os projetos em fase de criação;

o Prover as informações necessárias à área de Gestão de Projetos e Processos para a elaboração de análises e avaliações;

o Dar suporte às áreas responsáveis pelos projetos no planejamento e desenvolvimento conceitual do Projeto;

o Fornecer todos os insumos necessários em termos de infra-estrutura tecnológica, atuando em conjunto com as áreas responsáveis pelo Projeto na fase de implementação.

• Cabe à Divisão Financeira: o Prover as informações necessárias à área de Gestão de Projetos e Processos para análise e avaliação;


56

o Definir as regras de cálculo e de avaliações aplicáveis para um Projeto no momento da análise de custo-benefício detalhado, conforme as normas financeiras adotas pela Companhia de Seguros.

• Cabe ao Comitê de Riscos: o Avaliar os riscos envolvidos no projeto e prover informação/ suporte às decisões do Comitê Executivo com relação à exposição da Companhia aos riscos envolvidos.

o Cabe ao Comitê Executivo: o Decidir pela aprovação ou recusa das fases descritas neste documento.

O DGPP funciona hoje como uma entidade organizacional estabelecida para auxiliar os times de projeto da organização na implementação de práticas, metodologias, ferramentas e técnicas do gerenciamento de projetos. De acordo com o conceito de Hallows (2002) sobre as funções de um PMO, o DGPP inclui-se no grupo de Suporte, ou seja, ajuda os gerentes de projetos a fazerem seu trabalho de uma maneira melhor, provendo assistência e clareza nos processos de gerenciamento de projetos. No entanto, de acordo com o modelo de Dinsmore (1998), o DGPP enquadra-se no modelo Project Support Office (PSO), apenas com a ressalva de que a responsabilidade pelo sucesso do projeto não reside apenas no DGPP, mas é compartilhada com as áreas que utilizam de seus serviços.

6.3.4 Organization Project Management Maturity Model (OPM3) - PMI O PMI desenvolveu este modelo de maturidade cuja visão é: “criar um modelo de maturidade endossado entusiasticamente e reconhecido no mundo inteiro como padrão para o desenvolvimento e avaliação das capacidades de gerenciamento de projetos dentro de uma organização”. Através da aplicação deste modelo podemos medir a performance dos projetos, articular o sucesso dos projetos, prever os resultados dos projetos e ajudar o trabalho conjunto dos projetos ao invés de colocar um projeto contra o outro.

• Resultado Final OPM3

Ilustração 6.3.4-1 - Resultado Final OPM3

• Resultado PPP – Projeto / Programa / Portfólio


57

Ilustração 6.3.4-2 - Resultado PPP – Projeto / Programa / Portfolio

• Resultado SMCI – Standardize / Measure / Control / Improve

Ilustração 6.3.4-3 - Resultado SMCI – Standardize / Measure / Control / Improve

• Resultado Detalhado PPP e SMCI


58

Ilustração 6.3.4-4 - Resultado Detalhado PPP e SMCI

• Conclusões OPM3 Segue abaixo nossas conclusões em relação ao resultado obtido com a aplicação do modelo OPM3 (PMI):

• A companhia de seguros demonstrou pequena atuação em gerenciamento de projetos; • Identificamos a necessidade de focar a atuação em Gestão de Programas e Portfólio, pois ainda é incipiente. Neste momento existe apenas um Programa na Companhia ainda em fase de planejamento e não existe Portfólio de Projetos.

• Eixo padronização e Controle: o Percentuais maiores; o Aparentemente a Companhia dá foco a estas capacidades.

• Eixo melhorias e mensuração: o Percentuais menores; o Necessidade de Revisão da metodologia; o Necessidade de Implementação de Portfólio inicial; o Necessitam de forte atuação.

6.3.5 Análise crítica do resultado da aplicação dos modelos Após a aplicação dos questionários dos modelos de maturidade em gerenciamento de projetos PMI (OPM3) na Companhia de Seguros e da obtenção dos resultados descritos anteriormente, descrevemos abaixo nossa análise:


59

Na aplicação dos questionários do modelo de maturidade OPM3, queremos ressaltar alguns pontos: 1. Para aplicarmos este questionário, entrevistamos um colaborador da Companhia de Seguros que não tem o conhecimento adequado de todos os processos, áreas, diretorias e stakeholders envolvidos em gerenciamento de projetos. Isto influenciou diretamente no resultado dos gráficos, pois o colaborador selecionado está atuando no Departamento de Gestão de Projetos e Processos a menos de 1 ano;

2. Algumas perguntas são muito genéricas, tornando imprecisas as respostas. Adotamos o critério de responder YES, às respostas que atendessem a pelo menos 75% do conceito que foi requerido pelas perguntas. Isto tornou o resultado final impreciso e pouco próximo à realidade.

3. Este questionário deve ser aplicado somente às pessoas que tenham uma boa visão global do negócio, bem como, ter atuado na gerência ou liderança de pelos menos 1 projeto de porte médio. Para diminuirmos os impactos e aumentarmos a assertividade, será necessário entrevistarmos mais de um colaborador da Companhia de Seguros.


60

7 CONSIDERAÇÕES FINAIS O Gerenciamento de Projetos, alinhado às práticas do PMI, é alvo de interesse de diversas organizações que buscam um elevado índice de sucesso em seus projetos. Podemos concluir que existe uma série de estudos em metodologias e ferramentas de gestão de desenvolvimento de software que auxiliam no alcance desses objetivos. O PMI apóia fortemente o uso de ferramentas e técnicas voltadas ao gerenciamento de projetos, e muitas são abordadas em cada disciplina do PMBOK como sugestão em cada processo do PMI. Porém, existem diversas outras opções no mercado, de fácil acesso e custos relativamente baixos. A grande maioria das metodologias e ferramentas de gestão de desenvolvimento de software são flexíveis: se adaptam a qualquer necessidade de projetos de sistemas, portanto, é necessário um estudo ou até mesmo uma pesquisa para determinar de que forma elas devem ser aplicadas.


61

8 CONCLUSÃO Podemos concluir, através do trabalho apresentado, que a Metodologia, se bem aplicada, pode influenciar fortemente no sucesso ou fracasso do Projeto. Não obstante, existem muitas organizações que desconhecem ou não utilizam adequadamente a Metodologia, que pode ser vista como um processo burocrático. Também podemos concluir que a boa comunicação é fundamental. Todos os processos do PMBOK exigem comunicação, assim como o uso de metodologia e ferramentas. Projetos envolvem fortemente as pessoas e a comunicação é fator chave para o sucesso de todo projeto. Em projeto de desenvolvimento de software a importância do gerente de projeto é fundamental para manter uma equipe motivada e focada no objetivo maior que é o projeto. É necessário ter habilidades, competências para escolher as melhores técnicas de gerência de pessoal, saber dar feedback, coothing, mentoring, etc., ou seja, o Gerente de Projetos deve possuir capacidade de liderar pessoas, devendo ficar atento para fato que na área de TI os profissionais possuírem formações muitos técnicas e que a mesma técnica de gerência de pessoal aplicada em uma fase pode não ser viável para a próxima e o contrário também é verdadeiro. Muitas soluções são flexíveis, customizáveis, de diferentes fabricantes, de custos diversos e acessíveis, bastando que a organização avalie e estude a melhor maneira de aplicá-las, podendo até contratar empresas especializadas e capacitar o uso através de treinamentos. Existem muitas outras soluções, que não abordamos neste trabalho, mas já consagradas e bastante utilizadas. Uma sugestão para um próximo trabalho seria um estudo mais detalhado das Metodologias mais utilizadas, com exemplos reais de aplicação e casos de sucesso e fracasso em diferentes tipos de projetos e estruturas organizacionais.


62

9 ANEXOS

9.1 Questionário OPM3

Question Questões Answer (Y/N)

1 Are the sponsor and other stakeholders involved in setting a direction for the project

that is in the best interests of all stakeholders?

Estão os patrocinadores ou demais stakeholders envolvidos em definir uma direção para o projeto, que esteja em concordância com os melhores interesses de todos os

stakeholders?

N

2 Does your organization consider risk during project selection?

A sua organização considera o risco durante a seleção dos projetos?

Y 3 Are your organization's goals and objectives

communicated to and understood by the project teams?

São as metas e objetivos de sua organização comunicados e

entendidos pelas equipes de projeto?

Y

4 Do the projects in your organization have clear and measurable objectives in addition to

time, cost, and quality?

Os projetos em sua organização possuem objetivos claros e

mensuráveis em adição aos de prazo, custo e Qualidade?

Y

5 Does your organization continuously improve the quality on projects to achieve customer

satisfaction?

A sua organização continuamente melhora a qualidade nos projetos para se obter a satisfação de seus

clientes?

Y

6 Does your organization have policies that describe the standardization, measurement, control, and continuous improvement of

project management processes?

A sua organização possui políticas que descrevem a padronização, a medição, o controle e a melhoria

contínua dos processos de gerenciamento de projetos?

N

7 Has your organization fully integrated the PMBOKÂ® Guide knowledge areas in its

project management methodology?

A sua organização integrou totalmente as áreas de conhecimento

do guia PMBOK® em sua metodologia de gerenciamento de

projeto?

N

8 Does your organization use project management processes and techniques in a manner that is relevant and effective for each

project?

A sua organização utiliza os processos e técnicas de

gerenciamento de projetos de uma maneira em que seja relevante e

efetiva para cada projeto?

Y

9 Does your organization use data internal to the project, data internal to the organization,

and industry data to develop models for planning and re-planning?

A sua organização utiliza dados internos para o projeto, dados

internos para a organização, e dados industriais para desenvolver modelos de planejamento e re-planejamento?

N

10 Does your organization establish the project manager role for all projects?

A sua organização estabelece as regras de gerenciamento de projetos

para todos os projetos?

Y

11 Does your organization establish standard cross-functional project team structures?

A sua organização estabelece estruturas padrões de equipes de

projetos cross-functional?

Y

12 Does your organization create a work environment that fosters teamwork, builds trust, and encourages project teams to take

calculated risks when appropriate?

A sua organização propicia um ambiente de trabalho que fomente o trabalho em equipe, construção de confiança, e encorajam os times de projeto a aceitar riscos calculados

quando apropriados?

Y


63

13 Does your organization have the necessary processes, tools, guidelines, or other formal

means to assess the performance, knowledge, and experience levels of project resources and assign them to project roles

appropriately?

A sua organização possui os processos, ferramentas, guias ou outros meios formais necessários

para avaliar a performance, conhecimento, e os níveis de

experiência dos recursos dos projetos para definir suas funções no projeto?

N

14 Does your organization create a work environment that supports personal and

professional achievement?

A sua organização propicia um ambiente de trabalho que suporta a realização pessoal e profissional?

Y

15 Do the project managers in your organization communicate and collaborate effectively and responsibly with project managers of related

projects?

Os gerentes de projetos em sua organização, comunicam e colaboram efetivamente e responsavelmente

com gerentes de projetos relacionados?

N

16 Does your organization establish and use standard documented processes at the Project level for the Initiation Processes

(Initiation Process)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Projeto para os Processos

de iniciação (Iniciação)?

Y

17 Does your organization establish and use standard documented processes at the

Project level for the Planning Core Processes (Project Plan Development, Scope Planning, Scope Definition, Activity Definition, Activity Sequencing, Activity Duration Estimating,

Schedule Development, Resource Planning, Cost Estimating, Cost Budgeting, Risk

Management Planning)?


Core de Planejamento (Desenvolvimento do Plano do

Projeto, Planejamento do Escopo, Detalhamento do Escopo, Definição das Atividades, Seqüenciamento das Atividades, Estimativa de Duração das Atividades, Desenvolvimento do

Cronograma, Planejamento dos Recursos, Estimativa dos Custos, Orçamento dos Custos, Plano de

Gerenciamento do Risco)?

Y

18 Does your organization establish and use standard documented processes at the Project level for the Planning Facilitating

Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk

Response Planning, Procurement Planning, Solicitação Planning)?


Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,

Montagem da Equipe, Planejamento das Comunicações, Identificação dos

Riscos, Análise Qualitativa dos Riscos, Análise Quantitativa dos Riscos, Plano de Resposta aos

Riscos, Planejamento das Aquisições, Preparação das Aquisições)?

N

19 Does your organization establish and use standard documented processes at the Project level for the Executing Core Processes (Project Plan Execution)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Projeto para os Processos Core de Execução (Execução do

Plano do Projeto)?

Y


Project level for the Executing Facilitating Processes (Quality Assurance, Team Development, Information Distribution, Solicitação, Source Selection, Contract

Administration)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Projeto para os Processos Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da

Equipe, Distribuição das Informações, Solicitação de Propostas, Seleção de Fornecedores e Administração dos

Contratos)?

N


64

21 Does your organization establish and use standard documented processes at the Project level for the Controlling Core Processes (Performance Reporting,

Integrated Change Control)?


Core de Controle (Relato de Desempenho e Controle Integrado de

Mudanças)?

Y


Project level for the Controlling Facilitating Processes (Scope Verification, Scope

Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and

Control)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Projeto para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

Y

23 Does your organization establish and use standard documented processes at the Project level for the Closing Processes (Contract Encerramento, Administrative

Closure)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Projeto para os Processos de Encerramento (Encerramento dos

Contratos e Encerramento Administrativo)?

Y

24 Can your organization demonstrate a return on investment from undertaking projects?

Pode a sua organização demonstrar um retorno de investimento de

undertaking projects?

Y

25 Do the projects in your organization define and review goals and success criteria at the beginning of the project and then review them

as the project progresses?

Os projetos na sua organização definem e revisam metas e critérios de sucessos no início do projeto e então as revisam com o progresso

dos projetos.

N

26 Does your organization have a standard approach for the definition, collection, and analysis of project metrics to ensure project

data is consistent and accurate?

Sua organização possui uma metodologia padrão para a definição,

coleta e análise das métricas de projeto para garantir que os dados de

projetos sejam consistentes e precisos?

Y

27 Does your organization use both internal and external standards to measure and improve

project performance?

Sua organização utiliza tanto padrões internos e externos para medir e

melhorar a performance do projeto?

N

28 Does your organization have defined gateway milestones, where project deliverables are assessed to determine whether the project

should continue or terminate?

Sua organização possui definido gateway milestones, aonde as saídas dos projetos são avaliadas para se

determinar a interrupção ou a continuidade do projeto?

Y

29 Does your organization use risk management techniques to take measurements and assess the impact of risk during project execution?

Sua organização faz uso de técnicas de gerenciamento de risco para se obter medidas e avaliações dos

impactos de risco durante a execução do projeto?

N

30 Does your organization use a formal performance system that evaluates

individuals and project teams on their project performance as well as the projects' overall

results?

Sua organização utiliza um sistema formal de performance que avaliam

os indivíduos e as equipes de projetos em suas performances de projeto, da mesma forma em que os resultados

gerais do projeto?

N

31 Does your organization establish and use measurements at the Project level for the Initiation Processes (Initiation Process)?

Sua organização estabelece e utiliza medições no Nível de Projeto para os Processos de Iniciação (Iniciação)?

Y


65

32 Does your organization establish and use measurements at the Project level for the Planning Core Processes (Project Plan Development, Scope Planning, Scope Definition, Activity Definition, Activity

Sequencing, Activity Duration Estimating, Schedule Development, Resource Planning,

Cost Estimating, Cost Budgeting, Risk Management Planning)?

Sua organização estabelece e utiliza medições no Nível de Projeto para os Processos Core de Planejamento (Desenvolvimento do Plano do




Y

33 Does your organization establish and use measurements at the Project level for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff

Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis,

Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?

Sua organização estabelece e utiliza medições no Nível de Projeto para os

Processos Facilitadores de Planejamento (Planejamento da

Qualidade, Planejamento Organizacional, Montagem da Equipe, Planejamento das Comunicações, Identificação dos Riscos, Análise Qualitativa dos Riscos, Análise

Quantitativa dos Riscos, Plano de Resposta aos Riscos, Planejamento das Aquisições, Preparação das

Aquisições)?

N

34 Does your organization establish and use measurements at the Project level for the Executing Core Processes (Project Plan

Execution)?


Processos Core de Execução (Execução do Plano do Projeto)?

Y

35 Does your organization establish and use measurements at the Project level for the Executing Facilitating Processes (Quality

Assurance, Team Development, Information Distribution, Solicitação, Source Selection,

Contract Administration)?

Sua organização estabelece e utiliza medições no Nível de Projeto para os Processos Facilitadores de Execução

(Garantia da Qualidade, Desenvolvimento da Equipe, Distribuição das Informações,

Solicitação de Propostas, Seleção de Fornecedores e Administração dos

Contratos)?

N

36 Does your organization establish and use measurements at the Project level for the Controlling Core Processes (Performance Reporting, Integrated Change Control)?

Sua organização estabelece e utiliza medições no Nível de Projeto para os Processos Core de Controle (Relato de Desempenho e Controle Integrado

de Mudanças)?

Y

37 Does your organization establish and use measurements at the Project level for the Controlling Facilitating Processes (Scope

Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk

Monitoring and Control)?

Sua organização estabelece e utiliza medições no Nível de Projeto para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos,

Controle da Qualidade, Monitoração e Controle dos Riscos)?

Y

38 Does your organization establish and use measurements at the Project level for the

Closing Processes (Contract Encerramento, Administrative Closure)?


Processos de Encerramento (Encerramento dos Contratos e Encerramento Administrativo)?

N

39 Does your organization establish and execute controls at the Project level to manage the stability of Initiation Processes (Initiation

Sua organização estabelece e executa controles no Nível de Projeto para se gerenciar a estabilidade para

N


66

Process)? os Processos de Iniciação (Iniciação)?

40 Does your organization establish and execute controls at the Project level to manage the

stability of Planning Core Processes (Project Plan Development, Scope Planning, Scope

Definition, Activity Definition, Activity Sequencing, Activity Duration Estimating,



Sua organização estabelece e executa os controles no Nível de

Projeto para se gerenciar a estabilidade para os Processos Core de Planejamento (Desenvolvimento

do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo,

Definição das Atividades, Seqüenciamento das Atividades,

Estimativa de Duração das Atividades, Desenvolvimento do Cronograma, Planejamento dos Recursos, Estimativa dos Custos, Orçamento dos Custos, Plano de


Y

41 Does your organization establish and execute controls at the Project level to manage the stability of Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?

Sua organização estabelece e executa os controles no Nível de

Projeto para se gerenciar a estabilidade para os Processos Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

42 Does your organization establish and execute controls at the Project level to manage the

stability of Executing Core Processes (Project Plan Execution)?


os Processos Core de Execução (Execução do Plano do Projeto)?

Y

43 Does your organization establish and execute controls at the Project level to manage the stability of Executing Facilitating Processes (Quality Assurance, Team Development,

Information Distribution, Solicitação, Source Selection, Contract Administration)?


os Processos Facilitadores de Execução (Garantia da Qualidade,

Desenvolvimento da Equipe, Distribuição das Informações,


Contratos)?

N

44 Does your organization establish and execute controls at the Project level to manage the stability of Controlling Core Processes

(Performance Reporting, Integrated Change Control)?


os Processos Core de Controle (Relato de Desempenho e Controle

Integrado de Mudanças)?

Y

45 Does your organization establish and execute controls at the Project level to manage the stability of Controlling Facilitating Processes (Scope Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and Control)?


os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle

Y


67

dos Custos, Controle da Qualidade, Monitoração e Controle dos Riscos)?

46 Does your organization establish and execute controls at the Project level to manage the stability of Closing Processes (Contract Encerramento, Administrative Closure)?


os Processos de Encerramento (Encerramento dos Contratos e Encerramento Administrativo)?

Y

47 Does your organization capture, analyze, and apply lessons learned from past projects?

Sua organização coleta, analisa e aplica as lições aprendidas de outros

projetos?

Y

48 Does your organization identify, assess, and implement improvements at the Project level

for the Initiation Processes (Initiation Process)?

Sua organização identifica, avalia e implementa melhorias no Nível de

Projeto para os Processos de Iniciação (Iniciação)?

Y

49 Does your organization identify, assess, and implement improvements at the Project level for the Planning Core Processes (Project

Plan Development, Scope Planning, Scope Definition, Activity Definition, Activity



Sua organização identifica, avalia e implementa melhorias no Nível de Projeto para os Processos Core de Planejamento (Desenvolvimento do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo,




Y


for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?


Projeto para os Processos Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

51 Does your organization identify, assess, and implement improvements at the Project level for the Executing Core Processes (Project

Plan Execution)?

Sua organização identifica, avalia e implementa melhorias no Nível de Projeto para os Processos Core de Execução (Execução do Plano do

Projeto)?

Y


for the Executing Facilitating Processes (Quality Assurance, Team Development,



Projeto para os Processos Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da


N


68

Contratos)?


for the Controlling Core Processes (Performance Reporting, Integrated Change

Control)?

Sua organização identifica, avalia e implementa melhorias no Nível de Projeto para os Processos Core de Controle (Relato de Desempenho e Controle Integrado de Mudanças)?

Y

54 Does your organization identify, assess, and implement improvements at the Project level for the Controlling Facilitating Processes

(Scope Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and Control)?


Projeto para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

Y


for the Closing Processes (Contract Encerramento, Administrative Closure)?


Projeto para os Processos de Encerramento (Encerramento dos


N

56 Does your organization have an organizational structure in place that supports effective communication and collaboration among projects in a program leading to improved results of those projects?

Sua organização possui uma estrutura organizacional em curso que

apóia uma comunicação efetiva e colaboração entre projetos em uma program leading para melhorar os

resultados desses projetos?

Y

57 Do program managers assess the confidence in projects' plans in terms of their schedule,

dependencies on other projects, and availability of resources?

Os gerentes de programas, avaliam a confiança nos planos do projeto em

termos do seu cronograma, dependência em relação à outros projetos, e disponibilidade de

recursos?

Y

58 Do program managers understand how their programs and other programs in the

organization fit into the organization's overall goals and strategies?

Os gerentes de programas entendem como os seus programas e outros programas na organização se

encaixam nas metas e estratégias gerais da organização?

Y

59 Does your organization use a common set of processes to consistently manage and

integrate multiple projects?

Sua organização utiliza um conjunto comum de processos para se

gerenciar consistentemente e integrar múltiplos projetos?

Y

60 Does your organization establish and use standard documented processes at the Program level for the Initiation Processes


Sua organização estabelece e utiliza processos documentados

padronizados no Nível de Programa para os Processos de Iniciação

(Iniciação)?

Y

61 Does your organization establish and use standard documented processes at the Program level for the Planning Core

Processes (Project Plan Development, Scope Planning, Scope Definition, Activity Definition,

Activity Sequencing, Activity Duration Estimating, Schedule Development,

Resource Planning, Cost Estimating, Cost


padronizados no Nível de Programa para os Processos Core de

Planejamento (Desenvolvimento do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo,

Definição das Atividades,

Y


69

Budgeting, Risk Management Planning)? Seqüenciamento das Atividades, Estimativa de Duração das

Atividades, Desenvolvimento do Cronograma, Planejamento dos Recursos, Estimativa dos Custos, Orçamento dos Custos, Plano de



Program level for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk



padronizados no Nível de Programa para os Processos Facilitadores de Planejamento (Planejamento da



Aquisições)?

N

63 Does your organization establish and use standard documented processes at the Program level for the Executing Core Processes (Project Plan Execution)?


padronizados no Nível de Programa para os Processos Core de Execução

(Execução do Plano do Projeto)?

N


Program level for the Executing Facilitating Processes (Quality Assurance, Team Development, Information Distribution, Solicitação, Source Selection, Contract

Administration)?


padronizados no Nível de Programa para os Processos Facilitadores de Execução (Garantia da Qualidade,



Contratos)?

N

65 Does your organization establish and use standard documented processes at the Program level for the Controlling Core Processes (Performance Reporting,



padronizados no Nível de Programa para os Processos Core de Controle (Relato de Desempenho e Controle


N


Program level for the Controlling Facilitating Processes (Scope Verification, Scope


Control)?


padronizados no Nível de Programa para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle dos Riscos)?

Y

67 Does your organization establish and use standard documented processes at the Program level for the Closing Processes (Contract Encerramento, Administrative

Closure)?


padronizados no Nível de Programa para os Processos de Encerramento

(Encerramento dos Contratos e Encerramento Administrativo)?

N


70

68 Does your organization evaluate metrics processes at all levels for improvements?

Sua organização avalia as métricas dos processos em todos os níveis

para seu crescimento?

Y

69 Does your organization establish and use measurements at the Program level for the Initiation Processes (Initiation Process)?

Sua organização estabelece e utiliza medições no Nível de Programa para

os Processos de Iniciação (Iniciação)?

N

70 Does your organization establish and use measurements at the Program level for the Planning Core Processes (Project Plan Development, Scope Planning, Scope Definition, Activity Definition, Activity



Sua organização estabelece e utiliza medições no Nível de Programa para os Processos Core de Planejamento

(Desenvolvimento do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo, Definição das Atividades, Seqüenciamento das Atividades, Estimativa de Duração das Atividades, Desenvolvimento do



Y

71 Does your organization establish and use measurements at the Program level for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff



Planning)?


os Processos Facilitadores de Planejamento (Planejamento da



Aquisições)?

N

72 Does your organization establish and use measurements at the Program level for the Executing Core Processes (Project Plan

Execution)?


os Processos Core de Execução (Execução do Plano do Projeto)?

N

73 Does your organization establish and use measurements at the Program level for the Executing Facilitating Processes (Quality







Contratos)?

N

74 Does your organization establish and use measurements at the Program level for the Controlling Core Processes (Performance Reporting, Integrated Change Control)?


os Processos Core de Controle (Relato de Desempenho e Controle


N

75 Does your organization establish and use measurements at the Program level for the Controlling Facilitating Processes (Scope




os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle dos Riscos)?

Y


71

76 Does your organization establish and use measurements at the Program level for the Closing Processes (Contract Encerramento,

Administrative Closure)?


os Processos de Encerramento (Encerramento dos Contratos e Encerramento Administrativo)?

N

77 Does your organization establish and execute controls at the Program level to manage the stability of Initiation Processes (Initiation

Process)?

Sua organização estabelece e execute controles no Nível de Programa para se gerenciar a

estabilidade para os Processos de Iniciação (Iniciação)?

Y

78 Does your organization establish and execute controls at the Program level to manage the stability of Planning Core Processes (Project Plan Development, Scope Planning, Scope





estabilidade para os Processos Core de Planejamento (Desenvolvimento


Definição das Atividades, Sequenciamento das Atividades,



Y

79 Does your organization establish and execute controls at the Program level to manage the stability of Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?

Sua organização estabelece e execute controles no Nível de Programa para se gerenciar a estabilidade para os Processos Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

80 Does your organization establish and execute controls at the Program level to manage the stability of Executing Core Processes (Project

Plan Execution)?


estabilidade para os Processos Core de Execução (Execução do Plano do

Projeto)?

Y

81 Does your organization establish and execute controls at the Program level to manage the stability of Executing Facilitating Processes (Quality Assurance, Team Development,


Sua organização estabelece e execute controles no Nível de Programa para se gerenciar a estabilidade para os Processos

Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da


Contratos)?

N

82 Does your organization establish and execute controls at the Program level to manage the

stability of Controlling Core Processes (Performance Reporting, Integrated Change

Control)?


estabilidade para os Processos Core de Controle (Relato de Desempenho

N


72

e Controle Integrado de Mudanças)?

83 Does your organization establish and execute controls at the Program level to manage the stability of Controlling Facilitating Processes (Scope Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and Control)?

Sua organização estabelece e execute controles no Nível de Programa para se gerenciar a estabilidade para os Processos

Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

Y

84 Does your organization establish and execute controls at the Program level to manage the

stability of Closing Processes (Contract Encerramento, Administrative Closure)?


estabilidade para os Processos de Encerramento (Encerramento dos


N

85 Does your organization identify, assess, and implement improvements at the Program level for the Initiation Processes (Initiation

Process)?

Sua organização identifica, avalia e implementa melhorias no Nível de Programa para os Processos de

Iniciação (Iniciação)?

Y

86 Does your organization identify, assess, and implement improvements at the Program level for the Planning Core Processes

(Project Plan Development, Scope Planning, Scope Definition, Activity Definition, Activity Sequencing, Activity Duration Estimating,




Programa para os Processos Core de Planejamento (Desenvolvimento do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo,




N

87 Does your organization identify, assess, and implement improvements at the Program

level for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?


Programa para os Processos Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

88 Does your organization identify, assess, and implement improvements at the Program level for the Executing Core Processes

(Project Plan Execution)?


Programa para os Processos Core de Execução (Execução do Plano do

Projeto)?

N


73


level for the Executing Facilitating Processes (Quality Assurance, Team Development,



Programa para os Processos Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da


Contratos)?

N

90 Does your organization identify, assess, and implement improvements at the Program level for the Controlling Core Processes

(Performance Reporting, Integrated Change Control)?


Programa para os Processos Core de Controle (Relato de Desempenho e Controle Integrado de Mudanças)?

N


level for the Controlling Facilitating Processes (Scope Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and Control)?


Programa para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

N

92 Does your organization identify, assess, and implement improvements at the Program level for the Closing Processes (Contract Encerramento, Administrative Closure)?

Sua organização identifica, avalia e implementa melhorias no Nível de Programa para os Processos de Encerramento (Encerramento dos


N

93 Does your organization effectively consider workload, profit requirements, and delivery timeframes in deciding how much project

work it can undertake?

Sua organização considera efetivamente workload, profit

requirements, e delivery timeframes ao decidir quanta carga de trabalho

pode assumir?

Y

94 Does your organization align and prioritize projects to its business strategy?

Sua organização alinha e prioriza seus projetos em função de sua

estratégia de negócios?

Y

95 Is your organization "projectized" in that it has project management policies and values, a

common project language, and use of project management processes across all

operations?

Sua organização é “projetizada”, pelo fato de possuir políticas e valores em

gerenciamento de projetos, uma linguagem comum de projetos, e

utilizar os processos de gerenciamento de projetos em todas

suas operações?

N

96 Does your organization use and maintain a common project management framework,

methodology, and process set for its projects?

Sua organização utiliza e mantém um framework, metodologia e um

conjunto de processos para o seu desenvolvimento?

Y

97 Are your organization's executives directly involved in the organization's project management direction, and do they

demonstrate knowledge and support of that direction?

Os executivos de sua organização estão diretamente envolvidos no

direcionamento do gerenciamento de projetos de sua organização? E eles

demonstram conhecimento e o suporte neste sentido?

N

98 Does the structure of your organization support its project management direction?

A estrutura de sua organização suporta o seu direcionamento no

gerenciamento de projetos?

N

99 Does your organization support open communication across all levels?

A sua organização suporta uma comunicação aberta entre todos os

seus níveis?

Y


74

100 Do people in different roles and functions throughout your organization collaborate to

define and agree on common goals?

As pessoas atuando em diferentes papéis e funções através de toda a

organização colaboram para se definir e concordar com metas comuns?

N

101 Does your organization set a strategy to retain knowledge of internal and external

resources?

A sua organização define uma estratégia para reter o conhecimento dos recursos internos e externos?

N

102 Does your organization have and support an internal project management community that proactively provides for all the roles required

for portfolio management?

A sua organização possui e suporta uma comunidade interna de

gerenciamento de projetos que colabora proativamente com para todos os papéis necessários ao gerenciamento de portfolio?

Y

103 Does your organization encourage membership in external project management communities (e.g. professional associations

or initiatives)?

A sua organização encoraja a filiação em comunidades externas de gerenciamento de projetos (por

exemplo: associações profissionais ou iniciativas)?

Y

104 Does your organization provide for the ongoing training and development of project

management resources?

A sua organização fornece treinamento contínuo e

desenvolvimento dos recursos envolvidos com o gerenciamento de

projetos?

N

105 Does your organization have progressive career paths for project-related roles?

A sua organização possui planos de carreiras progressivos para os papéis

ligados à projetos?

N

106 Does your organization perform portfolio management including planning, risk

management, procurement, and financial management?

A sua organização realiza o gerenciamento de portfolio incluindo o

planejamento, gerenciamento de risco, procurement, e gerenciamento

financeiro?

Y

107 Does your organization balance the mix of projects in a portfolio to ensure the health of

the portfolio?

A sua organização balanceia o mix de projetos em um portfolio para garantir

a saúde do portfolio?

Y

108 Does your organization's quality management system include portfolio management?

O sistema de gerenciamento da qualidade de sua organização inclui o

gerenciamento de portfolio?

N

109 Is your organization's quality management system reviewed by an independent body?

O sistema de gerenciamento da qualidade de sua organização é

revisado por um organismo independente?

N

110 Does your organization establish and use standard documented processes at the Portfolio level for the Initiation Processes


Sua organização estabelece e utiliza processos padrões documentados no Nível de Portfolio para os Processos

de Iniciação (Iniciação)?

Y

111 Does your organization establish and use standard documented processes at the Portfolio level for the Planning Core

Processes (Project Plan Development, Scope Planning, Scope Definition, Activity Definition,

Activity Sequencing, Activity Duration Estimating, Schedule Development,

Resource Planning, Cost Estimating, Cost Budgeting, Risk Management Planning)?


Core de Planejamento (Desenvolvimento do Plano do




Y


75


Portfolio level for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk



Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

113 Does your organization establish and use standard documented processes at the Portfolio level for the Executing Core Processes (Project Plan Execution)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Portfolio para os Processos Core de Execução (Execução do

Plano do Projeto)?

Y


Portfolio level for the Executing Facilitating Processes (Quality Assurance, Team Development, Information Distribution, Solicitação, Source Selection, Contract

Administration)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Portfolio para os Processos Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da


Contratos)?

N

115 Does your organization establish and use standard documented processes at the Portfolio level for the Controlling Core Processes (Performance Reporting,



Core de Controle (Relato de Desempenho e Controle Integrado de

Mudanças)?

N


Portfolio level for the Controlling Facilitating Processes (Scope Verification, Scope


Control)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Portfolio para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

Y

117 Does your organization establish and use standard documented processes at the Portfolio level for the Closing Processes (Contract Encerramento, Administrative

Closure)?

Sua organização estabelece e utiliza processos padrões documentados no Nível de Portfolio para os Processos de Encerramento (Encerramento dos


Y

118 Does your organization gather quality assurance metrics on its projects?

Sua organização coleta métricas da garantia da qualidade em seus

projetos?

N

119 Does your organization have a central project metrics repository?

Sua organização possui um repositório central de métricas de

projeto?

N

120 Does your organization use project metrics to determine project, program, portfolio, and

organizational effectiveness?

Sua organização utiliza métricas de projeto para se determinar a

efetividade dos projetos, programas, portfolio e da organização?

N

121 Does your organization use formal performance assessment processes and

Sua organização utiliza um processo formal de avaliação de performance e

Y


76

systems to evaluate individuals and project teams?

sistemas, para se avaliar o indivíduo e a equipe?

122 Does your organization evaluate and consider the investment of human and financial resources when selecting projects?

Sua organização avalia e considera o investimento em recursos humanos e financeiros ao selecionar projetos?

Y

123 Does your organization evaluate and consider the value of projects to the organization when

selecting projects?

Sua organização avalia e considera o valor dos projetos para a organização

ao selecionar projetos?

Y

124 Does your organization have project management tools that are integrated with

other corporate systems?

Sua organização possui ferramentas de gerenciamento de projetos que

estão integradas com outros sistemas corporativos?

Y

125 Does your organization establish and use measurements at the Portfolio level for the Initiation Processes (Initiation Process)?

Sua organização estabelece e utiliza medições no Nível de Portfolio para

os Processos de Iniciação (Iniciação)?

N

126 Does your organization establish and use measurements at the Portfolio level for the Planning Core Processes (Project Plan Development, Scope Planning, Scope Definition, Activity Definition, Activity



Sua organização estabelece e utiliza medições no Nível de Portfolio para os Processos Core de Planejamento

(Desenvolvimento do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo, Definição das Atividades, Seqüenciamento das Atividades, Estimativa de Duração das Atividades, Desenvolvimento do



N

127 Does your organization establish and use measurements at the Portfolio level for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff



Planning)?


os Processos Facilitadores de Planejamento (Planejamento da



Aquisições)?

N

128 Does your organization establish and use measurements at the Portfolio level for the Executing Core Processes (Project Plan

Execution)?

Sua organização estabelece e utiliza medições no Nível de Portfolio para os Processos Core de Execução (Execução do Plano do Projeto)?

N

129 Does your organization establish and use measurements at the Portfolio level for the Executing Facilitating Processes (Quality







Contratos)?

N

130 Does your organization establish and use measurements at the Portfolio level for the Controlling Core Processes (Performance Reporting, Integrated Change Control)?

Sua organização estabelece e utiliza medições no Nível de Portfolio para os Processos Core de Controle

(Relato de Desempenho e Controle Integrado de Mudanças)?

N


77

131 Does your organization establish and use measurements at the Portfolio level for the Controlling Facilitating Processes (Scope




os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle dos Riscos)?

N

132 Does your organization establish and use measurements at the Portfolio level for the Closing Processes (Contract Encerramento,

Administrative Closure)?

Sua organização estabelece e utiliza medições no Nível de Portfolio para os Processos de Encerramento (Encerramento dos Contratos e Encerramento Administrativo)?

N

133 Does your organization establish and execute controls at the Portfolio level to manage the stability of Initiation Processes (Initiation

Process)?

Sua organização estabelece e executa controles no Nível de Portfolio para se gerenciar a

estabilidade para os Processos de Iniciação (Iniciação)?

Y

134 Does your organization establish and execute controls at the Portfolio level to manage the stability of Planning Core Processes (Project Plan Development, Scope Planning, Scope




Sua organização estabelece e executa os controles no Nível de Portfolio para se gerenciar a

estabilidade para os Processos Core de Planejamento (Desenvolvimento





Y

135 Does your organization establish and execute controls at the Portfolio level to manage the stability of Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?

Sua organização estabelece e executa os controles no Nível de Portfolio para se gerenciar a

estabilidade para os Processos Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

136 Does your organization establish and execute controls at the Portfolio level to manage the

stability of Executing Core Processes (Project Plan Execution)?


estabilidade para os Processos Core de Execução (Execução do Plano do

Projeto)?

N

137 Does your organization establish and execute controls at the Portfolio level to manage the stability of Executing Facilitating Processes (Quality Assurance, Team Development,



estabilidade para os Processos Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da

Equipe, Distribuição das Informações,

N


78


Contratos)?

138 Does your organization establish and execute controls at the Portfolio level to manage the

stability of Controlling Core Processes (Performance Reporting, Integrated Change

Control)?

Sua organização estabelece e executa controles no Nível de Portfólio para se gerenciar a

estabilidade para os Processos Core de Controle (Relato de Desempenho e Controle Integrado de Mudanças)?

N

139 Does your organization establish and execute controls at the Portfolio level to manage the stability of Controlling Facilitating Processes (Scope Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and Control)?


estabilidade para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

N

140 Does your organization establish and execute controls at the Portfolio level to manage the stability of Closing Processes (Contract Encerramento, Administrative Closure)?


estabilidade para os Processos de Encerramento (Encerramento dos


Y

141 Does your organization have a program to achieve project management maturity?

Sua organização possui um programa para se atingir a maturidade em

projetos?

N

142 Does your organization recognize the need for OPM3 as part of a project management

maturity program?

Sua organização reconhece a importância do OPM3 como parte de

um programa de maturidade em gerenciamento de projetos?

Y

143 Does your organization incorporate lessons learned from past projects, programs, and portfolios into its project management

methodology?

Sua organização incorpora as lições aprendidas de projetos, programas e

portfólios passados em sua metodologia de gerenciamento de

projetos?

Y

144 Does your organization identify, assess, and implement improvements at the Portfolio level

for the Initiation Processes (Initiation Process)?

Sua organização identifica, avalia e implementa melhorias no Nível de Portfolio para os Processos de

Iniciação (Iniciação)?

N


for the Planning Core Processes (Project Plan Development, Scope Planning, Scope




Sua organização identifica, avalia e implementa melhorias no Nível de Portfolio para os Processos Core de Planejamento (Desenvolvimento do Plano do Projeto, Planejamento do Escopo, Detalhamento do Escopo,




N


79


for the Planning Facilitating Processes (Quality Planning, Organizational Planning, Staff Acquisition, Communications Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, Procurement Planning, Solicitação

Planning)?


Portfolio para os Processos Facilitadores de Planejamento (Planejamento da Qualidade, Planejamento Organizacional,




N

147 Does your organization identify, assess, and implement improvements at the Portfolio level for the Executing Core Processes (Project

Plan Execution)?

Sua organização identifica, avalia e implementa melhorias no Nível de Portfolio para os Processos Core de Execução (Execução do Plano do

Projeto)?

N


for the Executing Facilitating Processes (Quality Assurance, Team Development,



Portfolio para os Processos Facilitadores de Execução (Garantia da Qualidade, Desenvolvimento da


Contratos)?

N


for the Controlling Core Processes (Performance Reporting, Integrated Change

Control)?

Sua organização identifica, avalia e implementa melhorias no Nível de Portfolio para os Processos Core de Controle (Relato de Desempenho e Controle Integrado de Mudanças)?

N


for the Controlling Facilitating Processes (Scope Verification, Scope Change Control, Schedule Control, Cost Control, Quality Control, Risk Monitoring and Control)?


Portfolio para os Processos Facilitadores de Controle (Verificação do Escopo, Controle de Mudanças do Escopo, Controle do Cronograma, Controle dos Custos, Controle da Qualidade, Monitoração e Controle

dos Riscos)?

N


for the Closing Processes (Contract Encerramento, Administrative Closure)?

Sua organização identifica, avalia e implementa melhorias no Nível de Portfolio para os Processos de

Encerramento (Encerramento dos Contratos e Encerramento

Administrativo)?

N


80

10 REFERÊNCIAS BIBLIOGRÁFICAS PRESSMAN, ROGER S. - Mitos do Software - Engenharia de Software, Edição 6, 2006, McGraw-Hill, Pesquisado em 18/6/2008

XAVIER, C.M.S.; VIVACQUA F.R.; MACEDO O.S. - Metodologia de Gerenciamento de Projetos: Methodware, Edição 3, 2005, Brasport, Pesquisado em 18/6/2008

PMI - O instituto - Disponível em <http://www.pmisp.org.br/instituto.asp>, Pesquisado em 18/6/2008

PMI - PROJECT MANAGEMENT INSTITUTE - - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 18/6/2008

Ferramenta - Disponível em <http://www.wikipedia.org.br/>, Pesquisado em 16/6/2008

Técnica - Disponível em <http://www.wikipedia.org.br/>, Pesquisado em 16/6/2008

CAMARGO, A.A. BUENO - Gestão de Projetos - Disponível em <http://www.multidoc.com.br>, Pesquisado em 16/6/2008

XAVIER, C.M.S.; VIVACQUA F.R.; MACEDO O.S. - Metodologia de Gerenciamento de Projetos: Methodware, Edição 3, 2005, Brasport, Pesquisado em 13/6/2008

Processo - Disponível em <http://www.wikipedia.org.br/>, Pesquisado em 16/6/2008

FIORINI T. SOELI.; STAA V.A.; BAPTISTA M. R - - Engenharia de Software com CMM, 1998, Brasport, Pesquisado em 13/6/2008

CRISTIAN REIS - O desenvolvimento de software deve ser difícil? - Disponível em <http://www.async.com.br/~kiko/papers/bullet/>, Pesquisado em 12/6/2008

SÉRGIO DOS SANTOS - Sucesso no desenvolvimento de software usando uma metodologia de desenvolvimento - Disponível em <http://imasters.uol.com.br/artigo/6566/des_de_software/sucesso_no_desenvolvimento_de_software_usando_uma_metodologia_de_desenvolvimento/>, Pesquisado em 13/6/2008

Metodologia - Disponível em <http://www.wikipedia.org.br/>, Pesquisado em 16/6/2008

Guia das melhores práticas de TI - Metodologias - Disponível em <http://www.infoblogs.com.br/view.action?contentId=33128&Guia-das-melhores-praticas-de-TI---Metodologias>, Pesquisado em 13/6/2008

Escopo (definição) - Dicionário da língua portuguesa, Disponível em <http://www.priberam.pt>, Pesquisado em 12/7/2008

PMI - PROJECT MANAGEMENT INSTITUTE - Gerenciamento do Escopo do Projeto - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 12/7/2008

"GUEDES, G.T.A. - Introdução à UML

UML 2 - Guia de Consulta Rápida, Edição 1, 2005, Novatec, Pesquisado em 12/7/2008"

GUEDES, G.T.A. - Histórico da UML - UML 2 - Guia de Consulta Rápida, Edição 1, 2005, Novatec, Pesquisado em 12/7/2008

PRESSMAN, ROGER S. - Modelagem de sistemas com a UML - Engenharia de Software, Edição 6, 2006, McGraw-Hill, Pesquisado em 12/7/2008


81

XAVIER, C.M.S.; VIVACQUA F.R.; MACEDO O.S. - O conceito de pacote de trabalho - Metodologia de Gerenciamento de Projetos: Methodware, Edição 3, 2005, Brasport, Pesquisado em 12/7/2008

HRIS guiedlines for joint application development - HRIS - Technology Resources for Employee and Campus Services, Disponível em <http://www.utexas.edu/ecs/trecs/hris/pub/jad.php>, Pesquisado em 12/7/2008

Joint Application Development - Joint Application Development - Wikipedia, Disponível em <http://pt.wikipedia.org/wiki/JAD>, Pesquisado em 12/7/2008

Joint Application Development - JAD - Apostila - Universidade Bandeirante de São Paulo, 2006, Pesquisado em 12/7/2008

Roberto Pallesi Msc. - Rational Unified Process: uma abordagem gerencial - Monografia, 2005, Pesquisado em 12/7/2008

PRESSMAN, ROGER S. - Prototipagem - Engenharia de Software, Edição 6, 2006, McGraw-Hill, Pesquisado em 12/7/2008

5W2H, Disponível em <http://pupila2.com/administracao/files/File/osm13_5w2h.pdf >, Pesquisado em 1/7/2008

- Método 5W2H - Disponível em <http://www.lugli.org/2008/02/09/o-metodo-5w-2h/>, Pesquisado em 1/7/2008

Brainstorming - Disponível em <http://pt.wikipedia.org/wiki/Brainstorming>, Pesquisado em 1/7/2008

PROF. ANA CLAUDIA - Diagrama de Fluxo de Dados - Análise e Projeto de Sistemas - Disponível em <http://www.unesc.net/>, Pesquisado em 4/7/2008

CAROL A. DEKKERS - O que é um ponto de função - BFPUG - Brazilian Function Point Users Group, Disponível em <http://www.bfpug.com.br/Artigos/Dekkers-PontosDeFuncaoEMedidas.htm>, Pesquisado em 23/9/2008

XAVIER, C.M.S.; VIVACQUA F.R.; MACEDO O.S. - Calcular o custo das atividades e do projeto - Metodologia de Gerenciamento de Projetos: Methodware, Edição 3, 2005, Brasport, Pesquisado em 23/9/2008

PMI - PROJECT MANAGEMENT INSTITUTE - Gerenciamento do custos do Projeto - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 23/9/2008

XAVIER, C.M.S.; VIVACQUA F.R.; MACEDO O.S. - Calcular o custo das atividades e do projeto - Metodologia de Gerenciamento de Projetos: Methodware, Edição 3, 2005, Brasport, Pesquisado em 23/9/2008

Análise de Pontos de Função - Análise de Pontos de função - Wikipedia, Disponível em <http://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o>, Pesquisado em 5/8/2008

Qualidade - Definição de qualidade - Wikipedia, Disponível em <http://pt.wikipedia.org/wiki/Qualidade>, Pesquisado em 23/9/2008

PMI - PROJECT MANAGEMENT INSTITUTE - Gerenciamento da qualidade do Projeto - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 23/9/2008


82

HSM MANAGEMENT - 6-Sigma - Disponível em <http://www.companyweb.com.br>, Pesquisado em 29/8/2008

BLOGCMMI - CMMi - Disponível em <http://www.blogcmmi.com>, Pesquisado em 29/8/2008

RALPH M. STAIR - Prototipagem - Princípios de Sistemas de Informação, Edição 2, 1998, LTC, Pesquisado em 8/10/2008

PMI - PROJECT MANAGEMENT INSTITUTE - Gerenciamento de Recursos Humanos do projeto - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 14/10/2008

PMI - PROJECT MANAGEMENT INSTITUTE - Gerenciamento de Recursos Humanos do projeto - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 14/10/2008

LEONARDO HOFF DOS SANTOS - Campanhas de incentivo - Disponível em <http://www.pensandomarketing.com/home/id88.html>, Pesquisado em 14/10/2008

PMI - PROJECT MANAGEMENT INSTITUTE - Gerenciamento de Riscos Humanos do projeto - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 15/10/2008

AMARAL, JOÃO ALBERTO ARANTES E SBRAGIO, RICARDO - Gestão de Projetos - Conceitos, metodologias, ferramentas e melhores práticas gerenciais, 2005, Scortecci Editora, Pesquisado em 15/10/2008

- Segurança em Sistemas - Disponível em <http://ensino.univates.br/>, Pesquisado em 15/10/2008

QUALIFIC - Gerência de Requisitos - Segurança de Informação, 2006, Qualific, Disponível em <http://www.qualific.com.br>, Pesquisado em 16/10/2008

PINHEIRO JÓSE MAURICIO DOS SANTOS - Políticas de Backup Corporativos - Disponível em <http://www.projetoderedes.com.br/artigos/>, Pesquisado em 18/10/2008

ALBUQUERQUE, RICARDO - Segurança no Desenvolvimento - Segurança no Desenvolvimento de Software., 2002, Campus, Pesquisado em 0/1/1900

MATRIZ DE RESPONSABILIDADES - Gerenciamento de Aquisições - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 15/10/2008

"GUEDES, G.T.A. - Introdução à UML

UML 2 - Guia de Consulta Rápida, Edição 1, 2005, Novatec, Pesquisado em 0/1/1900"

MATRIZ DE RESPONSABILIDADES - Planejamento de recursos humanos: Ferramentas e Técnicas - PMBOK - Guia de Conhecimentos em Gerenciamento de Projetos, Edição 3, 2005, Project Management Institute, Pesquisado em 20/10/2008

INTRANET - Intranet - Wikipédia, Disponível em <http://pt.wikipedia.org/wiki/Intranet>, Pesquisado em 20/10/2008

CARVALHO, M. & RABECHINI JR, R. - Construindo Competências para Gerenciar Projetos. São Paulo.Editora Atlas S.A. 2005.


83

HARPHAM, A. - Just How Mature is Your Organization at Project Management Published on Dec 21, 2004. , Disponível em <http://www.allpm.com/modules.php?op=modload&name=News&file=article&sid=1280>

Documents

Gerenciamento de Projetos e Metodologia de SW