UNIVERSIDADE PAULISTA - UNIP EaD

Projeto Integrado Multidisciplinar

Curso Superior de Tecnologia

MATHEUS NASCIMENTO DA SILVA – RA 0455229

PROJETO DE DESENVOLVIMENTO DE UM SISTEMA DE RESERVA DE

EQUIPAMENTOS

SÃO PAULO – SP UNIVERSIDADE PAULISTA

2022

1
MATHEUS NASCIMENTO DA SILVA – RA: 0455229

SISTEMA DE RESERVA DE EQUIPAMENTOS

Projeto Integrado Multidisciplinar

para obtenção do título de graduação em analise
Desenvolvimento de Sistemas apresentado à
Universidade Paulista – UNIP EaD
Orientador(a):Professora Priscila Facciolli

São Paulo – SP Polo de Pirituba

2022

2
RESUMO

O Projeto Integrador Multidisciplinar (PIM) promove o envolvimento de professores e

alunos na busca da interdisciplinaridade. O presente estudo vem discorrer sobre as
disciplinas aplicadas durante o semestre, com o objetivo de complementar o processo
de aprendizagem do curso de tecnologia. A temática de estudo proposta para o PIM
V é um projeto de reserva de equipamentos pelos funcionários de uma escola.
Que tem como propósito agilizar, controlar e monitora o uso de equipamentos e
recursos de apoio aos professores da escola.
Então a escola entra em contato com uma empresa de software para desenvolver um
sistema de reserva de equipamentos O sistema tem como objetivo cadastro dos
equipamentos, que forem solicitados por cada professor controlar entrada e saída e o
estado que o equipamento se encontra, na devolução, emite relatórios, conforme o
pedido do usuário, especificando situação do aparelho etc... relatórios de com que
determinado aparelho está, também podendo fazer programações de quando o
aparelho será devolvido e efetuando uma reserva para que ninguém possa pegar
tendo assim completo conhecimento das disponibilidades destes aparelhos e de como
eles foram usados, quem utilizou, o estado da entrega e devolução dos equipamentos,
controlar datas entradas e saídas e horários de reserva.

Palavras-chave: Sistema, Controle Reserva, Equipamentos, MYSQL, PHP E APACHE

3
ABSTRACT

The Multidisciplinary Integrator Project (PIM) promotes the involvement of teachers

and students in the search for interdisciplinarity. The present study discusses the
subjects applied during the semester, with the aim of complementing the learning
process of the technology course. The study theme proposed for the PIM V is a project
of equipment reservation by the employees of a school.

Its purpose is to streamline, control and monitor the use of equipment and resources
to support school teachers

So the school gets in touch with a software company to develop an equipment

reservation system The system aims to register the equipment, which is requested by
each teacher to control entry and exit and the state that the equipment is in, upon
return, issues reports, according to the user's request, specifying the situation of the
device etc... reports on what a device is, also being able to schedule when the device
will be returned and making a reservation so that no one can pick it up, thus having full
knowledge of availability of these devices and how they were used, who used them,
the status of delivery and return of the equipment, control arrival and departure dates
and reservation times.

Keywords: System, Reserve Control, Equipment, MYSQL, PHP E APACHE

4
SUMÁRIO
1.CAPA ...................................................................................................................... 1
2.FOLHA DE ROSTO ................................................................................................ 2
3.RESUMO ................................................................................................................ 3
4.ABSTRACT ............................................................................................................ 4
5.SUMARIO ............................................................................................................... 5
6. INTRODUÇÃO ...................................................................................................... 6
7. DESENVOLVIMENTO ......................................................................................... 7
1.ECONOMIA E MERCADO ........................................................................ 7
2.1 OS AGENTES ECONÔMICOS ................................................................ 7
2.2 INVESTIMENTO FINANCEIRO E CRONOGRAMA ................................ 8
3. METODOLOGIA MPS.BR E QUALIDADE ................................................ 8
4. PLANEJAMENTO .................................................................................... 10
5. FERRAMENTAS IMPLEMENTAÇÃO ..................................................... 11
6. RESERVA EQUIPAMENTOS ATUAL ..................................................... 12
6.1 DIFICULDADES APRESENTADAS PELO MODELO ATUAL ............. 12
7. LEVANTAMENTO DE REQUISITOS ....................................................... 13
7.1 REQUISITOS FUNCIONAIS ................................................................. 13
7.2 REQUISITOS NÃO FUNCIONAIS ......................................................... 14
7.3 REGRAS DE NEGÓCIO ........................................................................ 14
8. ROTEIRO DE TESTES ............................................................................ 15
9. INTERFACES .......................................................................................... 16
10. CLASSE ................................................................................................ 18
8. CONCLUSÃO ...................................................................................................... 19
9. REFERÊNCIAS BIBIOGRAFICAS ...................................................................... 20

5
INTRODUÇÃO

Com o crescimento do volume de negócios e a expansão das empresas, surgem

também a necessidade de melhor planejamento das tecnologias utilizadas.
Como benefício do uso adequado dos recursos tecnológicos, podemos citar a
agilidade, qualidade nos processos internos, redução de custos, segurança da
informação, acessibilidade, ganho de produtividade e competitividade, entre outros.
Este projeto vamos abordar como controlar e organizar as reservas de utilização de
equipamentos necessários para as aulas serem mais esclarecedoras, aspectos
complementares de determinado assunto, atrativas, com imagens, vídeos, notícias,
comentários para um maior compreendimento, os equipamentos são para professores
e funcionários da escola.
Alguns problemas foram relatados pelos professores sobre os equipamentos que
escola disponibiliza, como colidir de precisar usar um determinado equipamento e
estar sendo utilizado por outro professor, e colidindo o horários ou saturar a
quantidade de aparelhos disponíveis e com insuficiência de organização quando
realizar uma reserva e verificar se está acessível para uso, se o equipamentos estão
disponíveis, e isso acaba sendo um recurso falho, transpondo assim um problema que
acarretará em um transtorno para o professores.
Para solucionar esses problemas a escola contratou uma empresa de software para
desenvolver um sistema para controlar as reservas dos equipamentos, fazendo se
necessário controlar o uso e as disponibilidades dos equipamentos disponíveis
pertencentes a escola.
Com esse controle será possível ter constantemente o conhecimento de quem usou
cada equipamento, quando e onde, contendo a descrição de sua usabilidade. Este
sistema tem como intuito auxiliar e informatizar o uso de equipamentos, aumentando
sua confiabilidade para ter total controle de cada equipamento disponível, para
conteúdo de aulas mais didáticas, sendo um tipo de agendamento de equipamento,
data e hora que será preciso para seu uso.
Este projeto relata o processo de elaboração de um sistema de software para controle
de reservas de equipamentos multimidias, Data show, TV com VCR, TV com DVD,
Projetor de Slides, Sistemas de Áudio-Microfone, Caixa Amplificada, Notebooks, o que
for necessário para os professores ministrarem suas aulas.
Este sistema será desenvolvido em linguagem JAVA e banco de dados MySQL
(Structured Query Language), esse é o modo mais viável para esse tipo de sistema
para internet, o Apache lhe permite a publicação de informações em sua intranet, é
6
utilizado principalmente para desenvolvimento web, seja plataforma Unix/Linux quanto
na Windows.
Desta forma, o desenvolvimento do sistema, para controlar reservas de
equipamentos, terá relevância para realização deste trabalho os transtornos ocorridos
pela inconsistência da desorganização das reservas dos aparelhos, inviabilizando o
planejamento dos usuários dos aparelhos e confrontando os contratempos. E iremos
abordar um pouco das disciplinas, Economia e Mercado, Engenharia Software II,
Programação Orientada a Objetos I, Projeto de Interface com Usuário.

DESENVOLVIMENTO

1.ECONOMIA E MERCADO
Atualmente, a utilização de sistemas de informações ou aplicações em software tem
sido essenciais na automação de processos, ganho de produtividade e
consequentemente, aumento de lucros das empresas. Como também nos mais
diferentes setores da economia, tiveram raiz os estudos e observações do economista
britânico Adam Smith em sua obra A Riqueza das Nações em 1776, em que cita a
divisão do trabalho entre diversos homens implica no aumento da produtividade
(MANZALLI, 2018). Neste trabalho, a elaboração do software de implementação de
um sistema de reserva e controle de empréstimos de equipamentos audiovisuais para
o Colégio Vencer Sempre que serão utilizados pelos professores para ministrar suas
aulas que irão ser mais esclarecedoras. A aquisição do software é realizada pela
administração da escola, que nesse cenário, é o agente demandante do produto
software.

2.1 OS AGENTES ECONÔMICOS

que interferem no projeto: o governo que sustenta a escola por sua vez entra como
sustentador dos serviços de ensino.
Empresas: Escola entra como empresa que presta serviços de ensino e contratam os
serviços de software.
Governo: Administra os impostos recolhidos das famílias e empresas e administram
esses recursos que são consumidos pela coletividade.
Mundo: Comércio exterior registra as transações econômicas com agentes
econômicos pertencentes a outros países.

2.2 INVESTIMENTO FINANCEIRO E CRONOGRAMA

7
 Por ser um projeto simples não pode ser vendido a um preço alto, os custos para
produção do software devem ser baixos, mas tem que atender aos padrões de
qualidades, e dentro das possibilidades deve ser entregue em um prazo solicitado,
sendo assim tendo um bom diálogo entre toda a equipe e o solicitante.
Após a confirmação da Escola o projeto, iniciara e as etapas, detalhadas a seguir, são
o cumprimento da entrega do software no prazo máximo de 90 dias (três meses).
O cumprimento das determinações do cronograma de entrega é crucial, de extrema
importância, pois, se descumprimos, podem gerar insatisfação do cliente, gerando
gastos desnecessários internos e até uma falência do projeto.
Os steakroads Serão um analista de sistemas para fazer o levantamento de
requisitos, planejamento e documentação, um desenvolvedor que irá codificar a
ferramenta e um testador para fazer toda validação do produto para depois entregar
o projeto.
Será de (7) dias o levantamento de requisitos do projeto, mais (7) dias para
compreender e entender o projeto e discutir e dar feedbacks. Prototipação e validação
junto ao usuário final do sistema, e de sessenta (60) dias para a codificação do
sistema, e quinze (15) dias para averiguação do projeto realizar todos os testes,
entregar o projeto com qualidade e no tempo estimado.
O custo do projeto será de acordo com o salário dos três envolvidos (analista,
desenvolvedor e testador) durante os 90 dias do projeto. Mais o custo total do projeto
incluindo mão de obra, licença de uso, mais mensalidades e custos de implantação:
• Análise: 15 dias (120 horas)
• Desenvolvimento: 60 dias (480 horas)
• Testes: 15 dias (120 horas)
• Tempo estimado de conclusão: 90 dias (760 horas)
• Valor total do projeto: R$ 60.000,00

3. METODOLOGIA MPS.BR E QUALIDADE

O MPS.BR é parte de um programa criado em 2003, pela coordenação SOFTTEX-
Associação da Promoção da Excelência do software Brasileiro, com o apoio de
organizações como MCTI – Ministério da Ciência, tecnologia e Inovação, da FINEP –
Financiadora de Estudos e projetos e do SEBRAE – Serviço Brasileiro de Apoio às
Micro e pequena Empresas e BID/FUMIN – Banco Internacional de desenvolvimento,
com o intuito de contribuir para uma competitividade das Micro e pequenas empresas
brasileiras produtoras de softwares, apoiando-as através da divulgação e adoção de
modelos de melhoria de processo de software.
Com a aplicação da metodologia, o mercado produziria produtos e serviços com
padrões de qualidades internacionais. Nesta metodologia, é realizada uma avaliação
8
e certificação das empresas em qualidade de processo de software, assim como as
realizadas pela metodologia CMMI, porém com adaptação a realidade brasileira.
Prevê uma graduação de níveis para as empresas avaliadas. A MPS.br tem em seu
escopo um conjunto de modelos referenciais, guias de implementação, avaliação e
aquisição.
Essas guias podem ser obtidas gratuitamente no site da SOFTTEX. A metodologia
MPS.br tende a ser mais leve em relação aos demais modelos existentes, atingindo
um maior número de empresas que tenham capacidade em alcançá-las. Os custos
para aplicação são considerados médios, e por isso metodologia escolhida para
aplicação na empresa que produzirá o software para reserva de equipamentos. O
MPS.br tem como base técnica as normas ISSO/IEC 12207;2008 [ISO/IEC, 2008a],
ISSO/IEC 20000;2011 [ISO/IEC, 2001] e ISO/IEC 15504-2 [ISSO/IEC, 2003].
Os níveis de maturidade estabelecem patamares de evolução de processos,
caracterizando estágios de melhoria da implementação de processos na organização.
O nível de maturidade em que se encontra uma organização permite prever o seu
desempenho futuro ao executar um ou mais processos.
Os níveis de maturidade da metodologia MPS.br:
• Nível A - Em otimização: não apresenta específicos para esse nível, apenas
modificando e aprimorando os processos existentes nos níveis anteriores.
• Nível B - Gerenciado Quantitativamente: apresenta além dos processos que já foram
informados nos níveis anteriores, a evolução da “Gerência de Projetos”;
• Nível C – Definido: inclui processos de “Desenvolvimento para Reutilização”,
Gerência de Decisões” e “Gerência de Riscos”;
• Nível D - Largamente Definido: incorpora além dos níveis anteriores, os processos:
“Desenvolvimento de Requisitos”, “Integração do Produto”, “Projeto e Construção do
Produto”, “Validação” e Verificação”;
• Nível E - Parcialmente Definido: composto pelos processos dos níveis anteriores, e
adicionados os processos: “Avaliação e Melhoria do Processo Organizacional”,
“Definição do Processo Organizacional”, “Gerência de Reutilização”;
• Nível F – Gerenciado: além dos processos implantados no nível anterior, são
adicionados novos processos: “Aquisição”, “Gerência de Configuração”, “Garantias
da Qualidade”, “Gerência de Portfólio de Projetos” e “Medição”;
• Nível G - Parcialmente Gerenciado: primeiro nível a ser atingido, implantando os
processos de “Gerência de Projetos”;
Como a empresa de software está em fase inicial, a ideia é iniciar a implantação do
nível G da maturidade do MPS.br, para que quando exista o crescimento e ampliação
da empresa, o modelo já esteja integrado à sua cultura, para implantação dos níveis
seguintes do MPS.br:

9
4. PLANEJAMENTO
Para obtenção de bons resultados do projeto, foi necessária a aplicação de
metodologias de engenharia de software em todo o projeto.
Para Pressman (2006), ela ajuda os engenheiros de software a compreender melhor
o problema que eles vão trabalhar para resolver.
Foram utilizadas normas e metodologias para facilitar o entendimento do cliente,
quais são os usuários que realmente irão interagir com o sistema, tendo início nas
etapas de levantamento dos requisitos funcionais, e não funcionais regras de negócio
e finalização entrega do produto e no aceite do cliente, passando pelas fases de
codificação e validação do projeto.
Os requisitos estão ligados a identificação das metas a serem atingidas no
funcionamento do software. É um processo de obtenção, refinamento e verificação
das necessidades do cliente em relação ao problema que será abordado/resolvido
pelo software.
Quanto mais completa e correta for a análise dos requisitos, melhor será o resultado.
Uma vez que automatiza o processo e o torna preciso, organizado e fácil de utilizar,
tornando viável o investimento da escola nesses equipamentos e no software, onde
através do comando reserva, que além da organização no processo, vai permitir a
escola melhorar agilidade no dia a dia.
Para desenvolver esse software, é necessário seguir respeitáveis métodos de
trabalho, que são projetados por pessoas com muita experiência e que permitem evitar
erros que poderiam atrasar o projeto ou mesmo fracassar.
Esses métodos são compostos de várias fases, que são:

• ANÁLISE DE REQUISITOS:
Qual é o problema a ser resolvido? Qual a necessidade do cliente.

• ANÁLISE:
Início da definição de informática, mas sem pensar numa implementação; precisa-se
definir qual linguagem será usada, o banco de dados etc.

• PROJETO:
Análise e descrição detalhada da futura implementação.

10
• IMPLEMENTAÇÃO:
Desenvolvimento do projeto.

• TESTE:
Testar se o sistema implementado faz o que era preciso, sendo definido inicialmente
sem erros.
As primeiras fases são as mais importantes e as mais difíceis, um erro nessas etapas
pode ter consequências muito graves.
Conforme citado, as fases não são tão bem separadas. Na realidade, torna-se difícil
de marcar exatamente o limite entre qualquer das etapas acima. O processo de
desenvolvimento também não é tão simples, precisa-se sempre de retornos para
corrigir alguns erros. O importante é descobri-los o mais rápido possível para não
perder tempo demais refazendo as coisas erradas, pois, como nos alerta Pressman
(2005), a importância do Software é o mecanismo que nos possibilita aproveitar e dar
vazão a esse potencial.
O que caracteriza um Software, segundo Pressman, é o fato deste poder ser
construído de diferentes formas, adequado ao que o ser humano constrói. O Software,
porém, não é sensível a problemas ambientais, que fazem com que o Hardware se
desgaste, e a maioria dos Software são feitos sob medida à sua realidade.

5. FERRAMENTAS IMPLEMENTAÇÃO
• PHP (Personal Home Page Tool ou ferramenta de página pessoal) [WEL 03] PHP
(um acrônimo recursivo para “PHP: Hypertext Preprocessor”) é uma linguagem de
script Open Source de uso geral, muito utilizada e especialmente guarnecida para o
desenvolvimento de aplicações Web embutível dentro HTML. Destaca-se entre as
linguagens por ser multiplataformas, ou seja, aceita vários sistemas operacionais,
como Windows, Unix, Linux etc. Além disso, ela é de fácil aprendizado, pois permite
a conexão direta com uma grande quantidade de bancos de dados relacionais
. • MYSQL [WEL 03]: É um servidor de banco de dados SQL multi-usuário e multi-
threaded, SQL é a linguagem de banco de dados mais popular no mundo. MySQL é
uma implementação cliente-servidor que consiste em um servidor e diferentes
programas clientes e bibliotecas. SQL é uma linguagem padronizada que torna fácil o
armazenamento e acesso de informações. O servidor MySQL é rápido e flexível o
suficiente para permitir armazenar logs e figuras nele. As principais vantagens do
MySQL são: velocidade, robustez e facilidade de uso.
• Apache [MAR 03]: O PHP foi criado pelo engenheiro de software Rasmus Lerdorf.
Rasmus faz parte da equipe de desenvolvimento Apache (www.apache.org). O
engenheiro lançou a primeira versão do PHP no final de 1994. Além de permitir que
você disponibilize conteúdo na Internet o Apache lhe permite a publicação de
11
informações em sua Intranet, tornando-o realmente um produto indispensável. Este
produto serve para servidores Linux e Windows, suportando aplicação de pequeno,
médio grande porte, Servidor Web.

6. RESERVA EQUIPAMENTOS ATUAL

A reserva atual dos equipamentos atualmente é efetuada pelos professores, para uso
em uma determinada data e registrada manualmente num livro confeccionado pela
secretária da escola.
Este livro está organizado por data da utilização, isto é, por data sequencial e suas
páginas constam relacionados todos os equipamentos disponíveis para uso, Turmas
e Professores.
O método atual de agendamento consiste seguintes passos:
• O professor dirige-se a secretária de coordenação.
• Informa a secretária da coordenação a necessidade do agendamento dos
equipamentos que serão necessários, o dia para agendamento e a turma onde serão
instalados os equipamentos.
• A secretária verifica se os equipamentos solicitados para reserva estão disponíveis
para o dia pretendido, através de realização de pesquisa manual no próprio formulário
existente para reserva.
• Se estiverem livres, são registrados no livro de registro, o nome do professor, os
equipamentos necessários e a turma onde serão instalados.
• No dia solicitado, a secretária da coordenação informa ao funcionário da
necessidade de instalação desses equipamentos nas respectivas turmas conforme
reserva efetuadas pelos professores.

6.1 DIFICULDADES APRESENTADAS PELO MODELO ATUAL

Observa-se que o processo de controle de reserva de equipamentos atualmente em
uso é obsoleto e caro, pois envolve despesas de uso de papel, encadernação, tinta
etc. Também é visível a baixa qualidade do serviço de controle à disposição e o tempo
que se perde para ir a secretaria ver se tem disponibilidade procurar no livro.
Além disso, a organização pode ser prejudicada uma vez que, eventualmente, um
equipamento pode ser reservado em duplicidade ou não reservado ocasionado por
falta de anotação de reserva não registrada na solicitação pessoal ou via telefone.
O sistema atual de reserva de equipamentos apresenta, segundo a secretária da
coordenação, as seguintes dificuldades:

12
• A falta de registro de reserva dos equipamentos solicitados, às vezes por
esquecimento da própria secretária bem como dos professores. Os professores
muitas vezes acham que foi solicitado o agendamento e na verdade não solicitaram.
• A confecção do livro de boletins de registros por ter uma página, para cada dia do
ano, exceto domingos, gera um volume com aproximadamente 261 folhas.
• Não possui relatórios rápidos e atualizados.
• Também não disponibilização relatórios de uso e de estado do equipamento.

7. LEVANTAMENTO DE REQUISITOS
Os requisitos podem ser classificados em dois grupos requisitos funcionais e não
funcionais.
Osa requisitos não funcionais descrevem o comportamento do sistema e suas ações
durante uma interação com usuário, ou seja, é aquilo que tem que ser feito pelo
sistema (suas funcionalidades).
Os requisitos não funcionais são aqueles relacionados ao ambiente onde o sistema
está inserido. Em geral estão relacionados com confiabilidade, performance e
robustez. Com isso definimos se o sistema será eficiente para tarefa que se propõe a
fazer ou não. A seguir serão apresentados os requisitos funcionais além de uma breve
descrição.

7.1 REQUISITOS FUNCIONAIS:

Que serão as necessidades que software precisar comprimir:
Requisitos Funcionais
RF01: O software deve permitir a inclusão, alteração, exclusão e visualização de
usuários.
RF02: O software deve permitir a inclusão, alteração, exclusão e visualização de
equipamentos.
RF03: O software deve possuir uma interface gráfica que permita a inclusão,
alteração, exclusão e visualização, de agendamento dos equipamentos, realizadas
pelos usuários.
RF04: O agendamento só pode ser realizado dentro de um período, estipulado pelo
colégio, com data máxima para agendar, e a mínima para agendar.
RF05: O agendamento só pode ser realizado, se tiver equipamentos disponíveis para
agendar, o software não pode ter mais agendamento do que equipamentos
disponíveis.

13
RF06: O software deve ter um campo de observação na tela de agendamento para
notificar alguma necessidade especial no agendamento.

7.2 REQUISITOS NÃO FUNCIONAIS:

Que serão as necessidades técnicas que o software precisa ter para alcançar os
requisitos funcionais:
Requisitos Não Funcionais
RN01: O software deverá se desenvolvido na linguagem PHP.
RN02: O software deverá utilizar banco de dados MySQL.
RN03: O software para identificar os usuários, deve possuir um sistema de login.
RN04: O software deve checar se o agendamento realizado não está sendo
duplicado, e checar se possuí o equipamento disponível para o agendamento
realizado.
RN05: O software deve ser responsivo na utilização, e ter tempo de resposta rápido.
no banco de dados do sistema devem ser feitas em tempo real.
RN06: Parte do software deve ser omitido entre os diferentes usuários. Administrador
do software devem possuir acesso ao cadastro e agendamento, enquanto os usuários
professores devem ter acesso apenas aos agendamentos.
RN07: Em caso de erros o sistema deve permitir a correção deles.

7.3 REGRAS DE NEGÓCIO

Dentro do contexto de desenvolvimento de software, as regras de negócio são
responsáveis pela definição do comportamento do software. Na implementação do
sistema trabalharemos com as seguintes regras de negócio:
Regras de Negócio
RN01: Equipamentos não podem ter o mesmo nome ao serem criados.
RN02: Usuários não podem ter o mesmo login ao serem criados.
RN03: Não são permitidas agendamento de um mesmo equipamento na mesma data
e horário atuais.
RN04: Agendamentos e exclusão só podem ser feitos em data e horários posteriores
a data e horário atuais.
RN05: Treinamento na utilização dos usuários do sistema.

14
8. ROTEIRO DE TESTES
Após estabelecer as necessidades e desenvolver o sistema, se faz necessário
testarmos suas funcionalidades para identificar se o mesmo irá realizar suas funções
necessárias.
Para isso é criado um roteiro de testes, para testar suas funções básicas e avançadas.
• Teste: 1 Objetivo: Testar login do sistema. Pré-condição: - Procedimento:
Digitar usuário e senha corretos. Resultado esperado: Ao digitar login correto o
usuário deve ser logado ao sistema.

• Teste: 2 Objetivo: Testar login do sistema. Pré-condição: - Procedimento:

Digitar usuário e senha errados. Resultado esperado: Ao digitar login errado o
usuário deve ser informado com mensagem de erro.

• Teste: 3 Objetivo: Testar agendamento. Pré-condição: Estar logado com

usuário. Procedimento: 1. Clicar em uma data disponível no calendário. 2.
Preencher os campos. 3. Gravar. Resultado esperado: Ao gravar com os
campos preenchidos, mensagem confirmando agendamento deve ser
apresentada.

• Teste: 4 Objetivo: Testar agendamento. Pré-condição: Estar logado com

usuário. 22 Procedimento: 1. Clicar em uma data no calendário. 2. Preencher
os campos. 3. Gravar. Resultado esperado: Ao selecionar um equipamento não
disponível, ou sala ocupada, ou período ocupado, usuário, deve ser informado
a indisponibilidade referente ao campo inacessível.

• Teste 5 Objetivo: Testar exclusão de agendamento. Pré-Condição: Ter um

agendamento. Procedimento: 1.Clicar em seus agendamentos. 2. Clicar em
excluir. Resultado esperado: Mensagem questionando se deseja realmente
excluir deve aparecer.

• Teste: 6 Objetivo: Testar agendamento fora do período. Pré-Condição: Esta

logado com usuário. Procedimento: 1. Alterar o calendário para uma data fora
do prazo. 2. Clicar em uma data fora do prazo. Resultado esperado: Mensagem
informando que essa data está fora do prazo, deve aparecer.

15
9. INTERFACES

TELA DE LOGIN, CRIADO PELO AUTOR

FALHA DE LOGIN, CRIADO PELO AUTOR

16
MENU DE AGENDAMENTO, CRIADO PELO AUTOR.

TELA DE AGENDAMENTO, CRIADO PELO AUTOR

17
MENU DE AGENDAMENTOS, CRIADO AUTOR

10. CLASSES
O sistema precisara ter classes bem definidas para ter um funcionamento correto, e
agilizar o processo de desenvolvimento dele. Essas classes serão as responsáveis
por gerenciar e estruturar a lógica do programa, e com funcionamento correto. Uma
prática que será muito utilizada será a de herança.
Citado o livro texto do curso de Programação Orientada a Objeto I (p.124): Em outras
palavras, a herança é um mecanismo de reaproveitamento em que as classes
originais ficam contidas na nova classe. A opção de poder criar uma classe principal,
que iremos chamar de superclasse, e ter classes secundarias, que iremos chamar de
subclasses. As classes Administrador e Funcionário são subclasses da classe
Usuário, logo, elas importam todos os atributos e métodos da superclasse para si
mesmo.
Mas podemos reparar que as subclasses possuem métodos com o mesmo nome da
superclasse, e isso é o que chamamos de Polimorfismo. Citando novamente Livro
Texto do curso de Programação Orientada a Objeto I (p. 135): Desta forma, duas ou
mais classes derivadas de uma mesma superclasse podem invocar métodos que têm
o mesmo nome, mas comportamentos distintos, especializados para cada classe
derivada, usando para tanto uma referência a um objeto do tipo da superclasse.
Definindo o método da superclasse com o atributo virtual, e aplicando o atributo over
ride nos métodos das subclasses, podemos rescrever os métodos sem
necessariamente criar um novo. Ter subclasses auxilia na categorização de objetos,
quando forem instanciados.

18
 Objetos são as instancias das classes durante a execução do programa. O Objeto é
algo que você utiliza e manipula na execução do programa, enquanto a Classe é a
lógica que foi desenvolvida para definir o funcionamento do Objeto.
Se formos trazer essa lógica para o mundo real, Classe é a planta de uma casa,
enquanto o Objeto dessa classe é a casa em si.

8.CONCLUSÃO

Ao apresentar as informações presentes neste estudo, mostro a viabilidade para uma

solução proposta para resolver, o problema do colégio Vencer Sempre. Com um
software de agendamento de equipamentos, seguindo as normas de qualidade e
tendo boas práticas na criação do código do software, podemos ver que é possível
tratar o problema apresentado, de agendamento de equipamentos, com uma solução
tecnológica que trará grandes benefícios para a instituição.
Com o conhecimento adquirido pelo curso de Engenharia de Software II, apresentei
rotinas de testes e uma norma de qualidade que será para aplicar ao projeto, focando
na qualidade e viabilidade do mesmo.
Com o conhecimento adquirido pelos cursos Projeto de Interface com o Usuário e
Programação Orientada a Objetos I, apresentei uma estruturação de classes, e
conceitos de interfaces para o programa, a qual visita os bons costumes de
programação e usabilidade do usuário.
Com o conhecimento adquirido pelo curso de Economia e Mercado, apresentei a
viabilidade do projeto e os agentes econômicos que se aplica essa solução. Com todo
esse conhecimento adquirido mostro uma solução que resolve os problemas
levantados anteriormente, sempre focando na qualidade do produto e na melhor
solução para todos as partes.

19
9. REFERÊNCIA
https://ava.ead.unip.br/bbcswebdav/pid-2682409-dt-content-rid-
6441945_1/institution/Conteudos_AVA/PROJETO%20INTEGRADO%20MULTIDISCI
PLINAR%20-
%20REGULAR/SUP%20TEC%20EM%20AN%C3%81LISE%20E%20DESENVOLVI
MENTO%20DE%20SISTEMAS/PROJETO%20INTEGRADO%20MULTIDISCIPLINA
R%20V/Manual%20do%20PIM%20V.pdf
Frederico Lopes, Helder; T. Ito Olavo. Programação orientada a objetos I. 1 ed. São
Paulo: Editora Sol, 2015.
Soares de Souza, Luciano. Projeto de interface com o usuário. 1 ed. São Paulo:
Editora Sol, 2015.
https://www.cursoemvideo.com/
Cursos PHP, MYSQL, HTML E SQL pelo curso em video
COSTA, IVANIR. Engenharia de Software. - São Paulo: Editora Sol, 2014. 168 p.
MANZALLI, MAURICÍO, FELIPPE e DITICIO, Claudio. Economia e mercado. - São
Paulo: Editora Sol, 2018. 248 p. https://www.impacta.edu.br/blog/desenvolvimento-
software-conheca-profissionais/
[COM 01] CONVERSE, Tim; PHP 4 a Bíblia – Campos. 2001. 696p. [MAR 03]
MARCELO, Antônio; Apache – Guia Rápido do Administrador de Redes –
BRASPORT, 2003.
PRESSMAN, R. S. (2006). Engenharia de Software. MH - MCGRAW HILL.SINTES,
Tony. Aprenda programação orientada a objetos em 21 dias. São Paulo: Pearson
Education do Brasil, 2002.
https://www.promovesoluções.com/quais-são-os-níveis-de-maturidade-domps-br/.
https://www.softex.br/wpcontent/uploads/2013/07/MPS.BR_GUIA_GERAL
_SOFTWARE_2012-c-ISBN- 1.pdf.
Quanto vale um software que você produz. Disponível em:
https://www.marcoratti.net/eng. gvs.html
. UNIP – Universidade Paulista. Economia e Mercado.
UNIP – Universidade Paulista. Programação Orientada à Objetos I.
UNIP – Universidade Paulista. Projeto de Interface com Usuário.
UNIP – Universidade Paulista. Engenharia de Software II.
MELO, Alexandre; NASCIMENTO, Maurício. PHP Profissional: Aprenda a
Desenvolver Sistemas profissionais Orientados a Objetos com Padrões de Projeto.

20
São Paulo: NOVATEC Editora, 2007. Disponível em:
http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/25488
Document shared on www.docsity.com

21