[ADS] PIM V - Reserva de Equipamentos Audiovisuais do Colégio Vencer Sempre

Prévia do material em texto

PIM V – Maria
Resumo
	Este trabalho acadêmico tem como objetivo projetar toda a vida de uma contratação de um software que administrará as reservas de equipamentos audiovisuais do “Colégio Vencer”, 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. 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 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, roteiro de testes, MPS-BR.
1. Introdução
De um lado o aumento da tecnologia e a diversidade de equipamentos que visam aprimorar cada vez mais o ensino das escolas, como data shows, sistemas de áudio, projetor de slides, entre diversos outros. De outro lado, o crescimento das escolas e o constante aumento de professores de demais colaboradores e alunos. Manter um controle dos equipamentos, quem está usando em determinado momento, reservas prévias para garantir a utilização e não atrapalhar os planos de uma aula, o controle antes manual feito por planilhas no computador, não é mais eficaz, surgindo a necessidade de um projeto para atender essa demanda.
Será necessário um planejamento realizado a partir da análise de todos os requisitos envolvidos no projeto, para uma estimativa coerente de cronograma e prazos na entrega das diferentes etapas do projeto, bem como os investimentos financeiros.
A partir das especificações da interface do novo software e utilização de metodologias de qualidade de software, o projeto objetiva ter uma fácil usabilidade, fácil implantação, e que agrade usuários de todos os níveis. Serão aplicados testes elaborados a partir de roteiros, afim de minimizar qualquer problema no software, garantindo sua segurança e qualidade.
O sistema será desenvolvido com a linguagem de programação C#, desenvolvido na plataforma Visual Studio, por ser uma linguagem orientada a objetos, o que auxilia na obtenção dos melhores resultados para o projeto.
2. INTERAÇÂO DO SISTEMA COM O “COLÉGIO VENCER SEMPRE” E COM O MERCADO
	O projeto de software para reserva de equipamentos audiovisuais do CVS será utilizado pelos funcionários que fazem o controle desses equipamentos, e pode ser estendido para alunos, diretoria, administração do colégio, além dos professores e demais colaboradores. A aquisição do software é realizada pela administração do colégio, que nesse cenário, é o agente demandante do produto de software. DO lado da oferta temos a empresa de tecnologia que está disposta a produzir tal software. Os funcionários da empresa de software oferecem seus serviços para a empresa, em troca de salários. A empresa de software visa lucros para futuros investimentos. Esse ciclo contempla os agentes financeiros envolvidos em todo o projeto.
3. INVESTIMENTO FINANCEIRO E CRONOGRAMA 
	Por ser um projeto simples que não pode ser vendido a um preço muito alto, os custos para a produção do software devem ser baixos, porém atender aos padrões de qualidade, e dentro das possibilidades, deve ser entregue em um prazo médio.
	Após o aceite do CVS do projeto oferecido, as etapas se iniciarão, detalhadas a seguir, para o cumprimento da entrega final do produto no prazo máximo de 4 meses. O cumprimento das determinações do cronograma de entrega é de extrema importância, chegando a ser mais relevantes do que os próprios custos, pois, se descumpridos, podem gerar insatisfação do cliente, elevação dos custos internos e até uma falência do projeto antes do tempo, deixando o mesmo incompleto. Serão envolvidos no projeto: um analista de sistemas para fazer os levantamentos dos requisitos, planejamento e documentação, um programador que irá codificar a ferramenta e um testador para fazer toda a validação para entrega do produto. Os esforços para projeção do software serão de acordo com o gráfico abaixo:
	De acordo com o gráfico apresentado, o cronograma será de 1 mês e meio para a fase de planejamento, que compreende levantamento de requisitos, prototipação e validação junto ao usuário final do sistema, 1 mês para codificação do sistema, 1 mês e meio para a 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 4 meses do projeto.
4. PLANEJAMENTO 
	Para obtenção de bons resultados do projeto, é necessária a aplicação de metodologias de engenharia de software do início ao fim. Para Pressman (2008), ela ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. A utilização de normas e metodologias facilitam o entendimento do que o cliente realmente deseja receber, quais são os usuários que realmente vã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/ resolvido pelo software. Quanto mais completa e correta for a análise dos requisitos, melhor será o resultado alcançado.
4.1 REQUISITOS FUNCIOANAIS
· Controle dos equipamentos: o sistema deverá controlar a reserva dos equipamentos audiovisuais do CVS, controlando a data e hora da reserva, o usuário solicitante, bem como confirmações, cancelamentos e devoluções para cada requisição. Serão impressos relatórios que demonstrem as entradas e saídas dos equipamentos, quem os utilizou e período de utilização.
· Avisos: para auxílio na organização e logística de entrega dos equipamentos, o sistema deverá avisar o usuário, quando estiver próximo ao período de uma reserva, através de alertas/ avisos, visando um preparo antecipado do equipamento, para que na hora reservada esteja pronto para entrega.
· Inventário: o sistema possuirá um cadastro de todos os equipamentos, datas de compra, garantia, entre outras características, a fim de gerenciar a vida útil dos equipamentos. Os equipamentos podem ser rastreados através de um QRCode fixado em cada um, possuindo identificação única. 
4.2 REQUISITOS NÃO FUNCIONAIS E REGRAS DE NEGÓCIO
· Permissões de acesso dos usuários: o sistema deverá ter controle de acessos seguro para diferentes usuários, bloqueando usuários comuns de acessarem relatórios administrativos. As informações pessoais dos usuários devem ser mantidas sobre o controle apenas dos administradores do sistema.
· Configurações do sistema: inicialmente o sistema será desenvolvido para Windows Desktop. Todos os relatórios devem seguir um padrão de fonte e espaçamento, conforme ABNT. Será desenvolvido em linguagem de programação C#, utilizando a plataforma Visual Studio 2019.
· Tempo de devolução e de espera: junto ao cadastro dos equipamentos, deverá ter informações de quanto tempo o usuário pode permanecer com o equipamento e também quanto tempo ele pode esperar para obter o equipamento, após a sua solicitação. Essas regras são importantes na definição de logística do sistema.
4.3 ESPECIFICAÇÃO DA INTERFACE
	O sistema será implantado na secretaria do colégio, no terminal do almoxarifado, e no notebook do diretor, onde são depositados osequipamentos. Todos os computadores trabalham com o Sistema Operacional Windows, e interagem com o sistema através de mouse, teclado e impressora. Será instalado no servidor que já é utilizado no colégio, comunicando-se com os terminais através de rede cabeada.
	As telas serão simples, com botões grandes e fácil usabilidade e entendimento. Deve apresentar rápida resposta nas consultas geradas, podendo ser utilizado simultaneamente entre diferentes usuários.
5. MPS-BR
	Em 2003, a coordenação da SOFTEX – Associação da Promoção da Excelência do Software Brasileiro, cria a metodologia MPS.BR, com o apoio do MCTI – Ministério da Ciência, Tecnologia e Inovação, da FINEP- Financiadora de Estudos e Projetos, 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 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ça-las. 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 audiovisuais do CVS, pois a empresa está em fase inicial e não dispõe de muitos recursos financeiros para investimento nas metodologias de processo de software.
	O MPS-BR tem como base técnica as normas ISSO/ IEC 12207:2008 [ISSO/ IEC, 2008ª], ISSO/ IEC 20000:2011 [ISSO/ IEC, 2011] e ISSO/ IEC 15504-2 [ISSO/ IEC, 2003]. Possuí 7 níveis de maturidades, como apresentado na figura abaixo:
· Nível G – Parcialmente Gerenciado: primeiro nível a ser atingido, implantando os processos de “Gerência de Projetos” e “Gerência 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.
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.
5.1 DETALHAMENTO DOS PROCESSOS PARA NÍVEL G DO MPS-BR
5.1.2 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.
· 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 das tarefas e dos produtos do trabalho devem ser estabelecidos e justificados.
· 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;
4.1.3 GERÊNCIA DE REQUISITOS
	Tem como objetivo manter atualizados os requisitos das partes interessadas do produto. 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.
6. PROTOTIPAÇÃO E TESTES
	Para garantia de um software com qualidade, será investida boa parte do projeto (um mês e meio, conforme cronograma) na elaboração, documentação e execução dos testes do software. Será utilizada a metodologia TDD (Test Driven Development). Essa metodologia visa gerir testes antes mesmo da codificação do sistema, garantindo que o que será criado funcionará (ANICHE, 2014). Pretende-se, com o uso dessa metodologia, atingir a satisfação do cliente, evitando erros na entrega do software.
6.1. CASOS DE TESTES
	As etapas de planejamento do projeto foram idealizadas a partir do estudo do caso das solicitações dos usuários envolvidos, e foram identificados a seguir:
	1) CADASTRO DE USUÁRIO: informar dados corretos e incorretos;
	2) INVENTÁRIO: informar os dados corretos para adicionar equipamento, e dados incorretos;
	3) RESERVAS: informar dados do equipamento e do usuário corretos, informar dados do equipamento e/ou do usuário incorretos e solicitar reserva de equipamento já reservado.
6.2 PROTOTIPAÇÃO
	Para cada tela/formulário do sistema, são especificados os campos e as regras envolvidas e a tela desenhada do sistema para cada um deles:
6.2.1 CADASTRO DE USUÁRIO
· Campos do cadastro do usuário: NOME -> nome do colaborador, admite somente letras, campo obrigatório; LOGIN -> nome curto para acesso aos sistema, admite letras, campo obrigatório, máximo de 7 caracteres; SENHA -> senha para acesso ao sistema, admite letras e números, mínimo de 5 caracteres, campo obrigatório; ENDEREÇO -> endereço do colaborador, admite letras e números, campo não obrigatório; EMAIL -> endereço de e-mail do colaborador; admite letras números e caracteres, validação de e-mails, campo não obrigatório.
6.2.2 INVENTÁRIO
· Campos do cadastro do inventário: NOME -> nome do equipamento, admite letras e números, campo obrigatório; FABRICANTE -> nome do fabricante do equipamento,admite letras e números, campo não obrigatório; DATA DA COMPRA -> data da aquisição do equipamento, admite datas contidas no calendário, campo não obrigatório; DATA DA GARANTIA - > data de prazo da garantia do equipamento admite datas contidas no calendário, campo não obrigatório.
6.2.3 RESERVAS
· Campos do cadastro de reservas: LOGIN -> login do colaborador que deseja reversar o equipamento, campo obrigatório, campo seleção dos usuários cadastrados; EQUIPAMENTO -> nome do equipamento que será reservado, campo obrigatório, campo seleção dos equipamentos cadastrados; DATA DA RESERVA -> data da reserva, admite datas contidas no calendário, campo obrigatório; HORA DA RESERVA -> hora da reserva, admite horas, campo obrigatório. Validar disponibilidade do equipamento para a data e hora da reserva solicitada.
6.3 TESTES
	Os roteiros de testes visam identificar: qual o caso de teste aplicado, o passa a passo para realização do teste, os dados informados nos testes, o resultado esperado, resultado obtido, e a data da realização do teste, documentados através de fichas denominadas “Resultado dos testes”.
	A seguir foram documentados os resultados para os 3 casos de testes planejados para o projeto do software:
6.3.1 CADASTRO DE USUÁRIO
· Passo a passo: digitar nome do colaborador;
· Dados informados: 1) “JOÃO DA SILVA”; 2) “M4R1A DO CEU”; 3) vazio;
· Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Não;
· Resultado obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Somente letras” e voltou o foco para o campo nome; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo nome.
· Passo a passo: ao digitar login do colaborador;
· Dados informados: 1) “JOAO”; 2) “M4R1A”; 3) vazio; 4) “FREDERICO”;
· Resultados esperado: permitir seguir com o cadstro? 1) Sim; 2) Não; 3) Não; 4) Não;
· Resultados obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Somente letras!” e voltou o foco para o campo login; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo login; 4) ao teclar “enter”, apareceu a mensagem “Máximo de 7 letras!” e voltou o foco para o campo login;
· Passo a passo: digitar senha do colaborador;
· Dados informados: 1) “12345”; 2) “MAR1A”; 3) vazio 4)” FRED”;
· Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Sim; 3) Não; 4) Não;
· Resultados obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, passou o foco para o campo seguinte; 3) ao teclar “enter”, apareceu a mensagem “Preenchimento obrigatório!” e voltou o foco para o campo senha; 4) ao teclar “enter”, apareceu a mensagem “Mínimo de 5 caracteres!” e voltou o foco para o campo senha;
· Passo a passo: digitar endereço do colaborador;
· Dados informados: 1) “12345”; 2) “Rua das Flores”; 3) vazio;
· Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Sim; 3) Sim;
· Resultados obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, passou o foco para o campo seguinte; 3) ao teclar “enter”, passou o foco para o campo seguinte;
· Passo a passo: digitar e-mail do colaborador;
· Dados informados: 1) “joao@email.com”; 2) “MAR1A”; 3) vazio;
· Resultado esperado: permitir seguir com o cadastro? 1) Sim; 2) Não; 3) Sim;
· Resultados obtido: 1) ao teclar “enter”, passou o foco para o campo seguinte; 2) ao teclar “enter”, apareceu a mensagem “Formato de e-mail inválido!” e voltou o foco para o campo e-mail; 3) ao teclar “enter”, passou o foco para o botão salvar;
6.3.2 INVENTÁRIO
· FAZER A PARTIR DAQUI O PONTO 6
7. PROGRAMAÇÃO ORIENTADA À OBJETOS
	A primeira linguagem de programação que utilizou os conceitos de programação orientada à objetos foi a Simula 67, criada por Ole Johan Dahl e Kristen Nygaard em 1967, porém esse paradigma de programação só passou a ser largamente utilizado na atualidade. A maioria das linguagens de programações atuais utilizam orientação à objetos, podendo citar: Java, C#, C++, Delphi, entre outras, que apesar de terem diferenças entre si, seguem os mesmos princípios e conceitos.
	A ideia principal da POO é aproximar o mundo real do mundo virtual, ou seja, uma simulação de episódios do cotidiano replicados no computador. O programador deve retratar através de objetos e a interação entre esses objetos, soluções para problemas reais, transcritos em uma linguagem de programação. Uma das grandes vantagens da programação orientada à objetos está na facilidade de fazer manutenções em sistemas legados, deixando seu custo menor em relação a outras formas de programação, além da reutilização contínua de código.
	Os principais conceitos da POO são: objetos, classes, herança e polimorfismo.
7.1 CLASSES E OBJETOS
	Um objeto é uma parte do sistema de computador, que possui em suas propriedades um conjunto de dados e procedimentos para manipulação desses dados. Pode-se dizer que um sistema com orientação à objetos é a soma de diversos “objetos” que se comunicam, em conjunto ou individualmente, para resolução de problemas.
	Do ponto de vista da programação. Um objeto pode ser comparado à uma variável em uma programação convencional. A variável possui um espaço em memória que armazena seu estado atual (valor), e possui um conjunto de operações e comandos que podem ser aplicados a ela. Da mesma forma um objeto, adquire um espaço em memória para guardar seu estado atual (valor), podendo ser aqui, um conjunto de atributos, além de um conjunto de operações que podem ser aplicados ao objeto (chamados aqui de métodos).
	As classes definem um tipo de dado no sistema, sendo formada por dados (atributos) e comportamentos (métodos). Após a definição de uma classe, vários objetos podem ser criados a partir da mesma, ou seja, a classe é o elemento que dá a forma para os objetos. No sistema de reservas de equipamento temos a classe “Cadastro”, “Excluir” e “Salvar e Novo”. A partir da classe “Cadastro” foram criados os objetos “Cadastro de Usuários”, “Inventário” e “Reservas”.
7.2 HERANÇA E POLIMORFISMO 
	A herança e o polimorfismo surgem com o objetivo de reutilização de códigos implementados previamente, a fim de diminuir o tempo de implementações futuras e repetição de código fonte. Remetendo às classes e objetos anteriormente especificados, quando se cria um objeto ou uma nova classe a partir de uma classe mãe, o objeto ou classe filhos “herda” todos os atributos e métodos da classe mãe, dessa forma não existe a necessidade de reprogramação dos métodos pré-existentes. Chamamos essas características de herança.
	O polimorfismo tem como significado “várias formas”. Para a programação orientada à objetos, pode-se entender que polimorfismo é a característica de um método ou atributo de possuir comportamentos diversos ou apresentar diferentes formas em sua execução e resposta, podendo ser utilizado em classes diversificadas da sua hierarquia.
	Ainda sobre o projeto do sistema de equipamentos para reserva do CVS, a classe “Cadastro” comporta os atributos e a implementação dos métodos “Cancelar”, “Excluir” e “Salvar e Novo” estão contidas nela, não sendo necessário implementar tais métodos nos objetos filhos “Cadastro de Usuários”, “Inventário” e “Reservas”, utilizando assim, herança e polimorfismo na projeção do sistema.
 
CONCLUSÃO
	A partir da demanda do CVS em adquirir um software para controle das reservas de seus equipamentos audiovisuais, cria-se a oportunidade de oferta de produzir este sistema. Cria-se a necessidade de um projeto para mapear e planejar toda a extensão dessa contratação, incluindo previsão de orçamento, 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 dos usuários ao executarem a tarefa na reserva dos equipamentos e na interação entre eles. Constatou-se a necessidade do sistema em assegurar umcontrole dos equipamentos do colégio, através de seus cadastros, controle de reservas e avisos. Foi também especificada a interface do sistema para obter aprovação junto aos usuários finais.
	Como o surgimento da oportunidade na produção do sistema de reservas pode vir a crescer e tornar-se mais complexo, desde seu início será atualizada a metodologia MPS-BR, em seu primeiro nível (G – Parcialmente Gerenciado), para que quando houver crescimento, a empresa já tenha em sua essência a aplicação de metodologias para constante melhora dos produtos.
	A utilização de testes bem documentados e prototipação de alta fidelidade visa entrega de um sistema com a melhor usabilidade possível, de fácil aprendizagem, e que caia no gosto dos usuários, mas principalmente, seja seguro e confiável.
	Por fim, a utilização de uma programação orientada à objetos será parte deste projeto, visando diminuição no tempo de codificação, reutilização de código fonte, utilizando classes, herança e polimorfismo em sua constituição, gerando ainda custos menores na produção do sistema.
Meses	Planejamento	Desnvolvimento	teste e entrega	8.1999999999999993	3.2	1.4