Você está na página 1de 34

32 Leis da Engenharia de Software

Joo Pascoal Faria Hugo Sereno Ferreira Faculdade de Engenharia da Universidade do Porto

5) (2

I lei fundamental da engenharia de requisitos

h
os requisitos terminam onde comea a liberdade do implementador.

II lei dos trs fes da gesto de prioridades

h
funcionalidade, fiabilidade, eficincia.

III principio fundamental da arquitectura de software

h
qualquer problema de estruturao de software resolve-se introduzindo nveis de indireco*
*corolrio. qualquer problema de desempenho resolvese removendo nveis de indireco.
jim gray

IV lei de arquimedes da arquitectura de software

h
um sistema de software fundado numa m arquitectura afundarse- sob o peso do seu prprio sucesso.

V princpio fundamental da desconfiana homem-mquina

h
inteligncia artificial melhor do que estupidez natural.

VI paradoxo da redundncia

h
a redundncia fonte de erros, mas tambm permite revelar erros.

VII princpio fundamental da verificao & validao

h
um programa que cumpre perfeitamente uma pssima especificao um pssimo programa, no um programa perfeito.

cem kaner

VIII limite fundamental da engenharia de software

h
praticamente impossvel provar que um programa est correcto*
*corolrio. desenvolver software conjecturar solues.

IX princpio fundamental da qualidade de software

h
todo o programa tem erros*
* o nmero de erros de um programa dado precisamente pela formula Nerros > K, em que K um inteiro qualquer.

leis de murphy

X lema fundamental do teste de software

h
os bugs escondem-se nos cantos e renem-se nas fronteiras.

boris beizer

XI princpio da incerteza no planeamento de projectos

h
no possvel fixar simultaneamente o resultado, custo e durao de um projecto de software.

XII dinmica do deslizamento de prazos

h
falta cada vez mais tempo para acabar o projecto.

XIII paradoxo de zenon do software

h
no basta fazer o que falta fazer para satisfazer o cliente*
*a satisfao do cliente um alvo em movimento.

XIV princpio da conservao da no-aceitao

h
os X% que falta implementar tm (100-X)% de importncia para o cliente.

XV lei fundamental da gesto de alteraes

h
fazem-se sempre mais alteraes, at no haver mais tempo para fazer alteraes*
*corolrio. a ltima alterao a que deu cabo de tudo.

XVI responsabilidade social do engenheiro de software

h
o mundo pode acabar devido a uma catstrofe. e a que entram os engenheiros de software*
* como causadores, entenda-se.

XVII propsito bsico do debugging

h
debugging consiste no processo de remoo de bugs*
* logo, programar o processo de os introduzir.
edsger dijkstra

XVIII a arte da remoo de bugs

h
os novios inserem cdigo correctivo; os mestres removem cdigo defeituoso.

Richard Pattis

XIX problema fundamental da usabilidade

h
o maior erro quando se tenta desenhar algo prova de idiotas, subestimar a capacidade deles.

Douglas Adam

XX principio da no-proporcionalidade

h
os primeiros 90% do cdigo correspondem a 90% do tempo de desenvolvimento*
* os restantes10% correspondem aos outros 90% do tempo de desenvolvimento.
Tom Cargill

XXI hiptese de wirth

h
o software tende a ficar mais lento, mais rapidamente do que o hardware fica mais rpido.
Wirth

XXII a navalha de mencken

h
para todo o problema complexo de software, existe uma soluo que simultneamente clara, simples, e errada.
H. L. Mencken

XXIII teoria da dilatao temporal

h
nunca h tempo para desenvolver correctamente*
* mas h sempre tempo para desenvolver de novo.

XXIV conjectura de transmutao de bruce

h
quaisquer defeitos suficientemente avanados so indestinguveis de funcionalidades.
Bruce Brown

XXV lei de hofstadter

h
o desenvolvimento demora sempre mais do que foi estimado, mesmo quando se tem em considerao a lei de hofstadter*
* esta lei recursiva.

XXVI paradoxo do planeamento

h
os planos no servem para nada*
* mas indispensvel planear.

Dwight Eisenhower

XXVII primeira lei da documentao de software

h
o melhor cdigo simultaneamente a sua melhor documentao.

XXVIII a dualidade do desenho de software

h
h duas formas de construir software:
(1) faz-lo to simples que obviamente no existem defeitos, ou (2) faz-lo to complexo que no existem defeitos bvios.

tony hoare

XXIX prtica e pragmtica da automatizao

h
se se automatizar uma pessegada, obtem-se uma pessegada automtica.

Rod Michael

XXX hiptese da congruncia da especificao

h
mais fcil colocar a especificao de acordo com o programa, que vice-versa.

Alan Perlis

XXXI principio da instabilidade quntica dos requisitos

h
quanto mais estvel um requisito considerado, maior a probabilidade de ele ser alterado.

XXXII lei da inflaco da concepo de software

h
a maior dificuldade durante a concepo de software deixar funcionalidades de fora.

Donald Norman

XXXII+I a intervenincia divina na construo de software

h
o software e as catedrais gozam essencialmente do mesmo processo*
* em ambos os casos, primeiro construmos e depois rezamos.

Você também pode gostar