Time: Galine
A partir das aulas de Fundamentos da Engenharia de Software da UFRJ, ministradas pelo professor Eber Assis e com auxilio do Luis Felipe Costa, iremos desenvolver um plugin para a plataforma iEducar.
O principal objetivo desse plugin é permitir a customização de relatórios que o iEducar gera e forma automática para as escolas, de forma que o usuário consiga alterar o que deseja sem a necessidade de entrar em contato com a equipe do iEducar.
Com isso estamos utilizando o GitHub, metodologias ágeis e o Telegram para facilitar a comunicação e organização ao longo do desenvolvimento. Quanto a metodologia ágil, estamos estudando e praticando o SCRUM, utilizando o Trello para ter controle de Sprints
O desenvolvimento irá ocorrer ao longo dos meses de abril até junho e a linguagem usada será Java
| Habilidades | Aline Rezende | Gilberto Lopes | Larissa Galeno | Tomaz Cuber |
|---|---|---|---|---|
| Organização | 🌠 | ⭐ | 🌠 | ⭐ |
| Comprometimento | 🌟 | 🌟 | 🌠 | 🌟 |
| Tempo | ⭐ | 🌟 | ⭐ | ⭐ |
| Criatividade | 🌠 | ⭐ | 🌟 | 🌠 |
| Perseverança | 🌠 | 🌠 | 🌠 | ⭐ |
| Java | ⭐ | 🌠 | 🌟 | 🌟 |
| Banco de dados | ⭐ | ⭐ | ⭐ | 🌟 |
| Git/Github | ⭐ | 🌠 | 🌟 | 🌟 |
| Métodos ágeis | 🌟 | 🌟 | 🌟 | 🌠 |
| Testes | ⭐ | ⭐ | ⭐ | ⭐ |
| Documentação | ⭐ | ⭐ | ⭐ | ⭐ |
| Github | Github | Github | Github |
O gráfico indica a quantidade de horas estimadas que deveriam ser trabalhadas durante a sprint (em rosa) e quanto realmente foi trabalhado (em verde). As datas indicam o início de cada sprint.
| Atividade | Descrição | Data de entrega | Acesse |
|---|---|---|---|
| Reação 1 | Reação ao conteúdo passado na semana de 19/03-21/03. Sendo sobre metodologia ágil e canvas | 26/03 | Link |
| Canvas | Entrega do Project Model Canvas seguindo os conhecimentos e debates em sala | 26/03 | Link |
| Reação 2 | Parágrafo abordando os temas debatidos na semana do dia 26/03-28/03, sobre a ferramenta trello, o github, Mapa mental e a correção e revisão do Canvas entregue | 02/04 | Link |
| Mapa Mental | Criar um mapa mental afim de gerenciar melhor o projeto tendo em mente suas necessidades e componentes | 02/04 | Link |
| Reação 3 | Parágrafo com relação aos conteúdos dados em sala nos dia 02/04 e 04/04 | 09/04 | Link |
| Reação 4 | Parágrafo em relação aos conteúdos dados em sala nos dias 09/04 - 11/04 | 16/04 | Link |
| Caminho | Pequeno texto explicando o caminho e o objetivo que o time decidiu trilhar quando decidiu que iria continuar com relatório Customizável | 16/04 | Link |
| Sail Boat Galine | Identificar na imagem "Sail boat" quais são os elementos na realidade da equipe Gaine | 16/04 - Em sala | Link |
| Histórias | As histórias de usuários que montamos a partir de requisitos | 18/04 | Link |
| Reação 5 | Parágrafo em relação aos conteúdos dados em sala nos dias 16/06 - 18/04 | 22/04 | Link |
| Protótipo de tela | Protótipo de tela afim de realizar teste de usuários | 25/04 | Link |
| Reação 6 | Parágrafo em relação aos conteúdos dados em sala nos dias 23/06 - 25/04 | 30/04 | Link |
| Definição de Pronto | O que nosso grupo decidiu que vai ser de fato pronto entregue e pronto | 02/05 | Link |
| Reação 7 | Parágrafo em relação ao que aconteceu na aula de 02/05 | 09/05 | Link |
| Reação 8 | Parágrafo em relação ao que aconteceu na aula de 07/05-09/05 | 14/05 | Link |
| Sprint/ | Diretório no repositório da Branch do time que irá indicar o andamento das sprints, deixando claro as erapas de Planejamento, revsão e retrospectiva | 16/05 | Link |
| Reação 9 | Parágrafo em relação ao que aconteceu na aula de 14/05-16/05 | 20/05 | Link |
| Sobre a Licença GPL2 | Parágrafo explicando a licença GPL2 | 18/05 | Link |
| Reação 10 | Parágrafo em relação ao que aconteceu na aula de 21/05-23/05 | 28/05 | Link |
| HACKCOMB / Reação 11 | Espaço para documentar o ocorrido durante o evento de HackComb (Reação 11) | 30/05 | Link |
| Técnica Pomodoro | Seção com a lista de tarefas que o grupo irá usar na técnica Pomodoro | 30/05 | Link |
| Reunião com o Daniel | Reunião com o Daniel, da comunidade Sou Java, para auxiliar com alguns problemas de testes | 09/06 | Link |
| Reação 12 | Parágrafo em relação ao que aconteceu na aula de 04/06-16/06 | 11/06 | Link |
| Atividade Casos de Uso | Montar o documento de Casos de Uso referente ao Trabalho final da Disciplina | 11/06 | Link |
| Reação 13 | Parágrafo em relação ao que aconteceu na aula de 11/06-13/06 | 18/06 | Link |
| Reação 14 | Parágrafo em relação ao que aconteceu na aula de 18/06-20/06 | 25/06 | Link |
| Reação 15 | Parágrafo em relação ao que aconteceu na aula de 25/06-27/06 | 02/07 | Link |
| Reação 16 | Parágrafo em relação ao que aconteceu na aula de 02/07-04/07 | 09/07 | Link |
| Reação 17 | Parágrafo em relação ao que aconteceu na aula de 09/07-11/07, última semana | 11/07 | Link |
| Tutorial | Tutorial para o usuário sobre como usar o nosso plugin | 04/07 | Link |
| Apresentação Final | Apresentação em slides para a amostra do Software para a turma | 11/07 | Link |
| Book | Book contando sobre como foi o desenvolvimento, suas dificuldades e os materiais produzidos junto ao Software | 11/07 | Link |
Dado que a equipe optou por continuar com o trabalho de Relatório Customizável traçamos como o nosso caminho, nossos objetivos, o seguinte: um software com uma interface amigável que possibilite diferentes templates de relatório para o usuário, e com essa escolha feita a aplicação fará diferentes perguntas ao usuário para customizá-lo, ao final queremos que o relatório seja gerado em extensão de odt para então, se o usuário desejar, exportar para a pdf. As perguntas mencionadas acima seriam, por exemplo, “deseja a foto de qual lado?”, ou “nome para assinatura”, “qual a turma”, “nome do aluno” e assim por diante.
O foco do grupo, por conta do pouco tempo, será produzir um MVP, sem a preocupação de conexão com o banco, que terá pelo menos um relatório completamente funcional e operando. Tal relatório iremos escolher a partir das necessidades da Prefeitura de Caxias.
Com isso, ao final, pretendemos ter um produto que gere mais ou menos dois relatórios que não dependerá do o iEducar ou do iReports. E assim, se tivermos tempo hábil, nós tentaremos fazer a conexão com banco a fim de refinar o projeto.
Visualmente, uma tarefa é considerada pronta quando seu cartão está na lista “Done” no quadro do Trello da equipe. Em questões do ciclo de desenvolvimento, isso significa que um ou mais membros executaram tal tarefa e essa foi trazida a equipe durante a revisão da Sprint na quarta-feira e discutida juntamente ao professor orientador se ela está de acordo com o planejado para o projeto. Caso a tarefa seja relacionada a programação, ela primeiro será colocada na lista “Testing”, período no qual ela deverá passar por todos os testes definidos de acordo com a funcionalidade proposta.
Negligenciar o projeto em prol de outras matérias
Conhecimento de Banco de dados
O que fizermos ser inutilizável
Java (falta prática com bibliotecas de teste, gráficas e outras necessárias para o projeto)
Não conseguirmos conciliar os horários dos membros
As ferramentas GitHub e trello para organização e Telegram e Discord para auxiliar e ajudar nessa falta de conciliação
Apoio de especialistas na sala virtual
Compreensão e auxilio do professor e das outras equipes
Entregar uma fatia vertical da nossa visão consistente com o escopo e tempo da disciplina
Ter a wiki e uma documentação formal relevante
Produção de conhecimento, tal como, um tutorial que mostra como o Software funciona
O protótipo de tela está em construção, porém parte já pode ser visto na plataforma Figma pelo link
Pomodoro é uma técnica de Gestão de tempo que consiste em cronometrar as atividades realizadas afim de aumentar a produtividade. A seguir temos a lista de atividades que o grupo pretende fazer ao longo do HACKCOMB, seguindo o passo a passo da técnica.
| Prioridade | Atividade | Tempo | Feito? |
|---|---|---|---|
| 0 | Deixar bem documentado as atividades | 5 min | X |
| 1 | Estruturar gráfico de Barra no Relatório no relatório de Teste | 25 min | X |
| 5 | Estruturar gráfico de Pizza no Relatório de teste | 25 min | |
| 4 | Separar os alunos entre série certa e errada | 25 min | |
| 6 | Entender Testes em funções void | 25 min | |
| 7 | Entender Testes em JavaFX | 25 min | |
| 2 | Criar Layout final do Relatório | 25 min | |
| 3 | Estruturar gráfico de Barra no Relatório no relatório de Final | 25 min |
Como ponto negativo dessa dinâmica é preciso destacar a minha falta de organização, ao pegar mais tarefas do que sozinha conseguia fazer de fato; muitas vezes a questão do tempo, ou seja, quando engajava em uma etapa do projeto era preciso interromper por conta do tempo que havia acabado; e sem contar com o fato de ter participado remotamente, por conta da distância. Já como ponto positivo destaco a atividade como um todo, pois por meio dela pude ter noção e aprendizado de tarefas que a principio não eram para ser realizadas por mim, com isso pude ter uma melhor noção da dimensão do projeto; e, no momento da manhã principalmente, foi muito proveitoso para ter um contato com o repositório do projeto e com a wiki, podendo verificar e corrigir eventuais falhas que tinham na página.
Por mais que a produção de código não tenha sido no nível esperado (podendo marcar somente um dos elementos da lista do Pomodoro) é possível concluir que o dia foi produtivo e bem proveitoso, mesmo tendo esbarrado em diversos erros enquanto tentava executar outras tarefas.
É possível ler sobre as atividades ao longo do dia e como isso afetou a equipe na parte de reações (HACKCOMB), onde ao longo do dia foi documentado cada passo, dúvida e resultado de pesquisa.
| Passo | Descrição |
|---|---|
| 1 | O funcionário escolhe o relatório Relação Aluno/Ano escolar |
| 2.1 | O funcionário escolhe a Escola |
| 2.2 | O funcionário escolhe a Turma |
| 2.3 | O funcionário escolhe o tipo de Gráfico |
| 2.4 | O funcionário aperta no botão para gerar o relatório |
| 3 | O sistema apresenta uma prévia do relatório em Jasper Viewer |
| 4 | O usuário salva o relatório em .odt |
| Passo | Descrição |
|---|---|
| 1 | O funcionário escolhe o relatório Gênero/Ano escolar |
| 2.1 | O funcionário escolhe a Escola |
| 2.2 | O funcionário escolhe a Turma |
| 2.3 | O funcionário escolhe o tipo de Gráfico |
| 2.4 | O funcionário aperta no botão para gerar o relatório |
| 3 | O sistema apresenta uma prévia do relatório em Jasper Viewer |
| 4 | O usuário salva o relatório em .odt |
Dado que o grupo vinha apresentando uma certa dificuldade em conseguir manejar e projetar os testes para o nosso Software, dado que a maioria das funções não possui ou retorno, ou então, aquela que possui o tipo de retorno é complexo e difícil de ser trabalhado. O grupo, então, ao conversar com o professor Luis foi sugerido que colocássemos retornos simbólicos para as funções, para ao menos conseguirmos usar o assert do JUnit, além disso o professor conseguiu que a equipe se reunisse com o Daniel, para que ele pudesse dar ideias e bolar estratégias conosco e como resolver o problema. Dessa forma no sábado, dia 09, na parte da tarde a integrante Larissa se reuniu com o Daniel da reunião conseguiu aproveitar algumas dicas e conselhos:
Este tutorial tem o intuito de explicar as funções básicas do plugin de gerar relatório customizável para um cliente, no nosso caso, um funcionário da prefeitura de Duque de Caxias.
Ao abrir o programa, o usuário tem a possibilidade de escolher duas opções: “Relação Aluno/Ano Escolar” ou “Relação Gênero/Ano Escolar” conforme é mostrado na imagem a seguir:
Caso seja escolhida a primeira opção, o botão em questão ficará verde. Veja:
E caso seja a segunda:
Quando é selecionada a primeira opção, a seguinte página é aberta:
Nela, o usuário pode selecionar a escola desejada, seja ela uma específica ou todas as disponíveis, pode escolher a turma da mesma forma; e ainda pode selecionar se deseja um gráfico de pizza ou de barras.
Ao selecionar uma opção de gráfico, o plugin abre um visualizador do relatório, onde no canto superior esquerdo se localiza o ícone de um disquete:
Ao clicar alí, a janela de “Salvar arquivo como” aparece. Para salvá-lo em .odt basta clicar na aba “Files of Type”, selecionar a opção “ODT” e clicar em “Save”:
Se for selecionado o de barra, o relatório gerado será semelhante a este:
Se for de pizza:
Acontece de forma análoga no caso de “Relação Gênero/Ano Escolar”, veja:
E os relatórios:
Tutorial de Git rápido:
Esse tutorial tem o intuito de familiarizar os componentes do grupo que não tem intimidade com o git e instrui-los nos comandos básicos para trabalhar com a branch especifica do time, no caso a Galine.
Para começar é necessário clonar o repositório do projeto com o comando:
git clone https://github.com/luisfcosta2015/FES-UFRJ.git
Assim, se der o comadno git branch vai perceber que aparece "*master" isso indica que você está trabalhando na branch master, mas você quer trabalhar na branch Galine. Com isso, é necessário criar a branch do nosso time no seu computador:
git branch Galine (Galine significa o nome da branch que estou criando no computador)
Agora com a branch criada é preciso mudar para essa branch nova
git checkout Galine (assim você sai da master e vai para a branch Galine)
Agora se der o comando git branch irá checar que a Galine está selecionada. Dessa forma é preciso puxar o que está online para o seu computador, fazendo o seguinte comando:
git pull origin Galine (caso apareça alguma mensagem de erro pode só fechar e abrir o terminal ou git bash, o comando terá funcionado)
E com esses passos você tem a branch Galine atualizada no seu computador. Futuramente
será necessário usar somente o git pull origin Galine (desde que já esteja na branch Galine)
Agora, imaginando que já tenha trabalhado e deseja colocar suas mudanças online é
necessário fazer uma sequencia de 3 comandos:
git add . (irá adicionar todos os arquivos modificados)
git commit -m “Comentário sobre as modificações que fez” (Não colocar comentário pode gerar erro)
git push origin Galine (ira colocar na branch Galine as modificações)
Considerações finais:
Caso seja usuário de Windows recomendo baixar e utilizar o git bash, ele indica sempre em qual branch que esta fazendo modificações de forma a ter pleno controle da onde esta realizando modificacoes. Ja usuarios de Linux precisam dar o comando “git branch” para ver a branch que está trablhando.
O grupo usará como interface gráfica a biblioteca de JavaFx. JavaFX, e comparado ao Swing possui uma sintaxe simplificada por se tratar de uma linguagem de script declarativa orientada a objeto. A IDE escolhida pelo grupo, IntelliJ, já vem com a opção de criar um projeto do estilo JavaFx de forma que já vem um código introdutório de um “Hello World”, uma pequena tela que mostra essas palavras.
Alguns sites/tutoriais bons: Importante para o primeiro contato e para aprender a estilizar, mostra como funciona a integração de css com o JavaFX e sobre as vantagens que seriam usar o FXML
https://docs.oracle.com/javase/8/javafx/get-started-tutorial/get_start_apps.htm
Complementar para quem costuma usar eclipse:
http://code.makery.ch/library/javafx-8-tutorial/pt/part1/
Após começar de fato o desenvolvimento da interface com JavaFX foram encontrados diversas “pedras”. Uma delas foi o descobrimento de uma ferramenta chamada “Scenebuilder”, a princípio oferecida pela própria Oracle, que tinha o intuito de facilitar o desenvolvimento, porém foi um empecilho no início, dado que era necessário entender como a ferramenta funcionava, que gastou ao desenvolvedor 4 horas a mais do e esperada na sprint. Além disso, depois de um tempo se acostumado com a interface, foi descoberto, por meio de mais pesquisas, que atualmente é usado o Gluon Scenebuilder (http://gluonhq.com/), uma vez que o oferecido pela oracle era limitado em certo aspectos. Dessa forma, até migrar a página para uma nova ferramenta, gerou mais um gasto de tempo não previsto.
Com essas dificuldades iniciais apontadas, foram, então, enfrentadas algumas outras “rochas” no momento do desenvolvimento. Uma delas foi a questão das “Pane”, no caso do nosso projeto, o jeito mais simples que o desenvolvedor encontrou foi fazer o esquema, em ambas as páginas, foi usar uma “Border Pane” como fundo mais geral, pois possibilita o uso em separado de bordas: “top” (onde fica o titulo da página, por exemplo), “right”, “left”, “bottom” (que serviram como margens), e o “center” (local em que colocamos o conteúdo de fato da página). E quem em cada borda dessa era necessário adicionar uma nova “Pane” de forma a eu poder incluir os componentes que eu quisesse (como botões, textos e afins).
Após isso, algumas etapas foram indo mais tranquilamente, como o uso de “Label” para o um titulo, a geração e customização de botões e ações dos botões. Entretanto, no momento de desenvolver a página em que o usuário iria escolher as definições para o formulário uma grande rocha foi encontrada. Pois, o uso do Menu dropdown não é nada intuitivo. De início o desenvolvedor tentou utilizar o “Menu Buttom”, porém esse componente não possuía nenhum método simples que retornasse o item o selecionado pelo usuário (o que gastou um tempo considerável de pesquisa), assim, apoś a ajuda dos integrantes do grupo Gaara vs. Rocklee.wmv, que nos enviaram um material que ensinava como fazer exatamente o que o grupo estava buscando, porém como componente “Choice Box”, dessa forma, mudamos o componente para “Choice box” conseguindo prosseguir com o fluxo do desenvolvimento.
Algumas das referências que usamos ao longo de todo esse processo pode ser vista em:
Para a geração dos relatórios, o grupo usará o Dynamic Reports , uma biblioteca livre ( Licença LGPL ) baseada no JasperReports, cujo diferencial é a capacidade de geração dinâmica de relatórios diretamente no código Java, de modo que toda lógica implementada no código pode alterar o visual do relatório em tempo de execução. Dessa forma, a customização do relatório pode ser feita pelo usuário através da UI.
Para uma visão geral da biblioteca a partir de exemplos práticos veja a página "Getting Started"
A funcionalidade mais importante para o projeto é chamada de "relatório AdHoc". Ela permite a criação dinâmica de relatórios pelo usuário através de uma Interface conectada ao DataSource (fonte dos dados, no caso do MVP o dump local do BD do i-educar)
Organização de um projeto de relatório AdHoc:
No caso do nosso projeto, a UI não está contida em uma aplicação web e sim integrada na própria aplicação Java pelo JavaFX (isso pode ser uma dificuldade futura)
Para mais exemplos de utilização de relatórios AdHoc acesse estes links:
Nos foi fornecido pelo time de desenvolvimento do i-educar um Dump do Banco de Dados da própria plataforma para que pudessemos desenvolver com uma referência real das tabelas do projeto. Um Dump de Banco de Dados é um arquivo texto contendo comandos SQL que, quando alimentados ao SGDB, irão recrear o banco no mesmo estado do instante no qual o Dump foi criado.
O SGDB usado pelo i-educar é PostgreSQL, logo para restaurar o Dump é necessário ter o Sistema instalado em sua máquina. Em distribuições GNU/Linux uma versão do PostgreSQL provavelmente estará disponível em seu Gerenciador de Pacotes. Usuários de Windows, infelizmente terão que usar seu mecanismo de busca favorito para descobrir como instalar. Para instalar o pacote psql em distribuições baseadas em Debian (Ubuntu, Linux Mint etc):
sudo apt install postgresql-client-common
E o tutorial acaba aqui porque eu sou uma derrota.
O gráfico burndown é uma representação do trabalho a ser feito versus o tempo estimado/gasto, ou seja, é uma representação do melhor jeito possível de executar as tarefas. Ele é útil para estimarmos em quanto tempo o trabalho será concluído e é uma ferramenta muito utilizada no desenvolvimento ágil.
Várias aplicações de planilha diferentes têm a função de criar um gráfico, mas nós utilizamos o Google Spreadsheet. Basta criar uma tabela organizada por uma coluna com as datas de cada sprint e mais duas colunas para o tempo estimado e o tempo de fato utilizado. Selecionamos a tabela inteira e, pelo menu “inserir”, clicamos em gráfico, e a aplicação nos dá o gráfico pronto, com opções de customização.
Fontes:
https://www.guiadoexcel.com.br/grafico-burndown-scrum-excel/;
http://blog.nexportengineering.com/2013/07/using-google-spreadsheet-as-burndown.html#.WwWdv0gvzIV;
https://pt.wikipedia.org/wiki/Scrum_(desenvolvimento_de_software)#Burndown_Chart;
https://en.wikipedia.org/wiki/Burn_down_chart.
Para essa última sprint, sprint#12, seguimos com a missão do Banco de dados que foi possível ser concluida, só checar em nossa retrospectiva. Em questão de aula, na segunda-feira não teve conteúdo e somente o teste final da matéria e na quarta-feira será a apresentação e encerramento. O material da nossa apresentação pode ser visto em:
Devido ao jogo do Brasil na segunda-feira, 02/07, não foi possível ter a aula do professor Eber. Porém, na aula de quarta-feira, seguimos com o ritmo normal, fazendo a Retrospectiva da sprint#11 e o Planejamento da sprint#12, a última sprint. Infelizmente, não foi possível fazer a revisão do produto com o cliente, dado que para o nosso grupo e questão era importante por termos feitos algumas mudanças solicitadas anteriormente. Além disso, o professor Luis separou um momento da aula para nos dar dicas e instruir em como devemos e podemos montar a apresentação do time. Falando, também, sobre um "book" para complementar a história e trajetória do time. Algumas dessas dicas foi o arquivo pdf Cozinhando seu Conteúdo e as anotações no quadro sobre o que deveria ter:
A aula de segunda-feira do professor Eber começou com seguinte questionamento: "O que vale mais a pena, investir em uma arquitetura de Software ou seguir o método do Constroi e derruba?". Dessa forma, o professor introduziu o tema da aula, arquitetura de Software, fazendo um paralelo com projetos da Engenharia Civil, que antes de construir um prédio de fato é preciso fazer uma planta. Seguindo, para o conteúdo de arquitetura de Software é, basicamente, definir como o Software vai funcionar e que, apesar de ser mais caro fazer estar projeção depois fica mais barato para manter. E em seguida, o professor apresentou como montar a visão lógica da arquitetura a partir de diagramas, como: diagrama de classes, digrama de transição e diagrama de sequência. Já na aula de quarta-feira, dado que era dia de jogo do Brasil, a dinâmica foi um pouco diferente. O professor Luis conversou conosco a respeito do projeto e do caminho feito até o dia 27 e depois cada grupo expôs o andamento do trabalho, colocando quanto achava que tinha feito e quanto ainda poderia ser feito. E depois foi feita a dinâmica de troca de times e, novamente, tivemos a chance de conversar com o time SSL falando sobre nossos problemas com testes e para isso eles nos recomendaram o Mockito. E assim, também,iniciada a sprint#11.
Na aula do Professor Eber de segunda-feira, primeiramente, fomos relembrados sobre como a especificação forma auxilia na produção de casos de teste. Ou seja, de que maneira o relatório de Casos de uso pode auxiliar na geração de casos de Teste. A partir disso, é possível fazer um documento com casos de teste funcionais, que, assim como os Casos de uso, é dividido em algumas partes:
Desa forma, ao fim da aula, nos foi mostrado um exemplo desse documento e solicitado que tentássemos produzir o mesmo documento, porém tendo em vista o nosso projeto.
Já na aula de laboratório de quarta-feira, conseguimos fazer a Retrospectiva da Sprint#9 e o planejamento para a Sprint#10, além disso, ao fazer a revisão com a Cliente conseguimos mostrar a atualização do Software (o fato de agora estar sendo produzido relatório com gráficos de pizza) e acordamos com ela que tentaríamos produzir um novo tipo de relatório, no caso, que mostre a comparação de Meninos e Meninos por série. Também, é importante frisar que ao longo da semana foram encontrados alguns elementos externos que complicam a produção do projeto, porém que tentaremos contorna-los ao longo da sprint#10.
Na aula de segunda-feira, devido a greve dos rodoviários, a presença na aula foi baixíssima, por conta disso o professor Eber fez a escolha de cancelar a aula, porém, para os presente, ele falou sobre como o levantamento e documentação de requisitos representa 20% do custo da produção de um Software. Em seguida, falou sobre os Requisitos funcionais que são as iterações do usuário com a aplicação (feito por meio de Casos de uso) e dos Requisitos não funcionais que são as restrições no projeto ou na implementação. E assim, aproveitou para se aprofundar um pouco mais nos casos de uso funcionais, explicando que o Diagrama de Casos de uso é uma das melhores formas para ter uma visão global do sistema por dar um panorama visual. Dessa forma, explicou sobre o UML, que é uma linguagem para diagramas. Assim, para concluir, revisou sobre os tópicos que são vistos como testes no Casos de uso, a pré condição (uma expressão lógica, logo se falhar não pode ocorrer) e a pós condição (uma expressão lógica que se tornará verdadeira depois).
Já na aula de quarta, de laboratório, o professor Luis pediu para que os grupos compartilhassem alguns do problema e tentassem se ajudar. No caso, nossa equipe conversou com a o time SSL, onde podemos conversar mais sobre o JUnit, recomendando esse tutorial para preparar o ambiente de teste na IDE que estamos usando. E na hora da volta, eles conversaram sobre como estão trabalhando com o banco de dados, explicando que, na verdade, não estão usando o Dump do Banco de dados, e sim o próprio iEducar, tendo que instalar o sistema para conseguir usar o banco, com isso eles nos recomendaram o seguinte tutorial, caso fossemos usar a mesma estratégia que eles. Por fim, seguimos com a retrospectiva da Sprint#8 e a revisão do Casos de uso com a cliente.
Na aula de segunda-feira, dado que havia um tempo que não tinha aula, o professor Eber iniciou revisando os métodos para gerar casos de teste e suas definições, ou seja, o método da Caixa Preta em que o teste é feito pela especificação e o da Caixa Branca que o teste é feito a partir do código fonte. Prosseguindo com o conteúdo novo, o professor fez o questionamento de “Como especificar o Software?” dando várias explicações de se pode facilitar o processo de especificação:
Dessa forma prosseguiu para para o Casos de uso que é um tipo de especificação que funciona como uma “História arrumada”, como o próprio professor disse.O relatório de Casos de é dividido em diferentes partes:
Assim, prosseguimos a aula com um esboço do que seria o caso de uso do nosso Software que estamos produzindo na matéria:
Já na quarta-feira (06/06), seguimos com o Sprint Review da sprint#7 que foi a sprint do HackComb, os detalhes podem ser vistos . E assim, demos início a sprint#8.
Dado a âncora que surgiu de última hora, a falta de combustível de última hora, o professor Luis conseguiu bolar uma forma de transformar essa âncora em um vento, surgindo com a ideia do HACKCOMB. A ideia é funcionar como uma espécie de Hackaton, um vez que as aulas foram suspensas por conta da greve era uma boa oportunidade de fazer com que os alunos se juntassem afim de dar uma avançada com o projeto por meio de colaboração com outros times, seja presencial ou remotamente (que é o caso da nossa equipe).
O dia foi separado em atividades, tendo um Hangout de abertura e a primeira atividade sendo para "ajeitar a casa", ou seja, checar a wiki e entender melhor a integração da plataforma git com o projeto, depois disso será realizada outra reunião afim de prosseguir com as próximas atividades. Após essa reunião prosseguimos para atividade de documentar o Pomodoro na wiki, que pode ser visto aqui. Com isso seguimos para um intervalo de 15 min. Assim seguimos para a tarefa de "Executar Tarefas Issues", que foi interpretada da seguinte forma: executar as tarefas chaves e problemas do projeto, ou seja, pontos chaves de desenvolvimento que atrapalham o projeto, essas tarefas foram: completar o Pomodoro com as atividades e começar a pesquisar como as tarefas que estão no Pomodoro podem ser realizadas. A seguir tivemos o terceiro Hangout do Hackcomb em que nos foi passada a próxima tarefa, que era definir as prioridade da atividade do Pomodoro seguindo, então, para a hora do almoço que só acabaria as 13:45. Nesse horário retornamos as atividades, começando a partir da lista de prioridade do Pomodoro, no caso da equipe a prioridade é deixar bem documentado tudo que está ocorrendo (por meio desse texto na wiki) e partindo para e assim partindo para outra prioridade até o próximo encontro pelo Hangout. Nesse encontro batemos um papo sobre pontos negativos e positivos e tivemos a apresentação do Elvis sobre Testes para seguir para a atividade em grupo de Testes, em que seriamos divididos em grupos para tentar entender e aprimorar a situação do projeto com Testes de Unidade e em assuntos que os grupos estavam complicados. No caso, o grupo Galine (Larissa) se juntou com o Gaara vs. RockLee (Pedro Nascimento) em que discutimos bastante sobre a relação interpessoal da equipe e como isso afeta os projetos das equipes e JavaFX. E depois a dupla Galine VS. Gaara vs. RockLee prosseguiu com a discussão sobre Testes, chegando a duas dúvidas comuns que podem ser vistas abaixo. Assim, prosseguimos para o final do dia, em que os times dividiram os pontos negativos e positivos (no caso da equipe pode ser visto aqui), fazendo assim, a conclusão da atividade
Pesquisando sobre git e sua integração com o projeto:
Como o git é uma ferramenta de versionamento de código, ou seja, um grupo de pessoas trabalhando simultaneamente em um projeto a funcionalidade Pull Request da Ferramenta funciona como uma forma de um dos programadores avisarem ao resto da equipe que ele acabou ao trabalho e que gostaria de integra-lo na master. A funcionalidade também mostra as diferenças entre a versão que está na master e a versão que está "em pull request"
A funcionalidade de "Issues" da ferramenta funciona, basicamente, como uma checklist. O objetivo principal dela seria colocar Bugs e ir marcando a medida que forem consertados, porém seu uso pode ir muito além disso. No HACKCOMB o professor usou tal funcionalidade para colocar as tarefas que seriam realizadas ao longo do dia, de forma a organizar entre os grupos o que seria feito.
Sobre Testes: após a apresentação do aluno Elvis algumas dúvidas ainda ficaram pendentes:
1) Como lidar com funções que possuem retornos dinâmicos mesmo que seja passado os mesmos parâmetros? Por exemplo, tenho uma função no código que ela retorna um objeto do tipo JRDataSource e ao imprimir no console vejo que a cada impressão o valor da variável é diferente mesmo que o parâmetro passado seja sempre o mesmo
2) Entender o Mockito de forma geral e tentar usa-lo com o JavaFX para o teste de interface
A licença GNU/GPL 2 é uma versão de 1991 da Licença Pública Geral do GNU. Essa é uma licença de software que oferece proteção dos direitos autorais ao autor do programa além de garantir as liberdades do usuário de executar o programa para qualquer propósito; de estudar o funcionamento do programa e alterá-lo como bem entender (acesso ao código-fonte é um pré-requisito para tanto); de redistribuir cópias do programa em qualquer meio ou mídia (inclusive cobrando um valor por esse ato) & a liberdade de distribuir cópias de suas versões modificadas para outros. Entretanto, qualquer cópia do programa ou obra baseada no programa programa deve também ser licenciada nos termos da GNU/GPL e conter avisos da modificação dos arquivos e datas das modificações. Além disso, é importante destacar que a licença GPL não provê garantia de qualquer tipo ao programa, sendo os riscos quanto à qualidade e desempenho do programa assumidos pelo usuário.
Na aula de segunda-feira, 21/05, o foco maior foi no entendimento de verificação caixa branca. Com isso, nos foi introduzido os diferentes tipos que o teste caixa branca possui:
Entretanto, devido ao tempo curto, na aula nos aprofundamos em Cobertura de Comandos e Caminho básico. Assim, a partir da exposição do professor Eber pode-se concluir que a Cobertura de Comandos não é nada efetiva, dado que é testado se o comando foi executado pelo menos uma vez; e o Teste do caminho básico, onde foram apresentados alguns conceitos: Grafo de Controle, Caminho independente, Complexidade Ciclomática. E além disso, foi nos dado um roteiro de como derivar os casos de de teste.
Em complemento a isso, no início da aula, o Professor Eber deu uma breve explicação sobre a diferença entre o teste de Regressão o teste de Fumaça, dado que o de regressão era demorado e custoso computacionalmente, surgiu, então, o teste de Fumaça que pode ser feito diariamente para checar se tudo que foi feito no dia anterior continua funcionando.
Já na aula de quarta foram feita as três etapas da Sprint a retrospectiva, revisão, e planejamento, que pode ser acompanhado com mais detalhe no repositório da equipe. Porém, devido a greve dos caminhoneiros, alguns membros da equipe não puderam estar presente e a revisão com o cliente fora comprometida.
A aula do professor Eber, dia 14/05, nos deu como base algum dos conceitos mais importantes da área de testes:
E com isso seguimos para a Definição formal de Testes e para mais conceitos que são usados na prática de Testes:
Com esses conceitos em mente, na aula prática de quarta-feira foi debatido qual ferramenta de teste seria utilizada pela disciplina, com isso segue a pesquisa feita pelo grupo em JUnit (a principio ferramenta escolhida para teste) e algumas ferramentas pesquisadas para a confecção de Testes no front-end.
JUnit, rudimentarmente falando, consiste em Testes de Unidade de Java, assim como o PyUnit serve para Python, Cutest para C. Testes de unidade, em geral, possui o foco de testar menor unidade do software por partes e é costumeiro que esses testes sejam feitos antes do produto estar terminado. A partir desse teste pode-se ter diferentes tipos de teste sendo feito: caminhos possíveis, condições de contorno, tratamentos de erros.
Para fazer testes em unidade Java, de maneira simples, é preciso criar uma classe de Teste para o método específico, e nessa classe o programador irá criar diferentes funções para testar diferentes aspectos de um módulo. E isso, muitas vezes,é feito pelo método assertEquals(esperado, resultadoReal) esse método, que faz parte da classe Assert, irá verificar se o resultado é de fato o esperado.
Refêrencias:
- https://stackoverflow.com/questions/8751553/how-to-write-a-unit-test - O passo a passo explicado de forma resumida sobre como montar um teste
- https://www.devmedia.com.br/junit-tutorial/1432 e https://www.tutorialspoint.com/junit/junit_test_framework.htm - Contribuiram para o entendimento geral do conceito de testes
- http://www.vogella.com/tutorials/JUnit/article.html - um tutorial melhor explicado e mais extenso sobre como criar um teste de fato
Como sugerido por um dos especialistas em Java, como opção para testes de Interface temos o Frologic (https://www.froglogic.com/squish/free-trial/), que serve para automatizar os testes e a ferramenta auxilia, pois com ela é capaz de gravar os testes gerados e revisar o passo a passo.
Porém, existem as classes chamadas TestFX que foram feitas para teste de unidade de aplicações que usam JavaFX. Para esse caso, tais referências podem ser vistas: https://medium.com/@mglover/java-fx-testing-with-testfx-c3858b571320 que explica o passo a passo de como criar esse teste e uma refêrencia relevante é a wiki do gitHub do TestFX https://github.com/TestFX/TestFX/wiki/Getting-Started.
Além disso, também é possível fazer o teste do JavaFX a partir do próprio JUnit, pelo o JavaFX tratar de uma ferramenta MVC (model-view-controller), que pareceu mais complicado que o caso do TestFX, algumas referências seria: https://dzone.com/articles/junit-testing-spring-mvc-2 e https://krishnasblog.com/2013/02/21/junit-testing-of-spring-mvc-application-testing-frontend-using-selenium/.
Na segunda-feira, dia 07/05, o Professor Eber começou a nos apresentar o conceito e conteúdos sobre Testes De Softwares. Mostrando que a qualidade de um produto é feito é certificada ao longo do processo de testes, e também apontando características gerais de processos de teste: Nível, Diferentes técnicas, Atores e Depuração. E com isso ele introduziu as diferentes estratégias de teste que existem, como testes de unidade por exemplo. Porém, por conta do tempo, ele irá finalizar essa parte na próxima aula de segunda-feira.
Já na quarta-feira, por ser aula de laboratório, infelizmente dois membros do grupo tiveram que se ausentar por razões médicas, porém em aula o professor Luis e colaboradores, especialistas em Java, deram o auxílio necessário para que a Sprint review e dúvidas fossem sanadas de forma urgente.
Como 01/05, terça-feira, foi feriado do dia do trabalho não tivemos aula na segunda-feira, de forma que a única aula da disciplina fosse na quarta dia 02/05.
Nessa aula de laboratório seguimos os mesmos procedimentos da última, fazendo a sprint review, porém como os membros da equipe tiveram a semana complicada por conta de provas de cálculo o desempenho da sprint foi extremamente baixo, dado que não conseguimos fazer nada do que estava na Sprint Backlog. Com isso, afim de minimizar danos, na aula produzimos o parágrafo referente a aula da semana passada (25/04) e a definição de pronto.
Como não conseguimos cumprir com o objetivo da segunda Sprint, para a Sprint 3 (que é para ser finalizada em 9/05) deixamos as tarefas faltantes da Sprint 2, porém reorganizando a divisão de tarefas. Dessa forma, pretendemos voltar mais engajados e entusiasmados com o projeto para que na Sprint 4 ocorra o planejado.
No dia 25/04, quarta-feira, aproveitamos para fazer a revisão e retrospectiva da Sprint 1. Os integrantes revisaram o que foi feito, passando do campo “done” para entregue (definição de pronto). A Sprint 1 consistia em tarefas sobre compreensão de tópicos obscuros para o time (como JavaFX e o espelho do banco), prototipação e reação da semana anterior, porém na aula percebemos que algumas dessas tarefas não puderam ser realizadas, ficando como atraso para a sprint 2 (no trello da equipe é possível ver se a atividade está atrasada caso ela esteja com uma etiqueta vermelha).
Com isso, para a sprint 2 ficamos de atraso com:
- Burndown da sprint 1
- Fazer a interface da tela home.
- Definir o número de páginas.
- Compreender o espelho do banco.
- Compreender o Dynamic Reports, uma bibilioteca para geração de relatório.
Além disso para Sprint 2 colocamos para fazer a definição de pronto, a reação da semana e o gráfico de burn down da sprint 2.
Nesta semana do dia 16/04 ao dia 18/04 tivemos um maior contato com a prática de metodologias ágeis, o SCRUM. Na segunda-feira, dia 16, fizemos uma reflexão tendo em vista a imagem do barco, identificando nossos riscos, ajudas que podemos ter, atrasos e objetivos. Com isso, mais os nossos requisitos montamos a nossa sprint#0 e o backlog. Com a sprint#0 definimos o tempo diário que dedicaremos ao projeto, definimos funções para cada integrante, como quem cuida da wiki, por exemplo e, por fim, delimitamos as nossas ferramentas: IntelliJ para o ambiente de desenvolvimento, Google Sheets para a confecção de Burn Down charts, Discord para reunião e o Telegram para a nossa Daily Review, que consiste em um bot que manda mensagem diariamente em um horário fixo para nós verificarmos o que foi feito. Já na quarta-feira, a aula começou com o Professor Luis nos mostrando um video de como fazer o Burn Down chart e, assim, demos prosseguimento com o prática de metodologias ágeis refinando o Backlog e colocando-o no Trello e definimos e criamos nossas histórias de usuário. No fim da aula definimos as nossa primeira Sprint, que também pode ser acompanhada pelo Trello, a fim de começar o desenvolvimento. Com isso a sprint tem atividades dedicadas a compreensão de assuntos ainda meio obscuros, prototipação de tela e produção de conteúdo, com o prazo de até 25/04.
No dia 09/04 ocorreu um segundo momento de levantamento de requisitos com Prefeitura de Caxias com a presença, novamente, da Sandra e da Poliana, membro equipe de desenvolvimento da prefeitura. A intenção era nos familiarizar com o funcionamento do iEducar e como as escolas o utilizavam, em meio a essa apresentação vimos que o iEducar não era usado de forma independente, o software iReports era usado para auxiliar na geração de relatórios. Os principais problemas que elas apontaram que nós do time focamos foram: a questão de “title” e “page header” não estarem bem definidos dependendo de qual relatório está trabalhando, o mesmo para “page footer” e “last page footer”; o fato do relatório não ser responsivo; e a ausência de um arquivo que apresentasse os dados em forma de gráfico. Ao final dessa aula a Poliana mostrou, rapidamente, como funciona a questão do banco de dados e o problema de se trabalharem com mais de 178 tabelas. Já na quarta-feira, 11/04, a primeira hora da aula foi dedicada para reparar confusões e mal entendidos da última aula quanto ao projeto, de forma que uma segunda proposta de trabalho fora apresentada (software para controle de merendas). Porém, o time Galine continuará com a proposta do Relatório Customizável e traçamos o nosso caminho de projeto. Com isso, ao fim da aula, o professor Luis nos apresentou a imagem do “Velejador” explicando seu significado, como a ancora e riscos e o vento sendo incentivo.
A aula de segunda-feira foi introduzida com um vídeo explicando a importância sobre testes de usabilidade e como é barato fazer, uma vez que é possível e comum fazer a prototipagem inicial com o papel e checar se a interface realmente está intuitiva e amigável para o usuário. Partindo para o final da aula tivemos a visita da Sandra, representante da prefeitura de Caxias, em que tivemos a possibilidade de fazer um levantamento de requisitos e fazer as devidas anotações. Na aula de quarta, primeira aula no Laboratório, utilizamos para organizar o trello de acordo com a maneira de desenvolvimento do Kanban e fazer uma pequena introdução sobre o funcionamento do Git para os outros membros que não tinham contato. Além disso, ao fim da aula, o professor nos introduziu ao que era Sprint #0, que tem a função de nos organizar e colocar o grupo na mesma página para, enfim, começar o desenvolvimento.
Na segunda-feira, 26/03, no inicio da aula fomos apresentados de maneira formal à ferramenta Trello. Uma vez que o Professor Luis Felipe nos mostrou como exemplo um board de um projeto que trabalhou, nos mostrando o conceito de boards, cards, backlog, sprints e também dando dicas de como poderíamos organizar o nosso com cores e os possíveis cards, sendo esses: um para o backlog, outro para sprint atual, um para “fazendo”, testes e “feito”. Em seguido o professor abriu conosco a página do GitHub, nos instruindo a criar uma wiki para cada time e mostrando exemplos de como deveria ser feito, e também mostrando tutoriais para lermos afim da turma se familiarizar mais com o ambiente do git e seus comandos. E de forma a concluir a aula, tivemos um momento de interdisciplinaridade de filosofia e literatura com desenvolvimento de Software, com o Luis nos mostrando conceitos e principais traços dos movimentos literários do Renascimento e Modernismo. Já na quarta-feira, 28, a aula começou com uma introdução e um pouco da história a respeito da linguagem Java, explicando sua origem e história. Em seguida passamos para a etapa de correções e arrumações do Canvas a partir das dicas e toques do Professor Luis. Nossa equipe recebeu destaque no campo do SMART Objective e tivemos que dar mais atenção aos campos de Linha do Tempo e Requisitos, por estarem deficientes.
O modelo de Desenvolvimento Ágil lida, principalmente, com a problemática do escopo em projetos de desenvolvimentode software. Em modelos clássicos de desenvolvimento em cascata o escopo é fixamente decidido após serem levantados todos os requisitos do cliente de apenas uma só vez. Porém, devido a própria natureza do software como produto, a mudança nas necessidades (tanto de componentes essenciais a serem incluídos, quanto de inúteis a serem removidos) do projeto é um fênomeno quase garantido. Os modelos ágeis resolvem esse impasse através do desenvolvimento iterativo e incremental: iterativo no sentido de acompanhamento cíclico e constante do cliente na forma de entregas periódicas; e incremental uma vez que as partes do produto são desenvolvidas separadamente, integrando mais facilmente com o todo. Para nosso projeto para a plataforma i-educar, optamos por usar o SCRUM como metodologia de desenvolvimento. Para isso, criaremos e manteremos um BACKLOG composto de tarefas pequenas que possam ser completadas em um tempo fixo de tempo por membros diferentes, que também serão modificadas de acordo com os requisitos levantados no encontro com o cliente e as dificuldades que tivermos ao longo do processo. Essas serão então ordenadas por prioridade e passaram a compor uma SPRINT, períodos de uma semana nos quais serão resolvidas e integradas ao projeto como um todo, ajustando o todo sempre que necessário e realizando testes. Esperamos que, com a sequência de Sprints, possamos constantemente entregar um produto funcional que traga à tona novas oportunidades de melhorarmos o produto final.