Sualé Abdul Sualé

O CONTRIBUTO DE SISTEMAS DE INFORMAÇÃO NA GESTÃO

HOSPITALAR
Caso do Centro Médico Privado do Benfica

Licenciatura em Informática

Universidade Pedagógica
Maputo
2021
 Sualé Abdul Sualé

O CONTRIBUTO DE SISTEMAS DE INFORMAÇÃO NA GESTÃO

HOSPITALAR
Caso do Centro Médico Privado do Benfica

Monografia Científica a ser apresentada ao

Departamento de Informática, da Faculdade
de Engenharias e Tecnologias, da UPM para
obtenção do grau de licenciatura.

Supervisor:
Prof. Doutor Félix Singo

Universidade Pedagógica
Maputo
2021
 ii

Índice
Lista de Tabelas ......................................................................................................................... iv
Lista de Figuras .......................................................................................................................... v
Lista de Siglas, Abreviaturas e Símbolos .................................................................................. vi
Declaração ...............................................................................................................................viii
Dedicatória................................................................................................................................. ix
Agradecimentos .......................................................................................................................... x
Resumo ...................................................................................................................................... xi
Abstract ..................................................................................................................................... xii
CAPÍTULO I - INTRODUÇÃO ................................................................................................ 1
1.1. Problema da Pesquisa ...................................................................................................... 2
1.2. Justificativa ...................................................................................................................... 3
1.3. Objectivos ........................................................................................................................ 3
1.3.1. Objectivo Geral ........................................................................................................ 3
1.3.2. Objectivos Específicos ............................................................................................. 3
1.4. Metodologia de Pesquisa ................................................................................................. 4
1.5. Estrutura do Trabalho ...................................................................................................... 4
CAPÍTULO II – REFERENCIAL TEÓRICO ........................................................................... 5
2.1. Sistema de Informação ........................................................................................................ 5
2.1.1. Características dos Sistemas de Informação ................................................................. 5
2.1.2. Classificação dos Sistemas de Informação ................................................................... 6
2.2. Sistemas de Gestão .............................................................................................................. 6
2.2.1. Enterprise Resource Planning ....................................................................................... 6
2.2.2. Customer Relationship Management ............................................................................ 8
2.3. Engenharia de Software ....................................................................................................... 9
2.4. Desenvolvimento de Sistema .............................................................................................. 9
2.4.1. Modelos de Processo de Sistema .................................................................................. 9
2.4.2. Metodologias de Desenvolvimento de Sistema .......................................................... 11
CAPÍTULO III - APRESENTAÇÃO, ANÁLISE E DISCUSSÃO DOS RESULTADOS DA
PESQUISA ............................................................................................................................... 25
3.1. Descrição do Local do Estudo ........................................................................................... 25
3.2. Modelo Actual ................................................................................................................... 26
3.3. Limitações do Modelo Actual e a proposta do novo Modelo ........................................... 26
3.4. Concepção e Implementação da Aplicação Web .............................................................. 27
3.4.1. Apresentação dos Dados da Amostra ......................................................................... 27
 iii

3.4.2. Objectivo do Sistema .................................................................................................. 27

3.4.3. Utilizadores do Sistema .............................................................................................. 27
3.4.4. Levantamento de Requisitos do Sistema .................................................................... 28
3.4.5. Diagrama de Caso de Uso ........................................................................................... 31
3.4.6. Modelagem Conceitual ............................................................................................... 32
3.4.7. Projecto Navegacional ................................................................................................ 33
3.4.8. Projecto da Interface Abstrata ..................................................................................... 34
3.4.9. Implementação ............................................................................................................ 34
CONSIDERAÇÕES FINAIS, RECOMENDAÇÕES E LIMITAÇÕES ................................. 37
4.1. Considerações Finais ......................................................................................................... 37
4.2. Recomendações ................................................................................................................. 37
4.3. Limitações ......................................................................................................................... 38
Referência Bibliografica ........................................................................................................... 39
APÊNDICES ........................................................................................................................... 42
Apêndice I: Descrição de Caso de Uso ................................................................................. 43
Apêndice II: Diagramas de Actividade, de Sequência, de Componente e de Implantação .. 47
Apêndice III: Manual de Utilizador ...................................................................................... 51
ANEXOS ................................................................................................................................. 53
Anexo I: Documentos para Impressão no Sistema ............................................................... 54
 iv

Lista de Tabelas

Tabela 1: Técnicas que cada metodologia propõe para cada fase do processo de
desenvolvimento ....................................................................................................................... 12
Tabela 2: Etapas do método OOHDM ..................................................................................... 15
Tabela3: Requisitos Funcionais de CLINET ............................................................................ 28
Tabela 4: Requisitos Não Funcionais de CLINET ................................................................... 30
Tabela 5: Descrição de Caso de Uso Cadastrar Funcionário ................................................... 42
Tabela 6: Descrição de Caso de Uso Cadastrar Utilizador ....................................................... 43
Tabela 7: Descrição de Caso de Uso Cadastrar Pacientes ........................................................ 44
 v

Lista de Figuras

Figura 1: Fases de desenvolvimento de SI hipermédia segundo a metodologia OOHDM ...... 14

Figura 2: Entrada Principal do Centro Médico Privado do Benfica ......................................... 25
Figura 3: Diagrama de Casos de Uso do CLINET ................................................................... 31
Figura 4: Diagrama de Classe de CLINET .............................................................................. 32
Figura 5: Diagrama de Navegação do CLINET ...................................................................... 33
Figura 6: Painel Principal de CLINET ..................................................................................... 34
Figura 7: Diagrama de Actividade para Iniciar Sessão ............................................................ 47
Figura 8: Diagrama de Actividade para Marcação de Consulta ............................................... 47
Figura 9: Diagrama de Actividade para registar Produto Clínico ............................................ 48
Figura 10: Diagrama de Sequência para Iniciar Sessão ........................................................... 48
Figura 11: Diagrama de Sequência para Marcação de Consulta .............................................. 49
Figura 12: Diagrama de Sequência para Registro do Produto ................................................. 49
Figura 13: Diagrama de Componente de CLINET ................................................................... 50
Figura 14: Diagrama de Implantação de CLINET ................................................................... 50
Figura 15: Tela para início de sessão........................................................................................ 51
Figura 16: Estrutura da Aplicação ............................................................................................ 51
Figura 17: Tela de Painel Principal .......................................................................................... 52
Figura 18: VD do Centro Médico Privado do Benfica ............................................................. 54
Figura 19: Receita do Centro Médico Privado do Benfica ....................................................... 54
Figura 20: Prescrição para Laboratório do Centro Médico Privado do Benfica ...................... 55
Figura 21: Histórico Clínico utilizado no CMPB ..................................................................... 55
Figura 22: Recibo de Consulta gerado pelo Sistema ................................................................ 56
Figura 23: Histórico Clínico gerado pelo Sistema.................................................................... 56
 vi

Lista de Siglas, Abreviaturas e Símbolos

ADV Abstract Data View

ASD Adaptive Software Development
CASE Computer-Aided Software Engineering
CLINET Clinic Network
CPU Central Processing Unit
CRM Customer Relationship Management
CSS Cascading Style Sheet
DER Diagramas Entidades Relacionamentos
DFD Diagrama de Fluxo de Dados
DSDM Dynamic Systems Development Method
DSI Desenvolvimento de Sistemas de Informação
ERP Enterprise Resource Planning
EUP Enterprise Unified Process
FDD Feature Driven Development
FET Faculdade de Engenharias e Tecnologias
GB Gigabyte
HDM Hypertext Design Model
HTML Hyper Text Markup Language
MVC Model View Controller
NDT Navigational Development Techniques
OOHDM Object Oriented Hypermedia Design Method
OOWS Objective Opiate Withdrawal Scale
OPEN Object-oriented Process, Environment and Notation
PHP PHP Hypertext Preprocessor
RAD Rapid Application Development
RAM Random Access Memory
RF Requisito Funcional
RNA Relationship Navigational Analysis
RNF Requisito Não Funcional
 vii

RUP Rational Unified Process

SAD Sistemas de Apoio a Decisão
SE Sistemas Especialistas
SGBD Sistema de Gestão de Base de Dados
SHDM Semantic Hypermedia Design Method
SI Sistema de informação
SIG Sistemas de Informações Gerenciais
SOHDM Scenario-based Object-Oriented Hypermedia Design Methodology
SPT Sistema de Processamento de Transações
SQ Structured Query Language
TI Tecnologia de Informação
UID User Interaction Diagram
UML Unified Modeling Language
UWE UML-Based Web Engineering
WebML Web Modeling Language
WSDM Web Site Design Method
XP Extreme Programming
 viii

Declaração

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

Maputo, 21 de Abril de 2021

(Sualé Abdul Sualé)

 ix

Dedicatória

Esta Monografia é dedicada a todos que acreditam em mim.

 x

Agradecimentos

Primeiramente agradeço os meus pais (Francisco Ernesto Sualé e Ivone Bernardo) pelo direito
a vida, de seguida vai um especial agradecimento aos meus irmãos Fernandes Vesta, Carmina
Fernandes Vesta, Talbia Abdul Sualé e Carlos Fernandes Vesta que sempre estão do meu lado
e me apoiando.
Agradeço ao meu Supervisor pela paciência, confiança, apoio, encorajamento e completa
disponibilidade em todos os momentos da realização deste trabalho.
Agradeço o Centro Médico Privado do Benfica por terem cooperado para a concretização
deste trabalho.
A Direcção dos Serviços Sociais por ter concedido a bolsa de estudos para conclusão do meu
curso.
Agradeço ao Corpo Docente da Faculdade de Engenharias e Tecnologias da Universidade
Pedagógica de Maputo, em especial aos docentes do curso de Licenciatura em Informática,
que durante os quatro anos forneceram as bases para a minha formação académica.
Por fim, agradeço os meus colegas e amigos, que sempre estiveram dispostos a ajudar-me,
dando críticas, ideias e estímulo para que eu continuasse a desenvolver socialmente e
profissionalmente.
 xi

Resumo

A combinação de computadores, redes de telecomunicações, informações médicas e

dados electrónicos de pacientes pode melhorar a qualidade do cuidado de saúde e a
produtividade dos profissionais de saúde, facilitando o acesso aos recursos disponíveis e
reduzindo os custos administrativos associados à prestação desses serviços. Os sistemas de
informação, podem auxiliar nos diagnósticos médicos, assim como na competitividade
empresarial em saúde e ainda podem contribuir na melhoria do atendimento num serviço de
necessidade como é o hospitalar. Todavia, eles precisam garantir a integridade das
informações mantidas e fornecidas por eles, a fim de evitar consequências graves, como
processos judiciais ou indução ao erro médico. O estudo realizado no âmbito desta
monografia tem como objectivo desenvolver um sistema de informação que contribua na
melhoria da gestão hospitalar do Centro Médico Privado do Benfica. O centro em estudo
realiza as suas actividades de gestão, usando os métodos tradicionais, durante o percurso vão
provocando situações de perda de dados ou informações internas bem como dos pacientes,
demora na execução das actividades e duplicação de informações, isto os leva à redundância
de informação. Trata-se de pesquisa aplicada, com uma abordagem qualitativa, com suporte
da revisão bibliográfica e entrevista para a recolha de dados, tendo recorrido a comunidade
hospitalar como amostra. Para além da metodologia referida, utilizou-se a metodologia de
desenvolvimento ágil para a criação da solução almejada. Depois da implementação do
sistema desenvolvido, notou-se que este é benéfico para os pacientes bem como os
funcionários do centro em estudo, reduzindo bastante o tempo no processo de gestão
hospitalar e na tomada de decisão.

Palavras-chave: Sistema Web, Sistema de Gestão, Gestão Hospital, Contributos, Centro

Médico.
 xii

Abstract

The combination of computers, telecommunications networks, medical information

and electronic patient data can improve the quality of health care and the productivity of
health-care professionals, facilitating access to available resources and reducing the
administrative costs associated with the provision of these services. Information systems can
assist in medical diagnoses, as well as in business competitiveness in health and can also
contribute to the improvement of care in a service of need such as the hospital. However, they
need to ensure the integrity of the information maintained and provided by them in order to
avoid serious consequences, such as legal proceedings or induced medical error. The study
carried out in the context of this monograph aims to develop an information system that
contributes to the improvement of the hospital management of the Private Medical Center of
Benfica. The center under study carries out its management activities, using traditional
methods, during the route will cause situations of loss of data or internal information as well
as patients, delay in the execution of activities and duplication of information, this leads to
redundancy of information. This is an applied research, with a qualitative approach, with the
support of the bibliographic review and interview for data collection, having used the hospital
community as a sample. In addition to the methodology mentioned, the agile development
methodology was used to create the desired solution. After the implementation of the
developed system, it was noted that this is beneficial for patients as well as employees of the
center under study, greatly reducing the time in the hospital management process and decision
making.

Keywords: Web System, Management System, Hospital Management, Contributions,

Medical Centre.
 1

CAPÍTULO I - INTRODUÇÃO

O desenvolvimento crescente de tecnologias traz a necessidade de realizar tarefas de

maneira simples e informatizada, isto é, que seja exigido o menor esforço possível por parte
das pessoas.
As aplicações baseadas na web são exemplos dessa informatização, visto que há
facilidade de acesso por qualquer dispositivo com conexão à internet. Além disso, essas
aplicações geralmente possuem uma interface de usuário bastante amigável, o que melhora a
visualização para quem acede.
Para as organizações, os sistemas de informação têm grande importância porque
representam uma evolução tecnológica com largos benefícios para os seus negócios,
principalmente quando se consegue alinhar estratégias empresariais às estratégias em sistemas
de informação. Ainda nestas organizações pode-se constatar a existência de sistemas de
gestão, uma classe de S.I., que dá certo suporte na tomada de decisão e na coordenação das
actividades, seja avaliação, analise, facturação, entre outras existentes.
Focando na gestão hospitalar, os sistemas de informação auxiliam não só nos
diagnósticos médicos, mas na competitividade empresarial em saúde e na melhoria do
atendimento num serviço de necessidade social. Todavia, eles precisam garantir a integridade
das informações mantidas e fornecidas por eles, a fim de evitar consequências graves, como
processos judiciais ou indução ao erro médico.
Actualmente, o Centro Médico Privado do Benfica, não dispõe de nenhuma tecnologia
moderna para a gestão hospitalar, sendo assim, há fraco apoio nas tomadas de decisões
referentes aos diagnósticos, má gestão do estoque dos insumos, falta de atenção aos dados dos
pacientes, entre outros aspectos ligado ao funcionamento hospitalar.
Considerando os argumentos supracitados, o autor propõe uma solução tecnológica
que melhor se adequa ao caso de estudo, esta que consiste na implementação de um sistema
de web de gestão hospitalar, onde os utilizadores da aplicação poderão optimizar o tempo de
trabalho.
 2

1.1.Problema da Pesquisa

O Centro Médico Privado do Benfica é uma clínica especialmente vocacionada para a

realização de triagem geral, consulta de medicina interna, consulta de pediatria, consulta de
ginecologia/obstetrícia, cuidados de enfermagem, laboratório de analise clínicas, sala de
observação, sala de tratamento, dispensário de medicamentos e planeamento familiar.
A clínica possui uma parte farmacêutica, onde efectua a venda de medicamentos e
possui um estoque que necessita de um controle diário, dado que as entradas e saídas são
dinâmicas tornando-se complicado para os funcionários realizarem a estatística de maneira
eficiente.
Actualmente, o centro realiza as suas actividades de gestão, usando os métodos
tradicionais, durante o percurso vão provocando situações de perda de dados ou informações
internas bem como dos pacientes, demora na execução das actividades e duplicação de
informações, isto os leva à redundância de informação. Em suma, não colabora para uma
melhor eficiência nas actividades.
Denota-se também, que o centro em referência possui computadores em seu
consultório e não tendo disponível nenhum tipo de sistemas para gerenciar as actividades
desenvolvidas, como alternativa, utilizam uma planilha do Excel para efectuar uma cotação
ou facturação. Para além disto, o prontuário é feito de modo convencional, nesta óptica, os
funcionários clínicos levam mais tempo tentando encontrar o histórico do paciente do que a
efectuar a própria consulta ou análise. Neste caso, as actividades só podem ser feitas e
visualizadas dentro do consultório pelos funcionários, ocorrendo um grande consumo de
tempo por meio de comunicação via telefone ou pessoalmente tentando encontrar o melhor
dia para o agendamento do paciente à clínica.
Contudo, à medida que o tempo vai passando, a clínica também vai cada vez mais
crescendo, registando o incremento do número de pacientes o que vai afectar a eficiência no
atendimento dos pacientes pela morosidade na busca dos dados da consulta anterior e pela
busca dos preços referentes a cada tipo de serviço.
Constatou-se ainda, que a gestão de estoque nem sempre é de acordo com a entrada
por motivos inconclusivos, e isto, leva à uma queda no que diz respeito ao balanço dos lucros
da clínica. Estas constatações levaram-nos a busca de uma solução, que é consubstanciada na
seguinte questão: que contributo os sistemas de informação podem trazer na gestão deste
hospital?
 3

1.2.Justificativa

As empresas procuram com sistemas de informação armazenar dados específicos e

pequenas funcionalidades que devem ser automatizadas para tornar ágil o processo de tomada
de decisões e disponibilizar melhores serviços aos seus clientes.
Para o caso em estudo, notou-se que o centro ainda não está a fazer o uso dos sistemas
de informação para a gestão das suas actividades; sendo assim, torna-se motivador conceber
um sistema que irá permitir que os funcionários optimizem o tempo na busca de dados dos
pacientes.
A sociedade Moçambicana está num processo de migração e adesão às tecnologias de
informação para solucionar vários problemas pontuais, nesta pesquisa o autor gostaria de
deixa ficar o seu contributo para a sociedade médica concebendo um sistema de gestão
hospital.
A motivação reside também no facto de que a pesquisa proporcionará vários
benefícios para o autor, como a culminação do curso, trabalhar e ter experiência com os
diversos segmentos da gestão hospitalar.

1.3.Objectivos

1.3.1. Objectivo Geral

✓ Desenvolver um sistema de informação para melhorar a gestão hospitalar do Centro
Médico Privado do Benfica.

1.3.2. Objectivos Específicos

✓ Descrever o modelo actual da gestão do centro médico;
✓ Identificar os requisitos funcionais e não funcionais do sistema;
✓ Elaborar diagramas comportamentais para especificar detalhes do comportamento do
sistema;
✓ Conceber um sistema web de gestão hospitalar que respeite as especificidades do
CMPB;
✓ Inferir a sua aceitabilidade pela comunidade médica local.
 4

1.4.Metodologia de Pesquisa

O presente trabalho é uma pesquisa aplicada pois, tem como premissa fundamental
gerar conhecimentos para a aplicação prática e imediata. Do ponto de vista da forma de
abordagem, é uma pesquisa qualitativa, tendo como ambiente institucional o Centro Médico
Privado do Benfica para a colecta de dados.
Para a materialização desta pesquisa foi usada a revisão bibliográfica de modo a colher
várias experiências referentes ao contributo de sistemas de informação na gestão hospitalar.
Como técnica de recolha de dados foi usada a entrevista não estruturada de modo a
obter a situação real do funcionamento da gestão do Centro Médico Privado do Benfica.
Para além da metodologia de pesquisa, importa descrever a metodologia do
desenvolvimento de aplicação. Onde nesta pesquisa para se atingir os objectivos relactivos ao
desenvolvimento da solução foi utilizada a metodologia de desenvolvimento ágil denominada
OOHDM (Object Oriented Hypermedia Design Method), este que é um método de projecto
para aplicações hipermédia que descreve as tarefas a serem executadas desde a análise de
domínio da aplicação até a sua implementação.

1.5.Estrutura do Trabalho

Para uma melhor apresentação dos conteúdos, o trabalho está dividido em quatro
capítulos nomeadamente: Introdução, Referencial Teórico, Apresentação e Discussão dos
Resultados e Conclusão também tema sua Bibliografia e Apêndices.
O primeiro capítulo, apresenta a visão geral do trabalho, desde a problematização,
motivação/justificativa, os objectivos (geral e específicos), as metodologias de pesquisa.
Passando o primeiro capítulo, o segundo capítulo dedica-se ao referencial teórico,
onde são abordados vários conceitos que subsidiam e garantem a compreensão do tema em
estudo.
O terceiro capítulo, trás a analise dos resultados da criação do projecto englobando os
requisitos, os testes, os protótipos, entre outros aspectos de desenvolvimento.
O quarto e último, apresenta a conclusão sobre a questão colocada e as respectivas
recomendações.
 5

CAPÍTULO II – REFERENCIAL TEÓRICO

Neste capítulo pretende-se trazer um referencial teórico que preste um suporte

científico à presente pesquisa.

2.1. Sistema de Informação

Sistema de informação (SI) é um conjunto de elementos ou componentes

inter-relacionados que coleta (entrada), manipula (processo), armazena e dissemina dados
(saída) e informações, e fornece reacção correctiva (mecanismo de realimentação) para
alcançar um objectivo, STAIR (2016).
Um sistema de informação pode ser definido tecnicamente como um conjunto de
componentes inter-relacionados que coletam (ou recuperam), processam, armazenam e
distribuem informações destinadas a apoiar a tomada de decisões, coordenação e o controle de
uma organização, LAUDON & LAUDON (2011, p. 12).

2.1.1. Características dos Sistemas de Informação

Considerando que em um sistema de informação o objectivo é um fluxo mais confiável e
menos burocrático das informações, POLLONI (2000, p. 31), afirma que um sistema de
informação possui certas características que os tornam eficazes; características mencionadas a
seguir:
✓ Produzir informações realmente necessárias, confiáveis, em tempo hábil e com custo
condizente, atendendo aos requisitos operacionais e gerenciais de tomada de decisão.
✓ Ter por base directrizes capazes de assegurar a realização dos objectivos, de maneira
directa, simples e eficiente.
✓ Integrar-se à estrutura da organização e auxiliar na coordenação das diferentes
unidades organizacionais (departamentos, divisões, directorias, etc.) por ele
interligado.
✓ Ter um fluxo de procedimentos (internos e externos ao processamento) racional,
integrado, rápido e de menor custo possível.
✓ Contar com dispositivos de controlo interno que garantam a confiabilidade das
informações de saída e adequada protecção aos dados controlados pelo Sistema.
✓ Ser simples, seguro e rápido em sua operação.
 6

2.1.2. Classificação dos Sistemas de Informação

Segundo GUIZELINI (2011), os SI podem ser classificados de várias maneiras,
segundo o nível organizacional em que se encontram, segundo as áreas funcionais que
actuam, segundo o apoio dado pelo sistema ou segundo sua arquitectura. A classificação
mais abrangente e utilizada é segundo o apoio dado pelo sistema, seguindo essa classificação,
temos os seguintes sistemas:
Sistema de Processamento de Transações (SPT): processam grandes volumes de
dados e informações, apoiando procedimentos administrativos e os mais variados níveis
operacionais, com ênfase na eficiência.
Sistemas de Informações Gerenciais (SIG): processam grande volume de dados,
podendo ser a fonte externa ou interna, tendo como fonte principal o SPT, mas toda
informação gerada tem como característica o uso de gerência, sendo seu utilizador,
normalmente gerentes e administradores. Estes buscam a integração da informação e são
aplicadas em vários sectores e em várias funções da empresa.
Sistemas de Apoio a Decisão (SAD): estes geram e gerenciam informações de apoio
directo a tomada da decisão, sendo essas informações geradas pelos SIG e SPT.
Sistemas Especialistas (SE): são sistemas desenvolvidos para auxiliar um sector
específico, sendo desenvolvido especialmente para tal função, sendo muito mais complexo e
estruturados que os anteriores.

2.2. Sistemas de Gestão

Um sistema de gestão é um programa voltado para gerir todas as tarefas executadas

dentro de uma empresa.
Existem dois tipos de sistemas de gestão de negócios: Enterprise Resource Planning e
Customer Relationship Management.

2.2.1. Enterprise Resource Planning

Enterprise Resource Planning (ERP), cujo significado é Planeamento de Recursos
Empresariais, ele é um programa que tem a função de controlar e acompanhar os recursos
financeiros de um negócio, assim como a parte fiscal. O ERP encarrega-se de centralizar
todos os dados e processos da empresa consolidando informações de todos os
departamentos/sectores da organização como financeiro, contabilidade, recursos humanos,
fabricação, estoque, marketing, vendas, compras, distribuição entre outros, ajudando
 7

inclusivamente na optimização das vendas e seus indicativos gerenciais apoiam as tomadas de

decisões.

Implementação de ERP
A implementação de um sistema ERP pode ser definida como o processo pelo qual
módulos de sistemas são colocados em funcionamento em uma empresa. Ela envolve a
adaptação dos processos de negócio ao sistema, a parametrização e eventual customização do
sistema, a conversão dos dados iniciais, a configuração do hardware e software de suporte, o
treinamento de utilizadores e gestores e a disponibilização do suporte e auxílio. Essa etapa
contempla as tarefas que vão desde o término da elaboração do planeamento de
implementação até o momento do início da operação.

Vantagens de ERP
✓ Qualidade e eficácia;
✓ Redução de custos;
✓ Agilidade na gestão empresarial;
✓ Elimina o uso de interfaces manuais;
✓ Optimiza o fluxo da informação e a qualidade da mesma dentro da organização;
✓ Optimizão processo de tomada de decisão estratégicas e táticas;
✓ Elimina a redundância de actividades;
✓ Reduz os limites de tempo de resposta ao mercado;
✓ Reduz o tempo dos processos gerenciais;
✓ Redução de estoque e carga de trabalho;
✓ Melhoria de Infraestrutura de Hardware;
✓ Aprendizado em TI;
✓ Permite a coleta de dados de modo automatizado;
✓ Promove padronização dos sistemas de informação;
✓ Melhora os controles operacionais;
✓ Garante a confiabilidade e transparência aos dados.

Desvantagens de ERP
✓ A utilização do ERP por si só não torna uma empresa verdadeiramente integrada;
✓ Altos custos que muitas vezes não comprovam a relação custo/benefício;
✓ Dependência do fornecedor do pacote;
 8

✓ Adoção de melhores práticas aumenta o grau de imitação e padronização entre as

empresas de um segmento;
✓ Torna os módulos dependentes uns dos outros;
✓ Inserção de dados não confiáveis, quando é necessário o input pelo utilizador;
✓ Dificuldade de repasse da cultura Organizacional aos funcionários;
✓ O seu fornecedor pode descontinuar a sua versão de ERP sem aviso prévio.

2.2.2. Customer Relationship Management

Customer Relationship Management (CRM), ou simplesmente Gestão de
Relacionamento com o Cliente, é uma ferramenta que permite a gestão dos contactos que a
empresa estabelece com seus leads, com o objectivo de transformá-los em clientes e conseguir
fidelizá-los.

Importância de um CRM
O uso da sistemática CRM é importante porque através dessa, as empresas podem ter
conhecimentos melhores dos seus clientes e consequentemente dar um tratamento
diferenciado para eles.

Vantagens
✓ Optimização de tempo;
✓ Monitoramento da equipe de vendas;
✓ Relação mais próxima com os contactos;
✓ Integração de equipas;
✓ Utilização remota;
✓ Felicidade do cliente.

Desvantagens
✓ Software de qualidade;
✓ Um software de acordo com a sua empresa.
 9

2.3. Engenharia de Software

De acordo com PRESSMAN (2011, p. 39), engenharia de software é o

estabelecimento e o emprego de sólidos princípios de engenharia de modo a obter software de
maneira económica, que seja confiável e funcione de forma eficiente em máquinas.
Para SOMMERVILLE (2006, p. 17), a engenharia de software é a actividade de
especificação, projecto, implementação, validação, implantação e implementação de sistemas
sociotécnicos.

2.4. Desenvolvimento de Sistema

O desenvolvimento de sistemas de informação (DSI) visa introduzir a forma de

melhorar o desempenho de Sistemas de Informação, que geralmente é composto por seis fases
principais (estudo de viabilidade, engenharia de requisitos, desenho, codificação, testes e
implementação e manutenção).

2.4.1. Modelos de Processo de Sistema

Existem vários modelos para o DSI, onde estes podem ser chamados de ciclo de vida
de SI ou simplesmente ciclo de resolução de problema. Estes modelos definem as actividades
para o desenvolvimento de software, especificando os produtos de cada actividade e os papeis
das pessoas envolvidas.
Como foi supracitado, existem diferentes ciclos de resolução de problemas que se
enquadram em diferentes paradigmas; os modelos para o DSI podem ser de diferentes tipos
nomeadamente: desenvolvimento sequencial linear, desenvolvimento evolutivo e
desenvolvimento incremental.

Paradigmas de Desenvolvimento de Sistemas

No desenvolvimento de sistemas existem seis paradigmas, estes que de certa maneira
enquadram-se com os tipos de desenvolvimentos de sistema.

Modelo em Cascata
O Modelo em Cascata (Waterfall Model), surgiu no início dos anos 70, sendo o
primeiro paradigma que veio tentar disciplinar e sistematizar o desenvolvimento de sistema
informático ROYCE (1970).
 10

Autor como PRESSMAN (2002), sustenta que neste modelo as fases definidas são
sistematicamente seguidas de maneira linear.

Modelo Prototipagem
Um protótipo é uma versão experimental de um sistema, construído com o objectivo
de ser explorado, experimentado e avaliado. A característica principal desse modelo é gerar
protótipos do sistema com definições de requisitos dados pelo cliente. Essas definições geram
documentos que, por sua vez resultam no protótipo. A prototipagem permite aumentar a
participação e interesse dos utilizadores no processo de desenvolvimento e construir sistemas
em que os requisitos, a priori, estão mal definidos, ajudando na definição e clarificação dos
mesmos. É também um excelente contributo para o desenho de interface.

Modelo V
Este modelo e o Espiral, são duas aproximações ao processo de DSI que podem ser
vistos como evolução do modelo em cascata. O Modelo V (V Model) define um conjunto de
fases e ordenada em forma da letra V. Neste modelo, o processo de DSI é basicamente
dividido em duas partes, as duas pernas do V (a parte da especificação e a da verificação e
validação). O paradigma sugere que nenhuma fase pode ser considerada completa, e a
seguinte começar, até que o documento produzido esteja completo.

Modelo Espiral
O Modelo Espiral foi evoluindo ao longo do tempo e foi desenvolvido para incluir os
melhores aspectos de ciclo convencional e da prototipagem, acrescentando uma nova fase, a
análise de risco, inexistente em qualquer um dos modelos anteriormente referidos. Este,
engloba várias iterações através de sucessivos ciclos, os quais lhe conferem a forma espiral.
Uma das vantagens do modelo é a consideração dos riscos em todas as etapas do processo, o
que poderá permitir reduzir os riscos antes que eles se tornem problemáticos. Este modelo não
esta muito difundido e é muito menos usado, comparativamente com o ciclo de vida
tradicional e a prototipagem.

Modelo de Desenvolvimento Rápido de Aplicações

O desenvolvimento rápido de aplicações (RAD – Rapid Application Development),
enquadra-se no tipo de desenvolvimento incremental e visa um ciclo de desenvolvimento
 11

muito curto. Este, surgiu como uma reacção ao tradicional problema de DSI, nomeadamente,
tempos demasiado longos de desenvolvimento. A principal característica desde modelo é que
o produto de software seja desenvolvido em componentes, pois a reutilização de código
permite que a equipe de desenvolvimento possa desenvolver um sistema completamente
funcional em pouco tempo.

Modelo de Desenvolvimento de SI Web

Actualmente, grande parte dos sistemas desenvolvidos funciona em ambiente Web, o
que levou a questionar a necessidade da utilização de diferentes abordagens para o
desenvolvimento destes sistemas de informação, vistos como Web Information Systems.
Autor como SHERRELL (2001), afirma que o modelo W é uma dessas abordagens
que resulta da adaptação do modelo V., e esta adaptação baseia-se na substituição da fase de
codificação por uma fase designada por implementação incremental, que inclui uma etapa de
validação com o cliente, devido à importância que a interface com o utilizador tem nestes
sistemas. Todas as outras fases têm de existir, independentemente de se tratar de um sistema
web ou não.

2.4.2. Metodologias de Desenvolvimento de Sistema

No desenvolvimento de sistemas, podemos encontrar vários tipos de metodologia,
nomeadamente metodologia estruturada, metodologia orientada a objectos e metodologia
ágil.

Metodologia Estruturada
Neste modelo, encontramos técnicas como Diagrama de Fluxo de Dados (DFD),
Diagrama Estrutural, Dicionário de Dados, Especificação de Processos, Diagramas Entidades
Relacionamentos (DER) e Diagramas de Transições de Estado.

Metodologia Orientada a Objectos

As técnicas de programação orientadas a objectos foram discutidas pela primeira vez
no final da década 60. As primeiras metodologias de projecto orientadas a objecto, ainda que
não tivessem este nome, foram descritas por Michael Jackson e Jean-Dominique Wamier na
década de 1970, segundo AVISON (1997, p. 313).
 12

De acordo com BARBIERI (1997), diz que um dos factores críticos encontrados
actualmente no desenvolvimento de sistemas com orientação a objectos é a falta de definição
de uma linha metodológica a ser seguida no projecto. Uma vez que a orientação a objectos
nasceu das linguagens orientadas a objectos, eram estas que, inicialmente, desempenhavam o
papel de metodologias de sistemas.
Esta metodologia trata dados e processos como entidades logicamente separadas.
Onde um objecto combina dados e os processos específicos que operam nesses dados. A
metodologia orientada a objectos baseia-se em conceitos de classe e herança, possuindo um
conjunto próprio de diagramas e também usa alguns diagramas similares aos da metodologia
estruturada.
Existem várias metodologias orientadas a objectos, mais o autor mencionará as mais
destacadas:
✓ DESIGN THINKING;
✓ HDM - Hypertext Design Model;
✓ OOHDM – Object Oriented Hypermedia Design Method;
✓ OOWS - Objective Opiate Withdrawal Scale;
✓ OPEN – Object-oriented Process, Environment and Notation;
✓ RNA – Relationship Navigational Analysis;
✓ RUP – Rational Unified Process;
✓ SHDM - Semantic Hypermedia Design Method;
✓ SOHDM – Scenario-based Object-Oriented Hypermedia Design Methodology;
✓ UWE – UML-Based Web Engineering;
✓ W2000;
✓ WebML – Web Modeling Language;
✓ WSDM – Web Site Design Method.

Tabela 1: Técnicas que cada metodologia propõe para cada fase do processo de desenvolvimento

Requisitos Análise Design Implementação Testes

HDM X X Diagrama de Entidade e X X
Relacionamento.
OOHDM Modelagem de Análise de Diagrama de Contexto; e OOHDM-WEB; X
Casos de Uso Casos de Uso; Abstract Data View CGILua.
UIDs. (ADV).
WSDM Entrevista; Role Linguagem Object Role Modeling X X
Activity Diagram Natural. (ORM).
(RAD).
SOHDM Data Flow Diagram Cenários Cartões CRC; Class DBMSs; CGI; X
(DFD). (SAC); Lista Structure Diagram (CSD); HTML; Java;
de Eventos. OO View; Access Shockwaves.
 13

Structure Node (ASN).

RNA Entrevista Linguagem X X X
Natural
WebML Entrevista; Análise Templates; Esquema Estrutural em WebRatio X
de Documento; Linguagem XML; Notação Gráfica e
Sketching and Natural; Textual.
Storyboarding Análise de
Casos de Uso;
Teste de
Aceitação.
UWE Entrevista; Diagrama de Diagramas de Classes ArgoUWE X
Questionário; Classe; Estereotipados; Diagramas
Modelagem de Cenários; de Interação; Diagramas de
Casos de Uso. Análise de Estado; Diagramas de
Casos de Uso; Actividades; Diagramas de
Prototipação. Desenvolvimento.
W200 X Diagrama de Diagramas de Classes X X
Estado; Estereotipados; Diagramas
Análise de de Interação; Diagrama de
Casos de Uso. Cenário.
NDT Entrevista; JAD; Linguagem X X X
Brainstorming Natural;
Templates;
Patterns;
Análise de
Casos de Uso;
testes de
Aceitação.
DDDP Entrevista Prototipação Prototipação X X
Fonte: PESSINI (2015)

OOHDM
Conceitos Básicos

Antes de detalhar sobre a metodologia OODHM, torna-se importante conhecer alguns

conceitos navegacionais essenciais segundo OLIVEIRA (2002):
✓ Hipertexto: sistema ou aplicativo que permite criar, manter e manipular trechos de
informações (textos e gráficos) interligados de forma não-sequencial ou não-linear;
✓ Multimídia: combinação de texto, gráficos, desenhos, imagens, áudio e vídeo, em um
conjunto ou apresentação exclusiva de computador;
✓ Hipermídia: junção dos tipos de dados da multimídia com os mecanismos e
semânticas dos hipertextos;
✓ Nós: trechos de informação correspondentes a uma parte de um documento de
hipermídia ou de hipertexto.
✓ Elos: ligações entre dois nós. A activação de um elo invoca o nó de destino de seu
relacionamento.
✓ Hiperdocumento: rede de nós e elos. Uma aplicação pode ser composta por um ou
mais hiperdocumentos relacionados.
 14

✓ Âncoras: estrutura de activação de um elo (normalmente botões).

✓ Estruturas de acesso: menus ou índices hierárquicos que permitem ao utilizador o
desvio do fluxo principal de ideias ou ainda roteiros, podendo ser pré-definidos ou
não.

O OOHDM (Object Oriented Hypermedia Design Model) foi criado em 1994 por
Schwabe & Rossi e tem-se mostrado eficiente na redução de agravantes como a dificuldade
de manutenção e reusabilidade em relação à construção de sistemas hipermídia, além de ter
atingido uma boa popularidade dentre os modelos de desenvolvimento de aplicações sendo
que o modelo produzido pelo OOHDM pode ser implementado em qualquer tipo de ambiente
de desenvolvimento disponível no mercado, seja este orientado a objecto ou não HENNRICH
(2005).
Esta metodologia utiliza modelos que permitem um desenvolvimento incremental da
aplicação, com a obtenção de progressos em pequenos passos, através da divisão do problema
em subproblemas e a posterior combinação das soluções ROSSI (1996).

Figura 1: Fases de desenvolvimento de SI hipermédia segundo a metodologia OOHDM

Fonte: TEIXEIRA (2002, p. 4)

As quatro fases da metodologia OOHDM tratam aspectos diferentes de um mesmo

problema e geralmente envolvem equipas de trabalho, desde projectistas a programadores,
requerendo muitas vezes, serviços de designers. As duas primeiras fases abrangem a
 15

totalidade dos requisitos funcionais do sistema e a parte dos requisitos não funcionais,
nomeadamente a navegabilidade. A terceira etapa foca essencialmente aspectos não
funcionais relacionados coma interface humano-computador. Finalmente, e da
responsabilidade dos programadores, é a fase da implementação.

Tabela 2: Etapas do método OOHDM

ACTIVIDADES PRODUTOS MECANISMOS INTERESSES

Levantamentos de Actores, tarefas, cenários e
Requisitos casos de uso
Modelagem Classes, subsistemas,
Conceitual relacionamentos,
perspectivas de atributos
Projecto Nós, elos, estruturas de
Navegacional acesso, contextos de
navegação, transformações
navegacionais
Projecto da Interface Objectos de interface
Abstrata abstrata, reações a eventos
externos, transformações
de interface
Implementação Aplicação com execução
Fonte: SCHWABE (1995)
Análise de cenários, Capturar requisitos da
análise de caso de uso aplicação de forma
independente da
implementação
Classificação, Modelagem da semântica
composição, do domínio da aplicação
generalização,
especialização
Mapeamento entre Leva em conta o perfil de
objectos conceituais e de utilizador e a tarefa, ênfase
navegação, padrões de em aspectos cognitivos e
navegação para descrição arquiteturais
da estrutura geral a
aplicação
Mapeamento entre Modelagem de objectos
objectos de navegação e perceptíveis, implementa
objectos de interface metáforas escolhidas,
descrição de interface para
objectos navegacionais
Fornecidos pelo Desempenho,
ambiente alvo completitude
 16

Levantamento de Requisitos

Consiste na identificação dos utilizadores da aplicação que será desenvolvida e na

definição das tarefas que serão apoiadas pelo aplicativo.
Segundo GUELL (2000), esta etapa envolve as seguintes fases: identificação dos
actores e tarefas, especificação dos cenários, especificação dos casos de uso, especificação
dos UIDs (diagrama de interação dos usuários) e validação dos casos de uso e dos UIDs.
De acordo com SCHWABE (2002), na fase de identificação dos actores, o projectista
interagem com o domínio da aplicação a fim de identificar os autores e as tarefas que serão
apoiadas, ocorrendo através de análises de documentos disponíveis e entrevistas de modo a
atender os requisitos do usuário da aplicação.
Na fase de especificação dos cenários, os utilizadores especificam os cenários que
descrevem as tarefas a serem realizadas na aplicação hipermídia. Um cenário é a descrição
narrativa de como o utilizador pode utilizar a aplicação e pode ser especificada tanto pelo
utilizador como pelo projectista.
Segundo JACOBSON (1999), um caso de uso é o modo que a aplicação será utilizada.
Na fase de especificação de casos de uso, é apresentada a interação do utilizador com a
aplicação, sem considerar seus aspectos internos. O projectista especifica os casos de uso
baseado na especificação dos cenários realizados pelos utilizadores.
Na fase de especificação dos UIDs, são elaborados diagramas quere presentam
graficamente a interação do utilizador com a aplicação hipermédia descritas textualmente nos
casos de uso. O diagrama apresenta a troca de informações entre o usuário e a aplicação, sem
considerar especificamente seus aspectos internos.
Na fase de validação dos casos de uso e dos UIDs, que é a fase final, o projectista se
inter-relaciona com o utilizador a fim de validá-los. Nesta fase, são validados pelo utilizador
os casos de uso e os diagramas relacionados com o papel que ele executa.

Modelagem Conceitual

O modelo conceptual é o esquema responsável pela análise do domínio da aplicação,

englobando todo o universo de informações relevantes para o sistema a desenvolver. Este
modelo é constituído com base em classes de objectos, relações e subsistemas. Este esquema
consiste num conjunto de classes de objectos e subsistemas relacionados entre si, podendo as
relações ser enriquecidas com informações de multiplicidade. Os subsistemas representam
abstracções de um modelo conceptual completo, podendo estes possuir um ou mais pontos de
 17

entrada e de saída. As classes são descritas da mesma maneira que as classes dos modelos
tradicionais orientados a objectos.

Projecto Navegacional

O modelo navegacional, é definido a partir do modelo conceptual, especifica os

objectos de informação que serão apresentadas aos diferentes tipos de utilizadores (actores) e
a possível navegação entre eles. O este modelo deriva do esquema conceptual, através de um
conjunto de mecanismos de definição de visões, sendo possível a partir de um mesmo modelo
conceptual construir diferentes visões, tendo em conta os diferentes perfis de utilizadores.

Projecto da Interface Abstrata

Para BABA (2005), o projecto de interface abstrata descreve os objectos de interface
que podem ser vistos, suas propriedades e transformações durante a navegação, de forma a
descrever as interações do usuário com a aplicação. Nesta etapa envolve a abordagem de
projecto Abstract Data View (ADV) para descrever a interface de uma aplicação hipermídia.

Implementação

É a última etapa do processo de construção de aplicativos hipermídia. O sistema

hipermídia a ser executado é produzido após o mapeamento do design abstrato da interface
(os objectos perceptíveis e suas transformações) em objectos de interface concretos
(escolhidos no ambiente de implementação). Para a respectiva implementação pode ser feita
uso de frameworks, ferramentas, linguagens de programação e ambientes de desenvolvimento
que podem reduzir o esforço necessário para a execução desta etapa.

Servidor Web

De acordo com ALECRIM (2006), afirma que um servidor web é um computador que
processa solicitações Hyper Text Transfer Protocol (HTTP), que é um dos protocolos de
padrões para internet.
 18

Base de Dados

Segundo SUEHRING (2002), base de dados é uma colecção organizada de dados que
se relacionam de modo a criar algum sentido e dar mais eficiência durante uma pesquisa ou
estudo.

Sistema de Gestão de Base de Dados

Autor como SUEHRING (2002), afirma que um Sistema de Gestão de Base de Dados
(SGBD) é um conjunto de programas de computador responsáveis pela gestão de uma base de
dados, tendo como principal objectivo retirar da aplicação cliente a responsabilidade de gestão
de acesso, a manipulação e a organização dos dados.

Structured Query Language

Structured Query Language (SQL) ou Linguagem de Consulta Estruturada é uma

linguagem de pesquisa declarativa padrão para base de dados relacional. Muitas das
características originais da SQL foram inspiradas na álgebra relacional.

MySQL

Para NEVES (2005), o MySQL é um sistema de gestão de bases de dados relacionais,

suporta SQL, é open source e é um dos Sistemas de Gestão de Base de Dados para utilização
profissional mais utilizado e mais conhecido a nível mundial.
O autor SUEHRING (2002), sustenta que MySQL é um SGBD que usa a linguagem
SQL como interface, é de código fonte aberto com uma comunidade de desenvolvedores a
nível mundial e também protegido por uma licença GNU.

Linguagem de Programação

Uma Linguagem de Programação é uma linguagem escrita e formal que especifica um

conjunto de instruções e regras usadas para gerar programas (software). existem várias
linguagens de programação, mais para este estudo destacaremos: PhP e JavaScript.
 19

PhP

Segundo NIXON (2012), PHP é uma linguagem que se utiliza para fazer o servidor
gerar saídas dinâmicas, saídas essas que podem ser diferentes cada vez que se faz requisição
da página HTML.
O PHP (um acrônimo recursivo para PHP: Hypertext Preprocessor) é uma linguagem
de script open-source de uso geral, muito utilizada, e especialmente adequada para o
desenvolvimento web e que pode ser embutida dentro do HTML, segundo o site php.net
(2019).

JavaScript

(…) o JavaScript é importante, pois fornece funcionalidade dinâmica no navegador e,

através do Ajax, comunicação oculta com o servidor Web “modificar dados da interface sem
recarregamento das páginas”. NIXON (2012)

HTML

Segundo NEVES (2004:13), HTML significa Hyper Text Markup Language, e

consiste numa linguagem de formatação de texto que possibilita a construção
(programação/formatação) de ficheiros de texto, com a extensão htm ou html, que contêm
pequenas marcas (tags) que indicam ao Web browser como apresentar o conteúdo incluído ou
referenciado no documento, sob a forma de texto, imagens ou suportes multimédia.

CSS

CSS é chamado de linguagem Cascading Style Sheete é usado para estilizar elementos
escritos em uma linguagem de marcação como HTML.

Framework

De acordo o site Wikipedia1, um framework em desenvolvimento de software, é uma

abstração que une códigos comuns entre vários projetos de software provendo uma
funcionalidade genérica.
Para o site Gaea2, um framework é um template com diversas funções que podem ser
usadas pelo desenvolvedor.
1
Link: https://pt.wikipedia.org/wiki/Framework, acessado aos 22/09/2019 as 19h20min.
 20

Laravel

De acordo com Roberto3, o Laravel é um framework de desenvolvimento rápido para

PHP, livre e de código aberto.
O site DevMedia4, interpreta Laravel como um Framework PHP utilizado para o
desenvolvimento web, que utiliza a arquitetura MVC e tem como principal
característica ajudar a desenvolver aplicações seguras e performáticas de forma
rápida, com código limpo e simples, já que ele incentiva o uso de boas práticas de
programação e utiliza o padrão PSR-2 como guia para estilo de escrita do código.

Benefícios da OOHDM

São utilizadas as mesmas primitivas de modelagem (objectos, classes), simplificando

na transição de uma actividade para outra. Ao longo do processo utilizamos agregação,
classificação e generalização/especialização. Pelo facto de os objectos serem artefactos
relativos, podem ser construídas aplicações sofisticados baseados em hipermídia, definindo-se
padrões de comportamento e de comunicação entre objectos.
Há poderosos formalismos existentes para especificar a estrutura, o comportamento e
as relações dos objectos e podemos adaptá-los ao campo da hipermédia.
Aplicações projectadas e construídas em torno de objectos tendem a ser mais robustas
e fáceis de modificar, tanto pelo uso de polimorfismo e herança como por composição.
Fornecem primitivas de modelagem de alto nível na forma de padrões de projeto que podem
ser utilizadas sem alterações, ou modificadas de acordo com as necessidades do projectista.

Unified Modeling Language

A UML (Unified Modeling Language) significa "Linguagem de Modelagem

Unificada" é uma linguagem de especificação, documentação, visualização e
desenvolvimento de sistemas orientados a objectos. Esta permite que a equipe de
desenvolvedores de sistemas visualize os produtos de seus trabalhos em diagramas
padronizados e provê tais aspectos PENDER (2004):

2
Link: https://gaea.com.br/entenda-o-que-e-framework/, acessado aos 22/09/2019 as 19h14min
3
Link: https://medium.com/joaorobertopb/o-que-%C3%A9-laravel-porque-us%C3%A1-lo-955c95d2453d,
acessado aos 22/09/2019 as 19h25min.
4
Link: https://www.devmedia.com.br/laravel-tutorial/33173, acessado aos 22/09/2019 as 19h30min.
 21

✓ Especificação: A UML é uma excelente linguagem de modelagem para a

especificação dos diferentes aspectos de um sistema orientado a objecto.
✓ Documentação: Os documentos produzidos pela especificação, são materiais
importantes para controlar, medir, e refletir sobre um sistema durante o seu
desenvolvimento e implantação.
✓ Visualização: A representação dos modelos visuais facilita a comunicação e faz com
que os membros da equipe de desenvolvimento tenham a mesma visão do sistema
como um todo. Cada símbolo gráfico tem uma semântica bem definida através da
notação UML.
✓ Construção: Geração automática de código a partir do modelo visual e geração do
modelo visual a partir do código. O principal objectivo da UML é representar qualquer
tipo de sistema, em termos de diagramas orientados a objecto.

Um diagrama é uma representação gráfica de um conjunto de elementos (classes,

interfaces, colaborações, componentes, nós, etc) e são usados para visualizar o sistema sob
diferentes perspectivas.
A UML define um número de diagramas que permite dirigir o foco para aspectos
diferentes do sistema de maneira independente. Se bem usados, os diagramas facilitam a
compreensão do sistema que está sendo desenvolvido.

Diagrama de Casos de Uso

Especifica um conjunto de funcionalidades, através do elemento sintático “casos de

uso”, e os elementos externos que interagem com o sistema, através do elemento sintático
“actor” SILVA (2007). Além de casos uso e actores, este diagrama contém relacionamentos
de dependência, generalização e associação e são basicamente usados para fazer a modelagem
de visão estática do caso de uso do sistema.

Diagrama de Classes

É um modelo fundamental de uma especificação orientada a objectos. Produz a

descrição mais próxima da estrutura do código de um programa, ou seja, mostra o conjunto de
classes com seus atributos e métodos e os relacionamentos entre classes. Classes e
relacionamentos constituem os elementos sintáticos básicos do diagrama de classes SILVA
(2007).
 22

Diagrama de Objectos

Consiste em uma variação do diagrama de classes em que, em vez de classes, são

representadas instâncias e ligações entre instâncias. A finalidade é descrever um conjunto de
objectos e seus relacionamentos em um ponto no tempo. Contém objectos e vínculos e são
usados para fazer a modelagem da visão de projecto estática de um sistema a partir da
perspectiva de instâncias reais ou prototípicas.

Diagrama de Pacotes

O pacote é um elemento sintático voltado a conter elementos sintáticos de uma

especificação orientada a objectos. Sua finalidade é tratar a modelagem estrutural do sistema
dividindo o modelo em divisões lógicas e descrevendo as interações entre ele em alto nível.

Diagrama de Estrutura Composta

Fornece meios de definir a estrutura de um elemento ede focalizá-la no detalhe, na

construção e em relacionamentos internos. É um dos novos diagramas propostos na segunda
versão de UML, voltado a detalhar elementos de modelagem estrutural, como classes, pacotes
e componentes, descrevendo sua estrutura interna.

Diagrama de Componentes

É um dos dois diagramas de UML voltados a modelar software baseado em

componentes. Tem por finalidade indicar os componentes do software e seus relacionamentos.
Este diagrama mostra os artefactos de que os componentes são feitos, como arquivos de
código fonte, bibliotecas de programação ou tabelas de base de dados. As interfaces é que
possibilitam as associações entre os componentes.

Diagrama de Implantação

Consiste na organização do conjunto de elementos de um sistema para a sua execução.

O principal elemento deste diagrama é o nodo, que representa um recurso computacional.
Podem ser representados em um diagrama tantos os nodos como instâncias de nodos. O
diagrama de implantação é útil em projectos onde há muita interdependência entre pedaços de
hardware e software.
 23

Diagrama de Sequência

Mostra a troca de mensagens entre diversos objectos, em uma situação específica e

delimitada no tempo. Coloca ênfase especial na ordem e nos momentos nos quais mensagens
para os objectos são enviadas. Em diagramas de sequência, objectos são representados através
de linhas verticais tracejadas (denominadas como linha de existência), 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 de um objecto para outro na forma de setas com a operação e os
nomes dos parâmetros.

Diagrama de Máquina de Estados

Tem como elementos principais o estado, que modela uma situação em que o elemento
modelado pode estar ao longo de sua existência, e a transição, que leva o elemento modelado
de um estado para o outro. Este diagrama vê os objectos como máquinas de estados ou
autómatos finitos que poderão estar em um estado pertencente a uma lista de estados finita e
que poderão mudar o seu estado através de um estímulo pertencente a um conjunto finito de
estímulos.

Diagrama de Comunicação

Este diagrama está voltado a descrever objectos interagindo e seus principais

elementos sintáticos são “objecto” e “mensagem”.

Diagrama de Actividades

Representa a execução das acções e as transições que são acionadas pela conclusão de
outras acções ou actividades.

Diagrama de Visão Geral de Integração

É uma variação do diagrama de actividades, proposto na versão atual de UML. Seus

elementos sintáticos são os mesmos do diagrama de actividades.
 24

Diagrama de Temporização

Consiste na modelagem de restrições temporais do sistema. É um diagrama

introduzido na segunda versão de UML, classificado como diagrama de interação. Este
diagrama modela interação e evolução de estados.

Metodologia Ágil

Surge com o intuito de atender a demanda dos clientes e seus projectos de maneira
mais dinâmica, flexível e com maior produtividade, permitindo com que a equipe de
desenvolvimento focasse no software em si, e não em sua concepção e documentação como as
outras.
Segundo SOMMERVILLE (2011), na década de 1980 e início da década de 1990,
acreditava-se que a melhor maneira de desenvolver um software era por meio de um
planeamento cuidadoso do projecto, com qualidade da segurança formalizada, uso de
ferramentas CASE (Computer-aided software engineering) e de um processo de
desenvolvimento rigoroso e controlado.

Podemos encontrar como exemplos de metodologias ágeis para o desenvolvimento de

sistemas de informação as seguintes:
✓ ASD - Adaptive Software Development;
✓ Crystal;
✓ Desenvolvimento Lean de Software;
✓ DSDM - Dynamic Systems Development Method;
✓ EUP - Enterprise Unified Process;
✓ FDD - Feature Driven Development;
✓ Scrum;
✓ XP - Extreme Programming.
 25

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

PESQUISA

Neste capítulo apresentamos, analisamos e discutimos os resultados da pesquisa

segundo a ordem dos objectivos específicos.

3.1. Descrição do Local do Estudo

O Centro Médico Privado do Benfica é uma clínica especialmente vocacionada para a

realização de triagem geral, consulta de medicina interna, consulta de pediatria, consulta de
ginecologia/obstetrícia, cuidados de enfermagem, laboratório de analise clínicas, sala de
observação, sala de tratamento, dispensário de medicamentos, planeamento familiar.
Localiza-se em Moçambique, na cidade de Maputo, distrito Urbano 5 e municipal de
KaMubukwana, no bairro de George Dimitrov “Benfica”, na rua de São Paulo, casa no 597/74.

Figura 2: Entrada Principal do Centro Médico Privado do Benfica

Fonte: Autor.
 26

3.2. Modelo Actual

Actualmente, as actividades clínicas do Centro Médico Privado do Benfica são

realizadas de forma convencional, onde neste processo, a Recepcionista é a responsável por
atender o paciente na marcação de consulta. Durante este processo (marcação de consulta), a
Recepcionista leva mais tempo procurando a agenda do Médico para melhor enquadrar o
paciente. Após este evento ter decorrido com sucesso, o Médico gasta mais tempo procurando
o histórico do paciente para melhor o diagnosticar, por vezes pela fadiga ele volta a iniciar o
diagnostico do princípio e o leva a receitar a medicação antiga. O Técnico de Laboratório por
ser o responsável pela interpretação dos exames realizados pelos pacientes, torna-lhe
complicado poder afirmar de imediato se os exames actuais tiveram um avanço positivo ou
não em relação aos anteriores por falta de uma revisão rápida nos processos anteriores do
paciente, e isto, leva bastante tempo porque ele deve procurar pelos arquivos armazenados no
centro. A farmácia pode ser vista como um local bastante frequentado pelos pacientes, sendo
assim, a Farmacêutica leva mais tempo para identificar se a receita recebida contém todos os
medicamentos no estoque do centro, visto que deve procurar na estante. Outro factor que os
farmacêuticos têm passado é a demora no fecho do caixa, porque ele deve conferir os recibos
emitidos.

3.3. Limitações do Modelo Actual e a proposta do novo Modelo

A falta de um processo dinâmico e bem definido para a tomada de decisão no Centro

Médico Privado do Benfica causa lentidão no processo de marcação de consultas, tomada de
decisão do diagnostico, controle do estoque e a gestão do próprio centro. Sendo assim, o
centro procura uma forma inovadora e dinâmica que possa facilitar na gestão hospitalar do
centro e nas tomadas de decisões.
O modelo proposto pelo autor será baseado numa plataforma Web. Nesta aplicação,
será possível cadastrar os pacientes, marcar consultas, marcar exames, gerir agenda do
médico, gerir o estoque clínico e ajudar o médico na tomada de decisão.
 27

3.4. Concepção e Implementação da Aplicação Web

3.4.1. Apresentação dos Dados da Amostra

Para a realização desta pesquisa priorizou-se uma amostra de quatro (4) pessoas, sendo
estas colaboradores do CMPB. Onde tivemos um (1) Médico Clínico, um (1) Farmacêutico,
um (1) Técnico de Laboratório e uma (1) Recepcionista.
A amostra citada no parágrafo anterior foi utilizada para colecta de dados desta
pesquisa. Visto que o autor pretende obter informações mais detalhadas do funcionamento do
Centro em estudo, obteve por entrevista não-estruturada pela vantagem de deixar o
entrevistado à vontade e sem uso de nenhum guião. Sendo que no decorrer da entrevista
podem surgir novas questões com base na resposta ou discurso do entrevistado.
Os dados obtidos foram destinados para a elaboração dos requisitos funcionais e não
funcionais, assim como a identificação dos utilizadores do sistema.

3.4.2. Objectivo do Sistema

O Sistema de Gestão do Centro Médico Privado do Benfica, que o autor intitulou por
CLINET (Clinic Network), tem como principal objectivo ajudar o médico na tomada de
decisão e dinamizar o processo de marcação de consultas, assim como o controle dos produtos
clínicos.

3.4.3. Utilizadores do Sistema

A aplicação web (CLINET) proposta pelo autor têm como utilizadores do sistema os
seguintes:
✓ Recepcionista, com acesso parcial;
✓ Técnico(a) do Laboratório, com acesso parcial;
✓ Enfermeiro(a), com acesso parcial;
✓ Médico(a) Clínico(a), com acesso parcial;
✓ Farmacêutico(a), com acesso parcial;
✓ Gestor(a), com acesso parcial.
 28

3.4.4. Levantamento de Requisitos do Sistema

Requisitos do Utilizador

O Sistema de Gestão do Centro Médico Privado do Benfica tem como requisitos do

utilizador os seguintes:
✓ Para poder utilizar o sistema é necessário que os utilizadores tenham noções básicas de
Informática.
✓ O sistema deve permitir que os recepcionistas tenham privilégios de visualizar os
dados dos pacientes para poder marcar uma consulta e poder verificar a agenda do
médico.
✓ O sistema deve garantir que os utilizadores com privilégios administrativos tenham o
controle geral da aplicação.

Requisitos do Sistema

Os requisitos do sistema subdividem-se em dois grupos: Requisitos Funcionais (RF) e

Requisitos não Funcionais (RNF). Na página seguinte, o autor faz ilustra os grupos dos
requisitos com auxílio de uma tabela para melhor compreensão.

Requisitos Funcionais

Tabela3: Requisitos Funcionais de CLINET

Código Descrição Prioridade Depende de

Funcionários
RF01 Registar dados do funcionário através do sistema. Alta RF05
RF02 Actualizar os dados dos funcionários. Média RF01
RF03 Visualizar os dados dos funcionários. Alta RF01
Utilizadores
RF04 Registar-se no sistema através de dados do
Alta RF01
funcionário.
RF05 Iniciar sessão. Alta RF04
RF06 Terminar sessão. Alta RF05
Pacientes
 29

RF07 Registar dados do paciente através do sistema. Alta RF05

RF08 Actualizar os dados dos pacientes. Alta RF07
RF09 Visualizar os dados dos pacientes. Alta RF07
RF10 Filtrar os pacientes em função de nome. Média RF07
Agendas
RF11 Criar agenda do funcionário através do sistema. Alta RF03, RF05
Visualizar agenda do funcionário através do
RF12 Média RF11
sistema.
RF13 Filtrar datas em branco da agenda do funcionário. Alta RF11
RF14 Actualizar agenda do funcionário. Alta RF07
Consultas
RF15 RF05, RF09,
Marcar uma consulta através do sistema. Alta
RF12
RF16 Visualizar consulta do paciente. Média RF15
RF17 Realizar consulta do paciente através do sistema. Alta RF16
RF18 Filtrar consultas em função de dados do paciente. Média RF09, RF16
Exames
RF19 Marcar exame do paciente através do sistema. Alta RF16
RF20 Visualizar exames do paciente através do sistema. Alta RF19
RF21 Filtrar exames em função de dados do paciente. Média RF09, RF20
Análises
RF22 Realizar Análises do paciente. Alta RF20
RF23 Visualizar resultados da análise do paciente. Alta RF22
RF24 Filtrar resultados da análise do paciente. Média RF23
Receitas
RF25 Gerar receita da consulta do paciente. Alta RF17
RF26 Visualizar receita da consulta do paciente. Média RF25
Produtos Clínico
RF27 Registar um produto clínico através do sistema. Alta RF05
RF28 Visualizar produtos através do sistema. Média RF27
RF29 Actualizar dados do produto através do sistema. Média RF27
Fornecedores
RF30 Registar dados do fornecedor através do sistema. Alta RF05, RF28
 30

RF31 Actualizar os dados dos fornecedores. Baixa RF30

RF32 Visualizar os dados dos fornecedores. Alta RF30
RF33 Filtrar os fornecedores em função de produto Média RF32
clínico.
Vendas
RF34 Efectuar venda ao paciente. Média RF05, RF26,
RF28
RF35 Visualizar vendas efectadas ao paciente. Média RF34
RF36 Actualizar vendas efectadas ao paciente. Baixa RF34
Fonte: Autor.

Requisitos Não Funcionais

Tabela 4: Requisitos Não Funcionais de CLINET

Código Descrição Prioridade

RNF01 Uso de novas tecnologias de modo a tornar o sistema mais rápido. Alta
RNF02 Garantir autenticidade dos dados do utilizador a nível da aplicação. Alta
RNF03 Disponível para acesso a qualquer instante. Alta
RNF04 Funcionar do mesmo modo em qualquer dispositivo, seja com Alta
pouca memória e sem muito poder de processamento.
RNF05 Suporte de uma quantidade exorbitante de acesso ao sistema em Alta
simultâneo.
RNF06 Ter em consideração a má qualidade de conexão com a internet em Alta
Moçambique, sendo assim, deve ser desenhada de tal modo que não
submeta a desistência.
RNF07 Garantir que a conexão com o servidor seja segura o suficiente para Média
evitar roubo de informação por parte de hackers.
RNF08 Ser totalmente compatível com versões antigas dos navegadores. Alta
Fonte: Autor.
 31

3.4.5. Diagrama de Caso de Uso

Figura 3: Diagrama de Casos de Uso do CLINET

Fonte: Autor.
 32

3.4.6. Modelagem Conceitual

Figura 4: Diagrama de Classe de CLINET

Fonte: Autor.
 33

3.4.7. Projecto Navegacional

Página web

Iniciar sessão

Painel Agenda dos Exames Análises Sair do

Consultas Farmácia Funcionários Definições CLINET
Principal Médicos Clínicos Clínicas

Visualizar
Vendas Visualizar Utilizadores
Consulta

Visualizar Medicamento Níveis de

Receita s acesso

Pacientes Estoque

Fornecedores

Figura 5: Diagrama de Navegação do CLINET

Fonte: Autor.
 34

3.4.8. Projecto da Interface Abstrata

Figura 6: Painel Principal de CLINET

Fonte: Autor.

No desenvolvimento desta aplicação surgiram vários incrementos, incrementos estes que o

autor tratou como módulos. Onde após a finalização de um dado módulo o autor tinha uma
interação com o cliente que juntos chegavam a um desfecho e assim era feito o clico até a
finalização de todos os módulos.

3.4.9. Implementação
Para a implementação do sistema, o autor dividiu em duas fases nomeadamente,
elaborando um manual de implementação e de utilizador.

Manual de Implantação

O manual de implantação é um documento que visa demonstrar os passos e os

recursos necessários para implantação do sistema. Este documento específico, contém todas
as informações relativas à implantação do mesmo, desde os requisitos de sistema e hardware
ao passo da instalação. Sendo ele fundamental para os responsáveis pela instalação do
aplicativo.
Os recursos mínimos de hardware para a configuração:
✓ 256MB de memória RAM;
✓ 4GB de espaço em disco livre; e
 35

✓ Placa de rede com acesso à Internet.

Requisitos mínimo de software:

✓ Apache2 ou outro webserver com os mesmo recursos;
✓ MySQL, PHP;
✓ Navegador (mínimo Internet Explorer 11).

Requisitos para instalação e configuração:

✓ Descompactador de Arquivos de ZIP/RAR (WinRAR, Flzip, WinZip);
✓ Sistema de Gestão de Base de Dados (PHPMyAdmin);
✓ Cliente FTP (FileZilla, WinSCP, Cyberduck) para instalações remotas;
✓ Cliente SSH (Putty, SmarTTy) para instalações remontas; e
✓ Editor para HTML, PHP, JS, entre outros (VS Code, Sublime Text Editor,
Notepad++).

Com o uso do Cliente FTP ou SSH descompacta o arquivo ZIP/RAR, em seguida,

acessa o servidor de hospedagem e cria a base de dados com mesmo nome utilizado no
arquivo exportado localmente, o passo a seguir é a importação da base de dados para o
servidor, com uso do FTP envia os arquivos descompactados para a hospedagem, finalizando
o envio; o passo a seguir é de testar pelo nome de domínio atribuído se o sistema esta no ar e
se esta devidamente configurado.

Manual de Utilizadores

Esse manual tem como objectivo mostrar os passos sobre como os utilizadores podem
fazer o uso desta aplicação. (Em anexo em apêndices III)

Validação dos Objectivos da Pesquisa

Neste ponto, o autor pretende de forma mais clara mencionar a validação dos
objectivos traçados.
✓ Descrever o modelo actual da gestão do centro médico.
Conforme consta no trabalho, foi feito um estudo no Centro Médico Privado do
Benfica, onde foi possível compreender de forma mais transparente a regra de negócio
utilizada na forma tradicional com base nas entrevistas feitas.
✓ Identificar os requisitos funcionais e não funcionais do sistema.
 36

Os requisitos funcionais e não funcionais foram todos identificados através da regra de

negócio do Centro Médico Privado do Benfica.

✓ Elaborar diagramas comportamentais para especificar detalhes do

comportamento do sistema.

Os diagramas comportamentais foram todos elaborados através dos requisitos identificados no

ponto 3.4.4 e os diagramas foram exibidos nos pontos 3.4.5, 3.4.6, 3.4.8 e o apêndice II.

✓ Conceber um sistema web de gestão hospitalar que respeite as especificidades

do CMPB.

Após a identificação dos requisitos funcionais e não funcionais, e com os diagramas

comportamentais elaborados, foi possível conceber o sistema utilizando ferramentas
abordadas ao longo do trabalho e que foi configurada no modo local/offline para a sua
implementação.

✓ Inferir a sua aceitabilidade pela comunidade médica local.

O sistema foi implementado no centro médico e, com base nesse processo, foi possível
colectar alguns dados relacionados a utilização e impacto deste na gestão da informação
relativa a gestão hospitalar. O sistema reduziu a margem de erros garantindo a não
sobreposição de processo pessoal de cada paciente, também reduziu a morosidade no processo
de marcação de consultas sendo que é tudo feito offline (sem necessidade de locomoção) na
fase inicial e online posteriormente. Assim sendo, a comunidade médica local aprovou a
aplicação.
 37

CONSIDERAÇÕES FINAIS, RECOMENDAÇÕES E LIMITAÇÕES

4.1. Considerações Finais

No início da presente pesquisa constatou-se que as empresas procuram com sistemas

de informação armazenar dados específicos e pequenas funcionalidades que devem ser
automatizadas para tornar ágil o processo de tomada de decisões e disponibilizar melhores
serviços aos seus clientes e que o centro em estudo ainda não esta fazer o uso dos sistemas de
informação para a gestão das suas actividades e que havia uma dificuldade, por isso era
importante estudar sobre o contributo de sistemas de informação na gestão hospitalar.
Diante disso, a pesquisa teve como objectivo desenvolver um sistema de informação
para melhorar a gestão hospitalar do Centro Médico Privado do Benfica, onde este objectivo
geral foi atendido positivamente visto que, o centro em estuda está fazendo o uso de sistema
desenvolvido. Também foram respondidos os demais objectivos, neste caso os específicos,
onde há automatização do processo de manipulação de dados e os diagramas
comportamentais foram elaborados.
O autor concluiu que os sistemas de informação podem trazer vários contributos na
gestão hospital, onde foi possível chegar a essa conclusão com base no uso das metodologias
propostas para o estudo. Para o caso do Centro Médico Privado do Benfica, o sistema
implementado trouxe muitas vantagens no que tangue à gestão hospitalar nomeadamente: …
Por fim, o autor concluiu que apesar da existência de uma concepção de um sistema de
gestão automatizado seja uma abordagem consolidada, o processo de desenvolvimento deve
permanecer contínuo, onde com o decorrer do tempo surgirão novos contextos, perspectivas e
necessidades que serviram de bases para pesquisas futuras.

4.2. Recomendações

O autor recomenda aos futuros pesquisadores que implementem uma interface mobile
para que os pacientes possam agendar ou solicitar uma marcação de consultas online e que
tornem a aplicação web como multi-tenent porque com este conceito os utilizadores/clinicas
podem partilhar a mesma aplicação com regra de negócio diferente e o
desenvolvedor/pesquisador optimiza o tempo de desenvolvimento ou actualização do sistema.
Recomenda-se a actualização constante do sistema implementado, visto que podem
surgir novas políticas de segurança, também a actualização frequente na optimização de
tempo de resposta quando este for implementado à novas instituições de saúde como o caso
de clínicas e centro médicos.
 38

Importa destacar a recomendação voltada aos responsáveis de saúde, estes devem

invistam nos sistemas de gestão hospitalar distribuído, visto que, uma boa parte dos centros
ou clínicas dispõem de sistemas centralizados (manual ou informatizado).
Como última recomendação destina-se aos estudantes da área de tecnologia que
implementem recursos tecnológicos na área da saúde, visto que, o nosso maior valor é a vida e se
tivermos auxílio da robótica ou inteligência artificial para monitorar os responsáveis de saúde
caso comentam erro, será uma grande valia para a sociedade em geral.

4.3. Limitações

As principais limitações ou dificuldades encontradas durante o processo do

desenvolvimento desta pesquisa foram:
✓ Padronização da informação a ser publicada na aplicação;
✓ Escolha da tecnologia ideal para o desenvolvimento do sistema;
✓ Dificuldades em encontrar obras que abordam sobre o tema em estudo;
✓ Dificuldade na hospedagem do sistema por parte do centro em estudo;
✓ Insuficiência de computadores no Centro Médico Privado do Benfica; e
✓ Limitação ao acesso à internet no Centro Médico Privado do Benfica.
 39

Referência Bibliografica

[1] ALECRIM, E. (2006). Conhecendo o servidor apache.

[2] ASPLAN. (24 de Outubro de 2019). Quais as principais vantagens e desvantagens de
um ERP? Fonte: Asplan: https://www.asplan.com.br/vantagens-e-desvantagens-de-
um-erp/
[3] AVISON, D. F. (1997). Information Systems Development Methodologies, Techniques
and Tools. London: McGraw-Hill, 2 ed.
[4] BABA, F. (2005). Modelagens de aplicação multimídia. UEL.
[5] BARBIERI, C. (1997). A Unificação dos Métodos OO. Rio de Janeiro: Computerworld,
v3.
[6] BRITO, L. S. (2003). WEBS CHARTS: Uma Ferramenta de desenvolvimento de
aplicações Web baseada no HMBS/M. UFMS.
[7] CLARO, A. (2013). Sistemas Informações Gerenciais. Brasil.
[8] DE ALMEIDA, G. A. (2017). Factores de escolha entre metodologias de
desenvolvimento de software tradicionais e ágeis. São Paulo: Universidade de São
Paulo.
[9] DE SOUZA, I. (24 de Outubro de 2019). Sistema de gestão: quais as vantagens e como
escolher o melhor para seu negócio. Fonte: Rock Content:
https://rockcontent.com/blog/sistema-de-gestao/
[10] DIAS, D. S., & GAZZANEO, G. (1986). Projeto de Sistemas de Processamento de
Dados. Rio de Janeiro: LTC: 12ª Ed.
[11] DRUCKER, P. F. (2003). Inovação e espírito empreendedor (entrepreneurship):
prática e princípios. São Paulo: Pioneira Thomson.
[12] GUELL, N. S. (2000). Modeling interactions and navigation in web applications. In
Proceedings of the World Wild Web and Conceptual Modeling’00 Workshop.
[13] Guizelini, A. F. (2011). Sistemas Integrados de Gestão (ERP) com ferramenta de
mudança organizacional em pequenas empresas. São Paulo.
[14] HENNRICH, J. C. (2005). Estudo da Metodologia Orientada a Objetos OOHDM, para
Modelagem e Desenvolvimento de Websites. Florianópolis: Universidade Federal de
Santa Catarina.
[15] JACOBSON, I. B. (1999). The Unified Software Development Process.
[16] KONSCIANSKI, A., & SOARES, M. d. (2006). Qualidade de Software: Aprenda as
Metodologias e Técnicas mais Modernas para o Desenvolvimento de Software. São
Paulo: Novatec Editora.
[17] LAUDON, K., & LAUDON, J. (2011). Sistemas de Informação Gerenciais. Brasil:
Pearson, 9ª Ed.
 40

[18] LOH, S. e. (18 de Outubro de 2019). Descoberta do Conhecimento em Prontuários

Eletrônicos. Fonte: UNIFESP:
http://telemedicina.unifesp.br/pub/SBIS/CBIS2002/dados/arquivos/106.pdf
[19] McGEE, J., & PRUSAK, L. (1994). Gerenciamento estratégico da informação:
aumente a competitividade e a eficiência de sua empresa utilizando a informação
como uma ferramenta estratégica. Rio de Janeiro.
[20] NEVES, P. M. (2004). O Guia prático da HTML. Portugal: CENTRO
ATLANTICO.PT, 1. ed.
[21] NEVES, P. M. (2005). O Guia Prático do Mysql. Lisboa: Centro Atlântico, 1. ed.
[22] NIXON, R. (2012). Learning PHP, MySQL, JavaScript, and CSS. United States of
America: 2. ed.
[23] OLIVEIRA, D. d. (2002). Sistemas, organizações e métodos: uma abordagem
gerencial. São Paulo: 13 ed.
[24] OLIVEIRA, R. Z. (2002). Uso do modelo OOHDM para a construção de uma
aplicação de ensino voltada para o setor agropecuário. Brasil: Revista Brasileira de
Agroinformática, Lavras, v.4.
[25] PENDER, T. (2004). UML, a Bíblia. Rio de Janeiro: Editora Campus.
[26] PESSINI, T. S. (2015). Avaliando Metodologias de Desenvolvimento Web sob a
Perspectiva Acadêmica e Industrial. Paraná: Revista Eletrônica Científica Inovação e
Tecnologia.
[27] PINTO, V. B. (2006). Prontuário Eletrônico de Paciente: Documento Técnico de
Informação e Comunicação do Domínio da Saúde. Florianópolis: Florianópolis:
Revista Eletrônica de Bibliotecon. Ci. Inf. N. 21.
[28] POLLONI, E. (2000). Sistemas de informação: estudo de viabilidade. São Paulo:
Futura.
[29] PRESSMAN, R. S. (2002). Engenharia de Software. Rio de Janeiro: Makron Books, 5ª
Ed.
[30] PRESSMAN, R. S. (2011). Engenharia de Software: uma abordagem profissional.
Porto Alegre: AMGH Editora, 7 ed.
[31] PRESSMAN, R. S. (2011). Engenharia de Software: uma abordagem profissional. Ne
York: Mc Graw Hill, 7 ed.
[32] ROQUE, R. F. (1998). Estudo comparativo de metodologias de desenvolvimento de
sistemas de informação utilizando a técnica Delphi. Florianópolis: Universidade
Federal de Santa Catarina.
[33] ROSSI, G. (1996). OOHDM - Object Oriented Hypermedia Design Method. Rio de
Janeiro: PUC-Rio.
 41

[34] ROYCE, W. W. (1970). Managing the Development of Large Software Systems:

Concepts and Techniques. Los Angele: Technical Papers of Western Electronic Show
and Convention (WesCon).
[35] SANTOS, R. (2004). Satisfação do Usuário e sua Importância para o Projeto de
Interfaces. 3º. Congresso Internacional de Ergonomia e Usabilidade, Design de
Interfaces e Interação Humano-Computador. Rio de Janeiro.
[36] SCHWABE, D. R. (1995). The object-oriented hypermedia design model.
Communications of the ACM, vol. 38.
[37] SCHWABE, D. V. (2002). Notação do modelo oohdm. Rio de Janeiro.
[38] SETZER, V. (1999). Dado, informação, conhecimento e competência. DataGramaZero:
Revista de Ciência da Informação, 12.
[39] SHERRELL, L. e. (2001). The W Life Cycle Model and Associated Methodology for
Corporate Web Site Development. Communications of the Association for Information
Systems.
[40] SILVA, R. P. (2007). UML 2 em Modelagem Orientada a Objetos. Florianopolis: Visual
Books.
[41] SOMMERVILLE, I. (2006). Software Engineering. United States of America.
[42] SOMMERVILLE, I. (2011). Engenharia De Software. 9ª ed.
[43] STAIR, R. M. (2016). Princípios de Sistema de Informação. EUA: Cengage Learning,
11ª Ed.
[44] STAIR, R. M., & REYNOLDS, G. W. (2016). Princípios de Sistema de Informação.
EUA: Cengage Learning, 11ª Ed.
[45] SUEHRING, S. (2002). MySQL Bible. New York.
[46] TEIXEIRA, L. F. (2002). Desenvolvimento de aplicações hipermédia utilizando a
metodologia OOHDM: a possibilidade de incluir os requisitos funcionais e não
funcionais de um sistema. Portugal: Universidade de Aveiro.
[47] TZUKUMO, A. N. (1997). Qualidade de Software: Visões de Produto e Processo de
Software. São Paulo: Piracicaba: II Escola Regional da Sociedade Brasileira de
Computação de São Paulo – II ERI da SBC.
[48] VERSIT. (24 de Outubro de 2019). O que é um ERP, vantagens e desvantagens. Fonte:
Versit: https://solucoes.versit.com.br/erp-vantagens-e-desvantagens/
 42

APÊNDICES
 43

Apêndice I: Descrição de Caso de Uso

Tabela 5: Descrição de Caso de Uso Cadastrar Funcionário

Nome do caso de uso Cadastrar Funcionário

Actor principal Gestor
Resumo Neste caso de uso encontraremos três caso de usos
estendidos nomeadamente visualizar, registar e actualizar
funcionário no sistema, caso haja um funcionário registado
no sistema pode-se actualizar os seus dados se houver
necessidade.
Requisitos RF05.
Regras de Negócio RNF01
Pré-condições Não se aplica.
Pós-condições O utilizador deve possuir uma conta no sistema com base
nos dados inseridos no formulário de registo e ter a sessão
iniciada para poder partilhar o conteúdo do sistema.
Fluxo principal
Acções do actor Acções do sistema
1. Solicita o registo do
funcionário.
2. Verifica se o funcionário está registado.
3. Regista o funcionário caso não esteja registado, se
estiver registado actualiza os dados do funcionário.
Restrições Para registar um funcionário é necessário ter dados do
funcionário e ele pertencer a instituição.
Fluxo alternativo
Acções do actor Acções do sistema
1. Inserir dados do funcionário
i. O sistema valida todos os campos com base
no fluxo de dados.
ii. O sistema guarda todos dados informados.
iii. O sistema vai a tela de visualização de
funcionários.
Observações Apenas deve ser cadastrado todos funcionários do Centro
 44

em Estudo.
Fluxo de excepção
Acções do actor Acções do sistema
1. Dados incorrectos
i. O sistema verifica se todos os campos
obrigatórios estão preenchidos.
ii. Caso haja um campo obrigatório não
preenchido o sistema exibe uma mensagem
“O campo [nome do campo] é de
preenchimento obrigatório!”.
iii. O sistema verifica o tipo de dado preenchido
em cada campo.
iv. Caso haja um campo esteja preenchido com
um tipo de dado diferente o sistema exibe
uma mensagem “O campo [nome do campo]
não é do tipo [tipo do dado]”.
v. O sistema mantém-se na tela de registo de
funcionário.
Fonte: Autor

Tabela 6: Descrição de Caso de Uso Cadastrar Utilizador

Nome do caso de uso Cadastrar Utilizador

Actor principal Gestor
Resumo Neste caso de uso encontraremos três caso de usos
estendidos nomeadamente visualizar, registar e actualizar
utilizador no sistema, caso haja um usuário registado no
sistema pode-se actualizar os seus dados se houver
necessidade.
Requisitos RF01.
Regras de Negócio RNF01
Pré-condições Para poder cadastrar um utilizador é necessário cadastrar
um funcionário.
 45

Pós-condições Não se aplica.

Fluxo principal
Acções do actor Acções do sistema
1. Solicita o registo do
utilizador após
registar um
funcionário.
2. Verifica se o utilizadorestá registado.
3. Regista o utilizador caso não esteja registado, se
estiver registado actualiza os dados do utilizador.
Restrições Para registar um usuário é necessário ter dados do
funcionário.
Fluxo alternativo
Acções do actor Acções do sistema
1. Inserir dados do utilizador
i. O sistema guarda todos dados
informados.
ii. O sistema vai a tela de visualização de
funcionários.
Observações Apenas deve ser cadastrado utilizador após o cadastro de
funcionários.
Fonte: Autor.

Tabela 7: Descrição de Caso de Uso Cadastrar Pacientes

Nome do caso de uso Cadastrar Pacientes

Actor principal Recepcionista
Resumo Neste caso de uso encontraremos três caso de usos
estendidos nomeadamente visualizar, registar e actualizar
utilizador no sistema, caso haja um usuário registado no
sistema pode-se actualizar os seus dados se houver
necessidade.
Requisitos RF01.
 46

Regras de Negócio RNF01

Pré-condições Para poder cadastrar um utilizador é necessário cadastrar
um funcionário.
Pós-condições Não se aplica.
Fluxo principal
Acções do actor Acções do sistema
4. Solicita o registo do
utilizador após
registar um
funcionário.
5. Verifica se o utilizadorestá registado.
6. Regista o utilizador caso não esteja registado, se
estiver registado actualiza os dados do utilizador.
Restrições Para registar um usuário é necessário ter dados do
funcionário.
Fluxo alternativo
Acções do actor Acções do sistema
2. Inserir dados do utilizador
iii. O sistema guarda todos dados
informados.
iv. O sistema vai a tela de visualização de
funcionários.
Observações Apenas deve ser cadastrado utilizador após o cadastro de
funcionários.
Fonte: Autor.
 47

Apêndice II: Diagramas de Actividade, de Sequência, de Componente e de Implantação

Figura 7: Diagrama de Actividade para Iniciar Sessão

Fonte: Autor.

Figura 8: Diagrama de Actividade para Marcação de Consulta

Fonte: Autor.
 48

Figura 9: Diagrama de Actividade para registar Produto Clínico

Fonte: Autor.

Figura 10: Diagrama de Sequência para Iniciar Sessão

Fonte: Autor.
 49

Figura 11: Diagrama de Sequência para Marcação de Consulta

Fonte: Autor.

Figura 12: Diagrama de Sequência para Registro do Produto

Fonte: Autor.
 50

Figura 13: Diagrama de Componente de CLINET

Fonte: Autor.

Figura 14: Diagrama de Implantação de CLINET

Fonte: Autor.
 51

Apêndice III: Manual de Utilizador

Iniciar Sessão

Figura 15: Tela para início de sessão

Fonte: Autor

Para iniciar a sessão na plataforma é necessário estar registado para obter as

credenciais (E-mail e Senha), onde sem estas credenciais devemos solicitar o gestor do
sistema para a adesão. Caso tenha esquecido a Senha pode recuperar clicando no botão
(Esqueceu a Senha?).

Estrutura da Aplicação
Esta aplicação está organizada de modo a simplificar a visualização da informação e
facilitar a execução das tarefas ao utilizador do sistema.
A página encontra-se dividida em duas secções principais:
(1) Menu Lateral: acesso às tarefas necessárias para a gestão hospitalar e a
visualização dos dados do utilizador. Este menu situa-se do lado direito da página, por baixo
do nome do utilizador com a sessão iniciada, e está sempre visível.
(2) Secção de Informação: local onde todas as informações são apresentadas. Os
dados apresentados nesta secção mudam consoante as informações e tarefas selecionadas.

1 2
Figura 16: Estrutura da Aplicação

Fonte: Autor
 52

Neste sistema teremos a existência de certos ícones comuns, onde estes serão
exibidos nas telas de listagem de cada componente existente no menu lateral.

➢ Ícone que indica a impressão de dados .

➢ Ícone que indica a visualização de dados .

➢ Ícone que indica para actualizar os dados .

➢ Ícone que indica a eliminação do dado .

➢ Ícone que indica adicionar mais .

➢ Ícone que indica eliminar uma linha .

Painel Principal
O painel principal é a tela que ilustra um resumo das actividades da clínica, nesta tela
teremos o total das vendas feitas, o total dos medicamentos existentes, número total de
exames feitos e número total de funcionários registados. Para além destes totais, ilustra uma
lista resumidas das 10 últimas consultas (seja terminada como não).

Figura 17: Tela de Painel Principal

Fonte: Autor.

As telas restantes do manual encontram-se no documento separado intitulado

(Manual de Utilizador de CLINET).
 53

ANEXOS
 54

Anexo I: Documentos para Impressão no Sistema

Figura 18: VD do Centro Médico Privado do Benfica

Fonte: Autor

Figura 19: Receita do Centro Médico Privado do Benfica

Fonte: Autor
 55

Figura 20: Prescrição para Laboratório do Centro Médico Privado do Benfica

Fonte: Autor

Figura 21: Histórico Clínico utilizado no CMPB

Fonte: Autor
 56

Figura 22: Recibo de Consulta gerado pelo Sistema

Fonte: Autor

Figura 23: Histórico Clínico gerado pelo Sistema

Fonte: Autor

Copy protected with Online-PDF-No-Copy.com