GRAI Integrated Methodology (GRAI-GIM)

Inicialmente reconhecida como GRAI, Graph with Results and Activities Interrelated, foi proposta pela Universidade de Bordéus como uma metodologia, cuja evolução originou um modelo, nela baseado. Este modelo dá pelo nome de GIM, GRAI Integrated Methodology, e veio estabelecer uma aproximação estruturada para análise e modelação de projetos CIM (Lin, 1999).

A framework GRAI-GIM é composta por dois métodos um dos quais, orientado ao utilizador, o

outro orientado à componente técnica. O método orientado ao utilizador procura converter os requisitos definidos pelo visado, em especificações que se manifestam quer ao nível funcional quer ao nível informacional e ainda ao nível dos recursos. Por outro lado, o método orientado a componente técnica procura a conversão de especificações do utilizador em especificações técnicas em termos dos componentes tecnológicos de informação e manufaturação e em termos organizacionais. Tal especificação deve permitir ao implementador definir claramente os componentes necessários para implementar o sistema. (Peristeras, 2001). Segundo o mesmo autor, esta framework é fortemente influenciada pelo seu modelo, o denominado GRAI model onde são utilizados quatro sistemas cooperadores, com o intuito de fornecer uma representação gráfica da estrutura genérica de componentes que compõe um sistema CIM (Computer Integrated Manufacturing), bem como uma perspetiva de como estes mesmos elementos se conectam entre si. Os subsistemas identificáveis para este modelo e anteriormente referidos, são o Sistema Físico (Physical System), o Sistema de Decisão (Decision System), o Sistema de Informação (Information System) e a Perspetiva Funcional (Functional View), representados na Ilustração 12.

O Sistema Físico engloba todos os componentes físicos de um sistema CIM tais como maquinaria e trabalhadores envolvidos no processo de transformação de matéria-prima. Por outro lado o Sistema de Decisão representa a hierarquia do processo de tomada de decisão existente num sistema CIM, onde a subdivisão do processo de decisão segundo diferentes níveis hierárquicos posteriormente subdivididos em tipos de função, torna possível a identificação de centros de decisão. A identificação e modelação destes, é parte importante da framework GRAI, uma vez que é neles que as decisões de determinada função em determinado nível hierárquico são tomadas.

No que respeita ao Sistema de Informação, este representa uma ligação entre o Sistema Físico e o Sistema de Decisão assim como uma ligação entre estes dois e o ambiente envolvente à organização, através do armazenamento e transformação de informação. No que respeita à Perspetiva Funcional, esta remete para a possibilidade de os três sistemas apresentados anteriormente serem encarados com três perspetivas distintas do sistema. Em cada perspetiva a observação é feita considerando aspetos particulares do sistema de forma exclusiva, remetendo outro tipo de observação para as restantes perspetivas. Mantendo este conceito em linha de consideração, para além das três perspetivas já existentes, foi criada uma quarta, a perspetiva funcional, que visa uma representação simplista das principais funções de todo o sistema e respetivas interações entre elas. Assim, a Perspetiva Funcional ajuda a criar uma representação simplificada do sistema atual, mas também representa um papel importante na definição dos limites do domínio de estudo a aplicar (Peristeras, 2001).

Para além do GRAI Model, esta framework apresenta também a sua componente de modelação que se caracteriza por uma abordagem aberta e genérica. A denominada GIM modeling framework

oferece a possibilidade de definir várias arquiteturas, dentro de uma mesma framework, tomando como base a noção de que as variáveis ciclo de vida organizacional e nível de abstração são independentes

44 Capítulo 2: Arquiteturas de Sistemas de Informação

entre si (Chen, et al., 1997). Assim, segundo os mesmos autores, para cada fase do ciclo de vida da organização pode ser criado um modelo organizacional em distintos níveis de abstração, a saber o Nível Conceptual (Conceptual Level), o Nível Estrutural (Structural Level) e o Nível de Realização (Realization Level).

Ao Nível Conceptual não existe armazenada informação técnica ou organizacional, caracterizando-se por ser o mais estável dos três níveis e onde a preocupação principal se prende com a resposta à questão, “o quê”. Já ao Nível Estrutural, a complexidade é incrementada assim como o número de questões a que se procura dar resposta, sendo elas “quem?”, ”quando?” e ”onde?”. Finalmente ao nível de Realização são integrados os componentes técnicos do sistema, sendo a este nível escolhidos os componentes reais que deste farão parte, o que torna este nível de abstração o mais específico de todos eles (Peristeras, 2001).

De notar que, os níveis de abstração e as perspetivas apresentadas não existem independentemente entre si, existindo entre eles um relacionamento, como se observa na Ilustração 13. (Peristeras, 2001).

A abordagem estruturada desta framework procura conseguir fornecer ao utilizador as especificações em termos de organização, de tecnologias de informação e de sistemas de manufaturação para a nova empresa, sendo esta abordagem composta por quatro fases distintas, a saber Inicialização (Initialization), Análise (Analysis), Construção (Design) e Implementação (Implementation), apesar de ter uma maior incidência apenas nas três primeiras. A fase de construção é divida para dar resposta aos dois diferentes métodos apresentados pela framework, numa construção orientada ao utilizador ou orientada à vertente técnica. O primeiro tipo de construção fornece as especificações

Ilustração 13 - Framework GRAI-GIM - Relacionamento entre as diferentes perspectivas e os diferentes níveis de abstração. [Fonte (Peristeras, 2001)]

técnicas necessárias para que o sistema seja compreensível por todos os intervenientes, enquanto o segundo tipo de construção permite obter todas as especificações técnicas necessárias para o desenvolvimento e implementação do novo sistema. Esta divisão existe para tentar contextualizar os utilizadores que não sejam especialistas tecnológicos com o contexto do desenvolvimento do sistema e para garantir que o processo de desenvolvimento vai de encontro os requisitos empresariais antes da fase de implementação (Peristeras, 2001).