COLLABORA – ANÁLISE DE MENSAGENS
LISTA DE ILUSTRAÇÕES
Figura 1 - Quadro exemplo Kanban preenchido. 7
Figura 2 - Quadro de Kanban Collabora. 11
Figura 3 - Diagrama BPMN para login no sistema. 13
Figura 4 - Diagrama BPMN iniciar atividade para aluno. 13
Figura 5 - Diagrama BPMN aluno respondendo atividade. 14
Figura 6 - BPMN Login professor 14
Figura 7 - BPMN verificar inatividade sistema. 15
Figura 8 - Diagrama de Caso de Uso Aluno. 16
Figura 9 - Diagrama de caso de uso Gerente. 17
Figura 10 - Diagrama de Caso de Uso Usuário fazendo Login.. 18
Figura 11 - Diagrama de caso de uso para Professor 19
Figura 12 - Diagrama de classe relação entre usuário e acesso. 20
Figura 13 - Diagrama de classe Questão e seus vínculos diretos. 21
Figura 14 - Diagrama de classe turma e seus relacionamentos. 22
Figura 15 - Diagrama de classe dica x conteúdo. 23
Figura 16 - Diagrama de classe Conteúdo Site. 23
Figura 17 - Diagrama de classe configurações gerais. 24
Figura 18 - Diagrama de classe Atividade X Questão. 25
Figura 19 - Diagrama de classe Mensagem X Aluno. 26
Figura 20 - Validação required input html5. 29
Figura 21 - Validação input file accept 30
Figura 22 - Validação jQuery min e máx input number 30
Figura 23 - Botões de relatório com ícones. 31
Figura 24 - Combo com seleção múltipla. 31
Figura 25 - Usando Sweet Alert mensagem sistema. 32
sumário
1 DESCRIÇÃO.. 4
2 MODELO DE DESENVOLVIMENTO DO SISTEMA ADOTADO.. 4
2.1 JUSTIFICATIVA.. 4
2.2 Scrum.. 5
2.2.1 Etapas do SCRUM utilizadas no estudo de caso. 6
2.3 KANBAN.. 6
2.3.1 Etapas do Kanban na literatura. 6
2.3.2 Etapas do Kanban utilizadas no estudo de caso. 7
2.4 Diagramas UML. 7
3 Aplicação do modelo adotado. 8
3.1 Planilha de solicitação de mudanças. 8
3.2 Diagramas adotados. 10
3.2.1 Diagrama BPMN.. 10
3.2.2 Diagrama de caso de uso. 13
3.2.3 Diagrama de classe. 17
3.3 Metodologia de desenvolvimento. 24
3.4 Implementações feitas. 25
4 Análise crítica do uso do modelo adotado. 28
4.1 Identificação dos pontos fortes. 28
4.2 Identificação dos pontos fracos. 29
O projeto que será usado como fonte de pesquisa para a disciplina de Engenharia de Software é o Collabora, um sistema de chat colaborativo destinado a verificar se aluno participa ou não das atividades colaborativas propostas. Fornece também a possibilidade do professor cadastrar e oferecer questionários aos alunos. As questões quando cadastradas ficam disponíveis para os grupos de alunos vinculados aquela atividade onde vai ser gravado as mensagens e verificado a colaboração posteriormente. O trabalho vai descrever correções e integrações de novas funcionalidades que houveram durante o desenvolvimento do sistema, a metodologia que foi empregada para separar o trabalho, além das ferramentas usadas e seus produtos gerados.
Optou-se pelo SCRUM como sendo uma metodologia de desenvolvimento pois dei acordo com BISSI (2007, p.1) ele é “extremamente ágil e flexível”. Na parte da programação foi escolhido a linguagem de programação Java usando o framework Struts2. Para banco de dados foi escolhido o PostgreSQL pois de acordo com PALHARINI (2016) ele é melhor que o MySQL “pela constante atualização da plataforma e consequentemente implementação acelerada de novas funcionalidades”.
O modelo foi escolhido por que dá a nós uma forma de somente uma pessoa programar, e ter a pessoa separada que avalia e valida as entregas. A linguagem de programação em Java e o uso do framework Struts2 foi algo que já veio com o projeto por isso acabou-se por continuar com ela e também por que seria inviável refazer tudo do zero em outra linguagem ou framework.
Na questão de planejamento foi escolhido o SCRUM ele é a metodologia com menos entregas possíveis. De acordo com BISSI (2007, p.1) ele “pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa, proporcionando um excelente entrosamento entre as equipes de desenvolvimento“. A aplicação dele ainda teve quer ser um pouco modificada para ser adaptada a realidade do projeto, porém é o ideal de acordo com BARROS (2009, p. 1) “se adéqua a equipes pequenas e projetos altamente dinâmicos e mutáveis, como a WEB”.
De acordo com Schwaber (2013, p.3) o SCRUM é um framework usado para manter produtos complexos e adaptativos. Dividido em quatro eventos importantes descritos em sequência:
No geral ainda temos a separação de quem compõe uma equipe de SCRUM que de acordo com NETO (2012) é composto de três papéis:
Das etapas do SCRUM foi dispensado as reuniões diárias, pois ficaria inviável a reunião diária para a equipe tanto devido a distância pelo trabalho estar sendo realizado em diferentes locais. Normalmente Sprints são definidos por períodos de um mês ou menos baseado em Schwaber (2013, p.8) porém como não conseguiu manter a reunião diária manteve-se o Sprint onde ele ficou agendado para reuniões semanais de revisão e verificação de funcionalidades estavam de acordo com o pedido.
Na separação de papéis as funções de Scrum Master e Product Owner foi englobada em somente uma, pois nesse caso o cliente tinha conhecimento técnico suficiente para retirar as dúvidas.
Para gerenciar o andamento do projeto será usado o Kanban que de acordo com MARTINS (2014) é um sistema para gerenciar o fluxo de trabalho com cartões onde na medida que o trabalho vai evoluindo ele é mudado de estágio. De acordo com AGUIAR (2007, p.176) as vantagens em utilizar são:
Para CRISP (2017) coloca benefícios mais envolvidos a área de desenvolvimento de software que podem ser vistos a seguir:
De acordo com MARIOTTI (2012, p. 7) as etapas do Kanban se resume a três:
Um quadro exemplo de como é o Kanban pode ser vista na figura seguinte:
Figura 1 - Quadro exemplo Kanban preenchido
Fonte: KNIBERG (2009, p.1)
Para utilização no processo, houve muitas reuniões mediante as quais pode-se retirar a visualização dos processos via descrição de cada tela e suas funcionalidades. A limitação do trabalho em geral foi feita pela professora Ishikawa, porém como eram várias alterações verificou-se a necessidade de fazer reuniões e adotar novos prazos para entrega.
A cada reunião realizada foi ponderado o que se realizou e o que ainda ficou a ser feito, dando assim possibilidade de arrumar o cronograma de entregas e visualizar as possíveis datas de entrega reais para cada funcionalidade que estivesse atrelada as tarefas agregadas ao projeto.
De acordo com SILVA (2001, p.10), eles “são a representação gráfica de um conjunto de elementos do sistema”. Ainda de acordo com SILVA (2010, p.10) ele permite representar as diferentes partes do sistema através de um modelo. Usar diagramas ajudam para não ter que analisar o código fonte cada vez que um novo integrante é inserido na equipe, assim ele pode analisar todas as regras sem ter que abrir o código fonte e ter certeza de qualquer alteração que irá fazer.
Será usado o framework Struts2 para desenvolvimento que segundo APACHE (2017) ele serve para criar aplicações MVC com Java, favorecendo a configuração e sendo extensível a uma arquitetura de plug-in e tem suporte para REST, AJAX e JSON. Um segundo conceito de acordo com PRADO (2007) é que ele é um framework open-source com base no projeto Jakarta aonde o mesmo usa Servlets, JavaBeans, XML e seu uso é voltado ao modelo MVC (Modelo / Visão / Controle).
A planilha em sequência mostrara as alterações pedidas de maneira geral separando pelo que foi feito naquele contexto, porém mudanças tais como alteração do padrão de PDF foi feito em vários lugares.
Tabela 1 - Planilhe de Controle de Mudanças
Fonte: Autoria própria
Para montagem da separação de tarefas, foi usado o sistema online chamado Trello, cujo mesmo é gratuito e permite a criação do quadro e acompanhamento por quem tu quiser convidar podendo definir permissões de visibilidade e também modificação. A seguir pode ser verificado como ficou as tarefas quase ao final da entrega desse projeto, nele pode-se ver a separação ideal entre quadros. Tem algumas referências que ainda colocam o uso de mais um quadro que seria para produção, porém a montagem dos quadros é opcional e adaptável ao seu ambiente de trabalho.
Figura 2 - Quadro de Kanban Collabora
Fonte: Autoria própria
Claro que no Kanban temos a movimentação dos quadros então periodicamente eles mudam de lugar de acordo com o que for terminando uma tarefa ela é mudada de quadro, porém a figura anterior pode demonstrar de maneira geral como ficou a estruturação de tarefas. Devido a ser usado o sistema online evitou-se a possibilidade de ficar perdido com o que foi feito e assim ter uma real noção do andamento do projeto alocada em um lugar só para todo mundo que tivesse permissão visualizar.
Ainda na ferramenta Trello percebe-se que é possível uma separação por cor o que seria muito bom para um acumulo de cartões em maior quantidade.
Diagramas que serão usados no projeto serão BPMN, casos de uso e de classes. Mediante os diagramas de caso de uso vai ser demonstrado o que foi feito e o que foi corrigido perante o sistema. Já no diagrama de classes será demonstrado por funcionalidades descrevendo o objeto e também os métodos que o utilizam para determinar seu escopo. E nos diagramas de BPMN foi decidido usar para ter uma visão geral de ações que levavam condicionais em considerações para executar uma tarefa A caso a ação condição fosse verdade ou B caso fosse falsa.
Optou-se por somente esses tipos, por que a produção inicial dos diagramas já havia sido feita. Então de maneira geral só quisemos demonstrar o que foi alterado mediante o sistema o que faz esses tipos de diagramas darem uma boa visão geral do sistema e de forma rápida.
Para demonstração do ato de entrar no sistema optou-se por usar o diagrama de BPMN cujo demonstra o passo a passo e as decisões envolvidas nele. No diagrama a seguir demonstrasse que para entrar no sistema ele usa como base o de Usuário onde nele se questiona primeiramente se aquele registro e senha é do tipo gerente, depois do tipo aluno e por final do tipo professor caso sucesso em algum desses caminhos ele direciona para seu respectivo painel, caso não ao final de tudo ele direciona para mensagem de erro e finaliza a ação.
Figura 3 - Diagrama BPMN para login no sistema
Fonte: Autoria própria
Quando quem estiver entrando for um aluno o sistema deve conferir se tem atividade disponível e tem número mínimo de pessoas ativas no grupo é o diagrama que vem em sequência. Nele pode se verificar o passo a passo que é feito pelo script, temos uma verificação se existe atividade, e posteriormente a verificação se o aluno tem mais alguém do seu grupo conectado para iniciar a atividade só então se tudo for positivo então poderá começar a atividade.
Figura 4 - Diagrama BPMN iniciar atividade para aluno
Fonte: Autoria própria
Para resposta da atividade os alunos devem começar a discutir no chat suas ponderações e em sequência será perguntado qual a alternativa e se todos responderem a mesma será mostrado se acertou ou não até a última questão. Na sequência então mostra-se o diagrama BPMN para mostrar como o sistema age para quando o aluno está ativo e com grupo mínimo de duas pessoas para iniciar suas atividades. Nele pode-se verificar etapas onde se pede consenso na resposta dada pelo grupo, e também é possível ver o ciclo de tarefas do script repete até não haver mais exercícios.
Figura 5 - Diagrama BPMN aluno respondendo atividade
Fonte: Autoria própria
Quando quem estiver entrando é um professor tem uma verificação se o mesmo já cadastrou alguma atividade e caso sim mostra dados atualizadas em sua tela inicial, caso não vem o painel, porém com informações vazias para atividade.
Figura 6 - BPMN Login professor
Fonte: Autoria própria
Para o sistema quando o usuário já está ativo foi feito uma verificação de tempo de inatividade, onde o mesmo a partir de 30 minutos após o usuário não fizer nenhuma ação e decidir recarregar a página ou trocar de funcionalidade será direcionado para fora do sistema. Assim com isso evitamos que alguma pessoa mal-intencionada acesse a sessão de outro usuário que por engano acabou deixando ela ativa. Na sequência tem o diagrama BPMN para conferir sessão inativa:
Figura 7 - BPMN verificar inatividade sistema
Fonte: Autoria própria
Para o cálculo de colaboração ele é feito pelo professor onde o mesmo primeiramente escolhe as mensagens a serem selecionadas e depois pode salvar seu resultado para em sequência ser feito o cálculo. No diagrama a seguir pode ser visto como é o caminho até poder calcular a colaboração, onde também é visto a necessidade de ter preenchido as configurações de peso da atividade.
Figura 8 - BPMN professor calculando colaboração
Fonte: Autoria própria
Na definição dos casos de uso dentro do diagrama foi usado o padrão “Manter ...” cujo ele demonstra que é o responsável pelo padrão na funcionalidade de CRUD (Create, Read, Update, Delete), ou seja, ele nos possibilita uma visão direta que a funcionalidade é ali responsável por criar, procurar, atualizar ou excluir uma linha da tabela. Na criação dos diagramas de caso de uso foi separado em quatro agrupamentos principais:
Figura 9 - Diagrama de Caso de Uso Aluno
Fonte: Autoria própria
Figura 10 - Diagrama de caso de uso Gerente
Fonte: Autoria própria
Figura 11 - Diagrama de Caso de Uso Usuário fazendo Login
Fonte: Autoria Própria
Figura 12 - Diagrama de caso de uso para Professor
Fonte: Autoria própria
Após a criação dos diagramas de caso de uso é possível verificar as classes, contudo como esse projeto não foi inicia do zero também se usou como base a separação pelas principais funcionalidades. Na sequência será mostrado o diagrama que mostra o relacionamento entre acesso e usuário onde um usuário poderá ter nenhum ou múltiplos acessos no sistema.
Figura 13 - Diagrama de classe relação entre usuário e acesso
Fonte: Autoria própria
Na construção da questão temos sua relação diretamente com as proposições onde pode haver para uma questão a proporção de uma ou mais proposições. Ainda para questão temos a relação com referência que para cada questão é obrigatório o cadastramento de uma referência e também por último temos o vínculo ao conteúdo da questão sendo que para uma questão pode haver um ou mais conteúdos vinculados. Na sequência colocasse o diagrama dessa relação:
Figura 14 - Diagrama de classe Questão e seus vínculos diretos
Fonte: Autoria própria
Na relação de turma temos a conexão com aluno onde uma turma pode ter um ou muitos alunos. Conectando a turma temos o professor que pode ser responsável por nenhuma ou muitas turmas e também por último a disciplina que uma turma pode ter nenhuma ou muitas.
Figura 15 - Diagrama de classe turma e seus relacionamentos
Fonte: Autoria própria
A relação entre dica e conteúdo é feita na proporção de um conteúdo pode ter nenhuma ou mais dicas cadastradas correlacionadas a ele. Pode-se ver melhor a sua relação no diagrama a seguir:
Figura 16 - Diagrama de classe dica x conteúdo
Fonte: Autoria própria
Para podermos editar conteúdo externo ao sistema de páginas de apresentação tais como equipe e descrição do projeto foi criado a funcionalidade de Conteúdo Site dentro dela é possível alocar conteúdo referente a página e o gerente do sistema poderá editar sem precisar que um programador edite o HTML direto no código fonte da página. Ao desenvolver a classe foi usado atributo para título da página e texto sendo esse gravado quase sem limitação de tamanho. Pode ser visto como ficou o diagrama na sequência:
Figura 17 - Diagrama de classe Conteúdo Site
Fonte: Autoria própria
Para configurações gerais ao sistema, foi criada a classe chamada Geral nela foi colocado atributos para alterar a URL Facebook, Twitter que são as redes sociais que ficam visíveis externamente ao projeto, também para possibilidade de trocar os logos de forma facilitada foi criado os campos para UTFPR, PPGCC, PPGECT, e do sistema que é o Collabora.
Figura 18 - Diagrama de classe configurações gerais
Fonte: Autoria própria
Para realizar o cadastramento de atividade, foi feito o diagrama de classes integrando a classe Atividade que pode ser relacionada a questão na taxa que uma atividade pode ter uma ou mais questões. Para demonstrar ainda a integração inicial de questão a seus outros relacionamentos fizemos a composição na figura seguinte também com as classes de proposição, referência, e conteúdo que se interligam essas a questão.
Figura 19 - Diagrama de classe Atividade X Questão
Fonte: Autoria própria
Para análise de Mensagens foi decidido fazer algo um pouco diferente, já que as mensagens eram estruturadas em três classes ditas Colaboracao, ColaboracaoComAnexo, e ColaboracaoTextual ficaria complicado fazer a busca desses elementos separados então foi feito a classe de Mensagem cujo serve de para agrupar e ajudar a salvar a mensagem em relação se é significativa ou não. O diagrama a seguir irá mostrar a relação entre a classe de Mensagem e a classe de Aluno cujo seria o dono da mensagem enviada.
Figura 20 - Diagrama de classe Mensagem X Aluno
Fonte: Autoria própria
Idealizamos o uso do SCRUM por ter seu foco em desenvolvimento ágil e também por ser o que melhor se adapta a equipe de somente um programador, tendo somente os avaliadores ou professoras no caso para validação do que foi implementado. No geral seu foco de uso teve obrigatoriamente algumas modificações tais como as reuniões diárias foram abolidas, na utilização da separação entre papéis não foram usados os três que são padrão do SCRUM, porém ainda conseguimos separar.
A separação dos papéis ocorreu em Product Owner onde aqui foi mantido pelas professoras responsáveis ao projeto e as funções dos dois outros papéis foram agrupadas sobre minha responsabilidade que seriam de Development Team (Time de Desenvolvimento) e Scrum Master (Líder de equipe). Sabendo-se que a equipe era somente de uma pessoa para esse trabalho fica claro o porquê da separação.
Por ter usado o SCRUM também se criou um cronograma para entrega de atividades utilizado principalmente para mostrar as histórias de caso de. No cronograma iniciou uma primeira versão que foi disponibilizado no Google Drive o qual foi sendo melhorado de acordo com novas histórias. As histórias foram montadas em base de perguntas feitas as professoras em cada.
Para criação das telas, ou seja, na camada de visualização foi utilizado o padrão do projeto que estava com framework Boostrap cujo ele nos fornece suporte a HTML, CSS, e JavaScript em determinadas funcionalidades usando integração para isso com o framework jQuery. O Boostrap foi escolhido pois nos fornece um padrão de desenvolvimento com responsividade, ou seja, ele se auto ajusta as diferentes telas que acessam o sistema desde que seja devidamente bem usado.
Houve-se algumas correções em telas devido ao mal-uso do framework Boostrap onde tivemos que zerar seu CSS ao original pois muitas modificações haviam sido feitas nele, e fomos voltando as alterações aos poucos em arquivo de estilo separado para o que foi modificado assim achando os problemas e restaurando padrões de responsividade quebrados entre outras coisas.
Para a iteração cliente servidor foi usado sempre que possível o padrão de retorno ou envio de dados com AJAX usado com framework jQuery e também integrações ao seu plugin Datatables para construção das tabelas. O uso de AJAX nos é interessante pois deixa a web mais dinâmica, ele é usado com retornos em JSON, ou text que seria para texto puro. Dentro desse componente de tabela ainda conseguimos a responsividade escondendo colunas dinamicamente e colocando no lugar delas um sinal de “+” onde clicando sobre o mesmo abre as colunas que foram escondidas em resoluções menores, já em resoluções maiores ele mostra todas as colunas para as buscas realizadas.
Para as funcionalidades de Manter Aluno e Manter Professor foi criado importações via planilhas CSV que ajuda no dia a dia do uso administrativo do Collabora a realizar o rápido cadastramento de novas turmas e ou professores. Nessas páginas para evitar a submissão integral da mesma usamos o plugin JQuery Form Plugin que envia escondido o arquivo sem submeter a página que evita ter que recarregar a página e retorna somente o necessário que seria uma mensagem em JSON com objeto com situação se foi bem-sucedido ou não o tramite. Nessa importação também inserimos a coluna de e-mail que agora no sistema poderá ser usada para recuperar a senha, caso esteja devidamente preenchido e correlacionado ao seu usuário no banco de dados. Na figura a seguir pode ser visto como ficou o campo de esqueceu senha, estando preenchido o campo usuário com o registro do usuário e sendo ele válido a pessoa poderá clicar sobre o campo esqueceu senha e será enviado um e-mail para o seu cadastro correlacionado.
Figura 21 - Formulário de Login com Esqueceu senha
Fonte 2: Autoria própria
Para as buscas usa o botão extensível do jQuery Datatable denominado de pdfhtml5 que funciona com uma integração a um plugin chamado pdfmake. Neste foram feitas adaptações do cabeçalho e rodapé para mostrar os logos da UTFPR e programas de pós-graduação. Foram adicionados botões de excelHtml5 para exportar ao formato XLSX, csvHtml5 que exporta em CSV.
Para as colunas dentro da tabela foi especializado colunas de imagem para que possam ser baixadas, economizando espaço e melhorando performance ao realizar a busca. Já nos logos se usou o formato data uri, ou seja, converte a coluna respectiva em formato de texto cujo assim salvamos utilizando Local Storage do html5 onde fica gravada no browser de forma escondida para futuras impressões de PDF.
Em um contexto geral foi feito melhorias em questão de performance no projeto priorizando todo o conteúdo de visualização imediata, e deixando o carregamento de JavaScript por último cujo esse traz efeitos, ou funcionalidades que não afetam o visual inicial do sistema. Com o uso dessa técnica deu a sensação de uma melhoria substancial no carregamento das telas, também retiramos todo e qualquer uso de repositório online para todo JavaScript e arquivos CSS serem requisitados diretamente do servidor o que diminui o trafego de banda larga.
Ainda houve uma revisão de todas as funcionalidades empregadas, menos a de chat onde foram corrigidos:
Figura 22 - Validação required input html5
Fonte: Autoria própria
Figura 23 - Validação input file accept
Fonte: Autoria própria
Figura 24 - Validação jQuery min e máx input number
Fonte: Autoria própria
Figura 25 - Botões de relatório com ícones
Fonte: Autoria própria
Figura 26 - Combo com seleção múltipla
Fonte: Autoria própria
Figura 27 - Usando Sweet Alert mensagem sistema
Fonte: Autoria própria
Houve também funcionalidades que foram feitas inteiramente do zero onde dentre elas estão:
Na funcionalidade de Análise de Mensagem do Chat se criou um botão para calcular o que foi salvo e assim mostrar cada particularidade da atividade separada em vários aspectos:
O uso do SCRUM foi feito por ser metodologia ágil para web, ele ter reuniões rápidas e frequentes também ajuda para ter rápido retorno do que está acontecendo.
Temos um ponto forte no SCRUM por ele já ser uma metodologia ágil o que ajuda por ela já estar desenvolvido nessa dinâmica. Também outro ponto que podemos ver é a separação de tarefas por cada etapa, o que gera uma organização e evita muito papel. A separação das reuniões do estilo que é o SCRUM é o que mais se equipara ao que necessitávamos. Semanalmente é programado a entrega de um Sprint cujo acontece as quartas feiras para ponderam e ver o que ainda é essencial ao termino.
Na utilização da linguagem de programação temos o benefício de reusabilidade cujo é feito empregando o máximo de componentes possíveis, onde pode-se ver aspectos claros com o uso de interface. Também para o uso da web temos o benefício de uso perante a todo mundo poder usar o sistema desde eu seja alocado em algum servidor.
No contexto da web ainda abrimos ao uso da técnica de Local Storage onde uma vez salvando esses dados no navegador aumentou e muito a performance do sistema nas partes onde a técnica foi usada.
O problema inicial é que o SCRUM não pode ser usado sem uma boa adaptação. Pois a produção basicamente isolada não é a mesma que empregada no SCRUM. Foi dispensado o uso de reuniões diárias e a separação por três grupos de pessoal não foi usado, e foi alterado para somente dois grupos para pessoal.
Um ponto ruim é montar uma estrutura fixa de revisão com data predeterminada em um projeto volátil em questões de alterações de visual, funcionalidades e novas integrações.
O uso da orientação a objetos de forma exagerada e ou errada pode também trazer problemas de performance tais como foram identificados no objeto questão, quando era feito busca de qualquer conjunto de questão também era retornado as proposições de todas elas. Para poucos dados não importa retornar as proposições mais como viu com muitas questões trazer as proposições acabou deixando lerdo o retorno de dados na busca de questão inicial. Para arrumar a lerdeza foi usado a técnica de salvar os dados da tabela com HTML5 Local Storage, ou seja, salvando os dados da tabela no browser ficou retornando bem mais rápido.
REFERÊNCIAS
AGUIAR, Giancarlo de França; PEINADO, Jurandir. COMPREENDENDO O KANBAN: UM ENSINO INTERATIVO ILUSTRADO, 2007.
APACHE. Apache Struts: The Apache Software Foundation, 2017. Disponível em: <http://struts.apache.org/>. Acesso em: 25 maio 2017.
BARROS, Pablo Vincius A. de; ALMEIDA, Isledna Rodrigues de; EMERY, Richarylson A. SCRUM: Uma metologia ágil para projetos web com pequenas equipes, 2009. Disponível em: <http://www.eventosufrpe.com.br/jepex2009/cd/resumos/r1106-3.pdf >. Acesso em: 25 maio 2017
BISSI, Wilson. Scrum – Metodologia de desenvolvimento ágil, 2007. Disponível em: < http://revistas.bvs-vet.org.br/campodigital/article/viewFile/30944/33947>. Acesso em: 25 maio 2017
CRISP. Kanban, 2017. Disponível em: < https://www.crisp.se/gratis-material-och-guider/kanban>. Acesso em: 25 maio 2017.
ISHIKAWA, Eliana. COLLABORA: A COLLABORATIVE ARCHITECTURE FOR EVALUATING INDIVIDUALS PARTICIPATION DURING THE DEVELOPMENT OF ACTIVITIES. Internation Journal of Software Engineering & Applications, v. 8, n. 1, dez. 2017.
KNIBERG, Henrik. Kanban vs Scrum, 2009. Disponível em: <https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf>. Acesso em: 25 maio 2017
LOPES, Camilo. Série Scrum: planejamento de Sprints e o papel do Product Owner, 2012. Disponível em: < https://imasters.com.br/artigo/24320/agile/serie-scrum-planejamento-de-sprints-e-o-papel-do-product-owner?trace=1519021197&source=single>. Acesso em: 25 maio 2017
MARIOTTI, F. S. Kanban: o ágil adaptativo. Introduzindo Kanban na equipe ágil, 2012. Disponível em: <http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf>. Acesso em: 25 maio 2017
MARTINS, Rafael. Kanban: 4 passos para implementar em uma equipe, 2014. Disponível em: <http://www.devmedia.com.br/kanban-4-passos-para-implementar-em-uma-equipe/30218>. Acesso em: 25 maio 2017.
NETO, Cazuza. Conhecendo o Scrum, 2012. Disponível em: <http://www.devmedia.com.br/conhecendo-o-scrum/25744>. Acesso em: 25 maio 2017.
PALHARINI, João Pedro Berton. Integração de aplicações via dados, 2016. Disponível em: < http://www.devmedia.com.br/integracao-de-aplicacoes-via-dados/34468>. Acesso em: 25 maio 2017.
PRADO, Alexandro dos Anjos. Fundamentos do Java Struts, 2007. Disponível em: <http://www.devmedia.com.br/fundamentos-do-java-struts/7238>. Acesso em: 25 maio 2017.
Schwaber, Ken; Sutherland, Jeff. Um guia definitivo para o Scrum: As regras do jogo, 2013.
SILVA, Douglas Marcos da. UML Guia de Consulta Rápida, 2001.
Figura 1 - Quadro exemplo Kanban preenchido. 7
Figura 2 - Quadro de Kanban Collabora. 11
Figura 3 - Diagrama BPMN para login no sistema. 13
Figura 4 - Diagrama BPMN iniciar atividade para aluno. 13
Figura 5 - Diagrama BPMN aluno respondendo atividade. 14
Figura 6 - BPMN Login professor 14
Figura 7 - BPMN verificar inatividade sistema. 15
Figura 8 - Diagrama de Caso de Uso Aluno. 16
Figura 9 - Diagrama de caso de uso Gerente. 17
Figura 10 - Diagrama de Caso de Uso Usuário fazendo Login.. 18
Figura 11 - Diagrama de caso de uso para Professor 19
Figura 12 - Diagrama de classe relação entre usuário e acesso. 20
Figura 13 - Diagrama de classe Questão e seus vínculos diretos. 21
Figura 14 - Diagrama de classe turma e seus relacionamentos. 22
Figura 15 - Diagrama de classe dica x conteúdo. 23
Figura 16 - Diagrama de classe Conteúdo Site. 23
Figura 17 - Diagrama de classe configurações gerais. 24
Figura 18 - Diagrama de classe Atividade X Questão. 25
Figura 19 - Diagrama de classe Mensagem X Aluno. 26
Figura 20 - Validação required input html5. 29
Figura 21 - Validação input file accept 30
Figura 22 - Validação jQuery min e máx input number 30
Figura 23 - Botões de relatório com ícones. 31
Figura 24 - Combo com seleção múltipla. 31
Figura 25 - Usando Sweet Alert mensagem sistema. 32
sumário
1 DESCRIÇÃO.. 4
2 MODELO DE DESENVOLVIMENTO DO SISTEMA ADOTADO.. 4
2.1 JUSTIFICATIVA.. 4
2.2 Scrum.. 5
2.2.1 Etapas do SCRUM utilizadas no estudo de caso. 6
2.3 KANBAN.. 6
2.3.1 Etapas do Kanban na literatura. 6
2.3.2 Etapas do Kanban utilizadas no estudo de caso. 7
2.4 Diagramas UML. 7
3 Aplicação do modelo adotado. 8
3.1 Planilha de solicitação de mudanças. 8
3.2 Diagramas adotados. 10
3.2.1 Diagrama BPMN.. 10
3.2.2 Diagrama de caso de uso. 13
3.2.3 Diagrama de classe. 17
3.3 Metodologia de desenvolvimento. 24
3.4 Implementações feitas. 25
4 Análise crítica do uso do modelo adotado. 28
4.1 Identificação dos pontos fortes. 28
4.2 Identificação dos pontos fracos. 29
O projeto que será usado como fonte de pesquisa para a disciplina de Engenharia de Software é o Collabora, um sistema de chat colaborativo destinado a verificar se aluno participa ou não das atividades colaborativas propostas. Fornece também a possibilidade do professor cadastrar e oferecer questionários aos alunos. As questões quando cadastradas ficam disponíveis para os grupos de alunos vinculados aquela atividade onde vai ser gravado as mensagens e verificado a colaboração posteriormente. O trabalho vai descrever correções e integrações de novas funcionalidades que houveram durante o desenvolvimento do sistema, a metodologia que foi empregada para separar o trabalho, além das ferramentas usadas e seus produtos gerados.
Optou-se pelo SCRUM como sendo uma metodologia de desenvolvimento pois dei acordo com BISSI (2007, p.1) ele é “extremamente ágil e flexível”. Na parte da programação foi escolhido a linguagem de programação Java usando o framework Struts2. Para banco de dados foi escolhido o PostgreSQL pois de acordo com PALHARINI (2016) ele é melhor que o MySQL “pela constante atualização da plataforma e consequentemente implementação acelerada de novas funcionalidades”.
2.1 JUSTIFICATIVA
O modelo foi escolhido por que dá a nós uma forma de somente uma pessoa programar, e ter a pessoa separada que avalia e valida as entregas. A linguagem de programação em Java e o uso do framework Struts2 foi algo que já veio com o projeto por isso acabou-se por continuar com ela e também por que seria inviável refazer tudo do zero em outra linguagem ou framework.
Na questão de planejamento foi escolhido o SCRUM ele é a metodologia com menos entregas possíveis. De acordo com BISSI (2007, p.1) ele “pode ser aplicado a qualquer produto ou no gerenciamento de qualquer atividade complexa, proporcionando um excelente entrosamento entre as equipes de desenvolvimento“. A aplicação dele ainda teve quer ser um pouco modificada para ser adaptada a realidade do projeto, porém é o ideal de acordo com BARROS (2009, p. 1) “se adéqua a equipes pequenas e projetos altamente dinâmicos e mutáveis, como a WEB”.
2.2 Scrum
De acordo com Schwaber (2013, p.3) o SCRUM é um framework usado para manter produtos complexos e adaptativos. Dividido em quatro eventos importantes descritos em sequência:
- Planejamento da Sprint, de acordo com LOPES (2012) tem dois pontos importantes para se considerar que são: saber o nível de importância que temos no product backlog e o product owner precisa ter conhecimento da listagem criada sem ficar preocupado com o necessário para sua implementação;
- Reunião diária que são feitas na média de 15 minutos pela manhã quando toda a equipe está reunida, serve para ver o que cada uma vai fazer durante o dia;
- Reunião para revisar o Sprint;
- Retrospectiva da Sprint
No geral ainda temos a separação de quem compõe uma equipe de SCRUM que de acordo com NETO (2012) é composto de três papéis:
- Product Owner: libera versões funcionais para o cliente, aceita ou rejeita os resultados dos trabalhos, garante a transparência do product backlog, e ordena a produção de acordo com a visão de prioridade do cliente
- Development Team (DT): são os programadores que desenvolve versões incrementais do produto que são entregues ao final de cada rodada (Sprint).
- Scrum Master (SM): gerencia a equipe de desenvolvimento estando em contato direto ao Product Owner. No geral ele sempre fica disponível para retirada de dúvidas no decorrer do projeto, assim elimina os problemas e preserva o bom funcionando em cada Sprint.
2.2.1 Etapas do SCRUM utilizadas no estudo de caso
Das etapas do SCRUM foi dispensado as reuniões diárias, pois ficaria inviável a reunião diária para a equipe tanto devido a distância pelo trabalho estar sendo realizado em diferentes locais. Normalmente Sprints são definidos por períodos de um mês ou menos baseado em Schwaber (2013, p.8) porém como não conseguiu manter a reunião diária manteve-se o Sprint onde ele ficou agendado para reuniões semanais de revisão e verificação de funcionalidades estavam de acordo com o pedido.
Na separação de papéis as funções de Scrum Master e Product Owner foi englobada em somente uma, pois nesse caso o cliente tinha conhecimento técnico suficiente para retirar as dúvidas.
2.3 KANBAN
Para gerenciar o andamento do projeto será usado o Kanban que de acordo com MARTINS (2014) é um sistema para gerenciar o fluxo de trabalho com cartões onde na medida que o trabalho vai evoluindo ele é mudado de estágio. De acordo com AGUIAR (2007, p.176) as vantagens em utilizar são:
- Ele valoriza o colaborador, fazendo com que ele tenha contribuição para experiência do sistema
- É um processo controlado pela produção
- Limita e permite reduzir estoques
- Reduz os cursos de fabricação
- Tem baixo custo de implantação, por só precisar de um quadro ele é o que há de mais viável nos dias atuais, e ainda temos os vários sistemas de Kanban criados que também nem precisam de quadro, e podem ser usados pela toda a equipe só precisando de um computador para acesso à internet, tal como o sistema da Trello.
Para CRISP (2017) coloca benefícios mais envolvidos a área de desenvolvimento de software que podem ser vistos a seguir:
- Gargalos ficam visíveis o que torna mais fácil sua otimização;
- Fornece o caminho para evolução gradual e desenvolvimento ágil;
- Pode ser usado mesmo sem integração ao Scrum com Sprints;
- É possível ser usado em todos os departamentos da empresa facilmente para ter fácil visibilidade do que está acontecendo;
2.3.1 Etapas do Kanban na literatura
De acordo com MARIOTTI (2012, p. 7) as etapas do Kanban se resume a três:
- Visualização de processos;
- Limitação do trabalho por tarefas, que seria a separação do trabalho em pequenos assuntos mediante os quais podem ser anotados em cartões;
- Gerenciamento do lead-time, onde se verifica o tempo que vai se levar para passar as atividades e chegar a sua entrega;
Um quadro exemplo de como é o Kanban pode ser vista na figura seguinte:
Figura 1 - Quadro exemplo Kanban preenchido
Fonte: KNIBERG (2009, p.1)
2.3.2 Etapas do Kanban utilizadas no estudo de caso
Para utilização no processo, houve muitas reuniões mediante as quais pode-se retirar a visualização dos processos via descrição de cada tela e suas funcionalidades. A limitação do trabalho em geral foi feita pela professora Ishikawa, porém como eram várias alterações verificou-se a necessidade de fazer reuniões e adotar novos prazos para entrega.
A cada reunião realizada foi ponderado o que se realizou e o que ainda ficou a ser feito, dando assim possibilidade de arrumar o cronograma de entregas e visualizar as possíveis datas de entrega reais para cada funcionalidade que estivesse atrelada as tarefas agregadas ao projeto.
2.4 Diagramas UML
De acordo com SILVA (2001, p.10), eles “são a representação gráfica de um conjunto de elementos do sistema”. Ainda de acordo com SILVA (2010, p.10) ele permite representar as diferentes partes do sistema através de um modelo. Usar diagramas ajudam para não ter que analisar o código fonte cada vez que um novo integrante é inserido na equipe, assim ele pode analisar todas as regras sem ter que abrir o código fonte e ter certeza de qualquer alteração que irá fazer.
Será usado o framework Struts2 para desenvolvimento que segundo APACHE (2017) ele serve para criar aplicações MVC com Java, favorecendo a configuração e sendo extensível a uma arquitetura de plug-in e tem suporte para REST, AJAX e JSON. Um segundo conceito de acordo com PRADO (2007) é que ele é um framework open-source com base no projeto Jakarta aonde o mesmo usa Servlets, JavaBeans, XML e seu uso é voltado ao modelo MVC (Modelo / Visão / Controle).
3.1 Planilha de solicitação de mudanças
A planilha em sequência mostrara as alterações pedidas de maneira geral separando pelo que foi feito naquele contexto, porém mudanças tais como alteração do padrão de PDF foi feito em vários lugares.
Tabela 1 - Planilhe de Controle de Mudanças
| Data | Requisitante | Mudança | Aprovada? |
| 15/03/2017 | Eliana Ishikawa/ Simone Nasser | JavaScript no final da página e CSS todo em cima, alocação da chamada do script isolado em uma página incluída chamada head.jsp e footer.jsp para evitar usar várias versões de JQuery ou outros nas diferentes páginas assim também otimizando a abertura das páginas | SIM |
| 15/03/2017 | Eliana Ishikawa/ Simone Nasser | Importação para alunos e professores em planilha CSV colocando nova coluna para e-mail | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Validação de sessão para quando não estiver logado faz tempo cair o sistema | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Corrigir botão sair para finalizar a sessão e repetir senha na entrada não deixando a pessoa entrar sem estar logada | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Esqueceu senha adaptando coluna e-mail para tabelas gerente, aluno e professor usando conta SMTP do Gmail | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Tirar tela verde que era a principal e contato, inserir os logos dos programas no rodapé de tudo | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Arrumar cadastro de referências, proposições, disciplina, ementa, conteúdo, exercícios, turma, grupos | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Revisão de erros de português e codificação do sistema, alterando tudo para o padrão de utf8 | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Utilização de validação de html5 nas diferentes telas | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Utilização de Sweet Alert para melhorar o visual das mensagens dadas na tela pelo sistema | SIM |
| 22/03/2017 | Eliana Ishikawa/ Simone Nasser | Corrigir erros de responsividade do sistema, transformar tabelas em responsivas | SIM |
| 14/05/2017 | Eliana Ishikawa/ Simone Nasser | Cadastro de dicas com procurar | SIM |
| 14/05/2017 | Eliana Ishikawa/ Simone Nasser | Criar gerenciar de conteúdo do site colocando já para editar a página de descrição do sistema e equipe disponível para gerentes | SIM |
| 14/05/2017 | Eliana Ishikawa/ Simone Nasser | Verificação de performance e criação dos índices correlacionados ao banco de dados nas principais queries | SIM |
| 14/05/2017 | Eliana Ishikawa/ Simone Nasser | Uso de cache com Local Storage em questões para melhorar o retorna da busca | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | Combo com select multiple para questões nos campos de conteúdo e ementa | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | Tela para análise de mensagem do chat | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | Tela de estatística do chat gerado após salvar com botão de calcular na tela de análise do chat | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | Relatório de Acessos gravando data cadastro, nome, endereço ip, e tipo de usuário colocando menu para consultar pelo login de gerentes | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | Tela de configuração campos para peso 1 e 2 links redes sociais e logos | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | PDF com cabeçalho saindo logo Collabora e rodapé logo UTFPR e programas PPGCC e PPGECT | SIM |
| 24/05/2017 | Eliana Ishikawa/ Simone Nasser | CSV, PDF, XLSX para onde tivesse possibilidade de realizar buscas na tela com tabela DataTable | SIM |
| 07/06/2017 | Eliana Ishikawa/ Simone Nasser | Configuração de Atividade para pesos de postagem e significativa, e mínimo e máximo do grupo | SIM |
| 07/06/2017 | Eliana Ishikawa/ Simone Nasser | Fazer telas que tinham carregamento de arquivos, mostrar para baixar eles na tabela de busca. Exemplo: dica | SIM |
Fonte: Autoria própria
3.2 USANDO O KANBAN
Para montagem da separação de tarefas, foi usado o sistema online chamado Trello, cujo mesmo é gratuito e permite a criação do quadro e acompanhamento por quem tu quiser convidar podendo definir permissões de visibilidade e também modificação. A seguir pode ser verificado como ficou as tarefas quase ao final da entrega desse projeto, nele pode-se ver a separação ideal entre quadros. Tem algumas referências que ainda colocam o uso de mais um quadro que seria para produção, porém a montagem dos quadros é opcional e adaptável ao seu ambiente de trabalho.
Figura 2 - Quadro de Kanban Collabora
Fonte: Autoria própria
Claro que no Kanban temos a movimentação dos quadros então periodicamente eles mudam de lugar de acordo com o que for terminando uma tarefa ela é mudada de quadro, porém a figura anterior pode demonstrar de maneira geral como ficou a estruturação de tarefas. Devido a ser usado o sistema online evitou-se a possibilidade de ficar perdido com o que foi feito e assim ter uma real noção do andamento do projeto alocada em um lugar só para todo mundo que tivesse permissão visualizar.
Ainda na ferramenta Trello percebe-se que é possível uma separação por cor o que seria muito bom para um acumulo de cartões em maior quantidade.
3.3 Diagramas adotados
Diagramas que serão usados no projeto serão BPMN, casos de uso e de classes. Mediante os diagramas de caso de uso vai ser demonstrado o que foi feito e o que foi corrigido perante o sistema. Já no diagrama de classes será demonstrado por funcionalidades descrevendo o objeto e também os métodos que o utilizam para determinar seu escopo. E nos diagramas de BPMN foi decidido usar para ter uma visão geral de ações que levavam condicionais em considerações para executar uma tarefa A caso a ação condição fosse verdade ou B caso fosse falsa.
Optou-se por somente esses tipos, por que a produção inicial dos diagramas já havia sido feita. Então de maneira geral só quisemos demonstrar o que foi alterado mediante o sistema o que faz esses tipos de diagramas darem uma boa visão geral do sistema e de forma rápida.
3.3.1 Diagrama BPMN
Para demonstração do ato de entrar no sistema optou-se por usar o diagrama de BPMN cujo demonstra o passo a passo e as decisões envolvidas nele. No diagrama a seguir demonstrasse que para entrar no sistema ele usa como base o de Usuário onde nele se questiona primeiramente se aquele registro e senha é do tipo gerente, depois do tipo aluno e por final do tipo professor caso sucesso em algum desses caminhos ele direciona para seu respectivo painel, caso não ao final de tudo ele direciona para mensagem de erro e finaliza a ação.
Figura 3 - Diagrama BPMN para login no sistema
Fonte: Autoria própria
Quando quem estiver entrando for um aluno o sistema deve conferir se tem atividade disponível e tem número mínimo de pessoas ativas no grupo é o diagrama que vem em sequência. Nele pode se verificar o passo a passo que é feito pelo script, temos uma verificação se existe atividade, e posteriormente a verificação se o aluno tem mais alguém do seu grupo conectado para iniciar a atividade só então se tudo for positivo então poderá começar a atividade.
Figura 4 - Diagrama BPMN iniciar atividade para aluno
Fonte: Autoria própria
Para resposta da atividade os alunos devem começar a discutir no chat suas ponderações e em sequência será perguntado qual a alternativa e se todos responderem a mesma será mostrado se acertou ou não até a última questão. Na sequência então mostra-se o diagrama BPMN para mostrar como o sistema age para quando o aluno está ativo e com grupo mínimo de duas pessoas para iniciar suas atividades. Nele pode-se verificar etapas onde se pede consenso na resposta dada pelo grupo, e também é possível ver o ciclo de tarefas do script repete até não haver mais exercícios.
Figura 5 - Diagrama BPMN aluno respondendo atividade
Fonte: Autoria própria
Quando quem estiver entrando é um professor tem uma verificação se o mesmo já cadastrou alguma atividade e caso sim mostra dados atualizadas em sua tela inicial, caso não vem o painel, porém com informações vazias para atividade.
Figura 6 - BPMN Login professor
Fonte: Autoria própria
Para o sistema quando o usuário já está ativo foi feito uma verificação de tempo de inatividade, onde o mesmo a partir de 30 minutos após o usuário não fizer nenhuma ação e decidir recarregar a página ou trocar de funcionalidade será direcionado para fora do sistema. Assim com isso evitamos que alguma pessoa mal-intencionada acesse a sessão de outro usuário que por engano acabou deixando ela ativa. Na sequência tem o diagrama BPMN para conferir sessão inativa:
Figura 7 - BPMN verificar inatividade sistema
Fonte: Autoria própria
Para o cálculo de colaboração ele é feito pelo professor onde o mesmo primeiramente escolhe as mensagens a serem selecionadas e depois pode salvar seu resultado para em sequência ser feito o cálculo. No diagrama a seguir pode ser visto como é o caminho até poder calcular a colaboração, onde também é visto a necessidade de ter preenchido as configurações de peso da atividade.
Figura 8 - BPMN professor calculando colaboração
Fonte: Autoria própria
3.3.2 Diagrama de caso de uso
Na definição dos casos de uso dentro do diagrama foi usado o padrão “Manter ...” cujo ele demonstra que é o responsável pelo padrão na funcionalidade de CRUD (Create, Read, Update, Delete), ou seja, ele nos possibilita uma visão direta que a funcionalidade é ali responsável por criar, procurar, atualizar ou excluir uma linha da tabela. Na criação dos diagramas de caso de uso foi separado em quatro agrupamentos principais:
- Aluno: onde a funcionalidade é responsável por abrir o chat, verificar novas atividades e se tiver grupo ativo começar a mesma junto ao chat. A figura 4 e 5 podem servir como complemento ao entendimento do caso de uso a seguir do aluno;
Figura 9 - Diagrama de Caso de Uso Aluno
Fonte: Autoria própria
- Gerente: gerencia professores cadastrados, alunos, disciplinas, turmas, outros gerentes, ementas, conteúdo, cadastro novos conteúdos no site, e também tem o relatório de acessos.
Figura 10 - Diagrama de caso de uso Gerente
Fonte: Autoria própria
- Usuário: responsável diretamente pela realização do login onde nessa ação realiza a gravação do acesso e qual foi o tipo de usuário usado, posteriormente acessando seu respectivo painel. Ele também é responsável por sair do sistema.
Figura 11 - Diagrama de Caso de Uso Usuário fazendo Login
Fonte: Autoria Própria
- Professor: ator responsável pela gestão de atividade, exercícios que compõe a atividade, grupos que são agrupamentos de alunos para compor a atividade, referências para usar no cadastramento de exercícios, dicas que são disponibilizadas quando o aluno estiver respondendo determinada atividade, mensagem onde o professor visualiza a troca do que foi conversado entre os alunos e pode considerar se é significativa, e configurar atividade para definir pesos, mínimo e máximo de pessoas a participar de um grupo.
Figura 12 - Diagrama de caso de uso para Professor
Fonte: Autoria própria
3.3.3 Diagrama de classe
Após a criação dos diagramas de caso de uso é possível verificar as classes, contudo como esse projeto não foi inicia do zero também se usou como base a separação pelas principais funcionalidades. Na sequência será mostrado o diagrama que mostra o relacionamento entre acesso e usuário onde um usuário poderá ter nenhum ou múltiplos acessos no sistema.
Figura 13 - Diagrama de classe relação entre usuário e acesso
Fonte: Autoria própria
Na construção da questão temos sua relação diretamente com as proposições onde pode haver para uma questão a proporção de uma ou mais proposições. Ainda para questão temos a relação com referência que para cada questão é obrigatório o cadastramento de uma referência e também por último temos o vínculo ao conteúdo da questão sendo que para uma questão pode haver um ou mais conteúdos vinculados. Na sequência colocasse o diagrama dessa relação:
Figura 14 - Diagrama de classe Questão e seus vínculos diretos
Fonte: Autoria própria
Na relação de turma temos a conexão com aluno onde uma turma pode ter um ou muitos alunos. Conectando a turma temos o professor que pode ser responsável por nenhuma ou muitas turmas e também por último a disciplina que uma turma pode ter nenhuma ou muitas.
Figura 15 - Diagrama de classe turma e seus relacionamentos
Fonte: Autoria própria
A relação entre dica e conteúdo é feita na proporção de um conteúdo pode ter nenhuma ou mais dicas cadastradas correlacionadas a ele. Pode-se ver melhor a sua relação no diagrama a seguir:
Figura 16 - Diagrama de classe dica x conteúdo
Fonte: Autoria própria
Para podermos editar conteúdo externo ao sistema de páginas de apresentação tais como equipe e descrição do projeto foi criado a funcionalidade de Conteúdo Site dentro dela é possível alocar conteúdo referente a página e o gerente do sistema poderá editar sem precisar que um programador edite o HTML direto no código fonte da página. Ao desenvolver a classe foi usado atributo para título da página e texto sendo esse gravado quase sem limitação de tamanho. Pode ser visto como ficou o diagrama na sequência:
Figura 17 - Diagrama de classe Conteúdo Site
Fonte: Autoria própria
Para configurações gerais ao sistema, foi criada a classe chamada Geral nela foi colocado atributos para alterar a URL Facebook, Twitter que são as redes sociais que ficam visíveis externamente ao projeto, também para possibilidade de trocar os logos de forma facilitada foi criado os campos para UTFPR, PPGCC, PPGECT, e do sistema que é o Collabora.
Figura 18 - Diagrama de classe configurações gerais
Fonte: Autoria própria
Para realizar o cadastramento de atividade, foi feito o diagrama de classes integrando a classe Atividade que pode ser relacionada a questão na taxa que uma atividade pode ter uma ou mais questões. Para demonstrar ainda a integração inicial de questão a seus outros relacionamentos fizemos a composição na figura seguinte também com as classes de proposição, referência, e conteúdo que se interligam essas a questão.
Figura 19 - Diagrama de classe Atividade X Questão
Fonte: Autoria própria
Para análise de Mensagens foi decidido fazer algo um pouco diferente, já que as mensagens eram estruturadas em três classes ditas Colaboracao, ColaboracaoComAnexo, e ColaboracaoTextual ficaria complicado fazer a busca desses elementos separados então foi feito a classe de Mensagem cujo serve de para agrupar e ajudar a salvar a mensagem em relação se é significativa ou não. O diagrama a seguir irá mostrar a relação entre a classe de Mensagem e a classe de Aluno cujo seria o dono da mensagem enviada.
Figura 20 - Diagrama de classe Mensagem X Aluno
Fonte: Autoria própria
3.4 Metodologia de desenvolvimento
Idealizamos o uso do SCRUM por ter seu foco em desenvolvimento ágil e também por ser o que melhor se adapta a equipe de somente um programador, tendo somente os avaliadores ou professoras no caso para validação do que foi implementado. No geral seu foco de uso teve obrigatoriamente algumas modificações tais como as reuniões diárias foram abolidas, na utilização da separação entre papéis não foram usados os três que são padrão do SCRUM, porém ainda conseguimos separar.
A separação dos papéis ocorreu em Product Owner onde aqui foi mantido pelas professoras responsáveis ao projeto e as funções dos dois outros papéis foram agrupadas sobre minha responsabilidade que seriam de Development Team (Time de Desenvolvimento) e Scrum Master (Líder de equipe). Sabendo-se que a equipe era somente de uma pessoa para esse trabalho fica claro o porquê da separação.
Por ter usado o SCRUM também se criou um cronograma para entrega de atividades utilizado principalmente para mostrar as histórias de caso de. No cronograma iniciou uma primeira versão que foi disponibilizado no Google Drive o qual foi sendo melhorado de acordo com novas histórias. As histórias foram montadas em base de perguntas feitas as professoras em cada.
3.5 Implementações feitas
Para criação das telas, ou seja, na camada de visualização foi utilizado o padrão do projeto que estava com framework Boostrap cujo ele nos fornece suporte a HTML, CSS, e JavaScript em determinadas funcionalidades usando integração para isso com o framework jQuery. O Boostrap foi escolhido pois nos fornece um padrão de desenvolvimento com responsividade, ou seja, ele se auto ajusta as diferentes telas que acessam o sistema desde que seja devidamente bem usado.
Houve-se algumas correções em telas devido ao mal-uso do framework Boostrap onde tivemos que zerar seu CSS ao original pois muitas modificações haviam sido feitas nele, e fomos voltando as alterações aos poucos em arquivo de estilo separado para o que foi modificado assim achando os problemas e restaurando padrões de responsividade quebrados entre outras coisas.
Para a iteração cliente servidor foi usado sempre que possível o padrão de retorno ou envio de dados com AJAX usado com framework jQuery e também integrações ao seu plugin Datatables para construção das tabelas. O uso de AJAX nos é interessante pois deixa a web mais dinâmica, ele é usado com retornos em JSON, ou text que seria para texto puro. Dentro desse componente de tabela ainda conseguimos a responsividade escondendo colunas dinamicamente e colocando no lugar delas um sinal de “+” onde clicando sobre o mesmo abre as colunas que foram escondidas em resoluções menores, já em resoluções maiores ele mostra todas as colunas para as buscas realizadas.
Para as funcionalidades de Manter Aluno e Manter Professor foi criado importações via planilhas CSV que ajuda no dia a dia do uso administrativo do Collabora a realizar o rápido cadastramento de novas turmas e ou professores. Nessas páginas para evitar a submissão integral da mesma usamos o plugin JQuery Form Plugin que envia escondido o arquivo sem submeter a página que evita ter que recarregar a página e retorna somente o necessário que seria uma mensagem em JSON com objeto com situação se foi bem-sucedido ou não o tramite. Nessa importação também inserimos a coluna de e-mail que agora no sistema poderá ser usada para recuperar a senha, caso esteja devidamente preenchido e correlacionado ao seu usuário no banco de dados. Na figura a seguir pode ser visto como ficou o campo de esqueceu senha, estando preenchido o campo usuário com o registro do usuário e sendo ele válido a pessoa poderá clicar sobre o campo esqueceu senha e será enviado um e-mail para o seu cadastro correlacionado.
Figura 21 - Formulário de Login com Esqueceu senha
Fonte 2: Autoria própria
Para as buscas usa o botão extensível do jQuery Datatable denominado de pdfhtml5 que funciona com uma integração a um plugin chamado pdfmake. Neste foram feitas adaptações do cabeçalho e rodapé para mostrar os logos da UTFPR e programas de pós-graduação. Foram adicionados botões de excelHtml5 para exportar ao formato XLSX, csvHtml5 que exporta em CSV.
Para as colunas dentro da tabela foi especializado colunas de imagem para que possam ser baixadas, economizando espaço e melhorando performance ao realizar a busca. Já nos logos se usou o formato data uri, ou seja, converte a coluna respectiva em formato de texto cujo assim salvamos utilizando Local Storage do html5 onde fica gravada no browser de forma escondida para futuras impressões de PDF.
Em um contexto geral foi feito melhorias em questão de performance no projeto priorizando todo o conteúdo de visualização imediata, e deixando o carregamento de JavaScript por último cujo esse traz efeitos, ou funcionalidades que não afetam o visual inicial do sistema. Com o uso dessa técnica deu a sensação de uma melhoria substancial no carregamento das telas, também retiramos todo e qualquer uso de repositório online para todo JavaScript e arquivos CSS serem requisitados diretamente do servidor o que diminui o trafego de banda larga.
Ainda houve uma revisão de todas as funcionalidades empregadas, menos a de chat onde foram corrigidos:
- Erro de acentuação por ter padrões ruins para codificação das páginas. O novo padrão implementado foi o UTF8 e cuidou-se para manter-se esse nas novas funcionalidades criadas.
- Uso de validações com HTML5 tais como required para campos obrigatórios, max para limitar a quantidade máxima de caracteres e min para limitar a quantidade mínima de caracteres que seria usada. Na figura a seguir pode ser visto que ao deixar o campo sem preencher e clicar sobre o botão salvar uma validação diferente que é um modelo padrão do navegador cujo o uso dela também ajuda na padronização visual e se a pessoa usuário do Collabora já usou algum outro sistema web certamente com esse tipo de mensagem saberá mais facilmente o que significa.
Figura 22 - Validação required input html5
Fonte: Autoria própria
- Validações em inputs de arquivos para aceitar somente tipos específicos usando “accept”. Para importação foi usado accept=”.csv” o que faz serem somente permitidos arquivos CSV naquele componente. Um exemplo de como fica esse tipo de validação pode ser visto na figura a seguir, onde abrindo o gerenciador de arquivos para escolher ele só mostra os arquivos previamente definidos no componente via atributo accept;
Figura 23 - Validação input file accept
Fonte: Autoria própria
- Validações com jQuery para mínimo e máximo em campos input number evitando com que o usuário digite números diferente do intervalo. Pode se ver na figura a seguir um exemplo onde anteriormente a mensagem foi digitado um no campo “min. grupo” ele ativou a mensagem e redefiniu o campo para seu valor certo sendo no caso 2;
Figura 24 - Validação jQuery min e máx input number
Fonte: Autoria própria
- Houve-se um uso massivo de ícones da Font Awesome onde podemos citar principalmente para botões de PDF, XLSX, CSV, calculadora, procurar, inputs para data, entre muitos outros.
Figura 25 - Botões de relatório com ícones
Fonte: Autoria própria
- Também podemos citar várias funcionalidades que haviam um problema ou outro de inserção de dados onde foram corrigidos tais como telas de aluno, professor, gerente, referências.
- Na função de Exercícios refizemos para ela aceitar salvar para uma questão um ou mais ementas, e um ou mais conteúdo. Onde isso é útil para um professor aproveitar questões e cadastrar em todas as matérias correlacionadas. Na figura a seguir pode ser visto que foi usado com componente select da Boostrap onde permite a seleção de uma ou mais opções vinculados a ele.
Figura 26 - Combo com seleção múltipla
Fonte: Autoria própria
- Uso do Sweet Alert cujo deixou muito bonito as mensagens ao invés de usar o velho alert padrão para sistemas web.
Figura 27 - Usando Sweet Alert mensagem sistema
Fonte: Autoria própria
Houve também funcionalidades que foram feitas inteiramente do zero onde dentre elas estão:
- Grupos havia-se o conceito, porém, todo o JavaScript de efeitos a tela e correlacionar o grupo ao aluno foi feito do zero.
- De Dicas que irá funcionar para os alunos terem orientação para as respostas mediante um conteúdo x;
- Configuração para o professor definir um peso para postagens, peso para mensagens significativas, nivelar mínimo e máximo de pessoas por grupo mediante uma turma previamente selecionada. Nesse cadastro o professor poderá cadastrar configurações prévias por turma e usa-las ou não na atividade.
- Atividade onde o conceito de tela já havia sido feito, porém sem nenhum funcionamento teve-se a problema de tudo correlacionado a JavaScript citando ao efeito de adicionar novos grupos a atividade, conteúdo com mesmo efeito além de retirar várias coisas que havia nessa tela por estarem confusas e que não conseguimos uso para elas.
- Análise de Mensagem do CHAT que é usada para buscar as mensagens por vários filtros e após o professor pode escolher qual é significativa, teve um link válido ou uma imagem viável a atividade.
Na funcionalidade de Análise de Mensagem do Chat se criou um botão para calcular o que foi salvo e assim mostrar cada particularidade da atividade separada em vários aspectos:
- Mensagens significativas por aluno ou grupo: foi criada uma aba onde verificasse e também nela tem um combo separador.
- Links válidos que é dado a quantidade por grupo e agrupado por atividades realizadas.
- % de mensagem válida em links, onde nesse caso se tem a separação por aluno, grupo, e atividade onde é mostrado por agrupamentos descritos anteriormente redesenhando a tabela.
- Quantidade de acertos tem a separação por questão ou atividade, onde ainda se o professor selecionar a separação por questão pode escolher para qual atividade.
O uso do SCRUM foi feito por ser metodologia ágil para web, ele ter reuniões rápidas e frequentes também ajuda para ter rápido retorno do que está acontecendo.
4.1 Identificação dos pontos fortes
Temos um ponto forte no SCRUM por ele já ser uma metodologia ágil o que ajuda por ela já estar desenvolvido nessa dinâmica. Também outro ponto que podemos ver é a separação de tarefas por cada etapa, o que gera uma organização e evita muito papel. A separação das reuniões do estilo que é o SCRUM é o que mais se equipara ao que necessitávamos. Semanalmente é programado a entrega de um Sprint cujo acontece as quartas feiras para ponderam e ver o que ainda é essencial ao termino.
Na utilização da linguagem de programação temos o benefício de reusabilidade cujo é feito empregando o máximo de componentes possíveis, onde pode-se ver aspectos claros com o uso de interface. Também para o uso da web temos o benefício de uso perante a todo mundo poder usar o sistema desde eu seja alocado em algum servidor.
No contexto da web ainda abrimos ao uso da técnica de Local Storage onde uma vez salvando esses dados no navegador aumentou e muito a performance do sistema nas partes onde a técnica foi usada.
4.2 Identificação dos pontos fracos
O problema inicial é que o SCRUM não pode ser usado sem uma boa adaptação. Pois a produção basicamente isolada não é a mesma que empregada no SCRUM. Foi dispensado o uso de reuniões diárias e a separação por três grupos de pessoal não foi usado, e foi alterado para somente dois grupos para pessoal.
Um ponto ruim é montar uma estrutura fixa de revisão com data predeterminada em um projeto volátil em questões de alterações de visual, funcionalidades e novas integrações.
O uso da orientação a objetos de forma exagerada e ou errada pode também trazer problemas de performance tais como foram identificados no objeto questão, quando era feito busca de qualquer conjunto de questão também era retornado as proposições de todas elas. Para poucos dados não importa retornar as proposições mais como viu com muitas questões trazer as proposições acabou deixando lerdo o retorno de dados na busca de questão inicial. Para arrumar a lerdeza foi usado a técnica de salvar os dados da tabela com HTML5 Local Storage, ou seja, salvando os dados da tabela no browser ficou retornando bem mais rápido.
REFERÊNCIAS
AGUIAR, Giancarlo de França; PEINADO, Jurandir. COMPREENDENDO O KANBAN: UM ENSINO INTERATIVO ILUSTRADO, 2007.
APACHE. Apache Struts: The Apache Software Foundation, 2017. Disponível em: <http://struts.apache.org/>. Acesso em: 25 maio 2017.
BARROS, Pablo Vincius A. de; ALMEIDA, Isledna Rodrigues de; EMERY, Richarylson A. SCRUM: Uma metologia ágil para projetos web com pequenas equipes, 2009. Disponível em: <http://www.eventosufrpe.com.br/jepex2009/cd/resumos/r1106-3.pdf >. Acesso em: 25 maio 2017
BISSI, Wilson. Scrum – Metodologia de desenvolvimento ágil, 2007. Disponível em: < http://revistas.bvs-vet.org.br/campodigital/article/viewFile/30944/33947>. Acesso em: 25 maio 2017
CRISP. Kanban, 2017. Disponível em: < https://www.crisp.se/gratis-material-och-guider/kanban>. Acesso em: 25 maio 2017.
ISHIKAWA, Eliana. COLLABORA: A COLLABORATIVE ARCHITECTURE FOR EVALUATING INDIVIDUALS PARTICIPATION DURING THE DEVELOPMENT OF ACTIVITIES. Internation Journal of Software Engineering & Applications, v. 8, n. 1, dez. 2017.
KNIBERG, Henrik. Kanban vs Scrum, 2009. Disponível em: <https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf>. Acesso em: 25 maio 2017
LOPES, Camilo. Série Scrum: planejamento de Sprints e o papel do Product Owner, 2012. Disponível em: < https://imasters.com.br/artigo/24320/agile/serie-scrum-planejamento-de-sprints-e-o-papel-do-product-owner?trace=1519021197&source=single>. Acesso em: 25 maio 2017
MARIOTTI, F. S. Kanban: o ágil adaptativo. Introduzindo Kanban na equipe ágil, 2012. Disponível em: <http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-%20Kanbam.pdf>. Acesso em: 25 maio 2017
MARTINS, Rafael. Kanban: 4 passos para implementar em uma equipe, 2014. Disponível em: <http://www.devmedia.com.br/kanban-4-passos-para-implementar-em-uma-equipe/30218>. Acesso em: 25 maio 2017.
NETO, Cazuza. Conhecendo o Scrum, 2012. Disponível em: <http://www.devmedia.com.br/conhecendo-o-scrum/25744>. Acesso em: 25 maio 2017.
PALHARINI, João Pedro Berton. Integração de aplicações via dados, 2016. Disponível em: < http://www.devmedia.com.br/integracao-de-aplicacoes-via-dados/34468>. Acesso em: 25 maio 2017.
PRADO, Alexandro dos Anjos. Fundamentos do Java Struts, 2007. Disponível em: <http://www.devmedia.com.br/fundamentos-do-java-struts/7238>. Acesso em: 25 maio 2017.
Schwaber, Ken; Sutherland, Jeff. Um guia definitivo para o Scrum: As regras do jogo, 2013.
SILVA, Douglas Marcos da. UML Guia de Consulta Rápida, 2001.
Comentários
Postar um comentário