as 32 leis da engenharia de software
Post on 15-Dec-2014
2.952 Views
Preview:
DESCRIPTION
TRANSCRIPT
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