UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ - UTFPR DEPARTAMENTO ACADÊMICO DE ELETROTÉCNICA - DAELT ENGENHARIA INDUSTRIAL ELÉTRICA ÊNFASE ELETROTÉCNICA
CARLOS ALBERTO SIEVERS
DESENVOLVIMENTO DE SOFTWARE APLICÁVEL À ORÇAMENTOS
DE OBRAS ELÉTRICAS
TRABALHO DE CONCLUSÃO DE CURSO
CURITIBA 2017
CARLOS ALBERTO SIEVERS
DESENVOLVIMENTO DE SOFTWARE APLICÁVEL À ORÇAMENTOS
DE OBRAS ELÉTRICAS
Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do título de Engenheiro Eletricista pelo Departamento Acadêmico de Eletrotécnica – DAELT - da Universidade Tecnológica Federal do Paraná.
Orientador: Prof. Me. Ubirajara Zoccoli
CURITIBA 2017
Carlos Alberto Sievers
Desenvolvimento de software aplicável à orçamentos de obras
elétricas
Este Trabalho de Conclusão de Curso de Graduação foi julgado e aprovado como requisito parcial para a obtenção do Título de Engenheiro Eletricista, do curso de Engenharia Industrial Elétrica ênfase Eletrotécnica do Departamento Acadêmico de Eletrotécnica (DAELT) da Universidade Tecnológica Federal do Paraná (UTFPR).
Curitiba, 30 de novembro de 2017.
____________________________________ Prof. Emerson Rigoni, Dr.
Coordenador de Curso
Engenharia Industrial Elétrica ênfase Eletrotécnica
____________________________________ Profa. Annemarlen Gehrke Castagna, Mestre Responsável pelos Trabalhos de Conclusão de Curso de Engenharia Industrial Elétrica ênfase Eletrotécnica do DAELT
ORIENTAÇÃO BANCA EXAMINADORA
______________________________________ Ubirajara Zoccoli, Me.
Universidade Tecnológica Federal do Paraná Orientador
_____________________________________ Luciane Brandalise, Dra.
Universidade Tecnológica Federal do Paraná
_____________________________________ Marcelo Rodrigues, Dr.
Universidade Tecnológica Federal do Paraná
_____________________________________ Marcio Aparecido Batista, Me.
Universidade Tecnológica Federal do Paraná A folha de aprovação assinada encontra-se na Coordenação do Curso de Engenharia Industrial Elétrica Ênfase
AGRADECIMENTOS
Agradeço a todos os professores que me proporcionaram conhecimento, não apenas racional, mas a manifestação do caráter e afetividade da educação no processo de formação profissional.
Agradeço ao professor Me. Ubirajara Zoccoli, que teve a paciência e conhecimentos necessários para me orientar neste estudo.
Agradeço a minha mãe e meu pai, pelo amor, incentivo e apoio incondicional.
Obrigado aos nossos colegas de caminhada.
Obrigado a todos que de alguma forma estiveram em meu caminho e me apoiaram em meu estudo e dedicação.
Agradeço a Deus por ter me dado saúde e força para superar todas as dificuldades.
RESUMO
SIEVERS, Carlos A. Desenvolvimento de software aplicável à orçamentos de obras elétricas. Trabalho de Conclusão de Curso – UTFPR – Universidade Tecnológica Federal do Paraná, Curso Superior de Engenharia Industrial Elétrica ênfase Eletrotécnica, Curitiba, 2017. 129p.
O estudo aqui apresentado visa desenvolver um programa que permita a melhoria no processo da criação de orçamentos de pequenas e médias empresas que direcionam os seus serviços para a área elétrica. Propõe-se a implementação de um programa que possua um Banco de Dados contendo informações atualizáveis a respeito de preços de materiais, mão de obra e serviços, buscando com isso a redução do tempo para a elaboração do orçamento, agilizando a entrega da proposta comercial da empresa e trazendo maior confiabilidade no valor final da obra a ser orçada. Um estudo inicial a respeito de elaboração de preços de obras é apresentado, trazendo os conceitos básicos a serem observados para a elaboração do preço final de venda de cada item a ser inserido no Banco de Dados. O trabalho analisa a seguir alguns conceitos básicos de Programação Orientada a Objetos (POO), com um foco na linguagem C# (C Sharp) e apresenta o ambiente de programação Visual Studio 2013, ambiente este onde foi desenvolvido o programa denominado Ebudget, sendo o “E” relacionado a área elétrica e a palavra inglesa “budget” significando orçamento em português. Um breve estudo da criação de um banco de dados será apresentado na sequência. Após o enfoque conceitual inicial, foi desenvolvido o programa em questão. Como resultado, o estudo apresenta um programa funcional com Banco de Dados Local, permitindo ao usuário a criação de orçamentos de forma rápida e intuitiva, através do acesso ao Banco de Dados e das informações lá armazenadas.
Palavras-chave: Software, Orçamento, Banco de Dados, Programação Orientada a Objetos, Linguagem C Sharp, Microsoft Visual Studio.
ABSTRACT
SIEVERS, Carlos A. Development of applicable software to budgets of electrical works. Trabalho de Conclusão de Curso – UTFPR – Universidade Tecnológica Federal do Paraná, Curso Superior de Engenharia Industrial Elétrica ênfase Eletrotécnica, Curitiba, 2017. 129p.
This study is aimed to develop a computer program which allows the improvement of the process of creating budgets of small and medium-sized enterprises which direct their services to an electrical area. It is proposed the implementation of a computer program which has a Database containing updatable information regarding prices of materials, labor and services, seeking thereby the reduction of time for the preparation of the budget, expediting the delivery of the company's commercial proposal and bringing greater reliability in the final value of the work to be budgeted. An initial study regarding the elaboration of works price is presented, bringing the basic concepts to be observed for the elaboration of the final sale price of each item to be inserted in the Database. This work examines some basic concepts of Object Oriented Programming (OOP), with a focus on the C # language (C Sharp) and presents the Visual Studio 2013 programming environment, where the Ebudget program will be created, being the "E" related to electrical area and the English word "budget" meaning budget in Portuguese. A brief study of the creation of a database will be presented in the sequence. After the initial conceptual focus, it was developed the program in question. As a result, it presents a functional software with Local Database, allowing the user to create budgets quickly and intuitively, through access to the Database and the information stored there.
Keywords: Sofware, Budget, Database, Object Oriented Programming, C Sharp Language, Microsoft Visual Studio.
LISTA DE FIGURAS
Figura 1 – Etapas da orçamentação ... 29
Figura 2 – Modelo Cascata segundo Sommerville ... 39
Figura 3 – Modelo Cascata segundo Pressman... 39
Figura 4 – Modelo V ... 40
Figura 5 – Modelo Incremental ... 41
Figura 6 – Modelo de Processos Concorrentes ... 41
Figura 7 – O Processo de Extreme Programming (XP) ... 42
Figura 8 – Modelos baseados em Cenário de Requisitos ... 45
Figura 9 – Estratégia de Teste ... 49
Figura 10 – Etapas para compilação e execução de um programa Java ... 52
Figura 11 – Microsoft Visual Studio Express 2013. ... 53
Figura 12 – Tela Inicial. ... 56
Figura 13 – Tela New Project. ... 57
Figura 14 – Área de trabalho/desenvolvimento do Visual Studio 2013. ... 57
Figura 15 – Tela de Login... 58
Figura 16 – Tela Inicial. ... 59
Figura 17 – Tela Cadastro de Clientes. ... 59
Figura 18 – Tela Cadastro de Clientes. ... 60
Figura 19 – Tela Cadastro de Clientes ... 60
Figura 20 – Tela Cadastro de Clientes ... 61
Figura 21 – Cadastro de Fabricantes ... 61
Figura 22 – Cadastro de Fornecedores ... 62
Figura 23 – Cadastro de Mão de Obra ... 62
Figura 24 – Cadastro de Materiais ... 63
Figura 25 – Cadastro de Materiais ... 63
Figura 26 – Cadastro de Serviços ... 64
Figura 27 – Cadastro de Unidades ... 65
Figura 28 – Cadastro de Usuários ... 65
Figura 29 – Movimentações ... 66
Figura 30 – Orçamentos ... 66
Figura 31 – Consultar ... 66
Figura 32 – Relatório ... 67
Figura 33 – Orçamentos para Consulta em PDF ... 67
Figura 34 – Criação do Banco de Dados ... 68
Figura 35 – Nome do Banco de Dados ... 68
Figura 36 – Adicionando Tabelas ... 69
Figura 37 – Adicionando Tabelas ... 69
Figura 39 – Tabela CIDADES sem informações ... 70
Figura 40 – Tabela CIDADES ... 70
Figura 41 – Tabela ESTADO... 71
Figura 42 – Tabela ESTADO... 71
Figura 43 – Tabela FABRICANTES ... 72
Figura 44 – Tabela FORNECEDORES ... 72
Figura 45 – Tabela MAO_DE_OBRA ... 72
Figura 46 – Tabela MATERIAIS ... 73
Figura 47 – Tabela ORCAMENTO ... 73
Figura 48 – Tabela ORCAMENTO_ITEM ... 73
Figura 49 – Tabela SERVICOS ... 74
Figura 50 – Tabela SERVICOS_MAO_DE_OBRA ... 74
Figura 51 – Tabela SERVICOS_MATERIAIS... 74
Figura 52 – Tabela UNIDADE_MEDIDA ... 74
Figura 53 – Tabela USUARIOS ... 75
Figura 54 – Solution Explorer do Projeto ... 76
Figura 55 – Classe CadastroCliente ... 76
Figura 56 – Estrutura do Código Classe CadastroCliente ... 77
Figura 57 – Final do Código Classe CadastroCliente ... 78
Figura 58 – Pasta Layers ... 79
Figura 59 – Pasta Model ... 79
Figura 60 – Pasta DAO ... 80
Figura 61 – Classes Clientes... 80
Figura 62 – Tabela CLIENTES no Banco de Dados ... 81
Figura 63 – Classes BancodeDados.cs e ClientesDAO.cs ... 81
Figura 64 – Pasta Controller... 82
Figura 65 – Start Debug ... 83
Figura 66 – Executando o Debug ... 83
Figura 67 – Orçamento Código 4 ... 85
Figura 68 – Orçamento Código 5 ... 86
Figura 69 – Orçamento Código 6 ... 87
Figura 70 – Orçamento Código 7 ... 88
Figura 71 – Mecanismo de Busca em Funcionamento ... 89
Figura 72 – Problemas na visualização ... 90
Figura 73 – Pasta Debug ... 98
Figura 74 – Arquivos Pasta Debug ... 98
Figura 75 – Pasta Debug em outro local do disco ... 99
Figura 76 – Login do Programa ... 99
Figura 77 – Senha incorreta ... 99
Figura 78 – Usuário incorreto ... 100
Figura 80 – Tela Inicial do Programa ... 101
Figura 81 – Cadastro Cliente Teste 3 ... 102
Figura 82 – Cliente Teste 3 cadastrado ... 102
Figura 83 – Alteração Cliente 1 ... 103
Figura 84 – Consulta Alteração Cliente 1 ... 103
Figura 85 – Exclusão Cliente 3 ... 104
Figura 86 – Cliente Teste 3 excluído ... 104
Figura 87 – Banco de Dados sem Fabricantes Cadastrados ... 105
Figura 88 – Banco de Dados com 3 Fabricantes Cadastrados ... 105
Figura 89 – Banco de Dados após sofrer alterações ... 106
Figura 90 – Fabricante 2 excluído ... 106
Figura 91 – Nenhum Fornecedor ... 107
Figura 92 – Dois Fornecedores ... 107
Figura 93 – Fornecedor 2 alterado ... 108
Figura 94 – Fornecedor 1 excluído ... 108
Figura 95 – Nenhuma Mão de Obra cadastrada ... 109
Figura 96 – Mão de Obra cadastrada ... 109
Figura 97 – Alteração Preço de Venda (h) do Engenheiro ... 110
Figura 98 – Técnico excluído ... 110
Figura 99 – Funcionamento da Caixa de Pesquisa ... 111
Figura 100 – Preço de Venda antigo ... 111
Figura 101 – Novo Preço de Venda ... 112
Figura 102 – Cadastro de Material Teste ... 112
Figura 103 – Material Teste 1 cadastrado ... 113
Figura 104 – Exclusão de Material ... 113
Figura 105 – Material excluído ... 114
Figura 106 – Aba Consulta em Cadastro de Serviços ... 114
Figura 107 – Cadastro de Serviço ... 115
Figura 108 – Verificação de Cadastro de Serviço ... 115
Figura 109 – Exclusão de Serviço ... 116
Figura 110 – Confirmação de Serviço Excluído ... 116
Figura 111 – Consulta de Unidades ... 117
Figura 112 – Nova Unidade Cadastrada ... 117
Figura 113 – Confirmação do Cadastro de Nova Unidade ... 118
Figura 114 – Tela Consulta de Usuários ... 118
Figura 115 – Cadastro de um Novo Usuário ... 119
Figura 116 – Novos Usuário Cadastrados ... 119
Figura 117 – Exclusão de Usuário ... 120
Figura 118 – Verificação de um Usuário ... 120
Figura 119 – Aba Consulta em Orçamentos ... 121
Figura 121 – Utilização do Período de Pesquisa... 122
Figura 122 – Criação de Novo Orçamento ... 123
Figura 123 – Verificação de Novo Orçamento... 123
Figura 124 – Verificação de Fabricantes em Consultar ... 124
Figura 125 – Opções de Verificação na Aba Consultar ... 124
Figura 126 – Verificação de Fornecedores ... 125
Figura 127 – Orçamentos na Aba Relatório ... 125
Figura 128 – Relatório Orçamentos ... 126
Figura 129 – Visualizador de Orçamentos ... 126
Figura 130 – Opções de Salvamento ... 127
Figura 131 – Salvo em Excel ... 127
Figura 132 – Salvo em PDF ... 128
Figura 133 – Salvo em Word ... 128
LISTA DE EQUAÇÕES
Equação 1: Custo Homem-Hora ... 33
Equação 2: Preço de Venda... 35
Equação 3: BDI Percentual ... 36
LISTA DE TABELAS
Tabela 1: Exemplo de tabela de custo unitário... 32 Tabela 2: Tabela de custo unitário com eletricista ... 32
SIGLAS
AC - Administração Central
ASD - Adaptative software Development
AT - Alta Tensão
BD - Banco de Dados
BDI - Benefícios e Despesas Indiretas
BT - Baixa Tensão
C - Linguagem de programação C
C# - Linguagem de programação C Sharp
CAD - Computer Aided Design (Desenho Assistido por Computador)
CD - Custo Direto
CF - Custo Financeiro
CI - Custo Indireto
DB - Data Base
DI - Despesas Indiretas
DSDM - Dynamics Systems Development Method EPI - Equipamento de Proteção Individual
HH - Homem Hora
IC - Imprevistos e Contingências
IMP - Impostos
kVA - Quilo Volt Àmpere
LO - Lucro Operacional
MSDN - Microsoft Developer Network MVA - Microsoft Virtual Academy
NBR 5410 - Norma Brasileira: Instalações elétricas de baixa tensão NTC - Normas Técnicas Copel
OO - Orientado à Objetos
PMBOK - Project Management Body of Knowledge POO - Programação Orientada à Objetos
PV - Preço de Venda
TCC - Trabalho de Conclusão de Curso XP - Extreme Programming
SUMÁRIO 1 INTRODUÇÃO ...15 1.1 TEMA ...16 1.1.1 Delimitação do Tema ...17 1.2 PROBLEMAS E PREMISSAS ...17 1.3 OBJETIVOS ...19 1.3.1 Objetivo Geral ...19 1.3.2 Objetivos Específicos ...19 1.4 JUSTIFICATIVA ...20 1.5 PROCEDIMENTOS METODOLÓGICOS ...21 2 REVISÃO DE LITERATURA ...22 2.1 PLANEJAMENTO DE OBRAS ...22 2.1.1 Importância do Planejamento ...22
2.1.2 Deficiências das empresas ...23
2.1.3 Ciclo de vida do projeto ...24
2.2 ORÇAMENTAÇÃO ...25 2.2.1 Considerações Gerais ...25 2.2.2 Graus do orçamento ...30 2.2.3 Composição de custos ...31 2.3 PROGRAMAÇÃO ...37 2.3.1 Engenharia de Software ...37 2.3.2 Modelos de Processo ...38 2.3.3 Desenvolvimento Ágil ...42
2.3.4 Princípios que Orientam a Prática ...44
2.3.5 Engenharia de Requisitos ...44
2.3.6 Modelagem de Requisitos ...45
2.3.7 Projeto de Interface do Usuário ...46
2.3.8 Teste de Software ...47
2.3.9 Programação Orientada a Objetos – POO ...49
2.3.10Linguagens de Programação ...51
3 DESENVOLVIMENTO DE SOFTWARE DE PROGRAMAÇÃO ...54
3.1 MODELO DE PROCESSO INCREMENTAL ...55
3.1.1 Primeiro Incremento: Interface ...56
3.1.2 Segundo Incremento: Banco de Dados ...68
3.1.3 Terceiro Incremento: Conexão entre Programa e Banco de Dados ...75
4 ESTUDO DE CASO...84
4.1 GERAÇÃO DE ORÇAMENTOS ...84
4.2 ANÁLISE DA EMPRESA ...88
5.1 SUGESTÕES DE TRABALHOS FUTUROS ...94 REFERÊNCIAS ...95 ANEXO A - TESTES ...97 A.1 LOGIN ...97 A.2 CADASTROS ...101 A.2.1 Clientes ...101 A.2.2 Fabricantes ...105 A.2.3 Fornecedores ...107
A.2.4 Mão de Obra ...109
A.2.5 Materiais ...111
A.2.6 Serviços ...114
A.2.7 Unidades ...117
A.2.8 Usuários ...118
A.3 MOVIMENTAÇÕES - ORÇAMENTO ...121
A.4 CONSULTA ...123
1 INTRODUÇÃO
Após a abertura econômica brasileira durante governo de Fernando Collor de Mello (1990), e da consequente falta de competitividade das empresas brasileiras perante as multinacionais, o que levou à falência diversas empresas em nosso país, houve, finalmente, o entendimento de que a produtividade seria algo fundamental para a sobrevivência de toda atividade econômica brasileira (KON, 1998). Especialmente após o controle da inflação e de políticas menos conservadoras, a competitividade entre empresas de diversos ramos de nossa economia se aflorou e a busca por novos mecanismos que trouxessem vantagem competitiva em relação aos concorrentes se intensificou.
Após o governo Itamar Franco e durante o governo de Fernando Henrique Cardoso, diversas empresas de grande porte se instalaram no Brasil, muitas delas multinacionais. Segundo Ramos & Reis (1997), novas tecnologias, produtos de qualidade e principalmente novas filosofias organizacionais tiveram de ser empregadas.
As multinacionais aqui instaladas terceirizaram muitos dos seus serviços, o que exigiu das terceiras a assimilação de parte ou da totalidade de suas filosofias de trabalho, focadas na produtividade, organização e parametrização de informações (Ramos & Reis, 1997).
Esta mudança do cenário nacional brasileiro ofereceu um novo campo de oportunidades, em especial para a engenharia de obras, na criação de ferramentas para o seu auxílio e gerenciamento; popularizando a utilização de ferramentas de Computer Aided Design (CAD) para a fase de projeto e popularizando a utilização dos computadores que finalmente se tornaram acessíveis para grande parte das empresas de médio e grande porte (MATTOS, 2006).
No final dos anos 90, grandes corporações brasileiras já haviam feito investimentos em gerenciamento e incorporado filosofias que buscassem a oferta da qualidade em seus processos. Nesta época surgiram algumas ferramentas para o processo de orçamentação focadas em obras civis. Uma dessas ferramentas é o programa EngWhere Magma (lançado em 1997) da empresa EngWhere. Este programa é dedicado a orçamentos de obras civis, e possui características que melhoram o desempenho e descomplicam a tarefa de orçamentação dentro da empresa (ENGWHERE, acesso em 5 de maio de 2015).
Após o desenvolvimento da programação no Brasil e após a popularização dos computadores em todas as empresas de engenharia, equipes destinadas exclusivamente para o desenvolvimento de orçamentos se tornaram comuns em grandes organizações. Estas equipes utilizam obras anteriores como base para atribuir tempo às tarefas, assim como material e custo, agilizando o trabalho de orçamentação e entrega da proposta final (MATTOS, 2006).
Segundo Mattos (2006), em empresas menores, normalmente o próprio dono, utilizando apenas a experiência adquirida cria a proposta sem levar em consideração detalhes de instalação ou projeto que possam inviabilizar determinada obra, vindo a causar o abandono da obra e até mesmo a falência da empresa.
1.1 TEMA
Em geral, os softwares hoje existentes no mercado visam o desenvolvimento de orçamentos para construção civil, detalhando os serviços de construção de paredes, colocação de pisos, transporte de material como tijolos e areia, além de outros. Porém, itens que dependam de infraestrutura elétrica são deixados de lado e terceirizados por estas construtoras, sendo adicionadas como um único item chamado por vezes como serviços de infraestrutura elétrica, sendo-lhe atribuído um valor global para a tarefa, sem maiores detalhamentos.
Segundo Mattos (2006), algumas instaladoras de serviços elétricos e de lógica, doravante chamadas apenas de instaladoras, possuem planilhas em Excel que auxiliam na confecção do preço dos serviços, mas mesmo estas planilhas não levam em consideração todos os detalhes do levantamento total do serviço, como encargos tributários e despesas indiretas.
Nesta perspectiva, objetivando suprir a necessidade das instaladoras com uma ferramenta que possibilite maior segurança na elaboração do preço final do serviço, assim como propiciar maior agilidade neste processo, propõe-se a criação de um programa destinado a organizar as tarefas de instalação elétrica, assim como conter os custos diretos e indiretos destes serviços.
1.1.1 Delimitação do Tema
Considerando por instalação elétrica qualquer atividade em que exista a necessidade de serviços para a instalação física de qualquer componente e/ou material que execute algum serviço elétrico (FILHO, 2004).
Segundo a NBR 5410 (2004), “componente (de uma instalação elétrica): Termo empregado para designar itens da instalação que podem ser acessórios, dispositivos, instrumentos, equipamentos...”.
Estes componentes e/ou materiais podem ser instalados em diversos tipos de instalação como supermercados, casas, prédios comerciais, prédios residenciais, postos de gasolina, subestações, etc. (FILHO, 2004).
Desta forma, a área de instalação elétrica é, portanto, ampla, possuindo diversas subáreas das quais podemos citar instalação em sistemas de geração, transmissão e distribuição de energia, em alta tensão (AT) ou baixa tensão (BT) (FILHO, 2004).
O desenvolvimento de um programa que abranja todo esse leque de opções se torna impraticável em um único Trabalho de Conclusão de Curso (TCC). Desta forma este trabalho de pesquisa visa examinar as instalações elétricas em baixa tensão até 75 kVA, com proteção máxima de disjuntor trifásico de 200 A, residenciais e comerciais, segundo as Normas Técnicas da Copel Distribuição (NTC), detalhando os componentes e serviços principais de uma instalação elétrica de BT de forma que seja possível mensurar isoladamente cada um deles, atribuindo uma abordagem qualitativa e também quantitativa no processo, permitindo que como resultado final seja entregue o produto orçamento, incluindo os serviços diretos e também indiretos.
1.2 PROBLEMAS E PREMISSAS
Segundo González (1998), existe uma relação entre prazo de execução e custo de uma obra, ou seja, a quantia fornecida pelo cliente, os recursos da obra, definem o andamento da obra, o seu prazo de entrega. Este por sua vez, ditam os
custos fixos mensais da instalação além dos custos indiretos de gerenciamento e de serviços como andaimes e equipamentos de segurança dentre outros.
A estimativa de custos e o estabelecimento do preço de venda do serviço é dependente de diversos fatores. Segundo Tisaka (2006), “Para o cálculo do preço de venda é necessário inicialmente levantar todos os custos diretos envolvidos numa construção civil e depois adicionar uma margem sobre ele...”. A margem sugerida por Tisaka visa cobrir todos os gastos excedentes e mais o lucro da obra.
Fica evidente a importância da observação atenta aos condicionantes gerais da obra a ser executada, traçando um plano geral e posteriormente detalhando cada um dos tópicos visando o detalhamento do serviço.
Segundo Mattos (2006), o preço final é composto por despesas diretas (mão de obra, equipamentos, materiais), despesas indiretas (equipes de supervisão, equipes de apoio, despesas gerais do canteiro de obras), impostos e lucro.
Segundo Mattos (2006), os problemas encontrados na estimava de valores em um orçamento consistem em:
1. Conhecimento técnico sobre os itens a serem orçados;
2. A correta identificação das características dos equipamentos e materiais, normalmente dimensionados para atendimento a normas específicas;
3. A correta descrição dos equipamentos e materiais levantados durante análise de projetos e atenção a atividade de identificação dos mesmos;
4. Correta quantificação do material necessário para completa execução do serviço, considerando em alguns casos uma quantia acima da estimada, já considerando perdas na instalação e perdas por alterações em projetos durante a obra, obrigando ao retrabalho de serviços;
5. Análise do trabalho com um enfoque em quantas horas serão necessárias para o término das atividades, já levando em consideração se o trabalho depende ou não de outras atividades. No segundo caso é necessário que a experiência técnica seja levada em consideração para que o tempo vendido de serviço (chamado de homem/hora) seja próximo do real;
O processo de criação de um orçamento é de importância fundamental para a execução de uma obra. Este processo requer tempo, conhecimento e organização das empresas que desejam ser competitivas atualmente.
Considerando o exposto acima, elaborou-se o seguinte problema a ser solucionado pelo presente projeto de pesquisa:
Como agilizar o processo de entrega de orçamentos levando-se em conta os custos diretos, indiretos, impostos a serem pagos e o lucro presumido em uma obra elétrica residencial e comercial de até 75 kVA em baixa tensão?
Uma alternativa para esta questão é a criação de um software modelo responsável por armazenar em seu banco de dados exemplo dos materiais frequentemente utilizados em obras elétrica residenciais e comerciais em baixa tensão, assim como informações sobre seu custo de compra e de venda, tempo de instalação (tempo de mão de obra) e custo de mão de obra.
1.3 OBJETIVOS
1.3.1 Objetivo Geral
Desenvolver um programa para orçamento de obras elétricas de até 75 kVA de demanda com proteção máxima de 200 A, visando agilizar a entrega do orçamento final.
1.3.2 Objetivos Específicos
Realizar estudo sobre o processo de Orçamentação: Estudo das Condicionantes, Composição de Custos, Fechamento do Orçamento; Verificar informações sobre planejamento de obras, custos diretos e
indiretos, assim como a possibilidade da utilização das informações da etapa de orçamento na execução de serviços;
Pesquisar sobre técnicas de armazenamento e utilização de informações em bancos de dados;
Apresentar informações sobre linguagens de programação orientadas a objetos;
Elaborar um programa que possibilite a entrega rápida de orçamentos; Realizar testes de funcionamento de software no Sistema Operacional
Windows 10; e,
Simular funcionamento do programa em empresa de engenharia, gerando alguns orçamentos e verificando as funcionalidades do programa.
1.4 JUSTIFICATIVA
O aumento da quantidade de empresas oferecendo serviços de instalação aumentou consideravelmente a partir dos anos 90, devido à redução dos tamanhos das empresas e do incremento da competitividade no setor (GONZÁLEZ, 2008). Porém, a qualidade dos serviços executados atualmente nem sempre é confiável, visto que muitas vezes o primeiro passo de uma obra, a orçamentação, é ignorado e deixado em segundo plano, proporcionando obras com materiais de qualidade inferior, mesmo que dentro das normas, para que se consiga algum lucro com o serviço, ou até mesmo proporcionando a falência de empresas quando itens significativos em valor são erroneamente analisados na proposta inicial (MATTOS, 2006). Desta forma a ajuda fornecida por um software que oriente as ações de orçamento de obra são essenciais para o sucesso da mesma.
Com o planejamento começando já na etapa de orçamentação, com o auxílio de uma ferramenta computacional, a estrutura básica da obra fica delineada, agilizando a entrega e diminuindo o risco de considerações falhas nos serviços (MATTOS, 2010).
O fator motivador para desenvolver este projeto é que as empresas de engenharia elétrica utilizam essencialmente planilhas em Excel para formação de preços em propostas comerciais, o que nem sempre é um processo ágil. Sem falar que muitos dos acessórios importantes que deveriam ser considerados com um grau suficiente de especificação no levantamento de preços em um orçamento são
considerados comumente apenas como uma verba, o que prejudica a qualidade da obra, reduz o lucro da empresa e muitas vezes produz custo desnecessário; pois muitos dos acessórios de instalação acabam não sendo adquiridos juntamente com o material a qual se destinam e consequentemente a obra sofre atraso (MATTOS, 2010).
1.5 PROCEDIMENTOS METODOLÓGICOS
A metodologia empregada no desenvolvimento da pesquisa consistiu em aspectos teóricos e práticos.
Os aspectos teóricos foram inicialmente direcionados a pesquisa sobre planejamento de obras. Na sequência um estudo sobre técnicas de orçamentação foi realizado. Posteriormente um estudo direcionado à área de programação se deu em três etapas: a primeira iniciando sobre os fundamentos de criação, manipulação e retirada de informações em banco de dados; a segunda sobre o desenvolvimento se software; e a terceira direcionada a escolha da linguagem de programação a ser utilizada no desenvolvimento do programa proposto por este trabalho.
O desenvolvimento prático levou em conta a criação do programa em questão, assim como testes de programação acerca de seu funcionamento. O programa tem acesso a um banco de dados com alguns exemplos dos itens comumente utilizados em instalações elétricas de baixa tensão, e seus atributos são acessíveis no menu do programa para escolha do item que corresponde ao necessário no projeto a ser orçado.
Testes foram realizados para verificar o funcionamento do programa, considerando o acesso ao banco de dados, por meio de tipos diferentes de usuários. Por se tratar de um programa modelo para orçamentação e pelo pouco tempo disponível, este trabalho trará apenas algumas simulações de orçamentos, o que é chamado normalmente de versão ALFA em softwares comerciais (PRESSMAN, 2011); ficando disponível para que outros alunos que se interessem em programação continuem o projeto.
2 REVISÃO DE LITERATURA
A revisão teórica deste capítulo se dará da seguinte forma. Primeiro foi discutido os aspectos básicos de planejamento de obras civis. Na sequência foi destacada a importância da orçamentação em obras e como esta técnica pode ser utilizada para produzir orçamentos de obras elétricas. Na parte final o enfoque foi a engenharia de software, focando conceitos básicos de Programação Orientada à Objetos (POO), banco de dados e desenvolvimento de softwares.
2.1 PLANEJAMENTO DE OBRAS
Segundo Mattos (2010), “O planejamento da obra é um dos principais aspectos do gerenciamento, conjunto de amplo espectro, que envolve também orçamento, compras, gestão de pessoas, comunicações, etc.”. Um planejamento mal executado pode colocar em risco o sucesso do empreendimento (MATTOS, 2010).
Verifica-se, portanto, a importância do planejamento para o sucesso da obra, ou empreendimento, e também da importância de cada um dos itens do planejamento, um dos quais o orçamento corretamente executado. Um planejamento bem executado aumenta as chances da sobrevivência das empresas em um mercado competitivo (MATTOS, 2010).
2.1.1 Importância do Planejamento
Um serviço bem planejado se inicia com o conhecimento da obra. Com a análise cuidadosa dos projetos, memoriais de cálculo e outros documentos que forneçam informações sobre o serviço a ser realizado, é possível determinar o período trabalhável, produtividades consideradas e todos os itens necessários para o sucesso do empreendimento (MATTOS, 2010).
A detecção de situações desfavoráveis é outro ponto a ser considerado durante o planejamento da obra, segundo Mattos (2010) “A previsão oportuna de situações desfavoráveis e de indícios de desconformidade permite ao gerente da obra tomar providências a tempo...”, o que minimiza os impactos destas situações.
Segundo Gehbauer (2002), “O planeamento prévio possibilita a disponibilização dos meios financeiros necessários...”. A relação com o orçamento também é um importante item no planejamento, visto que o casamento de informações pode identificar oportunidades de melhoria (MATTOS, 2010).
“Para que a execução de uma obra seja economicamente viável e ocorra sem falhas técnicas, devem ser evitadas improvisações no canteiro de obras” (GEHBAUER, 2002).
Para que improvisações sejam evitadas no canteiro de obras, faz-se necessária a correta distribuição de atividades entre todos os envolvidos. Portugal (2017) diz que “É preciso conhecer qual é a relação de cada parte dos processos necessários para execução do gerenciamento do projeto...”.
Gehbauer (2002) sinaliza que a comparação entre o previsto e o realizado facilita o gerenciamento da obra, já que é possível corrigir pequenos desvios antes que eles comprometam o prazo determinado.
A padronização dos serviços e a criação de dados históricos aumenta o profissionalismo da empresa e inspira confiança nos clientes (MATTOS, 2010).
Segundo Gehbauer (2002), o estudo da viabilidade do projeto deve ser verificado periodicamente, permitindo que qualquer desvio seja corrigido e diminuindo os riscos financeiros da instalação e consequente fracasso do orçamento.
2.1.2 Deficiências das empresas
A deficiência do planejamento de uma obra pode trazer prejuízos para a empresa, seja durante a análise dos projetos e documentos, seja no caso de um orçamento mal elaborado, estouros no orçamento podem levar até a sua falência (GONZÁLEZ, 2008).
Segundo Mattos (2010), duas das principais causas da deficiência em planejamento e controle de obras são o planejamento excessivamente informal e o mito do tocador de obras. No primeiro caso o planejamento não leva em conta todas as especificidades da obra, o que no decorrer do empreendimento acaba gerando dificuldades no seu controle, pois muitas ações que são tomadas para controlar a situação acabam não sendo as melhores possíveis, já que faltou planejamento. No
segundo caso, o tocador de obras se vale de sua experiência e acredita que pode controlar tudo de maneira natural, o que pode ocasionar problemas similares aos vistos no primeiro caso.
2.1.3 Ciclo de vida do projeto
Projetos, de modo geral, devem empregar materiais, equipamentos e pessoas de modo organizado e que passado determinado período de tempo resultem em um final esperado (PORTUGAL, 2017). Ou seja, cada passo realizado em um empreendimento será uma etapa a ser cumprida dentro de um planejamento. “A série de fases de um projeto é denominada de ciclo de vida do projeto” (PORTUGAL apud KEELLING, 2002).
Na construção civil é comum o termo projeto ser associado às plantas arquitetônicas, elétricas, hidráulicas, etc. Neste trabalho vamos considerar um projeto como “... um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo” (MATTOS apud PMBOK, 2010).
O projeto, conforme definição anterior, possui duas características importantes, a temporariedade (que significa que o projeto possui uma duração finita) e que ele é um produto único (que significa não se tratar de um produto em uma linha de montagem, mas de algo único) (MATTOS, 2010).
Segundo PMBOK (2012), os projetos possuem quatro estágios distintos entre si. O estágio 1 é denominado “Inicio do projeto”; neste estágio o escopo geral é definido; a formulação do empreendimento é determinada, ou seja, a forma com que cada atividade será realizada é formulada; os custos são verificados buscando a viabilidade do projeto; a fonte orçamentária é determinada; os elementos básicos necessários para orçamentos são identificados pelos anteprojetos.
No segundo estágio os projetos executivos detalhando todos os elementos à execução da obra são apresentados e a partir deles o orçamento analítico e o planejamento da obra são executados, esta etapa é chamada “Organização e Preparação”.
No estágio três a obra é iniciada. Sendo executadas as obras civis, montagens mecânicas e demais instalações. Esta etapa é denominada “Execução do Trabalho”.
O estágio quatro, também chamado de “Encerramento do Projeto” contempla o comissionamento, que segundo Horsley (1998), é o processo que assegura que a toda a instalação, considerando seus sistemas e componentes, estejam de acordo com as especificações constantes nos projetos através de testes, analisando se está operando e se mantendo de acordo com as necessidades. A inspeção final, seguida da transferência de responsabilidades e resolução das últimas pendências, além do termo de recebimento, finaliza a obra.
O planejamento de uma obra é de extrema importância para as empresas que visam a permanência em um mercado competitivo (GONZÁLEZ, 2008).
2.2 ORÇAMENTAÇÃO
2.2.1 Considerações Gerais
Em geral, o preço de venda de um serviço é a soma dos custos diretos, custos indiretos, impostos e lucro. Para encontrar todos esses valores é necessário considerar todas as fases do serviço a ser executado.
Portugal (2017) considera importante observar na formação do preço de venda as seguintes fases de um projeto:
Mobilização; Planejamento; Execução; e,
Desmobilização e encerramento.
Desta forma a orçamentação da obra se reveste de vital importância para o sucesso do empreendimento.
O orçamento, além de dar o valor de venda da obra, serve de subsídio para outros pontos importantes para a execução da obra. Segundo Mattos (2006), as aplicações são:
Levantamento dos materiais e serviços; Obtenção de índices para acompanhamento; Dimensionamento de equipes;
Realização de simulações;
Geração de cronogramas físico e financeiro; Análise da viabilidade econômico-financeira. 2.2.1.1 Orçamento e Orçamentação
“Orçamento não se confunde com orçamentação. Aquele é o produto; este, o processo de determinação” (MATTOS, 2006).
Segundo González (2008) “um orçamento é uma previsão (ou estimativa) do custo ou do preço de uma obra”. Ou seja, não existe a certeza de que o custo da obra seja exatamente o valor gasto para executá-la. Desta forma é necessária muita atenção a todos os pontos relevantes constantes em um orçamento para que esta “estimativa” se aproxime do valor real e de que este orçamento, no caso da concorrência ser ganha, possua aplicação conforme descrito anteriormente.
2.2.1.2 Orçamento nas empresas
Em pequenas empresas a experiência, normalmente do proprietário, é utilizada para realizar a estimativa de preços. Nestes casos a estimativa é realizada sem muitos detalhes e leva em conta a experiência do proprietário, que em geral é o executor de obras (MATTOS, 2006).
Em empresas maiores outros métodos são utilizados, tais como planilhas eletrônicas preenchidas com os itens relacionados aos serviços e seus respectivos valores e softwares dedicados a orçamentos (GONZÁLEZ, 2008). Nestas empresas o funcionário responsável pela criação do orçamento nem sempre possui experiência na execução de obras, o que acaba dificultando a correta análise de custos de mão de obra e de custos indiretos (MATTOS, 2006). Para minimizar o impacto desta falta de experiência do orçamentista, normalmente os valores e serviços são revisados por pessoal técnico de campo (GANZÁLEZ, 2008).
Segundo Mattos (2006), em grandes empresas, departamentos especializados em orçamento são responsáveis por controlar todas as informações relacionadas às obras, como exemplo pode-se citar:
Mão de obra necessária; Custo de materiais; Canteiro de obras; e, Outros.
O ideal é que os orçamentos sejam feitos por profissionais que conheçam não somente os custos de um serviço, mas também tenham experiência em execução do tipo de serviço a ser orçado, pois desta forma o valor do orçamento adotado será o mais próximo do valor real (DIAS, 2011).
2.2.1.3 Atributos do orçamento
Segundo Mattos (2006), “os principais atributos do orçamento são aproximação, especificidade e temporalidade”.
O primeiro atributo de orçamento diz que ele é aproximado e não exato, visto que todas as variáveis são estimadas. Segundo Mattos (2006), diversos itens se relacionam com o valor aproximado do orçamento:
Mão de obra: Que leva em conta a produtividade das equipes e encargos sociais e trabalhistas;
Material: Que considera o preço dos insumos, impostos, desperdício de materiais e reaproveitamento de materiais;
Equipamento: Que leva em consideração o custo horário e a produtividade;
Custos indiretos: Custo com pessoal de apoio e despesas gerais;
Imprevistos: Verba inserida no orçamento para suprir eventuais problemas de instalações, refazimento de serviços e serviços que não estavam explicitados adequadamente.
O atributo seguinte é a especificidade. Este atributo, segundo Mattos (2006), leva em consideração o fato de que o orçamento de uma obra realizada em uma cidade é diferente de qualquer outra obra igual, mas em cidades diferentes, visto que os custos são diferentes para cada caso.
O último atributo é a temporalidade, que, segundo Mattos (2006), “um orçamento realizado tempos atrás já não é válido hoje”. Isto por causa de reajustes em insumos, mão de obra, impostos dentre outros, que acabam exigindo uma adequação.
Dias (2011) considera na formação de preços a sazonalidade dos produtos, que segundo ele variam seus preços de acordo com a demanda.
Para o caso de um orçamento a ser realizado hoje, e que seja de uma obra igual à realizada no passado, devem ser analisados os insumos e serviços que sofreram alterações e corrigidos para a geração de um orçamento coerente com os valores atuais.
2.2.1.4 Enfoques do orçamento
Do ponto de vista do proprietário, o orçamento define o preço total do empreendimento. Para ele, o montante que será desembolsado ao longo do tempo e como será desembolsado ao longo do tempo são itens importantes (MATTOS, 2006).
Já do ponto de vista do construtor, o orçamento possui um caráter de planejamento da obra, já que ele deve se preocupar com o material que será gasto, as perdas, mão de obra, e todos os demais gastos quantificados e multiplicados pelos seus respectivos custos unitários (MATTOS, 2006).
2.2.1.5 Etapas da orçamentação
Segundo Mattos (2006), a primeira etapa da orçamentação é o “estudo das condicionantes”. Nesta etapa a leitura e interpretação do projeto, assim como as especificações técnicas são cuidadosamente analisadas. Outra leitura importante nesta etapa é a do edital da obra a ser realizada, sendo este “... o principal documento da fase de licitação” (MATTOS, 2006). Outro ponto importante nesta etapa é a visita técnica, já que nem sempre os projetos e o edital trazem todos os detalhes da obra bem delineados (GONZÁLEZ, 2008).
A segunda etapa, segundo Mattos (2006), é a “composição de custos”. Nesta etapa os principais pontos a serem observados são:
Identificação dos serviços; Levantamento de quantitativos; Discriminação dos custos diretos; Discriminação dos custos indiretos; Cotação de preços; e,
Definição de encargos sociais e trabalhistas.
A terceira etapa é o “fechamento do orçamento”. Segundo Mattos (2006), nesta etapa deve-se definir a lucratividade da obra, levando fatores como concorrência e risco do empreendimento e o cálculo do BDI.
A figura 1 fornece uma visão geral das etapas de orçamentação.
Figura 1 – Etapas da orçamentação Fonte: Mattos (2006).
2.2.2 Graus do orçamento
2.2.2.1 Grau de detalhe do orçamento
Segundo Mattos (2006), o orçamento pode ser classificado, de acordo com o grau de detalhamento, em:
Estimativa de custo; Orçamento preliminar; e,
Orçamento analítico ou detalhado. 2.2.2.2 Estimativa de Custos
Dias (2011) diz que: “A estimativa de custo deve ser utilizada em etapas iniciais dos estudos de um empreendimento, ou seja, na viabilidade econômica ou projeto básico...”, ou seja, ele serve apenas para ter-se uma ideia do custo global do serviço.
2.2.2.3 Orçamento preliminar
“O orçamento preliminar está um degrau acima da estimativa de custos, sendo um pouco mais detalhado. Ele pressupõe o levantamento expedito de algumas quantidades e atribuição do custo de alguns serviços” (MATTOS, 2006).
Uma característica orçamentária que pode ser utilizada neste orçamento é a estimativa de custos por etapa de obra, que, segundo Mattos (2006), decompõe a estimativa inicial percentualmente em cada etapa da obra.
2.2.2.4 Orçamento analítico
Segundo Mattos (2006), “o orçamento analítico constitui a maneira mais detalhada e precisa de se prever o custo da obra. Ele é efetuado a partir de composições de custos e cuidadosa pesquisa...”.
Por se tratar de um orçamento mais detalhado, faz-se necessária a utilização de formulários para preenchimento de dados de insumos, serviços, lucros e outras informações abordadas anteriormente.
De acordo com o TCU (2009), um orçamento detalhado de uma obra precisa conter:
Serviços necessários para a sua execução; Levantamento preciso dos quantitativos; Cálculo do custo unitário dos serviços; Cálculo do custo direto de uma obra; e, Estimativa dos custos indiretos e do lucro.
Este trabalho utilizará um banco de dados para o armazenamento de todas as informações necessárias para a criação de orçamentos analíticos. Os pontos a serem observados por este trabalho são:
Levantamento de Quantidades: Etapa que exige a análise de toda a documentação fornecida para levantamento de dimensões;
Critérios de medições e pagamentos: Verificado da documentação fornecida pelo cliente;
Perdas e reaproveitamento: Verificar no caso de reforma a possibilidade de reuso de materiais e tanto em reformas quanto em novos empreendimentos a existência de perdas de materiais; e,
Composição de custos: Levar em conta os custos unitários, mão de obra, encargos, custo do material, custo de equipamento, custo horário total, custo indireto, BDI, preço de venda.
2.2.3 Composição de custos
2.2.3.1 Custos unitários
Segundo Tisaka (2006), a Composição de Custos Unitários são as quantidades de material e de horas de equipamento, assim como o número de horas trabalhadas pela equipe para a execução de cada unidade desses serviços.
A tabela 1 mostra o exemplo de uma tabela de custo unitário em que um eletroduto que possui peça (pç) como unidade, condutor que possui metro (m) como unidade e um quadro elétrico com verba (vb) como unidade, possuem todos eles índices e seus custos unitários multiplicados dando o custo total de cada um destes insumos, que por sua vez ao serem somados geram o custo total.
Tabela 1: Exemplo de tabela de custo unitário
Insumo Unidade Índice Custo unitário Custo total
Eletroduto θ 1", 3 m pç 10 R$ 5,00 R$ 50,00 Condutor #10,0 mm², 750V m 73 R$ 12,00 R$ 876,00 Quadro Elétrico vb 1 R$ 2.500,00 R$ 2.500,00 Total R$ 3.426,00 Fonte: Autor (2017). 2.2.3.2 Mão de obra
A mão de obra é um insumo que pode ser inserido na tabela de custo unitário com unidade hora (h). Ao exemplo anterior, pode ser adicionado o tempo trabalhado por um eletricista para a instalação do quadro elétrico e dos 30 metros de eletroduto, e a passagem dos condutores também pelo eletroduto. Considerando que o tempo gasto foi de 4 horas a tabela 2 mostra a alteração do valor total do serviço.
Tabela 2: Tabela de custo unitário com eletricista
Insumo Unidade Índice Custo unitário Custo total
Eletroduto θ 1", 3 m pç 10 R$ 5,00 R$ 50,00 Condutor #10,0 mm², 750V m 73 R$ 12,00 R$ 876,00 Quadro Elétrico vb 1 R$ 2.500,00 R$ 2.500,00 Eletricista hr 4 R$ 20,00 R$ 80,00 Total R$ 3.506,00 Fonte: Autor (2017).
Segundo Tisaka (2006), o valor deste item é a soma do salário do funcionário, neste exemplo o eletricista, acrescido dos tributos e outras despesas. O custo unitário do serviço do eletricista não é o valor homem-hora (HH). Este deve levar em consideração os encargos sociais e trabalhistas, além de outras despesas que podem ser utilizadas para o valor de uma hora trabalhada do profissional como
Equipamento de Proteção Individual (EPI), alimentação, transporte (MATTOS, 2006).
Como exemplo para cálculo do HH, chama-se de hora-base o valor do serviço do eletricista no exemplo anterior, e considerando que após a consideração de todos os encargos sociais e trabalhistas, EPI e alimentação, chegou-se a conclusão de que o valor total do HH pode ser dado pela equação 1 a seguir:
Equação 1: Custo Homem-Hora
Fonte: Mattos (2006).
Considerando que todos os encargos correspondem a 80%, o valor total do HH fica em R$ 36,00.
2.2.3.3 Custo do material
Após a identificação e quantificação dos insumos a serem utilizados em uma obra, passa-se então à coleta de preços. Segundo Dias (2011), esta tarefa deve levar em conta a localização em que o serviço será realizado e das características sazonais dos insumos nesta localização. “Na engenharia de custos nenhum parâmetro deve ser considerado fixo para os contratos da empresa.” (DIAS, 2011).
Os materiais são representados por unidades de medida (TISAKA, 2006). Segundo Mattos (2006), “os principais aspectos que influenciam no preço de aquisição do insumo são”:
Especificações técnicas; Unidade e embalagem; Quantidade; Prazo de entrega; Condições de pagamento; Validade da proposta;
Local e condições de entrega; e,
2.2.3.4 Custo do equipamento
Segundo Tisaka (2006), “O custo horário do transporte e movimentação dos materiais e pessoas dentro da obra... geralmente incluem o custo horário dos operadores”. Desta forma em uma composição de preços, deve se estabelecer uma taxa horária considerando o tempo efetivamente trabalhado por um equipamento e o tempo improdutivo (MATTOS, 2006). O custo de propriedade também deve ser considerado, assim como a depreciação do equipamento e a sua manutenção (TISAKA, 2006).
Neste trabalho o custo do equipamento quando alugado será declarado como verba.
2.2.3.5 Custo indireto
Serviços de engenharia, canteiro de obras, telefone, assim como do escritório central são despesas que não fazem parte dos custos dos serviços, mas devem ser considerados no orçamento (TISAKA, 2006). Mesmo que os custos citados não estejam diretamente envolvidos na execução de um serviço ou obra, as suas ocorrências são essenciais para o projeto (PORTUGAL, 2017). Desta forma as despesas indiretas devem ser somadas às despesas diretas dando como resultado o custo total da obra (GONZÁLEZ, 2008).
Segundo Gehbauer (2002), “... os custos indiretos da obra compreendem todos aqueles custos que resultam de sua execução e que não podem ser incorporados nos custos de nenhum dos serviços individualmente”. Estes custos devem ser calculados separadamente e ser acrescidos aos custos unitários da obra (GEHBAUER, 2002).
Os principais fatores que influenciam no custo indireto, segundo Mattos (2006) são:
Localização geográfica: Uma obra em local remoto requer muita despesa com mobilização de pessoal e equipamentos, custos de viagem, aluguel de casas;
Política da empresa: Faixa salarial, quantidade de veículos disponíveis, padrão do canteiro de obras;
Prazo: As despesas administrativas são proporcionais à duração da obra; e,
Complexidade: Obras com elevado grau de dificuldade tendem a exigir mais supervisão de campo e suporte externo (consultoria).
2.2.3.6 Preço de venda e BDI
O preço de venda ou o preço final estimado da obra deve contemplar “...os custos diretos e a taxa de Benefício e Despesas Indiretas (BDI), a qual engloba os custos indiretos e o lucro,” (TCU, 2009).
Portugal (2017) ressalta a importância do cálculo do BDI, já que dentro dos custos indiretos estão as despesas da própria empresa, despesas estas destinadas a atender requisitos internos e a sua saúde financeira.
Segundo Mattos (2006), “o preço de venda é o valor total ofertado pelo contrato, valor que engloba todos os custos, o lucro e os impostos. É o valor final do orçamento”. É o preço que será cobrado ao cliente pela instaladora.
Equação 2: Preço de Venda
Fonte: Mattos (2006).
Sendo:
PV: Preço de venda; CD: Custo direto; CI: Custo indireto;
AC: Administração central; CF: Custo financeiro;
IC: Imprevistos e contingências; LO: Lucro operacional;
IMP: Impostos; e,
O BDI percentual (BDI%), segundo Mattos (2006), “é o fator a ser aplicado ao custo direto para obtenção do preço de venda”.
Equação 3: BDI Percentual
Fonte: Mattos (2006).
O BDI serve então para que após a determinação do preço de venda, possamos diluir os custos indiretos sobre os custos diretos (MATTOS, 2006).
Equação 4: Preço de Venda pelo BDI Percentual
Fonte: Mattos (2006).
Como exemplo, se o custo direto de uma obra é de R$ 200.000,00 (com impostos), o custo indireto R$ 40.000,00 (com impostos), e o lucro desejado é de R$ 60.000,00, então:
O preço de venda será R$ 300.000,00; e, O BDI% será igual a 0,50 (50%).
Vale salientar que cada obra deve ter seu próprio BDI que vai depender das características da obra, experiência do executor, dentre outros fatores (GONZÁLEZ, 2008).
2.3 PROGRAMAÇÃO
2.3.1 Engenharia de Software
Segundo Pressman (2011), “Software é o elemento-chave na evolução de produtos e sistemas baseados em computador e uma das mais importantes tecnologias no cenário mundial”. Segundo Sommerville (2011), “O mundo moderno não poderia existir sem o software”.
Nos últimos 50 anos o hardware e o software evoluíram e processos foram criados para que ambos operassem com qualidade (PRESSMAN, 2011).
Segundo Sommerville (2011), o software é abstrato, não é restringido pela propriedade física de materiais, não tendo limites para o seu potencial.
Com a evolução das linguagens de programação e das técnicas envolvidas, a criação de software se transformou em uma indústria de software e as técnicas organizadas e utilizadas para entrega do produto software dentro de prazos estimados e orçamentos estimados são chamadas de Engenharia de Software (PRESSMAN, 2011).
De acordo com o mesmo autor, “O processo de software incorpora cinco atividades estruturais: comunicação, planejamento, modelagem, construção e emprego; e elas se aplicam a todos os projetos de software”.
Comunicação: É realizada antes de se começar qualquer trabalho, é a etapa em que se busca compreender as necessidades e objetivos do software a ser produzido;
Planejamento: É a atividade em que o trabalho a ser realizado para o produto software é organizado, descrevendo técnicas, os riscos, os recursos necessários e o cronograma;
Modelagem: É a etapa em que se verifica como as partes componentes do software se encaixarão. Normalmente cria-se um esboço e a partir dele melhorias são feitas buscando-se detalhar cada vez mais todos os processos envolvidos;
Construção: É a atividade em que o software é produzido através da programação e testes são realizados para a verificação dos requisitos; e,
Emprego: É a atividade que se dá quando “o software é entregue ao cliente, que avalia o produto entregue e fornece feedback, baseado na avaliação”.
2.3.2 Modelos de Processo
Segundo Pressman (2011), “Um modelo de processo genérico para engenharia de software consiste num conjunto de atividades metodológicas e de apoio, ações e tarefas a realizar”. Cada modelo de processo, dentre os vários existentes, pode ser descrito por um fluxo de processo diferente. Padrões de processo são utilizados para resolver problemas comuns encontrados como parte do processo de software (SOMMERVILLE, 2011).
De acordo com Pressman (2011), num esforço para organizar e estruturar o desenvolvimento de software, um modelo de processo é utilizado. Este modelo de processo utiliza cinco atividades metodológicas genéricas: comunicação, planejamento, modelagem, construção e emprego.
Os modelos de processo sequenciais, tais como o de cascata e o modelo V, são os paradigmas da engenharia de software mais antigos. Tendo aplicabilidade em situações em que os requisitos são bem definidos e estáveis (PRESSMAN, 2011).
Conforme Sommerville (2011), o modelo “Cascata” considera as atividades fundamentais do processo, que segundo ele são: especificação de requisitos, projeto de software, implementação e teste unitário, integração e teste de sistema, operação e manutenção.
Já Pressman (2011) classifica as atividades fundamentais de processo como: comunicação, planejamento, modelagem, construção, emprego.
A figura 2 apresenta o modelo Cascata na visão de Sommerville e a figura 3 apresenta o modelo Cascata segundo Pressman.
Figura 2 – Modelo Cascata segundo Sommerville Fonte: SOMMERVILLE (2011).
Figura 3 – Modelo Cascata segundo Pressman Fonte: PRESSMAN (2011).
De acordo com Pressman (2011), existe uma variação do sistema cascata, que ele denomina como “modelo V”. Neste modelo, existe maior interação entre as atividades de processo e um maior refinamento do que no modelo Cascata original. A figura 4 (página 40) apresenta o modelo V.
Figura 4 – Modelo V Fonte: PRESSMAN (2011).
O desenvolvimento Incremental, segundo Sommerville (2011), possui uma abordagem que intercala as atividades de especificação, desenvolvimento e validação. “O sistema é desenvolvido como uma série de versões (incrementos)”.
Este modelo apresenta uma combinação dos fluxos de processos lineares e paralelos. Este tipo de modelo pode fornecer um software funcional, mas sem todas as atividades ativas desde à primeira versão; a cada nova versão ou “incremento”, novos recursos são adicionados a primeira versão sem prejudicar a funcionalidade do software (PRESSMAN, 2011).
Figura 5 – Modelo Incremental Fonte: PRESSMAN (2011)
Outro modelo citado por Pressman (2011) é o Modelo de processo concorrente (figura 6), que possibilita que uma equipe de software represente elementos iterativos e concorrentes de qualquer modelo de processo.
Figura 6 – Modelo de Processos Concorrentes Fonte: PRESSMAN (2011)
2.3.3 Desenvolvimento Ágil
Segundo Pressman (2011), “Em uma economia moderna, as condições de mercado mudam rapidamente, tanto o cliente quanto o usuário final devem evoluir e novos desafios competitivos surgem sem aviso”.
Alguns elementos são importantes para o desenvolvimento ágil: a importância das equipes que se auto organizam, que tenham controle sobre o trabalho por elas realizado, sobre a comunicação e sobre a colaboração entre os membros da equipe e entre os desenvolvedores e seus clientes; o reconhecimento de que as mudanças representam oportunidades e ênfase na entrega rápida do software para satisfazer o cliente (MARTIN, 2009).
Um processo ágil que é o mais amplamente utilizado é a Extreme Programming (XP). Segundo Pressman (2011), “a XP sugere um número de técnicas poderosas e inovadoras que possibilitam a uma equipe ágil criar versões de software frequentemente...”, o que propicia recursos e funcionalidades estabelecidos anteriormente, e, então, priorizando os envolvidos. O processo XP pode ser dividido em planejamento, projeto, codificação, teste. A figura 7 representa o processo XP.
Figura 7 – O Processo de Extreme Programming (XP) Fonte: Pressman (2011)
O planejamento é a atividade em que os requisitos são verificados, as necessidades avaliadas e as prioridades indicadas. No caso de um processo de software incremental, onde partes funcionais do software podem ser lançadas antes mesmo do produto completo, alterações nos requisitos podem ser feitos e as necessidades reavaliadas conforme a solicitação do cliente (PRESSMAN, 2011).
O projeto XP observa a simplicidade no código a ser produzido, evitando a funcionalidade extra do software, o que pode ser feita por incremento posteriormente (PRESSMAN, 2011).
A codificação é a etapa seguinte, nesta etapa devem-se realizar testes de unidades, buscando um código simples e após os testes realizados, incrementar progressivamente o código (LEFFINGWELL, 2007).
Por fim a etapa testes é realizada pelo cliente, objetivando as especificações e verificando as características e funcionalidades do sistema como um todo (PRESSMAN, 2011).
Segundo Leffingwell (2007) existem outros modelos de processos ágeis, modelos buscam a colaboração humana e a organização de equipes, mas que definem suas próprias atividades metodológicas e seus pontos de ênfase, buscando o aumento da qualidade, da produtividade e elevando a moral da equipe. Um destes métodos é o Adaptive Software Development (ASD), proposto para desenvolvimento de softwares e sistemas complexos (LEFFINGWELL, 2007). O ASD usa um processo iterativo que incorpora um planejamento cíclico de desenvolvimento iterativo que incorpora grupos focados nos clientes e revisões técnicas formais como mecanismos de feedback em tempo real. “O Scrum enfatiza o uso de um conjunto de padrões de software que se mostrou efetivo para projetos com cronogramas apertados, requisitos mutáveis e aspectos críticos de negócio” (PRESSMAN, 2007). O método de desenvolvimento de sistemas dinâmicos (DSDM), “defende o uso de um cronograma de tempos definidos e sugere que apenas o trabalho suficiente seja requisitado para cada incremento de software...”, facilitando o incremento seguinte (PRESSMAN, 2011). Crystal é uma família de modelos de processos ágeis que podem ser desenvolvidos para uma característica especifica de um projeto (LEFFINGWELL, 2007).
2.3.4 Princípios que Orientam a Prática
Segundo Martin (2009), práticas de engenharia de software envolvem princípios, conceitos, métodos e ferramentas aplicados por engenheiros ao longo de todo o processo de desenvolvimento. Diversos princípios genéricos se aplicam ao processo como um todo, independentemente do projeto ou do produto.
Um conjunto de princípios considerados essenciais pode auxiliar na aplicação de um processo de software e na execução de métodos efetivos de engenharia de software (PRESSMAN, 2011). Com relação ao processo, os princípios essenciais estabelecem uma base filosófica que orienta a equipe durante essa fase de desenvolvimento (MARTIN, 2009). Quanto à prática, os princípios estabelecem valores e regras servindo como guia ao analisar um problema, ao projetar uma solução, ao implementar e testar a solução e, por fim, disponibilizar o produto final para o seu cliente (MARTIN, 2009).
A construção incorpora um ciclo de codificação e testes no qual o código fonte para um componente é gerado e testado. Segundo Pressman (2011), “Embora haja muitos princípios de testes, apenas um é dominante: teste consiste em um processo de execução de um programa com o intuito de encontrar um erro”.
A “disponibilização ocorre na medida em que cada incremento de software é apresentado ao cliente e engloba a entrega, o suporte e o feedback” (PRESSMAN, 2011). Os princípios fundamentais para a entrega consideram o gerenciamento das expectativas dos clientes e o fornecimento ao cliente de informações de suporte apropriadas sobre o software. O suporte exige preparação antecipada.
“Feedback permite ao cliente sugerir mudanças que tenham valor agregado e fornecer ao desenvolvedor informações para o próximo ciclo de engenharia de software” (PRESSMAN, 2011).
2.3.5 Engenharia de Requisitos
Segundo Pressman (2011), a engenharia de requisitos é a etapa em que as atividades de comunicação com o cliente e de modelagem são definidas para o processo genérico de software. São conduzidas sete funções distintas de engenharia de requisitos:
Concepção: Os interessados estabelecem os requisitos, definem restrições de projeto e tratam as principais características e funções que obrigatoriamente têm de estar presentes no sistema;
Levantamento: Expande e refina os requisitos da função concepção; Elaboração: Expande ainda mais as necessidades em um modelo, um
conjunto de elementos comportamentais, orientados à fluxos e baseados em cenários e classes;
Negociação: Com o intuito de desenvolver um plano de projeto realista; Especificação: Verifica cada requisito do projeto;
Validação: Analisa se o projeto cumpre seu trabalho; e,
Gestão: Verifica se o cliente teve suas necessidades atendidas. 2.3.6 Modelagem de Requisitos
O objetivo da modelagem de requisitos, figura 8, é criar uma variedade de representações que descrevem aquilo que o cliente requer, estabelecendo uma base de criação de um projeto de software e definindo os requisitos que podem ser validados assim que o software for construído (PRESSMAN, 2011).
Figura 8 – Modelos baseados em Cenário de Requisitos Fonte: Pressman (2011).
