Relatório 01/11/2013

Resumo Geral

Durante essa semana, iniciamos o documento referente aos testes para que o programa exposto não esteja sujeito a erros de execução ou procedimentos indevidos. Integrantes pesquisaram um pouco sobre testes e começaram a desenvolver um documento para este fim. Além disso, assistimos algumas apresentações de colegas e esperamos aprender com elas. Alguns pontos exigidos pelos professores foram:

·         Revisão em relação a formatação do documento entregue – já está sendo feita pelos integrantes do grupo para que haja correção antes da entrega da versão final.

·         Apresentação das atividades que serão entregues a prazo e aquelas que não foram finalizadas a tempo.

·         Refazer Casos de uso

Testes de software

Resumo

Este documento tem como objetivo descrever o processo de testes referentes ao software a ser apresentado, além da importância deste. Em relação à manutenção de possíveis bugs, apresentaremos a resolução do problema e o possível erro.

Introdução

            A decisão de realização de testes no software consiste basicamente em descobrir a existência de defeitos que podem ser imprecisões, desentendimentos, inconsistência. Através do debugging – processo de encontrar bugs associados a um defeito – temos como objetivo mostrar que a aplicação faz o esperado e não faz mais do que o esperado. Ao contrario do que se pensam os testes não melhoram a qualidade de um software, apenas ajuda a identificas problemas que poderíamos ter evitado. Dividimos os testes em:

·         Teste de Unidade – relacionados ao teste de um método, classe ou grupo de classes.

·         Teste de Integração – teste inter-método (testa a integração de todos os métodos), intra-classe e inter-classe (interações entre métodos públicos).

·         Testes de Sistema – toda a aplicação

Para a realização desses testes, decidimos usar um programa chamado JaBuTi, que testa automaticamente os itens citados anteriormente, além do fluxo de dados entre as classes.

Posteriormente, após a realização dos testes, postaremos os seguintes tópicos:

Testes com Jabuti

Testes do sistema

Referências:

MACORATTI, José Carlos. Link disponível em: http://www.macoratti.net/tst_sw1.htm

RAMOS, Ricardo Argenton  em Teste de Software Orientada a Objeto. Link disponível em http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ES_II_2010_1/aulas/TesteSoftwareOO.pdf

Relatório 24/10/2013

Resumo Geral

                No decorrer da semana, tínhamos como meta, entregar os documentos - versão 1 -(manual técnico, manual do usuário, relatório de desenvolvimento) encadernados, junto com o CD contendo o programa. Pensando nisso, focamos na finalização da documentação e das funcionalidades do programa. A partir disso, o alarme que avisara ao usuário que a data de vencimento do pagamento não realizado está chegando foi finalizada. Também fizemos algumas mudanças no layout (inserimos ícones nas abas). Finalizamos então o projeto para a entrega deste da forma como está descrita no Manual do usuário - versão 1 (Figura 1).

Figura 1

Após a entrega dos trabalhos, foi proposto que continuássemos com o desenvolvimento do projeto. Através do controle no cronograma desse último bimestre, temos funções a serem finalizadas como:

·  Implementação de gráficos que mostrem despesas do usuário no último mês, separando-as em categorias. Construímos um esboço deste gráfico para exemplificar a ideia e facilitar o desenvolvimento do código como pode ser visto na figura 3. Estamos estudando ainda qual seria o melhor gráfico a ser exposto (pizza ou em colunas). A decisão que tomamos no momento foi que o gráfico em coluna é melhor para visualizar as despesas em apenas um mês, pois mostra com mais detalhes onde foi gasto maior parte do dinheiro. Já a geração de gráficos em relação ao ano ou a um número de meses maior que um, o gráfico em pizza é mais propicio por mostrar de forma clara qual foi o mês que o usuário gastou mais (figura 2). É necessário perceber que o enfoque entre despesa e mês é importante em cada tipo de gráfico. Resta apenas decidir qual gráfico é mais útil ou se o tempo que nos resto é suficiente para que façamos as duas formas de geração e gráfico.

Figura 2

Figura 3

·  Terminar a documentação com revisão da versão 1 (erros de formatação e apontamento dos professores), atas de reuniões e organização dos temas.

·   Realização dos testes, utilização no dia-a-dia (verificar a presença de erros na pratica) e resultados de sua utilização.

·  Divulgação e mercado consumidor

Relatorio 17/10/2013

Relatório de atividades – 17/10/2013         

Resumo Geral

Após a reunião com os professores no terceiro bimestre, decidimos focar na modelagem do banco de dados (evolução dos modelos do banco de dados melhor descrita no documento O desenvolvimento). Após a finalização deste, implementamos no banco de dados propriamente dito e fizemos as devidas alterações no programa. Também neste bimestre obtivemos a finalização das telas do aplicativo, mudando o seu layout e implementando detalhes como ícones para melhorar a navegação do usuário. Foram realizadas algumas atividades como uso de layouts individuais para cada item na lista de pagamentos e ingressos na última semana. Além disso, criamos layout novo para tela de ingressos, adicionamos ingressos completamente funcionais e botão para confirmar pagamento agendado, ícone de status ao lado de cada pagamento.

                O agendamento dos pagamentos próximos à data de pagamento foi implementado como foi proposto em primeira instância. O alerta avisa ao usuário que a data da conta do cartão crédito ou o pagamento agendado esta aproximando e que precisa ser paga. O layout foi modelado novamente, adicionando-se ícones nas abas e na impressão dos extratos, para que o usuário adicione ou apague uma despesa. Nas últimas semanas antes da entrega do projeto, o programa está quase pronto.

Relatório de atividades – 10/10/2013                         

Resumo Geral

                Esta semana foi realizada a correção modelo do banco de dados (versão 6) sendo apresentada para o professor Renato. Além disso, algumas atualizações do programa foram:

• Adicionado ícones as abas, botões de Novo e Cancelar e status dos pagamentos na lista.
• A lista foi alterada de ListView para ExpandableListView. Nesta atualização o programa está habilitado a organizar os pagamentos por dia.
• Tela de ingressos está com design em lista e suporta novos ingressos. Além disso, cada linha utiliza os arquivos de layout pgto_row.xml (para cada item) e pgto_parent.xml (para o cabeçalho da ExpandableListView) – (figura abaixo)

                O modelo do banco de dados foi finalmente finalizado e apresentado para os clientes (figura 1).

Relatório de atividades – 03/10/2013

Relatório de atividades – 03/10/2013

Resumo Geral
 - Nesta semana, componentes do grupo revisaram o banco de dados desenvolvido com clientes e pediram opiniões. Alguns pontos apontados pelos clientes foram:
• Redefinição da tela
o Opção Extrato: Opção de adicionar e remover estarão no mesmo local. Já os ingressos estarão em outra tela no mesmo formato (Ilustração 2)
• Tela de Extrato: Adicionar opção de listar pagamentos por cartão.
- A atualização feita esta semana foi referente à Tela de cadastro de pagamento. Ao adicionarmos a data referente ao pagamento, o usuário terá acesso à tela de calendário. A ferramenta utilizada foi TimePickerDialog e DatePickerDialog.

Anexo
 Sugestão do colega Victor Moneratto durante as aulas
• Campo TextBox vir com letra maiúscula como default;
• Melhorar o layout – colocar imagem nas abas, botões fixos com apenas um logo. Por exemplo: um botão com uma imagem com + para o usuário escolher apenas adicionar. Posteriormente, o usuário escolheria o que desejaria adicionar (trocar botões escrito Novo);
• Deixar telas com o padrão do Android para facilitar o usuário que já esta em contato com essa interface;
• TextBox com tratamento para dinheiro