Desenvolvimento de Sistema de Reserva de Equipamentos Audiovisuais

Prévia do material em texto

1 
 PROJETO INTEGRADOR MULTIDISCIPLINAR-PIM 5 
 CURSO SUPERIOR DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
 ANA PAULA DE OLIVEIRA CAMPOS - RA: 2228068 
 CAIO CESAR HILDEBRANDO ALVES DA SILVA - RA: 0606495 
 CARLOS EDUARDO FONTOURA SILVA - RA: 2222349 
 JOÃO PEDRO OBAGE PREDIN - RA: 2299440 
 JONAS ROBERTO DE LIMA - RA: 2227384 
 NAYARA KIYOTA PRADO - RA: 2228589 
 DESENVOLVER UM SISTEMA DE RESERVA DE EQUIPAMENTOS 
 AUDIOVISUAIS, QUE AGILIZE E CONTROLE 
 EMPRÉSTIMOS DE EQUIPAMENTOS E RECURSOS DE APOIO AOS 
 PROFESSORES DE COLÉGIOS DE ENSINOS 
 FUNDAMENTAL E MÉDIO. 
 LUZIÂNIA-GO 
 2023 
 2 
 PROJETO INTEGRADO MULTIDISCIPLINAR EM ANÁLISE E 
 DESENVOLVIMENTO DE SISTEMAS 
 Projeto Integrado Multidisciplinar - 
 PIM 5, apresentado como um dos 
 pré-requisitos para aprovação das 
 disciplinas do semestre vigente, no 
 Curso Superior de Tecnologia em 
 Desenvolvimento de Sistemas. 
 PROF(a). ORIENTADOR(a): 
 Profa. Ma. Gislaine Stachissini 
 LUZIÂNIA-GO 
 2023 
 3 
 RESUMO 
 O presente trabalho (PIM – Projeto Integrado Multidisciplinar), proposto pela UNIP – 
 Universidade Paulista, tem como objetivo estruturar um projeto com o objetivo de 
 desenvolver os arcabouços para construção de uma aplicação para reserva de equipamentos 
 audiovisuais, que visa agilizar e administrar nas escolas de ensino fundamental e médio a 
 cessão de instrumentos e recursos para apoiar os professores no suporte ao aprendizado dos 
 alunos. O procedimento utilizado corrobora pela possibilidade de oferecer umas possíveis 
 formas de estruturação dos professores e na busca de fundamentação teórica, aspirando o 
 sucesso nos processos de ensinagem, com a ajuda das novas tecnologias de informação e 
 comunicação, de que modo, como auxílio dos materiais. O projeto busca utilizar como pilares 
 todos os conceitos e conhecimento adquirido através das disciplinas do semestre vigente, para 
 se criar uma plataforma que atenda às premissas, sendo necessário pesquisar e compreender 
 qual é a melhor direção para se oferecer um produto que atenda todos os requisitos solicitados 
 para a resolução desse aprimoramento no uso de tecnologia da informação. Desse modo, o 
 projeto será elaborado a partir da definição de estratégias de acordo com as necessidades, 
 apontando a lógica de negócios e as técnicas de requisitos, programação e econômicas 
 adequadas para sua conclusão de forma eficiente. 
 Palavras-chave: Requisitos, sistema, orientação a objetos, economia e engenharia de 
 Software; 
 4 
 ABSTRACT 
 This work (PIM – Multidisciplinary Integrated Project), proposed by UNIP – 
 Universidade Paulista, has the objective of structuring a project with the objective of 
 developing the arcabouços for the construction of an application for the reservation of 
 audiovisual equipment, which aims to expedite and manage the schools of Teaching 
 fundamental and medium the cessation of instruments and resources to support the teachers 
 does not support the apprenticeship of two students. The procedure used corroborates the 
 possibility of offering some possible ways of structuring two teachers and in search of 
 theoretical foundation, aspiring or succeeding in our teaching processes, with the help of the 
 new information and communication technologies, in which way, as an aid to two materials. 
 The project seeks to use as pillars all the concepts and knowledge acquired through the 
 disciplines of the current semester, to create a platform that meets the requirements, being 
 necessary to research and understand which is the best direction to offer a product that meets 
 all the requested requirements for the resolution of this improvement not using information 
 technology. In this way, the project will be elaborated from the definition of strategies 
 according to the needs, relying on business logic and the requirements, programming and 
 economic techniques suitable for its conclusion in an efficient manner. 
 Keywords : Requirements, system, object orientation, economics and software 
 engineering; 
 5 
 SUMÁRIO 
 1. INTRODUÇÃO ...................................................................................................................... 6 
 2. OBJETIVO .............................................................................................................................. 8 
 3. ENGENHARIA DE SOFTWARE .......................................................................................... 8 
 3.1. ENGENHARIA DE REQUISITOS ............................................................................................ 9 
 3.2. REGRA DE NEGÓCIO ............................................................................................................ 12 
 4. NORMAS DE QUALIDADE: ........................................................................................................... 13 
 5. MERCADO E ECONOMIA ................................................................................................. 15 
 5.1. ESTUDO DE VIABILIDADE ECONÔMICA ......................................................................... 15 
 6. INTERFACE COM O USUÁRIO ........................................................................................ 17 
 6.1. PROTÓTIPOS ........................................................................................................................... 18 
 6.2. PROTÓTIPOS DAS TELAS .................................................................................................... 18 
 6.3. DIAGRAMAS ........................................................................................................................... 30 
 7. PROGRAMAÇÃO ORIENTADA A OBJETOS .................................................................. 32 
 7.1. CLASSES .................................................................................................................................. 32 
 7.2. OBJETOS .................................................................................................................................. 32 
 7.3. HERANÇA ................................................................................................................................ 32 
 7.4. POLIMORFISMO ..................................................................................................................... 33 
 8. ROTEIRO DE TESTES ........................................................................................................ 33 
 9. CONCLUSÃO ...................................................................................................................... 40 
 10. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................ 41 
 6 
 1. INTRODUÇÃO 
 Este trabalho PIM – Projeto Integrado Multidisciplinar V, tem como objetivo permitir 
 uma análise crítica, que tenta facilitar a busca de informação e a solução de problemas para 
 construção do conhecimento nas disciplinas elencadas para o desenvolvimento do trabalho. A 
 princípio o presente trabalho visa descrever toda prática que envolve a Análise e 
 Desenvolvimento de Sistemas dentro do projeto. Este trabalho é baseado nas teorias e práticas 
 das disciplinas nas quais tem os desafios de desenvolver um sistema de reserva de 
 equipamentos audiovisuais, que agilize o controle de empréstimos de equipamentos e recursos 
 e visando trabalhardiversos requisitos de projetos de software. Tais disciplinas são: 
 Engenharia de Software II, Economia e Mercado, Projeto de Interface com o Usuário e 
 Programação Orientada a Objetos I. 
 A disciplina Engenharia de Software vem apresentar uma visão geral dos processos 
 que envolvem a construção de uma aplicação de software, o foco está na mediação dos 
 seguintes conteúdos: princípios fundamentais da Engenharia de Software; processo de 
 software; modelos de processos de software; engenharia de requisitos; ferramentas CASE. A 
 Engenharia de Software é uma área que se preocupa com a aplicação de teoria, conhecimento 
 e prática para o desenvolvimento efetivo e eficiente de sistemas de software que satisfaçam os 
 requisitos dos usuários (ACM/IEEE, 2014). Os alunos egressos da disciplina de Engenharia 
 de Software devem demonstrar habilidades para gerenciar projetos de software, analisar, 
 projetar, verificar, validar, implementar e manter sistemas de software (Soares, 2004). A 
 Engenharia de Software (ES) é uma disciplina específica dos cursos de Computação e por si 
 só apresenta desafios na aprendizagem, pois contém foco excessivo na teoria. Somado aos 
 desafios da disciplina, o professor também se depara com a diversidade no nível de 
 conhecimento dos alunos (LEMOS; CUNHA; SARAIVA, 2019). A disciplina de projeto de 
 Interface com o Usuário vem com a ideia que com a disseminação das tecnologias houve o 
 surgimento de áreas de design. Entre elas, estão o UI e o UX. Por serem ramos que surgiram 
 em um mesmo período pode haver uma confusão entre os termos que divergem ou 
 convergem. O termo Experiência do Usuário (user experience, em inglês, geralmente 
 abreviado como UX) foi popularizado por Donald Norman no seu livro “The Invisible 
 Computer” (O computador invisível, em tradução livre – sem edição em português) (PETRIE; 
 BEVAN, 2009), para englobar “todos os aspectos das interações do usuário com o produto: 
 como ele é percebido, apreendido e usado. Inclui facilidade de uso e, mais importante de tudo, 
 as necessidades [do usuário] que o produto satisfaz”. A disciplina de Programação Orientada 
 7 
 a Objetos (POO) mostrou-se o paradigma de programação mais influente. Quase todos os 
 cursos da área de computação incluem a POO como parte do seu currículo [Beck and 
 Cunningham 1989]. Entretanto, ensinar este importante paradigma ainda é difícil, 
 principalmente quando ele é incluído após a programação procedural e o aluno precisar 
 “abandonar” o controle que ele conhece com o paradigma procedural e confiar no 
 conhecimento da POO [COOPER et al. 2003]. Assim, a criação e discussão de técnicas e 
 metodologias de ensino que despertem o interesse do aluno no processo de 
 ensino-aprendizagem da POO são de grande interesse dos educadores da área [Kölling 1999]. 
 A disciplina de Economia e Mercado que tradicionalmente classifica os sistemas econômicos 
 em economia de mercado ou capitalista, economia socialista ou planificada e/ou economia 
 mista. No Brasil, o sistema utilizado é o de mercado. Um sistema econômico é a maneira 
 como a sociedade se organiza visando solucionar a forma como utilizará seus recursos 
 produtivos (trabalho, capital, recursos naturais, etc) para produzir bens e serviços para atender 
 as necessidades da sociedade. Essa interação entre o público (as pessoas) e as unidades 
 produtoras (empresas) resulta, de acordo com Luiz e Silva (2001), em dois fluxos em um 
 sistema econômico: um fluxo de bens e serviços e, de outro lado, um fluxo monetário. 
 Diante do exposto acima, apresenta-se ao Colégio Vencer Sempre um projeto de 
 gestão que visa desenvolver um sistema de reserva de equipamentos audiovisuais, que agilize 
 e controle os empréstimos de equipamentos e recursos de apoio aos professores de colégios de 
 Ensinos Fundamental e Médio. que tem como foco unificar as informações, objetivando à 
 integração e sinergia entre o setor de audiovisual da escola e os professores, com 
 consequentes melhorias no ambiente e nas rotinas de trabalho, acarretando em 
 aperfeiçoamento do atendimento dispensado aos professores e colaboradores implementa a 
 simplificação de tarefas de disponibiliza equipamentos de informática e vídeo (tais como 
 datashows, TV com VCR, TV com DVD, projetor de slides, sistemas de áudio-microfone, 
 caixa amplificada, notebooks, kits multimídia etc.), refletindo em progressos na qualidade dos 
 produtos e serviços oferecidos. O presente trabalho visa, conquanto, proporcionar ao setor de 
 audiovisual do colégio, com base nos conhecimentos nas disciplinas acima já citadas, cumprir 
 de maneira rápida e segura sua finalidade, bem como atingir seus objetivos com eficiência. 
 2. OBJETIVO 
 A tecnologia da informação que permite vigiar é a mesma que aumenta a velocidade, e 
 com ela a economia ganhou uma agilidade e mobilidade nunca vistas, com o cenário onde 
 8 
 a economia se caracteriza pela intensa competitividade entre as empresas, inovações digitais 
 para a resposta de saúde pública e a influência das organizações, com a globalização e 
 juntamente com a queda de barreiras comerciais ocasionadas pelo surgimento da internet tem 
 como consequência uma disputa acirrada entre as companhias, “O espaço deixou de ser 
 obstáculo, não há mais fronteiras naturais nem lugares óbvios a ocupar” (BAUMAN, 
 ZYGMUNT (2001). Com o intuito de compreender os acontecimentos, possibilitando a 
 tomada de decisões de forma seguras e assertivas e com o uso adequado de sistemas que 
 gerenciam dados de maneira rápida e objetiva, em tempo real é imprescindível. 
 Perante o exposto anteriormente, intervenções eficazes e ao se analisar a demanda do 
 projeto decidiu- se então fazer-se a construção de uma ferramenta de fácil acessibilidade e 
 universalidade considerando o possível sistema. As ferramentas escolhidas foram a linguagem 
 web e ferramentas gratuitas para o ambiente de desenvolvimento e apoio dos processos da 
 engenharia de software sendo validadas por uma análise de viabilidade econômica. 
 O bjetivando à integração e sinergia entre as unidades de audiovisual e os professores e 
 coordenadores, com consequentes melhorias na gestão da informação, acarretando em 
 aperfeiçoamento do atendimento dispensado aos clientes e simplificação de tarefas ao reservar 
 os equipamentos de forma fácil e simplificada, refletindo em progressos na qualidade dos 
 serviços oferecidos. 
 3. ENGENHARIA DE SOFTWARE 
 Engenharia de software é constituída por diversas concepções estruturais que abrange 
 diversas ferramentas que possibilitam aos profissionais de tecnologia da informação fazer o 
 uso e desenvolverem aplicações software com alto nível de qualidade. A engenharia de 
 software (ES) é uma área da tecnologia sensibilizada com a especificação, desenvolvimento, 
 testes e criação de um software de maneira sistemática. A execução dessas tarefas, durante o 
 processo de desenvolvimento do software pelos profissionais de tecnologia, também é 
 indispensável às práticas de gerênciade projetos, particularmente as de organização, 
 produtividade e qualidade (PRESSMAN; MAXIM, 2016). A disciplina foi criada em como 
 solução à "crise do software", tachada por alto custo, baixa qualidade, insatisfação dos 
 clientes, atrasos na entrega e orçamentos acima do previsto (PRESSMAN; MAXIM, 2016). O 
 ensino da Engenharia de Software é de extrema importância em formar profissionais 
 qualificados no desenvolvimento de sistemas. Esses profissionais podem contribuir para a 
 qualidade de software, além de contribuir para resolução de problemas tradicionais e 
 9 
 indústrias de software (GIBBS, 1994, PRIKLADNICKI et al., 2009). Alguns processos e 
 procedimentos são essenciais para garantir a qualidade do produto de software. Nesse sentido 
 as técnicas de verificação e validação, para executar as atividades dessas técnicas é necessário 
 ter um meio rápido e prático para ser montado um projeto bem elaborado. As maneiras 
 essenciais de verificar se um software está pronto para ser utilizado pelo cliente é através de 
 várias etapas de qualidade como: 
 ● Projetos, prazos e custos sob controle; 
 ● Satisfação do usuário; 
 ● Diminuição de erros nos projetos de software; 
 ● Melhoria da competitividade da empresa 
 O foco da engenharia de Software versa sobre a aplicação e abordagens sistemáticas, 
 disciplinadas e quantificáveis para desenvolver, operar, evoluir e manter um software. No 
 processo de garantia da qualidade que considera se as características do produto estão dentro 
 das normas e/ou regras estabelecidas e se as atividades estão de acordo com o que foi 
 planejado. 
 3.1. ENGENHARIA DE REQUISITOS 
 A engenharia de requisitos, de acordo com Sommerville (2007, p. 49), tem como 
 objetivo definir o que o sistema deve fazer, quais as necessidades reais e identificar quais 
 restrições existem para que o software seja desenvolvido. É nesse processo da engenharia de 
 software que ocorre a comunicação entre o cliente e o analista da equipe de desenvolvimento. 
 Quando essa comunicação não é bem sucedida, o restante do projeto pode ficar 
 comprometido, causando impacto no custo e prazo. Conforme pode ser observado na Figura 
 1, Sommerville (2007) define que o processo de engenharia de requisitos é composto de 
 quatro atividades: estudo de viabilidade, levantamento e análise de requisitos, documentação 
 dos requisitos e, por fim, validação dos requisitos. Ao final dessas atividades, é obtido o 
 documento de requisitos. 
 10 
 Figura 01 – Atividades da Engenharia de Requisitos 
 Fonte: SOMMERVILLE, 2007, p. 50. 
 3.1.1. LEVANTAMENTO E ANÁLISE DE REQUISITOS 
 Esse trabalho prepara o levantamento das necessidades do usuário, ou seja, os 
 requisitos do sistema solicitado pelo cliente, pode ser realizado por diversas técnicas. Para 
 Sommerville (2007), a atividade de análise de requisitos visa priorizar e resolver conflitos 
 entre requisitos, pois quando vários usuários participam desse processo, é inevitável que 
 ocorra contradição entre requisitos levantados de usuários distintos. Na atividade de 
 levantamento de requisitos, o analista inicia uma comunicação com o usuário utilizando 
 técnicas para que possa obter o conhecimento das necessidades do usuário. Com as respostas 
 obtidas, é possível identificar quais serviços o sistema deve oferecer, quais as suas restrições, 
 o que é esperado pelo usuário e demais informações, tal como a possibilidade de integração 
 com outros sistemas. 
 Existem distintas técnicas para proceder o levantamento dos requisitos, 
 particularmente: Joint Application Development (JAD), prototipação, entrevista, questionário, 
 observação, Implantação da Função de Qualidade (IFQ), casos de uso e pontos de vista. Nesse 
 projeto foram usados as técnicas prototipação, entrevista. 
 Os Requisitos podem ter subclassificações em requisitos funcionais, requisitos de 
 qualidade ou funcionais e restrições ou regras de negócio. Existem dois tipos de classificação 
 de requisitos, são eles: Requisitos Funcionais(RF) e os Requisitos Não- Funcionais(RNF). As 
 Regra de Negócio (RN), são os dispositivos restringem e definem como um determinado 
 processo de negócio deve ser executado, além de demonstrar conhecimentos como a relação a 
 um processo, também constituem difíceis aspectos restritivos na execução deste processo. 
 11 
 3.1.2. REQUISITOS FUNCIONAIS 
 Os requisitos funcionais podem descrever o que o sistema deve fazer de forma 
 abrangente e abstrata ou de forma detalhada, de acordo com o público para o qual está 
 voltado. Caso seja para que os usuários entendam suas funcionalidades, a descrição será 
 simplista. Porém quando o alvo é a equipe de desenvolvimento, os requisitos funcionais 
 abrangem informações e detalhes mais específicos como suas funções, entradas e saídas e em 
 como o sistema deve se comportar em determinadas situações. (SOMMERVILLE, 2011). 
 Ávila e Spínola (2008, p 48) definem os requisitos funcionais resumindo as funcionalidades 
 que o software deve apresentar. 
 Deste modo, foram levantados os requisitos para o primeiro ciclo do projeto Colégio 
 Vencer Sempre: 
 Tabela 01 - Requisitos Funcionais do sistema 
 RF01: O sistema deverá permitir ao setor de audiovisual manter os equipamentos. 
 RF02: O sistema deverá permitir ao usuário manter a reserva dos equipamentos. 
 RF03: O sistema deverá permitir ao usuário confirmar a reserva efetuada junto ao whatsapp 
 do usuário. 
 RF04: O sistema deverá permitir ao usuário emitir um relatório das reservas efetuadas. 
 RF05: O sistema deverá permitir ao usuário consultar um painel das reservas efetuadas. 
 RF06: O sistema deverá permitir ao setor de audiovisual ter um controle de entrada e saída 
 dos equipamentos. 
 RF07: O sistema deverá permitir ao setor de audiovisual enviar um whatsapp caso ocorra uma 
 alteração em alguma reserva. 
 RF08: O sistema deverá permitir ao setor de audiovisual enviar um e-mail e/ou whatsapp 
 caso tenha alteração em algum equipamento. 
 RF09: O sistema deverá permitir ao mantenedor alterar a situação dos equipamentos para 
 "ATIVO", "EM MANUTENÇÃO" e “INATIVO” 
 RF10: O sistema deverá permitir ao usuário efetuar o login no sistema. 
 RF11: O sistema deverá permitir ao setor de audiovisual emitir um relatório dos 
 equipamentos. 
 Fonte: Próprios autores 
 12 
 3.1.3. REQUISITOS NÃO FUNCIONAIS 
 Os requisitos não funcionais não estão relacionados aos serviços ou necessidades que 
 o sistema deve atender, mas sim a propriedades específicas de funcionamento, como 
 disponibilidade, tempo de resposta, desempenho, segurança e confiabilidade, entre outras 
 características. Estes requisitos são, na sua maioria, mais importantes e críticos que os 
 requisitos funcionais que, em determinadas situações, permitem aos usuários encontrar 
 maneiras de contornar uma função do sistema que não atenda suas necessidades 
 (SOMMERVILLE, 2011). Ávila e Spínola (2008, p 48) classificam os requisitos não 
 funcionais como “condições que o software deve atender ou qualidades específicas que o 
 software deve ter”. 
 Deste modo, foram levantados os requisitos não funcionais para o primeiro ciclo doprojeto Colégio Vencer Sempre: 
 Tabela 02 - Requisitos não funcionais do sistema 
 RNF01: O sistema deverá ser executado no sistema operacional Windows (10 e 11). 
 RNF02: Necessita de uma conexão estável com a internet. 
 RNF03: O sistema será desenvolvido em Linguagem PHP 
 RNF04: O sistema deverá contar com um banco de dados para armazenamento de 
 informações de produtos. 
 RNF05: O sistema deverá possuir interface gráfica com ícones representativos que auxiliem 
 no processo de integração do usuário com o sistema, a fim de torná- la mais intuitiva. 
 RNF06: O sistema deverá apresentar capacidade de adaptação de interface em diferentes 
 dispositivos (desktops, dispositivos móveis, notebooks), quando escalado para tal; 
 RNF07: Deve ser feito um backup dos dados do sistema a cada 12 horas; 
 RNF08: O processamento de informações do sistema deve ser rápido; 
 Fonte: Próprios autores 
 3.2. REGRA DE NEGÓCIO 
 A regras de negócio refere-se às diretrizes que definem ou restringem ações, 
 mostrando como as operações devem ser conduzidas e se há algum limite nessa aplicação. 
 Essas regras são importantes para que a organização tenha uma visão clara do que deve ser 
 feito, como e por qual razão. Uma regra de negócio definirá a forma que o sistema fará este 
 atendimento de necessidades definidas. “São regras que servem para definir ou restringir 
 13 
 alguma ação nos processos de sua empresa. São declarações que irão descrever como 
 determinadas operações devem ser realizadas e se há algum limite que precisa ser aplicado.” 
 (OLIVEIRA, 2018). 
 Deste modo, foram levantados as regras de negócios para o primeiro ciclo do projeto 
 Colégio Vencer Sempre: 
 Tabela 03 - Regras de negócio do sistema 
 RN01: Somente colaboradores do setor de controle de equipamentos deve levá los até o local 
 e instalá-los; 
 RN02: Após o término do uso, um colaborador do setor de controle de equipamentos deve se 
 encarregar de retorná-los; 
 RN03: Apenas os colaboradores terão acesso a área de depósito dos equipamentos; 
 RN04: As reservas devem ser feitas com no mínimo 15 dias de antecedência; 
 RN05: Em casa de reserva emergencial pela alta gestão as reservas podem ser canceladas; 
 Fonte: Próprios autores 
 4. NORMAS DE QUALIDADE: 
 No Brasil, onde aproximadamente 73% da indústria de software é constituída por 
 PMEs, poucas organizações têm adotado modelos de referência (MINISTÉRIO DE CIÊNCIA 
 E TECNOLOGIA 2008). Constatou-se que normalmente as organizações só implementam as 
 boas práticas da engenharia de software quando estas são exigidas em avaliações de processos 
 (NOGUEIRA, M.O. 2006). 
 Neste conjunto foi criada uma iniciativa para melhorar a capacidade de 
 desenvolvimento de software nas organizações brasileiras, o programa MPS.BR1 (Melhoria 
 de Processo do Software Brasileiro). Esta iniciativa teve início em 2003 sob a coordenação da 
 Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), com apoio do 
 governo (MCT e FINEP), SEBRAE/PROIMPE e BID (Banco Interamericano de 
 Desenvolvimento), da indústria de software brasileira e de instituições de pesquisa. O 
 principal objetivo desta iniciativa é desenvolver e disseminar um modelo de melhoria de 
 processos brasileiro (o modelo de referência MPS2) visando estabelecer um caminho 
 economicamente viável para que organizações, incluindo as PMEs, alcancem os benefícios da 
 melhoria de processos e da utilização de boas práticas da engenharia de software em um 
 intervalo de tempo razoável. O modelo foi desenvolvido levando em consideração normas 
 14 
 internacionais, modelos internacionalmente reconhecidos, boas práticas da engenharia de 
 software e as necessidades de negócio da indústria de software brasileira. 
 O MR-MPS busca atender à necessidade de implantar os princípios de engenharia de 
 software de forma adequada às necessidades de negócio das organizações brasileiras e define 
 sete níveis de maturidade de processos para organizações que produzem software: A (Em 
 Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E 
 (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). Cada um dos níveis 
 de maturidade (do nível G - primeiro estágio de maturidade ao nível A - mais maduro) 
 apresenta cumulativamente um conjunto de processos e atributos de processos que indicam 
 onde a unidade organizacional tem que investir esforço para melhoria, de forma a atender aos 
 seus objetivos de negócio e ao MR-MPS. Assim, os níveis de maturidade são definidos em 
 duas dimensões: a dimensão de capacidade de processos e a dimensão de processos. A 
 dimensão de capacidade de processos do MR-MPS é constituída de um framework de 
 medição. A capacidade de processos é definida em uma escala ordinal que representa 
 capacidade crescente do processo. Esta escala vai desde não atingir o propósito básico do 
 processo até atingir precisamente os objetivos de negócio atuais para o processo. Dentro do 
 framework a medida da capacidade é baseada em um conjunto de nove atributos de processo 
 (AP), em total conformidade com a ISO/IEC 15504-2: AP 1.1 (o processo é executado), AP 
 2.1 (o processo é gerenciado), AP 2.2 (os produtos de trabalho do processo são gerenciados), 
 AP 3.1 (o processo é definido), AP 3.2 (o processo está implementado), AP 4.1 (o processo é 
 medido), AP 4.2 (o processo é controlado), AP 5.1 (o processo é objeto de inovações), AP 5.2 
 (o processo é otimizado continuamente). Cada AP contém um conjunto de resultados de 
 atributo de processo (RAP) utilizados para avaliar a implementação de um AP. 
 Conclui-se tecnicamente que para melhorar a capacidade de desenvolvimento de 
 software da equipe de desenvolvimento do projeto, o MR-MPS mostrou-se depois da 
 avaliação e melhoria de processos, a ISO/IEC iniciou ainda um esforço para desenvolver um 
 modelo de referência de processos para o domínio de engenharia de software. A norma base 
 para esta iniciativa foi a ISO/IEC 12207 [7]. Esta norma provê um conjunto de processos, 
 atividades e tarefas para ciclos de vida de produtos e serviços de software. 
 15 
 5. MERCADO E ECONOMIA 
 No cenário contemporâneo da economia que se diferencia pela clara competitividade 
 entre as empresas, com a globalização e junto com a queda de barreiras comerciais 
 acarretadas pelo surgimento da internet tem como resultado uma disputa ardorosa entre as 
 empresas. O uso adequado de sistemas que administram dados de maneira rápida e objetiva, 
 com o intuito de compreender os acontecimentos em tempo real é indispensável, permitindo 
 melhor controle e agilidade, tornando a tomada de decisões seguras e assertivas. Segundo 
 (VASCONCELLOS, 2004, p. 2). “Economia é a ciência social que estuda como os indivíduos 
 e a sociedade decidem (escolhem) empregar recursos produtivos escassos na produção de 
 bens e serviços, de modo a distribuí-los entre as várias pessoas e grupos da sociedade, a fim 
 de satisfazer as necessidades humanas”. Um ponto distinto que merece ênfase é a ideia de 
 prática e riqueza através do atributo e do acúmulo de bens e recursos, sendo apenasatravés do 
 consumo que as pessoas se sentem vivas e existem (BAUDRILLARD, 2003). A sofisticação 
 das estratégias comerciais explora justamente esses valores, a fim de ampliar a lucratividade, 
 e, por isso, existe a compreensão da importância de se assumir uma nova ética para refazer as 
 bases das trocas e sua relação com o ecossistema. 
 A estabilidade da humanidade depende agora de uma construção recente de 
 funcionamento dos comércios que se destacou e subsidiou as demais dimensões do humano 
 ao econômico. Por isso, estamos de acordo com KARL POLANYI (2001), quando assegura 
 que o esforço por espaçar o trabalho das outras dimensões da vida e sujeitá-lo às leis do 
 mercado supriu a socialização pela atomização, como modelos de organização social. 
 A economia e o comércio precisam ser aceitos como integrantes da sociedade, e esta 
 deve ser entendida como parte do meio ambiente. Para ser coeso com isso, o comércio deve 
 estar a serviço do acesso aos bens e serviços, a serviço da vida, como as diferentes culturas 
 fizeram e fazem nas diferentes experiências históricas (BELSHAW, 1968; 
 GEORGESCU-ROEGEN, 2003). 
 5.1. ESTUDO DE VIABILIDADE ECONÔMICA 
 Os desenhos econômicos são fundamentais pela necessidade de colocar recursos que 
 muitas vezes são escassos de maneira que acolha às necessidades do jeito mais diligente 
 possível. Assim sendo, não poderia ser distante no ramo do desenvolvimento de soluções 
 tecnológicas. A competência de criação e inovação é, ao final das contas, a aptidão essencial 
 das companhias que sobrevivem e prosperam no mercado capital. Quando se fala em 
 16 
 software, novidades podem surgir por todos os lados, de projetos, novos modelos, de grandes 
 empresas, de pequenas empresas e de madrugadas inspiradas de um desenvolvedor com uma 
 boa ideia. 
 Para fazer uma análise da viabilidade econômica de um projeto tecnológico envolve 
 o estudo de fases que abordam o conhecimento sobre o cliente, nesse caso o colégio Vencer 
 Sempre, que vai atuar e a previsão de faturamento da empresa. No domínio dessas 
 informações é admissível efetuar o cálculo dos indicadores que medirão viabilidade 
 econômica do projeto. Segundo (SOUZA E CLEMENTE 2009), para realizar a análise da 
 viabilidade econômica financeira de um projeto de software pode ser utilizada a Metodologia 
 Multi-Índice (MM), a qual por meio de vários indicadores auxilia no processo decisório 
 quanto a aceitação ou rejeição do projeto. Os indicadores são classificados em relação ao 
 retorno, aos riscos e para melhor a percepção, podem ser analisados por meio de sensibilidade 
 (LIMA e al.,2015). 
 O cliente desse projeto, é o Colégio Vencer Sempre, uma empresa com visão de 
 futuro, que requisitou um projeto de desenvolvimento de software para que, levando em conta 
 que o atual contexto do colégio que utiliza um sistema de agendamento arcaico, analógico e 
 impróprio, para desenvolver um sistema digital, online de reservas para o uso de seus 
 equipamentos de informática e audiovisuais pelos professores e coordenadores da escola, 
 vendo que a troca de tempo por custo é favorável. A assistência da disciplina de Economia e 
 Mercado, evidenciaremos como funciona um bom estudo de viabilidade econômica, que 
 consiste em avaliar se determinado projeto é realizável ou não. Seu objetivo é prever ou 
 antecipar os cenários otimistas e pessimistas de um plano. 
 Tabela 04 - Levantamento de Custos para desenvolvimento do sistema 
 Despesa Quantidade Valor individual Valor final 
 Imposto PJ 1 R$10.000,00 R$10.000,00 
 Salário desenvolvedor 4 R$6.000,00 R$24.000,00 
 Salário Analista 2 R$5.000,00 R$10.000,00 
 Infraestrutura em nuvem 1 R$2.000,00 R$2.000,00 
 Custos Gerenciais (água, luz, 
 internet) 
 1 R$1.000,00 R$1.000,00 
 Gastos com o projeto R$47.000,00 
 Lucratividade do projeto 25% 
 Preço final R$58.750,00 
 Fonte: Próprios autores 
 17 
 Para SOUZA E CLEMENTE (2009), o valor presente líquido é a concentração de 
 todos os valores esperados de um fluxo de caixa na data zero. O autor afirma ainda que o 
 VPL, com certeza, é a técnica robusta de análise de investimento mais conhecida e mais 
 utilizada. Com base nas informações elencadas acima. Portanto, o VPL é definido como o 
 valor presente dos fluxos de caixa deduzidos o valor inicial do investimento, isto é: 
 VPL = VP (Fluxos) – Investimento. 
 A análise da viabilidade de um projeto de investimento revela que os métodos 
 econômico-financeiros de avaliação de projetos auxiliam os gestores no processo de tomada 
 de decisões. Muitas vezes um investimento é necessário, mas, do ponto de vista de custos, 
 pode ser menos viável. O projeto se mostra de maneira econômica viável, sendo que deve ser 
 executado no prazo de 120 dias. A empresa terá um lucro de 25% em cima dos gastos. Para 
 execução do projeto, será necessária a utilização de mão de obra especializada de um analista 
 de sistemas para fazer o levantamento dos requisitos, planejamento e documentação e, um 
 desenvolvedor que codificará a ferramenta, sendo que ambos em conjunto farão a validação 
 de requisitos ao final do processo para entregar o produto. 
 6. INTERFACE COM O USUÁRIO 
 Experiência do Usuário, como a expressão sugere, envolve o estudo das sensações e 
 emoções que os usuários vivenciam ao utilizar um produto de tecnologia . O projeto de um 
 novo software permeia diversas incumbências, o projeto de interface com o usuário em 
 grandes organizações é contratado projetistas especializados em interface para seu software de 
 aplicação. No entanto, vamos assumir a responsabilidade pelo projeto de interface com o 
 usuário, que será projetar um Sistema de Reserva de Equipamentos Audiovisuais, que tem 
 como objetivo montar uma interface intuitiva e de fácil acesso. Experiência do Usuário de alta 
 qualidade se tornou um fator competitivo central do desenvolvimento de produto/serviço de 
 mercados consumidores maduros (OBRIST, ROTO, VÄÄNÄNEN-VAINIO-MATTILA, 
 2009). Acredita-se que com o uso do Design de Serviços e UX de forma conjunta pode 
 entregar resultados com maiores chances da entrega do valor desejado pelos clientes criando 
 um relacionamento e a fidelização dos clientes levando a uma maior participação no 
 mercado e a valorização da marca. 
 A disciplina de UX é uma parte fundamental de todo o processo para se fazer um bom 
 projeto de software. Para que a aplicação alcance o seu melhor potencial, é necessário que sua 
 18 
 interface com o usuário seja projetada para convencionar as habilidades, experiências e 
 expectativas dos clientes e/ou usuários do produto. Uma interface de UX projetada de forma 
 inadequada, indica que os clientes terão dificuldades de entender o sistema e irão desistir de 
 acessar e tentarão outro meio mais fácil de utilizar o projeto. 
 Um fato significativo é que a imagem mental, onde cada usuário pode ter uma 
 compreensão do software diferente de outros usuários, pode tender com o modelo de projeto 
 de engenharia de software, que pode ser muito diferente da imagem mental. Dessaforma, é 
 importante entender os usuários em si, bem como o modo pelo qual vão usar o sistema 
 (PRESSMAN,2006). 
 6.1. PROTÓTIPOS 
 Durante o processo de avaliação da Experiência do Usuário, os usuários são 
 convocados a avaliar os protótipos. Os métodos de avaliação citados são questionários, 
 observações do uso e entrevistas. ROTO (2014) classifica diversos métodos de avaliação da 
 Experiência do Usuário tanto como métodos de avaliação para produtos prontos quanto para 
 produtos em desenvolvimento (protótipos), Dessa forma, é possível apreciar mudanças na 
 experiência que o usuário tem ao utilizar os protótipos de um produto, com o objetivo de 
 obter um produto final usável e que proporcione uma boa experiência. Esse processo de fazer 
 os protótipos ajuda na avaliação da experiência do usuário que pode servir para os clientes 
 colocarem em prática, discutidos para melhor avaliar os protótipos do sistema a ser 
 construído, e para os desenvolvedores testar as suas próprias aplicações e, também, pode 
 prestar o serviço de avaliação da experiência do usuário melhor para o cliente. 
 6.2. PROTÓTIPOS DAS TELAS 
 A visualização das telas ou protótipos de telas nada mais é do que um modelo 
 funcional com base nos requisitos citados anteriormente onde será simulado como serão as 
 telas do sistema de reserva de equipamentos. Esse é o formato mais rápido e eficiente de se 
 validar e até mesmo definir os requisitos do produto. A interface com o usuário é a “porta de 
 entrada do software”, assim vários fatores são levados em conta para a elaboração de uma 
 interface, como perfil do usuário, tecnologia e software disponíveis (PRESSMAN, 2001). 
 Para construção dos protótipos de tela utilizamos a ferramenta Figma 
 (https://www.figma.com) por ter uma interface de alta fidelidade e ter uma arquitetura aberta e 
 19 
 de fácil compreensão pois ela completa com as melhores ferramentas reconhecidas no 
 mercado para esta finalidade. 
 Logo abaixo será apresentado um esboço de cada tela do sistema onde o usuário 
 poderá ter acesso a reserva ou empréstimo dos equipamentos. 
 6.2.1. TELA LOGIN 
 A tela de login permite ao usuário fazer a entrada para o sistema é a mesma para os 
 dois tipos de usuários, ela é composta por dois campos de preenchimento, sendo mostrado na 
 Figura 02, sendo os campos de Login e Senha. A tela na qual o sistema tem o seu primeiro 
 contato com a classe cliente. 
 Esses campos fazem a validação do cliente, que após esse processo entrega a interface 
 que esse cliente tem à disposição, tendo o atributo administrador válido ou invalido. 
 A partir dessa validação, o usuário acessa a interface correspondente. 
 Figura 02 – Tela de acesso ao sistema que solicita um usuário e senha 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 20 
 6.2.2. TELA ADMINISTRADOR - HOME 
 A tela home do administrador vai atender o usuário que tem o atributo de 
 administrador do sistema, a Figura 03 mostra o que esse tipo de usuário tem acesso. Os botões 
 centralizados à esquerda, têm as funções de levar o usuário a tela de busca e a tela de cadastro 
 de novo usuário, no botão equipamento, temos o envio para uma tela igual à do usuário, 
 porém voltada para equipamento e no último botão, fica responsável pelo relatório de reservas 
 realizadas pelos clientes comuns. O usuário responsável por administrar essas funções não 
 pode reservar equipamentos, apenas cadastrar e atualizar o sistema. 
 Figura 03 – Tela inicial do usuário administrador 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.3. TELA ADMINISTRADOR - USUÁRIO 
 Na Figura 04 a tela representa a busca dos usuários cadastrados, por meio de seu id, 
 nome e/ou e-mail, conferindo o resultado na tela que será abordada na Figura 05, ou mesmo o 
 21 
 cadastro de um novo usuário. As telas de navegação possuem um botão de retorno a tela 
 home, posicionado no mesmo local em todas as telas, do mesmo modo podendo ser criado 
 uma memória do usuário, que ligeiramente pode iniciar todo o seu processo caso entre em 
 uma tela que o usuário não desejava. 
 Figura 04 – Tela do usuário administrador que buscar os usuários cadastrados 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.4. TELA ADMINISTRADOR - RESULTADO DA BUSCA 
 A tela que é devolvida da procura pelo usuário, simulada na Figura 5, temos o retorno 
 das as informações cadastradas, podendo ser alteradas para sua atualização, o reenvio da 
 senha do usuário e deletar o usuário caso necessário. Uma advertência sobre as senhas, essa 
 parte fica sobre a responsabilidade do administrador o reenvio, por questões de segurança, 
 como todo o sistema tem a ideia de ser algo local e de funcionalidade exclusiva do 
 22 
 administrador será responsável por esse envio, a senha poder ser gerada pelo sistema e o 
 administrador não terá a acesso ao conteúdo, pois será criptografada a nova senha. O usuário 
 poderá alterar a senha que receber ao entrar no seu perfil. 
 Figura 05 – Tela do usuário administrador com resultado da busca aos usuários 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.5. TELA ADMINISTRADOR - CADASTRAR NOVO USUÁRIO 
 Na Figura 06 contínua o padrão das telas de busca, porém com o diferencial que 
 somente é possível cadastrar um novo usuário, com os atributos que temos à disposição, 
 podemos visualizar e classificar essa classe e a classe que fica por registrar essas informações. 
 23 
 Figura 07 – Tela do usuário administrador para cadastrar novo usuário 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.6. TELA ADMINISTRADOR - EQUIPAMENTO 
 O segundo botão da tela home direciona o administrador a tela da Figura 07, que 
 permite selecionar um equipamento já cadastrado e o cadastro de um novo equipamento. 
 24 
 Figura 07 – Tela do usuário administrador selecionar um equipamento já 
 cadastrado e o cadastro de um novo 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.7. TELA ADMINISTRADOR - EQUIPAMENTO SELECIONADO 
 Posteriormente a seleção de um equipamento na tela antecedente, o usuário tem 
 contado com a tela da Figura 08, que permite a alteração das informações do equipamento 
 seguido de atualização e a remoção da lista de equipamentos. No atributo estado o 
 administrador pode sem a obrigação de deletar o mesmo ou deixar em manutenção. 
 25 
 Figura 08 – Tela do usuário administrador para alteração das informações e/ou 
 exclusão de um equipamento 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.8. TELA ADMINISTRADOR - CADASTRAR EQUIPAMENTO 
 A figura 09, traz uma tela similar à de seleção do equipamento, contudo voltada para o 
 cadastro total. A propriedade de estado é um atributo que fica como ativo em sua criação, por 
 não existir necessidade de escolher essa opção na criação, bem como logo que é necessário 
 adicionar um novo equipamento é lógico que ele está em estado de funcionamento pleno. 
 26 
 Figura 09 – Tela do usuário administrador para cadastrar equipamento 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.9. TELA ADMINISTRADOR - RELATÓRIO 
 Na figura 10, apresenta a tela de relatório acionada na tela home peloterceiro botão 
 que. Nessa tela o administrador pode visualizar todos os equipamentos reservados com data e 
 hora de utilização. Nessa mesma tela tem a opção de acesso ao histórico, onde o usuário 
 administrador pode escolher um período para visualizar reservas acontecidas no dia vigente. 
 O histórico é disponibilizado por meio de um arquivo no formato “pdf” com o período 
 selecionado. 
 27 
 Figura 10 – Tela do usuário administrador para emissão de relatórios de reserva 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.10. TELA USUARIO - HOME 
 Na Figura 11, na tela home voltada o usuário não administrador disponibiliza somente 
 a ação de reserva e pedidos realizados e um calendário do dia vigente. Abordaremos a classe 
 que será utilizada para pesquisa e filtragem mais à frente. 
 28 
 Figura 11 – Tela do usuário para acessar a solicitação de reserva e pedidos 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.11. TELA USUÁRIO - RESERVA DE EQUIPAMENTO 
 Na figura 12, temos o principal objetivo do sistema, a tela de reserva, onde o usuário 
 pode escolher o equipamento por meio da seleção. 
 29 
 Figura 12 – Tela do usuário para escolha do equipamento a ser reservado 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.2.12. TELA USUÁRIO - CONFIRMAÇÃO DE RESERVA DE 
 EQUIPAMENTO 
 Em seguida selecionar a tela do sistema e atualizar para a figura 13, que apresenta o 
 equipamento selecionado e os dias que ele está reservado, podendo, portanto, selecionar o dia 
 e horário caso esteja disponível. 
 30 
 Figura 13 – Tela do usuário para confirmar os dados da reserva 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 6.3. DIAGRAMAS 
 Nos processos da engenharia de software uma das etapas basilares é a análise de 
 requisitos, onde o projetista vai até o cliente e faz o levantamento das necessidades deste para 
 então iniciar o projeto de um software. o projetista faz uma documentação técnica dos dados 
 coletados empregando uma série de representações esquemáticas (Diagramas), que amparam 
 na compreensão das relações entre as informações, norteando os programadores durante o 
 desenvolvimento do software. Estes diagramas são elaborados quase sempre a partir de uma 
 linguagem conhecida como UML (Unified Modeling Language), que não é uma linguagem de 
 programação, mas sim um conjunto de diagramas compostos por uma série de símbolos 
 gráficos com significados bem específicos. Faz-se também na fundamentação, a relação dos 
 31 
 diagramas da UML com a perspectiva do Design a partir da visão de Twyman (1979), Horn 
 (1998), das variáveis visuais de Bertin (1983), entre outros. 
 6.3.1. DIAGRAMAS DE CLASSES 
 No desenvolvimento a partir da descrição de uma série de conceitos e abordagens 
 como: a cor quanto informação, diagramas e sua relação com a linguagem gráfica, o que é 
 UML, o que é o Diagrama de Classes, práticas profissionais e sua aplicação conforme o 
 modelo proposto por Coad, Lefebvre e De Luca (1999). O diagrama de classes é considerado 
 por muitos autores o diagrama mais utilizado da UML. Segundo Versolato (2015), em seu 
 livro Análise Orientada a Objetos, o diagrama de classes tem como objetivo modelar a visão 
 estática do sistema, mostrando um conjunto de classes, interfaces, colaborações e os seus 
 relacionamentos. O propósito é facilitar a divisão das classes do sistema, bem como 
 demonstrar como as classes do sistema interagem entre si. 
 Para o contexto inicial do sistema temos a classe usuário, que é usada tanto para o 
 usuário comum o que somente solicita a reserva como para o administrado, tendo como 
 atributos relacionados a cada campo da tela, não ficando visível apenas a senha no cadastro. 
 Logo abaixo será apresentado um esboço do diagrama de classes do projeto 
 representando as principais classes do sistema. 
 Figura 14 – Diagrama de classes do projeto 
 Fonte – Elaborado no Aplicativo Figma - Próprios autores 
 32 
 7. PROGRAMAÇÃO ORIENTADA A OBJETOS 
 Em tempos contemporâneos, a Programação Orientada a Objetos (POO) mostrou-se o 
 paradigma de programação mais dominante. A maioria dos cursos da área de computação 
 incluem a POO como parte do seu currículo [Beck and Cunningham 1989]. Contudo, ensinar 
 este importante paradigma ainda é difícil, principalmente quando ele é incluído após a 
 programação procedural e o aluno precisar “abandonar” o controle que ele conhece com o 
 paradigma procedural e confiar no conhecimento da POO [COOPER et al. 2003]. A POO têm 
 diferentes vertentes e a que se explora neste projeto é a programação orientada a objetos que 
 sugere representar de forma fácil e abrangente a relação entre os elementos de uma classe com 
 o mundo real, para contextualizar partes do processo da construção do projeto, 4 propriedades 
 do POO serão esclarecidas tecnicamente. 
 7.1. CLASSES 
 Uma das partes fundamentais da abrangência da POO Com a classe definida, que é a 
 base para que se possa ser criar os objetos, que de forma técnica recebe o nome de instanciar. 
 Uma classe é um projeto de um objeto. Ela informa como criar um objeto de um tipo 
 específico. (SIERRA & BATES, 2007). 
 7.2. OBJETOS 
 Trory, Howland e Good (2018) demonstram que o uso de objetos concretos, que 
 podem ser palpáveis e interativos, auxiliam no exercício de abstração de conceitos 
 matemáticos e computacionais. O objeto pode ser definido com uma instância da classe, a 
 classe seria a a forma e o objeto o bolo, o que através de apenas uma forma a classe, se pode 
 criar diversos bolos os objetos para o exemplo em questão. Com a mesma classe se pode criar 
 diversos objetos com atributos e diferentes. 
 7.3. HERANÇA 
 A herança proporciona o reuso de software, quer dizer: novas classes são criadas a 
 partir de outras já existentes, absorvendo atributos e comportamentos e adicionando os seus 
 próprios. A herança é um dos comportamentos fundamentais da POO. Herança admite que se 
 defina uma classe filha que reutiliza (herdando), estende ou modifica o comportamento de 
 uma classe pai. Essa classe específica que outras classes herdam, recebe o nome de classe 
 base ou superclasse, e simultaneamente os que herdam desta classe são chamados de 
 derivadas ou especialistas. Uma essa classe derivada herda atributos e métodos da classe pai, 
 33 
 a fim de se criar novas classes com comportamentos e dados diferente, mas que não precisa 
 ser criada do zero. 
 7.4. POLIMORFISMO 
 Na literalidade, o polimorfismo constitui “muitas formas”, ou seja, é a competência de 
 a mesma coisa oferecer diferentes formas. Em POO o polimorfismo é a capacidade do mesmo 
 nome de uma ação poder ser interpretado de formas diversas, por diferentes objetos 
 provocando diferentes invocações de funções de diferentes classes. É os objetos receptor da 
 Mensagem, com a sua relação de pertença à Classe, que associa o Método que deve ser 
 invocado. É a forma que um método se comporta com o objeto passando como parâmetro. 
 Esta capacidade só é possível pela estrutura das Classes, pela relação de pertença dos objetos 
 às suasClasses e pela diferença entre Mensagem e Método. Em resumo, se um método recebe 
 um objeto que requer uma classe como herança, esse método recebe um objeto novo, logo a 
 classe que foi passada para essa nova classe não vai poder ser recebida nesse método. Alguns 
 tipos de polimorfismo, sobrecarga e sobrescrita, onde sobrecarga seriam métodos que ganham 
 versões do mesmo método e sobrescrita é qual se herda um método que, porém, é sobrescrito, 
 porque suas ações causaram um resultado diferente do esperado para o novo objeto. 
 8. ROTEIRO DE TESTES 
 Os testes são realizados com a intenção de descobrir erros e defeitos em um sistema. 
 [Myres, 2004]. O Método de Testes de Software concebe uma estruturação de fases, 
 atividades, artefatos, papéis e responsabilidades que tem o alvo de padronizar as tarefas, além 
 de maximizar a organização e monitoramento dos projetos de testes. Deste modo, o objetivo 
 do processo de teste é abastecer informação para avaliar a qualidade do produto, decisões e 
 processos para uma atividade de teste. Além do mais, o processo de teste busca afiançar que 
 nenhum passo crítico do processo seja perdido, ou seja, que todas as atividades sejam 
 alcançadas na ordem correta. Philippe Kruchten, em seu livro “The rational unified process: 
 Na introdução (BOSTON: ADDISON-WESLEY, 1999) ”, propõe que existem pelo menos 
 três dimensões de qualidade que precisam ser consideradas antes de se iniciar qualquer ciclo 
 de teste: Confiança, Funcionalidade e Performance. Os testes geralmente são baseados em 
 roteiros de teste criados a partir da especificação. Os Roteiros de Testes são compostos por 
 um conjunto de casos de teste definidos para uma determinada especificação. 
 Logo abaixo será apresentado os roteiros de teste do sistema representando os testes 
 nas principais funcionalidades do sistema. 
 34 
 A Tabela 05 apresenta o caso de teste para a funcionalidade de acesso ao sistema, 
 comum a todo tipo de usuário. 
 Tabela 05 – Acesso ao sistema 
 Tipo Descrição 
 Identificação Permitido aos dois tipos de usuários 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Permite a entrada de dois tipos diferentes de 
 usuários no sistema 
 Ator primário Cliente e Administrador 
 Interessados Administradores e usuários comuns 
 Pré-condições O usuário deve possuir um login e senha cadastrados 
 anteriormente 
 Resultado esperado 
 Após fazer o login, o usuário deves ser 
 redirecionado à página inicial de acordo com o seu 
 tipo de usuário 
 Fluxo Principal: 
 1. Usuário abre o software. 
 2. É apresentada a tela de login e senha. 
 3. O usuário preenche os campos com as informações pedidas. 
 4. O sistema redireciona o usuário, conforme sua credencial. 
 Fluxo Exceção: 
 1. Caso o usuário não possua login cadastrado, deverá solicitar o cadastro ao administrador. 
 2. Recebe por e-mail o login e senha 
 3. Realiza o procedimento do fluxo normal. 
 Fonte: Próprios autores 
 A Tabela 06 apresenta o caso de teste para a funcionalidade de apresentação da tela 
 primária do sistema, disponível ao cliente administrador. 
 Tabela 06 - Home administrador 
 Tipo Descrição 
 Identificação home 
 Objeto de Teste Sistema administrador 
 Caso de Teste O usuário consegue acessar o sistema para diferentes 
 propósitos. 
 Ator primário Administrador 
 Interessados Administradores 
 Pré-condições O usuário deve ter realizado o login 
 Resultado esperado 
 O usuário tem acesso a três opções de 
 direcionamento 
 de sistema. 
 Fluxo Principal: 
 1. O usuário tem acesso a três opções no sistema. 
 2. Pode efetuar a consulta de usuários do sistema, consulta de equipamentos 
 e relatório de equipamentos. 
 Fluxo Exceção: 
 35 
 1. O usuário não consegue acessar a opção desejada. 
 2. Ocorre o redirecionamento para a página inicial do sistema. 
 Fonte: Próprios autores. 
 A Tabela 07 apresenta o caso de teste para a funcionalidade da tela de pesquisa e 
 cadastro de usuário. 
 Tabela 07 - Pesquisa e cadastro de usuários 
 Tipo Descrição 
 Identificação Pesquisa e cadastro de usuários 
 Objeto de Teste Sistema Reservas 
 Caso de Teste O usuário consegue cadastrar manualmente novos 
 usuários e realizar buscas de cadastro 
 Ator primário Cliente 
 Interessados Administradores 
 Pré-condições O usuário deve ter realizado o login e acessar a 
 página de 
 Resultado esperado Ocorre o redirecionamento para a página de 
 pesquisa e cadastro de usuários. 
 Fluxo Principal: 
 1. O usuário acessa a página de usuário. 
 2. Tem-se acesso à pesquisa de usuários cadastrados através de seu id,nome ou e-mail. 
 3. Acesso à ferramenta de cadastro de novos usuários. 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a opção desejada. 
 2. Ocorre o redirecionamento para a página inicial do sistema. 
 3. O usuário não digita as informações para consulta corretamente. 
 Fonte: Próprios autores. 
 A Tabela 08 apresenta o caso de teste para a funcionalidade da tela de busca dos 
 usuários cadastrados. 
 Tabela 08 - Busca de usuário 
 Tipo Descrição 
 Identificação Busca de usuário 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Acesso ao resultado da busca de usuário 
 Ator primário Cliente 
 Interessados Administradores 
 Pré-condições 
 O usuário deve ter realizado login, acessando a 
 página de usuários e preenchido o espaço de texto de 
 pesquisa de usuários. 
 Resultado esperado Uma tela onde se tem todas as informações do 
 usuário solicitado é apresentada. 
 Fluxo Principal: 
 1. O usuário digita o ID, nome ou e-mail do usuário que deseja obter informações cadastrais. 
 2. O sistema exibe a tela onde estão todos os dados de cadastro do usuário solicitado. 
 36 
 Fluxo Exceção: 
 1. O usuário não consegue acessar as informações de cadastro de outros usuários. 
 2. Ocorre o redirecionamento para a página inicial do sistema. 
 Fonte: Próprios autores. 
 A Tabela 09 apresenta o caso de teste para a funcionalidade da tela de busca do 
 usuário. 
 Tabela 09 - Busca de usuários 
 Tipo Descrição 
 Identificação Cadastro de usuário 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Tela para a realização de cadastro de novos usuários 
 a partir do sistema do administrador. 
 Ator primário Cliente 
 Interessados Administradores 
 Pré-condições 
 O usuário deve ter realizado login, acessando a 
 página de usuários e preenchido o espaço de texto de 
 pesquisa de usuários. 
 Resultado esperado Acesso à página para cadastro de novos usuários do 
 sistema 
 Fluxo Principal: 
 1. Na página inicial o usuário seleciona a opção “Usuário”. 
 2. Na tela de Usuário, é selecionada a opção “Cadastrar novo usuário”. 
 3. Ocorre o redirecionamento para a página de cadastro de usuário, onde deve-se fornecer as informações 
 pedidas pelo sistema. 
 4. Selecionar se o usuário cadastrado é administrador ou usuário comum. 
 5. Realizar o cadastro. 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a página de cadastro de novos usuários. 
 1.1 O corre o redirecionamento para a página inicial do sistema. 
 2. O usuário não fornece todas as informações necessárias para realização do cadastro. 
 2.1 O sistema exibe a mensagem de erro ao cadastrar novo usuário. 
 3. Os dados fornecidos não são suficientes ou não estão no formato exigido pelo sistema. 
 3.1 O sistema exibe a mensagem de erro ao cadastrar novo usuário e identifica em qual local os dados 
 fornecidos não estão em conformidade. 
 Fonte: Próprios autores. 
 A Tabela 10 apresenta o caso de teste para a funcionalidade da tela de consulta de 
 equipamento. 
 Tabela 10 - Consulta de equipamentos 
 Tipo Descrição 
 Identificação Consulta deequipamentos 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Acesso às informações de estoque de equipamentos 
 Ator primário Cliente 
 37 
 Interessados Administradores 
 Pré-condições 
 O usuário deve ter realizado login, acessando a 
 página de equipamentos e selecionado o 
 equipamento desejado. 
 Resultado esperado Redirecionado para a tela de equipamento 
 selecionado 
 Fluxo Principal: 
 1. Usuário acessa a página de equipamentos. 
 2. O equipamento desejado é selecionado. 
 3. O sistema exibe as informações do equipamento: nome, estado, descrição. 
 4. Usuário consegue modificar informações do equipamento (apenas administradores). 
 5. Usuário consegue deletar o equipamento (apenas administradores). 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a página consulta de equipamentos. 
 1.1 Ocorre o redirecionamento para a página inicial do sistema. 
 2. O usuário seleciona corretamente o equipamento desejado, porém o sistema não traz a informação. 
 2.1 Selecionador retorna ao ponto inicial, permitindo ao usuário consultar novamente. 
 Fonte: Próprios autores. 
 A Tabela 11 apresenta o caso de teste para a funcionalidade da tela de cadastro de 
 equipamentos. 
 Tabela 11 - Cadastro de equipamentos 
 Tipo Descrição 
 Identificação Cadastro de equipamentos 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Cadastro de novos equipamentos no sistema. 
 Ator primário Cliente 
 Interessados Usuários 
 Pré-condições 
 O usuário deve ter realizado login como 
 administrador, acessado a página de equipamentos e 
 selecionando a opção de cadastrar novo 
 equipamento. 
 Resultado esperado Acesso à tela de cadastro de equipamentos. 
 Fluxo Principal: 
 1. Usuário acessa a página de equipamentos. 
 2. Seleciona a opção de cadastrar novo equipamento. 
 3. O usuário é redirecionado para a tela de cadastro de equipamentos. 
 4. Deve-se preencher corretamente os campos com o nome do novo equipamento a ser cadastrado e sua 
 descrição. 
 5. Adicionar foto do equipamento caso seja necessário. 
 6. Selecionar a opção “Cadastrar”. 
 7. Redirecionado para a página de equipamentos. 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a página de cadastro de equipamentos. 
 1.1 Ocorre o redirecionamento para a página inicial do sistema. 
 2. O usuário não fornece as informações necessárias para a realização de um novo cadastro de equipamento. 
 2.1 Sistema sinaliza as informações que devem ser preenchidas. 
 38 
 3. O sistema exibe a mensagem de erro ao cadastrar um novo equipamento e identifica em qual campo os 
 dados fornecidos não estão em conformidade. 
 Fonte: Próprios autores. 
 A Tabela 12 apresenta o caso de teste para a funcionalidade da tela de relatório dos 
 equipamentos. 
 Tabela 12 - Relatório dos equipamentos 
 Tipo Descrição 
 Identificação Relatório dos equipamentos 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Visualização de todos os equipamentos reservados 
 com data e hora de utilização. 
 Ator primário Cliente 
 Interessados Usuários 
 Pré-condições O usuário deve ter realizado login e acessar a página 
 de relatório. 
 Resultado esperado Acesso à tela de relatório de equipamentos 
 reservados e utilizados. 
 Fluxo Principal: 
 1. O usuário acessa a página de Relatório. 
 2. É exibida uma tela com calendário para navegação por data, relatório diário de equipamentos reservados. 
 3. O usuário consegue acessar a opção de “Histórico”, onde se preenche o período no qual se deseja realizar a 
 consulta do relatório e o sistema fornece um arquivo PDF com o período selecionado. 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a página de Relatório. 
 1.1 Ocorre o redirecionamento para a página inicial do sistema. 
 2. O arquivo PDF disponibilizado pelo sistema não é gerado corretamente (erro ao selecionar o período do 
 histórico). 
 Fonte: Próprios autores. 
 A Tabela 13 apresenta o caso de teste para a funcionalidade da tela de reserva de 
 equipamento pelo usuário. 
 Tabela 13 - Reserva de equipamentos 
 Tipo Descrição 
 Identificação Reserva de equipamento 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Reserva de equipamentos 
 Ator primário Cliente 
 Interessados Usuários 
 Pré-condições O usuário deve ter realizado login e acessar a página 
 de Reserva. 
 Resultado esperado Acesso à tela de reserva de equipamentos 
 Fluxo Principal: 
 39 
 1. O usuário acessa a página de Reserva. 
 2. É selecionada a opção “Reservar”. 
 3. Ocorre o redirecionamento para a página de reserva. 
 4. O usuário digita o equipamento que deseja reservar. 
 5. O sistema exibe as informações do equipamento, foto e datas em que está reservado. 
 6. O usuário selecionar a opção de reservar o equipamento é reservado, a data de reserva é gravada. 
 7. O usuário é redirecionado para a página de Reserva. 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a página de reserva. 
 1.1 Ocorre o redirecionamento para a página inicial do sistema. 
 2. O nome do equipamento não é digitado corretamente. 
 2.1 A tela de informações de equipamento não é exibida. 
 3. A data escolhida para reserva não está disponível. 
 3.1 A reserva de equipamento não é realizada. 
 Fonte: Próprios autores. 
 A Tabela 14 apresenta o caso de teste para a funcionalidade da tela da reserva de equipamento 
 pelo usuário. 
 Tabela 14 - Reserva de equipamentos 
 Tipo Descrição 
 Identificação Reservas realizadas 
 Objeto de Teste Sistema Reservas 
 Caso de Teste Visualização da tela de pedidos de reserva. 
 Ator primário Cliente 
 Interessados Usuários 
 Pré-condições 
 O usuário deve ter realizado login, acessando a 
 página de reserva e selecionando a opção de 
 pedidos. 
 Resultado esperado A tela de pedidos é exibida 
 Fluxo Principal: 
 1. O usuário acessa a página de pedidos. 
 2. Confere se sua reserva de equipamentos está no sistema. 
 3. O usuário consegue cancelar a reserva realizada. 
 3.1 Uma tela alertando o usuário que a reserva será excluída é exibida. 
 4. Caso a reserva for cancelada, o usuário é redirecionado para a página de reserva. 
 Fluxo Exceção: 
 1. O usuário não consegue acessar a página de pedidos. 
 2. Ocorre o redirecionamento para a página inicial do sistema. 
 Fonte: Próprios autores. 
 40 
 9. CONCLUSÃO 
 O objetivo do trabalho consiste na criação de um projeto para desenvolver um sistema 
 de reserva de equipamentos audiovisuais, que agilize e controle empréstimos de equipamentos 
 e recursos de apoio aos professores/colaboradores, sendo assim, viabilizado por meio do 
 emprego das técnicas de levantamento e análise de requisitos junto ao cliente, para saber quais 
 suas necessidades para o projeto, nesse contexto o uso de ferramentas de prototipação para 
 auxiliar no processo de interação das interface com o usuário, além da apresentação do 
 diagrama de classes, este diagrama permite modelar de forma mais precisa o software do 
 cliente e os dados a serem armazenados. O desenvolvimento do sistema vai permitir aos 
 usuários e gestores da instituição de ensino qualidade, agilidade e eficiência no atendimento 
 das demandas de recursos de apoio às aulas. Foram elencados o desenvolvimento e o 
 conhecimentos das normas para melhorar a capacidade de desenvolvimento de software nas 
 organizações brasileiras o MPS-BR e validação da viabilidade econômica do projeto com os 
 conhecimentos de economia e mercado. Foram elencados ao longo do texto técnicas e 
 ferramentas que tem por objeto agilizar o processo de implementação de um sistema que pode 
 ser aplicado integralmente no seu desenvolvimento por parte dos envolvidos. O estudo 
 colaborou para embutir os conceitos adquiridos nas disciplinas estudadas, fazem-se incentivos 
 para quese continuem os estudos e desenvolvimentos de novas ferramentas e técnicas que 
 permitam a criação de sistemas dinâmicos de maneira prática que podem atender a diversos 
 nichos de negócios. Podendo assim usar-se do artifício da tecnologia como resposta a diversas 
 adversidades que se encontram em nossos dias e atender as mais diversas necessidades das 
 organizações. 
 41 
 10. REFERÊNCIAS BIBLIOGRÁFICAS 
 
 BAUDRILLARD, Jean. A sociedade de consumo. Lisboa: Edições 70, 2003. 
 CUNHA, A. M.; BRAGA E SILVA, G.; MONTE-MOR, J. A.; DOMICIANO, M. A. P.; 
 VIEIRA, R. G. Estudo de Caso Abrangendo o Ensino Interdisciplinar de Engenharia de 
 Software. In: Fórum de Educação em Engenharia de Software, 2008. 
 Deitel, H. M. & Deitel, P. J. Java, como programar. 4. ed. Porto Alegre: Bookman, 2003. 
 GREMAUD, AMAURY PATRICK; VASCONCELLOS, MARCO ANTÔNIO SANDOVAL 
 DE; JÚNIOR, RUDINEI TONETO. Economia Brasileira Contemporânea. 5. ed. São Paulo: 
 Atlas, 2004. 
 KATHY SIERRA, BERT BATES. Rio de Janeiro: Alta Books, 2007. 
 MCT – MINISTÉRIO DE CIÊNCIA E TECNOLOGIA (2008), site do Ministério de Ciência 
 e Tecnologia - www.mct.gov.br, acessado em 01/04/2023. 
 NOGUEIRA, M.O. (2006) Qualidade no Setor de Software Brasileiro, Tese de Doutorado, 
 COPPE/UFRJ, abril 2006. 
 OBRIST M, ROTO V, VÄÄNÄNEN-VAINIO-MATTILA K. User Experience 
 Evaluation – Do You Know Which Method to Use? CHI 2009 - Conference of Human 
 Factors and Computer Systems. p. 2763 – 2766, 2009. 
 PETRIE, Helen; BEVAN, Nigel. The evaluation of accessibility, usability and user 
 experience. In: STEPHANDIS, Constantine. The universal access handbook. Boca Raton, 
 Florida, Estados Unidos: Crc Press, p. 20.1-20.14. 2009. Disponível em: . Acesso em: 12 
 março. 2023. 
 42 
 PRESSMAN, ROGER S. Engenharia de Software. 6ª ed. Rio de Janeiro: McGraw-Hill, 2006. 
 ROTO, VIRPI ET AL. All about UX. Disponível em: < http://www.allaboutux.com >. Acesso 
 em: 05 abr. 2023. 
 SILVA, CÉSAR ROBERTO LEITE DA; LUIZ, SINCLAYR. Economia e mercados: 
 introdução à economia. 18. ed. São Paulo: Saraiva, 2001. 
 SOMMERVILLE, I. (2003). Engenharia de software. 5.ed. São Paulo: Pearson. 
 SOUZA, NALI DE JESUS DE. Economia Básica. 1. ed. São Paulo: Atlas, 2007. 
 SOUZA, A.; CLEMENTE, A. Decisões Financeiras e Análise de Investimentos: 
 Fundamentos, técnicas e aplicações. 6 ed. 186 p. São Paulo: Atlas, 2009 
 SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley, 
 2007. 
 TRORY, A., HOWLAND, K., & GOOD, J. (2018). Designing for concreteness fading in 
 primary computing. In Proceedings of the 17th ACM Conference on Interaction Design and 
 Children (pp. 278-288). 
 VAZQUEZ, CARLOS; SIMÕES, GUILHERME (2016). Engenharia de Requisitos: Software 
 Orientado ao Negócio . [S.l.]: Brasport 
 ZANETTI, H. A., & BORGES, M. A. (2021). Por que estimular a Aprendizagem 
 Significativa no ensino de Programação Orientada a Objetos?. In Anais do Simpósio 
 Brasileiro de Educação em Computação (pp. 290-295). SBC. 
http://www.allaboutux.com/