Riscos e Dificuldades no Desenvolvimento de Software

Apresentação em tema: "Riscos e Dificuldades no Desenvolvimento de Software"— Transcrição da apresentação:

1 Riscos e Dificuldades no Desenvolvimento de Software
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. A maioria das “autópsias” a estes projectos de software indicam que os seus problemas teriam sido evitados – ou fortemente reduzidos – se tivesse existido uma preocupação genuína na identificação e redução dos seus factores de maior risco. Frequentemente, aconteceu que durante as primeiras fases de execução destes projectos surgiram “vagas de optimismo” que impediram os responsáveis de compreender alguns sinais transmitidos por factores de elevado risco que mais tarde seriam causadores de desastres O entusiasmo sobre as novas capacidades do software é importante. Mas deve ser moderado com a identificação e redução antecipada dos factores de alto risco, de forma que as pessoas estejam prevenidas e possam centralizar o seu entusiasmo e energia nos aspectos positivos do seu produto. 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”. 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 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 Meses Uma vez que o esforço de desenvolvimento de software é um esforço intelectual, o esforço de comunicação é enorme; consequentemente, o tempo das tarefas de cada pessoa é cada vez mais ocupado pela comunicação. Conclui-se portanto, que aumenta os prazos de execução em vez de os diminuir. BROOKS, Frederick. The Mythical Man-Month

8 Desenvolver Software (3)
% Curva Ideal Curva Real Erros devidos a efeitos secundários Tempo Quantidade Erros Mudança 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 Projectos Contratados
Alteração dos Requisitos do Utilizador 80% Excessiva Pressão sobre Prazos 65% Baixa Qualidade % 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% Os dados de Jones referem-se a vários milhares de Projectos em centenas de empresas em 20 países. Controlo de configuração --> Falta de rigor no controlo de versões do código, das especificações. As alterações ao projecto não são controladas formalmente. JONES, Capers – Assessement and Control of Software Risks

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

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

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 O QBT contém mais de 170 perguntas; algumas delas não eram aplicáveis à realidade portuguesa. Tal como no questionário do SEI, aqui as respostas também eram apenas SIM/NÃO

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]. As respostas foram agrupadas em frequências: Muito frequente Pouco frequente Raro e Muito Perigoso Pouco Perigoso Nada Perigoso Posteriormente apliquei o mecanismo de Boehm para calcular o impacto de cada um dos riscos

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

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. O Hardware não é limitativo e a linguagem de programação é adequada.

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: Seguem-se:
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 As reduções drásticas de Pessoal são consideradas pouco frequentes As alterações de Requisitos do Utilizador são consideradas muito frequentes

23 Conclusões (7) Impacto de Risco Probabilidade Perigo O B L H P E Q S F
20 40 60 80 100 Probabilidade Perigo O B L H P E Q K=7200 S F N D I A J G R U K=5400 C T K=4500 M a) Derrapagens Orçamentais b) Alteração dos requisitos do utilizador c) Excesso de “papelada” d) Pressão excessiva sobre os prazos e) Fricções entre pessoal da empresa cliente e da empresa fornecedora f) Fricções entre Gestores de Projecto e Administradores g) Elevados Custos de Manutenção h) Métricas incorrectas i) Estimativas de Qualidade Incorrectas j) Controlo de Configuração inadequado k) Normas e Políticas de Software inadequadas l) Ferramentas e Metodologias inadequadas m) Ausência de Código reutilizável n) Baixa produtividade o) Baixa qualidade p) Metas não cumpridas q) Má estrutura organizacional r) Fracos investimentos em tecnologia s) Reduções drásticas de pessoal t) Síndroma da bala de prata u) Baixa transferência de Tecnologia K=3600 K=2700 K=1800

24 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!

25 Evoluções possíveis deste trabalho:
Este trabalho apenas pretendeu ser um levantamento patológico. Futuramente poder-se-á: 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.

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.” 1. Convergência entre literatura e dados recolhidos por mim. 2. Factores de risco mais importantes. Robert Charette

27 Alteração de Requisitos
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 Pressão Excessiva sobre os prazos
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 Metas não Cumpridas 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 Derrapagens Orçamentais
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 Baixa Qualidade 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