Time: Celta 80km\h
Somos o grupo Celta 80 km/h e nossa missão é absorver todas as lições das aulas de Fundamentos de Engenharia de Software ministradas em 2018.1 na Universidade Federal do Rio de Janeiro e transformá-las em um plug-in sensacional para a plataforma i-Educar. A plataforma já é implementada em centenas de escolas da rede pública por todo o Brasil e saber que nosso trabalho pode melhorar de certo modo a educação do nosso país nos motiva.
Vamos expor aqui todo o nosso progresso na elaboração do plug-in, resumindo aulas e gerando subprodutos que irão nos auxiliar na montagem do projeto sempre que requisitado por nosso orientador, Luis Felipe Coimbra Costa. Esta página também servirá como uma central para toda outra informação pertinente acerca do projeto supracitado.
Desenvolvedor e Relações Públicas (Música)
Scrum Master (Co-piloto)
Product Owner (Carona)
Designer (GPS)
Desenvolvedor (Piloto)
Desenvolver uma extensão para formatar relatórios gerados pelo software livre i-Educar.
| Produto | Descrição | Entrega |
|---|---|---|
| Canvas | Canvas Montado Cooperativamente | 26/mar |
| Resumo I | Resume aulas dos dias 19-21/03. Sobre manifesto ágil e scrum. | 26/mar |
| Resumo II | Resume aulas dos dias 26-28/03. Sobre processo de software e Canvas. | 02/abr |
| Mapa Mental | Mapa mental sobre o projeto da disciplina | 02/abr |
| Resumo III | Resume aulas dos dias 09-11/04. Discussão sobre o rumo do projeto tendo em vista os problemas apresentados por Caxias | 16/abr |
| Metáfora Barco | Análise da metáfora do barco aplicada ao nosso time | 29/abr |
| Histórias de Usuário | As Histórias de Usuário identificadas pela equipe até o momento | 29/abr |
| BurnDown Chart | Gráfico burndown chart do desenvolvimento por membro | 18/mai |
| Resumo IV | Resume as aulas dos dias 14/05 e 16/05, cujo tema foi testes | 22/mai |
| Casos de uso | Casos de uso desenvolvidos para o dia 10/06 | 10/jun |
| Casos de teste | Caso de teste desenvolvido para o dia 03/07 | 03/jul |
| História | Status |
|---|---|
| Eu como diretor quero gerar relatórios nos formatos pdf, excel e odt para me adequar a qualquer situação | To do |
| Eu como diretor quero gerar o relatório de maneira sequencial para ter mais praticidade | Done |
| Eu como diretor quero poder lançar atualizações diárias para poder não ter todo o trabalho de uma vez | Done |
| Eu como diretor quero poder editar dados já lançados para que não tenha que gerar um novo relatório do zero em caso de erro. | Done |
| Eu como diretor quero poder me referenciar apenas ao mês e ano para gerar a página do cardápio para que não tenha que olhar no calendário. | Done |
| Eu como diretor quero cadastrar os dados da minha escola de forma a não ter que ficar repetindo-os em todos os relatórios. | Done |
| Eu como diretor gostaria que cálculos usando dados pré-inseridos fossem feitos pelo sistema para que eu tenha mais praticidade. | Done |
| Eu como diretor gostaria de lançar diretamente os itens usados no cardápio para que não gaste tempo procurando um a um na tabela. | Done |
| Eu como administrador quero poder mudar aspectos do modelo de relatório a fim de que todos os computadores utilizem o novo modelo | To do |
| Eu como leitor quero poder filtrar os relatórios por escola para facilitar minha busca | Done |
| Eu como leitor quero poder filtrar os relatórios por mês de referência para facilitar minha busca | To do |
| Eu como usuário do sistema gostaria de poder ter acesso ao sistema através de um login e senha a fim de que possa trabalhar efetivamente. | Done |
| Eu como administrador quero poder gerar novos perfis a fim de que possa dar acesso a outras pessoas de acordo com seu nível de acesso. | Done |
| Eu como usuário gostaria que todos os arquivos fossem salvos em um banco de dados para centralizar a informação. | Done |
| Eu como usuário quero poder interagir com uma tela de login a fim de que a aplicação fique mais intuitiva e organizada | Done |
| Eu como administrador quero adicionar e modificar permissões por tipo de usuário para que tenha mais liberdade de modificar futuramente. | Done |
| Eu como administrador quero poder editar os dados de um usuário existente no banco de dados para que não precise excluir em caso de perda de senha. | Done |
| Eu como administrador quero poder excluir um usuário do banco de dados para que possa remover o acesso ao sistema de alguém | Done |
| Tipo de teste | Classe | Resultado |
|---|---|---|
| Unitário - I.M. | Calendario |  |
| Unitário - I.M. | Escola |  |
| Unitário - I.M. | MaisEducacao |  |
| Unitário - I.M. | Permissoes |  |
| Unitário - I.M. | RefeicoesDados |  |
| Unitário - I.M. | Relatorio | --- |
| Unitário - I.M. | TelaCadastro |  |
| Unitário - I.M. | TelaLogin |  |
| Unitário - I.M. | TiposDeUsuario |  |
| Unitário - I.M. | Usuario |  |
I.M. - Interfaces do Módulo
- Organização de tarefas - Descobrimos para que serve o pull request e sua importância no uso do git para integração, como nosso projeto ja estava integrado no git, não precisamos fazer esta etapa.
- A organização de pomodoro ajuda a separar as tarefas de forma coesa e simples :), contudo limita o tempo o que pressiona a finalização das tarefas.
- Após o intervalo a issue a ser feita era Executar tarefas, que nós interpretamos como sendo terminar as tarefas da sprint anterior ou fazer o sprint planning. Optamos por fazer o sprint planning.
- Backlog: Configurar o banco no pc, Configurar os botões da tela Principal para só aparecer as opções permitidas ao usuario, Conectar todas as partes do codigo no BdManager, conseguir gerar o Relatorio nos formatos de texto, Terminar de colocar as informações da capa relatorio
- Conversa entre times: foi de muita utilidade a conversa entre times, pois pudemos ver como outros times estavam tratando a ideia dos testes unitários usando junit e mockito.
- Testes: estávamos muito perdidos sobre como faríamos para automatizar os testes de interface, mas não tínhamos percebido que já podíamos ter começado com os testes de unidade, utilizando o JUnit e o Mockito. Como estamos usando a IDE Netbeans e a mesma possui integração com JUnit, criar os testes de unidade acabou se tornando uma tarefa muito menos complicada do que parecia a princípio. Nos testes de unidade, testaríamos método por método de cada classe.
Fotos:
Metodologia ágil é um modelo de esquematização e execução de projetos de maneira muito mais eficiente e comunicativa do que as clássicas. Uma das maneiras de executar o projeto por esta metodologia é utilizando o scrum, que em reuniões periódicas, normalmente semanais, mas com prazo máximo de um mês (não mais que isso), decide uma sequência de tarefas a serem executadas (sprints) além de estabelecer de maneira mais ampla tudo que deve ser executado pensando em seus prazos de entrega, a fim de cumprir com os requisitos dentro de seus prazos.
Esta maneira de ver o projeto de uma maneira mais geral, estabelecendo metas a longo prazo, é chamada de BackLog e são nas tarefas definidas neste que é decidida e divida a sprint entre todos os desenvolvedores do grupo. Já os requisitos representam todas as características e funcionalidades que um determinado software possui, tais como, ter uma interface amigável, ter uma opção de modificar todas as palavras selecionadas por um outra específica ou um pedido do usuário, como a solicitação de que haja um botão na cor de rosa no canto inferior esquerdo.
Um modo amplamente difundido e conhecido de se aplicar a metodologia ágil no processo de idealização do projeto é utilizando o project model canvas, que tenta responder de maneira colaborativa e organizada em pequenos blocos as perguntas fundamentais do mesmo: Por que?, O que?, Quem?, Como? e Quanto?
Duas equipes podem ter como resultado final da elaboração dois Canvas completamente diferentes, mesmo que o contexto, as condições base e o projeto seja o mesmo. Isto acontece pois a elaboração bastante subjetiva e depende muito de como cada equipe olha para o projeto como um todo.
Entretanto, existem aspectos fundamentais que não podem deixar de estar presente em todos os canvas, o que poderíamos chamar de “pontos chaves”. Um exemplo é o fato de o product owner sempre aparecer presente na equipe, pois pelo modelo de processo SCRUM o product owner é um importante membro da equipe e deve participar ativamente da idealização do projeto.
Vale a pena comentar a diferença entre Processo, Processo de Software e Modelo de Processo. Um processo é uma sequência de passos com um propósito, enquanto que um processo de software são atividades, métodos, tecnologias e práticas utilizadas para o desenvolvimento de um software. Um Modelo de Processo é a abstração de um determinado processo, de forma a descrevê-lo de uma maneira geral.
Um projeto é uma instância de um processo, pois um determinado processo pode ser aplicado para mais de um projeto, enquanto que um mesmo projeto só pode usar um único processo. Aplicando esta comparação para o projeto atual de desenvolver um plug-in para o e-Educar, o processo utilizado seria o SCRUM.
Para desenvolver o projeto será utilizada a linguagem java, por isto, durante uma das aulas foi apresentado sua estrutura principal.
