Trigésima Sétima Semana - Quarto Bimestre Não É Folga

Terça-feira passada apresentamos nossas alterações desde a apresentação do 3° bimestre. Não conseguimos atingir as expectativas de nosso orientador, já que produzimos menos do que poderíamos. Os erros na documentação apontados pelos professores que avaliaram nosso trabalho no 3° bimestre permaneceram na documentação entregue no 4°. Isso se deve a uma certa falta de comprometimento da equipe com o projeto durante esse último bimestre, o que também foi agravado por termos diversas coisas acontecendo ao mesmo tempo (fechamento de notas, vestibulares etc). Agora é correr atrás do prejuízo, tentando fechar o sistema até o final das aulas.

Trigésima Sexta Semana - Progressos em Correções

Nessa semana, como havíamos planejado, demos foco ao desenvolvimento das funcionalidades restante como, por exemplo, os filtros de animais e a mudança da senha da ONG ao acessar o sistema pela primeira vez. Também finalizamos de revisar os erros gramaticais da documentação.

De: Gabriel Renato

Trigésima Quinta Semana - Mudar Faz Bem

Durante nossa última retrospectiva chegamos junto a conclusão que nosso problema de produtividade se agravou ultimamente por não estarmos mais seguindo a metodologia que nos propusermos a seguir, ainda mais com nosso Scrum Master sem trabalhar para tentar ajudar a equipe a entrar nos eixos. A partir dessa conclusão, nos comprometemos a organizar nossa forma de trabalho, cumprindo com nossas cerimônias. Para efetivar a mudança, o membro Renata Souza se candidatou a ocupar a posição de Scrum Master, no lugar do Gabriel Renato.
A equipe começou a ter foco nas  funcionalidades que estão faltando no sistema (além dos erros presentes na documentação) dando início ao filtro de animais, um dos requisitos da aplicação, para a apresentação final que será feita no dia 14 ou 21 de novembro.

De: Nicolas Caous

Trigésima Quarta Semana - Correções e Correções

Nesta semana a equipe continuou a progredir nas correções com tarefas de desenvolvimento, como a de manter a tela de cadastro e edição de ONGs iguais e com as de documentação a serem feitas na Sprint desta semana. Uma discussão teria sido feita esta semana durante as cerimônias sobre a priorização de tarefas, porém esta discussão não foi concretizado por conta de alguns integrantes que tiveram imprevistos no dia. As pesquisas planejadas para esta semana ainda estão sendo feitas para que as implementações dos filtros sejam corretas e para que esses novos conhecimentos sejam passados possivelmente pelo blog futuramente.

De: Enzo Morales

Trigésima Terceira Semana - Corrigindo os Infinitos Erros

Essa semana a equipe continuou a corrigir os inacabáveis erros do projeto. Nós percebemos que precisamos rever nossa priorização das tarefas, já que do jeito que está, corremos o risco de não conseguir desenvolver as funcionalidades indispensáveis que ainda faltam no projeto, já que estamos focando apenas nos erros. Por conta disso, essa semana iniciaremos um estudo para implementar os filtros na listagem de animais, aproveitando para refatorar o endpoint de animais, mesclando-o com o feed e reorganizando para que ele se adeque ao REST.

De: Renata Souza

Trigésima Segunda Semana - Começando a Corrigir de Fato os Erros

Essa semana terminamos de elencar todos os erros apontados pelos professores tanto na revisão da documentação quando durante a apresentação. Com todos eles listados, agora iniciamos a debater nossa estratégia para corrigir todos eles durante o tempo que nos resta. Decidimos atacar tanto os erros de documentação, quanto os erros no sistema antes de iniciar o desenvolvimento das funcionalidades que ficaram faltando.

Uma coisa que percebemos nas últimas semanas é a importância de anotar todas os erros que os professores nos apontarem, assim como as orientações dadas por eles. Dessa forma foi muito mais fácil para nós organizarmos nossas tarefas, já que foi simplesmente um trabalho passar para o Trello aquilo que já tínhamos registrado. Além disso, assim garantimos que quase tudo que os professores pediram está em nossa lista de afazeres, o que não deixa passar nada que tem que ser corrigido.

De: Isabelle Neves

Trigésima Primeira Semana - A Semana das Correções

Nesta semana, a equipe escreveu todas as análises das outras equipes pondo cada uma no repositório, faltando apenas um resumo de todas a apresentações para ser concluído.  Durante esta semana, a equipe se reuniu com os orientadores para discutir sobre o andamento do projeto e sobre pontos que não foram citados durante a banca, sendo esses pontos detalhes que a equipe deixou passar com a documentação e o desenvolvimento, como validação de CNPJ no site do administrador e o nome do curso na capa. Para estes detalhes pendentes, a gerente da equipe criou um novo quadro no Trello para as correções desses erros que será utilizado nas próximas cerimônias de Planning.

Quadro de correções que devem ser feitas no 4º bimestre

De: Julia Fernandes

Trigésima Semana - A Resposta do Julgamento

Na semana retrasada a equipe afirmou que não teriam mais faltas com o blog, porém infelizmente esse compromisso não foi realizado devido ao desencontro de todos da equipe durante o feriado prolongado que coincidiu com o dia da escrita da postagem, que é realizado com todos juntos e a preparação com a apresentação que não se era de conhecimento se seria na semana seguinte ao feriado ou a próxima. 
Na semana passada, a equipe toda se preparou para apresentação do 3º bimestre criando os slides com base em que os professores apontaram nas primeiras apresentações do ano e neste bimestre para que os mesmos erros não fossem cometidos durante a apresentação (Como a projeção do projeto no mobile, padronização de slides), complementando algumas faltas do sistema e otimizando para um melhor desempenho.
Para poder projetar a tela do celular, a equipe tinham 3 opções de softwares que são recomendados pelo site do Ivan. o AirDroid, Vysor e o TeamViewer, todos precisando de conta para ser utilizado. O software utilizado pela equipe foi o TeamViewer pelo computador e o para o celular o TeamViewer Host, que permite que o celular que seja utilizado remotamente.  Mesmo conseguindo projetar a tela do celular, o time teve problemas com latência tendo um tempo de resposta longo. Para as próximas apresentações, o professor Ivan recomendou o uso do AirDroid para realizar as projeções para que problemas de queda de conexão ou de latência fossem evitados.
Na apresentação, os professores criticaram alguns pontos da documentação em questão de estrutura como a disposição dos capítulos e como alguns conteúdos foram escritos, tendo erros gramaticais e de conteúdo, sendo a forma de como alguns dos quadros foram feitos por exemplo. Para a aplicação, os professores que nos orientaram nos parabenizaram pelo trabalho feito mesmo com todo o atraso do time apontando apenas a falta do UTF-8 na aplicação e de certos recursos para o sistema que se fazem necessários, como o envio da página do animal com os dados para quando a organização que receber a notificação de um animal cadastrado.
Nesta semana, depois da apresentação, a equipe esta escrevendo a análise da apresentação de outras equipes, separando a equipe para dois integrantes uma equipe. Com data de entrega para a próxima aula. Além de começarmos a consertar e observar os erros apontados pelos professores em questão de documentação.

De: Nicolas Caous

Vigésima Nona Semana -Três Dias pro Juízo Final.

Nesta terça-feira entregamos a primeira versão da documentação, e por conta disso (já que ficamos focados em terminá-la), acabamos não fazendo a nossa publicação da semana passada, sendo essa a primeira vez que deixamos de fazer a publicação semanal. Como recomendação para qualquer trabalho que deve ser realizado, iremos ressaltar. Nunca. Nunca. Eu repito: Nunca! Deixe as coisas para fazer de última hora, você não terá tempo de verificar se o que foi feito está correto e decente. Um exemplo disso foi o que aconteceu com os nossos manuais, pois não sabemos como eles deviam ser feitos, portanto, não temos certeza se a maneira com a qual os desenvolvemos está correta.

Na próxima semana começarão as apresentações dos projetos, sendo a ordem de apresentação decidida por meio de um sorteio feito pelos professores. Neste domingo receberemos as informações referentes a esse sorteio, por garantia nossa equipe já está se preparando para se apresentar.

De: Gabriel Renato

Vigésima Oitava Semana - Cada Vez Mais Próximos do Juízo Final.

Nessa semana verificamos o que faltava colocar de conteúdo obrigatório na nossa documentação, como o desenvolvimento dos Manuais Técnico e do Usuário, o relatório do StatSVN, a documentação da nossa Pesquisa de Mercado, o capitulo de Escolhas, além do nosso cronograma atual para que possamos explicar o atraso no desenvolvimento do projeto. Tentaremos completar a documentação até a data de entrega, que será no dia 29/08.

Ainda estamos tendo problemas com a inclusão do novo membro da equipe no desenvolvimento do projeto, já que ele não tem experiência com o Android Studio, além de não conhecer direito o funcionamento do nosso sistema.    

De: Enzo Morales                  

Vigésima Sétima Semana - O Fim Está Próximo

As atividades da semana resumiram-se à refatoração do modelo do banco de dados para se adequar ao que foi planejado. Como o novo membro do time não conhecia o Android Studio, algumas tarefas de layout foram utilizadas para introduzi-lo na ferramenta e com isso praticamente todas as telas estão prontas, faltando apenas adicionar os filtros nas telas de listagem, já que estamos com dificuldade para utilizar o componente FilterDialog. Quanto a documentação, percebemos que o formato de fundamentação bibliográfica de nossa monografia estava incorreto (estávamos apenas citando autores durante todo o texto, não tendo o capítulo de revisão de literatura) e iniciamos o trabalho de adequá-lo.

De: Renata Souza

Vigésima Sexta Semana - Volta das aulas turbulenta.

Na primeira aula de PDS desse bimestre foi decidido em uma reunião entre os gerentes que seria necessário a demissão de um membro de cada equipe. A equipe se reuniu e, por meio de uma votação, decidiu que o membro que seria demitido seria o Giovanni Henrique, sendo contratado para ocupar seu lugar Enzo Leitão, ex-membro da equipe MÁQUINAS.

De: Nicolas Caous

Vigésima Quinta Semana - Volta das Férias

Essa semana as aulas voltaram e com isso, se foi o tempo extra que tínhamos para dedicarmos ao projeto. Porém conseguimos finalizar os endpoints que manipulam os usuários, sejam eles usuários representante de ONG, usuários adotantes ou usuários administradores. Continuamos as correções da documentação. Finalizamos o layout do site e estamos caminhando para a finalização do layout do aplicativo.

De: Julia Fernandes

Vigésima Quarta Semana - Avanços Concretos

Finalmente temos algo concreto no aplicativo: o login está 100% funcional. Agora com a estrutura de comunicação com a API montada, os próximos passos serão menos turbulentos que os últimos meses. Os próximos passos são o cadastro de usuário e a listagem de animais, que estão para serem entregues essa semana, se tudo ser certo.

O layout do site administrativo (por onde serão cadastradas as ONGs) está praticamente pronto. Com ajuda do Bootstrap, conseguimos deixar o layout responsivo e funcional. O menu do sistema no Mobile foi reconstruído tendo um novo layout e uma nova forma de construção em sua atividade (activity) em que o menu é iniciado e desenhado tendo como valores os IDs dos layouts respectivos e a escrita dos dados em métodos distintos sem o uso do método setDrawerListener. Com a nova codificação para o menu o método descontinuado, a equipe não terá problemas com alguma falta de suporte nas futuras atualizações do Android Studio.

Continuando com a revisão da documentação das tecnologias utilizadas pela equipe, o time acrescentou o Gradle, e pretendemos escrever sobre o Maven também.

De: Gabriel Renato

Vigésima Terceira Semana - Recomeçando o Aplicativo

Com o fim da Sprint da semana passada, os integrantes da equipe repararam que houve uma maior produtividade usando os horários fixos de trabalho no projeto para a semana, porém esta produtividade ainda não é o suficiente para recuperar o atraso.

Mudanças no menu tiveram que ter sido feitas por conta da descontinuação do método setDrawerListener que estava sendo utilizado na construção da tela. O problema que a equipe teve com a captação de imagens, que ficavam pixeladas ou não eram desenhadas, foi resolvido nesta semana tendo como resolução não atribui-la diretamente a um bitmap, mas sim a uma variável Uri para que então seja feita a conversão para evitar a perda de qualidade.

No decorrer dos últimos dias, a equipe percebeu a necessidade de atualizar nosso banco de dados (e seus diagramas) por conta de mudanças que ocorreram desde o planejamento da implementação do aplicativo. Além disso, grande parte do que foi implementado no aplicativo começou a sofrer mudanças para se adaptar ao novo funcionamento da API, que precisou ser modificada para se adequar à arquitetura RESTful. Após revisar o sistema, foi averiguado que a modelagem atual do sistema não cumpria os requisitos de segurança, ou seja, haviam muitas brechas de segurança que a criptografia implementada e a modelagem implementada não asseguravam. O sistema, então, foi remodelado, descartando a criptografia, já que, na nova modelagem, ela não é mais necessária.

A grande brecha de segurança foi a desconsideração de que todo o código disponibilizado no aplicativo pode ser descompilado e visualizado, sendo assim, a criptografia não fazia efeito algum para a segurança do sistema. Outros problemas envolviam escolhas errôneas na modelagem do sistema, como por exemplo, não associar o token a um usuário, permitindo que um mesmo token possa acessar os recursos do sistema inteiro, inclusive os recursos de todos os outros usuários. Outra escolha errada para o desenvolvimento da API foi a criação de status próprios do sistema, sendo que isso acaba fazendo com que a API deixe de ser da arquitetura REST, além de vários outros erros que distanciavam o sistema cada vez mais da arquitetura base almejada. Em uma arquitetura REST, os status do próprio HTTP devem ser respeitados e utilizados, assim como os vários padrões de criação dos requests HTTP, como por exemplo, utilizar-se dos métodos corretos para os pedidos, utilizar-se dos headers corretos para a autenticação etc.

Após revisar o capitulo “Tecnologias e ferramentas”, percebemos que não foram documentadas as ferramentas que estão sendo utilizadas para a comunicação entre a equipe, os professores e representantes de ONGs, além disso, a introdução para as ferramentas de desenvolvimento estava confusa, por isso foram refeitas.

De: Isabelle Neves

Vigésima Segunda Semana - Começo das Férias

A cada Sprint definimos uma pontuação baseada na quantidade de atividades pedidas por outras matérias para evitar uma sobrecarga de tarefas durante a semana, assim em semanas de provas a pontuação tende a ser menor do que em semanas de início de bimestre, por exemplo. Porém, mesmo com este método de pontuação a equipe tem falhado ao cumprir com as Sprints tendo completado poucas durante o semestre por conta da falta de compromisso dos integrantes. Percebemos que mesmo tendo uma metodologia eficiente, os integrantes precisam ser cobrados constantemente para que concluam suas tarefas durante as Sprints e que tarefas mais complexas demandam integrantes que trabalhem em harmonia, ou seja, não possuem ideias ou raciocínios distintos para atingir um mesmo objetivo, resultando em uma produtividade maior. Como entramos de férias essa semana, a pontuação das Sprints serão maiores. Por conta disso, todos os integrantes do time definiram horários fixos para trabalhar no projeto todos os dias, dedicando mais tempo durante os fins de semana visando um aumento de produtividade e recuperar as metas não alcançadas nos últimos meses.
Como resposta ao e-mail enviado semana passada, o professor explicou que as publicações devem conter além do resumo semanal, contemplar técnicas importantes que desenvolvemos no decorrer da semana, lembrando que pode haver mais de uma publicação por semana. Seguindo esta orientação, iremos apresentar a construção de uma classe que gerência as permissões necessárias de uma aplicação mobile (Android).
Construindo a classe:
Para construir a classe de permissões, criaremos um método que dado como parâmetros um activity, um requestCode e uma listagem com as permissões verifica se as permissões passadas já estão autorizadas e caso não estejam, solicita através de um "pop up" a permissão. A seguir, o código da classe de permissões:

public class PermissionUtils {

    //Solicita as permissões
    public static boolean validate(Activity activity, int requestCode, String... permissions) {
        List<String> list = new ArrayList<String>();
        for (String permission : permissions) {
            // Valida permissões
            boolean ok = ContextCompat.checkSelfPermission(activity, permission) == PackageManager.PERMISSION_GRANTED;
            if (! ok ) {
                list.add(permission);
            }
        }
        if (list.isEmpty()) {
            // Tudo ok, retorna true
            return true;
        }

        // Lista de permissões que falta acesso.
        String[] newPermissions = new String[list.size()];
        list.toArray(newPermissions);

        // Solicita permissões
        ActivityCompat.requestPermissions(activity, newPermissions, 1);

        return false;
    }
}

Para chamar esta classe, em sua activity inicial (Activity da primeira tela que é exibida na aplicação) basta colocar o código abaixo dentro do OnCreate.

String[] permissoes = new String[] {
    Manifest.permission.PERMISSAO_QUE_VOCE_QUER_1,
    Manifest.permission.PERMISSAO_QUE_VOCE_QUER_2,
    Manifest.permission.PERMISSAO_QUE_VOCE_QUER_3,
}

Todas as Strings de permissão do Android
De: Giovanni Henrique

Vigésima Primeira Semana - Nosso Erro

Em nossa última aula de PDS, os professores orientadores nos chamaram a atenção quanto ao modelo de postagem que estamos seguindo. Apesar da conversa, continuamos com dúvidas a respeito disso, já que o modelo sugerido (ou o que entendemos dele) consiste em publicações a respeito de experiências passadas pelo time na semana, com o intuito de ajudar outros times que podem passar pelas mesmas coisas, mas o que entendemos da bíblia (dicas.ivan) consiste em relatórios semanais resumidos do progresso das atividades do grupo. Como estamos de férias a partir dessa semana, mandamos um e-mail com o intuito de tirar essa dúvida (enquanto isso vamos continuar errando).
Voltando à nossa programação, durante a semana refatoramos nosso código da documentação no LaTeX, separando os capítulos em arquivos diferentes, para facilitar a navegação. Também pesquisamos sobre análise estática, para que possamos prosseguir com nossa documentação.
Com isso, descobrimos que a análise estática de código verifica a qualidade do código-fonte. Essa verificação é realizada antes mesmo que haja execução do software, diferentemente do que ocorre com os testes unitários que validam o software com base no resultado de sua execução.
É importante ressaltar a diferença entre validação e verificação, para completo entendimento do conceito da análise estática. Uma verificação considera “fazer certo alguma coisa”, ou seja, garante que os passos para atingir um dado objetivo foram realizados corretamente. Verificação é eficiência. A validação trata de “fazer a coisa certa”, ou seja, garantir que o objetivo seja atingido, independente da forma como os passos foram realizados. Validação é eficácia. Considera-se, portanto, que a análise estática de código está relacionada à verificação, pois analisa como o código-fonte foi construído internamente.
A análise estática de código não verifica apenas arquivos texto (com extensão .java, .jsp, .js). Cada ferramenta, dependendo de sua implementação, pode realizar a verificação em código-fonte ou bytecode. Embora algumas ferramentas sejam capazes de realizar a verificação estática em arquivos JSP e JavaScript, por exemplo, a análise aqui costuma se focar especificamente em código-fonte Java (bem como EM bytecodes).
A análise estática pode ter sua verificação agrupada em três aspectos principais:
- Verificação por estilo: Considera elementos como indentação, espaços e tabs, convenção de nomes, número de parâmetros, alinhamento na vertical, formato e presença de comentários, dentre outros. São todos os aspectos que contribuem para tornar o código mais padronizado, organizado e legível. A ferramenta mais utilizada para verificação por estilo é o Checkstyle (http://checkstyle.sourceforge.net/);
- Verificação por boas práticas: Aplica uma gama de regras para verificar se práticas corretas estão sendo realizadas, como evitar duplicação de código, garantir o correto uso de encoding, implementação do método clone(), tamanho de métodos e classes, tamanho de parâmetros, uso do padrão Singleton, criação desnecessária de variáveis locais e muitas outras. O conjunto de regras é extenso e visa garantir que o código apresente as melhores práticas possíveis. A ferramenta de verificação mais utilizada para aplicar boas práticas é o PMD (https://pmd.github.io/);
- Verificação por bugs: Trata de encontrar erros no sistema. Isto é importante para antecipar a identificação de problemas no software (até antes mesmo de sua execução pelo cliente). A ferramenta mais utilizada para identificação de bugs é o Firebug (http://getfirebug.com/).
A verificação das ferramentas PMD e Checkstyle é realizada sobre código-fonte não compilado (arquivo com extensão .java), mas a verificação com Firebug analisa bytecodes (arquivos compilados do Java, com extensão .class). Desta forma, para análises envolvendo Firebug, uma compilação prévia é necessária. Isso é tratado pelo seu respectivo plugin, de forma que se faz transparente ao desenvolvedor.
Para fazer análise estática em projetos de Android, é recomendado o uso do Lint, outros softwares como FindBugs e o APK Analyzer (que já vem juntamente com o Android Studio) também são utilizados para fazer essas verificações.
Depois de tanta pesquisa, utilizamos o CheckStyle para verificar nosso código e achamos alguns erros. Na próxima semana, vamos documentar esses erros e terminar de corrigi-los.

De: Renata Souza

Vigésima Semana - Mais Uma Semana Comum do Final Do Bimestre

Nesta semana começamos a fazer as mudanças indicadas pelos professores, como os requisitos não-funcionais que ainda estavam incompletos e a refatoração na API dos verbos HTTP utilizados. Além disso, também começamos a adequar nossa documentação final ao padrão exigido na disciplina, adicionando o capítulo de métricas e iniciando a análise estática do nosso código. Também atualizamos nosso banco de dados, assim como os diagramas relacionados a ele, devido a necessidade de uma nova tabela.

De: Nicolas  Caous

Décima Nona Semana - Semana Estranha com Dias Esquisitos

Nesta semana a equipe apresentou os progressos de desenvolvimento do sistema Meu Mascote aos orientadores de curso, que possuem o papel de clientes deste produto. Com esta apresentação, foram reformulados alguns dos pontos da aplicação que foram propostos durante o segundo bimestre como os requisitos por exemplo. A equipe esta sofrendo com atrasos no desenvolvimento devido ao serializer na API, o que resultará em um novo cronograma a ser projetado pela equipe para cobrir o atraso que teve no mês de Maio.

A API esta sendo reformulada para que possa ter o seu consumo o mais breve para se ter o primeiro requisito do sistema cumprido. Enquanto isso, a pesquisa de mercado continua sendo feita tendo mais resultados a cada dia e as métricas serão iniciadas ao longo das próximas Sprints da equipe.

De: Julia Fernandes

Décima Oitava Semana - A Última Semana Antes da Apresentação

Nos últimos sete dias, a equipe se concentrou no desenvolvimento das funcionalidades de login e cadastro para o aplicativo. Por conta de problemas com as dependências e com a configuração do projeto no Android Studio, ainda não conseguimos recuperar o atraso no planejamento mensal feito. Além disso, reservamos parte do tempo para a montagem da apresentação do 2° bimestre, que acontecerá na próxima terça-feira (13/06). Nosso objetivo é apresentar a modelagem do projeto, nosso plano de testes e os protótipos para os professores.

De: Gabriel Renato

Décima Sétima Semana - Mais Uma Semana Como Todas as Outras Semanas

Nessa semana em nossa aula de PDS o professor Daniel (um de nossos orientadores) verificou o andamento do nosso projeto e nos deu dicas quanto ao desenvolvimento de nossa documentação, ressaltando a parte de métricas que ainda não havia sido iniciadas e a criação de uma tabela que apresentasse todos os requisitos do sistema em um apêndice individual. Com isso, decidimos retomar a pesquisa de mercado, mas ainda assim continuamos com foco no desenvolvimento da aplicação visando recuperar as tarefas estipuladas para maio que acabaram não sendo concluídas no tempo estipulado.

De: Isabelle Neves

Décima Sexta Semana - IT'S ALIVE!

Com a documentação já bastante avançada, estamos concentrando forças no desenvolvimento do aplicativo nos últimos dias. Para o andamento do projeto ficar mais transparente e objetivo, estamos seguindo um cronograma mensal de desenvolvimento.

Cronograma mensal de desenvolvimento do projeto Meu Mascote

Como resultado do trabalho dessa semana, já temos o endpoint /getpublickey funcionando (endpoint para pegar a chave pública do servidor), além de termos o banco de dados funcionando no Heroku. Para o aplicativo em si desenvolvemos o menu e já conseguimos fazer a conexão com a API. Nos próximos dias pretendemos fazer a tela de login e cadastro funcionar, além da listagem de animais e fechando assim aquilo que planejamos para o mês de maio.

De: Giovanni Henrique

Décima Quinta Semana - Um Pequeno Passo Para o Projeto, Mas um Grande Passo Para a Equipe

Na última semana, a equipe teve sucesso com funcionamento de uma API que retorna a soma de dois valores quaisquer, o que abre margem para o inicio do desenvolvimento oficialmente. De forma gradual, os integrantes são encarregados além de tarefas de documentação, para tarefas do desenvolvimento do sistema que são definidas na Planning da mesma forma que as tarefas de documentação.

De: Renata Souza

Décima Quarta Semana - De Volta aos Desenvolvimento

Nessa semana terminamos os diagramas que representam o caminho de cada usuário que utilizará nosso aplicativo usando como base o padrão UML, além de terminar a documentação relacionada ao diagrama de casos de uso.

Estipulamos metas mensais para as sprints seguintes e retomamos o desenvolvimento da nossa aplicação em si. Recomeçamos com os testes da comunicação entre a API e o banco de dados. Para este mês as metas definidas são: a implementação da tela de login, da tela de cadastro de animais do representante da ONG, da tela de listagem de animais, e de alguns endpoints da API. Apesar de retomarmos a elaboração da nossa aplicação, apenas parte da equipe ficará voltada para este processo nessa semana, para que assim ainda haja um andamento em nossa documentação.

De: Nicolas Caous

Décima Terceira Semana - Seguindo as Sugestões do Cliente

Essa semana continuamos o desenvolvimento da documentação e, seguindo o conselho do professor, decidimos utilizar do padrão UML para o desenvolvimento dos diagramas da arquitetura da nossa aplicação. O diagrama de casos de uso e da arquitetura de software foram finalizados. Acrescentamos à documentação uma explicação sobre a metodologia de trabalho e também iniciamos a parte sobre a segurança dos dados. Foi decidido e documentado um padrão a respeito do retorno dos endpoints da nossa API.

De: Julia Fernandes

Décima Segunda Semana - Mais Uma Semana Comum

Nesta semana, nós finalizamos do Diagrama de Casos de Uso da aplicação, que será inserida na documentação final. Foram definidas medidas de segurança que consiste na encriptação dos dados do login.

Para a documentação, as atas das reuniões, que são gravadas, serão atualizadas até o dia da ultima reunião. Para facilitar esta tarefa, foi criado uma conta no Dropbox que armazenará todos os áudios de cada reunião feita pela equipe.

De: Gabriel Renato

Décima Primeira Semana - As Preparações Para o Inicio do Desenvolvimento

A equipe está se preparando para poder iniciar em breve o desenvolvimento dos planos documentados nas últimas semanas, que serão finalizados o mais rápido possível. Houveram  reformulações e correções nos diagramas e parágrafos que descrevem as funções, além de correções sugeridas pelo professor ou por colegas de equipe estarem sendo feitas por toda a equipe.

Na última reunião, no dia 18/04, percebemos a necessidade de adotar um método para que se tenha uma rotação de pessoas para que cuidem de  cada tópico das reuniões semanais. Resultando assim, em uma melhor comunicação para a equipe dando a responsabilidade da fala para cada.

De: Isabelle Neves

Décima Semana - Bimestre Novo, Rotina Nova

Na reunião feita pela equipe nesta terça feira, dia 11 de Abril, levantamos os pontos positivos e negativos do bimestre passado, entre eles percebemos que não estávamos seguindo com o Scrum, metodologia ágil escolhida pela equipe, já que não havíamos definido nenhum Scrum Master ou P.O.(Product Owner). 

Sendo assim, foi feita nesta reunião uma votação para decidir quem ficaria com tais responsabilidades, como resultado disso Gabriel Renato será nosso Scrum Master e Isabelle Neves será nossa P.O. Além disso, assim como foi explicado em nossa primeira publicação sobre o nosso sistema de rotação de gerencia, Isabelle Neves foi escolhida como a nova gerente da equipe.

De: Giovanni Henrique

Nona Semana - O Fim do Começo

Nesta semana, durante uma reunião, foi decidido o descarte de uma das tecnologias que estávamos utilizando para gerenciar o banco de dados da aplicação. E teve a recriação das tabelas para banco de dados, junto com seu diagrama.

E houve uma continuação do planejamento de software, que estará na documentação final do projeto.

De: Renata Souza

Oitava Semana - O Planejamento

Essa semana nós nos reunimos com os professores, para que eles nos auxiliassem no andamento do projeto. Após a reunião, chegamos a uma nova divisão de tarefas, em que nossos membros não possuem foco em apenas uma divisão do projeto, além de termos definido um líder para cada frente.  A nova divisão está definida como:

Tentamos realizar contato com ONGs que cuidam de animais abandonados, para definir melhor nossos requisitos e o funcionamento da aplicação. As respostas obtidas até agora não agregaram muito valor ao projeto, apesar do surgimento de oportunidades de parcerias, que só seriam concretizadas após o término do desenvolvimento do aplicativo.
Como dito na última postagem, nessa última semana demos prioridade para o planejamento de toda a nossa aplicação. Pretendemos seguir nessa semana com o mesmo foco.

De: Nicolas Caous

Sétima Semana - Mudança de Estratégia

Após a primeira semana de desenvolvimento não obtivemos os resultados esperados, pois os membros da equipe desconsideraram as dificuldades que encontraríamos.

Após realizarmos a reunião de planejamento semanal concluímos que começamos o projeto de maneira equivocada, pois iniciamos o desenvolvimento do projeto sem definirmos a arquitetura do sistema e todo o seu planejamento. Sendo assim, para esta semana focaremos os nossos esforços no desenvolvimento da documentação incluindo agora o planejamento da arquitetura do sistema, em contraste, suspenderemos o início da implementação do projeto por enquanto.

De: Julia Fernandes

Sexta Semana - Inicio do Desenvolvimento do Projeto

Imagem da 1ª Sprint no Trello

Nesta semana, juntamente com a ajuda do Trello, começamos a organizar o desenvolvimento da nossa aplicação. Planejamos deixar as funcionalidades básicas (como tela de login e cadastro do usuário adotante) utilizáveis, além do início do desenvolvimento do banco de dados e da pesquisa de servidores web gratuitos, para isso realizamos a nova divisão de tarefas:

 
Ocorreu um progresso no desenvolvimento da documentação final, como a inclusão da proposta inicial corrigida e da parte dos descartes de tecnologias e funcionalidades. Também foram incluídas as publicações do blog. Acabamos, por fim, terminar o vídeo promocional e a confecção do formulário para a pesquisa de mercado.

Também contactamos novas ONGs, recebemos o retorno de algumas e visitamos outras. Estamos estudando uma parceira com uma OSCIP (Organização da Sociedade Civil de Interesse Público) que dá suporte à diversas ONGs.

De: Gabriel Renato

Quinta Semana - A Apresentação da Proposta

Nesta semana cuidamos dos últimos detalhes da apresentação da proposta inicial analisando os resultados adquiridos até o momento da pesquisa de mercado, preparando a apresentação em slides e finalizando as documentações e análises. Após a apresentação da proposta inicial, realizamos uma reunião para discutir sobre os pontos negativos levantados pelos professores em relação ao nosso projeto, com isso traçamos uma estratégia para aperfeiçoar nossa aplicação, estrutura do grupo e do trabalho em geral. Desenvolvemos um protótipo visual para auxiliar o andamento do projeto e definimos a logotipo do aplicativo.

As falhas apontadas pelos professores foram em relação ao objetivo do projeto, pois acabamos por ampliar demais o escopo e perdendo a objetividade da aplicação para resolver o problema que propusemos inicialmente.

Houve um avanço no desenvolvimento do vídeo promocional. Estamos nos preparando para começar o desenvolvimento da aplicação na próxima semana e finalizando a escolha das tecnologias a serem utilizadas.

De: Isabelle Neves

Quarta Semana - Preparações para a Apresentação

No dia 7 de Março, teremos que fazer uma apresentação da nossa proposta inicial para os professores. Devido a isso nosso foco estava no desenvolvimento das documentações necessárias para a apresentação.

Nós definimos por completo quais serão as funcionalidades da nossa aplicação, além das tecnologias que iremos usar para o desenvolvimento da aplicação. Ao desenrolar da semana, encontramos alguns problemas para mexer no LaTeX, o editor de texto escolhido pela equipe, já que ainda não estávamos acostumados com a ferramenta. Para agilizar o processo, optamos por usar a ferramenta online, ShareLaTeX, para que assim mais de uma pessoa pudesse manipular o arquivo, buscando deixar todos os nossos documentos padronizados resolvemos usar o Modelo de Tese do abnTeX2, que é disponibilizado pelo próprio ShareLaTeX.

Por conta de uma dificuldade encontrada em como acessar e alterar o SVN através do computador pessoal, escolhemos utilizar o TortoiseSVN. A gerente da nossa equipe, Julia, criou um Slide Tutorial sobre o TortoiseSVN devido a confusão inicial a utiliza-lo, estamos pensando em disponibiliza-lo futuramente para ajudar as equipes que virão futuramente para que esse problema não fique mais atrapalhando todos que forem fazer esse trabalho.

Também começamos a desenvolver alguns diagramas referentes a nossa aplicação, a nossa gerente desenvolveu o Diagrama de Caso de Usos e deu uma ajuda inicial ao Nicolas com o MER (Modelo Entidade Relacionamento).

Gabriel Renato, o responsável por dar suporte para a documentação e cuidar do canal do Youtube começou a desenvolver o vídeo proposta. Começamos também a desenvolver as Análises do Grupos Anteriores, escolhendo a Equipe do BoostMyCar, como sendo uma das opções de análise porém ainda não decidimos

Alguns dos membros da equipe baixaram o Ubuntu para utilizar as aplicações com Linux, o Nicolas começou a pesquisar sobre o PhoneGap, um Framework que usaremos juntamente com o Android Studio para o desenvolvimento do aplicativo e o Giovanni e a Isabelle estão começando a fazer testes no Android Studio para aprender a como usar a ferramenta.

Ainda estamos fazendo nossa pesquisa de mercado, procurando por aplicativos parecidos com o nosso e consultando pessoas para ver como seria a aceitação do público ao nosso aplicativo.

De: Giovanni Henrique

Terceira Semana - O Primeiro Contato

Nessa semana, entramos em contato com algumas ONG's, através de e-mail e telefone, e já recebemos o retorno de algumas organizações. A partir das respostas, definimos algumas das regras de negócios da nossa aplicação.

Também finalizamos o protótipo do logo para o aplicativo, faltando apenas definir qual serão as cores utilizadas no mesmo.

De: Renata Souza

Segunda Semana - Avanços da Equipe

Os avanços da equipe quanto à disciplina dessa semana foram: 

A definição da proposta do projeto a ser desenvolvido como sendo um aplicativo voltado para a integração de pessoas que buscam animais de estimação e ONGs de animais abandonados;

Inicio do desenvolvimento da parte visual (protótipo para logo); 

Pesquisa das dependências das tecnologias a serem utilizadas para o projeto;

Pesquisa relativa às ONGs com o objetivo de entrar em contato via e-mail com as organizações e definir as funções necessárias para a aplicativo;

Início da pesquisa de mercado focado na busca de aplicativos homólogos;

Início das análises de projetos passados;

Reuniões para o estudo de mercado e para o desenvolvimento do projeto.

De: Nicolas Caous

Primeira Semana - A Criação da Equipe

     Este blog foi criado para ajudar no desenvolvimento do projeto de PDS (Prática de Desenvolvimento de Sistemas) ao nos permitir manter a organização durante o avanço do sistema, pois sempre saberemos os avanços e problemas de outro membro da equipe o que permitirá um trabalho mais rápido e eficaz, além de permitir a distribuição de informações sobre o projeto ao longo de sua evolução.
     Durante a Criação das Equipes, houve um pequeno problema relacionado ao "balanceamento dos grupos", o que acabou por atrasar o desenvolvimento dos projetos, porém apesar desse atraso a Equipe Void já conseguiu bons resultados e avanços.
     Dentre os avanços feitos no grupo, que teve mais ou menos de dois a três dias de atraso, fizemos nossa primeira reunião com o objetivo de analisar as primeiras ideias, que no momento são 5, e como será a distribuição das tarefas entre os integrantes em cada caso, tanto em relação as reuniões quanto com o desenvolvimento do sistema.
     Nossa equipe, particularmente, se preocupa bastante com as reuniões, devido a organização que as mesmas causam em relação a elaboração e otimização do projeto. Por conta disso, temos um planejamento de fazer, pelo menos, duas reuniões por semana.

     Atualmente a Equipe é formada por seis integrantes:

• Renata Souza 
• Giovanni Henrique
• Nicolas Caous 
• Gabriel Renato 
• Isabelle Neves Porto
• Julia Fernandes Santana

     Já que as iniciais de nossos nomes não conseguem formar um nome pronunciável para a equipe, tivemos que optar por uma eleição, onde vários nomes possíveis para a equipe foram mostrados para os membros do time, como resultado disso temos o nome "Team Void". 

     Para a escolha do Gerente, o mesmo método foi usado, aqueles que gostariam de gerir o grupo se candidataram e todos votaram naqueles que achavam ser o melhor, no fim decidimos fazer um sistema de rotação de gerentes em que a cada bimestre o gestor da equipe mudaria. Como resultado disso, a primeira gerente do time será Julia F.
     Para a próxima semana pretendemos definir qual será o nosso projeto para então começar a desenvolvê-lo.

De: Julia Fernandes