Tpicos Especiais

em Engenharia de
Software

Padres de Projetos
Gerenciamento de Configurao de Software
Gesto de Riscos

Padres de Projeto
Nos ltimos anos, este tema tem ganhado a

ateno da comunidade de software, que a

cada dia cobrada para projetar solues de
software com melhor qualidade e com o
menor custo. Uma forma sem dvida que
contribui para a obteno na qualidade se
projetos de software so os padres de
projetos.

Padres de Projeto
Atualmente, no se concebe um processo de

desenvolvimento de software srio sem a

utilizao da orientao a objetos, pois esta
permite agregar qualidades importantes aos
sistemas desenvolvidos sob seus paradigmas,
como a extensibilidade e a reusabilidade.

Padres de Projeto
Para criar as melhores solues, preciso:
Processo detalhado para obter uma anlise dos
requisitos, funcionais ou no funcionais,
Desenvolver um projeto que os satisfaa e que
possibilite submet-los a teste, para constatar
eventuais falhas,
Arquitetura flexvel para acomodar futuros
problemas e requisitos sem a necessidade da
realizao do re-projeto.

Padres de Projeto
Projetistas avanados sabem que no devem

resolver cada problema a partir de princpios

elementares ou do zero. Ao invs disso, eles
reutilizam solues que funcionaram no
passado, e os utilizam repetidamente em seus
projetos.

Padres de Projeto
Os padres de projetos tornam mais fcil a

reutilizao de solues e arquiteturas bem

sucedidas para construir softwares orientados
a objetos de forma flexvel e fcil de manter.
Pode reduzir a complexidade do processo de
projetar software.
Possibilita reutilizar e empregar componentes
preexistentes em sistemas futuros.

Padres de Projeto
Padres de projeto so conjuntos de classes e

objetos. Para utiliz-los necessrio se

familiarizar com os padres mais populares e
eficazes utilizados pela engenharia de
software e conhecer o seu contexto e escopo.

Definindo padres de projeto

Pode-se entender como padro de projeto,

como a soluo recorrente para um

problema em um contexto, mesmo que em
projetos e reas distintas.

Definindo padres de
projeto
Contexto diz respeito ao ambiente, e as

circunstncias dentro do qual algo existe.

Problema a questo indefinida, algo que
precisa ser investigado e solucionado.
Soluo refere resposta do problema que
ajuda a soluciona-lo.

Definindo padres de
projeto
Para construir um padro necessrio que a

soluo do problema tenha regularidade,

ou seja, se puder ser utilizada
repetidamente.

Caractersticas de um padro de
projeto
Devem possuir umnome, que descreva o

problema, as solues e consequncias.

Deve relatar de maneira clara a qual
(is)problema(s) ele deve ser aplicado.
Soluodescreve os elementos que compem o
projeto, seus relacionamentos, responsabilidades
e colaboraes.
Deve relatar quais so as
suasconsequnciaspara que possa ser analisada
a soluo alternativa de projetos e para a
compreenso dos benefcios da aplicao.

Caractersticas de um padro de
projeto
Trechos de cdigos especficos no podem

ser considerados um padro de projeto, pois

os padres devem estar a um nvel maior de
abstrao e no limitado a recursos de
programao.
Deve ser exprimido na forma de algoritmo.

Como padres de projeto solucionam problemas

O principal foco do uso dos padres de projeto

no desenvolvimento de software o da
orientao a objetos.
A parte mais difcil do projeto a
decomposio de um sistema em objetos,
pois muitos fatores entram em jogo:
encapsulamento, granularidade, dependncia,
flexibilidade, desempenho, evoluo,
reutilizao e assim por diante.

Como selecionar um padro de projeto

Considerar como solucionam problemas de

projeto.
Examinaro que faz de fato, quais seus
princpios e que tpico ou problema particular
de projeto ele trata (soluciona).
Estudar como padres se relacionam e as
semelhanas existentes entre eles.
Invs de considerar o que pode forar uma
mudana em um projeto, considerar o que voc
quer ser capaz de mudar sem re-projet-lo.

Como usar um padro de projeto

Ler o padro por completo para obter sua

viso geral.
Conhecer, principalmente, a sua
aplicabilidade e consequncias para que ele
realmente solucione o seu problema;
Estudar Estrutura, Participantes e
Colaboraes. Assegurando-se de que
compreendeu as classes e objetos no padro
e como se relacionam entre si;

Como usar um padro de projeto

Escolher os nomes para os participantes do

padro que tenham sentido no contexto da

aplicao;
Definir as classes. Declarar as interfaces,
estabelecer os seus relacionamentos de
herana e definir as variveis de instncia que
representam dados e referncias a objetos.
Identifique as classes existentes na aplicao
que sero afetadas pelo padro e modifiqueas;

Como usar um padro de projeto

Defina os nomes especficos da aplicao

para as operaes no padro. Os nomes em

geral dependem da aplicao. Use as
responsabilidades e colaboraes associadas
com cada operao como guia;
Implemente as operaes para suportar as
responsabilidades e colaboraes presentes
do padro.

Principais padres de projeto

A seguir alguns exemplos de padres de

projetos.

Abstract Factory
Este padro deve ser aplicado quando se

deseja isolar a aplicao da implementao da

classe concreta, a qual seria conhecida apenas
em tempo de execuo ou compilao.
Imagine uma aplicao que fosse
implementada para oferecer suporte a
plataformas e caractersticas distintas. Por
exemplo: Uma viso desktop e uma mvel.

Factory Method
Definir uma interface para criar objetos, mas

deixar que as subclasses decidem que classe

instanciar. O Factory Method, tambm
conhecido como construtor virtual, possibilita
adiar a criao do objeto a subclasses .
Um exemplo de utilizao do padro pode ser
na construo de aplicaes que tenham que
dar suporte a diferentes implementaes de
persistncia com o mnimo de re-trabalho.

Singleton
Garante que um objeto ter apenas uma nica

instncia, isto , que uma classe ir gerar apenas

um objeto e que este estar disponvel de forma
nica para todo o escopo de uma aplicao.
Imagine uma aplicao que exista
simultaneamente num dispositivo mvel (Pocket
PC, Celular, Palm) e num ambiente corporativo e
necessite de um processo de sincronizao entre
as informaes processadas no dispositivo mvel
e na base corporativa.

Adapter
Converte a interface de uma classe por outra

esperada pelos clientes, possibilitando que

classes com interfaces incompatveis
trabalhem em conjunto.

Template Method
Define o esqueleto de um algoritmo em uma

operao, postergando alguns passos para serem

implementados por subclasses, as quais redefinem
certos passos de um algoritmo sem mudar a
estrutura do mesmo. Este padro utilizado para:
Implementar as partes invariantes de um algoritmo

e deixar para subclasses a implementao da parte

variante;
Fatorar o comportamento semelhante entre
subclasses numa superclasse evitando-se assim a
duplicao de cdigo;

Concluindo
O uso de padres de projeto propicia a construo

de aplicaes e ou estruturas de cdigo de forma

flexvel e a documentao de solues
reaproveitveis.
possvel identificar os pontos comuns entre duas
solues diferentes para um mesmo problema.
Desenvolvendo solues que podem ser reutilizadas.
Possibilitam atravs de uma linguagem clara e
concisa, que os conhecimentos sejam transferiados
em um alto nvel de abstrao e assim facilitam o
desenvolvimento e o reaproveitamento de cdigo.

Gerncia de
Configurao de
Software

Os sistemas de software esto em constante

evoluo.
A manuteno do software chega a consumir
75% do custo total do seu ciclo de vida.
20% de todo o esforo de manuteno
usado para consertar erros de implementao
80% so utilizados na adaptao do software
em funo de modificaes em requisitos
funcionais, regras de negcios e na
reengenharia da aplicao.

A Gerncia de Configurao de Software surgiu da

necessidade de controlar estas modificaes, por

meio de mtodos e ferramentas, com o intuito de
maximizar a produtividade e minimizar os erros
cometidos durante a evoluo.
uma disciplina que controla e notifica as inmeras
correes, extenses e adaptaes aplicadas durante
o ciclo de vida do software de forma a assegurar um
processo de desenvolvimento e evoluo sistemtico
e rastrevel, sendo indispensvel quando equipes
manipulam, muitas vezes em conjunto, artefatos
comuns.

O uso dos sistemas de Gerncia de

Configurao fundamental para prover

controle sobre os artefatos produzidos e
modificados por diferentes recursos desde o
planejamento e levantamento de requisitos
at a construo e entrega do produto.

Vamos analisar alguns problemas

identificados quando a Gerncia de

Configurao no utilizada no
desenvolvimento de software.

Espao de trabalho compartilhado. Qual seria

a soluo?

Sob a perspectiva de desenvolvimento, a

Gerncia de Configurao de Software

abrange trs sistemas principais: controle de
modificaes, controle de verses e
controle de gerenciamento de
construo.

Controle de Verses
Permite que os artefatos sob Gerncia de

Configurao evoluam de forma distribuda,

concorrente e disciplinada, evitando perdas ou
sobreposies durante o desenvolvimento e a
manuteno do artefato.
Ferramentas de mercado: CVS, Subversion,
IBM Rational ClearCase e Microsoft Visual
Source Safe.

Controle de Modificaes
Armazena todas as informaes geradas

durante o andamento das solicitaes de

modificao e relata essas informaes aos
participantes interessados e autorizados.
Ferramentas de mercado: Bugzilla, Jira, Trac e
IBM Rational ClearQuest.

Gerenciamento de
Construo
Automatiza o processo de transformao dos

diversos artefatos do software que compem

um projeto em um sistema executvel
propriamente dito.
Este processo ocorre de forma aderente s
normas, procedimentos, polticas e padres
definidos para o projeto. Podemos citar como
exemplos de ferramentas de mercado: Maven
e Apache Ant.

Vantagens da utilizao da GCS

Ganho de produtividade e eficincia;
Diminuio do retrabalho e dos erros;
Aumento da disciplina no processo de desenvolvimento;
Aumento da memria organizacional;
Acesso s informaes qualitativas e quantitativas referentes

ao processo de desenvolvimento. Ex.: medida de esforo em

uma alterao e frequncia de modificaes por componente;
Possibilidade de estabelecer uma trilha de auditoria indicando
por que, quando e por quem um artefato foi alterado;
Auxlio gerncia de projetos;
Garantia de ambiente estvel no qual o produto deve ser
desenvolvido.

Vamos ver alguns conceitos e estratgias de

organizao do trabalho da rea de Gerncia

de Configurao.

Operaes check-in e
check-out
Dentro do espao de trabalho do

desenvolvedor, o sistema de controle de

verses permite que os artefatos sejam
obtidos, por meio de uma operao conhecida
comocheck-out e retornados ao repositrio,
por meio de uma operao conhecida
comocheck-in.

Operaes check-in e
check-out
Artefatos recebem o nome de itens de

configurao.
Para cada item de configurao armazenado,
so anexadas informaes como: datas da
criao ou alterao, comentrios e verses.

Operaes check-in e
check-out

Baselines e Releases
So marcos no versionamento de artefatos.
Asbaselinesrepresentam conjuntos de itens

de configurao formalmente aprovados que

servem de base para as etapas seguintes de
desenvolvimento.
Relieses representam as entregas formais
feitas ao cliente.

Ramos (Branch)
A GCS tambm permite que a

implementao de novas funcionalidades

por uma equipe seja realizada em paralelo,
mas de forma isolada e independente das
modificaes de outros desenvolvedores.
O isolamento obtido com o uso de ramo
(branch).
As linhas de desenvolvimento (codelines)
so designadas para cada projeto e so
compartilhadas por vrios desenvolvedores.

Ramos (Branch)
A primeira linha de desenvolvimento definida

no projeto , por conveno,

nomeadamainline.
O ramo criado no repositrio e representa
uma linha secundria de desenvolvimento que
pode ser unida novamente linha principal
(mainline) por meio da operao de juno
(merge).

Ramos (Branch)

importante ressaltar que o isolamento longo

dificulta a operao de juno, portanto,

necessrio realizar junes periodicamente.

Estratgias de
Organizao
Mesmo com timas ferramentas, a juno

pode ser uma atividade difcil, em funo dos

conflitos que ocorrem.
Deve-se pensar no custo e benefcio,
avaliando duas alternativas:
Usar isolamento com ramos e conciliar os

eventuais conflitos que podem surgir ao fazer a

juno deste ramo com amainline;
No usar isolamento e fazer todas as
modificaes namainline.

Manuteno Catica
Estratgia onde no existe isolamento e,

portanto, a impossibilidadede separar o que

manuteno corretiva da evolutiva.
Namainlineocorre a evoluo e a correo do
software. No existem ramificaes.

Manuteno em Srie
As evolues no software s separadas das

correes no software.
Esta estratgia pode ser usada quando
umareleasedo produto ser entregue para a
homologao. Namainlines ocorre a
evoluo do produto e o ramo fica destinado
s correes.
Antes da juno, umareleasecom as
correes criada.

Gerncia de Configurao e
Desenvolvimento de Software
A Gerncia de Configurao referenciada

em diversas normas, processos,

procedimentos, polticas e padres, como ISO
12207, CMMI e MPS.Br.
O processo de GCS dividido em 5 funes:
identificao da configurao
controle da configurao
acompanhamento da situao da configurao
auditoria da configurao
gerenciamento de liberao e entrega.

Identificao da
Configurao
A funo de identificao da configurao tem

por objetivo:
Seleo de quais artefatos sero itens de

configurao;
Definio de uma nomenclatura, que possibilite
a identificao inequvoca dos itens de
configurao,baselinesereleases
Descrio dos itens, tanto fsica quanto
funcionalmente.

Controle da Configurao
A funo de controle da configurao

designada para controlar e acompanhar a

evoluo dos itens de configurao
selecionados na funo de identificao.
Ferramentas como JIRA, Bugzilla, dentre
outras, apiam, em conjunto com as
ferramentas de controle de verses, as
atividades desta funo.

Acompanhamento da Situao da
Configurao
A funo de acompanhamento da situao da

configurao visa:
Armazenar as informaes geradas pelas

demais funes;
Permitir que essas informaes possam ser
acessadas em funo de necessidades
especficas, por exemplo, para a melhoria do
processo, para a estimativa de custos futuros e
para a gerao de relatrios gerenciais.

Auditoria de
Configurao
A funo de auditoria da configurao ocorre

geralmente quando umareleasedeve ser

criada. Suas atividades compreendem:
Auditoria funcional, que abrange a reviso dos

planos, dados, metodologia e resultados dos

testes, assegurando que areleasecumpre
corretamente o que foi especificado
Auditoria fsica, com o objetivo de certificar que
arelease completa em relao ao que foi
acertado em clusulas contratuais.

Gerenciamento de Liberao e
Entrega
A funo de gerenciamento de liberao e

entrega descreve o processo formal de:

Construo e liberao de umareleasedo

produto;
Entrega, com informaes de como implantar o
software no ambiente final de execuo.

Definio do Processo e
Responsabilidades
Para auxiliar e garantir a execuo das

atividades relacionadas com as funes da

Gerncia de Configurao de Software, uma
organizao pode definir uma equipe de
Gerncia de Configurao.
A Gerncia de Configurao um processo
auxiliar de controle e acompanhamento das
atividades do desenvolvimento de software.

Processo
Desenvolvimento

Processo Homologao

Processo Liberao

Processo Gerenciar
Ramos

Gesto de Riscos

Riscos so eventos que podem ocorrer no

futuro e se concretizados,afetam o projeto

de software.
Os fatores relacionados ao risco so:
o evento ou fato que caracteriza o risco,
a probabilidade de que ele ir ocorrer

(possibilidade),
a perda resultante de sua ocorrncia
(conseqncia).

O risco caracteriza-se pela incerteza (pode ou

no ocorrer) e perda (se o evento ocorrer,

consequncias inesperadas ou perdas iro
ocorrer).
Ele faz parte de qualquer atividade, no
podendo ser eliminado.
No possvel conhecer todos os riscos de
um projeto de software.

Categoria de Riscos
Existem trs categorias principais de riscos:
Risco de projeto,
Risco tcnico,
Risco de negcio.

Riscos de Projetos
Os riscos de projetoameaam o plano do

projeto.
So possibilidades de ocorrerem problemas
com oramento, cronograma, pessoal,
recursos, cliente e requisitos.

Riscos Tcnicos
Ameaam a qualidade do produto, ou seja,

so as possibilidades de ocorrerem problemas

com a especificao, projeto tcnico,
implementao, interfaces, verificaes e
manuteno (ambiguidades na especificao,
incertezas tecnolgicas, obsolescncia
tecnolgica, tecnologia de ponta).

Riscos de Negcios
So aqueles queameaam a viabilidade do

software a ser desenvolvido, ocorrendo quando:

desenvolve-se um excelente produto do qual

ningum precisa (risco de mercado)

desenvolve-se um produto no alinhado com a
estratgia da companhia (risco estratgico)
desenvolve-se um produto que a fora de vendas
no entende como vend-lo ou pode ocorrer
perda do apoio da gerncia de alto nvel da
companhia (risco gerencial) e a reduo de
oramento ou de pessoal (risco oramentrio).

Atividades Associadas a Riscos

As atividades associadas ao risco podem ser

divididas em: gerenciais e tcnicas.

Gerenciais: so responsveis peloplanejamento,
organizao, seleo de pessoas, controle,
direo, garantia da qualidade e gerncia da
configurao. Esta atividade est influencia
diretamente o projeto e ao processo.
Tcnicas englobam a anlise de requisitos,
projeto, cdigo e teste. Esta atividade influencia
tanto o produto quanto o processo.

Gerncia de Riscos
Tem como objetivo ajudar a equipe de

software a entender e gerenciar incertezas

durante o processo de desenvolvimento.
Engloba aes como:
identificao dos eventos de risco,
clculo das probabilidades e dos impactos,
desenvolvimento de respostas para eliminar,
reduzir ou lidar com os eventos, caso eles

ocorram, permitindo um controle do processo

como um todo.

Paradigma de Gerncia de Riscos

um processo contnuo com dois

componentes: avaliar (identificar e analisar) e

controlar (planejar, monitorar e resolver).
Comunicao o conduit atravs do qual as
informaes fluem e o principal obstculo da
gerencia de riscos.

Atividades da Gerncia de Riscos

Identificar:produzir uma lista dos riscos que

podem vir a comprometer o resultado esperado.

Os riscos podem ser genricos (ameaam
qualquer projeto) ou especficos do projeto. Para
identificar os riscos especficos necessrio:
entender a tecnologia, a equipe e o ambiente do

projeto,
examinar o plano do projeto e o escopo do sistema
e responder aseguinte pergunta: que
caractersticas especiais este sistema possui que
podem ameaar o plano do projeto?

Atividades da Gerncia de Riscos

Analisar:Avaliar a probabilidade da perda e a

magnitude da perda, associada com cada

item de risco e com a possvel composio
desses riscos.

Atividades da Gerncia de Riscos

Planejar: definir aes para enderear cada item de

risco, priorizar as aes ecriar um plano integrado de

gerncia de riscos. O planejamento pode ter vrios
objetivos:
Atenuar o risco.
Evitar o risco modificando o projeto do produto ou o

processo de desenvolvimento.
Transferir o risco.
Aceitar o risco e as consequncias, caso o eventoocorra.
Fazerum estudo futuro do risco para obter mais
informaes e compreender melhor as caractersticas do
risco.

Atividades da Gerncia de Riscos

Monitorar:acompanhar o status do risco e das

aes executadas
Resolver:executar as aes planejadas e

reportar os resultados da resoluo do risco.

Atividades da Gerncia de Riscos

Comunicar:prover informaes para e entre

entidades e nveis organizacionais envolvidos

no projeto. Inclui nveis dentro do projeto, da
organizao, da organizao do cliente e a
comunicao entre desenvolvedor, cliente e
usurio.

Identificao dos riscos

A identificao dos riscos pode ser feita

atravs de um Checklist que focaliza

subconjuntos de riscos conhecidos:
Tamanho do produto
Impacto no negcio
Caractersticas do cliente
Definio do processo
Tecnologia a ser utilizada
Tamanho experincia da equipe

Risco Tamanho do Produto

So riscos associados ao tamanho do produto a ser

desenvolvido ou modificado. O risco diretamente

proporcional ao tamanho do produto.
Checklist :
Tamanho estimado em linhas de cdigo ou Pontos de
Funo?
Grau de confiabilidade da estimativa?
Tamanho do produto em nmero de transaes,
programas ou arquivos?
Percentual de desvio do tamanho estimado observado
em projetos anteriores?
Nmero de usurios?
Nmero de mudanas nos requisitos do produto, antes e
depois da entrega?

Risco Impacto no Negcio

Conflito entre as consideraes de negcios e a realidade tcnica.
Checklist :
Efeito do produto sobre o lucro da empresa?
Visibilidade do produto para a gerncia snior?
Nmero de clientes que iro utilizar o produto e consistncia

entre o produto e suas necessidades?

Nmero de produtos com o qual ir interagir?
Sofisticao dos usurios finais?
Quantidade e qualidade da documentao que dever ser
entregue ao cliente?
Restries governamentais quanto construo do produto?
Custos associados a entrega em atraso?
Custos associados a entrega com defeitos?

Risco Caractersticas do Cliente

Um mau cliente provoca fortes impactos negativos na capacidade da

equipe entregar o produto no prazo e dentro do oramento. Clientes

geralmente possuemdiferentes necessidades.
Checklist :
Voc j trabalhou com o cliente no passado?
O cliente possui uma slida idia sobre suas necessidades? Ele reserva

algum tempo para decrev-las?

Os clientes concordam em reservar tempo para participar de sesses de
elicitao de requisitos?
Os clientes esto dispostos a estabelecer vnculos de comunicao com
a equipe de desenvolvimento?
Os clientes concordam em participar de revises?
Os clientes so tecnicamente sofisticados na rea do produto?
Os clientes entendem os processos de software?
Os clientes resistiro a participar de trabalhos tcnicos detalhados?

Risco do Processo

Checklist :

gerncia apoia a definio de polticas formais que enfatizem a

importncia de padres de processos de software?

A organizao desenvolveu um processo de software para ser utilizado?

A equipe concorda com o processo documentado e est disposta a

utiliz-lo?

Processos de software foram utilizados em projetos anteriores?

A organizao promove treinamentos tcnicos e gerenciais em

engenharia de software?

A equipe tcnica e gerencial dispe de padres de engenharia de

software publicados?

Revises tcnicas formais so realizadas regularmente em todas as fases

do processo?

Casos de testes e procedimentos de testes formais so realizados

regularmente?

Risco do Processo

Os resultados das revises tcnicas so documentados,

incluindo erros e recursos utilizados?

Existe alguma garantia que os padres de engenharia de

software esto sendo observados?

A gerncia de configurao est sendo utilizada?

Existe controle mudanas nos requisitos dos usurios?

O trabalho subcontratado est documentado, os requisitos

esto especificados e existe um plano para cada trabalho?

Existem procedimentos definidos para acompanhar e rever os

trabalhos subcontratados?

H tcnicas para facilitar a comunicao entre a equipe e

usurios?

H mtodos especficos de anlise?

Risco do Processo
Existem convenes para cdigo documentadas e so

utilizadas?
Mtodos especficos de teste so utilizados?
Esto sendo utilizadas ferramentas para apoiar o planejamento
e acompanhamento do projeto?
Esto sendo utilizadas ferramentas de gerncia de
configurao?
Esto sendo utilizadas ferramentas para auxiliar na criao de
prottipos?
Esto sendo utilizadas ferramentas de teste?
Esto sendo utilizadas ferramentas para auxiliar na produo
da documentao?
Mtricas de qualidade esto sendo coletadas e analisadas?
Mtricas de produtividade esto sendo coletadas e analisadas?

Riscoda Tecnologia
Atuar no limite da tecnologia excitante e desafiador, mas

oferece muitos riscos. Alm de ser muito difcil prever esses

riscos e mais ainda elaborar um planejamento para mitig-los.
Checklist :
A tecnologia nova para a organizao?
Existem interfaces com hardware/software novo ou no testado?
O software ir fazer interface com sistemas de bancos de dados

no testados na rea do software?

Os requisitos demandam interfaces com usurios
especializadas?
Os requisitos exigem a construo de componentes que nunca
foram desenvolvidos pela organizao?
Os requisitos exigem novos mtodos de anlise, projeto e teste?

Risco tamanho e experincia da equipe

Checklist :
Boas pessoas esto disponveis?
As pessoas possuem o perfil adequado?
A equipe pode comprometer-se durante toda a
durao do projeto?
Parte da equipe est atuando em part time?
A equipe possui expectativas adequadas sobre
o projeto?
A equipe recebeu o treinamento necessrio?
A rotatividade de pessoal dever ser baixa?

Anlise de Riscos
Tem como objetivo avaliar o efeito dos riscos

potencias. Para isso, envolve responder a

perguntas do seguinte tipo:
Isto um risco ou no?
Qual a probabilidade de ocorrncia?
O quanto srio este risco?
Quais so as consequncias?

Projeo de Risco
Permite estabelecer uma escala que reflita a

probabilidade percebida do risco alm de

delinear sua consequncia, estimando assim,
o impacto do risco no projeto e no produto.

Plano para Mitigar os

Riscos
Define aes para evitar ou reduzir a probabilidade de

ocorrncia ou reduzir as consequncias dos riscos

Exemplos para mitigar risco de rotatividade de pessoal:
Reunio com a equipe para identificar causas de

rotatividade elevada.
Reduzir as causas que esto sob o controle da equipe antes
do projeto comear.
Aps o incio do projeto, assumir que a rotatividade ser
elevada e definir procedimentos para adotar quando as
pessoas deixarem o projeto.
Organizar a equipe de tal maneira que informaes sobre
atividades de desenvolvimento so amplamente conhecidas.
Elaborar uma documentao adequada.

Monitorar os Riscos
Aps o incio do projeto, o gerente do projeto

monitora fatores que podem indicar se a

probabilidade do risco est aumentando ou
diminuindo.
Exemplos:
Atitudes da equipe em funo do aumento das

presses do projeto
Relaes interpessoais
Problemas com remunerao
Aumenta da oferta de trabalho

Plano de Contingncia
Define aes assumindo que os esforos para

mitigar o risco no surtiram efeito e que ele

tornou-se realidade.

Estgios em Gerncia de
Riscos
Problemtico:
Falta de comunicao causando falta de

coordenao
Pessoas esto muito ocupadas resolvendo
problemas que no pensam no futuro
Riscos no so endereados at que se tornem
problemas
Notcias sobre riscos so encaradas como m
notcia e as pessoas que se preocupam com
riscos so hostilizadas
Gerncia de crise utilizada

Estgios em Gerncia de
Riscos
Atenuando:
Mudana da gerncia de crise para gerncia de riscos
Introduo dos conceitos de risco
Pessoas passam a se preocupar com riscos mas no os

endeream de forma sistemtica

Como as pessoas tm pouco conhecimento e
experincia, sentem-se inseguras em como reportar os
riscos
Gerentes utilizam a gerncia de riscos para reduzir a
probabilidade e consequncia de riscos crticos elaboram planos de contingncia
nfase nas fases iniciais do desenvolvimento

Estgios em Gerncia de
Riscos
Prevenindo:
A gerncia de riscos deixa de ser vista como uma

atividade de gerncia e passa a ser vista como

umaatividade da equipe
Transio da abordagem evitar os sintomas dos riscos
para identificar e eliminar as razes das causas de riscos
Envolvimento da equipe e eventualmente dos clientes,
com o gerente entendendo que a gerncia de riscos um
processo dinmico e que no pode ser tratado de forma
isolado
Ponto de inflexo entre abordagem reativa e proativa
Pessoas j possuem experincia em identificar riscos, mas
sentem-se inseguras em quantific-los

Estgios em Gerncia de
Riscos
Antecipando:
Transio da gerncia subjetiva para a gerncia

quantitativa do risco
Utilizao de mtricas para antecipar falhas e
prever eventos futuros
Habilidade para aprender, adaptar e antecipar
mudanas
Equipe e clientes utilizam a gerncia de riscos
para quantificar riscos com razovel acurcia e
para focar nas reais prioridades

Estgios em Gerncia de
Riscos
Criando Oportunidades:
Viso positiva da gerncia de riscos utilizada para inovar e criar um novo
futuro
Mudana de paradigma para riscos percebidos como perspectiva para
economizar dinheiro e fazer melhor do que o planejado
Risco, assim como qualidade, passa a ser responsabilidade de todos
Risco um processo tico e contnuo, identificado e resolvido em um
ambiente aberto e sem ameaas
Atitudes profissionais favorecem uma comunicao aberta e
contribuies individuais
Admite-se que existem coisas que no sabemos e concorda-se com a sua
existncia, utilizando cenrios de melhor e pior caso
Pessoas entendem que existe um custo de oportunidade associado a
cada escolha e que a busca desse equilbrio melhora o processo de
deciso
Risco no mais visto como algo negativo, mascomo oportunidades.

Atividade
Imagine um contexto em que uma equipe de desenvolvimento de

software est com problemas em relao as frequentes alteraes de

escopo de um projeto que j extrapolou, demasiadamente, o
cronograma inicial, impactando em custos e o descrdito do projeto
para os envolvidos, principalmente, usurios chave. Voc foi
contratado como gestor deste projeto, j que para a alta gesto da
empresa o problema da no entrega no prazo foi a falta de gesto.
Sabemos que h outros problemas que impactam do desenvolvimento.
Imagine os problemas que causaram este cenrio (seja criativo).
Descreva, detalhadamente o que voc faria para convencer a alta
gesto da credibilidade do projeto, gerenciar as demandas de forma
clara e seguir a risca um novo cronograma para entrega.
Trabalhe com artefatos que comprovem a evoluo do projeto e o
envolvimento dos interessados (que atualmente esto
desinteressados).