Stricto Sensu em Gestão do Conhecimento e Tecnologia da
Informação
REUSO DE DECISÕES NO PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE
Brasília - DF
2012
SANDRA SILVA DE ALVARENGA
REUSO DE DECISÕES NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão de Conhe-cimento e Tecnologia da Informação da Uni-versidade Católica de Brasília, como requisito parcial para a obtenção do Grau de Mestre em Gestão do Conhecimento e da Tecnologia da Informação.
Orientador: Prof. Dr. Hércules Antônio de Prado
Coorientador: Prof. Dr. Fábio Bianchi Campos
Ficha elaborada pela Biblioteca Pós-Graduação da UCB A473r Alvarenga, Sandra Silva de.
Reuso de decisões no processo de desenvolvimento de software. / Sandra Silva de Alvarenga – 2012.
99f. ; il.: 30 cm
Dissertação (mestrado) – Universidade Católica de Brasília, 2012. Orientação: Prof. Dr. Hércules Antônio de Prado
Coorientação: Prof. Dr. Fábio Bianchi Campos
1. Desenvolvimento de software. 2. Gestão do conhecimento. 3. Tomada de decisões. 4. Tecnologia da informação. I. Prado, Hércules Antônio de, orient. II. Campos, Fábio Bianchi, coorient. III. Título.
AGRADECIMENTOS
Primeiramente à Deus, pelo dom da vida, saúde e inspiração para as horas difíceis.
A minha filha Giovana por entender a minha ausência em muitos momentos para o de-senvolvimento desta pesquisa.
Ao meu marido Bruno pela força, incentivo e compreensão nas horas em que precisei.
Aos meus pais, meus exemplos de vida e amor, por estarem sempre ao meu lado.
Aos meus orientadores, Hércules Prado e Fábio Bianchi pela condução do meu apren-dizado, com tamanha dedicação.
Aos Professores Edilson Ferneda e Ana Paula Fukuda por todo apoio na execução das pesquisas.
Aos colaboradores deste trabalho, por acreditarem na pesquisa e pela imensa ajuda, sem a qual nada disso seria possível.
RESUMO
Referência: ALVARENGA, Sandra. Reuso de Decisões no Processo de Desenvolvimento de Software. 2012. 99. Mestrado em Gestão do Conhecimento e Tecnologia da Informação - Universidade Católica de Brasília, Brasília, 2012.
Esta pesquisa objetiva apresentar um processo que permita suportar o reuso de decisões toma-das durante o processo de desenvolvimento de software, sejam elas de natureza arquitetural, tecnológica, gerencial ou mesmo de mensuração de qualidade; no intuito de auxiliar a reduzir prazos e custos em novos projetos, evitando muitas vezes retrabalho e adoção de variadas soluções para uma mesma classe de problemas. Como parte do estudo foi realizado um levan-tamento das situações de tomada de decisão com profissionais atuantes em diversas áreas da Engenharia de Software. A partir do resultado desta pesquisa, foi proposto um processo (no que tange a Reuso dno e procedimentos) favorável ao reuso das mais variadas decisões reali-zadas durante projetos de desenvolvimento de software, utilizando técnicas de Raciocínio Baseado em Casos e Design Rationale. No intuito de avaliar a aplicabilidade deste processo, um estudo de caso foi aplicado, sendo este dividido em duas etapas: construção da base de casos e aplicação de dinâmica em grupo. Este experimento indicou resultados satisfatórios, no que remete a aplicação do processo de suporte à tomada de decisão proposto em casos reais.
ABSTRACT
This research aims to present a process for supporting the reuse of decisions made during the software development process, whether in architectural, technological, management, or else quality measurement, in order to help reducing time and costs in new projects, avoiding re-work and the adoption of different solutions to the same class of problems. As part of the study we performed a search of decision-making situations with software engineering profes-sionals. From the result of this research, we proposed a process (related software and proce-dures) that favors the reuse of several decisions made during software development projects, using Case Based Reasoning and Design Rationale techniques. In order to evaluate the ap-plicability of this process, a case study was applied, which was divided into two phases: con-struction of the case base and application of group dynamics. This experiment showed satis-factory results, which refers to the application of process support decision making in real cas-es proposed.
LISTA DE ILUSTRAÇÕES
Figura 1: Spiral Evolution of Knowledge Conversion and Self-transcending Process ... 23
Figura 2: Processo de aprendizado organizacional ... 44
Figura 3: Processo de tomada de decisão ... 65
Figura 4: Arquitetura do Decision Maker ... 67
Figura 5: Modelagem dos casos de uso ... 67
Figura 6: Diagrama de classes ... 69
Figura 7: Tela de Login - Decision Maker ... 72
Figura 8: Tela Principal - Decision Maker ... 72
Figura 9: Tela de Novo Problema - Decision Maker ... 72
Figura 10: Tela de Solução do Problema - Decision Maker ... 73
Figura 11: Tela Problemas Similares - Decision Maker ... 73
Figura 12: Tela Problemas Similares – Reuso - Decision Maker ... 74
Figura 13: Tela Pesquisar Problema - Decision Maker... 75
Figura 14: Tela Editar Problema - Decision Maker ... 75
Figura 15: Gênero dos Participantes ... 77
Figura 16: Tempo de Experiência em Desenvolvimento de Software ... 77
Figura 17: Função no Projeto ... 78
Figura 18: Complexidade ... 78
Figura 19: Categorias ... 79
Figura 20: Tecnologias ... 80
Figura 21: Tempo de experiência em desenvolvimento de software - Etapa 2 ... 80
Figura 22: Gráfico - Moda x Mediana - Avaliação do Processo de Suporte a Tomada de Decisão Proposto ... 81
Figura 23: Gráfico - Moda x Mediana - Avaliação da Ferramenta Decision Maker ... 82
Figura 24: Gráfico - Moda x Mediana - Avaliação da Aplicação do Processo de Suporte a Tomada de Decisão em Casos Reais ... 83
LISTA DE TABELAS
Tabela 1: Síntese da revisão de literatura ... 14
Tabela 2: Funções e pesos de similaridade local adotadas no Analogus ... 52
Tabela 3: Experiência em Desenvolvimento de Software ... 56
Tabela 4: Função no projeto ... 57
Tabela 5: Decisões do Projeto x Disciplinas ... 58
Tabela 6: Decisões do Projeto x Disciplinas ... 58
Tabela 7: Critérios que influenciam a escolha de uma alternativa ... 59
Tabela 8: Grau de importância na representação de um problema ... 59
Tabela 9: Grau de importância na representação de uma solução ... 60
Tabela 10: Similaridade local dos atributos... 70
Tabela 11: Similaridade local dos atributos ajustada ... 71
Tabela 12: Respostas - Avaliação do Processo de Suporte a Tomada de Decisão Proposto .. 81
Tabela 13: Respostas - Avaliação da Ferramenta Decision Maker ... 82
LISTA DE QUADROS
Quadro 1: Perspectivas de Representação o DR (FRANCISCO, 2004) ... 35
Quadro 2: Funções de similaridade local avaliadas no Analogus ... 51
Quadro 3: Funções de similaridade local adotadas no ECoCADe ... 53
Quadro 4: Grau de Similaridade... 68
Quadro 5: Domínio – Categoria do Problema ... 70
Quadro 6: Domínio – Complexidade do Problema ... 70
LISTA DE SIGLAS
CMMi – Capability Maturity Model Integration. DR – Design Rationale.
EJB – Enterprise JavaBeans. GC – Gestão do Conhecimento. JPA – Java Persistence API. JSF – Java Server Faces.
MBE –Medicina Baseada em Evidências.
MPS.BR –Melhoria de Processos do Software Brasileiro. PBE–Prática Baseada em Evidências.
SUMÁRIO
1 INTRODUÇÃO ... 13
1.1 REVISÃO DE LITERATURA ... 14
1.2 RELEVÂNCIA DO ESTUDO ... 16
1.3 FORMULAÇÃO DO PROBLEMA ... 17
1.4 OBJETIVOS ... 18
1.5 ORGANIZAÇÃO DO TRABALHO DE DISSERTAÇÃO ... 18
2 REFERENCIAL TEÓRICO ... 20
2.1 GESTÃO DO CONHECIMENTO ... 20
2.2 GESTÃO DO CONHECIMENTO DURANTE O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ... 26
2.2.1 Modelos de maturidade ... 27
2.2.2 Desenvolvimento ágil ... 30
2.3 DESIGN RATIONALE ... 32
2.3.1 História do Design Rationale ... 33
2.3.2 Funcionamento do Design Rationale ... 35
2.4 RACIOCÍNIO BASEADO EM CASOS ... 37
2.4.1 História do Raciocínio Baseado em Casos ... 39
2.4.2 Funcionamento do Raciocínio Baseado em Casos ... 40
2.5 DISCUSSÃO SOBRE O REFERENCIAL TEÓRICO ... 43
3 TRABALHOS CORRELATOS ... 47
3.1 GIBIS ... 47
3.2 QUESTMAPTM ... 47
3.3 JANUS ... 48
3.4 DOCRATIONALE ... 48
3.5 INFORAT ... 49
3.6 SIBYL ... 49
3.7 SEURAT ... 49
3.8 ANALOGUS ... 50
3.9 ECOCADE E MODECOCA ... 52
4 METODOLOGIA ... 55
4.1 CLASSIFICAÇÃO DA PESQUISA ... 55
4.2 PRESSUPOSTOS ... 55
4.3 PESQUISA SITUAÇÕES DE TOMADA DE DECISÃO ... 55
4.4 ELABORAÇÃO DOS INSTRUMENTOS DE COLETA DE DADOS ... 60
4.5 VALIDAÇÃO É PRÉ-TESTE DOS QUESTIONÁRIOS ... 61
4.6 SELEÇÃO DAS AMOSTRAS ... 61
4.7 COLETA E ANÁLISE DOS DADOS ... 62
4.8 DELIMITAÇÃO DO ESTUDO ... 63
4.9 ETAPAS DA METODOLOGIA ... 63
4.10 RESULTADOS ESPERADOS ... 63
5 ESTUDO DE CASO ... 64
5.1 IMPLEMENTAÇÃO DA SOLUÇÃO ... 66
5.2 INTERFACE DO DECISION MAKER ... 71
5.3 APLICAÇÃO DO ESTUDO ... 75
5.4.1 Coleta de dados reais - Levantamento de situações problema ... 76
5.4.2 Avaliação do processo de Suporte à Tomada de Decisão proposto ... 80
5.5 CONCLUSÃO SOBRE A CONTRIBUIÇÃO DO PROCESSO DE REUSO DE DECISÕES DURANTE O DESENVOLVIMENTO DE SOFTWARE ... 84
6 CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ... 85
REFERÊNCIAS ... 88
APÊNDICE A QUESTIONÁRIO SITUAÇÕES TOMADA DE DECISÃO ... 95
APÊNDICE B LEVANTAMENTO DE SITUAÇÕES PROBLEMA ... 97
1 INTRODUÇÃO
Diante da concorrência acentuada entre organizações que desenvolvem e mantêm sof-tware para se destacarem no mercado de trabalho, torna-se necessário atuar de forma eficiente e eficaz em relação à preservação do capital intelectual envolvido. Para tanto, tais organiza-ções fazem uso dos mais variados artefatos, modelos e metodologias no intuito de resguardar as informações envolvidas nos projetos. Porém, a quantidade de informações disponível nem sempre garante a qualidade do processo ou do produto. Ou seja, mesmo o conhecimento ex-plicitado nesses artefatos (diagramas, documentos, processos, entre outros) ainda não é sufici-ente por não compreenderem todas as informações necessárias para o completo sufici-entendimento do software. Além disso, na maioria das vezes, a realização de uma atividade pode se benefi-ciar da experiência de decisões passadas. Isso evitaria o retrabalho ou mesmo a adoção de soluções que não as melhores para a mesma classe de problemas. No entanto, o problema com o reuso ocorre, geralmente, porque apenas as últimas decisões do projeto são documentadas. Preservar o histórico das decisões tomadas pode ser oneroso ou ter chances limitadas de su-cesso caso não se disponha de um suporte operacional adequado. As experiências adquiridas, as lições aprendidas, informações de processos de análise e tomada de decisão raramente são preservadas, ficando contidas apenas na mente dos agentes envolvidos (conhecimento tácito). O processo de explicitação de conhecimento tácito, porém, não é uma tarefa trivial. Ao contrário, é caracterizado pela dificuldade em identificar os ativos relevantes e em definir e aplicar uma metodologia apropriada. A dificuldade em se determinar que informação preser-var está muitas vezes associada ao contexto em que foi gerada. Além disso, como extrair esse ativo, presente inicialmente apenas no intelecto dos protagonistas de sua criação? Esse pro-blema é tratado no âmbito da área de estudo que vem sendo chamada de Inteligência Coletiva (IC).
A Engenharia de Software (ES), como disciplina intensiva no uso de conhecimento especializado tem se beneficiado fortemente de abordagem que preserve e compartilhe o co-nhecimento (PAULA FILHO, 2001). Geralmente, o reuso de componentes e estruturas funci-onais de projeto requerem um alto nível de conhecimento agregado. Por outro lado, o trata-mento do conhecitrata-mento envolvido na construção de componentes visando seu reuso no de-senvolvimento de outros componentes ainda é um problema sem uma solução amplamente aceita.
Este trabalho foca a definição de um processo envolvendo representação e recuperação de problema, que possibilite a explicitação, organização e armazenamento dos conhecimentos tácito e explícito envolvidos durante o desenvolvimento de software, conservando e comparti-lhando o capital intelectual visando: (i) evitar a adoção de soluções que experiências anterio-res mostraram gerar anterio-resultados não satisfatórios (segurança) e (ii) evoluir produtos pautando-se em decisões anteriores (maturidade).
1.1 REVISÃO DE LITERATURA
Esta proposta aborda questões relacionadas ao reuso de decisões durante o processo de desenvolvimento de software. Nesse sentido, foi realizada uma pesquisa em bases terciárias acessíveis por meio do portal de periódicos da Capes, conforme mostrado na Tabela 1. A se-guir, são comentados alguns dos trabalhos encontrados nessa pesquisa e que se mostraram relevantes.
Tabela 1: Síntese da revisão de literatura
Termos de Busca Web of Science Decision-making [DM] 128.590
Knowledge Reuse [KR] 303
Software Development Process [SDP] 1.605
Design Rationale [DR] 687
Knowledge Management [KM] 10.874
DM + KR 12
SDP + KM 29
KM + DR 33
KR + SDP 5
SDP + DR 6
DM + KR + SDP 1
KR + SDP + DR 0
DM + KR + DR 1
DM + KR + SDP + DR 0
O processo de desenvolvimento de software é intenso no uso de conhecimento, envol-vendo muitas decisões durante todo o ciclo de vida do produto. A dependência da efetividade de uma decisão com relação ao grau de conhecimento envolvido foi observada por Figueiredo (2006), que comparou decisões tomadas por equipes mais e menos experientes a cerca de uma mesma situação.
A criticidade em torno das decisões está relacionada às inúmeras possibilidades para solucionar um mesmo problema. Rittel (1973) considera que soluções nunca são simplesmen-te certas ou erradas, somensimplesmen-te melhores ou piores, de acordo com o consimplesmen-texto. Ao mesmo simplesmen- tem-po, as diferentes situações enfrentadas por projetos considerados semelhantes fazem com que cada problema seja tido como único.
Dentre as diversas abordagens para auxílio no processo decisório, Rittel (1973) encon-trou no DR uma resposta para a complexidade envolvida em projetos. Segundo ele, os pro-blemas reais não eram bem descritos e não vinham associados a um conjunto de possíveis soluções, não permitindo uma visão clara da problemática logo de início.
Diversos outros autores se dedicaram a estudos sobre o DR. Karsenty (1996) propôs uma avaliação empírica a respeito da utilidade dos documentos do DR no processo de manu-tenção de software. Concluiu-se que tais documentos eram úteis para os projetistas, auxilian-do-os na compreensão de problemas.
Brathall, Johansson e Regnell (2000) apresentaram um experimento para avaliar a portância da documentação das decisões fundamentais de design (DDRD) para predizer im-pactos de mudanças ou evoluções da arquitetura de software. Verificou-se a relevância da DDRD para o aumento da eficácia e eficiência dos produtos finais, agilizando o desenvolvi-mento dos produtos.
Tyree e Akeman (2005) defendem que a maioria das decisões arquiteturais dos proces-sos de desenvolvimento de software não documentam explicitamente as decisões. Arquitetu-ras compreendem diversos tipos de decisões com diferentes níveis de granularidade, e todo esse conhecimento deveria ser descrito e capturado apropriadamente. Assim, eles propõem uma lista com um conjunto de atributos caracterizando as decisões que se quer capturar e do-cumentar. Além disso, os relacionamentos entre decisões com outros artefatos de software deveriam ser descritos e documentados explicitamente na ordem de representação das esco-lhas selecionadas e das alternativas para cada escolha.
que obtém os traços das informações coletadas, utilizando mineração de dados.
Para Capilla, Nava e Dueñas (2007), as decisões de design e suas razões podem ser descritas por atributos considerados relevantes para uma determinada arquitetura ou organiza-ção, permitindo uma abordagem mais flexível para a captura e caracterização das decisões de design arquiteturais. Assim, os arquitetos de software podem decidir as informações a serem armazenadas para descrever suas decisões e estimar o esforço necessário para capturar o DR.
Assim, parece ser consenso que a captura do DR é um problema relevante. Embora se-ja reconhecida a importância e a vantagem na preservação do conhecimento envolvido duran-te as tomadas de decisão, ainda exisduran-te dificuldade em identificar quais atributos melhor carac-terizam uma situação problema e a decisão dela advinda. O excesso de informações ou mes-mo sua insuficiência podem dificultar não somente a representação da situação comes-mo também a recuperação de casos semelhantes para reuso.
No entanto, Capilla, Nava e Dueñas (2007) e Tyree e Akeman (2005) não se mostra-ram satisfeitos com os atributos escolhidos para a caracterização do processo de decisão. Eles tiveram dificuldade em lidar com a subjetividade envolvida na identificação de informações a serem capturadas, o que levou à representação de informações desnecessárias ou que dificul-tavam a sua recuperação. Além disso, suas abordagens exigiam um considerável esforço para adoção, o que poderia resultar em desmotivação para o profissional responsável em executar essa tarefa.
Outro aspecto importante é o feedback ao longo do tempo, com relação a um determi-nado DR. A avaliação de cada situação contribui para a classificação da consistência das in-formações, tendo em vista que algumas soluções poderiam não ser as melhores ou mesmo terem se mostrado ineficientes. A partir destes feedbacks, é possível se propor melhorias na composição do DR.
As informações passíveis de serem associadas aos rationales envolvem a identificação da situação-problema, as várias propostas possíveis de solução, suas respectivas avaliações, entre outras. A explicitação, avaliação e articulação deste conjunto extenso de informações é um problema ainda não totalmente resolvido, segundo a literatura revisada, o que nos dá uma ideia da importância e da necessidade do presente estudo.
1.2 RELEVÂNCIA DO ESTUDO
Intelectual (CI), em detrimento ao Capital Financeiro (CF). Essa visão, totalmente orientada pelas ideias, experiências, descobertas e especializações de colaboradores, caracteriza o CI como elemento chave da vantagem competitiva. Essa ideia é complementada por Turoff (1976, apud COSTA, 2005), que afirma que um grupo bem formado possibilita a geração de um grau de inteligência maior do que a de qualquer de seus participantes, consagrando assim o poder do conhecimento coletivo.
O processo de desenvolvimento de software, usualmente caracterizado por longos ci-clos de vida, dificilmente consegue manter a mesma composição de equipe durante um proje-to. Bruge e Brown (2000) alertam para a necessidade da preservação do conhecimento diante desse cenário.
Conklin (1989) expôs a importância da compreensão das decisões anteriormente to-madas, como, quais as alternativas consideradas, o porquê do descarte de algumas delas, quais os critérios satisfeitos, quais as suposições feitas e quais suas consequências para decisões mais consistentes e com maiores chances de sucesso.
Nota-se, então, que o índice de retrabalho e a adoção de soluções não padronizadas ou mesmo com chances limitadas de sucesso são mais frequentes na realidade dessas organiza-ções do que deveriam ser. As resoluorganiza-ções para os problemas acabam não sendo efetivas. Daí a relevância em se definir um modelo que possibilite o captura de conhecimento compreenden-do não somente sua solução e justificativa, mas também as alternativas consideradas e descar-tadas durante a tomada de decisão no processo de desenvolvimento de software.
1.3 FORMULAÇÃO DO PROBLEMA
A quantidade de informações disponíveis em um projeto de desenvolvimento de sof-tware nem sempre garante a qualidade do processo ou produto. Ou seja, mesmo o conheci-mento explicitado nos artefatos usuais de uma metodologia de desenvolviconheci-mento de software (diagramas, documentos, especificações, processos) vem se mostrando insuficiente pelo fato de não abranger todas as informações necessárias para o completo entendimento do produto. Além disso, na maioria das vezes, a realização de uma atividade relacionada ao desenvolvi-mento de um software é antecedida por análises de esforço e entendidesenvolvi-mento do produto, na tentativa de prever soluções, evitar o retrabalho e a adoção de variadas soluções para um mesmo problema.
contribuir para o sucesso de novas decisões. Em função disso, pode-se formular a seguinte questão de pesquisa: como o conhecimento acumulado durante o processo de desenvolvimen-to de software pode ser representado e reutilizado em novas desenvolvimen-tomadas de decisão?
1.4 OBJETIVOS
O objetivo geral deste trabalho é propor um mecanismo que possibilite (i) a sistemati-zação dos conhecimentos relativos às decisões tomadas durante um processo de desenvolvi-mento de software e (ii) o compartilhamento desse conhecimento com outros técnicos e em outras situações.
Como objetivos específicos podem ser citados:
a) Identificar o conhecimento envolvido durante a tomada de decisão no processo de de-senvolvimento de software;
b) Propor uma forma de aquisição, representação e armazenamento desse conhecimento; c) Propor uma forma de recuperação do conhecimento envolvido em decisões tomadas no
contexto de uma equipe de desenvolvimento de software de modo a viabilizar o seu reu-so em situações similares.
1.5 ORGANIZAÇÃO DO TRABALHO DE DISSERTAÇÃO
O presente trabalho obedece a algumas etapas principais e é dividido em seis capítu-los. No capítulo que se segue, são apresentadas as concepções teóricas dos temas relacionados a pesquisa, conceituando Gestão do Conhecimento, Gestão do Conhecimento durante o Pro-cesso de Desenvolvimento de Software, Deign Rationale, Raciocínio Baseado em Casos.
O terceiro capítulo relaciona diversos trabalhos correlacionados ao tema pesquisado, no sentido de subsidiar a evolução dessa pesquisa.
A metodologia da pesquisa utilizada no presente trabalho é disposta no quarto capítu-lo, detalhando a classificação da pesquisa, pressupostos, coleta e análise dos dados, delimita-ção do estudo, as etapas, seledelimita-ção das amostras e os resultados esperados.
O quinto capítulo explora o estudo de caso do trabalho, realizado com profissionais atuantes em projetos de desenvolvimento de software onde é descrita a visão geral da solução proposta, seguida pelo detalhamento das características do sistema proposto: o Decision
O sexto e último capítulo apresenta as conclusões deste trabalho e propõe as possibili-dades de pesquisas futuras.
2 REFERENCIAL TEÓRICO
Neste capítulo são apresentadas as bases conceituais sobre as quais se assenta esta pesquisa. Discute-se a Gestão do Conhecimento (GC) a partir de um contexto amplo, confor-me colocado por Lévy (1999), até a formulação de Nonaka e Takeuchi (1997) de uma gestão orgânica, centrada no indivíduo e na socialização de seu conhecimento em uma organização por meio de processos de transformação. Em seguida, foca-se em GC no contexto da ES, dis-cutindo-se, em particular, os modelos de maturidade por associarem explicitamente o reuso com o nível de maturidade de uma organização e os modelos ágeis calcados no reuso intensi-vo do conhecimento. Na sequência, a técnica do Design Rationale (DR) é explorada nas suas características, mormente por determinar o contexto desta pesquisa. O Raciocínio Baseado em Casos (RBC) é incluído como técnica de suporte utilizada para a prática do reuso de soluções. Por fim, os pilares – GC, GC em ES, DR e RBC – são discutidos em conjunto de modo a se visualizar o corpo integrado de conhecimento definido como o leito desta pesquisa.
2.1 GESTÃO DO CONHECIMENTO
As sociedades humanas, desde a pré-histórica até a era da informática, passaram por uma série de transformações em suas formas de registro de conhecimento. Isso porque desde os tempos mais remotos, a inteligência humana já possuía seu reconhecimento perante a soci-edade. A escrita, então, se tornou a principal forma de registro, promovendo a socialização e a preservação das informações consideradas relevantes. A partir do advento desta, o registro de informações pôde ser mais fiel, permitindo a preservação de conhecimentos, tornando cada vez mais viável a cooperação entre indivíduos, possibilitando o compartilhamento de suas informações como aprendizado permanente (LÉVY, 1999).
Lévy (1994, p. 28) destaca a importância de se valorizar a capacidade de ouvir e pres-tar atenção no outro, de tal forma que quanto mais o parceiro ganha, maior é o ganho de cada um. Além disso, cada ser humano é único, portador de sabedoria e interpretação própria. A diversidade da humanidade possibilita o interesse e especialização de cada um por áreas dis-tintas. Além disso, as relevâncias da aptidão e do interesse do indivíduo são ressaltadas como aliadas na criação de um conhecimento.
individual, o que é conhecido como capital intelectual (STEWART, 1998).
Segundo Stewart (1998), o valor de uma organização é determinado mais pelo seu ca-pital intelectual do que por seu caca-pital financeiro, agindo como elemento chave da vantagem competitiva. Dessa forma, a “competitividade das organizações passou a ser determinada pe-las ideias, experiências, descobertas e especialização que colaboradores conseguem gerar e difundir (PAIVA, 2000, p. 1).
Considerando a importância dos ativos intangíveis para as empresas, a inteligência humana e os recursos intelectuais podem ser considerados como ativos mais valiosos da orga-nização (EDVINSSON e MALONE, 1998 apud LARA, 2005).
Stewart (1998) também define capital intelectual como a junção dos seguintes ativos: Capital humano, que corresponde ao conhecimento e competências de cada um dos
fun-cionários. Esse capital é perdido quando funcionários vão embora das empresas;
Capital estrutural, que corresponde ao conhecimento ou competência coletiva, como processos, documentos e atas. Esse capital é conservado quando funcionários vão embo-ra das empresas;
Capital do cliente, o qual inclui conhecimento e vantagens provindas dos clientes. É o valor que se ganha com o relacionamento com os clientes. Para este capital é importante a utilização de mecanismos de captura, guarda e recuperação do conhecimento como, por exemplo, sistemas de gestão de relacionamentos.
Balceiro, R. e Balceiro, L (2001) entendem inteligência empresarial como a composi-ção de três pilares: conhecimento, inovacomposi-ção (aplicacomposi-ção do conhecimento para a solucomposi-ção de problemas) e empreendedorismo (planejamento de ações em negócios). O conhecimento é considerado a base por representar a matéria-prima para os demais. Os autores chegam a con-jecturar que uma organização só é capaz de aprender constantemente através desses três pila-res.
O conhecimento é insumo básico para que as organizações possam funcionar, de nada adiantando ativos materiais de alta tecnologia se as pessoas não tiverem o conhecimento ne-cessário para fazê-los funcionar adequadamente (PAIVA, 2000).
Angeloni (2003) considera informação como dados com contexto específico para so-lução de determinada situação de decisão. Complementarmente, Davenport (1998, p.19) con-ceitua informação como dados com significado, dotados de relevância e propósito. Além dis-so, a informação pode ser considerada como “a matéria-prima para se obter conhecimento” (MALHOTRA, 1997).
A agregação de valor à informação depende de experiências anteriormente vivencia-das. A integração de experiências antigas com novas informações favorece a percepção de novas perspectivas. Para Angeloni (2003, p18), essas perspectivas resultam no conhecimento, reconhecido como a “[...] informação processada pelos indivíduos”.
Considerando tais conceitos, dados permitem a geração de informações, que por sua vez possibilitam o conhecimento, que pode resultar em matéria-prima para geração de novos dados. Esses três elementos se destacam pela sua fundamental importância no processo deci-sório, baseado em gerir o conhecimento em prol da vantagem competitiva da organização.
Nonaka e Takeuchi (1997), a partir dos estudos de Polanyi (1966), referem-se ao co-nhecimento organizacional da seguinte forma: conhecimento explícito é aquele que pode ser formalizado e armazenado em documentos, manuais, bases de dados, atas, entre outros meios, e conhecimento tácito é o conhecimento próprio das pessoas que não se encontra formalizado em meios concretos.
A estes dois tipos, Miranda (1999, p. 17) acrescenta o conhecimento estratégico, defi-nido como a combinação dos dois conhecimentos acima descritos, constituído “[...] a partir de informações estratégicas e de acompanhamento, juntamente com o conhecimento de especia-listas”.
Nonaka e Kono (1998, p. 42-45) identificam quatro formas de conversão entre os co-nhecimentos tácito e explícito, representando uma estratégia para a troca de conhecimento (Figura 1):
A socialização envolve o compartilhamento de conhecimento tácito entre indivíduos, através de proximidade física.
A externalização corresponde à expressão do conhecimento tácito e sua tradução em formatos que podem ser compreendidos por outros indivíduos, ou seja, é a transforma-ção desse conhecimento em explícito, envolvendo técnicas que auxiliem a expressão de ideias entre indivíduo e grupo, se tornando parte do grupo.
grupo para o organizacional.
A internalização consiste na transformação do conhecimento explícito em tácito. Ela ocorre pela interpretação individual do conhecimento organizacional de um determina-do grupo.
Figura 1: Spiral Evolution of Knowledge Conversion and Self-transcending Process
i = indivíduo, g = grupo, o = organização
Fonte: (NONAKA, 1998)
Esses modos de conversão podem ser entendidos como a transformação do aprendiza-do individual em coletivo, ou seja, aprendiza-do conhecimento tácito em explícito, de forma a facilitar a criação do conhecimento estratégico.
É evidente que o ser humano é portador de inteligência e criatividade inigualáveis. Po-rém, muitas vezes, informações ficam concentradas em seus criadores. O avanço da informá-tica amplifica a capacidade de ouvir, prestar atenção e compartilhar através da exposição de ideias e insights em ambientes virtuais.
A Inteligência Coletiva (IC) é uma combinação de comportamentos, preferências ou concepções de um grupo de pessoas que podem ser usadas para criar novas ideias (SEGA-RAN, 2008). Ainda segundo Segaran (2008), novas conclusões podem ser alcançadas através das mais diversas opiniões. Segundo ele o conhecimento coletivo combina as interpretações, conhecimentos experiências e intuições de um grupo de pessoas a fim de criar intuições, no-vas soluções.
adap-tação a novos problemas. Quanto maior for o envolvimento dos membros desse grupo, maior o potencial de absorção desse novo conhecimento.
Segaran (2008) propõe grupos como instrumentos que permitem a valorização pessoal, evitando todo o desperdício da riqueza humana e possibilitando a continuidade de trabalhos, pensamentos e descobertas sem a necessidade de recomeço.
Trabalhar em grupo também traz motivação para cada um de seus membros, pois seu trabalho vai ser observado, comentado e avaliado por pessoas que o observam. O grupo tam-bém tem mais capacidade de gerar alternativas de forma criativa, levantar as vantagens e des-vantagens de cada uma, selecionar as viáveis e tomar decisões (BENBUNAM-FICH e HILTZ, 1999).
No entanto um grupo necessita de um espaço que permita todo o entrosamento neces-sário para a sua condução. O ciberespaço pode ser caracterizado como um meio de exploração de problemas, de discussão diversa e ampla, contando com evidências de processos comple-xos, de tomada de decisão e de avaliação dos resultados (LÉVY, 1994).
Para Lévy (1994), esse ambiente, envolvido pela valorização do ser humano, permite a contribuição de cada um de maneira contínua para a elaboração e o aperfeiçoamento dos pro-blemas comuns, abertura de novas questões para a formulação de argumentos e para enunciar e adotar posições independentes umas das outras.
O ciberespaço é um ambiente totalmente democrático e dinâmico, acompanhando as modificações de acordo com cada realidade. Através da internet (ambiente sem o qual o cibe-respaço não existiria) comunidades geograficamente distribuídas podem se encontrar isentas de preconceitos e discriminações e expor pensamentos e conclusões. Por intermédio das fer-ramentas comunicacionais disponíveis, torna-se cada vez mais possível a obtenção de insights individuais, que contribuem para os coletivos inteligentes, através das mais variadas trocas de informações.
São várias as ferramentas de comunicação contemporânea contidas no ciberespaço. A Wikipédia e o Google exemplificam utensílios que possibilitam a interação virtual.
Wikipédia é uma enciclopédia na internet mantida por contribuições das mais variadas pessoas. Qualquer assunto pode ser abordado por um colaborador e evoluído por outro, tor-nando mais consistente e concreto o compartilhamento do conhecimento.
Assim, enquanto a Wikipédia conserva os conhecimentos dos colaboradores, disponi-bilizados através das contribuições, o Google obtém as informações relevantes de acordo com a solicitação do colaborador.
Em virtude disso, é fundamental garantir a ausência de limitações de modo a favorecer a criatividade no ciberespaço, gerada pelo indivíduo e amadurecida pelo coletivo, transforma-da, assim, em conhecimento.
O conhecimento é o insumo para o processo decisório das organizações, pois a decisão está condicionada à qualidade e quantidade da informação existente. Além disso, representa o uso das informações associado às experiências vividas pelo indivíduo. No entanto, devido à sua subjetividade, o conhecimento sobre determinado tema pode variar de pessoa para pessoa.
A crescente complexidade do ambiente, em que ocorre a tomada de decisão, exige das organizações maior fundamentação das informações diante de uma necessidade de decisão.
Cada vez mais as organizações necessitam tomar grande número de decisões a fim de solucionar novos e mais complexos problemas. Essas decisões, geralmente, contam com ex-periências pessoais, sensações e feeling de cada profissional.
Para Simon et al. (1987), a resolução de problemas pode ser composta pelas seguintes tarefas: (i) verificar a existência de um problema, (ii) levantar informações relacionadas ao problema, (iii) identificar objetivos a serem alcançados, (iv) apresentar alternativas ao pro-blema e (v) analisar as alternativas. Complementando esta atividade, tomada de decisão esco-lhe a solução para a problemática em questão.
O processo de decisão de Simon (1965) propõe ainda um modelo dividido em três fa-ses e de um ciclo de revisão constante (com feedback):
Inteligência ou Investigação: fase responsável pela coleta de indícios e evidências vi-sando identificar as variáveis que caracterizam o problema.
Desenho ou Concepção: fase da formulação do problema, da construção e análise das alternativas, de acordo com a sua potencialidade.
Escolha: fase que a seleção da alternativa é realizada.
Feedback: durante o ciclo, o decisor pode retornar a uma fase, anteriormente vivencia-da, no intuito de ajustar algum ponto.
2.2 GESTÃO DO CONHECIMENTO DURANTE O PROCESSO DE DESENVOLVI-MENTO DE SOFTWARE
O desenvolvimento de software é um processo que envolve diversos perfis de profissi-onais, trabalhando em fases distintas, necessitando interagir e, ao mesmo tempo, envolvendo decisões, que levam em consideração uma série de opções (RUS, LINDVALL e SINHA, 2001, p. 2).
Neste processo, as organizações precisam cada vez mais de soluções para negócios ur-gentes, diminuindo o custo e o tempo para a escolha sem deixar de fora a qualidade da solu-ção, buscando o aumento da efetividade da decisão. Enganos e retrabalhos devem ser evitados ao máximo e, em contra partida, soluções de sucessos devem servir de base para novos pro-blemas.
Cenários como este, envolvem uma gama de decisões e estão cada vez mais orientados ao conhecimento: uma empresa deve decidir quais produtos irá desenvolver; um gerente de projeto deve escolher sua equipe e planejar o projeto, escolhendo um conjunto de técnicas e métodos a ser usado; um projetista deve escolher uma solução eficiente; um programador tem que decidir por uma função ou recurso da ferramenta e da linguagem adotada; e um testador deve escolher melhores estratégias para efetuar testes mais eficientes (RUS, LINDVALL e SINHA, 2001, p. 2). O conhecimento envolvido neste processo é disperso, de grande propor-ção e se amplia rapidamente (PARREIRAS e BAX, 2003).
Rus e Lindvall (2001) identificam algumas necessidades de conhecimento de organi-zações ligadas ao desenvolvimento de software:
Aquisição de conhecimento em novas tecnologias: constante monitoramento de ambien-te em busca de novas ambien-tecnologias;
Acesso a novos domínios de conhecimento: envolvimento do conhecimento de domínio negocial no intuito de agregar valor ao negócio com o desenvolvimento de software; Compartilhamento de conhecimento sobre políticas e práticas institucionais:
dissemina-ção da cultura organizacional, infraestrutura de trabalho e práticas institucionais aos co-laboradores de uma organização;
Captura de conhecimento relacionado ao capital intelectual: o indivíduo é considerado o recurso mais importante nas organizações. Preservar o conhecimento possuído por cada um se transforma no grande diferencial competitivo das organizações, proporcionando a criação de uma estratégia que mitigue a perda desse recurso;
troca mútua de conhecimento entre membros de uma equipe de desenvolvimento de sof-tware, independente do tempo e espaço que ocupem.
Durante o processo de desenvolvimento de software várias são as soluções idealizadas para determinada problemática. Dentre as várias discussões para a definição de uma alternati-va, muitos argumentos são envolvidos, porém são critérios bem definidos que determinam a escolha final.
Todo o raciocínio envolvido em um processo de tomada de decisão pode ser essencial para a condução bem sucedida do projeto, porém nem sempre essas informações são docu-mentadas.
Muitas são as vezes que determinado profissional necessita de ajuda de terceiros para compreender uma demanda, pois as explicações que precisa não estão contempladas na do-cumentação disponível. Além disso, a rotatividade de colaboradores agrava esse tipo de cená-rio, promovendo, algumas vezes, a reestruturação de uma solução, que pode ser conflitante com o restante do projeto (BURGE e BROWN, 2000).
A engenharia de software, apesar de disponibilizar variadas formas para a documenta-ção das informações relacionadas a projetos de software, sofre com a ausência da representa-ção dos conhecimentos tácitos, envolvidos em processos decisórios, de forma efetiva. Além disso, as empresas estão cada vez mais preocupadas em atingir níveis mais altos dos modelos de maturidade de capacidade, gastando muito tempo com documentações, métricas, indicado-res, do que simplesmente escrevendo e debugando códigos (BURGE, 2008).
2.2.1 Modelos de maturidade
Modelos de capacidade e maturidade de software são focados para melhoria de pro-cessos nas organizações. Para tal, compreendem elementos essenciais a serem implementados em disciplinas e processos no intuito de favorecer a evolução de procedimentos executados de forma imatura até adquirirem disciplina resultando em melhora de qualidade e eficiência (CHRISSIS, KONRAD e SHRUM, 2006).
O processo de DRU se propõe a identificar oportunidades de reutilização sistemática de ativos na organização e, se possível estabelecer um programa de reutilização para desen-volvê-los a partir de engenharia de domínios de aplicação. São esperados os seguintes resulta-dos em sua implementação (SOFTEX, 2009):
DRU 1: Domínios de aplicação em que serão investigadas oportunidades de reutilização de ativos ou nos quais se pretende praticar reutilização são identificados, detectando os respectivos potenciais de reutilização;
DRU 2: A capacidade de reutilização sistemática da organização é avaliada e ações cor-retivas são tomadas, caso necessário;
DRU 3: Um programa de reutilização, envolvendo propósitos, escopo, metas e objeti-vos, é planejado com a finalidade de atender às necessidades de reutilização de domí-nios;
DRU 4: O programa de reutilização é implantado, monitorado e avaliado;
DRU 5: Propostas de reutilização são avaliadas de forma a garantir que o resultado da reutilização seja apropriado para a aplicação alvo;
DRU 6: Formas de representação para modelos de domínio e arquiteturas de domínio são selecionadas;
DRU 7: Um modelo de domínio que capture características, capacidades, conceitos e funções comuns, variantes, opcionais e obrigatórios é desenvolvido e seus limites e re-lações com outros domínios são estabelecidos e mantidos;
DRU 8: Uma arquitetura de domínio descrevendo uma família de aplicações para o do-mínio é desenvolvida e mantida por todo o seu ciclo de vida;
DRU 9: Ativos do domínio são especificados; adquiridos ou desenvolvidos, e mantidos por todo o seu ciclo de vida.
Dias et al. (2010, p. 9) considera que os 4 últimos resultados esperados de DRU são satisfeitos por métodos ágeis. No entanto, o DRU1 e DRU2 não podem ser considerados satis-feitos por estes métodos por não poderem garantir definição do problema para a tomada de decisão e de guias para a análise das decisões, respectivamente. Estes autores sugerem que, através da criação de um guia simples e direto (sem conflitar com o princípio ágil do volume mínimo de documentação) e das práticas de reuniões rápidas, a análise das decisões é favore-cida.
Reutili-zação, proposto pelo MPS.BR, não são claramente abordados pelo desenvolvimento ágil (DI-AS et al., 2010, p.9).
Klein (1999) afirma a existência de duas perspectivas para tomada de decisões pelos seres humanos: a natural e a racional. A primeira é caracterizada pelo envolvimento dos deci-sores com problemas e objetivos mal definidos, sendo resolvidas a partir de intuições e expe-riências. Em contrapartida, decisões racionais envolvem processos formais, baseados em li-nhas de raciocínio, direcionando o desenvolvedor na tomada de decisão de forma objetiva e consciente.
Em apoio à segunda perspectiva, o processo de GDE tem propósito relacionado à aná-lise de possíveis decisões críticas usando um processo formal com critérios estabelecidos para avaliação das alternativas identificadas. Para efeitos de orientação e aderência a este propósi-to, são esperados 7 resultados (DIAS et al., 2010, p.9):
GDE 1: Guias organizacionais para a gerência de decisões são estabelecidos e mantidos; GDE 2: O problema ou questão a ser objeto de um processo formal de tomada de
deci-são é definido;
GDE 3: Critérios para avaliação das alternativas de solução são estabelecidos em ordem de importância, de forma que os critérios mais importantes exerçam mais influência na avaliação;
GDE 4: Alternativas de solução aceitáveis para o problema ou questão são identificadas; GDE 5: Os métodos de avaliação das alternativas de solução são selecionados de acordo
com sua viabilidade de aplicação;
GDE 6: Soluções alternativas são avaliadas usando os critérios e métodos estabelecidos; GDE 7: Decisões são tomadas com base na avaliação das alternativas utilizando os
cri-térios de avaliação estabelecidos.
Um dos mais críticos elementos de suporte para o aprendizado organizacional é a inte-gração da solução técnica em atividades diárias de trabalho. Isso porque a captura e represen-tação do conhecimento não são consideradas um dos fatores mais importantes para o aprendi-zado, mas sim a aplicação de práticas que incorporam o uso do conhecimento existente como parte do fluxo de trabalho e base para a execução das atividades (HENNINGER, 2001 p.10).
Semelhante ao MPS.BR, o CMMi (Capability Maturity Model Integration) é uma abordagem de melhoria de processos e definição de maturidade organizacional, considerado como referência no cenário atual. Trata-se de um modelo internacional, criado pela SEI (
como guia, elencando elementos essenciais para a construção de processos efetivos, caracteri-zando, na representação por estágios, 5 níveis de maturidade organizacional (FIGUEIREDO, 2006).
No intuito de apoiar tomadas de decisões, o nível de maturidade 3 do CMMi prevê a área de processo Análise de Decisão e Resolução (DAR), o qual preconiza 6 práticas específi-cas (CHRISSIS et al., 2006): (i) definir guias para a análise de decisões; (ii) definir critérios de avaliação; (iii) identificação de alternativas de solução; (iv) selecionar métodos de avalia-ção; (v) avaliar alternativas usando critérios e métodos previamente definidos e (vi) selecionar alternativas, baseadas em avaliação de critérios.
2.2.2 Desenvolvimento ágil
O desenvolvimento ágil tornou-se popular em 2001 através de um pequeno grupo de dezessete especialistas em processos de desenvolvimento de software que se reuniu em Utah (Estados Unidos da América) no intuito de estabelecerem princípios padrão para este tipo de desenvolvimento, criando assim a aliança ágil, estabelecendo posteriormente o Manifesto Ágil. Este manifesto, cujas ideias começaram a ser esboçadas desde 1990 no intuito de vencer as fraquezas percebidas na engenharia de software convencional, é formado pelos seguintes conceitos (PRESMAN, 2006):
Indivíduos e Iterações são considerados mais que processos e ferramentas;
Software funcionando é considerado mais importante que documentações abrangentes; Colaboração com o cliente é considerada mais relevante que negociação de contratos; Resposta a mudanças é considerada mais importante que seguir um plano determinado.
Além destes conceitos, há doze princípios para o alcance da agilidade (BECK et al., 2001):
1. Prioridade mais alta é a satisfação do cliente através de entregas rápidas e contínuas de software com valor agregado;
2. Mudanças em requisitos são bem vindas, até mesmo de forma tardia no desenvolvimen-to;
3. Entregas frequentes de software, de poucas semanas a poucos meses, sempre preferen-cialmente em uma escala mínima de tempo;
4. Pessoas de negócio e desenvolvedores devem trabalhar juntas diariamente durante o projeto;
um ambiente e o suporte necessário para essas pessoas, confiando neles para obter o trabalho realizado;
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa cara-a-cara;
7. Software funcionando é a medida primária para o progresso;
8. Os processos ágeis promovem desenvolvimento sustentável. Patrocinadores, desenvol-vedores e usuários devem ser capazes de manter um ritmo constante de forma indefini-da;
9. A atenção à excelência técnica e ao bom design devem ser contínuas aumentando a agi-lidade;
10. Simplicidade, considerada aqui como a arte de maximizar a quantidade de trabalho não realizado, é essencial, devendo ser assumida em todos os aspectos do projeto;
11. As melhores arquiteturas, requisitos e designs surgem de equipes auto-organizáveis; 12. Em intervalos regulares, a equipe reflete sobre como ser tornar mais eficaz e então
refi-na e ajusta seu comportamento, de acordo com suas conclusões.
Jacobson (2002, apud HICKMANN JUNIOR e YANZER, p. 3) enxerga a agilidade da seguinte forma:
Agilidade tornou-se atualmente uma palavra mágica quando se descreve um procso de desenvolvimento de procsoftware. Tudo é ágil. Uma equipe ágil é uma equipe es-perta, capaz de responder adequadamente a modificações. Modificação é aquilo para o qual o desenvolvimento de software está principalmente focado. Modificações no software que está sendo construído, modificações nos membros da equipe, modifi-cações por causa de novas tecnologias, modifimodifi-cações de todas as espécies que po-dem ter impacto no produto que eles constroem ou no projeto que cria o produto. O apoio para modificações deveria ser incorporado em tudo que fazemos em software, algo que se adota porque está no coração e na alma do software. Uma equipe ágil re-conhece que o software é desenvolvido por indivíduos trabalhando em equipes e que as especialidades dessas pessoas e sua capacidade de colaborar estão no âmago do sucesso do projeto.
Pressman (2006) sugere ainda algumas características do processo que deveriam ser adotadas por equipes de software, dentre as quais são citadas:
Colaboração: devem disponibilizadas informações que auxiliem o cliente e equipe do projeto e entende o trabalho realizado, agregando valor ao negócio. Para isso, faz-se ne-cessária a prática de colaboração entre os membros da equipe;
Capacidade de tomada de decisão: é necessária autonomia para a tomada de decisão so-bre os mais variados tópicos do projeto;
resolvido atualmente pode não corresponder a um mesmo problema no futuro. Para isso, a equipe do projeto deve ter a capacidade de lidar continuamente com mudanças.
Beck et al. (2001) considera que o desenvolvimento ágil se resume à eficácia da equi-pe em responder mudanças, caso as seguintes reduções sejam realizadas: (i) de custo de mo-vimentação de informação entre pessoas, melhorando o clima de equipe, favorecendo o senso de comunidade e moral de modo que as pessoas fiquem mais propensas a compartilhar infor-mações valiosas de forma rápida, e (ii) de tempo utilizado para tomadas de decisão, na avalia-ção das suas consequências.
O desenvolvimento ágil também prega reuniões diárias de curta duração (preferenci-almente não ultrapassando quinze minutos) na qual os pontos relevantes (problemas, depen-dências, riscos, marcos, dentre outros) ao andamento do projeto são discutidos, no intuito de promover o monitoramento e feedback. Está prática promove a comunicação entre a equipe do projeto facilitando a comunicação dos problemas encontrados e sua resolução de forma muito mais rápida. No entanto, as ações corretivas para os impedimentos identificados são tomadas sem a existência de registros em planos, nem documentação relativa a isso, nem aná-lise de resultados para determinar a eficácia das ações corretivas tomadas (ADM, 2003).
Em complementação, o ciclo de vida desse tipo de processo é caracterizado por ser curto e propício a projetos em que o sistema sofra mudanças de requisitos frequentemente (DIAS et al., 2010, p. 3).
Diante do exposto, pode-se perceber que o conhecimento é complexo, mas não é caó-tico. Uma boa representação torna explícitas as informações aos demais envolvidos (SCHREIBER et al., 2002). Mas para que o conhecimento possa ser gerido de forma eficaz é necessária a adoção de alguma técnica que auxilie a sua representação.
2.3 DESIGN RATIONALE
O registro de informações relativas às decisões é considerado de significativa impor-tância, pois soluções analisadas e adotadas em projetos passados podem ser úteis para situa-ções vivenciadas no presente, uma vez que erros cometidos podem ser evitados e solusitua-ções adotadas podem ser aprofundadas (SOUZA et al., 1998).
decisões e avaliações. Ou seja, DR corresponde à documentação das decisões do projeto, jun-tamente com as alternativas consideradas, as avaliações, argumentações e justificativas que conduziram a escolha de uma solução.
Burge e Brown (2000) ressaltam que a documentação existente em processos de de-senvolvimento de software é muito importante para o resultado do produto gerado, porém elas acabam registrando apenas as últimas decisões de cada fase. Isso ocorre devido ao esforço, considerado oneroso, para registrar todas as alternativas investigadas.
De forma geral, uma “rationale” é uma justificação por trás de uma decisão (DU-TOIT, 2006). Aplicando a um projeto, “design rationale” é a razão pela qual um produto está. Esta técnica corresponde ao coproduto de design ao longo da produção de um artefato, captu-rando as decisões e dificuldades encontradas em determinado momento de um projeto.
Intrinsecamente, pode-se valorar a elaboração de um DR de acordo com a melhora de
performance da gestão por processos ou mesmo de projetos, fornecendo uma forma unificada
de documentar decisões e proporcionar o amadurecimento de soluções.
Esse valor favorece a comunicação entre os diversos envolvidos em projetos, sejam eles participantes de diferentes equipes e funções. A comunicação estabelecida por essa técni-ca subsidia o processo de manutenção, pois promove o entendimento da estratégia de um arte-fato, podendo apresentar restrições e impactos relacionados à sua mudança.
2.3.1 História do Design Rationale
Toulmin (1958) pode ser considerado o precursor de esquemas de representação gráfi-ca semiformal para visualização de argumentos baseados em DR. Nessa representação, um argumento é composto por um fato ou observação; um passo lógico e uma assertiva. A justifi-cativa era apoiada ou por um material de apoio ou por uma explicação.
Conklin (1989) enxergou no DR a importância para o processo de manutenção. De acordo com o autor, as atividades de manutenção podem ser influenciadas pelas decisões to-madas no projeto. Dessa forma, as suposições efetuadas, alternativas rejeitadas, critérios e requisitos considerados influenciariam no grau de qualidade, confiança e tempo na execução de demandas de manutenção.
pela representação de argumentos.
Além disso, Carroll e Moran (1991) concluíram que o design rationale, quando apli-cado em problemas reais, demonstra não apenas a solução de problemas difíceis, ou mesmo uma reflexão sobre a melhor solução, mas ilustra os mais variados tipos de resoluções do pro-blema, considerando características distintivas, sem a intenção de apresentar soluções singu-larmente corretas. Dessa forma, de acordo com os autores, dependendo do aspecto a ser con-siderado, um problema possui potencial de conter soluções ilimitadas, considerando efeitos colaterais e diferentes contextos de aplicação.
Em 1996, DR foi referido por Gruber e Russel como explicações sobre o raciocínio do projeto, correspondendo à representação do Como e do Porque um artefato, ou componente foi construído ou projetado, ou mesmo como uma solução de projeto foi definida.
Hu (2000) definiu o DR como a justificativa da decisão tomada para a elaboração de um artefato do projeto ou parte dele, incluindo a representação de suas razões, alterações e de todas as demais decisões intermediárias.
Francisco (2004) entendeu que a limitação da memória humana pode ser considerada um importante motivador para a preservação do DR. Com o passar do tempo, os seres huma-nos não preservam de forma completa e fiel algumas informações. O autor considerou o DR como solução para essa problemática, proporcionando a lembrança de toda a razão por detrás da solução, diminuindo as ocorrências de perpetuação de erros já cometidos ou mesmo de soluções ineficientes.
No decorrer dos anos, diferentes abordagens foram criadas para o DR. A sua represen-tação pode seguir três perspectivas: a argumenrepresen-tação, a comunicação e a documenrepresen-tação (SHIPMAN e McCALL, 1997). Dessa forma, a argumentação e a documentação têm seu foco voltado para as decisões do projeto e para a razão por detrás delas. O que as difere é que a primeira tem como objetivo adicional estruturar como o decisor abordou o problema; e a se-gunda tem como objetivo principal fornecer conhecimento sobre o projeto a pessoas externas. A perspectiva de comunicação é uma tentativa de preservar a comunicação do projeto (e-mails, minutas de reunião, etc) em tempo real (BURGE e BROWN, 2000).
Quadro 1: Perspectivas de Representação o DR (FRANCISCO, 2004)
Perspectivas Características
da informação Argumentação Comunicação Documentação Conteúdo Semiestruturado Não estruturado Estruturado Nível de detalhamento da
informa-ção armazenada em relainforma-ção à pro-duzida durante as discussões
Médio (analítica e
sintetizada) Alto (Analítica) Baixa (Sintetizada) Momento da Captura Durante a discussão Durante a discussão Após a discussão Esforço/Atividade requerido(a) no
momento da discussão Classificar os nós e links Não possui Não possui Esquemas de representação Nós e links Diversas mídias Linear
São muitas as notações para representar a argumentação, dentre elas são consideradas como destaque as seguintes (FRANCISCO, 2004):
Issue Based Information System (IBIS): modelo baseado em questões, representando a argumentação por meio de questões (problemas), posições (respostas) e argumentos (prós e contras);
Procedural Hierarchy of Issues (PHI): extensão do IBIS, representando a argumentação por meio de Questão, Subquestão, Resposta, Sub-Resposta, Argumento e Subargumen-to.
Question Option Criteria (QOC): nesse modelo os nós são Questão, Opção e Critério. O destaque dessa notação em relação às demais está no nó Critério, que possibilita a cap-tura explícita dos critérios, que influenciaram na tomada da decisão.
Decision Rationale Language (DRL): assim como PHI, também é uma extensão do IBIS, no entanto, envolve um número maior de abstrações e relacionamentos (Proble-ma, Decisão, Objetivo, Alternativa, Alegação, Questão, Procedimento e Grupo).
Além disso, de acordo com Burge (2005), a representação do DR pode ser implemen-tada seguindo uma abordagem formal (computador representando o dado sem necessariamen-te ser compreendido por uma pessoa), informal (facilmennecessariamen-te compreendido por pessoas, mas sem utilização por máquina) ou semiformal (combinação entre a formal e informal).
2.3.2 Funcionamento do Design Rationale
O ponto forte do DR é que a sua captura garante a preservação de informações relaci-onadas a tomadas de decisões importantes em um projeto. Porém, para que isso seja possível se faz necessário o desenvolvimento de uma representação que contemple as seguintes ques-tões: O que é apropriado representar? Como poderia ser usada a representação? Que alternati-vas são pensadas para a resolução de uma questão? Porque determinada solução foi adotada? Que feedbacks foram oferecidos ao longo do tempo em que determinada solução foi utiliza-da?
Além disso, é de vital importância assegurar que os assuntos essenciais serão óbvios a outras pessoas, que possam vir a consultá-los posteriormente, pois promoveria a visibilidade de todas as ideias que auxiliaram na condução do projeto até o presente momento, facilitando a continuidade na mesma linha de raciocínio ou até mesmo a integração de novos participan-tes.
Dessa forma, a captura do DR auxilia: (i) a resolução de problemas de naturezas seme-lhantes; (ii) a compreensão do design de um produto; (iii) a manutenção de um produto, evi-tando o esquecimento do porquê da adoção de determinadas soluções; (iv) a avaliação de im-pacto de mudanças ou inclusão de novos requisitos; (iv) a comunicação entre equipes; (v) o acompanhamento e a descoberta de erros durante o processo; e (vi) a redução de arbitrarieda-de no processo arbitrarieda-de tomada arbitrarieda-de arbitrarieda-decisão, visto que é embasado por atributos que auxiliam a justi-ficativa de uma escolha em detrimento de outras (SOUZA et al., 1998).
O grande destaque desse paradigma é a preocupação na preservação das alternativas envolvidas em um processo decisório. Geralmente, durante esse processo, várias soluções são consideradas, porém apenas uma delas é adotada. Para o DR, a preservação das alternativas consideradas, mas não usadas, juntamente com a justificativa de descarte é considerada tão importante quanto à solução adotada e sua justificativa.
No entanto, a representação do DR nem sempre acontece conforme esperado. Horner e Attowood (2006) investigaram as barreiras para o uso do DR e as dividiram nas seguintes áreas:
Cognitiva, envolvendo limitação de processamento humano de informações que torna impossível a captura exaustiva de um raciocínio;
Captura, onde as barreiras envolvem dificuldades em elicitar o conhecimento tácito; a falta de incentivos para a captura; a dificuldade em perceber os prováveis benefícios; os custos envolvidos e o risco de expor um funcionário, caso sua decisão não tenha sido satisfatória;
ser armazenado e quais serão os métodos usados para recuperação;
Uso, visto como as limitações envolvendo a aplicabilidade do reuso efetivo do raciocí-nio.
São as estratégias definidas para a representação do DR que determinam a forma como ocorrerá a recuperação (HU et al., 2000). Dessa forma, recuperações do DR podem ser classi-ficadas de acordo com sua iniciativa: usuário e sistema (LEE, 1997).
Um sistema com iniciativa do usuário depende do usuário para decidir o que do DR será preservado ou mesmo consultado (LEE, 1997).
Por outro lado, um sistema com iniciativa do sistema é caracterizado por atribuir ao próprio sistema a responsabilidade de decidir quando e como serão apresentadas as informa-ções (LEE, 1997).
Diante do exposto, o DR proporciona uma orientação para a representação de um pro-blema, no intuito de retratá-lo de forma íntegra e completa, proporcionando uma possível re-cuperação capaz de auxiliar tomadas de decisão.
2.4 RACIOCÍNIO BASEADO EM CASOS
De acordo com Wangenheim, C. e Wangenheim, A. (2003, p. 1), a ideia básica do RBC é a resolução de um problema novo baseado em informações de situações anteriores e similares. Dessa forma, um novo problema pode ser resolvido a partir da reutilização de uma solução aplicada anteriormente.
Esta proposição iniciou-se através de pesquisas realizadas por Kolodner (1992), que vislumbrava uma nova fronteira no campo da inteligência artificial, proporcionando o des-prendimento sensível da dependência de um especialista no domínio da situação para a reso-lução de um problema.
Para que esta proposta seja passível de ser realizada, cada conhecimento de um pro-blema é representado por um caso contextualizado, registrando um episódio em que uma situ-ação problemática foi considerada resolvida (seja total ou parcialmente). Um caso é caracteri-zado através de uma situação de problema associada com sua respectiva solução. Por inter-médio de similaridades, um problema novo pode fazer uso de casos antigos, adaptando a so-lução adotada de acordo com a necessidade da nova situação (WANGENHEIM, C. e WAN-GENHEIM, A., 2003, p. 11).
conheci-mento:
Representação de casos: é um dos pontos mais críticos do RBC, pois um caso deve ser estruturado de tal forma que permita uma indexação apropriada para uma recuperação útil e rápida;
Recuperação de casos: Inicia a partir da necessidade de resolver um novo problema e termina com o retorno da melhor solução disponível na base. Para que essa operação ocorra conforme o esperado, é necessário estabelecer, por meio de objetivos claros, quais critérios melhor representam um problema e qual o tipo de similaridade será con-siderada: níveis estáticos, semânticos e de funcionalidade. Dessa forma, o processo de recuperação de dados deve ser capaz de descartar os casos pouco significativos mos-trando apenas aqueles que ofereçam maior proximidade da solução;
Reuso de casos: Nesta etapa duas são as possibilidades: cópia integral da solução recu-perada ou sua adaptação para a nova realidade;
Revisão de casos: Neste processo será avaliado o sucesso ou a falha da solução adotada. Ambas as situações precisam ser armazenadas na base de casos, porém, para os casos que caracterizarem falhas, é necessário identificar as razões para esse resultado, contri-buindo para futuramente evitar a ocorrência de falhas semelhantes;
Retenção de casos: também conhecido como processo de aprendizado, consiste na apro-priação de resultados, anteriores e o atual, para melhorar a qualidade das soluções obti-das. Dessa forma, será realizada uma avaliação visando identificar se o novo caso será incluído na base ou se será apenas a atualização de um caso antigo.
De acordo com Aamodt (1994), a descrição de um problema define um novo caso, o que dispara, através de um mecanismo de RBC, a recuperação de experiências similares pas-sadas, no intuito de auxiliar a resolução do problema através do reuso de soluções. Dependen-do da coleção de experiências encontradas, uma solução pode ser totalmente ou parcialmente aproveitada. Caso exista um problema idêntico ao atual, a solução será reusada na sua totali-dade. Porém, uma solução passada pode servir de insumo para inferências da atual, resultando numa adaptação da versão anteriormente utilizada para atender a nova problemática.
Para que o ciclo do raciocínio baseado em casos seja capaz de auxiliar na resolução de um problema, faz-se necessária a existência de experiências passadas na base de pesquisa; caso contrário, nenhum resultado será apresentado.
2000). Porém, para que a manipulação computacional de casos ocorra de forma efetiva, de-vem ser considerados alguns aspectos relacionados à gestão do conhecimento.
De acordo com Shiu e Pal (2004), o RBC deve ser utilizado em cenários que compre-endam as seguintes características: (i) seja impossível de compreender perfeitamente o domí-nio; (ii) existem exceções em novas situações; (iii) o problema ocorre de forma recorrente;
(iv) é vantajosa a adaptação de uma situação para a resolução de outra; (v) Situações anterio-res fornecem insumos significativos para novas situações.
Ainda de acordo com Shiu e Pal (2004), o uso do RBC pode proporcionar as seguintes vantagens: (i) redução de esforço na aquisição de conhecimento; (ii) evitar reincidência de erros; (iii) flexibilidade na modelagem do conhecimento, pois são representados de forma gradativa à medida que os casos são reutilizados; (iv) refinamento das soluções, gerando re-sultados mais confiáveis; (v) Flexibilidade de uso, pois pode ser aplicado em diferentes domí-nios.
2.4.1 História do Raciocínio Baseado em Casos
Podem ser considerados como precursores de pesquisas sobre RBC em Inteligência Artificial, os trabalhos de Schank e Abelson (1977) sobre Memória Dinâmica com o propósito de criar modelos cognitivos da solução de problemas, favorecendo o aprendizado de situa-ções. Nestes estudos, Schank e Abelson propuseram que o conhecimento humano relacionado às situações vivenciadas fica registrado na memória como se fossem roteiros, permitindo a construção de expectativas sobre resultados esperados. Roteiros foram propostos no início de 1980, caracterizando eventos rotineiros do dia-a-dia (como uma ida ao médico ou a um res-taurante) no intuito de auxiliar a análise desses eventos ou mesmo das atividades, através de previsões de ações tipicamente realizadas (WANGENHEIM, C. e WANGENHEIM, A., 2003, p. 29-31).
Gick e Holyoak (1983), também no início dos anos 80, estudavam outra linha que con-tribuiu significativamente para a teoria do RBC: o estudo por analogia. No raciocínio analógi-co é utilizada a transferência de domínio para solucionar um novo problema:
Se um peixe nada batendo as barbatanas e empurrando a água para trás, posso inventar um objeto chamado remo que pode servir para impulsionar um barco realizando movimentos rítmicos que empurram a água para trás.
