É possível usar os nossos modelo de informática no trabalho com usuários?

Autora: Maria Alexandra V. C. da Cunha


É indispensável a participação do usuário na construção de um sistema. Ponto estabelecido, argumentos conhecidos, não há dificuldade para que qualquer analista concorde com tal idéia.

Apareceram as técnicas JAD (Joint Application Design) e JAD-like (afinal uma importação pura jamais nos serviria, algo sob medida sempre veste muito melhor), usuários começam a ser convidados a participar das equipes de projeto de sistemas (e esta é uma tendência que veremos se acentuar), surgem os recursos de prototipação e de geração de código, mas o velho problema de falta de comunicação, de não entendimento dos requisitos do usuário ainda persiste.

Nossos usuários são especialistas na sua área de negócio, têm uma linguagem particular, não entendem o que analistas falam, e vice-versa,e isto não é propriamente uma novidade. Houve tentativas de formação de especialistas "bilíngües", aqueles que falariam as duas línguas - a do negócio e a de informática - mas, quando raramente isto pôde ser alcançado, o processo de formação foi lento e a um custo muito alto (afinal, é difícil ser expert em duas áreas distintas).

Neste contexto, ainda nos debatendo com problemas de comunicação usuário-informática, porque não continuarmos insistindo que as ferramentas de modelagem utilizadas pelos analistas são excelentes meios de comunicação? Talvez o que esteja errado seja a forma como têm sido apresentadas, e isto serve tanto para os modelos estruturados que podemos chamar de "convencionais" como para os modelos que começamos a ver aplicados na análise orientada a objetos.

2. MODELOS E MODELAGEM

Modelagem significa transformar uma idéia vaga numa definição precisa, com a maior brevidade possível [GAN88]. Isto se aplica a qualquer área, onde um especialista tenha que atender algum cliente com necessidades não perfeitamente conhecidas, e tal usuário seja oriundo de uma área de negócio também pouco conhecida.

Na atividade de serviços de informática, e mais especificamente no desenvolvimento de sistemas, modelagem é, por associação, transformar a idéia vaga que temos sobre as necessidades de informação de um cliente ou usuário, em uma definição precisa de um sistema de informação, e isso tão rápido quanto possível.

3. POR QUE CONSTRUIR MODELOS?

A literatura é pródiga no incentivo à construção de modelos na análise de sistemas. Eles ajudam a pensar, realçam ou enfatizam certos requisitos decisivos de um sistema e relegam outros, permitem modificações e correções nos requisitos do usuário a baixo custo e risco mínimo (pode-se mesmo abandonar o modelo, ou partes dele, e construir um novo), avaliam o grau de compreensão do técnico em relação às necessidades e requisitos do usuário, antes de iniciar a fase de construção do projeto e, finalmente, facilitam a comunicação com o usuário [YOU90].

Os analistas de sistemas vêm usando modelos no seu trabalho há anos. Tais modelos nos ajudam a nos debruçarmos mais atentamente sobre um problema, porque efetivamente nos ajudam a pensar, a descobrir riscos e possibilidades de solução (nos ajudam a simular soluções); com eles introduzimos modificações na fase de projeto sem que o custo dessas modificações seja proibitivo, deixamos de lado os detalhes irrelevantes e valorizamos outros que claramente são de fundamental importância. O grande desafio ainda é utilizá-los como ferramenta de comunicação com o usuário, e não só como ferramenta de trabalho do analista. Temos tendência de olhar os modelos que produzimos como verdadeiras "obras de arte", produto de um conhecimento herdado de uma alta sofisticação tecnológica, e não como instrumentos simples de conversas com o usuário, instrumentos de validação do projeto do sistema a ser construído.

4. PARA MODELAR SISTEMAS

Os diagramas mais comuns nos nossos ambientes de desenvolvimento são os chamados "estruturados", ou "convencionais", tais como DFD's, modelos de dados, diagramas de transição de estados, diagrama funcional ou modelo de negócio [ORT91]. Ao preenchermos um Dicionário de Dados, também estamos em atividade de modelagem, só que utilizando uma ferramenta textual,e não gráfica. O resultado ainda é uma representação simplificada da realidade, uma descrição dos pontos relevantes.

Estes modelos, apesar dos nomes pomposos, têm características comuns a muitos outros que usamos na vida quotidiana - mapas, globos, projetos de arquitetura, maquetes, e até carrinhos e bonecas de brinquedo. As simplificações da realidade no caso da análise de sistemas nos ajudam a responder perguntas específicas, tais como: O que podemos saber a respeito das funções do sistema; O que podemos saber a respeito das "coisas" do sistema (entidades) e do relacionamento entre elas; Quais os objetos do sistema; Qual o conteúdo de um determinado fluxo de dados; O que faz este processo.

Um bom modelo possui como características [YOU90]: ser gráfico, possuir adequado detalhamento textual de suporte, poder ser visualizado de forma subdividida, ter mínima redundância e ser claro para o leitor. Se é fato que os modelos que utilizamos possuem tudo isto, por que tanta dificuldade em utilizá-los como meio de comunicação com o usuário? Talvez sejam eles o elo perdido da "linguagem comum" que tanto se tem procurado.

5. DIFICULDADES NOS TRABALHOS COM OS USUÁRIOS

Já houve esforços por parte dos analistas de trabalharem na validação dos requisitos de um sistema com o usuário a partir dos modelos gerados na fase de análise. Estes esforços foram na maioria das vezes infrutíferos, e no entanto diz-se que [DeM89] "se algo do que fazemos não pode ser mostrado ao usuário, esse algo é totalmente sem valor como ferramenta de análise". Uma contradição? Não, apenas um constatar de que existem dificuldades que devem ser superadas, entre elas:

- Símbolos desconhecidos

Ao explicarmos o significado de cada símbolo de um modelo, obtemos como resposta (às vezes uma resposta não falada, mas tão clara como se o fosse): - "Eu não entendo nada dessas coisas de quadrados e flechas, entidades e não sei o que mais, isso é com vocês da computação". Como já foi falado em tom de brincadeira por um colega, parece-nos que se liga a simbologia do modelo àquelas matérias do segundo grau que não foram do seu agrado, como matemática e física. "E eu que escolhi trabalhar com X ou Y, justamente para não ter que lidar com essas coisas. Informática e seus símbolos são problemas dos malucos que escolheram trabalhar com tal profissão". Claro que isto é um exagero, temos uma série de usuários que trafegam pelas Ciências Exatas tão à vontade quanto nós, mas entre todos está disseminado (e por nossa culpa) que aqueles modelos são para nosso uso pessoal, e que eles não têm absolutamente nada a ver com o que foi gerado.

- Modelo pronto assusta

Um modelo gráfico tem a vantagem de condensar um grande volume de informações. Essa é uma vantagem para quem sabe lê-lo, e uma desvantagem para quem está tendo o primeiro contato. É muita informação apresentada numa forma desconhecida. O caso de um DFD é típico: quer coloquemos todas as informações em uma folha [GAN83], quer as dividamos numa forma top-down (sete mais ou menos dois processos) [DeM89], quer apresentemos os processos modelados evento a evento [PAL91], o volume gráfico é grande, e associado ao desconhecimento da notação, assusta.

- O modelo parece mais "certo" do que é

A forma gráfica, a apresentação, demonstra trabalho de estudo em cima do problema. Pode-se vir a pensar que, depois de tanta elaboração, os requisitos estão conforme a necessidade do usuário. Ora, forma não tem nada a ver com o conteúdo e não se pode correr o risco de não ter o modelo validado quanto à validade dos requisitos ali apresentados, apenas porque a forma corresponde aos padrões estabelecidos pela metodologia em uso na empresa.

- Resistência à novidade

Uma nova forma de trabalho sempre assusta, o medo do desconhecido não é novidade para ninguém. Neste caso temos usuários trabalhando com ferramentas novas e analistas trabalhando de uma nova forma.

- Falha na apresentação dos modelos por parte dos analistas

"O grupo de análise encarregado do seu projeto gostaria de marcar uma reunião para proceder à validação dos modelos - DFD e MER - e da especificação de processos descrita em português estruturado. Esta especificação foi feita a partir de entrevistas pessoais e com base nos diagramas de contexto e de fluxo de dados elaborados nas reuniões JAD com os seus chefes de divisão."

- Algumas sugestões para o trabalho com usuários

a) Utilize os modelos em sessões de modelagem participativa (JAD-like).
Os modelos ao serem construídos passo a passo em conjunto com o usuário tornam-se para ele conhecidos, não se corre o risco de surpreendê-lo com um grande volume de informações totalmente novo. Os modelos são os "nossos" modelos e não mais os modelos do pessoal da informática (e afinal quem sabe mais sobre o negócio do cliente do que o próprio cliente?).

b) Não apresente os modelos formalmente.

Exemplos são interessantes, mas os modelos não devem ser apresentados de uma forma acadêmica, que enfatiza a sintaxe e a notação, ao invés do uso. Os conceitos e símbolos devem ser introduzidos à medida que forem sendo necessários, o que permite uma fácil assimilação por parte do usuário. Os modelos utilizados pela análise de sistemas são de fácil compreensão, não é preciso que haja uma aula sobre cada um para que possa ser usado. A exceção a isto talvez possa ser o modelo de dados, que requer uma capacidade de abstração maior que os outros na sua elaboração, mas em algumas empresas têm havido experiências bem sucedidas utilizando Engenharia da Informação com JAD onde todos os modelos de dados são gerados em conjunto com o usuário. Uma apresentação anterior dos símbolos e um pequeno exemplo pode facilitar a condução dos trabalhos.

c) Modelagem não é oportunidade para exibição de conhecimento teórico.

É óbvio, mas não é demais ressaltar que frases do tipo "esta é a simbologia proposta pelo pesquisador Tom DeMarco", não melhoram em nada a qualidade do futuro sistema de informações.

d) Leve a atenção do grupo para o conteúdo do modelo.

A atenção do grupo deve estar voltada para o objeto do negócio, para o conteúdo do modelo, e não para a simbologia utilizada ou para detalhes de construção. Tomemos o exemplo de um mapa. Se perguntarmos a dez motoristas o que quer dizer aquele 1:10.000, a maioria dentre eles não saberá dizer o significado de tal numeração. E no entanto, dez entre dez brasileiros que dirigem sabem utilizar um mapa rodoviário. Talvez um usuário tenha alguma dificuldade de fazer um modelo sozinho, e para isso existe a figura do facilitador em uma sessão de JAD, mas é efetivamente ele que dita os requisitos do sistema, verifica, valida, através do modelo que está construindo.

e) Atenção à estética ao apresentar o modelo final.

Simplicidade, clareza, transparência. O usuário tem que reconhecer seu negócio ao visualizar o modelo. Com as ferramentas CASE, redesenhar modelos é uma tarefa trivial, deve ser consumido o tempo que for necessário até que se obtenha uma boa estética.

f) Atenção aos nomes dados aos elementos dos modelos.

Utilize o jargão do cliente, seu vocabulário, os verbos e objetos do negócio. O usuário tem que ver espelhado no modelo uma solução para o ambiente que ele domina.

g) Participação do usuário na construção.

Se o analista não é adepto da idéia de JAD, ou a empresa não é, mesmo assim os modelos preliminares devem ser feitos com o usuário, em entrevista pessoal. Quando forem apresentados os modelos definitivos, elaborados num trabalho de detalhamento pelo analista, o usuário poderá mais facilmente validá-los, será uma linguagem conhecida.

CONCLUSÃO

É indispensável a participação do usuário na construção de um Sistema de Informação. A utilização das ferramentas de modelagem para comunicação com o usuário, apregoada pelos autores de Metodologia de Desenvolvimento de Sistemas como possível e necessária, não tem sido bem sucedida. Cabe ao Analista de Sistemas, no trabalho com o usuário, a utilização apropriada dos modelos que ele já domina. Os modelos são simples, claros, transparentes. Mudando a nossa forma de atuação, podemos comprovar que o insucesso tem sido provocado pela forma como eles são apresentados, e não por deficiência dos modelos.

Referências bibliográficas

1. ANTUNES, Dante Carlos. MDS - Metodologia de Desenvolvimento de Serviços. Curitiba: Celepar/Disud, 1990.

2. DEMARCO, Tom. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989.

3. GANE, Chris. Desenvolvimento rápido de sistemas. Rio de Janeiro: LTC, 1988.

4. GANE, Chris; Sarson, Trish. Análise estruturada de sistemas. Rio de Janeiro: LTC, 1983.

5. ORTOLANI, Luiz Fernando; CUNHA, Maria Alexandra. Desenvolvendo sistemas de qualidade através da modelagem de negócio. In Congresso Nacional de Informática, 14. Anais. São Paulo: SUCESU, 1991.

6. PALMER, John; Horácio. Análise essencial de sistema. São Paulo: MacGraw-Hill, 1991.

7. SOARES NETO, Horácio. Apontamentos do seminário Metodologia de Análise da Informação. Curitiba: Mestre, 1990.

8. YORDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, 1990.