ANDRÉ LUIZ KANZLER ESTÁGIO CURRICULAR I E II DI – DOCUMENT IMAGE 2.0 EMPRESA: SELBETTI GESTÃO DE DOCUMENTOS SA SETOR: DESENVOLVIMENTO SUPERVISOR: RAFAEL BRYCH ORIENTADOR: CRISTIANO DAMIANI VASCONCELLOS CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS CENTRO DE CIÊNCIAS TECNOLÓGIAS - CCT UNIVERSIDADE DO ESTADO DE SANTA CATARINA – UDESC JOINVILLE SANTA CATARINA - BRASIL OUTUBRO - 2011 APROVADO EM ........../........../.......... ________________________________ Professor Cristiano Damiani Vasconcellos Bacharelado em Ciência da Computação – PUC-PR – 1993 Mestre em Engenharia Elétrica e Informática Industrial – UTFPR – 1997 Doutorado em Ciências da Computação – UFMG - 2004 Professor Orientador ________________________________ Professor Gilmário Barbosa dos Santos Bacharel em Processamento de Dados – UFBA- 1996 Mestre em Ciências da Computação –UFSC - 1999 ________________________________ Professor Kariston Pereira Tecnólogo em Processamento de Dados – UDESC Bacharel em Ciência da Computação – UDESC Especialista em Ciência da Computação/Redes de Computadores – UFSC Mestre em Ciência da Computação - UFSC Doutor em Engenharia e Gestão do Conhecimento - UFSC ________________________________ Rafael Brych Supervisor da CONCEDENTE Carimbo da Empresa UNIDADE CONCEDENTE Razão Social: Selbetti Gestão de Documentos SA CGC/MF: 83.483.230/0001-86 Endereço: Av. Getúlio Vargas, 408 Bairro: CEP: 89202-000 Cidade: Joinville UF: SC Fone: (47) 3441-6000 Supervisor: Rafael Brych Cargo: Product Owner ESTAGIÁRIO Nome: André Luiz Kanzler Matrícula: 211220927 Endereço: Rua Carlos Stamm, 283 Bairro: Vila Nova CEP: 89237-010 Cidade: Joinville UF: SC Fone: 34390654 Curso de: Tecnologia em Análise e Desenvolvimento de Sistemas Título do Estágio: DI – Document Image 2.0 Período: 01/09/2011 a 26/10/2011 Carga horária: 240 AVALIAÇÃO FINAL DO ESTÁGIO I e II PELO CENTRO DE CIÊNCIAS TECNOLÓGICAS Representada pelo Professor da Disciplina: CONCEITO FINAL DO ESTÁGIO I e II NOTA ETG I (Média do Processo) NOTA ETG II (Média do Processo) Rubrica do Professor da Disciplina Excelente (9,1 a 10) Muito Bom (8,1 a 9,0) Joinville Bom (7,1 a 8,0) Regular (5,0 a 7,0) Reprovado (0,0 a 4,9) ____/____/______ Nome do Estagiário: André Luiz Kanzler QUADRO I AVALIAÇÃO NOS ASPECTOS PROFISSIONAIS Pontos QUALIDADE DO TRABALHO: Considerando o possível. 4 ENGENHOSIDADE: Capacidade de sugerir, projetar, executar modificações ou inovações. 5 CONHECIMENTO: Demonstrado no desenvolvimento das atividades programadas. 4 CUMPRIMENTO DAS TAREFAS: Considerar o volume de atividades dentro do padrão razoável. 5 ESPÍRITO INQUISITIVO: Disposição demonstrada para aprender. 5 INICIATIVA: No desenvolvimento das atividades. 5 SOMA 28 QUADRO II AVALIAÇÃO DOS ASPECTOS HUMANOS Pontos ASSIDUIDADE: Cumprimento do horário e ausência de faltas. 5 DISCIPLINA: Observância das normas internas da Empresa. 5 SOCIABILIDADE: Facilidade de se integrar com os outros no ambiente de trabalho. 5 COOPERAÇÃO: Disposição para cooperar com os demais para atender as atividades. 5 SENSO DE RESPONSABILIDADE: Zelo pelo material, equipamentos e bens da empresa. 5 SOMA 25 PONTUAÇÃO PARA O QUADRO I E II Sofrível - 1 ponto, Regular - 2 pontos, Bom - 3 pontos, Muito Bom - 4 pontos, Excelente - 5 pontos LIMITES PARA CONCEITUAÇÃO AVALIAÇÃO FINAL Pontos De 57 a 101 - SOFRÍVEL SOMA do Quadro I multiplicada por 7 196 De 102 a 147 - REGULAR SOMA do Quadro II multiplicada por 3 75 De 148 a 194 - BOM SOMA TOTAL 271 De 195 a 240 - MUITO BOM De 241 a 285 - EXCELENTE Nome da Empresa: Selbetti Gestão de Documentos Representada pelo Supervisor: Rafael Brych CONCEITO CONFORME SOMA TOTAL Rubrica do Supervisor da Empresa Local: Data: Carimbo da Empresa UDESC UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS - FEJ PLANO DE ESTÁGIO CURRICULAR I e II ESTAGIÁRIO Nome: André Luiz Kanzler Matrícula: 211220927 Endereço (Em Jlle): Rua Carlos Stamm, 283 Bairro: Vila Nova CEP: 89237-010 Cidade: Joinville UF: SC Fone: (47) 3439-0654 Endereço (Local estágio): Selbetti Gestão de Documentos SA Bairro: Centro CEP: 89202-000 Cidade: Joinville UF:SC Fone: 3441-6000 Regularmente matriculado no semestre: 02/2011 Curso: Tecnologia em Análise e Desenvolvimento de Sistemas Formatura (prevista) Semestre/Ano: 2012/01 UNIDADE CONCEDENTE Razão Social: Selbetti Gestão de Documentos SA CGC/MF: 83.483.230/0001-86 Endereço: Av. Getúlio Vargas, 408 Bairro: Centro CEP: 89202-000 Cidade: Joinville UF: SC Fone: (47) 3441-6000 Atividade Principal: Gestão de Documentos Supervisor: Rafael Brych Cargo: Product Owner DADOS DO ESTÁGIO Área de atuação: Programação de Sistemas Departamento de atuação: Desenvolvimento Fone: (47) 3441-6000 Ramal: 6029 Horário do estágio: 08:00 as 12:00 / 13:30 as 15:30 Total de horas: 240 Período: 01/09/2011 a 27/10/2011 Nome do Professor Orientador: Cristiano Damiani Vasconcellos Disciplina(s) simultânea(s) com o estágio Quantas: 7 Quais: DIR – SI – Direito Aplicado GPR – Gerencia de Projetos MCI-SI – Metodologia Científica PES – SI – Pesquisa Operacional REC – Rede de Computadores SOR – Sociologia das Organizações TES-12 – Análise e Projeto de Sistemas Avançados OBJETIVO GERAL Atuar na área de desenvolvimento de sistemas, com a análise, desenvolvimento e testes do sistema DI - 2.0 (Document Image 2.0), para melhorar tanto a qualidade e usabilidade do produto, quanto o código para futuras modificações no sistema. O DI é um módulo de um sistema ECM (Enterprise Content Management OU Gestão de Conteúdo Empresarial), o qual é responsável por captura e indexação de imagem em um sistema ECM. ATIVIDADES OBJETIVO ESPECÍFICO HORAS 1 - ANÁLISE 1.1 - Levantamento de requisitos 1.2 - Criar documento de requisitos 2 - DESENVOLVIMENTO 2.1 - Elaboração do produto 3 – TESTES 3.1 - Testes manuais 3.2 - Criação do manual para o usuário 1.1 - Realizar o levantamento de requisitos, de acordo com a versão 1.0 do sistema, para identificar as alterações necessárias para melhorá- lo. Verificar com as pessoas que estão em contato diariamente com os clientes, para analisar as reais necessidades e melhorias que os clientes possuem. 1.2 - Após o levantamento de requisitos, criar o documento com todos os requisitos levantados para que o sistema seja desenvolvido conforme o especificado 2.1 – Desenvolvimento do sistema, de acordo com o documento de requisitos criado. 3.1 – Realizar os testes manuais para verificar se o sistema foi desenvolvido de acordo com o especificado e se irão atender as necessidades dos usuários. 3.2 – Para a utilização do sistema, será necessário que os usuários saibam as alterações que ocorreram e as novas funcionalidades. 30 20 150 20 20 Rubrica do Professor Orientador Rubrica do Comitê de Estágios Rubrica do Coordenador de Estágios Rubrica do Supervisor da Empresa Data: Data: Data: Data: Carimbo da Empresa CRONOGRAMA FÍSICO E REAL PERÍODO (10 horas) ATIVIDADES P R 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 20 21 22 23 24 Levantamento de requisitos P R Criar documento de requisitos P R Desenvolvimento do sistema P R Testes manuais P R Criação do manual do usuário P R Análise das atividades de leitura obrigatória e aprovação de documento P R Desenvolvimento das atividades de leitura obrigatória P R Testes manuais da atividade de leitura obrigatória P R Desenvolvimento das atividades de aprovação de documento P R Testes manuais das atividades de aprovação de documento P R Ajustes nos erros encontrados durante os testes manuais P R Legenda: Programado Realizado Aos meus pais Sandra Zoller Kanzler E Adolar Kanzler AGRADECIMENTOS Muitas pessoas e empresas tornaram-se merecedoras do nosso reconhecimento, pelo muito que colaboraram para a realização deste trabalho, dentre elas destacam-se: Meus pais, os quais nunca deixaram de acreditar no meu potencial e sempre deram o apoio necessário para concluir o curso; A Selbetti, a qual me oportunizou a realizar o estágio obrigatório. Aos professores, os quais não mediram esforços para repassar os seus ensinamentos. Aos amigos que acompanharam a minha caminhada na vida universitária. SUMÁRIO LISTA DE FIGURAS ............................................................................................................. XII RESUMO ................................................................................................................................ XIV 1 INTRODUÇÃO ...................................................................................................................... 15 1.1.1 Objetivo Geral .................................................................................................................... 15 1.1.2 Objetivos Específicos .............................................................................................................. 16 1.1.2.1 Atividades de Análise: ..................................................................................................... 16 1.1.2.2 Atividades de Desenvolvimento ...................................................................................... 16 1.1.2.3 Atividades de Testes ........................................................................................................ 16 1.1.3. Justificativa ............................................................................................................................. 16 1.2 ORGANIZAÇÃO DO ESTUDO ..................................................................................................... 17 2 A EMPRESA .......................................................................................................................... 18 2.1 HISTÓRICO ................................................................................................................................... 18 2.2 PRINCIPAIS PRODUTOS ............................................................................................................. 19 2.2.1 SmartCount .............................................................................................................................. 19 2.2.2 SmartGreen .............................................................................................................................. 20 2.2.3 SmartShare .............................................................................................................................. 21 2.3 PRINCIPAIS CLIENTES ............................................................................................................... 22 2.3.1 Clientes que possuem SmartCount .......................................................................................... 22 2.3.2 Clientes que possuem SmartGreen .......................................................................................... 23 2.3.3 Clientes que possuem SmartShare ........................................................................................... 23 2.4 CONSIDERAÇÕES GERAIS ......................................................................................................... 23 3 CONCEITOS .......................................................................................................................... 24 3.1 LINGUAGEM DE PROGRAMAÇÃO ........................................................................................... 24 3.3 ECM - ENTERPRISE CONTENT MANAGEMENT .................................................................... 25 3.4 DI - DOCUMENT IMAGE ............................................................................................................ 26 3.5 INDEXAÇÃO DE DOCUMENTOS .............................................................................................. 26 3.6 OCR - OPTICAL CHARACTER RECOGNITION ....................................................................... 26 3.7 DESENVOLVIMENTO RÁPIDO DE SOFTWARE ..................................................................... 28 3.7.1 SCRUM ................................................................................................................................... 28 3.8 WEB SERVER ................................................................................................................................ 30 4 ATIVIDADES DESENVOLVIDAS ..................................................................................... 32 4.1 LEITURA OBRIGATÓRIA DE DOCUMENTO ........................................................................... 32 4.2 APROVAÇÃO DE PUBLICAÇÃO DE DOCUMENTO ............................................................... 37 4.4 ANÁLISE DO SISTEMA DI 2.0 ..................................................................................................... 44 4.4.1 Levantamento de Requisitos .................................................................................................... 44 4.4.1.1 Client ............................................................................................................................... 44 4.4.1.2 Server............................................................................................................................... 48 4.4.1.3 Web Site ........................................................................................................................... 49 4.4.2 Fluxograma .............................................................................................................................. 52 4.4.2.1 Client ............................................................................................................................... 52 4.4.2.2 Server............................................................................................................................... 53 4.4.3 Protótipo de Telas ................................................................................................................... 54 CONSIDERAÇÕES FINAIS ................................................................................................... 58 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 60 GLOSSÁRIO ............................................................................................................................. 62 ANEXOS .............................................................................................................................. LXIII ANEXO A .......................................................................................................................................... LXIII ANEXO B ......................................................................................................................................... LXVII LISTA DE FIGURAS FIGURA 2.1 - HISTÓRICO DA SELBETTI ......................................................................... 19 FIGURA 2.2 - TELA INICIAL DO SMARTCOUNT ........................................................... 20 FIGURA 2.3 - CONFIGURAÇÃO DE EMAIL DO SMARTGREEN ................................ 21 FIGURA 2.4 - TELA INICIAL DO SMARTSHARE ............................................................ 22 FIGURA 3.1 – EXEMPLO DE DIGITALIZAÇÃO E UTILIZAÇÃO DO OCR ............... 27 FIGURA 3.2 – FUNCIONAMENTO DO SCRUM ................................................................ 30 FIGURA 3.3 – SERVIDOR WEB SERVER .......................................................................... 31 FIGURA 4.1 - DESTAQUE PARA DOCUMENTOS QUE NÃO FORAM LIDOS .......... 33 FIGURA 4.2 - MENU DE ATIVIDADES ECM .................................................................... 33 FIGURA 4.3 - NOVA LISTAGEM DE DOCUMENTOS NÃO LIDOS ............................. 33 FIGURA 4.5 - TELA DE PUBLICAÇÃO DE DOCUMENTO ............................................ 35 FIGURA 4.6 - RELATÓRIO DE DOCUMENTOS NÃO LIDOS POR DOCUMENTO .. 36 FIGURA 4.7 - RELATÓRIO DE DOCUMENTOS NÃO LIDOS POR USUÁRIO .......... 36 FIGURA 4.8 - GERENCIAMENTO DE TIPO DE DOCUMENTO ................................... 38 FIGURA 4.9 - GERENCIAMENTO DE TIPO DE DOCUMENTO ................................... 39 FIGURA 4.10 – TELA DE PUBLICAÇÃO DE DOCUMENTOS ....................................... 40 FIGURA 4.11 - MENU DE ATIVIDADES ECM .................................................................. 40 FIGURA 4.12 – LISTAGEM DE DOCUMENTOS A SEREM APROVADOS ................. 41 FIGURA 4.13 – VISUALIZADOR DE DOCUMENTOS COM A OPÇÃO DE APROVAÇÃO DO DOCUMENTO ........................................................................................ 41 FIGURA 4.14 – VISUALIZAÇÃO DE DOCUMENTO COM OS VOTOS DOS USUÁRIOS ................................................................................................................................ 42 FIGURA 4.15 – MENU DE ATIVIDADES ECM- DOCUMENTOS AGUARDANDO APROVAÇÃO ........................................................................................................................... 43 FIGURA 4.16 – LISTAGEM DOS DOCUMENTOS PUBLICADOS AGUARDANDO APROVAÇÃO ........................................................................................................................... 43 FIGURA 4.17 – FLUXOGRAMA DO APLICATIVO CLIENT .......................................... 52 FIGURA 4.18 – FLUXOGRAMA DO APLICATIVO SERVER ......................................... 53 FIGURA 4.19 – PROTÓTIPO DE GERENCIAMENTO DO APLICATIVO CLIENT ... 54 FIGURA 4.20 – PROTÓTIPO DA TELA DE VISUALIZAÇÃO E INDEXAÇÃO DE DOCUMENTOS........................................................................................................................ 55 FIGURA 4.21 – PROTÓTIPO DA TELA DE GERENCIAMENTO DO WEB SITE ....... 56 FIGURA 4.22 – PROTÓTIPO DA TELA DE ACOMPANHAMENTO DE PUBLICAÇÕES ........................................................................................................................ 57 RESUMO Este relatório de estágio tem como objetivo mostrar as atividades que foram realizadas durante o período de estágio realizado na empresa Selbetti. Como objetivo principal do estágio é a análise, desenvolvimento e testes do módulo DI – Document Image 2.0. Porém, primeiramente foram realizadas atividades de melhorias no sistema SmartShare, o qual por necessidades e prioridades de clientes, teve que ser desenvolvido primeiramente, e com isso o desenvolvimento do módulo DI 2.0 teve que ser adiado. Este relatório irá explicar mais detalhadamente os conceitos sobre os sistemas de ECM, Document Image entre outros conceitos e também as atividades que foram realizadas no período de estágio. 1 INTRODUÇÃO A Selbetti Gestão de Documentos tem como principal ramo de atividade o aluguel de impressoras e também sistemas para o gerenciamento de documentos de uma empresa. Em relação à gestão de documentos, a empresa possui diversos sistemas, no qual se pode citar o SmartCopy, SmartGreen e SmartShare. O sistema SmartCopy realiza a contabilização de impressões, o SmartGreen tem como objetivo a conscientização das pessoas em relação às impressões realizadas e o SmartShare é o sistema de gerenciamento de conteúdo de uma empresa, podendo armazenar qualquer documento que uma empresa possui, desde manuais, contratos até apresentações, músicas, entre outros, para que seja acessível a todos os funcionários da empresa. As atividades desenvolvidas neste estágio têm como escopo o sistema SmartShare. 1.1 OBJETIVOS O objetivo principal deste estágio é a reformulação de um módulo do SmartShare, que é o DI - Document Image, e esta nova versão será chamada de DI 2.0. Este módulo é responsável pela indexação de um documento, criar uma imagem onde é possível retirar informações importantes do documento, criar palavras para busca e publicar este documento no sistema. Assim, este documento poderá ser encontrado no SmartShare pelas pessoas que tiverem permissão de acesso para pesquisas e até mesmo edição do documento. 1.1.1 Objetivo Geral Atuar na área de desenvolvimento de sistemas, com a análise, desenvolvimento e testes do sistema DI 2.0, para melhorar tanto a qualidade e usabilidade do produto, quanto o código para futuras modificações no sistema. Este módulo é responsável por indexar um documento, tratamento da imagem para extração de informações, permitindo uma pesquisa mais rápida e acesso mais fácil aos documentos e publicação dos mesmos no SmartShare. Realizar melhorias no sistema, de acordo com as necessidades dos clientes. 16 1.1.2 Objetivos Específicos Os objetivos específicos estão divididos em três grandes atividades: Análise, Desenvolvimento e Testes. 1.1.2.1 Atividades de Análise: - Realizar o levantamento de requisitos, de acordo com a versão 1.0 do DI, para identificar as alterações necessárias no objetivo de melhorar o produto. Verificar com as pessoas que estão em contato diariamente com os clientes, para analisar as reais necessidades e melhorias que os clientes possuem. - Após o levantamento de requisitos, criar o documento com todos os requisitos levantados para que o mesmo seja desenvolvido, e que seja desenvolvido conforme o especificado. 1.1.2.2 Atividades de Desenvolvimento - Criar o banco de dados, para que atenda as necessidades do produto e conforme documento de requisitos. - Desenvolvimento do produto, de acordo com o documento de requisitos criado. 1.1.2.3 Atividades de Testes - Realizar os testes manuais para verificar se o sistema foi desenvolvido de acordo com o especificado e se irão atender as necessidades dos usuários. - Para a utilização do produto, será necessário que os usuários saibam as alterações que ocorreram e as novas funcionalidades que o produto terá através da criação de um manual, que estará disponível para os mesmos. 1.1.3. Justificativa 17 Atualmente, a empresa possui a versão 1.0 do sistema DI - Document Image. Porém, essa versão apresenta alguns erros e algumas funcionalidades não estão executando adequadamente, onde a alta complexidade torna inviável a utilização do sistema. Com isso, resolveu-se desenvolver a versão 2.0 do sistema, porém essa nova versão é um projeto inteiramente novo, da versão anterior foi considerado apenas o levantamento de requisitos como base para o projeto do sistema. 1.2 ORGANIZAÇÃO DO ESTUDO Este documento mostrará no segundo capítulo, um pouco da história da empresa, seus produtos e alguns dados, como quantidade de funcionários, área de atuação e outras informações sobre a empresa. No terceiro capítulo, serão mostrados os conceitos que serão utilizados no desenvolvimento do sistema e entendimento das necessidades da empresa. Para o desenvolvimento será necessário a criação de alguns documentos que auxiliarão o entendimento das necessidades e como deverá ficar o sistema. No quarto capítulo, serão mostradas as atividades que foram realizadas durante o período de estágio. Por fim, no quinto capítulo será mostrada a conclusão do estágio, com as atividades que realmente foram desenvolvidas, as dificuldades, aprendizados e o resultado final do estágio. 18 2 A EMPRESA 2.1 HISTÓRICO A história da Selbetti começa no ano de 1977, onde a empresa inicia as suas atividades na venda de máquinas de escrever, da marca Olivetti, e também móveis para escritório. No ano de 1982, surgem novas tendências de mercado e máquinas mais modernas, e com isso novos produtos para ser vendidos, como a máquina de escrever eletrônica, caixas registradoras e o Telex. A partir do ano de 1990, a Selbetti muda o seu foco e começa a ver uma grande oportunidade em vendas das máquinas copiadoras da Olivetti e impressoras a jato de tinta, que estavam surgindo no mercado. Com muitas empresas terceirizando seus serviços de impressão, o aluguel de impressoras multifuncionais se tornou um mercado promissor, pois as empresas não queriam gastar seu tempo se preocupando com as impressoras e sim deixar por conta de uma empresa e pagar pelo serviço. Com a empresa nos dois ramos de atuação, móveis para escritório e aluguel de impressoras, no ano de 2005 a Selbetti separou-se em duas empresas, a Selbetti Ambientes e Selbetti Gestão de documentos. Neste mesmo ano, a SELBETII Gestão de Documentos começa a dar os primeiros passos no ramo de desenvolvimento de software, voltado para a gestão de documentos e contabilização de impressões, permitindo o gerenciamento e o acompanhamento de impressões. No ano de 2008, a Selbetti realizou um dos seus maiores case de sucesso, ao ganhar a licitação de outsourcing de impressão do estado de Santa Catarina, onde todos os prédios públicos iriam ter impressoras e multifuncionais instalados por responsabilidade da Selbetti. Neste projeto, foram instalados aproximadamente 2500 equipamentos, desde impressoras pequenas, multifuncionais, até impressoras de grande porte, com grande capacidade de realizar cópias. Com o crescimento da empresa, no ano de 2010 a Selbetti tornou-se uma empresa S/A, Sociedade Anônima, porém de capital fechado. A Figura 2.1 mostra a evolução da Selbetti durando o decorrer dos anos. 19 Figura 2.1 - Histórico da Selbetti Fonte: Selbetti 2.2 PRINCIPAIS PRODUTOS 2.2.1 SmartCount “É um software de controle e gerenciamento de impressão. Com ele é possível monitorar tudo que é impresso dentro de uma organização como quem, quando, qual documento, colorido ou PB, tipo de papel, aplicativo entre outras propriedades de impressão.” (SELBETTI, 2011). Com isso, fica a responsabilidade do sistema gerar relatórios e controlar tudo que é impresso dentro de uma empresa. A Figura 2.2 mostra a tela inicial do SmartCount. 20 Figura 2.2 - Tela inicial do SmartCount Fonte: Selbetti 2.2.2 SmartGreen “Módulo de conscientização ambiental, onde será possível, de forma parametrizada, avisar o(s) usuário(s) através de mensagens o quanto a empresa ou os usuários gastam em água e árvores para produzir o papel necessário das impressões realizadas”. (SELBETTI, 2011). A Figura 2.3 mostra a tela de configuração de envio de email com o objetivo de alertar os usuários a respeito da responsabilidade ambiental quando um determinado número de páginas for impressas. 21 Figura 2.3 - Configuração de email do SmartGreen Fonte: Selbetti 2.2.3 SmartShare “Essa é a solução para gestão dos fluxos de trabalho e dos documentos (ECM/BPM). Todos os arquivos são disponibilizados em um portal para que possam ser acessados de qualquer lugar através de uma interface WEB.” (SELBETTI, 2011) As atividades descritas nesse relatório foram realizadas no SmartShare, o qual é possível realizar a busca de documentos que forem digitalizados e indexados pelo módulo DI 2.0. O SmartShare pode armazenar todo o conteúdo de uma empresa, desde vídeos, apresentações, até documentos como contrato, manuais entre outros. Ou seja, quaisquer documentos que a empresa desejar armazenar em um meio digital visando uma maior 22 organização, confiabilidade e possibilitando que a busca seja realizada de maneira mais ágil. A Figura 2.4 é mostrada a tela inicial do SmartShare. Figura 2.4 - Tela inicial do SmartShare Fonte: Selbetti 2.3 PRINCIPAIS CLIENTES 2.3.1 Clientes que possuem SmartCount Atualmente, a Selbetti possui diversos clientes com o software instalado, dentre os quais podemos destacar: TUPY, Intelbras, Univille, Tuper. 23 2.3.2 Clientes que possuem SmartGreen Todos os clientes que possuem o SmartGreen possuem também o SmartCount. Dentre os clientes que possuem ativo o módulo SmartGreen no SmartCount, podemos destacar: Tuper, Back, Viqua. 2.3.3 Clientes que possuem SmartShare Os principais clientes que possuem o SmartShare instalado são: CELESC, Berlanda, MM Mercado Móveis. 2.4 CONSIDERAÇÕES GERAIS A Selbetti está dividida em duas empresas com focos diferentes. A Selbetti Gestão de Documentos, a qual é responsável pelo aluguel de impressoras, sistemas de gerenciamento de documentos, entre outros e a Selbetti Ambientes, a qual é responsável pela comercialização de móveis. De acordo com o sistema interno de consulta de funcionários, no dia 12 de setembro de 2011, a empresa possuía 283 funcionários. A empresa fornece diversos benefícios para os funcionários e também realiza alguns projetos culturais. O funcionário recebe vale alimentação, vale transporte, plano de saúde, auxilio bolsa de estudo e cartão Good Card. Para incentivar os funcionários, a empresa colabora com o lar Abdon Batista todo mês e procura realizar alguns eventos durante o ano para que o funcionário vá até a instituição e conheça o trabalho realizado e também as pessoas que estão recebendo o benefício da mesma. 24 3 CONCEITOS 3.1 LINGUAGEM DE PROGRAMAÇÃO Linguagem de programação é o meio de comunicação entre os seres humanos e o computador, podendo assim, criar programas e fazer com que o computador faça o que o ser humano deseja que ele faça (ANDRADE, 2007). A linguagem de programação veio a ajudar os seres humanos a criar programas que resolvam problemas diários ou necessidades que enfrentam. A linguagem utilizada no estágio é C# (C-sharp), que é uma linguagem de alto nível e necessita ser compilada para ser executada pelo computador. C# é uma linguagem de programação orientada a objetos, criada pela Microsoft e faz parte da sua plataforma .Net (dot Net). O C# foi desenvolvido baseando-se em C++, Java e Pascal em 1999, por uma equipe liderada por Anders Hejlsberg, que foi chamado primeiramente de Cool e no lançamento da plataforma .Net mudou o nome para C#. (PACIEVITCH, 2011). O C# é utilizado para executar a regra de negócio do sistema e o acesso ao banco de dados. A linguagem de programação utilizada para realizar a interface com o usuário é o ASP, o qual se pode criar e executar páginas Web dinâmicas e aplicações interativas com o usuário. Com o ASP, podem-se utilizar comandos HTML, componentes e comandos de Script, criando assim aplicações Web de maneira fácil de desenvolver e modificar. (MICROSOFT, 2011). O ASP consegue realizar a comunicação com o C# e assim, cada linguagem fica responsável por realizar o seu papel, ASP com a interface e C# com a regra de negócio e comunicação com banco de dados. Para auxiliar no desenvolvimento, utilizou-se a linguagem de programação Javascript, que auxilia o ASP com a interface do sistema. Ela é responsável por executar alguns comandos de maneira rápida no navegador do usuário, não necessitando da intervenção do servidor. Com isso, é possível deixar a página mais dinâmica, alterando cores, escondendo partes da página entre outros efeitos na página. (ALVAREZ, 2004). O Javascript permite que o programador deixe a página mais dinâmica para a utilização do usuário e deixar o processamento da execução dos comandos com responsabilidade do navegador. Para a programação, foi utilizado o programa Visual Studio 2008, o qual foi criado pela empresa Microsoft e com o auxílio do framework Telerik, que auxilia na construção de telas e componentes da tela, tornando o visual muito mais bonito e atraente. 25 3.2 BANCO DE DADOS Um SGBD - Sistema de Gerenciamento de Banco de dados é responsável por administrar uma série dados que possuem ligação entre eles e deve possuir um ambiente que seja confiável e eficiente para realizar consultas e armazenar qualquer informação. (KORTH e SILBERSCHATZ, 1989). Um SGBD é criado para manipular uma quantidade grande de informações, e possui ferramentas para o armazenamento correto e manipulação dos dados, quando for requisitada alguma consulta. O SGBD deve ter mecanismos confiáveis para armazenar as informações para evitar um acesso desautorizado ao banco de dados, mesmo que ocorra a queda no sistema. (KORTH e SILBERSCHATZ, 1989). O banco de dados utilizado para a realização deste estágio é o SQL SERVER 2005. As informações armazenadas no mesmo serão de forma relacional, onde tudo que for armazenado diretamente no banco de dados será em forma de dados, dentro de tabelas. O SQL SERVER é da empresa Microsoft, que possui a versão gratuita Express. Esta versão do banco de dados possui menos recursos que as versões pagas, porém atende as necessidades da empresa para o armazenamento de dados. 3.3 ECM - ENTERPRISE CONTENT MANAGEMENT ECM ou Gestão de Conteúdo Empresarial são métodos, estratégias e ferramentas que são utilizadas para gerenciar, capturar, armazenar, preservar e fornecer para qualquer pessoa que necessite de um documento relacionado a uma empresa. As ferramentas ECM permitem a organização e gerenciamento de todos os conteúdos que uma empresa possui. (AIIM, 2011). O sistema ECM da Selbetti é o SmartShare, que é responsável por realizar todo o armazenamento e organização dos conteúdos de uma empresa. Após o armazenamento do documento, é possível realizar buscas ou navegar em pastas para encontrar os documentos. 26 3.4 DI - DOCUMENT IMAGE O DI é um sistema que utiliza equipamentos e sistemas específicos para a captação, armazenamento, visualização, indexação e impressão de imagens de documentos. (FRANCO e BARREIRO, 2007). Ou seja, é o processo de transformar um documento físico, como por exemplo, um contrato, em um documento digital, através de uma imagem e pode ser armazenado em um sistema ECM, através da indexação do documento utilizando um sistema de reconhecimento de caracteres, para se tornar disponível e procurado posteriormente por qualquer pessoa que possua permissão para leitura do documento. A grande vantagem de guardar uma cópia digital é que ela não se deteriora com o tempo, e as chances de perder este documento são quase nulas, pois uma vez armazenada no sistema, ficará lá até que alguém apague o mesmo. 3.5 INDEXAÇÃO DE DOCUMENTOS A indexação de documentos possibilita atribuir determinados índices para as imagens de documentos, o qual pode ser recuperado após o armazenamento da imagem. Para realizar a extração de informações de uma imagem de um documento, pode-se utilizar a ferramenta OCR - Optical Character Recognition ou Reconhecimento Ótico de Caracteres, o qual realiza esta função. (FRANCO e BARREIRO, 2007) O módulo DI do sistema SmartShare utiliza OCR para extrair a informação que será usada na indexação dos documentos. 3.6 OCR - OPTICAL CHARACTER RECOGNITION OCR é o processo automático que realiza o reconhecimento de caracteres em uma imagem e realiza a tradução para caracteres e podem ser armazenados em um banco de dados, tornando-se índice de um documento. Com isso, economiza espaço de armazenamento e é possível realizar pesquisas para procurar o documento armazenado, de acordo com a indexação realizada (Figura 3.2). O reconhecimento preciso de caracteres depende de alguns 27 fatores, como por exemplo, resolução da imagem, brilho, contraste, número de pontos, entre outros. O módulo DI 2.0 realiza a indexação de documentos físicos. Os documentos necessitam de índices para serem armazenados no SmartShare e os usuários poderão utilizar os índices para pesquisar os documentos de maneira prática e rápida. Como essas informações estão no próprio documento, para evitar que os usuários tenham que digitar as informações dos documentos um a um manualmente, o DI 2.0 utiliza da tecnologia OCR para o reconhecimento de caracteres em um documento. Com isso, o processo de indexação de documentos torna-se muito mais rápido e ágil e consequentemente menos cansativo ao usuário. Figura 3.1 – Exemplo de Digitalização e utilização do OCR Fonte: http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF http://img.tfd.com/cde/OCR.GIF 28 3.7 DESENVOLVIMENTO RÁPIDO DE SOFTWARE Com a crescente demanda dos negócios globais sofrendo rápidas mudanças, é extremamente necessário o rápido desenvolvimento de um software para aproveitar às oportunidades e adequar-se as atuais necessidades das empresas para auxiliar em suas atividades. Se isso não ocorrer, um software desenvolvido por um longo período de tempo, pode não atender mais às necessidades, pois já houve diversas mudanças na regra do sistema ou negócios da empresa no qual terá que ser alterado ou algumas vezes, feito novamente. (SOMMERVILLE, 2007). No desenvolvimento rápido de software, a documentação de todo o projeto é reduzida para não se perder muito tempo nesta etapa. Com isso, o foco principal é o desenvolvimento do sistema, onde o mesmo não é entregue todo de uma vez, mas sim em incrementos, ou seja, conforme as funcionalidades ficam prontas, já são entregues para o cliente, para o mesmo realizar os primeiros testes e verificar se o que foi desenvolvido é realmente o que foi planejado e atende as suas necessidades. Caso não tenha atendido às necessidades, retorna para o time de desenvolvimento que arruma o que for necessário. 3.7.1 SCRUM Um dos tipos de modelo de desenvolvimento ágil é o SCRUM, que fornece métodos para definir o planejamento, o papel de cada pessoa e como o time irá trabalhar. O SCRUM determina o papel de cada participante, definindo assim a função de cada pessoa. Esta metodologia possui os seguintes passos: primeiramente é definido qual o produto, neste caso o software, e quais os requisitos e alterações que são necessárias realizar. Esta tarefa é realizada pelo proprietário do produto ou, em inglês, Product Owner o qual é chamado de PO. A lista de atividades a serem desenvolvidas pelo time e a prioridade de cada atividade é definida pelo PO, criando assim o Product Backlog. Após definidas todas as atividades e as respectivas prioridades, uma pessoa do time de desenvolvimento é escolhida como Scrum Master, que seria um coordenador do projeto. O PO, o Scrum Master e o time de desenvolvimento definem um período de desenvolvimento, o qual é chamado de Sprint. A Sprint possui as atividades que foram definidas no Product Backlog, onde as atividades com maiores prioridades são executadas primeiro. Todas as atividades são escritas em post- it em 29 um quadro branco, para que seja possível visualizar de maneira fácil e rápida, as atividades que não foram realizadas, as que estão em desenvolvimento e as que estão em homologação. Cada Sprint deve durar entre duas a quatro semanas, e ao final, deverá ter alguma atividade desenvolvida e entregue para o cliente. Após o término da Sprint, se o Product Backlog ainda possui atividades, são definidas novamente as atividades a serem desenvolvidas e inicia-se uma nova Sprint até que todas as atividades acabem. Porém, no meio de uma Sprint, podem ser adicionadas novas atividades no Product Backlog, conforme for necessário, e estes serão realizados em outra Sprint. Durante a Sprint, é realizada uma reunião diária de no máximo quinze minutos, onde cada integrante explana as atividades que está realizando e as suas dificuldades, para que se houver o time possa ajudar o mesmo e as atividades possam ser concluídas o quanto antes. (CISNEIROS, 2009). Este modelo de desenvolvimento é um padrão para todas as empresas que desejam segui-lo, no qual a SELBETTI vem utilizando desde o ano de 2009 e vem trazendo resultados positivos tanto para o software quanto para as pessoas, pois é uma forma muito mais interativa e participativa de desenvolvimento. Na Figura 3.2 é apresentado como funciona o desenvolvimento com a metodologia SCRUM. 30 Figura 3.2 – Funcionamento do SCRUM Fonte: http://qualidadebr.files.wordpress.com/2009/07/o-ciclo-de-trabalho-do-scrum1.jpg Com a metodologia SCRUM, todos os integrantes da equipe de desenvolvimento participam de todas as etapas na construção do software, desde a análise até os testes finais. Assim, existe um maior entendimento por parte de todos os integrantes e uma maior motivação aos desenvolvedores. Devido ao fato da metodologia de desenvolvimento rápido de software não utilizar muita documentação, este relatório possui apenas a documentação utilizada no desenvolvimento do software. Com isso, a quantidade de documentação é reduzida. A documentação utilizada na Selbetti é o Sprint Document, chamado de SD. A cada Sprint é realizado um SD para documentar as atividades que foram definidas, com o detalhamento do que deverá ser feito para que a atividade seja realizada. 3.8 WEB SERVER Web Server é um servidor que se encontra em algum lugar na internet, onde se pode saber ou não a sua localização. Sua principal função é fornecer arquivos que estão em seu disco rígido para algum computador que requisitar determinada informação e também realizar o contrário, armazenar algum arquivo que é transmitido, e tudo isto através da rede de computadores. (Bishop, 2003). No módulo DI 2.0, para a publicação de documentos, o servidor Web Server irá ser utilizado na comunicação entre o aplicativo Client e irá transferir todos os arquivos que estiverem na máquina local para o servidor, para que o aplicativo realize a publicação dos documentos. 31 Figura 3.3 – Servidor Web Server Fonte: BISHOP, 2003 32 4 ATIVIDADES DESENVOLVIDAS O objetivo principal deste estágio é a reformulação do módulo DI 2.0, onde as atividades de análise começariam no início do mês de setembro. Porém, devido à exigência de clientes, outras atividades que estavam planejadas para o final do ano, tiveram que ser desenvolvidas primeiramente. Com isso, o projeto proposto no plano de estágio não foi totalmente concluído. As atividades de análise do módulo DI 2.0 tiveram início na metade do mês de outubro. O desenvolvimento do módulo DI 2.0 não foi iniciado, pois as atividades de leitura obrigatória de documento e aprovação de documento tiveram seu desenvolvimento antecipado, prejudicando as atividades de desenvolvimento e testes referentes ao DI 2.0. Nas três primeiras semanas de desenvolvimento das atividades descrita neste relatório, o estagiário realizou o papel de Scrum Master do time do desenvolvimento, o qual é o responsável pelas alterações que ocorrem no sistema, pela cobrança da realização das reuniões diárias, pela análise de todas as alterações que devem ser realizadas no sistema, mas isso tudo, com a ajuda de todo o time. 4.1 LEITURA OBRIGATÓRIA DE DOCUMENTO A atividade de leitura obrigatória de documento seria desenvolvida no final do ano. Porém, com a necessidade da mesma em um cliente, teve seu desenvolvimento antecipado. Esta atividade tem como objetivo de, ao publicar um documento, o usuário que estiver publicando poderá escolher os perfis de usuário que deverão ler obrigatoriamente o documento. Como por exemplo, um documento de Padrões de Desenvolvimento, deverá ser lido por todos os usuários que possuírem o perfil de desenvolvimento. Para que o usuário saiba que existe um documento para ler, existem duas possibilidades. A primeira é através da listagem normal de documentos, onde antes do título do documento, estará escrito “Leitura Obrigatória” em vermelho, para dar um destaque maior ao documento (Figura 4.1). 33 Figura 4.1 - Destaque para documentos que não foram lidos Outra possibilidade, é através do menu lateral esquerdo (Figura 4.2), onde foi criado um novo painel, que poderá ser visto quantos documentos que não foram lidos. Figura 4.2 - Menu de Atividades ECM No exemplo da Figura 4.3, existem ao todo treze documentos para que o usuário realize a leitura. Ao clicar sobre a quantidade de documentos, é aberta a listagem com os documentos que ainda não foram lidos. Figura 4.3 - Nova listagem de documentos não lidos Para que o desenvolvimento da nova funcionalidade foi necessário realizar as seguintes modificações no sistema. 34 Acrescentada a opção “Requer Leitura Obrigatória” (Figura 4.4), no gerenciamento de Tipo de Documento. Figura 4.4 - Gerenciamento de Tipo de Documento Assim, quando o usuário for publicar um documento de um tipo que requer leitura obrigatória, poderão ser escolhidos os perfis que deverão ler o documento. Na tela de publicação de documentos, houve a necessidade de acrescentar uma aba, para que o usuário selecione os perfis que deverão ler o documento. Porém, para que um perfil possa ser selecionado para leitura obrigatória, este perfil deverá ter permissão para leitura do documento, onde estes perfis também são selecionados na tela de publicação de documento, na primeira aba (Figura 4.5). 35 Figura 4.5 - Tela de Publicação de Documento Para verificar se existe algum usuário que não leu algum documento, foi desenvolvido dois novos relatórios. O primeiro relatório, mostra por documento, os usuários que ainda não realizaram a leitura do documento (Figura 4.6). Outro relatório, mostra por usuário, os documentos que o mesmo não realizou a leitura do documento (Figura 4.7). Com esses relatórios, os supervisores ou responsáveis por determinado departamento, podem ter o controle dos usuários que não estão lendo os documentos e podem cobrar a leitura dos usuários. 36 Figura 4.6 - Relatório de documentos não lidos por documento Figura 4.7 - Relatório de Documentos não lidos por usuário 37 As atividades de testes foram realizadas primeiramente pela equipe que desenvolveu a atividade, que ao total foram três pessoas. Foram encontrados alguns pequenos erros, os quais foram corrigidos. Porém, com o desenvolvimento da atividade de aprovação de publicação de documento, que será explicado a seguir, houve diversas alterações a serem feitas, para se adequar as alterações que foram realizadas. Com isso, ocupou bastante tempo após a conclusão da segunda atividade, para alterar a atividade desenvolvida. Para maiores detalhes, o documento utilizado pela equipe de desenvolvimento com a descrição de todas as alterações realizadas se encontra no Anexo A. 4.2 APROVAÇÃO DE PUBLICAÇÃO DE DOCUMENTO Alguns documentos não podem ser publicados e já se tornarem vigentes e disponíveis para os usuários que possuem permissão de leitura, pois necessita ser visto e aprovado por algum grupo de pessoas. Para isso, foi criada uma regra no sistema onde é possível que esta aprovação seja realizada. Para que o documento seja aprovado e torne-se vigente, existem duas possibilidades de aprovação: Unânime ou Maioria. Quando a aprovação for de forma Unânime, para que o documento seja aprovado, todos os usuários que foram selecionados para a aprovação do documento devem aprovar o documento. Caso o documento não seja aprovado por todos, o usuário que tentou realizar a publicação do documento poderá realizar uma nova tentativa, onde ela será votada, podendo realizar este procedimento até que o documento seja aprovado. Quando um usuário for aprovar ou reprovar o documento, poderá explicar em um campo „Observações‟ o que o documento falta para ser aprovado, dando assim, mais usabilidade ao sistema, sem ter necessidade do usuário publicador ficar mandando email ou perguntando pessoalmente as alterações necessárias para o usuário que reprovou o documento. Na opção de aprovação pela Maioria, para o documento ser aprovado, o mesmo deverá ter mais de cinquenta por cento de votos de aprovação. Porém, para que o documento se torne vigente e acessível para os usuários, todos os usuários que foram selecionados para realizar a votação deverão dar o seu voto, e após isto, o documento estará disponível. Quando um documento for reprovado, o usuário que está realizando a publicação do documento só poderá realizar as alterações e realizar uma nova publicação daquela versão do documento, quando todos os usuários realizarem os seus votos e inserirem as suas observações, para garantir que todos os usuários possam colocar o motivo o qual estão reprovando o documento. 38 Para que a alteração fosse realizada, foram necessárias as seguintes alterações. No gerenciamento de tipo de documento, foi acrescentada uma nova opção para selecionar se o tipo de documento requer aprovação para publicação (Figura 4.8). Quando um documento requerer aprovação, será possível selecionar os perfis de usuários que poderão realizar a aprovação do documento e os perfis que deverão obrigatoriamente realizar a votação. Se existir algum usuário dentro de um perfil aprovador que não necessita realizar a aprovação de documento, poderá ser retirado para que não realize o voto. Da mesma forma, caso possua algum usuário que não necessita realizar a leitura obrigatória do documento, o mesmo poderá ser retirado. (Figura 4.9). Figura 4.8 - Gerenciamento de Tipo de Documento 39 Figura 4.9 - Gerenciamento de Tipo de Documento Na publicação de documento, acrescentou-se uma nova aba, onde poderá selecionar os perfis de usuários que irão realizar a aprovação do documento. Os perfis previamente selecionados no gerenciamento de tipo de documento sendo como obrigatórios, para o tipo de documento que está sendo publicado, estarão bloqueado, pois estes deverão votar. (Figura 4.10) 40 Figura 4.10 – Tela de publicação de documentos Para determinado usuário saber que existe alguma pendência de aprovação de documento, foi criado uma opção no menu de Atividades ECM, juntamente com a leitura obrigatória, para visualizar todos os documentos que não receberam o seu voto. (Figura 4.11). Figura 4.11 - Menu de Atividades ECM Ao clicar sobre o menu de documentos aguardando a aprovação do documento, será aberto uma listagem com todos os documentos que requerem aprovação do documento. No exemplo da Figura 4.12, existem seis documentos aguardando a aprovação. 41 Figura 4.12 – Listagem de documentos a serem aprovados Para o usuário realizar a sua votação, os visualizadores de documentos foram alterados para esta nova funcionalidade. Quando o usuário abrir o documento para realizar a votação, será exibido um botão com a opção “Aprovar” e outro botão “Reprovar” (Figura 4.13). Caso seja selecionada a opção reprovado, um campo de texto chamado “Observações” será de preenchimento obrigatório, onde o usuário poderá colocar as suas observações, o motivo pelo qual não foi aprovado e tudo que for necessário alterar para o documento ser aprovado. Porém, este campo poderá também ser utilizado quando a opção “Aprovar” for selecionado, mas fica a critério do usuário escolher se quer escrever algo ou não. Figura 4.13 – Visualizador de documentos com a opção de aprovação do documento 42 Após a votação de cada usuário, será realizada uma contagem pelo sistema, e verificar se todos os usuários realizaram a votação e o documento já pode tornar-se vigente. Caso o documento alcance os votos necessários para ser aprovado, o mesmo tornará vigente e será notificado, através de email, a todos os usuários que possuem permissão de leitura, que um novo documento foi publicado. Para todos os usuários que abrirem o documento, estará disponível juntamente com a visualização do documento, uma listagem com todos os aprovadores e os votos que cada um realizou. Porém, a observação inserida pelos aprovadores, estará disponível apenas ao usuário publicador do documento e para os aprovadores. (Figura 4.14) Figura 4.14 – Visualização de Documento com os votos dos usuários 4.3 AGUARDANDO APROVAÇÃO DE DOCUMENTO Após o usuário realizar a publicação de um documento que deverá passar pela aprovação de outros usuários, o mesmo poderá acompanhar a votação de seu documento 43 através de uma nova listagem criada, que irá listar todos os seus documentos que estão aguardando aprovação ou documentos reprovados. O menu de acesso a nova listagem ficará junto com o menu de leitura obrigatória e aprovação de documento (Figura 4.15). Figura 4.15 – Menu de Atividades ECM- Documentos aguardando aprovação Ao clicar sobre o menu, será aberta a listagem com todos os documentos publicados pelo usuário que requerem aprovação para publicação. (Figura 4.16). Figura 4.16 – Listagem dos documentos publicados aguardando aprovação Quando um documento estiver aguardando a votação, não poderá ser realizada nenhuma ação com o documento, apenas visualizar as informações do mesmo e abrir o documento. Porém, quando o documento for reprovado, o usuário poderá tentar realizar uma nova publicação, através da revisão de documento. Com isso, o documento poderá ser alterado de acordo com as sugestões dos aprovadores e assim tentar que o documento seja aprovado. Porém, caso o usuário desista de tentar realizar uma revisão, a versão poderá ser cancelada através do botão de cancelamento de revisão. Caso o usuário opte por cancelar a revisão e não tentar arrumar o documento, todo o histórico de votações ficará armazenado para ser visualizado no relatório e apenas o status do documento será alterado para não aparecer na listagem de documentos. Na figura 4.16, o primeiro documento da listagem foi reprovado pelos aprovadores, onde é possível cancelar a revisão, realizar uma nova revisão, editar 44 propriedades e exibir propriedades. Nesta mesma listagem, possui três documentos que estão aguardando a votação, e com isso, é permitido apenas clicar no botão de informações. Para maiores detalhes do que foi alterado, o documento que foi utilizado pela equipe de desenvolvimento para realização das atividades de aprovação de documento, se encontra no Anexo B. 4.4 ANÁLISE DO SISTEMA DI 2.0 O DI é o módulo responsável pela indexação e publicação do documento no sistema de ECM SmartShare. Com isso, o módulo é divido em três aplicativos: Client, Server e Web Site. O aplicativo Client será responsável pelo monitoramento de determinada pasta, onde quando algum arquivo for digitalizado e for salvo na pasta, o aplicativo irá abrir o documento e irá solicitar ao usuário os índices deste documento, para ser armazenados no SmartShare e estes índices serão utilizados para a busca do documento no sistema. Após a indexação do documento, o aplicativo irá gerar um lote de documento, por tipo de documento, e disponibilizar os arquivos para o aplicativo Server, onde o mesmo irá realizar a publicação no sistema SmartShare. O aplicativo Server será responsável por verificar quando um lote de documento estiver pronto para publicação e pegará os documentos com os respectivos índices e publicará todo o lote de documento no sistema SmartShare, através de um Web Server. O aplicativo Web Site gerenciará todo o DI, onde possibilitará ao usuário pausar a publicação de um lote, iniciar a publicação, trocar prioridades, configurar o número de documentos por lote e acompanhar o andamento das publicações. 4.4.1 Levantamento de Requisitos 4.4.1.1 Client Para que o aplicativo Client, será necessário os seguintes requisitos:  Configuração da pasta a ser monitorada. o Será necessário cadastrar a pasta na qual os arquivos que foram digitalizados serão salvos, para que o aplicativo possa ficar analisando a mesma e quando 45 um documento for salvo na mesma, possa abrir a tela para que o usuário indexe o arquivo. o Campos: Pasta a ser monitorada. o Ator: Usuário  Configuração do Banco de dados o Para que o aplicativo salve as informações de indexação, é necessário que o banco de dados seja cadastrado, informando os dados necessários para que o aplicativo realize a conexão com o mesmo. o Campos: Instância, nome do banco de dados, usuário, senha. o Ator: Usuário  Serviço de Monitoramento o O Serviço que ficará monitorando a pasta cadastrada não ficará visível para o usuário, ou seja, será criado apenas um ícone que ficará na barra do Windows, ao lado do relógio, para que o mesmo possa realizar as configurações, clicando com o botão direito do mouse, onde será aberto um menu com as opções de ações permitidas. o Ações permitidas: Iniciar monitoramento, pausar monitoramento, cadastrar pasta. o O serviço deverá ser iniciado juntamente com o sistema operacional, não necessitando o usuário iniciar o serviço. o Ator: Aplicativo / Usuário  Visualizador de documento com os campos para o preenchimento dos índices o Quando um novo documento for salvo na pasta que está sendo monitorada, deverá ser aberta uma nova janela mostrando o documento digitalizada e ao lado, um menu com os campos necessários para a indexação do arquivo. o O primeiro campo a ser mostrado é Tipo de Documento, o qual, dependendo de cada tipo, possui seus próprios índices que serão preenchidos pelo usuário. o Como na maioria das vezes os arquivos digitalizados fazem parte de um lote e são feitos sequencialmente, o campo Tipo de Documento e seus índices 46 permanecerão preenchidos conforme o ultimo documento indexado, evitando assim que o usuário tenha que informar para cada documento, o seu tipo e seus índices, onde quase todos são iguais para os documentos do mesmo lote. o Ator: Aplicativo / Usuário  Preenchimento dos índices o Após o documento ser aberto para visualização e os índices carregados, o usuário deverá informar todos os índices do documento, para que o mesmo seja armazenado e indexado no SmartShare. o Ator: Usuário  Indexar os arquivos o Após o usuário informar todos os índices, o arquivo deverá ser indexado no banco de dados do DI. o Serão armazenados todos os campos informados e também o caminho onde o documento será salvo, juntamente com o seu nome que será gerado de forma randômica, evitando assim que tenham dois arquivos com o mesmo nome. o Ator: Aplicativo  Organizar os arquivos em pastas o Após os arquivos serem indexados pelo DI, os mesmos serão armazenados em pastas diferentes, por tipo de documento, para que fiquem organizados e para facilitar o trabalho com os lotes de documentos. o Cada tipo de documento terá sua pasta específica. o O aplicativo irá retirar o arquivo da pasta que está sendo monitorada e copiará o mesmo para a pasta de acordo com o seu tipo. o Ator: Aplicativo 47  Pausar Monitoramento o Criar opção no ícone ao lado do relógio ao usuário para que quando necessário, o aplicativo pare de ficar monitorando um diretório, pois muitas vezes é digitalizada uma série de arquivos e só após a digitalização de todos os documentos é realizada a indexação. o Ator: Usuário  Iniciar Monitoramento o Da mesma forma que para pausar o monitoramento, criar opção no ícone ao lado do relógio, para que o usuário inicie o monitoramento novamente, onde se houver documentos na pasta, mostre para o usuário realizar a indexação do documento. o Caso haja mais de um arquivo ao iniciar o monitoramento, deverá abrir primeiramente o arquivo mais antigo, e após informar os índices do mesmo e indexar no DI, deverá ser aberto o próximo arquivo e assim sequencialmente. o Ator: Usuário  Fechar Lote de Arquivos o Quando determinado Tipo de Documento tiver a quantidade de documentos cadastrada no aplicativo Web Site, para gerar um lote, o sistema deverá fechar o lote e disponibilizar os arquivos no Servidor, onde o mesmo se encarregará de realizar a publicação no SmartShare. o Gerar um lote no banco de dados, para que o aplicativo do servidor saiba que existe um lote para ser processado. o Ator: Aplicativo  Disponibilizar arquivos no Servidor o Depois de criado o lote, o aplicativo Client deverá transferir todos os arquivos que estiverem no computador local para o servidor principal, onde estará instalado o DI Server. o O Client deverá garantir que todos os arquivos foram transferidos para o servidor e que não houve perda de arquivos. Caso algum arquivo foi perdido na 48 hora da transferência, este arquivo deverá ser transmitido novamente, para que todos estejam disponíveis para o servidor. o Ator: Aplicativo  Criar Instalador o Criar um instalador para o aplicativo Client e realizar todas as configurações necessárias para que o aplicativo possa ser utilizado. O instalador deverá ser de fácil utilização, onde o usuário deverá apenas executar o arquivo, realizar poucas configurações e o aplicativo seja instalado. o Ator: Aplicativo / Usuário. 4.4.1.2 Server  Verificar Lote fechado o O aplicativo irá verificar a cada período de tempo determinado se existe algum lote de documento que pode iniciar a publicação deste lote de documentos no SmartShare. o Ator: Aplicativo.  Publicação de Lote o Quando houver um lote pronto para ser publicado, o aplicativo deverá iniciar as publicações do documento no SmartShare. o Deverá obedecer a prioridade dos tipos de documento, para publicar primeiramente os lotes que possuem maior prioridade. Este cadastro será mostrado no aplicativo Web Site. o Ator: Aplicativo.  Armazenar Log o Conforme os lotes forem concluídos, deverá ser registrado um log informando que determinado lote teve sua publicação concluída. 49 o Quando houver algum erro com algum lote, deverá ser registrado em um log para que o usuário responsável pelas publicações do lote faça as correções necessárias e o lote seja publicado novamente. o Campos: código do lote, descrição do log, data, hora, tipo (erro ou acompanhamento).  Ator: Aplicativo. o Criar PDF Search, que é o arquivo que foi digitalizado em formato PDF, porém o conteúdo de texto fica disponível para ser selecionado e pesquisado. o Para que seja possível realizar a busca de informações dentro de um documento, o aplicativo realizará a leitura da imagem do arquivo, com o auxílio de um programa com OCR, para que seja possível realizar a extração de informações. O programa OCR a ser utilizado será o LEADTOOLS.  Ator: Aplicativo 4.4.1.3 Web Site  Configuração da quantidade de arquivos para gerar um lote. o A configuração será feita por tipo de documento, selecionando o Tipo de documento e informando a quantidade de documentos necessários para gerar um lote. o Campos: Tipo de Documento, Quantidade de arquivos por lote. o Ator: Usuário  Gerenciamento de Prioridade o Criar cadastro para gerenciamento das prioridades por tipo de documento. Este prioridade será utilizada na publicação de lotes no SmartShare, onde o aplicativo Client verificará qual lote possui maior prioridade para publicação. o Campos: Tipo de Documento, prioridade. o Ator: Usuário 50  Dashboard de Acompanhamento de publicações o Criar dashboard com os lotes de documentos que estão aguardando publicação e os que estão sendo publicados. o Deverá mostrar através de um Progress bar o andamento da publicação dos lotes de documentos, para saber o estado em que se encontra a publicação. o Ator: Aplicativo  Dashboard de Log de erros o Para a visualização dos erros que ocorreram no lote ao realizar a publicações dos documentos, deverá ser criada uma listagem mostrando todos os erros ocorridos e com a descrição do mesmo, para que seja possível o usuário realizar as devidas alterações para que o problema seja sanado. o Informações a serem mostradas: Lote o qual ocorreu o problema, número do documento, descrição do problema. o Ator: Aplicativo.  Dashboard de Log do sistema o Para visualização de todos os log´s do sistema, deverá ser criada uma listagem mostrando tudo o que está acontecendo, para que o usuário possa acompanhar o processo de publicação dos lotes. o Ator: Aplicativo  Parar publicação de lote o Enquanto um lote estiver sendo publicado, o usuário poderá interromper a publicação do lote para que outro lote possa ser publicado. o Ator: Usuário.  Iniciar Publicação o O usuário poderá iniciar a publicação de um lote da maneira que quiser. o Não será necessário que um lote tenha a sua publicação iniciada, pois o Server realizará a inicialização automática. Porém, se um lote foi parado, a única forma para que ele volte a publicar, é através desta funcionalidade. 51 o Ator: Usuário  Gerenciamento de número de lotes simultâneos o Criar Gerenciamento de número máximo publicações de lotes simultâneas. o Campos: número máximo de publicações. o Ator: Usuário  Gerenciamento de endereço para publicação o Quando um lote for publicado, deverá possuir o endereço do SmartShare para a publicação do documento. o Campos: Tipo de documento, endereço para publicação. o Ator: Usuário  Re-publicar lote com erro o Após algum lote ter problemas ao publicar os documentos, o mesmo irá aparecer na lista de lotes com erro. Após o usuário corrigir o erro no lote, o mesmo poderá tentar republicar o lote, para que o mesmo publique os documentos no SmartShare. o Ator: Usuário  Visualizar informações da publicação o Para que o usuário possa visualizar informações referentes à publicação do lote, poderá ser realizado através da listagem de lotes publicados. o O usuário poderá visualizar: Quantidade de documentos do lote, tempo médio de publicação de cada documento, tempo total para o lote ser publicado. o Ator: Usuário. 52 4.4.2 Fluxograma 4.4.2.1 Client Para melhor entendimento, o fluxo de atividades do aplicativo Client pode ser visualizado na Figura 4.17. Figura 4.17 – Fluxograma do aplicativo Client Após o aplicativo ser iniciado, o mesmo fica monitorando, em uma pasta previamente cadastrada, até que um arquivo seja salvo nesta pasta. Quando um arquivo é salvo, o aplicativo realiza a leitura deste arquivo e abre o mesmo em tela, para que o usuário informe o tipo deste documento e os índices do arquivo, para que após o documento ser publicado no SmartShare, possa ser pesquisado utilizando estes mesmos índices. Depois de informado todos os índices, o arquivo é salvo em uma pasta, separadas por tipo de documento e os índices são salvos no banco de dados do DI. 53 Quando o arquivo é salvo na pasta, o aplicativo verifica se a quantidade de arquivos é a mesma quantidade previamente cadastrada no aplicativo Web Site. Caso alcance a quantidade cadastrada, o aplicativo fecha um lote no Client e inicia a transferência destes arquivos para o Servidor, através de um Web Server. Após o término da transferência, é verificado se todos os arquivos foram completamente transferidos. Caso todos os arquivos foram transferidos, o aplicativo fecha o lote e disponibiliza para o aplicativo Server realizar a publicação destes arquivos. A qualquer momento durante o fluxo, o usuário poderá pausar o serviço de monitoramento da pasta, pois isto se torna necessário quando é realizado um grande número de digitalizações e que o usuário só irá realizar a indexação ao término das digitalizações. E quando for necessário, o usuário terá a possibilidade de iniciar novamente o serviço de monitoramento. 4.4.2.2 Server Para melhor entendimento, o fluxo de atividades do aplicativo Server pode ser visualizado na Figura 4.18. Figura 4.18 – Fluxograma do aplicativo Server 54 Após o serviço ser iniciado, o mesmo verifica se existe algum lote de documento que esteja disponível para a publicação no SmartShare. Depois de verificado a existência de algum lote, o mesmo realiza a indexação do documento e realiza a leitura do documento utilizando a ferramenta OCR, retirando informações do documento necessárias para a indexação. Se não acontecer nenhum erro na publicação do documento, o sistema irá gravar um log de acompanhamento. Porém, caso ocorra algum erro, será gravado um log de erro, para que o usuário possa visualizar o mesmo e realizar as correções necessárias. 4.4.3 Protótipo de Telas Para que o serviço de monitoramento identifique a pasta que contém os arquivos digitalizados e o banco de dados no qual será realizado o armazenamento das informações, deverá ser cadastrado em cada computador em que o aplicativo estiver instalado. (Figura 4.19). Figura 4.19 – Protótipo de gerenciamento do aplicativo Client Quando um documento for salvo na pasta que estiver sendo monitorada e o serviço estiver iniciado, será aberta a tela da Figura 4.20, com a opção de visualização do documento e informação dos índices. 55 Figura 4.20 – Protótipo da tela de visualização e indexação de documentos Para a configuração do sistema, deverá ser feito pelo aplicativo Web Site, que terá a opção de configurar a quantidade de arquivos para fechar um lote, a prioridade de tipo de documentos, quantos lotes são publicados simultaneamente e o local onde o SmartShare está instalado para publicação dos documentos. Na Figura 4.21 é mostrado o protótipo da tela. 56 Figura 4.21 – Protótipo da tela de gerenciamento do Web Site Para acompanhar as publicações, será criada uma tela onde serão mostrados os lotes pendentes para publicação, os lotes que estão sendo publicados, os lotes com erros e os log´s do sistema, informando o que está acontecendo com os lotes. Enquanto um lote estiver sendo publicado, poderá ser pausada a publicação para que se tenha início outro lote. Após, o lote poderá ser iniciado novamente de acordo com a necessidade do usuário. Os lotes com erro poderão ser publicados novamente, entrando na fila de lotes pendentes. A Figura 4.22 mostra o protótipo da tela de acompanhamento das publicações. 57 Figura 4.22 – Protótipo da tela de acompanhamento de publicações CONSIDERAÇÕES FINAIS O relatório apresenta as atividades realizadas no estágio obrigatório do acadêmico do curso de Tecnologia em Análise e Desenvolvimento de Sistemas, com o objetivo de atuar na área de desenvolvimento de sistemas. Com o objetivo principal da criação de uma versão do módulo DI – Document Image, que apresenta diversos erros que inviabilizam o seu uso. Devido à necessidade de clientes, algumas atividades, em outros módulos do SmartShare, tiveram que ser antecipadas e com isso o desenvolvimento da versão 2.0 do módulo DI foi adiado. Duas novas funcionalidades foram implementadas no sistema SmartShare para atender as necessidades dos clientes, a leitura obrigatória de documento e a aprovação de documento para publicação. Nestas novas funcionalidades foram desenvolvidas atividades de análise, identificando todas as alterações necessárias para que as atividades fossem realizadas, desenvolvimento das alterações necessárias e atividades de testes, para identificação de erros e defeitos no sistema. Com a realização das atividades foi possível colocar em prática diversas atividades e conceitos que foram aprendidos durante o curso de graduação, como atividades de análise de sistemas, lógica de programação, gerenciamento de projetos, utilização do banco de dados, e assim, aplicar e ao mesmo tempo aprender com as atividades realizadas. Para isto, as disciplinas que mais contribuíram foram: Análise de Sistemas, Banco de Dados, Introdução a Ciência da Computação, Engenharia de Software, Lógica de Programação, Estrutura de Dadose Gerência de Projetos. ATIVIDADES FUTURAS Conforme descrito, a atividade de análise do módulo DI 2.0 foi iniciada, porém a análise do banco de dados não foi realizada, faltando assim o término da análise, desenvolvimento e os testes do sistema. Está previsto para que estas atividades terminem em dezembro, e que o mesmo possa ser atualizado e utilizado pelos clientes. Na aprovação de documentos para publicação, não houve tempo hábil para a criação de um relatório mostrando o histórico de votação de cada versão do documento publicado, ficando uma pendência a ser realizada pelo time de desenvolvimento após o término do estágio. REFERÊNCIAS BIBLIOGRÁFICAS AIIM. What is Enterprise Content Management (ECM)?. Disponível em: . Acesso em: 02 de outubro de 2011 ANDRADE, Gabriel. O que são Linguagens de Programação. Disponível em: . Acesso em 21 de outubro de 2011. ALVAREZ, Miguel Ange. O que é Javascript. Disponível em: . Acesso em 18 de outubro de 2011. BISHOP, Clarke. What is a Web Application Server? Disponível em: . Acesso em 20 de outubro de 2011. FRANCO, Thiago Eduardo Reis. BARREIRO, Vandeir de Paula. A TECNOLOGIA DOCUMENT IMAGING NO GERENCIAMENTO ELETRÔNICO DE DOCUMENTOS. Disponível em: . Acesso em: 01 de outubro de 2011. KORTH, Henry F. SILBERSCHATZ, Abraham. Sistemas de Banco de Dados. São Paulo: McGraw-Hill, 1989. MICROSOFT. Active Server Pages. Disponível em: . Acesso em 20 de outubro de 2011. PACIEVITCH, Yuri. C#. , 2011. SELBETTI. Selbetti Gestão de Documentos. Disponível em: . Acesso em 15 de outubro de 2011. SISNEIROS, Hugo. Modelo de Desenvolvimento Ágil SCRUM. Disponível em: . Acesso em 18 de outubro de 2011 SOMMERVILLE, Ian. Engenharia de Software. 8ª Ed. São Paulo – SP. Editora Pearson Education do Brasil, 2007. GLOSSÁRIO Os conceitos básicos apresentados a seguir estão baseados em diversas fontes bibliográficas. ASP Active Server Pages. Linguagem de programação utilizada para criação de páginas Web. Dashboard Significa painel de indicadores. DI Document Image ECM Enterprise Content Management ou Gestão de Conteúdo Empresarial HTML HyperText Markup Language, que significa Linguagem de Marcação de Hipertext. Utilizado para criação de páginas Web. OCR Optical Character Recognition, que significa Reconhecimento Ótico de Caracteres. ANEXOS ANEXO A 1. 285 – REQUERER LEITURA PARA DOCUMENTO, COM ATIVIDADE OBRIGATÓRIA (73h) 1.1 Alterar Gerenciamento de tipo de documento (4h) - Adicionar checkbox na aba „Avançado‟ para informar se o tipo de documento é de leitura obrigatória ou não. - Adicionar coluna „st_leitura_obrigatoria‟ na tabela do banco de dados. - Bloquear e desmarcar, caso esteja marcado, o checkbox quando o tipo de documento for Nota Fiscal Eletrônica. 1.2 Acrescentar coluna TABELA PERFIL_DOCUMENTO (0,5h) - Acrescentar a coluna „st_leitura_obrigatoria‟ na tabela PERFIL_DOCUMENTO para identificar por documento e por perfil, quais serão os perfis que terão que ler obrigatoriamente o documento. Obs.: Informação inserida no item 3.3 (publicação do documento) e utilizada no item 3.5 (revisão documento). 1.3 Adicionar aba de perfis obrigatórios na publicação do documento (16h) - Adicionar aba para o usuário selecionar os perfis que deverão ler o documento publicado. - A aba só deverá aparecer se o tipo de documento escolhido estiver com a opção de leitura obrigatória selecionada. - Só deverão aparecer os perfis que estiverem selecionados para leitura, da primeira aba. - Acrescentar a informação dos perfis que deverão ler o documento na tabela PERFIL_DOCUMENTO, criado no item 3.2. 1.4 Adicionar coluna na tabela USUARIO_DOCUMENTO (6,5h) - Adicionar as colunas „st_leitura_obrigatoria‟ e „cd_versao_documento‟ na tabela USUARIO_DOCUMENTO para identificar por usuário se o mesmo leu ou não determinado arquivo de leitura obrigatória. - Inserir, na hora de publicar o documento, um registro para cada usuário do perfil selecionado para leitura obrigatória, para saber os usuários que ainda não leram o documento. 1.5 Revisão do documento (6h) - Inserir um registro, após a revisão do documento, na tabela USUARIO_DOCUMENTO, para cada usuário do perfil do documento que requerem leitura obrigatória do documento, de acordo com a tabela PERFIL_DOCUMENTO. 1.6 Identificação no portal se documento requer leitura (4h) - Identificar no portal se o documento não foi lido e requer a leitura do usuário. 1.7 Alterar Viewer e relatórios (2h) - Alterar Viewer normal e padrão para, ao abrir o documento, atualizar a tabela USUARIO_DOCUMENTO, de acordo com as alterações realizadas na tabela, pois foram inseridas 2 novas colunas, do item 3.4. - Alterar os relatórios Documento x Usuário e Usuário x Documento. 1.8 Criar Relatório documento x leitura obrigatória (8h) - Criar um relatório de Documento x Leitura Obrigatória, onde irá mostrar os documentos que são de leitura obrigatória e os usuários que ainda não realizaram a leitura do mesmo. - No relatório devem aparecer apenas os documentos que estão para Leitura Obrigatória, não podendo aparecer documentos que requerem aprovação para publicação do usuário. - Um documento, pode tanto requer aprovação para publicação quanto ser de leitura obrigatória para um determinado usuário. Mas o documento só irá aparecer como leitura obrigatória quando ele não requer aprovação. 1.9 Notificação AGENT (2h) - Gerenciamento de Notificação: Criar 4 novos tipos de ações e vincular ao tipo de aplicação Cadastro de Documento: Aprovado, Reprovado, Requer Leitura e Requer Aprovação - Criar notificação para que o usuário seja alertado quando houver um documento leitura obrigatória. Obs.: As outras 4 ações serão realizadas em outra atividade. 1.10 Criar o menu Pendências GED (8h) - Criar novo menu na barra lateral esquerda, com as pendências que o usuário possui no GED. Mostrar a opção de Leitura, e abaixo a informação de quantos documentos que o usuário deverá ler. - Caso tenha algum documento a ser lido, destacar esta informação, para ficar mais visível ao usuário. - Caso não houver nenhum documento, não deixar destacado. - Quando o usuário clicar sobre o item Leitura, abrir o painel descrito no item 3.11. - Quando o usuário clicar sobre o título do Menu: "ATIVIDADES ECM", deverá abrir o painel com a listagem de documentos com todas as 1.11 Criar painel de documento não lidos (16h) - Criar painel para que o usuário possa ver todos os documentos de leitura obrigatória que não foram lidos por ele. - Ao clicar sobre o documento, deverá ser aberto o Viewer que estiver configurado, e após a leitura, o mesmo não aparecerá mais no painel. - Após a leitura do documento, ao fechar o documento, a listagem de documentos não poderá mais ter o documento na listagem e todos os filtros devem permanecer como estavam antes de abrir o documento. ANEXO B 2. 284 – APROVAÇÃO OBRIGATÓRIA DE DOCUMENTO INTEGRADO NO SHARE ECM (102,5h) 2.1 Alterar Gerenciamento de Tipo de Documento (10,5h) - Acrescentar checkbox na aba avançado, para identificar os tipos de documento que deverão ser aprovados para se tornarem vigentes. - Acrescentar coluna „st_requer_aprovacao‟ na tabela TIPO_DOCUMENTO -Acrescentar combobox com as opções: „Unanime‟ ou „Maioria‟ para determinar a forma de votação que o documento passará para se tornar vigente. - Acrescentar opção para selecionar os perfis obrigatórios que irão aprovar o documento, e utilizar caixas de marcação, para identificar quais são obrigatórios e quais não. - Criar nova tabela „PERFIL_APROVA_TIPO_DOCUMENTO‟, que irá armazenar os perfis que deverão aprovar determinado tipo de documento. 2.2 Alteração na publicação do documento (16h) - Acrescentar 3 colunas na tabela USUARIO_DOCUMENTO: „st_requer_aprovacao‟, „st_aprovado‟ e „ds_observacao‟, onde estes serão responsáveis por controlar se o usuário possui alguma atividade de aprovação de documento. - Acrescentar coluna na tabela VERSAO_DOCUMENTO, para indicar qual é o status da versão do documento. Os status poderão ser: aprovado, reprovado, aguardando aprovação. - Acrescentar aba na tela de publicação, para selecionar os aprovadores do documento. Por padrão, deverão vir selecionado e bloqueado os perfis que foram cadastrados como obrigatórios na tela de gerenciamento de tipo de documento (item 4.1). Os perfis que não foram marcados como obrigatórios, deverão estar habilitados para serem marcados se necessário. - Ao publicar o documento, deverá inserir um registro na tabela USUARIO_DOCUMENTO para cada usuário que deve aprovar o documento. - Para os usuários que estiverem „ausente‟ e forem de um perfil que faz a aprovação do documento, deve-se passar esta atividade para o seu substituto. 2.3 Quantidade de Tentativas (16h) - Acrescentar coluna na tabela VERSAO_DOCUMENTO para controlar a tentativa atual de aprovação de documento e para ver quantas tentativas foram necessárias para que o documento fosse aprovado. - Acrescentar coluna na tabela USUARIO_DOCUMENTO para controlar a qual tentativa pertence o voto do aprovador. - Quando o documento for publicado, e o mesmo requer aprovação, deverá ser inserido com a quantidade 1. Caso o documento for reprovado pelos aprovadores, o usuário irá revisar o mesmo, será ATUALIZADA a tabela VERSAO_DOCUMENTO, acrescentando em 1 a quantidade de tentativas e alterando o status da versão do documento. Na tabela USUARIO_DOCUMENTO, será acrescentado novamente um registro para cada usuário aprovador, para a tentativa atual. Assim, serão controlados os votos de cada usuário aprovador em cada versão e em cada tentativa do documento. 2.4 Aprovar ou Reprovar Documento (16h) - Caso o usuário que abriu o documento seja aprovador do documento e o mesmo ainda não votou mostrar as opções APROVAR e REPROVAR para o mesmo realizar o seu voto. Abaixo, acrescentar o campo observação, caso o mesmo queira realizar alguma observação do documento. - Caso o usuário que abriu o documento seja aprovador do documento e já realizou a votação, não irá mostrar as opções de voto. - Após cada aprovação/reprovação de um documento, deverá ser verificado o tipo de aprovação, se é Unanime ou Maioria. Caso todos os usuários votaram ou for a maioria, o documento deverá ser aprovado ou reprovado, tendo seu status na tabela VERSAO_DOCUMENTO alterado. Obs.: Considera-se maioria quando a quantidade de votos para determinada opção for MAIOR que 50%. - Inserir opção para que seja possível mostrar o voto de cada aprovador do documento. Obs: Esta opção ficará visível para todos que abrirem o documento, porém o campo OBSERVAÇÃO deverá ficar visível APENAS para o publicador do documento e para os revisores. Outros usuários não poderão ver estas observações, pois poderão conter informações que não sejam interessantes mostrar para todos os usuários que abrirem o documento. - A observação do documento será mostrada através de um Zoom. 2.5 Alterar Histórico Portal (2h) - Ao visualizar o histórico do documento, deverão aparecer apenas as versões aprovadas. Caso possua alguma versão que está aguardando aprovação, a mesma não deverá aparecer para ser visualizada. 2.6 Alterar Histórico Viewer´s (2h) - Ao visualizar o histórico do documento no Viewer, deverá mostrar apenas as versões que estiverem aprovadas. 2.7 Agent para notificar usuários (16h) - Acrescentar campo no gerenciamento de tipo de documento, para que seja possível cadastrar de quanto em quanto tempo o usuário irá receber o aviso de que existem pendências relacionadas a aprovação de documento. - Quando um documento for APROVADO ou REPROVADO, o usuário publicador deverá receber um email notificando a alteração do status do seu documento. - Quando um documento for publicado, os aprovadores deverão receber um email alertando que existe um documento para ser aprovado. - Se existir algum cadastro no gerenciamento de documento referente ao tempo de envio de email alertando sobre pendência da aprovação de documento, será enviado email de acordo com o tempo cadastrado para os usuários que possuírem pendências. Este ficará enviando email para o usuário, até que o mesmo realize as pendências que possui. - Os usuários que possuem permissão para leitura do documento, só poderão receber o email de nova publicação ou revisão após a aprovação do documento. 2.8 Alterar menu de pendências GED e painel (16h) - Alterar o menu lateral de pendências GED e acrescentar a opção de Aprovação, e abaixo, o número de documentos que o usuário possui para aprovação do documento. Após clicar sobre a opção, deverá ser aberto o painel central, listando todos os documentos que estão para ser aprovados. - Criar um painel que irá mostrar para o usuário todos os documentos que estão aguardando o seu voto. - Alterar o menu lateral de pendências GED e acrescentar a opção "A Aprovar", e abaixo, mostrar o número de documento que o usuário publicou e está esperando ser aprovado. - Criar um painel que irá mostrar os documentos do usuário que estão esperando para ser aprovado. 2.9 Relatório de Aprovação por documento (8h) - Criar relatório que irá mostrar todo o histórico de votação por versão de cada documento. 2.10 Usuários não aprovadores (8h) - Criar tabela TIPO_DOCUMENTO_USUARIO_NAOAPROVA. - Alterar a tela de gerenciamento de tipo de documento, criando uma listagem de usuários com checkbox, onde esses usuários serão baseados nos perfis de aprovação selecionados. Trazer todos os usuários ordenados por ordem alfabética, e para aqueles onde não for necessário enviar um registro de aprovação, obter os checados. - Alterar tela de publicação, adicionando a condição ao buscar os usuários aprovadores, para não trazer os usuários da tabela TIPO_DOCUMENTO_USUARIO_NAOAPROVA, do tipo de documento selecionado (caso exista). - Realizar alteração também na hora de iniciar uma revisão, para que busque apenas os usuários aprovadores dos perfis selecionados e não estando na tabela TIPO_DOCUMENTO_USUARIO_NAOAPROVA. 4.11 Cancelar Publicação - Acrescentar opção de Cancelar publicação no menu "A AProvar", para que o usuário cancele a revisão do documento que foi reprovada. - Botão ficará visível apenas quando o status do documento for 3 (Reprovado). Enquanto estiver em votação não poderá cancelar a publicação. - Ao clicar sobre o botão, será exibida uma mensagem de confirmação. - Ao cancelar a publicação de um documento, a id_status_documento será 4 (Cancelado), para que o histórico das votações fique disponível nos relatórios e não poderá mais ser visível na listagem de documentos. 4.12 Acompanhamento de Publicações - Criar painel e opção no menu de Atividades ECM para mostrar todas as publicações dos usuários; - Esta opção deverá estar disponível para os usuários que são AdminRoot. Para ser Admin Root, o código do usuário deverá estar registrado no arquivo web.config --> --> e também ser Administrador Geral no SmartShare. - Ao clicar no menu, será mostrada uma listagem com todos os documentos que foram publicados e possuem status 1 (Aguardando aprovação) e 3 (reprovado).