SUGESTÕES DE TRABALHOS FUTUROS

A partir deste trabalho, outros trabalhos podem ser desenvolvidos utilizando a mesma base de programação, todas buscando melhorar esta aplicação e agregar conhecimento, tais como:

 Criação de um Banco de Dados em um servidor ou na nuvem;  Criar mecanismos compatíveis com sistemas tributários;

 Criação de um novo Design para o programa, considerando a sua utilização em Smartphones;

 Importação e Exportação de informações com outros programas, como Excel; e,

 Criação de modelos de proposta no próprio programa, buscando informações no Banco de Dados e inserindo em propostas comerciais.

REFERÊNCIAS

DEITEL, H. M. Java, como programar. Editora Bookman: Porto Alegre, 2003.

DIAS, P. R. V. Engenharia de Custos: Uma metodologia de orçamentação para obras civis. 9ª Ed. Sindicato das Editoras de Livros: Rio de Janeiro, 2011.

FILHO, J. M. Instalações Elétrica Industriais. Editora LTC: Rio de Janeiro, 2004.

GEHBAUER, F. Planejamento e Gestão de Obras. Editora CEFET-PR: Curitiba, 2002.

GONZÁLEZ, M. A. S. Noções de Orçamento e Planejamento de Obras. 49f. (Notas de Aula) – Universidade do Vale do Rio dos Sinos. São Leopoldo, 2008.

ENGWHERE, 2015. Disponível em:

<<http://www.engwhere.com.br/software/software.htm>>. Acesso em: 25 de setembro de 2015.

HORSLEY, D. Process Plant Comissioning: A User Guide. Editora Institue of Chemical Engineering, 1998.

IBEC, Fórum de BDI e Gerenciamento de Alteração de Escopo. Instituto Brasileiro de Engenharia de Custos: Rio de Janeiro, 2014.

KON, A. Desenvolvimento regional e trabalho no Brasil. São Paulo: Associação Brasileira de Estudos do Trabalho, 1998. 140p. (Coleção ABET – Mercado de trabalho, 2)

LEFFINGWELL, D. Scaling Software Agility: Best Practices for Large Enterprises. Editora Addison-Wesley Professional, 2007.

MANDEL, T. The Elements of User Interface Design. Editora Wiley, 1997.

MARTIN, R. C. Clean Code: A Handbook of Agile Software Creaftsmanship. Editora Prentice Hall: Boston, 2009.

MATTOS, A. D. Como Preparar Orçamentos de Obras. Editora Pini: São Paulo, 2006.

MATTOS, A. D. Planejamento e Controle de Obras. Editora Pini: São Paulo, 2010.

MENDES, D. R. Programação Java: com Ênfase em Orientação a Objetos. Editora Novatec. 2015. Disponível em:

<http://novatec.com.br/livros/javaoo/capitulo9788575221761.pdf>>. Acesso em: 25

de setembro de 2015.

MSDN, 2015. Disponível em: <<https://msdn.microsoft.com/pt-br/default.aspx>>. Acesso em: 25 de setembro de 2015.

PMBOK, Um Guia do Conhecimento em Gerenciamento de Projetos (GUIA PMBOK). Editora Saraiva: São Paulo, 2012.

PORTUGAL, M. A. Como Gerenciar Projetos de Construção Civil: Do orçamento à entrega de obra. Editora Brasport: Rio de Janeiro, 2017.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. Editora AMGH: Porto Alegre, 2011.

RAMOS, L.; REIS, J.G.A. Emprego no Brasil nos anos 90. Rio de Janeiro: IPEA, 1997. 28p. (Texto para discussão, 468).

SANTOS, L. C. Microsoft Visual C# 2010 Express: Aprenda a Programar na Prática. Editora Érica: São Paulo, 2010.

SOMMERVILLE, I. Engenharia de Software. Editora Pearson Education do Brasil. São Paulo, 2011.

TCU, Obras Públicas: Recomendações Básicas para a Contratação e Fiscalização de Obras de Edificações Públicas. TCU: Brasília, 2014.

TISAKA, M. Orçamento na Construção Civil: Consultoria, projeto e execução. Editora Pini: São Paulo, 2006.

ANEXO A - TESTES

Segundo Sommerville (2011), o processo de teste de software possui dois objetivos distintos:

1. Demonstrar ao desenvolvedor e ao cliente que o software atende a seus requisitos;

2. Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou de forma diferente das especificações.

No primeiro caso, quando softwares customizados são programados, deve haver pelo menos um teste para cada requisito do documento de requisitos previamente analisado (SOMMERVILLE, 2011).

No segundo caso, o teste de defeitos preocupa-se com a “... eliminação de comportamentos indesejáveis do sistema, tais como panes, interações indesejáveis com outros sistemas, processamentos incorretos e corrupção de dados” (SOMMERVILLE, 2011),

O primeiro caso pode ser chamado de “Teste de Validação” e o segundo caso “Teste de Defeitos”. No Teste de Validação, entradas desejadas que estão dentro de um universo possível de opções entram no sistema e analisa-se a saída do sistema, caso o que sair estiver de acordo com o esperado o programa passou no Teste de Validação. Agora considerando um caso em que uma entrada do sistema não estiver prevista, não estando dentro de um universo possível de opções previstas, é desejável analisar se o software será ou não estável, se ele continuará funcionando adequadamente ou não. Neste caso se utiliza o Teste de Defeitos.

Este capítulo se preocupará com o segundo caso, Teste de Defeitos. O capítulo 5 será um estudo de caso em empresa mantida em anonimato.

A.1 LOGIN

O programa será executado a partir da pasta “Debug”. Para isso é necessário que todos os documentos permaneçam nesta pasta. Um atalho poder ser criado na área de trabalho.

Como o programa funciona conjuntamente com a plataforma “Windows framework 4.5” em modo Debug, não existe a necessidade de instalá-lo no sistema, bastando que o Microsoft SQL Server 2014 (Banco de Dados) esteja instalado no computador.

O Visual Studio gera a pasta originalmente no disco D: e se encontra em “D:\Documentos\SVR_03\SVR_03\SVR_03\Ebudget\SVR_03\bin”.

Figura 73 – Pasta Debug Fonte: Autor (2017).

Em outros computadores a pasta “Debug” pode ser colocada em qualquer pasta e em qualquer disco rígido (interno). Ao abrirmos a pasta “Debug” encontramos os arquivos conforme figura 74.

Figura 74 – Arquivos Pasta Debug Fonte: Autor (2017).

Ao clicar-se em “SVR_03.exe” a tela de login deverá ser apresentada. O arquivo original deste TCC possui apenas um usuário cadastrado e uma senha, sendo o usuário “Carlos” e a senha “carlos”.

Após copiar a pasta “Debug” e colocar em outra pasta no disco rígido e clicando em “SVR_03.exe” o programa inicia, conforme figura 76.

Figura 75 – Pasta Debug em outro local do disco Fonte: Autor (2017).

Figura 76 – Login do Programa Fonte: Autor (2017).

Caso a senha estiver incorreta, a tela ficará conforme figura 77.

Figura 77 – Senha incorreta Fonte: Autor (2017).

Similarmente a isso, caso o usuário estiver incorreto o programa também não inicializará, conforme figura 78.

Figura 78 – Usuário incorreto Fonte: Autor (2017).

Caso as informações informadas estejam corretas, o programa deve iniciar normalmente e apresentar a tela inicial da figura 79.

Figura 79 – Tela Inicial do Programa Fonte: Autor (2017).

O nome Ebudget foi escolhido para este TCC para que o programa desenvolvido não ficasse sem nome próprio. A ideia surgiu da palavra “Budget” que traduzida do inglês para o português significa orçamento. A letra “E” à frente faz menção a Elétrica em geral.

A.2 CADASTROS

No capítulo 3, durante a criação do Primeiro Incremento (Interface) foi explicado o funcionamento das telas, por isso, essa parte do trabalho se encarrega apenas de mostrar os testes.

Na tela inicial ao clicarmos em cadastros aparecerão as opções:  Clientes;  Fabricantes;  Fornecedores;  Mão de Obra;  Materiais;  Serviços;  Unidades; e,  Usuários. A.2.1 Clientes

Considerando que já estão cadastrados dois clientes no sistema, figura 80, o próximo a ser cadastrado, seguindo a ordem, receberá o código “3”.

Figura 80 – Tela Inicial do Programa Fonte: Autor (2017).

Para isto basta clicar na aba “Cadastro de Clientes”, preencher com as informações e clicar em “Salvar” (figura 81).

Figura 81 – Cadastro Cliente Teste 3 Fonte: Autor (2017).

Para verificar se o cliente foi cadastrado corretamente basta clicar na aba consulta (figura 82).

Figura 82 – Cliente Teste 3 cadastrado Fonte: Autor (2017).

Caso algum cliente sofra alguma alteração de endereço, telefone, dentre outros, as informações precisam ser alteradas. Para testar se o programa consegue efetuar as alterações necessárias, clicou-se duas vezes na empresa a sofrer alterações e as novas informações foram inseridas, o botão “Alterar” foi selecionado e a mensagem foi apresentada (figura 83).

Figura 83 – Alteração Cliente 1 Fonte: Autor (2017).

A figura 82 apresenta as informações da empresa Cliente Teste 1 antes de sofrer as alterações e a figura 84 apresenta o novo endereço e CPF, bastando confrontar as informações da figura 82 e figura 84.

Figura 84 – Consulta Alteração Cliente 1 Fonte: Autor (2017).

Com o intuito de verificar se o programa consegue excluir um cliente, um duplo clique selecionou na aba “Consulta” a empresa “Cliente Teste 3” e o botão Excluir, figura 85, foi clicado.

Figura 85 – Exclusão Cliente 3 Fonte: Autor (2017).

Verificou-se, figura 86, a exclusão do cliente do sistema.

Figura 86 – Cliente Teste 3 excluído Fonte: Autor (2017).

Após executar os testes verificou-se o correto funcionamento do castro de clientes no sistema.

A.2.2 Fabricantes

O banco de dados, figura 87, não possuía fabricantes cadastrados.

Figura 87 – Banco de Dados sem Fabricantes Cadastrados Fonte: Autor (2017).

Para efeito de teste, cadastrou-se 3 empresas, conforme pode ser verificado na figura 88.

Figura 88 – Banco de Dados com 3 Fabricantes Cadastrados Fonte: Autor (2017).

Realizou-se a alteração na informação das fabricantes 2 e 3 (figura 89). e excluiu-se a fabricante 2 (figura 90).

Figura 89 – Banco de Dados após sofrer alterações Fonte: Autor (2017).

Figura 90 – Fabricante 2 excluído Fonte: Autor (2017).

A.2.3 Fornecedores

O banco de dados, figura 91, não possuía fornecedores cadastrados.

Figura 91 – Nenhum Fornecedor Fonte: Autor (2017).

Para efeito de teste cadastrou-se 2 empresas, conforme figura 92.

Figura 92 – Dois Fornecedores Fonte: Autor (2017).

Realizou-se a alteração na informação do fornecedor 2 na figura 93

Figura 93 – Fornecedor 2 alterado Fonte: Autor (2017).

A figura 94 apresenta a exclusão do fornecedor 1.

Figura 94 – Fornecedor 1 excluído Fonte: Autor (2017).