16 (24) Leis Fundamentais da Engenharia de Software

Apresentação em tema: "16 (24) Leis Fundamentais da Engenharia de Software"— Transcrição da apresentação:

1 16 (24) Leis Fundamentais da Engenharia de Software
João Pascoal Faria 16 é uma potência de 2 Na próxima versão, serão 32 Grupo de Interesse em Engenharia de Software FEUP, Fevereiro de 2006 (v.0.2)

2 Índice Engenharia de Requisitos de Software Desenho de Software
Lei nº 1 – Lei fundamental da Engenharia de Requisitos Lei nº 2 – Lei dos 3 éfes da Gestão de Prioridades Desenho de Software Lei nº 3 – Princípio fundamental da Arquitectura de Software Lei nº 4 – Lei de Arquimedes da Arquitectura de Software Lei nº 5 – Princípio fundamental da Desconfiança Homem-Máquina Lei nº 6 - Paradoxo da Redundância Verificação & Validação de Software Lei nº 7 – Princípio fundamental da Verificação & Validação Lei nº 8 – Limitação fundamental da Engenharia de Software Lei nº 9 – Princípio fundamental da Qualidade de Software Lei nº 10 – Lema fundamental do Teste de Software Gestão de Projectos de Software Lei nº 11 – Princípio da incerteza no Planeamento de Projectos Lei nº 12 – Dinâmica do Deslizamento de Prazos Satisfação de Clientes em Projectos de Software Lei nº 13 – Paradoxo de Zenon do Software Lei nº 14 – Princípio da Conservação da Não-Aceitação Alteração de Software Lei nº 15 – Lei fundamental da Gestão de Alterações Responsabilidade Social e Profissional do Engenheiro de Software Lei nº 16 – Responsabilidade social do Engenheiro de Software

3 Lei nº 1 – Lei fundamental da Engenharia de Requisitos
Os requisitos terminam onde começa a liberdade do implementador. Resolve um dos dilemas de ER

4 Lei nº 2 – Lei dos 3 éfes da Gestão de Prioridades
1º) Funcionalidade 2º) Fiabilidade 3º) Eficiência Funcionalidade para vender Fiabilidade para confiar e usar Eficiência quando cresce o volume de dados e utilizadores

5 Lei nº 3 – Princípio 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. Constantes simbólicas Abstracção de dados e algoritmos Apontadores Encapsulamento e acesso indirecto aos dados Publish/subscribe Arquitectura por camadas Etc. (Jim Gray, Transaction Processing Systems)

6 Lei nº 4 – Lei de Arquimedes da Arquitectura de Software
Um sistema de software fundado numa má arquitectura afundar-se-á sob o peso do seu próprio sucesso. A arquitectura é a base de sustentação de um produto de software.

7 Lei nº 5 – Princípio fundamental da Desconfiança Homem-Máquina
Inteligência artificial é melhor do que estupidez natural. É o choque entre a inteligência e a estupidez, não se sabendo onde está uma ou outra. Os utilizadores desconfiam dos sistemas informáticos, porque desconfiam que foram dotados de inteligência (artificial) para suprir a suposta estupidez (natural) dos utilizadores. Um sistema menos estúpido, que apela mais à inteligência do utilizador, pode favorecer mais o ego do utilizador e obter a sua adesão. Excesso de inteligência do sistema pode ser vista como estupidez pelo utilizador.

8 Lei nº 6 - Paradoxo da Redundância
A redundância é fonte de erros, mas também permite revelar erros. Exemplos: Bases de dados: guardar o total de uma factura; pode ser fonte de erro, pois podemo-nos esquecer de actualizar o total cada vez que actualizamos as linhas Mas se uma transacção falhar a meio, vai-se notar pois o total fica inconsistente Código de teste: O código de teste permite detectar erros mas também pode ter erros Sistemas tolerantes a falhas têm vários sub-sistemas redundantes entre si o nº total de defeitos no sistema aumenta permite detectar erros na comparação de resultados dos sub-sistemas

9 Lei nº 7 – Princípio fundamental da Verificação & Validação
Um programa que cumpre perfeitamente uma péssima especificação é um péssimo programa, não um programa perfeito. (Cem Kaner, Testing Computer Software)

10 Lei nº 8 – Limitação fundamental da Engenharia de Software
É praticamente impossível provar que um programa está correcto. Corolário: Desenvolver software é conjecturar soluções para problemas.

11 Lei nº 9 – Princípio fundamental da Qualidade de Software
Todo o programa tem erros. Além disso, o número de erros de um programa é dado precisamente pela fórmula n > a, em que a é um inteiro qualquer. (*) (leis de Murphy dos computadores) (*) Não é possível fixar com segurança um limite inferior para o nº de erros de um programa.

12 Lei nº 10 – Lema fundamental do Teste de Software
Os bugs escondem-se nos cantos e reúnem-se nas fronteiras. (Boris Beizer, Software Testing Techniques) Bugs frequentemente têm a ver com valores limite

13 Lei nº 11 – Princípio da incerteza no Planeamento de Projectos
Não é possível fixar simultaneamente o resultado, custo e duração de um projecto de software. Princípio da incerteza de Heisenberg: não é possível fixar simultaneamente a posição e velocidade de um corpo.

14 Lei nº 12 – Dinâmica do Deslizamento de Prazos
Falta cada vez mais tempo para acabar o projecto. Quando os prazos começam a deslizar, há uma tendência para deslizaram cada vez mais … até se atingir uma situação de ruptura … Hoje falta 1 semana Passado 1 semana, afinal, realisticamente, são precisas mais 2 semanas Passadas mais 2 semanas, se calhar não sabemos se conseguimos .. Gravita quadraticamente em relação ao abismo …

15 Lei nº 13 – Paradoxo de Zenon do Software
Não basta fazer o que falta fazer para satisfazer o cliente (*). Aquiles o guerreiro decide saír a competir nunha carreira contra dunha tartaruga. Xa que corre moito máis axiña que ela, e seguro das súas posibilidades, dálle unha vantaxe inicial. Ao dar a saída, Aquiles percorre en pouco tempo a distancia que os separaba inicialmente, mais ao chegar alí descobre que a tartaruga xa non está, senón que avanzou, máis lentamente, un pequeno treito. Sen se desanimar, sigue a correr, mais ao chegar de novo onde estaba a tartaruga, esta avanzou un pouco máis. Deste xeito, Aquiles non gañará a carreira, xa que a tartaruga estará sempre por diante de el. Realmente, sábese que Aquiles atinxirá á tartaruga, xa que unha suma de infinitos termos pode ter un resultado finito. Os tempos nos que Aquiles percorre a distancia que lle separa do punto anterior no que se atopaba a tartaruga son cada vez máis e máis pequenos, e a súa suma dá un resultado finito, que é o momento en que atinxirá á tartaruga. ( (*) A satisfação do cliente é um alvo em movimento.

16 Lei nº 14 – Princípio da Conservação da Não-Aceitação
Os X% que falta implementar têm (100-X)% de importância para o cliente. Assim nunca mais se consegue obter a aceitação do cliente … Princípio da conservação da quantidade de movimento: quantidade de movimento = Cte, isto é massa * velocidade = Cte

17 Lei nº 15 – Lei fundamental da Gestão de Alterações
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.

18 Lei nº 16 – Responsabilidade social do Engenheiro de Software
O mundo pode acabar devido a uma catástrofe. E é aí que entram os Engenheiros de Software (*). (*) como causadores, entenda-se.