Autor: Fábio Haertel

  • Entenda as fases da Gestão de Documentos no contexto eletrônico

    Entenda as fases da Gestão de Documentos no contexto eletrônico

    Considerado o primeiro estudioso do ciclo de vida dos documentos (que aqui definimos como fases da gestão de documentos), o norte-americano Philip C. Brooks, arquivista e diretor da biblioteca Harry S. Truman, afirmava que o armazenamento ou descarte de um documento só poderia ser realizado após o entendimento completo de seu valor.

    Assim, um documento sem valor poderia ser descartado, sendo que apenas documentos com alto valor poderiam seguir o ciclo de vida completo da gestão documental. Nesta perspectiva, de acordo com Smith (1986), dependendo do seu valor para a empresa, um documento possui um ciclo de vida médio baseado em 4 fases: criação, utilização, arquivamento e descarte.

    Entendendo as fases da Gestão de Documentos

    Fases da gestão de documentos

    O arquivista americano James Rhoads (1989) descreve cada uma das fases da gestão de documentos como:

    1. Criação: produção de formulários e utilização de tecnologias modernas ao processo.
    2. Utilização: contempla a utilização dos documentos para realizar atividades de uma organização. Aborda a gestão dos arquivos, aperfeiçoamento dos sistemas de arquivo e automação dos processos.
    3. Arquivamento: aborda os processos de conservação e preservação dos documentos, a construção de políticas de acesso e criação de metadados.
    4. Descarte: contempla a tomada de decisão a respeito da conservação do documento e a criação de programas de retenção.

    Entende-se que, nas fases da gestão de documentos, o ciclo de vida inicia-se na primeira vez que um documento é organizado e utilizado em larga escala. Continua à medida que o documento é armazenado por mais tempo, até que seu valor operacional se encerre, sendo descartado ou arquivado. O princípio por trás deste conceito é de que a informação gravada possui uma “vida” similar a um organismo biológico. Ela nasce, vive e morre.

    Limitações das fases da Gestão de Documentos

    Na linha de pesquisa de Barry (1994), existem limitações no conceito de fases da gestão de documentos. Pense nos documentos eletrônicos: os mesmos são dinâmicos e recursivos por natureza, podendo existir em mais de uma fase simultaneamente ou ressurgir em uma fase mais antiga. Diante disso, as pesquisas sugerem que, com relação a documentos eletrônicos, é necessária uma extensão do conceito de ciclo de vida documental.

    Neste contexto, Greg O’Shea e David Roberts, arquivistas australianos, sugerem que exista um contraste entre os conceitos de ciclo de vida completo (continuum documental) e ciclo de vida tradicional.

    No ciclo de vida tradicional, os arquivos (documentos) são vistos como “saídas” (outputs), enquanto no continuum documental eles são vistos como “transações”. A Associação de Padrões da Austrália (S.A.A, 1996) definiu o continuum documental como toda a extensão da existência de um documento, referindo-se a um regime consistente e coerente de processos de gestão, desde a data de criação do documento (e antes da criação, no planejamento de sistemas de gestão) até a preservação e uso deste documento como arquivo.

    Nesta perspectiva, nota-se que a introdução de sistemas de gestão eletrônica de documentos gerou mudanças no conceito padrão de ciclo de vida documental, substituindo-o pelo conceito de continuum documental.

    Fases da Gestão de Documentos no contexto eletrônico

    Conforme relata Yuosoff (2000), o ponto central na diferenciação entre documentos digitais e em papel é o “meio” no qual se encontram. Documentos em papel são tratados como objetos tangíveis, enquanto documentos eletrônicos são dependentes de hardware e software, podendo se tornar obsoletos rapidamente.

    A Associação de Padrões da Austrália (S.A.A, 1996) afirma que, na gestão de documentos eletrônicos, o objeto de estudo passa a ser o conteúdo do documento, não mais o “meio” no qual se encontra. Sendo assim, sabendo que os documentos são dependentes da tecnologia atual, seu conteúdo é passível de transformação e conversão. Estes pontos foram responsáveis pela promoção do conceito de continuum documental na gestão de documentos.

    Concluindo

    Os avanços na tecnologia demonstraram que a gestão de documentos de forma tradicional não era mais adequada. O conceito de ciclo de vida documental (fases da gestão de documentos) precisava ser substituído por um novo modelo, ou seja, algo que representasse com mais clareza as características específicas dos documentos eletrônicos.

    A ideia de “continuidade” proposta pelo continuum documental explica que, diferentemente dos documentos em formato de papel, os arquivos digitais não possuem um “fim de vida”, pois até mesmo quando descartados podem voltar a um estado anterior ou serem transformados em outros tipos de dados.

  • Conheça o AngularJS, novo aliado do Fusion Platform

    Conheça o AngularJS, novo aliado do Fusion Platform

    A introdução do framework AngularJS ao Fusion Platform oferece vantagens aos desenvolvedores e abre portas a novos mercados para este sistema que já vem apresentando resultados surpreendentes na gestão integrada de processos, documentos e indicadores para obtenção de soluções mais ágeis e assertivas para as empresas.

    Um dos principais pontos melhorados foi o desenvolvimento da aplicação, que passou a ser mais elegante e estruturado, com menos linhas de código, passível de testes e compatível com outros frameworks emergentes, agregando também mais valor de mercado ao produto. Do ponto de vista comercial, a introdução do Angular JS foi responsável pela modernização do Fusion, trazendo o produto a um patamar mais elevado. Confira abaixo as cinco principais características do AngularJS que contribuem para a sua utilização no Fusion:

    1. Organização dos componentes de forma hierárquica e independente

    A organização hierárquica de uma aplicação AngularJS é prevista em documentação, e os desenvolvedores podem optar por seguir as boas práticas de programação. Foi escolhida uma configuração de pastas relacionada ao modelo de camadas do AngularJS, que é baseado no MVC e permite a separação de conceitos (separation of concerns) de uma aplicação web.

    root/# diretório raíz.
    app.js# js do módulo principal da aplicação.
    ….assets/# componentes javascript não relacionados à aplicação Angular (ex. jquery).
    ….common/….css/# serviços e diretivas compartilhados por toda a aplicação Angular.# folhas de estilo
    ….controllers/….services/….directives/….filters/….tpl/

     

     

    # controllers, serviços, diretivas, filtros e templates html.

    Através desta configuração, cada conceito da aplicação Angular é disposto em pastas diferentes. Por exemplo, todos os arquivos HTML (interfaces) estão presentes na pasta tpl, enquanto todos os serviços (comunicação com o servidor) ficam na pasta services. Estes conceitos, quando separados, permitem o desenvolvimento independente dos componentes da aplicação.

    1. Programação reativa através do conceito de Two way data-binding

    O paradigma da programação reativa pode ser explicado da seguinte maneira: imagine um documento Excel contendo diversas células. A alteração no valor de uma célula pode refletir no valor de outra, sem que a pessoa a altere explicitamente. O AngularJS é um framework reativo. Qualquer alteração em tela, como por exemplo, o preenchimento de um campo texto, reflete no modelo javascript subjacente que contém as informações da tela, sem que o programador precise “codificar” esta alteração.

    01
    Figura1 – Reatividade no AngularJS

    Qualquer alteração realizada no campo texto é refletida no modelo Javascript, e vice-versa (Two way data-binding). Esta característica proporciona ganhos de produtividade e redução do número de linhas de código, pois o AngularJS fica responsável pela sincronia dos dados da aplicação, assim como o Excel é responsável pela alteração automática do valor de uma célula.

    1. Templates HTML

                No AngularJS, os templates HTML são arquivos que podem ser anexados a qualquer parte da aplicação e garantem o reuso de componentes. Um designer pode, por exemplo, definir um arquivo HTML contendo um formulário, e disponibilizá-lo para todos os pontos da aplicação que necessitem de um.

    form.html

    02

    A grande vantagem desta abordagem é a criação de um trabalho conjunto envolvendo designers e desenvolvedores. Enquanto os designers criam os templates, os desenvolvedores podem utilizá-los de acordo com suas necessidades. O Fusion utiliza o framework Bootstrap como suporte ao desenvolvimento de componentes reutilizáveis.

    1. Arquitetura MVC

                O AngularJS utiliza o conceito de MVC (Model-View-Controller), que é caracterizado por:

    MODEL: Camada de negócios, responsável pela lógica dos dados da aplicação.

    VIEW: Responsável pela visualização dos dados da aplicação.

    CONTROLLER: Controla a interação com o usuário. Comunica-se com a view e o model.

    A arquitetura MVC permite que cada aspecto da aplicação web seja analisado separadamente. É permitido, por exemplo, desenvolver o layout da aplicação (view) sem ter conhecimento do modelo (dados) da aplicação. Isto torna possível, por exemplo, a separação entre desenvolvedores front e back-end. Enquanto os primeiros desenvolvem a interface (view), os últimos se preocupam com a lógica dos dados (model), sem ter conhecimento da interface. Isto gera um senso de independência entre os desenvolvedores e possibilita a contratação de pessoas especializadas em áreas específicas.

    1. Serviços RESTful

     A comunicação entre o navegador web e o servidor da aplicação é realizada pelo AngularJS através do padrão REST. Esta arquitetura estabelece padrões na utilização do protocolo HTTP  e define, por exemplo, que o comando PUT deve ser utilizado para enviar um recurso ao servidor e DELETE para removê-lo. Antes da utilização do AngularJS, o Fusion utilizava o conceito de servlets para realizar a comunicação cliente-servidor. Este conceito não enfatiza os mesmos padrões do REST e por isso torna-se inferior ao analisar-se a aplicação do ponto de vista organizacional. Outra característica do padrão REST é permitir que as interfaces sejam chamadas de forma isolada. Normalmente, um serviço REST é acessado através de uma URL, exemplo: http://192.168.1.25:80/app/rest/getusers. O retorno deste serviço – neste exemplo, uma listagem de usuários (getusers), pode ser anexado a qualquer parte da aplicação, basta chamar a URL.

    03
    Figura 2 – Chamada da interface pela URL


    A facilidade que o AngularJS trouxe para o Fusion Platform é mais um dos vários motivos para você conhecer e implantar este sistema em sua empresa, levando mais praticidade e inteligência à gestão integrada de processos, documentos e indicadores.

Fale com a gente