icaromh / final-project Goto Github PK

• Incluir parágrafo introdutório da seção antes da subseção 4.1.

• Informar de que forma o Docker é usado no projeto e como isso auxilia o trabalho

• Para auxiliar futuros leitores, informar porque foi utilizado MongoDB ao invés de banco de dados relacional.

• O que significa “transpila”?.

• O IONIC.JS substituiu o NATIVESCRIPT durante o projeto?

The main method for gathering this information about the extent of a website, either for
search engine indexing or for archiving, is to follow the paths of links from one page to
another (so-called ‘crawling’) and there are two main issues with this:

http://21stcenturywalton.pbworks.com/f/What%20is%20Web%202.0.pdf

Pag 39

@book{andersen2007web,
  title={What is Web 2.0?: ideas, technologies and implications for education},
  author={Andersen, Per},
  volume={1},
  number={1},
  year={2007},
  publisher={JISC Bristol}
}

Estudar as melhores tecnologias para resolver o problema. Inicialmente tenho certeza de algumas:

• NodeJS - Para criação do Crawler e API(baixa latência)
• Ionic - Framework para desenvolvimento mobile hibrido
• NativeScript - Framework JS para desenvolvimento de aplicativos nativos
• Docker - Automação de deploy da infraestrutura
• NGINX - Servidor que vai gerir a porra toda
• Travis CI - Automação de Testes

Em aberto

• RabbitMQ - Para sistema de filas
• MongoDB - Não sei se é o banco ideal
• RethinkDB - Não sei se é o banco ideal
• Cache ?

Update in chapter 4 explain the tecnology.

Explain in chapter 7 why change.

• No cronograma devem constar os itens de desenvolvimento e as entregas do TCC.
• O cronograma deve estar aderente à abordagem de desenvolvimento escolhida, de modo que deve ser visível o que será entregue em cada Sprint.

1. [CRONOGRAMA] Pensei em dividir o desenvolvimento em duas etapas, seguindo TCC I e II. Na primeira etapa seria o desenvolvimento do Crawler + Normalizer + Banco + API. Parece muita coisa, mas o crawler já está "pronto". Agora preciso normalizar os dados, salvar no banco e deixar exposto em uma API. E na segunda parte iniciaria o desenvolvimento do Aplicativo, Differ e Notificações.

Descrever como funciona a segurança dos dados de um aluno

http://wp.clicrbs.com.br/conecte/2016/12/22/celular-e-o-principal-meio-de-acesso-a-internet-no-brasil-segundo-ibge/?topo=52,1,1,,171,e171

• Adicionar no capitulo 4 (analise de tecnologias) NightmareJS e Electron
• Cap.5 Descrição da Solução:
  • Descrever o fluxo que faz com que o objetivo do trabalho seja alcançado. Só desenvolver o aplicativo não é o suficiente, o que nele resolve?
  • Comentar que o MONGODB é o "dono das informações do aluno"

• Incluir parágrafo introdutório da seção antes da subseção 3.1. Algo como “Esta seção apresenta os objetivos do trabalho, divididos em objetivo geral e objetivos específicos.”.

• Incluir parágrafo introdutório da subseção 3.2 com o texto similar a “Os objetivos específicos deste trabalho são:”.

• A motivação de tempo de resposta máximo de 2s deveria ser um objetivo específico. Talvez outras motivações possam ser objetivos específicos.

O principal problema é o acesso mobile aos dados do portal do aluno. Através do celular em uma rede móvel é um grande problema acessá-lo. Existem MUITAS requisições, consultas demoradas e redirecionamentos desnecessários.

• Fazer uma pesquisa de "satisfação"
• Pegar dados do grupo de ADS do facebook, lá sempre existem reclamações de alunos.
• Pegar depoimentos de alguns alunos
• Adicionar referência dos dado %

Falta uma finalização no capítulo mostrando o que tu vai fazer, que é o escopo do teu trabalho.
Acredito que seja algo como diminuir o tráfego e uma interface melhor.

Referencia #4

Melhorar a escrita dos objetivos, mas basicamente:

• Quero entregar uma alternativa de acesso aos dados do portal, mais rápida e mais limpa.
• Quero avisar quando houver uma alteração nas faltas
• Quero avisar quando tiver uma fatura por vencer
• Quero avisar quando tiver uma nota alterada
• Quero otimizar o processo de acessar o portal, esperar cerca de 60 segundos e redireciomentos desnecessários.

• A API foi pensada em cima da estutura do crawler que busca separadamente notas e faltas, então salvava-as em collections separadas;
• Ao fazer uma POC do aplicativo, foi percebido que não fazia sentido os dados ficarem salvos separadamente se o que os une são as disciplinas. Em uma das telas do aplicativo (lista de disciplinas por semestre) o desenho mostrou-se muito mais simples unificando os dados de notas e faltas.
• Com isso as collections de notas e faltas agora uniram-se para dar vida a collection de disciplinas, onde o crawler salva (quando termina de buscar) os dados de notas e faltas daquela disciplina.

Descrever porquê não é simples hoje visualizar os dados do Portal do Aluno SENACRS

Easyac pode ser o título mas precisa de alguma explicação a respeito do projeto.

Algo como:

• Aplicação web para visualização de dados acadêmicos
• Aplicativo mobile para acompanhamento de desempenho educaional/acadêmico

Basicamente copiar do Miga Ajuda

• Scrum adaptado
• Reuniões semanais
• Validação com o cliente sempre que der

• Antes do problema, introduzir aspectos de “negócio”, no caso, o acompanhamento acadêmico.
• Remover o tempo de 10 a 40 segundos.
• Revisar tempos verbais (futuro) em todo o texto, principalmente para a versão final.

Levar em consideração descrição da #2

O principal objetivo desta seção é validar se os objetivos propostos foram atendidos.

• Informar que o código passando nos testes unitários é uma validação e está em constante melhora.
• Informar o % de cobertura de testes
• Adicionar que se os critérios de aceite fossem atingidos, era uma validação feita.
• Remover informações sobre formulários, deixar apenas para TCC II

//
Adicionar melhor como testar.

• Formulário para primeira entrega
  • facilidade de uso da API
  • facilidade de uso do crawler
  • documentação legível
  • mais coisas
• Formulário para segunda entrega
  • Facilidade de uso no app
  • Respostas imediatas

• Escolha do Orientador
• Definição do Problema #4
• Definição dos Objetivos e Solução #5
• Definição da Abordagem de Desenvolvimento #8
• Artefatos de Arquitetura #9
• Definição das Tecnologias #6
• Validação #10
• Descrição da Solução #7
• Apresentação geral do Projeto #3
• Resumo #2
• Entrega do Plano de Trabalho (mínimo, 3 orientações)
• Início do Desenvolvimento.
• Prazo para re-entrega do Plano de Trabalho
• Limite para primeira entrega.
• Primeira atualização do relatório.
• Limite para segunda entrega.
• Segunda atualização do relatório.
• Entrega do Relatório Parcial
• Preparação da Apresentação.
• Banca do Relatório Parcial
• Plano de ação para as férias.
• Limite para a terceira entrega.
• Férias
• Limite para apresentação do trabalho de férias.
• Atualização do relatório de andamento com as correções da banca.
• Limite para a quarta entrega.
• Atualização do relatório.
• Entrega do Relatório de Andamento
• Apresentação do Relatório de Andamento.
• Banca do Relatório de Andamento
• Limite para quinta entrega.
• Limite para término da implementação. Início da validação com usuários.
• Finalização do relatório de desenvolvimento.
• Finalização da análise dos resultados.
• Revisão final do relatório.
• Entrega do Relatório Final
• Apresentação para a banca final
• Banca Final
• Revisão do Relatório Final
• Entrega do Relatório Final

• Descrever a solução em aspectos funcionais e técnicos, iniciando pelos funcionais. Quais dados serão disponibilizados no aplicativo? O que o aluno poderá fazer? Após a descrição textual das funcionalidades, é conveniente listá-las em itens.

• Considerar dividir a seção em subseções.

• A Figura 3 está completa? Parece que falta algo na parte inferior (chamadas do aplicativo).

• Incluir figura da arquitetura utilizada na apresentação e explicá-la.

• Considerando a utilização de tecnologias e ferramentas bastante atuais, ilustrar e descrever mais detalhes técnicos do funcionamento da aplicação ou ampliar as descrições na seção anterior, ampliando a informação de como as tecnologias e ferramentas são utilizadas no projeto.

• Primeiro momento vai ser testada a API, constantemente atualizada e com testes unitários
• Os Bots também terão testes unitários
• Validação do APP/webapp será online e com formulário para ajudar.

Ao longo do desenvolvimento os pilares: Bots, API e APP serão mostrados aos POs do projeto

Ver anexos em #7

Por quê ser informado sobre as alterações e possuir um layout adaptado para o mobile é importante?

• expressjs
• mocha
• instambul
• jsonwebtoken
• docker compose
• cheerio
• nightmare
• request

Trabalhar +/- em cima disso:

O projeto visa facilitar a visualização de dados do aluno, acompanhar notas e faturas a pagar.
Será criado um aplicativo hibrido para exibir os dados e notificações
Através de uma API e uma camada de Cache, criada por um robô que busca constantemente os dados.

Pág. 8.

• Aquela citação de duas linhas não pode ser assim. Sugiro botar a informação no parágrafo anterior, com as tuas palavras, e citar ali mesmo.

• Algo como “Este processo pode demorar de 10 a 40 segundos (…), o que vai contra estudos que mostram que até 40% dos usuários abandonam um site após o terceiro segundo de espera (Gomez, 2016).”

Pág. 14.

• A figura com dois “Robô” e duas “API” está estranha. Faz mais sentido um robô e uma API.

Pág. 16.

• Ordena os itens do Product backlog a partir das prioridades. Se tu não utiliza os códigos de itens no texto, tira. Se não são utilizados, só atrapalham o texto.

• Mantém as prioridades nos itens de Backlog implementados (e mantém ordenados por prioridade).

• Precisa, para as tabelas do Product Backlog (implementados e não implementados dizer “Tabela X - …” e “Fonte: Autor do Projeto.”

• Insere um texto como “Foi utilizado uma lista com as funcionalidades (Product Backlog), e os itens ainda não implementados estão na Tabela X e os itens já implementados na Tabela Y.”

Pág. 17.

• Mantém as prioridades nos itens de Backlog. (Vale para todas as sprints.)

• No item 7.2.1, e nos outros semelhantes, inclui um texto antes da tabela: “Os itens de backlog implementados nessa sprint são apresentados na Tabela X.”

Pág. 20.

• Como não são “algoritmos”, troca os algoritmos para “Figura”. Tu consegue botar “LyX-Code” dentro de um “float de Figura”.

Pág. 22.

• O Algoritmo 3 está “solto” no texto (não tem nada dizendo “como no Algoritmo 3”). Troca para Figura, como os outros.

• A Modelagem de Dados está vazia…

• Essa tela apresentada é a “modelagem da interface” ou o resultado obtido? Se não teve modelagem de interface, não precisa botar nada.

Pág. 23.

• O Algoritmo 4 está “solto” no texto (não tem nada dizendo “como no Algoritmo 4”). Troca para Figura, como os outros.

• A seção 8 (Funcionamento do Sistema) deve começar em uma nova página.

• Fala qual a linguagem/framework utilizada para os Algoritmo 5 e 6 (esses continuam como Algoritmos!).

• Quando tu cita o Algoritmo 4 (que vai virar figura), como está em outra seção é de “bom tom” dizer a página em que se encontra. Dá pra fazer isso com o “cross-reference” do LyX (ou no pior caso com o LaTeX).

Pág. 25.

• Tira o Algoritmo 7. Está feio e não traz nenhuma informação relevante.

Pág. 26.

• Transforma os algoritmos 8 e 9 em Figuras.

Pág. 27.

• “endpoint” deve ser em itálico. (“Web” também, em todo texto.)

• O formato é YML, e não .yml.

Bibliografia:

• Bota o link do Whitepaper do Gomez num Bit.ly da vida para não ficar daquele tamanho.

• Retirar crase de “à 40 segundos”.
• Introduzir também aspectos de “negócio”, no caso, o acompanhamento acadêmico.

Uma arquitetura distribuída:

• Bots para buscar dados
• Normalizer para normalizar os dados vindos do Portal
• Diff uma camada que consiga diferenciar os dados inputados dos já salvos no banco e avisar que são diferentes, uma nota nova, por exemplo.
• Banco para guardar os dados do normalizer
• API para comunicar banco -> app ou qualquer solução que queiram criar
• App para exibir os dados

1. Ionic Framework
2. ExpressJS
3. ... quase tudo

Título do Projeto

• Especificar que o aplicativo é para acompanhamento acadêmico no Senac.

Apresentação Geral do Projeto

• Não utilizar primeira pessoa. Ex: percamos.
• Retirar crase de “à 40 segundos”.
• Introduzir também aspectos de “negócio”, no caso, o acompanhamento acadêmico.

Validação – Estratégia

• O principal objetivo desta seção é validar se os objetivos propostos foram atendidos.

Cronograma (TCCI e TCCII)

• No cronograma devem constar os itens de desenvolvimento e as entregas do TCC.
• O cronograma deve estar aderente à abordagem de desenvolvimento escolhida, de modo que deve ser visível o que será entregue em cada Sprint.

Bah, aqui fodeu. Pensar certinho e conversar com o professor orientador