Novamente foi difícil deixar de falar do produto e concentrar no processo de evolução. No entanto creio que as discussões foram apropriadas e conseguimos chegar a uma conclusão importante: temos mais confiança na dinâmica do jogo. A idéia de duas rodadas ficou consolidada.
Os ajustes as regras já codificadas através de léxico e de cenários são pontuais. A Milene fez uma observação importante: o jogador que leu as regras foi o que menos dúvida teve e que demonstrou uma melhor estratégia.
Foi excelente também o momento de desenho coletivo. A partir das propostas da Milene, com o tabuleiro de movimentos e muita discussão usando um estilo de reunião do tipo “brainstorming”, conseguimos produzir um desenho que creio ser muito bom.
As mudanças foram: produz e inspeciona na mesma rodada, o resultado da inspeção é a troca por artefato de mesmo tipo, não inspecionado. Os problemas podem ser distribuídos para dois adversários. Um jogador terá no máximo dois problemas permanentes.
Foi lembrado que os engenheiros de software: filho do chefe e Paula trazem um toque de humor ao jogo.
O grupo concordou que é necessária uma revisão das cartas de problemas e de conceitos.
Ficou acertado que produziremos a monografia usando o seguinte esquema:
a) Introdução – introdução a idéia de evolução de software com ênfase em: leis de lehman, refatoração e gerência de configuração.
b) Histórico – relato sobre o que fizemos ao longo do semestre, um texto de preferência organizado cronologicamente.
c) Produto – descrição do produto que produzimos com ênfase principal na última versão dos cenários e do léxico representativo das regras. Aqui também estaremos apontando as 8 cartas escolhidas por vocês para serem retiradas ou modificadas. Também listaremos 3 sugestões de cartas por cada um de vocês.
d) Análise da Evolução – a análise será centrada na identificação por cada um de vocês de 3 tipos de refatoração na evolução dos cenários (fizemos 5 versões), e de pelo menos 2 padrões de descrição de cenários. Cada um comentará a experiência e a dificuldade da gerência de configuração dos conjuntos de versões. A análise da evolução deve fazer uso de rastros para os documentos originais utilizados.
e) Conclusão – a conclusão será focada nas leis de lehman e como as observamos elas ocorrerem durante o exercício de evolução de que participamos.
A aula do dia 4 discutirá essa conclusão.
Não esqueci: lembrem do que falei. É preciso ter paciência e procurar ir ajudando na medida do possível. Não deixem de ler: O Povo Brasileiro: A formação e o sentido do Brasil de Darcy Ribeiro.
quinta-feira, junho 21, 2007
quinta-feira, junho 14, 2007
Aulas: 14, 15 e 16
Progredimos no jogo. A aula 15, diferente do planejado, ainda teve como tema a evolução dos cenários e da discussão das cartas de problemas. Em função disso distribuimos o trabalho para termos o primeiro teste com "outros", ou seja o envolvimento de jogadores não diretamente relacionados com a evolução do jogo.
Entre a aula 15 e a aula de ontem, 16, fizemos um bom trabalho. Terminamos as novas cartas de problemas e fizemos duas versões de regras: uma com o uso de léxico e cenários e outra com o uso de texto e cenários.
O jogo de ontem, aula 16, em duas sessões, comprovou que estamos no caminho certo. O jogo está mais dinâmico, mais fácil de explicar e posso dizer: entusiasma quem joga. É um ótimo resultado.
No entanto, creio que precisamos repensar o papel das cartas de problemas. Sobre a dinâmica: creio que a divisão entre jogadas de ação e de problemas está ok. É uma maneira mais sofisticada de jogar, mas creio mais proveitosa. No entanto, precisamos rediscutir esse tema.
Apesar do esforço que fizemos em formalizar as regras, me parece que elas foram pouco utilizadas. Portanto, não tivemos a oportunidade de ter um "feedback" sobre isso. No entanto, poderemos pedir que os participantes (os "outros") façam uma leitura e crítica após a experiência do jogo.
Entre a aula 15 e a aula de ontem, 16, fizemos um bom trabalho. Terminamos as novas cartas de problemas e fizemos duas versões de regras: uma com o uso de léxico e cenários e outra com o uso de texto e cenários.
O jogo de ontem, aula 16, em duas sessões, comprovou que estamos no caminho certo. O jogo está mais dinâmico, mais fácil de explicar e posso dizer: entusiasma quem joga. É um ótimo resultado.
No entanto, creio que precisamos repensar o papel das cartas de problemas. Sobre a dinâmica: creio que a divisão entre jogadas de ação e de problemas está ok. É uma maneira mais sofisticada de jogar, mas creio mais proveitosa. No entanto, precisamos rediscutir esse tema.
Apesar do esforço que fizemos em formalizar as regras, me parece que elas foram pouco utilizadas. Portanto, não tivemos a oportunidade de ter um "feedback" sobre isso. No entanto, poderemos pedir que os participantes (os "outros") façam uma leitura e crítica após a experiência do jogo.
quarta-feira, maio 30, 2007
Aula 13
Nessa reunião procuramos examinar no detalhe como
os cenários evoluíram desde da Aula 10. Tivemos três versões.
Vimos como é difícil seguir, manualmente, todas as mudanças que ocorreram.
Uma das dificuldades é a definição da granularidade do que é considerado como uma mudança. Já tínhamos falado sobre isso nos comentários do artigo de Gerência de Configuração.
Além disso, creio que ficou evidente a complexidade da tarefa, em face da possibilidade de uma mudança afetar a mais de um cenário.
Vimos também que existem “padrões” no processo de evolução. É exatamente aqui que o trabalho que fizemos na reunião está relacionado aos artigos de re-fatoração e de padrão de cenários.
Na reunião que teremos hoje, onde analisaremos as cartas de conceito e problemas devemos também prestar atenção a como elas evoluíram.
Espero que hoje possamos estar prontos para empacotar a segunda versão do SimulES.
Agenda:
os cenários evoluíram desde da Aula 10. Tivemos três versões.
Vimos como é difícil seguir, manualmente, todas as mudanças que ocorreram.
Uma das dificuldades é a definição da granularidade do que é considerado como uma mudança. Já tínhamos falado sobre isso nos comentários do artigo de Gerência de Configuração.
Além disso, creio que ficou evidente a complexidade da tarefa, em face da possibilidade de uma mudança afetar a mais de um cenário.
Vimos também que existem “padrões” no processo de evolução. É exatamente aqui que o trabalho que fizemos na reunião está relacionado aos artigos de re-fatoração e de padrão de cenários.
Na reunião que teremos hoje, onde analisaremos as cartas de conceito e problemas devemos também prestar atenção a como elas evoluíram.
Espero que hoje possamos estar prontos para empacotar a segunda versão do SimulES.
Agenda:
- Aula 14: hoje dia 30. Como falamos acima.
- Aula 15: dia 6. Discussão dos artigos de refatoração e padrões. Última chance para empacotar versão 2.0. Começo da aplicação dos conceitos dos artigos aos casos de evolução do SimulES.
- Aula 16: dia 13 Uso do Jogo, de preferência com jogadores externos.
- Aula 17: dia 20 Aplicação dos conceitos de refatoração e padrões. Identificação de novas leituras. Começo da escrita de artigo/relatório.
- Aula 18: dia 27 Reunião sobre artigo/relatório.
- Aula 19: dia 4 Reunião sobre relatório. Prazo final para conclusão dos “blogs” individuais.
Aula 11 -- Aula 12
A Milene fez um ótimo trabalho. Vejam aí do lado o que ela
escreveu com base nas duas reuniões de trabalho do grupo.
escreveu com base nas duas reuniões de trabalho do grupo.
segunda-feira, maio 07, 2007
Aula 10
Parabéns para a equipe. Pela primeira vez esse semestre terminamos o jogo.
Corrigi os problemas iniciais da descrição das regras. Certamente ainda existem
outros. Creio que o melhor é evoluir o que está abaixo. Mãos a obra. Lembrem que
é fundamental termos o léxico também!
Título: Dinâmica do SimulES
Objetivo: Descrever as regras do SimulES
Contexto:INICIO DE JOGO.
Atores: jogador
Recursos: dado, cartas, informações do projeto
Episódios:
Jogador da vez inicia turno.
Se jogador puder empacotar o produto, então jogador SUBMETE PRODUTO.
Jogador JOGA RODADA DE AÇÕES.
Jogador JOGA RODADA DE CONCEITOS
Jogador TRATA PROBLEMAS (** é isso mesmo? – falta detalhar).
Título: Inicio de jogo
Objetivo: Descrever os preparativos para inicio do jogo
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo.
Cada jogador tem uma carta de engenheiro de software
Atores: jogador
Recursos: dado, cartas, informações do projeto
Episódios:
Jogador joga dado. Restrição: Maior dado inicia jogo.
Jogador escolhe aleatoriamente do monte de carta de informações de projeto um projeto. Restrição: outros jogadores têm que concordar com carta escolhida por jogador que inicia jogo.
Cada jogador escolhe uma carta de engenheiro de software e coloca-a no tabuleiro.
Título: Joga Rodada de Ações
Objetivo: Descrever as regras da rodada de ações
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogador
Recursos: dado, cartas, informações do projeto
Episódios:
Jogador usa seus Engenheiros de Software em CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE DEFEITO.
Se jogador não usou engenheiros de software então INTEGRA ARTEFATOS EM UM MÓDULO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades podem ser afetadas por cartas de conceito ou carta de problemas.
Jogador lança o dado.
Se dado igual a 1,ou 2 ou 3, então jogador pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.
Se dado igual a 4 ou 5 ou 6, então jogador pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3.
Título: Joga Rodada de Conceitos
Objetivo: Descrever as regras da rodada de conceitos
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido, Todos os jogadores terminaram JOGA RODADA DE AÇÕES
Atores: jogador, concorrente
Recursos: cartas, informações do projeto
Episódios:
Jogador descarta suas cartas de conceito no tabuleiro caso sejam permanentes.
Se jogador tem cartas de engenheiro de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (informado na carta de projeto) colocando-os no tabuleiro.
Jogador descarta cartas, retornando-as aos montes apropriados.
Jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema.
Jogador lê em voz alta o problema que submete ao concorrente.
Título: Recebe cartas
Objetivo: Descrever as regras da rodada de receber cartas
Contexto: Informações do projeto no centro da mesa
Todos os jogadores terminaram JOGA RODADA DE AÇÕES, Jogador recebeu cartas de concorrente
Atores: jogador, concorrente
Recursos: cartas, informações do projeto
Episódios:
Jogador estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador atende a demanda da carta de problema. Restrição: carta de problema pode ser contraposta por carta de conceito.
Se o problema é temporário então jogador descarta a carta de problema.
Se o problema é permanente então jogador mantêm carta. Restrição: carta de problema pode ser contraposta por carta de conceito.
Título: Submete produto
Objetivo: Descrever as regras de submeter produto
Contexto: Informações do projeto no centro da mesa
Jogador acabou de integrar seu último modulo
Atores: jogador, concorrente
Recursos: cartas, informações do projeto, módulos
Episódios:
Jogador mostra que produziu x módulos, de acordo com as informações de projeto. Concorrente (qualquer) escolhe x artefatos (cartas) de qualquer dos módulos, onde x é o nível de qualidade do projeto.
Se artefatos escolhidos (desvirados) forem livres de defeito, então jogador ganha o jogo.
Título: Constrói artefato
Objetivo: Descrever as regras de construir artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito
Atores: jogador
Recursos: cartas, informações do projeto
Episódios:
Jogador, para cada carta de engenheiro de software, escolhe do monte de artefatos os artefatos que podem ser produzidos por aquele engenheiro de software.
Se jogador escolhe carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade da carta de engenheiro de software.
Se o jogador escolhe carta cinza, então o número de cartas é determinado pela metade mais um da complexidade do projeto e pela habilidade da carta engenheiro de software. estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador coloca as cartas escolhidas no tabuleiro de acordo com o jogador e de acordo com o tipo de artefato produzido.
Título: Inspeciona artefato
Objetivo: Descrever as regras para inspecionar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogador
Recursos: cartas, informações do projeto, artefato
Episódios:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a inspeção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a inspeção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é desvirado no tabuleiro.
Título: Corrige artefato
Objetivo: Descrever as regras para corrigir artefatos inspecionados
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos inspecionados ( INSPECIONA ARTEFATO) no tabuleiro
Atores: jogador
Recursos: cartas, informações do projeto, artefato inspecionado
Episódios:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a correção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a correção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é substituído por artefato livre de defeito (carta branca sem defeito).
Título: Integra artefatos em um módulo
Objetivo: Descrever as regras para integrar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogador
Recursos: cartas, informações do projeto
Episódios:
Jogador escolhe módulo do projeto.
Jogador seleciona artefatos do tabuleiro, independente de responsável (engenheiro de software) de acordo com as informações de projeto.
Jogador integra o módulo juntando as cartas em um monte fora do tabuleiro.
Corrigi os problemas iniciais da descrição das regras. Certamente ainda existem
outros. Creio que o melhor é evoluir o que está abaixo. Mãos a obra. Lembrem que
é fundamental termos o léxico também!
Título: Dinâmica do SimulES
Objetivo: Descrever as regras do SimulES
Contexto:INICIO DE JOGO.
Atores: jogador
Recursos: dado, cartas, informações do projeto
Episódios:
Jogador da vez inicia turno.
Se jogador puder empacotar o produto, então jogador SUBMETE PRODUTO.
Jogador JOGA RODADA DE AÇÕES.
Jogador JOGA RODADA DE CONCEITOS
Jogador TRATA PROBLEMAS (** é isso mesmo? – falta detalhar).
Título: Inicio de jogo
Objetivo: Descrever os preparativos para inicio do jogo
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo.
Cada jogador tem uma carta de engenheiro de software
Atores: jogador
Recursos: dado, cartas, informações do projeto
Episódios:
Jogador joga dado. Restrição: Maior dado inicia jogo.
Jogador escolhe aleatoriamente do monte de carta de informações de projeto um projeto. Restrição: outros jogadores têm que concordar com carta escolhida por jogador que inicia jogo.
Cada jogador escolhe uma carta de engenheiro de software e coloca-a no tabuleiro.
Título: Joga Rodada de Ações
Objetivo: Descrever as regras da rodada de ações
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogador
Recursos: dado, cartas, informações do projeto
Episódios:
Jogador usa seus Engenheiros de Software em CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE DEFEITO.
Se jogador não usou engenheiros de software então INTEGRA ARTEFATOS EM UM MÓDULO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades podem ser afetadas por cartas de conceito ou carta de problemas.
Jogador lança o dado.
Se dado igual a 1,ou 2 ou 3, então jogador pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.
Se dado igual a 4 ou 5 ou 6, então jogador pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3.
Título: Joga Rodada de Conceitos
Objetivo: Descrever as regras da rodada de conceitos
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido, Todos os jogadores terminaram JOGA RODADA DE AÇÕES
Atores: jogador, concorrente
Recursos: cartas, informações do projeto
Episódios:
Jogador descarta suas cartas de conceito no tabuleiro caso sejam permanentes.
Se jogador tem cartas de engenheiro de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (informado na carta de projeto) colocando-os no tabuleiro.
Jogador descarta cartas, retornando-as aos montes apropriados.
Jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema.
Jogador lê em voz alta o problema que submete ao concorrente.
Título: Recebe cartas
Objetivo: Descrever as regras da rodada de receber cartas
Contexto: Informações do projeto no centro da mesa
Todos os jogadores terminaram JOGA RODADA DE AÇÕES, Jogador recebeu cartas de concorrente
Atores: jogador, concorrente
Recursos: cartas, informações do projeto
Episódios:
Jogador estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador atende a demanda da carta de problema. Restrição: carta de problema pode ser contraposta por carta de conceito.
Se o problema é temporário então jogador descarta a carta de problema.
Se o problema é permanente então jogador mantêm carta. Restrição: carta de problema pode ser contraposta por carta de conceito.
Título: Submete produto
Objetivo: Descrever as regras de submeter produto
Contexto: Informações do projeto no centro da mesa
Jogador acabou de integrar seu último modulo
Atores: jogador, concorrente
Recursos: cartas, informações do projeto, módulos
Episódios:
Jogador mostra que produziu x módulos, de acordo com as informações de projeto. Concorrente (qualquer) escolhe x artefatos (cartas) de qualquer dos módulos, onde x é o nível de qualidade do projeto.
Se artefatos escolhidos (desvirados) forem livres de defeito, então jogador ganha o jogo.
Título: Constrói artefato
Objetivo: Descrever as regras de construir artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito
Atores: jogador
Recursos: cartas, informações do projeto
Episódios:
Jogador, para cada carta de engenheiro de software, escolhe do monte de artefatos os artefatos que podem ser produzidos por aquele engenheiro de software.
Se jogador escolhe carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade da carta de engenheiro de software.
Se o jogador escolhe carta cinza, então o número de cartas é determinado pela metade mais um da complexidade do projeto e pela habilidade da carta engenheiro de software. estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador coloca as cartas escolhidas no tabuleiro de acordo com o jogador e de acordo com o tipo de artefato produzido.
Título: Inspeciona artefato
Objetivo: Descrever as regras para inspecionar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogador
Recursos: cartas, informações do projeto, artefato
Episódios:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a inspeção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a inspeção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é desvirado no tabuleiro.
Título: Corrige artefato
Objetivo: Descrever as regras para corrigir artefatos inspecionados
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos inspecionados ( INSPECIONA ARTEFATO) no tabuleiro
Atores: jogador
Recursos: cartas, informações do projeto, artefato inspecionado
Episódios:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a correção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a correção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é substituído por artefato livre de defeito (carta branca sem defeito).
Título: Integra artefatos em um módulo
Objetivo: Descrever as regras para integrar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogador
Recursos: cartas, informações do projeto
Episódios:
Jogador escolhe módulo do projeto.
Jogador seleciona artefatos do tabuleiro, independente de responsável (engenheiro de software) de acordo com as informações de projeto.
Jogador integra o módulo juntando as cartas em um monte fora do tabuleiro.
quarta-feira, maio 02, 2007
Aula 9
Nessa aula jogamos mais um vez. As regras foram mudadas.
Incluiu-se a noção de rodada de dado e rodada de cartas. Acreditamos
que isso tornou o jogo mais dinâmico.
Abaixo listamos uma primeira versão das novas regras escritas na linguagem de cenários.
Vamos utiliza-las tanto para jogarmos na Aula 10 (hoje) como também para estudarmos a linguagem proposta como uma linguagem para descrição das regras do jogo.
A leitura sobre cenários deve incluir os seguintes artigos: construção de cenários, inspeção de cenários e identificação de padrões em cenários.
Além disso estaremos lendo o seguinte artigo: "Evolving Object-Oriented Designs with Refactorings" de Tokuda e Batory.
A regras, numa primeira versão, estão listadas abaixo.
Título: Inicio de jogo
Objetivo: Descrever as regras do SimulES
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 da vez inicia rodada.
Jogador JOGA DADO.
Jogador DESCARTA CARTAS.
Jogador RECEBE CARTAS
Se jogador empacotou o produto, então jogador SUBMETE PRODUTO.
Título: Joga Dado
Objetivo: Descrever as regras da rodada de jogar dados
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
Se dado igual a 1, então jogador lança dado. Restrição: jogador só prossegue após tirar número diferente de 1.
Se dado igual a 2 ou 3, então jogador pega 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.
Se dado igual a 4 ou 5 ou 6, então jogador pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3.
Se jogador tem engenheiros de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (informado na carta de projeto) colocando-o(s) no tabuleiro.
Título: Descarta cartas
Objetivo: Descrever as regras da rodada de destacar cartas
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido, Todos os jogadores terminaram JOGA DADO
Atores: jogadores, jogador, concorrente
Recursos: cartas, informações do projeto
Episódio:
Jogador descarta suas cartas de conceito no tabuleiro.
Jogador usa seus Engenheiros de Software para CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE DEFEITO OU INTEGRA ARTEFATOS EM UM MÓDULO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades podem ser afetadas por cartas de conceito ou carta de problemas.
Jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema.
Jogador ler em voz alta o problema que submete ao concorrente.
Título: Recebe cartas
Objetivo: Descrever as regras da rodada de receber cartas
Contexto: Informações do projeto no centro da mesa
Todos os jogadores terminaram JOGA DADO, Jogador recebeu cartas de concorrente
Atores: jogadores, jogador, concorrente
Recursos: cartas, informações do projeto
Episódio:
Jogador estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador atende a demanda da carta de problema. Restrição: carta de problema pode ser contraposta por carta de conceito.
Se o problema é temporário então jogador descarta a carta de problema.
Se o problema é permanente então jogador mantêm carta. Restrição: carta de problema pode ser contraposta por carta de conceito.
Título: Submete produto
Objetivo: Descrever as regras de submeter produto
Contexto: Informações do projeto no centro da mesa
Jogador acabou de integrar seu último modulo
Atores: jogadores, jogador, concorrente
Recursos: cartas, informações do projeto, módulos
Episódio:
Jogador mostra que produziu x módulos, de acordo com as informações de projeto. Concorrente (qualquer) escolhe x artefatos (cartas) de qualquer dos módulos, onde x é o nível de qualidade do projeto.
Se artefatos escolhidos (desvirados) forem livres de defeito, então jogador ganha o jogo.
Título: Constrói artefato
Objetivo: Descrever as regras de construir artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito
Atores: jogadores, jogador,
Recursos: cartas, informações do projeto
Episódio:
Jogador, para cada carta de engenheiro de software, escolhe do monte de artefatos os artefatos que podem ser produzidos por aquele engenheiro de software.
Se jogador escolhe carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade da carta de engenheiro de software.
Se o jogador escolhe carta cinza, então o número de cartas é determinado pela metade mais um da complexidade do projeto e pela habilidade da carta engenheiro de software. estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador coloca as cartas escolhidas no tabuleiro de acordo com o jogador e de acordo com o tipo de artefato produzido.
Título: Inspeciona artefato
Objetivo: Descrever as regras para inspecionar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogadores, jogador
Recursos: cartas, informações do projeto, artefato
Episódio:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a inspeção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a inspeção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é desvirado no tabuleiro.
Título: Corrige artefato
Objetivo: Descrever as regras para corrigir artefatos inspecionados
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos inspecionados ( INSPECIONA ARTEFATO) no tabuleiro
Atores: jogadores, jogador
Recursos: cartas, informações do projeto, artefato inspecionado
Episódio:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a correção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a correção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é substituído por artefato livre de defeito (carta branca sem defeito).
Título: Integra artefatos em um módulo
Objetivo: Descrever as regras para integrar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogadores, jogador
Recursos: cartas, informações do projeto
Episódio:
Jogador escolhe módulo do projeto.
Jogador seleciona artefatos do tabuleiro, independente de responsável (engenheiro de software) de acordo com as informações de projeto.
Jogador integra o módulo juntando as cartas em um monte fora do tabuleiro.
Incluiu-se a noção de rodada de dado e rodada de cartas. Acreditamos
que isso tornou o jogo mais dinâmico.
Abaixo listamos uma primeira versão das novas regras escritas na linguagem de cenários.
Vamos utiliza-las tanto para jogarmos na Aula 10 (hoje) como também para estudarmos a linguagem proposta como uma linguagem para descrição das regras do jogo.
A leitura sobre cenários deve incluir os seguintes artigos: construção de cenários, inspeção de cenários e identificação de padrões em cenários.
Além disso estaremos lendo o seguinte artigo: "Evolving Object-Oriented Designs with Refactorings" de Tokuda e Batory.
A regras, numa primeira versão, estão listadas abaixo.
Título: Inicio de jogo
Objetivo: Descrever as regras do SimulES
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 da vez inicia rodada.
Jogador JOGA DADO.
Jogador DESCARTA CARTAS.
Jogador RECEBE CARTAS
Se jogador empacotou o produto, então jogador SUBMETE PRODUTO.
Título: Joga Dado
Objetivo: Descrever as regras da rodada de jogar dados
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
Se dado igual a 1, então jogador lança dado. Restrição: jogador só prossegue após tirar número diferente de 1.
Se dado igual a 2 ou 3, então jogador pega 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.
Se dado igual a 4 ou 5 ou 6, então jogador pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3.
Se jogador tem engenheiros de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (informado na carta de projeto) colocando-o(s) no tabuleiro.
Título: Descarta cartas
Objetivo: Descrever as regras da rodada de destacar cartas
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido, Todos os jogadores terminaram JOGA DADO
Atores: jogadores, jogador, concorrente
Recursos: cartas, informações do projeto
Episódio:
Jogador descarta suas cartas de conceito no tabuleiro.
Jogador usa seus Engenheiros de Software para CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE DEFEITO OU INTEGRA ARTEFATOS EM UM MÓDULO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades podem ser afetadas por cartas de conceito ou carta de problemas.
Jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema.
Jogador ler em voz alta o problema que submete ao concorrente.
Título: Recebe cartas
Objetivo: Descrever as regras da rodada de receber cartas
Contexto: Informações do projeto no centro da mesa
Todos os jogadores terminaram JOGA DADO, Jogador recebeu cartas de concorrente
Atores: jogadores, jogador, concorrente
Recursos: cartas, informações do projeto
Episódio:
Jogador estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador atende a demanda da carta de problema. Restrição: carta de problema pode ser contraposta por carta de conceito.
Se o problema é temporário então jogador descarta a carta de problema.
Se o problema é permanente então jogador mantêm carta. Restrição: carta de problema pode ser contraposta por carta de conceito.
Título: Submete produto
Objetivo: Descrever as regras de submeter produto
Contexto: Informações do projeto no centro da mesa
Jogador acabou de integrar seu último modulo
Atores: jogadores, jogador, concorrente
Recursos: cartas, informações do projeto, módulos
Episódio:
Jogador mostra que produziu x módulos, de acordo com as informações de projeto. Concorrente (qualquer) escolhe x artefatos (cartas) de qualquer dos módulos, onde x é o nível de qualidade do projeto.
Se artefatos escolhidos (desvirados) forem livres de defeito, então jogador ganha o jogo.
Título: Constrói artefato
Objetivo: Descrever as regras de construir artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito
Atores: jogadores, jogador,
Recursos: cartas, informações do projeto
Episódio:
Jogador, para cada carta de engenheiro de software, escolhe do monte de artefatos os artefatos que podem ser produzidos por aquele engenheiro de software.
Se jogador escolhe carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade da carta de engenheiro de software.
Se o jogador escolhe carta cinza, então o número de cartas é determinado pela metade mais um da complexidade do projeto e pela habilidade da carta engenheiro de software. estuda como atender a demanda d carta de problema colocado pelo concorrente.
Jogador coloca as cartas escolhidas no tabuleiro de acordo com o jogador e de acordo com o tipo de artefato produzido.
Título: Inspeciona artefato
Objetivo: Descrever as regras para inspecionar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogadores, jogador
Recursos: cartas, informações do projeto, artefato
Episódio:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a inspeção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a inspeção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é desvirado no tabuleiro.
Título: Corrige artefato
Objetivo: Descrever as regras para corrigir artefatos inspecionados
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos inspecionados ( INSPECIONA ARTEFATO) no tabuleiro
Atores: jogadores, jogador
Recursos: cartas, informações do projeto, artefato inspecionado
Episódio:
Jogador escolhe artefato do tabuleiro.
Se o engenheiro de software responsável pelo artefato faz a correção, então o projeto gasta um ponto de tempo desse engenheiro.
Se outro engenheiro de software faz a correção, então o projeto gasta dois pontos de tempo desse engenheiro.
Artefato inspecionado é substituído por artefato livre de defeito (carta branca sem defeito).
Título: Integra artefatos em um módulo
Objetivo: Descrever as regras para integrar artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito. Jogador tem artefatos no tabuleiro
Atores: jogadores, jogador
Recursos: cartas, informações do projeto
Episódio:
Jogador escolhe módulo do projeto.
Jogador seleciona artefatos do tabuleiro, independente de responsável (engenheiro de software) de acordo com as informações de projeto.
Jogador integra o módulo juntando as cartas em um monte fora do tabuleiro.
sábado, abril 21, 2007
Aula 8
Bom desempenho. Vamos discutir as pendências na próxima Quarta.
No redesenho do jogo, um dos objetivos foi fazê-lo mais dinâmico, vamos ver o que está impedindo esse dinamismo.
Seria bom lermos as regras da versão original.
Bom lembrar que vamos jogar novamente na próxima Quarta.
No redesenho do jogo, um dos objetivos foi fazê-lo mais dinâmico, vamos ver o que está impedindo esse dinamismo.
Seria bom lermos as regras da versão original.
Bom lembrar que vamos jogar novamente na próxima Quarta.
quarta-feira, abril 11, 2007
Aula 6
Vimos em aula que a distinção entre espaço de produto e espaço de versão é chave para o entendimento da questão de configuração. O material do artigo é substancial no tratamento de diferentes políticas para a implementação do controle entre diferentes instâncias de um determinado conjunto.
Na discussão procurei expressar que minha visão é complementar a do artigo, ressaltando a ressalva que fiz sobre o espaço de produto. Creio que nesse espaço é também importante tratar da variabilidade, o que chamamos de configurações e que o espaço de versões seria fundamentalmente destinado a variabilidade temporal e seria portanto o espaço de versões.
Vejam que na definição do artigo, versões aplica-se tanto a aspectos de diferentes configurações como a diferentes versões temporais. O que o artigo faz é reduzir tanto configurações distintas de um mesmo conjunto e versões de um conjunto ao longo do tempo ao conceito de versões. Vejam que existe uma figura no texto em que isso fica bem claro ( o cubo).
Façam uma pesquisa sobre o tema. Sugestão procurem "white papers" de fornecedores de ferramentas para o controle de configuração. Coloquem o que acharam nos seus "blogs".
Iremos nessa Quarta iniciar o estudo do jogo da Evolução.
Na discussão procurei expressar que minha visão é complementar a do artigo, ressaltando a ressalva que fiz sobre o espaço de produto. Creio que nesse espaço é também importante tratar da variabilidade, o que chamamos de configurações e que o espaço de versões seria fundamentalmente destinado a variabilidade temporal e seria portanto o espaço de versões.
Vejam que na definição do artigo, versões aplica-se tanto a aspectos de diferentes configurações como a diferentes versões temporais. O que o artigo faz é reduzir tanto configurações distintas de um mesmo conjunto e versões de um conjunto ao longo do tempo ao conceito de versões. Vejam que existe uma figura no texto em que isso fica bem claro ( o cubo).
Façam uma pesquisa sobre o tema. Sugestão procurem "white papers" de fornecedores de ferramentas para o controle de configuração. Coloquem o que acharam nos seus "blogs".
Iremos nessa Quarta iniciar o estudo do jogo da Evolução.
quinta-feira, março 29, 2007
Aula 5
Em aula vimos que o artigo sobre triagem de problemas estava relacionado a evolução porque mostra uma visão operacional da tarefa de modificação de programas. No entanto, para termos essa visão foi necessário entendermos como deve funcionar o processo de registro de problemas e sua relação com o processo de modificação. O aspecto de quem indicar para o tratamento de um dado problema, o tema principal do artigo, serviu para termos uma visão do aspecto operacional do processo de mudança. Apesar de não ser o tema principal do artigo, fica evidente o papel de gerência de mudança, principalmente quanto vimos as conclusões do artigo.
O processo de triagem é parte de um processo mais complexo, o processo de gerência de mudança. Vale salientar que essa mudança ocorre em função da retro-alimentação proveniente do contexto onde atua o software. Vimos também que o processo de gerência de mudança está intimamente ligado ao processo de controle das versões do software.
Portanto vimos uma visão abstrata da evolução através da teoria de Lehman e o debate sobre sua abrangência e vimos, através de um relato ortogonal, uma visão do nível operacional da evolução.
O aspecto importante sobre essas duas visões é que elas levam ao conceito de gerência de mudança. Em software o processo de gerência de mudança é fundamentado no conceito
de gerência de configuração.
Portanto para a Aula 6 leremos o clássico: "Version Models For Software Configuration Management"
O processo de triagem é parte de um processo mais complexo, o processo de gerência de mudança. Vale salientar que essa mudança ocorre em função da retro-alimentação proveniente do contexto onde atua o software. Vimos também que o processo de gerência de mudança está intimamente ligado ao processo de controle das versões do software.
Portanto vimos uma visão abstrata da evolução através da teoria de Lehman e o debate sobre sua abrangência e vimos, através de um relato ortogonal, uma visão do nível operacional da evolução.
O aspecto importante sobre essas duas visões é que elas levam ao conceito de gerência de mudança. Em software o processo de gerência de mudança é fundamentado no conceito
de gerência de configuração.
Portanto para a Aula 6 leremos o clássico: "Version Models For Software Configuration Management"
segunda-feira, março 26, 2007
Aula 4
Na aula anterior discutimos, na maior parte do tempo, o tipo de crescimento das curvas de volume de código. A discussão entre o crescimento ser o inverso do quadrado, linear, super linear afetava principalmente as leis 4 e 5.
Para a proxíma aula vejam o artigo que mencionei sobre o desenvolvimento de código aberto. É uma artigo bem interessante. Vale a pena ler.
No entanto, discutiremos o artigo com o título "Who Should Fix this Bug" apresentado no último ICSE. Estou usando o endereço do curso sobre evolução de software que é lecionado na Universidade de Waterloo. Vale a pena visitar a página com o programa daquele curso.
Para a proxíma aula vejam o artigo que mencionei sobre o desenvolvimento de código aberto. É uma artigo bem interessante. Vale a pena ler.
No entanto, discutiremos o artigo com o título "Who Should Fix this Bug" apresentado no último ICSE. Estou usando o endereço do curso sobre evolução de software que é lecionado na Universidade de Waterloo. Vale a pena visitar a página com o programa daquele curso.
segunda-feira, março 19, 2007
Aula 3
“Processos de evolução de software são sistemas de retro-alimentação em múltiplos níveis, em múltiplos laços (loops) e envolvendo múltiplos agentes.”.
Voltamos à frase que caracteriza a oitava lei de Leham. Para consolidar o conceito de retro-alimentação apresentei o modelo ultra-estável de Ashby segundo a visão de Jaques Mélèse. Veja aqui um exemplo desse modelo. O texto está em Francês, mas as figuras são fáceis de entender.
O importante desse modelo é a divisão de trabalho entre: Detectar, Controlar (entender o desvio e formalizar seu entendimento) e Regular (agir sobre o sistema). Com isso, além de, simplesmente, lidarmos com entrada e saída, temos as varáveis essenciais e as variáveis de ação.
Vimos também que o conceito de institucionalização de sistemas de informação, ajuda o entendimento do porque os sistemas de software têm uma vida longa (“old code never dies”).
Debatemos em mais detalhes a Leis 4 e 5. No fundo, meu entendimento da Lei 4 já pressupõe a Lei 8, no entanto, a seguir o que diz Lehman, fatores referentes a capacidade laboral da organização responsável pela software é que melhor explicariam essa lei. Vejam que a definição da Lei 4 mudou no segundo artigo que lemos, para tocar no ponto da retro-alimentação.
No que concerne a Lei 5, “De maneira geral, a taxa de crescimento incremental e taxa crescimento a longo prazo tende a declinar.” a explicação passa pela noção de limite. Ou seja, a organização entende que para um determinado produto, já não vale a pena o crescimento face aos problemas que ele pode gerar.
A próxima leitura é um artigo com críticas as leis da evolução.
Voltamos à frase que caracteriza a oitava lei de Leham. Para consolidar o conceito de retro-alimentação apresentei o modelo ultra-estável de Ashby segundo a visão de Jaques Mélèse. Veja aqui um exemplo desse modelo. O texto está em Francês, mas as figuras são fáceis de entender.
O importante desse modelo é a divisão de trabalho entre: Detectar, Controlar (entender o desvio e formalizar seu entendimento) e Regular (agir sobre o sistema). Com isso, além de, simplesmente, lidarmos com entrada e saída, temos as varáveis essenciais e as variáveis de ação.
Vimos também que o conceito de institucionalização de sistemas de informação, ajuda o entendimento do porque os sistemas de software têm uma vida longa (“old code never dies”).
Debatemos em mais detalhes a Leis 4 e 5. No fundo, meu entendimento da Lei 4 já pressupõe a Lei 8, no entanto, a seguir o que diz Lehman, fatores referentes a capacidade laboral da organização responsável pela software é que melhor explicariam essa lei. Vejam que a definição da Lei 4 mudou no segundo artigo que lemos, para tocar no ponto da retro-alimentação.
No que concerne a Lei 5, “De maneira geral, a taxa de crescimento incremental e taxa crescimento a longo prazo tende a declinar.” a explicação passa pela noção de limite. Ou seja, a organização entende que para um determinado produto, já não vale a pena o crescimento face aos problemas que ele pode gerar.
A próxima leitura é um artigo com críticas as leis da evolução.
domingo, março 11, 2007
Aula 2
Nessa aula centramos nossa atenção na taxonomia de classificação presente no artigo de
Verhoef. Lembro que esse artigo foi encontrado no "Software Engineering Body of Knowledge" na versão "stoneman".
Usando as classes apresentadas no artigo falamos do processo de produção de software em geral e citamos alguns exemplos.
Começamos a discutir a frase de Lehman e continuaremos na próxima aula. Uma importante caractéristica da frase é que ela aplica-se a sistemas do tipo E. E o que são sistemas que não são do tipo E? Esses são chamados sistemas do tipo S. Veja exemplos aqui e aqui.
Para a próxima aula vamos discutir as leis de Lehman, no artigo indicado na Aula 1. Além disso, devemos ler outro artigo do Prof. Lehman: "Rules and Tools for Software Evolution Planning and Management". Vejam o elo para o artigo, bem como uma tradução das leis em uma postagem feita em 2006.
Como disse, espero que cada um faça seu "blog" e nele coloque o resumo do que leu, pesquisou e do que anotou/observou em aula. Assim que tiver o endereço me digam, para que possa postar aqui, como foi feito no ano anterior (elos -- 2006-1).
Verhoef. Lembro que esse artigo foi encontrado no "Software Engineering Body of Knowledge" na versão "stoneman".
Usando as classes apresentadas no artigo falamos do processo de produção de software em geral e citamos alguns exemplos.
Começamos a discutir a frase de Lehman e continuaremos na próxima aula. Uma importante caractéristica da frase é que ela aplica-se a sistemas do tipo E. E o que são sistemas que não são do tipo E? Esses são chamados sistemas do tipo S. Veja exemplos aqui e aqui.
Para a próxima aula vamos discutir as leis de Lehman, no artigo indicado na Aula 1. Além disso, devemos ler outro artigo do Prof. Lehman: "Rules and Tools for Software Evolution Planning and Management". Vejam o elo para o artigo, bem como uma tradução das leis em uma postagem feita em 2006.
Como disse, espero que cada um faça seu "blog" e nele coloque o resumo do que leu, pesquisou e do que anotou/observou em aula. Assim que tiver o endereço me digam, para que possa postar aqui, como foi feito no ano anterior (elos -- 2006-1).
quinta-feira, março 01, 2007
Aula 1
sob o Enfoque de Re-Engenharia". Temos uma cópia na biblioteca. Vale a pena ler.
Para Souza a manutenção deveria ser classificada em: corretiva, adaptativa, evolutiva, preventiva e de suporte. Em artigo recente, Chris Verhoef classifica manutenção em: antes da entrega, corretiva, adaptativa, perfectiva, e preventiva. No fundo essas propostas são fundamentalmente baseadas no trabalho de Swanson de 1976.
Lembrem que fiz uma diferença entre o conceito de manutenção e o conceito de evolução.
Algumas das primeiras idéias sobre evolução estão explicitadas numa palestra convidada que proferi na JAIIO em Buenos Aires em 1997.
A leitura para a próxima aula é Laws of Software Evolution Revisited do Professor Lehman. O objetivo principal é procurar entender o que é o conceito de "complex, multi loop multilevel feedback system"
Para Souza a manutenção deveria ser classificada em: corretiva, adaptativa, evolutiva, preventiva e de suporte. Em artigo recente, Chris Verhoef classifica manutenção em: antes da entrega, corretiva, adaptativa, perfectiva, e preventiva. No fundo essas propostas são fundamentalmente baseadas no trabalho de Swanson de 1976.
Lembrem que fiz uma diferença entre o conceito de manutenção e o conceito de evolução.
Algumas das primeiras idéias sobre evolução estão explicitadas numa palestra convidada que proferi na JAIIO em Buenos Aires em 1997.
A leitura para a próxima aula é Laws of Software Evolution Revisited do Professor Lehman. O objetivo principal é procurar entender o que é o conceito de "complex, multi loop multilevel feedback system"
terça-feira, fevereiro 27, 2007
Bem-vindos
Vejam que mantive a história da matéria.
No entanto, a cada aula colocarei uma nova nota. Eventualmente esse nota pode ser um simples
elo para uma nota do ano anterior.
Sejam Bem-vindos!
No entanto, a cada aula colocarei uma nova nota. Eventualmente esse nota pode ser um simples
elo para uma nota do ano anterior.
Sejam Bem-vindos!
Assinar:
Postagens (Atom)