Time: GaaraVsRockLee.wmv
Essa sessão é reservada para o grupo GaaraVSRockLee.wmv, da disciplina Fundamentos de Engenharia de Software ministrada em 2018.1 da Universidade Federal do Rio de Janeiro.
Aqui relataremos os conhecimentos obtidos durante as principais etapas do processo de desenvolvimento de software visto ao longo do curso, além das aulas lecionadas pelos professores Eber Assis Schmidt e Luis Felipe Coimbra Costra.
- Gabriel Aureo de Oliveira Campos - Desenvolvimento, pesquisa
- Henrique Vermelho de Toledo - Scrum Master, design, e desenvolvimento
- Matheus Vinicius da Silva de Figueiredo - Desenvolvimento, pesquisa
- Pedro Vítor Marques Nascimento - Design, arte, desenvolvimento, gestão
- Desenvolver um gerador modular de relatórios escolares a partir de templates criados pelo usuário, com uma estrutura de banco de dados que permita alcançar os dados necessários para documentos típicos como planilhas de notas, histórico escolar, etc. Código aberto.
| Atividade | Descrição |
|---|---|
| Mapa Mental | Esquema confeccionado para auxiliar e guiar nossos objetivos iniciais e fases de planejamento do projeto |
| Canvas | Project Model Canvas criado nas primeiras aulas para auxílio à equipe. |
| Mockups | Lista com mockups criados para o projeto até o presente momento |
| Comic de desenvolvimento | Tirinha elaborada conforme conselhos vistos em aula para melhor visualizar problematizações apresentáveis e tangíveis ao cliente final. (product owner). |
| Documento de Requisitos | Documento com uma gama de informações definitivas sobre o projeto criado ao final da Sprint 0. |
| Sail Boat do time | Ilustração, também guiada pelas aulas, para buscar representar e sumarizar as possíveis dificuldades, facilidades e direção geral do projeto, através de uma simples analogia náutica. |
| Backlog | Lista elaborada de todas as tarefas a serem cumpridas até o fim das sprints. Uma versão idêntica mas separada em front end e back end para uso prático do grupo se encontra no Trello Principal. |
| Iterações do Produto Final | São listadas aqui as iterações do projeto por data, com funcionalidades esperadas até aquele momento |
| Definição de Conclusão | Um breve adendo sobre os critérios de conclusão do projeto. |
| Relatórios produzidos | Entregas de impressões, reações e resumos dos conteúdos dados em aula em forma de relatório, em ordem de entrega. |
Por motivos de agilização de workflow, este trello contém materiais disponíveis aqui como mockups, canvas, tirinhas, assim como ferramentas e links úteis convenientemente organizados na primeira coluna.
Álbum completo com os primeiros mockups, prévia disponível abaixo:
Baseado nas primeiras impressões e expectativas do projeto, foi proposta um programa mais voltado para a customização não só de conteúdos como está previsto para o projeto real, mas também de layout e design de documentos oriundos do planejado plug-in de customização. Acredita-se que não representa o entregável final por esses motivos, mas por motivos de documentação preferiu-se deixar disponível essa trajetória do desenvolvimento.
Essa versão contemplaria um viés modularizado para a elaboração dos documentos escolares - a partir de abas, como no Chrome, seriam extensíveis campos a escolha do usuário. Templates prontos seriam ofertados e haveria a opção de criar novos templates.
Álbum com uma tela de tooltip do Mockup 0, prévia disponível abaixo
Este é o documento principal do projeto, nomeado openReport, que descreve seus requisitos e suas funcionalidades previstas à altura da Sprint #0 do desenvolvimento.
- Não balancear bem tempo de estudo com projeto (por conta de provas)
- Integrar mySQL com Java
- Escopo ser grande
- Equipe com horários muito diferentes que dificultam reuniões
- Desconhecimento de bibliotecas Java - ou mesmo as particularidades da própria linguagem.
- Equipe já teve experiência com projetos de escopo médio.
- Equipe se conhece e se dá bem.
- Cada um tem uma especialização diferente, torna fácil separar tarefas.
- Auxílio do professor em casos de dificuldade.
- Finalizar o projeto de maneira satisfatória.
- Criar uma documentação clara que possibilite outras pessoas contribuir posteriormente.
- Organizar tudo na Wiki do projeto.
| Nome | Tipo | Horas | Concluído |
|---|---|---|---|
| Telas isoladas ocas | Interface | 2h | X |
| Adição de Dados em cada Campo | Interface BD | 3h | |
| Edição de Dados em cada Campo | Interface BD | 2h | |
| Remoção de Dados em cada Campo | Interface BD | 1h | |
| Conexão Direta com BD para acesso e edição | Interface BD | 4h | |
| Interface dos componentes isoladamente | Interface Componentes | 1h | X |
| Adição de Componentes | Interface Componentes | 3h | O |
| Remoção de Componentes | Interface Componentes | 1h | O |
| Edição de Componentes | Interface Componentes | 3h | |
| Salvar Modificações em Classe Template | Interface Componentes | 2h | |
| Chamada de Exportar PDF a partir de Classe | Interface Componentes | 2h | |
| Serialização e Deserialização de Classe Template em XML | Exportar PDF | 2h | X |
| Salvar XML em arquivo | Exportar PDF | 1h | |
| Imprimir Cabeçalho | Exportar PDF | 3h | O |
| Imprimir Texto | Exportar PDF | 1h | O |
| Imprimir Título | Exportar PDF | 1h | O |
| Imprimir Assinatura | Exportar PDF | 2h | |
| Imprimir Tabela Simples | Exportar PDF | 4h | |
| Tabela: Pegar dados do BD | Exportar PDF | 3h | |
| Imprimir componentes de acordo com Layout | Exportar PDF | 5h | |
| Finalização Diagrama ER | Banco de Dados | 1h | X |
| Implementação do Diagrama e das tabelas em mySQL | Banco de Dados | 2h | O |
| Popular Banco de Dados | Banco de Dados | 1h | O |
| Enumeração dos Queries de acordo com o componente Tabela Simples | Banco de Dados | 2h | |
| Implementação dos Queries enumerados | Banco de Dados | 6h | |
| Integração com Java | Banco de Dados | 5h |
| Bônus | Tipo | Horas |
|---|---|---|
| Escolher entre pagina vertical e horizontal | Exportar PDF | 3h |
| Visual do Componente Tabela para histórico Escolar | Interface Componentes | 1h |
| Visual do Componente Imagem | Interface Componentes | 1h |
| Componente Tabela para histórico Escolar | Exportar PDF | 4h |
| Componente Imagem | Exportar PDF | 1h |
| Número | Data | Funcionalidades |
|---|---|---|
| 1 | 18/05 | Adicionar e remover Componentes, Acessar banco de dados |
| 2 | ? | Edição de componentes, salvar como template XML, Edição do banco de dados através do programa e anteriores. |
| 3 | ? | Exportar para PDF, abrir template e anteriores. |
| Final | ? | Finalização - polimento - e correção de bugs. |
O time considera pronto um software que possibilite ao usuário adicionar, editar e remover dados do banco de dados da escola. Além disso a possibilidade de, em cima deles, emitir relatórios com estrutura dividida em Title, Page Header, Body, Page Footer e Footer. Estes relatórios podem acessar os dados do banco de dados de maneira que seja possível listar alunos em uma turma específica e coisas do gênero. Outra funcionalidade é a possibilidade de salvar o template do relatório em um arquivo XML que pode ser lido posteriormente pelo sistema.
- Backlog iniciado - Trello
- Reunião decisiva da equipe para planejamento do backlog, objetivo e funções de cada membro da equipe.
- Rumo de projeto decidido, objetivo na Wiki atualizado
- Primeiros planejamentos de back-end, interface (mockups)
Esta sprint serviu como um preparo geral para o trabalho principal que o grupo terá de codificação das ideias discutidas, nas quais as ferramentas preparadas até agora - o PM-Canvas, Trello, Mapa Mental dentre outros servirão de apoio para um projeto flexível-iterativo, organizado e agilmente desenvolvido.
Os links (nos títulos) concedem permissão para comentários, agradecemos quaisquer observações que possam ser feitas para melhorar a qualidade de nossos relatórios!
Um dos conceitos fundamentais da Engenharia de Software é o planejamento; um projeto feito sem organização ou estratégia pode virar facilmente um desastre e frustrar tanto o cliente quanto os próprios desenvolvedores. Nesse contexto, dentre as diversas maneiras de se lidar com este problema, destaca-se o uso de Métodos Ágeis, que consistem em técnicas e metodologias para potencializar o ritmo de desenvolvimento de um projeto.
Existem diversos Métodos Ágeis: Kanban, DSDM, entre outros, cada um com suas características e tipos recomendados de projeto. O Scrum, um dos mais famosos, é conhecido pela divisão do projeto em ciclos mensais (ou até semanais) chamados de Sprints. Este conceito significa simplesmente uma coleção de tarefas para serem feitas até o término de tal ciclo. Além disso, é designado à equipe um Scrum Master, indivíduo responsável pelo contato com clientes finais/donos de produto e pela designação das tarefas de cada sprint.
Para um Método Ágil funcionar, em especial o Scrum, é preciso uma lista de funcionalidades para que o software seja concluído. Em especial, é necessário acima de tudo entender qual o problema que a solução virtual visa resolver na elaboração desta lista. É preciso ter certeza que o produto final irá realmente beneficiar o cliente.
A elaboração da lista completa de funcionalidades só é possível a partir da Análise de Requerimento de Software, pois é nela que os profissionais competentes irão moldar o produto, entender sua proposta e, claro, suas funcionalidades chave para então encaminhá-las aos desenvolvedores.
Fundamentalmente, Processo de Software representa um amontoado de técnicas, modelos, e ações direcionadas para o desenvolvimento e manutenção de software e afins. Nesse contexto, equipes responsáveis pela produção se organizam em torno de diversos modelos em existência na indústria com o fim de gerir e dar sequência ao produto final que é o software funcional e em concordância com o que foi proposto para o mesmo.
Um exemplo interessante disso em ação é a criação deste próprio relatório, que não deixa de ser uma parte instrumental do projeto final da disciplina FES-2018, sendo realizado semanalmente para que no final, exista uma documentação do projeto e dos ensinamentos repassados aos alunos.
Dentre os modelos, destaca-se o modelo em cascata (Waterfall Model), variações do mesmo, e modelos ágeis que surgiram em resposta aos mesmos. Para o primeiro, tipicamente é dedicado para cada etapa do processo um tempo extenso - requisitos, design, codificação, testes e manutenção. Esse método é originado das engenharias, sendo quase uma equivalência aproximada para fins de desenvolvimento de software.
Entretanto, é amplamente criticado na indústria por suas características que não se traduzem bem para o viés digital - é dotado de inflexibilidade, exigindo relatórios extensos e numerosos, baixíssima capacidade de mudança durante desenvolvimento, com permissões e burocracias gerenciais obrigatórias. Para hoje sabe-se que a agilidade e flexibilidade são intrínsecas ao bom desenvolvimento. O Scrum, discutido anteriormente e as subsequentes variações do Waterfall Model se unem nessa direção.
Como parte do Processo de Software, uma ferramenta que entrará como parte do projeto é o Project Model Canvas, que se dá por um quadro, impresso ou digital, aonde há regiões separadas (da esquerda para a direita numa progressão linear) para um amontoado considerável de necessidades e características que um processo desse tipo abrange. É de considerável ajuda às equipes, organizando desde de stakeholders, equipes, custos até restrições que inicialmente podem passar despercebidos.
O conceito de Testes de Usabilidade foi apresentado como uma proposta interessante na parte de interação com o cliente - através de protótipos produzidos no papel, é possível dar ao cliente uma ideia do que se pode desenvolver e como ele irá interagir com o produto final.
Acredita-se que estes testes de funcionalidade, juntamente com as tirinhas de desenvolvimento citadas anteriormente sejam de firme ajuda nos meados da Sprint #0 (também apresentada em aula) - que é a etapa do desenvolvimento ágil iterativo responsável por colocar nos eixos iniciais as fases de codificação do software. É fundamental verificar na entrega da Sprint #0 que a equipe esteja reunida, que os requisitos tenham sido levantados e o backlog inicial de entregas erguido considerando o mesmo.
A equipe GaaraVSRocklee.wmv espera entregar a Sprint #0 na forma do Trello, plataforma aonde serão organizadas as entregas/backlog do Scrum e cada sprint será formalizada dentro do Trello do grupo. Além disso, uma visita rápida de uma responsável da Prefeitura de Caxias, Sandra, foi realizada para dar um pouco de luz ao projeto.
Foi realizada outra visita da equipe da prefeitura da Caxias, com duas responsáveis pela gestão do Sistema i-Educar, Sandra e Poliana. Houve um sentimento de definição maior do projeto em questão, posto que a turma foi apresentada o sistema i-Educar em funcionamento e problemas existentes da plataforma. Ficou claro também ao grupo que o software desejado pela prefeitura era uma distinta da inicialmente proposta de customização estética de relatórios - atualmente procura-se mais a resolução erros específicos da plataforma i-Educar com o sistema i-Report.
Somado a isso, houve uma reunião geral da turma com a equipe em outra aula instrumental na decisão dos rumos do projeto final. Cada grupo apresentando suas impressões dos estudos até então contribuiu para a instauração de uma nova opção de projeto - um sistema para gerenciar merendas para substituir as planilhas em Excel usados em escolas em Caxias.
Por motivos de alteração da estrutura existente e requisitos originais do projeto, o grupo GaaraVsRockLee.wmv decidiu em uma reunião no domingo, dia 15/04 que optaria pela rota dos relatórios.
Nessas aulas foram planejados e entregues nos dias subsequentes o backlog final do produto (instrumental no funcionamento do Scrum para popular as sprints), o Sail Boat para auxiliar nos rumos do projeto e serviram de grande auxílio para desencadear o desenvolvimento e estimar com mais corretude o tempo necessário para as etapas do projeto.
Com o auxílio do professor Luis e da Poliana da equipe de Caxias, foi possível dar início ao desenvolvimento do projeto, tendo em vista o dimensionamento das tarefas e reflexões tidas a respeito do projeto. Também foi lecionado ao grupo diretivos para confecção do Burn Down Chart, gráfico responsável pela medição das tarefas cumpridas em relação ao tempo.
O grupo espera que essas ferramentas possam ser de ajuda constante, isto é, que estejam no auxílio e em uso (principalmente o backlog) até o final do projeto.