Desenvolvimento e Avaliação do Sistema de Apoio a Gestão de
Compras e Almoxarifado da Universidade Federal Rural da
Amazônia
Allan J. de A. Santos1, Antônio Lobato1, Alexandre Melo1
1Universidade Estácio de Sá (Estácio-FAP)
66050-350 – Belém – PA – Brasil
{allanjh,alobato,alexmelo}@gmail.com.br
Abstract. This paper deals with the development and evaluation of the support system for the purchasing and warehouse management of the Federal Rural University of Amazonia. The development was carried out based on the agile methodology Extreme Programming and the evaluation realized through the application of questionnaires made based on an exploratory model of success in information systems in order to capture the view of the users regarding the developed system. After analyzing the data obtained from the questionnaires, it was verified that there was success in its implementation, although there are points that must be observed to ensure the continuity of the good functioning of the system. Resumo. Este artigo trata do desenvolvimento e avaliação do sistema de apoio a gestão de compras e almoxarifado da universidade federal rural da Amazônia. O desenvolvimento foi realizado utilizando com base a metodologia ágil Extreme Programming e a avaliação do mesmo realizada através da aplicação de questionários confeccionados com base em um modelo exploratório de sucesso em sistemas de informações de modo a captar a visão dos usuários quanto ao sistema desenvolvido. Após a análise dos dados obtidos dos questionários foi verificado que houve sucesso na sua implementação, apesar de haverem pontos que devem ser observados para assegurar a continuidade do bom funcionamento do sistema.
1. Introdução
O setor privado tem passado por grandes mudanças nos últimos anos, desde a globalização e mais intensamente com a chegada da internet, e recentemente, os dispositivos móveis, o nível de competitividade entre as empresas vem se intensificando cada vez mais. Desta maneira, por estarem nesse cenário de ampla concorrência, as empresas da iniciativa privada estão sempre em busca de mais eficiência e foco nos resultados para garantir sua sobrevivência.
Em contrapartida, no setor público, apesar de não se ter a ampla concorrência para gerar a urgência por eficiência e resultados favoráveis, se tem fatores que corroboram para que haja a adoção de novos princípios gerenciais que levem empresas e órgãos públicos a serem mais eficientes. Para Ching, Silveira, & Freire (2011) a Lei Complementar nº101/2000 [Brasil 2000], conhecida como Lei de Responsabilidade Fiscal é considerada um divisor de águas na administração pública, e acrescenta que as empresas e os órgãos do setor público têm
procurado adotar práticas e instrumentos de administração do setor privado, a fim de obter maior capacidade gerencial.
Oliveira et al. (2015) cita que A Nova Contabilidade Pública contribui para que o setor público incorpore os princípios gerenciais de eficácia, eficiência e avaliação de resultados, que são práticas de administração da iniciativa privada, a fim de se obter maior competência gerencial.
Outro ponto importante é a adoção da tecnologia de informação na administração pública. Para Mota, Oliveira Júnior e Freitas (2016) os sistemas de informação são essenciais em todos os âmbitos da administração pública pois eles garantem agilidade, confiabilidade e qualidade das informações geradas.
Neste contexto de busca por eficiência e adoção de novas práticas gerenciais dentro do setor público, a Superintendência de Patrimônio e Materiais (SPM) da Universidade Federal Rural da Amazônia (UFRA) decide então, adotar uma ferramenta que facilite a sua gestão, ao mesmo tempo que proporcione maior eficiência, controle e agilidade ao processo.
O desenvolvimento da ferramenta se justifica devido a SPM ser um setor de fundamental importância dentro UFRA, ele é responsável por suprir todas as necessidades de materiais que a instituição possa ter, desde os alimentos para o restaurante universitário até suprimentos para impressoras e resmas de papel utilizados dentro das dependências da UFRA. Além disso o sistema parte de uma iniciativa da própria SPM que sente a necessidade de modernizar seu processo interno, que antes da implantação do sistema de apoio tinha como características: ser um sistema predominantemente manual, com controles de itens comprados não padronizado, com dificuldade de emissão de relatórios gerenciais e com informações não centralizadas, dificultando assim a gestão da mesma.
Este artigo tem como objetivo o desenvolvimento e avaliação do software de apoio a gestão de compras e almoxarifado da UFRA. Para o desenvolvimento do software foi tomado como base o Extreme Programming (XP) como metodologia a ser seguida, foi dada preferência para ferramentas e tecnologias de uso livre, como também observados a adequação das mesmas a infraestrutura de rede já existente na universidade. Para a realização da avaliação do software desenvolvido foram aplicados questionários aos usuários do sistema, questionários estes baseados no modelo exploratório sugerido por Oliveira et al. (2015), com o objetivo de avaliar se, de acordo com a visão dos usuários a adoção do software obteve sucesso.
2. Referencial Teórico
Tanto para o desenvolvimento do software, quanto para a avaliação do mesmo, foram buscadas na literatura especializada, as bases para sua execução. O processo de desenvolvimento de software possui uma literatura vasta, cobrindo desde modelos de processos mais genéricos até modelos de processos construídos para um fim específico. Para este artigo são referenciados apenas os modelos que foram utilizados para dar base ao processo de desenvolvimento do software em questão.
Quanto a avaliação do software na literatura, há várias metodologias de avaliação, porém em sua maioria de forma genérica e aplicada a sistemas de informação de empresas
privadas, para a avaliação realizada neste artigo, foi dada a preferência para trabalhos que fossem aplicados a administração pública.
2.1 Metodologia de Desenvolvimento de Software
Muitos processos de desenvolvimento de software (ou metodologias de desenvolvimento) foram criados e adaptados ao longo do tempo, podendo ser divididos em: formais ou clássicos e as metodologias ágeis. Dentro dos processos clássicos o mais conhecido é o modelo cascata, que é caracterizado pela divisão do projeto em etapas em sequência linear, sendo que uma etapa depende do término da anterior para iniciar [Martins 2016].
As metodologias tradicionais são consideradas rígidas e burocráticas e devido às limitações existentes, surgiram então as metodologias ágeis. Estas, emergiram em 2001 a partir de uma reunião de dezessete especialistas em desenvolvimento de software, que culminou no manifesto ágil, que conta com 12 princípios norteadores que trazem 4 premissas: indivíduos e interação mais que processos e ferramentas, software em funcionamento mais que documentação abrangente, colaboração com o cliente mais que negociação de contratos e responder a mudanças mais que seguir um plano [Agile Manifesto 2018].
Os modelos ágeis são coleções de boas práticas e princípios de engenharia de software. Apesar destes princípios não serem novos dentro da indústria de software, dentro dos modelos ágeis eles são utilizados com uma diferente abordagem, tornando-os mais flexíveis e adaptáveis. Dentre os modelos ágeis existentes pode-se destacar: Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software Development (LSD), entre outros. [Anwer et al. 2017]
Para este artigo será dado enfoque no XP, pois é a metodologia utilizada como base para o desenvolvimento do software em questão. Além do XP, serão abordados alguns conceitos relativos a modelagem de software.
2.1.1 Extreme Programming - XP
Segundo Nunes (2016) o XP é caracterizado por ser uma metodologia de desenvolvimento de software voltada para projetos cujos requisitos são vagos e mudados com frequência, com sistemas orientados a objetos, que possuem uma pequena equipe de desenvolvimento, o desenvolvimento se dá de maneira incremental e por ter o envolvimento do cliente em níveis “extremos”.
Para tanto o XP conta com 5 valores fundamentais e 12 práticas que o distingue de outras metodologias [Anwer et al 2017]. Os valores estão listados abaixo e as 12 práticas estão contidas na Tabela 1.
Comunicação: Entre a equipe e o cliente de modo que detalhes do projeto sejam
tratados com atenção e agilidade;
Simplicidade: Implementar apenas aquilo que é suficiente para atender a cada
Feedback: O cliente reavalia suas necessidades conforme ele aprende com o sistema, desta maneira ele dá um feedback para a equipe;
Coragem: A equipe precisa acreditar que as práticas e valores do XP irão gerar um
software de qualidade, com segurança e agilidade e;
Respeito: Respeito a si mesmo e aos outros é necessário para a correta implementação
das práticas do XP.
Tabela 1. As 12 Práticas do XP. Fonte: adaptado de Anwer et al. (2017)
Pequenas Releases: Cada release terá uma porção dos requisitos de modo que seja
possível avaliação por parte do cliente e tenha valor para o mesmo.
Feedback: O cliente reavalia suas necessidades conforme ele aprende com o sistema, desta maneira ele dá um feedback para a equipe;
Metáfora: É a utilização de termos mais amigáveis e compreensivos ao invés de termos
técnicos, facilitando assim a comunicação dentro do projeto;
Projeto Simples: O projeto deve ser simples, focado nos requisitos atuais e não nos
futuros.
Teste Contínuo: O XP usa teste unitário e teste de aceitação continuamente.
Refatoração: É a reestruturação do sistema sem mudar seu comportamento. No XP, os
desenvolvedores melhorarem contínuamente a qualidade do código é uma atividade de rotina.
Programação em Pares: No XP, a codificação é realizada por dois programadores em
uma única máquina. A ideia é desenvolver um código de alta qualidade a um alto custo, já que a maioria dos erros serão corrigidos pelo programador que estará auxiliando aquele que estará no controle do teclado.
Propriedade Coletiva: No XP, qualquer programador pode acessar qualquer parte do
código a qualquer momento e melhora-lo, desde que faça a bateria de testes necessárias após a mudança.
Integração Contínua: Após o término de uma tarefa, o sistema é integrado e testado,
isso pode ocorrer várias vezes no mesmo dia. Reduzindo os problemas de integração e garantindo a qualidade do software.
40 Horas Por Semana: O XP desencoraja o uso de horas extras constantemente.
Programadores cansados e entediados cometem mais erros, por isso o XP coloca a regra de trabalhar apenas 40 horas por semana.
Cliente Sempre Disponível: No XP, um representante do cliente faz parte do time está
disponível o tempo todo.
Padrão de Codificação: Dentro do XP o código pode ser acessado e mudado por
qualquer um dos programadores, para tanto é necessário que sejam seguidos padrões de codificação.
2.1.2 Modelagem de Software
A atividade de desenvolvimento de software possui uma complexidade ímpar, Pressman e Maxim (2016) a descrevem como, desafiadora, criativa e divertida. A parte mais difícil é decidir o que construir, para tanto é necessário que haja um perfeito entendimento daquilo que o cliente deseja.
Para descobrir então aquilo que o cliente necessita são utilizadas técnicas de engenharia de requisitos, a qual abrange sete tarefas distintas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão dos requisitos. Estas atividades podem ocorrer de forma paralela e devem ser adaptadas as necessidades do projeto [Pressman e Maxim 2016].
Requisitos podem ser definidos como descrições de serviços fornecidos pelo software e as suas restrições operacionais, podem ser classificados como requisitos funcionais e requisitos não funcionais. Os requisitos funcionais descrevem o que o sistema deve fazer e se comportar mediante a certos eventos, os requisitos não funcionais podem ser descritos como um atributo de qualidade, de desempenho, de segurança ou como uma restrição geral de um sistema [Pressman e Maxim 2016].
Após a extração dos requisitos há a necessidade de melhor representa-los, apesar da escrita ser um bom veículo de comunicação ela não é a melhor maneira de representar requisitos de um software e para isso é utilizada a Unified Modeling Language (Linguagem de modelagem unificada - UML).
A UML é uma linguagem visual baseada no paradigma de orientação a objetos e tem como objetivo auxiliar os engenheiros de software a modelar, definindo as características do sistema o qual estão trabalhando [Guedes 2018]. A UML compreende uma grande quantidade de diagramas, cada um analisa o sistema ou parte dele de uma determinada perspectiva, sempre um complementando o outro, esta multiplicidade de visões permite que falhas sejam encontradas, diminuindo a ocorrência de erros futuros.
A utilização dos diagramas depende da complexidade de cada projeto, não sendo necessária a utilização de todos os diagramas dentro de um projeto, apenas se for julgado necessário. Dentre os diagramas existentes pode-se citar: Diagrama de Classes, de Casos de Uso, de Atividades, de Sequência, de Objetos, de Componentes etc.
Os diagramas utilizados neste artigo foram:
Diagrama de Casos de Uso: É um diagrama geral e informal, consultado durante todo o processo de modelagem e serve como base para outros diagramas. Procura identificar atores e as respectivas funcionalidades disponibilizadas [Guedes 2018]. Um exemplo do mesmo pode ser visto na Figura 2.
Diagrama de Classes: É o diagrama que define a estrutura das classes utilizadas pelo sistema, seus atributos, métodos e relacionamentos. É um dos mais utilizados e um dos mais importantes [Guedes 2018]. Um exemplo do mesmo pode ser visto na Figura 6.
Diagrama de Atividades: Para Pressman e Maxim (2016) o diagrama de atividades complementa o de casos de uso ao fornecer uma representação gráfica do fluxo de interação
em um cenário específico, é muito semelhante a um fluxograma. Um exemplo do mesmo pode ser encontrado na Figura 7.
Outro ponto importante dentro da modelagem de um software é o banco de dados, o local onde será armazenado as informações oriundas do software. A técnica mais difundida quanto a modelagem de dados é a modelagem Entidade-Relacionamento (ER). A UML, como mencionado anteriormente, é baseada no paradigma orientado a objetos, por isso não possui uma notação específica para banco de dados, já que a grande maioria dos bancos de dados são relacionais.
O modelo ER segundo Machado (2018) descreve a estrutura conceitual e lógica geral de um banco de dados, objetivando a definição do contexto dos dados em que o sistema funciona. Para tanto são definidos três elementos: entidades, relacionamentos e atributos.
As entidades são quaisquer coisas do mundo real que se deseje armazenar informações sobre. Os relacionamentos são os relacionamentos entre essas coisas, estes relacionamentos podem ocorrer de forma direta ou depender da associação de outras entidades. Os atributos são as características de uma entidade ou relacionamento, as informações que se pretende armazenar destes [Machado 2018]. Um exemplo de diagrama ER pode ser visto na Figura 5.
2.2 Avaliação de Software
Segundo Alipour et al. (2017), dada a complexidade que envolve os sistemas de informação (SI), pode-se encontrar casos de sucesso e fracasso em todo lugar, que o desenvolvimento de software, mesmo nas melhores condições é gradual, demorado, envolve alto custo e tem um impacto muito grande nas organizações quando implantado, por isso é crítico que se faça uma avaliação do mesmo, principalmente em termos de satisfação do usuário.
Para a realização da avaliação é necessário o desenvolvimento de métricas em observância aos contextos específicos e aos atores envolvidos, para tanto são sugeridos vários modelos de sucesso de SI, sendo que segundo Oliveira et al. (2015), o principal deles é o sugerido por Delone e McLean, que sugere um modelo com seis construtos, a saber, qualidade da informação, qualidade do sistema, qualidade do serviço, uso, satisfação do usuário e benefícios líquidos do uso.
Como se pode notar, apesar de a mensuração do sucesso de SI se tornar cada vez mais complexa devido ao crescente uso e aumento do número de usuários, a sua essência ainda é simples, pois existem elementos-chave consistentes, como a qualidade da informação, qualidade de sistemas, uso e resultados que permanecem sendo a chave para o sucesso de SI [Olivera et al 2015].
Para a avaliação de SI em instituições públicas Oliveira et al. (2015) sugere um modelo contendo 6 construtos, baseado nos modelos de Delone e McLean e Gable et al., porém adequando-os para a realidade da administração pública, como pode ser visto na Figura 1.
Figura 1. Construtos Sugeridos para Avaliação de SI na Administração Pública Fonte: Oliveira et al. (2015)
Os construtos sugeridos por Oliveira et al. (2015) são:
Suporte da alta gestão: É o fator mais importante para o sucesso do projeto. Um
projeto que tenha suporte da alta gestão pode resolver os problemas persistentes do fracasso do projeto de TI.
Qualidade do Sistema: Está relacionada a facilidade de uso, flexibilidade,
confiabilidade e segurança. Um dos pontos mais importantes é a navegação dentro do sistema e a segurança das informações pessoais dos usuários.
Qualidade da Informação: A informação apresentada pelo sistema deve ser
relevante, compreensível, precisa, concisa, integral, pontual e útil.
Qualidade do Serviço: É a qualidade do apoio que os usuários do sistema recebem
por parte do departamento de SI.
Benefícios em Processos: Está ligado geralmente a quatro aspectos, a saber,
diminuição de custos, confiabilidade, precisão e disponibilidade.
Benefícios Institucionais: Está relacionado ao custo/benefício de adoção do sistema
por parte do órgão público.
3. Metodologia
Como já mencionado anteriormente, as metodologias utilizadas neste artigo foram baseadas na literatura encontrada e foram aplicadas de modo que se adaptem ao ambiente em que o sistema foi desenvolvido e implantado. Abaixo estão descritas as metodologias utilizadas para o desenvolvimento do software quanto para a avaliação do mesmo.
Para o desenvolvimento do software foram consideradas algumas características no momento da escolha das tecnologias e ferramentas utilizadas, a saber: adequação a infraestrutura de rede já existente na universidade e utilização de tecnologias e ferramentas de uso livre.
Sendo assim o software foi desenvolvido utilizando tecnologias baseadas em web, utilizando a rede interna já existente. Desta maneira foram utilizadas: PHP e Python como linguagens de back-end, AngularJS para o front-end e MySQL como banco de dados. Para a escrita do código foram utilizados o NetBeans para o PHP, VSCode para o AngularJS e o PyCHarm que apesar de ter sua versão comercial, possui versão de uso livre para Python.
A linguagem Python foi utilizada para a escrita de scripts que capturam os dados referentes a um determinado pregão eletrônico no portal de compras governamentais [Portal de Compras 2018], ela foi escolhida pois já possui várias bibliotecas e frameworks disponíveis para esse fim, além de material de apoio e comunidade ativa que auxiliam no desenvolvimento.
O PHP foi escolhido pois além de ser uma linguagem de uso livre, ela é uma tecnologia web, a qual se adequa facilmente a infraestrutura de rede existente na universidade, existe facilidade de encontrar profissionais que a utilizam e uma ampla comunidade ativa que auxilia caso exista algum problema a ser resolvido.
O AngularJS foi escolhido pelo fato de ter uma curva de aprendizado baixa e ter um grande poder de desenvolvimento de front-end, o que facilita a construção de telas mais amigáveis, ocasionando uma boa experiência para o usuário.
O MySQL foi escolhido pelo fato de ser uma tecnologia de uso livre e pelo fato de ser já conhecida pelo desenvolvedor, o que garante maior agilidade no desenvolvimento e maior qualidade no produto final obtido através do uso da ferramenta.
A coleta de requisitos foi realizada através de entrevistas e análise de documentos que serviriam de modelo para a produção dos artefatos gerados durante os processos que compõem a SPM, como ata de preços, autorização de compra, extrato de compra etc.
A metodologia de desenvolvimento utilizada foi baseada no XP, das doze práticas da referida metodologia apenas duas não foram utilizadas, a Programação em Pares, pois o desenvolvimento foi realizado por apenas um programador e a Refatoração, devido a prioridade no desenvolvimento de novas funcionalidades preencher todo o tempo do único desenvolvedor.
Quanto as demais, o desenvolvimento foi realizado no próprio cliente, tendo este sempre disponível para tirar dúvidas. As entregas aconteceram de forma iterativa, cada iteração durando em média uma semana, sempre com Pequenas Releases e estas sempre com entrega de algo funcional que pudesse ser testada pelo próprio cliente, que após testar as funcionalidades entregues dava o Feedback quanto a entrega, caso fosse necessária alguma correção esta era priorizada na próxima iteração e entregue, caso fosse aceita esta era integrada ao software como um todo, realizando assim a Integração Contínua.
Os requisitos das iterações foram sempre escolhidos pelo cliente e o desenvolvimento foi sempre focado nos requisitos atuais, o código podia ser acessado e mudado por qualquer pessoa que fazia parte do projeto, desde que mantivesse o padrão de codificação e não foram realizadas horas extras durante o desenvolvimento.
3.2 Avaliação do Software
A avaliação do software implantado se faz necessária para assegurar que os objetivos que foram traçados para ele foram alcançados. E se estes foram alcançados, se o foram da melhor maneira, através de software confiável, com boa usabilidade, com baixa curva de aprendizado etc.
Para a realização desta avaliação, foi tomado como base o trabalho realizado por Oliveira et al. (2015) que sugere um modelo exploratório de avaliação de pós-adoção de sistemas de informações (SI) na administração pública, neste modelo o autor elenca construtos, retirados da literatura, que influenciam no sucesso quanto a adoção de SI e o adapta para a realidade da administração pública, os construtos e uma breve descrição dos mesmos pode ser visto na Tabela 2.
Para esta pesquisa foram utilizados apenas 4 construtos dos que foram sugeridos, os dois construtos não contemplados são: Suporte da Alta Gestão e Qualidade do Serviço. O primeiro pelo fato de o desenvolvimento do software partir de uma iniciativa da própria gestão da SPM, que além da iniciativa prestou suporte quanto a local, material e estrutura para que o projeto fosse executado, o que sugere total suporte da mesma, sem a necessidade de realizar uma pesquisa mais aprofundada quanto a este construto. Quanto ao segundo, que é qualidade do serviço, este não se aplica, pois o suporte de Tecnologia de Informação (TI) oferecido a SPM quanto ao software desenvolvido é realizado pelo próprio desenvolvedor, ou seja, não há suporte oficial.
Tabela 2. Modelo Exploratório de Sucesso de SI na Administração Pública. Fonte: adaptado de Oliveira et al. (2015)
O questionário foi elaborado e este aplicado aos servidores que trabalham diretamente com o software desenvolvido. Cada pergunta foi criada para ser direta, relacionada a um construto elencado pelo modelo sugerido e utilizando a Escala Likert que varia de 1 a 5 para obtenção das respostas [Souza et al. 2016]. Deste modo, a avaliação do software se dará a partir de uma análise quantitativa das respostas obtidas da aplicação dos questionários.
4. Resultados
Os resultados referentes ao desenvolvimento de software foram obtidos após alguns meses de desenvolvimento. A implantação ocorreu assim que as funcionalidades referentes ao perfil de divisão de compras estavam quase todas desenvolvidas, faltando apenas alguns relatórios. Quanto a avaliação, ela se deu após pouco mais de um ano após a implantação.
4.1 Desenvolvimento de Software
O sistema desenvolvido dividiu os usuários em perfis de acordo com o setor em que trabalham e um perfil geral para o superintendente, de modo que os colaboradores de cada setor tenham acesso apenas às funcionalidades de seu setor e o superintendente consiga ter acesso a todas as funcionalidades do sistema, de acordo com os requisitos passados pelo cliente, presentes na Tabela 3. Sendo assim o sistema conta com uma tela de login que autentica os usuários, identificando-os em 4 perfis de acesso: Divisão de Compras, Divisão de Patrimônio, Divisão de Almoxarifado e Superintendente, conforme Figura 2.
Tabela 3. Tabela de Requisitos Fonte: autor (2018)
Requisitos Funcionais
RF001 O sistema deve restringir o acesso ao sistema a usuários previamente cadastrados.
RF002 O sistema deve permitir que os usuários acessem apenas as funcionalidades adequadas a seu perfil, vinculado no momento do cadastro.
RF003 O sistema deve permitir que o perfil do Superintendente tenha acesso a todas as funcionalidades do sistema.
RF004 O sistema deve permitir Manter Usuários. RF005 O sistema deve permitir Manter Licitações.
RF006 O sistema deve permitir a importação dos dados de Licitações do site “www.comprasgovernamentais.gov.br”.
RF007 O sistema deve permitir Manter Fornecedor. RF008 O sistema deve permitir Manter Ata de Licitação. RF009 O sistema deve permitir Manter Autorização de Compra. RF010 O sistema deve permitir Manter Empenhos.
RF011 O sistema deve permitir a importação dos dados de Empenhos do site “www.portaldatransparencia.gov.br”.
RF012 O sistema deve permitir Manter Entrada de Material.
RF013 O sistema deve permitir a emissão de Relatórios de Licitações.
RF014 O sistema deve permitir a emissão de Relatórios de Autorizações de Compra. RF015 O sistema deve permitir a emissão de Relatórios de Entrada de Material. RF016 O sistema deve permitir a emissão de Relatórios de Atas.
RF017 O sistema deve permitir a emissão de Relatórios de Entrada de Material. RF018 O sistema deve permitir a emissão de Relatórios de Empenho.
RF019 O sistema deve permitir a emissão do Extrato por Fornecedor
Requisitos Não Funcionais
RNF001 O sistema deve ser executado nos navegadores Mozilla Firefox ou Google Chrome.
RNF002 O sistema deve utilizar a rede local já existente para ser executado.
RNF004 O sistema deve ser desenvolvido utilizando tecnologias de uso livre.
Após a autenticação do usuário, este é redirecionado para uma página inicial onde ele tem acesso às funcionalidades pertinentes ao seu perfil e por questões de segurança, todas as ações do mesmo passam a ser gravadas no banco de dados de modo a saber quais páginas foram acessadas e quais ações foram executadas pelo usuário dentro do sistema. Esta funcionalidade dá maior segurança e permite que haja auditoria do que acontece dentro do sistema.
Como mencionado acima, o Superintendente terá acesso a todas as funcionalidades do sistema. Além das funcionalidades disponíveis aos outros perfis, será o responsável por cadastrar os usuários, atribuindo a estes o perfil correto, assim como terá a responsabilidade por manter as licitações (criar, ler, editar e excluir licitações), processo realizado por meio da importação dos dados da licitação, oriundos do portal de compras do governo [Portal de Compras 2018].
Figura 2. Diagrama de Casos de Uso Fonte: autor (2018)
O perfil de Divisão de Compras possui acesso às funcionalidades relacionadas as compras dos itens licitados e relacionamento com fornecedores, como pode ser visto na Figura
3. Dentro de relacionamento com fornecedores há a manutenção do cadastro dos mesmos, que deve ser realizada para que seja possível a correta confecção dos documentos de vínculo jurídico entre estes e a universidade (Ata de registro de preços ou Contrato) e ainda, a geração do extrato para publicação no Diário Oficial. Os documentos são gerados pelo sistema, utilizando os modelos oficiais regimentados pela UFRA.
Vale ressaltar que a tela de acompanhamento de pregão eletrônico foi desenvolvida de modo a se conseguir saber como está o andamento do processo de licitação apenas ao olhar para a mesma, como pode ser visto na Figura 3. Conforme o processo segue, as opções vão trocando de cor de forma que facilmente se consegue saber como está o andamento do processo de determinada licitação.
Figura 3. Tela de Acompanhamento de Pregão Eletrônico Fonte: autor (2018)
Figura 4. Tela de Autorização de Compra Fonte: autor (2018)
Os perfis de Divisão de Almoxarifado e Divisão de Patrimônio possuem acesso às mesmas funcionalidades, já que os seus processos são semelhantes, a diferença estará apenas a nível de banco de dados (como pode ser visto na Figura 5, tabela “empenhos_entrada” e tabela “entradas”, as quais possuem o campo “setor”, onde se dá a diferenciação) e no tipo de material que cada setor receberá, o Patrimônio recebe materiais de longa duração e o Almoxarifado recebe materiais de uso recorrente.
Figura 5. Diagrama de Entidade Relacionamento Fonte: autor (2018)
Figura 6. Diagrama de Classes Fonte: autor (2018)
Quanto as funcionalidades relacionadas a compras dos itens licitados, há a classificação dos itens de acordo com o Sistema Integrado de Administração Financeira do Governo Federal (SIAFI) e a autorização de compra, esta última desenvolvida com o intuito de auxiliar o servidor de modo a não permitir que seja pedido uma quantidade maior do que foi licitado, como mostra a Figura 4, diminuindo o retrabalho ocasionado pelo erro de preenchimento do documento. Além destas funcionalidades haverá a emissão de relatórios que servirá como ferramenta de monitoramento do processo.
As funcionalidades disponíveis para os dois perfis são acessadas a partir do momento em que há a entrada do empenho de despesa (ou simplesmente empenho), que é “o ato emanado de autoridade competente que cria para o Estado obrigação de pagamento pendente ou não de implemento de condição” [Brasil 1964]. Este documento tem sua origem na autorização de compra emitida pelo setor de compras dentro da SPM e é o aceite da autorização por parte da PROAF, que é o órgão responsável pela gestão financeira da UFRA. Ao ser dada a entrada do empenho no setor, este é vinculado a autorização de compra (processo explicado na Figura 7) emitida de modo a saber quais os itens foram comprados, como pode ser visto na Figura 6, onde há a classe associativa “AC_Empenho” que faz a
ligação e guarda das informações referentes a mesma. Os demais dados do empenho são importados diretamente do Portal da Transparência [Portal da Transparência 2018].
No momento da entrega do material, o servidor acessa a tela de entrada de material e informa o número do empenho ou CNPJ do fornecedor, aparecerá embaixo uma lista de empenhos de acordo com a entrada de dados, o servidor escolhe qual o empenho que representa a entrada do material, é então redirecionado para a tela onde irá informar a entrada do material, verificando se as quantidades e valores estão de acordo com o que foi pedido e o total confere com o total do empenho. Estando tudo correto é então dada entrada no estoque, do Patrimônio ou Almoxarifado, dependendo do caso.
Figura 7. Diagrama de Atividades – Vínculo de Empenho a Autorização de Compra Fonte: autor (2018)
Além das funcionalidades citadas acima, há os relatórios de entrada de empenho e de entrada de material, que estão disponíveis para que se tenha maior controle do processo.
Os questionários foram aplicados aos nove servidores que utilizam o sistema, sendo 3 do Setor de Compras, 4 do Setor de Almoxarifado, 1 do Setor de Patrimônio e 1 da Superintendência. O modelo do questionário pode ser visto no apêndice 1 e a média das respostas obtidas por questão, agrupadas por construto, na Tabela 4.
Tabela 4. Respostas Obtidas Após a Aplicação dos Questionários. Fonte: Autor (2018)
Oliveira et al. (2015) sugere 6 construtos, sendo o primeiro o Suporte de Alta Gestão, quanto a este, para a avaliação do software foi considerado que o fato de o desenvolvimento da aplicação ter sido uma iniciativa da própria Superintendência da SPM procurando dar maior segurança, agilidade e controle para o seu processo, já é argumento suficiente para afirmar que há suporte da alta gestão quanto ao projeto, como falado anteriormente.
Quanto ao construto de Qualidade do Serviço, como já mencionado, não há suporte oficial ao software desenvolvido, então este não se aplica.
Quanto aos demais construtos, pode-se perceber que a partir da visão dos servidores que utilizam o software a adoção foi bem-vinda pelos mesmos, o software chegou bem perto da nota máxima em praticamente quase todos os construtos; Lembrando que foi utilizado a Escala Likert com variação de 1 a 5 para obtenção das respostas, sendo 5 a nota máxima na maioria das questões, excetuando as perguntas 1 e 2 em que se pergunta quanto a dificuldade de aprendizado e dificuldade de uso no dia-a-dia, respectivamente, onde quanto menor a nota, melhor, pois mostra baixa dificuldade nestes quesitos.
Sendo assim, como já mencionado, o construto Qualidade do Sistema teve um rendimento um pouco diferente (Perguntas 1 e 2), pode-se inferir que os usuários encontraram certa dificuldade ao aprender e utilizar o sistema, desta feita, é necessário melhorar a usabilidade do sistema, de modo a deixa-lo mais fácil de utilizar.
5. Discussão dos Resultados
Quanto ao desenvolvimento do software, este não parou nas funcionalidades aqui apresentadas, conforme foi sendo utilizado outros requisitos apareceram e precisam ser
implementados. Além das novas funcionalidades, deve-se destacar que o mesmo requer manutenção periódica nos scripts de importação dos dados da Licitação e dos Empenhos, pois tanto o Portal da Transparência quanto o Portal de Compras Governamentais podem sofrer alteração na sua estrutura sem aviso prévio e impactar no bom funcionamento do sistema.
Outro ponto a se destacar foi o fato de o sistema ser bem aceito na sua implantação, apesar de a maioria dos servidores estarem trabalhando com o processo anterior já a um bom tempo, a mudança para o novo processo utilizando o software ocorreu de maneira tranquila, sendo necessário apenas um treinamento com todos para apresentar a ferramenta e algum treinamento de forma individual para sanar dúvidas pontuais.
Quanto a avaliação do software, pode-se afirmar que foi obtido sucesso na sua implementação na SPM, de acordo com a visão dos servidores que o utilizam, o mesmo gera confiança, agiliza o processo, melhora o desempenho do seu trabalho e trouxe ganhos para o setor em que eles trabalham, como pode ser visto na Tabela 3. O único ponto que teve um conceito menor foi quanto a qualidade do sistema, que ao serem perguntados sobre a dificuldade de uso e dificuldade no aprendizado, foram obtidas respostas um pouco menores do que eram esperadas.
Algo a se destacar é a falta de um suporte oficial do software, ocasionando um problema quanto ao construto Qualidade do Serviço, que avalia o quão bom é o suporte de TI. Esta falta de um suporte oficial pode impactar na continuidade do bom andamento do projeto, já que futuramente este pode ficar sem manutenção, o que é preocupante.
Como proposta para trabalhos futuros pode-se propor o estudo da usabilidade do software, desenvolver as mudanças necessárias de acordo com o estudo e avaliar novamente o mesmo para verificar se as mudanças surtiram o efeito desejado, a saber, facilidade de uso.
Além do estudo de usabilidade, pode-se propor também a criação de um módulo de Business Intelligence (BI), no qual ao utilizar os conceitos de Supply Chain, pode-se alcançar uma colaboração com os fornecedores para a fim de criar uma estruturada cadeia de suprimentos, onde fornecedores e SPM trabalham juntos para suprir as demandas da UFRA.
Além da utilização dos conceitos de Supply Chain, pode-se utilizar uma ferramenta de previsão de demanda, antecipando-se a esta o setor torna-se proativo, minimizando a falta de materiais essenciais ao funcionamento da universidade, realizando um melhor planejamento dos gastos públicos, tornando-os mais eficientes.
Referências
Agile Manifesto (2018) “The Agile Manifesto”, http://agilemanifesto.org/, Acesso em: 14/11/2018.
Alipour, J., Karimi, A., Ebrahimi, S., Ansari, F. e Mehdipour, Y. (2017). Success or failure of hospital information systems of public hospitals affiliated with Zahedan University of Medical Sciences: A cross sectional study in the Southeast of Iran. International Journal of Medical Informatics, 108, páginas 49-54.
Anwer, F., Aftab, S., Shah, S. S. M. e Waheed, U. (2017). Comparative analysis of two popular agile process models: extreme programming and scrum. International Journal of Computer Science and Telecommunications, 1(2).
Brasil (2000) “Lei Complementar nº 101, de 04 de maio de 2000”,
http://www.planalto.gov.br/ccivil_03/LEIS/LCP/Lcp101.htm, Acesso em: 01/11/2018. Brasil (1964) “Lei n° 4.320, de 17 de março de 1964”,
http://www.planalto.gov.br/ccivil_03/LEIS/L4320.htm, Acesso em: 12/11/2018.
Ching, H. Y., Silveira, H. F. R., e Freire, F. D. S. (2011). Gestão de custos na administração pública: estudo de casos do governo da Bahia e do Banco Central do Brasil. Revista de Economia e Administração, 10(2).
Guedes, G. T. (2018). UML 2-Uma abordagem prática. Novatec Editora.
Machado, F. N. R. (2018). Banco de Dados-Projeto e Implementação. Editora Saraiva.
Martins, J. e Menezes, R. M. T. (2016). Metodologia Ágil – framework scrum – em gerenciamento de projetos de software. Cognitio/Pós-Graduação UNILINS, 1(7).
Mota, T. B. e Oliveira Júnior, A. M. C. (2016). Desenvolvimento e uso de um software de gestão sob a ótica das dimensões organizacional, tecnológica e humana em empresas públicas. Navus - Revista de Gestão e Tecnologia, páginas 70–87.
Nunes, R. D. (2016). A implantação das metodologias ágeis de desenvolvimento de software Scrum e Extreme Programming (XP): uma alternativa para pequenas empresas do setor de tecnologia da informação. ForScience: revista científica do IFMG, 4(2).
Oliveira, D. d. L., da Silva Ferreira, E. P., de Freitas Carneiro, A., da Costa, R. F., e Silva Porto, W. (2015). Sucesso de sistemas de informações na administração pública: Proposta de um modelo exploratório. Future Studies Research Journal: Trends & Strategies, 7(2). Portal de Compras (2018) “Portal de Compras do Governo Federal”,
https://www.comprasgovernamentais.gov.br/, Acesso em: 04/11/2018.
Portal da Transparência (2018) “Portal da Transparência do Governo Federal”, https://www.portaldatransparencia.gov.br/, Acesso em: 11/11/2018.
Pressman, R. and Maxim, B. (2016). Engenharia de Software-8ª Edição. McGraw Hill Brasil. Souza, R., Lopes, J., Cardozo, A., Carvalho, T., Davet, P., Wolf, A., Yamin, A., Barbosa, J. e
eventos distribuídos. CSBC 2016 – XXXVI Congresso da Sociedade Brasileira de Computação, páginas 1206-1215.
Apêndice 1
Questionário desenvolvido pelo autor, baseado em Souza et al. (2016).
Questionário
1 – O quão difícil foi para você aprender a utilizar o sistema? responda em uma escala de 1 a 5, onde 1 representa nenhuma dificuldade e 5 grande dificuldade.
1 2 3 4 5
2 – O quão difícil é utilizar o sistema no seu dia-a-dia? responda em uma escala de 1 a 5, onde 1 representa nenhuma dificuldade e 5 grande dificuldade.
1 2 3 4 5
3 – O quanto você confia nas informações geradas pelo sistema? responda em uma escala de 1 a 5, onde 1 representa não confio e 5 confia plenamente.
1 2 3 4 5
4 – O quanto o sistema lhe ajuda no seu trabalho do dia-a-dia? responda em uma escala de 1 a 5, onde 1 representa não ajuda e 5 ajuda muito.
1 2 3 4 5
5 – Na sua visão, o quanto a adoção do sistema agilizou o processo no seu setor. responda em uma escala de 1 a 5, onde 1 representa não agilizou e 5 agilizou muito.
1 2 3 4 5
6 – Na sua visão, o quanto o sistema melhorou o desempenho do seu trabalho? responda em uma escala de 1 a 5, onde 1 representa não melhorou e 5 melhorou muito.
1 2 3 4 5
7 – Na sua visão, o quanto o sistema melhorou o desempenho da SPM como um todo? responda em uma escala de 1 a 5, onde 1 representa não melhorou e 5 melhorou muito.
1 2 3 4 5
8 – Na sua visão, o sistema atende às suas expectativas quanto a melhorar o desempenho do seu trabalho? responda em uma escala de 1 a 5, onde 1 representa não atende e 5 atende com certeza.
