Pim V

UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar - PIM V
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
MIRIAN CARLA CORRÊA - RA: 0547594
SISTEMA DE RESERVA DE EQUIPAMENTOS
RIBEIRÃO PRETO-SP
2021
MIRIAN CARLA CORRÊA - RA: 0547594
SISTEMA DE RESERVA DE EQUIPAMENTOS
Projeto Integrado Multidisciplinar V - PIM V
Projeto Integrado Multidisciplinar para a obtenção

do título de graduação em Curso Superior de
Tecnologia em Análise e Desenvolvimento de
Sistemas, apresentado à Universidade Paulista -
UNIP EaD.
Orientador: Professora Patricia Toffolo
RIBEIRÃO PRETO-SP
2021
AGRADECIMENTOS
Em agradecimento aos professores do segundo semestre do Curso Superior de Tecnologia em

Análise e Desenvolvimento de Sistemas que compartilharam conosco seus ensinamentos, nos
guiando nas aulas com ensinamentos e inspiração.
RESUMO
O Projeto Integrado Multidisciplinar V tem por objetivo utilizar os conhecimentos adquiridos

nas disciplinas apresentadas ao longo do semestre, sendo elas: Economia e Mercado,
Engenharia de Software II, Projeto de Interface com o Usuário e Programação Orientada a
Objetos I, para a elaboração de um Sistema de Informação. O Sistema foi idealizado com a
finalidade de controlar as reservas de equipamentos de multimeios do Colégio Vencer
Sempre, permitindo realizar o cadastro de equipamentos, cadastro de usuários e emissão de
relatórios, como o de reservas do dia. O Projeto constata o ciclo de vida da construção de um
software, desde o orçamento, previsão de gastos, cronograma de entrega, levantamento,
análise e documentação dos requisitos, prototipação, interfaces, testes e implantação do
produto junto ao usuário.
Palavras chave: Projeto. Sistema de Informação. Reserva de equipamentos.

ABSTRACT
The Integrated Multidisciplinary Project V aims to use the knowledge acquired in the
disciplines presented throughout the semester, which are: Economy and Market, Software
Engineering II, User Interface Design and Object-Oriented Programming I, for the elaboration
of an Information System. The system was conceived with the purpose of controlling the
reservation of multimedia equipment at the Vencer Sempre School, to register the equipment,
register users and issue reports, such as the daily reservation. The project shows the life cycle
of software construction, from the budget, forecast of expenses, delivery schedule, survey,
analysis and documentation of requirements, prototyping, interfaces, tests and product
implementation with the user.
Key words: Project. Information System. Equipment Reservation.

SUMÁRIO
1. INTRODUÇÃO...........................................................................................11
1.1. OBJETIVOS DO PROJETO.............................................................................11

1.1.1. Objetivo geral.....................................................................................11
1.1.2. Objetivos específicos..........................................................................11
1.2. GESTÃO DE CONHECIMENTO.....................................................................12
1.3. SISTEMA ATUAL RESERVA DE EQUIPAMENTOS..........................................13
1.3.1. Dificuldades apresentadas pelo modelo atual.....................................14
1.4. SOLUÇÃO PROPOSTA..................................................................................14
1.4.1. Ferramentas de implementação..........................................................15
1.4.1.1. MySQL..........................................................................................15
1.4.1.2. PHP.............................................................................................16
1.4.1.3. Apache.........................................................................................16
2. ECONOMIA E MERCADO......................................................................16
2.1. MERCADO DE ATUAÇÃO............................................................................17

2.2. AGENTES ECONÔMICOS.............................................................................17
2.2.1. Agentes econômicos identificados no projeto....................................18
2.3. GERENCIAMENTO DO TEMPO DO PROJETO.................................................18
2.3.1. Cronograma........................................................................................20
2.4. VIABILIDADE ECONÔMICA E FINANCEIRA DO PROJETO.............................20
2.4.1. Custo do projeto..................................................................................22
3. ENGENHARIA DE SOFTWARE II........................................................22
3.1. QUALIDADE DE SOFTWARE........................................................................23

3.2. NORMAS DE QUALIDADE...........................................................................23
3.2.1. ISO 9126.............................................................................................24
3.2.2. MPS-BR..............................................................................................25
3.3. CLASSIFICAÇÃO DOS REQUISITOS..............................................................27
3.3.1. Engenharia de requisitos.....................................................................27
3.3.2. Requisitos Funcionais.........................................................................29
3.3.3. Requisitos não funcionais...................................................................30
3.3.4. Regras de negócio...............................................................................31
3.4. DOCUMENTAÇÃO DO PROJETO..................................................................31
3.5. PLANEJAMENTO DE TESTES.......................................................................33
3.5.1. Metodologia e Ferramentas................................................................35
3.5.2. Casos de teste......................................................................................35
3.5.3. Roteiros de teste...................................................................................35
3.5.3.1. Especificações de Interface..........................................................36
4. PROJETO DE INTERFACE COM O USUÁRIO..................................52
4.1. ESPECIFICAÇÃO DA INTERFACE.................................................................52

4.1.1. IHC- interação humano-computador..................................................53
4.2. CASOS DE USO..........................................................................................54
4.3. PROTÓTIPO................................................................................................62
5. Programação Orientada a Objetos............................................................69
5.1. OBJETOS....................................................................................................70
5.2. CLASSES....................................................................................................70
5.3. HERANÇA..................................................................................................70
5.4. POLIMORFISMO..........................................................................................71
5.5. CLASSES E HERANÇAS DO SISTEMA..........................................................71
6. Conclusão.....................................................................................................73
7. REFERÊNCIAS..........................................................................................74
TABELA DE ILUSTRAÇÕES
Figura 01 - Evolução dos Sistemas de Informação e comunicação.....................................12
Figura 02 - Custos do Projeto.......................................................................................22
Figura 03 - MPF-SW..................................................................................................26
Figura 04 - Requisitos Funcionais.................................................................................29
Figura 05 - Requisitos Não Funcionais..........................................................................30
Figura 06 - Regras de Negócio......................................................................................31
Figura 07 - Descrição Requisitos Funcionais..................................................................32
Figura 08 - Processo de Teste de Software.....................................................................34
Figura 09 - Casos de Teste...........................................................................................35
Figura 10 - Especificações de Interface..........................................................................36
Figura 11 - Roteiro de Teste 01 | Login no Sistema.........................................................38
Figura 12 - Evidência: Tela 01 - Principal | Login e Senha...............................................38
Figura 13 - Roteiro de Teste 02 - Login Incorreto no Sistema...........................................38
Figura 14 - Evidência: Tela Inicial | Mensagem Erro Login e Senha.................................39
Figura 15 - Roteiro de Teste 03 | Cadastro de Usuário no Sistema com Sucesso..................39
Figura 16 - Evidência: Tela 02 - Usuários | Administrador..............................................40
Figura 17 - Evidência: Tela Usuários | Administrador - Mensagem Usuário Cadas.............41
Figura 18 - Evidência: Tela Usuários | Administrador - Definir Perfil de Usuário..............41
Figura 19 - Roteiro de Teste 04 | Cadastro de Usuário já cadastrado no Sistema................42
Figura 20 - Evidência: Tela Usuários | Administrador - Mensagem Usuário Já Cadastrado.42
Figura 21 - Roteiro de Teste 05 | Busca de Usuários no Sistema........................................43
Figura 22 - Evidência: Tela Usuários | Administrador - Buscar Usuário............................44
Figura 23 - Evidência: Tela Usuários | Administrador - Resultado da Busca......................44
Figura 24 - Evidência: Tela Usuários | Administrador - Usuário Não Encontrado..............45
Figura 25 - Roteiro de Teste 06 | Cadastro de Equipamentos no Sistema com Sucesso.........45

Figura 26 - Roteiro de Teste 07 | Reservar Equipamentos no Sistema...............................46
Figura 27 - Evidência: Tela 04 - Nova Reserva | Administrador - Reserva de Equipamentos 47
Figura 28 - Evidência: Tela Equipamentos | Administrador - Confirmação Reserva de
Equipamentos.......47
Figura 29 - Roteiro de Teste 08 | Busca e Cancelamento de Reservas de Equipamentos no
Sistema.........48
Figura 30 - Evidência: Tela Equipamentos | Administrador - Confirmação Cancelamento
Reserva de Equipamentos.....49
Figura 31 - Roteiro de Teste 09 | Busca de Reservas de Equipamentos no Sistema..............49
Figura 32 - Evidência: Tela 07 - Nova Reserva | Usuário.................................................50
Figura 33 - Roteiro de Teste 10 | Reservar Equipamentos no Sistema...............................50
Figura 34 - Evidência: Tela 07 - Nova Reserva | Usuário.................................................51
Figura 35 - Evidência: Tela Nova Reserva | Usuário - Mensagem Reserva Realizada..........52
Figura 36 - Diagrama de Caso de Uso | Administrador....................................................54
Figura 37 - Diagrama de Casos de Uso | Usuário............................................................55
Figura 38 - Caso de Uso 01 | Login no Sistema...............................................................55
Figura 39 - Caso de Uso 02 | Cadastro de Usuários no Sistema.........................................56
Figura 40 - Caso de Uso 03 | Busca de Usuários no Sistema..............................................57
Figura 41 - Caso de Uso 04 | Definir Perfil de Usuário.....................................................58
Figura 42 - Caso de Uso 05 | Cadastro de Equipamentos no Sistema.................................59
Figura 43 - Caso de Uso 06 | Reserva de Equipamentos no Sistema...................................60
Figura 44 - Caso de Uso 07 | Consulta de Reserva de Equipamentos no Sistema.................61
Figura 45 - Caso de Uso 08 | Cancelamento de Reserva de Equipamentos no Sistema.........61
Figura 46 - Tela 01 - Principal | Login e Senha...............................................................63
Figura 47 - Tela 02 - Usuários | Administrador..............................................................64
Figura 48 - Tela 03 - Equipamentos | Administrador - Busca Equipamentos......................64
Figura 49 - Tela 04 - Nova Reserva | Administrador - Reserva de Equipamentos...............65

Figura 50 - Tela 05 - Reservas | Administrador..............................................................66
Figura 51 - Tela 06 - Reservas | Usuário........................................................................67
Figura 52 - Tela 07 - Nova Reserva | Usuário.................................................................68
Figura 53 - Classes e Heranças.....................................................................................71

11
1. INTRODUÇÃO
O Colégio Vencer Sempre disponibiliza equipamentos, tais como: data show, TV

com VCR, TV com DVD, Projetor de Slides, Microfone, Caixa Amplificada, Notebooks, Kits
Multimídia, etc., como ferramentas de apoio para aulas e palestras aos professores e
coordenadores da instituição, alocando-os em salas de aula e auditórios, a pedido antecipado
dos colaboradores. O Sistema de Reserva de Equipamentos e recursos audiovisuais tem como
propósito agilizar e controlar o empréstimo de equipamentos e recursos de apoio aos
professores e dos demais colaboradores que necessitem utilizá-los.
Utilizando as técnicas aprendidas nas disciplinas de
Segundo FONSECA (2015, p.76), “a importância de se desenvolver sistemas para

automatizar o controle e reserva de algum tipo de serviço é algo que se identifica há muitos
anos.”
Segundo REZENDE E ABREU (2000), “os sistemas operam, principalmente,

como ferramentas para executar o desempenho da empresa e suas abrangências, como
facilitadores dos processos internos e externos, meios para absorver a qualidade,
produtividade e inovação tecnológica organizacional.”
1.1. Objetivos do projeto
1.1.1. Objetivo geral
• Desenvolver uma solução para a gestão das reservas de equipamentos multimídia do

Colégio Vencer Sempre.
1.1.2. Objetivos específicos

12
• Sistema de informação como solução que permite a gestão de reserva de

equipamentos;
• Conceder ao administrador o controle do cadastro de equipamentos e usuários;
• O sistema permitir ao usuário realizar reservas de equipamentos;
• O sistema disponibiliza o relatório de reservas de acordo com a data e horário
selecionados.
1.2. Gestão de Conhecimento
A figura abaixo remete a visão piramidal da evolução dos sistemas de informação

referida por Martin (1982), Martin e Leben (1989), adaptada e apresentada por Pacheco e
Kern (2003), com base no trabalho de Pant e Hsu (1995), dá uma ideia de como a tecnologia
da informação e comunicação evoluiu nas organizações. Nota-se, pois, ao longo do tempo,
conforme O’Brien (2004), considerável expansão das funções dos sistemas de informação
computadorizados, causando impacto a usuários finais e a gestores das organizações.
Figura 01 - Evolução dos Sistemas de Informação e comunicação
Fonte: Martin (1982), Martin e Leben (1989) e Pacheco e Kern (2003).

13
Os sistemas de controle de reservas possuem um papel importante para organizar

os bens e serviços de instituição.
O domínio e organização sobre os dados e informações é fundamental para

qualquer tipo de serviço ou atendimento prestado.
“Governança de dados é uma técnica para gerenciar informações por toda a

organização.” (R. KE RAINER JR; CASEYCEGIELSKI, 2011, p.35).
Segundo R. KE RAINER JR, CASEY CEGIELSKI (2011, p. 22), “para serem

lucrativas, as empresas precisam desenvolver uma estratégia para gerenciar esses dados de
forma eficiente. “
Segundo SCHMITT ap ud LAUDON e LAUDON (1999, p.4) “um sistema de

informação (SI) pode ser qualificado para ter a aplicabilidade de tratar as informações com a
finalidade de facilitar o planejamento, o controle, a coordenação, a análise e o processo
decisório em empresas. “
Dessa maneira, verifica-se a necessidade do desenvolvimento de um sistema de

controle para reservas do uso de equipamentos multimídia para o Colégio Vencer Sempre.
1.3. Sistema atual reserva de equipamentos
Atualmente os equipamentos multimídia disponibilizados pelo Colégio Vencer

Sempre, como apoio pedagógico para incremento de aulas, palestras e outros eventos, são
reservados pelos usuários de da seguinte forma:
1º O usuário (professor, coordenador, etc.) dirige-se até a secretaria do Colégio

Vencer Sempre.
2º O usuário solicita a reserva, informando o equipamento que será utilizado, a

data e horário de utilização e qual será o evento;
14
3º A reserva do equipamento é registrada no livro, assim como o nome do usuário,

geralmente o professor e também a aula, palestra ou outro evento onde o equipamento será
utilizado.
A reserva é registrada manualmente em um caderno chamado de "Reservas de

Equipamentos" utilizado pela secretaria do colégio.
1.3.1. Dificuldades apresentadas pelo modelo atual
O modelo atual apresenta algumas dificuldades:
1º O método de busca não é eficiente;
2º Pode ocorrer duplicidade de reservas;
3º Podem ocorrer falhas ou esquecimento do registro da reserva.
1.4. Solução proposta
Em tempos de tecnologia e de um mercado recheado de novas demandas, as

instituições precisam se adequar e informatizar, sistematizar as funções que até então são
feitas a próprio punho e no papel.
Hoje os sistemas de software fazem parte da vida e do cotidiano de cada vez mais
pessoas. Informação e conhecimento são com certeza a principal alavanca da economia. A
Tecnologia da Informação influencia de forma elevada no desempenho de todos os setores
econômicos, sejam estes públicos ou privados, e é também um setor extremamente dinâmico e
de elevado peso econômico.
Nesse ambiente de diferentes demandas de atividades e funções, as empresas

precisam criar novas formas de lidar com os problemas e com a rotina empresarial. Nesse
sentido, a tecnologia de informação pode representar um grande auxílio para que os
15
administradores desenvolvam soluções inovadoras para uma ampla gama de problemas.

(KLEINSORGE 2015, p. 22).
Aí que entram em cena os mais diferentes modelos de sistemas de informação,

como por exemplo, os de gestão de reservas, para atuarem na resolução de problemas.
1.4.1. Ferramentas de implementação
1.4.1.1. MySQL
Banco de Dados é basicamente um conjunto de informações organizadas e de fácil

acesso, permitindo o gerenciamento e atualizações das informações disponíveis no sistema.
O MySQL , desenvolvido na década de 90, por David Axmark, Allan Larsson e

Michael Widenius., é um banco de dados open source, de qualidade. Possui características
que o fazem ser consistente, como: alta performance, confiabilidade, fácil usabilidade, com
isso é um dos mais escolhidos pelos desenvolvedores.
Dentre as características do MySQL, há todas as funções de um sistema

gerenciador de banco de dados, além disso armazenar dados de multiacesso, com completas
atividades de outros bancos de dados como, gerenciamento de acesso, integridade dos dados e
relacional, concorrência, transações entre outros (MILANÍ, 2007, p. 26).
Com essas funções um gerenciador de banco de dados é um dos pontos principais

de um sistema, website ou um simples projeto de solução rápida, pois a importância de
descriminar detalhadamente todas as informações dos dados, assim com mais informações do
tipo dos dados o armazenamento tem que ser da forma proposicional a compreender todos os
dados das tabelas, que MySQL disponibiliza vários tipos de tabelas para armazenamento de
dados, tendo cada tipo a suas próprias características, sendo assim, é possível escolher a
melhor que se adequa a função que será designada. (MILANÍ, 2007, p.26).
Qualificado o MySql dentre as funções de uso básico até mais elevadas, com
criação de banco de dados e tabelas, inserir, excluir e alterar dados, efetuar rotinas de backup
e recovery, criar e dar privilégios a usuários. O armazenador de informações mais diversas e
quase sempre importantes, torna-se necessário ter segurança sob os dados recebidos, na hora
de inserir dados restritos o MySQL trabalha com criptografia no tráfego de senhas e os
16
serviços de firewall de autenticação que determina o responsável por se habilitar na utilização

do serviço. (MILANÍ, 2007, p.26)
1.4.1.2. PHP
Segundo TATROE, MACINTYRE e LERDORF (2013), “o PHP tem amplo

suporte para bancos de dados. O PHP suporta todos os principais bancos de dados (incluindo
o MySql). “
No Desenvolvimento de Softwares, o uso de linguagens de programação é

trabalhado, adequando a melhor linguagem às funções que serão realizadas pelo sistema.
O PHP (personal home page). é uma linguagem multiplataforma, possui biblioteca

de códigos, é prática e adequada para o desenvolvimento de sistemas web.
1.4.1.3. Apache
Apache é um servidor Open Source, alimenta cerca de 46% de todos os sites que
estão hospedados na internet, sendo um dos servidores mais antigos e confiáveis.
Ele estabelece conexão entre o servidor e os navegadores de sites como (Internet

Explorer, Mozilla Firefox, Google Chrome, etc.).
“O Apache Software Foundation é uma pedra fundamental do ecossistema de

software de código aberto moderno - suportando algumas das soluções de software mais
usadas e importantes que alimentam a economia atual da Internet." - Mark Driver, vice-
presidente de pesquisa da Gartne
2. ECONOMIA E MERCADO
(MENDES, 2004) “O mercado é um local ou ambiente social / virtual, no qual

agentes econômicos, realizam transações econômicas, isto é, uma troca de bens e serviços
17
entre particulares, empresas ou outro tipo de organização, por uma unidade monetária ou por
outros bens. “
A existência do mercado é de grande importância no desenvolvimento da

economia, da sociedade e das instituições, além de ser a principal atividade econômica.
Tanto quanto a ciência política, a psicologia e a sociologia, a economia é uma

ciência social. Pode ser definida como estudo da alocação (utilização) dos recursos escassos
na produção de bens e serviços para a satisfação das necessidades ou dos desejos humanos.
2.1. Mercado de atuação
Vivemos em um país que faz parte do Top 10 entre os mercados mundiais de TI,
representando 1,9% de vendas de hardware, software de serviços globais.
O Brasil é o 9º maior mercado e também representa 36,5% das vendas totais do

setor na América Latina.
O setor de TI no Brasil está cada vez mais centrado no desenvolvimento de

software e deve ser o maior impulsionador de crescimento para o setor de TI, pois
investimentos maiores em segurança e aplicativos na nuvem aumentarão as vendas nos
próximos anos.
Para 2021 a projeção é de que mercado de desenvolvimento de software no Brasil

deva crescer mais de 10%. É o que aponta o recente estudo “Mercado Brasileiro de Software
– Panorama e Tendências 2020”, realizado pela ABES (Associação Brasileira das Empresas
de Software) em parceria com o IDC.
2.2. Agentes econômicos
Agentes Econômicos são todas entidades com autonomia, capaz de realizar

operações econômicas e deter valor econômico. Cria-se um circuito econômico quando
estabelecem-se interações e relações entre os agentes, quando no exercício das funções.
18
Segundo Mendes et al. (2015) são pessoas de natureza física ou jurídica que,
através de suas ações, contribuem para o funcionamento do sistema econômico, seja este
capitalista ou socialista.
A aquisição do software é realizada pela administração do colégio, que nesse

cenário, é o agente demandante do produto de software.
Cada agente econômico tem sua própria função e participação no sistema

econômico e é responsável pela oferta e pela demanda.
2.2.1. Agentes econômicos identificados no projeto
Empresa: inclui todos os agentes encarregados de produzir e comercializar bens e

serviços, ligados por sistemas de informação e influenciados por um ambiente externo. O
colégio entra como empresa que presta serviços de ensino e contratam serviços de software.
Segundo Santana, et al (2019, p.32), “pode-se conceituar empresa como toda
atividade econômica organizada, para a produção ou circulação de bens (produtos) ou de
serviços. “
Os serviços são conceituados como bens especiais não tangíveis, prestados por
pessoas ou empresas.
O Colégio Vencer Sempre é caracterizado como uma empresa prestadora de

serviços educacionais.
Famílias: inclui todas as famílias e indivíduos da economia que, no papel de

consumidores, adquirem os mais diversos tipos de bens e serviços para satisfazerem suas
necessidades. Os pais ou responsáveis pagam a mensalidade, o colégio por sua vez entra
como prestadores dos serviços de ensino.
Governo: inclui todas as organizações que, estão sob o controle do Estado, direta
ou indiretamente, sendo federal, estadual ou municipal. Administra impostos recolhidos e
recursos que são consumidos.
2.3. Gerenciamento do tempo do projeto

19
O gerenciamento do cronograma do projeto inclui os processos necessários para

gerenciar o término pontual do projeto. (Guia PMBOK® - 6ª. Ed. 2018. P. 711)
O objetivo do gerenciamento do tempo de projeto é descrever os processos

requeridos para o término do projeto, garantindo que ele cumpra com os prazos definidos em
um cronograma de atividades, e assim diminuir as possibilidades de que o projeto venha a
extrapolar os prazos, gerando assim, insatisfações e aumento de custos.
Os principais processos dessa gestão são:
Planejar o gerenciamento do cronograma: É o processo responsável por

estabelecer as políticas, os procedimentos que serão utilizados e a documentação que será
utilizada no planejamento, desenvolvimento, gerenciamento, execução e controle do
cronograma do projeto.
Definir as atividades: consiste em identificar e documentar as ações e atividades

especificas a serem realizadas para produzir os diversos tangíveis do projeto.
Sequenciar as atividades: responsável por identificar e documentar os

relacionamentos, as dependências entre as atividades do projeto. Este processo define uma
sequência lógica para a realização do trabalho.
Estimar os recursos das atividades: Este processo identifica o tipo, quantidade e

características dos recursos exigidos para concluir a atividade, permitindo uma estimativa de
custos e duração mais exatas.
Estimar a duração das atividades: Este processo fornece uma quantidade de

tempo necessário para concluir cada atividade.
Desenvolver o cronograma: Este processo realiza a inclusão das atividades do

cronograma, suas durações, recursos, disponibilidades de recursos e os relacionamentos
lógicos.
Controlar o cronograma: Este processo fornece meios para reconhecimento dos

desvios com relação ao caminho planejado e tomada de medidas corretivas e preventivas para
com isso minimizar os riscos.
20
2.3.1. Cronograma
Após o aceite do Colégio Vencer Sempre, as etapas de desenvolvimento do

projeto terão início, para o cumprimento da entrega do produto no prazo máximo de 90 dias
(três meses).
Serão envolvidos no projeto um analista de sistemas para fazer o levantamento

dos requisitos, planejamento e documentação e, um programador e que irá codificar a
ferramenta e a equipe irá testar o sistema a fim de realizar a validação dos requisitos.
2.4. Viabilidade econômica e financeira do projeto
A análise de viabilidade econômica e financeira é um estudo que consiste em

avaliar e medir, os custos e benefícios de determinado projeto ou investimento. Irá comparar
os retornos que poderão ser obtidos com os investimentos demandados, para decidir se vale a
pena ou não investir. É uma ferramenta capaz de fornecer informações a respeito da sua
rentabilidade e qual o seu impacto na empresa. Seu objetivo é prever ou antecipar os cenários
otimistas e pessimistas de um plano. Para realização desse estudo, segundo Guia -PMBOK é
utilizado o Business Case do Projeto.
Estudo documentado de viabilidade econômica usado para determinar a validade

dos benefícios de um componente ainda sem definição suficiente, usado como base para a
autorização de outras atividades de gerenciamento de projetos. (Guia PMB OK® - 6ª. Edição,
2018, P. 29).
Para o desenvolvimento de um business case template, basicamente são essenciais

quatro tópicos, para um documento bem elaborado, que irá fornecer informações sobre riscos
e recompensas envolvidos na tomada de ação, com abordagens viáveis para a implantação do
projeto:
Números: quais são as receitas para tocar esse projeto, as despesas e resultados
esperados financeiramente após implementação deste novo produto, serviço ou solução?
21
Pessoas: quais são os profissionais que farão parte do projeto? Há profissionais

especializados em cada setor necessário do projeto? Quem vai dar o respaldo?
Mercado: qual é o momento e comportamento do mercado para esse projeto? Tem

demanda? Vai inovar? Vai gerar interesse? Baseado em quê?
Produtos e serviços: o que esse novo produto ou serviço vai oferecer de inovação
ou benefício para os usuários? O que vai solucionar? O business case precisa reunir os
benefícios, as desvantagens, custos e riscos da situação atual e projeção do futuro.
Podemos conceituar investimento financeiro como a aplicação de capital com a

expectativa de um benefício futuro.
O primeiro passo para justificar novos investimentos é alinha-los à estratégia da

organização. Para que o investimento proporcione impacto efetivo, ele precisa estar integrado
à estratégia de negócio, ou seja, ele precisa estar diretamente associado com os objetivos
organizacionais do momento. Ao implementar tecnologias sem a preocupação de relacioná-las
ao negócio, a empresa corre risco de implementar algo caro e inútil para a realidade.
Devemos utilizar dos cálculos de indicadores financeiros:
VPL - Valor presente líquido;
ROI - Retorno do investimento;
TIR -Taxa interna de retorno;
PDR - Período de reembolso e
RCB - Relação de custo-benefício.
Apresentando bons resultados nestes indicadores, é possível demonstrar a alta

gestão que o projeto é sim um investimento de grande valor para a organização.
22
2.4.1. Custo do projeto
O custo total se refere a soma do custo de Levantamento de Requisitos,

Desenvolvimento, Investimentos, Treinamento, Implantação. Visitas de Manutenção e
Atualizações do Software.
A empresa desenvolvedora do Software trabalhará com uma margem de lucro de

40%, aproximadamente.
Valor final do produto: R$ 17.000,00
Figura 02 - Custos do Projeto
Fonte: Autoria própria, 2021
3. ENGENHARIA DE SOFTWARE II
Segundo uma definição proposta por Fritz Bauer (apud Press man, Roger S, 2011,
Pag.39) Engenharia de software é o estabelecimento e o emprego de sólidos princípios de
engenharia de modo a obter software de maneira econômica, que seja confiável e funcione de
forma eficiente em máquinas reais.
O Institute of Electrical and Eletrônics Engenineers - IEEE (SWEBOK, 2004) a

define como:
23
Engenharia de software é a aplicação de uma abordagem sistemática, disciplinada

e quantificável para o desenvolvimento, operação e manutenção de software, isto é, a
aplicação de engenharia de software.
3.1. Qualidade de software
Qualidade é um termo que pode ter diferentes interpretações. Existem muitas

definições para o termo qualidade de software propostas na literatura.
Para SOMMERVILLE (2008) podemos definir que a Garantia de qualidade

consiste em estabelecer procedimentos e padrões que conduzam ao desenvolvimento de
software de alta qualidade.
Para PRESSMAN (2011), a definição de Qualidade de software está relacionada

com a conformidade a requisitos funcionais e de desempenho que foram explicitamente
declarados, a padrões de desenvolvimento documentados, e a características implícitas que
são esperadas de todo software desenvolvido por profissionais.
A qualidade de software está diretamente ligada com a qualidade do processo

através do qual o software é desenvolvido, portanto, para se ter qualidade em um produto de
software é necessário ter um processo de desenvolvimento bem definido, que deve ser
documentado e acompanhado [Swebok, 2004].
3.2. Normas de qualidade
Segundo a norma NBR ISO (2000), qualidade de software é definida como um

conjunto de características que devem ser alcançadas em um determinado grau para que o
produto atenda às necessidades de seus usuários.
Um sistema de qualidade é aquele que possui todas as ferramentas para atender o

que o cliente solicita, conforme as etapas de planejamento e para assegurar isso, existem
normas.
Rocha (2001) “a qualidade de um sistema é um conjunto de características que

avaliam o grau de qualidade. “
24
3.2.1. ISO 9126
As definições e diretrizes da ISO 9126 podem ser utilizadas desde o levantamento

dos requisitos até a avaliação do software, ela define as características da qualidade que
devem estar presentes em um software. A norma ISO 9126 é uma referência técnica mundial
para qualidade de um produto de software e fornece um modelo, definido em seis categorias:
Confiabilidade;
Usabilidade;
Eficiência;
Manutembilidade;
Portabilidade e
Funcionalidade.
Existem quatro tipos de manutenção e utilidade diferente para cada uma delas:
Corretiva;
Preventiva;
Perfectiva e
Adaptativa.
A manutenção corretiva é utilizada para corrigir algum problema encontrado em

um sistema em produção, a atuação é reativa e emergencial.
25
As preventivas são manutenções planejadas, isto é, a manutenção pode ser

programada para um melhor momento, onde é possível parar o funcionamento de um sistema
em produção.
A perfectiva é similar a preventiva, porém, o intuito é de fato alterar, ou seja,

incluir novas funcionalidades que buscam satisfazer o usuário final. Geralmente são feitas
quando o sistema precisa se comportar de maneira igual ou melhor que a de um concorrente.
A manutenção adaptativa é tratada de forma não planejada e de forma reativa, são

as manutenções feitas para adequar o software a novas tecnologias, modelos de gestão ou
nova legislação.
3.2.2. MPS-BR
O MPS-BR (Melhoria de Processos do Software Brasileiro) é um modelo de

qualidade de processo criado em 2003 pela Associação para Promoção da Excelência do
Software Brasileiro (SOFTEX) para melhorar a capacidade de desenvolvimento de software
nas empresas brasileiras.
Para se definir o MPS-BR as normas e modelos internacionalmente reconhecidos

como CMMI (Capability Maturity Model Integration), e nas normas ISO/IEC 12207 e
ISO/IEC 15504 foram levadas em consideração.
Os níveis de maturidade no modelo MPS-BR estabelecem patamares de evolução

dos processos. O nível de maturidade em que se encontra uma organização permite prever o
seu desempenho futuro ao executar um ou mais processos.
O modelo define sete níveis de maturidade:
A - Em Otimização;
B - Gerencia do Quantitativamente;
C - Definido;
26
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.
Figura 03 - MPF-SW
Fonte: Promove Soluções (2021)
A escala de maturidade inicia-se no nível G e progride até o nível A. Para cada um

destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a
organização deve colocar o esforço de melhoria.
O progresso e o alcance de um determinado nível de maturidade do MPS-SW se

obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos
processos e os resultados esperados dos atributos de processo estabelecidos para aquele nível.
A divisão em 7 estágios tem o objetivo de possibilitar uma implementação e

avaliação adequada as micro, pequenas e médias empresas.
A possibilidade de se realizar avaliações considerando mais níveis também

permite uma visibilidade dos resultados de melhoria de processos em prazos mais curtos. A
27
implantação do modelo MP S-BR tem com o principal benefício o melhoramento na

qualidade dos produtos aumentando assim a competitividade da empresa em relação aos
outros produtos da mesma linha de mercado.
A MPS-br será a referência de norma de qualidade utilizada pela empresa

desenvolvedora de software do projeto.
O modelo MPS foi desenvolvido com foco nas pequenas e médias empresas que
possuem diversas restrições técnicas e financeiras. No entanto, o modelo também é
completamente adequado para grandes organizações que possuem recursos suficientes para
investir em melhoria de processo de software [SOFTEX, 2007].
3.3. Classificação dos requisitos
3.3.1. Engenharia de requisitos
A engenharia de requisitos é um processo que engloba todas as atividades que

contribuem para a produção de um documento de requisitos, pelo qual os requisitos de um
produto de software são coletados, analisados, documentados e gerenciados ao longo de todo
o ciclo de vida do software. Antes de iniciar qualquer trabalho técnico, é uma boa ideia
aplicar um conjunto de tarefas de engenharia de requisitos.
O processo de engenharia de requisitos tem como objetivo produzir um

documento de requisitos acordados que especifica um sistema que satisfaz os requisitos dos
stakeholders. Estas levam a um entendimento de qual será o impacto do software sobre o
negócio, o que o cliente quer e como os usuários finais irão interagir com o software
(PRESSMAN, 2011, Pág. 126).
Também de acordo com Pressman (2011, p.127), os requisitos são na verdade

uma ponte entre o projeto e a construção do sistema, é um processo que identifica as
necessidades do negócio e as restrições do projeto, ou seja, com os requisitos é possível que o
desenvolvimento do sistema tenha um ponto de partida.
28
Especificação de software ou engenharia de requisitos é o processo de

compreensão e definição dos serviços requisitados do sistema e identificação de restrições
relativas à operação e ao desenvolvimento do sistema.
A engenharia de requisitos é um estágio particularmente crítico do processo de

software, pois erros nessa fase inevitavelmente geram problemas no projeto e na
implementação do sistema.
Os usuários finais e os clientes precisam de uma declaração de requisitos em alto

nível; desenvolvedores de sistemas precisam de uma especificação mais detalhada do sistema
(SOMMERVILLE, 2011, Pág. 24).
Os Requisitos são além de funções, objetivos, propriedades, restrições que o

sistema deve possuir para satisfazer contratos, padrões ou especificações de acordo com o
usuário.
De acordo com Paula Filho (2000, P.13), “Os requisitos são as características que
definem os critérios de aceitação de um produto.”
Definição glossário de engenharia de software do IEEE [IEE90]:
Requisito é uma condição ou capacidade necessitada por um usuário para resolver

um problema ou alcançar um objetivo.
Requisito é uma condição ou capacidade que deve ser satisfeita ou possuída por
um sistema ou componente do sistema para satisfazer um contrato, um padrão ou uma
especificação.
Uma representação documentada de uma condição ou capacidade como em 1 ou

2.
Segundo Sommerville (2007) um processo de levantamento e análise de requisitos

é composto pelas seguintes etapas:
29
Compreensão do domínio: Os analistas devem desenvolver sua compreensão do

domínio da aplicação;
Coleta de requisitos: É o processo de interagir com os stakeholders do sistema

para descobrir seus requisitos. A compreensão do domínio se desenvolve mais durante essa
atividade;
Classificação: Essa atividade considera o conjunto não estruturado dos requisitos

e os organiza em grupos coerentes;
Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os

requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão

mais importantes do que outros. Esse estágio envolve interação com os stakeholders para a
definição dos requisitos mais importantes;
Verificação de requisitos: Os requisitos são verificados para descobrir se estão

completos e consistentes e se estão em concordância com o que os stakeholders desejam do
sistema.
Abaixo, a relação de Requisitos Funcionais, Requisitos Não Funcionais e Regras

de Negócio pertencentes ao projeto do Sistema de Reserva de Equipamentos do Colégio
Vencer Sempre:
3.3.2. Requisitos Funcionais
Requisitos funcionais são declarações de serviços que o sistema deve fornecer, de

como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em
determinadas situações. Em alguns casos, os requisitos funcionais também podem explicitar o
que o sistema não deve fazer. (SOMMERVILLE, 2011, Pág. 59).
Figura 04 - Requisitos Funcionais
Requisitos Funcionais Caso de Uso

30
RF01 Login no Sistema UC01

RF02 Cadastro de Usuários no Sistema UC02
RF03 Busca de Usuários no Sistema UC03
RF04 Definir Perfil de Usuário UC04
RF05 Cadastro de Equipamentos no Sistema UC05
RF06 Reserva de Equipamentos no Sistema UC06
RF07 Consulta de Reserva de Equipamentos no Sistema UC07
RF08 Cancelamento de Reserva de Equipamentos no Sistema UC08
3.3.3. Requisitos não funcionais
Requisitos não funcionais. São restrições aos serviços ou funções oferecidos pelo
sistema. Incluem restrições, de timing, restrições no processo de desenvolvimento e restrições
impostas pelas normas. Ao contrário das características individuais ou serviços do sistema, os
requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um todo.
(SOMMERVILLE, 2011, Pág. 59).
Figura 05 - Requisitos Não Funcionais
Requisitos Não Funcionais

RNF0
Desenvolvido em PHP
1
RNF0
Utilizar banco de dados MySQL
2
RNF0
O sistema deve possuir integração com usuários do Active Directory
3
RNF0
A exclusão de algum dado se dará na manutenção do banco de dados
4
RNF0 O sistema deve produzir as respostas às ações do usuário no tempo máximo de 5
5 segundos
RNF0 Todos os computadores devem conectar-se em rede, além do servidor e recursos que
6 serão compartilhados
RNF0 O sistema não deve permitir a reserva do mesmo equipamento para o mesmo dia e
7 horário
31
3.3.4. Regras de negócio
Regras de negócio (RN) são premissas e restrições aplicadas a uma operação

comercial de uma empresa, que precisam ser atendidas para que o negócio funcione da
maneira esperada. As regras de negócio definem como o sistema fará o atendimento às
necessidades e exigências definidas.
As restrições, validações, condições e exceções do processo são exemplos

clássicos de regras de negócio.
Figura 06 - Regras de Negócio
Regras de Negócio
A logo do Colégio Vencer Sempre O sistema deve estar presente nas telas do
RN01
sistema
RN02 O sistema deve apresentar os dados da reserva conforme o horário
RN03 O sistema deve vincular o registro do usuário à reserva
Somente usuários com perfil de administrador poderão cadastrar novos usuários no

RN04
sistema
Somente usuários com perfil de administrador poderão cadastrar novos

RN05
equipamentos no sistema
O sistema deve possuir senhas de acesso e identificação para diferentes tipos de

RN06
usuários do sistema
3.4. Documentação do Projeto
Documentação de especificação de requisitos de um sistema de reservas de

equipamentos desenvolvido para uma instituição de ensino.
Introdução
32
Este documento especifica os requisitos do Sistema de Reservas de Equipamentos

Multimidias do Colégio Vencer Sempre, fornecendo aos desenvolvedores as informações
necessárias para o projeto e implementação e também como o sistema deve se comportar.
Escopo do Produto
O sistema tem como objetivo agilizar e auxiliar no gerenciamento das reservas de

equipamentos multimidias e recursos de apoio aos professores e dos demais colaboradores da
instituição.
Visão Geral do Documento
Este documento apresenta uma descrição geral de todos os requisitos funcionais.
Descrição Geral
O Sistema de Reserva de Equipamentos permite ao usuário gerenciar as reservas

de recursos multimídias
O Sistema de Reserva de Equipamentos Multimidias é um sistema local

multiplataforma que pode ser locado na Internet.
O Sistema não permite reserva de equipamentos em duplicidade.
O Sistema atenderá todos os requisitos, conforme a necessidade do cliente.
Descrição de Requisitos do Sistema
Figura 07 - Descrição Requisitos Funcionais
Descrição de Requisitos Funcionais

Login no Sistema
RF01
O sistema deve permitir realizar login para acesso.
RF02 Cadastro de Usuários no Sistema
33
O sistema deve permitir o cadastro de Novos Usuários.

Busca de Usuários no Sistema
RF03
O sistema deve permitir ao administrador realizar a busca de usuário.
Definir Perfil de Usuário
RF04
O sistema deve permitir definir os privilégios do Novo Usuário.
Cadastro de Equipamentos no Sistema
RF05
O sistema deve permitir o cadastro de Novos Equipamentos.
Reserva de Equipamentos no Sistema
RF06
O sistema deve permitir reservar equipamentos, conforme data e hora.
Consulta de Reserva de Equipamentos no Sistema
RF07 O sistema deve permitir consultar as reservas de equipamentos pela data e

hora.
Cancelamento de Reserva de Equipamentos no Sistema

RF08
O sistema deve permitir o cancelamento de reservas de equipamentos.
Fonte: Autoria própria, 2021.
3.5. Planejamento de testes
O teste de software é um elemento de um tópico mais amplo, muitas vezes

conhecido como verificação e validação (V&V). Verificação refere-se ao conjunto de tarefas
que garantem que o software implementa corretamente uma função específica. Validação
refere-se a um conjunto de tarefas que asseguram que o software foi criado e pode ser
rastreado segundo os requisitos do cliente. (PRESSMAN, 2011, Pág. 402)
O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para
descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é
executado usando dados fictícios. Os resultados do teste são verificados à procura de erros,
anomalias ou informações sobre os atributos não funcionais do programa. (SOMMERVILLE,
2011, P ág. 144).
Segundo Myers (1979), testar um software é um processo de executar um

programa ou sistema com a intenção de encontrar defeitos. Para Dijkstra (1985), os testes
podem mostrar a presença de falhas em um software, mas nunca a sua ausência.
34
Testar um software consiste em verificar se ele atende às expectativas, se seu

funcionamento é limpo, amigável e correto e se ele se enquadra no ambiente para o qual foi
projetado. Tudo isso evita surpresas desagradáveis no futuro. (BRAG A, 2016).
O teste caixa preta é realizado por um membro da equipe que não conhece e não
possui nenhuma informação sobre o funcionamento do sistema ou da aplicação a ser testada,
ele apenas examina as saídas sem saber como e onde essas entradas estão sendo utilizadas
(IZABEL, 2014).
Já o teste caixa branca é realizado por alguém que já possui informações do

sistema, a técnica é utilizada para executar uma investigação da lógica interna e da estrutura
do código fonte (IZABEL, 2014).
Figura 08 - Processo de Teste de Software
Fonte: Brasil Escola – 2021

35
3.5.1. Metodologia e Ferramentas
Ao realizar os testes, foi possível testar todas as funções do sistema e afirmar que
o mesmo está em pleno funcionamento, pronto para ser utilizado pelos usuários.
A metodologia de testes utilizada foi a TDD (Test Driven Development). Essa

metodologia visa gerir testes antes mesmo da codificação do sistema, garantindo que o que
será criado funcionará (ANICHE, 2014).
Como gerenciamento durante os testes funcionais, foi utilizada a ferramenta Jira -. disponível
em < https://www.atlassian.com/software/jira>.
3.5.2. Casos de teste
Figura 09 - Casos de Teste
Casos de teste
1 Login no Sistema
2 Login Incorreto no Sistema
3 Cadastro de Usuário no Sistema com Sucesso
4 Cadastro de Usuário já cadastrado no Sistema
5 Busca de Usuários no Sistema
6 Cadastro de Equipamentos no Sistema com Sucesso
7 Reservar Equipamentos no Sistema
8 Busca e Cancelamento de Reservas de Equipamentos no Sistema
9 Busca de Reservas de Equipamentos no Sistema
1
Reservar Equipamentos no Sistema
0
3.5.3. Roteiros de teste
O teste de softwares é uma das atividades do processo de desenvolvimento do

software, que tem por objetivo testar sistematicamente o software, a fim de encontrar falhas e
aumentar a confiabilidade do produto final.
36
3.5.3.1. Especificações de Interface
Figura 10 - Especificações de Interface
Tela Elemento Descrição Tipo Formato Tamanho Validação
O campo deve ser

Alfanuméric Alinhado a
1 Campo Usuário 11 preenchido com
o esquerda
usuário válido
O campo deve ser
Alfanuméric Alinhado a
1 Campo Senha 11 preenchido com senha
o esquerda
válida
Alinhado a Campo deve ser
2 Campo Nome Alfa 11
esquerda preenchido
Alinhado a
2 Campo CPF Numérico 11 CPF deve ser válido
esquerda
Alinhado a
2 Campo RG Numérico 11 RG deve ser válido
esquerda
2 Campo Função Alfa 11
esquerda preenchido
2 Campo Registro Numérico 11
esquerda preenchido
2 Botão Buscar - - - Obter dados do usuário
2 Botão Cancelar - - - Limpar campos
Cadastrar Novo
2 Botão Salvar - - - Usuário no Banco de
Dados
Campo será preenchido
Alinhado a
3 Campo ID Numérico 11 após a confimação do
esquerda
cadastro no sistema
esquerda preenchido
3 Campo Nº Série Numérico 11
esquerda preenchido
3 Campo Patrimônio Numérico 11
esquerda preenchido
Obter dados do
3 Botão Buscar - - -
equipamento
Link para a 4 -
3 Botão Reservar - - -
Reservas
3 Botão Cancelar - - - Limpar campos
Cadastrar Novo
3 Botão Salvar - - - Equipamento no Banco
de Dados

4 Campo ID Numérico 11
esquerda preenchido
esquerda preenchido
37

esquerda preenchido
esquerda preenchido
4 Campo Solicitante Alfa 11
esquerda preenchido
4 Campo Evento Alfa 11
esquerda preenchido
4 Campo Horário/Data Numérico 11
esquerda preenchido
Horário/Horári Caixa de Alinhado a Selecionar janela de
4 Campo -
o seleção esquerda horário para reserva
Cancelar A Reserva deve ser
4 Botão - - -
Reserva cancelada do sistema
A Reserva deve ser
4 Botão Salvar Reserva - - -
salva do sistema
5 Campo Data Numérico 11
esquerda preenchido
5 Campo -
Obter dados de
5 Botão Buscar - - - Reservas para a data,
conforme busca
Link para a 4 - Nova
5 Botão Opções - - -
Reserva
5 Botão Sair - - - Deslogar do sistema
6 Campo Data Numérico 11
esquerda preenchido
6 Campo -
Obter dados de
6 Botão Buscar - - - Reservas para a data,
conforme busca
6 Botão Sair - - - Deslogar do sistema
7 Campo ID Numérico 11
esquerda preenchido
esquerda preenchido
esquerda preenchido
esquerda preenchido
7 Campo Solicitante Alfa 11
esquerda preenchido
7 Campo Evento Alfa 11
esquerda preenchido
7 Campo Horário/Data Numérico 11
esquerda preenchido
7 Campo -
A Reserva deve ser
7 Botão Salvar Reserva - - -
salva do sistema
38
Figura 11 - Roteiro de Teste 01 | Login no Sistema
Caso de teste 01: Login no Sistema
Procedimento inicial:
> Acessar o sistema como usuário administrador
Data de execução: 13/03/2021

Situação: Sucesso
I
Passos para execução Dados de entrada Resultado esperado
D
Sistema valida credenciais no
Sistema exibe tela de Login no Usuário: ADM sistema e exibe a tela de Usuário
1
Sistema Senha: ADM com o menu com as opções a
esquerda
Figura 12 - Evidência: Tela 01 - Principal | Login e Senha
Figura 13 - Roteiro de Teste 02 - Login Incorreto no Sistema
Caso de teste 02: Login Incorreto no Sistema

39
> Acessar o sistema como usuário administrador
Situação: Sucesso
Situação
: Passos para execução Dados de entrada Resultado esperado
Sucesso
Sistema valida credenciais no
Sistema exibe tela de Login no Usuário: ADM sistema e exibe a tela de Usuário
1
Sistema Senha: 123456 com o menu com as opções a
esquerda
Figura 14 - Evidência: Tela Inicial | Mensagem Erro Login e Senha
Figura 15 - Roteiro de Teste 03 | Cadastro de Usuário no Sistema com Sucesso
Caso de teste 03: Cadastro de Usuário no Sistema com Sucesso
Situação: Sucesso
40
> Acessar o sistema como usuário administrador > Informar Login > Informar senha >
Confirmar no botão "Enter " do teclado.
I
D
Sistema exibe tela "Cadastro de
Usuários" com os seguintes
"José Maria Silva",
campos: "Nome", "CPF", Sistema cadastra o Novo
"123.456.789-10", "12.345.678-
"RG", "Função", "Registro", Usuário no banco de dados
90", "Professor Filosofia",
1 "Telefone" e "E-mail" e os e exige a mensagem:
"12345", "(11) 12345-
botões "Buscar", "Cancelar" e "Usuário Cadastrado com
6789","jose_maria@email.com.
"Salvar". Usuário preenche Sucesso."
"
todos os campos e seleciona o
botão "Salvar."
O sistema confirma o
Sistema exibe caixa de cadastro de Novo Usuário e
mensagem: "Usuário exibe uma mensagem
2 Cadastrado com Sucesso.", - solicitando a definição do
usuário confirma, clicando no perfil do usuário
botão "OK." cadastrado: "Tornar Novo
Usuário Administrador."
Caso selecione "SIM", o
Sistema solicita a definição de
Novo Usuário terá o perfil
preferências para o Novo
de Administrador e se
3 Usuário, usuário seleciona -
"NÂO", o Novo Usuário
"SIM" ou "NÂO" e confirma
não terá os privilégios de
no botão "OK."
ADM.
Figura 16 - Evidência: Tela 02 - Usuários | Administrador

41
Figura 17 - Evidência: Tela Usuários | Administrador - Mensagem Usuário Cadastrado
Figura 18 - Evidência: Tela Usuários | Administrador - Definir Perfil de Usuário

42
Figura 19 - Roteiro de Teste 04 | Cadastro de Usuário já cadastrado no Sistema
Caso de teste 04: Cadastro de Usuário já cadastrado no Sistema
Situação: Sucesso
I
D
Sistema exibe tela "Cadastro
de Usuários" com os seguintes
campos: "Nome", "CPF", "José Maria Silva",
"RG", "Função", "Registro", "123.456.789-10", "12.345.678-
Sistema exige a mensagem:
1 "Telefone" e "E-mail" e os 90", "Professor Filosofia",
"Usuário já cadastrado."
botões "Buscar", "Cancelar" e "12345", "(11) 12345-
"Salvar". Usuário preenche 6789","jose_maria@email.com."
botão "Salvar."
Sistema exibe tela de Usuários
com os seguintes campos:
Sistema exibe caixa de
"Nome", "CPF", "RG",
mensagem: "Usuário já
2 - "Função", "Registro",
cadastrado", usuário confirma,
"Telefone" e "E-mail", usuário
clicando no botão "OK."
preemche todos os campos e
seleciona o botão "Salvar."
Figura 20 - Evidência: Tela Usuários | Administrador - Mensagem Usuário Já Cadastrado

43
Figura 21 - Roteiro de Teste 05 | Busca de Usuários no Sistema
Caso de teste 05: Busca de Usuários no Sistema
Situação: Sucesso
I
D

Usuários" com os seguintes
campos: "Nome", "CPF",
"RG", "Função", "Registro",
Sistema aguarda o critério de
1 "Telefone" e "E-mail" e os -
busca.
botões "Buscar", "Cancelar" e
"Salvar". Usuário preenche
botão "Salvar."
44
Sistema retorna o resultado de

busca com todos os dados do
usuário: "José Maria Silva",
"123.456.789-10", "12.345.678-
Usuários". Usuário preenche
90", "Professor Filosofia",
2 um dos seguintes campos 123.456.789-10
"12345", "(11) 12345-6789" e
"CPF" e seleciona o botão
jose_maria@email.com ou exibe
"Buscar."
a mensagem “Usuário Não
Encontrado”, caso não localize o
cadastro no banco de dados.
Figura 22 - Evidência: Tela Usuários | Administrador - Buscar Usuário
Figura 23 - Evidência: Tela Usuários | Administrador - Resultado da Busca

45
Figura 24 - Evidência: Tela Usuários | Administrador - Usuário Não Encontrado
Figura 25 - Roteiro de Teste 06 | Cadastro de Equipamentos no Sistema com Sucesso

46
Caso de teste 06: Cadastro de Equipamentos no Sistema com Sucesso
Situação: Sucesso
I
D

Equipamentos", com os
seguintes campos "ID",
"Nome", "Nº Série" e
Sistema cadastra o Novo
patrimônio e os botões "Caixa de som",
1 Equipamento no banco de
"Buscar", "Reservar", "123456789" e "123"
dados.
"Cancelar" e "Salvar." Usuário
preenche todos os campos, com
exceção do campo "ID" e
seleciona o botão "Salvar."
Figura 26 - Roteiro de Teste 07 | Reservar Equipamentos no Sistema
Caso de teste 07: Reservar Equipamentos no Sistema
Situação: Sucesso
> Acessar o sistema como administrador > Informar Login > Informar senha >
Confirmar no botão "Enter " do teclado > Selecionar o botão "Reservas"
I
D
Sistema exibe tela "Reserva

de Equipamentos ", com os
seguintes campos "", Nome, “12”, “Caixa de Som”,
Nº Série, Patrimônio, “12345678”, “12”3,
Solicitante, Evento, “Professor Mathias Sistema exibe e mensagem
1 Horário/Data e Filosofia”, “Palestra "Reserva Realizada com
Horário/Horário e os botões Auditório”, Sucesso" e o botão "OK"
Cancelar Reserva e Salvar “30/03/3031” e
Reserva. O Usuário preenche “11:00 - 13:00”
todos os campos e seleciona
o botão "Salvar Reserva"
47
Usuário confirma a
Sistema exibe tela "Reservas"
.4 mensagem, selecionando o -
com os campos em branco
botão "OK"
Figura 27 - Evidência: Tela 04 - Nova Reserva | Administrador - Reserva de Equipamentos
Figura 28 - Evidência: Tela Equipamentos | Administrador - Confirmação Reserva de Equipamentos

48
Figura 29 - Roteiro de Teste 08 | Busca e Cancelamento de Reservas de Equipamentos no Sistema
Caso de teste 08: Busca e Cancelamento de Reservas de Equipamentos no Sistema
Situação: Sucesso
> Acessar o sistema como usuário administrador > Informar Login > Informar
senha > Confirmar no botão "Enter " do teclado > Selecionar o botão "Reservas"
I
D
Sistema exibe tela

"Reservas ", com os
seguintes campos "Data",
Sistema retorna a busca,
"Horário", e os botões
"30/03"e listando todos os equipamentos
1 "Buscar", "Opções" e
"11:00 - 13:00" reservados para o dia e horário
"Salvar." Usuário preenche
escolhido.
o campo "Data", seleciona
um horário e seleciona o
botão "Buscar".
Sistema exibe a tela "Reserva

Usuário seleciona o botão de Equipamentos" com os
2 -
"Opções" botões "Cancelar Reserva" ou
"Salvar Reserva"
49
Sistema exige mensagem

Usuário seleciona o botão
3 - "Reserva Cancelada com
"Cancelar Reserva"
Sucesso" e o botão "OK,"
Figura 30 - Evidência: Tela Equipamentos | Administrador - Confirmação Cancelamento Reserva de Equipamentos
Figura 31 - Roteiro de Teste 09 | Busca de Reservas de Equipamentos no Sistema
Caso de teste 09: Busca de Reservas de Equipamentos no Sistema

Situação: Sucesso
> Acessar o sistema como usuário > Informar Login > Informar senha >
I
D
50
Sistema exibe tela

"Reservas ", com os
seguintes campos "Data",
Sistema retorna a busca,
"Horário", e os botões
listando todos os
"Buscar", "Opções" e "30/03"e "11:00 -
1 equipamentos
"Salvar." Usuário 13:00"
reservados para o dia e
preenche o campo "Data",
horário escolhido.
seleciona um horário e
seleciona o botão
"Buscar".
Usuário seleciona o botão Sistema exige a tela de

2 -
"Sair" Login
Figura 32 - Evidência: Tela 07 - Nova Reserva | Usuário
Figura 33 - Roteiro de Teste 10 | Reservar Equipamentos no Sistema
Caso de teste 10: Reservar Equipamentos no Sistema

51
Situação: Sucesso
> Acessar o sistema como usuário > Informar Login > Informar senha >
I
D
Sistema exibe tela "Reserva
de Equipamentos ", com os
seguintes campos "", Nome,
“12”, “Caixa de Som”,
Nº Série, Patrimonio,
“12345678”, “12”3,
Solicitante, Evento,
“Professor Mathias Sistema exibe e mensagem
Horário/Data e
1 Filosofia”, “Palestra "Reserva Realizada com
Horário/Horário e os botões
Auditório”, Sucesso" e o botão "OK"
Cancelar Reserva e Salvar
“30/03/3031”e
Reserva. O Usuário
“11:00 - 13:00”
preenche todos os campos e
seleciona o botão "Salvar
Reserva"
Usuário confirma a Sistema exibe tela

.4 mensagem, selecionando o - "Reservas" com os campos
botão "OK" em branco
Figura 34 - Evidência: Tela 07 - Nova Reserva | Usuário

52
Figura 35 - Evidência: Tela Nova Reserva | Usuário - Mensagem Reserva Realizada
Com os testes realizados, foi possível definir com clareza, todas as mensagens de
que o sistema deve exibir, dependendo da ação do usuário.
A situação foi de sucesso para todos os testes realizados até o final do processo de
desenvolvimento.
4. PROJETO DE INTERFACE COM O USUÁRIO
4.1. Especificação da interface
O sistema será implantado na secretaria do colégio, no almoxarifado e na sala da

diretoria, onde estão dispostos os computadores que serão os terminais utilizados para
implantação do sistema.
A interação com o sistema será através do computador e seus periféricos: mouse,

teclado e impressora. Os terminais possuem acesso à internet.
53
As telas do sistema serão simples, com botões grandes e de fácil entendimento e

usabilidade.
Esforce-se ao máximo para produzir o modelo mais simples possível. Não exagere
no software. Mantendo modelos simples, o software resultante também será simples. O
resultado será um software mais fácil de ser integrado, testado e mantido. Além disso,
modelos simples são mais fáceis de compreender e criticar, resultando em uma forma
contínua de feedback que otimiza o resultado final. (PRESSMAN; MAXIM, 2016).
A tecnologia deve ser usada sempre para maximizar as habilidades dos seres
humanos, e o uso de computadores deve ser o mais simples, seguro e agradável possível.
Criação de sistemas difíceis de usar pode inviabilizar o sucesso de softwares que poderiam ser
bastante úteis.
4.1.1. IHC- interação humano-computador
O IHC (Interação humano-computador) é o estudo da interação entre seres

humanos e computadores. A interação entre seres humanos e máquinas acontece através da
interface, formada por software e hardware que se unem para realizar uma tarefa específica.
IHC é uma matéria interdisciplinar que relaciona:
Ciência da computação;
Artes;
Design;
Ergonomia;
Psicologia;
Sociologia;
Semiótica;
Linguística e áreas afins.

54
Possui o objetivo de desenvolver ou melhorar a segurança, utilidade, eficácia e

usabilidade de produtos interativos computacionais.
Os critérios de qualidade para software definidos em IHC são:
Acessibilidade: remoção das barreiras que impedem mais usuários de serem

capaz de acessar a interface do sistema e interagirem com ele.
Comunicabilidade: responsabilidade de o designer comunicar ao usuário suas

intenções de design e a lógica que rege o comportamento da interface.
Experiência do usuário: está relacionado com os sentimentos e emoções dos

usuários.
Usabilidade: facilidade de aprendizado e uso da interface, bem como a satisfação

do usuário em decorrência desse uso.
4.2. Casos de Uso
Ensina Jacobson (1992 apud MACORATTI, 2004) que um caso de uso é um

“documento narrativo que descreve a sequência de eventos de um ator que usa um sistema
para completar um processo".
O administrador possui acesso total a todas as funcionalidades do sistema, já o

usuário cadastrado, seja ele professor, coordenador ou outros, somente as funcionalidades
necessárias para efetuar a reserva e visualização das reservas já efetuadas.
Figura 36 - Diagrama de Caso de Uso | Administrador

55
Figura 37 - Diagrama de Casos de Uso | Usuário
Figura 38 - Caso de Uso 01 | Login no Sistema
UC01
56
Nome Login no Sistema
Descrição O sistema deve permitir realizar login para acesso.
Atores Administrador, Usuários

Entradas e precondições Entradas: login e senha
Saídas e pós condições O sistema autentica o usuário
Fluxo de eventos
1º Usuário informa o login e a senha;

Fluxo principal
2º O sistema verifica os dados do usuário.
Se o usuário informar login ou senha incorretos, o sistema

deve enviar uma mensagem ao usuário informando: "Usuário
Fluxo secundário 1
ou Senha Inválidos. Por favor, verifique os dados e tente
novamente."
Se o usuário informar login ou senha corretos, o sistema

Fluxo secundário 2 autentica os dados e apresenta o menu, conforme o perfil do
usuário.
Figura 39 - Caso de Uso 02 | Cadastro de Usuários no Sistema
UC02
Nome Cadastro de Usuários no Sistema
Descrição O sistema deve permitir o cadastro de Novos Usuários.
Atores Administrador.
Pré-condições:
Ter efetuado login no sistema e possuir perfil de
Administrador.
Entradas e precondições
Entradas:
Nome; CPF; RG; Função; Registro; Telefone e e-mail.
Saídas e pós condições Inclusão dos dados do usuário no banco de dados.

57
Fluxo de eventos
1º Administrador informa dados de novo usuário, conforme

campos da Tela Cadastro Novo Usuário: Nome; CPF; RG;
Função; Registro; Telefone e e-mail;
Fluxo principal 2º O sistema verifica armazena os dados do usuário no Banco
de Dados;
3º O novo usuário tem acesso ao sistema de reserva de
equipamento, conforme o seu perfil.
Se o usuário já estiver cadastrado, o sistema deve enviar uma

Fluxo secundário 1
mensagem informando: "Usuário Já Cadastrado."
Se usuário não estiver cadastrado e todos os campos forem

preenchidos corretamente, o sistema deve enviar uma
Fluxo secundário 2
mensagem informando: "Usuário Cadastrado Com Sucesso," e
salvar os dados do novo usuário no Banco de Dados.
Figura 40 - Caso de Uso 03 | Busca de Usuários no Sistema
UC03
Nome Busca de Usuários no Sistema
O sistema deve permitir ao administrador realizar a busca de

Descrição
usuário.
Pré-condições:
Dados do usuário cadastrados no Banco de Dados.
Usuário ter efetuado login no sistema e perfil de
Administrador.
Entradas:
Critérios de busca: Nome; CPF; RG; Função; Registro;
Telefone ou e-mail.
Resultado da Busca, informando os dados do Usuário,

Saídas e pós condições
conforme critério informado.
Fluxo de eventos
58
1º Administrador informa critério de busca: Nome; CPF;

RG; Função; Registro; Telefone e e-mail;
Fluxo principal 2º O sistema realiza a busca no Banco de Dados;
3º O sistema retorna com os dados do usuário, conforme
busca realizada.
Se o usuário não estiver cadastrado, o sistema deve enviar

Fluxo secundário 1
mensagem informando: "Usuário Não Localizado."
Se o usuário estiver cadastrado, o sistema deve retornar o

Fluxo secundário 2
resultado da Busca realizada no banco de dados
Figura 41 - Caso de Uso 04 | Definir Perfil de Usuário
UC04
Nome Definir Perfil de Usuário
O sistema deve permitir definir os privilégios do Novo
Descrição
Usuário.
Pré-condições:
Administrador;
Admnistrador salvar dados de Novo Usuário no Sistema;
O sistema enviar uma mensagem informando: "Novo
Cadastro Realizado com Sucesso";
Entradas:
Cadastro de Novo Usuário: Nome; CPF; RG; Função;
Registro; Telefone ou e-mail.
Saídas e pós condições Definição Perfil de Novo Usuário cadastrado.

59
Fluxo de eventos
1º Administrador confirma cadastro de Novo Usuário no

sistema;
2º O sistema envia uma mensagem solicitando ao
adiministrador para selacionar uma das opções: "Sim" ou "
Não" e confirmar para definir os privilégios do Novo Usuário:
Fluxo principal
"Tornar Novo Usuário Administrador;"
2º O sistema armazena a definição de perfil e privilégios no
Novo Usuário no Banco de Dados;
3º O novo usuário tem acesso ao sistema de reserva de
equipamento, conforme o seu perfil.
Figura 42 - Caso de Uso 05 | Cadastro de Equipamentos no Sistema
UC05
Nome Cadastro de Equipamentos no Sistema
Descrição O sistema deve permitir o cadastro de Novos Equipamentos.
Pré-condições:
Administrador.
Entradas:
Dados do Novo Equipamento: ID (Será criado após Salvar
Cadastro do Equipamento); Nome; Nº de Série e Patrimônio
(conforme registro).
Saídas e pós condições Inclusão no Novo Equipamento no Banco de Dados
Fluxo de eventos
60
1º Administrador informa dados do Novo Equipamento:

Nome; Nº de Série e Patrimônio.
2º O Administrador Salva o Novo Cadastro e o Sistema gera
um ID para o Equipamento;
Fluxo principal
3º O sistema armazena os dados no Novo Equipamento no
Banco de Dados;
4º O sistema disponibiliza o Equipamento cadastrado para
Reservas.
Figura 43 - Caso de Uso 06 | Reserva de Equipamentos no Sistema
UC06
Nome Reserva de Equipamentos no Sistema
O sistema deve permitir reservar equipamentos, conforme
Descrição
data e hora.
Atores Administrador, Usuários.
Pré-condições:
Usuário ter efetuado login no sistema;
Dados do equipamento cadastrados no Banco de Dados,
Equipamento não estar reservado para a mesma data e
Entradas e precondições horário.
Entradas:
Equipamento;
Data e hora da reserva.
Saídas e pós condições Reserva de Equipamento no Sistema
Fluxo de eventos
1º Usuário informa dados do equipamento a ser reservado;

2º Usuário informa Solicitante da Reserva;
3ºUsuário informa o Evento onde o equipamento será
utilizado;
Fluxo principal
4º Usuário informa o dia e horário em que o equipamento será
utilizado;
5ºApós Salvar Reserva, o equipamento fica reservado no
sistema, conforme dia e horário informados.

61
Figura 44 - Caso de Uso 07 | Consulta de Reserva de Equipamentos no Sistema
UC07
Nome Consulta de Reserva de Equipamentos no Sistema
O sistema deve permitir consultar as reservas de
Descrição
equipamentos pela data e hora.
Atores Administrador, Usuários.
Pré-condições:
Usuário ter efetuado login no sistema;
Reserva de Equipamento ter sido realizada no sistema.
Entradas:
Retorno da Busca por reservas de Equipamento no Sistema,

Saídas e pós condições
conforme data e hora informados.
Fluxo de eventos
1º Usuário informa data e hora da Reserva;

Fluxo principal 2º O sistema retorna a Busca por reservas de Equipamento no
Sistema, conforme data e hora informados.
Figura 45 - Caso de Uso 08 | Cancelamento de Reserva de Equipamentos no Sistema
UC08
Nome Cancelamento de Reserva de Equipamentos no Sistema
O sistema deve permitir o cancelamento de reservas de
Descrição
equipamentos.
62
Pré-condições:
Usuário ter efetuado login no sistema e possuir perfil de
Administrador;
Entradas e precondições Reserva de Equipamento ter sido realizada no sistema.
Entradas:
Saídas e pós condições Cancelamento da Reserva de Equipamento no Sistema.
Fluxo de eventos
1º Administrador informa data e hora da Reserva;

2º O sistema retorna a Busca por reservas de Equipamento no
Sistema, conforme data e hora informados;
3º O Administrador seleciona a reserva que deseja cancelar e
seleciona o botão "Opções";
Fluxo principal 4º Ao selecionar Opções, a tela de Reserva se abre com mais
opçãoes: "Cancelar Reserva" ou "Salvar Reserva";
5º O Administrador seleciona a opção "Cancelar Reserva";
6º O sistema deve enviar uma mensagem informando:
"Reserva Cancelada com Sucesso", confirmado o
cancelamento da Reserva.
4.3. Protótipo
Segundo SOMMERVILLE (P.30,2011), um protótipo é uma versão inicial de um

sistema de software usada para experimentar opções de projeto e descobrir mais sobre o
problema e suas possíveis soluções. Tem como objetivo facilitar o entendimento dos
requisitos de uma aplicação. Além disso, ela permite apresentar conceitos e funcionalidades
do software de modo simplificado, é possível propor uma solução adequada para o problema
do cliente, aumentando sua percepção de valor. O usuário poderá avaliar como os recursos
estarão distribuídos, a organização do layout e outros itens que impactam na experiência de
uso.
A Prototipação é utilizada no processo de desenvolvimento pelos desenvolvedores

que a usam como parâmetro para produzir uma versão final de alta fidelidade com os
63
requisitos levantados. Durante o projeto, ajustes poderão ser feitos para alinhar as
expectativas do cliente através da experiência e avaliação do protótipo pelo usuário.
Tela de Login e Senha
Abaixo, a tela de Login no sistema. O usuário deve inserir as informações de

“Usuário” e “Senha” válidos para acessar o sistema e ser direcionado as opções de “Reserva
de Equipamentos.”
Figura 46 - Tela 01 - Principal | Login e Senha
Tela de Cadastro de Usuários
Somente usuários com perfil de administrador tem acesso a Tela de Cadastro de

Usuários. Nessa tela é possível cadastrar Novo usuário, preenchendo todos os campos com os
dados no Novo Usuário e clicando no botão “Salvar.” O sistema exibirá uma mensagem,
confirmando que o cadastro foi realizado com sucesso. O botão “Cancelar”, quando acionado,
cancela a ação iniciada e é possível realizar a busca por usuários, preenchendo um dos
campos como requisito e selecionando o botão “Buscar”.
64
Figura 47 - Tela 02 - Usuários | Administrador
Tela de Cadastro de Equipamentos
Somente usuários com perfil de administrador tem acesso a Tela de Cadastro de

equipamentos. Para cadastro de Novo Equipamento, o administrador deve preencher todos os
campos com os dados no equipamento em “Salvar.” O botão “Cancelar”, quando acionado,
cancela a ação iniciada e é possível realizar a busca por equipamentos, preenchendo um dos
campos como requisito e selecionando o botão “Buscar”. O botão “Reservar”, direciona o
administrador para a “Tela de Reserva de Equipamentos.”
Figura 48 - Tela 03 - Equipamentos | Administrador - Busca Equipamentos

65
Tela de Reserva de Equipamentos
Na Tela de Reserva de Equipamentos, o administrador pode optar por “Cancelar a

Reserva” que já está confirmada no sistema e também pode inserir uma Nova Reserva,
preenchendo todos os campos e selecionando o botão “Salvar Reserva.”
Figura 49 - Tela 04 - Nova Reserva | Administrador - Reserva de Equipamentos

66
Tela de Reservas
A Tela de Reservas apresenta uma prévia dos equipamentos reservados, ao

realizar uma busca, preenchendo os campos “Data” e “Horário” e selecionando o botão
“Buscar” a direita. Selecionando uma das Reservas, é possível realizar alguma ação,
selecionando o botão “Opções”, o Administrador é direcionado para a “Tela de “Reserva de
Equipamentos “, onde pode verificar mais detalhes a respeito do equipamento reservado e
pode optar por “Cancelar a Reserva" ou “Sair” do sistema, conforme o botão selecionado.
Ainda sobre a Tela de Reservas, ao selecionar o botão “Sair”, o sistema apresenta a “Tela de
Login.”
Figura 50 - Tela 05 - Reservas | Administrador

67
Tela de Reservas
A Tela de Reservas apresenta uma prévia dos equipamentos reservados. Nela, o

usuário realiza uma busca pela data e horário, preenchendo os campos “Data” e “Horário” e
selecionando o botão “Buscar” a direita. Ao selecionar o botão “Sair”, o sistema apresenta a
“Tela de Login.”
Figura 51 - Tela 06 - Reservas | Usuário

68
Tela de Reserva de Equipamentos
Usuários em geral podem inserir uma Nova Reservas, preenchendo todos os

campos e selecionando o botão “Salvar Reserva.”
Figura 52 - Tela 07 - Nova Reserva | Usuário

69
5. PROGRAMAÇÃO ORIENTADA A OBJETOS
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu

próprio estado local e oferecem operações nesse estado. A representação do estado é privada e
não pode ser acessada diretamente, de fora do objeto. Processos de projeto orientado a objetos
envolvem projetar as classes de objetos e os relacionamentos entre essas classes. Essas classes
definem os objetos no sistema e suas interações. Quando o projeto é concebido como um
programa em execução, os objetos são criados dinamicamente a partir dessas definições de
classe. Sistemas orientados a objetos são mais fáceis de mudar do que os sistemas
desenvolvidos com abordagens funcionais. (SOMMERVILLE, 2011, pag.139)
Programação Orientada a Objetos é uma metodologia recente que se baseia

fundamentalmente no conceito de objetos. É uma forma de desenvolvimento de sistemas de
software que o trata como um conjunto de componentes que interagem entre si para resolver
um problema. Esses componentes são denominados Objetos. (C ADENHEAD;
LEMAY,2005).
70
Na Programação Orientada a Objetos, um programa de computador é conceituado

como um conjunto de objetos que trabalham juntos para realizar uma tarefa. Cada objeto é
uma parte do programa, interagindo com as outras partes de maneira específica e totalmente
controlada. (CADENHEAD; LEMAY, 2005, p.6)
5.1. Objetos
Os objetos são instâncias de classes, que realizam tarefas por meio de ações e
podem se agrupar em tipos que são organizados hierarquicamente, antes de se criar um objeto
temos que definir uma classe para o mesmo
O objeto é uma entidade com capacidade de salvar seu estado e que oferece um
número de operações que examinam ou alteram esse estado (jocobson,1993).
5.2. Classes
Através da definição de uma classe, descreve-se que propriedades ou atributos que
o objeto terá. Além da especificação de atributos, a definição de uma classe descreve também
qual o comportamento de objetos da classe, ou seja, que funcionalidades podem ser aplicadas
a objetos da classe. Essas funcionalidades são descritas através de métodos. Um método nada
mais é que um procedimento ou função, com a restrição que ele manipula apenas suas
variáveis locais e os atributos que foram definidos para a classe.
5.3. Herança
É um recurso que permite que novas classes sejam definidas a partir de classes
anteriores com a seguinte hierarquia.
Herança é um mecanismo que permite que uma classe herde todo o

comportamento e os atributos de outra classe. (CADENHEAD; LEMAY, 2005, p. 13).
Super classes ou ascendente: são as ascendentes de uma classe.
Subclasses ou descendente: são as descendentes de uma classe

71
Classe mãe: é a ascendente direta de uma classe.
Classe filha: é a descendente direta de uma classe.
5.4. Polimorfismo
O Polimorfismo tem uma característica que possibilita a criação de código capaz

de operar sobre valores distintos. Possibilita que as subclasses invoquem os mesmos métodos
herdados através da mesma assinatura, embora se comportem de maneira diferente.
O polimorfismo permite escrever programas que processam objetos que

compartilham a mesma superclasse (direta ou indiretamente) como se todos fossem objetos da
superclasse; isso pode simplificar a programação (DEITEL; DEIT EL, 2010, p. 305).
Existem duas formas de implementação do polimorfismo:
Sobrecarga (Overload) um identificador ou operador é sobrecarregado quando

pode ser utilizado para designar duas ou mais operações distintas.
Sobrescrita (Override) é alcança do com auxílio do uso de herança nas classes e

a reescrita de métodos das superclasses nas suas subclasses.
As classes, objetos e seus atributos estão representados abaixo. No software de

reserva de equipamentos desenvolvido para o colégio Vencer Sempre, podemos utilizar a
herança para aproveitar os atributos e métodos da classe “Usuário admin” na classe
“Usuário”, retirando somente os métodos “Cadastrar“ e “Excluir.”
5.5. Classes e Heranças do Sistema
Figura 53 - Classes e Heranças

72

73
6. CONCLUSÃO
Algumas atividades como: Levantamento de requisitos; Análise de Requisitos;

Projeto; Implementação; Testes; Implantação são comuns à grande parte dos diversos tipos de
processos de desenvolvimento de software existentes.
Um sistema de informações pode ser utilizado para automatizar processos de uma

organização. No que diz respeito ao retorno de investimentos no projeto, o Levantamento de
Requisito é a etapa mais importante e deve-se disponibilizar tempo suficiente para essa fase
do projeto, para que se compreenda as necessidades do cliente em relação ao sistema a ser
desenvolvido.
A fim de criar uma estratégia de solução, na Análise ou especificação de

requisitos, os desenvolvedores fazem um estudo detalhado dos dados levantados na atividade
anterior, de onde são construídos protótipos. Etapa onde é feita Validação e Verificação.
Existem alguns aspectos a serem considerados na fase de Projeto do Sistema,

como: arquitetura, linguagem de programação qu será utilizada, Sistema Gerenciador de
Banco de Dados, padrão de interfaces, entre outros.
O sistema é codificado na Implementação a partir da descrição da fase de projeto

em uma outra linguagem.
Diversas atividades são executadas na fase de testes a fim de se validar o produto

de software.
A instalação do software no ambiente do usuário compreende, por fim a

Implantação, incluindo ainda manuais do sistema e treinamento dos usuários.
Até a metade da década de 1950, as empresas administravam tudo em registros

impressos e divulgavam suas informações em papel. Durante os últimos (...) anos, cada vez
mais as informações organizacionais e o fluxo delas entre os principais atores dos negócios
foram computadorizados. (LAUDON, LAUDON, 2010, p. 20).
Os CRS nasceram na década 60 e foi desenvolvido na década de 1980. Estes

sistemas conhecidos como Sistemas de Reservas por Computador (Computer Reservation
System), tornaram-se rapidamente instrumentos dominantes para o processo de reservas de
vôos por companhias aéreas. Assim, as agências de viagem começaram a usar a tecnologia de
74
informação através dos CRSs que, de acordo com Guthan (2002), providenciavam os dados e
as informações necessárias para seus trabalhos. com o tempo foram adotados também por
hotéis e pelos operadores turísticos, que com certeza se beneficiaram com a forma que
encontraram de melhorar a gestão das suas reservas.
Logo, a implantação o do projeto pode ser considerada viável e benéfica para a

instituição de ensino Colégio Vencer Sempre, trazendo uma solução para o problema
enfrentado, de forma efetiva.
7. REFERÊNCIAS
BATISTA, Emerson de Oliveira. Sistema de Informação: o uso consciente da tecnologia

para o gerenciamento. São Paulo: Saraiva, 2004.
BRAGA, Pedro Henrique (org.). Teste de Software. Londres: Pearson Education, 2016. 139
p.
DALFOVO, Oscar (Org.). Sistemas de informação: estudos e casos. Blumenau:

Acadêmica,2004.
LEBEN, Joe. Strategic information planning methodologies.2nd ed. Englewood Cliffs,

New Jersey: Prentice-Hall, 1989. 328 p.
MENAMIN, Sthephen M.; PALMER, John F. Análise Essencial de Sistemas. [S.l.]: Editora
Makron Books, 1994.
PRESSMAN, R. S. Engenharia de Software. Rio de Janeiro: McGraw-Hill, 2006.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. São Paulo:

McGraw-Hill, 2011.
75
PRESSMAN, Roger; MAXIM, Bruce. Engenharia de Software: uma abordagem

profissional. 8. ed. Nova Iorque: Mcgraw-hill Education, 2016. 968p. Tradução AMGH
Editora Ltda.
ROCHA, A.R. J.C. MALDONADO; K.C. WEBER, (2001) Qualidade de Software -Teoria
e Prática. Prent ice Hall, São Paulo.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. Londres: Pearson Education, 2007.

568 p.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,
2011
BOURQUE pierre. IEEE Computer Society. Versão 3. 2014. Guide to the Software
Engineering Body of Knowledge. Disponível em: < https://ieeecs-
media.computer.org/media/education/swebok/swebok-v3.pdf>. Acesso em: 03 mar. 2021.
DALL’OGLIO, Pablo. PHP: Programando com Orientação a Objetos. São Paulo: Novatec
Editora, 2015. Disponível em: <https://www.adianti.com.br>. Acesso em: 04 mar. 2021.
FONSECA, Juana. Sistemas Informatizados de Reserva e Recepção. Montes Claros:

Instituto Federal do Norte de Minas Gerais, 2015. Disponível em:
<http://ead.ifnmg.edu.br/uploads/documentos/m8qmC2H9jH.pdf>. Acesso em: 10 mar. 2021.
MELO, Alexandre; NASCIMENTO, Maurício. PHP Profissional: Aprenda a Desenvolver

Sistemas profissionais Orientados a Objetos com Padrões de Projeto. São Paulo: Novatec
Editora, 2007. Disponível em: <
http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/254880.pdf>. Acesso em:
07 mar. 2021.
MILANI, André. MySQL - Guia do Programador. São Paulo: Novatec Editora, 2006.
Disponível em: <https://books.google.com.br>. Acesso em: 07 mar. 2021.
RAGGET, Dave. Introdução à World Wide Web. 1998. Disponível em:

<https://www.w3.org/People/Raggett/book4/ch01.html>. Acesso em: 03 mar. 2021.
RAINER, R. Kelly; CEGIELSKI, Casey G. Introdução a Sistemas de Informação:

Apoiando e Transformando Negócios na era da mobilidade. 3 ed. Rio de janeiro: Elsevier,
2011. Disponível em: <https://books.google.com.br>. Acesso em: 03 mar. 2021.
76
SANCHES, André Rodrigo. Fundamentos de Armazenamento e Manipulação de Dados.

São Paulo, 2005. Disponível em: <http://www.ime.usp.br/~andrers/aulas/bd2005-
1/aula6.html>. Acesso em: 02 mar. 2021.
SANTANA, de Fabiano. AD - Active Directory. [S.l], [2008]. Disponível em:

<http://www.juliobattisti.com.br/fabiano/artigos/activedirectory.asp>. Acesso em: 04
mar.2021.
SHIMITT, Carlos. Sistemas Integrados de Gestão Empresarial: Uma Contribuição no

Estudo do Comportamento Organizacional e dos Usuários na Implantação de Sistemas
ERP. Florianópolis: Repositório Institucional (RI) da UFSC, 2004. Disponível em:
<https://repositorio.ufsc.br/handle/123456789/86941>. Acesso em: 02 mar. 2021.
SOFTEX. Guia Geral MPS de Software: mps.br - Brasil: Softex, 2020. Disponível em:
<https://softex.br/download/mps-br-guia-geral-software-2020/>. Acesso em: 04 mar. 2021
TATROE, Kevin. MACINTYRE, Peter. LERDORF, Rasmus. Programming PHP, 3ed

Edition. Editora: OREILLY 2013. Disponível em: <http://wtf.tw/ref/tatroe.pdf>. Acesso em:
07 mar. 2021.
The Apache Software Foundation. Software utilizado no Sistema disponível em:

<https://www.apache.org>. Acesso em: 07 mar. 2021.

Pim V

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pim V

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE PAULISTA - UNIP EaD

Projeto Integrado Multidisciplinar - PIM V

Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

MIRIAN CARLA CORRÊA - RA: 0547594

SISTEMA DE RESERVA DE EQUIPAMENTOS

SISTEMA DE RESERVA DE EQUIPAMENTOS

Projeto Integrado Multidisciplinar V - PIM V

Projeto Integrado Multidisciplinar para a obtenção

Orientador: Professora Patricia Toffolo

Em agradecimento aos professores do segundo semestre do Curso Superior de Tecnologia em

O Projeto Integrado Multidisciplinar V tem por objetivo utilizar os conhecimentos adquiridos

Palavras chave: Projeto. Sistema de Informação. Reserva de equipamentos.

Key words: Project. Information System. Equipment Reservation.

1.1. OBJETIVOS DO PROJETO.............................................................................11

2.1. MERCADO DE ATUAÇÃO............................................................................17

3. ENGENHARIA DE SOFTWARE II........................................................22

3.1. QUALIDADE DE SOFTWARE........................................................................23

4. PROJETO DE INTERFACE COM O USUÁRIO..................................52

4.1. ESPECIFICAÇÃO DA INTERFACE.................................................................52

5. Programação Orientada a Objetos............................................................69

Figura 01 - Evolução dos Sistemas de Informação e comunicação.....................................12

Figura 02 - Custos do Projeto.......................................................................................22

Figura 04 - Requisitos Funcionais.................................................................................29

Figura 05 - Requisitos Não Funcionais..........................................................................30

Figura 06 - Regras de Negócio......................................................................................31

Figura 07 - Descrição Requisitos Funcionais..................................................................32

Figura 08 - Processo de Teste de Software.....................................................................34

Figura 09 - Casos de Teste...........................................................................................35

Figura 10 - Especificações de Interface..........................................................................36

Figura 11 - Roteiro de Teste 01 | Login no Sistema.........................................................38

Figura 12 - Evidência: Tela 01 - Principal | Login e Senha...............................................38

Figura 13 - Roteiro de Teste 02 - Login Incorreto no Sistema...........................................38

Figura 14 - Evidência: Tela Inicial | Mensagem Erro Login e Senha.................................39

Figura 15 - Roteiro de Teste 03 | Cadastro de Usuário no Sistema com Sucesso..................39

Figura 16 - Evidência: Tela 02 - Usuários | Administrador..............................................40

Figura 17 - Evidência: Tela Usuários | Administrador - Mensagem Usuário Cadas.............41

Figura 18 - Evidência: Tela Usuários | Administrador - Definir Perfil de Usuário..............41

Figura 19 - Roteiro de Teste 04 | Cadastro de Usuário já cadastrado no Sistema................42

Figura 20 - Evidência: Tela Usuários | Administrador - Mensagem Usuário Já Cadastrado.42

Figura 21 - Roteiro de Teste 05 | Busca de Usuários no Sistema........................................43

Figura 22 - Evidência: Tela Usuários | Administrador - Buscar Usuário............................44

Figura 23 - Evidência: Tela Usuários | Administrador - Resultado da Busca......................44

Figura 24 - Evidência: Tela Usuários | Administrador - Usuário Não Encontrado..............45

Figura 25 - Roteiro de Teste 06 | Cadastro de Equipamentos no Sistema com Sucesso.........45

Figura 27 - Evidência: Tela 04 - Nova Reserva | Administrador - Reserva de Equipamentos 47

Figura 28 - Evidência: Tela Equipamentos | Administrador - Confirmação Reserva de

Figura 29 - Roteiro de Teste 08 | Busca e Cancelamento de Reservas de Equipamentos no

Figura 30 - Evidência: Tela Equipamentos | Administrador - Confirmação Cancelamento

Figura 31 - Roteiro de Teste 09 | Busca de Reservas de Equipamentos no Sistema..............49

Figura 32 - Evidência: Tela 07 - Nova Reserva | Usuário.................................................50

Figura 33 - Roteiro de Teste 10 | Reservar Equipamentos no Sistema...............................50

Figura 34 - Evidência: Tela 07 - Nova Reserva | Usuário.................................................51

Figura 35 - Evidência: Tela Nova Reserva | Usuário - Mensagem Reserva Realizada..........52

Figura 36 - Diagrama de Caso de Uso | Administrador....................................................54

Figura 37 - Diagrama de Casos de Uso | Usuário............................................................55

Figura 38 - Caso de Uso 01 | Login no Sistema...............................................................55

Figura 39 - Caso de Uso 02 | Cadastro de Usuários no Sistema.........................................56

Figura 40 - Caso de Uso 03 | Busca de Usuários no Sistema..............................................57

Figura 41 - Caso de Uso 04 | Definir Perfil de Usuário.....................................................58

Figura 42 - Caso de Uso 05 | Cadastro de Equipamentos no Sistema.................................59

Figura 43 - Caso de Uso 06 | Reserva de Equipamentos no Sistema...................................60

Figura 44 - Caso de Uso 07 | Consulta de Reserva de Equipamentos no Sistema.................61

Figura 45 - Caso de Uso 08 | Cancelamento de Reserva de Equipamentos no Sistema.........61