PIM - V_ UNIP

Prévia do material em texto

<p>UNIVERSIDADE PAULISTA – UNIP EAD</p><p>Projeto Integrado Multidisciplinar V</p><p>Curso Superior de Tecnologia em</p><p>Análise e Desenvolvimento de Sistemas</p><p>BRENDON SANTOS  DE ALMEIDA - 2338718</p><p>JOÃO VICTOR DE LIMA GUERAZO - 2334224</p><p>RAQUEL SANTANA BATISTA - 2340371</p><p>Projeto de Sistema Escola Vencer Sempre</p><p>Campinas - São Paulo</p><p>2024</p><p>BRENDON SANTOS  DE ALMEIDA - 2328718</p><p>JOÃO VICTOR DE LIMA GUERAZO -2334224</p><p>RAQUEL SANTANA BATISTA - 2340371</p><p>Projeto de Sistema Escola Vencer Sempre</p><p>Projeto Integrado Multidisciplinar em</p><p>Análise e Desenvolvimento de Sistemas</p><p>Projeto Integrado Multidisciplinar para obtenção do título</p><p>de tecnólogo em Análise e Desenvolvimento de Sistemas,</p><p>apresentado à Universidade Paulista – UNIP EaD.</p><p>Orientador (a): Profa. Ma. Gislaine Stachissini</p><p>Campinas - São Paulo</p><p>2024</p><p>RESUMO</p><p>O objetivo deste trabalho é desenvolver um sistema de reserva de equipamentos audiovisuais para um colégio de ensino fundamental e médio chamado Vencer Sempre que integre conceitos de várias disciplinas. Para identificar os agentes econômicos envolvidos e avaliar a viabilidade econômica do projeto, levando em consideração o prazo e o investimento necessários, a disciplina de economia e mercado será empregada.</p><p>Os requisitos do sistema, que incluem interfaces, regras de negócios e mensagens, serão identificados e especificados por meio da Engenharia de Software II. Escolhendo a metodologia de qualidade de software MPS.br, levando em consideração a busca de qualidade da empresa de software e seus limites financeiros.</p><p>Um plano de testes será feito para garantir que os requisitos funcionais sejam atendidos, incluindo um roteiro de testes detalhado. Serão criados protótipos de interfaces de alta fidelidade explicando o funcionamento. Isso será feito usando os fundamentos da disciplina de projeto de interface com o usuário.</p><p>Por fim, para garantir uma abordagem técnica e fundamentada no desenvolvimento do projeto, a disciplina de programação orientada a objetos I será empregada para descrever os fundamentos de objetos, classes, herança e polimorfismo, bem como para identificar esses elementos no sistema proposto. Para fornecer uma visão abrangente e multidisciplinar do desenvolvimento do sistema de reserva de equipamentos audiovisuais, este estudo visa integrar os conhecimentos das disciplinas mencionadas anteriormente.</p><p>Palavras-chave: Reserva, Equipamentos, Colegio, Economia, Software, Requisitos, Interfaces, Testes, Protótipos, Programação, Desenvolvimento, Integração.</p><p>ABSTRACT</p><p>The objective of this work is to develop a reservation system for audiovisual equipment for an elementary and high school called Vencer Sempre that integrates concepts from various disciplines. In order to identify the economic agents involved and assess the economic feasibility of the project, taking into account the time frame and investment required, the discipline of economics and market will be employed.</p><p>System requirements, which include interfaces, business rules, and messaging, will be identified and specified through Software Engineering II. Choosing the software quality methodology MPS.br, taking into account the software company's pursuit of quality and its financial limits.</p><p>A testing plan will be made to ensure that the functional requirements are met, including a detailed testing roadmap. Prototypes of high-fidelity interfaces explaining how they work will be created. This will be done using the fundamentals of the UI design discipline.</p><p>Finally, to ensure a technical and grounded approach in the development of the project, the discipline of object-oriented programming I will be employed to describe the fundamentals of objects, classes, inheritance and polymorphism, as well as to identify these elements in the proposed system. To provide a comprehensive and multidisciplinary view of the development of the audiovisual equipment reservation system, this study aims to integrate the knowledge of the previously mentioned disciplines.</p><p>Keywords: Reservation, Equipment, School, Economy, Software, Requirements, Interfaces, Tests, Protótipos, Prototypes, Development, Integration.</p><p>LISTAGEM DE TABELAS</p><p>Tabela 1 – TABELA VALORES…………………………………………………….……12</p><p>SUMÁRIO</p><p>1.INTRODUÇÃO.......................................................................................................07</p><p>2.PROTÓTIPO DE INTERFACE DE SISTEMA........................................................08</p><p>2.1. Tela de Login………………………………………………………………………….08</p><p>2.2. Minhas Reservas……………………………………………………………………..09</p><p>2.3.Consultar Reservas……………………………………………………………………09</p><p>2.4.Reserva de Equipamentos……………………………………………………………10</p><p>2.5.Reservas Marcadas…………………………………………………………………...10</p><p>3.INVESTIMENTOS...................................................................................................11</p><p>3.1.Agentes Econômicos………………………………………………………………….11</p><p>3.1.2.Consumidores Finais………………………………………………………………..11</p><p>3.1.3.Fornecedores………………………………………………………………………...11</p><p>3.1.4.Governo………………………………………………………………………………11</p><p>3.2.VIABILIDADE ECONÔMICA………………………………………………………….11</p><p>3.2.1.Análise de Custos……………………………………………………………………11</p><p>3.2.2.Análise de Mercado…………………………………………………………………11</p><p>3.2.3.Retorno Sobre Investimento (ROI)....................................................................11</p><p>3.2.4.Prazo de Conclusão…………………………………………………………………11</p><p>3.3.INVESTIMENTO FINANCEIRO NECESSÁRIO……………………………………11</p><p>3.3.1.Desenvolvimento de Software……………………………………………………..11</p><p>3.3.2.Suporte pós-venda…………………………………………………………………..11</p><p>3.4.TABELA DE VALORES……………………………………………………………….12</p><p>4.NORMAS DE QUALIDADE...................................................................................12</p><p>4.1.Motivo da Escolha…………………………………………………………………….12</p><p>4.2.Componentes…...………………...…………………………………………………...13</p><p>4.2.1.Modelo de Referência (MR-MPS).....................................................................13</p><p>4.2.2.Método de Avaliação (MA-MPS).......................................................................13</p><p>4.2.3.Modelo de Negócio (MN-MPS).........................................................................13</p><p>4.3. Níveis de Maturidade…….…………………………………………………………..13</p><p>5.REQUISITOS .........................................................................................................15</p><p>5.1 Requisitos Funcionais..........................................................................................15</p><p>5.1.1.Registro do Usuário…………………………………………………………………15</p><p>5.1.2.Alteração de Cadastro………………………………………………………………15</p><p>5.1.3.Exclusão do Cadastro………………………………………………………………15</p><p>5.1.4.Reservar Equipamento……………………………………………………………..15</p><p>5.1.5.Data de Reserva do Equipamento………………………………………………...15</p><p>5.2.Requisitos Não Funcionais..................................................................................16</p><p>5.2.1.Usabilidade…………………………………………………………………………..16</p><p>5.2.2.Quantidade de Uso……………………………………….…………………………16</p><p>5.2.3.Compatibilidade……………………………………………………………………..16</p><p>6.PROGRAMAÇÃO ORIENTADA A OBJETOS……………………………………….17</p><p>6.1.1.Classe………………………………………………………………………………...16</p><p>6.1.2.Encapsulamento…………………………………………………………………….16</p><p>6.2.Tipos de Encapsulamento de Classe………………………………………………..16</p><p>6.2.1.Público (Public).................................................................................................16</p><p>6.2.2.Protegida (Protected)........................................................................................16</p><p>6.2.3.Privado (Private)...............................................................................................16</p><p>6.2.4.Objeto…………………………………………………………………………………17</p><p>6.2.5.Herança………………………………………………………………………………17</p><p>6.2.6.Polimorfismo…………………………………………………………………………17</p><p>6.3.Identificação de POO no sistema……………………………………………………17</p><p>6.3.1.Classes do Sistema…………………………………………………………………17</p><p>7.ROTEIRO DE TESTES..........................................................................................18</p><p>7.1.Plano de Testes………………………………………………………………………..18</p><p>7.1.1.Requisitos Funcionais………………………………………………………………18</p><p>7.1.2.Planejamento de Teste……………………………………………………………..18</p><p>7.2.Roteiro de Testes……………………………………………………………………...19</p><p>7.2.1.Login no Sistema……………………………………………………………………19</p><p>7.1.5.Cadastro no Sistema………………………………………………………………..20</p><p>7.1.6.Reservas de Materiais………………………………………………………………21</p><p>7.1.7.Exclusão de Cadastro………………………………………………………………22</p><p>CONCLUSÃO............................................................................................................23</p><p>REFERÊNCIAS.........................................................................................................24</p><p>1.INTRODUÇÃO</p><p>Uma demanda cada vez mais premente para incorporar a tecnologia na educação moderna é um meio de maximizar os resultados e otimizar os processos. Neste contexto, a criação de um sistema de reserva de equipamentos audiovisuais é crucial para melhorar a gestão e facilitar o acesso aos recursos necessários para um ensino eficiente.</p><p>O objetivo deste estudo é explorar e integrar conhecimentos de Engenharia de Software II, Economia e Mercado, Projeto de Interface com o Usuário e Programação Orientada a Objetos I. O objetivo é desenvolver um sistema que facilite e controle o empréstimo de equipamentos e recursos de apoio para professores na escola Vencer Sempre. A combinação dessas áreas fornecerá uma abordagem multidisciplinar e abrangente, garantindo que o sistema proposto funcione e seja eficaz.</p><p>O sistema também será capaz de atender às necessidades únicas e dinâmicas do ambiente educacional moderno. Neste caso, o objetivo principal é fornecer uma ferramenta que não apenas facilite, mas também melhore a gestão de recursos audiovisuais, a fim de melhorar o processo de ensino-aprendizagem.</p><p>2.PROTÓTIPO DE INTERFACE DE SISTEMA</p><p>Nossa empresa criou um sistema personalizado e para escola vencer para gerenciamento de aparelhos audiovisuais com o intuito de facilitar a maneira que os professores utilizavam os equipamentos tendo em vista que eles usavam um sistema manual para reserva de equipamentos.</p><p>Começamos criando um sistema com uma tela inicial onde os usuários fariam seu login usando seu usuário e senha e haveria um botão para caso o usuário esqueça a senha.</p><p>2.1 Tela de Login</p><p>Quando o usuário concluir o login ele entrará no sistema onde ele terá acesso a três abas, são essas: “Minhas reservas, Consultar reservas e Reservas Marcadas”. Nelas ele poderá efetuar as tarefas: Consultar as reservas feitas pelo próprio usuário; Consultar quais equipamentos estão disponíveis para efetuar a reserva e consultar quais equipamentos estão reservados por outros usuários e até quando estarão disponíveis.”</p><p>2.2. Minhas reservas</p><p>Na segunda imagem, conseguimos ver como ficaria distribuído o Layout e como ficariam dispostos os elementos referentes às reservas feitas pelo o usuário, seria possível visualizar as datas em que os equipamentos foram reservados e clicando nos equipamentos é possível cancelar a reserva.</p><p>2.3. Consultar reservas</p><p>Temos uma representação na imagem três de como seriam feitas as reservas e como ficaria arrumado os equipamentos na tela, é importante citar que clicando nos equipamentos que estão como “Disponível” seria possível reservá los sendo representado na quarta imagem.</p><p>2.4. Reserva de equipamentos</p><p>2.5. Reservas marcadas</p><p>Na aba “Reservas marcadas” pode-se verificar quais seriam os outros usuários que estariam reservando os equipamentos e até quando ele se manterá reservado como demonstrado na imagem seis.</p><p>3.INVESTIMENTOS</p><p>3.1. Agentes Econômicos</p><p>3.1.2. Consumidores Finais: Empresa que comprou e utilizará o software.</p><p>3.1.3. Concorrentes: Outras empresas de software que vendem produtos comparáveis e têm o potencial de influenciar o mercado.</p><p>3.1.4. Fornecedores: Empresas que fornecem materiais de desenvolvimento de software, como hardware, software de terceiros, serviços de hospedagem, etc.</p><p>3.1.4. Governo: Regulamentações e políticas governamentais podem influenciar o mercado de software, como leis de propriedade intelectual, incentivos fiscais, etc.</p><p>3.2. VIABILIDADE ECONÔMICA</p><p>3.2.1. Análise de custos: Avaliação dos custos associados ao desenvolvimento de software, que inclui mão de obra, equipamentos, licenças de software e outros elementos.</p><p>3.2.2. Análise de Mercado: Estudo da concorrência, da demanda do mercado e das tendências do setor para avaliar o potencial de mercado do software.</p><p>3.2.3. Retorno sobre Investimento (ROI): Cálculo do retorno esperado sobre o investimento realizado no projeto.</p><p>3.2.4. Prazo de Conclusão: Estimar o tempo necessário para o desenvolvimento e implementação do software levando em consideração fatores como complexidade do projeto, recursos disponíveis, etc.</p><p>3.3. INVESTIMENTO FINANCEIRO NECESSÁRIO</p><p>3.3.1. Desenvolvimento de Software: Custos associados ao desenvolvimento do software, incluindo salários da equipe de desenvolvimento, custos de hardware e software, custos de infraestrutura, etc.</p><p>3.3.2. Suporte pós-venda: Custos associados ao suporte técnico, manutenção, atualização de software, etc.</p><p>Para a realização do trabalho um analista de sistemas será necessário para levantar os requisitos, planejar e documentar. Os desenvolvedores que irão codificar o software farão o trabalho em conjunto para garantir que os requisitos sejam validados ao final do processo de entrega do produto.O projeto é economicamente viável se for concluído em um período de pelo menos 30 dias.</p><p>3.4. TABELA VALORES</p><p>Despesas</p><p>Mensal</p><p>Valor</p><p>Valor Final</p><p>Analista</p><p>x1</p><p>R$ 5.000,00</p><p>R$ 5.000,00</p><p>Desenvolvedor</p><p>x2</p><p>R$ 3.500,00</p><p>R$ 7.000,00</p><p>Manutenção</p><p>x24</p><p>R$ 50,00</p><p>R$ 1.200,00</p><p>Licença de Software</p><p>x1</p><p>R$ 1.000,00</p><p>R$ 1.000,00</p><p>Gastos com o Projeto</p><p>x1</p><p>R$ 4.000,00</p><p>R$ 4.000,00</p><p>Valor Final R$ 18.200</p><p>4. NORMAS DE QUALIDADE</p><p>O MPS.br está alinhado com as melhores práticas internacionais e serve como modelo de referência para melhorar os processos de desenvolvimento de software no Brasil. É baseado em normas internacionais como CMMI (Capability Maturity Model Integration),e nas normas ISO/IEC 12207 e ISO/IEC 15504 mas adaptado às demandas das empresas de software brasileiras, o que o torna uma opção viável para empresas com recursos limitados.</p><p>4.1. Motivo da escolha</p><p>1- Adequação às pequenas empresas: O MPS.br foi criado para atender às necessidades das pequenas e médias empresas de software, considerando seus recursos limitados e suas particularidades.</p><p>2- Abordagem Gradativa: O MPS.br oferece um caminho de melhoria gradual com vários níveis de maturidade. Isso permite que sua empresa comece com práticas mais básicas e evolua à medida que adquire mais recursos e experiência.</p><p>3- Custo-Benefício: O MPS.br não requer muito dinheiro para ser implementado. Ele oferece uma abordagem acessível e pragmática para melhorar os processos de desenvolvimento de software.</p><p>4- Foco na Qualidade e Produtividade: O MPS.br ajuda sua empresa a entregar produtos de melhor qualidade de forma mais eficiente, sendo reconhecido nacional e internacionalmente como um modelo de referência para a melhoria de processos de software.</p><p>5- Reconhecimento no Mercado: O MPS.br é reconhecido em todo o país como um modelo padrão para a melhoria de processos de software. Isso pode ajudar a tornar a empresa mais confiável no mercado.</p><p>4.2. COMPONENTES</p><p>4.2.1. Modelo de Referência (MR-MPS)</p><p>O MPS.br define os procedimentos e práticas necessários para que uma organização alcance um determinado nível de maturidade em seu desenvolvimento de software. Ele é organizado em etapas e áreas de processo, incluindo garantia da qualidade, gerenciamento de projetos, engenharia de requisitos e desenvolvimento e manutenção de software.</p><p>4.2.2. Método de Avaliação (MA-MPS)</p><p>Oferece um conjunto de critérios e indicadores para avaliar o desempenho dos processos de uma organização em relação aos requisitos do modelo. As avaliações podem ser realizadas por avaliadores qualificados e seguindo um processo formal de auditoria. As organizações que atingem níveis de maturidade específicos podem obter certificações reconhecidas pelo mercado.</p><p>4.2.3. Modelo de Negócio (MN-MPS)</p><p>Ele define o conjunto de tarefas e materiais necessários para implementar e manter a melhoria de processos em uma empresa. Inclui elementos como instrução, orientação e recursos de suporte.</p><p>4.3. NÍVEIS DE MATURIDADE</p><p>A estrutura do MPS.br é escalada em diferentes níveis de maturidade, que apresenta o progresso de evolução da organização. Os níveis de maturidade são:</p><p>Os diferentes niveis de maturidade do MPS-BR (FONTE: https://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-e-mps-br/27010)</p><p>5. REQUISITOS</p><p>5.1. Requisitos funcionais:</p><p>5.1.1. Registro do usuário: Informações preenchidas nos campos de texto, como nome e e-mail. Esse conteúdo é enviado a um banco de dados relacional para facilitar a organização e consulta. Uma confirmação é exibida após o cadastro ser realizado com sucesso, enquanto uma mensagem de erro é mostrada em caso de falha. Além disso, um mecanismo de validação será aplicado para evitar a inserção de números no campo de nome e converter todas as palavras em minúsculas antes do envio para o banco de dados.</p><p>5.1.2. Alteração de cadastro: Nesta parte, é possível realizar alterações nos dados do perfil do usuário, sendo que as informações no banco de dados são atualizadas juntamente com a data em que foram modificadas. Será exibida uma mensagem de confirmação caso a modificação do cadastro seja bem-sucedida. Em caso de falha, uma mensagem de erro será apresentada.</p><p>5.1.3. Exclusão do cadastro: Aqui pode ser feita a exclusão do perfil do usuário assim como todos dados no banco de dados. Feita unicamente pelo o gerente do sistema, o sistema verifica se o usuário é cadastrado e se for o usuário é excluído. Mensagem de confirmação bem sucedido da exclusão do cadastro caso tenha sido efetuado com sucesso, senão, mensagem de erro.</p><p>5.1.5. Reservar equipamento: Ao escolher o item desejado, o usuário registrado recebe um retorno de confirmação através de uma alteração no botão, que passa a exibir a cor vermelha e altera a mensagem de "DISPONÍVEL" para "INDISPONÍVEL". As informações, incluindo a identificação do equipamento, nome e identificação do usuário, e data, são então armazenadas no banco de dados, e também são exibidas na área de consulta.</p><p>5.1.6. Data de reserva do equipamento: Esta etapa corresponde à segunda fase do processo de locação, sendo a primeira a seleção do equipamento. Será disponibilizado um campo para inserção da data no formato dd/mm/aa. O sistema impedirá a reserva do mesmo equipamento na mesma data e horário. As informações com a data serão enviadas ao banco de dados onde vão ser armazenadas e serão excluídas depois de um determinado tempo.</p><p>5.2. Requisitos não funcionais:</p><p>5.2.1. Usabilidade: Todas as variáveis ​​de entrada terão valores padrão e esses valores serão usados ​​sempre que os dados de entrada estiverem faltando ou forem inválidos.</p><p>5.2.2. Quantidade de uso: É necessário que o sistema tenha capacidade para lidar com até 1000 usuários ao mesmo tempo, mantendo a degradação de desempenho em no máximo 10% em qualquer operação, a fim de otimizar o desempenho da aplicação.</p><p>5.2.3. Compatibilidade: Caso haja necessidade de futuras atualizações e migrações, o sistema reconhecerá os arquivos de versões passadas e os converterá automaticamente para o novo formato, uma vez confirmado pelo usuário.</p><p>6. Programação Orientado a Objetos</p><p>A Programação Orientada a Objetos (POO), tem por finalidade facilitar o trabalho dos programadores de software, pois o objetivo da POO é desenvolver um software visando a satisfação do cliente, garantindo que seja entregue um software que atenda as necessidades do cliente e que seja exatamente o que foi solicitado. Uma característica da Programação Orientada a Objetos é fazer o desenvolvedor pensar nas coisas de maneiras distintas, as transformando em objetos e aplicando as propriedades e métodos da POO, reduzindo a complexidade do desenvolvimento e da manutenção do software.</p><p>6.1.1. Classe: na classe são criadas as funcionalidades, com auxílio dos métodos, que diz o que o objeto irá fazer, como por exemplo andar, para e etc, e suas especificidades como sua cor, tipo e etc. A classe é utilizada para construir o objeto.</p><p>6.1.2. Encapsulamento: limitação imposta aos atributos de uma classe, restringindo aos métodos dessa classe através dos limitadores de acesso.</p><p>6.2. Tipos de encapsulamento de classe:</p><p>6.2.1. Público (public): a classe só é vista pelas demais caso estiverem dentro do mesmo pacote;</p><p>6.2.2. Protegida (protected): acesso restringido apenas os da mesma classe e subclasse;</p><p>6.2.3. Privado (private): acesso permitido somente pela própria classe.</p><p>6.2.4. Objeto: o objeto por ser representado por algo real ou virtual, é formado por um conjunto de variáveis e métodos, onde as variáveis possuem um tipo que define os possíveis valores que ela pode ter, já métodos são a rotinas que são executadas quando as tarefas são realizadas como alterações na variável de um objeto.</p><p>6.2.5. Herança: a herança permite definir uma nova classe, com base em uma já existente. A classe criada pode herdar variáveis e métodos de uma classe já existente (subclasse). Esse mecanismo permite que a subclasse inclua e sobreponha as novas variáveis.</p><p>6.2.6. Polimorfismo: O polimorfismo na biologia é usado para definir diversas formas de membros de uma mesma espécie, usando essa mesma analogia na POO o polimorfismo permite tratar objetos semelhantes de uma maneira uniforme. Para ele ser usado é necessário o conceito de herança, aplicados aos métodos da classe.</p><p>6.3. Identificações de POO no sistema</p><p>6.3.1. Classes do sistema</p><p>· No sistema de controle de reserva de equipamentos temos as classes: Usuário e Equipamentos.</p><p>· A Classe Usuário possui os atributos: Nome, login, senha, CPF e data de nascimento, tipo de usuário.</p><p>· A Classe Usuário possui os métodos: Efetuar reserva de equipamento, consulta de reserva, datas das reservas e consulta de equipamentos.</p><p>· A Classe Usuário possui os Objetos: Professor e Diretoria (o objeto Diretoria possui o privilégio de administrar o sistema por inteiro).</p><p>· A Classe Equipamento possui os atributos: Ser reservado;</p><p>· A Classe Equipamento possui os métodos: Identificar se está disponível para uso ou não.</p><p>· A Classe Equipamento possui os Objetos: Projetor HDMI, Microfone, DVD, Smart TV, Caixa de Som, Notebook Positivo.</p><p>7. Roteiro de testes</p><p>Os testes de software tem como objetivo garantir ao cliente o pleno funcionamento, a qualidade e desempenho esperados. Garantir a alta qualidade do produto oferecido e prevenir o retrabalho por parte dos programadores.</p><p>O software desenvolvido é para controle de requisições de equipamentos, vimos a necessidade de ser testado os sistemas de login e senha do programa. Além de também a entrada e saída de dados disponíveis. Se os controles com os equipamentos estão atualizados, as listas de equipamentos disponíveis, listas de pessoas cadastradas no sistema. Quantos erros podem aparecer para o usuário no momento do acesso e navegação no programa.</p><p>7.1. Plano de testes</p><p>Para elaborar um planejamento de teste para os requisitos funcionais de um software, é importante seguir algumas etapas.</p><p>7.1.1. Requisitos Funcionais:</p><p>·</p><p>· Requisito 1: O sistema deve permitir que os usuários realizem login no sistema ou se cadastrem.</p><p>· Requisito 2: O sistema deve permitir que os usuários naveguem pelo sistema.</p><p>· Requisito 3: O sistema deve permitir que os usuários reservem equipamentos no sistema.</p><p>· Requisito 4: O sistema deve permitir que os usuários visualizem caso o equipamento desejado está ou não reservado.</p><p>·</p><p>·</p><p>7.1.2. Planejamento de Teste:</p><p>·</p><p>· Objetivo: Verificar se os requisitos funcionais do sistema estão sendo atendidos.</p><p>· Estratégia: Testes de unidade, integração e sistema.</p><p>· Recursos Necessários: Ambiente de teste, casos de teste e equipe.</p><p>· Cronograma: Início dos testes após o desenvolvimento de cada funcionalidade do software.</p><p>7.2. Roteiro de Testes:</p><p>7.2.1. Login no Sistema:</p><p>· Passo 1: Fazer o acesso ao login no sistema</p><p>· Passo 2: Preencher os campos de nome de usuário e senha</p><p>· Passo 3: Clicar em login.</p><p>· Verificação: O login no sistema foi criado com sucesso e o acesso no sistema foi iniciado.</p><p>7.2.2. Cadastro no Sistema:</p><p>· Passo 1: O usuário que não possui cadastro poderá ser adicionado no sistema por meio dos administradores do sistema.</p><p>· Passo 2: Nesta aba o novo usuário poderá cadastrar seu nome completo, CPF, email e cadastro de nova senha..</p><p>· Passo 3: O sistema é apenas direcionado ao uso de professores e administrado pela diretoria.</p><p>· Verificação: O cadastro de novos usuários foi realizado com êxito, a entrada de dados no banco de dados foi concluída com sucesso.</p><p>7.2.3. Reservas de Materiais:</p><p>· Passo 1: Acessar a página “Reserva de equipamentos”.</p><p>· Passo 2: Selecionar o equipamento desejado.</p><p>· Passo 3: Reserva-lo fazendo com que ele fique indisponível, até a data e hora da devolução.</p><p>· Verificação: A reserva foi concluída e o sistema gerou um aviso na cor vermelha mostrando que o equipamento está indisponível até a data e hora de entrega.</p><p>7.2.4. Exclusão de Cadastro:</p><p>· Passo 1: Esta função está restrita apenas ao uso da diretoria.</p><p>· Passo 2: O administrador do sistema realiza o acesso no banco de dados do sistema.</p><p>· Passo 3: Dentro do banco de dados, ele pode realizar a exclusão definitiva do cadastro de determinado funcionário. Geralmente realizado quando um funcionário é desligado da empresa.</p><p>· Verificação: A exclusão dos cadastros no banco de dados foi concluída com êxito. Além de ser restrita apenas para os administradores do sistema.</p><p>8.CONCLUSÃO</p><p>A importância da abordagem multidisciplinar na engenharia de software foi demonstrada pela integração de diversas disciplinas do desenvolvimento de um sistema de reserva de equipamentos audiovisuais para o colégio Vencer Sempre. É viável garantir não apenas a funcionalidade do sistema, mas também sua viabilidade econômica e qualidade técnica, ao empregar conceitos de economia e mercado, engenharia de software, qualidade de software, projeto de interface com o usuário e programação orientada a objetos. Esta estratégia reafirma como crucial levaria diversas visões e conhecimentos no desenvolvimento de soluções tecnológicas, com o objetivo de satisfazer as demandas dos usuários e assegurar o desenvolvimento do projeto.</p><p>9.REFERÊNCIA</p><p>Os diferentes niveis de maturidade do MPS-BR (Fonte: >https://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-cmmi-e-mps-br/27010https://blogdaqualidade.com.br/o-que-e-o-mps-br/https://promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/https://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdfhttps://www.cin.ufpe.br/~processos/TAES3/slides-2012.2/O%20Modelo%20MPS-BR.pdfhttps://www.devmedia.com.br/maturidade-no-desenvolvimento-de-software-c</p><p>mmi-e-mps-br/27010https://softex.br/mpsbr/https://meuartigo.brasilescola.uol.com.br/informatica/programacao-orientada-objetos.htmhttps://devbook.com.br/diferenca-entre-objeto-e-classe/</p>