análise do procedimento de submissão de teses …mgi03010/trabalhos/asi_grupo.pdfanálise do...

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

Upload: dobao

Post on 13-Dec-2018

217 views

Category:

Documents


0 download

TRANSCRIPT

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)

Índice1. Introdução......................................................................................................................................... 12. Análise de Requisitos....................................................................................................................... 1

2.1. Situação problemática...............................................................................................................22.1.1. Rich Picture.......................................................................................................................4

2.2. Sistemas Relevantes..................................................................................................................52.2.1. Definição de Raíz..............................................................................................................52.2.2. CATWOE..........................................................................................................................5

2.3. Modelo Conceptual...................................................................................................................62.4. Factores de Sucesso ................................................................................................................ 72.5. Comparação com a situação actual........................................................................................... 8

3. Especificação de Requisitos do Sistema de EDMS........................................................................103.1. Descrição Geral.......................................................................................................................10

3.1.1. Propósito......................................................................................................................... 103.1.2. Âmbito do sistema.......................................................................................................... 103.1.3. Definições, acrónimos e abreviaturas..............................................................................113.1.4. Referências......................................................................................................................113.1.5. Visão Geral......................................................................................................................11

3.2. Descrição Completa................................................................................................................ 113.2.1. Perspectivas.....................................................................................................................113.2.2. Funções........................................................................................................................... 113.2.3. Características dos utilizadores....................................................................................... 123.2.4. Restrições........................................................................................................................ 12

3.2.4.1. Autenticidade...........................................................................................................123.2.4.2. Segurança................................................................................................................ 13

3.2.5. Suposições e Dependências.............................................................................................133.3. Requisitos Específicos............................................................................................................ 13

3.3.1. Requisitos de Interface Externa.......................................................................................133.3.1.1. Interfaces do utilizador............................................................................................ 133.3.1.2. Interfaces de Hardware............................................................................................ 133.3.1.3. Interfaces com outro software................................................................................. 133.3.1.4. Interfaces de comunicações..................................................................................... 14

3.3.2. Requisitos funcionais...................................................................................................... 143.3.3. Requisitos de Performance..............................................................................................143.3.4. Restrições de Desenvolvimento...................................................................................... 153.3.5. Requisitos não funcionais............................................................................................... 153.3.6. Diagrama de Classes....................................................................................................... 163.3.7. Diagrama “Use Cases”.................................................................................................... 173.3.8. Atributos do Sistema.......................................................................................................18

3.3.8.1. Confiança.................................................................................................................183.3.8.2. Disponibilidade....................................................................................................... 183.3.8.3. Segurança................................................................................................................ 183.3.8.4. Facilidade de manutenção....................................................................................... 183.3.8.5. Portabilidade............................................................................................................18

4. Conclusão....................................................................................................................................... 185. Apêndice.........................................................................................................................................19

5.1. Definições, acrónimos e abreviaturas..................................................................................... 195.2. Referências..............................................................................................................................19

5.2.1. Artigos.............................................................................................................................195.2.2. Documentos on-line........................................................................................................ 205.2.3. Links................................................................................................................................20

5.3. Diagrama de Actividades das Universidades Analisadas....................................................... 22

5.3.1. UFRS (Brasil)..................................................................................................................225.3.2. DELFT (Holanda)........................................................................................................... 235.3.3. OXFORD (Inglaterra)..................................................................................................... 255.3.4. CURTIN (Australia)........................................................................................................26

5.4. Gestão Electrónica de Documentos (GED)............................................................................ 275.4.1. Gestão de Conteúdo........................................................................................................ 275.4.2. XML................................................................................................................................27

5.5. Assinatura Digital................................................................................................................... 285.5.1. Criptografia Assimétrica................................................................................................. 285.5.2. Garantir sigilo..................................................................................................................285.5.3. Assinar um documento....................................................................................................295.5.4. Assinar e garantir sigilo...................................................................................................305.5.5. Função Hash....................................................................................................................315.5.6. Assinatura Digital aliada à função Hash......................................................................... 315.5.7. Certificados de Segurança...............................................................................................335.5.8. Segurança da Chave Pública através do uso de Smart-Cards......................................... 335.5.9. Segurança do algoritmo RSA..........................................................................................345.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 àsprovas 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áticaActualmente 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ízUm 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 deDoutoramento

T (Transformação) Transferência de grande volume de documentos em papel -> Transferênciade documentos em formato electrónico

W (Weltanschauung) Optimizar o processo de submissão de teses, desde a conclusão daelaboração da tese até a entrega em formato electrónico à biblioteca. Asconsequências serão a diminuição do volume de papéis, a facilitação e aagilização do processo.

O (Donos) Faculdade de EngenhariaE (Envolvente) Restrições impostas pelo regulamento de doutoramento da Universidade

do Porto;

As pessoas mais conservadoras não sentem-se à vontade com documentoselectrónicos e atribuem pouca segurança à assinatura digital.

5

2.3. Modelo ConceptualO 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 oprocedimento actual não prevê.

O processo de transferência de documentos electrónicos assinadosdigitalmente 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 eencaminhamento de documentos.

7

2.5. Comparação com a situação actual

Actividade Ideal Presente Diferenças MudançasCandidato solicita permissãopara procedimento de pósgraduação.

Candidato preenche oformulário on-line e submetea tese, o resumo em inglêsfrancês e português e seuCurriculum Vitae formatoPDF e assinada"digitalmente", por ele epelo orientador.

Candidato preenche oformulário em papel eentrega-o, junto com 8cópias da tese, 8 cópias doresumo em inglês, francês eportuguês e 8 cópias doCurriculum Vitae,à secretaria de pós-graduação.

Grande volume de papel;

O Doutorando está sujeito aoperíodo de funcionamento dasecretaria de pós-graduação.

Nenhum documento empapel;

Solicitação efectuadaimediatamente.

Comissão de Doutoramentonomeia Examinadores edefine a data para a defesa

Comissão emite despacho,on-line, de nomeação dojúri.

Comissão encaminha àsecretaria de pós-graduaçãodespacho de nomeação doJúri.

Doutorando é informado danomeação do Júri pelasecretaria de pós-graduação.

Doutorando é informado,através de e-mail, a respeitoda nomeação do júriimediatamente após aemissão do despacho.

Júri reúne-se e profereDespacho Liminar

Júri submete o despachoassinado "digitalmente".

Júri envia despacho àsecretaria de pós-graduaçãoque por sua vez comunicaráao candidato.

Demora entre a emissão dodespacho e ciência docandidato, já que odocumento passa pelasecretaria de pós-graduação.

Doutorando toma ciência dodespachoimediatamente. Pois osistema efectua o aviso pore-mail.

Candidato Corrige a tese (Senecessário)

Reformula a tese, assina-a"digitalmente" e envia-a on-line.

Reformula a tese, emite-aem um número de cópiasigual ao número deelementos do júri.

Grande volume de papel;

Doutorando está sujeito aoperíodo de funcionamento dasecretaria de pós-graduação.

Nenhum documento empapel;

Tese corrigida éencaminhada imediatamente.

Candidato apresenta edefende a tese

Em sessão pública. Em sessão pública. - -

8

Actividade Ideal Presente Diferenças MudançasJúrireúne-se e emite resultadofinal

Resultado é assinado"digitalmente" por todos osmembros do Júri esubmetido ao sistema deEDMS.

Resultado é assinado portodos os membros do Júri eencaminhado à secretaria depós-graduação.

Demora entre a emissão doresultado e ciência dodoutorando, já que odocumento passa pelasecretaria de pós-graduação.

Doutorando toma ciência doresultado imediatamente.Pois o sistema efectua oaviso por e-mail.

Candidato efectuaalterações supervisionadopelo orientador

Após efectuadas asalterações, o orientadorassina o relatório e ocandidato submete orelatório.

Essa actividade não existeactualmente.

- A tese deve ser alteradamediante as exigências dojúri.

Candidato consolida a versão final da tesee a envia à secretaria de pós-graduação

A tese ganha o formato deum livro.Candidato envia 6 cópias daversão final à secretaria depós-graduação. Uma dessascópias vai para a biblioteca.

Idem - -

Envia versão final da tese, em formato electrónico, à biblioteca

Submete, on-line, a tese emformato PDF à biblioteca.

Essa actividade não existe. A tese é enviada, em papel, àbiblioteca através dasecretaria de pós-graduação.

-

Comissão de Doutoramentoconfere grau ao candidato

O candidato recebe o título. Idem - -

9

3. Especificação de Requisitos do Sistema de EDMSEsse 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 GeralA seguir serão descritos os objectivos, o propósito e o âmbito do sistema.

3.1.1. PropósitoO 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 sistemaEsse 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 assinaturasdigitais. 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 abreviaturasVeja no apêndice.

3.1.4. ReferênciasVeja no apêndice.

3.1.5. Visão GeralO 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. PerspectivasNã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çõesO 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 utilizadoresO 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ós-

Graduaçã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. AutenticidadeAssinar "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çaO 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ênciasO 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 utilizadorO 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 HardwareO software deverá utilizar o protocolo HTTPS.

3.3.1.3. Interfaces com outro softwareO 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 pelodesenvolvimento 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çõesO sistema estará acessível através da Internet e através da Intranet da FEUP.

3.3.2. Requisitos funcionaisA 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 Performancea) 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 DesenvolvimentoNão aplicável

3.3.5. Requisitos não funcionaisa) 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çaO 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. DisponibilidadeO sistema deverá estar disponível 24 horas por dia durante 7 dias por semana.

3.3.8.3. SegurançaTodos 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çãoTodas 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. PortabilidadeO sistema deverá ser desenvolvido utilizando uma linguagem de programação não-

proprietá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ãoCom 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 abreviaturasEDMS: 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-03-

2004].

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údoAs 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. XMLO 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 DigitalNo 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étricaPode 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 sigiloNesse 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 documentoNesse 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 sigiloPara 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 HashUma 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 HashO 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çaNo 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-CardsO 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 RSAO 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