10 · web viewelaborar telas simples, seguindo os padrões de design e usabilidade, identificando...

Índice2. Prefácio.......................................................................................................................................................10

3. Principais Documentos relativos ao Levantamento de Dados do Sistema...................11

3.1 – Documento de Requisitos do Sistema.....................................................................................15

4. Descrição Textual do Sistema...........................................................................................................18

Objetivos do projeto...................................................................................................................................24

- Contexto do Negócio...............................................................................................................................24

- Objetivos.......................................................................................................................................................24

- Funções Principais...................................................................................................................................25

- Questões de Desempenho.....................................................................................................................25

- Restrições Técnicas e Administrativas...........................................................................................26

6. Estudo de Viabilidade Financeira....................................................................................................28

6.1 - Previsão Financeira..........................................................................................................................28

6.2 – Investimentos em Infra – estrutura.........................................................................................28

6.3 – Investimento em desenvolvimento..........................................................................................31

6.4 – Custos Totais......................................................................................................................................31

6.5 – Benefícios.............................................................................................................................................32

7. Riscos do Projeto...................................................................................................................................33

7.1 – Conhecimento limitado sobre todo o processo de controle de uma.........................33

7.1.1 – Magnitude........................................................................................................................................33

7.1.2 – Descrição..........................................................................................................................................33

7.1.3 – Impacto.............................................................................................................................................33

7.1.4 – Indicadores......................................................................................................................................33

7.1.5 – Estratégia de Mitigação..............................................................................................................33

7.1.6 – Plano de contingência.................................................................................................................34

7.2 – Prazos não cumpridos....................................................................................................................35

7.2.1 – Magnitude........................................................................................................................................35

7.2.2 – Descrição..........................................................................................................................................35

7.2.3 – Impacto.............................................................................................................................................35

7.2.4 – Indicadores......................................................................................................................................35

2



7.3 – Os equipamentos necessários não serem adquiridos pela Unidade..........................36

7.3.1 – Magnitude........................................................................................................................................36

7.3.2 – Descrição..........................................................................................................................................36

7.3.3 – Impacto.............................................................................................................................................36

7.3.4 – Indicadores......................................................................................................................................36



7.4 – Perda de um componente da equipe.......................................................................................38

7.4.1 – Magnitude........................................................................................................................................38

7.4.2 – Descrição..........................................................................................................................................38

7.4.3 – Impacto.............................................................................................................................................38

7.4.4 – Indicadores......................................................................................................................................38



7.5 – Surgimento de novos requisitos ou alterações nos requisitos já................................40

7.5.1 – Magnitude........................................................................................................................................40

7.5.2 – Descrição..........................................................................................................................................40

7.5.3 – Impacto.............................................................................................................................................40

7.5.4 – Indicadores......................................................................................................................................40



7.6 – Interface do sistema não possuir uma correta usabilidade...........................................42

7.6.1 – Magnitude........................................................................................................................................42

7.6.2 – Descrição..........................................................................................................................................42

7.6.3 – Impacto.............................................................................................................................................42

7.6.4 – Indicadores......................................................................................................................................42



3

7.7 – Desempenho Funcional do Sistema.........................................................................................43

7.7.1 – Magnitude........................................................................................................................................43

7.7.2 – Descrição do Risco.......................................................................................................................43

7.7.3 – Impactos...........................................................................................................................................43

7.7.4 – Indicadores......................................................................................................................................43


7.7.6 – Plano de Contingência................................................................................................................44

7.8 – Rompimento do Contrato por parte do Usuário.................................................................45

7.8.1 – Magnitude........................................................................................................................................45

7.8.2 – Descrição do Risco.......................................................................................................................45

7.8.3 – Impactos...........................................................................................................................................45

7.8.4 – Indicadores......................................................................................................................................45


7.8.6 – Plano de Contingência................................................................................................................46

8. Plano de Projeto......................................................................................................................................47

8.1 – Divisão de Tempo e Esforço........................................................................................................47

9. Glossário.....................................................................................................................................................51

10. Atributos dos Requisitos..................................................................................................................52

10.1 Atributos...............................................................................................................................................52

10.1.1 – Complexidade..............................................................................................................................52

10.1.2 - Estabilidade...................................................................................................................................52

10.1.3 – Prioridade.....................................................................................................................................53

– Custo..............................................................................................................................................................53

– Risco.............................................................................................................................................................. 54

10.2 - Matriz de Atributos dos Requisitos........................................................................................55

11 – Documentos de Requisitos............................................................................................................56

11.1 – Diagrama de Casos de Uso.........................................................................................................56

11.1.1 – Diagrama de Casos de Uso (Representação do Super Ator.....................................57

11.2 – Descrição do Caso de Uso Efetuar Login.............................................................................58

11.2.1 – Cenários do Caso de Uso Efetuar Login............................................................................60

4

11.2.2 - Diagrama de Atividades – Efetuar Login..........................................................................61

11.2.3 – Diagrama de Seqüência do Caso de Uso Efetuar Login.............................................62

11.2.4 – Diagrama de Classes – tela_login........................................................................................63

11.2.5 – Diagrama de Estado – tela_login.........................................................................................64

11.3 – Descrição do Caso de Uso Cadastrar Funcionário...........................................................65

11.3.1 – Cenário do Caso de Uso Cadastrar Funcionário..........................................................67

11.3.2 – Diagrama de Atividades do Caso de Uso Cadastrar Funcionário..........................69

11.3.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Funcionário...........................70

11.3.4 – Diagrama de Classes - tela_cadastro_funcionario........................................................71

11.3.5 – Diagrama de Estados – tela_cadastro_funcionario (incluir)...................................72

11.3.6 – Diagrama de Estados – tela_cadastro_funcionario (excluir)...................................73

11.3.7 – Diagrama de Estados – tela_cadastro_funcionario (editar)....................................74

11.4 – Descrição do Caso de Uso Solicitar Consulta.....................................................................75

11.4.1 – Descrição do Cenário do Caso de Uso Solicitar Consulta.........................................77

11.4.2 – Diagrama de Atividades do Caso de Uso Solicitar Consulta....................................80

11.4.3. – Diagrama de Seqüência do Caso de Uso Solicitar Consulta....................................81

11.4.4. – Diagrama de Classes – tela_atendimento_balcao........................................................82

11.4.5. – Diagrama de Estado – tela_atendimento_balcao (incluir)......................................83

11.4.6. – Diagrama de Estado – tela_atendimento_balcao (editar).......................................84

11.4.7. – Diagrama de Estado – tela_atendimento_balcao (excluir)......................................85

11.5 – Descrição do Caso de Uso Realizar Pré-Consulta............................................................86

11.5.1 – Descrição do Cenário do Caso de Uso Pré-Consulta...................................................88

11.5.2 – Diagrama de Atividades do Caso de Uso Pré-Consulta.............................................90

11.5.3 – Diagrama de Seqüência do Caso de Uso Pré-Consulta..............................................91

11.5.4 – Diagrama de Classes – tela_pre_consulta........................................................................92

11.5.5 – Diagrama de Estado – tela_pre_consulta (incluir).......................................................93

11.5.6 – Diagrama de Estado – tela_pre_consulta (editar)........................................................94

11.5.7 – Diagrama de Estado – tela_pre_consulta (excluir)......................................................95

11.6 – Descrição do Caso de Uso Realizar Consulta Médica.....................................................96

11.6.1 – Descrição do Cenário do Caso de Uso Realizar Consulta Médica..........................98

5

11.6.2 – Diagrama de Atividades do Caso de Uso Realizar Consulta Médica.................100

11.6.3 – Diagrama de Seqüência do Caso de Uso Realizar Consulta Médica..................101

11.6.4 – Diagrama de Classes – tela_consulta..............................................................................102

11.6.5 – Diagrama de Estado – tela_consulta (incluir).............................................................103

11.6.6 – Diagrama de Estado – tela_consulta (editar)..............................................................103

11.6.6 – Diagrama de Estado – tela_consulta (editar)..............................................................104

11.6.7 – Diagrama de Estado – tela_consulta (excluir)............................................................105

11.7 – Descrição do Caso de Uso Emitir Pedido de Exames..................................................106

11.7.1 – Descrição do Cenário do Caso de Uso Emitir Pedido de Exames.......................108

11.7. 2 – Diagrama de Atividades para o Caso de Uso Emitir Pedido de..........................110

11.7.3 – Diagrama de Seqüência para o Caso de Uso Emitir Pedido de Exames...........111

11.7.4 – Diagrama de Classes - exames...........................................................................................112

11.7.5 – Diagrama de Estado – tela_exames(incluir)................................................................113

11.7.5 – Diagrama de Estado – tela_exames(editar).................................................................114

11.7.7 – Diagrama de Estado – tela_exames (excluir)..............................................................115

11.8 – Descrição do Caso de Uso Atendimento Ambulatorial...............................................116

11.8.1 – Descrição do cenário do Caso de Uso Atendimento Ambulatorial....................118

11.8.2 – Diagrama de Atividade do Caso de Uso Atendimento Ambulatorial................119

11.8.3 – Diagrama de Seqüência do Caso de Uso Atendimento Ambulatorial...............120

11.8.4 – Diagrama de Classes – tela_atendimento_ambulatorial.........................................121

11.8.5 – Diagrama de Estado – tela_atendimento_ambulatorial (incluir).......................122

11.8.6 – Diagrama de Estado – tela_atendimento_ambulatorial (editar)........................123

11.9 – Descrição do Caso de Uso Controlar Medicamento.....................................................124

11.9.1 - Descrição do Cenário do Caso de Uso Controlar Medica-mento........................126

11.9.2 – Diagrama de Atividade para o Caso de Uso Controlar Medicamento..............127

11.9.3 – Diagrama de Seqüência do Caso de Uso Controlar Medicamento.....................128

11.9.4 – Diagrama de Classes – medicamento.............................................................................129

11.9.5 – Diagrama de Estado – tela_controla_medicamento (incluir)...............................130

11.9.6 – Diagrama de Estado – tela_controla_medicamento (estornar)...........................131

11.10 – Descrição do Caso de Uso Atribuir Nível de Acesso..................................................132

6

11.10.1 – Descrição do Cenário do Caso de Uso Atribuir Nível de Acesso......................134

11.10.2 – Diagrama de Atividade do Caso de Uso Atribuir Nível de Acesso...................135

11.10.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Nível de Acesso..............136

11.10.4 – Diagrama de Classes – tela_controle_acesso............................................................136

11.10.4 – Diagrama de Classes – tela_controle_acesso............................................................137

11.10.5 – Diagrama de Estado – tela_controle_acesso (incluir)...........................................138

11.10.6 – Diagrama de Estado – tela_controle_acesso (editar)............................................139

11.10.7 – Diagrama de Estado – tela_controle_acesso (inativar)........................................140

11.11 – Descrição do Caso de Uso Cadastrar Usuários............................................................141

11.11.1 – Descrição do Cenário do Caso de Uso Cadastrar Usuários.................................143

11.11.2 – Diagrama de Atividade do Caso de Uso Cadastrar Usuários.............................145

11.11.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Usuários............................146

11.11.4 – Diagrama de Classes – tela_cadastro_usuario..........................................................146

11.11.4 – Diagrama de Classes – tela_cadastro_usuario..........................................................147

11.11.5 – Diagrama de Estado – tela_cadastro_usuário (incluir)........................................148

11.11.6 – Diagrama de Estado – tela_cadastro_usuário (editar).........................................149

11.11.7 – Diagrama de Estado – tela_cadastro_usuario (inativar).....................................150

11.12 – Descrição do Caso de Uso Emitir Relatórios................................................................151

11.12.1 – Relatório de Atendimento................................................................................................154

11.12.2– Relatório de Exames Solicitados.....................................................................................155

.......................................................................................................................................................................... 155

11.12.3 – Relatório de Solicitações de Consulta..........................................................................156

11.12.4 – Relatório de Listagem de Medicamentos...................................................................157

11.12.5 – Relatório de Listagem de Categorias...........................................................................158

11.12.6 – Descrição do Cenário do Caso de Uso Emitir Relatórios.....................................159

11.12.7 – Diagrama de Atividade para o Caso de Uso Emitir Relatórios.........................160

11.12.8 – Diagrama de Seqüência para o Caso de Uso Emitir Relatório..........................161

11.12.9 – Diagrama de Classes – tela_relatorios.........................................................................162

11.12.10 – Diagrama de Estado – tela_relatorios.......................................................................163

11.13 – Descrição do Caso de Uso Cadastrar Medicamentos................................................164

7

11.13.1 – Descrição do Cenário do Caso de Uso Cadastrar Medicamentos.....................167

11.13.2 – Diagrama de Atividades do Caso de Uso Cadastrar Medicamentos...............169

11.13.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Medicamentos................170

11.13.4 – Diagrama de Classes – tela_cadastra_medicamento.............................................171

11.13.5 – Diagrama de Estado – tela_cadastra_medicamento (incluir)............................172

11.13.6 – Diagrama de Estado – tela_cadastra_medicamento (editar).............................173

11.13.6 – Diagrama de Estado – tela_cadastra_medicamento (excluir)...........................174

11.14 – Descrição do Caso de Uso Cadastrar Exames..............................................................175

11.14.1 – Descrição do Cenário do Caso de Uso Cadastrar Exames...................................177

11.14.2 – Diagrama de Atividades do Caso de Uso Cadastrar Exames.............................179

11.14.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Exames..............................180

11.14.4 – Diagrama de Classes – tela_cadastro_exames..........................................................181

11.14.5 – Diagrama de Estado – tela_cadastro_exames (incluir)........................................182

11.14.6 – Diagrama de Estado – tela_cadastro_exames (editar).........................................183

11.14.7 – Diagrama de Estado – tela_cadastro_exames (excluir)........................................184

11.15 – Descrição do Caso de Uso Cadastrar Tipos de Medica-mentos...........................184

11.15 – Descrição do Caso de Uso Cadastrar Tipos de Medica-mentos...........................185

11.15.1 – Descrição do Cenário do Caso de Uso Cadastrar Tipos de Medicamentos..187

11.15.2 – Diagrama de Atividades do Caso de Uso Cadastrar Tipos de Medicamentos........................................................................................................................................................................... 189

11.15.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Tipos de Medicamentos........................................................................................................................................................................... 189

11.15.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Tipos de Medicamentos........................................................................................................................................................................... 190

11.15.4 – Diagrama de Classes – tela_cadastro_tipo_medicamento...................................191

11.15.5 – Diagrama de Estados – tela_cadastro_tipo_medicamento (incluir)...............192

11.15.6 – Diagrama de Estados – tela_cadastro_tipo_medicamento (editar)................193

11.15.7 – Diagrama de Estados – tela_cadastro_tipo_medicamento (excluir)...............194

11.16 – Diagrama de Classes – SGBD...............................................................................................195

12 – Modelo de Dados............................................................................................................................196

12.1 – Diagrama Entidade Relacionamento (DER)....................................................................196

8

12.2 – Modelo Entidade Relacionamento (MER)........................................................................196

12.2 – Modelo Entidade Relacionamento (MER)........................................................................197

12.2.1 – Considerações sobre o MER...............................................................................................198

12.2 – Modelo Físico dos Dados.........................................................................................................199

13. Diagrama de Componentes...........................................................................................................200

14. Diagrama de Implementação.......................................................................................................201

15. Projeto de Testes...............................................................................................................................202

16 – Anexos.................................................................................................................................................216

16.1 – Formulário de Encaminhamento (Anexo I)....................................................................216

16.2 – Formulário de Pedido de Exames (Anexo II)..................................................................217

16.3 – Termo de Sigilo Profissional (Anexo III)..........................................................................218

9

2. Prefácio

O projeto a ser desenvolvido como Trabalho de Conclusão de Curso I e II será

um sistema que será implementado na Unidade Mista de Saúde do Município

de Rafard.

Esta Unidade atende de uma forma geral toda a população do município,

localizado no interior de São Paulo, com cerca de 9.000 habitantes.

A escolha por esse projeto partiu de uma necessidade levantada junto a

Unidade Mista de Saúde, que vinha passando por problemas no controle dos

medicamentos e também das consultas.

O presente sistema será desenvolvido por dois grupos. Devido ao tamanho do

sistema e ao tempo disponível para a realização do trabalho, a melhor solução

encontrada foi a de dividir o desenvolvimento deste em dois grupos. Ao final do

projeto, os sistemas serão integrados.

Sendo assim, esperamos com esse projeto poder contribuir com uma melhora

na qualidade dos serviços prestados, assim como com a melhoria no controle

dos medicamentos e na utilização dos serviços de saúde de uma forma geral.

Além disso, também esperamos colocar em prática tudo aquilo que vimos

durante o curso, aprimorando nossos conhecimentos com a aplicação do

trabalho prático.

10

3. Principais Documentos relativos ao Levantamento de Dados do Sistema

Entrevista

A reunião abaixo descrita foi realizada com a sra. Luciana – Coordenadora de

Saúde do Município, com a sra. Maria do Socorro – Coordenadora

Administrativa da Unidade de Saúde e também participaram os alunos: André

Luís, Leandro, Cristiane e Márcia.

Ata de reunião – 01-03-07

Cadastro de pacientes – Atualmente o cadastro é realizado da seguinte

forma: o paciente procura pelo funcionário responsável pelo cadastro, que fica

no prédio da prefeitura, com cópia de documentos, comprovante de residência

e essa pessoa realiza um cadastro e emite a carteirinha do SUS. De posse

dessa carteirinha, o paciente vai até o hospital onde é realizado outro cadastro

no sistema local (somente cadastro e emissão de folha para consulta).

Para a emissão dessa carteirinha do SUS, o paciente deve levar a carteirinha

antiga utilizada pela unidade de saúde. Nessa nova carteira, consta ainda o

número da antiga, além de outra seqüência numérica para a nova carteirinha.

O objetivo dessa nova reunião é verificar a possibilidade de unificar esse

processo, realizando um único cadastro.

Emissão de carteirinhas pelo sistema: Nesse ponto, houve interesse total

por esse procedimento. A carteirinha é impressa em papel cartão e

posteriormente plastificada.

11

Listagem de exames pré-cadastrados no sistema, para auxilio do médico:

nesse ponto, também houve interesse, contudo, a tabela utilizada não é a

tabela AMB e sim, a tabela SUS.

Novos exames que não estejam na tabela SUS podem ser solicitados, contudo,

esse procedimento não é rotina, pois, segundo as informações obtidas, a

tabela do SUS é mais abrangente que a tabela AMB.

Para fins de esclarecimento, a tabela AMB é a tabela que contém todos os

procedimentos médicos reconhecidos pela Associação Médica Brasileira e que

serve de parâmetro para a maioria dos planos de saúde hoje existentes.

Quanto aos remédios, a distribuição desses é realizada somente aos

munícipes, com a apresentação da carteirinha do SUS e mediante a prescrição

através de receita médica.

Quanto ao controle de estoque desses medicamentos, algumas

particularidades: existem remédios de administração hospitalar, que ficam

armazenados numa sala denominada “Sala de Medicamentos”. Esses

medicamentos são fornecidos pela farmácia, contudo, não são medicamentos

distribuídos também à população em geral e sim, somente para administração

no próprio hospital.

Além disso, existe também o atendimento de urgência, que possui somente

medicamentos para utilização interna e durante a semana. Esses

medicamentos também são fornecidos pela farmácia. Durante os finais de

semana, alguns medicamentos são transferidos da farmácia para a sala de

atendimento com a finalidade de distribuição à população que será atendida

durante o final de semana.

Uma alternativa proposta para esses casos seria a seguinte:

No caso da sala de medicamentos, estes sairiam da farmácia, apenas

transferindo-se o local do estoque e a baixa definitiva desses medicamentos

seria feita pela enfermeira chefe do turno, ao término deste.

12

O mesmo procedimento seria adotado pela sala de urgência em relação aos

medicamentos utilizados durante a semana.

Durante os finais de semana, em relação aos medicamentos distribuídos,

poderia ser adotada a política de se transferir também o estoque dos

medicamentos para a sala de urgência, sem, contudo, baixá-lo do estoque. A

baixa definitiva seria realizada da mesma forma, pela enfermeira responsável

pelo plantão, ao término deste. Na segunda-feira, os remédios não distribuídos

seriam novamente transferidos para a farmácia, sem alteração alguma no

estoque geral.

A questão levantada quanto a leitura dos remédios através do código de barras

ficou presa a questão de que os frascos de medicamentos não possuem

códigos e sim, somente as caixas fechadas. Uma possibilidade levantada foi a

emissão pelo próprio sistema de um código de barras para cada medicamento,

ou então, a transferência através da digitação mesmo.

No que se refere às informações que precisam ficar disponíveis a cada funcionário, o que nos foi solicitado é que todos os profissionais de saúde

(médicos, psicólogos, terapeutas, enfermeiras chefes) devem ter acesso total

aos dados clínicos do paciente. Já os demais, somente aos dados relativos a

cada setor, por exemplo, na farmácia, somente o nome do paciente e o

medicamento prescrito e assim para todos os demais setores.

Durante uma consulta, por exemplo, seria aconselhável deixar disponível ao

médico dados relativos a possíveis problemas crônicos como, por exemplo,

históricos de hipertensão, doenças genéticas, etc.

Plano de contingência: a unidade de saúde possui um gerador que mantém

todo o hospital em caso de interrupção de energia, sendo assim, a hipótese do

sistema sofrer paradas com a falta de energia, podendo ocasionar problemas

aos usuários está descartada. Foi também discutido a importância de se

manter uma máquina para ser o servidor do sistema, de forma isolada, com

todas as políticas de acesso e planos de back-up que serão explorados mais a

fundo no momento oportuno. Fomos informados de que boa parte dos

13

equipamentos já está disponível e o que for necessário será providenciado em

tempo. Também a passagem dos cabos de rede já está sendo providenciada.

Em relação ao número médio de atendimento aos pacientes, fomos

informados de que o fluxo diário é de em média 200 pessoas, entre todas as

especialidades e consultas ao clínico geral.

Outros pontos da reunião: Há a necessidade que o sistema também seja

implantado no consultório de atendimento psicológico, assim como todas as

demais especialidades do local. Foi solicitada uma entrevista com um dos

psicólogos para se levantar as suas necessidades, tendo em vista que não

houve uma certeza de que existe, por parte destes, um controle adicional ao

controle do histórico clínico geral do paciente (que são utilizados pelos médicos

e demais profissionais).

Também foi solicitado o agendamento do atendimento de fisioterapia. O

atendimento nessa especialidade também é fornecido dentro da própria

Unidade Mista de Saúde, porém, esse atendimento só poderá ser realizado

mediante um encaminhamento médico. Desta forma, nenhum paciente pode

chegar ao balcão e pedir por um tratamento. Somente se constatada a

necessidade através de um dos médicos da Unidade é que este tratamento

poderá ser iniciado.

O que nos foi pedido é um controle do agendamento do atendimento após o

paciente ser encaminhado. As anotações clínicas do atendimento fisioterápico

são realizadas na mesma ficha clínica do paciente, não havendo a necessidade

de um controle adicional.

Existem casos de consultas externas, realizadas na casa dos pacientes. Nesse

caso, um profissional é deslocado até o local e depois, ao retornar a unidade

de saúde, o próprio profissional que fez o atendimento é responsável por incluir

os dados daquele atendimento no sistema.

Acompanhar esse atendimento externo, através de um controle de quantos

pacientes existem nessa situação, manter uma agenda desses atendimentos,

pode também ser uma tarefa implantada pelo sistema.

14

3.1 – Documento de Requisitos do SistemaApós a entrevista acima descrita, foi elaborado um documento de requisitos

contendo a data do levantamento, o entrevistador, o entrevistado e a descrição

da funcionalidade.

Data: 01/03/07

Entrevistador: Leandro e André

Entrevistada: Maria do Socorro

Descrição da Funcionalidade: O sistema deverá manter um cadastro de todos

os pacientes e funcionários da Unidade Mista de Saúde. Para o cadastramento

dos pacientes deverão ser respeitadas algumas restrições, como por exemplo,

o paciente residir no município de Rafard e também votar no próprio município.

Data 01/03/07



Descrição da Funcionalidade: O sistema deverá controlar o estoque de

medicamentos da Unidade. As saídas desses medicamentos poderão ocorrer

por duas formas: A primeira é feita para a utilização dentro da própria unidade,

nas salas e atendimento ambulatorial e sala de medicamentos. A segunda

forma é através da distribuição direta ao público.

Essa distribuição ao público só pode ser feita mediante uma receita médica,

emitida na própria Unidade Mista de Saúde.

O problema atual é o fato de não haver um controle mais detalhado sobre o

estoque, possibilitando saídas indevidas dos medicamentos, fato esse que gera

um grande prejuízo aos cofres públicos.

15

Data 01/03/07



Descrição da Funcionalidade: O sistema também deverá controlar todo o

atendimento do paciente na Unidade. Esse controle se inicia quando o paciente

chega ao balcão de atendimento e solicita uma consulta. Após esse

procedimento, ele é encaminhado a pré-consulta, procedimento que consiste

na checagem da pressão arterial, temperatura e peso do paciente.

Realizado esses procedimentos iniciais, o paciente é então encaminhado à

consulta e desta, vários desdobramentos podem ocorrer, tais como: receita

médica, encaminhamentos, pedidos de exames e encaminhamento para

atendimento ambulatorial dentro da própria Unidade.

Data 01/03/07



Descrição da Funcionalidade: Emitir pedidos de exames também é uma

funcionalidade que o sistema deverá atender. Essa emissão está condicionada

a uma necessidade levantada pelo médico durante a realização da consulta.

Essa funcionalidade também servirá de base para a emissão de futuros

controles sobre os exames solicitados. Alguns dos exames são realizados em

laboratórios externos, havendo posteriormente a cobrança. Como também não

existe atualmente nenhum controle mais específico e confiável, problemas

também já ocorreram.

16

Data 01/03/07



Descrição da Funcionalidade: A emissão de relatórios também é mais uma das

funcionalidades. Alguns tipos de relatórios que o sistema deverá emitir:

relatórios de pacientes, de atendimentos, de medicamentos (entradas e

saídas), de exames e encaminhamentos.

17

4. Descrição Textual do Sistema

Sistema de Gerenciamento do Hospital Municipal de Rafard

Objetivos do Software

O objetivo do software é o de melhorar a qualidade do atendimento, além de

possibilitar, por parte da administração do hospital, ter um controle amplo de

todas as atividades desempenhadas no local.

O software atenderá todos os departamentos da Unidade, iniciando-se na

recepção, quando o paciente faz o pedido da consulta. Após isso, passará a

pré-consulta, que é basicamente a checagem de algumas informações que

auxiliarão o médico durante a consulta. Essas checagens são basicamente:

peso, temperatura e pressão arterial.

A consulta médica é o procedimento realizado após a pré-consulta. Nesse

ponto, o paciente é atendido pelo médico. Os possíveis desdobramentos de

uma consulta podem ser: o encaminhamento a alguma outra especialidade

médica, a solicitação de exames, o encaminhamento para um atendimento

ambulatorial, a prescrição de medicamentos. Todos esses procedimentos

serão contemplados pelo software, que acompanhará toda a passagem do

paciente pela unidade, mantendo sempre um histórico atualizado do seu

quadro clínico, controlando o estoque de medicamentos da Unidade de Saúde,

emitindo guias para exames ou encaminhamentos além de proporcionar

controles gerenciais, como por exemplo, o controle do tempo de atendimento,

relatórios de atendimento, dentre outros.

18

Descrição do Sistema

O Sistema de Gerenciamento do Hospital Municipal de Rafard atenderá as

seguintes áreas: atendimento (balcão recepção), atendimento pré-consulta,

consulta, atendimento ambulatorial, autorização de exames, retirada de

medicamentos na farmácia local e emissão de relatórios.

Abaixo descreveremos detalhadamente os critérios que o sistema deverá

atender nas áreas acima citadas.

Atendimento no balcão de recepção

Nesse local o paciente simplesmente terá seu pedido de consulta aberto. Será

solicitada a sua carteirinha, onde consta o seu número de matrícula e, com

base nisso, localizado o seu prontuário.

Feito isso, o paciente será encaminhado a sala de pré-consulta.

Atendimento Pré-Consulta

Nesse estágio do atendimento o paciente passa pela checagem de

temperatura, pressão arterial e peso, procedimentos esses realizados por uma

enfermeira. Esses dados são anotados no seu histórico e posteriormente,

encaminhados ao médico para que o atendimento em si seja realizado.

Atendimento Médico

Ao entrar no consultório, o médico já possui algumas informações do paciente,

coletadas na etapa anteriormente descrita.

Durante a consulta vários desdobramentos podem ocorrer, como por exemplo,

uma solicitação de exames clínicos, o atendimento ambulatorial, como por

exemplo, a aplicação de medicamentos no próprio hospital, ficando o paciente

em observação por algumas horas, a prescrição de medicamentos, que podem

19

ou não ser fornecidos pela própria Unidade de Saúde, o encaminhamento a

outro local, por exemplo, para um atendimento especializado ou mesmo uma

internação.

Na sessão de anexos (Anexo I, pág. 130), encontra-se o formulário atualmente

utilizado para esse fim.

Durante a realização da consulta, o médico anota no histórico clínico do

paciente o que foi relatado durante a consulta além dos procedimentos

descritos.

Para efeito de exemplificação, assumiremos que um paciente saiu da sala de

consulta com as seguintes recomendações: aplicação de uma medicação no

ambulatório, pedido de um exame de sangue e um raio-x e a prescrição de

alguns medicamentos, sendo que um deles, está disponível para distribuição

na farmácia do hospital.

Ao sair do consultório, os seguintes passos poderão ser realizados:

Atendimento Ambulatorial

Ao chegar ao ambulatório, a enfermeira responsável apenas consultará no

terminal disponível na sala, quais procedimentos serão ministrados naquele

paciente.

Essas informações serão repassadas ao ambulatório de forma automática,

assim que a consulta for realizada.

Atendimento na Farmácia

Como o paciente saiu com medicamentos prescritos, ele deverá ir até a

farmácia. Na farmácia, a farmacêutica responsável já terá igualmente

disponível em seu terminal os medicamentos prescritos para aquele paciente,

podendo realizar a entrega somente do que foi indicado pelo médico.

20

Ao realizar a entrega, automaticamente será gerada uma baixa naquele

medicamento, que poderá ser checado pela administração, com o fim de

conferir os estoques, sempre que necessário.

Emissão de Relatórios

Em princípio, os relatórios emitidos serão: relatórios de atendimento mensal,

com resumo de quantas consultas, relatórios de exames solicitados,

medicamentos mais utilizados e listagem cadastral de funcionários.

Particularidades que o Sistema deverá atender

O ambulatório da unidade também é abastecido pelos medicamentos da

farmácia, sendo assim, toda vez que o estoque do ambulatório for abastecido,

o medicamento será baixado do estoque geral e passará para o controle de

estoque do ambulatório, com a finalidade de se ter um acompanhamento

preciso da utilização dos medicamentos.

Todo o sistema deverá ter uma política de acessos restritos a determinadas

áreas e procedimentos, pois o sistema estará trabalhando com informações

sigilosas e, portanto, deverá prever que somente pessoas autorizadas tenham

acesso a estas informações. Por exemplo, o histórico clínico do paciente

deverá estar disponível somente aos profissionais da saúde.

O atendimento no balcão terá acesso apenas aos dados cadastrais do

paciente, como nome, endereço, etc.

A equipe de enfermagem, apenas aos procedimentos que deverão ser

realizados no ambulatório e a farmácia, somente aos medicamentos prescritos.

Funções que NÃO contemplaremos no sistema:

As funcionalidades abaixo descritas serão implementadas pelo outro grupo de

desenvolvimento, fazendo parte do segundo módulo do sistema.

21

Ao final do desenvolvimento desse projeto, os módulos serão integrados e com

isso, poderá atender a todas as funcionalidades solicitadas.

As funcionalidades não atendidas pelo nosso módulo são:

1. Acompanhamento dos exames e posteriores controles e relatórios

gerados por esse processo.

2. Escala de plantões e férias de médicos e equipe de enfermagem

3. Agendamento de consultas de especialidades que são realizadas na

própria unidade

4. Agendamento de atendimento odontológico, também existente na

unidade.

Sigilo das Informações

O sistema para a UMS de Rafard, trabalhará com informações sigilosas, que

em hipótese alguma podem ser divulgadas ou ficar expostas a pessoas não

autorizadas. Dentro do sistema, visando resolver esse problema, foram

adotados níveis de acesso, que serão definidos pelas coordenadoras da

unidade a cada usuário do sistema.

Por outro lado, as informações também serão vistas pela equipe de

desenvolvedores, que poderão ter acesso a todo o conteúdo armazenado no

banco de dados. Visando garantir a total privacidade e sigilo as informações foi

elaborado um termo de responsabilidade (ver anexo III, pág 132 e 133). Nesse

termo os desenvolvedores se comprometem, perante a direção da UMS, a não

divulgar qualquer tipo de informação obtida com o desenvolvimento do sistema

sob pena de sofrer sanções legais caso esse compromisso seja rompido.

22

Plano de contingência

A UMS oferece atendimento ininterruptamente, sendo assim, houve a

necessidade de se ter um plano de contingência caso algum equipamento

viesse a sofrer algum tipo de dano, impedindo seu correto funcionamento.

A hipótese mais viável levantada foi a de possuir pelo menos duas máquinas

que serviriam de reserva e seriam colocadas em uso, caso houvesse algum

problema com as máquinas normalmente utilizadas. Essas máquinas já se

encontram na UMS e portanto não serão contabilizadas no custo final do

projeto. São máquinas que atualmente são utilizadas e serão substituídas por

equipamentos novos.

Rotinas de back-up

Toda a rotina de back-up será programada para ser realizada de forma

automática, através do servidor. Devido ao alto número de informações

digitadas durante o dia, a proposta é realizar o back-up duas vezes ao dia,

sendo uma delas às 6:00 horas a manhã e a outra, às 18:00 horas.

As coordenadoras já foram orientadas sobre a necessidade de providenciar um

local seguro para armazenar os back-ups, inclusive fora do prédio da UMS. As

cópias de segurança serão feitas em mídias digitais (CDs ou DVDs).

23

Objetivos do projeto

- Contexto do Negócio

O presente projeto constitui-se no desenvolvimento de um sistema para a

Unidade Mista de Saúde do Município de Rafard.

A Unidade Mista de Saúde, mantida pela prefeitura de Rafard, é um posto de

atendimento médico a população do município, que funciona de forma

ininterrupta, vinte e quatro horas por dia, sete dias por semana.

Diversos tipos de atendimentos são oferecidos na UMS, como por exemplo, o

atendimento de plantão, ou seja, a pessoa será atendida pelo médico que

estiver de plantão naquele dia, o atendimento de urgência / emergência, o

atendimento com especialistas, ou seja, aquele em que o paciente é

encaminhado pelo médico plantonista, dependendo do seu tipo de problema.

Na UMS existem os seguintes atendimentos de especialidades: ginecologia,

cardiologia, atendimento psicológico e dentário.

Além do atendimento, a UMS também possui a distribuição de medicamentos

as pessoas residentes no município de Rafard, de forma gratuita. Essa

distribuição somente é realizada para pessoas que possuam o cadastro

atualizado da prefeitura.

- Objetivos

● Melhorar o controle e distribuição de medicamento na Unidade Mista de

Saúde de Rafard.

● Agilizar o atendimento aos pacientes.

● Permitir melhor gerenciamento e segurança das informações.

24

● Melhor administração do dinheiro público dentro da Unidade Mista de

Saúde de Rafard.

● Diminuir o tempo de espera do paciente na recepção.

- Funções Principais.

● Evitar que a recepcionista necessite consultar agendas com o(s)

cadastro(s) do(s) paciente(s), ou em determinados casos elaborar um

cadastro do novo paciente.

● Facilitar a consulta do histórico do paciente, diminuindo o volume de

papéis dentro da unidade.

● Controlar toda emissão de receituário para retirada de medicamentos da

farmácia.

● Controlar toda movimentação de entrada e saída de medicamento da

farmácia.

● Manter prontuário do paciente atualizado e de fácil acesso.

● Facilidade no preenchimento e busca do prontuário pelo médico ou

atendente.

● Formalizar e padronizar o atendimento.

- Questões de Desempenho

Para esse sistema não foram observadas questões críticas de desempenho,

contudo, algumas observações valem ser citadas.

Para o funcionamento adequado do sistema é indispensável que haja uma rede

de computadores funcionando adequadamente, máquinas com uma

capacidade razoável de processamento, por exemplo com as configurações

mínimas a seguir:

25

Estações de trabalho: (consultórios médicos, atendimento balcão, urgência /

emergência, farmácia, consultório odontológico): Processador com velocidade

mínima de 500 Mhz, 512 MB de memória RAM e 200 MB de espaço livre no

HD.

Servidor: Processador com velocidade mínima de 1.8 Ghz, 1 GB de memória

RAM, 160 GB de HD, gravador de CD/DVD.

- Restrições Técnicas e Administrativas

Restrições Técnicas:

Da mesma forma, as restrições técnicas para esses sistemas não são críticas,

pois alguns fatores já estão presentes na UMS. Uma restrição técnica seria por

exemplo, a falta de energia elétrica, entretanto, a unidade já possui um gerador

de energia que atende a todas as dependências, solucionando portanto esse

problema.

Restrições Administrativas:

Pelo motivo do sistema trabalhar com informações sigilosas, existe a

necessidade de um controle seguro dos acessos a estas informações. O

sistema deverá prover um controle de acessos por usuários, pois, dentro desse

contexto, somente profissionais da saúde (médicos, enfermeiras, psicólogos)

podem ter acesso ao histórico clínico do paciente e os demais funcionários,

poderão acessar somente as informações cadastrais dos pacientes.

Uma outra restrição administrativa é o controle do tempo de atendimento. O

horário de início de cada fase do atendimento (atendimento no balcão, pré-

26

consulta e consulta) deverá ser registrado, não havendo por parte do usuário, a

possibilidade de modificar esse horário.

O usuário solicitou para que a hora não fosse mostrada na tela e sim somente

gravada internamente. Esse fato, além de impedir modificações não levantaria

suspeitas sobre o controle que se pretende fazer, podendo com isso, mascarar

um resultado que não corresponde a realidade atual.

27

6. Estudo de Viabilidade Financeira

6.1 - Previsão Financeira

A previsão de custos com esse projeto será composta através dos seguintes

pontos: custos com equipamentos, custos com instalações, custo com a

implementação do sistema, custo com treinamentos.

Não levamos em consideração, para esse projeto, os custos fixos como:

energia elétrica, água, alimentação e materiais de expediente.

Também procuramos adotar como critério para o cálculo do valor do sistema a

análise por pontos de função (FP).

Uma restrição a essa técnica (FP), foi o fato de não possuirmos dados

históricos para poder calcular um valor com maior precisão.

6.2 – Investimentos em Infra – estrutura.

Para a implantação desse sistema na Unidade Mista de Saúde, serão

necessários os seguintes equipamentos:

Um Computador com as seguintes características:

- Processador Pentium IV ou similar;

- 1 GB de memória RAM

- 160 GB de HD

- Gravador de DVD

- Monitor LCD 15”

- Placa mãe ASUS ou similar

- No-break

Esse computador será o servidor, justificando portanto, uma máquina mais potente.

28

Oito Computadores com as seguintes características:

- Processador Pentium III ou superior

- 512 MB de memória RAM

- 40 GB de HD

- Monitor 15” ou superior

- Placa Mãe ASUS ou similar

- Estabilizador

Essas máquinas servirão como terminal de consulta e inserção de dados, ou

seja, as máquinas que ficarão nos consultórios , farmácia, atendimento

ambulatorial, sala de aplicações, sala de pré-consulta e recepção.

A distribuição dos equipamentos, justificando o pedido de oito máquinas, seria

feita da seguinte forma:

- Três máquinas, sendo uma para cada um dos três consultórios;

- Uma máquina para a farmácia;

- Uma máquina para o atendimento ambulatorial;

- Uma máquina para a sala de aplicações;

- Uma máquina para sala de pré-consulta;

- Uma máquina para a recepção.

Quatro Impressoras.

Sugerimos dois tipos de impressoras: laser e matricial.

As vantagens e desvantagens de cada uma são:

- Matricial: Custo para aquisição do equipamento é maior que para uma

impressora Laser. Manutenção com recarga é mais barata, por usar a fita.

Impressão mais demora e menos precisa.

29

- Laser: Custo para aquisição mais baixo. Manutenção de recarga é mais

cara, por usar o Toner. Imprime em média de 3000 a 4000 folhas por toner,

dependendo do modelo escolhido. Impressão rápida e precisa.

Para efeito de melhor visualizar a distribuição dos equipamentos na

UMS, colocamos abaixo um desenho ilustrando as salas e os equipamentos

que estarão em cada uma delas:

30

Desenho ilustrativo da distribuição dos equipamentos na UMS

Com base nas descrições acima, elaboramos uma planilha contendo os custos com infra estrutura, ficando da seguinte forma:

Descrição Material Quantidade Valor Unitário Valor Total

Micro computador (servidor)

Equipamento 1 2.400,00 2.400,00

Micro computador (estações)

Equipamento 8 1.400,00 11.200,00

Impressoras Laser

Equipamento 4 550,00 2.200,00

Impressora Matricial

Equipamento 4 950,00 3.800,00

Total de Equipamentos: 19.600,00

6.3 – Investimento em desenvolvimento

Esse cálculo tem efeito meramente didático, tendo em vista que o sistema não terá custo algum ao usuário.

Para calcular o valor com o desenvolvimento, utilizamos a técnica de pontos de função (PF). Após os cálculos, chegamos ao valor aproximado de 210 pontos de função para o desenvolvimento desse sistema.

Através de levantamentos já realizados, um programador utilizando a ferramenta Delphi, produz em média 0,1477 PF por hora, sendo assim, nosso sistema precisaria de 1420 horas para desenvolvimento.

Utilizando um valor médio de R$ 25,00 por hora (valor praticado em nossa região), chegamos ao valor de R$ 35.500,00.

Somando o custo do Equipamento (R$ 19.600,00) mais o custo do desenvolvimento (R$ 35.500,00), mais o custo do subsistema UMS2 (R$ 35.000,00), chegamos a um valor total de R$ 90.100,00.

31

Tabela de valores com investimentos em equipamentos

6.4 – Custos TotaisAbaixo destacamos os custos totais para o desenvolvimento do sistema, incluindo os equipamentos necessários e também, o valor da mão de obra com o desenvolvimento.

Total de Equipamentos 19.600,00

Custos com Desenvolvimento 75.500,00

Custo total do projeto 90.100,00

6.5 – BenefíciosOs custos com a elaboração e desenvolvimento desse projeto justificam-se pelos benefícios proporcionados.

Atualmente todo o controle é feito de forma manual, possibilitando a ocorrência de falhas durante o processo, assim também como uma forma incorreta de administrar os bens públicos, tendo em vista que situações graves vem acontecendo, como por exemplo, a distribuição de medicamentos à população sem ter um controle realmente eficiente, garantindo que somente as pessoas cadastradas recebam os medicamentos e também que não haja saída de remédios sem a devida autorização, no caso, uma receita emitida durante uma consulta médica realizada na própria unidade de saúde.

O sistema fornecerá a possibilidade de se ter um controle mais amplo sobre todo o processo administrativo, possibilitando que as coordenadoras de saúde e administrativa acompanhem e gerenciem de uma forma mais ampla o que acontece na Unidade Mista de Saúde.

A entrega de medicamentos, controle de atendimento, controle dos exames, tudo isso será administrado de forma mais prática e rápida, possibilitando determinar com mais precisão realmente quais cobranças são devidas, quais são os medicamentos com maior utilização, se a entrega está sendo feita de forma correta e conforme prescrita pelo médico, além das possibilidades da visualização de relatórios sintetizando todos esses processos.

Também podem ser destacados os benefícios intangíveis do sistema, como por exemplo, uma maior satisfação da população, menor sobrecarga de trabalho aos funcionários uma vez que as inúmeras anotações em papéis hoje feitas, serão totalmente transferidas ao sistema, além do controle das pastas dos pacientes que atualmente é totalmente manual e que também será informatizado com a implantação do sistema.

Quanto ao custo, o valor que aparentemente parece ser um investimento alto, pode ser rapidamente revertido em economia, tendo em vista que com um

32

Tabela de resumo dos custos do projeto

melhor controle na entrega de medicamentos o alto custo atualmente utilizado para efetuar a reposição destes, tende a sofrer uma queda brusca de valores.

33

7. Riscos do Projeto

7.1 – Conhecimento limitado sobre todo o processo de controle de uma Unidade Mista de Saúde

7.1.1 – MagnitudeAlta

7.1.2 – DescriçãoO conhecimento da equipe, no que se refere a todo o processo de controle de

uma unidade de saúde, é relativamente limitado.

7.1.3 – ImpactoPodem ocorrer dificuldades para implementar algumas particularidades do

sistema, tendo em vista que algumas rotinas são muito específicas e fogem ao

domínio de conhecimento da equipe.

7.1.4 – IndicadoresAlguns processos que por ventura não tenham sido especificados

corretamente, durante o levantamento dos requisitos, podem vir a não

funcionar adequadamente ou mesmo não ser implementados, caso tenham

sido omitidos. Como já relatado, a equipe possui um conhecimento limitado do

processo como um todo e isso pode prejudicar, em parte, o desenvolvimento

do sistema

7.1.5 – Estratégia de MitigaçãoProcurar por sistemas similares, conversar em hospitais onde sistemas

parecidos já estejam em funcionamento para poder minimizar ao máximo

possíveis falhas.

34

7.1.6 – Plano de contingênciaFazer reuniões constantemente com o usuário do sistema, mostrar protótipos e

envolvê-los em todas as partes do desenvolvimento, procurando sempre

corrigir, em tempo hábil, possíveis falhas.

35

7.2 – Prazos não cumpridos


7.2.2 – DescriçãoO tempo para concluir e implantar o sistema exceder o prazo estimado e

determinado para a conclusão da tarefa.

7.2.3 – ImpactoNesse caso, pode esse risco gerar uma insatisfação de tal tamanho no usuário,

que ele venha a cancelar o projeto.

7.2.4 – IndicadoresAtrasos nas entregas parciais do projeto.

7.2.5 – Estratégia de MitigaçãoAcompanhar sempre o cronograma, verificando periodicamente se o

desenvolvimento está dentro do prazo previsto.

7.2.6 – Plano de contingênciaCaso não seja possível contemplar todas as funcionalidades do sistema,

conforme descrição já detalhada, elencar as prioridades, as funcionalidades

básicas sem as quais o sistema seria inviável e implementá-las primeiramente.

36

7.3 – Os equipamentos necessários não serem adquiridos pela Unidade Mista de Saúde


7.3.2 – DescriçãoA Unidade Mista de Saúde, seja por qual motivo for, deixar de adquirir e

disponibilizar os equipamentos necessários para a implantação do sistema.

Esses equipamentos são: computadores, impressoras e todo o cabeamento de

rede.

7.3.3 – ImpactoSem os equipamentos de hardware necessários, o projeto torna-se inviável,

pois não poderá de fato ser implantado, comprometendo todo o trabalho de

desenvolvimento.

7.3.4 – IndicadoresAtrasos na aquisição dos equipamentos, demora na liberação de verbas para a

compra.

7.3.5 – Estratégia de MitigaçãoConscientizar os responsáveis, durante todo o processo de desenvolvimento,

da importância de adquirir e deixar toda a estrutura pronta para a implantação,

frisando sempre os benefícios que o sistema trará à Unidade Mista de Saúde.

37

7.3.6 – Plano de contingênciaComo um último recurso, caso a aquisição de fato não seja feita, tentar a

doação dos equipamentos através de empresas locais.

38

7.4 – Perda de um componente da equipe

7.4.1 – MagnitudeMédia

7.4.2 – DescriçãoPor qualquer motivo, um membro da equipe de desenvolvimento necessitar

deixá-la, durante a fase de desenvolvimento. Esse é um fator que pode

ocasionar alguns transtornos, porém, não ocasionaria o cancelamento do

projeto.

7.4.3 – ImpactoTodos os membros da equipe são importantes, portanto, caso algum venha a

deixá-la, alguns transtornos podem ocorrer, tais como: necessidade de

readaptação das tarefas e possíveis atrasos no cronograma.

7.4.4 – IndicadoresMembro do grupo desistir do curso.

Membro do grupo se ausentar, por motivos alheios à sua vontade.

7.4.5 – Estratégia de MitigaçãoProcurar sempre manter um diálogo franco com toda a equipe, procurando

identificar possíveis pontos que possam causar desistência, exceção àqueles

motivos de força maior.

39

7.4.6 – Plano de contingênciaReadaptar o projeto aos alunos que continuam na equipe, redistribuindo tarefas

e reorganizando o cronograma para que as tarefas possam continuar a ser

cumpridas.

40

7.5 – Surgimento de novos requisitos ou alterações nos requisitos já existentes


7.5.2 – DescriçãoO surgimento de novos requisitos, dependendo do estágio em que se encontre

o desenvolvimento, pode ocasionar uma grande mudança na estrutura do

sistema. Novos requisitos podem ocorrer por força de mudança na Legislação

ou mesmo, por mudanças nas regras do negócio. O mesmo é válido para

modificações nos requisitos já existentes, principalmente se estes já estiverem

completamente implementados.

7.5.3 – ImpactoMudanças muito profundas nos requisitos ou a adição de novas

funcionalidades, não descritas no início do projeto, podem levar a atrasos no

cronograma ou, numa situação mais extrema, inviabilizar o projeto.

7.5.4 – IndicadoresNovas solicitações por parte do usuário.

7.5.5 – Estratégia de MitigaçãoEstabelecer prioridades nos requisitos do usuário, orientando-o em quais são

as funcionalidades essenciais ao funcionamento do sistema.

41

7.5.6 – Plano de contingênciaFazer um levantamento inicial de requisitos bastante detalhado, procurando

identificar ao máximo as funcionalidades que o sistema deverá atender. Caso

surjam novos requisitos, identificar a prioridade desse requisito e o impacto

dele no desenvolvimento, verificando se ele é indispensável e, caso seja,

readaptar as tarefas para atendê-lo.

42

7.6 – Interface do sistema não possuir uma correta usabilidade


7.6.2 – DescriçãoA interface gráfica do sistema, ou seja, as telas do sistema, não possuírem

uma navegação amigável e intuitiva, dificultando a utilização do sistema.

7.6.3 – ImpactoCaso a interface, que é a ponte de ligação do usuário com o sistema, não seja

facilmente navegável e intuitiva, os usuários podem se sentir desestimulados a

utilizá-la.

7.6.4 – IndicadoresTelas confusas, com muitos itens numa única aba, sem as sinalizações

adequadas e botões de atalhos.

7.6.5 – Estratégia de MitigaçãoElaborar telas simples, seguindo os padrões de design e usabilidade,

identificando todos os campos e botões de forma adequada.

7.6.6 – Plano de contingênciaSe identificado qualquer tipo de dificuldade de utilização, por parte dos

usuários, imediatamente fazer as adaptações necessárias afim de resolver o

problema.

43

7.7 – Desempenho Funcional do Sistema

7.7.1 – Magnitude

Alto

7.7.2 – Descrição do Risco

O sistema não se mantém estável, gerando erros ou possuindo um tempo de resposta

alto.

7.7.3 – Impactos

Insatisfação do usuário operacional do sistema e também do público que dele

depende.

7.7.4 – Indicadores

Alto tempo de resposta, freqüentes queda do desempenho do sistema e erros durante

a execução.

7.7.5 – Estratégia de Mitigação

Possuir equipamentos de hardware adequados e um bom Sistema de Gerenciamento

de Banco de Dados.

44

7.7.6 – Plano de Contingência

Verificar as deficiências de hardware antes do sistema ser implantado e, antes de

colocar o sistema totalmente funcional, utilizá-lo por alguns dias em fase de teste,

identificando e corrigindo os problemas que surgirão.

45

7.8 – Rompimento do Contrato por parte do Usuário

7.8.1 – Magnitude

Alto

7.8.2 – Descrição do Risco

O usuário do sistema decide, por razões adversas, romper o contrato de

desenvolvimento.

7.8.3 – Impactos

O grupo de desenvolvimento ficará sem o projeto, podendo ter comprometido o seu

Trabalho de Conclusão de Curso.

7.8.4 – Indicadores

Usuário recebe outra proposta de empresas da área que atendam suas necessidades

de forma mais rápida.

Mudanças nos critérios administrativos, por se tratar de órgão público, que impeçam a

continuidade do desenvolvimento.

7.8.5 – Estratégia de Mitigação

Procurar sempre manter contato com usuário, identificando possíveis insatisfações da

parte dele que possam gerar um rompimento.

Cumprir prazos e atender aos requisitos solicitados.

46

7.8.6 – Plano de Contingência

Procurar adaptar o sistema a outra unidade que possua características similares

quanto ao funcionamento, embora não seja uma alternativa das mais simples.

47

8. Plano de Projeto

8.1 – Divisão de Tempo e Esforço

Para efeito de um melhor entendimento, elaboramos uma tabela demonstrando

a divisão do tempo durante o desenvolvimento do projeto:

Atividades TCC I Tempo alocado

Levantamento dos requisitos do sistema (entrevistas com usuário, validação dos requisitos levantados)

18%

Estudo de viabilidade financeira 7%

Descrição dos casos de uso e cenários 10%

Diagramas de casos de uso,diagrama de classes, diagramas de atividades e diagramas de seqüência.

25%

Diagrama de entidade relacionamento e modelo entidade relacionamento

5%

Implementação de alguns casos de uso 25%

Realização de testes 10%

48

Tabela de distribuição do tempo durante o projeto do TCC I

Abaixo demonstramos os mesmos valores acima descritos, porém, na forma de gráfico:

Distribuição do Tempo no Projeto

18%

7%10%

25%

5%

25%

10%

0%

5%

10%

15%

20%

25%

30%

1

Atividades

% d

e Te

mpo

Util

izad

a

Levantamento dosrequisitos do sistema Estudo de viabilidadefinanceiraDescrição dos casos deuso e cenáriosDiagramas

DER

Implementação

Testes

Gráfico da Distribuição do Tempo para a realização do projeto

A fase inicial do projeto, que envolve o levantamento de requisitos do sistema,

sendo uma das fases principais do projeto, envolve 20% do total do tempo do

projeto. Após esse levantamento foi gerado um documento de requisitos (item

3.1, página 10), que foi analisado pelo usuário para verificar se realmente tudo

o que foi combinado estava documentado.

Na segunda fase temos o estudo de viabilidade financeira do projeto,

elaborando os custos com equipamentos e também com o desenvolvimento.

Na terceira fase ocorre a descrição dos casos de uso e cenários do sistema, ou

seja, uma narração descritiva de como cada parte do sistema funcionará.

Na quarta fase, ocorre a elaboração dos diagramas de atividade e seqüência,

contendo os casos de uso e os diagramas de classes. Essa fase servirá para a

49

futura implementação do sistema, pois, através dos diagramas já se pode

estabelecer uma prévia do funcionamento do sistema que, estando de acordo

com as necessidades do usuário, servirá de guia para a implementação do

sistema.

Na quinta fase, após os diagramas terem sido elaborados, ocorre a elaboração

dos modelos de dados, representados através de diagramas. Esses modelos

serão a base para a implementação do banco de dados.

Na sexta fase, que é a implementação de alguns dos casos de uso do sistema,

temos o primeiro protótipo do sistema. Através da documentação realizada, a

implementação é feita. O artefato produzido nessa fase é um protótipo do

sistema que servirá, principalmente, para validar junto ao usuário o que está

sendo desenvolvido.

Na sétima e última fase, os testes do sistema são executados visando suprir

possíveis falhas na elaboração e no levantamento de requisitos.

Abaixo colocamos um cronograma do período de desenvolvimento do sistema.

A tabela mostra o nome da atividade e sua data de início e .

Início FinalTCC I 12/2/2007 18/5/2007

Concepção do Projeto 14/2/2007 7/3/2007Levantamentos de requisitos 14/2/2007 23/2/2007Validação dos requisitos 6/3/2007 7/3/2007Estudo Financeiro 12/2/2007 16/2/2007Estudo de Viabilidade Financeira 12/2/2007 16/2/2007Descrição do Projeto 12/3/2007 13/3/2007Descrição Textual do Sistema 12/3/2007 13/3/2007Elaboração de Diagramas 19/3/2007 9/4/2007Diagramas de Casos de Uso 19/3/2007 20/3/2007Descrição dos Cenários 26/3/2007 26/3/2007Diagramas de Classe 26/3/2007 27/3/2007Diagramas de Atividade 30/3/2007 3/4/2007Diagramas de Sequência 7/4/2007 9/4/2007Modelos de Dados 7/4/2007 9/4/2007DER 7/4/2007 9/4/2007Implementação 16/4/2007 18/5/2007Implementação dois casos de uso 16/4/2007 26/4/2007Realização de Testes 14/5/2007 18/5/2007

TCC II 14/8/2007 13/11/2007Elaboração de cronograma 14/8/2007 14/8/2007Planejamento das atividades 14/8/2007 14/8/2007Modelo de Projeto 14/8/2007 22/8/2007

50

Atualizar o modelo fisico de dados 14/8/2007 14/8/2007Revisar o Banco de Dados 14/8/2007 18/8/2007Diagrama de estados 18/8/2007 19/8/2007Diagrama de Atividades 19/8/2007 21/8/2007Atualizar o Estudo de Viabilidade Financeira 21/8/2007 22/8/2007Documento de Arquitetura 22/8/2007 27/8/2007Diagrama de Implementação 22/8/2007 25/8/2007Modelo de Arquitetura do Sistema 25/8/2007 27/8/2007Implementação 27/8/2007 31/10/2007Integração com o Banco de dados 27/8/2007 29/8/2007Codificação do Sistema 29/8/2007 26/10/2007Correção de falhas 26/10/2007 27/10/2007Manual do usuario, Manual de instalação 27/10/2007 31/10/2007Revisão do Projeto 27/10/2007 29/10/2007Adaptar modificações do Projeto 27/10/2007 29/10/2007Projeto de Testes 29/10/2007 5/11/2007Planejar os testes a serem executados 29/10/2007 31/10/2007Instalar a versão beta 31/10/2007 1/11/2007Realização de Testes 1/11/2007 5/11/2007Implantação 5/11/2007 13/11/2007Implantação do sistema 5/11/2007 09/11/2007Treinamento 9/11/2007 13/11/2007

Ressaltamos que nem todas as tarefas foram cumpridas de acordo com o cronograma estabelecido, principalmente a Implantação do sistema e Treinamento dos Usuários. Esse atraso deve-se principalmente ao fato da Unidade Mista de Saúde ainda não ter conseguido os equipamentos necessários para a instalação do sistema.

51

Cronograma de desenvolvimento total do projeto (TCC I e II)

9. Glossário

COREN Conselho Regional de Enfermagem

CRF Conselho Regional de Farmácia

CRM Conselho Regional de Medicina

Diagnóstico Após a análise dos sintomas do paciente, o médico emite seu parecer, chamado de diagnóstico.

Especialidade Especialização do profissional. Por exemplo, cardiologista, ginecologista, etc

FP Pontos de Função

Pré-Consulta Procedimentos realizados antes da consulta, como pesagem, verificação da pressão arterial e temperatura

Prescrição Tudo aquilo que o médico receita ao paciente

Prontuário Local onde são registradas todas as informações do paciente

SGBD Sistema Gerenciador de Banco de Dados

UMS Unidade Mista de Saúde

Status Indica no sistema, o estado de um determinado cadastro, por exemplo, se ele está ativo ou inativo.

52

10. Atributos dos Requisitos

Para podermos posteriormente classificar a matriz dos requisitos, faremos

primeiramente a descrição de cada atributo e sua respectiva classificação.

10.1 Atributos

10.1.1 – Complexidade

Este atributo caracteriza o requisito quanto ao seu grau de dificuldade na

implementação, relacionamento com outros requisitos, podendo assumir os

seguintes valores:

Alta – O requisito é muito complexo, a sua implementação depende de

vários outros requisitos relacionados.

Média – Esse requisito possui boa parte da sua implementação de fácil

desenvolvimento.

Baixa – Esse requisito possui implementação trivial.

10.1.2 - Estabilidade

Esse atributo relaciona-se com a possibilidade do requisito sofrer alterações

durante o desenvolvimento do projeto. Possui os seguintes valores:

Alta – São os requisitos do sistema que raramente sofrerão algum tipo

de mudanças.

Média – São os requisitos que sofrem alterações com uma freqüência

intermediária.

53

Baixa – Aqueles requisitos que podem sofrer alterações constantes ao

longo do desenvolvimento do projeto.

10.1.3 – Prioridade

Esse atributo caracteriza a importância do requisito dentro do projeto. Seus

valores podem ser:

Essencial – São os requisitos de mais alta prioridade. São

indispensáveis ao desenvolvimento do projeto, sem eles, o sistema

não funcionará;

Importante – Possuem certa relevância, portanto, caso não seja

implementado, o funcionamento do sistema não será comprometido;

Desejável – É o requisito que, se desenvolvido, acrescentará valores

ao sistema, contudo, caso não seja, não comprometerá o

funcionamento básico do sistema.

– Custo

Esse atributo está relacionado ao custo financeiro do requisito ao projeto.

Pode ser:

Alto – Custo de implementação mais elevado em relação aos demais

requisitos;

Médio – Custo de implementação está na média em relação ao

demais requisitos;

54

Baixo – Custo de implementação está abaixo da média, em relação

aos demais requisitos;

– RiscoIndica se o requisito poderá causar danos que possam comprometer o

projeto. Podem ser classificados em:

Alto – É o requisito que, se ocorrer, pode comprometer

significativamente o projeto;

Médio – É o requisito que, se ocorrer, trará conseqüências

moderadas ao projeto;

Baixa – São os requisitos que dificilmente trarão algum tipo de

conseqüência negativa ao projeto

55

10.2 - Matriz de Atributos dos Requisitos

Descrição Complexidade Estabilidade Prioridade Custos RiscoEfetuar Login Alta Alta Essencial Médio MédioAtribuir Nível de Acesso Média Alta Essencial Médio MédioCadastrar Funcionário Média Média Essencial Médio MédioCadastrar Paciente Média Média Essencial Médio MédioCadastrar Medicamento Média Média Essencial Médio MédioCadastrar Tipo de Medicamento Média Média Essencial Médio MédioCadastrar Exames Média Média Essencial Médio MédioCadastrar Usuários Média Média Essencial Médio MédioSolicitar Consulta Baixa Alta Essencial Baixo MédioRealizar Pré-Consulta Média Alta Essencial Baixo MédioRealizar Consulta Alta Média Essencial Alto AltoEmitir Pedido de Exames Média Média Importante Médio MédioRealizar Atendimento Ambulatorial

Médio Médio Essencial Médio Médio

Controlar Medicamento Alta Médio Essencial Médio MédioEmitir Relatórios Média Baixa Essencial Médio Médio

56

11 – Documentos de Requisitos

11.1 – Diagrama de Casos de Uso

57

11.1.1 – Diagrama de Casos de Uso (Representação do Super Ator Funcionário)

Esclarecimento: O ator O Paciente, foi colocado nessa representação devido ao fato de que este, num determinado momento, pode ser paciente e também funcionário.

Por exemplo, um funcionário da Unidade que fosse atendido em uma consulta, seria nesse momento além de funcionário, também paciente.

58

11.2 – Descrição do Caso de Uso Efetuar Login

Projeto: UMS - Rafard

Identificador do Caso de Uso: Efetuar Login

Número do Caso de Uso: 1

Autor do Caso de Uso: Fábio Lima

Número da Versão do Caso de Uso: 1

Atores:

Iniciadores: Funcionário.

Colaboradores: Todos os usuários que estiverem cadastrados no sistema.

Resumo: Esse caso de uso tem por permitir ou não a entrada do usuário do sistema.

Casos de Uso Referenciados: Cadastrar Entidade, Controlar Acesso.

Pré-Condições: Existir um usuário padrão previamente cadastrado para efetuar o primeiro login.

Pós-Condições: Usuário logado no sistema.

Fluxo de Execução Básico:

Inicialização:

O usuário executa o sistema.

Processo:

O login e senha são inseridos pelo usuário e após, este confirma os dados, clicando no botão ok.

59

Terminação:

O sistema irá definir o nível de acesso do usuário logado de acordo com o seu cadastro de nível de acesso.

Exceções:

O usuário digitar seu login e senha errados.

Interface Gráfica do Caso de Uso Efetuar Login

60

11.2.1 – Cenários do Caso de Uso Efetuar Login

Cenário Ótimo inserção:

Usuário inicia o sistema

Tela de login é aberta

Usuário digita seu login e sua senha

O usuário e senhas estão corretos

O sistema verifica o nível de acesso do usuário logado

O sistema é liberado para uso.

Cenário com Exceção inserção: Usuário Digitar Login ou senha incorretos.

Usuário inicia o sistema

Tela de login é aberta

Usuário digita seu login ou sua senha errados

É mostrada uma mensagem informando o erro.

Usuário digita seu login e sua senha

O usuário e senhas estão corretos

O sistema verifica o nível de acesso do usuário logado

O sistema é liberado para uso

61

11.2.2 - Diagrama de Atividades – Efetuar Login

62

11.2.3 – Diagrama de Seqüência do Caso de Uso Efetuar Login

63

11.2.4 – Diagrama de Classes – tela_login

64

11.2.5 – Diagrama de Estado – tela_login

65

11.3 – Descrição do Caso de Uso Cadastrar Funcionário


Identificador do Caso de Uso: Cadastrar Entidades


Autor do Caso de Uso: Leandro da Silva


Atores:

Iniciadores: Funcionário.

Colaboradores: Todos os usuários que estiverem cadastrados no sistema.

Resumo: Esse caso de uso representa todo o cadastramento das entidades do sistema.

Casos de Uso Referenciados: Efetuar Login.

Pré-Condições: Existir um funcionário para ser cadastrado.

Pós-Condições: Funcionário cadastrado.


Inicialização:

Esse caso de uso se inicia quando houver a necessidade de cadastramento de uma determinada entidade, ou seja, quando o funcionário acessar uma tela de cadastro.

Processo:

O usuário seleciona no menu Cadastro qual item será cadastrado. Será aberto um formulário, referente ao item que será cadastrado, onde o usuário irá digitar os dados necessários.

66

Terminação:

Esse caso de uso se encerra quando o usuário do sistema confirma o cadastramento da entidade, ou então, quando resolve cancelar o cadastramento, cancelando a operação.

Exceções:

Os dados disponíveis para cadastrar a entidade não são suficientes para completar o cadastro.

Interface gráfica do caso de uso Cadastrar Funcionário

67

11.3.1 – Cenário do Caso de Uso Cadastrar Funcionário

Cenário Ótimo para inserção:

O funcionário clica no menu cadastro e escolhe a opção desejada

É aberta uma tela para a inserção dos dados

O funcionário solicita os dados para efetuar o cadastro

O funcionário clica no botão salvar

Os dados são gravados

É exibida uma mensagem confirmando a inserção dos dados no sistema.

Cenário com Exceção para inserção: O sistema verifica que os dados não são consistentes

O funcionário clica no menu cadastro e escolhe a opção desejada

É aberta uma tela para a inserção dos dados

O funcionário solicita os dados para efetuar o cadastro


O sistema verifica que os dados não são consistentes

É exibida uma mensagem de erro ao funcionário

A tela para a inserção dos dados é novamente disponibilizada para que o usuário corrija os dados.




Cenário Ótimo para edição:

Funcionário abre o formulário de cadastro.

68

Atendente seleciona o cadastro a ser alterado.

Atendente altera os dados.

Atendente confirma alteração.

Cenário com exceção edição:

Cadastro do paciente não existe.

Campos obrigatórios não preenchidos.

Cenário Ótimo para exclusão:


Funcionário seleciona o paciente a ser excluído.

Sistema verifica se existe relação com o paciente.

Sistema retorna que não há relação.

Exclusão efetuada com sucesso.

Cenário com exceção exclusão:


Funcionário seleciona o paciente a ser excluído.

Sistema verifica que existe relação com o paciente.

Sistema retorna que não há possibilidade de exclusão.

Sistema inativa o paciente.

69

11.3.2 – Diagrama de Atividades do Caso de Uso Cadastrar Funcionário

70

11.3.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Funcionário

71

11.3.4 – Diagrama de Classes - tela_cadastro_funcionario

72

11.3.5 – Diagrama de Estados – tela_cadastro_funcionario (incluir)

73

11.3.6 – Diagrama de Estados – tela_cadastro_funcionario (excluir)

74

11.3.7 – Diagrama de Estados – tela_cadastro_funcionario (editar)

75

11.4 – Descrição do Caso de Uso Solicitar Consulta


Identificador do Caso de Uso: Solicitar Consulta


Autor do Caso de Uso: André Luís Belini


Atores:

Iniciadores: Paciente

Colaboradores: Atendente

Resumo: Esse caso de uso representa a chegada do paciente ao hospital, passando pelo balcão de atendimento e a solicitação de uma consulta médica, por parte deste. O Atendente irá solicitar o cartão de saúde do paciente e localizará o seu prontuário para a consulta.

Casos de Uso Referenciados: Atendimento Pré-Consulta.

Pré-Condições: Existir um paciente previamente Ca-dastrado, Existir uma Solicitação de Consulta, Existir um médico previamente cadastrado, Existir uma atendente previamente cadastrada.

Pós-Condições: O prontuário do paciente estará disponível para a pré-consulta.


Inicialização:

Esse caso de uso se inicia quando o paciente chega à recepção da Unidade e solicita uma consulta.

76

Processo:

Após ter em mãos a carteirinha com a matrícula do paciente, o atendente deverá selecionar a opção Nova Consulta. Será então aberta a tela para que o atendente selecione o paciente a ser atendido, dando início ao processo de atendimento

Terminação:

Esse caso de uso se encerra quando o atendente selecionar o nome do paciente e confirmar a inclusão de uma nova consulta.

Exceções:

Paciente chegar à unidade em estado grave e ser encaminhado diretamente ao pronto atendimento, não realizando os procedimentos rotineiros.

Campos não preenchidos

Interface Gráfica do Caso de Uso Solicitar Consulta

77

11.4.1 – Descrição do Cenário do Caso de Uso Solicitar Consulta


Paciente chega à recepção e solicita uma consulta

Atendente solicita o cartão do paciente

Atendente inclui uma nova solicitação de consulta no sistema.

Atendente insere os dados.

Atendente confirma solicitação.

Cenário com exceção inserção: Campos não preenchidos

Paciente chega a recepção e solicita uma consulta





Campos não preenchidos.

Atendente é informada que existem campos não preenchidos.

Solicitação retorna para que a atendente insira os dados.

Cenário com exceção inserção: O paciente dá entrada em estado grave na unidade de saúde.

Paciente dá entrada em estado grave na unidade de saúde

Paciente é encaminhado diretamente ao atendimento médico.

Paciente ou acompanhante, após atendimento retornam para realiza o procedimento de solicitar consulta na recepção.

78

Paciente chega à recepção e solicita uma consulta






Atendente abre o formulário de cadastro.

Atendente seleciona a solicitação a ser alterada.

Atendente altera os dados.

Atendente confirma alteração.


Solicitação de consulta não existe.




Atendente seleciona a solicitação a ser excluída.

Sistema verifica se existe relação com a solicitação.





79

Atendente seleciona a solicitação a ser excluída.

Sistema verifica que existe relação com a solicitação.


Sistema inativa a solicitação.

80

11.4.2 – Diagrama de Atividades do Caso de Uso Solicitar Consulta

81

11.4.3. – Diagrama de Seqüência do Caso de Uso Solicitar Consulta

82

11.4.4. – Diagrama de Classes – tela_atendimento_balcao

83

11.4.5. – Diagrama de Estado – tela_atendimento_balcao (incluir)

84

11.4.6. – Diagrama de Estado – tela_atendimento_balcao (editar)

85

11.4.7. – Diagrama de Estado – tela_atendimento_balcao (excluir)

86

11.5 – Descrição do Caso de Uso Realizar Pré-Consulta


Identificador do Caso de Uso: Realizar Pré-Consulta




Atores:

Iniciadores: Atendente, Paciente

Colaboradores: Enfermeira

Resumo: Esse caso de uso representa o próximo passo após a passagem pelo balcão de atendimento. Nesse estágio, o paciente passa pela checagem do seu peso, altura, pressão arterial e temperatura. Esses dados são incluídos no prontuário do paciente, que será então encaminhado ao médico.

Casos de Uso Referenciados: Solicitar Consulta, Realizar Consulta Médica.

Pré-Condições: O paciente ter passado pelo balcão de atendimento e ter solicitado uma consulta.

Pós-Condições: O prontuário do paciente estará disponível ao médico para a consulta


Inicialização:

Esse caso de uso se inicia quando o atendente confirma a inclusão de uma nova solicitação de consulta no sistema.

87

Processo:

Assim que o atendente do balcão incluir a nova consulta, a equipe de enfermagem irá inicial o pré-atendimento. A enfermeira fará as checagens necessárias e anotará os dados no prontuário do paciente, será enviado posteriormente ao médico para que a consulta em si possa ser realizada.

Terminação:

Após terem sido realizados todos os passos acima, a enfermeira confirmará os dados no sistema. Esse procedimento encerra o atendimento pré-consulta e gerará o atendimento de consulta.

Exceções:

Paciente dá entrada em estado grave e não é atendido pela pré- consulta, passando diretamente ao atendimento de emergência.

Interface Gráfica do Caso de Uso Pré-Consulta

88

11.5.1 – Descrição do Cenário do Caso de Uso Pré-Consulta


A enfermeira chama o paciente para o pré-atendimento

O paciente passa pela checagem do seu peso, altura, pressão arterial e temperatura,

Enfermeira digita os dados do pré atendimento.

Enfermeira confirma os dados e encerra esse processo.

Cenário com Exceção para inserção:

Paciente da entrada na unidade em estado grave.

Paciente é prontamente atendido.

Paciente após atendimento retorna para seguir os procedimentos da Pré- consulta.

A enfermeira chama o paciente para o pré-atendimento

O paciente passa pela checagem do seu peso, altura, pressão arterial e temperatura,

Enfermeira digita os dados do pré atendimento.

Enfermeira confirma os dados e encerra esse processo.


Enfermeira abre o prontuário do paciente.

Enfermeira seleciona o prontuário ser alterado.

Enfermeira altera os dados.

Enfermeira confirma alteração.

89


Prontuário do paciente não existe.


Cenário Ótimo exclusão:


Enfermeira seleciona o prontuário a ser excluído.

Sistema verifica se existe relação com a pré-consulta.





Enfermeira seleciona o prontuário a ser excluído.

Sistema verifica que existe relação com a pré-consulta.


Sistema informa o procedimento a ser tomado.

Sistema inativa a pré-consulta.

90

11.5.2 – Diagrama de Atividades do Caso de Uso Pré-Consulta

91

11.5.3 – Diagrama de Seqüência do Caso de Uso Pré-Consulta

92

11.5.4 – Diagrama de Classes – tela_pre_consulta

93

11.5.5 – Diagrama de Estado – tela_pre_consulta (incluir)

94

11.5.6 – Diagrama de Estado – tela_pre_consulta (editar)

95

11.5.7 – Diagrama de Estado – tela_pre_consulta (excluir)

96

11.6 – Descrição do Caso de Uso Realizar Consulta Médica


Identificador do Caso de Uso: Realizar Consulta Médica




Atores:

Iniciadores: Enfermeira, Paciente

Colaboradores: Enfermeira, Farmacêutica.

Resumo: Esse caso de uso é o momento onde o médico tem disponível a ficha clínica do paciente, com os dados da pré-consulta e também todo o seu histórico. O médico irá anotar no histórico do paciente o que ocorreu durante a consulta, além de anotar também os medicamentos prescritos, possíveis exames e, se necessário, qual será o atendimento ambulatorial que aquele paciente irá receber.

Casos de Uso Referenciados: Realizar Pré-Consulta, Fazer Atendimento Ambulatorial, Controlar Medicamento

Pré-Condições: Haver uma solicitação de consulta. Haver uma pré-consulta.

Pós-Condições: Histórico clínico do paciente atualizado. Emissão de receita de medicamentos. Emissão de Pedido de Exames. Indicação de Atendimento Ambulatorial


Inicialização:

Esse caso de uso se inicia quando a enfermeira confirma a nova consulta, após as checagens da pré-consulta.

97

Processo:

Assim que a enfermeira confirmar a consulta, o médico receberá um aviso informando que existe uma consulta a ser realizada. O médico chamará o paciente e realizará a consulta. Feito isso, anotará os dados do paciente, seu histórico clínico e um espaço para a prescrição da consulta atual, além de campos destinados a solicitação de exames e medicamentos a serem utilizados ou ministrados no ambulatório.

Terminação:

Esse caso de uso se encerra quando o médico termina o preenchimento de todos os dados necessários e clicar no botão finalizar consulta.

Exceções:

Paciente, por algum motivo, desistir da consulta.

Interface Gráfica do Caso de Uso Realizar Consulta Médica

98

11.6.1 – Descrição do Cenário do Caso de Uso Realizar Consulta Médica


O médico verifica que existe uma consulta para ser realizada

Médico chama o paciente ao consultório

O médico realiza o atendimento

O médico analisa os sintomas

O médico, se necessário, faz a prescrição dos medicamentos necessários

O médico , se necessário,faz a solicitação dos exames necessários

O médico, se necessário, faz o encaminhamento do paciente para o atendimento ambulatorial.

Cenário exceção inserção:

O médico verifica que existe uma consulta para ser realizada

Médico chama o paciente ao consultório

Médico é informado que paciente desistiu da consulta

Médico finaliza a consulta.

Cenário Ótimo edição:

Médico abre a consulta do paciente.

Médico seleciona a consulta a ser alterada.

Médico altera os dados.

Médico confirma alteração.

99


Consulta do paciente não existe.




Médico seleciona a consulta a ser excluída.

Sistema verifica se existe relação com a consulta.





Médico seleciona a consulta a ser excluída.

Sistema verifica que existe relação com a consulta.



Sistema inativa a consulta.

100

11.6.2 – Diagrama de Atividades do Caso de Uso Realizar Consulta Médica

101

11.6.3 – Diagrama de Seqüência do Caso de Uso Realizar Consulta Médica

102

11.6.4 – Diagrama de Classes – tela_consulta

103

11.6.5 – Diagrama de Estado – tela_consulta (incluir)

104

11.6.6 – Diagrama de Estado – tela_consulta (editar)

105

11.6.7 – Diagrama de Estado – tela_consulta (excluir)

106

11.7 – Descrição do Caso de Uso Emitir Pedido de Exames


Identificador do Caso de Uso: Emitir Pedido de Exames


Autor do Caso de Uso: Rafaela Chirita da Silva


Atores:

Iniciadores: Médico

Colaboradores: Paciente

Resumo: Esse caso de uso representa um dos desdobramentos de uma consulta médica. Após o atendimento, um dos possíveis resultados de uma consulta é uma solicitação de exames, que é o alvo desse caso de uso.

Casos de Uso Referenciados: Realizar Consulta.

Pré-Condições: Existir uma consulta com a necessidade de exames complementares.

Pós-Condições: Histórico do paciente atualizado, emissão do formulário de pedido de exames.


Inicialização:

Esse caso de uso se inicia quando, durante uma consulta, o médico julga necessário solicitar exames complementares para auxiliar no diagnóstico do paciente.

Processo:

107

O médico preenche os dados necessários sobre os exames solicitados e os entrega ao paciente para que este possa, posteriormente, realizar os exames solicitados.

Terminação:

Esse caso de uso se encerra quando o médico finaliza a consulta, confirmando o atendimento e encaminhando o paciente para as providências decorrentes desta.

Exceções:

Campos não preenchidos.

Interface Gráfica do Caso de Uso Emitir Pedido de Exames

108

11.7.1 – Descrição do Cenário do Caso de Uso Emitir Pedido de Exames


O médico verifica a necessidade de solicitar exames complementares ao pacienteO médico acessa a opção de exames e preenche os dados necessáriosO médico solicita a impressão do pedido.O médico libera o paciente.

Cenário com Exceção inserção: Campos não Preenchidos

O médico verifica a necessidade de solicitar exames complementares ao pacienteO médico acessa a opção de exames Preenche os dados necessários.Campos não PreenchidosMedico retorna preencher os campos que faltam.O médico solicita a impressão do pedido.O médico libera o paciente.


Médico abre o pedido de exame do paciente.

Médico seleciona o pedido de exame a ser alterado.

Médico altera os dados.

Médico confirma alteração.


Pedido de exame do paciente não existe.


109



Médico seleciona o pedido de exame a ser excluído.

Sistema verifica se existe relação com o pedido de exame.





Médico seleciona o pedido de exame a ser excluído.

Sistema verifica que existe relação com o pedido de exame.


Processo finalizado.

110

11.7. 2 – Diagrama de Atividades para o Caso de Uso Emitir Pedido de Exames

111

11.7.3 – Diagrama de Seqüência para o Caso de Uso Emitir Pedido de Exames

112

11.7.4 – Diagrama de Classes - exames

113

11.7.5 – Diagrama de Estado – tela_exames(incluir)

114

11.7.5 – Diagrama de Estado – tela_exames(editar)

115

11.7.7 – Diagrama de Estado – tela_exames (excluir)

116

11.8 – Descrição do Caso de Uso Atendimento Ambulatorial


Identificador do Caso de Uso: Atendimento Ambulatorial.


Autor do Caso de Uso: Leandro da Silva


Atores:

Iniciadores: Médico

Colaboradores: Enfermeira, Paciente.

Resumo: Esse caso de uso, só se inicia a partir do momento que o médico faz o atendimento do paciente, solicitando para o mesmo um atendimento ambulatorial. A partir disso a enfermeira analisa a ficha do paciente com toda a prescrição do médico, chama o paciente para que o mesmo seja atendido, concluindo o atendimento.

Casos de Uso Referenciados: Realizar Consulta.

Pré-Condições: O paciente ter passado pela consulta. Possuir medicamento para o atendimento.

.

Pós-Condições: Paciente atendido e consulta concluída. Atendimento ambulatorial efetuado,


Inicialização:

Esse caso de uso se inicia quando a enfermeira chama o paciente para que o mesmo seja atendido, concluindo o atendimento.

Processo:

117

A partir do momento que os procedimentos foram prescritos pelo médico, a enfermeira executa o atendimento, confirmando a aplicação dos procedimentos e finalizando o atendimento.

Terminação:

Esse caso de uso se encerra quando a enfermeira confirma o atendimento gravando os dados do atendimento.

Interface Gráfica do Caso de Uso Atendimento Ambulatorial

118

11.8.1 – Descrição do cenário do Caso de Uso Atendimento Ambulatorial


Paciente é encaminhado ao ambulatório.

Enfermeira verifica o prontuário.

Paciente passa pelo(s) cuidado(s) necessário(s).

Enfermeira dá baixa no(s) medicamento(s) utilizado(s).

Atendimento concluído.

Cenário exceção inserção:

Não se aplicam.

119

11.8.2 – Diagrama de Atividade do Caso de Uso Atendimento Ambulatorial

120

11.8.3 – Diagrama de Seqüência do Caso de Uso Atendimento Ambulatorial

121

11.8.4 – Diagrama de Classes – tela_atendimento_ambulatorial

122

11.8.5 – Diagrama de Estado – tela_atendimento_ambulatorial (incluir)

123

11.8.6 – Diagrama de Estado – tela_atendimento_ambulatorial (editar)

124

11.9 – Descrição do Caso de Uso Controlar Medicamento

Projeto : UMS - Rafard

Identificador do Caso de Uso: Controlar Medicamento


Auto do Caso de Uso: Fábio Lima


Atores

Iniciadores : Médico

Colaboradores : Farmacêutica

Resumo : Este caso de uso representa o controle dos medicamentos dentro do

UMS de Rafard. Após a consulta com o médico, se esta gerar uma receita

médica, o sistema irá gerar uma solicitação do medicamento receitado. A

farmacêutica entrega para o paciente o medicamento receitado e o mesmo já é

baixado do sistema.

Casos de Uso Referenciados: Realizar Atendimento Ambulatorial, Realizar

Consulta Médica.

Pré-Condições: Existir a prescrição de um medicamento

durante uma consulta. Possuir medicamentos

no estoque.

Pós-Condições : Estoque de medicamento atualizado.


Inicialização:

Este caso de uso se inicia a partir da emissão de uma receita médica.

125

Processo:

Após o médico efetuar a receita médica contendo o(s) medicamento(s),

o paciente vai até a farmácia, onde a farmacêutica já terá disponível

quais medicamentos deverá entregar ao paciente, através do número da

consulta ou nome do paciente. Ao confirmar a retirada do(s)

medicamento(s), o estoque da farmácia é atualizado.

Terminação:

O caso de uso termina quando a farmacêutica clicar no botão “Efetuar

Baixa dos Medicamentos“.

Exceções:

Farmacêutica faz entrega errada.

Interface Gráfica do Caso de Uso Controlar Medicamento

126

11.9.1 - Descrição do Cenário do Caso de Uso Controlar Medica-mento


O paciente solicita o(s) medicamento(s) receitado(s) pelo médico.

Farmacêutica consulta o(s) medicamento(s) receitado(s).

Farmacêutica entrega os medicamentos receitados

Farmacêutica atualiza estoque de medicamentos.


Cenário com exceção inserção: Farmacêutica faz entrega errada.

O paciente solicita o(s) medicamento(s) receitado(s) pelo médico.

Farmacêutica consulta o(s) medicamento(s) receitado(s).

Farmacêutica entrega os medicamentos receitados.

Farmacêutica faz entrega errada.

Farmacêutica estorna a movimentação.

Sistema atualiza estoque de medicamentos.


127

11.9.2 – Diagrama de Atividade para o Caso de Uso Controlar Medicamento

128

11.9.3 – Diagrama de Seqüência do Caso de Uso Controlar Medicamento

11.9.4 –

Diagrama de Classes – medicamento

129

11.9.5 – Diagrama de Estado – tela_controla_medicamento (incluir)

131

11.9.6 – Diagrama de Estado – tela_controla_medicamento (estornar)

132

11.10 – Descrição do Caso de Uso Atribuir Nível de Acesso


Identificador do Caso de Uso: Cadastrar Nível de Acesso


Autor do Caso de Uso: Fábio Lima


Atores:

Iniciadores: Coordenadora Administrativa, Coordenadora de Saúde

Colaboradores: Todos os usuários que estiverem cadastrados.

Resumo: Esse caso de uso tem por finalidade o cadastro do nível de acesso dos usuários ao sistema.

Casos de Uso Referenciados: Cadastrar Entidades.

Pré-Condições: Estar cadastrado no sistema. Existir um usuário padrão previamente cadastrado para efetuar o primeiro acesso.

Pós-Condições: Definição do nível de acesso para aquele usuário.


Inicialização:

O caso de uso se inicia após o cadastro do usuário no sistema.

Processo:

A coordenadora administrativa, que é a pessoa responsável por efetuar esse cadastro, dará ao usuário as permissões segundo critérios internos da administração. São essas regras que irão determinar os acessos e funcionalidades do sistema que o usuário poderá realizar.

133

Terminação:

Esse caso de uso termina após o cadastramento dos níveis de acesso.

Exceções:

Se usuário estiver autenticado não é possível inativar.

Interface Gráfica do Caso de Uso Cadastrar Nível de Acesso

134

11.10.1 – Descrição do Cenário do Caso de Uso Atribuir Nível de Acesso


O funcionário acessa a tela de cadastro desejadaO funcionário consulta o usuário desejadoO funcionário atribui os níveis permitidos de acesso ao sistemaO funcionário grava o acesso atribuído ao funcionário.

Cenário com exceção inserção:

Não se aplicam

Cenário Ótimo para editar:

O funcionário acessa a tela de cadastro desejadaO funcionário seleciona o usuário desejado.O funcionário atribui os níveis permitidos de acesso ao sistema.O funcionário edita os dados de acesso do usuário.O funcionário grava o acesso atribuído ao usuário.

Cenário com exceção editar:

Se usuário estiver autenticado não é possível inativar.

135

11.10.2 – Diagrama de Atividade do Caso de Uso Atribuir Nível de Acesso

136

11.10.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Nível de Acesso

137

11.10.4 – Diagrama de Classes – tela_controle_acesso

138

11.10.5 – Diagrama de Estado – tela_controle_acesso (incluir)

139

11.10.6 – Diagrama de Estado – tela_controle_acesso (editar)

140

11.10.7 – Diagrama de Estado – tela_controle_acesso (inativar)

141

11.11 – Descrição do Caso de Uso Cadastrar Usuários


Identificador do Caso de Uso: Cadastrar Usuários


Autor do Caso de Uso: Leandro


Atores:

Iniciadores: Coordenadora Administrativa.

Colaboradores: Todos os usuários que estiverem cadastrados.

Resumo: Esse caso de uso tem por finalidade o cadastro de todos os usuários do sistema.

Casos de Uso Referenciados: Cadastrar Entidades.

Pré-Condições: Existir um usuário para ser cadastrado.

Pós-Condições: Usuário cadastrado.


Inicialização:

Esse caso de uso se inicia quando houver a necessidade de cadastramento de um determinado usuário, ou seja, quando a Coordenadora acessar a tela de cadastro.

Processo:

A Coordenadora Administrativa seleciona no menu Cadastro qual item será cadastrado. Será aberto um formulário, referente ao item que será cadastrado, onde a coordenadora ira digitar os dados necessários.

142

Terminação:

Esse caso de uso se encerra quando a Coordenadora confirma o cadastramento do usuário, ou então, quando resolve cancelar o cadastramento, cancelando a operação.

Exceções:

Os dados disponíveis para cadastrar o usuário não são suficientes para completar o cadastro.

Interface Gráfica do Caso de Uso Cadastrar Usuários.

143

11.11.1 – Descrição do Cenário do Caso de Uso Cadastrar Usuários.


A Coordenadora acessa a tela de cadastro desejada.

È aberta à tela para a inserção dos dados.

A Coordenadora solicita os dados para efetuar o cadastro.

A Coordenadora clica no botão salvar.

Os dados são gravados.

È exibida uma mensagem confirmando a inserção dos dados no

sistema.

Cenário com Exceção para inserção: O sistema verifica que os dados não são consistentes

A Coordenadora acessa a tela de cadastro desejada.

È aberta à tela para a inserção dos dados.

A Coordenadora solicita os dados para efetuar o cadastro.

A Coordenadora clica no botão salvar.

O sistema verifica que os dados não são consistentes

É exibida uma mensagem de erro ao funcionário

A tela para a inserção dos dados é novamente disponibilizada para que o funcionário corrija os dados.





A Coordenadora abre o formulário de cadastro.

A Coordenadora seleciona o cadastro a ser alterado.

A Coordenadora altera os dados.

144

A Coordenadora confirma alteração.


Cadastro do usuário não existe.




A Coordenadora seleciona o usuário a ser excluído.

Sistema verifica se existe relação com o usuário.





A Coordenadora seleciona o usuário a ser excluído.

Sistema verifica que existe relação com o usuário.


Sistema inativa o usuário.

145

11.11.2 – Diagrama de Atividade do Caso de Uso Cadastrar Usuários

146

11.11.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Usuários.

147

11.11.4 – Diagrama de Classes – tela_cadastro_usuario.

148

11.11.5 – Diagrama de Estado – tela_cadastro_usuário (incluir)

149

11.11.6 – Diagrama de Estado – tela_cadastro_usuário (editar)

150

11.11.7 – Diagrama de Estado – tela_cadastro_usuario (inativar)

151

11.12 – Descrição do Caso de Uso Emitir Relatórios


Identificador do Caso de Uso: Emitir Relatórios


Autor do Caso de Uso: Rafaela Chirita da Silva


Atores:

Iniciadores: Funcionário

Colaboradores:

Resumo: Esse caso de uso tem por finalidade emitir relatórios com base nas movimentações realizadas pelo sistema.

Casos de Uso Referenciados: Efetuar Login.

Pré-Condições: Possuir movimentações e cadastros realizados e gravados através do sistema

Pós-Condições: Relatórios impressos de forma satisfatória.


Inicialização:

O caso de uso se inicia após quando o funcionário clicar no menu relatórios

Processo:

O funcionário selecionará o tipo o relatório necessário e após, clicará no botão gerar relatório, ficando disponível a possibilidade de visualização na tela ou impressão

Terminação:

Esse caso de uso termina quando o relatório é impresso.

152

Exceções:

Não existirem dados a ser listados, dentro das especificações que o funcionário digitou.

Interface Gráfica do Caso de Uso Emitir Relatórios

153

11.12.1 – Relatório de Atendimento

154

11.12.2– Relatório de Exames Solicitados

155

11.12.3 – Relatório de Solicitações de Consulta

156

11.12.4 – Relatório de Listagem de Medicamentos

157

11.12.5 – Relatório de Listagem de Categorias

158

11.12.6 – Descrição do Cenário do Caso de Uso Emitir Relatórios

Cenário Ótimo:

O funcionário acessa o menu RelatóriosO funcionário seleciona o relatório desejadoO sistema busca as informações necessáriasO sistema imprime o relatório desejado

Exceção:

Não existe nenhuma informação cadastrada que atenda a solicitação do funcionário

Cenário Ótimo com Exceção:

O funcionário acessa o menu RelatóriosO funcionário seleciona o relatório desejadoO sistema busca as informações necessáriasNão existe nenhuma informação cadastrada que atenda a solicitação do funcionárioO sistema emite uma mensagem informando que não existem dados a serem impressos.

159

11.12.7 – Diagrama de Atividade para o Caso de Uso Emitir Relatórios

160

11.12.8 – Diagrama de Seqüência para o Caso de Uso Emitir Relatório

161

11.12.9 – Diagrama de Classes – tela_relatorios

162

11.12.10 – Diagrama de Estado – tela_relatorios

163

11.13 – Descrição do Caso de Uso Cadastrar Medicamentos


Identificador do Caso de Uso: Cadastrar Medicamentos


Autor do Caso de Uso: Leandro Silva


Atores:

Iniciadores: Farmacêutica.

Colaboradores: Paciente, Farmacêutica.

Resumo: Esse caso de uso é o momento onde a farmacêutica irá cadastrar todos os novos medicamentos disponíveis pela UMS. Esses novos medicamentos só poderão ser cadastrados quando o mesmo estiver à disposição da unidade, ou do médico.

Casos de Uso Referenciados: Controlar Medicamentos.

Pré-Condições: Possuir novos medicamentos para cadastro.

Pós-Condições: Estoque atualizado. Medicamento disponível para o médico receitar.


Inicialização:

Esse caso de uso se inicia quando a farmacêutica possuir novos medicamentos para serem cadastrados.

164

Processo:

A partir do momento que a unidade estiver à disposição dos novos medicamentos, a farmacêutica ira cadastrar os mesmos em suas respectivas categorias, podendo assim ser receitados pelo médico.

Terminação:

Esse caso de uso se encerra quando a farmacêutica termina de cadastrar todos os medicamentos necessários, atualizando o estoque da unidade.

Exceções:

Não se aplicam.

165

Interface Gráfica do Caso de Uso Cadastrar Medicamentos.

166

11.13.1 – Descrição do Cenário do Caso de Uso Cadastrar Medicamentos.


A farmacêutica verifica a necessidade de cadastrar novos medicamentos

A farmacêutica cadastra os novos medicamentos existentes no sistema.

A farmacêutica atualiza o estoque.


A farmacêutica seleciona o medicamento a ser alterado.

A farmacêutica altera os dados.



Medicamento a ser alterado não existe.



A farmacêutica seleciona o medicamento a ser excluído.

Sistema verifica se existe relação com o medicamento.



167


A farmacêutica seleciona o medicamento a ser excluído.

Sistema verifica que existe relação com o medicamento.



Sistema inativa o medicamento.

168

11.13.2 – Diagrama de Atividades do Caso de Uso Cadastrar Medicamentos.

169

11.13.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Medicamentos.

170

11.13.4 – Diagrama de Classes – tela_cadastra_medicamento

171

11.13.5 – Diagrama de Estado – tela_cadastra_medicamento (incluir)

172

11.13.6 – Diagrama de Estado – tela_cadastra_medicamento (editar)

173

11.13.6 – Diagrama de Estado – tela_cadastra_medicamento (excluir)

174

11.14 – Descrição do Caso de Uso Cadastrar Exames


Identificador do Caso de Uso: Cadastrar Exames




Atores:

Iniciadores: Médico.

Colaboradores: Paciente, Médico.

Resumo: Esse caso de uso é o momento onde o Médico irá cadastrar todos os exames disponíveis pela UMS. Quando não houver disponível o paciente é encaminhado para outro lugar.


Pré-Condições: Possuir exames para cadastro.

Pós-Condições: Exames atualizado. Exame disponível para o médico.


Inicialização:

Esse caso de uso se inicia quando o médico possuir novos exames para serem cadastrados.

Processo:

A partir do momento que a unidade estiver à disposição dos novos exames, o médico ira cadastrar os mesmos, podendo assim ser receitados.

175

Terminação:

Esse caso de uso se encerra quando o médico termina de cadastrar todos os exames necessários.

Exceções:

Não se aplicam.

Interface Gráfica do Caso de Uso Cadastrar Exames.

176

11.14.1 – Descrição do Cenário do Caso de Uso Cadastrar Exames.


O Médico verifica a necessidade de cadastrar novos exames.

O Médico cadastra os novos exames existentes no sistema.

O Médico atualiza o cadastro de exames.


O Médico seleciona o exame a ser alterado.

O Médico altera os dados.

O Médico atualiza o sistema.


Exame a ser alterado não existe.



O Médico seleciona o exame a ser excluído.

Sistema verifica se existe relação com o exame.




177

O Médico seleciona o exame a ser excluído.

Sistema verifica que existe relação com o exame.



Sistema inativa o exame.

178

11.14.2 – Diagrama de Atividades do Caso de Uso Cadastrar Exames.

180

11.14.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Exames.

181

11.14.4 – Diagrama de Classes – tela_cadastro_exames.

182

11.14.5 – Diagrama de Estado – tela_cadastro_exames (incluir).

183

11.14.6 – Diagrama de Estado – tela_cadastro_exames (editar).

184

11.14.7 – Diagrama de Estado – tela_cadastro_exames (excluir).

185

11.15 – Descrição do Caso de Uso Cadastrar Tipos de Medica-mentos


Identificador do Caso de Uso: Cadastrar Tipos de Medicamentos




Atores:

Iniciadores: Farmacêutica.

Colaboradores: Paciente, Farmacêutica.

Resumo: Esse caso de uso é o momento onde a farmacêutica irá cadastrar todos os tipos de medicamentos disponíveis pela UMS. Esses novos tipos de medicamentos só poderão ser cadastrados quando o mesmo estiver à disposição da unidade, ou do médico.


Pré-Condições: Possuir novos tipos de medicamentos para cadastro.

Pós-Condições: Estoque atualizado. Medicamento disponível para o médico receitar.


Inicialização:

Esse caso de uso se inicia quando a farmacêutica possuir novos tipos de medicamentos para serem cadastrados.

186

Processo:

A partir do momento que a unidade estiver à disposição dos novos tipos de medicamentos, a farmacêutica ira cadastrar os mesmos em suas respectivas categorias, podendo assim ser receitados pelo médico.

Terminação:

Esse caso de uso se encerra quando a farmacêutica termina de cadastrar todos os tipos de medicamentos necessários, atualizando o estoque da unidade.

Exceções:

Não se aplicam.

Interface Gráfica do Caso de Uso Cadastrar Tipos de Medicamentos.

187

11.15.1 – Descrição do Cenário do Caso de Uso Cadastrar Tipos de Medicamentos.


A farmacêutica verifica a necessidade de cadastrar novos tipos de medicamentos

A farmacêutica cadastra os novos tipos de medicamentos existentes no sistema.



A farmacêutica seleciona o tipo de medicamento a ser alterado.

A farmacêutica altera os dados.



Tipo de Medicamento a ser alterado não existe.



A farmacêutica seleciona o tipo de medicamento a ser excluído.

Sistema verifica se existe relação com o tipo de medicamento.



188


A farmacêutica seleciona o tipo medicamento a ser excluído.

Sistema verifica que existe relação com o tipo de medicamento.



Sistema inativa o tipo de medicamento.

189

11.15.2 – Diagrama de Atividades do Caso de Uso Cadastrar Tipos de Medicamentos.

190

11.15.3 – Diagrama de Seqüência do Caso de Uso Cadastrar Tipos de Medicamentos.

191

11.15.4 – Diagrama de Classes – tela_cadastro_tipo_medicamento.

192

11.15.5 – Diagrama de Estados – tela_cadastro_tipo_medicamento (incluir).

193

11.15.6 – Diagrama de Estados – tela_cadastro_tipo_medicamento (editar).

194

11.15.7 – Diagrama de Estados – tela_cadastro_tipo_medicamento (excluir).

195

11.16 – Diagrama de Classes – SGBD

196

12 – Modelo de Dados

12.1 – Diagrama Entidade Relacionamento (DER)

197

12.2 – Modelo Entidade Relacionamento (MER)

198

12.2.1 – Considerações sobre o MER

No relacionamento da tabela usuário com entidade, a cardinalidade correta

seria 0,1, tendo em vista que nem toda entidade do sistema é necessariamente

um usuário, por exemplo, funcionários da equipe de limpeza, motoristas, etc.

No relacionamento das tabelas: consulta_odontológica, procedimento e

procedimento_odontologico, a tabela procedimento_odontologico é a tabela

resultante do relacionamento (N,N) entre as tabelas consulta_odontologica e

procedimento.

No relacionamento das tabelas entidade, escala e itens_escala, a tabela

itens_escala é a tabela resultante do relacionamento (N,N) entre as tabelas

entidade e escala.

No relacionamento das tabelas consulta_medica, exames e consulta_exames,

a tabela consulta_exames é a tabela resultante do relacionamento (N,N) entre

as tabelas consulta_medica e exames.

No relacionamento das tabelas prescricao e medicamento, a cardinalidade

correta seria (0,1), tendo em vista que nem sempre uma prescrição médica

precisa ser um medicamento, podendo ser somente uma orientação.

Não foi possível fazer a representação correta em nossos diagramas devido à

restrições encontradas com a ferramenta que utilizamos para fazer a

modelagem (DBDesigner).

199

12.2 – Modelo Físico dos Dados

200

13. Diagrama de Componentes

201

14. Diagrama de Implementação

202

15. Projeto de Testes

O projeto de teste de um software é uma das atividades de suma importância

no ciclo do desenvolvimento. Tem por objetivo identificar falhas e possibilitar as

devidas correções, antes da entrega do produto final ao usuário.

O teste de um software consiste numa rotina exaustiva de testes de validação

de dados, consistência de campos, verificação de desempenho, estabilidade e

confiabilidade do software.

Todo projeto, por mais bem elaborado, sempre possui falhas e para tanto, um

teste bem sucedido é aquele que consegue identificar essas falhas, aquele que

revela o erro que não foi previsto pela equipe de desenvolvimento.

Um teste de software deve conter vários aspectos, dentre eles:

Iniciar-se ao nível dos módulos e contemplar, posteriormente, a

integração entre os diversos módulos do sistema;

Deve atender a pontos específicos do software. Sendo assim, um

mesmo teste não pode ser aplicado no projeto todo, devendo cada

módulo conter os testes específicos a ele.

Deve, preferencialmente, ser realizada por uma equipe diferente da

equipe de desenvolvimento. Essa indicação visa minimizar problemas

com os “vícios” do programador, que já está habituado a rotina e

dificilmente terá uma visão crítica e diferente do sistema, a ponto de

poder localizar falhas.

A fase de treinamento dos usuários também pode ser incorporada a fase dos

testes do sistema. Isso possibilita, inclusive, diminuir custos com a equipe de

testes. O usuário é um ótimo “testador” do software, pois é ele quem sabe

exatamente o que o sistema deve fazer. É sempre aconselhável incluí-lo na

etapa de testes.

Uma seqüência de itens deve ser observada para garantir a qualidade do

produto final. Esses itens provenientes da fase de levantamento de requisitos

203

do software. Uma vez identificadas as funcionalidades que o sistema deverá

atender, deve-se ter o cuidado constante de garantir que esses requisitos

funcionem da melhor forma possível. Para poder mensurar esse padrão de

qualidade, alguns itens a ser seguidos podem ser:

1. Exatidão: Verifica se todo o sistema está atendendo às especificações

propostas pelo cliente;

2. Confiabilidade: Verifica se o sistema está processando as informações

de maneira adequada, garantindo a confiabilidade das saídas das

informações;

3. Eficiência: Verifica se o sistema está utilizando, da melhor forma, os

recursos necessários para funcionar adequadamente.

4. Integridade: Verifica se o sistema garante que, somente usuários

habilitados possam efetuar determinadas transações e que os acessos

indevidos serão bloqueados.

5. Usabilidade: Verifica se o sistema possui uma interface amigável e

intuitiva, possibilitando ao usuário um melhor conforto durante a

utilização do software, se os recursos necessários estão dispostos de

maneira fácil e simples;

6. Manutenibilidade: Verifica o esforço necessário para prover a

manutenção do sistema. Se esse esforço for mínimo, significa que sua

manutenibilidade é boa.

7. Flexibilidade: Verifica o esforço necessário para promover adaptações

no sistema.

8. Portabilidade: Verifica se o sistema pode ser utilizado em várias

plataformas;

9. Reusabilidade: Verifica se o sistema foi projetado de forma a

proporcionar a reutilização de trechos de códigos em outros módulos ou

mesmo outros sistemas.

204

10. Interoperabilidade: Verifica o esforço necessário para acoplar o sistema

a outros sistemas, possibilitando o trabalho em conjunto de vários

sistemas;

A soma de todos esses itens pode fornecer um panorama mais detalhado da

garantida da qualidade do produto final.

Também é objetivo dessa observação, prover meios para aprimorar o padrão

de qualidade, numa busca constante pela melhoria do produto. A satisfação

futura do cliente pode ser previamente mensurada pelos fatores acima

expostos, pois, se eles não trouxerem bons resultados, dificilmente o usuário

final do sistema ficará satisfeito. Essa análise faz parte da métrica do sistema,

ou seja, um conjunto de medidas que visam fornecer os indicadores

necessários para desenvolver um produto adequado.

Após a definição dos critérios e quais são os fatores que influenciam

diretamente a qualidade do produto de software, deve-se elaborar um plano de

testes. O plano de teste deve conter o propósito do testes e os resultados que

são esperados com a realização desses testes.

Abaixo encontram-se alguns pontos a serem observados na realização de

testes de software:

1. Casos de testes: É um conjunto de testes, orientações para sua

execução e resultados esperados. Normalmente esses casos de testes

saem dos documentos de requisitos, dos casos de uso ou códigos do

projeto.

2. Procedimento de testes: São instruções detalhadas para a avaliação de

um caso de teste. Um procedimento de teste pode avaliar desde uma

parte de um caso de teste até vários casos de teste juntos.

3. Classes de testes e componentes: Indicam as classes e os

componentes que interagem com o teste a ser realizado;

205

4. Colaboração de testes: Representam todos os materiais que podem

auxiliar na elaboração dos testes, por exemplo, diagramas de seqüência,

atividade, fluxos de mensagens, etc.

5. Testes de configuração: Asseguram requisitos mínimos do hardware

para que o software funcione adequadamente.

6. Testes de compatibilidade: Identifica possíveis falhas provenientes da

integração do sistema com outros sistemas;

7. Testes de conformidade: Verifica se o sistema está agindo em

conformidade com padrões mundiais estabelecidos, caso esses existam;

8. Testes de funcionalidade: Verifica se o que foi desenvolvido foi

exatamente o que foi solicitado pelo cliente.

9. Teste de performance: Analisa o desempenho do sistema;

10.Testes de Segurança: Verifica se o sistema provê segurança, se

proporciona integridade das informações;

11.Testes de Stress: Verifica a carga máxima que o sistema suporta. Visa

garantir que o sistema suportará uma grande quantidade de dados;

12.Testes de aceitação: É a homologação do sistema, onde o usuário

registra formalmente, o aceite ou não do produto desenvolvido.

Abaixo, colocamos os testes que foram realizados no sistema UMS – Rafard

Formulário: Cadastro de Profissionais (Médicos, Enfermeiros e Funcionários)

# Teste Resultado esperado Resultado real Status

01 Abrir formulário de Cadastro dos Profissionais.

Abertura do formulário de cadastro

Formulário aberto OK

02 Clicar no botão inserir novo registro

Habilitação dos campos para a inserção dos registros

Campos habilitados OK

206

03 Clicar no botão de “Salvar”, sem inserir os dados obrigatórios

Efetuar a consistência dos campos de preenchimento obrigatórios

O sistema não permitiu a gravação do registro sem os campos obrigatórios

OK

04 Aplicar o filtro de pesquisa para localizar registros já cadastrados

Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)

Filtragem dos resultados de forma correta

OK

05 Clicar no botão “Editar”, para modificar um registro já inserido

Habilitação dos campos para a modificação dos registros e realização das consistências necessárias

Campos habilitados de forma adequada e consistências efetuadas

OK

06 Clicar no botão de “Excluir” o registro.

Exibição de uma mensagem de confirmação e efetiva exclusão

A mensagem foi exibida. Se clicado na opção “não”, a operação foi cancelada e quando clicado em “sim”, o registro foi excluído

OK

Formulário: Cadastro de Pacientes


01 Abrir formulário de Cadastro dos Pacientes



02 Clicar no botão inserir novo paciente






OK




OK


Habilitação dos campos para a modificação dos registros e realização das consistências


OK

207

necessárias




OK

Formulário: Cadastro de Medicamentos


01 Abrir formulário de Cadastro de Medicamentos.



02 Clicar no botão inserir novo medicamento






OK

04 Clicar no ícone de atalho para o cadastro de tipo de medicamento

Abertura do cadastro de tipo de medicamento

Cadastro de tipos de medicamentos abertos

OK




OK




OK




OK

208

Formulário: Cadastro de Tipo de Medicamentos


01 Abrir formulário de Cadastro de Tipo de Medicamentos.



02 Clicar no botão inserir novo tipo de medicamento






OK




OK




OK



Tela não foi aberta Reprovado

Formulário: Cadastro de Usuários


01 Abrir formulário de Cadastro de usuários



02 Clicar no botão inserir novo usuário




Efetuar a consistência dos campos de preenchimento

O sistema não permitiu a gravação do

OK

209

obrigatórios registro sem os campos obrigatórios




OK




OK




Formulário: Cadastro de Exames


01 Abrir formulário de Cadastro de Exames

Abertura do formulário de Exames


02 Clicar no botão inserir novo exame






OK




OK



A mensagem foi exibida. Se clicado na opção “não”, a operação foi cancelada e quando clicado em

OK

210

“sim”, o registro foi excluído




Formulário: Solicitação de Consulta (Atendimento balcão)


01 Abrir formulário de Solicitação de Consulta

Abertura do formulário da Solicitação da Consulta








OK




OK


Exibição de uma mensagem de confirmação e efetiva exclusão. A exclusão somente será permitida se não houverem registros relacionados


OK



Filtragem efetuada satisfatoriamente

OK

07 Aplicar o filtro de pesquisa para localizar o nome do paciente



OK

08 Aplicar o filtro de pesquisa para localizar o nome do médico

Filtragem correta pelos critérios estabelecidos (código, nome e parte


OK

211

do nome)

09 Aplicar o filtro de pesquisa para localizar o nome do atendente



OK

Formulário: Atendimento Pré-Consulta


01 Abrir formulário de Pré- Consulta

Abertura do formulário de Pré-Consulta





OK


Habilitação dos campos para a modificação dos registros e realização das consistências necessárias. Alterações somente podem ser realizadas até a consulta ser concluída.

Campos habilitados de forma adequada e consistências efetuadas. Mesmo que nada seja modificado, o sistema pede a inclusão do campo auxiliar de enfermagem e fala que existem registros na aba geral para serem salvos. Logo após, ocorre uma mensagem de erro. Mesmo após a confirmação da consulta, foi possível editar o registro.

Reprovado


Exibição de uma mensagem de confirmação e efetiva exclusão. A exclusão somente será permitida se não houverem registros relacionados


OK

05 Aplicar o filtro de pesquisa para localizar registros já

Filtragem correta pelos critérios estabelecidos

Filtragem efetuada OK

212

cadastrados (código, nome e parte do nome)

satisfatoriamente

07 Aplicar o filtro de pesquisa para localizar solicitações de consultas pendentes e já finalizadas

Filtragem correta pelos critérios estabelecidos


OK

Formulário: Atendimento Consulta


01 Abrir formulário de Consulta

Abertura do formulário de consulta


02 Clicar na aba Consulta para iniciar o procedimento

Tela da consulta aberta e campos prontos para receber os dados

A tela foi aberta e os dados inseridos com sucesso

OK

03 Clicar no botão Pré-Consulta para poder visualizar os dados do procedimento

Abertura da tela e exibição dos dados da pré-consulta realizada

Tela aberta corretamente e dados exibidos

OK

04 Clicar no botão Exames Abertura da tela para que o médico possa solicitar os exames

Ocorreu um erro de tipo de campo

Reprovado

05 Clicar no botão histórico Exibição das consultas anteriores do paciente

Não foi exibido adequadamente o registro dos textos inseridos nas consultas anteriores

Reprovado

06 Clicar no botão Prescrição Abertura da tela de prescrição de medicamentos. Possibilita a inclusão de medicamentos já cadastrados ou a inclusão de novos, que não constam em estoque

Os medicamentos que estão no estoque foram incluídos corretamente, porém, os que foram digitados manualmente ocasionam no sistema um erro de “key violation”

Reprovado

07 Clicar no botão de encaminhamento

Abertura da tela onde o médico preencherá o formulário de encaminhamento do paciente e preenchimento dos dados

Formulário aberto e dados inseridos com sucesso

OK

213

08 Edição de registros da pré-consulta

Tentar modificar um registro incluído na pré-consulta

Modificação não permitida

OK

09 Edição de registros do histórico do paciente

Tentar modificar um registro do histórico

Modificação não permitida

OK

10 Pesquisa de medicamentos por código

Filtrar os medicamentos da farmácia pelo código

Filtragem não efetuada

Reprovado

11 Pesquisa de medicamentos pelo nome

Filtrar os medicamentos da farmácia pelo nome


12 Pesquisa de medicamentos por partes do nome

Filtrar os medicamentos da farmácia por partes do nome


13 Selecionar a opção de exclusão da consulta

Verificar se a consulta está finalizada. Caso esteja, não permitir a exclusão, porém, se ainda estiver em aberto, permitir a exclusão

Exclusão não efetuada em nenhuma das circunstâncias

Reprovado

15 Selecionar filtro de consulta por status

Mostrar, de acordo com o filtro selecionado, as consultas em aberto e finalizadas

Filtragem ocorrida com sucesso

Reprovado

16 Filtrar consulta por nome do paciente

Mostrar as consultas já realizadas por um determinado paciente

Filtragem não ocorrida

Reprovado

17 Clicar no botão finalizar consulta

Finalização da consulta, não permitindo nenhum tipo de alteração posterior

Permite alteração em campos após a finalização da consulta

Reprovado

Formulário: Movimentação de Medicamentos


01 Abrir formulário de Movimentação de Medicamentos

Abertura do formulário da Movimentação de Medicamentos





214




OK




OK


Exibição de uma mensagem de confirmação e efetiva exclusão.

O Registro foi excluído, porém os dados continuam aparecendo na parte inferior da tela

Reprovado

06 Incluir uma baixa que resulte em estoque negativo

O sistema não permitir a baixa

A baixa foi incluída com sucesso, gerando um estoque negativo

Reprovado

Formulário: Cadastro de Nível de Acesso


01 Abrir a tela de nível de acesso

Abertura da tela A tela foi aberta corretamente

OK

02 Selecionar um usuário para atribuir suas permissões

Usuário selecionado, permitindo a inclusão das permissões

Ocorreu um erro ocasionando o travamento do sistema

Reprovado

Formulário: Atendimento Ambulatorial


01 Abrir formulário de Atendimento Ambulatorial

Abertura do formulário do Atendimento Ambulatorial


02 Clicar no botão inserir novo atendimento

O sistema deverá retornar o resultado da consulta, com a prescrição passada pelo médico ao paciente

Esse procedimento não está sendo realizado

Reprovado

Formulário: Tela Login


215

01 Abrir tela de login Abertura da tela de login


02 Clicar no botão entrar sem a digitação do login e senha

Sistema impedir o login Sistema impediu o login

OK

03 Fazer login com usuário e senha inexistentes

Sistema impedir o login Sistema não impediu o login

Reprovado

A realização dos testes no sistema UMS foi feita juntamente com a fase de

desenvolvimento. Constantemente a equipe se subdividia para realizar os

testes nos módulos desenvolvidos e procurar por falhas.

Infelizmente não houve tempo hábil para instalar o sistema, em caráter

experimental, na Unidade Mista de Saúde do município, antes da entrega final

do projeto. Certamente esse procedimento auxiliaria muito na identificação de

falhas ocorridas na fase de desenvolvimento.

Os erros acima apontados foram devidamente corrigidos após a identificação

das falhas.

216

16 – Anexos

16.1 – Formulário de Encaminhamento (Anexo I)

217

16.2 – Formulário de Pedido de Exames (Anexo II)

218

16.3 – Termo de Sigilo Profissional (Anexo III)

219

10 · web viewelaborar telas simples, seguindo os padrões de design e usabilidade, identificando...

Documents