Você está na página 1de 32

UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar V

Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

Sistema de Reserva de Multimídia

Campinas – Taquaral – São Paulo

São Caetano do Sul– São Paulo

São Paulo - Vila prudente– São Paulo

Cabo de Santo Agostinho – Pernambuco

Campinas – Swift – São Paulo

ANO 2021
2

UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar IV

Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas

SISMEDIA

Projeto Integrado Multidisciplinar V

Alexandre José da Silva -0586519

Alexandre Murta Rezende – 058104

Felipe de Freitas Souza – 0575988

Júlio Cesar Vieira - 0591317

Matheus Justi Lima - 0577054

Orientador (a):

Professor Luiz Antônio de Lima

Campinas – Taquaral – São Paulo

São Caetano do Sul– São Paulo

São Paulo - Vila prudente– São Paulo

Cabo de Santo Agostinho – Pernambuco

Campinas – Swift – São Paulo

ANO 2021
3

RESUMO

Este trabalho acadêmico tem como objetivo idealiza a criação e contratação


de um software que administrará as reservas de equipamentos audiovisuais
de escolas de ensino fundamental e médio, em especial o “Colégio Vencer
Sempre”, desde o orçamento, previsão de gastos, cronograma de entrega,
dividindo o projeto e suas fases por dia, passando pelas etapas de
levantamento, análise e documentação dos requisitos (funcionais e não
funcionais), prototipação de alta fidelidade, especificação de interfaces, até as
etapas mais técnicas com a codificação em linguagem orientada à objetos,
testes, entrega do produto, e implantação junto ao usuário. No qual esse
software possui o propósito de automatizar, facilitando e organizando toda
dinâmica como os empréstimos de equipamentos audiovisuais e de multimídia
para os professores ministrarem suas aulas. O Software é projetado para que
se obtenha o melhor desempenho e custo-benefício, será documentado todo
o processo e metodologia de software utilizada na implantação do sistema
para obtenção de um produto com qualidade, utilizando a metodologia MPS.br
para obter práticas de engenharia de software, testes (incluindo todo o roteiro,
os casos de sucesso e insucesso, fichas de execução dos testes), negociação
no mercado e pós-venda, com o intuito de crescimento para a recente
empresa de software que procura se consolidar no mercado.

Palavras-chave: Sistema para reservas. Programação orientada à objetos.


Projeto de software. Protótipo. Roteiro de testes. MPS.br.
4

ABSTRACT

This academic work aims to idealize the creation and contracting of software
that will manage the reserves of audiovisual equipment of elementary and high
schools, in particular the “Colégio Vencer Semper”, from the budget,
expenditure forecast, delivery schedule, dividing the project and its phases by
day, going through the steps of surveying, analyzing and documenting the
requirements (functional and non-functional), high-fidelity prototyping,
interface specification, up to the more technical steps with object-oriented
language coding, testing, product delivery, and deployment with the user. In
which this software has the purpose of automating, facilitating and organizing
all dynamics such as loans for audiovisual and multimedia equipment for
teachers to teach their classes. The Software is designed to obtain the best
performance and cost-benefit, the entire software process and methodology
used in the implementation of the system will be documented to obtain a quality
product, using the MPS.br methodology to obtain engineering practices.
Software, tests (including the entire script, cases of success and failure, test
execution sheets), market negotiation and after-sales, with the intention of
growing for the recent software company that seeks to consolidate itself in the
market.

Keywords: Reservation system. Object-oriented programming. Software


design. Prototype. Test script. MPS.br.
5

SUMÁRIO

INTRODUÇÃO .............................................................................................. 6

1. PLANEJAMENTO ...................................................................................... 7

1.1 Requisitos funcionais ............................................................................... 8

1.2 Requisitos não funcionais ........................................................................ 9

1.3 Requisitos de negócio ........................................................................... 10

1.4 Modelos de qualidade ............................................................................ 11

2. METODOLOGIA MPS.Br......................................................................... 11

3. OS NIVEIS DE MATURIDADE DA METODOLOGIA MPS.br SÃO: ......... 13

3.1 Detalhamento dos processos para nível G do MPS.br........................... 16

3.1.1 Gerência de Projetos .......................................................................... 16

3.1.2 Gerência de Requisitos ...................................................................... 17

4. PROGRAMAÇÃO ORIENTADA AO OBJETO ......................................... 18

4.1 Objeto: ................................................................................................... 19

4.2 Classe: .................................................................................................. 19

4.3 Herança: ................................................................................................ 19

4.4 Polimorfismo: ......................................................................................... 20

5. PROTÓTIPO ........................................................................................... 21

5.1 como rodar o protótipo ........................................................................... 21

6. TESTES DE SOFTWARE ....................................................................... 24

7. ECONOMIA E MERCADO....................................................................... 26

7.1 Agentes Econômicos ............................................................................. 27

7.2 Viabilidade Econômica .......................................................................... 28

8.PRAZO DE ENTREGA E INVESTIMENTOS ............................................ 29

9.CONCLUSÃO ........................................................................................... 31

10. REFERÊNCIAS .................................................................................... 32


6

INTRODUÇÃO

Sistema de Reserva de Multimídia

Com o avanço da tecnologia nas salas de aulas o ensino mundial necessita


de novas tecnologias para ajudar a difundir o conhecimento, deixando as
aulas mais dinâmicas e facilitando o aprendizado.

Os custos de equipamentos podem ser altos e a disponibilidade limitada pela


escola sendo que o compartilhamento de recursos por professores é
inevitável, este sistema tem como objetivo controlar e organizar o empréstimo
de equipamentos multimídias, de forma que os professores consigam se
planejar na utilização dos mesmos.
7

1. PLANEJAMENTO

Entendemos que para obter um excelente resultado de um projeto, é


necessário a aplicação de metodologias de engenharia de software do seu
início ao fim. Segundo Roger S. Pressman (2006), ela ajuda os engenheiros
de software a compreender melhor o problema que eles vão trabalhar para
solucionar os problemas que apareceram na criação do software. Ao iniciar
um projeto de qualquer trabalho técnico, é de vital importância comunica-se e
colaborar com cliente e (outros interessados/envolvidos). Pois, as utilizações
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 e/ou resolvido pelo software. Quanto mais completa e correta for a
análise dos requisitos, melhor será o resultado alcançado.

O nosso projeto de um sistema de reserva de equipamentos audiovisuais para


colégio de Ensino Fundamental e Médio (“Colégio Vencer Sempre”), visa a
melhorar o desempenho pedagógico, uma vez que automatiza o processo e
o torna preciso, organizado e fácil de utilizar, tornando viável o investimento
do colégio nesses equipamentos e no software, onde através do programa de
reserva, que além da organização no processo, vai permitir ao colégio
melhorar a dinâmica das aulas, e consequentemente a qualidade do ensino.

Requisitos de sistema são as descrições mais detalhadas sobre o que o


sistema deve ser capaz de fazer para satisfazer as necessidades e requisitos
do usuário.
8

Figura 1. Requisito de Software

Fonte : https://medium.com/lfdev-blog/como-escrever-requisitos-de-software-
de-forma-simples-e-garantir-o-m%C3%ADnimo-de-erros-no-sistema-app-
74df2ee241cc

Existe uma definição propagada na literatura de Engenharia de Software que


afirma que um Requisito Funcional define o que o sistema fará, e o Requisito
Não-Funcional define como o sistema fará.

1.1 Requisitos funcionais


Os requisitos funcionais são todos os problemas e necessidades que devem
ser resolvidos ou atendidas para o correto funcionamento do software.

De acordo com Sommerville (2011), os requisitos funcionais são declarações


de serviços que o sistema deve fornecer, de como o sistema deve reagir a
entradas específicas e de como o sistema deve se comportar em
determinadas situações.
9

Quadro 1- Requisitos funcionais

Requisitos funcionais
Cadastrar Usuário Essa função
permitirá que o
usuário seja
cadastrado pelo
administrador do
sistema.

Cadastrar Essa função


Equipamento permitirá que o
equipamento
seja cadastrado
pelo
administrado do
sistema.

Efetuar Login Essa função


permitirá que o
usuário efetue o
login no sistema.

Reservar Essa função


Equipamento permitirá que o
usuário faça a
reserva do
equipamento.

Consultar Essa função


Equipamento permitirá que o
usuário consulte
se o
equipamento
está disponível.

1.2 Requisitos não funcionais


Os requisitos não funcionais são executados principalmente na fase de projeto
arquitetural e/ou detalhado, estão associados às características
comportamentais do software e não são solicitados pelos usuários. Esses
requisitos devem ser avaliados pela equipe de desenvolvimento, validados
10

junto aos usuários e definidos aqueles que devem ser aplicados a cada tipo
de sistema.

De acordo com Sommerville (2011), os requisitos não funcionais são


restrições nos serviços e nas funções oferecidas pelo sistema e, por exemplo,
podem incluir restrições de tempo, restrições no processo de
desenvolvimento, e restrições impostas por normas.

Quadro 2 – Requisitos não funcionais

Requisitos Não Funcionais


Sistema será desenvolvido em linguagem JAVA
Banco de dados será o MySQL
Sistema deverá rodar na web
Sistema deverá ter uma interface gráfica para facilitar a utilização.

1.3 Requisitos de negócio

Requisitos de negócio é o processo de descobrir, analisar, definir e


documentar os requisitos relacionados a um objetivo de negócios específico.
Segundo SOMMERVILLE (2011), os Requisitos de Negócio, são declarações,
em uma linguagem natural como diagramas de quais serviços são esperados
dos sistemas e as restrições sob as quais ele dever operar, os Requisitos de
Sistemas, seriam os detalhamentos, as funções, os serviços e as restrições
operacionais.
11

Quadro 3 – Requisitos de negócio

Requisitos de Negócio
O Sistema não deverá permitir cadastrar o mesmo equipamento mais
de uma vez.
O Sistema deverá verificar a disponibilidade do equipamento na data
e hora que está sendo reservado.
O sistema deverá verificar se o usuário está cadastrado.
O sistema deverá ter um botão de ajuda para cada função para auxiliar
o usuário.
Sistema deverá verificar se o equipamento selecionado está
disponível.

1.4 Modelos de qualidade


Para se desenvolver um software com qualidade, no projeto usaremos boa
para a documentação e execução dos testes do software. Utilizaremos a
norma de qualidade MPS.BR (Melhoria de Processos do Software Brasileiro).

A MPS.BR foi criada em 2003 pela empresa Softex para a melhorar a


capacidade de desenvolvimento de software nas empresas brasileiras.

Foi escolhida a MPS.BR por ela considerar as normas e modelos


internacionalmente reconhecidas como a CMMI (Capability Maturity Model
Integration), e nas normas ISO/IEC 12207 e ISO/IEC 15504.

2. METODOLOGIA MPS.Br

A metodologia MPS.br foi criada 2003, pela coordenação da SOFTEX -


Associação da Promoção da Excelência do Software Brasileiro, com o apoio
do MCTI - Ministério da Ciência, Tecnologia e Inovação, da FINEP -
Financiadora de Estudos e Projetos e do SEBRAE - Serviço Brasileiro de
Apoio às Micro e Pequena Empresas e BID/FUMIN - Banco Interamericano
de Desenvolvimento, com o intuito de contribuir para uma maior
competitividade das micro e pequenas empresas brasileiras produtoras de
12

softwares, apoiando-as através da divulgação e adoção de modelos de


melhoria de processo de software.

Com a aplicação da metodologia, o mercado produziria produtos e serviços


com padrões de qualidades internacionais. Nesta metodologia, é realizada

uma avaliação e certificação das empresas em qualidade de processo de


software, assim como as realizadas pela metodologia CMMI, porém com
adaptação a realidade brasileira. Prevê uma graduação de níveis para as
empresas avaliadas.

O MPS.br tem em seu escopo um conjunto de modelos referenciais, guias de


implementação, avaliação e aquisição. Essas guias podem ser obtidas
gratuitamente no site da SOFTEX. A metodologia MPS.br tende a ser mais
leve em relação aos demais modelos existentes, atingindo um maior número
de empresas que tenham capacidade em alcançá-las.

FIGURA 2. Componentes do MPS.BR (SOFTEX, 2007)


Fonte: http://isosoftware.blogspot.com/2009/09/mpsbr.html
13

Os custos para aplicação são considerados médios, e por isso foi a


metodologia escolhida para aplicação na empresa que produzirá o software
para reserva de equipamentos. O MPS.br tem como base técnica as normas
ISO/IEC 12207:2008 [ISO/IEC, 2008a], ISO/IEC 20000:2011 [ISO/IEC, 2011]
e ISO/IEC 15504-2 [ISO/IEC, 2003].

3. OS NIVEIS DE MATURIDADE DA METODOLOGIA MPS.br SÃO:

• Nível G – Parcialmente Gerenciado: primeiro nível a ser atingido,


implantando os processos de “Gerência de Projetos” e “Gerencia de
Requisitos”;
• Nível F – Gerenciado: além dos processos implantados no nível
anterior, são adicionados 5 novos processos: “Aquisição”, “Gerência de
Configuração”, “Garantia da Qualidade”, Gerência de Portfólio de Projetos” e
“Medição”;
• Nível E – Parcialmente Definido: compostos pelos processos dos
níveis anteriores, e adicionados os processos: “Avaliação e Melhoria do
Processo Organizacional”, “Definição do Processo Organizacional”, “Gerência
de Recursos Humanos” e “Gerência de Reutilização”.
• Nível D – Largamente Definido: incorpora além dos níveis anteriores,
os processos: “Desenvolvimento de Requisitos”, “Integração do Produto”,
“Projeto e Construção do Produto”, “Validação” e “Verificação”;
• Nível C – Definido: inclui processos de “Desenvolvimento para
Reutilização”, “Gerência de Decisões” e “Gerência de Riscos”;
• Nível B – Gerenciado Quantitativamente: apresenta além dos
processos já informados nos níveis anteriores, a evolução da “Gerência de
Projetos”;
• Nível A – Em Otimização: não apresenta processos específicos para
esse nível, apenas modificando e aprimorando os processos existentes nos
níveis anteriores.
14

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.
15

TABELA 1 - Níveis de Maturidade do MPS.BR


Fonte: SOFTEX (2005)
16

Figura 3. Níveis de MPS.br


Fonte: https://www.promovesolucoes.com/quais-sao-os-niveis-de-
maturidade-do-mps-br/

3.1 Detalhamento dos processos para nível G do MPS.br

3.1.1 Gerência de Projetos


Tem como objetivo manter atualizadas as atividades, recursos, riscos,
prazos e responsabilidades do projeto.

Nesse processo, deve ser possível acompanhar o desenvolvimento das


etapas do projeto, permitindo correções para não comprometer o andamento
geral. Resultados esperados nessa fase do projeto:

• GPR1: escopo do projeto é estabelecido, mantido, atualizado e utilizado;


17

• GPR2: um processo contido no projeto é mantido, atualizado e utilizado,


contendo, pelo menos, o ciclo de vida do projeto e a lista de tarefas que serão
executadas;

• GPR3: são estabelecidas e mantidas estimativas de dimensões de tarefas e


produtos de trabalho do projeto.

• GPR4: esforço, duração e custo para execução da s tarefas e dos produtos


do trabalho devem ser estabelecidas e justificadas;

• GPR5: orçamento e cronograma devem ser estabelecidos e mantidos


atualizados;

• GPR6: definidos os recursos humanos a partir do conhecimento individual


dos participantes, e experiência;

• GPR7: definidos os recursos e ambiente de trabalhos necessários;

• GPR8: definida a estratégia para operação e suporte do produto;

• GPR9: envolvimento das partes envolvidas no projeto é planejado;

• GPR10: definidos os riscos do projeto, bem como seus impactos;

• GPR11: verificação de viabilidade do projeto;

• GPR12: definição de um plano geral;

• GPR13: revisão do plano do projeto com todos os envolvidos e obtenção de


um compromisso de todos;

• GPR14 a 17: monitoramento de todos os mapeamentos anteriores;

• GPR18: ações corretivas relacionadas a desvios do projeto;

3.1.2 Gerência de Requisitos


Tem como objetivo manter atualizadas os requisitos das partes
interessadas do produto. Resultados esperados:
18

• REQ1: são mapeadas as necessidades, expectativas e restrições das partes


interessadas;

• REQ2: os requisitos são especificados, priorizados e mantidos atualizados;

• REQ3: entendimento e análise dos requisitos junto aos fornecedores;

• REQ4: aprovação dos requisitos pelos fornecedores dos requisitos;

• REQ5: comprometimento da equipe técnica em relação aos requisitos;

• REQ6: a rastreabilidade bidirecional entre requisitos, atividades e produtos


de trabalho são estabelecidas e mantidas;

• REQ7: revisão dos itens anteriores;

4. PROGRAMAÇÃO ORIENTADA AO OBJETO

A programação orientada a objeto de como objetivo aproximar o mundo real


do mundo digital, uns dos criadores do modelo de programação orientada a
objeto foi Alan Kay um matemático e biólogo que deu origem a um postulado
que dizia "O computador ideal deve funcionar como um organismo vivo, isto é
cada célula se relaciona com outras a fim de encontrar um objetivo , mas cada
um funcionando de forma autônoma e as células poderiam se reagrupar para
resolver outro problema ou desempenhar outras funções" com esse conceito
a ideia era tornar a programa algo mais natural.

As principais vantagens da programação orientada a objeto é que ela é


confiável ou seja o isolamento entre as partes gera software seguro, ao alterar
uma parte, nenhuma outra parte é alterada, é oportuna dividindo tudo em
partes, várias delas podem ser desenvolvidas em paralelo, é manutenível
atualizar um software se torna mais fácil, é extensível o software não estático,
e reutilizável podemos usar objetos de um sistema que criamos em outro
sistema futuro e por fim ele é natural mais fácil de entender.
19

4.1 Objeto:
O conceito de objeto é uma coisa material ou abstrata que pode ser
percebida pelos sentidos e descrita por meio de suas características,
comportamento e estado atual, todo objeto deve ter Atributos (características),
Métodos (Comportamento) e Estados (Estado Atual) idealizado através de
uma classe, ou seja, é definido através de uma classe que um esboço do é o
Objeto.

4.2 Classe:
O conceito de classe é uma descrição abstrata de um objeto com
características similares, ou seja, classe um esboço de um objeto que irá
definir suas características que torna classe e objeto quase a mesma coisa,
exceto pela forma como são implementados.

Por exemplo: Uma classe chamada "Caneta" pode gerar ou instanciar um


objeto chamado "Caneta-1" com suas características, métodos e estado atual
definidos, ou seja, um objeto é uma instância de uma classe, outro exemplo
uma forma de biscoito tem como objetivo fazer biscoitos exatamente iguais
podemos dizer que essa forma é uma classe que irá gerar objetos com as
mesmas características, porém com valores diferentes.

Podemos ver isso aplicado o nosso projeto quando a partir de uma classe
"Equipamento" e da classe "Usuário" instanciamos objeto com os mesmos
características, porém com valores diferentes, por exemplo, objeto
"Datashow" que é instanciado da classe "Equipamento" ou objeto "Professor"
que é instanciado da classe "Usuário".

4.3 Herança:
O conceito de herança é a possibilidade que as classes compartilhem seus
atributos, métodos e outros membros da classe entre si, a herança adota a
hierarquia para obter um sistema esquematizado. Na herança temos dois
tipos principais de classe, a classe base também chamada de superclasse ou
20

classe mãe, que é a classe que concede as características a uma outra classe
e classes derivadas ou classes filhas, que é a classe que herda as
características da classe base.

Utilizando a herança uma classe derivada geralmente é utilizada para


especificar características que a tornam única baseadas na classe base. Por
exemplo: a classe base seria usada com uma modelo genérico, ou seja, uma
classe "Pessoa" com os atributos "Nome" e "Idade" poderia ter uma classe
derivada "Professor” e classe derivada "Aluno" com os atributos "Nome" e
"Idade" Herdados das classes "Pessoa" acrescido do atributo "Matéria" e
"Curso" com relação entre si hierarquicamente.

Podemos ver isso sendo aplicado no projeto quando vamos realizar um


cadastro de usuária onde temos uma classe base "Pessoa" com
atributos "Nome" e "Senha” com a classe derivada "Funcionário" com
atributos herdados Nome e Senha acrescidos de atributo "Cargo" assim
tornado possível a criação de novas classe derivadas como "Aluno" ou
"Terceirizados".

4.4 Polimorfismo:
O princípio a partir do qual as classe derivadas de uma única classe base
são capazes de utilizar os métodos que embora apresentem a mesma
assinatura, comportam-se de maneira diferente para cada uma das classes
derivadas ou seja é um mecanismo por meio do qual selecionamos as
funcionalidades que podemos utilizar de forma dinâmica por um programa no
decorrer de sua execução (desde que tenham a mesma assinatura), utilizando
o polimorfismo, os mesmo atributos e objetos podem ser utilizados em objetos
distintos, mas com lógicas diferentes em sua implantação no código isto é que
chamamos de Polimorfismo de sobreposição.

Por exemplo: Vamos dizer que uma determinada classe chamada "Professor"
e outra com o nome de "Diretor" podem ter como classe base uma classe
chamada pessoa, dentro dessa classe base um método chamado
21

"CalculaHoraAula" , este método definido na classe base se comporta de


forma diferente para as chamadas feitas a partir de uma instância de
"Professor" e para instâncias de "Diretor" ela pode ser considerada um
método polimórfico, ou seja, um método de várias formas, sendo assim
podemos dizer que utilizando uma superclasse podemos criar classe
derivadas que irão utilizar os mesmo métodos da superclasse mais realizando
a sobreposição dos valores do seus métodos.

Podemos ver isso sendo aplicado no nosso sistema quando vamos realizar a
reserva de equipamento em determinado dia da semana em que utilizamos a
mesma superclasse com os métodos de data, hora e equipamento.

5. PROTÓTIPO
No desenvolvimento de produtos, por exemplo, a confecção de protótipos é
parte essencial do projeto, consistindo em fase onde são realizados testes
práticos com o produto, antes que este possa ser disponibilizado para
produção, sendo assim comercializado.

5.1 como rodar o protótipo


O sistema está publicado temporariamente em

- Instalar o Node.js

Ir para o site https://nodejs.org/en/download/ , fazer o download e instalar


de acordo com o seu sistema operacional
22

- Instalar o Angular

Abrir um prompt de comando e digitar

npm i @angular/cli

- Após a instalação do angular deverá instalar as bibliotecas utilizadas no


projeto, para tanto deverá ir para o diretório da aplicação e digitar
23

- Após instalar os componentes digitar comando abaixo para rodar a aplicação


24

- Abrir um navegador e ir para o endereço

http://localhost:4200/

6. TESTES DE SOFTWARE
O principal objetivo do processo de teste de software é revelar possíveis
falhas/bugs para que sejam corrigidos até que atinja a qualidade desejada
pelo cliente.

Segundo SOMMERVILLE (2011), o teste de software é um elemento de um


tópico mais amplo, muitas vezes conhecido como verificação e validação
(V&V). Verificação refere-se ao conjunto de tarefas que garantem que o
software implementa corretamente uma função específica. Validação refere-
se a um conjunto de tarefas que asseguram que o software foi criado e pode
ser rastreado segundo os requisitos do cliente.

Quadro 4 – Roteiro de Testes

Cadastrar Equipamento

1 - Clicar no botão cadastrar equipamento


2 - Clicar em novo equipamento
3 - Digitar o nome e quantidade de equipamento
4 - Clicar em salvar.

Caso 1: Equipamento cadastrado com sucesso.

Exibe uma mensagem dizendo que o equipamento foi cadastrado com


sucesso.

Caso 2: Nome do equipamento já existe.

Exibe uma mensagem de erro ao usuário dizendo que o equipamento


já foi cadastrado.

Cadastrar Usuário

1 - Clicar no botão cadastrar Usuário


2 - Clicar no botão Novo Usuário
25

3 - Digitar o nome, perfil e senha do usuário


4 - Clicar em salvar.

Caso 1: Usuário cadastrado com sucesso.

Exibe uma mensagem dizendo que o equipamento foi cadastrado com


sucesso.

Caso 2: Usuário já existente.

Exibe uma mensagem de erro ao dizendo que o usuário já foi


cadastrado.

Efetuar Login

1 - Clicar no botão Login


2 - Entrar com o código de usuário e senha
3 - Clicar no botão OK

Caso 1: Usuário e senha correta.

Abre a tela principal do sistema.

Caso 2: Usuário inexistente ou senha inválida.

Exibe uma mensagem de erro ao dizendo que o usuário ou senha


errada.

Reservar Equipamento

1 - Clicar no botão Reservar Equipamento


2 - Selecionar equipamento disponível na lista
3 - Selecionar dia e hora desejada
4 - Clicar no botão OK

Caso 1: Equipamento reservado.

Exibe uma mensagem dizendo que o equipamento XXXXXXX foi


reservado para o dia XX/XX/XX no horário XX:XX

Caso 2: Equipamento não digitado


26

Se for clicado o botão OK sem selecionar um equipamento exibir uma


mensagem de erro pedindo para o usuário selecionar um
equipamento.

Caso 3: Dia ou hora não selecionados

Se for clicado o botão OK sem selecionar data e hora será exibido uma
mensagem pedindo para o usuário selecionar data e hora para a
reserva.

Consultar Equipamento

1 - Clicar no botão Consultar Equipamento


2 - Selecionar o equipamento a ser consultado
2 - Clicar no botão OK

Caso 1: Exibe histórico do equipamento.

Exibe uma tela com as datas e horas que o equipamento está


reservado

7. ECONOMIA E MERCADO

Nesta disciplina iremos abordar os fatores econômicos fundamentais para o


nosso projeto embasando os agentes econômicos e a viabilidade econômica
da implementação de nosso software de reserva de equipamentos para
auxílio dos professores de colégios de Ensino Fundamental e Médio.

Na visão popular, a economia se limita a ser um estudo sobre dinheiro,


investimentos e finanças. Com certeza, esses são elementos estudados por
essa ciência. Mas ela não se limita apenas a isso. Em sua essência, a
economia trata principalmente das escolhas feitas pelas pessoas todos os
27

dias. A ciência econômica é uma ciência social, porque observa o


comportamento humano. A palavra-chave para estender a Economia é a
escassez de algo como: tempo, serviço, produto e demanda. Não temos em
vista tudo que desejamos e engloba escolhas como o que consumir, produzir,
onde vamos trabalhar e onde iremos chegar.

Hoje em nosso Cenário atual a economia é gerada por grandes meios de


produção desde o manuseio de plantações agrícolas até os softwares e
foguetes que são lançados ao espaço. A economia está em todo e qualquer
lugar e pode ser acessada, controlada e ditada por tendências, Problemas
econômicos, doenças, vendas e muito mais.

7.1 Agentes Econômicos


Nossos agentes econômicos se dividem em dois grupos:

Famílias (Professores e Alunos): conjunto de pessoas que existem num país


cuja atividade económica é o consumo.

Empresas (Colégio Vencer): conjunto de empresas cuja atividade é a


produção de bens.

Como mencionado o primeiro grupo de agentes econômicos é a Família, pois


nelas existem Professores, Alunos, Diretores e funcionários da organização,
esses Agentes recebem salários, rendas e remuneração por seus serviços
prestados a Organização. Neste momento visamos facilitar a vida dos
funcionários para que consigam realizar a reserva dos produtos desejados de
forma fácil e rápida e sem problemas de conflito com outros colaboradores
que desejam reservar o produto no mesmo dia e horário.

Referente a Empresa (Colégio Vencer) visualizamos uma necessidade de


organização em suas reservas de equipamentos, onde a demanda era alta e
a reserva era escassa de organização. Então criamos um software que
auxiliará a reserva e demanda dos produtos áudio visuais para facilidade e
interação das aulas. Com isso ajudaremos a organização a reduzir custos,
28

otimizar tempo e facilitar a comunicação de seus funcionários nos dias e


horários ajustados em nosso programa.

7.2 Viabilidade Econômica

Como apresentado em nossa introdução, a economia vai além do dinheiro ela


pode ser definida como escassez de algo, um exemplo é a falta de tempo,
falta de produtos áudio visuais para serem usados ao mesmo tempo.
Pensando nisso nós criamos um Software que trará um ganho de tempo, pois
como a reserva era feita manualmente o professor se dirigia ao local e
preenchia a folha a mão e muitas vezes seu produto reservado não estava no
local.

Outro ganho que traremos é o ganho da Interação entre alunos e professores,


pois com o ganho de tempo geramos maior fluxo nas aulas, acelerando o
aprendizado e interação dos alunos e professores com os equipamentos
áudio visuais, transformando a aula em um local de aprendizado rápido e
interativo, onde levamos tecnologia e outras formas de conhecer e praticar a
matéria ensinada.

E por último a Economia em dinheiro, pois se pensarmos que deverá haver


um notebook, um projetor, um microfone e caixa para cada professor para que
não ocorra o risco dele ficar sem em suas aulas, o valor dos produtos
mencionados serão maiores que o valor investido no software, com a rotação
dos produtos existentes reservados em nosso banco de dados e no sistema
de reservas os professores poderão ver as reservas em tempo real na palma
de sua mão ou mesmo em seu computador e assim saberão que naquele dia
não poderão realizar o uso do equipamento desejado, assim deverão
remanejar seu tempo para usar o produto em outro dia.

Além deste comparativo destacado acima, embasamos outros dois ganhos


econômicos de tempo e de aprendizado na sala de aula, que agregará mais
valor em nosso serviço.
29

8.PRAZO DE ENTREGA E INVESTIMENTOS

Por se tratar de um projeto simples de programação que não pode ser vendido
superior à sua média a um preço muito alto, porém não fugindo aos critérios
de normas de qualidade para obter um projeto com custo-benefício favorável
quanto para empresa desenvolvedora do projeto (software - Sistema de
Reserva de Equipamentos Audiovisuais), como também para o cliente final
(Colégio Vencer Sempre).

Logo após o aceite do (“Colégio Vencer Sempre”), as etapas darão início e


para que o projeto consiga seguir todos os cronogramas estabelecidos e
prazos definidos anteriormente, a comunicação entre o solicitante do projeto
e a empresa esteja bem familiarizada pois, isso conduzira o projeto e deve ser
extremamente alinhado, assim como cada responsável no projeto. Serão
envolvidos no projeto: um analista de sistemas para fazer o levantamento dos
requisitos, planejamento e confecção da documentação, um programador que
irá codificar a ferramenta e um testador para fazer toda a validação para
entrega do produto.

Todo trabalho em equipe para projeção do software será assistido de acordo


com o gráfico.
30

Horas

Análise Desenvolvimento Testes

Figura 3: Evolução do projeto.

Fonte: O autor Excel (2021).

De acordo com a representação gráfico, o cronograma será de quinze (5) dias


para a fase de planejamento, que compreende o levantamento de requisitos,
prototipação e validação junto ao usuário final do sistema; sessenta (10) dias
para a codificação do sistema; quinze (5) dias para criação dos requisitos de
testes, execução dos testes e entrega do produto.

O custo do projeto será de acordo com o salário dos três envolvidos (analista,
desenvolvedor e testador) durante os 90 dias do projeto. O custo total do
projeto incluindo mão de obra, licença de uso, mais mensalidades e custos de
implantação:

Análise: 5 dias (120 horas)


Desenvolvimento: 10 dias (240 horas)
Testes: 5 dias (120 horas)

Tempo estimado de conclusão: 30 dias (720 horas)


Valor total do projeto: R$ 30.000,00
31

9.CONCLUSÃO

Com esse projeto foi possível utilizar os conhecimentos adquiridos nas


matérias estudadas durante o primeiro bimestre com as atividades aplicadas
no projeto, com o objetivo de testar e consolidar os conhecimentos adquiridos
durante as aulas e exercícios. Com a matéria de Economia de Mercado foi
possível demonstrar o mapeamento dos agentes econômicos que atuam
diretamente com a nossa empresa para o fornecimento do software,
demonstrar a viabilidade econômica para a implantação desse projeto, indicar
todas as informações relevantes para o desenvolvimento do projeto como
prazo de conclusão e também investimentos financeiros.

Com a Engenharia de Software II foi possível realizar a análise dos requisitos


funcionais, não funcionais e de negócios que foram necessários para o
desenvolvimento do sistema e definir toda a documentação, as interfaces das
regras de negócio e as mensagens a serem exibidas foram desenvolvidas no
projeto, também nesta etapa definimos as normas de qualidade que seriam
mais adequadas para a nossa empresa com argumentos técnicos e
exemplificando a metodologia utilizada, a elaboração da nossa base de teste
para os requisitos funcionais e para negócios, juntamente com o roteiro de
teste. Na matéria de Projeto de Interface com o Usuário, desenvolvemos
nosso protótipo do projeto com alta fidelidade com as interfaces, foram
detalhadas cada interface apresentada, explicando o funcionamento de cada
dado de entrada, processamento e saída.

Por fim, na matéria de Programação Orientada a Objeto I, foram descritos


alguns dos seus fundamentos de forma técnica como a funcionalidade de
objeto, classes, fundamentos da herança e polimorfismo exemplificado em
nosso projeto. Assim foi possível evidenciar todas as matérias que foram
apresentadas nessa parte de curso consolidando algumas das necessidades
para os profissionais de Análise e Desenvolvimento de Sistema.
32

10. REFERÊNCIAS

Instalação node– https://nodejs.org/en/download/

Instalação angular –
https://www.npmjs.com/package/@angular/cli#installation

Agentes Econômicos - https://www.slideshare.net/anamotatorres/agentes-


economicos-55418066/4

O que é Economia? - https://www.politize.com.br/o-que-e-economia/

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.

Programação orientada a objetos I. / Helder Frederico Lopes, Olavo T. Ito. –


São Paulo: Editora Sol, 2015

Introdução à POO - Partes 1 e 2/Artigo da Revista Clube Delphi Edição 108.


/Por Guinther Em 2010

BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. 2 ed. Rio
de Janeiro: Campus, 2006.

Você também pode gostar