Como a Glória mencionou, vamos ter que estabelecer o padrão de como trataremos o artefato que evoluirá.
A princípio os cartões serão os átomos, mas isso ainda precisa ser melhor discutido. Partiremos de NIC (número de identificação de cartões).
Vamos procurar manter sintonia com a notação do artigo anterior (vide resumo da Cidiane).
Está claro o sentido da evolução/ mudança: tradução e adaptação.
Falta deixar claro o processo de evolução a ser utilizado, que será baseado em um sistema de GC.
terça-feira, abril 25, 2006
sexta-feira, abril 07, 2006
Gerência de Configuração
Aula de 11/4
Nossa agenda passa por 3 pontos.
O primeiro é uma breve introdução à gerência de configuração. Como salientei na explicação do conceito de baseline o tema gerência de configuração é de fundamental importância.
Devemos começar a ler o artigo, Version Models For Software Configuration Management, que trata de aspectos básicos ligados a configuração e controle de versão. Discutiremo esse artigo na aula de 18/4 e na aula de 25/4.
Na introdução do tema, tenho ensinado que gerência de configuração, nada mais é do que saber que partes estão compondo um todo, num determinado ponto no espaço temporal. Isso é muito usado em processos fabris que, para a fabricação de um determinado produto, precisa que suas máquinas estejam alinhadas segundo uma determinada configuração. Por exemplo, numa fábrica de artefatos plásticos essa noção é importante, porque uma mesma instalação fabril pode produzir diferentes artefatos, o que muda é a configuração empregada para cada produto. Como não tenho nada mais detalhado disponível, no momento, vou utilizar duas fontes da internet. Uma mais geral vem de um instituto de configuração nos EUA e outra é um artigo de André Dias da empresa Pronus.
O segundo ponto é pensar como faremos o planejamento do trabalho da disciplina. Nesse contexto gostaria de discutir o artigo Four Interesting Ways in Which History Can Teach Us About Software. Achei esse artigo na página de Michael Godfrey, o que escreveu o artigo usado na dissertação do Roberto sobre o crescimento super-linear do Lynux. Godfrey é professor de Waterloo e seu curso de evolução está na Web. Certamente iremos reutilizar alguns dos recursos lá listados.
O terceiro é decidir sobre o tema do nosso trabalho. No momento tenho os seguintes candidatos:
1) Continuar o estudo da evolução do C&L. Nesse caso estaríamos utilizando o material de 2002-1 e o trabalho de re-engenharia do C&L que vem sendo conduzido num projeto de IC com o aluno Rodrigo Buás. O Rodrigo fez uma nova arquitetura baseada numa infra-estrutura geral que pode ser instanciada para diferentes aplicações e utilizará essa infra-estrutura para construir o C&L. A arquitetura segue o padrão arquitetural de 3 níveis (Interface, Aplicação, Repositório). Aqui os estudos estariam mais ligados a analise do repositório do código e o produto seria uma série de estatísticas e avaliações qualitativas, bem como material de apoio (documentos)
2) Centrar o estudo na evolução de cenários, nesse caso tomando por base uma série de cenários desenvolvida por uma turma de Engenharia de Requisitos de 2005-1 que foi parcialmente modificada por uma turma de Princípios de Engenharia de Software de 2005-2. Aqui o objetivo é produzir uma nova versão de cenários a nível de especificação (ou arquitetura ?) e um registro de como foi feita a evolução.
3) Estudar o jogo criado na Universidade da Califórnia, Irvine para facilitar o aprendizado da Engenharia de Software. Nesse caso teríamos como produto final não só um novo jogo em Português, como o próprio registro de como foi sua evolução.
Nossa agenda passa por 3 pontos.
O primeiro é uma breve introdução à gerência de configuração. Como salientei na explicação do conceito de baseline o tema gerência de configuração é de fundamental importância.
Devemos começar a ler o artigo, Version Models For Software Configuration Management, que trata de aspectos básicos ligados a configuração e controle de versão. Discutiremo esse artigo na aula de 18/4 e na aula de 25/4.
Na introdução do tema, tenho ensinado que gerência de configuração, nada mais é do que saber que partes estão compondo um todo, num determinado ponto no espaço temporal. Isso é muito usado em processos fabris que, para a fabricação de um determinado produto, precisa que suas máquinas estejam alinhadas segundo uma determinada configuração. Por exemplo, numa fábrica de artefatos plásticos essa noção é importante, porque uma mesma instalação fabril pode produzir diferentes artefatos, o que muda é a configuração empregada para cada produto. Como não tenho nada mais detalhado disponível, no momento, vou utilizar duas fontes da internet. Uma mais geral vem de um instituto de configuração nos EUA e outra é um artigo de André Dias da empresa Pronus.
O segundo ponto é pensar como faremos o planejamento do trabalho da disciplina. Nesse contexto gostaria de discutir o artigo Four Interesting Ways in Which History Can Teach Us About Software. Achei esse artigo na página de Michael Godfrey, o que escreveu o artigo usado na dissertação do Roberto sobre o crescimento super-linear do Lynux. Godfrey é professor de Waterloo e seu curso de evolução está na Web. Certamente iremos reutilizar alguns dos recursos lá listados.
O terceiro é decidir sobre o tema do nosso trabalho. No momento tenho os seguintes candidatos:
1) Continuar o estudo da evolução do C&L. Nesse caso estaríamos utilizando o material de 2002-1 e o trabalho de re-engenharia do C&L que vem sendo conduzido num projeto de IC com o aluno Rodrigo Buás. O Rodrigo fez uma nova arquitetura baseada numa infra-estrutura geral que pode ser instanciada para diferentes aplicações e utilizará essa infra-estrutura para construir o C&L. A arquitetura segue o padrão arquitetural de 3 níveis (Interface, Aplicação, Repositório). Aqui os estudos estariam mais ligados a analise do repositório do código e o produto seria uma série de estatísticas e avaliações qualitativas, bem como material de apoio (documentos)
2) Centrar o estudo na evolução de cenários, nesse caso tomando por base uma série de cenários desenvolvida por uma turma de Engenharia de Requisitos de 2005-1 que foi parcialmente modificada por uma turma de Princípios de Engenharia de Software de 2005-2. Aqui o objetivo é produzir uma nova versão de cenários a nível de especificação (ou arquitetura ?) e um registro de como foi feita a evolução.
3) Estudar o jogo criado na Universidade da Califórnia, Irvine para facilitar o aprendizado da Engenharia de Software. Nesse caso teríamos como produto final não só um novo jogo em Português, como o próprio registro de como foi sua evolução.
segunda-feira, abril 03, 2006
Aula de 4/4
Desculpem a demora. Como tinha mencionado a leitura para a aula de amanhã é menos trabalhosa. São 12 páginas em espaço duplo e revendo, mais uma vez, as leid de evolução.
Estou indicando a leitura do Cápitulo 3 da dissertação de mestrado do Roberto Holanda, mais especificamente as páginas (36 -- 44).
Estou indicando a leitura do Cápitulo 3 da dissertação de mestrado do Roberto Holanda, mais especificamente as páginas (36 -- 44).
Assinar:
Postagens (Atom)