PIM V - ADS - RAFAEL MARTINS DA SILVA

Prévia do material em texto

0 
 
UNIVERSIDADE PAULISTA 
 
UNIP EaD 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
PIM V 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIP 
2020 
1 
 
UNIP EaD 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
Projeto para Reservas de Equipamentos Audiovisuais. 
 
 
 
 
Rafael Martins da Silva 
RA: 0505681 
Tec. em Análise e Desenvolvimento de Sistemas 
2º Semestre 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIP 
2020 
2 
 
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 do 
“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-Chaves: MPS-BR. Orientada a objetos. Programação. Roteiro de testes. Sistemas 
para reserva. 
 
 
 
 
3 
 
ABSTRACT 
This academic work aims to project the entire life of a software contract that will manage the 
audiovisual equipment reserves of “Colégio Vencer Semper”, from the budget, expenditure 
forecast, delivery schedule, dividing the project and its phases per day , going through the steps 
of gathering, analyzing and documenting the requirements (functional and non-functional), 
high-fidelity prototyping, interface specification, up to the most technical steps with object-
oriented language coding, testing, product delivery, and deployment 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. 
 
Keyword: MPS-BR. reservation system. object-oriented programming. software design test. 
script. 
4 
 
SUMÁRIO 
 
 
1. INTRODUÇÃO .............................................................................................. 5 
2. INTERAÇÃO DO SISTEMA COM O “COLÉGIO VENCER SEMPRE” E 
COM O MERCADO ................................................................................................ 6 
3. INVESTIMENTO FINANCEIRO E CRONOGRAMA ............................... 6 
4. PLANEJAMENTO ......................................................................................... 7 
5. MPS-BR ........................................................................................................ 10 
6. PROTOTIPAÇÃO E TESTES ..................................................................... 14 
7. PROGRAMAÇÃO ORIENTADA A OBJETOS ......................................... 20 
8. CONCLUSÃO ............................................................................................... 22 
9. REFERÊNCIAS ............................................................................................ 23 
 
 
5 
 
1. INTRODUÇÃO 
 
De um lado o aumento da tecnologia e a diversidade de equipamentos que visam 
aprimorar cada vez mais o ensino das escolas, como data shows, sistemas de áudio, projetor de 
slides, entre diversos outros. De outro lado, o crescimento das escolas e o constante aumento 
de professores e demais colaboradores e alunos. Manter um controle dos equipamentos, quem 
está usando em determinado momento, reservas prévias para garantir a utilização e não 
atrapalhar os planos de uma aula, o controle antes manual feito por planilhas no computador, 
não é mais eficaz, surgindo a necessidade de um projeto para atender essa demanda. 
Será necessário um planejamento realizado a partir da análise de todos os requisitos 
envolvidos no projeto, para uma estimativa coerente de cronograma e prazos na entrega das 
diferentes etapas do projeto, bem como os investimentos financeiros. 
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. 
 
6 
 
2. INTERAÇÃO DO SISTEMA COM O “COLÉGIO VENCER SEMPRE” E COM O 
MERCADO 
 
O projeto de software para reserva de equipamentos audiovisuais do “Colégio Vencer 
Sempre” 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. Do lado da oferta temos a empresa de 
tecnologia que está disposta a produzir tal software. Os funcionários da empresa de software 
oferecem seus serviços para a empresa, em troca de salários. A empresa de software visa lucros 
para futuros investimentos. Esse ciclo contempla os agentes financeiros envolvidos em todo o 
projeto. 
 
3. INVESTIMENTO FINANCEIRO E CRONOGRAMA 
 
Por ser um protejo simples que não pode ser vendido a um preço muito alto, os custos 
para produção do software devem ser baixos, porem 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 4 
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: 
 
 
 
7 
 
Figura 1 - Cronograma do projeto 
 
Fonte: o autor (2020) 
 
De acordo com o gráfico apresentado, o cronograma será de 1 mês e meio para a fase 
de planejamento, que compreende levantamento de requisitos, prototipação e validação junto 
ao usuário final do sistema; 1 mês para a codificação do sistema; 1 mês e meio para criação dos 
requisitos de testes, execução dos testese entrega do produto. 
O custo do projeto será de acordo com o salário dos três envolvidos (analista, 
desenvolvedor e testador) durante os 4 meses do projeto. 
 
 
4. 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. 
 
 
 
 
8 
 
4.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 uma 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. 
 
4.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 devoluçã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. 
 
 
 
 
9 
 
4.3. Especificação de interface 
 
O sistema será implantado na secretaria do colégio, no terminal do almoxarifado, e no 
notebook do diretor, onde são depositados 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. 
 
 
10 
 
5. MPS-BR 
 
Em 2003, a coordenação da SOFTEX - Associação da Promoção da Excelência do 
Software Brasileiro, cria a metodologia MPS.BR, 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, porem 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ça-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 audiovisuais do “Colégio 
Vencer Sempre”, pois a empresa está em fase inicial e não dispõe de muitos recursos financeiros 
para investimento nas metodologias de processo de software. 
O MPS-BR tem como base técnica as normas ISO/IEC 12207:2008 [ISO/IEC, 2008], 
ISO/IEC 20000:2011 [ISO/IEC, 2011] e ISO/IEC 15504-2 [ISO/IEC, 2003]. 
Possui 7 níveis de maturidades, como apresentado na figura abaixo: 
 
11 
 
Figura 2 - Níveis do MPS-BR 
 
Fonte: https://www.promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/ Acessado em 
22/03/2020 
 
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. 
12 
 
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. 
 
5.1. Detalhamento dos processos para nível G do MPS-BR 
 
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 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; 
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; 
13 
 
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; 
 
 
14 
 
6. PROTOTIPAÇÃO E TESTES 
 
Para garantia de um software com qualidade, será investida boa parte do projeto (um 
mês e meio, conforme cronograma) 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. 
 
6.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: 
CADASTRO DE USUÁRIO: informar dados corretos e incorretos; 
INVENTÁRIO: informar os dados corretos para adicionar equipamento, e dados 
incorretos; 
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; 
 
6.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: 
 
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; 
15 
 
Figura 3 - Tela de cadastro do usuário 
 
Fonte: aluno 
 
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 de inventário 
 
Fonte: acadêmico. 
 
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 -
16 
 
> 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 - Telas reservas 
 
Fonte: acadêmico. 
 
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 atravé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: 
 
a) 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. 
 
17 
 
b) 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; 
 
c) 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; 
 
d) 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; 
e) 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; 
 
Inventário 
f) 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; 
18 
 
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 
“Preenchimentoobrigatório!” e voltou o foco para o campo equipamento. 
 
g) 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; 
 
h) 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; 
 
i) 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 invá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; 
 
j) 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. 
 
19 
 
k) 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. 
 
l) 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; 
 
m) 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. 
 
 
20 
 
7. PROGRAMAÇÃO ORIENTADA A 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. 
 
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 à 
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”. 
21 
 
 
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 nos objetos filhos “Cadastro de Usuários”, “Inventário” e “Reservas”, utilizando 
assim, herança e polimorfismo na projeção do sistema. 
 
 
 
22 
 
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 oportunidadede 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. 
 
 
23 
 
9. REFERÊNCIAS 
 
 
ANICHE, Maurício. Test-Driven Development: Teste e Design no mundo real. São Paulo: 
Casa do Código, 2014. 
https://www.softex.br/wp- content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-
c-ISBN-1.pdf. Acessado em 22/03/2020 as 9:35hs. 
https://www.promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/. Acessado 
em 22/03/2020 as 11:00hs. 
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. 
UNIP -Universidade Paulista. Ref.: Economia e Mercado. Itaberaí, 2020. 
UNIP -Universidade Paulista. Ref.: Programação Orientada à Objetos I. Itaberaí, 2020. 
UNIP -Universidade Paulista. Ref.: Projeto de Interface com o Usuário. Itaberaí, 2020. 
UNIP -Universidade Paulista. Ref.: Engenharia de Software II. Itaberaí, 2020. 
https://monitoriadeengenhariadesoftware.wordpress.com/2016/09/06/estudo-de- viabilidade-
de-software/. Acessado em 19/03/2020 as 20:17hs.r