F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTOGestão de componentes de HW e PCBs
Carlos Manuel Queiroz Santos
V
ERSÃO FINALMestrado Integrado em Engenharia Eletrotécnica e de Computadores
Orientador: Prof. Dr. André Monteiro de Oliveira Restivo Co-orientador: Prof. Dr. Luís Filipe Pinto de Almeida Teixeira
Resumo
Numa empresa de produção e desenvolvimento de produtos eletrónicos, utilizam-se diariamente grandes quantidades de componentes, que apesar de semelhantes têm características distintas, o que poderá gerar erros de comunicação entre os diversos departamentos da empresa. Neste con-texto a empresa NIBBLE - Engenharia Lda., sugeriu como projeto de dissertação o tema “Gestão de Componentes de Hw e PCBs”.
O objetivo deste projeto é a criação de uma solução, que se adaptasse à empresa e que permitisse gerir os componentes utilizados na produção de Printed Circuit Board (PCB) para resolução do problema existente.
Assim, através do contacto com a empresa, foi definido o problema e conhecida a situação atual, com o levantamento das necessidades, apuraram-se também os requisitos, definiu-se a arquitetura do sistema criando uma aplicação web que integrou o sistema Sage Retail e Eagle já existentes na empresa.
Após estas etapas, a aplicação Web Gecel desenvolvida como protótipo foi implementada na em-presa e validada, sendo capaz de satisfazer as necessidades e os requisitos impostos pela emem-presa, mostrando-se uma solução válida, quer relativamente ao processo de associação de componentes às referências internas, quer ao processo de planeamento de produção possibilitando uma gestão ativa dos componentes de Hw e PCBs na empresa NIBBLE.
Face aos resultados obtidos nesta dissertação, é possível concluir que a implementação de uma plataforma web capaz de integrar os vários sistemas de uma empresa pode aumentar significa-tivamente a sua eficiência. A implementação desta plataforma na NIBBLE permitiu melhorar o seu método de trabalho e possibilitou uma comunicação mais eficaz entre os departamentos da empresa. Contudo, existem ainda novas linhas de desenvolvimento a explorar, para realização de trabalhos futuros.
Abstract
In a company with a focus on the production and development of electronic products, a lot of different components are used daily, that, although similar, have different characteristics. This can generate communication errors between the different departments of the company. In this context, the company NIBBLE - Engenharia Lda., proposed a dissertation topic with the title of "Management Components of Hw and PCBs".
The aim of this project is to create a solution adapted to the company that allows it to manage the components used in the production of Printed Circuit Board (PCB) and to solve the existing problem.
Through several contacts with NIBBLE, the problem was defined and the current situation has been assessed. The requirements and the system architecture were defined in order to create a web application that was capable of integrating the Sage Retail and Eagle systems which already existed in the company.
After these steps, the Gecel application was developed and validated as a prototype at the company, being able to satisfy the proposed needs and requirements. This application has been shown to be a valid solution, both in relation to the process of associating components with their respective internal references and the planning process, allowing an active management of hardware and PCBs at NIBBLE.
Finally, given the results obtained, it seems clear that the implementation of a web platform can be used to realize the integration of the various systems of a company while also improving their effi-ciency. The implementation of this platform has improved the working methodology of NIBBLE and enabled a more effective communication between company departments. However, there are new lines of development to explore in a future work.
Agradecimentos
Ao Professor Doutor André Restivo, por todos os conselhos e apoio prestado durante a elaboração desta dissertação.
Ao Engenheiro João Rodrigues, pela disponibilidade e ajuda prestada no desenvolvimento do projeto.
À empresa NIBBLE e a todos os seus colaboradores, pelo modo como me acolheram e pelo bom ambiente proporcionado durante estes meses;
À Juliana, pela paciência, compreensão e pelo apoio incondicional;
À minha família, especialmente à Tia Anita e à Linda, pelo acolhimento e incentivo que me deram durante estes 5 anos.
Carlos Santos
‘Failure is an option here. If things are not failing, you are not innovating enough.’
Elon Musk
Conteúdo
1 Introdução 1 1.1 Contexto . . . 1 1.2 Motivação . . . 1 1.3 Objetivo . . . 2 1.4 Resultados . . . 2 1.5 Estrutura do Documento . . . 3 2 Revisão Bibliográfica 5 2.1 Conceitos Inerentes . . . 5 2.1.1 Gestão de Materiais . . . 52.1.2 Printed Circuit Board (PCB) . . . 6
2.1.3 Bill of Materials (BOM) . . . 7
2.1.4 Software System integration . . . 7
2.2 Soluções Existentes . . . 8
2.2.1 Ciiva . . . 8
2.2.2 Arena PLM BOMcontrol . . . 9
2.3 Ferramentas de Trabalho . . . 10
2.3.1 Hypertext Preprocessor (PHP) . . . 10
2.3.2 HyperText Markup Language (HTML) . . . 11
2.3.3 Cascading Style Sheets (CSS) . . . 12
2.3.4 Javascript . . . 12 ix
x CONTEÚDO 2.3.5 jQuery . . . 13 2.3.6 SMARTY . . . 13 3 Problema 15 3.1 A Empresa . . . 15 3.2 Processos analisados . . . 15
3.2.1 Associação de referências internas . . . 16
3.2.2 Planeamento das produções . . . 17
3.3 Levantamento das Necessidades . . . 18
4 Solução 19 4.1 Introdução . . . 19
4.2 Requisitos . . . 19
4.2.1 Requisitos funcionais . . . 19
4.2.2 Requisitos não funcionais . . . 22
4.3 Arquitetura . . . 24 4.3.1 Integração de Sistemas . . . 24 4.3.2 Processos Chave . . . 25 4.3.3 Modelo Relacional . . . 26 5 Implementação 31 5.1 Arquitetura do sistema . . . 31 5.2 Páginas Implementadas . . . 32 5.2.1 Interface de produtos . . . 33
5.2.2 Interface de importação da BOM . . . 35
5.2.3 Interface de componentes . . . 36
5.2.4 Interface de fornecedores . . . 37
5.2.5 Interface de categorias . . . 38
CONTEÚDO xi
6 Validação 41
6.1 Introdução . . . 41
6.2 Análise dos processos . . . 41
6.3 Análise dos requisitos . . . 43
6.4 Análise temporal . . . 45
6.5 Sumário . . . 46
7 Conclusões e Trabalho Futuro 47 7.1 Conclusões . . . 47
7.2 Trabalho Futuro . . . 48
Lista de Figuras
2.1 PCB de um Radio [1] . . . 6
2.2 Análise de uma BOM no Ciiva . . . 9
2.3 Arena PLM BOMControl . . . 10
2.4 Esquema de Funcionamento de uma página Web [2] . . . 11
2.5 Exemplo de um código HTML . . . 12
3.1 Fluxograma do processo de associação de referências internas . . . 17
4.1 Interceção das diversas plataformas . . . 25
4.2 Nova Interceção das diversas plataformas . . . 25
4.3 Processo de Criação de um Produto na Aplicação Web . . . 27
4.4 Processo de Produção Virtual na Aplicação Web . . . 28
4.5 Modelo Relacional da Aplicação Gecel . . . 29
5.1 Esquema da estrutura dos ficheiros . . . 32
5.2 Mapa de páginas da aplicação Gecel . . . 33
5.3 Página dos Produtos . . . 33
5.4 Página de um Produto . . . 34
5.5 Listagem de componentes de um Produto . . . 35
5.6 Página de importação de uma BOM . . . 35
5.7 Página dos Componentes . . . 36
5.8 Página dos Componentes . . . 37 xiii
xiv LISTA DE FIGURAS
5.9 Página dos fornecedores . . . 37
5.10 Página de um fornecedor . . . 38
5.11 Página de categorias . . . 39
5.12 Página de planeamento de produção . . . 39
5.13 Página de produções . . . 40
6.1 Novo processo de associação de referências internas . . . 42
6.2 Página de adição de novos componentes . . . 44
Lista de Tabelas
4.1 Requisito RF01: Visualizar entidades . . . 20
4.2 Requisito RF02: Pesquisa e filtro de componentes . . . 20
4.3 Requisito RF03: Adicionar e editar elementos nas entidades . . . 20
4.4 Requisito RF04: Associar componentes a produtos . . . 21
4.5 Requisito RF05: Importar BOM em formato CSV . . . 21
4.6 Requisito RF06: Produções virtuais com reserva de stock . . . 21
4.7 Requisito RF07: Exportar dados dos fornecedores . . . 22
4.8 Requisito RF08: Registo de atividade dos utilizadores . . . 22
4.9 Requisito RNF01: Disponibilidade . . . 22 4.10 Requisito RNF02: Eficiência . . . 23 4.11 Requisito RNF03: Manutenção . . . 23 4.12 Requisito RNF04: Segurança . . . 23 4.13 Requisito RNF05: Usabilidade . . . 24 xv
Lista de Listagens
2.1 Exemplo de código sem Smarty . . . 14
2.2 Exemplo de código com Smarty . . . 14
2.3 Exemplo de código com Smarty . . . 14
6.1 Função para obter componentes de uma categoria . . . 43
6.2 Código de verificação de login . . . 44
Abreviaturas e Símbolos
BD Base de Dados BOM Bill of Materials CAD Computer Aided Design CE Comissão Europeia CSS Cascading Style Sheets CSV Comma Separated Values
DEEC Departamento de Engenharia Electrotécnica e de Computadores DOM Document Object Model
EAGLE Easily Applicable Graphical Layout Editor
FEUP Faculdade de Engenharia da Universidade do Porto GPS Global Positioning System
HTML HyperText Markup Language HW Hardware
LED Light Emitting Diode PCB Printed Circuit Board PDO PHP Data Objects PHP Hypertext Preprocessor SQL Structered Query Language
Capítulo 1
Introdução
Esta dissertação resulta do tema proposto pela empresa NIBBLE - “Gestão de componentes de Hw e PCBs”, no âmbito da Dissertação de conclusão do 5º ano do Mestrado Integrado em Engenharia Eletrotécnica e Computadores da Faculdade de Engenharia da Universidade do Porto.
1.1
Contexto
O mercado dos produtos eletrónicos é competitivo e em constante mudança. A NIBBLE é uma empresa portuguesa, presente no mercado desde 2004, sediada no concelho da Trofa, especializada na Gestão e Desenvolvimento de Projetos de Engenharia Eletrónica com Investigação e Desenvol-vimento interno. Esta empresa procura elaborar produtos e soluções para os seus clientes com um padrão de qualidade e diferenciação elevado (conforme diretivas da Certificação CE).
Os Produtos e Soluções são projetados e desenvolvidos até ao produto final, sendo as áreas de Segurança e Domótica, Global Positioning System (GPS) e Comunicações Móveis, a Iluminação Light Emitting Diode (LED) o Core Business da NIBBLE.
Na produção de qualquer produto eletrónico é necessário a agregação de diversos componentes. Neste contexto a transição entre o processo de gestão, desenvolvimento e produção tem de ser o mais eficaz e eficiente possível.
1.2
Motivação
No contexto de uma empresa de desenvolvimento e produção de produtos eletrónicos surgem dificuldades na interação entre os vários departamentos. Numa empresa como a NIBBLE é
2 Introdução
damental a comunicação entre o departamento de Desenvolvimento do Produto e a Gestão da Empresa.
Por vezes, o Departamento de Desenvolvimento quando concebe um produto, composto por uma Printed Circuit Board (PCB), não tem consciência da existência de stocks, nem quais os compo-nentes mais utilizados nos diferentes produtos da empresa. Por outro lado, o Departamento de Gestão da empresa, responsável pela compra de componentes não tem a visão de quais os com-ponentes mais adequados para cada produto concebido. Se a comunicação de informação não for clara e objetiva pode originar diversos erros.
Após o desenvolvimento das PCBs, estas passam do Departamento de Desenvolvimento para o Departamento de Produção. Neste processo, existem, por vezes, falhas relativas às referências ou mesmo falta de componentes essenciais à sua produção. Um dos principais factos na origem destes problemas, é a existência de vários tipos de referências para o mesmo produto, uma do fabricante, outra do fornecedor e uma interna da empresa. Para além dos factos já referidos, existem ainda vários fabricantes para componentes equivalentes.
1.3
Objetivo
O objetivo deste projeto é desenvolver uma solução que permita integrar as plataformas de gestão de stocks e desenvolvimento de PCBs existentes na empresa, melhorando assim, a comunicação entre os diversos departamentos (Gestão, Desenvolvimento e Produção).
Terá assim como propósito, a melhoria da gestão dos diversos componentes necessários para a produção de dispositivos impressos em placas PCB, o que permitirá ter uma visão mais clara de stocks disponíveis em função dos produtos a serem produzidos, bem como permitir aumentar a capacidade de resposta e rapidez de orçamentação de novos produtos.
1.4
Resultados
A solução encontrada após levantamento das necessidades da empresa e procurando dar resposta aos requisitos funcionais e não funcionais propostos foi a criação de uma aplicação web, que integrou as plataformas Sage Retail e EAGLE já existentes na empresa NIBBLE.
1.5 Estrutura do Documento 3
1.5
Estrutura do Documento
Para além da Introdução, na qual são apresentados o contexto, motivação, objetivo e resultados e a própria estrutura do documento, esta dissertação contém ainda mais seis capítulos.
No capítulo 2, é a realizada a revisão bibliográfica, onde são explanados sucintamente os tópicos, tecnologias, soluções existentes e linguagens de programação fundamentais para a abordagem do problema e desenvolvimento da solução do projeto.
No capítulo 3, está presente a abordagem do problema sendo desenvolvidas a contextualização da empresa, os processo analisados bem como o levantamento das necessidades da empresa com vista a encontrar uma solução que as satisfaça.
No capitulo 4, são levantados os requisitos, com o intuito de, juntamente com a empresa, estruturar a solução para o problema. É descrita também a arquitetura onde serão abordados a integração dos sistemas, os processos chave da aplicação e o modelo relacional.
No capítulo 5 é apresentada a arquitetura do Sistema, que inicialmente necessitou de um estudo aprofundado. São também estruturadas as páginas web da aplicação, que foram desenvolvidas em parceria com o departamento de desenvolvimento da empresa.
No capítulo 6 é apresentada a validação da aplicação, com a análise dos processo de associação de referências e planeamento de produção, bem como dos requisitos funcionais e não funcionais propostos pela empresa. A análise temporal também é descrita neste capítulo.
No último capítulo, estão presentes as conclusões, bem como ideias para trabalhos a desenvolver no futuro, de forma a aumentar, ainda mais, a qualidade do sistema.
Capítulo 2
Revisão Bibliográfica
Neste capítulo serão apresentados os conceitos inerentes ao desenvolvimento do projeto, bem como as plataformas já utilizadas pela empresa. Serão também apresentadas soluções já existentes e as ferramentas necessárias para conceção do projeto.
2.1
Conceitos Inerentes
Para a elaboração deste projeto foram necessários a aprendizagem e o aprofundamento de alguns conceitos relacionados com a gestão de componentes, PCB e Bill of Materials (BOM). Por isso, estes conceitos serão abordados de forma mais detalhada nesta secção.
2.1.1 Gestão de Materiais
A gestão de materiais corresponde a um conjunto de métodos, controlos e práticas relacionadas com produção de um produto ou serviço, que pode ser utilizado desde as pequenas até grandes empresas.
O principal objetivo é conciliar os interesses entre as necessidades de suprimentos e a otimização dos recursos financeiros e operacionais que a empresa dispõe. Este abrange a aquisição de peças de reposição e substituições, o controlo de qualidade das compras, e as normas envolvidas na encomenda, o transporte e armazenamento dos componentes [3].
Assim, é fundamental, reconhecer e definir as necessidades, classificando-as, segundo o tipo, es-tratégica ou operacionalidade. Devem sempre ser avaliados elementos fundamentais, tais como qualidade, quantidade, prazo, preço, tempo e produto. Estes elementos vão permitir diminuir o
6 Revisão Bibliográfica
custo de operação que a empresa prepara na elaboração de seus produtos ou na venda de serviços, de acordo com o ramo que a empresa exerce.
Torna-se fulcral também o planeamento da compra dos componentes, analisando o tempo de es-pera que a aquisição do produto irá ter e o seu custo benefício. Materiais comprados demasiado cedo podem representar capital empatado e, por outro lado, atrasos e despesas podem existir se materiais não estiverem disponíveis quando forem necessários.
A gestão de materiais é considerada, por isso, um dos setores vitais de uma empresa, pois colabora na execução de elaboração de um produto ou na realização de um serviço que será oferecido ao consumidor final [4].
2.1.2 Printed Circuit Board (PCB)
A maioria das publicações sobre PCB atribui a invenção do circuito a Paul Eisler, um engenheiro austríaco, que em 1936, no entanto, só em 1943, é que as PCB foram usadas de uma forma mais ampla, sendo empregues em equipamentos de rádio para uso militar, onde era fundamental que o circuito funcionasse em situações extremamente adversas. Na Figura 2.1 está representado um exemplo de uma PCB de um rádio.
Figura 2.1: PCB de um Radio [1]
Após a Segunda Guerra Mundial, e com o advento dos transístores, surgiram novas aplicações, tornando-se a forma mais comum de construção de circuitos transistorizados, sendo empregues em todos os tipos de equipamentos eletrónicos, principalmente em construção de circuitos integrados [5].
2.1 Conceitos Inerentes 7
Apesar das alternativas existentes às PCB, a sua fabricação e montagem podem ser automatizados, o que torna os circuitos mais baratos e mais rápidos e diminui erros de fiação na sua produção.
2.1.3 Bill of Materials (BOM)
Bill of materialsé considerada uma lista de materiais, subcomponentes, componentes ou partes constituintes de um dado produto.
Na área eletrónica é uma lista de componentes usados para a construção de placas PCB. Esta pode conter diversas informações dos respetivos componentes, como por exemplo, o nome, a quantidade, as referências do fabricante ou do fornecedor e posição na placa.
Uma vez o projeto finalizado, a BOM é passada para a equipa responsável pela aquisição dos componentes ou engenheiros de produção [6].
Para gerir toda a informação contida na BOM, as empresas podem utilizar ferramentas com o Microsoft Excel ou um sistema dedicado a gerir a BOM como, por exemplo, o Ciiva e o Arena PLM BOMcontrol.
2.1.4 Software System integration
O system integration process integra num sistema de solução um conjunto de ideias que possuem várias soluções separadas. É a componente de um processo de sistema de engenharia que unifica os componentes e o processo de um produto. Ela assegura que o hardware, software e os com-ponentes do sistema humano que vão interagir cheguem ao propósito do sistema ou satisfaçam as necessidades do cliente [7].
Assim, para a integração de um sistema é preciso conhecer os vários sistemas e subsistemas utili-zados para a produção de componentes, e desenvolver uma estratégia de planeamento, conceção, execução, recolha de dados e avaliação que os integre.
A NIBBLE no desenrolar das suas atividades utiliza diversas plataformas, sendo as seguintes relevantes para o projeto:
EAGLE é a plataforma para desenvolvimento de PCB, sendo esta utilizada pelo Departamento de Desenvolvimento. Com esta finalidade, apresenta uma biblioteca de componentes; um editor esquemático, que possibilita desenhar o projeto preliminar do circuito; um editor que define o layout físico da placa de circuito; um editor do dispositivo, usado para projetar novos componentes; um autorouter, que determina automaticamente como é que elementos
8 Revisão Bibliográfica
do circuito podem ser ligados e, finalmente, o CAM (Computer Aided Manufacturing) do processador, que lê o projeto e produz arquivos para a fabricação da placa.
Sage Retail é a plataforma utilizada para gestão de stocks, faturação, gestão de clientes e for-necedores, tendo esta um papel fundamental para as atividades da gestão da empresa. O sistema permite realizar o registo de vendas e cobranças com gestão em tempo real e global das operações financeiras, o acompanhamento dos stocks, a gestão de relacionamento com clientes, o agendamento eletrónico para a marcação de serviços a prestar a clientes, emissão de documentos, racionalizando ao mesmo tempo o conjunto dos processos da empresa e interligando-as entre si.
MySQL Workbench é o sistema que gere a base de dados de algumas plataformas web que a empresa dispõe. Este sistema tem como vantagens, a fácil utilização, devido a sua arquite-tura e a maior flexibilidade e rapidez de acesso aos dados. A Structered Query Language (SQL) é a linguagem de programação utilizada nestes sistemas, permitindo ao utilizador, de forma simples, selecionar a informação desejada para a sua pesquisa.
Para integrar estas plataformas, foi utilizado o método de integração horizontal ou Enterprise Service Bus(ESB), que é um método de integração em que um subsistema especifico dedica-se a comunicar com outros subsistemas, o que permite reduzir o número de conexões (interfaces) para apenas uma por subsistema. Assim, são reduzidos os custos de integração e é aumentada a flexibilidade [8].
2.2
Soluções Existentes
De modo a ter uma visão mais clara do projeto, foram estudas algumas plataformas de análise e gestão de componentes eletrónicos já existentes, destacando-se o Ciiva e o Arena PLM BOMcon-trol.
2.2.1 Ciiva
O Ciiva é um software de análise de BOM de componentes eletrónicos. Este software permite incorporar produtos através do formato CSV, sendo este o principal formato de exportação dos programas de desenvolvimento de produtos.
Recorrendo às referências do fabricante ou do fornecedor a BOM é analisada, e posteriormente, é feita a correspondência aos respetivos componentes disponíveis na base de dados web do Ciiva. Este software apresenta uma “Smart Parts Pesquisa e de Análise”, que contém todas as informa-ções relativas aos componentes, que permite realizar a seleção, gerar a BOM, os ciclos de vida
2.2 Soluções Existentes 9
de seleção, os componentes obsoletos, assim como obtém os preços em tempo real, disponibi-liza os fornecedores confiáveis e melhora a cadeia de fornecimento com componentes alternativos verificados (representado na Figura 2.2). Além destas duas ferramentas possui o “Smart Parts Management”, que automatiza todas as tarefas demoradas do processo.
Atualmente, os dispositivos eletrónicos contêm um grande número de componentes, a partir de uma variedade de fabricantes e fornecedores. A BOM, pode por isso, sofrer alterações em várias fases do ciclo de vida de um produto, muitas vezes sem alterar os dados de projeto de hardware originais, tais como esquemas ou layout. O Ciiva, leva à diminuição de falhas, como, a mudança manual para uma folha de cálculo ou documento, sem registo de quem, quando e o porquê de alterações realizadas [9].
Figura 2.2: Análise de uma BOM no Ciiva
2.2.2 Arena PLM BOMcontrol
O Arena PLM BOMControl é um software que simplifica a gestão de BOM oferecendo um equi-líbrio entre a flexibilidade e o controlo em cada ponto do ciclo do componente, do protótipo à produção, gerando relatórios de conformidade e realizando auditorias intantâneas. É um cloud product que garante informações sobre o produto em tempo real em qualquer parte do mundo. Inclui arquivos de projeto, lista de materiais, itens, custos, informações de fornecedores, o status de conformidade, horários e tarefas. A empresa pode adicionar ou subtrair um número ilimitado de usuários através das cadeias de fornecimento e fornecer seletivamente o acesso a informação e detalho do projeto, como é possível objetivar no esquema representado na Figura 2.3 (Adaptado de Arena PLM)[10].
10 Revisão Bibliográfica
Figura 2.3: Arena PLM BOMControl
2.3
Ferramentas de Trabalho
Neste tópico serão abordadas as linguagens necessárias para o desenvolvimento da aplicação web: Hypertext Preprocessor (PHP), Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), Javascript e o motor de templates Smarty.
2.3.1 Hypertext Preprocessor (PHP)
O PHP é uma linguagem de scripting que é utilizada principalmente para desenvolver páginas dinâmicas, inserindo no HTML instruções para serem executadas por um programa alojado no servidor, com o objetivo de definir as partes dinâmicas das páginas Web. O programador po-derá assim adicionar instruções no template HTML, que serão interpretadas pelo servidor, como representado na Figura 2.4 [11].
O PHP permite, assim, para além de gerar conteúdo dinâmico das páginas, enviar e receber coo-kies, efetuar estatísticas, gerar gráficos ou ficheiros PDF, animações e consoante inputs dos utiliza-dores, obter respostas imediatas em formas de páginas HTML. Existe atualmente uma quantidade considerável de linguagens de server-side scripting, no entanto a que mais se destaca em termos de adoção é a PHP, uma vez que a maior parte dos servidores fornece suporte e está disponível na maior parte das plataformas, sendo de fácil instalação e aprendizagem.
2.3 Ferramentas de Trabalho 11
Figura 2.4: Esquema de Funcionamento de uma página Web [2]
2.3.2 HyperText Markup Language (HTML)
HTML não é uma linguagem de programação, mas sim uma linguagem de markup, cujo propósito é descrever o conteúdo de uma página Web, constituída por imagens, texto e outros elementos especiais, cuja função é delimitar porções do conteúdo da página. O conteúdo é posteriormente, gerido por um processador no Web browser que o recebe como forma de dados de entrada e os representa de uma forma visual através da interpretação das tags [11].
Os documentos em HTML são ficheiros de texto simples, que podem ser criados e editados em qualquer editor de texto comum, no entanto existem no mercado editores de texto orientados para a sua construção, com recursos que facilitam, por exemplo, a repetição de tarefas, a inserção de objetos ou elaboração de tabelas.
Toda a estrutura de uma página HTML está contida na tag <html> e consiste, no mínimo, em duas áreas principais, o cabeçalho definido pela tag <head> e o corpo definido pela tag <body>. O cabeçalho contém informação relativa ao título da página (definido por <title>), metadata que são palavras-chave úteis para os motores de busca (<meta>), elementos de estilização dos elementos, escripts com funções para interação avançada. O corpo apresenta elementos que compõe a página, como imagens (<img>), texto (p.e <p>), elementos especiais, como separadores (p.e. <div>) e elementos de interação com o utilizador (<button>). A Figura 2.5 mostra um exemplo de um
12 Revisão Bibliográfica
código HTML e seu resultado.
Figura 2.5: Exemplo de um código HTML
Atualmente, o interesse na utilização do HTML tinha desaparecido com a recorrente utilização da linguagem de programação Javascript para a manipulação de elementos HTML, no desenvolvi-mento de aplicações web, com novas funções de interação, eventos ordenados a partir do servidor e desenho, entre outras. Assim, é possível a partir de um standard aberto desenvolver aplicações com recurso a Javascript, sem necessitar de recorrer a métodos pouco ortodoxos, sem qualquer documentação validada disponível[12].
2.3.3 Cascading Style Sheets (CSS)
As CSS podem-se definir como um conjunto de regras que indicam ao browser qual o aspeto do documento e permitem que este seja definido separadamente do markup da página e do próprio conteúdo escrito em HTML. Estas regras dividem-se em duas partes: um seletor que indica qual o elemento ao qual vai ser associado uma regra de estilo, e uma declaração do estilo que indica o conjunto de regras a serem aplicadas. Estas regras podem ser incluídas no ficheiro HTML através de um tag (<style>), ou num ficheiro separado, ligado a esse documento através do tag (<link>). Este último permite utilizar as mesmas definições de estilo em diferentes páginas. Desta forma, é possível mudar o estilo de uma aplicação, modificando apenas um único ficheiro [13].
2.3.4 Javascript
O JavaScript é uma linguagem de programação, que modifica o documento, ao aproveitar o Do-cument Object Model (DOM), uma plataforma e modelo, independente da linguagem para re-presentar documentos HTML (parte estática da página). Assim, a DOM providencia métodos e propriedades através dos quais o script tem acesso de forma dinâmica e pode atualizar o conteúdo, estrutura e estilo dos documentos.
2.3 Ferramentas de Trabalho 13
A execução do código Javascript juntamente com a página HTML é efetuada pelo browser. Esta linguagem é frequentemente utilizada para validar os dados introduzidos por utilizadores num formulário, permite detetar eventos e atuar sobre os valores e/ou atributos dos elementos HTML das páginas Web, expandir divisões ocultas ou compactadas, carregar documentos, entre muitas outras funcionalidades.
2.3.5 jQuery
O jQuery é uma biblioteca JavaScript cross-browser que permite adicionar elementos dinâmicos e interativos a páginas web, diminuindo as diferenças de processamento dos vários browsers, o que torna o desenvolvimento das aplicações mais rápido [14].
A sintaxe do jQuery foi desenvolvido para simplificar a navegação das páginas HTML, selecionar elementos Document Object Model (DOM), criar animações, manipular eventos e aumentar in-terações AJAX numa página Web. Pode criar plugins sobre a biblioteca, possibilitando a criação de camadas de abstração para interações de mais baixo nível, o que simplifica o desenvolvimento de aplicações web mais dinâmicas e complexas [15]. Permite também, alterar de forma simples o CSS da página segundo eventos.
Uma vez que são muitas as vantagens desta biblioteca, que no entanto, não irão acrescentar mais-valia a este documento, o que é importante salientar é que o JQuery melhora e simplifica o trabalho dos programadores.
2.3.6 SMARTY
Smartyé um motor de templates muito usado em aplicações Web, principalmente em aplicações escritas em PHP. Este motor efetua a separação da lógica da aplicação do seu design, permitindo poupar imenso tempo, quando usada adequadamente. É uma ferramenta útil, quando o código necessita de ser adaptado, reestruturado ou reescrito, pois ao separar o código responsável pela lógica (PHP) do código de design (HTML) é possível criar, alterar e apagar templates, mantendo toda a lógica intacta da aplicação.
Na Listagem 2.1 é possível visualizar um exemplo de código PHP que pode ser separado, através da ferramenta Smarty nas Listagens 2.2 e 2.3. Por isso, o Smarty facilita a criação de templates bem estruturados, de fácil compreensão e reutilização, reduzindo o tempo de desenvolvimento da aplicação. Outra das suas vantagens é a deteção de erros e a verificação do estado das variáveis utilizadas para o desenvolvimento da aplicação.
14 Revisão Bibliográfica
Listagen 2.1: Exemplo de código sem Smarty 1 <?php
2 echo"<table >";
3 echo"<th >Id </th ><th >Nome </th ><th >Morada </th > 4 <th > Codigo Postal </th >";
5 foreach $utilizador as $elemento { 6 echo "<td >". elemento ['id ']" </td >"; 7 echo "<td >". elemento ['nome ']" </td >"; 8 echo "<td >". elemento ['morada ']" </td >";
9 echo "<td >". elemento ['codigo_postal ']" </td >"; 10 }
11 echo" </table >" 12 ?>
Listagen 2.2: Exemplo de código com Smarty 1 <?php
2 $smarty -> assign (" utilizador ",$utilizador ); 3 $smarty -> display (" utilizador .tpl");
4 ?>
Listagen 2.3: Exemplo de código com Smarty
Capítulo 3
Problema
Neste capítulo será apresentada a empresa NIBBLE, serão explanados os processos analisados, tendo como pontos chave o processo de associação das referências internas e o planeamento de produções. O levantamento das necessidades teve como finalidade melhorar o fluxo de informação entre os vários departamentos e permitir fazer um bom planeamento das produções.
3.1
A Empresa
Tal como mencionado na Secção 1.1 a NIBBLE é uma empresa portuguesa, presente no mercado desde 2004, sediada no concelho da Trofa. A partir de 2013, após obtenção do registo de marca internacional, projetou-se para um mercado mais amplo, procurando fornecer um conjunto de produtos e serviço de qualidade nas áreas de “Segurança e Domótica”, “GPS e Comunicações Moveis” e “Iluminação LED”.
Assim, a empresa está organizada internamente em três departamentos: departamento de gestão, desenvolvimento e produção. Esta organização permite desenvolver a sua atividade baseada nos princípios orientadores: Investigação, Desenvolvimento e Inovação, sendo responsável pela ideia inicial e pelo desenvolvimento do produto final, controlando todo o processo de gestão do produto.
3.2
Processos analisados
Para o desenvolvimento de uma solução que satisfizesse as necessidades da empresa foram analisa-dos os processos já existentes na empresa. Assim, foram consideraanalisa-dos como premissas essenciais a associação de referências internas do produto e o planeamento das produções, uma vez que são essenciais para o bom funcionamento da empresa, e neles foram encontradas algumas lacunas. A
16 Problema
análises foi realizada através de várias reuniões com a empresa, onde foi possível perceber o seu modo de funcionamento.
3.2.1 Associação de referências internas
O departamento de desenvolvimento tem engenheiros responsáveis pela estruturação e desenvol-vimento do projeto. A fim de tornar a comunicação entre os vários departamentos mais eficaz existe um manual de qualidade, onde estão especificadas referências internas que dizem respeito, não só aos produtos finais, mas também a todos os componentes utilizados como matéria-prima. Estas referências são geradas pela plataforma Sage Retail, que atribuiu a cada existência uma nova referência de acordo com a categoria a que pertence. Cabe ao departamento de gestão a supervisão desta função.
Após a aprovação do projeto de um produto pelo departamento de gestão, é selecionado um enge-nheiro de desenvolvimento que será responsável pela sua execução.
Para dar início ao projeto o engenheiro de desenvolvimento tem que fazer todo o levantamento sobre os requisitos técnicos existentes sobre o produto a desenvolver.
Posteriormente, utilizando a plataforma o EAGLE, aplicação desenvolvida especialmente para con-ceber placas de PCB, o engenheiro desenha o esquema elétrico e são escolhidos os componentes que farão parte do produto.
De modo a selecionar os componentes indicados, é realizada uma pesquisa nos fornecedores da empresa e posteriormente, escolhidos os componentes, tendo em conta os seguintes critérios:
• Cumprimento dos requisitos, • Qualidade,
• Preço,
• Quantidade disponível, • Rapidez de entrega • (. . . )
Na mesma plataforma, o engenheiro de desenvolvimento define o layout físico da placa/circuito, otimizando o espaço, tendo em consideração não só o espaçamento das vias, mas também as espe-cificações técnicas do produto, este passo é essencial para que a PCB tenha um bom desempenho durante o seu funcionamento.
3.2 Processos analisados 17
Todo este procedimento termina com a exportação da BOM no formato CSV, que será entregue ao departamento de Gestão para análise.
Após a receção da BOM o engenheiro de gestão realiza a associação de cada um dos componentes que constam nesta à referência interna da empresa. Este processo é feito recorrendo a um ficheiro Excel onde já constam as associações feitas em projetos anteriores. O nome dos componentes que constituem a BOM são atribuídos pelo engenheiro de desenvolvimento ainda na fase de desen-volvimento, podendo variar para o mesmo componente. Portanto, quando executada a função de associação se o nome não for exatamente igual ao dado nos projetos anteriores a associação não é feita.
Para os componentes em que não é possível realizar a atribuição de referência automaticamente, o gestor realiza uma pesquisa individual na base de dados da empresa para cada componente consoante as características do mesmo. No caso de esta pesquisa falhar o gestor questiona o engenheiro responsável pelo projeto sobre a possibilidade de substituir o componente ou se é necessário adquirir um componente novo.
Este processo está descrito de forma simplificada no fluxograma da Figura 3.1.
Figura 3.1: Fluxograma do processo de associação de referências internas
3.2.2 Planeamento das produções
Quando surge uma encomenda de um produto na empresa, o departamento de gestão verifica o stock existente desse produto, e caso a quantidade seja insuficiente para satisfazer a encomenda é gerada uma nova produção. Para dar início à produção o departamento de gestão necessita de verificar se possui as quantidades de matéria-prima, ou seja, componentes necessários para a
18 Problema
realização da produção. Para isso, o gestor recorre à plataforma Sage Retail, consulta o stock de todos os componentes existentes na empresa e exporta um ficheiro em formato CSV onde constam as referências internas e o correspondente stock de cada um dos componentes. Recorrendo ao programa Excel o gestor importa a tabela resultante da exportação do ficheiro e compara-a com a BOM do produto em questão. Se existirem as quantidades necessárias para a produção do produto, é dada a ordem de início de produção ao departamento de produção. Caso não sejam satisfeitas as quantidades necessárias, o gestor verifica através da referência interna qual o componente ou componentes em falta, analisa os fornecedores daquele ou daqueles componentes e procede à encomenda.
3.3
Levantamento das Necessidades
Tendo como objetivo melhorar o fluxo de informação entre os vários departamentos e permitir fazer um bom planeamento das produções, foi realizado um levantamento das necessidades da empresa. Neste sentido foram efetuadas varias reuniões com membros da empresa dos vários departamentos. Destas reuniões verificaram-se que os aspetos mais relevante a melhorar seriam os seguintes:
• O método de associação das referências internas aos componentes, evitando duplicação de referências internas para o mesmo componente e troca de componentes durante a produção do produto;
• A gestão dos stocks da empresa, de forma a melhorar o controlo do stock dos componentes armazenados nos diferentes espaços da empresa;
• A Perceção das características dos vários componentes existentes na empresa e seus simila-res no mercado evitando duplicação de aquisições de componentes semelhantes;
• A Capacidade de previsão dos stocks necessários para a produção da empresa, permitindo tornar célere a resposta de orçamento aos clientes.
Capítulo 4
Solução
Neste capítulo serão descritos os requisitos principais da aplicação web, bem como a arquitetura especificando o modo como foi realizada a integração dos sistemas existentes, os processos chave e o modelo relacional utilizado.
4.1
Introdução
O conhecimento do processo de comunicação entre os diversos departamentos da NIBBLE e suas limitações criou a necessidade de desenvolver como solução um protótipo de uma aplicação web adaptada às necessidades da empresa em estudo. É de salientar que a criação deste protótipo fez com que fossem discutidos, revistos e validados alguns processos utilizados de forma a melhorar a eficiência da empresa.
4.2
Requisitos
A análise de necessidades, descrita no Secção 3.3 levou à determinação dos requisitos principais da aplicação web. Para simplificar a abordagem os requisitos, estes serão apresentados em formato de tabela genericamente, subdividindo-os em requisitos funcionais e não funcionais. Cada requisito apresenta um id, que não terá em conta a prioridade de implementação, um título e uma descrição que inclui um resumo do que se pretende com esse requisito.
4.2.1 Requisitos funcionais
Nesta subsecção serão apresentados, como referido anteriormente, os requisitos funcionais. 19
20 Solução
Tabela 4.1: Requisito RF01: Visualizar entidades RF01 Visualizar entidades
Permitir visualizar todos os produtos, componentes, fornecedores e categorias, devendo haver páginas diferentes para cada uma das entidades. O modo de apresentação deverá ser realizado em formato de tabela, de forma a facilitar a sua visualização.
A visualização em diferentes páginas para cada entidade vai permitir aos utilizadores da aplicação ter uma visão mais clara de todas as características existentes, tornando o processo de pesquisa mais fácil e célere.
Tabela 4.2: Requisito RF02: Pesquisa e filtro de componentes RF02 Pesquisa e filtro de componentes
Permitir que o utilizador visualize e pesquise os componentes pelas suas carac-terísticas ou pelas categorias, às quais pertencem. Criar filtros para a seleção de componentes mediante as características indicadas pelo utilizador. A lista de resultados deverá ser apresentada em formato de tabela após pesquisa.
Durante o processo de desenvolvimento de uma PCB o engenheiro de desenvolvimento necessita de consultar as características do componente, sendo a pesquisa correta e rápida essencial para a seleção do componente a utilizar. Para além da pesquisa, é também importante que seja possível para o mesmo, filtrar os componentes existentes pelas características que este pretende. Assim, a criação de uma ferramenta de pesquisa e filtro na aplicação reduzirá o tempo despendido para estes passos.
Tabela 4.3: Requisito RF03: Adicionar e editar elementos nas entidades RF03 Adicionar e editar elementos nas entidades
Permitir adicionar novos elementos às diferentes entidades: componentes, pro-dutos, versões, fornecedores, categorias e parâmetros. Caso, seja necessário alterar características dos elementos, possibilitar a sua edição.
No caso, especifico de componentes, possibilitar a importação de novo com-ponentes através da leitura de um ficheiro CSV.
Cada elemento é adicionado ou editado através de uma página criada para esse efeito, onde consta um formulário que o utilizador terá que preencher com as características do elemento e submetê-lo.
Este requisito é fundamental para a manutenção da aplicação atualizada a longo prazo. Possibilita que quer o departamento de gestão, quer o de desenvolvimento adicionem novos elementos à pla-taforma e os consigam editar também. Esta função permite a aplicação acompanhar as alterações que vão sendo introduzidas ao portfólio da empresa, não se tornando por isso, obsoleta.
4.2 Requisitos 21
Tabela 4.4: Requisito RF04: Associar componentes a produtos RF04 Associar componentes a produtos
Permitir que os componentes sejam associados a produtos, criando assim a lista de componentes necessários para produzir o produto.
Possibilitar a adição de alternativas ao componente em questão para um dado produto, ou seja, a utilização de um componente que apesar de não ser o com-ponente de referência pode substitui-lo na produção por permitir o desempenho das mesmas funções.
A associação de todos os componentes ao produto permitirá uma mais correta análise do produto em questão. Esta funcionalidade poderá melhorar a listagem de componentes de um produto, bem como as suas alternativas, possibilitando ao utilizador escolher o componente que pretende para um dado produto.
Esta associação poderá também diminuir o tempo de resposta a encomendas, pois em caso de inexistência do componente principal, é possível utilizar as alternativas disponíveis em stock e satisfazer as necessidades para a produção do produto
Tabela 4.5: Requisito RF05: Importar BOM em formato CSV RF05 Importar BOM em formato CSV
De forma a possibilitar uma associação de componentes mais rápida, a aplica-ção deverá ser capaz de importar a BOM do produto no formato CSV.
Deverá ser também capaz, de analisar este ficheiro e proceder às respetivas associações entre o nome do componente escolhido pelo engenheiro de desen-volvimento e a referência interna existente no manual de qualidade da empresa. Caso esta associação não seja realizada automaticamente, a aplicação deverá alertar o utilizador e possibilitar ao mesmo, a escolha da referncia indicada.
Esta função da aplicação poderá permitir que seja o engenheiro de desenvolvimento a realizar a associação dos componentes à referência interna da empresa, sem que seja necessário intervir o departamento de gestão. Assim, o processo ficará mais rápido e diminuirá a probabilidade de ocorrência de erros na escolha dos componentes para a realização das placas PCB.
Tabela 4.6: Requisito RF06: Produções virtuais com reserva de stock RF06 Produções virtuais com reserva de stock
Possibilitar ao utilizador saber se existe em stock matéria-prima necessária para a produção de um dado produto. Após conhecimento da existência de stock, proceder á sua reserva virtual.
Esta funcionalidade é essencial para o planeamento ativo dos stocks, pode proporcionar ao depar-tamento de gestão conhecer em tempo real quais os componentes e suas quantidades, aumentando
22 Solução
a eficiência no processo de orçamentação e planeamento de produção.
Tabela 4.7: Requisito RF07: Exportar dados dos fornecedores RF07 Exportar dados dos fornecedor
Deverá ser possível exportar todos os dados dos fornecedores, gerando um ficheiro CSV.
A exportação dos dados dos fornecedores, possibilitará a utilização destes dados em outros forma-tos, podendo ser utilizados para o contacto de fornecedores através de outras plataformas.
Tabela 4.8: Requisito RF08: Registo de atividade dos utilizadores RF08 Registo de atividade dos utilizadores
Deverá registar todas as ações realizadas por cada um dos utilizadores, e iden-tificar qual o utilizador que realizou determinada ação.
Esta informação deverá ser disponibilizada somente para o administrador da aplicação e representada em forma de tabela.
O registo de atividade dos utilizadores é um requisito bastante importante para o bom funciona-mento e manutenção da qualidade dos produtos da empresa, pois permite atribuir a cada utilizador as ações realizadas na aplicação e colmatar possíveis erros identificando como foi realizada a ação e por quem.
A monitorização do trabalho realizado pelo administrador é também um ponto chave de todo o processo de melhoria continua da qualidade e segurança.
4.2.2 Requisitos não funcionais
Nesta subsecção serão apresentados, como referido anteriormente, os requisitos não funcionais. Tabela 4.9: Requisito RNF01: Disponibilidade
RNF01 Disponibilidades
Deverá ser um sistema resistente a falhas que possam impedir o seu funciona-mento, de modo a que este esteja sempre disponível para todos os utilizadores ao mesmo tempo.
Durante o normal funcionamento de uma empresa a disponibilidade do sistema permite realizar variadas ações por utilizadores diferentes, isto contribuirá para a diminuição de tempo de produção e aumento da eficiência da empresa.
4.2 Requisitos 23
Tabela 4.10: Requisito RNF02: Eficiência RNF02 Eficiência
A aplicação desenvolvida exigirá trocas de informação constante entre as di-ferentes plataformas existentes na empresa, assim o tempo de execução das operações deve ser reduzido, de modo a obter-se uma eficiência aceitável.
Tal como mencionado no ponto anterior, para além de disponível a aplicação deve ser o mais efici-ente possível, ou seja realizar as funções/ações pretendidas com a utilização de menor quantidade de recursos possível. Logo, este requisito permitirá aos utilizadores poupar tempo na comunicação entre os diversos departamentos acelerando a produção da empresa.
Tabela 4.11: Requisito RNF03: Manutenção RNF03 Manutenção
Garantir que a aplicação permita uma fácil manipulação e alteração das suas funcionalidades e entidades que o constituem, bem como a possibilidade de introduzir novas funcionalidades.
A manutenção é um requisito fundamental para que a aplicação continue a ser utilizada pela em-presa, caso este requisito não seja satisfeito a aplicação tornar-se-á obsoleta num curto espaço de tempo.
De modo a serem possíveis intervenções de manutenção é essencial que o desenvolvimento da aplicação seja organizado e estruturado, ou seja que o código deverá ter comentários e marcadores de forma a localizar as funções pretendidas.
Tabela 4.12: Requisito RNF04: Segurança RNF04 Segurança
Garantir que a aplicação esteja preparada para manter a integridade da infor-mação que circula.
A aplicação deverá ser capaz de se resguardar de ações não autorizadas, através da criação de permissões dadas aos utilizadores.
A segurança apresenta uma importância acrescida para uma empresa, pois os produtos nela desen-volvidos são únicos e competitivos num mercado vasto.
Por isso, qualquer fuga de informação pode ter repercussões graves para a empresa, quer a nível financeiro, quer a nível de recursos humanos, criando instabilidade entre os seus colaboradores. Desta forma, a confidencialidade dos dados, mas também da própria aplicação devem ser garanti-dos e monitorizagaranti-dos pelos administradores.
24 Solução
Tabela 4.13: Requisito RNF05: Usabilidade RNF05 Usabilidade
A aplicação deve apresentar uma interface amigável, intuitiva e de fácil utili-zação, garantindo uma boa comunicação entre utilizador e a aplicação.
A usabilidade permite apresentar a informação de uma forma agradável, de fácil leitura, tentando proporcionar uma experiência fluida aos utilizadores. Este requisito pode minimizar alguns erros de utilização através do desenvolvimento de um conjunto de funcionalidades de assistência ao utilizador para o orientar nos passos necessários à realização da ação.
4.3
Arquitetura
Para a implementação da página web na empresa foi necessário pensar no processo de integração dos sistemas já existentes com o protótipo criado, definir quais os processos chave e criar o modelo relacional da aplicação.
4.3.1 Integração de Sistemas
Para criar uma integração da aplicação web com os sistemas já existentes na empresa, a aplicação tem de ser capaz de recolher dados da plataforma de desenvolvimento EAGLE, bem como da plataforma Sage retail.
Após uma análise da EAGLE optou-se por realizar esta recolha de dados recorrendo a um utili-zador que exportará a BOM em formato CSV e posteriormente, importará o mesmo ficheiro para aplicação web.
Relativamente à comunicação com a plataforma Sage Retail, utilizada pelo departamento de ges-tão, numa fase inicial do desenvolvimento da aplicação não foi possível ter acesso à base de dados desta plataforma. Por conseguinte, o departamento de gestão da empresa sugeriu que a interação entre as duas plataformas fosse realizada recorrendo a um utilizador através da exportação de um ficheiro CSV, que seria integrado na aplicação web e vice-versa.
A Figura 4.1 mostra, o primeiro esquema desenvolvido para a interação entre as plataformas da empresa e a aplicação web desenvolvida, cujo o nome atribuído foi Gecel ( Gestão de componentes electrónicos).
Já em fase de desenvolvimento da aplicação foi facultado o acesso à base de dados da plataforma Sage Retail, sendo possível fazer uma melhor análise da mesma. O Sage Retail pode armazenar
4.3 Arquitetura 25
Figura 4.1: Interceção das diversas plataformas
os dados em dois tipos de bases, MySQL ou Access. A base de dados que consta na empresa para a plataforma Sage Retail é Access. Deste modo, optou-se por ler diretamente os dados necessários na base de dados access do Sage Retail. Em conjunto com a empresa optou-se, por questões de segurança, que a aplicação web somente fizesse a leitura, no entanto não seria permitida a alteração dos dados existentes na base de dados do Sage Retail. A Figura 4.2 mostra o esquema desenvolvido para a interação entre as plataformas da empresa e a aplicação web, tendo em conta este conhecimento.
Figura 4.2: Nova Interceção das diversas plataformas
4.3.2 Processos Chave
Tendo em conta a importância de alguns processos para o estabelecimento da solução, foram debatidos previamente com a empresa, os seguintes processos chave: Processo de criação de um produto, bem como Processo de Produção Virtual.
26 Solução
4.3.2.1 Processo de Criação de um Produto
Sabendo que um dos processos fundamentais para esta empresa é a associação das referências internas aos componentes que constituem cada um dos produtos, foi elaborado em conjunto com o engenheiro de desenvolvimento um fluxograma presente na Figura 4.3. Este fluxograma esque-matiza o processo de criação de um novo produto na aplicação web.
4.3.2.2 Processo de Produção Virtual
Um dos objetivos da aplicação é permitir ao departamento de gestão realizar produções virtuais, podendo assim prever melhor as quantidades de stocks necessárias para a produção dos diferentes produtos. Para poder ter um visão mais clara deste processo foi elaborado o fluxograma presente na Figura 4.4, antes do início do desenvolvimento da aplicação.
4.3.3 Modelo Relacional
A empresa possui um vasto stock de componentes com diferentes características. Para os uti-lizadores da aplicação Gecel terem acesso a esta vasta informação é necessário recorrer a uma base de dados dedicada à mesma. Como a empresa já possuía outras bases de dados em MySQL, optou-se pela mesma, para desenvolver o modelo relacional da aplicação e pelo programa MySQL Workbench para a leitura do mesmo.
4.3 Arquitetura 27
28 Solução
4.3 Arquitetura 29
Capítulo 5
Implementação
5.1
Arquitetura do sistema
Uma aplicação web é constituída por vários tipos de linguagens como PHP, HTML, CSS, Javas-cript, assim como ficheiros de imagens.
Neste projeto optou-se por uma divisão do código em diversos ficheiros separados por linguagem, permitindo organizar a construção da aplicação e facilitar a deteção e correção de erros de código. O desenvolvimento da lógica de apresentação (os templates em HTML) e da lógica de negócio (código PHP) foram interligados através do Smarty, que é um motor de compilação de templates PHP, descrito na Secção 2.3.6.
Para melhor compreensão do desenvolvimento da aplicação web, dividiu-se a tarefa de desenvol-vimento em três partes:
• Apresentação
• Lógica de negócio
• Acesso a dados
A Figura 5.1 esquematiza a arquitetura da plataforma representando as várias camadas da aplica-ção.
32 Implementação
Figura 5.1: Esquema da estrutura dos ficheiros
5.2
Páginas Implementadas
Nesta secção será apresenta a aplicação web desenvolvida como solução para o problema proposto pela empresa NIBBLE. Esta aplicação foi desenvolvida tendo como pressupostos os requisitos presentes na Secção 4.2 e foi denominada Gecel.
Optou-se por iniciar a descrição com um mapa da aplicação, que consta na Figura 5.2 onde cons-tarão as páginas da aplicação e a sua organização.
Posteriormente, serão apresentadas as páginas mais importantes da aplicação e será realizada uma descrição sucinta das funções que podem ser realizadas em cada uma delas.
Todas as páginas apresentam um cabeçalho com o logótipo da empresa, seguido de uma barra de navegação, que permite navegar na aplicação.
5.2 Páginas Implementadas 33
Figura 5.2: Mapa de páginas da aplicação Gecel
5.2.1 Interface de produtos
Após ser efetuado login o utilizador é direcionado para a página produtos, que está presente na Figura 5.3: Nesta página o utilizador pode visualizar os produtos que a empresa produz. Para adicionar um novo produto, o utilizador deve carregar no botão “Novo Produto” e responder ao formulário onde é pedido o nome do produto e a imagem do mesmo. O utilizador poderá também, dar inicio a uma nova produção selecionando o botão “Produzir”, onde deve indicar qual o produto, a versão e a quantidade que pretende produzir.
34 Implementação
Após selecionar um produto, o utilizador é direcionado para uma página idêntica à da Figura 5.4, onde está representado um dos produtos. O utilizador pode, assim, ver todas as versões existentes do produto, e adicionar novas versões premindo o botão “Nova Versão”.
Caso seja necessário mudar o nome ou a imagem do produto, basta selecionar o botão “Editar Produto”, onde é redirecionado para uma nova página em que consta o formulário com os dados atuais do produto. Para editar basta alterar os dados e premir o botão “Guardar”.
Figura 5.4: Página de um Produto
Para visualizar uma versão, o utilizador deverá clicar sobre o nome da versão que pretende se-lecionar, surgindo a página presente na Figura 5.5. Nesta página constam todos os componentes que constituem a versão, sendo possível adicionar mais componentes através do botão “Adicionar Componente” e remover um componente da lista, clicando sobre o botão correspondente com a forma de “X”.
O utilizador pode ainda adicionar alternativas a um componente, pois em caso de falta de stock do mesmo, podem ser utilizadas as alternativas para satisfazer a produção, para isso basta selecionar o botão com o símbolo de “+”, onde aparecerá um popup para selecionar o componente.
Para iniciar a produção deste produto, o utilizador prime o botão “Produzir” sendo somente neces-sário indicar a quantidade pretendida.
Quando é criada uma nova versão é necessário adicionar todos os componentes que constituem o produto (BOM). De forma a adicionar todos os componentes mais rapidamente, o utilizador poderá importar a BOM do produto, para isso, esta deverá estar no formato de CSV. O utilizador clica então, no botão “Importar CSV” sendo depois direcionado para a página representada na Figura 5.6.
5.2 Páginas Implementadas 35
Figura 5.5: Listagem de componentes de um Produto
5.2.2 Interface de importação da BOM
Quando uma BOM é importada, alguns componentes são associados automaticamente à referência interna da empresa, sendo assinalados com um marcador verde seguidos da referência e das carac-terísticas dos componente, como é possível ver na Figura 5.2.2. Os componentes não associados automaticamente são assinalados com um marcador vermelho, devendo o utilizador selecionar a referência do componente correto. Quando o utilizador seleciona uma referência para um dado componente são indicados, na coluna “dados” da tabela, os parâmetros do componente selecio-nado, a fim de confirmar, se é este o que o utilizador pretende escolher.
36 Implementação
Caso a BOM contenha componentes que ainda não constem no inventário da empresa, o utilizador poderá inseri-los através do botão “Adicionar Componente”.
Após serem associados todos os componentes às respetivas referências internas o utilizador deverá submeter a lista de componentes através do botão “Submeter”.
5.2.3 Interface de componentes
Para visualizar todos os componentes que constam no inventário da empresa foi desenvolvida a página: “Componentes” representada na Figura 5.7. Esta página pode ser acedida através da barra de navegação no separador “Componentes”. Nesta página encontra-se uma tabela, que apresenta todos os componentes e seus respetivos stocks nos diferentes armazéns, o número de unidades encomendadas e o somatório do stock mais as encomendas.
De forma a tornar uma pesquisa dos componentes mais célere, estes podem ser filtrados por cate-gorias, ou pelo nome através da barra “Pesquisa”.
Para sincronizar os componentes com os dados presentes na plataforma de gestão Sage Retail da empresa, deverá ser premido o botão “Atualizar Componentes”. Assim, serão atualizados todos os stocks e encomendas dos respetivos componentes, bem como, serão adicionados os que ainda não constam na plataforma Gecel.
Figura 5.7: Página dos Componentes
Nesta página, podem ainda ser adicionados componentes através do botão “Novo Componente”. Caso seja criado um componente novo, este irá para a lista de componentes não sincronizados, que pode ser consultada clicando no botão “Não Sincronizados”, pois terão de ser exportados para serem introduzidos na plataforma Sage Retail através de um ficheiro CSV.
5.2 Páginas Implementadas 37
Figura 5.8: Página dos Componentes
Selecionando um componente, serão visualizadas todas as informações do respetivo componente: categoria, parâmetros, fornecedores, preços, assim como os produtos nos quais está a ser utilizado, como mostra a Figura 5.8. Podem ainda ser editados os dados do componente através do símbolo de editar, ou eliminar o componente no botão “X”
5.2.4 Interface de fornecedores
Na página fornecedores são apresentados todos os fornecedores de componentes da empresa.
38 Implementação
É possível adicionar novos fornecedores à plataforma selecionando o botão “Novo Fornecedor” e preenchendo o formulário com os dados necessários.
Para novas ofertas de componentes o botão “Nova Oferta” dispara um popup com um formulário onde o utilizador deverá indicar o fornecedor, componente, preço e data da oferta. Todos os fornecedores listados podem ser exportados para um ficheiro CSV premindo o botão “Exportar Fornecedores”.
Para selecionar um fornecedor o utilizador deve clicar sobre o nome do mesmo, sendo direcionado para a página, como ilustra a Figura 5.10.
Nesta página estão representados todas as ofertas de componentes do fornecedor à empresa. É nesta página, que é possível editar ou excluir o fornecedor, selecionando os botões corresponden-tes.
Figura 5.10: Página de um fornecedor
5.2.5 Interface de categorias
Na página das categorias estão representadas todas as categorias dos componentes utilizados na empresa, como ilustra a Figura 5.11. Na tabela constam também as quantidade dos componentes por categoria. Caso seja premido o nome de uma categoria é possível visualizar as características da mesma, como os respetivos componentes que lhe pertencem.
5.2 Páginas Implementadas 39
Figura 5.11: Página de categorias
5.2.6 Interface de produção
Quando um utilizador pretende produzir um produto, após indicar a quantidade que pretende, é direcionado para uma página idêntica à da Figura 5.12, onde será realizado o planeamento dessa produção. De forma a evitar alguns erros foram implementadas algumas regras em javascript que alertam o utilizador quando as necessidades não são cumpridas, ou se utiliza componentes para além do stock disponível.
Figura 5.12: Página de planeamento de produção
Os componentes são separados por uma linha preta mais carregada consoante as suas característi-cas. Os componentes alternativos são agrupados ao componente principal, partilhando as caracte-rísticas “Q. Nec” e “Q. Falta”, que representam a quantidade necessária a e a quantidade em falta,
40 Implementação
respetivamente.
O utilizador deverá indicar a quantidade a enviar (“Q. Enviar”) e a utilizar (“Q. Utilizar”), conso-ante o stock se encontre o armazém NIBBLE ou armazém externo respetivamente, até a coluna de quantidade em falta ser igual a 0, não podendo ultrapassar as quantidades em stock dos armazéns. Após concluído o processo de planeamento o utilizador é encaminhado para a página, representada na Figura 5.13 onde constam todas as produções, concluídas ou em produção.
Quando um produção é concluída o utilizador devera selecionar o botão com o símbolo de “visto”, que mudará o estado da produção para concluído.
É possível visual ainda todos os componente que estão a ser utilizados em todas as produções ativas, através do botão “Em Produção”.
Capítulo 6
Validação
6.1
Introdução
Durante este projeto foi desenvolvido uma aplicação web protótipo como solução ao problema apresentado pela empresa. Essa aplicação foi posteriormente, implementada na empresa, possi-bilitando aos vários departamentos utilizá-la no seu dia-a-dia como suporte às atividades desen-volvidas. Esta aplicação pretendia tornar mais rápida e eficiente a troca de informação entre os diferentes departamentos e possibilitar uma melhoria significativa nos processos de associação de componentes às suas respetivas referências internas, diminuindo a quantidade de falhas ocorridas, bem como melhorar o processo de planeamento de produção.
Para a validação da aplicação web foi feita uma análise dos processos de associação de refe-rências e planeamento de produção, comparando o anterior modelo existente na empresa com o introduzido com a nova aplicação. Os requisitos foram também analisados e validados através da demonstração da sua sua existência na aplicação desenvolvida. Foi planeada também, uma análise temporal dos processos realizados com e sem a aplicação.
6.2
Análise dos processos
O processo de associação de referências utilizado pela a empresa, descrito na Secção 3.2.1 era re-alizado por dois departamentos: Gestão e Desenvolvimento. Com a implementação da aplicação web Gecel, o processo de associação, passou a se o que está representado no fluxograma presente na Figura 6.1. Como é possível verificar, o processo passa a ser somente realizado pelo departa-mento de desenvolvideparta-mento, ou seja pelo engenheiro responsável pelo projeto, o que simplifica o mesmo.
42 Validação
Reduzindo o número de pessoas intervenientes e o número de etapas do processo, é possível concluir que o número de falhas também é reduzido, pois parte do processo é realizado automati-camente pela aplicação.
Figura 6.1: Novo processo de associação de referências internas
Relativamente ao processo de planeamento de produção descrito na Secção 3.2.2, sem a aplicação Gecel, era necessário exportar todo o inventário da empresa da plataforma Sage Retail e fazer a comparação com as necessidades recorrendo a plataforma Excel. Deste modo, não era possível obter informação das matérias primas que estavam a ser utilizados nas produções em curso, e por isso, o stock que se encontrava no Sage Retail nem sempre correspondia à realidade.
Através da aplicação Gecel o gestor pode realizar o planeamento das produções sem necessitar de recorrer a mais nenhuma aplicação, tendo uma visão clara dos componentes que dispõem e dos que estão ser utilizados na produção, porque como visualizado na Figura 5.12 na mesma página estão disponíveis os dados sobre o stock contabilizado na plataforma Sage Retail, os componentes encomendados, bem como os componentes que estão a ser utilizados nas produções em curso. As-sim, existe uma simplificação no processo de planeamento de produção, sendo necessário apenas 3 passos para a conclusão do processo:
• 1º passo: seleção do produto e número de unidades a produzir;
• 2º passo: confirmação das quantidades a utilizar dos diferentes componentes em armazém; • 3º passo: conclusão do processo.
Com a aplicação também são minimizados os erros de stock, pois existe uma visão global sobre a disposição dos componentes nos diferentes departamentos da empresa.
