Projeto Reserva de Equipamentos

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar V 
 Tecnologia em Análise e Desenvolvimento de Sistemas 
 
 
 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
 
 
 
 
SISTEMA DE RESERVA DE EQUIPAMENTOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
São Paulo 
2022 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
NOME DO ALUNO – RA: 0000000 
 
 
 
 
SISTEMA DE RESERVA DE EQUIPAMENTOS 
Projeto Integrado Multidisciplinar V 
 
 
 
Projeto Integrado Multidisciplinar V para obtenção 
do título de tecnólogo em Análise e 
Desenvolvimento de Sistemas, apresentado à 
Universidade Paulista – UNIP EaD. 
 
 
Orientador(a): Prof. Diego Rocha. 
 
 
 
 
 
 
 
 
 
 
 
São Paulo 
2022 
RESUMO 
 
O Colégio Vencer Sempre, instituição fictícia alvo deste projeto, disponibiliza 
equipamentos de informática e vídeo (tais como datashow, TV com VCR, TV com DVD, 
Projetor de Slides, Sistemas de Áudio-Microfone, Caixa Amplificada, Notebooks, Kits 
Multimídia etc.), como ferramentas de apoio para aulas e palestras, aos professores 
e coordenadores da instituição, alocando-os em salas de aula e auditórios, a pedido 
antecipado dos colaboradores. O objetivo geral desse trabalho foi desenvolver o 
projeto de um Sistema de reserva de equipamentos audiovisuais, a fim de agilizar e 
controlar o empréstimo de equipamentos e recursos de apoio aos professores de 
colégios de Ensino Fundamental e Médio. O projeto visou principalmente a união do 
conteúdo teórico com a prática das disciplinas de Economia e Mercado, Engenharia 
de Software II, Projeto de Interface com o Usuário e Programação Orientada a Objetos. 
Neste trabalho foram detalhados os processos para desenvolvimento do sistema de 
agendamento, além da prototipação, requisitos funcionais e não-funcionais, regras de 
negócio, testes e agentes econômicos. Pode-se dizer que os objetivos foram 
alcançados, levando os alunos ao crescimento acadêmico inerente a esta proposta 
de trabalho. 
 
Palavra-chave: Economia e Mercado; Engenharia de Software II; Projeto de Interface 
de Usuários; Programação orientada a objetos. 
 
ABSTRACT 
 
The Colégio Vencer Sempre, a fictitious institution that is the target of this project, 
provides computer and video equipment (such as datashow, TV with VCR, TV with 
DVD, Slide Projector, Audio-Microphone Systems, Amplified Box, Notebooks, Multi-
media Kits, etc.), as support tools for classes and lectures, to professors and coordi-
nators of the institution, allocating them in classrooms and auditoriums, at the advance 
request of employees. The general objective of this work was to develop the project of 
an audiovisual equipment reservation system, in order to speed up and control the loan 
of equipment and support resources to teachers of elementary and high schools. The 
project aimed mainly at the union of theoretical content with the practice of the subjects 
of Economics and Market, Software Engineering II, User Interface Design and Object 
Oriented Programming. In this work, the processes for developing the scheduling sys-
tem were detailed, in addition to prototyping, functional and non-functional require-
ments, business rules, tests and economic agents. It can be said that the objectives 
were achieved, leading the students to the academic growth inherent to this work pro-
posal. 
 
Keywords: Economy and Market; Software Engineering II; User Interface Design; 
Object-oriented programming. 
SUMÁRIO 
 
1 INTRODUÇÃO .................................................................................................. 5 
2 DSENVOLVIMENTO ......................................................................................... 6 
2.1 Ciclo de Vida .................................................................................................... 6 
2.1.1 Fases ................................................................................................................ 6 
2.1.2 Modelos............................................................................................................. 7 
2.1.3 Requisitos funcionais ....................................................................................... 10 
2.1.4 Requisitos de Negócio ..................................................................................... 11 
2.2 Modelagem da solução com orientação a objetos ...................................... 11 
2.2.1 Abstração ......................................................................................................... 11 
2.2.2 Encapsulamento .............................................................................................. 12 
2.2.3 Herança............................................................................................................ 12 
2.2.4 Polimorfismo .................................................................................................... 13 
2.3 Interface do Usuário ...................................................................................... 14 
2.4 Rotina de Testes ............................................................................................. 17 
2.5 Viabilidade econômica ................................................................................... 20 
2.5.1 Custo do Projeto .............................................................................................. 20 
3 CONSIDERAÇÕES FINAIS ............................................................................. 22 
 REFERÊNCIAS ............................................................................................... 23 
5 
 
1 INTRODUÇÃO 
 
 O Projeto Integrado Multidisciplinar (PIM) é uma proposta da UNIP que possui 
como objetivo a apresentação de um trabalho prático que una a teoria aprendida nas 
disciplinas cursadas durante o bimestre. O PIM V de Análise e Desenvolvimento de 
Sistemas é composto pelas disciplinas de Economia e Mercado, Engenharia de 
Software II, Projeto de Interface de Usuários e Programação orientada a objetos. 
Neste PIM, um sistema de agendamento de objetos escolares deverá ser criado para 
o Colégio Vencer Sempre, instituição fictícia criada para a proposta. 
 O Colégio Vencer Sempre possui alunos do ensino fundamental e médio e 
disponibiliza equipamentos de informática e vídeo (tais como datashow, TV com VCR, 
TV com DVD, Projetor de Slides, Sistemas de Áudio-Microfone, Caixa Amplificada, 
Notebooks, Kits Multimídia etc.) para que os professores e palestrantes possam 
complementar o ensino e a oratória. Estes instrumentos de apoio são geralmente 
agendados com antecedência e conferidos no momento da devolução, porém a escola 
não conta ainda com um sistema informatizado para controle destes empréstimos e 
agendamentos equipamentos e recursos audiovisuais, o que poderia agilizar e 
controlar os empréstimos. 
 Assim, o objetivo principal deste trabalho é apresentar uma proposta de 
software que atenda a esta demanda, auxilie no controle do empréstimo e devolução 
de equipamentos de informática e vídeo da escola e com o auxílio das disciplinas base, 
de seu conteúdo teórico e de uma pesquisa bibliográfica prévia detalhar a viabilidade 
econômica deste projeto, prazos, requisitos funcionais, não funcionais e de negócios 
envolvidos, metodologias, roteiro de testes, entre outros itens importantes na 
composição do projeto e aprendidos durante as disciplinas. 
 Espera-se que este projeto possa inspirar os profissionais de tecnologia 
relacionados à área de educação para que proporcionem às escolas públicas e 
privadas um serviço semelhante, auxiliando no processo de gerenciamento de seus 
equipamentos. 
 
6 
 
2 DESENVOLVIMENTO 
 
2.1 Ciclo de VidaO ciclo de vida do Software é a estrutura que contem os processos, atividades 
e tarefas envolvidas no desenvolvimento, no gerenciamento e manutenção de um 
produto de software, abarcando a vida do sistema, a demarcação de suas condições 
e o término de seu uso. A definição do modelo de ciclo de vida é o primeiro passo no 
processo de criação de um programa. A partir disto é que será definida a melhor forma 
de atender aos pedidos do cliente, bem como os prazos para entrega da primeira 
versão. 
 
2.1.1 Fases 
 
As fases do ciclo de vida do software são representadas na figura a seguir: 
Figura 1: fases do ciclo de vida do desenvolvimento de software 
 
Fonte: autores, 2022. 
A fase de reunião com o cliente é a primeira, pois é nesta fase em que serão 
discutidas as necessidades e as especificidades do projeto, como público e o objetivo. 
A partir daí pode-se discutir e levantar os requisitos mínimos a fim de definir o modelo 
Reunião com o 
Cliente
Fase de 
Requisitos
Fase de projeto
Fase de 
implementação
Fase de testes
Fase de 
produção
7 
 
que será utilizado. A fase de projeto é quando será realizada a concepção, 
especificação, design da interface prototipação e design da arquitetura. 
O momento em que todas as funcionalidades definidas nas fases anteriores 
são traduzidas em linguagem de programação é a fase de implementação e em 
seguida são realizados os testes necessários para conferir o funcionamento do que 
foi desenvolvido. Por fim, na fase de produção ocorre a implantação do produto final. 
 
2.1.2 Modelos 
 
Os modelos de ciclo de vida proporcionam uma maior organização ao processo 
de desenvolvimento, fazendo com que a equipe possa seguir métodos de 
aplicabilidade no momento de desenvolver um programa. Os modelos mais utilizados 
são: 
a) Modelo em cascata: é o modelo mais antigo, cujas atividades fundamentais são 
a análise e definição de requisitos, projeto, implementação, teste e integração. 
O nome do modelo foi dado devido à sequência das fases, pois cada uma inicia 
somente quando a anterior é finalizada e o resultado da fase anterior é como 
entrada para a fase atual (o fim de cada fase resulta em um documento 
aprovado). Nesse modelo, a ênfase maior é dada para as fases de análise e 
projeto antes mesmo de seguir para a programação, para que haja definição 
clara do objetivo do software e retrabalhos sejam evitados. A figura 2 apresenta 
o modelo em cascata: 
Figura 2: Modelo em cascata 
 
Fonte: devmedia.com.br 
8 
 
b) Modelo em V: Tem como característica principal a evidência dada à verificação 
e validação, pois as fases do lado esquerdo geram um plano de teste que será 
cumprido no lado direito. Assim como no modelo em cascata, o cliente somente 
recebe a primeira versão do programa ao final do ciclo, a diferença é que 
apresenta menos risco, devido à existência do projeto prévio dos testes nas 
fases de análise e projeto. 
Figura 3: Modelo em V 
 
Fonte: devmedia.com.br 
 
c) Modelo Incremental: Neste modelo, são obtidos os requisitos do cliente e 
reunidos os módulos de acordo com a sua funcionalidade. Após esta junção, a 
equipe e o cliente definem a prioridade de desenvolvimento dos módulos de 
acordo com a importância de cada funcionalidade para o negócio do cliente. 
Figura 4: Modelo incremental 
 
Fonte: devmedia.com.br 
d) Modelo evolutivo: Este modelo parte da ideia de que o cliente não expõe todos 
os requisitos, que eles não sejam bem conhecidos ou que estejam passando 
por mudanças. Assim, a análise é feita com base nos requisitos que já se têm 
até então, com a primeira versão sendo entregues ao cliente. O cliente utiliza o 
9 
 
programa em seu ambiente operacional, e a partir do uso desta primeira versão 
esclarece o que não foi bem compreendido e fornece informações que delimi-
tem o software até estar como se deseja. 
Figura 5: Modelo evolutivo 
 
Fonte: devmedia.com.br 
e) Modelo Prototipagem: prototipagem é a montagem de um esboço do que foi 
entendido a partir do pedido do cliente. A prototipagem tanto pode ser conside-
rada um ciclo de vida como uma ferramenta em outros modelos de ciclo. Este 
esboço ou protótipo em engenharia de software pode ser o desenho de uma 
tela ou um software contendo algumas funcionalidades do sistema final. Se já 
puderem ser utilizados pelos clientes em produção podem ser considerados 
como operacionais, ou serão chamados não operacionais se ainda não pude-
rem ser utilizados. No fim, poderão ser rejeitados, ou reutilizados buscando 
evolução até a versão final. 
Figura 6: Modelo prototipagem 
 
Fonte: devmedia.com.br 
10 
 
f) Modelo ágil: Junto com o framework Scrum, este foi o modelo escolhido para 
este projeto, que se destaca por ser desenvolvido com base em uma aborda-
gem de planejamento incremental e muito interativa. Seu desenvolvimento é 
composto por um mini-projeto de aproximadamente quatro semanas de dura-
ção, entre todas as fases do ciclo. Ao fim de cada mini-projeto, o cliente recebe 
para apreciação o montante de novas funcionalidades, que são aperfeiçoadas, 
incluídas ou excluídas de acordo com o feedback. O modelo Scrum é um dos 
principais frameworks para este modelo, e é baseado em transparência, inspe-
ção e adaptação. O framework Scrum possui um profissional que valida e tra-
mita os fundamentos do framework na equipe de desenvolvimento, o Scrum 
Master. 
Figura 7: Modelo ágil 
 
Fonte: devmedia.com.br 
 
2.1.3 Requisitos funcionais 
 
O requisito funcional é a exigência ou pedido de certa funcionalidade que um 
programa deve atender e que é especificado desde o início do desenvolvimento do 
software. Os requisitos de um programa dependerão do que o cliente necessita. No 
caso deste projeto, foram especificados sete requisitos funcionais, a saber: 
• ID 1 - Realização de cadastro de novos usuários: necessária para utilização do 
sistema 
• ID 2 - Efetuar Login: Para autenticar os usuários cadastrados e permitir as ope-
rações na parte restrita do sistema. 
• ID 3 - Realização de reservas: de acordo com a data e hora escolhidos pelo 
usuário. 
• ID 4 - Consultar reservas: O sistema deverá listar as reservas já realizadas para 
que o usuário possa consultar e modificar. 
11 
 
• ID 5 - Cadastro e controle dos equipamentos: O administrador poderá incluir 
equipamentos e controlar todo o sistema. 
• ID 6 - Níveis de acesso: As funções executadas pelo sistema obedecerão a 
dois níveis- o nível 1 para o usuário comum e o nível 2 para o administrador. 
• ID 7 - Ajuda: aba disponibilizada com tópicos para auxiliar o usuário. 
 
2.1.4 Requisitos de Negócio 
 
São as regras de negócio que definirão a forma como o sistema atenderá às 
necessidades do cliente, definidas previamente. Assim, ela pode ser entendida como 
a forma como um requisito funcional será atendido. Para o sistema do Colégio Vencer 
Sempre, a regra de empréstimo e devolução de equipamentos de mídia seguirá a 
seguinte regra: 
• Só poderá retirar o equipamento aquela pessoa que se identificar com RG e ID 
do sistema, ou autorização assinada para terceiros. O mesmo deverá ocorrer 
no caso de devolução do equipamento. 
 
2.2 Modelagem da solução com orientação a objetos 
 
Existem muitas maneiras de realizar programação. Estas diferentes maneiras 
são conhecidas como paradigmas de programação. Entre estes paradigmas pode-se 
citar a Programação Orientada a Objetos (POO) que é utilizada na maioria dos siste-
mas atuais e suportada por um grande número de linguagens. A POO se faz presente 
nas fases de análise, levantamento e projeto. Assim, falar em Orientação a Objetos 
requer um conceito que vá além do código. Para ser considerada neste paradigma, a 
linguagem deve atender a quatro tópicos imprescindíveis, a saber: abstração, 
 
2.2.1 Abstração 
 
A abstração é um ponto imprescindível quando se fala em POO. Como se trata 
da representação de um objeto, é preciso terem mente a ação deste objeto dentro 
sistema e três pontos são importantes: a identidade do que está sendo criado, as ca-
12 
 
racterísticas do objeto e as ações que o objeto deverá executar, ou método. A identi-
dade deve ser única para não haver conflito e para tal a identidade real de cada objeto 
se dá por 
 <nome_do_pacote>.<nome_do_objeto>.</nome_do_objeto></nome_do_pacote>. 
Com relação às características do objeto, na POO elas são chamadas de pro-
priedade. Por exemplo, as propriedades de um objeto “gato” podem ser “peso”, “raça”, 
“tamanho”. Já o método trata das ações que serão executadas pelo objeto. Os méto-
dos podem ser variáveis como “Apagar()” em um objeto lâmpada até “Miar()” em um 
objeto gato. 
 
2.2.2 Encapsulamento 
 
Esta é uma das principais técnicas que podem definir a POO. Trata-se de um 
elemento que pode adicionar segurança à POO por funcionar como uma caixa preta 
e esconder as propriedades. A maioria das Linguagens Orientadas a Objetos imple-
mentam esta técnica com base em propriedades privadas com ligação a métodos es-
peciais conhecidos como getters e setters, que irão retornar e setar o valor da propri-
edade, respectivamente. Isto evita o acesso à propriedade do objeto, incluindo mais 
uma camada de segurança à aplicação. Por exemplo, quando alguém aperta o botão 
para ligar um rádio, não é possível saber o que está acontecendo internamente, então 
pode-se dizer que os métodos que ligam o rádio estão encapsulados. 
 
2.2.3 Herança 
 
Pode-se dizer que o reuso de código é uma boa vantagem da POO em partes 
por uma questão que é conhecida como herança. Na orientação a objetos, a herança 
ocorre como numa herança familiar. O objeto abaixo na hierarquia irá herdar caracte-
rísticas dos objetos acima dele. A herança direta é aquela herdada das características 
do objeto mais acima enquanto as outras são consideradas heranças indiretas. 
A herança muda muito entre as linguagens. Em algumas existe a herança múl-
tipla, que é o objeto herdar características de muitos objetos acima da hierarquia, si-
multânea e diretamente pois cada objeto pode possuir quantos “pais” for necessário. 
 
 
13 
 
2.2.4 Polimorfismo 
 
Como foi dito, os objetos recebem as características e ações de seus “ances-
trais”. Porém, em certos casos as ações para um mesmo método precisam ser dife-
rentes e o polimorfismo é quando o sistema tem uma alteração no funcionamento 
interno de um método recebido de um objeto ancestral. 
As várias linguagens de programação implementam o polimorfismo de manei-
ras distintas. O C#, por exemplo, utiliza métodos virtuais possíveis de serem reimple-
mentados nas classes filhas. Já em Java, só o atributo “@Override” já é o suficiente. 
A figura 8 apresenta as classes de entidades de negócio do sistema para o colégio. 
Foi definida a classe Pessoa, herdada pelas classes filhas UsuarioComum e Usuario-
Administrador, desta forma, obtém-se o polimorfismo dos métodos e atributos co-
muns. As demais classes que foram definidas estão em composição, obedecendo a 
regra de tem um (Painel Reserva e Painel equipamento) e tem vários (Reserva e Equi-
pamento). Também foi adotado o nome classe UsuárioComum e Usuário Administra-
dor a fim de permitir certas funções a partir do nível de acesso do usuário. 
Figura 8: Diagrama de classes 
 
Fonte: autores, 2022. 
14 
 
 
2.3 Interface do Usuário 
 
É importante que o sistema apresente um bom design, que seja simplificado, 
demonstre elegância, beleza, etc. Assim, neste projeto a navegação será de usabili-
dade mais simples, de fácil acesso com o mouse, teclado ou telas touch screen. O 
design das interfaces será fluido, para que se adapte aos diversos tamanhos de mo-
nitores encontrados no mercado. 
O projeto conta ainda com botões grandes, para facilitar o uso de usuários por 
meio do touch screen. Os textos e imagens também precisam ser fluidos para que a 
visualização seja padronizada independente do ambiente. Com relação aos textos, as 
telas principais terão uma redução de informações, pois isto evita poluição visual. Mai-
ores informações estarão concentradas na aba “Ajuda”. As figuras a seguir mostram 
um protótipo do sistema. 
Figura 9: Tela de Login 
 
Fonte: autores, 2022. 
 
15 
 
Figura 10: Tela de Reservas 
 
Fonte: autores, 2022. 
Figura 11: Tela de Buscas 
 
Fonte: autores, 2022. 
 
16 
 
Figura 12: Reservas 
 
Fonte: autores, 2022. 
Figura 13: Busca de Reserva 
 
Fonte: autores, 2022. 
 
17 
 
Figura 14: Busca de Equipamentos 
 
Fonte: autores, 2022. 
Figura 15: Ajuda 
 
Fonte: autores, 2022. 
 
2.4 Rotina de Testes 
 
O analista é o integrante do time de desenvolvimento que garante o funciona-
mento adequado do software de acordo com os requisitos. Além disto, o analista de 
qualidade auxilia a equipe desenvolvedora a diminuir os prejuízos e otimizar o tempo 
18 
 
trazendo à tona falhas existentes e antevendo possíveis falhas. Existem recomenda-
ções de que haja um esforço de testes em torno de 30% a 40% de todo o esforço do 
projeto. As tabelas a seguir apresentam os casos de uso para teste: 
Quadro 1: UC Valida Login 
Nome: Valida Login 
Ator: Usuário 
Pré-condição: Acesso à tela inicial do programa 
Fluxo Principal: 1. Abrir a tela inicial 
2. Inserir nome de usuário e senha 
3. Clicar no botão entrar 
4. Usuário apto entra no sistema 
5. Término do UC 
Fluxo Secundário: 3.1. O usuário pode não entrar no sistema 
3.2. O usuário pode inserir login ou senha incorretos 
Pós condição: As informações serão inseridas corretamente e o usuário conseguirá o 
acesso ao sistema. 
Fonte: autores, 2022. 
Quadro 2: UC Reserva de dispositivos 
Nome: Reserva de equipamento 
Ator: Usuário 
Pré-condição: Acesso à tela de reservas 
Fluxo Principal: 1. Abrir a tela de reservas 
2. Escolher o botão ‘nova reserva’ 
3. Buscar o dispositivo por nome, Id ou categoria 
4. Fornecer data e hora 
5. Informações válidas garantem a reserva e o sistema retorna à página 
inicial 
6. Término do UC 
Fluxo Secundário: 5.1. O usuário pode não entrar no sistema 
5.2. O usuário pode inserir login ou senha incorretos 
Pós condição: As informações serão inseridas corretamente e o usuário conseguirá o acesso 
ao sistema. 
Fonte: autores, 2022. 
Quadro 3: UC Consulta de Reservas 
Nome: Busca de Reservas 
Ator: Usuário 
Pré-condição: Acesso à tela de reservas 
Fluxo Principal: 1. Abrir a tela de reservas 
2. Escolher o botão ‘consultar reservas’ 
19 
 
3. Buscar o dispositivo por nome, Id ou categoria 
4. Fornecer data e hora 
5. Informações válidas fazem com que as informações apareçam na tela 
e o sistema retorna às reservas 
6. Término do UC 
Fluxo Secundário: 4.1. O usuário pode não entrar no sistema 
3.1. O usuário pode inserir informações de busca incorretas 
Pós condição: As informações serão inseridas corretamente e o usuário conseguirá o acesso 
às informações 
Fonte: autores, 2022. 
Quadro 4: UC Cadastro de dispositivos 
Nome: Cadastro de equipamentos 
Ator: UsuárioAdministrador 
Pré-condição: Acesso à tela de controle 
Fluxo Principal: 1. Abrir a tela de controle 
2. Escolher o botão ‘cadastro de equipamentos’ 
3. Informar o nome e a categoria do equipamento 
4. Clicar em cadastrar 
5. Informações válidas fazem com que o usuário retorne à tela anterior 
6. Término do UC 
Fluxo Secundário: 4.1. O usuário pode não entrar no sistema 
4.2. O usuário pode inserir informações de cadastro incorretas 
Pós condição: As informações serão inseridas corretamente e o cadastro será realizado 
Fonte: autores, 2022. 
Quadro 5: UC Controle do Sistema 
Nome: Controle do sistema 
Ator: UsuárioAdministrador 
Pré-condição: Acesso à tela de controle 
Fluxo Principal: 1. Abrir a tela de controle 
2. Escolher o botão ‘controle’ 
3. Buscar reservas pelo id do UsuárioAdministrador 
4. Informações válidas fazem com que seja liberado a tela de controle 
5. Términodo UC 
Fluxo Secundá-
rio: 
1.1. O usuário pode não entrar no sistema 
3.1. O usuário pode inserir informações de busca incorretas 
Pós condição: As informações serão inseridas corretamente e o gerenciamento poderá ser re-
alizado 
Fonte: autores, 2022. 
Quadro 6: UC Tela de Ajuda 
Nome: Ajuda 
20 
 
Ator: Usuário 
Pré-condição: Acesso à tela de ajuda 
Fluxo Principal: 1. Abrir a tela de ajuda 
2. Escolher o tópico da dúvida 
3. Informação exibida 
Fluxo Secundário: 2.1. O usuário pode não entrar no sistema 
Pós condição: O sistema exibirá o tópico do tema da ajuda solicitada 
Fonte: autores, 2022. 
 
2.5 Viabilidade econômica 
 
Os autores deste trabalho consideram que foram contratados para realizar este 
projeto para o Colégio Vencer Sempre. Partindo deste princípio, trata-se de uma em-
presa em ascensão e com poucos recursos financeiros disponíveis para obter as dis-
pendiosas certificações de qualidade e maturidade. Apesar de ser um investimento 
alto, uma empresa precisa delas para que cresça em conceito nacional e internacio-
nal. As metodologias de qualidade internacionais como, ISO, CMMI e MPS.BR tem 
ajudado empresas em início de atividades a impulsionarem seus negócios. Por isto, 
esta empresa adotou a MPS.BR, programa que busca a melhora da capacidade de 
desenvolvimento de software, além dos serviços e práticas de gerenciamento para 
empresas que querem crescer em qualidade por um baixo custo de implementação e 
com uma média de duração de 15 meses. 
 
2.5.1 Custo do Projeto 
 
O custo total deste projeto será de R$15.000,00 mensais, com manutenções 
por dois anos. O Software será entregue em 60 dias úteis. A equipe será composta 
por um Scrum Master, quatro programadores, sendo dois do nível júnior, um pleno e 
um sênior, um analista de qualidade e um coordenador de projetos. 
Estes valores são viáveis. Como os custos com a equipe giram em torno de 
R$50.000,00, o valor cobrado de R$15.000,00 mensais fará com que a empresa tenha 
um lucro aproximado de 55%. Os agentes econômicos atuantes diretamente com a 
empresa serão as famílias, visto que a empresa necessita de mão de obra qualificada 
para a produção. Como agente econômico, a empresa criará um bem e serviço e a 
21 
 
partir do capital recebido como pagamento empregos poderão ser gerados, contribu-
indo para a economia e para o crescimento pessoal dos colaboradores. 
 
22 
 
3 CONSIDERAÇÕES FINAIS 
 
Este Projeto Integrado Multidisciplinar foi muito importante para absorver o 
conteúdo das disciplinas estudadas: Economia e Mercado, Engenharia de Software II, 
Projeto de Interface com o Usuário e Programação Orientada a Objetos, 
conhecimento este muito importante para a execução da parte prática do projeto. 
Como resultado de pesquisas aprofundadas, pôde-se desenvolver um 
programa com o objetivo de cadastrar equipamentos de áudio, mídia e vídeo da 
biblioteca do colégio Vencer Sempre, bem como organizar os empréstimos e 
devoluções destes equipamentos. Usando as diretrizes e materiais complementares 
indicados pelo Manual do PIM V, foi possível realizar esta tarefa com sucesso. 
A importância deste trabalho é, em primeiro lugar, complementar a 
aprendizagem dos alunos que criaram este projeto, mas igualmente importante é a 
forma como pode motivar os programadores trabalharem em prol de melhorias na 
educação. Devido a tudo o que foi exposto, considera-se que os objetivos deste 
trabalho foram alcançados. 
 
 
23 
 
REFERÊNCIAS 
 
 CICLOS de vida de um Software. Devmedia, 2021. Disponível em: 
<https://www.devmedia.com.br/ciclos-de-vida-do-software/21099>. Acesso em: 28 
mar. 2022. 
FIGUEIREDO, Eduardo. Requisitos Funcionais e Requisitos Não Funcionais. UFMG, 
s.d. Disponível em: 
<https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/req-funcional-
rnf_v01.pdf>. Acesso em: 01 abr. 2022. 
HENRIQUE, João. Programação Orientada a Objetos e programação estruturada. 
Alura, 23 out. 2019. Disponível em: < https://www.alura.com.br/artigos/poo-
programacao-orientada-a-objetos>. Acesso em: 03 abr. 2022. 
OS 4 Pilares da Programação Orientada a Objetos. Devmedia, 2014. Disponível em: 
<https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-
objetos/9264>. Acesso em: 03 abr. 2022.