Riscos e Dificuldades no Desenvolvimento de Software

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

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

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

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

5. Objectivos 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?

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

7. Meses Pessoas 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. BROOKS, Frederick. The Mythical Man-Month. 1995.

8. 20 - 50 % Erros devidos a efeitos secundários Quantidade Erros Curva Real Mudança Curva Ideal Tempo Desenvolver Software (3) PRESSMAN, Roger. Software Engineering. McGraw-Hill, 1997, New York.

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

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

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

12. Etapas 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)

13. Especificações • Hardware • Software PRODUTO • Requisitos e Especificações • Codificação e Instalação • Testes e Integração PROCESSO • Experiência do Chefe de Projecto • Ambiente da Equipa GESTÃO • Escassez de Competências • Prazos • Restrições Contratuais • Articulação Cliente-Fornecedor RECURSOS O Modelo de Risco proposto RISCO

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

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

16. Probabilidade Muito Frequente Ocasional Raro Muito Perigoso Elevado Perigo Normal Médio Perigo Baixo Nada Perigoso O 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.

17. Conclusões (1) DIFICULDADES 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.

18. Conclusões (2) PROCESSO 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.

19. Conclusões (3) MÉ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.

20. Conclusões (4) RECURSOS • 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.

21. Conclusões (5) Os riscos considerados mais 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

22. Algumas Conclusões (6) Os riscos considerados mais 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

23. O B L 80 H P E Q F D S N I A J G R 60 U C T M Perigo 40 20 20 40 60 80 100 Probabilidade Conclusões (7) Impacto de Risco K=7200 K=5400 K=4500 K=3600 K=2700 K=1800 0 0

24. Mais do que o hardware ou o software, há que centrar as atenções no peopleware! 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.

25. 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-á:

26. Risco e Incerteza “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

27. Inexperiência de Utilizadores • Inexperiência de Gestores • Metodologias Inadequadas • Estimativas Inadequadas de Custos Fricção com Utilizadores Fricção com Gestores Alteração de Requisitos • Prazos não Cumpridos • Derrapagens Orçamentais • Atrasos na Comercialização • Pressão Excessiva sobre Prazos • Moral Fraco da Equipa

28. Alteração de requisitos dos Utilizadores • Estimativas inadequadas • Medições Incorrectas • Planeamento Incorrecto • Práticas de Gestão Incorrectas Pressão Excessiva sobre os prazos • Moral Fraco da Equipa • Elevada Rotatividade de Pessoal • Projectos Cancelados • Derrapagens Orçamentais • Baixa Qualidade

29. Inexperiência dos Gestores • Inexperiência do Pessoal • Alteração de requisitos dos Utilizadores • Estimativas inadequadas • Medições Incorrectas • Planeamento Incorrecto 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

30. 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 Cancelados Prazos Demasiado Longos Metas Não cumpridas Derrapagens Orçamentais • Fricção com Utilizadores • Fricção com Gestão Sénior • Atritos entre Pessoal • Moral Fraco da Equipa

31. 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 Produtividade Prazos Demasiados Longos 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