10 · Web viewElaborar telas simples, seguindo os padrões de design e usabilidade, identificando...
Transcript of 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.2.5 – Estratégia de Mitigação..............................................................................................................35
7.2.6 – Plano de contingência.................................................................................................................35
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.3.5 – Estratégia de Mitigação..............................................................................................................36
7.3.6 – Plano de contingência.................................................................................................................37
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.4.5 – Estratégia de Mitigação..............................................................................................................38
7.4.6 – Plano de contingência.................................................................................................................39
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.5.5 – Estratégia de Mitigação..............................................................................................................40
7.5.6 – Plano de contingência.................................................................................................................41
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
7.6.5 – Estratégia de Mitigação..............................................................................................................42
7.6.6 – Plano de contingência.................................................................................................................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.5 – Estratégia de Mitigação..............................................................................................................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.5 – Estratégia de Mitigação..............................................................................................................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
Entrevistador: Leandro e André
Entrevistada: Maria do Socorro
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
Entrevistador: Leandro e André
Entrevistada: Maria do Socorro
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
Entrevistador: Leandro e André
Entrevistada: Maria do Socorro
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
Entrevistador: Leandro e André
Entrevistada: Maria do Socorro
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.1 – MagnitudeAlta
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.1 – MagnitudeAlta
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.1 – MagnitudeAlta
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.1 – MagnitudeAlta
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Cadastrar Entidades
Número do Caso de Uso: 2
Autor do Caso de Uso: Leandro da Silva
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 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.
Fluxo de Execução Básico:
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 funcionário 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 usuário corrija os dados.
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 Ó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 abre o formulário de cadastro.
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 abre o formulário de cadastro.
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Solicitar Consulta
Número do Caso de Uso: 3
Autor do Caso de Uso: André Luís Belini
Número da Versão do Caso de Uso: 1
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.
Fluxo de Execução Básico:
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
Cenário Ótimo para inserção:
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
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.
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 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 Ótimo para edição:
Atendente abre o formulário de cadastro.
Atendente seleciona a solicitação a ser alterada.
Atendente altera os dados.
Atendente confirma alteração.
Cenário com exceção edição:
Solicitação de consulta não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo para exclusão:
Atendente abre o formulário de cadastro.
Atendente seleciona a solicitação a ser excluída.
Sistema verifica se existe relação com a solicitação.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
Cenário com exceção exclusão:
Atendente abre o formulário de cadastro.
79
Atendente seleciona a solicitação a ser excluída.
Sistema verifica que existe relação com a solicitação.
Sistema retorna que não há possibilidade de exclusã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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Realizar Pré-Consulta
Número do Caso de Uso: 4
Autor do Caso de Uso: André Luís Belini
Número da Versão do Caso de Uso: 1
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
Fluxo de Execução Básico:
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
Cenário Ótimo para inserção:
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.
Cenário Ótimo para edição:
Enfermeira abre o prontuário do paciente.
Enfermeira seleciona o prontuário ser alterado.
Enfermeira altera os dados.
Enfermeira confirma alteração.
89
Cenário com exceção edição:
Prontuário do paciente não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo exclusão:
Enfermeira abre o prontuário do paciente.
Enfermeira seleciona o prontuário a ser excluído.
Sistema verifica se existe relação com a pré-consulta.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
Cenário com exceção exclusão:
Enfermeira abre o prontuário do paciente.
Enfermeira seleciona o prontuário a ser excluído.
Sistema verifica que existe relação com a pré-consulta.
Sistema retorna que não há possibilidade de exclusão.
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Realizar Consulta Médica
Número do Caso de Uso: 5
Autor do Caso de Uso: André Luís Belini
Número da Versão do Caso de Uso: 1
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
Fluxo de Execução Básico:
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
Cenário Ótimo inserção:
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
Cenário com exceção edição:
Consulta do paciente não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo exclusão:
Médico abre a consulta do paciente.
Médico seleciona a consulta a ser excluída.
Sistema verifica se existe relação com a consulta.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
Cenário com exceção exclusão:
Médico abre a consulta do paciente.
Médico seleciona a consulta a ser excluída.
Sistema verifica que existe relação com a consulta.
Sistema retorna que não há possibilidade de exclusão.
Sistema informa o procedimento a ser tomado.
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Emitir Pedido de Exames
Número do Caso de Uso: 6
Autor do Caso de Uso: Rafaela Chirita da Silva
Número da Versão do Caso de Uso: 1
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.
Fluxo de Execução Básico:
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
Cenário Ótimo inserção:
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.
Cenário Ótimo edição:
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.
Cenário com exceção edição:
Pedido de exame do paciente não existe.
Campos obrigatórios não preenchidos.
109
Cenário Ótimo exclusão:
Médico abre o pedido de exame do paciente.
Médico seleciona o pedido de exame a ser excluído.
Sistema verifica se existe relação com o pedido de exame.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
Cenário com exceção exclusão:
Médico abre o pedido de exame do paciente.
Médico seleciona o pedido de exame a ser excluído.
Sistema verifica que existe relação com o pedido de exame.
Sistema retorna que não há possibilidade de exclusão.
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Atendimento Ambulatorial.
Número do Caso de Uso: 7
Autor do Caso de Uso: Leandro da Silva
Número da Versão do Caso de Uso: 1
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,
Fluxo de Execução Básico:
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
Cenário Ótimo inserção:
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
Número do Caso de Uso: 8
Auto do Caso de Uso: Fábio Lima
Número da Versão do Caso de Uso: 1
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.
Fluxo de Execução Básico:
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
Cenário Ótimo inserção:
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.
Atendimento concluído.
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.
Atendimento concluído.
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
130
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Cadastrar Nível de Acesso
Número do Caso de Uso: 9
Autor do Caso de Uso: Fábio Lima
Número da Versão do Caso de Uso: 2
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.
Fluxo de Execução Básico:
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
Cenário Ótimo para inserção:
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Cadastrar Usuários
Número do Caso de Uso: 10
Autor do Caso de Uso: Leandro
Número da Versão do Caso de Uso: 1
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.
Fluxo de Execução Básico:
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.
Cenário Ótimo para inserção:
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.
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 Ótimo para edição:
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.
Cenário com exceção edição:
Cadastro do usuário não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo para exclusão:
A Coordenadora abre o formulário de cadastro.
A Coordenadora seleciona o usuário a ser excluído.
Sistema verifica se existe relação com o usuário.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
Cenário com exceção exclusão:
A Coordenadora abre o formulário de cadastro.
A Coordenadora seleciona o usuário a ser excluído.
Sistema verifica que existe relação com o usuário.
Sistema retorna que não há possibilidade de exclusão.
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Emitir Relatórios
Número do Caso de Uso: 11
Autor do Caso de Uso: Rafaela Chirita da Silva
Número da Versão do Caso de Uso: 1
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.
Fluxo de Execução Básico:
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Cadastrar Medicamentos
Número do Caso de Uso: 11
Autor do Caso de Uso: Leandro Silva
Número da Versão do Caso de Uso: 1
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.
Fluxo de Execução Básico:
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.
Cenário Ótimo inserção:
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.
Cenário Ótimo edição:
A farmacêutica seleciona o medicamento a ser alterado.
A farmacêutica altera os dados.
A farmacêutica atualiza o estoque.
Cenário com exceção edição:
Medicamento a ser alterado não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo exclusão:
A farmacêutica seleciona o medicamento a ser excluído.
Sistema verifica se existe relação com o medicamento.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
167
Cenário com exceção exclusão:
A farmacêutica seleciona o medicamento a ser excluído.
Sistema verifica que existe relação com o medicamento.
Sistema retorna que não há possibilidade de exclusão.
Sistema informa o procedimento a ser tomado.
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Cadastrar Exames
Número do Caso de Uso: 12
Autor do Caso de Uso: Leandro Silva
Número da Versão do Caso de Uso: 1
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.
Casos de Uso Referenciados: Controlar Medicamentos.
Pré-Condições: Possuir exames para cadastro.
Pós-Condições: Exames atualizado. Exame disponível para o médico.
Fluxo de Execução Básico:
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.
Cenário Ótimo inserção:
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.
Cenário Ótimo edição:
O Médico seleciona o exame a ser alterado.
O Médico altera os dados.
O Médico atualiza o sistema.
Cenário com exceção edição:
Exame a ser alterado não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo exclusão:
O Médico seleciona o exame a ser excluído.
Sistema verifica se existe relação com o exame.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
Cenário com exceção exclusão:
177
O Médico seleciona o exame a ser excluído.
Sistema verifica que existe relação com o exame.
Sistema retorna que não há possibilidade de exclusão.
Sistema informa o procedimento a ser tomado.
Sistema inativa o exame.
178
179
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
Projeto: UMS - Rafard
Identificador do Caso de Uso: Cadastrar Tipos de Medicamentos
Número do Caso de Uso: 13
Autor do Caso de Uso: Leandro Silva
Número da Versão do Caso de Uso: 1
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.
Casos de Uso Referenciados: Controlar Medicamentos.
Pré-Condições: Possuir novos tipos de medicamentos para cadastro.
Pós-Condições: Estoque atualizado. Medicamento disponível para o médico receitar.
Fluxo de Execução Básico:
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.
Cenário Ótimo inserção:
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 atualiza o estoque.
Cenário Ótimo edição:
A farmacêutica seleciona o tipo de medicamento a ser alterado.
A farmacêutica altera os dados.
A farmacêutica atualiza o estoque.
Cenário com exceção edição:
Tipo de Medicamento a ser alterado não existe.
Campos obrigatórios não preenchidos.
Cenário Ótimo exclusão:
A farmacêutica seleciona o tipo de medicamento a ser excluído.
Sistema verifica se existe relação com o tipo de medicamento.
Sistema retorna que não há relação.
Exclusão efetuada com sucesso.
188
Cenário com exceção exclusão:
A farmacêutica seleciona o tipo medicamento a ser excluído.
Sistema verifica que existe relação com o tipo de medicamento.
Sistema retorna que não há possibilidade de exclusão.
Sistema informa o procedimento a ser tomado.
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
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Cadastro dos Pacientes
Abertura do formulário de cadastro
Formulário aberto OK
02 Clicar no botão inserir novo paciente
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
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
Campos habilitados de forma adequada e consistências efetuadas
OK
207
necessárias
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 Medicamentos
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Cadastro de Medicamentos.
Abertura do formulário de cadastro
Formulário aberto OK
02 Clicar no botão inserir novo medicamento
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
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 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
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
05 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
208
Formulário: Cadastro de Tipo de Medicamentos
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Cadastro de Tipo de Medicamentos.
Abertura do formulário de cadastro
Formulário aberto OK
02 Clicar no botão inserir novo tipo de medicamento
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
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 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
05 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
06 Aplicar o filtro de pesquisa para localizar registros já cadastrados
Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)
Tela não foi aberta Reprovado
Formulário: Cadastro de Usuários
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Cadastro de usuários
Abertura do formulário de cadastro
Formulário aberto OK
02 Clicar no botão inserir novo usuário
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
03 Clicar no botão de “Salvar”, sem inserir os dados obrigatórios
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
04 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
05 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
06 Aplicar o filtro de pesquisa para localizar registros já cadastrados
Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)
Tela não foi aberta Reprovado
Formulário: Cadastro de Exames
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Cadastro de Exames
Abertura do formulário de Exames
Formulário aberto OK
02 Clicar no botão inserir novo exame
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
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 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
05 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
OK
210
“sim”, o registro foi excluído
06 Aplicar o filtro de pesquisa para localizar registros já cadastrados
Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)
Tela não foi aberta Reprovado
Formulário: Solicitação de Consulta (Atendimento balcão)
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Solicitação de Consulta
Abertura do formulário da Solicitação da Consulta
Formulário aberto OK
02 Clicar no botão inserir novo exame
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
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 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
05 Clicar no botão de “Excluir” o registro.
Exibição de uma mensagem de confirmação e efetiva exclusão. A exclusão somente será permitida se não houverem registros relacionados
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
06 Aplicar o filtro de pesquisa para localizar registros já cadastrados
Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)
Filtragem efetuada satisfatoriamente
OK
07 Aplicar o filtro de pesquisa para localizar o nome do paciente
Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)
Filtragem efetuada satisfatoriamente
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
Filtragem efetuada satisfatoriamente
OK
211
do nome)
09 Aplicar o filtro de pesquisa para localizar o nome do atendente
Filtragem correta pelos critérios estabelecidos (código, nome e parte do nome)
Filtragem efetuada satisfatoriamente
OK
Formulário: Atendimento Pré-Consulta
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Pré- Consulta
Abertura do formulário de Pré-Consulta
Formulário aberto OK
02 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
03 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. 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
04 Clicar no botão de “Excluir” o registro.
Exibição de uma mensagem de confirmação e efetiva exclusão. A exclusão somente será permitida se não houverem registros relacionados
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
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
Filtragem efetuada satisfatoriamente
OK
Formulário: Atendimento Consulta
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Consulta
Abertura do formulário de consulta
Formulário aberto OK
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
Filtragem efetuada OK
12 Pesquisa de medicamentos por partes do nome
Filtrar os medicamentos da farmácia por partes do nome
Filtragem efetuada OK
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
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Movimentação de Medicamentos
Abertura do formulário da Movimentação de Medicamentos
Formulário aberto OK
02 Clicar no botão inserir novo exame
Habilitação dos campos para a inserção dos registros
Campos habilitados OK
214
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 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
05 Clicar no botão de “Excluir” o registro.
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
# Teste Resultado esperado Resultado real Status
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
# Teste Resultado esperado Resultado real Status
01 Abrir formulário de Atendimento Ambulatorial
Abertura do formulário do Atendimento Ambulatorial
Formulário aberto OK
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
# Teste Resultado esperado Resultado real Status
215
01 Abrir tela de login Abertura da tela de login
Formulário aberto OK
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