Só para descansar a vista.Aproveite.
quarta-feira, julho 26, 2006
terça-feira, junho 20, 2006
quinta-feira, junho 01, 2006
Nova versão das regras
Essa nova versão procura abordar o que falamos na penúltima aula.
Há um novo conceito de término. Para terminar o jogador deve ter X componentes, conforme o determinado na informações de projeto.
As cartas de artefatos passam a ter duas cores (verso) brancas e cinzas.
Enfim, ...
Leiam. É um rascunho de trabalho.
jcl
Há um novo conceito de término. Para terminar o jogador deve ter X componentes, conforme o determinado na informações de projeto.
As cartas de artefatos passam a ter duas cores (verso) brancas e cinzas.
Enfim, ...
Leiam. É um rascunho de trabalho.
jcl
segunda-feira, maio 29, 2006
Artigo de Refactoring
O artigo de refactoring "Evolving Object-Oriented Designs with Refactorings" de Tokuda e Batory pode ser encontrado aqui.
Estou um pouco atrasado com a Versão 1.0, mas amanhã (Terça) ela
estará disponível.
Estou um pouco atrasado com a Versão 1.0, mas amanhã (Terça) ela
estará disponível.
segunda-feira, maio 22, 2006
Versão 0.0
Regras do Jogo
Objetivo do jogo:
Os jogadores competem para terminar um projeto de software. É vencedor quem consegue completar o projeto primeiro.
Através do jogo os jogadores aprendem conceitos de engenharia de software, sob a ótica de evolução.
Peças do Jogo:
Cartas, tabuleiro, projeto, dado.
São os seguintes os tipos de cartas:
1. engenheiros de software (cartas que descrevem típicos engenheiros de software). Essas cartas são o principal recurso que o jogador terá para terminar o jogo. São os engenheiros de software que produzem os artefatos, que são necessários para se cumprir o projeto.
2. problemas, cartas que descrevem problemas clássicos de engenharia de software resultantes de falhas no processo de produção. Essas cartas são utilizadas, para criar obstáculos ao progresso dos engenheiros de software dos outros jogadores.
3. conceitos, cartas que descrevem boas práticas de engenharia de software. Essas cartas podem ser utilizadas pelos jogadores para avançarem face ao seu objetivo.
4. artefatos, cartas que simbolizam os artefatos produzidos. Esses artefatos podem variar em graus de qualidade. Através da composição dos artefatos um jogador será o vencedor assim que cumprir o determinado no projeto.
O tabuleiro é uma área onde cada jogador coloca seus engenheiros de software em colunas.
O projeto é escolhido aleatoriamente de uma série de projetos padrão, que determinam uma série de condições sobre como compor o produto final, bem como descrevem os recursos disponíveis.
Visão Geral:
Podem jogar de 4 a 9 jogadores.
Os jogadores sentam-se na mesa de jogo. Cada jogador deve ter um espaço próximo a si para montar seu tabuleiro de jogo. Um projeto é sorteado do conjunto de projetos. As informações desse projeto devem ficar visíveis a todos os jogadores (sugere-se que o projeto fique no centro da mesa).
As cartas são separadas em três montes: um para as cartas engenheiros de software, outro para as cartas de problemas e conceitos e outro para as cartas de artefatos. Essas cartas deverão estar viradas.
Com o dado escolhe-se quem começa o jogo. O jogo deve prosseguir no sentido horário.
O jogador da vez joga o dado e de acordo com o número tirado retira tantas cartas quantas as indicadas pelo dado de dois dos montes a sua escolha. Dessas, o jogador seleciona 2 de cada monte e descarta as outras. O descarte significa que as cartas rejeitadas retornam ao monte na parte inferior. Caso o jogador tenha tirado o número 1 ele joga o dado novamente. Caso o jogador tenha tirado o número 2, não haverá descarte.
Exemplo: É a vez de Maria. Ela joga o dado. O número tirado é 4. Maria seleciona dois montes; que podem ser: engenheiros e artefatos ou engenheiros e problemas/conceitos ou artefatos e problemas/conceitos. De cada um ela retira 4 cartas (já que o dado indicou 4). Escolhe, segundo sua estratégia de jogo e os limites impostos pelo projeto, duas cartas de cada monte. Se as cartas forem de problemas/conceitos, ela as guarda na sua mão. Se as cartas forem de engenheiros ela coloca-os no tabuleiro. Se as cartas forem de artefatos ela coloca-as na coluna do engenheiro de software escolhido para ser o responsável por aquele artefato. Claro que Maria só pode descartar as cartas de artefatos se tiver colocado no tabuleiro seus engenheiros de software.
Ao fim de sua jogada. O jogador está apto a receber dos seus adversários as cartas de problemas. Ele pode receber cartas de problemas dos 3 jogadores que jogaram imediatamente antes dele. Claro, que na primeira jogada esse caso não ocorrerá, já que ninguém jogou ainda. Cada um dos 3 jogadores pode colocar um obstáculo para o jogador da vez. As cartas de problemas recebidas, ou alteram diretamente o estado do tabuleiro do jogador ou devem ser guardadas. O conteúdo das cartas deve ser lido em voz alta pelo jogador que coloca o obstáculo. Cabe a todos os outros jogadores prestarem atenção aos efeitos do problema ocorrido.
As cartas de conceito devem ficar na mão do jogador e podem ser utilizadas quando lhe convier, segundo sua estratégia. Elas poderão ser utilizadas, por exemplo, para evitar uma carta de problema, ou poderão ser usadas para aumentar a produtividade da equipe de engenheiros de software.
Abaixo, vai uma primeira tentativa de mostrar a dinâmica do jogo usando a técnica de léxico e cenários (parcialmente). Vide mais informações aqui e aqui.
Título: Primeira jogada
Objetivo: Dar início ao jogo
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogadores
Recursos: dado, cartas, informações do projeto
Episódio:
Jogador lança dado.
Se dado igual a 1, então jogador lança dado. Restrição: jogador só prossegue após tirar número diferente de 1.
Jogador escolhe combinação de montes.
Jogador escolhe 2 cartas de cada monte. Restrição: jogador deve respeitar as condições do projeto e usar estratégia de jogo.
Se carta é do tipo engenheiros de software então jogador monta tabuleiro.
Se carta é do tipo conceitos ou problemas jogador guarda cartas.
Se carta é do tipo artefato então jogador atribui artefato a um engenheiro de software. Restrição: jogador só pode fazer isso se tiver o tabuleiro com os engenheiros de software.
Jogo
Noção: Entretenimento entre jogadores.
Objetiva simular um projeto de software com caráter educativo.
É composto de tabuleiro, dado, cartas, mesa e informações de projeto
Impacto: Jogam de 4 a 9 jogadores.
O jogo é iniciado com a escolha do primeiro jogador.
O jogo termina quando um jogador completa o projeto.
Informações do projeto (...)
Mesa (...)
Jogador / Jogadores (...)
Dado (...)
Objetivo do jogo:
Os jogadores competem para terminar um projeto de software. É vencedor quem consegue completar o projeto primeiro.
Através do jogo os jogadores aprendem conceitos de engenharia de software, sob a ótica de evolução.
Peças do Jogo:
Cartas, tabuleiro, projeto, dado.
São os seguintes os tipos de cartas:
1. engenheiros de software (cartas que descrevem típicos engenheiros de software). Essas cartas são o principal recurso que o jogador terá para terminar o jogo. São os engenheiros de software que produzem os artefatos, que são necessários para se cumprir o projeto.
2. problemas, cartas que descrevem problemas clássicos de engenharia de software resultantes de falhas no processo de produção. Essas cartas são utilizadas, para criar obstáculos ao progresso dos engenheiros de software dos outros jogadores.
3. conceitos, cartas que descrevem boas práticas de engenharia de software. Essas cartas podem ser utilizadas pelos jogadores para avançarem face ao seu objetivo.
4. artefatos, cartas que simbolizam os artefatos produzidos. Esses artefatos podem variar em graus de qualidade. Através da composição dos artefatos um jogador será o vencedor assim que cumprir o determinado no projeto.
O tabuleiro é uma área onde cada jogador coloca seus engenheiros de software em colunas.
O projeto é escolhido aleatoriamente de uma série de projetos padrão, que determinam uma série de condições sobre como compor o produto final, bem como descrevem os recursos disponíveis.
Visão Geral:
Podem jogar de 4 a 9 jogadores.
Os jogadores sentam-se na mesa de jogo. Cada jogador deve ter um espaço próximo a si para montar seu tabuleiro de jogo. Um projeto é sorteado do conjunto de projetos. As informações desse projeto devem ficar visíveis a todos os jogadores (sugere-se que o projeto fique no centro da mesa).
As cartas são separadas em três montes: um para as cartas engenheiros de software, outro para as cartas de problemas e conceitos e outro para as cartas de artefatos. Essas cartas deverão estar viradas.
Com o dado escolhe-se quem começa o jogo. O jogo deve prosseguir no sentido horário.
O jogador da vez joga o dado e de acordo com o número tirado retira tantas cartas quantas as indicadas pelo dado de dois dos montes a sua escolha. Dessas, o jogador seleciona 2 de cada monte e descarta as outras. O descarte significa que as cartas rejeitadas retornam ao monte na parte inferior. Caso o jogador tenha tirado o número 1 ele joga o dado novamente. Caso o jogador tenha tirado o número 2, não haverá descarte.
Exemplo: É a vez de Maria. Ela joga o dado. O número tirado é 4. Maria seleciona dois montes; que podem ser: engenheiros e artefatos ou engenheiros e problemas/conceitos ou artefatos e problemas/conceitos. De cada um ela retira 4 cartas (já que o dado indicou 4). Escolhe, segundo sua estratégia de jogo e os limites impostos pelo projeto, duas cartas de cada monte. Se as cartas forem de problemas/conceitos, ela as guarda na sua mão. Se as cartas forem de engenheiros ela coloca-os no tabuleiro. Se as cartas forem de artefatos ela coloca-as na coluna do engenheiro de software escolhido para ser o responsável por aquele artefato. Claro que Maria só pode descartar as cartas de artefatos se tiver colocado no tabuleiro seus engenheiros de software.
Ao fim de sua jogada. O jogador está apto a receber dos seus adversários as cartas de problemas. Ele pode receber cartas de problemas dos 3 jogadores que jogaram imediatamente antes dele. Claro, que na primeira jogada esse caso não ocorrerá, já que ninguém jogou ainda. Cada um dos 3 jogadores pode colocar um obstáculo para o jogador da vez. As cartas de problemas recebidas, ou alteram diretamente o estado do tabuleiro do jogador ou devem ser guardadas. O conteúdo das cartas deve ser lido em voz alta pelo jogador que coloca o obstáculo. Cabe a todos os outros jogadores prestarem atenção aos efeitos do problema ocorrido.
As cartas de conceito devem ficar na mão do jogador e podem ser utilizadas quando lhe convier, segundo sua estratégia. Elas poderão ser utilizadas, por exemplo, para evitar uma carta de problema, ou poderão ser usadas para aumentar a produtividade da equipe de engenheiros de software.
Abaixo, vai uma primeira tentativa de mostrar a dinâmica do jogo usando a técnica de léxico e cenários (parcialmente). Vide mais informações aqui e aqui.
Título: Primeira jogada
Objetivo: Dar início ao jogo
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogadores
Recursos: dado, cartas, informações do projeto
Episódio:
Jogador lança dado.
Se dado igual a 1, então jogador lança dado. Restrição: jogador só prossegue após tirar número diferente de 1.
Jogador escolhe combinação de montes.
Jogador escolhe 2 cartas de cada monte. Restrição: jogador deve respeitar as condições do projeto e usar estratégia de jogo.
Se carta é do tipo engenheiros de software então jogador monta tabuleiro.
Se carta é do tipo conceitos ou problemas jogador guarda cartas.
Se carta é do tipo artefato então jogador atribui artefato a um engenheiro de software. Restrição: jogador só pode fazer isso se tiver o tabuleiro com os engenheiros de software.
Jogo
Noção: Entretenimento entre jogadores.
Objetiva simular um projeto de software com caráter educativo.
É composto de tabuleiro, dado, cartas, mesa e informações de projeto
Impacto: Jogam de 4 a 9 jogadores.
O jogo é iniciado com a escolha do primeiro jogador.
O jogo termina quando um jogador completa o projeto.
Informações do projeto (...)
Mesa (...)
Jogador / Jogadores (...)
Dado (...)
Regras do Jogo
Estou um pouco atrasado com a versão 0.0. Devo postar ainda hoje.
No entanto, o Eduardo avançou no trabalho. Por favor, dêem uma olhada no blog dele (aí do lado).
Obrigado.
No entanto, o Eduardo avançou no trabalho. Por favor, dêem uma olhada no blog dele (aí do lado).
Obrigado.
quinta-feira, maio 11, 2006
Nova versão das Instruções
Temos uma versão 3.0 das instruções. Creio que podemos congela-la, tendo em vista que agora vamos partir
para as instruções do novo jogo.
Lembrem do combinado. Vamos utilizar o "blog" para colocarmos nossas idéias sobre como deveria ser o novo jogo.
Na próxima Segunda vamos ter como objetivo sair com uma versão 0.0 do novo jogo. Estaremos trabalhando em um nível mais alto de abstração, isto é estaremos tratando das regras gerais e da dinâmica do jogo.
Creio que ficou concordado que o jogo teria de 4 a 9 participantes. Certo?
para as instruções do novo jogo.
Lembrem do combinado. Vamos utilizar o "blog" para colocarmos nossas idéias sobre como deveria ser o novo jogo.
Na próxima Segunda vamos ter como objetivo sair com uma versão 0.0 do novo jogo. Estaremos trabalhando em um nível mais alto de abstração, isto é estaremos tratando das regras gerais e da dinâmica do jogo.
Creio que ficou concordado que o jogo teria de 4 a 9 participantes. Certo?
Novo Artigo para Leitura
Aqui vai um artigo recente do Journal of Software Maintenance and Evolution, seu título é Towards a taxonomy of software change.
Vejamos o quanto ele pode ser útil no nosso trabalho.
Vejamos o quanto ele pode ser útil no nosso trabalho.
Espaço de Produto x Espaço de Versão
O artigo que recomendei centra sua análise no espaço de produto e no espaço de versão. Comentei na última reunião que a gerência de configuração é uma combinação desses espaços.
Nessa combinação influem diversos fatores, mas principalmente:
a) a base representacional do espaço de produto: o que efetivamente é guardado na configuração, o esquema proposto no artigo é simples, apesar de bastante eficaz (árvores E/OU). Lembrei que pode haver necessidade de outros tipos de esquema, como por exemplo, quando é necessário anotações extras como a justificativa de porque uma ligação existe.
b) a versão é normalmente um conceito aplicado a um elemento, mas a agregação desses elementos, um produto, também é alvo de diferentes versões.
c) a granularidade do que está sob controle, e
d) a transformação de elementos que podem deixar de existir ou agregar-se, total ou parcialmente, a outros elementos.
O sistema de informação para tratar da gerência de configuração é um sistema não trivial, e é tanto mais complexo, quanto maior for o nível de granularidade e do controle necessário.
Portanto, não deixem de ler o referido artigo. Se acharem um melhor, me digam, mas esse é o que me parece tratar de maneira mais detalhada dos princípios básicos de um sistema desse tipo.
Nessa combinação influem diversos fatores, mas principalmente:
a) a base representacional do espaço de produto: o que efetivamente é guardado na configuração, o esquema proposto no artigo é simples, apesar de bastante eficaz (árvores E/OU). Lembrei que pode haver necessidade de outros tipos de esquema, como por exemplo, quando é necessário anotações extras como a justificativa de porque uma ligação existe.
b) a versão é normalmente um conceito aplicado a um elemento, mas a agregação desses elementos, um produto, também é alvo de diferentes versões.
c) a granularidade do que está sob controle, e
d) a transformação de elementos que podem deixar de existir ou agregar-se, total ou parcialmente, a outros elementos.
O sistema de informação para tratar da gerência de configuração é um sistema não trivial, e é tanto mais complexo, quanto maior for o nível de granularidade e do controle necessário.
Portanto, não deixem de ler o referido artigo. Se acharem um melhor, me digam, mas esse é o que me parece tratar de maneira mais detalhada dos princípios básicos de um sistema desse tipo.
sexta-feira, maio 05, 2006
Versão 2.0 das Regras
Desculpem o atraso. Aqui vai a versão 2.o. Leiam e comentem até Terça (no máximo até as 12 horas), para que eu possa gerar a versão 3.0.
Vale lembrar que é bom ir pensando sobre os cartões e sobre o que queremos mudar. Por exemplo: para evolução documentos são importantes, e devem estar claros, mas principalmente eles devem poder ser "rastreados", isto é devem deixar uma trilha.
Lembrem das leis de evolução e das noções de gerencia de configuração (mudanças).
Vale lembrar que é bom ir pensando sobre os cartões e sobre o que queremos mudar. Por exemplo: para evolução documentos são importantes, e devem estar claros, mas principalmente eles devem poder ser "rastreados", isto é devem deixar uma trilha.
Lembrem das leis de evolução e das noções de gerencia de configuração (mudanças).
terça-feira, abril 25, 2006
Configuração de Trabalho
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.
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.
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).
terça-feira, março 28, 2006
Retro-Alimentação
Fiz dois comentários sobre notas do Eduardo e da Glória.
Vou listar as duas abaixo, mas vejam que existem um redundância na resposta. Enfim o mesmo
problema, mas com respostas diferentes.
Eduardo,
O ponto, aqui, é a discussão se o porte para outra plataforma aumenta a funcionalidade. Sob a ótica funcional me parece que a base de funções oferecidas permanece a mesma, apenas pode-se usar outra plataforma. No entanto, no caso de uma plataforma móvel, poderia-se argumentar que a mobilidade oferecida aumenta a funcionalidade do todo, ou seja um sistema fixo passa a ser móvel. No entanto, me parece que a visão mais correta seja a de que houve uma adição de caractéristica ao sistema. Esta adição sendo fruto de uma demanda externa caracteriza o "feedback loop".
Glória,
O ponto que ressaltei foi o que trata da diferença entre aspectos funcionais e não funcionais.
Por exemplo: plataforma móveis, exigem um esforço de minituarização.
Isso deve ser visto como um "feedback" negativo na medida que representa uma reorganização do software (código), mas representa um aumento de "funcionalidade" sob a ótica de que agora o artefato é também móvel e portanto mais "funcional".
Enfim...
Vou listar as duas abaixo, mas vejam que existem um redundância na resposta. Enfim o mesmo
problema, mas com respostas diferentes.
Eduardo,
O ponto, aqui, é a discussão se o porte para outra plataforma aumenta a funcionalidade. Sob a ótica funcional me parece que a base de funções oferecidas permanece a mesma, apenas pode-se usar outra plataforma. No entanto, no caso de uma plataforma móvel, poderia-se argumentar que a mobilidade oferecida aumenta a funcionalidade do todo, ou seja um sistema fixo passa a ser móvel. No entanto, me parece que a visão mais correta seja a de que houve uma adição de caractéristica ao sistema. Esta adição sendo fruto de uma demanda externa caracteriza o "feedback loop".
Glória,
O ponto que ressaltei foi o que trata da diferença entre aspectos funcionais e não funcionais.
Por exemplo: plataforma móveis, exigem um esforço de minituarização.
Isso deve ser visto como um "feedback" negativo na medida que representa uma reorganização do software (código), mas representa um aumento de "funcionalidade" sob a ótica de que agora o artefato é também móvel e portanto mais "funcional".
Enfim...
quarta-feira, março 22, 2006
Material de Evolução
O material da turma de 2002-1 está disponível na página do curso.
Dêem uma olhada.
Dêem uma olhada.
Próximo Artigo
"What Netscape learned from cross-platform software development". Nossa leitura desse artigo de Cusumano deve ser comparativa com o que lemos de Lehman e com as críticas de Scacchi. O elo fornecido é da ACM, no portal Capes temos acesso a esse artigo.
quinta-feira, março 16, 2006
As Leis da Evolução de Software
Conforme discutimos em aula, as leis de Lehman, sumarizadas abaixo, são fundamentalmente centradas no conceito de retro-alimentação.
Vale também lembrar que essas leis são válidas para software que não podem ser considerados sistemas fechados, ou seja simples programas que tem especificação bem definida e que portanto podem ser verificados formalmente, se essa especificação for socialmente aceita como completa. Vejam exemplos desse tipo de software (chamado por Lehman de S-type) aqui e aqui.
As leis de Lehman, apresentadas a seguir, foram traduzidas do artigo Rules and Tools for Software Evolution Planning and Management (a tradução usou partes da tradução feita por Roberto Holanda de outro artigo de Lehman e usou o termo software em substituição a E-type Software):
I - Mudança contínua.
Um software deve ser continuamente adaptado, caso contrário se torna progressivamente menos satisfatório.
II - Complexidade crescente.
À medida que um software é alterado, sua complexidade cresce, a menos que um trabalho seja feito para mantê-la ou diminuí-la.
III - Auto-regulação.
O processo de evolução de software é auto-regulado próximo à distribuição normal com relação às medidas dos atributos de produtos e processos.
IV - Conservação da estabilidade organizacional .
A não ser que mecanismos de retro-alimentação tenham sido ajustados de maneira apropriada, a taxa media de atividade global efetiva num software em evolução tende a ser manter constante durante o tempo de vida do produto.
V - Conservação da Familiaridade.
De maneira geral, a taxa de crescimento incremental e taxa crescimento a longo prazo tende a declinar.
VI - Crescimento contínuo.
O conteúdo funcional de um software deve ser continuamente aumentado durante seu tempo de vida para para manter a satisfação do usuário.
VII - Qualidade decrescente.
A qualidade do software será entendida como declinante a menos que o software seja rigorosamente adaptado às mudanças no ambiente operacional.
VIII - Sistema de Retro-alimentação.
Processos de evolução de software são sistemas de retro-alimentação em múltiplos níves, em múltiplos laços (loops) e envolvendo múltiplos agentes.
A próxima leitura pode ser encontrada aqui.
terça-feira, março 07, 2006
Bem-vindo
Aqui estaremos postando notícias, resumos e elos para consumo de nossa disciplina de Evolução de Software.
Recomendo a leitura de um breve resumo que fiz em 1997 e de uma entrada recente no meu blog.
O desenho inicial do curso, toma por base esse blog. Cada um de vocês deverá também ter um blog.
Comentários são muito bem vindos!
O primeiro encontro será para que possamos tentar traçar uma linha de interesse mais sintonizada com cada um de vocês. Vamos ver como funcionará.
As duas primeiras leituras são:
1) Laws of Software Evolution Revisited, e
2) Rules and Tools for Software Evolution Planning and Management
Na próxima Terça (dia 14) discutiremos esse dois artigos.
Recomendo a leitura de um breve resumo que fiz em 1997 e de uma entrada recente no meu blog.
O desenho inicial do curso, toma por base esse blog. Cada um de vocês deverá também ter um blog.
Comentários são muito bem vindos!
O primeiro encontro será para que possamos tentar traçar uma linha de interesse mais sintonizada com cada um de vocês. Vamos ver como funcionará.
As duas primeiras leituras são:
1) Laws of Software Evolution Revisited, e
2) Rules and Tools for Software Evolution Planning and Management
Na próxima Terça (dia 14) discutiremos esse dois artigos.
Assinar:
Postagens (Atom)