PIM IV Analise e desenvolvimento de sistemas UNIP

Prévia do material em texto

Resumo 
A programação orientada a objetos é um método de programação mais utilizada atualmente, 
que, aliada a bons métodos de engenharia de software podem resultar em projetos 
controlados e de alta qualidade. Portanto, o objetivo desse trabalho foi discorrer sobre 
características técnicas de programação orientada a objetos, além de descrever o método 
MPS.BR de desenvolvimento de software, além de realizar um estudo de viabilidade 
econômica do projeto. Após, foram prototipadas telas de interface com o usuários e 
desenvolvidos roteiros de testes para um software de reserva de equipamentos em um 
Colégio. 
 
Palavras-Chave: orientação objetos, programação, MPS.BR, engenharia software 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Abstract 
Object oriented programming is the most used type of computer programming these days, 
which, alongside with good software engineering methods, can result in high quality 
software. Therefor the objective of this work was to describe the characteristics of object 
oriented programming, besides describing the MPS.BR software developing method, and 
conduct economic feasibility studies. Then, user interface screens were prototyped and 
testes scripts were developed for an equipment reservation software. 
 
Key words: object oriented, MPS.BR, software engineering. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sumário 
Introdução ..................................................................................................................... 5 
Empresa RammSoft Ltda .......................................................................................... 5 
Objetivo do projeto ........................................................................................................ 5 
Engenharia de Software ............................................................................................... 6 
Requisitos ..................................................................................................................... 6 
Requisitos não funcionais do programa ..................................................................... 6 
Requisitos funcionais do programa ........................................................................... 6 
Casos de Uso (UC) ................................................................................................... 6 
Regras de Negócio.................................................................................................... 7 
Metodologia de Qualidade de Software – Melhoria de Processos de Software Brasileiro 
(MPS.BR) ..................................................................................................................... 9 
Planejamento de teste ................................................................................................ 12 
Requisitos a serem testados ................................................................................... 12 
Estratégias e ferramentas de teste .......................................................................... 12 
Roteiro de Testes ....................................................................................................... 13 
Localização 1: Tela 1 .............................................................................................. 13 
Localização 2: Tela 2 .............................................................................................. 14 
Localização 3: Tela 3 .............................................................................................. 14 
Localização 4: Tela 4 .............................................................................................. 15 
Economia e Mercado .................................................................................................. 16 
Agentes Econômicos .................................................................................................. 16 
Viabilidade Econômica ............................................................................................ 17 
Projeção de custos, despesas e investimentos .................................................... 17 
Cronograma e Investimento .................................................................................... 18 
Programação Orientada a objetos .............................................................................. 18 
Classes e Objetos ................................................................................................... 18 
Herança .................................................................................................................. 19 
Polimorfismo ........................................................................................................... 19 
Programa Colégio Vencer Sempre .......................................................................... 19 
Interface com Usuário ................................................................................................. 20 
Tela 1 ...................................................................................................................... 20 
Tela 2 ...................................................................................................................... 22 
Tela 3 ...................................................................................................................... 24 
Tela 4 ...................................................................................................................... 26 
Tela 5 ...................................................................................................................... 30 
Conclusão ................................................................................................................... 31 
Referências ................................................................................................................ 32 
Apêndice I ................................................................................................................... 33 
Relatório de testes .................................................................................................. 33 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Introdução 
 
 O colégio Vencer Sempre é um tradicional colégio que, juntamente com as 
novidades pedagógicas também apresenta diversas novidades tecnológicas que 
disponibilizam ao professor uma grande variedade de materiais auxiliares para tornar as 
aulas cada vez mais iterativas e envolventes, visando sempre o aprendizado do aluno. 
 Com o avanço das técnicas pedagógicas, o colégio Vencer Sempre disponibiliza em 
sua estrutura física diversos equipamentos para que o professor utilize em sala de aula. 
Com o aumento da procura desses equipamentos por partes dos professores notou-se a 
necessidade de um sistema de reserva para tais equipamentos para organizar a utilização 
bem como controlar o uso para eventuais situações de reparo. Para tanto o colégio Vencer 
Sempre contratou a empresa Rammsoft Ltda para levantes os requisitos e desenvolver um 
software de agendamento que supra as necessidades de seus funcionários. O colégio 
Vencer Sempre, contem em sua estrutura física, 10 salas separadas em dois blocos (A e B), 
onde em cada bloco ficam os alunos de ensino fundamental e médio. Há também 3 
auditórios onde os professores pode fazer cursos e aulões. 
Empresa RammSoft Ltda 
 
 A empresa Rammsoft é uma empresa de sociedade limitada, sediada na cidade de 
Curitiba/PR, fundada no ano de 2019. Especializada em desenvolvimento de software sob 
demanda, conta com 10 funcionários separados em 4 departamentos, um funcionário de 
recursos humanos, 3 funcionários na equipe de desenvolvimento, 2 na equipe de marketing 
e design, 2 nos suporte técnico , gerente geral e um auxiliar de serviços gerais. Apesar de 
ser uma empresa de pequeno porte, elabusca certificação MPS. Para poder manter seu 
nome no mercado, a empresa trabalha com diversos projetos ao mesmo tempo dividindo-os 
entre os funcionários de acordo com suas competências. 
 
 
Objetivo do projeto 
 
Criar um sistema de reserva de equipamentos para o Colégio Vencer sempre, onde os 
professores terão a possibilidade de visualizar todos os equipamentos disponíveis, escolher qual 
deseja e reserva-lo, escolhendo data e horário para a reserva, usando seu perfil profissional com 
vinculação de matrícula à reserva. 
 
Engenharia de Software 
 
Requisitos 
 
Requisitos são propriedades que uma aplicação apresenta para solucionar problemas reais, 
os quais permeiam os objetivos do sistema. Os requisitos são presentes em todo o ciclo de vida 
de um software, do começo do projeto, onde são levantados, até a fase de testes, verificação e 
validação. 
Requisitos não funcionais do programa 
 
Os requisitos não funcionais são aqueles relacionados ao uso da aplicação, e determina 
como o sistema executará as funções estabelecidas pelos requisitos funcionais (Vazquez et al, 
2016). Os requisitos-não funcionais do sistema serão: 
-Requisitos de eficiência: O sistema deverá processar 2 requisições por minuto, podendo 
cada uma vir de diferentes estações instaladas no colégio. 
-Requisitos de portabilidade: o sistema será desenvolvido executará em Windows versão 
10. 
-Requisitos de entrega: o sistema deverá gerar um relatório de acompanhamento de uso, a 
cada 30 dias. 
-Requisitos de implementação e padrões: o sistema será desenvolvido na linguagem 
orientada a objeto C#. 
-Requisitos de interoperabilidade: o sistema deverá se comunicar com banco SQL server, 
para recuperar as informações profissionais dos usuários. 
-Requisitos éticos: o sistema não deverá divulgar informações de cadastro na tela, o 
acesso a essas informações é restrito ao perfil administrador. 
 
Requisitos funcionais do programa 
 
Os requisitos funcionais definem uma função de um sistema. Uma função é definida como 
um conjunto de entradas, seus comportamentos e saída (Vazquez et al 2016). Nos requisitos 
funcionais, existe uma materialização das solicitações realizadas pelo software, especificando 
resultados particulares do sistema. Serão gerados casos de uso (UC) para auxiliar na 
determinação dos requisitos funcionais do programa 
 
Casos de Uso (UC) 
 
Especificações de caso de uso são narrativas em texto, que auxiliam na representação dos 
requisitos funcionais do sistema. No sistema do colégio Vencer Sempre, os atores dos casos de 
uso serão os professores e outros funcionários que utilizarão o sistema (Tabela 1). 
Caso de Uso 1 
Sumário: aba CADASTRO o usuário ira preencher os dados de cadastro 
(nome/matrícula/função), mas para acessar essas funções é necessário 
realizar login com dados de acesso do admin 
Pré-Condições: Os dados inseridos precisam ser validados ao clicar no 
botão 'CADASTRAR' 
Cadastro de 
usuário 
Pós-Condições: após preenchimento e validação pelo sistema, mensagem 
de 'CADASTRO REALIZADO'/'ERRO' 
Caso de Uso 2 
Sumário: Na aba 'RESERVAS', escolhe usuário e escolhe data/horário e 
equipamento desejados e clica em 'RESERVAR' 
Pré-Condições: O equipamento selecionado deve estar disponível 
(equipamentos reservados não serão selecionáveis) 
Escolha 
data/hora e 
equipamento 
Pós-Condições: após a escolha, o equipamento reservado não será 
selecionável no horário/data escolhidos. 
Regra de negócio: equipamentos já reservados não ficarão disponíveis 
nos horários previamente selecionados. Um usuário pode reservar mais 
que um equipamento para mesma data/hora. 
Caso de Uso 3 
Sumário: Na aba CADASTRO usuário clica no botão excluir usuários 
Pré-Condições: O usuário deve selecionar qual cadastro que excluir, na 
nova janela que ira abrir. 
Exclusão de 
usuário 
Pós-Condições: após a escolha, clicar no botão EXCLUIR USUÁRIO, 
usuário selecionado será excluído do banco de dados. 
Regra de negócio: pelo menos um cadastro deve estar selecionado para 
que o botão EXCLUIR USUÁRIO fique ativo 
Tabela 1: Casos de Uso 
 
Regras de Negócio 
 
 As regras de negócio são o que determinam como o processo é definido e dá as 
bases de conduta para os usuários. É um conjunto de instruções que os usuários já 
seguem, que devem ser contempladas no desenvolvimento do software. 
 Somente funcionários com login admin poderão realizar cadastro no software. 
 Há vinculação da matrícula do funcionário à reserva. 
 A retirada e devolução dos equipamentos é de responsabilidade do usuário. 
 Existe uma tolerância de dez minutos entre as reservas, terminado o horário de 
reserva, o equipamento será considerado como ‘disponível’ dentro do software. 
 Havendo reclamações de devolução atrasada, o coordenador pedagógico poderá 
exclui o usuário faltoso. 
 O cadastro usuários e equipamentos deverá ser feito pelo coordenador pedagógico, 
 
Interface Usuário 
 
Requisitos de cada interface frente aos requisitos do sistema estão apresentados na tabela 
2. 
 
Nº 
tela 
Requisitos sistema Requisitos da tela Mensagens 
 
1 Registro e especificação 
de todos os 
equipamentos da escola, 
com numeração. 
Tela de login para permitir acesso á tela 
de cadastro. Após login: Campo textbox 
para inserção de tipo de equipamento, 
campo textbox para numeração do 
equipamento, campo textbox para 
observações, botão com ação para 
confirmação e gravação de dados em 
banco de dados. 
Mensagem1: 
Equipamento cadastrado 
com sucesso 
Mensagem2: Favor 
preencher *campo* 
Mensagem3: Equipamento 
já cadastrado 
2 Cadastro de todos os 
funcionários que 
poderão reservar os 
equipamentos 
Tela de login para permitir acesso a tela 
de cadastro. Campo textbox para nome 
do funcionário, campo textbox para 
matrícula profissional do funcionário. 
Botão para cadastro. 
Mensagem1: 
Usuário cadastrado com 
sucesso 
Mensagem2: Numero de 
matrícula inválido 
Mensagem3: Usuário já 
cadastrado 
3 Tabela de todos os 
funcionários e 
equipamentos 
cadastrados 
Tabela com todos os funcionários e 
equipamentos cadastrados e checkbox 
em cada cadastro para seleção, e botão 
para exclusão de funcionário 
Mensagem1: Não há 
usuário/equipamento 
selecionado! 
Mensagem2: Deseja excluir 
usuário/equipamento 
selecionado(s)? 
4 Interface de escolha de 
equipamentos, onde 
funcionários cadastrados 
poderão visualizar quais 
os equipamentos 
Campo combobox onde serão exibidos 
os equipamentos cadastrados, campo 
extboc onde deverão ser inseridos os 
horários para a reserva e campo 
combobox onde serão exibidas as salas 
Mensagem1: Reserva 
efetuada com sucesso! 
Mensagem2: Equipamento 
não disponível para 
data/hora escolhido! 
disponíveis e escolher 
quais desejam para 
utilização. 
para onde os equipamentos serão 
levados, campo com escolha de data, 
campo combobox com os funcionários 
cadastrados no sistema. 
Mensagem3: Favor 
selecionar um equipamento. 
Mensagem4: Favor 
selecionar um usuário. 
5 Interface de visualização 
das reservas 
Tabela para exibição de todos os 
equipamentos com seus respectivos 
status de reserva, juntamente com a 
data e horário de reserva, se houver. 
Tela sem interação com 
usuário 
Tabela 2: Interface usuários, seus requisitos e mensagens. 
 
Metodologia de Qualidade de Software – Melhoria de Processos de Software 
Brasileiro (MPS.BR) 
 
 O modelo de qualidade de software escolhido foi o MPS.BR (Melhoria de Processos 
de Software Brasileiro). A escolha da metodologia de qualidade de software se deu pela 
qualidade do modelo, que apresenta elementos de modelos internacionalmente 
reconhecidos como CMMI, além das normas ISSO/IEC 12207 e ISSO/IEC 15504, além de 
levar em consideração a realidade do mercado de software brasileiro. Esta ultima 
característica é fundamental para uma empresa que está iniciando no mercado, sem muitos 
recursos financeirose de pessoal. Além de existir um agente regional na cidade de 
Curitiba/PR, a ASSESPRO/PR, facilitando a certificação (https://softex.br/agentes/). 
 O MPS.BR apresenta sete níveis de maturidade que estabelecem patamares de 
evolução do processo, o nível de maturidade que se encontra um projeto permite prever seu 
desempenho futuro ao executar um ou mais processos. Os níveis de maturidade estão 
apresentados na tabela 3. 
 
Nível de Maturidade Processos Atributos de processo 
A – Otimizado Não há processos definidos AP 1.1, AP 2.1, AP 2.2, 
AP 3.1, AP 3.2, AP 4.1, 
AP 4.2, AP 5.1, AP 5.2. 
B – Gerenciado 
Quantitativamente 
Não há processos definidos AP 1.1, AP 2.1, AP 2.2, 
AP 3.1, AP 3.2, AP 4.1, 
AP 4.2. 
C – Definido Gerência de decisões. Gerência 
de riscos. Desenvolvimento para 
AP 1.1, AP 2.1, AP 2.2, 
AP 3.1, AP 3.2. 
https://softex.br/agentes/
reutilização. 
D – Largamente definido Desenvolvimento de requisitos. 
Projeto e construção do produto. 
Integração do produto. 
Verificação. Validação. 
AP 1.1, AP 2.1, AP 2.2, 
AP 3.1, AP 3.2. 
E – Parcialmente definido Definição do processo 
organizacional. Avaliação e 
melhoria do processo 
organizacional. Gerência para 
reutilização. Gerência de recursos 
humanos. 
AP 1.1, AP 2.1, AP 2.2, 
AP 3.1, AP 3.2. 
F – Gerenciado Garantia de qualidade. Gerência 
da configuração. Medição. 
Aquisição. Gerência de portfólio. 
AP 1.1, AP 2.1, AP 2.2. 
G – Parcialmente 
gerenciado 
Gerência de projetos. Gerência de 
requisitos. 
AP 1.1, AP 2.1. 
Tabela 3: Processos MPR.BR por nível de maturidade (https://softex.br/mpsbr/). 
 
Sendo o nível G o primeiro a ser implementado e o nível A, o nível máximo que a empresa 
pode atingir. A implementação do MPS.BR exige a aplicação de vários processos relacionados ao 
produto de software, cada nível de maturidade apresenta diversos processos que devem ser 
seguidos para evoluir para o próximo nível. A evolução até o nível F, por exemplo, está listada a 
seguir (Tabela 3). 
 
Evolução Nível G 
Gerência de requisitos: o propósito desse processo é gerenciar 
os requisitos do sistema e de seus componentes, para verificar 
inconsistências entre os planos do projeto e os produtos de 
trabalho do projeto. 
Gerência de projetos: estabelecer e manter planos que definem 
as atividades, recursos e responsabilidades do projeto. Prover 
informações sobre o andamento do projeto de forma que 
correções possam ser feitas quando houver desvio significativo 
do andamento do projeto. 
Evolução Nível F 
Gerência de portfólio: analisar para iniciar e manter projetos que 
sejam necessários, suficientes e sustentáveis de forma a 
atender os objetivos estratégicos da empresa. Não obrigatório 
https://softex.br/mpsbr/
para empresas que possuem apenas um produto. 
Gerência de aquisição: gerenciar aquisição de produtos 
necessários elo adquirente. É opcional para empresas que não 
necessitam adquirir produtos a parte. 
Gerência de configuração: estabelecer e manter a integridade 
de todos os produtos de trabalho de um projeto e disponibiliza-lo 
a todos os envolvidos. 
Gerência de medição: coletar, analisar e relatar dados 
referentes as produtos desenvolvidos. 
Gerência de qualidade: assegurar que os produtos de trabalho e 
a execução de processos estão em conformidade com os 
planos, cronograma e recursos definidos. 
Tabela 4: Exemplo de processos para evolução até nível F. 
 
Além dos níveis de maturidade, o MPS.BR também descrevem atributos de processo que 
devem ser realizados a cada nível (Tabela 3), além dos resultados esperados para cada nível, 
afim de evidenciar que as metas de cada nível foram atingidas. Os atributos do processo são 
utilizados para implementação e avaliação de todo o processo, e são numerados de 1 a 5, 
conforme detalhado na tabela 5. 
 
Atributo de processo 
AP 1.1 O processo é executado e realiza o que foi proposto para ele. 
AP 2.1 O processo é gerenciado, ou seja, a execução do processo é 
gerenciada. 
AP 2.2 Os produtos do trabalho são gerenciados 
AP 3.1 O processo é definido, significa que existe um padrão e esse 
padrão apoia a implementação do processo. 
AP 3.2 O processo é implementado, após padronizado o processo é 
implementado para atingir seus objetivos. 
AP 4.1 O processo é medido, significa que algumas medições são 
feitas para assegurar que o desempenho do processo ajude a 
alcançar os objetivos para qual este foi proposto. 
AP 4.2 O processo é controlado estatisticamente para garantir 
previsibilidade, estabilidade e capacidade de execução. 
AP 5.1 O processo é o objetivo das inovações, as mudanças são 
identificadas a partir de análise de seus indicadores e da 
investigação de possíveis inovações. 
AP 5.2 O processo é otimizado continuamente. 
Tabela 5: Atributos de processo. 
Planejamento de teste 
 
 Esse documento tem como objetivo apresentar o planejamento das atividades de 
teste do software Colégio Vencer Sempre, sendo que este documento será utilizado como 
base para as atividades de revisão, verificação, e validação do projeto. Esse 
acompanhamento visa garantir a análise comparativa do resultado real x resultado 
planejado, com essa análise ações corretivas e preventivas poderão ser tomadas, sempre 
que os resultados reais desviem significativamente dos esperados. 
 
 O projeto tem como objetivo o desenvolvimento de um software de reserva 
equipamentos para o Colégio Vencer Sempre. Este documento de planejamento de testes 
tem como objetivo documentar os testes realizados no projeto de software Vencer Sempre, 
além de documentar as melhorias necessárias ao analisar os resultados dos testes. Este 
documento é direcionado aos agentes requerentes do projeto, com o objetivo de informar e 
capacitar as os agentes a usar o software e em como agir quando encontrar 
comportamentos estranhos no software. 
Requisitos a serem testados 
 
 Os requisitos a serem testados nesse documento são o desempenho do software, 
interface com usuário e funcionalidades. Ao analisar a necessidade de requisitos de 
segurança, a equipe juntamente com os agentes requerentes não verificaram a necessidade 
de segurança de acesso, visto que o software estará disponível em equipamentos 
localizados em locais de acesso restrito. 
 
Estratégias e ferramentas de teste 
 
 Serão adotadas duas estratégias de testes, testes automatizados, e serão 
executados como funções criadas dentro do projeto, estes farão testes de interface e 
usabilidade, somente testes lógicos do código. Serão também realizados testes de 
usabilidade (descritos a seção Roteiro de Testes), que serão feitos por agentes da equipe 
de desenvolvimento. 
 
Roteiro de Testes 
 
 Os roteiros de testes existem para guiar testes funcionais em softwares. O roteiro é 
elaborado a partir das especificações dos casos de uso. Os roteiros de testes são 
separados em localização, objeto e caso de teste. Uma localização pode conter mais que 
um objeto de testes, e este pode ser definido como um conjunto de casos de teste. Abaixo, 
os roteiros de testes para cada tela são descritos. 
 
Localização 1: Tela 1 
 Objeto de teste 1: Campos textbox 
o Caso de teste 1: 
 Descrição: Testar todos os campos textbox para caracteres 
especiais. 
 Pré-condição: caixas textbox estarem disponíveis. 
 Procedimento: Testar textos com caracteres especiais para 
observar comportamento do sistema. 
 Resultado esperado: sistema aceitar caracteres especiais sem 
que ocorra desconfiguração do texto. 
 Objeto de teste 2: Botão ‘CADASTRAR’ 
o Caso de teste 2: 
 Descrição: Testar comportamento do botão CADASTRAR 
quando algum campo textbox estiver vazio. 
 Pré-condição: caixas textobox estares disponíveis 
 Procedimento: deixar algumas caixas textbox vazias. 
 Resultado esperado: Mensagem de ‘Favor preencher*campo*’ 
deve ser exibida. 
o Caso de teste 2.1: 
 Descrição: Testar comportamento botão CADASTRAR 
Pré-condição: equipamento já estar cadastrado. 
 Procedimento: cadastrar duas vezes o mesmo equipamento. 
 Resultado esperado: mensagem de ‘Equipamento já 
cadastrado’ deve ser exibida. 
o Caso de teste 2.2: 
 Descrição: Testar comportamento botão CADASTRAR 
 Pré-condição: Novo cadastro. 
 Procedimento: cadastrar o equipamento. 
 Resultado esperado: mensagem de ‘Cadastro realizado com 
sucesso’ deve ser exibido. 
 
Localização 2: Tela 2 
 Objeto de teste 1: Campos textbox 
o Caso de teste 1.1 
 Descrição: testar uso de caracteres especiais 
 Pré-condição: campos textbox liberados. 
 Procedimento: Utilizar caracteres especiais do cadastro de 
novos usuário 
 Resultado esperado: mensagem de ‘Cadastro realizado com 
sucesso’ deve ser exibido e cadastro deve estar com as 
formatações corretas 
 Objeto de teste 2: Botão cadastro 
o Caso de teste 2.1 
 Descrição: testar comportamento botão com número de 
matrícula inválido 
 Pré-condição: campos textbox liberados. 
 Procedimento: Realizar novo cadastro digitar 000000 no 
número de matrícula. 
 Resultado esperado: mensagem de ‘Número de matrícula 
inválida’ deve ser exibido e cadastro não deve ser realizado. 
o Caso de teste 2.2 
 Descrição: testar comportamento botão com número de 
matrícula de usuário já cadastrado. 
 Pré-condição: campos textbox liberados. 
 Procedimento: Realizar cadastro de um mesmo usuário duas 
vezes 
 Resultado esperado: mensagem de ‘Usuário já cadastrado’ 
deve ser exibido e cadastro não deve ser realizado. 
Localização 3: Tela 3 
 Objeto de teste 1: botão ‘excluir’ 
o Caso de teste 1.1: 
 Descrição: Testar comportamento botão excluir quando não há 
cadastros selecionados. 
 Pré-condição: tela de cadastros estar aberta 
 Procedimento: Testar a exclusão de cadastro sem selecionar 
nenhum cadastro. 
 Resultado esperado: botão excluir retornar mensagem ‘não há 
cadastros selecionados’ e não executar. 
o Caso de teste 1.2: 
 Descrição: Testar comportamento botão excluir quando há 
cadastros selecionados. 
 Pré-condição: tela de cadastros estar aberta 
 Procedimento: Testar a exclusão de cadastro com vários 
cadastros selecionados. 
 Resultado esperado: botão excluir retornar mensagem ‘deseja 
excluir cadastro(s) selecionado(s)?’ após confirmação, 
cadastros devem ser excluídos. 
Localização 4: Tela 4 
 Objeto de teste 1: botão ‘reservar’ 
o Caso de teste 1.1: 
 Descrição: Testar comportamento botão reservar quando não 
há equipamentos selecionados. 
 Pré-condição: tela de equipamentos estar aberta 
 Procedimento: Testar a reserva de equipamento sem 
selecionar nenhum equipamento. 
 Resultado esperado: botão reserva retornar mensagem ‘Favor 
selecionar um equipamento’ e não executar. 
 
o Caso de teste 1.2: 
 Descrição: Testar comportamento botão reserva quando há 
equipamentos selecionados. 
 Pré-condição: tela de equipamentos estar aberta 
 Procedimento: Testar a reserva de cadastro com vários 
equipamentos selecionados. 
 Resultado esperado: botão reservar retornar mensagem 
‘deseja reservar equipamentos(s) selecionado(s)?’ após 
confirmação, cadastros devem ser reservados. 
o Caso de teste 1.3: 
 Descrição: Testar comportamento botão reservar quando não 
há usuários selecionados. 
 Pré-condição: tela de equipamentos estar aberta 
 Procedimento: Testar a reserva de equipamento sem 
selecionar nenhum usuário. 
 Resultado esperado: botão reserva retornar mensagem ‘Favor 
selecionar um usuário cadastrado’ e não executar. 
o Caso de teste 1.4: 
 Descrição: Testar comportamento botão reservar quando 
equipamento selecionado não estiver disponível. 
 Pré-condição: tela de equipamentos estar aberta 
 Procedimento: Testar a reserva de equipamento ele estando 
reservado por outro usuário. 
 Resultado esperado: botão reserva retornar mensagem ‘Favor 
selecionar um equipamento’ e não executar 
 
 
 
Economia e Mercado 
Agentes Econômicos 
 
 Os agentes econômicos que estão influenciam diretamente na empresa são (i) 
empresas, sendo essas as maiores requerentes de serviços para a Rammsoft. Por ser uma 
empresa de software, não existe estoque de mercadorias a serem negociados, todo o 
produto comercializado pela empresa depende diretamente de da produção e manutenção 
fornecida por seus funcionários. Portanto, as (ii) famílias dos funcionários também são 
agentes econômicos que atuam indiretamente com a empresa, com suas demandas de 
poder de compra. O (iii) governo é um agente econômico de atua diretamente com a 
empresa, por meio de empresas públicas que captam recursos através de impostos sob 
serviço e trabalho (exemplo INSS). 
 
Viabilidade Econômica 
 
 Projeção de custos, despesas e investimentos 
 
 Para a produção e desenvolvimento do software, serão utilizadas as estruturas atuais 
da empresa, sendo necessária somente a manutenção da estrutura atual. Entrará na 
projeção de despesas do projeto, somente gastos fixos de funcionamento, como aluguel, 
luz, água, internet, limpeza e pagamento de pessoal, a projeção de gastos está descrita na 
tabela 6. O desenvolvedor 2 só entrará no projeto na fase de testes, tanto para realizar 
testes como desenvolver testes para projeto. A projeção des despesas foi feita com base em 
rateios dos custos mensais, dividindo-os pelo número de projetos que a empresa tem 
durante os meses de duração do projeto. O projeto Colégio Vencer Sempre foi planejado 
para dois meses de desenvolvimento, com um mês adicional de testes e ajustes, totalizando 
três meses. Nesses três meses de desenvolvimento do projeto, a empresa Rammsoft está 
executando mais três projetos de desenvolvimento, fazendo com que o rateio seja feito entre 
os quatro projetos (Tabela 8). 
 
Gastos/Mês 1 2 3 
Rateio Luz R$ 225,00 R$ 225,00 R$ 225,00 
Rateio Água R$ 175,00 R$ 175,00 R$ 175,00 
Rateio Aluguel R$ 375,00 R$ 375,00 R$ 375,00 
Folha de pagamento* R$ 4.025,00 R$ 4.025,00 R$ 4.625,00 
Total R$ 4.800,00 R$ 4.800,00 R$ 5.600,00 
Tabela 6: Projeção de gastos. 
 
 O gasto denominado ‘folha de pagamento’ compreende todos os pagamentos, 
inclusive os pagamentos rateados entre os projetos (Tabela 7 e Tabela 8). 
 
Folha de pagamentos 
 1 2 3 
Desenvolvedor 1 2.500,00 2.500,00 2.500,00 
Desenvolvedor 2 (rateio) 3.200,00 (/4) 
Gerente geral (rateio) 5.000,00 (/4) 5.000,00 (/4) 5.000,00 (/4) 
Limpeza (rateio) 1.250,00 (/4) 1.250,00 (/4) 1.250,00 (/4) 
Tabela 7: Detalhamento da folha de pagamentos. 
 
 
Valores totais 
Luz R$ 900,00 
Água R$ 700,00 
Aluguel RS 1.500,00 
Tabela 8: Valores totais utilizados no rateio de gastos. 
 
Cronograma e Investimento 
 
 O cronograma de desenvolvimento foi criado baseado nos processos presentes no 
MPS.BR, levando em consideração um desenvolvedor trabalhando full-time no projeto, com 
o auxilio de um desenvolvedor sênior na fase de testes. 
 
 
s
1 
s
2 
s
3 
s
4 
s
5 
s
6 
s
7 
s
8 
s
9 
s 
10 
s 
11 
s 
12 
Levantamento de requisitos x x x 
Organização e planejamento de fases x x x 
Codificação x x x x x x 
Testes x x x x x 
Finalização x x x 
Tabela 9: Cronograma simplificado de desenvolvimento de software. 
 
Levando em consideração todos os custos do projeto, o valor estimado de 
investimento por parte do colégio Vencer Sempre será de R$ 8.500,00. Podendo este ser 
feito em duas parcelas, 50% do valor de entrada e 50% do valor na entrega do projeto. 
Programação Orientada a objetos 
 
Classes e Objetos 
 
 O conceito de orientação objeto está relacionado com o conceito de classificar, 
organizar e abstrair coisas. A classe é um agrupamento de objetos que possuem 
semelhanças entre si, tanto estrutural quanto funcional. Toda classe possui atributos e 
métodos, sendo os atributos uma característica comum aos objetos da classe e o método 
um conjunto de ações que o mesmo pode realizar (Leite, 2006). As açõesexecutadas pelos 
métodos podem depender dos valores dados, portando, os métodos são estritamente 
ligados aos dados (Leite, 2006) 
 
Herança 
 
 Quando duas ou mais classes compartilham atributos e métodos é possível usar a 
herança para otimizar o código. Por exemplo, se temos uma classe chamada ‘Corsa’ com os 
atributos ‘motor’, ‘volante’ e ‘pedal’, e outra classe chamada ‘Polo’ com os mesmos atributos, 
podemos criar uma classe chama ‘Automóvel’ que contenha a semelhança entre as duas 
classes, fazendo com que ‘Corsa’ e ‘Polo’ herdem os atributos de ‘Automóvel’, desta 
maneira pode-se dizer que ‘Corsa’ e ‘Polo’ são subclasses de ‘Automóvel’ e esta a 
superclasse. Também existe a possibilidade de redefinir os métodos herdados pela 
subclasse, ou seja, refazer a sua implementação, o que é chamado de sobrescrita ou 
overriding. 
Polimorfismo 
 
 Segundo Ferrerira e Jarabeck (2006) um exemplo didático de polimorfismo é dado 
por um moedor de carne. Esse equipamento tem a função de moer carne, não importa o tipo 
(classe) de carne que você utilize o resultado sempre será carne moída. Portanto, o 
polimorfismo pode ser definido como um código que pode ser aplicado a várias classes de 
objeto. A mesma mensagem é transmitida a objetos de classes distintas e eles poderão 
reagir de maneiras diferentes. 
 
Programa Colégio Vencer Sempre 
 
 As classes, objetos e seus atributos estão representados na imagem abaixo (Imagem 
1). 
 
 
Imagem 1: Classes e Objetos. 
 
 No software de reserva de equipamentos desenvolvido para o colégio Vencer 
Sempre, podemos utilizar a herança para aproveitar os atributos e métodos da classe 
‘Usuário admin’ na classe ‘Usuário’ retirando somente os métodos ‘Cadastrar ’ e ‘Excluir’ 
Interface com Usuário 
 
 Os protótipos de telas foram desenvolvidos utilizando Visual Studio 2019 (Microsoft). 
Tela 1 
 
 A tela 1 é a tela onde o usuário fará o registro dos equipamentos disponíveis, mas 
antes terá de fazer login com usuário e senha (usuário admin). 
 
 
Imagem 2: Tela de login da aba Cadastro equipamento. 
 
Após login, a tela de cadastro de equipamentos ficará disponível. 
 
 
Imagem 3: Tela de cadastro de equipamento, com mensagem de cadastro realizado com 
sucesso. 
 A tela de cadastro de equipamento pode apresentar os seguintes erros: 
 
1- Equipamento já cadastrado. 
 
Imagem 4: Mensagem de erro de equipamento já cadastrado. 
 
2- Favor preencher *campo*. 
 
Imagem 5: Mensagem de erro de campo não preenchido. 
 
Tela 2 
 
 A tela 2 é destinada ao cadastro dos usuários. Também é necessário realizar login 
para acessar essa página (imagem 6). 
 
 
Imagem 6: Tela de login da aba Cadastro Funcionário. 
 
 Após login com usuário e senha, a tela de cadastro de usuário é liberada (imagem 7). 
 
Imagem 7: Tela de cadastro de usuário com mensagem de usuário cadastrado. 
 
A tela de cadastro de usuário pode apresentar os seguintes erros: 
1- Erro de matrícula inválida 
Quando uma matrícula invalida é inserida no campo ‘matricula funcionário’ a seguinte 
mensagem é apresentada: 
 
 
 
Imagem 8: Tela de cadastro de funcionários com erro de matrícula inválida, note que há 
uma vírgula no final do número de matrícula. 
 
2- Erro de ‘Usuário já cadastrado’ 
Quando um usuário já cadastrado é inserido no sistema, o programa apresenta o 
seguinte erro: 
 
Imagem 9: tela de cadastro de usuário com erro de ‘Usuário já cadastrado’. 
 
Tela 3 
 
 A tela 3 se destina a campos com usuários e equipamentos cadastrados, além da 
exclusão de equipamentos e usuários. Também é necessário realizar login nessa tela 
(Imagem 10). 
 
 
Imagem 10: Tela de login para acessar aba itens cadastrados. 
 
 Após o cadastro, a tela de itens cadastrados é liberada (Imagem 11). 
 
Imagem 11: Tela de itens cadastrados com mensagem de confirmação de exclusão. 
 
A tela 3 pode apresentar o seguinte erro: 
1- Erro ao excluir item. 
Para excluir um item, este deve ser selecionado na checklistbox. Se não houver algo 
selecionado, o programa retorna a seguinte mensagem (Imagem 12). 
 
 
Imagem 12: tela de itens cadastrados com erro de exclusão por não atender aos critérios do 
botão. 
 
Tela 4 
 
 A tela 4 é destinada a reserva de equipamentos pelos funcionários, não é necessário 
login para acessar essa tela (Imagem 13, 14, 15 e 16). 
 
 
Imagem 13: tela de reserva de equipamento com mensagem de reserva efetuada com 
sucesso. 
 
 
Imagem 14: Tela de reserva de equipamento mostrando detalhe do calendário para seleção 
de datas. 
 
Imagem 13: Tela de reserva de equipamentos com detalhe do combobox para seleção de 
local. 
 
 
Imagem 14: Tela de reserva de equipamentos com detalhe do combobox para escolha de 
usuário. 
 
 A tela 4 pode apresentar os seguintes erros: 
1- Erro de equipamento não disponível. 
Quando o equipamento selecionado não está disponível para a data e hora selecionados 
o programa retorna a seguinte mensagem (Imagem 15). 
 
 
 
Imagem 15: Tela 4 com erro de equipamento não disponível. 
 
2- Erro de seleção de usuário. 
Quando o usuário não seleciona um usuário para a reserva, a seguinte mensagem é 
apresentada (Imagem 16). 
 
Imagem 17: Tela 4 com mensagem de erro quando usuário não é selecionado. 
3 – Erro de seleção de equipamento. 
 Quando o usuário não seleciona o equipamento, o sistema apresenta o seguinte erro 
(imagem 18). 
 
 
Imagem 18: Tela 4 com mensagem de erro de seleção de equipamento. 
 
 
Tela 5 
 
 Esta interface fica disponível a todos os usuários para que estes possam conferir a 
disponibilidade dos equipamentos (imagem 19). 
 
 
Imagem 19: Tela de verificação de reservas. 
 
Conclusão 
 
 Este trabalho permitiu uma percepção realista de quão complexo é a criação de um 
software sob demanda com interfaces, a precificação do serviço e a elaboração de testes 
que permitam uma maior segurança no lançamento do programa. Apesar de haver uma 
limitação quanto ao conhecimento técnico de alguns tópicos, devido ao período letivo que 
esse trabalho foi desenvolvido, a execução do trabalho foi possível e demonstrou que todas 
as etapas de desenvolvimento são igualmente importantes e devem ser realizadas com 
planejamento e organização. Por isso, para que a execução do projeto obedeça aos 
cronogramas de tempo e custos, além de o produto ser de boa qualidade, planejamento e 
gestão competente são de vital importância. 
 
 
 
 
 
 
 
 
 
 
 
Referências 
 
Vazquez, Carlos; Simões, Guilherme. Engenharia de Requisitos: Software Orientado ao 
Negócio. Brasport, 2016. 
 
Ferreira, Marcelo; Jarabeck, Flávio. CA Visual Objects - O Livro, São Paulo, Express, 1995. 
 
Leite, Milton. Tecnicas de programação: uma abordagem moderna Rio de Janeiro Brasport 
2006. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Apêndice I 
 
Relatório de testes 
 
Projeto 
Reserva Escola Vencer Sempre 
 
Objetivos 
Testes de usabilidade e testes de interface. 
 
Testes 
Foram realizados testes de acordo com o roteiro de testes. 
 
Localização 1: Tela 1 
Caso de teste 1 - Teste de campos textbox para caracteres especiais. 
 O teste foi realizado um total de 5 vezes, testando os caracteres especiais til (~), 
acento circunflexo (^), acento agudo (´), crase (`), hífen (-) e igual (=). Somente 1 teste teve 
resultado diferente do esperado (=), e a correção foi efetuada. 
 Resultado esperado: Imagem 3 
 
 Caso de teste 2.1 – Comportamento botão cadastrar com campo textbox vazio. 
 O teste foi realizado em todos os campos textbox e nenhum erro foi encontrado. 
 Resultado esperado: Imagem 5 
 
 Caso de teste 2.2 – Comportamento botão cadastrar com equipamento já 
cadastrado. 
 O teste foi realizado 5 vezes, com 5 cadastros diferentes e não foram encontrados 
erros. 
 Resultado esperado: Imagem 4 
 
 Caso de teste 2.3 – Comportamento botão cadastrar novo cadastroO teste foi realizado 10 vezes, e nenhum erro foi encontrado. 
 Resultado esperado: Imagem 3 
Localização 2: Tela 2 
 Caso de teste 1.1 – Campos textbox para caracteres especiais 
O teste foi realizado um total de 5 vezes, testando os caracteres especiais til (~), 
acento circunflexo (^), acento agudo (´), crase (`), hífen (-) e igual (=). Somente 1 teste teve 
resultado diferente do esperado (=), e a correção foi efetuada. 
 Resultado esperado: Imagem 7 
 
 Caso de teste 2.1 – Comportamento botão com matrícula inválida 
 O teste foi realizado 10 vezes, com 3 resultados diferentes do esperado, sendo que o 
sistema aceitou os caracteres ‘-’. Erro foi corrigido. 
 Resultado esperado: Imagem 8 
 
 Caso de teste 2.2 – Comportamento botão com número de matrícula já cadastrado. 
 O teste foi realizado 5 vezes, sem nenhum erro. 
Resultado esperado: Imagem 9 
 
Localização 3: Tela 3 
 Caso de teste 1.1 – testar comportamento bota excluir quando não há itens 
selecionados. 
 O teste foi realizado 8 vezes, nos três primeiros testes a mensagem de erro não foi 
exibida, o erro foi corrigido e foram realizados mais 5 testes. 
 Resultado esperado: Imagem 12 
 
 Caso de teste 1.2 – Comportamento do botão quando há itens selecionados. 
 O teste foi realizado 5 vezes, sem nenhum erro. 
 Resultado esperado: Imagem 11 
 
Localização 4; Tela 4 
 Caso de teste 1.1 – Testar comportamento do botão reservar quando não há 
equipamentos selecionados 
 O teste foi realizado 5 vezes e nenhum erro foi encontrado. 
 Resultado esperado: Imagem 18 
 
 Caso de teste 1.2 – Testar botão reserva 
 O teste foi realizado 10 vezes, nenhum erro foi encontrado. 
 Resultado esperado: Imagem 14 
 
 Caso de teste 1.3 – testar comportamento botão reservar quando não há usuários 
selecionados. 
 O teste foi realizado 15 vezes no total. Incialmente o botão reservar efetuava a 
reserva sem que houvesse um usuário selecionado, o erro foi corrigido. 
 Resultado esperado: Imagem 17 
 
 Caso de teste 1.4 – testar comportamento botão reservar quando não há 
disponibilidade do equipamento 
 O teste foi realizado 5 vezes, e nenhum erro foi detectado. 
 Resultado esperado Imagem 15