Diffuse

 

 

iControl

 

 

 

Documento de Requisitos

 

 

 

 

 

Graduação em Engenharia e Ciência da Computação

Especificação de Requisitos e Validação de Sistemas (2005.2)

Prof. Jaelson Freire Brelaz de Castro

 

Diego Martins Vieira Barros

José Olino de Campos Lima Júnior

Saulo Lopes da Silva Oliveira

Turah Xavier de Almeida

 

 

 

 

 

1.     Introdução. 8

1.1.    Motivação. 8

1.2.    O Problema Identificado. 8

1.3.    Propósito do Documento de Requisitos. 9

1.4.    Escopo do Produto. 9

1.5.    Convenções e Termos. 10

1.6.    Referências. 11

1.7.    Visão Geral 11

2.     Descrição Geral 13

2.1.    Funções Gerais. 13

2.2.    Características dos Usuários. 13

2.3.    Suposições e Dependências. 13

3.     Requisitos do Software. 15

3.1.    Requisitos Funcionais. 15

3.1.1.      [RF01] Logar 15

3.1.2.      [RF02] Cadastrar equipamento. 15

3.1.3.      [RF03] Procurar equipamento. 16

3.1.4.      [RF04] Descadastrar equipamento. 16

3.1.5.      [RF05] Visualizar informações do equipamento. 16

3.1.6.      [RF06] Atualizar informações do equipamento. 16

3.1.7.      [RF07] Cadastrar saída de equipamento. 17

3.1.8.      [RF08] Cadastrar entrada de equipamento. 17

3.1.9.      [RF09] Listar equipamentos que se encontram no CIn. 17

3.1.10.    [RF10] Consultar histórico de entrada e saída de equipamentos. 18

3.1.11.    [RF11] Cadastrar permissão de saída de equipamento. 18

3.1.12.    [RF12] Procurar permissão de saída de equipamento. 18

3.1.13.    [RF13] Descadastrar permissão de saída de equipamento. 19

3.1.14.    [RF14] Visualizar permissão de saída de equipamento. 19

3.1.15.    [RF15] Atualizar permissão de saída de equipamento. 19

3.2.    Requisitos Não-Funcionais. 20

3.2.1.      Requisitos de Processo. 20

3.2.1.1.    [RNF01] Processo de Desenvolvimento. 20

3.2.1.2.    [RNF02] Linguagem de Programação. 20

3.2.1.3.    [RNF03] Modelagem.. 21

3.2.2.      Requisitos de Produto. 21

3.2.2.1.    Performance. 21

3.2.2.1.1    [RNF04] Tempo de Resposta. 21

3.2.2.1.2    [RNF05] Concorrência. 21

3.2.2.2.    Segurança. 21

3.2.2.2.1    [RNF06] Disponibilidade. 21

3.2.2.2.2    [RNF07] Confidencialidade. 22

3.2.2.3.    Usabilidade. 22

3.2.2.3.1    [RNF08] Ajuda online. 22

3.2.2.3.2    [RNF09] Mensagem de Erro. 22

3.2.2.3.3    [RNF10] Interface com o Usuário. 22

3.2.3.      Requisitos Externos. 23

3.2.3.1.    [RNF11] Tempo de Desenvolvimento. 23

3.2.3.2.    [RNF12] Custo. 23

4.     Modelagem Organizacional 24

5.     Modelagem dos Requisitos Não-Funcionais. 28

6.     Diagramas de Casos de Uso. 31

6.1.    Gerenciamento de equipamentos. 32

6.2.    Gerenciamento de permissões de saída de equipamentos. 33

6.3.    Fluxo de equipamentos. 33

6.4.    Consultas do sistema. 34

7.     Conclusão. 35

Apêndice A – Sobre o Centro de Informática. 36

Apêndice B – Coleta de Informações. 37

Apêndice C – Glossário. 39

Apêndice D – Detalhamento dos Casos de Uso. 40

[UC01] Logar 40

[UC02] Cadastrar equipamento. 41

[UC03] Procurar equipamento. 42

[UC04] Descadastrar equipamento. 42

[UC05] Visualizar informações do equipamento. 43

[UC06] Atualizar informações do equipamento. 44

[UC07] Cadastrar saída de equipamento. 44

[UC08] Cadastrar entrada de equipamento. 45

[UC09] Listar equipamentos que se encontram no CIn. 46

[UC10] Consultar histórico de entrada e saída de equipamentos. 46

[UC11] Cadastrar permissão de saída de equipamento. 47

[UC12] Procurar permissão de saída de equipamento. 48

[UC13] Descadastrar permissão de saída de equipamento. 48

[UC14] Visualizar permissão de saída de equipamento. 49

[UC15] Atualizar permissão de saída de equipamento. 50

 

Figura 1 - Modelagem SD do iControl 25

Figura 2 - Modelagem SR do iControl 27

Figura 3 - Grágico SIG do iControl 29

Figura 4 - Atores do sistema iControl 31

Figura 5 – Casos de uso do gerenciamento de equipamentos. 32

Figura 6 – Casos de uso do gerenciamento de permissões de saída de equipamentos  33

Figura 7 – Casos de uso do fluxo de equipamentos. 33

Figura 8 – Casos de uso das consultas do sistema. 34

 

Tabela 1 - Convenções e Termos. 10

Tabela 2 - Atores do sistema iControl 31

Tabela 3 - Glossário. 39

 

 

 

O custo de produção e desenvolvimento dos sistemas de informática e de eletrônica vem reduzindo a uma velocidade bastante alta, levando ao oferecimento de diversas vantagens a um número cada vez maior de instituições. Um sistema automatizado de controle do fluxo de equipamentos de uma instituição pode aproveitar de poderosas ferramentas para prover um controle mais rígido, aumentar a segurança e a agilidade nos processos envolvidos.

O projeto iControl tem o intuito de suprir essas necessidades, oferecendo facilidades não somente a funcionários da administração da instituição, como também às pessoas que necessitam de algum equipamento da instituição emprestado.

 

 

Como caso de estudo, foi tomado o Centro de Informática (CIn - UFPE). O sistema, porém, será elaborado visando-se uma possibilidade de extensão a outras instituições. O atual sistema de controle de fluxo de equipamentos do Centro será discutido em detalhes no Apêndice A. O processo de pesquisa e coleta de informações será detalhado no Apêndice B.

Para centros que possuam uma grande quantidade de equipamentos e que exista algum fluxo, um sistema de controle automático dos processos envolvidos torna-se indispensável. Além da falta de segurança, a ausência de um sistema de controle automático provoca um sensível atraso na liberação de um equipamento.

Entrevistas com funcionários revelaram a gravidade do fato: é comum ocorrer o furto de alguns equipamentos da instituição, revelando a gravidade de não haver um controle automatizado. Além do prejuízo financeiro, este fato pode até acarretar na paralisação de projetos de pesquisa.

Além dos furtos, há uma enorme burocracia para liberação de saída de um equipamento do Centro. O trabalho do suporte poderia ser facilitado com a implantação do sistema: uma permissão de saída de um equipamento poderia ser concedida remotamente (via Internet). Sendo assim, a automatização deste processo proveria um aumento no controle, na segurança e na agilidade no gerenciamento de equipamentos.

 

 

Este documento é destinado ao cliente e aos integrantes da equipe de desenvolvimento do projeto iControl, servindo como instrumento de comunicação importante, tanto entre o gerente do projeto e o cliente, quanto entre os desenvolvedores do sistema. Desta forma, o documento apresentará uma descrição das funções e serviços que o sistema deve proporcionar, além das restrições organizacionais que o sistema deve atender e algumas propriedades gerais.

 

 

Este projeto tem como objetivo automatizar o controle do fluxo de equipamentos da instituição, trazendo como benefícios o aumento na segurança, a minimização do tempo que atualmente é necessário para liberar o empréstimo de um equipamento e uma redução nas despesas decorrentes de eventuais furtos de equipamentos.

Para que este projeto seja corretamente desenvolvido, é preciso que já exista um sistema de informação com cadastro das pessoas e controle do fluxo destas no Centro, ao qual o iControl será integrado. Este sistema, chamado iM,  já foi desenvolvido para o CIn por alunos da graduação, onde a identificação dos usuários é feita com o uso de um leitor de impressão digital.

Através da Internet, os funcionários do suporte do Centro poderão conceder permissões para que usuários possam sair/entrar no CIn durante um período de tempo especificado, além de terem acesso a uma lista que conterá todos os equipamentos que estarão fora do Centro e os respectivos responsáveis.

 

 

Esta seção explica o conceito de alguns termos importantes e convenções que serão mencionadas no decorrer deste documento.

 

Tabela 1 - Convenções e Termos

 

 

[1].                  Estudo de Viabilidade do iControl:

http://www.cin.ufpe.br/~dmvb/icontrol/viabilidade.htm

[2].                  Site da disciplina de Especificação de Requisitos e Validação de Sistemas:

http://www.cin.ufpe.br/~if716

[3].                  SOMMERVILLE, Ian. Engenharia de Software. 6ª edição.

[4].                  KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering: Processes and Techniques. 1^st edition.

 

 

A estrutura deste documento será descrita a seguir:

·         A seção 1 apresentou uma introdução ao sistema iControl e ao documento de requisitos, tanto através de uma motivação e da identificação do problema na instituição onde foram coletadas as informações (detalhadas nos Apêndices A e B), como também descrevendo o escopo do produto, alguma convenções e termos utilizados e as referências;

·         A seção 2 apresenta uma descrição geral do sistema, através de funções gerais, características dos usuários, suposições e dependências;

·         A seção 3 apresenta os requisitos do software (funcionais e não-funcionais);

·         A seção 4 apresenta a modelagem organizacional usando a notação i*, através dos modelos de dependência estratégica e de razão estratégica;

·         A seção 5 apresenta a modelagem dos requisitos não-funcionais do sistema, feita através do NFR Framework;

·         A seção 6 apresenta os diagramas de casos de uso para as várias funcionalidades do sistema;

·         A seção 7 apresenta uma conclusão resumindo o conteúdo deste documento;

·         O Apêndice A apresenta o atual sistema de controle de fluxo de equipamentos no Centro de Informática;

·         O Apêndice B apresenta o processo de pesquisa e coleta de informações no Centro;

·         O Apêndice C apresenta um glossário com os termos técnicos usados neste documento;

·         O Apêndice D apresenta o detalhamento dos casos de uso do sistema.

 

 

 

Ao final da primeira versão do produto, as seguintes funcionalidades serão implementadas:

·         Cadastro de Equipamentos (inserção, remoção, atualização e consulta);

·         Cadastro de Permissões de Saída de Equipamentos (inserção, remoção, atualização e consulta);

·         Consulta de lista de equipamentos que foram emprestados e não se encontram na instituição;

·         Controle de fluxo (entrada/saída) de equipamentos;

·         Consulta de histórico de entradas e saídas de equipamentos.

Estas funcionalidades serão descritas com maior detalhe nas seções seguintes deste documento.

 

 

O sistema iControl possuirá dois tipos de usuários: ativos e passivos. Os usuários ativos serão os funcionários do suporte, enquanto que os usuários passivos serão as pessoas que trafegam pelo Centro e podem fazer empréstimos de equipamentos.

Para acessar o sistema, os usuários necessitarão de autenticação através de login e senha.

 

 

Para que o sistema iControl funcione corretamente, ele deverá ser integrado ao sistema iM, que já foi desenvolvido por alunos da graduação do Centro de Informática, que controla o fluxo de pessoas da instituição.

Além disso, o cliente contratante ficará responsável pela aquisição, caso necessário, de um servidor onde o sistema a ser desenvolvido será instalado.

 

 

Nesta seção, serão apresentados os requisitos funcionais, não-funcionais e organizacionais do sistema.

 

 

A seguir estão listados os requisitos que descrevem as funcionalidades do sistema.

 

 

O sistema deve permitir que usuários autorizados, neste caso os funcionários do suporte, tenham acesso às suas funcionalidades. Esta autenticação do usuário deve ser feita através do login e da senha do mesmo.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que ele forneça os seguintes dados do equipamento: nome, tipo do equipamento, status do equipamento, descrição, localização, projeto que o adquiriu, órgão financiador da compra (origem do equipamento), data da aquisição e ID da tag. No caso de PCs ou equipamentos que possuam recurso para comunicação, deverão também ser fornecidos os endereços IP e MAC dos mesmos. Em seguida, o sistema deverá mostrar uma mensagem indicando se o cadastro foi efetuado com sucesso. Se sim, o funcionário do suporte deverá fixar uma RFID tag ao equipamento cadastrado.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que a procura pelo equipamento seja feita por nome ou código do mesmo. Em seguida, o sistema deverá exibir uma lista com os equipamentos encontrados. 

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que ele escolha o(s) equipamento(s) que deseja descadastrar. Em seguida, o sistema deverá mostrar uma mensagem indicando se a remoção foi efetuada com sucesso.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que ele escolha o equipamento que deseja visualizar. Em seguida, o sistema deverá exibir uma tela com as informações do equipamento.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que as informações dos equipamentos sejam alteradas pelo funcionário do suporte quando o mesmo solicitar. Em seguida, o sistema deverá exibir uma tela para confirmação com as informações atualizadas. Por fim, o sistema deverá mostrar uma mensagem indicando se as alterações foram efetuadas com sucesso.

 

 

 

Quando a antena de RFID detectar a ID da tag de um equipamento, o sistema deverá verificar se o usuário possui permissão para sair do Centro portando o equipamento naquela data. Caso ele tenha permissão, o portão deverá ser aberto e o sistema deverá cadastrar a saída do equipamento. Como dados da saída serão cadastrados a data, a hora, o login do usuário e o código do equipamento.

 

 

 

Quando a antena de RFID detectar a ID da tag de um equipamento e o portão de entrada do Centro for aberto, o sistema deverá cadastrar a entrada do equipamento. Como dados da entrada serão cadastrados a data, a hora, o login do usuário portador do equipamento e o código do equipamento.

 

 

 

O funcionário do suporte que estiver logado no sistema, através da intranet do Centro, deverá poder obter uma lista de todos os equipamentos que se encontrarem no CIn.

 

 

 

O funcionário do suporte deverá estar logado no sistema. Ele deverá poder informar as datas de início e fim do período do qual deseja obter o histórico de entrada e saída de equipamentos. O sistema deverá, então, exibir uma lista com o histórico solicitado.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que ele forneça os seguintes dados da permissão de saída de equipamento a ser cadastrada: o código do equipamento, o login do usuário e o período de validade da permissão. O período de validade da permissão deve consistir de duas datas, uma de início e outra de fim da validade. Se uma permissão para o usuário sair com o equipamento especificado já estiver cadastrada, ela deve ser removida antes do cadastro da nova permissão. Por fim, o sistema deverá mostrar uma mensagem indicando se a permissão foi cadastrada com sucesso.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que a procura pela permissão seja feita por código do equipamento ou login do usuário. Em seguida, o sistema deverá exibir uma lista com a(s) permissão(ões) de saída de equipamento encontrada(s).

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que ele escolha a(s) permissão(ões) de saída de equipamento que deseja descadastrar. Em seguida, o sistema deverá mostrar uma mensagem indicando se a remoção foi efetuada com sucesso.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que ele escolha a permissão de saída de equipamento que deseja visualizar. Em seguida, o sistema deverá exibir uma tela com as informações dessa permissão.

 

 

 

O funcionário do suporte deverá estar logado no sistema. O sistema deverá permitir que as informações das permissões de saída de equipamento sejam alteradas pelo funcionário do suporte quando o mesmo solicitar. Em seguida, o sistema deverá exibir uma tela para confirmação com as informações atualizadas. Por fim, o sistema deverá mostrar uma mensagem indicando se as alterações foram efetuadas com sucesso.

 

 

 

Os requisitos que representam os aspectos não-funcionais do sistema serão apresentados a seguir. Eles foram divididos em três categorias: Requisitos de Processo, Requisitos de Produto e Requisitos Externos.

 

 

Os requisitos de processo são restrições que estão relacionadas com o processo de desenvolvimento do sistema.

 

 

O processo RUP será utilizado como metodologia de desenvolvimento do sistema.

 

 

 

A interface web do sistema será desenvolvida com uso de JSP (Java Server Pages), enquanto que o restante do sistema será desenvolvido utilizando a linguagem de programação Java.

 

 

 

O sistema deverá ser modelado utilizando a linguagem UML.

 

 

 

Os requisitos de produto são restrições que especificam as características desejadas que o sistema deve fornecer.

 

 

 

O sistema deverá responder às requisições dos usuários em um tempo não superior a 20 segundos.

 

 

 

O sistema deverá suportar a carga de até 50 acessos simultâneos.

 

 

 

 

O sistema deverá estar disponível 24 horas por dia.

 

 

Para terem acesso às funcionalidades do sistema, os usuários cadastrados deverão possuir login e senha.

 

 

 

 

O sistema deverá prover ajuda online aos usuários.

 

 

 

Caso um usuário acesse alguma funcionalidade de maneira indevida, a mensagem de erro exibida pelo sistema deverá ser construtiva e objetiva. Com isso, o usuário saberá como proceder e não terá dificuldades no uso desta funcionalidade.

 

 

 

O sistema deverá prover uma interface com o usuário que seja intuitiva, prática e fácil de usar.

 

 

 

Os requisitos externos são restrições derivadas do local que o sistema está sendo desenvolvido.

 

 

O tempo gasto com o desenvolvimento do sistema não deverá ser maior que 4 meses e 12 dias, ou seja, não deverá superar em 10% o tempo estimado no Estudo de Viabilidade do iControl [1].

 

 

 

O custo de desenvolvimento e manutenção do sistema não poderá exceder o valor de R$ 80.500,84 estimado no Estudo de Viabilidade do iControl [1].

 

 

 

A modelagem organizacional do iControl contém a descrição dos processos do sistema envolvendo vários atores. A técnica de modelagem utilizada neste documento é a técnica i* (istar). Nesta modelagem, serão apresentados o Modelo de Dependência Estratégica (SD) e o Modelo de Razão Estratégica (SR).

O Modelo de Dependência Estratégica do iControl consiste de uma descrição intencional dos processos do sistema em termos de uma rede de relacionamentos de dependência entre atores. Este diagrama é composto por três atores: o Professores/Alunos, o CIn e o iControl. Numa visão geral, os professores e alunos do Centro são representados pelo ator Professores/Alunos, enquanto que os funcionários do Centro são representados pelo ator CIn, que interage com o ator iControl. O ator Professores/Alunos interage com o ator CIn, já que ele é o responsável pelo gerenciamento dos equipamentos.

Os professores e os alunos têm a necessidade que o CIn empreste equipamentos e objetivam obter permissão de saída de equipamento.

O Centro de Informática objetiva otimizar o processo de empréstimo de equipamentos e gerenciar equipamentos, controlando o seu fluxo e, conseqüentemente, reduzindo os prejuízos com a provável redução dos furtos e empréstimos indevidos de equipamentos do Centro. Além disso, o CIn objetiva uma maior agilidade no processo de empréstimo de equipamentos e objetiva ter segurança em relação às informações que são disponibilizadas e armazenadas pelo sistema. Todos esses objetivos satisfeitos através de um sistema que tenha um bom grau de usabilidade e uma boa performance.

A seguir encontra-se o modelo SD do iControl.

 

Figura 1 - Modelagem SD do iControl

 

O Modelo de Razão Estratégica (SR) do iControl consiste de uma descrição intencional dos processos em termos de elementos dos processos e as razões que estão por detrás deles.

O objetivo do Centro de Informática de “Cadastro de equipamentos” é representado pela composição das seguintes tarefas: “Inserir novos equipamentos”, “Consultar equipamentos emprestados”, “Verificar prazo de entrega equipamentos” e “Tratar pedidos de permissão”, que por sua vez contém a tarefa “Liberar equipamento”.

Os objetivos do CIn “Gerenciar equipamentos”, “Reduzir prejuízos”, “Controlar fluxo de equipamentos” e “Agilidade no processo de empréstimo de equipamentos”, são atingidos através do objetivo “Tratar pedidos”, que é representado pela tarefa “Pedido equipamento”.

A tarefa “Pedido equipamento” é decomposta em quatro sub-tarefas:

·         Consultar equipamento;

·         Atualizar equipamento;

·         Inserir equipamento;

·         Remover equipamento.

Por fim, o objetivo “Segurança” pode ser atingido através do objetivo “Garantir segurança das transações”, que por sua vez é conquistado pela tarefa “Controlar acesso e transações”, que é dividida nas seguintes sub-tarefas:

·         Exigir login e senha dos usuários;

·         Armazenar log das transações.

O modelo SR do iControl pode ser visualizado em seguida.

 

Figura 2 - Modelagem SR do iControl

 

 

Nesta seção do documento, apresentamos a modelagem das qualidades gerais do iControl, os Requisitos Não-Funcionais (NFR), que foram modelados através do gráfico SIG (Softgoal Interdependency Graph), utilizando a ferramenta NFR Framework.

Os tipos de requisitos não-funcionais do sistema são: Performance (Tempo de Resposta e Concorrência), Usabilidade, Custo, Tempo e Segurança (Disponibilidade e Confidencialidade).

O gráfico SIG ilustra o inter-relacionamento entre os requisitos não-funcionais do sistema apresentados nas seções anteriores, em particular os requisitos de produto e os requisitos externos.

Neste grafo, que será exibido em seguida, podemos visualizar a decomposição e operacionalização dos requisitos não-funcionais, bem como contribuições (positivas ou negativas) e prioridades.

 

Figura 3 - Grágico SIG do iControl

 

O softgoal Performance é decomposto nos softgoals Tempo de Resposta e Concorrência, que são operacionalizados por Execução de testes para localizar pontos de otimização e Servidor com boa capacidade de memória e processamento, respectivamente.

O softgoal Segurança é decomposto nos softgoals Disponibilidade e Confidencialidade. A segurança é o softgoal prioritário do sistema. A Disponibilidade é operacionalizada por Replicação do servidor e Utilização de no break no servidor. A Confidencialidade é operacionalizada por Mecanismo de controle de acesso, que por sua vez é uma junção das operacionalizações Exigir login e senha e Armazenar log das transações. Esta última operacionalização contribui negativamente no Tempo de Resposta.

O softgoal Usabilidade é operacionalizado por Ajuda online, Mensagens de erro construtivas e Interface intuitiva.

Os softgoals Custo e Tempo representam os requisitos não-funcionais externos do sistema.

O Custo é operacionalizado por Planejamento detalhado e Cronograma bem elaborado, enquanto que o Tempo é operacionalizado por Supervisão do desenvolvimento e Cronograma bem elaborado.

 

 

Tabela 2 - Atores do sistema iControl

 

Figura 4 - Atores do sistema iControl

 

Os diagramas de casos de uso modelados a seguir foram separados de acordo com as funcionalidades do sistema. O detalhamento de todos os casos de uso encontra-se no Apêndice D deste documento.

 

 

Figura 5 – Casos de uso do gerenciamento de equipamentos

 

 

Figura 6 – Casos de uso do gerenciamento de permissões de saída de equipamentos

 

 

Figura 7 – Casos de uso do fluxo de equipamentos

 

 

Figura 8 – Casos de uso das consultas do sistema

 

 

Este documento será utilizado não só por toda a equipe, como também pelo cliente. Ele servirá como guia durante as etapas do desenvolvimento do sistema iControl, já que aqui estão apresentados todos os requisitos acordados com o cliente. As possíveis modificações deverão ser descritas no histórico de versões.

Além disso, deverá ser respeitada a coerência entre o sistema que será desenvolvido e todos os requisitos descritos neste documento.

Para possibilitar uma melhor visualização do sistema pelo leitor, foram feitas as seguintes modelagens: diagramas de casos de uso, modelagem organizacional e modelagem dos requisitos não-funcionais.

 

 

Apêndice A – Sobre o Centro de Informática

 

Apesar de ser um dos mais novos da UFPE (criado oficialmente em 1999), o CIn conta com a expertise de mais de 25 anos de funcionamento, já que é a evolução natural do antigo Departamento de Informática.

Hoje, atuam no corpo docente do CIn 46 doutores. Estão matriculados no Centro cerca de 600 alunos de graduação, 123 de mestrado, 65 alunos de doutorado e 165 de especialização. A Infra-Estrutura do CIn conta com mais de 500 pontos de trabalho interligados em Rede, distribuídos nos 15 laboratórios, nas salas de aulas e dos professores. Além dos pontos de trabalho, o Centro possui diversos equipamentos de alta tecnologia, que são usados em pesquisas e no ensino.

O controle dos equipamentos é feito diretamente pelo suporte do CIn, que se encarrega de localizar, obter informações e controlar o registro dos equipamentos.  Permissões de saídas com equipamentos, porém, são dadas pelos coordenadores de infra-estrutura: André Santos e Carlos Ferraz. Quando um usuário quer requisitar a permissão, ele deve entrar com contato um dos coordenadores, que irá conceder a permissão. É registrada, em papel, a data e hora em que foi concedida a permissão e, após o retorno, a data e hora em que o equipamento foi devolvido.

Além da falta de agilidade do processo, os equipamentos ficam bastante susceptíveis a furtos. O sistema de segurança atual se restringe ao uso de câmeras, que não se encontram distribuídas em todos os ambientes do Centro. No caso de um tipo de equipamento que se encontra em grande número, a ausência de um determinado equipamento pode passar muito tempo despercebida.

 

 

Apêndice B – Coleta de Informações

 

O processo de coleta de informações se iniciou após a definição do problema (prover um maior controle, segurança e agilidade no gerenciamento de equipamentos). A partir daí, foi necessária a escolha de alguma instituição como estudo de caso.

Como mencionado anteriormente, foi escolhido o Centro de Informática. A escolha se deu devido às adequações do Centro ao problema (grande número de usuários e equipamentos e existência de um fluxo) e também devido ao contato com os funcionários do Centro.

Inicialmente foi contactada Marlice Novais de Oliveira, que faz parte do suporte do Centro. Ela nos forneceu informações sobre a hierarquia da organização, indicando os envolvidos nos vários processos que envolvem equipamentos. Foi ela que nos recomendou entrar em contato com alguém da Oficina para saber mais detalhes.

Em seguida, foi entrevistado o funcionário Júlio Guilherme Glasner de Maia Chagas. O Sr. Júlio faz parte do grupo de funcionários da Oficina, e trabalha diretamente com os equipamentos. Ele coordena não só a manutenção, mas a localização e registro de saída de equipamentos.

As dúvidas mais importantes apresentadas aos funcionários foram:

 

Como funciona atualmente o processo de entrada e saída de equipamentos?

Como é concebida uma permissão de saída com equipamento?

Quais são as maiores dificuldades dos processos envolvidos?

Há algum sistema automatizado envolvido?

O sistema atual é vulnerável (susceptível a furtos)?

Quais reclamações vocês costumam ouvir?

 

Para obter informações sobre o iM, sistema de gerenciamento e identificação de usuários criados por alunos, foram entrevistados João Fernando Bione e Diogo Maciel Guimarães, que fizeram parte do grupo de desenvolvimento do sistema. Eles forneceram informações importantes sobre o sistema, como: arquitetura e descrição dos módulos. Além disso, puderam ajudar a verificar a viabilidade da extensão do sistema, dando sugestões de como proceder.

 

 

Apêndice C – Glossário

 

A seguir estão descritos os termos inerentes ao contexto do projeto.

 

Tabela 3 – Glossário

 

 

Apêndice D – Detalhamento dos Casos de Uso

 

 

Pré-condições: O funcionário do suporte deverá estar cadastrado no sistema.

Pós-condições: Funcionário do suporte logado no sistema.

Requisitos Associados: RF02

Fluxo de eventos principal:

1.     O sistema exibe uma página com os campos “Login” e “Senha”;

2.     O funcionário do suporte preenche os campos “Login” e “Senha” e clica no botão “Entrar”;

3.     O sistema verifica se o login e senha fornecida são válidos [FS01] [FS02];

4.     Se a senha e o login estiverem corretos, o funcionário do suporte é logado no sistema;

5.     Encerra-se o caso de uso.

 

[FS01] Usuário inexistente

1.     Este fluxo secundário se inicia ao verificar que o login fornecido na operação de autenticação não está cadastrado no sistema;

2.     O sistema exibe novamente a página de autenticação com a mensagem “Usuário inexistente” próximo ao campo de login;

3.     Retorna ao passo 4 do fluxo principal e encerra-se o fluxo secundário.

 

[FS02] Senha incorreta

1.     Este fluxo secundário se inicia ao verificar que a senha fornecida na operação de autenticação está inconsistente com a senha cadastrado no sistema sob aquele usuário;

2.     O sistema exibe novamente a página de autenticação com a mensagem “Senha incorreta” próximo ao campo de senha;

3.     Retorna ao passo 4 do fluxo principal e encerra-se o fluxo secundário.

 

 

Pré-condições: O funcionário do suporte deverá estar logado no sistema.

Pós-condições: O equipamento é adicionado ao sistema.

Requisitos Associados: RF02

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte selecionar a opção “Cadastrar equipamento” dentro do menu “Equipamentos”;

3.     O sistema exibe uma página requisitando:

a.     Nome;

b.     Tipo;

c.      Status;

d.     Descrição;

e.     Localização;

f.       Projeto;

g.     Origem;

h.     Data de aquisição;

i.        ID da tag;

j.       Endereços IP e MAC (apenas no caso de PCs ou equipamentos que possuam recurso para comunicação).

4.     O funcionário do suporte entra com os dados do equipamento e clica no botão “Continuar” [FS03];

5.     O sistema gera um código para o equipamento, que será o identificador único do mesmo;

6.     O sistema exibe uma tela solicitando que a RFID tag correspondente seja fixada no equipamento;

7.     O funcionário do suporte fixa a RFID tag solicitada no equipamento;

8.     O equipamento é cadastrado no sistema;

9.     O sistema exibe uma página de confirmação;

10.                       Encerra-se o caso de uso.

 

[FS03] Cancelar operação

1.     Este fluxo secundário tem início quando o funcionário do suporte clica no botão “Cancelar”;

2.     O sistema retorna à página inicial;

3.     Encerra-se este caso de uso.

 

 

Pré-condições: O funcionário do suporte deverá estar logado no sistema.

Pós-condições: Não se aplica.

Requisitos Associados: RF03

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte selecionar a opção “Procurar equipamentos” dentro do menu “Equipamentos”;

3.     O sistema exibe uma página onde devem ser escolhidos o tipo da procura (nome ou código) e o seu conteúdo;

4.     O usuário clica no botão “Procurar”;

5.     O sistema exibe uma página com todos os equipamentos encontrados;

6.     Encerra-se este caso de uso.

 

 

Pré-condições: O funcionário do suporte deve estar logado no sistema.

Pós-condições: O equipamento é removido do sistema.

Requisitos Associados: RF03, RF04, RF05

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte procura o equipamento [UC03] que deseja remover ou clica no botão “Remover” da tela de visualizar informações do equipamento [UC05];

3.     Caso tenha procurado o equipamento, o funcionário do suporte seleciona um ou mais equipamentos que deseja remover e clica no botão “Remover”. O sistema exibe então, uma página com todos os equipamentos selecionados e com o botão “Confirmar”;

4.     Caso tenha visualizado o equipamento, o sistema exibe uma página com as informações do equipamento e com o botão “Confirmar”;

5.     O funcionário do suporte clica no botão “Confirmar” [FS03];

6.     O sistema remove o(s) equipamento(s);

7.     O sistema exibe uma página de confirmação;

8.     Encerra-se o caso de uso.

 

[FS03] Cancelar operação

1.     Este fluxo secundário tem início quando o funcionário do suporte clica no botão “Cancelar”;

2.     O sistema retorna à página inicial;

3.     Encerra-se este caso de uso.

 

 

Pré-condições: O funcionário do suporte deve estar logado no sistema.

Pós-condições: Não se aplica.

Requisitos Associados: RF03, RF05

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte procura o equipamento [UC03];

3.     O funcionário do suporte seleciona o equipamento cujas informações deseja visualizar;

4.     O sistema exibe uma página com todas as informações do equipamento selecionado pelo usuário;

5.     Encerra-se o caso de uso.

 

 

Pré-condições: Funcionário do suporte deve estar logado no sistema.

Pós-condições: O equipamento tem suas informações atualizadas.

Requisitos Associados: RF03, RF05, RF06

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte clica no botão “Atualizar” ao visualizar a equipamento [UC05], ou quando escolhe atualizar o equipamento a partir da procura pelo mesmo [UC03];

3.     O sistema exibe uma página com os dados atuais do equipamento;

4.     O funcionário do suporte entra com os novos dados do equipamento e clica em “Atualizar”;

5.     O sistema exibe uma página com as informações atualizadas do equipamento e o botão “Confirmar”;

6.     O funcionário do suporte clica no botão “Confirmar” [FS03];

7.     O equipamento é atualizado no sistema;

8.     O sistema exibe uma página confirmando a operação;

9.     Encerra-se o caso de uso.

 

[FS03] Cancelar operação

1.     Este fluxo secundário tem início quando o funcionário do suporte clica no botão “Cancelar”;

2.     O sistema retorna à página inicial;

3.     Encerra-se este caso de uso.

 

 

     Pré-condições: O equipamento deve estar cadastrado no sistema.

Pós-condições: A saída do equipamento é cadastrada no sistema.

Requisitos Associados: RF07

Fluxo de eventos principal:

1.     Este caso de uso se inicia quando um usuário se aproxima do portão de saída com um equipamento do Centro;

2.     A antena de RFID detecta a ID da tag do equipamento;

3.     O sistema verifica se o usuário tem permissão para sair do Centro com o equipamento [FS04];

4.     O sistema autoriza a abertura do portão de saída do Centro;

5.     O portão de saída é aberto;

6.     O sistema coleta o login do usuário e o código do equipamento, assim como a data e hora em que o portão foi aberto;

7.     A saída do equipamento é cadastrada no sistema;

8.     Encerra-se o caso de uso.

 

 [FS04] Permissão negada

1.     Este fluxo alternativo tem início quando um usuário não é autorizado a sair do Centro com um determinado equipamento;

2.     O sistema não autoriza a abertura do portão de saída do Centro;

3.     Encerra-se este caso de uso.

 

 

Pré-condições: O equipamento deve estar cadastrado no sistema.

Pós-condições: A entrada do equipamento é cadastrada no sistema.

Requisitos Associados: RF08

Fluxo de eventos principal:

1.     Este caso de uso se inicia quando um usuário se aproxima do portão de entrada com um equipamento do Centro;

2.     A antena de RFID detecta a ID da tag do equipamento;

3.     O sistema autoriza a abertura do portão de entrada do Centro;

4.     O portão de entrada é aberto;

5.     O sistema coleta o login do usuário e o código do equipamento, assim como a data e hora em que o portão foi aberto;

6.     A entrada do equipamento é cadastrada no sistema;

7.     Encerra-se o caso de uso.

 

 

Pré-condições: O funcionário do suporte deve estar logado no sistema através da intranet.

Pós-condições: Todos os equipamentos que se encontram no CIn serão exibidos em uma lista.

Requisitos Associados: RF09

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte selecionar a opção “Listar equipamentos que se encontram no CIn” dentro do menu “Entrada e Saída”;

3.     O sistema exibe uma página com todos os equipamentos que se encontram no CIn no momento da consulta;

4.     Encerra-se este caso de uso.

 

 

Pré-condições: Um funcionário do suporte deve estar logado no sistema.

Pós-condições: As entradas e saídas de equipamentos encontradas são exibidas em uma lista.

Requisitos Associados: RF10

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte selecionar a opção “Consultar histórico de equipamentos” dentro do menu “Entrada e Saída”;

3.     O funcionário do suporte entra com as datas de início e fim do período do qual deseja obter o histórico de entrada e saída de equipamentos;

4.     O sistema exibe uma página com todas as entradas e/ou saídas de equipamentos encontradas;

5.     Encerra-se este caso de uso.

 

 

Pré-condições: O funcionário do suporte deverá estar logado no sistema

Pós-condições: A permissão de saída do equipamento é cadastrada no sistema.

Requisitos Associados: RF11

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte selecionar a opção “Cadastrar permissão de saída de equipamento” dentro do menu “Equipamentos”;

3.     O sistema exibe uma página requisitando:

                                                           a.      Código do equipamento;

                                                           b.      Login do usuário;

                                                            c.      Período de permissão: datas de início e de fim.

4.     O funcionário do suporte entra com os dados da permissão e clica no botão “Continuar” [FS03];

5.     O sistema verifica se já existe um cadastro de permissão de saída para o equipamento solicitado [FS05];

6.     A permissão de saída do equipamento é cadastrada no sistema;

7.     O sistema exibe uma página de confirmação;

8.     Encerra-se o caso de uso.

 

[FS03] Cancelar operação

1.     Este fluxo secundário tem início quando o funcionário do suporte clica no botão “Cancelar”;

2.     O sistema retorna à página inicial;

3.     Encerra-se este caso de uso.

 

[FS05] Conflito de permissão de saída do equipamento

1.     Este fluxo secundário inicia-se quando é detectado que já existe uma permissão de saída cadastrada no sistema para o código do equipamento e o login do usuário fornecidos;

2.     O sistema descadastra a permissão de saída de equipamento existente;

3.     Volta ao passo 6 do fluxo de eventos principal.

 

 

Pré-condições: O funcionário do suporte deverá estar logado no sistema.

Pós-condições: Não se aplica.

Requisitos Associados: RF12

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte selecionar a opção “Procurar permissões de saída de equipamentos” dentro do menu “Equipamentos”;

3.     O sistema exibe uma página onde devem ser escolhidos o tipo da procura (código do equipamento ou login do usuário) e o seu conteúdo;

4.     O funcionário do suporte clica no botão “Procurar”;

5.     O sistema exibe uma página com todas as permissões de saída de equipamentos encontradas;

6.     Encerra-se este caso de uso.

 

 

Pré-condições: O funcionário do suporte deve estar logado no sistema.

Pós-condições: A permissão de saída de equipamento é removida do sistema.

Requisitos Associados: RF12, RF13

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte procura a permissão de saída de equipamento [UC12];

3.     O funcionário do suporte seleciona uma ou mais permissões de saída de equipamentos que deseja remover e clica no botão “Remover”;

4.     O sistema exibe uma página com todas as permissões de saída de equipamentos selecionadas com os botões “Confirmar” e “Cancelar”;

5.     O funcionário do suporte clica no botão “Confirmar” [FS03];

6.     O sistema remove a(s) permissão(ões) de saída de equipamento(s);

7.     O sistema exibe uma página de confirmação;

8.     Encerra-se o caso de uso.

 

[FS03] Cancelar operação

1.     Este fluxo alternativo tem início quando o funcionário do suporte clica no botão “Cancelar”;

2.     O sistema retorna à página inicial;

3.     Encerra-se este caso de uso.

 

 

Pré-condições: Funcionário do suporte deve estar logado no sistema.

Pós-condições: Não se aplica.

Requisitos Associados: RF12, RF14

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte procura a permissão de saída de equipamento [UC12];

3.     O sistema exibe uma página com todas as informações da permissão de saída de equipamento e com o botão “Atualizar”;

4.     Encerra-se o caso de uso.

 

 

Pré-condições: Funcionário do suporte deve estar logado no sistema.

Pós-condições: A permissão de saída de equipamento tem suas informações atualizadas.

Requisitos Associados: RF12, RF14, RF15

Fluxo de eventos principal:

1.     Include (Logar);

2.     Este caso de uso se inicia quando o funcionário do suporte clica no botão “Atualizar” ao visualizar a permissão de saída de equipamento [UC14], ou quando escolhe atualizar permissão de saída de equipamento a partir da procura pela mesma [UC12];

3.     O sistema exibe uma página com os dados atuais da permissão de saída de equipamento;

4.     O funcionário do suporte entra com os novos dados da permissão de saída de equipamento e clica em “Atualizar”;

5.     O sistema exibe uma página com as informações atualizadas da permissão de saída de equipamento e o botão “Confirmar”;

6.     O funcionário do suporte clica no botão “Confirmar” [FS03];

7.     A permissão de saída de equipamento é atualizada no sistema;

8.     O sistema exibe uma página confirmando a operação;

9.     Encerra-se o caso de uso.

 

[FS03] Cancelar operação

1.     Este fluxo alternativo tem início quando o funcionário do suporte clica no botão “Cancelar”;

2.     O sistema retorna à página inicial;

3.     Encerra-se este caso de uso.