PIM V pd

Prévia do material em texto

2
UNIP EAD
PROJETO INTEGRADO MULTIDISCIPLINAR V
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
Projeto de um Sistema de reserva de equipamentos
audiovisuais
Autor: 
2022
UNIP EAD
PROJETO INTEGRADO MULTIDISCIPLINAR IV
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
Projeto de um Sistema de reserva de equipamentos
audiovisuais
 Nome: 
 RA: 
 Curso: ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
 Semestre: 3
 Orientador: 
2022
RESUMO
Este trabalho tem como objetivo a criação de um projeto de um software de sistema de reservas de aparelhos audiovisuais para uma instituição de ensino chamada Colégio Vencer Sempre com o objetivo de otimizar o processo de reserva demonstrando todo o processo de construção de um software para um cliente, como: prototipação, regras de negócio, requisitos e o roteiro de testes. Utilizando o conteúdo aprendido durante a primeira etapa do terceiro semestre do curso, para demonstração do grau de aproveitamento.
Palavras-chave: Projeto de software, Programação orientada à objetos, Roteiro de testes.
ABSTRACT
This work aims to create a project for a reservation system software for audiovisual devices for an educational institution called Colégio Vencer Sempre with the objective of optimizing the reservation process demonstrating the entire process of building a software for a customer such as: prototyping, business rules, requirements and the test script. Using the content learned during the first stage of the third semester of the course, to demonstrate the degree of use.
Keywords: Software design, Object-oriented programming, Test script.
SUMÁRIO
INTRODUÇÂO ............................................................................................................ 7
1. INTEGRAÇÃO ........................................................................................................ 8
2. INVESTIMENTO E CRONOGRAMA ...................................................................... 8
2.1 Viabilidade Econômica ..................................................................................... 10
3. CICLO DE VIDA DO SOFTWARE ........................................................................ 10
3.1 Etapas do ciclo .................................................................................................. 11
3.2 Modelo de ciclo de vida do software ............................................................... 11
3.3 Requisitos não funcionais ................................................................................ 14
3.4 Requisitos funcionais e regras de negócio .................................................... 15
4. DESENVOLVIMENTO DO MODELO ................................................................... 17
4.1 Classes e Objetos .............................................................................................. 17
5. INTERFACE .......................................................................................................... 19
5.1 Telas ................................................................................................................... 19
5.1.1 Login ................................................................................................................ 19
5.1.2 Cadastro ........................................................................................................... 20
5.1.3 Reserva e consulta ........................................................................................... 21
5.1.4 Busca de equipamentos ................................................................................... 21
5.1.5 Ajuda ................................................................................................................ 23
5.2 Especificações da interface .............................................................................. 23
6. MODELO DE QUALIDADE .................................................................................. 24
6.1 Processos de Gerência ..................................................................................... 26
6.1.1 Gerência de Projetos ........................................................................................ 26
6.1.2 Gerência de Requisitos .................................................................................... 27
7. TESTES DE SOFTWARE ..................................................................................... 27
8. CONCLUSÃO ....................................................................................................... 31
9. REFERÊNCIAS .................................................................................................... 32
INTRODUÇÃO
A tecnologia e seus componentes são a principal alavanca da economia, com sua constante influência nos setores econômicos, sejam estes públicos ou privados. A participação da indústria de software no setor econômico não pode ser determinada só pelos efeitos diretamente relacionados com a área, os softwares provocam impacto em todos os seguimentos da economia e hoje estão correlacionados com a vida e o cotidiano da maioria das pessoas diretamente ou indiretamente, seja em programas de computador, celulares, carros, catracas eletrônicas e painéis de trânsito 
Nesse cenário de transformações provocadas pela utilização de computadores e celulares, o comportamento e a forma que as pessoas se comunicam foi modificada, a partir disso a importância do mercado de software no Brasil foi consolidada, inclusive na área da educação.
Com os constantes avanços da tecnologia e a constante exigência por melhorias por parte da sociedade o Colégio Vencer Sempre analisou a necessidade de modernizar seu processo de controle de equipamentos e recursos, antes feito manualmente. 
Baseado nesse cenário, foi projetado o desenvolvimento de um software com o objetivo de entregar valor e eficiência com fácil usabilidade e diminuição do tempo gasto para realização da tarefa.
1. INTEGRAÇÃO
O software para reserva de equipamentos audiovisuais para escolas será de responsabilidade dos funcionários que faziam o controle desses equipamentos antes da mudança. O uso do software será estendido para alunos, diretoria, administração, professores e demais colaboradores. A aquisição do software será realizada pela administração do colégio, que dado o cenário, é o agente demandante do produto. 
Todos os agentes econômicos do ciclo têm participação no projeto, sejam eles: Famílias que pagam mensalidade e mantém a instituição, os Alunos como consumidores dos serviços de ensino, a Instituição de ensino que entra como empresa que contrataram o serviço de software, o Governo que administra os impostos recolhidos das famílias e empresas e administram esses recursos que são consumidos pela coletividade, entre outros. 
2. INVESTIMENTO E CRONOGRAMA
Por se tratar de um projeto simples, os custos para produção do software são menores que projetos de complexidade média e alta, portanto mais acessível. Para atender aos padrões de qualidade foi estipulado uma entrega a médio prazo. 
Assim que todas partes interessadas estiverem de acordo com o projeto, serão iniciadas as etapas, detalhadas a seguir, para o cumprimento da entrega final do produto no prazo máximo de 90 dias. Para gerar valor para o cliente é de extrema importância o cumprimento das determinações e do cronograma de entrega.
Serão envolvidos no projeto: um Analista de Sistemas para fazer o levantamento dos requisitos e documentação, um Desenvolvedor que irá codificar a ferramenta e um Analista de Testes para fazer toda a validação para entrega do produto. Os esforços do time para realização do projeto estão demonstrados no gráfico abaixo: 
Figura 1 – Esforço em horas demandado no projeto.
 Fonte: Elaboradapelo autor, 2022
O cronograma será separado entra 3 etapas sendo elas: Fase de planejamento que compreende o levantamento de requisitos, prototipação e validação junto ao usuário final do sistema, Fase de codificação e desenvolvimento do sistema e Fase de testes que compreende a criação, execução e validação de testes baseados no requisito e regra de negócio.
Análise: 15 dias (120 horas)
Desenvolvimento: 60 dias (480 horas)
Testes: 15 dias (120 horas)
Tempo estimado de conclusão: 90 dias (760 horas) 
O custo do projeto foi calculado de acordo com o salário dos colaboradores 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: 
O custo de produção e manutenção durante o primeiro ano do software para o Colégio Vencer Sempre é de R$ 58.625,00. O valor estipulado para o custo do projeto é possível pois o custo para o cliente final é de R$ 91.000,00, pois com o preço cobrado conseguimos custear a equipe e pretendemos ter o lucro em torno de 55%.
Custo de produção do projeto: R$ 58.625,00
Custo para o cliente final: R$91.000,00
2.1 Viabilidade Econômica 
Por se tratar de uma empresa nova no mercado e não possuir fontes e recursos financeiros em abundância, analisamos que obter grandes certificações de qualidade e maturidade no momento não é viável. Após a conclusão nossa empresa analisou as metodologias possíveis para execução do projeto sem necessidade de gastos exorbitantes. Graças a metodologias de qualidade internacionais como, ISO, CMMI e MPS.BR, as micro, pequenas e médias empresas podem alavancar seu negócio. 
Foi adotada a metodologia MPS.BR, que se trata de um programa que tem como objetivo melhorar a capacidade de desenvolvimento de software, serviços e as práticas de gestão para empresas que desejam se erguer qualitativamente, sendo seus pontos fortes o baixo custo de implementação e tempo de duração médio de 15 meses.
3. CICLO DE VIDA DO SOFTWARE
Para um sistema final estar em funcionamento ele passa por diversas fases, desde a especificação de requisitos para elaboração do projeto até a sua implementação para o cliente final, esse processo acontece tanto em novos softwares como em softwares já desenvolvidos, sendo esse processo chamado de ciclo de vida do software. Definido pela norma NBR ISO/IEC 12207:1998 como:
“Estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software, abrangendo a vida do sistema, desde a definição de seus requisitos até o término de seu uso.”
Este ciclo conta com algumas fases, dentre elas 6 destacam-se como principais encontradas em todos projetos de software.
3.1 Etapas do ciclo
1. Reunião com o Cliente: Aqui serão discutidas as necessidades, objetivos e público alvo do software;
2. Fase de requisitos: levante dos requisitos, estudo de viabilidade e definição de modelo;
3. Fase de projeto: Desenvolvimento de concepção, especificação, design da interface, prototipação e design da arquitetura;
4. Fase de implementação: Codificação das funcionalidades definidas durante as fases anteriores;
5. Fase de testes: Realização de testes de acordo com os requisitos;
6. Fase de produção: Implantação do produto final em produção.
3.2 Modelo de ciclo de vida do software
Assim como a existência de várias fases de ciclo de vida, também há diferentes modelos de ciclo de vida de desenvolvimento de software. Os modelos de ciclo de vida auxiliam o time de desenvolvimento a se organizar e seguir métodos de aplicabilidade para o desenvolvimento de um software. Os principais modelos de software são:
• Modelo cascata: Conhecido como modelo onde uma nova fase do ciclo de vida só começa quando a sua anterior já acabou. Esse modelo é desenvolvido de forma sequencial e nenhuma entrega é realizada ao cliente final até todas etapas serem concluídas, ocasionando na demora para entrega;
Imagem 2 – Modelo Cascata
Fonte: https://pt.wikipedia.org/wiki/Modelo_em_cascata. Acesso em 09/04/2022.
 
• Modelo Espiral: É um modelo interativo e sequencial que se baseia em análise de riscos e viabiliza a entrega de versões do software desenvolvido que passaram por etapas do ciclo de vida, sendo o produto final entregue rapidamente. O seu ciclo de vida é dividido em 4 estágios;
Imagem 3 – Modelo espiral
 Fonte:https://miro.medium.com/max/1400/1*RkEarinR8m3rJh7cOLKPyg.png. Acesso em 10/04/2022.
• Modelo Incremental: Desenvolvimento de várias partes do sistema simultaneamente. O desenvolvimento passa por todo o ciclo entregando parte dos produtos a cada incremento, mesmo que os primeiros incrementos sejam somente partes, essas são operacionais e funcionam sem as outras.
Imagem 4 – Modelo IncrementalFonte: https://www.devmedia.com.br/introducao-aos-processos-de-software-e-o-modelo-incremental-e-evolucionario/29839. Acesso em 10/04/2022.
• Prototipagem: Desenvolvimento com base na criação de um protótipo do produto ao longo do ciclo de vida com meta em mostrar as funcionalidades de forma limitada. Uma das suas principais características é propor que os usurários avaliem e possam propor novos requisitos antes da fase final de implementação do produto;
Imagem 5 – Modelo Prototipagem
 Fonte: https://centraldaengenharia.files.wordpress.com/2011/02/prototipacao.jpg. Acesso em 10/04/2022.
• Modelo ágil: Destaca pelo desenvolvimento baseado em uma abordagem de planejamento incremental e muito interativa. O desenvolvimento é composto por iterações que duram em torno de 1 a 4 semanas incluindo todas as fases do ciclo. Ao final de cada iteração é entregue ao cliente um conjunto de novas funcionalidades, após essa entrega o cliente dá o seu e feedback e novas metas.
Um dos principais frameworks do modelo ágil é o Scrum. O modelo Scrum é fundamentado em 3 pilares, transparência, inspeção e adaptação. Uma ótima metodologia a ser utilizada em organização onde as equipes tem dificuldade priorização das atividades. O framework Scrum é composto por um Scrum Master, profissional responsável por validar e tramitar os fundamentos do framework no time de desenvolvimento.
Imagem 6 – Modelo Ágil
Fonte: https://metodologiaagil.com. Acesso em 10/04/2022.
3.3 Requisitos não funcionais
Os requisitos não funcionais de um software são aqueles que descrevem não o que o sistema fará, mas como ele fará. Para o sistema de reservas de equipamentos, foram elencados os seguintes requisitos não-funcionais:
Desempenho: O processo de cadastro de colaboradores, consultas, reservas e demais tarefas do sistema é bastante simples, não necessitando de um computador com alto nível de processamento;
Os computadores deverão ter os requisitos mínimos de configuração abaixo:
• 10 GB de espaço no disco rígido
• 2 GB de Memória RAM
• Processador Dual Core 2.8GHz ou superior
• Sistema operacional Windows 7 
Usabilidade: Qualquer usuário do sistema deverá conseguir utiliza-lo de uma maneira simples e descomplicada;
Confiabilidade: O backup deve ser realizado todo dia após fim do expediente, a ponto de guardar todo processo realizado durante o uso do sistema;
Segurança: Os usuários deverão realizar uma etapa de autenticação no sistema para que seja possível acessar as funcionalidades;
Manutenibilidade: O sistema deverá ser atualizado conforme a necessidade de adicionar novos equipamentos no banco de dados;
Compatibilidade: O parque da empresa é composto por estações de trabalho com o sistema operacional Windows. Para esse sistema operacional utilizamos sempre a versão mais recente.
O sistema, por se tratar de um aplicativo desktop em arquitetura cliente/servidor, deverá rodar nos sistemas operacionais elencados neste requisito considerando todas informações descritas acima.
3.4 Requisitos funcionais e regras de negócio
Um requisito de sistema de software que especifica uma função que o sistema ou componente deve ser capaz de realizar. Estes são requisitos de software que definem o comportamento do sistema. Um software poderá ter diversos requisitos a depender da necessidade do cliente. No ciclo devida do sistema foi especificado 7 requisitos, que estão descritos na tabela abaixo:
Tabela 1 – Requisitos funcionais
	ID
	Requisito
	Descrição
	1
	Cadastrar-se
	O usuário deve conseguir se cadastrar no sistema
	2
	Realizar Login
	O usuário cadastrado no sistema deve conseguir realizar login para utiliza-lo
	3
	Efetuar reservas
	O usuário logado no sistema deve conseguir efetuar uma reserva com sucesso
	4
	Consultar reservas
	O usuário logado no sistema deve conseguir consultar suas reservas ativas
	5
	Administrar sistema
	O usuário administrador deve conseguir cadastrar novos equipamentos e fazer a gestão do sistema
	6
	Níveis de acesso
	O sistema deve possuir permissões de acordo com o nível do usuário.
Nível 1: Usuário comum.
Nível 2: Usuário administrador.
	7
	Ajuda
	A tela inicial do sistema deve conter uma página de ajuda contendo tópicos para auxiliar o usuário em caso de dúvidas
Fonte: Elaborada pelo autor, 2022
A partir dos requisitos funcionais podemos definir como serão aplicados. As regras de negócio são padrões que definem como o sistema fará o atendimento às necessidades/exigências definidas. Essas regras podem ser compreendidas em como um requisito funcional se realizará.
Para o sistema de reservas de equipamentos, será tratado a regra de expedição e devolução de equipamentos de acordo com a seguinte descrição:
 Sempre que uma pessoa se dirigir ao departamento para retirar algum equipamento ou fazer a devolução, esta pessoa deve se identificar com seu ID. O profissional do departamento deve entrar no sistema com o ID informado para fazer o controle de despacho, devolução ou alteração.
4. DESENVOLVIMENTO DO MODELO
A Programação Orientada a Objetos (POO), é um paradigma de desenvolvimento utilizado com bastante frequência na atualidade. Suportada por uma grande quantidade de linguagens, confronta também outro paradigma, o Procedural, mais conhecido como estruturado. A POO não é apenas um paradigma de linguagem de programação, ela está presente nas fases de análise, levantamento e projeto. Portanto, quando falamos em Orientação a Objetos temos bastante abrangente, além do próprio código. Seus 4 pilares são:
Herança: Capacidade de um objeto ser idealizado ou baseado em um outro objeto. O reuso do código é uma das suas vantagens, além disso objetos “filhos” herdam características e ações de seus ancestrais, ainda sim podendo ser modificadas.
Polimorfismo: Possibilidade de herdar um método de classe pai e atribuir uma nova implementação para o método pré-definido.
Encapsulamento: Técnica que insere segurança na aplicação em uma POO escondendo suas propriedades. Muitas linguagens orientadas utilizam o encapsulamento baseado em propriedades privadas por métodos chamados getters e setters sendo responsáveis por resgatar e definir o valor da propriedade.
Abstração: Imagina o que o objeto vai realizar dentro da aplicação e define uma identidade ao objeto que vai ser criado. Essa identidade deve ser única dentro do sistema, para evitar conflitos no código. 
4.1 Classes e Objetos
A classe é um modelo, um planejamento, já o objeto seria a classe materializada, ou seja, um objeto com os devidos atributos qualificados. 
As características são nomeadas como propriedades. Por exemplo, as propriedades de um objeto “carro” poderiam ser “modelo”, “cor” e “marca”. Ações que o objeto executará são chamadas de métodos e podem ser muito variados, dependendo do tipo de solução desenvolvida, dessa forma, os benefícios da POO é a representação mais fácil de ser compreendida, facilitando a comparação com o mundo real. Também é considerado um benefício a reutilização do código e a fácil manutenção. Abaixo segue a representação das classes de entidades de negócio do sistema:
Imagem 7 – Diagrama de classes 
Fonte: Elaborada pelo autor, 2022
Como representado no diagrama, foi definida uma classe Pessoa que é herdada pelas classes filhas UsuarioComum e UsuarioAdministrador, obtendo se assim o polimorfismo de atributos e métodos comuns. As demais classes definidas estão em composição, obedecendo a regra de tem um (representado em painelReserva e painelEquipamento) e tem vários (representado em reservas e equipamento). Foi adotado o nome da classe UsuárioComum e Usuário Administrador para dividir permissões sob funcionalidades de acordo com o nível de acesso do usuário.
5. INTERFACE
 Como descrito nos requisitos, qualquer usuário do sistema deverá conseguir utiliza-lo de uma maneira simples e descomplicada, para isso sua interface deve ser simplificada.
5.1 Telas
A partir disso, a navegação por meio das telas do sistema será de fácil usabilidade, onde os usuários poderão interagir com mouse, teclado e telas touchscreen. As interfaces contarão com um design básico e fluido para se adaptar em tamanhas variados de monitores. Abaixo os protótipos das telas.
5.1.1 Login
O usuário já cadastrado deve preencher todos os campos de input com dados válidos. Logo após ele deve clicar em entrar e assim o usuário será redirecionado para a tela de reserva.
Imagem 8 – Tela de login
Fonte: Elaborada pelo autor, 2022
5.1.2 Cadastro 
O usuário deve preencher todos os campos de input com dados válidos. Logo após ele deve clicar em cadastrar e assim o usuário será redirecionado para a tela de login
Imagem 9 – Tela de cadastro 
Fonte: Elaborada pelo autor, 2022
5.1.3 Reserva e consulta
Nessa tela existem caminhos para duas funcionalidades diferentes. 
Funcionalidade 1: O usuário pode realizar uma nova reserva de equipamentos.
Funcionalidade 2: O usuário pode realizar uma pesquisa sobre reservas ativas
Para que sejam executadas as ações basta o usuário pressionar os respectivos botões da interface.
Imagem 10 – Tela de reserva e consulta
Fonte: Elaborada pelo autor, 2022
5.1.4 Busca e reserva de equipamentos
Após a seleção da funcionalidade 1 da tela Reserva e Consulta, o usuário é redirecionado para a tela Busca de Equipamento onde será possível procurar pelo aparelho desejado via ID ou nome do equipamento e após encontra-lo poderá concluir a reserva.
Imagem 11 – Tela de busca de equipamento
Fonte: Elaborada pelo autor, 2022
Após a escolha do equipamento o usuário é redirecionado para a tela onde irá preencher data e horário da reserva.
Imagem 12 – Tela de reserva
Fonte: Elaborada pelo autor, 2022
Após a seleção da funcionalidade 2 da tela de Reserva e Consulta, o usuário será redirecionado para essa tela onde poderá consultar reservas já realizadas utilizando o id ou o nome do equipamento.
Imagem 13 – Tela de busca de reserva
Fonte: Elaborada pelo autor, 2022
5.1.5 Ajuda
Nessa tela o usuário poderá consultar a FAQ com tópicos para auxiliar o uso do sistema. Para acessa-la o usuário pode clicar no ícone “?” em qualquer página do sistema. Para selecionar o tópico desejado basta o usuário clicar em cima e ele será redirecionado para a respectiva página.
Imagem 13 – Tela de Ajuda
Fonte: Elaborada pelo autor, 2022
5.2 Especificações da interface
Características principais:
- Botões grandes, para fácil usabilidade de usuários que utilizarem telas touch;
- Textos e imagens fluidos para se comportar em diferentes ambientes;
-Telas principais do sistema com mínima informação possível para evitar poluição contando com uma área de ajuda ao usuário para auxiliar na usabilidade.
6. MODELO DE QUALIDADE
A metodologia MPS.br, criada 2003 pela coordenação da SOFTEX - Associação da Promoção da Excelência do Software Brasileiro, foi concebida com o intuito de incentivar uma maior competitividade entre micro e pequenas empresas brasileiras produtoras de softwares, apoiando-as através da divulgação e adoção de modelos de melhoria de processo de software.
No âmbito dessa metodologia, são realizadas avaliações com certificação de graduação em níveis para as empresas avaliadas, assim como as realizadas pela metodologia CMMI, porém com adaptação à realidade brasileira. 
O MPS.br segue um conjunto de modelos referenciais, guias de implementação, avaliação e aquisição. Essas guias podem ser obtidas gratuitamente no siteda SOFTEX. Essa metodologia tende a ser mais leve em relação aos demais modelos existentes, podendo assim atingir um maior número de empresas.
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]. Seus custos para aplicação são considerados médios, e dessa forma foi considerada a melhor opção de metodologia a ser escolhida para aplicação na empresa que produzirá o software para reserva de equipamentos. 
A metodologia MPS.br é dividida em diferentes níveis de maturidade, esses níveis estabelecem patamares de evolução de processos, caracterizando melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho ao executar um ou mais processos. 
Os níveis 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.
Dado o cenário em que a empresa de software está em fase inicial, a ideia é a implantação do nível G de maturidade da MPS.br, para quando existir a chance de uma ampliação na empresa, o modelo já esteja integrado à sua cultura, para que seja possível a evolução para próximos níveis.
Na Figura 2, temos a representação do MPS.br:
Imagem 14 – Níveis do MPS.br
Fonte:. Acesso em 09/04/2022.
6.1 Processos de Gerência
Tem como objetivo manter atualizadas as atividades, recursos, riscos, prazos e responsabilidades do projeto e também tem como objetivo manter atualizadas os requisitos das partes interessadas do produto
6.1.1 Gerência de Projetos
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: O escopo do projeto é estabelecido, mantido, atualizado e utilizado;
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: Devem ser estabelecidos e justificados, os esforços, duração e custo para execução das tarefas e dos produtos do trabalho;
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;
6.1.2 Gerência de Requisitos
Nesse processo, deve ser possível acompanhar a evolução dos requisitos.
Resultados esperados:
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;
7. TESTES DE SOFTWARE
Um dos principais integrantes do time de desenvolvimento com forte destaque e indispensável é o analista de qualidade. Sua função é essencial para garantir que o software está funcionado e de acordo com os requisitos, além de ajudar os desenvolvedores a ganhar tempo expondo falhas existentes e possíveis falhas que possa vir a existir. Segundo Pressman recomenda um esforço de testes de 30 a 40% do esforço total do projeto, além de outros esforços que podem ser visualizados no gráfico;
Imagem 15 – Distribuição de esforço
Fonte: Elaborada pelo autor, 2022
Abaixo segue os casos de uso para teste:
Tabela 2 - UC Valida login
Fonte: Elaborada pelo autor, 2022
Tabela 3 - UC Reserva de equipamento
Fonte: Elaborada pelo autor, 2022
Tabela 4 - UC Consulta de reservas
Fonte: Elaborada pelo autor, 2022
Tabela 5 - UC Cadastro de equipamentos
Fonte: Elaborada pelo autor, 2022
Tabela 6 - UC Controle do sistema
Fonte: Elaborada pelo autor, 2022
Tabela 7 - UC Ajuda
Fonte: Elaborada pelo autor, 2022
8. CONCLUSÃO
A partir da demanda de aquisição de software de controle de reservas para equipamentos audiovisuais do Colégio Vencer Sempre, foi analisada a oportunidade de ofertar a produção desse sistema. A partir disso surge a necessidade de um projeto para mapear e planejar toda a extensão desse contrato, incluindo previsão de orçamento, cronograma, análise de requisitos, documentação e planejamento durante todas as etapas do projeto.
O levantamento dos requisitos funcionais e não funcionais foi realizado através de análise de uso dos usuários ao executar as tarefas de reserva dos equipamentos e na interação com o cliente. 
Visando o crescimento do projeto será utilizado o modelo de melhoria de processos MPS.br, em seu primeiro nível (G – Parcialmente Gerenciado), para constante melhora dos produtos. 
A utilização de testes bem documentados e prototipação de alta fidelidade visa a entrega de um sistema com a usabilidade a gosto do cliente, garantindo a qualidade, segurança e confiança.
Além disso a programação orientada à objetos foi incluída nesse projeto, visando a diminuição no tempo de codificação e a reutilização de código fonte com a utilização de classes, herança e polimorfismo, gerando menor custo na produção do sistema.
9. REFERÊNCIAS 
GORDON S. R.; GORDON, J. R. Sistemas de informação: uma abordagem gerencial. 
São Paulo: LTC, 2006.
PALADINI, E. P. et al. Gestão da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005.
FERNANDES, J. H. C. Qual a prática do desenvolvimento de software? Ciência e Cultura, Campinas, v. 55, n. 2, p. 29-33, abr./maio/jun. 2003. Disponível em: http://cienciaecultura.bvs.br/scielo.php?script=sci_arttext&pid=S0009-67252003000200021. Acesso em: 8 abr. 2022.
KROENKE, D. M. Banco de dados: fundamentos, projetos e implementação. Rio de Janeiro: LTC, 1998.
ATÉ O MOMENTO. Exemplos de Requisitos Não Funcionais. Disponível em:
https://www.ateomomento.com.br/exemplos-requisitos-nao-funcionais/. Acesso em:
9 abr. 2022.
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, Juazeiro, 2009. Disponível em: Acesso em: 9 abr. 2022.
ALURA. POO: o que é programação orientadaa objetos?. Disponível em:
https://www.alura.com.br/artigos/poo-programacao-orientada-a-objetos. Acesso em:
9 abr. 2022.
LINHA DE CÓDIGO. Proporção média de esforço de testes em relação ao esfor-
ço total do projeto. Disponível em: http://www.linhadecodigo.com.br/artigo/1780/
proporcao-media-de-esforco-de-testes-em-relacao-ao-esforco-total-do-
projeto.aspx#:~:text=A%20regra%2040%2D20%2D40,total%20do%20projeto
%20%5BPRE00%5D.&text=Existe%20uma%20rela%C3%A7%C3%A3o%20entre
%20o,n%C3%BAmero%20de%20casos%20de%20testes. Acesso em: 9 abr. 2022.
MACORRATI.NET. O ciclo de vida do desenvolvimento de Software. Disponível
em: http://www.macoratti.net/17/09/net_slcd1.htm. Acesso em: 10 abr. 2022.
QUALIDADE BR. MPS.BR. Disponível em: https://qualidadebr.wordpress.com/
2008/08/23/mpsbr/#:~:text=Qual%20%C3%A9%20o%20custo%20da,com%20a
%20necessidade%20da%20empresa. Acesso em: 10 abr. 2022.
TODA MATÉRIA. Setores da Economia. Disponível em: https://www.todamateria.-
com.br/setores-da-economia/. Acesso em: 11 abr. 2022.
UFMG. Requisitos Funcionais e Requisitos Não Funcionais. Disponível em:
https://homepages.dcc.ufmg.br/~figueiredo/disciplinas/aulas/req-funcional-
rnf_v01.pdf. Acesso em: 11 abr. 2022.
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.
MPS.BR. Guia Geral do Software. Disponível em: https://www.softex.br/wpcontent/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf. Acesso em: 11 abr. 2022.
MACORATTI. Quanto vale um software que você produz. Disponível em: http://www.macoratti.net/eng_qvs.html . Acesso em: 13 abr. 2022.
Esforço em horas	
Requisitos	Desenvolvimento	Testes	120	480	120	
Districuição do esforço (Regra 40/20/40)	
Codificação (15 a 20%	)	Análise e projeto (30 a 40%)	Teste e depuração (40 a 50%)	40	20	40