Fatos e falácias da engenharia de software

Aleksandr Shitik

Escrevo meus próprios posts e livros, e faço resenhas de filmes e livros. Especialista em cosmologia e astronomia, TI, produtividade e planejamento.

Robert L. Glass

Gêneros: Programação

Ano de publicação: 2008

Ano de leitura: 2020

Minha avaliação: Máxima

Número de leituras: 1

Total de páginas: 233

Resumo (páginas): 0

Idioma original da publicação: Inglês

Traduções para outros idiomas: Russo, Chinês

Informações gerais

Livro de 2008, composto por 55 fatos e 10 equívocos sobre desenvolvedores e programação em geral. Todos os materiais estão divididos em grupos específicos, como: gerenciamento, desenvolvimento e outros.

É importante mencionar desde o início que quase todos os temas e questões abordados pelo autor são bastante controversos, e diferentes leitores podem ter opiniões bastante divergentes. Para economizar tempo e espaço, não pretendo descrever minha opinião ou visão sobre cada ponto. Aqui, apenas listarei brevemente todos os fatos e equívocos, e no final farei uma avaliação geral do livro. Cada fato ou equívoco é apresentado com o tamanho aproximado de um artigo médio, portanto, se estiver interessado, você pode não ler o livro todo, mas escolher temas específicos. Antes de listar todos os fatos e equívocos, também destaco que o autor segue uma estrutura clara na apresentação do material:

• Primeiro, ele discute o fato ou equívoco em si.
• Depois, descreve os debates e controvérsias em torno dele.
• Por fim, apresenta as fontes de informação relacionadas ao tema.

Fatos sobre programação

Fator humano

1. O fator mais importante no desenvolvimento de software não são os métodos e ferramentas usados pelos programadores, mas os próprios programadores.
2. Segundo pesquisas sobre diferenças individuais, os melhores programadores superam os piores em até 28 vezes. Considerando que a remuneração nunca é proporcional, o melhor programador é o investimento mais valioso na indústria de software.
3. Se um projeto está atrasado, adicionar mais pessoal só o atrasará ainda mais.
4. As condições de trabalho têm grande influência na produtividade e na qualidade do resultado.
5. O barulho publicitário em torno de ferramentas e métodos é uma praga na indústria de software. A maioria das melhorias traz ganhos de produtividade e qualidade de apenas 5–35%. No entanto, muitas foram anunciadas como proporcionando vantagens "de uma ordem de magnitude".
6. O aprendizado de um novo método ou ferramenta inicialmente reduz a produtividade dos programadores e a qualidade do produto. O benefício só vem após a curva de aprendizado. Portanto, só faz sentido adotar novas abordagens se a) houver valor real e b) houver paciência para esperar pelos resultados.
7. Os desenvolvedores falam muito sobre ferramentas. Experimentam várias, adquirem muitas, mas quase não as utilizam de fato.
8. Uma das causas mais comuns de projetos incontroláveis é a má estimativa. (A segunda causa é tratada no Fato 23.)
9. A maioria das estimativas de projetos de software é feita no início do ciclo de vida. Isso não nos incomoda até percebermos que são feitas antes mesmo de os requisitos serem definidos e estudados. Portanto, são feitas no momento errado.
10. A maioria das estimativas em projetos de software é feita por executivos ou profissionais de marketing, e não por quem realmente desenvolverá o software ou seus gestores. Ou seja, as estimativas são feitas pelas pessoas erradas.
11. As estimativas raramente são ajustadas posteriormente. Em outras palavras, as estimativas feitas por pessoas erradas e no momento errado normalmente não são corrigidas.
12. Se as estimativas são tão incorretas, não há muitos motivos para se preocupar com o fato de os projetos não serem concluídos nos prazos estimados. No entanto, todos se preocupam com isso.
13. Não há comunicação entre gerentes e programadores. Em um estudo sobre um projeto considerado fracassado pela gestão por não atender às estimativas, os técnicos o descreveram como o melhor projeto em que já trabalharam.
14. A análise de viabilidade quase sempre resulta em um "sim".
15. O reuso em pequena escala (bibliotecas de sub-rotinas) surgiu há quase 50 anos e está bem estabelecido.
16. O reuso em grande escala (componentes) ainda é amplamente não resolvido, embora todos concordem sobre sua importância.
17. O sucesso do reuso em grande escala é maior em famílias de sistemas relacionados e depende da área de domínio, o que limita sua aplicabilidade.
18. Na prática do reuso, existem duas "regras dos três": a) componentes reutilizáveis levam três vezes mais esforço para serem desenvolvidos do que os descartáveis; b) um componente só é considerado suficientemente genérico para entrar numa biblioteca após ser usado em três aplicações diferentes.
19. Modificar código reutilizável é extremamente propenso a erros. Se for necessário mudar mais de 20–25% do código de um componente, é melhor reescrevê-lo do zero.
20. O reuso de padrões de projeto resolve os problemas associados ao reuso de código.
21. Um aumento de 25% na complexidade do problema leva a um aumento de 100% na complexidade da solução de software. Isso não é algo que se possa mudar; é um fato.
22. Oitenta por cento do trabalho em software é intelectual. Uma parte significativa é criativa. Apenas uma pequena parte é técnica.

Requisitos

23. Uma das duas causas mais comuns de projetos incontroláveis são os requisitos voláteis. (A outra é tratada no Fato 8.)
24. Corrigir erros nos requisitos é mais caro se descobertos na fase de operação e mais barato se encontrados nos estágios iniciais de desenvolvimento.
25. Requisitos ausentes são os mais difíceis de corrigir.

Projeto

26. À medida que avançamos dos requisitos iniciais para a arquitetura, somos bombardeados por "requisitos derivados" (relacionados à solução de projeto), causados pela complexidade do processo. Essa lista pode ser 50 vezes maior que a original.
27. A melhor solução de projeto raramente é única.
28. Projeto é um processo iterativo complexo. A solução inicial geralmente está errada e certamente não é a ideal.

Codificação

29. Os programadores passam do projeto à codificação quando o problema foi decomposto em "primitivos" dominados pelo projetista. Se projetista e codificador forem diferentes, é provável que os primitivos de um não coincidam com os do outro, o que causa problemas.
30. COBOL é uma linguagem muito ruim, mas todas as outras (para processamento de dados de negócios) são piores.
31. A fase de correção de erros é a mais trabalhosa do ciclo de vida.

Teste

32. Descobre-se que, em softwares que o programador típico presume serem cuidadosamente testados, muitas vezes apenas 55–60% dos caminhos lógicos foram verificados. O uso de ferramentas automatizadas, como analisadores de cobertura, pode aumentar essa proporção para cerca de 85–90%. Testar 100% dos caminhos lógicos de um software é praticamente impossível.
33. Mesmo que fosse possível atingir 100% de cobertura de testes, isso não serviria como critério de suficiência dos testes. Cerca de 35% dos defeitos de software são causados por caminhos lógicos omitidos, e outros 40% estão relacionados à execução de combinações únicas de caminhos lógicos. Eles não podem ser identificados apenas com 100% de cobertura de testes.
34. Sem ferramentas, é quase impossível fazer um bom trabalho de depuração. Depuradores são amplamente utilizados — ao contrário de outras ferramentas, como analisadores de cobertura de testes.
35. Os testes raramente são automatizados. Ou seja, certos processos de teste podem e devem ser automatizados, mas uma parte significativa do trabalho relacionado ao teste não pode ser automatizada.
36. Um complemento importante às ferramentas de teste é o código de depuração embutido, criado pelo programador, preferencialmente incluído no código objeto dependendo de diretivas de compilação.
37. Inspeções minuciosas podem eliminar até 90% dos erros de um produto de software antes mesmo que o primeiro teste de referência seja executado.
38. Inspeções minuciosas oferecem muitos benefícios, mas não podem substituir os testes.
39. É amplamente reconhecido que revisões feitas posteriormente (também chamadas de retrospectivas) são importantes tanto do ponto de vista do usuário quanto da melhoria do processo. No entanto, na maioria das organizações, revisões retrospectivas não são realizadas.
40. Inspeções envolvem não apenas fatores técnicos, mas também fatores sociais. Focar apenas em um deles em detrimento do outro é um caminho direto para o desastre.
41. O custo de manutenção geralmente representa de 40 a 80% (em média 60%) do custo total do software. Portanto, essa pode ser a fase mais importante do ciclo de vida do software.
42. Cerca de 60% dos custos de manutenção vão para a melhoria do código, e cerca de 17% para a correção de erros. Assim, a manutenção de software consiste principalmente na adição de novas funcionalidades, e não na correção de falhas.
43. Manutenção é uma solução, não um problema.
44. Comparando desenvolvimento e manutenção de software, as tarefas são em grande parte semelhantes, exceto pela tarefa adicional da manutenção, que é "compreender o produto mantido". Isso representa cerca de 30% do tempo gasto na manutenção e é a atividade predominante. Portanto, pode-se dizer que a manutenção é mais trabalhosa do que o desenvolvimento.
45. Melhorar a qualidade do desenvolvimento de software leva a um aumento da manutenção, não à sua redução.

Qualidade

46. Qualidade é um conjunto de atributos.
47. Qualidade não é definida pela satisfação do usuário, conformidade com os requisitos do cliente, aceitabilidade do preço, cumprimento dos prazos ou confiabilidade.
48. Existem erros aos quais a maioria dos programadores é propensa.
49. Erros tendem a se agrupar.
50. Ainda não existe uma única abordagem definitiva para eliminar erros.
51. Os erros são inevitáveis. O objetivo é evitar erros críticos ou minimizá-los.

Eficiência

52. A eficiência depende mais de um bom design do aplicativo do que de uma boa codificação.
53. A eficiência do código em linguagens de alto nível, compilado com os parâmetros de otimização apropriados, pode atingir 90% da eficiência de um código em assembler funcionalmente comparável. Em algumas arquiteturas modernas complexas, pode até ser superior.
54. Existem compromissos entre otimização de tamanho e otimização de velocidade. Muitas vezes, melhorar um resulta em piorar o outro.

Sobre pesquisas científicas

55. Muitos pesquisadores da indústria de software tendem mais a defender suas teorias do que a conduzir pesquisas. O resultado: a) o valor de algumas das teorias promovidas é muito menor do que seus proponentes acreditam; b) há poucas pesquisas para determinar o verdadeiro valor dessas teorias.

Equívocos sobre programação

1. Não se pode gerenciar o que não se pode medir.
2. A gestão pode garantir a qualidade de um produto de software.
3. A programação pode e deve ser impessoal.
4. Ferramentas e tecnologias são universais.
5. A programação precisa de mais metodologias.
6. Para estimar custos e prazos, conte primeiro as linhas de código.
7. Usar dados de entrada aleatórios é uma boa maneira de otimizar os testes.
8. "Todos os erros se tornam visíveis se forem observados por olhos suficientes".
9. Sabendo quanto custou a manutenção anteriormente, é possível prever quanto custará no futuro e decidir se vale a pena substituir o produto.
10. As pessoas podem aprender a programar apenas vendo como se escrevem programas.

Conclusão

Apesar de o livro ter sido escrito em 2008, ainda o recomendo para quem está estudando programação. Uma desvantagem evidente é que é difícil confirmar ou refutar os percentuais e números citados pelo autor. Além disso, alguns fatos já se tornaram obsoletos. No entanto, a maior parte do conteúdo continua relevante e será útil não apenas para desenvolvedores, mas também para gerentes.