Evolução de Software - Algumas Considerações

Ao longo do curso, pôde-se perceber a complexidade na tarefa de evoluir um software. Inicialmente, tivemos contato com as leis de Lehman, que serviram para nortear nossos estudos. Dessas 8 leis, destaco a 1a lei, que trata da mudança contínua - um software deve ser constantemente adaptado, caso contrário se torna progressivamente menos satisfatório e a 8a lei, relacionada ao feedback - processos de evolução de software são sistemas de feedback em múltiplos níves, múltiplos laços e múltiplos agentes, e devem ser tratados como tal para que possam ser modificados e/ou melhorados com sucesso.
Na tarefa de evoluir o SimulES, pudemos perceber que melhorar, documentar, rastrear e refatorar são tarefas complexas que exigem muita colaboração dos integrantes da equipe. realizamos várias melhorias no jogo, como: melhoria na dinâmica da partida, introduzindo a idéia de 2 rodadas, melhoria da documentação, utilização de cenários, produção do Léxico do SImulES e revisão das cartas. Foi possível também apontar vários problemas, como a lentidão da partida, excesso de cartas de problemas, entre outros. Tivemos a oportunidade de obter um valioso feedback de jogadores convidados, o que contribuiu sensivelmente para a melhoria do jogo.
Visando manter a rastreabilidade do SimulES ao longo das evoluções feitas, foi realizado um processo manual para controlar todas as versões de cenários produzidas, sendo necessário ainda definir a granularidade de uma mudança e as considerações a serem feitas pela equipe.
Sendo assim, pode-se concluir que a evolução de software é uma tarefa complexa, que exige dedicação e observação das boas práticas adquiridas em sala de aula com o Prof. Julio.

Última Aula

Nessa aula, consolidamos a idéia de 2 rodadas no SimulES. Foi realizada a técnica de "brainstorming" para melhorar ainda mais o jogo, e chegamos a uma proposta excelente de um tabuleiro central para ajudar a dinâmica e localização do jogador na rodada.
Foram consolidadas ainda, algumas regras que estavam em aberto e por fim, decidimos os tópicos da monografia que será escrita por toda a equipe.

Jogando o SimulES: Feedback dos jogadores convidados

Após uma série de reuniões, modificações das regras, refatoração das cartas e melhoria da dinâmica do jogo, foi feito um convite para que outros alunos pudessem experimentar a nova versão do jogo SimulES. Isso seria de suma importância pois pela primeira vez iríamos obter um feedback dos usuários finais.
Foram recrutados dois grupos de 4 componentes para jogar. O primeiro grupo possuia uma documentação que consistia nos cenários do SimulES e uma complementação a respeito do jogo. O segundo grupo possuia uma documentação diferente do primeiro grupo, incluíndo o Léxico do SimulES no lugar da complementação. Isso permitiria avaliar a documentação baseado em como os jogadores entenderiam a dinâmica do jogo.
Ao iniciar a partida, pudemos perceber que apenas 1 aluno no primeiro grupo leu a documentação. Isso prejudicou um pouco o dinamismo do jogo, pois trata-se de um ambiente com um pouco de complexidade para aprender sem ler as regras. Algumas dúvidas surgiram, como em que momento deveriam produzir artefatos ou jogar o dado para comprar cartas. A partida foi se tornando divertida e proveitosa para os jogadores, porém com o passar do tempo os jogadores foram acumulando problemas (a proporção das cartas de problema é mais que o dobro das cartas de conceito) e a partida tornou-se monótona. O término do jogo se deu pelo encerramento do tempo.
A segunda partida foi marcada pela ausência da maioria dos componentes. Somente uma aluna se fez presente para experimentar o SimulES. A fim de que ela pudesse ter contato com o jogo, os alunos da cadeira de Evolução de Software jogaram a partida com a aluna. Isso influênciou diretamente o dinamismo da partida, pois os jogadores já eram experientes.
Podemos tiram algumas lições baseadas no feedback dos jogadores:

• A leitura da documentação é proveitosa no que diz respeito a dinâmica do jogo. Isso ficou comprovado pelo aluno que realizou a leitura.
• A proporção das cartas de conceitos e problemas é muito desigual. Isso afeta o dinamismo da partida a médio prazo. Torna-se necessário criar mais cartas de conceito, visto que existem pouco menos da metade que as cartas de problemas.
• Nenhum jogador inspecionou sequer um artefato. Devemos ver porque isso ocorreu e se está diretamente ligado ao desenvolvimento do jogo.
• A divisão de rodadas no jogo melhora o dinamismo porém aumenta a complexidade e sofisticação do SimulES com relação ao entendimento.
• Cartas bem humoradas como o filho do Chefe e a engenheira Paula são bem vindas.
• Os jogadores não tiveram dificuldades em interpretar as cartas de problemas e conceitos.

Sendo assim, pode-se concluir que estamos no caminho certo de evolução e que com mais algumas modificações, o SimulES tem tudo para se tornar uma referência no ensino da engenharia de software.

Evolução das cartas de problemas de RH do jogo SimulES

Nesta aula, os alunos iniciaram o processo de evolução das cartas de problemas do jogo SimulES. Inicialmente, surgiu um debate sobre maturidade e habilidade nas cartas. Decidiu-se que o texto das cartas deveria ser revisto baseados em que habilidade estaria ligado a parte de produção profissional do engenheiro, e maturidade a experiência e personalidade.

Em seguida, os problemas foram divididos entre os alunos por áreas. Segue abaixo, a evolução das cartas de Recursos Humanos. As alterações feitas foram basicamente, escrever maturidade ao invés de personalidade, colocá-las no padrão especificado pela turma, revisão do texto da carta barulho anormal (que tornou-se Atraso no Pagamento).

Referência:

FIGUEIREDO, E. M. L., LOBATO, C. A., DIAS, K. L., LEITE, J. C. S. P., LUCENA, C. J. P., "SimulES: Um Jogo para o Ensino de Engenharia de Software. " Monografia em Ciência da Computação n 34/06. Departamento de Informática - PUC-Rio, 2006.

Evolução e Rastreabilidade dos Cenários do SimulES

Nesta aula, o grupo de alunos se reuniu para corrigir e definir o conjunto de cenários para descrever as regras do SimulES. Abaixo são listados alguns exemplos obtidos. Todos os cenários podem ser obtidos no blog da aluna Milene Serrano , que realizou um excelente trabalho.

Título: Dinâmica do SimulES
Objetivo: Descrever as regras do SimulES
Contexto: INICIO DE JOGO.
Atores: jogador, jogador da vez.
Recursos: dado, cartas, cartão do projeto, tabuleiro.
Episódios: Jogador da vez inicia turno.
Se jogador da vez puder empacotar o produto, então jogador da vez SUBMETE PRODUTO.
Jogador da vez JOGA RODADA DE AÇÕES.
Cada jogador JOGA RODADA DE AÇÕES.
Jogador da vez JOGA RODADA DE CONCEITOS.
Cada jogador JOGA RODADA DE CONCEITOS.
Jogador da vez TRATA PROBLEMAS.
Cada jogador TRATA PROBLEMAS.


É fácil observar a separação do jogo em rodada de ações e rodada de conceitos .


Título: Joga Rodada de Ações
Objetivo: Descrever as regras da rodada de ações.
Contexto: Cartão do projeto no centro da mesa.
Jogador da vez já foi escolhido.
Atores: jogador da vez.
Recursos: dado, cartas, cartão do projeto, tabuleiro.
Episódios: Jogador da vez usa seus Engenheiros de Software em CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE ARTEFATO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades e o custo dessas ações podem ser afetados por cartas de conceitos ou cartas de problemas.
Jogador da vez lança o dado.
Se dado igual a 1, 2 ou 3, então jogador da vez pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador da vez não pode pegar cartas do monte de engenheiros de software.
Se dado igual a 4 ou 5 ou 6, então jogador da vez 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 da vez não usou engenheiros de software e nem jogou o dado, então INTEGRA ARTEFATOS EM UM MÓDULO.

Um último exemplo poderia ser:


Título: Submete produto
Objetivo: Descrever as regras da submissão de produto.
Contexto: Cartão do projeto no centro da mesa.
Jogador de vez acabou de integrar seu último módulo.
Atores: jogador, jogador da vez, adversário.
Recursos: cartas, cartão do projeto, módulo.
Episódios: Jogador da vez mostra que produziu todos os módulos, de acordo com o cartão do projeto.
Adversários escolhem todos os artefatos de x módulos, onde x é o nível de qualidade do projeto. Restrição: Adversários não podem escolher módulo protegido por carta de conceito do jogador da vez.
Adversários desviram artefatos escolhidos.
Adversários verificam artefatos desvirados.
Se artefatos verificados forem livres de defeito, então jogador da vez ganha o jogo.
Se artefatos verificados forem defeituosos, então jogador da vez pode corrigir um por turno de jogo.


Os cenários apresentados anteriormente pertencem a sua versão D. Mas o que é rastreabilidade e como é possível manter a rastreabilidade em um projeto de software?

Para responder essas perguntas e preocupado com a rastreabilidade na evolução do jogo SimulES, a turma realizou a leitura do artigo Rastreabilidade de Requisitos .
Do ponto de vista gerencial, a rastreabilidade possibilita identificar rapidamente artefatos de desenho, projeto e código afetados por uma solicitação de mudança. Para isso, a gerência deve entre outras ações: documentar, realizar controle de mudanças, manter planos, descrever os cenários, etc. Do ponto de vista da qualidade, a importância da rastreabilidade está na análise da cobertura de testes de funcionalidade e correção de defeitos.

Com relação ao SimulES, ao utilizar o software C&L (cenários e léxico), tem-se um elo indicando toda relação de dependência entre cenários, objetos, verbos, estados entre outros. Além disso, foi exercitado em aula o processo de rastreabilidade entre os cenários do jogo. Inicialmente, foram definidas para as 4 versões de cenários presentes as letras A, B, C, D. Em seguida, definiu-se a granularidade para rastreabilidade a diferença entre as sentenças. Cada sentença em cada versão possuia um código único. Por exemplo, na versão A, o primeiro cenário possui código CA1 (C - cenário e A - versão e 1 - numeração do cenário). Logo o contexto desse cenário seria CA1C1. Baseado nisso, pode-se apresentar um exemplo de evolução de cenários:


Título: Inicio de jogo (CA1)
Objetivo: Descrever as regras do SimulES (CA1O1)
Contexto: Informações do projeto no centro da mesa (CA1C1)
Primeiro jogador já foi escolhido (CA1C2)
Atores: jogadores (CA1A1)
Recursos: dado, cartas, informações do projeto (CA1R1), (CA1R2), (CA1R3)
Episódio: Jogador da vez inicia rodada. (CA1E1)
Jogador JOGA DADO. (CA1E2)
Jogador DESCARTA CARTAS. (CA1E3)
Jogador RECEBE CARTAS. (CA1E4)
Se jogador empacotou o produto, então jogador SUBMETE PRODUTO. (CA1E5)


Título: Inicio de jogo (CB2)
Objetivo: Descrever os preparativos para inicio do jogo (CB2O2)
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo. (CB2C1)
Cada jogador tem uma carta de engenheiro de software. (CB2C2)
Atores: jogador (CB2A1)
Recursos: dado, cartas, informações do projeto. (CB2R1), (CB2R2), (CB2R3)
Episódios: Jogador joga dado. Restrição: Maior dado inicia jogo. (CB2E1)
Jogador escolhe aleatoriamente do monte de carta de informações de projeto um projeto. (CB2E2) 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. (CB2E3)


Título: Inicio de jogo (CC2)
Objetivo: Descrever os preparativos para inicio do jogo. (CC2O1)
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo. (CC2C1)
Cartas embaralhadas sobre a mesa. (CC2C2)
Cada jogador tem uma carta de engenheiro de software. (CC2C3)
Atores: jogador (CC2A1)
Recursos: dado, cartas, informações do projeto, tabuleiro.(CC2R1),(CC2R2),(CC2R3)
Episódio: Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo. (CC2E1)
Jogador escolhe aleatoriamente do monte de cartões de projeto. Restrição: Outros jogadores têm que concordar com carta escolhida por jogador que inicia jogo. (CC2E2)
Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário. (CC2E3)


Título: Inicio de jogo (CD2)
Objetivo: Descrever os preparativos para início do jogo. (CD2O1)
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo. (CD2C1)
Cartas embaralhadas sobre a mesa. (CD2C2)
Cada jogador tem uma carta de engenheiro de software. (CD2C3)
Atores: jogador, jogador da vez. (CD2A1), (CD2A2)
Recursos: dado, cartas, cartão do projeto, tabuleiro. (CD2R1), (CD2R2), (CD2R3)
Episódios: Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo e é o jogador da vez. (CD2E1)
Jogador da vez escolhe aleatoriamente do monte de cartões de projeto. Restrição: Outros jogadores têm que concordar com o cartão escolhido pelo jogador da vez. (CD2E2)
Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário. (CD2E3)

Ao final do exemplo pode-se perceber como foram realizadas todas as mudanças nos cenários. Uma das mudanças perceptíveis foi a versão do cenário CA1 para CB2, pois o cenário A foi quebrado em 2 cenários, nascendo assim um novo cenário CB1 (Dinâmica do SimulES).

Ao fim da atividade, s alunos puderam perceber o quanto é difícil documentar a evolução de um software e manter a rastreabilidade entre elas.

Construção do léxico para o jogo SimulES

Nesta aula, os alunos iniciaram a construção do léxico para o jogo SimulES, baseado nos cenários produzidos e corrigidos anteriormente. Foi utilizado para esta tarefa o software C&L.
Inicialmente, foram identificados e separados os sujeitos, verbos, objetos e estados.

Sujeitos: jogador, adversário

Verbos: comprar, descartar, desvirar, produzir, construir, inspecionar, integrar, contratar, empacotar, jogar, verificar. Importante salientar as demais conjugações possíveis de todos os verbos.

Objetos: carta, cartão, carta de conceito, carta de problema, sentidod do jogo, tabuleiro, pontos de tempo, monte, habilidade, maturidade, módulo, tamanho do projeto, complexidade do projeto, qualidade do projeto, orçamento do projeto, engenheiro de software, artefato, artefato branco, artefato cinza.

Estados: contratado, demitido, escolhido, desvirado, defeituoso, livre de defeito.

Em seguida, é apresentado alguns léxicos presentes no C&L:


Nome: artefato
Noção: Cartas que simbolizam os produtos que são produzidos pelos engenheiros de software e que podem ou não conter defeitos.
Artefatos com defeito possuem um inseto.
Podem ser de boa qualidade (branco) ou de má qualidade (cinza).
Classificação: Objeto
Impacto(s): Jogador pode produzir artefato. Jogador coloca artefatos no tabuleiro.
Sinônimo: artefatos


Nome: carta de conceito
Noção: Cartas que representam boas práticas de Engenharia de Software. Possuem referências para pesquisas do conceito citado. Podem neutralizar cartas de problemas.
Classificação: Objeto
Impacto(s): Jogador compra carta de conceito.
Jogador descarta carta de conceito.
Jogador usa carta de conceito.
Jogador coloca carta de conceito no tabuleiro.
Sinônimo: cartas de conceito conceito



Nome: carta de problema
Noção: Cartas que descrevem problemas clássicos de Engenharia de Software resultantes de faltas no processo de produção. São utilizadas para criar obstáculos ao progresso dos jogadores adversários. Podem ser neutralizadas por cartas de conceito.
Classificação: Objeto
Impacto(s): Jogador compra carta de problema. Jogador descarta carta de problema. Jogador usa carta de problema. Jogador coloca carta de problema no tabuleiro.
Algumas cartas de problema usam a maturidade como condição de aplicação do problema.
Sinônimo: cartas de problema problema cartas de problemas


Nome: engenheiro de software
Noção: Carta do jogo que representa o profissional responsável por desempenhar ações. Possui habilidade e maturidade.
Classificação: Objeto
Impacto(s): Um jogador pode contratar e/ou demitir engenheiros de software. Um jogador pode desempenhar ações por meio de seus engenheiros de software contratados.
Sinônimo: engenheiros de software


Nome: contratar
Noção: Jogador contrata engenheiro de software.
No início do jogo é obrigatório cada jogador contratar um engenheiro de software.
O engenheiro contratado deve ser colocado no tabuleiro do jogador.
Classificação: Verbo
Impacto(s): Engenheiro de software contratado só poderá produzir artefatos no próximo turno.
Sinônimo: Contratados contrata contratação

Descrição das regras do SimulES utilizando Cenários

Nesta aula, os alunos tiveram contato com uma linguagem para descrição de cenários, com o objetivo de escrever as regras do SImulES. Pode-se verificar os cenários no site do prof. Júlio. Abaixo, seguem exemplos de descrições realizadas:

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: 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.