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.