Desenvolvimento de Software com Técnica JAD

Prévia do material em texto

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 
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 casosos 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? 
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 maisbaixos 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: 
 
 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. 
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ãoestá 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 
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 melhorferramenta 
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.