Sistema de Gestão para Oficinas de Eletrónica

Transcrição

1 UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO Escola de Ciências e Tecnologia Departamento de Engenharias Sistema de Gestão para Oficinas de Eletrónica Dissertação de Mestrado em Tecnologias da Informação e Comunicação APRESENTADA POR: JOSÉ MANUEL MOREIRA VIEIRA GOMES Sob orientação dos Professores Doutores Vítor Filipe e Luís Babosa Vila Real, Outubro de 2013

2

3 UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO Escola de Ciências e Tecnologia Departamento de Engenharias Sistema de Gestão para Oficinas de Eletrónica Dissertação de Mestrado em Tecnologias da Informação e Comunicação APRESENTADA POR: JOSÉ MANUEL MOREIRA VIEIRA GOMES Sob orientação dos Professores Doutores Vítor Filipe e Luís Babosa Composição do Júri: Vila Real, 2013

4

5 Dissertação de Mestrado, submetida à Universidade de Trás-os-Montes e Alto Douro, para cumprimento dos requisitos necessários para a obtenção do grau de Mestre em Tecnologias de Informação e Comunicação.

6

7 Não existem métodos fáceis para resolver problemas difíceis René Descartes

8

9 Agradecimentos A presente dissertação é testemunho de como o esforço, colaboração e trabalho conjunto resultam na concretização de objetivos e satisfação de todos os intervenientes, a união faz a força. Estarei eternamente grato pela disponibilidade, dedicação, experiência e conhecimentos transmitidos pelo Professor Doutor Vítor Filipe e Professor Doutor Luís Filipe Barbosa ao longo deste árduo caminho, exemplarmente transcenderam os seus papéis como orientadores, em muito lhes devo o sucesso deste projeto. Quero também agradecer ao Professor Doutor Ramiro Gonçalves pela enorme criatividade, dinâmica e colaboração prestadas. Ao Sr. Emanuel pela iniciativa na realização deste projeto, constante disponibilidade, encorajamento e motivação prestados. A toda à Escola de Ciências e Tecnologia pelas instalações concedidas. Aos meus familiares e amigos por todo o apoio e ajuda. Um agradecimento muito especial aos meus pais pelo esforço enorme que sempre fizeram para me dar acesso a esta experiência, educação e conhecimento. I

10 II

11 Resumo Palavras Chave: Sistema de Gestão; Oficinas de Eletrónica; Desenvolvimento de Software; Tecnologias da Informação na Educação A otimização de recursos é cada vez mais uma obrigação que todas as instituições enfrentam. Mas com que recursos ou meios se chega a esse fim? Com que métodos? Quais os desafios associados? A utilização de sistemas de informação é sem dúvida uma forma eficiente para se chegar a esse fim, com o registo e acesso à informação de forma mais acessível estes meios tecnológicos permitem alcançar resultados que até então seriam difíceis. Este projeto descreve o estudo e análise na resolução do problema de gestão existente nas Oficinas de Eletrónica do Departamento de Engenharias da Universidade de Trás-os-Montes e Alto Douro. É apresentada e desenvolvida uma proposta aplicacional, desde a análise até à implementação de um software que se apresenta como uma solução à gestão das Oficinas. Abordou-se o estudo seguindo uma metodologia de desenvolvimento intrínseca ao problema em questão e a todas as características associadas aos sistemas de gestão, com vista a obter uma solução à medida, por meio de Tecnologias de Informação capazes de apoiar os utilizadores na gestão de todos os serviços e recursos das Oficinas de forma integrada com os restantes sistemas de informação já existentes na instituição de ensino. Apresentam-se os resultados dos testes realizados para a validação da proposta aplicacional em contexto real, sendo comparadas a prestação dos serviços das Oficinas antes e após a implementação do sistema de gestão desenvolvido. III

12 IV

13 Abstract Keywords: Management System; Electronic Store; Software Development; Information Technologies in Education Resource optimization has become an obligation that all institutions are facing. But with which resources or ways they will achieved it? With which methods? What are the associated challenges? The use of Information Systems is undoubtedly an efficient way to to reach this purpose, with the registration and access of information in a more accessible way, this technological resources allow results that would be difficult to achieve in other ways. This project describes the study and analysis towards the resolution of the problem founded at the Electronic Workshop in the Department of Engineering from the University of Trás-os-Montes e Alto Douro. It is presented and developed a applicational proposal from the analysis to the implementation of a software that presents itself as a solution to the management problem of the Workshop. The followed approach was a restrict methodology associated to the problem in hands and all the technical features associated to the management systems, with the goal to get a fully designed and personalized software through Information Technologies which can support users in the management of all services and resources at the Workshop and completely integrated with other Information Systems existing in the institution. It s presented the results of tests performed to validate the proposed application in real context being compared the services of the Workshop before and after the implementation of the developed management system. V

14 . VI

15 Índice Geral AGRADECIMENTOS... I RESUMO... III ABSTRACT... V ÍNDICE GERAL... VII ÍNDICE DE FIGURAS... XI ÍNDICE DE TABELAS... XV GLOSSÁRIO, ACRÓNIMOS E ABREVIATURAS... XVII 1. INTRODUÇÃO Contexto das Oficinas de Eletrónica da UTAD Objetivos Organização do Documento REVISÃO BIBLIOGRÁFICA Dos Sistemas de Informação à Gestão Soluções comerciais de gestão Primavera Express (free-license) Primavera Executive (paid-license) SAP (paid-license) Openbravo (opensource paid-license) Conclusões do Levantamento Enquadramento Tecnológico Sistemas Operativos Linguagens Hardware Interface do Utilizador Conclusão VII

16 3. ESPECIFICAÇÃO DO SISTEMA Método de Desenvolvimento Análise de Requisitos Requisitos Funcionais Requisitos Não Funcionais Modelação de Dados Módulo de Utilizadores Módulo de Grupos de Trabalho Módulo Académico Módulo de Artigos Módulo de Documentos Modelação Funcional Módulo de Funcionalidades Publicas Módulo de Gestão de Utilizadores Módulo de Área Pessoal Módulo de Gestão Académica Módulo de Gestão de Artigos Módulo de Gestão de Categorias de Artigos Módulo de Gestão de Famílias de Artigos Módulo de Gestão de Unidades de Medida de Artigos Módulo de Gestão de Locais de Armazenamento Módulo de Gestão de Preços Módulo de Gestão de Compras Módulo de Gestão de Requisições Módulo de Gestão de Reparações Módulo de Apoio à Gestão Conclusão IMPLEMENTAÇÃO DO SISTEMA Mecanismos de Comunicação Arquitetura do SGOE Segurança Tecnologias Utilizadas NET ASP.NET MVC C# Javascript Jquery ASP MS-SQL AJAX VIII

17 JSON LINQ CSS Pagination Dynamic-Menu Action-Filter Doodle Report Integração do Sistema Instalação Inserção de Dados Instalação da Aplicação e Base de Dados Configuração das Zonas de Trabalho Funcionamento do Sistema Módulo de Gestão de Artigos Módulo de Gestão Académica Módulo de Gestão de Requisições Módulo de Gestão de Reparações Módulo de Gestão de Utilizadores Módulo de Gestão de Área Pessoal Módulo de Apoio à Gestão Módulo de Gestão de Compras TESTES E RESULTADOS Caraterização da Amostra e Recolha de Dados Avaliação do Sistema Em Papel Avaliação do SGOE Satisfação na Pesquisa de Artigos Satisfação No Acesso à Conta Corrente Satisfação Na Requisição de Artigos Satisfação Na Utilização dos Menus Satisfação Na Compreensão de Dados Satisfação na Rapidez a Carregar as Páginas Satisfação na Utilização do Aplicação no Âmbito Geral Resposta Emocional Obtida Pelos Utilizadores Avaliação do Design da Aplicação Escolha da Preferência de Sistema Conclusão CONCLUSÕES E DESENVOLVIMENTOS FUTUROS BIBLIOGRAFIA ANEXOS IX

18 Anexo 1- Diagrama de Casos de Uso, Módulos e Acesso Anexo 2 - Diagrama de Sequência, Registo de Requisição Anexo 3 - Diagrama de Sequência, Levantamento de Requisição Anexo 4 - Diagrama de Sequência, Pedido de Reparação Anexo 5 - Diagrama de Sequência Processo de Reparação Anexo 6 Questionário de Testes X

19 Índice de Figuras Figura 1 - Duas Formas Possíveis de Fornecimento, (Carravilla, 1997)... 2 Figura 2 Estrutura Hierárquica de Uma Empresa (Reynolds & Stair, 2010)... 8 Figura 3 - Funcionamento do Sistema Operativo e Respetivo Browser Figura 4 Arquitetura de Aplicações Web Figura 5 - Modelo de Desenvolvimento em Espiral (Boehm, 1988) Figura 6 - DER Módulo Utilizadores Figura 7 - Módulo Grupos de Trabalho Figura 8 - Módulo Académico Figura 9 - Modulo de Artigos Figura 10 - Módulo de Documentos Figura 11 - Módulo de Funcionalidades Públicas Figura 12 - Módulo de Gestão de Utilizadores Figura 13 - Módulo de Área Pessoal Figura 14 - Módulo de Gestão Académica Figura 15 - Módulo de Gestão de Artigos Figura 16 - Módulo de Gestão de Categorias de Artigos Figura 17 - Módulo de Gestão de Famílias de Artigos Figura 18 - Módulo de Gestão de Unidades de Medida de Artigos Figura 19 - Módulo de Gestão de Locais de Armazenamento Figura 20 - Módulo de Gestão de Preços Figura 21 - Módulo de Gestão de Compras Figura 22 - Módulo de Gestão de Requisições XI

20 Figura 23 - Módulo de Gestão de Reparações Figura 24 - Módulo de Apoio à Gestão Figura 25 - Aplicações 2Tier Figura 26 - Aplicações 3Tier Figura 27 - Arquitetura do SGOE Integrado com o Serviço LDAP Figura 28 - Replicação de Dados Figura 29 - Armários de Armazenamento de Componentes Figura 30 - Balcões de atendimento das Oficinas Figura 31 - Listagem e Criação de Artigos Figura 32 - Código de Barras Figura 33 Registar Artigo Figura 34 Detalhes Artigo Figura 35 Registar Curso Figura 36 Registar Cadeira Figura 37 Registar Projeto Figura 38 - Registo de Requisição Figura 39 - Devolução de Artigos Figura 40 - Registo de Pedido de Reparação Figura 41 Lista de Pedidos de Reparação Figura 42 Calendário de Reparações Figura 43 - Edição de Utilizador Figura 44 - Registo de Grupo de Trabalho Figura 45 Conta Corrente Figura 46 - Relatório Excel Figura 47 - Notificação de Devedores via Figura 48 - Registo de Compra Figura 49 Eficiência no Registo de Operações nas Oficinas Figura 50 Satisfação na Pesquisa de Artigos no SGOE Figura 51 Satisfação no Acesso à Conta Corrente Figura 52 Satisfação na Requisição de Artigos Figura 53 Satisfação na Utilização dos Menus Figura 54 Satisfação na Compreensão de Textos, Dados e Informações Figura 55 Satisfação na Rapidez a Carregar as Páginas XII

21 Figura 56 Satisfação na Utilização da Aplicação de Um Modo Geral Figura 57 Resposta Emocional na Utilização do Sistema Figura 58 Avaliação do Design da Aplicação Figura 59 Sistema Preferido Após Testes e Formações XIII

22 XIV

23 Índice de Tabelas Tabela 1 Comparativo de Softwares de Gestão 14 Tabela 2 Eficiência na Prestação dos Serviços pelo Método Manual 76 XV

24

25 Glossário, Acrónimos e Abreviaturas ASP - Active Server Pages API - Application Programming Interface CRM - Customer Relationship Management CLR - Common Language Runtime CSS - Cascading Style Sheets CSV - Comma-Separated Values DER - Diagrama de Entidade e Relacionamento TI - Tecnologias de Informação ERP - Enterprise Resource Planning FAQ - Frequently Asked Questions GUI - Graphical User Interface HTML - HyperText Markup Language HTTP - Hypertext Transfer Protocol JVM - Java Virtual Machine JSON - JavaScript Object Notation LDAP - Lightweight Directory Access Protocol LINQ - Language-Integrated Query MVC - Model View Controller MS IIS Microsoft Internet Information Services POS - Point of Sale PDF - Adobe Portable Document Format PHP - Hypertext Preprocessor SAFT PT - Standard Audit File for Tax Purposes Versão Portuguesa SO - Sistema Operativo XVII

26 SGOE Sistema de Gestão para Oficinas de Eletrónica SIDE Sistema de Informação de Apoio ao Ensino SQL - Structured Query Language TCP/IP - Transmission Control Protocol/Internet Protocol TLS - Transport Layer Security URL - Uniform Resource Locator VB - Visual Basic VBScript - Microsoft Visual Basic Scripting Edition XML - extensible Markup Language XSLT - extensible Stylesheet Language for Transformation XVIII

27 1. Introdução As organizações representam a congregação de esforços individuais na realização de objetivos comuns. Pode-se considerar que o motor económico de qualquer sociedade são as atividades empresariais em que as empresas transformam os recursos humanos, monetários, matérias-primas ou capitais em bens ou serviços para a sociedade. O aparecimento das instituições deve-se a diversos fatores, tais como os de natureza social ou material. Estas têm como objetivo produzir riqueza, ir ao encontro das necessidades da sociedade e em paralelo assegurar a sua autossustentabilidade. Cada vez mais as organizações enfrentam desafios de operabilidade. Nunca até aos dias de hoje, com a crescente conjuntura, se deu tanta importância à otimização de recursos. Na atualidade exige-se uma maior eficiência das instituições face às grandes necessidades e desafios que a sociedade demanda. A gestão das organizações passa a ser cada vez mais um processo fulcral ao sucesso e sobrevivência das instituições e sustentabilidade da sociedade. Gestão é o processo organizacional que inclui planeamento estratégico, estabelecimento de objetivos, gestão de recursos, implementação de recursos humanos e financeiros necessários para atingir os objetivos e avaliação de resultados. Gestão também inclui gravar e guardar factos e informação para mais tarde usar ou para terceiros dentro da organização. As funções de gestão não estão limitadas aos gestores ou supervisores. Cada membro da organização tem funções de reportar e gerir como parte do seu trabalho (Stuhlman, 2012). Os princípios da gestão são universais, aplicam-se a todos os tipos de empresas e níveis organizacionais. Ao nível da gestão, os sistemas de informação assumem cada vez mais um papel fulcral, assumindo-se como um recurso importante no ato de gestão, permitindo o registo e leitura de factos, informação e quantificação de resultados. No paradigma atual são raras as instituições que não fazem uso de sistemas de informação para melhorar o seu 1

28 desempenho, desde a aplicação de simples sistemas de faturação até aos sistemas de gestão altamente complexos. No âmbito dos sistemas de gestão, «Gestão» é o ato de gerir, governar ou administrar algo. Já a palavra «sistema» refere-se ao método ou procedimento usado para efetuar o ato de gestão (Gouveia & Ranito, 2007). Segundo (Sampaio, 2011), um sistema de gestão pode ser definido como um conjunto de processos organizacionais interligados que fazem uso de diferentes recursos para alcançar os objetivos especificados pela organização. Assim sendo os Sistemas de Gestão relacionam-se com o planeamento, realizando, controlando e melhorando várias atividades numa organização por si só e em relação às partes interessadas, relativamente à performance da empresa a curto e longo prazo. Estes estabelecem a necessidade de sistematizar e formalizar um conjunto de processos organizacionais num conjunto de procedimentos que estão relacionados com diferentes áreas de gestão do negócio. Um bom sistema de gestão garante um melhor controlo de stocks, reduz os erros, otimiza os processos e a utilização dos meios. Os stocks influenciam o custo dos materiais e assim alteram o custo final do produto. Estes representam 20-50% do ativo de uma empresa e rondam 90% do capital circulante. Como tal, o objetivo máximo na sua gestão é o stock zero. Só com uma boa reorganização de processos e gestão da informação útil é Figura 1 - Duas Formas Possíveis de Fornecimento, (Carravilla, 1997) possível atingir tal objetivo. Neste contexto os Sistemas de Gestão representam um papel vital (Carravilla, 1997). Contudo, alerta-se a ter em consideração diversas variáveis tais como possível inflação no custo do produto a médio ou curto prazo, descontos de quantidade e tempo útil 2

29 necessário para o seu fornecimento. Como é possível verificar na Figura 1, o fornecimento pode ser instantâneo e dividido em diversas fazes consoante as necessidades, ou moroso, obrigando a um maior aprovisionamento, previsão de necessidades e gestão de custos. Quando existe um aprovisionamento de stocks devemos ter igualmente em conta fatores como o custo de aprovisionamento ao nível do espaço, bloqueio de capital relativamente ao valor investido e dificuldades de controlo nas entradas e saídas. Uma questão seriamente importante é o meio como se gere. Deve-se optar por um formato em papel com diversos dossiers e processamento manual? Ou devemos enveredar por uma solução digital por meio de aplicações informáticas? Toda e qualquer empresa ou organização possui um sistema de gestão, caso contrário a mesma não funcionaria e seria inexistente num conceito prático. Isto não significa obrigatoriamente o uso de Tecnologias de Informação (TI), segundo (Amaral, 1994), sistemas de informação, em sentido lato, são a totalidade de atividades de processamento e representação de dados formais e informais dentro da organização, incluindo as comunicações internas e com o mundo exterior. Sistemas de Informação em sentido estrito são um subsistema de informação baseado em computador com a finalidade de promover o registo e o suporte de serviços de gestão e operação da organização. O formato digital tem diversas vantagens, ausência de fronteiras geográficas, disponibilidade 24h/24h, 365 dias ao ano, acessos múltiplos, acesso estruturado ao conteúdo, recuperação de informação, conservação e preservação, reduzido espaço físico, networking e custo reduzido (Ramalho, 2007). No contexto do ensino, os sistemas de informação são sujeitos a condicionantes específicas, possibilitando novos canais de aprendizagem, avaliação e comunicação sem limitações ao nível de espaço e tempo. Estes permitem dar uma maior resposta às instituições, aumentando a sua capacidade de formação e ao mesmo tempo tornar mais eficientes todos os processos de gestão académica Contexto das Oficinas de Eletrónica da UTAD As Oficinas de Eletrónica da Universidade de Trás-os-Montes e Alto Douro (UTAD) têm como objetivo prestar serviços de apoio à instituição e alunos na área de Eletrónica, nomeadamente na cedência de componentes eletrónicos, dispositivos laboratoriais necessários para a realização dos protocolos experimentais nas aulas práticas, 3

30 no desenvolvimento dos diferentes projetos, consultadoria, reparação e manutenção de aparelhos eletrónicos pertencentes à universidade, alunos, funcionários ou entidades externas. Atualmente, toda a gestão dos recursos e serviços prestados pelas Oficinas é efetuada por meio manual, em suporte de papel, seguindo normas pouco restritas e que algumas vezes, devido à morosidade do processo, acaba por nem ser efetuado, perdendo-se assim informação relevante necessária para a tomada de decisões que conduzam a uma gestão mais eficiente. Já diversas tentativas foram tomadas com o objetivo de encontrar uma solução para o problema existente, contudo dos diferentes projetos desenvolvidos apenas foi criada uma base de dados Access, onde inicialmente se registou todo o inventário de artigos das oficinas e as suas existências. Contudo por ser uma ferramenta de utilização morosa acabou por ser posta de lado. Neste contexto surge a iniciativa de se encontrar uma solução tecnológica que solucione os problemas existentes na prestação de serviços e cedência de bens por parte das Oficinas. Este sistema vai oferecer um canal de comunicação constante entre os diferentes utilizadores e as Oficinas, permitindo um maior controlo e gestão, baixando significativamente os seus custos e aumentando significativamente a sua rentabilidade Objetivos Neste contexto pretende-se, com este trabalho, desenvolver um sistema de informação à medida, orientado especificamente ao contexto das Oficinas de Eletrónica da Universidade de Alto Douto e Trás-os-Montes, de forma a permitir um canal de comunicação constante e de fácil acesso para todos os utilizadores intervenientes. A nova plataforma deve permitir o acesso via Web na utilização dos diferentes serviços, garantindo maior acessibilidade e gestão das operações realizadas com as Oficinas O sistema tem como principal objetivo solucionar o processo de requisição e devolução dos artigos utilizados pelos alunos no desenvolvimento dos diferentes projetos associados aos múltiplos cursos no seio da universidade. Desta forma as premissas principais passam pela criação de registos corretos das entradas e saídas de material e notificação dos utilizadores intervenientes assim que necessário para a devolução dos diferentes artigos. 4

31 Outro objetivo também fulcral passa por permitir um método de agendar de forma intuitiva os serviços de reparação prestados pelas Oficinas, oferecendo um canal de comunicação entre os diferentes utilizadores e Oficinas para o controlo do processo de reparação desde o agendamento do serviço até ao seu término. Ao nível da gestão das Oficinas um dos principais objetivos do sistema passa por permitir a criação de relatórios acessíveis gerados com base na informação obtida nos diferentes registos das oficinas. Como a mão-de-obra útil ao nível da gestão das Oficinas é escassa, o sistema sempre que possível deve automatizar as ações de notificação dos diferentes utilizadores, baseando-se em determinadas heurísticas pré-definidas. Como objetivos de mais alto nível pretende-se que o sistema permita uma utilização acessível aos utilizadores, com um interface eficiente e de fácil compreensão, onde é permitido o registo de diversas informações associadas às diferentes operações Organização do Documento Esta secção apresenta sucintamente a estrutura e conteúdo do referente trabalho, onde é possível identificar cinco capítulos, apresentados de forma sequencial formando uma lógica e métodos associados ao desenvolvimento do projeto, desde de um conjunto de reflexões iniciais até a uma série de implementações, conclusões e perspetivas futuras. O presente capítulo, de índole introdutório, faz uma descrição do contexto, enquadramento e objetivos do projeto desenvolvido. Posteriormente o segundo capítulo descreve o panorama das Tecnologias de Informação ao nível das instituições, os níveis de gestão onde operam e são estudadas as mais recentes soluções existentes no mercado. Após o enquadramento o terceiro capítulo descreve todo o trabalho de análise, especificação e documentação do sistema desenvolvido. No quarto capítulo são descritas detalhadamente as tecnologias e metodologias, processos e funcionamento do sistema desenvolvido. O quinto capítulo descreve os detalhes na avaliação e testes efetuados no sistema. E por último o quinto capítulo, a conclusão, consiste nas considerações finais sobre o trabalho desenvolvido e indicação de implementações futuras. 5

32 Página Sem Texto Propositadamente 6

33 2. Revisão Bibliográfica 2.1. Dos Sistemas de Informação à Gestão Atualmente, o computador é uma das tecnologias mais populares e eficazes que o indivíduo tem ao seu dispor para lidar com a informação (Gouveia & Ranito, 2007). Com a proliferação dos computadores pessoais a iniciar-se por volta da década de oitenta passou a ser possível às instituições e utilizadores comuns fazer uso desta tecnologia, que anteriormente devido aos seus custos elevados só estava acessível a mercados com maior poder de compra. Desde então o computador passou a assumir uma relação de mediação entre indivíduos e instituições para a troca e uso de informação. Como a partilha e acesso à informação se tornou mais fácil, o acesso ao conhecimento e a experiências de terceiros na resolução de problemas e necessidades passa a tornar-se uma constante (Gouveia & Ranito, 2007). No seio das organizações um dos fatores determinantes para o seu correto funcionamento é a forma como estas tratam a informação e de que maneira fazem uso da mesma para se otimizarem. Neste paradigma o computador permite lidar com a informação com maior facilidade em três aspetos principais, melhor manobrabilidade com a escala da informação, complexidade da informação e métodos de organização da informação. O computador ajuda a simplificar processos de tomada de decisão, a diminuir as dificuldades de manipulação de dados e informação, permitindo um canal otimizado na gestão do fenómeno de excesso da mesma (Gouveia & Ranito, 2007). A informação, dependendo da natureza da sua utilização no seio das organizações, pode ser dividida em três níveis de utilização dos recursos de informação e dados, a que também estão associados diferentes níveis de controlo. Os níveis de responsabilidade operacional, tático e estratégico (Figura 2). 7

34 2 Revisão Bibliográfica Figura 2 Estrutura Hierárquica de Uma Empresa (Reynolds & Stair, 2010) O computador e as ferramentas associadas permitem o aumento progressivo das atividades automáticas na organização da informação, em detrimento das manuais devido a um conjunto variado de fatores, urgência no tratamento de informação, quantidade de informação a manipular (escala), diversidade de fontes de informação, complexidade da informação a manipular, necessidade de conhecer cenários alternativos, velocidade de reação/capacidade de resposta, fiabilidade e segurança no sistema. Os computadores não são um fim em si, mas um meio de auxiliar o processo de decisão e a ação, com maior eficiência e com eficácia. Desta forma, o suporte ao fluxo de informação proporciona um menor esforço, uma maior eficiência e por isso mesmo tem impacto na eficácia e desempenho da organização, (Gouveia & Ranito, 2007). A informação (bem como a sua recolha, tratamento e apresentação) tem como objetivo final facilitar a tomada de decisões no negócio quer sejam de nível operacional, tático ou estratégico. Assim, fará algum sentido uma maior abordagem sobre o processo da «gestão» (enquanto conjunto de decisões sobre dados e informação), já que esta existe a todos os níveis da empresa. No entanto, um computador por si só corre o risco de se tornar uma ilha de informação. As redes para partilha de dados, os computadores e o nascimento da World Wide Web são a resposta atual a este problema. Atualmente os Sistemas de Informação têm o desafio de se integrar com todos os Stakeholders no seio das organizações. 8

35 Numa visão de mais baixo nível podemos identificar as seguintes funções associadas a um sistema de informação: recolha da informação garantindo a correta entrada de dados no sistema, armazenamento da informação garantindo o registo dos dados necessários ao sistema, processamento da informação dando resposta às exigências de dados e informação para suporte do sistema, representação da informação, permitir uma perceção e navegação com qualidade nos dados e informação disponíveis no sistema, distribuição da informação e garantir o fluxo de dados e de informação no sistema. O Sistema de Informação é constituído pela integração de recursos humanos, equipamento de dados e informação (que suportam as operações, a gestão e a tomada de decisão), utiliza hardware, software, procedimentos manuais, modelos de análise, planeamento, controlo e de decisão (Gouveia & Ranito, 2007). Um sistema de informação pode ser decomposto em subsistemas de informação, normalmente cada um deles com finalidades específicas bem definidas. Nos Sistemas de Informação mais recentes essa divisão é comercialmente denominada como módulos cada um gerindo uma parte específica no seio da organização, num ou vários níveis da empresa. Como módulos principais podemos referir gestão de clientes e vendas, gestão de compras/fornecedores e gestão de artigos. Estes podem ser encontrados nos sistemas mais básicos, normalmente utilizados em micro e pequenas empresas. Hoje em dia denominamse como Sistemas de Gestão todos os Sistemas de Informação que oferecem apoio à «gestão» das organizações por meio de um software ou ferramenta digital. Um sistema de gestão procura planear, executar, monitorizar e melhorar as diferentes atividades de uma organização, tendo em conta as necessidades e expectativas das diferentes partes interessadas (Sampaio, 2011). Nos sistemas mais complexos como é o caso dos Enterprise Resource Planning (ERP) utilizados em pequenas, médias e grandes empresas, normalmente encontra-se o módulo de gestão financeira, vendas, planeamento, inventário, operacional, recursos humanos e administração. Mais recentemente associado ao módulo de vendas/operacional é possível encontrar um sub-módulo CRM (Costumer Relationship Manager), este oferece diversos tipos de funcionalidades que apoiam diretamente o operacional de vendas no formato de atendimento e serviço prestado. Enterprise Resource Planning é um Conjunto integrado de módulos de software que possuem um sistema de gestão de base de dados comum, que de forma integrada, recolhem e partilham dados e informação (Gouveia & 9

36 2 Revisão Bibliográfica Ranito, 2007). Os ERP s possuem numerosas aplicações que podem suportar praticamente todas as atividades internas de uma organização. Todos estes módulos trabalham de forma totalmente integrada permitindo um cruzamento otimizado de toda a informação. Estes sistemas tendem a cobrir todas as áreas funcionais da organização com a capacidade de fazer funcionar em conjunto aplicações distintas, mesmo estas sendo de fornecedores distintos Soluções comerciais de gestão Na procura da melhor solução para o caso das Oficinas também se considerou a hipótese de adotar uma solução/pacote de software já existente no mercado. Nesse sentido efetuou-se um levantamento de alguns dos sistemas disponíveis comercialmente, procurando responder a duas questões fulcrais. As soluções comerciais respondem aos requisitos exigidos nas Oficinas de Eletrónica? Que vantagens existem no desenvolvimento de uma aplicação feita à medida? A escolha dos aplicativos que de seguida serão comentados foi feita segundo tendências de mercado, custos, soluções que se apresentaram mais adotadas, integrais, completas e previsivelmente mais adequadas Primavera Express (free-license) A empresa Portuguesa (Primavera) presta suporte e formação, garantindo todo o apoio necessário à correta implementação, manutenção e utilização das suas soluções. A versão gratuita do seu sistema de gestão possibilita as funcionalidades de Point-of-Sale (POS) e backoffice, criação de ficheiros Standard Audit File for Tax Purposes na Versão Portuguesa (Saft-PT), registo de artigos, vendas, recibos, gestão de stocks, compras, utilizadores e clientes. De referir que, apesar de apresentar detalhes interessantíssimos a nível de informação, a sua navegabilidade e interface, são pouco apelativos, bastante inacessíveis e pouco percetíveis para o utilizador. Outro problema encontra-se no excessivo número de atributos existente nos formulários de introdução de dados. Estes em determinados contextos acabam por ser desnecessários e apenas acrescentam complexidade e ineficiência na utilização. O mesmo acontece com algumas funcionalidades que não são necessárias. Não possui um módulo/acesso web que acaba por ser uma grande desvantagem na 10

37 atualidade, visto operar unicamente como mono-utilizador, (PRIMAVERA Business Software Solutions, 2012) Primavera Executive (paid-license) A solução Primavera Executive é uma solução global, com elevada capacidade de adequação, disponibiliza vários mecanismos para ajustar/adequar a solução da melhor forma ao negócio. Logística Área Financeira Tesouraria Contabilidade Equipamentos e Ativos Bastante mais completo do que a versão Express, visto ser um ERP, nomeadamente na gestão de fornecedores, produção e inventário. Possui uma navegabilidade bastante mais intuitiva, mas um interface pouco apelativo, ficando mesmo assim abaixo do desejável. Tal como na versão Express, em contextos específicos a sua utilização torna-se complexa e lenta devido ao excesso de informação que é necessário introduzir em diversos formulários. Em ambas as versões existe uma enorme falta de modulação/adaptação a cada caso de implementação em específico, não permitindo uma especificação a cada tipo de negócio ou função da instituição. Todos os dados são integrados por meio da sua Shell integrada, sendo a informação apresentada ao utilizador completamente transversal. Está disponível em diversas línguas e realidades fiscais para empresas multinacionais. Permite uma poupança no número de licenças PRIMAVERA (com utilização de Terminal Server). A Primavera apresenta soluções específicas para os setores da Construção, Manufatura, Retalho e Restauração, mas nestes casos estes sistemas não apresentam as vantagens já mencionadas dos sistemas ERP, para a sua adoção necessitam de implementações à medida. Se necessário, é possível acrescentar o módulo web extra através do Primavera WebCentral. É uma solução possível de ser adotada nas Oficinas da UTAD contudo inviável devido aos custos avultados da sua licença. Atualmente diversas médias e grandes 11

38 2 Revisão Bibliográfica empresas utilizam este Sistema como é o caso da Sanyo Portugal Eletrónica, entre outros, (PRIMAVERA Business Software Solutions, 2013) SAP (paid-license) O SAP ERP Corporate Services pretende oferecer benefícios como aumento da transparência e controlo, redução de custos, diminuição de riscos financeiros, otimização do suporte à decisão, crescimento da instituição, desempenho de equipamentos e melhoramento no atendimento ao cliente. Fornece uma arquitetura orientada a serviços permitindo às empresas adaptarem-se ao seu próprio ritmo ( como parte de suas soluções SAP ). A SAP e os seus parceiros fornecem apoio à empresa na adoção desta arquitetura tendo baixo risco e custos controlados, oferecendo uma arquitetura orientada a serviços baseada em serviços de empresa pré-embalados/agrupados em cenários de negócios. Possui uma tecnologia adaptativa para as empresas em rede, apresentando assim benefícios nas estratégias de negócio flexíveis, processos de negócio inovadores, melhor desempenho da empresa, experiência de utilizador incomparável, possibilidade de estender os processos de negócios a todos os funcionários, fornecedores e clientes. A SAP não possui uma solução genérica, para cada setor de atividade existe uma versão otimizada do seu ERP, nomeadamente: SAP for Aerospace & Defense, SAP for Automotive, SAP for Banking, SAP for Chemicals, SAP for Consumer Products, SAP for Defense & Security, SAP for Engineering, Construction & Operations, SAP for Healthcare, SAP for High Tech, SAP for Higher Education & Research, SAP for Industrial Machinery & Components, SAP for Insurance, SAP for Life Sciences, SAP for Logistics Service Providers, SAP for Media, SAP for Mill Products, SAP for Mining, SAP for Oil & Gas, SAP for Postal Services, SAP for Professional Services, SAP for Public Sector, SAP for Railways, SAP for Retail, SAP for Telecommunications, SAP for Utilities e SAP for Wholesale Distribution. Trata-se do sistema líder europeu sendo uma solução extremamente completa, contudo complexo na perceção da sua lógica e funcionamento, o que torna obrigatória a formação dos seus utilizadores. É uma solução aplicável às Oficinas da UTAD, contudo inviável em termos de custos na compra da licença de utilização, parametrização e implementação. Atualmente encontra-se em produção no grupo Unicer Bebidas SA, TAP 12

39 Maintenance & Engineering, Compal, Jerónimo Martins, Delta entre outros, (SAP Portugal, 2013) Openbravo (opensource paid-license) Apresenta-se como ERP low cost bastante intuitivo, com design multi-guia na aplicação, totalmente integrado e com fluxos de processos eficientes de forma a facilitar e agilizar a colaboração das operações de ponto a ponto, entre os diferentes operadores. Abrange ainda uma ampla gama de aplicações dirigidas à contabilidade, vendas/crm, gestão de compras, stocks, produção, projetos, serviços e integração e-commerce. Tem uma característica importante, já que é modular e atualizável, é de fácil interação, com diversas aplicações de acesso e centenas de extensões nativas tais como, Intercompany Documents for Document Manage, Google Maps Logistics, Frequently Asked Questions (FAQ), Warehouse Management, Sales Management, Rest Webservice, Bussiness Intelligence, Mass Invoicing, Lightweight Directory Access Protocol (LDAP) Authentication, Stock Control, Human Capital Management e CRM. Permite o pagamento automatizado por meio do seu Electronic invoicing and banking e criação de documentos num formato standard, Portable Document Format (PDF). Tem um interface acessível e altamente otimizado em comparação com os concorrentes, contudo devido a ser tão completo acaba por se tornar demasiado complexo e de utilização difícil e morosa. É 100% Web-Based, garantindo assim maior facilidade de acesso e grande compatibilidade com dispositivos móveis. Os clientes têm a opção de implementação da aplicação na nuvem (cloud) reduzindo na complexidade e despesas de manutenção. Por fim, é Open Source permitindo a sua readaptação, desenvolvimento, manutenção e controlo completo por parte do cliente ao longo do tempo. Tal como o Primavera Executive permite a sua utilização com diferentes moedas. Tem um custo de aquisição reduzido com licença de utilização vitalícia, ou caso não seja financeiramente possível a compra pela empresa são fornecidos outros métodos de pagamento, pacotes de aplicativos ou por número de licenças. Esta solução poderia ser uma possibilidade para as Oficinas da UTAD, mas a sua implementação exigiria uma intensa formação dos utilizadores e grande parte das funcionalidades não seriam úteis, como tal seria necessário desenvolver a parametrização de todo o software/módulos necessários, tornando o mesmo mais acessível e eficiente. 13

40 2 Revisão Bibliográfica Além disso acaba por ser inviável devido aos custos iniciais de implementação e licenças. Atualmente é utilizado em diversas pequenas, médias e grandes empresas como é o caso da Johnson Controls, da Offerum, entre outros, (Openbravo, 2013) Conclusões do Levantamento Após a análise das diferentes soluções pode-se concluir que o problema das Oficinas é bastante específico, a falta de recursos financeiros, necessidade de integração do novo aplicativo com o software já existente, contexto orientado ao ensino, especificidade na informação, fluxos de trabalho, desenvolvimento expansível e com facilidade de desenvolvimento por posteriores alunos. É possível uma melhor perceção das vantagens e desvantagens das diferentes soluções na Tabela 1. Tabela 1 Comparativo de Softwares de Gestão Primavera Express Primavera Executive Openbravo SAP Solução à Medida Solução Parametrizável Gratuita Custo de Compra Gratuito Substancial Baixo Alto Alto Custo de Implementação Baixo Substancial Substancial Alto Alto Navegabilidade Má Razoável Boa Má Boa Solução Apelativa Gestão de Artigos Gestão de Compras Gestão de Vendas Gestão de Clientes 14

41 Gestão de Alunos Gestão de Docentes Gestão de Administradores Gestão de Requisições Gestão de Fornecedores Gestão de Cadeiras Gestão de Cursos Gestão de Projetos Académicos Gestão de Grupos de Trabalho Gestão de Relatórios Acesso Via Web Gestão de Reparações Gestão de Contas Correntes Notificações Via Diversas implementações existentes nos sistemas estudados foram registadas, dando uma enorme ajuda no processo criativo na resolução de problemas ao nível da modelação de dados, funcional e de interface gráfico. Desta forma obteve-se uma maior contextualização tendo em vista alcançar a melhor solução possível Enquadramento Tecnológico Para uma melhor implementação e desenvolvimento deste sistema foi previamente efetuado um estudo de contextualização tecnológica, fulcral ao sucesso do projeto no 15

42 2 Revisão Bibliográfica contexto das Oficinas da UTAD. Desta forma obteve-se um panorama das melhores práticas e tecnologias utilizadas na atualidade Sistemas Operativos A escolha do Sistema Operativo (SO) é importante para o sucesso do projeto. Embora não contribua diretamente para a fiabilidade das aplicações, pode fornecer formas que permitam controlar a falta desta. No caso das aplicações Web isso passa a não ser um problema de grande relevância visto a aplicação correr completamente do lado do servidor, sendo apenas utilizado um web-browser como terminal para acesso. Contudo se o sistema utilizado não oferecer eficiência, robustez e segurança, esse terminal torna-se vulnerável, oferecendo um meio de acesso à aplicação colocando em risco todos os dados ao qual o Figura 3 - Funcionamento do Sistema Operativo e Respetivo Browser utilizador tem acesso ao longo da sua sessão. Na Figura 3 podemos visualizar a que níveis a interação entre o Utilizador, Browser e Sistema Operativo ocorre. Visto o sistema Windows ser o mais utilizado a nível institucional e mesmo pessoal, a sua aplicação é quase obrigatória por parte dos utilizadores finais na maior parte dos casos. Este S.O (Sistema Operativo) ao longo dos tempos nas suas diferentes versões tem-se mostrado fiável, estável e seguro, salvo raras exceções. Optar por uma solução livre como Linux seria uma solução vantajosa unicamente ao nível financeiro devido às licenças de utilização, contudo obrigaria à readaptação de todos os utilizadores com formações, testes de utilização e implementação. As exigências e probabilidades de futuros problemas seriam enormes. Caso a instituição venha a optar por outro sistema facilmente essa 16

43 operação pode ser efetuada visto a aplicação ser Web e como tal completamente independente dos sistemas operativos utilizados pelos diferentes utilizadores. No caso das aplicações Web ao nível do servidor a escolha do S.O. onde estas aplicações se encontram alojadas é uma decisão extremamente importante. O S.O. utilizado e a tecnologia escolhida para o desenvolvimento da aplicação estão dependentes um do outro, a procura da melhor solução vai depender das circunstâncias da empresa tais como poder de compra, experiência de utilização, segurança, maior ou menor otimização de recursos, serviços a prestar, entre outros Linguagens Seguidamente à definição do sistema é necessário determinar as linguagens e ambientes de programação. A fiabilidade e desenvolvimento de qualquer software são sensíveis a estes dois fatores. Em qualquer linguagem é necessário fazer a gestão dos tipos, dimensão das variáveis e informação temporária. Segundo (Ferreira, 1995) a dimensão pode ser, previamente declarada e fixa, declarada e variável e não declarada. No caso de se desenvolver num paradigma orientado a objetos é necessário também fazer a gestão das classes. Segundo (Booch, 1998) esta filosofia de desenho de aplicações decompõe o sistema em elementos chave de acordo com o domínio do problema, ao invés de decompor o problema em passos. Passa-se a poder criar objetos que representam a realidade com conjuntos de atributos, permitindo gerir os dados de forma mais lógica e simples. Existem três tipos de linguagens: as compiladas, as interpretadas e as semi (ou pré)- compiladas. Qualquer um dos tipos pode ser utilizado para desenvolvimento de aplicações stand-alone ou Web. Os dois últimos tipos são aqueles que deixam as tarefas de verificação de consistência nas atribuições, comparações em expressões lógicas e verificação de sintaxe a cargo dos programadores. Estes trazem diversos problemas como por exemplo no nome das variáveis utilizadas e a sua invocação, utilização de funções já implementadas em diferentes bibliotecas, entre outros. Por este motivo segundo (Ferreira, 1995) é preferível a utilização de linguagens compiladas em detrimento das restantes. A única vantagem que se pode associar às linguagens interpretadas e semi-compiladas é a facilidade, aparente, de programação e o controlo oferecido ao programador. Esta vantagem é no entanto de desprezar face aos problemas de fiabilidade que podem ser encontrados. 17

44 2 Revisão Bibliográfica Atualmente as linguagens mais utilizadas para o desenvolvimento de aplicações são C, C++, C#, Active Server Pages (ASP), Visual Basic (VB), Objective-C, Java, Hypertext Preprocessor (PHP) e Javascript. Todas elas, são compiladas à exceção do Javascript e PHP. Em termos de eficiência de processamento acabam por ser idênticas, as principais diferenças são mesmo ao nível da lógica de desenvolvimento e das funcionalidades que as suas framework s disponibilizam. Como principal diferença podemos destacar o Java que permite o desenvolvimento de aplicações multi-plataforma por meio da Java Virtual Machine (JVM). Em termos de mercado a mais utilizada é o C por ser a base de evolução das restantes e por ter a reputação de linguagem com mais performance. Ao nível de desenvolvimento Web as linguagens C, C++, C#, VB, Objective-C e Java podem ser utilizadas no desenvolvimento de aplicações no lado do cliente e servidor. Neste paradigma com Applets e Servlets, utiliza-se uma aplicação cliente (Applet) que funciona como um terminal de acesso, a mesma efetua pedidos e recebe respostas HTTP. Do lado servidor (Servlet) utiliza-se uma aplicação que se encontra à escuta recebendo os pedidos e efetuando as respostas HTTP. Este contexto embora seja completamente funcional e eficiente acarreta o desconforto na obrigatoriedade de todos os utilizadores do tipo cliente terem o pré-requisito de instalar a aplicação caso queiram ter acesso ao sistema. Para o aumento da acessibilidade dos sistemas baseados na Web surgiu o paradigma de Aplicações Web, as principais diferenças assentam na utilização de um Web Browser ubíquo como aplicação cliente e na utilização de linguagens de marcação como é o exemplo do HTML para gerar conteúdos acessíveis aos humanos. Como tal surgiram linguagens específicas para o desenvolvimento destes sistemas, tais como ASP.net, VB.net, Java Servlets, JSPs e PHP. Para o desenvolvimento de interfaces gráficos mais apelativos e dinâmicos surgiram outras linguagens para complementar o HTML como é o caso de Java Applets, Javascript, Flash e Silverlight Hardware A escolha e dimensionamento do hardware onde o sistema vai ser implementado é uma escolha essencial à sua boa performance. Segundo (Reynolds & Stair, 2010) hardware é um conjunto de periféricos ou equipamentos físicos usados para a entrada, processamento e saída de um sistema de informação. 18

45 No caso das aplicações Web a arquitetura necessária é mais complexa. Os utilizadores necessitam de um computador com ligação à internet para aceder ao sistema como terminal de acesso e os administradores de um computador/servidor onde a aplicação fica instalada, o mesmo deve de preferência ter algum poder de computação e memória Figura 4 Arquitetura de Aplicações Web para lidar com todos os pedidos efetuados pelos diferentes utilizadores. Como se observa na Figura 4 existem várias opções na arquitetura Web. Ao nível das grandes aplicações podemos ter a base de dados ou mesmo a aplicação distribuída por diversos servidores, aumentando a sua performance mas também a sua complexidade na gestão e processamento de dados, tudo depende da necessidade do sistema e dimensão da organização. Para colocar a aplicação em produção é também necessário um endereço publico, um domínio e conexão à internet. Caso sejam necessárias outras funcionalidades que exijam diferentes periféricos como, impressora, leitor de códigos de barras ou de identificação biométrica, o número de periféricos aumenta. 19

46 2 Revisão Bibliográfica Interface do Utilizador Segundo (Pressman, 2000) o design da interface de utilizador é a criação de um meio de comunicação eficiente entre um humano e um computador. O importante num software ao nível da interface gráfica é a dificuldade de utilização, a indução do utilizador a erros e o sentimento deste na concretização dos seus objetivos, independentemente do poder computacional e funcionalidades oferecidas pelo mesmo. A interface molda a perceção que o utilizador tem do software e por isso é uma premissa de primeira instancia que a mesma seja implementada corretamente. Um sistema de informação com interface gráfica do utilizador graphical user interface (GUI) fornece aos utilizadores um uso mais familiar e confortável. Este torna a manipulação do sistema mais produtiva e reduz o tempo de aprendizagem. No caso da Internet e tecnologias Web as mesmas inicialmente foram desenvolvidas com o objetivo de divulgar informações em texto simples com páginas estáticas em HyperText Markup Language (HTML), onde a navegação é feita pelo meio das diferentes páginas existentes. Aos poucos evoluíram deixando de apresentar interfaces pouco sofisticadas e assim modificaram a sua finalidade inicial. A Web deixa então de ser um repositório partilhado de conteúdos estáticos e passa a ser uma rede de acesso a diversos sistemas de informação dinâmicos. Como tal, segundo (Pressman, 2000) ao nível da aplicação foram definidos dois atributos fulcrais: - Navegação: É a definição dos caminhos por onde o utilizador pode ter acesso ao conteúdo e aos serviços oferecidos pela aplicação. O utilizador deve perceber a lógica de navegação por defeito ao utilizar a aplicação. A navegação é um aspeto a ter em conta pois segundo (Rosenfeld & Morville, 2002) «perder-se» está associado à confusão, frustração, raiva e medo. Em resposta a esse perigo a humanidade desenvolveu ao longo do tempo ferramentas de navegação como astrolábios, mapas, sinais rodoviários e sistemas de posicionamento global. - Interface: Através da interface o utilizador tem o seu contacto direto com a aplicação, por esse motivo é importante lembrar que uma interface bem estruturada melhora a perceção dos serviços oferecidos e a informação apresentada. Por isso deve ser bem estruturada e ergonomicamente sólida. 20

47 No desenvolvimento de aplicações, deve ser dada prioridade à satisfação do cliente, desenvolvendo e apresentando-se diferentes versões do software de forma contínua até se chegar a uma versão estável. As alterações e incrementos devem ser entregues em curtos períodos, para que o cliente possa avaliar as modificações regularmente, fornecendo o feedback de forma implícita e influenciando as adaptações do sistema. Segundo (Pressman, 2000) a questão Como asseguro que a mesma foi implementada corretamente? é respondida colocando as diferentes versões em testes pelos utilizadores finais. O feedback obtido é então utilizado para a próxima alteração iterativa do protótipo. É verdade que as interfaces gráficas orientadas ao utilizador, janelas, ícones e cliques do rato eliminaram diversos dos principais problemas. Mas mesmo num «mundo de janelas» todos temos encontrado interfaces que são difíceis de perceber, utilizar, confusas e em muitos casos, totalmente frustrantes. O design de interfaces orientadas ao utilizador tem muito mais a ver com o estudo das pessoas do que com os problemas tecnológicos (Pressman, 2000) Conclusão Com esta revisão conclui-se que as organizações são estruturas complexas com processos e contextos muito próprios de caso para caso, sendo um desafio intrínseco para quem estuda e melhora toda a logística associada às mesmas. Pelo mesmo motivo é possível perceber como é que os Sistemas de Informação se enquadram neste meio, os seus principais intervenientes, as vantagens e desvantagens que apresentam, os desafios que enfrentam e os melhores métodos na sua adoção. Após um levantamento das caraterísticas de alguns sistemas de gestão comerciais conclui-se que nenhum satisfaz os requisitos pretendidos para a aplicação das Oficinas da UTAD. Por fim, a correta implementação de um Sistema de Informação obriga a que se estude o panorama tecnológico não só a nível de soluções já existentes mas também avaliar se é ou não vantajoso construir uma solução de raiz, otimizada, inovadora, utilizando as mais recentes tecnologias e soluções de desenvolvimento. Dessa forma é possível obter um panorama das tecnologias, arquiteturas e quais os desafios que as mesmas apresentam no contexto onde estas se pretendem aplicar. Só após a obtenção de uma imagem holística das instituições e todas as soluções técnicas aplicáveis é possível tomar a decisão mais acertada na escolha de uma solução. 21

48 Página Sem Texto Propositadamente 22

49 3. Especificação do Sistema As oficinas de eletrónica da UTAD possuem um balcão de atendimento aberto ao público onde prestam serviços de apoio à instituição e a entidades externas na área de Eletrónica. Os alunos ou qualquer pessoa/instituição pertencente ou não à Universidade podem-se deslocar a este balcão e ter acesso aos diferentes serviços. Apenas os alunos ou indivíduos pertencentes à Universidade têm acesso ao serviço de cedência de componentes eletrónicos ou equipamentos laboratoriais. Atualmente para o ato de requisição existem seis formulários destintos: Requisição de componentes ou equipamentos laboratoriais associado a grupos de trabalho com um máximo de cinco alunos; Requisição unicamente de componentes eletrónicos associados a um ou vários docentes caso estejam a desenvolver projetos em conjunto; Requisição de equipamentos laboratoriais associados a um ou vários docentes; Requisição de placas eletrónicas de circuitos impressos feitas à medida associada a docentes ou alunos; Requisição de equipamentos informáticos associados a alunos ou docentes; Requisição de componentes eletrónicos ou equipamentos laboratoriais associados a projetos de mestrado dos diferentes alunos e seus orientadores. Relativamente ao serviço de reparação qualquer entidade ou pessoa pode ter acesso ao mesmo. Para o registo deste serviço existem três formulários distintos: Reparação de um equipamento qualquer pertencente à universidade de qualquer faculdade ou departamento; Registo de uma reparação associada a uma entidade ou pessoa singular externa à universidade; 23

50 3 Especificação do Sistema Registo de uma reparação pertencente a qualquer equipamento pertencente aos laboratórios do departamento/faculdade de engenharia da Universidade. A gestão e utilização eficiente de toda esta documentação torna-se complexa, exigindo um esforço de todos os colaboradores das Oficinas no registo, busca e organização dos diferentes arquivos. Apesar do bom profissionalismo e dedicação dos diferentes funcionários das Oficinas, tais operações em momentos de grande afluência por parte dos utilizadores/clientes, tornam-se extremamente morosas e frustrantes para os diferentes colaboradores. Como tal, para um registo mais rápido dos diferentes formulários a solução encontrada foi passar a colocar os utilizadores/clientes a preencherem por si mesmos os diferentes formulários, registando os diferentes componentes, equipamentos e quantidades que desejam. Tal operação gera diversos erros na informação registada, muitas vezes por descuido do utilizador, deteção tardia da inexistência de stock de determinado componente ficando este registado na mesma, má verificação do registo por parte do funcionário, não registo de novos equipamentos ou componentes pedidos mais tarde, ou muitas das vezes por falta de tempo a requisição nem sequer é registada. Ao nível das reparações, como o fluxo de operações não é tão intenso, os registos acabam por ser mais corretos. Contudo, ao longo da reparação como o processo de procura do artigo correspondente e respetivo formulário é extremamente moroso, o registo das diferentes ações efetuadas e respetivos artigos utilizados é feito unicamente quando a reparação se encontra terminada. Como grande parte das reparações muitas das vezes demoram dias a serem concluídas isso provoca esquecimento devido a erro humano, não sendo contabilizadas corretamente as horas despendidas nem os artigos utilizados. Tais erros acarretam custos não contabilizados para a instituição que devem ser evitados Método de Desenvolvimento Uma das decisões mais fulcrais no desenvolvimento de qualquer projeto de software é a escolha do método de desenvolvimento, os resultados finais e eficiência ao longo do projeto são extremamente dependentes deste processo. O processo de desenvolvimento de software varia de organização para organização e de projeto para projeto, diferindo no número de fases, na ordem de execução destas (Linear, iterativa, espiral), nas ferramentas e métodos utilizados, nos produtos que precisam de ser entregues, no staff utilizado e em muitos outros detalhes. Após um debate 24

51 Sistema de Gestão Para Oficinas de Eletrónica sobre as diferentes particularidades do projeto o método escolhido foi o de Espiral Iterativa, Figura 5. Face à realidade da equipa, meios de desenvolvimento e instituição onde a aplicação vai ser implementada a criação de diferentes versões protótipo com uma interação constante com o utilizador final oferece uma melhor perspetiva de sucesso. Figura 5 - Modelo de Desenvolvimento em Espiral (Boehm, 1988) Pode-se contatar que neste modelo o projeto decorre ao longo de uma espiral, começando no centro e deslocando-se no sentido horário. O número de ciclos (iterações) vai depender do tipo de projeto, qualidade dos desenvolvedores e do meio abrangente em si. O produto final de cada iteração pode ser um relatório, um protótipo, um sistema operativo, uma nova versão (release) ou a espiral pode permanecer operacional ao longo de todo o ciclo de vida do software onde novas funcionalidades e otimizações vão sendo feitas ao longo do tempo, dependendo do tipo de instituição, das suas exigências e do poder de compra, (Boehm, 1988) Análise de Requisitos Com vista a desenvolver um software adequado, eficiente e feito à medida da instituição é importante recolher as necessidades e problemas existentes. Neste sentido foi feita uma análise e especificação de requisitos funcionais e não funcionais. Segundo (Arlow & Neustadt, 2006) uma engenharia de requisitos pobre é a principal causa na falha de desenvolvimento de software. Neste trabalho foram utilizados diversos métodos para a recolha dos diferentes requisitos do sistema tal como análise sensorial no meio, conversas informais, brainstorming e questionários. O grande contacto e envolvimento tanto na análise como ao longo do desenvolvimento de todos os utilizadores foi algo que se teve em grande 25

52 3 Especificação do Sistema importância visto ser, com base em (Arlow & Neustadt, 2006) o segundo fator que mais contribui para o insucesso no desenvolvimento de software. O requisito é a especificação do que deverá ser implementado, sendo apenas declarações do que o sistema deve fazer e não de como essas funcionalidades devem ser implementadas, contudo segundo (Arlow & Neustadt, 2006) na prática não é possível evitar o como em diversos aspetos do sistema. Existem dois tipos de requisitos: os funcionais que especificam o comportamento desejado para o sistema e os não funcionais que especificam propriedades ou restrições específicas do sistema. Todos os requisitos foram declarados seguindo as normas especificadas na UML2 (Unified Modeling Language) Requisitos Funcionais Os requisitos funcionais identificados para o Sistema de Gestão de Oficina de Eletrónica (SGOE) são os seguintes: - O sistema deve registar e gerir reparações efetuadas para a UTAD; - O sistema deve registar e gerir reparações efetuadas por clientes externos à UTAD; - O sistema deve registar e gerir reparações efetuadas por entidades externas à UTAD; - O sistema deve registar e gerir a requisição de equipamentos informáticos; - O sistema deve registar e gerir a requisição de circuitos impressos; - O sistema deve registar e gerir a requisição de equipamento de laboratório (de medida e teste); - O sistema deve registar e gerir a requisição de componentes eletrónicos; - O sistema deve registar e gerir orçamentos para reparação de equipamentos; - O sistema deve permitir registar o estado do material dando baixa do mesmo nos stocks no caso de se encontrar danificado; - O sistema deve permitir o registo dos componentes que ficam montados em circuitos e portanto fora do stock de utilização; 1 Linguagem de modelação para auxílio na visualização e desenho no desenvolvimento de Software 26

53 Sistema de Gestão Para Oficinas de Eletrónica - Deve permitir dar baixa dos respetivos componentes que se encontram em stock; - Deve associar os respetivos pedidos ao utilizador. No caso de ser aluno deve registar o curso e a respetiva disciplina a que pertence; - Deve permitir a entrega de componentes por fases e descontar na conta do respetivo utilizador; - O sistema deve registar um valor por cada tipo de componente ou equipamento e criar um valor total por cada lista de requisição; - O sistema deve permitir visualizar o rácio de importância/atualização por cada componente; - O sistema deve registar um stock mínimo por tipo de componente; - O sistema deve permitir inserir e alterar requisições; - O sistema deve permitir inserir e alterar orçamentos; - O sistema deve permitir inserir e alterar reparações; - Deve permitir o registo de dívida por utilizador relativo a pedidos de componentes/equipamentos/reparações; - O sistema deve ter um motor de busca de componentes; - O sistema deve ter um motor de busca de reparações; - O sistema deve gerar códigos de barras associados a serviços e artigos; - O sistema deve ler códigos de barras; - O sistema deve permitir a criação de relatórios de apoio à decisão, nomeadamente contagem total de componentes utilizados especificados por tipo e contagem geral, total de componentes usados por utilizador em número e valor, identificação do componente mais utilizado, curso que mais componentes gastou e qual o componente mais gasto no mesmo em número e valor monetário e ainda o funcionário que mais registos efetuou Requisitos Não Funcionais No que diz respeito às características não funcionais foram identificados os seguintes requisitos para o SGOE (Sistema de Gestão de Oficina de Eletrónica): - O sistema deve ser implementado como uma plataforma Web; - O sistema deve estar sincronizado com o Sistema de Informação de Apoio ao Ensino (SIDE) e as suas respetivas contas de utilizador; 27

54 3 Especificação do Sistema - O sistema deve permitir uma visualização acessível das listas de requisição de modo a que o funcionário tenha facilidade na seleção e preparação dos respetivos pedidos; - Deve impedir os utilizadores de solicitarem novos componentes/equipamentos caso não tenham entregue os respetivos pedidos anteriores; - O sistema deve ter um alarme físico e por via de no local de trabalho para avisar o respetivo funcionário aquando da chegada de novos pedidos ou baixa de stocks; - O sistema deve permitir o aviso automático do docente responsável via , no caso de um utilizador danificar um numero máximo de componentes/equipamentos; - O sistema deve obrigar a que os campos mais relevantes no preenchimento dos requisitos sejam obrigatórios; - O sistema deve ter os seguintes utilizadores: Administrador, Chefe de Oficina, Convidado, Aluno, Docente e Funcionário; - O registo e procura de componentes no sistema (sem ser via motor de busca) devem ser feitos da seguinte forma: Família -> Categoria/Tipo -> Nome; - O sistema deve registar a frequência de utilização de cada tipo de componente ou equipamento; - O sistema deve calcular a prioridade de compra pela frequência de utilização e rácio de atualização e assim criar uma lista de compras prioritárias por ordem. - O sistema não deve permitir que os clientes consigam alterar uma requisição depois de esta ser levantada; - O sistema deve identificar cada encomenda de forma única e associar a mesma ao respetivo cliente ou grupo de clientes; - O sistema deve permitir ligações a Web-sites com os datasheet relativos a cada componente. - O sistema deve permitir a definição de quantidades por equipamento/componente nas respetivas requisições e gestão de stocks Modelação de Dados Para o desenvolvimento da base de dados em primeira instância é conveniente realizar um modelo conceptual que seja capaz de representar de forma explícita a sua estrutura e assim concluir se este preenche ou não os requisitos do sistema. A informação tem um valor e como tal deve ser guardada de alguma forma usável, em algum tipo de 28

55 Sistema de Gestão Para Oficinas de Eletrónica ficheiro para que seja útil (Bagui & Earp, 2003). Nos últimos 20 anos aproximadamente, existiram três tipos básicos de modelos lógicos para bases de dados, hierárquico, rede e relacional. Estes afirmam que a maior parte das bases de dados em uso atualmente são relacionais, isto devido às suas inúmeras vantagens na organização e acesso aos dados. Dentro dos diferentes modelos relacionais para representação de dados o desenvolvimento de Diagrama de Entidades e Relacionamentos (DER) é sem dúvida a técnica que mais tem sido utilizada. Este modelo foi introduzido por E. Codd em 1970, mas só chegou a um estado eficiente assim que este propôs as formas normais (Codd, 1990). Um DER é um modelo em rede que descreve a estruturação dos dados armazenados de um sistema, com elevado nível de abstração. Este especifica a base de dados documentando aquilo que a mesma contém. Os modelos DER são uma base fundamental para as fases subsequentes de construção e implementação dos sistemas. No desenvolvimento de um DER, um analista inicialmente tem em conta as entidades (objetos e conceitos relevantes para o sistema que está a ser modelado) e posteriormente analisa os relacionamentos entre as entidades identificadas. Segundo (Bagui & Earp, 2003) o DER é a ferramenta do analista para definir que informação deve ser guardada num sistema de informação, trata-se do desenho técnico para construir a base de dados. No desenvolvimento destes modelos devemos ter em consideração apenas os dados necessários e evitar guardar dados que podem ser obtidos através de cálculos ou deduções com base noutros dados, o sistema deve estar preparado para necessidades futuras, incluindo atributos, tabelas ou relacionamentos que eventualmente sejam necessários. No desenvolvimento do DER para o SGOE implementou-se aproximadamente quinze versões evolutivas, aprimorando-se ao longo do processo qual a informação a ser guardada e a forma como a mesma é estruturada, sempre com vista a obter um modelo de dados eficiente, completo, dinâmico e que preencha os requisitos obtidos na fase de análise. Ao longo deste processo os utilizadores tiveram um papel interventivo intenso em todas as versões criadas até se obter um consenso entre ambas as partes. Para uma melhor perceção do modelo de dados o DER foi dividido em vários módulos: utilizadores, grupos de trabalho, académico, artigos e documentos. Desta forma é possível uma explicação detalhada e individual dos diferentes módulos, seus papéis e funcionamento. 29

56 3 Especificação do Sistema Módulo de Utilizadores Neste módulo temos uma tabela principal «Utilizador» com todos os dados relevantes sobre os utilizadores que vão interagir diretamente com o sistema (Figura 6). Nesta tabela é registado o seu nome, login de acesso, morada, entre outras informações. Por meio do relacionamento com a tabela «Tipo de Utilizador» é possível de forma dinâmica auferir diversos tipos de utilizadores à medida das necessidades do sistema. Isto torna o modelo extremamente dinâmico para possíveis implementações futuras. Ou seja, podemos ter vários utilizadores de diferentes tipos, com diferentes níveis de acesso a informações e Figura 6 - DER Módulo Utilizadores funcionalidades. Desta forma o administrador facilmente gere os diferentes utilizadores e os seus níveis de acesso e pode mesmo cancelar o seu acesso de forma definitiva ou temporária por meio do atributo «Estado» na tabela «Utilizador». Outro aspeto relevante é o facto de obter-se diversas informações relativas à forma de pagamento do utilizador para compra de artigos ou serviços. Tem-se acesso ao tipo de preço que o utilizador tem direito desde preço de compra, preço de venda recomendado ao público, preço de estudante e preço de funcionário. Foi ainda acrescentado o atributo «Desconto» que cada utilizador pode obter, isto possibilita que independentemente do tipo de utilizador e do preço a que tem acesso ainda lhe pode ser aplicada uma margem de desconto consoante diversas variáveis no seu histórico de operações, tal como o montante médio de compras, numero total de compras, periodicidade de compras, entre outros. 30

57 Sistema de Gestão Para Oficinas de Eletrónica Módulo de Grupos de Trabalho Figura 7 - Módulo Grupos de Trabalho Neste Módulo é apresentada a tabela «Grupo» que tem como objetivo registar grupos de trabalho, estes representam conjuntos de utilizadores que se associam para desenvolver determinado projeto ou trabalho dentro da instituição. Temos uma tabela intermediária «Participa» entre «Grupo» e «Utilizador», desta forma podemos ter um utilizador associado a diversos grupos, assim como um grupo associado a diversos utilizadores (Figura 7). A tabela «Participa» regista também a data de início de participação do utilizador no grupo, alcançando desta forma um maior controlo dos diferentes utilizadores e períodos de participação. A existência de mais um relacionamento entre o utilizador e o grupo deve-se à necessidade de registar quem vai ser o utilizador administrador do grupo, tendo esse utilizador acesso a alterar o nome do grupo e respetivos utilizadores participantes. O mesmo grupo pode ser utilizado independentemente da unidade curricular ou projeto que esteja a ser desenvolvido, desta forma evitamos o registo de múltiplos grupos de trabalho muitas das vezes com os mesmos participantes sempre que se criam novos projetos ou unidades curriculares Módulo Académico Neste módulo registam-se todos os dados académicos da instituição, nomeadamente os seus cursos, unidades curriculares, projetos ou trabalhos associados (Figura 8). Mais uma vez temos uma tabela intermediária «ListaU.Curriculares» pois no processo de análise constatou-se que para além de um Curso ter diversas Unidades Curriculares as mesmas podem pertencer a diferentes cursos. 31

58 3 Especificação do Sistema A cada curso é associado o utilizador que corresponde ao seu Coordenador, este vai ter acesso a alterar o seu nome, unidades curriculares, entre outras funcionalidades. Em cada cadeira é também definido o utilizador que corresponde ao seu docente responsável, este vai ter acesso a gerir todos os projetos ou trabalhos associados à/s cadeira/s que lhe correspondem Módulo de Artigos Figura 8 - Módulo Académico Neste módulo é feito o inventário de todos os artigos existentes nas Oficinas, desde componentes eletrónicos, esquipamentos informáticos e laboratoriais (Figura 9). Isto é possível devido ao facto de termos a possibilidade de associar um artigo a uma família e categoria previamente registadas. O inventário do tipo de artigos existentes nas oficinas é complexo e como tal ao invés de se associar o artigo a uma única tabela «Tipo» que seria uma abordagem mais simples e lógica, existiu a necessidade de o relacionar com duas tabelas distintas categoria e família, desta forma temos acesso a dois níveis de especificação, simplificando a sua procura e perceção. De referir que os serviços são também registados na tabela «Artigo» tendo depois uma categoria associada específica. Um artigo pode ter diversos locais de armazenamento com diferentes partições, gavetas, armários e salas. Tal complexidade deve-se ao facto dos componentes eletrónicos serem de tamanho reduzido e como tal estão organizados em grandes armários com pequenas gavetas divididas em diferentes partições. Registou-se a unidade de medida associada aos artigos visto os mesmos poderem ser quantificados de diversas formas, como através do peso ou unidade. 32

59 Sistema de Gestão Para Oficinas de Eletrónica Figura 9 - Modulo de Artigos Como ao longo do tempo os preços de venda dos artigos são variáveis foi criada uma tabela «Preço de Venda» independente, desta forma tem-se um registo da variação do 33

60 3 Especificação do Sistema preço e mante-se a informação relativa às vendas de forma persistente ao longo do tempo. Assim como o preço de venda, o valor de compra sofre o mesmo tipo de alterações, desta forma regista-se o preço de compra na tabela «Preco_Fornecedor» sendo este associado ao fornecedor correspondente Módulo de Documentos Neste módulo são registados todos os documentos associados ao registo de transações ou serviços efetuados nas Oficinas desde, compras, requisições, pedidos de reparação, reparações, devoluções de requisições e baixas de artigos. A definição do tipo de documento é feita pelo relacionamento com a tabela «Tipo de Documento» (Figura 10). Figura 10 - Módulo de Documentos Para uma melhor explicação da utilização destas tabelas será apenas exemplificado o processo de registo de uma compra. Esta é composta por uma série de cabeçalhos com diferentes dados correspondentes à tabela «Documento», e um conjunto de diversos artigos ou serviços com preços unitários associados. Este conjunto de artigos ou serviços é representado por meio de uma tabela intermediária «LinhaDocumento», isto porque uma compra pode ter diversos artigos assim como um artigo pode estar associado a diversas 34

61 Sistema de Gestão Para Oficinas de Eletrónica compras. A abordagem foi inspirada na fatura como documento físico onde podemos identificar o cabeçalho com todas as informações do vendedor e comprador e posteriormente todos os artigos associados em diferentes linhas com as suas quantidades. No topo da tabela «Documento» existem três relacionamentos ligados à tabela «Utilizador». Estes relacionamentos registam interações entre os diferentes utilizadores e o documento associado. No registo de uma requisição de artigos, os relacionamentos registam o utilizador que efetua o registo, o utilizador que regista o levantamento dos artigos nos balcões das oficinas e em terceiro, o cliente para quem se dirige a requisição no caso da mesma ser registada pelos funcionários em nome de outro utilizador. Também é possível verificar a existência de um auto relacionamento entre a tabela «Documento». Este serve para associar as devoluções ou baixas relativas a uma requisição. Uma requisição pode também ser registada em nome de um grupo de trabalho por meio do relacionamento correspondente. É ainda guardado o projeto ao qual a requisição pertence. Por meio deste relacionamento conseguimos saber também qual a cadeira e curso associados. No registo de uma compra é possível associar o fornecedor correspondente por meio de um relacionamento com a tabela «Fornecedor» Modelação Funcional A modelação funcional é mais um dos passos fulcrais na engenharia de requisitos, com esta pode-se definir de forma simples as diferentes funções e forma de navegação a implementar no software com base na análise de requisitos feita. Neste trabalho a técnica de modelação escolhida foi a de Casos de Uso que consta na linguagem de modelação UML2 (Booch, Rumbaugh, & Jacobson, 1999). Existem dois tipos de diagramas de Casos de Uso, de Negócio onde se representa o conjunto de serviços presentes numa organização como um todo e de Aplicação que mostram um conjunto de atores externos e a sua ligação aos casos de uso fornecidos pelo sistema. Neste projeto apenas vai ser utilizado o segundo tipo visto o modelo de negócio das oficinas ser de simples perceção. Os casos de uso são um conjunto de diagramas que têm como objetivo mostrar o que um sistema deve fazer e não como o mesmo deve ser desenvolvido. Segundo (Arlow & Neustadt, 2006) a modelação de casos de uso é uma forma diferente e complementar de 35

62 3 Especificação do Sistema obter e documentar requisitos. Esta modelação é feita descobrindo as fronteiras do sistema, atores, casos de uso e fluxos, é feita por meio de interações até se chegar a uma versão estável. Os atores definem quais são os perfis de utilizadores do sistema, os casos de uso as funcionalidades a implementar, os fluxos as diferentes formas de navegar entre funções (casos de uso) e as fronteiras definem o âmbito do sistema ou seja até onde é necessário modelar o sistema. No desenvolvimento do SGOE a recolha e análise dos casos de uso foi feita iterativamente com os utilizadores finais. Inicialmente foi feita uma folha de cálculo com todos os atores e casos de uso encontrados e seguidamente discutida e apresentada pela equipa de desenvolvimento aos utilizadores. Após se ter chegado a um consenso ao nível da folha de cálculo passou-se então ao desenho e apresentação dos diagramas correspondentes até se chegar novamente a um modelo estável. Nos casos de uso mais complexos foi feita a especificação por meio de diagramas de sequência. Os diagramas de sequência representam o comportamento do sistema, mostram as interações entre os utilizadores e os componentes do sistema, isto é, uma sequência de mensagens trocadas entre vários objetos num determinado contexto. Os diagramas de sequência permitem descrever uma sequência em particular, um caso de uso, e não muitos casos de uso de uma vez. Para uma melhor apresentação e explanação dos casos de uso o diagrama principal foi dividido em módulos visto o número de casos de uso ser bastante extenso e complexo. Observa-se no Anexo 1 Erro! Fonte de referência não encontrada.os diferentes módulos e quais são de acesso público e privado por meio da associação «include» ou «extend». Ao longo do documento vai-se explicando caso a caso o funcionamento de cada módulo de forma individual. Ao nível dos utilizadores do sistema foram identificadas as seguintes entidades listadas de forma hierárquica: - Utilizador não autenticado, - Cliente; - Aluno; - Docente; - Funcionário; - Chefe de oficina; - Administrador. 36

63 Sistema de Gestão Para Oficinas de Eletrónica Os utilizadores não autenticados são todos aqueles que visitam a página e têm acesso à informação pública. Todos os utilizadores têm acessos distintos ao sistema dependendo do nível hierárquico. Subindo ao longo da escala hierárquica as entidades vão herdando o acesso às funcionalidades cujos níveis abaixo já obtinham. Ao longo dos diagramas será representado o conjunto de casos de uso estudados e entidades com o nível hierárquico mais baixo a ter acesso aos mesmos. Todas as entidades que tenham um nível hierárquico acima da entidade representada no respetivo diagrama também têm acesso à funcionalidade descrita Módulo de Funcionalidades Publicas Neste módulo qualquer utilizador com acesso à internet tem acesso a estas funcionalidades. Todo e qualquer utilizador não autenticado que tenha uma ligação à internet pode aceder a informações sobre a instituição e instruções de utilização básicas. Figura 11 - Módulo de Funcionalidades Públicas Um utilizador não autenticado tem acesso a visualizar os conteúdos existentes nas páginas «Home» e «About», pode efetuar o Login no caso de ter as suas credenciais de acesso pessoais. Um utilizador não registado caso deseje pode-se registar unicamente como cliente e ter acesso às restantes funcionalidades privadas (Figura 11). Para se registar como um utilizador de diferentes tipos só por intermédio do backoffice nos balcões das Oficinas. 37

64 3 Especificação do Sistema Módulo de Gestão de Utilizadores Neste módulo o chefe de oficina tem acesso ao registo e edição de um utilizador, fornecedor ou grupo de trabalho (Figura 12). Para um acesso mais eficiente da informação foi criado o caso de uso «Detalhes», desta forma o utilizador inicialmente tem acesso à Figura 12 - Módulo de Gestão de Utilizadores lista de utilizadores, fornecedores ou grupos com a informação mais relevante e caso o deseje tem acesso a informação mais detalhada de um dos registos à sua escolha. De referir que os administradores do sistema também têm acesso a estas funcionalidades. 38

65 Sistema de Gestão Para Oficinas de Eletrónica Módulo de Área Pessoal Neste módulo o utilizador tem acesso à sua conta corrente pessoal, onde pode ver todas as requisições e reparações de forma detalhada, visualizando todos os serviços e artigos associados. Pode também alterar a sua password ou dados pessoais (Figura 13). De referir que todo e qualquer utilizador tem acesso a estas funcionalidades. Figura 13 - Módulo de Área Pessoal Módulo de Gestão Académica Neste módulo o docente, Chefe de Oficina ou Administrador têm acesso à gestão de toda a componente académica, nomeadamente dos Cursos, Cadeiras e Projetos de desenvolvimento (Figura 14). Mais uma vez foi aplicada a funcionalidade de informação detalhada unicamente para os cursos, por ser o único registo com mais informação específica a expor ao utilizador. 39

66 3 Especificação do Sistema Figura 14 - Módulo de Gestão Académica Módulo de Gestão de Artigos Neste módulo qualquer utilizador pode visualizar informações relativas a artigos, contudo apenas o chefe de oficina pode criar e editar um artigo. Somente o chefe de oficina e funcionário podem ciar um código de barras único associado a um artigo (Figura 15). Figura 15 - Módulo de Gestão de Artigos 40

67 Sistema de Gestão Para Oficinas de Eletrónica Módulo de Gestão de Categorias de Artigos Neste módulo o utilizador do tipo cliente pode visualizar as categorias e os artigos associados, pode também ver a sua informação de forma mais detalhada. Apenas o chefe de oficina e administrador podem criar ou editar categorias (Figura 16). Figura 16 - Módulo de Gestão de Categorias de Artigos Módulo de Gestão de Famílias de Artigos Neste módulo tal como no anterior o cliente pode visualizar todas as famílias de artigos, mas apenas o chefe de oficina as pode criar ou editar (Figura 17). Figura 17 - Módulo de Gestão de Famílias de Artigos 41

68 3 Especificação do Sistema Módulo de Gestão de Unidades de Medida de Artigos Neste módulo é feito o acesso à gestão das unidades de medida associadas a artigos (Figura 18). Apenas o Chefe de Oficina e Administrador podem listar, criar e editar unidades de medida. Figura 18 - Módulo de Gestão de Unidades de Medida de Artigos Quando é criado um novo artigo, o Chefe de Oficina pode selecionar uma das unidades de medida registadas neste módulo Módulo de Gestão de Locais de Armazenamento Quanto aos locais de armazenamento dos diferentes artigos, a sua visualização é possível pelos funcionários, chefes de oficina e administradores. Já o seu registo e edição, só são possíveis pelos chefes de oficina e Administradores. Neste caso, como é possível obter vários locais de armazenamento para o mesmo artigo o registo é feito de forma diferente do caso das unidades de medida (Figura 19). Quando é registado um novo local Figura 19 - Módulo de Gestão de Locais de Armazenamento 42

69 Sistema de Gestão Para Oficinas de Eletrónica de armazenamento, seleciona-se o artigo correspondente, devendo este estar previamente registado. Também é possível criar o registo do local de armazenamento e só posteriormente associar o artigo, por meio da edição Módulo de Gestão de Preços Através do módulo de Gestão de Preços é possível gerir os preços de compra e venda dos diferentes artigos (Figura 20). A listagem, registo e edição de preços só pode ser feita pelo Chefe de Oficina e Administrador, contudo qualquer utilizador quando regista uma requisição ou visualiza o seu processo de reparação de um determinado item tem acesso aos preços de venda individuais e totais associados. Figura 20 - Módulo de Gestão de Preços 43

70 3 Especificação do Sistema Módulo de Gestão de Compras O módulo de Gestão de Compras oferece o acesso a todas as compras registadas em formato de lista ou individualmente de forma detalhada. É possível também o seu registo e edição, onde se seleciona o fornecedor e preço previamente registados (Figura 21). Figura 21 - Módulo de Gestão de Compras Módulo de Gestão de Requisições Neste módulo, é feita a gestão de requisições de componentes e equipamentos laboratoriais por parte dos alunos para uso nas unidades curriculares lecionadas na universidade (Figura 22). O aluno pode criar a sua requisição on-line e editar a mesma até ao ato de levantamento dos artigos. O levantamento é registado pelo funcionário assim que o aluno se desloca às instalações das Oficinas e recolhe os artigos requisitados. A devolução dos artigos é obrigatória após o aluno terminar o seu trabalho ou ter atingido o prazo limite para finalizar o projeto. A devolução é registada pelo funcionário assim que o aluno entrega os respetivos itens que requisitou. No caso de existirem artigos danificados também é feito o registo da baixa destes. Tanto no caso de devolução ou de baixa do artigo, o registo é associado à requisição previamente efetuada e reciprocamente ao aluno ou grupo que a efetuou. Também é possível ao funcionário registar a requisição no ato de levantamento no caso de o aluno, por algum motivo, não o ter feito previamente, o que é ligeiramente contraproducente e deve ser evitado a todo o custo pelos funcionários. 44

71 Sistema de Gestão Para Oficinas de Eletrónica Para uma melhor perceção do fluxo de trabalho efetuado ao longo do registo, levantamento e devolução de uma requisição, foram elaborados dois diagramas de sequência que nos apresentam, de forma gráfica e temporal, a ordem de trabalhos efetuada (Anexo 2 e Anexo 3). Figura 22 - Módulo de Gestão de Requisições Como é possível verificar para o registo de uma nova requisição em primeira instância é necessário que o utilizador efetue o login. De seguida preenche o respetivo formulário e vai adicionando artigos conforme necessita, sendo corrigidos os dados e verificados os campos obrigatórios assim que o utilizador adiciona um artigo, otimizando o processo de preenchimento com um feedback constante. O utilizador é sempre informado de forma explícita ao longo do processo de quais são os campos que estão mal preenchidos sendo identificado o problema que originou o erro. Caso não consiga corrigir o erro pode sempre cancelar a operação e prosseguir com o uso normal da aplicação. No caso do levantamento, em primeira instância, é obrigatório o registo da requisição pelo aluno ou funcionário. 45

72 3 Especificação do Sistema O funcionário tem a responsabilidade de periodicamente verificar a chegada de novas requisições, preparando o conjunto de artigos requeridos atempadamente. Desta forma assim que o aluno se dirige ao balcão das Oficinas já terá a sua requisição pronta e de forma rápida efetua o levantamento Módulo de Gestão de Reparações Neste módulo é feita a gestão de todos os pedidos de agendamento e execução de reparações efetuadas pelas Oficinas (Figura 23). Figura 23 - Módulo de Gestão de Reparações 46

73 Sistema de Gestão Para Oficinas de Eletrónica O cliente regista on-line o pedido de reparação para uma data à sua escolha, a mesma é seguidamente avaliada pelo funcionário. Este pode alterar a data conforme a disponibilidade das Oficinas e o grau de dificuldade da reparação, o mesmo é obtido por meio da descrição do Cliente, de seguida submete o pedido de reparação. Após este registo passa a ser registada uma reparação. Ao longo do processo o funcionário vai editando a reparação, adicionando os serviços ou artigos que foram necessários. O Cliente vai tendo acesso a toda esta informação ao longo do tempo. Assim que o Funcionário regista a reparação como terminada o cliente pode dirigir-se aos balcões das Oficinas e levantar o artigo já reparado. O funcionário além de ter acesso ao registo, edição e detalhes de reparações por meio de formulários, ainda o pode fazer por meio de um calendário gráfico. Desta forma tem um acesso mais fácil à marcação de reparações ao longo do tempo, podendo gerir de forma mais eficiente o tempo necessário e disponível para cada reparação registada, tendo acesso aos intervalos de tempo livres para registo de novas intervenções. Para uma melhor perceção das interações existentes ao longo do processo de uma reparação foram elaborados dois diagramas de sequência ilustrados nos Anexo 4 e Anexo Módulo de Apoio à Gestão Neste módulo é possível o acesso à informação de forma estruturada e relevante à gestão das Oficinas. É possível o acesso à conta corrente de qualquer utilizador, sabendo detalhadamente quais as requisições e reparações solicitadas, assim como todos os serviços e artigos associados. Tanto o Chefe de Oficina como o Administrador podem ter acesso a um relatório detalhado das saídas de artigos ou serviços efetuados, onde pode obter informações detalhadas como a data de operação, utilizador que efetuou a operação, registo, utilizador requerente, curso, tipo de pedido, quantidades, entre outros. 47

74 3 Especificação do Sistema O acesso à lista de devedores das Oficinas também é exequível, desta forma é possível ter acesso à informação detalhada de cada um dos diferentes utilizadores e tomar as devidas precauções. Dentro desta lista é posteriormente executável selecionar e notificar um conjunto de diferentes utilizadores da sua dívida e da obrigatoriedade de entregar ou pagar os respetivos artigos requeridos ou reparações de forma automática por via de (Figura 24) Conclusão Figura 24 - Módulo de Apoio à Gestão Neste capítulo fez-se a análise e especificação de requisitos do SGOE. Desta forma é possível evitar um conjunto de problemas associados desde sempre à engenharia de software. Ao longo do processo de desenvolvimento e decorrer das interações com todos os colaboradores do projeto, esta documentação é por diversas vezes alterada de forma a manter-se atualizada, correspondendo ao sistema no seu estado final. 48

75 4. Implementação do Sistema Para o desenvolvimento do SGOE serão necessárias diversas tecnologias orientadas ao paradigma Web. Visto este meio de comunicação ser extremamente complexo, com uma rede aberta ao mundo, diversos detalhes têm de ser discutidos na busca da melhor solução. Como tal vão ser descritos alguns dos conceitos e tecnologias utilizadas Mecanismos de Comunicação Segundo (Shklar & Rosen, 2009) o protocolo Hypertext Transfer Protocol (http) é a base da World Wide Web, trabalha na camada de aplicação no modelo Transmission Control Protocol/Internet Protocol (TCP/IP) usando o TCP na camada de transporte para transmitir mensagens. Este protocolo faz uso do paradigma pedido resposta ou seja a aplicação cliente envia uma mensagem de pedido HTTP ao servidor o qual retorna com uma mensagem de resposta. A estrutura das mensagens de pedido e resposta HTTP é similar às mensagens de . Consistem num conjunto de linhas no cabeçalho seguidas de uma linha em branco e de seguida no corpo da mensagem. O protocolo HTTP não guarda informações de estado é «Stateless», ou seja, uma transação consiste num único pedido por parte do cliente, seguido por uma única resposta por parte do servidor, contudo existem mecanismos que permitem contornar esta desvantagem Arquitetura do SGOE No desenvolvimento de uma aplicação Web standard a arquitetura utilizada baseiase em duas camadas distintas, a de aplicação e a de dados como se verifica na Figura

76 4 Implementação do Sistema Figura 25 - Aplicações 2Tier Neste projeto a arquitetura adotada será de 3 camadas seguindo o modelo Model View Controller (MVC), tendo como principal vantagem encapsular os dados da aplicação e disponibilizar uma maior flexibilidade na lógica de negócio por meio do controlador (Figura 26). Esta separação ajuda a gestão no desenvolvimento de uma aplicação, permitindo a concentração num aspeto de implementação de cada vez. Podendo-se por exemplo implementar o layout visual sem qualquer tipo de preocupação ao nível da lógica e dados. Figura 26 - Aplicações 3Tier 4.3. Segurança As aplicações Web funcionam num ambiente compartilhado, apesar de todas as vantagens que esta plataforma proporciona, a partilha de dados neste meio torna os dados mais vulneráveis a ataques. Com base em (Shklar & Rosen, 2009) o protocolo HTTP transmite as mensagens em texto aberto permitindo que qualquer fonte que intercete as mensagens de comunicação as consiga ler e alterar, pelo que surge a necessidade de criar mecanismos de segurança mais fiáveis por meio de controlo de acessos, meios de 50

77 Sistema de Gestão Para Oficinas de Eletrónica comunicação cifrados e certificados de identificação digitais. Nas aplicações Desktop, uma vez que os dados são mantidos na máquina local, são menos suscetíveis de ataque no acesso à informação. No SGOE toda a informação é trocada por meio de protocolos de comunicação seguros. Foram adotados mecanismos via HTTPS que acrescentam o protocolo Transport Layer Security (TLS) na camada de transporte, encriptando os dados na comunicação entre cliente e servidor por meio de algoritmos de chave pública. Ao nível da base de dados as passwords encontram-se cifradas impedindo que no caso da aplicação sofrer algum tipo de invasão as mesmas não estejam expostas em texto limpo Tecnologias Utilizadas NET A framework.net é um meio de execução e gestão de aplicações em funcionamento contínuo. Disponibiliza a gestão de memória e outros serviços do sistema por meio do Common Language Runtime (CLR) e uma extensa biblioteca de funções que permite aos programadores tirar proveito de código robusto e fiável para grande parte das principais áreas de desenvolvimento de aplicações por meio da.net Framework Class Library. O CLR é também o verdadeiro responsável pela interoperabilidade entre as linguagens suportadas pela plataforma.net como é o caso do Visual Basic, C#, C++, F#, J# entre outras, nas suas diferentes versões. Permite a execução das aplicações.net em diferentes plataformas como Windows 7, Windows 8, Windows Phone e Xbox ASP.NET MVC A framework ASP.NET MVC fornece uma alternativa ao padrão Web Forms ASP.NET para desenvolvimento de aplicações Web. É uma framework de apresentação leve e altamente robusta que tal como com as aplicações Web Forms-based é integrada com recursos ASP.NET. Segue o padrão MVC, como tal a separação existente entre as diferentes camadas oferece maior controlo sobre partes individuais do projeto, o que permite mais facilmente desenvolver, modificar e testar a aplicação. Esta divisão também permite o desenvolvimento de aplicações de uma forma mais orientada aos processos existentes no seio das entidades/empresas, onde se apresenta o interface gráfico na camada 51

78 4 Implementação do Sistema View, os processos de negócio na camada Controler, a estruturação e registo de dados na camada Model C# Para o desenvolvimento de toda a lógica da aplicação do lado do servidor foi utilizada a linguagem C# que é parte integral da tecnologia ASP.NET MVC. É uma linguagem de programação orientada a objetos, compilada, fortemente tipada, desenvolvida pela Microsoft como parte da plataforma.net. O C de C#, assim como o C de C++, e de Objective-C não são por acaso. A sintaxe é inspirada na linguagem C Javascript JavaScript é uma linguagem script/interpretada, orientada a objetos e multiplataforma. É uma linguagem leve e com uma estrutura pequena. Não é útil como linguagem standalone, mas é desenhada para fácil integração em outros produtos ou aplicações, tais como Web Browsers. O JavaScript contém um conjunto de objetos tais como o Array, Data e Math, e um conjunto de elementos da linguagem como operadores, controlo de estruturas e declarações. Pode ser estendido para diversos propósitos gerando e manipulando objetos adicionais. As extensões cliente-side possibilitam colocar elementos num formulário HTML em resposta a eventos do utilizador como operações com o rato, inserção de dados ou navegação na página. O JavaScript Server-side estende a linguagem principal, manipulando ou criando objetos relevantes à aplicação, podendo por exemplo manipular dinamicamente ficheiros HTML Jquery JQuery é uma biblioteca JavaScript multi-browser desenvolvida para simplificar os scripts client side desenvolvidos em JavaScript que interagem com o HTML. As mesmas permitem o processamento de diversas operações no browser do cliente. Desde animações, cálculos, operações assíncronas ou interfaces mais ergonómicos facilitando o desenvolvimento de aplicações Web dinâmicas. 52

79 Sistema de Gestão Para Oficinas de Eletrónica ASP ASP (Active Server Pages), foi o primeiro script engine do lado do servidor para dinamicamente gerar páginas Web. Faz uso de linguagens script como é o caso do JavaScript ou Microsoft Visual Basic Scripting Edition (VBScript). Com o ASP é possível combinar hipertexto com comandos script e componentes COM para criar páginas Web interativas. Assim como o desenvolvimento e alteração de aplicações Web complexas de forma mais fácil. É uma tecnologia extremamente útil efetuando grande parte do processamento da informação a apresentar ao cliente MS-SQL A tecnologia Microsoft SQL Server é um sistema de gestão de bases de dados relacionais desenvolvido pela Microsoft. Do ponto de vista da base de dados é uma aplicação cuja principal função é armazenar e retornar dados quando os mesmos são requisitados por outras aplicações, podendo as mesmas estar instaladas no mesmo computador ou numa outra máquina estabelecendo a comunicação por meio de uma rede. Existem diferentes versões do MS SQL Server cada uma desenvolvida para diferentes contextos e cargas de execução AJAX Asynchronous JavaScript + XML, embora não seja uma tecnologia por si só, é um termo utilizado em 2005 por Jesse James Garrett que descreve uma nova abordagem utilizando um conjunto de tecnologias existentes, incluindo o HTML ou XHTML, Cascading Style Sheets (CSS), JavaScript, The Document Object Model, XML, extensible Stylesheet Language for Transformation (XSLT) e a mais importante XMLHttpRequest Object. Quando estas tecnologias são combinadas no modelo AJAX, as aplicações Web são capazes de fazer alterações de forma rápida no interface do utilizador sem ser necessário voltar a descarregar toda a página Web. Isto torna a aplicação mais rápida e eficiente aos pedidos do utilizador. A aplicação passa a trabalhar de forma assíncrona. Embora o X em AJAX se refira a extensible Markup Language (XML), o JavaScript Object Notation (JSON) é mais utilizado do que XML atualmente por ser mais 53

80 4 Implementação do Sistema leve e parte integrante do JavaScript. Tanto JSON como XML são utilizados para transferir informação no modelo AJAX JSON JSON (JavaScript Object Notation) é um formato de texto para troca de dados extremamente eficiente. É de fácil leitura para humanos para ler e escrever, assim como é fácil para as máquinas de o analisar e gerar. É baseado num subconjunto do JavaScript. JSON é um formato de texto que é completamente independente de linguagens utilizando unicamente normas que são familiares aos programadores da família da linguagem C como o C, C++, C#, Java, JavaScript, Perl, Python, entre outras. Essas propriedades fazem do JSON o formato ideal para troca de dados LINQ A tecnologia Language-Integrated Query (LINQ) é uma extensão das linguagens C# ou VB que permite efetuar querys a bases de dados relacionais por meio do código. É possível criar expressões LINQ de duas formas, por meio de querys ou da Application Programming Interface (API). Desta forma é possível aceder e manipular dados complexos de forma extremamente intuitiva e eficiente sem ser necessário escrever qualquer código Structured Query Language (SQL). A ferramenta de desenvolvimento Visual Studio inclui as funcionalidades LINQ que possibilitam a manipulação de coleções na framework.net, bases de dados SQL, ADO.NET Datasets e documentos XML CSS Cascading Style Sheets (CSS) contêm regras de estilização que são aplicadas a elementos HTML numa página Web. Estes estilos definem como os diferentes elementos são apresentados e onde se devem posicionar na página. Quando se edita a apresentação de uma página Web, a mesma pode fazer-se de três formas, em linha, dentro de uma secção <style> numa página Web, ou dentro style sheet/documento CSS externo. 54

81 Sistema de Gestão Para Oficinas de Eletrónica Pagination Trata-se de uma classe previamente desenvolvida para plataforma ASP.NET MVC que permite navegar por meio de páginas nas diferentes linhas de informação a que acedemos, caso contrário o número de linhas apresentadas correspondentes a um conjunto de tabelas na base de dados seria enorme e pouco acessível Dynamic-Menu Este conjunto de classes com a biblioteca de funções HtmlHelper são capazes de dinamicamente criar um menu, que se encontra definido de forma persistente, num documento XML consoante o tipo de utilizador Action-Filter Este filtro de funcionalidades restringe o acesso a utilizadores não autenticados de realizar um conjunto de operações, mesmo que tenham acesso ao Uniform Resource Locator (URL) especifico da ação e façam um pedido HTTP por outro meio que não o interface da aplicação. No caso de acederem a determinada funcionalidade e não terem acesso por não estarem autenticados ou não terem permissões suficientes, a aplicação notifica o utilizador de que se trata de uma área restrita a utilizadores autenticados. É de salientar que este filtro é lançado em todas as ações que se deseje que não sejam públicas. Os acessos são definidos num documento XML onde estão especificados todos os acessos por tipo de utilizador relativos a cada ação Doodle Report É uma biblioteca de funções desenvolvida para a framework.net que permite criar diferentes relatórios do tipo Excel, PDF, HTML e Comma-Separated Values (CSV) por meio de querys efetuadas a qualquer coleção de dados por meio da tecnologia LINQ Integração do Sistema Sendo a necessidade de integrar as diferentes contas de utilizadores já registados no SIDE um dos principais requisitos para o SGOE, essa associação é feita por meio do 55

82 4 Implementação do Sistema serviço de diretorias em funcionamento na UTAD (Figura 27). Atualmente a autenticação dos utilizadores no SIDE é efetuada comunicando com o serviço de LDAP da UTAD. Este serviço de diretorias encontra-se hierarquicamente acima do SIDE tendo registados praticamente todos os utilizadores do sistema. O SGOE acede a este serviço da mesma forma que o SIDE, importando os dados do utilizador quando este efetua o login pela primeira vez. De seguida é apresentado um formulário onde se pede ao utilizador para complementar a informação já obtida no serviço LDAP. As credenciais de acesso mantêmse e não podem ser alteradas por meio do SGOE. Sempre que um utilizador pretende efetuar o login no SGOE, este efetua um pedido de aprovação ao serviço LDAP: Caso o utilizador exista no sistema e as credenciais de acesso correspondam, o mesmo retorna uma resposta positiva. O SGOE permite o registo de utilizadores externos à instituição. Desta forma o utilizador segue o processo de registo de novo cliente. Para se registar como um utilizador de tipo diferente esta ação só é possível por intermédio do responsável de oficina nos balcões das Oficinas da UTAD. Figura 27 - Arquitetura do SGOE Integrado com o Serviço LDAP 56

83 Sistema de Gestão Para Oficinas de Eletrónica 4.5. Instalação Para colocar em produção o SGOE, ainda numa versão protótipo, diversos procedimentos foram efetuados, de modo a permitir um início de utilização o mais estável possível, sem grandes problemas e que ofereça confiança aos utilizadores finais Inserção de Dados Como já referido no capítulo de introdução, anteriormente ao desenvolvimento deste projeto os funcionários das Oficinas desenvolveram uma base de dados na tecnologia Access onde foi efetuado o inventário de existências das Oficinas. Para uma maior acessibilidade e otimização no início da utilização da aplicação todos os dados foram replicados previamente para a base de dados do SGOE desenvolvida na tecnologia MS-SQL. A replicação foi feita ao nível do código, a aplicação acedeu à base de dados já existente, copiou, formatou e ajustou os dados à estrutura da nova base de dados (Figura 28). Como na nova base de dados a estrutura foi pensada e otimizada a outro nível, nesta fase acabou por se complicar mais o processo de replicação, tendo sido necessário imenso cuidado nos locais onde colocar os diferentes dados, evitando repetições e incoerências com as chaves estrangeiras e seus atributos associados, respeitando desta forma sempre a sua normalização. 57

84 4 Implementação do Sistema Figura 28 - Replicação de Dados Instalação da Aplicação e Base de Dados Para colocar em produção o SGOE foi necessário um servidor Web com o Windows Server e o Microsoft Internet Information Services (MS IIS) já instalados e um endereço Web/HTTP para acesso dos diferentes utilizadores à plataforma. Atualmente, por motivos de segurança visto a aplicação ainda se encontrar numa versão protótipo, o endereço fornecido apenas disponibiliza o acesso à plataforma por meio da rede interna da universidade ou externamente por meio da rede privada virtual (VPN). Para a aplicação aceder ao serviço LDAP foi também necessário permitir o acesso do servidor da aplicação SGOE ao servidor LDAP por meio de uma VPN interna que restringe acessos alheios a este serviço. Todos os dados de acesso encontram-se definidos num ficheiro XML que pode ser alterado e redefinido sempre que necessário. Para efetuar as diferentes notificações via o SGOE acede ao serviço de mail da universidade. O acesso a este serviço é feito unicamente dentro da rede interna com acesso restrito. Da mesma forma que no serviço LDAP os dados de acesso encontram-se guardados num ficheiro XML. A aplicação neste momento encontra-se alojada num servidor com o sistema operativo Windows Server 2008 de 64bit, com dois processadores Intel Xeon de 3.0GHZ com 4GB de RAM. 58