Este documento apresenta 32 leis e princípios fundamentais da engenharia de software, cobrindo tópicos como requisitos, arquitetura, teste, qualidade, gestão de projetos e documentação.
1. 32 (2
Leis da5)
Engenharia de Software
João Pascoal Faria
Hugo Sereno Ferreira
Faculdade de Engenharia da Universidade do Porto
2. I
lei fundamental da
engenharia de requisitos
h
os requisitos terminam onde
começa a liberdade do
implementador.
3. II
lei dos três éfes da
gestão de prioridades
h
funcionalidade,
fiabilidade,
eficiência.
4. III
principio fundamental da
arquitectura de software
h
qualquer problema de estruturação de
software resolve-se introduzindo níveis
de indirecção*
*corolário. qualquer problema de desempenho resolve-
se removendo níveis de indirecção.
jim gray
5. IV
lei de arquimedes da
arquitectura de software
h
um sistema de software fundado
numa má arquitectura afundar-
se-á sob o peso do seu próprio
sucesso.
6. V
princípio fundamental da
desconfiança homem-máquina
h
inteligência artificial é melhor
do que estupidez natural.
7. VI
paradoxo da redundância
h
a redundância é fonte de erros,
mas também permite revelar
erros.
8. VII
princípio fundamental da
verificação & validação
h
um programa que cumpre
perfeitamente uma péssima
especificação é um péssimo programa,
não um programa perfeito.
cem kaner
9. VIII
limite fundamental da
engenharia de software
h
é praticamente impossível
provar que um programa está
correcto*
*corolário. desenvolver software é conjecturar
soluções.
10. IX
princípio fundamental da
qualidade de software
h
todo o programa tem erros*
* o número de erros de um programa é dado precisamente
pela formula Nerros > K, em que K é um inteiro qualquer.
leis de murphy
11. X
lema fundamental do
teste de software
h
os bugs escondem-se nos cantos
e reúnem-se nas fronteiras.
boris beizer
12. XI
princípio da incerteza no
planeamento de projectos
h
não é possível fixar simultaneamente
o resultado, custo e duração de um
projecto de software.
13. XII
dinâmica do
deslizamento de prazos
h
falta cada vez mais tempo para
acabar o projecto.
14. XIII
paradoxo de
zenon do software
h
não basta fazer o que falta fazer
para satisfazer o cliente*
*a satisfação do cliente é um alvo em movimento.
15. XIV
princípio da conservação
da não-aceitação
h
os X% que falta implementar têm
(100-X)% de importância para o
cliente.
16. XV
lei fundamental da
gestão de alterações
h
fazem-se sempre mais alterações,
até não haver mais tempo para
fazer alterações*
*corolário. a última alteração é a que deu cabo de tudo.
17. XVI
responsabilidade social do
engenheiro de software
h
o mundo pode acabar devido a
uma catástrofe. e é aí que entram
os engenheiros de software*
* como causadores, entenda-se.
18. XVII
propósito básico do
debugging
h
debugging consiste no processo
de remoção de bugs*
* logo, programar é o processo de os introduzir.
edsger dijkstra
19. XVIII
a arte da remoção de bugs
h
os noviços inserem código
correctivo; os mestres removem
código defeituoso.
Richard Pattis
20. XIX
problema fundamental da
usabilidade
h
o maior erro quando se tenta
desenhar algo à prova de idiotas,
é subestimar a capacidade deles.
Douglas Adam
21. XX
principio da
não-proporcionalidade
h
os primeiros 90% do código
correspondem a 90% do tempo
de desenvolvimento*
* os restantes10% correspondem aos outros 90% do
tempo de desenvolvimento.
Tom Cargill
22. XXI
hipótese de wirth
h
o software tende a ficar mais
lento, mais rapidamente do que o
hardware fica mais rápido.
Wirth
23. XXII
a navalha de mencken
h
para todo o problema complexo
de software, existe uma solução
que é simultâneamente clara,
simples, e errada.
H. L. Mencken
24. XXIII
teoria da
dilatação temporal
h
nunca há tempo para
desenvolver correctamente*
* mas há sempre tempo para desenvolver de novo.
25. XXIV
conjectura de
transmutação de bruce
h
quaisquer defeitos
suficientemente avançados são
indestinguíveis de funcionalidades.
Bruce Brown
26. XXV
lei de hofstadter
h
o desenvolvimento demora sempre
mais do que foi estimado, mesmo
quando se tem em consideração a
lei de hofstadter*
* esta lei é recursiva.
27. XXVI
paradoxo do planeamento
h
os planos não servem para nada*
* mas é indispensável planear.
Dwight Eisenhower
28. XXVII
primeira lei da
documentação de software
h
o melhor código é
simultaneamente a sua melhor
documentação.
29. XXVIII
a dualidade do
desenho de software
h
há duas formas de construir software:
(1) fazê-lo tão simples que obviamente não
existem defeitos, ou (2) fazê-lo tão complexo
que não existem defeitos óbvios.
tony hoare
30. XXIX
prática e pragmática
da automatização
h
se se automatizar uma pessegada,
obtem-se uma pessegada automática.
Rod Michael
31. XXX
hipótese da congruência
da especificação
h
é mais fácil colocar a
especificação de acordo com o
programa, que vice-versa.
Alan Perlis
32. XXXI
principio da instabilidade
quântica dos requisitos
h
quanto mais estável um requisito é
considerado, maior a probabilidade
de ele ser alterado.
33. XXXII
lei da inflacção da
concepção de software
h
a maior dificuldade durante a
concepção de software é deixar
funcionalidades de fora.
Donald Norman
34. XXXII+I
a interveniência divina
na construção de software
h
o software e as catedrais gozam
essencialmente do mesmo processo*
* em ambos os casos, primeiro construímos e depois rezamos.