Você está na página 1de 74
Faculdade de Tecnologia da Zona Leste RAFAEL NISE PEREIRA Melhores práticas para gerenciamento do escopo

Faculdade de Tecnologia da Zona Leste

RAFAEL NISE PEREIRA

Melhores práticas para gerenciamento do escopo de projetos baseado no PMBOK

SÃO PAULO

2010

Faculdade de Tecnologia da Zona Leste RAFAEL NISE PEREIRA Monografia apresentada no curso de Tecnologia

Faculdade de Tecnologia da Zona Leste RAFAEL NISE PEREIRA

Monografia apresentada no curso de Tecnologia em Informática para Gestão de Negócios na FATEC-ZL como exigência parcial para obter o titulo de Tecnólogo em Informática para Gestão de Negócios.

Orientador: Prof. Mestre Joilson de Souza Cardoso

SÃO PAULO

2010

PEREIRA, Rafael Nise Melhores práticas para gerenciamento do escopo de projetos baseado no PMBOK / Rafael Nise Pereira – Faculdade de Tecnologia da Zona Leste, São Paulo, 2010

73 p.

Orientador: Me. Joilson de Souza Cardoso Trabalho de Conclusão de Curso – Faculdade de Tecnologia da Zona Leste

1. Gerenciamento de projetos. 2. Gerenciamento do escopo de projetos. 3. PMBOK.

Faculdade de Tecnologia da Zona Leste PEREIRA, Rafael Nise Melhores práticas para gerenciamento do escopo

Faculdade de Tecnologia da Zona Leste

PEREIRA, Rafael Nise

Melhores práticas para gerenciamento do escopo de projetos baseado no PMBOK

Monografia apresentada no curso de Tecnologia em Informática para Gestão de Negócios na FATEC-ZL como exigência parcial para obter o titulo de Tecnólogo em Informática para Gestão de Negócios.

Aprovado em:

Banca Examinadora

Prof. Me Joilson de Souza Cardoso Instituição: FATEC-ZL

Julgamento:

Assinatura:

Prof. Me Antônio Rodrigues Carvalho Neto Instituição: FATEC-ZL

Julgamento:

Prof. Glauber Rocha Romão

Julgamento:

Assinatura:

Instituição: SENAC

Assinatura:

São Paulo, 10 de dezembro de 2010.

Dedico este trabalho às pessoas que sempre estiveram ao meu lado em cada momento de dificuldade e me auxiliaram a superá-los. Aos meus irmãos, minha futura esposa, Elide e a minha mãe Valdenis pela relação de amor, amizade, companheirismo que temos e que tem um valor inestimável.

Agradecimentos

A Deus por sempre estar presente em minha vida em todos os instantes.

Aos meus familiares, por todo amor e apoio.

À minha futura esposa por ser uma fonte inspiração.

Ao professor Joilson Cardoso pelo auxilio na solução das minhas dúvidas e apresentar idéias valiosas para concluir este trabalho.

À professora Célia pela dedicação em revisar este trabalho na busca de

erros e pelos conselhos.

A todos os amigos e professores que me auxiliaram no desenvolvimento

deste trabalho.

Sumário

1. Introdução

12

2. O que é um projeto?

14

2.1. Diferenças de operações correntes e projetos

15

2.2. Subprojetos, programas e portfólios

15

2.3. Partes envolvidas no projeto (Stakeholders)

16

2.4. Ciclo de vida do projeto

17

2.5. Evoluções do gerenciamento de projetos

21

2.5.1. PMI

22

2.5.2. PMBOK

23

2.6.

Conceito de gerenciamento de projetos

24

2.6.1. Gerenciamento de integração do projeto

25

2.6.2. Gerenciamento do escopo do projeto

25

2.6.3. Gerenciamento de tempo do projeto

26

2.6.4. Gerenciamento de custo do projeto

26

2.6.5. Gerenciamento de qualidade do projeto

26

2.6.6. Gerenciamento de recursos humanos do projeto

27

2.6.7. Gerenciamento das comunicações do projeto

27

2.6.8. Gerenciamento de risco do projeto

27

2.6.9. Gerenciamento de aquisições do projeto

28

3. Controle integrado de mudanças e inter-relação entre escopo, qualidade,

tempo e risco

28

4.

Como gerenciar o escopo do projeto

32

4.1.

Coletar os requisitos

32

4.1.1. Coleta de requisitos, entradas necessárias

33

4.1.2. Coleta de requisitos, ferramentas necessárias

34

4.1.3. Coleta de requisitos, saídas necessárias

37

4.2.

Definir o escopo

39

4.2.1. Definir o escopo, entradas necessárias

40

4.2.2. Definir o escopo, ferramentas necessárias

41

4.2.3. Definir o escopo, saídas necessárias

42

4.3.

Criar a estrutura analítica do projeto (EAP ou WBS)

43

4.3.2.

Criar a estrutura analítica do projeto, ferramentas necessárias

44

4.3.3.

Criar a estrutura analítica do projeto, saídas necessárias

46

4.4.

Verificar o escopo

48

4.4.1. Verificar o escopo, entradas necessárias

49

4.4.2. Verificar o escopo, ferramentas necessárias

50

4.4.3. Verificar o escopo, saídas necessárias

50

4.5.

Controlar o escopo

51

4.5.1.

Controlar o escopo, entradas necessárias

52

4.5.2.

Controlar o escopo, ferramentas necessárias

52

4.5.3.

Controlar o escopo, saídas necessárias

53

4.6.1.

Vantagens do gerenciamento de escopo

53

4.6.2.

Principais causas de fracassos em projetos

54

5. Estudo de caso sobre o projeto do sistema de controle de palestras e

chamadas (SCPC)

55

5.1. Características principais do estudo de caso

55

5.2. Modelo de ciclo de vida iterativo incremental

55

5.3. EAP do projeto SCPC

56

5.4. Documentação do escopo do projeto e produto

58

5.5. Considerações sobre o estudo de caso

59

6. Considerações finais

61

Referências bibliográficas

62

Anexos

63

Anexo A. Documento de visão

63

Anexo B. Documento de caso de uso

69

Anexo C. Diagramas de classe

70

Anexo D. Sugestão de continuidade deste trabalho diferença entre RUP e

PMBOK

72

Anexo E. Autorização de uso deste trabalho

73

Lista de figuras

Figura 1. As áreas de abrangência de portfólios, programas, projetos e subprojetos Figura 2. Possíveis partes envolvidas no projeto

áreas de abrangência de portfólios, programas, projetos e subprojetos Figura 2. Possíveis partes envolvidas no projeto

16

17

Figura 3. O ciclo de vida de um projeto subdividido em fases características 19 Figura 4. Exemplo do inter-relacionamento das fases de um projeto ou grupo

21

de processos

Figura 5. As áreas de conhecimento do Gerenciamento de Projetos 25

Figura 6. Visão geral dos processos de gerenciamento de projetos PMBOK 4

29

2008

Figura 7. Relacionamento entre os fatores de qualidade, tempo, custo 30

Figura 8. Projetos com restrições de tempo

31

Figura 9. Tempo X Custo relação mais importante

31

Figura 10. Processos de Gerenciamento de Projetos distribuídos ao longo das

fases do projeto

Figura 11. Mapa mental do processo de coletar requisitos 34

32

Figura 12. Mapa mental do processo de definir escopo

.40

Figura 13. Mapa mental do processo de criar a EAP

.43

Figura 14. Exemplo de EAP dividido por fases

45

Figura 15. Exemplo de EAP com primeiras entregas como primeiro nível de

decomposição

46

Figura 16. Mapa mental do processo de verificar o escopo

49

Figura 17. Mapa mental do processo de controlar o escopo

51

Figura 18. EAP do projeto SCPC

57

Figura 19. Fase de iniciação do projeto SCPC com seus processos divididos

em pacotes de trabalho necessário para conclusão do projeto

Figura 20. Fase de elaboração do projeto SCPC com seus processos divididos em atividades necessárias para conclusão do projeto 58

57

Lista de siglas

PMI - Project Management Institute PMBOK - Project Management Body of Knowledge PMP - Project Management Professional ISO - International Organization for Standardization JAD - Joint Application Development WBS - Work Breakdown Structure

PEREIRA, Rafael Nise. Melhores práticas para gerenciamento de escopo de projetos baseado no PMBOK (Project Management Body of Knowledge). 73 f. – Faculdade de Tecnologia da Zona Leste, São Paulo, SP.

Resumo

O gerenciamento de escopo de projetos é essencial para as organizações, que atuam num mercado a cada dia mais competitivo, com recursos muitas vezes limitados e clientes mais exigentes, precisa de processos que facilitem identificação das reais necessidades dos clientes e da definição de atividades necessárias para realizar estes projetos com sucesso, pois oportunidades de negócios que surgem a todo o momento são essências para sobrevivências das empresas. O objetivo deste trabalho é conceituar as melhores práticas de gerenciamento do escopo de projetos e os processos necessários para desenvolver esta atividade. Em busca de responder a seguinte pergunta, quais as principais causas de fracassos no processo de gerenciamento do escopo do projeto e como é possível mitigá-los? Foram levantadas as possíveis causas, falta de comunicação entre os envolvidos, atrasos no cronograma, custos acima do orçamento, conflitos na equipe e com os envolvidos, projetos com definições incompletas, ambiente instável, retrabalhos para ajustar escopo. No estudo de caso deste trabalho foi realizada uma análise entre os processos, ferramentas e documentos propostos pelo PMBOK 4 para gerenciar o escopo de projetos e os que foram definidos como necessários para desenvolver o projeto SCPC. A utilização dos conhecimentos de gerenciamento de projeto proporciona resultados positivos, como a definição de um canal único de comunicação entre os envolvidos e na formalização de todas as informações, relevantes, estes documentos devem constar de forma detalhada sem deixar nenhuma necessidade ou expectativa como subentendida, incluindo cada solicitação de alteração e seu respectivo impacto no projeto. Muitas mudanças devem ser adiadas para não inviabilizarem a conclusão do projeto.

Palavras- chave: Gerenciamento de projetos; Gerenciamento do escopo de projetos; PMBOK;

PEREIRA, Rafael Nise. Best practices for scope project management based on the PMBOK (Project Management Body of Knowledge). 73 f. – Faculdade de Tecnologia da Zona Leste, São Paulo, SP.

Abstract

Scope project management is critical for organizations that operate in a market increasingly competitive, with often limited resources and more demanding costumers, need processes that facilitate identification of customers' real needs and definition of activities necessary to deliver these projects successfully, for business opportunities that arise at any time are essential to business survival. The objective of this work is to conceptualize best practices for scope project management and processes required to develop this activity. In searching to answer the following question, what are the main causes of process failures of Scope Project management and how you can mitigate them? Were raised the possible causes, lack of communication between those involved; Schedule delays and costs over budget; Conflict in the team and with stakeholders; Projects with incomplete definitions; Environment unstable; Rework scope to adjust; This work has intention to analyze of the processes, tools and documents proposed by PMBOK 4 to Scope Project manage and those identified as necessary to develop the project SCPC. The use of knowledge of the project management bringing positive results, as the definition of a single channel of communication between those involved and the formalization of all information, relevant, these documents must contain a detailed leaving no need or expectation as implied, including every change request and its corresponding impact on the project. Many changes must be postponed for not foreclosing the project's completion.

Key words: Project Management, Project Scope Management, PMBOK;

12

1. Introdução

Toda a história da humanidade é repleta de grandes realizações, muitas delas podem ser consideradas como projetos. É provável que os primeiros projetos fossem voltados para solucionar problemas do dia a dia, como a organizar uma caçada, implantar uma agricultura e desenvolver mecanismos de segurança. Ainda que estes empreendimentos possam ser considerados primitivos, também eram pressionados por prazos para atingir metas predeterminadas. E durante toda a Antiguidade grandes construções foram realizadas entre elas a grande muralha da China, as pirâmides do Egito e a dos Maias, mesmo sem o auxilio de ferramentas, técnicas e metodologias avançadas de que dispomos hoje, as pessoas criaram linhas de tempo, alocaram materiais e recursos e avaliaram os riscos envolvidos em seus projetos. (VALERIANO, 2001)

Atualmente, a globalização e os meios de comunicação têm diminuído às barreiras geográficas, o que possibilita uma maior concorrência, várias oportunidades de negócios, uma vez que, alcança um número maior de mercados. Mas criou desafios a serem superados, ambientes em constantes mudanças; pressões para acompanhar a velocidade do mercado; clientes esclarecidos exigem cada vez mais produtos melhores e serviços mais rápidos; Para atender a todas as expectativas as empresas estão descobrindo que existem muitas vantagens na utilização do gerenciamento do projeto.

Objetivo deste trabalho é conceituar as melhores práticas de gerenciamento do escopo de projetos e o processo necessário para desenvolver está atividade. E como o gerenciamento do escopo de projetos pode ajudar a controlar e monitorar os principais causadores de fracasso em projetos.

Em busca de responder a seguinte pergunta, quais as principais causas de fracassos no processo de gerenciamento do escopo do projeto e como é possível mitigá-los?

13

Algumas

hipóteses

levantadas

sobre

gerenciamento do escopo do projeto:

as

causas

de

fracasso

no

A. Falta de comunicação entre os envolvidos;

B. Atrasos no cronograma;

C. Custos acima do orçamento;

D. Conflitos na equipe e com os envolvidos;

E. Projetos com definições incompletas;

F. Ambiente instável;

G. Retrabalhos para ajustar escopo.

Será utilizada a metodologia de pesquisa bibliográfica neste trabalho que permite aumentar o conhecimento das melhores práticas descritas no PMBOK 4 versão 2008 sobre gerenciamento do escopo do projeto, e em livros, artigos, revistas especializadas, publicações, sites relacionados ao assunto, estudo de caso.

Este trabalho está organizado em cinco capítulos. Introdução; No capítulo segundo são abordados os conceitos de projetos, formas de organização, partes envolvidas no projeto, ciclo de vida do projeto, evoluções do gerenciamento de projetos, PMI, PMBOK, conceito de gerenciamento de projetos e áreas de conhecimento. No capítulo terceiro descreve a inter-relação as principais causas de mudanças em projetos, o porquê da necessidade do controle de mudanças. No capítulo quarto a definição de escopo, processos necessários para gerenciar o escopo do projeto (coletar requisitos, definir escopo, criar a EAP ou WBS, verificar escopo e controlar escopo). No quinto capitulo encontra-se o estudo de caso sobre o projeto do sistema de controle de palestras e chamadas (SPCP).

14

2. O que é um projeto?

Segundo

o

(PMBOK

2008,

p.5)

Projeto

é

um

esforço

temporário

empreendido para criar um produto, serviço ou resultado único.

De acordo com a definição apresentada na norma NBR ISO 10.006, que trata das diretrizes para qualidade no gerenciamento de projetos, projeto é um processo único, consistente com conjunto coordenado e controlado de atividades com data de início e término, conduzida para atingir um objetivo com requisitos especificados, incluindo restrições de tempo, custo e recursos.

Com base nos conceitos mencionados acima, um projeto é um esforço temporário e não-repetitivo empreendido para alcançar um objetivo específico, com limitações de recursos, prazos e devem ser planejados, executados e controlados.

Temporário significa que todo projeto tem um início e um término bem definidos, ao indicando curta duração de tempo, pois muitos projetos podem duram anos. Um projeto é finalizado quando seus objetivos são alcançados ou quando é evidente que não serão ou poderão ser atingidos por não cumprir um dos acordos contratuais (prazos, custos e especificações) ou desinteresse dos apoiadores do projeto (gerentes e empresa contratante do projeto). Não repetitivo significa que o produto ou serviço é de algum modo, diferente de todos os produtos e serviços semelhantes.

O termo temporário não se aplica ao serviço ou produto gerado pelo projeto, pois muitos projetos têm resultados duradouros, a construção de um monumento poderá durar séculos.

15

2.1. Diferenças de operações correntes e projetos

Segundo (VALERIANO, 2001), operações correntes são seqüências de processos repetidamente executados, geralmente são distribuídos por órgãos incumbidos da execução de tarefas especializadas, sob a denominação genérica de departamentos. As equipes dos departamentos geralmente pertencem a uma mesma especialidade profissional: marketing, contabilidade, engenharia (com suas especializações), produção (obras, eletricidade, mecânica, software), vendas, manutenção etc. O projeto, por ser temporário, é executado por uma organização por uma organização transitória e tem inicio e fins predeterminados. Em geral, e ao contrário das equipes funcionais, especializadas e permanentes, as equipes de projeto congregam profissionais de diversas especializações, formando equipes multifuncionais ou multidepartamentais. A finalidade dos projetos é criar algo que ainda não existe, seja produto ou serviço, enquanto que operação produz repetidamente um dado produto ou presta um serviço. A operação é conseqüência do projeto em outras palavras os projetos dão origem a uma nova operação, novo produto ou ocorrem para significativos melhoramentos naqueles já existentes.

2.2. Subprojetos, programas e portfólios

Quando um projeto precisa ser dividido em várias partes de fácil gerenciamento e controle, chamamos de subprojetos. Os subprojetos, são responsáveis por partes do projeto ou fases extremante especificas, podem ser desenvolvidos por um grupo especifico ou terceirizados.

O termo programa e utilizado para identificar um conjunto de projetos relacionados entre si que, coordenados e gerenciados de forma integrada. O interesse de organizar projetos em programas é tático, pois a vários benefícios

16

de controle que não seriam obtidos se eles fossem gerenciados de forma individual.

Portfólios (carteira de projetos) são a organização de um grupo de projetos, programas, subprojetos e outros trabalhos agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de cumprir os objetivos estratégicos do negócio conforme demonstra a figura 1 abaixo.

do negócio conforme demonstra a figura 1 abaixo. Figura 1 – As áreas de abrangência de

Figura 1 – As áreas de abrangência de portfólios, programas, projetos e subprojetos. Fonte: (VARGAS, 2009, p. 8)

2.3. Partes envolvidas no projeto (Stakeholders)

Segundo (XAVIER e CHUERI, 2008), as pessoas, grupo de pessoas e organizações que estão ativamente envolvidas no projeto, ou cujos interesses possam ser afetados de forma positiva ou negativa, direta ou indiretamente com resultado da execução ou conclusão do projeto, são chamadas de partes interessadas ou envolvidas. As partes envolvidas podem exercer influência sobre o projeto e seus resultados. A equipe de gerenciamento deve assim

17

identificar esses interessados, determinar suas necessidades então gerenciar e influenciar tais necessidades, a fim de assegurar um projeto bem sucedido. As possíveis partes envolvidas no projeto são descritos na figura 2.

partes envolvidas no projeto são descritos na figura 2. Figura 2 - Possíveis partes envolvidas no

Figura 2 - Possíveis partes envolvidas no projeto Fonte: (XAVIER e CHUERI, 2008, p. 17)

2.4. Ciclo de vida do projeto

A organização ou os gerentes de projetos podem dividir projetos em fases para oferecer melhor controle gerencial com ligações adequadas com as

18

operações em andamento da organização executora. Coletivamente, essas fases são conhecidas como o ciclo de vida do projeto. Muitas organizações identificam um conjunto específico de ciclos de vida para serem usados em todos os seus projetos (PMBOK, 2008).

Segundo (VARGAS, 2009) cada fase do projeto é caracterizada pela entrega, ou finalização, de um determinado trabalho. Toda entrega deve ser tangível e de fácil identificação, como, por exemplo, um relatório confeccionado, um cronograma estabelecido ou um conjunto de atividades realizado.

As atividades necessárias para criação de um produto são exclusivas de cada empresa e do produto que será criado. As atividades do desenvolvimento de um software são bem diferentes das utilizadas para obtenção de produtos farmacêuticos. Mas o mesmo ciclo de vida pode ser utilizado para organizar e monitorar tanto o desenvolvimento de produtos farmacêuticos como de softwares.

A quantidade de fases em projeto está relacionada à sua natureza. Existem diversos modelos de ciclo de vida, desenvolvidos para fins específicos, por diversas instituições, como o Departamento de Defesa dos Estados Unidos (DOD), a Agência Espacial Americana (NASA), o Project Management Institute (PMI), mas todas elas abrangem aproximadamente as mesmas quantidades de atividades.

Na figura 3 podemos observar como o ciclo de vida de um projeto pode ser dividido nas seguintes fases (iniciação, planejamento, execução, monitoramento e controle, encerramento) de acordo com PMBOK 4:

19

19 Figura 3 - O ciclo de vida de um projeto subdividido em fases características. Fonte:

Figura 3 - O ciclo de vida de um projeto subdividido em fases características. Fonte: (VARGAS, 2009, p. 31)

Para (VARGAS, 2009) as principais características das fases do ciclo de vida são as seguintes:

Fase de iniciação, nesta fase as necessidades dos envolvidos são identificadas e transformadas em problemas estruturados que devem ser resolvidos pelo projeto. Também definimos nessa fase a missão

e o objetivo do projeto, a documentação inicial é produzida e as melhores estratégias são identificadas e selecionadas.

Fase de planejamento, nesta fase tudo que é necessário para realização do projeto é detalhado, incluindo cronogramas, interdependências entre atividades, alocação dos recursos envolvidos, análise de custos etc., para que, no final dessa fase, ele esteja suficientemente detalhado para ser executado sem dificuldade

e imprevistos. Nesta fase os planos de escopo, qualidade, tempo, custo, recursos humanos, comunicação, riscos e aquisições são desenvolvidos.

Fase de execução, tudo que foi planejado anteriormente é colocado em prática. Os erros cometidos nas outras fases ficam evidentes

20

nesta fase. Grande parte do orçamento e do esforço do projeto é consumida nesta fase.

Fase de monitoramento e controle acontece paralelamente ás demais fases do projeto. Tem como objetivo controlar aquilo que está sendo realizado pelo projeto, de modo a propor ações corretivas e preventivas no menor espaço e de tempo possível após a detecção da anormalidade. O objetivo do controle é comparar o status atual do projeto com status previsto pelo planejamento, tomando ações preventivas e corretivas em caso de desvio.

Fase de encerramento é quando a execução dos trabalhos é avaliada através de uma auditoria interna ou externa, os documentos do projeto são encerrados e todas as falhas ocorridas durante o projeto são discutidas durante o projeto e analisadas para que erros similares não ocorram em novos projetos, por isso está fase é conhecido como a fase de aprendizado.

Com o desenvolvimento do projeto, praticamente todas as fases são realizadas quase que simultaneamente, constituindo um clico de vida conforme a figura 4.

constituindo um clico de vida conforme a figura 4. Figura 4. Exemplo do inter-relacionamento das fases

Figura 4. Exemplo do inter-relacionamento das fases de um projeto ou grupo de processos. Fonte: (PMBOK 42, 2008, p. 19)

21

2.5. Evoluções do gerenciamento de projetos

Segundo (VALERIANO, 2001), a história da humanidade relata grandes feitos podendo ser classificados como projetos. É muito provável, que os projetos mais antigos deviam estar voltados para as necessidades mais básicas, como o preparo e execução de uma campanha de caçada, instalação de uma agricultura e criação de dispositivos e sistemas de segurança ou defesa. Todos estes empreendimentos, ainda que primitivos, eram premidos por prazos para alcançar objetivos preestabelecidos e tinham algum tipo de organização e de administração. Durante a Antiguidade grandes construções forma realizadas pirâmides do Egito e dos Maias, a grande muralha da China. Mais atuais, citam-se canal do Panamá e de Suez, explorações submarinas e espaciais.

Para (VARGAS, 2009), por mais tenhamos evoluído tecnicamente, nos deparamos com ambiente que evolui muitas vezes mais, ou seja, hoje somos muito mais capazes que no passado, porém, esse nosso aumento é cada vez menor se comparado com o aumento na dinâmica do ambiente.

A evolução do gerenciamento de projetos pode ser dividida em três períodos:

Gerenciamento empírico, baseado nas qualidades inatas dos gerentes e de seus auxiliares ou nos procedimentos precedentes, muito mais como arte, do que como técnica. Foi o caso dos grandes construtores da Antiguidade e Idade Média, os feitos dos grandes chefes militares ou exploradores.

Gerenciamento clássico ou tradicional, geralmente considerado aquele a partir das décadas de 1949 ou 1950, com empreendimentos predominantes de engenharia, nas áreas de defesa, na aeronáutica e mais recentemente na espacial. Em geral, aqui os projetos são

22

essencialmente técnicos, de grande complexidade e caracterizados pelos altos custos, pelo vulto dos problemas envolvidos e dos prazos relativamente longos.

Mais recentemente (inícios da década de 1990), teve o começo do moderno gerenciamento de projetos. Voltado para uma ampla gama de aplicações, esse tipo de abordagem gerencial perdeu o caráter tipicamente técnico e vem sendo utilizado para todo tipo de problema empresarial. É uma ferramenta extraordinária que permite as organizações responderem com extrema rapidez as solicitações e pressões dos ambientes próximos e remotos, devido principalmente ao rápido ciclo de vida dos produtos, à velocidade da evolução tecnológica é acirrada competição, já em caráter global.

2.5.1. PMI

O PMI (Project Management Institute) ou Instituto de Gerenciamento de Projeto foi fundado em 1969, nos Estados Unidos, por cinco voluntários, com o propósito de garantir o uso das melhores práticas, pois dentre as diversas formas de se executar projetos nas mais variados segmentos, que após entre as melhores praticas identificadas de gerenciamento de projetos, para ser possível a aplicação não apenas em uma área de negócio especifica, para que isso seja possível foi feito um extenso trabalho de catalogação em formato de documentações descritivas das formas existentes na época, analisando os resultados, as praticas que obtiveram melhores resultados passaram a ser chamadas de melhores praticas.

Conforme (PMI-SP, 2010) o crescimento na quantidade de associados foi criado um Código de Conduta Profissional (Code of Professional Conduct) para os profissionais de gerenciamento de projetos e o primeiro certificado, o PMP em 1984, sendo reconhecido pela ISO 9001 em 1999, para receber o

23

certificado é necessário preencher uma série de requisitos entre eles a comprovação de experiência, aceite do Código de Conduta Profissional e aprovação no Exame de Certificação PMP. A PMP certifica os profissionais coordenadores de múltiplos projetos, para assegurar sucesso sendo

reconhecidos para tomada de decisão e traçar objetivos estratégicos. Essa certificação se destaca pelos requisitos bem superiores as outras certificações

e pela forma diferenciada no processo de certificação, divido em três etapas nas quais o candidato é avaliado em diversas competências, a quantidade de experiência comprovada também é superior.

2.5.2. PMBOK

Segundo (PMI-SP, 2010) o PMBOK (Project Management Body of Knowledge) é o guia que identifica o subconjunto do conjunto de conhecimentos em gerenciamento de projetos, reconhecido como boa prática.

A boa prática é identificada pelo acordo geral de sua aplicação correta das

habilidades, ferramentas e técnicas para aumentam das chances de sucessos do projeto, porém, as necessidades dos projetos são especificas, nem todas as boas práticas precisam obrigatoriamente aplicadas, a equipe de gerenciamento de projetos determina o que é adequado ao projeto. A primeira edição do PKBOK foi publicada 1996, a segunda em 2000, a terceira em 2004 e a quarta em 2008. O PMBOK é a maior e mais importante publicação do instituto PMI, proveniente do resultado do esforço de diversas fontes, incluindo voluntários, em pesquisas, revisões e aprimoramentos das melhores praticas no gerenciamento de projetos.

24

2.6. Conceito de gerenciamento de projetos

Para o (PMBOK 4, 2008) o gerenciamento de projetos é a aplicação de conhecimentos, habilidades e técnicas para projetar atividades que visem atingir ou exceder as necessidades e expectativas das partes envolvidas com relação ao projeto. Com intuito de satisfazer as necessidades e expectativas das partes envolvidas o gerente de projetos deve encontrar o equilíbrio entre as atividades inerentes ao projeto.

Segundo (KERZNER, 2004) uma gestão bem sucedida de projetos exige planejamento e coordenação extensivos. Assim, o fluxo de trabalho e a coordenação do projeto devem ser administrados horizontalmente, não mais verticalmente como ocorria na gerencia tradicional. O fluxo de trabalho horizontal de trabalho acarreta em produtividade, eficiência e eficácia. As empresas que conseguiram se especializar em fluxo horizontal de trabalho é, geralmente, mais lucrativo que aquelas que continuam a utilizar exclusivamente o fluxo vertical.

Para o (PMBOK 4, 2008) organiza as áreas de conhecimento em gerenciamento de projetos em quarenta e dois processos e que foram agrupados em nove áreas de conhecimento: Integração, Escopo, Tempo,

Custo, Qualidade, Recursos Humanos, Comunicações, Riscos e Aquisições. A coordenação destas áreas e responsabilidades da Integração conforme a figura

5.

25

25 Figura 5. As áreas de conhecimento do Gerenciamento de Projetos Fonte: (XAVIER e CHUERI, 2008,

Figura 5. As áreas de conhecimento do Gerenciamento de Projetos Fonte: (XAVIER e CHUERI, 2008, p. 6)

2.6.1. Gerenciamento de integração do projeto

Descreve os processos e as atividades que integram os diversos elementos do gerenciamento de projetos, que são identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos de gerenciamento de projetos. Ele consiste nos processos de gerenciamento de projetos: Desenvolver o termo de abertura do projeto, desenvolver o plano de gerenciamento do projeto, orientar e gerenciar a execução do projeto, monitorar e controlar o trabalho do projeto, realizar o controle integrado de mudanças e encerrar o projeto ou fase. (PMBOK 4, 2008)

2.6.2. Gerenciamento do escopo do projeto

Descreve os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário, para que seja

26

concluído com sucesso. Ele consiste nos processos de gerenciamento de projetos: Coletar os requisitos, definição do escopo, criar EAP ou WBS, Verificação do escopo e Controle do escopo. (PMBOK 4, 2008)

2.6.3. Gerenciamento de tempo do projeto

Descreve os processos relativos ao término do projeto no prazo correto. Ele consiste nos processos de gerenciamento de projetos: Definir as atividades, seqüenciar as atividades, estimativa de recursos das atividades, estimativa de duração da atividade e desenvolver o cronograma. (PMBOK 4,

2008)

2.6.4. Gerenciamento de custo do projeto

Descreve os processos envolvidos em planejamento, estimativa, orçamento e controle de custos, de modo que o projeto termine dentro do orçamento aprovado. Ele consiste nos processos de gerenciamento de projetos: Estimar os custos, determinar o orçamento e controlar os custos. (PMBOK 4, 2008)

2.6.5. Gerenciamento de qualidade do projeto

Descreve os processos envolvidos na garantia de que o projeto irá satisfazer os objetivos para os quais foi realizado. Ele consiste nos processos de gerenciamento de projetos: Planejamento da qualidade, realizar a garantia da qualidade e realizar o controle da qualidade. (PMBOK 4, 2008)

27

2.6.6. Gerenciamento de recursos humanos do projeto

Descreve os processos que organizam e gerenciam a equipe do projeto. Ele consiste nos processos de gerenciamento de projetos: Desenvolver plano de recursos humanos, mobilize a equipe do projeto, desenvolver a equipe do projeto e gerenciar a equipe do projeto. (PMBOK 4, 2008)

2.6.7. Gerenciamento das comunicações do projeto

Descrevem os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e adequada. Ele consiste nos processos de gerenciamento de projetos: Identificar partes interessadas, planejar as comunicações, distribuição das informações, gerencie as expectativas das partes interessadas e reportar desempenho. (PMBOK 4, 2008)

2.6.8. Gerenciamento de risco do projeto

Descreve os processos relativos à realização do gerenciamento de riscos em um projeto. Ele consiste nos processos de gerenciamento de projetos: Planejamento do gerenciamento de riscos, Identificação de riscos, realizar a análise qualitativa de riscos, realize a análise quantitativa de riscos, planejar de respostas a riscos e monitor e controlar os riscos. (PMBOK 4, 2008)

28

2.6.9. Gerenciamento de aquisições do projeto

Descreve os processos que compram ou adquirem produtos, serviços ou resultados, além dos processos de gerenciamento de contratos. Ele consiste nos processos de gerenciamento de projetos: Planejar as aquisições, conduzir as aquisições, administrar as aquisições, e encerrar as aquisições. (PMBOK 4,

2008)

3. Controle integrado de mudanças e inter-relação entre escopo, qualidade, tempo e risco

Segundo o (PMBOK 4, 2008), mudanças são realizadas desde o início do projeto até o seu término. O controle de mudanças é necessário porque raramente a execução dos projetos segue com exatidão o plano de gerenciamento do projeto. O plano de gerenciamento do projeto, a declaração do escopo do projeto e outras entregas precisam ser mantidas através do gerenciamento contínuo e cuidadoso das mudanças, rejeitando ou aprovando essas mudanças, de forma que as mudanças aprovadas sejam incorporadas a uma linha de base revisada. As mudanças propostas podem exigir estimativas de custos, seqüências de atividades do cronograma, datas do cronograma, recursos necessários e análise de alternativas de respostas a riscos, novas ou revisadas. Essas mudanças podem exigir ajustes no plano de gerenciamento do projeto, na declaração do escopo do projeto ou em outras entregas do projeto. O nível aplicado de controle de mudanças depende da área de aplicação, da complexidade do projeto específico, dos requisitos de contratos e do contexto e ambiente em que o projeto é realizado.

29

A

figura

6

demonstra

os

processos

do

PMBOK

4

2008

e

suas

respectivas fases do ciclo de vida dos projetos.

2008 e suas respectivas fases do ciclo de vida dos projetos. Figura 6. Visão geral dos

Figura 6. Visão geral dos processos de gerenciamento de projetos PMBOK 4 2008. Fonte: (SOTILLE, 2010, s/p)

O escopo do projeto pode ser afetado por três fatores básicos que devem ser controlados e gerenciados para garantir que o projeto atinja seus objetivos, a figura 7 é um modelo proposto por Kerzner (2002) que evidências estes fatores.

30

30 Figura 7. Relacionamento entre os fatores de qualidade, tempo, custo. Fonte: (BRUZZI, 2008, p. 16)

Figura 7. Relacionamento entre os fatores de qualidade, tempo, custo. Fonte: (BRUZZI, 2008, p. 16)

Para (BRUZZI, 2008), todo projeto precisa inter-relacionar fatores relativos à qualidade, custo e tempo. É extremamente relevante determinar a variável predominante no projeto. O escopo do projeto define o que será ou não atendido e determina os limites. É interessante trabalhar com estas variáveis dando peso e importância a cada uma delas.

Um projeto com prazo reduzido pode prejudicar a qualidade e aumentar o custo. Ao ser trabalhar com projetos prematuros pode-se comprometer a qualidade do processo e ao mesmo tempo o custo ao ser trabalhar dobrado, mas com compras urgentes sem uma pesquisa prévia, compras fora de estação ou com produtos em alta, quebra de regras legais, conforme a figura 8.

31

31 Figura 8. Projetos com restrições de tempo. Fonte: (BRUZZI, 2008, p. 17) Quando um projeto

Figura 8. Projetos com restrições de tempo. Fonte: (BRUZZI, 2008, p. 17)

Quando um projeto precisa de mais tempo para ser executado do que o combinado, acontece a relação mais importante (tempo x custo). Com prejuízo direto a variável qualidade. Um projeto que tem seu tempo aumentado pode trazer aumento de custo com mais horas trabalhadas e não ter mais qualidade em sua execução, conforme a figura 9.

ter mais qualidade em sua execução, conforme a figura 9. Figura 9. Tempo X Custo relação

Figura 9. Tempo X Custo relação mais importante. Fonte: (BRUZZI, 2008, p. 17)

32

4. Como gerenciar o escopo do projeto

O gerenciamento do escopo do projeto inclui os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para terminar o projeto com sucesso. 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. Na figura 10, podem ser observados os processos de gerenciamento de escopo nas suas respectivas fases.

de gerenciamento de escopo nas suas respectivas fases. Figura 10. Processos de Gerenciamento de Projetos

Figura 10. Processos de Gerenciamento de Projetos distribuídos ao longo das fases do projeto. Fonte: (VARGAS, 2009, p. 59)

4.1. Coletar os requisitos

Segundo o (PMBOK4, 2008) o processo de definir e documentar as funções e funcionalidades do projeto e do produto necessários para atender às necessidades e expectativas do patrocinador, cliente e outras partes

33

interessadas. O sucesso do projeto está diretamente influenciado pelo cuidado na correta captura e gerenciamento dos requisitos do produto. Esses requisitos precisam ser levantados, analisados e registrados em detalhe suficiente para serem medidos durante a execução do projeto. Os requisitos são a base do EAP( estrutura analitica do projeto). Custo, cronograma e planejamento da qualidade são todos planejados com base nos requisitos. O desenvolvimento do escopo do projeto começa com e análise das informações contidas no termo de abertura do projeto.

A figura 11 , demonstra os documentos necessários para iniciar o processo de coletar os requisitos , ferramentas que podem ser utilizadas na extração dos requisitos e documentos gerados no final do processo.

dos requisitos e documentos gerados no final do processo. Figura 11. Mapa mental do processo de

Figura 11. Mapa mental do processo de coletar requisitos. Fonte: (VARGAS, 2009, p. 59)

4.1.1. Coleta de requisitos, entradas necessárias

Para (PMBOK4, 2008) o termo de abertura do projeto é um documento que autoriza formalmente um projeto ou uma fase inicial. Serve de linha base

34

para o trabalho do gerente do projeto. Contém uma descrição de ato nível dos requisitos do projeto e produto que atenda as necessidades e expectativas das partes interessadas, também possui estimativas iniciais de qual o prazo destinado, recursos necessários e orçamento disponível. Usualmente o termo de abertura do projeto contém:

• Título do projeto;

• Um resumo das condições que definem o projeto;

• Justificativa do projeto;

• Nome do gerente de projeto, suas responsabilidades e

autoridades;

• Necessidades básicas do trabalho a ser realizado;

• Principais partes interessadas;

• Descrição produto do projeto;

• Cronograma básico do projeto;

• Necessidades iniciais de recursos;

• Necessidades de suporte pela organização;

• Premissas e restrições;

• Controle e gerenciamento das informações do projeto;

• Aprovações com assinatura do executivo responsável pelo documento (elemento externo ao projeto);

4.1.2. Coleta de requisitos, ferramentas necessárias

Entrevista é uma abordagem formal ou informal para descobrir informações das partes interessadas, geralmente é realizado por meio de perguntas preparadas ou espontâneas e anotação ou gravação das respostas. As entrevistas são freqüentemente um entrevistador e um entrevistado, mas há casos um entrevistador e vários entrevistados e vários entrevistadores e vários entrevistados.

35

Dinâmica de grupo reuniu os interessados pré-qualificados e especialistas no assunto para aprender sobre suas atitudes e expectativas sobre um produto proposto, serviço ou resultado. O moderador guia o grupo formado através de um debate interativo, criado para ser mais do que uma conversa cara-a-cara.

Oficinas são focadas no encontro das principais partes interessadas das diversas áreas envolvidas no projeto, para em conjunto definir os requisitos do produto. Oficinas são consideradas técnicas básicas para definição de requisitos inter funcionais e conciliar as partes interessadas. Devido a sua natureza de interação em grupo promove relacionamento e melhora a comunicação das partes interessadas. Outra vantagem desta técnica é que as questões podem ser descobertas e resolvidas mais rapidamente do que em entrevista individuais. Um exemplo de um método de oficina é o JAD (Joint Application Development) que é usado na indústria de desenvolvimento de software. Estas sessões facilitadas foco no usuário e trazer a equipe de desenvolvimento em conjunto para melhorar o processo de desenvolvimento de software.

Técnicas de criatividade em grupo, diversas atividades em grupo podem ser organizadas para identificar os requisitos do projeto e do produto. Algumas das técnicas de grupo criatividade que podem ser utilizados são:

• Brainstorming. A técnica usada para gerar e coletar idéias múltiplas

relacionadas ao projeto e requisitos do produto. Neste processo deve-se evitar

a censura pessoal as idéias geradas na devem ser avaliadas.

• Técnica de grupo nominal. Esta técnica aumenta a reflexão com um

processo de votação utilizado para classificar as idéias mais úteis para o prosseguimento de brainstorming ou de priorização. Cada membro do grupo do grupo é encorajado a melhorar as idéias apresentadas. • Mapa mental, idéias criadas através brainstorming individual são

consolidados em um único mapa para refletir em comum e diferenças na compreensão e gerar novas idéias.

36

• Diagrama de Afinidade, esta técnica permite um grande número de idéias a serem classificados em grupos para revisão e análise.

Técnicas de tomada de decisão em grupo podem ser aplicadas com Delphi que é um método de tomada de decisão em grupo que se caracteriza

pelo fato de cada membro do grupo apresentar as suas idéias, mas nunca face

a face com os restantes elementos. Cada elemento é assim isolado da

influência dos restantes. Como não ocorre a presença física dos participantes numa reunião, este método pode ser usado quando os elementos do grupo se

encontram distantes geograficamente. Apresenta, contudo, alguns inconvenientes, entre os quais o maior consumo de tempo na tomada de uma decisão e a perda dos benefícios associados ao intercâmbio pessoal de idéias proporcionado por outros métodos. Características das atividades do método Dephi:

• Identificação do problema, construção do questionário e apresentação do mesmo cada um dos elementos do grupo;

• Resposta ao questionário de forma anônima e independente por cada um dos elementos do grupo;

• Compilação das respostas e sua distribuição pelos membros do grupo acompanhado do questionário revisto;

• Resposta ao novo questionário da mesma forma descrita na fase 2, isto

é, de forma anônima e independente;

• Repetição das terceira e quarta fases até se atingir uma solução de consenso.

Questionários e pesquisas são conjuntos de questões destinadas a acumular rapidamente informações de um número grande de entrevistados. Questionários e / ou pesquisas são mais apropriados para grandes populações, quando forma de obtenção dos dados é rápida e onde a análise estatística é adequada.

37

Observações fornecem uma maneira direta de ver as pessoas em seu ambiente e como eles realizam seus trabalhos ou tarefas e execução de processos. É particularmente útil para os processos de execução quando as pessoas que usam o produto têm dificuldade ou estão relutantes em articular as suas necessidades. A observação, também chamado de "posto de trabalho", geralmente é feito externamente pelo observador visualizando o usuário que executa o trabalho dele ou dela. Também pode ser feito por um "observador participante", que realmente executa um processo ou procedimento para experimentar como é feito para descobrir necessidades ocultas.

Protótipos é um método de obtenção de uma opinião inicial sobre os requisitos, fornecendo um modelo de funcionamento do produto esperado antes de realmente construir. Uma vez que os protótipos são tangíveis, que permite aos interessados a experimentar com um modelo do seu produto final em vez de apenas discutir representações abstratas das suas necessidades.

4.1.3. Coleta de requisitos, saídas necessárias

Para (VARGAS, 2009) o documento dos requisitos do projeto registra os requisitos necessários para atender as necessidades do projeto. Os requisitos podem começar em um nível alto e tornar-se progressivamente mais detalhado conforme o projeto é desenvolvido. Antes da linha de base, os requisitos devem ser inequívocas (mensuráveis e verificáveis), rastreável, completa, consistente e aceitável para os principais interessados. O formato de um documento de requisitos podem variar de um simples documento listando todos os requisitos discriminados por partes interessadas e prioridade, para formas mais elaboradas contendo resumo executivo, descrições detalhadas, e anexos. Normalmente o documento contém:

• Titulo do projeto;

38

• Nome da pessoa que elaborou o documento;

• Descrição básica do projeto e da oportunidade;

• Objetivo do projeto;

• Requisitos funcionais desejáveis (priorizados);

• Requisitos não funcionais (relacionados ao desempenho, segurança, confidencialidade etc.);

• Requerimentos principais de qualidade;

• Potenciais impactos do projeto em outras áreas;

• Critérios de aceitação do projeto;

• Potenciais impactos do projeto em outras áreas;

• Restrições consideradas na criação dos requerimentos;

• Premissas consideradas na criação dos requerimentos;

• Registro de alterações no documento de requisitos;

• Aprovações;

Segundo (VARGAS, 2009) o plano de gerenciamento de requisitos do projeto é auxiliar ao plano de gerenciamento de projetos e descreve os procedimentos que serão utilizados para documentar como os requerimentos serão analisados, documentados e gerenciados através do projeto. No plano de gerenciamento dos requisitos deve estar documentado:

• Titulo do projeto;

• Nome da pessoa que elaborou o documento;

• Critério de priorização dos requisitos;

• Critério de rastreabilidade dos requisitos;

• Sistema de controle de mudanças nos requisitos;

• Níveis de aprovação de mudanças nos requisitos;

• Outros assuntos relacionados ao gerenciamento de requisitos do

projeto não previstos no plano de gerenciamento dos requisitos;

• Registro de alterações no documento;

• Aprovações;

Matriz de rastreabilidade de requisitos é um documento em forma de tabela que lista os requisitos do projeto de modo a permitir o rastreamento do

39

requisito dentro da EAP do projeto, determina seu status, teste e requisitos relacionados. Tem como objetivo garantir que cada requerimento adicione valor ao objetivo do projeto e esteja perfeitamente ligado ao escopo de atividades. Este documento contém os seguintes campos:

• ID do requisito;

• Nome do requisito;

• Descrição do requisito;

• Tipo do requisito;

• Prioridade do requisito

• Elemento(s) da EAP onde o requisito está associado;

• Outros requisitos associados e relacionados (ID);

• Status do requisito;

• Critério de aceitação e conclusão;

• Comentários;

4.2. Definir o escopo

Para (PMBOK 4, 2008) definir o escopo é o processo de desenvolvimento de uma descrição detalhada do projeto e do produto. A preparação detalhada da declaração do escopo é crítica para o sucesso e baseiam-se nas principais entregas, premissas e restrições que são documentas durante a iniciação do projeto. Durante o planejamento, o escopo do projeto é definido e descrito com maior especificidade à medida que mais informações sobre o projeto são identificadas. Riscos existentes, premissas e restrições são analisadas para a sua conclusão; riscos adicionais, suposições e restrições são acrescentados conforme necessário. Figura 12 mostra as entradas, ferramentas e técnicas, e saídas para a definição de escopo processo.

40

40 Figura 12. Mapa mental do processo de definir escopo. Fonte: (VARGAS, 2009, p. 59) 4.2.1.

Figura 12. Mapa mental do processo de definir escopo. Fonte: (VARGAS, 2009, p. 59)

4.2.1. Definir o escopo, entradas necessárias

Termo de abertura do projeto descrição no capítulo 4.1.1 Coleta de requisitos, entradas necessárias.

Documentação dos requisitos descrição no capítulo 4.1.3 Coleta de requisitos, saídas necessárias.

Ativos de processos organizacionais que podem influenciar o processo de definir o escopo incluem, mas não estão limitados a:

• Políticas, procedimentos e modelos para a declaração do escopo do projeto;

• Arquivos de projetos anteriores;

• As lições aprendidas com as fases anteriores ou projetos;

41

4.2.2. Definir o escopo, ferramentas necessárias

Opinião especializada é freqüentemente usada para analisar as informações necessárias para desenvolver a declaração do escopo do projeto. Essa sentença e conhecimentos serão aplicados para todos os detalhes técnicos. Tal habilidade é fornecida por qualquer grupo ou indivíduo com conhecimento ou treinamento especializado e está disponível a partir de muitas fontes, incluindo:

• Departamentos dentro da organização;

• Consultores;

• Partes interessadas, inclusive clientes ou patrocinadores;

• Profissionais e técnicos de associações;

• Grupos da Indústria;

• Especialistas no assunto;

Análise de produto para os projetos que têm como objetivo desenvolver um produto, ao contrário de um serviço ou resultado, a análise do produto pode ser uma ferramenta eficaz. Cada área de aplicação possui um ou mais métodos geralmente aceitos para traduzir as descrições dos produtos de alto nível em características mais detalhadas. A análise do produto inclui técnicas como a repartição do produto, análise de sistemas, análise de requisitos, engenharia de sistemas, engenharia de valor e análise de valor.

Identificação de alternativas é uma técnica usada para gerar diferentes abordagens para executar e realizar o trabalho do projeto. Uma variedade de técnicas de manejo geral pode ser utilizada, tais como brainstorming, pensamento laterais, par de comparações múltiplas, etc.

Oficinas descrição no capítulo 4.1.2 coleta de requisitos, ferramentas necessárias.

42

4.2.3. Definir o escopo, saídas necessárias

Para (VARGAS, 2009) a declaração do escopo do projeto é o documento que formaliza o escopo de todos os trabalhos a serem desenvolvidos no projeto, servindo de base para futuras decisões do projeto. É possível que, ao longo do projeto, a declaração de escopo seja revisada, ou refinada, para refletir as mudanças acontecidas nele. Normalmente a declaração do escopo contém:

• Titulo do projeto;

• Nome da pessoa que elaborou o documento;

• Nome do patricionador;

• Nome do gerente do projeto e suas resposabilidades e

autoridades;

• Nome dos integrantes do time do projeto;

• Descrição do projeto;

• Objetivo do projeto;

• Expectativas do cliente/patrocinador;

• Fatores de sucesso do projeto;

• Restrições;

• Premissas;

• Exclusões especificas (tudo que não será abordado pelo projeto);

• Principais atividades e estratégias do projeto;

• Principais entregas do projeto;

• Orçamento básico do projeto;

• Plano de entrega e marcos do projeto;

• Registro de alterações no documento;

• Aprovações;

Atualização dos documentos do projeto que pode incluir, mas não estão limitados a:

43

• Registros das partes interessadas;

• Requisitos de documentação;

• Requisitos da matriz de rastreabilidade.

4.3. Criar a estrutura analítica do projeto (EAP ou WBS)

Conforme (PMBOK 4, 2008) a EAP é o processo de subdivisão das principais entregas do projeto e do trabalho do desenvolvimento do produto em partes menores e mais gerenciáveis. A estrutura do EAP é decomposta hierarquicamente orientada a determinar as atividades necessárias a serem executadas pela equipe do projeto para realizar os objetivos do projeto, sendo que cada nível descendente da EAP representa uma definição cada vez mais detalhada do projeto. A EAP organiza e define o escopo total do projeto, e representa o trabalho especificado na declaração do escopo aprovado do projeto atual. Figura 13 mostra as entradas, ferramentas e técnicas, e saídas para a criar a estrutura analitica do projeto.

e saídas para a criar a estrutura analitica do projeto. Figura 13. Mapa mental do processo

Figura 13. Mapa mental do processo de criar a EAP. Fonte: (VARGAS, 2009, p. 60)

44

4.3.1.

Criar

a

necessárias

estrutura

analítica

do

projeto,

entradas

Declaração do escopo do projeto, descrição no capítulo 4.2.3 Definir o escopo, saídas necessárias.

Documentação dos requisitos escopo do projeto, descrição no capítulo 4.1.3 Coleta de requisitos, saídas necessárias.

Ativos de processos organizacionais, descrição no capítulo 4.2.1 Definir

o escopo, entradas necessárias.

4.3.2.

Criar

necessárias

a

estrutura

analítica

do

projeto,

ferramentas

Decomposição é a subdivisão das entregas do projeto em componentes menores e mais gerenciáveis, estes componentes são definidos até o nível de

pacote de trabalho. O nível de pacote de trabalho é o nível mais baixo na EAP

é o ponto em que a duração e custo das atividades para o trabalho pode ser

estimados e gerenciados de formar mais confiável. O nível de detalhe dos pacotes de trabalho irá variar de acordo com o tamanho e a complexidade do projeto. Um pacote de trabalho pode ser repartido em atividades menores.

A decomposição do trabalho total do projeto em pacotes de trabalho geralmente envolve as seguintes atividades:

• Identificar e analisar as atividades e trabalhos relacionados;

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

45

• Decompondo os níveis superiores da EAP em componentes

detalhados de nível inferior;

• Desenvolver e atribuição de códigos de identificação para os

componentes da EAP;

• Verificação de que o grau de decomposição do trabalho é necessário e suficiente;

A estrutura WBS pode ser criado em diversas formas, tais como:

• Usar as fases do ciclo de vida do projeto como o primeiro nível de

decomposição, com as entregas do produto e do projeto inserido no segundo nível, como mostrado na figura 14;

inserido no segundo nível, como mostrado na figura 14; Figura 14. Exemplo de EAP dividido por

Figura 14. Exemplo de EAP dividido por fases. Fonte: (PMBOK 4, 2008, p. 119)

• Utilizar principais entregas como o primeiro nível de decomposição, conforme mostrado na figura 15;

46

46 Figura 15. Exemplo de EAP com primeiras entregas como primeiro nível de decomposição. Fonte: (PMBOK

Figura 15. Exemplo de EAP com primeiras entregas como primeiro nível de decomposição. Fonte: (PMBOK 4, 2008, p. 120)

• Usar os subprojetos que podem ser desenvolvidos por organizações fora da equipe do projeto, tais como o trabalho contratado. O vendedor, então, desenvolve o apoio contrato estrutura de divisão de trabalho como parte do trabalho contratado.

4.3.3.

Criar

a

necessárias

estrutura

analítica

do

projeto,

saídas

Segundo (PMBOK 4, 2008) a EAP é uma decomposição hierárquica orientada a entrega do trabalho a ser executado pela equipe do projeto, para realizar os objetivos do projeto e criar as entregas necessárias, com cada nível descendente da EAP representa uma definição cada vez mais detalhada do trabalho do projeto. A EAP é finalizada através da criação de contas de controle para os pacotes de trabalho e um identificador exclusivo de um código de contas. Esses identificadores fornecem uma estrutura para a somatória hierárquica dos custos, cronograma e informações sobre recursos. Uma conta

47

de controle é um ponto de controle de gestão, onde o custo, escopo e cronograma estão integradas e em comparação com o valor acumulado para a medição de desempenho. contas de controle são colocados em pontos de gerenciamento selecionados no EAP. Cada conta de controle pode incluir um ou mais pacotes de trabalho, mas cada um dos pacotes de trabalho deve ser associado a apenas uma conta de controle.

Para (PMBOK 4, 2008) o dicionário da EAP é um documento gerado pelo processo de criação da EAP que da suporte as sua atividades. O dicionário da EAP fornece uma descrição mais detalhada dos componentes da EAP, inclusive pacotes de trabalho e contas de controle. Algimas informações contidas no dicionário da EAP:

• Código de identificador de conta;

• Descrição do trabalho;

• Organização por responsável;

• Lista dos marcos do cronograma;

• Programar a atividades relacionadas;

• Recursos necessários;

• Estimativas de custos;

• Requisitos de Qualidade;

• Critérios de aceitação;

• Referências técnicas;

• Informações contratuais;

Linha base do escopo é um componente do plano de gerenciamento de projetos. Componentes da linha de base escopo incluem:

• Declaração do escopo do projeto;

• EAP;

• O dicionário da EAP;

Atualização dos escopos do projeto os documentos que podem ser atualizados incluem, mas não está limitada a documentação de requisitos. Se

48

aprovado resultado das solicitações de mudança a partir do processo de criar EAP, então a documentação de requisitos pode precisa ser atualizada para incluir as alterações aprovadas.

4.4. Verificar o escopo

Segundo (PMBOK 4, 2008) a formalização da aceitação das entregas do projeto terminadas. A verificação do escopo é o processo de obtenção da aceitação formal pelas partes Interessadas do escopo do projeto terminado e das entregas associadas. A verificação do escopo do projeto inclui a revisão das entregas para garantir que cada uma delas foi terminada de forma satisfatória. Se o projeto foi finalizado antes do término (abortado), o processo de verificação do escopo do projeto deve determinar e documentar o nível e a extensão do término. A verificação do escopo difere do controle da qualidade porque a verificação do escopo trata principalmente da aceitação das entregas, enquanto o controle da qualidade trata principalmente do atendimento aos requisitos de qualidade especificados para as entregas. Em geral, o controle da qualidade é realizado antes da verificação do escopo, mas esses dois processos podem ser realizados em paralelo. Figura 16 mostra as entradas, ferramentas e técnicas, e saídas para a verificar o escopo do projeto.

49

49 Figura 16. Mapa mental do processo de verificar o escopo. Fonte: (VARGAS, 2009, p. 60)

Figura 16. Mapa mental do processo de verificar o escopo. Fonte: (VARGAS, 2009, p. 60)

4.4.1. Verificar o escopo, entradas necessárias

Plano de gerenciamento do projeto é o processo de documentação das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares. O plano de gerenciamento do projeto define como o projeto será executado, monitorado e controlado e encerrado. O projeto de plano de gestão de conteúdo irá variar de acordo sobre a área de aplicação e complexidade do projeto. O plano de gerenciamento de projeto é desenvolvido através de uma série de processos integrados, até o encerramento do projeto. Este processo resulta em um plano de gerenciamento de projetos que é progressivamente elaborada por atualizações e controladas e aprovadas.

Documentação dos requisitos escopo do projeto, descrição no capítulo 4.1.3 Coleta de requisitos, saídas necessárias.

Matriz

de

rastreabilidade,

requisitos, saídas necessárias.

descrição

no

capítulo

4.1.3

Coleta

de

50

Entrega validada consiste em verificar e as entregas que foram concluídas e a necessária correção para atender o processo de controle de qualidade.

4.4.2. Verificar o escopo, ferramentas necessárias

A inspeção que inclui atividades como medição, exame e verificação para determinar se o trabalho e as entregas atendem aos requisitos e critérios de aceitação do produto. Inspeções são por vezes chamadas de revisões, revisões do produto, auditorias e orientações. Em algumas áreas de aplicação esses diferentes termos têm significado estreito e específico.

4.4.3. Verificar o escopo, saídas necessárias

Entregas aceitas que preenchem os critérios que devem ser formalmente assinados e aprovados pelo cliente ou patrocinador. A documentação formal recebida do cliente ou patrocinador reconhecendo a aceitação formal das partes interessadas das entregas do projeto é encaminhado para o fase de encerramento do processo.

Solicitações de mudança que são as entregas terminadas que não foram formalmente aceitas são documentadas, juntamente com as razões da não aceitação. Esses resultados podem exigir um pedido de mudança para o reparo do defeito.As solicitações de mudança são processadas para revisão e destinação pelo processo integrado de mudanças.

51

Atualizações dos documentos que inclui todos os documentos que definem o escopo do produto ou do relatório sobre a conclusão do produto, estes documentos são resultantes do processo de verificação de escopo.

4.5. Controlar o escopo

Controle das mudanças no escopo do projeto. Esses processos interagem entre si e também com processos de outras áreas de conhecimento. Cada processo pode envolver o esforço de uma ou mais pessoas ou de grupos de pessoas, com base nas necessidades do projeto. Cada processo ocorre pelo menos uma vez em todos os projetos e também em uma ou mais fases do projeto, se ele estiver dividido em fases. Embora os processos estejam apresentados aqui como componentes distintos com interfaces bem definidas, na prática eles podem se sobre por e interagir de maneiras não detalhadas aqui. Figura 17 mostra as entradas, ferramentas e técnicas, e saídas para a controlar o escopo do projeto.

e técnicas, e saídas para a controlar o escopo do projeto. Figura 17. Mapa mental do

Figura 17. Mapa mental do processo de controlar o escopo. Fonte: (VARGAS, 2009, p. 60)

52

4.5.1. Controlar o escopo, entradas necessárias

Plano de gerenciamento do projeto, descrição no capítulo 4.4.1 Verificar

o escopo, entradas necessárias.

Informação sobre o desempenho do trabalho contém dados sobre o andamento do projeto, tais como atividades que tenham já iniciadas, os seus progressos e resultados que já se acabaram.

Documentação dos requisitos escopo do projeto, descrição no capítulo 4.1.3 Coleta de requisitos, saídas necessárias.

Matriz

de

rastreabilidade,

requisitos, saídas necessárias.

descrição

no

capítulo

4.1.3

Coleta

de

Ativos de processos organizacionais, descrição no capítulo 4.2.1 Definir

o escopo, entradas necessárias.

4.5.2. Controlar o escopo, ferramentas necessárias

Análise de variação são medições de desempenho do projeto usadas para avaliar as consequências das mudanças na linha base escopo. Importantes aspectos de controle do escopo do projeto incluem a determinação da causa e grau de variação em relação à base de escopo e decidir se uma ação corretiva ou preventiva é necessária.

53

4.5.3. Controlar o escopo, saídas necessárias

Medições de desempenho do trabalho incluem análise do planejanto das atividades, resultado da realização destas atividades ou outras medidas de desempenho escopo. Estas informações são documentadas e comunicadas às partes interessadas.

Atualização dos ativos de processos organizacionais inclui geralmente:

• Causas das variações;

• Ações corretivas escolhidas e as razões;

• Outros tipos de lições aprendidas do controle do escopo do projeto.

Solicitação de mudança, descrição no capítulo 4.4.3 Verificar o escopo, saídas necessárias

Atualização do plano de gerenciamento do projeto consiste na solicitação de mudanças forem aprovadas afetaram o escopo do projeto, a declaração de escopo, a EAP, o dicionário da EAP, estes documentos devem se revisados para atender as mudanças solicitadas. Mas estás mudanças também afetaram custos e cronograma, que também deverem ser revisados.

Atualizações dos documentos do projeto consistem na documentação de requisitos e na matriz de rastreabilidade de requisitos.

4.6.1. Vantagens do gerenciamento de escopo

O gerenciamento de escopo pode ser aplicado em diversos tipos de projetos não estão restritos aos gigantescos, alta complexidade e custo

54

elevados. Qualquer linha de negócio terá benefícios pelo gerenciamento do escopo, os principais são:

Evita surpresas durante o ciclo de vida do projeto.

Documenta e facilita as estimativas para futuros projetos.

Permitem determinar as atividades, recursos e prazos necessários para desenvolver o projeto e somente os necessários.

Agilidade nas tomadas de decisões, já que as informações estão organizadas e disponibilizadas.

Permite uma melhor divisão do trabalho.

4.6.2. Principais causas de fracassos em projetos

O projeto inclui muitas atividades e pouco tempo para realizá-las;

O excesso de documentação pode tornar os processos de difícil gerenciamento;

As estimativas financeiras pobres ou incompletas;

O projeto é baseado em dados insuficientes, ou inadequados;

Sistema de controle inadequado.

Treinamento e capacitação inadequados.

55

5. Estudo de caso sobre o projeto do sistema de controle de palestras e chamadas (SCPC)

O sistema de controle de palestras e chamadas, que foi desenvolvido com apoio e participação de estagiários, funcionários, professores, alunos e voluntários em conjunto ao NDTI (Núcleo de Desenvolvimento de Tecnologia da Informação) no segundo semestre de 2009, permite que os participantes se cadastrem nas palestras de interesse, e que os coordenadores do evento cadastrem os eventos que acontecerão, gerará listas de presença para os alunos que participarem e certificados para todos os participantes. O sistema no momento fornece um veículo de comunicação entre os alunos, comunidade e o CTZL (Centro Tecnológico da Zona Leste) na informatização da instituição com possibilidade de extensão para o World Wide Web.

5.1. Características principais do estudo de caso

Este estudo de caso sobre o do sistema de controle de palestras e chamadas (SCPC) tem como objetivo demonstrar as fases do ciclo de vida do projeto, processos de cada fase, documentos gerados e utilizados para

gerenciar este projeto e características em comum os descritos no PMBOK 4

2008.

5.2. Modelo de ciclo de vida iterativo incremental

Ciclo de vida utilizado no desenvolvimento do sistema de controle de palestras e chamadas (SCPC) é baseado no modelo iterativo e incremental,

56

que está organizado nas seguintes fases (iniciação, elaboração, construção e transição) projetos desenvolvidos segundo está abordagem dividem o desenvolvimento de um produto de software em ciclos. Em cada ciclo é alocado um subconjunto de requisitos que são desenvolvidos, no próximo ciclo, outro subconjunto dos requisitos será desenvolvido e requisitos já finalizados podem sofre alterações nos próximos ciclos. Por meio da construção incremental e iterativa de novas funcionalidades são adicionadas até que o sistema completo esteja construído.

É similar ao modelo de ciclo de vida proposto pelo PMBOK 4 2008 no qual cada fase do projeto acontece à entrega, ou finalização, de um determinado trabalho. Mas o ciclo de vida utilizado no desenvolvimento do projeto SCPC não tem uma fase especifica de controle, e sim um processo responsável por esta atividade o gerenciamento de configurações e mudanças que é realizado durante todo o ciclo de vida do projeto. Este processo geralmente é apoiado por softwares específicos, foi utilizado sistema de controle de versões e mudanças SubVersion o que permitiu uma maior interação entre os envolvidos no desenvolvimento do projeto, pois armazena as mudanças nas informações, o que permiti comparar versões diferentes de documentos, algo essencial para evitar o retrabalho, pois programadores gastam horas fazendo pequenas alterações em seus aplicativos e então precisão desfazer essas modificações ou verificá-las alguns dias depois. Em os benefícios do processo de gerenciamento de configurações e mudanças é mais evidente em projetos maiores onde vários programadores e analistas trabalham juntos e simultâneos nos mesmos arquivos o que pode levar a uma grande desordem.

5.3. EAP do projeto SCPC

Podemos notar que os processos utilizados para desenvolver o projeto SCPC se repetem ao longo das fases do ciclo de vida uma característica do

57

modelo iterativo e incremental que pode ser observado na figura 16, mas em cada fase os processos são decompostos até o nível de pacote de trabalho específicos daquela fase como demonstra a figura 18, 19 e 20.

daquela fase como demonstra a figura 18, 19 e 20. Figura 18. EAP do projeto SCPC.

Figura 18. EAP do projeto SCPC. Fonte: (SCPC, 2009, s/p)

Figura 18. EAP do projeto SCPC. Fonte: (SCPC, 2009, s/p) Figura 19. Fase de iniciação do

Figura 19. Fase de iniciação do projeto SCPC com seus processos divididos em pacotes de trabalho necessário para conclusão do projeto. Fonte: (SCPC, 2009, s/p)

58

58 Figura 20. Fase de elaboração do projeto SCPC com seus processos divididos em atividades necessárias

Figura 20. Fase de elaboração do projeto SCPC com seus processos divididos em atividades necessárias para conclusão do projeto. Fonte: (SCPC, 2009, s/p)

5.4. Documentação do escopo do projeto e produto

Muitos documentos, ferramentas, técnicas foram utilizados para gerenciar o escopo do projeto e do produto SCPC, alguns se identificam com os propostos pelo PMKOK 4 2008 e outros não. Os principais documentos utilizados são os seguintes:

Documento de visão define o que os envolvidos esperam do produto a ser desenvolvido, em termos das necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais pretendidos, proporciona a base contratual para requisitos técnicos mais detalhados.

59

Diagrama de caso de usos que corresponde a uma visão extremamente de alto nível do sistema. Esse diagrama representa graficamente os atores (envolvidos), casos de usos (funcionalidades do sistema) e relacionamentos entre esses elementos.

Diagrama de classes é muito utilizado na construção do modelo de classe desde o nível de analise até o nível de especificação. A implementação do sistema é toda baseada nos modelos de classe desenvolvidos nos processos de analise e design.

Estes documentos descritos acima podem ser encontrados nos anexos deste trabalho.

5.5. Considerações sobre o estudo de caso

Um dos pontos que podem ser destacados no projeto SCPC é o fato de que foi desenvolvido por uma equipe inexperiente em gerenciamento de projetos formada por estagiários e voluntários, sem uma pessoa com experiência no papel de gerente do projeto, a pessoa responsável por gerenciar o projeto também tinha que realizar outras atividades, este sobrecarga de trabalho em uma pessoa gerou algumas falhas durante o ciclo de vida do projeto, alguns documentos não foram atualizados conforme as mudanças ocorriam e outros documentos nem foram criados. Para evitar estes problemas poderia utiliza as melhores práticas descritas no PMBOK 4 2008 para gerenciamento de escopo do projeto, dentre elas as descritas no processo de verificar o escopo e controlar o escopo.

Uma pergunta que deve ser respondida depois da conclusão de um projeto foi bem sucedido. Só que está pergunta é passível de pelo menos duas respostas, uma delas seria que não foi bem sucedido por não realizou todo o

60

trabalho definido como necessário para conclusão do projeto e a outra resposta é que foi bem sucedido, pois apesar dos imprevistos o projeto foi entregue dentro do prazo e totalmente funcional. É importante ressaltar que os processos responsáveis por avaliar os resultados obtidos com o termino do projeto no PMBOK 4 2008 encontram-se na fase de encerramento do ciclo de vida do projeto, está fase também é conhecida como fase de aprendizado onde problemas ocorridos podem ser avaliados para que não ocorram nos próximos projetos.

61

6. Considerações finais

Os processos de gerenciamento do escopo iniciam-se com sua definição. Primeiramente, é necessário transformar as expectativas e desejos dos clientes em documentos formais, que são os seguintes a declaração do escopo, a documentação dos requisitos, o plano de gerenciamento dos requisitos, a matriz de rastreabilidade dos requisitos e estrutura analítica do projeto. Para definição destes processos é necessário o envolvimento dos interessados no projeto, e podem ser auxiliados por técnicas JAD e DELPHI, até o fechamento de cada documento. E nestes documentos devem constar de forma detalhada e deixar nenhuma necessidade ou expectativa como subentendida.

As mudanças são comuns em todos os projetos e inevitáveis. O mais importante possuir o controle sobre elas. Devemos criar um único ponto de contato entre as partes envolvidas, o gerente do projeto deve intermédia este para sempre está informado do que acontece no projeto. Nenhuma alteração deve ocorrer sem o consentimento do gerente do projeto e a devida análise de impacto no prazo, custo e risco. Falhas de controle nem sempre estão relacionadas com as atividades controlar o escopo também são afetados pelos processos de comunicação. Um usuário pode solicitar uma alteração diretamente ao programador, que as executa sem consultar o gerente do projeto, deixando de lado outras atividades em andamento. O usuário não percebe que seus pedidos desestabilizam o desenvolvimento, o que afeta a produtividade e qualidade, com conseqüências nos prazos e custo.

O sucesso no gerenciamento do escopo está em utilizar um canal único de comunicação entre os envolvidos e na formalização de todas as informações, relevantes, incluindo cada solicitação de alteração e seu respectivo impacto no projeto. Muitas mudanças devem ser adiadas para não inviabilizarem a conclusão do projeto.

62

Referências bibliográficas

BRUZZI, Demerval Guilarducci. Gerenciamento de Projetos - 1ª Edição - Distrito Federal: Editora SENAC Distrito Federal, 2008.

KERZNER, Harold. Gestão de Projetos As Melhores Práticas - 2ª Edição - Bookman, 2004.

PMISP. Introdução aos conceitos do gerenciamento de escopo. Disponível em < http://www.pmisp.org.br/instituto.asp>. Acessado em 15 de Setembro de 2010 às 14 horas

PMI. PMBOK - Um guia do Conjunto de Conhecimentos em Gerenciamento de Projetos - 4ª Edição - Pensilvânia: PMI, 2008.

SOTILLE, Mauro. Visão geral dos processos do gerenciamento de projetos –

em

<http://www.pmtech.com.br/artigos/Processos_PMBOK_4a_Mauro_Sotille.pdf>.

Acesso em 25 de Agosto de 2010 às 17 horas

PMBOK

Edição.

Disponível

VALERIANO, Dalton L. Gerenciamento Estratégico e Administração por Projetos – 1ª Edição - Makron Books, 2001.

VARGAS, Ricardo Viana. Gerenciamento de Projetos - 7ª Edição - Rio de Janeiro: Brasport, 2009.

XAVIER, Carlos Magno da Silva, CHUERI, Luciana de O. Vilanova. Metodologia de Gerenciamento de Projetos no Terceiro Setor – 1ª Edição - Rio de Janeiro: Brasport, 2008.

63

Anexos

Anexo A. Documento de visão

Versão 1.0

Histórico da Revisão

 

Data

 

Versão

Descrição

 

Autor

6

de

agosto

de

1.0

Versão beta

Glauber

Rocha

2009

 

Romão

 

Índice Analítico

 

Introdução

Posicionamento

Descrições dos Envolvidos e Usuários

Visão Geral do Produto

Características do Produto

Restrições

Limites de qualidade

Precedência e Prioridade

Outros Requisitos do Produto

Requisitos da Documentação

Introdução

A finalidade deste documento é coletar, analisar e definir as características e

necessidades de alto nível do Sistema de Controle de Palestras e Chamadas. Ele se

concentra nos recursos necessários aos envolvidos e aos usuários-alvo e nas razões que

levam a essas necessidades. Os detalhes de como o sistema atinge essas necessidades

são descritos nos modelos de caso de uso e nas especificações suplementares.

64

Finalidade

A finalidade deste documento é definir os requisitos de alto nível do Sistema de

Controle de Palestras e Chamadas em termos de necessidades dos usuários finais.

Escopo

Este Documento de Visão refere-se ao Sistema de Controle de Palestras e Chamadas,

que será desenvolvido pelo NDTI (Núcleo de Desenvolvimento de Tecnologia da

Informação). Esse sistema permitirá que os participantes se cadastrem na palestras de

interesse, e que os coordenadores do evento cadastrem os eventos que acontecerão,

gerará listas de presença para os alunos que participarem e certificados para todos os

participantes.

Definições, Acrônimos e Abreviações

Consulte o documento Glossário.

Referências

NA.

Posicionamento

Oportunidade de Negócios

O Sistema de Controle de Palestras e Chamadas no momento fornece um veículo de

comunicação entre os alunos, comunidade e o CTZL (Centro Tecnológico da Zona

Leste) na informatizado na instituição com possibilidade de extensão para a World

Wide Web.

Os benefícios previstos dessa abordagem incluem:

65

2. O network gerado pela divulgação de nossos eventos levará ao maior número de correntes discentes e docentes para nossas vagas disponíveis, aumentando assim a qualidade de nosso ensino.

3. A divulgação dos trabalhos realizados por nossos colaboradores contará como uma vantagem competitiva no mercado de trabalho.

Descrição do Problema

O problema

Divulgar os eventos acadêmicos do CTZL

Afeta

Docentes, discentes e comunidade

O seu impacto é

Que não participam de eventos, pois não têm meios fáceis para se atualizarem e participarem dos eventos.

Uma solução ideal seria

Manter um sistema online para divulgação e controle dos eventos que acontecerão no CTZL.

Sentença de Posição do Produto

Para

Docentes, discentes e comunidade

Quem

Quiser acompanhar grupos ou eventos específicos de formação profissional

Sistema de Controle de Palestras e Chamadas

é um software

Que

Divulga e mantém o cadastro dos participantes dos eventos.

Diferente de

O estado atual que requer que eles verifiquem as notícias com colegas e secretária regularmente para encontrar aqueles de seu interesse.

Nosso produto

Matem a divulgação dos eventos, assim os interessados podem acompanhar nossos eventos e se inscreverem por ele.

Descrições dos Envolvidos e Usuários

66

Demografia do Público

O Público-alvo desse sistema compreende um segmento da sociedade de interesse intelectual e acadêmico profissional.

Resumo dos Envolvidos

Nome

Representa

Papel

Diretor

Diretor da FATEC.

Aprova divulgação de novos eventos, assinar certificados de participação.

Coordenador

de

Coordenadores dos cursos da instituição.

Entrar em contato com parceiros da FATEC, assinar certificados de participação.

Curso

Parceiros

Palestrantes e empresas

 

interessadas desenvolvimento do FATEC.

no

Apresentar propostas de incentivo ao desenvolvimento do FATEC.

Resumo dos Usuários

Nome

Representa

Papel

Participante

Alunos ou convidados, que participaram das palestras.

Informar-se

e

inscrever-se

em

novos eventos.

 

Coordenador

Responsáveis pelos eventos que acontecerão no CTZL.

Cadastrar novos eventos, palestrantes e voluntários, que poderão ser usuários do sistema.

Administrador

Operador que determinará os perfis de acesso ao sistema, e suas características visuais.

Colocar conteúdo no site da Web, categorizar o conteúdo, perfis e características do sistema.

Voluntario

Quem participará de atividades voluntárias, como operador do sistema ou não.

Inscrever e marcar presença dos participantes no dia do evento e gerar certificados.

Ambiente do usuário

67

As pessoas acompanharão as notícias sobre os eventos através da página web.Os padrões de uso não são previsíveis nesse momento, embora haja previsão de volumes maiores durante a última semana que antecede os eventos, como a Semana Tecnológica.

Os usuários apenas terão que ter um computador com acesso a internet para utilizarem os serviços disponibilizados pelo Sistema de Controle de Palestras e Chamadas, sendo que para os alunos a FATEC também disponibiliza de computadores conectados a internet para este fim.

Necessidades dos Principais Envolvidos/Usuários

Necessidade

Prioridade

Preocupações

Solução

Soluções Propostas

Atual

Especificar perfil

Alta

Nível

de

Nenhuma

Permitir vários níveis de seleção de páginas

granularidade

Receber resposta quando cadastrar em nova palestra

Alta

Níveis de volume

Nenhum

Usar arquitetura em camadas para permitir a escalabilidade

e

tempo de

resposta

Divulgar

as

Alta

Tempo

de

É

feita

Fornecer links em uma página da Web para os itens de eventos

palestras

disponibilidade

pessoalmente

com

comunicação

 

entre

os

alunos

Divulgar

o

Alta

Manter

sistema

Selecionar

Estabelecer parcerias com outros sites

endereço

atualizado

canais

de

eletrônico

do

propaganda

 

sistema

para

atingir

indiretamente

os segmentos

do mercado

Verificar

a

Média

Nenhuma

Nenhuma

Fornecer relatórios aos anunciantes sobre o

distribuição

de

publicidade

para

número

de

estimar

a

visualizações do conteúdo publicitário

eficiência

68

Alternativas e Concorrência

No momento, não existe uma alternativa direta para esse serviço.

Visão Geral do Produto

Perspectiva do Produto

Este produto impulsionará a participação dos alunos e comunidade acadêmica em geral nas atividades de toda a instituição, que forem divulgadas por ele. Graficamente, o sistema pode ser visto desta forma:

nas atividades de toda a instituição, que forem divulgadas por ele. Graficamente, o sistema pode ser

69

Anexo B. Documento de caso de uso

69 Anexo B. Documento de caso de uso

70

Anexo C. Diagramas de classe

Manter inscriçãoTO

70 Anexo C. Diagramas de classe Manter inscriçãoTO
70 Anexo C. Diagramas de classe Manter inscriçãoTO

71

71
71

72

Anexo

D.

Sugestão

de

diferença entre RUP e PMBOK

continuidade

deste

trabalho

Como sugestão de continuidade deste trabalho, indico um estudo comparativo entre gerenciamento do escopo de projetos de software com RUP e PMBOK, quais vantagens, desvantagens, diferenças das duas abordagens.

73

Anexo E. Autorização de uso deste trabalho

Eu, Rafael Nise Pereira, autorizo a inserção deste trabalho na biblioteca digital de trabalhos de conclusão de curso, no portal da FATEC-ZL (www.fateczl.edu.br) bem como em qualquer meio eletrônico utilizado pela instituição, para os fins educacionais, técnicos, culturais de divulgação institucional e não comerciais.