O usuário e o processo de análise

Segundo Pressman (2006), análise de sistemas define as metas de investigação e a especificação da solução do problema a partir dos requisitos levantados para a criação e implementação de um software. Larman (2004) enfatiza que a análise possui como característica a investigação do problema e dos requisitos, em vez de uma solução.

Wazlawich (2004) afirma que na fase de análise serão buscadas as primeiras informações sobre o sistema a ser desenvolvido. Nesta fase, assume-se pouco conhecimento do analista sobre o sistema e, portanto, existe uma grande interação com o usuário.

Desta forma, como observado por Pressman, Larman e Wazlawich, a análise é uma fase importante e crítica por influenciar em todo o processo de desenvolvimento. Mas, alguns analistas e, principalmente, programadores insistem na construção do software diretamente na máquina, sem uma prévia visão dos objetivos do sistema. Esta atitude é observável em programadores e pequenas empresas de software.

Lima (2006) realizou um estudo para demonstrar que um processo de análise bem estruturado conduz a uma visão mais ampla do sistema. Em seu trabalho de conclusão de curso em sistemas de informação, comparou o processo de construção de um sistema denominado “tarefura”, construído sem técnicas de análise. Em um segundo momento, realizou-se a reconstrução do software com a aplicação da técnica de caso de uso.

Segundo Lima, os resultados foram bastante significativos. Entre as funcionalidades básicas (requisitos funcionais), com ou sem a técnica, todas foram implementadas. Mas, quando se analisou os requisitos diretamente relacionados ao funcionamento da aplicação, observou-se que o idealizador do software não atentou para uma série de detalhes. No geral, a diferença em termos quantitativos destes itens (requisitos não-funcionais) ficou respectivamente em: dezoito (sem técnica) contra vinte e cinco (com o uso da técnica de caso de uso). Portanto, enfatizando a importância da aplicação de técnicas consistentes em processos de análise.

Mas, apesar das ferramentas e técnicas utilizadas em análise contribuírem no processo da investigação dos problemas de análise, deve-se elencar e discutir os aspectos relacionados ao usuário que afetam esse processo. Entre eles, encontram-se:

• Conhece totalmente o negócio a ser modelado;
• Não sabe se expressar corretamente;
• Expressa termos inerentes ao negócio a ser modelado;
• Não conhece o processo de desenvolvimento de software;
• Não emprega a devida importância a uma entrevista;
• Possui “medo” por passar informações importantes a um estranho (analista);
• Fica “entusiasmado” com a solução apresentada;

Por outro lado, um analista de sistema, tem como características:

• Insiste em propor “melhores soluções”;
• Comunica-se com uma linguagem técnica;
• Esquece que quem conhece o negócio é o usuário;
• Apresenta “artefatos” que confundem o usuário;
• Falta de preparo para se relacionar aos vários tipos de comportamento do usuário;
• Não tem um conhecimento mínimo do domínio a ser modelado;

A seguir será criticado cada um dos pontos apresentados como características dos usuários, bem como as referentes a um analista de sistema.

Discussão

No tópico anterior, verificaram-se alguns aspectos relacionados ao usuário e ao analista de sistemas. Segundo a definição já proposta, define-se o usuário como a pessoa ou algo com cognição que forneça e contribua com as funcionalidades necessárias para que um software seja desenvolvido, participando durante todo o processo. Por outro lado, o analista de sistemas é definido como o profissional responsável por investigar e entender um problema de análise.

Sabe-se que em um processo de interação usuário-analista a definição dos seus papeis é imprescindível para o bom termino dos trabalhos de análise. O papel do usuário é claro: pessoa ou algo que será entrevistado, questionado, no sentido de fornecer os insumos básicos para iniciar o projeto de construção ou manutenção de um software. Por outro lado, no que se refere a um analista de sistemas, deve-se dizer que: ele é o responsável por entender a dinâmica do problema a ser resolvido. Esta distinção é necessária porque o usuário confunde o analista de sistemas com o profissional que vai programar; apresentar protótipos de interfaces; entre outros. A definição dos papeis é importante para ficar claro o que será discutido nesta sessão do artigo.

Primeiramente, o enfoque será dado ao usuário. No tópico anterior, foram apresentadas sete características que permeiam o universo do usuário de projeto de sistemas.

O primeiro deles refere-se a: “conhece totalmente o negócio a ser modelado”. Este aspecto é importante devido ao conhecimento empírico produzido pela experiência do usuário em relação ao seu ambiente de trabalho. Portanto, por mais que um analista se esforce, nunca saberá mais do que o seu usuário sobre o seu negócio. Por exemplo, na existência de dez comércios de ferragens, provavelmente os processos de funcionamento dos dez serão muito diferentes nos detalhes, já que, seus donos, vendedores, entre outros, conhecem os pormenores de cada uma dessas organizações.

Em relação ao segundo aspecto: “não sabe se expressar corretamente”. Aqui se debate algo surpreendente! Apesar do usuário ser o detentor do conhecimento sobre o seu negócio ou área de atuação, o mesmo tem dificuldade em expressar como funcionam os procedimentos dentro da empresa ou negócio. Entre programadores e analistas de sistemas é fácil verificar frases do tipo: “ele não sabe o que quer!”; “já está mudando novamente o que ele tinha pedido”. São frases que “tiram o sono” de analistas e programadores.

Existem alguns motivos para que isto aconteça, entre eles podem-se destacar:

1. O usuário de projeto tem como prioridade o funcionamento do negócio e não o do sistema;
2. O usuário não possui conhecimento sobre a granularidade dos processos; níveis; cadeias de processos; entre outros. Para comprovar este fato, observa-se que muitas vezes o usuário fica alternando entre funcionalidades, e frases do tipo: “agora lembrei, não se esqueça que o relatório tem que ser impresso somente as quarta-feiras”, e também, “estamos falando de vendas, mas me lembrei agora, que em compras deve-se registrar o funcionário que a operacionalizou”, são observáveis em processos de analise.

Algumas soluções podem ser apontadas para evitar este tipo de problema:

1. Deixar claro que o analista quer entender o negócio e não o sistema, e;
2. Que o analista é um iniciante na área de negócio daquela empresa e, portanto, necessita entender bem do negócio.

Esses dois pontos apresentados anteriormente apontam um outro problema. O usuário está preocupado com o sistema computacional, enquanto que o analista precisa entender a lógica do negócio. Este tipo de comportamento do usuário pode ser verificado quando o mesmo expressa as funcionalidades em sentenças tal como: “na tela de venda colocar um botão para iniciar uma nova venda, uma grade para os itens...”. Esse tipo de enunciado não ajuda o analista a entender o que é “vender produto” para uma determinada organização empresarial.

Em outros casos, os próprios analistas produzem este comportamento, analisam usando diretamente os termos botões, telas, entre outros. Pode-se dizer que isto até que funcione, mas, de forma alguma consegue capturar os objetivos da organização empresarial e também as necessidades dos processos existentes internamente. A informatização não se preocupa somente em disponibilizar sistemas, mas também, que estes sistemas estejam alinhados com os processos da empresa.

O terceiro aspecto refere-se aos termos utilizados pelo usuário nas sessões de análise de sistemas. Neste caso é necessário preparar um glossário, um esquema, ou qualquer outro artefato que defina claramente o que o usuário quer expressar. Às vezes, dentro da organização, criam-se conceitos que fora dela possuem significados totalmente divergentes e, neste caso, se o analista não investigar de forma cuidadosa, o sistema produzido durante o projeto poderá apresentar resultados totalmente diferentes do que o usuário especificou. Um exemplo: “... na nossa empresa preparamos o produto a ser entregue pelo vendedor”. Ou seja, o que ele quer dizer com “preparamos”? Para uma organização, preparar poderá ser “construir” e, em outra organização poderá ser “fazer o acabamento do produto final”. Assim, observa-se que um mesmo termo, resultam em funcionalidades divergentes na produção do sistema computacional. Em relação a este aspecto, faz-se necessário o analista de sistema dominar a linguagem utilizada dentro da organização, da forma mais rápida possível.

Quarto aspecto: o usuário não conhece o processo de desenvolvimento de software. Primeiramente, necessita-se fazer uma analogia deste aspecto com a construção civil. Esta analogia é importante, porque primeiro: sistema é algo intangível, ou seja, o usuário vê o sistema operando em um computador, mas não consegue mensurar a sua dimensão, e segundo: o usuário não enxerga um sistema como algo que possui estruturas que devem ser respeitadas para o bom funcionamento do mesmo. Ou seja, como uma casa ou prédio, um software possui estruturas. Mas, fica a pergunta: “porque comparar software com casas e prédios?”. A primeira resposta pode ser dada da seguinte forma: “porque é onde habitam os dados e informações” e, a segunda: qualquer pessoa por mais inexperiente que seja, sabe dos princípios da construção de uma casa ou prédio.

Essa discussão é oportuna porque o usuário não abstrai software como um analista de sistemas e, conclui que fazer alterações, pedir novas funcionalidades, entre outros, não produz impactos na estrutura do mesmo. Mas, como todo programador e analista de sistema conhecem, algumas mudanças podem deixar um software inoperante durante meses, ou então, produzir uma série de erros inexistentes até então.

Primeiramente, verifique o que o usuário quer: “uma casinha de cachorro”; “uma casa comum”; “um prédio”. Isso é importante por dois aspectos:

1. Mostra claramente ao usuário a dimensão do software pedido pelo mesmo, e;
2. A partir da dimensão do software é possível mostrar ao usuário se certas alterações são possíveis ou não. Assim, torna-se fácil explicar que, se ele desejar uma “casinha de cachorro”, esta mesma, em um futuro próximo, não poderá ter o status de “uma casa comum”. Neste caso, deverá ser feito um novo software.

Da mesma forma, “uma casa comum” ao contrário de “uma casinha de cachorro” necessita de outro alicerce, vigas, nova estrutura hidráulica, nova rede elétrica, entre outros. Ou seja, coisas que não existem em “casinhas de cachorros”. Da mesma forma, deve-se proceder a construção de um “novo prédio”.

Além disso, estas analogias também são importantes para mostrar aos usuários a complexidade de algumas alterações realizadas em software. Por exemplo, mover os móveis de lugar em uma casa é relativamente fácil; ao contrário, mudar a posição física de uma parede em uma casa é muito mais complexo. Neste ultimo caso, é necessário tirar os móveis do cômodo, desativar as chaves de energia, quebrar paredes, entre outros. Com essa linguagem fica mais fácil para o usuário analisar se as mudanças têm grande risco ou não.

A analogia da construção de um software com a construção de uma casa ou prédio também ajuda o analista de sistemas, ou o profissional responsável por atender o usuário, a mostra-lhe em que fase está o desenvolvimento do sistema. Assim pode-se proceder à comparação, é claro, desde que a mesma seja enquadrada para uma determinada metodologia de desenvolvimento, possibilitando ao usuário entender o que a equipe de desenvolvimento está fazendo. Por exemplo, no processo unificado pode-se comparar a fase de concepção com o esboço de uma planta de uma casa ou prédio.

Quinto aspecto: os usuários não empregam a devida importância às entrevistas. Por mais formal que o analista de sistemas seja nas entrevistas, o usuário não presta a devida importância à análise por alguns motivos:

1. A entrevista está sendo efetuada durante o trabalho do usuário, ou seja, o usuário sempre dará prioridade para atender os clientes dele, e;
2. Não compreende a importância da entrevista, logo não visualiza o porquê ser entrevistado, já que, o analista sabe o que tem que ser feito. Neste caso, o analista de sistemas deve lembrar ao usuário que o mesmo está iniciando o processo de construção da “casa” ou “prédio” onde as informações da empresa irão morar. O mesmo deve questionar o usuário se ele não iria atender o engenheiro ou arquiteto que está planejando a “casa” ou “prédio” onde ele (usuário) irá morar. Com certeza, ele vai pensar duas vezes antes de dizer que não irá atender o analista de sistemas.

Sexto aspecto: os usuários possuem “medo” em passar informações importantes a um estranho. Na verdade, o “medo” do usuário não se refere somente a insegurança gerada pela idoneidade de quem o entrevista, ou seja: o analista de sistemas.

Também, existe medo em relação ao cumprimento do prazo do projeto ante a necessidade de se usar o software; Outra situação que gera muito medo e até pânico aos usuários é ouvir que o sistema está sendo desenvolvido e nunca ver nada do que está sendo codificado. Como conseqüência, as implicações de se produzir “medo” nos usuários variam de pequenas discussões, agressões verbais e até o cancelamento do projeto.

Por outro lado, o sétimo aspecto refere-se ao “entusiasmo” do cliente mediante a possibilidade do software “resolver todos os seus problemas”. Ou seja, um comportamento contrário do aspecto anterior. Apesar de que para um analista de sistemas é melhor conviver com um usuário “entusiasmado” do que com um que esteja com “medo” do projeto, ambos são comportamentos nocivos ao processo de construção do software. Deve-se ter em mente que em todo o projeto o usuário deve-se apresentar com sobriedade em relação ao andamento do mesmo. Tanto o “entusiasmo” e o “medo” são reações emocionais e afetivas que produzem a perda de foco do usuário sobre o projeto. Portanto, exige-se clareza de um analista de sistemas, ou seja, saber dizer “não” ou “sim” no momento exato, mas, lembrando que já deva ter sido estabelecido uma linguagem comum entre analista de sistema e o seu usuário.

Agora, segue a discussão sobre algumas características apresentadas pelos analistas de sistemas.

A primeira delas: insistir em apresentar melhores soluções tem como resultado dois aspectos distintos:

1. O analista de sistemas com benevolência quer mostrar ao seu cliente soluções que atendam ao negócio, e;
2. Com toda a benevolência não ser bem interpretado pelo usuário. Isso parece paradoxal, mas é exatamente o segundo caso que mais acontece na prática. O porquê deste comportamento é totalmente previsível quando você lembra do seguinte fato: “você gostaria que alguém ou um estrangeiro começasse a ditar as regras de como devem funcionar a sua casa; sua empresa; a sua forma de trabalhar?”. Provavelmente, a maioria das respostas é “não”. Um outro motivo, psicológico, que explica esse fato é que quando você domina as regras, fica mais fácil de entender o que está acontecendo. Assim, quando o analista, que na maioria dos casos é considerado um elemento “estranho” à empresa, começa a ditar regras, este tira a propriedade e autoridade de negócio do usuário. Portanto, para resolver e suplantar este tipo de situação, nos momentos iniciais de uma análise, o analista de sistemas deve se comportar como um ouvinte e produzir fielmente o que está sendo pedido pelo usuário. Somente depois de ter sido estabelecido um diálogo e confiança comum entre os dois é que fica mais conveniente o analista propor soluções que agreguem valor ao negócio.

O segundo aspecto: a comunicação do analista de sistemas com o usuário em linguagem técnica da informática é algo prejudicial. Não se observa vantagem nenhuma neste aspecto. Primeiro, porque o analista está investigando o domínio do usuário e não o seu, então, a linguagem predominante é a de negócio e a do negócio do seu usuário. Nos primeiros momentos de uma análise não tem sentido em se falar de interfaces, modelagem conceitual. Alias, mostrar o funcionamento de uma interface é algo totalmente compreensível e ajuda a criar um ambiente de confiança entre usuário e analista, agora, mostrar modelos conceituais, mapas de dependência de requisitos, só tem causado “medo” e “pânico”. Desta forma, todo analista de sistemas tem que ter em mente que: a investigação na fase de análise deve produzir o entendimento do negócio do usuário e, não, mostrar a um usuário que ele é ignorante em analise e projeto de sistemas.

No que se refere ao terceiro aspecto: “esquece de que quem conhece o negócio é o usuário”, lembra novamente que o analista deve ouvir, para depois em um segundo momento propor soluções. Nunca deve apresentar soluções que fogem do conhecimento atual do usuário. Este tipo de procedimento tem colocado muitos usuários em situações constrangedoras.

O quarto aspecto: “apresenta artefatos que confundem o usuário”. Primeiramente, define-se artefato como um documento que retrata determinado aspecto do software. Tanto a técnica de casos de uso de Cockburn (2005) e o uso de diagramas de casos de uso da UML são as exceções deste caso, já que são ferramentas de processos de análise que auxiliam o usuário a entender o que será desenvolvido no seu software. Por outro lado, apresentar documentos de arquitetura, diagramas de classes, não vai impressionar nenhum usuário e, em um momento futuro pode servir como argumento do usuário para dizer que o analista ficou perdendo tempo em desenhar diagramas. Comparando novamente com a construção civil, pode-se dizer que até hoje não existe um engenheiro ou arquiteto que tenha sido destaque na profissão, por mostrar aos clientes, suas plantas e maquetes. O que todos valorizam no final, é a casa ou o prédio construído.

Quinto aspecto: “falta de preparo para se relacionar aos vários tipos de comportamento do usuário”. Aqui se apresenta um aspecto provavelmente muito pouco trabalhado nas metodologias de desenvolvimento de software; o usuário como elemento humano. Em algumas metodologias mais clássicas como o método cascata, o usuário “aparecia” no início do desenvolvimento e novamente na “implantação”. A interação entre este e o método era mínima, produzindo softwares que não tinham quase nenhuma semelhança com o que o usuário havia especificado. Mesmo hoje, no processo unificado e no extreme programming, melhorias no relacionamento do usuário devem ser introduzidas como premissa e não como um favor ao mesmo e, neste quesito, o XP tem conseguido grandes êxitos ao desmistificar o processo de projeto de software aos usuários, trazendo-o junto ao desenvolvimento do projeto.

Na realidade, observa-se que obstante das metodologias, os analistas de sistemas têm um engessamento aos procedimentos formais de análise, concentrando-se na aplicação dos métodos e esquecendo da figura humana do usuário. Para estes casos, outros aspectos têm que ser levados em consideração:

Não se devem tratar usuários distintos e nem grupos de usuários da mesma forma, isto pode ser fatal;

Ouvir o usuário em um primeiro momento para entender sua cognição, seu “modus operandi”. Isto é importante para se promover empatia e afetividade entre usuário e analista, já que o usuário está depositando confiança e acredita que este irá resolver o problema que será investigado. Além disso, estabelecer uma relação de confiança ajuda em momentos difíceis do projeto. Ou seja, se em um determinado momento a confiança e empatia forem grandes, é capaz do usuário pedir a opinião do analista, concordar plenamente e validar a proposta do mesmo. Em outros momentos, quando o analista de sistema perceber ansiedade causada por problemas pessoais é prudente este adiar a entrevista, ou parar para conversar com o usuário, para estabelecer confiança e, a seguir, continuar novamente a entrevista.

O formalismo exagerado, analistas de sistemas de terno e gravata, do “estilo matrix” não causam boa impressão aos usuários, mas, produzem certo desconforto inicial por passarem ao mesmo a imagem de que uma “máquina” e não um ser humano está ali para auxiliá-lo. Possivelmente a psicologia poderia ser uma ferramenta poderosa para auxiliar “na cura dos problemas apresentados pelos usuários e dos sistemas do usuário”.

O último aspecto relacionado aos analistas de sistema, tem sido a falta de domínio em relação aos negócios que devem ser analisados. É importante um conhecimento prévio do que deverá ser analisado, ou seja, estudar, fazer uma revisão bibliográfica do assunto, conhecer tecnologias relacionadas ao negócio. É uma prática que apresenta bons resultados. O usuário percebe que o analista pesquisa, apresenta, sabe discutir o assunto e, claro, estabelece com isso uma relação de confiança. Algo que deve ser lembrado, principalmente aos analistas de sistemas, refere-se a “aventura” de analisar domínios dos quais eles não tem um bom conhecimento. Este tipo de procedimento pode trazer problemas na própria análise, bem como, para todo o restante do processo de desenvolvimento de software. Apesar do uso das ferramentas de análise ajudar, elas não provêem soluções. Neste caso, as soluções sempre irão depender do conhecimento do analista de sistemas em par com o seu usuário.

Considerações finais

O usuário é o principal interessado em um processo de desenvolvimento de software. Durante muito tempo esta indústria, composta por médias e grandes empresas de informática, se preocuparam com métodos e normas do processo de desenvolvimento. Isso trouxe grandes melhorias aos processos, já que, há poucos anos atrás não existia nem mesmo uma linguagem padrão de projetos, entre outros. Mas, mesmo assim, um elemento ainda continua sendo marginalizado neste processo, o usuário.

Este artigo apresentou algumas características relacionadas aos usuários e aos analistas de sistemas, cuja relação é muito importante durante um processo de desenvolvimento. O analista é o responsável por ser a interface entre toda a equipe de desenvolvimento e o usuário.

Apresentaram-se várias características de comportamentos e atitudes que são comumente reproduzidas pelos usuários. Talvez esses comportamentos sejam respostas à forma que é apresentada a eles o processo de análise e projeto de sistemas, produzindo medo, ansiedade, euforia, entusiasmo, incompreensão, entre outros.

Neste caso, apontaram-se também possíveis atitudes a serem levadas em consideração pelos analistas de sistemas que, em alguns casos devem proceder como verdadeiros “psicoterapeutas”, tamanha a diversidade de tipos de usuários encontrados em processos de analise de sistemas. Isso tem suma importância, porque uma abordagem inapropriada pode causar, em um primeiro momento, um desconforto entre ambas as partes.

Na verdade, muitas dessas observações apresentadas neste artigo são frutos de anos de experiência em análise e projeto de sistemas e, geralmente, o engessamento técnico produz situações onde os analistas de sistemas não estão preparados. Tentou-se abordar a maioria dos aspectos, mas, podem existir outros. No entanto, pode-se afirmar que as situações que foram abordadas aqui são encontradas na realidade e vivenciadas pela maioria dos analistas. Portanto, a relação analista-usuário deve ser permeada de transparência, clareza, linguagem comum e uma boa ligação afetiva.

Welder Maurício de Souza
Contato: welder.mauricio@hotmail.com

Referências

CARVALHO, A. E. S. de; et. al. Uma estratégia para a implantação de uma gerência de requisitos visando a melhoria do processo de software. Workshop de engenharia de requisitos. Argentina. 2001.
COCKBURN, A; Escrevendo casos de uso eficazes: um guia prático para desenvolvedores de software. Editora Bookman. 2005.
FERNANDES, D. B. Análise de sistemas orientada ao sucesso: porque os projetos atrasam? Editora Moderna. 2005.
JACOBSON, I; Grady, B; Rumbaugh, J; UML guia do usuário. Editora Campos. 2000.
JONES, C; Conflict and Litigation between costumers and developers. Software productivity research – Artamis corporation. 2001. Disponível em: <http: www.spr.com/news/ConflictandLitigationArticle.pdf>. Acessado em 30 de junho de 2007.
KONTONYA, G; Summerville, I; Requirements engineering: process and techniques; John Willey and Sons, 1998.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientado a objetos e ao processo unificado. Editora Bookman. 2004.
LIMA, G. A. Análise de eficiência da aplicação da técnica de caso de uso em processos de análise de sistemas. Trabalho de conclusão de curso (Bacharelado em sistemas de informação). Instituto de Ensino Superior Social e Tecnológico de Taguatinga. Taguatinga-DF. 2006.
POHL, K; The three dimensions of software requirements: a framework and its application. Information systems; Vol. 19; n.3; p. 243-258. 1994.
PRESSMAN, R. S. Engenharia de Software. Editora McGraw-Hill. 6ª ed. 2006.
ROSELINO, J. E. A indústria do software: o “modelo brasileiro” em perspectiva comparada. 228f. Dissertação de doutorado. Universidade estadual de campinas. Departamento de economia. Campinas. 2006.
STANDISH; The caos report. The Standish Group International. Inc. USA. 1994.
SWEBOK. Guide to the software engineering body of knowledge. Instituto de engenheiros elétricos e eletrônicos. 2004.
WAZLAWICH, R. S. Análise e projeto de sistemas de informação orientados a objetos. Editora Campus. Publicação da Sociedade Brasileira de Computação. 2004.