Orientador: • Prof. Luís Valadares Tavares
Marco António Oliveira
Riscos e Dificuldades no Riscos e Dificuldades no Desenvolvimento de SoftwareDesenvolvimento de Software
Mestrado em Engenharia e Gestão de Tecnologia
Pertinência do Tema (1)Pertinência do Tema (1)
"Em praticamente todas as fases dos mais bem sucedidos projectos de software, existem muita coisas que são extremamente importantes, mas que são desconhecidas”
Jim McCarthy, Program Manager, Microsoft Visual C++
Pertinência do Tema (2)Pertinência do Tema (2)
A taxa de insucesso em projectos de software situa-se entre os 30 e os 40 %;
Em 90 % dos projectos, o orçamento é ultrapassado;
40 a 50 % do dinheiro gasto em software vai para correcções e alterações;
35 % das empresas americanas tiveram pelo menos um projecto desastroso.
Contracting for Computer Software Development, GAO Report, 1990
Pertinência do Tema (3)Pertinência do Tema (3)
A maioria das “autópsias” a projectos desastrosos software indicam que os seus problemas teriam sido evitados/reduzidos se tivesse existido uma preocupação genuína na identificação e redução dos seus factores de maior risco.
O entusiasmo sobre as novas capacidades do software é importante mas não deve ser exagerado.
A atitude em relação ao risco no desenvolvimento de software deve ser semelhante à medicina preventiva e segue o ditado popular “mais vale prevenir que remediar”.
Objectivos do EstudoObjectivos do Estudo
Este trabalho pretendeu responder a duas questões:
Que características apresentam as dificuldades que surgem no desenvolvimento de software ?
Quais os riscos mais comuns e os riscos mais perigosos em projectos de software desenvolvidos no nosso país?
Desenvolver Software (1)Desenvolver Software (1)
É extremamente difícil entregar software de boa qualidade dentro dos prazos previstos.
Na maioria das empresas, o trabalho e o investimento centram-se em torno de dois aspectos fundamentais: actividade intelectual e esforços mecânicos.
Sendo o software um produto não tangível, mas apenas o resultado de um esforço intelectual, a gestão do mesmo apresenta características próprias na medida em que os esforços mecânicos são mínimos.
Muitas das causas das aflições que surgem no desenvolvimento de software têm origem numa série de mitos que propagam confusões e mal-entendidos.
Desenvolver Software (2)Desenvolver Software (2)
Desenvolver software não é um processo mecanicista; adicionar novas pessoas a um projecto que já está atrasado, acaba por o atrasar ainda mais.
Pessoas
Me
se
s
BROOKS, Frederick. The Mythical Man-Month. 1995.
Desenvolver Software (3)Desenvolver Software (3)
Tempo
Qua
ntid
ade
Err
os
Curva RealMudança
Erros devidos a efeitos secundários
Curva Ideal
PRESSMAN, Roger. Software Engineering. McGraw-Hill, 1997, New York.
20 - 50 %
O que é o Risco?O que é o Risco?
Os dicionários definem a palavra “risco” como “exposição à possibilidade de perdas ou danos” ou apenas “possibilidade de perda”.
Exposição ao risco (também designado como “impacto do risco”). Assim, a exposição ao risco pode ser definida por
ER = P(RI) x D(RI)
em que ER é a exposição ao risco, P(RI) é a probabilidade de obter resultados insatisfatórios e D(RI) são os danos causados por resultados insatisfatórios.
Os Riscos mais ComunsOs Riscos mais Comuns
Projectos Não Contratados Alteração dos Requisitos do Utilizador 80% Excessiva Pressão sobre Prazos 65% Baixa Qualidade 60% Derrapagem de Custos 55% Controlo de Configuração inadequado 50%
Projectos Contratados Elevados Custos de Manutenção 60% Atritos entre empregados do cliente
e da empresa contratada 50% Alteração dos Requisitos do Utilizador 45% Critérios de Aceitação não previstos 30% Propriedade legal do software e dos produtos 20%
JONES, Capers – Assessement and Control of Software Risks. 1994.
Os Riscos mais PerigososOs Riscos mais Perigosos
Métricas incorrectas Medições incorrectas Excessiva pressão sobre os prazos Práticas incorrectas de Gestão Estimativas incorrectas de Custos Síndroma da Bala de Prata Alteração dos Requisitos do Utilizador Baixa Qualidade Baixa Produtividade Projectos Cancelados
JONES, Capers – Assessement and Control of Software Risks. 1994.
Etapas do EstudoEtapas do Estudo
Adaptar e aplicar o questionário do SEI-CMU a um modelo proposto
Adaptar o mecanismo de avaliação de risco
do SEI-CMU (pag. 62)
Identificar os riscos mais comuns Identificar os riscos mais perigosos Quantificar os resultados e aplicar o
mecanismo de Boehm para calcular o impacto do risco (pag. 64)
O Modelo de Risco propostoO Modelo de Risco proposto
RISCO
• Requisitos e Especificações• Codificação e Instalação• Testes e Integração
• Especificações• Hardware• Software
PROCESSO
PRODUTO
GESTÃO
RECURSOS
• Experiência do Chefe de Projecto• Ambiente da Equipa
• Escassez de Competências• Prazos• Restrições Contratuais• Articulação Cliente-Fornecedor
Questionário (1)Questionário (1)
O questionário foi distribuído a quase uma centena de chefes/gestores de projecto.
Na 1ª parte (baseada num questionário de Avaliação de Risco do SEI-CMU) é pedido para identificar um conjunto de dificuldades num projecto específico.
Aqui as dificuldades foram agrupadas em 4 categorias distintas:
Definição de Produto a Desenvolver Processo de Desenvolvimento Métodos de Gestão Recursos
Questionário (2)Questionário (2)
Na segunda parte era apresentada uma lista com mais de duas dezenas de riscos possíveis no desenvolvimento de software.
Pedia-se ao entrevistado que considerasse toda a sua experiência profissional e identifique nessa lista aqueles que considera ser os riscos mais comuns e aqueles que considera ser os riscos mais perigosos.
Os riscos constantes dessa lista foram seleccionados de um trabalho de Capers Jones [1994].
O impacto do riscoO impacto do risco
Ao quantificar a frequência e o perigo de cada risco, estamos em condições de calcular o impacto de cada risco.
Probabilidade
MuitoFrequente
Ocasional Raro
Muito Perigoso
Perigo Normal
Pe
rig
o
Nada Perigoso
Elevado
Médio
Baixo
Conclusões (1)Conclusões (1)
DIFICULDADES NA DEFINIÇÃO DO PRODUTODIFICULDADES NA DEFINIÇÃO DO PRODUTO
Na maioria dos projectos em causa as especificações do software a desenvolver não estavam completas, eram pouco claras ou requeriam interpretação;
Em 50% dos projectos as especificações baseavam-se em suposições optimistas ou pouco realistas;
Mais de metade dos projectos incluíam alguma coisa em que a empresa não tinha experiência.
PROCESSO DE DESENVOLVIMENTOPROCESSO DE DESENVOLVIMENTO
As alterações das especificações eram controladas;
Existiam planos formais para quase todas as actividades do projecto;
Em 30% dos projectos não havia planos formais para Testes e Instalação do Software;
O processo de desenvolvimento é bem compreendido pelos membros da equipa.
Conclusões (2)Conclusões (2)
MÉTODOS DE GESTÃOMÉTODOS DE GESTÃO
A maioria dos chefes de projecto consideram-se experientes;
Quase sempre existia reconhecimento pelo trabalho realizado pelos membros da equipa;
Na maioria dos projectos havia um bom espírito de equipa;
Apenas metade dos chefes de projecto envolviam os membros da equipa nas tomadas de decisão.
Conclusões (3)Conclusões (3)
RECURSOSRECURSOS
A escassez de competências verifica-se primeiramente em áreas como Garantia de Qualidade e Análise de Performance (70%).
Áreas como Segurança, Desenho e Metodologias também registam carência de competências (55%).
Em 65% dos casos, o prazo não é o adequado para a conclusão dos trabalhos, e o contrato Cliente-Fornecedor provoca algumas restrições ao projecto.
Conclusões (4)Conclusões (4)
Conclusões (5)Conclusões (5)
Os riscos considerados mais comunsmais comuns são: Alteração de Requisitos do Utilizador Pressão excessiva sobre os prazos Metas não Cumpridas Derrapagens Orçamentais
Seguem-se: Estimativas e Métricas incorrectas Má Estrutura Organizacional Elevados Custos de Manutenção Baixa Qualidade
Os riscos considerados mais perigososmais perigosos são: Baixa qualidade Alteração de Requisitos do utilizador Ferramentas e Metodologias Inadequadas Métricas Incorrectas Fricções entre Pessoal empresa Cliente e
Fornecedor Metas Não cumpridas Má Estrutura Organizacional
Algumas Conclusões (6)Algumas Conclusões (6)
F
Conclusões (7)Conclusões (7)
I
H
O
G
E
U
0
0
20
40
60
80
20 40 60 80 100
Probabilidade
Pe
rig
o
K=1800
K=2700
K=3600
K=4500
K=5400
B
D
P
AQ
L
N
M
C
RJ
S
T
Impacto de Risco
K=7200
Para lá das Conclusões...Para lá das Conclusões...
A maior parte dos riscos envolvidos não são de natureza tecnológica mas sim de natureza relacionamento humana.
Para os gestores é mais fácil lidar com tecnologia do que com questões humanas.
Mais do que o hardware ou o software, há que centrar as atenções no peopleware!
Evoluções possíveis deste trabalho:Evoluções possíveis deste trabalho:
Alargar o leque de entrevistados para poder fazer uma classificação do tipo de projectos em causa;
Estudar a relação entre os diferentes riscos;
Analisar as terapias propostas para cada um dos riscos.
Este trabalho apenas pretendeu ser um levantamento patológico. Futuramente poder-se-á:
“Os riscos da tecnologia apenas são controláveis se compreendermos as suas limitações e tivermos expectativas razoáveis sobre a sua utilização. Um sucesso no futuro obtém-se antevendo um insucesso no presente.”
Robert Charette
Risco e IncertezaRisco e Incerteza
Alteração deRequisitos
• Prazos não Cumpridos• Derrapagens Orçamentais• Atrasos na Comercialização• Pressão Excessiva sobre Prazos• Moral Fraco da Equipa
• Inexperiência de Utilizadores• Inexperiência de Gestores• Metodologias Inadequadas• Estimativas Inadequadas de Custos
Fricção com UtilizadoresFricção com Gestores
Pressão Excessiva sobre os prazos
• Moral Fraco da Equipa• Elevada Rotatividade de Pessoal• Projectos Cancelados• Derrapagens Orçamentais• Baixa Qualidade
• Alteração de requisitos dos Utilizadores• Estimativas inadequadas• Medições Incorrectas• Planeamento Incorrecto• Práticas de Gestão Incorrectas
Metas não Cumpridas
• Fricção com Utilizadores• Fricção com Gestão Sénior• Moral Fraco da Equipa• Projectos Cancelados• Derrapagens Orçamentais• Baixa Qualidade
• Inexperiência dos Gestores• Inexperiência do Pessoal• Alteração de requisitos dos Utilizadores• Estimativas inadequadas• Medições Incorrectas• Planeamento Incorrecto
Derrapagens Orçamentais
• Fricção com Utilizadores• Fricção com Gestão Sénior• Atritos entre Pessoal• Moral Fraco da Equipa
• Práticas Incorrectas de Gestão• Pessoal Inexperiente• Alteração de Requisitos do Utilizador• Estimativas Incorrectas• Planeamento Inadequado• Pressão Excessiva sobre os Prazos
Projectos CanceladosPrazos Demasiado LongosMetas Não cumpridas
Baixa Qualidade
• Fricção com Utilizadores• Baixa satisfação dos Utilizadores• Fricção com Gestão Sénior• Elevados Custos de Manutenção• Moral Fraco da Equipa
• Inexperiência dos Gestores• Pessoal Inexperiente• Alteração de Requisitos do Utilizador• Estimativas Incorrectas• Planeamento Incorrecto• Correcção deficiente de Erros• Pressão Excessiva sobre os Prazos
Baixa ProdutividadePrazos Demasiados Longos
Top Related