jad

1. O Desenvolvimento de Software Aplicando a Técnica Joint Application Design
Marco A. PALUDO
PUC-PR – PPGEPS – Pontifícia Universidade Católica do Paraná
R. Imaculada Conceição, 1155 - 80215-901 - Curitiba - Paraná - Brasil
FESP - BSI - Fundação de Estudos Sociais do Paraná – Curso BSI
Rua Gal. Carneiro, 216 Centro Curitiba PR Brasil - 80060-150
paludo@fesppr.br
Robert C. BURNETT
PUC-PR - PPGEPS - Pontifícia Universidade Católica do Paraná
R. Imaculada Conceição, 1155 - 80215-901 - Curitiba - Paraná - Brasil
robert@rla01.pucpr.br
João M. LOCH
CEFET-PR - PPGTE - Centro Federal de Educação Tecnológica do Paraná
Av. Sete de Setembro, 3165. Rebouças - Curitiba-PR - CEP: 80230-901
matias@fesppr.br
Dálcio REIS
CEFET-PR - PPGTE - Centro Federal de Educação Tecnológica do Paraná
Av. Sete de Setembro, 3165. Rebouças - Curitiba-PR - CEP: 80230-901
dalcio@ppgte.cefetpr.br
RESUMO
O objetivo deste trabalho é apresentar a importância da
técnica JAD e sua contribuição na transferência do
conhecimento tácito para o explícito na área de
desenvolvimento de software, minimizando os custos e
acelerando o processo de desenvolvimento e manutenção
de software. O processo para elaboração deste trabalho
iniciou com a revisão da literatura na área do
conhecimento e as suas formas de transmissão e dos
aspectos que envolvem o processo de desenvolvimento e
manutenção de software e nas ferramentas e métodos
que suportam este ciclo de desenvolvimento. Foram
identificados os principais problemas presentes no
desenvolvimento de produtos de software e observadas
as técnicas aplicadas neste processo de desenvolvimento.
Foram contatados gerentes de projetos que utilizam a
técnica JAD na região de Curitiba, no Estado do Paraná -
Brasil, com o intuito de evidenciar os resultados do
emprego desta técnica. Os dados foram processados com
base nas respostas dos entrevistados. A pesquisa
efetuada analisou e validou a técnica JAD, comprovando
a sua efetividade nas empresas que a adotam. Foram
obtidos produtos de software com maior qualidade e
projetos com maior grau de efetividade, principalmente
com a participação do usuário. Relatam-se experiências
de empresas e consultores que utilizam a técnica, tanto
para o desenvolvimento como para a manutenção de
sistemas. Pretende-se com este estudo oferecer subsídios
para os desenvolvedores interessados em inovar no
processo de criação e manutenção de software, bem
como contribuir com o processo de inovação no
desenvolvimento de serviços.
Palavras-chave: Desenvolvimento de Software,
Conhecimento; Produtividade; Planejamento.
1. O DESENVOLVIMENTO DE SOFTWARE E O
CONHECIMENTO
Nos últimos anos, o tema “conhecimento”,
segundo Reis (2000:32) [10] tem sido explorado por
autores proeminentes como Peter Drucker, Alvin Toffler,
James Brian Quin, Michael Gibbons, Thomas
Davenport, Ikujiro Nonaka, Peter Lorange, Peter Senge,
Giovanni Dosi entre outros. O conhecimento, segundo
Davenport & Prusack (1998) [1], não é dado e nem
informação – embora estejam relacionados, mas sim,
uma informação valiosa da mente humana, que inclui
reflexão, síntese e contexto. Normalmente é de difícil
estruturação, trabalhosa captura em máquinas,
freqüentemente tácito ou subentendido, de transferência
dificultosa e complexo de gerenciar. (DAVENPORT &
PRUSACK, 1998) [1].
O conhecimento implícito ou tácito, segundo
Reis (2000:33) [10], citando Gibbons (1994), refere-se
ao conhecimento não codificável o qual não pode ser
transmitido por documentos escritos e que está presente
no cérebro humano de quem trabalha com um processo
particular de transformação. Para adquiri-lo, é necessário
um grande investimento individual, financeiro e
temporal uma vez que este tipo de conhecimento se
adquire através de um longo processo de educação e de
acumulação de experiências (Reis, 2000:34) [10]. Desta
forma, o conhecimento tácito só pode ser utilizado por
quem o detém. Cita-se o exemplo dos usuários de um
software, que sabem fazer as suas atividades, adquiridas
por processos de educação e experiências ao longo de
sua vida.
O conhecimento explícito ou codificável,
segundo Reis (2000:34) [10], é aquele que pode ser
armazenado fora do cérebro humano, portanto, ele é
formal e sistemático. O conhecimento explícito, por ter
uma distribuição fácil e de baixo custo, é abundante,
especialmente como resultado dos avanços nas
tecnologias de informação, tornando-se difícil atribuir e
defender direitos de propriedade. Ainda por apresentar a
característica de baixo custo para sua distribuição, Reis
(2000:34) [10] destaca que os esforços de criação deste

2. conhecimento são elevados e seus resultados podem ser
incertos. No contexto abordado por este trabalho pode
ser evidenciada a quantidade de produtos de software,
cujo custo de distribuição é baixo, mas os custos de
elaboração e de manutenção são elevados.
O software, segundo Pressman (1995:24) [9] é
um elemento de sistema lógico, e não físico e que não se
desgasta. Para Schorer (2000) [11] o software é o melhor
negócio do mundo: não se desgasta, não polui, você
vende para um número infinito de clientes no mundo
inteiro, continua sendo dono do produto e ainda recebe
valores para a sua manutenção. Como os sistemas de
informação tornaram-se cada vez mais complexos, o
desenvolvimento, a manutenção e a operação estão
atingindo seus limites da viabilidade material e
econômica. O desenvolvimento de software é visto cada
vez mais, segundo Paludo (2003) [7] como uma
disciplina de engenharia e, desta forma, princípios e
métodos a ela inerentes vêm sendo progressivamente
aplicados, como exemplo planejamento, formalismo e
capacidade de reproduzir projetos bem sucedidos.
Diante desses fatos, a comunidade de
desenvolvimento de software tem despendido especial
atenção aos problemas apresentados nas diversas áreas e
nas diversas etapas do ciclo de desenvolvimento de
software. Nenhum grupo de especialistas isolado tem a
responsabilidade exclusiva pela criação de novos
conhecimentos (NONAKA, 1997:39). Para ele, altos e
médios gerentes, bem como os demais funcionários de
linha, desempenham todos um papel. Dessa forma, o
valor da contribuição de qualquer pessoa é determinado
pela importância da informação que ela traz ao sistema
como um todo, independentemente da hierarquia.
Algumas abordagens consideram este conceito como
valor agregado (earned value).
Os problemas que estão presentes no
desenvolvimento de software podem ser caracterizados a
partir de uma série de perspectivas diferentes, mas
segundo Pressman (1995:23) [9] os gerentes
responsáveis pelo desenvolvimento de software
concentram-se nas questões de ‘primeiro plano’, tais
como: (i) as estimativas de prazo e de custo
freqüentemente são imprecisas; (ii) a produtividade das
pessoas da área de software não tem acompanhado a
demanda por seus serviços; e (iii) a qualidade de
software às vezes é menos que adequada.
Os elevados custos do software sejam eles para
o desenvolvimento ou manutenção, têm sido objeto de
constantes discussões entre a área contratante e de
desenvolvimento. Os prazos estimados geralmente não
são cumpridos e os índices de erros para novos
programas causam insatisfação ao cliente gerando
frustrações e desconfiança. Para ilustrar e confirmar
estas características, pesquisa desenvolvida no Brasil
com gerentes de projetos de software indicou que 12,8%
dos gerentes de projetos simplesmente desconhecem os
seus custo e que 41,43% dos projetos atrasam (Machado,
2002) [5].
Além dessas, Pressman (1995) [9] destaca as
seguintes dificuldades no desenvolvimento do software:
a) não dedicação de tempo para coletar dados sobre o
processo de desenvolvimento de software; b)
insatisfação do cliente com o sistema “concluído”; c) a
qualidade de software freqüentemente é suspeita devido
a pouca importância é dada aos testes de software. Em
muitos casos os testes são executados pelo próprio
desenvolvedor, exercitando somente o que o programa
era destinado a fazer, esquecendo-se de testar aquilo que
o sistema não deve fazer. Para Pressman (1995, p.23) [9]
somente agora [1995] estão começando a surgir
conceitos quantitativos sólidos de confiabilidade e
garantia de qualidade de software.
2. CAUSAS DOS PROBLEMAS DE
DESENVOLVIMENTO E MANUTENÇÃO DE
SOFTWARE
Os problemas associados ao desenvolvimento e
manutenção do software, segundo Pressman (1995:24)
[9] foram causados pelo próprio caráter do software e
pelas falhas das pessoas que detinham a
responsabilidade pelo desenvolvimento de software. Esta
também é uma atividade nova, com pouco mais de 40
anos. O software, por ser de natureza lógica, torna-se um
desafio para as pessoas que o desenvolvem, mas os
problemas vistos anteriormente são causados por falhas
humanas. Gerências médias e altas com pouca
preparação e qualificação assumem a responsabilidade
pelo gerenciamento e desenvolvimento de projetos de
sistemas para computadores. A falta de comunicação
entre os atores envolvidos no processo cria uma
incompreensão do software a ser desenvolvido e quando
isso ocorre, os problemas associados às falhas serão
inevitáveis.
O processo de desenvolvimento de software,
segundo Pressman (1995:46) [9] contém três fases
distintas, as quais são: definição, desenvolvimento e
manutenção. Na fase de definição (o quê) o
desenvolvedor de software busca identificar quais as
informações devem ser processadas, quais as funções
desejadas, quais as interfaces devem ser estabelecidas,
quais restrições e critérios de validação. Na fase de
desenvolvimento (o como) procura-se definir como a
estrutura de dados e a arquitetura de software devem ser
projetadas, como os detalhes procedimentais devem ser
implementados, a utilização de uma linguagem de
programação e como os testes devem ser realizados. Já
na fase da manutenção o desenvolvedor concentra-se nas
mudanças associadas à correção de erros, adaptação e
melhorias.
3. O DESENVOLVIMENTO DE SOFTWARE E
SUAS TÉCNICAS
A engenharia de software vem evoluindo e
refinando técnicas e métodos para o desenvolvimento de
aplicações e sistemas de informação que sejam
confiáveis, de fácil manutenção e com custo e prazos de
desenvolvimento viáveis. Uma forma para atingir essas
metas é o emprego de reuso no processo de
desenvolvimento. Outra abordagem eficiente é a
formalização do processo de desenvolvimento e, em
especial, a formalização da documentação utilizada
como base para todo o ciclo de vida do software.
(PALUDO, 2003) [7].
Diante dos problemas e suas causas no
gerenciamento e desenvolvimento de software, quais as
técnicas que poderiam ser utilizadas para reduzir os
problemas e ampliar a participação do cliente em todas
as etapas do desenvolvimento e manutenção do
software? Como fazer para transferir o conhecimento
tácito ou implícito, que está com o cliente ou usuário, em
um conhecimento explícito ou codificável em um
software?

3. Existem muitos métodos para o
desenvolvimento de projetos de software e o Joint
Application Design – JAD, é uma técnica de reunião que
têm por objetivo acelerar o projeto de desenvolvimento e
manutenção de software. Sua aplicação permite a criação
de sistemas mais eficazes em menor tempo, tendo como
um de seus maiores benefícios à aderência que pode ter a
vários métodos de desenvolvimento de software
atualmente empregados, como análise estruturada,
análise essencial, orientada a objetos, Unified Process,
entre outras.
Desenvolvida originalmente em 1977, pela
IBM do Canadá, ela nasceu da frustração de se tentar
obter um acordo entre os usuários, quanto às exigências
e projetos de sistemas para manufatura (JUDY, 1993:11)
[4]. Visto como um meio de se obter consenso entre um
grupo de usuários, a técnica fixou-se rapidamente,
principalmente no Canadá, onde a IBM executou
diversos JAD’s para seus clientes. Embora seja visto
como uma ruptura das tradicionais metodologias de
desenvolvimento de software, segundo Judy (1993:11)
[4], o JAD é um método de senso comum. Ele vem
sendo utilizado em grande escala por empresas de
consultoria, na engenharia de sistemas e em empresas
dos mais variados segmentos de negócios (financeiro,
serviços, indústrias, comércio, etc.).
Essa técnica se adapta perfeitamente na
metodologia de desenvolvimento de sistemas, pois vem
sendo vista como um compromisso com a qualidade e o
consenso entre os desenvolvedores e os clientes. Utiliza-
se de um líder neutro que, por intermédio de reuniões,
orienta os usuários e analistas para projetarem juntos o
sistema, tornando-os co-responsáveis pelo sucesso ou
fracasso do sistema. Estas reuniões obedecem a agendas
e calendários previamente estabelecidos, as quais estão
baseadas em formalizações, regras de comportamento e
geração de documentação acerca das definições obtidas.
Por que o JAD recebeu tanta atenção e tornou-
se um padrão tão bem-sucedido? Judy (1993:3) [4]
afirma que “enquanto a maioria das metodologias difere
no padrão de diagramas e textos que empregam, o JAD
se distingue por toda a sua filosofia e abordagem”. Ele
coloca na mesma posição os usuários e profissionais da
área de sistemas para que projetem o sistema em
conjunto, através de sessões de grupo. Esta técnica
possui uma abordagem inovadora, mas dentro do senso
comum, para a definição dos objetivos e requisitos do
software e projeto das interfaces (telas, relatórios,
dados).
Os relatórios oficiais mais recentes sobre o
cenário nacional da Qualidade e Produtividade no Setor
de Software Brasileiro apresentam a técnica JAD sendo
utilizada por 8,1 % das empresas desenvolvedoras de
software. Estes números apontam uma lacuna e uma boa
oportunidade para estas empresas fazerem uso desta
técnica e aprimorarem a qualidade e produtividade em
seus processos. A fonte deste percentual de uso é a
“Tabela 40 – Práticas de Engenharia de Software
adotadas no desenvolvimento e manutenção de software”
do relatório editado em 2002 pelo Ministério da Ciência
e Tecnologia (MCT, 2002) [6].
4. JOINT APPLICATION DESIGN
Para Judy (1993:3) [4] a técnica Joint
Application Design traz diversos benefícios para o
processo de desenvolvimento de software, sendo
apresentados na seqüência os principais:
a) Maior produtividade: estudos relatam aumentos de
20 a 60% na produtividade, em relação aos métodos
tradicionais. Esses ganhos são obtidos tanto no que diz
respeito ao cronograma quanto ao número de horas
necessárias para completar as fases de definição de
objetivos, exigências e projeto das interfaces, produzindo
melhores informações.
b) Maior qualidade: embora muitas organizações
experimentam o JAD por causa de seus ganhos de
produtividade, usuários e analistas de sistemas,
costumam citar “projeto de software de alta qualidade”
como sendo o maior benefício do método.
Considerando-se o ciclo de desenvolvimento do
software, o JAD se ajusta perfeitamente em todas as suas
fases, conforme o ciclo de vida de desenvolvimento do
software apresentado na Figura 1. Pode observar-se que
o JAD atua fortemente nos três primeiros ciclos,
enquanto os últimos três ciclos referem-se a execução do
projeto após aprovação durante as reuniões. Devido à
participação intensiva das pessoas "certas", o resultado
final é um sistema que é funcionalmente correto.
c) Trabalho em equipe: promove o espírito de
cooperação, entendimento e trabalho em equipe. É
comum, nos métodos tradicionais de desenvolvimento de
sistemas, que os usuários apresentem resistências em um
novo sistema, tentando dificultar a sua implantação. O
JAD produz informações baseadas no consenso do grupo
e faz com que os participantes construam o sistema,
apoiados no conhecimento de cada um. Dessa forma,
usuários e analistas tornam-se confiantes e todos são co-
responsáveis pelo sucesso ou pelo fracasso do sistema.
d) Custos mais baixos de desenvolvimento e
manutenção: o projeto de alta qualidade, obtido através
do JAD, possibilita uma grande economia de tempo e
dinheiro durante as fases de desenvolvimento e após a
entrega do sistema. Isso é possível, pois o sistema é
desenvolvido de forma mais rápida, consistente e com o
comprometimento do usuário. Estudos têm demonstrado
que os erros na definição dos objetivos, requisitos e
projeto externo são os mais caros de corrigir, incorrendo
com freqüência em significativos estouros de prazos e
orçamentos. Segundo Gary Rusch (p.11), citado por Judy
(1993:5) [4] “a eliminação dos erros constitui até 40%
dos custos de um sistema. Desses erros, 45 a 65% são
cometidos no projeto do sistema”. Proporcionando um
projeto correto desde o início os custos com correções de
erros e manutenções são reduzidos.
Princípios do JAD
Segundo Davenport & Prusack (1999:108) [1]
a transferência espontânea e estruturada do
conhecimento é vital para o sucesso de uma empresa.
Para que ocorra esta transferência de conhecimentos
entre os desenvolvedores de software e os clientes, faz-se
necessário o desenvolvimento de estratégias para
incentivar essas trocas espontâneas. Para a obtenção dos
benefícios do JAD, segundo Judy (1993:5) [4], é
necessário que sejam seguidos os quatro princípios
básicos, para tornar o sistema mais tangível aos
participantes. Esses princípios são:

4. a) Dinâmica de grupo: desperta a força e a criatividade
da dinâmica de grupo para determinarem os objetivos e
os requisitos do sistema. Auxiliados por um líder
experiente, usuários, gerentes e analistas definem como
será o projeto, desde: o escopo; os objetivos; os
problemas com a sistemática atual; layout de telas e
relatórios; modelo dos dados.
b) Recursos audiovisuais: utiliza esses recursos para
tornar o projeto do sistema menos abstrato, permitindo
uma comunicação perfeitamente compreendida pelos
participantes.
c) Processo organizado e racional: o JAD emprega a
análise top-down e atividades extremamente bem
definidas, determinando um caminho a ser seguido desde
o início ao fim do projeto. Isso possibilita a garantia de
uma análise completa reduzindo as chances de falhas ou
lacunas no projeto e cada nível de detalhe recebe a
devida atenção.
d) A escolha do local: o local escolhido deverá ser
agradável para evitar a dispersão dos participantes e,
preferencialmente, afastado do local de trabalho para
evitar interrupções e facilitar o intercâmbio entre os
participantes. O acesso deve ser restrito aos
participantes, convidados e ouvintes para que a atenção
seja mantida durante todo o período de trabalho.
e) Documentação com a abordagem WYSIWIG "O
que você vê é o que você obtém": produz um
documento final, de forma clara e completa, onde estão
registrados os resultados do processo para que analistas e
usuários entendam as decisões tomadas. Este documento
garante a qualidade esperada do projeto e ajuda a evitar
acusações mútuas, promovendo a confiança e o orgulho
dos participantes nos documentos do projeto.
Participantes do JAD
As pessoas que participam do JAD, segundo
Judy (1993:44) [4] têm funções bem definidas, com
tarefas e responsabilidades específicas para cada uma
delas. Tudo irá depender das pessoas selecionadas, pois
pessoas sem experiência, sem imaginação e resistentes a
mudanças irão projetar um JAD ruim. Com pessoas
competentes e compromissadas, a metodologia produzirá
soluções inovadoras e altamente eficientes. Os principais
integrantes do JAD são:
Condutor (líder de reunião, mediador): é a
pessoa que irá conduzir o JAD tendo como principais
atribuições reunir e conduzir os participantes do JAD.
Deve ter facilidade de comunicação, possuir grande
conhecimento e experiência (teoria e prática) na
condução e apresentação da técnica ao grupo; ter
capacidade de controlar as discussões e superar as
questões pessoais entre os participantes; estar sempre
preparado e pronto para surpresas que possam surgir no
decorrer da reunião; ter conhecimento de sistemas
aplicativos; ser imparcial, ter domínio de grupo e
facilidade de síntese.
Analista de Sistemas: geralmente é a pessoa
que efetuará o desenvolvimento do sistema, dando
continuidade aos trabalhos do JAD. Suas principais
características: possuir conhecimento das necessidades
do usuário; ter competência na elaboração da
documentação; saber comunicar-se; possuir boa redação
e conhecer o negócio da empresa.
Patrocinador: o Patrocinador ou Executivo
Responsável é a pessoa que possui autoridade suprema
sobre a área funcional que o sistema abrangerá. Suas
principais atribuições são: resolver os conflitos que
ocorrem durante as sessões; fornecer uma visão
estratégica para os participantes, pois conhece as
diretrizes gerais da empresa e os objetivos a atingir;
manter o projeto suprido de recursos financeiros e
humanos quando o sistema estiver em produção e deve
participar em tempo integral das reuniões.
Usuários do sistema: são as pessoas que irão
trabalhar com o sistema. Suas informações serão de
extrema importância para implementação do sistema e
suas principais atribuições são: apresentar as
necessidades de processamento de informações para o
sistema e fornecer dados importantes para a abrangência
do mesmo; decidir sobre o projeto, pois será o principal
interessado no sistema; participar das votações e avalizar
as decisões tomadas. A sua principal característica é a de
possuir experiência e bom conhecimento do ambiente
organizacional da empresa.
Documentador: o responsável por esta
atividade deve fazer todas as anotações necessárias para
produzir o documento final do JAD e auxiliar o líder de
reunião.
Demais participantes: a prática tem
demonstrado que eventualmente são necessárias outras
pessoas no processo e que tal necessidade deve ser
avaliada pelos membros do projeto e do usuário, tais
como: Gerente da área de sistemas, Auditoria interna,
especialista e equipe de desenvolvimento (caso esteja
definida).
4.3 ORGANIZAÇÃO E A APLICAÇÃO DO JAD
EM UM PROJETO DE SOFTWARE (ADAPTAÇÃO
DA TÉCNICA)
O JAD é organizado em quatro sessões, sendo
elas:
a) Primeira reunião: a primeira reunião,
conduzida pelo Patrocinador o qual fará a abertura dos
trabalhos, apresentando os participantes. Nessa reunião
são definidos: a) o escopo do sistema (a idéia principal
do que se espera do sistema); b) os objetivos específicos
a serem alcançados com o novo sistema; c) os problemas
com a sistemática atual, os quais o sistema deverá
resolvê-los; d) os limites do sistema; e) as pessoas a
serem entrevistadas durante a fase de levantamento de
dados; e f) a data da sessão de Design.
b) Levantamento de dados e análise: a etapa
de levantamento de dados inicia-se após a primeira
reunião, cabendo a sua execução ao Analista de Sistemas
responsável pelo projeto. Ele efetuará o levantamento de
dados e a análise, utilizando-se como base os itens
definidos na reunião inicial, descrevendo os processos ou
eventos e elaborando os respectivos Diagramas de Fluxo
de Dados - DFD's.
c) Planejamento para a Sessão de Design: é
prudente fazer uma reunião de planejamento da sessão
de design entre o Analista de Sistemas e o Condutor.
Nessa reunião, o Analista de Sistemas apresenta ao
Condutor a proposta do sistema a ser debatida no Design
para que o mesmo tome conhecimento do sistema e
apresente suas críticas e sugestões com o objetivo de
melhorar a apresentação da proposta. Concluída esta
etapa, o Analista responsável irá preparar o material de
apoio (proposta do sistema), a lista de presenças, a pauta
para a reunião, a convocação dos participantes e
providenciar os recursos audiovisuais para a sessão de
design.

5. d) Reunião de design: a reunião de design é o
ponto alto da técnica do JAD, pois é o momento onde os
atores envolvidos no projeto irão debater sobre a
proposta a ser apresentada pelo Analista de Sistemas
responsável. Esta reunião está dividida nas seguintes
etapas:
d.1) Apresentações, definição de objetivos,
levantamento de problemas e limites do sistema: o
condutor administra o progresso da reunião,
apresentando inicialmente a pauta e fornecendo aos
participantes uma visão geral da técnica do JAD, seus
objetivos e quais as responsabilidades dos integrantes.
Através da dinâmica de grupo, definem-se os objetivos a
serem alcançados com o novo sistema, problemas
encontrados com a sistemática atual, prioridades, limites
e soluções;
d.2) Análise dos processos, dados e
interfaces do sistema: o Analista de Sistemas apresenta
o esboço do sistema, cabendo aos usuários debaterem
cada processo apresentado e sugerindo as alterações
necessárias, inclusive os dados das tabelas, os layouts e
os relatórios (pré-impressos ou não). Também é possível
que esses layouts sejam montados durante a própria
sessão de design. Uma vez concluído o processo, passa-
se ao processo seguinte;
d.3) Análise do novo fluxo e necessidades
administrativas surgidas: concluída a análise dos
processos, dados e interfaces do sistema, o Condutor
verifica junto aos participantes os aspectos de segurança
e auditoria do novo sistema. Nesta etapa o novo fluxo de
trabalho é analisado e debatido, registrando as eventuais
sugestões e problemas. Posteriormente os participantes
identificam as necessidades administrativas que possam
ter surgido com a proposta apresentada, relacionando-as
e identificando os responsáveis e prazos para a solução
de cada necessidade;
d.4) Cronograma, aprovação do novo fluxo
e avaliação da reunião: o Analista de Sistemas
apresenta o cronograma, prazos e responsáveis para o
desenvolvimento e implantação do sistema. Para a
aprovação do novo fluxo do sistema o Condutor do JAD
busca a aprovação do sistema proposto junto aos
participantes, verificando se o mesmo irá solucionar os
problemas atuais e se atenderá os objetivos a serem
alcançados, bem como os limites propostos. Esta etapa é
de fundamental importância, pois as responsabilidades e
os compromissos são acordados neste momento.
Também a aprovação do novo fluxo é essencial e cabe
ao Condutor da sessão alertar a todos os participantes
que estarão aprovando e concordando com todas as
decisões tomadas durante a sessão de design, afetando
diretamente todas as etapas posteriores do ciclo de vida
do desenvolvimento do software. Ao final da sessão de
design, o Condutor busca a opinião dos participantes
quanto à utilização da técnica do JAD, com o objetivo de
identificar os pontos positivos e corrigir as falhas para
aprimorar as futuras reuniões;
d.5) Documento final: após a conclusão da
sessão de design, o Analista de Sistemas irá elaborar um
documento final, abrangendo todas as sessões do JAD,
com base nas anotações realizadas pelo Documentador.
Esse documento representa as conclusões do grupo,
estabelecendo o compromisso de todas as partes
envolvidas no desenvolvimento do sistema e será
assinado por todos os participantes. Cada participante, ao
assinar o projeto, está assumindo a co-responsabilidade
pelo sucesso ou fracasso do sistema.
Essa abordagem cria um comprometimento
mútuo pelo sucesso do projeto, minimizando a procura
pelos “culpados” quando um projeto fracassa. Nesta
etapa pode haver duas formas de procedimento. A
primeira, mais comum, ocorre com a elaboração
posterior da ata que será entregue para a apreciação e
aprovação por todos os envolvidos em um momento
seguinte ao da reunião. A segunda abordagem ocorre
quando é disponível recurso de ferramentas
automatizadas durante as sessões do JAD. Nesta última
abordagem, no exato momento em que as sugestões e
correções vão sendo evidenciadas, o Documentador
transcreve cada comentário ou alteração no próprio
corpo do projeto, seja um texto, um DFD ou um modelo
de dados. Desta forma, ao final da reunião toda a
documentação está atualizada e pode ser verificada e
assinada ao término da sessão. Tem-se esta abordagem
como a mais indicada, mas é considerada pré-requisito
para o sucesso da técnica JAD.
Apesar de toda a preparação das sessões, Paula
Filho (2003:117) [8] alerta para os riscos e cuidados na
condução das sessões JAD, pois as sessões [do JAD]
exigem intenso comprometimento dos desenvolvedores e
clientes, embora durem normalmente um período
bastante curto se comparado a duração do projeto
completo. Deve ser constantemente enfatizado o
benefício da aplicação desta técnica até mesmo para que
o cliente e os gestores liberem, das atividades
corriqueiras, todos os participantes que sejam
considerados importantes para a reunião. Dentre os
principais problemas que podem comprometer a eficácia
dos JADs são evidenciados: a) não-participação das
pessoas que desempenham papéis chaves nos processo
de negócio que irão utilizar o software; b) participação
de pessoas não comprometidas com o sistema e com os
objetivos iniciais; c) número reduzido ou excessivo de
participantes.
5. RELATO DE USO DE CONSULTORES
QUE UTILIZAM O JAD EM CURITIBA/BRASIL
Na opinião dos Consultores, Denis D.
Fernandes [2] e de Mário G. Gabardo [3] (2003), a
produtividade é ampliada em aproximadamente 30%
tendo em vista que o trabalho é realizado em conjunto e
as divergências são discutidas até que se chegue a um
consenso. Dessa forma, a análise de requisitos torna-se
uma tarefa menos estafante para o Analista de Sistemas,
reduzindo sensivelmente o tempo necessário para as
demais fases do desenvolvimento de sistema. Quanto à
qualidade os Consultores dizem que reduz
substancialmente o descontentamento do usuário com o
sistema produzido, pois ele participa ativamente das
definições dos requisitos. Nos trabalhos em equipe, os
consultores observam que há diferentes tipos de pessoas
e cada um com suas características, uns contribuindo
mais, outros menos, mas de uma forma geral consegue-
se as definições desejadas. Observam, também, que há
uma intensiva participação do usuário na análise de
requisitos, no desenho das interfaces e definições das
informações, tornando-o comprometido e co-autor do
sistema, dividindo as glórias e as dificuldades com o
analista de sistemas.
Quanto aos custos mais baixos de
desenvolvimento e manutenção, os Consultores afirmam
que o JAD agiliza a fase de análise do sistema,
permitindo um projeto físico estável e sem alterações

6. durante o desenvolvimento em função da alta qualidade
dos requisitos. A fase de manutenção, após a entrega,
será menos corretiva e mais evolucionista do produto. Os
consultores observam ainda que quando se diz maior
produtividade e maior qualidade está se dizendo custos
mais baixos. Como na empresa a produtividade
aumentou em 30%, pode-se dizer que os custos de
desenvolvimento diminuíram nesta proporção, deixando
de existir aquele custo de manutenção que existe na
implantação do sistema.
Quanto ao processo organizado e racional, os
Consultores afirmam que sempre que se utiliza método,
organização e planejamento para o entendimento de
qualquer coisa, a probabilidade de sucesso é muito
maior. No desenvolvimento de sistemas não é diferente.
A organização e o formalismo do JAD aumentam e
muito o sucesso do projeto. A agenda deve ser conhecida
por todos com antecedência e o Condutor é o
responsável por executá-la com autoridade, caso
contrário, o processo não funciona.
Destacam, ainda, que a técnica foi tão bem
aceita que foi incluída na Metodologia de
desenvolvimento de Sistemas, sendo obrigatório o seu
uso. Consideram, também, o papel do Condutor do JAD,
o qual deve conhecer a técnica, já ter participado na
aplicação em outros sistemas e ser um apreciador
vibrante da técnica. Deve também ser analista de
sistemas sênior para que, não sendo comprometido com
a solução, poder levantar pontos com definições
precárias que poderão trazer impactos negativos no
projeto físico, etc.
Os Consultores destacam que a aplicação do
JAD, comparado à outras técnicas, é a melhor ferramenta
para o desenvolvimento de sistemas que já surgiu. O
Analista de Sistemas que não adotar algo parecido, com
certeza terá muitos problemas em sua profissão,
principalmente nos dias atuais em que as soluções estão
cada vez mais complexas, envolvendo não só usuários
internos à empresa, como também clientes e
fornecedores.
6. CONCLUSÃO
O software tornou-se o elemento principal da
evolução dos sistemas e aplicações baseados em
computador. Por outro lado, encontra-se a dificuldade
para a transferência do conhecimento tácito para o
conhecimento explícito. Os desenvolvedores conhecem
as técnicas para o desenvolvimento do software mas, na
maioria das vezes, desconhecem o conhecimento das
atividades do cliente. Esse impasse leva ao
desenvolvimento de softwares de baixa qualidade e
produtividade gerando, muitas vezes, atritos entre os
atores. A técnica do JAD, se adaptada à realidade da
empresa e aplicada corretamente tende a aproximar esses
atores e torna-se uma interface para a conversão do
conhecimento tácito em conhecimento explícito. O
consenso e o comprometimento entre os atores cria um
ambiente de despeito mútuo e de responsabilidade pelo
sucesso do sistema. A técnica do JAD pode ser aplicada
em outras atividades, tais como: reuniões de negócio,
avaliação e implantação de pacotes de software, entre
outras atividades. Pelas informações dos consultores
pesquisados, observa-se que a técnica desenvolve um
importante papel na intermedição de conhecimentos
entre as equipes de trabalho.
7. REFERÊNCIAS
[1] DAVENPORT, Thomas H; PRUSACK, Laurence.
Conhecimento empresarial: como as organizações
gerenciam o seu capital intelectual. Rio de Janeiro:
Campus, 1998.
[2] FERNANDES, Denis Donato. Entrevista concedida
em março/2003 em Curitiba, Paraná, Brasil.
[3] GABARDO, Mário Gerson. Entrevista concedida em
março/2003 em Curitiba, Paraná, Brasil.
[4] JUDY, August H. (1993). Joint Application Design.
São Paulo: Makron Books, 1993.
[5] MACHADO, Cristina Filipak (2002). A-Risk: Um
Método para Identificar e Quantificar Risco de Prazo em
Projetos de Desenvolvimento de Software. Curitiba:
PUCPR. Dissertação de Mestrado, 2002.
[6] MCT - Ministério da Ciência e Tecnologia (2002):
Qualidade e Produtividade no Setor de Software
Brasileiro. N.4 (2002). Brasília: Secretaria de Política de
Informática. ISSN 1518-112X.
[7] PALUDO, Marco Antônio; BURNETT, Robert
Carlisle. O Reuso de Componentes da Modelagem
Dinâmica. In: 2DA. CONFERÊNCIA
IBEROAMERICANA EN SISTEMAS, CIBERNÉTICA
E INFORMÁTICA CISCI 2003, Orlando: International
Institute of Informatics and Systemics IIIS, 2003. v. 1.
[8] PAULA FILHO, Wilson de Pádua. Engenharia de
Software: Fundamentos, Métodos e Padrões. Segunda
Edição. Rio de Janeiro: LTC, 2003.
[9] PRESSMAN, Roger S. Engenharia de Software. São
Paulo: Makron Books, 1995.
[10] REIS, Dálcio R. Contributos para a melhoria da
eficiência e da eficácia nas relações de cooperação entre
universidades e pequenas e médias empresas industriais
brasileiras. Aveiro/Portugal, 2000. Tese de Doutorado.
371 págs.
[11] SCHORER, Hans G. Cônsul da República da
Alemanha em Curitiba/PR. Entrevista concedida em
julho/2000. Curitiba, Paraná, Brasil
[12] STARKEY, Ken. Como as organizações aprendem:
relatos do sucesso das grandes empresas. In A empresa
criadora de conhecimento. Ikujiro Nonaka, p. 27-43. São
Paulo: Futura, 1997.