Este trabalho desenvolve um módulo para o sistema de gestão financeira da Universidade Eduardo Mondlane (UEM) focado no registo e distribuição do orçamento do Estado. O módulo visa resolver os problemas atuais no processo moroso e ineficiente de registo e distribuição do orçamento entre os centros de despesa da UEM. O trabalho inclui uma análise de requisitos e modelagem lógica do módulo proposto com diagramas de casos de uso, sequência, classes e modelo conceptual de dados.

1. Universidade Politécnica
A Politécnica
Escola Superior de Gestão, Ciências e Tecnologias
Licenciatura em Engenharia Informática e de Telecomunicações
SISTEMA DE GESTÃO FINANCEIRA DA UEM:
MÓDULO DE REGISTO E DISTRIBUIÇÃO DE ORÇAMENTO DO ESTADO
JESSE GALBO ISSUFO
MAPUTO
2018

2. Universidade Politécnica
Escola Superior de Gestão, Ciências e Tecnologias
Licenciatura em Engenharia Informática e de Telecomunicações
SISTEMA DE GESTÃO FINANCEIRA DA UEM:
MÓDULO DE REGISTO E DISTRIBUIÇÃO DE ORÇAMENTO DO ESTADO
Jesse Galbo Issufo
SUPERVISOR: dr. Marcelo Viriato Munguanaze
Monografia apresentada a Escola Superior de
Gestão e Tecnologias – Universidade
Politécnica, como parte dos requisitos para
obtenção do grau de Licenciatura em
Engenharia Informática e de
Telecomunicações
MAPUTO
2018

3. JESSE ISSUFO I
PARECER DO SUPERVISOR

4. JESSE ISSUFO II
DECLARAÇÃO DE HONRA
Eu, Jesse Galbo Issufo, nascido aos 29 de Agosto de 1996, filho de Galbo Issufo e de Arsénia Rosa
Manuel, discente da Universidade Politécnica, no curso de engenharia informática e de
telecomunicações, declaro por minha honra que este trabalho é resultado da minha pesquisa
pessoal e das orientações do meu tutor, feita segundo os critérios em vigor na Universidade
Politécnica. O seu conteúdo é original e todas as fontes consultadas estão devidamente
mencionadas no texto e na bibliografia.
Maputo, Junho de 2018
__________________________________________________
(Jesse Galbo Issufo)

5. JESSE ISSUFO III
AGRADECIMENTOS
Em primeiro lugar agradecer a Allah pela vida, saúde e tudo que me tem dado ao longo deste
período.
Aos meus pais pela força, motivação, critica e companheirismo durante toda a minha vida e
principalmente na vida académica.
Endereço os meus sinceros agradecimentos aos meus Professores do Curso de Licenciatura em
Engenharia Informática e Telecomunicações, pela dedicação, disponibilidade e competência que
demostraram ao longo do curso, disseminando conhecimento.
Agradecimento especial vai para ao dr. Marcelo Munguanaze, a dra. Antonieta Macuacua, a eng.
Gilda Cossa, ao eng. Valdo Chuquela, a Lina Ussene, ao eng. Momade Abuld e ao Milton Goane
pela dedicação, interesse, motivação e paciência durante a elaboração do trabalho
Os agradecimentos estendem-se aos colegas de turma Algy Adamo, Danilo Saleiro, Einstein Bata,
Elon Feliciano, Jaime Castelo e Leocílio Buque pelo companheirismo e por me ajudarem uma
grande barreira que é o egoísmo, e também aos amigos de infância Edilson Mavie, Faizal Pelela e
Rubens Vilanculos que me ensinaram a perseguir os meus objectivos e não desistir, lutando para
superar todas as barreiras no meu caminho.
À minha família e a todos aqueles quem de forma directa e indirecta contribuíram para que este
trabalho se tornasse uma realidade.

6. JESSE ISSUFO IV
RESUMO
O presente trabalho, pretende explorar as Tecnologias de Informação e Comunicação (TICs) no
âmbito da gestão financeira, concretamente no desenvolvimento de um módulo para o sistema para
a gestão financeira da Universidade Eduardo Mondlane (UEM). Sendo este sistema pertencente
ao UEM.eCampus, que é uma plataforma para albergar iniciativas TICs desenvolvidas nas
unidades orgânicas da UEM.
Sendo a UEM uma instituição de ensino pública, esta recebe fundos provenientes do Estado para
que possa se manter um funcionamento, fundos estes que devem ser registados e posteriormente
distribuídos pelos centros de despesa das unidades orgânicas da UEM. Este processo de registo e
distribuição do orçamento em um dado ciclo, até este momento, é moroso e de certa forma ineficaz
e ineficiente, pois para fazer a distribuição pelos centros de despesa é preciso tomar em conta
vários critérios, estes que se mal verificados fazem com que a haja uma certa discrepância entre o
orçamento registado e distribuído e o orçamento posteriormente contabilizados.
Este trabalho tem como objectivo desenvolver um módulo do sistema informático que irá
responder as necessidades da Direcção de Finanças (DFin) da Universidade Eduardo Mondlane
(UEM), mas com o foco no registo e distribuição do orçamento da UEM, resolvendo assim o
problema que a DFin vinha enfrentando para controlar estes processos. E para a realização deste
trabalho foi usada a metodologia descritiva pois foi necessário fazer a colecta de dados e com os
dados recolhidos modelar o módulo. Com a realização deste trabalho espera-se os melhores
resultados no âmbito de gestão financeira no Direcção de Finanças, podendo contribuir para a
melhoria no exercício económico.
Palavras chave: Sistemas informáticos, Gestão financeira, Uso de sistemas informáticos,
Integração de dados, Virtualização, Tecnologia de Informação e Comunicação.

7. JESSE ISSUFO V
ABSTRACT
The present work intends to explore the area of Information and Communication Technologies
(ICTs) within the scope of financial management, specifically in the development of a module for
the financial management system of Eduardo Mondlane University (UEM). This system belongs
to UEM.eCampus, which is a platform to host ICT initiatives developed in the organic units of
UEM.
Since UEM is a public educational institution, it receives funds from the State so that it can be run,
which funds must be registered and subsequently distributed to the organic units expense centers.
This process of recording and distributing the budget in a given cycle, up to this point, is time
consuming and inefficient and inefficient, since in order to distribute the expenditure centers it is
necessary to take into account several criteria, that leads to a certain discrepancy between the
budget recorded and distributed and the budget subsequently accounted for.
This work aims to develop a computer system module that will respond to the needs of the Eduardo
Mondlane University (UEM) Finance Department (DFin), but with a focus on the registration and
distribution of the UEMs budget, thus solving the problem that the DFin had been facing to control
these processes. In addition, for the accomplishment of this work the descriptive methodology was
sed because it was necessary to do the data collection and with the collected data modeling the
module. With the accomplishment of this work the best results are expected in the scope of
financial management in the Finance Department, being able to contribute to the improvement in
the economic exercise.
Keywords: Computer systems, financial management, Use of computer systems, Data integration,
Virtualization, Information and Communication Technology.

8. JESSE ISSUFO VI
ÍNDICE
1. CAPÍTULO I – INTRODUÇÃO ..........................................................................................................1
1.1. Problema de investigação..............................................................................................................2
1.2. Perguntas a investigar e hipóteses a considerar ............................................................................3
1.2.1. Perguntas a investigar ...........................................................................................................3
1.2.2. Hipóteses H0 e H1 ................................................................................................................3
1.3. Objectivos .....................................................................................................................................4
1.3.1. Objectivo Geral.....................................................................................................................4
1.3.2. Objectivos Específicos..........................................................................................................4
1.4. Justificativa ...................................................................................................................................5
1.5. Delimitações do trabalho ..............................................................................................................6
1.6. Processo de investigação...............................................................................................................6
2. CAPÍTULO II – REVISÃO BIBLIOGRÁFICA ..................................................................................7
2.1. Tecnologia de informação.............................................................................................................7
2.2. Desenvolvimento profissional de software...................................................................................7
2.3. Gestão Financeira..........................................................................................................................8
2.3.1. Estrutura Organizacional da gestão financeira da UEM .......................................................9
2.4. Sistemas de Informação para Gestão Financeira ........................................................................10
2.5. Modelos de processo de software ...............................................................................................12
2.5.1. Modelo de desenvolvimento incremental ...........................................................................13
2.5.2. Rational Unified Process (RUP) .........................................................................................13
2.6. Engenharia de requisitos.............................................................................................................16
2.6.1. Identificação dos requisitos.................................................................................................17
2.6.2. Requisitos funcionais..........................................................................................................18
2.6.3. Requisitos não funcionais ...................................................................................................18
2.6.4. Validação de Requisitos......................................................................................................19
2.7. Diagramas Lógicos .....................................................................................................................20
2.7.1. Diagrama de classes............................................................................................................21
2.7.2. Diagrama de casos de uso ...................................................................................................22
2.7.3. Diagrama de sequência .......................................................................................................23
2.7.4. Diagrama de actividades .....................................................................................................24

9. JESSE ISSUFO VII
2.8. Modelação de dados....................................................................................................................25
3. CAPÍTULO III – METODOLOGIA ..................................................................................................27
4. CAPÍTULO IV – CASO DE ESTUDO..............................................................................................29
4.1. Direcção de Finanças ..................................................................................................................29
4.2. Cenário actual do registo do orçamento geral do Estado na UEM .............................................29
4.3. Cenário actual da distribuição do orçamento geral do Estado pelos centros de despesa............30
4.4. Cenário actual do reajuste do plano de actividades e orçamento................................................31
5. CAPÍTULO V – ANÁLISE DE REQUISITOS E MODELAGEM DO MÓDULO PROPOSTO ....33
5.1. Visão geral do módulo de registo e distribuição do orçamento geral do Estado ........................34
5.2. Descrição do funcionamento do módulo de registo e distribuição do orçamento geral do Estado
35
5.3. Requisitos do módulo .................................................................................................................36
5.3.1. Requisitos Funcionais do módulo.......................................................................................37
5.3.2. Requisitos não funcionais ...................................................................................................39
5.3.3. Regras de Negócio do módulo............................................................................................39
5.4. Diagramas Lógicos .....................................................................................................................40
5.4.1. Diagrama de Casos de Uso .................................................................................................40
5.4.2. Descrição dos Casos de uso ................................................................................................41
5.4.3. Diagrama de Sequência.......................................................................................................44
5.4.4. Diagrama de Actividades....................................................................................................47
5.4.5. Diagrama de Classes...........................................................................................................48
5.5. Modelo Conceptual de dados......................................................................................................49
6. CAPITULO VI – CONCLUSÕES E RECOMENDAÇÕES..............................................................51
6.1. Conclusões..................................................................................................................................51
6.2. Recomendações...........................................................................................................................53
7. Bibliografia .........................................................................................................................................54
8. ANEXOS ............................................................................................................................................58

10. JESSE ISSUFO VIII
ÍNDICE DE FIGURAS
Figura 2.1 – Estrutura Organizacional da Direcção de Finanças......................................................9
Figura 2.2 – Áreas de decisão da gestão Financeira .......................................................................10
Figura 2.3 – Ilustração do funcionamento de um sistema de informação........................................11
Figura 2.4 – Ilustração do funcionamento do modelo incremental.................................................13
Figura 2.5 – Fases do RUP .............................................................................................................14
Figura 2.6 – Ilustração do processo de engenharia de requisitos.....................................................17
Figura 4.1 – Cenário do registo do orçamento geral do Estado…………………………………...30
Figura 4.2 – Cenário da distribuição do orçamento geral do Estado por centros de despesa……...31
Figura 4.3 – Cenário do plano de actividades e orçamento…………………………….................32
Figura 5.1 – Visão geral do funcionamento do módulo...................................................................34
Figura 5.2 – Diagrama de casos de uso...........................................................................................40
Figura 5.3 – Diagrama de sequencia do caso de uso: Registar Orçamento do Estado para Unidades
Descentralizadas............................................................................................................................45
Figura 5.4 – Diagrama de sequencia do caso de uso: Registar Orçamento Geral do Estado para
UEM...............................................................................................................................................46
Figura 5.5 – Diagrama de sequencia do caso de uso: Distribuir Orçamento Geral do Estado pelos
centros de despesa da UEM............................................................................................................47
Figura 5.6 – Diagrama de actividades interfuncional do módulo....................................................48
Figura 5.7 – Diagrama de classes do módulo..................................................................................49
Figura 5.8 – Modelo conceptual de dados do módulo.....................................................................50

11. JESSE ISSUFO IX
ÍNDICE DE TABELAS
Tabela 2.1 – Exemplos de sistemas financeiros..............................................................................12
Tabela 2.2 – Técnicas de validação de requisitos............................................................................20
Tabela 5.1 – Requisitos funcionais do módulo...............................................................................38
Tabela 5.2 – Requisitos não funcionais do módulo.........................................................................39
Tabela 5.3 – Requisitos regras de negócio do módulo....................................................................39
Tabela 5.4 – Descrição do caso de uso: Registar Orçamento do Estado para Unidades
Descentralizadas............................................................................................................................42
Tabela 5.5 – Descrição do caso de uso: Registar Orçamento Geral do Estado para UEM...............43
Tabela 5.6 – Descrição do caso de uso: Distribuir Orçamento Geral do Estado pelos centros de
despesa da UEM.............................................................................................................................44

12. JESSE ISSUFO X
LISTA DE SIGLAS
CIUEM – Centro de Informática da Universidade Eduardo Mondlane
CUN – Conselho Universitário.
DFin – Direcção de Finanças
DSI – Desenvolvimento de Sistemas de Informação
DSM – Departamento de Sistemas e Multimédia
GPLAN – Gabinete de Planificação
MEF – Ministério da Economia e Finanças
SIBC – Sistema Informático Baseado em Computador
SIGF – Sistema Integrado de Gestão Financeira
SIPMA – Sistema Integrado de Planificação e Monitoria de Actividades
TICs – Tecnologias de Informação e Comunicação
UEM – Universidade Eduardo Mondlane

13. JESSE ISSUFO 1
1. CAPÍTULO I – INTRODUÇÃO
O presente trabalho tem a ver com a Universidade Eduardo Mondlane (UEM), concretamente com
Centro de Informática (CIUEM), onde o autor realizou o estágio académico. No período do estagio
o autor foi integrado no Departamento de Sistemas e Multimédia, nas equipas de análise e desenho
de sistemas e de desenvolvimento de sistemas, onde teve a oportunidade de praticar os
conhecimentos de levantamento e análise de requisitos, modelação de base de dados, prototipação
e desenvolvimento de sistemas em equipa.
Na UEM decorre um projecto chamado UEM.eCampus, que é uma plataforma para acomodar as
iniciativas de Tecnologias de Informação e Comunicação (TICs) desenvolvidas nas diversas
unidades orgânicas da UEM permitindo, deste modo, facilitar a partilha de dados e recursos entre
os diversos actores da vida da UEM. Sendo que durante o estágio, o autor esteve também envolvido
com o desenvolvimento do Sistema de Gestão Financeira (SIGF).
Na sequência o autor notou que poderia contribuir desenvolvendo o Módulo de Registro e
Distribuição do Orçamento Geral do Estado, o qual é o objecto deste trabalho.
Actualmente o registo e distribuição de orçamento geral na UEM é feito de forma manual, isto é,
os dados são gravados em planilhas Excel. Tornando assim esta importante tarefa complicada, pois
há casos de erros no registo do orçamento que levam a discrepância entre este orçamento e o
orçamento posteriormente contabilizados, então surge a necessidade de um módulo capaz de
minimizar os erros e poder ter maior controle sobre os dados e sobre todo esse processo.
Neste contexto, este trabalho pretende implementar sistemas informáticos para a gestão financeira,
para que esta possa registar o orçamento geral da UEM e distribuir o orçamento pelos centros de
despesa das unidades orgânicas, criando assim um ambiente de maior interacção entre elas.
Para isto será necessário fazer uma analise sobre a forma de recolha de dados actual através de
entrevistas, encontros com stakeholders e engenharia de requisitos e modelação da base de dados
e do próprio sistema.

14. JESSE ISSUFO 2
1.1. Problema de investigação
Para o começo do exercício económico nas unidades orgânicas da UEM é necessário que lhes
sejam fornecidos os respectivos orçamentos, provenientes do Estado. Compete a Direcção de
Finanças da UEM registar o orçamento aprovado e distribuir o mesmo entre as unidades orgânicas,
de acordo com o plano de actividades de cada uma.
Dai que começam os constrangimentos pois este processo é feito em planilhas Excel que podem
facilmente ser alteradas e que por qualquer descuido podem resultar numa má distribuição do
orçamento, sem contar com a falta de automatização de processos como a verificação do
orçamento registado e distribuído no ciclo anterior que é tomada em conta antes que seja feita a
nova distribuição.
A falta de um módulo no sistema de gestão financeira para o registo e distribuição do orçamento
da UEM, tem criado um certo desconforto para a Direcção de Finanças da UEM, pois a falta de
automatização dos processos entre o registro e distribuição causam uma certa discrepância entre o
orçamento aprovado pelo governo e distribuição do orçamento pelas unidades orgânicas e órgãos
centrais da UEM, e o orçamento contabilizado posteriormente.
.

15. JESSE ISSUFO 3
1.2. Perguntas a investigar e hipóteses a considerar
1.2.1. Perguntas a investigar
De que forma o desenvolvimento do módulo de registo e distribuição do orçamento geral do Estado
para o sistema de gestão financeira ajudará na gestão financeira na Universidade Eduardo
Mondlane?
1.2.2. Hipóteses H0 e H1
H0: Com o desenvolvimento do módulo de registo e distribuição do orçamento geral do Estado, a
DFin não conseguirá amenizar ou solucionar a discrepância entre o orçamento registado e o
orçamento distribuído.
H1: Com o desenvolvimento do módulo de registo e distribuição do orçamento geral do Estado, a
DFin poderá efectuar este processo de forma organizada, tendo maior controle sobre o orçamento
geral do Estado na UEM.

16. JESSE ISSUFO 4
1.3. Objectivos
1.3.1. Objectivo Geral
 Desenvolver o módulo de registo e distribuição do orçamento geral do Estado do sistema
de gestão de finanças da UEM.
1.3.2. Objectivos Específicos
 Efectuar o levantamento de requisitos e identificar os fluxos correntes de registo e
distribuição do orçamento geral do Estado na UEM;
 Conceber o modelo conceptual do módulo;
 Conceber o módulo de registo e distribuição de orçamento geral do Estado do sistema de
gestão financeira.

17. JESSE ISSUFO 5
1.4. Justificativa
Tendo Moçambique apresentado um elevado crescimento nas áreas tecnológicas, é importante que
todas as outras áreas possam ser beneficiadas, sendo estas optimizadas, de forma a que funcionem
de forma eficiente, continua e prática, criando maior dinamismo no acesso e partilha de informação
e também um certo apoio a decisões, assim, o uso de softwares de apoio tem crescido em varias
áreas.
Levando como exemplo, o caso do registo criminal, que até a alguns anos atrás trabalhava com
arquivos físicos, que contavam com grandes constrangimentos desde o registo dos dados, até ao
acesso dos mesmos, mas actualmente com o uso de sistemas informáticos, todos os processos
puderam ser optimizados de forma a que o acesso e partilha de informação passou a ser em tempo
real.
Durante o estagio académico no Centro de informática da Universidade Eduardo Mondlane o autor
pôde fazer parte de equipa de desenvolvimento do Sistema de Gestão Financeira da UEM, onde
pôde perceber que poderia contribuir com o desenvolvimento do módulo de registo e distribuição
do orçamento geral do Estado na UEM.
Este processo é feito de forma manual, desta forma em todos os ciclos económicos devem ser
criadas planilhas Excel para poder registar e distribuir o orçamento. Para realização deste processo,
é necessário tomar em conta vários parâmetros, em consequência disso, vários erros podem ocorrer
durante este processo, criando uma discrepância entre o orçamento realmente aprovado e
orçamento contabilizado, então alem de tornar este processo moroso, a falta de um módulo pode
criar mais constrangimentos como a perda de informação.
Desta forma, é fácil perceber o quão é vantajoso é o uso de sistemas informáticos nas instituições
e para o caso do tema, será desenvolvendo um modulo capaz de dinamizar os processos de evitar
e controlar a discrepância entre o orçamento geral do Estado aprovado para UEM e orçamento
contabilizado posteriormente e distribuição do orçamento pelos centros de despesas das unidades
orgânicas e órgãos centrais.

18. JESSE ISSUFO 6
1.5. Delimitações do trabalho
Este trabalho irá apenas abranger o desenvolvimento do módulo de registo e distribuição do
orçamento geral do Estado do sistema de gestão financeira da Universidade Eduardo Mondlane.
Se focando nas áreas de análise e desenho do sistema, modelação da base de dados,
desenvolvimento e implementação do sistema.
1.6. Processo de investigação
A investigação será conduzida através da colecta de dados, análise de dados e prototipagem, onde
o autor fará a colecta de dados através de certas entrevistas, consultas e revisões bibliográficas
identificando os requisitos funcionais e não funcionais mais importantes e essências para que o
módulo do sistema seja modelado e desenvolvido de acordo com as exigências dos usuários. Após
essa colecta de dados, segue a analise de dados que consistirá na construção dos diagramas lógicos
e suas descrições, modelagem da base de dados e dos fluxos para poder implementar no sistema o
fluxo actual de dados. Tendo os requisitos e os fluxos para o sistema, o autor criará um protótipo
de forma a ter um modelo para que possa se basear ao desenvolver o modulo do sistema.

19. JESSE ISSUFO 7
2. CAPÍTULO II – REVISÃO BIBLIOGRÁFICA
2.1. Tecnologia de informação
Sousa (2009:18) afirma que as tecnologias de informação dizem respeito a processos de
tratamento, controlo e comunicação de informação, baseados em meios electrónicos, portanto,
computadores ou sistemas informáticos.
E com o uso dos computadores e os periféricos de entradas e de saída é possível resolver muitos
problemas concretos do dia-a-dia, e os sistemas computadorizados prestam serviços que são
normalmente designados aplicações. (Nabais 1993:22).
Para Nabias (1993) a automatização das actividades administrativas aumentam a rendibilidade das
diversas funções a executar em qualquer escritório electrónico. Esta pode ser usada para fins
administrativos, de planeamento e no processo de tomada de decisões, e o uso da informática
permite que a informação seja tratada e analisada mais rápida e eficientemente contribuindo para
maior eficácia da gestão.
2.2. Desenvolvimento profissional de software
Diferente dos softwares criados para uso do próprio desenvolvedor como, por exemplo, cientistas
e engenheiros que escrevem programas para processar seus dados experimentais, ou mesmo por
aqueles que escrevem programa como hobby (apenas por diversão), os softwares profissionais são
usados por alguém diferente do seu desenvolvedor. Estes são normalmente criados por equipas em
vez de indivíduos, e são mantidos e alterados durante a vida. (Sommerville 2011)
Para Sommerville (2011:3) a engenharia de software tem por objectivo apoiar o desenvolvimento
profissional de software, mais do que a programação individual. Ela inclui técnicas que apoiam
especificação, projecto e evolução de programas, que normalmente não são relevantes para o
desenvolvimento de software pessoal.

20. JESSE ISSUFO 8
Normalmente, quando surge a palavra software, as pessoas pensam em simples programas para
computador, mas quando falamos de engenharia de software, falamos não só do programa em si,
mas de toda a documentação associada e dados de configuração necessários para fazer esse
programa operar da melhor forma. (Sommerville 2011)
Ao falar de sistemas de software Sommerville (2011:3) diz que:
Um sistema de software desenvolvido profissionalmente é, com frequência, mais do que
apenas um programa; ele normalmente consiste em uma série de programas separados e
arquivos de configuração que são usados para configurar esses programas. Isso pode incluir
documentação do sistema, que descreve a sua estrutura; documentação do usuário, que
explica como usar o sistema; e sites, para usuários baixarem a informação recente do
produto.
Ao escrever um programa para uso próprio, onde ninguém mais usará, não há necessidade de se
preocupar com a documentação, diferente do caso onde escrevemos um programa para outras
pessoas usarem e onde outros poderão fazer alterações, então surge a necessidade de documentar
e até mesmo fornecer o código do programa. (Sommerville 2011)
2.3. Gestão Financeira
O termo gestão é muito usado no campo empresarial, sendo este, muitas vezes designado como o
acto de gerenciar recursos de forma eficiente para que as metas ou objectivos pré-estabelecidos
sejam alcançados.
A gestão financeira é área de administração que cuida dos recursos financeiros da empresa, ou
seja, trata de processos, instituições, mercados e instrumentos envolvidos na transferência de
recursos entre pessoas, empresas e governos. (Chiavenato 2014)
Para Chiavenato (2014:13) a gestão financeira é designada como a ciência e a arte de administrar
fundos, envolvendo a aplicação de princípios económicos e financeiros no sentido de maximizar
a riqueza da empresa e do valor das suas acções.

21. JESSE ISSUFO 9
Sendo que Nunes (2017), define a gestão de empresas como uma das tradicionais áreas funcionais
da gestão, encontrada em qualquer organização e à qual cabem as análises, decisões e actuações
relacionados com os meios financeiros necessários à actividade da organização. Desta forma, a
função financeira integra todas as tarefas ligadas à obtenção, utilização e controlo de recursos
financeiros de forma a garantir, por um lado, a estabilidade das operações da organização e, por
outro, a rendibilidade dos recursos nela aplicados.
A maximização do lucro é o objectivo básico da gestão financeira, sendo este a contribuição para
o aumento do valor da empresa pela escolha e selecção dos investimentos que possuem a melhor
compensação entre o risco e o retorno. (Chiavenato 2014)
2.3.1. Estrutura Organizacional da gestão financeira da UEM
Figura 2.1 – Estrutura Organizacional da Direcção de Finanças
Dentro da estrutura organizacional da gestão financeira da UEM, o trabalho se encaixa com
departamento de planeamento e análise financeira (planeamento e controle orçamental), pois este
coordena, com os demais órgãos da instituição, a montagem dos respectivos orçamentos de
Director
Director-Adjunto
Administração e
Secretariado
Departamento de
Execução do Orçamento
do Estado
Departamento do
Fundo de Doações
Departamento de
Mobilização de Funcos e
Gestão de Receitas Próprias
Departamento de
Planeamento e
Análise Financeira

22. JESSE ISSUFO 10
despesa e o seu acompanhamento e controle ao longo do exercício anual, para verificar se as
despesas orçadas estão a ser realizadas adequadamente.
Para Chiavenato (2014), a finalidade do planeamento e controle orçamental é de assessorar todos
os órgãos da empresa na montagem dos orçamentos departamentais e monitorar a sua execução,
apontando os desvios, principalmente quando as despesas realizadas excedem o que foi orçado.
Desta forma, a gestão financeira envolve uma infinidade de decisões, sobre o que fazer com os
recursos financeiros que porventura sobrem, como utilizar adequadamente os recursos disponíveis
e o oque fazer para obter recursos adicionais.
Segundo Chiavenato (2014), a gestão financeira é responsável por três áreas distintas de decisão:
 Captação de recursos financeiros externos no mercado e avaliação dessa captação;
 Utilização de recursos financeiros nas operações cotidianas da empresa e avaliação dessa
utilização;
 Aplicação de recurso financeiros, seja no mercado, em novos negócios ou em outros
investimentos.
Figura 2.2 – Áreas de decisão da gestão Financeira
2.4. Sistemas de Informação para Gestão Financeira
Laudon & Laudon (2007:9) definem um sistema de informação como um conjunto de
componentes inter-relacionados que colectam, processam, armazenam e distribuem informações
Entrada Empresa Saída
Captação
de Recurso
Financeiros
Utilização
de Recursos
Financeiros
Aplicação
de Recursos
Financeiros

23. JESSE ISSUFO 11
com o objectivo de apoiar a tomada de decisões, a coordenação, bem como o controle de uma
instituição.
Sendo estes sistemas de informação, usados para fins administrativos e de planeamento, permitem
uma rápida análise dos recursos da instituição, já que estes tratam e analisam as informações de
forma mais rápida e eficiente, contribuindo para maior eficácia da gestão. (António 2015)
Desta forma, fica claro que os sistemas de informações, pegam em dados, que são sequencias de
factos brutos, que depois de organizados e arranjados de uma forma que as pessoas possam
entende-las geram informações.
Para a produção destas informações que as instituições necessitam para tomar decisões, controlar
operações e analisar problemas, um sistema de informação deve realizar três actividades,
nomeadamente, a entrada, o processamento e a saída. A entrada que captura ou colecta dados
brutos vindos como inputs da instituição ou do seu ambiente externo. O processamento que
converte os dados brutos vindos da entrada em uma forma mais significativa. A Saída que transfere
as informações processadas às pessoas que as utilizarão ou às actividades nas quais elas serão
empregadas. E estes sistemas de informação também querem um feedback, que é a saída que
retorna certas informações aos membros da instituição para ajuda-los a avaliar e corrigir o estagio
de entrada. (Laudon & Laudon 2007)
Figura 2.3 – Ilustração do funcionamento de um sistema de informação
Entrada
Processar
Classificar
Organizar
Calcular
Saída
Feedback
Sistema de Informação

24. JESSE ISSUFO 12
As finanças de uma instituição são responsáveis pela gestão dos activos financeiros, como dinheiro
em caixa, acções, títulos e outros investimentos, então o seu objectivo é maximizar o retorno desses
activos, como foi abordado no ponto anterior. Para conseguir determinar se a instituição está
conseguindo o melhor retorno sobre os investimentos, as finanças devem obter consideráveis
quantidades de informações vindas de fontes externas. (Laudon & Laudon 2007)
Laudon & Laudon (2007) dão alguns exemplos de sistemas financeiros:
Sistema Descrição Grupos Atendidos
Contas a receber Relaciona as contas a receber Gerência operacional
Orçamento Prepara orçamentos de curto
prazo
Gerência média
Planeamento de lucros Planeja lucros ao longo prazo Gerência sénior
Tabela 2.1 – Exemplos de sistemas financeiros
A tabela mostra alguns sistemas de informação financeiros típicos encontrados em grandes
instituições. A gerência sénior usa tais sistemas para estabelecer as metas de investimento de longo
prazo da empresa e fazer previsões de longo alcance para seu desempenho financeiro. A gerência
média, por sua vez, utiliza-os para supervisionar e controlar os recursos financeiros da empresa. E
por fim, a gerência operacional emprega os sistemas financeiros para monitorar o fluxo de recursos
da instituição realizados por meio de transacções. (Laudon & Laudon 2007)
2.5. Modelos de processo de software
Para Sommerville (2011:19) um modelo de processo de software é uma representação simplificada
de um processo de software. Cada modelo representa uma perspectiva particular de um processo
e, portanto, fornece informações parciais sobre ele.
Existem vários modelos de processo de software como: o modelo de cascata; o modelo baseado
em componentes; o modelo espiral; o desenvolvimento incremental; a engenharia de software
orientada a reúso; o paradigma de prototípico; e o processo unificado. Sendo o modelo de
desenvolvimento incremental usado para a elaboração deste trabalho.

25. JESSE ISSUFO 13
2.5.1. Modelo de desenvolvimento incremental
No desenvolvimento incremental a ideia é de desenvolver uma implementação inicial e logo depois
apresentar para a validação do usuário e continuar a desenvolver várias versões até que, o sistema
pedido esteja completo. Actividades de especificação, desenvolvimento e validação são
intercaladas, e não separadas, com rápido feedback entre todas as actividades. (Sommerville 2011)
Figura 2.4 – Ilustração do funcionamento do modelo incremental
Segundo Sommerville (2011:22) o Desenvolvimento incremental de software, que é uma parte
fundamental das abordagens ágeis, é melhor do que uma abordagem em cascata para a maioria dos
sistemas de negócios, e-commerce e sistemas pessoais. Este modelo reflecte a maneira como
resolvemos os problemas, pois geralmente resolvemos os problemas passo a passo então
dificilmente elaboramos uma solução completa para resolver o problema.
2.5.2. Rational Unified Process (RUP)
O Rational Unified Process (RUP) é um exemplo de modelo de processo moderno, derivado de
trabalhos sobre a Unified Modelling Language (UML) e o Unified Software Development Process.
(Sommerville 2011). Este foi desenvolvido com o objectivo de assegurar a produção de sistemas
com qualidade e de poder ser usado num grande numero de projectos e organizações.
Especificação
Desenvolvimento
Validação
Versão inicial
Versão final
Descrição do
esboço
Versões
intermediarias

26. JESSE ISSUFO 14
Segundo Sommerville (2011) o RUP reúne elementos de todos os modelos de processos genéricos,
ilustra boas praticas na especificação e no projecto e apoia a prototipação e a entrega incremental.
Lopes, et al. (2005) e Sommerville (2011), afirmam que o RUP se baseia em seis boas práticas,
que são recomendadas para o uso, de forma a garantir um desenvolvimento de qualidade. Estas
são:
1. Desenvolver o sistema iterativamente – que significa planear os incrementos do sistema
com base nas prioridades do cliente e desenvolver os recursos de alta prioridade no início
do processo de desenvolvimento do sistema.
2. Gerenciar os requisitos – que significa documentar explicitamente os requisitos do
cliente, acompanhar suas mudanças e analisar o impacto das mudanças no sistema antes de
aceitá-las.
3. Usar arquitectura baseadas em componentes – que significa estruturar a arquitectura do
sistema em componentes.
4. Modelar visualmente o sistema – que significa usar modelos gráficos da UML para
apresentar visões estáticas e dinâmicas do sistema.
5. Verificar a qualidade do software – que significa assegurar que o software atenda aos
padrões de qualidade organizacional.
6. Controlar as mudanças do software – que significa gerenciar as mudanças do software,
usando um sistema de gerenciamento de mudanças e procedimentos e ferramentas de
gerenciamento de configuração.
Para Lopes et al. (2005), o RUP se desenrola segundo um processo iterativo organizado em fases,
para assegurar a qualidade de desenvolvimento, no qual define pontos de controlo, onde deve ser
avaliada a consecução ou não do projecto, ou seja, estas fases são estreitamente relacionadas ao
negócio, e não a assuntos técnicos.
Lopes et al. (2005) e Sommerville (2011), descrevem estas fases como:
1. Concepção: O objectivo da fase de concepção é estabelecer um business case para o
sistema. Onde se deve identificar todas as entidades externas (pessoas e sistemas) que vão

27. JESSE ISSUFO 15
interagir com o sistema e definir as interacções. Desta forma, os principais requisitos são
identificados para reunir um consenso de aceitação sobre o produto final, que é sempre um
Sistema de Informação Baseado em Computador. Esta fase também tem como objectivo
planear, avaliar riscos, custos e vantagens do projecto em causa.
2. Elaboração: As metas da fase de elaboração são desenvolver uma compreensão do
problema dominante, estabelecer um framework da arquitectura para o sistema,
desenvolver o plano do projecto e identificar os maiores riscos do projecto. No fim dessa
fase, você deve ter um modelo de requisitos para o sistema, que pode ser um conjunto de
casos de uso da UML, uma descrição da arquitectura ou um plano de desenvolvimento do
software.
3. Construção: Esta é a fase de fabricação, onde os componentes são desenvolvidos e
integrados num ponto final, sendo cuidadosamente testados. Durante essa fase, as partes
do sistema são desenvolvidas em paralelo e integradas. Na conclusão dessa fase, pretende-
se ter um sistema de informático já a funcionar, bem como a documentação associada
pronta para ser entregue aos usuários. Deve-se também avaliar se o produto está em
condições de ser usado pelos utilizadores e se estes estão preparados para a introdução de
um novo sistema.
4. Transição: A fase final do RUP implica transferência do sistema da comunidade de
desenvolvimento para a comunidade de usuários e em seu funcionamento em um ambiente
real. Isso é ignorado na maioria dos modelos de processo de software, mas é, de fato, uma
actividade cara e, às vezes, problemática. Pois para o caso da substituição do sistema antigo
pelo novo, as bases de dados são convertidas e os utilizadores treinados, para que o sistema
possa estar em operação. Na conclusão desta fase, se deve ter um sistema de software
documentado e a funcionar correctamente em seu ambiente operacional.

28. JESSE ISSUFO 16
Concepção Elaboração Construção Transição
I1 E1 E2 C1 C2 C3 C4 T1 T2
Modelagem de Negócio
Requisitos
Análise e Design
Implementação
Teste
Implantação
Figura 2.5 – Fases do RUP
2.6. Engenharia de requisitos
Sommerville (2011) explica que os requisitos de um sistema são as descrições do que o sistema
deve fazer, os serviços que oferece e as restrições a seu funcionamento. Esses requisitos reflectem
as necessidades dos clientes para um sistema que serve a uma finalidade determinada, como
controlar um dispositivo, colocar um pedido ou encontrar informações.
Para Pfleeger (2004), um requisito é uma característica do sistema ou a descrição de algo que o
sistema é capaz de realizar, para atingir os seus objectivos.
Normalmente estes requisitos correspondem a actividades ou processos, novos ou antigos, então
o sistema é um aprimoramento de algo já feito de forma manual, ou mesmo automática.

29. JESSE ISSUFO 17
Figura 2.6 – Ilustração do processo de engenharia de requisitos
2.6.1. Identificação dos requisitos
A identificação de requisitos é uma parte especialmente importante do processo, onde devemos
utilizar uma variedade de técnicas para determinar o que os usuários e os clientes realmente
querem. Devemos trabalhar com os clientes e usuários, com o objectivo de entender o problema
quando ainda não encontramos uma solução para ele. Descobrimos quais itens de dados são
passados de uma função para outra e quais os processos transformam os dados de uma forma ou
estado para outro. (Pfleeger 2004)
Pfleeger (2004), diz que é útil separar os requisitos em prioridades:
1. Requisitos que devem ser totalmente satisfeitos;
2. Requisitos que são altamente desejáveis, mas não necessários;
3. Requisitos que são possíveis, mas podem ser eliminados;
Ao fazer a descrição dos requisitos surge uma necessidade de separa-los em diferentes níveis para
que diferentes leitores possam usa-los e estes seriam: requisitos de usuário e os requisitos de
sistema. Que são descritos por Sommerville (2011:58) como:
 Os Requisitos de usuário são declarações, em uma linguagem natural com diagramas, de
quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este
deve operar.
Análise do
Problema
Descrição do
Problema
Prototipação e
Testes
Documentação
e Validação
Identificação e Análise dos Requisitos
Definição e Especificação
do Requisitos
Identificamos
todas
necessidades dos
usuários?
Estamos a utilizar as
técnicas e pontos de
vista certos?
A função é viável?
Conseguimos o que os
usuários esperavam?

30. JESSE ISSUFO 18
 Requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições
operacionais do sistema de software. O documento de requisitos do sistema deve definir
exactamente o que deve ser implementado. Pode ser parte do contracto entre o comprador
do sistema e os desenvolvedores de software.
Os requisitos são ainda classificados em: requisitos funcionais e requisitos não funcionais;
2.6.2. Requisitos funcionais
Os requisitos funcionais descrevem o que o sistema deve fazer, como deve reagir, o que deve
conter. Estes podem mudar de acordo com o tipo de software a ser desenvolvido e pela forma da
qual será aplicada e usada. (Sommerville 2011)
Podendo também, descrever uma interacção entre o sistema e seu ambiente, identificando como o
sistema deve se comportar, considerando um certo estimulo, sem discutir sobre que computador
especifico e linguagem de programação serão usadas, ou as estruturas de dados internas
envolvidas. (Pfleeger 2004)
Segundo Sommerville (2011:59) quando expressos como requisitos de usuário, os requisitos
funcionais são normalmente descritos de forma abstracta, para serem compreendidos pelos
usuários do sistema. No entanto, requisitos de sistema funcionais mais específicos descrevem em
detalhes as funções do sistema, suas entradas e saídas, excepções etc.
2.6.3. Requisitos não funcionais
Sommerville (2011:60) define os requisitos não funcionais como:
Requisitos que não estão directamente relacionados com os serviços específicos oferecidos pelo
sistema a seus usuários. Eles podem estar relacionados a propriedades emergentes do sistema,
como confiabilidade, tempo de resposta e ocupação de área. Uma alternativa a esse cenário seria
os requisitos definirem restrições sobre a implementação do sistema, como as capacidades dos
dispositivos de E/S ou as representações de dados usadas nas interfaces com outros sistemas.

31. JESSE ISSUFO 19
Pleeger (2004), também diz que os requisitos funcionais colocam restrições no sistema, ou seja,
descrevem restrições no sistema que limitam as nossas opções para criar soluções para o problema.
Todavia, a selecção é feita no estagio do projecto, depois que os requisitos tenham sido
especificados.
Os requisitos não funcionais surgem por meio das necessidades dos usuários, devido a restrições
de orçamento, políticas organizacionais, necessidade de interoperabilidade com outros sistemas de
software ou hardware, ou a partir de factores externos, como regulamentos de segurança ou
legislações de privacidade. (Sommerville 2011:60)
2.6.4. Validação de Requisitos
Para poder verificar se os requisitos definem o sistema que o cliente realmente quer é necessário
um processo de validação, e esta, está preocupada em encontrar problemas com os requisitos.
Durante o desenvolvimento ou após o sistema estar em uso, as descobertas de erros no documento
de requisitos podem gerar altos custos de retrabalho, pois, o custo para consertar um problema de
requisitos por meio de uma mudança no sistema é geralmente muito maior do que o custo de
consertar erros de projecto ou de codificação, isso acontece porque, muita coisa já pode estar
preparada de forma que não agrade ao cliente. (Sommerville 2011:76)
Então a validação de requisitos é o processo que determina se a especificação é consistente com a
definição dos requisitos, isto assegura que os requisitos atenderão às necessidades dos clientes.
Pleeger (2004)
Diversos tipos de verificação podem ser efectuados com os requisitos no documento segundo
Sommerville (2011), que são: verificações de validade; verificações de consistência; verificações
de completude; verificações realismo e a verificabilidade.
Existem técnicas para a validação de requisitos que podem ser usadas individualmente e em grupo,
e Sommerville (2011:77) descreve como:
 Revisões de requisitos: os requisitos são analisados sistematicamente por uma equipe de
revisores que verifica erros e inconsistências.

32. JESSE ISSUFO 20
 Prototipação: nessa abordagem para validação, um modelo executável do sistema em
questão é demonstrado para os usuários finais e clientes. Estes podem experimentar o
modelo para verificar se ele atende a suas reais necessidades.
 Geração de casos de teste: os requisitos devem ser testáveis. Se os testes forem concebidos
como parte do processo de validação, isso frequentemente revela problemas de requisitos.
Se é difícil ou impossível projectar um teste, isso normalmente significa que os requisitos
serão difíceis de serem implementados e devem ser reconsiderados.
Pleeger (2004) também indica algumas técnicas de validação de requisitos, que sao:
Técnicas de validação de requisitos
Técnicas manuais Leitura
Referência cruzada manual
Entrevistas
Revisões
Listas de verificação
Modelos manuais para verificar funções e
relações
Técnicas automatizadas Referência cruzada automatizada
Modelos automatizados para activar as
funções
Protótipos
Tabela 2.2 – Técnicas de validação de requisitos
2.7. Diagramas Lógicos
Um sistema orientado a objectos é composto de objectos interactivos que mantêm seu próprio
estado local e oferecem operações nesse estado. Processos de projecto orientado, os objectos
envolvem projectar as classes de objectos e os relacionamentos entre essas classes. (Sommerville
2011:125)

33. JESSE ISSUFO 21
Para poder fazer essa representação é geralmente usada a UML (Unified Modelling Language),
que é uma linguagem de diagramas para especificar, visualizar e documentar modelos de software
orientados por objectos. (Macêdo 2012)
A UML é composta por vários diagramas, mas esta não obriga o uso de todos, o desenvolvedor
apenas faz uso dos diagramas que forem necessários para documentar os modelos. Estes diagramas
estão subdivididos em duas grandes categorias, sendo, os diagramas estruturais, que mostram a
estrutura estática do sistema, e os diagramas comportamentais, que mostram o comportamento
dinâmico entre os objectos no sistema incluindo métodos, colaborações e actividades. (Bell 2016)
Dos diagramas apenas irei abordar os usados durante o desenvolvimento do trabalho, sendo, da
categoria dos diagramas estruturais o diagrama de classe, e da categoria dos diagramas
comportamentais o diagrama de casos de uso, diagrama de sequência e o diagrama de actividades.
2.7.1. Diagrama de classes
Macêdo (2012) afirma que os diagramas de classe são chamados diagramas estáticos porque
mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre
elas: quais classes conhecem quais classes ou quais classes são parte de outras classes, mas não
mostram a troca de mensagens entre elas.
Desta forma, as classes servem dois propósitos: permitem compreender o mundo real naquilo que
é relevante para o sistema de informação que se pretende desenvolver e fornecem uma base prática
para a implementação em computador. (Nunes & O’Neill 2003)
Segundo Nunes & O’Neill (2003) a perspectiva estática fornecida pelo diagrama de classes tem
como objectivo suportar os requisitos funcionais do sistema, que foram levantados durante a
identificação e analise de requisitos, sendo o resultado deste, um modelo que será usado na fase
de desenho.
Neste diagrama, podemos mostrar os diferentes níveis de acesso que cada atributo e método podem
assumir, sendo, público (significa que ele pode ser acedido de qualquer lugar da classe ou
subclasse); protegido (significa que ele só pode ser acedido de dentro da própria classe ou em suas

34. JESSE ISSUFO 22
classes-filha); ou privado (significa que ele só pode ser acedido de dentro da própria classe).
(Macêdo 2012)
Tendo já determinado os métodos e atributos de uma classe, é necessário que se representem as
associações, estão são as relações entre os objectos. As associações são caracterizadas por terem
um nome e quando necessário, podem também incluir o papel que os objectos têm na relação.
Após se identificar as associações é necessário se identificar a cardinalidade de uma associação,
mais conhecida como multiplicidade, e esta serve para indicar quantos objectos participam na
relação. (Nunes & O’Neill 2003)
2.7.2. Diagrama de casos de uso
Diagramas de casos de uso descrevem relacionamentos e dependências entre um grupo de casos
de uso e os actores participantes no processo. Então os casos de uso são descrições de interacções
típicas entre os usuários de um sistema e o sistema propriamente dito. Os usuários do sistema são
chamados de actores, e um actor é uma entidade externa (fora do sistema) que interage com o
sistema participando em um caso de uso. Actores podem ser pessoas reais (por exemplo usuário
do sistema), outro sistema de computador ou eventos externos. (Macêdo 2012)
Lopes et al. (2005), também dizem que o caso de uso é qualquer sequencia de acções que os actores
realizam no sistema, de forma a atingir os objectivos, mostrando as funcionalidades que o sistema
deve oferecer, na perspectiva que interage com ele, para satisfazer os requisitos funcionais
identificados.
A comunicação entre um actor e os use cases pode ser representada em uma simples linha recta,
onde os actores são colocados em um ponto qualquer do diagrama, com o pressuposto que haverá
alguma comunicação de emissão ou recepção, ou representado com uma seta cujas pontas indicam
a direcção da comunicação, e neste caso é habitual colocar os actores emissores à esquerda da
fronteira do sistema e os actores à direita. (Nunes & O’Neill 2003)
Entre os casos de uso, podem existir relacionamentos, que seriam descritos por Macêdo (2012):

35. JESSE ISSUFO 23
 Include (inclui): que especifica que um caso de uso utiliza ou inclui a funcionalidade
disponibilizada num outro caso de uso
 Extend (estende): que especifica que em determinadas situações, ou em algum ponto
(chamado um ponto de extensão) um caso de uso será estendido por outro.
Mas para além da representação do diagrama de casos de uso, é necessária uma descrição de cada
caso de uso, e estas são narrativas de texto do caso de uso. Elas usualmente tomam a forma de uma
nota ou um documento que é de alguma maneira ligado ao caso de uso, e explana o processo ou
actividades que tomarão lugar no caso de uso. (Macêdo 2012)
Para Nunes & O’Neill (2003), na descrição do caso de uso pressupõe-se que estão reunidas todas
condições que garantem que tudo corra bem, tendo um cenário onde não surgem problemas,
denominado cenário principal (fluxo principal). Contudo, pode existir a necessidade de descrever
situações alternativas, ou seja, cenários secundários (fluxos secundários).
2.7.3. Diagrama de sequência
Para Macêdo (2012) o diagrama de sequencia é usado para mostrar uma sequência de actividades.
Mostra o fluxo de trabalho (workflow) a partir de um ponto inicial até um ponto final, detalhando
as decisões do caminho tomado durante a execução das tarefas. Este diagrama possui várias
aplicações, desde a definição do fluxo básico de um programa até a definição de um processo com
as suas tomadas de decisões e acções.
Os diagramas de sequência permitem definir e clarificar a colaboração entre as classes do sistema,
ou seja, realça a ordem cronológica das mensagens entre objectos, usadas para ilustrar o
comportamento do sistema num cenário de concretização de um caso de uso. (Nunes & O’Neill
2003)
Estes são representados através de linhas verticais tracejadas, com o nome do objecto no topo. O
eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas

36. JESSE ISSUFO 24
de um objecto para outro na forma de setas com a operação e os nomes dos parâmetros. (Macêdo
2012)
As mensagens trocadas entre objectos representam a invocação de um serviço (operação)
disponibilizado por um objecto, com o objectivo de despoletar uma acção ou actividade. (Nunes
& O’Neill 2003)
Nunes & O’Neill (2003) descrevem os tipos de mensagens trocadas entre os objectos como:
 Mensagem síncrona: significa que o objecto emissor fica suspenso à espera de uma
resposta, retomando posteriormente o controlo, e é usada quando o objecto emissor
necessita de dados provenientes do objecto receptor, para continuar o seu processamento;
 Mensagem assíncrona: permite à operação emissora prosseguir o seu processamento, e é
útil para ilustrar sistemas com processos concorrentes;
 Mensagem simples: útil para quando ainda não está definido o tipo de mensagem ou o
tipo não relevante;
 Mensagem de retorno: é usado para ilustrar o retorno da mensagem enviada que poderá
ser um valor ou um sinal, esta é implícita para mensagens simples ou síncronas, então a
sua representação é opcional.
2.7.4. Diagrama de actividades
Este diagrama descreve a sequência de actividades num sistema com a ajuda das actividades. São
uma forma especial de diagramas de estado, que somente (ou principalmente) contém actividades.
Estes não são importantes somente para a modelagem de aspectos dinâmicos de um sistema ou um
fluxograma, mas também para a construção de sistemas executáveis por meio de engenharia de
produção reversa. (Macêdo 2012)
O diagrama de actividades pode ser usado para detalhar apenas um caso de uso associado a um
processo de negócio, mas também pode ser usado na descrição de um fluxo de actividades mais
alargado, envolvendo diversos casos de uso, que constitui aquilo que se pode designar por processo
de negócio interfuncional. (Nunes & O’Neill 2003)

37. JESSE ISSUFO 25
Nunes & O’Neill (2003) apontam uma das características do diagrama de actividade que é a
capacidade de descrever conjuntos de actividades que se desenvolvem em paralelo, que é usada
quando se descreve um projecto de desenvolvimento de software, no qual algumas das actividades
podem ser realizadas em simultâneo por diversos actores.
Num diagrama de actividades é necessário identificar a actividade inicial, que pode ser puramente
virtual, para identificar o inicio do diagrama. Esta é descrita por um circulo preenchido a negro, e
num diagrama de actividades apenas pode existir uma. A actividade operacional, que permite
descrever um conjunto de acções que são realizadas quando a actividade se inicia, durante o seu
curso normal e quando termina. Para identificar a actividade terminal de um fluxo, é usado um
circulo a preto, limitado por uma circunferência, num diagrama de actividades podem existir varias
actividades terminais. (Nunes & O’Neill 2003)
Nunes & O’Neill (2003) explicam que no diagrama de actividade podem ser usados símbolos, em
forma de diamante, para representar caminhos alternativos baseados numa expressão booleana
(condição). Este representa uma divergência no fluxo de controlo, possui uma transição de entrada
e duas ou mais transições de saída.
2.8. Modelação de dados
A Modelação de Dados é a criação de um modelo físico que explica a lógica por traz do sistema,
com ele é possível explicar as características de funcionamento e comportamento de um software.
Esta é a base de criação do Banco de dados e parte essencial para a qualidade do software. (Miranda
2017)
Para Damas (2005: 15) “uma base de dados consiste em uma colecção de dados estruturados,
organizados e armazenados de forma persistente”.
Para Belo (2004) o ciclo de vida de uma base de dados integra as principais etapas do desenho do
seu esquema lógico global, alocação de dados num sistema computacional e na definição dos
esquemas locais específicos ao sistema de bases de dados.

38. JESSE ISSUFO 26
Segundo Belo (2004) as etapas fundamentais a ser consideradas são: análise de requisitos; desenho
do esquema; refinamento de utilização; distribuição de dados; esquemas locais e desenho físico e
a implementação, monitorização e modificação da base de dados.
A modelação ER (Entidade-Relacionamento) é a técnica de modelação de dados mais popular,
dado a sua simplicidade, facilidade compreensão e leitura e um bom meio de discussão e análise
em processos de definição para esquemas de bases de dados. Os diagramas ER são excelentes
meios para a comunicação com os utilizadores finais dos sistemas de bases de dados quando se
pretende apresentar e validar os nossos sistemas de dados durante a fase de modelação. (Belo 2004)
As entidades são representações de algo no mundo físico para um sistema, como por exemplo,
entidades pessoa, carro, produto, entre outros. Também temos os relacionamentos entre as
entidades, que nada mais é do que a ligação entre duas entidades, ou algo que faça com que essas
entidades tenham algo em comum, isto segundo Miranda (2017).
Os possíveis relacionamentos apontados por Miranda (2017) são:
 Relacionamento um-para-um (1 : 1): é explicado da seguinte forma: Uma entidade em “A”
está associada com no máximo uma entidade em “B”, e uma entidade em “B” está
associada com no máximo uma entidade em “A”.
 Relacionamento um-para-muitos (1 : n): é explicado da seguinte forma: Uma entidade em
“A” está associada a qualquer número de entidades em “B”, e uma entidade em “B”,
todavia, pode estar associado a no máximo uma entidade em “A”.
 Relacionamento muitos-para-muitos (m : n): é explicado da seguinte forma: Uma entidade
em “A” está associada a qualquer número de entidades em “B” e vice-versa.

39. JESSE ISSUFO 27
3. CAPÍTULO III – METODOLOGIA
A metodologia de pesquisa adoptada foi a da pesquisa descritiva, pois foi necessário saber como
o registo e distribuição do orçamento geral do Estado é feito actualmente na Universidade Eduardo
Mondlane. Para Seliger & Shohamy (1989) a pesquisa descritiva envolve um conjunto de técnicas
usadas para especificar, delinear ou descrever, fenómenos que ocorrem, naturalmente sem
manipulação experimental.
Para a elaboração deste trabalho foi necessário recolher dados através da engenharia de requisitos,
observações e consultas em certas fontes como bibliotecas e a internet.
Para Sommerville (2011:69) os processos de engenharia de requisitos podem incluir quatro
actividades de alto nível, estas visam avaliar se o sistema é útil para a empresa (estudo de
viabilidade), descobrindo requisitos (negociação e análise), convertendo-os em alguma forma-
padrão (especificação), e verificar se os requisitos realmente definem o sistema que o cliente quer
(validação).
O estudo de viabilidade decorreu em varias sessões com os stakeholders (corpo administrativo da
Direcção de Finanças da UEM) e com uma equipa de analista de sistemas do Departamento de
Sistemas e Multimédia do CIUEM, onde foi identificado o problema, foram definidos os
objectivos, e foram definidos os resultados esperados, bem como o meio para atingir esses
objectivos, que foi o desenvolvimento do módulo para o sistema de gestão de financeiro.
Após o estudo de viabilidade, foi realizado durante reuniões com os stakeholders o levantamento
e mapeamento dos requisitos funcionais e não funcionais, bem como o desenho do fluxo, através
da descrição do cenário actual, actividades desenvolvidas e o fluxo dos eventos durante o processo
de registo e distribuição do orçamento.
Nepomuceno (2012) afirma que a definição de todos os requisitos necessários ao sistema pelo
cliente ou usuário geralmente é uma tarefa muito difícil e para poder testar os requisitos de uma
forma mais eficiente, seria necessária a utilização de um protótipo do sistema.
Portanto foi necessário desenhar o protótipo do módulo para que através dele fosse possível
encontrar acertos e falhas nos requisitos e fluxos já previstos para o sistema. Onde também foi

40. JESSE ISSUFO 28
possível classificar e priorizar os requisitos, para simplificar a visão geral do funcionamento
previsto para o sistema.
A partir do levantamento dos requisitos foi possível montar uma especificação (documentação) de
alto nível, descrevendo as funcionalidades e restrições do módulo do sistema, explicando o que o
módulo deve fazer, como deve reagir, o que deve conter e o que não está directamente relacionado
com os serviços específicos oferecidos pelo sistema à seus usuários, isso através do uso de
diagramas lógicos com o auxilio da linguagem natural.
Durante o desenvolvimento ou após o sistema estar em uso, as descobertas de erros no documento
de requisitos podem gerar altos custos de retrabalho, pois, o custo para consertar um problema de
requisitos por meio de uma mudança no sistema é geralmente muito maior do que o custo de
consertar erros de projecto ou de codificação, isso acontece porque, muita coisa já pode estar
preparada de forma que não agrade ao cliente. (Sommerville 2011:76)
Para poder verificar se os requisitos definem o sistema que o cliente realmente quer, foi necessário
um processo de validação, e este, está preocupado em encontrar problemas com os requisitos. E
esta decorreu de forma continua junto dos stakeholders, através da apresentação do protótipo do
sistema.

41. JESSE ISSUFO 29
4. CAPÍTULO IV – CASO DE ESTUDO
4.1. Direcção de Finanças
A direcção de finanças é uma das unidades administrativas da UEM, cujo um dos seus objectivos
é monitorar e rever os serviços fornecidos aos órgãos dentro da UEM, afim de assegurar a
eficiência dos serviços fornecidos, e desenvolver estes serviços em parceria com a comunidade
universitária e outros intervenientes da UEM, bem como mobilizar os fundos orçamentados para
a instituição, os quais provêm de quatro tipos de fontes: Orçamento do Estado, Doações, Crédito,
e Receitas Próprias.
4.2. Cenário actual do registo do orçamento geral do Estado na UEM
Para o caso do orçamento geral do Estado, de uma forma simplificada, as unidades orgânicas
elaboram os seus planos de actividades onde contém as actividades e orçamentos previstos para o
ano e submetem ao Gabinete de Planificação (GPlan) e a Direcção de Finanças (DFin), estes por
sua vez, harmonizam os planos das unidades e elaboram o plano de actividades e orçamento da
UEM e este é submetido ao Ministério de Economia e Finanças (MEF).
Após o MEF aprovar o plano de actividades e orçamento da UEM, esta comunica sobre o
orçamento aprovado à UEM (para o caso das unidades centralizadas¹) e a cada uma das unidades
descentralizadas².
Cabe a DFin registar o orçamento aprovado de acordo com a orientação do MEF, sendo este
dividido em duas categorias: Despesas de Funcionamento e Despesas de Investimento. Para cada
uma das categorias são indicadas certas rúbricas do classificador económico do Estado, para as
quias foram aprovadas para o determinado ciclo e são ainda indicados eixos dos quais a rúbricas
pertencem. O mesmo registo deve ser efectuado pelas unidades descentralizadas, que
posteriormente enviam o registo do seu orçamento aprovado para a DFin, para que este possa
concatenar os orçamentos, elaborando assim o orçamento total aprovado para a UEM.

42. JESSE ISSUFO 30
Deste orçamento total aprovado para UEM, uma certa percentagem fica cativa por rúbrica no
Estado, sendo este valor cativo, deliberado caso a UEM solicite.
Figura 4.1 – Cenário do registo do orçamento geral do Estado
4.3. Cenário actual da distribuição do orçamento geral do Estado pelos centros de
despesa
Após a aprovação e registo do orçamento geral do Estado, cabe a DFin fazer a distribuição deste
orçamento pelos centros de despesa¹ das unidades, porém, só o orçamento correspondente a
categoria de despesa de funcionamento é distribuído, pois as despesas de investimento são geridas
centralmente pela UEM.
Tendo em conta a proposta e o histórico orçamental das unidades centralizadas, a Dfin elabora
uma proposta de distribuição para os centros de despesa e submete ao Conselho Universitário
(CUN). Com a aprovação do CUN sobre o orçamento aprovado para cada centro de despesa, a
Dfin já poderá distribuir o orçamento, pois no CUN são estudas todas as actividades das
actividades que estão de acordo com o plano estratégico da UEM e do Estado.
A distribuição é feita de acordo com a proposta orçamental de cada unidade, onde o orçamento é
divido por cada actividade dos centros de despesa, sendo que nem todas as actividades serão
orçamentadas por esta fonte, e nem todas as actividades serão orçamentadas por completo. Após
feita a divisão do orçamento, a DFin comunica as unidades sobre orçamento total disponível para

43. JESSE ISSUFO 31
os seus centros de despesa e para quais actividades foram alocadas o orçamento e também
comunica sobre o inicio da fase de reajuste do orçamento. E para o caso das unidades
descentralizadas, a DFin apenas poderá aumentar o orçamento caso seja solicitado pela unidade,
pois estas recebem o orçamento directamente do Estado.
Figura 4.2 – Cenário da distribuição do orçamento geral do Estado por centros de despesa
4.4. Cenário actual do reajuste do plano de actividades e orçamento
Feita a distribuição do orçamento pelos centros de despesa e notificação da DFIn, cabe a unidade
reajustar o plano de actividades de acordo com o orçamento disponível, visto que nem sempre o
orçamento disponível é suficiente para as necessidades apresentadas na proposta de plano de
actividades e orçamento da unidade.
No momento de reajuste a unidade poderá excluir algumas actividades ou apenas reajustar o valor
de realização das actividades, podendo realizar as actividades com outras fontes de orçamento.
Após o reajuste das actividades, a unidade deverá comunicar a GPlan e a DFin sobre o orçamento
reajustado, para que este possam monitorar a realização das actividades e consumo do orçamento.

44. JESSE ISSUFO 32
Figura 4.3 – Cenário do plano de actividades e orçamento

45. JESSE ISSUFO 33
5. CAPÍTULO V – ANÁLISE DE REQUISITOS E MODELAGEM
DO MÓDULO PROPOSTO
Ao falar de sistemas de software Sommerville (2011:3) diz que um sistema de software
desenvolvido profissionalmente é, com frequência, mais do que apenas um programa; ele
normalmente consiste em uma série de programas separados e arquivos de configuração que são
usados para configurar esses programas. Isso pode incluir documentação do sistema, que descreve
a sua estrutura; documentação do usuário, que explica como usar o sistema; e sites, para usuários
baixarem a informação recente do produto.
Desta forma, este capítulo visa trazer uma abordagem desde a visão geral da solução, definição
dos requisitos até a elaboração dos modelos conceptual e lógico do sistema.
Escopo: pertence ao escopo desta monografia parte da descrição do módulo: Registo do
Orçamento Geral do Estado aprovado para as unidades descentralizadas; Registo do Orçamento
Geral do Estado aprovado para UEM e unidades centralizadas; Distribuição do Orçamento Geral
do Estado para os centros de despesa da UEM.

46. JESSE ISSUFO 34
5.1. Visão geral do módulo de registo e distribuição do orçamento geral do Estado
O desenvolvimento do módulo surge da necessidade de informatizar dois processos,
nomeadamente, o registo do orçamento geral do Estado na UEM comunicado pelo Ministério da
Economia e Finanças e da distribuição deste mesmo orçamento entre os centros de despesa da
UEM. A Figura abaixo ilustra os intervenientes e a origem dos dados que serão manipulados pelo
módulo.
Figura 5.1 – Visão geral do funcionamento do módulo
O SIGF (Sistema Integrado de Gestão Financeira) guardará toda informação relativa ao registo do
orçamento geral do Estado aprovado para as unidades descentralizadas e de toda UEM, bem como
o registo da distribuição do orçamento pelo centros de despesa, tendo em conta o plano de
actividades e orçamento elaborado no SIPMA (Sistema Integrado de Planificação e Monitoria de
Actividades), sendo que o SIGF irá pegar os dados do SIPMA para que possamos ter noção do que
a UEM planificou e pediu e quanto desse valor foi aprovado pelo estado, bem como saber do
orçamento proposto para cada actividade dos centros de despesa, para que a DFin e a CUN possam
ter melhor noção de quanto possam distribuir para cada centro de despesa.

47. JESSE ISSUFO 35
O registo do orçamento geral do Estado e distribuição pelos centros de despesa, também se reflecte
num outro módulo do SIGF, que é o módulo de despesas, pois para DFin manter o controle do que
é requisitado e para quê é requisitado é necessário que haja um plano de actividades e orçamento
e que este plano já tenha sido aprovado e orçamentado no módulo de registo e distribuição do
orçamento.
5.2. Descrição do funcionamento do módulo de registo e distribuição do orçamento
geral do Estado
Antes que seja registado e distribuído o orçamento do Estado, será necessário que a DFin configure
no sistema os centros de despesa de cada unidade para o ciclo (ano), podendo uma unidade
administrar mais de um centro de despesa. Depois desta configuração, a unidade deverá criar o
plano de actividades e orçamento, indicando quais as actividades irão executar, e para cada
actividade indicar as suas actividades especificas, sendo que cada actividade especifica engloba
um conjunto de bases de cálculos, que é onde são especificados os itens que serão necessários para
a realização das actividades.
Tendo os planos das unidades, a DFin e GPlan elaboram o plano de actividades e orçamento da
UEM e enviam para o MEF, que posteriormente comunica a UEM (exactamente a DFin) e as
unidades descentralizadas sobre o orçamento aprovado, então as unidades descentralizadas
deverão comunicar a DFin sobre os seus orçamentos aprovados. Tendo o orçamento aprovado para
as unidades descentralizadas, a DFin irá registar no sistema o orçamento aprovado para cada uma
delas por rúbricas e eixos, que é a forma como o MEF comunica sobre o orçamento aprovado.
Com o orçamento aprovado para as unidades descentralizadas, a DFin poderá registar o orçamento
central da UEM, que é somado ao orçamento das unidades descentralizadas, para que se tenha o
orçamento total da UEM, que é dividido por categorias, eixos e rúbricas. Por cada rúbrica o
governo mantém uma certa percentagem cativa, que subtraído do total da UEM, para que se tenha
o orçamento disponível para cada rúbrica no ciclo.

48. JESSE ISSUFO 36
Antes que se possa fazer a distribuição por centros de despesa, é necessário que sejam retiradas as
dividas das despesas de cada rúbrica do ciclo anterior, para que se tenha o orçamento distribuível
para o ciclo actual.
Tendo orçamento distribuível, a DFin poderá distribuir o orçamento pelos centros de despesa,
podendo visualizar as actividades propostas por cada unidade para os centros de despesa e decidir
quanto deve distribuir para cada um deles, sendo que nem sempre o orçamento aprovado será igual
ou maior ao orçamento proposto, então sendo necessário que a unidade faça a um reajuste do seu
plano de actividades e orçamento.
Após a distribuição feita pela DFin, cada unidade terá a oportunidade de reajustar os planos de
actividade e orçamento de cada um dos seus centros de despesa, para caso seja necessário, ajustar
o valor necessário para uma actividade ou mudar a fonte de orçamento para cada uma das bases
de calculo, ou apenas não realizar toda a actividade com essa fonte de orçamento.
5.3. Requisitos do módulo
Os requisitos funcionais descrevem o que o sistema deve fazer, como deve reagir, o que deve
conter. Estes podem mudar de acordo com o tipo de software a ser desenvolvido e pela forma da
qual será aplicada e usada. (Sommerville 2011)
Os requisitos podem apresentar 3 tipos de prioridades:
Essencial (E): é o requisito sem o qual o sistema não entra em funcionamento. Requisitos
essenciais são requisitos imprescindíveis, que têm que ser implementados obrigatoriamente.
Importante (I): é o requisito sem o qual o sistema entra em funcionamento, mas de forma não
satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema
poderá ser implantado e usado mesmo assim.
Desejável (D): é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o
sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que
podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para
implementá-los na versão que está sendo especificada.

49. JESSE ISSUFO 37
5.3.1. Requisitos Funcionais do módulo
Ref. Requisito Descrição Prioridade Dependência
RF01 Gerir centros de
despesa
Permitir o registo, leitura e
actualização de todos os centros de
despesa da UEM;
E ----------
RF02 Gerir unidades
orgânicas
Permitir o registo, leitura e
actualização de todas as unidades
orgânicas da UEM;
E ----------
RF03 Associar centros
de despesa às
unidades
orgânicas do ciclo
Permitir a associação das unidades
orgânicas aos seus devidos centros de
despesa para o ciclo corrente;
E RF01, RF02
RF04 Gerir Grupos de
actividades
Permitir o registo, leitura e
actualização dos grupos de actividades
realizados na UEM;
E ----------
RF05 Associar centros
de despesa aos
grupos de
actividades
Permitir a associação dos centros de
despesa da unidade aos grupos de
actividades que pretendem realizar no
ciclo
I RF03, RF04
RF06 Gerir categorias
de despesa
Permitir o registo, leitura e
actualização das categorias de despesa
usados na UEM;
E ----------
RF07 Gerir rúbricas do
classificador
económico do
Estado
Permitir o registo, leitura e
actualização das rúbricas do
classificador económico do Estado
usadas na UEM;
E ----------
RF08 Gerir eixos do
plano estratégico
Permitir o registo, leitura e
actualização dos eixos abrangidos na
UEM;
E ----------

50. JESSE ISSUFO 38
RF09 Gerir o plano de
actividades e
orçamento das
unidades
orgânicas
Permitir o registo, leitura e
actualização do plano de actividades e
orçamento das unidades orgânicas,
permitindo a actualização de
actividades, actividades especificas e
bases de calculo;
I RF01, RF04,
RF07, RF08
RF10 Registar o
orçamento geral
do Estado para
unidades
descentralizadas
Permitir o registo do orçamento geral
do estado para as unidades
descentralizadas por rúbricas e eixos;
E RF02, RF07,
RF08
RF11 Registar o
orçamento geral
do Estado para
toda UEM
Permitir o registo do orçamento geral
do Estado para toda a UEM por
rúbricas e eixos, que provêm do
somatório do orçamento central e
descentralizado;
E RF07, RF08,
RF10
RF12 Distribuir o
orçamento
registado pelos
centros de despesa
Permitir a distribuição do orçamento
registado por rúbricas e eixos pêlos
centros de despesa agrupados por
grupos de actividades;
E RF05, RF11
RF13 Reajustar o plano
de actividades e
orçamento
Permitir o reajuste do plano de
actividades e orçamento proposto para
cada centros de despesa pela unidade
orgânica de acordo com o orçamento
distribuído;
E RF09, RF12
Tabela 5.1 – Requisitos funcionais do módulo

51. JESSE ISSUFO 39
5.3.2. Requisitos não funcionais
Ref. Descrição
RNF01 O módulo deve conter restrições de uso para os usuários do sistema
RNF02 O módulo deve garantir a protecção de dados
RNF03 O módulo deve ser fiável e disponível
RNF04 O módulo deve de fácil manuseio
RNF05 O módulo deve interagir com os restantes módulos do sistema
RNF06 O módulo deve ter menor tempo de resposta possível
Tabela 5.2 – Requisitos não funcionais do módulo
5.3.3. Regras de Negócio do módulo
Ref. Descrição
RN01 A associação do centros de despesa com as unidades e a associação destas com os
grupos de actividades deverão ser feitas em todos os ciclos económicos;
RN02 Apenas as rubricas da categoria de despesa correspondente a funcionamento serão
distribuídas para as unidades orgânicas e centros de despesa. As que correspondem
a categoria de investimento devem ser geridas centralmente;
RN03 Apenas a Direcção de Finanças poderá registar e associar os centros de despesa da
unidade;
RN04 O orçamento distribuído num ciclo para um centro de despesa, corresponde ao limite
de distribuição para o ciclo posterior do centro de despesa;
RN05 O orçamento aprovado para uma rúbrica, não pode ser passado para outra rúbrica;
RN06 As dividas de um ciclo correspondem as requisições executadas mas não pagas do
ciclo anterior;
RN07 O orçamento correspondente a salários e remunerações será apenas distribuído por
unidades orgânicas e não centros de despesa;
RN08 As actividades não orçamentadas pelo Estado podem mudar de Fonte de orçamento
(receitas próprias ou doações) para que ainda possam ser realizadas;
Tabela 5.3 – Requisitos regras de negócio do módulo

52. JESSE ISSUFO 40
5.4. Diagramas Lógicos
Dos diagramas apenas serão abordados os usados durante o desenvolvimento do módulo, sendo,
da categoria dos diagramas estruturais o diagrama de classe, e da categoria dos diagramas
comportamentais o diagrama de casos de uso, diagrama de sequência e o diagrama de actividades.
5.4.1. Diagrama de Casos de Uso
O diagrama de casos de uso foi útil para descrever relacionamentos e dependências entre um grupo
de casos de uso e os actores participantes no processo. Desta forma, os casos de uso descreveram
interacções típicas entre os usuários do módulo e o módulo propriamente dito.
Figura 5.2 – Diagrama de casos de uso

53. JESSE ISSUFO 41
5.4.2. Descrição dos Casos de uso
Caso de Uso: Registar Orçamento do Estado para Unidades
Descentralizadas
Descrição: Pretende-se registar o orçamento geral do Estado
para as unidades descentralizadas para que se possa
ter o orçamento total da UEM, pois estas recebem
a comunicação do orçamento directamente do MEF
Actores: Gestor Orçamental da Direcção de Finanças
Pré-Condições: - Unidades orgânicas registadas no sistema
- Rúbricas do classificador económico de despesa
do Estado registadas no sistema
-Eixos do plano estratégico registados no sistema
- Autenticação do utilizador
Pós-Condição: - Orçamento Geral do Estado da UEM já pode ser
registado;
Fluxo Principal
Acções do Actor Sistema
1. No menu escolhe Entradas de Fundos e depois
Registo de Orçamento Descentralizado;
3. Nos filtros do registo, escolhe a Fonte de
Orçamento, a Unidade Descentralizada e o
Eixo;
5. Selecciona a rúbrica e insere o valor aprovado
para essa rúbrica, numa unidade
descentralizada segundo um eixo e clica em
gravar;
2. Mostra a interface de registo de orçamento
descentralizado;
4. Mostra todas as rúbricas encontradas
consoante aos filtros;
6. Grava na base de dados e mostra o orçamento
aprovado para unidade descentralizada por
rúbrica e eixo;
Fluxo Alternativo 01 – Não encontra a rúbrica para uma dada unidade num eixo
Acções do Actor Sistema

54. JESSE ISSUFO 42
1. Pesquisa pelos orçamentos já registados
através dos filtros;
2. Mostra o registo do orçamentos segundo os
filtros
Tabela 5.4 – Descrição do caso de uso: Registar Orçamento do Estado para Unidades
Descentralizadas
Caso de Uso: Registar Orçamento Geral do Estado para UEM
Descrição: Pretende-se registar o orçamento geral do Estado
para toda a UEM, juntamente com o orçamento das
unidades descentralizadas
Actores: Gestor Orçamental da Direcção de Finanças
Pré-Condições: - Categorias de despesa registadas no sistema
- Subcategorias de despesa registadas no sistema
- Rúbricas do classificador económico de despesa
do Estado registadas no sistema
-Eixos do plano estratégico registados no sistema
- Autenticação do utilizador
Pós-Condição: - Orçamento Geral do Estado da UEM já pode ser
distribuído por centros de despesa da unidade;
Fluxo Principal
Acções do Actor Sistema
1. No menu escolhe Entrada de Fundos e depois
Registo de Orçamento da UEM;
3. Nos filtros de registo, escolhe a Fonte de
Orçamento, a Categoria de Despesa, a
Subcategoria de Despesa e o Eixo;
5. Selecciona as rúbricas e insere os valores
centrais para estas de acordo com os filtros;
2. Mostra a interface de registo de orçamento da
UEM;
4. Mostra todas as rúbricas encontradas
consoante os filtros;
6. Soma o orçamento central de cada rúbrica com
o orçamento descentralizado correspondente,
dando o orçamento total de funcionamento da
UEM;

55. JESSE ISSUFO 43
8. Insere a divida de cada uma das rúbricas
seleccionadas;
10. Verifica os valores inseridos e calculados pelo
sistema e clica em gravar;
7. Retira uma percentagem cativa por rúbrica do
orçamento de funcionamento da UEM,
calculando o orçamento disponível por rúbrica;
9. Subtrai a divida do orçamento disponível da
respectiva rúbrica, calculando o orçamento
distribuível de cada rúbrica;
11. Grava na base de dados e mostra o orçamento
aprovado por rúbrica;
Fluxo Alternativo 01 – Categoria de Despesa sem Subcategoria
Acções do Actor Sistema
1. Nos filtros de registo, escolhe a Fonte de
Orçamento, a Categoria de Despesa e o Eixo;
3. Segue com o fluxo principal a partir do ponto
5;
2. Mostra todas as rúbricas encontradas consoante
os filtros;
Tabela 5.5 – Descrição do caso de uso: Registar Orçamento Geral do Estado para UEM
Caso de Uso: Distribuir Orçamento Geral do Estado pelos
Centros de despesa da UEM
Descrição: Pretende-se distribuir o orçamento geral do Estado
da rubrica num determinado eixo pêlos centros de
despesa de acordo com os grupos de actividades
Actores: Gestor Orçamental da Direcção de Finanças
Pré-Condições: - Orçamento Geral do Estado da UEM registado
- Grupos de actividades registados
- Centros de despesa associados aso grupos de
actividades
- Autenticação do utilizador
Pós-Condição: - A unidade já pode reajustar o plano de actividades
e orçamento;

56. JESSE ISSUFO 44
Fluxo Principal
Acções do Actor Sistema
1. No menu escolhe Entrada de Fundos e depois
Registo de Orçamento da UEM;
3. Pesquisa pelas rúbricas com orçamento já
registado, sendo da categoria de despesa de
funcionamento e pelos seus diversos eixos;
5. Clica em distribuir na linha da rúbrica do eixo
que deseja distribuir;
7. Selecciona o grupo de actividades para ver os
centros de despesa ao grupo seleccionado;
9. Distribui o orçamento aprovado para rúbrica do
eixo seleccionado pelos centros de despesa e
clica em gravar;
2. Mostra a interface de registo de orçamento da
UEM;
4. Mostra as rúbricas já registadas de acordo com
os filtros;
6. Mostra a interface de distribuição do orçamento
para a rúbrica seleccionada;
8. Mostra os centros de despesa associados ao
grupo de actividades de actividades;
10. Grava na base de dados, e subtrai o valor total
distribuído para os centros de despesa do
orçamento distribuível da rúbrica do eixo;
Fluxo Alternativo 01 – Ver actividades planificadas pelos centros de despesa antes de distribuir
Acções do Actor Sistema
1. Selecciona o grupo de actividades para ver os
centros de despesa ao grupo seleccionado;
3. Clica em ver actividades;
5. Segue com o fluxo principal a partir do ponto 9;
2. Mostra os centros de despesa associados ao
grupo de actividades de actividades;
4. Mostra as actividades, actividades especificas e
bases de calculo planificadas pelo centro de
despesa para aquela rubrica e eixo;
Tabela 5.6 – Descrição do caso de uso: Distribuir Orçamento Geral do Estado pelos centros de
despesa da UEM
5.4.3. Diagrama de Sequência
O diagrama de sequencia foi usado para mostrar algumas sequências de actividades, mostrando o
fluxo de trabalho a partir de um ponto inicial até um ponto final, detalhando as decisões do caminho
tomado durante a execução da tarefa.

57. JESSE ISSUFO 45
Figura 5.3 –Diagrama de sequencia do caso de uso: Registar Orçamento do Estado para Unidades
Descentralizadas

58. JESSE ISSUFO 46
Figura 5.4 –Diagrama de sequencia do caso de uso: Registar Orçamento Geral do Estado para
UEM

59. JESSE ISSUFO 47
Figura 5.5 –Diagrama de sequencia do caso de uso: Distribuir Orçamento Geral do Estado pelos
centros de despesa da UEM
5.4.4. Diagrama de Actividades
O diagrama de actividades foi usado para descrever a sequência de actividades no módulo com a
ajuda das actividades. Estes não foram importantes somente para a modelagem de aspectos
dinâmicos do módulo, mas também para a construção de sistemas executáveis por meio de
engenharia de produção reversa.

60. JESSE ISSUFO 48
Figura 5.6 –Diagrama de actividades interfuncional do módulo
5.4.5. Diagrama de Classes
O diagrama de classes foi usado para mostrar as classes, com seus métodos e atributos, bem como
os relacionamentos estáticos entre elas: quais classes conhecem quais classes ou quais classes são
parte de outras classes.

61. JESSE ISSUFO 49
Figura 5.7 –Diagrama de classes do módulo
5.5. Modelo Conceptual de dados
Como resultado da identificação dos objectos do sistema e da relação entre eles, foi possível
conceber o seguinte modelo conceptual para o módulo:
 As tabelas de cor verde representam os parâmetros iniciais do sistema;
 As tabelas de cor azul claro representam as principais associações entre para os parâmetros,
ou seja, são os parâmetros secundários;

62. JESSE ISSUFO 50
 As tabelas de cor laranja representam o plano de actividade e orçamento elaborado pelas
unidades orgânicas;
 As tabelas de cor cinza representam o registro de orçamento central e descentralizado e a
distribuição por centros de despesa;
 As tabelas de cor rosa representam o plano de actividades e orçamento reajustado depois
da distribuição;
Figura 5.8 –Modelo conceptual de dados do módulo

63. JESSE ISSUFO 51
6. CAPITULO VI – CONCLUSÕES E RECOMENDAÇÕES
6.1. Conclusões
As tecnologias de informação e comunicação (TICs), são de extrema importância naquilo que é a
actualidade vivida em todo o mundo. Sendo assim, o desenvolvimento do módulo de registo e
distribuição do orçamento geral do Estado para o sistema de gestão financeira (SIFG) da
Universidade Eduardo Mondlane (UEM), vem como forma a solucionar ou amenizar alguns
problemas encontrados na área administrativa da UEM.
Este foi o começo da resolução de alguns problemas e constrangimentos que foram expostos pela
Direcção de Finanças (DFin), visto que, o uso de sistemas informáticos para área administrativa,
auxiliam o tempo de conciliação, distribuição e tramitação de informações entre os usuários, e
também pode auxiliar na elaboração de relatórios.
A análise teórica e o desenvolvimento do trabalho possibilitaram uma análise do problema
enfrentado no processo de registo e distribuição do orçamento geral do Estado pelos centros de
despesa da UEM, e também a determinar uma solução baseada em TICs para a resolução deste
problema.
Tendo percebido o problema, foi possível fazer a identificação e levantamento dos requisitos e
ainda o mapeamento dos fluxos de operações necessárias para o módulo. Sendo os principais
requisitos e fluxos do módulo: primeiro o registo do orçamento geral do Estado de funcionamento
das unidades orgânicas da descentralizadas da UEM, segundo o registo do orçamento geral do
Estado para a UEM central e o cálculo do orçamento geral do Estado total para UEM segundo
alguns quesitos internos da UEM e o plano estratégico do Estado, terceiro a distribuição do
orçamento pelos centros de despesa das unidades orgânicas segundo as actividades planificadas
para o ano económico e em quarto um requisito complementar a distribuição, que é o reajuste do
plano de actividades e orçamento de cada centro de despesa de acordo com o orçamento
distribuído.

64. JESSE ISSUFO 52
Logo após a identificação de requisitos e fluxos, a modelação e desenho do módulo se desenvolveu
a partir da apresentação do protótipo inicial usado para a validação dos stakeholders, de onde foi
possível identificar novos requisitos para o módulo que foram difíceis de levantar verbalmente,
bem como verificar falhas nos requisitos previamente identificados. Aplicando a metodologia de
desenvolvimento ágil, o modelo conceptual do módulo foi melhorando de forma incremental
consoante as interacções com os stakeholders, onde eram apresentadas versões intermediarias do
protótipo.
Tendo o modelo conceptual do módulo, foi possível desenvolver (codificar) o módulo dentro do
sistema de gestão financeira existente, de acordo com as tecnologias usadas para desenvolver o
sistema. Paralelamente ao desenvolvimento do módulo, testes betas foram sendo realizados, onde
toda a fase desenvolvida era testada antes que se pudesse prosseguir para a fase seguinte, até que
todo módulo fosse desenvolvido e pronto para os testes alfas com os utilizadores do sistema, para
que o módulo seja implantado.
Como resultado do presente trabalho foi criar um processo de registo e distribuição do orçamento
geral do Estado na UEM, respeitando vários critérios internos e externos, que possibilita maior
controle e segurança dos sensíveis dados financeiros, possibilitando também uma maior
diversificação de relatórios que podem ser extraídos do módulo com base nas necessidades dos
usuários, desta forma, dando um certo apoio as decisões tomadas a nível estratégico.
Desta forma, é possível concluir que o desenvolvimento do módulo de registo e distribuição do
orçamento geral do Estado vai resolver o problema no processo de registo e distribuição do
orçamento na UEM, criando facilidades de manipulação e controle do orçamento, solucionando
ou amenizando a discrepância entre os valores registados no começo do ano económico e o
contabilizado no fim deste.
Sendo os frutos deste módulo usados no módulo de despesas, onde poderão ser feitas requisições
consoante o orçamento das actividades planeadas e reajustadas.

65. JESSE ISSUFO 53
6.2. Recomendações
 Tendo em conta o número e variação de relatórios necessários não só para módulo de
registo e distribuição do orçamento na UEM, recomenda-se a criação de um módulo de
extracção de dados, para que os mais variados tipos de relatórios possam ser obtidos do
sistema;
 Recomenda-se também, um módulo de monitoria das despesas, para que seja um
intermédio entre orçamento usado no módulo de despesas e o orçamento disponível
proveniente do módulo de receitas próprias da UEM e do módulo de registo e distribuição
do orçamento do Estado;
 Recomenda-se que se veja a opção de adaptação do módulo de registo e distribuição do
orçamento para a possibilidade de ser usado por outras instituições que também recebam o
orçamento do Estado.

66. JESSE ISSUFO 54
7. Bibliografia
 António, P. (2015) Informática e Tecnologias de Informação. Lisboa: Edições Sílabo. [1ª
ed]
 Barbosa, G. (2008) Sistemas de Apoio a Decisão SAD.
<http://www.administradores.com.br/artigos/tecnologia/sistema-de-apoio-a-decisao-
sad/26378/>. Consultado em: 22-02-2018
 Bell, D. (2016) O Diagrama de Classes.
<https://www.ibm.com/developerworks/br/rational/library/content/RationalEdge/sep04/b
ell/index.html>. Consultado em: 31-05-2018
 Belo, O. (2004) Desenho e Modelação de Esquemas de Bases de Dados.
<http://necc.di.uminho.pt/wiki/lib/exe/fetch.php?media=ap:3ano:bd:ap_bd_1112_modela
caobd.pdf>. Consultado em: 29-05-2018
 Chiavenato, I. (2014) Gestão Financeira: Uma Abordagem Introdutória. Barueri, São
Paulo: Editora Manole. [3ª ed]
 Damas, L. (2005) SQL: Structured Query Language. Lisboa: FCA
 Eduardo, C. (2007) Sistemas de Informação: Sistemas de Gestão Empresarial.
<http://www.administradores.com.br/producao-academica/sistemas-de-informacao-
sistemas-de-gestao-empresarial/358/>. Consultado em: 28-05-2018

67. JESSE ISSUFO 55
 Laudon, K. e Laudon, J. (2007) Sistemas de Informações Gerencias. São Paulo: Pearson
Education. [7ª ed]
 Lopes, F., Morais, M. e Carvalho, A. (2005) Desenvolvimento de Sistenas de Informação.
Lisboa: FCA.
 Lopes, M. (1997) Sistemas de Informação para Gestão: Conceitos e Evolução. Lisboa:
Universidade Aberta
 Macêdo, D. (2012) Introdução a UML e seus diagramas.
<http://www.diegomacedo.com.br/introducao-a-uml-e-seus-diagramas/>. Consultado em:
02-06-2018
 Marconi, M. e Lakatos, E. (2003) Fundamentos de Metodologia Científica. São Paulos:
Atlas S.A. [5ª ed]
 Martins, V. (2006) Integração de Sistema de Informação: Perspectivas, Normas e
Abordagens. Lisboa: Edições Sílabo. [1ª ed]
 Mendes, A. (2012) Requisitos Não Funcionais. <https://www.devmedia.com.br/artigo-
engenharia-de-software-3-requisitos-nao-funcionais/9525>. Consultado em: 22-05-2018
 Miranda, W. (2017) Modelagem de dados. <http://aprendaplsql.com/modelagem-de-
dados/modelagem-de-dados-parte-01/>. Consultado em: 29-05-2018

68. JESSE ISSUFO 56
 Nabias, C. (1993) Iniciação à Informática. Lisboa: Editorial Presença.
 Nepomuceno, D. (2012) Modelos Incremental, Espiral e de Prototipação.
<http://engenhariadesoftwareuesb.blogspot.com/2012/12/blog-post.html>. Consultado
em: 25-05-2018
 Nunes, M. e O’Neill, H. (2003) Fundamental de UML. Lisboa: FCA. [2ª ed]
 Nunes, P. (2017) Gestão (ou Administração) Financeira.
<http://knoow.net/cienceconempr/gestao/gestao-financeira/>. Consultado em: 25-05-2018
 Olumene, L. (2017) Sistemas Integrados e Inter-organizacionais. Slide de apoio para
Licenciatura em Engenharia Informática e de Telecomunicações. Universidade
Politécnica. Maputo. Agosto.
 Pfleeger, S. L. (2004) Engenharia de Software: Teoria e prática. São Paulo: Pearson
Education. [2ª ed]
 Seliger, H.W. e Shohamy, E. (1989) Second Language Research Methods. Oxford: Oxford
University Press.
 Silva, R. (2011) Importância dos Sistemas de Informação para Gestão de Empresas.
<http://www.administradores.com.br/artigos/tecnologia/a-importancia-dos-sistemas-de-
informacao-para-a-gestao-das-empresas/56331/>. Consultado em: 28-05-2018

69. JESSE ISSUFO 57
 Sommerville, I. (2011) Engenharia de Software. São Paulo: Pearson Education. [9ª ed]
 Sousa, S. (2005) Tecnologias de Informação. Lisboa: FCA. [5ª ed]
 Sousa, S. (2009) Tecnologias de Informação. Lisboa: FCA. [6ª ed]

70. JESSE ISSUFO 58
8. ANEXOS