• Nenhum resultado encontrado

O Moodle (Modular Object Oriented Dynamic Learning Environment) é um software livre distribuído pela GNU, foi desenvolvido para a gestão do ensino-aprendizagem tendo como metodologia pedagógica o sócio construtivismo, no qual os participantes constroem conhecimentos colaborativamente interagindo com o ambiente, criado no ano de 1999 por Martin Dougiamas e desde então vem sendo desenvolvido colaborativamente pela comunidade de software livre que reúne milhares de profissionais de vários países (COLE; FOSTER, 2007).

Desenvolvido na linguagem de programação PHP, o Moodle é um sistema altamente portável tendo a possibilidade de instala-lo em diversos sistemas operacionais (Linux, Unix, Windows, Mac OS X). Além disso também trabalha com diversos bancos de dados como MySQL, PostgreSQL, Oracle entre outros. (FILHO, 2004). Concebido em uma

2Gráfico de Gantt é um gráfico usado para ilustrar o avanço das diferentes etapas de um projeto 3Wiki é utilizado para identificar qualquer coleção de documentos, uma enciclopédia online.

CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS 24

arquitetura baseada em componentes que vem facilitando o seu aprimoramento contí- nuo possibilitando incorporar módulos com novas funcionalidades, o que favorece a fácil adaptação do sistema às necessidades de seus usuários (MOODLE, 2015).

Atores

De acordo com a documentação4 oficial do Moodle, é possível criar usuários com maiores ou menores atribuições, ou seja, são diferentes níveis que possibilitam um usuário ter mais áreas acessíveis do que outro. por Padrão temos os seguintes atores que operam o sistema: Visitante, aluno, tutor, autor de curso, administrador representados pela figura 3.12.

Figura 3.12: Atores do Moodle.

1. Visitante: Têm a possibilidade de apenas visualizar o curso e seu conteúdo, ele não pode participar das atividades, se comportando apenas como um observador. 2. Aluno: É quem faz o curso, ele é quem recebe o conteúdo do professor, interage

com os colegas, ele envia material, contribui no fórum, vê suas notas, o curso é dado para ele.

3. Moderador: Geralmente é uma função dada à professores colaboradores, ou pro- fessores que apenas vão acompanhar o curso, ele não pode editar nenhum material. 4. Tutor: Quem produz o material e pode acrescentar os conteúdos no ambiente, ele quem molda o ambiente, tem atribuições de criar atividades, recursos, inserir alunos no curso que já estejam cadastrados no Moodle, configurar notas e o formato de curso que ele pretende que tenha seu curso.

5. Autor de curso: Tem as mesmas funções do professor, ele quem cria o curso por isso o nome diferente. Em um curso a distância é importante os alunos saberem com quem estão lidando, por isso o status, possibilitando que ele saiba quem é professor e quem é aluno.

6. Administrador: Quem tem as atribuições máximas no Moodle, ele pode configurar todo o ambiente, tanto a página inicial e as categorias de curso quanto os próprios cursos, ele tem possibilidade também de entrar como professores, alunos, o que é muito utilizado para testes. Geralmente sobre ele que cai a responsabilidade dos problemas que o ambiente venha a ter, ele quem tem atribuição de instalar o Mo- odle, quem tem acesso a senhas de FTP, de banco de dados, e quem pode baixar plugins, temas. Ele tem acesso a todas as áreas do ambiente, pode excluir e inserir usuários e dar suas atribuições, pode alterar materiais e organizar o ambiente.

Além desses atores e atribuições é possível também criar novos atores e definir suas áreas de acesso e permissões no sistema.

Módulo de Solicitação Externa - MSE

Este novo módulo é semelhante a um formulário web que foi desenvolvido e incorpo- rado no Moodle, pode ser acessado através de um botão chamado "Suporte"que pode ser requisitado pelo usuário a qualquer momento, pois este botão está disposto no canto su- perior direito da tela do Moodle. A Figura 3.13 ilustra os dados captados pelo formulário como nome, e-mail, telefone, assunto e detalhes.

Através deste formulário, os usuários do M oodle poderão comunicar-se diretamente com o setor de suporte da TI servindo de canal de comunicação direta, este novo canal de comunicação teve a necessidade de ser criado para ajudar os usuários com os possíveis problemas que eles venham enfrentar com o uso do moodle já que o SEDIS Solicitação não está acessivel a estes usuários.

O MSE vai atuar na captação de problemas técnicos de um publico alvo externo aos funcionários da SEDIS e injetar estas informações no SEDIS Solicitação através do IN- TEGRA para que elas sejam resolvidas pelos funcionários da TI.

O SEDIS Solicitação não atinge os usuários externos (alunos, professores e tutores) ficando limitado apenas aos funcionários internos da SEDIS, com a criação desse novo módulo, as informações captadas pelo MSE, serão injetadas no SEDIS Solicitações e tra- tadas como uma solicitação só que agora teremos esse novo status de solicitação externa.

Figura 3.13: Módulo de solicitação externa.

Padrão arquitetural

Aproveitando o padrão arquitetural desenvolvido pelos funcionários da TI, o MSE foi elaborado seguindo este padrão que é baseado em camadas(visualização e controle) que contém três componentes Form, View e Controller. O componente View é responsável

CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS 26

Figura 3.14: Arquitetura do Módulo de solicitação Externa.

por configurar algumas informações que serão úteis para identificar de onde a solicitação externa está sendo enviada e o usuário que a criou. Essa pré configuração é necessária pois a SEDIS possui diversos AVAs para cada tipo de cursos e treinamentos que ela oferece, o componente Form é responsável por montar os componentes HTML que compõem o formulário e o controlador executa as requisições da aplicação oriundas dos componentes Viewe Form.

A Figura 3.14 ilustra a relação das duas camadas e seus componentes, comparando este modelo arquitetônico com o do SEDIS Solicitação percebe-se a falta da camada de persistência, esta camada não será implementada no MSE pois os dados das solicitações externas serão exportados (persistidos) para o SEDIS Solicitação através do INTEGRA, no capítulo de desenvolvimento do middleware será detalhado com maiores informações essa etapa.

Desenvolvimento da proposta de

integração

Este capítulo apresenta a proposta de integração dos sistemas da SEDIS e o processo de negócio mostrando como os sistemas se correlacionam com os subsetores da TI (De- senvolvimento e Suporte) e as pessoas (papéis) das equipes. Logo depois é descrito a proposta do módulo de integração e como está sendo desenvolvida. Além disto, são apre- sentados a modelagem da aplicação por meio de diagramas da UML(Unified Modeling Language) e as estratégias de implementação envolvidas na solução do problema de inte- gração.

O departamento de Tecnologia da Informação - TI da SEDIS está dividido em três sub- setores: Desenvolvimento, Suporte e Coordenação de TI. O subsetor de desenvolvimento tem como objetivo analisar, projetar, implementar realizar manutenção e implementar soluções de softwares no ramo do ensino, pesquisa e extensão da SEDIS. Este setor é constituído por uma equipe multidisciplinar (programadores, analistas, web design, ad- ministrador de banco de dados e um coordenador) de profissionais da área de tecnologia da informação que executam todos os procedimentos necessários para o desenvolvimento e manutenção das soluções de TI da SEDIS.

O subsetor de suporte realiza atendimento ao usuário, manutenção de equipamentos de informática, administra e gerencia a rede e laboratórios de informática da SEDIS, este setor é constituído por uma equipe multidisciplinar (técnicos em manutenção de compu- tadores, técnicos de suporte ao usuário, técnicos de redes e um coordenador) de profissi- onais da área de tecnologia da informação.

O subsetor de coordenação de TI exerce um papel mais alto nível com a responsabili- dade de gerenciar projetos e os serviços de TI oferecidos pelo setor. Desse modo o gestor de TI atua na elaboração de projetos, implantação e gerenciamento.

4.1

Processo de funcionamento do setor de TI.

Um chamado técnico é iniciado quando os usuários externos (professor, tutor ou aluno) entra em contato com o subsetor de suporte por telefone ou e-mail. O atendente anota todos os dados do problema do usuário e dirige-se até o sistema SEDIS-Solicitação

CAPÍTULO 4. DESENVOLVIMENTO DA PROPOSTA DE INTEGRAÇÃO 28

para abrir uma solicitação com esses dados.

Caso o usuário seja algum funcionário (usuário interno) da SEDIS, ele terá acesso direto ao sistema e não precisa entrar em contato com a atendente. Os dados de uma solicitação são formados por: Data da solicitação, telefone para contato, assunto da soli- citação e detalhes (descrição do problema).

O coordenador do Suporte TI analisa todas as solicitações submetidas para distribuí- las entre os funcionários de TI que detêm o conhecimento adequado para resolvê-las. Estes funcionários são orientados a resolver as solicitações no menor tempo possível e caso não seja possível resolvê-las, é orientado a comentá-las para que o usuário de TI esteja sempre informado sobre o andamento da sua solicitação (OLIVEIRA et al., 2013). Vejamos o diagrama de atividades na Figura 4.1 que mostra o fluxo de controle deste processo.

Figura 4.1: Diagrama de atividades: Criação e atendimento de uma solicitação. Quando uma solicitação de serviço de TI é resolvida apenas no setor de suporte, o SEDIS Solicitações por si só atende muito bem a necessidade do SETOR finalizando ali mesmo o problema do solicitante. Mas nem sempre a resolução da solicitação acontece desta maneira e a resolução da solicitação necessita de esforços do setor de desenvolvi- mento, gerando demandas de trabalho para o este setor e criando uma relação de trabalho entre os setores. Ao se criar uma nova demanda para o setor de desenvolvimento, o

CAPÍTULO 4. DESENVOLVIMENTO DA PROPOSTA DE INTEGRAÇÃO 30

coordenador precisa criar uma tarefa no Redmine informando o tipo, título, descrição, si- tuação, prioridade, início, data prevista para término e para quem vai ser delegada a tarefa. A partir deste procedimento é que a solicitação pode começar a ser atendida pelo setor de desenvolvimento. Quando a tarefa for solucionada no Redmine, o coordenador do de- senvolvimento deve informar para o coordenador do suporte que a requisição do SEDIS Solicitação já foi atendida e que o coordenador do suporte pode fechar a solicitação no SEDIS Solicitação. Vejamos o diagrama de atividades na Figura 4.2 que trata bem este processo.

Figura 4.2: Estrutura de funcionamento entre o SEDIS Solicitação e o Redmine.

Documentos relacionados