Gestão de Projecto

 Actividades de gestão
 Planeamento de projecto
 Organização da actividades
 Escalonamento do projecto
 Gestão de risco

João Araújo – Engenharia de Software

 Gestão de Projecto

 ES profissional está sujeita a restrições de orçamento e scheduling

 Falhas ocorridas em vários sistemas estavam relacionadas a
problemas de gestão de SW:
• Entrega atrasada, não confiáveis, performance pobre, custos altos
 Gestores de SW são responsáveis pelo planeamento e escalonamento
do desenvolvimento do projecto
 Diferença entre ES e outras engenharias
• O producto é intangível
• Não há um processo padrão
• Projectos de SW de grande porte são frequentemente one-off

João Araújo – Engenharia de Software

 Actividades de Gestão
 Actividades
• Preparação de proposta
• objectivos e como vai ser conduzido
• Cálculo do orçamento do projecto
• recursos necessários
• Planeamento e escalonamento do projecto
• milestones e deliverables
• Acompanhamento e revisões do projecto
• formal / informal
• Selecção e avaliação de pessoal
• orçamento, disponibilidade, treino
• Preparação de relatórios e apresentações
• documentos concisos e coerentes

João Araújo – Engenharia de Software

 Pessoal
 Pode não ser possível seleccionar as pessoas
ideais para trabalhar no projecto
• O orçamento pode não permitir a utilização de profissionais
altamente especializados
• Profissionais com a experiência apropriada pode não estar
disponível
• Uma organizacão pode decidir por oferecer cursos aos seus
empregados
 Os gestores tem que trabalhar dentro destas
restrições especialmente quando há uma falta de
profissionais de TI a nível mundial

João Araújo – Engenharia de Software

 Planeamento de Projecto

 O gestor deve antecipar problemas e propor soluções

 Planeamento de projecto é uma atcividade que consome considerável
tempo de gestão
 Tipos de planeamento:
• qualidade: procedimentos e padrões
• validação: abordagem, recursos e escalonamento
• gestão de configuração: procedimentos e estruturas de GC
• manutenção: requisitos, custos e esforço
• desenvolvimento de staff: cursos

João Araújo – Engenharia de Software

 Planeamento de Projecto
• Estabelecer as restrições do projecto
• Inicializar os parâmetros do projecto
• Definir milestones e deliverables
• while projecto não for completado ou cancelado do
• faça o escalonamento do projecto
• inicie actividades de acordo com o projecto
• aguarde
• revise o progresso do projecto
• revise estimativas dos parâmetros do projecto
• actualize o escalonamento do projecto
• renegocie restrições do projecto e deliverables
• if surgirem problemas then
 iniciar revisões técnicas
• end if
• end do

João Araújo – Engenharia de Software

 Planeamento de Projecto

 Estrutura do documento
• Introdução
• Organização do projecto
• Análise de risco
• Requisitos de recursos de HW e SW
• Work breakdown - partição do projecto em actividades e identificação de
milestones e deliverables
• Escalonamento do projecto
• Mecanismos de acompanhamento e relatórios

João Araújo – Engenharia de Software

 Organização das Actividades

 Milestones: final de uma actividade

 Deliverable: um resultado do fim de uma fase de projecto entregue
ao cliente
 Milestones no processo de requisitos

Actividades

Estudo de Análise de Desenvolv. Estudo de Especificação

factibilidade requisitos de protótipo desenho de requisitos

Relatório de Definição Relatório de Desenho Especificação

factibilidade de requisitos avaliação arquitectural de requisitos

João Araújo – Engenharia de Software

Milestones
 Escalonamento do projecto
 Particionar o projecto em tarefas e estimar o
tempo e recursos necessários p/ completar cada
tarefa
 Organizar tarefas concorrentemente para fazer o
melhor uso da força de trabalho
 Minimizar as dependências entre as tarefas p/
evitar atrasos
 Depende da intuição e experência dos gestores

João Araújo – Engenharia de Software

 O processo de escalonamento

Identificar Identificar Estimar Alocar Criar

actividades dependências recursos pessoas diagramas

Requisitos de SW

João Araújo – Engenharia de Software

 Problemas de escalonamento
 Estimar o custo de desenvolvimento de uma
solução é duro
 Productividade não é proporcional ao nº de
pessoas trabalhando numa tarefa
 Adicionar pessoas a um projecto atrasado torna-o
mais atrasado por causa dos problemas de
comunicação
 O inesperado sempre acontece, portanto sempre
considere contingência no planeamento

João Araújo – Engenharia de Software

 Dependências e durações de tarefas
T
a
r
e
fa D
u
r
a
çã
o
(
di
a
s) D
e
p
e
nde
n
ci
a
s
T
1 8
T
2 1
5
T
3 1
5 T
1(
M1
)
T
4 1
0
T
5 1
0 T
2
,
T4(
M2
)
T
6 5 T
1
,
T2(
M3
)
T
7 2
0 T
1(
M1
)
T
8 2
5 T
4(
M5
)
T
9 1
5 T
3
,
T6(
M4
)
T
1
0 1
5 T
5
,
T7(
M7
)
T
1
1 7 T
9(
M6
)
T
1
2 1
0 T
1
1(
M8)

João Araújo – Engenharia de Software

 Rede de Actividades
14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 10 days 11/8/99 5/9/99

10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99
João Araújo – Engenharia de Software
 Diagrama de barras
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish

João Araújo – Engenharia de Software

 Alocação de pessoas a tarefas
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10

Jim T7

Mary T5

João Araújo – Engenharia de Software

 Gestão de risco
 A gestão de risco preocupa-se em identificar
riscos e planear p/ minimizar seus efeitos num
projecto
 Um risco é a probabilidade de que alguma
circunstância adversa ocorrerá
• Riscos de projecto afectam o escalonamento ou recursos
• Riscos de produto afectam a qualidade do software a ser
desenvolvido
• Riscos de negócio afectam a organização na procura ou no
desenvolvimento do software

João Araújo – Engenharia de Software

 Riscos de Software
Risco Tipo Descrição
Mudança de pessoal Projecto Pessoal experiente deixa o projecto
antes que esteja terminado.
Mudança na gestão Projecto Há uma mudança na gestão da
organização que implica em
prioridades diferentes.
Falta de hardware Projecto Hardware essencial para o projecto
não será entregue no prazo certo
Mudança de requisitos Projecto e Haverá um número maior de
produto mudanças nos requisitos do que o
que foi previsto
Atrasos na especificação Projecto e Especificações de interfaces
produto importantes não estão prontas nos
prazos
Tamanho subestimado Projecto e O tamanho do sistema foi
produto subestimado
Desempenho fraco de Produto Ferramentas CASE não tem o
ferrameta CASE desempenho esperado
Mudança na tecnologia Negócio A tecnologia utilizada p/ construir o
sistema é superada por uma nova
tecnologia
Competição com outro Negócio Um outro produto (concorrente) é
produto lançado no mercado antes que o
sistema seja completado

João Araújo – Engenharia de Software

 O processo de gestão de risco
 Identificação do risco
• Identificar riscos de projecto, de produto e de negócio
 Analisar os riscos
• Avaliar a probabilidade e as consequências destes riscos
 Planeamento de riscos
• estabelecer planos para evitar ou minimizar os efeitos dos riscos
 Monitoração de riscos
• Monitorar os riscos através do projecto

João Araújo – Engenharia de Software

 O processo de gestão de risco

Identificação Análise Planeamento Monitoração

de riscos de riscos de riscos de riscos

Lista de riscos Planos de Avaliação

Lista de riscos
em ordem contingência e de riscos
em potencial
de prioridade p/ evitar riscos

João Araújo – Engenharia de Software

 Identificação de risco
 Riscos de tecnologia
 Riscos de pessoal
 Riscos organizacionais
 Riscos de requisitos
 Riscos de estimativa

João Araújo – Engenharia de Software

 Riscos e tipos de riscos
Tipo de risco Riscos possíveis

Tecnologia As bases de dados utilizadas no sistema não podem processar tantas

transações por segundo como era esperado
Os componentes de SW que deviam ser reutilizados contém defeitos que
limitam sua funcionalidade

Pessoal É impossível recrutar pessoal com as habilidades necessárias

O pessoal chave não está disponível em fases críticas
Treino necessário p/ o pessoal não está disponível

Organizacional Problemas financeiros forçam a reduções no orçamento do projecto

Ferramentas O código gerado por ferramentas CASE tools é ineficiente.

Ferramentas CASE não podem ser integradas

Requisitos Mudanças nos requisitos que acarretam um considerável re-desenho são

propostas.

Estimativa O tempo necessário p/ desenvolver o SW é subestimado

O tamanho do SW é subestimado

João Araújo – Engenharia de Software

 Análise de riscos
 Avaliar a probabilidade e a seriedade do risco
 A probabilidade pode ser muito baixa, baixa, moderada,
alta ou muito alta
 Os efeitos do risco podem ser catastróficos, sérios,
toleráveis ou insignificantes
 Exemplos:
• O pessoal chave está doente em fases críticas do prohecto
• Probabilidade: Moderada
• Efeito: Sério
• É impossível recrutar pessoal qualificado
• Probabilidade: Alta
• Efeito: Catastrófico

João Araújo – Engenharia de Software

 Planeamento de riscos
 Considerar cada risco e desenvolver uma estratégia p/ gerir este risco
• Estratégias p/ evitar o risco
• A probabilidade p/ o surgimento do risco será reduzida
• Estratégias p/ minimizar o risco
• O impacto do risco no projecto ou produto será reduzida
 Planos de contingência
• Se o risco surgir, planos de contingência devem ser utilizados
 Exemplos:
• Problemas de recrutamento: alertar o cliente das dificuldades e das
possibilidades de atrasos, investigar componentes que possam ser
comprados
• Doenças: reorganizar o time para que haja mais sobreposição de
trabalho

João Araújo – Engenharia de Software

 Monitoração do risco
 Avaliar cada risco identificado regularmente p/
verificar se ele está se tornando mais ou menos
provável
 Avaliar se os efeitos do risco mudaram
 Cada risco chave deve ser discutido nas reuniões

João Araújo – Engenharia de Software

 Factores de risco

• Indicadores de risco de acordo com o tipo de risco

• Tecnologia: Atrasos na entrega do HW ou no suporte do SW

• Pessoal: Desânimo, relacionamentos pobres entre os membros da equipa

• Organização: Fofoca organizacional, falta de acção da gestão senior

• Ferramentas: Reclamações sobre as ferramentas CASE utilizadas

• Requisitos: Muitos pedidos de mudanças nos requisitos

• Estimativa: Falha em cumprir o escalonamento

João Araújo – Engenharia de Software