32 (25) Leis da Engenharia de Software
João Pascoal FariaHugo Sereno Ferreira
Faculdade de Engenharia da Universidade do Porto
Ilei fundamental da
engenharia de requisitos
os requisitos terminam onde começa a liberdade do
implementador.
h
IIlei dos três éfes da
gestão de prioridades
funcionalidade,
fiabilidade,
eficiência.
h
IIIprincipio fundamental da
arquitectura de software
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.
h
jim gray
IVlei 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.
Vprincípio fundamental da
desconfiança homem-máquina
h
inteligência artificial é melhor do que estupidez natural.
VIparadoxo da redundância
h
a redundância é fonte de erros, mas também permite revelar
erros.
VIIprincí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
VIIIlimite fundamental da
engenharia de software
h
é praticamente impossível provar que um programa está
correcto*
*corolário. desenvolver software é conjecturar soluções.
IXprincí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
Xlema fundamental do
teste de software
h
os bugs escondem-se nos cantos e reúnem-se nas fronteiras.
boris beizer
XIprincí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.
XIIdinâmica do
deslizamento de prazos
h
falta cada vez mais tempo para acabar o projecto.
XIIIparadoxo 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.
XIVprincí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.
XVlei 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.
XVIresponsabilidade 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.
XVIIpropósito básico do
debugging
h
debugging consiste no processo de remoção de bugs*
* logo, programar é o processo de os introduzir.
edsger dijkstra
XVIIIa arte da remoção de bugs
h
os noviços inserem código correctivo; os mestres removem
código defeituoso.
Richard Pattis
XIXproblema fundamental da
usabilidade
h
o maior erro quando se tenta desenhar algo à prova de idiotas, é subestimar a capacidade deles.
Douglas Adam
XXprincipio 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
XXIhipótese de wirth
h
o software tende a ficar mais lento, mais rapidamente do que o
hardware fica mais rápido.
Wirth
XXIIa 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
XXIIIteoria da
dilatação temporal
h
nunca há tempo para desenvolver correctamente*
* mas há sempre tempo para desenvolver de novo.
XXIVconjectura de
transmutação de bruce
h
quaisquer defeitos suficientemente avançados são
indestinguíveis de funcionalidades.
Bruce Brown
XXVlei 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.
XXVIparadoxo do planeamento
h
os planos não servem para nada*
* mas é indispensável planear.
Dwight Eisenhower
XXVIIprimeira lei da
documentação de software
h
o melhor código é simultaneamente a sua melhor
documentação.
XXVIIIa 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
XXIXprática e pragmática
da automatização
h
se se automatizar uma pessegada, obtem-se uma pessegada automática.
Rod Michael
XXXhipó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
XXXIprincipio da instabilidadequântica dos requisitos
h
quanto mais estável um requisito é considerado, maior a probabilidade
de ele ser alterado.
XXXIIlei da inflacção da
concepção de software
h
a maior dificuldade durante a concepção de software é deixar
funcionalidades de fora.
Donald Norman
XXXII+Ia 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.
Top Related