Área de gerência de projetos por cristiano born adriana ...siaibib01.univali.br/pdf/cristiano...

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

FERRAMENTA PARA AUXILIAR NO GERENCIAMENTO DE ESCOPO DE PROJETOS CONFORME O PMBOK

Área de Gerência de Projetos

por

Cristiano Born

Adriana Gomes Alves, M. Eng. Orientadora

Itajaí (SC), junho de 2009

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

FERRAMENTA PARA AUXILIAR NO GERENCIAMENTO DE ESCOPO DE PROJETOS CONFORME O PMBOK

Área de Gerência de Projetos

por

Cristiano Born Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Adriana Gomes Alves, M.Eng.

Itajaí (SC), junho de 2009

ii

SUMÁRIO

LISTA DE ABREVIATURAS................................................................ iv

LISTA DE FIGURAS .............................................................................. v

LISTA DE TABELAS.............................................................................vi RESUMO................................................................................................vii ABSTRACT...........................................................................................viii 1. INTRODUÇÃO....................................................................................9 1.1 PROBLEMATIZAÇÃO................................................................................... 9 1.1.1. Formulação do Problema............................................................................. 11 1.1.2 Solução Proposta .......................................................................................... 12 1.2 OBJETIVOS ................................................................................................... 12 1.2.1 Objetivo Geral.............................................................................................. 12 1.2.2 Objetivos Específicos.................................................................................... 12 1.3 METODOLOGIA........................................................................................... 12 1.4 ESTRUTURA DO TRABALHO ................................................................... 13

2. FUNDAMENTAÇÃO TEÓRICA ....................................................15 2.1 GERENCIAMENTO DE PROJETO............................................................ 15 2.1.1 Processos de Gerenciamento de Projetos .................................................... 16 2.1.2 Áreas do Conhecimento ............................................................................... 18 2.1.3 Processos de Gerenciamento de Projetos x Áreas do Conhecimento ........ 19 2.1.4 Gerenciamento do Escopo ........................................................................... 20 2.2 ANÁLISE DAS FERRAMENTAS PARA GERENCIAMENTO DE ESCOPO DE PROJETOS..................................................................................... 26

3. PROJETO ..........................................................................................30 3.1 REQUISITOS DA FERRAMENTA.............................................................. 30 3.1.1 Requisitos Funcionais .................................................................................. 30 3.1.2 Requisitos Não Funcionais........................................................................... 31 3.1.3 Regras de Negócio ........................................................................................ 32 3.2 DIAGRAMA DE CASOS DE USO ............................................................... 33 3.2.1 Módulo Principal.......................................................................................... 34 3.2.1.1 UC01.01. Carregar Projeto ................................................................... 38 3.2.1.2 UC01.02. Visualizar Projeto.................................................................. 39 3.2.1.3 UC01.03. Visualizar Plano de Gerenciamento ..................................... 39 3.2.1.4 UC01.04. Visualizar Declaração do Escopo ......................................... 40 3.2.1.5 UC01.05. Visualizar EAP ...................................................................... 40 3.2.1.5 UC01.06. Visualizar Dicionário da EAP............................................... 41 3.2.1.6 UC01.07. Criar Solicitação de Mudanças............................................. 41 3.2.1.7 UC01.08. Visualizar Solicitações de alterações .................................... 42

iii

3.2.1.8 UC01.09. Visualizar Histórico de Modificações................................... 43 3.2.1.9 UC01.10. Criar, Alterar ou Excluir Projeto......................................... 43 3.2.1.10 UC01.11. Criar, Alterar a Lista de Aprovadores................................. 44 3.1.2.11 UC01.12. Aprovar Projeto .................................................................... 45 3.2.1.12 UC01.13. Aprovar Plano de Gerenciamento........................................ 46 3.2.1.13 UC01.14. Aprovar Declaração do Escopo ............................................ 46 3.2.1.14 UC01.15. Aprovar EAP......................................................................... 47 3.2.1.15 UC01.16. Aprovar Dicionário da EAP ................................................. 47 3.2.1.16 UC01.17. Aprovar Solicitação de Mudança ......................................... 48 3.2.1.17 UC01.18. Criar o Plano de Gerenciamento.......................................... 49 3.2.1.18 UC01.19 Criar a Declaração do Escopo do Projeto............................. 50 3.2.1.19 UC01.20 Criar a EAP............................................................................ 51 3.2.1.20 UC01.21 Criar o Dicionário da EAP .................................................... 52 3.2.1.21 UC01.22. Verificar o Escopo do Projeto............................................... 53 3.2.2 Módulo Administrativo................................................................................ 53 3.2.2.1 UC02.01. Manter Empresa ................................................................... 54 3.2.2.2 UC02.01. Manter Usuário ..................................................................... 55 3.3 DIAGRAMA DE CLASSES .......................................................................... 55 3.4 DIAGRAMA DE ATIVIDADES ................................................................... 58

4. IMPLEMENTAÇÃO.........................................................................60 4.1 BANCO DE DADOS ...................................................................................... 60 4.2 SCRIPTCASE................................................................................................. 62 4.3 DRAW2D ........................................................................................................ 63

5. APRESENTAÇÃO DA FERRAMENTA.........................................64 5.1 MÓDULO ADMINISTRATIVO................................................................... 64 5.2 MÓDULO PRINCIPAL................................................................................. 65 5.3 PRINCIPAIS DIFICULDADES ENCONTRADAS..................................... 76

6. TESTES E VALIDAÇÃO..................................................................77

7. CONCLUSÃO ....................................................................................78 7.1 TRABALHOS FUTUROS ............................................................................. 79

REFERÊNCIAS BIBLIOGRÁFICAS..................................................80

iv

LISTA DE ABREVIATURAS

ABNT Associação Brasileira de Normas Técnicas AJAX Asynchronous Javascript And XML EAP Estrutura Analítica de Projeto ER Entidade Relacionamento GP Gerenciamento de Projetos GPL General Public License GTZ Deutsche Gesellschaft für Technische Zusammenarbeit GmbH HTTP Hypertext Transfer Protocol ISO International Organization of Standardization LGPL Lesser General Public License MS Microsoft Corporation NBR Normas Brasileiras OSS Open Source Software PDCA Plan – Do – Check – Act ou Planejar – Fazer – Verificar – Agir PDF Portable Document Format PHP Hypertext Preprocessor PMBOK Project Management Body of Knowledge PMI Project Management Institute SQL Structured Query Language TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí WBS Work Breakdown Structure WEB Word Wide Web ZOPP Ziel orientierte Projekt Planung

v

LISTA DE FIGURAS

Figura 1. Ciclo PDCA ...................................................................................................................16 Figura 2. Mapeamento entre os grupos de processos de gerenciamento de projetos e o ciclo PDCA.

..............................................................................................................................................17 Figura 3. Fluxograma de processos do gerenciamento do escopo de projetos .................................21 Figura 4. Exemplo de Estrutura Analítica de Projeto – EAP...........................................................24 Figura 5. Atores do Módulo Principal ............................................................................................33 Figura 6. Diagrama de Casos de uso do ator Usuário .....................................................................35 Figura 7. Diagrama de Casos de Uso do ator Autor........................................................................36 Figura 8. Diagrama de Casos de Uso do ator Responsável. ............................................................37 Figura 9. Diagrama de Casos de Uso do ator Gerente ....................................................................38 Figura 10. Diagrama de Caso de Uso do Módulo Administrativo...................................................54 Figura 11. Diagrama de Classes .....................................................................................................57 Figura 12. Diagrama de Atividades................................................................................................59 Figura 13. Interface Principal do MySQL Workbench ...................................................................60 Figura 14. Diagrama de Entidade Relacionamento.........................................................................61 Figura 15. Interface principal do framework ScriptCase.................................................................63 Figura 16. Módulo Administrativo - Manter Cadastro de Empresa/ Organização. ..........................64 Figura 17. Módulo Administrativo – Manter Cadastro de Usuário .................................................65 Figura 18. Módulo Principal - Tela de Acesso ao sistema. .............................................................66 Figura 19. Módulo Principal - Menu..............................................................................................66 Figura 20. Módulo Principal - Cadastro de Projeto.........................................................................67 Figura 21. Módulo Principal - Cadastro de Aprovadores................................................................68 Figura 22. Módulo Principal - Aprovação de Projeto .....................................................................69 Figura 23. Módulo Principal – Carregar Projeto.............................................................................70 Figura 24. Módulo Principal - Declaração do Escopo ....................................................................71 Figura 25. Módulo Principal - Estrutura Analítica do Projeto - Modo Textual................................72 Figura 26. Módulo Principal - Estrutura Analítica do Projeto em Modo Gráfico. ...........................73 Figura 27. Módulo Principal - Dicionário da EAP..........................................................................74 Figura 28. Módulo Principal - Criação de Solicitação de Alteração no Escopo do Projeto..............75 Figura 29. Módulo Principal - Visualizar Solicitações de Alteração no Escopo..............................76

vi

LISTA DE TABELAS

Tabela 1. Resumo das áreas do conhecimento conforme PMBOK. ................................................18 Tabela 2. Processos de Gerenciamento de projetos x Áreas do conhecimento ................................19 Tabela 3. Funcionalidades dos softwares avaliados e da ferramenta proposta .................................28 Tabela 4. Características gerais dos softwares avaliados e da ferramenta proposta .........................28 Tabela 5. Cenário UC01.01. Carregar Projeto ................................................................................39 Tabela 6. Cenário UC01.02. Visualizar Projeto..............................................................................39 Tabela 7. Cenário UC01.03. Visualizar Plano de gerenciamento do Projeto ...................................40 Tabela 8. Cenário UC01.04. Visualizar Declaração do Escopo ......................................................40 Tabela 9. Cenário UC01.05. Visualizar EAP .................................................................................41 Tabela 11. Cenário UC01.06. Visualizar Dicionário da EAP.............Erro! Indicador não definido. Tabela 12. Cenário UC01.07. Criar Solicitação de Mudança..........................................................42 Tabela 13. Cenário UC01.08. Listar Solicitações de Mudança .......................................................42 Tabela 14. Cenário UC01.09. Gerar Histórico de Modificações .....................................................43 Tabela 15. Cenário UC01.10. Criar, Alterar ou Excluir Projeto......................................................44 Tabela 16. Cenário UC01.11. Criar, Alterar a Lista de Aprovadores ..............................................45 Tabela 17. Cenário UC01.12. Aprovar Projeto...............................................................................45 Tabela 18. Cenário UC01.13. Aprovar Plano de Gerenciamento ....................................................46 Tabela 19. Cenário UC01.14. Aprovar Declaração do Escopo .......................................................47 Tabela 20. Cenário UC01.15. Aprovar EAP...................................................................................47 Tabela 21. Cenário UC01.16. Aprovar Dicionário da EAP............................................................48 Tabela 22. Cenário UC01.17. Aprovar Solicitação de Mudança.....................................................49 Tabela 23. Cenário UC01.18. Criar o Plano de Gerenciamento ......................................................49 Tabela 24. Cenário UC01.19. Criar a Declaração do Escopo do Projeto.........................................50 Tabela 25. Cenário UC01.20. Criar a EAP.....................................................................................51 Tabela 26. Cenário UC01.21. Criar o Dicionário da EAP...............................................................52 Tabela 27. Cenário UC01.22. Verificar o Escopo do Projeto..........................................................53 Tabela 28. Cenário UC02.01. Manter Empresa ..............................................................................54 Tabela 29. Cenário UC02.02. Manter usuário. ...............................................................................55

vii

RESUMO

BORN, Cristiano. Ferramenta para auxiliar no gerenciamento de escopo de projetos conforme o PMBOK. Itajaí, 2009. 81 p. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. Este Trabalho de Conclusão de Curso teve como objetivo o desenvolvimento de uma ferramenta computacional que auxilie o gerenciamento do escopo de projetos, seguindo o Guia PMBOK – 3ª Edição (Project Management Body of Knowledge). Nele são destacadas a grande importância do gerenciamento de projetos e a necessidade da utilização de uma metodologia para gerenciamento de projetos. É dada ênfase ao gerenciamento de escopo de projetos, mais especificamente aos processos que fazem parte do gerenciamento do escopo: planejamento do escopo, definição do escopo, criação da estrutura analítica do projeto (EAP), verificação do escopo e controle do escopo. Um dos motivos para a realização deste trabalho foi a dificuldade encontrada para gerenciar o escopo de projetos utilizando as ferramentas computacionais disponíveis no mercado. A ferramenta computacional desenvolvida é voltada para a WEB e foi desenvolvida na linguagem de programação PHP e utilizando o banco de dados MySQL. Foram utilizadas as ferramentas ScriptCase para construção dos layout’s e também o componente Draw2D para construção da Estrutura Analítica do Projeto. Palavras-chave: PMBOK. Gerenciamento de Projetos. Escopo.

viii

ABSTRACT

This Final Work aims to developed tool to assist the project management according to the PMBOK Guide - 3rd edition (Project Management Body of Knowledge). This guide points out the importance of project management and the need for using a methodology. Emphasis is placed on the project scope management, in particular the processes that are part of the scope management: scope planning, scope definition, creation of the work’s breakdown structure, scope verification, and scope control. One of the major reasons for this work was the difficulty to manage projects scopes using the computational tools available in the market. The modeling of the system of this Final Work, highlighting use cases diagrams, classes diagrams and prototypes for the system’s main screens. The computational tool will be focused on the WEB, being developed in the PHP programming language and using the MySQL database. Keywords: PMBOK. Project Management. Scope.

1. INTRODUÇÃO

Com certa freqüência, os termos “projetos” e “gerenciamento de projetos” são ditos no dia-

dia, porém o significado dessas expressões pode ser entendido de diversas maneiras por pessoas

diferentes. A palavra “projeto” pode significar um plano, uma proposta ou um empreendimento.

Nas empresas, em geral, “projeto” se refere a um conjunto de atividades relacionadas umas às

outras, envolvendo um grupo de pessoas que trabalham em conjunto para alguma atividade que será

realizada uma única vez, durante um período de tempo determinado (DUFFY, 2007).

Segundo a norma NBR/ISO 10006 (ABNT, 2000), projeto é “um processo único,

consistindo em um grupo de atividades coordenadas e controladas com datas para início e término,

empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de

tempo, custo e recursos”.

De forma semelhante, o PMI - Project Management Institute (PMI, 2004) define projeto

como “um empreendimento único, com início e fim determinados, que utiliza recursos e é

conduzido por pessoas, visando atingir objetivos predefinidos”.

Basicamente, o projeto se caracteriza por ser: temporário, exclusivo e progressivo (PMI,

2004). Ou seja, os projetos possuem um início e fim determinados, todo produto ou serviço gerado

por um projeto é exclusivo e a sua elaboração é progressiva, fazendo com que o mesmo seja

desenvolvido em etapas e continuado através de incrementos.

1.1 Problematização

Os projetos estão presentes em todas as organizações, pois são instrumentos fundamentais

para qualquer atividade de mudança e geração de produtos e serviços. A pesquisa de um novo

produto, a construção de um edifício, o desenvolvimento de um software, o lançamento de um novo

produto ou serviço são exemplos de projetos. Desta forma, gerenciar projetos de forma eficiente é

um dos grandes desafios dos executivos da atualidade (SOTILLE et al., 2007).

A globalização, as novas tecnologias, a reestruturação das organizações e a busca pela

eficiência na gestão empresarial tornam o gerenciamento de projetos assunto fundamental para a

sobrevivência e crescimento das organizações. Com o crescente aumento do número de projetos, da

10

necessidade por resultados mais rápidos, com mais qualidade e menor custo, cada vez é maior a

importância do bom gerenciamento de projetos (DINSMORE, 2007).

A importância no gerenciamento de projetos pode ser comprovada pelos estudos como o do

Standish Group (THE STANDISH GROUP, 2004) que indicam que somente 29% dos projetos

mundiais são bem-sucedidos ao cumprir o orçamento, cronograma e qualidade planejados.

Entretanto, os mesmos estudos indicam uma taxa de sucesso de 75% para projetos que empregam

conceitos modernos de gerenciamento de projetos. Esses fatos compõem as forças por trás do

enorme interesse em técnicas modernas de gerenciamento de projetos como as descritas no

PMBOK (PMBOK® Guide: A guide to the Project Management Body of Knowledge – Third

edition), nas quais o presente trabalho tem como base de estudos.

Segundo Kimons (2001) o sucesso do projeto pode depender de fatores variados. Dentre os

quais se destacam:

Definição adequada e precisa do escopo;

Boa definição e priorização das razões para se fazer o projeto;

Entendimento dos riscos potenciais que podem afetar o projeto;

Um bom plano de gerenciamento de riscos;

Incorporação rápida de cada mudança aprovada de escopo;

A confecção de um plano de execução logo após a definição da estratégia do projeto; e

Início imediato da execução de um plano de recuperação quando detectados desvios do

realizado em comparação com o projetado.

Outro estudo que merece destaque é o Benchmarking em Gerenciamento de Projetos Brasil:

relatório 2004 (PINTO, 2005), que lista os problemas que ocorrem com maior freqüência nos

projetos, relatados pelos pesquisadores, em ordem decrescente:

1. Não cumprimento dos prazos estabelecidos;

2. Mudanças de escopo constantes;

3. Problemas de comunicação;

4. Recursos humanos insuficientes;

11

5. Riscos não avaliados corretamente;

6. Mudanças de prioridade constantes;

7. Escopo do projeto com nível de detalhe insuficiente;

8. Não-cumprimento do orçamento estabelecido;

9. Disputas por recursos entre gerências funcionais e o gerente de projetos;

10. Problemas na administração do trabalho/contratos de terceiros;

11. Problemas políticos;

12. Produtos mal especificados;

13. Problemas culturais;

14. Expectativa do cliente (interno ou externo) desalinhada com a realidade do projeto;

15. Falta de autoridade do gerente de projetos;

16. Recursos humanos sem as competências necessárias;

17. Recursos financeiros insuficientes; e

18. Falta de apoio da alta administração.

Já Sotille et al. (2007) afirma que parte dos problemas em projetos é decorrente da falta de

planejamento e controle do escopo. A questão é determinar o que se pretende fazer, e a falha nessa

determinação causa incremento não desejado do escopo, atrasos no cronograma, custos acima do

previsto, falta de recursos e pessoal, mudanças de requisitos e especificações abaixo do esperado,

produtos que não satisfazem o cliente e até mesmo o cancelamento do projeto.

1.1.1. Formulação do Problema

Diante desses fatos, pode-se perceber a importância do gerenciamento de projetos e em

específico a importância do gerenciamento de escopo de projetos. Os processos de gerenciamento,

planejamento, controle e definição do escopo são críticos para o sucesso do projeto como um todo.

E este é um dos fatores que impulsionaram a realização deste Trabalho de Conclusão de Curso,

visto que uma ferramenta computacional que possibilite um melhor gerenciamento de escopo de

projetos é de grande valia para a execução de qualquer projeto.

12

1.1.2 Solução Proposta

Diante da importância do gerenciamento do escopo de projetos, este Trabalho de Conclusão

de Curso apresenta o estudo das recomendações do Guia PMBOK enfatizando a área de

gerenciamento do escopo. Foi realizado o levantamento de requisitos de uma ferramenta de

gerenciamento de escopo, o estudo das ferramentas similares e também foi desenvolvida uma

ferramenta computacional que proporcione ao gerente de projetos e todos os interessados, o

gerenciamento do escopo de projeto conforme as recomendações do Guia PMBOK terceira edição.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

O objetivo geral foi o desenvolvimento de uma ferramenta computacional que apóie o

gerenciamento do escopo de projeto, conforme recomendações do Guia PMBOK terceira edição.

1.2.2 Objetivos Específicos Compreender o processo de gerenciamento de projetos conforme as recomendações do

Guia PMBOK, com ênfase na área de Gerenciamento de Escopo;

Pesquisar e analisar soluções de software similares;

Determinar os requisitos exigidos pelo sistema;

Pesquisar os conceitos e tecnologias necessários à implementação do sistema;

Realizar a modelagem conceitual do sistema;

Implementar o sistema;

Testar e validar a implementação do sistema; e

Documentar o desenvolvimento e os resultados do sistema.

1.3 Metodologia

A metodologia deste trabalho foi dividida em duas etapas principais: (1) estudo /

embasamento teórico e modelagem do sistema, e (2) desenvolvimento / implementação do projeto.

Na etapa de estudo e embasamento teórico foi desenvolvida a fundamentação teórica,

utilizando na pesquisa diversos livros, artigos publicados e pesquisas realizadas por diversos

13

autores. Foi nesta etapa que se definiu o tema/problema deste projeto e adquiriu-se o conhecimento

necessário sobre as soluções e tecnologias existentes com o objetivo de poder propor a solução mais

adequada e eficiente para a solução do problema.

Na etapa de modelagem o objetivo principal foi especificar completamente o funcionamento

da solução proposta criando o modelo conceitual, definindo os requisitos tanto funcionais quanto

não funcionais, as regras do negócio e modelos de casos de uso.

Na etapa de implementação foi desenvolvido o projeto da ferramenta computacional

conforme o projeto elaborado na etapa de modelagem. No desenvolvimento da ferramenta, foi

utilizado o componente gráfico Draw2D (HERZ, 2008), que possibilita através de uma biblioteca de

Javascript, a criação de gráficos para a construção da EAP. Também foram estudados framewoks

para o desenvolvimento da aplicação, optando pela utilização da ferramenta ScriptCase, visto que a

mesma facilita e agiliza o desenvolvimento de sistemas voltados para Web.

Após a implementação, foram realizados testes que tinham como finalidade avaliar as

funcionalidades desenvolvidas conforme os requisitos levantados durante o projeto, para isto, foram

utilizados estudos de casos reais de projetos desenvolvidos pela orientadora e pelo acadêmico autor

deste TCC. Os resultados foram documentados, com aprovação das operações ou com as devidas

correções dos erros em caso de falhas apresentadas durante o período de testes.

Também foi desenvolvida a documentação requerida para futuras pesquisas, citando os

resultados alcançados e as conclusões formadas pelo trabalho realizado.

1.4 Estrutura do trabalho

O trabalho está dividido em sete capítulos. O primeiro capítulo é a introdução, onde são

abordados alguns conceitos de projetos, a importância do gerenciamento de projetos e é apresentado

o problema. Neste capítulo também são abordados os objetivos do trabalho bem como a

metodologia utilizada para a realização do mesmo.

No segundo capítulo é apresentada uma revisão bibliográfica baseada principalmente em

livros e no Guia PMBOK. São abordados temas de gerenciamento de projetos, seus processos e

principalmente gerenciamento de escopo de projetos que é o foco deste trabalho. Neste capítulo

também são apresentadas algumas ferramentas similares ao projeto proposto, de forma a avaliar

suas funcionalidades e aderência ao escopo de projeto conforme definido pelo PMBOK.

14

Já no terceiro capítulo é apresentado o projeto do sistema, onde são apresentados os

requisitos funcionais e não funcionais da ferramenta, regras de negócio, além dos diagramas de

casos de uso, classes e atividades.

No quarto (Implementação) e no quinto (Apresentação da Ferramenta) capítulo são

apresentados os resultados obtidos durante a implementação do sistema, descrevendo as

funcionalidades implementadas.

O sexto capítulo apresenta os testes e resultados obtidos com o uso da ferramenta, com o

objetivo de avaliar a usabilidade da ferramenta desenvolvida, a conformidade com os requisitos

propostos e também verificar o funcionamento da ferramenta nos principais navegadores.

No sétimo capítulo são apresentadas as considerações finais, lições apreendidas,

dificuldades encontradas durante o desenvolvimento e sugestões para trabalhos futuros que possam

vir a aprimorar e expandir as funcionalidades da ferramenta para contemplar os demais processos

do gerenciamento de projetos.

15

2. FUNDAMENTAÇÃO TEÓRICA

O presente trabalho tem como base o PMBOK: Um guia do conjunto de conhecimentos em

Gerenciamento de Projetos - Terceira edição (PMBOK® Guide: A guide to the Project

Management Body of Knowledge – Third edition) (PMI, 2004). Lançado pelo PMI no ano de 1996,

o PMBOK está em sua terceira edição (2004), nele estão práticas tradicionais comprovadas e

amplamente aplicadas, além de práticas inovadoras que estão surgindo para o gerenciamento de

projetos.

Além do PMBOK, trabalho teve como base de estudo ferramentas similares já existentes

para gerenciamento de escopo de projetos. Foram estudadas as funcionalidades, características,

pontos fortes e fracos de cada ferramenta, projetada e desenvolvida a nova ferramenta com a

finalidade de um melhor e mais eficaz gerenciamento de escopo de projetos de acordo com o

PMBOK.

2.1 Gerenciamento de Projeto

Segundo Sotille et al.(2007) o gerenciamento de projetos é descrito por muitos como

“ciência para conseguirmos obter os resultados”. Trata-se de iniciar, planejar, executar e controlar

projetos até seu encerramento ordenado, consistindo na aplicação de conhecimentos, habilidades,

ferramentas e técnicas com o objetivo de atingir ou até mesmo superar as necessidades e

expectativas dos clientes e demais interessados no projeto.

Segundo Prado (2000), a boa prática de gerenciamento de projetos produz resultados

bastante expressivos para as organizações dentre os quais é possível destacar:

Redução de custos e prazos de desenvolvimento de novos produtos;

Aumento no tempo de vida dos novos produtos;

Aumento de vendas e receita;

Aumento do número de clientes e de sua satisfação; e

Aumento da chance de sucesso nos projetos.

O gerenciamento de projetos é composto por processos, os quais são destacados na próxima

seção.

16

2.1.1 Processos de Gerenciamento de Projetos

Para melhor planejar, executar e controlar um projeto, o mesmo é dividido em partes

menores, que são chamadas de fases ou processos. De acordo com o PMBOK (PMI, 2004), os

processos de gerenciamento de projetos são classificados em cinco grupos:

Iniciação;

Planejamento;

Execução;

Monitoramento / Controle; e

Encerramento.

Esses grupos de processos se sobrepõem e interagem de diversas formas trocando

informações entre si conforme o andamento do projeto. Muitas vezes os resultados de um processo

são entradas para a execução de outro processo, ou então são efetivamente as entregas do projeto

(PMI, 2004). A integração desses cinco grupos de processos faz uma analogia ao ciclo PDCA

(Plan – Do – Check – Act ou Planejar – Fazer – Verificar – Agir), muito utilizado na administração

em geral, este ciclo aprimorado descreve o conjunto de processos que devem ser seguidos para que

um projeto seja bem gerenciado. A Figura 1 ilustra o ciclo PDCA.

Figura 1. Ciclo PDCA Fonte: IMAI (1996), p.12.

Conforme o PMBOK (PMI, 2004), o grupo de Planejamento corresponde ao “Planejar” do

ciclo PDCA, o processo de execução, ao “Fazer”, os processos de monitoramento e controle

englobam “Verificar” e “Agir”. Além disso, como os projetos são finitos, o PMBOK ainda

17

caracteriza os grupos de processos que iniciam (Iniciação) e finalizam (Encerramento) um projeto

(PMI, 2004). Desta forma, a Figura 2 mostra o relacionamento entre os grupos de processos de

gerenciamento de projetos e o ciclo PDCA.

Figura 2. Mapeamento entre os grupos de processos de gerenciamento de projetos e o ciclo PDCA. Fonte: Adaptado de PMI (2004).

Além das funções básicas correspondentes ao ciclo PDCA, os processos de gerenciamento

de projetos são caracterizados da seguinte forma, segundo o PMBOK (PMI, 2004):

1. Processos de Iniciação: Define e autoriza o início do projeto ou uma de suas fases.

2. Processos de Planejamento: Define e refina os objetivos do projeto, planeja as ações

a serem realizadas e também o escopo do projeto.

3. Processos de Execução: Coordena os recursos físicos (pessoas, materiais e

equipamentos) para realizar o que foi planejado.

4. Processos de Monitoramento / Controle: Mede e monitora o progresso do projeto,

visando identificar os desvios do plano, de maneira a implementar ações corretivas,

quando necessárias.

5. Processos de Encerramento: Formaliza a aceitação do produto, serviço ou resultado

ou fase do projeto. Além de comunicar todos interessados sobre tais eventos,

arquivamento e aceitação final da fase ou do projeto.

18

O gerenciamento de projetos é realizado através destes cinco processos, com a aplicação dos

conhecimentos, habilidades, ferramentas e técnicas para projetar e controlar as atividades do projeto

com o objetivo de atingir seus requisitos (PMI, 2004). Sendo assim, o PMBOK propõe nove áreas

de conhecimento que são necessárias para o bom gerenciamento de projetos. Na seção 2.1.2 são

especificadas cada uma dessas nove áreas do conhecimento.

2.1.2 Áreas do Conhecimento

Segundo Dinsmore (2007), para atingir completamente o objetivo do projeto, aplicando os

conhecimentos, habilidades e técnicas, o PMBOK propõe nove áreas de conhecimento: integração,

escopo, tempo, custo, qualidade, recursos humanos, comunicações, risco e aquisições. Essas áreas

descrevem os conhecimentos e as boas práticas relacionadas ao gerenciamento de projetos com base

nos processos que as compõem. A Tabela 1 apresenta um resumo das nove áreas do conhecimento

conforme o PMBOK (PMI, 2004).

Tabela 1. Resumo das áreas do conhecimento conforme PMBOK.

Área do conhecimento Descrição Integração

Engloba todos os processos e decisões necessárias para assegurar que o resultado final seja como o esperado, é nesta etapa que ocorre a integração de todas as peças do projeto.

Escopo Engloba os processos necessários para assegurar que sejam executadas todas e somente as atividades necessárias à realização do projeto. Consiste nos processos de iniciação, planejamento do escopo, definição do escopo, verificação do escopo e controle de alterações do escopo.

Tempo Engloba os processos necessários para assegurar a conclusão do projeto no prazo previsto.

Custos Engloba os processos necessários para garantir que o projeto seja concluído dentro do orçamento aprovado.

Qualidade Engloba os processos necessários para assegurar que o projeto seja concluído com a qualidade desejada, conforme os requisitos, especificações e adequação ao uso.

Recursos Humanos Engloba os processos necessários para a utilização mais efetiva do pessoal envolvido no projeto.

Comunicações Engloba os processos necessários para garantir a geração, coleta, divulgação, armazenagem e controle das informações do projeto.

Riscos Engloba os processos que procuram maximizar os eventos positivos e minimizar as conseqüências negativas aos objetivos do projeto.

Aquisições Engloba os processos necessários para a aquisição de bens e serviços externos para cumprir o escopo do projeto.

19

2.1.3 Processos de Gerenciamento de Projetos x Áreas do Conhecimento

A Tabela 2 representa o cruzamento dos cinco processos de gerenciamento de projetos e as

nove áreas do conhecimento em gerenciamento de projetos, demonstrando a interação dos mesmos.

Tabela 2. Processos de Gerenciamento de projetos x Áreas do conhecimento

Processos de Gerenciamento de Projetos Áreas do Conhecimento Iniciação Planejamento Execução Monitoramento

e Controle Encerramento

Integração X X X X X Escopo X X Tempo X X Custos X X

Qualidade X X X Recursos Humanos

X X X

Comunicação X X X Riscos X X

Aquisições X X X X

Fonte: Adaptado de PMI (2004).

No grupo de processos de iniciação de projetos, a área de integração do gerenciamento de

projetos está presente, pois é através desta área que é desenvolvido o termo de abertura do projeto e

também a declaração do escopo preliminar do projeto (PMI, 2004). Já o grupo de processos de

planejamento necessita de todas as nove áreas do conhecimento, podendo destacar as atividades de

desenvolvimento do plano de gerenciamento do projeto, planejamento de escopo, desenvolvimento

de cronograma, estimativas de custos e tempo, planejamento de qualidade, recursos humanos,

comunicações, identificação e análise dos riscos, e também o planejamento de aquisições (PMI,

2004).

Durante o processo de execução de projetos, a área de integração do projeto está presente,

pois é através dela que é orientada e gerenciada a execução do projeto. A área de qualidade do

projeto também se faz presente durante a execução, para que seja garantida a qualidade do projeto.

A área de recursos humanos para contratar ou mobilizar a equipe do projeto e também para

desenvolver a equipe. A comunicação para garantir a distribuição das informações durante a

execução. Já a área de aquisições também está presente no processo de execução para que sejam

selecionados os fornecedores e solicitadas suas respostas (PMI, 2004).

20

O processo de monitoramento e controle necessita de todas as áreas do conhecimento, pois

este processo monitora e controla todos os aspectos do projeto, incluindo então as nove áreas do

conhecimento (PMI, 2004). E no grupo de processos de encerramento de projeto, estão presentes as

áreas de integração e aquisições, com as funções, respectivamente de encerrar o projeto e encerrar o

contrato do projeto (PMI, 2004).

2.1.4 Gerenciamento do Escopo

Por se tratar da área do conhecimento na qual o presente trabalho está sendo realizado, o

estudo do gerenciamento do escopo é mais aprofundado e o mesmo é mais detalhado nesta seção.

Segundo o PMBOK (PMI, 2004), a gerência do Escopo do Projeto abrange os processos

necessários para garantir que a equipe realize todo e somente o trabalho necessário para que o

projeto seja bem-sucedido. “O gerenciamento do escopo do projeto trata principalmente da

definição e controle do que está e do que não está incluído no projeto” (PMI, 2004, p. 103).

Dentre as nove áreas do conhecimento em gerenciamento de projetos, o gerenciamento de

escopo é uma das áreas mais importantes de todo processo de gerenciamento. A importância dessa

área se deve ao fato de que um dos motivos mais comuns de fracasso de um projeto, normalmente

está relacionado a falhas no gerenciamento de escopo de projetos (PEREIRA, 2005).

É comum encontrar projetos cujo escopo não é claro e bem definido (PEREIRA, 2005). Esta

indefinição pode acarretar em diversos problemas para o gerente de projetos, prejudicando

estimativas de custos, prazos e recursos necessários para o projeto. Ao contrário de quando se tem

um escopo bem definido, pois o gerente de projetos tem a possibilidade de gerenciar de maneira

eficiente o projeto, fazendo com que todos saibam o que está dentro dos limites do projeto e o que

está fora dos limites. Assim, toda mudança de escopo durante o andamento do projeto, pode ser

controlada e calculadas novas estimativas de custos, prazos e recursos necessários para o projeto.

Segundo o PMI (2004), o gerenciamento de escopo de projetos possui cinco principais

processos e cada um deles ocorre pelo menos uma vez em todos os projetos:

Planejamento do Escopo;

Definição do Escopo;

Criar a EAP – Estrutura Analítica do Projeto;

Verificação do Escopo; e

21

Controle do Escopo.

De maneira análoga a gerência de projetos, os processos de gerenciamento de escopo

interagem entre si e também com processos das outras áreas de conhecimento. A Figura 3 mostra

essa interação dos processos do gerenciamento do escopo e demais processos que participam desta

interação.

Figura 3. Fluxograma de processos do gerenciamento do escopo de projetos

Fonte: Adaptado de PMI (2004).

2.1.4.1 Planejamento do Escopo

O processo de planejamento do escopo é o processo de elaboração e documentação da

estratégia que será utilizada para o desenvolvimento do trabalho a ser realizado durante o projeto

(XAVIER, 2005). Este processo tem como objetivo fundamental, prover uma orientação consistente

e realista do que deve ser gerado pelo projeto e de como isso deve ser executado e controlado

(SOTILLE et al., 2007).

22

O resultado do processo de planejamento de escopo é o plano de gerenciamento de escopo.

A principal finalidade deste plano é descrever como o projeto deve ter seu escopo gerenciado e

como as mudanças do projeto devem ser incorporadas ao mesmo (DINSMORE, 2007).

Segundo o PMI (2004), os principais componentes do plano de gerenciamento de escopo

são:

Roteiro de preparação de uma declaração detalhada do escopo, com base na declaração

preliminar do projeto, bem como o tratamento de suas mudanças;

Procedimentos para construção da estrutura analítica de projeto (EAP), com as

respectivas regras para sua aprovação e manutenção ao longo do projeto; e

Procedimentos para a verificação e aceitação formal das entregas do projeto.

O plano de gerenciamento do escopo do projeto pode ser informal e genérico ou formal e

bem detalhado, de acordo com o porte do projeto, seu impacto sobre a organização, riscos

envolvidos, prazos, recursos disponíveis e necessários (SOTILLE et al., 2007).

2.1.4.2 Definição do Escopo

Durante o processo de definição do escopo são descritos e definidos mais especificamente as

necessidades, desejos e expectativas dos interessados no projeto e convertidos em requisitos do

projeto. A definição do escopo é o processo de subdivisão das principais entregas do projeto em

componentes menores e mais gerenciáveis, assim como o trabalho necessário para criar estas

entregas (PMI, 2004).

Segundo Dinsmore (2007) este processo está baseado na idéia de que uma descrição clara

sobre o trabalho a ser realizado é insuficiente para o controle do escopo do projeto, sendo assim, é

necessário que se transforme esta descrição em entregas ou resultados concretos do trabalho a ser

realizado, para que se tenha a possibilidade de acompanhar e controlar o escopo do projeto. Esta

subdivisão dos principais produtos é realizada até que elas cheguem a um nível de detalhe suficiente

para auxiliar a equipe de gerenciamento do projeto na definição das atividades do projeto.

A declaração do escopo além de fornecer um detalhamento do projeto, permite que a equipe

do projeto realize um planejamento mais detalhado, orienta o trabalho durante a execução, fornece

uma linha base para avaliar as solicitações de mudanças e verifica se estão dentro ou fora do limite

do projeto. A declaração detalhada do escopo inclui diretamente ou indiretamente (PMI, 2004):

23

Objetivos, especificações, restrições e premissas do projeto;

Descrição do escopo do produto assim como seus critérios de aceitação;

Requisitos, limites e entregas do projeto;

Organização inicial do projeto;

Riscos iniciais definidos;

Marcos do cronograma;

Recursos financeiros e estimativas de custos;

Requisitos do gerenciamento de configuração do projeto; e

Requisitos de aprovação.

Segundo Dinsmore (2007), o processo de definição do escopo possibilita uma melhor

precisão das estimativas de custo, duração e recursos necessários para o projeto. Além de facilitar as

designações de responsabilidades aos membros da equipe do projeto.

2.1.2.3 Criar a Estrutura Analítica de Projeto - EAP

Estrutura Analítica de Projeto - EAP é a expressão da língua portuguesa para Work

Breakdown Structure – WBS. Segundo o PMI (2004) ela é “uma decomposição hierárquica

orientada à entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do

projeto e criar as entregas necessárias” (PMI, 2004, p. 112).

A EAP, por meio de uma estrutura semelhante a um organograma, representa o que deverá

ser entregue pelo projeto. Isto é, ela organiza e define o escopo total do projeto, permitindo detalhar

quais entregas devem ser geradas pelo projeto a partir dos seus objetivos. Segundo o PMI (2004), a

EAP subdivide o trabalho do projeto em partes menores e mais facilmente gerenciáveis, contendo

em cada nível mais baixo da estrutura, uma definição mais detalhada do trabalho do projeto. A

Figura 4 mostra um exemplo de estrutura analítica de projeto (EAP) de um projeto de software.

Segundo Sotille et al. (2007), a organização das entregas por meio da EAP vem sendo

bastante utilizada nos projetos do mundo todo, pois permite o esclarecimento a todos os

interessados no projeto sobre o que se espera em termos de resultados do projeto, e

conseqüentemente, do que será monitorado e controlado. Através desta estrutura, é possível estimar

custos, agendar, controlar e monitorar o trabalho do projeto.

24

Um dos processos necessários para a construção da EAP é a decomposição que segundo o

PMI (2004), é uma técnica que subdivide o escopo do projeto e as entregas do projeto em

componentes menores e mais fácil de gerenciar. Esta decomposição é realizada até que o trabalho

do projeto necessário para realização do escopo do projeto e ao fornecimento das entregas seja

definido em detalhes suficientes para dar suporte à execução, monitoramento e controle do trabalho.

Figura 4. Exemplo de Estrutura Analítica de Projeto – EAP. Fonte: PMI (2004).

Segundo o PMI (2004) a decomposição do trabalho total do projeto normalmente envolve as

seguintes atividades:

Identificação das entregas e do trabalho relacionado;

Estruturação e organização da EAP;

Decomposição dos níveis mais altos da EAP em componentes detalhados de nível mais

baixo;

Desenvolvimento e atribuição de códigos de identificação aos componentes da EAP; e

Verificar se o grau de decomposição do trabalho é necessário e suficiente.

Cabe lembrar que a subdivisão deve ser feita de tal forma que cada uma das entregas ou

subprojetos representa produtos, serviços ou resultados verificáveis. Sendo que cada um desses

componentes deve ter especificado a unidade organizacional que irá executar este componente do

25

projeto e tais componentes também são definidos em termos de como o trabalho do projeto será

realmente executado e controlado (PMI, 2004).

O principal documento gerado pelo processo de Criar a EAP é a própria EAP. Outro

importante documento que dá suporte a EAP é chamado de dicionário da EAP, este documento é

um complemento da EAP. Nele contém o detalhamento dos componentes contidos em uma EAP,

inclusive pacotes de trabalho (elementos do nível inferior), podendo incluir informações de

planejamento, tais como prazos, orçamentos, riscos, qualidade, assim como a declaração do

trabalho, a organização responsável e uma lista de marcos do cronograma (PMI, 2004).

2.1.4.4 Verificação do Escopo

Segundo o PMI (2004), a verificação do escopo é o processo de obtenção da aprovação

formal do escopo do projeto por parte de seus interessados. A verificação do escopo do projeto visa

garantir que as entregas do projeto e os resultados do trabalho foram realizados de maneira

satisfatória.

Vale lembrar que a verificação do escopo se difere do processo de controle de qualidade,

embora ambos possam ocorrer paralelamente. A verificação do escopo busca garantir a aceitação do

trabalho realizado, enquanto o controle de qualidade busca verificar o quanto os resultados ou

entregas atendem os padrões de qualidade exigidos pelo projeto (DINSMORE, 2007).

Segundo o PMI (2004, p. 119) “este processo documenta as entregas terminadas que foram

aceitas. As entregas que não foram aceitas são documentadas juntamente com as razões da não

aceitação”.

2.1.4.5 Controle do Escopo

O controle do escopo envolve processos, procedimentos e padrões que são usados para

gerenciar as mudanças do escopo do projeto, assim como o controle do impacto dessas mudanças.

Segundo Dinsmore (2007), tais procedimentos visam garantir a documentação, relato, análise,

custeamento, aprovação e implementação das mudanças no projeto.

A fim de se ter um total controle do escopo do projeto, o PMI (2004) sugere a utilização de

algumas ferramentas e técnicas tais como:

26

1. Sistema de Controle de Mudanças: Este sistema define os procedimentos para efetuar

as mudanças no escopo do projeto e no escopo do produto.

2. Análise da variação: Visa avaliar a extensão da variação, determinar a causa da

variação do escopo e decidir se são necessárias ações corretivas.

3. Re-planejamento: As solicitações de mudança aprovadas que afetam o escopo podem

exigir alterações na EAP e no dicionário da EAP, na declaração do escopo do projeto

e no plano de gerenciamento do escopo do projeto. Podendo resultar em atualizações

nos componentes do plano de gerenciamento do projeto.

4. Sistema de gerenciamento de configuração: Fornece procedimentos para obtenção da

situação das entregas e garante que as mudanças solicitadas no escopo do projeto

serão cuidadosamente documentadas e consideradas, antes de serem processadas

pelo Controle Integrado de mudanças.

Segundo o PMI (2004), com o controle do escopo, é possível gerenciar as mudanças

solicitadas e também as ações corretivas recomendadas para o melhor desenvolvimento do projeto.

Permitindo, através das mudanças já aprovadas, a atualização dos seguintes itens:

Declaração do escopo do projeto;

EAP - Estrutura Analítica do Projeto;

Dicionário da EAP;

Linha da base do escopo;

Ativos de processos organizacionais; e

Plano de gerenciamento do projeto.

2.2 Análise das ferramentas para gerenciamento de Escopo de projetos

Com o intuito de apoiar a análise e projeto da ferramenta para Gerência de Escopo de

projetos, objetivo deste TCC, foram estudadas algumas ferramentas disponíveis no mercado. As

ferramentas selecionadas para análise são freqüentemente utilizadas por gerentes de projetos e suas

equipes para auxiliá-los na gestão de projetos. A análise foi feita através de dois aspectos:

funcionais e não funcionais. Os softwares avaliados e suas respectivas versões são os seguintes:

27

1. MS-Project 2007 - Microsoft Office Project Standard 2007

2. Project Builder

3. VPMI Professional – Virtual

4. DotProject 2.1.2

5. WBS Chart Pro 4.7

O MS-Project 20071 é um software desenvolvido pela Microsoft e é amplamente utilizado

por gerentes de projeto. Possui interface amigável, típica de produtos Microsoft. Dentre suas

principais funcionalidades destacam-se: agendamento de tarefas, cronograma Gantt, estimativas de

custos e criação de diversos relatórios. Apesar de ter diversas funcionalidades este software não

evidencia gerenciamento de escopo do projeto.

O Project Builder2 foi desenvolvido pela empresa brasileira Project Builder Ltda. Criado em

1999, o software auxilia o gerenciamento corporativo de projetos e está fundamentado em conceitos

e nas boas práticas compiladas pelo PMI (Project Management Institute) e GTZ (Método ZOPP). A

ferramenta é totalmente voltada para WEB e tem como principais funcionalidades: cronograma

Gantt, painel de controle dos projetos, estrutura analítica do projeto - EAP (disponível em formato

gráfico) e histórico do projeto.

O VPMI Professional3 também é um software voltado para WEB, possui uma interface

bastante simples e amigável. Tem como destaque a integração com o MS-Project, a criação de

cronograma Gantt, cálculo de riscos do projeto, cálculo do valor agregado do projeto e possibilidade

de comunicação via e-mail com a equipe de projeto. Este software, também não evidencia o

gerenciamento de escopo de projetos.

O DotProject4 é um software livre, voltado para o gerenciamento de projetos corporativos. É

uma aplicação WEB, sendo assim, seu acesso é feito através do navegador. Possui diversas

funcionalidades, das quais se destacam: diagrama de Gantt, agendamento e acompanhamento de

tarefas, informação de usuários e colaboradores de cada tarefa, comunicação via e-mail e

1 Microsoft Office Project 2007. Disponível em <http://office.microsoft.com/pt-br/project/>. Acesso em 02 out. 2008. 2 Project Builder. Disponível em <http://www.projectbuilder.com.br/>. Acesso em 02 out. 2008. 3 VMPi Professional. Disponível em <http://www.vcsonline.com/>. Acesso em: 02 out. 2008. 4 DotProject. Disponível em <http://www.dotproject.net/>. Acesso em 02 out. 2008

28

repositório de arquivos relacionados a cada projeto. Apesar de esse software apresentar diversas

funcionalidades ele também não evidencia o gerenciamento de escopo de projetos.

O WBS Chart Pro5 é uma ferramenta desenvolvida pela Critical Tools. É uma aplicação

desktop, exclusiva para a construção da estrutura analítica do projeto – EAP. Possui uma interface

bastante simples e tem como principais funcionalidades a criação da EAP, com informações como

valores e horas gastas em cada tarefa e a verificação da realização das tarefas.

Todos os softwares foram testados. A exceção foi o Project Builder, que é um software pago

e não possui nenhuma versão demo ou Trial, sendo assim, sua avaliação foi realizada conforme

informações disponibilizadas no site da empresa desenvolvedora6.

As Tabelas 3 e 4 demonstram a análise realizada com as principais funcionalidades

avaliadas e também requisitos não funcionais. Além dos softwares avaliados, as tabelas contêm a

solução proposta pelo presente projeto de pesquisa.

Tabela 3. Funcionalidades dos softwares avaliados e da ferramenta proposta

Software Avaliado

Criação da EAP

(Gráfico)

Controle de

Alteração do escopo

Plano de gerenciamento

Definição das

tarefas

Dicionário da EAP

Verificação do escopo

MS-Project Não Sim Não Sim Sim Sim Project Builder

Sim Não identificado

Sim Sim Sim Sim

VPMI Não Sim Não Sim Sim Sim DotProject Não Não Não Sim Sim Sim WBS Chart

Pro Sim Não Não Sim Não Não

Ferramenta Proposta

Sim Sim Sim Sim Sim Sim

Tabela 4. Características gerais dos softwares avaliados e da ferramenta proposta

5 WBS Chart Pro. Disponível em <http://www.criticaltools.com/>. Acesso em 02 out. 2008. 6 Project Builder. Disponível em <http://www.projectbuilder.com.br/>. Acesso em 02 out. 2008.

29

Software Avaliado Software Gratuito Plataforma Web Língua Portuguesa MS-Project Não Não Sim

Project Builder Não Sim Sim VPMI Não Sim Não

DotProject Sim Sim Sim WBS Chart Pro Não Não Não

Ferramenta Proposta Sim Sim Sim

Através desta análise, foi possível constatar que as ferramentas disponíveis no mercado não

contemplam todos os aspectos desejáveis para gerenciamento de escopo de projetos conforme o

PMBOK. O Project Builder foi o software que mais se aproximou dos requisitos desejáveis, porém,

não é gratuito e também não possui nenhuma versão Demo ou Trial, impossibilitando o uso do

mesmo sem a sua aquisição.

Com a análise foi constatado que para três funcionalidades essenciais no gerenciamento de

escopo só são possíveis com no máximo dois softwares, ou seja, só é possivel:

Criar a EAP em modo gráfico com os softwares: Project Builder e WBS Chart Pro;

Controlar as alterações de escopo com os softwares: MS-Project e VPMI; e

Criar o plano de gerenciamento de escopo com o software Project Builder.

A ferramenta proposta, além de atender aos requisitos necessários para permitir o

gerenciamento de escopo de projetos, tem como diferenciais três características: ser um software

gratuito, voltado para a web e na língua portuguesa.

30

3. PROJETO

Neste capítulo é apresentada a análise desenvolvida visando à especificação do software

para gerenciamento de escopo, conforme estudado na revisão bibliográfica. São apresentados os

requisitos funcionais, requisitos não funcionais, as regras de negócio, casos de uso e diagramas de

atividades, além do modelo de classes de domínio.

Devido ao melhor entendimento do processo de gerenciamento de escopo de projeto, alguns

novos requisitos foram adicionados ao projeto, buscando assim, um melhor funcionamento da

ferramenta. Também foi adicionado um novo módulo ao projeto, denominado Módulo

Administrativo, para que neste módulo, o Administrador do sistema consiga cadastrar os

funcionários da empresa, assim como os dados da organização.

3.1 REQUISITOS DA FERRAMENTA

Neste item, estão listados os requisitos funcionais, não-funcionais e as regras de negócios da

ferramenta proposta. Esta é a parte do processo responsável por definir e traduzir as informações

coletadas durante o levantamento de requisitos, que compreende e define os serviços necessários

para fornecer uma base estável para o projeto do software (SOMMERVILLE, 2007). Este processo

é bastante crítico, pois a má especificação dos requisitos pode resultar em erros nas próximas etapas

do projeto.

3.1.1 Requisitos Funcionais

Segundo Cysneiros (2005), os requisitos funcionais são as funcionalidades que um software

deve ser capaz ou pode ser capaz de executar ou fornecer. A seguir a descrição dos requisitos

funcionais da ferramenta desenvolvida:

RF01 - O sistema deve permitir criar, visualizar, editar e excluir projetos.

RF02 - O sistema deve permitir criar, visualizar, editar e excluir a declaração do escopo

do projeto.

RF03 - O sistema deve permitir criar, visualizar, editar e excluir o plano de

gerenciamento do escopo.

RF04 - O sistema deve permitir criar, visualizar, editar e excluir a EAP.

31

RF05 - O sistema deve permitir criar e visualizar, editar e excluir o dicionário da EAP.

RF06 - O sistema deve permitir criar, visualizar e excluir solicitações de modificações

no escopo do projeto.

RF07 - O sistema deve permitir que sejam definidas as responsabilidades (Aprovadores)

do projeto.

RF08 - O sistema deve permitir que seja feita a verificação do escopo, permitindo

definir o status do projeto e também dos subprodutos (deliverables) do projeto.

RF09 - O sistema deve permitir que sejam aprovadas ou não as solicitações de

mudanças no escopo do projeto.

RF10 - O sistema deve permitir que todas as modificações de escopo sejam registradas e

armazenadas (histórico de modificações) e consultadas.

RF11 – O sistema deve permitir que um projeto seja aprovado ou reprovado.

RF12 – O sistema deve permitir que o plano de gerenciamento de escopo seja aprovado

ou reprovado.

RF13 – O sistema deve permitir que a declaração do escopo do projeto seja aprovada ou

reprovada.

RF14 – O sistema deve permitir que a Estrutura Analítica do Projeto seja aprovada ou

reprovada.

RF15 – O sistema deve permitir que um projeto já existente seja carregado pelo sistema.

RF16 – O sistema deve permitir que os usuários sejam cadastrados no sistema, através

do Módulo Administrativo.

RF17 – O sistema deve permitir que sejam cadastrados os dados da

empresa/organização, através do Módulo Administrativo.

RF18 – O Sistema deve permitir que o Dicionário da EAP seja aprovado ou reprovado.

3.1.2 Requisitos Não Funcionais

Segundo Cysneiros (2005), os requisitos não funcionais demonstram as limitações, ou

atributos de qualidade para um software para o processo de desenvolvimento da ferramenta. Tais

32

limitações podem ser de segurança, precisão, usabilidade e desempenho. A seguir pode-se

visualizar a descrição dos requisitos não funcionais da ferramenta desenvolvida:

RNF01 - O sistema deve ser voltado para WEB.

RNF02 - O sistema deve ser desenvolvido na linguagem PHP.

RNF03 - O sistema deve ser compatível com o Banco de Dados MySQL.

RNF04 - O sistema deve ter um tempo de acesso menor que 20 segundos para qualquer

função do sistema em situação normal do servidor, rede e conexões.

RNF05 - O sistema deve estar conforme a definição de Gerenciamento de Escopo

apresentada pelo Guia PMBOK- Terceira Edição, 2004.

3.1.3 Regras de Negócio

Segundo Cysneiros (2005), regras de negócio são regras que irão restringir algum aspecto

lógico da ferramenta. A seguir pode-se observar a descrição das regras de negócio da ferramenta

proposta:

RN01 – Para que seja criada a declaração de escopo do projeto, o projeto tem que estar

autorizado.

RN02 – Para que seja criado o plano de gerenciamento, a declaração do escopo tem que

estar autorizada.

RN03 – Para que seja criada a EAP, o plano de gerenciamento tem que estar aprovado.

RN04 – Após realizar as alterações, os itens alterados devem ser novamente aprovados,

comparando a solicitação de alteração com as modificações realizadas.

RN05 – Para ser criado um projeto, todos os campos do termo de abertura do projeto

(Project charter) devem estar preenchidos.

RN06 – Para aprovar qualquer item do projeto, o usuário deverá estar incluso entre os

responsáveis pela devida aprovação, definidos no plano de gerenciamento do projeto.

RN07 – Para aceitar qualquer entrega do projeto, o usuário deverá estar cadastrado como

sendo um dos responsáveis por tal tarefa no plano de gerenciamento do escopo.

33

RN08 – Para modificar qualquer item do gerenciamento do escopo já aprovado, deve

haver uma solicitação de modificação aprovada.

3.2 DIAGRAMA DE CASOS DE USO

O diagrama de caso de uso é uma forma de aplicar e descrever um requisito que será

realizado pelo software, além de ser um mecanismo central para a descoberta e definição de outros

requisitos do sistema. Tendo como finalidade, expressar a maneira com que elementos externos

interagem com as funcionalidades disponíveis no sistema (LARMAN, 2004).

Ainda segundo Larman (2004), existe uma forte relação entre os requisitos funcionais e os

casos de uso. A principal diferença é que os casos de uso descrevem de forma mais detalhada como

determinada ação será executada pelo software, sendo este um dos principais mecanismos utilizados

em diversos processos de desenvolvimento de software, para a descoberta e definição de requisitos.

O diagrama de casos de uso é composto por seis atores. Sendo que o ator Administrador

somente possui acesso ao Módulo Administrativo do sistema e os demais atores possuem acesso ao

Módulo Principal do sistema. A figura 5 apresenta os cinco atores do módulo principal do sistema.

Figura 5. Atores do Módulo Principal

34

3.2.1 Módulo Principal

O módulo principal do sistema é o módulo de produção, onde todos os atores terão acesso,

com exceção do ator Administrador. A seguir são descritas as funcionalidades que cada ator possui

dentro do sistema.

O ator Usuário é o ator genérico e possui as funções básicas do sistema, tais como:

Carregar projeto;

Visualizar projeto;

Visualizar plano de gerenciamento do escopo;

Visualizar declaração do escopo;

Visualizar EAP;

Visualizar dicionário da EAP;

Criar solicitações de alteração no escopo do projeto;

Visualizar solicitações de alteração; e

Visualizar histórico de solicitações.

Vale lembrar, que estas funcionalidades qualquer outro ator também tem acesso, a Figura 6

mostra o diagrama de caso de uso do ator Usuário.

35

Figura 6. Diagrama de Casos de uso do ator Usuário

O ator Autor, além das funcionalidades do ator Usuário, também possui as seguintes opções,

como mostra a Figura 6:

Criar, alterar ou excluir projeto; e

Criar, alterar a lista de aprovadores.

36

Figura 7. Diagrama de Casos de Uso do ator Autor

A Figura 7 mostra os casos de uso do ator Responsável, que além de possuir todas as

funcionalidades do Usuário, possui as seguintes funcionalidades:

Aprovar projeto;

Aprovar plano de gerenciamento do escopo do projeto;

Aprovar declaração do escopo do projeto;

Aprovar EAP;

Aprovar dicionário da EAP; e

Aprovar solicitações de alteração.

37

Figura 8. Diagrama de Casos de Uso do ator Responsável.

O ator Gerente possui as funcionalidades do ator Usuário, além das seguintes

funcionalidades, como mostra a Figura 8:

Criar o plano de gerenciamento;

Criar a declaração do escopo do projeto;

Criar a EAP;

Criar o dicionário da EAP; e

Verificar o escopo do Projeto.

38

Figura 9. Diagrama de Casos de Uso do ator Gerente

O ator Time possui acesso apenas as funcionalidades do ator Usuário, não tendo assim,

nenhuma funcionalidade em especial. A Figura 9 mostra a interação entre os diferentes tipos de

usuário, porém todos os atores herdam as funcionalidades do Usuário.

Os itens a seguir apresentam a descrição dos casos de uso da ferramenta proposta, com suas

especificações, requisitos externos e cenários.

3.2.1.1 UC01.01. Carregar Projeto

Este caso de uso tem como cenário principal a escolha de um projeto a ser carregado,

permitindo que um projeto já criado seja carregado para o usuário.

Requisitos Externos:

RF15 – O sistema deve permitir que um projeto já existente seja carregado pelo sistema.

Pré-condição: Pelo menos um projeto deve estar criado.

Pós-condição: Dados do projeto selecionado são carregados.

39

Tabela 5. Cenário UC01.01. Carregar Projeto

Carregar Projeto – Cenário Principal 1. O sistema apresenta todos os projetos existentes da empresa que o usuário está cadastrado. 2. O usuário seleciona um dos projetos. 3. O sistema carrega os dados do projeto, mostrando para o usuário o Termo de Abertura do Projeto.

Exceção 1. Caso nenhum projeto cadastrado, o sistema não exibe nenhum projeto.

3.2.1.2 UC01.02. Visualizar Projeto

Este caso de uso tem como cenário principal a visualização de um projeto, não permitindo a

alteração de qualquer informação.


RF01 - O sistema deve permitir criar, visualizar, editar e excluir projetos.

Pré-condição: O projeto deve estar criado.

Pós-condição: O termo de abertura do projeto é mostrado ao usuário, apenas para

visualização.

Tabela 6. Cenário UC01.02. Visualizar Projeto

Visualizar Projeto – Principal 1. O usuário seleciona a opção visualizar projeto. 2. O sistema carrega os dados do Termo de Abertura do Projeto, não permitindo qualquer alteração.

3.2.1.3 UC01.03. Visualizar Plano de Gerenciamento

Este caso de uso tem como cenário principal a visualização do plano de gerenciamento do

projeto, não permitindo a alteração de qualquer informação.


RF03 - O sistema deve permitir criar, visualizar, editar e excluir o plano de gerenciamento

do escopo.

Pré-Condição: O plano de gerenciamento do escopo do projeto deve estar cadastrado.

40

Pós-condição: O plano de gerenciamento do escopo do projeto é mostrado ao usuário,

apenas para visualização.

Tabela 7. Cenário UC01.03. Visualizar Plano de gerenciamento do Projeto

Visualizar Plano de Gerenciamento do Projeto - Principal 1. O usuário seleciona a opção visualizar plano de gerenciamento do projeto. 2. O sistema carrega os dados do Plano de gerenciamento do Projeto, não permitindo qualquer alteração.

3.2.1.4 UC01.04. Visualizar Declaração do Escopo

Este caso de uso tem como cenário principal a visualização da declaração do escopo do



RF02 - O sistema deve permitir criar, visualizar, editar e excluir a declaração do escopo do

projeto.

Pré-condição: A declaração do escopo deve estar cadastrada.

Pós-condição: A declaração do escopo do projeto é mostrada ao usuário, apenas para

visualização.

Tabela 8. Cenário UC01.04. Visualizar Declaração do Escopo

Visualizar Declaração do Escopo do Projeto - Principal 1. O usuário seleciona a opção visualizar declaração do escopo do projeto. 2. O sistema carrega os dados da Declaração do Escopo do Projeto, não permitindo qualquer alteração.

3.2.1.5 UC01.05. Visualizar EAP

Este caso de uso tem como cenário principal a visualização da Estrutura Analítica do



RF04 - O sistema deve permitir criar, visualizar, editar e excluir a EAP.

Pré-condição: A EAP deve estar cadastrada.

Pós-condição: A EAP é mostrada ao usuário, apenas para visualização.

41

Tabela 9. Cenário UC01.05. Visualizar EAP

Visualizar EAP - Principal 1. O usuário seleciona a opção visualizar EAP. 2. O sistema carrega os dados da EAP, não permitindo qualquer alteração.

Visualizar EAP modo gráfico – Alternativo 1. Após o sistema carregar os dados da EAP, o usuário seleciona a opção “Visualizar EAP em modo gráfico” 2. O sistema abre uma nova janela, mostrando a EAP em modo gráfico.

Exceção: Caso a EAP não cadastrada, o sistema não exibe os itens.

3.2.1.5 UC01.06. Visualizar Dicionário da EAP

Este caso de uso tem como cenário principal a visualização do Dicionário da EAP, não

permitindo a alteração de qualquer informação.


RF05 - O sistema deve permitir criar e visualizar, editar e excluir o dicionário da EAP.

Pré-condição: O dicionário da EAP deve estar cadastrado.

Pós-condição: O Dicionário da EAP é mostrado ao usuário, apenas para visualização.

Tabela 10. Cenário UC01.06. Visualizar Dicionário da EAP

Visualizar Dicionário da EAP – Principal 1. O usuário seleciona a opção visualizar Dicionário da EAP. 2. O sistema carrega os dados do primeiro item do Dicionário EAP, não permitindo qualquer alteração.

Visualizar outros itens do Dicionário da EAP – Alternativo 1. Após o sistema carregar os dados do primeiro item do dicionário da EAP, o usuário seleciona uma opção: “Avançar”, “Retroceder”, “Primeira”, “Última”. 2. O sistema carrega os dados do item do dicionário da EAP, conforme solicitado pelo usuário.

Exceção Caso o dicionário da EAP não está cadastrado, o sistema não exibe os dados.

3.2.1.6 UC01.07. Criar Solicitação de Mudanças

Permite que sejam criadas solicitações de mudanças no escopo do projeto. Este caso de uso

tem como cenário principal a criação de uma solicitação de mudança no escopo do projeto, já como

cenário alternativo este caso de uso permite o cancelamento da criação desta solicitação.

42


RF06 - O sistema deve permitir que sejam criadas solicitações de modificações no escopo

do projeto.

Pré-condição: A EAP deve estar criada e aprovada.

Pós-condição: Solicitação de mudança criada.

Tabela 11. Cenário UC01.07. Criar Solicitação de Mudança

Criar solicitação de mudança no escopo do projeto - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome da Organização - Nome do Projeto 2. O sistema carrega o número da solicitação de mudança de forma incremental. 3. O sistema atribui a data da solicitação de mudança para a data atual. 4. O usuário informa os dados necessários. 5. O usuário confirma a solicitação. 6. O sistema valida os dados 7. O sistema armazena os dados

Cancelar solicitação de mudança - Exceção Caso o usuário não confirme a solicitação de mudança no escopo: 1. O sistema não armazena nenhum dado.

3.2.1.7 UC01.08. Visualizar Solicitações de alterações

Permite que sejam listadas todas as solicitações de mudanças no escopo do projeto.


RF06 - O sistema deve permitir criar, visualizar e excluir solicitações de modificações no

escopo do projeto.

Pré-condição: Ao menos uma solicitação de alteração deve estar criada.

Pós-condição: Lista de solicitações de alterações exibidas.

Tabela 12. Cenário UC01.08. Listar Solicitações de Mudança

Listar solicitações de mudança - Principal 1. O usuário solicita a listagem das solicitações de alteração no escopo do projeto 2. O sistema carrega o nome da organização. 3. O sistema carrega o nome do projeto. 4. O sistema carrega a lista de solicitações de alterações armazenadas, exibindo os

43

números das solicitações, breve descrição da solicitação, Nome de quem solicitou a alteração, o grau de impacto e o status da solicitação (Aprovada, Reprovada, Não avaliada)

Exceção Caso o nenhuma solicitação de mudança cadastrada, o sistema não exibe os dados.

3.2.1.8 UC01.09. Visualizar Histórico de Modificações

O sistema deve gerar um histórico contendo todas as modificações no escopo do projeto que

foram aprovadas.


RF10 - O sistema deve permitir que todas as modificações de escopo sejam registradas e

armazenadas (histórico de modificações).

Pré-condição: Ao menos uma solicitação de mudança de escopo deve estar aprovada.

Tabela 13. Cenário UC01.09. Gerar Histórico de Modificações

Listar alterações – Principal 1. O usuário solicita a listagem do histórico de modificações no escopo do projeto 2. O sistema carrega o nome da organização. 3. O sistema carrega o nome do projeto. 4. O sistema carrega a lista de alterações aprovadas, exibindo os números das solicitações, breve descrição da solicitação, Nome de quem solicitou a alteração, o grau de impacto e a data em que a alteração foi realizada.

Exceção Caso o nenhuma modificação cadastrada e aprovada, o sistema não exibe os dados.

3.2.1.9 UC01.10. Criar, Alterar ou Excluir Projeto

Este caso de uso tem como cenário principal a criação de um projeto, permitindo que um

novo projeto seja criado. Além do cenário principal, existem outros três cenários alternativos que

permitem alterar um projeto, cancelar a criação do projeto e excluir um projeto.


RF01 - O sistema deve permitir criar, editar e excluir projeto.

Pré-condição: A empresa deve estar cadastrada e pelo menos um funcionário deve estar

cadastrado.

44

Pós-condição: O projeto foi criado ou alterado.

Tabela 14. Cenário UC01.10. Criar, Alterar ou Excluir Projeto

Criar Projeto - Principal 1. O sistema apresenta a tela para cadastro de projeto. 2. O usuário opta por criar um novo projeto. 3. O usuário informa os dados do projeto, conforme a tela. 4. O usuário confirma a criação do projeto. 5. O sistema armazena os dados do projeto.

Cancelar criação do projeto - Alternativo Caso o usuário não confirme o passo 4 do cenário principal: 1. O sistema não armazena nenhuma informação.

Alterar Projeto - Alternativo Caso o projeto já tenha sido aprovado, o sistema solicita o número da solicitação de mudança de escopo aprovada para que seja feita a alteração do projeto. Caso não haja solicitação de mudança de escopo aprovada, abre o termo de abertura de projeto apenas para visualização. 1. O sistema apresenta a tela para cadastro de projeto. 2. O usuário opta por alterar um projeto. 3. O usuário altera os dados do projeto. 4. O usuário confirma a alteração do projeto. 5. O sistema valida os dados. 6. O sistema armazena os dados do projeto.

Excluir Projeto - Exceção 1. O sistema apresenta a tela para cadastro de projeto. 2. O usuário opta por excluir um projeto. 3. O usuário confirma a exclusão do projeto. 5. O sistema exclui o projeto. 6. O sistema armazena os dados da exclusão.

3.2.1.10 UC01.11. Criar, Alterar a Lista de Aprovadores

Este caso de uso tem como cenário principal a criação dos Aprovadores das etapas do

gerenciamento do escopo do projeto, permitindo que os diversos aprovadores sejam escolhidos.

Além do cenário principal, existe o cenário alternativo que permite alterar os aprovadores do

projeto.


RF07 - O sistema deve permitir que sejam definidas as responsabilidades (Aprovadores) do

projeto.

Pré-condição: O projeto deve estar criado.

45

Pós-condição: A Lista de aprovadores criada e a permissão de cada usuário aprovador a sua

etapa correspondente.

Tabela 15. Cenário UC01.11. Criar, Alterar a Lista de Aprovadores

Criar Lista de Aprovadores – Principal 1. O usuário seleciona o usuário aprovador de cada uma das etapas do gerenciamento do projeto. 2. O usuário grava a seleção. 3. O sistema armazena a lista de aprovadores e seta a permissão de cada usuário a sua fase correspondente.

Alterar Lista de Aprovadores – Alternativo 1. O usuário modifica um ou mais aprovadores. 2. O usuário confirma a alteração. 3. O sistema grava a alteração, modificando as permissões dos usuários conforme a nova lista de aprovadores.

3.1.2.11 UC01.12. Aprovar Projeto

Este caso de uso tem como cenário principal a Aprovação/Reprovação de um projeto.


RF11 – O sistema deve permitir que um projeto seja aprovado ou reprovado.

Pré-condição: O projeto deverá estar criado.

Pós-condição: O status do projeto definido como aprovado ou reprovado, permitindo ou não

a seqüência do fluxo do projeto.

Tabela 16. Cenário UC01.12. Aprovar Projeto

Aprovar Projeto - Principal 1. O responsável seleciona a opção aprovar. 2. O responsável confirma a escolha. 3. I sistema grava o status do projeto como aprovado, permitindo a continuação do processo normal do projeto.

Reprovar Projeto - Exceção 1. O responsável seleciona a opção reprovar. 2. O responsável confirma a escolha. 3. O sistema seta o status do projeto como reprovado, não permitindo a continuação daquele projeto.

46

3.2.1.12 UC01.13. Aprovar Plano de Gerenciamento

Este caso de uso tem como cenário principal a Aprovação/Reprovação de um plano de

gerenciamento do projeto.


RF12 – O sistema deve permitir que o plano de gerenciamento de escopo seja aprovado ou

reprovado.

Pré-condição: O plano de gerenciamento do escopo deverá estar criado.

Pós-condição: O status do plano de gerenciamento projeto definido como aprovado ou

reprovado, permitindo ou não a seqüência do fluxo do projeto.

Tabela 17. Cenário UC01.13. Aprovar Plano de Gerenciamento

Aprovar Plano de Gerenciamento do Projeto - Principal 1. O responsável seleciona a opção aprovar. 2. O responsável confirma a escolha. 3. I sistema grava o status do plano de gerenciamento do projeto como aprovado, permitindo a continuação do processo normal do projeto.

Reprovar Plano de Gerenciamento do Projeto - Alternativo 1. O responsável seleciona a opção reprovar. 2. O responsável confirma a escolha. 3. O sistema seta o status do plano de gerenciamento do projeto como reprovado, não permitindo a continuação daquele projeto.

3.2.1.13 UC01.14. Aprovar Declaração do Escopo

Este caso de uso tem como cenário principal a Aprovação/Reprovação da Declaração do

Escopo do Projeto


RF13 – O sistema deve permitir que a declaração do escopo do projeto seja aprovada ou

reprovada.

Pré-condição: A declaração do escopo deverá estar criada.

Pós-condição: O status da declaração de gerenciamento projeto definido como aprovado ou

reprovado, permitindo ou não a seqüência do fluxo do projeto.

47

Tabela 18. Cenário UC01.14. Aprovar Declaração do Escopo

Aprovar Declaração do Escopo do Projeto - Principal 1. O usuário seleciona a opção aprovar. 2. O usuário confirma a escolha. 3. I sistema grava o status da Declaração do Escopo do projeto como aprovado, permitindo a continuação do processo normal do projeto.

Reprovar Declaração do Escopo - Alternativo 1. O usuário seleciona a opção reprovar. 2. O usuário confirma a escolha. 3. O sistema seta o status da Declaração do Escopo do projeto como reprovado, não permitindo a continuação daquele projeto.

3.2.1.14 UC01.15. Aprovar EAP

Este caso de uso tem como cenário principal a Aprovação/Reprovação da Estrutura

Analítica do Projeto.


RF14 – O sistema deve permitir que a Estrutura Analítica do Projeto seja aprovada ou

reprovada.

Pré-condição: A estrutura analítica do projeto (EAP) deverá estar criada.

Pós-condição: O status da EAP definido como aprovado ou reprovado, permitindo ou não a

seqüência do fluxo do projeto.

Tabela 19. Cenário UC01.15. Aprovar EAP

Aprovar EAP - Principal 1. O usuário seleciona a opção aprovar. 2. O usuário confirma a escolha. 3. I sistema grava o status da EAP como aprovado, permitindo a continuação do processo normal do projeto.

Reprovar EAP- Alternativo 1. O usuário seleciona a opção reprovar. 2. O usuário confirma a escolha. 3. O sistema seta o status da EAP como reprovado, não permitindo a continuação daquele projeto.

3.2.1.15 UC01.16. Aprovar Dicionário da EAP

Este caso de uso tem como cenário principal a Aprovação/Reprovação do Dicionário da

EAP.

48


RF18 – O Sistema deve permitir que o Dicionário da EAP seja aprovado ou reprovado.

Pré-condição: O dicionário da EAP deverá estar criado.

Pós-condição: O status do Dicionário da EAP definido como aprovado ou reprovado,

permitindo ou não a seqüência do fluxo do projeto.

Tabela 20. Cenário UC01.16. Aprovar Dicionário da EAP

Aprovar Dicionário da EAP - Principal 1. O usuário seleciona a opção aprovar. 2. O usuário confirma a escolha. 3. I sistema grava o status do Dicionário da EAP como aprovado, permitindo a continuação do processo normal do projeto.

Reprovar Dicionário da EAP- Alternativo 1. O usuário seleciona a opção reprovar. 2. O usuário confirma a escolha. 3. O sistema seta o status do Dicionário da EAP como reprovado, não permitindo a continuação daquele projeto.

3.2.1.16 UC01.17. Aprovar Solicitação de Mudança

Permite que as solicitações de mudanças sejam controladas. Permitindo ao responsável pela

aprovação, aprovar ou não cada uma das solicitações de mudança do escopo do projeto. Este caso

de uso tem como cenário principal a aprovação de uma solicitação de mudança e como cenário

alternativo a reprovação de uma solicitação.


RF09 - O sistema deve permitir que sejam aprovadas ou não as solicitações de mudanças no

escopo do projeto.

Pré-condição: A solicitação de mudança no escopo deve estar criada.

Pós-condição: A solicitação de mudança no escopo foi aprovada ou reprovada.

Pós-condição: Caso a solicitação de mudança no escopo foi aprovada, é permitido fazer

alterações no escopo do projeto.

49

Tabela 21. Cenário UC01.17. Aprovar Solicitação de Mudança

Aprovar solicitação - Principal 1. O gerente do projeto descreve seu parecer sobre a alteração. 2. O gerente do projeto define o status da solicitação como aprovada. 3. O gerente do projeto confirma a alteração. 4. O sistema valida os dados 5. O sistema armazena os dados.

Reprovar solicitação - Alternativo 1. O gerente do projeto descreve seu parecer sobre a alteração. 2. O gerente do projeto define o status da solicitação como reprovada 3. O gerente do projeto confirma a alteração. 4. O sistema valida os dados 5. O sistema armazena os dados.

3.2.1.17 UC01.18. Criar o Plano de Gerenciamento

Permite que seja criado o plano de gerenciamento do escopo do projeto conforme protótipo

de tela. Este caso de uso tem como cenário principal a criação do plano de gerenciamento do escopo

do projeto, como cenários alternativos o cancelamento do plano de gerenciamento de escopo e

alteração do plano de gerenciamento de escopo, como cenário de exceção este caso de uso possui a

não aprovação do plano de gerenciamento de escopo.


RF03 - O sistema deve permitir que o gerente de projetos crie o plano de gerenciamento do

escopo.

RF07 - O sistema deve permitir que o gerente de projeto defina responsabilidades.

Pré-condição: A declaração do escopo de projeto deve estar aprovada.

Pós-condição: Plano de gerenciamento do escopo do projeto criado ou alterado.

Tabela 22. Cenário UC01.18. Criar o Plano de Gerenciamento

Criar plano de gerenciamento do escopo - Principal 1. O sistema verifica se a declaração do escopo do projeto foi aprovada. 2. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome da Organização - Nome do Projeto - Nome de quem elaborou o projeto - Nome de quem aprovou o projeto - Data da criação do projeto - Nome do gerente do projeto

50

3. O usuário informa os dados necessários. 4. O usuário confirma. 5. O sistema armazena os dados.

Cancelar plano de gerenciamento do escopo - Alternativo Caso o usuário opte por cancelar o plano de gerenciamento do escopo do projeto, durante a sua criação: 1. O sistema não armazena nenhuma informação.

Declaração do Escopo não Aprovada – Exceção Caso a declaração do escopo do projeto ainda não foi aprovada. 1. O sistema não permite a criação do plano de gerenciamento do escopo.

3.2.1.18 UC01.19 Criar a Declaração do Escopo do Projeto

Permite criação da declaração do escopo do projeto (Scope Statement), conforme o protótipo

de tela. Tendo como cenário principal a criação da declaração do escopo, como cenários

alternativos o cancelamento da criação da declaração do escopo e a alteração da declaração do

escopo, como exceção este caso de uso tem a não aprovação de uma declaração de escopo.


RF02 - O sistema deve permitir que o gerente de projetos crie a declaração do escopo do

projeto.

Pré-condição: O projeto deve estar criado e aprovado.

Pós-condição: Declaração do escopo do projeto criada ou alterada.

Tabela 23. Cenário UC01.19. Criar a Declaração do Escopo do Projeto

Criar declaração do escopo - Principal 1. O sistema verifica se o projeto foi aprovado. 2. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto. 3. O usuário informa os dados necessários. 4. O usuário confirma a declaração. 5. O sistema armazena os dados.

Alterar a declaração do Escopo – Alternativo Caso a declaração do escopo do projeto já tenha sido aprovada, o sistema solicita o número da solicitação de mudança de escopo aprovada para que seja feita a alteração da declaração do escopo do projeto. Caso não haja solicitação de mudança de escopo aprovada, abre a declaração do escopo projeto apenas para visualização. 1. O sistema apresenta a tela da Declaração do Escopo. 2. O sistema carrega os dados do projeto que já estão armazenados e aprovados. 3. O usuário altera os dados necessários. 4. O usuário confirma a declaração.

51

5. O sistema armazena as informações.

Cancelar criação da declaração do escopo - Exceção Caso o usuário opte por cancelar a declaração do escopo do projeto, durante a sua criação: 1. O sistema não armazena nenhuma informação.

Projeto não aprovado – Exceção Caso o projeto ainda não tenha sido aprovado. 1. O sistema não permite criar a declaração do escopo do projeto.

3.2.1.19 UC01.20 Criar a EAP

Permite que o gerente de projetos crie a EAP, permitindo que sejam criados subprodutos

menores, até que eles estejam em um nível de detalhe que permita o gerenciamento do trabalho do

projeto.


RF04 - O sistema deve permitir que o gerente de projeto crie a EAP (modo gráfico e em

forma de lista).

Pré-condição: O plano de gerenciamento do escopo do projeto deve estar criado e aprovado.

Pós-condição: EAP do projeto criada ou alterada.

Tabela 24. Cenário UC01.20. Criar a EAP

Criar a EAP - Principal 1. O sistema verifica se o plano de gerenciamento de escopo de projeto foi aprovado. 2. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto: - Nome da Organização - Nome do Projeto - Nome de quem elaborou o projeto - Nome de quem aprovou o projeto - Data da criação do projeto - Nome do gerente do projeto 3. Vai para o cenário adicionar fase ou subproduto. Após adicionar as fases ou subprodutos retorna ao passo 4. 4. O usuário confirma a criação da EAP. 5. O sistema armazena os dados. 5. O sistema atualiza a lista de níveis.

Alterar a EAP – Alternativo Caso a EAP já tenha sido aprovada, o sistema solicita o número da solicitação de mudança de escopo aprovada para que seja feita a alteração da EAP. Caso não haja solicitação de mudança de escopo aprovada, o sistema abre a EAP apenas

52

para visualização. 1. O sistema apresenta a tela da EAP. 2. O sistema carrega os dados da EAP que já estão armazenados e aprovados. 3. O usuário altera os dados necessários. 4. O usuário confirma a alteração. 5. O sistema armazena as informações.

Adicionar fase ou subproduto à EAP - Alternativo 1. O usuário informa o nível da fase ou subproduto do projeto. 2. O usuário informa o nome da fase ou subproduto do projeto. 3. O usuário adiciona a fase ou subproduto do projeto. 4. O sistema adiciona a estrutura a fase ou subproduto.

Cancelar a criação da EAP - Exceção Caso no passo 3 do cenário principal, o usuário opte por cancelar: 1. O sistema não armazena os dados.

3.2.1.20 UC01.21 Criar o Dicionário da EAP

Permite que seja criado o dicionário da EAP conforme o protótipo de tela. O cenário

principal deste caso de uso trata da criação do dicionário da EAP, onde são inseridas as informações

de cada um dos subprodutos da EAP. Como cenário alternativo, este caso de uso possui o

cancelamento da criação do dicionário da EAP.


RF05 - O sistema deve permitir que o gerente de projetos crie o dicionário da EAP.

Pré-condição: o gerente deve ter permissão para criar a EAP para o projeto selecionado.

Pós-condição: Dicionário da EAP foi criado ou alterado.

Tabela 25. Cenário UC01.21. Criar o Dicionário da EAP

Criar o dicionário da EAP - Principal 1. O sistema carrega os dados do projeto conforme o cadastro na criação do projeto. 2. O sistema carrega as informações referentes à fase ou subproduto da EAP: - Número referente à fase ou subproduto - Nome da fase ou subproduto. 3. O usuário informa os dados necessários. 4. O usuário confirma a operação. 5. O sistema armazena os dados.

Dicionário da EAP aprovado - Alternativo No passo 1 do cenário principal, caso o dicionário da EAP já tenha sido aprovado, o sistema solicita o número da solicitação de mudança de escopo aprovada para que seja feita a alteração do dicionário da EAP. Caso não haja solicitação de mudança de escopo aprovada, abre o dicionário da EAP

53

apenas para visualização.

Cancelar criação do dicionário da EAP - Exceção Caso o usuário não confirme a criação do dicionário no passo 16 do cenário principal: O sistema não armazena nenhuma informação.

3.2.1.21 UC01.22. Verificar o Escopo do Projeto

Permite que seja definido/verificado o escopo do projeto, permitindo que cada subproduto

(deliverable) da EAP tenha seu status verificado, podendo ser aceita ou não a entrega, bem como

definido o status de completo/ em andamento/ não iniciado, registrando quem aceitou/alterou este

status. Este caso de uso tem como base a EAP.


Pré-condição: A EAP deve estar criada e aprovada.

Pós-condição: O status de cada item da EAP foi definido.

RF08 - O sistema deve permitir que seja feita a verificação do escopo, permitindo definir o

status do projeto e também dos subprodutos (deliverables) do projeto.

Tabela 26. Cenário UC01.22. Verificar o Escopo do Projeto

Verificar Escopo - Principal 1. O usuário deverá ir para a tela da EAP. 2. O usuário deverá verificar se todos os subprodutos e fases do projeto estão Ok, verificando um a um. 3. O usuário deverá atribuir o status do subproduto ou fase do projeto conforme seu estado atual.

Reprovar um item da EAP - Alteranativo 1. O usuário acessa o item da EAP. 2. O usuário seleciona a opção reprovado. 3. O usuário armazena os dados. 4. O sistema armazena as informações.

Cancelar verificação do Escopo – Exceção 1. O usuário escolhe a opção cancelar. 2. O sistema não armazena nenhuma informação e retorna ao menu principal.

3.2.2 Módulo Administrativo

54

O módulo Administrativo do sistema é onde o ator Administrador cadastra os usuários e

também os dados da empresa. Ou seja, neste módulo são inseridas as informações básicas do

sistema, tais como o cadastro da empresa e também dos usuários que terão acesso ao sistema.

Neste módulo há apenas um ator, que é chamado de Administrador, a seguir são mostrados

os cenários de casos de uso deste usuário. A Figura 6 mostra o diagrama de Casos de Uso do

Módulo Administrativo do sistema.

Figura 10. Diagrama de Caso de Uso do Módulo Administrativo

3.2.2.1 UC02.01. Manter Empresa

Permite ao administrador manter os dados da empresa.


RF17 – O sistema deve permitir que sejam cadastrados os dados da empresa/organização,

através do Módulo Administrativo.

Tabela 27. Cenário UC02.01. Manter Empresa

Inserir Empresa - Principal 1. O usuário informa os dados da empresa. 2. O usuário confirma os dados da empresa. 3. O sistema armazena as informações no banco de dados.

Alterar Empresa – Alternativo 1. O sistema carrega os dados da empresa cadastrada. 2. O usuário altera os dados da empresa. 3. O usuário confirma a alteração. 4. O sistema armazena as informações no banco de dados.

Excluir Empresa – Exceção 1. O sistema carrega os dados da empresa cadastrada.

55

2. O usuário seleciona a opção de excluir a empresa. 3. O sistema verifica se não existem projetos daquela empresa. 4. O sistema exclui os dados do banco de dados.

3.2.2.2 UC02.01. Manter Usuário

Permite ao administrador manter os usuários cadastrados no sistema.


RF16 – O sistema deve permitir que os usuários sejam cadastrados no sistema, através do

Módulo Administrativo.

Tabela 28. Cenário UC02.02. Manter usuário.

Inserir Funcionário - Principal 1. O usuário informa os dados do usuário. 2. O usuário confirma os dados do usuário. 3. O sistema grava armazena as informações no banco de dados, permitindo o acesso do mesmo ao sistema.

Alterar Funcionário – Alternativo 1. O sistema carrega os dados do funcionário cadastrado. 2. O usuário altera os dados do funcionário. 3. O usuário confirma a alteração. 4. O sistema armazena as informações no banco de dados.

Excluir Funcionário – Exceção 1. O sistema carrega os dados do funcionário cadastrado. 2. O usuário seleciona a opção de excluir funcionário. 3. O sistema exclui os dados do banco de dados.

3.3 DIAGRAMA DE CLASSES

A Figura 11 corresponde ao diagrama de classes do projeto. O diagrama é composto pelas

seguintes classes:

Organizacao: Constam as informações sobre a organização na qual o projeto pertence.

Colaborador: Constam as informações sobre o colaborador da empresa, assim como os

dados para acesso ao sistema.

Projeto: Constam as informações gerais do projeto.

PlanoGerenciamento: Constam informações do plano de gerenciamento do escopo do

projeto.

56

Aprovadores: São os papéis e responsabilidades das quais o colaborador pode exercer

em um determinado projeto. Podendo ter vários papéis vinculados ao mesmo

colaborador.

DeclaracaoEscopo: Contém as informações sobre a declaração do escopo do projeto.

EAP: Contém informações sobre o autor e aprovador da Estrutura Analítica do Projeto.

SolicitacaoModificacao: Contém informações de uma solicitação de alteração no

projeto, assim com o status da solicitação.

HistoricoAlteracoes: Onde são armazenadas as modificações no escopo do projeto,

assim com a solicitação correspondente a modificação.

Dicionário: Cada fase ou subproduto do projeto possui um dicionário da EAP, onde

estão armazenadas as informações sobre cada um dos itens da EAP.

ItemEAP: Constam as informações sobre os ítens da EAP. Assim como os critérios de

aceitação do subproduto, descrição do subproduto, nível do subproduto na EAP e o

responsável.

57

Figura 11. Diagrama de Classes

58

3.4 DIAGRAMA DE ATIVIDADES

O diagrama de atividades, Figura 12, demonstra o fluxo de atividades desde a criação do

escopo até a mudança do mesmo, mediante uma solicitação de alteração. Procura-se demonstrar a

necessidade de aprovação de cada novo item ou alterações do escopo, não apresentando neste

diagrama todas as funcionalidades do sistema.

O fluxo inicia com o Autor criando um novo projeto. Uma vez que criado o projeto, o

mesmo fica disponível ao Responsável para que o mesmo aprovar ou não o projeto. Caso o

responsável reprove o projeto, o mesmo é encerrado. Caso contrário, o projeto passa para a etapa

seguinte, onde o Gerente do projeto crie a declaração do escopo do projeto.

Criada a declaração do escopo, o responsável deverá aprovar ou reprovar a declaração do

escopo. Caso reprovada, o projeto é encerrado, caso contrário, o projeto passa para a próxima etapa,

que é a criação do Plano de Gerenciamento.

Uma vez que criado o plano de gerenciamento, o mesmo deverá ser aprovado ou reprovado

pelo Responsável. Se reprovado, o plano de gerenciamento deverá ser criado novamente. Se

aprovado, o projeto passa para a próxima etapa, que é a criação da EAP.

Criada a EAP, a mesma deverá ser aprovada ou reprovada pelo Responsável. Se reprovada,

a mesma deverá ser criada novamente. Se aprovada, todos os elementos do escopo do projeto

estarão definidos e aprovados. Para que algum dos elementos seja alterado, o Usuário deverá criar

uma Solicitação de Alteração.

Uma vez que criada uma solicitação de alteração, a mesma deverá ser aprovada ou

reprovada pelo Responsável. Se reprovada, a solicitação é arquivada. Se aprovada, a solicitação é

armazenada no histórico de modificações do escopo e os elementos (Declaração do escopo do

projeto, Plano de gerenciamento do Projeto e EAP) do projeto podem ser alterados. Após a

alteração, o responsável deverá aprovar ou reprovar a alteração, confirmando ou não a alteração dos

elementos do Escopo do Projeto.

O ciclo pode ser iniciado novamente a partir da solicitação de alteração criada pelo Usuário.

E para finalizar o ciclo, o projeto deverá ser encerrado.

59

act Workflow

Autor Responsável Gerente Usuário

Novoprojeto

Cria projeto Aprova? Cria declaração doescopo

Encerra

AprovaDeclaração?

Solicita Alteração

AprovaSolicitação?

ArquivaSolicitação

Armazena noHistórico deAlterações

Altera os ItensAfetados pela

Alteração (escopo,plano de

gerenciamento, EAP)

Cria plano degerenciamento

Aprovaplano?

AprovaEAP?

Cria EAP

Fim doprojeto?

EncerraAprovaAlteração?

[Sim]

[Não]

[Sim]

[Não]

[Sim]

[Não]

[Não]

[Não]

[Sim]

[Não]

[Não]

[Sim]

[Sim]

[Sim]

Figura 12. Diagrama de Atividades

60

4. IMPLEMENTAÇÃO

Neste capítulo são apresentados os resultados alcançados durante a fase de implementação,

abordando as ferramentas utilizadas no processo de desenvolvimento, os componentes utilizados e

também o banco de dados.

4.1 Banco de Dados

Conforme o projeto do software, o banco de dados utilizado foi o MySQL 5.0. Para

definição do modelo entidade relacionamento, foi utilizado o software MySQL Workbench 5.0.30

OSS (SUN MICROSYSTEMS, 2008), esta versão está disponível sob duas formas de licença:

Comercial e Open Source, sendo esta última a utilizada neste trabalho, sob licença GPL.

A ferramenta é de fácil utilização, intuitiva e auto-explicativa, trabalhando com diversas

entidades e relacionamentos. Na Figura 13 é apresentada a interface principal do MySQL

Workbench versão 5.0.30, onde pode-se visualizar algumas entidades e seus relacionamentos.

Figura 13. Interface Principal do MySQL Workbench

Utilizando o MySQL Workbench foi desenvolvido o modelo entidade relacionamento que

contempla o projeto. Na Figura 14 é apresentado o modelo ER.

61

Figura 14. Diagrama de Entidade Relacionamento

62

4.2 ScriptCase

Buscando aumentar a velocidade de implementação e facilitar o desenvolvimento, foram

pesquisados alguns frameworks, onde destacaram-se o Zend Framework7 e ScriptCase8. Ambos

framework, são compatíveis com a linguagem PHP, suportam o banco de dados MySQL e são

compatíveis com o sistema operacional Windows, requisitos básicos para o desenvolvimento deste

projeto.

Após a análise dos frameworks, foi escolhido o ScriptCase, devido ao grande número de

documentos, manuais e exemplos disponíveis na internet além de tutoriais e exemplos da própria

ferramenta, disponíveis no site da empresa fabricante do framework, NetMake9.

O ScriptCase é um ambiente completo de desenvolvimento para a construção de aplicações

Web de forma rápida e eficiente, reduzindo o tempo de desenvolvimento, manutenção e

distribuição. Através de uma interface amigável, o ScriptCase permite a criação de novos sistemas

com formulários, consultas gerenciais e relatórios (NETMAKE, 2006).

Este framework suporta diversos bancos de dados como Oracle, DB2, MS SQLServer,

MySQL, PostgreSQL, Sybase, MS Access etc. O código-fonte das aplicações são em PHP e

JavaScript, com o uso da tecnologia AJAX. Vale lembrar que as aplicações rodam totalmente

independentes da ferramenta e são compatíveis com diversos sistemas operacionais das plataformas

Windows, Unix, Linux entre outros (NETMAKE, 2006).

O acesso ao framework de desenvolvimento é feito diretamente no browser, necessitando

apenas do serviço HTTP, permitindo que outros usuários conectem-se a ferramenta, sem a

necessidade da instalação na máquina local. A Figura 15 apresenta a interface principal do

framework ScriptCase.

Vale ainda ressaltar, que o ScriptCase foi obtido sob licença acadêmica concedida para 120

dias junto ao fabricante.

7Zend Framework – Disponível em: http://framework.zend.com/. Acesso em 10 abril 2009. 8 ScriptCase – Disponível em: http://www.scriptcase.com.br/. Acesso em 10 abril 2009. 9 NetMake – Desenvolvedora do framework ScriptCase - http://www.netmake.com.br/. Acesso em 12 abril 2009.

63

Figura 15. Interface principal do framework ScriptCase

4.3 Draw2D

O componente Draw2D foi desenvolvido por Herz (2008) e está disponível sob licença

LGPL. Esta biblioteca permite elaborar diagramas para as mais diversas finalidades. Baseado na

biblioteca JavaScript Vector Graphics Library, este componente permite a criação de diagramas de

maneira mais simples e rápida.

A escolha da utilização deste componente, justifica-se pela maneira simples e rápida do

componente gerar os mais diversos diagramas em JavaScript, permitindo assim, a criação da EAP –

Estrutura Analítica do Projeto em modo gráfico.

64

5. APRESENTAÇÃO DA FERRAMENTA

A ferramenta para Gerenciamento de Escopo de Projetos começou a ser desenvolvida de

acordo com a modelagem de entidade relacionamento proposta, tendo em vista as principais regras

de negócio definidas.

5.1 Módulo Administrativo

Utilizando o framework ScriptCase, primeiramente foi desenvolvido o Módulo

Administrativo do sistema, de maneira que o administrador do sistema pudesse cadastrar as

Empresas/Organizações e seus respectivos usuários do sistema. A Figura 16 mostra a tela

desenvolvida para Manter o Cadastro de Empresa/Organização.

Figura 16. Módulo Administrativo - Manter Cadastro de Empresa/ Organização.

Após ter uma empresa devidamente cadastrada, o administrador do sistema já pode cadastrar

os usuários/funcionários ligados à empresa. A Figura 17 mostra a tela desenvolvida para Manter o

Cadastro de Usuários.

65

Figura 17. Módulo Administrativo – Manter Cadastro de Usuário

5.2 Módulo Principal

Após serem realizados os cadastros de empresa e usuário, o mesmo já pode acessar a

ferramenta de Gerenciamento de Escopo através da tela de acesso ao sistema. Conforme mostra a

Figura 18.

Existente a diferença entre as cores dos Módulos Administrativo e Módulo Principal, para

não existir qualquer problema de identificação do módulo. Sendo o módulo administrativo nas cores

branco e laranja e o módulo principal nas cores branco e verde.

66

Figura 18. Módulo Principal - Tela de Acesso ao sistema.

Após acessar o sistema, o usuário tem acesso ao Menu principal, onde o usuário tem

disponível apenas a opção de criar um novo projeto ou carregar um projeto. Sendo que as demais

funcionalidades ficam inativas até o usuário selecionar um projeto ou criar um novo projeto. A

Figura 19 mostra o menu principal da aplicação.

Figura 19. Módulo Principal - Menu

Selecionando a opção Criar Novo projeto, o sistema irá abrir para o usuário a tela do Termo

de Abertura do Projeto, conforme mostra a Figura 20. Nesta tela, são cadastradas as informações

necessárias para a abertura do projeto.

De maneira similar, a funcionalidade Visualizar Projeto mostra esta mesma tela, só que com

a restrição de que o usuário não pode alterá-la, somente visualizar.

67

Figura 20. Módulo Principal - Cadastro de Projeto

No cadastro do projeto, o gerente de projetos é definido, assim como o autor do mesmo.

Porém é necessário que o autor do projeto defina quem serão os aprovadores do projeto e também

os aprovadores das demais fases do Gerenciamento do Escopo de Projetos.

A definição dos aprovadores é feita através da seleção dos usuários na tela de Aprovadores,

conforme mostra a Figura 21.

68

Menu principal -> Plano de Gerenciamento de Escopo -> Aprovadores.

Figura 21. Módulo Principal - Cadastro de Aprovadores

Após a definição dos aprovadores, o usuário cadastrado como Aprovador do Projeto deve

aprovar o Termo de Abertura do Projeto, inicialmente Cadastrado. Para que após a aprovação ou

reprovação, o fluxo do gerenciamento do escopo do projeto possa seguir normalmente. A Figura 22

mostra a tela de Aprovação do Projeto, de forma similar, as demais aprovações são realizadas.

Vale ressaltar, que somente os dois usuários cadastrados como Aprovadores do projeto,

possuem acesso a esta opção do Menu Principal.

69

Figura 22. Módulo Principal - Aprovação de Projeto

Após a aprovação do projeto, o usuário que foi designado como gerente do projeto deverá

criar a Declaração do Escopo do Projeto (Project Charter). Para isto, o gerente do projeto deverá

acessar o sistema, através da tela de Acesso ao Sistema (Figura 18) e carregar o projeto que ele

desejar, conforme a Figura 23.

70

Figura 23. Módulo Principal – Carregar Projeto

Após o gerente de projeto selecionar o projeto desejado, ele poderá criar a Declaração do

Escopo do Projeto, conforme mostra a Figura 24.

Na tela da Declaração do Escopo do Projeto, alguns campos como a justificativa do projeto,

premissas e restrições do projeto, são buscados direto do Termo de Abertura do Projeto,

previamente cadastrado.

71

Figura 24. Módulo Principal - Declaração do Escopo

72

Conforme já mencionado, a aprovação da Declaração do Escopo do Projeto é feita de forma

semelhante à aprovação do Projeto e após a aprovação da Declaração do Escopo do Projeto, o

gerente do Projeto poderá criar a Estrutura Analítica do Projeto. A Figura 25 mostra a tela de

Criação da Estrutura Analítica do Projeto em modo textual.

Para a inserção dos subprodutos da EAP, o gerente de projetos só precisa informar qual será

o subproduto “Pai”, ou seja, para os itens do primeiro nível da EAP, o item pai é o próprio projeto.

Conforme são inseridos os itens na EAP, estes itens automaticamente podem ser escolhidos como

“Pai” do próximo item que será inserido.

Figura 25. Módulo Principal - Estrutura Analítica do Projeto - Modo Textual

73

Para visualizar a Estrutura Analítica do Projeto – EAP em modo gráfico, o usuário deverá

clicar no botão na parte inferior da tela da EAP, como mostra a Figura 25. Clicando no botão, o

usuário visualizará a EAP da seguinte forma, como mostra a Figura 26.

A mesma EAP cadastrada na Figura 25, aparece na Figura 26, só que de forma gráfica.

Figura 26. Módulo Principal - Estrutura Analítica do Projeto em Modo Gráfico.

Após a criação e aprovação da EAP, o gerente do projeto pode criar o Dicionário da EAP,

como mostra a Figura 27. O dicionário da EAP nada mais é do que a definição bem detalhada de

cada um dos itens da EAP. Ou seja, para cada um dos itens da EAP o gerente do projeto deverá

criar uma descrição como o da Figura 27 e para o usuário “navegar” entre os itens da EAP, o

usuário deverá utilizar os botões superiores da tela.

74

Figura 27. Módulo Principal - Dicionário da EAP

Outra importante funcionalidade do sistema é a opção de solicitar alterações no escopo do

projeto, todos os usuários podem fazer esta solicitação, desde que estejam cadastrados no projeto. A

Figura 28 mostra como é criada uma solicitação de alteração. De maneira semelhante a criação, o

sistema permite que sejam visualizadas as solicitações e também permite ao responsável pela

aprovação da solicitações que a mesma seja aprovada ou reprovada.

75

Figura 28. Módulo Principal - Criação de Solicitação de Alteração no Escopo do Projeto

Outra importante funcionalidade do sistema é a consulta do status das solicitações de

alteração. Nesta consulta, é apresentado uma breve descrição da alteração solicitada, o usuário

requerente, setor, grau de impacto, data da solicitação e o status da solicitação, podendo ser “Não

Avaliado”, “Aprovado” ou “Reprovado”.

A Figura 29 mostra o relatório das solicitações de alteração do escopo do Projeto.

76

Figura 29. Módulo Principal - Visualizar Solicitações de Alteração no Escopo

Além destas telas, o sistema possui mais algumas para aprovação e visualização, porém as

principais foram descritas neste capítulo.

5.3 Principais Dificuldades Encontradas

Ao longo do projeto, foram encontradas algumas dificuldades, em que se tentou resolver da

melhor forma possível e entre elas pode-se citar:

Compreensão das metodologias de desenvolvimento do framework ScriptCase, para

construção do sistema. Para isto, foi necessário estudar o tutorial da ferramenta, manuais

de funcionamento, documentação disponível, além de assistir os vídeos disponíveis no

site do fabricante.

Compreensão do funcionamento e metodologia utilizada pelo componente Draw2D.

Para isto, foi necessário estudar a documentação disponível da biblioteca, exemplos de

aplicações disponíveis, estudo dos tutoriais disponíveis na internet e análise de trabalhos

desenvolvidos por acadêmicos e pesquisadores.

Integração do componente Draw2D com o framework ScriptCase. Para isto, foram

realizadas diversas pesquisas, buscando trabalhos que também possuem esta integração.

77

6. TESTES E VALIDAÇÃO

Foram realizados diversos testes durante o desenvolvimento da aplicação. Porém, todos eles

foram feitos de maneira empírica, sem metodologia, podendo assim, fazer com que alguns casos

específicos de erro, não sejam detectados a tempo, e que ocorram apenas em situações específicas,

dificultando sua resolução. Uma forma de contornar esse problema, seria através da utilização de

métodos mais eficazes para realização dos testes, porém, o curto prazo dificultou os testes.

Também foram realizados alguns testes integrados, simulando a criação de projetos,

aprovação, reprovação dos mesmos. Foi simulada a criação do plano de gerenciamento do projeto,

aprovação e reprovação do mesmo, além da atribuição das responsabilidades aos aprovadores de

cada etapa do projeto.

Visando testar as funcionalidades de criação, aprovação, reprovação e alteração da

Declaração do Escopo do Projeto, foram simulados, cadastrados, aprovados e reprovados diversos

projetos, buscando assim não deixar que nenhum erro passasse despercebido.

Durante os testes da criação da EAP, foram cadastradas diversas estruturas diferentes de

EAP, com diferentes números de itens e subitens. Gerando diferentes estruturas gráficas através do

componente Draw2D.

Também foram criadas diversas solicitações de alterações, sendo elas algumas vezes

aprovadas e outras vezes reprovadas, para que ambas as situações fossem testadas. Após a criação

das solicitações de alteração, foram geradas as consultas das solicitações, visando conferir o status

de cada alteração, conforme sua aprovação ou reprovação.

Não foi possível realizar os testes referentes a verificação do Escopo do Projeto, pois a

funcionalidade de atualização do status de cada item da EAP, não foi implementada. Desta forma, a

ferramenta não contempla o processo de verificação do escopo do projeto.

78

7. CONCLUSÃO

O principal objetivo deste projeto foi o desenvolvimento de uma ferramenta voltada para

Web que permitissem aos gerentes e equipes de projetos terem um maior e melhor controle do

escopo dos projetos.

Através da etapa de fundamentação teórica foi possível constatar a grande importância do

gerenciamento de projetos e da comprovação através dos dados e pesquisas realizadas. Com este

trabalho foi possível perceber que o uso de práticas e metodologias como a do PMBOK, facilita o

gerenciamento e aumentam a probabilidade de sucesso do projeto. Sendo que um dos pontos

fundamentais para se ter sucesso no projeto é o gerenciamento de escopo de projetos.

Seguindo as técnicas e recomendações descritas pelo PMBOK, concluiu-se que o

gerenciamento de escopo de projetos é de vital importância para os projetos. Também foi possível

perceber que o planejamento e a definição do escopo são fatores críticos para o sucesso do projeto,

assim como o gerenciamento do escopo e o controle sobre as alterações.

Sabe-se que é bastante comum ocorrer alterações no escopo de projeto e estas impactam em

diversas áreas, necessitando assim que estas mudanças sejam mais bem controladas e administradas,

justificando o uso de uma ferramenta que auxilie no gerenciamento do escopo de projetos e assim

possibilite ao gerente um maior controle sobre as alterações no projeto.

Durante a análise das ferramentas existentes no mercado, constatou-se que é difícil encontrar

ferramentas de gerenciamento de escopo de projeto que sigam as recomendações do PMBOK e

contemplam todos os processos do gerenciamento de escopo de projetos, reforçando ainda mais a

importância deste trabalho de conclusão de curso que visou o desenvolvimento de tal ferramenta.

Através do desenvolvimento desta ferramenta foi possível compreender o funcionamento de

novas tecnologias tais como o framework ScriptCase e o componente Draw2D. Também foram

encontradas diversas dificuldades dentre as quais pode-se destacar a funcionalidade do componente

Draw2D e também a integração do ScriptCase. Também foi possível concluir que a fase de testes de

software merece uma atenção especial no processo de desenvolvimento, uma vez que somente com

testes empíricos, alguns erros apresentados pelo sistema podem passar despercebidos.

79

Entretanto, o objetivo principal deste trabalho foi alcançado, pois foi desenvolvida uma

ferramenta para auxiliar no gerenciamento de escopo de projetos. Além do desenvolvimento da

ferramenta, inúmeros conhecimentos foram obtidos através das pesquisas, estudos, análises e

desenvolvimento da ferramenta, assim como o grande aprendizado sobre gerenciamento de escopo

de projetos conforme o PMBOK.

7.1 Trabalhos Futuros

O sistema desenvolvido pode ser considerado como o começo de uma série de melhorias

que podem ser feitas a partir das tecnologias e métodos utilizados neste projeto. Desta forma ficam

algumas recomendações que poderão aprimorar ainda mais o sistema, bem como abranger outras

áreas do Gerenciamento de Projetos.

Uma oportunidade real de trabalho é a integração com a ferramenta de gerenciamento de

riscos de projeto que está sendo desenvolvida pelo acadêmico Mateus Miller Figueiredo no seu

trabalho de conclusão de curso. Além dessas duas áreas do Gerenciamento de Projetos, novas áreas

podem ser incorporadas a esta ferramenta, tais como a área de custos do projeto, tempo e

aquisições. Visto que são áreas que são influenciadas diretamente pelo escopo do projeto e também

são muito importantes para o bom gerenciamento de projetos.

80

REFERÊNCIAS BIBLIOGRÁFICAS

ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, NBR ISO 10006 – Gestão de qualidade – Diretrizes para a qualidade na gestão de projetos. Rio de Janeiro, 2000.

CYSNEIROS, L. M. Requisitos não funcionais: da elicitação ao modelo conceitual. 2005. 224f. Tese (Doutorado em Ciência da Computação) – Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro, 2005.

DINSMORE, Paul Campbell. Como se tornar um profissional em gerenciamento de projetos. 2. ed. Rio de Janeiro: Qualitymark, 2007.

DUFFY, Mary Grace. Gestão de projetos: managing projects. Rio de Janeiro: Elsevier, 2007.

HERZ, A. Open-jACOB Draw2D, 2008. Disponível em: <http://draw2d.org>. Acesso em: 20 out. 2008.

IMAI, Massaki. Gemba Kaizen – estratégias e técnicas do Kaizen no piso de fábrica. São Paulo: IMAM, 1996.

KIMONS, Robert L. Picking projects for profitability. PM Network, 2001.

LARMAN, C. Utilizando UML e Padrões. 2. ed. Porto Alegre: Bookman, 2004.

NETMAKE, NETMAKE. Disponível em: <http://www.netmake.com.br/> Acesso em: 10 jun. 2009.

PRADO, Darcy. Gerenciando projetos nas organizações. Belo Horizonte: EDG, 2000.

PEREIRA, Marcos Valdeir. A importância do gerenciamento de escopo na gestão de projetos, 2005. Disponível em: <http://www.ietec.com.br/> Acesso em: 08 ago. 2008.

PINTO, Américo. Benchmarking em gerenciamento de projetos Brasil: relatório 2004. Rio de Janeiro: SENAI, 2005.

PMI - Project Management Institute. Guia PMBOK: um guia do conjunto de conhecimentos em gerenciamento de projetos. 3. ed. Pennsylvania: Project Management Institute. 2004.

SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Prentice Hall, 2007.

SUN MICROSYSTEMS. MySQL Workbench. Disponível em: <http://dev.mysql.com/workbench/>. Acesso em: 10 jun. 2009.

SOTILLE, Mauro Afonso et al. Gerenciamento do escopo em projetos. Rio de Janeiro: Editora FGV, 2007.

THE STANDISH GROUP (EUA). 2004 Third quarter research report: Chaos Demographics. 2004. Disponível em: <http://www.standishgroup.com/>. Acesso em: 09 ago. 2008.

81

XAVIER, Carlos Magno da Silva. Gerenciamento de projetos: como definir e controlar o escopo do projeto. São Paulo: Saraiva, 2005.

Área de gerência de projetos por cristiano born adriana ...siaibib01.univali.br/pdf/cristiano...

Documents