UNIVERSIDADE FEDERAL DE SANTA CATARINA
Sistema web de suporte ao processo de voluntariado da Iniciativa
Computação na Escola
Gabriel Stedile
Florianópolis - SC
UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE SISTEMAS DE INFORMAÇÃO
Sistema web de suporte ao processo de voluntariado da Iniciativa
Computação na Escola
Gabriel Stedile
Trabalho de conclusão de curso
apresentado como parte dos
requisitos para obtenção do grau
de Bacharel em Sistemas de
Informação
Florianópolis - SC
2019/2
Gabriel Stedile
Sistema web de suporte ao processo de voluntariado da Iniciativa
Computação na Escola
Trabalho de conclusão de curso apresentado como parte dos requisitos
para obtenção do grau de Bacharel em Sistemas de Informação
Orientador(a):
Dr. Jean Carlo Rossa Hauck
Banca examinadora
Prof. José Eduardo De Lucca, Dr.
Resumo
A área da tecnologia da informação tem evoluído rapidamente e se faz presente nas mais diversas áreas da sociedade. No entanto percebe-se um déficit quantitativo e qualitativo de profissionais da área, dentre vários motivos, pela alta demanda de conhecimento técnico inerente da área, rápida expansão do setor no país e das constantes inovações associadas ao mercado de tecnologia. Uma medida possível para se alterar essa situação é gerar interesse e curiosidade pela área ainda na Educação Básica, com matérias relacionadas a tecnologia, como programação e segurança. Para isso, iniciativas com apoio de voluntariado, como a iniciativa Computação na Escola, fortalecem o ensino de computação no ensino fundamental e médio. No entanto, a gestão do processo de voluntariado é complexa. Nesse contexto, o presente trabalho tem como objetivo desenvolver um sistema web com a finalidade de apoiar a gestão do processo de voluntariado. Com base em fundamentação teórica, estado da arte e entrevista com responsáveis, o sistema foi idealizado, desenvolvido, testado e implantado.
Palavras-chave: Sistema Web, Computação na Escola, Gestão de Processos,
Abstract
The area of information technology has evolved fast and is present in the most diverse areas of society. However, there is a quantitative and qualitative deficit of professionals in the area, among many reasons, due to the high demand for inherent technical knowledge of the area, fast expansion of the sector in the country and the constant innovations associated with the technology market. A possible measure to change this situation is to generate interest and curiosity for the area still in basic education, with technology-related subjects, such as programming and security. To this end, volunteer initiatives such as the Computation at School initiative strengthen the teaching of computing in elementary and high school. However managing the volunteering process is complex. In this context, this paper aims to develop and implement a web system to support the management of the volunteering process. Through theoretical foundation and interview with managers, the system was designed and will be developed, tested and implemented.
Keywords: Web System, School Computing, Process Management, Volunteering,
Lista de Figuras
Figura 1 - Fases do ciclo de gestão do voluntariado Figura 2 - Comunicação request-response
Figura 3 - Representação de request HTTP Figura 4 - Representação de response HTTP Figura 5 - Interface do aplicativo Ivolunteer Figura 6 - Interface do aplicativo Samaritan Figura 7 - Interface do aplicativo SignUp Figura 8 - Interface do aplicativo Whentohelp Figura 9 - Interface do aplicativo Yourvolunteers
Figura 10 - Fluxograma do processo de voluntariado - Parte 1 Figura 11 - Fluxograma do processo de voluntariado - Parte 2 Figura 12 - Diagrama de casos de uso
Figura 13 - Protótipo de tela inicial
Figura 14 - Protótipo de tela de Voluntários
Figura 15 - Protótipo de tela de edição de Voluntários
Figura 16 - Diagrama Entidade Relacional do CnE - Volunteer Figura 17 - Mapa mental de concepção do nome da aplicação Figura 18 - Logo com título
Figura 19 - Logo sem título
Figura 20 - Arquitetura geral do sistema Doate Figura 21 - Estrutura de pastas do projeto Figura 22 - Formik
Figura 24 - Axios
Figura 25 - Interface:Typescript
Figura 26 - Tipagem de parâmetros: Typescript Figura 27 - Celebrate
Figura 28 - Nodemailer Figura 29 - Email service Figura 30 - Express Figura 31 - TypeORM
Figura 32 - Doate: Tela Inicial Figura 33 - Doate: Tela de contato Figura 34 - Doate: Email de contato Figura 35 - Doate: Página de login Figura 36 - Doate: Página de Calendário Figura 37 - Doate: RCnE menu
Figura 38 - Doate: CRUD de Instituições Figura 39 - Doate: Nova Instituição
Figura 40 - Doate: Email de cadastro de instituição Figura 41 - Doate: Editar Instituição
Figura 42 - Doate: Novo projeto
Figura 43 - Doate: Exemplo de tabelas Figura 44 - Doate: Novo material
Figura 45 - Doate: Novo material do tipo arquivo Figura 46 - Doate: Novo material do tipo link externo Figura 47 - Doate: Novo usuário
Figura 48 - Doate: Email novo usuário
Figura 49 - Doate: Email novo usuário voluntário Figura 50 - Doate: Tela de cadastro de voluntário
Figura 51 - Doate: Tela de cadastro de voluntário: empresa selecionada Figura 52 - Doate: Tela de cadastro de voluntário: empresa CnE
Figura 53 - Doate: Email de confirmação de cadastro Figura 54 - Doate: Aviso de confirmação de cadastro Figura 55 - Doate: Tela de confirmar cadastro
Figura 56 - Doate: Formulário de cadastro de voluntário Figura 57 - Doate: Exemplo de validação de formulários Figura 58 - Doate: Tela de captura de assinatura
Figura 59 - Doate: Pdf Formulário de cadastro de voluntário Figura 60 - Doate: Primeira etapa de validação concluida
Figura 61 - Doate: Badge de sinalização de validação de voluntário Figura 62 - Doate: Voluntário aguardando instituição
Figura 63 - Doate: Revisão do formulário de cadastro de voluntário Figura 64 - Doate: Formulário de recomendação do voluntário Figura 65 - Doate: Tela de termo de responsabilidade do voluntário Figura 66 - Doate: Terceira etapa de validação concluida
Figura 67 - Doate: Abas de documentos do voluntário Figura 68 - Doate: Calendário inicial do voluntário ativado Figura 69 - Doate: Tela de profile do usuário
Figura 70 - Doate: Novo evento a partir do calendário Figura 71 - Doate: Exemplos de eventos no calendário
Figura 72 - Doate: Novo evento a partir do CRUD de eventos Figura 73 - Doate: Tela de edição de evento
Figura 74 - Doate: Visualizar evento
Figura 75 - Doate: Visualizar materiais do evento Figura 76 - Doate: Avaliar evento
Figura 77 - Doate: Visualizar avaliação de evento Figura 78 - Interface do aplicativo Insomnia Figura 79 - Interface do aplicativo Notion
Figura 80 - Resultados primeira pergunta avaliação: utilidade Figura 81 - Resultados segunda pergunta avaliação: utilidade Figura 82 - Resultados avaliação: SUS
Lista de Tabelas
Tabela 1 - Termos de busca Tabela 2 - Strings de busca
Tabela 3 - Resultado das strings de busca executadas Tabela 4 - Análise de atendimento as funcionalidades Tabela 5 - Requisitos Funcionais
Tabela 6 - Requisitos Não-Funcionais Tabela 7 - Atores e Permissões
Tabela 8 - Rastreabilidade entre os casos de uso e requisitos funcionais Tabela 9 - Detalhamento de caso de uso: UC4 - CRUD de voluntários Tabela 10 - Detalhamento de caso de uso: UC10 - Avaliar mentoria Tabela 11 - Mapeamento Casos de uso e protótipos de tela
Tabela 12 - Cores da identidade visual da CnE Tabela 13 - Cores selecionadas do blog QuickSprout Tabela 14 - Cor selecionada da identidade visual da UFSC Tabela 15 - Lista de avaliadores
Tabela 16 - Respostas da primeira pergunta avaliação: funcionalidade Tabela 17 - Respostas da segunda pergunta avaliação: funcionalidade Tabela 18 - SUS: Pontuação por avaliador
Lista de abreviaturas e siglas
CnE - Computação na Escola
CRUD - Create, Read, Update and Delete
RCnE - Responsável pela Computação na Escola RF - Requisitos funcionais
RFN - Requisitos não funcionais HTTP - Hypertext transfer protocol MVP - Minimum Viable Product
UFSC - Universidade Federal de Santa Catarina AJAX - Asynchronous Javascript and XML JS - Javascript
MIT - Massachussetts Institute of Technology URL - Uniform Resource Locator
ORM - Object Relational Mapping DOM - Document Object Model
SUMÁRIO
SUMÁRIO 12 1. INTRODUÇÃO 14 1.2 Objetivos 19 1.2.1 Objetivo Geral 19 1.2.2 Objetivos Específicos 19 1.3 Metodologia 20 2. FUNDAMENTAÇÃO TEÓRICA 22 2.1 Voluntariado 22 2.2 Aplicação web 25 2.2.1 Tecnologias 27Esta seção trata da apresentação de algumas das principais tecnologias
utilizadas no desenvolvimento da solução. 27
2.2.1.1 Servidor 27 2.2.1.1.1 PostgreSQL 27 2.2.1.1.2 Node.js 28 2.2.1.2 Cliente 28 2.2.1.2.1 React 28 3.1 Protocolo de pesquisa 29
3.2 Execução das buscas 32
3.3 Resultados das buscas: Ferramentas selecionadas 34
3.4 Análise dos resultados 41
4 PROPOSTA DE SOLUÇÃO 44
4.1 Requisitos 44
4.2 Casos de uso 50
4.3 Prototipação de Telas 55
4.4 Modelagem do banco de dados 58
5 DESENVOLVIMENTO 59
5.1 - Processo criativo de concepção do nome 59
5.2 - Identidade visual 61
5.2.1 - Logo 61
5.2.2 - Paleta de cores e fontes 63
5.2.3 - Elementos de interface 64
5.3 - Arquitetura geral do sistema 65
5.3.1 - Cliente: React 67
5.3.2 - Servidor: NodeJS 73
5.4 - Fluxo de telas do sistema Doate 82
5.5 - Insomnia 118
5.6 - Notion 119
6 AVALIAÇÃO DO SISTEMA DOATE 120
6.1 - Definição da avaliação por usuários 120
6.1 - Teste de utilidade 122
6.2 - Teste de funcionalidade 124
6.3 - Teste de usabilidade 127
6.4 - Ameaças a validade da avaliação 129
7 CONCLUSÃO 130
REFERÊNCIAS 133
APÊNDICE A - DETALHAMENTO DOS CASOS DE USO 139
APÊNDICE B - PROTÓTIPO DAS TELAS 146
APÊNDICE C - TERMO DE RESPONSABILIDADE DO VOLUNTÁRIO 150
APÊNDICE D - FORMULÁRIO DE RECOMENDAÇÃO DE CADASTRO DE VOLUNTÁRIO 153
APÊNDICE E - FORMULÁRIO DE CADASTRO DE VOLUNTÁRIO 154
APÊNDICE F - AVALIAÇÃO DA PLATAFORMA DOATE 155
APÊNDICE G - CÓDIGO DA PLATAFORMA DOATE 157
1. INTRODUÇÃO
A área da tecnologia da informação tem evoluído em uma velocidade sem precedentes e se faz presente nas mais diversas áreas da sociedade. Cientistas e empresários renomados como Stephen Hawking e Bill Gates já haviam feito previsões sobre impactos negativos na sociedade, como aumento do desemprego devido à ascensão das tecnologias “Inteligentes”, robótica e algoritmos (BROUGHAM, 2017). Muitas ocupações profissionais que se encontram em risco devido a automação não são necessariamente posições de baixa qualificação: mas sim trabalhos às vezes bem pagos da classe média, muitos desses relacionados ao setor de serviços e/ou associados a tarefas rotineiras que possam ser facilmente automatizadas. Este processo é conhecido como polarização de mercado, com a valorização e disponibilidade crescente de ocupações mais complexas e também de ocupações de baixa habilidade. Em contrapartida, ocupações de média habilidade, que exigem menor formação, registram contração no número de empregados (MACHADO, 2017).
Por consequência, o desenvolvimento da ciência e tecnologia exige desenvolvimento humano para se adequar à própria transformação que o meio vem sofrendo. Torna-se assim necessário que cada vez mais a população não só tenha acesso a informação e tecnologia, como usuário e/ou consumidor, como também tenha condições de avaliar e participar ativamente dessas mudanças (PINHEIRO, 2007).
A Softex publicou artigo apontando um déficit aproximado de 408 mil profissionais de TI até 2020 (SOFTEX, 2018). Esta carência, tanto qualitativa quanto
quantitativa por profissionais da área, gera perdas bilionárias para a indústria do setor. Além disso, esta necessidade é observada tanto no nível nacional como internacional, onde a grande maioria da participação nesse setor é do sexo masculino (SOFTEX, 2018). O desinteresse por parte do sexo feminino é observado desde o momento da escolha do curso de graduação até a conclusão de cursos na área (NUNES, 2015). Nesse contexto entende-se que é necessário entender melhor e desenvolver estratégias diversas e complementares para os diferentes sexos, a fim de se alcançar maiores taxas de inclusão e interesse pela área tecnológica.
Percebe-se que a insuficiência do setor é quantitativa e qualitativa, em virtude, dentre vários motivos, da alta demanda de conhecimento técnico inerente da área, da rápida expansão do setor no país e das inovações constantes que estão associadas ao mercado de tecnologia (BORTOLUZZI, 2018). A baixa qualificação de profissionais se manifesta por exemplo na dificuldade de se trazer resultados satisfatórios para as empresas (OTTE, 2018), além destes não possuírem competências que possibilitem às corporações se inserirem em cenários de negócios com alta competitividade.
Uma medida possível para se alterar essa situação, gerando interesse e curiosidade pela área, seria o contato precoce desde a Educação Básica com assuntos relacionados à tecnologia, como programação, segurança e suporte técnico (WANGENHEIM, 2017). No entanto, outro problema se apresenta diante disso: a disponibilidade de profissionais capacitados para ensinar computação nas escolas (ALVES, 2016). Diversas iniciativas, desde publico-privadas como voluntárias, se apresentam com o intuito de suprir e desenvolver pessoas para o futuro mercado de trabalho.
A iniciativa Computação na Escola (CnE) é realizada por professores e1 pesquisadores do departamento de Informática e Estatística da Universidade Federal de Santa Catarina (INE/UFSC), com o apoio de profissionais voluntários de diversas empresas. A principal meta da iniciativa é ampliar o ensino de computação no ensino fundamental e médio, tornando real a oportunidade de se aprender computação prematuramente . Para tal feito, a CnE realiza o papel de gestão e2 mediação entre as partes interessadas nesse contexto: empresas que desejam contribuir e recomendar seus colaboradores para tais iniciativas; escolas que buscam estimular seus alunos a terem a oportunidade de complementar seu aprendizado com conhecimento tecnológico e inovador; voluntários tanto vinculados a empresas ou até mesmo pessoas que desejam atuar no programa por si própria e que tenham conhecimento ou interesse para participar, sendo neste caso possível se filiar diretamente a iniciativa CnE. Os eventos que a iniciativa promove vão desde treinamentos e geração de conteúdo para todas as partes, como também mentoria e a ação propriamente dita de voluntariado.
O voluntariado é a ação de pessoas que doam seu trabalho e talento para realização de ações de natureza social, possuindo um forte caráter de justiça e equidade social (RAMOS, 2016). Já pela lei brasileira, encontra-se uma definição de voluntariado no decreto Nº 9.906 :
“considera-se atividade voluntária a iniciativa não remunerada de pessoas físicas,
isolada ou conjuntamente, prestada à pessoa física, a órgão ou à entidade da
1http://www.computacaonaescola.ufsc.br/
administração pública ou entidade privada sem fins lucrativos, que tenha objetivos cívicos, culturais, educacionais, científicos, recreativos ou de assistência à pessoa, que vise ao benefício e à transformação da sociedade por meio de ações cívicas, de desenvolvimento sustentável, culturais, educacionais, científicas, recreativas, ambientais, de assistência à pessoa ou de promoção e defesa dos direitos humanos e dos animais.”(BRASIL, 2019)
No entanto, gerenciar um processo de voluntariado para estas iniciativas pode se tornar um desafio, por ser burocrático, demandar tempo e possuir diversas etapas. Além disso, estudos (RAMOS, 2016) sobre voluntariado apontam que, para resultados mais eficazes e retenção dos voluntários nos projetos, uma boa gestão é fundamental e deve ser muito semelhante a uma empresa: deve se preocupar com a vinculação da organização e seus ambientes, além de facilitar os fluxos de informação.
Existem atualmente sistemas para gerenciamento de voluntariado, como por exemplo: ivolunteer , samaritan , signup , whentohelp 3 4 5 6 e yourvolunteers . 7 Entretanto, essas soluções disponíveis, de modo geral, são sistemas genéricos, desenvolvidos de modo a atingir o máximo de clientes possíveis para comercialização. Não foi encontrado um sistema que tivesse funcionalidades
3 https://ivolunteer.com/ 4 https://samaritan.com/ 5 https://signup.com/ 6 https://whentohelp.com/ 7 https://yourvolunteers.com
específicas para as necessidades da CnE e que também se preocupasse em ter um interface moderna de fácil usabilidade. Além disso, todos os sistemas mais robustos encontrados são de código fechado e com diversas funcionalidades pagas.
No intuito de desenvolver um sistema que supra essas necessidades expostas acima, foi desenvolvido um trabalho prévio de TCC (MAESTRI, 2018) onde foi levantado um conjunto de funcionalidades e produzido um protótipo de sistema. No entanto, o resultado desse trabalho produziu um protótipo inicial de sistema, sem contemplar as necessidades de robustez e usabilidade de um sistema para ser colocado em produção e sem abranger todos os requisitos necessários. Assim, é necessário implementar um sistema completo para ser colocado em produção, atendendo a todos os requisitos aprovados pelos responsáveis da CnE, interface web com boa experiência do usuário, e principalmente preocupado com usabilidade e robustez.
A vista disso, espera-se que a existência de uma ferramenta web que automatize o processo completo de voluntariado da CnE facilite a interação empresa-escola como também aumente e retenha o interesse de voluntários nessa iniciativa.
1.2 Objetivos
1.2.1 Objetivo Geral
Analisar, desenvolver e implantar uma aplicação web de gerência do processo de voluntariado para a iniciativa Computação na Escola. A aplicação deve contemplar o cadastro de: empresas, escolas e voluntários; funcionalidade de avaliação de eventos pelas entidades participantes; e a administração geral do processo de voluntariado.
1.2.2 Objetivos Específicos
a) Analisar a literatura e o estado da arte dos sistemas de suporte ao voluntariado; b) Analisar e modelar uma solução técnica para um sistema de suporte ao processo de voluntariado;
c) Desenvolver módulos web responsáveis pelo cadastro de empresas, escolas e voluntários; avaliação de eventos e administração geral dos processos da computação na escola.
1.3 Metodologia
Com o objetivo de alcançar o escopo deste trabalho, foi adotada uma metodologia de pesquisa e desenvolvimento em 5 etapas:
Etapa 1: Investigação da literatura sobre os conceitos essenciais ao tema deste trabalho. Essa etapa é composta pelas seguintes atividades:
Atividade 1.1: Análise da literatura sobre conceitos de gestão de voluntariado. Atividade 1.2: Análise da literatura sobre as tecnologias utilizadas no desenvolvimento de sistemas web, como JavaScript, HTML5, CSS e NodeJS.
Etapa 2: Levantamento e mapeamento sistemático do estado da arte sobre conceitos e gestão do voluntariado. Essa etapa é composta pelas seguintes atividades:
Atividade 1.1: Definição dos termos e estrutura das buscas.
Atividade 1.2: Execução das buscas e seleção de trabalhos relevantes. Atividade 1.3: Análise da apuração dos trabalhos.
Etapa 3: Análise e engenharia de requisitos que atendam as necessidades dos usuários do sistema de voluntariado. Essa etapa é composta pelas seguintes atividades:
Atividade 1.1: Realização de entrevistas com membros e ex-membros da CnE. Atividade 1.2: Análise dos dados obtidos nas entrevistas e reformulação dos requisitos do sistema.
Etapa 4: Modelar e implementar o sistema web de auxílio ao processo de voluntariado da iniciativa CnE. Essa etapa é composta pelas seguintes atividades: Atividade 1.1: Modelagem do banco de dados, classes e funções utilizando diagramas UML.
Atividade 1.2: Modelagem e definição dos protótipos de tela.
Atividade 1.3: Desenvolvimento e implementação dos módulos do sistema.
Atividade 1.4: Testes exploratórios para detecção de problemas no sistema .
Etapa 5: Implantação e avaliação da usabilidade e funcionalidades do sistema. Essa etapa é composta pelas seguintes atividades:
Atividade 1.1: Implantação do sistema em ambiente de produção. Atividade 1.2: Planejamento dos métodos de avaliação.
Atividade 1.3: Execução da avaliação e validação com os responsáveis da iniciativa CnE.
2. FUNDAMENTAÇÃO TEÓRICA
São abordados neste capítulo conceitos teóricos centrais e necessários para compreensão do domínio deste trabalho. Em primeiro momento é apresentado o conceito de voluntariado. Em um segundo momento é debatido aspectos técnicos relacionados a implementação da solução proposta por este trabalho.
2.1 Voluntariado
Tomando base a lei nº 9608/1998 (BRASIL, 1998), o serviço de voluntariado é definido por algumas diretrizes:
1 - É uma atividade não remunerada;
2 - Pode ser prestada por pessoa física ou instituição privada, mas que não tenha fins lucrativos;
3 - Possua caráter e objetivos cívicos, culturais, educacionais, científicos, recreativos ou de assistência social.
Como resultado, tal serviço não gera vínculo empregatício, nem obrigação de natureza trabalhista.
No Brasil, aproximadamente 7.4 milhões de pessoas realizam algum tipo de trabalho voluntário, sendo equivalente a 4.4% da população com mais de 14 anos de idade (DE OLIVEIRA, 2018). Ainda nessa pesquisa, o perfil dos voluntários é prioritariamente de mulheres, 5,1% comparado a 3,5% dos homens. Além disso, a
dedicação ao trabalho voluntário é maior entre as pessoas que possuem alguma ocupação comparado a outros que não são ocupados e existe uma maior porcentagem de participação entre pessoas mais velhas.
Algumas grandes empresas que adotam programas de voluntariado no Brasil pode-se citar: Santander, Bosch e Nextel. Alguns benefícios citados, tanto por empresas como pelos funcionários que participam de ações de voluntariado, são o desenvolvimento de noções de trabalho em equipe, integração e solidariedade. Tais pontos contribuem para um melhor clima organizacional e consequentemente uma melhor produtividade e saúde organizacional (INÁCIA, 2019).
No entanto, assim como existe uma tendência de crescimento do número de pessoas que desejam participar de ações voluntárias, existe um elevado índice de evasão em atividades de voluntariado, que entre alguns fatores, pesquisam apontaram que a principal e possível causa é a utilização de uma gestão não apropriada (OLIVEIRA, 2007).
A gestão do voluntariado é o ato de estabelecer objetivos para atingir a finalidade proposta, se comprometendo com eficácia, eficiência e efetividade de seu voluntariado (RAMOS, 2016). Para que isso ocorra é essencial que a gestão implemente um sistema de regras, supervisão e motivação, tornando possível aproveitar de forma otimizada o potencial do trabalho voluntário.
De acordo com Marcos e Amador (2014), a gestão do voluntariado pode ser analisada com um conjunto de fases bem definidas onde cada uma possui objetivos
e atividades consideradas como práticas promotoras de gestão eficaz e eficiente de voluntariado:
Figura 1 - Fases do ciclo de gestão do voluntariado (MARCOS; AMADOR, 2014).
1 - Tem como objetivo contextualizar o voluntário na organização e na estrutura de sua gestão, tendo como boas práticas a elaboração de um plano de voluntariado e criação de uma ferramenta de gestão que permita replicar os procedimentos em toda a organização.
2 - Define as funções do voluntário, através do mapeamento de perfis sociodemográficos, escolares e profissionais.
3 - Entrada e onboarding do voluntário na organização, realizado através do compromisso de colaboração, definindo direitos e deveres de ambas as partes.
4 - Acompanhamento das atividades do voluntário durante suas ações, onde boas práticas de comunicação com líderes e integrantes do grupo possibilitam um acompanhamento contínuo e a manutenção da satisfação e expectativas e necessidades dos integrantes.
5 - Desenvolvimento de ações de reconhecimento e valorização do desempenho de voluntários, manifestadas de inúmeras formas como certificados, prêmios ou atos públicos.
6 - Consolidação de todas as etapas anteriores e manutenção da relação posterior entre a organização e o voluntário, através processos de orientação da saída e avaliação do voluntariado, além de comunicação regular divulgando novas atividades e convocações.
2.2 Aplicação web
Uma aplicação web pode ser definida como um sistema de informática que utiliza um navegador para acesso e emprega tecnologias web como HTML, Javascript e CSS (APLICAÇÃO WEB, 2019). Se organiza em uma estrutura de arquitetura denominada cliente-servidor, onde o browser é o cliente que solicita requisições ao servidor web, que possui a responsabilidade de processar e devolver esta determinada resposta (DEVMEDIA, 2012).
Figura 2 - Comunicação request-response. (DEVMEDIA, 2012)
O protocolo de comunicação utilizado entre cliente e servidor é o protocolo HTTP, que define a estrutura dos pacotes de comunicação, em outras palavras, quais dados e metadados podem ser inseridos em cada mensagem de request ou
response (ALURA, 2019). Na figura 3 e 4 pode-se observar uma representação das estruturas de request e response respectivamente:
Figura 3 - Representação de request HTTP
Figura 4 - Representação de response HTTP
2.2.1 Tecnologias
Esta seção trata da apresentação de algumas das principais
tecnologias utilizadas no desenvolvimento da solução.
2.2.1.1 Servidor
2.2.1.1.1 PostgreSQL
PostgreSQL é um sistema de gerenciamento de banco de dados objeto-relacional que usa e estende a linguagem SQL. Algumas de suas principais características e pontos fortes são: arquitetura e conjunto de recursos robustos; integridade de dados, manutenção e evolução por parte da comunidade de código aberto . O serviço utiliza a linguagem SQL, popularmente conhecida para inserir,8 acessar e gerenciar o conteúdo armazenado no banco de dados.
2.2.1.1.2 Node.js
O Node.js é um ambiente de execução javascript, que no contexto de modelo de aplicação cliente-servidor, se encontra do lado do servidor. Entre algumas vantagens de sua utilização estão: flexibilidade em instalar dependências para situações específicas; leveza pelo fato de seu ambiente não necessitar de grandes recursos computacionais e utilização de mesma linguagem no frontend e backend, já que javascript é a linguagem padrão para desenvolvimento web (OPUS, 2018).
2.2.1.2 Cliente
2.2.1.2.1 React
O React é uma biblioteca javascript declarativa, eficiente e flexível criada em 2011 pelo Facebook, com a principal função de criar interfaces através da estruturação da aplicação em componentes reutilizáveis. (MEDIUM, 2018) . Outro diferencial é o uso do conceito de Virtual DOM: uma representação de uma árvore de objetos que são comparados com a DOM real no browser nos processos de renderização. Apenas os componentes que tiveram seus estados modificados são re-renderizados, tornando o carregamento e atualização de páginas webs muito mais rápidas e elemento-específicas (IMASTERS, 2019). Está é a definição de Single Page Application - SPA - onde o aplicativo web reage a interação do usuário reescrevendo dinamicamente apenas elementos necessários, ao invés do padrão do navegador carregar páginas novas inteiras após receber ações ou novos dados de um servidor da web (SINGLE PAGE APPLICATION, 2020). Com isso se atinge o principal objetivo que é realizar transições mais rápidas e que façam o site se
comportar como se fosse um aplicativo nativo, oferecendo uma melhor experiência ao usuário.
3. ESTADO DA ARTE
O mapeamento do estado da arte foi realizado por meio de ferramentas de busca na web. Foi utilizado como base de pesquisa o Google Scholar , pois realiza 9 suas buscas em uma grande variedade de bases de dados e possui uma boa funcionalidade de filtros que facilitam a triagem de resultados. Apenas termos em português e inglês foram usados nas buscas, sendo que somente resultados nesses dois idiomas foram analisados. O período de pesquisa está compreendido entre 2015 até 2019.
3.1 Protocolo de pesquisa
De forma a planejar a realização da busca pelo estado da arte, é definido um protocolo de pesquisa, que busca responder a seguinte pergunta de pesquisa: quais e como são as ferramentas de apoio ao processo de voluntariado atualmente disponíveis?
Critérios de inclusão
- O material encontrado deve apresentar features do sistema que possibilitam a análise e enquadramento na resolução das necessidades do sistema de apoio para voluntariado da iniciativa Computação na Escola.
- O material encontrado deve ser específico para gestão de processos de voluntariado em iniciativas de responsabilidade social.
Critérios de exclusão
- Os estudos que não possibilitem o acesso ao sistema serão desconsiderados devido a impossibilidade de se testar funções e interface.
Critérios de qualidade
- Os estudos devem preferencialmente dar soluções e se relacionar com todas as necessidades que o sistema de apoio para voluntariado da iniciativa Computação na Escola deve atender.
- O material encontrado deve utilizar tecnologias recentes (até 5 anos) e levarem em consideração interface e usabilidade do sistema.
Tabela 1
- Termos de busca
Termo Sinônimos Traduções
Sistema Web Aplicativo, Aplicação, Sistema Informatizado, Software
Web System, Application, Computerized System, Software, Gerenciamento
de Processos
Gestão, Controle Process Management,
Management Voluntariado Responsabilidade Social,
Terceiro Setor
Social Responsibility, Corporate Social Responsibility / CSR, Voluntary, Voluntary Sector / Community Sector
Tabela 2
- Strings de busca
Nº String de Busca
Pesquisas por palavras chaves apenas nos títulos
1 allintitle:(("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema Informatizado") AND ("Gerenciamento de Processos" OR "Gestão" OR "Controle") AND ("Voluntariado" OR "Responsabilidade Social" OR "Terceiro Setor")) PERIOD (2015 to 2019)
2 allintitle:(("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema Informatizado") AND ("Gerenciamento de Processos" OR "Gestão" OR "Controle")) PERIOD (2015 to 2019)
3 allintitle:(("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema Informatizado") AND ("Voluntariado" OR "Responsabilidade Social" OR "Terceiro Setor")) PERIOD (2015 to 2019)
4 allintitle:(volunteer management system) PERIOD (2015 to 2019) Pesquisas por palavras chaves livre
5 ("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema Informatizado" OR "Web System" OR "Application" OR "Computerized System" OR "Software") AND ("Gerenciamento de Processos" OR "Gestão" OR "Controle" OR "Process Management" OR "Management") AND ("Voluntariado" OR "Responsabilidade Social" OR "Terceiro Setor" OR "Social Responsibility" OR "Corporate Social Responsibility/ CSR" OR "Voluntary" OR "Voluntary Sector/ Community Sector") PERIOD (2015 to 2019)
6 ("Sistema Web" OR "Aplicativo" OR "Aplicação" OR "Sistema Informatizado") AND ("Gerenciamento de Processos" OR "Gestão" OR "Controle") AND ("Voluntariado" OR "Responsabilidade Social" OR "Terceiro Setor") PERIOD (2015 to 2019)
7 ( "Web System" OR "Application" OR "Computerized System" OR "Software") AND ( "Process Management" OR "Management") AND ("Social Responsibility" OR "Corporate Social Responsibility/ CSR" OR "Voluntary" OR "Voluntary Sector/ Community Sector")
Pesquisas por frases específicas livre
8 Sistema web de apoio a gestão de voluntariado PERIOD (2015 to 2019) 9 Web system to support volunteer management PERIOD (2015 to 2019)
3.2 Execução das buscas
As buscas foram realizadas durante os meses de Maio a Julho de 2019, gerando um total de 11 iterações de buscas.
Tabela 3
- Resultado das strings de busca executadas
Primeira a Nona Execução
A tabela 3 apresenta o resultado das 9 primeiras interações realizadas no google scholar. Foram utilizadas 3 formas de pesquisa:
Nº String de Busca
Pesquisas por palavras chaves apenas nos títulos
1 0
2 7
3 0
4 7
Pesquisas por palavras chaves livre
5 * 1.110.000
6 14.600
7 64.300
Pesquisas por frases específicas livre
8 9.960
1 - Palavras chaves apenas nos títulos dos artigo, onde se mostrou bastante escasso o retorno das buscas - no máximo de 7 resultados, sendo que nenhum destes atendeu aos critérios de inclusão.
2 - Palavras chaves localizadas em qualquer parte do artigo, no qual retornou uma quantidade de artigos na casa dos milhares devido ao fato que muitas das palavras chaves serem comuns nos textos dos artigos, tornando o resultado desse tipo de estratégia de filtragem pouco eficiente.
3 - A pesquisa por frases específicas encontradas de forma livre no artigo se mostrou também pouco eficiente, ao retornar um grande número de resultados que não se adequavam especificamente ao contexto do trabalho.
Tanto o resultado escasso como o retorno de uma grande quantidade de resultados não específicos reforça a dificuldade de encontrar artigos que em seu conteúdo desenvolveram ou analisaram ferramentas de gestão neste setor.
Décima e décima primeira interação
Em razão do escasso resultado retornado pelo google scholar, foi realizado duas iterações de busca no Google , utilizando os termos definidos na tabela 1. A10 décima interação foi com os termos em inglês e décimo primeiro com os termos em português, buscando por ferramentas correlatas.
Após análise da documentação e uso quando possível de versões free ou trials, foi elencada para análise mais profunda 5 ferramentas atuais no mercado:
1 - ivolunteer 11 2 - samaritan 12 3 - signup 13 4 - whentohelp 14 5 - yourvolunteers 15
3.3 Resultados das buscas: Ferramentas selecionadas
Nesta seção são apresentadas as ferramentas encontradas que atendem os critérios de inclusão. 11https://ivolunteer.com/ 12https://samaritan.com/ 13https://signup.com/ 14https://whentohelp.com/ 15https://yourvolunteers.com
1 - Ivolunteer
Figura 5 - Interface do aplicativo Ivolunteer.
O aplicativo possui período gratuito de 30 dias. Como pontos positivos possui um CRUD com muitas opções de configuração, tornando flexível a diversos cenários de gestão de voluntários. Durante a utilização no período free, foi constatado alguns limites de funcionalidade, como máximo de 15 voluntários, caixa de email com espaço de 250 mensagens e possibilidade de apenas 1 administrador. Ivolunteer apresenta uma alta complexidade, pois possui amplo espectro de funções e opções de configuração, exigindo um alto grau de entendimento das opções da plataforma a fim de dominá-la. Algumas funções relevantes são: possui diversos
níveis de perfil de acesso; geração de QR code e upload de arquivos de apoio para eventos; controle de aviso de eventos; Log de atividade desde administrados até voluntários; envio e controle de emails customizáveis através de uma plataforma própria. Trabalha com 3 níveis de assinatura: Free, Standard e Premium, e nas duas últimas faz-se o acesso a mais funcionalidades avançadas, como por exemplo recebimento de pagamentos e doações. Como pontos negativos as contas de voluntários não possuem ids, passwords, sendo que basta cadastrar nome e email se tem acesso a plataforma. Isso pode tornar menos seguro por não possuir tantas informações obrigatórias dos voluntários. Outro ponto é que a aplicação é pseudo responsiva, pois apesar de em janelas e telas menores o site não ter apresentado quebras drásticas de elementos e interfaces, gerou muitas barras de rolagem e distribuição da informação de uma forma pouco efetiva ou atraente. Por fim, não possui visão de acesso das instituições parceiras e avaliação quantitativa dos voluntários e ou dos eventos.
2 - Samaritan
Figura 6 - Interface do aplicativo Samaritan.
O sistema possui 3 níveis de assinatura: Simples, Standard e PRO. Como funcionalidades relevantes possui: número ilimitado de voluntários; envio de email em massa; busca por oportunidades de voluntariado através de diversos filtros e interesses; upload de documentos necessários; controle de horas disponibilizadas em eventos de voluntariado; função intuitiva de controle de agenda utilizando drag and drop. Em versões pagas adiciona algumas opções avançadas como verificação de antecedentes criminais e log de atividades. Como ponto negativo é necessário se submeter a um processo relativamente burocrático apenas para testar a versão free, sendo obrigatório solicitar o demo enviando uma grande quantidade de dados sobre o interessado.
3 - Signup
Figura 7 - Interface do aplicativo SignUp.
O aplicativo possui 3 formas de assinatura: Starter, Plus e Max. Possui uma interface semi responsiva por não demonstrar quebras de elementos em tamanhos de janela menores em browsers ou acesso mobile, mas que gera uma redistribuição da informação e de alguns elementos em tela pouco intuitivos ou agradáveis à experiência do usuário. Como funcionalidades positivas e relevantes têm-se: dashboard com calendário de eventos; envio de email; controle de participantes em cada evento de voluntariado; envio de email como forma de convite e cadastro na plataforma; geração de link compartilhável do evento de voluntariado; função de coleta de contribuições e fundos monetários. Nas versões pagas possui serviço de permissão digital com intuito de minimizar burocracia e a utilização de documentos físicos e também possui o serviço de geração de relatórios dos projetos de voluntariado. Como pontos negativos sua versão free possui muitos anúncios
distribuídos pela interface e o cadastro de usuário é realizado de uma forma pouco segura, necessitando apenas de email, nome e telefone.
4 - Whentohelp
Figura 8 - Interface do aplicativo Whentohelp.
O aplicativo possui duas formas de assinatura: Lite version e Full version. A versão Lite possui um período de 30 dias free e depois possui também um pequeno valor para continuar a utilização. Existem poucas diferenças de funcionalidade entre as duas assinaturas, sendo a diferença maior é no tempo disponível para cada versão: limite de 250 voluntários cadastrados e histórico de no máximo 18 meses na versão Lite. Já sua versão Full estas funções se tornam ilimitadas e ao usuário é permitido salvar mensagens internas por mais de 30 dias, exportar seus dados em diversos formatos de arquivo, entre outras. Algumas funcionalidades relevantes em comum são: perfis de acesso para gerenciadores de eventos e voluntários; sistema de email e notificações de alertas de mensagens; sistema de like e deslike de eventos; função para voluntários adicionar suas habilidades e características em
seu perfil pessoal; possibilidade de acesso de login mobile tanto para coordenadores como para voluntários; analisador de conflito de data e hora entre eventos. Seus principais pontos negativos é que sua versão free possui um limite baixo para quantidade máxima de voluntários, 250 por conta, e também o fato de seu histórico ser de apenas até 18 meses.
5 - Yourvolunteers
Figura 9 - Interface do aplicativo Yourvolunteers.
A plataforma possui 3 planos de assinatura: Free, Premium e Custom. Disponibiliza voluntários ilimitados; possui um tutorial no moldes step-by-steps na primeira vez que um usuário se cadastrar e logar no sistema; apresenta aceite de termos de uso
e resumo de atividades dos usuários além de integração e visualização do calendário do voluntário. A versão free no entanto apresenta muitos anúncios distribuídos pela interface, tornando a experiência do usuário incomoda e poluída. Por fim, o sistema de email está disponível apenas nas versões pagas.
3.4 Análise dos resultados
A fim de analisar os aplicativos elencados, foram especificados alguns requisitos iniciais, tomando como base o TCC anterior da ferramenta (MAESTRI, 2018) e por meio de entrevista presencial com um dos coordenadores da CnE. Abaixo segue a subdivisão destes em requisitos funcionais e não funcionais:
• RF1 - O sistema deve permitir o cadastro de voluntários.
• RF2 - O sistema deve possuir o cadastro de representantes das empresas.
• RF3 - O sistema deve possuir o cadastro de representantes das instituições beneficiadas.
• RF4 - O sistema deve permitir o cadastro de eventos de voluntariado. • RF5 - O sistema deve permitir o cadastro de treinamentos.
• RF6 - O sistema deve permitir a avaliação dos eventos de voluntariado.
• RNF1 - O sistema deve ter todas suas funcionalidades gratuitas. • RNF2 - O sistema deve ter seu código Open-Source.
• RNF3 - O sistema deve ser uma Aplicação web responsiva.
• RNF4 - O sistema deve ter uma interface amigável, norteada por boas práticas de UX Design.
A tabela 4 expõe um quadro comparativo apontando a ocorrência ou ausência dos requisitos básicos acima nos aplicativos do mercado elencados. Temos 4 graus de atendimento de cada requisito:
T - Totalmente atendido P - Parcialmente atendido N - Não atendido
NT - Não testado
Tabela 4
- Análise de atendimento as funcionalidades
Ivolunteer, Signup e Whentohelp possuem RF1 parcialmente atendido por existir uma limitação de quantidade de voluntários cadastrados.
RF2 se apresenta apenas parcialmente como uma funcionalidade possível no
Whentohelp pois é possível definir um controle de perfil que possibilita simular um tipo de perfil diferente. A mesma situação ocorre para o caso da RF3. Todos os outros aplicativos trabalham apenas com a figura de um ou mais administradores que gerem os voluntários que se cadastram aos sistemas.
RF1 RF2 RF3 RF4 RF5 RF6 RNF1 RNF2 RNF3 RNF4 Ivolunteer P N N T P N N N P P samaritan T NT NT T PT N N N P P signup P N N T N N N N P P whentohelp P P P T P T N N P P yourvolunteers T N N T N N N N P P
Para o RF4, todos os sistemas apresentam a funcionalidade, inclusive em em suas versões gratuitas.
Ivolunteer e whentohelp apresentam parcialmente a funcionalidade RF5 de cadastro de treinamentos, pois apesar de não terem a opção de criar eventos de diferentes tipos além do voluntariado, pode-se simular eventos treinamentos através da criação de eventos que tem como anexo de documentos e vídeos utilizados para treinamento.
Das 5 ferramentas elencadas, apenas o Whentohelp apresenta funcionalidades de avaliação de eventos (RF6).
Algumas funcionalidades não puderam ser testadas completamente devido o acesso destas apenas em versões pagas, como é o caso do aplicativo Samaritan. No entanto, para todos os casos, foi consultado nos sites e documentação oficial de cada ferramenta sobre a disponibilidade ou não das funcionalidades elencadas.
Dentre todas as plataformas de gestão analisadas, pode-se observar que
Whentohelp é a que mais se aproxima das necessidades da CnE. Ainda sim não atende uma série de requisitos básicos, como acesso a todos funcionalidades de forma gratuita e possuir interface intuitiva e responsiva.
A análise da stack tecnológica de cada sistema não foi possível ser realizada pois nenhuma das plataformas são de código aberto e em sua documentação não havia material contendo informação sobre esse aspecto.
Diante da análise das plataformas elencadas e de outras possibilidades não citadas no presente trabalho, mas que foram encontradas durante as pesquisas, tem-se o conhecimento de diversas aplicações no mercado que possuem o papel de auxiliar na gestão de processos de voluntariado. Porém nenhuma destas consegue
atender tanto aos requisitos básicos citados acima como outros requisitos que serão adicionados e debatidos ao decorrer deste documento. Dessa forma chega-se à conclusão que é necessário o desenvolvimento e implementação de uma sistema específico para o contexto da iniciativa Computação na Escola.
4 PROPOSTA DE SOLUÇÃO
O processo de elaboração da solução deste trabalho se desenvolve a partir de 4 fases: 1- definição de requisitos funcionais e não-funcionais através da análise do fluxo do processo de gestão de voluntários; 2- levantamento dos casos de uso e seus respectivos detalhamentos; 3 - definição de protótipos de tela; 4 - modelagem inicial de banco de dados.
O objetivo principal da solução é a implementação de um sistema web que tenha o papel de apoiar o processo de gestão de todas as partes que compõem o processo de voluntariado, no contexto da iniciativa Computação na Escola. Para o desenvolvimento deste sistema foi adotado a stack de tecnologia javascript, devido a sua importância no cenário atual de tecnologia web e sua alta capacidade de tornar as páginas interativas (DA SILVA, 2019).
4.1 Requisitos
O levantamento de requisitos da solução foi realizado em 3 etapas distintas. A primeira etapa foi executada por meio de entrevista com o coordenador do projeto, onde foi exposto o domínio geral da necessidade a ser sanada. Além disso, foram apresentadas as expectativas da iniciativa CnE com relação às
funcionalidades que o sistema deve atender, principalmente no que tange a implementação de produto com caráter profissional de uso.
Em um segundo momento foi realizado mapeamento bibliográfico e levantamento de ferramentas existentes no mercado, descritas e elencadas na seção 4.1 deste documento, além do próprio TCC produzido anteriormente que se relaciona com essa solução (MAESTRI, 2018). Logo após, essas fontes foram utilizadas como material de apoio para identificação de novas funcionalidades ou aperfeiçoamento de requisitos previamente levantados na primeira etapa.
Na terceira etapa, com os requisitos e protótipos de telas produzidos através de anotações reunidas na segunda etapa, foram feitas entrevistas com uma pessoa relacionada a CnE e com o coordenador do projeto a fim de validar e confirmar as propostas desenvolvidas.
Ao fim dessas etapas foi produzido o fluxograma de gestão do processo de voluntariado, apresentado em duas partes nas figuras 10 e 11 logo abaixo:
Figura 11 - Fluxograma do processo de voluntariado - Parte 2.
O resultado das 3 etapas foi a definição dos requisitos funcionais apresentado na tabela 5 e dos requisitos não funcionais apresentado na tabela 6:
Tabela 5
- Requisitos Funcionais
Identificação Descrição
RF1 O sistema deve permitir o cadastro do representante da escola na plataforma.
cadastro do representante da escola.
RF3 O sistema deve permitir o cadastro do representante da empresa na plataforma.
RF4 O sistema deve permitir ao RCnE avaliar o formulário de cadastro do representante da empresa.
RF5 O sistema deve permitir ao representante da empresa convidar por email potenciais voluntários.
RF6 O sistema deve permitir o cadastro do voluntário na plataforma.
RF7 O sistema deve permitir ao representante da empresa avaliar a solicitação de vínculo do voluntário à empresa.
RF8 O sistema deve permitir ao voluntário enviar arquivos necessários.
RF9 O sistema deve permitir ao representante da empresa recomendar a inscrição de voluntários.
RF10 O sistema deve permitir ao RCnE avaliar a inscrição de voluntário recomendada.
RF11 O sistema deve permitir ao RCnE criar, editar, deletar e acessar empresas.
RF12 O sistema deve permitir ao RCnE criar, editar, deletar e acessar voluntários.
RF13 O sistema deve permitir ao RCnE criar, editar, deletar e acessar projetos.
RF14 O sistema deve permitir ao RCnE criar, editar, deletar e acessar eventos.
RF15 O sistema deve permitir ao RCnE criar, editar, deletar e acessar escolas.
RF16 O sistema deve permitir ao RCnE anexar documentos aos eventos.
RF17 O sistema deve permitir ao RCnE e Voluntários avaliar treinamentos.
RF18 O sistema deve permitir ao RCnE, representante da escola e voluntários avaliar mentorias.
RF19 O sistema deve permitir ao RCnE acessar histórico de projetos e eventos.
Tabela 6
- Requisitos Não-Funcionais
4.2 Casos de uso
Por meio da análise dos requisitos definidos e do fluxograma apresentado nas figuras 10 e 11, foram identificadas quatro entidades externas que irão interagir com a solução, representando 4 papéis de atores no diagrama de casos de uso. São esses: Responsável na Computação na Escola (RCnE), Representante da escola, Representante da empresa e Voluntário.
Além da identificação dos atores, foram analisados os requisitos funcionais de forma a identificar os casos de uso e, a partir desses, elaborar o diagrama de casos de uso. A figura 12 apresenta o diagrama de caso de uso da plataforma de gestão do voluntariado.
Identificação Descrição
RNF1 O sistema deve ter todas suas funcionalidades gratuitas.
RNF2 O sistema deve ser Open-Source.
RNF3 O sistema deve ser uma aplicação web.
RNF4 O sistema deve possuir design responsivo nas interfaces gráficas.
Figura 12 - Diagrama de casos de uso.
A tabela 7 apresenta o que cada ator representa no mundo real e quais são os casos de uso que cada um respectivamente poderá acessar no sistema.
Tabela 7
- Atores e Permissões
A tabela 8 exibe a relação entre os casos de uso e quais requisitos funcionais estes atendem. Pode-se observar que todos os requisitos nomeados na tabela 5 foram atendidos pelo grupo de casos de uso apresentados na imagem 7:
Ator Descrição Casos de Uso Permitidos
RCnE Representa
coordenadores ou pessoas responsáveis pela gestão da CnE.
UC1 - CRUD de Empresa.
UC2 - CRUD de projetos. UC3 - CRUD de eventos. UC4 - CRUD de
voluntários.
UC6 - Alocar voluntários. UC7 - Avaliar
recomendação de voluntário.
UC8 - Avaliar eventos e projetos.
UC9 - CRUD de escola. Representante da escola Representa a pessoa
responsável na escola pela comunicação e decisões oficiais relacionadas à relação com a CnE.
UC9 - CRUD escola. UC10 - Avaliar mentoria.
Representante da empresa Representa a pessoa responsável na empresa pela comunicação e decisões oficiais relacionadas à relação com a CnE.
UC1 - CRUD de empresa. UC13 - Avalia solicitação de vínculo de voluntário. UC5 - Recomendar voluntário.
Voluntário Representa a pessoa
que irá executar mentorias através das iniciativas da CnE.
UC4 - CRUD de voluntários.
UC12 - Gerar termo de voluntariado.
UC11 - Gerar termo de responsabilidade.
Tabela 8
- Rastreabilidade entre os casos de uso e requisitos
funcionais
As tabelas 9 e 10 a seguir evidenciam com mais detalhamento os casos de uso “CRUD de voluntários” e “Avaliar mentoria”. Demais detalhamento dos casos de uso se encontram no apêndice A.
Casos de uso Requisitos
UC1 RF11, RF4 UC2 RF13 UC3 RF14, RF13, RF16 UC4 RF12, RF5, RF6, RF8 UC5 RF9 UC6 RF9, RF10 UC7 RF10 UC8 RF17 UC9 RF15, RF1, RF2 UC10 RF18, RF19 UC11 RF8 UC12 RF8 UC13 RF7
Tabela 9
- Detalhamento de caso de uso: UC4 - CRUD de voluntários.
Nome do Caso de Uso UC4 - CRUD de voluntários
Pré-Condições Ter a empresa ao qual se vincula cadastrada e solicitação de vínculo aceita.
Atores Envolvidos Voluntário.
Resumo Descreve os passos necessários para que o usuário cadastre um voluntário.
Fluxo Principal - Criar Voluntário
1. O usuário clica em “novo” na página de dashboard de Voluntários. 2. O sistema apresenta uma modal contendo o formulário de cadastro de
voluntário.
3. O usuário preenche os dados necessários. 4. O usuário clica em “salvar”.
5. O sistema salva os dados no banco de dados e envia um e-mail avisando sobre o novo acesso.
Fluxo de Exceção I - Campos obrigatórios não preenchidos
1. No passo 4 do fluxo principal o sistema emite uma mensagem informando que há campos obrigatórios não preenchidos.
Tabela 10
- Detalhamento de caso de uso: UC10 - Avaliar mentoria.
4.3 Prototipação de Telas
Esta seção apresenta alguns protótipos de tela, sendo a relação com seus respectivos casos de uso mapeados na tabela abaixo:
Nome do Caso de Uso UC10 - Avaliar mentoria
Pré-Condições Ter evento com o status “aguardando avaliação”.
Atores Envolvidos RCnE, Representantes da escola e Voluntários.
Resumo Descreve os passos necessários para que RCnE, Representantes da escola e Voluntários possam avaliar o evento de voluntariado.
Fluxo Principal - Avaliar Mentoria
1. O usuário clica no evento a ser avaliado no dashboard de Eventos. 2. O sistema apresenta uma modal contendo os dados do evento, onde um
dos campos é a avaliação do evento. 3. O usuário preenche os dados necessários. 4. O usuário clica em “Avaliar”.
5. O sistema salva a avaliação no banco de dados e retorna uma mensagem de sucesso para o usuário.
Fluxo de Exceção I - Campos obrigatórios não preenchidos
1. No passo 6 do fluxo principal o sistema emite uma mensagem informando que há campos obrigatórios não preenchidos.
Tabela 11
- Mapeamento Casos de uso e protótipos de tela
Logo abaixo são apresentados os protótipos da “Tela inicial” para UC3, “Tela de Voluntários” e “Tela de edição de Voluntários” para UC4. Demais protótipos de tela se encontram no apêndice B.
Figura 13 - Protótipo de tela inicial
Caso de Uso Protótipo de tela
UC3 Figura 13
UC4 Figura 14 e 15
UC2 Figura 21 (Apêndice B)
UC3 Figura 22 E 23 (Apêndice B)
Figura 14 - Protótipo de tela de Voluntários
4.4 Modelagem do banco de dados
Esta seção apresenta o mapeamento das entidades relacionadas ao sistema CnE - Volunteer através do diagrama ER abaixo. O sistema de gerenciamento de banco de dados adotado para o desenvolvimento desta solução foi o MYSQL.
5 DESENVOLVIMENTO
Este capítulo apresenta passo a passo todo o processo de concepção, desenvolvimento e implementação da plataforma Doate. Esclarece decisões de projeto, como por exemplo: seleção da tecnologia empregada; utilização de Designs Patterns; processo criativo do nome; origem das cores e logo empregados na interface visual da web; apresentação da versão final das principais telas referentes ao fluxo central do programa.
5.1 - Processo criativo de concepção do nome
Para criar o nome para a plataforma foi utilizado o aplicativo Whimsical . 16 Esta plataforma é um workspace online que possibilita a criação de wireframes,
flowcharts e mind maps, sendo este último, utilizado como apoio na concepção do nome selecionado neste trabalho. Na figura 17 logo abaixo, pode-se observar que a palavra "Voluntário" é o ponto inicial, e a partir dela realizou-se um processo de
brainstorm de outras palavras e ideias correlatas ao contexto do sistema, considerando que a relação "escolas - empresas - Cne/UFSC" fosse adotada como ideia basal e que fosse remetida no nome final. Tal ideia foi plotada separadamente, ao lado direto no mapa mental, em amarelo.
Figura 17 - Mapa mental de concepção do nome da aplicação
O próximo passo foi uma rodada de novas palavras e ideias correlatas, onde entre algumas possibilidades, optou-se pelo conceito do nome ser uma sigla "simples" e "sonora", o que contribuiria para os usuários lembrarem e reconhecerem facilmente o sistema. Por fim, realizou-se uma última rodada, utilizando anagramas e conexões com base nas palavras previamente plotadas das etapas anteriores. Gerou-se um grande número de opções - a maioria omitidas neste documento devido a sua não relevância - até ser selecionado 4 possibilidades.
Em um primeiro momento, optou-se por selecionar um nome internacional, utilizando a língua inglesa. Dessa forma o sistema foi batizado de "CNE Volunteers". No entanto, mais tarde, durante o desenvolvimento do projeto, buscando encontrar um nome que expressasse mais o significado e conexão com o objetivo da plataforma, executou-se uma nova rodada de reavaliação. Dessa vez, foi considerado também o próprio contexto local de influência e atuação do sistema proposto. Como conclusão optou-se por um nome na língua nativa brasileira que
carregava como principal significado a ideia e sigla para "Doar-se para escola". Assim, o sistema foi rebatizado de Doate.
5.2 - Identidade visual
5.2.1 - Logo
Para criação do logo foi contratado um serviço de designer para criar e entregar um produto profissional. O designer contratado foi Thiago Martins Machado. Primeiro ocorreu uma reunião de alinhamento e explicação do panorama geral do projeto. Além disso, foi repassado quais eram as ideias norteadoras para sua concepção e com qual paleta de cores da identidade visual estariam disponíveis.
Após algumas reuniões de ajustes interativos, foi produzido duas versões finais do logo, uma com título (Figura 18) e outra contendo apenas o logo (Figura 19).
Figura 18 - Logo com título
Figura 19 - Logo sem título
O significado principal que a configuração do logo tem como objetivo passar é a união e comunicação das pessoas envolvidas, o que remete ao processo completo de gestão realizada pelo sistema.
5.2.2 - Paleta de cores e fontes
Para seleção da paleta de cores que foram utilizadas no sistema, foi considerado como base um documento interno oficial da identidade visual da iniciativa computação na escola. Após mapear-se qual grupo de cores que seria necessário para atender todas as demandas da interface, foram elencadas 9 cores. 5 foram retiradas da identidade visual da CnE e mostradas na tabela abaixo:
Tabela 12
- Cores da identidade visual da CnE
Outras 3 cores que eram necessárias e não existiam referência oficial na identidade visual da CnE, foram selecionadas de um artigo no blog QuickSprout, sobre tendências para 2020 de cores para web sites (PATEL, Neil, 2019). Patel é uma das maiores referências na área e mantém esse blog que reúne as principais tendências e novidades sobre marketing digital e websites. Do artigo foram elencadas as seguintes cores:
Tabela 13
- Cores selecionadas do blog QuickSprout
Vermelho Azul claro Verde Laranja Roxo
A última cor foi retirada do manual de identidade visual da UFSC, como referência do sistema a própria instituição:
Tabela 14 - Cor selecionada da identidade visual da UFSC
Para seleção da fonte utilizada no sistema foi respeitada a fonte utilizada na identidade visual da CnE, a Roboto. Esta fonte faz parte de uma família de fontes sem serifa, desenvolvida pela Google que a descreve como "moderna, mas acessível e emocional" (ROBOTO, 2020). É até hoje a fonte padrão no sistema operacional Android.
5.2.3 - Elementos de interface
Com relação ao estilo e efeitos de interação dos elementos web em tela, optou-se a Material-UI , uma das bibliotecas de componentes React mais utilizados 17 para desenvolvimento de aplicativos web responsivos e com base no padrão de design da google, o Material Design . Os motivos para a escolha dessa biblioteca 18 foram :
● Implementa um modelo padronizado e mundialmente conhecido;
17 https://material-ui.com/pt/ 18 https://material.io/design
● Facilidade e agilidade no processo de desenvolvimento;
● Vasta documentação e possibilidade de estilização dos componentes;
● Experiência do autor com esta tecnologia, a fim de minimizar eventuais problemas ou curva de aprendizado para sua implementação.
5.3 - Arquitetura geral do sistema
Figura 20 - Arquitetura geral do sistema Doate
A plataforma Doate foi desenvolvida utilizando a arquitetura cliente-servidor, como mostrado na Figura 20. É considerado uma estrutura de aplicação distribuída, ou seja, as tarefas e cargas de trabalho são distribuídas entre o fornecedor de um recurso/serviço, nesse caso sendo responsabilidade do servidor, e os requerentes desses serviços, o cliente. Observando a figura pode-se notar a visão geral do fluxo de dados:
1 - O usuário acessa o sistema web que para carregar a página inicia o processo de renderização dos componentes. Durante este processo, são necessários dados que
estão no servidor. O React então realiza requisição HTTP através do Axios (5.3.1.3), com o objetivo de carregar estes dados. No contexto de um formulário sendo preenchido pelo usuário, é utilizado o Formik (5.3.1.1) e o Yup(5.3.1.2) respectivamente para controle e validação dos formulários.
2 - O servidor Node recebe e analisa a requisição onde o celebrate (5.3.2.1) realiza a validação dos atributos dentro do corpo da requisição. Caso esteja tudo certo o servidor continua o processamento separando e destinando para a rota correta de serviços disponíveis.
3 - O serviço requerido realiza conexão com o banco de dados PostegreSQL, através do express (5.3.2.3) e do TypeORM (5.3.2.4).
4 - Realizado a query no banco, os dados requisitados são retornados e novamente processados no servidor Node pelo express e pelo TypeORM.
5- Uma vez prontos para serem retornados ao cliente, o servidor retorna a requisição. No caso deste trabalho existem cenários onde nesse momento são enviados emails pelo nodemailer (5.3.2.2) para certos destinatários.
6 - Por fim, o cliente React recebe a resposta da requisição, se necessário este realiza algum processamento ou limpeza nos dados, termina o processo de renderização dos componentes e mostra em tela para o usuário.
Para escolha e utilização de cada tecnologia e solução foram levados em consideração três requisitos por ordem de importância:
- Ferramenta free;
- Domínio de conhecimento prévio ou que tinha baixa curva de aprendizado por parte do autor do trabalho a fim de manter um processo de
desenvolvimento ágil e efetivo.
Nos próximos tópicos será desenvolvido as principais partes e tecnologias do sistema, elucidando suas respectivas funções e responsabilidades.
5.3.1 - Cliente: React
O projeto front end foi desenvolvido com a biblioteca Javascript React. Tem como principal função facilitar a criação de elementos das páginas e seu controle de renderização de acordo com a necessidade.
Figura 21 - Estrutura de pastas do projeto
● node_modules -> Pasta que contém as dependências e bibliotecas instaladas e utilizadas no projeto.
● public -> Contém a página html principal que será carregada no browser e outros arquivos como o favicon do site.
● src/assets -> Contém todas as imagens e recursos locais utilizados no site, como por exemplo o logo.
● src/components -> Pasta referente a todos os componentes React criados ou separados para utilização e/ou re-utilização. Como exemplo
