UNIVERSIDADE LICUNGO

FACULDADE DE CIÊNCIAS E TECNOLOGIA

CURSO DE LICENCIATURA EM INFORMÁTICA

ZACARIAS LUCAS MANUEL

PROPOSTA DE IMPLEMENTAÇÃO DO SISTEMA DE GESTÃO DE PATRIMÓNIO

NA UNILICUNGO

BEIRA
2021
 ZACARIAS LUCAS MANUEL

PROPOSTA DE IMPLEMENTAÇÃO DO SISTEMA DE GESTÃO DE PATRIMÓNIO

NA UNILICUNGO

Monografia apresentada a Faculdade de Ciências e

Tecnologia como requisito para a obtenção do grau
académico de Licenciatura em Informática com
Habilitação em Engenharia de Desenvolvimento de
Software.

Orientador: Msc. Almiro Madeira

BEIRA
2021
 ÍNDICE
DECLARAÇÃO.......................................................................................................................8

DEDICATÓRIA.......................................................................................................................9

AGRADECIMENTOS...........................................................................................................10

RESUMO................................................................................................................................11

ABSTRACT...........................................................................................................................12

CAPÍTULO I - INTRODUÇÃO............................................................................................13

1.1 Introdução...................................................................................................................13

1.2. Problematização...............................................................................................................14

1.3. Justificativa......................................................................................................................15

1.4. Objectivos........................................................................................................................15

1.4.1. Objectivo Geral........................................................................................................15

1.4.2. Objectivos específicos.............................................................................................15

1.5. Delimitação do Tema.......................................................................................................16

1.5.1. Delimitação Espacial...............................................................................................16

1.5.2. Delimitação contextual........................................................................................16

CAPÍTULO II - REVISÃO DA LITERATURA...................................................................17

2.1. Gestão de Recursos Patrimoniais................................................................................17

2.2. Custos associados ao estoque......................................................................................18

2.3. Gestão de Informação.................................................................................................20

2.2. Sistema Informático....................................................................................................21

CAPÍTULO III – METODOLOGIA DE TRABALHO.........................................................22

3.1. Classificação da Pesquisa.......................................................................................22

3.1.1. Quanto ao método usado...............................................................................22

3.1.2. Quanto a abordagem.....................................................................................22

3.1.3. Quanto a natureza................................................................................................23

 3.1.4. Quanto aos Objetivos..........................................................................................23

3.1.5. Quanto aos Procedimentos técnicos....................................................................23

3.2. Instrumentos de Colecta de Dados.........................................................................24

3.2.1. Observação directa........................................................................................24

3.2.2. Entrevista.............................................................................................................24

3.3. Metodologia de desenvolvimento do sistema.........................................................25

3.5. Tecnologias Utilizadas................................................................................................26

3.5.1. PHP (versão 7)....................................................................................................26

3.5.2. Cascading Style Sheets (CSS 3)..........................................................................27

3.5.3. Hypertext Markup Language (HTML VERSÃO 5).....................................27

3.5.4. JavaScript......................................................................................................27

3.5.5. JQuery Versão 4............................................................................................27

3.5.6. Bootstrap 4.0.................................................................................................28

3.4.6. Framwork Codeigniter........................................................................................28

3.4.7. Base de dados MySQL........................................................................................28

3.4.8. Servidor Web.......................................................................................................28

3.4.9. Modelagem do Projecto......................................................................................29

CAPÍTULO IV - APRESENTAÇÃO, ANÁLISE E DISCUSSÃO DOS RESULTADOS...30

4.1 Cenário Actual.............................................................................................................30

4.2 Estrutura do Sistema....................................................................................................30

4.3 Requisitos Funcionais e Não Funcionais.....................................................................31

4.3.1 Requisitos funcionais...........................................................................................32

4.3.1 Requisitos não funcionais....................................................................................32

4.4 Diagramas UML..........................................................................................................33

4.4.1 Diagrama de caso de uso......................................................................................33

 4.4.2 Diagrama de classe...............................................................................................35

4.4.3 Diagrama de entidade e relacionamento..............................................................35

4.5 Descrição do Sistema...................................................................................................37

CAPITULO V - CONCLUSÕES E RECOMENDAÇÕES...................................................42

5.1 Conclusão.....................................................................................................................42

5.2 Recomendações............................................................................................................42

Referências Bibliográficas......................................................................................................43

Índice de Figuras
Figura 1: Compensação de custos de estoques com a quantidade pedida.__________________20
Figura 2: Estrutura do modelo MVC_______________________________________________31
Figura 3: Diagrama de caso de uso Login__________________________________________34
Figura 4: Diagrama de caso de uso Operações______________________________________34
Figura 5: Diagrama de Classe do sistema proposto___________________________________35
Figura 6: Diagrama de ER do sistema proposto______________________________________36
Figura 7: Tela de login da administração___________________________________________37
Figura 8: Tela de cadastro de produtos_____________________________________________38
Figura 9: Tela de adicionar edição de produtos______________________________________38
Figura 10: Aquisição de produtos_________________________________________________39
Figura 11: Saída de produtos do estoque___________________________________________40
Figura 12: Tela de pedidos______________________________________________________40
Figura 13: Tela de cadastro de utilizador___________________________________________41

Índice de Tabelas
Tabela 1: Requisitos Funcionais do sistema Proposto-------------------------------------------------32
Tabela 2: Requisitos não funcionais do sistema proposto---------------------------------------------32
 6

Lista de Siglas e Abreviaturas

CSS – Cascading Style Sheet

GI – Gestão de Informação

HTML – Hypertext Markup Language

JQuery – Javascript Query

PHP – Hypertext Pre-processor

RF – Requisitos Funcionais

RNF – Requisitos Não Funcionais

RUP – Rational Unified Process

SGBD – Sistema de Gestão de Base de Dados

SI – Sistema de Informação

SQL – Structured Query Language

TI – Tecnologia de Informação

UML – Unified Model Language

Unilicungo – Universidade Licungo

 7

DECLARAÇÃO
Declaro que esta Monografia é resultado da minha investigação pessoal e das orientações do meu
supervisor, o seu conteúdo é original e todas as fontes consultadas estão devidamente
mencionadas no texto, nas notas e na bibliografia final.
Declaro que este trabalho ainda não foi apresentado em nenhuma outra instituição para a
obtenção de qualquer grau académico.

Beira, aos ____ de Dezembro de 2021

_________________________________________
(Zacarias Lucas Manuel)
 8

DEDICATÓRIA
 9

AGRADECIMENTOS
 10

RESUMO

Manuel, Zacarias Lucas. (2021). Proposta de implementação do sistema de gestão de estoques

na universidade Licungo,

O presente trabalho tem como proposta a implementação do sistema de gestão de estoque

no Departamento de Logística e Património na Unilicungo. Com o sistema proposta resolver-se-á
os problemas que tem acontecidos no departamento, visto que tem havido diversas dificuldades
para o controlo das saídas e entradas do património. O sistema tem como objetivo armazenar e
organizar as informações sobre o património da Unilicungo. O sistema proposto irá organizar
toda a parte de cadastro e movimentação de transferência dos bens, até a emissão de relações
sobre o estado do património actual ou passado. Com a implantação de um sistema especializado,
esperam-se resultados mais precisos e eficientes, dinâmicos e reduzindo ao máximo. O sistema
foi desenvolvido utilizando uma linguagem de programação web com o objetivo de tornar o
acesso, ao mesmo, fácil dentro e fora da instituição caso haja a necessidade.
O autor se apoio em diversas literaturas que tratam do assunto de gestão de património tendo o
método da observação directa como a base de extração dos requisitos para o desenvolvimento do
sistema proposto.

Palavras chaves: Património, Programação web, Gestão de património.

 11

ABSTRACT

The present work proposes the implementation of the wealth management system at Unilicungo.
With the proposed system, the problems that have occurred in the university's heritage
department will be solved, as there have been several difficulties in controlling the exits and
entrances of the heritage. The system aims to store and organize information about Unilicungo
assets. The proposed system will organize all the registration and transfer of assets, up to the
issue of reports on the state of the current or past assets. With the implementation of a specialized
system, more precise and efficient, dynamic and reducing results are expected. The system was
developed using a web programming language with the objective of making it easy to access
inside and outside the institution, should the need arise.

The author draws on several literatures dealing with the issue of wealth management, using the
direct observation method as the basis for extracting the requirements for the development of the
proposed system.

Keywords: Assets, Web programming, Assets management.

 12

CAPÍTULO I - INTRODUÇÃO
1.1 Introdução
A Gestão Patrimonial voltada a Administração Pública tem por objectivo principal atender às
demandas por materiais permanentes e de consumo com o intuito de viabilizar as diversas
actividades desenvolvidas em um determinado órgão público, sem perder de vista o controle, a
integridade e a acuracidade dos registros patrimoniais atendendo assim, as exigências e
normativos dos órgãos de controle, quer seja interno como a auditoria interna, quer sejam
externos.
Para viabilizar o alcance dos seus objetivos, a Administração Patrimonial encontra-se subdividida
em actividades relacionadas a aquisição, recebimento, conferência, armazenamento,
movimentação e baixa de bens pertencentes ao património das instituições públicas. Essas
actividades necessitam ser desenvolvidas de forma eficiente e oportuna, visando evitar prejuízos
ao erário, uma vez que as organizações destinam recursos financeiros para sua execução.
Nos dias actuais apesar da grande oferta de software no mercado, ainda existem instituições que
fazem seu controle de património manualmente ou se baseando em simples planilhas do Excel,
acarretando um custo muito alto aos proprietários, associados e responsáveis pela Instituição.
Esse controle muitas vezes não chega a ser feito por motivos adversos. Custos como mão de obra,
materiais, espaço e perca de informações, são alguns dos principais problemas encontrados ao se
fazer tudo da maneira procedural.
É neste contexto que surge o interesse do autor em pesquisar sobre o tema em questão, uma vez
que actua de forma auxiliar na gestão patrimonial da Universidade Licungo - Extensão da Beira,
instituição objeto da pesquisa, bem como pela ausência de disponibilidade de estudos acadêmicos
direcionados à gestão patrimonial da referida Universidade, de forma a auxiliar a Universidade
Licungo (Unilicungo) de forma geral no seu controle de património, disponibilizando formas
fáceis de acesso às informações como inclusão, edição, exclusão e geração de relatórios.
O sistema para a gestão patrimonial desta universidade, foi desenvolvido para facilitar o manejo
de informações e controlar o estado do património, facilitando a correção de problemas que
possam vir a ocorrer, como por exemplo: identificar quais equipamentos que estão em
manutenção ou os que já foram totalmente depreciados. Com isso haverá uma diminuição nos
custos, proporcionando assim economia em papéis, espaço físico e tempo na busca de
 13

informações. Mantendo a integridade dos dados será possível proporcionar tranquilidade e

segurança na Unilicungo.

Esta pesquisa é composta por 5 capítulos, onde o capítulo 1 contém aspectos iniciais, abordando
o tema de estudo e a formulação da problemática, ou seja, um contexto da realidade do assunto.
Inclui-se ainda, a justificativa da pesquisa que visa descrever e argumentar sobre as razões e
motivações da escolha do tema em questão, os objectivos, os quais mostram a finalidade do
trabalho, divididos em geral e específicos e por fim a delimitação do tema que visa impor limites
na pesquisa.

O capítulo 2 consiste na revisão da literatura, o qual apresenta o levantamento literário dos

trabalhos semelhantes anteriormente pesquisados, os aspectos abordados, lacunas existentes na
literatura e as fontes disponíveis para a pesquisa.

O capítulo 3 apresenta os procedimentos metodológicos para o direccionamento

da pesquisa, abordando a natureza da mesma, o universo, os instrumentos e o
tratamento de dados utilizados.

O capítulo 4 evidencia os resultados alcançados, fundamentados nas informações e directrizes

dos capítulos anteriores, respondendo aos objectivos, delineados pelos procedimentos
metodológicos.

Por fim, o capítulo 5 demonstra as considerações finais, ou seja, os aspectos

relevantes em conformidade com o tema abordado, recomendações para as empresas além de
sugestões para trabalhos futuros, juntamente com os elementos pós-textuais: referências e
apêndices.

1.2. Problematização
A Universidade Licungo, com sede na Cidade de Quelimane, é uma pessoa colectiva de direito
público dotado de personalidade jurídica e goza de autonomia estatutária e regulamentar,
Cientifica, pedagógica, administrativa, financeira, patrimonial e disciplinar. Criada ao abrigo do
Decreto 3/2019 de 14 de Fevereiro no âmbito da reestruturação do Ensino Superior, ela engloba
os recursos humanos, materiais e financeiros da extinta Universidade Pedagógica (Delegações de
Quelimane e Beira) e funciona nas províncias da Zambézia e Sofala.
 14

A Gestão do estoque da Unilicungo é feita utilizando planilhas electrónicas, essas planilhas

simplesmente contém a quantidade que existe e nem descrevem o histórico do material no
estoque. Com isso surgiu-se na Unilicungo a necessidade de desenvolver um sistema de controle
património para melhorar o controlo do património da instituição, a universidade ofereceu a
oportunidade para fazer a análise e o desenvolvimento do sistema junto ao trabalho de conclusão
do curso, neste sentido surge a seguinte questão de pesquisa: Como melhorar a gestão do
património da Universidade Licungo – Extensão da Beira, através de um sistema web?

1.3. Justificativa
Para que se tenha um controle efectivo do património de uma instituição, deve-se investir em
funcionários para executar periodicamente rotinas de conferências, espaço para armazenamento
de documentação, material para cadastro e controle das informações. Contudo, usando desses
métodos, fica difícil garantir a integridade e segurança das informações.
A realização deste trabalho justifica-se à medida que se constata a existência de estudos como os
realizados por Coutinho (2004), Santos (2012) e Barbosa (2013), que apontam a necessidade
de se aprofundar as pesquisas sobre o tema, na perspectiva de encontrar caminhos para um
controle eficiente sobre os bens móveis, instrumentos indispensáveis na consecução das
actividades realizadas pela Administração Pública, e por representarem uma parcela significativa
do património das organizações.
O sistema proposto foi desenvolvido com o objectivo de facilitar a manutenção e acesso aos
dados, tornando mais fácil o controle patrimonial. Será possível executar de forma rápida
cadastros de novos equipamentos adquiridos, transferências de setor, consultas de estado,
retiradas e emissão de documentos.

1.4. Objectivos

1.4.1. Objectivo Geral

 Propor a implementação de um sistema de gestão para o controle do património na
Universidade Licungo-Beira.
 15

1.4.2. Objectivos específicos

 Analisar o sistema actual de gestão de estoque no Departamento de Logística e
Património;
 Identificar as necessidades para a implementação de um sistema automatizado;
 Modelar o sistema;
 Apresentar o protótipo do sistema.

1.5. Delimitação do Tema

1.5.1. Delimitação Espacial

O ponto referencial para esta pesquisa é o Departamento de Logística e Património da
Universidade Licungo Extensão da Beira.

1.5.2. Delimitação contextual

O tema enquadra-se nas áreas relacionadas de Desenvolvimento de Sistema, Aplicações Web e
Segurança Informática, no contexto social, o público-alvo são os funcionários que aderem ao
processo de gestão patrimonial da Unilicungo – Extensão da Beira, objectivando a melhoria no
processo de aderência do mesmo.
 16

CAPÍTULO II - REVISÃO DA LITERATURA

Neste capítulo faz-se o embasamento teórico sobre os principais aspectos abordados ao
longo do desenvolvimento do trabalho.

2.1. Gestão de Recursos Patrimoniais

Para a execução das suas atividades, as instituições públicas ou privadas, necessitam, dentre
outros recursos, dos recursos patrimoniais ou activos imobilizados entendidos como as
instalações representadas pelos bens móveis e imóveis, que integram o património das
organizações. Segundo Martins et al. (2007), são cinco os recursos necessários para uma
organização atuar de forma eficiente tais como: materiais; humanos; tecnológicos; financeiros e
patrimoniais.
Segundo Francischini e Gurgel (2002) é considerado recurso patrimonial ou activo imobilizado
todo bem de natureza relativamente permanente, mantido na organização com a finalidade de
produzir bens ou serviços e não estar destinado a venda. Os bens móveis e imóveis por
transmitirem a ideia de poder gerar produtos e serviços e, portando, produzir riquezas, são muitas
vezes considerados como sinónimos de recursos. Assim, um automóvel, classificado como bem
móvel pode ser utilizado na prestação de um serviço com valor económico, e como tal é um
recurso (MARTINS et al. 2007).

Segundo Meirelles (2006) os recursos patrimoniais representados pelos bens móveis e imóveis
são considerados bens públicos de uso especial ou uso privativo que se destinam à função
pública, utilizados de maneira exclusiva.
Para Pozo (2007) na administração moderna torna-se cada vez mais necessário uma boa gestão
dos recursos patrimoniais. Utilizar adequadamente os activos permanentes como máquinas,
equipamentos, passa, a ser elemento gerador de receitas e não de despesas, é assim uma função
integrante do bom administrador. O resultado operacional de uma organização é, sem dúvida
alguma em função das condições físicas dos bens patrimoniais, de sua conservação e de seu
trato.
Uma parcela significativa dos investimentos feitos pelas as organizações é representada pelos
bens móveis, ou bens do activo imobilizado. Segundo Santos (2012) os bens móveis, geralmente
representados pelos chamados materiais permanentes, ao longo da sua trajectória de uso,
 17

recebem tratamentos físicos e contábeis específicos que fazem da administração patrimonial, uma
actividade de muita responsabilidade.
Para Francischini e Gurgel (2004) uma vez adquirido o material permanente, ele passa a ser
utilizado na produção de bens ou serviços e dificilmente poderá ser descartado em curto prazo.
As compras de atcivos são, portanto, de muita responsabilidade e um erro qualquer levará a
instituição a ter de suportar, por tempo elevado, as consequências dessa aquisição errada.

2.2. Custos associados ao estoque

Estoques são considerados elementos fundamentais para quase todas as instituições, mais
se forem utilizados de forma errada podem acarretar custos altos.

Conforme Dias (2006), todo e qualquer armazenamento gera determinados custos para a
organização: juros; depreciação; aluguel; equipamentos de movimentação; deterioração;
obsolescência; seguros; salários; conservação.

Segundo Ching (1999), os custos associados aos estoques podem ser divididos em três
categorias:

A primeira categoria o custo de aquisição representa os custos fixos administrativos

associados ao processo de aquisição do estoque. Incluem-se os custos de pedidos de compra,
inspeções de recebimento, e demais custos burocráticos de um armazém.

Complementando Ballou (2006) os custos relacionados com as compras de materiais para

repor os estoques são quase sempre uma significativa força econômica que define a quantidade
da reposição.

Segundo Ballou (2006, pag. 279) ao se solicitar uma reposição de estoque, incorre-se a
uma variedade de custos relacionados ao processamento, preparação, transmissão, manutenção e
ao pedido de compra.

A segunda categoria o custo de manutenção dos estoques segundo Ching (1999),

representa os custos de armazenagem, seguros, preservação e obsolescência do material estocado
e o custo de oportunidade de se empregar o dinheiro gasto em estoque em outros investimentos.
 18

Complementando Ballaou (2006, pag. 279). Os custos de manutenção dos estoques são
aqueles resultantes do armazenamento, ou propriedade, de produtos durante um determinado
período, proporcional à média das quantidades de mercadoria disponíveis.

Segundo Ballou (2006, pg. 279) os custos de manutenção podem ser divididos em quatro
classes:

 Custo de espaço: são aqueles cobrados pelo volume cobrado no prédio de estocagem. Nos
casos dos espaços próprios, os custos de espaços são determinados pela alocação de
custos operacionais com relação ao espaço, ventilação e iluminação.
 Custo de capital: são aqueles derivados do valor em dinheiro imobilizado em estocagem
 Custos dos serviços de estocagem: seguros e impostos são exemplos deste custo, o seu
valor está relacionado com o nível de estoque disponível. Os seguros garantem proteção
ao estoque contra perdas causadas por incêndio, tempestades ou furtos. Já os valores dos
impostos são calculados de acordo o nível de estoque na data de avaliação.
 Custo dos riscos de estocagem: são os custos relacionados a deterioração, roubos, danos
ou obsolescência. Ao decorrer do tempo na manutenção dos estoques, uma parte dele
acabará contaminada, danificada, ou seja, desperdiçada de alguma forma ou indisponível
para consumo.

Ballou (2006) aborda a terceira categoria de custos associados aos estoques são: os custos
da falta de estoque ocorrem quando um pedido não pode ser atendido, pelo estoque convencional.
Esse custo pode ocasionar atrasos nos pedidos e na produção, deixando insatisfeitos os
requerentes, podendo gerar prejuízos financeiros e ainda novos custos adicionais de transporte
quando esses pedidos não são atendidos da forma convencional.

O custo total representa o somatório dos custos de pedir, manter o estoque ao longo de um
período, segundo Ballou (2006), o conceito do custo total reconhece que os custos individuais
exibem comportamentos conflitantes e que os mesmos devem ser analisados de maneira geral a
fim de se chegar ao ponto ótimo.

A figura 1 apresentada por Ballou (2006) representa a função do custo total do estoque
onde o vértice da parábola representa o ponto ótimo do estoque.
 19

Figura 1: Compensação de custos de estoques com a quantidade pedida.

Fonte: Ballou (2006)

2.3. Gestão de Informação

O conceito de informação é um dos maiores paradoxos existentes em toda a Ciência da
Informação devido à dificuldade encontrada para conceituar ou definir tal termo. Um dos grandes
desafios dos estudiosos e pesquisadores da área é definir ou conceituar informação de maneira
sólida e coerente. Nenhum dos diversos e inúmeros conceitos realizados até o momento pode ser
considerado como “unânime” ou definitivo. Diversos fatores devem ser levados em consideração
nas tentativas de definição do termo “informação” e seu real significado, levando em conta as
mais diversas situações e contextos.
Gestão da Informação (G.I.) é um conjunto de processos que englobam atividades de
planejamento, organização, direção, disponibilização e controle dos repartições informacionais da
organizacão.
A G.I. visa tornar eficaz a utilização das repartições informacionais em qualquer contexto
organizacional, facilitando através do embasamento teórico as atividades organizacionais. dentre
elas, a tomada de decisões.
 20

Marchiori(2002) salienta de maneira concisa a principal função dos gestores da

informação: "A função principal do gestor ou gerente de repartições informacionais é prover um
serviço e/ou produto de informação que seja direcionado, funcional e atrativo aos objetivos a
serem alcançados".
A definição de Informação pode ser: um conjunto de dados organizados que fazem
sentido e referencia a um acontecimento, um fato ou um fenômeno, que no seu contexto tem um
determinado significado para o receptor, cujo fim é reduzir a incerteza ou incrementar
conhecimento sobre algo.
Capurro e lijorland (2007) consideram que o termo informação costuma ser utilizado
geralmente para designar uma acção, forma de moldar a mente ou o ato de comunicar, transmitir
conhecimento.

2.2. Sistema Informático

Na visão de PEREIRA & FONSECA (1997, p. 241) “São mecanismos de apoio a gestão,
desenvolvidos com base na tecnologia de informação e com suporte da informática para actuar
como condutores das informações que visam facilitar, agilizar e optimizar o processo decisório
nas organizações”.
Os sistemas de informação computadorizados (SI) utilizam hardware, software, redes de
telecomunicações; técnicas de administração de dados computadorizadas e outras formas de
tecnologia de informarão (TI) para transformarem repartições de dados em produtos de
informação. Estes produtos oferecem informações para a tomada de decisão feita pelos gestores.
Para FERREIRA (2008) Sistema de Informação é um tipo especializado de sistema que
pode ser definido como sendo um conjunto de elementos ou componentes inter-relacionados que
colectam (entrada), manipulam e armazenam (processo), disseminam (saída) os dados e
informação fornecem um e mecanismo de feedback. É um conjunto formado por pessoas,
software, hardware, procedimentos e dados.
 21

CAPÍTULO III – METODOLOGIA DE TRABALHO

Segundo GIL (2008) diz que a metodologia descreve os procedimentos a serem seguidos na
realização da pesquisa.

3.1. Classificação da Pesquisa

3.1.1. Quanto ao método usado

Conforme Ferreira (1998), o método indutivo define suas regras e etapas a partir de dois
pressupostos que se sustentam na ideia da existência de um determinismo nas leis observadas na
natureza. Enquanto O método dedutivo parte das teorias e leis consideradas gerais e universais
buscando explicar a ocorrência de fenômenos particulares. O exercício metódico da dedução
parte de enunciados gerais (leis universais) que supostos constituem as premissas do pensamento
racional e deduzidas chegam a conclusões. O exercício do pensamento pela razão cria uma
operação na qual são formuladas premissas e as regras de conclusão que se denominam
demonstração.
Para esta pesquisa quanto ao método usado foi optado por utilizar o método indutivo com isso
analisou-se diversos senários em outras empresas que utilizam as tecnologias ou um sistema de
gestão de estoque e conclui-se que com o sistema proposto irá se resolver a questão de
morosidade de aquisição de informação e garantir-se uma boa gestão do património da
Unilicungo.

3.1.2. Quanto a abordagem

A pesquisa qualitativa considera que existe uma relação entre o mundo e o sujeito além daquela
traduzida em números. Nessa abordagem, o objetivo central da pesquisa é entender a explicação
de algum fenômeno. Ou seja, há subjetividades e nuances que não são quantificáveis. A pesquisa
quantitativa considera elementos quantificáveis. Isto é, o objetivo da pesquisa é analisar
fenômenos a partir de quantificações, normalmente através de ferramentas estatísticas. O
pesquisador, nesse caso, é apenas um observador, que não pode analisar os dados de forma
subjetiva. A função dele é de simplesmente apresentar os resultados, a partir de uma estrutura,
como tabelas e gráficos. Isso significa traduzir opiniões e números em informações para elaborar
classificações e análises.
 22

Quanto a abordagem foi utilizada a pesquisa qualitativa que aborda temas que não podem ser
quantificados em equações e estatísticas, onde o autor fez diversos estudos baseando-se em
entrevistas, analise documental e questionários (Ver Apêndice A) que conduziram o
desenvolvimento do presente trabalho.

3.1.3. Quanto a natureza

De forma direta, a pesquisa básica objetiva gerar conhecimentos novos para avanço da
ciência sem alguma aplicação prática prevista. É uma pesquisa puramente teórica, que requer
obrigatoriamente uma revisão bibliográfica. Por sua vez, a pesquisa aplicada objetiva gerar
conhecimentos para aplicações práticas com objetivo de solucionar problemas específicos.
Optou-se pela pesquisa aplicada cujo objectivo é gerar conhecimentos para aplicações
práticas dirigidas à solução de problemas específicos. Em caso especial é de fazer o estudo que
culminará com o desenvolvimento de um sistema de gestão de património da Universidade
Licungo.

3.1.4. Quanto aos Objetivos

A pesquisa exploratória tem o objetivo de proporcionar maior familiaridade com um
problema. Para tanto, envolve levantamentos bibliográficos, entrevistas com pessoas que tiveram
experiências práticas com o problema, além da análise de exemplos. Assumindo, em geral, a
forma de pesquisas bibliográficas e estudos de caso.
Optou-se por utilizar a pesquisa exploratória que envolve levantamento bibliográfico,
entrevistas com pessoas que tiveram experiências práticas com o problema, além da análise de
exemplos. Para tal o autor efectuou diversas entrevistas com a direção do património da
Unilicungo.

3.1.5. Quanto aos Procedimentos técnicos

Optou-se pela pesquisa-acção que é um tipo de pesquisa com base empírica que é concebida e
realizada em estreita associação com uma ação ou com a resolução de um problema colectivo no
caso a direcção do património da Universidade Licungo Beira e no qual os pesquisadores e
 23

participantes representativos da situação ou do problema estão envolvidos de modo cooperativo

ou participativo. THIOLLENT (1986, p.14).
O autor juntamente com o Departamento de Logística e Património da Unilicungo arquitetou um
sistema que facilite a gestão do estoque.

3.2. Instrumentos de Colecta de Dados

Segundo MARCONI & LAKATOS (2003, p.165) aponta que esta é uma “Etapa da
pesquisa em que se inicia a aplicação dos instrumentos elaborados e das técnicas selecionadas, a
fim de se efectuar a colecta dos dados previstos”. Nesta pesquisa irá usar os métodos de
entrevista que apoio e permitiu a participação do autor no processo de desenvolvimento do
sistema proposto, a observação direita.

3.2.1. Observação directa

Segundo MARCONI & LAKATOS (2003, p.190) “A observação directa é uma técnica de
colecta de dados para conseguir informações e utiliza os sentidos na obtenção de determinados
aspectos da realidade. Não consiste apenas em ver e ouvir, mas também em examinar fatos ou
fenómenos que se desejam estudar”. Durante esta etapa far-se-á a observação nas planilhas e
documentos utilizados para o controlo do estoque da Unilicungo, o que permitirá a recolha de
informações visíveis sobre as causas e a situação actual.

3.2.2. Entrevista
De acordo com Lakatos e Marconi (2003, p. 92):

“A entrevista é um encontro entre duas pessoas, a fim de que uma delas obtenha
informações a respeito de determinado assunto, mediante uma conversação de natureza
profissional. É um procedimento utilizado na investigação social, para a colecta de dados
ou para ajudar no diagnóstico ou no tratamento de um problema. ”

Nesta pesquisa usou os métodos de entrevista que apoio e permitiu a participação do autor no
processo de desenvolvimento do sistema proposto por meio de roteiro de questionários, conforme
o apêndice A.
 24

3.3. Metodologia de desenvolvimento do sistema

A metodologia tradicional de desenvolvimento de sistemas utiliza-se do conceito de que as

actividades envolvidas são executadas de uma forma sequencial e ordenadas e com passos bem
estabelecidos. PRIKLADNICK, WILLI e MILANI (2014).
Estes métodos tendem a gerar incrementos que são artefactos de software (PRESSMAN,
2011), além de serem burocráticos e consideravelmente lentos, até mesmo pelo volume de
artefactos gerados (PRIKLADNICK, WILLI e MILANI, 2014).

3.4. Metodologia do Sistema

Para desenvolvimento deste trabalho baseou-se na metodologia RUP (Rational Unified
Process). É um dos muitos processos contidos na Biblioteca Processo Racional, que oferece as
melhores prácticas de orientação adequada para o seu desenvolvimento em particular ou
necessidade do projeto.
Segundo Sommerville (2007, p. 72) as melhores prácticas abordadas são as seguintes:
- desenvolver o software interativamente: planear os incrementos de software com base nas
prioridades do cliente, desenvolver e entregar o mais cedo possível às características de sistema
de maior prioridade no processo de desenvolvimento;

- gerenciar requisitos: documentar explicitamente os requisitos do cliente e manter o

acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças no sistema
antes de aceitá-las;

- usar arquiteturas baseadas em componentes: estruturar a arquitetura do sistema com

componentes, reduzindo a quantidade de software a ser desenvolvido e, consequentemente,
reduzir custos e riscos;

- modelar software visualmente: usar modelos gráficos de UML (Unified Model Language)
para apresentar as visões estática e dinâmica do software;

- verificar a qualidade do software: garantir que o software atenda aos padrões de qualidade da
organização;
 25

- controlar as mudanças do software: gerenciar as mudanças do software, usando um sistema

de gerenciamento de mudanças, procedimentos e ferramentas de gerenciamento de configuração.
Conforme Sommerville, o RUP está organizado em cinco (5) fases que são:
 Fase de concepção/iniciação: esta fase abrange as tarefas de comunicação com o cliente
e planejamento.
Nesta fase o autor junto com a direcção do património da Unilicungo reuniu e extraiu os
requisitos do sistema e em seguida separou os requisitos em funcionais e não funcionais
para poder passar para a fase de desenvolvimento (confome aparece na secção 4.3 do
Capítulo 4).
 Fase de elaboração: abrange a modelagem do modelo genérico do processo.
O autor com todos itens do ponto anterior modelo o sistema em questão utilizando UML
para descrever o funcionamento do mesmo pelos diagramas (confome aparece na secção
4.4 do Capítulo 4).
 Fase de construção: Nesta fase o autor desenvolveu o sistema em questão utilizando a
linguagem PHP (conforme a amostragem na secção 4.5 do Capítulo 4).
 Fase de transição: O autor fará a entrega do software para a Unilicungo e posteriormente
colher os feedbacks do teste do software em uso (fase não realizada nesta monografia).
 Fase de produção: E por último o autor entrega o software desenvolvido para a
universidade e dará o acompanhamento para implementar as novas funcionalidades do
software (fase não realizada nesta monografia).

3.5. Tecnologias Utilizadas

Nesse capítulo serão apresentadas todas ferramentas utilizadas para desenvolver o sistema
proposto desde linguagens, softwares, banco de dados entre outras tecnologias.

3.5.1. PHP (versão 7)

Existem diversas linguagens de programação com suporte a orientação a objectos. Dentre eles,
destacam-se o PHP (Hypertext Pre-processor), Javascript e entre outros.

Nesse trabalho, foi utilizada a linguagem PHP, por ser uma linguagem de baixo custo, largamente
utilizada, por possuir alta performance, excelente documentação e por ser robusta e flexível.
 26

A linguagem PHP é muito utilizada, e especialmente adequada para o desenvolvimento web e que
pode ser embutida dentro do HTML. O autor utilizou essa linguagem para desenvolver os pontos
funcionais do sistema e validação dos dados.

3.5.2. Cascading Style Sheets (CSS 3)

O CSS, do português “Folha de Estilo em Cascata” é uma linguagem de estilo, responsável pela
formatação e apresentação de conteúdo: layout, cores, fontes entre outros (Flatschart, 2011).

Neste trabalho foi usado o CSS para definir como serão exibidos os elementos contidos no código
das páginas HTML.

3.5.3. Hypertext Markup Language (HTML VERSÃO 5)

O HTML, do português “Linguagem de Marcação de Hyper-texto”, é a principal linguagem

utilizada na web. Ela permite a criação de documentos estruturados em títulos, parágrafos, listas,
links, tabelas, formulários e em muitos outros elementos nos quais podem ser incorporadas
imagens e objectos, como por exemplo, uma animação ou um vídeo (Flatschart, 2011).

Essa linguagem foi utilizada para desenhar o esqueleto da interface o sistema.

3.5.4. JavaScript

JavaScript é uma linguagem de programação que apresenta sintaxe semelhante à do Java, mas é
totalmente diferente no conceito e no uso. Oferece tipagem dinâmica, é interpretada, ao invés de
compilada, possui óptimas ferramentas padrões para listagens (como as linguagens de script, de
modo geral) e oferece bom suporte a expressões regulares.

Utilizou-se essa linguagem como forma de dinamizar os eventos do sistema como efeitos de
processamento e entre outros.

3.5.5. JQuery Versão 4

Para dar a vida a essas funcionalidades do Javascript uso-se o jquery (Javascript Query).
 27

3.5.6. Bootstrap 4.0

Para criação da Interface do usuário foi utilizado o Bootstrap que é um framework web com
código-fonte aberto para desenvolvimento de componentes de interface e front-end para sites e
aplicações web usando HTML, CSS e JavaScript, baseado em modelos de design para a
tipografia, melhorando a experiência do usuário em um site amigável e responsivo. Para agilizar
o desenvolvimento da interface apoiou-se nesse framework front-end como forma de dar a vida
do sistema.

3.4.6. Framwork Codeigniter

O framework é um conjunto de códigos genéricos e básicos usados como um pacote por
desenvolvedores que estão criando um sistema. Dessa forma, quando um projecto é iniciado, esse
pacote de códigos prontos é um suporte que facilita o trabalho, evitando a necessidade de iniciar
o sistema do zero, partindo já de uma base comum a qualquer desenvolvimento.

Para esse projecto de pesquisa o autor utilizou o Codeigniter como framework da linguagem PHP
na sua versão 4.

3.4.7. Base de dados MySQL

MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem
SQL (Linguagem de Consulta Estruturada, do inglês Structured Query Language) como
interface.

O autor o utilizou para poder armazenar os dados dos produtos da Unilicungo gerenciado pelo
sistema proposto.

3.4.8. Servidor Web

E como servidor web foi escolhido o Apache que é mais especificamente, um container de
servlets (módulos de software que são responsáveis por atender requisições de aplicações cliente
e prestar-lhes algum tipo de serviço) e acaba sendo muito leve e flexível de que outros servidores
 28

e o mais importante suprindo as principais necessidades da aplicação (The Apache Software

Foundation, 2020).

3.4.9. Modelagem do Projecto

Para a modelagem do sistema proposto será utilizado a UML. A UML é a linguagem padrão para
especificar, visualizar, documentar e construir artefactos de um sistema e pode ser utilizada com
todos os processos ao longo do ciclo de desenvolvimento e através de diferentes tecnologias de
implementação.
 29

CAPÍTULO IV - APRESENTAÇÃO, ANÁLISE E DISCUSSÃO DOS RESULTADOS

Os dados analisados a seguir são referentes a observação feita na direção do património da
Universidade Licungo. E também são apresentados os requisitos de sistema e apresentados
algumas telas do sistema propostos.

4.1 Cenário Actual

A direcção de património da Unilicungo utiliza um sistema de gestão não automatizado isto é, o

registo é feito no Excel e outros documentos no Word fazendo com que o controlo não seja muito
eficaz, visto que se torna difícil controlar o histórico das actividades do património da instituição.
Em relação ao aumento da quantidade no estoque dos produtos da Unilicungo não se tem o maior
controlo de qual entrou primeiro ou último ou seja se, se comprou 10 toners de uma certa marca e
se utilizam 6, esse número é subtraído directo da coluna da linha correspondente ficando 4 e
quando se fazer uma nova aquisição é feito a alteração directo na linha e coluna que possuem o
valor 4, isto é se adquiriu-se mais 10 toners se altera o valor de 4 para 14 e assim torna-se difícil
ter o controlo do histórico das aquisições. E quando se quer verificar o fornecedor de um certo
material para a universidade são obrigados fazer a busca dos recibos e documentos com esses
registos o outro processo que acaba se tornando demorado, pelo facto de não ser uma pessoa que
trabalha no sector cada um tem a sua maneira de organizar os documentos por mais que existam
pastas de arquivos.

4.2 Estrutura do Sistema

É importante realçar antes que, uma estrutura de software abrange a forma como suas partes são
organizadas, incluindo questões como o comportamento dessa estrutura e quais componentes são
responsáveis por realizar um conjunto específico de funções, ou seja, é um modelo repetível sob
o qual um sistema pode ser desenvolvido.

No desenvolvimento do software, foi utilizado o framework Codeigniter que aplica o padrão de

arquitectura MVC (Model-View-Controler) que divide a aplicação em 3 camadas nomeadamente
o modelo (model) que isola as demais camadas do sistema de forma a facilitar a sustentabilidade
 30

do código, a visão (view) que representa a interface do usuário e o controlador (controller)

responsável por ligar o modelo e a visão, fazendo com que os modelos possam ser repassados
para a visão ou o inverso.

Figura 2: Estrutura do modelo MVC

Fonte: Ramos (2010)

4.3 Requisitos Funcionais e Não Funcionais

Requisitos são solicitações, desejos, necessidades. Um requisito é a propriedade que um software

exibe para solucionar problemas reais, é a conjuntura indispensável para satisfazer um objecto.
Quando se trata de um software sob demanda, por exemplo, um requisito é uma maneira pelo
qual o sistema oferecido deve fazer, ou um condicionamento no desenvolvimento do sistema.

Frequentemente, as especificações de requisitos de software são criadas sem que haja real
entendimento das necessidades e problemas da organização. Por meio das técnicas de modelagem
de processo de negócio, é possível compreender melhor o ambiente no qual o sistema a ser
construído irá funcionar, o que possibilita identificar requisitos correspondentes às reais
necessidades do negócio (BAKER, 2001).

A forma utilizada para levantar os requisitos foi a observação directa, que faz parte da maioria
dos processos de engenharia de requisitos.
 31

4.3.1 Requisitos funcionais

Os requisitos funcionais são de extrema importância no desenvolvimento do sistema em causa,

pois, sem eles não há funcionalidades no sistema. Seus modelos devem ser construídos em um
nível de entendimento claro e objectivo, além de um código fonte totalmente aplicável.
Conclusão, são todas as necessidades, características ou funcionalidades esperadas em um
processo que podem ser atendidos pelo software.

A tabela abaixo descreve todos os requisitos funcionais do sistema proposto.

Tabela 1: Requisitos Funcionais do sistema Proposto

RF001: O sistema deverá permitir a criação, eliminação, edição e a visualização dos

produtos.
RF002: O sistema deverá possibilitar que o administrador faça o cadastro de outros
utilizadores.
RF003: O Sistema deve permitir registar a entrada e saída dos produtos no estoque.
RF004: O Sistema deverá permitir o registo de históricos dos produtos.
RF005: O Sistema deverá ter diferentes níveis de acesso.
RF006: O sistema deverá permitir a emissão de relatórios dos movimentos dos produtos.

Fonte: Elaborado pelo autor (2021).

4.3.1 Requisitos não funcionais

Um requisito Não Funcional, por sua vez pode ser definido como “de qual maneira” o sistema
deve fazer. A tabela abaixo descreve todos os requisitos não funcionais do sistema.

Tabela 2: Requisitos não funcionais do sistema proposto

RNF0001: O sistema deverá ser desenvolvido com a linguagem PHP.

RNF0002: O sistema deverá armazenar os dados no MYSQL.
RNF0003: Deverá utilizar o Padrão MVC.
RNF0004: Deverá controlar as secções e não permitir que um usuário sem autorização
 32

possa entrar em áreas restritas.

RNF0005: Deve ter as cores do logotipo da universidade.
RNF0006: Deve ter uma interface amigável e fácil de mexer.

Fonte: Elaborado pelo autor (2021).

4.4 Diagramas UML

A diagramação em Linguagem de modelagem unificada (UML) foi criada: para estabelecer uma
linguagem visual comum no complexo mundo do desenvolvimento de software, que também
poderia ser compreendida por usuários do mundo dos negócios e qualquer pessoa que queira
entender mais sobre um sistema.

A Linguagem de modelagem unificada (UML) foi criada para estabelecer uma linguagem de
modelagem visual comum, semanticamente e sintaticamente rica, para arquitetura, design e
implementação de sistemas de software complexos, tanto estruturalmente quanto para
comportamentos.

4.4.1 Diagrama de caso de uso

O diagrama de caso de uso descreve a funcionalidade proposta para um sistema que será
projetado, é uma excelente ferramenta para o levantamento dos requisitos funcionais do sistema.
Um caso de uso representa uma unidade discreta da interação entre um actor (humano,
dispositivo ou outro software) e o sistema. Um caso de uso é uma unidade de um trabalho
significante.

Casos de uso são tipicamente relacionados a "actores". Um actor é um humano ou entidade

máquina que interage com o sistema para executar um significante trabalho.

Para este trabalho foram feitos os seguintes casos de uso:

 33

Figura 3: Diagrama de caso de uso Login

Fonte: Autor(2021)

A figura 4, ilustra um esquema do diagrama de caso de uso onde os utilizadores do sistema

executam uma acção efectuar login e que está por sua vez inclui um outro caso de uso que
verifica o login de modo a executar a o caso de uso estendido quando os dados dos utilizadores
forem inválidos.

Figura 4: Diagrama de caso de uso Operações

Fonte: Autor(2021)

O esquema acima apresentado ilustra diversos casos relacionados aos actores do sistema
descrevendo as operações que cada um poderá realizar dentro do sistema.
 34

4.4.2 Diagrama de classe

Em programação, um diagrama de classes é uma representação da estrutura e relações das classes

que servem de modelo para objectos. Pode-se afirmar de maneira mais simples que seria um
conjunto de objectos com as mesmas características, assim saber-se-ia identificar objectos e
agrupá-los, de forma a encontrar suas respectivas classes. Na Unified Modeling Language (UML)
em diagrama de classe, uma classe é representada por um rectângulo com três divisões, sendo
elas o nome da classe, seus atributos e por fim os métodos.

O diagrama de classe serve também para auxiliar o desenvolvedor a enxergar visualmente as

funcionalidades do sistema que será desenvolvido por ele. É importante salientar que o diagrama
de classe não é desenhado pensando-se em um uma linguagem de programação específica, mas
sim como uma estrutura que irá orientar o desenvolvedor a entender o relacionamento entre
classes.

Cada classe do diagrama representa uma tabela do banco de dados, por esse motivo é tão
importante criá-lo. Observa-se também que para identificar-se uma classe, precisa-se antes
identificar-se seus objectos com características semelhantes.

Figura 5: Diagrama de Classe do sistema proposto

Fonte: Autor(2021).

4.4.3 Diagrama de entidade e relacionamento

O diagrama Entidade Relacionamento é composto por um conjunto de objetos gráficos que visa
representar todos os objetos do modelo Entidade-Relacionamento tais como entidades, atributos,
atributos chaves, relacionamentos, restrições estruturais, etc.
 35

O diagrama ER fornece uma visão lógica do banco de dados, fornecendo um conceito mais
generalizado de como estão estruturados os dados de um sistema. A partir das informações
obtidas, pode-se desenvolver um modelo conceitual que será utilizado para orientar o
desenvolvimento propriamente dito, fornecendo informações sobre os aspectos relacionados ao
domínio do projecto em questão. O diagrama ER do software proposto é apresentada segundo a
figura abaixo:

Figura 6: Diagrama de ER do sistema proposto

Fonte: Autor(2021)
 36

4.5 Descrição do Sistema

Como forma de descrever as principais funcionalidades da solução, serão apresentadas em

seguida as principais telas que a constituem:

Figura 7: Tela de login da administração

Fonte: Autor (2021)

De modo a restringir a entrada de pessoas indesejáveis na área administrativa da plataforma,

inicialmente é apresentada uma página de login que exige ao visitante credenciais, onde é exigido
o nome de utilizador e a palavra-passe. Caso a credenciais inseridas nos campos não existam no
banco de dados, um erro de dados de acesso será apresentado a pessoa que esteja tentando
efectuar um login no sistema.

Realçar-se que a solução possui níveis de acesso concebidos pelos administradores da plataforma.
Os níveis são verificados após à confirmação dos dados de acesso, e quando isso acontecer,
dependendo do nível do usuário, algumas telas e informações não serão disponibilizadas para a
visualização.
 37

Figura 8: Tela de cadastro de produtos

Fonte: Autor(2021)

Nessa tela é onde o utilizador fará os cadastros dos produtos pertencente ao património, dando
assim alguns detalhes como marca, categoria, referência e algumas descrições do mesmo.

Figura 9: Tela de adicionar edição de produtos

Fonte: Autor (2021)

 38

Após o cadastro o utilizador é redirecionado para a tela de edição de produtos, onde poderá ver os
detalhes referentes ao item cadastrado e tem também a possibilidade de executar algumas acções
como clicar no botão de registar o estoque, registar a saída do produto ou habilitar a edição para
fazer algumas alterações referentes ao produto.

Na mesma tela são registados os históricos do produto caso esteja com problemas técnicas, e
também são “puxados” registos como entrada e saída do estoque.

Figura 10: Aquisição de produtos

Fonte: Autor (2021)

A tela acima é onde os utilizadores efectuam o cadastro das entradas dos produtos no estoque,
podendo assim registar o fornecedor e o contacto caso haja a necessidade de obter o produto
novamente pode se entrar em contacto com o mesmo. Nessa tela também é apresentado a
quantidade disponível no estoque e também é exibido uma tabela com os registos das entradas.
 39

Figura 11: Saída de produtos do estoque

Fonte: Autor (2021)

A tela acima é onde são registadas as saídas dos produtos, com isso nessa tela é especificado o
departamento, quem faz a entrega e quem recebe. Também são descritos outros detalhes que se
acharem crucial para o acto neste item.

Figura 12: Tela de pedidos

Fonte: Autor (2021)

 40

A tela acima apresentada, contém todo o histórico dos produtos desde a manutenção, entrada e
saída.

Figura 13: Tela de cadastro de utilizador

Fonte: Autor (2021)

A tela acima é onde será feito o cadastro dos utilizadores do sistema.

 41

CAPITULO V - CONCLUSÕES E RECOMENDAÇÕES

5.1 Conclusão

Com a expansão tecnológica percebe-se que cada vez mais rotinas e processos estão sendo
automatizado por instituições que buscam produtividade e simplicidade, confiável, e segura.

O sistema desenvolvido oferece os recursos necessários para o Departamento de Logística e

Património da Unilicungo de modo a obter uma melhor organização e controle sobre os bens
patrimoniais e a conservação de informações de fácil acesso.

Outro ponto de relevância foi a forma utilizada para o desenvolvimento da aplicação, pois
proporcionou o aprimoramento do conhecimento em relação ao aprendizado que recebemos
durante o curso (Análise e Desenvolvimento de Sistemas), onde tivemos a oportunidade de
colocar em prática tudo o que aprendemos como boas práticas, padrões de projeto e novos meios
e formas de se desenvolver um sistema.

O desenvolvimento do sistema foi fundamental em relação ao aprendizado e aprimoramento dos

conhecimentos e habilidades, foi possível melhorar a programação orientada a objetos de forma
significativa junto a alguns conceitos dos padrões de projetos MVC.

5.2 Recomendações

A princípio, recomenda-se a aderência pela capacitação técnica que é um dos requisitos

fundamentais para facilitar o entendimento da aplicação

Seria importante também que num futuro próximo o sistema proposto fosse integrado à um
sistema de emissão de etiquetas e códigos de barra para melhorar o controlo e scanner dos dados
de equipamentos.
 42

Referências Bibliográficas

Baker, C. (2001). Foundations of Functional Requirements and Non-Functional Requeriments

(3rd ed.). Clevendon: Multilingual Matters LTD.

BALLOU, Ronald H (2006). Gerenciamento da cadeia de suprimentos/Logística.

BARBOSA, D. D. (2013). Manual de Controle Patrimonial: nas entidades públicas. 1. ed.

Brasília: Gestão Pública.

CAPURRO, R (1996, p. 259-270). On the genealogy of information. In: KORNWACHS, K.;

JACOBY, K. (Ed.). Information: New questions to a multidisciplinary concept. Berlin:
Akademie.

CHING, H. Y (1999). Gestão de estoques na cadeia de logística integrada. São Paulo: Atlas.

COUTINHO, J. R. de A. (2004). Gestão Patrimonial na Administração Pública: noções gerais

sobre os bens das entidades que integram a administração pública e sua utilização. Rio de
Janeiro: Lumen Juris.

DIAS, M. P. (2006). Administração de materiais (compacta ed.). São Paulo: Atlas. Empresarial.
5. ed. Porto Alegre: Bookman.

FERREIRA, N. S. C (2008). A gestão enquanto instrumento para a construção e qualificação de

recursos patrimoniais.

FERREIRA, N. S. C. (1998). Gestão Participativa dos recursos Patrimoniais: atuais tendências,

novos desafios. São Paulo: Cortez.

FLATSCHART, F. (2011, p. 228). HTML5: embarque imediato. Rio de Janeiro, RJ: Braspor.
(Web conceitos & ferramentas).

FRANCISCHINI,G. P., GURGEL, F. do A. (2004). Administração de Materiais e do Património.

1. ed. São Paulo: Pioneira Thomson Learning.

GIL, A. C. (2008). Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas.
 43

LAKATOS, E. M.; MARCONI, M. de A. (2003). Fundamentos de metodologia científica. 5. ed.

São Paulo: Atlas.

MARCHIORI, P. Z.( 2002, maio/ago, p. 72–79) . A ciência e a gestão da informação:

compatibilidades no espaço profissional. Ciência da Informação, Brasília, v. 31, n. 2.

MEIRELLES, H. L (2012). Direito administrativo brasileiro. Rio de Janeiro: Malheiros.

PEREIRA, M. J. L.; FONSECA, J. G. M. (1997). Faces da decisão: as mudanças de paradigmas

e o poder da decisão. São Paulo: Makron Books.

POZO, H. (2007). Administração de Recursos Materiais e Patrimoniais. 4ª Ed. São Paulo: Atlas.

PRESSMAN, R. S (2011). Engenharia de Software - uma abordagem profissional. 7a. ed. Porto
Alegre: AMGH Bookman, v. I.

RAMOS, P (2010). Entendendo o MVC. São Paulo. Contexto.

SANTOS, G. dos (2012). Gestão Patrimonial: Ampliada e atualizada. 4 ed. Florianópolis: Secco.

SOMMERVILLE (2007), I. Engenharia de Software. 8a Edição. Addison Wesley.

THIOLLENT (1986), M. Metodologia da Pesquisa-Ação. São Paulo: Cortez.

 44

APÊNDICE A – Instrumento de Coleta de Dados

QUESTIONÁRIO

Este questionário integra uma pesquisa realizada na Universidade Licungo - Extensão da Beira e nas
Chefias dos Departamento de Logística e Património, tendo como objetivo extrair subsídios
complementares para elaboração da Monografia do estudante Zacarias Lucas Manuel.
Destacamos a importância de sua colaboração e ressaltamos que as informações obtidas neste instrumento
de pesquisa serão utilizadas única e exclusivamente para fins académicos.

PARTE I – PERFIL DO RESPONDENTE

1– Unidade onde exerce suas atribuições:
R:

2 - Cargo/Carreira Profissional:
R:

3- Formação (Escolaridade):
R:

4 – Tempo de exercício nas atividades relacionadas ao património da unidade:

R:

PARTE II - DIAGNÓSTICO
1- Existem manuais ou documentos semelhantes que formalizam as rotinas de trabalho ligadas ao
controle dos materiais permanentes da unidade? Em caso positivo quais?
R:
 45

3- Sua unidade tem conseguido ser eficaz na execução dos inventários de bens: no final do
exercício; e quando da mudança na direcção da unidade? Em caso negativo por quais motivos?
R:

4- Enquanto responsável pelo controle do acervo patrimonial, conhece a totalidade e tipos de

bens que integram esse acervo? A noção desse tipo de informação seriam importantes para um
controle eficiente?
R:

5– O acervo patrimonial existente em sua unidade atende às necessidades em termos de

flexibilidade ou filtro em consultas diárias?
R:

6 – Quais os critérios que adotam para adquirir novos bens patrimoniais para a sua unidade?
R:

7- Quais os critérios adotados por essa unidade no momento de solicitar o descarte dos bens
patrimoniais?
R:

8– Como classificariam o conteúdo das informações disponíveis para o desempenho das

actividades de (aquisição, guarda, conservação, e descarte) dos bens patrimoniais?
R:

9- Este sector tem conseguido ser eficaz na condução dos processos de inventários físicos:
anuais; e quando da mudança na direção das unidades da instituição? Em caso negativo, por quais
motivos?
R:

10- Que sugestões apresenta para aperfeiçoar o controle do acervo patrimonial da instituição e
para evitar possíveis desperdícios de recursos públicos?