Fim do projeto - 30/06/2017

Dia 28/06 marca o fim do projeto St. Locator, onde foi efetuada a entrega da versão final com as correções apontadas na primeira entrega, resultando na aprovação na disciplina de A6PGP. Gostaríamos de agradecer o apoio de todos, em especial aos orientadores do projeto, professores Ivan e Braz e ao Instituto Federal de Educação, Ciência e Tecnologia do estado de São Paulo.

Não deixe de acompanhar a Equipe São Longuinho e o aplicativo St. Locator em seus canais:

YouTube: https://www.youtube.com/channel/UC2UK43p8FGeuTKDGLj3VDKA

Website: https://www.stlocator.com.br

Última Reunião para Acertos - 25/06/2017

A entrega final do trabalho está muito próxima, estamos na reta final, a ansiedade é grande e a expectativa é maior ainda, portanto a equipe está lutando contra o tempo para realizar os últimos ajustes para finalizar o documento. 

A reunião do dia 25/06 provavelmente será a última realizada via Skype antes da entrega final da documentação que será na próxima quarta feira dia 28/06, nesta reunião tivemos como foco principal alinhar as correções feitas por cada integrante da equipe, rever as observações realizadas pelos professores orientadores e pelo professor convidado na documentação da primeira entrega e levantamento de ajustes finais na documentação.

Nesta reunião foram discutidos os seguintes assuntos:

•  Alterações realizadas no Back-end;
•  Referências na documentação final;
•   Diagrama de Caso de Uso;
•   Diagrama de Classe;
•   Métricas do projeto;

Reunião para Acertos - 18/06/2017

A última entrega do trabalho se aproxima e a equipe está acertando as ultimas alterações para finalizar a documentação.

A reunião do dia 18/06 teve como principal foco a discussão das atividades realizadas e atividades a fazer. Vale ressaltar que as modificações levantadas pelos professores orientadores e pelo professor convidado foram divididas entre todos os membros da equipe e cada um ficou responsável pela correção de uma parte.

Nesta reunião foram discutidos os seguintes assuntos:

• Correções já finalizadas
• Alterações nos Casos de Uso
• Finalização da pesquisa de opinião, MER e DER
• Revisão do Diagrama de Classes
• Alterações no Banco de Dados
• Roteiro de Testes
• Correções em Funcionalidades do Sistema
• Renovação do Certificado SSL

Reunião para acertos - 11/06/2017

Com a aproximação da entrega final do projeto, se fez necessário mais uma reunião para acertos de tarefas, e verificar o andamento com todos os membros do grupo de como estavam as correções na documentação e desenvolvimento do projeto.

Os assuntos discutidos na reunião foram:

• Correções

• Caso de uso

• Desenvolvimento

• Diagrama de sequência

• Documentação

• Entrega final

• Plano de testes

Enfim, a Primeira Entrega! - 21/05/2017

A primeira tão temida data chegou: a Primeira Entrega. No dia 24/05 a equipe São Longuinho terá que entregar o documento finalizado para a primeira avaliação dos professores orientadores.

Os últimos ajustes do documento foram realizados no dia 20/05. Foram realizadas alterações na parte do desenvolvimento do projeto e escrita em sua totalidade as considerações finais após toda a execução do trabalho. 

A maior preocupação da equipe agora é a impressão do documento, que está marcada para amanhã (22/05/2017). A equipe optou por utilizar a impressora de um dos integrantes para imprimir o trabalho. Foi realizado um levantamento dos custos que teríamos com a impressão em uma gráfica e com a compra de insumos para realizar a impressão em casa. Após análise dos gastos, optamos imprimir no equipamento de um dos integrantes pois é um equipamento corporativo, de qualidade e com um valor mais em conta. Além disso, teremos total controle sobre a qualidade de impressão.

Hoje, foi realizada também a última reunião antes da Primeira Entrega. A equipe discutiu sobre alguns assuntos ainda pendentes do desenvolvimento, além do vídeo do Gource, e apresentação da documentação final.

Vamos com tudo para esta entrega e para a apresentação do trabalho!

Reunião Semanal - 14/05/2017

Reunião realizada dia 14/05/2017 via Skype, para análise do andamento da documentação, Verificação de algumas mudanças e inclusão de de atributos e tecnologias no sistema.

• Banco de Dados

• Desenvolvimento

• Documentação

• Google Maps

• Plano de teste

• Requisitos

Com a aproximação da primeira entrega do projeto, estão sendo definida a forma de impressão da documentação, implementação de planos de teste do sistema, para verificar se tudo esta funcionado corretamente e se atente aos requisitos definidos pelos interessados no projeto.

A Primeira Entrega se aproxima! - 10/05/2017

Estamos em 10/05 de 2017 e a primeira entrega do trabalho final está cada vez mais perto. A primeira entrega do trabalho é no dia 24/05 e a partir de hoje faltam exatamente duas semanas!

Em visto disso, as reuniões tem sido cada vez mais focadas em apresentar as entregas de cada um durante a semana. Nesta quarta-feira a equipe São Longuinho se juntou a fim de colocar em dia as tarefas da documentação.

Ate o presente momento, os seguintes tópicos já foram abordados finalizados:

• Corpo do Documento - 100%
• Introdução - 100%
• Revisão de Literatura - 100%
• Gerenciamento do Projeto - 100%
• Desenvolvimento do Projeto - 70%
• Conclusão - 0%
• Apêndices - 60%

A equipe considera esta uma evolução boa e irá precisar focar sobretudo na descrição de diagramas técnicos e na parte de desenvolvimento do trabalho. Como previsto, a conclusão será uma das últimas partes a serem elaboradas, uma vez que abrange todo o conteúdo do trabalho.

A data que a equipe se propôs a finalizar a documentação é 17/05 e precisaremos trabalhar bastante para atingi-la!

O Levantamento de Requisitos – 03/05/2017

Para realizar o levantamento de requisitos do sistema, o método utilizado foi a observação e testes de mesa, onde foi realizado a análise do uso de sistemas com processos de cadastro de usuário, login, cadastros de objetos, entre outros aspectos similares ao do projeto em desenvolvimento.

O objetivo deste levantamento se dá pela necessidade de conhecer melhor cada detalhe da nossa aplicação e assim traçar um plano para seu desenvolvimento.

Como esperado, ao realizar esta analise, observamos que cada requisito do nosso sistema possui suas particularidades e relevâncias para o funcionamento da aplicação, sentimos a necessidade de classificá-los, assim conseguimos nos prepara melhor para o plano de desenvolvimento do sistema, essa classificação foi subdividida em “Essencial”, “Importante” e “Dispensável”, onde classificamos os como essencial aqueles requisitos que consideramos fundamentais para o funcionamento da nossa aplicação, os requisitos classificados como importantes são aqueles que fundamentam nosso sistema, porém são menos críticos que os classificados como essenciais, já os dispensáveis são os requisitos que desejamos que o sistema possua para facilitar a utilização e deixar nosso sistema mais robusto.

Reunião para Acertos - 30/04/2017

Na reunião realizada em 30/04/2017, iniciamos falando sobre a parte documental do projeto, e terminamos discutindo sobre o desenvolvimento.

Os temas abordados sobre a documentação, foram a introdução e resumo do projeto, para definição do texto, que iria fazer parte do projeto. Quanto à documentação, foi firmemente batido na tecla da junção do Front-End com o Back-End, e a necessidade que eles tinham de caminhar juntos nesta reta final do projeto.

Definimos, para dar continuidade ao desenvolvimento, a regra de negócio sobre as categorias fixas de pesquisas no projeto, auxiliando o usuário à direcionar bem sua ocorrência, aumentando as chances de sucesso na recuperação.

Para finalizar a reunião, falamos sobre o controle sessões ativas do site, definindo que não faríamos o controle pelo banco de dados, apenas o controle em cache.

Rotas - 22/04/2017

A configuração de rotas trata-se simplesmente de uma técnica para tornar as URLs mais semânticas, além de permitir mais de uma forma de acessa-la, isso ajuda e permite melhor interação com mecanismo de busca que desconsideram caracteres especiais. No Codeigniter, instanciamos um dado controller e acessamos um método, conforme imagens abaixo.

Por exemplo, um link para a página de ocorrências:

View:

<a href="<?php echo site_url('Occurrence') ?>" class="hvr-underline-reveal">Ocorrência</a>  







Controller:

class Categoriacontroller extends CI_Controller

{

 function add()

    { 

        $this->load->library('form_validation');




         $this->form_validation->set_rules('categoria_nome','Categoria Nome','required|max_length[50]');

      

        if($this->form_validation->run())   

        { 

            $params = array(

                'categoria_nome' => $this->input->post('categoria_nome'),

            );

          

            $tb_categoria_id = $this->Categoriamodel->add_tb_categoria($params);

            redirect('categoriacontroller/index');

        }

        else

        {

            $this->load->view('categoriamodel/add');

        }

    } ....

Para site_url('Occurrence') acessar o controller correto é necessário especificar a rota:

arquivo: application/config/routes.php


$route['Occurrence'] = 'CategoriaController/add';

Autenticações com Firebase - 21/04/2017

De acordo com a orientação geral do projeto St. Locator de criar soluções a partir de frameworks e APIs já estabelecidas como forma de agilizar o desenvolvimento, utilizaremos o Firebase para gerenciar as autenticações de usuários. Essa API do Google reúne diversas soluções para o desenvolvimento de aplicações mobile e web, como banco de dados, telemetria, hosting de aplicações, testes automatizados, notificações push, publicidade, e claro, a autenticação. 

Essa solução possui interessantes atrativos como a utilização de redes sociais para realizar o login de usuários, entre as quais temos as opções de contas do Google, Facebook, Twitter e Github, no entanto para nossa aplicação optamos por por não utilizar os dois últimos. Além disso, há a opção de usar e-mail e senha não relacionados à redes sociais, esse processo é plenamente suportado pelo Firebase que disponibiliza cadastro, verificação e alteração de senha, mas caso seja utilizado um e-mail cujo provedor seja conhecido ele passa à associar ambas ao mesmo UID conforme a imagem abaixo:

A integração é muito fácil de ser feita e não exige conhecimento avançado em infraestrutura e programação, pois além de excelentes tutoriais, a forma de configuração em console torna tudo muito simples e intuitivo. Sendo o único ponto que exige mais atenção a interação com o Facebook, que se trata de outro contexto onde é preciso criar um conta de desenvolvedor e configurar permissões para permitir a integração de suas API de login, mas nada muito complexo.

Reunião para acertos - 16/04/2017

Reunião realizada via Skype, para fazer acertos sobre tarefas distribuídas anteriormente para os membros da equipe.

• Revisão de Literatura a respeito dos tópicos de front-end, banco de dados, análise de risco, perdas de itens, homologação e testes.

•  Rotas da aplicação

•  Firebase para autenticação

•  Cronograma;

•  Planejamento do projeto;

•  Ambiente e servidor;

•  Configuração da documentação no Trello.

Com a data da entrega do projeto cada vez mais próximo, foi apresentado o progresso do projeto, referente a documentação e desenvolvimento, através do cronograma.

SSL, certificado e teste Qualys SSL Labs - 10/04/2017

Para a segurança da comunicação do servidor web, é necessário utilizar SSL. O certificado escolhido para nosso servidor foi o certificado da autoridade Let's Encrypt, que provê certificados gratuítos para utilização em websites, validando sua segurança. A Let's Encrypt emite certificados válidos por 90 dias, e a autoridade encoraja a automatização do processo de renovação através do seu cliente de instalação e renovação, o certbot.

Implantamos o certificado do Let's Encrypt em nosso servidor Apache, e realizamos testes com a ferramenta da Qualys SSL Labs, a SSL Server Test. Em um primeiro momento, após a implantação, nosso servidor (já configurado e certificado) recebeu nota A (a mínima que o projeto exige para aprovação). Em aula, foi sugerido pelo Prof. Ivan a obtenção da nota A+ (nota máxima do SSL Server Test), onde tivemos que pesquisar e entender o funcionamento do mecanismo de segurança HSTS (HTTP Strict Transport Security), que permite a comunicação estritamente via HTTPS com nosso servidor,  necessário para obtenção da maior nota possível no teste.

Após a implementação do HSTS, obtivemos a nota máxima no Qualys SSL Server Test.

Aula - 05/04/2017

Foi realizado em aula por todos os membros do grupo o teste no banco de dados.

Foi distribuído tarefas referentes a REVISÃO DA LITERATURA, entrega agendada para 12/04/2017.

• Perdas de itens e homologação (Edicrede)

• Concorrência, gerenciamento de projeto e análise de requisitos (Bruno)

• Uml (Leandro)
• Bancos de dados (Matheus)
• Front – End e infraestrutura (Gustavo)

• Back – End (Aleson)

Reunião para acertos - 02/04/2017

No dia 02/04, a equipe São Longuinho se reuniu via Skype, para verificar a entrega de tarefas definidas anteriormente e definir a divisão das próximas etapas.

Entregas:

Banco de Dados

Análise de Risco

Demonstração do combo box

Escopo do Documento

Próximas tarefas:

• Manual do Usuário
• Revisão da Análise de Risco
• Teste do Banco de Dados
• Organizar projeto no Trello

Foram entregues tarefas pré de finadas, que serão revisadas pelos membros do grupo durante a semana, incluindo o teste no banco de dados, que será feito na quarta feira (05/04/2017) durante a aula. Foram elencadas tarefas a cada membro do grupo para próxima semana.

As URL's - 02/04/2017

A correta utilização de uma API REST do lado do cliente está em grande parte em entender o mecanismo da URL do servidor. Podemos começar com um simples exemplo:

 

O example_api é como mostrado acima um controlador (MVC) , podendo ser user, products, customers, etc. O users se trata de um recurso de uma base de dados, por exemplo, esse recurso interage com os verbos HTTP: GET, PUT, DELETE, POST, etc., para realizar as operações de CRUD: create, read, update e delete. Na atual versão do REST server utilizado o JSON é o padrão, dado sua popularidade e mais notável diferença para o xml que é sua menor verbosidade, mas permite como dito em uma postagem anterior, XML, HTML e CSV, para tanto é necessário requisitar um formato através da URL, como o exemplo a seguir:

Onde format aceita xml, json, html, csv, conforme mostra a página de exemplos codeigniter-restserver:

Ao permitir essa variada forma de se interagir com a API estamos aumentando as possibilidades para eventuais usos de aplicações lado do cliente independentemente da linguagem de programação utilizada, estes poderão escolher a melhor forma de se tratar as informações consumidas.

fonte: https://code.tutsplus.com/tutorials/working-with-restful-services-in-codeigniter--net-8814

REST API - 31/03/2017

O sistema StLocator tem a proposta de oferecer seus serviços em forma  de API, supondo um eventual crescimento da aplicação e ou integração com outros sistemas que estendam e ou agreguem de alguma forma à solução para restituição de bens perdidos, portanto o nosso servidor utilizará o modelo de arquitetura REST.

Transferência de Estado Representacional, em inglês, Representation State Transfer, ou REST, é um termo datado de 2000 na tese de doutorado de Roy Fielding, um dos principais autores das especificações do protocolo HTTP e co-fundador do projeto Apache Web Server. A própria rede mundial de computadores é um exemplo de aplicação funcionando em REST. Essa tecnologia aproveita o protocolo mais utilizado e seus métodos para realizar transações stateless. Também conhecidos como HTTP verbs, pode-se citar entre os mais comuns: GET, POST, PUT, DELETE.  O paradigma “sem estado” dessas transações de requisição entre cliente e  servidor torna cada um delas únicas, poupando o lado do cliente de tratar comunicação com banco de dados, logs, cache, etc., e da mesma forma o lado servidor não lida com interface, experiência de usuário, logo tal divisão permite liberdade de evolução distinta para os ambientes. A partir desse princípio o modelo de serviço converge com o estrutural da aplicação, que a princípio considerou-se tratar de um MVC, quando na prática acaba se tornando um MVW, Model View Whatever,  o tanto faz é uma bem humorada definição sugerida pela equipe do Angular JS que significa utilizar  o que for mais adequado para aplicação, seja MVC, MVVM ou o MVP. Neste momento utilizaremos o MVC, contudo outras abordagens poderão ser analisadas durante o desenvolvimento.

Nosso servidor REST terá diversos tipos de respostas de acordo com as  requisições clientes, pois disponibilizaremos respostas em JSON, XML, HTML e CSV, o que permite uma integração com aplicações Web e Mobile.

Framework PHP - 29/03/2017

O desenvolvimento de um sistema de forma “from scratch”, ou seja do zero, é custosa e requer muita experiência do desenvolvedor e domínio da tecnologia empregada para uma conclusão bem sucedida. Esse é o motivo para a popularidade do uso de frameworks, toolkits, engines, etc., que tornam o processo de construção de um sistema drasticamente mais fácil, por exemplo, em desenvolvimento de jogos, onde há uma enorme gama de ferramentas facilitadoras utilizadas tanto por amadores quanto pela indústria digital. A partir dessa premissa a equipe São Longuinho, optou por utilizar uma framework para a criação do lado servidor da aplicação, à tal escolha pesou dois pontos fundamentais que são a facilidade de uso e ou aprendizado e poder da ferramenta, para tanto foram avaliados diversas frameworks e chegou-se ao Cakephp e CodeIgniter, ambas as duas mais populares e gratuitas. Tal popularidade é resultado do poder de ambas, que são muito bem documentadas, contêm bibliotecas repletas de funcionalidades e facilidades, mas o ponto de desempate foi a facilidade de manipulação e adaptação aos interesses do nosso servidor como descrito no escopo do projeto, uma API Rest. 

A framework escolhida foi o CodeIgniter cuja arquitetura é a MVC (Utilizaremos o MVW, mas trataremos desse tema na próxima postagem), que será utilizado junto com o CRUDgniter para uma implementação do tipo database first e uma extensão para o REST server. Essa decisão nos exonera da árdua tarefa de construir funcionalidades complexas, como as relacionadas à segurança de acesso à diretórios, roteamento, arquivos de configurações, etc., portanto permite que a equipe tenha foco principal em desenvolver o negócio da aplicação.

PHP - POO - 21/03/2017

A linguagem escolhida para o back-end da aplicação é o PHP (PHP Hypertext Preprocessor), uma linguagem de programação interpretada escolhida pelos seguintes atrativos: ser a mais utilizada no lado servidor, por ser de código aberto, de fácil aprendizado, multi-plataforma, de baixo custo de manutenção e consumo, e principalmente por suportar o paradigma de orientação à objetos. A arquitetura do sistema seguirá o MVC (model, view, controller), implementando classes de ORM (Object Relational Model) na camada mais importante a Model, através de desgin patterns como Factory, Composite e Repository e técnicas de programação PDO (PHP data object) para acesso padrão aos diversos bancos de dados relacionais suportados por essa linguagem, de forma a tornar a aplicação o mais flexível possível, por exemplo, usaremos o banco PostgreSQL, mas através de um arquivos .ini é possível mudar para qualquer outro, como o sqlite, mysql, oracle, etc. A versão utilizada será a 7.0, tomando como material principal de referência o livro php Programando Orientado a Objetos do graduado analista e mestre em engenharia de software Pablo Dall’Oglio.

    O servidor funcionará como uma API, permitindo que seja usada por fontes externas através de REST, portanto em comandos de HTTP semântico, como GET, PUT, DELETE, UPDATE, etc, retornando objetos JSON (JavaScript Object Notation) menos verbosos que o XML, seguindo uma tendência tecnológica para aplicações em microservices, o que facilita a integração com outros sistemas.

Reunião Sobre Ressalvas - 12/03/2017

Na aula para orientação, do dia 08/03, demonstramos para o professor os requisitos funcionais e não funcionais do sistema, o que gerou ressalvas do professor Ivan, e as ressalvas foram nossos principais assuntos na reunião semanal do dia 12/03, feita via Skype.

Com as ressalvas, definimos que teríamos que alterar o MER e o DER que já estavam prontos, com as principais mudanças de:

• Flag de controle para saber quais são as ocorrências que irão passar na próxima verificação, para evitar várias leituras simultâneas na tabela.
• Tabela de log de alteração para manter histórico das ocorrências, mantendo trilha das alterações realizadas pelo usuário.

Além das alterações no modelo e diagrama, alteramos a ideia de excluir dados antigos de ocorrências já correspondidas e criaremos uma tabela de histórico, visando a performance para análises de correspondências das ocorrências.

Definimos na reunião que utilizaríamos SHA_2 para o armazenamento das senhas dos usuários que optarem por criação da conta diretamente no site e para as empresas que se interessarem pelo serviço.

Os próximos passos, deixamos para fechar 100% o MER e o DER, para iniciarmos a implantação e fase de testes do modelo, além de definir as demais análises, fechando os assuntos até o final do mês, para o início do desenvolvimento e estruturação do documento.

Desenvolvimento da Análise - 06/03/2017

No dia 06/03/2017 a equipe São Longuinho se reuniu no Shopping D a fim de conversar sobre o Sprint definido no dia 01/03/2017. A ideia era basicamente ver a evolução de cada uma das tarefas elencadas, bem como dificuldades e viabilidades para melhor execução.

Os principais pontos abordados foram: 

• Demonstração do ambiente previamente preparado
• Modelo Entidade-Relacionamento
• Diagrama Entidade-Relacionamento
• Casos de Uso
• Diagrama de Caso de Uso
• Requisitos Funcionais
• Requisitos Não Funcionais

Todas as tarefas elencadas para o Sprint desta semana fluíram bem, sem atrasos. A maior dificuldade se deu na construção do MER e do DER, uma vez que a equipe não estava conseguindo abstrair todos os conceitos dos requisitos funcionais e não funcionais. Mesmo assim, a ideia é chegar na aula de quarta-feira (08/03/2017) com estes pontos definidos, para que os professores possam nos orientar.

Preparação do ambiente Amazon AWS - 03/03/2017

A fim de entender e estudar a arquitetura dos serviços da Amazon, esse fim de semana corremos atrás de estudar as configurações necessárias para que o sistema funcione perfeitamente. 

Conseguimos configurar uma máquina virtual Linux com o EC2, conectar via SSH utilizando o cliente PuTTY no Windows e realizar a instalação dos pacotes que iremos precisar para a utilização do sistema (Servidor web, PHP e PostgreSQL+Postgis). Com bastante leitura da documentação da Amazon AWS (disponível em https://aws.amazon.com/documentation/), conseguimos utilizar o Amazon Route 53 (serviço de DNS da Amazon) e direcionar nosso domínio (http://stlocator.com.br). 

Optamos por entender a infraestrutura do nosso ambiente para evitar problemas ao final do projeto (dica dada por alunos de semestres anteriores da disciplina), tendo assim, uma experiência fluída e tranquila ao disponibilizar nossa aplicação. 

Boa semana a todos, e não esqueça de acompanhar também a equipe São Longuinho no YouTube (o primeiro vídeo já foi enviado!).

Reunião para acertos - 25/02/2017

No dia 25/02, a equipe São Longuinho se reuniu no Starbucks da Avenida Paulista - Consolação a fim de discutir alguns assuntos definidos previamente. O foco principal da reunião era debater sobre as ressalvas e orientações dos professores após a nossa primeira apresentação para estes e para os colegas de sala de aula.

A reunião foi muito produtiva e conseguimos sair de lá com definições que foram além da pauta da reunião.

Primeiramente discutimos os pontos levantados pelo professores após a apresentação inicial do projeto. A primeira ressalva foi com relação à internacionalização do aplicativo: nós aceitamos a sugestão dos professores, de criar um aplicativo pensando em sua utilização global. Para isso, utilizaremos os padrões do i18n. Em seguida, discutimos sobre a possibilidade da utilização de um servidor AWS RDS junto com um servidor AWS EC2. A princípio esta será a infra estrutura do sistema. Posteriormente, falamos ainda da figura de um administrador do sistema, algo que não estava em nossos planos inicialmente. Este foi um ponto muito importante levantado pelos professores e decidimos que iremos criar esta entidade para administrar alguns parâmetros do sistema.

Partimos então para a definição do nome do sistema. De início, ele iria se chamar São Longuinho. Contudo, após a sugestão de internacionalização, pensamos em criar um nome que fosse facil de se pronunciar e que pudesse ser usado em qualquer lugar do mundo. A escolha foi: Saint Locator, ou em abreviação, St.Locator. Dessa forma, podemos manter a ideia de um "Santo Localizador" que poderá ser usado em qualquer lugar do globo. Logo após a definição do nome do projeto, registramos o domínio "stlocator.com.br".

Começamos a discutir os casos de uso do sistema e esboçar o diagrama de casos de uso. Em paralelo, iniciamos a descrição também dos requisitos funcionais e não funcionais.

O último assunto abordado na reunião foi o Sprint para a próxima semana.

A reunião foi muito produtiva e a equipe São Longuinho irá continuar nesta tocada, até o fim do projeto.

O próximo passo agora é seguir à risca o Sprint discutido e entregar tudo que combinamos neste reunião.

Enfim a apresentação! - 22/02/2017

Chegou o dia da primeira apresentação do nosso projeto de A6PGP! Neste dia, todos os grupos deveriam apresentar ao professores e aos colegas as suas ideias, bem como suas definições, tecnologias e metodologias a serem utilizadas.

Por meio de sorteio, a equipe São Longuinho foi selecionada como a quinta equipe a se apresentar. Contudo, devido a alguns problemas ocorridos com outras equipes, acabamos sendo o terceiro projeto a ser apresentado.

Ao final da apresentação, os professores Braz e Ivan fizeram questionamentos com relação à algumas escolhas que tivemos para desenvolver o projeto, além de dar algumas dicas que facilitariam o escalonamento da nossa aplicação no futuro. 

Um ponto levantado por ambos os professores foi o nome da nossa aplicação. Até então, tínhamos escolhido como nome para o aplicativo o mesmo nome da equipe: São Longuinho. Contudo, devido às intenções de internacionalização, talvez esse não fosse o nome mais adequado, uma vez que há lugares em que este Santo não existe. Sendo assim, fomos para a casa com a tarefa de escolher um nome que pudesse ser utilizado em qualquer lugar do mundo. 

Fomos questionados também quanto à utilização de um banco de dados geoespacial para armazenar os dados de localização dos objetos. Neste caso, o professor Ivan nos indicou a utilização desta tecnologia e, após algumas pesquisas, pudemos constatar que este tipo de banco de dados facilita a manipulação de dados geoespaciais e isso será essencial para o funcionamento do nosso aplicativo. Além disso, foram citadas também a utilização de padrões de internacionalização como o i18n, por exemplo e a utilização do Amazon RDS.

Anotadas todas as críticas e sugestões, agora a equipe São Longuinho tem como tarefa ponderar cada um dos pontos levantados e solucionar os problemas apresentados. 

Na próxima quarta-feira (01/03/2017) não teremos aula de A6PGP, o que não significa que não haverá trabalho. Muito pelo contrário: utilizaremos a parada do Carnaval para acelerar! Os próximos passos agora são, além da solução dos problemas levantados na apresentação, o desenvolvimento de parte da análise do projeto além da estruturação das entidades e modelos para o banco de dados da aplicação. 

Não vemos a hora de começar a desenvolver esta belezinha! 

Documentação, apresentação e logotipo - 18/02/2017

Após definido e aprovado o escopo do projeto, a equipe São Longuinho começou a trabalhar em cima desta ideia. Nos reunimos via Skype no dia 18/02/2017 para definirmos os pontos principais da aplicação. São eles:

• Objetivo
• Problema
• Proposta
• Escopo
• Metodologias (Gerenciamento e Desenvolvimento)
• Tecnologias e Ferramentas

Finalizada a formalização da proposta, começamos a esboçar o logotipo do sistema. A ideia era que ele pudesse unir elementos que remetessem à localização e ao santo ajudador de objetos perdidos, mais conhecido como São Longuinho.

E então, após alguns bons rabiscos e muitas edições de imagem, chegamos ao produto final: o logotipo do aplicativo da equipe São Longuinho!

Proposição de ideias aos professores - 15/02/2017

Na noite de 15/02/2017, tivemos a segunda aula de Prática de Gerenciamento de Projetos. A proposta desta aula era de apresentar ideias para o desenvolvimento do projeto aos professores ‎Ivan Francolin Martinez‎ e José Braz de Araujo.

A equipe, que já havia sido formada na última aula (08/02/2017), esteve durante toda a semana focada em pensar em aplicações que solucionassem problemas do cotidiano. Ao todo, foram 8 contribuições, das quais 5 foram eleitas relevantes e adequadas à disciplina.

Antes de apresentá-las, realizamos uma breve reunião em sala de aula para selecionar as 3 melhores ideias propostas durante a semana.

Primeiramente apresentamos as três ideias ao professor Ivan. De primeira uma delas já foi descartada, restando ainda outras duas a serem consideradas, por mais que ainda houvesse muitas dúvidas com relação ao funcionamento e tecnologias. Em seguida, apresentamos as três ideias ao professor Braz. Mais uma vez, tivemos uma das ideias deixada de lado, restando as outras mesmas aplicações sugeridas pelo professor Ivan. Os dois professores fizeram questionamentos com relação às propostas apresentadas e solicitaram que resolvêssemos estes problemas para decidirmos qual seria a aplicação a ser desenvolvida durante todo o semestre.

Após discutirmos sobre os questionamentos dos professores chegamos a conclusão de qual seria a nossa ideia principal. Então, nos reunimos novamente (dessa vez com os professor Ivan e Braz juntos) e apresentamos possíveis soluções para seus questionamentos. A surpresa veio: o primeiro grupo com o escopo aprovado.

A ideia do projeto é criar uma aplicação que facilite a recuperação de objetos perdidos, com chat em tempo real, notificações por e-mail, utilização de geolocalização, etc. O sistema irá colocar em contato a pessoa que perdeu e a pessoa que achou o objeto, tornando a recuperação deste mais fácil e mais ágil. Todo o processo será feito de forma anônima e ficará a critério dos usuários expor os seus dados e outros meios de contato.

Sendo assim, da forma mais sugestiva possível, não podíamos criar nome melhor para a equipe: São Longuinho.

O próximo passo agora é documentar o escopo do projeto e as tecnologias a serem utilizadas. Devemos formalizar isto em um documento e criar uma apresentação com este tópico. Apresentaremos oficialmente a ideia aos professores e toda a turma, a fim de recebermos críticas e sugestões para o bom funcionamento da aplicação.