System Labor Pré Projeto

Prévia do material em texto

UNIVERSIDADE ESTADUAL DE GOIÁS 
CÂMPUS DE ITABERAÍ 
 
 
 
 
 
 
 
Alan Ferreira Costa 
Fernanda Silva de Jesus 
Diego Batista de Sousa Marques 
 
 
 
 
 
System Labor 
 
 
 
 
 
 
 
 
 
 
 
 
ITABERAÍ 
2015 
 
 
Alan Ferreira Costa 
Fernanda Silva de Jesus 
Diego Batista de Sousa Marques 
 
 
 
 
 
 
 
 
 
 
 
 
 
System Labor 
 
 
Trabalho Final de Curso apresentado à 
Universidade de Goiás, Campus de Itaberaí, como 
requisito parcial para a conclusão do curso de 
graduação em Sistema de Informação, sob 
orientação do Professor (a) Thais Peres Montes. 
 
 
 
 
 
 
 
 
 
 
ITABERAÍ 
2015 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Dedicamos este trabalho em primeiro lugar ao Senhor 
nosso Deus que nos deu graça e capacidade para 
planeja-lo, aos nossos pais, nossos professores e 
amigos que nos influenciaram para a conclusão do 
mesmo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Agradecemos a Deus por nos proporcionar 
momentos em que podemos conviver e aprender 
mais um com o outro, assim como as experiências em 
outras áreas de ensino, agradecemos a professora 
Thais Peres que nos motivou e cooperou com grande 
estimulo e persistência para a realização desse 
trabalho. Além de agradecer em especial ao 
proprietário da empresa Laboratório Cabral, Luís 
Antônio Campos Cabral onde colaborou com grande 
profissionalismo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Ninguém quer morrer. Mesmo as pessoas que 
querem chegar ao Paraíso não querem morrer para 
estar lá. Mas apesar disso, a morte é um destino de 
todos nós. Ninguém nunca escapou. E deve ser 
assim, porque a morte é provavelmente a maior 
invenção da vida. É o agente de transformação da 
vida. Ela elimina os antigos e abre o caminho para os 
novos”. Steve Jobs. 
 
 
RESUMO 
 
Este projeto tem como principal foco a análise e desenvolvimento de um 
sistema de informação para um laboratório de análises clínicas, baseando se na 
engenharia de software. O acompanhamento das atividades dentro da empresa 
proporciona melhores condições de trabalho. Nesse âmbito o sistema fornecerá 
condições em que poderá agendar horários e manter o controle de seus cadastros 
sendo eles de cliente ou de exames, auxiliando a empresa a monitorar suas rotinas. 
Foram feitas pesquisas bibliográficas e entrevistas que conduziram ao entendimento 
da necessidade da empresa sendo analisado com as propostas de análise orientada 
a objetos que propuseram essa realização. O objetivo final deste foi a capacitação de 
implementação e análise do mesmo, conseguindo chegar a uma conclusão eficácia 
do sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE FIGURA 
 
Figura 1- Modelo Cascata. ................................................................................................................ 22 
Figura 2 - Modelo Espiral. ................................................................................................................. 23 
Figura 3 - Modelo de Prototipação .................................................................................................. 24 
Figura 4 - Diagrama de caso de negocio ........................................................................................ 37 
Figura 5 – Diagrama de caso de uso .............................................................................................. 38 
Figura 6 - Modelo Relacional Normalizado .................................................................................... 39 
Figura 7 - Diagrama de Classe ........................................................................................................ 40 
Figura 8 - Diagrama de Sequência de Agenda ............................................................................. 41 
Figura 9 - Diagrama de Sequência de Cliente ....................................................................................... 42 
Figura 10 - Diagrama de Sequência de Convenio ........................................................................ 43 
Figura 11 - Diagrama de Sequência de Exame............................................................................. 44 
Figura 12 - Protótipo Alto nivel - Tela Principal ............................................................................. 51 
Figura 13 - Protótipo Alto Nivel - Tela de Exames ....................................................................... 52 
Figura 14 - Protótipo Alto Nível -Tela de busca de exames ....................................................... 53 
Figura 15 - Protótipo de Alto nível - Tela de convênios ............................................................... 54 
Figura 16 - Protótipo de Alto nível - Tela de Cadastro de Funcionário ...................................... 55 
Figura 17 - Prototipo de Alto Nivel - Tela de Cadastro de Clientes ............................................ 56 
Figura 18 - Protótipo Alto nível - Tela de Agenda ......................................................................... 57 
Figura 19 - Protótipo de Baixo Nível - Tela Principal .................................................................... 58 
Figura 20 – Protótipo Baixo Nível - Tela de Exames ................................................................... 59 
Figura 21 - Protótipo Baixo Nível -Tela de busca de exames .................................................... 60 
Figura 22 - Protótipo de Baixo nível - Tela de convênios ............................................................ 61 
Figura 23 - Protótipo de Baixo nível - Tela de Cadastro de Funcionário ................................... 62 
Figura 24 - Protótipo de Baixo Nível - Tela de Cadastro de Clientes ........................................ 63 
Figura 25 - Protótipo Alto nível - Tela de Agenda ......................................................................... 64 
 
 
 
LISTA DE TABELAS 
 
Tabela 1 - Requisitos ................................................................................................................... 34 
 
 
 
 
LISTA DE SIGLAS E ABREVIATURAS 
 
UML - Unified Modeling Language; 
SGDB- Sistema de Gerenciamento de Banco de Dados; 
CASE – Computer Aided Software Engineering; 
MRN- Modelo Relacional Normalizado. 
 
 
SUMÁRIO 
INTRODUÇÃO ...................................................................................................................... 12 
1 ENGENHARIA DE REQUISITOS ............................................................................... 14 
1.1 REQUISITOS ............................................................................................................................. 14 
1.2 REQUISITOS FUNCIONAIS ............................................................................................................ 15 
1.3 REQUISITOS NÃO FUNCIONAIS...................................................................................................... 16 
1.4 LEVANTAMENTO DE REQUISITOS .................................................................................................. 17 
1.5 VALIDAÇÃO DE REQUISITOS ......................................................................................................... 17 
2 ENGENHARIA DE SOFTWARE .................................................................................19 
2.1 SOFTWARE .............................................................................................................................. 20 
2.2 PROCESSOS DE SOFTWARE .......................................................................................................... 20 
2.3 MODELO DE PROCESSO DE SOFTWARE .......................................................................................... 21 
2.3.1 MODELO CASCATA .................................................................................................................... 22 
2.3.2 MODELO ESPIRAL ..................................................................................................................... 23 
2.3.3 MODELO DE PROTOTIPAÇÃO ....................................................................................................... 24 
2.4 ETAPAS DE ENGENHARIA DE SOFTWARE......................................................................................... 25 
2.4.1 ESPECIFICAÇÃO ......................................................................................................................... 25 
2.4.2 DESENVOLVIMENTO .................................................................................................................. 26 
2.4.3 VALIDAÇÃO .............................................................................................................................. 27 
2.4.4 EVOLUÇÃO .............................................................................................................................. 27 
3 UML.................................................................................................................................. 29 
3.1 DIAGRAMAS DE CASO DE USO ..................................................................................................... 29 
3.2 DIAGRAMA DE CLASSES .............................................................................................................. 30 
3.3 DIAGRAMA DE SEQUÊNCIA .......................................................................................................... 31 
4 ESTUDO DE CASO ........................................................................................................ 33 
4.1 ANÁLISE INICIAL ........................................................................................................................ 33 
4.1.2 TABELA DE REQUISITOS............................................................................................................... 34 
4.2 LISTA DE REQUISITOS NÃO FUNCIONAIS .......................................................................................... 35 
4.3 ANÁLISE DE ENTREVISTA ............................................................................................................. 35 
4.6 DIAGRAMA DE CLASSE (DADOS ESTRUTURAIS) ................................................................................ 40 
4.7 DIAGRAMA DE SEQUÊNCIA (EVENTOS TEMPORAIS) .......................................................................... 41 
4.8 FERRAMENTAS (SOFTWARES, HARDWARE E EQUIPAMENTO UTILIZADO). ...................................... 45 
5 CONSIDERAÇÕES FINAIS ......................................................................................... 46 
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................. 47 
APÊNDICE ............................................................................................................................. 48 
 
12 
 
INTRODUÇÃO 
 
Um sistema se caracteriza por um conjunto de elementos organizados e 
relacionados que interagem entre si, desde modo seu funcionamento se dá através 
de entrada e saída de informações. Contudo um sistema revela uma série de metas 
que vem atingir um objetivo ou vários deles. 
É observado a dificuldade de um laboratório de análises clínicas em suas 
atividades rotineiras utilizando software que já não proporciona as devidas 
atualizações que veio a defasar suas ferramentas não se adequando as necessidades 
do próprio laboratório. Para este, foi criado o System labor um sistema que por sua 
vez irá agilizar as atividades dentro do laboratório, proporcionando uma maneira 
simples de lidar com o mesmo, favorecendo uma ambiente de fácil compreensão e 
menos estressante. Objetivo deste é propor ao usuário final satisfação em seus 
propósitos, com a certeza de que estará usufruindo de um sistema eficaz em sua 
empresa. 
O sistema será baseado na engenharia de software, na qual oferece ao 
engenheiro de software auxilio para a análise e desenvolvimento do sistema, 
identificando os principais requisitos que irão exercer funcionalidades dentro do 
sistema. Como modelo de linguagem foi escolhida a linguagem UML (Unified Modeling 
Language) que oferece uma análise construtiva do sistema, além de oferecer 
ferramentas cases que ajudam na construção do mesmo. Escolhido a ferramenta 
Astha, na qual possibilita a criação de diagramas, dentre eles foram criados diagrama 
de caso de uso, diagrama de classes, e o diagrama de sequência. Para a montagem 
da prototipação foi realizada em base da orientação a objetos de linguagem Java, 
utilizando o netBeans 8.1. O MySQL Workbench 6.3 foi utilizado para a montagem do 
MRN (modelo relacional normalizado). 
Este trabalho está estruturado em 5 capítulos, iniciando pela introdução que 
fala sobre o tema escolhido, abordando toda a metodologia usada para a criação 
deste. 
No capítulo 1 será abordado todo o levantamento de requisitos dentro da 
engenharia de software, assim como suas definições e a validações destes. 
 
13 
 
No capítulo 2 falará de toda a análise e desenvolvimento dentro da 
engenharia de software, tratando de seus modelos utilizados para a criação deste 
sistema, oferecendo toda a estrutura necessária para a documentação do mesmo. 
No capítulo 3 tratará dos diagramas retratados na linguagem UML, assim 
como, suas definições, especificará as ações e funcionalidades que o sistema irá 
fazer. 
No capítulo 4 discorrerá dos requisitos levantados para o desenvolvimento 
do projeto, assim como todos os implementos importantes para implementa ló. 
No capítulo de considerações finais são apresentando os resultados finais, 
que comtemplam as observações obtidas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
14 
 
1 Engenharia de requisitos 
 
Os requisitos são o centro no processo da criação de um software, sendo 
determinante para a qualidade do projeto em desenvolvimento. A Engenharia de 
requisitos consiste no levantar, analisar e controlar estes requisitos. 
A Engenharia de requisitos se inicia durante a atividade de comunicação 
entre o analista e seu cliente, continuando na modelagem da aplicação e se adaptando 
às necessidades do processo, do projeto, do produto e das pessoas que estão 
realizando o trabalho, garantindo a qualidade e a viabilidade das informações 
adquiridas no levantamento de requisitos. Para Magela (2006, p.19) esta etapa “[...] é 
responsável por garantir a consistência e a qualidade dos requisitos especificados”, 
para um melhor desenvolvimento da aplicação. 
Frederick P. Brooks, nos diz que esta é a parte mais árdua na criação de 
uma aplicação, pois consiste em identificar o que irá se construir. Caso ocorra erros 
nesta identificação poderá chegar a inutilização do projeto desenvolvido, geralmente 
estes erros ocorre quando o analista não consegue compreender o que o cliente, ou 
a não expressão adequada dos problemas a serem resolvidos por parte do cliente e 
de seus funcionários. 
 Pressman (2011, p. 126) comenta a respeito destes acontecimentos 
narrando as falas de um cliente com seu desenvolvedor dizendo o seguinte: “Eu sei 
que vocêimagina que entendeu aquilo que eu lhe disse, mas o que você não 
compreende é que aquilo que eu lhe disse era exatamente aquilo que eu quis dizer”. 
As falhas com a comunicação poderão tornar um software inútil para o cliente, não o 
atendendo da forma esperada. 
 
1.1 Requisitos 
 
Os requisitos são descritos como uma condição ou capacidade que o 
usuário necessita para resolver determinado problema. De acordo com Sommerville 
(2007, p.79) os “[...] requisitos refletem as necessidades dos clientes de um sistema 
que ajuda a resolver algum problema, por exemplo, controlar um dispositivo, enviar 
 
15 
 
um pedido ou encontrar informações”. Sendo mais preciso são características e 
funcionalidades que o software deve atender para realizar as atividades requeridas 
pelo usuário; 
Os requisitos formam um conjunto de funcionalidades (característica, 
objetivos, propriedades, habilidade ou qualidade) que compõe o sistema, este por sua 
vez criado de acordo com as necessidades de cada empresa. Segundo Magela (2006, 
p.2) requisitos atuam como: “[...] Conjunto de sentenças condicionadas pelos 
processos e pela política de negócio da empresa que visam a definir as 
funcionalidades que devem estar presentes em um software”. Com a descrição acima 
entende-se que os requisitos são descrições das funcionalidades e restrições em que 
o sistema deve atuar tendo em vista modernizar e agilizar os processos da empresa. 
Segundo Pfleeger requisito: “[...] é uma característica do sistema ou a descrição de 
algo que o sistema é capaz de realizar, para atingir os seus objetivos”. 
(PFLEEGER,2004, p.111). Sendo o mesmo, o alicerce principal para a construção da 
aplicação, caso ocorra um mal levantamento ou interpretação destes, poderá ocorrer 
um grande comprometimento do sistema podendo o inutiliza-lo permanentemente. 
Na construção de um sistema os requisitos podem ser caracterizados como 
requisitos funcionais e requisitos não funcionais, veremos cada um deles a seguir. 
 
1.2 Requisitos Funcionais 
 
Os requisitos descreve as funcionalidades e o comportamento do sistema, 
tornando-se “o verdadeiro alvo na análise de requisitos porque são eles que fornecem 
o que deve ser construído”. (Magela, p. 9, 2006), mais precisamente vão variando de 
acordo com cada situação para qual o software é desenvolvido. 
Estes requisitos a também como funções do software, onde vai detalhar as 
execuções do próprio sistema, ou seja, detalhar suas características. De acordo 
com Sommerville (2007) são as declarações que o sistema deve fornecer, reagir a 
entradas especificas e como o sistema deve se comportar”, nas atividades requeridas 
ao mesmo. 
 
16 
 
Estes requisitos podem ser operações matemáticas, detalhes técnicos e 
outras funcionalidades que definem o que o sistema poderá realizar como a 
manipulação dos dados e processos. 
 
1.3 Requisitos não funcionais 
 
Os requisitos não funcionais estão relacionados a manipulação do sistema 
pelo usuário, em termos de confiança, desempenho, suporte, utilidade e sua 
escalabilidade. Dependendo dos serviços fornecidos pelos requisitos funcionais 
durante a construção do software, ou seja, estão diretamente relacionados a suas 
funções. Para Magela (2006) esses requisitos: “[...]restringem a forma como os 
requisitos funcionais fornecerão seus serviços e se comportarão durante a execução 
do software que está sendo produzido”. (MAGELA, 2006, p.3). 
Estes requisitos restringe o desenvolvimento do sistema, a linguagem a ser 
desenvolvido e quais técnicas ou ferramentas de implementação a ser utilizadas. 
Contudo não se aplicam as características ou serviços individuais do sistema. É assim 
que Pfleeger (2004, p.115) os descrevem: “Os requisitos não funcionais ou restrições 
descrevem uma restrição no sistema que limita nossas opções para criar uma solução 
para o problema”. 
Contudo Sommerville (2007), afirma que: 
“Os requisitos não funcionais surgem devido às necessidades do usuário, ás 
restrições de orçamento, ás politicas organizacionais, a necessidade de 
interoperabilidade com outros sistemas de software ou hardware ou a fatores 
externos, como regulamentos de segurança ou legislação a respeito da 
privacidade”. (SOMMERVILLE, 2007, p. 82). 
 
Denominados de atributos de qualidade estes requisitos atuam como 
critério de seleção, ou seja, vão identificar e definir se o software desenvolvido é 
confiável, eficiente (desempenho, espaço, rapidez, memória), confiável, portabilidade. 
 
 
17 
 
1.4 Levantamento de requisitos 
 
O levantamento de requisitos é umas das etapas com mais destaque e 
importância no processo de desenvolvimento de software, pois é onde serão 
identificados os requisitos que o projeto devera suprir, tendo assim uma maior 
interatividade entre os analistas responsável por esta etapa e o seu cliente, 
procurando suprir e satisfazer suas reais necessidades, é nesta etapa que acontecerá 
uma análise minuciosa dos dados, sendo responsável por “[...] mais da metade dos 
defeitos de um software, tem origem em erros cometidos no levantamento de 
requisitos”. (MAGELA, 2006, p.14). 
Contudo para Sommerville (2007) os engenheiros trabalhara com o cliente 
e seus funcionários para saber quais serviços o software irá fornecer para melhor 
atender ao cliente, com a determinada afirmação. 
“Nessa atividade, os engenheiros de software trabalham com os clientes e os 
usuários finais do sistema para aprender sobre o domínio e a aplicação, quais 
serviços o sistema deve fornecer, o desempenho esperado do sistema, 
restrições de hardware, etc.”. (SOMMERVILLE, 2007, p.97). 
 
Esta atividade auxiliará no esclarecimento de dúvidas, tendo suma 
importância para melhor compreender e analisar os requisitos coletados. Para 
Pressman (1995, p.133) o levantamento de requisitos trata-se da: “[...] resolução de 
problemas, elaboração, negociação e especificação”, da aplicação em 
desenvolvimento. Esta é interação entre o desenvolvedor e o cliente, é chamadas de 
stakeholders, termo usado para se referir a pessoas que atuam direta ou 
indiretamente com o sistema, e quando são elaboradas entrevistas para alcançar os 
objetivos (os requisitos) em que se trabalhara no desenvolvimento do software. 
 
1.5 Validação de requisitos 
 
Todos os processos da Engenharia de requisitos são de suma importância 
para o desenvolvimento de um projeto que venha atender as necessidades, 
solicitadas pelo cliente, porem após o levantamento temos que validar os nossos 
 
18 
 
requisitos, confirmando se atendem as reais necessidades dos usuários finais da 
aplicação. Sommerville nos alerta que se o sistema não apoia os reais objetivos da 
empresa, o mesmo e inútil pois não contem valor para a empresa. 
Neste período que ocorre a descobertas dos erros nos requisitos 
encontrados na elicitação (Levantamento de requisitos). Sommerville nos alerta que 
se estes erros não são corrigidos já nas primeiras etapas no processo de 
desenvolvimento do software poderá levar a um custo excessivo no projeto: 
“[...] erros em um documento de requisitos podem levar a custos excessivos 
de retrabalho quando são descobertos durante o desenvolvimento ou depois 
que o sistema está em operação”. (SOMMERVILLE, 2007, p.105). 
 
Quem deve atuar na validação de requisitos? A resposta para esta 
pergunta e simples todos os envolvidos e interessados na aplicação. Assim descrito 
por Magela: “[...] deverá ser validada por todos os envolvidos no projeto. Os usuários, 
os financiadores e os técnicos são os responsáveis por essa tarefa”. (MAGELA, 2006, 
p.23). 
Todos os envolvidos examinaram as especificações procurando por erros 
como: requisitos não estruturados(Não há problemas em sua interpretação), 
requisitos que violam alguma regra de negócio (leis, códigos, normas que impossibilita 
a resolução deste requisitos) e outros descritos por Pressman como: “[...] áreas em 
que esclarecimentos podem ser necessário, informações omissas, 
inconsistências(um problema importante quando produtos ou sistemas de grande 
porte passam por engenharia), requisitos conflitantes ou requisitos irrealísticos 
(inatingíveis). (PRESSMAN, 2006, p.120) 
 
 
 
 
 
 
19 
 
2 Engenharia de software 
 
A Engenharia de software está voltada para a produção de software com 
qualidade, tendo também como função na área da computação destinada a 
especificação, desenvolvimento e manutenção de sistemas. Sommerville a descreve 
a Engenharia de software como uma disciplina que está: “[...] relacionada com todos 
os aspectos da produção de software, desde os estágios iniciais de especificação do 
sistema até a sua manutenção, depois que este entrar em operação”. 
(SOMMERVILLE, 2007, p. 5). 
Deste mesmo modo os engenheiros de software à utilizam para resolver 
seus problemas na computação, é uma forma de estudo utilizado pelos mesmos para 
obter resultados e desenvolvimento de bons softwares. Pfleeger afirma que como 
engenheiros de software temos que usar: “[...] nosso conhecimento sobre 
computadores e computação para ajudar a resolver problemas”. (PFLEEGER, 2004, 
p. 2). 
Contudo a engenharia está relacionada a métodos, processos e 
ferramentas nas quais contribuem para a construção do software, onde cada etapa 
proporcionará maneiras de como planejar, projetar e desenvolver o sistema. 
Segundo Pressman: 
“Ela abrange um conjunto de três elementos fundamentais: métodos, 
ferramentas e procedimentos que possibilita ao gerente o controle de 
processo de desenvolvimento de software e oferece ao profissional uma base 
para a construção de software de alta qualidade produtivamente”. 
(PRESSMAN, 1995, p. 31) 
 
Portanto a engenharia de software proporciona meios que auxilia no 
desenvolvimento, desde os estados iniciais até sua finalização, proporcionando assim 
a criação de sistemas qualificados. 
 
 
 
20 
 
2.1 Software 
 
Muitos pensam que quando se fala de software está se referindo a somente 
ao executável que está em seu computador, no entanto para Sommerville a definição 
de software é muito mais complexa que isso, para ele “Software não é apenas o 
programa, mas também todos os dados de documentação e configuração associados, 
necessários para que o programa opere corretamente”. (SOMMERVILLE, 2007, p. 4), 
esta documentação citada por Sommerville se estende desde as entrevistas 
realizadas com o cliente até a relatórios gerados com testes e implantações do 
software. 
Já Pressman o define com outras palavras, mas com o mesmo sentido e 
objetivo, dizendo que software: “Abrange programas que executam em computadores 
de qualquer tamanho e arquitetura, conteúdo que é apresentado ao programa a ser 
executado e documentados tanto em forma impressa quanto virtual...”. (PRESSMAN, 
2006, p.1) Assim como disse Pressman um programa pode ser executado por 
qualquer dispositivo capaz de interpretar e executar as instruções contidas em seus 
códigos independentemente da linguagem de programação no qual é desenvolvido, 
além de sua documentação poder ser tanto impressa quanto virtualizadas. 
 
2.2 Processos de Software 
 
Podemos considerar um conjunto de tarefas ordenadas como sendo um 
processo. Processos de software é um determinado conjunto de tarefas ordenadas, 
assim como nos ordenamos tudo que fazemos ou seja criamos um roteiro para realizar 
nossos afazeres também é assim no desenvolvimento de um software, para Pfleeger 
(2004, p. 36) os processos de software contém: “uma série de etapas que envolvem 
atividades, restrições e recursos para alcançar a saída desejada”. Esta saída tão 
desejada informada pelo autor e simplesmente um produto de qualidade e que atenda 
todas as reivindicações destinadas ao mesmo. 
Sommerville, se refere ao processo de software como um conjunto de 
atividades e resultados que associados leva a produção eficaz de software, já 
 
21 
 
Pressman define o processo de software como um roteiro que busca ajudar os 
engenheiros de software a criar seus projetos a tempo com um resultado de boa 
qualidade, para ele processo é o roteiro que se segue para a criação do software. 
Apesar da existência de vários modelos de processos, não há o modelo 
ideal a ser utilizado, Pressman comenta sobre esta afirmação com os dizeres: 
“Em nível de detalhe, o processo adotado depende do software que você está 
construindo. Um processo poderia ser apropriado à criação de softwares para 
o sistema de aviônica de uma aeronave, enquanto um processo inteiramente 
diferente seria indicado para a criação de um site”. (PRESSMAN, 2006, p.16) 
 
Como descrito anteriormente, pela não existência de um processo de 
software ideal, mas sim um que se enquadra ao projeto em questão, iremos comentar 
sobre os três modelos de processos mais utilizados: 
 Modelo em cascata 
 Modelo Espiral 
 Modelos de Prototipação. 
Veremos a seguir o que são modelos de processos de software. 
 
2.3 Modelo de Processo de Software 
 
Os Modelos de processos foi criado para colocar ordem no 
desenvolvimento de software fornecendo um roteiro de criação para o software, para 
Sommerville (2007, p. 6) o modelo de processo de software: “[...] é uma descrição 
simplificada desse processo de software que representa uma visão dele”. 
Representando a sequência das atividades com suas entradas e saídas, até mesmo 
os papeis das pessoas envolvidas com a aplicação. Pfleeger também comenta sobre 
a utilização de um modelo e seus subprodutos tendo o objetivo de ajudar a equipe 
entender a diferença entre o que ocorre e o que deveria ocorrer nos processos de 
software. 
 Pressman (2006, ed. 06, p. 37) defende que estes modelos: “[...] só 
definem um conjunto distinto de atividades, ações, tarefas, marcas e produtos de 
 
22 
 
trabalho que são necessários para fazer a engenharia de software com alta 
qualidade”, Pressman nós diz que estes modelos não garante a perfeição do projeto, 
porém fornece uma sequência de trabalho mais efetiva, dando estabilidade, controle 
e organização ao projeto e assim chegar o mais próximo possível do que seu cliente 
almeja com a utilização do software. 
 
2.3.1 Modelo cascata 
 
Figura 1- Modelo Cascata, Disponível em: <http://jkolb.com.br/o-modelo-em-
cascata/>, acesso em jun. de 2015. 
Apesar da existência de muitos outros modelos, o mais utilizado para esta 
devida função é o Modelo cascata, pois a grande maioria dos modelos existes se 
derivaram do mesmo, apenas acrescentando novas funcionalidade. Pfleeger (2004, 
p.39) comenta em seus escritos que: “[...] muitos outros modelos mais complexos são 
apenas variações do modelo cascata, incorporando loops de feedback e atividades 
extras”. O modelo cascata apresenta uma sequência linear para o desenvolvimento 
da aplicação, seguindo uma série de requisições. Pressman aborda o assunto com os 
dizeres que o cascata é um modelo: 
“[...] sequencial e sistemática para o desenvolvimento de software, 
começando como o levantamento de necessidades por parte do cliente, 
avançando pelas fases de planejamento, modelagem, construção, emprego 
e culminando no suporte continuo do software concluído” (PRESSMAN, 2007, 
ed. 7ª, p. 59) 
 
Este modelo apresenta suas vantagens nas documentações que serão 
produzidas em todas as suas etapas, já sua desvantagem fica a cargo de sua 
 
23 
 
inflexibilidade tornando difícil a mudança de requisitos do usuário,além de que cada 
atividade se inicie apenas quando a anterior estiver completa e verificada. 
Sommerville nos orienta a utilizar este modelo em apenas uma situação, quanto os 
requisitos forem bem compreendidos e não haver possibilidade de ocorrer mudanças 
radicais no desenvolvimento da aplicação. 
 
2.3.2 Modelo Espiral 
 
Figura 2 - Modelo Espiral, Disponível em: 
Mhttp://www.devmedia.com.br/introducao-aos-processos-de-software-e-o-modelo-incremental-
e-evolucionario/29839>, Acesso em jun. de 2015. 
O modelo espiral foi proposto por (Boehm 1988) sendo considerado 
evolucionário, envolvendo todos os outros modelos de processo de software como as 
principais atividades da modelo cascata. Esse processo descreve um fluxo de 
atividade em espiral, onde cada loop representa uma etapa do processo. Deste modo 
Sommerville afirma que: “[...] em vez de representar o processo de software como 
uma sequência de atividades com algum retorno entre uma e outra, o processo é 
realizado como uma espiral”. (SOMMERVILLE, 2007, p. 48), deixando assim de 
apresentar o modelo linear do cascata. 
Segundo Pfleeger: 
“Consequentemente, a concepção das operações é o produto da primeira 
interação e os requisitos são o principal produto da segunda interação. Na 
terceira iteração, o desenvolvimento do sistema produz o projeto, e na quarta, 
habilita os testes”. (PFLEEGER, 2004, p.46). 
 
24 
 
 
Assim o modelo espiral se inicia em determinando os objetivos como 
também soluções e restrições para cada etapa do processo de software, dando como 
também continuidade para cada procedimento por ele realizado. Pressman define o 
primeiro circuito: 
“[...] em volta da espiral pode resultar no processo de desenvolvimento de 
uma especificação de produto; passagens subsequentes em torno da espiral 
pode ser usadas para desenvolver um protótipo e, então, progressivamente, 
versões cada vez mais sofisticadas do software. Cada passagem pela região 
de planejamento resulta em ajustes no planejamento do projeto”. 
(PRESSMAN, 2007, p. 65). 
 
Contudo é um modelo que envolve todos os outros modelos de processo 
de software, ou seja, é um modelo interativo, sendo também um processo evoluído a 
cada etapa de desenvolvimento. 
 
2.3.3 Modelo de Prototipação 
 
Figura 3 - Modelo de Prototipação, Disponivel em: 
<http://www.devmedia.com.br/introducao-aos-processos-de-software-e-o-modelo-incremental-
e-evolucionario/29839> Acesso em jun. 2015. 
 
O modelo de prototipação é a etapa em que é feito o feedback do processo 
de software, onde poderão ser analisados os custos e demais problemas sendo assim 
é uma interação do cliente e todos os outros envolvidos no desenvolvimento do 
software. Segundo Pressman o paradigma da prototipação: 
 
25 
 
“[...] começa com a comunicação. Faz se uma reunião com os envolvidos 
para definir os objetivos gerais do software, identificar quais requisitos já são 
conhecidos e esquematizar quais áreas necessitam, obrigatoriamente, de 
uma definição mais ampla”. (PRESSMAN, 2007, p. 63). 
 
A partir das análises realizadas pelos clientes e desenvolvedores, poderão 
dar início ao procedimento de desenvolvimento do software, Pfleeger afirma que: “[...] 
assim que os usuários e clientes decidem o que realmente querem, os requisitos são 
revisados”. (PFLEEGER, 2004, p. 43) e se inicia a próxima etapa do desenvolvimento. 
Segundo Sommerville o modelo de prototipação é um modelo rápido e 
interativo. 
“Um protótipo é uma versão inicial de um sistema de software usado para 
demostrar conceitos, experimentar opções de projetos e, geralmente, 
conhecer mais sobre o problema e suas possíveis soluções. 
Desenvolvimento rápido e interativo do protótipo é essencial, de modo que os 
custos são controlados e os stakeholders do sistema podem experimentar o 
protótipo mais cedo no processo de software”. (SOMMERVILLE, 2007, p. 
271). 
Os protótipos permitem que o usuário do sistema verifique o que está sendo 
feito além de como será a utilização da aplicação, esse modelo pode ser entregue 
através do computador, em uma folha, não importa a maneira a ser entregue, podendo 
também ser realizada a todo o momento de desenvolvimento do software para que se 
possa ter sempre um feedback do produto e a opinião do cliente. 
 
2.4 Etapas de Engenharia de Software 
 
2.4.1 Especificação 
 
A especificação permite que os envolvidos no desenvolvimento venham a 
definir o que será produzido no software e as suas restrições. SOMMERVILLE, afirma 
que os clientes e engenheiros definem: “[...] o software a ser produzido e as restrições 
para a sua operação”. (SOMMERVILLE, 2007, p.6), neste contexto podem ser 
definidos quantos analistas estará atuando para a criação de uma restrição decidida 
pelos envolvidos. 
 
26 
 
Segundo Zave (1984), citado por Shari Lawrence (2004, p. 43), um modelo 
de processo permite aos desenvolvedores e clientes examinarem antecipadamente 
os requisitos e suas implicações no desenvolvimento, de modo que possam discutir e 
resolver algumas incertezas. No modelo de especificação operacional, os requisitos 
do problema são avaliados ou executados de modo a demonstrar o comportamento 
do sistema”. 
Contudo a especificação delimita cada elemento do sistema, ou seja, 
descreve as informações, sendo assim a função e o desempenho do computador e 
restrições do mesmo. Segundo PRESSMAN (1995, p. 222): “[...] Ela descreve a 
função e o desempenho de um sistema baseado em computador e as restrições que 
orientarão no seu desenvolvimento”. 
Desse modo podemos perceber que há uma semelhança entre a 
especificação e a prototipação onde ambas permitem que o usuário tenha acesso as 
informações nelas contidas, e que venha dar mais sugestões e dicas para um melhor 
desempenho do engenheiro para a conclusão do sistema. 
 
2.4.2 Desenvolvimento 
 
Para Sommerville o software: “[...] é projetado e programado”. 
(SOMMERVILLE, 2007. p. 6). Podemos definir desenvolvimento de software como 
sendo um planejamento e elaboração de um sistema, na qual irá fornecer informações 
que compõem suas características de como fazer, quando fazer, etc. 
Esta etapa pode ser dividida em partes, sendo dividida entre seus 
engenheiros para a melhor distribuição de tempo e funcionalidades de cada questão, 
para que se possa realizar um feedback com o cliente e assim finaliza lo. Para Shari 
Lawrence: “[...] novos modelos de processos são desenvolvidos para ajudar a reduzir 
o tempo de desenvolvimento”. (LAWRENCE, 2004, p.44), é uma etapa que requer 
muito tempo para desenvolver, quanto menor tempo para a realização do 
desenvolvimento do software melhor será para a entrega do produto ao cliente, sendo 
algo que precisa ser elaborado e planejado toda a estrutura do software como também 
o tempo de entrega do mesmo. 
 
27 
 
 
2.4.3 Validação 
 
Mesmo com tantos feedbacks realizados durante a realização do software 
é necessário que haja uma validação do mesmo, onde serão verificados se os 
requisitos vão suprir a necessidade da empresa além de coincidir com o que o cliente 
deseja. Segundo Sommerville validação de software é na qual: “[...] o software é 
verificado para garantir que é o que o cliente deseja”. (SOMMERVILLE, 2007, p.6). 
Segundo Lawence descreve a importância da validação: “é importante 
lembrar que a validação é mais do que uma simples verificação da rastreabilidade. 
Para assegurar que o sistema fará o que os clientes e usuários esperam, devemos 
confirmar que os objetivos e as intenções dos clientes e usuários sejam satisfeitos. 
Do contrário, os projetistas nos ajudarão a construir um sistema que não é o que os 
clientes querem”. (LAWRENCE, 2004, p.143). 
Dessemodo espera se que a validação seja bem sucedida para que o 
cliente esteja satisfeito com os resultados esperados. Segundo PRESSMAN a mesma 
se dá por várias definições mas uma solução simples (se bem que polêmica):” [...] é 
que a validação é bem sucedida quando o software funciona de uma maneira 
razoavelmente esperada pelo cliente”. (PRESSMAN, 1995, p.858). 
Contudo é necessário que exista vários feedbacks com o próprio cliente 
para que o engenheiro compreenda o que o cliente quer para a sua empresa como 
ela imagina que o software vai ajuda ló, sendo assim ficara mais fácil de montar um 
cenário de como o cliente deseja, no entanto que se possa valida ló e estar tudo certo. 
 
2.4.4 Evolução 
 
A evolução de software se dá através da modificação para se adaptar as 
empresas, ou seja, são necessários que as empresas façam uma avaliação de seu 
sistema e o custo que esse software trará para o financeiro da empresa. Pois sendo 
esse software criado para suprir as necessidades de uma grande empresa de vários 
 
28 
 
departamentos saíra com alto custo para uma pequena empresa. Segundo 
Sommerville: “[...] o software é modificado para se adaptar as mudanças dos requisitos 
do cliente e do mercado”. (SOMMERVILLE, 2004, p.6). 
Sendo assim o software irá conter todo o ciclo de vida, porém é de suma 
importância atender aos requisitos que o cliente precisa, é necessário adapta ló para 
uma pequena empresa ou uma grande empresa, ou seja, tem que estar habito para o 
mercado de trabalho, onde a empresa que adquirir dando ao usuário certa confiança 
no seu processamento de dados 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
29 
 
3 UML 
 
A UML (Unified Modeling Language) ou Linguagem de Modelagem 
Unificada foi adotada a partir de 1997 com o objetivo de auxiliar os engenheiros de 
software na caracterização do sistema dentre outras atividades, logo se tornou um 
modelo universal na representação gráfica de softwares, porém não se caracteriza 
como um processo de desenvolvimento, pois a mesma é uma linguagem 
independente. De acordo com Guedes: 
“[...] cumpre destacar que a UML não é um processo de desenvolvimento de 
software e tampouco está ligada a um de forma exclusiva, sendo totalmente 
independente, podendo ser utilizada por muitos processos de 
desenvolvimento diferentes ou mesmo de forma que o engenheiro considerar 
mais adequada”. (GUEDES, 2ed. p 19, 2011) 
 
A UML e comparada por Eduardo Bezerra a uma caixa de ferramenta 
fazendo analogia a um pedreiro que se utiliza das ferramentas contidas na caixa para 
realizar seus afazeres, do modo os engenheiros de softwares, utiliza as ferramentas 
da UML para a construção de seus sistemas. Sabemos que a linguagem de 
modelagem está voltada para representação conceitual e física de um software, assim 
como a UML para a estrutura de projetos de softwares. 
No entanto apenas uma linguagem não é suficiente para a compreensão 
de um sistema tanto para o engenheiro, quanto para seu cliente. Para Jacobson, 
Rumbauch, Booch (p.14, 2005): “[...] Uma linguagem de modelagem é a linguagem 
cujo vocabulário e regras tem seu foco voltado para a representação conceitual e física 
de um sistema”. Guedes também exemplifica em seu livro (UML 2 - Uma Abordagem 
Prática - 2ª Edição) como a UML auxiliar os engenheiros a definirem as características 
do software, se utilizando de seus requisitos, seu comportamento, sua estrutura 
lógica, a dinâmica de seus processos e até mesmo as necessidades físicas sobre a 
máquina que o mesmo será implantado. 
A linguagem UML auxiliar os engenheiros de software, possibilitando vários 
meios (ferramentas) para a representação de um sistema antes do mesmo de seu 
desenvolvimento. Ela e subdividida em três 
 
3.1 Diagramas de Caso de Uso 
 
 
30 
 
O Diagrama de Caso de Uso é utilizado no levantamento de requisitos 
sendo de forma geral e o mais informal da UML, sendo de fácil compreensão e leitura. 
Segundo Guedes (2011, p.30) o diagrama de caso de uso é utilizado: “[...] 
normalmente nas fases de levantamento e analise de requisitos do sistema, embora 
venha a ser consultado durante todo o processo de modelagem e possa servir de base 
para outros diagramas”. 
Jacobson, Rumbaugh e Booch (2005, p241) afirma que o diagrama de caso 
de uso organiza o comportamento do sistema, com seus atores, caso de uso e 
relacionamento. 
“Os diagramas de casos de uso têm um papel central para a modelagem do 
comportamento de um sistema, de um subsistema ou de uma classe. Cada 
um mostra um conjunto de casos de uso e atores e seus relacionamentos”. 
(JACOBSON, RUMBAUGH E BOOCH, 2005, p.241). 
 
Podemos dizer que o caso de uso surge como um relatório de como o 
sistema deverá atuar de acordo com o levantamento de requisitos. Para Bezerra 
(2007, p 54) o caso de uso representa: “[...] um relatório de uso de certa funcionalidade 
do sistema em questão, sem revelar a estrutura e o comportamento internos desse 
sistema”. Estes comportamentos internos no qual é citado por Bezerra é a codificação 
responsável para realizar determinada funcionalidade que o diagrama esteja 
representando. 
O diagrama de caso de uso irá ajudar na implementação do sistema e seus 
comportamentos, assim como sua estrutura e ambiente. Sendo de suma importância 
no desenvolvimento do software pela compreensão, visualização e especificação para 
que se possa documentar o comportamento do software. 
 
3.2 Diagrama de classes 
 
O diagrama de classe tem como objetivo organizar as classes que ira 
conter a aplicação permitindo que as mesmas sejam visíveis bem como seus métodos 
e atributos. Sendo ela de suma importância além de auxiliar o desenvolvimento de 
outros diagramas da UML. Guedes (2011, p101) cita que: “[...] esse diagrama 
 
31 
 
apresenta uma visão estática de como as classes são organizadas, preocupando se 
em como definir a estrutura lógica das mesmas”. 
Este diagrama é composto por suas classes assim como seus 
relacionamentos, sendo encontrado em sistemas orientados a objetos. Assim descrito 
por Jacobson, Rumbaugh e Booch (2005, p 107): “[...] os diagramas de classes são 
os diagramas encontrados com maior frequência na modelagem de sistemas 
orientados a objetos. Um diagrama de classe mostra um conjunto de classes, 
interfaces e colaborações e seus relacionamentos”. 
Portanto o diagrama de classe é constituído por anotações e 
especificações dos seus atributos e métodos, Bezerra (2011, p112) diz que: “O 
diagrama de classes é utilizado na construção do modelo de classes desde o nível de 
análise até o nível de especificação. De todos os diagramas da UML, esse é o mais 
rico em termos de notação”. 
 
3.3 Diagrama de sequência 
 
Este diagrama trata-se de uma sequência de eventos que ocorrem durante 
um processo que o software está realizando, tendo como base o diagrama de caso 
de uso, dependendo também do diagrama de classes. Segundo Guedes (2011, p 192) 
o diagrama de sequência é uma excelente forma de validar e complementar o 
diagrama de classe: “[...] pois é ao modelar um diagrama de sequência que se percebe 
quais métodos são necessários declarar em que classe”. 
O diagrama de sequência tem como objetivo a ordem em que as atividades 
serão efetuadas, mostrando graficamente cada processo. Bezerra (2011, p193) diz 
que o objetivo do diagrama de sequência: “[...] é apresentar as interações entre 
objetos na ordem temporal em que elas acontecem”. 
Desse modo o diagrama de sequência da ênfase a ordenação das 
mensagens, observando a importância das transações de mensagens ocorridas no 
mesmo, objetivando os passos para a modelagem. Segundo Jacobson, Rumbaughe 
 
32 
 
Booch (2005, p 255) afirma que: “[...] o principal conteúdo em um diagrama de 
sequência é o conjunto de mensagens”. 
Com este diagrama podemos observar a importância da conectividade de 
cada diagrama, ou seja, um diagrama complementa e facilita o entender do diagrama 
anterior ou posterior a ele. A sequência de atividades dentro de um software ira 
influenciar nos afazeres que o sistema irá realizar, constituindo assim passos para um 
bom software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
33 
 
4 ESTUDO DE CASO 
 
4.1 Análise inicial 
 
Um laboratório de análises clinicas realiza seus procedimentos de 
agendamento de clientes e exames por meio de um sistema que atualmente vem 
proporcionando falhas para cadastro de cliente e exame. Este por sua vez está há 
muito tempo na empresa e por falta de atualização do sistema, veio à defasagem de 
suas ferramentas, ocasionando a impossibilidade de responder as expectativas da 
empresa. O mesmo não possui disponibilidade ao laboratório para que possa verificar 
os resultados dos exames, seus horários agendados entre outras situações. 
Iremos oferecer ao cliente formas mais simples e eficazes de se realizar as 
tarefas do dia a dia, modernizando processos, como recebimentos que até então é 
feito apenas com dinheiro. No intuito de acompanhar as novas tendências do mercado 
“consumidor”, iremos realizar transações com cartão de crédito e débito para que o 
laboratório possa oferecer melhores possibilidades aos clientes na hora do 
pagamento, que até então é feito no papel e na caneta na hora que o cliente pega o 
resultado do exame e sem um extrato final dos lucros obtidos. 
O novo sistema disponibilizara melhor condições para agendamento e 
cadastro de exames e clientes com maior agilidade, disponibilizando históricos, 
relatórios de suas principais funções de acordo com a necessidade da empresa e o 
controle de pagamentos dos serviços prestados. O sistema terá por sua vez a 
possibilidade de acessos, impressão e agendamento de horários via web. 
Economia de tempo e melhores tomadas de decisões são alguns dos 
aspectos que influenciará para rendimento de atividades, crescimento da empresa, 
interesse do cliente pelos serviços prestados, destaque no mercado, entre outros 
benefícios. 
 
 
 
34 
 
4.1.2 Tabela de requisitos 
Tabela 1 - Requisitos 
N° 
Requisitos 
Interesse Motivo Solicitante Data Atores 
R1 Gerenciar 
clientes 
Obter controle sobre os 
clientes e dados 
pessoais. 
Gerente 06/04/15 Secretária 
R2
 
 
Agendar 
horários 
Controlar a quantidade e 
a capacidade de clientes 
atendidos ao dia. 
Gerente 06/04/15 Secretária 
e cliente 
R3 Cadastrar 
médicos 
Para controle de contato 
de exames por médicos. 
Gerente 06/04/15 Secretária 
R4 Gerenciar 
convênios 
Controle de convênios 
existentes. 
Gerente 06/04/15 Gerente 
R5 Cadastrar 
funcionários 
Acesso do funcionário ao 
sistema e controle dos 
dados. 
Gerente 06/04/15 Gerente 
R6 Gerar 
Relatórios 
Ter controle sobre as 
atividades realizadas no 
sistema. 
Gerente 06/04/15 Gerente e 
secretária 
R7 Cadastrar 
exames 
Controle e manter um 
histórico para melhor 
acompanhamento do 
cliente. 
Gerente 06/04/15 Secretária 
R8 Confirmar 
realização 
de exame 
Verificar a realização do 
exame. 
Gerente 06/04/15 Enfermeira 
 
35 
 
R9 Aprovar 
exame 
Controle para que os 
exames esteja em 
perfeitas condições. 
Gerente 06/04/15 Biomédica 
R10 Controlar 
pagamento 
Controle de exames 
pagos ou ainda em 
dividas. 
Gerente 06/04/15 Gerente e 
secretária 
 
4.2 Lista de requisitos não funcionais 
 
 
 Integração com banco de dados para armazenamento de informações. 
 Autenticação para clientes e funcionários, para delimitar funções e ações no 
software. 
 Software de fácil manuseio, descrições das funções, com padrões em palavras 
e ícones de fácil compreensão. 
 Módulos de segurança (tratamento contra falhas, fraudes, backup e 
restauração de dados, etc.), para proteção dos dados e evitar a perca dos 
mesmos. 
 Procurar manter o maior desempenho possível ao software. 
 A aplicação deverá ter total funcionalidade nos seguintes sistemas 
operacionais Windows e Linux; 
 
4.3 Análise de entrevista 
 
 
Ao se realizar a entrevista pode se perceber as dificuldades e as 
necessidades em que o cliente possui. A implantação do novo sistema vai suprir as 
necessidades da empresa, trazendo assim agilidade e facilidade em suas diversas 
tarefas. 
 
36 
 
Deparamos com um sistema atual que contem falhas e pequenos detalhes 
que precisam ser corrigidos, para não ocorrer perigos de influenciar nos resultados 
finais dos exames, que por sua vez poderiam gerar sérios problemas para a empresa. 
Além de não ter uma interface intuitiva para seus usuários sendo de difícil 
compreensão por não possuir botões, ícones e outras formas de facilitar uma melhor 
compreensão do que está sendo realizado no sistema. 
Em seu laboratório o cliente possui diversas dificuldades uma delas são os 
agendamentos de clientes que são realizados manualmente em uma agenda. Além 
da correção de falhas no cadastro como a falta de campos necessário para melhor 
avaliação dos resultados obtidos nos exames do cliente. Existe ainda a redundância 
de informações no banco de dados, como no caso de apenas um cliente conter vários 
cadastros, pela impossibilidade do sistema atual reutilizar o primeiro cadastro e não 
conseguir de forma ágil e fácil mostrar ao operador do software os exames feitos por 
este paciente, não sendo necessário a utilização de vários códigos para procurar 
exame realizado pelo mesmo. 
Outro fato de que pede melhoria está no fato que o sistema somente tem 
seu funcionamento em uma máquina, impedindo que duas pessoas o acesse 
simultaneamente tendo que esperar que um termine suas ações para que o próximo 
venha a utilizar o sistema. Com as novas formas de pagamentos que sugiram no 
mercado, o módulo de pagamentos deste software deixou de auxilia-lo pois não tem 
suporte a tecnologias como (credito, debito e outros). 
 
 
 
 
 
 
 
 
 
37 
 
4.4 Diagramas de casos de uso 
 
Figura 4 - Diagrama de caso de negocio 
 
 
 
38 
 
 
Figura 5 – Diagrama de caso de uso 
 
39 
 
4.5 Requisitos de dados 
 
 
Figura 6 - Modelo Relacional Normalizado 
 
40 
 
4.6 Diagrama de Classe (Dados estruturais) 
 
 
Figura 7 - Diagrama de Classe 
 
41 
 
4.7 Diagrama de Sequência (Eventos temporais) 
 
 
Figura 8 - Diagrama de Sequência de Agenda 
 
 
 
42 
 
 
Figura 9 - Diagrama de Sequência de Cliente 
 
43 
 
 
Figura 10 - Diagrama de Sequência de Convenio 
 
44 
 
 
Figura 11 - Diagrama de Sequência de Exame 
 
 
 
 
 
 
 
45 
 
4.8 FERRAMENTAS (softwares, HARDWARE E equipamento utilizado). 
 
As Ferramentas CASE, são ferramentas que auxiliam no processo de 
desenvolvimento de software. Para cada tipo de desenvolvimento de sistema existe 
uma ferramenta case para auxiliar o analista na sua criação, seja no banco de dados 
ou nos diagramas, são ferramentas que abrangem desde a análise e levantamentos 
de requisitos até a programação e testes no sistema. São ferramentas que são de fácil 
manutenção e manuseio, além de facilitar o trabalho do analista e tem por função ser 
mais rápido, ou seja, reduz o tempo gasto. 
A ferramenta utilizada para a criação dos protótipos foio netbeans 8.1, e 
para os relatórios que a aplicação irá realizar a ferramenta iReport 5.6.0. 
Na elaboração dos diagramas, sendo eles os diagramas de caso de uso de 
software, o caso de uso de negócio, o diagrama de classes e os diagrama de 
sequência de exames, agenda, cliente e convenio, foi usada a 
ferramenta Astah Community 7.0. 
Para a análise e modelagem das tabelas do banco, foi 
utilizado MySQL Workbench 6.3, para descrever o MRN onde é descrito as tabelas 
do SGBD e suas respectivas ligações. 
 
 
46 
 
5 CONSIDERAÇÕES FINAIS 
 
A ideia do projeto é implementar um sistema de forma que esse venha se 
adequar ás condições propostas e transparecer conforme o que convêm em seus 
capítulos, ao usuário final. 
Uma das hipóteses levantada é que o system labor poderia desempenhar 
um acesso fácil dessas informações, que ao longo do tempo seja adquirida por ele. 
Para o desenvolvimento do projeto foram feitas entrevistas com algumas empresas 
que trabalham com a área de laboratório de análises clínicas, pesquisas pela internet 
visitando alguns sites de laboratórios. A metodologia foi realizada através de livros, 
sites de ajuda e até mesmo outros projetos criados pelos acadêmicos do curso de 
sistemas de informação. 
 
 
47 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
PRESSMAN, Roger S., Engenharia de Software Uma Abordagem Profissional - 7ª 
edição, AMGH Editora Ltda. 2011. 
PRESSMAN, Roger S., Engenharia de Software - 6ª Edição, McGraw-Hill, 2006 
 
SOMMERVILLE, Lan, Engenharia de Software 8ª edição, São Paulo, Person 
Education, 2007. 
 
MAGELA, Rogério, Engenharia de Software Aplicada Fundamentos, Rio de Janeiro, 
Alta Books, 2006. 
 
PFLEEGER, Shari Lawrence, Engenharia de Software Teoria e Prática, São Paulo, 
Prentice Hall, 2004. 
 
BARROS, de Marcelo, Engenharia de Software. Disponível em: 
<http://pt.slideshare.net/daniellobao/4-eng-requisitos >. Acesso em: 29 mai. 2015. 
 
GUEDES, GILLEANES T.A.UML2 uma abordagem pratica. Edição são Paulo novatec 
editora 2011. 
FURGERI, SÉRGIO, java 6: ensino didático: desenvolvendo e implementando 
aplicações 2edição são Paulo Érica 2008. 
BOOCH, GRADY, RUMBAUGH, JAMES JACOBSON, Ivar UML guia do usuario Rio 
de Janeiro Elsevier 2005, 2 Edição. 
 
 
 
48 
 
APÊNDICE 
Entrevista realizada com o Gerente Luiz Antônio Campos Cabral Junior ao 
dia nove de abril de dois mil e quinze. 
1) De que maneira o cliente pode efetuar o pagamento dos exames? 
R: Pagamento é a vista, mas gostaria que o meu cliente pudesse pagar tanto 
no dinheiro, cartão e em alguns casos posso fazer com boletos a 30 dias para 
pagamento. 
 
2) Qual o problema encontrado no sistema atual e de que maneira pode ser 
melhorado no próximo sistema? 
R: Não imprime com impressoras utilizando a porta usb e necessário utilizar 
portas paralelas, gostaria de o programa funcionar em mais de um computador 
no laboratório. 
 
3) A empresa possui algum tipo de convênio particular ou público, com médicos 
da região? 
R: O laboratório tem convênios com o Ipasgo, sus e com algumas empresas 
particulares. 
 
 
4) Existe possibilidade de envio dos resultados exames para os médicos? 
R: Em alguns casos quando o cliente já pede para o médico aceitar o exame 
enviado via e-mail ou em convênios particulares cujo o médico solicite. 
 
 
5) Quais os relatórios o sistema poderá gerar para melhor atender sua empresa? 
R: A quantidade de exames realizados pelo laboratório, convênios em que 
estes exames foram realizados. 
 
6) Quais cadastros serão necessários para melhor ajuda-lo em sua empresa? 
R: Os cadastros que irão me ajudar e o cadastro de cliente, exames e o 
agendamento de horários. 
 
 
49 
 
7) O sistema disponibilizará um histórico dos exames de seus clientes? 
R: O histórico dos exames realizados anteriormente por meus clientes é de 
suma importância, pois com ele vou poder acompanhar melhor o estado clínico 
de cada paciente, além de saber como está sua alimentação e a prática de 
exercícios. 
 
8) O exame ficara disponível via WEB para seus clientes por qual período de 
tempo? 
R: Gostaria que não ficasse muito tempo para não poder ser reutilizado já que 
exames tem data de validade após um mês de feito não é mais aceitos pelos 
médicos, pois o organismo da pessoa pode sofrer alterações durante este 
período. 
 
9) Quais os recursos serão disponibilizados para o seu cliente via web? 
R: Apenas o básico mesmo como o agendamento de horários, um possível pré-
cadastro dos clientes e para exames particulares a impressão dos exames e 
acesso a digitalização da receita médica. 
 
10) Qual o método utilizado para o agendamento dos exames e cadastramento de 
cliente? 
 
R: O agendamento de meus clientes e feito de forma manual por minha 
secretaria, já o cadastro de cliente e feito no sistema que irá ser substituído, 
porem apresenta muitos erros como dificuldades, tenho que sempre cadastrar 
o mesmo cliente várias vezes. 
 
 
Entrevista realizada com a Secretaria Aline Ferreira Costa ao dia dez de 
abril de dois mil e quinze. 
 
 
1) Qual o problema encontrado no sistema atual e de que maneira pode ser 
melhorado no próximo sistema? 
 
50 
 
R: 
- Sempre e necessário fazer um novo cadastro quando o paciente vai fazer um 
exame, pois o sistema da erro nos dados do paciente se utilizar um cadastro 
antigo. 
- Para ter acesso a um cadastro de um cliente feito anteriormente tem que 
digitar o nome do paciente e procurar todos os códigos até encontrar o cadastro 
que deseja, depois sai dessa parte o sistema, entra em outra digitando o código 
para ter acesso ao cadastro antigo. 
- no campo de cadastro de exames cabem apenas 10 exames, se houver mais 
tem que efetuar um novo cadastro para o mesmo paciente gerando assim outro 
código. 
 
2) Qual o método utilizado para o agendamento dos exames e cadastramento de 
cliente? 
R: O agendamento e feito por agenda. O paciente deve contem a receita 
médica, informar o nome completo, data de nascimento, endereço e os 
números de telefone. 
 
3) Existem observações ou restrições que necessita ser tratadas com uma maior 
atenção? 
R: O sistema deveria sim ter campos de observações, no caso se ele e 
diabético ou possui alguma doença contagiosa ou faz algum tratamento que o 
uso de medicamentos poderia afetar os resultados dos exames, assim 
facilitaria na hora de conferir os resultados atuais com os resultados antigos 
não precisaria ficar procurando nos vários cadastros se ele já teve alguma 
alteração em um de seus exames. 
 
4) O que agilizaria o cadastramento dos exames no sistema? 
R: Agilizaria se toda vez não tivesse que cadastrar o paciente todas as vezes 
que ele for fazer novos exames. Além do acesso a este cadastro por meio de 
nome ou cpf, não precisando encontrar o código de cada cadastro feito para 
aquele paciente. 
 
 
51 
 
Protótipos 
 
Figura 12 - Protótipo Alto nivel - Tela Principal 
 
52 
 
 
Figura 13 - Protótipo Alto Nivel - Tela de Exames 
 
53 
 
 
Figura 14 - Protótipo Alto Nível -Tela de busca de exames 
 
54 
 
 
Figura 15 - Protótipo de Alto nível - Tela de convênios 
 
55 
 
 
Figura 16 - Protótipo de Alto nível - Tela de Cadastro de Funcionário 
 
56 
 
 
Figura 17 - Prototipo de Alto Nivel - Tela de Cadastro de Clientes 
 
 
57 
 
 
Figura 18 - Protótipo Alto nível - Tela de Agenda 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
58 
 
 
 
 
Figura 19 - Protótipo de Baixo Nível - Tela Principal 
 
59 
 
 
 
 
Figura20 – Protótipo Baixo Nível - Tela de Exames 
 
 
 
 
 
60 
 
 
 
Figura 21 - Protótipo Baixo Nível -Tela de busca de exames 
 
61 
 
 
Figura 22 - Protótipo de Baixo nível - Tela de convênios 
 
 
62 
 
 
Figura 23 - Protótipo de Baixo nível - Tela de Cadastro de Funcionário 
 
63 
 
 
Figura 24 - Protótipo de Baixo Nível - Tela de Cadastro de Clientes 
 
64 
 
 
 
 
 
 
Figura 25 - Protótipo Alto nível - Tela de Agenda 
	INTRODUÇÃO
	1 Engenharia de requisitos
	1.1 Requisitos
	1.2 Requisitos Funcionais
	1.3 Requisitos não funcionais
	1.4 Levantamento de requisitos
	1.5 Validação de requisitos
	2 Engenharia de software
	2.1 Software
	2.2 Processos de Software
	2.3 Modelo de Processo de Software
	2.3.1 Modelo cascata
	2.3.2 Modelo Espiral
	2.3.3 Modelo de Prototipação
	2.4 Etapas de Engenharia de Software
	2.4.1 Especificação
	2.4.2 Desenvolvimento
	2.4.3 Validação
	2.4.4 Evolução
	3 UML
	3.1 Diagramas de Caso de Uso
	3.2 Diagrama de classes
	3.3 Diagrama de sequência
	4 ESTUDO DE CASO
	4.1 Análise inicial
	4.1.2 Tabela de requisitos
	4.2 Lista de requisitos não funcionais
	4.3 Análise de entrevista
	4.6 Diagrama de Classe (Dados estruturais)
	4.7 Diagrama de Sequência (Eventos temporais)
	4.8 FERRAMENTAS (softwares, HARDWARE E equipamento utilizado).
	5 CONSIDERAÇÕES FINAIS
	REFERÊNCIAS BIBLIOGRÁFICAS
	APÊNDICE