F
ACULDADE DEE
NGENHARIA DAU
NIVERSIDADE DOP
ORTOSistema de gestão e apoio à produção
Joana Peneda Paiva Cubal de Almeida
Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Orientador interno: Professor Luís Teixeira
Orientador externo: Engenheiro João Rodrigues
Resumo
As ferramentas de gestão são fundamentais no dia a dia de uma empresa ao constituírem um suporte fundamental para a operacionalização, controlo, eficiência e eficácia dos seus processos.
A NIBBLE é uma empresa sediada na Trofa que é especializada na Gestão e Desenvolvimento de Projetos de Engenharia Eletrónica e que possui uma desta ferramentas (REPRO). No entanto face a algumas lacunas e ineficiências detetadas, foi sentida a necessidade de proceder a uma melhoria da mesma.
De forma a criar uma nova plataforma de gestão, foi necessário proceder a uma avaliação dos processos atuais da empresa, da qual resultou a elaboração do mapa de processos AS IS.
Após a análise e estudo detalhado deste, foram identificados alguns problemas e elaborados os requisitos que permitiram dar inicio ao desenvolvimento de uma nova ferramenta (REPRO+).
Foram, em seguida, criados o mapa de processos TO BE, os casos de uso e os devidos moc-kupsque permitiram apresentar à empresa uma possível solução do problema. Esta solução foi analisada e aprovada pela empresa, tendo daí surgido o desenvolvimento e a criação do REPRO+. A ferramenta desenvolvida dá o apoio necessário aos técnicos, procurando ser um auxílio no desempenho das funções de cada um, bem como permitir o registo de todas as etapas de alguns dos processos da empresa.
A avaliação final da mesma foi bem sucedida, tendo-se concluído que esta apresenta vanta-gens relativamente à anterior quer em termos de tempos, como os de registos, que em termos da facilidade e versatilidade na sua utilização.
Abstract
Management tools are fundamental in the daily basis of a company since they create a support which is essential for the operationalization, control, efficiency and accuracy of its processes.
NIBBLE is a company from Trofa specialized on the management and development of elec-tronic engineering projects which possesses one of these tools (REPRO). However, due to some disparities and inefficiencies detected, the need to improve it was felt.
To create this new management platform, it was necessary to start with an evaluation of the current operations of the company, from which the map of operations AS IS was created.
After it’s analysis and detailed study, some problems were identified and the requirements, allowing the initiation of the development of a new tool (REPRO+) were identified.
The map of operations TO BE, the use cases and their mockups were then created, allowing a possible solution for the problem, to be presented to the company. It’s analysis and approval by the corporation gave rise to the development and creation of REPRO+.
The tool developed guarantees the necessary support for the technicians through helping them to perform their functions and ensuring a record of all the steps of some of the company’s opera-tions.
The final evaluation of this tool was successful, given that it was concluded that it presents several advantages relative to the previous one, both in terms of time of registration as well as in terms of the facility and versatility in its use.
Agradecimentos
Deixo aqui expressa a minha gratidão ao meu orientador interno, Professor Luís Teixeira, pelo incentivo e apoio nas diversas questões e dúvidas que foram surgindo ao longo desta disserta-ção. Quero agradecer igualmente ao meu orientador externo Eng. João Rodrigues, pelos seus ensinamentos e pelo auxilio prestado no desenvolvimento da dissertação, sem os quais teria sido impossível alcançar os resultados obtidos.
Gostaria de agradecer à empresa NIBBLE, pela oportunidade de trabalhar neste tema bem como por todo o apoio durante a realização desta dissertação.
Agradeço à Faculdade de Engenharia da Universidade do Porto e a todos os meus professores, por toda a formação e desafios propostos, que me permitiram o conhecimento necessário para a realização desta dissertação bem como para os desafios futuros que me esperam.
Um especial agradecimento à minha família, por todo o apoio durante toda a minha vida pes-soal e académica, por toda a paciência que tiveram e por todos os ensinamentos que me permitiram chegar até aqui. Foram sem dúvida o meu fôlego durante todos estes anos. Agradeço-lhes também, tal como ao Engenheiro e amigo Paulo Azevedo, por todos os erros corrigidos nesta dissertação.
Por último, agradeço aos meus amigos e colegas de equipa, por todo o apoio constante e ajuda na passagem de certos obstáculos, não só ao longo desta dissertação, mas ao longo de todos estes anos académicos e desportistas.
Joana Peneda Paiva Cubal de Almeida
“Great web design without functionality is like a sports car with no engine”
Paul Cookson
Conteúdo
1 Introdução 1 1.1 Enquadramento . . . 1 1.2 Objetivos . . . 1 1.3 Motivação . . . 2 1.4 Organização da dissertação . . . 3 2 Revisão Bibliográfica 5 2.1 Sistemas de informação . . . 52.1.1 Sistemas de informação empresarial . . . 6
2.2 Construção de um sistema de informação . . . 7
2.3 Aplicação Web . . . 9 2.3.1 Framework . . . 9 3 Análise inicial 15 3.1 Abordagem ao problema . . . 15 3.2 Modelo AS IS . . . 16 3.2.1 Mapa de processos . . . 16 3.2.2 Ferramenta atual . . . 18 3.3 Oportunidades de melhoria . . . 21 4 Solução 23 4.1 Requisitos . . . 23 4.1.1 Requisitos funcionais . . . 23
4.1.2 Requisitos não funcionais . . . 25
4.2 Modelo TO BE . . . 25
4.2.1 Mapa de processos . . . 26
4.2.2 Mockup . . . 27
4.2.3 Tecnologias web a utilizar . . . 32
5 Protótipo 35 5.1 Estrutura e dados da ferramenta . . . 35
5.1.1 Estrutura . . . 35 5.1.2 Base de dados . . . 39 5.2 Ferramenta desenvolvida . . . 45 5.2.1 Autenticação . . . 45 5.2.2 Menu . . . 45 5.2.3 Zona administrativa . . . 46 5.2.4 Zona testes . . . 49 ix
5.2.5 Zona de reparação . . . 54 5.2.6 Zona do cliente . . . 63 6 Resultados 67 6.1 Resultados . . . 67 6.1.1 Resultados quantitativos . . . 67 6.1.2 Resultados qualitativos . . . 69
7 Conclusões e Trabalho Futuro 71
7.1 Satisfação dos Objetivos . . . 71
7.2 Principais dificuldade . . . 72
7.3 Trabalho Futuro . . . 72
Lista de Figuras
2.1 Representação do que é um sistema de informação (imagem original retirada do
livro Management Information Systems) [1] ) . . . 5
2.2 Análise do ambiente de um SI (imagem original retirada do livro Management Information Systems)[1] ) . . . 6
2.3 Construção de um sistema de informação (imagem original retirada do livro Ma-nagement Information Systems [1]). . . 7
2.4 Modelo MVC [2] . . . 10
2.5 PHP Frameworkmais populares nos trabalhos [3] . . . 12
2.6 Frameworksmais populares em certos países [3] . . . 12
3.1 Fluxo do processo dos testes e montagem . . . 16
3.2 Mapa de processos AS IS . . . 17
3.3 Menu de entrada no REPRO . . . 18
3.4 Menu principal . . . 18
3.5 Janela de relatório de testes . . . 19
3.6 Janela de registo da montagem . . . 20
3.7 Janela de saída . . . 21
4.1 Mapa de processos TO BE . . . 26
4.2 Mockupda zona administrativa . . . 28
4.3 Mockupda janela de seleção do produto . . . 29
4.4 Mockup da janela da seleção do constituinte referentes ao produto final selecio-nado na figura 4.3 . . . 29
4.5 Mockupdo relatório de testes . . . 30
4.6 Mockupda zona de montagem . . . 30
4.7 Janela referente ao relatório de saída dos produtos para um certo cliente . . . 31
4.8 Mockupda janela de reparação . . . 31
5.1 Estrutura do menu principal da ferramenta com as diferentes autenticações . . . . 36
5.2 Estrutura referente à Zona de Testes . . . 36
5.3 Estrutura referente à Zona de Reparação . . . 37
5.4 Estrutura referente a Zona de Administração . . . 38
5.5 Estrutura referente à autenticação do Cliente . . . 39
5.6 Tabelas da base referentes aos clientes e aos restantes utilizadores . . . 40
5.7 Modelo da base de dados referentes às tabelas dos produtos, constituintes, mode-los, hardwares e firmwares . . . 40
5.8 Modelo da base de dados das tabelas que serão preenchidas maioritariamente na zona de teste . . . 41
5.9 Modelo da base de dados das tabelas que serão preenchidas na zona de reparação
e cliente . . . 42
5.10 Relação entre as tabelas da base de dados da Zona de Administração . . . 43
5.11 Relação entre as tabelas da Base de Dados da Zona de Testes . . . 44
5.12 Relação entre os dados da Base de Dados da Zona de Reparação e da Zona do Cliente . . . 44
5.13 Janela de autenticação dos trabalhadores e administradores . . . 45
5.14 Menus principais da ferramenta | 1-Menu da autenticação do administrador ou trabalhador 2-Menu da autenticação do cliente . . . 45
5.15 Janela do Admin Panel . . . 46
5.16 Página da zona de testes após escolha de produto . . . 49
5.17 Página de criação dos respetivos relatório de testes . . . 50
5.18 Janela de montagem de produtos . . . 51
5.19 Janela de documentos de saída da zona de teste . . . 52
5.20 Janela referente à pesquisa de produtos pelo seu número de série . . . 53
5.21 Página do documento de saída da zona de testes . . . 54
5.22 Janela do documento de entrada da zona de reparação . . . 55
5.23 Pop up do registo de um novo número de série de um produto na base de dados na zona de reparação . . . 57
5.24 Página da ação "reparar" . . . 58
5.25 Pop up de adição dos respetivos constituintes no produto assinalado . . . 59
5.26 Relatório de avaliação que será mandado para o cliente posteriormente . . . 60
5.27 Pop up para iniciar reparação do produto . . . 61
5.28 Página para criação do relatório de reparação ou substituição dos constituintes . . 61
5.29 Página da zona do cliente . . . 63
5.30 Página para criação de novo registo de produtos para reparação . . . 64
Abreviaturas e Símbolos
BD Base de Dados
CSS Cascading Style Sheets FK Foreign Key
HTML Hyper Text Markup Language HTTP Hypertext Transfer Protocol MVC Model-vision-controller
MySQL MY Structured Query Language OPC Other Persons Code
PHP Hypertext Preprocessor PK Primary Key
SI Sistemas de Informação
Capítulo 1
Introdução
1.1
Enquadramento
O contexto na qual uma empresa se insere apresenta diversas ameaças e oportunidades, e está em constante mudança. De modo a assegurar o seu sucesso e sustentabilidade é importante que as empresas se dotem de ferramentas de apoio aos seus processos, por forma a que estes possam ser geridos de uma forma eficaz mas também eficiente. A criação de uma boa ferramenta não é necessariamente a solução para os desafios, sendo essencial um conjunto de fatores para que tudo funcione de forma sinérgica.
A NIBBLE é uma empresa sediada na Trofa, e é especializada na Gestão e Desenvolvimento de Projetos de Engenharia Eletrónica. A NIBBLE desenvolve os seus produtos passando estes in-ternamente por uma fase de teste e montagem. O cliente, após receber estes produtos já montados, se necessário, poderá voltar a envia-los para a empresa de modo a que sejam reparados. Existe também a possibilidade de devolução do produto na íntegra. A empresa propôs esta dissertação com o objetivo de alterar a gestão dos seus processos internos de produção, visando otimizar a ferramenta de gestão já existente.
Em termos de áreas de conhecimento, esta dissertação está inserida, na área de desenvolvi-mento web, sendo também abrangido as áreas de gestão relacionadas com a otimização de proces-sos.
1.2
Objetivos
Esta dissertação tem como principal objetivo a otimização dos processos produtivos da em-presa através da criação de uma ferramenta web, permitindo que todo o trabalhado desenvolvido pelos funcionários seja levado a cabo de uma forma mais eficiente. É importante salientar que,
independentemente desta redução de tempo associado ao desenvolvimento dos processos e do re-gisto dos mesmos na plataforma web, a qualidade dos produtos não deve ser afetada. A comunica-ção entre os vários intervenientes, nomeadamente, técnicos, gestores de produtos e clientes, será algo que estará facilitado com a implementação desta ferramenta, facilitando assim um melhor acompanhamento de registos e resolução de problemas.
O desenvolvimento da ferramenta teve em consideração alguns requisitos de modo a que esta possa ser um facilitador do trabalho dos gestores de produção, nomeadamente no que respeita à capacidade para introdução de novos produtos, novas versões e testes realizados. Deste modo, todas as etapas pelas quais o produto passa, ficam registadas na mesma base de dados, incluindo o controlo, passando pela montagem e eventual entrada em fase de reparação.
O processo de testes está atualmente otimizado e com uma rapidez e eficácia bastante elevada sendo que precisa de uma ferramenta que de forma a agilizar o processo, acompanhe este ritmo. A atual ferramenta de apoio aos processos, é algo ineficiente, sendo que se tende a recorrer a métodos alternativos, tais como o registo através de folhas de cálculo. A criação da ferramenta foi assim um dos pontos mais relevantes desta dissertação, uma vez que o desempenho desta terá de ir ao encontro da velocidade a que os testes são realizados.
Para uma melhor e mais eficiente implementação desta nova ferramenta será necessário adotar o uso de equipamentos de suporte, como por exemplo um leitor de código de barras, podendo estes simplificar e acelerar a introdução de dados dos produtos na ferramenta. Deste modo, diminuímos também os erros humanos que poderão estar a surgir aquando do registo dos respetivos números de série.
1.3
Motivação
A motivação para esta dissertação surge devido à carência por parte da NIBBLE de uma ferra-menta de otimização dos seus processos, cujo intuito seria combater as dificuldade de registo dos produtos, podendo até otimizar tempos em cada um dos seus processos.
Com a criação de uma boa ferramenta e melhoria da gestão dos processos, a NIBBLE, num futuro próximo, poderá usufruir de uma melhoria no seu desempenho ao nível de testes, de mon-tagem e de reparações uma vez que nestes, é muito importante ter em consideração o fator tempo. Deste modo, poderemos dar a possibilidade à empresa, não só de produzir mais, mas também de rentabilizar melhor o seu tempo, fazendo uma melhor distribuição deste por todos os processos.
Assim, através de um registo mais organizado, permite que o gestor de produtos faça um melhor acompanhamento dos processos, tendo noção dos problemas mais comuns de forma a minimizar os mesmos.
1.4 Organização da dissertação 3
1.4
Organização da dissertação
Para além da introdução, esta dissertação contém mais 6 capítulos:
• O capitulo 2, é onde se aborda o estado da arte relativamente ao tema em questão. Este contém uma revisão sobre os sistemas de informação empresariais e um breve estudo sobre aplicações web na atualidade.
• No capítulo 3, estão explicados os primeiros passos no desenvolvimento da dissertação. É neste capítulo que é delineada a abordagem ao problema, tal como a explicação dos proces-sos AS IS e da ferramenta atual REPRO, sendo depois abordados os problemas dos mesmos. • No capítulo 4, enumeram-se os requisitos funcionais e não funcionais da nova ferramenta REPRO+, o modelo TO BE dos processos, alguns dos mockups, casos de uso da solução proposta e por último quais as tecnologias web que se utilizaram.
• No capítulo 5, explica-se o protótipo desenvolvido, analisando a estrutura da base de dados do mesmo, expondo também algumas páginas da ferramenta desenvolvida.
• No capítulo 6, apresentam-se os resultados obtidos com a criação da nova ferramenta RE-PRO+, quer a nível quantitativo, quer a nível qualitativo.
• No capítulo 7é abordado o nível de cumprimento dos objetivos fixados para a dissertação, prestando também sugestões para um trabalho futuro tal como as principais dificuldades sentidas na criação deste trabalho.
Capítulo 2
Revisão Bibliográfica
2.1
Sistemas de informação
Os Sistemas de Informação (SI) são a convergência entre os recursos humanos e os recursos computacionais, sendo portanto utilizados como plataforma de comunicação. Estes permitem a criação e armazenamento de informação, bem como a utilização desses dados para um melhor controlo e planeamento do que tem de ser feito, de modo a que todas essas decisões sejam tomadas de forma ponderada. [4]
É importante ter a noção que os SI não são apenas desenhados tendo em conta a tecnologia, mas também tomando em consideração o conjunto de processos organizacionais (gestão) bem como as pessoas envolvidas nos processos (organização), como podemos ver na figura 2.1.
Figura 2.1: Representação do que é um sistema de informação (imagem original retirada do livro Management Information Systems)[1] )
Estes sistemas têm vindo a ser cada vez mais utilizados a nível empresarial, uma vez que, nos últimos tempos tem havido um aumento significativo do uso das tecnologias.
A sua utilização tem como objetivo permitir a análise, e melhoria bem como potenciar o fun-cionamento das empresas. Nesta área de atuação, uma boa decisão pode influenciar o aumento de capital de uma empresa do mesmo modo que uma má decisão pode fazer com que a empresa perca capital. É uma área que requer um grande investimento mas que, ao mesmo tempo, se bem trabalhada, pode trazer muitos benefícios, inclusivamente um aumento no ranking a nível empresarial.[1]
Assim, um SI contém informação não só interna à organização mas também do seu ambiente externo, sendo importante que a empresa tenha conhecimento da sua concorrência, nomeadamente no que respeita a fornecedores, clientes existentes e ao que estes procuram. A figura 2.2representa o contexto de uma organização bem como as partes interessadas com que esta interage.
Figura 2.2: Análise do ambiente de um SI (imagem original retirada do livro Management Infor-mation Systems)[1] )
2.1.1 Sistemas de informação empresarial
A implementação de um Sistema de Informação nas empresas deve ter em conta a criação, a transmissão, o tratamento e o armazenamento da informação. A decisão para implementação destes sistemas tem que ser tomada com base num prévio estudo da situação, uma vez que os investimentos necessários para construir e realizar a sua manutenção são elevados. Só fará sentido investir na implementação destes sistemas se a empresa conseguir obter retorno.
Cada vez mais se opta pela empresa digital ("Digital Firm"), onde se cria um relacionamento de negócio com funcionários, clientes e outros parceiros externos, através de redes digitais. Estas são feitas por plataformas criadas de forma a suportar funções e serviços das organizações. Assim, estas empresas oferecem uma maior flexibilidade a nível organizacional e de gestão, sendo uma das
2.2 Construção de um sistema de informação 7
suas grandes vantagens competitivas a fácil troca de informação dentro e para fora da organização, nomeadamente com clientes. [1]
2.2
Construção de um sistema de informação
Para construir um SI é necessário percorrer um conjunto de etapas, podendo ser necessário a reestruturação do mesmo, quer a nível de material, quer a nível de gestão e de processos da em-presa. Assim para construir estes sistemas é importante seguir 6 fases conforme ilustrado na figura
2.3e apresentadas de seguida. [1]
Figura 2.3: Construção de um sistema de informação (imagem original retirada do livro Manage-ment Information Systems [1])
1. Análise do sistema
Numa primeira fase é importante fazer uma análise do problema que a organização pretende resolver. É necessário perceber quais as causas raíz do mesmo e qual o caminho a percorrer de modo a que seja possível desenhar uma solução fiável e funcional. É desta análise que é retirada toda a informação necessária para a compreensão e definição de uma solução para o problema, e onde é feito o levantamento de requisitos a satisfazer; [1]
2. Desenho do sistema
Nesta fase é avaliado o que é necessário para o sistema cumprir os requisitos, ou seja, é aqui que é feito o planeamento geral e escolhidas as especificações do sistema utilizando a informação recolhida na fase da análise; [1]
3. Programação
Nesta fase implementa-se o sistema com base nos requisitos e esboços criados nas fases anteriores;
4. Testes
De forma a perceber se a implementação do sistema está alinhada com os requisitos, é ne-cessário efetuar um conjunto de testes para verificar se os resultados obtidos correspondem ao que era pretendido, apurando também a sua funcionalidade;[1]
5. Integração do sistema
Após todos os testes serem efetuados procede-se à instalação do novo sistema na empresa. Há várias métodos para se fazer esta transição: [1]
• parallel strategy
Este método faz com que os dois sistemas sejam corridos em paralelo de modo a verificar se o novo sistema implementado contém erros e, caso se verifique, a empresa terá sempre o antigo sistema funcional, não prejudicando o trabalho a ser realizado; • direct cutover
Neste método, seleciona-se um dia específico no qual é desativada a ferramenta an-tiga e colocada em funcionamento a nova. Este método pode trazer associado muitos riscos, podendo ter consequências prejudiciais para a empresa, inclusivamente mone-tários;
• pilot study
Este método implementa o novo sistema colocado num único departamento da em-presa, de modo a ser possível estudar as suas funcionalidades em ambiente empresarial sem prejudicar como um todo o trabalho da empresa. Quando esta estiver a trabalhar ao seu máximo potencial, esta poderá ser implementada nos restantes departamentos da empresa;
• phased approach
Este método faz com que o sistema seja implementado na empresa por funções ou cargos, ou seja, tal como o anterior em vez de introduzir o sistema num departamento este será introduzido por cargos.
6. Produção e manutenção
Finalmente, depois do novo sistema já ter sido instalado e o antigo removido, este deverá ser mantido em constante observação e consequente manutenção para correção de pequenos erros que poderão existir, podendo até ser acrescentadas novas funcionalidades. [1]
2.3 Aplicação Web 9
2.3
Aplicação Web
Com o passar dos anos e com a rápida evolução da tecnologia, as aplicações web são algo que cada vez mais exigem manutenção, vigilância e modificação por ajuste.
2.3.1 Framework
Uma framework é um conjunto de códigos-fonte, funções, classes e metodologias que ajudam na criação de uma aplicação web. A utilização das mesmas tem como vantagem a possibilidade de utilizar algo previamente criado e a sua aplicação ao trabalho a desenvolver. [5]
Muitas frameworks têm bibliotecas com acesso a bases de dados e templates sendo que em caso de se pretender melhorar alguma funcionalidade é necessário perceber o código desenvolvido por outra pessoa (OPC). Numa primeira abordagem, o programador poderá sentir-se bloqueado, uma vez que cada framework é programada de forma diferente mesmo sendo o conceito base o mesmo. Porém, a longo prazo os programadores vão percebendo que aquele esforço inicial de aprendizagem é algo que compensa, uma vez que se tem acesso a funcionalidades já criadas, podendo utiliza-las sem as ter de as criar de raiz. [2,5]
Assim, num projeto com grandes dimensão, é importante ter disponíveis as tecnologias cor-retas e que melhor se adequam ao desenvolvimento do mesmo. Ao utilizar uma framework, di-minuímos o tempo, o esforço e os recursos necessários para desenvolver e manter uma aplicação web. Ao utilizarmos esta tecnologia fazemos com que haja uma separação vincada entre a parte lógica da aplicação e a visão da mesma. [Modelo-Visão-Controlador (MVC)]. [6]
2.3.1.1 Arquitetura de uma framework
De modo a entender o funcionamento das frameworks, é importante perceber a sua arquitetura MVC.
O MVC é um padrão de arquitetura de software que faz a separação entre o utilizador e o controlo da aplicação, sendo este um padrão que separa as aplicações em várias camadas fazendo com que a complexidade do projeto diminua e aumente a sua flexibilidade.[7]
Como podemos ver na figura 2.4, existem três grandes divisões: a visão, o modelo e o con-trolador, sendo estas explicadas posteriormente.
Figura 2.4: Modelo MVC [2]
• Visão
Na visão é gerada uma representação gráfica dos dados existentes no modelo, sendo que estes dados podem ser colocados em forma de gráficos, texto, imagens ou tabela de modo a que o utilizador os possa visualizar e manipular. [7]
No desenvolvimento da aplicação é possível desenhar estas janelas, utilizando linguagens como HTML, CSS e Javascript de modo a que seja possível uma interação mais intuitiva por parte do utilizador; [2]
• Modelo
É no modelo onde é possível ir buscar toda a informação necessária de modo a satisfazer as operações dadas pelo utilizador. Aqui, estão armazenados todos os dados, sendo que quando há alguma alteração, os controladores são notificados e estes posteriormente notificam a visão; [2]
• Controlador
É no controlador que é feito o processamento e a resposta dos eventos feitos pelo utilizador, ou seja, analisa a entrada e envia comandos para o modelo e para a visão.
Resumindo, o controlador é a interface entre o modelo e a visão, manipulando os dados usando o modelo e interagindo com a visão enviando-lhe os dados necessários. [2,7] O modelo, apresentado na figura 2.4 e numerado de 1 a 6, funciona da seguinte forma: 1. Utilizador envia um requisito ao controlador, 2. O controlador analisa o requisito e chama o modelo, 3. O modelo realiza a lógica necessária e faz a devida coneção com a base de dados
2.3 Aplicação Web 11
posteriormente, 4. O modelo envia ao controlador o resultado obtido, 5. O controlador manda a informação para a vista, 6. O requisito está terminado quando este é enviado para o utilizador. [2] Conhecendo agora o conceito de MVC, é possível compreender melhor o conceito de uma frameworke qual a necessidade de a utilizar num projeto de aplicação web.
2.3.1.2 PHP frameworks
O linguagem PHP tornou-se numa das linguagens mais utilizadas no desenvolvimento web. Esta linguagem é desenhada especificamente para o uso de aplicações web, e visto ser uma lingua-gem de programação Open-Source tem três grandes vantagens: o suporte a diversos tipos de base de dados, a utilização de estrutura de linguagem de C e Perl e o facto de ter muita documentação, uma vez que tem uma grande escala a nível mundial. [2,8,6]
Cada vez mais o número de frameworks de PHP tem vindo a aumentar. Apesar de, por base serem todas idênticas, estas distinguem-se pela evolução que têm e através das funcionalidades que oferecem ao utilizador.
Para entender melhor quais as frameworks mais utilizadas atualmente, foi necessário fazer uma pesquisa das mesmas.
Para escolher uma framework, não basta que esta tenha todas as funcionalidades necessárias nem que seja a melhor do mercado. O mais importante é ser uma framework que o programador conheça e na qual confia. A escolha de uma framework é assim uma fase importante para dar arranque ao desenvolvimento de uma aplicação web, visto que tanto a rapidez como a qualidade do trabalho irá depender dela. [8,5]
Estudo das frameworks
Como podemos ver nas figuras 2.5e 2.6, existem duas frameworks que se destacam a nível empresarial quando comparadas com as restantes, o Laravel e a Symfony2. [3]
É importante realçar que a framework PHP utilizada pela empresa NIBBLE em algumas das suas aplicações se encontra na quarta posição (CodeIgniter).
Figura 2.5: PHP Framework mais populares nos trabalhos [3]
Na figura 2.6, é possível verificar a distribuição da popularidade das frameworks por países concluindo-se que em países de grandes dimensões (Estados Unidos, Reino Unido, Alemanha), são escolhidas as duas primeiras frameworks apresentados no figura 2.5. [3]
Também na figura 2.6, é possível perceber que a framework Laravel, é da mesma forma a mais escolhidas pelos portugueses para o desenvolvimento de aplicações web.
Figura 2.6: Frameworks mais populares em certos países [3]
Tendo em consideração a popularidade das frameworks Laravel e Symfony2, bem como o facto da framework CodeIgniter ser a ferramenta usada na empresa NIBBLE, apresentam-se de seguida algumas características das mesmas.
2.3 Aplicação Web 13
Laravel
Laravel é atualmente a frameworks mais utilizada, tendo sido criada em 2011 por Taylor Otwell. As vantagens de utilização desta frameworks são as seguintes: [9,10]
• A migração de dados, uma vez que esta facilita a comunicação com a base de dados; • Utilização de Eloquent, sendo este um wrapper de base de dados. Este faz com que haja
conexão com a base de dados sempre que haja um pedido e fecha a base de dados quando este pedido é terminado;
• É uma framework open source, o que faz com que muitos programadores sugiram à fra-meworknovas ideias e funcionalidades, fazendo com que a ferramenta esteja em constante evolução. Deste modo, esta possui uma extensa documentação uma vez que existe uma comunidade de suporte muito ampla;
• Mesmo que sejam criadas novas versões, uma vez que esta está em constante evolução, o utilizador não necessita de alterar o código anteriormente escrito;
• A framework Laravel utiliza a arquitetura MVC;
• São utilizads templates e Blades, fazendo com que a programação seja mais simples. É de notar que o Blade é a visão do MVC da aplicação;
• Laravel utiliza middlewares, sendo esta muito útil para filtrar requisitos de HTTP. Por exem-plo, os middlewares que verificam se o utilizador está autenticado e se este tem permissão para aceder a certas páginas ou até funções específicas da aplicação, fazendo aumentar o nível de segurança da mesma.
Symfony2
Logo a seguir à framework Laravel surge a Symfony2, tendo esta também sido lançada em 2011. As suas vantagens são as seguintes: [11,12]
• Tem boa documentação;
• A complexidade na criação de um projeto é reduzida, uma vez que esta contém uma estrutura inicial bem organizada para o início de um projeto;
• Esta framework não utiliza só o conceito MVC;
• Cada programador escolhe qual a biblioteca que pretende (ex:PHP ou TWIG para a visão); • Esta framework tem medidas de segurança para tornar as aplicações o mais seguras
CodeIgniter
Por último foi estudado o CodeIgniter uma vez que é a framework utilizada atualmente na empresa NIBBLE em algumas das suas aplicações. Apesar desta framework estar colocada pelos programadores abaixo do laravel e do Symfony2, como ilustrado na figura 2.5, não faz desta uma frameworkincapaz. As vantagens para a mesmas são as seguintes: [13,14]
• CodeIgniter é uma framework open-source criada para o uso de aplicações web. • Utiliza o modelo MVC.
• Existência de uma biblioteca já incorporada que o programador pode utilizar quando neces-sário, apesar de esta não ser muito ampla;
• Uma framework com bastante documentação, tornando também mais fácil a instalação da mesma
• O ambiente de trabalho desta framework é fácil de usar, sendo amigável para o usuário • O espaço ocupado por esta framework é reduzido. Não sendo necessário qualquer tipo de
re-configuração para esta funcionar;
Um dos grandes problemas desta framework é o facto de estar estagnada, tendo uma reduzida gama de versões, sendo que começa a ficar desatualizada quanto às tendências evolutivas do PHP.
Hoje em dia muitas empresas recorrem a empresas que criam softwares de gestão como é o caso da SAP que cria sistemas de gestão empresariais (ERP). Tal opção torna-se no entanto bastante onerosa. Deste modo, as empresas que necessitam de programas de menor dimensão, preferem contratar pessoas para criar-los de raiz do que comprar algo já feito e otimizar de acordo com o que é necessário.
Capítulo 3
Análise inicial
Neste capítulo será abordado e explorado o modelo AS IS. Será realizada a análise dos vários processos da ferramenta atualmente utilizada na empresa NIBBLE, e identificados os problemas detetados nesta.
3.1
Abordagem ao problema
No mundo empresarial é importante que os funcionários tenham acesso à informação de que necessitam relativamente aos produtos que circulam na empresa, bem como o percurso dos mes-mos. Para que haja esse tipo de conhecimento é necessário uma ferramenta que permita a partilha da informação relevante entre todos os envolvidos.
Sendo a NIBBLE uma empresa que concebe e produz os produtos que comercializa é impor-tante a existência de uma ferramenta com essas características.
Dentro da NIBBLE os produtos desenvolvidos poderão passar por três processos distintos a saber:
1. Testes aos constituintes e montagem do produto; 2. Reparação do produto, se necessário;
3. Devolução do produto, se necessário (na empresa NIBBLE raramente acontece, uma vez que são os seus distribuidores que tratam desse processo).
De momento, a empresa já possui uma ferramenta, com o nome REPRO onde é possível registar todas as fases pelas quais passa o produto desde os testes, montagem e saída dos mesmos, incluindo a reparação de um produto já existente.
Com o objetivo de ter uma ferramenta que permita de uma forma mais clara e intuitiva criar, manter, e arquivar esses registos surgiu a necessidade de criar uma nova ferramenta a que se deu o nome de REPRO+. Nesta conceção foi possível otimizar alguns processos da empresa, de modo a ser gerado um fluxo mais simples aquando da utilização desta ferramenta, diminuindo simultane-amente a probabilidade de perda de alguns registos.
Para que se entenda melhor o tipo de produtos que são vendidos na NIBBLE foi criado o seguinte esquema:
Figura 3.1: Fluxo do processo dos testes e montagem
Como apresentado na figura 3.1, a criação de um produto para venda resulta da junção de um ou mais constituintes. Um produto K é composto por dois constituintes: X e Y.
Poderão ser gerados múltiplos produtos K com os mesmos constituintes X e Y. A todos eles quer ao produto final quer aos constituintes, deverão ser atribuídos número de séries diferentes de modo a permitir a fácil identificação e rastreabilidade de todos eles, bem como ter acesso a todos os relatórios de testes pelos quais passaram. Estes registos são importantes caso o produto dê nova entrada na empresa, para reparação ou devolução.
3.2
Modelo AS IS
De modo a estabelecer os primeiros passos a dar na criação desta nova ferramenta e possi-bilitar a introdução de melhorias na mesma, foi necessário conhecer e estudar profundamente os processos e o REPRO.
3.2.1 Mapa de processos
O REPRO, tal como referido anteriormente, permite o suporte a três processos distintos: testes aos constituintes e a montagem final dos produtos; a reparação dos produtos enviados pelos clien-tes; e por último a devolução desses mesmos produtos, quando estes não satisfizeram os objetivos dos clientes (processo que raramente acontece, tendo até pouca relevância, pelo facto da NIBBLE vender a distribuidores).
Foi assim, criado o mapa de processos, ilustrado na figura 3.2, que permitiu perceber quais as fases principais de cada processo bem com o seu principal objetivo.
3.2 Modelo AS IS 17
Figura 3.2: Mapa de processos AS IS
• No primeiro processo, representado na figura 3.2, o objetivo é proceder à realização dos testes, aos ajustes necessário a cada um dos constituintes e, de seguida, completar a monta-gem final do produto, de modo a que este possa ser registado na ferramenta REPRO ou no excel, saindo para o respetivo cliente.
• No segundo processo o objetivo é possibilitar ao cliente a reparação dos produtos comprados (tendo este garantia ou não). Nesta situação pode ser necessário reparar os constituintes do produto ou mesmo proceder à sua substituição.
• No terceiro processo o objetivo é dar a possibilidade ao cliente de devolver os produtos comprados, se houver um motivo válido para o fazer, ficando estes na empresa até outro cliente os solicitar.
3.2.2 Ferramenta atual
De modo a compreender os processos referidos anteriormente, foi necessário estudar o ferra-menta REPRO, apresentando assim o seu funcionamento geral.
Para iniciar a navegação pela mesma é necessário fazer o devido login, tendo acesso a uma janela com a seguinte barra de navegação:
Figura 3.3: Menu de entrada no REPRO
Para iniciar um registo de dados, seja para testes e montagem, seja para reparação, é necessário abrir a janela PRODUTO da barra de navegação representada na figura 3.3. O utilizador terá acesso a todos os produtos inseridos no REPRO.
Após a seleção do produto desejado, um novo menu será mostrado (figura 3.4).
Figura 3.4: Menu principal
De modo a perceber, todas as funcionalidades da ferramenta, bem como todas as possibilidades apresentadas no menu, foi criado uma numeração de 1 a 7, na barra de navegação principal, como apresentado na figura 3.4.
1. PRODUTO: Retorna à página referida anteriormente, que nos permite acesso a todos os produtos inseridos no REPRO.
2. TESTES: É aqui que são registados os resultados dos testes dos constituintes, sendo neces-sário escrever o número de série do mesmo, os erros e comentários, se necesneces-sário. De notar, que apenas um dos constituintes de um produto é aqui registado deste modo.
3. MONTAGEM: Aqui são inseridos os registos das montagens do produto, associando os números de série dos constituintes do mesmo e gerando um só número de série que será o do produto final que sairá para o cliente.
4. REPARAÇÃO: Aqui é possível registar todos os dados relativos às reparações dos produ-tos.
5. SAÍDA: É aqui que são registadas as saídas quer da zona de testes quer da zona de reparação, não sendo possível distinguir de onde provem o produto.
3.2 Modelo AS IS 19
6. ENTRADA: Aqui é onde são gerados os documentos de entrada, estes documentos só são necessários quando os produtos necessita de entrar na empresa para reparação ou devolução. 7. ADMINISTRAÇÃO: Esta parte do menu é também apresentado na figura 3.3, e é o local
onde é possível adicionar novos hardwares e softwares aos vários constituintes.
Nesta zona, o registo fica incompleto pois sempre que são adicionados novos hardwares e softwaresé necessário completar o seu registo diretamente na base de dados.
Nos pontos assinalados com os números 4, 5 e 6 da figura 3.4, poderão ser efetuados registos do produto selecionado, mas é preciso notar que esta ferramenta permite efetuar também registos de outros produtos que não tenham sido selecionados previamente.
3.2.2.1 Registos no REPRO
Em seguida será feita uma análise mais detalhada de cada uma das páginas envolvidas no pro-cesso de testes e montagens (figura 3.2). Para se registarem os testes realizados aos constituintes de um certo produto, proceder à sua montagem final e registar a saída, é necessário aceder aos menus 2, 3 e 5 representados na figura 3.4.
Registo dos testes (menu 2)
Como apresentado figura 3.5, para proceder ao relatório de testes de um dos constituintes do produto, é necessário cumprir os seguintes passos:
• Preenchimento do cabeçalho do relatório, onde se regista o número de série; • Selecionar o modelo desejado e consequentemente o software e hardware;
• Preencher informação sobre o resultado dos testes na listagem gerada aquando da introdução do produto;
• Escrever as observações necessárias (opcional); • Guardar o relatório.
Uma vez submetido o relatório de testes, o sistema está apto para o registo da montagem.
Registo da Montagem (menu 3)
Figura 3.6: Janela de registo da montagem
Na figura 3.6, é possível ver a janela de registo da montagem do produto. Para tal é necessário cumprir os seguintes passos:
• Selecionar o relatório de testes que pretende usar (neste relatório encontra-se o número de série do constituinte);
• É necessário introduzir o número de série do constituinte do produto que teve registo num folha de excel, tal como referido aquando da explicação da barra de navegação (2. TESTES); • Inserir o número de série da montagem, ou seja, o número de série do produto final que será
vendido ao cliente;
• Após terminada a montagem procede-se à respetiva validação.
Após a validação, o produto esta terminado e pronto para sair para o cliente. Sendo então necessário o preenchimento do relatório de saída (figura 3.7).
3.3 Oportunidades de melhoria 21
Registo da saída (menu 5)
Figura 3.7: Janela de saída
Deste relatório constam as seguintes informações:
• Data do documento, número de fatura e número de guia; • Identificação do cliente que irá receber os produtos; • Quais os produtos que vão sair para o cliente; • Observações (opcional).
Uma vez terminada a inserção dos dados o utilizador guarda estes registos, ficando assim, o processo de testes e montagens finalizado.
3.3
Oportunidades de melhoria
Após a análise cuidada da ferramenta REPRO foram detetadas algumas oportunidades de me-lhoria que serviram de base ao desenvolvimento da nova ferramenta.
• A inserção de um novo utilizador da ferramenta, tem que ser feita diretamente através da base de dados;
• Se houver necessidade de inserir dados de um produto na ferramenta, como por exemplo a listagem de erros no relatório de testes, associar hardwares e softwares aos testes, estes tem que ser feitos, também, através da base de dados;
• Como consequência da dificuldade de inserção de dados na ferramenta, existe falta de re-gisto de produtos na mesma, uma vez que se fazem estes rere-gistos em folhas de cálculo partilhadas;
• Nos relatórios de testes ocorre uma falta de registo de erros, devido ao facto de estes deverem ser feitos num documento muito extenso (listagem) e com demasiados passos. Assim, para poupar tempo o trabalhador corrige o erro na hora e não o regista;
• Pelo facto do processo de testes e montagens ser feito em lotes, para otimização de tempo, leva a que os registos sejam efetuados apenas no final, o que pode levar à falha no registo de alguns produtos;
• Atualmente, a comunicação com o cliente, de orçamentos e estados de reparação, é feita através de uma folha de excel partilhada com a empresa, independente da ferramenta RE-PRO;
• A pesquisa por produtos é complexa. Não é intuitiva nem clara a forma como um utilizador faz pesquisas na ferramenta, sendo que algumas delas não são possíveis sem o acesso à base de dados;
• A saída dos produtos é registada no mesmo local, provocando dificuldade na distinção entre documentos que saem da zona de testes e da zona de reparação;
• Quando o utilizador cria um documento de entrada, este nunca necessita de ser finalizado para que os produtos nele inseridos sejam reparados;
• Na zona de reparação, se um dos constituintes necessitar de ser substituído por um novo, esta substituição será registada em comentário;
• O acesso a algumas páginas é demorado, por vezes 30 segundos só para que está seja carre-gada, devido ao tamanho da BD e á falta de otimização dos pedidos à mesma.
Capítulo 4
Solução
Uma vez estudado o modelo AS IS e detetadas algumas possibilidades de melhoria no mesmo, mostrou-se necessário criar os requisitos funcionais e não funcionais e os mockup’s para que fosse possível implementar uma solução. Neste capítulo serão expostas as tecnologias utilizadas para o desenvolvimento desta nova ferramenta, que terá o nome de REPRO+.
4.1
Requisitos
Para o desenvolvimento do REPRO+ foi necessário definir os requisitos funcionais e não fun-cionais do mesmo.
4.1.1 Requisitos funcionais
Os requisitos funcionais são baseados em aspetos técnicos do projeto, ou seja, estão relacio-nados com o funcionamento do sistema, podendo ser cálculos, manipulação de dados e detalhes técnicos.
• A ferramenta deve possibilitar a utilização por mais do que 1 utilizador em simultâneo. Para o trabalhador, administrador ou cliente entrarem na ferramenta, é necessário fazer a devida autenticação;
• A ferramenta deve possibilitar o registo de novos utilizadores.
Deve existir um local na ferramenta onde seja possível inserir novos clientes, trabalhadores e administradores, sem haver necessidade de aceder manualmente à base de dados;
• A ferramenta deve possibilitar adicionar novos produtos bem como os respetivos cons-tituintes.
Deve existir um local na ferramenta onde seja possível inserir novos produtos (nome e sigla) e os devidos constituintes (nome, associar o mesmo ao produto pretendido, a sigla, imagem, e o documento de testes);
• A ferramenta deve possibilitar adicionar novos modelos, hardwares e firmwares aos constituintes que desejar.
A cada constituinte inserido na ferramenta deve ser possível associar vários modelos e a esses modelos associar hardwares e firmwares, sem ser necessário a utilizador deslocar-se à base de dados;
• A ferramenta deve permitir gerar relatórios de testes.
Os trabalhadores e administradores devem poder criar relatórios de testes dos constituintes e inserir nos mesmos o número de série e, se necessário, os erros e comentários;
• A ferramenta deve permitir o registo de montagem de um produto.
Os trabalhadores e administradores devem poder registar na ferramenta as várias montagens criadas, associar às mesmas os números de série dos constituintes anteriormente inseridos na ferramenta, e gerar um único número de série, que será o do produto final;
• A ferramenta deve permitir registar reparações e devoluções.
Deve ser possível ao cliente enviar para a empresa os seus produtos para reparação ou devo-lução (sempre que para tal exista um motivo válido), sendo esta registada;
• Deve ser possível registar relatórios de reparação e de substituição.
Na zona de reparação deve ser possível o registo da reparação ou substituição dos consti-tuintes dos produtos;
• A ferramenta deve permitir o registo de novos produtos na zona de reparação.
Caso o produto que tenha dado entrada na reparação nunca tenha sido registado anterior-mente na ferramenta, por ter sido criado antes do desenvolvimento da ferramenta, o seu registo deve ser possível nesse momento, através dos seus respetivos números de série; • A ferramenta deve permitir dar entrada e saída dos produtos.
Uma vez efetuada a montagem do produto o utilizador deve ter possibilidade de dar saída do mesmo para o cliente. Este produto poderá dar entrada e saída posteriormente na ferramenta através do cliente, para reparação;
• Deve ser possível os utilizadores terem acesso a registos anteriores.
Na navegação pela ferramenta deve ser possível ter acesso a toda a informação nela contida relativamente a registos anteriormente efetuados;
• Deve ser possível o utilizador pesquisar certos campos da base de dados na própria ferramenta.
Os trabalhadores e administradores devem ter possibilidade de pesquisar os produtos ven-didos, através do seu numero de série, e terem acesso a toda a informação do histórico dos mesmos.
4.2 Modelo TO BE 25
Deve permitir ainda a consulta de documentos finalizados e não finalizados das zonas de entrada e saída, através do nome do cliente, ou da data de criação do documento;
• Possibilidade de comunicação com o cliente através da ferramenta.
Deve ser possível a existência de comunicação com o cliente através da ferramenta. Esta deve permitir a introdução do número de série do produto para reparação e deve possibilitar a avaliação do respetivo orçamento caso o produto não tenha garantia.
4.1.2 Requisitos não funcionais
Os requisitos não funcionais são todos aqueles relacionados com o uso da aplicação, ou seja, aqueles que estejam mais dirigidos ao utilizador e ao exterior (qualidade, suporte, interface utili-zador/sistema e até ambientais).
• A ferramenta deve ser intuitiva e simples.
A ferramenta deve ser fácil de aprender e intuitiva quando manuseada; • A ferramenta deve ser desenvolvida em tecnologias web.
É cada vez mais frequente a utilização da tecnologias web, devendo estas ser utilizadas na criação desta ferramenta;
• A ferramenta deve ter segurança.
Esta ferramenta deve ser criada com qualidade, não podendo o cliente ter acesso às zonas dos trabalhadores e administradores (zona de testes, reparação e administração);
• O tempo de resposta das páginas deve ser reduzido.
Quando os utilizadores desejarem mudar de página esta deve ser executada de forma rápida (menos de 8 segundos);
• A inserção de dados deve ser rápido e eficaz.
O tempo de inserção de dados na ferramenta, quer seja de utilizadores, produtos, constituin-tes, modelos, hardwares e firmwares, deve ser de aproximadamente 5 minutos;
• A ferramenta não deve alterar substancialmente os processos atuais.
Ao desenvolver a ferramenta e alterando alguns processos existentes, estes devem ser seme-lhante aos atuais, de modo a não gerar muita alterações na empresa.
4.2
Modelo TO BE
Depois de estudar o modelo AS IS foi possível estruturar o modelo TO BE focando-nos no que seria importante alterar para resolver os problemas e para cumprir todos os requisitos apresentados.
4.2.1 Mapa de processos
Tal como no modelo AS IS, o mapa de processos do modelo TO BE tem três processos distintos: testes e montagens, reparação e devolução.
De acordo com o apresentado figura 4.1, as fases principais dos processos de reparação e de-volução mantiveram-se iguais, enquanto as do processo de testes e montagem foram ligeiramente alteradas.
No modelo TO BE, o registo na ferramenta, passou a ser obrigatório, quer na fase de testes quer na fase de montagem e não apenas após terem ocorrido essas duas fases como anteriormente acontecia. Assim, este processo obriga, a que haja uma sequência lógica no processo geral.
Contudo, o modo de funcionamento dos três processos sofreu algumas modificações, como se poderá constatar ao longo da dissertação.
4.2 Modelo TO BE 27
4.2.2 Mockup
Após a criação dos novos processos foi importante desenvolver os mockups da aplicação de modo a ter uma visão global da nova ferramenta e, ao mesmo tempo garantir que esta cumpre todos os requisitos.
Foram assim desenhadas 62 janelas que representariam o futuro da ferramenta. Estas janelas são dinâmicas, permitindo ao utilizador ter uma perspetiva de como funcionará a ferramenta.
Para se iniciar a navegação, existe três tipos de autenticação possíveis: a do cliente, a do ad-ministrador e a do trabalhador.
Os mockups a seguir apresentados serão referentes a autenticação de um administrador, uma vez que é esta que tem mais permissões.
Depois da autenticação do administrador, com o respetivo username e password, este terá acesso à zona de testes e montagens, à zona de reparação e à zona administrativa.
Zona administrativa
Na zona administrativa será possível aceder a várias opções:
• Adicionar novos utilizadores (administradores, trabalhadores ou clientes); • Adicionar novo produto;
• Adicionar novos constituintes ao produto criado; • Adicionar novos modelos ao constituinte; • Adicionar hardwares a um certo modelo; • Adicionar firmwares a um certo modelo.
Figura 4.2: Mockup da zona administrativa
Após a autenticação efetuada, e com todos os dados dos produtos criados, o administrador ou o trabalhador pode efetuar qualquer um dos registos referidos anteriormente (testes, montagem e reparação).
Zona de testes e montagens
Na zona de testes e montagens o utilizador poderá optar por duas alternativas: efetuar os testes aos constituintes ou montar um novo produto.
Os passos necessários para realizar cada um dos procedimentos, são apresentados de seguida: • Para iniciar o registo do relatório de teste necessita selecionar um produto e de seguida o
constituinte que deseja testar;
• Para um utilizador fazer um registo de montagem necessita selecionar o produto que deseja construir, não necessitando de escolher qualquer constituinte.
A janela apresentada na figura 4.3, é onde será escolhido o produto, seja este para testes ou montagem:
4.2 Modelo TO BE 29
Figura 4.3: Mockup da janela de seleção do produto
Como referido anteriormente, se o utilizador pretender realizar os relatórios de testes necessita selecionar um dos constituintes desse mesmo produto, como é possível ver na figura 4.4.
Figura 4.4: Mockup da janela da seleção do constituinte referentes ao produto final selecionado na figura 4.3
Depois do constituinte escolhido, cria-se assim o relatório de testes. A estrutura desse relatório pode ser vista na figura 4.5.
Figura 4.5: Mockup do relatório de testes
Porém, se o utilizador desejar criar a montagem do produto, não necessita de executar o passo da figura 4.4, bastando selecionar o produto final, como é ilustrado na figura 4.3 e escolher o menu montagem, tendo acesso à janela apresentada na figura 4.6.
Figura 4.6: Mockup da zona de montagem
Após a criação dos relatórios de testes e montagens, os produtos encontram-se prontos para dar saída para o cliente. Para isso, deve ser gerado na ferramenta, um relatório de saída que será ilustrado na figura 4.7.
4.2 Modelo TO BE 31
Figura 4.7: Janela referente ao relatório de saída dos produtos para um certo cliente
Zona de Reparação
Os relatórios de entrada e saída dos produtos para o respetivo cliente funcionam de um modo semelhante á figura 4.7, não sendo assim, necessário apresentar as suas janelas de visualização.
A reparação dos produtos encontra-se representado na figura 4.8.
Nesta página, será possível:
• adicionar o produto com os respetivos números de série (quer dos constituintes quer do produto em si), caso este nunca tenha dado saída na ferramenta anteriormente;
• criar relatórios de avaliação caso o produto já não se encontre dentro da garantia e; • criar o registo de reparação dos produtos em questão.
4.2.3 Tecnologias web a utilizar
Como anteriormente mencionado no capítulo 1, esta dissertação tem como objetivo criar uma ferramenta auxiliar à produção da empresa NIBBLE. Uma vez estudados os objetivos, problemas, requisitos e a ferramenta atual (REPRO), foi necessário analisar quais as tecnologias a utilizar para a criação da ferramenta web (REPRO+), de modo a que esta esteja alinhada com todos os requisitos estipulados.
A maioria dos websites já não se limitam a ser desenvolvidos recorrendo ao uso da combinação das linguagens HTML e CSS, ou seja, para além das linguagem já habitualmente utilizadas neste género de ferramentas existem muitas frameworks disponíveis no mercado. Devido a esta grande diversidade, torna-se difícil a escolha relativamente à qual será a mais adequada a utilizar para a aplicação que se pretende desenvolver.
Cada página web é uma junção de diferentes linguagens, estando estas ligadas a qualidade e usabilidade que o utilizador conseguirá tirar delas. Por exemplo, se juntarmos HTML, CSS e Javascript é possível criar uma página web funcional e com qualidade não sendo necessário recorrer a uma framework. O uso desta última linguagem, irá permitir um maior dinamismo da página. [15]
Dentro da linguagem PHP existem frameworks que têm mais destaque, como por exemplo o Laravele o Symfony2, como referido no capítulo 2. Para além de todos estes estudos, previa-mente referidos no capítulo 2, é também importante ter um conhecimento geral das tecnologias de desenvolvimento de bases de dados. A linguagem SQL (Structured Query Language) é uma linguagem de pesquisa de base de dados que é utilizada em vários sistemas de gestão de bases de dados nomeadamente o MySQL e o PostgreSQL.
Assim, para a construção desta ferramenta, é necessário ter conhecimentos relativamente a HTML, CSS e Javascript, as frameworks Bootstrap e Laravel e SQL.
HTML, CSS e Javascript
• O HTML significa Hyper Text Markup Language e é uma linguagem standard para o desen-volvimento de aplicações web. É através desta linguagem que é possível apresentar texto, tabelas, listas, entre outros elementos numa página web.
4.2 Modelo TO BE 33
• O CSS significa Cascading Style Sheets e funciona em conjunto com o HTML. Quando olhamos para uma página de um website, o browser está a receber informação tanto de HTMLcomo de CSS, sendo que o HTML se foca mais na estrutura e no conteúdo da página e o CSS se foca mais no estilo da página.
• Alguns websites também enviam Javascript para o browser, sendo o javascript uma lingua-gem de programação baseada em scripts em que é utilizada maioritariamente para tornar as páginas web mais interativas. Esta linguagem é contida nos documentos HTML, apesar de ser colocada num ficheiro externo uma vez que pode ser reutilizada em varias páginas distintas. [16]
Bootstrap e Laravel
Uma vez apresentadas estas três linguagens, é possível analisarmos algumas frameworks que serão utilizadas na ferramenta, tal como por exemplo o Bootstrap, que é maioritariamente uma frameworkde CSS e o Laravel, que é uma framework de PHP.
• O Bootstrap é uma ferramenta dedicada ao design das aplicações. Este contém três pastas: css, fontse js que para serem utilizadas se devem incluir no ficheiro HTML. O bootstrap faz com que seja possível criar aplicações simples, de forma mais rápida e de fácil usabilidade. Existem também já templates de partes de aplicações feitas que poderão ser adicionadas nos ficheiros caso estas não se encontrem presentes. Optou-se assim por utilizar esta tecnologia pela sua facilidade de utilização e pela quantidade de templates que esta dispõe de partida, fazendo com que haja uma mais fácil otimização em termos de tempo, sendo que não será necessária a preocupação com as configurações do design da ferramenta. [17]
• O Laravel é uma framework de PHP. Hoje em dia existem muitas no mercado, como foi estudado no capítulo 2, contudo, esta foi a escolhida para o desenvolvimento da ferramenta em questão. É uma framework que conta com muitos apoios relativamente a locais de aprendizagem, o que facilita o entendimento da mesma. É também uma framework que se encontra num acentuado crescimento relativamente à sua utilização, mais do que qualquer outra no mercado. Tal, pode trazer benefícios à empresa sendo que, quando esta atualiza para uma nova versão, é permitida a utilização de todos os dados anteriormente arquivados, não necessitando de alterar nenhuma parte do código.
Apesar desta escolha, não é retirado qualquer valor à framework Symfony2, sendo esta uma ferramenta equiparável ao Laravel. Relativamente a framework CodeIgniter, visto ser uma fra-meworkque com o passar do tempo tem cada vez menos atualizações, pode significar que, num futuro próximo, não ajudará a empresa a melhorar as funcionalidades da ferramenta, sendo até um ponto fraco para o seu posterior desenvolvimento e adaptação. A mudança de framework não é algo arriscado de se fazer, uma vez que maior parte delas utiliza o modelo MVC.
Capítulo 5
Protótipo
Após a análise da ferramenta atual REPRO e de ter uma solução delineada, criou-se uma nova versão da ferramenta à qual se chamou REPRO+. Esta terá o mesmo fim, sendo no entanto mais intuitiva e fácil de utilizar. Dadas estas características, bem como a sua usabilidade, um maior número de registos e uma maior comunicação entre todos os utilizadores poderá ser feito. Este capítulo será referente à fase da implementação da mesma, conhecendo a sua estrutura e as respetivas janelas de utilização.
A interface do REPRO+ foi desenvolvida na linguagem PHP, sendo esta uma linguagem de programação utilizada na comunicação entre cliente e o servidor, que utiliza o sistema de gestão de bases de dados MySQL. Nesta dissertação foram também utilizadas as linguagens de HTML, CSSe Javascript juntamente com as frameworks Bootstrap e Laravel.
5.1
Estrutura e dados da ferramenta
De forma a que se perceba a estrutura base do funcionamento da ferramenta produzida, foram desenvolvidos vários esquemas para que seja possível seguir visualmente todos os passos que um utilizador percorre enquanto utiliza a mesma. Para além disso, foi também desenvolvido um modelo da base de dados expondo assim o número total de tabelas e o que cada uma destas contém, permitindo também visualizar o seu modelo relacional.
5.1.1 Estrutura
Na figura 5.1, é apresentado o esquema do menu de navegação a que um trabalhador, adminis-trador ou cliente pode ter acesso após a autenticação, sendo que, posteriormente, cada uma destas zonas será apresentada com maior detalhe.
Figura 5.1: Estrutura do menu principal da ferramenta com as diferentes autenticações
O trabalhador ou administrador, como ilustrado na figura 5.1, terão acesso à zona de testes, à zona de reparação e à de administração.
É de notar que as setas contínuas representam nos esquemas seguintes um caminho dito obri-gatório, sendo necessário passar por todas as etapas de um determinado caminho quando este é o escolhido. As linhas descontinuas, por outro lado, representam um caminho que o utilizador pode optar por fazer (caminho opcional).
Zona de testes
O esquema relativo a esta zona está ilustrado na figura 5.2 e apresenta quais os possíveis caminhos pelos quais estes utilizadores poderão optar por percorrer.
5.1 Estrutura e dados da ferramenta 37
Zona de reparação
Ainda dentro do mesmo modo de autenticação, poder-se-á ter acesso à zona de reparação onde, como se pode ver na figura 5.3, estão disponíveis as seguintes funcionalidades:
Zona de administração
O acesso ao menu da zona de administração está, de momento, aberto a dois tipos de auten-ticação, trabalhador e administrador. Após a seleção de entrada nesta zona, os utilizadores são reencaminhados para uma nova janela com um layout distinto do anterior, onde se tem acesso a um novo menu lateral. Na figura 5.4, estão disponíveis as funcionalidades desta zona.
5.1 Estrutura e dados da ferramenta 39
Zona do cliente
O menu, quando a autenticação é feita pelo cliente, é distinto, no entando, este terá acesso ás seguintes funcionalidades (figura 5.5):
Figura 5.5: Estrutura referente à autenticação do Cliente
5.1.2 Base de dados
Após feita a exposição da estrutura da nova ferramenta, é importante conhecer a sua base de dados. A base de dados funciona como background à ferramenta e é através dela que são apresentados todos os dados necessários para que a ferramenta funcione como desejado.
Serão de seguida apresentadas as 21 tabelas utilizadas para desenvolver a ferramenta, apresentando-as com o respetivo conteúdo. São também expostapresentando-as apresentando-as relações existentes entre apresentando-as váriapresentando-as tabelapresentando-as. Todas as tabelas têm uma chave primária com a sigla PK sendo que esta é uma variável única e não nula que identifica cada registo inserido na base de dados. A maior parte das tabelas têm também associadas chaves estrangeiras com a sigla FK, o que faz com que esse campo consiga fazer uma conexão com outra tabela distinta pelo id (PK).
As primeiras duas tabelas apresentadas são relativas aos clientes, com o nome: customers e a tabela dos utilizadores com o nome: users.
Figura 5.6: Tabelas da base referentes aos clientes e aos restantes utilizadores
Para se perceber melhor o modelo da base de dados das restantes 19 tabelas foi feita uma divisão, apresentando as tabelas restantes em três figuras diferentes.
A figura 5.7 terá 5 tabelas, as quais serão preenchidas através da zona de administração da ferramenta.
Figura 5.7: Modelo da base de dados referentes às tabelas dos produtos, constituintes, modelos, hardwarese firmwares
Nestas são adicionados: • categories - novos produto; • products - novos constituintes;
• modelprods - os modelos dos vários constituintes;
5.1 Estrutura e dados da ferramenta 41
• firmwares - os novos firmwares aos modelos dos constituintes;
Na figura 5.8são representadas 5 tabelas que serão preenchidas maioritariamente na zona de testes:
Figura 5.8: Modelo da base de dados das tabelas que serão preenchidas maioritariamente na zona de teste
Nestas serão:
• documenttests - registados todos os documentos de teste feitos aos vários constituintes; • testerrors - registados todos os erros existentes em todos os constituintes que se encontram
inseridos na base de dados;
• assemblies - feitos os registos das montagens dos produtos e onde são feitas as associações dos números de série;
• documentexists - registados todos os documentos de saída da zona de teste;
• assemblyindocumentexits - é a tabela que faz a junção das 2 tabelas anteriores através dos seus id (PK);
Por último, na figura 5.9temos as restantes 9 tabelas que serão preenchidas na zona de repa-ração e na zona do cliente da ferramenta.
Figura 5.9: Modelo da base de dados das tabelas que serão preenchidas na zona de reparação e cliente
Nestas serão:
• customerentries - registados os pedidos de reparações dos produtos, podendo alguma desta informação ser alterada posteriormente nos documentos de entrada;
• documententries - registados todos os documentos de entrada;
• customerentryindocumententries - é a tabela que faz a junção das 2 tabelas anteriores atra-vés dos seus id (PK);
• evaluationreports - inseridos os dados dos orçamentos, caso o produto em questão não tenha garantia;
• evaluationreportincustomerentries - é a tabela que faz a junção da tabela anterior com a dos customerentries através dos seus id (PK);
5.1 Estrutura e dados da ferramenta 43
• documentreports - registados os dados dos relatórios, quer de substituição quer de repara-ção;
• customerentryindocumentreports - é a tabela que faz a junção da tabela anterior com a dos customerentriesatravés dos seus id(PK);
• documentrepairexits - registados todos os documentos de saída da zona de reparação; • customerentriesindocumentexits - é a tabela que faz a junção da tabela anterior com a dos
customerentriesatravés dos seus id (PK);
Uma vez já exposto o modelo da base de dados, apresentam-se agora as relações entre as ta-belas, fazendo com que se perceba toda a lógica por trás da atividade que existe na ferramenta.
Na figura 5.10, são apresentadas as relações que as tabelas categories, products, modelprods, hardwarese firmwares têm entre si.
Como já foi discutido, um produto pode ter vários constituintes e um constituinte pode ter vários modelos. Cada modelo pode ainda ter vários firmwares e hardwares. Estas relações fazem com que haja uma sequência lógica entre estas cinco tabelas, como será possível constatar na figura 5.10.
Figura 5.10: Relação entre as tabelas da base de dados da Zona de Administração
De seguida, será apresentado o modelo relacional da zona de testes, estando ilustradas na fi-gura 5.11, todas as tabelas que interagem nesta zona e as suas relações.
Figura 5.11: Relação entre as tabelas da Base de Dados da Zona de Testes
Finalmente, na figura 5.12, apresenta-se o modelo relacional da zona de reparação e da zona do cliente.
5.2 Ferramenta desenvolvida 45
5.2
Ferramenta desenvolvida
Com base em tudo o que foi referido, foi possível produzir a ferramenta REPRO+. São apre-sentadas de seguida, algumas das páginas criadas, de forma a que seja possível entender as funci-onalidades que cada uma possui usando um suporte visual.
5.2.1 Autenticação
Como referido anteriormente, de modo a ter permissão para se manusear a ferramenta RE-PRO+, quer o utilizador seja trabalhador, administrador ou mesmo cliente, têm que fazer login. Na figura 5.13encontra-se ilustrada a interface da autenticação para o administrador ou trabalha-dor, sendo a interface de autenticação do cliente idêntica a nível de funcionalidade. No entanto, o URLtal como alguns aspetos textuais são diferentes.
Figura 5.13: Janela de autenticação dos trabalhadores e administradores
5.2.2 Menu
Fazendo a devida autenticação poder-se-á ter acesso a dois menus distintos. O menu para administradores ou trabalhadores encontra-se apresentado na figura 5.14 com o número 1 e o menu para a autenticação como clientes será o número 2 da mesma figura.
Figura 5.14: Menus principais da ferramenta | 1-Menu da autenticação do administrador ou traba-lhador 2-Menu da autenticação do cliente
