=========== MILESTONE 2 =========== ======================== Andre Henrique - Raphael ======================== testes de aceitação: 10,0 código: 9,5 - o código dos dois métodos getPagamentos em Sistema continua repetido - deu pra entender pulaFaixa, mas dá pra ficar mais simples, p.ex., com um mapa das faixas (apenas observação) design: 10,0 documentação: 10,0 relatório: 10,0 ============= Alan - Rafael ============= testes de aceitação: 10,0 código: 9,5 Obs.: os testes de unidade criados não são necessários, porque os testes de aceitação já cobrem (continua com os testes do milestone anterior) design: 9,0 - crie exceções diferentes para cada situação, e não lançar sempre KarateKidException documentação: 10,0 relatório: 8,5 - faltam atributos no diagrama de classes - não precisa detalhar os métodos novos que vocês criaram no texto do relatório (dá pra entender isso no código), mas não foram tirados pontos por isso; detalhem mais os patterns que vocês usaram, por que usaram, ou, se não usaram, por que não foi preciso =================== Anderson - Jeysibel =================== testes de aceitação: 10,0 código: 10,0 design: 10,0 documentação: 10,0 - capricharam na documentação desta vez relatório: 9,5 - faltaram os atributos das classes no diagrama UML ============ André - Luiz ============ testes de aceitação: 10,0 código: 9,5 - getPagamentos' têm código repetido design: 10,0 documentação: 8,5 - várias classes não têm descrição relatório: 9,5 - faltaram os relacionamentos no diagrama de classes =============== Carlos - Samuel =============== testes de aceitação: 10,0 código: 9,5 - códigos repetidos nos getPagamentos' design: 9,0 - verificaValorPagamento deveria estar em Pagamento (e similares tb; não usou bem o Expert) documentação: 10,0 relatório: 8,5 - só usaram composição e expert? descrever por que outros patterns não foram necessários - faltam atributos no diagrama de classes, e há mais métodos importantes das classes não mostrados ===== Cesar ===== testes de aceitação: 10,0 código: 10,0 design: 9,0 - falta hierarquizar as exceções (só há CarateException para todas as situações) documentação: 10,0 relatório: 9,0 - faltam atributos e métodos no diagrama de classes =============== Danilo - Thiago =============== testes de aceitação: 10,0 código: 9,5 - números mágicos em Data design: 9,0 - usaram herança entre Aluno e Pessoa documentação: 10,0 relatório: 9,5 - faltam alguns atributos e métodos no diagrama de classes =================== Demetrio - Fabricio =================== testes de aceitação: 7,0 - 18 erros em us4 (resultados de comando "saldo" desconhecido), 2 erros em us4_1, 3 erros em us7 código: 9,0 - não entendi por que o lançamento de exceções é feito em SistemaDeTratamentoDeErros (?) design: 9,0 - falta hierarquia de exceções documentação: 9,0 - falta a documentação de Sumario, SistemaDeTratamentoDeErros, etc. relatório: 6,0 - falta diagrama de classes =============== Rafael - Tiago =============== testes de aceitação: 10,0 código: 10,0 design: 10,0 documentação: 9,0 - não há documentação das classes, só dos métodos relatório: 10,0 =============== Rodrigo - Arthur =============== testes de aceitação: 10,0 código: 9,5 - falta organizar as classes em pacotes design: 10,0 documentação: 10,0 relatório: 9,5 - não dá pra ver o diagrama de classes; tentem fracionar a imagem, ou usar uma resolução maior ========================== Rodrigo Justino - Vinicius ========================== testes de aceitação: 10,0 código: 9,0 - melhorar código de alguns métodos, como transformaEmData() de Data design: 9,0 - continuam usando herança entre Aluno e Pessoa documentação: 8,0 - falta documentar métodos de algumas classes, como Sisac - falta documentar as classes e pacotes relatório: 8,0 - foi impossivel analisar os diagramas, mesmo colocando no zoom máximo ================ Taciano - Romulo ================ testes de aceitação: 10,0 código: 9,5 - organizar classes em pacotes design: 9,0 - continuam usando herança entre Aluno e Cliente documentação: 10,0 relatório: 10,0 ============= Wilson - Davi ============= testes de aceitação: 10,0 código: 9,5 - organizar código em pacotes design: 10,0 documentação: 9,0 - falta comentar alguns métodos em Sistema - falta documentar as classes relatório: 8,5 - explicar melhor a seção dos patterns - diagrama de classes faltando atributos =========== MILESTONE 1 =========== ======================== Andre Henrique - Raphael ======================== testes de aceitação: 10,0 código: 8,5 - cascatas de ifs nos metodos "verifica.." - repetição de código não testado nos getPagamentos design: 9,0 - usaram herança na implementação de pessoa e aluno documentação: 10,0 relatório: 10,0 ============= Alan - Rafael ============= testes de aceitação: 10,0 código: 8,5 - cascatas de ifs em Gerencia - não precisa de testes de unidade, os testes de aceitação já cobrem - duplicacao n/m1-20/Data.java (75%) n/m1-20/Verificador.java (35%) 70 nao tirei pontos - pouca duplicacao design: 6,5 - usou herança entre Pessoa e Aluno - falta a Façade documentação: 10,0 relatório: 2,0 - o relatório deve conter a descrição dos patterns usados, não das user stories - o diagrama de classes deve fazer parte do relatório, e deve conter informações sobre os atributos e métodos principais das classes, não apenas seus nomes e traços que não dão informação sobre os relacionamentos =================== Anderson - Jeysibel =================== testes de aceitação: 10,0 código: 9,5 design: 10,0 documentação: 8,0 - falta a documentação da Façade e de métodos em outras classes relatório: 10,0 ============ André - Luiz ============ testes de aceitação: 10,0 código: 8,5 - cascatas de ifs design: 9,0 - usaram herança entre Cliente e Pessoa documentação: 9,0 - falta documentar a Façade relatório: 10,0 =============== Carlos - Samuel =============== testes de aceitação: 10,0 código: 8,0 - cascata de ifs - repetição de código design: 9,0 - usaram herança entre Aluno e Cliente documentação: 10,0 relatório: 4,0 - o relatório deve conter a descrição dos patterns usados - o diagrama de classes deve conter informações sobre os atributos e métodos principais das classes, não apenas seus nomes ===== Cesar ===== testes de aceitação: 6,0 - erros em us1_2, us2_1 e us3_1 código: 9,0 design: 10,0 documentação: 10,0 relatório: 7,5 - diagrama de classes deve conter métodos e atributos importantes de cada classe =============== Danilo - Thiago =============== testes de aceitação: 10,0 código: 8,5 - cascata de ifs design: 9,0 - usaram herança entre Aluno e Pessoa documentação: 10,0 relatório: 8,0 - faltam métodos no diagrama UML =================== Demetrio - Fabricio =================== testes de aceitação: não consegui testar código: 9,0 design: 9,0 - usaram herança entre Pessoa e Aluno documentação: 8,0 - falta a documentação da Façade relatório: 6,0 - falta diagrama de classes =============== Rafael - Thiago =============== testes de aceitação: 10,0 código: 8,0 - cascata de ifs - testes de unidade não servem para nada design: 9,0 - usaram herança entre Aluno e Pessoa documentação: 8,0 - falta documentar a Façade e outras classes relatório: 7,5 - diagrama de classes deve conter atributos e métodos importantes de cada classe =============== Rodrigo - Artur =============== testes de aceitação: 10,0 código: 8,5 duplicacao n/m1-27/PagamentoCash.java (96%) n/m1-27/PagamentoCheque.java (96%) 75 n/m1-27/PagamentoCartao.java (96%) n/m1-27/PagamentoCheque.java (96%) 75 n/m1-27/PagamentoCartao.java (96%) n/m1-27/PagamentoCash.java (96%) 75 design: 9,0 - usaram herança entre Aluno e Pessoa documentação: 10,0 relatório: 10,0 ========================== Rodrigo Justino - Vinicius ========================== testes de aceitação: 10,0 código: 8,5 - cascatas de ifs design: 9,0 - usaram herança entre Aluno e Pessoa documentação: 8,0 - falta documentar a Façade e alguns métodos de outras classes relatório: 6,0 - falta diagrama de classes ================ Taciano - Romulo ================ testes de aceitação: 10,0 código: 8,5 - cascatas de ifs design: 9,0 - usaram herança entre Aluno e Cliente documentação: 10,0 relatório: 10,0 ============= Wilson - Davi ============= testes de aceitação: 10,0 código: 9,0 design: 9,0 - usaram herança entre Cliente e Pessoa documentação: 10,0 relatório: 9,0 - explicar melhor a seção dos patterns