Baixe o app para aproveitar ainda mais
Prévia do material em texto
32 (25) Leis da Engenharia de Software João Pascoal Faria Hugo Sereno Ferreira Faculdade de Engenharia da Universidade do Porto I lei fundamental da engenharia de requisitos os requisitos terminam onde começa a liberdade do implementador. h II lei dos três éfes da gestão de prioridades funcionalidade, fiabilidade, eficiência. h III principio 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 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. V princípio fundamental da desconfiança homem-máquina h inteligência artificial é melhor do que estupidez natural. VI paradoxo da redundância h a redundância é fonte de erros, mas também permite revelar erros. 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 VIII limite fundamental da engenharia de software h é praticamente impossível provar que um programa está correcto* *corolário. desenvolver software é conjecturar soluções. 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 X lema fundamental do teste de software h os bugs escondem-se nos cantos e reúnem-se nas fronteiras. boris beizer 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. XII dinâmica do deslizamento de prazos h falta cada vez mais tempo para acabar o projecto. 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. 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. 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. 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. 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 XVIII a arte da remoção de bugs h os noviços inserem código correctivo; os mestres removem código 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 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 XXI hipótese de wirth h o software tende a ficar mais lento, mais rapidamente do que o hardware fica mais rápido. Wirth 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 XXIII teoria da dilatação temporal h nunca há tempo para desenvolver correctamente* * mas há sempre tempo para desenvolver de novo. XXIV conjectura de transmutação de bruce h quaisquer defeitos suficientemente avançados são indestinguíveis de funcionalidades. Bruce Brown 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. XXVI paradoxo do planeamento h os planos não servem para nada* * mas é indispensável planear. Dwight Eisenhower XXVII primeira lei da documentação de software h o melhor código é simultaneamente a sua melhor documentação. 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 XXIX prática e pragmática da automatização h se se automatizar uma pessegada, obtem-se uma pessegada automática. Rod Michael 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 XXXI principio da instabilidade quântica dos requisitos h quanto mais estável um requisito é considerado, maior a probabilidade de ele ser alterado. 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 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.
Compartilhar