sábado, 21 de novembro de 2009

Organização de áreas

A organização de áreas de forma a desenvolver um projecto de software bem podia ser um tema da disciplina de engenharia de software. Já agora os programas físicos ainda são um mito no momento presente da construção deste livro.
Este é um modelo imaginativo de como poderá ser um projecto de linguagem explicita neste livro.
Até agora já se sabe do tema deste livro e sabe-se do possível poderosíssimo potencial que a informática pode trazer ao nosso mundo. Não se trata só de jogos, de filmes, de bases de dados, de música etc. Mas de uma organização e abstracção tal e de uma capacidade de manuseamento bastante flexível, que podem controlar meios físicos para concretizar os sonhos do Homem: dominar a natureza. Uma questão foi portanto levantada, sendo ela o poderio.
Mas se o Homem não é organizado e não facilta, então não servirá de nada. Fica aqui uma proposta de organização evolutiva para além das referidas. Finalmente uma “não tanto virtual”. Talvez as metodologias com o RUP(rational unified process) ou XP(extreme programming) e etc ajudem...
Pode chegar o dia em que o conhecimento torne-se algo demasiado “volumoso”. Nessa altura haverá grupos de especialistas programadores cada um estudando partículas de uma determinada escala.
Ora o mais importante é que cada grupo saiba trabalhar com os 2 grupos (o que estuda as mais pequenas imediatamente seguir e o que estuda as maiores imediatamente seguir), através de uma linguagem apropriada ao trabalho de cada um e de acordo com aquilo que sabem ou estão habituados; de forma que se concretize melhor e mais rapidamente o trabalho final. Não esquecer que o que o engenheiro informático tem de melhor é a lógica e não o conhecimento das linguagens ou arquitecturas.
Para isso existirá um director que propõe um projecto, de seguida cada grupo de estudo de partículas vai impondo regras, metas e limites aos outros mais abaixo. Se houver a hipótese de o projecto ser possível, então vai a parte mais difícil (a construção do código fonte começando do baixo nível), sendo este um modelo bottom-up. Mas uma das particularidades das metodologias de desenvolvimento de software é o máximo de paralelismo, de maneira que seria bem melhor estabelecer a comunicação inter-camada e depois se possivel vai-se logo por esse método (modelo share-and-go), senão podia-se tentar pelo outro. Tem a desvantagem de necessitar de emuladores para teste, uma vez que a camada anterior não foi desenvolvida. O modelo bottom-up tem a vantagem de ser mais flexível com APIs por parte dos de mais baixo nível.
Se o projecto não for mesmo possível, então será mais um caso para a comunidade científica em geral ou talvez não conforme o resultado de uma organização que trata de casos falhados. Uma metodologia destas exige vários trabalhos em simultâneo de forma a evitar sobre-uso de folgas nos mapas de Gant (um diagrama que descreve as várias tarefas ao longo do tempo).
Mas algo que pode mexer nestes problemas com bom impacto são os programas quânticos (códigos de alto nível que correm em qualquer escala).
Algo típico da engenharia de requisitos é a capacidade de dialogo com o cliente. Depois de feito é preciso que o utilizador final saiba fazer o que lhe convém e isso está relacionado com a interface e a documentação fornecidos.

Licença GPL

Sem comentários:

Enviar um comentário