Orientador: Prof. Luís Valadares Tavares Marco António Oliveira Riscos e Dificuldades no Desenvolvimento de Software Mestrado em Engenharia e Gestão de.

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++


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


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 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.


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.


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.


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.



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


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

Orientador: Prof. Luís Valadares Tavares Marco António Oliveira Riscos e Dificuldades no Desenvolvimento de Software Mestrado em Engenharia e Gestão de.

Documents