projeto-de-sistema-teleatendimento-medico

Prévia do material em texto

Projeto de Sistema:
Teleatendimento Médico
Gestão da Qualidade
Universidade Paulista (UniP)
37 pag.
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
 
 
UNIVERSIDADE PAULISTA - UNIP EaD 
 
Projeto Integrado Multidisciplinar VII 
 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistema 
 
 
 
 
 
IVAN ABILIO ALVES - 0576149 
PATRICK GONÇALVES – 0589972 
PEDRO GALASSI JANUÁRIO - 0583529 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Projeto de Sistema: Teleatendimento Médico 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SOBRADINHO - DF 
2021
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
 
 
IVAN ABILIO ALVES - 0576149 
PATRICK GONÇALVES – 0589972 
PEDRO GALASSI JANUÁRIO - 0583529 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Projeto de Sistema: Teleatendimento Médico 
 
 
 
 
 
 
 
 
 
 
 
Projeto Integrado Multidisciplinar para 
obtenção do título de tecnólogo em 
Análise e Desenvolvimento de 
Sistemas apresentado à Universidade 
Paulista – UNIP EaD. Orientadora: 
Sandra Muniz Bozolan. 
 
 
 
 
 
 
 
 
 
SOBRADINHO – DF 
2021
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
 
 
RESUMO 
 
Diante da problemática causada pela pandemia do Covid-19, o Hospital pretende 
implantar um sistema de teleatendimento, para contribuir com a segurança tanto dos 
seus profissionais e clientes, quanto da população local, pois com esse sistema, pode-
se gerenciar quais atendimentos realmente precisam ser realizados de forma 
presencial, ocasionando assim, em menos circulação de pessoas e 
consequentemente do vírus covid-19. Esse trabalho visa explicar a construção desse 
sistema, por uma Empresa de Software iniciante no mercado, chamada BugSoft, que 
atua na área de soluções baseadas em software. Levando em consideração as 
seguintes disciplinas com seus respectivos fundamentos: “Empreendedorismo”, na 
construção de um “modelo de negócios” para a empresa de software; “Projetos de 
Sistemas Orientados a Objetos”, com requisitos e casos de uso; “Gestão da 
Qualidade”, para a fabricação de um software com qualidade; e “Gerenciamento de 
Projetos de Software”, explicando os documentos fundamentais para uma empresa no 
momento de iniciar um projeto. Tudo isso, buscando evidenciar a importância dessas 
matérias na atual conjuntura mundial. 
 
Palavras-Chave: Empreendedorismo. Projetos de Sistemas Orientados a Objetos. 
Gestão da Qualidade. Sistema de Teleatendimento. Gerenciamento de Projetos de 
Software. 
 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
 
 
ABSTRACT 
 
In view of the problems caused by the Covid-19 pandemic, the Hospital intends to 
implement a teleservice system, to contribute to the safety of both its professionals 
and clients, as well as the local population, because with this system, it is possible to 
manage which services they really need be carried out in person, thus causing less 
circulation of people and consequently of the covid-19 virus. This work aims to 
explain the construction of this system, by a new Software Company in the market, 
called BugSoft, which operates in the area of software-based solutions. Taking into 
account the following disciplines with their respective foundations: 
“Entrepreneurship”, in the construction of a “business model” for the software 
company; “Object Oriented Systems Projects”, with requirements and use cases; 
“Quality Management”, for the manufacture of quality software; and “Software Project 
Management”, explaining the fundamental documents for a company when starting a 
project. All this, seeking to highlight the importance of these matters in the current 
world situation. 
 
Key words: Entrepreneurship. Object Oriented Systems Projects. Quality 
Management. Teleservice system. Software Project Management. 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
 
 
 SUMÁRIO 
 
 
INTRODUÇÃO ....................................................................................................................... 5 
1. EMPREENDORISMO ........................................................................................................ 6 
2. PROJETO DE SISTEMAS ORIENTADO A OBJETOS .................................................... 14 
2.1 REQUISITOS ................................................................................................................. 14 
2.1.1 REQUESITOS FUNCIONAIS ...................................................................................... 15 
2.1.2 REQUISITOS NÃO FUNCIONAIS .............................................................................. 15 
2.1.3 REQUISITOS DE NEGÓCIOS .................................................................................... 16 
2.2 DIAGRAMAS ................................................................................................................. 17 
2.2.1 DIAGRAMA DE CASO DE USO ................................................................................. 17 
2.2.2 DIAGRAMA DE ATIVIDADES ..................................................................................... 22 
2.2.3 DIAGRAMA DE CLASSES ......................................................................................... 23 
2.2.4 DIAGRAMA DE SEQUÊNCIA ..................................................................................... 23 
2.2.5 DIAGRAMA DE COMPONENTES E IMPLANTAÇÃO ................................................. 25 
3. GESTÃO DA QUALIDADE .............................................................................................. 25 
4. GERENCIAMENTO DE PROJETO DE SOFTWARE ....................................................... 31 
CONCLUSÃO ...................................................................................................................... 35 
 
 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
5 
 
INTRODUÇÃO 
 
Por conta da atual problemática causada pela pandemia do Covid-19, a 
telemedicina se tornou uma ferramenta de mister importância, pois sua prática 
compreende ao uso de tecnologias da informação na área da saúde para permitir o 
atendimento remoto. Assim, os profissionais de saúde podem evitar aglomerações 
nos hospitais ou até mesmo nos meios de transporte, gerenciando quais 
atendimentos podem ocorrer a distância. 
Além disso, também é interessante observar que os atendimentos remotos 
podem ajudar a diminuir a pressão nos sistemas de saúde, um dos principais pontos 
de preocupação dos 26 Manual de Estágio especialistas em relação a pandemias. 
Contudo, é bom lembrar que as últimas portarias do Ministério da Saúde, 
regulando sobre a telemedicina, descrevem que os atendimentos devem acontecer 
em um meio que garanta a integridade, a segurança e o sigilo de informações, bem 
como a necessidade de registro das consultas em prontuário clínico 
É nesse contexto que apresentamos um projeto de sistema de 
teleatendimento, encomendado por um hospital, que será realizado por uma nova 
empresa de software. 
 
 
 
 
 
 
 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
6 
 
1. EMPREENDORISMO 
 
Inicialmente, expomos o “Plano de Negócios”da empresa responsável pelo 
desenvolvimento do sistema de teleatendimento. 
 
 
 
 
Imagem 1 – Pág. 1 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
7 
 
 Imagem 2 – Pág. 2 do Plano de Negócios 
Imagem 3 – Pág. 3 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
8 
 
 Imagem 4 – Pág. 4 do Plano de Negócios 
Imagem 5 – Pág. 5 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Fonte: Próprio Autor (2021). 
Ivan Abilio – Gerente – Engenheiro TI 
Pedro Galassi – Desenvolvedor - ADS 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
9 
 
 
 Imagem 6 – Pág. 6 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
10 
 
 
 
 
Imagem 7 – Pág. 7 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
11 
 
 
Imagem 8 – Pág. 8 do Plano de Negócios 
Imagem 9 – Pág. 9 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
12 
 
 
Imagem 10 – Pág. 10 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
13 
 
 
 
Imagem 11 – Pág. 11 do Plano de Negócios 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
14 
 
Fonte: Análise de Requisitos. 
2. PROJETO DE SISTEMAS ORIENTADO A OBJETOS 
 
Usando como escopo conceitos de Projetos de Sistemas Orientados a 
Objetos, definiremos como esse sistema será construído, observando algumas 
regras para que o software tenha um padrão de qualidade esperado pelo Hospital. 
Além disso, também veremos a apresentação de diagramas para um melhor 
entendimento de como o software se relacionara e se comportara em seu 
funcionamento. 
 
2.1 REQUISITOS 
 
Canguçu (2021), explica que os requisitos não são apenas as funções que o 
software deve fazer, mas sim os objetivos, recursos e limitações desse software, 
assim o sistema também deve atender esses requisitos para atender as 
necessidades do contrato, padrão ou especificação do usuário. 
 Imagem 12 - Requisitos do Sistema 
 
 
 
 
 
 
 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
15 
 
2.1.1 REQUESITOS FUNCIONAIS 
 
Os requisitos funcionais se traduzem no que o software irá realizar 
externamente para atender as necessidades do cliente. Nesse sentido, Canguçu 
(2021) expõe que o requisito funcional se define pela necessidade, uma função de 
um aplicativo ou parte dele, sendo ele um conjunto de funcionalidades que vão 
compor o seu software. 
Dado o exposto, agora observemos os requisitos funcionais específicos do 
sistema de Reserva de Equipamentos solicitado pelo hospital. 
 
 
 
 
 
 
 
 
 
 
2.1.2 REQUISITOS NÃO FUNCIONAIS 
 
Por outro lado, também há os requisitos não funcionais, que estabelece como o 
software irá realizar a necessidade do cliente. Dessa forma, Alff (2018) conceitua esse 
requisito como uma restrição ao sistema, sendo ele responsável pela forma de como o 
sistema deve trabalhar. Assim, os requisitos não funcionais são sempre mensuráveis, 
consequentemente sendo possível verificar se ele está ou não sendo atendido pelo 
software. 
O sistema permitirá o cadastro de usuários externos(pacientes) e 
internos(profissionais). 
O cadastro do profissional interno exigira: nome, cpf e cargo. 
O sistema permitirá que o usuário interno visualize os dados do 
paciente. 
O sistema permitirá que os usuários realizem a marcação de 
atendimentos. 
O sistema exigirá que o usuário especifique qual atendimento necessita. 
O sistema notificará o usuário obtendo a confirmação do atendimento. 
O sistema atualizará a agenda do profissional de saúde. 
O sistema permitirá o cancelamento de atendimentos. 
Tabela 1 – Requisitos Funcionais do Projeto de Teleatendimento 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
16 
 
 Tabela 3 –Regras de Negócios do Projeto de Reservas de Equipamentos 
Vejamos os Requisitos Não Funcionais do Sistema de Teleatendimento 
solicitado pelo Hospital. 
 
2.1.3 REQUISITOS DE NEGÓCIOS 
 
Por último, mas não menos importante abordaremos sobre os Requisitos de 
Negócios ou então Regras de Negócios, que são regras que devem ser observadas 
pelos usuários no momento de usar o software. Conforme Ventura(2014), sistemas 
não existem sem regras de negócio e nem todas as regras de negócio são 
automatizadas através de um sistema. Desse modo, um sistema sem regras seria 
caótico, pois o usuário poderia fazer tudo a sua maneira, inexistindo um padrão, 
ocasionando em complicações para o software. Porém, nem toda Regra de Negócio 
é realizada por um sistema, existem procedimentos que geralmente não são 
automatizados via software. 
Analisemos agora as Regras de Negócios do Sistema de Reservas de 
Equipamentos. 
 
O software deve ser desenvolvido em uma linguagem de programação orientada a 
objetos. 
O software trabalhará com a manipulação de classes para o controle de 
agendamentos dos pacientes. 
O software vai trabalhar em nuvem, sendo aceito na maioria dos sistemas 
operacionais e mobiles. 
A interface do sistema deve ser intuitiva de fácil utilização. 
O software será leve, e não consumira muita memória do hardware do usuário. 
Regras 
O cadastro não será realizado caso o cpf já exista no sistema. 
Somente usuários internos poderão confirmar o atendimento solicitado 
pelo cliente. 
Tabela 2 – Requisitos Não Funcionais do Projeto de Teleatendimento 
Fonte: Próprio Autor (2021). 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
17 
 
2.2 DIAGRAMAS 
 
Nesse capítulo, apresentamos os diagramas do sistema, definido pelo Prof. 
Lima (2020) como uma representação visual, estruturada e simplificada de um 
conceito, ideia, produto etc. 
Desse modo, essas representações nos permitirão observar como o sistema 
funciona e como se relacionará com o usuário. 
2.2.1 DIAGRAMA DE CASO DE USO 
 
Primeiramente, faremos a utilização de casos de uso, que conforme Jacobson 
(2005), é um tipo de “documento narrativo”, que descreve a sequência de eventos 
de um ator que usa um sistema para completar um processo. Nesse sentido, 
montaremos um diagrama para essa representação, levando em consideração os 
usuários e a respectivouso que ele pretenda fazer. 
 
 
 
 
Diagrama 1 – Casos de Uso do Sistema 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
18 
 
Podemos observar, de acordo com o diagrama, que o sistema possui 2 
autores (usuário interno e usuário externo) e 4 casos de uso: “Login”; “Marcar 
atendimento”; “Confirmar atendimento” e “Cancelar atendimento”. 
Começamos então pelo caso de uso “Login”, que deverá ser feito por todos os 
autores para utilizar o sistema. 
 
 
 
 Vejamos agora, o caso de uso realizado pelos dois autores, “Marcar 
atendimento”. 
 
Nome Login 
Objetivo Acessar o sistema para fazer o seu uso. 
Autores 
1. Usuário Interno 
2. Usuário Externo 
Pré-
Condição 
O usuário não ter feito ainda o login no sistema depois de iniciado. 
Fluxo 
Básico 
1. O usuário preenche o campo “Login”; 
2. O usuário preenche o campo “Senha”; 
3. O usuário seleciona a opção “Entrar”; 
4. O sistema exibe o menu principal de acordo com o usuário 
logado; 
5. O caso de uso é encerrado. 
Fluxo 
Alternativo 
Alternativa ao passo 4 – O usuário não observou a regra de 
negócio 
a. O sistema exibe a mensagem “Login ou/e senha incorreto (s), 
tente novamente”; 
b. O usuário retoma ao passo 1. 
Regra de 
Negócio 
O sistema só permitirá o seu uso, caso os dados preenchidos no 
campo “Login” e “Senha” sejam validos. 
Tabela 4 – Caso de uso “Login” 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
19 
 
Nome Marcar atendimento 
Objetivo Marcar atendimento no hospital. 
Autores 
1. Usuário Interno 
2. Usuário Externo 
Pré-
Condição 
Ter executado o caso de uso “Login”. 
Fluxo 
Básico 
1. O usuário seleciona a opção “Marcar novo atendimento”; 
2. O sistema exibe as opções disponíveis no hospital; 
3. O usuário seleciona a consulta ou exame desejado.; 
4. O sistema exibe as datas disponível para o atendimento 
selecionado; 
5. O usuário seleciona a data desejada; 
6. O sistema exibe uma ficha com o atendimento e a data 
selecionados pelo cliente; 
7. O usuário confirma; 
9. O sistema atualiza o banco de dados das datas e atendimentos 
disponíveis; 
9. O sistema exibe a mensagem “Atendimento marcado! Aguarde a 
nossa confirmação.” 
10. O sistema volta para a tela inicial; 
11. O caso de uso é encerrado. 
Fluxo 
Alternativo 
Alternativa ao passo 5 – O usuário não observou a regra de 
negócio “RN1” 
a. O sistema exibe a mensagem “Por favor, selecione o 
atendimento desejado”; 
b. O usuário retoma ao passo 3. 
Alternativa ao passo 5 – O usuário não observou a regra de 
negócio “RN2” 
a. O sistema exibe a mensagem “Por favor, selecione a data 
desejada para o atendimento”; 
b. O usuário retoma ao passo 4. 
Regras de 
Negócio 
RN1. O sistema só exibirá as datas disponíveis caso o usuário 
selecione o atendimento desejado. 
Tabela 5 – Caso de uso para marcar atendimento 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
20 
 
Fonte: Próprio Autor (2021). 
 
Outro caso de uso realizado pelos dois autores é o “Cancelar atendimento”: 
 
RN2. O sistema só exibirá a mensagem de confirmação caso o 
usuário selecione a data desejada. 
Nome Cancelar atendimento 
Objetivo Cancelar o atendimento anteriormente marcado. 
Autores 
1. Usuário Interno 
2. Usuário Externo 
Pré-
Condições 
Ter executado o caso de uso “Login” e “Marcar atendimento” 
Fluxo 
Básico 
1. O usuário seleciona a opção “Cancelar atendimento”; 
2. O sistema exibe os atendimentos anteriormente marcado pelo 
usuário; 
3. O usuário seleciona o atendimento que deseja cancelar; 
4. O sistema exibe uma ficha com o atendimento anteriormente 
marcado pelo usuário com a mensagem de cancelamento; 
5. O usuário confirma; 
6. O sistema atualiza o banco de dados das datas e atendimentos 
disponíveis; 
7. O sistema exibe a mensagem “Atendimento cancelado!” 
8. O sistema volta para a tela inicial; 
9. O caso de uso é encerrado. 
Fluxo 
Alternativo 
Alternativa ao passo 5 – O usuário não observou a regra de 
negócio “RN1” 
a. O sistema exibe a mensagem “Por favor, selecione o atendimento 
que deseja cancelar”; 
b. O usuário retoma ao passo 3. 
Regras de 
Negócio 
RN1. O sistema só exibirá a mensagem de confirmação do 
cancelamento caso o usuário selecione o atendimento que deseja 
cancelar. 
Fonte: Próprio Autor (2021). 
Tabela 6 – Caso de uso para cancelar o atendimento 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
21 
 
Fonte: Próprio Autor (2021). 
Por último, observemos o caso de uso que só é realizado pelo autor “Usuário 
Interno, o “Confirmar atendimento”. 
 
Nome Confirmar atendimento 
Objetivo Confirmar o atendimento anteriormente marcado. 
Autor 1. Usuário Interno 
Pré-
Condições 
Ter executado o caso de uso “Login” e “Marcar atendimento”. 
Fluxo 
Básico 
1. O usuário seleciona a opção “Confirmar atendimento”; 
2. O sistema exibe os atendimentos anteriormente marcado pelo 
usuário; 
3. O usuário seleciona o atendimento que deseja confirmar; 
4. O sistema exibe uma ficha com o atendimento anteriormente 
marcado pelo usuário com a mensagem de confirmação; 
5. O usuário confirma; 
6. O sistema exibe a mensagem “Atendimento confirmado!” 
7. O sistema volta para a tela inicial; 
8. O caso de uso é encerrado. 
Fluxo 
Alternativo 
Alternativa ao passo 5 – O usuário não observou a regra de negócio 
“RN1” 
a. O sistema exibe a mensagem “Por favor, selecione o atendimento 
que deseja confirmar”; 
b. O usuário retoma ao passo 3. 
Regras de 
Negócio 
RN1. O sistema só exibirá a mensagem de confirmação do 
atendimento caso o usuário selecione o atendimento que deseja 
confirmar. 
 
 
 
Tabela 7 – Caso de uso para confirmar o atendimento 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
22 
 
Imagem 2 – Sem qualidade Vs Com Qualidade 
Fonte: Próprio Autor (2021). 
2.2.2 DIAGRAMA DE ATIVIDADES 
 
Nesse subcapítulo, apresentamos o diagrama de atividades do sistema de 
teleatendimento. Esse diagrama, tem como objetivo principal, segundo 
Ventura(2016), especificar o comportamento do software, do ponto de vista 
funcional, ou seja, das suas funcionalidades. 
Assim, poderemos observar, de forma gráfica, como o sistema de 
teleatendimento funcionará. 
 
 
 
 
 
Diagrama 2 – Atividades do Sistema 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
23 
 
Fonte: Próprio Autor (2021). 
2.2.3 DIAGRAMA DE CLASSES 
 
O diagrama de classes por sua vez, nos permite ilustrar graficamente como 
será a estrutura do software (em nível micro ou macro), e como cada um dos 
componentes da sua estrutura estarão interligados, conforme nos explica 
Ventura(2018). 
Ou seja, conseguiremos ver a estrutura interna, de forma gráfica é claro, do 
sistema de teleatendimento. 
 
 
 
 
Diagrama 3 – Classes do Sistema 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
24 
 
Fonte: Próprio Autor (2021). 
2.2.4 DIAGRAMA DE SEQUÊNCIA 
 
Nesse subcapitulo, expomos um diagrama de sequência do sistema de 
teleatendimento. Esse diagrama, segundo Oliveira (2018), procura representaros 
eventos, em ordem, e mensagens trocados no uso do software. 
Nesse sentido, poderemos ter noção de como o sistema interage para realizar 
uma função. Nesse caso em específico, observemos como o sistema opera para 
marcar um atendimento. 
 
 
 
 
 
Diagrama 4 –Sequência do Sistema 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
25 
 
Fonte: Próprio Autor (2021). 
2.2.5 DIAGRAMA DE COMPONENTES E IMPLANTAÇÃO 
 
Por fim, apresentamos o diagrama de componentes e implantação do sistema 
de teleatendimento. Esse diagrama, conforme Silva (2015), representa um 
modelamento físico dos componentes de software de um determinado Sistema. 
Nesse sentido, podemos visualizar, graficamente, os aspectos físicos do 
software desejado pelo hospital. 
 
 
Diagrama 5 – Componentes e Implantação do Sistema 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
26 
 
Fonte: Qualidade de Software. 
Imagem 13 – Sem qualidade Vs Com Qualidade 
3. GESTÃO DA QUALIDADE 
 
 Nesse capítulo, apontamos qual a melhor técnica para implantar 
qualidade em nosso sistema de teleatendimento. 
Primeiramente, é mister explicar alguns conceitos. De acordo com Pressman 
(1994), a qualidade de software pode ser definida com a entrega do software ao 
cliente com todos os seguintes itens observados: requisitos funcionais; de 
desempenho que foram explicitamente declarados; padrões de desenvolvimento 
claramente documentados; características implícitas que são esperadas de todo 
software desenvolvido por profissionais. 
 
 
 
 
 
 
 
 
 
Dito isso, a empresa deverá adotar uma norma de qualidade para produzir ao 
hospital, e como a empresa de software é nova no mercado e ainda carece de 
grandes recursos financeiros, a norma mais adequada para ela é a “MPS.BR”. 
Rafael (2012) confirma que uma das metas dessa norma visa definir e aprimorar um 
modelo de melhoria e avaliação de processo de software, atendendo 
preferencialmente as micro, pequenas e médias empresas, de forma a adequar as 
suas necessidades de negócio para serem reconhecidas nacional e 
internacionalmente como uma empresa de qualidade. 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
27 
 
Tabela 8 – Níveis de Maturidade da Norma MPS.Br 
Nesse sentido, o MPS.Br serve como um “selo” que indica o nível de 
maturidade da empresa em relação às práticas relacionadas ao desenvolvimento de 
software. Esse selo possui níveis, sendo cada um com suas diversas práticas 
associadas. Então, uma empresa, que possui o "selo" MPS. Br, utiliza essas boas 
práticas e, teoricamente, tem condições de desenvolver softwares com qualidade e 
com custos e prazos dentro do estimado. 
Para implementar essa norma, Montoni(2018) explica que é preciso 
reorganizar e reestruturar os processos de gestão e produção em sua empresa. Pois 
como os processos do MPS.Br são adotados em níveis de maturidade, é preciso 
que haja o alinhamento do negócio a cada uma das etapas requeridas e aos poucos 
consiga atender aos requisitos de cada processo. 
Vejamos agora os níveis de maturidade para implantar a norma “MPS.Br”, 
eles vão do “G” ao “A”, sendo do menor para o maior: 
Nível de 
Maturidade 
Processos 
G: Parcialmente 
Gerenciado 
Gerência de Projetos (GPR): estabelecer e manter planos 
que definem as atividades, recursos e responsabilidades 
do projeto, bem como prover informações sobre o 
andamento do projeto que permitam a realização de 
correções quando houver desvios significativos no 
desempenho; 
Gerência de Requisitos (GRE): gerenciar os requisitos do 
produto e dos componentes do projeto e identificar 
inconsistências entre os requisitos, os planos do projeto e 
os produtos de trabalho do projeto. 
F: Gerenciado 
Os do “G”, mais: 
Aquisição (AQU): gerenciar a aquisição de produtos que 
satisfaçam às necessidades expressas pelo adquirente; 
Gerência de Configuração (GCO): estabelecer e manter a 
integridade de todos os produtos de trabalho de um 
processo ou projeto e disponibilizá-los a todos os 
envolvidos; 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
28 
 
Garantia da Qualidade (GQA): assegurar que os produtos 
de trabalho e a execução dos processos estejam em 
conformidade com os planos, procedimentos e padrões 
estabelecidos; 
Gerência de Portfólio de Projetos (GPP): iniciar e manter 
projetos que sejam necessários, suficientes e sustentáveis, 
de forma a atender aos objetivos estratégicos da 
organização; 
Medição (MED): coletar, armazenar, analisar e relatar os 
dados relativos aos produtos desenvolvidos e aos 
processos implementados na organização e em seus 
projetos, de forma a apoiar os objetivos organizacionais. 
E: Parcialmente 
Definido 
Os do “G” e “F”, mais: 
Avaliação e Melhoria do Processo Organizacional 
(AMP): determinar o quanto os processos padrões da 
organização contribuem para alcançar os objetivos de 
negócio da organização e para apoiar a organização a 
planejar, realizar e implantar melhorias contínuas nos 
processos com base no entendimento de seus pontos 
fortes e fracos; 
Definição do Processo Organizacional (DFP): 
estabelecer e manter um conjunto de ativos de processo 
organizacional e padrões do ambiente de trabalho usáveis 
e aplicáveis às necessidades de negócio da organização; 
Gerência de Recursos Humanos (GRH): prover a 
organização e os projetos com os recursos humanos 
necessários e manter suas competências adequadas às 
necessidades do negócio; 
Gerência de Reutilização (GRU): gerenciar o ciclo de vida 
dos ativos reutilizáveis. 
D: Largamente 
Definido 
Os anteriores, mais: 
Desenvolvimento de Requisitos (DRE): definir os 
requisitos do cliente, do produto e dos componentes do 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
29 
 
produto; 
Integração do Produto (ITP): compor os componentes do 
produto, produzindo algo integrado e consistente com seu 
projeto, e demonstrar que os requisitos funcionais e não 
funcionais são satisfeitos para o ambiente alvo ou 
equivalente; 
Projeto e Construção do Produto (PCP):projetar, 
desenvolver e implementar soluções para atender aos 
requisitos; 
Validação (VAL): confirmar que um produto ou 
componente do produto atenderá ao seu uso pretendido 
quando colocado no ambiente para o qual foi desenvolvido; 
Verificação (VER): confirmar que cada serviço e/ou 
produto de trabalho do processo ou do projeto atende 
apropriadamente os requisitos especificados. 
C: Definido 
Os anteriores, mais: 
Desenvolvimento para Reutilização (DRU): identificar 
oportunidades de reutilização sistemática de ativos na 
organização e, se possível, estabelecer um programa de 
reutilização para desenvolver ativos a partir de engenharia 
de domínios de aplicação; 
Gerência de Decisões (GDE): analisar possíveis decisões 
críticas usando um processo formal, com critérios 
estabelecidos, para avaliação das alternativas 
identificadas; 
Gerência de Riscos (GRI): o propósito é identificar, 
analisar, tratar, monitorar e reduzir continuamente os riscos 
em nível organizacional e de projeto. 
B: Gerenciado 
Quantitativamente 
Composto pelos processos dos níveis de maturidade 
anteriores (GPR, GRE, AQU, GCO, GQA, GPP, MED, 
AMP, DFP, GRH, GRU, DRE, ITP, PCP, VAL, VER) e 
pelos resultados evoluídos do Gerência de Projetos 
(GPR). 
Document shared on www.docsity.comDownloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
30 
 
 
Desse modo, a cada nível dessa norma a ser implementada na empresa, 
melhor será o nível da qualidade de seu software. 
 
 
 
 
 
 
 
A: Em Otimização 
Composto pelos processos dos níveis de maturidade 
anteriores (G ao B), todos atuando em forma conjunta para 
implementações e inovações no processo de produção da 
empresa. 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
31 
 
 Imagem 14 – Pág.1 do Termo de Abertura do Projeto 
4. GERENCIAMENTO DE PROJETO DE SOFTWARE 
 
Nesse capítulo, abordaremos a documentação indispensável para subsidiar o 
desenvolvimento do sistema de teleatendimento. 
Apresentamos o Termo de Abertura do Projeto, que possui todas as 
informações necessárias para auxiliar os interessados na construção do sistema. 
 
 
 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
32 
 
 Imagem 15 – Pág.2: Matriz e Responsabilidades 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
33 
 
 Imagem 16 – Pág.3: Riscos, Cronograma e Custos 
 
Agora, expomos um documento de suma importância para a empresa 
desenvolvedora de software, pois irá auxiliar a empresa nos próximos 
empreendimentos: Lições Aprendidas. 
 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
34 
 
 Imagem 17 – Lições Aprendidas 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte: Próprio Autor (2021). 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
35 
 
CONCLUSÃO 
 
Com base em tudo que vimos, há de se concordar com a importância das 
matérias trabalhadas, na construção de um sistema de teleatendimento muito 
requisitado atualmente por diversos ramos de serviços. Empreendedorismo nos 
auxiliou na construção de um modelo de negócio para a empresa desenvolvedora de 
software. Projeto de Sistemas Orientado a Objetos nos trouxe as metodologias para 
levantar os requisitos e construir os diagramas importantes para o entendimento do 
sistema. Gestão de Qualidade nos deram fundamentos para construir um software 
com qualidade. E por fim, Gerenciamento de Projeto de Software nos amparou na 
construção de documentos fundamentais para a empresa no desenvolvimento de 
um projeto. 
Infere-se, portanto, que essas matérias em conjunto alcançam muito mais 
aspectos inovadores do que se possam imaginar. Dito isso, que essa conjuntura 
seja reconhecida pelas empresas, pela sua contribuição na inovação de seus 
acervos e sistemas, principalmente pela problemática atual, implantada pela 
pandemia do COVID-19. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark
36 
 
 
 
REFERÊNCIAS 
 
ALFF, Chico. O que são Requisitos Funcionais e Não Funcionais? Análise de 
Requisitos, 2018. Disponível em: https://analisederequisitos.com.br/requisitos-
funcionais-e-nao-funcionais/. Acesso em 25 de mar. de 2021. 
CANGUÇU, Raphael. O que são Requisitos Funcionais e Requisitos Não 
Funcionais? Codificar, 2021. Disponível em: https://codificar.com.br/requisitos-
funcionais-nao-funcionais/. Acesso em 25 de mar. de 2021. 
LIMA, Christiano Santos. Engenharia de Software. Christiano Santos. 2020. 
Disponível em: https://engenharia-de-software-v1.3.pdf. Acesso em 14 de set. de 
2021. 
MONTONI, Mariano. Quais são os níveis de maturidade do MPS BR? ProMove, 
2018. Disponível em: https://promovesolucoes.com/quais-sao-os-niveis-de-
maturidade-do-mps-br/. Acesso em 31 de mar. de 2021. 
OLIVEIRA, Diego. Diagrama de Sequência. Instituto Federal. 2018. Disponível em: 
https://docente.ifrn.edu.br/diegooliveira/disciplinas/pds/aula-15-diagrama-de-
sequencia. Acesso em 17 de set. de 2021. 
PRESSMAN, R. S. Engenharia de Software. 6ª edicão. Rio de Janeiro: McGraw-Hill, 
2006. 
RAFAEL, Artur. O que é o MPS.br? OFICINA DA NET, 2012. Disponível em: 
https://www.oficinadanet.com.br/artigo/desenvolvimento/melhoria-de-processos-do-
software-brasileiro--mpsbr. Acesso em 31 de mar. de 2021. 
Silva, Flávio. Modelagem de Software. Facom. 2015. Disponível em: 
http://www.facom.ufu.br/~flavio/swmod-files/files/2015-02/11-UML-Diagramas-
Compoentes-e-Implantacao-Pacotes.pdf. Acesso em 17 de set. de 2021. 
VENTURA, Plínio. Entendendo o Diagrama de Atividades da UML. Até o Momento, 
2016. Disponível em: https://www.ateomomento.com.br/uml-diagrama-de-atividades/. 
Acesso em 16 de set. de 2021. 
VENTURA, Plínio. Entendendo o Diagrama de Classes da UML. Até o Momento, 
2018. Disponível em: https://www.ateomomento.com.br/uml-diagrama-de-classes/. 
Acesso em 16 de set. de 2021. 
 
 
 
 
 
 
Document shared on www.docsity.com
Downloaded by: jessi-quadros (j.tampss@gmail.com)
https://www.docsity.com/?utm_source=docsity&utm_medium=document&utm_campaign=watermark