Time: Lorem Ipsum
Página dedicada ao grupo Lorem Ipsum da disciplina de Fundamentos de Engenharia de Software da Universidade Federal do Rio de Janeiro para o período de 2018.1.
O time utilizará esta seção para publicar os avanços no projeto, bem como os entregáveis de cada etapa.
| Entregável | Papel | Lógica | Java | Mét. Ágeis | Git/Github |
|---|---|---|---|---|---|
| Luis Felipe Costa | Product Owner | - | - | - | - |
| Daniel Lopes | Scrum Master | ⭐ | ✔️ | ⭐ | ✔️ |
| João Felipes | Desenvolvedor | ⭐ | ✔️ | 😐 | ✔️ |
| Hiromi Kame | Desenvolvedor | ⭐ | ✔️ | 😐 | 😐 |
| François Boéchat | Desenvolvedor | ⭐ | ✔️ | 😐 | 😐 |
Legenda:
- 😐 : Iniciante
- ✔️ : Intermediário
- ⭐ : Avançado
Desenvolver um sistema de gerenciamento de merendas para substituir as planilhas utilizadas na Prefeitura de Caxias e, durante o processo, aprender sobre o planejamento e desenvolvimento de software.
| Entregável | Descrição | Data de Entrega |
|---|---|---|
| Reação 1 | Texto de até 250 palavras sobre as aulas com os temas: métodos ágeis e SCRUM | 26/03/2018 |
| Canvas | Project Model Canvas do projeto de componente | 26/03/2018 |
| Reação 2 | Texto de até 250 palavras sobre as aulas com os temas: processos de software e canvas | 02/04/2018 |
| Mapa mental | Mapa mental do projeto para identificar melhor suas componentes | 02/04/2018 |
| Reação 3 | Texto de até 250 palavras sobre as aulas com os temas: Testes de usabilidade e iEducar em Caxias | 09/04/2018 |
| Mockups | Mockups das telas do sistema | - |
| Reação 4 | Texto de até 250 palavras sobre as aulas com os temas: Novo levantamento iEducar e nova proposta de projeto | 16/04/2018 |
| Sail Boat | Sail Boat do time | 23/04/2018 |
| Reação 5 | Texto de até 250 palavras sobre as aulas com os temas: Começo do projeto e primeira Sprint | 23/04/2018 |
| Histórias de usuário | Histórias de usuário do projeto | - |
| Reação 9 | Texto de até 250 palavras sobre as aulas com os temas: Testes de Software | 21/05/2018 |
| Burndown | Gráfico burndown do time | - |
| Tutorial | Tutorial de instalação do banco e da aplicação | - |
| Apresentação Final | Apresentação final do projeto | - |
| Book do Projeto | Documentação do projeto e sistema | - |
- Presença e auxílio do professor
- Conversas no Telegram
- Tutoriais
- Dificuldade para instalar o programa
- Dificuldade na integração com o banco de dados
- Dificuldade na programação
- Falhas no programa
- Integrar o banco de dados
- Entregar um software eficiente que receba informações do banco de dados e os organize nos relatórios correspondentes
- O usuário pode se logar e, dependendo do seu nível de permissão, modificar informações.
| Histórias |
|---|
| Como diretor da escola quero cadastrar a quantidade de alunos matriculados em cada modalidade. |
| Como diretor da escola quero cadastrar a quantidade de alunos que consumiram alguma refeição. |
| Como diretor da escola quero cadastrar o total de refeições servidas. |
| Como diretor quero cadastrar as informações sobre o cardápio especificando cada refeição. |
| Como secretário quero cadastrar os usuários do sistema, determinando o nível de permissão de cada um. |
| Como secretário quero cadastrar as informações sobre cada escola. |
| Como secretário quero cadastrar o estoque de alimentos. |
| Como secretário quero gerar um relatório com todos os alimentos cadastrados. |
| Como secretário quero quando necessário realizar o remanejamento dos alimentos, cadastrando informações sobre os alimentos, o mês, o motivo, a escola de origem e a escola de destino. |
| Como secretário quero gerar um relatório para cada mês contendo todas as informações sobre os alimentos, cardápio, estoque e remanejamento. |
| Como secretário, diretor ou funcionário quero visualizar as informações sobre os alimentos. |
| Como secretário, diretor ou funcionário quero visualizar as informações sobre cardápio. |
| Como secretário, diretor ou funcionário quero visualizar as informações sobre estoque e remanejamento. |
Inicialmente precisamos fazer o download dos seguintes programas:
Xampp (versão 5.6.8): Windows, Linux
MySQL Workbench 6.3: Windows, Linux
Para instalar o xampp e o MySQL Workbench é só ir avançando mesmo, não tem segredo.
Ao iniciar o Xampp é só clicar em start ao lado de MySQL, se der certo embaixo vai aparecer escrito:
03:08:29 [mysql] Attempting to start MySQL app...
03:08:29 [mysql] Status change detected: running
Se você estiver com o SQL Server instalado, ou com algum programa que usa a porta 3306 provavelmente vai dar erro, para resolver isso basta desinstalar o SQL Server. Se mesmo assim não der certo dá para mudar a porta, aí é só seguir esse vídeo.
Agora abra o MySQL Workbench, na tela principal está escrito MySQL Connections clique no botão que tem o sinal de mais, coloca qualquer nome lá em Connection Name e dá OK.
Vai abrir uma Query, aí é só copiar o script do merenda.sql e colar e em seguida clica no primeiro botão que tem um sinal de raio. Do lado esquerdo, lá embaixo vai tá escrito SCHEMAS e do lado tem um sinal de atualização, clica nesse sinal e se tudo der certo vai aparecer escrito o nome do banco (mydb) nesse lugar.
Vamos precisar fazer o download do executável do projeto ou do projeto em si no repositório no Github gerando o executável com o Netbeans.
Caso baixe diretamente o executável, é só extrair o arquivo e executar o arquivo Merenda_escolar.jar, para obter sucesso na execução é necessário ter o JRE instalado em seu computador.
Ao executar é exibido a tela de login, se tudo estiver correto no canto inferior esquerdo aparecerá escrito em verde a mensagem: “Conectado” e em seguida usamos o usuário admin e a senha admin para logar no sistema. Caso apareça escrito “Não Conectado” em vermelho quer dizer que não está conectado ao banco, para resolver isso desinstalamos todos os programas e instalamos novamente repetindo todos os passos aqui descritos.
Apresentação final do projeto do time Lorem Ipsum.
Book do projeto final do time Lorem Ipsum.
Os métodos ágeis surgiram como alternativa aos antes utilizados modelos de desenvolvimento em cascata ou iterativo. Esses últimos eram muito focados na documentação do software e na sua regulamentação, este devendo ter uma série de documentos e diagramas muito bem feitos e analisados antes que o desenvolvimento em si pudesse começar. Isso tornava o processo lento e, com a chegada de novas tecnologias e aumento de demanda de software, esses modelos não mais satisfaziam a demanda do mercado.
Assim, os métodos ágeis possuem diversas características importantes. Algumas delas são: entregas rápidas durante o desenvolvimento; mudanças no escopo do projeto, em qualquer etapa do desenvolvimento, são muito mais fáceis de fazer; a simplicidade é essencial; o cliente possui uma visão muito melhor do produto, visto que são feitas, na maioria dos modelos, pequenas entregas funcionais durante o curso do projeto; e, a mais importante, o levantamento de requisitos se torna parte essencial e fundamental de um projeto que utiliza métodos ágeis.
Como não existe grande documentação em cima do projeto, o escopo dele é muito definido nos requisitos do sistema. Para que o projeto ocorra da melhor maneira, é preciso levantar os requisitos corretamente. Requisitos levantados erroneamente, geram funcionalidades que não resolvem os problemas dos clientes e, portanto, precisam ser refeitas. Num modelo em que a rapidez é essencial, isso é muito ruim.
A principal metodologia ágil usada hoje é o SCRUM, que basicamente consiste em fazer Sprints de desenvolvimento, no fim das quais alguma funcionalidade será entregue ao cliente e este dará o feedback para a equipe, representada por um Scrum Master (gerente de projeto) e pelo Product Owner (quem tem contato direto com o cliente).
O Project Model Canvas é uma ferramenta robusta que consiste numa versão mais simples e direta do plano de projeto. Ele é formado por blocos que respondem seis perguntas essenciais em relação ao projeto: por quê? o quê? quem? como? quando? e quanto?
O objetivo desse modelo é facilitar o planejamento de novos projetos, possibilitando que eles possam ser pensados e executados em tempo menor do que o que seria necessário para desenvolver um plano de projeto e executar o seu desenvolvimento.
A ideia importante e inovadora por trás do PM Canvas é a de que “é mais fácil pensar e planejar visualmente”. Assim, quando a “alma” do projeto (canvas) é impressa e colocada em papel (ou em ferramentas online) e a equipe estará constantemente olhando e alterando o que for necessário, absorvendo melhor todo o escopo, motivações e impactos do projeto.
Já os processos de software são as ferramentas, atividades e metodologias utilizadas no desenvolvimento de software. Alguns exemplos desses processos são: SCRUM, XP e Modelo em Cascata.
Os processos de software podem ser utilizados em muitos projetos, mas cada projeto, idealmente, utiliza somente um processo de software. Mudanças entre processos de software durante o desenvolvimento de um projeto não são recomendadas.
Nas aulas foi apresentado o conceito de testes de usabilidade e sua importância para a melhor visualização e entendimento do projeto. Com a prototipagem em papel tem-se uma poderosa ferramenta para testes com o usuário final de um produto. Com protótipos de telas do sistema em papel, o usuário tem a chance de interagir diretamente com o sistema, entendendo seu funcionamento e repassando o feedback diretamente para a equipe de desenvolvimento. Assim, alterações podem ser feitas rapidamente e sem custo, diferente do que aconteceria caso esses testes fossem realizados após o começo do desenvolvimento.
Tivemos também uma curta entrevista com uma representante da prefeitura de Caxias que nos explicou um pouco melhor sobre como o iEducar funciona hoje e quais são seus principais problemas. Dentre os principais problemas, temos o fato de que muitas das escolas usuárias se situam em áreas de risco e por isso o acesso à internet é dificultado. Além disso, muitas customizações oferecidas pelo iReport para o iEducar não são satisfatórias, com título e header aparecendo em todas as páginas de um relatório e as assinaturas no rodapé não aparecem na última página.
Na última aula, foi falado sobre a Sprint #0 e como ela funciona e durante a aula pudemos começar a preparação dessa sprint para o projeto do nosso sistema.
Foi feita uma nova entrevista para melhor levantamento de requisitos do projeto da componente para o sistema iEducar, com duas representantes da prefeitura de Caxias, Sandra e Poliana. Mais alguns problemas em relação ao iEducar foram apresentados. Entre eles, a falta de uma visualização dos dados dos relatórios em gráficos. Além disso, foram reiterados os problemas com titulos, header e footer que aparecem em mais páginas do que deveriam ou não aparecem onde deveriam (no caso do footer). Foi também discutido o problema com o banco de dados do sistema, que consiste de um total de 178 tabelas, tornando o trabalho de manipulação desses dados muito extenso e cansativo.
Mais tarde, devido a todos os problemas apresentados na entrevista citada, somados a realização de que o projeto que a Prefeitura de Caxias esperava de nós era na verdade diferente da proposta que nos foi passada, o professor propôs um novo projeto. Esse projeto seria um sistema de gerenciamento das merendas para a Prefeitura de Caxias, com o objetivo de substituir o trabalho manual que é realizado atualmente com planilhas. Com um projeto bem mais definido e uma ideia mais clara do que precisa ser feito e de como fazê-lo, nosso grupo decidiu seguir nessa direção. Assim, esperamos ter os entregáveis anteriores (como plano de projeto e mapa mental) alterados para satisfazer essa mudança de direção para o projeto.
A semana se iniciou com a Sprint #0 e refatoramento do backlog para atender à mudança no rumo do projeto (de relatórios customizados para o projeto de merenda escolar) e, logo após, deu-se início a primeira sprint. Durante esse tempo também foram apresentadas ferramentas de confecção do backlog do produto e de acompanhamento das sprints quando elas começassem, tais como o gráfico de Sprint Burndown.
Outro ponto importante que foi passado durante esse período foram as instruções de criação do Sail Boat do time, especificando melhor os objetivos do projeto, os riscos envolvidos no desenvolvimento, as dificuldades e atrasos que podem aparecer para os membros durante o desenvolvimento e as forças e motivações que o grupo possui para mover o projeto adiante.
Com o início da Sprint o grupo encontrou dificuldades em achar seu ritmo e dedicar o tempo necessário à realização das tarefas iniciais. Parte disso ocorreu por causa de tentativas mal sucedidas de instalação e configuração do ambiente de desenvolvimento. Isso também ocorreu por conta da má distribuição de tarefas. No começo da sprint não foram definidas quais tarefas seriam realizadas por quais membros e isso prejudicou a produtividade da equipe. Assim, as tarefas não foram executadas até o momento e não há mais o tempo necessário para a realização de todas elas.
Testes constituem uma parte essencial do desenvolvimento de software e tem como objetivo revelar falhas no projeto para que estas sejam corrigidas de modo que o produto final atinja a qualidade desejada. Os testes constituem aproximadamente 50% de todo o esforço e tempo de trabalho durante o desenvolvimento de um projeto.
Existem diferentes abordagens para se atacar o problema do teste de software. Entre as principais estão: testes de unidade, integração, validação e sistema. Nos testes de unidade o foco se encontra nos componentes individuais do sistema. Nos testes de integração, o foco está na correção da integração dos componentes. Já nos testes de validação, o foco reside na verificação do atendimento dos requisitos. Finalmente, nos testes de sistema o foco está no funcionamento correto da combinação do software com os outros elementos do sistema, tais como hardware, pessoas e dados.
Como as possibilidades de entrada de testes crescem exponencialmente, é importante saber até quando aplicar testes ao sistema. Existem basicamente duas possibilidades ou critérios de finalização de testes: os testes param (nesse caso, é preciso determinar quando eles param); os testes não param (nesse caso, é preciso determinar transferência da incubência de testes). Se os testes param em algum momento, podem ser usados modelos matemáticos para determinar o momento de parada (modelar falhas como função do tempo de execução). Se os testes não param, apenas ocorrem transferências da responsabilidade de testar, do desenvolvedor para o usuário, por exemplo.