PONTIFCIA UNIVERSIDADE CATLICA DO RIO GRANDE DO SUL

FACULDADE DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO









Aplicao de Ontologias
Engenharia de Requisitos em
Ambientes de DDS




Ricardo Rosa Angrisani




Dissertao apresentada como
requisito parcial obteno do
grau de Mestre em Cincia da
Computao na Pontifcia
Universidade Catlica do Rio
Grande do Sul.



Orientador: Prof.Dr. Jorge Luis Nicolas Audy








Porto Alegre
2006
















Dados Internacionais de Catalogao na Publicao (CIP)



A593a Angrisani, Ricardo Rosa
Aplicao de ontologias engenharia de requisitos em ambientes
de DDS / Ricardo Rosa Angrisani. Porto Alegre, 2006.
139 f.

Diss. (Mestrado) Fac. de Informtica, PUCRS
Orientador: Prof. Dr. Jorge Luis Nicolas Audy

1. Engenharia de Requisitos. 2. Engenharia de Software.
3. Sistemas Distribudos. 4. Informtica. 5. Ontologia.
I. Ttulo.
CDD 005.1

Ficha Catalogrfica elaborada pelo
Setor de Tratamento da Informao da BC-PUCRS































"Sonhar mais um sonho impossvel
Lutar quando fcil ceder
Vencer o inimigo invencvel
Negar quando a regra vender"
(Miguel de Cervantes)


AGRADECIMENTOS

Sou muito grato aos meus amigos que guardo no meu corao e fao questo
de manter por perto. Sejam eles membros da minha famlia, professores, colegas de
trabalho ou mesmo boas pessoas que conheci ao longo da minha jornada.
Agradeo ao Prof.Dr. Jorge Audy pela orientao, compreenso e dedicao, no
s a mim, mas ao trabalho nas reas de ensino, de desenvolvimento e de pesquisa,
sendo uma referncia de profissional dedicado, competente e de respeito.
Aos professores Dr. Michael Mora, Dr. Marcelo Blois, Dr. Ricardo Bastos, Dr.
Roberto Evaristo, Msc. Rodrigo Espndola pelo tempo dispensado, tanto na colaborao
direta ao meu trabalho como tambm em ensinamentos de vida, profissionalismo e
amizade.
Ao Prof. Eduardo Peres, pelo incentivo, apoio, amizade e colaborao para todo o
processo envolvendo o curso de mestrado, desde o ingresso at a concluso. E pela
oportunidade de crescimento pessoal e profissional atravs de ensinamentos e
orientao em vrios momentos.
Aos meus pais Ennio e Heloisa pela compreenso, carinho, apoio, suporte e
incentivo para eu sempre prosseguir, mesmo sob dificuldades. Pela orientao,
educao e referncia que me deram, fazendo de mim, com certeza, uma pessoa
melhor.
minha excelente amiga e colega de trabalho, Vanessa Pires, que deu apoio
moral, tcnico e espiritual em vrios momentos durante a minha graduao, ps-
graduao e vida. Tambm aos meus amigos Caroline Cintra, Carlos Gollo, Paulo Silva,
Jaqueline Boeck e Eduardo Gomes pela contribuio com lies de vida e sugestes no
trabalho.
minha namorada, que minha fonte de inspirao e alegria. Lcia, quero voc
sempre comigo na minha vida, no meu caminho, pois tu s minha estrela guia.






APLICAO DE ONTOLOGIAS ENGENHARIA DE REQUISITOS EM
AMBIENTES DE DDS

RESUMO

Os novos desafios que surgem em virtude da crescente distribuio de operaes
de desenvolvimento de software acentuam os problemas relacionados Engenharia de
Requisitos. Assim, a fim de amenizar o impacto do Desenvolvimento Distribudo de
Software no trabalho das equipes, este trabalho consiste em identificar um processo de
Engenharia de Requisitos no qual se obtenha valor agregado atravs da aplicao de
tcnicas de Gesto de Conhecimento. A proposta visa definir um processo no qual se
possa facilitar e prover a formalizao do conhecimento a fim de diminuir as
ambigidades na interpretao de conceitos e seus relacionamentos facilitando o
entendimento entre as pessoas. A pesquisa contribui ao propor um processo e uma
ferramenta que facilitem o trabalho das equipes dispersas com requisitos de software.

Palavras-chave: Engenharia de Requisitos, Desenvolvimento Distribudo de Software,
Engenharia de Requisitos, Ontologias, Dicionrio de Dados, Processo de
Desenvolvimento de Software.


ONTOLOGY APPLICATION ON REQUIREMENTS ENGINEERING IN
DSD ENVIRONMENTS

ABSTRACT

The new rising challenges coming from the increasing distribution of software
development operations are contributing to maximize Software Engineering problems.
So, in order to decrease the Distributed Software Development impacts in the work of
the teams, this research consists on identifying a Software Engineering process which
could have more value aggregated through the definition of a process that provides
knowledge formalization in order to decrease interpretation problems and ambiguities
about concepts and their relationships. Its expected this formalization will promote
better communication and understanding between people and will contribute with the
facilitation of the work done by the distributed teams in the software Engineering area.

Keywords: Requirements Engineering, Distributed Software Development, Software
Engineering, Ontologies, Data Dictionary, Software Development Process.




Lista de Figuras
FIGURA 1 DESENHO DE PESQUISA .................................................................................... 19
FIGURA 2 ESPIRAL DE TRANSFORMAO DE CONHECIMENTO ............................................... 30
FIGURA 3 PROCESSOS DE TRANSFORMAO DO CONHECIMENTO ......................................... 31
FIGURA 4 GRAFO BASEADO EM RDF ................................................................................. 44
FIGURA 5 CONSTRUO DE ONTOLOGIAS BASEADA NO LAL ................................................ 49
FIGURA 6 - PROCESSO DE DESENVOLVIMENTO DO FRAMEWORK METHONTOLOGY .................. 52
FIGURA 7 - PROCESSO DE DESENVOLVIMENTO DE ONTOLOGIAS HELIX-SPINDLE ........................ 53
FIGURA 8 - ABORDAGEM HBRIDA DE EVARISTO E DEDESOUZA ............................................... 55
FIGURA 9 - AMBIENTE PROPOSTO ........................................................................................ 79
FIGURA 10 FLUXO SEQENCIAL ........................................................................................ 81
FIGURA 11 - FLUXO CONTNUO ............................................................................................ 81
FIGURA 12 FLUXO SOB DEMANDA ..................................................................................... 82
FIGURA 13 ANLISE DE MUDANA SOBRE CONHECIMENTO .................................................. 84
FIGURA 14 FASE DE DEFINIES INICIAIS ........................................................................... 86
FIGURA 15 FASE DE MAPEAMENTO DE CONTEXTO .............................................................. 86
FIGURA 16 FASE DE CRIAO DA ESPECIFICAO DE REQUISITOS ....................................... 87
FIGURA 17 FASE DE GERENCIAMENTO DE REQUISITOS ........................................................ 87
FIGURA 18 FERRAMENTA RMC ......................................................................................... 88
FIGURA 19 IDENTIFICAO DE INCONSISTNCIA ENTRE CONHECIMENTO DE PROJETO E DA
ORGANIZAO ................................................................................................................... 97
FIGURA 20 MANTER ONTOLOGIAS GERAIS E MANTER ONTOLOGIAS ESPECFICAS ................ 104
FIGURA 21 ALINHAR ONTOLOGIAS, CLASSIFICAR ONTOLOGIAS E SUGERIR ONTOLOGIAS. ..... 105
FIGURA 22 ATENUAR AVALIAO DE ONTOLOGIAS ............................................................ 106
FIGURA 23 REGISTRAR MTRICAS DE ONTOLOGIAS .......................................................... 107
FIGURA 24 CONSULTAR DADOS SUMARIZADOS SOBRE ONTOLOGIAS E CONSULTAR
DADOS DE ESTIMATIVAS SOBRE ONTOLOGIAS ..................................................................... 107
FIGURA 25 MANTER CLIENTES, MANTER PROJETOS, MANTER TIPOS DE PROJETOS E MANTER
CONTEXTO DE PROJETOS. ................................................................................................ 108
FIGURA 26 MANTER CLIENTES, MANTER PROJETOS, MANTER TIPOS DE PROJETOS ,MANTER C
ONTEXTO DE PROJETOS E CONSULTAR PARTICIPAO E INTERESSE DOS USURIOS. .............. 109
FIGURA 27 REGISTRAR UNIFICAO E DESDOBRAMENTO DE ONTOLOGIAS E CONSULTAR
HISTRICO DE EVOLUO DE ONTOLOGIAS ........................................................................ 109
FIGURA 28 CONTROLE ADMINISTRATIVO E AUTENTICAO ................................................ 110
FIGURA 29 EXEMPLO DE EVOLUO DE ONTOLOGIA ......................................................... 111
FIGURA 30 MODELO CONCEITUAL DE CLASSES DE CONCEITOS .......................................... 112
FIGURA 31 MODELO CONCEITUAL DE CLASSES ................................................................ 113
FIGURA 32 TELA DE MANUTENO DE CONCEITOS ESPECFICOS ....................................... 115
FIGURA 33 TELA DE CONSULTA DE DADOS SUMARIZADOS SOBRE CONCEITOS ..................... 115
FIGURA 34 TELA DE ATENUAO SOBRE A AVALIAO DE CONCEITOS ................................ 116



Lista de Tabelas
TABELA 1- DISTRIBUIO DAS EQUIPES DE PROJETO NO CENRIO 1 ........................................ 91
TABELA 2- DIFERENA DE CONHECIMENTO RELACIONADO A REQUISITOS CENRIO 1............... 92
TABELA 3- DISTRIBUIO DAS EQUIPES DE PROJETO NO CENRIO 2 ........................................ 93
TABELA 4- DIFERENA DE CONHECIMENTO RELACIONADO A REQUISITOS CENRIO 2............... 94
TABELA 5- EQUIPE DE PROJETO NO CENRIO 3 ..................................................................... 95
TABELA 6- DIFERENA DE CONHECIMENTO RELACIONADO A REQUISITOS CENRIO 2............... 96


Lista de Abreviaturas

CMMI Capability Maturity Model Integration
DDS Desenvolvimento Distribudo de Software
GC Gesto do Conhecimento
GSD Global Systems Development
DAML DARPA Agent Markup Language
OIL Ontology Inference Layer
OWL Web Ontology Language
RDF Resource Definition Framework
RUP Rational Unified Process
TI Tecnologia da Informao
URI Universal Resource Identifier
UML Unified Modeling Language
W3C World Wide Web Consortium
XML Extensible Markup Language


Sumrio
1. INTRODUO ............................................................................................................................... 14
1.1. Justificativa ............................................................................................................................. 15
1.2. Estrutura da Dissertao ......................................................................................................... 15
1.3. Objetivos................................................................................................................................. 16
1.3.1. Questo de Pesquisa ...................................................................................................... 16
1.3.2. Objetivo Geral ................................................................................................................. 17
1.3.3. Objetivos Especficos ...................................................................................................... 17
2. METODOLOGIA DE PESQUISA .................................................................................................... 19
3. BASE TERICA ............................................................................................................................ 22
3.1. Engenharia de Requisitos ....................................................................................................... 22
3.1.1. Requisitos ....................................................................................................................... 23
3.1.2. Dificuldades da ER .......................................................................................................... 24
3.2. Conceitos da Gesto do Conhecimento .................................................................................. 25
3.2.1. Dados ............................................................................................................................. 25
3.2.2. Informao ...................................................................................................................... 26
3.2.3. Conhecimento ................................................................................................................. 27
3.2.4. Tipos de Conhecimento ................................................................................................... 28
3.3. Gesto do Conhecimento ........................................................................................................ 32
3.3.1. Aplicaes da Gesto do Conhecimento ............................................................................. 33
3.3.1.1. TI e Gesto do Conhecimento ..................................................................................... 34
3.3.1.2. Engenharia de Software e Gesto do Conhecimento ................................................... 34
3.3.1.3. Fatores de Influncia da Gesto do Conhecimento ...................................................... 35
3.3.1.4. Fatores de Insucesso nas Organizaes ..................................................................... 37
3.3.1.5. Estratgias para Gesto do Conhecimento em Ambientes Distribudos ....................... 38
3.4. Ontologias .............................................................................................................................. 39
3.4.1. Definio ......................................................................................................................... 40
3.4.2. Ontologias Aplicadas na Construo de Sistemas de Informao .................................... 42
3.4.3. Aplicao de Ontologias na WEB .................................................................................... 44
3.5. Dicionrio de Dados ................................................................................................................ 45
4. TRABALHOS RELACIONADOS .................................................................................................... 47
4.1. Modelo de Processo de Lopes para DDS ................................................................................ 47
4.2. Pesquisa de Daniela Damian .................................................................................................. 48
4.3. Pesquisa de Karin Breitman .................................................................................................... 49
4.4. Anlise de Requisitos Baseada em Ontologias........................................................................ 50
4.5. O Framework Methontology .................................................................................................. 51
4.6. O processo Helix-Spindle ..................................................................................................... 53
4.7. O Processo Knowledge Meta Process .................................................................................. 54
4.8. Abordagem para Gesto de Conhecimento ............................................................................. 55
5. APLICAO DE GESTO DO CONHECIMENTO NA ENGENHARIA DE REQUISITOS EM
AMBIENTES DE DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE ............................................... 57
5.1. Contexto de Aplicao ............................................................................................................ 57
5.2. Coleta de Dados ..................................................................................................................... 58
5.3. Anlise de Dados .................................................................................................................... 60
5.3.1. Dimenso de Dados Demogrficos ................................................................................. 60
5.3.2. Dimenso de Aspectos Organizacionais .......................................................................... 61
5.3.3. Dimenso de Aspectos Sociais ....................................................................................... 62
5.3.4. Dimenso de Aspectos Tcnicos ..................................................................................... 67
5.3.5. Dimenso de Questes Gerais ........................................................................................ 71
5.4. Lies Aprendidas .................................................................................................................. 74
6. PROCESSO PROPOSTO .............................................................................................................. 78
6.1. Ambiente Proposto ................................................................................................................. 78
6.2. Processo Proposto .................................................................................................................. 79
6.2.1. Fluxos do Processo ......................................................................................................... 81
6.2.2. Atividades do Processo ................................................................................................... 82


6.2.3. Papis do Processo ........................................................................................................ 88
7. JUSTIFICATIVA ............................................................................................................................. 90
7.1. Cenrio 1 Projetos Relacionados ......................................................................................... 91
7.2. Cenrio 2 Projetos No-Relacionados .................................................................................. 93
7.3. Cenrio 3 Projeto e Organizao.......................................................................................... 95
8. CONSIDERAES FINAIS ........................................................................................................... 98
8.1. Contribuies ........................................................................................................................ 100
8.2. Limitaes do Estudo ............................................................................................................ 100
8.3. Estudos Futuros .................................................................................................................... 101
8.4. Proposta de Continuidade ..................................................................................................... 102
8.4.1. Especificao da Ferramenta ........................................................................................ 102
8.4.1.1. Especificao Funcional da Ferramenta .................................................................... 103
8.4.1.2. Proposta de Modelo de Classes ................................................................................ 112
8.4.1.3. Prottipo de Telas e Anlise de Ferramentas ............................................................. 114
REFERNCIAS .................................................................................................................................... 117
APNDICE A ESTUDO DE CASO .................................................................................................... 126

14


1. INTRODUO

A importncia de se obter um entendimento do que deve ser feito em todas as
etapas de desenvolvimento de um produto de software torna-se cada vez mais
explcita, medida que as organizaes realizam projetos que necessitam de esforos
conjuntos de equipes geograficamente distribudas, seja entre subunidades de uma
mesma organizao ou entre parceiros. Para que se obtenha um mesmo entendimento
e que este seja uniforme para todos envolvidos em um projeto e em uma organizao,
preciso formalizar conceitos e estabelecer critrios formais de relao entre eles.
Para suprir esta necessidade de alinhamento do entendimento, a Gesto do
Conhecimento (GC) e a utilizao de tcnicas de formalizao surgem como peas-
chave, pois possibilitam o uso de processos e representao formal para estruturao
do conhecimento [ALM05] e seus relacionamentos.
Neste trabalho, aborda-se um contexto mais restrito que o de auxiliar equipes de
projeto na Engenharia de Requisitos em empresas de Desenvolvimento de Software,
tendo como cenrio os ambientes de Desenvolvimento Distribudo de Software (DDS).
Assim, tendo em vista a necessidade de amenizar as diferenas de aspectos locais e
culturais [PRI06b], eliminando dvidas ou ambigidades para que os esforos sejam
gastos em trabalho efetivo pertinente ao ciclo de vida dos projetos. Ao invs de ser
gasto trabalho desnecessrio para resolver problemas de entendimento ou para realizar
alinhamento sobre a compreenso nica de um assunto entre equipes diferentes.
A Gesto do Conhecimento pode trazer muitos benefcios para o ambiente de
trabalho de uma empresa [EVA00], no entanto preciso compreender em que
momento deve-se aplic-la e quais os mecanismos que devem ser adotados. Para que
os esforos sejam justificados e realmente facilitem o trabalho dirio dos colaboradores
de uma empresa, agregando mais valor ao processo de desenvolvimento de software
importante obter um processo definido e institucionalizado. Este processo deve servir
de base para a aplicao da Gesto do Conhecimento criando um ambiente de
incentivo e viabilidade para a adoo das prticas da Gesto do Conhecimento.

15


1.1. Justificativa
Esta pesquisa visa prover um processo de desenvolvimento que auxilie na
resoluo de problemas freqentes relacionados Engenharia de Requisitos
encontrados em organizaes que utilizam operaes envolvendo Desenvolvimento
Distribudo de Software. Embora o conhecimento seja um diferencial competitivo de
grande importncia, considerado um recurso econmico-chave por Peter Druker
[AHN02], muitas empresas no sabem como quantific-lo ou formaliz-lo. O estudo
realizado aborda a utilizao de mecanismos, tais como ontologias e dicionrio de
dados, para diminuir a incerteza sobre o conhecimento envolvido no somente em um
projeto, mas em uma organizao que desenvolve software com equipes distribudas.
Entende-se que atravs da explicitao do conhecimento possvel auxiliar a melhoria
dos processos de Engenharia de Requisitos [PRI06a].
Damian [DAM05] refora a importncia de se utilizar uma comunicao que
diminua a ambigidade, a fim de que se obtenha um entendimento comum entre os
envolvidos em um projeto com equipes distribudas e que assim sejam produzidas
especificaes de requisitos de maior qualidade, ou seja, que reflitam e descrevam
solues para as necessidades e expectativas do cliente. Em ambientes distribudos as
ontologias e dicionrios de dados representam mecanismos para resolver problemas de
ambigidade na comunicao que so muito comuns, mesmo em ambientes
controlados de pesquisa, conforme se pode verificar nos trabalhos de [AUD04],
[DAM05] e [LOP04].
Portanto, para diferentes domnios de conhecimento no portflio de projetos de
uma organizao pode-se criar um mecanismo que disponibilize o compartilhamento de
informao organizada, concisa e coerente a fim de que o escopo e a definio de
requisitos possam ser mais bem controlados, medidos e gerenciados no processo de
Engenharia de Requisitos.
1.2. Estrutura da Dissertao
A Metodologia de Pesquisa ser detalhada no captulo 2 atravs da apresentao
de um modelo de trabalho com etapas a serem seguidas a fim de se obter os
resultados esperados, atacando os objetivos gerais e especficos expostos neste
captulo, no item 1.3.
16


J no captulo 3, a base terica que foi estudada ao longo da pesquisa e que foi
considerada fonte e suporte para o procedimento do trabalho e para o aprendizado das
questes que envolvem a Gesto do Conhecimento e a Engenharia de Requisitos,
tanto genericamente quanto em Ambientes de Desenvolvimento Distribudo de Software
(DDS) servindo de apoio na construo de um processo para a Engenharia de
Requisitos em Ambientes de DDS. No captulo 4 relatam-se os trabalhos relacionados,
citando trabalhos atuais que visam atacar parcial ou integralmente os mesmos
problemas desta pesquisa, mas com abordagens diferentes.
A coleta de dados que consiste no levantamento de necessidades e entendimento
da realidade de profissionais que atuam com desenvolvimento distribudo de software
relatada no captulo 5. Em seguida, o captulo 6 compreende a especificao de um
processo de desenvolvimento de software que tem o objetivo de atender aos objetivos
do trabalho, seguindo um processo de Engenharia de Requisitos para DDS.
J o captulo 7 expe a justificativa de aplicao deste processo indicando
cenrios de ganho efetivo ao utiliz-lo no apoio a Engenharia de Requisitos em
ambientes de Desenvolvimento Distribudo de Software. Por fim, no captulo 8 so
feitas as consideraes finais sobre o tema e destacam-se as contribuies,
possibilidades de continuidade de pesquisa e de desenvolvimento de ferramentas, bem
como as limitaes deste trabalho.
1.3. Objetivos
Os objetivos so os pontos que se deseja que sejam alcanados e que
direcionaram o trabalho desenvolvido. Aqui se apresenta a questo de pesquisa, pois a
partir dela possvel estabelecer os objetivos do trabalho, direcionando-os de forma a
responder esta questo levantada. Estes objetivos so detalhados em seguida,
estabelecendo primeiro o Objetivo Geral a logo aps os Objetivos Especficos.

1.3.1. Questo de Pesquisa
A diretriz desta dissertao diretamente identificada na seguinte questo de
pesquisa:
17


Qual processo poderia para suportar a Engenharia de Requisitos em
ambientes de Desenvolvimento Distribudo de Software com o uso de Gesto de
Conhecimento?.
1.3.2. Objetivo Geral
O objetivo geral criar um ambiente no qual a utilizao tcnicas de Gesto de
Conhecimento sirvam de apoio Engenharia de Requisitos em ambientes de
Desenvolvimento Distribudo de Software (DDS). As principais fontes de problemas
nesta rea provem da distncia que acentua diferenas culturais e gera problemas de
comunicao [DAM05]. Ento, neste contexto importante que o conhecimento
relacionado aos requisitos de um sistema seja explicitado de forma a estar sempre
disponvel em um meio padro que sofra pouca ou nenhuma influncia da lngua e da
cultura.
Entende-se que um ambiente adequado ao cenrio de empresas que utilizam
Engenharia de Requisitos em ambientes de DDS deve ser composto de um processo
definido com foco no tratamento do conhecimento relacionado a requisitos de software
objetivando a minimizao de ambigidades e inconsistncias.
1.3.3. Objetivos Especficos
Os objetivos especficos so:
Aprofundar o estudo sobre a base terica da pesquisa em Gesto do
Conhecimento e na possvel aplicao desta na Engenharia de Requisitos em
ambientes de Desenvolvimento Distribudo de Software, bem como nos
processos de construo e manipulao de do conhecimento atravs de
ontologias e dicionrio de dados.
Identificar um processo de desenvolvimento para o uso de tcnicas de
Gesto de Conhecimento no suporte a Engenharia de Requisitos em
ambientes de DDS, definindo assim o escopo de aplicao do prottipo de
ferramenta a ser utilizado.
Trabalhar junto a pesquisadores das reas de Gesto de Conhecimento e de
Engenharia de Requisitos para avaliar a construo do processo outro
objetivo que ser buscado, pois atravs da colaborao de pessoas que
18


realizam pesquisa sobre o assunto na atualidade que se pode melhor guiar
os passos a serem realizados, desde os estudos at o desenvolvimento do
processo.
Exemplificar a aplicao do processo em um contexto de ganho efetivo para
os projetos de DDS.

19


2. METODOLOGIA DE PESQUISA

O trabalho realizado seguiu uma metodologia de pesquisa dividida em trs etapas
que so identificadas no desenho de pesquisa da Figura 2. Estas etapas foram
realizadas em seqncia, onde o conhecimento e as entregas eram construdos a partir
do conhecimento adquirido e dos produtos entregues nas etapas anteriores.
importante detalhar as trs etapas da pesquisa para que se entendam os objetivos
alcanados em cada uma delas.






























Figura 1 Desenho de Pesquisa

DESENHO DE PESQUISA
Especificao de
Ferramenta
Definio das
Ferramentas de Apoio
Base Terica
ETAPA 1
Estudo de Caso:
Identificao de
processo de uso de GC
em Engenharia de
Requisitos.

Especificao de
Processo
Criao de Processo
ETAPA 2
Justificativa de Processo
ETAPA 3
20


A primeira etapa consistiu em estudar, revisar e complementar a Base Terica
obtida nos estgios iniciais do mestrado. Foi realizado o estudo sobre novos trabalhos
nas reas de Gesto do Conhecimento e Engenharia de Requisitos em ambientes de
Desenvolvimento Distribudo de Software. Assim, esta base de conhecimento
possibilitou delinear uma forma de trabalho a ser adotada na Etapa 2.
A etapa da pesquisa, onde se obteve o entendimento sobre as necessidades
atuais da Engenharia de Requisitos em DDS foi a segunda. Nela foi realizada a
transposio do universo de problemas identificados para uma soluo de processo
objetivando facilitar o trabalho em ambientes de DDS atravs do uso de tcnicas de
GC. Para melhor controlar o trabalho dividiu-se este etapa em 3 sub-etapas.
Na sub-etapa Estudo de Caso: Identificao de Processo de uso de GC em
Engenharia de Requisitos para Ambientes de DDS construiu-se um processo em
conjunto com profissionais das reas de Gesto do Conhecimento e de Engenharia de
Requisitos em ambientes de DDS, tanto com foco em pesquisa, como com foco no
mercado para se obter quais os melhores pontos de insero para um processo de
apoio. Nesta sub-etapa os profissionais que trabalham com pesquisa foram consultados
para definir a construo de um Estudo de Caso que foi aplicado aos profissionais que
trabalham no mercado.
Para a Especificao de Processo, que foi a segunda sub-etapa, continuou-se
trabalhando junto a profissionais da rea de Engenharia de Requisitos para identificar
as caractersticas que agregariam valor ao trabalhar-se um processo para ambientes de
DDS. Ento, nesta especificao foram identificadas, discutidas e detalhadas as
atividades pertencentes ao processo a ser elaborado. A partir das informaes
coletadas avaliou-se o escopo para que fosse construdo o processo de forma que
fosse possvel conciliar o cronograma dos projetos das organizaes avaliadas com o
andamento desta pesquisa. A documentao gerada constituiu referncia para
consulta e posterior continuidade atravs da extenso ou manuteno do processo em
outros projetos de pesquisa.
Na ltima sub-etapa, o de Criao do Processo, foi gerada uma biblioteca de
processo com o apoio da ferramenta RMC, facilitando a sua conferncia junto s
organizaes, seu controle de configurao e sua manuteno. A terceira etapa
21


consistiu na Justificativa de aplicao do processo atravs da explicao de cenrios de
DDS onde se expe a necessidade de uso de um mecanismo facilitador para a
Engenharia de Requisitos.
22


3. BASE TERICA

Com o objetivo de utilizar um processo para Gesto do Conhecimento bem
definido, primeiro os estudos foram voltados ao entendimento dos conceitos envolvidos
na Gesto do Conhecimento, a fim de entender o que deve ser tratado, explicitando a
diferena entre estes conceitos base que so os dados, as informaes e o
conhecimento. Os conceitos base a seguir sero explicados em detalhe sob a viso de
diferentes autores. Aps definidos os conceitos principais, aborda-se a Gesto do
Conhecimento e seus contextos de aplicao. Ao final do captulo, foca-se diretamente
sobre a representao formal do conhecimento atravs de ontologias e dicionrios de
dados.
3.1. Engenharia de Requisitos
Para que um projeto de desenvolvimento de software seja bem sucedido, este
deve obedecer s suas restries de prazo, custo e tempo, no entanto, ainda deve-se
observar a qualidade do produto sendo entregue, pois este deve ser validado e
verificado. A validao consiste em assegurar que o produto final corresponda aos
requisitos do software, j a verificao consiste em assegurar consistncia,
completitude e integridade do produto em cada fase e entre fases consecutivas do ciclo
de vida do software [CMM06].
imprescindvel que o software realize a tarefa para o qual foi proposto, e para
que isto se concretize as necessidades, propsitos e caractersticas de um software
devem ser identificados, priorizados, documentados e especificados. Mesmo assim,
no se pode garantir totalmente que as especificaes criadas para um software vo ao
encontro das necessidades do cliente [PRE01]. Assim, a abordagem mais adequada
que se estabelea e siga um processo padro para a Engenharia de Requisitos (ER),
garantindo que todos os membros de uma equipe esto alinhados com este processo e
sabem trabalhar com base nele.
A Engenharia de Requisitos definida como a rea da Engenharia de Software
que aborda metas reais, funes e restries de um software, bem como engloba estes
fatores atravs da especificao do comportamento do software e de sua evoluo
[ZAV97]. A Engenharia de Requisitos que fornece os mecanismos para que se
23


entenda e analise as necessidades do cliente para poder ento apontar e analisar o que
pode ser feito para atender a estas necessidades. Com base nas necessidades prov
meios de negociar uma soluo razovel que seja especificada de forma no ambgua
e tambm prov meios para validar a especificao do software e gerenciar os
requisitos ao longo de um projeto que resultar no produto de software [PRE01].
Sabe-se que cada organizao deve adaptar os seus processos para adaptar-se
ao seu ambiente de trabalho com suas caractersticas especficas de cultura, de tipo de
projeto e de software que desenvolve, experincia, modelos de referncia que segue
(Ex: RUP [RUP98], CMM [CMM06]) e o mesmo se aplica para a Engenharia de
Requisitos. Assim, deve-se ter um conjunto estruturado de atividades que devem ser
seguidas para que seja possvel obter informaes do cliente e formaliz-las,
especific-las, valid-las para obter um acordo sobre os requisitos do software e ento
iniciar a sua construo ou manuteno [KOT98].
A maioria dos processos de Engenharia de Requisitos possui as atividades de
identificao, anlise e negociao, documentao e validao de requisitos [KOT98]
[SOM97]. A identificao consiste em apontar e formalizar as expectativas e
necessidades dos stakeholders com relao ao produto de software a ser construdo.
Aps a identificao dos requisitos iniciais parte-se para a anlise dos requisitos,
detalhando-os em alto nvel, categorizando-os e priorizando-os para que seja feita a
negociao sobre quais devem ser aceitos e se obtenha um consenso sobre esta
negociao.
Depois de analisados e negociados, os requisitos devem ser documentados em
maior detalhe, especificados atravs de documentos que identificam claramente quais
os passos e funcionalidades que o sistema deve possuir para que retorne um resultado
de valor para o cliente. Por fim, deve-se garantir que as especificaes dos requisitos
foram construdas de forma a no conterem erros ou problemas de entendimento por
parte da equipe ou do cliente.
3.1.1. Requisitos
Entende-se um requisito como sendo uma caracterstica do software que prov
valor ao cliente e que soluciona um problema ou satisfaz alguma imposio formalizada
para o software [THA00]. Tambm, um requisito pode ser entendido como uma
24


condio ou capacidade que um software deve realizar [RUP98]. Ainda pode-se ter que
requisitos so propriedades que um software deve possuir para funcionar com sucesso
no seu ambiente proposto [GOG96].
Os requisitos podem ser tipificados em funcionais e no-funcionais [THA00]
[RUP98], onde os requisitos funcionais expressam o comportamento do software pela
especificao de condies de entrada e sada que deve possuir enquanto que os no
funcionais so atributos de qualidade desejados e que no so descritos pelos
requisitos funcionais [RUP98].
3.1.2. Dificuldades da ER
O que deve ser construdo o maior problema a ser identificado, abordado e
detalhado na Engenharia de Requisitos [BER98]. Este problema mais bem
compreendido quando detalhado atravs das principais dificuldades encontradas na
Engenharia de Requisitos, segundo a literatura.
A identificao de stakeholders pode ser um problema, pois sem a percepo
de quem so as pessoas diretamente envolvidas, no possvel identificar
claramente quais so as expectativas, necessidades e relacionamentos em
relao ao software a ser construdo.
Ambigidade e falta de clareza: o conhecimento relacionado a requisitos deve
ser o mesmo tanto para a equipe de projeto que construir o software quanto
para o cliente, a fim de que se obtenha o mesmo entendimento para fins de
acordo e aprovao. Portanto importante evitar o uso de grias,
comunicao estritamente textual e desenhos ou abreviaturas [VAS03]. No
entanto, tanto a linguagem natural quanto linguagens formais, podem ter
significados e representatividade diferenciados para membros da equipe de
projeto e para clientes, por isso deve-se ter uma linguagem comum a ambos
a fim de reduzir a ambigidade e aumentar a clareza dos requisitos
especificados.
Rastreamento de Requisitos: deve-se prevenir o surgimento de inconsistncias
ao realizar a manuteno de requisitos na ER atravs da utilizao de
mecanismos de rastreamento que auxiliem o trabalho dos analistas,
desenvolvedores e de toda a equipe. O rastreamento horizontal e vertical
25


[CMM06] deve ser garantido de forma a diminuir o esforo necessrio para o
rastreamento dos requisitos [DAV95], evitando ou minimizando o aumento de
custo e prazo de um projeto.
Dificuldades de Comunicao: preciso entender, analisar e posicionar a
equipe corretamente de acordo com ambiente sociolgico no qual est inserido
um projeto de desenvolvimento de software para diminuir as ocorrncias de
dificuldades de comunicao que podem gerar especificaes incorretas ou
incompletas. Para facilitar a comunicao deve-se obter credibilidade,
engajamento e esprito de equipe entre as pessoas atravs de disponibilidade
e acessibilidade para contato pessoal em interaes formais e informais
[CAR99].
Diferenas Culturais: As diferenas culturais podem tanto ser positivas,
trazendo pontos de vista diferenciados que poderiam no ser percebidos em
ambientes menos diversificados, quanto negativas onde os mesmos pontos de
vista diferenciados podem levar aos desentendimentos sobre requisitos do
produto de software a ser construdo [DAM05].

3.2. Conceitos da Gesto do Conhecimento
Nesta seo apresentam-se os conceitos fundamentais da Gesto do
Conhecimento, que so os dados, a informao e o conhecimento em si.
3.2.1. Dados
Em Awad [AWA03] entende-se que os dados constituem fatos estticos,
desorganizados e no processados. Os dados por si s no tem significado, no entanto
a interpretao e avaliao dada a eles podem ser consideradas importantes e assim
se tornar informao. Os dados representam um conjunto de fatos discretos sobre
eventos, registros estruturados de transaes.
Os dados so utilizados quantitativamente na coleta de padres, nmero de
clientes que compram determinados produtos, por exemplo, e em outros indicadores
importantes (limites, medianas, mdias sobre um determinado contexto). Com base
26


nestes indicadores pode-se ter suporte para derivar informaes que indiquem
comportamento e varincias.
Todas as organizaes precisam de indicadores e dados, principalmente aquelas
que necessitam armazenar um grande volume de operaes e transaes. No entanto
deve-se observar a relevncia, importncia e granularidade da representao dos
dados para que deles seja extrada a informao. Ento, temos que os dados
representam o registro simples de quaisquer fatos, conceitos e entidades que possam
ser descritas e armazenadas.
3.2.2. Informao
Para Awad [AWA03] a informao obtida pela anlise e formatao dos dados
para conferir a eles significado, forma e relevncia. Organizando os dados por um
objetivo que satisfazer a necessidade de quem procura, obtm-se um conjunto de
fatos que constituem a informao. Deve-se entender que a informao trabalhada
em um enfoque diferente daquele conferido aos dados, pois para os dados o enfoque
quantitativo enquanto que para a informao o enfoque qualitativo. Portanto, os dados
s tornam-se informao na medida em que significado e valor so adicionados a eles.
Diversos autores expem suas interpretaes sobre a informao, Freitas e Kladis
(1995) [AWA03], consideram que a informao um recurso fundamental que deve
trabalhado e ajustado ao nvel em que ser utilizado, no exigindo mais detalhe que o
necessrio. Laudon e Laudon (1999) [AWA03] afirmam que a informao um conjunto
de dados que as pessoas agregam de maneira a torn-los teis e significativos. J Stair
(1998) [AWA03] salienta que a informao deve apresentar alguns aspectos
importantes, para que seja de grande valia para os tomadores de deciso:
a) Precisa, no devendo conter erros, representando um significado real;
b) Completa, devendo apresentar todos os fatos importantes e necessrios;
c) Econmica, de baixo custo de produo conforme o valor que agrega;
d) Flexvel, sendo utilizada para diversas finalidades;
e) Confivel, devendo ser de fonte confivel, dependendo diretamente da coleta
dos dados;
f) Relevante, devendo ser importante para os tomadores de deciso;
g) Simples, sendo de fcil entendimento;
27


h) Em tempo, devendo estar disponvel no momento adequado;
i) Verificvel, devendo existir meios de checar a sua veracidade.

Atravs de todas estas vises, e pela prpria definio dos dados e da informao,
entende-se que a informao caracterizada como o passo intermedirio entre o
conhecimento, gerado a partir dela, e os dados brutos.

3.2.3. Conhecimento
Chegando forma mais complexa de representao sobre a compreenso de um
determinado assunto, se passa da informao para o conhecimento. Sendo um assunto
to importante, encontra-se a definio de conhecimento no s em dicionrios, mas
em vrios artigos e itens da literatura de Administrao e Informtica.
Segundo Awad [AWA03] o conhecimento o entendimento humano sobre uma
rea de interesse, que adquirido atravs de estudo e experimentao. Nonaka
[NON94], Firestone [FIR02] e Irma [FER04] consideram que o conhecimento em uma
rea representa as crenas justificadas sobre relaes entre conceitos naquela rea em
particular. Estas reas de conhecimento so chamadas de domnios, onde os domnios
renem uma comunidade, dando a ela uma identidade, definindo os pontos chave que
os indivduos precisam trabalhar.
Portanto, um conhecimento de um determinado domnio relevante a certo grupo
de pessoas, que se define por comunidade de prtica. A comunidade de prtica
envolve as pessoas que interagem e desenvolvem relacionamentos que ajudam a
resolver problemas e partilhar conhecimento. Lembrando que prtica o corpo de
conhecimento, mtodos, ferramentas, casos, fatos, documentos que os membros
dividem e desenvolvem juntos. Uma comunidade trs consigo praticantes que
acumulam conhecimento prtico no seu domnio aumentando sua habilidade de agir
individualmente e coletivamente.
Neste ponto, pode-se fazer a referncia direta de que a comunidade de prtica
representa pessoas envolvidas na utilizao de um processo e que ao longo do tempo
essa comunidade absorve o conhecimento, institucionalizando-o no grupo e assim
dominando melhor os mtodos, ferramentas, etc.
28


Podemos ver que nas publicaes cientficas encontram-se diferentes vises para
o conhecimento:
a) Conhecimento o entendimento, viso ou familiaridade adquirida com o
estudo, investigao, observao, ou experincia ao longo do tempo.
Tambm conceituado como crena pessoal justificada que aumenta a
capacidade de um indivduo tomar uma ao, conforme Ward [WAR04].
b) Conhecimento a informao em um contexto.
c) Conhecimento o entendimento baseado em experincia.
d) Conhecimento traduz-se na experincia ou informao que pode ser
comunicada ou compartilhada.
e) Conhecimento , enquanto constitudo de dados e informao, um
entendimento maior de uma situao, relacionamentos, fenmeno causal,
e as teorias e regras que permeiam um domnio ou problema.
f) Conhecimento um conjunto de unidades mentais de todos os tipos que
nos propiciam entendimento e interpretao dos fatos.
g) O conhecimento composto e baseado fortemente em atos potenciais e
nos sinais que o referenciam [FIR02].
h) Conhecimento significa ter capacidade para ao efetiva [FIR02]

Tendo-se tantos conceitos diferentes, importante entender que cada
organizao, grupo ou equipe deve estabelecer seu prprio entendimento sobre a
definio de conhecimento e comunic-lo s comunidades de prtica, s assim
possvel trabalhar com clareza sobre ele. Ainda, para aumentar a clareza sobre o
conhecimento sendo tratado, deve-se separar o conhecimento de forma organizada,
tipificando-o conforme segue no item 4.1.

3.2.4. Tipos de Conhecimento
Para melhor compreender e classificar o conhecimento de forma a poder identificar
fontes geradoras de um determinado conhecimento, formas de captur-lo e trat-lo, os
autores identificam na literatura trs classificaes, dividindo o conhecimento em tcito
ou explcito, declarativo ou procedural e geral ou especfico.
29


3.2.4.1. Tcito ou Explcito
Nonaka e Takeuchi surgiram com uma importante classificao de conhecimento
que o separa em tcito e explcito e muito utilizada atualmente [NON94]. Segundo
Awad [AWA03], o conhecimento explcito se refere ao conhecimento que expresso
em nmeros ou palavras, podendo ser distribudo formalmente e sistematicamente na
forma de dados, especificaes, manuais, desenhos, udio e vdeo, programas de
computador e patentes.
Para tratar o conhecimento explcito, Hildreth [HIL99] afirma que foram adotadas
ferramentas tais como os sistemas especialistas e a codificao do conhecimento em
procedimentos de suporte a operaes. Mas nem sempre todas as operaes podem
ser documentadas e quando se entra em situaes especiais que necessitam de
solues alternativas ento temos o que chamado de criao do conhecimento tcito.
Em contraposio ao conhecimento explcito, temos o conhecimento tcito que
inclui previses, intuies e palpites e complementa o conhecimento explcito. O
conhecimento tcito difcil de ser expresso e formalizado, portanto difcil de ser
compartilhado, isto porque o conhecimento tcito subjetivo e baseado em
experincias e atividades individuais [AWA03]. Hildreth [HIL99] expe que o
conhecimento tcito menos tangvel, onde uma estratgia rgida no se faz efetiva.
Este tipo de conhecimento menos quantificvel e no pode ser capturado, codificado
e armazenado to facilmente.
Focando neste problema, Futami [FUT06] cita Nonaka e Takeuchi (1997) que
fazem uma crtica construtiva s empresas ocidentais considerando que elas possuem
uma viso direta e objetiva e que assim deixam em segundo plano o conhecimento
tcito, baseando-se mais no conhecimento explcito. No entanto o conhecimento tcito
uma fonte importante de competitividade e o principal fator que gerou a
competitividade e a inovao das empresas japonesas na dcada de 1980. Nonaka e
Takeuchi (1997) dizem que os tericos ocidentais do gerenciamento no tm viso da
organizao como entidade que cria novos conhecimentos.
Para administrar o conhecimento tcito preciso entender os processos que o
envolvem em uma organizao, necessitando da participao, colaborao e
experincia das pessoas sobre determinadas atividades em comunidades de prtica
30


conforme sugerem Lave & Wenger (1991) [FUT06]. O conhecimento tcito propagado
pelas prprias pessoas que encontram problemas e depois compartilham seus
sucessos e insucessos no ambiente de trabalho e em atividades dirias onde as
comunidades de prtica surgem como facilitadoras para que isto ocorra.
As comunidades de prtica envolvidas no conhecimento tcito participam de trs
etapas que so a Coleta de informao, a Construo do conhecimento sobre as
prticas especficas da comunidade e a Obteno do Conhecimento construdo a partir
das competncias dos membros de uma comunidade.
Atravs destas definies, podemos diferenciar claramente o conhecimento tcito
do explcito, pois o explcito formal e faz parte de um processo da organizao, j o
tcito informal e torna-se parte da comunidade atravs do consenso adotado em um
determinado grupo. Embora sejam dois tipos distintos de conhecimento, eles sofrem
mudanas que caracterizam o ciclo de transformao de conhecimento tcito e
explicito, que representado pelo processo de converso do conhecimento, definido
pela espiral de Nonaka e Takeuchi (1995) pela figura 2:

Figura 2 Espiral de transformao de Conhecimento

A transio entre estes dois tipos de conhecimento dada pelo ciclo mostrado na
figura 3, onde a converso de conhecimento tcito para conhecimento explcito se d
pela externalizao; e do explcito para o tcito pela internalizao. Ainda pode-se gerar
novo conhecimento explcito a partir dele mesmo pela combinao de conhecimentos
explcitos, e tambm pode ser gerado novo conhecimento tcito a partir de
conhecimento tcito existente pela realizao da socializao.
31



Figura 3 Processos de transformao do conhecimento

3.2.4.2. Declarativo ou Procedural
Irma [FER04] define que o conhecimento declarativo tem seu foco em crenas
sobre relacionamentos entre variveis e pode ser definido na forma de proposies,
correlaes ou frmulas relacionando conceitos ligados a variveis. J o conhecimento
procedural o contrrio, foca em crenas ligadas a seqncias de passos ou aes
para resultados desejados.
3.2.4.3. Geral ou Especfico
O conhecimento geral aquele que um grande nmero de pessoas domina e que
pode ser transferido facilmente enquanto que o especfico poucos dominam e muito
caro de ser transferido. O conhecimento especfico pode ser tcnico ou contextual.
Tem-se que o conhecimento especfico tcnico um conhecimento profundo sobre uma
rea especfica e inclui o conhecimento sobre ferramentas e tcnicas que podem ser
usadas para a resoluo de problemas. Este conhecimento tcnico normalmente
adquirido como parte de um treinamento formal e consolidado atravs da experincia.
J o conhecimento especfico contextual se refere ao conhecimento existente em
determinados momentos e lugares no qual o trabalho realizado. Por depender de
contexto, este conhecimento pertence organizao e a unidade desta onde as tarefas
so realizadas. Ainda, o conhecimento contextual no pode ser adquirido por
treinamento formal, mas sim no seu contexto especfico onde ser utilizado e aplicado,
ou seja, numa determinada equipe ou grupo. Para realizar a disseminao e
treinamento no conhecimento especfico uma tcnica importante a migrao de reas,
32


para que se adquiram conhecimentos relativos a cada rea em questo. Esta tcnica
de migrao muito utilizada atualmente na educao de trainees das organizaes
[FER04].

3.3. Gesto do Conhecimento
Tendo entendido quais so os itens base que formam o conhecimento, atravs da
conceituao de dados, informao e conhecimento em si, com suas diferentes
classificaes, ento parte-se para um contexto mais amplo, abordando a Gesto do
Conhecimento. Lembrando ainda que o conhecimento possibilita empresa uma
atualizao de seus processos de modo que esta se adapte as novas exigncias do
mercado, garantindo uma vantagem competitiva sobre as demais. Um exemplo disso
a agilidade com que os funcionrios podem executar suas atividades dentro da
empresa, transformando rotinas repetitivas em atividades rpidas e de qualidade. A
empresa, ento, toma por objetivo a gerncia de todo conhecimento advindo de seus
funcionrios, com o intuito de agregar cada vez mais valor aos seus produtos e
servios.
A Gesto Conhecimento se d quando a empresa consegue acumular, produzir,
manter e alavancar suas bases de conhecimento de forma rpida, gil e eficaz.
Segundo Laudon e Laudon (1999) [AWA03], o gerenciamento do conhecimento pode
ser feito de quatro maneiras, pela distribuio, criao, compartilhamento e captura do
conhecimento.
Por meio de mudanas que surgiram no mercado, explica-se a necessidade que a
empresa possui de evoluir de uma perspectiva de Gesto da Informao, para um
conceito mais amplo de Gesto do Conhecimento que trata das relaes de como as
pessoas desempenham suas atividades baseadas no conhecimento. Ento temos a
definio dessa Gesto que segundo Awad [AWA03] uma rea multidisciplinar que
abrange pessoas, tecnologia e processos envolvidos em negcios, economia,
psicologia e gerncia de informao.
A Gesto do Conhecimento trata de descobrir as fontes de informaes
importantes para o escopo de trabalho e transform-las em conhecimento atravs da
captura, aplicao de uma linguagem comum, categorizao, transferncia e
33


compartilhamento delas. Conceito corroborado por Irma [FER04] que afirma que GC
uma importante disciplina que promove a criao, compartilhamento e sinergia do
conhecimento em uma organizao.
Segundo Terra [TRU05], a Gesto do Conhecimento um processo sistmico e
especfico que tem por objetivo adquirir, organizar e compartilhar o conhecimento dos
funcionrios da empresa, para que os mesmos possam utiliz-lo quando haja
necessidade. Terra e Kruglianskas citam que a Gesto do Conhecimento o conjunto
de processos que administram a criao, a disseminao e a utilizao do
conhecimento.
Destaca-se que a GC consiste em atividades focadas na obteno do
conhecimento organizacional para que a empresa alcance seus objetivos. Nela, a
empresa tem como objetivo que seus funcionrios utilizem o conhecimento para
aprender, ensinar, resolver problemas e dar apoio na tomada de decises. Ento a GC
destaca-se como um mecanismo efetivo para aumentar o entendimento e ordenao de
atividades de uma empresa, para que esta possa ter competitividade e ento atingir o
sucesso nos seus processos de trabalho e posteriormente, no mercado.
muito importante que se possam medir as conseqncias advindas das
transformaes do mercado em relao Gesto do Conhecimento, pois assim, a
empresa pode analisar e prever situaes futuras, se antecipando aos fatos e gerando
vantagem em relao s outras empresas. Pois as empresas que querem ter um
diferencial competitivo em relao aos seus concorrentes precisam de uma viso
voltada para a Gesto do Conhecimento, tendo a empresa como uma comunidade
humana, e com um enorme capital intelectual que deve ser aproveitado e formalizado.
Para Davenport e Prusak (1998) [FER04], a Gesto do Conhecimento tem uma
importncia crescente para as empresas, e as tecnologias de informao tm um papel
fundamental no seu suporte.
3.3.1. Aplicaes da Gesto do Conhecimento
A Tecnologia da Informao (TI) uma rea que prov uma srie de ferramentas
para a manipulao de dados e informaes, ainda, uma rea de Conhecimento vasta
e que pode beneficiar-se da aplicao da Gesto do Conhecimento. Aqui so
34


mostrados os pontos de insero da Gesto do Conhecimento na Tecnologia da
Informao.
3.3.1.1. TI e Gesto do Conhecimento
O uso integrado de ferramentas de TI, suas potencialidades e facilidades provem
acelerao de resultados na resoluo de problemas na Gesto do Conhecimento. E
embora a TI seja fundamental para o agrupamento do conhecimento explcito, hoje
ainda no est sendo aplicada com efetividade no que diz respeito ao conhecimento
tcito.
Mesmo assim, ao facilitar o registro do conhecimento e o acesso a ele atravs de
redes e interatividade com os contedos armazenados, a TI colabora fortemente nos
processos de externalizao e internalizao. Portanto a TI torna-se importante a partir
do momento que o usurio percebe os benefcios de sua aplicao e a adota como boa
prtica, criando sistemas a serem utilizados efetivamente como facilitadores.
Estes sistemas de TI criados para suporte a GC podem ser separados em duas
abordagens distintas, com tecnologias centradas no indivduo e as centradas na
mquina. De um lado temos as tecnologias centradas no indivduo que geram sistemas
interativos e ferramentas de groupware, facilitando a internalizao do conhecimento
explcito pelo compartilhamento de interesses e experincias pessoais, provendo
acesso dinmico ao conhecimento explcito. Por outro lado, as tecnologias centradas na
mquina, atuam na externalizao do conhecimento tcito atravs do registro deste
conhecimento.
As tecnologias centradas na mquina ainda atuam na combinao de
conhecimento explcito, pelo uso de bases de dados, sistemas especialistas,
ferramentas de suporte a deciso e agentes de busca. No entanto TI no funciona por
si s, preciso definir processos, papis, responsabilidades para dar suportes a esses
sistemas de ERP e intranets corporativas.
3.3.1.2. Engenharia de Software e Gesto do Conhecimento
Ward [WAR04] afirma que o conhecimento na rea de engenharia de software
dinmico e envolve tecnologia, cultura organizacional e necessidade de mudana das
prticas de desenvolvimento de software de uma organizao. Na engenharia de
35


software, o conhecimento sobre os prprios processos deve ser base para a criao de
novo conhecimento envolvendo as pessoas e disseminando-o, pois documentos
escritos so menos procurados quando um problema surge. Revises e discusses em
projetos possibilitam que conhecimento tcito e explcito seja administrado
efetivamente.
Na verdade a GC no para substituir, mas sim para complementar as tcnicas
existentes de engenharia de software. O reuso de conhecimento muito evidente nos
projetos de software com a utilizao de componentes reutilizveis, onde o
conhecimento propagado atravs de aplicaes e frameworks.
3.3.1.3. Fatores de Influncia da Gesto do Conhecimento
Tendo entendido os cenrios de aplicao da gesto do conhecimento inseridas
na Informtica, enfocando nos contextos de Tecnologia da Informao e Engenharia de
Software, parte-se para identificar e explicar quais so as variveis, ou seja, os fatores
que influenciam diretamente a aplicao da gesto do conhecimento a fim de entender
quais aspectos externos podem influir no fracasso ou sucesso de uma estratgia de
Gesto do Conhecimento a ser aplicada em uma organizao. Segundo Malhotra
[MAL00] estes fatores so a mudana de gerncia, os fatores culturais e a existncia de
premissas incorretas ou mitos.
A mudana de gerncia uma grande dificuldade em um vasto nmero de
empresas. Realizar a troca de pessoas chave significa alterar o modo de gerncia pr-
estabelecido. Sabendo que o mtodo tradicional para distribuir o conhecimento o de
se definir um grupo de informaes que precisam ser conhecidas e gerar mecanismos
ou processos de trabalho nos quais uma pessoa entra em contato com outra buscando
conhecimento para que seja feita a troca de idias e experincias em um ciclo fechado
somente entre essas duas pessoas. Por isso a importncia de haver um nmero de
pessoas chave suficiente para garantir que a troca de informao e o fluxo de
conhecimento no sejam interrompidos.
Os fatores culturais esto diretamente relacionados com o compartilhamento do
conhecimento, pois compartilhar o conhecimento e us-lo varia de cultura para cultura e
um desafio obter modelos e padres de como iniciar e trabalhar a gesto do
conhecimento independente da localizao e contexto. Existem cinco grandes
36


dimenses culturais, onde a distncia representa questes relacionadas percepo
sobre comunicao e confiana entre equipes. A incerteza uma dimenso que aborda
a tolerncia sobre ambigidades e necessidade de regras formais que existe em
determinados ambientes, onde uns so mais rgidos do que outros e aceitam mais ou
menos incertezas.
Outra dimenso o individualismo onde se considera o quanto uma nica pessoa
coloca seus interesses a frente dos interesses do grupo ao qual pertence. O tempo
uma dimenso usada na definio da cultura de serem realizados planos de longo ou
de curto prazo. Sociedades ocidentais tendem a ser imediatistas enquanto que as
sociedades orientais tm uma viso de longo prazo. Em culturas altamente focadas,
tipicamente ocidentais, o conhecimento controlado e no deixado fluir livremente, o
que pode levar mais tempo se no houver incentivo para as pessoas.
Ainda h a questo do gnero, onde a masculinidade est relacionada com a idia
de que metas e assertividades se opem aos objetivos pessoais. Em locais de cultura
mais masculina, espera-se que as mulheres fiquem em casa e faam tarefas
domsticas. Embora muitas organizaes possuam repositrios centralizados para
hospedagem e distribuio, as taxas de contribuio so abaixo do esperado, onde
uma das razes chave a dificuldade de quebrar hbitos tradicionais e culturais. O que
pior em ambientes distribudos em virtude de posturas diferentes em diferentes
pases, estados, unidades de uma mesma organizao e suas equipes. Para diminuir
este problema busca-se encorajar e incentivar que o conhecimento seja compartilhado
para que no se tenha tanto impacto da diferena de linguagem, lugar, comportamento
e contexto.
Por fim, temos o fator sobre a existncia de premissas incorretas e Mitos, sendo
importante a anlise de sentenas que no so mais vlidas na realidade atual, tal
como: GC pode entregar a informao correta para a pessoa correta no tempo em que
necessria. Este conceito desatualizado, pois os modelos de negcio antigos
baseiam-se no fato de que as mudanas so incrementais e h um mercado estvel no
qual os executivos conseguem prever as mudanas.
No entanto os novos modelos de negcio pregam que a mudana estrutural e
fundamental e no apenas incremental, portanto aplica-se o comportamento mais
37


flexvel possvel para suportar as mudanas e faz-las rapidamente. Por isso muitas
vezes no possvel entregar a informao precisamente.
Outra premissa incorreta a de que GC pode distribuir e guardar inteligncia e
experincias humanas. Pode-se guardar muita informao em banco de dados e
sistemas de armazenamento, mas impossvel armazenar os ricos modelos mentais
que contextualizam e interpretam os dados. Sabendo que o conhecimento
dependente de contexto, registrar explicitamente a interpretao de uma situao por
uma pessoa em um determinado instante de tempo no significa armazenar o seu
conhecimento. Ainda sabe-se que cada pessoa interpreta o que lhe passado de forma
diferente bem como busca apoio de pessoas mais experientes ou especialistas.
3.3.1.4. Fatores de Insucesso nas Organizaes
Com base nos fatores de influncia sobre a Gesto do Conhecimento, ento se
tem a base para discutir os fatores de insucesso da Gesto do Conhecimento nas
Organizaes. Salientam-se estes fatores como pontos de ateno ao se adotar uma
abordagem voltada a Gesto do Conhecimento.
Segundo a publicao Harvard Management [HMU99], h vrios grandes
problemas que so encontrados nas organizaes. Um deles o de Comear grandes
iniciativas e projetos, pois h grande complexidade das informaes envolvidas e
problemas de implantao na alocao de recursos (humanos ou no) e que aumentam
a resistncia dos colaboradores em participar de iniciativas complicadas e mal
elaboradas. Portanto mais prtica a adoo de uma abordagem simples com projetos-
piloto significativos. Lembrando que como qualquer outro projeto em uma organizao
preciso haver Gesto de Projeto e o escopo e expectativas devem ser bem definidos
em relao iniciativa proposta para que se atinjam os resultados esperados.
Outro problema so iniciativas baseadas apenas em tecnologia. Apenas utilizar
solues tecnolgicas no garante o funcionamento de um programa de GC, pois
apenas uma base de dados no ir trazer o conhecimento sem a ajuda de pessoas.
Alm do mais muita informao e dados sem organizao chegam a ser piores do que
nenhuma informao. importante disponibilizar a informao onde as pessoas esto
acostumadas a procurar e em mais de um ponto, para que os dados sejam encontrados
regularmente e no somente quando procurados.
38


No modelar o comportamento pode criar dificuldades, se no forem mudados os
modelos de gerncia adotados pelos prprios gestores no h como incorporar a
gerncia do conhecimento nos processos da empresa. Logo, os gestores precisam
incentivar e questionar as pessoas sobre suas participaes, incentivando a mudana
de comportamento, modelando-o para atingir os objetivos da organizao.
Ignorar o poder de recompensas pode ser problemtico, as pessoas quando
recompensadas por compartilhar conhecimento repetem o compartilhamento com mais
freqncia. Uma tcnica incorporar a gesto em avaliaes formais de desempenho e
em sistemas de incentivo e compensao. Outra forma associar descobertas e idias
aos seus criados, tornando seus nomes difundidos e bem conceituados na empresa.
Finalmente, vale ressaltar que a Gesto do Conhecimento inserida no contexto
de Sistemas de Informao e Tecnologia da Informao est sujeita as dificuldades que
temos hoje nas empresas que atuam nestas reas. Ento importante sempre lembrar
de planejamento, qualidade, processo e os riscos que estes fatores envolvem, bem
como aplic-los sob a tica da Gesto do Conhecimento.
3.3.1.5. Estratgias para Gesto do Conhecimento em Ambientes Distribudos
[EVA03] cita Bartlett e Ghoshal (1989) enumerando quatro estratgias para
competio em empresas que atuam com ambientes distribudos. A primeira a
Multinacional que visa dar independncia quase total s filiais. Atravs da
independncia, as filiais podem responder rapidamente s mudanas no mercado local.
Na estratgia Global as aes das subsidirias so altamente controladas pela matriz
onde o enfoque atingir eficincia global atravs de economia de escala com produtos
e servios padronizados.
Ainda h a estratgia Internacional e a Transnacional, onde a Internacional explora
o conhecimento da matriz pela difuso e adaptao, rpida aplicao da inovao o
objetivo principal. E na Transnacional h uma interdependncia da matriz e suas filiais,
no entanto deve ser dinmica com esforos coordenados garantindo flexibilidade local e
explorando os benefcios da eficincia e integrao globais e buscando divulgar a
inovao mundialmente.
Outro estudo que o de Ives e Jarvenpaa (1991) [EVA03] aponta trs estratgias.
Estratgia de Operaes globais de TI independentes aquela na qual as subsidirias
39


desenvolvem seus prprios sistemas durante grande parte do tempo fazendo com que
sejam raros os desenvolvimentos colaborativos. A segunda estratgia a de TI global
orientada pela matriz onde as solues de TI mundiais so impostas. E na ltima
estratgia de Fortes ligaes entre matriz e filial se usa a colaborao e assistncia
mtua.
Ainda no estudo de Evaristo encontra-se uma estratgia levantada atravs da
pesquisa de Ives e Jarvenpaa consiste em e ter a viso e as iniciativas baseadas nos
escritrios regionais, ou seja, localmente. O fato que esses escritrios necessitam de
colaborao regional para trocar experincias e funcionar com eficincia e eficcia,
ento ao invs de adotar uma estratgia da corporao foi adotada uma estratgia
local para a Gesto do Conhecimento.
Cada filial da regio livre para executar aes da maneira mais propcia desde
que atinja as metas e respeite as polticas estabelecidas para aquela regio. Aqui se
tm o benefcio de menor burocracia e menos tempo entre pensamento e prtica. Na
outra ponta temos que empreendimentos corporativos globais levam anos para serem
executados devido a grande quantidade de atores, redes e relaes a serem
gerenciadas.
Por outro lado a estratgia regional leva menos tempo devido a proximidade dos
escritrios locais e afinidades de contexto. Um contraponto nesta estratgia a
dificuldade de compartilhar o conhecimento entre regies, visto que cada regio
emprega suas prprias ferramentas e iniciativas de captura e armazenamento de troca
de conhecimento entre regies [EVA03].
3.4. Ontologias
Com a compreenso sobre os conceitos envolvidos na Gesto do Conhecimento,
quais os fatores relevantes para sua aplicao e tendo um enfoque geral sobre sua
utilizao nas reas de Informtica e em Ambientes Distribudos ento parte-se para a
formalizao do conhecimento em si. Logo, nesta seo apresentam-se os conceitos
fundamentais das Ontologias, quais suas aplicaes mais atuais e trabalhos na rea.
40


3.4.1. Definio
No mbito da Computao e da Inteligncia Artificial, as ontologias representam
um artefato de engenharia que composto de um vocabulrio especfico de descrio,
de uma realidade e de um conjunto de premissas sobre o significado pretendido para as
palavras deste vocabulrio. Tambm se entende que as ontologias definem as regras
que regulam a combinao entre os termos e as suas relaes. Embora existam muitas
definies sobre ontologias, iremos adotar a definio simples e de alto nvel de
Grubber [GRU03] que se aplica perfeitamente no contexto da Cincia da Computao.
Grubber afirma que uma ontologia uma especificao explcita de uma
conceituao. Uma conceituao uma viso abstrata e simplificada do mundo que se
deseja representar, sendo composta por uma coleo de objetos, conceitos, o
relacionamento entre estes conceitos e outras entidades que se assume existirem em
um domnio [GRU03].
Na literatura ainda encontra-se definies complementares como a de Guarino
[GUA96], que prope a insero do carter intencional de interpretao humano s
ontologias. Assim temos que uma definio intencional especifica uma lista de
caractersticas de um conceito e que a definio extencional a enumerao de
aspectos de todas as espcies que so do mesmo nvel de abstrao.
Seja especfica ou genrica, intencional ou extencional cada ontologia agrega uma
parte de domnio de conhecimento para uma determinada rea em particular e uma das
principais motivaes para sua construo a possibilidade de compartilhar e reutilizar
conhecimento. Mas para que seja construda uma ontologia bem formada necessria
a existncia dos seguintes componentes:
Classes de conceitos organizadas de uma forma estruturada e formal,
indicando hierarquias, generalizaes e especializaes em um determinado domnio,
caracterizando um formato taxonmico.
Relaes: aps classificados devidamente, os conceitos devem ser co-
relacionados, formalizando as possveis interaes entre eles em um domnio.
Indicando propriedades semelhantes, dependncias e associaes.
Axiomas: so premissas consideradas evidentes e verdadeiras
41


Instncias: so os dados em si, que compem as ontologias. So as
representaes reais dos conceitos.
O papel das ontologias ento explicitar, formalizar e fornecer um padro de
compartilhamento de informao, podendo representar um modelo comum que permita
a troca de informao entre aplicaes e agentes de software de um modo significativo.
Portanto ao classificarmos as informaes contidas em uma ontologia devemos levar
em conta que essa informao possa ser automatizada e computvel, e no
classificada da maneira que os seres humanos organizam o conhecimento.
Em ambientes computacionais preciso manter as ontologias [MAE00], e h duas
tcnicas que so muito utilizadas para dar manuteno em uma base de ontologias.
Pode-se trabalhar com a reduo, isto , retirar os elementos da ontologia que no so
relevantes para o domnio da aplicao que se est modelando. Outra tcnica a
evoluo da ontologia, isto , aprender sobre o conceito de palavras no
desconhecidas, reconhecendo assim os conceitos de maior relevncia (centrais) para a
ontologia.
A Reduo da Ontologia necessria para definies de ontologias genricas
sobre um determinado domnio, especificando quais os conceitos e relacionamentos
devem necessariamente pertencer ontologia. Tipicamente, pode-se utilizar a
freqncia de termos como um critrio de classificao. Entidades que so
referenciadas frequentemente so supostamente conceitos relevantes para o modelo.
Porm nem sempre isso verdade, e a extrao destes termos necessita de um apoio
do usurio para sua validao.
Para determinar a relevncia das entidades da ontologia, as mesmas so
comparadas com as freqncias obtidas a partir de uma anlise prvia. possvel que
o usurio escolha diversas medidas de relevncia para freqncia computacional.
Todos os conceitos existentes e suas relaes, que so mais freqentes permanecem
na ontologia.
Na Evoluo da Ontologia, tem-se que um importante aspecto da manuteno
de ontologias sua extenso incremental com conceitos associados a entradas lxicas.
A abordagem de evoluo baseada na premissa que palavras desconhecidas podem
compartilhar uma conceituao semelhante de palavras conhecidas. necessrio um
42


apoio humano para realizar estas identificaes e assim complementar a Ontologia e
agregar mais complexidade e conhecimento.
3.4.2. Ontologias Aplicadas na Construo de Sistemas de Informao
Novas ferramentas para a construo de Sistemas de Informao tm sido criadas
com a utilizao de ontologias. Com estas ferramentas possvel trabalhar em nvel de
aplicao, de persistncia ou de interface sempre relacionando conceitos relativos a um
sistema, atravs de representao de dados, cones e detalhes de interface ou ainda
funcionalidades e regras de negcio [BAE05].
Tambm se podem usar ontologias pr-definidas em tempo de desenvolvimento
ou em tempo de execuo de um Sistema de informao. Utiliz-las para
desenvolvimento ou em reengenharia pode levar casos de uso especficos e
adaptaes ao contexto do projeto. Mesmo assim as ontologias devem permanecer em
um repositrio contendo todas as ontologias aplicadas ao domnio geral e s tarefas
especficas em um dado momento.
Uma ontologia utilizada correta e eficientemente pode ser transposta diretamente
para um componente de um Sistema de informao, facilitando o trabalho de anlise e
auto-validao da ontologia em questo. Assim uma ontologia pode guiar a criao de
outras ontologias mais especficas, chamadas de ontologias de aplicao,
incrementando as ontologias existentes em um projeto ou ainda representando um
componente de software em sua totalidade.
J utilizar uma ontologia em tempo de desenvolvimento possibilita que sejam
aumentados os ndices de reutilizao em comparao ao reuso aplicado na
Engenharia de Software. Em tempo de desenvolvimento o desenvolvedor que
capaz de reusar e compartilhar conhecimento de domnio, focando-se mais sobre o
conhecimento e arquitetura do que em detalhes de desenvolvimento,
independentemente da plataforma de software a ser adotada. No entanto precisa-se
aumentar a produo de ontologias reutilizveis para que se possam realizar mais
combinaes aumentando a rede de conhecimento em quantidade e em qualidade e
assim possibilitando maior reaproveitamento do que armazenado.
Algumas ontologias de aplicao podem ser criadas para diferentes tipos de
componentes de software, sejam eles ligados visualizao e comunicao externa
43


(interfaces), ligados persistncia de dados ou ainda ligados a regras de negcio em si
(programas) [BAE05]:
Ontologias para bancos de dados: uma ontologia pode definir um modelo de
banco de dados atravs do processamento de requisitos em linguagem natural e da
transformao destes requisitos em modelos conceituais. Ento estes modelos
definidos podem ser aplicados a diferentes arquiteturas (ex: Orientada a Objetos,
Relacional) e tipos e bancos de dados (ex: Oracle, SQL Server). Ainda atravs da
combinao de diferentes modelos de ontologias para banco de dados pode-se
estabelecer uma base para a construo de um repositrio direcionado ao
datawharehousing, atravs da combinao de diferentes domnios de informao
dentro de uma empresa.
Ontologias aplicadas interface: sabendo que as ontologias armazenam
informao semntica sobre o relacionamento de entidades e classes de um domnio,
pode-se utiliz-las para validar regras de entrada de dados em um formulrio, por
exemplo. Mais explicitamente ainda, uma ontologia em si pode ser navegada e
manipulada visualmente para a construo de consultas e compreenso do vocabulrio
do sistema que utiliza neste caso o usurio est consciente de sua utilizao e ela no
atua apenas internamente como um mecanismo de trabalho. Assim a ontologia pode
auxiliar na construo de outras ontologias mais especficas e, dependendo de sua
complexidade, tambm pode ajudar na retirada e diminuio de ambigidades entre
termos e relaes.
Ontologia como programa: Programas contm muito conhecimento sobre um
sistema, especialmente no que se refere requisitos e regras de negcio. Num
programa as regras so estticas e so implementadas na forma e classes,
declaraes ou mtodos complexos que nem sempre so claros o suficiente para
compreenso de uma pessoa nova ao domnio. Aplicando-se ontologias ao
desenvolvimento de software possvel automatizar a gerao deste cdigo esttico e
suas regras aumentando a transparncia, integrao e manutenibilidade do sistema.
Conclui-se que a obteno de ontologias aplicadas se d pela avaliao de
ontologias de alto nvel e ontologias de domnio e tambm pela transformao destas
em ontologias de aplicao. Um uso importante de ontologias o suporte a
44


comunicao de agentes, onde esta comunicao se d pela troca de mensagens
contendo expresses direcionadas para uma ontologia a qual os agentes podem
acessar.
3.4.3. Aplicao de Ontologias na WEB
Ciente do panorama de utilizao de Ontologias em Sistemas de Informao
busca-se entender melhor a sua aplicao e representao da World Wide Web, pois
esta representa um excelente mecanismo para compartilhamento de conhecimento,
dada a sua abrangncia de uso e facilidade de acesso ao que se procura e ao advento
da WEB Semntica.
Ainda, na ltima dcada foram propostas vrias linguagens para representao de
ontologias, ou seja, representao do conhecimento. Atualmente algumas dessas
linguagens vm sendo utilizadas na construo de ontologias para a WEB Semntica.
Temos o RDF [W3C05] que tem o papel de fornecer um modelo formal [BRE05] de
dados e sintaxe para codificar metadados que possam ser processados por mquinas,
exemplificado na figura 4. No entanto o RDF no oferece conectivos lgicos para
descrever negao, disjuno e conjuno.
















Figura 4 Grafo baseado em RDF
J o RDF-Schema [W3C05] oferece primitivas de modelagem que permitem a
construo de hierarquias, classes, propriedades, subclasses e subpropriedades. RDF
e RDF-Schema (RDFS) so as fundaes da WEB Semntica, e como extenso ao
gestor
Felipe
PMP RUP
certificado certificado
Fichas
Tcnicas
Certificado
usa
gera
nome
Projeto1
nome_projeto
45


RDFS surgiu a OWL. A OWL [W3C05] tem como objetivo representar ontologias e foi
embasada nos princpios da linguagem DAML+OIL. A seguir descreve-se cada uma
destas linguagens em maior detalhe.
3.5. Dicionrio de Dados
Segundo [WIK05], tem-se que um dicionrio de dados uma coleo de
metadados que contm definies e representaes de elementos de dados. Assim
representam uma alternativa s ontologias na formalizao do conhecimento
Especificamente em Sistemas de Gerncia de Bancos de Dados, dicionrios de
dados representam grupos de tabelas e vises que podem ser unicamente consultadas
e que contm :
Definio de elementos de dados
Perfis de usurios, papis e privilgios.
Descrio de objetos
Integridade de restries
Stored procedures e triggers
Estrutura geral da base de dados
Informao de verificao
Alocaes de espao

Um dicionrio de dados bem preparado prov consistncia entre itens de dados
que esto relacionados onde pode-se ter, por exemplo, a validao de nmeros de
telefone; atravs da definio de um formato para 'nmero de telefone' onde
"(XX)9999-9999" dever ser obedecido em as referncias a este tipo de informao.
Ao construir um dicionrio de dados de dimenso organizacional, se deve buscar a
padronizao de definies semnticas a serem adotadas na empresa toda. Assim, um
dicionrio de dados incluir definies semnticas e de representao para elementos de
dados, tendo os componentes semnticos com foco na criao precisa do significado
dos elementos de dados, e as definies de representao indicando como os
elementos de dados so armazenados em uma estrutura computacional e tipada.
46


Os dicionrios de dados so mais completos que glossrios (termos e definies)
pois normalmente possuem uma ou mais representaes de estruturao de dados. Os
dicionrios de dados so gerados, normalmente, separados do Modelo de Dados visto
que estes ltimos costumam incluir complexos relacionamentos entre elementos de
dados.
Ento, com a definio formal do conhecimento no contexto dos ambientes
computacionais, cria-se a base para iniciar o estudo de uma srie de trabalhos
relacionados com a formalizao do conhecimento nas organizaes atravs de
ferramentas de software. Este assunto e os trabalhos sobre Engenharia de Requisitos e
Ambientes de Desenvolvimento Distribudo de Software sero vistos no prximo
captulo Trabalhos Relacionados.

47


4. TRABALHOS RELACIONADOS

A identificao e estudo de trabalhos relacionados surgem como passos
posteriores ao entendimento sobre a Gesto do Conhecimento e formas de
representao do conhecimento. Dentre estes trabalhos, o que mais se destacam so o
processo proposto em Um modelo de Processo de Engenharia de Requisitos para
Ambientes de Desenvolvimento Distribudo de Software [LOP04], e ainda os estudos
de Daniela Damian em Studies in Distributed Software Requirements Engeneering
[DAM05] e Facilitation in Distributed Requirements Engeneering [DAM03]. Ambos
alm de serem trabalhos relacionados tambm foram considerados como referncia e
base para este trabalho. Embora o Estudo de Daniela em [DAM05] no esteja
diretamente relacionado, foi considerado neste captulo, pois tambm um trabalho
que busca identificar formas de representao de conhecimento que facilitem o trabalho
de Engenharia de Requisitos em ambientes de DDS, aproximando-se ento dos
objetivos deste trabalho.
4.1. Modelo de Processo de Lopes para DDS
O modelo proposto por Lopes [LOP04] foi obtido atravs da avaliao de
diferentes projetos de desenvolvimento distribudo de software, onde foram
identificados e definidos papis e responsabilidades, atividades e artefatos. Este
modelo prope 4 fases que so a de Definies Iniciais, a de Mapeamento de Contexto,
a de Criao da Especificao e a de Gerenciamento de Requisitos. Alm destas fases
ainda h um grupo especfico para reunir atividades de suporte.
A fase de Definies iniciais visa estabelecer a infra-estrutura necessria ao
processo de engenharia de requisitos em ambientes distribudos. Para isto preciso
escolher o idioma da especificao, o dicionrio a ser utilizado, os meios de
comunicao, os embaixadores (analistas de sistema ou de negcio que faro
comunicao direta com o cliente, representando a equipe de desenvolvimento) e
pontos focais, definir a equipe e responsabilidades e os padres de especificao.
Na segunda fase, ou seja, no Mapeamento de Contexto o objetivo mapear o
contexto da localidade e do negcio onde o software em desenvolvimento ser inserido,
simplificando o entendimento a ser obtido pelas equipes distantes. Nesta fase so
48


conduzidas a criao ou atualizao da base de informaes culturais e de contexto, a
criao ou atualizao da base de conceitos do UdI (Universo de Informaes) e a
obteno de informaes gerais sobre o negcio, atividades estas que so executadas
de forma constante durante o processo.
J para a Criao da Especificao de requisitos, tendo as bases para incio da
especificao de requisitos bem formadas, cria-se ento esta especificao e tambm
so obtidos, evoludos, inspecionados e validados os artefatos de requisitos.
Na fase final de Gerenciamento de Requisitos conduzida a manuteno dos
artefatos de requisitos, assegurando que esto constantemente alinhados com os
objetivos de negcios e atualizados de acordo com as modificaes de ambiente. Neste
modelo de processo encontra-se o alinhamento entre atividades de Engenharia de
Software e de Gesto de Conhecimento a fim de facilitar o processo de Engenharia de
Requisitos em Ambientes de Desenvolvimento Distribudo de Software.
4.2. Pesquisa de Daniela Damian
No prximo trabalho avaliado destaca-se a importncia de diferentes
mecanismos de comunicao a fim de resolver ambigidades. Daniela Damian
[DAM05] fez um experimento que aponta a eficcia de utilizao de vdeo conferncia
em reunies sobre Engenharia de Requisitos em projetos distribudos, especificamente
ao facilitar o trabalho em um ambiente orientado a tarefas.
Equipes que utilizam sistemas que auxiliam a realizao de reunies em
ambientes distribudos, obtm aprovao de requisitos mais eficaz, o que demonstra o
benefcio trazido pelo uso de outros meios de comunicao. A pesquisa aponta uma
tendncia para a construo de um modelo multimdia que ajude a negociao de
requisitos em ambientes de Desenvolvimento Distribudo de Software.
J no trabalho Facilitation in Distributed Requirements Engeneering [DAM03],
Damian explora o trabalhador como facilitador de reunies sobre Engenharia de
Requisitos. Estudando quatro grupos em diferentes configuraes de equipe e de tipos
de comunicao. Foi verificado neste estudo que o uso de facilitadores com equipes
distribudas foi possvel e que diferentes meios de comunicao se mostraram teis,
embora ainda existam problemas com o uso de mecanismos computacionais. Outro
resultado foi que a comunicao face-a-face j no se demonstra mais necessria e
49


que pode ser substituda por outros mecanismos no processo de engenharia de
requisitos, por exemplo, atravs do uso de softwares de colaborao (Netmeeting e
Messenger) e da troca de arquivos de udio e vdeo.
No entanto identificou-se que preciso que o entendimento sobre os requisitos e
seus mecanismos de facilitao seja aprimorado e que sejam construdos modelos
adequados para melhorar a comunicao entre equipes distribudas. As concluses
obtidas foram que regras de interao precisam ser definidas, o propsito das reunies
deve ser claro e no deve haver limitao de comunicao entre membros de uma
mesma equipe em uma mesma localidade.
4.3. Pesquisa de Karin Breitman
Outro trabalho importante o de Karin Breitman [BRE03b], no qual se aponta a
Engenharia de Requisitos como mecanismo para a criao de ontologias baseadas no
Lxico Estendido da Linguagem (LAL), tambm proposto por Breitamn [BRE03a] (figura
5).


Figura 5 Construo de Ontologias baseada no LAL
Para que estas ontologias sejam criadas a partir do LAL foi criada uma
ferramenta que visa minimizar o nmero de intervenes do usurio. Este ferramenta
50


identifica conceitos, propriedades e axiomas de ontologias, diminuindo retrabalho e
facilitando a extrao de conhecimento a partir de textos relacionados a requisitos. No
entanto, necessrio um trabalho prvio na classificao de termos e sinnimos do
LAL em objetos e sujeitos, estados, verbos, noes e impactos, que so mapeados
para classes, axiomas, propriedades e descries de uma ontologia.
4.4. Anlise de Requisitos Baseada em Ontologias
Tambm importante destacar o trabalho Ontology Based Requirements
Analysis: Lightweight Semantic Processing Approach onde proposto um mtodo para
associao entre requisitos de software e ontologias de domnio, ontologias estas que
representam componentes semnticos sobre os requisitos [KAI05].
Este mtodo permite que os Engenheiros de Conhecimento possam analisar
uma especificao de requisitos dando enfoque para a semntica sobre o domnio da
aplicao. No trabalho so mostrados 4 tipos de processamento semntico atravs de
um estudo de caso. Os tipos de processamento incluem a deteco de inconsistncia e
falta de completude em especificaes de requisitos, a medio da qualidade de uma
especificao com relao ao seu significado e por fim a previsibilidade sobre
mudanas nos requisitos baseando-se em anlise semntica sobre um histrico de
mudanas.
Na deteco de inconsistncia e no completude, a inconsistncia validada
pela busca de elementos mutuamente contraditrios que tenham sido mapeados para
um requisito. J para detectar a no completude mapeia-se o documento buscando as
relaes entre conceitos a fim de detectar um conceito que possui uma relao no
completa, ou seja, um conceito que referencia outro conceito que no est definido no
documento em questo, que est sendo analisado. A medio de qualidade de uma
especificao utiliza 4 critrios a serem contabilizados:
Correto: sendo analisada a ontologia de um domnio especfico ento
todos os requisitos devem estar relacionados com elementos desta
ontologia.
Completude: todos os elementos da ontologia devem ser mencionados
no documento de requisitos, para garantir sua completude.
51


Consistncia: se existem relacionamentos entre conceitos que causam
contradio, ento h uma inconsistncia.
No ambigidade: quando um requisito (ou item deste) mapeado para
vrios outros elementos que no so semanticamente relacionados
ento se considera que h uma ambigidade.
E para prever mudanas nos requisitos h dois passos importantes que so a
mudana de padres na ontologia e a avaliao. Coletando padres sobre a mudana
de requisitos constantemente, auxilia-se na previso de mudana nos requisitos no
futuro. Foram encontrados 2 padres no estudo de caso que so a adio de nova
funcionalidade e a melhoria de funcionalidades j existentes. Em ambos os padres o
sistema de ontologias contribui na deteco de mudanas pela avaliao do
relacionamento de necessidade sugerindo a insero de novas funcionalidades e pelo
relacionamento de agregao, onde melhorias podem vir a ser agregadas no futuro.
Tem-se que alguns autores identificaram formas de trabalhar com as ontologias e
gerenci-las de forma independente ao ciclo de projetos, criando um processo
transversal ao processo de desenvolvimento de software em si.
4.5. O Framework Methontology
Um dos processos de trabalho propostos o framework Methontology. Este
framework trata-se de uma proposta de ciclo de vida para o desenvolvimento de
ontologias que visa obteno de consistncia e completude na representao do
conhecimento [FER99]. Neste ciclo de vida as ontologias so obtidas atravs de
transformaes feitas por tradutores baseando-se em representaes intermedirias.
O framework Methontology divide-se em 3 nveis principais [JON05], conforme
demonstrado na figura 6. O nvel de Gerncia envolve as fases de planejamento,
controle e segurana da qualidade, j o nvel Tcnico trata de especificao,
conceituao, formalizao, desenvolvimento e manuteno. Por fim h o nvel de
Suporte que diz respeito aquisio de conhecimento, integrao, avaliao,
documentao e gerncia de configurao.
52



Figura 6 - Processo de desenvolvimento do Framework Methontology
Ento se deve no somente planejar a construo de ontologias, como tambm
acompanhar sua criao e avaliar a sua qualidade durante o seu desenvolvimento,
conforme abordado no nvel de Gerncia. No nvel Tcnico uma ontologia ser
especificada, conceituada, formalizada, desenvolvida e depois entrar em manuteno
na medida do necessrio. J no nvel de Suporte, as atividades ocorrem
freqentemente em paralelo com as atividades do nvel Tcnico, onde o conhecimento
adquirido, avaliado e integrado ao conhecimento sendo trabalhado. Para manter o
controle, deve sempre haver documentao e acompanhamento sobre os artefatos que
envolvem o processo, pois assim podem-se identificar itens de configurao e realizar
baselines das ontologias durante o ciclo de vida proposto.
As mais significativas ontologias construdas com esta metodologia so [JON05]:
Chemicals: contm conhecimento sobre o domnio de elementos qumicos
e estruturas cristalinas. Nesta ontologia baseia-se uma ferramenta de aprendizado
sobre qumica (Chemical Onto-Agent).
Ontologias de poluentes ambientais: representa mtodos de deteco de
poluentes em diferentes meios, seja na gua, solo ou ar. Tambm identifica a
concentrao mxima destes poluentes permitida em diversas legislaes (europia,
espanhola, alem).
Ontologia de referncia: ontologia sobre ontologias que serve de ndice de
busca para outras ontologias. Possui links e descries das ontologias que relaciona.
53


Esta ontologia gerou a construo da ferramenta Onto-Agent, que busca novas
ontologias para o corpo de conhecimento, sempre obedecendo a critrios pr-
estabelecidos.
4.6. O processo Helix-Spindle
Este outro modelo que se denomina Helix-Spindle, envolve as abordagens tericas
e prticas para a construo de ontologias. Aqui, teoria e prtica colaboram
diferentemente para o surgimento da ontologia, onde a especificao da ontologia se d
atravs da teoria e sua validao ocorre pela prtica [KIS04].
Anloga proposta do Processo Unificado, o Helix-Spindle sugere um ciclo de
vida iterativo-incremental (figura 7) onde as ontologias so construdas e melhoradas a
cada nova fase e iterao de fases tericas. A primeira fase do modelo a Concepo,
nesta fase criada a representao informal da ontologia. J na Elaborao refinam-se
as representaes informais transformando-as em semi-formais (ex: diagramas UML) e
por fim na fase de Definio obtm-se uma representao estritamente formal.

Figura 7 - Processo de desenvolvimento de ontologias Helix-Spindle
Ao final de cada fase terica para a construo das ontologias h pontos de
verificao onde estas ontologias sero validadas e testadas dentro do domnio e
54


contexto ao qual foram idealizadas. Com isto, pretende-se obter ento consistncia e
completude, tambm foco do modelo framework MethOntology. Um estudo de caso
utilizado pela metodologia Helix-Spindle foi a ontologia GRITIKA [KIS04], uma ontologia
destinada a representao de servios WEB orientada a objetivos, regras, interaes,
informao, conhecimento e agentes.
4.7. O Processo Knowledge Meta Process
O terceiro processo avaliado foi o Knowledge Meta Process [STA06]. Este
processo consiste de cinco passos principais, onde cada um possui sub-passos,
necessita de uma deciso ao seu final e resulta em uma entrega especfica.
Os passos ou fases principais levam a uma aplicao de Gesto de Conhecimento
baseada em ontologias. As fases so: Estudo de Viabilidade, Iniciao, Refinamento,
Avaliao e Aplicao e Evoluo. Em cada uma das fases devem ser tomadas
decises que determinam o prosseguimento para a prxima fase e em cada uma delas
tambm so gerados produtos de trabalho importantes.
No Estudo de Viabilidade, deve-se observar que muitos fatores alm de
tecnologia, tais como engenharia de software e recursos humanos, determinam o
sucesso ou fracasso de sistemas de Gesto de Conhecimento.
Para a Iniciao, iniciado o trabalho sobre especificao de Requisitos de
Ontologias. O resultado desta fase a descrio semi-formal de uma ontologia,
contendo um grupo de nodos e arestas nomeados ou no. Aps a Iniciao, o
Refinamento consiste em refinar as descries semi-formais sobre ontologias para se
obter a ontologia alvo que necessita ser avaliada na prxima fase. A deciso principal
determinar se a ontologia alvo satisfaz os requisitos capturados na Iniciao, onde o
engenheiro de ontologia compara os requisitos iniciais com a ontologia gerada.
Ento para avaliar a ontologia construda no Refinamento, surge a fase de
Avaliao, onde h 3 tipos diferentes de avaliao com foco em tecnologia, foco no
usurio ou foco em ontologias. Seja qual for o modelo de avaliao utilizado o objetivo
que ao final da fase obtenha-se uma ontologia avaliada e que possa ser utilizada em
um sistema produtivo. O mais usual que para se ter um uso de produo destas
ontologias, sejam necessrias diversas iteraes de Avaliao e Refinamento.
55


Finalmente, a Aplicao e Evoluo representam o real uso das ontologias. A
Aplicao de ontologias depende de um processo que envolva criao, captura, busca
e uso de conhecimento. J a Evoluo de ontologias no um processo de
conhecimento, mas sim um processo organizacional que deve possuir regras explcitas
para a manuteno de ontologias. Fundamentalmente, necessrio que se
identifiquem os papis, as atividades e a seqncia de tempo envolvidas no ciclo de
evoluo que gera uma ontologia melhorada.

4.8. Abordagem para Gesto de Conhecimento
Evaristo e Desouza [EVA00] propem uma abordagem hibrida (Figura 8) para a
gesto de conhecimento em ambientes distribudos. No trabalho, realizam uma
comparao entre as abordagens de gesto de conhecimento de codificao e
personalizao com dois modelos computacionais: cliente-servidor e ponto-a-ponto
(P2P).
Na abordagem de codificao o conhecimento individual condensado,
contextualizado e centralmente disponibilizado em um bando de dados, partindo da
premissa que o conhecimento pode ser facilmente extrado e codificado. Isto torna esta
abordagem muito similar ao modelo cliente-servidor. J a personalizao representa o
oposto, focando na dimenso tcita do conhecimento e assumindo que o conhecimento
compartilhado pelo contato direto entre os indivduos, tendo assim um carter
distribudo que a torna muito semelhante ao modelo P2P.

Figura 8 - Abordagem hbrida de Evaristo e DeDesouza
56



Estas abordagens tm implicaes positivas e negativas na gesto de conhecimento
em projetos distribudos que so analisadas sobre trs dimenses da gesto do
conhecimento: compartilhamento, controle e estruturao do conhecimento. Com base
nesta anlise identificada uma abordagem hbrida visando maximizar os benefcios
dos modelos cliente-servidor e P2P, quando aplicados gesto do conhecimento. E
esta abordagem hbrida facilita e auxilia o processo de gerncia de requisitos atravs
da adoo de prticas de gesto do conhecimento, possibilitando um melhor
entendimento e distribuio da informao entre as pessoas.

57


5. APLICAO DE GESTO DO CONHECIMENTO NA
ENGENHARIA DE REQUISITOS EM AMBIENTES DE
DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE

Neste captulo, inicialmente apresenta-se o contexto de aplicao de GC na
Engenharia de Requisitos em Ambientes de DDS. Em seguida, detalha-se o estudo de
caso realizado, descrevendo a coleta dos dados e num segundo momento realiza-se a
anlise dos mesmos sob uma viso crtica, ligando os resultados encontrados ao
contedo disponvel na literatura. Ao final do captulo, utiliza-se a anlise dos dados e a
documentao coletada como base para identificar as lies aprendidas.
5.1. Contexto de Aplicao
Para este trabalho aborda-se a utilizao de tcnicas de GC como forma de
facilitar a comunicao entre equipes distantes geograficamente. Sabendo que a
formalizao facilita o entendimento das pessoas, foi identificado o uso de dicionrio de
dados para a formalizao do conhecimento, por representar uma soluo menos
complexa do que ontologias e utilizada como exemplo de tcnica de GC.
Com base neste entendimento sobre, o prximo passo foi identificar um
processo que possibilite entendimento compartilhado entre equipes e grupos diferentes,
sobre os conceitos envolvidos com requisitos e relacionamento entre eles. Mais
especificamente, ao obter um entendimento comum entre usurios, clientes e equipes
de desenvolvimento pode-se prover um produto final que corresponde s expectativas e
necessidades de um projeto de software.
Para corresponder as necessidades e expectativas do cliente preciso
transformar estas necessidades em caractersticas de um software e a partir deste
momento identificar e especificar requisitos. Logo, percebe-se que dicionrios de dados
podem auxiliar no processo de Engenharia de Requisitos, desde sua identificao at
sua homologao. Se todos se comunicam uniformemente e obtm um mesmo
entendimento sobre um determinado conceito (ou requisito) aumentam-se as chances
de sucesso do projeto, onde o produto final atender o esperado pelo cliente.
Somando-se a este contexto, ainda sabemos que muitas empresas adotaram o
trabalho com equipes distribudas, principalmente para minimizar custos e buscar mo-
58


de-obra qualificada, ou ainda em funo de estratgias comerciais. Contudo, o
desenvolvimento distribudo agrava os problemas de comunicao e entendimento
entre usurios ou clientes e a equipe de desenvolvimento, quando no raramente h
mais de uma equipe de desenvolvimento e estas esto tambm em localidades
diferentes [PRI06b]. Finalmente, para atender ao contexto distribudo, importante
entender que a contextualizao dos projetos nem sempre segue a risca o que vlido
para a organizao, portanto proposta uma base centralizada com conhecimentos
fundamentais e com menor flexibilidade e bases individuais para os projetos, onde se
pode instanciar o conhecimento, aproximando-o da realidade dos projetos.

5.2. Coleta de Dados
Para identificar o processo de uso de GC na Engenharia de Requisitos em
ambientes de DDS se buscou realizar um estudo de caso com profissionais da rea de
desenvolvimento de software, profissionais estes que trabalham em empresas inseridas
no contexto de desenvolvimento distribudo de software (atendendo assim a sub-etapa
de Identificao de Processo da segunda etapa da Metodologia de Pesquisa proposta
neste trabalho). Primeiro, criou-se um protocolo de estudo de caso com o objetivo de
entender e identificar os problemas que existentes em ambientes de DDS e como
resolv-los atravs da aplicao de GC.
O estudo de caso envolveu um procedimento de entrevistas presenciais e
remotas, utilizando diferentes dimenses com suas respectivas questes, a fim de que
se pudesse entender os problemas e o contexto especfico nos quais ocorriam. Esta
tcnica foi desenvolvida conforme proposto por Yin [YIN06]. Tambm foram coletados
dados de documentos de projeto das empresas onde os profissionais foram
entrevistados, visando confirmar as informaes recebidas.
Os profissionais que participaram do estudo de caso so de diferentes empresas
situadas no Brasil, mas que possuem clientes em outros estados e em outros pases,
tais como Estudos Unidos e Portugal, caracterizando no somente ambientes de DDS,
mas tambm ambientes de desenvolvimento global. Ainda, tendo clientes distintos,
estas empresas trabalham tanto com clientes internos, ou seja, clientes de outras
unidades da mesma organizao como tambm com clientes externos.
59


Com relao ao processo de trabalho, todos os profissionais trabalham em
empresas que seguem as prticas recomendadas pelo CMMI nvel 2. Portanto estes
profissionais atuam em ambientes de trabalho onde os processos de desenvolvimento
de software possuem papis, atividades e artefatos bem definidos para trabalhar com:
Gerncia e Acompanhamento de Projetos;
Gerncia de Configurao;
Mtricas e Anlise;
Garantia da Qualidade de Software;
Gerncia de Sub-Contratao;
Gerncia de Requisitos, que foco deste trabalho.
Ento, na coleta de dados utilizou-se um questionrio com questes abertas e
questes fechadas. O questionrio teve a validao de face e contedo realizada por
dois pesquisadores e dois analistas de sistemas de empresas diferentes, onde a cada
validao sofreu melhorias at a obteno da verso preliminar. Em seguida, foi
realizado um pr-teste com dois analistas de sistema de empresas diferentes no qual
foram identificadas necessidades de reformular algumas questes a fim de evitar
problemas de entendimento e generalizar os conceitos, para que fossem entendidos na
realidade das diferentes empresas.
Aps finalizar o questionrio, este foi enviado aos respondentes das empresas e
a partir deste momento foram marcadas entrevistas presenciais com os trabalhadores
que se dispuseram para tal e os demais responderam remotamente atravs de correio
eletrnico. O questionrio foi respondido por 4 pessoas de cada empresa, totalizando
assim 12 pessoas, sendo 3 gerentes de projeto, 6 analistas de sistemas e 3 analistas
de negcio.
Depois de recebidas as respostas dos questionrios, realizou-se a consolidao
dos resultados utilizando a anlise de contedo e o mdulo estatstico do Excel. Ainda,
em duas empresas foi feita a triangulao dos dados fornecidos nos questionrios com
os documentos utilizados nos projetos e com as definies formais das polticas
organizacionais de cada empresa, o que possibilitou uma maior confiabilidade dos
resultados.
60


O questionrio possui 5 dimenses que foram exploradas a fim de entender o
contexto e problemas vivenciados pelos profissionais entrevistados. Estas dimenses
sero detalhadas a seguir. A primeira dimenso abordou os dados demogrficos,
identificando os respondentes e sua atuao e experincia. Nesta dimenso as
questes solicitaram informaes pertinentes formao acadmica, experincia
profissional e funo atual desempenhada na empresa. J a segunda dimenso teve o
foco na empresa, para que se entendesse o ambiente de trabalho e dados gerais sobre
a distribuio das operaes de desenvolvimento de software das empresas.
A terceira dimenso focou nos aspectos sociais, utilizando questes objetivas e
outras subjetivas que serviram para embasar as perguntas objetivas. Na quarta
dimenso se estudou os aspectos tcnicos, complementando as informaes sociais,
para que se obtivesse o entendimento completo sobre o ambiente de trabalho em que
os profissionais entrevistados estavam atuando.
E a quinta dimenso abriu questes subjetivas para que fosse possvel coletar
maior detalhe sobre a idia de aplicao de ontologias em seus ambientes de trabalho,
citando vantagens e desvantagens, mais especificamente no auxlio Engenharia de
Requisitos em ambientes de desenvolvimento distribudo de software. Todos os dados
do questionrio apresentam-se descritos no Anexo 1 Estudo de Caso.
5.3. Anlise de Dados
5.3.1. Dimenso de Dados Demogrficos
Inicialmente importante destacar que para melhor visualizao dos dados aqui
descritos, deve-se consultar o Anexo 2 Questes Tabuladas.
Ento se aborda a primeira dimenso da entrevista (questionrio), sabendo que
foram entrevistadas 12 pessoas, entre elas 11 possuam nvel superior completo na
rea de Cincia da Computao e uma delas (gestor de projeto) em Administrao com
nfase em Anlise de Sistemas e mdia de idade de 27,58 anos. Todos os
respondentes trabalhavam a pelo menos 2 anos na organizao, mas nenhum
excedendo 5 anos de trabalho. Este tempo de trabalho dos profissionais em suas
empresas indica que os entrevistados devem possuir conhecimento tcito significativo,
acumulado e absorvido em funo de suas experincias em projetos. Davenport
[DAV98] cita que a experincia adquirida representa conhecimento tcito direto e que
61


um diferencial competitivo para o profissional e para a empresa. Assim, acredita-se que
a qualidade das respostas tenha um nvel superior e diferenciado em funo da
experincia dos entrevistados [VAL05].
Ainda a mdia de tempo de trabalho na rea de Computao de quase 8 anos
(7,92), no entanto, a mdia baixa quando se fala de atuao no papel para o qual foram
entrevistados, onde todos os respondentes possuam experincia de pelo menos 3
anos desempenhando o mesmo papel para o qual foram avaliados nos questionrios,
no entanto, apenas 1 excedia 5 anos de experincia na funo. Todos estes dados
demogrficos da primeira dimenso que foram identificados estavam em conformidade
com a documentao coletada.
5.3.2. Dimenso de Aspectos Organizacionais
Em relao aos aspectos organizacionais que se mostra a diferena entre as
empresas dos trabalhadores entrevistados, pois cada uma possui polticas nitidamente
diferenciadas. Duas empresas so de grande porte, e trabalham somente com
desenvolvimento distribudo de software, possuindo atualmente mais de 150
funcionrios cada uma (com uma chegando a mais de 1000 na rea de Tecnologia de
Informao), somente na unidade dos entrevistados em questo. J a terceira empresa
de mdio porte, e atua com desenvolvimento distribudo de software somente atravs
de atuao conjunta com clientes que trabalham com este tipo de desenvolvimento. No
que se refere localidade dos clientes, uma das empresas trabalha apenas com
clientes dos Estados Unidos, a outra com clientes de Portugal e a ltima com clientes
de Estados Unidos e Portugal. Contudo, o que estas empresas possuem em comum
que suas equipes de desenvolvimento esto todas situadas no Brasil. Outro fato
importante, no que se refere segunda dimenso, que o processo de Engenharia de
Requisitos de todas as empresas era baseado no modelo CMMI [CMM06] e nas
prticas do Processo Unificado definido pela Rational Software (RUP) [RUP98].
O incio do processo de Engenharia de Requisitos se dava de duas formas, seja
atravs da leitura de documentao fornecida pelo cliente, seja por interao direta com
o cliente, exigindo viagens para ter reunies face-a-face com o cliente. Num segundo
momento, aps ter sido realizado o entendimento geral, eram gerados o documento de
Viso de Produto e logo em seguida o de Especificao de Requisitos de Software,
62


identificando atravs da tcnica de Casos de Uso quais seriam as funcionalidades a
serem contempladas no ciclo de vida do projeto. A partir destas definies ento se
partia para as especificaes funcionais e tcnicas, dando subsdios para o incio de
ciclos de desenvolvimento e teste de software.
5.3.3. Dimenso de Aspectos Sociais
Na terceira dimenso, para os aspectos sociais foram realizadas questes
objetivas onde se pode verificar mais diretamente o resultado sobre as respostas
dadas. Na primeira e na segunda questo, pode-se notar que a maioria dos
respondentes cita que h comunicao direta e freqente com o cliente no perodo de
definio de requisitos. Na comunicao com o cliente, os mecanismos mais utilizados
pelos analistas so as reunies face a face, telefone, correio e chat eletrnico. No
entanto os que realizam mais reunies diretas com o cliente so os analistas de
negcio.
Ainda na segunda questo, percebe-se que h a interao entre os analistas de
sistema e a equipe de desenvolvimento se d praticamente atravs de reunies face a
face sendo apoiada pelo uso de meios eletrnicos. J os analistas de negcio utilizam
mais os meios eletrnicos para se comunicar com o desenvolvimento, visto que muitas
vezes esto na localidade do cliente, separados geograficamente.
Entre si, os analistas utilizam tanto mecanismos eletrnicos (chat e e-mail) como
tambm reunies face-a-face, quando h a oportunidade, e tambm h grande
interao por telefone para realizar alinhamento sobre o entendimento dos requisitos.
J a gerncia de projeto utiliza a maioria de mecanismos de comunicao disponveis
para atuar junto ao cliente, analistas e equipe de desenvolvimento, mas na maioria dos
casos realiza poucas reunies face-a-face com o cliente, visto que est mais
diretamente ligada a equipe de desenvolvimento realizando o acompanhamento dos
projetos. Embora no tenha sido possvel verificar a freqncia de utilizao dos
diferentes mecanismos de comunicao, h evidncias de utilizao de todos atravs
de atas de reunio, emails e inclusive histricos de chats eletrnicos que so salvos
nos repositrios dos projetos.
A utilizao de diferentes mecanismos e tcnicas de comunicao vai ao
encontro da pesquisa de [DAM03] onde se tem que em ambientes de desenvolvimento
63


distribudo de software a interao entre equipes separadas geograficamente
fundamental para a Engenharia de Requisitos, aumentando a confiana entre as partes
e facilitando o processo de levantamento e anlise de requisitos. Para facilitar esta
interao o trabalho de Daniela destaca a importncia de utilizar diferentes meios de
comunicao, facilitando o contato e formalizando a informao trocada.
Notou-se, pela avaliao das respostas da questo 3, que apenas uma equipe
de uma das empresas citou que h uma descrio formal dos procedimentos de
comunicao na empresa, sendo esta descrio dada no prprio processo de
desenvolvimento de software. Na triangulao dos dados verificou-se que o processo
abrange parcialmente a forma de comunicao a ser adotada, falando apenas em
documentao e no em comunicao diria e/ou informal.
Nas respostas da questo 4 nota-se que muitas vezes as atividades de interao
entre as equipes se do de forma ad-hoc, e ao ser explicado pelos entrevistados de 2
empresas, para eles esta comunicao ad-hoc representa a comunicao informal
cotidiana. Dentro da equipe de projeto, nota-se que todos entrevistados explicitaram a
clara utilizao de reunies peridicas, sejam elas semanais ou quinzenais, para alinhar
e acompanhar o andamento das atividades e o entendimento sobre requisitos. J na
interao com o cliente as reunies inicialmente se do de forma mais freqente e
direta, e durante o andamento do projeto h uma formalizao maior, onde as reunies
so agendadas previamente e definidas em cronograma. Com relao s questes 3 e
4 salienta-se o trabalho de [ROS97], onde explicitada a importncia de haver um
padro formal de comunicao definido para que o canal de comunicao seja
controlado e nenhuma informao seja perdida. possvel verificar atravs dos
cronogramas de projeto que havia atividades para reunies da equipe de projeto e
tambm reunies dos analistas com o cliente, garantindo o que foi relatado pelos
entrevistados.
Os resultados da questo 5 enfatizam ainda mais a importncia das reunies,
pois estas realmente representam um mecanismo de distribuio do conhecimento.
Contudo, os documentos gerados a partir das reunies e do trabalho da equipe servem
de base para a formalizao deste conhecimento, construindo a base de referncia
para discusses futuras. E pela questo 6, verifica-se que foi unnime a resposta de
64


que os mecanismos disponveis so utilizados por todas as equipes, mesmo em
diferentes empresas, o que corroborado pelas mesmas evidncias mencionadas para
a confirmao das respostas das questes 1 e 2. Nissen cita as reunies como
mecanismo de comunicao utilizado freqentemente entre equipes, mesmo em
ambientes de DDS, ainda outros autores citam que as reunies so importantes para a
Distribuio do Conhecimento [CHA99] [DAV98] [NIS06].
Passando para a questo 7, procura-se identificar se h alguma preparao dos
profissionais para atuar com os meios de comunicao fornecidos pela empresa, ento
obteve-se que as tcnicas mais utilizadas so o treinamento e/ou processo de
onboarding dos funcionrios e ainda num segundo momento pode tambm ser feita a
passagem de conhecimento realizada informalmente dos funcionrios mais experientes
para os mais novos, em termos de documentao realmente foi encontrado na
descrio dos processos de Onboarding qual a forma de atuar com os meios de
comunicao, detalhando as polticas organizacionais sobre o uso de telefone, e-mail e
chat eletrnico.
Estas iniciativas vo de encontro ao modelo CMMI, mais especificamente no
nvel 3 h uma rea de processo [CMM06] que a de Treinamento Organizacional,
onde se busca determinar os treinamentos necessrios para a organizao, realizar
estes treinamentos e registr-los, mantendo a capacidade de treinamento. Lembrando
que embora as empresas dos entrevistados ainda estejam no nvel 2, muitas j aplicam
prticas apontadas pelo nvel 3.
Tendo entendido o funcionamento e prticas adotadas, procura-se identificar se
os envolvidos entendem a importncia de utilizao de meios de comunicao no
levantamento e alinhamento de requisitos. Sendo que a escala de respostas de 1 a 5
(1 sendo o menos importante e 5 o mais) e obtendo uma mdia de 4,41 pode-se ver
que dado muito valor a qualquer ferramenta que facilita o trabalho de comunicao.
Ainda nas entrevistas presenciais foi destacado verbalmente que estas ferramentas
devem ser prticas e de fcil acesso, os comunicadores instantneos foram citados
como exemplo deste tipo de ferramenta. As opinies dos entrevistados corroboram com
a pesquisa de Damian [DAN02], onde se busca os meios de comunicao como
65


catalisadores da Engenharia de Requisitos, com diferencial para ambientes de
Desenvolvimento Distribudo de Software.
Os problemas de comunicao mais freqentes citados em diferentes estudos
so identificados tambm nas respostas da questo 9, onde as maiores dificuldades
levantadas foram as diferenas culturais e de idioma. E pela questo 10, nota-se que
essas dificuldades se do justamente no processo de levantamento e entendimento de
requisitos realizado pelos Analistas de Negcio quando esto em contato direto com o
cliente. Onde muitas vezes o cliente no se faz claro o suficiente ou quando ocorrem os
problemas de interpretao relacionados a cultura e a diferena de idioma. Na
literatura, os pontos de maior gerao de problemas so adventos da diferena cultural,
ou seja, de postura e comportamento e tambm da diferena de idioma, conforme
alguns autores tais como Ewic e Prikladnicki [NGU05] [PRI06a].
Por serem descritivas, as questes 11 e 12 necessitaram de um trabalho mais
criterioso de avaliao para identificar categorias de alto nvel que tivessem sido
abordadas pelos entrevistados. Aqui se percebeu, pela questo 11, que os
entrevistados apontaram como fatores culturais chave:
Comportamento envolvimento, dedicao e educao so diferenciados entre
as equipes distribudas, e esta diferena mais visvel ainda entre a equipe de
projeto e o cliente.
Comprometimento preocupao constante com o andamento do projeto e os
resultados finais que necessria por parte de todos os membros da equipe, no
entanto no uma constante entre os envolvidos nos projetos.
Flexibilidade habilidade de encontrar caminhos alternativos para atingir os
objetivos de cada atividade, gerenciando possveis conflitos gerados por perfis
de trabalho, culturas diferenciadas, restries funcionais, tcnicas oramentrias,
etc.
Comunicao e Conhecimento preocupao constante com a clareza dos
conceitos envolvidos e com o objetivo de ter toda a equipe com uma mesma
viso sobre o sistema, o negcio e as atividades pendentes.
Onde, na questo 12, todos os entrevistados apontaram que o cliente tem
influncia direta sobre os fatores culturais, visto que em todas as empresas envolvidas
66


neste caso de uso tem-se que a equipe de projeto vivencia uma cultura e o cliente
outra. Lembrando novamente que todas as empresas do estudo de caso tm unidades
de desenvolvimento de software situadas no Brasil, enquanto que seus clientes esto
nos Estados Unidos e Portugal.
Um aspecto interessante a ser considerado que alguns entrevistados de
diferentes empresas citaram que o treinamento a respeito da cultura presente na
organizao e no cliente no seria importante, levando a mdia de respostas da
questo 13 para 3,92. Estes entrevistados citaram que no seria necessrio um
treinamento formal para comunicar esta informao, sabendo que isto poderia ser
passado informalmente, no entanto cai-se no risco de o conhecimento no ser
repassado e ento haverem problemas de comunicao. No entanto estas opinies so
opostas ao pregado na literatura, o modelo CMMI [CMM06] cita que o treinamento
organizacional importante para todos os envolvidos com os processos da empresa, a
fim de garantir no s a uniformidade e efetividade do treinamento como tambm para
ajudar na garantia de institucionalizao do prprio processo. Ainda, Nonaka e
Takeushi apontam que a transmisso informal do conhecimento, ou seja, a distribuio
de conhecimento tcito difcil de ser realizada devido a este conhecimento ser
diferente para cada pessoa e por este motivo est sujeito a problemas de interpretao
[NON94].
Embora existam problemas de comunicao nos projetos, na questo 14
percebeu-se que os respondentes acreditam que o cliente possui confiana na
empresa, atravs da mdia de 4,66. Lembrando que os entrevistados so todos
experientes, trabalhando em suas empresas a pelo menos 2 anos. Por isso entende-se
que estes profissionais tiveram a oportunidade de conquistar a confiana do cliente ao
longo do tempo. Isto evidenciado ainda mais na questo 15, pois as oportunidades de
integrao face-a-face com o cliente no so freqentes, portanto o tempo para adquirir
a confiana mais longo. Alguns autores apontam que a confiana como fator de
sucesso na Engenharia de Requisitos em ambientes distribudos, no entanto comentam
que a confiana deve ser adquirida no s pela comunicao remota, mas mais
fortemente pelo contato pessoal, com contatos diretos e regulares com o cliente.
[PRI06a] [ESP05].
67


Sabendo que a confiana do cliente difcil de ser conquistada e demanda
tempo, tambm importante avaliar a confiana interna na equipe, sobre a execuo
das tarefas envolvidas no projeto e sobre a Engenharia de Requisitos. A maioria dos
entrevistados, conforme as respostas dadas na questo 16 e 17 sentem-se confortvel
em confiar em outros membros da equipe de projeto, onde a mdia das respostas ficou
em 1,58 para a questo 16 (considerando 1 como discordar totalmente em no deixar
que membros da equipe tenham influncia sobre os problemas importantes do projeto)
e 4,58 para a questo 17 (sendo 5 concordar plenamente em entregar a completa
responsabilidade do projeto para outro membro da equipe). Esta importncia de
comunicao e confiana entre as equipes distribudas geograficamente ou no
explicitada por Sirkka [JAR99] no trabalho Communication and Trust in Global Virtual
Teams, para que o trabalho seja realizado de forma organizada e concisa.
5.3.4. Dimenso de Aspectos Tcnicos
Na quarta dimenso, para os aspectos tcnicos, a maioria das questes foi
realizada a fim de obter o entendimento da construo do produto para avaliar o
trabalho e os profissionais envolvidos na Engenharia de Requisitos. Na primeira
questo procura-se entender se existe a prtica de armazenar os dados, informao e
conhecimento envolvidos na Engenharia de Requisitos na organizao. Ainda, verifica-
se se esta base consultada, pois no basta que o conhecimento esteja acessvel,
preciso que este seja utilizado a fim de que se possa aproveitar o trabalho que j foi
realizado anteriormente e no seja necessrio realizar anlises de requisito
desnecessrias, sofrendo o risco de incorrer em novos erros e problemas de
comunicao e interpretao.
As respostas da questo 1 apontam um problema no processo ou na cultura
organizacional, pois embora a maioria dos entrevistados tenha citado que existe uma
base com informaes sobre requisitos, informao confirmada pela existncia de
bases de armazenamento de lies aprendidas dos projetos que so mantidas sob
Gerncia de Configurao, muito poucos apontaram que esta base utilizada como
referncia na abertura de novos projetos. No s a documentao, mas utilizao de
lies aprendidas recomendada pelos modelos de qualidade de software CMMI e
SPICE como tambm [EGY04] salienta que as lies aprendidas so facilitadores para
68


que no seja feito retrabalho para analisar novamente conceitos que j foram
entendidos e no recorrer em erros j cometidos.
A Gesto do Conhecimento, seria um mecanismo para motivar no s a
alimentao de uma base de conhecimento, mas tambm a utilizao da mesma
atravs da definio de processos de trabalho direcionados. E esta utilizao ocorre em
poucas ocasies para os entrevistados, conforme respondido na questo 1. Ento na
questo 2 explicita-se a pergunta sobre a utilizao de Gesto do Conhecimento na
empresa, e apenas em uma empresa os entrevistados citaram que ela existe
formalmente. Mesmo tendo respondido no para a questo, outros entrevistados
citaram que suas empresas estavam trabalhando em iniciativas para a Gesto do
Conhecimento, ao realizar a triangulao dos dados pode-se notar que realmente duas
empresas esto iniciando projetos direcionados para a Gesto do Conhecimento, j
para a terceira empresa no foi possvel realizar a triangulao, pois a documentao
no foi disponibilizada.
Afirma-se em [ESP05] e [SIL06] que a Gesto do Conhecimento deve ser
identificada como necessria para que depois seja estudado um plano de implantao e
por fim defina-se o processo de Gesto do Conhecimento mais adequado aos objetivos
da empresa, para isso ento necessitando que seja feita uma definio formal do
processo, conforme esperado na questo 2.
Tendo ou no Gesto do Conhecimento, ainda possvel que a divulgao da
informao seja facilitada para que problemas sejam resolvidos de forma mais eficaz ou
rpida, a maioria dos entrevistados (dez) indicou que existe mecanismo pra tal. O
mesmo foi citado pela maioria ao serem perguntados nas questes 4, 5 onde se busca
se utilizado algum mecanismo para resoluo de ambigidades e conflitos agora
focando em requisitos e novamente obteve-se maioria, e dessa vez unanimidade, de
respostas confirmando que os entrevistados utilizam formas de resolver empecilhos que
venham a dificultar o processo de Engenharia de Requisitos. Na documentao do
processo de desenvolvimento encontra-se as especificaes funcionais e anlises de
mudana como pontos de discusso e resoluo de problemas e ambigidades,
sempre atravs de debate em reunies, presenciais ou no.
69


Na questo 6 aborda-se a divulgao das definies formais tomadas em
relao a um requisito de software a ser construdo e se identificou que todos utilizam
alguma forma de divulgao, para que se possa garantir que o entendimento obtido
entre cliente e equipe foi o mesmo, aqui as especificaes funcionais dos projetos que
foram avaliadas apresentam-se como forma de divulgao das definies formais.
No que se refere s questes 4,5 e 6 deve-se entender que a informao deve
fluir para que os Requisitos sejam tratados adequadamente e se possa definir qual o
produto esperado como resultado final do processo de desenvolvimento de software e
Sem um adequado compartilhamento da informao, ou seja, com problemas e
conflitos a confiana entre equipes atingida, e os esforos de priorizao e
negociao de requisitos tendem a no ser efetivos, conforme afirma Miriam
Sayao[SAY05].
Sabendo sobre os mecanismos de comunicao e resoluo de problemas,
aborda-se o contexto tcnico dos projetos. Para os tipos de projeto de desenvolvimento
determinou-se, atravs das respostas na questo 7, que duas das empresas realizam
projetos de manuteno, embora um dos entrevistados de uma dessas empresas
nunca tenha atuado com um projeto deste tipo. Contudo, todas as empresas realizam o
desenvolvimento de novas solues.
Considerando as diferentes realidades, processos e clientes de cada empresa,
um aspecto importante ter o apoio e confiana do cliente, no somente em relao s
pessoas, mas tambm em relao ao processo de trabalho, e para isso o primeiro
passo que o cliente compreenda este processo. Aqui nota-se claramente que h um
ponto de incerteza, onde exatamente 50% dos entrevistados citaram que acredita que o
cliente compreende o processo de desenvolvimento e 50% no o compreende, pelos
resultados da questo 8. Aqui seria interessante entender que o prprio conhecimento
relacionado no somente a requisitos, mas ao processo de Engenharia de Requisitos,
pudesse estar representado em uma ferramenta de Gesto de Conhecimento. O
entendimento do processo pelo cliente ressaltado por Clnio Salviano que diz o fato
de ter um processo definido e envolver seu cliente nele torna-o cmplice do mesmo, ou
seja, mais fcil seguir com o projeto. [SAL03].
70


As respostas dadas na questo 8 ainda so apoiadas pelas respostas da
questo 9, onde embora uma das empresas trabalhe apenas com desenvolvimento de
novas aplicaes e , pela triangulao dos dados, observe-se que esta empresa possui
apenas um processo definido para a Engenharia de Requisitos, os entrevistados
citaram que o processo no o mesmo para todas as equipes. Ainda ao retornar aos
entrevistados para entender melhor suas respostas, foi indicado que muitas equipes
no seguem o processo definido, indicando problemas organizacionais. Outros
indicaram que o processo de Engenharia no o mesmo no seu entendimento, pois
pode ser customizado, no entanto para este trabalho entende-se que customizao de
processo no caracteriza um desvio de processo. importante que no exista um
processo ad-hoc, que sejam adotadas prticas, documentos, papis e atividades no
consistentes em diferentes projetos, o que deve existir a personalizao do processo
para adequar-se s necessidades e caractersticas especficas de um projeto conforme
sugerido nos modelos CMMI e MPS-BR [CMM06] [MPS06].
J na questo 10, embora tenha sido uma questo aberta, todos os
respondentes indicaram que utilizam processos prprios de suas empresas. No entanto
todos estes processos tm uma caracterstica comum, pois so embasados no modelo
CMMI e na instncia de processo do RUP. Ainda foi ressaltado que no s o processo
de Engenharia de Requisitos est documentado e formalizado como tambm os
projetos possuem documentao de requisitos que elaborada pelos analistas e
validada pelos usurios. A documentao citada est claramente disponvel no
repositrio dos projetos e tambm verificada pelos membros de equipes de garantia
de qualidade. Este tipo de formalizao do processo e adoo de prticas prprias para
a Engenharia de Requisitos vai ao encontro dos modelos de qualidade [CMM06]
[ISO05].
Baseando na idia de que h um processo definido e formalizado para a
Engenharia de Requisitos ento na questo 11, busca-se identificar a aceitao e
necessidade de utilizao da Gesto de Conhecimento na rea de requisitos das
empresas, entendendo que os profissionais esto inseridos em um contexto prprio
para tal devido s operaes de desenvolvimento distribudo e familiaridade e
experincia com processos de desenvolvimento de software. E pela resposta da
71


questo 11 nota-se que h boa aceitao entre os profissionais para a utilizao de
mecanismos de Gesto do Conhecimento, onde a mdia de suas respostas ficou em
4,08 (considerando 5 como muito importante e 1 como pouco importante).
Embora na questo 11 seja destacado pelos profissionais o interesse em utilizar
a Gesto de Conhecimento, na questo 12 h uma variao quando se fala em
compartilhar experincia e aprendizado da Engenharia de Requisitos com o cliente,
pois com o mesmo critrio de avaliao, com valores indo de 1 a 5, a mdia diminuiu
para 3,58. Neste sentido, ao conversar com os entrevistados, muitos salientaram que
seus clientes no se envolveriam no processo de Gesto de Conhecimento e
disponibilizar uma ferramenta de software para eles seria um custo sem necessidade.
No entanto, uma das empresas possui planos de implantar a Gesto do Conhecimento
tendo como um dos objetivos a unificao de esforos de cliente e equipe de
desenvolvimento. Alm de lembrar novamente a importncia do envolvimento do cliente
destacada por Clnio [SAL03] tambm se agrega o conceito de Desouza [DES03] onde
a atuao do cliente especificamente na Gesto do Conhecimento se faz necessria.
5.3.5. Dimenso de Questes Gerais
Na quinta dimenso foram feitas apenas questes abertas aos trabalhadores
entrevistados, para que se entenda em profundidade suas idias, entendimento e
sugestes possveis para a construo da ferramenta a ser prototipada neste trabalho
de mestrado. Todas as questes so direcionadas sob a viso da aplicao de
ontologias, buscando vantagens, desvantagens e obter em alto nvel caractersticas e
pontos de insero da ferramenta que foi especificada posteriormente.
Na primeira questo identificou-se que os entrevistados citaram vantagens
direcionadas ao entendimento dos requisitos. Percebeu-se que a formalizao em
ontologias poderia facilitar a Engenharia de Requisitos em ambientes de
desenvolvimento distribudo de software em:
Compartilhar conhecimento sobre requisitos e suas regras de negcio entre
todos os envolvidos em um projeto.
Esta vantagem segue os processos de compartilhamento e distribuio do
conhecimento citados na literatura [W3C05] [NIS06].
72


Proporcionar o entendimento correto de conceitos e as relaes entre os
mesmos, evitando ambigidade e interpretaes incorretas, visto que a
organizao do conhecimento pode ser feita de forma mais semelhante ao
pensamento humano.
Sabendo que se deve buscar evitar problemas de comunicao desde a criao
dos conceitos at seu compartilhamento e distribuio, como determinam Nissen
e Davenport [NIS06] [DAV98].
Divulgar lies aprendidas em outros projetos, o que destacado tanto em
projetos de desenvolvimento de software, como tambm em projetos de
pesquisa [NIS06].
Identificao de relaes necessrias nos componentes tcnicos do sistema
(tabelas, classes, etc) como decorrncia da relao identificada entre os
conceitos.

A segunda questo busca que os entrevistados, com sua experincia na
utilizao de ferramentas de software, apontem pontos desnecessrios de serem
incorporados na ferramenta e possveis desvantagens que possam ser provenientes da
utilizao de ontologias. Resumindo as respostas em pontos gerais, os entrevistados
abordaram como desvantagens:
Excesso de burocracia para preenchimento de inmeros documentos e
ainda exigir do usurio a validao de vrios documentos desnecessrios para o
desenvolvimento do software a ser desenvolvido.
Esforo investido na definio ou manuteno da ontologia, em projetos
pequenos ontologias mais simples ou o glossrio de projeto poderiam ser o
suficiente.
A anlise baseada no reaproveitamento do conhecimento pode levar
erros de avaliao, estimativas ou entendimento. Para contornar este problema
que deve ser adotada uma abordagem mista de armazenamento do
conhecimento [EVA00] [ESP05].

73


Nas duas ltimas questes, procura-se entender que problemas a ferramenta
poderia ajudar a resolver e quais as caractersticas que ela deveria possuir. Os
entrevistados disseram que os problemas a serem resolvidos no mbito de Engenharia
de Requisitos em ambientes de DDS seriam:
A utilizao de uma base de conhecimento com premissas e referncias
sobre requisitos de software. Caracterstica esta de acordo com a proposta de
modelo de Lopes [LOP04].
Padronizao de conceitos relativos a requisitos entre cliente e equipe e
equipe de desenvolvimento em ambientes de desenvolvimento distribudo de
software. Padronizao j citada e envolvida tambm no modelo de processo
proposto por Lopes [LOP04].
Integrao com outras ferramentas para manter a consistncia entre
diferentes ambientes, pois j h ferramentas utilizadas para formalizar requisitos
na empresa, no entanto de forma mais textual. Ao formalizar atravs de
ontologias ento, pode-se tornar estas integraes mais efetivas.
Compartilhamento de boas prticas, as deixando claras e acessveis para
todos, j mencionado por Nissen e Davenport [NIS06] [DAV98].
Armazenamento centralizado e controlado com facilidade na recuperao
de informaes, onde pode ser utilizada arquitetura proposta por Evaristo e
estudada por Espndola [EVA00] [ESP05].

Quanto s caractersticas da ferramenta, levantadas na ltima questo, muitos
entrevistados (7), citaram que a facilidade de uso (inclusive para leigos) da ferramenta
muito importante, dado que a Gesto de Conhecimento e a organizao do
conhecimento em ontologias gerariam a necessidade de entendimento e aprendizado
para lidar com uma nova viso sobre a estruturao das informaes. Ainda foi citado
que outras caractersticas importantes so:
Simplicidade
Objetividade e facilidade na organizao das informaes e conceitos
Desempenho no inferior a das demais ferramentas utilizadas atualmente
para a Engenharia de Requisitos
74


Possibilidade de organizao do conhecimento por projeto e por rea de
negcio da empresa.
Funcionalidade de busca poderosa.

5.4. Lies Aprendidas
A partir dos estudos realizados e da avaliao da documentao coletada, tendo
por base os objetivos deste trabalho de pesquisa, foram identificadas as seguintes
lies aprendidas:
Lio 1 Oportunidade de uso de GC:
Foi feita a identificao da oportunidade de realizar a formalizao do
conhecimento em um formato que seja de fcil tratamento e reconhecimento, ao
contrrio de ontologias que possibilitam um tratamento computacional mais
robusto e complexo, sugere-se o uso de dicionrio de dados. Justifica-se esta
oportunidade atravs do estudo de caso pelas respostas dadas em relao
Dimenso de Aspectos Sociais nas questes 5, 6 verifica-se a importncia de
diferentes mecanismos para auxiliar na facilitao da comunicao e distribuio
do conhecimento.
Tambm nos Aspectos Tcnicos, pelas questes 1,2 nota-se a oportunidade
de aplicao da Gesto do Conhecimento e pela 4,5 e 6 onde ressaltada a
importncia de mecanismos facilitadores para a resoluo de problemas,
ambigidades e conflitos em relao especificao dos Requisitos de software.
A partir desta identificao se escolheu dicionrio de dados por prover a
representao do conhecimento e no exigir complexidade de implementao,
dada necessidade de aplicao rpida para demonstrao em empresas em
uma futura continuidade do trabalho.
Lio 2 Necessidade ferramenta de apoio a Engenharia de Requisitos em
DDS com o uso de GC:
A utilizao de ferramenta para unificao, disseminao, formalizao e
reaproveitamento do conhecimento relacionado Engenharia de Requisitos
contextualizada nos projetos de Desenvolvimento Distribudo de Software se faz
necessria conforme encontrado no estudo de caso pelas respostas dadas em
75


relao Dimenso de Aspectos Sociais nas questes 9 e 10. As respostas
destas questes demonstram que embora as empresas utilizem ferramentas
auxiliares para realizar o alinhamento e entendimento em relao aos Requisitos,
ainda existem problemas em relao comunicao (culturais, idioma) que
surgem principalmente na Anlise de Negcio e em menor nmero na Anlise de
Sistemas. Para solucionar estes problemas ento se pode aplicar uma
ferramenta que aborde estas questes, sob a tica da Gesto do Conhecimento,
atacando diretamente problemas culturais e de idioma, atravs da unificao do
Conhecimento.
A necessidade de uma ferramenta de apoio ainda explicitada na questo 3
da Dimenso 5, onde foram apontados vrios problemas que atualmente no
so solucionados pelas ferramentas em uso nas empresas e que poderiam ser
atacados se atravs do uso compartilhado de conhecimento em um dicionrio de
dados, sendo possvel identificar e extrair conhecimento relevante que auxilie na
Engenharia de Requisitos. Esta necessidade explicitada vai ao encontro a
definio de etapas da Gesto do Conhecimento que so a criao,
distribuio e manuteno de conhecimento [NIS06] [DAV98]. Com isto o
conhecimento criado armazenado em uma base comum, controlada e que
pode ser utilizada por diferentes membros da empresa e gerida por um perfil
especfico, ou seja, pelo Engenheiro do Conhecimento [LOP04].
Ainda, conforme destacado no estudo de caso atravs da questo 2 da
Dimenso Questes Gerais, importante integrar com outras ferramentas
utilizadas nas empresas e assim garantir consistncia e flexibilidade na
manipulao de informaes e conhecimento relativo a requisitos pertinentes a
projetos ou tipos de projetos, no contexto de DDS [ONT04]. Realizando a
unificao do conhecimento presente em ferramentas de controle de requisitos,
rastreamento de requisitos e gerncia de mudanas, pode-se coletar e analisar
mtricas mais confiveis bem como manter a consistncia da informao de
Requisitos de forma a evitar redundncias [CMM06].
A instrumentao do processo fundamental para a melhoria do trabalho e
aceitao do prprio processo conforme indicado por modelos de qualidade e
76


processos de desenvolvimento de software [CMM06] [RUP98]. E a
instrumentao com o uso de GC na Engenharia de Requisitos tambm se fazer
presente na literatura por [DAM02] [BRE05].
Lio 3 Necessidade de utilizao de processo definido:
A importncia de utilizao da ferramenta e de conceitos iniciais de Gesto
do Conhecimento apoiados por um processo adequado ao ambiente de trabalho
e prticas adotadas pela empresa no Desenvolvimento Distribudo de Software,
evitando burocracia e ajustando-se de forma pertinente Engenharia de
Requisitos identificada nas questes 8 e 9 da Dimenso Aspectos Tcnicos,
onde nota-se que deve haver um processo claro, explcito e bem documentado
para que se evitem problemas de entendimento sobre onde e quando utilizar
uma ferramenta de apoio de forma adequada. Tambm, pela Dimenso de
Questes Gerais ao apontar na segunda questo as possveis desvantagens,
os entrevistados citam que no deve haver burocracia e nem realizao de
trabalho desnecessrio, portanto a ferramenta deve diminuir o trabalho, e no
aumentar, sendo inserida em um processo de aplicao bem definido.
A literatura vai ao encontro desse entendimento obtido no estudo de caso,
pois no s o desenvolvimento de software [CMM06] [RUP98], como as
atividades voltadas para a Gesto do Conhecimento e suporte a utilizao da
ferramenta precisam estar modelados em um processo de trabalho efetivo
[LOP04] e no levando a burocracia ou trabalho desnecessrio, conforme
preocupao dos entrevistados na coleta e anlise dos dados.
Lio 4 Minimizar problemas de reutilizao do conhecimento em
Ambientes distribudos e com projetos distintos:
O conhecimento deve ser gerido e categorizado adequadamente, com
tratamento direcionado por uma pessoa (que seria o Engenheiro do
Conhecimento) para que ao iniciar novos projetos, o contexto destes projetos
seja entendido confrontado com o conhecimento armazenado na base
organizacional, assim se poder tirar o real e efetivo proveito sobre o
armazenamento do conhecimento. Caso no se avalie a aplicao do
conhecimento organizacional ao mbito do projeto, pode-se aplicar
77


incorretamente a definio de um conceito ou ontologia, portanto fundamental
diminuir ou at eliminar problema de reutilizao do conhecimento que possam
surgir nos projetos, conforme evidenciado na resposta da questo 2, da
Dimenso Questes Gerais, onde enfatizada a importncia de considerar os
aspectos e conhecimento especficos do projeto, no realizando
reaproveitamento do conhecimento de forma indiscriminada assumindo que deve
ser sempre utilizado o conhecimento organizacional. Isto tambm importante
dada a natureza do Desenvolvimento Distribudo, onde no s ontologias podem
resolver conflitos e explicitar o conhecimento, mas a definio do contexto
especfico dos projetos em relao s ontologias que ir melhor contemplar a
realidade de cada projeto. Na questo 1 dos aspectos tcnicos tambm se tm
uma observao importante sobre reutilizao onde mostra-se que a maioria dos
projetos no beneficia-se do uso de lies aprendidas, onde conceitos
importantes poderiam ser reaproveitados.
Entendendo que o simples reaproveitamento de um conhecimento pode no
ser o mais adequado visto que o que se aplica para um projeto em um contexto
especfico pode no se aplicar outro projeto semelhante, mas que possui
caractersticas nicas. Para tanto importante que a se mantenha o
conhecimento de forma geral e de forma especfica, conforme [EVA00].

Com base nestas lies aprendidas foi direcionada a especificao do processo, a
fim de atender s expectativas e necessidades levantadas por profissionais de
mercado, entendendo que sua experincia e conhecimento, aliados aos estudos
presentes na literatura, contribuam para a construo de um processo eficaz e aplicvel
no suporte a Engenharia de Requisitos em ambientes de Desenvolvimento Distribudo
de Software.
78


6. PROCESSO PROPOSTO

Partindo das lies aprendidas atravs da anlise do estudo de caso realizado,
pode-se ento compreender melhor a realidade dos projetos realizados em ambientes
distribudos, com suas caractersticas e problemas especficos, principalmente no que
se refere Engenharia de Requisitos. E tendo em vista a teoria estudada, pode-se
identificar meios de aplicar processos de construo e manuteno de ontologias para
melhorar o desenvolvimento de software e o entendimento do conhecimento relativo a
estes projetos.
Ento, prope-se a utilizao de um ambiente que contemple o uso de tcnicas de
Gesto do Conhecimento atravs da formalizao em dicionrio de dados para a
Engenharia de Requisitos em Ambientes de Desenvolvimento Distribudo de Software,
focando nos contextos gerais e especficos [EVA00]. A partir deste ambiente foi
instanciado um processo baseado em outro processo j definido para a Engenharia de
Requisitos em Ambientes de DDS [LOP04].
A seguir, descreve-se o ambiente proposto tendo por base a pesquisa de
Espndola e Evaristo [ESP05] [EVA00] e a lio aprendida 4. Na seqncia, no item 2
descreve-se o processo de trabalho para justific-lo no captulo seguinte.

6.1. Ambiente Proposto
A fim de atacar o problema da distribuio do conhecimento adotou-se uma
abordagem que possibilita a flexibilidade do desenvolvimento distribudo. Este trabalho
prope um ambiente que contempla tanto os cenrios dos projetos com seus mbitos
especficos, quanto o conhecimento da organizao, que deve ser mais rgido e
mantido por mais tempo (Figura 9).
79



Figura 9 - Ambiente Proposto

Visando a flexibilidade e tendo uma arquitetura com diferencial destinada
especificamente para projetos de desenvolvimento de software em ambientes
distribudos, a soluo tem como ponto principal a possibilidade de manter o
conhecimento na sua forma mais geral, com aplicao a todos os contextos, ou seja, a
ser utilizada por toda a organizao. E tambm permite a instanciao do conhecimento
geral para o contexto dos projetos, caracterizando o conhecimento especfico. Visto que
o conhecimento ser formalizado em de forma distinta, preservando a especificidade de
projetos e provendo flexibilidade pelo uso de bases distintas para os projetos e uma
centralizada para a organizao, ento se prope as Bases de Conhecimento, tanto
gerais (BOG), quanto especficas (BOE). Esta abordagem fundamenta-se no estudo de
caso atravs da Lio 4 e no trabalho de Evaristo que sugere uma abordagem hbrida
onde o conhecimento especfico dos projetos e o conhecimento organizacional so
mantidos de forma independente, utilizando uma base centralizada com ndice para o
conhecimento especfico dos projetos [EVA00].
6.2. Processo Proposto
Entre os estudos relacionados foram encontrados modelos de processo
importantes, tendo como base a Engenharia de Requisitos tanto para a utilizao em
ambientes distribudos quanto para a construo de ontologias. Foi feita esta pesquisa
80


a fim de encontrar um processo que servisse de base para o trabalho das equipes de
projeto em ambientes distribudos estando conforme com a lio 3 aprendida pelo
estudo de caso.
Destacou-se o trabalho de Lopes [LOP04] por tratar um dos focos do trabalho, a
Engenharia de Requisitos em ambientes de Desenvolvimento Distribudo de Software.
Com base neste processo ento o prximo passo foi buscar subsdios para melhor
entender a definio de processos, por isto foram estudados o modelo CMMI e o
processo de desenvolvimento de software RUP.
O CMMI [CMM06] define objetivos genricos e especficos que devem ser
cumpridos para que se tenha um processo uniforme e de qualidade, e o RUP identifica
um processo instanciado com papis, artefatos e atividades. Tendo por base os
objetivos definidos no CMMI e a referncia de processo dada pelo RUP entende-se
melhor como construir um processo de desenvolvimento de software. O RUP tambm
foi referncia para a exemplificao de padres de documentos relacionados com as
disciplinas de Modelagem de Negcio e Modelagem de Requisitos. Portanto, foi
possvel aliar as boas prticas e objetivos do modelo CMMI, aos exemplos prticos de
atividades, papis e documentos envolvidos em um processo de desenvolvimento de
software fornecidos pelo RUP [RUP98].
Em paralelo ao estudo de modelos e processos foi estudada e escolhida a
ferramenta Rational Method Composer como mecanismo de formalizao do modelo de
processo de [LOP04] e da instanciao de processo realizada neste trabalho. Na
seqncia, tinha-se por meta estender e instanciar o modelo de processo de Lopes
[LOP04], pois um modelo de alto nvel que necessita ser explorado para que tenha
uma melhor aplicao em projetos no que se refere ao uso de GC. No entanto primeiro
foi necessrio entender os processos de construo de conhecimento, identificados na
base terica como o Methontology, Helix-Spindle e o Knowledge Meta Process, que no
caso, abordam a formalizao atravs de ontologias.
Tendo reunido esta base de conhecimento para melhor aplicar a definio de
processos, identificaram-se atividades genricas dos processos de desenvolvimento de
software a serem utilizadas no contexto de Gesto de Conhecimento. Ento, primeiro
81


foram instanciados 3 fluxos a serem utilizados no ciclo de vida do processo estendido a
partir do trabalho de Lopes [LOP04].
6.2.1. Fluxos do Processo
Os fluxos identificados so os que foram denominados de Seqencial, Contnuo
e Sob Demanda apenas para questes de organizao. Cada um destes fluxos rene
atividade de diferentes tipos e que ocorrem em funo de diferentes objetivos, onde
esta organizao foi feita apenas para melhor organizar e agrupar as atividades.
O fluxo Seqencial representa as atividades que so executadas durante uma
fase, seguindo uma ordem pr-definida, e esto agrupadas a fim de que seja cumprido
um objetivo maior, representado pelos marcos de uma determinada fase. No fluxo
Seqencial tem-se 4 fases encadeadas, onde cada uma estabelece a base para o incio
da prxima, conforme apontado na Figura 10.

Figura 10 Fluxo Seqencial

O fluxo Contnuo (figura 11) envolve uma atividade que deve ser executada
periodicamente e representa o acompanhamento do projeto de desenvolvimento de
software no que se refere ao uso de conhecimento. Aqui, em momentos pr-
determinados, monitora-se o andamento do projeto e so coletadas informaes de
referncia sobre este andamento comparando o conhecimento do projeto em questo
com o conhecimento de outros projetos e da organizao.

Figura 11 - Fluxo Contnuo

E o fluxo Sob Demanda (figura 12) agrupa as atividades que sero realizadas
somente quando surgirem necessidades especficas que precisem de ao imediata e
82


pontual para resolver estas questes. As atividades do fluxo Sob Demanda envolvem a
especificao e anlise de mudana sobre o conhecimento e a gerncia das bases de
conhecimento. O fluxo Contnuo e o Sob-Demanda, em termos de organizao, nada
mais so do que uma especializao do conjunto de atividades denominado por Lopes
como Atividades de Suporte [LOP04].

Figura 12 Fluxo Sob Demanda

6.2.2. Atividades do Processo
Com os fluxos definidos ento se passou a identificar atividades a serem
utilizadas em cada um destes ciclos, tendo sempre como base o RUP, CMMI e
processos de construo de ontologias. Trs grupos importantes de atividades foram
adotados para que se obtivessem atividades a serem incorporadas aos fluxos do
processo a ser instanciado.
Os grupos representados por reas de processo do CMMI [CMM06] e disciplinas
do RUP [RUP98] so a Gesto de Configurao, a Gesto de Mudanas, a Medio e
Anlise e a Gerncia de Requisitos. Na Gesto de Mudanas, de Configurao e de
Requisitos, foram criadas atividades pertencentes tanto ao fluxo Seqencial quanto ao
fluxo Sob Demanda. E para a Medio e Anlise foram criadas atividades ligadas ao
fluxo Contnuo.
Destacando que o modelo instanciado utiliza todas as atividades do modelo de
Lopes [LOP04]. As atividades das 4 fases principais de seu modelo (Definies Iniciais,
Mapeamento de Contexto, Criao da especificao e Gerenciamento de Requisitos)
foram mantidas e relacionadas ao fluxo Seqencial. As atividades de suporte foram
83


atribudas ao fluxo Contnuo, assim aqui detalha-se apenas as atividades novas que
foram criadas para este trabalho.
6.2.2.1 Medio e Anlise de Conhecimento
Da Medio e Anlise identificou-se a necessidade de haver uma atividade
constante do monitoramento do uso de conhecimento durante o projeto. Monitorar o
uso de conhecimento (figura 11) uma atividade baseada nas atividades de
documentao e avaliao do framework Methontology [JON05] em que se requer
avaliao sobre dados a serem coletados sobre o conhecimento em relao a sua
utilizao, ou seja, qual a freqncia de uso, a relevncia do conhecimento, integridade
e clareza do conhecimento, onde se deve entender se ele precisa de alteraes ou
pode levar interpretaes ambguas. Para que estes dados sejam avaliados
necessrio que no projeto implante-se um mecanismo de avaliao por parte dos
usurios, a fim de atribuir conceitos a cada um dos itens mencionados, dessa forma o
Engenheiro do conhecimento ter condies de avaliar estes dados na execuo desta
atividade.
6.2.2.2 Gesto de Mudanas e de Configurao para Conhecimento
Na Gesto de Mudanas e de Configurao, o objetivo principal manter o
controle sobre o conhecimento, garantindo sua estabilidade e identificando o impacto
sobre suas mudanas. Primeiro necessrio manter o versionamento do
conhecimento, no caso do dicionrio de dados, presente em uma base de
conhecimento a ser montada para o projeto ou para a organizao, conforme Lopes
[LOP04]. A partir do versionamento possvel obter maior controle sobre as alteraes
realizadas sobre os dicionrios de dados e a base de conhecimento, identificando quais
foram os responsveis e as respectivas datas de alterao e a diferena entre verses.
Para abranger estas mudanas ento surge um conjunto de atividades denominado
Anlise de Mudana Sobre Conhecimento (figura 13), que pertence ao fluxo Sob
Demanda (figura 12).
84



Figura 13 Anlise de Mudana Sobre Conhecimento

Para este conjunto de atividades, entende-se que sendo as mudanas melhorias
ou correes, devem ser formalmente requisitadas em uma atividade especfica, que
a Solicitar Mudanas na base de Conhecimento, e pode ser realizada por qualquer
papel envolvido no projeto. Ento aps a solicitao, as propostas de mudana podem
ser avaliadas por um Grupo de Controle de Configurao e Mudanas sobre
conhecimento, anlogo ao CCB proposto pelo CMMI [CMM06]. tarefa deste grupo
avaliar a viabilidade de uma mudana sobre um dicionrio de dados existente ou a
viabilidade de criao de um novo dicionrio ou conceito dentro deste. Tambm cabe a
este grupo analisar o impacto das alteraes propostas, garantindo que no sero
geradas inconsistncias na base de conhecimento. Estas duas tarefas so englobadas
pela atividade de Avaliar Mudanas na base de conhecimento, onde uma ferramenta
de auxlio a esta tarefa seria a aplicao do uso de uma matriz de rastreamento, no
abordada aqui neste trabalho.
No CCB envolve-se o Engenheiro de Conhecimento, os Analistas de Negcio e
de Aplicao (estes analistas so papis do modelo proposto por Lopes) e o Gerente
de Projeto. Assim todos devem obter entendimento comum e comunicar a todas as
equipes de projeto envolvidas com esta base, as eventuais mudanas que forem
aprovadas na atividade de Aprovar Mudanas sobre a base de conhecimento. Com
isto encerra-se a Anlise de Mudana sobre Conhecimento e pode-se ento seguir
85


para a melhoria ou construo de novos dicionrios de dados ou conceitos identificados
dentro destes.
Depois de identificada a necessidade de mudana, ento se parte para outras
duas atividades do fluxo Sob Demanda (figura 12), onde a primeira atividade a de
Especificao de Conhecimento, definindo e documentando o escopo e objetivo das
ontologias novas ou alteradas. Aqui surge um novo artefato que o de Especificao
de Requisitos de Conhecimento, proposto pelo Knowledge Meta Process [STA06].
Neste artefato ento sero documentados o escopo, objetivo e contedo das ontologias
em mudana, onde este documento ter a referncia para todas os conceitos,
propriedades e demais itens de conhecimento relacionados ontologia de um projeto
ou da organizao.
6.2.2.3 Engenharia de Requisitos de Conhecimento
Ao criar ou alterar um dicionrio de dados, os conceitos e relacionamentos
envolvidos devem ser coletados e formalizados, alterando a base de conhecimento do
projeto ou da organizao, o que ser realizado pelo Engenheiro de Conhecimento na
atividade Coletar e Formalizar Conhecimento sob Demanda. Estas duas tarefas de
coleta e formalizao seguem a proposta do modelo Methontology [JON05] que possui
as fases de Especificao e Formalizao para a construo de uma ontologia, e do
modelo Helix-Splindle [KIS04] que traz os conceitos da fase de Definio.
6.2.2.4 Atividades do Fluxo Seqencial
A primeira fase do fluxo Seqencial a de Definies Iniciais (figura 14), nesta
fase que criada a infra-estrutura para a conduo do processo de Engenharia de
Requisitos em Ambientes Distribudos. Para cumprir esta fase necessrio realizar a
definio de responsabilidades, do idioma de especificao, do dicionrio, dos pontos
focais ou embaixadores, da forma de interao e dos padres de especificao,
conforme [LOP04].
86



Figura 14 Fase de Definies Iniciais

Na segunda fase, chamada de Mapeamento de Contexto (figura 15), objetiva-se
mapear o contexto da localidade e o do negcio no qual o software a ser produzido se
insere, simplificando o entendimento pelas equipes distantes. Aqui so criadas ou
atualizadas as bases de Informaes Culturais ou de Contexto e de Conceitos do UdI
(Universo de Informaes) onde sero armazenadas os dados de um projeto em um
dicionrio de dados e ainda sero obtidas as informaes gerais sobre o negcio,
seguindo tambm [LOP04].

Figura 15 Fase de Mapeamento de Contexto

Na Criao da Especificao de Requisitos que a terceira fase(figura 16),
cria-se ento a Especificao dos Requisitos [STA06], onde estes requisitos so
87


obtidos, evoludos, inspecionados e validados atravs de sua documentao. As
atividades envolvidas nesta fase so de criar e distribuir os artefatos iniciais do projeto,
evoluir os artefatos de requisitos, inspecion-los e valid-los e construir novas
informaes relevantes ao conhecimento [LOP04].


Figura 16 Fase de Criao da Especificao de Requisitos

A ltima fase de Gerenciamento de Requisitos (figura 17) consiste em manter
os artefatos de requisitos, garantindo que estes esto constantemente alinhados com
os objetivos de negcios e atualizados de acordo com as modificaes do ambiente
[STA06] [CMM06].

Figura 17 Fase de Gerenciamento de Requisitos

No ltimo passo do trabalho sobre processo, optou-se por utilizar a ferramenta
Rational Method Composer (Figura 18) para realizar duas atividades relacionadas
formalizao de processos. Primeiro foi documentado na ferramenta o modelo de
processo de [LOP04]. A partir desta documentao foi estendido, e instanciado,
88


tambm no RMC, o processo com os fluxos, atividades, artefatos e papis propostos
neste trabalho.

Figura 18 Ferramenta RMC

A aplicao do RMC diminuiu o tempo de trabalho, pois esta ferramenta permite
a reutilizao de atividades j definidas anteriormente para a construo de um novo
processo. O que foi til na instanciao do novo processo a partir do modelo de Lopes
[LOP04].
6.2.3. Papis do Processo
Em relao atribuio de papis, surge mais um papel fundamental ao uso de
GC que o Engenheiro de Conhecimento [KIS04] [JON05]. O engenheiro de
89


conhecimento o responsvel por trabalhar com o conhecimento, identificando novos
conceitos e os relacionamentos com conceitos j existentes. Para exercer o papel de
Engenheiro de conhecimento so necessrias certas habilidades, tais como o
entendimento geral de conceitos sobre um universo de discurso e a possibilidade de
transformar este entendimento em uma representao formal, ou seja, no mbito deste
trabalho, em um dicionrio de dados. Para isto podem-se tomar duas abordagens.
Uma abordagem de que o Embaixador definido por Lopes [LOP04] possa
assumir este papel, visto que ele o portador da informao e grande responsvel pela
comunicao entre equipes. Assim o Embaixador deve entender sobre o projeto e
alinhar o conhecimento entre os membros das equipes geograficamente separadas.
Na outra abordagem prope-se neste trabalho que exista uma outra pessoa
responsvel apenas pelo papel de Engenheiro de Conhecimento, no entanto esta
pessoa deve estar em contato constante no somente com o Embaixador, mas com os
pontos focais das equipes distribudas. O processo comporta estas duas abordagens,
pois um papel pode ser assumido por diferentes pessoas, ou ainda, dois ou mais papis
podem ser atribudos a uma nica pessoa.


90


7. JUSTIFICATIVA

O processo proposto buscou caractersticas que possibilitassem a adequao a
padres de mercado e que agregassem valor ao prover mecanismos de implementao
adequados a manipulao e descoberta de conhecimento. Assim, entende-se que as
seguintes caractersticas colaboraram para a elaborao de uma soluo de software
mais adequada a auxiliar na resoluo de problemas da Engenharia de Requisitos em
ambientes de DDS:
biblioteca de processo definida formalmente facilitando sua manuteno,
alterao e extenso;
fcil compreenso e extenso do processo, devido a utilizao de padres
de mercado e documentao de apoio;
representao do conhecimento flexvel e de fcil construo atravs do
uso de dicionrio de dados;
ambiente que suporta a manuteno e anlise sobre o conhecimento em
nvel organizacional e no nvel de projeto, possibilitando preservar a
especificidade dos projetos e identificar, a partir destes projetos, conceitos
relacionados a requisitos que sejam relevantes para toda a organizao;
coletar mtricas e disponibilizar dados para acompanhar a gesto e
alterao do conhecimento nos projetos e na organizao.

Lembra-se que todas as diferenas de um mesmo conceito entre projetos
distintos devem ser ressaltadas e apresentadas ao Engenheiro de Conhecimento para
que ele possa decidir se dever ser feito um alinhamento de representao entre os
projetos e a organizao ou no. Com base nestas caractersticas possvel identificar
possveis problemas e solues em projetos que apresentem caractersticas
semelhantes de outros dentro da mesma organizao.
A fim de explicitar melhor a contribuio do processo, apresenta-se 3 cenrios
onde ele poderia ser aplicado e traria benefcios efetivos aos projetos ou agregaria
conhecimento a organizao.
91


Em cada cenrio descreve-se o problema demonstrando os ganhos em
situaes de utilizao do processo, ou seja, explicitando ganhos que no seriam
percebidos apenas pela descrio do processo em si. Ento, aqui se buscou
demonstrar a aplicao dinmica do processo e os seus benefcios. importante
lembrar que os cenrios demonstram exemplos de aplicao focando na resoluo de
problemas, e no na complexidade de uma determinada situao.

7.1. Cenrio 1 Projetos Relacionados
O Cenrio 1 trata de trs projetos j desenvolvidos de uma aplicao de turismo
onde tem-se um website de uma agncia de viagens. Os requisitos envolvidos nesta
aplicao referem-se diretamente a venda de produtos:
Vos;
Estadias em hotis;
Pacotes de viagens;
No entanto, todos os produtos oferecidos encontram-se em sistemas externos,
com os quais foi feita integrao para resgatar informaes relevantes destes produtos.
Estes sistemas externos disponibilizam servios para pesquisa, detalhamento, e
personalizao dos produtos a serem comprados (Ex: data de estadia e vos, tipo de
quarto ou tipo de refeio), bem como operaes de pagamento, reserva e
cancelamento. Dada a complexidade de integrao com cada um desses sistemas,
cada integrao foi considerada como um projeto a parte.

TABELA 1- DISTRIBUIO DAS EQUIPES DE PROJETO NO CENRIO 1
Sistema Projeto Equipe Cliente
Star Projeto 1, portal de turismo Brasil Portugal
Galileo Projeto 2, sistema de venda de vos Brasil Portugal
Mundo
Vip
Projeto 3, sistema de venda de pacotes
de viagens
Portugal Portugal

Ento, aps a construo da aplicao principal e sua entrada em produo,
finalizando o Projeto 1, surgiu um novo requisito. Este novo requisito envolveu o
92


sistema externo que controla as informaes de venda de Vos denominado Galileo,
com integrao controlada pelo Projeto 2. O novo requisito consistia na gerao de
uma taxa de emisso de ticket a ser cobrada em todos os vos comprados no sistema
Galileo.

TABELA 2- DIFERENA DE CONHECIMENTO RELACIONADO A REQUISITOS CENRIO 1
Projeto 2 Projeto 3
Produto Produto
Integra com Integra com
Possui Taxa Possui Taxa
Taxa Taxa
Aplica em Clculo de Preo Aplica em Clculo de Preo
Aplica em Comunicao com Pesquisa Aplica em Comunicao com Pesquisa
Aplica em Comunicao com Reserva <sem correspondncia>

A partir deste novo requisito foi realizada uma anlise de mudana atravs da
macro-atividade Anlise de Mudana sobre Conhecimento contida no Fluxo Sob
Demanda do processo proposto. Esta mudana foi aprovada e teve-se ento uma
alterao no escopo do projeto 2, envolvendo o mdulo de clculo de preo e a
comunicao com os servios de Pesquisa e Reserva de vos. Ao formalizar esta
alterao sobre o requisito, se criou uma extenso do conceito anterior sobre venda de
produtos, onde agora, uma venda est associada a uma taxa de emisso sobre o
produto, no caso, ticket de passagem area.
Num segundo momento, o cliente do projeto 3 (Mundo Vip), localizado em
Portugal, realizou a solicitao explcita de que fosse realizado o repasse da cobrana
de uma taxa de imposto aplicado a empresas de turismo, onde o preo de todos os
pacotes de viagens seria acrescido de um percentual relativo a este imposto. No
entanto, o cliente deixou claro que esta alterao deveria ser feita nas pesquisas e no
clculo de preo do produto, porm nada foi dito sobre o servio de reserva do Mundo
Vip conforme demostra a tabela 3. Lembrando que embora o nome dos conceitos seja
o mesmo, eles tem significado diferente para cada projeto.
Mas por causa do conhecimento adquirido com a taxa de emisso do sistema
Galileo, o analista de Portugal seguindo o processo proposto e realizando a atividade
Monitorar Uso de Ontologias contida no Fluxo Contnuo, obtm o resultado de que no
93


projeto da ferramenta Galileo (Projeto 2), relacionado com o Projeto 1, havia alteraes
no servio de reservas diretamente relacionadas com o conceito de venda de produtos.
Portanto o analista identifica que o impacto no requisito do projeto 3 maior do que o
esperado, levando a replanejamento do projeto e tambm a atualizao da
especificao da mudana do Projeto 3, a fim de incluir alteraes no servio de
reservas.
7.2. Cenrio 2 Projetos No-Relacionados
O Cenrio 2 trata de dois projetos distintos, onde um deles (Projeto 1)
denominado GCS j teria sido completamente desenvolvido. O Projeto 2 estaria em
Fase de Criao da Especificao de Requisitos, onde realizada a atividade de
Coletar e Formalizar Conhecimento. A partir deste cenrio, analizando o
conhecimento de outros projetos e o conhecimento organizacional, surge a
oportunidade de identificao de desvios em relao a outros projetos ou ainda de
apontamento de requisitos que no haviam sido identificados a priori nestes projetos
(Tabela 4).

TABELA 3- DISTRIBUIO DAS EQUIPES DE PROJETO NO CENRIO 2
Sistema Projeto Equipe Cliente
GCS Projeto 1, transporte de alimentos. Brasil Portugal
HC -
Hospital
Care
Projeto 2, administrao hospitalar. Brasil Estados
Unidos

Os requisitos envolvidos nestes projetos so distintos a princpio, pois o Projeto 1
trata de logstica para transporte de alimentos derivados de frango e o Projeto 2 trata de
administrao de recursos hospitalares. Embora o domnio de conhecimento destes
dois projetos seja completamente distinto, em ambos os projetos normas definidas por
rgos Governamentais ou Ministrios devem ser seguidas. Similarmente ao Cenrio
1, somente avaliando o conhecimento de outros projetos e da organizao, mesmo que
este conhecimento seja utilizado por equipes geograficamente distantes possvel
encontrar pontos de convergncia entre projetos distintos.
94


O Projeto 1 que encontra-se em produo e utilizao por seu cliente, possui um
requisito no qual necessrio emitir certificados para o transporte de alimentos
derivados de frango. A partir de notas ficais geradas sobre a venda destes alimentos,
extrai-se a informao necessria dos produtos sendo transportados e ento, deve-se
transpor esta informao para documentos que devem ser gerados seguindo formatos
pr-definidos que so dados por templates do tipo .doc e que so fornecidos pelo
Ministrio da Agricultura. O requisito em questo indica que um documento possui
formatos padro que por sua vez so baseados em templates .doc e toda esta
informao poderia ser adquirida e analisada, estando na base de conhecimento pelos
dicionrios de dados, pois o projeto dado como concludo.
J no projeto 2, ao iniciar a consolidao de requisitos para aprovao e
estudando a base de conhecimento percebe-se que h relao entre os conceitos
seguir templates e formato. At ento, pensava-se que haveria apenas formatos de
documentos fixos a serem definidos pelo cliente em questo, conforme indicado na
Tabela 5.

TABELA 4- DIFERENA DE CONHECIMENTO RELACIONADO A REQUISITOS CENRIO 2
Projeto 1 Projeto 2
Documento Documento
certificados de trnsito para produtos derivados de
frango.

documentos de compra e venda de produtos
hospitalares.

Possui formato

Possui formato

Formato Formato
formato para a gerao de documentos a serem
enviados ao Ministrio da Agricultura.

formato fixo para a gerao de documentos de
Administrao de recursos hospitalares conforme
regras do Hospital.

Possui Templates <sem correspondncia>
os formatos de documentos so gerados a partir de
templates.


Template <sem correspondncia>
padro de documento para emisso de certificados
de trnsito que deve ser no formato Microsoft
Word.



95


Tendo que a propriedade possui templates est ligada a templates em
formato Word, o Engenheiro do Conhecimento repassa esta informao aos Analistas
de Negcio que por sua vez consultaram o cliente e descobrem que todos os
documentos gerados no sistema HC (Hospital Care) deveriam obedecer aos formatos
definidos pelo Departamento de Sade dos Estados Unidos. Neste caso, j pde ser
feito um planejamento do projeto, realizando a definio da arquitetura junto a ex-
membros do Projeto 1 a fim de realizar o aproveitamento das funcionalidades
desenvolvidas para a gerao de certificados e diminuir a complexidade para
implementao do requisito de gerao de documentos do Projeto 2.
7.3. Cenrio 3 Projeto e Organizao

O Cenrio 3 descreve apenas um projeto (Projeto 1) que, no entanto, obteria
ganhos com a aplicao do processo por dois motivos, onde um seria a formalizao do
conhecimento e o outro motivo seria o aproveitamento de conhecimento organizacional.
Neste cenrio demonstra-se os ganhos em carter de alto nvel, onde o domnio do
conhecimento especificado do Projeto 1 (administrao de recursos humanos) no
necessitaria ser levado em considerao (Tabela 6).

TABELA 5- EQUIPE DE PROJETO NO CENRIO 3
Sistema Projeto Equipe Cliente
RH Ipiranga Projeto 1, administrao de recursos
humanos.
Brasil Portugal

Ao ter um fornecedor de requisitos ou stakeholder que tenha um entendimento
diferente sobre um requisito, o analista de negcio ou mesmo o analista de sistemas,
podem recorrer a base de conhecimento para realizarem o alinhamento com esta
pessoa. O alinhamento pode ser feito de forma direta e sem intermediao visto que um
conhecimento relacionado a um requisito e formalizado deve ter sido aprovado tanto
pela equipe de desenvolvimento quanto pelo cliente previamente. Ou seja, todo
conhecimento da base tanto de projeto, quanto da organizao aprovado antes de ser
formalizado. Ento aqui se tm um ganho no processo de Engenharia de Requisitos ao
96


prover meios de diminuir problemas de entendimento, onde neste cenrio, ao ser
levantada uma discusso no Projeto 1, o analista recorrer a base de conhecimento.
O Projeto 1 (RH Ipiranga) desenvolvido em uma tecnologia que no de
conhecimento da equipe de desenvolvimento, e isto representa um risco a ser apontado
diretamente pelo Gestor do Projeto. No entanto, nenhum requisito adicional percebido
pelos analistas na Fase de Criao da Especificao de Requisitos (tabela 7). No
entanto, todos os projetos da organizao devem utilizar um framework de
desenvolvimento para acelerar a construo dos produtos de software.

TABELA 6- DIFERENA DE CONHECIMENTO RELACIONADO A REQUISITOS CENRIO 2
Projeto 1 Conhecimento Organizacional
Projeto Projeto
<sem correspondncia> Possui Framework

.

todos os projetos da organizao possuem
requisitos no funcionais que fazem parte dos
produtos de software.

Requisito No Funcional Requisito No Funcional
<sem correspondncia> Framework de Desenvolvimento
o arcabouo que direciona e fornece padres de
desenvolvimento para os projetos baseados em
determinada tecnologia.


Assim, caso o Projeto 1 fosse realizado na tecnologia Oracle Forms, at ento
desconhecida, pois a organizao trabalha apenas com .NET e Java, haveria a
ausncia de um framework de desenvolvimento (figura 19). O Engenheiro de
Conhecimento ou Analista, ao recorrer ao conhecimento Organizacional executando a
atividade de Monitorar Uso de Conhecimento, perceberiam uma no conformidade do
projeto com as diretrizes da organizao visto que o framework no havia sido
percebido como um requisito no funcional.
Visto que a organizao prope que um projeto utilize um framework de
desenvolvimento, ento surgiria um requisito no funcional que seria a aplicao de um
framework para Oracle Forms e assim seria disparado o processo de mudana do
Fluxo Sob Demanda, pela atividade Anlise de Mudana sobre Conhecimento.

97


No caso, sob o aspecto de Engenharia de Requisitos o problema se encerra. No
entanto, do ponto de vista da Engenharia de Software o Projetista deveria verificar a
existncia de um framework para Oracle Forms na Organizao e caso este no exista,
deveria indicar que o projeto precisa construir um framework para esta linguagem a fim
de atender o novo requisito no funcional identificado.

Figura 19 Identificao de inconsistncia entre conhecimento de Projeto e da Organizao

Este conhecimento no somente auxilia no planejamento do projeto, mas
tambm trar ganhos para a organizao, pois ao ter um framework pronto para Oracle
Forms, os prximos projetos no necessitaro cri-lo. Ainda mais, caso o cliente seja
interno, o prprio framework poder ser negociado como produto a ser entregue, ao
invs de ser absorvido nos custos do projeto, diminuindo assim o lucro do Projeto 1.

Projeto X FrameworkJava
Projeto 1 ???
PossuiFramework
PossuiFramework
98


8. CONSIDERAES FINAIS

A comunicao e o alinhamento do conhecimento em um projeto de
desenvolvimento de software exercem papel fundamental na compreenso e
especificao dos requisitos do software a ser construdo. Portanto, o conhecimento
no deve somente ser formalizado e disponibilizado, como tambm deve ser
compartilhado e analisado para que se tenha um entendimento comum e para que seja
possvel descobrir e explicitar aplicaes do conhecimento que nem sempre so
determinadas a priori. Assim, com o compartilhamento e anlise do conhecimento,
formalizado atravs do uso de bases de conhecimento (dicionrio de dados), cria-se
mecanismos para diminuir as ambigidades e desentendimentos.
A Engenharia de Requisitos uma rea crtica para o desenvolvimento de
software que pode ser apoiada pela Gesto do Conhecimento. Ento destacam-se dois
fatores importantes sobre a relevncia da pesquisa onde h grandes oportunidades de
pesquisa pois:
A Engenharia de Requisitos em Ambientes de Desenvolvimento Distribudo de
Software caracteriza uma srie de desafios que devem ser estudados, abordados e
resolvidos, no somente atravs da aplicao de processos, mas pela instrumentao
destes, pela aplicao de ferramentas de software. A Gesto do Conhecimento e
ferramentas de suporte ao Desenvolvimento de Software baseadas em manipulao do
conhecimento surgem como facilitadores de vrias reas de conhecimento e conforme
apresentado neste trabalho, podem ser aplicadas na rea de Tecnologia da Informao
e mais especificamente, auxiliar no s na resoluo de problemas da Engenharia de
Requisitos, como tambm da Engenharia de Requisitos no contexto de
Desenvolvimento Distribudo de Software.
Mesmo em projetos executados localmente, mas que envolvem equipes distintas
preciso que os conceitos e seus inter-relacionamentos estejam formalizados,
documentados e acessveis a consulta. Em projetos onde as equipes esto separadas
geograficamente acentua-se mais ainda a necessidade de um meio comum de
compartilhamento de informao e de um formato padro para estruturar o
conhecimento a ser compartilhado.
99


A formalizao do conhecimento vai ao encontro dessas necessidades
encontradas nos projetos. Pelo estudo de caso realizado e analisado entende-se a
importncia do trabalho e percebe-se que a aplicao do processo proposto para este
trabalho de Mestrado prov uma oportunidade de melhoria na Engenharia de
Requisitos em Ambientes de DDS.
Um processo bem definido, estabelecido e compreendido pela equipe que for
utiliz-lo trar maturidade ao desenvolvimento de software e facilitar os processos
envolvidos na Engenharia de Requisitos. Isto se aplicar tanto no levantamento quanto
na especificao, aprovao ou gerncia de mudanas sobre o conhecimento envolvido
em um projeto.
Durante o trabalho ainda observou-se que um processo bem definido deve ter
atividades com objetivos e responsabilidades claras a fim de evitar burocracia e no
conformidades tais como inconsistncia na documentao. Somente um processo bem
definido passvel de ser utilizado sem gerar desconforto as equipes de trabalho e
trazer resultados efetivos, no entanto preciso entender que a maturidade do processo
obtida pelo seu uso e experimentao.
Atravs da aplicao real de um processo e acompanhamento de sua utilizao
que possvel melhor-lo a partir do retorno fornecido pelas equipes que o utilizam.
No basta obter conhecimento bem definido e nem uma ferramenta construda
adeqadamente, preciso que as necessidades das equipes sejam atendidas e que as
atividades no sejam burocrticas, mas sim aceleradoras do desenvolvimento
garantindo que o conhecimento no s est formalizado e disponvel, mas que til e
mantido, gerenciado e reaproveitado.
Ento, conforme os captulos 6 e 7, o objetivo geral dessa dissertao foi atingido,
com a proposta de um ambiente apoiado pela definio de um processo de apoio a
Engenharia de Requisitos em Ambientes de Desenvolvimento Distribudo de Software.
O objetivo especfico de aprofundar o estudo sobre a base terica da pesquisa
focando em Gesto do Conhecimento e aplicao deste na Engenharia de Requisitos e
Desenvolvimento Distribudo de Software, bem como nos processos de construo e
manipulao de conhecimento, foi atingido pela base terica apresentada no captulo 4.
A identificao de um processo de trabalho para o uso de ontologias no suporte a
100


Engenharia de Requisitos em ambientes de DDS, atingiu-se pela avaliao do captulo
6, realizando um estudo de caso e explicitando lies aprendidas que resultaram no
processo definido no captulo 6.
Durante a execuo do trabalho foram consultados pesquisadores e profissionais
da rea, tanto atravs do estudo de caso, como em reunies informais e na
apresentao da atividade de Seminrio de Andamento. Ainda tem-se por objetivo
especificar e construir este prottipo de ferramenta que possa ser utilizado por equipes
distribudas geograficamente e que auxilie na Engenharia de Requisitos. E o objetivo
especfico final o de exemplificar a aplicao da ferramenta em um contexto de ganho
efetivo para os projetos de DDS o que foi descrito no captulo 7.
8.1. Contribuies
A aplicao de GC para a Engenharia de Requisitos em Ambientes de DDS visa
amenizar problemas do DDS especificamente no que se refere ao conhecimento
relacionado aos requisitos dos projetos e o conhecimento consolidado sobre certos
requisitos na Organizao. Ainda, o estudo apresenta o levantamento de dados e de
requisitos referentes s necessidades atuais para o apoio a Engenharia de Requisitos
em DDS e prope uma soluo para atender estas necessidades, envolvendo o
processo e sua instrumentao.
Outras contribuies foram:
Estudo com profissionais da rea
Formalizao de processo em ferramenta de mercado (Rational Method
Composer), facilitando a publicao, a manuteno e extenso do processo
no futuro.
Base terica atual e trabalhos relacionados baseados em processos de
construo do conhecimento.

8.2. Limitaes do Estudo
O estudo possui a limitao do nmero de empresas e de entrevistados, contudo
a grande maioria dos resultados est apoiada na base terica, e somente estes
foram tomados como lies aprendidas. Lies aprendidas estas que nortearam a
posterior definio do processo e da especificao de ferramenta. Outra limitao
101


a de no ter sido feita a construo e validao da ferramenta e processo propostos
devido s limitaes de tempo impostas ao trabalho e tambm agenda das
empresas que foram abordadas.
Outras limitaes foram:
No especificao de ferramenta e modelo de inferncia de
conhecimento.
No criao de prottipo funcional de ferramenta.
No continuao de estudo de integrao com ferramentas de mercado.
8.3. Estudos Futuros
A utilizao de Ontologias computacionalmente atravs da aplicao dos
padres RDF e OWL suportados por processos de Gesto do Conhecimento e a
promessa de uma revoluo da rede mundial de computadores atravs da WEB
Semntica [BRE05] apontam um grande potencial de pesquisa futura. Ainda,
aliando-se estas tcnicas na resoluo de problemas da Engenharia de Requisitos
em Ambientes de DDS, entra-se em uma rea de pesquisa muito pouco explorada
e, portanto abrindo um novo contexto para pesquisa.

Ento como pesquisa futura, sugere-se:
A aplicao do processo proposto a fim de identificar melhorias e ajust-lo
de acordo com a realidade das empresas que utilizam DDS;
Aliar o processo definido como forma de implementao de modelos de
qualidade, principalmente ao CMMI, visto que referncia comum entre as
empresas abordadas nesta pesquisa. Assim, poder-se-ia ter, no caso do
CMMI, ganhos na utilizao do processo e na ferramenta propostas
atacando as reas de Gerncia de Requisitos (REQM) e Desenvolvimento
de Requisitos (RD).
Abrir o escopo desta pesquisa e inserir tcnicas e atividades sobre
estimativas de projeto baseadas em requisitos e complexidade de suas
ontologias, possvel prover suporte aos oramentos de projetos utilizando
a captura do conhecimento de especialistas e auxiliando uma equipe
102


comercial de uma empresa de DDS, apoiando o processo de venda, as
estimativas iniciais de projeto e a negociao com o cliente.
Utilizar ontologias, que so uma forma de representao mais complexa e
permite maior detalhamento, possui bibliotecas de software prontas para
tratamento computacional (RDF, RDFS e OWL) e adequadas aos padres
da WEB Semntica. Ainda as ontologias possibilitam que se descubra
novos conhecimentos atravs da aplicao de mecanismos de inferncia.
Integrar com ferramentas de mercado, aumentando sua funcionalidade e
por conseqncia aumentando sua aplicabilidade nas empresas.
Prover um mecanismo de rastreabilidade entre informaes ou conceitos
presentes em ontologias ou dicionrios de dados, para facilitar a anlise de
impacto sobre mudanas propostas sobre o conhecimento j estabelecido.
8.4. Proposta de Continuidade
Para que o processo proposto seja mais bem aplicado em um ambiente real
importante que seja tambm criada uma ferramenta que d suporte a este processo
para que as atividades sejam realizadas com maior agilidade e controle. Com o uso de
uma ferramenta ser possvel formalizar o conhecimento da organizao e compartilh-
lo mais facilmente entre seus colaboradores.
Aqui segue uma proposta de continuidade do trabalho com a especificao de
uma ferramenta baseada em ontologias, garantindo maior riqueza de representao do
conhecimento. Ento fez-se uma breve descrio de funcionalidades, seguida de uma
proposta de modelo de classes e de um prottipo de telas.
8.4.1. Especificao da Ferramenta
Primeiramente, para especificar a ferramenta deve-se entender claramente qual
o problema foco sendo abordado. Tem-se que os projetos de desenvolvimento
distribudo de software necessitam melhorar a comunicao entre as equipes e com o
cliente. H diferena de interpretao para os conceitos, o contexto em que estes se
aplicam e qual a relao entre eles.
Estas dificuldades de comunicao e entendimento do conhecimento,
identificadas nas lies 1, 2 e 4 afetam os clientes que no recebem o que esperam,
103


onde os produtos finais nem sempre refletem suas necessidades, pois no foram
abordados da forma correta por causa de problemas de comunicao. Assim,
diminuda a confiana do cliente nos seus fornecedores, sejam eles internos e externos.
As empresas de desenvolvimento de software perdem clientes e passam a ter uma
imagem de no cumprir com o que prometem com problemas de interpretao de
conceitos e relacionamentos de requisitos.
Logo, o impacto se d em erros de anlise recorrentes entre projetos, pois o
conhecimento no formalizado e muito menos compartilhado. Ainda em alto tempo de
anlise para alinhamento entre cliente e analistas sobre o que deve ser feito. E tambm
em aumento de custos na correo de defeitos e uso de horas de retrabalho em funo
de requisitos mal compreendidos e definidos.
Ento a soluo de ferramenta proposta visa contemplar as operaes
envolvidas na documentao, utilizao, distribuio e manuteno do conhecimento
relacionado a requisitos, facilitando o processo de Engenharia de Requisito pelo uso de
Ontologias em Ambientes de Desenvolvimento Distribudo de Software. E aqui se
prope um conjunto de funcionalidades para detalhar esta ferramenta.
8.4.1.1. Especificao Funcional da Ferramenta

Ento, a fim de prover o conhecimento em nvel organizacional e no nvel dos
projetos entende-se que deve haver ontologias gerais para a organizao e
ontologias especficas para os projetos, ento sugere-se duas funcionalidades que
so Manter Ontologias Gerais e Manter Ontologias Especficas (figura 20). Onde
as Ontologias Gerais so mantidas pelo Engenheiro do Conhecimento enquanto que
as especficas so mantidas pelos Analistas de Projeto e de Negcio, pois estes
esto mais prximos da realidade dos projetos.
104


Manter Ontologias Gerais
Engenheiro de
Conhecimento
Analista de
Negcio
Gestor de Projeto
Analista de
Sistemas
Manter Ontologias Especficas
Engenheiro de
Conhecimento

Figura 20 Manter Ontologias Gerais e Manter Ontologias Especficas

Para garantir a consistncia entre as Ontologias Gerais e as Especficas,
evitando que existam problemas de entendimento em funo de incoerncia entre estas
Ontologias, ento o Engenheiro de Conhecimento poder realizar o alinhamento entre
elas atravs da funcionalidade Alinhar Ontologias (figura 21), onde dentro de uma
ontologia existe apenas a cpia de um conceito geral para um especfico ou de um
especfico para um geral, substituindo-o. Ainda, deve-se lembrar que todas as
Ontologias criadas devem ser aplicadas a um ou mais domnios de conhecimento da
organizao e contextos de projeto, para tanto deve ser possvel Classificar
Ontologias (figura 21), definindo para cada conceito em uma Ontologia seus contextos
e domnios de aplicao, onde se prope a simples atribuio de valores de domnio
que determinem o contexto de aplicao de um conceito, tais como Transporte,
Turismo, Administrativo/Financeiro e outros.
Ainda, um mecanismo importante para utilizao de ontologias a realizao de
inferncias sobre estas ontologias presentes nos projetos, confrontando-as entre si e
com as ontologias organizacionais. Aqui, a partir de ontologias classificadas em um
105


determinado domnio e que pertencem a projetos que esto inseridos em um mesmo
contexto, procura-se identificar caractersticas (propriedades) semelhantes e a partir
destas inferir um conhecimento que possa ser generalizado ou instanciado. Para isso o
Engenheiro do Conhecimento poder consultar e apontar sobre uma lista de
inferncias, quais seriam vlidas. Isto caracteriza um processo semi-automtico, onde o
sistema identifica conhecimento que possa ser generalizado ou instanciado, no entanto
necessria a interveno do Engenheiro de Conhecimento a ser realizado no caso de
uso Sugerir Ontologias (figura 21).
O processo de inferncia dar-se-ia de duas formas de processamento, o
Morfolgico e o Semntico. O processamento Morfolgico baseia-se em identificar
palavras que podem ser agrupadas pela sua estrutura de formao, utilizando a
radicalizao. Atravs da radicalizao possvel identificar um radical comum para
palavras diferentes, comparando palavras que so parecidas e possuem uma estrutura
em comum. Assim, dentro de uma Ontologia pode-se apontar conceitos que so
semelhantes ou relacionados, onde por exemplo identificar-se-ia uma relao entre
Transporte e Transportadora.
No entanto, apenas o processamento Morfolgico no suficiente para
determinar relacionamento entre conceitos, para aumentar a eficcia desta inferncia,
deve-se aplicar tambm o processamento Semntico onde deve haver um trabalho do
Engenheiro de Conhecimento ao Classificar Ontologias identificando relacionamento
semntico entre palavras completamente distintas atravs da atribuio de uma
propriedade igual a, onde possa ser identificado um grupo de conceitos que
possuem um relacionamento dado pela mesma propriedade.
Alinhar Ontologias Classificar Ontologias
Engenheiro de
Conhecimento
Sugerir Ontologias

Figura 21 Alinhar Ontologias, Classificar Ontologias e Sugerir Ontologias.
106



Depois de criadas, as Ontologias passam a ser utilizadas e com esta utilizao
possvel avaliar critrios importantes sobre sua estrutura tais como importncia,
relevncia, completude e pertinncia. No entanto, as avaliaes sendo realizadas por
Gestores de Projeto, Analistas de Sistemas e de Negcio que esto inseridos em
ambientes distintos, podem sofrer distores relativas ao prprio ambiente, ou relativas
a situao e contexto do projeto e dos membros de equipe, assim para amenizar o
impacto destas distores pode ser usada a funcionalidade Atenuar Avaliao de
Ontologias (figura 22).
Atenuar Avaliao de Ontologias
Engenheiro de
Conhecimento
Manter Ontologias Especficas
<<extend>>

Figura 22 Atenuar Avaliao de Ontologias
medida que as Ontologias so utilizadas, consultadas, criadas e alteradas
importante que sejam coletadas mtricas que determinem a volatilidade e idade das
Ontologias, por exemplo. Com base nestas mtricas podero ser feitas consultas para a
identificao de possveis padres de informao e conhecimento, levando a um melhor
controle e entendimento sobre os requisitos. Para contemplar estas duas necessidades,
tm-se as funcionalidades de Registrar Mtricas de Ontologias (figura 23) e Consultar
Dados Sumarizados sobre Ontologias (figura 24). Ainda, com base nas informaes
coletadas possvel tambm realizar a avaliao de Ontologias referentes a requisitos
entre diferentes projetos, dando o enfoque sobre a complexidade dos requisitos e a
complexidade das prprias Ontologias na funcionalidade Consultar Dados de
Estimativas sobre Ontologias (figura 24).
107


Registrar Mtricas de Ontologias
Manter Ontologias Gerais
<<include>>
Alinhar Ontologias
<<include>>
Registrar Unificao/Desdobramento
de Ontologias
<<include>>
Classificar Ontologias
<<include>>
Engenheiro de Conhecimento
Atenuar Avaliao de Ontologias
<<include>>
Registrar Encaminhamento de
Ontologias
<<include>>
Analista de Sistemas

Figura 23 Registrar Mtricas de Ontologias

Consultar Dados de Estimativas
sobre Ontologias
Gestor de Projeto
Consultar Dados Sumarizados
Sobre Ontologias
Engenheiro de
Conhecimento

Figura 24 Consultar Dados Sumarizados Sobre Ontologias e Consultar Dados de Estimativas Sobre
Ontologias

Para melhor contextualizar as Ontologias e requisitos associados a elas
importante que se tenha no sistema a manuteno de dados dos projetos distribudos e
108


seus respectivos contextos. Ento se deve informar os tipos de projetos,
caracterizando-os em relao a distribuio e manuteno ou criao de novas
solues. Tambm se deve informar o contexto dos projetos determinando o domnio
de conhecimento relacionado s Ontologias e requisitos sendo abordados (transportes,
telefonia e consrcios, por exemplo). Tambm deve-se determinar os membros das
equipes de projeto e caractersticas especificadas, mantendo as informaes dos
projetos em si e tambm mantendo as informaes dos clientes associados a estes
projetos. Portanto, incluem-se as funcionalidades de Manter Projetos, Manter Tipos
de Projetos, Manter Contexto de Projetos e Manter Clientes (figura 25).
Manter Contexto de Projetos
Manter Clientes
Administrador
Manter Tipos de Projetos
Engenheiro de
Conhecimento
Manter Projetos

Figura 25 Manter Clientes, Manter Projetos, Manter Tipos de Projetos e Manter Contexto de Projetos.
Sabendo que ambientes de Gesto de Conhecimento devem ser colaborativos e
necessitam da interao entre os usurios e destes com a ferramenta sendo utilizada
ento se disponibiliza uma funcionalidade na qual os usurios comuns podem submeter
ao Engenheiro de Conhecimento as suas sugestes de criao ou complementao de
Ontologias, para que se tenha uma base de Conhecimento construda a partir das
experincias de todos, envolvendo-os mais ainda no processo de trabalho de
Engenharia de Requisitos, esta funcionalidade chama-se Registrar Encaminhamento
de Ontologias (figura 26). Atravs desta funcionalidade e dos logs do sistema, pode-se
observar qual a participao e interesse dos usurios, avaliando a utilizao e
contribuio dos mesmos sobre a base de Conhecimento da organizao na
funcionalidade Consultar Participao e Interesse dos Usurios (figura 26).
109


Gestor de Projeto
Consultar participao e interesse
dos usurios
Engenheiro de
Conhecimento
Analista de
Negcio
Analista de
Sistemas
Manter Ontologias Especficas
Registrar Encaminhamento de
Ontologias
<<extend>>

Figura 26 Manter Clientes, Manter Projetos, Manter Tipos de Projetos ,Manter Contexto de Projetos e
Consultar Participao e Interesse dos usurios.
Para acompanhar a evoluo e alterao das Ontologias ao longo do ciclo de
vida dos projetos e ao longo de sua existncia e utilizao na organizao, mapeia-se
no somente sua criao e alterao, mas faz parte da manuteno das mesmas a
unificao e desdobramento de Ontologias, onde uma ontologia pode ser substituda
por duas ou mais novas ontologias, ou que duas ou mais ontologias possam ser
unificadas em uma s pela funcionalidade de Registrar unificao e desdobramento de
Ontologias (figura 27). A partir de todas estas operaes ento se pode consultar por
Consultar histrico de Evoluo de Ontologias (figura 27) a evoluo das ontologias
baseando-se em dados coletados de mtricas, suas alteraes e informaes de
unificao e desdobramento.
Registrar Unificao/Desdobramento
de Ontologias
Engenheiro de
Conhecimento
Consultar Histrico de Evoluo de
Ontologias

Figura 27 Registrar unificao e desdobramento de Ontologias e Consultar Histrico de Evoluo de
Ontologias
110


Por fim, para que seja um sistema completo importante que existam mdulos
de administrao onde seja possvel manter grupos e seus respectivos usurios (figura
28), que estes usurios possam realizar a autenticao no sistema e acessar as
funcionalidades especficas disponibilizadas para seus grupos de acesso e que as
operaes do sistema possam ser posteriormente supervisionadas atravs da gerao
de um Log dessas operaes. Tambm importante disponibilizar um controle
administrativo para que seja possvel configurar informaes fundamentais para o
funcionamento do sistema, tais como ativar e desativar a gerao de LOG, editar
endereo de servidor de email e de banco de dados.
Manter Dados da Organizao
Manter Usurios
Manter Grupos de Usurios
Administrador
Registrar Login
Usurio

Figura 28 Controle Administrativo e Autenticao

Estas operaes se daro pelas funcionalidades de Manter Usurios, Manter
Grupos de Acesso, Registrar Login e Registrar Log de Sistema (figura 28). Tambm
lembrando da realidade e dados de configurao relevantes para a organizao, tais
como emails administrativos, valores de atenuao baseados na experincia
organizacional e no processo de desenvolvimento obtm-se a funcionalidade de
Manter Dados da Organizao.
Aqui, importante tambm que alm da funcionalidade individualmente
explicada, entendam-se as transaes. Por isso na figura 29, mostra-se as
transformaes que podem ocorrer com uma Ontologia. Estas transformaes so
armazenadas de modo que num segundo momento possa-se acompanhar o histrico
de evoluo de uma Ontologia, representando as mudanas relacionadas ao
111


conhecimento da Organizao e dos Projetos. Na figura 29, mostra-se o exemplo onde
uma Ontologia foi desdobrada em duas outras novas Ontologias, e ainda, cada uma
destas novas Ontologias sofreu alteraes diferentes. Uma das Ontologias (Ontologia
2) foi avaliada pelos usurios e aps esta avaliao o Engenheiro do Conhecimento
realizou a atenuao desta avaliao seguindo os fatores atenuantes identificados para
a organizao (conforme definido em Aplicar Atenuao sobre Avaliao de
Ontologias). J a outra Ontologia (Ontologia 3), foi alinhada com a Ontologia 4 e
posteriormente alterada por um Engenheiro do Conhecimento, levando a uma nova
verso da Ontologia 3, com os dados resultantes do alinhamento e da alterao.
Ontologia 1
Ontologia 2 Ontologia 3
Desdobramento Desdobramento
Ontologia 4
Ontologia
3.1
Alinhamento
Alterao
Ontologia
2.1
Avaliar
Ontologia
2.2
Atenuar

Figura 29 Exemplo de Evoluo de Ontologia

Exemplificaram-se estas transaes para um melhor entendimento do
funcionamento do sistema, visto que as operaes em questo representam as que
sero mais utilizadas na ferramenta. No considerando a consulta s Ontologias, que
embora importante, no representa uma transao complexa.

112


8.4.1.2. Proposta de Modelo de Classes

Tendo definido o que deve ser feito, ento se deu seqncia ao trabalho com a
construo de um modelo de classes conceitual de alto nvel que dever ser aprimorado,
no qual j so identificadas as classes principais que sero implementadas e os
relacionamentos entre os objetos.
ConceitoEspecifico
nome
predecessor
projeto
ativo
descricao
propriedades []
arquivos []
requisitos []
getNome()
setNome()
getPredecessor()
setPredecessor()
getAtivo()
setAtivo()
getDescricao()
setDescricao()
getPropriedades []()
setPropriedades []()
getArquivos []()
setArquivos []()
getRequisitos []()
setRequisitos []()
0..n
1
0..n
1
Conceito
nome
predecessor
ativo
descricao
propriedades []
arquivos []
getNome()
setNome()
getPredecessor()
setPredecessor()
getAtivo()
setAtivo()
getDescricao()
setDescricao()
getPropriedades []()
setPropriedades []()
getArquivos []()
setArquivos[]()
incluiAlteraConceito()
excluiConceito()
1
0..n
1
0..n

Figura 30 Modelo Conceitual de Classes de Conceitos

Apontam-se como classes importantes as classes de Ontologias Gerais e
Especficas (figura 30), onde ambas esto relacionadas a tipos e contextos de projeto,
bem como relacionadas diretamente a projetos. Entendo que o simples relacionamento
de uma Ontologia a um Tipo de Projeto e Contexto, ajuda na identificao de quais
Ontologias sero utilizadas em um projeto que se inicia.
As Ontologias sero avaliadas pelos usurios atravs de funcionalidades da
ferramenta, para tal importante que se tenha mapeada a avaliao em si, seus
respectivos fatores atenuantes, se houver quais os itens (critrios) da avaliao e se foi
encaminhada alguma sugesto relativa a algum destes itens. Para cada Ontologia
113


podem-se associar arquivos em diferentes tipos de mdia para complementar o
significado de uma Ontologia, e estabelecer propriedades de relao entre Ontologias e
recursos sejam eles textos ou outras Ontologias.
ConceitoEspecifico
0..n
1
0..n
1
Propriedade
valor
ontologia : Conceito
getValor()
setValor()
getOntologia()
setOntologia()
incluiAlteraPropriedade()
excluiPropriedade()
Arquivo
nome
cArquivo
getNome()
setNome()
uploadArquivo()
downloadArquivo()
Tipo
nome
ativo
getNome()
setNome()
getAtivo()
setAtivo()
incluiAlteraTipo()
excluiTipo()
Contexto
nome
ativo
getNome()
setNome()
getAtivo()
setAtivo()
incluiAlteraContexto()
excluiContexto()
Requisito
nome
descricao
getNome()
setNome()
getDescricao()
setDescricao()
incluiAlteraRequisito()
excluiRequisito()
Projeto
nome
unidade
fase
situacao
getNome()
setNome()
getUnidade()
setUnidade()
getFase()
setFase()
getSituacao()
setSituacao()
incluiAlteraProjeto()
excluiProjeto()
1 1..n 1 1..n
1
1..n
1
1..n
0..n
1
0..n
1
0..n 1 0..n 1
Usuario
nome
login
senha
getNome()
setNome()
getLogin()
setLogin()
getSenha()
setSenha()
autentica()
incluiAlteraUsuario()
excluiUsuario()
0..n
0..n
0..n
0..n
FatorAtenuante
nome
percentual
getNome()
setNome()
getPercentual()
setPercentual()
atenuarConceito()
incluirAlteraFator()
excluiFator()
Avaliacao
nome
valor []
getNome()
setNome()
getValor()
setValor()
0..n
1
0..n
1
Conceito
0..n
1
0..n
1
0..n
1
0..n
1
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
1
0..n
1
0..1
1
0..1
1
Cliente
nome
ativo
getNome()
setNome()
getAtivo()
setAtivo()
incluiAlteraCliente()
excluiCliente()

Figura 31 Modelo Conceitual de Classes
No que se refere aos Projetos de desenvolvimento, sabe-se que cada projeto
ter um cliente e uma equipe, bem como ser classificado conforme os tipos e
contextos de projeto disponveis. Tambm cada projeto ter um conjunto de Ontologias
associadas aos seus requisitos, realizando a ligao entre o conhecimento da
Organizao e o conhecimento do Projeto. Todas estas informaes sobre as
114


Ontologias, suas extenses e os Projetos e seus Requisitos, est modelada no
diagrama conceitual de classes da figura 31.

8.4.1.3. Prottipo de Telas e Anlise de Ferramentas

Para melhor entender o processo proposto e tambm sugerir uma futura
elaborao de ferramenta de apoio a este processo foram avaliadas ferramentas de
desenvolvimento de software, primeiro as de mais baixo nvel tais como Net Beans,
Eclipse, Jena, Sql Developer, Toad, Tomcat, JBoss. Nas ferramentas de mais alto nvel
ou de nvel gerencial, foram avaliados o Rational Requisite Pro, Microsoft Project,
Rational Clearquest e Bugzilla.
Entre as ferramentas analisadas identificou-se que a plataforma de
desenvolvimento seria o Eclipse SDK 3.2, incorporando a plataforma Java SDK 5.0 ,
Servidor de Aplicao Tomcat e biblioteca para uso de RDF e OWL, Jena [JEN06]. O
Eclipse possibilita a integrao de diferentes ferramentas e bibliotecas de forma fcil e
acessvel, pois h plug-ins a serem utilizados para o controle de verso (CVS) e teste
unitrio (JUnit).
O Requisite Pro demonstra a aplicao prtica de matrizes de rastreabilidade,
que so facilitadores na identificao de possveis impactos ocorridos nas alteraes de
requisitos e seus respectivos conceitos, pois ao alterar um documento so
apresentados como suspeitos os documentos a ele relacionados. Por sua vez, o
Clearquest e Bugzilla destacam o acompanhamento de atividades, mudanas,
melhorias e defeitos, desde seu cadastro at o seu encerramento, garantindo maior
controle sobre o que realizado no projeto, por quem e quando.
As ferramentas aqui citadas foram estudadas a fim de entender as possibilidades
de integrao futura com ferramentas de mercado, a fim de facilitar o trabalho realizado
nas organizaes e manter a consistncia entre diferentes aplicaes que envolvam a
manuteno de requisitos.
Os prottipos de telas partiram das especificaes funcionais citadas
anteriormente que foram criadas a partir do estudo de caso, do ambiente e processo
definido e da base terica. Este prottipo disponibilizado em formato HTML j pronto
para adequar-se a WEB Semntica caso sejam utilizados os padres RDF e OWL.
115




Figura 32 Tela de Manuteno de Conceitos Especficos

Depois de definidas as telas bsicas, partiu-se ento para as telas de
funcionalidades relacionadas diretamente com o objetivo do trabalho, prototipando os
cadastros bsicos num primeiro momento. Depois foram construdas as telas de
funcionalidades ligadas a Conceitos tais como a manuteno de Conceitos Especficos
(Figura 32), Consulta de Dados Sumarizados sobre Conceitos (Figura 33) e a
Atenuao da Avaliao de Conceitos (Figura 34).



Figura 33 Tela de Consulta de Dados Sumarizados sobre Conceitos
116




Figura 34 Tela de Atenuao sobre a Avaliao de Conceitos


117


REFERNCIAS

[AHN02] AHN, Jae-Hyeon & Chang, Suk-Gown. Valuation of Knowledge: A
Business Performance-Oriented Methodology. In: Proceedings of the 35
th
Hawaii
International Conference on System Sciences, 2002, pp. 2619-2626.

[ALM05] ALMEIDA, Maurcio B; MOURA, Maria A. Uma Iniciativa Interinstitucional
para construo de Ontologia sobre Cincia da Informao: Viso Geral do Projeto
P.O.I.S. Revista Eletrnica de Biblioteconomia e Cincia da Informao, vol. 19,
Setembro 2005, pp.53-72.

[AUD04] AUDY, Jorge; ANDRADE, Gilberto; CIDRAL, Alexandre. Fundamentos
de Sistemas de Informao. Bookman, 2005, 208p.

[AWA03] AWAD, Elias M; GHAZIRI, Hassan. Knowledge Management. Pearson
Prentice Hal, 2003, 456p.

[BAE05] BAETS, Walter. Extending the Horizons of Knowledge-Based
Management.Springer Science and Business Media, 2005, 393p.

[BRE03a] BREITMAN, K.K; Leite, J.C.S.P. Lexicon Based Ontology Construction.
Software engineering for multi-agent systems II: research issues and practical
applications, vol. 2940, Novembro 2003, pp. 19-34.

[BRE03b] BREITMAN, K. Anais do WER03 Gerao de Ontologias Subsidiada
pela Engenharia de Requisitos In: Workshop em Engenharia de Requisitos, 2003,
pp.255-269.

[BRE05] BREITMAN, Karin. Web Semntica: a internet do futuro. LTC, 2005,
212p.

118


[BER98] BERRY, Daniel; LAWRENCE, Brian. Guest Editors Introduction
Requirements Engineering. IEEE Software, California, vol. 15-2, Marco 1998, pp. 26-29.

[CAR99] CARMEL, Erran. Global Software Teams Collaborating Across Borders
and Time Zones. Prentice Hall, 1999, 269 p.

[CHA99] CHAUVEL, D; DESPRES, C. Knowledge management(s). Journal of
knowledge Management. v. 3-2, Junho 1999, pp. 110-120.

[CMM06] Software Engineering Institute, CMMI for Systems Engineering and
Software Engineering V1.2, Staged Representation. Capturado em:
http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf, Dezembro 2006.

[DAM03] DAMIAN, Daniela. An Exploratory Study of Facilitation in Distributed
Requirements Engineering. Requirements Engineering Journal, vol. 8-1, Agosto 2003,
pp. 23-41.

[DAM05] DAMIAN, Daniela. Studies in Distributed Software Requirements
Engineering. Capturado em:
http://sern.ucalgary.ca/KSI/KAW/KAW99/papers/Damian2/Damian_et_al.pdf, Outubro
2005.

[DAV95] DAVIS, Alan. Tracing: A Simple Necessity Neglected. IEEE Software,
vol. 12-5, Dezembro 1995, pp. 6-7.

[DAV98] DAVENPORT, T. H.; KLAHR, P. Managing customer support
knowledge. California Management Review. vol. 40-3, Maio 1998, pp. 195-208.

[DES03] De Souza, Kevin.C. (2003a). Barriers to effective use of knowledge
management systems in software engineering. Communications of the ACM, vol. 46-1,
Outubro 2003, pp. 99-101.
119



[EGY04] EGYED, Alexander; Barry Boehm. Software Requirements Negotiation:
Some Lessons Learned. In: 20
th
International Conference on Software Engineering,
1998, pp. 503-506.

[ESP04] ESPINDOLA, Rodrigo; MAJDENBAUM, Azriel. Uma Anlise Crtica dos
Desafios para Engenharia de Requisitos em Manuteno de Software. In: VII
Workshop on Requirements Engineering, 2004, pp. 226-238.

[ESP05] ESPINDOLA, Rodrigo; PRICKLADNICKI, Rafael. Uma Abordagem
Baseada em Gesto do Conhecimento para Gerncia de Requisitos em
Desenvolvimento Distribudo de Software. In: VIII Workshop on Requirements
Engineering, 205, pp. 87-89.

[EVA00] EVARISTO, Roberto; SCUDDER, Richard. Geographically distributed
project teams: a dimensional analysis. In: Proceedings of the 33th Hawaii International
Conference on System Sciences, 2000, pp. 7052-7060.

[EVA03] EVARISTO, Roberto; DESOUZA, Kevin C.; Global Knowledge
Management Strategies. European Management Journal, vol. 21-1, Setembro 2003,
pp. 62-67.

[FER04] FERNANDEZ, Irma Becerra; GONZALEZ, Avelino; SABHERWAL, Rajiv.
Knowledge Management: Chalenges, Solutions, and Technologies. Pearson Prentice
Hall, 2004, 386p.

[FIR02] FIRESTONE, Joseph; MCELROY, Mark. Generations of Knowledge
Management. White Paper on Executive Information Systems, Inc. Wilmington, 2002,
51p.

120


[FUT06] FUTAMI, Andr; VALENTINA, Luiz; POSSAMAI, Osmar. Um Modelo de
Gesto do Conhecimento para a Melhoria de Qualidade do Produto. Centro
Tecnolgico, Universidade Federal de Santa Catarina. Abril, 2006. Capturado em:
www.ctc.ufsc.br/produto/Produto2/pdfs/AndreFutami.pdf , Abril 2006.

[GOG96] GOGUEN, Joseph. Formality and Informality in Requirements
Engineering. In: Proceedings of Second International Conference on Requirements
Engineering, 1996, pp. 102-109.

[GRU93] GRUBER, T.R. Towards Principles for the Design of Ontologies Used for
Knowledge Sharing. International Journal of Human and Computer Studies, vol. 43,
Julho 1993, pp. 907-928.

[GUA96] GUARINO, Nicola; GIARETTA, Pierdaniele. Towards Very Large
Knowledge Bases: Knowledge Building and Knowledge Sharing, NL. IOS Press, 1996,
pp. 25-32.

[GUA98] GUARINO, Nicola. Formal Ontology and Information Systems. In:
Proceedings of FOIS98, 1998, pp. 3-15.

[HIL99] HILDRETH, Paul; WRIGHT, Peter; KIMBLE, Chris. Knowledge
Management: Are we missing something?. In: Proceedings of the 4
th
UKAIS
Conferente, 1999, pp. 347-435.

[HMU99] Harvard Management Update. Do we know how to do that?. Harvard
Business Online, vol.4-2, Abril 1999, pp. 1-4.

[ISO05] ISO - International Organization for Standardization. ISO/IEC 15504
(SPICE). Capturado em : http://www.iso.org/, Outubro 2005.

121


[JAR99] JARVENPAA, Sirkka L. and Dorothy E. Leidner. Communication and
Trust in Global Virtual Teams. Organization Science, vol. 10-6, Outubro 1999, pp. 791-
815.

[JAV06] Java technology. Sun Microsystems, Inc. Janeiro,2006. Capturado em:
http://java.sun.com/docs/books/tutorial/, Maio 2006.

[JEN06] Jena Semantic Web Framework. A Semantic Web Framework for Java.
Maio, 2006. Capturado em: http://jena.sourceforge.net/, Junho 2006.

[JON05] JONES, Dean. Methodologies for Ontology Development. Novembro,
2005. Capturado em http://www.iet.com/Projects/RKF/SME/methodologies-for-ontology-
development.pdf, Novembro 2005.

[KAI05] KAIYA, Haruhiko; SAEKI, Motoshi. Ontology Based Requirements
Analysis: Lightweight Semantic Processing Approach. In: Proceedings of the Fifth
International Conference on Quality Software, 2005, pp. 223-230.

[KIS04] KISHORE, RAJIV; ZHANG, HONG; RAMESH, R. A Helix-Spindle Model
for Ontological Engineering. Communications of the ACM, vol. 47-2, Maio 2004, pp. 32-
41.

[KOT98] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering:
Process and Techniques. John Wiley, 1998, 294 p.

[LOP99] LOPEZ, Mariano Fernandez. Overview of Methodologies for building
Ontologies. In: Proceedings of the IJCAI-99 Workshop on Ontologies and Problem-
Solving Methods, 1999, pp. 4.1-4.13.

122


[LOP04] LOPES, L. Um Modelo de Processo de Engenharia de Requisitos para
Ambientes de Desenvolvimento Distribudo de Software. Dissertao de Mestrado,
Programa de Ps-Graduao em Cincia da Computao, PUCRS, 2004, 138p.

[MAE00] MAEDCHE A.; STAAB, S.: The Text-To-Onto Ontology Learning
Environment. In: Eight International Conference on Conceptual Structures, 2000, pp.
14-18.

[MAL00] MALHOTRA, Yogesh. Knowledge Management for E-Business
Performance: Advancing Information Strategy to Internet Time. Information Strategy:
The Executive's Journal. vol. 16-4, Abril 2000, pp. 5-16.

[MPS06] MPS-BR, Melhoria de Processo Brasileiro de Software, Guia Geral
verso 1.1. Sociedade Brasileira para Promoo da Exportao de Software - Sofftex.
Capturado em: http://www.softex.br/mpsbr/_guias/MPS.BR_Guia_Geral_V1.1.pdf,
Fevereiro 2006.

[NGU05] NGUYEN, Phong T.; VERNER, June M. Trust in Software Outsourcing
Relationships: An Analysis of Vietnamese Practitioners Views. Capturado em:
http://www.bcs.org/upload/pdf/ewic_ea06_paper2.pdf, Setembro 2005.

[NIS06] NISSEN, Mark E. A Framework for Integrating Knowledge Process and
System Design. Capturado em: http://web.nps.navy.mil/~menissen/papers/NPS-PM-
05-007.pdf, Janeiro 2006.

[NON94] NONAKA, Ikujiro. A dynamic theory of Organizational Knowledge
Creation. Organization Science journal, vol. 5-1, Junho 1994, pp. 14-37.

[PRE01] PRESSMAN, Roger S. Software Engineering: a Practioners Approach.
McGraw Hill, 2001, 860p.

123


[PRI06a] PRIKLADNICKI, Rafael ; AUDY, Jorge Luis Nicolas ; DAMIAN, Daniela .
Offshore Sourcing of Software Development Projects: Towards a Maturity Model
Proposal for Offshore Insourcing. Capturado em:
http://www.sbl.tkk.fi/idoese/IDoESE_Prikladnicki_final1.pdf, Agosto 2006.

[PRI06b] PRIKLADNICKI, Rafael ; AUDY, Jorge Luis Nicolas ; EVARISTO,
Roberto. A Reference Model for Global Software Development: Findings from a Case
Study. In: ICGSE - IEEE International Conference on Global Software Engineering,
2006, pp. 18-25.

[ROS97] ROSSON, Mary Beth; CHIN JR., George. Participatory Analysis: Shared
Development of Requiments from Scenarios. In: Proceedings of Human Factors in
Computing Systems, 1997, pp. 162-169.

[RUP98] The Rational Unified Process. Software Development Book for Rational
Method Composer v 7.0, 1998, 238p.

[SAL03] SALVIANO, Clnio S.; SILVA, Odair Jacinto da; BORGES, Carlos Alberto.
Aplicao da ISSO/IEC TR 15504 na Melhoria do Processo de Desenvolvimento de
Software de uma Pequena Empresa. In: V Simpsio Internacional de Melhoria de
Processo de Software, 2003, pp.41-52.

[SAY05] SAYO, Miriam; LEITE, Jlio Cesar S.P. Uso de Agentes no Processo
de Requisitos em Ambientes Distribudos de Desenvolvimento. In: WER05 - Workshop
em Engenharia de Requisitos, 2005, pp.135-147.

[SIL06] SILVA, Sergio Luis da. Gesto do Conhecimento: uma reviso crtica
orientada pela abordagem da criao do conhecimento. Capturado em:
www.ibict.br/cienciadainformacao/include/getdoc.php?id=1095&article=461&mode=pdf,
Fevereiro 2006.

124


[SOM97] SOMMERVILLE, Ian; SAWYER, Peter. Requirements Engineering A
Good Practice Guide. John Wiley, 1997, 404p.

[STA06] STAAB, S.; STUDER, R. and SURE, Y. Methodology for Development
and Employment of Ontology based Knowledge Management Applications, Capturado
em: www.aifb.uni-karlsruhe.de/WBS/ysu/publications/2002_sigmod-methodology.pdf,
Maio 2006.

[THA00] THAYER, Richard; DORFMAN, Merlin. System and Software
Requirements Engineering Second Edition. IEEE Computer Press Tutorial, 2000, 528
p.

[TRU05] TerraForum - Gesto do Conhecimento e Portais Corporativos.
Understanding the difference between information management and knowledge
management. Capturado em :
http://www.terraforum.com.br/lib/pages/viewdoc.php?from=map&l_intDocCod=13,
Dezembro 2005.

[VAL05] VALENTIM, Marta L.P.; GELINSKI Joo V.V. Gesto do Conhecimento
como parte do processo de inteligncia competitiva organizacional. Capturado em:
http://www.sgmf.pt/NR/rdonlyres/E407561C-1096-4B93-80DA-
0F25F8D2C3D0/2801/gestodoconhecimentovantagemcompetititva.pdf, Novembro
2005.

[VAS03] VASCONCELOS, Karine. OntoEditor: Um editor para manipular
ontologias na WEB. Dissertao de Mestrado, Programa de Ps-Graduao em
Informtica, Universidade Federal de Campina Grande, 2003, 124p.

[W3C05] World Wide Web Consortium. Capturado em: http://www.w3c.org,
Outubro 2005.

125


[WAR04] WARD, James; AURUM, Aybke. Knowledge Management in Software
Engineering Describing the Process. In: Proceedings of the 2004 Australian Software
Engineering Conference, 2004, pp.137-142.

[WIK05] Wikipdia- A enciclopdia livre. Dicionrio de Dados. Capturado em :
http://pt.wikipedia.org/wiki/Dicion%C3%A1rio_de_Dados, Julho 2005.

[YIN06] Yin, Robert K. Estudo de caso : planejamento e mtodos,
Bookman, 2006, 212p.

[ZAV97] ZAVE, Pamela. Classification of Research Efforts in Requirements
Engineering. ACM Computing Surveys, vol. 29-4, Maio 1997, pp.315-321.


126


APNDICE A ESTUDO DE CASO

Protocolo para Estudo de Caso: Identificao de caractersticas relativas
Engenharia de Requisitos e Gesto do Conhecimento em organizaes de
desenvolvimento de software que atuam em ambientes DDS

Objetivo
Identificar as caractersticas relativas Engenharia de Requisitos e Gesto do Conhecimento em
organizaes de desenvolvimento de software que atuam em ambientes DDS.

Questo de pesquisa
Como utilizar ontologias para suportar a Engenharia de Requisitos em ambientes de Desenvolvimento
Distribudo de Software?.

Unidade de estudo
Organizaes de desenvolvimento distribudo de software.

Caracterstica-chave do mtodo de estudo de caso
Este um roteiro para o desenvolvimento e aplicao de um instrumento de pesquisa semi-estruturada
com questes fechadas, abertas e em escala Lickert que se caracteriza como uma pesquisa do tipo
transeccional. O objetivo identificar caractersticas de organizaes de DDS.

Organizao desse Protocolo
O protocolo ser organizado com o segue:

1. Procedimentos

A. Levantamento das questes e estruturao do guia para a entrevista
Participantes: Ricardo Angrisani
Local: N/A
Datas: De 13/08/2006 a 20/08/2006

B. Reunies para reviso do guia para a entrevista
Participantes: Jorge Luis Nicolas Audy. Doutor em Sistemas de Informao UFRGS -
2001 (Especialista, Pesquisador Snior)

Local: Pr Reitoria de Pesquisa e Ps Graduao da PUCRS (Jorge)
Revises
Datas: 13/08/2006

C. Validao de Face e Contedo
Participantes: Rodrigo Espindola
127


Local: PUCRS
Data: 20/08/2006
D. Pr-teste
Participantes:
Caroline Carbonell Cintra
Local: Porto Alerge, Tecnopuc, DBServer Assessoria em Sistemas de Informao
Data: 25/08/2006


2. Escolha dos Participantes

Relao respondentes x dimenses
Respondentes
Dimenses
1 2 3 4 5
Gestor de Projeto X X X X X
Analista de Sistemas
X X X X X
Analista de Negcio
X X X X X

3. Outros recursos utilizados
A. Recursos materiais
Sistema de gerenciamento de e-mails para envio e recebimento das
entrevistas;
Microcomputador com Windows XP e Microsoft Excel para anlise de dados.

4. Modelo do estudo e Dimenses da Pesquisa

O esquema a seguir representa graficamente os principais aspectos enfocados no
desenvolvimento deste trabalho.
Organizaes de Desenvolvimento
Distribudo de Software
Aspectos
Tcnicos
Aspectos
Organizacionais
Aspectos
Sociais
Comunicao
Cultura
Confiana
Gesto de
Conhecimento
Alocao de
Recursos em
Projeto
Metodologia de
Desenvolvimento
Recursos Distribuio das
Operaes
Referenciais
Estratgicos
Projeto de
Desenvolvimento

Figura 1 - Aspectos enfocados no trabalho

5. Anlise de dados
128



A anlise de dados utilizar a tcnica de anlise de contedo [YIN01] e para tabulao dos
dados coletados pretende-se utilizar o mdulo estatstico, realizado atravs do Excel. A coleta
de dados envolve fontes primrias (resultado da aplicao do instrumento) e fontes secundrias
(documentao e registros de arquivos). A triangulao dos dados coletados permitir maior
confiabilidade nos resultados obtidos. Esta entrevista insere-se em uma pesquisa de base
qualitativa, exploratria, sendo o estudo de caso o principal mtodo de pesquisa, aplicado
conforme proposto por [YIN01].

6. Dimenses e questes do guia para entrevista

Dimenso 1 Dados Demogrficos (Todos)
Indivduo
1. Qual seu nome?
2. Qual sua idade?
Escolaridade
3. Informe sua escolaridade (maior):

( ) 1 Grau ( ) Superior Completo () Mestrado Completo
( ) 2 Grau ( ) Especializao ( ) MBA Incompleto
( ) Superior Inc. ( ) Mestrado Incompleto ( ) MBA Completo

4. Ano de concluso (ltimo curso): 2006
Experincia
5. Tempo de experincia profissional na rea de informtica:
6. Tempo de experincia profissional trabalhando em organizaes de desenvolvimento
distribudo de software

7. Qual o seu conhecimento sobre o desenvolvimento distribudo de software?
Nenhum Pouco J ouviu falar Conhece Conhece bem
Relacionamento
com a Empresa
8. Tempo de empresa:
9. Funo: Gestor de Projeto Analista de Sistemas Analista de Negcio

Dimenso 2 Aspectos Organizacionais
Referenciais
Estratgicos
[KHA03a],
[NOL79]
10. Qual a misso e negcio da empresa?
11. Qual a estratgia da empresa em relao ao desenvolvimento distribudo de software?

Recursos
[CAR02], [SHA03]
12. Nmero de pessoas (aproximado) trabalhando atualmente na corporao, na rea de
Tecnologia de informao (desenvolvimento ou manuteno de software):

Distribuio das
Operaes
[KIS03], [EVA03],
[SHA03]
13. Onde se localizam as equipes (desenvolvimento, anlise de negcio, anlise de sistema,
gerncia de projeto) que atendem os clientes que utilizaro os softwares gerados pela
empresa?
Dimenso 3 Aspectos Sociais
Caracterizam-se como aspectos sociais as dimenses envolvidas na organizao que permeiam todo e qualquer
tipo de trabalho.
129


Comunicao
[CAR99]
1. Existe comunicao direta (face a face) freqente entre a(s) equipe(s) da empresa e o
cliente para a definio de requisitos? Caso afirmativo, qual a freqncia (ms)?

2. Preencha abaixo (marcando uma ou mais opes) com as iniciais dos meios de
comunicao utilizados entre as equipes distribudas (do cliente e/ou da empresa).
Considere que a comunicao interna (Ex: Cliente x Cliente) tambm relevante. Caso
existam outras formas de comunicao, descreva-as textualmente:

(C) Correspondncia
(Ce) Correio eletrnico
(F) Fax
(Cv) Correio de voz
(Ch) Chat eletrnico
(Ba) Broadcast de udio em sentido nico
(Bv) Broadcast de vdeo em sentido nico
(T) Telefone
(V) Videoconferncia
(Rv) Reunio em realidade virtual
(Rf) Reunio face a face
Outra(s):

Cliente Equipe de
Desenvolvimento
Equipe
de
Anlise
de
Sistemas
Equipe
de
Anlise
de
Negcio
Gerncia
de Projeto
Cliente
Equipe de
Desenvolvimento

Equipe de
Anlise de
Sistemas

Equipe de
Anlise de
Negcio

Gerncia de
Projeto



3. Existe um protocolo/padro nico definido na empresa, que oriente quais procedimentos
(utilizao, documentao, etc) devem ser realizados para cada meio de comunicao entre
as equipes distribudas?
No Sim
Qual?


4. Qual o nvel de interao entre as equipes distribudas e o cliente? Preencha abaixo com
as iniciais do nvel de interao entre as equipes distribudas:
(I)ntensa
(F)reqente
(N)ormal
(R)egular
(Ra)ra

130


Cliente Equipe de
Desenvolvimento
Equipe
de
Anlise
de
Sistemas
Equipe
de
Anlise
de
Negcio
Gerncia
de
Projeto
Cliente
Equipe de
Desenvolvimento

Equipe de
Anlise de
Sistemas

Equipe de
Anlise de
Negcio

Gerncia de
Projeto



5. Existem atividades de integrao entre as equipes distribudas e o cliente? Em caso
afirmativo, preencha a matriz com as iniciais do tipo de interao entre as equipes
distribudas (marcando uma ou mais opes):


(Tf) Trabalho conjunto fulltime
(Tp) Trabalho conjunto part time
(Rm) Reunies mensais
(Rs) Reunies semanais
(Rd) Reunies dirias
(Rc) Reunies no regulares, definidas em cronograma
(In) Interao no programada

Cliente Equipe de
Desenvolvi
mento
Equipe de
Anlise de
Sistemas
Equipe de
Anlise de
Negcio
Gerncia
de
Projeto
Cliente
Equipe de
Desenvolvimento

Equipe de
Anlise de
Sistemas

Equipe de
Anlise de
Negcio

Gerncia de
Projeto



6. Existem mecanismos para formalizao e distribuio do conhecimento referente a
Requisitos?
No Sim
Quais?

7. Que equipes utilizam estes mecanismos para formalizao e distribuio do
conhecimento referente a Requisitos?

131


8. Existem treinamentos formais para a utilizao dos meios de comunicao? Como eles
so apresentados para os participantes?

9. Em sua opinio, a existncia de ferramentas (net meeting; softwares para conferencia
virtual; etc) que auxiliem a comunicao fundamental para minimizar rudos entre as
equipes distribudas.
Discordo totalmente Concordo Totalmente

10. Existem dificuldades de entendimento de conceitos ou requisitos entre a equipe e o
cliente? Quais?
Cultural
Comunicao e Idioma
Confiana
Outra(s):

11. Quando ocorrem mais frequentemente as dificuldades de entendimento de conceitos ou
requisitos entre a equipe e o cliente?
Anlise de Negcio
Anlise de Sistema
Outra(s):

Cultura
[EVA03], [CAR99]

12. Descreva o que voc considera fatores culturais chave na sua organizao
(personalidade, criatividade, etc).

13. Como os fatores citados na questo anterior so afetados pela influncia do cliente
(interno ou externo) na empresa?

14. Em sua opinio, a empresa deve fornecer treinamento para as equipes distribudas a
respeito das culturas presentes na organizao e no cliente.
Discordo totalmente Concordo Totalmente

Confiana
[SAB99], [WHI94]
15. Em sua opinio, o cliente (interno ou externo) demonstra confiana no trabalho da
empresa?

Sim
No, nosso histrico de projetos ainda no grande o suficiente.
No, h problemas de alinhamento entre as equipes.
No, h outros problemas de confiana. Quais?

16. A empresa (ou a diviso em que voc trabalha) propicia freqentemente oportunidades
para a integrao (presencial) entre os funcionrios e o cliente? No Sim

17. Em minha opinio, eu no deixaria que outros membros da equipe tivessem influncia
sobre problemas importantes ao projeto.
Discordo totalmente Concordo Totalmente

18. Em minha opinio, estaria confortvel em entregar para outro membro do time, se ele
estivesse preparado, a completa responsabilidade do projeto.
Discordo totalmente Concordo Totalmente


132



Dimenso 4 Aspectos Tcnicos
Caracterizam-se como aspectos tcnicos as dimenses envolvidas na construo do produto. Todo e qualquer
trabalho que envolva pessoal altamente treinado e especializado em processos de engenharia e concepo de
produto.
Gesto de
Conhecimento
[EVA03]
1. Existe uma base de dados com informaes sobre requisitos disponvel na empresa?
No Sim

a) Esta base de dados utilizada toda a vez que se inicia um novo projeto de
desenvolvimento? No Sim

2. A gesto de conhecimento uma funo formalmente definida na empresa? No
Sim

3. Existe alguma atividade ou processo para divulgar informaes entre as equipes e o
cliente que auxiliem em resoluo mais precisa ou veloz de problemas?
No Sim

4. Existe alguma forma de resoluo de ambigidades na comunicao entre equipes e
cliente?
No Sim -Quais?


5. Existe alguma forma de resoluo de conflitos na comunicao entre equipes e
cliente no que se refere aos requisitos?
No Sim -Quais?

6. Existe alguma forma de divulgao para definies, que so de entendimento
comum, entre equipes distribudas e cliente no que se refere aos requisitos?
No Sim Quais?

133


Projeto de
Desenvolvimento
[EVA03], [YEO01]
7. Quais os tipos de desenvolvimento de software existentes na empresa?
Manuteno de Software
Desenvolvimento Completo de Novas Solues

8. Em sua opinio, o processo de desenvolvimento de software compreendido pelo
cliente?
No Sim

9. Qual o modelo de gesto de requisitos utilizado na empresa? CMMI (REQ-M)
Outros Quais?

10. O padro de gesto de requisitos o mesmo utilizado por todas equipes da
empresa? No Sim

11. Existe um processo organizacional padronizado e formalizado entre a empresa (ou
a diviso em que voc trabalha) e o cliente para a engenharia de requisitos? Qual?

12. importante a existncia de mecanismos de gesto do conhecimento na empresa.
Discordo totalmente Concordo Totalmente

13. Deve existir uma base comum de dados entre a empresa e o cliente, de modo que
elas possam trocar experincias sobre determinado problema, bem como compartilhar
aprendizados em relao engenharia de requisitos.
Discordo totalmente Concordo Totalmente


CONCEITO DE ONTOLOGIA
Ontologia
Uma ontologia uma descrio formal de conceitos e relaes que existem em um domnio
de interesse. Basicamente, uma ontologia consiste desses conceitos e relaes, e suas
definies, propriedades e restries.
Ontologias so teis para apoiar a especificao e implementao de qualquer sistema de
computao complexo. Ajudando as pessoas a compreender melhor certa rea de
conhecimento e a atingir um consenso no seu entendimento sobre uma rea de
conhecimento.


Dimenso 5 Questes Gerais
Vantagens
1. Cite quais so, em sua opinio, as principais vantagens da formalizao do
conhecimento (em ontologias) para com relao a Engenharia de Requisitos no
desenvolvimento distribudo de software.

Desvantagens
2 . Cite quais so, em sua opinio, as principais desvantagens que poderia-se ter na
formalizao do conhecimento (em ontologias) para com relao a Engenharia de
Requisitos no desenvolvimento distribudo de software.

Ferramentas de
apoio
3. No que, em sua opinio, uma ferramenta de Gesto de Conhecimento poderia auxiliar a
resolver os conflitos na engenharia de requisitos?
4. Que caractersticas essa ferramenta deveria possuir?


134


Anexo 2 Questes Tabuladas

Dimenso 3 Aspectos Sociais
Sim No
1. Existe comunicao direta (face a face) freqente
entre a(s) equipe(s) da empresa e o cliente para a
definio de requisitos?

9 3
Caso afirmativo, qual a freqncia (ms)? Freqncia mdia de 3,2 reunies
por semana;

2. Comunicaes entre equipes
Equipes Mecanismo de Comunicao
Desenvolvimento-Cliente Ce 4, Ch 4, T 2
Anlise de Sistemas-Cliente Rf 4, T 12, Ch 12, Ce 12
Anlise de Negcio-Cliente Rf 10, T 12, Ch 12, Ce 12 , V 6
Gerncia de Projeto-Cliente Rf 2, T 12, Ch 12, Ce 12 , V 2 , F 1
Anlise de Sistemas-Desenvolvimento Rf 12, Ch 7, Ce 10, T 3
Anlise de Negcio-Desenvolvimento Rf 5, Ch 7, Ce 9, T 5
Gerncia de Projeto-Desenvolvimento Rf 12, Ch 12, Ce 12
Anlise de Negcio-Anlise de Sistemas Rf 12, Ch 12, Ce 12, T 8
Gerncia de Projeto-Anlise de Sistemas Rf 12, Ch 12, Ce 12, T 3
Anlise de Negcio-Gerncia de Projeto Rf 12, Ch 12, Ce 12, T 5


Sim No
3. Existe um protocolo/padro nico definido na empresa,
que oriente quais procedimentos (utilizao,
documentao, etc) devem ser realizados para cada
meio de comunicao entre as equipes distribudas?

3 9
Qual? Processo de desenvolvimento de
software - 3

4. Atividades de integrao entre as equipes distribudas e o cliente
Equipes Mecanismo de Comunicao
Desenvolvimento-Cliente Ad-hoc 12
135


Anlise de Sistemas-Cliente Reunies espordicas definidas em cronograma
8
Reunies Semanais 5
Ad hoc- 4
Anlise de Negcio-Cliente Reunies espordicas definidas em cronograma
10
Reunies Semanais 6
Reunies dirias - 3
Ad hoc- 7
Gerncia de Projeto-Cliente Reunies Semanais 9
Reunies espordicas definidas em cronograma
5
Anlise de Sistemas-Desenvolvimento Reunies Semanais 12
Ad hoc- 8
Anlise de Negcio-Desenvolvimento Reunies espordicas definidas em cronograma
4
Ad hoc- 7
Gerncia de Projeto-Desenvolvimento Reunies Semanais 12
Ad hoc- 8
Anlise de Negcio-Anlise de Sistemas Reunies Quinzenais 4
Reunies Semanais 2
Ad hoc- 8
Gerncia de Projeto-Anlise de Sistemas Reunies Semanais 12
Ad hoc- 8
Anlise de Negcio-Gerncia de Projeto Reunies Semanais 12
Ad hoc- 8


Sim No
5. Existem mecanismos para formalizao e distribuio
do conhecimento referente a Requisitos?

10 2
Qual? Reunies semanais - 12
Workshops de apresentao de
requisitos - 3
Documentos - 11
Intranet - 3
Email- 2

136



6. Que equipes utilizam estes mecanismos para
formalizao e distribuio do conhecimento referente a
Requisitos?

Todas 12

7. Existem treinamentos formais para a utilizao dos
meios de comunicao? Como eles so apresentados
para os participantes?

Treinamento- 8
Reunio de Passagem de
Conhecimento- 5

Mdia
8. Em sua opinio, a existncia de ferramentas (net
meeting; softwares para conferencia virtual; etc) que
auxiliem a comunicao fundamental para minimizar
rudos entre as equipes distribudas.
4,41

9. Existem dificuldades de entendimento de conceitos ou
requisitos entre a equipe e o cliente?
Cultural 9
Idioma 7
Documentao incompleta- 3
Falta de prototipao - 4

10. Quando ocorrem mais frequentemente as
dificuldades de entendimento de conceitos ou requisitos
entre a equipe e o cliente?
Anlise de Negcio 10
Anlise de Sistemas- 5

11. Descreva o que voc considera fatores culturais
chave na sua organizao (personalidade, criatividade,
etc).

12. Como os fatores citados na questo anterior so
afetados pela influncia do cliente (interno ou externo) na
empresa?

Respostas comentadas no texto

Mdia
13. Em sua opinio, a empresa deve fornecer
treinamento para as equipes distribudas a respeito das
culturas presentes na organizao e no cliente.
3,92

Mdia
14. O cliente (interno ou externo) demonstra confiana no 4,66
137


trabalho da empresa?

Sim No
15. A empresa (ou a diviso em que voc trabalha)
propicia freqentemente oportunidades para a integrao
(presencial) entre os funcionrios e o cliente?
3 9

Mdia
16. Em minha opinio, eu no deixaria que outros
membros da equipe tivessem influncia sobre problemas
importantes ao projeto.
1,58

Mdia
17. Em minha opinio, estaria confortvel em entregar
para outro membro do time, se ele estivesse preparado,
a completa responsabilidade do projeto.
4,58

Dimenso 4 Aspectos Tcnicos
Sim No
1. Existe uma base de dados, com informaes sobre
requisitos, disponvel na empresa?
Esta base de dados utilizada toda a vez que se inicia
um novo projeto de desenvolvimento

9

3
3

5

Sim No
2. A gesto de conhecimento uma funo formalmente
definida na empresa?
3 9

Sim No
3. Existe alguma atividade ou processo para divulgar
informaes entre as equipes e o cliente que auxiliem em
resoluo mais precisa ou veloz de problemas?
10 2

Sim No
4. Existe alguma forma de resoluo de ambigidades na
comunicao entre equipes e cliente?
12 0

Sim No
5. Existe alguma forma de resoluo de conflitos na 12 0
138


comunicao entre equipes e cliente no que se refere
aos requisitos?

Sim No
6. Existe alguma forma de divulgao para definies,
que so de entendimento comum, entre equipes
distribudas e cliente no que se refere aos requisitos?
12 0

Manuteno Novas solues
7. Quais os tipos de desenvolvimento de software
existentes na empresa?
7 12

Sim No
8. Em sua opinio, o processo de desenvolvimento de
software compreendido pelo cliente?
6 6

9. Qual o modelo de gesto de requisitos utilizado na
empresa?
RUP- 3
CMMI e RUP 5
MSF - 4

Sim No
8. Em sua opinio, o processo de desenvolvimento de
software compreendido pelo cliente?
6 6

Sim No
9. O padro de gesto de requisitos o mesmo utilizado
por todas as equipes da empresa?
7 5

10. Existe um processo organizacional padronizado e
formalizado entre a empresa (ou a diviso em que voc
trabalha) e o cliente para a engenharia de requisitos?
Qual? Processo prprio baseado em CMMI/REQ-M e
RUP/Requisitos
Respostas comentadas no texto

Mdia
11. importante a existncia de mecanismos de gesto
do conhecimento na empresa.
4,08

Mdia
12. Deve existir uma base comum de dados entre a
empresa e o cliente, de modo que elas possam trocar
3,58
139


experincias sobre determinado problema, bem como
compartilhar aprendizados em relao engenharia de
requisitos.