Thursday, August 31, 2006

Aula 7

A aula foi dividida em duas partes. A primeira foi sobre codificação, e a segunda, voltamos a falar dos requisitos.

Primeira parte :

Foi comentado a diferença entre Buble sort e Quick sort. O primeiro usa menos memória mas é mais lento. E o Segundo e mais rápido e usa mais memória. Cabe ao engenherio tomar a decisão correta.

Falamos sobre acoplamento fraco e a sua importância. Sobre a expressão "JUST IN TIME" e foi dado o exemplo da madereira. Se a madereira trabalha sem estoque, ela só vai poder cortar quando a matéria-prima chegar. Produz na mesma velocidade em que chega o estoque.

Logo após, foi comentado novamente sobre o conceito do Sr. Knuth sobre programação
literária. Produzir uma documentação legível e bem escrita. Utilizar também frases curtas.

Segunda Parte :

Voltando a falar de requisitos, foi ensinado como elicitar os requisitos. Como extrair as informações necessárias do cliente.

  • Entrevista
  • Reuniões
  • Questionário
  • Leitura de documentos
  • Etnografia
  • Observação
  • Engenharia reversa
  • Reutilização
  • Participação do cliente
Para a entrevista foi comentado sobre o conhecimento do questionamento 5W1H e 5W2H.

5W1H ==> O que ? Por que ? Onde ? Quando ? Quem ? Como ?
5W2H ==> O que ? Por que ? Onde ? Quando ? Quem ? Como ? Quanto custa ?

Sobre modelagem: vimos que temos que escolher uma linguagem artificial para modelarmos os requisitos. Modelar -> Analizar/Verificar -> Validação -> Retro-Alimentação ( correteza / completeza) .


Aula 6

Começamos a aula com mapeamento de decisões e árvore de decisões.
Elas ajudam a detectar erros na especificação. Também combatem a ambiguidade e servem para descobrir erros antes que eles ocorram.
Falamos sobre escopo, ele delimita a área de entendimento aonde usaremos o modelo. Aonde também estará os requisitos do projeto.

Duas frases que foram enfatizadas :

Um BOM desenho vale mais que mil palavras.
Para um software ser eficaz, ele precisa atender os requisitos.

Aula 5

-= MODELOS =-

Vimos na aula o conceito de modelos. Logo no início fizemos um exercício de fluxograma, que é uma linguagem gráfica simples.
Falamos sobre as vantagens de se fazer um modelo:
  • Ajudam a sair da abstração para um nível de detalhe bastante acentuado.
  • Simplificam, combatem a complexidade.
  • Estabelecem uma liguagem comum.
  • Facilitam a sistematização.
Regras que ajudam nos modelos, são as regras 3, 4, 5, comentadas nas aulas 3 e 4 .

Outras regras de bom uso:
  • Acoplamento baixo.
  • Coesão alta.
  • Information Hiding ( Encapsulamento ).

Aula 4

== Regra 4 - Invenção de nomes ==

Escolher o nome com sapiência, para que outras pessoas consigam identificar e associar a sua função.

O nome tem que ser : Legível, Relacionado com o problema, ter prefixo.

Prós : Bom entendimento, capacidade de análise.
Capacidade de análise.

Contras: Dá muito trabalho.
Gasta mais memória.

Concluindo, vale a pena gastar um pouco mais de tempo para criar variáveis. Isso influi num bom entendimento no futuro, ou para outras pessoas que lerão seu documento.


== Regra 5 - “Small is Beautiful” ==

Faça um código simples, direto e pouco prolixo.


== Regra 6 - Como organizar seu livro diário ==

Serve para manter o registro sobre a sua propriedade e lembrar das alterações que você fez.
Foram mencionadas associações de Engenharia de Software como: SBC, IEEE, ACM.
Separar os erros por tipo: Interface, dispositivos de entrada e saída, memória, etc. .

Isso tudo está denominado no Personal Sofware Process (PSP) , para fins de facilitar o desenvolvimento do software ou documentos em geral.

Thursday, August 17, 2006

Aula 3

Falamos novamente sobre o software C & L .
Discutimos sobre arte x artezanato.
O professor comentou sobre o livro PSP( Personal Software Process ), a bíblia do engenheiro de software para efeitos de controle de sua produtividade.

Foi dado na sala de aula 6 regras de disciplina:

1- Todo documento deve ter título, autor, data, versão, indicador de conteúdo.

2- Em todo documento deve ter pré e pós condições. ETVX (Entry-Tasks-Verification&Validation-Exit), criado pela IBM nos anos 80.


3- [ 3 ,6 ] Todo sistema é um sub-sistema de um sistema maior.
Sempre divida o sistema em 3 ou 6 partes, assim torna-se mais facil identificar o início, meio e fim do que se deseja dividir, enquanto que não torna muito complexas as interconexões entre as partes.

Douglas Ross falou: "Tudo tem início, meio e fim."
Numero mágico -> 7+- 2
A clusterização diminui a complexidade dos problemas.

Aula 2

Na aula 2 foi comentado o triangulo do conhecimento.

- Engenharia de Software
- Conhecimento da plataforma
- Conhecimento do problema a ser abordado

Falamos da diferença entre eficácia e eficiência.

O professor também pediu para dar uma olhada no software C & L , uma ferramenta de edição e visualização de Cenários e Léxicos.

Também falamos sobre eficácia versus eficiência no momento do desenvolvimento de um software.
O professor comentou novamente sobre a linguagem usada em mini-computadores chamada MUMPS.

Aula 1

A primeira aula foi a apresentação do curso e sobre o que será abordado.
Discutimos sobre software livre e software proprietário. As vantagens e desvantagens de um código aberto. Várias linguagens foram citadas pelo professor, entre elas Cobol, MUMPS, Fortran, Scheme.
Também foi comentado sobre a qualidade do software e seu processo de desenvolvimento.