Blog do Grupo

June 22, 2006

Acesse o blog do grupo do trabalho final de PES através do link:

http://pes061group1.wordpress.com/

Aulas 16, 17, 18 e 19

June 5, 2006

Versão 1.0

 

Pré-condição: Parte do trabalho proposto pronto

 

Aula 16 – Demonstração do primeiro trabalho: (2/5 e 4/5)

Marco Antonio: Nessa aula, mostramos ao professor o trabalho ainda em processo de desenvolvimento. No meu caso, eu já havia feito praticamente todo o esqueleto do trabalho, faltando implementar detalhes como criptografar senha e e-mail e as três tentativas. Também faltavam os léxicos e cenários.

O maior problema apontado pelo professor foi o espaço de nomes, ou seja, o nome das variáveis utilizadas não estava satisfatório quanto à clareza de seu significado para o programa.

Outro problema foi a integração das intefaces de acesso e cadastramento de forma inadequada, pois um dos campos (e-mail) era desnecessário em uma das opções (acesso). Esse último foi corrigido com sucesso no trabalho final.

Fabio: Essa aula foi dedica a demostração do andamento dos trabalhos ao professor. Ja tinha implementado bastante coisa mas não sabia como organizar os cenário e os lexico, coloquei tudo no inicio do trabalho. O professor disse que eu deveria entrelaçar os cenários com o programa de forma com que os cenário relatem o que esta acontecendo naquele determinado trecho. Alem disso me aconselhou a manter os aquivos na puc e não no meu servidor em casa.

 

Pós-condição: Uma melhor direção de como continuar o trabalho após os conselhos do professor.

 

Pré-condição: Trabalho pronto

 

Aula 17 – Entrega do primeiro trabalho: (9/5 e 11/5)

Marco Antonio: Apresentei o funcionamento do trabalho ao professor. Quanto à execução, ele estava de acordo com a especificação, mas eu não havia entendido direito a questão dos léxicos e cenários, pois eu não os integrei ao código, desenvolvendo-os somente no programa C&L. O professor me deu mais uma chance para que eu pudesse apresentar o trabalho depois. Nessa ocasião, os cenários e léxicos estavam adequadamente integrados ao código, como especificado.

O problema principal do trabalho estava no espaço de nomes, que, apesar de mais adequado que no protótipo, não estava de acordo com os léxicos. Usei termos em inglês para as variáveis, enquanto que o léxico e os cenários estavam todos em português, por exemplo. Mesmo quando havia sinônimos em inglês nos léxicos, eu usei termos adicionais para, na minha concepção, identificar melhor cada variável, mas acabei sendo infeliz nessa tentativa.

No geral, percebi a importância da integração do código com os cenários e léxicos para um perfeito entendimento do mesmo.

Fabio: Apesar um uma boa demonstraçao do trabalho na aula passada tive problemas na demostração do trabalho. Não consegui acessar o código fonte dos arquivos php no meu servidor, alem disso o labGrad não disponibilisa nenhuma ferramenta para acesso remoto. Com isso o professor me pediu para colocar um ponteiro no blog para a codigo fonte para ele olhar depois. O que fiz na hora seguinte. Para apresentação entrelaçei os cenários no codigo como o professor havia pedido. Por um vacilo esqueci de mostar * no lugar da senha, o que o professor me chamaou atenção, pois estava especificado no cenário.

 

Pós-condição: Trabalho avaliado e nota.

 

Pré-condição: Todas as aulas anteriores

 

Aula 18 – Revisão para a prova: (16/5)

Aqui, o professor explicou como seria o esquema da prova: cinco questões práticas e cinco questões teóricas.

As questões teóricas poderiam ser discursivas ou de múltipla escolha relacionadas ao aspecto da teoria apresentada em aula.

As questões práticas tinham como base o próprio código produzido pelos alunos no primeiro trabalho, ou seja, parte de suas respostas deveriam ser respondidas no próprio código, apontando certos aspectos do mesmo.

Além disso, respondeu a algumas dúvidas relacionadas à matéria para que pudéssemos estar preparados. Algumas delas foram relacionadas a DFD, SADT, diagrama de seqüência, etc. Relembrou, também, a relação do custo de correção de erro com o estágio de desenvolvimento (definição, arquitetura ou código) e as diferentes técnicas de arquitetura, incluindo sub-linguagens da UML.

 

Pós-condição: Uma noção melhor de o que esperar no dia da prova.

 

Pré-condição: Saber sobre V&V, SADT e MTF.

 

Aula 19: (23/5)

A aula começou com o assunto de V&V (Verificação e Validação). O processo de inspeção formal de Fagan foi mencionado, incluindo suas etapas:

0 – Planejamento

1 – Preparação

2 – Leitura

3 – Reunião (com os autores)

4 – Revisão

5 – Acoplamento

 

Na etapa 2, foi frisada a importância de uma checklist contendo todas as regras de consistência apoiadas na base de conhecimento e, após terminada a leitura, a importância de um relatório com os resultados.

Em todo o processo, também é essencial a presença de um líder para coordená-lo.

Para mais informações sobre o processo de inspeção formal de Fagan, visite o link: http://en.wikipedia.org/wiki/Fagan_Inspection .

 

Também foram mencionadas as funções básicas de um gerente de projeto:

– Organizar

– Planejar

– Controlar

– Dirigir

Na verdade, sua função principal é atingir metas e, para isso, um gerente usa recursos, como organizar a equipe e escolher as MTF (Métodos, Técnicas e Ferramentas). Se fôssemos enxergar o processo como um nó de um SADT, o gerente seria o controle correspondente.

 

Pós-condição: Uma visão mais detalhada sobre o processo de verificação e também uma noção sobre gerência de projetos.

Autores: Marco Antonio e Fabio

Data: 5/6/2006

Aulas 13, 14 e 15

May 13, 2006

Versão 1.0

Aula 15:

Na aula 15 o professor falou sobre as Macro Arquiteturas ( Lembrando: na aula 14 foi descutido XML e padões de desenhos que são Micro Arquiteturas ). O professor falou sobre a arquitetura MVC (Model View Controller) onde o View controla a saida grafica e textual. O Controller interpreta as entradas do teclado e do mouse do usuário e aciona o Model ou/e o View conforme necessário. O Model controla o comportamento e os dados de dominio da aplicação, respondendo a pedidos de informação sobre um determinado estado (normalmente do View) , e repondendo com instruções para mudar de estado (geralmente para o Controller). O Professor explicou o que são Conectivos e Conectores na Macro Arquitetura. O profesor apresentou a arquitetura de Tubos e Filtros (pipes and Filters), a arquitetura de Redes, a de Repositórios e a de Camadas e fez exeplos no quadro para exemplificar. Achei um exemplo prático legal do MVC em j2me (java para celular) aqui .

Aula 14:

Nessa aula o professor introduziou a classe o conceito de linguagem de descrição de dados XML. Disse algumas vantagens sobre ela como flexibilidade e a vantagem de poder usa-la como meta linguagem. Em uma rapida pesquisa ficamos sabendo que a XML é vastamente usada nas linguagens de programação Java e .NET. Tanto para descrver arquivos de configuração / propriedades como em meta linguagem. Ex: Uma ferramente muito usada em Java é a ant que funciona como um "make" de C. Onde o programador define as propriedades da compilação atravéz de tags específicas em um arquivo xml chamado build.xml.

Outro tópico importante discutido nessa aula foi os Padões de Desenho, onde o professor explicou que os Padrões de Desenho são padrões de programação que com o tempo foram ficando conhecido por serem uteis em determinados casos. O professor comentou sobre o livro Design Patterns que eu ja conhecia e posso dizer que é uma ótima compra. Esse é um livro que descreve um monte de padrões, da exemplos e diz as situações em que aquele padrão é usualmente usado com sucesso. Conhecer esses padrões podem facilitar bastante a vida do programador e tornar o codigo mais legivel, pois quando outro programador for ler ocódigo, ele facilmente reconhecerá o padrão usado.

Aula 13:
A aula 13 foi no laboratório de graduação onde os alunos acessaram um tutorial da Borland sobre UML. Esse tutorial descreve diferentes diagramas da UML e no final de cada sessão contem perguntas para testar se o conhecimento foi aprendido. O professor ficou tirando duvidas enquanto os alunos pesquisavam e aprendiam. O professor recomendou fortemente que se respondam as perguntas do site pois na prova haverá perguntas semelhantes. A baixo segue um link para o tutorial.

link para o trabalho

May 9, 2006

Ola professor, o link para visualizar o meu trabalho é http://fabytes.sytes.net la esta todo o trabalho. Para visualizar o fonte das paginas trabpes1.php e trabpes2.php que são as paginas php que fazem o login e cadastra novo cliente acesse as paginas pagina1.php e pagina2.php. Obrigado e descupe o transtorno. Fabio B. P

Aulas 10, 11 e 12

April 26, 2006

Versão 1.0

Pré-condição:

Ter noções de construção de sistemas.

Aula 10: Uma das ênfases dessa aula foi a TGS (Teoria Geral de Sistemas) e sua importância no desenvolvimento e/ou entendimento de sistemas complexos. Como a teoria é geral, pode ser aplicada em diferentes campos do conhecimento; a prova disso é que foi desenvolvida por um biólogo, Karl Ludwig von Bertallanffy, mas, aqui, estamos aplicando em engenharia de software.

Interpretação da TGS:

“1. Definição:
“Um conjunto de partes inter-relacionadas que trabalham na direção de um objetivo.”
2. Contextualização:
“Todo sistema é um sub-sistema de um sistema maior”
3. Classificação:
“Os sistemas podem ser classificados quanto à sua: natureza (natural, artificial) , origem (concreto, abstrato) e tipo (aberto, fechado).”
4. Características Básicas:
“Os sistemas têm propósito, são afetados pela globalidade e sofrem os efeitos tanto da entropia como da homeostase”.
5. Conceitos fundamentais:

a. Limites:
Talvez esse seja um dos
pontos mais difíceis de ser definido, isto é
qual a fronteira de um sistema? Como
delimitar o que está dentro ou fora do sistema.
b. Interfaces:
A maneira como
os subsistemas se relacionam através de entradas e
saídas.
c. Pontos de Vista:
Todo sistema pode ser entendido ou observado de diferentes ângulos ou pontos de vista. A TGS considera que um sistema pode ser influenciado
por pontos de vista.
d. Nível de Abordagem (abstração):
Todo sistema tem um nível de detalhe. O
importante é assegurar que o
nível de detalhe utilizado é condizente
com o propósito do sistema.
e. Hierarquia:
A pedra fundamental da TGS na luta com a complexidade. A
idéia de
dividir um problema grande (sistema) em problemas menores
(subsistemas) é
intrínseca a idéia de sistemas”

http://sisdinf.blogspot.com/2006/04/um-breve-resumo-sobre-teoria-geral-dos.html

Uma das filosofias da TGS é o “dividir para conquistar”. Dividindo um sistema complexo em vários sistemas mais simples, podemos facilitar seu desenvolvimento, embora isso também gere outro possível problema: a comunicação entre as diferentes divisões. Resolvemos isso usando a hierarquia, ou seja, cada parte também é dividida em diversas partes, porém cada parte só se comunica com seus ascendentes; cortamos as comunicações horizontais e nos atemos às verticais.

Dois termos também importantes são acoplamento e coesão. O acoplamento mede o tipo de mensagem trocada na comunicação e a coesão o quanto cada parte está conectada. É desejável ter uma coesão forte e um acoplamento fraco, ou seja, que as partes estejam intimamente interligadas, mas que a informação que trafega entre elas seja simples.

Outro conceito relacionado mencionado em aula foi o “information hiding”, inventado pelo Prof. David Parnas, que se refere ao fato de um módulo cliente de um certo módulo servidor não precisar saber exatamente o funcionamento interno deste último, somente o que for necessário para usar suas funcionalidades. Isso está intimamente ligado com a diminuição do acoplamento.

 

Outra filosofia para o desenvolvimento de sistemas é a orientação a objetos. Ela prega que objetos do mundo real podem ser modelados através de objetos no sentido ao qual estamos acostumados em programação. Ambos têm atributos e métodos claramente encapsulados em si e alguns deles se comunicam com outros objetos, sejam do mesmo tipo ou não.

Em contrapartida com a teoria de sistemas, o foco não é mais a divisão, mas a especialização. Normalmente há um objeto pai de todos, que forma a classe mais geral e seus descendentes são mais especializados, apesar de ainda serem do mesmo tipo que o patriarca.

 

Finalmente, a orientação a aspectos. É uma novidade em termos de engenharia de software e algo alternativo às duas filosofias citadas anteriormente. É muito útil para considerarmos as características transversais, um ponto em que as filosofias anteriores pecam. Um exemplo do uso de orientação a aspectos nos foi apresentado na segunda aula do curso.

Pós-condição:

Conhecemos três das mais importantes filosofias necessárias para se entender e desenvolver sistemas de informação, podendo, agora, aplicá-las na nossa vida profissional e acadêmica.

Pré-condição:

Nenhuma

Aula 11: O foco dessa aula foi a SADT (Structured Analysis & Design Technique), que é uma técnica usada na construção de modelos. Segundo essa visão, cada modelo deve ter um objetivo e um ponto de vista.

Há duas perspectivas de modelos:

– Processo (Actigrama)

– Dados (Datagrama),

porém somente os actigramas foram focados em aula. Os actigramas não consideram os dados utilizados no processo.

Os modelos são construídos segundo os princípios de decomposição (Vide normas de disciplina nas aulas 3 e 4), formando uma espécie de árvore, onde o primeiro nível, A0, é constituído de uma raiz, que contém somente uma ação-pai, e seus filhos diretos, sendo os próximos níveis A1, A2, etc. Cada nível deve poder caber numa única folha de papel, usada como parâmetro de visualização, exceto o nível A0, constituído de duas partes, portanto de duas folhas de papel.

Notação:

Um retângulo contendo o nome da ação. Nele, chegam setas à esquerda, as entradas, e saem setas pela direita, as saídas. Há, ainda, setas chegando por cima e por baixo, que representam, respectivamente, controles e mecanismos.

 

Na aula, fizemos um exemplo do nível A0 de um SADT para aluguel de DVD, onde as ações dos filhos diretos da raiz eram cadastrar, entregar, pagar, receber e verificar, todas num SADT de título “Alugar” (ação-pai).

“Objetivo: Descrever as principais atividades que um artefato de software deve apoiar para que DVDs sejam alugados.

Ponto de vista: Engenheiro de software com conhecimento geral sobre o funcionamento de locação de DVDs.”

Numa outra folha de papel, construímos a raiz, que se constituía de uma única ação, alugar, cujas entradas eram todas as entradas presentes em seus filhos e idem para as saídas e os controles (não consideramos mecanismos).

 

Pós-condição:

Conhecemos uma técnica concreta para planejamento e modelagem de sistemas.

Pré-condição:

Conhecer o SADT e ter noções de UML.

Aula 12: O foco dessa aula foi o processo de decomposição em Diagramas do tipo DFD (Diagrama de Fluxo de Dados). Apesar de não ser uma sublinguagem da UML, como dito em aula, ainda assim é importante, pelas seguintes razões citadas no blog da disciplina:

“1) DFD expõe claramente o sentido de contexto.

2) DFD é uma linguagem relativamente simples.

3) É mais um exemplo da filosofia de sistemas (hierarquia – decomposição).

4) É orientada a fluxo — transformação e portanto serve como contraponto a linguagem do SADT.”

Uma grande diferença para o SADT é o fato de as entradas se tornarem saídas.

Em sala, foi vista, em detalhe, a passagem do nível 1 para o nível 2 do diagrama, partindo do exemplo do processo “escolher” do caso do aluguel de DVDs. Percebemos que as regras de preservação de entradas e saídas ajudam a detectar erros. O próprio processo de decomposição permite que a necessidade de decomposição seja revista em termos do diagrama.

A linguagem MER foi comparada com o diagrama de classes. Mais uma vez foi ressaltada a filosofia de generalização da orientação a objetos e a importância da herança. Também foi ressaltada a importância do domínio da UML para um engenheiro de software.

Pós-condição:

Conhecemos mais um método de auxílio ao planejamento de sistemas.

Autores: Fabio Pereira e Marco Antonio Curvello
Data: 26/4/2006 Contém: Resumo de 3 aulas

 

Aulas 7, 8 e 9

April 8, 2006

Versão: 1.0

pré-condição:

Alguma experiencia em projetos, teste e uma cabeça fresca para aprender algums coiceito fundamentais da engenharia de software.

  • Aula 7: Nesta aula foi discutido um conceito muito importante. O da corretude X consistência. Foi dito que através de testes podemos tornar um software mais consistente, o que não significa que estaremos tornando-o mais correto. A corretude do aplicativo será feita pelo cliente que aprovação ou não o software. Um ponto importante é que teste só validam, encontram inconsistencias, defeitos, para encontrar erros é necessário outro processo. Outro conceito interessante que foi lembrado é sobre o Universo de Informação(UDI) ou domínio do problema. Esse conceito diz respeito a todo conhecemento necessário para o desenvolvimento e validação do software. Deve ser levado em conta as necessidade e condições de trabalho do cliente, estudado tudo relacionado ao assunto para que se possa ter um bom udi. Abrindo um parênteses aqui para o tema de Cenários (que vai ser fortemente discutido na disciplina) alguns Atores do udi são: Clientes, usuários e desenvolvidores.pós-condição: Aprendemos conceito muito importantes nessa aula, não só importante mas como dificeis e sutis, temos que ficar pensando um pouco para que tudo se encaixe direito.

    pré-condição:

    Conhecimento em alguma linguage de programação, noção de intrnet, banco de dados, programação web. conhecimento em php, mysql e html ajudará bastante.

  • Aula 8: Essa aula foi dada pelo monitor Bernardo que nos ensinou um pouco de programação php, mysql e html. Nos avisou sobre um trabalho valendo nota que será pedido no qual usaremos essas tecnologias. ele tembém fez uma introdução do que é Cenários e Léxicos e nos mostrou alguns exemplos de como fazer. Para a gelera que usa linux recomendo LAMP (linux, apache,mysql e php), para quem não sabe apache é um servidor web onde você pode hospedar as suas próprias paginas html,php,etc.. basta configurar. O alternativo é o tomcat bem bom também mais achei um pouquinho mais dificil de configurar. Aqui tem um link para um site ensinado como instalar no Fedora. http://users.tkk.fi/~tkarvine/lamp-linux-apache-mysql-php.html obs: não testei pois uso outra distribuição derivada de Debian, aqui um link: http://librenix.com/?page=LAMPpós-condição: Aprendemos um pouco mais sobre html,php, mysql e principalmente sobre Cenários e léxicos, o que significam e para que servem.

    pré-condição:

    Experiência basica em produção de software.

  • Aula 9: Na aula 9 foi apresentado o conceito de elicitação (descobrimento, clareamento) do conhecimento. Algumas dessas maneiras são:
    1- Entrevista
    2- Reunião
    3- Leitura de documentos
    4- Questionários
    5- Observação
    6- Etnografia (esqueci o q significa mas foi dito na aula)
    7- Reutilização
    8- Análize de protocolo
    9-Participação (clientes/usuários)
    Para cada um desses item existem técnicas, algumas vezes bem elaboradas de complexas, para aplicar o método. Foi lembrado também a técnia de engenharia concorrente na qual mais de uma parte do software é desenvolvido ao mesmo tempo sem a necessidade de ir fazendo uma parte verificando, corrigindo e adicionando ao baseline para poder proceguir com o desenvolvimento. Ma página da matéria o professor citou MTF's mas não explicou o que significa e não anotei nada sobre isso no caderno também.pós-condição: Aprendemos diversas técnicas para fazer elicitação do conhecimento no processo de desenvolvimento de software.

    Autores: Fabio Pereira e Marco Antonio
    Data: 08/04/2006 Contém: resumo de 3 aulas

  • Resumo: Aulas 4, 5 e 6

    March 27, 2006

    Versão 1.0

     

    Pré-condição:

    Conhecer as quatro primeiras regras de disciplina.

     

    • Aula 4: Foram apresentadas as últimas regras de disciplina:
      • 5 – "Small is beautiful" / "Clean/Simple Design", i.e., sempre simplificar tudo ao máximo
      • 6 – Manter um livro diário (log book) (com o intuito de aprender com os erros e facilitar o aprendizado)

    Um dos comentários pertinentes à 5ª regra foi sempre evitar o "goto" ao programar.

    Também foi mencionada a "way back machine" (http://www.archive.org/web/web.php). Site, onde podemos encontrar arquivos antigos já apagados da internet. Muito útil para encontrar temas discutidos no passado ou até notícias antigas.

    Outro nome mencionado foi o do senhor Knuth, inventor do TeX (precursor do LateX) , também relacionado com a programação literária.

    Também revimos as três estruturas básicas em programação: seqüência, seleção e iteração.

     

    Pós-condição:

    Completamos nosso conhecimento sobre as regras de disciplina para se trabalhar com o engenheiro de software. Também aumentamos nossa cultura específica da área, aprendendo sobre mais uma personalidade do mundo da engenharia de software e também conhecendo um site tão útil como a "way back machine".

     

     

    Pré-condição:

    Conhecimento básico de lógica.

     

    • Aula 5: Nos foi introduzido os novos conceitos de tabela e árvore de decisão. Através de um exemplo de regras estabelecidas para decidir se um candidato a seguro de veículo está apto a ser assegurado ou não, montamos a tabela de decisão.

    Essa aula foi, no mínimo, polêmica. Ao nos depararmos com algumas inconsistências lógicas na especificação das regras, a grande questão que se levantou foi o que fazer se algo semelhante acontecer na nossa vida profissional, ou seja, se houver inconsistências ou incompletudes na especificação de um software dada por um cliente, por exemplo. A recomendação do professor foi, sempre que possível, resolver tais dúvidas se comunicando com o cliente, ou seja, sempre deve haver o feedback. O conhecimento tácito, ou seja, aquele que é está implícito para quem especifica, também contribui para esse problema, pois nem sempre ele é conhecido pelo desenvolvedor.

    Também foi introduzido o conceito de baseline, que está intimamente ligado com o primeiro estágio do desenvolvimento de um software: a definição (logo em seguida, vêm o desenho/modelo e a implementação). Um comentário interessante foi o fato de o desejo do desenvolvedor ser que, uma vez definida a baseline, ela não se altere. Porém, pelo fato de nem sempre o cliente ter suas necessidades e desejos bem definidos, isso nem sempre é possível.

    O trabalho principal do engenheiro de software é transformar necessidades e desejos em um modelo em linguagem de representação.
    Pós-condição:

    Agora obtemos mais um recurso de modelagem, a tabela/árvore de decisão. Aprendemos ainda mais sobre o que é ser um engenheiro de software realmente, suas dificuldades e barreiras a serem transpostas.

     

     

    Pré-condição:

    Conhecimentos básicos de linguagem de programação. Experiência mínima com desenvolvimento de software. Noções de algoritmos.

    • Aula 6: Nesta aula, foi frisada a importância de se ter um código inteligível. Nomes de variáveis significativos ajudam na leitura do código ("old code never dies").

    Todavia, é preciso haver um equilíbrio entre facilidade de leitura e facilidade de escrita, apesar de isso não ser fácil, pois um contribui negativamente para o outro. Na verdade, o que deve ser maximizado é a eficiência (uma softmeta, por ser algo impossível de se medir com precisão, assim como as próprias facilidade de leitura e escrita). Foram apresentadas dicas para essa "sintonia fina", contrapondo economia de espaço e economia de tempo (computacionais) e também facilidade de leitura e de escrita.

     

    Pós-condição:

    Aprendemos mais sobre o equilíbrio entre o uso de espaço e tempo computacionais e também sobre a facilidade de leitura e escrita, ou seja, podemos dizer que, aplicando o que foi aprendido, seremos capazes de escrever códigos mais eficientes.

     

    Autores: Fabio Pereira e Marco Antonio
    Data: 27/03/2006
    Contém: 1 página html

    Resumo: Aulas 1, 2 e 3

    March 25, 2006

    Versão 1.1

     

    Neste documento, será apresentada uma versão resumida das aulas 1, 2 e 3 de Engenharia de Software em tópicos. Antes de cada tópico, haverá uma pré-condição, que é necessária para que se possa entender o conteúdo
    da aula. Após cada tópico, será apresentada uma pós-condição que representa o
    efeito surtido pela aula (tópico).

     

    Pré-condição:

    A única pré-condição para esta aula é ter sido aprovado na matéria Programação em Ponto Grande ou a equivalente Programação
    Modular.

    • Aula 1: Nesta aula, foi dito um pouco sobre o que é a matéria de Engenharia de software, como ela será dada e
      cobrada na disciplina. Ao final da aula, foi pedido para que fosse pesquisado o
      nome Edward Yourdon. O resultado da pesquisa foi:

    Edward Yourdon, presidente da Cutter Consortium, é mundialmente conhecido por ser o líder no desenvolvimento dos métodos estruturados de análise/design na década de 70.
    Yourdon foi também co-desenvolvedor do método Yourdon/Whitehead para orientação a objeto (OO) em
    análise/design e da popular métodologia Coad/Yourdon.
     
     
     

    Pós-condição:

    Após a aula, tivemos conhecimento sobre a disciplina e como ela seria dada e cobrada, uma leve introdução à engenharia de software.
    Finalizamos esse tópico com o conhecimento de uma personalidade da engenharia de
    software, Edward Yourdon.

     

    Pré-condição:

    Esta aula não requereu nenhuma pré-condição especial.

    • Aula 2: Esta aula introduziu alguns conceitos
      novos e importantes como: Meta, Soft-meta, Tarefa, Correlação, Contribuição, a
      diferença entre tópico e tipo em engenharia de software. Foram feitos alguns
      exercícios e mostrados alguns exemplos. Também foram sugeridas ferramentas
      existentes para se trabalhar com esses conceitos como o V-Graph.

    Pós-condição:

    Após essa aula, aprendemos conceitos importantes de engenharia de software que nos ajudarão a entender e projetar requisitos melhores. Além disso, sabemos que podemos contar com ferramentas auxiliares
    para nos ajudar nessa tarefa.

     

    Pré-condição:

    Ter assistido alguma aula anterior para que possa se ter uma idéia dos conceitos de engenharia de software.

    • Aula 3: Na terceira aula, foram introduzidos conceitos como
      disciplina e processo criativo. Foi dito que o desenvolvimento de software é
      um processo cooperativo que precisa tanto de disciplina quanto de
      criatividade. Foi descrita, detalhadamente, a Regra de Disciplina para
      Documentos que será utilizada daqui para frente em todos os documentos produzidos na disciplina. Essas regras não serão descritas aqui pois constam do blog da disciplina. Ao final da aula, foi pedido que se pesquisasse sobre
      Watts Humphrey. O resultado da pesquisa foi o seguinte:

     
    Watts Humphrey foi membro do Software Engineering Institute (SEI), vice-presidente na IBM e fundou o programa de processo de software no SEI. Ele introduziu as disciplinas de Processo de Software
    Pessoal (PSP) e Processo de Software em equipe (TSP).
    Watts também escreveu livros sobre Capability Maturity Model (CMM), PSP e TSP. Em 2005, Watts foi condecorado com a medalha nacional de tecnologial.
     
     

    Pós-condição:

    Conhecemos mais uma personalidade importante na engenharia de software, entendemos a necessidade de ter disciplina e os benefícios que
    os processos criativos podem prover. Além disso, a partir deste momento em que
    tomamos conhecimento das Regras de Disciplina para Documentos, teremos que
    produzir um documento semelhante a esse a cada 3 aulas.

    Autores: Fabio Pereira e Marco Antonio

    Data: 23/03/2006

    Contém: 1 página html