Análise do
Procedimento de
Submissão de Teses da
FEUP
Guilherme de Oliveira Dutra
Análise de Sistemas de Informação
Mestrado em Gestão de Informação 2003/2004
FEUP
(Professor: António Lucas Soares)
Índice
1. Introdução......................................................................................................................................... 1
2. Análise de Requisitos....................................................................................................................... 1
2.1. Situação problemática...............................................................................................................2
2.1.1. Rich Picture.......................................................................................................................4
2.2. Sistemas Relevantes..................................................................................................................5
2.2.1. Definição de Raíz.............................................................................................................. 5
2.2.2. CATWOE..........................................................................................................................5
2.3. Modelo Conceptual...................................................................................................................6
2.4. Factores de Sucesso ................................................................................................................ 7
2.5. Comparação com a situação actual........................................................................................... 8
3. Especificação de Requisitos do Sistema de EDMS........................................................................10
3.1. Descrição Geral.......................................................................................................................10
3.1.1. Propósito......................................................................................................................... 10
3.1.2. Âmbito do sistema.......................................................................................................... 10
3.1.3. Definições, acrónimos e abreviaturas..............................................................................11
3.1.4. Referências...................................................................................................................... 11
3.1.5. Visão Geral......................................................................................................................11
3.2. Descrição Completa................................................................................................................ 11
3.2.1. Perspectivas.....................................................................................................................11
3.2.2. Funções........................................................................................................................... 11
3.2.3. Características dos utilizadores....................................................................................... 12
3.2.4. Restrições........................................................................................................................ 12
3.2.4.1. Autenticidade...........................................................................................................12
3.2.4.2. Segurança................................................................................................................ 13
3.2.5. Suposições e Dependências.............................................................................................13
3.3. Requisitos Específicos............................................................................................................ 13
3.3.1. Requisitos de Interface Externa.......................................................................................13
3.3.1.1. Interfaces do utilizador............................................................................................ 13
3.3.1.2. Interfaces de Hardware............................................................................................ 13
3.3.1.3. Interfaces com outro software................................................................................. 13
3.3.1.4. Interfaces de comunicações..................................................................................... 14
3.3.2. Requisitos funcionais...................................................................................................... 14
3.3.3. Requisitos de Performance..............................................................................................14
3.3.4. Restrições de Desenvolvimento...................................................................................... 15
3.3.5. Requisitos não funcionais............................................................................................... 15
3.3.6. Diagrama de Classes....................................................................................................... 16
3.3.7. Diagrama “Use Cases”.................................................................................................... 17
3.3.8. Atributos do Sistema....................................................................................................... 18
3.3.8.1. Confiança.................................................................................................................18
3.3.8.2. Disponibilidade....................................................................................................... 18
3.3.8.3. Segurança................................................................................................................ 18
3.3.8.4. Facilidade de manutenção....................................................................................... 18
3.3.8.5. Portabilidade............................................................................................................18
4. Conclusão....................................................................................................................................... 18
5. Apêndice.........................................................................................................................................19
5.1. Definições, acrónimos e abreviaturas..................................................................................... 19
5.2. Referências..............................................................................................................................19
5.2.1. Artigos.............................................................................................................................19
5.2.2. Documentos on-line........................................................................................................ 20
5.2.3. Links................................................................................................................................20
5.3. Diagrama de Actividades das Universidades Analisadas....................................................... 22
5.3.1. UFRS (Brasil)..................................................................................................................22
5.3.2. DELFT (Holanda)........................................................................................................... 23
5.3.3. OXFORD (Inglaterra)..................................................................................................... 25
5.3.4. CURTIN (Australia)........................................................................................................26
5.4. Gestão Electrónica de Documentos (GED)............................................................................ 27
5.4.1. Gestão de Conteúdo........................................................................................................ 27
5.4.2. XML................................................................................................................................ 27
5.5. Assinatura Digital................................................................................................................... 28
5.5.1. Criptografia Assimétrica................................................................................................. 28
5.5.2. Garantir sigilo..................................................................................................................28
5.5.3. Assinar um documento....................................................................................................29
5.5.4. Assinar e garantir sigilo...................................................................................................30
5.5.5. Função Hash....................................................................................................................31
5.5.6. Assinatura Digital aliada à função Hash......................................................................... 31
5.5.7. Certificados de Segurança............................................................................................... 33
5.5.8. Segurança da Chave Pública através do uso de Smart-Cards......................................... 33
5.5.9. Segurança do algoritmo RSA..........................................................................................34
5.5.10. Ataque ao RSA..............................................................................................................34
1. Introdução
Esse ensaio visa propor um procedimento optimizado de submissão de teses1 de
doutoramento para a Faculdade de Engenharia da Universidade do Porto.
Para tanto foram analisados os procedimentos de submissão de teses de 4 (quatro)
faculdades de países distintos, todas elas ligadas à área tecnológica. São a Universidade Federal do
Rio Grande do Sul do Brasil, Delft da Holanda, Curtin da Austrália e Oxford da Inglaterra.
O procedimento aqui proposto objectiva cobrir pontos que o procedimento actual não cobre,
nomeadamente, a possibilidade de re-submissão da tese no caso de um resultado negativo após a
defesa, pequenas correcções da tese após a defesa, se necessárias, e a obrigatoriedade da entrega da
versão final da tese à biblioteca, em formato electrónico.
Para apoiar o procedimento, será proposto um sistema que automatizará o trâmite de
documentos. Todos os documentos serão electrónicos e deverão ser assinados "digitalmente", veja o
anexo sobre Assinaturas Digitais. O processo será gerido por um sistema de Enterprise Document
Management System (EDMS), veja o anexo sobre Gestão Electrónica de Documentos.
O capítulo a seguir é baseado na Metodologia SSM (Soft Systems Methodology) e descreve
a análise de requisitos. Conforme Simões e Soares (2002), a metodologia SSM permite desenvolver
um quadro conceptual das situações descritas como ideais, compará-lo com a situação real e analisar
as mudanças possíveis culturalmente e desejáveis sistemicamente.
O terceiro capítulo discorre a especificação de requisitos, sua estrutura é baseada no IEEE
Std 830-1998 Recomended Practice for Software Requirements Specifications (Práticas
Recomendadas para a Especificação de Requisitos de Software).
2. Análise de Requisitos
O regulamento de doutoramento da Universidade do Porto foi aprovado pela Secção
Científica do Senado nas suas reuniões de 15 de Janeiro e 18 de Março de 1993 e foi publicado no
Diário da República nº. 94, II Série de 22 de Abril de 1993. O procedimento de submissão da tese é
contemplado a partir do Artigo 18º.
Entretanto, esse regulamento descreve um procedimento burocrático e que não cobre uma
série de aspectos, dentre eles, a possibilidade de re-submissão da tese quando a classificação final
1 O procedimento de submissão de teses compreende desde o momento em que o doutorando requer admissão às
provas até a defesa e entrega da versão final da tese.
1
for “Reprovado”, as normas de formatação, a correcção (se necessária) após a defesa, as questões
referentes aos direitos do autor e confidencialidade e a entrega da versão final em formato
electrónico, o que permitirá a disponibilização da tese através de um repositório electrónico. Outro
problema é o grande volume de documentos, em papel, envolvidos, o que torna o processo ainda
mais burocrático.
Esses problemas serão descritos em detalhe na secção abaixo.
2.1. Situação problemática
Actualmente o processo de submissão de teses da Faculdade de Engenharia da Universidade
do Porto envolve um grande número de documentos em papel. Isso ocorre, principalmente, por
causa da quantidade de cópias da tese requeridas durante as principais fases do processo.
No momento da entrega da tese são requeridas 8 cópias da tese, 8 cópias do resumo em
português, inglês e francês e 8 cópias do Curriculum Vitae. Esse número de cópias de cada
documento se faz necessário, visto que cada elemento do júri receberá uma cópia da tese para
análise, outra cópia ficará retida na secretária de pós-graduação.
Segundo o regulamento de doutoramento da Universidade do Porto, o júri é composto por:
a) Reitor ou seu delegado, que preside;
b) Por um mínimo de três e um máximo de sete vogais doutorados;
c) O orientador e o co-orientador, sempre que exista, devem integrar o júri como
vogais.
Em seguida, o júri analisa a tese e profere um despacho liminar. Se o júri determinar a
necessidade de efectuar alterações na tese, o candidato deverá entregar a tese reformulada em
número de cópias igual ao número de elementos do júri. Após a defesa o candidato deve entregar 6
cópias da versão aprovada da tese.
Um das cópias da versão final vai para a biblioteca, mas não está previsto a entrega de uma
versão electrónica à biblioteca.
Todo essa transferência de documentos envolve custos de envio, além do que há uma
demora até que o documento chegue às mãos do destinatário.
O regulamento de doutoramento da Universidade do Porto não cita normas de formatação
para as teses. Entretanto, no catálogo electrónico da biblioteca da Faculdade de Engenharia pode ser
encontrado um documento intitulado “Normas para Apresentação de Dissertações”, de autoria do
Dr. Manuel António Cerqueira da Costa Matos.
Se após a defesa da tese o júri emitir um parecer negativo e consequentemente a
classificação final for “Reprovado”, não há a possibilidade do candidato reformular a tese.
2
A partir dessa situação problemática será proposto um procedimento ideal. O qual será
apoiado por um sistema de Enterprise Document Management System, denominado daqui por
diante de sistema de EDMS.
3
2.1.1. Rich Picture
4
2.2. Sistemas Relevantes
2.2.1. Definição de Raíz
Um sistema para gerir o trâmite de documentos necessários à submissão de teses de
doutoramento na Faculdade de Engenharia da Universidade do Porto. O objectivo é facilitar e
agilizar o processo e reduzir o volume de papéis.
Tal sistema controlará e automatizará a transferência de documentos bem como o acto de
assiná-los "digitalmente". Será implementado pelo Centro de Informática Professor Correia Araújo.
2.2.2. CATWOE
C (Clientes)
Doutorando, Júri, Comissão de Doutoramento, Biblioteca, Secretaria,
Orientador e co-orientador.
A (Actores)
Doutorando, Membros do Júri, Responsável pela Comissão de
Doutoramento
T (Transformação)
Transferência de grande volume de documentos em papel -> Transferência
de documentos em formato electrónico
W (Weltanschauung)
Optimizar o processo de submissão de teses, desde a conclusão da
elaboração da tese até a entrega em formato electrónico à biblioteca. As
consequências serão a diminuição do volume de papéis, a facilitação e a
agilização do processo.
O (Donos)
Faculdade de Engenharia
E (Envolvente)
Restrições impostas pelo regulamento de doutoramento da Universidade
do Porto;
As pessoas mais conservadoras não sentem-se à vontade com documentos
electrónicos e atribuem pouca segurança à assinatura digital.
5
2.3. Modelo Conceptual
O Modelo Conceptual foi elaborado utilizando o Diagrama de Actividades segundo UML (Unified Modeling Language).
6
2.4. Factores de Sucesso
Efectividade
O procedimento de submissão de teses proposto prevê situações que o
procedimento actual não prevê.
O processo de transferência de documentos electrónicos assinados
digitalmente tornar-se-á natural através da utilização do sistema.
Eficácia
O sistema contribuirá para a agilizar o processo de submissão de teses,
reduzindo o tempo gasto na transferência de documentos.
Eficiência
O sistema reduzirá o esforço de armazenagem, localização e
encaminhamento de documentos.
7
2.5. Comparação com a situação actual
Actividade
Ideal
Presente
Diferenças
Mudanças
Candidato solicita permissão Candidato preenche o
para procedimento de pós
formulário on-line e submete
graduação.
a tese, o resumo em inglês
francês e português e seu
Curriculum Vitae formato
PDF e assinada
"digitalmente", por ele e
pelo orientador.
Candidato preenche o
formulário em papel e
entrega-o, junto com 8
cópias da tese, 8 cópias do
resumo em inglês, francês e
português e 8 cópias do
Curriculum Vitae,
à secretaria de pósgraduação.
Grande volume de papel;
Comissão de Doutoramento Comissão emite despacho,
nomeia Examinadores e
on-line, de nomeação do
define a data para a defesa
júri.
Comissão encaminha à
secretaria de pós-graduação
despacho de nomeação do
Júri.
Doutorando é informado da Doutorando é informado,
nomeação do Júri pela
através de e-mail, a respeito
secretaria de pós-graduação. da nomeação do júri
imediatamente após a
emissão do despacho.
Júri reúne-se e profere
Despacho Liminar
Júri envia despacho à
secretaria de pós-graduação
que por sua vez comunicará
ao candidato.
Demora entre a emissão do
despacho e ciência do
candidato, já que o
documento passa pela
secretaria de pós-graduação.
Doutorando toma ciência do
despacho
imediatamente. Pois o
sistema efectua o aviso por
e-mail.
Grande volume de papel;
Nenhum documento em
papel;
Júri submete o despacho
assinado "digitalmente".
Candidato Corrige a tese (Se Reformula a tese, assina-a
Reformula a tese, emite-a
necessário)
"digitalmente" e envia-a on- em um número de cópias
line.
igual ao número de
elementos do júri.
Candidato apresenta e
defende a tese
Em sessão pública.
Em sessão pública.
Nenhum documento em
papel;
O Doutorando está sujeito ao
período de funcionamento da Solicitação efectuada
secretaria de pós-graduação. imediatamente.
Doutorando está sujeito ao
período de funcionamento da Tese corrigida é
secretaria de pós-graduação. encaminhada imediatamente.
-
-
8
Actividade
Ideal
Presente
Diferenças
Mudanças
Demora entre a emissão do
resultado e ciência do
doutorando, já que o
documento passa pela
secretaria de pós-graduação.
Doutorando toma ciência do
resultado imediatamente.
Pois o sistema efectua o
aviso por e-mail.
Júri
reúne-se e emite resultado
final
Resultado é assinado
"digitalmente" por todos os
membros do Júri e
submetido ao sistema de
EDMS.
Resultado é assinado por
todos os membros do Júri e
encaminhado à secretaria de
pós-graduação.
Candidato efectua
alterações supervisionado
pelo orientador
Após efectuadas as
alterações, o orientador
assina o relatório e o
candidato submete o
relatório.
Essa actividade não existe
actualmente.
Candidato consolida
a versão final da tese
e a envia à
secretaria de
pós-graduação
A tese ganha o formato de
Idem
um livro.
Candidato envia 6 cópias da
versão final à secretaria de
pós-graduação. Uma dessas
cópias vai para a biblioteca.
Envia versão
final da tese, em
formato electrónico,
à biblioteca
Submete, on-line, a tese em
formato PDF à biblioteca.
Comissão de Doutoramento O candidato recebe o título.
confere grau ao candidato
Essa actividade não existe.
Idem
-
A tese deve ser alterada
mediante as exigências do
júri.
-
-
A tese é enviada, em papel, à
biblioteca através da
secretaria de pós-graduação.
-
-
-
9
3. Especificação de Requisitos do Sistema de EDMS
Esse capítulo é baseado no IEEE Std 830-1998, Recomended Practice for Software
Requirements Specifications (Práticas Recomendadas para a Especificação de Requisitos de
Software), essa norma é baseada em um modelo no qual o processo de especificação resulta em um
documento sem ambiguidades e completo. Fundamentalmente descreve abordagens recomendadas.
3.1. Descrição Geral
A seguir serão descritos os objectivos, o propósito e o âmbito do sistema.
3.1.1. Propósito
O sistema automatizará o trâmite de documentos. Todos os documentos serão electrónicos e
deverão ser assinados "digitalmente", veja o anexo sobre Assinaturas Digitais.
Assim, o número de documentos em papel será reduzido significativamente. O trânsito de
documentos em papel não mais existirá, isso significa economia com despesas de envio e agilidade,
pois os documentos electrónicos chegam ao destinatário imediatamente.
3.1.2. Âmbito do sistema
Esse sistema enquadra-se na categoria Enterprise Document Management System (EDMS) e
receberá o nome de Sistema de Gestão de Processos de Pós-Graduação (SGPP).
Seu objectivo é apoiar todas as etapas do processo, desde o preenchimento do formulário de
solicitação do procedimento de Pós-Graduação até a entrega da versão final da tese em formato
electrónico à biblioteca. É importante salientar que todos os documentos envolvidos no processo
serão electrónicos, inclusive despachos, pareceres, relatórios e resultados.
O sistema requererá que todos os documentos submetidos sejam digitalmente assinados . O
acto de assinar um documento "digitalmente" será possível através da utilização de um software
para assinaturas digitais. Os detalhes estão descritos no anexo sobre Assinatura Digital.
Os documentos não serão enviados directamente à(s) pessoa(s) interessado(s), ao invés disso, o
documento será submetido ao sistema, o qual avisará o(s) interessado(s) através de e-mail. O
interessado acederá ao documento à partir do endereço electrónico indicado no próprio e-mail.
Somente após a comprovação de autenticidade2 do documento é que o interessado confirmará o seu
recebimento. Nesse momento o sistema enviará um e-mail à pessoa que submeteu o documento,
2
A comprovação de autenticidade dos documentos é conseguida através da utilização de um software de assinaturas
digitais. Veja o anexo sobre Assinaturas Digitais.
10
isso é a confirmação de que o interessado recebeu o documento em perfeitas condições.
Os utilizadores somente poderão aceder ao sistema ou parte dele mediante autenticação, o
que será possível através de “login” e senha.
3.1.3. Definições, acrónimos e abreviaturas
Veja no apêndice.
3.1.4. Referências
Veja no apêndice.
3.1.5. Visão Geral
O próximo tópico descreve os requisitos, as características, as perspectivas, as funções, as
restrições e as dependências do sistema.
3.2. Descrição Completa
3.2.1. Perspectivas
Não mais haverá tráfego de documentos em papel, visto que os documentos serão
electrónicos, consequentemente também não haverá acumulo de papel.
As despesas de envio de documentos não mais existirão.
Os documentos chegarão imediatamente ao interessado, tornando assim o processo mais
rápido.
O sistema permitirá ao candidato acompanhar todo o processo. Assim, será possível
observar em que ponto está o processo, quais pessoas estão envolvidas nesse momento e os prazos
vigentes. Dessa forma, o processo ficará mais transparente.
3.2.2. Funções
O sistema permitirá aos utilizadores submeterem os documentos assinados "digitalmente".
O interessados serão avisados, através de e-mail, a respeito da disponibilidade dos
documentos. O sistema controlará a confirmação de recebimento dos documentos.
Os utilizadores serão notificados periodicamente, por e-mail, a respeito dos prazos
recorrentes ao processo.
11
A versão final da tese será encaminhada à biblioteca no momento em que o candidato
submetê-la.
Todos os envolvidos poderão acompanhar o processo através do sistema.
3.2.3. Características dos utilizadores
O sistema de EDMS destina-se a todos aqueles envolvidos no processo, nomeadamente o
doutorando, o orientador, o co-orientador (se houver), os funcionários da Secretaria de PósGraduação, os elementos do Júri, os membros da Comissão de Doutoramento e o responsável da
biblioteca pelo recebimento de teses.
Documentos electrónicos não são novidades para esse utilizadores, mas o conceito de
assinatura digital será algo novo para a grande maioria das pessoas envolvidas nesse processo.
Algumas dessas pessoas, devido a falta de conhecimento, poderão atribuir falta de fiabilidade às
assinaturas digitais. Por essa razão as pessoas que estão ligadas à FEUP deverão receber formação
sobre assinaturas digitais. As outras pessoas poderão utilizar o tutorial disponível no próprio
sistema.
3.2.4. Restrições
3.2.4.1. Autenticidade
Assinar "digitalmente" um documento requer um Certificado Digital. Os certificados
digitais poderão ser emitidas pela FEUP ou por uma entidade certificadora, como por exemplo a
VeriSign ou a Thawte.
É necessária a utilização de um software para aplicar o certificado digital ao documento,
gerando assim a assinatura digital. Esse software deverá ser instalado nos computadores das pessoas
envolvidas no processo.
A escolha do software para assinaturas digitais ficará a cabo dos desenvolvedores, entretanto
o software em questão deve utilizar os algoritmos RSA e MD5. Veja o anexo sobre assinaturas
digitais.
Nota: Actualmente a FEUP disponibiliza o software PDF995, trata-se de um software
“freeware” para conversão de ficheiros .doc em .pdf. Sugere-se então, para assinaturas digitais, a
adopção do Signture995, já que ambos os softwares são da mesma empresa, a Software995.
12
3.2.4.2. Segurança
O protocolo padrão da WEB é o HTTP, entretanto, nesse protocolo as informações circulam
desprotegidas pela Internet. Para resolver esse problema deverá ser utilizado o protocolo HTTPS,
nesse protocolo as informações circulam “criptografadas” através da Internet e só são
descodificadas no destino.
3.2.5. Suposições e Dependências
O sistema poderá ser acedido através da Intranet da FEUP. As pessoas que acederão ao
sistema de fora precisarão apenas de um computador, uma conexão à Internet e o software para
assinaturas digitais.
3.3. Requisitos Específicos
3.3.1. Requisitos de Interface Externa
3.3.1.1. Interfaces do utilizador
O sistema será acessível através de um navegador Web padrão de mercado.
Para aceder ao sistema o utilizador deverá digitar seu Login e Senha. Depois da
autenticação, o sistema apresentará a situação actual do respectivo processo.
3.3.1.2. Interfaces de Hardware
O software deverá utilizar o protocolo HTTPS.
3.3.1.3. Interfaces com outro software
O sistema de EDMS aqui proposto deverá ser um módulo do SIFEUP3, por isso a
autenticação do utilizador ficará a cargo do SIFEUP. O EDMS compartilhará a base de dados do
SIFEUP, evitando assim redundância de informação.
Não haverá comunicação directa entre o EDMS e o software utilizado para assinaturas
3 SIFEUP é o sistema de informação da FEUP. Conforme o Centro de Informática Correia Araújo, responsável pelo
desenvolvimento do software, o seu objectivo principal é difundir e facilitar os recursos informativos da Faculdade,
incrementando a cooperação entre os seus membros.
13
digitais. Entretanto, o sistema deverá verificar a autenticidade das assinaturas digitais nos
documentos submetidos, para isso, precisará “ler” os ficheiros criados pelo software de assinaturas
digitais.
3.3.1.4. Interfaces de comunicações
O sistema estará acessível através da Internet e através da Intranet da FEUP.
3.3.2. Requisitos funcionais
A seguir serão descritas as funcionalidades do software.
a) O sistema deverá pedir o “login” e a senha de cada utilizador.
b) O sistema deverá possibilitar o preenchimento, on-line, de todos os formulários
necessários ao procedimento.
c) O sistema deverá possibilitar a submissão de documentos.
d) O sistema deverá verificar se a assinatura digital pertence à pessoa que submeteu o
documento. Para isso o sistema deverá armazenar os certificados digitais de todas as pessoas
envolvidas no processo.
e) O sistema deverá avisar ao(s) destinatário(s), através de e-mail, que há um documento
disponível.
f) O sistema deverá exigir que os utilizadores confirmem o recebimento de documentos.
3.3.3. Requisitos de Performance
a) O sistema deverá ser capaz de processar as transações em menos de 2 segundos.
b) O tempo de resposta ao utilizador dever ser menor do que 5 segundos.
c) O sistema deverá suportar ao menos 100 utilizadores em simultâneo.
14
d) Os e-mails que comunicam sobre a disponibilidade de um documento devem chegar ao
destinatário em até 2 horas.
3.3.4. Restrições de Desenvolvimento
Não aplicável
3.3.5. Requisitos não funcionais
a) O sistema deverá estar disponível na Internet, de forma a estar acessível a partir de
qualquer localização geográfica.
b) O sistema deverá estar disponível 24 horas por dia durante 7 dias por semana.
c) O sistema deverá ser implementado em uma arquitectura de 3 camadas, ou seja, servidor
de banco de dados, servidor de aplicações e cliente.
d) O sistema deverá armazenar os certificados digitais de todas as pessoas envolvidas no
processo.
e) O sistema deverá possibilitar ao utilizador acompanhar o estado actual do processo.
Deverá ser possível saber quais pessoas estão envolvidas no actual momento e quais os prazos.
f) O sistema deverá possuir um mecanismo de alerta. Dessa forma, os utilizadores serão
notificados, por e-mail, 5 (cinco), 3 (três) e 1 (um) dias antes do vencimento do prazo de entrega de
um documento.
g) O sistema deverá encaminhar a versão final da tese à biblioteca.
15
3.3.6. Diagrama de Classes
16
3.3.7. Diagrama “Use Cases”
17
3.3.8. Atributos do Sistema
3.3.8.1. Confiança
O sistema deve exigir que os documentos sejam assinados digitalmente, a confirmação de
que o documento foi entregue e que a assinatura digital foi verificada.
Os utilizadores que não confirmarem o recebimento e a verificação da assinatura de um
documento em até 36 horas serão notificados diariamente até o fazerem.
Essas medidas conferiram “confiabilidade” ao sistema.
3.3.8.2. Disponibilidade
O sistema deverá estar disponível 24 horas por dia durante 7 dias por semana.
3.3.8.3. Segurança
Todos os utilizadores devem autenticar-se no sistema através da utilização de login e
password. As passwords devem possuir um mínimo de 6 caracteres, sendo que o sistema não deverá
aceitar passwords óbvias, além disso, o sistema deverá requerer a alteração das passwords a cada 6
meses.
Deve ser efectuado um backup em “Tape Dat” ou “Zip Disk” todos os dias às 5:00 a.m.
3.3.8.4. Facilidade de manutenção
Todas os módulos, rotinas e funções devem ser devidamente documentados. Os
desenvolvedores deverão ter acesso ao Help produzido a partir dessa documentação.
3.3.8.5. Portabilidade
O sistema deverá ser desenvolvido utilizando uma linguagem de programação nãoproprietária e um SGBD (Sistema de Gestão de Banco de Dados) disponível nos principais sistemas
operativos. Sugere-se a utilização da linguagem JAVA e do SGBD Oracle.
4. Conclusão
Com a implementação do sistema de EDMS proposto nesse documento, não mais haverá
trânsito de documentos em papel, isso significa economia com despesas de envio e agilidade, pois
os documentos electrónicos chegam ao destinatário imediatamente.
Outra consequência será o facto de que a Secretaria de Pós-Graduação passará a ser apenas
um ponto de “apoio” físico, deixando de ser a entidade responsável por arquivar e encaminhar os
18
documentos.
5. Apêndice
5.1. Definições, acrónimos e abreviaturas
EDMS: Enterprise Document Management System. Designação para sistemas de gestão
electrónica de documentos.
IEEE: Institute of Electrical and Electronics Engineers.
MD5: Message Digest nº 5
RSA: Algoritmo de Criptografia criado por Ron Rivest, Adi Shamir e Len Adleman.
SGBD: Sistema de Gestão de Banco de Dados.
SSM: Soft Systems Methodology.
UML: Unified Modeling Language.
XML: Extensible Markup Language.
5.2. Referências
5.2.1. Artigos
Lopes, Milton E. (2001), Soft Systems Methodology An Application to a Community
Based Association, Fielding Graduate Institute, Action Research Symposium, Alexandria,
VA.
Rose, Jeremy. (1997), Soft Systems Methodology as a Social Science Research Tool
Systems, Research and Behavioural Science, vol.14 no. 4 pp 249-258.
19
Simões, Dora, Soares, António L., (2002), Utilização da SSM em Ambientes
Organizacionais de Engenharia, 3ª Conferência da Associação Portuguesa de Sistemas de
Informação. Departamento de Engenharia Informática. Universidade de Coimbra.
5.2.2. Documentos on-line
Delft University, Doctorate Regulations,
<http://www.promood.tudelft.nl/docs/doctorateregulations_ENG.pdf>, [acedido em 30-032004].
Delft University, Instructions for authors of PhD theses,
<http://www.library.tudelft.nl/eng/pdf/auteursinstructie-e.pdf>, [acedido em 28-03-2004].
FEUP, Regulamento do Doutoramento da Universidade do Porto,
<http://sifeup.fe.up.pt/si/WEB_UTIL.download_file?p_name=F1114969480/Regulamento%
20de%20Doutoramento.pdf>, [acedido em 25-03-2004].
IEEE Std 830-1998, Recommended Practice for Software Requirements SpeciÞcations,
<http://users.snip.net/~gbooker/INFO627/IEEE-830-1998.pdf>, [acedido em 20-05-2004].
IEEE Std 1233-1998, Guide for Developing System Requirements Specifications,
<http://se.inf.ethz.ch/teaching/ss2004/0250/readings/Guide_Developing_SRS.pdf>,
[acedido em 20-05-2004].
5.2.3. Links
Curtin University, Base de Dados de Teses,
<http://lisweb.curtin.edu.au/theses/>, [acedido em 10-04-2004].
Curtin University, Forms, Politics and Guidelines,
<http://research.curtin.edu.au/graduate/forms.html>, [acedido em 29-03-2004].
Curtin University, Intelectual Property,
20
<http://policies.curtin.edu.au/documents/ownership_intell_property.doc>,
[acedido em 22-04-2004].
E-SEC, Princípios de Assinatura Digital,
<http://www.digitrust.com.br/AssinaturaDigital.doc>, [acedido em 18-04-2004].
Harvard, Student Handbook,
<http://www.hsph.harvard.edu/registrar/handbook/index.shtml>, [acedido em 04-04-2004].
Marcos Vojciechovski, O Gerenciamento de Conteúdos em Projectos,
<http://www.pm21.com.br/pdf/artigo_001.pdf>, [acedido em 19-04-2004].
Oxford, Regulations,
<http://www.clp.ox.ac.uk/postgrad/Handbook2003_4.html>, [acedido em 14-04-2004].
Stanford, PhD Program,
<http://www.gsb.stanford.edu/phd/>, [acedido em 11-03-2004].
Universidade de São Paulo, Manual para a elaboração de teses,
<http://www.usp.br/ip/biblioteca/pdf/Dissertacoeseteses.pdf>, [acedido em 10-03-2004].
Universidade Federal do Rio Grande do Sul, Biblioteca Digital,
<http://www.biblioteca.ufrgs.br/bibliotecadigital/>, [acedido em 02-04-2004].
Universidade Federal do Rio Grande do Sul, Normas para Monografias,
<http://www.inf.ufrgs.br/biblioteca/html/normas.htm>, [acedido em 01-04-2004].
Universidade Federal do Rio Grande do Sul, Regimento de Pós-Graduação,
<http://www.inf.ufrgs.br/pos/ppgc/comuns/regimento.html>, [acedido em 01-04-2004].
Universidade de São Paulo, Regimento de Pós-Graduação,
<http://www.usp.br/prpg/regimento/regimento.htm>, [acedido em 09-03-2004].
21
5.3. Diagrama de Actividades das Universidades Analisadas
5.3.1. UFRS (Brasil)
Ficheiros em anexo:
•
UFRS.png
•
UFRS – Banca Examinadora.png
•
UFRS – Decisão da Comissao.png
22
5.3.2. DELFT (Holanda)
Ficheiros em anexo:
•
DELFT.png
23
24
5.3.3. OXFORD (Inglaterra)
Ficheiros em anexo:
•
Oxford.png
•
Oxford-solicitacao.png
25
5.3.4. CURTIN (Australia)
Ficheiros em Anexo:
Curtin.png
26
5.4. Gestão Electrónica de Documentos (GED)
As ferramentas de GED surgiram devido à necessidade de reduzir o volume papéis e
permitir o acesso concorrente a documentos de diferentes unidades organizacionais. No seu sentido
clássico as ferramentas de GED devem permitir o armazenamento electrónico, a classificação e a
recuperação de documentos. Aos poucos foram incorporadas funcionalidades de controlo de versão,
workflows, entre outras.
A evolução das ferramentas GED conduz-nos às ferramentas EDMS (Enterprise Document
Management System). EDMS são ferramentas que incorporam funcionalidades das ferramentas de
Gestão de Conteúdo (WCM), Portal Corporativo (Enterprise Internet Portal) e GED, além de
geralmente utilizarem a tecnologia XML.
5.4.1. Gestão de Conteúdo
As ferramentas de Gestão de Conteúdo têm por objectivos reconhecer e isolar unidades de
informação, como textos, imagens e números em diferentes contextos, como certificados, artigos de
jornais, textos livres, e-mails.
Uma grande evolução das ferramentas de Gestão de Conteúdo é a implementação do
conceito de diferenciação de forma e conteúdo. Forma é soma de estética, estrutura e navegação,
conteúdo é a informação com valor agregado.
A partir daí é possível compor as unidades de informação em diferentes contextos, ou seja,
apresentar a informação de maneira personalizada para um grupo específico de utilizadores.
As ferramentas EDMS têm como foco a partilha de documentos e não apenas o seu envio.
Isso significa agilizar os processos de disseminação e recuperação de informações, permitindo que
os membros da equipa tenham acesso aos documentos de qualquer lugar e a qualquer hora, podendo
visualizar, elaborar, comentar, revisar e aprovar qualquer tipo de documento.
Para que essas ferramentas e tecnologias possam ser implantadas é preciso uma revisão e
optimização dos processos relacionados à documentação, além de uma mudança de comportamento.
5.4.2. XML
O XML é um padrão desenvolvido pelo World Wide Web Consortium (W3C). Foi
desenvolvido para a estruturação de informações orientadas a texto e para processar estas
informações usando sistemas de informação.
A principal contribuição do XML para a Gestão de Conteúdo é o fato de que esta tecnologia
baseia-se na separação do conteúdo e apresentação. Este é o motivo pelo qual os principais sistemas
27
de gestão de conteúdo são baseados em XML.
5.5. Assinatura Digital
No processo convencional, um sinal gráfico (pessoal) é aposto a um papel para ratificar o
seu conteúdo. O processo é válido porque a assinatura está atrelada ao papel de forma permanente.
A mesma não pode ser transferida para uma outra folha. É fato que esse processo não é “inforjável”
visto que o sinal gráfico pode ser copiado de forma idêntica por uma pessoa capacitada.
O processo de assinatura digital se utiliza de algoritmos criptográficos para fundir um
segredo (pessoal) a um conjunto de bytes (mensagem a ser assinada). A garantia é que somente
quem conhece o segredo pode reproduzir o mesmo resultado. O resultado desse processo é a
assinatura digital.
O processo de verificação da assinatura (reconhecimento de firma) utiliza-se de uma
informação pública acrescida da mensagem original para verificar se a referida pessoa
efectivamente assinou a mensagem. Note que as características descritas acima têm princípios
idênticos aos da assinatura manuscrita: a) Assinatura privada; b) Verificação pública.
Porém a assinatura digital possui algumas vantagens em relação à assinatura convencional:
•
É mais segura pois é muito difícil de forjar;
•
Cada assinatura digital está intimamente ligada ao conteúdo do documento;
•
Pode ser remetida pela rede e verificada remotamente através de uma cópia da
mesma. Essa característica não é válida para a assinatura tradicional.
5.5.1. Criptografia Assimétrica
Pode ser utilizada para garantir sigilo, ou seja, impedir que pessoas não autorizadas leiam o
documento, ou pode ser utilizada para implementar assinaturas digitais.
Utiliza o conceito de chaves públicas e privadas. Cada utilizador possui uma chave privada e
uma chave pública. A chave privada não pode sair da mão do dono do par de chaves. Somente a
chave pública pode ser distribuída.
Um algoritmo para criptografia assimétrica amplamente utilizado é o RSA
5.5.2. Garantir sigilo
Nesse caso a chave pública será uma chave que servirá para a criptografia dos dados e a
chave privada será a chave para decriptografia (deciframento) da mensagem.
Procedimento:
28
•
receptor fornece sua chave pública (KUb) ao emissor.
•
emissor aplica à mensagem (M) a chave pública (KUb) do receptor, criando a
mensagem (C)
•
emissor envia mensagem (C) ao receptor
•
receptor aplica sua chave privada (KRb) à mensagem (C) e obtém a mensagem
(M).
Esquema de Criptografia Assimétrica para garantir sigilo
5.5.3. Assinar um documento
Nesse caso a chave privada será uma chave que servirá para a criptografia dos dados e a
chave pública será a chave para decriptografia (deciframento) da mensagem.
Procedimento:
•
Emissor aplica chave privada (KRa) à mensagem (M), gerando a assinatura (S);
•
Somente a chave pública (KUa) do Emissor pode decriptografar a assinatura (S).
* Se a chave pública do emissor foi capaz de decriptografar a assinatura significa que
somente ele poderia tê-la gerado.
29
Esquema de Criptografia Assimétrica para assinatura digital
5.5.4. Assinar e garantir sigilo
Para isso é preciso usar dois pares de chaves públicas e privadas.
Procedimento:
•
Emissor aplica à mensagem (M) a chave pública do receptor.
•
Emissor aplica à assinatura (A) sua chave privada.
Esquema de Criptografia Assimétrica para para sigilo e assinatura digital
30
5.5.5. Função Hash
Uma função é dita unidireccional ou de hash quando possui a característica de transformar
um texto de qualquer tamanho em um texto ininteligível de tamanho fixo. Além disso ela também
se caracteriza por ser fácil de calcular e difícil de serem invertidas. Um exemplo simples de uma
função unidireccional, porém não aplicada à criptografia é o cálculo do resto da divisão de um
número por outro. Um exemplo simples de uma função unidireccional, porém não aplicada à
criptografia é o cálculo do resto da divisão de um número por outro. Por exemplo, se criar-se uma
função que calcule o resto da divisão de qualquer número por 10 o que temos é que qualquer que
seja o número que será dividido por 10 o resultado é sempre um número entre 0 e 9. Isto é, o
processo de cálculo é bem simples porém como saber se o resultado do resto for, por exemplo, 9
qual foi o número que divido por 10 gerou resto 9. É muito difícil afirmar com certeza visto que
existem infinitos números que divididos por 10 darão resto 9. A esse fato damos o nome de colisão.
Isto é, quando dois números diferentes aplicados à função de hash geram o mesmo resultado
dizemos que houve uma colisão. Nesse ponto é que faz-se a diferença entre uma função de hash
criptográfica e uma não criptográfica. A função de hash criptográfica é aquela que foi elaborada a
possuir o mínimo de colisões possível.
O tamanho do seu resultado é sempre fixo e pequeno. Uma função de hash tem em média 20
bytes de saída independente do tamanho do texto de entrada.
Geralmente usa-se funções de Hash para efectuar cálculos de integridade no envio de
mensagens.
Procedimento ao enviar mensagem:
•
Calcula-se o Hash (H) da mensagem;
•
Envia-se a mensagem e seu Hash (H)
Processo de verificação de integridade:
•
Recebe-se a mensagem e seu Hash (H);
•
Calcula-se novamente o hash da mensagem H’;
•
Compara-se H com H’ para ver se são iguais;
•
Se H e H’ são iguais então a mensagem está íntegra.
Os algoritmos de hash mais utilizados actualmente são o MD5(Message Digest nº 5) e
SHA1 (Standard Hash Algorithm nº 1).
5.5.6. Assinatura Digital aliada à função Hash
O processo de assinatura digital descrito aqui utiliza algoritmo de chave pública e algoritmo
de hash para montar a assinatura. A assinatura digital nada mais é que a mensagem cifrada através
31
da chave privada do assinante. O algoritmo de chave pública garante que se um determinado texto
for cifrado com a chave privada somente poderá ser decifrada com a chave pública correspondente.
Como a chave privada é mantida em segredo sendo somente conhecida pelo proprietário essa
operações constitui uma assinatura digital, pois garante que ela fica atrelada ao texto e somente o
possuidor da chave privada poderia efectuar aquela operação. Da mesma forma o processo de
verificação passa por decifrar a mensagem utilizando a chave pública. Assim a pessoa que verifica
pode ter certeza de que quem realmente gerou a assinatura foi a pessoa correcta. O processo é muito
simples e pode ser aplicado não somente a um texto, mas também a qualquer tipo de arquivo digital
(imagem, som, etc).
Na prática como o resultado de uma cifragem é do tamanho da mensagem original seria
inviável fazer somente a cifragem no processo de assinatura. Isso porque a assinatura ficaria do
tamanho da mensagem original. Se está-se a falar de 1kbyte isso não chega a ser problema. Porém,
se está-se a falar de 10Mbytes teria-se uma assinatura de 10Mbytes. Por essa razão, na prática o que
se faz é aplicar um cálculo de hash sobre a mensagem e cifrar o resultado do hash e não a
mensagem. O hash é usado aqui porque, independente do tamanho da mensagem, o resultado dele é
de no máximo 20 bytes. E dessa forma a assinatura ficaria com tamanho pequeno independente do
tamanho da mensagem a ser assinada.
Assim um processo de assinatura poderia ser o seguinte:
Assinatura:
•
Obtém-se a assinatura (A) através da aplicação da chave privada (KRa) no Hash (H)
da mensagem (M),A = KRa(h(M));
•
Envia-se a mensagem (M) e a assinatura (A);
Reconhecimento da Assinatura:
•
Recebe-se a mensagem (M), a assinatura (A) e a chave pública (KUa);
•
Obtém-se o Hash da mensagem original, H = h(M))
•
Decripta-se a assinatura utilizando a chave pública (KUa) e obtém-se o Hash da
mensagem, H’ = h(M’);
•
Compara-se o hash da mensagem original h(M) com a mensagem decriptada h(M’).
Se os dois hashs são iguais então a assinatura está correcta.
Obs: O reconhecimento de firma digital é um pouco diferente do processo convencional.
Neste, somente o sinal gráfico da assinatura é comparada não se dando nenhuma importância ao
conteúdo do papel. Na assinatura digital o reconhecimento da firma sempre envolve o conteúdo da
mensagem. Qualquer adulteração do texto original torna a verificação da assinatura incorrecta.
32
5.5.7. Certificados de Segurança
No funcionamento de transferência de documentos, os usuários da tecnologia RSA
normalmente anexam a chave pública a um documento enviado, de modo que o destinatário não
precise procurá-la em um repositório de chaves públicas.
Porém, como pode o destinatário ter certeza de que esta chave pública realmente pertence à
pessoa indicada ou se um invasor não entrou na rede e esta se passando pelo remetente, fazendo-se
passar por um usuário legítimo.
Para contornar este problema existe o Certificado Digital, um tipo de passaporte ou
credencial digital. O certificado digital é a chave pública do usuário "assinada digitalmente" por
alguém qualificado para isso, como o director de segurança de uma rede ou uma Autoridade
Certificadora (CA) como a VeriSign.
Ao enviar uma mensagem, seu certificado digital segue em anexo. O destinatário da
mensagem utiliza o certificado digital inicialmente para verificar se a chave pública do autor é
autêntica e/ou então para ler a própria mensagem. Dessa forma, apenas a chave pública (a da
autoridade certificadora) deve ser publicada, pois a partir daí todos os outros podem simplesmente
transmitir seus respectivos certificados digitais válidos juntamente com suas mensagens.
Caso deseje-se revogar o certificado de uma determinada pessoa ou caso a chave pública de
algum usuário foi comprometida recorre-se à Revogação de Certificados. Para isso a autoridade
certificadora deve manter uma lista de certificados revogados.
5.5.8. Segurança da Chave Pública através do uso de Smart-Cards
O processo mais fiável, actualmente, para guardar a chave privada são os smart-cards
(cartões inteligentes) que possuem um chip interno à prova de invasão e somente podem ser
acedidos através de uma senha ou algum tipo de biometria (impressão digital por exemplo). Esses
cartões possuem chips, isto é, podem fazer processamento interno. Assim podem ser gravados
internamente a eles programas que geram o par de chaves e protegem a chave privada contra
qualquer tipo de invasão. O usuário nunca tem acesso ao conteúdo do cartão, ele somente solicita ao
cartão que faça determinado tipo acção, no caso que assine um documento digital usando a chave
privada do proprietário do cartão. Essas acções somente são executadas se o possuidor do cartão
digitar correctamente a senha de acesso ou opuser a sua impressão digital sobre o mesmo. Ele não
permite que, se o cartão for roubado ou perdido sejam feitas tentativas sucessivas de se obter a
senha, pois depois de um número determinado de tentativas ele tem seu funcionamento suspenso
33
por tempo indeterminado. Além disso, o chip contém mecanismos de autodestruição caso seja
rompido.
5.5.9. Segurança do algoritmo RSA
O RSA inicia-se com dois grandes números primos, p e q. Dados esses números, encontra-se
seu produto, n=pq, denominado módulo. Um terceiro número e, menor do que n e relativamente
primo ao (p-1)(q-1) é escolhido e seu inverso mod (p-1)(q-1), d, calculado.
O algoritmo do RSA é:
•
Criptografar: C = Me mod n
•
Decriptografar: M = Cd mod n
A segurança do RSA é baseada na dificuldade de facturar um número n quando n é um
número muito grande. Suponhamos que perdemos os números p e q, mas conhecemos o produto n =
pq. Como recuperar?
Existem vários métodos de ataque ao RSA, mas todos os caminhos são pelo menos tão
difíceis quanto factorar n.
5.5.10. Ataque ao RSA
O ataque mais grave ao RSA é descobrir a chave privada correspondente a uma chave
pública. Isto permitiria ao hacker ler as mensagens criptografadas e forjar assinaturas. O caminho
óbvio é tentar factorar o número n e descobrir os factores p e q. Se o RSA for equivalente ao
problema da factoração, esse é o único ataque possível, porém isso ainda não foi provado e é
razoável admitir que pode existir outro ataque ao RSA que não tente uma factoração directa de n.
Uma das características do RSA é que ele um sistema multiplicativo. Uma função é dita
multiplicativa quando dado f(x) e f(y), calcular f(xy) é fácil. Isso significa que o RSA é susceptível a
ataques por texto.
Claro que se o administrador de rede armazenar a chave privada de maneira insegura ou com
uma criptografia baixa (normalmente se criptografa a chave privada por segurança) é possível atacar
o servidor e roubar o arquivo contendo a chave privada. Isto não é exactamente um ataque ao RSA,
porém deve-se tomar muito cuidado onde guardar a chave privada.
Um projecto da distributed.net em 22 de Agosto de 1999 anunciou a decifragem de uma
mensagem criptografada, um desafio da RSA Labs. Nesta ocasião, um conjunto de computadores
permitiu a factoração de um número com 512bits (155 dígitos decimais) em dois primos de 78
34
dígitos cada. O algoritmo foi o Number Field Sieve em uma rede com 300 mil computadores.
Seriam necessárias 8000 Anos-MIPS para fazer isso. A filtragem (passo 2) foi feito em um
supercomputador Cray C916 no Centro de Computação Académica de Amesterdão e a
implementação do código foi feito por Peter Mongomery consumiu 3,2GB de RAM, 224 horas de
CPU para processar a matriz tridimensional com 6.699.191 linhas, 6.711.336 colunas e 417.131.631
linhas em profundidade. O tempo de factoração total foi de 5,2 meses, além de 2,2 meses para
seleccionar os polinómios. A RSA Labs mantém vários desafios em seu site para números de 576 à
2048 bits. Para ter uma ideia da dimensão, a RSA Labs estima que o RSA1024 requer 1 milhão de
vezes mais esforço computacional do que o RSA512.
35