SUMRIO

INTRODUO.......................................................................................................3

DESAFIO 1.............................................................................................................4

2.1

Gerenciamento de riscos do projeto..................................................................4

2.1.1

Planejar o gerenciamento dos riscos.............................................................4

2.1.2

Identificar os riscos.........................................................................................4

2.1.3

Realizar a anlise qualitativa dos riscos.........................................................5

2.1.4

Realizar a anlise quantitativa dos riscos......................................................5

2.1.5

Planejar respostas aos riscos.........................................................................5

2.1.6

Controlar os riscos..........................................................................................5

2.2

GERENCIAMENTO DO ESCOPO DO PROJETO............................................6

2.2.1

Principais tpicos............................................................................................7

2.2.2

Opinio pessoal..............................................................................................8

2.3

fornecedores.......................................................................................................8

2.4

Partes Interessadas............................................................................................9

Desafio 2..............................................................................................................11

3.1.1

Decises de projeto de arquitetura...............................................................11

3.1.2

Organizao de sistema...............................................................................11

3.1.2.1 Modelo de repositrio....................................................................................11

3.1.2.2 Modelo cliente-servidor.................................................................................11
3.1.2.3 Modelo de mquina abstrata (em camadas)................................................12
3.1.3

Estilos de decomposio modular................................................................12

3.1.4

Modelos de objetos.......................................................................................12

3.1.4.1 Decomposio Orientada a Objeto..............................................................12

3.1.4.2 Pipelining orientado a funes.....................................................................13
3.1.5

Arquiteturas de referncia............................................................................13

3.1.5.1 Controle centralizado....................................................................................14

3.1.5.2 Sistemas orientados a eventos....................................................................14
4

Desafio 3..............................................................................................................15

4.1.1

Programao para Web II.............................................................................15

4.1.1.1 Comparao de frameworks para desenvolvimento web (Java).................15

4.1.1.2 Relacione os custos/benefcios de usar frameworks no desenvolvimento
Web

16

4.1.1.3 Programao Java Web (plataforma de desenvolvimento).........................17

5

CONCLUSO......................................................................................................18

REFERNCIAS...........................................................................................................19

1 INTRODUO
Na vida cotidiana sempre convivemos com riscos. Podemos por
exemplo: ser assaltados, contrair doenas ou sofrer um acidente de carro. Para
esses casos h solues simples como: ter o veculo segurado, vacinar-se ou andar
com cinto de segurana. Dentro de um projeto de desenvolvimento de um sistema
no diferente.
Corre-se o risco de indesejveis surpresas. H situaes em que
poder incidir um risco grave e que poder significar o fracasso do prprio projeto.
A Gerncia de Riscos est presente em vrias metodologias de
Gesto de Projetos. Neste trabalho ser escolhido como base o modelo de
Gerenciamento de Riscos do PMBOK (Project Management Body of Knowledge)
desenvolvido pelo PMI (Project Managemanent Institute).
O fator de maior peso na escolha do PMBOK como o modelo a ser
detalhado o fato de existir uma disciplina ou grupo de processos que se dedica ao
estudo do risco.

2 DESAFIO 1

2.1 GERENCIAMENTO DE RISCOS DO PROJETO

O risco do projeto um evento ou condio incerta que, se ocorrer,
ter um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como
tempo, custo, escopo ou qualidade.
Um risco pode ter uma ou mais causas e, se ocorrer, um ou mais
impactos.
2.1.1 Planejar o gerenciamento dos riscos
Indica como conduzir as atividades de gerenciamento dos riscos de
um projeto.
Riscos mais comuns tem consequncias que impactam o
escopo, cronograma, custo, e/ou qualidade.
A causa pode ser um requisito, premissa, restrio, ambiente
e/ou condio que tenha efeito sobre os itens acima.

2.1.2 Identificar os riscos

Identificar os riscos o processo de determinao dos riscos que
podem afetar o projeto e de documentao de suas caractersticas. O principal
benefcio desse processo a documentao dos riscos existentes e o conhecimento
e a capacidade que ele fornece equipe do projeto de antecipar os eventos.
2.1.3 Realizar a anlise qualitativa dos riscos
A classificao relativa ou a lista de prioridades dos riscos do
projeto. Riscos agrupados por categorias. Causas dos riscos. Lista de riscos que
exigem resposta a curto prazo. Lista de riscos para anlise e resposta adicionais.
Lista de observao de riscos de baixa prioridade. Tendncias dos resultados da
anlise qualitativa de riscos.

2.1.4 Realizar a anlise quantitativa dos riscos

realizada nos riscos que foram priorizados

pelo processo

Anlise qualitativa dos riscos por afetarem potencial e significativamente as

demandas conflitantes do projeto, analisa o efeito desses eventos de risco e lhes
atribui uma classificao numrica.
Apresenta uma abordagem quantitativa para a tomada de
decises na presena da incerteza.
Usa tcnicas como a simulao de Monte Carlo e a anlise da
rvore de deciso.
2.1.5 Planejar respostas aos riscos
O planejamento de respostas a riscos o processo de desenvolver
opes e determinar aes para aumentar as oportunidades e reduzir as ameaas
aos objetivos do projeto.
As respostas a riscos planejadas precisam ser adequadas
importncia do risco, econmicas ao enfrentar o desafio, rpidas, realistas dentro do
contexto do projeto, acordadas por todas as partes envolvidas e ser de propriedade
de uma pessoa especfica.
frequentemente necessrio selecionar a melhor resposta a
riscos a partir de diversas opes.
2.1.6 Controlar os riscos
Controlar os riscos o processo de implementao de planos de
respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos
riscos residuais, identificao de novos riscos e avaliao da eficcia do processo de
riscos durante todo o projeto. O principal benefcio desse processo a melhoria do
grau de eficincia da abordagem dos riscos no decorrer de todo o ciclo de vida do
projeto a fim de otimizar continuamente as respostas aos riscos.
2.2 GERENCIAMENTO DO ESCOPO DO PROJETO
O captulo 5 aborda o tema gerenciamento do escopo do projeto,

que so os processos necessrios para garantir que o projeto atenda aos requisitos
bsicos para que o projeto possa ser terminado com sucesso. Com isto, podemos
definir os limites do projeto mostrando para o cliente o que ele pode ou no esperar
como resultado dos trabalhos do projeto.
Devemos lembrar que para iniciarmos o gerenciamento do escopo
do projeto, devemos ter j prontos o project charter e a declarao do escopo
preliminar do projeto, pois a partir destes, iremos nos aprofundar no projeto e
iniciarmos o plano de gerenciamento do escopo do projeto, detalhando os trabalhos.
Dentre os processos, esto descritos a estrutura necessria para o
desenvolvimento do planejamento do escopo, da definio do escopo, da criao da
EAP, da verificao do escopo (onde o projeto sofre as verificaes para uma
entrega) e do controle do escopo (onde o projeto sofre mudanas).
Em cada um deles o captulo 5 do PMBOK nos mostra quais os
componentes necessrios para serem utilizados como forma de entrada de
informaes para estes processos e destes, quais as suas origens, e por vezes
fazendo referncias a outros captulos que teriam maiores informaes. Tambm nos
mostra como deve ser o processamento das informaes provenientes destas
entradas para que o resultado destes processamentos sejam as sadas
demonstradas em cada um deles, nos quais descrevo abaixo:
- No processo de planejamento do escopo onde a sada o plano de
gerenciamento do escopo do projeto, o captulo aponta as entradas e d diretrizes
para extrair estas informaes onde podemos notar que destas, at mesmo as
condies de mercado poderiam afetar a forma como deveria ser gerenciado o
escopo do projeto. Na sada deste item, teremos a informao necessria de como o
escopo do projeto ser definido, documentado, verificado, gerenciado e controlado
pela equipe de gerenciamento de projetos.
- No processo de definio do escopo descrevemos mais
detalhadamente o escopo do projeto, pois, ao planejar temos uma viso mais
abrangente do projeto, tendo como sada a declarao do escopo do projeto, a

atualizao do escopo do projeto, assim como o processamento das mudanas

aprovadas.
- No processo de criao da EAP, identificamos as entregas atravs
da decomposio total dos trabalhos do projeto em componentes menores para que
seja possvel o gerenciamento de uma forma mais fcil. Neste processo, tambm
importante o dicionrio da EAP, onde descrevemos o que e como deve ser feito
cada entrega.
- No processo de verificao do escopo temos um controle das
entregas terminadas para que estas possam ser aceitas ou sofrerem solicitaes de
mudanas e/ou correes.
- No processo de controle do escopo implementado o controle do
impacto das mudanas sobre o escopo do projeto, e responsvel por atualizaes
nos documentos gerados pelos outros processos, como a declarao do escopo, a
EAP e seu dicionrio e o plano de gerenciamento do escopo do projeto.
2.2.1 Principais tpicos
Planejamento do escopo como podemos gerenciar de forma
efetiva para obter o sucesso do projeto.
Sada: Plano de gerenciamento do projeto
Definio do escopo definio detalhada do escopo do projeto
Sadas Declarao de escopo do projeto
Criar EAP definio dos entregveis do projeto
Sadas EAP e dicionrio de EAP
Verificao do escopo validao das entregas com o escopo
definido
Sadas - entregas aceitas ou solicitaes de mudanas e/ou
correes
Controle do escopo gerenciamento das solicitaes de
mudanas
Sadas atualizaes do plano de gerenciamento do projeto, da

declaraes de escopo do projeto e da EAP

2.2.2 Opinio pessoal
O gerenciamento do escopo do projeto fundamental principalmente
na rea de tecnologia da informao para ajudar na documentao dos projetos.
Ainda existem muitos projetos do tipo eternos, que por no terem sido
documentados o seu escopo, estes nunca acabaram.
Porm, estes processos devem ser muito bem dosados devido ao
seu alto nmero de documentao gerada, que pode criar um ambiente
demasiadamente burocrtico. Para garantir a dose certa, o gerente de projetos deve
possuir o feeling necessrio para desenvolver as informaes dos documentos de
acordo com o cliente e o projeto a ser desenvolvido.
Particularmente tinha muitas dvidas em relao sobre como
controlar o escopo de projetos devido a quantidade de solicitaes feitas pelos
usurios, que no meu caso so os gerentes e diretores da empresa onde trabalho.
Para isso a EAP foi fundamental onde j a utilizei para demonstrar o status atual do
projeto que estou trabalhando. A visualizao das tarefas fica muito simples e ajuda
at mesmo a demonstrar as dimenses do projeto.
2.3 FORNECEDORES
O PMBoK diz que esta rea inclui os processos necessrios para
comprar ou adquirir produtos, servios ou resultados externos sua equipe do
projeto. Veja que em um projeto, nem sempre ser possvel desenvolver seus
produtos, ferramentas e servios, sendo necessria a compra ou aquisio dos
mesmos.

Os

objetivos

desta

rea

so:

Aumentar

eficincia

em

compras/aquisies; Fazer o melhor uso dos recursos internos e externos; Acelerar

o cronograma Podemos utiliz-los para terceirizar um servio ou comprar algo
pronto do que desenvolver internamente no projeto; Gerenciar/melhorar os custos
Procurar a melhor forma de obter um melhor ROI; Reduzir os riscos relacionados, j
que so grandes fonte de riscos; Existem apenas 4 processos nesta rea:

Iniciao Planejamento

Execuo

Monitoramento e Controle

Encerramento

2.4 PARTES INTERESSADAS

So todas as pessoas e organizaes envolvidas no projeto, ou
cujos interesses podem ser positiva ou negativamente afetados pela realizao ou
pelos resultados do projeto. As partes interessadas tambm podem exercer
influncia sobre o projeto e sobre os membros da equipe do projeto. [PMI 2008, p.
23]
Desde a iniciao do projeto, a equipe de gerenciamento precisa
identificar as partes interessadas internas e externas. Ao longo do planejamento e da
execuo do projeto, o gerente do projeto e sua equipe devem gerenciar as
diferentes necessidades, preocupaes e expectativas das partes interessadas, bem
como a influncia destas no projeto, para garantir um resultado bem sucedido.
Alguns exemplos de possveis partes interessadas podem incluir:
Patrocinador (Sponsor): pessoa ou grupo que fornece os recursos
financeiros para a realizao do projeto, e que tambm prov o aval estratgico e
poltico que viabiliza e promove o projeto e o defende;
A equipe do projeto, que inclui o gerente do projeto, a equipe de
gerenciamento do projeto, e outros membros da equipe que executam trabalho no
projeto mas no esto necessariamente envolvidos com o gerenciamento:
Clientes e usurios;
Presidente, donos e executivos;
Acionistas e investidores;
Gerentes funcionais;

10

Escritrio de projetos (Project Management Office - PMO),

gerentes e comits de portflios e de programas;
Fornecedores e parceiros comerciais;
Concorrentes;
Governo, em suas diversas esferas e poderes;
Organismos de regulao e fiscalizao internos e externos,
incluindo auditorias, agncias, conselhos, sindicatos e associaes institucionais,
profissionais e oficiais;
Organizaes no governamentais (ONG);
Comunidades, vizinhana e populao abrangida pelas aes e
resultados do projeto.
Outros elementos importantes que influenciam projetos so as
culturas e estilos organizacionais, bem como os fatores ambientais da empresa, do
mercado, da sociedade e da localizao geopoltica onde o projeto acontece.

11

3 DESAFIO 2

3.1.1 Decises de projeto de arquitetura

Projeto de arquitetura um processo criativo cujas atividades
diferem radicalmente dependendo do tipo de sistema que est sendo desenvolvido.
Contudo, uma srie de decises comuns afetam todos os processos
de projeto.

3.1.2 Organizao de sistema

Reflete a estratgia bsica que usada para estruturar um sistema.
Trs estilos de organizaes so amplamente usados:

3.1.2.1

O estilo de repositrio de dados compartilhados;

Estilo de servios e servidores compartilhados;

Estilo de mquina abstrata ou em camadas.

Modelo de repositrio
Os subsistemas devem trocar dados. Isso pode ser feito de duas

maneiras:
Os dados compartilhados so mantidos em um banco de dados
central ou repositrio e podem ser acessados por todos os subsistemas;
Cada subsistema mantm seu prprio banco de dados e passa
dados explicitamente para outros subsistemas.
Quando grandes quantidades de dados so compartilhadas, o
modelo de repositrio de compartilhamento o mais usado.
3.1.2.2

Modelo cliente-servidor
um modelo distribudo de sistema que mostra como dado e

processamento so distribudos por uma variedade de componentes.

12

Estabelece

servidores

independentes

que

fornecem

servios

especficos, tais como impresso, gerenciamento de dados, etc.

Estabelece clientes que acessam esses servios.
uma rede que permite aos clientes acessar os servidores.
3.1.2.3

Modelo de mquina abstrata (em camadas)

Usado para modelar o interfaceamento dos subsistemas.
Organiza o sistema em um conjunto de camadas (ou mquinas

abstratas), cada uma dss quais fornecendo um conjunto de servios.

Apoia o desenvolvimento incremental dos subsistemas em camadas
diferentes. Quando uma camada de interface muda, somente a camada adjacente
afetada.
Contudo, frequentemente artificial estruturar sistemas dessa
maneira.

3.1.3 Estilos de decomposio modular

Estilos de decomposio de subsistemas em mdulos.
No

distino

rgida

entre

organizao

de

sistema

decomposio modular.
3.1.4 Modelos de objetos
Estruturar o sistema em um conjunto de objetos fracamente
acoplados com interfaces bem definidas.
A decomposio orientada a objetos est relacionada identificao
de classes de objetos, aos seus atributos e s suas operaes.
Quando implementados, os objetos so criados a partir dessas
classes e um tipo de controle usado para coordenar as operaes de objetos.
3.1.4.1

Decomposio Orientada a Objeto

Estruturar o sistema em um conjunto de objetos fracamente

13

acoplados com interfaces bem definidas.

A decomposio orientada a objetos est relacionada identificao
de classes de objetos, aos seus atributos e s suas operaes.
Quando implementados, os objetos so criados a partir dessas
classes e um tipo de controle usado para coordenar as operaes de objetos.
3.1.4.2

Pipelining orientado a funes

Transformaes funcionais processam suas entradas para produzir

sadas.
Pode ser chamado de estilo de duto (pipe) e filtro (como no shell
UNIX)
Variaes dessa abordagem so muito comuns. Quando as
transformaes so sequenciais, isso um modelo sequncia em lotes, que
extensivamente usado em sistemas de processamento de dados.
No realmente adequado para sistemas interativos.
3.1.5 Arquiteturas de referncia
Os modelos de arquitetura podem ser especficos para algum
domnio de aplicao.
Existe dois tipos de modelos de domnio especfico
Modelos genricos que so abstraes de uma srie de sistemas
reais que englobam as caractersticas principais desses sistemas. Abordados no
Captulo 13.
Modelos de referncia so mais abstratos, um modelo idealizado.
Fornece um meio de informao sobre essa classe de sistema e sobre comparao
de arquiteturas diferentes.
Os modelos genricos so geralmente modelos bottom-up. Os
modelos de referncia so modelos top-down.
Os modelos de referncia so derivados de um estudo de domnio
de aplicao ao invs de sistemas existentes.
Pode ser usado como base para a implementao de sistemas, ou
comparar sistemas diferentes. Atua como um padro contra o qual os sistemas

14

podem ser avaliados.

O modelo OSI um modelo de camadas para sistemas de
comunicao.
3.1.5.1

Controle centralizado
Um subsistema de controle responsvel pelo gerenciamento da

execuo de outros subsistemas.

Modelo chamada-retorno
o modelo de subrotina top-down onde o controle inicia no topo de
uma hierarquia de subrotina, e se move para baixo da hierarquia. aplicvel a
sistemas seqenciais.
Modelo de gerenciador
aplicvel a sistemas concorrentes. Um componente de sistema
controla a parada, o incio e a coordenao de outros processos de sistema. Pode
ser implementado em sistemas seqenciais como uma declarao Case.
3.1.5.2

Sistemas orientados a eventos

Dirigidos por eventos gerados externamente onde o timing dos

eventos est fora do controle dos subsistemas que processam o evento.

Dois modelos dirigidos a eventos principais
Modelos de broadcast. Um evento transmitido a todos os
subsistemas. Qualquer subsistema programado para manipular esse evento pode
responder a ele.
Modelos orientados a interrupes. Usado em sistemas de tempo
real onde as interrupes so detectadas por um tratador de interrupes e
passadas por algum outro componente para processamento.
Outros modelos dirigidos a eventos incluem sistemas de planilhas e
de produo.

15

4 DESAFIO 3

4.1.1 Programao para Web II

4.1.1.1

Comparao de frameworks para desenvolvimento web (Java).

O mercado de frameworks Java imenso. H muitas opes boas

disponveis no mercado e muitos pontos a considerar na adoo ou estudo de algum

novo framework.
O Struts com certeza o framework com maior unanimidade no
mercado, em especial por causa de sua verso 1.x. A verso 2.0 no tem tanta fora
mas um dos mais importantes.
Um dos frameworks mais usados hoje o JavaServer Faces - JSF.
Seu grande apelo ser o framework oficial do Java EE para Web, enquanto que
todos os outros so de terceiros. O JSF tem ainda muitas caractersticas diferentes
do Struts ou do VRaptor que vimos nesse curso.
Em especial, o JSF dito um framework component-based,
enquanto que Struts (1 e 2) e VRaptor so ditos request-based ou action-based. A
ideia principal de um framework de componentes abstrair muitos dos conceitos da
Web e do protocolo HTTP provendo uma forma de programao mais parecida com
programao para Desktop. O JSF tem componentes visuais ricos j prontos,
funciona atravs de tratamento de eventos e stateful (ao contrrio da Web "normal"
onde tudo stateless)
Mas o JSF no nico framework baseado em componentes. H
outras opes (menos famosas) como o Google Web Toolkit - GWT ou o Apache
Wicket. Da mesma forma, h outros frameworks request-based alm de Struts e
VRaptor, como o Stripes ou o Spring MVC.
Quando falamos de frameworks voltados para persistncia e bancos
de dados, felizmente, no h tanta dvida quanto no mundo dos frameworks Web. O
Hibernate praticamente unanimidade no mercado Java, principalmente se usado
como implementao da JPA. H outras possibilidades, como o Toplink, o

16

EclipseLink, o OpenJPA, o DataNucleus, o JDO, o iBatis etc. Mas o Hibernate o

mais importante.

4.1.1.2

Relacione

os

custos/benefcios

de

usar

frameworks

no

desenvolvimento Web
Se o framework estiver pronto, os benefcios so claros em termos
de:
Reduo de custos
Reduo de time-to-market
Motivos:
Maximizao de re-uso (anlise, design, cdigo, testes)
Desenvolvedores se concentram em adicionar valor em vez de
reinventar a roda
Menos manuteno
Fatorao de aspectos comuns a vrias aplicaes
Uso de herana permite corrigir todas as aplicaes com a troca
de uma classe-me
Mas cuidado com o "Fragile Base Class Problem" onde a troca da
classe-me quebra as filhas
Estabilizao melhor do cdigo (menos defeitos) devido ao uso
em vrias aplicaes
Outras vantagens
Melhor consistncia e compatibilidade entre aplicaes
Alavancagem do conhecimento de especialistas
Framework oferece uma forma de empacotar o conhecimento de
especialistas sobre domnios de problemas
Assim, no se perde o conhecimento com a sada de especialistas
e o conhecimento pode ser usado/estudado sem a presena do especialista
Resultado: criao de patrimnio estratgico da empresa
(Strategic Asset Building)
Desvantagens
Construir um framework complexo
Re-uso no vem sozinho: deve ser planejado
mais complexo e demora mais fazer uma aplicao tendo que
construir um framework em vez de fazer a aplicao do zero
Benefcios so realizados em longo prazo
Quem pode pensar em longo prazo quando se est competindo
"On Internet time"?
Uma empresa aeroespacial demorou anos para fazer frameworks
e comeou a ter retorno na quarta misso
Precisa modificar o processo de desenvolvimento e criar novos

17

incentivos
Vencer o "Not Made Here Syndrome"
"The most profoundly elegant framework will never be reused
unless the cost of understanding it and using its abstractions is lower than the
programmer's perceived cost of writing them from scratch" (Booch, Dr Dobb's
Journal, 1994)
4.1.1.3

Programao Java Web (plataforma de desenvolvimento)

18

5 CONCLUSO
Responde-se aos objetivos sem, no entanto, justific-los.

19

REFERNCIAS
Sommerville, Ian. Engenharia de Software - 8 Edio.
Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK)
Quinta Edio.