Sénégal
note 2 – Principes et méthodes de consolidation
Além da atribuição de responsáveis em uma determinada obra, o sistema desenvolvido também possibilita a atribuição de várias res- ponsabilidades para cada obra, que traduzem-se em tarefas específicas que podem ser criadas e atribuídas para qualquer um dos usuários responsáveis cadastrados.
O menu de responsabilidades pode ser acessado a partir do momento que uma obra atinge o estágio "em Execução". Para navegar para a listagem de responsabilidades (Figura 40), basta clicar no item com o texto "Responsabilidades", exibido tela de visualização das obras em execução, conforme a Figura 39.
Para adicionar uma nova responsabilidade, basta clicar no bo- tão que exibe o símbolo matemático de sinal positivo (+) e preencher
Capítulo 3. Desenvolvimento 64
as informações do formulário de inserção de responsabilidades, apre- sentado na Figura 41.
A implementação da inserção e atribuição de responsabilidades é feita pela classe de serviço ScheduleService.java e pode ser observada na Figura 27. A resolução das responsabilidades é implementada pelo método solveResponsability() e está apresentada na Figura 28.
3.2.2.10 RF10 - O sistema deve viabilizar o gerenciamento de atrasos Um atraso em um determinado cronograma é reconhecido pelo sistema quando a data limite do cronograma (atributo ’deadline’) é ultrapassada pela data atual. A comparação entre as datas limite e atual é realizada pelo app toda vez que o cronograma em ques- tão é visualizado (quando a tela de visualização do cronograma é exibida), executando o método delayExists() da classe ScheduleVi- ewActivity.java, presente na Figura 59. Quando o sistema detectar um atraso, ele exibirá um modal de informação explicando para o usuário os encaminhamentos possíveis de gerenciamento, conforme a Figura 48. Os encaminhamentos sugeridos ao usuário são a criação de novas responsabilidades, o envio de e-mails informando o atraso para os responsáveis e/ou o cadastro de registros de atraso.
A criação de responsabilidades a partir do módulo de cronogra- mas pode ser feita pela da tela de visualização de um determinado cronograma que esteja atrasado, como demonstrado na Figura 49. Para navegar para o módulo de responsabilidades, basta clicar no botão de responsabilidades (representado pelo ícone no canto superior direito da tela em questão).
O envio de e-mails informativos para os responsáveis avisando que o cronograma em questão está atrasado, pode ser feito pela tela de visualização de cronogramas atrasados, conforme a Figura 49. Para enviar os e-mails, basta clicar no botão de e-mail (representado pelo
Capítulo 3. Desenvolvimento 65
ícone em formato de carta na tela em questão questão).
O cadastro de registros de atrasos pode ser feito clicando no botão que exibe o símbolo matemático de sinal positivo (+) da tela de visualização de cronogramas atrasados (Figura 49) e preencheendo as informações do formulário de inserção de atrasos, conforme apresen- tado nas figuras Figura 50 e Figura 51. O cadastro de atrasos utiliza 2 telas diferentes para preencher todas informações necessárias, que incluem a classificação do atraso segundo a literatura estudada no Se- ção 2.2, além do título, motivo, número de dias estimado e informações adicionais.
A tela de visualização de cronograma (Figura 21) também con- tém o botão de resolver o cronograma (representado por um símbolo de "check"), que muda o estado do cronograma atual para "Resolvido". Tanto cronogramas dentro do prazo quanto cronogramas atrasados podem ser resolvidos. O histórico de todos atrasos registrados e o dia de resolução do cronograma ainda ficarão salvos e as informações poderão ser visualizadas normalmente após a resolução.
A implementação do cadastro de atrasos é feita pela classe de serviço ScheduleService.java, utilizando as classes nativas FirebaseDa- tabase e DatabaseReference. A Figura 52 mostra o código referente ao método writeDelay(). O ato de resolução de um atraso é implementado pelo método solveSchedule() e pode ser observado na Figura 53.
3.3 VALIDAÇÃO
O adjetivo válido faz referência àquilo que vale legalmente ou que é firme e subsistente. A validação segundo o dicionário online Dicio [16] é a ação e o efeito de validar. Segundo o site Conceito [17], a validação no âmbito da informática é o processo de revisão ao qual um programa é submetido para verificar se este cumpre todas suas especificações. O processo de validação é realizado durante toda
Capítulo 3. Desenvolvimento 66
etapa de desenvolvimento, mas realiza-se principalmente ao final da implementação. A intenção da validação é confirmar que o software desempenhe as tarefas que o utilizador pretende realizar.
A validação do sistema implementado foi realizada durante todo processo de desenvolvimento, conforme as funcionalidades foram sendo escritas, implementadas e testadas. Além disso, foi realizada principalmente estabelecendo contato com os entrevistados e1, e2 e e3 via WhatsApp. Deste modo, foi possível esclarecer as respectivas dúvidas sobre análise, modelagem e construção civil; que surgiram durante a implementação do sistema.
3.3.1 Testes
A fase de testes no contexto de desenvolvimento de softwares é a análise dinâmica do sistema a fim de identificar e eliminar discrepân- cias em relação ao contexto em que ele deve operar [20]. Em outras palavras, o teste do aplicativo é a etapa responsável por verificar o bom funcionamento, detectar eventos inesperados e corrigi-los antes do lançamento do app.
No âmbito do desenvolvimento de aplicativos móveis, devido ao grande número de modelos de smartphones disponíveis no mercado, às varidades de versões dos sistemas operacionais e à pluralidade de tamanhos diferentes de telas, é fundamental implementar aplicativos que se adaptem bem a essas diversidades.
Devido a esstes fatores, foram realizados diferentes tipos de testes para confirmar o bom funcionamento do aplicação.
3.3.1.1 Testes de compatibilidade
O segmento de testes definido como ’Testes de compatiblidade’ exerce a função de analisar a adequação do aplicativo perante o hard- ware do smartphone que executa-o. Este segmento demonstra-se extre-
Capítulo 3. Desenvolvimento 67
mamente importante em aplicativos móveis, pois um grande diferencial entre os aparelhos é o tamanho da tela. As dimensões da tela do apa- relho que executa a aplicação interferem diretamente na organização dos componentes de cada interface. Por isso, é importante a organi- zação dos componentes de maneira relativa e evitar impor dimensões exatas, para permitir que a interface seja maleável de acordo com o dispositivo que exibe-a.
Para realizar os testes de compatibilidade foi possível utilizar a gama de emuladores disponíveis pelo Android Studio. O ambiente de desenvolvimento Android Studio oferece uma varidade de emulado- res de diferentes fabricantes, tamanhos de tela e versões de firmware, que são gerenciados pelo Android Virtual Device Manager [4]. Foram criados 3 emuladores com diferentes características para verificar o fun- cionamento da compatibilidade do sistema. Os emuladores utilizados foram:
1. SmartPhone Pixel 2: Fabricante Google, resolução 1080x1920, Android versão 10.0 API 29;
2. SmartPhone Nexus S: Fabricante Samsung, resolução 720x1280, Android versão 5.1 API 22;
3. SmartPhone Galaxy Nexus One: Fabricante Samsung, resolução 480x800, Android versão 5.1 API 22.
Os testes de compatibilidade do projeto basearam-se em exe- cutar cada uma das funcionalidades do aplicativo em cada um dos emuladores. O resultado inicial das execuções foi a constatação de que algumas telas precisavam adquirir uma nova orientação de distribuição de componentes. Em telas muito enxutas, como a do Smartphone Ga- laxy Nexus 2, algumas interfaces não exibiam todos componentes com perfeição. A solução para este empecilho foi atingida com a adoção da
Capítulo 3. Desenvolvimento 68
distribuição de orientação RecyclerView [37]. O widget RecyclerView é uma versão mais avançada e flexível do ListView e pode ser utilizado para exibir uma lista de rolagem de elementos com base em grandes conjuntos de dados ou componentes. Deste modo, foi possível distri- buir adequadamente os componentes em todas plataformas testadas, pois quando a plataforma possuir uma tela pequena demais para a interface em questão, a função de barra de rolagem será incorporada. A Figura 58 demonstra a comparação de visualização da lista de or- çamentos entre todos emuladores avaliados, exibindo respectivamente os aparelhos Pixel 2, Nexus S e Galaxy Nexus 2.
3.3.1.2 Testes de mobilidade
O segmento de testes definido como ’Testes de mobilidade’ exerce a função de analisar e validar a capacidade de comunicação do aplicativo com outros aplicativos do mesmo smartphone. Este tipo de teste tem se tornando cada dia mais importante devido ao crescimento da necessidade de compartilhar informações com outros aplicativos.
No contexto do sistema desenvolvido, as únicas comunicações com aplicativos terceiros são realizadas durante as funções de anexar arquivos fotográficos e de enviar e-mails sobre o atraso do cronograma.
Ambas integrações estabelecem comunicação perfeitamente em cada um dos smartphones testados, executando a integração com a galeria e com o aplicativo de e-mail do Google (Gmail), sem apresentar qualquer problema.
3.3.1.3 Testes de segurança
O segmento de testes definido como ’Testes de segurança’ exerce a função de analisar e determinar se as informações sigilosas contidas no aplicativo estão seguras, sem risco de que terceiros tenham acesso aos dados. Os testes de segurança no sistema desenvolvido foram
Capítulo 3. Desenvolvimento 69
realizados utilizando duas abordagens diferentes: Estática e dinâmica. A abordagem estática analisou o código do programa, sem executá- lo, buscando encontrar brechas de segurança na implementação. A abordagem dinâmica não analisa o código em si, mas a execução do aplicativo em questão.
Primeiramente, foram definidos os pontos chave do sistema aonde permissões de usuário são aplicadas:
1. Tela de login (Figura 30): Autenticação do utilizador;
2. Tela do menu principal do aplicativo (Figura 32): Exibição do botão de obras;
3. Tela de listagem de obras (Figura 36): Exposição somente das obra que o usuário é responsável.
A atividade MainActivity.java é responsável por gerenciar a tela de login (Figura 30), o arquivo activity-main.xml é responsável por modelar e organizar os componentes visuais da mesma. A implemen- tação da autenticação é feita pelo próprio objeto nativo FirebaseAuth, que apenas é chamado pelo aplicativo desenvolvido, como apresentado na Figura 16. Mesmo assim, é necessário verificar se as sessões não são mantidas após realizar logout ou quaisquer ações que levem a uma inconsistência. Os casos de testes executados para verificar esse comportamento podem ser visualizados na Tabela 3
A atividade HomeActivity.java é responsável por gerenciar a tela do menu principal (Figura 32), o arquivo activity-home.xml é res- ponsável por modelar e organizar os componentes visuais da mesma. A exibição do botão de obras (que navega para a lista de obras) é controlada pelo método checkAcccountVerification(), que é executado sempre que a interface em questão é exibida. A checagem de verifi- cação pode ser feita pelo objeto nativo FirebaseAuth, chamando o
Capítulo 3. Desenvolvimento 70
Tabela 3 – Tela de login - Testes realizados
Caso de Teste Descrição Resultado es-
perado
Resultado ob- tido
CDT-01 Verificar se é possível en- trar no sistema sem o uso de e-mail e/ou senha
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-02 Verificar se é possível en- trar no sistema após reali- zar o Logout
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-03 Verificar se é possível en- trar no sistema após fe- char o aplicativo com o gerenciador de tarefas do smartphone
Não deve ser possível
Não foi possí- vel: Passou no teste
método isEmailVerified(). Desta forma, os utilizadores da aplicação só poderão visualizar quaisquer obras posteriormente à verificação do e-mail. Mesmo assim, é necessário efetuar testes que examinem a visibilidade do botão de obras perante cenários diferentes. Os casos de teste executados para verificar esse comportamento estão apresentados na Tabela 4.
A atividade ListConstructionActivity.java é responsável por ge- renciar a tela de login (Figura 36), o arquivo activity-list-construction.xml é responsável por modelar e organizar os componentes visuais da mesma. A seleção das obras exibidas para o usuário logado é feita pelo método, como observado na Figura 57. Ainda sim, é necessário executar testes que verifiquem que as obras exibidas sempre serão de responsabilidade de usuário. Os casos de teste executados para verificar esse comportamento estão apresentados na Tabela 5.
Capítulo 3. Desenvolvimento 71
Tabela 4 – Tela do menu principal - Testes realizados
Caso de Teste Descrição Resultado es-
perado
Resultado ob- tido
CDT-01 Verificar se é possível visua- lizar o botão de obras ante- riormente à verificação da conta
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-02 Verificar se é possível visu- alizar o botão de obras de um usuário verificado
O botão de obras deve ser exibido
O botão foi exbidio normal- mente: Passou no teste CDT-03 Verificar se é possível visu-
alizar o botão de obras de um usuário não verificado, após realizar logout do sis- tema com um usuário veri- ficado
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-04 Verificar se é possível visu- alizar o botão de obras de um usuário não verificado, após solicitar o envio do e- mail de verificação
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-05 Verificar se é possível visu- alizar o botão de obras de um usuário não verificado, após solicitar o envio do e- mail de verificação, visuali- zar o e-mail, porém não ati- var a verificação via link.
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-06 Verificar se é possível visu- alizar o botão de obras de um usuário após solicitar o envio do e-mail de verifica- ção, visualizar o e-mail e ativar a verificação via link.
O botão de obras deve ser exibido O botão foi exbidio normal- mente: Passou no teste 3.3.2 Disponibilização 3.3.2.1 Código
Todo o código do sistema desenvolvido pode ser acessado livre- mente através do repositório ’constructmanager’ [55], que está presente
Capítulo 3. Desenvolvimento 72
Tabela 5 – Tela de listagem de obras - Testes realizados
Caso de Teste Descrição Resultado es-
perado
Resultado ob- tido
CDT-01 Verificar se é possível ob- servar uma obra na tela de listagem na qual o usuário não foi atribuído como res- ponsável
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-02 Verificar se é possível obser- var uma obra na tela de lis- tagem na qual o usuário foi atribuído como responsável
A obra deve ser exibida
Obra exibida normalmente na listagem: Passou no teste CDT-03 Verificar se é possível ob-
servar uma obra na tela de listagem na qual o usuário foi inicialmente atribuído como responsável, mas re- movido posteriormente
Não deve ser possível
Não foi possí- vel: Passou no teste
CDT-04 Verificar se é possível ob- servar uma obra na tela de listagem na qual o usuá- rio não foi inicialmente atribuído como responsável, mas foi adicionado posteri- ormente
A obra deve ser exibida
Obra exibida normalmente na listagem: Passou no teste
no agregador de código Github e possui a licensa de distribuição livre do MIT [61].
3.3.2.2 Servidor
Apesar do código disponibilizado, o que faz um aplicativo poder se conectar com um banco de dados específico e realizar as operações necessárias, é a configuração presente no arquivo ’google-services.json’. Este arquivo de configuração possui 2 funções principais: Reproduzir recursos Android que podem ser usados no contexto do aplicativo e adicionar dependências para bibliotecas básicas necessárias para os serviços habilitados (por exemplo, Firebase Realtime Database
Capítulo 3. Desenvolvimento 73
e Firebase Cloud Storage). O repositório disponibilizado no Github não contém o arquivo ’google-services.json’ por motivos óbvios de segurança: Todas credenciais necessárias para acessar o banco estão contidas nele, e cada usuário tem uma disponibilidade limitada de armazenamento gratuito.
Para utilização personalizada do aplicativo por terceiros, é ne- cessário que estes gerem seu próprio arquivo ’google-services.json’ e movam-o para o diretório /app do projeto. Para realizar esta ação, basta cadastrar-se no console do Firebase [28] com qualquer e-mail com domínio gerenciado pelo Google, criar um novo projeto, acessar o menu de configurações e fazer o download do arquivo de configu- ração mais recente, como demonstrado na Figura 54. Em seguida, o arquivo pode ser movido ao repositório e o aplicativo já funcionará escrevendo e lendo informações diretamente no banco de dados de sua propriedade. Lembrando, como o banco segue um modelo não relacio- nal, não é preciso modelá-lo ou inicializá-lo de nenhuma forma, toda modelagem necessária já está feita diretamente no código. Quando as operações de escrita são realizadas, caso a base de dados esteja vazia, os caminhos para os nodos adicionados são criados automaticamente.
74
4 CONCLUSÕES
O desenvolvimento do projeto possibilitou o estudo, a imple- mentação e a disponibilização de uma alternativa gratuita entre ge- renciadores de construções.
Inicialmente, o trabalho abordou o estudo de soluções existen- tes para desempenhar as ações definidas; encontrando algumas opções válidas, porém nenhuma opção viável totalmente gratuita. Em seguida, foi efetuada uma pesquisa sobre fundamentações teóricas relacionadas com o conteúdo do projeto, buscando convergir informações proveni- entes da literatura com os exemplos de implementações encontrados. Logo, foram definidos os objetivos e requisitos do projeto e a implemen- tação do aplicativo foi efetuada, seguindo o guia de desenvolvimento oficial do Android [34] e visando o cumprimento dos objetivos defini- dos. Finalmente, foram realizadas intensas sessões de testes perante o aplicativo desenvolvido, validando as funcionalidades implementadas.
Um ponto fundamental a ser citado é o volume de dados apro- vado gratuitamente pelo Firebase. O armazenamento gratuito máximo do Realtime Database é de até 1 gigabyte, enquanto o volume máximo de downloads mensal é de 10 gigabytes. O Firebase Cloud Storage oferece armazenamento de até 5 gigabytes e largura da banda de 1 gi- gabyte por dia. Situações reais que ultrapassam esses volumes teriam que utilizar um plano não gratuito do banco de dados.
Conforme as informações apresentadas durante a monografia, conclui-se que a aplicação desenvolvida conseguiu cumprir todos ob- jetivos almejados e desempenhar todos requisitos definidos.
4.1 TRABALHOS FUTUROS
O aplicativo desenvolvido funciona adequadamente para con- textos onde obras de pequeno e médio porte são gerenciadas, aonde
Capítulo 4. Conclusões 75
não existe um volume massivo de informações. Situações onde uma grande de quantidade de dados é processada exigiriam uma adequação em alguns módulos do sistema, como por exemplo nas telas de lista- gem. Em contextos com milhares de registros, seria imprescindível as funcionalidades de ordenação e filtragem dos itens, o que ainda não é implementado no projeto em questão. A funcionalidade da inserção de documentos também seria uma implementação viável e interessante à ser desenvolvida para trabalhos futuros, como acrescentado pela banca avaliadora deste projeto.
76
REFERÊNCIAS
[1] R. L. Tucker A. Laufer. “Is Construction Planning Really Doing its Job? A critical examination of focus, role and process”. Em:
Construction Management and Economics(1987).
[2] Edipo Montsech Amorim Alvez. “MÉTODO PARA PLANO DE AÇÃO DE OBRAS ATRASADAS”. Em: (2015).
[3] Android Studio. Google, 2020. Disp. em: https://developer. android.com/studio/intro?hl=pt-br(acesso em 20/01/2020). [4] Android Virtual Device Manager. Google, 2020. Disp. em: https:
/ / developer . android . com / studio / run / managing - avds . html?hl=pt-PT(acesso em 29/10/2020).
[5] App Store. Apple, 2020. Disp. em: https://www.apple.com/ app-store/ (acesso em 30/10/2020).
[6] Arquitetura da plataformar Android. Google, 2020. Disp. em: https://developer.android.com/guide/platform?hl=pt- br(acesso em 03/09/2020).
[7] Asana. 2020. Disp. em: https : / / asana . com/ (acesso em 04/06/2020).
[8] Delmir Peixoto de Azevedo Junior; Renato de Campos. “Defi- nição de requisitos de software baseada numa arquitetura de modelagem de negócios”. Em: (2008). Disp. em: https://www.
REFERÊNCIAS 77
scielo . br / scielo . php ? pid = S0103 - 65132008000100003 & script=sci_arttext.
[9] Steve Easterbrook Bashar Nuseibeh. “Requirements Enginee- ring: A Roadmap”. Em: (2018). Disp. em: https://www.cs. toronto.edu/~sme/papers/2000/ICSE2000.pdf.
[10] Caderno de Encargos. ECivil, 2020. Disp. em: https://www. ecivilnet.com/dicionario/o-que-e-caderno-de-encargos. html (acesso em 06/11/2020).
[11] Canal ObraFit. Google, 2020. Disp. em: https://www.youtube. com/channel/UCr-ynSk2HtK8gxUahPk7gEg(acesso em 30/10/2020). [12] Fanny Chien. “ESTUDO COMPARATIVO DE TÉCNICAS
PARA LEVANTAMENTO DE REQUISITOS DE APLICATI- VOS MÓVEIS”. Em: (2018).
[13] Construct App. 2020. Disp. em: https://constructapp.io/ en/(acesso em 04/04/2020).
[14] Construon. Brasil: Construon, 2020. Disp. em: http://construon. com.br/(acesso em 16/01/2020).
[15] ÍTALO DE OLIVEIRA COSTA. “UMA COMPARAÇÃO EN- TRE MICRO FRAMEWORKS WEB PARA O DESENVOL- VIMENTO DE APLICAÇÕES BACK-END EM JAVA”. Em: (2019). Disp. em: http://repositorio.ufc.br/bitstream/ riufc/49763/1/2019_tcc_ideocosta.pdf.
REFERÊNCIAS 78
[16] Definição de ’validação’. Dicionário Dicio, 2020. Disp. em: https: //www.dicio.com.br/validacao/(acesso em 03/10/2020). [17] Definição de Validação. Conceito, 2020. Disp. em: https://
conceito.de/validacao(acesso em 10/11/2020).
[18] Char Coulin Didar Zowghi. Requirements Elicitation: A Survey
of Techniques, Approaches, and Tools. 2005.
[19] Adriana Coelho Dourado. “Técnicas para o levantamento de requisitos: uma proposta para a obtenção de resultados mais