Collabora - Análise de Mensagens

• 
  

  DESCRIÇÃO

  
  

O projeto é o Collabora onde o mesmo é um sistema de chat colaborativo para ver o que cada aluno realmente participa na atividade. Ainda fornecendo também a possibilidade de o professor cadastrar e oferecer questionários aos alunos.

 

• 
  

  MODELO DE DESENVOLVIMENTO DO SISTEMA ADOTADO

  
  

Optamos pelo Scrum como sendo uma metodologia de desenvolvimento ágil ideal ao mundo de programação web. Também na parte da programação escolhemos a linguagem de programação Java cujo foi desenvolvido para ser orientado a objetos e usando o framework struts2 para facilitar a integração ao sistema final. Para banco de dados foi escolhido o PostgreSQL por ter maior facilidade e integração ao Java.

 

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.

 

2.2  Scrum

De acordo com Schwaber (2013, p.3) ele é um framework usado para manter produtos complexos e adaptativos. A sua separação de acordo com Schwaber (2013, p.4) é dividido em quatro eventos importantes descritos em sequência:

• Planejamento da Sprint


• 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

De acordo com NETO (2012) o Scrum é composto de três papéis:

• Product Owner é ele quem 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, onde eles vão desenvolvendo versões incrementais do produto que são entregues ao final de cada rodada (Sprint).


• Scrum Master (SM) ele 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 eliminando os problemas e prezando o bom funcionando em cada Sprint.

 

 

 

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 ele 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.

 

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 utilizadas no estudo de caso

Para utilização no processo, houve muitas reuniões mediante as quais podemos 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 as alterações foram mais profundas nesse caso verificou-se a necessidade de ir fazendo reuniões e adotando novos prazos para entrega.

O gerenciamento de entrega em si também é verificado a toda reunião vendo no geral onde foi entregue naquele dia e analisando quanto mais ainda teria que fazer após refazermos o planejamento com dúvidas e outros caminhos em funcionalidades que foram criadas.

 

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 nos permite representar as diferentes partes do sistema através de um modelo. Usar diagramas desse gênero ajudam para não ter que olhar o código fonte cada vez que o entra um novo integrante 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.

No geral serão mostrados diagramas de casos de uso correlacionando os objetivos de uso principal que são:

• Acesso que serve para fazer o controle de quem entrou no sistema e marcando horário, servindo para posterior pesquisa pelo Gerente.


• Aluno ele tem acesso ao chat e pode entrar em novas atividades para começar a responder.

Figura 2 - Diagrama de Caso de Uso Aluno

Fonte: Autoria própria

 

• Atividade controla quais questões estariam relacionadas a atividade e que grupos iram participar desse grupo


• A funcionalidade criada para conteúdo do site irá cadastrar conteúdo para mostrar em páginas diversas, dando a dinâmica do usuário editar o conteúdo por si mesmo sem precisar de um desenvolvedor para escrever o conteúdo HTML em cima.


• Dica para controlar e cadastrar textos que serviram de dicas para as questões da atividade


• Gerente cadastra o professor administrador onde esse 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 3 - Diagrama de caso de uso Gerente

Fonte: Autoria própria

 

• Grupo correlaciona a que alunos pertencem um grupo


• Professor correlaciona quem pode cadastrar atividade e gerenciar e determinar seu início, também cadastra questões, grupos de alunos, referência cujo serão usadas para questão, dicas para a atividade, e tem também a tela de Análise de Mensagem do CHAT.


• Questão cadastra exercícios para uma atividade, com várias opções e colocando uma alternativa como certa para validação posterior do sistema.


• Análise de Mensagem é para filtrar as mensagens de acordo com data de postagem, disciplina, turma, grupo, atividade e aluno que fizeram a postagem da mensagem. Depois o professor pode olhar mensagem a mensagem e salvar as significativas em avaliação da mensagem, se ela tem algum link, e se tem imagens consideráveis boas a atividade. Após salvar temos ainda o botão que se abre nessa tela que seria para estatística.


• Cálculo Estatístico é foi separado para observação em tabelas de significativas por aluno e grupos, links válidos, % total de mensagens válidas, quantidade de acertos durante a atividade, e na aba final tem-se o cálculo de colaboração. Nessa tela ainda fizemos a separação por cor da nota retirado.

Tabela 1 - Faixa de valores para nota de colaboração

Faixa de valores para C	Nível de Colaboração
<= 3	Muito baixa colaboração
>3 e <=5	Baixa colaboração
>5 e <= 7	Média colaboração
>7 e <= 9	Boa colaboração
>9 e <= 10	Muito boa colaboração

Fonte: Ishikawa (2017, p.41)

 

• Usuário é o objeto usado para login intermediário onde nele definimos registro e senha para posterior verificação se pode usar o sistema e também já aproveitamos para gravar a sessão. No geral ele é usado para efetuar o login de professor, aluno, e gerente que seria o cargo de professor administrador.

Figura 4 - Diagrama de Caso de Uso Usuário fazendo Login

Fonte: Autoria Própria

 

• Aplicação do modelo adotado

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 seria um framework open-source com base no projeto Jakarta aonde o mesmo usa Servlets, JavaBeans, e XML e seu uso é voltado ao modelo MVC (Modelo / Visão / Controle);

Para criação das telas, ou seja, na camada de visualização foi utilizado o template fornecido pelo 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.

Para as buscas de dados e devida inserção de dados, ou seja, quase toda a integração entre cliente browser e servidor web foi usado AJAX usado com framework JQuery e também integrações ao seu plugin Datatables para construção das tabelas. O uso de AJAX nos dias atuais é interessante pois deixa a web mais dinâmica e atual aos dias de hoje, ele é usado com técnicas de JSON. Dentro desse componente ainda conseguimos a responsividade escondendo colunas dinamicamente e colocando no lugar delas um sinal de “+” onde clicando sobre o “+” abre as colunas que foram escondidas em resoluções menores, deixando mostrando integralmente todas as colunas em resoluções maiores.

Foi criado importações via planilhas “.csv” que são extensões comuns no dia a dia atual e foram usadas para professor e alunos. Nessa situação usamos o script “jquery.form” que envia escondido o arquivo sem submeter a página. Nessa importação também inserimos a coluna de e-mail que agora no sistema poderá ser usada para repetir a senha.

Na situação das buscas ainda para automatizar usamos o botão extensível do JQuery datatable que é pdfhtml5 que funciona com uma integração a um plugin terceiro muito famoso chamado pdfmake nele foram feitos adaptação do cabeçalho e rodapé para mostrar os logos da UTFPR e programas de pós-graduação. Nesse mesmo esforço de mecanismo de exportação ainda colocamos botões de excelHtml5 para exportar ao Excel, csvHtml5 que exporta em um arquivo separado por ponto e vírgula cujo é possível abrir normalmente em várias planilhas eletrônicas tais como Excel da Microsoft ou Calc do Open Office.

Para as colunas dentro da tabela que agora era trazida pela datatable especializamos colunas de imagem para que possam baixar a mesma sem imprimir ela direto assim economizando espaço e melhorando performance ao realizar a busca. Já nos logos convertemos elas para o formato data uri, ou seja, convertemos ela em texto cujo assim salvamos utilizando Local Storage do html5 onde deixa elas gravadas no browser de forma escondida para uso em futuras impressões de PDF.

Diagramas que serão usados no projeto 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 o que será descrito o objeto em si e também os métodos que o utilizam para determinar seu escopo.

Por ter usado o Scrum também se criou um cronograma para entrega de atividades cujo foi utilizado principalmente as histórias de caso de uso para montar ele. No cronograma iniciamos uma primeira versão que foi alocado no Google Drive cujo foi sendo melhorado de acordo com novas histórias. As histórias foram montadas em base de perguntas feitas as professoras em cada reunião cujo estabelecemos o que fazer, e como fazer sobre cada funcionalidade, e também à medida que apareceriam foram dadas novas ideias.

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.

Na funcionalidade de Análise de Mensagem do Chat criamos um botão para calcular o que foi salva e assim mostrar cada particularidade da atividade separada em vários aspectos cujos quais posso citar em:

• Mensagens significativas por aluno ou grupo cujo 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 temos a separação por aluno, grupo, e atividade e mostrasse em cada caso o percentual de links que foram considerados válidos.


• 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 ele gostaria que mostrasse.

 

 

• Análise crítica do uso do modelo adotado

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 claro 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 fantástica 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. Já que a produção basicamente isolada não é a mesma que empregada no Scrum cujo é separado em 3 níveis básicos. E também o número de reuniões necessárias não foi possível mediante que uma reunião diária sozinha não é essencial.

Um ponto ruim também é montar uma estrutura fixa de revisão com data predeterminada em um projeto altamente volátil em questões de alterações de visual, funcionalidades e novas integrações o que ficavam levando a novos prazos.

Em questão de banco de dados o MySQL é mais voltado desenvolvimento web cujo ele fica ágil e também é usado pelo Facebook que seria uma opção ao invés do PostgreSQL.

Também uma alternativa legal a se considerar que facilitaria e muito o andamento seria a linguagem de programação PHP cujo demonstra e facilita que a partir dos anos melhorou. O PHP tem suporte a websocket é usado em muitas hospedagens. Também um problema que se identificou foi a falta de uso de containers cujo possibilitaria isolar o ambiente de produção e desenvolvimento, além de termos versões separadas no desenvolvimento.

Em um contexto geral também se identificou que certas maneiras de puxar os dados em objetos faziam a performance piorar. Exemplo pode-se citar que ao selecionar as questões de uma determinada disciplina, ementa relacionada a questão e conteúdo relacionado a ementa e disciplina ele traz as proposições e nisso pode demorar um tempo expressivo para retornar os dados a tela, até fazendo o usuário achar que o sistema está com erro.

Para arrumar essa 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.

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

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.

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.