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     

15 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 Email    

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.

2.3. 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

16

contexto das Oficinas da UTAD. Desta forma obteve-se um panorama das melhores práticas e tecnologias utilizadas na atualidade.

2.3.1. 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

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

17

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.

2.3.2. 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.

18

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.

2.3.3. 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.

19

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

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.

20

2.3.4. 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.

21

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).

2.4. 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.

Página Sem Texto Propositadamente

23

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;

24

 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.