PIM V

Prévia do material em texto

UNIVERSIDADE PAULISTA - UNIP EaD
Projeto Integrado Multidisciplinar
Curso Superior de Tecnologia em
Análise e Desenvolvimento de Sistemas
MÁRIO SÉRGIO LIMA CRAVEIRO - 2283999
MEZZOFANI PEREIRA DE OLIVEIRA - 0612201
CASE COLÉGIO VENCER-SEMPRE:
PROJETO DE APLICATIVO PARA RESERVA DE EQUIPAMENTOS
PICUÍ-PB
2023
RESUMO
Esta pesquisa preocupa-se em tornar o processo de reserva de equipamentos e
recursos tecnológicos do Colégio Vencer-Sempre mais eficiente, para que professores e
alunos consigam aproveitar ainda mais o tempo em sala de aula. Assim, analisa-se
diversos fatores, como: a viabilidade financeira do projeto, a análise do perfil dos usuários,
das tarefas desenvolvidas pelo sistema e do ambiente em que será aplicado, a fim de
construir uma interface adequada, elaborar um cronograma apropriado de tarefas,
estabelecer os requisitos do algoritmo e, sobretudo, montar roteiro de testes para esses
requisitos. Além disso, este projeto alicerça-se na Programação Orientada a Objetos
como, para além de linguagem, um paradigma norteador do software proposto. E, ainda,
prefere-se a MPS. br como metodologia de qualidade, tendo em vista as limitações de
tempo e recursos financeiros.
Palavras-chave: Colégio Vencer-Sempre. Programação Orientada a Objetos. Mps.br.
Usuários. Tarefas. Ambiente. Reserva de Equipamentos. Software.
ABSTRACT
This research is concerned with making the process of booking equipment and
technological resources at Colégio Vencer-Semper more efficient, so that teachers and
students can make the most of their time in the classroom. Thus, several factors are
analyzed, such as: the financial viability of the project, the analysis of the users' profile, the
tasks developed by the system and the environment in which it will be applied, in order to
build an adequate interface, elaborate an appropriate schedule of tasks , establish the
requirements of the algorithm and, above all, assemble a test script for these
requirements. Furthermore, this project is based on Object Oriented Programming as, in
addition to language, a guiding paradigm of the proposed software. And yet, MPS.br is
preferred as a quality methodology, considering the limitations of time and financial
resources.
Keywords: Colégio Vencer-Sempre.Object Oriented Programming. Mps.br. Users. Tasks.
Environment. Equipment Reservation. Software.
SUMÁRIO
1. 1.0 INTRODUÇÃO…………………………………………………………………………5
2. 2.0 PLANEJAMENTO FINANCEIRO……………………………………………………6
3. 2.1 AGENTES ECONÔMICOS………………………….……………………………….6
4. 2.2 CRONOGRAMA……………………………………………………………………….6
5. 2.3 INVESTIMENTO FINANCEIRO……….……………………………………………..7
6. 2.4 VIABILIDADE ECONÔMICA………………………………………………………….7
7. 3.0 LIMITES DO SISTEMA………….…………………………………………………….7
8. 4.0 REQUISITOS DO SISTEMA………………………………………………………….8
9. 5.0 METODOLOGIA MPS.br…..………………………………………………………….9
10. 6.0 ROTEIRO DE TESTES……………………...……………………………………...12
11. 7.0 PROTÓTIPO DE INTERFACE…………………….………………………………..18
12. 8.0 ORIENTAÇÃO A OBJETOS………………………………………………………..22
13. 8.1 CLASSES…………………………………………….…………………………...….22
14. 9.0 CONCLUSÃO………………………………..………………………………………23
15. 10.0 REFERÊNCIAS…………………………………………………………………….24
5
1.0 INTRODUÇÃO
A inovação é um processo inerente e simultâneo ao desenvolvimento da raça
humana. Dessa forma, o economista Schumpeter(1985) conceitua esse processo como
qualquer conhecimento ou hábito que, uma vez incorporado, são aprofundados nos
subconscientes dos indivíduos. Contudo, a principal característica da inovação é sua
capacidade de agir de maneira holística, não se limitando à área do conhecimento
gerador.
Por exemplo, a inovação tecnológica afetou diversas áreas da vida cotidiana, entre
elas a educação, pois muitos professores e docentes utilizam de equipamentos como:
datashow, laptops, TVs e outros eletrônicos como materiais de suporte para ministrar
suas aulas. Entretanto, a inovação traz consigo não apenas soluções, mas também novos
obstáculos para o dia-a-dia.
Neste sentido, este trabalho surge como meio solucionador do problema que o
Colégio Vencer-Sempre enfrenta com o atual sistema de reserva de equipamentos. Diante
disso, propõe-se criar um sistema com finalidade de agilizar e controlar os empréstimos
de equipamentos fornecidos pela escola e, ao mesmo tempo, dar mais comodidade para
os colaboradores. Para isso, será necessário a prototipação de uma interface eficiente,
um código-fonte capaz de alicerçar todo o sistema e, sobretudo, definir custos e encontrar
os agentes econômicos envolvidos em todo o processo
6
2.0 PLANEJAMENTO FINANCEIRO
A construção de qualquer sistema exige a elaboração de um planejamento
financeiro, no caso do software para o Colégio Vencer-Sempre, o planejamento necessita
da conclusão das seguintes etapas:
a) Identificação dos agentes econômicos envolvidos no processo;
b) Estabelecer cronograma para a realização do projeto;
c) Definir o investimento financeiro necessário;
d) Compreender a viabilidade econômica do software.
2.1 AGENTES ECONÔMICOS
A doutrina ortodoxa da Economia afirma que as relações socioeconômicas são
regidas por cinco principais agentes econômicos: famílias, empresas, mercado, Estado e
o mundo. Muito embora, para este trabalho, os agentes fundamentais são: as empresas,
que se traduzem no próprio Colégio Vencer-Sempre e nos fornecedores necessários para
a construção do software, o Estado, que poderá, futuramente, se beneficiar do sistema
desenvolvido para reserva de equipamentos e o mercado, pois a criação dessa pesquisa
é fruto da relação entre oferta e demanda.
2.2 CRONOGRAMA
Ao entender a necessidade do cliente, o Colégio Vencer-Sempre, é possível definir
prazos para a entrega de resultados e, também, o prazo para a entrega do produto final.
Tabela 01: Cronograma de resultados
RESULTADO(S) PRAZO EM DIAS PRAZO EM HORAS
Análise e levantamento dos
requisitos
10 dias 60 horas
Finalização do código fonte 15 dias 90 horas
Prototipação de interface 5 dias 30 horas
Validação da interface e
construção da interface final
2 dias 12 horas
7
Integração código-fonte com
interface final
5 dias 30 horas
Fase de testes 10 dias 60h
Fonte: Autor
Tendo em vista o cronograma acima, entende-se que projeto final estará pronto
após 47 dias, totalizando 282(duzentos e oitenta e duas) horas.
2.3 INVESTIMENTO FINANCEIRO
Para calcular o investimento financeiro que o Colégio Vencer-Sempre terá que
realizar, é preciso, em primeira instância, orçar o valor da hora trabalhada. Sendo assim,
considera-se os seguintes fatores:
I. A falta de recursos financeiros e a inexperiência mercadológica da empresa
que desenvolverá o software;
II. O preço médio do mercado para a hora trabalhada;
III. A expectativa de relacionamento entre o negócio B2B (Business-to-business).
Diante disso, estima-se que a hora trabalhada equivalerá a R$70,00 (setenta reais).
Dessa forma, o valor do projeto e o investimento financeiro calculador equivalerão a
R$19.740,00 (dezenove mil e setecentos e quarenta reais).
2.4 VIABILIDADE ECONÔMICA
Compreender a viabilidade econômica deste projeto é compreender o seu
custo-benefício. Em outras palavras, é entender que o novo sistema de reserva de
equipamentos automatizará tarefas, tornará processos mais eficientes e promoverá mais
conforto aos colaboradores e a administração da escola. Ou seja, o algoritmo
economizará tempo, repercutindo em aulas mais planejadas, menos equívocos e choques
de reservas e, consequentemente, maior respaldo da escola na região e, a longo prazo,
mais alunos.
3.0 LIMITES DO SISTEMA
8
A limitação de um sistema é um passo importante na sua confecção, porém, para
que esse processo seja executado, é fundamental que se entenda e analise os seguintes
itens:
a) Os usuários que usufruirão do sistema;
b) As tarefas que serão executadas pelo sistema e;
c) O ambiente em que o sistema será utilizado.
Neste sentido, podemos entender que o software proposto para a reserva de
equipamentos pode ser conceituado como: “aplicativomobile que os professores do
Colégio Vencer-Sempre utilizarão para reservar equipamentos e outros recursos
tecnológicos para ministrar palestras e aulas. Além disso, os administradores da escola
também usufruirão do sistema para gerenciar e controlar os equipamentos disponíveis e
os docentes que realizam os agendamentos”.
A partir do conceito descrito, é possível entender que:
I. Os usuários do sistema serão os professores e administradores do Colégio
Vencer-Sempre. Ou seja, os usuários variam em idade, gênero, maturidade
tecnológica e experiência profissional;
II. As principais tarefas executadas serão as reservadas de equipamentos e o
gerenciamento de inventário. Contudo, também observa-se subtarefas, como:
log de operações, identificação de usuário, permissão de acessos e outras;
III. O ambiente é o item que mais varia de acordo com a definição, pois o
software será um aplicativo mobile, possibilitando o usuário acessá-lo em
diversos locais.
4.0 REQUISITOS DO SISTEMA
Com a limitação do sistema, torna-se inevitável que se proponha os requisitos
funcionais e não funcionais para a confecção do sistema que, segundo Ribeiro(2015, p
24), podem ser definidos como:
[...] requisitos funcionais envolvem o correto funcionamento do software, sua
integração com outros sistemas, suas interfaces e a garantia de que qualquer
alteração feita não afete a aplicação [...] requisitos não funcionais surgem
principalmente na fase de projeto arquitetural e/ou detalhado, estão ligados à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
junto aos usuários e definidos aqueles que devem ser aplicados a cada tipo de
sistema.
9
Diante dessa definição, pode-se propor a seguinte divisão de requisitos:
01. Funcionais:
a. Gerenciamento de reserva de equipamentos - o aplicativo deve gerenciar a
data, hora e equipamento ou recurso tecnológico escolhido por um usuário
para que estes dados não entrem em conflito com dados escolhidos por
outros usuários. Além disso, o sistema deve permitir cancelamentos de
agendamentos a partir da definição de prazo mínimo escolhido por
administradores. Por fim, o algoritmo deve ser online e ter o mínimo de
tempo de atualização possível;
b. Manutenção de inventário - o sistema deve permitir que administradores
gerenciam a disponibilidade de equipamentos e o cadastro desses recursos
tecnológicos a partir das características e atributos necessários;
c. Login e senha - O sistema deve realizar o login e senha dos usuários a partir
das informações anteriormente cadastradas. Além disso, a interface deve
demonstrar quando as credenciais informadas estiverem incorretas;
02. Não funcionais:
a. Permissão de acessos - o sistema deve identificar os usuários a partir do
seu cadastramento, sendo eles dois tipos: usuários comuns(professores) e
administradores;
b. Linguagem e plataforma - o sistema será codificado em C#, com mescla de
Java para a plataforma mobile. Sabe-se que o desenvolvimento pode ser um
pouco mais lento pois a linguagem C# não ser originalmente projetada para
códigos de mobile, mas o sistema de classes, tão essencial para este
sistema, da programação orientada a objetos é melhor explorado nesta
linguagem.
5.0 METODOLOGIA MPS.br
Antes de iniciar qualquer processo ligado diretamente ao desenvolvimento do
sistema, é necessário escolher uma metodologia adequada da qualidade para o
desenvolvimento de software frente às Normas Internacionais. Contudo, é importante
10
considerar que a empresa desenvolvedora do software possui recursos limitados e é nova
no mercado.
Sendo assim, devido essas características, entende-se que a metodologia MPS.br
é a que melhor se adequa a realidade da desenvolvedora, pois, nas palavras de
Ribeiro(2015, p. 24), essa metodologia possui “o objetivo de incentivar as pequenas e
médias empresas brasileiras de produção de software a implantar um modelo de
qualidade de melhoria de processo com custos mais acessíveis à realidade brasileira”.
No entanto, sabe-se que esta metodologia de qualidade de software possui 7(sete)
níveis de maturidade, sendo eles:
Figura 01 - Níveis de Maturidade
11
Fonte: SOFTEX(2021)
Assim, tendo em vista as limitações da desenvolvedora, pretende-se atingir o nível
G de maturidade, envolvendo os processos básicos e alicerçadores para desenvolvimento
de sistemas: Gerência de Projeto e a Engenharia de Requisitos.
12
6.0 ROTEIRO DE TESTES
Apesar do nível de maturidade esperado para a desenvolvedora ser o “G” na
escala da metodologia MPS.br e, ao mesmo tempo, do planejamento de testes ser um
processo que, geralmente, só costuma acontecer nos níveis intermediários – nível D ou
acima – entende-se que para validar a qualidade desta pesquisa, é fundamental a
existência de um roteiro de testes, mesmo que básico.
Logo, por ter natureza básica, mas sem perder o foco na qualidade, os testes
possuem como característica chave o enfoque nos requisitos funcionais. Em outras
palavras, o roteiro será embasado em testes alfa e beta e testes de usabilidade. Além
disso, acontecerá segundo o cronograma definido anteriormente, com prazo de 10(dez)
dias e na fase de testes.
Tabela 02: Cronograma de Testes
TESTE PRAZO DESCRIÇÃO AGENTES
Teste Alfa 4 dias O Teste Alfa possui
objetivo de verificar
e validar o software
ainda dentro da
desenvolvedora e
sem a interferência
direta do(s)
cliente(s).
Funcionários da
desenvolvedora
Teste de
Usabilidade I
4 dias (simultâneo
ao Teste Alfa)
Apesar de, na
maioria das vezes,
os testes de
usabilidade
centrarem-se nos
indicadores da
interface, o Teste de
Usabilidade I servirá
como meio de
feedback dos
agentes do Teste
Alfa.
Funcionários da
desenvolvedora
Teste Beta 5 dias O Teste Beta
acontecerá com
alguns poucos
funcionários do
Funcionários do
Colégio
Vencer-Sempre
13
Colégio
Vencer-Sempre, o
objetivo é mesclar
usuários comuns e
usuários
administradores
para que os
requisitos
funcionais(login e
senha,
gerenciamento de
equipamentos e
manutenção de
inventário) sejam
testados.
Teste de
Usabilidade II
5 dias (simultâneo
ao Teste Beta)
Possui finalidade
semelhante ao
Teste de
Usabilidade I, mas
este acontecerá sob
a perspectiva direita
de usuários, que
buscarão muito
mais os resultados
práticos do que
técnicos.
Funcionários do
Colégio
Vencer-Sempre
Apuração de
resultados
1 dia O objetivo é apurar
os feedbacks
obtidos com os
testes de
usabilidades
concorrentes aos
testes Alfa e Beta.
Dessa forma,
aprimorar o
software, se
necessários
Desenvolvedora
Fonte: Autor
O passo seguinte após a definição do cronograma é elaborar um roteiro de testes
para os requisitos funcionais que, por definição de Ribeiro(2015, p. 36), pode ser
traduzido como uma “descrição detalhada do passo a passo para a execução do sistema,
14
a fim de verificar cada caso de teste identificado na fase anterior”. Sendo assim, segue o
roteiro de testes proposto:
Tabela 03 - RT: Reserva de Equipamentos
Funcionalidade: Reserva de equipamentos
Pré-condições: Equipamentos e recursos tecnológicos cadastrados no sistema, sistema
de data, hora e local para reserva disponível.
Procedimentos iniciais: Login realizado com sucesso de usuário comum (professor) e
acesso a opção reserva de equipamentos
ID Procedimento Dado de Entrada Resultado Esperado
1 Sistema exibe equipamentos
disponíveis para reserva
- Dados exibidos:
equipamentos e
recursos tecnológicos
disponíveis, com
quantidades dispostas
e caracterização.
2 Usuário muda para a tela de
equipamentos não-disponíveis
- Dados exibidos:
equipamentos e
recursos tecnológicos e
caracterizados como
“não disponíveis”
3 Usuário volta para tela anterior e
clica em um dos equipamentos
disponíveis
- Dados exibidos:
descrição e
caracterização do
equipamento escolhido
e calendário com datas
disponíveis para
agendamento
4 Usuário seleciona a data escolhida - Dados exibidos: horas
disponíveis para
agendamento
5 Usuário selecionahora escolhida,
preenche o campo observação e
conclui
Observação do
usuário
Agendamento salvo e
atualização online no
sistema. Dado exibido:
“Seu agendamento foi
realizado com sucesso”
6 Usuário seleciona data não
disponível.
- Dados exibidos: “Data
escolhida não
disponível”
15
7 Usuário seleciona o campo “meus
agendamentos”
- Dados exibidos:
Agendamentos
realizados pelo usuário
8 Usuário seleciona um de seus
agendamentos
- Dados exibidos: opção
de reagendar ou de
cancelar agendamento
9 Usuário seleciona reagendar e
seleciona nova data
- Dados exibidos: “Seu
reagendamento foi um
sucesso”.
A data anteriormente
agendada é atualizada
online e a nova data e
horário são marcados
como não disponíveis.
10 Usuário seleciona cancelar
agendamento
- Dados exibidos:
“Agendamento
cancelado”.
Fonte: Autor
Tabela 04 - RT: Manutenção de Inventário
Funcionalidade: Manutenção de Inventário
Pré-condições: Cadastro de usuários administradores realizado
Procedimentos iniciais: Login realizado com sucesso de usuário administrador
ID Procedimento Dado de Entrada Resultado Esperado
1 Seleciona a opção “Inventário” - Dados exibidos:
equipamentos e
recursos tecnológicos
já cadastrados no
sistema
2 Seleciona um dos equipamentos
cadastrados
- Dados exibidos:
equipamento com suas
características (nome,
descrição, salas de uso
e quantidade)
3 Seleciona a ferramenta para alterar
dados do equipamento
- Dados exibidos:
Interface de alteração
de características.
16
4 Seleciona e altera nome do
equipamento
Nome do
equipamento, ex:
Notebook
Dados exibidos: o
nome do equipamento
deve ser alterado para
o novo nome escolhido
pelo usuário
5 Seleciona e altera descrição do
equipamento
Descrição do
equipamento
Dados exibidos: a
descrição do
equipamento deve ser
alterado para a nova
descrição escolhida
pelo usuário
6 Seleciona e altera as salas de uso do
equipamento
Salas de uso do
equipamento
Dados exibidos: as
salas de uso do
equipamento devem
ser alteradas para as
novas salas escolhidas
pelo usuário
7 Seleciona e altera quantidade do
equipamento
Quantidades do
equipamento
Dados exibidos: a
quantidade do
equipamento deve ser
alterado para a nova
quantidade escolhida
pelo usuário
8 Seleciona opção salvar - Os itens alterados
devem constar na
interface de
informações sobre o
equipamento
9 Usuário volta para a tela de
inventário
- Dados exibidos: a tela
de interface de
inventário
10 Seleciona botão para adicionar novo
equipamento
- Dados exibidos:
Interface para
cadastramento de
equipamento com 5
lacunas para
preenchimento:
imagem do
equipamento, nome do
equipamento,
descrição, salas de uso
e quantidade.
17
11 Usuário preenche as lacunas
necessárias e seleciona a opção
salvar
Imagem;
Nome do
equipamento;
Descrição do
equipamento;
Salas de uso;
Quantidade
O sistema deve voltar
para interface de
inventário que, agora,
também deve conter o
item adicionado.
Fonte: Autor
Tabela 05 - RT: Login e senha
Funcionalidade: Login e senha
Pré-condições: Cadastro de usuários administradores e usuários comuns já realizado.
Procedimentos iniciais: Abertura do aplicativo
ID Procedimento Dado de Entrada Resultado Esperado
1 Usuário comum deve preencher
corretamente as credenciais e
apertar o botão login
Usuário;
Senha.
O sistema deve
processar as
credenciais e realizar
corretamente o login do
usuário comum. Ou
seja, deve prosseguir
para a interface de
reserva de
equipamentos.
2 Usuário comum deve preencher
nome de usuário correto, mas senha
errada.
Usuário;
Senha incorreta
Dados exibidos:
“Usuário e/ou senha
incorretos”
3 Usuário comum deve preencher
nome de usuário incorreto, mas
senha certa.
Usuário
incorreto;
Senha
Dados exibidos:
“Usuário e/ou senha
incorretos”
4 Usuário comum deve selecionar
opção de “Esqueceu a senha?”
- Dados exibidos:
“Procure um
administrador do
sistema”
5 Usuário administrador deve
preencher corretamente as
credenciais e apertar o botão login
Descrição do
equipamento
O sistema deve
processar as
credenciais e realizar
corretamente o login do
usuário administrador.
Ou seja, deve
prosseguir para a
18
interface de
manutenção de
inventário, controle de
datas e cadastro de
usuários.
6 Usuário administrador deve
preencher nome de usuário correto,
mas senha errada.
Usuário;
Senha incorreta
Dados exibidos:
“Usuário e/ou senha
incorretos”
7 Usuário administrador deve
preencher nome de usuário
incorreto, mas senha certa.
Usuário
incorreto;
Senha
Dados exibidos:
“Usuário e/ou senha
incorretos”
8 O usuário administrador deve
selecionar a opção de “Esqueceu a
senha?”
- Dados exibidos:
“Procure um
administrador do
sistema”
Fonte: Autor
7.0 PROTÓTIPO DE INTERFACE
Após o detalhamento dos requisitos funcionais e não-funcionais e, ainda, a
elaboração de um roteiro de testes para cada um dos RF, torna-se possível a prototipação
de uma interface para o sistema. Pois, de maneira geral, pode-se descrever uma interface
como sendo a representação gráfica da análise do ambiente, dos usuários e das tarefas
realizadas pelo algoritmo.
Dessa forma, para a prototipação demonstrada a seguir, utilizou-se a ferramenta
Cacoo, mundialmente referenciada quando o assunto é a construção de wireframes –
“esboços, as primeiras versões de como será um projeto visualmente, antes de definir o
design e o conteúdo” (KRIGER, 2021).
Na imagem a seguir (Figura 02), por exemplo, é possível ver o protótipo das
interfaces de entrada, referente ao login e senha, e o menu do usuário comum
(professor), onde é observado a presença de elementos de fácil compreensão e intuitivos.
19
Figura 02 - Usuario Comum: Login e Menu
Fonte: Autor
Este padrão simples, intuitivo e de fácil compreensão é mantido em todo o projeto
de interface, porque o perfil dos usuários é muito diverso quando o assunto é maturidade
tecnológica.
Nas próximas figuras, é possível observar as interfaces de interação em que
aconteceram os identificadores (IDs) do roteiro de testes referente a funcionalidade de
Reserva de Equipamentos (Tabela 03).
Figura 03 - Usuario Comum: Reserva e Agendamento I
20
Fonte: Autor
Figura 04 - Usuario Comum: Reserva e Agendamento II
Fonte: Autor
Figura 05 - Usuario Comum:Alteração e Reserva
Fonte: Autor
21
Destaca-se que a Figura 05, em específico, descreve a interface em que ocorrerá
as interações referentes aos identificadores compreendidos entre o 7(sete) até o 10(dez)
do mesmo roteiro de testes (Tabela 03). Além disso, para melhor organizar este projeto e
o sistema, a interface de um usuário administrador sofre ligeiras alterações, como
observado a seguir:
Figura 06 - Administrador: Login e Menu
Fonte: Autor
Figura 07 - Administrador: Manutenção de Inventário
22
Fonte: Autor
8.0 ORIENTAÇÃO A OBJETOS
Partindo do ponto de vista acadêmico, é possível identificar algumas características
da Programação Orientada a Objetos neste sistema. Contudo, para ser objetivo, este
projeto irá se centrar no detalhamento de classes e nas suas peculiaridades, como:
herança e polimorfismo.
8.1 CLASSES
Neste projeto, é possível identificar duas macro classes: usuários e equipamentos.
Contudo, tais classes são capazes de gerar classes menores, esta relação pode ser
melhor compreendida no diagrama abaixo:
Figura 08 - Diagrama de Classes
Fonte: Autor
23
Apesar de transmitir complexidade, nesta relação encontra-se apenas três
principais interações de classes: associação, representada pelas linhas retas, herança,
representada pela seta, e polimorfismo dinâmico, que acontece de forma implícita e
impulsiona quase todas as interações.
Para melhor entender o que a Figura 08 deseja transmitir, é necessário iniciar a
interpretação a partir da classe "Usuários" que, dentro dos seus atributos, possui uma
subclasse: “Cargo”. Logo, “Cargo” é, ao mesmo tempo, um atributo de "Usuários” e uma
classe e, neste papel, associa-se a duas outras classes: “Usuário_Comum” e
“Administrador” que, por suas vezes, são classes herdeiras de “Usuários”. Além disso,
“Administrador”, ao efetuarseu método “Manutenção_de_Inventário”, pode gerar um novo
objeto da classe “Equipamento”, esta também possui uma classe herdeira:
“NãoDisponível”, que pode ter um objeto gerado quando um Usuário Comum efetua o
método de “Reservar_Equipamento”.
9.0 CONCLUSÃO
Entende-se que este projeto atingiu seus objetivos ao propor um sistema eficiente
para a reserva de equipamentos do Colégio Vencer Sempre. Contudo, também sabe-se
que é necessário a avaliação do sistema ao final da sua implementação tendo em vista,
principalmente, os seguintes parâmetros: eficiência, eficácia, satisfação, atratividade e
inteligibilidade. A demanda avaliativa é explicada, sobretudo, porque o Colégio já possuía
um sistema para a reserva, ou seja, neste caso a empresa de software não está
implementando ou suprindo uma demanda insaciada, mas se propõe a melhorar um
processo e/ou tarefa. Além disso, também é de conhecimento que o algoritmo e idéia
proposta neste trabalho é passível de melhora, principalmente quanto: sistema de
esquecimento de senha, interface personalizada com a logo da escola, emissão de
relatório de agendamento, possibilidade de acesso de log dentro da interface e outros
10.0 REFERÊNCIAS
SCHUMPETER, J.A. A teoria do desenvolvimento econômico. São Paulo:Nova
Cultural, 1985. Coleção “Os Economistas”. (Primeira edição, em língua alemã, em 1911).
24
RIBEIRO, André Luiz. Engenharia de Software II. / André Luiz Ribeiro. – São Paulo:
Editora Sol, 2015. 188 p., il.
SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro. SOFTEX, 2021.
KRIGER, Daniel. WIREFRAME: O QUE É, QUAL SUA FINALIDADE E QUAIS OS
TIPOS?. Kenzie, 2021. Disponível: <https://kenzie.com.br/blog/wireframe/>. Acesso em
01 de Abril de 2023.
https://kenzie.com.br/blog/wireframe/