Em nossa discussao na ultima aula, foram levantados alguns possiveis problemas com o jogo que pretendemos evoluir. Sao elas: 1) A dinamica inicial do jogo (Fase de Requisitos e Fase de Projeto) nao entusiasma muito o jogador. Parece um periodo macante em que o jogador tem que passar ate chegar a parte mais interessante (Fase de Implementacao). 2) Para alguns de nos jogadores, o jogo pareceu ser muito demorado, provavelmente devido ao modelo cascata utilizado. Em nossa primeira experiencia, jogando durante duas aulas e so chegamos a Fase de Implementacao porque atropelamos um pouco as outras fases. Ou seja, nao fizemos documentacao adequada nas fases de requisitos e projeto. 3) O jogo nao define claramente quantas pessoas devem jogar. Em nossa experiencia, jogamos em 6 pessoas. Um problema relacionado a isso e que muito problemas eram lancados para cada jogador (ate 5). Com este elevado numero de problemas, torna-se dificil para qualquer jogador evoluir (e ganhar o jogo). 4) O jogo nao fornece muitas informacoes (bibliografia) sobre seus fundamentos principais. Como este e um jogo educativo, acreditamos que os jogadores deveriam ser induzidos a procurar mais informacoes sobre conceitos de Engenharia de Software / Desenvolvimento de Software. A sexta lei de Lehman [2] diz que o conteudo funcional do programa deve ser continuamente ampliado para atender a satisfacao do usuario durante o ciclo de vida do software. O artigo do Scacchi [3] levanta pelo menos dois pontos contra esta lei:(i) a falta de estudos que fornecam informacoes sobre a satisfacao do usuario e como ela e avaliada;(ii) o encolhimento do software para atender anseios de usuarios de dispositivos moveis (minimizacao). Em relacao ao primeiro ponto levantado, concordo que deve haver estudos para relacionar o crescimento funcional ao feedback de satisfacao do usuario. Por outro lado, minha opiniao em relacao ao segundo ponto e que a minimizacao de software para atender usuarios de dispositivos moveis nao deve ser tratada como um contra exemplo desta sexta lei. Pois, acredito que neste caso as funcionalidades da aplicacao estao aumentando, uma vez que agora o sistema e capaz de executar tanto em equipamentos do tipo desktop quanto do tipo handheld. [Referencias] Vide postagem anterior. No link abaixo se encontra a traducao das cartas de engenheiros de software: Cartas de Engenheiros Falta fazer a arte (ilustracao) das cartas. Este trabalho eu deixo para outra pessoa que tenha mais habilidade nesta area ;-)Enquanto fazia a traducao pensei que poderiamos pensar em funcionarios que se enquadram melhor para determinada funcao. Esta ideia surgiu do jogo anterior, pois no jogo original P&P tinha um programador (Brian, numero 86) que era consultor e sofria penalidade menor quando trabalhava no codigo de outros programadores. Em contrapartida, poderiamos criar engenheiros de software que, por exemplo, aumentasse sua habilidade quando trabalhava nos requisitos (e/ou desenho). Enquanto poderiamos ter um outro engenheiro de software que fosse mais produtivo quando trabalhasse na rastreabilidade do projeto. Da mesma forma, poderiamos ter aqueles que fossem penalizados quando trabalhassem em fases que nao sao especialistas. Com o proposito principal de introduzir conceitos de evolucao de software no jogo Programadores