Gestão Do Conhecimento em Processos de Engenharia de Software em Organizações Empresariais

LICENCIATURA EM SISTEMAS E TECNOLOGIAS DE INFORMAO
GESTO DO CONHECIMENTO EM PROCESSOS DE ENGENHARIA DE

SOFTWARE EM ORGANIZAES EMPRESARIAIS
Projeto Final de Licenciatura
Elaborado por Paulo Srgio dos Santos Carreteiro

Discente n 20131827
Orientador Professor Doutor Jos Braga de Vasconcelos
Barcarena
Junho de 2016
Universidade Atlntica
Licenciatura em Sistemas e Tecnologias de Informao
GESTO DO CONHECIMENTO EM PROCESSOS DE ENGENHARIA DE

SOFTWARE EM ORGANIZAES EMPRESARIAIS
Projeto Final de Licenciatura
Elaborado por Paulo Srgio dos Santos Carreteiro

Discente n 20131827
Orientador Professor Doutor Jos Braga de Vasconcelos
Barcarena
Junho de 2016
Gesto do Conhecimento em Processos de Engenharia de Software em Organizaes Empresariais Licenciatura
em Sistemas e Tecnologias de Informao
Agradecimentos
O desporto e a corrida ensinaram-me duas coisas, em primeiro lugar que o mais importante no
como se comea uma prova mas sim como se acaba e em segundo lugar que os desafios que
se apresentam como mais difceis, so os que nos ensinam mais e que acabam por nos tornar
mais fortes. A minha motivao e a fora de vontade foram importantes para superar esta
maratona, mas o apoio e a ajuda de familiares, amigos, colegas e docentes tornaram com que o
percurso que muitas vezes parecia uma subida ngreme se tornasse numa inclinao
ligeiramente acentuada.
Agradeo ao Professor Doutor Jos Braga de Vasconcelos por todo o apoio, orientao e
colaborao neste trabalho, pelos desafios que me foi lanando ao longo de toda a licenciatura,
essenciais no meu crescimento acadmico, tornando-se sem dvida um dos professores mais
marcantes.
Ao Professor Doutor Alexandre Baro um agradecimento especial pela ajuda e orientao na

elaborao do artigo cientfico, que foi aceite na conferncia World Cist 2016. Ao restante
corpo docente da Universidade Atlntica, o meu obrigado pelo conhecimento transmitido.
Uma palavra aos meus colegas de curso por toda a ajuda, trocas de opinies, ideias e momentos
divertidos que proporcionaram durante a licenciatura, de todos um agradecimento especial ao
Nuno Silva pela ajuda, dicas e partilha do seu valioso conhecimento que foi essencial em muitas
etapas da licenciatura.
minha famlia e amigos pela fora e palavras de incentivo o meu sincero obrigado, minha
me em especial que no pode assistir em vida a um dos seus grandes desejos, estou certo que
esteve presente durante este percurso.
Por ltimo minha mulher Lgia, principal motivadora para o meu ingresso nesta licenciatura,
aos meus filhos Afonso e Letcia, os trs so os meus pilares, pelo amor, apoio incondicional e
por me terem libertado para que me pudesse focar durante todo este tempo. A todos o meu
obrigado!
Objetiva a genialidade que possuis, seno impera a preguia.
Lusa Carreteiro
Paulo Carreteiro Junho 2016 Universidade Atlntica iii

Lista de Abreviaturas
ETL - Extraction Transformation Load
MS - Manuteno de Software
GC - Gesto do Conhecimento
ES - Engenharia de Software
CVDS - Ciclo de Vida de Desenvolvimento de Software
SWEBOK - Software Engineering Body of Knowledge
DSR - Design Science Research
CMMI - Capability Maturity Model Integration
RD - Requirement Definition
TS - Technical Solution
VAL - Validation
VER - Verification
PI - Product Integration
BRS - Business Requirements Specification
SRS - Software Requirements Specification
PRS - Project Requirements Specification
UML - Unified Modelling Language
Paulo Carreteiro Junho 2016 Universidade Atlntica iv

Resumo
A Manuteno de Software a ultima fase do ciclo de vida do desenvolvimento de software e

a sua atividade visa a correo de incidentes. Os indivduos que nela participam necessitam de
dominar um conjunto significativo de competncias. Adicionalmente muitos destes problemas
quando ocorrem exigem intervenes rpidas por originarem indisponibilizao do negcio ou
causarem impactos significativos noutras aplicaes ou sistemas.
Nas fases anteriores dos projetos de desenvolvimento de software, gerado um nmero

significativo de documentao sobre o software que est a ser produzido, onde so descritas
funcionalidades, regras e condies referentes ao funcionamento do mesmo. Apesar da
existncia de toda essa documentao muito raramente ela utilizada pelos indivduos que
efetuam a manuteno, que acabam por recorrer interpretao da linguagem de programao
do software ou a trocas informais de ideias, gastando grande parte do tempo da manuteno a
tentar perceber o que est a ser mantido.
Neste trabalho abordada a implementao da Gesto do Conhecimento na Manuteno de

Software, em primeiro lugar como forma de tornar mais eficiente esta atividade e em segundo
utiliz-la como ferramenta para validar, corrigir e atualizar o conhecimento produzido
anteriormente, utilizando o back flushing dos processos de ETL do Data Warehousing.
Palavras-chave Gesto do Conhecimento; Engenharia de Software; Ciclo de Vida do

Desenvolvimento de Software; Manuteno de Software.
Paulo Carreteiro Junho 2016 Universidade Atlntica v

Abstract
Software Maintenance is the last phase of the software development lifecycle and its activity is
aimed at correcting incidents. Individuals who participate need to master a significant set of
skills. In addition when many of these problems occur require rapid interventions for yielding
unavailability of business or cause significant impacts in other applications or systems.
In previous phases of software development projects, it is generated a significant number of

documents of the software that is being produced, where are described features, rules and
conditions related to its functioning. Despite the existence of all this documentation seldom it
is used by individuals who perform maintenance, who end up resorting to interpretation of
software programming language or informal exchanges of ideas with their peers, spending
much of the maintenance time trying to understand what it is to be maintained.
This paper discusses the implementation of Knowledge Management in Software Maintenance,

first as a way to become more efficient this activity and secondly to use it as a tool to validate,
correct and update the knowledge produced previously using the "back flushing " a processes
from ETL in Data Warehousing .
Keywords Knowledge Management; Software Engineering; Software Life Cycle; Software

Maintenance.
Paulo Carreteiro Junho 2016 Universidade Atlntica vi

NDICE
Introduo ......................................................................................................................... 1
1 Definies e Conceitos da Gesto do Conhecimento e da Engenharia de Software. 4
1.1 O Conhecimento e a sua Gesto .................................................................................. 4
1.1.1 Definio e Nveis do Conhecimento ................................................................... 4
1.1.2 Caractersticas do Conhecimento ......................................................................... 4
1.1.3 A Gesto do Conhecimento .................................................................................. 4
1.2 Engenharia de Software ............................................................................................... 6
1.2.1 Definio .............................................................................................................. 6
1.2.2 Caractersticas....................................................................................................... 6
1.2.3 Fases do Ciclo de Vida do Desenvolvimento ....................................................... 7
2 A Gesto do Conhecimento em Projetos de Desenvolvimento de Software .......... 10
2.1 Desafios Organizacionais........................................................................................... 10
2.2 A Reificao de Conhecimento nas Organizaes .................................................... 11
3 Metodologia de Investigao .................................................................................. 14
3.1 Design Science Research ........................................................................................... 14
3.2 Orientaes de Investigao ...................................................................................... 15
3.2.1 Desenho do Artefacto ......................................................................................... 16
3.2.2 Importncia do problema .................................................................................... 16
3.2.3 Desenho do artefacto como processo de pesquisa .............................................. 17
4 Gesto do Conhecimento na Engenharia de Software ............................................ 18
5 Modelo MIMIR ....................................................................................................... 21
5.1 Introduo ao Modelo ................................................................................................ 21
5.1.1 CMMI ................................................................................................................. 21
5.1.2 CMMI for Development ..................................................................................... 23
Paulo Carreteiro Junho 2016 Universidade Atlntica vii

5.2 Viso de Alto-nvel do Modelo e atores .................................................................... 30
5.3 Captura de conhecimento da Definio de Requisitos .............................................. 32
Concluso e trabalho futuro ............................................................................................ 36
Bibliografia ..................................................................................................................... 38
Anexos ............................................................................................................................ 40
A Knowledge Management Approach for Software Engineering Projects Development ... 40
Paulo Carreteiro Junho 2016 Universidade Atlntica viii

NDICE DE FIGURAS
Figura 1 - Ciclo de Vida da Gesto do Conhecimento adaptado (Rus, Lidvall, & Sinha,
Knowledge Managment in Sofware Engineering, 2001) ........................................................... 5
Figura 2 - Fases do Ciclo de Vida dos Projetos de Desenvolvimento de Software ................... 8
Figura 3 - Relao entre o ciclo de vida da Gesto do Conhecimento e os Projetos de
Desenvolvimento de Software .................................................................................................. 12
Figura 4 - Segmentao de CVDS de acordo com os seus outputs e necessidades ................. 19
Figura 5 - As trs dimenses crticas numa organizao (Software Engineering Institute,
Novembro 2010) ....................................................................................................................... 23
Figura 6 reas de processo da Engenharia no modelo CMMI-DEV (Software Engineering
Institute, Novembro 2010) ........................................................................................................ 24
Figura 7 Exemplo de parte do documento de requisitos de negcio ..................................... 25
Figura 8 - Exemplo de parte do documento de requisitos de funcionais .................................. 26
Figura 9 - Exemplo de parte do documento de tcnico ASP/JSP ............................................. 27
Figura 10 - Exemplo de parte do documento de peer review ................................................... 28
Figura 11 - Exemplo de parte do documento de plano de testes .............................................. 29
Figura 12 - Exemplo de parte do documento do plano de integrao ...................................... 30
Figura 13 - Modelo MIMIR (Alto Nvel) (Carreteiro, Vasconcelos, Baro, & Rocha, 2016) . 31
Figura 14 Modelo MIMIR para a fase de Definio de Requisitos (Carreteiro, Vasconcelos,
Baro, & Rocha, 2016) ............................................................................................................. 33
Paulo Carreteiro Junho 2016 Universidade Atlntica ix

INTRODUO
A Manuteno de Software (MS) uma atividade exigente e complexa, os indivduos que nela
participam precisam de dominar as linguagens de programao utilizadas no software, conhecer
a arquitetura do sistema, entender os modelos de dados, ter um conhecimento funcional das
aplicaes e saber as atualizaes que sobre estes so realizadas bem como os impactos
associados. Adicionalmente e derivado da escassez de recursos, cada vez mais a MS efetuada
a vrias aplicaes, obrigando a gerir uma quantidade significativa e complexa de informao.
Esta atividade habitualmente entregue a indivduos com maior experincia dentro da

organizao, decorrente da sua senioridade e heursticas obtidas ao longo dos anos nos diversos
projetos de desenvolvimento de software. Esta preferncia vem reforar o elevado grau de
exigncia, conhecimento, sensibilidade e experincia necessria por parte de quem as realiza,
devido criticidade que representam e urgncia com que as mesmas devem ser realizadas.
No decorrer dos projetos de Engenharia de Software (ES) so produzidos um elevado nmero

de documentos, que pela dificuldade em serem pesquisveis e indexados, raramente so
utilizados no auxlio resoluo de problemas e muitas vezes no se encontram devidamente
atualizados, apesar de terem como principal objetivo descrever todo o conhecimento
identificado durante a realizao dos projetos.
Constata-se que os indivduos que participam na MS, acabam maioritariamente por recorrer
interpretao da linguagem de programao ou a uma troca informal de ideias com outros
membros da equipa, o que faz com que entre 40% a 60% do tempo consumido no processo de
MS gasto na compreenso do software que est a ser mantido.
A Gesto do Conhecimento (GC) surge com o objetivo de otimizar o conhecimento individual

das organizaes. Identifica o conhecimento existente nas organizaes, quem o detm, quando
e como foi gerado, a GC propem-se assim a geri-lo mais eficazmente. nica porque incide
sobre o indivduo como um especialista e como portador do conhecimento relevante que ele
pode partilhar sistematicamente com a organizao.
Da experincia tida e da reviso da literatura efetuada, constata-se:

A implementao da Gesto do Conhecimento na Engenharia de Software tem sido mais

focada nas fases de requisitos, desenho e codificao tendo ficado a MS para segundo
plano;
O acesso a informao relevante, ou seja, de onde se possam obter respostas que
contenham solues concretas ou com a orientao para a resoluo dos erros com que
os indivduos so confrontados, um dos principais problemas na realizao de tarefas
de MS.
Como poder a MS beneficiar da adoo de mtodos de GC? A captura do conhecimento gerado

na manuteno pode ser utilizado como meio para validar, atualizar e corrigir o conhecimento
documentado nas fases anteriores?
Neste trabalho apresentado um modelo onde mapeado, catalogado e armazenado o

conhecimento mais relevante para a MS, a partir dos documentos criados nas diversas fases do
ciclo de vida da ES, tornando o acesso ao mesmo mais eficiente e fcil, visando reduzir o tempo
gasto atualmente. O modelo ir tambm permitir que as equipas de MS sejam utilizadas para
validar, corrigir e atualizar o conhecimento criado em fases anteriores, para tal no modelo
utilizado uma analogia com a tcnica de back flushing utilizada nos processos de ETL1.
Este trabalho encontra-se organizado da seguinte forma: No primeiro captulo so apresentadas

as definies e caractersticas da GC nas organizaes, da ES e explicadas as fases do CVDS
bem como as principais atividades nelas realizadas. No segundo captulo demonstra-se a ligao
entre os conceitos da GC e as atividades da ES no sentido de demonstrar a relao de
proximidade entre ambos, provando que o desenvolvimento de software uma atividade de
conhecimento intensivo. Os dois primeiros captulos pretendem expor os alicerces onde este
trabalho assenta, essenciais para realizar o respetivo enquadramento. No terceiro captulo
apresentada a metodologia seguida para a realizao do trabalho e conceo do modelo. No
captulo quatro efetuada uma introduo sobre a abordagem deste trabalho para a
implementao de uma iniciativa de GC na ES. No captulo quinto apresentado o modelo, os
1
Do ingls Extract Transform Load (Extrao Transformao Carregamento), so ferramentas de software cuja funo a extrao de dados
de diversos sistemas, transformao desses dados conforme regras de negcio e por fim o carregamento dos dados.
Paulo Carreteiro Junho 2016 Universidade Atlntica 2

seus atores e o seu funcionamento onde introduzido o conceito de back flushing. Por ltimo,
apresentada a concluso do trabalho efetuado e identificado o trabalho futuro a realizar.

1 DEFINIES E CONCEITOS DA GESTO DO CONHECIMENTO

E DA ENGENHARIA DE SOFTWARE
1.1 O Conhecimento e a sua Gesto
1.1.1 Definio e Nveis do Conhecimento
consensual a existncia de trs nveis de refinamento nomeadamente dados, informao e por

fim conhecimento (Davenport, 2010), (Rus & Lindvall, Knowledge Management in Software
Engineering, 2002). Dados so os itens, valores, nomes, etc., informao que se encontra numa
forma no estruturada. Informao diz respeito a dados j estruturados, isto , que se encontram
organizados de uma forma lgica. Conhecimento quando j existe uma anlise realizada sobre
a informao que possibilita efetuar relaes entre os diversos tipos de informao que permite
efetuar classificaes, em suma informao sobre a informao.
1.1.2 Caractersticas do Conhecimento
O conhecimento pode ser explcito ou tcito e separado pela forma como est distribudo, ou
seja, onde pode ser aplicado, a quem est acessvel e que atividades so por ele suportadas.
Significa que o conhecimento existente nas organizaes pode residir nelas prprias, ao nvel
individual ou num grupo de pessoas.
assim possvel separar a informao propriamente dita, dos conhecimentos subjacentes s

pessoas, ou seja o conhecimento como um corpo de informao, como um saber individual e
como um saber em equipa (Casco, 2014). Enquanto um corpo de informao, ele encontra-se
de uma forma explcita e codificvel, nos outros dois ele de natureza tcita e pessoal ou
dependente da dinmica das equipas, sendo no entanto consensual que o conhecimento
existente nos indivduos a base para as restantes dimenses.
1.1.3 A Gesto do Conhecimento
A Gesto do Conhecimento visa atravs de ferramentas e processos otimizar o conhecimento

individual das organizaes para o gerir mais eficazmente, identificando onde que ele est,
quem o detm, quando e como foi gerado. nica porque incide sobre o indivduo como um
especialista e como o portador do conhecimento importante que ele pode partilhar
sistematicamente com a organizao (Rus, Lidvall, & Sinha, Knowledge Managment in
Sofware Engineering, 2001).
O seu ciclo de vida constitudo por um conjunto de processos/fases, conforme a Figura 1, que
visam de uma forma sistemtica e com o auxlio de ferramentas capturar o conhecimento tcito
existente na organizao, transform-lo em conhecimento explcito e organiz-lo para que
possa ser partilhado e utilizado, possibilitando a gerao de novo conhecimento.
Figura 1 - Ciclo de Vida da Gesto do Conhecimento adaptado (Rus, Lidvall, & Sinha,
Knowledge Managment in Sofware Engineering, 2001)
O conhecimento no uma receita, um procedimento definido para lidar com uma situao
concreta, uma situao de rotina. O conhecimento deve permitir lidar com diferentes situaes,
antecipar implicaes e avaliar os seus efeitos (Casco, 2014).

possvel estabelecer uma relao entre a ES e a GC? Estas so questes que sero
apresentadas no captulo seguinte.
1.2 ENGENHARIA DE SOFTWARE
1.2.1 Definio
De acordo com o SWEBOK2 a ES a aplicao de uma abordagem sistemtica, disciplinada e

quantificvel ao desenvolvimento, operao e manuteno de software.
A ES uma disciplina onde necessrio dominar tanto competncias sociais como tcnicas
(Alawneh, Hattab, & Al-Ahmad, 2008), nela so realizadas um conjunto complexo de tarefas,
que vo desde a identificao de requisitos, passando pelo design, a construo, os testes, a
implementao e finalmente a manuteno do software.
A ES visa a organizao, a produtividade e a qualidade atravs da aplicao de tecnologias e

prticas de gesto de projetos nas atividades relacionadas com o desenvolvimento de aplicaes
ou sistemas.
1.2.2 Caractersticas
De acordo com o SWEBOK a ES composta por um conjunto de reas de conhecimento que

so:
Requisitos de software;
Design de software;
Construo de software;
Teste de software;
Manuteno de software;
Gesto de configurao de software;
Gesto de engenharia de software;
Processos de Engenharia de Software;
2
Software Engineering Body Of Knowledge
Ferramentas e Mtodos de Engenharia de Software;

Qualidade de software.
As seis primeiras reas esto relacionadas com os processos de desenvolvimento de software

enquanto as quatro ltimas dizem respeito a mtodos e metodologias, ou seja, prticas para a
realizao dos processos.
Focando a anlise nos processos da ES, ou projetos de desenvolvimento de software,

identificam-se diversos modelos, alguns deles so:
Cascata;
Iterativo;
Modelo em V;
Espiral;
gil; entre outros.
Estes modelos, conhecidos como modelos de ciclo de vida do desenvolvimento de software

definem as atividades que permitem especificar e transformar requisitos de software no produto
final ou entregvel (Bourque & Fairley, 2014).
1.2.3 Fases do Ciclo de Vida do Desenvolvimento
No obstante a particularidade de cada projeto de desenvolvimento de software existem sempre

entre cada um deles alguns pontos em comum. Analisando os diversos modelos do ciclo de vida
dos projetos de desenvolvimento de software, verifica-se que maioritariamente so compostos
pelas fases indicadas na
Figura 2.

Figura 2 - Fases do Ciclo de Vida dos Projetos de Desenvolvimento de Software
A criao do conhecimento originado nos clientes ou stakeholders, atravs da identificao

de necessidades que visam melhorar a sua atividade. Os peritos efetuam a anlise realizando
reunies, entrevistas e questionrios capturando-o em documentos prprios de requisitos de
negcio. Estas anotaes so depois transformadas em documentos de desenho que servem de
transferncia entre o conhecimento do negcio e o conhecimento tcnico. A codificao e os
testes, que funcionam como provas de conceito, do cdigo gerado so a implantao sobre a
forma de software do conhecimento reunido. Depois de deviamente certificado o produto final
implementado, efetuando a sua partilha pelos diversos sistemas ou ambientes. Finalmente
entra numa atividade de manuteno com o objetivo corrigir problemas pontuais com o seu
uso.
H uma interao entre a equipa tcnica e os clientes, que so os donos do conhecimento do

negcio. Esses clientes devem transferir o conhecimento do negcio para os analistas, para que

eles possam desenvolver modelos que devem ajudar a transferir conhecimento do negcio ao
conhecimento tcnico em modelos que descrevem o software (Camacho, Sanches-Torres, &
Galvis-Lista, 2013).

2 A GESTO DO CONHECIMENTO EM PROJETOS DE

DESENVOLVIMENTO DE SOFTWARE
A dependncia em tecnologia por parte das organizaes continua a aumentar, fazendo com
que por um lado, os custos do desenvolvimento de software consumam uma fatia significativa
do oramento e por outro aumentem o volume e a diversidade da informao com que as
organizaes tm de lidar (Rus & Lindvall, Knowledge Management in Software Engineering,
2002), (Natali & Falbo, 2005).
A capacidade para eliminar os excessos sem perca de eficincia e qualidade so os desafios que
as organizaes de conhecimento intensivo tm de ultrapassar e o fator principal para uma
abordagem da GC sobre o CVDS. De seguida so apresentados alguns dos desafios para as
organizaes na implementao da GC, bem como o estabelecimento de uma relao entre os
projetos de desenvolvimento de software e a GC como introduo abordagem deste trabalho
sobre a sua implementao na ES.
2.1 DESAFIOS ORGANIZACIONAIS
Durante as diversas fases do CVDS produzido um volume significativo de documentos, que

servem para registar o conhecimento adquirido no decorrer de cada projeto. Lidar com a sua
utilizao um dos desafios das organizaes. A dificuldade em conseguir obter deles
informao significativa, aceder e pesquisar o que realmente importante num determinado
contexto, faz com que toda essa documentao no seja utilizada e difcil de partilhar, para alm
de que a forma como se encontra dispersa faz com que no seja atualizada (Rus & Lindvall,
Knowledge Management in Software Engineering, 2002), (Natali & Falbo, 2005).
Enquanto algum do conhecimento registado, existe outro que se mantm na mente dos
indivduos (Natali & Falbo, 2005), o que significa que no final do dia esse conhecimento deixa
a organizao. As heursticas que os indivduos adquirem ao longo de anos de experincia no
possvel de transmitir para outros no espao de meses, criando lacunas de conhecimento na
organizao quando estes indivduos deixam a organizao, algumas das vezes com
consequncias graves e complexas de resolver.
Gerir o conhecimento e os seus fluxos de extrema importncia para as organizaes, no

entanto a GC no produto que se possa adquirir, a GC leva o seu tempo, envolve processos,
tecnologia e acima de tudo pessoas e organizaes, de forma a criarem uma cultura de partilha
onde os primeiros devem participar e os segundos devem encorajar, GC = Pessoas + Processos
+ Tecnologia (Leistner, 2010).
2.2 A Reificao de Conhecimento nas Organizaes
O desenvolvimento de software uma atividade coletiva, complexa e criativa (Natali & Falbo,
2005). Os projetos de desenvolvimento de software so compostos por equipas de indivduos
multidisciplinares. So estas equipas que aplicam no seu dia-a-dia as fases do ciclo de vida do
desenvolvimento de software.
Ao realizarem estas atividades estas equipas, efetuam uma apropriao significativa do

conhecimento, regras e processos de negcio existentes nos seus clientes. O uso de anotaes
para capturar aspetos do conhecimento tcito no particularmente novo, no entanto, a
contribuio distintiva deste trabalho permite relacionar a anotao diretamente com a
taxonomia da competncia (Vasconcelos, Kimble, Miranda, & Henriques, 2009).
Este conhecimento em conjunto com a experincia em projetos anteriores diariamente

explicitado por estas equipas, das mais diversas formas, representando o conhecimento
organizacional. Estas anotaes podem ser vistas como um exemplo do conhecimento gerado,
que se encontravam externalizadas e que so registadas num contexto especfico, permitindo a
captura do conhecimento individual e de grupo. Como atividades que se encontram
incorporadas no dia-a-dia do grupo de trabalho possibilitam preservar esse conhecimento para
reutilizao futura (Vasconcelos, Kimble, Miranda, & Henriques, 2009).
A GC identifica as atividades relacionadas com o processo de conhecimento na organizao,

conforme j apresentado na Figura 1, por outro lado, os Projetos de Desenvolvimento de
Software so os processos executados pelos indivduos nas atividades relacionadas com o
desenvolvimento de software, compostos pelo ciclo de vida do desenvolvimento de software
identificado anteriormente na

Figura 2.
possvel criar uma relao quase direta entre os processos de um e as atividades de outro,
Figura 3, evidenciando que as atividades exercidas no desenvolvimento de software so acima
de tudo processos transformao de conhecimento tcito em explcito (Aurum & Ward, 2004).
Figura 3 - Relao entre o ciclo de vida da Gesto do Conhecimento e os Projetos de

Desenvolvimento de Software
As atividades realizadas nos projetos de desenvolvimento de software, quando devidamente

documentadas, so atividades de reificao de conhecimento organizacional. importante que
todo este conhecimento produzido pelas equipas de projetos seja devidamente preservado,
valorizado e gerido de forma adequada nas organizaes. A gesto deste conhecimento
possibilita por exemplo:
Criar informao sobre lies aprendidas, identificando boas e ms prticas que podem servir
de guias para novos projetos;

Permite que novos elementos possam obter informao sobre artefactos e projetos utilizando-o
como material de estudo;
Identificar os peritos em determinadas reas;

Registar boas prticas e lies aprendidas em projetos anteriores;
Minimizar o tempo consumido na leitura de linhas de cdigo para saber as frmulas e
regras;
Registar problemas frequentes ocorridos e como atuar sobre os mesmos durante os
processos de manuteno.
Grupos de pessoas em organizaes de conhecimento intensivo precisam criar mecanismos para

induzir a inovao, encontrar fontes de informao, gerir as competncias de forma eficiente e
recolher ideias e sugestes, a fim de fazer o seu trabalho (Vasconcelos, Kimble, Miranda, &
Henriques, 2009).
Na realidade, a maioria deste tipo de organizaes j lida e dispe de tecnologia e processos

suficientes que podem ser utilizados na implementao da Gesto do Conhecimento na
Engenharia de Software. As ferramentas baseadas no conhecimento podem acelerar a
transferncia de conhecimentos especializados de engenheiros e, desta forma, reduzir o ciclo
de vida do conhecimento (Lowry, 1993).

3 METODOLOGIA DE INVESTIGAO
Metodologia o estudo dos mtodos, das etapas a seguir num determinado processo. o
conjunto de tcnicas e processos utilizados para a pesquisa e elaborao de um trabalho
cientfico. um processo utilizado para orientar uma investigao, o estudo de uma cincia ou
para alcanar um determinado fim. A metodologia de investigao aborda as principais regras
para a produo cientfica, fornecendo as tcnicas, os instrumentos e os objetivos para uma
melhor execuo e qualidade do trabalho cientfico.
Pela natureza deste trabalho das diversas metodologias existentes a opo recaiu sobre a Design
Science Research (DSR), uma vez que esta metodologia visa a criao de artefatos para a
resoluo de problemas da vida real, com o objetivo de tornar mais eficazes e eficientes as
organizaes para as quais a investigao se destina.
3.1 Design Science Research
O paradigma da DSR tem nas suas razes a engenharia e cincia do artificial assim designada
por Herbert Simon3, referido por Hevner, seguindo uma analogia s cincias comportamentais
com razes nas cincias naturais. A DSR fundamentalmente um paradigma para resoluo de
problemas com o objetivo de criar inovaes que definem as ideias, prticas, capacidades
tcnicas ou produtos que podem ser tornados mais eficazes e eficientes atravs da anlise,
design, implementao, gesto e utilizao de tecnologias de informao (Hevner, Ram, March,
& Park, 2004).
Definies como construtos, modelos, mtodos e instanciaes no s fazem parte da DSR mas
so tambm utilizados como linguagem no dia-a-dia dos sistemas de informao nas
organizaes (Hevner, Ram, March, & Park, 2004). Tal como as atividades do ciclo de vida do
desenvolvimento, que so amplamente abordadas neste trabalho, tambm a DSR tem o seu ciclo
de investigao, tornando-a por este motivo como uma metodologia naturalmente utilizada na
realizao de trabalhos de investigao relacionados com sistemas de informao como este.
3
Foi um pesquisador nos campos de psicologia cognitiva, informtica, administrao pblica, sociologia econmica, e filosofia. Por vezes,
descreveram-no como um polmata.
A DSR direciona a investigao para os sistemas de informao, tendo por base a relao
existente entre a estratgia de negcio e tecnologias de informao das organizaes, a
infraestrutura da organizao e a infraestrutura das tecnologias de informao (Hevner, Ram,
March, & Park, 2004), utilizando estes quatro pilares e as ligaes entre eles, cada vez mais
significativas nos dias que correm para sustentar o processo de investigao.
Entre alguns dos problemas que a DSR visa resolver podemos encontrar os que so
caracterizados por uma dependncia crtica sobre as capacidades de sociabilizao dos
indivduos nas organizaes, como por exemplo o trabalho em equipa ou sobre as capacidades
cognitivas para produzir solues, nomeadamente a criatividade (Hevner, Ram, March, & Park,
2004). Estes dois tipos de problemas identificados por Hevner so muito representativos da
investigao efetuada neste trabalho, nomeadamente pela sua relao ao tema da gesto do
conhecimento nas organizaes e nos projetos de desenvolvimento de software, com especial
inciso sobre a MS.
3.2 Orientaes de Investigao
So sete as linhas orientadoras de investigao da DSR (Hevner, Ram, March, & Park, 2004),
nomeadamente:
Desenho do artefacto
Importncia do problema
Avaliao do desenho
Contribuio da investigao
Rigor na investigao
Desenho do artefacto como processo de pesquisa
Comunicao da pesquisa
Estas servem de guio para a investigao a efetuar e assentam no propsito que esta
metodologia visa a resoluo de problemas e que o conhecimento dos problemas, a sua
compreenso e resoluo so resolvidos com a criao e implementao de um artefacto
(Hevner, Ram, March, & Park, 2004).

De seguida efetuado o respetivo enquadramento de cada uma das linhas orientadoras da

metodologia, de acordo com o trabalho realizado at ao momento.
3.2.1 Desenho do Artefacto
A criao/desenho de um artefacto a primeira de todas, um artefacto entenda-se, pode ser um

modelo, um constructo, um mtodo ou uma instanciao. No caso deste trabalho optou-se pela
elaborao de um modelo, apresentado no captulo 4, que representa os principais fluxos de
conhecimento na organizao, os principais atores e as reas de atuao do artefacto. Neste
modelo de alto nvel est identificado o fluxo inicial e a origem do conhecimento, que decorre
da definio de requisitos de negcio. Foi utilizada como ferramenta para o design deste a
linguagem Unified Modelling Language4, o modelo ser posteriormente refinado e reavaliado
at sua instanciao.
3.2.2 Importncia do problema
A segunda orientao da metodologia que o artefacto dever enderear um problema de

negcio que possa ser resolvido atravs da implementao de uma soluo tecnolgica. Neste
trabalho o problema identificado endereado atravs da questo de investigao Como poder
a MS beneficiar da adoo de mtodos de GC?. Nas organizaes de conhecimento intensivo,
como o caso das que efetuam desenvolvimento de software, o consumo de tempo
desperdiado na reanlise dos processos de MS poder representar cerca de 60% dessa atividade
(Anquetil, Oliveira, Sousa, & Dias, 2007).
Para uma atividade que se pretende que seja eficiente e objetiva, como o caso da manuteno
de software, este um tema com uma importncia relevante, como experincia pessoal constato
que numa semana de trabalho o tempo gasto por indivduo em processos de MS pode equivaler
a cerca de 50% do seu tempo, ou seja, em cerca de 2,5 dias por semana em atividades de
manuteno. Se sobre esse tempo for consumir por volta de 1 dia a tentar perceber o que est a
4
UML - uma linguagem de modelagem que permite representar um sistema de forma padronizada.
ser mantido, sendo que 1 ano tem 52 semanas, teremos cerca de 50 dias, ou seja, quase dois
meses de trabalho por ano que poder ser gasto a tentar perceber o que est a ser mantido.
3.2.3 Desenho do artefacto como processo de pesquisa
DSR uma investigao iterativa, uma vez que na gnese do seu processo est a procura para
criar um artefacto, muitas vezes a pesquisa incessante para criar o melhor artefacto possvel
acaba por ser contraproducente, fazendo com que o produto final acabe por no se encaixar na
realidade da organizao. Muitas vezes a experincia pessoal, as heursticas do investigador,
acabam por determinar a criao de um artefacto mais adequado realidade da organizao. A
gerao de verses e testes sobre elas que produzem novos requisitos e necessidades que por
sua vez criam novas verses um processo identificado por Hevner como o ciclo Gerao/Teste
(Hevner, Ram, March, & Park, 2004).
O processo de pesquisa para o desenho do artefacto, modelo MIMIR, foi realizado de forma
iterativa, atravs da reviso da literatura e consequente redesenho do modelo. A minha
experincia pessoal e o conhecimento dos processos existentes permitiram adequar o modelo
realidade organizacional, tendo sido para tal criadas diversas verses como forma de o otimizar
e ajustar o mais possvel. Seguindo a metodologia apresentada e como trabalho futuro ser
efetuado o seu refinamento, as reavaliaes necessrias e a respetiva instanciao, tudo tambm
efetuado de forma iterativa.

4 GESTO DO CONHECIMENTO NA ENGENHARIA DE

SOFTWARE
O conhecimento em projetos de desenvolvimento de software diverso e em constante

crescimento. Organizaes tm dificuldade em identificar o contedo, a localizao e a melhor
forma de tirar partido desse conhecimento (Rus & Lindvall, Knowledge Management in
Software Engineering, 2002).
Um passo importante para um projeto de GC a caracterizao de um ativo de conhecimento.

O conhecimento de domnio inclui processos de negcios, processos de deciso, competncias
empresariais, o conhecimento declarativo e processual, heursticas e conhecimento informal
(Vasconcelos, Kimble, Miranda, & Henriques, 2009).
Neste trabalho as atividades do CVDS foram segmentadas em trs reas de processo que
derivaram da
Figura 2, tendo em conta a combinao dos seus outputs com as suas necessidades. As reas
de processo so:
Definio de Requisitos (DR);

Desenvolvimento de Software (DS);
Manuteno do Software (MS).
Esta segmentao visa facilitar a identificao de todos os documentos produzidos nas diversas
fases e determinar para cada um deles a informao mais relevante, conforme se pode observar
na Figura 4.

Figura 4 - Segmentao de CVDS de acordo com os seus outputs e necessidades
Constata-se que a introduo de mtodos de Gesto do Conhecimento (GC) nos processos de

Engenharia de Software (ES) nas Organizaes maioritariamente centrado nas fases do Ciclo
de Vida do Desenvolvimento de Software (CVDS) anteriores MS, mais concretamente na
definio de requisitos, desenho e codificao. (Rus & Lindvall, Knowledge Management in
Software Engineering, 2002), (Aurum & Ward, 2004), (Natali & Falbo, 2005), (Alawneh,
Hattab, & Al-Ahmad, 2008), (Camacho, Sanches-Torres, & Galvis-Lista, 2013), (Isotani,
Dermeval, Bittencourt, & Barbosa, 2015) .
Como tal, o foco deste trabalho sobre a rea MS, onde as abordagens da GC na ES tm sido
menos exploradas, mas onde a importncia de gerir o conhecimento poder significar
intervenes mais cirrgicas, objetivas e eficazes com a consequente reduo do tempo e
respetivos custos para a organizao.
Verifica-se que os documentos produzidos nas fases anteriores do CVDS raramente so

utilizados como ajuda para a resoluo de problemas no processo de MS (Carreteiro,
Vasconcelos, Baro, & Rocha, 2016), onde as equipas acabam por recorrer leitura do cdigo
fonte ou a trocas informais de ideias com os seus pares para encontrarem a resoluo de
problemas, estimando-se que 40% a 60% do esforo das equipas de MS gasto a tentarem
perceber o software que esto a manter. Os indivduos envolvidos na MS lidam com problemas
reais e por isso a sua atividade pode ser utilizada para avaliar o conhecimento documentado nas
fases anteriores do CVDS.

5 MODELO MIMIR
5.1 Introduo ao Modelo
A MS uma atividade complexa e exigente, os indivduos que dela fazem parte tm de dominar
linguagens de programao, arquitetura do sistema, modelos de dados, conhecimento de
processos, saber sobre os impactos das atualizaes no software entre outros, sendo que por
vezes este conhecimento multiplicado por vrias aplicaes, concluindo-se que na MS tem de
ser gerida uma quantidade significativa de informao (Rodrguez, Vizcano, & Martnez,
2004).
Os indivduos mais experientes acabam por ser os escolhidos para esta tarefa devido sua
senioridade e heursticas, tornando-os como tal os eleitos pelas organizaes para assumir estas
funes, realando assim que esta atividade exige um elevado nvel de conhecimento,
sensibilidade e experincia devido criticidade e urgncia da mesma.
O modelo MIMIR apresentado em seguida, cujo nome deriva do deus da mitologia nrdica, o
mais sbio dos deuses nrdicos e guardio da Fonte de todo o Conhecimento, uma
abordagem para mapear a informao produzida com base nos documentos criados nas fases
CVDS, com o objetivo de extrair deles a informao mais relevante para a MS.
O modelo baseado nos documentos de referncia do CMMI-DEV5, que consiste num conjunto
de boas prticas direcionadas para atividades de desenvolvimento de produtos e servios. Para
melhor compreender o modelo MIMIR importante perceber os conceitos inerentes produo
dos documentos que derivam do CMMI-DEV, motivo pelo qual ser de seguida realizada uma
pequena apresentao da metodologia e da documentao adequada aos processos do CVDS.
5.1.1 CMMI
O modelo CMMI foi criado para satisfazer as necessidades do departamento de defesa dos
Estados Unidos por volta dos anos 80. Com o aparecimento de sistemas operativos mais leves
5
CMMI-DEV Capability Maturity Model Integration for Development um modelo de boas prticas que ajuda as organizaes a melhorar
os seus processos.
e com utilizao mais grfica (ex. Windows) o software do departamento comeou a ser
desenvolvido por empresas externas com um controlo do prprio departamento.
Apesar de existir um controlo apertado no que dizia respeito segurana com que o
desenvolvimento era efetuado, a sua externalizao acabou por levantar outras questes. Era
essencial assegurar que o software era entregue no prazo definido, com o oramento
estabelecido e que as funcionalidades pedidas estavam asseguradas. Esta necessidade por parte
do departamento de defesa acabou por se tornar num requisito de qualidade no
desenvolvimento de software (Liberato, 2008).
A resposta a esta necessidade surgiu da Carnegie Mellon University's Software Engineering

Institute que concebeu um modelo que conseguisse definir os elementos essenciais dos
processos de desenvolvimento, que designaram de Capability Maturity Model. Decorrente da
sua grande aceitao e resultados efetivos nas organizaes este modelo tornou-se uma
referncia, contendo as melhores prticas para os projetos de desenvolvimento de software, uma
vez que descreve os diferentes estgios de maturidade por onde as organizaes passam na
evoluo dos ciclos de desenvolvimento.
O seu sucesso acabou por dar origem criao de vrios modelos de maturidade com aplicao
noutras reas, no entanto e apesar do valor que eles representam para as organizaes a
implementao destes vrios modelos representava custos acrescidos tanto a nvel financeiro
como a nvel de complexidade da sua implementao (Software Engineering Institute,
Novembro 2010). Como resposta a este problema foi criado o Capability Maturity Model
Integration, que integrava trs modelos de maturidade, a saber:
Capability Maturity Model for Software (SW-CMM) v2.0 draft C

Systems Engineering Capability Model (SECM)
Integrated Product Development Capability Maturity Model
Os modelos foram escolhidos por terem entre si diferentes abordagens ao processo de melhoria
e porque eram extremamente populares nas comunidades de desenvolvimento de software e de
engenharia de sistemas (Software Engineering Institute, Novembro 2010). A utilizao de
modelos j aceites e com provas dadas, permitiu que a integrao tivesse um conjunto de
modelos passveis de continuar a ser adotados por quem j tinha implementado os modelos per

si, e tambm que quem ainda no tivesse adotado os modelos de maturidade tivesse referncias
com melhorias efetivas.
Figura 5 - As trs dimenses crticas numa organizao (Software Engineering Institute,

Novembro 2010)
O modelo de maturidade permitiu a organizaes aplicar normas a projetos de

desenvolvimento, entregues a empresas externas garantindo um aumento nas taxas de sucesso
dos mesmos. O CMMI funciona como um guia para a melhoria das trs dimenses crticas
numa organizao, Figura 5, atravs da otimizao dos processos das mesmas e capacidade de
gerir o desenvolvimento, aquisio e manuteno de produtos e servios (Liberato, 2008).
5.1.2 CMMI for Development
CMMI-DEV composto por melhores prticas que abordam atividades de desenvolvimento de

produtos e de servios. Define prticas que cobrem o ciclo de vida do produto, desde a sua
conceo at a entrega e manuteno. A nfase sobre o trabalho necessrio para construir e
manter o produto total (Software Engineering Institute, Novembro 2010). Assim, fornecendo
as orientaes necessrias para documentar e nortear o conhecimento produzido nos projetos
de desenvolvimento de software, o modelo CMMI-DEV contempla quatro grandes reas de
processos, nomeadamente:

Gesto de Processos;
Gesto de Projetos;
Engenharia;
Suporte.
Os processos da rea de Engenharia, que esto diretamente relacionados com o CVDS e que
fornecem a base de anlise para o modelo MIMIR, enquadram todas as atividades de requisitos,
desenvolvimento e manuteno. So processos com a estratgia orientada elaborao,
implementao e otimizao de um produto. As cinco reas de processos da Engenharia,
representadas na Figura 6, so:
Definio de Requisitos (RD)

Soluo Tcnica (TS)
Validao (VAL)
Verificao (VER)
Integrao de Produto (PI)
Figura 6 reas de processo da Engenharia no modelo CMMI-DEV (Software

Engineering Institute, Novembro 2010)

O processo de Definio de Requisitos (RD) diz respeito elaborao, anlise e levantamento

de todas as necessidades dos stakeholders6. Sendo de extrema importncia que as necessidades
dos patrocinadores do projeto (no modelo MIMIR identificados como Sponsors) sejam
perfeitamente entendidas e delimitadas.
A correta definio e entendimento das necessidades, para alm da importncia que tem na
qualidade do produto final, produz tambm informao essencial para outras fases do CVDS,
como os critrios para as matrizes de testes ou determinados atributos do produto como por
exemplo segurana, usabilidade e de manuteno (Software Engineering Institute, Novembro
2010), esta ltima essencial no foco do modelo MIMIR. So elaborados documentos onde se
descrevem os requisitos de negcio (BRS), Figura 7, e documentos de requisitos funcionais
(SRS ou PRS), Figura 8, que sero utilizados pelo modelo MIMIR para popular o modelo de
dados de conhecimento.
Figura 7 Exemplo de parte do documento de requisitos de negcio
6
Parte interessada ou interveniente no projeto.
So documentados todo o tipo de requisitos, desde os que dizem efetivamente respeito ao

negcio, origem do projeto, mas tambm todos os outros requisitos colaterais, que sejam
necessrios existir derivado do objetivo a atingir.
Figura 8 - Exemplo de parte do documento de requisitos de funcionais
A rea de processo Soluo Tcnica (TS) consiste no desenvolvimento propriamente dito do

produto que ser posteriormente utilizado no processo de Integrao de Produto. O modelo
prev neste processo o estudo de solues alternativas para determinar a melhor soluo tcnica
a implementar com base em determinados critrios. Critrios esses que podem ser
significativamente diferentes de soluo para soluo, dependendo do tipo de produto, ambiente
operacional, os requisitos de desempenho e de suporte de custo ou de calendrio de entrega.

A rea de processo de Verificao (VER) utilizada como complemento rea de processo

Soluo Tcnica (TS), para realizar a verificao do desenho e peer review7 durante a fase de
desenvolvimento da soluo tcnica e antes da verso final do produto.
Documentos como desenhos tcnicos, conforme Figura 9, onde so descritas e representadas as

alteraes ou implementaes a realizar decorrente dos requisitos especificados anteriormente,
em linguagem natural ou em linguagens de modelao, como por exemplo o UML 8 , so
tipicamente documentos associados rea de processo Soluo Tcnica.
Figura 9 - Exemplo de parte do documento de tcnico ASP/JSP
7
Processo de avaliao do trabalho desenvolvido por outrem com competncias similares ou superiores com o objetivo de manter standards
de qualidade e performance.
8
Unified Modeling Language
Os relatrios de peer review, Figura 10, relacionados com a rea de Verificao, so utilizados
para anlise e avaliao por elementos com maior experincia e conhecimento tcnico sobre o
trabalho desenvolvido pelos elementos da equipa.
Figura 10 - Exemplo de parte do documento de peer review
A rea de processo de Validao (VAL) est relacionada com a realizao de testes efetuados
sobre o produto, que permitam criar evidncias de que o mesmo vai de encontro s necessidades
identificadas nos requisitos. Estes testes comprovam o funcionamento do produto, funcionando
como uma prova de conceito. A validao pode ser realizada no ambiente operacional ou num
ambiente operacional simulado.
A elaborao de documentos como matrizes e planos de testes, Figura 11, onde no primeiro so
descritos os testes que se pretendem efetuar sobre cada uma das componentes alteradas em
funo dos requisitos definidos, e no segundo onde so estabelecidas as estratgias,

necessidades e critrios para os testes a realizar.
Figura 11 - Exemplo de parte do documento de plano de testes
Por ltimo, a rea de processo Integrao de Produto (PI) contm as prticas especficas
associadas gerao de uma estratgia de integrao, integrao de componentes do produto,
e entregando o produto ao cliente. Esta rea de processo suportada por processos tanto da rea
de Verificao como da rea de Validao, para identificar as componentes concludas e
consequentemente passveis de serem entregues.
O Plano de Integrao, Figura 12, o documento relacionado com esta rea de processo, apesar
de ser um documento prprio de uma fase final do CVDS de todo importante que o seu
preenchimento se realize durante o decorrer das fases anteriores, minimizando assim o risco de
falhas.

Figura 12 - Exemplo de parte do documento do plano de integrao
Todos os documentos apresentados, principais referncias associadas ao modelo CMMI-DEV,

so a estrutura para alimentar a base de conhecimento do modelo MIMIR. Nos prximos
captulos ser feita a apresentao da framework MIMIR, primeiro apresentando uma viso de
alto nvel onde se pretende mostrar o modelo na sua totalidade, para dar toda a abrangncia do
mesmo, e em seguida detalhada a vertente relacionada com o segmento da Definio de
Requisitos.
5.2 Viso de Alto-nvel do Modelo e atores
O driver para a criao deste modelo o facto de que as equipas de manuteno de software
so confrontados com problemas efetivos e por esse motivo tm uma necessidade premente de
ter acesso a conhecimento relevante que os possa auxiliar quando confrontados com situaes
de erro (Carreteiro, Vasconcelos, Baro, & Rocha, 2016). Esta necessidade possibilita com que
estes indivduos possam atuar como agentes validadores da informao existente, permitindo
que corrijam ou atualizem o conhecimento obtido (Carreteiro, Vasconcelos, Baro, & Rocha,
2016). A partir dessa mesma atualizao aplicada a tcnica de back flushing para corrigir os
dados na origem, neste caso as bases de conhecimento onde fica registado o conhecimento das
fases anteriores conforme representado na Figura 13.
Figura 13 - Modelo MIMIR (Alto Nvel) (Carreteiro, Vasconcelos, Baro, & Rocha,
2016)
Este modelo visa uma abordagem preliminar s fases do CVDS em organizaes de

conhecimento intensivo, baseada na segmentao em trs reas, de acordo com a Figura 4, e
para o qual foram definidos um conjunto de atores, utilizando a representao UML, criando
esteretipos dos atores nomeadamente: Sponsor, Analista, Equipa de Desenvolvimento e
Equipa de Manuteno (Maintainer).
O papel do Sponsor definir as necessidades do projeto e validador no que qualidade dos

requisitos diz respeito, estes podem ser internos ou externos organizao. O analista o perito
para este modelo, fornece os requisitos discutidos com o Sponsor, a anlise aplicacional, sendo
este ator a principal fonte do conhecimento no projeto. A equipa de desenvolvimento
composta pelos indivduos que participam no projeto essencialmente na fase de codificao.

Em projetos menores o analista pode acabar por integrar a equipa de desenvolvimento. A equipa
de manuteno so os indivduos que do suporte aplicao ou sistema. Se o analista
exclusivamente um analista de negcio no ter qualquer participao na equipa de
manuteno, no entanto se for um analista aplicacional far com toda a certeza parte da equipa
de manuteno.
No que s reas de conhecimento definidas no modelo diz respeito, a RD Knowledge, ser

onde ficar armazenado todo o conhecimento relacionado com a vertente de levantamento de
requisitos. A SD Knowledge servir para registar a informao das fases de desenvolvimento,
como por exemplo especificaes tcnicas para desenvolvimento, ligaes entre software,
regras existentes no cdigo, etc. A SM Knowledge ir guardar informao especfica dos
processos de manuteno, como por exemplo problemas rotineiros e a sua soluo, sequncia
de execuo do processos batch9 , sequncia de navegao na aplicao, etc. Por ltimo, a
Quality Control Knowledge onde residiro as correes e atualizaes ao conhecimento
existente nas outras bases. As correes ficaro aqui at que os peritos (analistas) faam uma
avaliao das correes propostas para dar incio ao processo de correo na fonte, back
flushing.
5.3 Captura de conhecimento da Definio de Requisitos
O MIMIR centra-se na extrao de conhecimento gerado nos documentos produzidos de acordo

com metodologia CMMI-DEV pelos elementos das equipas de conhecimento intensivo durante
as fases do CVDS. A elicitao das necessidades do Sponsor por parte do Analista, decorrente
de reunies e entrevistas, iro originar a criao do documento BRS, que ir conter uma
descrio de alto-nvel das necessidades do negcio.
Na Figura 14 encontra-se a representao do modelo MIMIR referente criao, recolha e

alimentao da base de dados de conhecimento da fase de Definio de Requisitos e cujo seu
fluxo ser de seguida descrito.
9
a execuo de uma srie de programas sem interveno manual.
Figura 14 Modelo MIMIR para a fase de Definio de Requisitos (Carreteiro,

Vasconcelos, Baro, & Rocha, 2016)
Atravs da utilizao de um mdulo prprio e especificamente dedicado extrao de

informao existente nos documentos, designado de MIMIR-Extractor, ir colher elementos do
documento tais como a identificao (cdigo unvoco por projeto), a sua descrio e o seu
mbito. Estes elementos desencadearo o momento de criao do projeto na base de dados de

conhecimento do MIMIR e adicionalmente permitir a criao das primeiras tags10 associadas

ao projeto, que posteriormente iro facilitar as pesquisas e o fluxo de conhecimento entre os
indivduos que participam no projeto e tambm os das equipas de manuteno.
Tambm produzido pelo Analista nesta fase do CVDS o documento das Especificaes dos
Requisitos Funcionais (PRS) do projeto. Elaborado por este, imediatamente aps os requisitos
de negcio estarem formalmente aceites pelos Sponsors, um documento que no sendo
especificamente de cariz tcnico, j dever conter menes a conceitos tcnicos direcionados
para a equipa de desenvolvimento, com o objetivo de permitir uma melhor compreenso dos
elementos desta e facilitar a associao entre um requisito e o impacto que ele representa na
estrutura tcnica do sistema ou sistemas.
Deste documento o extrator retirar de cada requisito funcional o seu cdigo unvoco de
identificao, a sua descrio, o tipo de requisito funcional e a rea funcional do sistema a que
este se refere. Adicionando esta informao base de dados do conhecimento do MIMIR pelo
extrator, que a associar ao projeto criado anteriormente no tratamento do BRS, fornecer
conhecimento numa linguagem natural, rpida e simples de interpretar pelos indivduos.
Utilizando o seu cdigo unvoco para cada requisito permitir ao MIMIR, posteriormente na
fase de desenvolvimento, mapear cada um dos diversos artefactos que so impactados no
projeto.
O ltimo documento desta fase e que ser utilizado pelo MIMIR para considerar como
concluda a fase de Definio de Requisitos, a Checklist dos Requisitos Funcionais (PRS-
CK). Daqui ser identificado o Analista envolvido e responsvel pela elicitao dos requisitos,
referncia para posterior identificao do especialista aplicacional que poder prestar
esclarecimentos e orientaes sobre o projeto.
Este documento, elaborado apenas aps a aceitao dos requisitos por parte dos Sponsors ir
determinar a concluso da fase de levantamento e definio de requisitos. Um novo mdulo do
modelo ser despoletado, o MIMIR-RCD que alterar o status do projeto na base de dados de
conhecimento da Definio de Requisitos e adicionalmente e de forma automtica far a
10
Em portugus etiqueta, uma palavra-chave (relevante) ou termo associado com uma informao (ex: uma imagem, um artigo, um vdeo)
que o descreve e permite uma classificao da informao baseada em palavras-chave.
disseminao e distribuio do conhecimento aos indivduos da equipa de desenvolvimento,

para que iniciem o seu processo de apropriao.

CONCLUSO E TRABALHO FUTURO
O desenvolvimento de software um processo de conhecimento intensivo e as atividades do

ciclo de vida de desenvolvimento de software so a reificao do conhecimento organizacional.
O conhecimento que resulta destas atividades amplamente documentado, no entanto, muito
pouco reutilizado seja para novos projetos ou como auxlio na manuteno de software, para
alm daquele que ainda fica residente nos indivduos, criando uma lacuna de conhecimento
organizacional.
Como fazer uso de todo esse conhecimento explicitado e como explicitar o que ainda reside na
mente dos indivduos so desafios que as organizaes tm pela frente. A proximidade entre as
atividades do ciclo de vida de desenvolvimento e a gesto do conhecimento pode facilitar a
implementao deste tipo de iniciativas.
Da reviso da literatura constata-se que muitas destas iniciativas incidem essencialmente nas
fases iniciais do ciclo de vida de desenvolvimento de software, essencialmente na definio e
levantamento de requisitos, deixando de parte a manuteno de software. Verifica-se tambm
que a manuteno de software tem uma grande necessidade de acesso ao conhecimento criado
no decorrer dos projetos, uma vez que at cerca de 60% do tempo gasto nesta atividade a
tentar perceber o que est a ser mantido.
Este trabalho visa precisamente a criao de um modelo, onde a partir de todos os documentos
criados nas fases prvias do ciclo de vida de desenvolvimento, se possa extrair conhecimento
til que sirva de suporte s equipas que participam na atividade de manuteno de software e
utilizar estes mesmos indivduos como validadores desse mesmo conhecimento explicitado
anteriormente.
Como trabalho futuro sero detalhadas as restantes reas do modelo MIMIR, tanto no processo
de alimentao da base de dados de conhecimento como no processo de backflushing, bem
como a instanciao do mesmo, mantendo sempre o foco do modelo nas organizaes de
desenvolvimento de software, combinando a experincia em projetos de software corporativos
como meio para avaliar os seus efeitos em pessoas, fluxos de trabalho e processos.

Adicionalmente, apesar de no se tratar do objetivo principal deste trabalho, pretende-se validar

com a instanciao do modelo, se a implementao deste tipo de iniciativa na fase de
manuteno pode funcionar como um facilitador para a adoo da gesto do conhecimento pela
organizao.

BIBLIOGRAFIA
Alawneh, A. A., Hattab, E., & Al-Ahmad, W. (2008). An Extended Knowledge Management
Framework during the Software Development Life Cycle. International Technology
Management Review.
Anquetil, N., Oliveira, K. M., Sousa, K. D., & Dias, M. G. (May de 2007). Software
maintenance seen as a knowledge management issue. INFORMATION AND
SOFTWARE TECHNOLOGY.
Aurum, A., & Ward, J. (2004). Knowledge Management in Software Engineering - Describing
the Process. 2004 Australian Software Engineering Conference.
Bourque, P., & Fairley, R. E. (2014). SWEBOK v3.0 - Guide to the Software Engineering Body
Of Knowledge. New Jersey: IEEE Computer Society.
Camacho, J. J., Sanches-Torres, J. M., & Galvis-Lista, E. (Maro de 2013). Understanding the
Process of Knowledge Transfer in Software Engineering: A Systematic Literature
Review.
Carreteiro, P., Vasconcelos, J. B., Baro, A., & Rocha, . (2016). A Knowledge Management
Approach for Software Engineering Projects Development. World Cist 2016. Recife:
Springer International.
Casco, F. (2014). Gesto de Competncias, do conhecimento e do talento. Lisboa: Edies

Slabo, Lda.
Davenport, T. H. (2010). Process Management for Knowledge Work. Em Handbook on

Business Process Management 1. Springer.
Hevner, A. R., Ram, S., March, S. T., & Park, J. (March de 2004). Design Science Research In
Information Systems Reserarch. Mis Quartely, pp. 75-105.
Isotani, S., Dermeval, D., Bittencourt, I., & Barbosa, E. (Maro de 2015). Ontology Driven
Software Engineering A Review of Challenges and Opportunities. IEEE LATIN
AMERICA TRANSACTIONS.
Leistner, F. (2010). Mastering Organizational Knowledge Flow. New Jersey: John Wiley &
Sons, Inc.
Liberato, M. E. (2008). Implementao do Modelo CMMI na Espirito Santo Informtica . Vila

Real.
Lowry, M. (1993). Methodologies for Knowledge-Based Software Engineering. California:

Artificial Intelligence Research Branch.
Natali, A. C., & Falbo, R. d. (2005). Knowledge Management in Software Engineering

Environments. Vitoria.
Rodrguez, O. M., Vizcano, A., & Martnez, A. I. (2004). How to Manage Knowledge in the
Software Maintenance Process. 6th International Workshop LSO 2004 (pp. 78-87).
Banff, Canada: Springer Berlin Heidelberg.
Rus, I., & Lindvall, M. (June de 2002). Knowledge Management in Software Engineering.
IEEE Software.
Rus, I., Lidvall, M., & Sinha, S. S. (Novembro de 2001). Knowledge Managment in Sofware
Engineering.
Software Engineering Institute. (Novembro 2010). CMMI para Desenvolvimento Verso

1.3.
Vasconcelos, J. B., Kimble, C., Miranda, H., & Henriques, V. (2009). A Knowledge-Engine
Architecture for a Competence Management Information System.

ANEXOS
A KNOWLEDGE MANAGEMENT APPROACH FOR SOFTWARE

ENGINEERING PROJECTS DEVELOPMENT
82-91.pdf

Gestão Do Conhecimento em Processos de Engenharia de Software em Organizações Empresariais

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gestão Do Conhecimento em Processos de Engenharia de Software em Organizações Empresariais

Uploaded by

Copyright:

Available Formats

LICENCIATURA EM SISTEMAS E TECNOLOGIAS DE INFORMAO

GESTO DO CONHECIMENTO EM PROCESSOS DE ENGENHARIA DE

Projeto Final de Licenciatura

Elaborado por Paulo Srgio dos Santos Carreteiro

Orientador Professor Doutor Jos Braga de Vasconcelos

Licenciatura em Sistemas e Tecnologias de Informao

GESTO DO CONHECIMENTO EM PROCESSOS DE ENGENHARIA DE

Projeto Final de Licenciatura

Elaborado por Paulo Srgio dos Santos Carreteiro

Orientador Professor Doutor Jos Braga de Vasconcelos

Ao Professor Doutor Alexandre Baro um agradecimento especial pela ajuda e orientao na

Objetiva a genialidade que possuis, seno impera a preguia.

Paulo Carreteiro Junho 2016 Universidade Atlntica iii

ETL - Extraction Transformation Load

CVDS - Ciclo de Vida de Desenvolvimento de Software

SWEBOK - Software Engineering Body of Knowledge

DSR - Design Science Research

CMMI - Capability Maturity Model Integration

BRS - Business Requirements Specification

SRS - Software Requirements Specification

PRS - Project Requirements Specification

UML - Unified Modelling Language

Paulo Carreteiro Junho 2016 Universidade Atlntica iv

A Manuteno de Software a ultima fase do ciclo de vida do desenvolvimento de software e

Nas fases anteriores dos projetos de desenvolvimento de software, gerado um nmero

Neste trabalho abordada a implementao da Gesto do Conhecimento na Manuteno de

Palavras-chave Gesto do Conhecimento; Engenharia de Software; Ciclo de Vida do

Paulo Carreteiro Junho 2016 Universidade Atlntica v

In previous phases of software development projects, it is generated a significant number of

This paper discusses the implementation of Knowledge Management in Software Maintenance,

Keywords Knowledge Management; Software Engineering; Software Life Cycle; Software

Paulo Carreteiro Junho 2016 Universidade Atlntica vi

1 Definies e Conceitos da Gesto do Conhecimento e da Engenharia de Software. 4

1.1 O Conhecimento e a sua Gesto .................................................................................. 4

1.1.1 Definio e Nveis do Conhecimento ................................................................... 4

1.1.2 Caractersticas do Conhecimento ......................................................................... 4

1.1.3 A Gesto do Conhecimento .................................................................................. 4

1.2 Engenharia de Software ............................................................................................... 6

1.2.1 Definio .............................................................................................................. 6

1.2.3 Fases do Ciclo de Vida do Desenvolvimento ....................................................... 7

2 A Gesto do Conhecimento em Projetos de Desenvolvimento de Software .......... 10

2.1 Desafios Organizacionais........................................................................................... 10

2.2 A Reificao de Conhecimento nas Organizaes .................................................... 11

3 Metodologia de Investigao .................................................................................. 14

3.1 Design Science Research ........................................................................................... 14

3.2 Orientaes de Investigao ...................................................................................... 15

3.2.1 Desenho do Artefacto ......................................................................................... 16

3.2.2 Importncia do problema .................................................................................... 16

3.2.3 Desenho do artefacto como processo de pesquisa .............................................. 17

4 Gesto do Conhecimento na Engenharia de Software ............................................ 18

5 Modelo MIMIR ....................................................................................................... 21

5.1 Introduo ao Modelo ................................................................................................ 21

5.1.1 CMMI ................................................................................................................. 21

5.1.2 CMMI for Development ..................................................................................... 23

Paulo Carreteiro Junho 2016 Universidade Atlntica vii

5.2 Viso de Alto-nvel do Modelo e atores .................................................................... 30

5.3 Captura de conhecimento da Definio de Requisitos .............................................. 32

Concluso e trabalho futuro ............................................................................................ 36

A Knowledge Management Approach for Software Engineering Projects Development ... 40

Paulo Carreteiro Junho 2016 Universidade Atlntica viii

Paulo Carreteiro Junho 2016 Universidade Atlntica ix

Esta atividade habitualmente entregue a indivduos com maior experincia dentro da

No decorrer dos projetos de Engenharia de Software (ES) so produzidos um elevado nmero