REPÚBLICA DE ANGOLA
INSTITUTO MÉDIO TÉCNICO PRIVADO SANTA ANA & NOESA
CURSO TÉCNICO DE INFORMÁTICA
PROVA DE APTIDÃO PROFISSIONAL
(PAP)
13ª CLASSE
DESENVOLVIMENTO DE SISTEMA DE GESTÃO DE PACIENTES PARA O
HOSPITAL JOSINA MACHEL
António Francisco Chimuco
Emanuel José António
Luanda, 2025
INSTITUTO TÉCNICO PRIVADO SANTA ANA & NOESA
CURSO TÉCNICO DE INFORMÁTICA
PROVA DE APTIDÃO PROFISSIONAL
(PAP)
13ª CLASSE
DESENVOLVIMENTO DE SISTEMA DE GESTÃO DE PACIENTES PARA O
HOSPITAL JOSINA MACHEL
GRUPO:1
ANTÓNIO CHIMUCO
Nº5
EMANUEL ANTÓNIO
Nº12
TURMA: B
TURNO: TARDE
ORIENTADOR: CLÁUDIO DOMINGOS
DEDICATÓRIA
Dedicamos primeiramente este trabalho à Deus,
a todos que nos apoiaram na conclusão deste
projecto e nos motivaram a não desistir desde o
princípio.
i
AGRADECIMENTOS
Agradecemos primeiro a Deus por ter nos mantido na trilha certa durante este projecto de pesquisa
com saúde e forças para chegar até o final.
Somos gratos à nossa família pelo apoio que sempre nos deram durante toda a nossa vida.
Deixamos um agradecimento especial ao nosso professor Claúdio Domingos pelo incentivo e pela
dedicação do seu escasso tempo ao nosso projecto de pesquisa.
Também queremos agradecer ao instituto médio técnico privado Santa Ana & Noesa e a todos os
professores do nosso curso pela elevada qualidade do ensino oferecido.
ii
ÍNDICE DE FIGURAS
Figura 1 Diagrama de Caso de Uso ....................................................................................................... 25
Figura 2 Diagrama de Classe ................................................................................................................ 26
Figura 3 Estrutura de Menu ................................................................................................................... 27
Figura 4 Interface Gráfica ..................................................................................................................... 27
Figura 5 Página de Login ...................................................................................................................... 28
Figura 6 Modelo Lógico de Dados ........................................................................................................ 29
Figura 7 Arquitectura Lógica da Aplicação .......................................................................................... 30
Figura 8 HTML ..................................................................................................................................... 31
Figura 9 CSS ......................................................................................................................................... 31
Figura 10 JS........................................................................................................................................... 32
Figura 11 PHP ....................................................................................................................................... 32
Figura 12 SQL ....................................................................................................................................... 32
Figura 13 VSCODE .............................................................................................................................. 33
Figura 14 XAMP ................................................................................................................................... 33
Figura 15 STARUML ........................................................................................................................... 34
Figura 16 [Link] ................................................................................................................................. 34
Figura 17 Arquitetura Fisica do Sistema ............................................................................................... 35
Figura 18 Modelo Fisico do sistema ..................................................................................................... 36
Figura 19 Extrato de Codico ................................................................................................................. 37
Figura 20 Anexo .................................................................................................................................... 42
iii
ÍNDICE DE TABELA .............................................................................................................. iii
Tabela 1 Materiais Necessários .................................................................................................................... 16
TABELA 2 REQUISITOS FUNCIONAIS .................................................................................................. 22
Tabela 3 Requisitos Não Funcionais ............................................................................................................. 23
iv
SIGLAS E ABREVIATURAS
BD – Base de Dados;
CSS - Cascanding Styles Sheets (Folhas de Estilo em Cascata);
HTML - Hypertext Markup Language (Linguagem De Marcação De Hipertexto);
JS - JavaScript;
PT – Projecto Tecnológico;
PAP – Prova de Aptidão Profissional
PHP – Hypertext Preprocessor;
RF – Requisitos Funcionais;
RNF – Requisitos Não Funcionais;
RUP – Rational Unified Process;
SGBD – Sistema de Gerencionamento de Banco de Dados;
UML – Unified Modeling Language(Linguagem de Modelagem Unificada;
SQL – Strutured Query Language (Linguagem de Consulta Estruturada);
VSCode – Visual Studio Code;
ASIPU – Administração Serviços Informática Puniv.
v
SUMÁRIO
O presente trabalho apresenta o desenvolvimento de um sistema de gestão de paciente para
o hospital Josina Machel, visando otimizar os processos de atendimento, registro e
acompanhamento dos pacientes. O sistema proposto busca modernizar o controle de informações
hospitalares, melhorando a eficiência administrativa e qualidade do serviço de saúde prestado.
Palavras-chave: HTML, CSS, JavaScript, Controle de Assiduidade.
vi
INTRODUÇÃO
O Hospital Josina Machel, instituição de referência em Angola, necessita modernizar
seus processos de gestão de pacientes. Este projecto visa desenvolver um sistema integrado para
automatizar o registro médico, agendamento de consultas e acompanhamento de pacientes,
permitindo maior eficiência no atendimento e melhor qualidade dos serviços prestados. A
implementação desta solução tecnológica contribuirá para a otimização dos recursos hospitalares
e para o fortalecimento da assistência médica oferecida à população.
9
JUSTIFICATIVA
A necessidade de um sistema de gestão hospitalar é fundamentada em:
Melhoria na qualidade do atendimento aos pacientes.
Redução de erros em processos administrativos.
Otimização do tempo de atendimento.
Melhor gestão de recursos hospitalares.
Acesso rápido ao histórico médico dos pacientes.
10
OBJETIVOS
OBJETIVOS GERAIS
Desenvolver um sistema de gestão de pacientes que integre e automatize os principais
processos administrativos e médicos do Hospital Josina Machel.
Objectivos especificos
• Implementar um sistema de cadastro e gestão de pacientes.
• Desenvolver um módulo de agendamento de consultas.
• Criar um sistema de gestão de prontuários eletrônicos.
• Implementar controle de internações.
• Desenvolver interface de relatórios gerenciais.
11
METODOLOGIA UTILIZADA
O presente trabalho foi elaborado usando o método de pesquisa qualitativa, pós foi descrito de
forma prática e textual os objectivos do trabalho para a elaboração do website. Para o evantamento
de dados foram usadas as seguintes técnicas: estudo de campo e revisão bibliográficas.
• Revisão bibliográfica: Com está técnica, fizemos o agrupamentos dos dados por meio de
manuais de apoio (livros), que nos ajudaram a sustentabilizar os conceitos descritos no
presente projecto.
• Estudo de campo: usamos está técnica afim de se obter todo tipo de dados relevantes para
o projecto. Por meio de um estudo efectuado no campo da actuação, em forma de
questionários, entrevistas e análises que nos levaram a estar familiarizados com o problema
geral do trabalho.
12
ESTRUTURA DO RELATÓRIO
O nosso projecto está composto por 5 capítulos que são:
Capítulo 1: Neste capítulo são abordadas as questões inerentes ao processo de concretização do
projecto, de forma específica e faseada.
Capítulo 2: Neste capítulo fizemos a análise dos requisitos necessários para a concretização do
projecto, os números de posts de trabalhos em que a nossa rede afectou, bem como os
componentes físicos e lógicos que suportam a nossa rede;
Capítulo 3: É apresentado o desenho da aplicação, referindo-se ao diagrama/arquitectura lógica da
aplicação.
Capítulo 4: Faz-se a abordagem das tecnologias e ferramentas que suportam a aplicação web.
Capítulo 5: Neste capítulo faz-se uma abordagem da implementação da arquitectura física do
sistema e do modelo físico de dados.
13
CAPITULO 1 DOMÍNIO DO PROBLEMA
1.1. OBJETO DE ESTUDO
O objecto de estudo deste trabalho consiste no processo de gestão e acompanhamento de pacientes
no Hospital Josina Machel.
1.2. ÂMBITO DO PROJECTO
O projecto de desenvolvimento do Sistema de Gestão de Pacientes para o Hospital Josina
Machel visa implementar uma solução tecnológica abrangente que permita o registro,
acompanhamento e gerenciamento eficiente das informações médicas e administrativas dos
pacientes.
1.3. OBJETIVO DA INSTITUIÇÃO
O objectivo principal do desenvolvimento do Sistema de Gestão de Pacientes para o
Hospital Josina Machel é modernizar e aprimorar o atendimento hospitalar, criando uma plataforma
digital integrada que permita o registro eficiente e seguro de informações dos pacientes, otimizando
processos administrativos, melhorando a comunicação entre departamentos, facilitando o
acompanhamento clínico, garantindo a confidencialidade dos dados e proporcionando uma gestão
mais ágil e eficaz, com foco na qualidade do atendimento e na tomada de decisões estratégicas para a
instituição de saúde.
1.4. UTILIZADORES (POTENCIAIS)
Os utilizadores potenciais do sistema incluem médicos, enfermeiros, técnicos de
laboratório e farmácia, pessoal administrativo da recepção e do arquivo, bem como gestores e
administradores hospitalares do Hospital Josina Machel.
Usuário final:
1. Recepcionistas/Secretários(as)
2. Médicos
3. Enfermeiros(as)
4. Farmacêuticos
5. Técnicos de Laboratório
6. Administradores
7. Pacientes
1.5 ÁREAS DE AUTOMATIZAÇÃO (PROCEDIMENTO MANUAL)
Para obter informações precisas sobre as áreas de automatização e procedimentos manuais no
Hospital Josina Machel, sugiro:
14
1. Contactar diretamente a administração do hospital
2. Consultar documentação oficial do hospital ou do Ministério da Saúde de Angola 3. Falar
com profissionais que trabalham no hospital
SITUAÇÃO ATUAL
1.O hospital atualmente utiliza um sistema manual de gestão, baseado em fichas e
prontuários físicos, resultando em processos lentos e ineficientes no atendimento aos pacientes.
2.Há frequentes problemas de perda de informações, duplicidade de registros e dificuldade
no acompanhamento do histórico médico dos pacientes devido à falta de digitalização dos dados.
3.A comunicação entre diferentes setores do hospital é prejudicada pela ausência de um
sistema integrado, causando atrasos em procedimentos e possíveis erros na transmissão de
informações críticas.
1.7. PROBLEMAS A SEREM RESOLVIDOS
1. Dificuldades na gestão manual dos registros médicos, resultando em perda de informações
críticas dos pacientes e atrasos no atendimento.
2. Ineficiência no controle de agendamentos e filas de espera, causando sobrecarga no sistema
e insatisfação dos pacientes.
3. Falta de integração entre os diferentes setores do hospital, gerando duplicidade de dados e
comunicação deficiente entre as equipes médicas.
1.8. SOLUÇÃO PROPOSTA
[Link] de um sistema web integrado para gestão hospitalar, com interface intuitiva e
módulos específicos para cada área do hospital.
[Link]ção de banco de dados centralizado e seguro para armazenamento de informações dos
pacientes, com backup automático e controle de acesso.
[Link]ção de aplicativo mobile para médicos e enfermeiros acessarem informações dos
pacientes em tempo real, facilitando a tomada de decisões e o atendimento.
1.9. MATERIAIS NECESSÁRIOS, ESTIMATIVA DO CUSTO E APOIOS
Um projecto, criação ou desenvolvimento de uma aplicação web para qualquer que seja a
empresa, normalmente tem tido um orçamento médio, dividindo o dinheiro da deslocação e da
alimentação.
15
Tabela 1 Materiais Necessários
FONTE / NCR Angola
MATERIAIS CUSTO
Windows 10 125.538KZ
Microsoft Office 84.594,00KZ
Visual Studio Code Gratuito
Notebook 250.000KZ
Programadores 598.000KZ
XAMPP Gratuito
[Link] Gratuito
StarUML Gratuito
TOTAL 965.538KZ
16
1.10. VIABILIDADE DO PROJECTO
2. A viabilidade do projecto refere-se à sua capacidade de ser realizado com sucesso, levando
em consideração e diversos factores como recursos disponíveis, prazos, custos e benefícios
esperados.
3. O projecto é viável , pois existem condições técnicas e financeiras para o funcionamento da
aplicação.
17
CAPITULO 2 ANÁLISE DE REQUISITOS
2.1. METODOLOGIA APLICACIONAL
O método é um aspeto essencial para o sucesso de qualquer produto, e no desenvolvimento
de software isso não é diferente. Em geral, um software bem-sucedido é resultado de um
processo de desenvolvimento cuidadosamente elaborado. Para gerenciar um projecto com
eficiência, é fundamental escolher uma metodologia de software que se adeque ao contexto
específico do projecto. Por essa razão, optamos por utilizar a metodologia RUP (Rational
Unified Process), um framework de processo de software que organiza o desenvolvimento em
fases iterativas e incrementais, como Iniciação, Elaboração, Construção e Transição, garantindo
qualidade e previsibilidade ao longo do projecto.
O RUP combina boas práticas da engenharia de software e utiliza ferramentas como a UML
(Unified Modeling Language), que auxilia na modelagem e documentação dos sistemas,
promovendo uma melhor comunicação entre os membros da equipe e partes interessadas. Além
disso, a metodologia é eficaz para gerenciar mudanças nos requisitos e para manter a
rastreabilidade dos artefactos produzidos, assegurando o alinhamento estratégico do projecto
com os objectivos organizacionais. (Kruchten, 2003) (SOMMERVILLE, 2007) (MARTINS,
2007) (BOOCH, RUMBAUGH, & JACOBSON, 2000).
2.2 TIPOS DE APLICAÇÃO
Neste projecto, desenvolveremos uma aplicação web, um software acessado por meio de
navegadores como Google Chrome, Mozilla Firefox ou Safari. Essas aplicações residem em
servidores web e são executadas remotamente, permitindo que os usuários interajam com elas
sem a necessidade de instalação local. A interação ocorre por meio de uma interface de usuário,
fornecida pelos navegadores, sendo acessível de qualquer dispositivo conectado à internet.
As aplicações web variam em complexidade, desde páginas interativas simples até sistemas
robustos, como redes sociais, ferramentas de produtividade e plataformas de e-commerce. Para
oferecer uma experiência dinâmica e interativa, essas aplicações utilizam arquiteturas que
envolvem o front-end (lado do cliente) e o back-end (lado do servidor), garantindo comunicação
eficiente entre as camadas. Exemplos conhecidos incluem Gmail, Facebook, Google Docs e
outros serviços online amplamente utilizados. (SOMMERVILLE, 2007) (BOOCH,
RUMBAUGH, & JACOBSON, 2000).
2.3 UTILIZADORES DO SISTEMA
Utilizadores do sistema, ou simplesmente usuários, referem-se a pessoas que interagem com
uma aplicação ou sistema por meio de um navegador web. Existem diferentes tipos de utilizadores
de sistema e no nosso projecto teremos 4 tipos de utilizadores:
18
Os administradores: Administradores de sistemas geralmente são membros do departamento
de Tecnologia da Informação (TI). As funções de um administrador de sistemas são bem
abrangentes, e variam muito de uma organização para outra.
- Os usuários (comunidade): É um agente, tanto um agente humano (usuário final) como um
agente de software, que usa um computador ou serviço.
[Link] DE FUNÇÕES (BASEADO NA METODOLOGIA DO PONTO 2.1)
A metodologia RUP organiza as actividades de desenvolvimento de software em várias disciplinas,
onde cada disciplina é composta por uma série de processos ou funções essenciais.
As funções/processos do sistema na metodologia RUP são especificadas nas seguintes etapas:
1. Gestão de Projectos;
2. Modelagem de Negócios;
3. Requisitos;
4. Análise e Design;
5. Implementação;
6. Testes;
7. Implantação;
19
2.4.1. ESPECIFICAÇÃO DOS PROCESSOS/ FUNÇÕES DO SISTEMA (PONTO 2.1)
Na metodologia RUP, as funções/processos do sistema são especificadas nas seguintes
etapas:
1. Gestão de Projectos:
• Definição de Objetcivos do Projecto: Estabelece metas e objectivos claros que o projecto deve
alcançar.
• Planejamento do Projecto: Elabora um plano detalhado para a execução das actividades do
projecto, incluindo cronogramas e alocação de recursos.
• Acompanhamento e Controle: Monitora o progresso do projecto, identificando desvios e
aplicando medidas corretivas quando necessário.
2. Modelagem de Negócios:
• Modelagem de Processos de Negócios: Descreve os processos de negócios que serão abordados
pelo sistema, garantindo uma compreensão clara do contexto organizacional.
Identificação de Actividades Críticas: Define as actividades-chave que impactam o sucesso do
projecto, priorizando-as para garantir a entrega de valor.
3. Requisitos:
• Identificação de Requisitos: Coleta, analisa e documenta os requisitos funcionais e não
funcionais do sistema.
• Gerenciamento de Mudanças de Requisitos: Acompanha e controla alterações nos requisitos
durante o ciclo de vida do projecto, garantindo que o impacto seja gerenciado de forma eficaz.
4. Análise e Design:
• Modelagem de Análise: Cria modelos que representam o sistema a partir da perspectiva do
usuário, como casos de uso e fluxos de interação.
• Modelagem de Design: Desenvolve modelos detalhados que descrevem a estrutura interna do
sistema, seus componentes e interações.
5. Implementação:
• Codificação: Traduz os modelos de design em código executável, garantindo que as
funcionalidades sejam implementadas conforme especificado.
• Testes Unitários: Realiza testes em módulos individuais para verificar se cada componente
funciona corretamente de forma isolada.
20
6. Testes:
• Testes de Integração: Avalia a interação entre diferentes componentes do sistema, garantindo
que funcionem juntos como esperado.
• Testes de Sistema: Realiza uma avaliação completa do sistema para verificar se ele atende aos
requisitos definidos.
7. Implantação:
• Preparação para Implantação: Planeja e executa a transição do sistema para o ambiente de
produção, incluindo a configuração de infraestrutura necessária.
• Suporte à Implantação: Oferece assistência técnica e operacional durante o processo de
implantação, garantindo uma transição suave e eficiente.
Essa abordagem, baseada na metodologia RUP, assegura que todas as funções do sistema
sejam claramente definidas, implementadas e testadas de forma estruturada, atendendo aos
requisitos estabelecidos antes de avançar para as próximas fases do desenvolvimento. (Kruchten,
2003) (SOMMERVILLE, 2007) (MARTINS, 2007) (BOOCH, RUMBAUGH, & JACOBSON,
2000).
2.4.2. REQUISITOS FUNCIONAIS
Requisitos funcionais são todos os problemas e necessidades que devem ser atendidos e
resolvidos pelo software por meio de funções ou serviços.
Na metodologia RUP, os requisitos funcionais são identificados e detalhados na fase de
Levantamentos de Requisitos. Esses requisitos descrevem as funções específicas que o sistema deve
realizar. (Kruchten, 2003) (Pressman, 2014).
21
TABELA 2 REQUISITOS FUNCIONAIS
Código Módulo Requisito Funcional Descrição
Sistema deve permitir cadastro
RF001 Registro de paciente completo de pacientes com:
dastro de pacientes nome completo, data
nascimento, gênero,
documento de identificação,
contato, endereço, tipo de
sangue, histórico médico
pregresso
RF002 Registro Médico Prontuário Digital Registrar todos os
atendimentos, consultas,
ações e procedimentos realizados
RF003 Agendamento Marcação de consultas Permitir agendamento online e
presencial de consultas por
especialidade
RF004 Internação Controle de Leitos Registrar entrada, evolução clínica
e alta hospitalar
RF005 Exames Solicitação/Resultado Permitir solicitação,
agendamento e registro de
resultados de exames
RF006 Prescrição Medicação Digital Emitir prescrições médicas com
registro de medicamentos,
dosagens e instruções
RF007 Segurança Controle Acesso Gerenciar níveis de acesso por
perfil de usuário (médico,
enfermeiro, administrativo)
RF008 Relatórios Indicadores
22
2.4.3. REQUISITOS NÃO FUNCIONAIS
Requisitos não funcionais são os requisitos relacionados ao uso da aplicação em termos
de compatibilidade, disponibilidade, usabilidade e manutenibilidade. Estes requisitos dizem
respeito a como as funcionalidades serão entregues ao usuário do software. (Kruchten, 2003)
(Pressman, 2014).
Na metodologia RUP, os requisitos não funcionais para um aplicativo web de controle de
assiduidade dos profissionais de saúde podem ser especificados da seguinte forma:
Tabela 3 Requisitos Não Funcionais
Código Categoria Requisito Não Descrição
Funcional
RNF01 Desempenho Tempo de Resposta O sistema deve responder a
consultas em tempo real
RNF02 Disponibilidade Funcionamento O sistema deve estar disponível
Contínuo 24/7 com mínimo de
interrupções
RNF03 Segurança Proteção de Dados Garantir a confidencialidade dos
dados dos pacientes
RNF04 Usabilidade Interface Intuitiva Interface amigável e de fácil
utilização para profissionais de
saúde
RNF05 Escalabilidade Capacidade de O sistema deve suportar o
Expansão crescimento da base de dados
RNF06 Backup Recuperação de Dados Realizar backup periódico dos
dados
RNF07 Conformidade Padrões de Saúde Aderência às normas e
regulamentos de saúde
RNF08 Portabilidade Acesso Multiplataforma Sistema acessível em diferentes
dispositivos
RNF09 Manutenção Facilidade de Código e estrutura que
Manutenção permitam atualizações e
correções
RNF10 Integração Interoperabilidade Capacidade de integração com
outros sistemas hospitalares
23
2.4.4. DIAGRAMA (BASEADO NA METODOLOGIA DO PONTO (2.1)
Diagrama é um desenho simplificado mostrando a aparência, estrutura ou funcionamento de
algo, ou seja, uma representação esquemática.
Na metodologia RUP existem alguns diagramas comumente utilizados, mas de acordo com
o nosso projecto utilizaremos o diagrama de casos de uso e de classe.
1. DIAGRAMA DE CASO DE USO
Caso de uso é um modelo que descreve como diferentes tipos de usuários interagem com
o sistema para resolver um problema. Como tal, ele descreve as metas dos usuários, as
interações entre os usuários e o sistema para satisfazer estas metas.
Figura 1 Diagrama de Caso de Uso
2. ESPECIFICAÇÕES
Na metodologia RUP, o diagrama de casos de uso é uma ferramenta fundamental para representar
interações entre atores e o sistema.
Suas principais especificações incluem:
[Link]: representa um papel externo que interage com o sistema. Pode ser uma pessoa, um sistema
externo, ou mesmo outro sistema.
[Link] de Uso: descreve uma interação específica entre um ator e o sistema. Geralmente, é
nomeado de acordo com a funcionalidade que oferece ao usuário.
24
[Link]: os casos de uso podem ter relacionamentos, como inclusão (quando um caso
de uso é parte de outro) e extensão (quando um caso de uso opcional pode ser adicionado a outro).
3. DIAGRAMA DE CLASSE
Diagrama de classes são cópias do sistema ou subsistema. Você pode utilizar os diagramas de
classe para modelar os objectos que compõem o sistema, para exibir os relacionamentos entre
os objectos e para descrever o que esses objectos fazem e os serviços que eles fornecem.
Figura 2 Diagrama de Classe
25
CAPITULO 3 DESENHO
3.1. ESTRUTURA DE MENU
A estrutura de menu refere-se a forma como o conteúdo é agrupado. Às vezes, ela é chamada de
arquitetura do site e diz respeito a como o conteúdo se conecta e é apresentado aos usuários e
mecanismo de pesquisa. (Mileto, 2015) (SOMMERVILLE, 2007).
Figura 3 Estrutura de Menu
3.2. ESTRUTURA DE INTERFACE GRÁFICA COM O UTILIZADOR
Uma interface gráfica com o usuário (GUI) é um ambiente visual que permite aos usuários
interagirem com dispositivos ou softwares por meio de elementos gráficos, com botões, ícone e
menus. (SOMMERVILLE, 2007) (Pressman, 2014)
Figura 4 Interface Gráfica
26
3.2.1 PÁGINA DE LOGIN
Uma página de login é uma interface em um site ou aplicativo que solicita que o usuário insira
sua credencial, como nome de usuário e senha, para acessar a página principal do site ou aplicativo.
A figura abaixo representa a tela de login onde os atores do sistema irão efectuar o login.
Figura 5 Página de Login
27
3.3. MODELO LÓGICO DE DADOS
O modelo lógico de dados estabelece a estrutura dos elementos de dados e os relacionamentos
entre eles. (Machado, 2010) (SOMMERVILLE, 2007) (Hernandez, 2013).
Figura 6 Modelo Lógico de Dados
28
3.4. A ARQUITETURA LÓGICA DE APLICACÃO
A arquitetura da aplicação define a articulação lógica dos componentes e serviços em
software sem estabelecer uma escolha definitiva sobre a maneira de aplicação, ou seja, trata-se da
definição da base estrutural. (Kruchten, 2003) (SOMMERVILLE, 2007) (Machado, 2010)
Figura 7 Arquitetura Lógica da Aplicação
29
CAPITULO 4 TECNOLOGIAS E FERRAMENTAS UTILIZADAS
4.1. TECNOLOGIAS UTILIZADAS (CONCEITOS\ DEFINIÇÕES)
• HTML
• CSS
• JavaScript
• SQL
HTML, ou HyperText Markup Language, é a linguagem de marcação usada na construção e
estruturação de páginas web. Ele é fundamental para a criação de conteúdo na web, pois define a
estrutura básica de uma página indicando elementos como títulos, parágrafos, listas, links, imagens
e outros. (Mileto, 2015)
Figura 8 HTML
CSS, ou Cascading Style Sheets, é uma linguagem de estilo utilizada em conjunto com
HTML para controlar a apresentação e o layout de elementos em uma página web. Enquanto o
HTML trata da estrutura e do conteúdo da página, o CSS define o estilo, a formatação e a aparência
desses elementos. (Mileto, 2015)
Figura 9 CSS
JavaScript é uma linguagem de programação de alto nível amplamente utilizada para
desenvolvimento web. Ela permite criar interatividade em páginas da web, sendo executada nos
navegadores dos usuários. JavaScript é essencial para criar funcionalidades dinâmicas, como
30
validação de formulário, manipulação do DOM (Modelo de Objeto de Documento) e interação
assíncronas com o servidor. (Flanagan, 2020) (Mileto, 2015)
Figura 10 JS
PHP é uma linguagem de script de servidor, amplamente usada para desenvolvimento web.
Ela é especialmente adequada para criar páginas web dinâmica e interativas. (Mileto, 2015)
Figura 11 PHP
SQL (Structured Query Languagem): Linguagem de consulta estrutura utilizada para gerenciar
emanipular bancos de dados relacionais. (Machado,2010)
Figura 42 SQL
31
4.2 FERRAMENTAS UTILIZADAS (CONCEITOS/DEFINIÇÕES)
As ferramentas utilizadas na conclusão do nosso projeto são as seguintes:
• Visual Studio Code
• XAMPP
• Star UML
• [Link]
O Visual Studio Code (VS Code) é um editor de código-fonte moderno, leve e altamente
extensível, desenvolvido pela Microsoft. Projetado para oferecer uma experiência otimizada de
desenvolvimento, ele suporta múltiplas linguagens de programação e fornece recursos avançados,
como realce de sintaxe, autocompletar inteligente, depuração integrada e integração com sistemas
de controle de versão, como o Git. (Gamarra, 2023).
Figura 13 VSCODE
XAMPP é uma distribuição gratuita e de código aberto que facilita o processo de
desenvolvimento web, fornecendo um ambiente completo e pré-configurado para rodar servidores
web localmente. O XAMPP inclui o Apache (servidor HTTP), MySQL (banco de dados), PHP
(linguagem de programação), e Perl, permitindo que desenvolvedores criem, testem e desenvolvam
seus sites ou aplicativos de forma eficiente e sem a necessidade de configurar cada componente
separadamente. (Henderson, 2013).
Figura 14 XAMP
O StarUML é uma ferramenta avançada de modelagem de software que permite criar, editar e
gerenciar diagramas complexos utilizando padrões como UML 2.x, SysML e outras notações (como
ERD e DFD). Sua proposta é oferecer uma modelagem ágil e extensível, possibilitando que equipes
32
de desenvolvimento e profissionais acadêmicos representem visualmente a estrutura, o
comportamento e os requisitos de sistemas de forma clara e eficiente. (StarUML, 2024).
Figura 15 STARUML
O [Link] é uma ferramenta gratuita e de código aberto para a criação, edição e colaboração em
diagramas. A ferramenta oferece uma interface intuitiva de arrastar e soltar, permitindo elaborar
diversos tipos de diagramas como fluxogramas, diagramas UML, diagramas de rede, entre outros,
de maneira rápida e visual. Além disso, o [Link] possibilita salvar os diagramas tanto localmente
quanto em serviços de armazenamento na nuvem (como Google Drive, OneDrive e Dropbox) e
suporta a exportação para formatos como PNG, JPEG, SVG e PDF, facilitando a integração e o
compartilhamento dos seus projetos. ([Link], s.d.).
Figura 16 [Link]
33
CAPITULO 5 IMPLEMENTAÇÃO
5.1. ARQUITETURA FÍSICA DO SISTEMA
Uma arquitetura de sistema é uma representação de um sistema em que existe um
mapeamento de funcionalidade para componentes de hardware, descreve também o comportamento
e relações entre as entidades a ele pertencentes. (Stallings, 2017) (Hennessy, 2000).
Figura 17 Arquitetura Física do Sistema
34
5.2. MODELO FÍSICO DE DADOS
Um modelo físico de dados introduz o contexto específico do banco de dados ausente em
modelos conceituais e lógicos de dados. Ele representa as tabelas, colunas, tipos de dados,
visualizações, restrições, índices e procedimentos dentro do banco de dados. (Machado, 2010)
(SOMMERVILLE, 2007) (Hernandez, 2013).
Figura18 Modelo Físico do sistema
35
5.3. EXTRATOS DE CÓDIGOS
Os extratos de códigos de uma aplicação servem para que se tenha uma pré-visualização de como
estão sendo escritos os códigos que compõe a aplicação ou sistema (Pressman, 2014)
(SOMMERVILLE, 2007).
Figura 19 Extrato de Códico
36
CONCLUSÃO
Concluímos que o desenvolvimento do sistema de gestão de pacientes para o Hospital Josina Machel
representa um marco significativo para a melhoria dos processos internos e da qualidade no
atendimento aos pacientes. Este sistema foi projetado para oferecer soluções eficazes, como o
gerenciamento de prontuários, agendamento de consultas, controle de fluxo de pacientes e suporte
à equipe médica.
Com foco na modernização tecnológica e no alinhamento às necessidades específicas do hospital, o
projecto reflete o compromisso com a eficiência operacional e a transformação digital no setor da
saúde. Além disso, o sistema visa assegurar a segurança dos dados, a acessibilidade e a integração
entre os departamentos, promovendo uma gestão mais transparente e ágil.
A implementação desse sistema não apenas otimiza as rotinas hospitalares, mas também eleva a
experiência do paciente, criando um ambiente mais organizado e centrado no cuidado humanizado.
Com isso, o Hospital Josina Machel fortalece sua posição como referência em saúde, inovando na
prestação de serviços e consolidando sua missão de salvar vidas com excelência.
37
GLOSSÁRIO
A
Assiduidade são Folhas de Estilo em Cascata, responsáveis pelo estilo e aparência das páginas web.
C
CSS são Folhas de Estilo em Cascata, responsáveis pelo estilo e aparência das páginas web.
D
[Link] é uma ferramenta online gratuita para criação de diagramas e fluxogramas. Ele oferece
uma interface intuitiva de arrastar e soltar, permitindo que os usuários desenhem uma variedade de
diagramas, como organogramas, diagramas de rede, fluxogramas, entre outros. O [Link] é uma
solução popular para criar visualizações visuais de processos e estruturas, e os diagramas criados
podem ser exportados para vários formatos, incluindo imagens e documentos.
D
DIAGRAMA é um desenho simplificado mostrando a aparência, estrutura ou funcionamento de
algo, ou seja, uma representação esquemática.
H
HTML é uma Linguagem de Marcação de Hipertexto, usada na construção de páginas web.
I
IMPLEMENTAÇÃO refere-se ao processo de transformar um conceito, plano ou projeto em
realidade por meio da execução de ações e atividades específicas. É a etapa em que as ideias e os
requisitos são colocados em prática, convertendo-se em um produto, sistema, serviço ou solução
funcional.
J
JAVASCRIPT é uma linguagem de programação utilizada para criar interatividade em páginas
web.
P
PHP é uma linguagem de script de servidor amplamente usada para desenvolvimento web. Ela é
especialmente adequada para criar páginas web dinâmica e interativas.
R
REQUISITOS no contexto do desenvolvimento softwares ou de projetos em geral, são as
especificações ou características necessárias para atingir um determinado objetivo ou entregar um
produto ou serviço.
S
STARUML é uma ferramenta de modelagem UML (Unified Modeling
Language) para design de software.
38
V
VISUAL STUDIO CODE é um editor de código-fonte leve e poderoso desenvolvido pela
Microsoft. Ele é gratuito, de código aberto e suporta diversas linguagens de programação.
VIABILIDADE entende-se como estudo que procura prever, anteceder o eventual êxito ou o
fracasso de um projeto, por tanto de acordo com a realidade do projeto e um estudo feito a nível do
mercado apresentamos uma solução simples e de custos relativamente baixos, tendo em conta os
grandes benefícios que a empresa terá buscando serviço de qualidade e eficiência.
X
XAMPP é um pacote de software que inclui Apache,
M
MySQL é um sistem de gerenciamento de banco de dados relacionais.
39
REFERÊNCIAS BIBLIOGRÁFICAS
BOOCH, G., RUMBAUGH, J., & JACOBSON, I. ( 2000). UML, Guia do Usuário. Rio de Janeiro:
Campus.
[Link]. (s.d.). [Link] Documentation. Fonte: [Link]: [Link] Flanagan,
D. (2020). JavaScript: Guia Definitivo. Sebastopol: O'Reilly Media.
Gamarra, F. D. (2023). Visual Studio Code. Madri: RA-MA,S.A. Editoral Y Publicaciones.
Henderson, J. (2013). Understanding Xampp, For Newbies. North Charleston: CreateSpace
Independent Publishing Platform.
Hennessy, D. A. (2000). Organização e Projeto de Computadores. Rio de Janeiro: LTC.
Hernandez, M. J. (2013). Database Design for Mere Mortals. Boston: Addison-Wesley.
Kruchten, P. (2003). Introdução ao RUP – Rational Unified Process. Rio de Janeiro: Ciência
Moderna LDA.
Machado, F. N. (2010). Banco de Dados-Projeto e Impletação. São Paulo: Novatec.
MARTINS, J. C. (2007). Técnica para Gerenciamento de Projetos de Software. Rio de Janeiro:
Brasport.
Mileto, E. M. (2015). Desenvolvimento de Software ||: INtrodução ao Desenvolvimento Web com
HTML, CSS, JavaScript e PHP. São Paulo: Érica.
Pressman, R. S. (2014). Software Engineering: A practitioner's Approach. Nova Iorque,EUA:
McGraw-Hill Education.
SOMMERVILLE, I. (2007). Engenharia de Software. São Paulo: Pearson Addison-Wesley.
Stallings, W. (2017). Arquitetura e Organização de Computadores. São Paulo: person.
StarUML. (2024). StarUML documentation. Fonte: StarUML : [Link]
40
ANEXOS
Figura 20 Anexo
41
ÍNDICE REMISSIVO
A
AGRADECIMENTOS, iv
C
Controle de Assiduidade, x CSS, x, 30
D
DEDICATÓRIA, iii
Diagrama, 25
Diagrama de classes, 26 [Link], 32
E
ESTRUTURA DE MENU, 27
H
HTML, x, 30, 36
I
INTERFACE GRÁFICA, 27 interface, 27, 32, 36
J
JUSTIFICATIVA, 12
JavaScript, x, 30
M
METODOLOGIA APLICACIONAL, 20
P
PROCESSO DE FUNÇÕES, 21
PHP, 31
R
Requisitos, 21, 23, 24
S
SQL, 31
StarUML, 32
V
Visual Studio Code, 31
X
XAMPP, 31, 37
42
ÍNDICE GERAL
DEDICATÓRIA ..............................................................................................................................................
i
AGRADECIMENTOS ...................................................................................................................................ii
ÍNDICE DE FIGURAS ................................................................................................................................ iii
SIGLAS E ABREVIATURAS ....................................................................................................................... v
SUMÁRIO ..................................................................................................................................................... vi
JUSTIFICATIVA ....................................................................................................................10
OBJETIVOS ................................................................................................................................................. 11
OBJETIVOS GERAIS ............................................................................................................11
Objectivos especificos ..............................................................................................................11
METODOLOGIA UTILIZADA .................................................................................................................. 12
ESTRUTURA DO RELATÓRIO ................................................................................................................ 13
CAPITULO 1 DOMÍNIO DO PROBLEMA ............................................................................................... 14
1.1. OBJETO DE ESTUDO ....................................................................................................14
1.2. ÂMBITO DO PROJECTO..............................................................................................14
1.3. OBJETIVO DA INSTITUIÇÃO .....................................................................................14
1.4. UTILIZADORES (POTENCIAIS) .................................................................................14
1.5 ÁREAS DE AUTOMATIZAÇÃO (PROCEDIMENTO MANUAL) ...........................14
SITUAÇÃO ATUAL ...............................................................................................................15
1.7. PROBLEMAS A SEREM RESOLVIDOS ....................................................................15
1.8. SOLUÇÃO PROPOSTA..................................................................................................15
1.9. MATERIAIS NECESSÁRIOS, ESTIMATIVA DO CUSTO E APOIOS ..................15
Tabela 1 Materiais Necessários .................................................................................................................... 16
1.10. VIABILIDADE DO PROJECTO .................................................................................17
CAPITULO 2 ANÁLISE DE REQUISITOS ............................................................................................... 18
2.1. METODOLOGIA APLICACIONAL ............................................................................18
2.2 TIPOS DE APLICAÇÃO .................................................................................................18
2.3 UTILIZADORES DO SISTEMA ....................................................................................18
[Link] DE FUNÇÕES (BASEADO NA METODOLOGIA DO PONTO 2.1) ..19
2.4.1. ESPECIFICAÇÃO DOS PROCESSOS/ FUNÇÕES DO SISTEMA (PONTO
2.1).............................................................................................................................................20
1. Gestão de Projectos: ..................................................................................................................... 20
2. Modelagem de Negócios: ............................................................................................................. 20
3. Requisitos: .................................................................................................................................... 20
4. Análise e Design: ......................................................................................................................... 20
5. Implementação: ............................................................................................................................ 20
6. Testes: .......................................................................................................................................... 21
7. Implantação: ................................................................................................................................. 21
2.4.2. REQUISITOS FUNCIONAIS ......................................................................................21
TABELA 2 REQUISITOS FUNCIONAIS .................................................................................................. 22
2.4.3. REQUISITOS NÃO FUNCIONAIS ............................................................................23
Tabela 3 Requisitos Não Funcionais ............................................................................................................ 23
2.4.4. DIAGRAMA (BASEADO NA METODOLOGIA DO PONTO (2.1) ......................24
1. DIAGRAMA DE CASO DE USO ....................................................................................24
2. ESPECIFICAÇÕES ...........................................................................................................24
3. DIAGRAMA DE CLASSE ................................................................................................25
CAPITULO 3 DESENHO ............................................................................................................................ 26
3.1. ESTRUTURA DE MENU ...............................................................................................26
3.2. ESTRUTURA DE INTERFACE GRÁFICA COM O UTILIZADOR .......................26
3.2.1 PÁGINA DE LOGIN .....................................................................................................27
3.3. MODELO LÓGICO DE DADOS ...................................................................................28
3.4. A ARQUITETURA LÓGICA DE APLICACÃO .........................................................29
CAPITULO 4 TECNOLOGIAS E FERRAMENTAS UTILIZADAS ........................................................ 30
4.1. TECNOLOGIAS UTILIZADAS (CONCEITOS\ DEFINIÇÕES) ..............................30
4.2 FERRAMENTAS UTILIZADAS (CONCEITOS/DEFINIÇÕES)...............................32
CAPITULO 5 IMPLEMENTAÇÃO ............................................................................................................ 34
5.1. ARQUITETURA FÍSICA DO SISTEMA......................................................................34
5.2. MODELO FÍSICO DE DADOS......................................................................................35
5.3. EXTRATOS DE CÓDIGOS ............................................................................................36
CONCLUSÃO .............................................................................................................................................. 37
GLOSSÁRIO ................................................................................................................................................ 38
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................................................... 40
ANEXOS ...................................................................................................................................................... 41
vii