PIM V- PROJETO DE UM SISTEM A DE RESERVA DE EQUI PAM ENTOS AUDIOVISUAIS PARA ESCOLAS

Prévia do material em texto

UNIVERSIDADE PAULISTA- UNIP EAD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia 
Nomes: 
PIM V- PROJETO DE UM SISTEM A DE RESERVA DE EQUI PAM ENTOS
AUDIOVISUAIS PARA ESCOLAS
SÃO PAULO-SP
2
2020
NOMES:
Renan Abreu Miranda RA: 2073537
William Clementino de Souza RA: 2062055
PIM V- PROJETO DE UM SISTEM A DE RESERVA DE EQUI PAM ENTOS
AUDIOVISUAIS PARA ESCOLAS
Projeto Integrado Multidisciplinar para a obtenção do título de graduação em Análise e Desenvolvimento de Sistemas, apresentado à Universidade Paulista-UNIP EAD.
Orientador: Profa. Priscila Facciolli
SÃO PAULO-SP
2020
RESUMO
Este trabalho acadêmico tem como objetivo projetar toda a vida de uma contratação de um software que administrará as reservas de equipamentos audiovisuais de escolas de ensino fundamental e médio, em especial o “Colégio Vencer Sempre”, desde o orçamento, previsão de gastos, cronograma de entrega, dividindo o projeto e suas fases por dia, passando pelas etapas de levantamento, análise e documentação dos requisitos (funcionais e não funcionais), prototipação de alta fidelidade, especificação de interfaces, até as etapas mais técnicas com a codificação em linguagem orientada à objetos, testes, entrega do produto, e implantação junto ao usuário. Será documentado todo o processo e metodologia de software utilizada na implantação do sistema para obtenção de um produto com qualidade, utilizando a metodologia MPS.br para obter práticas de engenharia de software, testes (incluindo todo o roteiro, os casos de sucesso e insucesso, fichas de execução dos testes), negociação no mercado e pós-venda, com o intuito de crescimento para a recente empresa de software que procura se consolidar no mercado.
Palavras-chave: Sistema para reservas. Programação orientada à objetos. Projeto de software. Roteiro de testes. MPS.br.
ABSTRACT
This academic work aims to project the entire life of a software contract that will manage the reserves of audiovisual equipment of elementary and high schools, in particular the “Colégio Vencer Semper”, from the budget, expenditure forecast, schedule of delivery, dividing the project and its phases per day, going through the steps of survey, analysis and documentation of the requirements (functional and non-functional), high-fidelity prototyping, specification of interfaces, up to the most technical steps with coding in language oriented to objects, tests, product delivery, and implantation with the user. The entire software process and methodology used to implement the system to obtain a quality product will be documented, using the MPS.br methodology to obtain software engineering practices, tests (including the entire script, success and failure cases, test execution sheets), market negotiation and after-sales, with the intention of growing for the recent software company that seeks to consolidate itself in the market.
Keywords: Reservation system. Object-oriented programming. Software design. Test script. MPS.br.
SUMÁRIO
INTRODUÇÃO.........................................................................................6
2. INVESTIMENTO FINANCEIRO E CRONOGRAMA............................7
3.PLANEJAMENTO................................................................................ 8
3.1. Requisitos funcionais.............................................................9
3.2. Requisitos não funcionais e regras de negócio .....................9
3.3. Especificação da interface....................................................10
4. METODOLOGIA MPS.br................................................................... 10
4.1. Detalhamento dos processos para nível G do MPS.br ..........11
4.1.1 Gerência de Projetos...........................................................12
4.1.2 Gerência de Requisitos........................................................12
5. PROTOTIPAÇÃO E TESTES..............................................................13
5.1. Casos de testes.....................................................................13
5.2. Prototipação...........................................................................13
5.2.1. Cadastro de usuário............................................................15
5.2.2. Inventário.............................................................................14
5.2.3. Reservas..............................................................................14
5.3. Testes.....................................................................................14
5.3.1. Cadastro de usuário.............................................................14
5.3.2. Inventário............................................................................. 15
5.3.3. Reserva.................................................................................17
6. PROGRAMAÇÃO ORIENTADA À OBJETOS...................................... 18
6.1. Classes e Objetos....................................................................19
6.2. Herança e Polimor/smo............................................................19
7. CONCLUSÃO....................................................................................... 20
8. REFERÊNCIAS BIBLIOGRÁFICA.........................................................21
INTRODUÇÃO
Informação e conhecimento são com certeza a principal alavanca da economia. A Tecnologia da Informação influência de forma elevada no desempenho de todos os setores econômicos, sejam estes públicos ou privados, e é também um setor extremamente dinâmico e de elevado peso econômico. A participação econômica da indústria de software não pode ser determinada só pelos empregos e impostos que geram. O software provoca um profundo impacto em quase todos os seguimentos da economia. Desde o nível mais baixo como automatizar tarefas que outrora eram repetitivas e desperdiçavam muito tempo e dinheiro, com o tempo e valores que antes as empresas gastavam com essas tarefas hoje elas podem usar em tarefas mais robustas e de maior importância. 
Hoje os sistemas de software fazem parte da vida e do cotidiano de cada vez mais pessoas, seja em programas de computador, celulares, carros, catracas eletrônicas e até mesmo em elevadores inteligentes. 
Nesse cenário de intensas transformações provocadas pela utilização de
computadores e celulares, o que modificou o comportamento e a forma de as pessoas se comunicarem, fortifica-se aí a importância do mercado de software no Brasil também na área da educação. 
A partir das especificações da Interface do novo software e utilização de metodologias de qualidade de software, o projeto objetiva ter uma fácil usabilidade, fácil implantação, e que agrade usuários de todos os níveis. Serão aplicados testes elaborados a partir de roteiros, a fim de minimizar qualquer problema no software, garantindo sua segurança e qualidade. 
O sistema será desenvolvido com a linguagem de programação C#, desenvolvido na plataforma Visual Studio, por ser uma linguagem orientada a objetos, o que auxilia na obtenção dos melhores resultados para o projeto.
2.INVESTIMENTO FINANCEIRO E CRONOGRAMA
Funcionamento da economia de mercado está associado a duas regras “compra e venda”, podemos dizer que tem como maior parte objetivo do lucro e não somente o atendimento das necessidades sociais. 
Mercado obedece à lei da oferta e procura, consiste na precificação dos produtos mediante a demanda. Nesse caso podemos usar a famosa “regra de três”, um produto muito procurado seu preço tende a subir, e por outro lado um produto em excelso que não tem tanta saída comercial, a tendência é o preço cair.
O Estado tem o papel de regulamentação e fiscalização da economia, além de atender setores prioritários como: energia, segurança, educação e saúde, entre outros. Porém não interversão do estado para regular a economia, pois o mercado autorregula, que acontece com base nos princípios da livre concorrência e da lei da oferta e procura.
Em economia, Leida Oferta e Procura é um modelo de determinação de preços num mercado. Num mercado em concorrência perfeita, os agentes econômicos tomam decisões que variam o preço até que este seja tal que a quantidade procurada seja igual à quantidade oferecida, resultando daí um equilíbrio econômico em que não há incentivos para a alteração de quantidades ou preços, a imagem abaixo pode resumir tudo isso que falamos: 
Após análises com a diretoria, professores notaram uma grande demanda nas reservas/equipamentos no Colégio Vencer Sempre, chegaram à conclusão que seria necessário adquirir um software para melhor controle dentro da instituição. Essa implementação do sistema permitirá que todos os professores e colaboradores possam agendar com mais segurança e comodidades que poderá contar com as ferramentas necessárias sem imprevistos. 
De acordo com o projeto solicitado, formalizado a proposta com um preço acessível diante dos preços do mercado, com um prazo para conclusão de 90 dias úteis após a assinatura do contrato. 
O cumprimento das determinações do cronograma de entrega é de extrema 
importância, sempre prezando pela qualidade e a satisfação do cliente em relação aos 
quesitos contratuais, se houver atrasos podem gerar insatisfação do cliente, elevação 
dos custos internos e prejuízo financeiro para ambas as empresas.
Para o projeto serão envolvidos: 
· 1 Desenvolvedor para codificação da ferramenta.
· 1 Analista de Sistemas para levantamento dos requisitos, planejamentos e validações até na entrega do produto.
Planejamento até a entrega, serão divididos em três fases:
· 10 dias para levantamento dos requisitos/planejamentos com os usuários que irão utilizar as ferramentas
· 40 dias para codificação da ferramenta de acordo com as especificações passadas do Analista
· 10 dias para implantação do sistema no Colégio.
Após a implantação o analista ficará à disposição no Colégio durante 7 dias para suportes. 
Custo do projeto será de R$ 15 mil, inclusos todos os custos relacionados ao analista e desenvolvedor até a entrega final. 
3. PLANEJAM ENTO
Para obtenção de bons resultados do projeto, é necessária a aplicação de metodologias de engenharia de software do início ao fim. Para Pressman (2006), ela ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. A utilização de normas e metodologias facilitam o entendimento do que o cliente realmente deseja receber, quais são os usuários que realmente irão interagir com o sistema, tendo início nas e tapas de levantamento dos requisitos funcionais, não funcionais, regras de negócio e finalização na entrega do produto e no aceite do cliente, passando pelas fases de codificação e validação do projeto.
A ideia de requisitos está ligada 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 alcançado.
 
O nosso projeto de um sistema de reserva de equipamentos audiovisuais para colégio de Ensino Fundamental e Médio, visa a melhorar o desempenho pedagógico, uma vez que automatiza o processo e o torna preciso, organizado e fácil de utilizar, tornando viável o investimento do colégio nesses equipamentos e no software, onde através do programa de reserva, que além da organização no processo, vai permitir ao colégio melhorar a dinâmica das aulas, e consequentemente a qualidade do ensino.
3.1. Requisitos funcionais
• 	Controle dos equipamentos: o sistema deverá controlar a reserva dos equipamentos audiovisuais do “Colégio Vencer Sempre”, controlando a data e hora da reserva, o usuário solicitante, bem como confirmações, cancelamentos e devoluções para cada requisição. Serão impressos relatórios que demonstrem as entrada e saídas dos equipamentos, quem os utilizou e período de utilização. 
• 	Avisos: para auxílio na organização e logística de entrega dos equipamentos, o sistema deverá avisar o usuário, quando estiver próximo ao período de um a reserva, a través de alertas/avisos, visando um preparo antecipado do equipamento, para que na hora reservada esteja pronto para entrega.
• 	Inventário: o sistema possuirá um cadastro de todos os equipamentos, datas de compra, garantia, entre outras características, a fim de gerenciar a vida útil dos equipamentos. Os equipamentos podem ser rastreados através de um QRCode fixado em cada um, possuindo identificação única.
3.2. Requisitos não funcionais e regras de negócio
• 	Permissões de acesso dos usuários: o sistema deverá ter um controle de acessos seguro para diferentes usuários, bloqueando usuários comuns de acessarem relatórios administrativos. As informações pessoais dos usuários devem ser mantidas sobre o controle apenas dos administradores do sistema.
• 	Configurações do sistema: inicialmente o sistema será desenvolvido apenas para Windows Desktop. Todos os relatórios devem seguir um padrão de fonte e espaçamento, conforme ABNT. Será desenvolvido em linguagem de programação C#, utilizando a plataforma Visual Studio 2019.
• 	Tempo de evolução e de espera: junto ao cadastro dos equipamentos, deverá ter informações de quanto tempo o usuário pode permanecer com o equipamento e quanto tempo ele pode esperar para obter o equipamento, após a sua solicitação. Essas regras são importantes na definição de logística do sistema.
3.3. Especificação da interface
O sistema será implantado na secretaria do colégio, no notebook do diretor, e no terminal do almoxarifado, onde são armazenados os equipamentos. Todos os computadores trabalham com Sistema Operacional Windows, e interagem com o sistema através de mouse, teclado e impressora. Será instalado no servidor que já é utilizado no colégio, comunicando-se com os terminais através de rede cabeada.
As telas serão simples, com botões grandes e fácil usabilidade e entendimento. Deve apresentar rápida resposta nas consultas geradas, podendo ser utilizado simultaneamente entre diferentes usuários.
4. METODOLOGIA MPS.br
A metodologia MPS.br foi criada 2003, pela coordenação da SOFTEX -Associação da Promoção da Excelência do Software Brasileiro, com o apoio do 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 Interamericano de Desenvolvimento, com o intuito de contribuir para uma maior 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 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.
O 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 SOFTEX. 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 foi a 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 IS O/IEC 12207:2008 [ISO/IEC, 2008a], IS O/IEC 20000:2011 [ISO/IEC, 2011] e ISO/IEC 15504-2 [ISO/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 oumais processos.
 
Os níveis de maturidade da metodologia MPS.br são:
 Nível G – Parcialmente Gerenciado: primeiro nível a ser atingido,
 Nível G – Parcialmente Gerenciado: primeiro nível a ser atingido implantando os processos de “Gerência de Projetos” e “Gerência de Requisitos”;
 Nível F – Gerenciado: além dos processos implantados no nível anterior,
 Nível F – Gerenciado: além dos processos implantados no nível anterior,
são adicionados 5 novos processos: “Aquisição”, “Gerência de Configuração”, “Garantia da Qualidade”, Gerência de Portfólio de Projetos” e “Medição”;
 Nível E – Parcialmente Definido: compostos 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 Recursos Humanos” e “Gerência de Reutilização”
 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 C – Definido: inclui processos de “Desenvolvimento para Reutilização”, “Gerência de Decisões” e “Gerência de Riscos”;
 Nível B – Gerenciado Quantitativamente: apresenta além dos processos já informados nos níveis anteriores, a evolução da “Gerência de Projetos”;
 Nível A – Em Otimização: não apresenta processos específicos para esse nível, apenas modificando e aprimorando os processos existentes nos níveis anteriores. 
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.
4.1. Detalhamento dos processos para nível G do MPS.br
4.1.1 Gerência de Projetos
Tem como objetivo manter atualizadas as atividades, recursos, riscos, prazos e responsabilidades do projeto. Nesse processo, deve ser possível acompanhar o desenvolvimento das etapas do projeto, permitindo correções para não com prometer o andamento geral. Resultados esperados nessa fase do projeto:
 GPR1: escopo do projeto é estabelecido, mantido, atualizado e utilizado; 
 GPR2: um processo contido no projeto é mantido, atualizado e utilizado, contendo, pelo menos, o ciclo de vida do projeto e a lista de tarefas que serão executadas;
 GPR3: são estabelecidas e mantidas estimativas de dimensões de tarefas e produtos de trabalho do projeto. 
 GPR4: esforço, duração e custo para execução das tarefas e dos produtos do trabalho devem ser estabelecidos e justificados;
 GPR5: orçamento e cronograma devem ser estabelecidos e mantidos atualizados;
 GPR6: definidos os recursos humanos a partir do conhecimento individual dos participantes, e experiência;
 GPR7: definidos os recursos e ambiente de trabalhos necessários;
 GPR8: definida a estratégia para operação e suporte do produto;
 GPR9: envolvimento das partes envolvidas no projeto é planejado;
 GPR10: definidos os riscos do projeto, bem como seus impactos;
 GPR11: verificação de viabilidade do projeto;
 GPR12: definição de um plano geral;
 GPR13: revisão do plano do projeto com todos os envolvidos e obtenção de um compromisso de todos;
 GPR14 a 17: monitoramento de todos os mapeamentos anteriores;
 GPR18: ações corretivas relacionadas a desvios do projeto;
4.1.2 Gerência de Requisitos
Tem como objetivo manter atualizadas os requisitos das partes interessadas do produto. Resultados esperados:
 REQ1: são mapeadas as necessidades, expectativas e restrições das partes interessadas;
 REQ2: os requisitos são especificados, priorizados e mantidos atualizados;
 REQ3: entendimento e análise dos requisitos junto aos fornecedores;
 REQ4: aprovação dos requisitos pelos fornecedores dos requisitos;
 REQ5: comprometimento da equipe técnica em relação aos requisitos;
 REQ6: a rastreabilidade bidirecional entre requisitos, atividades e produtos de trabalho são estabelecidas e mantidas;
 REQ7: revisão dos itens anteriores;
5. Prototipação e Testes
Para garantia de um software com qualidade, será investida boa parte do projeto na elaboração, documentação e execução dos testes do software. Será utilizada a metodologia TDD (Test Driven Development). Essa metodologia visa gerir testes antes mesmo da codificação do sistema, garantindo que o que será criado funcionará (ANICHE, 2014). Pretende-se, com o uso dessa metodologia, atingir a satisfação do cliente, evitando erros na entrega do software.
5.1. Casos de testes
As etapas de planejamento do projeto foram idealizadas a partir do estudo do caso das solicitações dos usuários envolvidos, e foram identificados a seguir:
1) CADASTRO DE USUÁRIO: informar dados corretos e incorretos;
2) INVENTÁRIO: informar os dados corretos para adicionar equipamento, e dados incorretos;
3) RESERVAS: informar dados do equipamento e do usuário corretos, informar dados do equipamento e/ou do usuário incorretos e solicitar reserva de equipamento já reservado;
5.2. Prototipação
Para cada tela/formulário do sistema, são especificados os campos e as regras envolvidas e a tela desenhada do sistema para cada um deles:
5.2.1. Cadastro de usuário
 Campos do cadastro do usuário: NOME -> nome d o colaborador, admite
 Campos do cadastro do usuário: NOME -> nome do colaborador, admite somente letras, campo obrigatório; LOGIN -> nome curto para acesso ao sistema, admite letras, campo obrigatório, máximo de 7 caracteres; SENHA-> senha para acesso ao sistema, admite letras e números, mínimo de 5 caracteres, campo obrigatório; ENDEREÇO -> endereço do colaborador, admite letras e números, campo não obrigatório; EMAIL -> endereço de e-mail do colaborador, admite letras, números e caracteres, validação de e-mails, campo não obrigatório.
5.2.2. Inventário
 Campos do cadastro do inventário: NOME -> nome do equipamento, admite letras e números, campo obrigatório; FABRICANTE -> nome do fabricante do equipamento, admite letras e números, campo não obrigatório; DATA DA COMPRA-> data de aquisição do equipamento, admite datas contidas no calendário, campo não obrigatório; DATA DA GARANTIA -> data de prazo de garantia do equipamento, admite datas contidas no calendário, campo não obrigatório.
5.2.3. Reservas
 Campos do cadastro de reservas: LOGIN -> login do colaborador que deseja reservar o equipamento, campo obrigatório, campo seleção dos usuários cadastrados; EQUIPAMENTO -> nome do equipamento que será reservado, campo obrigatório, campo seleção dos equipamentos cadastrados; DATA DA RESERVA -> data da reserva, admite datas contidas no calendário, campo obrigatório; HORA DA RESERVA -> hora de reserva, admite horas, campo obrigatório. Validar disponibilidade do equipamento para a data e hora da reserva solicitada.
5.3. Teste
Os roteiros de testes visam identificar: qual o caso de teste aplicado, o passo a passo para realização do teste, os dados informados nos testes, o resultado esperado, resultado obtido, e a data da realização do teste, documentados a través de fichas denominadas “Resultado dos testes”. 
A seguir foram documentados os resultados para os 3 casos de testes planejados para o projeto do software:
5.3.1. Cadastro de usuário
 Passo a passo: digitar nome do colaborador;
 Dados informados: 1) “JOÃO DA SILVA”; 2) “MAR1A DO CÉU”; 3) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Somente letras!” e voltou o foco para o campo nome; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo nome.
 Passo a passo: digitar login do colaborador;
 Dados informados: 1) “JOAO”; 2) “MAR1A”; 3) vazio; 4) “FREDERICO”;
Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Não;	
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Não;4) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Somente letras!” e voltou o foco para o campo login; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo login; 4) ao teclar “enter”, apareceu a mensagem “Máximo de 7 letras!” e voltou o foco para o campo login;
 Passo a passo: digitar senha do colaborador;
 Dados informados: 1) “12345”; 2) “MAR1A”; 3) vazio; 4) “FRED”;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Sim; 3) Não; 4) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, passou o foco para o campo seguinte; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo senha; 4) ao teclar “enter”, apareceu a mensagem “Mínimo de 5 caracteres!” e voltou o foco para o campo senha;
 Passo a passo: digitar endereço do colaborador;
 Dados informados: 1) “12345”; 2) “Rua das Flores, nº 32”; 3) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Sim; 3) Sim;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, passou o foco para o campo seguinte; 3) ao teclar “enter”, passou o foco para o campo seguinte;
 Passo a passo: digitar e-mail do colaborador;
 Dados informados: 1) “joao@email.com”; 2) “MAR1A”; 3) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Sim;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o botão salvar; 2) ao teclar “enter”, apareceu a mensagem “Formato de e-mail inválido!” e voltou o foco para o campo e-mail; 3) ao teclar “enter, passou o foco para o botão salvar;
5.3.2. Inventário
 Passo a passo: digitar nome do equipamento;
 Dados informados: 1) “RETROPROJETOR1”; 2) “SCANNER”; 3) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Sim; 3) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, passou o foco para o campo seguinte; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo equipamento.
 Passo a passo: digitar nome do fabricante;
 Dados informados: 1) “EPSON”; 2) “XEROX 1”; 3) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Sim; 3) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, passou o foco para o campo seguinte; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo fabricante;
 Passo a passo: digitar data da compra do equipamento;
 Dados informados: 1) “11/03/2020”; 2) “30/02/2020”; 3) vazio; 4) “Não consta”;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Sim; 4) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter, apareceu a mensagem “Data inválida!” e voltou o foco para o campo data da compra; 3) ao teclar “enter”, passou o foco para o campo seguinte; 4) ao teclar “enter”, apareceu a mensagem “Data Inválida!” e voltou o foco para o campo data da compra;
 Passo a passo: digitar data da garantia do equipamento;
 Dados informados: 1) “11/03/2020”; 2) “30/02/2020”; 3) vazio; 4) “Não consta”;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Sim; 4) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o botão salvar; 2) ao teclar “enter”, apareceu a mensagem “Data in válida!” e voltou o foco para o campo data da garantia; 3) ao teclar “enter”, passou o foco para o botão salvar; 4) ao teclar “enter”, apareceu a mensagem “Data Inválida!” e voltou o foco para o campo data da garantia;
5.3.3. Reserva
 Passo a passo: selecionar nome do colaborador da reserva; Dados informados: 1) seleção de um colaborador da lista; 2) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo seleção do nome do colaborador.
 Passo a passo: selecionar nome do equipamento da reserva;
 Dados informados: 1) seleção de um equipamento da lista; 2) vazio;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo seleção do nome do equipamento.
 Passo a passo: digitar data da reserva do equipamento;
 Dados informados: 1) “11/03/2020”; 2) “30/02/2020”; 3) vazio; 4) “Não consta”;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não 3) Não; 4) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o próximo; 2) ao teclar “enter”, apareceu a mensagem “Data inválida!” e voltou o foco para o campo data da reserva; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo data da reserva; 4) ao teclar “enter”, apareceu a mensagem “Data Inválida!” e voltou o foco para o campo data da reserva
 Passo a passo: digitar hora da reserva do equipamento; Dados informados: 1) “15:00”; 2) “15:62”; 3) vazio; 4) “Não consta”; 5) incluir hora e data que já tenha reserva anterior;
 Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não 3) Não; 4) Não; 5) Não;
 Resultado obtido: 1) ao teclar “enter”, passou o foco para o botão salvar; 2) ao teclar “enter”, apareceu a mensagem “Hora inválida!” e voltou o foco para o campo hora da reserva; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo hora da reserva; 4) ao teclar “enter”, apareceu a mensagem “Hora Inválida!” e voltou o foco para o campo hora da reserva; 5) ao teclar “enter”, apareceu a mensagem “Equipamento reservado para horário informado!” e voltou o foco para o campo hora da reserva.
6. PROGRAMAÇÃO ORIENTADA À OBJETOS
A primeira linguagem de programação que utilizou os conceitos de programação orientada à objetos foi a Simula 67, criada por Ole-Johan Dahl e Kristen Nygaard em 1967, porém esse paradigma de programação só passou a ser largamente utilizado na atualidade. A maioria das linguagens de programações atuais utilizam orientação à objetos, podendo citar: Java, C#, C++, Deplhi entre outras, que apesar de terem diferenças entre si, seguem os mesmos princípios e conceitos
. 
A ideia principal da POO é aproximar o mundo real do mundo virtual, ou seja, uma simulação de episódios do cotidiano replicados no computador. O programador deve retratar através de objetos e a interação entre esses objetos, soluções para problemas reais, transcritos em uma linguagem de programação.
Uma das grandes vantagens da programação orienta à objetos está na facilidade de fazer manutenções em sistemas legados, deixando seu custo menor em relação a outras formas de programação, além da reutilização contínua de código. Os principais conceitos da POO são: objetos, classes, herança e polimorfismo.
6.1. Classes e Objetos
Um objeto é uma parte do sistema de computador, que possui em suas propriedades um conjunto de dados e procedimentos para manipulação desses
dados. Pode-se dizer que um sistema com orientação à objetos é a soma de diversos “objetos” que se comunicam, em conjunto ou individualmente, para resolução de problemas.
Do ponto de vista da programação, um objeto pode ser comparado à uma variável em uma programação convencional. A variável possui um espaço em memória que armazena seu estado atual (valor), e possui um conjunto de operações e comandos que podem ser aplicados a ela. Da mesma forma um objeto, adquire um espaço em memória para guardar seu estado atual (valor), podendo ser aqui, um conjunto de atributos, além de um conjunto de operações que podem ser aplicados ao objeto (chamados aqui de métodos).
 
As classes definem um tipo de dado nosistema, sendo formada por dados (atributos) e comportamentos (métodos). Após a definição de uma classe, vários
objetos podem ser criados a partir da mesma, ou seja, a classe é o elemento/ que dá a forma para os objetos. No sistema de reservas de equipamentos temos a classe “Cadastro” que possui como atributo o campo nome, e possui como métodos: “Cancelar”, “Excluir” e “Salvar e Novo”. A partir da classe “Cadastro” foram criados os objetos “Cadastro de Usuários”, “Inventário” e “Reservas”.
6.2. Herança e Polimorfismo
A herança e o polimorfismo surgem com o objetivo de reutilização de códigos implementados previamente, a fim de diminuir o tempo de implementações futuras e repetição de código fonte. Remetendo às classes e objetos anteriormente especificados, quando se cria um objeto ou uma nova classe a partir de uma classe 24 mães, o objeto ou classe filhos “herda” todos os atributos e métodos da classe mãe, dessa forma não existe a necessidade de reprogramação dos métodos pré-existentes. Chamamos essa característica de herança.
O polimorfismo tem como significado “várias formas”. Para a programação orientada à objetos, pode-se entender que polimorfismo é a característica de um método ou atributo de possuir comportamentos diversos ou apresentar diferentes formas em sua execução e resposta, podendo ser utilizado em classes diversificadas da sua hierarquia.
Ainda sobre o projeto do sistema de equipamentos para reserva do “Colégio Vencer Sempre”, a classe “Cadastro” comporta os atributos e a implementação dos métodos “Cancelar”, “Excluir” e “Salvar e Novo” estão contidas nela, não sendo necessário implementar tais métodos nos objetos filhos “Cadastro de Usuários”, “Inventário” e “Reservas”, utilizando assim, herança e polimorfismo na projeção do sistema.
7. CONCLUSÃO
A partir da demanda do “Colégio Vencer Sempre” em adquirir um software para controle das reservas de seus equipamentos audiovisuais, cria-se a oportunidade de oferta de produzir este sistema. Cria-se a necessidade de um projeto para mapear e planejar toda a extensão dessa contratação, incluindo previsão de orçamento, cronograma, análise de requisitos, documentação e planejamento durante todas as etapas do projeto.
O levantamento dos requisitos funcionais e não funcionais foi realizado através de análise dos usuários ao executarem a tarefa na reserva dos equipamentos e na interação entre eles. Constatou-se a necessidade do sistema em assegurar um controle dos equipamentos do colégio, através de seus cadastros, controle de reservas e avisos. Foi também especificada a interface do sistema para obter aprovação junto aos usuários finais.
Como o surgimento da oportunidade na produção do sistema de reservas pode vir a crescer e tornar-se mais complexo, desde seu início será utilizada a metodologia MPS.br, em seu primeiro nível (G – Parcialmente Gerenciado), para que quando houver crescimento, a empresa já tenha em sua essência a aplicação de metodologias para constante melhora dos produtos. 
A utilização de testes bem documentados e prototipação de alta fidelidade
visa a entrega de um sistema com a melhor usabilidade possível, de fácil aprendizagem, e que caia no gosto dos usuários, mas principalmente, seja seguro e confiável.
Por fim, a utilização de uma programação orientada à objetos será parte deste
projeto, visando diminuição no tempo de codificação, reutilização de código fonte, utilizando classes, herança e polimorfismo em sua constituição, gerando ainda custos menores na produção do sistema. 
8. REFERÊNCIAS BIBLIOGRÁFICAS
UNIP - Universidade Paulista. Economia e Mercado. São Paulo, 2020.
UNIP - Universidade Paulista. Programação Orientada à Objetos I. São Paulo, 2020.
UNIP - Universidade Pau lista. Projeto de Interface com o Usuário. São Paulo, 2020.
UNIP - Universidade Paulista. Engenharia de Software II. São Paulo, 2020. 
ANICHE, Maurício. Test-Driven Development: Teste e Design no mundo real. São
Paulo: Casa do Código, 2014.
PRESSMAN, ROGER S. Engenharia de Software. McGra w-Hill, 2006. SINTES,
Tony. Aprenda programação orientada a objetos em 21 dias. São Paulo: Pearson
Education do Brasil, 2002.
https://www.softex.br/wpcontent/uploads/2013/07/MPS.BR_Guia_Geral_Software_20
12-c-ISBN-1.pdf. Acessado em 07/04/2021 às 20:35hs.
https://www.promovesolucoes.com/quais-sao-os-ni veis-de-maturidade-do-mps-br/ .
Acessado em 09/04/2021 as 21:05hs.
https://monitoriadeengenhariadesoftware.wordpress.com/2016/09/06/estudo-de-
viabilidade-de-software/ . Acessado em 10/04/2021 as 20:17hs.
Quanto vale um software que você produz. Disponível em:
http://www.macoratti.net/eng_qvs.html. Acessado em 11/04/2021 as 18:50hs.
 N ível E – Parcialmente D efinido: compostos pelos processos dos