PIM V - SISTEMA DE RESERVA DE EQUIPAMENTOS AUDIOVISUAIS - PASSEI DIRETO

Prévia do material em texto

2
UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia
ALUNO – RA: XXXXXXX
PROJETO DE UM SISTEMA DE RESERVA DE EQUIPAMENTOS AUDIOVISUAIS PARA ESCOLAS
CIDADE
2020
ALUNO – RA: XXXXXXX
PROJETO DE UM SISTEMA DE RESERVA DE EQUIPAMENTOS AUDIOVISUAIS PARA ESCOLAS
Projeto Integrado Multidisciplinar para obtenção do título de graduação em Análise e Desenvolvimento de Sistemas apresentado à Universidade Paulista – UNIP EaD.
Orientador(a): Prof. XXXXXXXXXXX.
CIDADE
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 Sempre”, from the budget, expenditure forecast, schedule of delivery, dividing the project and its phases by 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 in the implementation of 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: System for reservations. Object-oriented programming. Software design. Test routing. MPS.br.
SUMÁRIO
INTRODUÇÃO	6
1. INTERAÇÃO DO SISTEMA COM A ESCOLA E COM O MERCADO	7
2. INVESTIMENTO FINANCEIRO E CRONOGRAMA	7
3. PLANEJAMENTO	9
3.1. Requisitos funcionais	9
3.2. Requisitos não funcionais e regras de negócio	10
3.3. Especificação da interface	10
4. METODOLOGIA MPS.br	11
4.1. Detalhamento dos processos para nível G do MPS.br	13
4.1.1 Gerência de Projetos	13
4.1.2 Gerência de Requisitos	14
5. PROTOTIPAÇÃO E TESTES	15
5.1. Casos de testes	15
5.2. Prototipação	15
5.2.1. Cadastro de usuário	15
5.2.2. Inventário	16
5.2.3. Reservas	17
5.3. Testes	18
5.3.1. Cadastro de usuário	18
5.3.2. Inventário	20
5.3.3. Reserva	21
6. PROGRAMAÇÃO ORIENTADA À OBJETOS	22
7.1. Classes e Objetos	23
7.2. Herança e Polimorfismo	23
8. CONCLUSÃO	24
9. REFERÊNCIAS BIBLIOGRÁFICAS	25
INTRODUÇÃO
Informação e conhecimento são com certeza a principal alavanca da economia. A Tecnologia da Informação influencia de forma elevada no desempenho de todos os setores econômicos, sejam estes públicos ou privados, e é também um setor extremamente dinâmico e de elevado peso econômico. 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 as mesmas 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.
1. INTERAÇÃO DO SISTEMA COM A ESCOLA E COM O MERCADO
O projeto de software para reserva de equipamentos audiovisuais para escolas será utilizado pelos funcionários que fazem o controle desses equipamentos, e pode ser estendido para alunos, diretoria, administração do colégio, além dos professores e demais colaboradores. A aquisição do software é realizada pela administração do colégio, que nesse cenário, é o agente demandante do produto de software. 
Praticamente todos os agentes econômicos interferem no projeto: Famílias – os pais pagam a mensalidade, o colégio por sua vez entra como consumidores dos serviços de ensino; Empresa: o colégio entra como empresa que presta serviços de ensino e contrataram nossos serviços de software; Governo; administra os impostos recolhidos das famílias e empresas e administram esses recursos que são consumidos pela coletividade. Mundo; comércio exterior registra as transações econômicas com agentes econômicos pertencentes a outros países. 
2. INVESTIMENTO FINANCEIRO E CRONOGRAMA
Por ser um projeto simples que não pode ser vendido a um preço muito alto, os custos para produção do software devem ser baixos, porém atender aos padrões de qualidade, e dentro das possibilidades, deve ser entregue em um prazo médio. 
Após o aceite do “Colégio Vencer Sempre” do projeto oferecido, as etapas se iniciarão, detalhadas a seguir, para o cumprimento da entrega final do produto no prazo máximo de 90 dias (três meses). O cumprimento das determinações do cronograma de entrega é de extrema importância, chegando a ser mais relevante do que os próprios custos, pois, se descumpridos, podem gerar insatisfação do cliente, elevação dos custos internos e até uma falência do projeto antes do tempo, deixando o mesmo incompleto.
Serão envolvidos no projeto: um analista de sistemas para fazer o levantamento dos requisitos, planejamento e documentação, um programador que irá codificar a ferramenta e um testador para fazer toda a validação para entrega do produto. Os esforços para projeção do software serão de acordo com o gráfico abaixo (Figura1): 
Figura 1. Tempo estimado do projeto.
Fonte: O autor (2020).
De acordo com o gráfico apresentado, o cronograma será de quinze (15) dias para a fase de planejamento, que compreende o levantamento de requisitos, prototipação e validação junto ao usuário final do sistema; sessenta (60) dias para a codificação do sistema; quinze (15) dias para criação dos requisitos de testes, execução dostestes e entrega do produto.
O custo do projeto será de acordo com o salário dos três envolvidos (analista, desenvolvedor e testador) durante os 90 dias do projeto. O custo total do projeto incluindo mão de obra, licença de uso, mais mensalidades e custos de implantação: 
Análise: 15 dias (120 horas)
Desenvolvimento: 60 dias (480 horas)
Testes: 15 dias (120 horas)
Tempo estimado de conclusão: 90 dias (760 horas) 
Valor total do projeto: R$ 51.625,00
3. PLANEJAMENTO
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 etapas 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, atravé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 também 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 ISO/IEC 12207:2008 [ISO/IEC, 2008a], ISO/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 se u desempenho futuro ao executar um ou mais processos. 
Os níveis de maturidade da metodologia MPS.br são:
 Nível G – Parcialmente Gerenciado: primeiro nível a ser atingido, implantando os processos de “Gerência de Projetos” e “Gerencia de Requisitos”;
 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.
Na Figura 2, temos a representaçãodo MPS.br:
								Figura 2. Níveis do MPS.br
Fonte: https://www.promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/ . Acesso em 09/04/2020
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 comprometer 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 da s tarefas e dos produtos do trabalho devem ser estabelecidas e justificadas;
 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 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.
Figura 3 – Tela de Cadastro de usuários.
Fonte: O autor (2020)
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.
Figura 4 – Tela Inventário
Fonte: O autor (2020)
5.2.3. Reservas
 Campos do cadastro de reservas: LOGIN -> login do colaborador que deseja reservar o equipamento, campo obrigatório, campo seleção do s 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. 
Figura 5 – Tela Reservas
Fonte: O autor (2020)
5.3. Testes
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; 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 in vá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 d a 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 d o 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.
7.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 e m 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 no sistema, 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”.
7.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 mãe, 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 no s objetos filhos “Cadastro de Usuários”,“Inventário” e “Reservas”, utilizando assim, herança e polimorfismo na projeção do sistema.
8. 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.
9. 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. McGraw-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_2012-c-ISBN-1.pdf . Acessado em 29/03/2020 às 20:35hs.
https://www.promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/ . Acessado em 09/04/2020 as 21:05hs.
https://monitoriadeengenhariadesoftware.wordpress.com/2016/09/06/estudo-de- viabilidade-de-software/ . Acessado em 23/03/2020 as 20:17hs.
Quanto vale um software que você produz. Disponível em: http://www.macoratti.net/eng_qvs.html . Acessado em 15 de abril de 2020 as 18:50hs.
Horas	Análise	Desenvolvimento	Testes	120	480	120