10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
KNOWLEDGE MANAGEMENT APPLICATION IN PRACTICES OF SOFTWARE
DEVELOPMENT PROCESS: PROPOSAL TO USE IN IT COMPANY
Ernane de Jesus Torres (IETEC - Instituto de Educação Tecnológica, MG, Brasil) [email protected]
Fernando Hadad Zaidan (IETEC - Instituto de Educação Tecnológica, MG, Brasil) mailto:[email protected] [email protected]
The implementation of the concept of collaborative knowledge is needed in modern
enterprises, especially when it comes to Software Engineering. There are major benefits of
implementing Knowledge Management used by the process of software development, such as
the appropriate process control, internal organization of the company, standardization,
processes alignment, centralizing information, among other competitive advantages that can
be obtained. Throughout this work will be presented studies based on theoretical concepts,
grounded in academic literature. Based on these concepts, it will be developed a proposal for
improving the development process in an IT company which was chosen as object of these
study. Concludes this paper the identifying some aspects that must be worked on
implementation of Knowledge Management in the process of software development.
Keywords: Collaborative Knowledge; Software Engineering; Software Development Process;
Knowledge Management.
APLICAÇÃO DA GESTÃO DO CONHECIMENTO NAS PRÁTICAS DO PROCESSO
DE DESENVOLVIMENTO DE SOFTWARE: PROPOSTA DE UTILIZAÇÃO EM
UMA EMPRESA DE TI
A implantação do conceito de conhecimento colaborativo se faz necessária na atual
conjuntura mercadológica, principalmente quando se trata da Engenharia de Software. São
grandes os benefícios da aplicação da Gestão do Conhecimento empregada no processo de
desenvolvimento de softwares, como o adequado controle do processo, organização interna da
empresa, padronização, alinhamento dos processos, centralização das informações, dentre
outras vantagens competitivas que podem ser obtidas. Ao longo deste trabalho serão
apresentados estudos baseados em conceitos teóricos, fundamentados na literatura acadêmica.
À luz desses conceitos, será elaborada uma proposta de melhoria do processo de
desenvolvimento em uma empresa de TI escolhida como objeto desse estudo. Conclui o artigo
a identificação de alguns aspectos que devem ser trabalhados na implementação da Gestão do
Conhecimento no processo de desenvolvimento de software.
Palavras-Chave: Conhecimento Colaborativo; Engenharia de Software; Processo de
Desenvolvimento de Software; Gestão do Conhecimento.
3343
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
1
INTRODUÇÃO
A implementação da Gestão do Conhecimento e a ideia de Conhecimento
Colaborativo vem crescendo muito dentro dos ambientes empresariais, conforme
Zaidan (2008) citou: “conhecimento tem pernas e caminha para casa todos os dias”.
Assim, as empresas têm se preocupado com a retenção do ‘intelecto’ dos seus
funcionários e da manipulação destes conhecimentos retidos, com o intuito de
convertê-las em vantagens competitivas. Mas, encontram muitas dificuldades em
realizar o compartilhamento do conhecimento devido a resistências das pessoas.
Dado este cenário é importante que haja um estudo de como absorver informações
e conhecimentos e retê-las antes de aplicá-las nas organizações, e pensar em
estratégias motivacionais a serem utilizadas nos funcionários e colaboradores com o
intuito de fazer que o mesmo compartilhe seus conhecimentos em um ambiente
corporativo e colaborativo.
Esse estudo tem o objetivo de identificar como a Gestão do Conhecimento se
interage com o Processo de Desenvolvimento de Software. Além de apresentar
alguns conceitos sobre o Processo de Desenvolvimento de Software e sobre a
Gestão do Conhecimento, também tem como objetivo descrever uma proposta de
implementação de práticas e ferramentas da Gestão do Conhecimento em uma
organização de desenvolvimento de software, de forma a evitar retrabalho, perda
dos processos, falta de padronização, enfim, perda de dinheiro.
O artigo está dividido em quatro partes: acima, consta a contextualização e o
objetivo. No capítulo dois tem-se a elucidação dos conceitos. O procedimento
metodológico está no item três. A proposta, objetivo principal deste estudo, está
descrita no capítulo quatro. O que se segue são as considerações finais e as
referências bibliográficas.
2
REFERENCIAL TEÓRICO
2.1
Processo de desenvolvimento de software
Pressman (2009) define que o processo de desenvolvimento de software é
possibilitado pela engenharia de software, que abrange um conjunto de três
elementos fundamentais – métodos, ferramentas e procedimentos – e que oferece
uma base para construção de software de alta qualidade. Os métodos envolvem um
amplo conjunto de tarefas: planejamento e estimativa de projeto, análise de
requisitos de software e de sistemas, projeto de estrutura de dados, arquitetura de
programa e algoritmo de processamento, codificação, teste e manutenção.
3344
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
Sommerville (2011) conceitua o processo de desenvolvimento de software como um
conjunto de atividades relacionadas que levam a produção de um produto de
software, e quatro atividades são fundamentais para esse processo: 1)
Especificação de software; 2) Projeto e implementação de software; 3) Validação de
Software; 4) Evolução de Software.
Ainda segundo Sommerville (2011), os processos de software são bastante
complexos e dependem de pessoas para tomar decisões e fazer julgamentos.
Sendo assim, não existe processo ideal, e a maioria das organizações desenvolvem
seus próprios processos de desenvolvimento de software, de forma a tirarem
proveito das capacidades das pessoas e das características do sistema em
desenvolvimento.
De acordo com Pressman (2009), o processo de desenvolvimento de software
contém três fases genéricas, que são encontradas em todo desenvolvimento,
independente da área de aplicação, tamanho, ou complexidade:
a) Definição: o desenvolvedor tenta identificar quais informações devem ser
processadas, o desempenho desejado, a interface estabelecida, as
restrições de projeto e os critérios de validação;
b) Desenvolvimento: o desenvolvedor deve definir como a estrutura de dados
e a arquitetura de software devem ser projetadas;
c) Manutenção: nessa fase concentram-se as mudanças associadas a
correções de erros, adaptações exigidas e ampliações do projeto.
Para Paula Filho (2009), na engenharia de software, processos podem ser definidos
para atividades como desenvolvimento, manutenção, aquisição e contratação de
software. Para cada um desses processos podem-se definir subprocessos. O
processo de desenvolvimento, por exemplo, abrange subprocessos de determinação
dos requisitos, análise, desenho, implementação e testes.
2.2
Atividades do processo de desenvolvimento
2.2.1 Especificação de software
Segundo Sommerville (2011), especificação de software ou engenharia de requisitos
é um estágio crítico no processo de software, pois é o processo de compreensão e
definição dos serviços requisitados do sistema e identificação de restrições relativas
ao seu desenvolvimento. O objetivo desse processo é produzir um documento de
requisitos de forma a fazer o alinhamento entre as funcionalidades do sistema e as
expectativas dos stakeholders.
Para Paula Filho (2009), a disciplina de engenharia de requisitos é o conjunto de
técnicas empregadas para levantar, detalhar, documentar e validar os requisitos de
um produto. Os requisitos de alta qualidade são claros, completos, sem
ambiguidade, implementáveis, consistentes e testáveis. Os requisitos que não
apresentam essas qualidades devem ser revistos e renegociados com os clientes e
usuários. Segundo Paula Filho (2009), “Uma boa engenharia de requisitos é um
passo essencial para o desenvolvimento de um bom produto, em qualquer caso.”.
3345
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
De acordo com Pressman (2009), a análise de requisitos é uma tarefa que faz a
ligação entre a alocação de software em nível de sistema e o projeto de software. A
tarefa de análise de requisitos é um processo de descoberta, refinamento,
modelagem e especificação, e deve ser feito com muito critério para evitar
interpretações errôneas e informações falsas.
De acordo com Sommerville (2011), o processo de engenharia de requisitos possui
quatro atividades principais: 1) Estudo de viabilidade; 2) Elicitação e análise de
requisitos; 3) Especificação de requisitos; 4) Validação dos requisitos.
Os requisitos de software são classificados como requisitos funcionais e requisitos
não funcionais.
a) Requisitos funcionais: Segundo Sommerville (2011), os requisitos
funcionais descrevem o que o sistema deve fazer. Os requisitos variam de
requisitos gerais, que identificam o que o sistema deve fazer, e requisitos
específicos, que refletem os sistemas e as formas de trabalho de uma
organização. A especificação dos requisitos funcionais de um sistema
deve ser completa, ou seja, todos os serviços requeridos pelo usuário
devem ser definidos, e a especificação deve ser consistente, ou seja, os
requisitos não devem ter definições contraditórias. De acordo com Lima
(2009), requisitos funcionais especificam ações que o sistema executar
independente de exigências físicas ou tecnológicas, e que estão
associadas ao modelo conceitual.
b) Requisitos não funcionais: Segundo Paula Filho (2009), os requisitos não
funcionais devem se enunciados de forma precisa e quantitativa. Os
requisitos não funcionais incluem os requisitos de desempenho e
qualidade do produto, e os requisitos lógicos sobre os dados persistentes
e os requisitos de natureza técnica, como restrições ao desenho e à
implementação. De acordo com Sommerville (2011), requisitos não
funcionais não estão relacionados com os serviços específicos do sistema,
mas às propriedades emergentes do sistema, como confiabilidade, tempo
de resposta e ocupação de área. Requisitos não funcionais especificam ou
restringem as características do sistema como um todo. Sendo assim, são
frequentemente mais críticos que requisitos funcionais individuais. Ainda
de acordo com Sommerville (2011), os requisitos não funcionais surgem
de acordo com necessidades dos usuários, restrições de orçamento,
políticas organizacionais, necessidade de integração com outros sistemas
de software ou hardware, ou a partir de fatores externos. Conforme Lima
(2009), requisitos não funcionais estão relacionados a características do
sistema ou do ambiente em que ele está inserido.
2.2.2 Projeto e implementação de software
Segundo Sommerville (2011), a fase de implementação do desenvolvimento de
software consiste na conversão de uma especificação de sistema em um sistema
executável, envolvendo processos de projeto e programação de software, e
refinamento da especificação. O desenvolvimento dos programas que implementam
3346
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
o sistema decorrem naturalmente dos processos de projeto de sistema, através da
utilização de ferramentas de desenvolvimento de software.
De acordo com Pressman (2009), o projeto é o primeiro passo da fase de
desenvolvimento de qualquer produto ou sistema de engenharia, e seu objetivo é a
produção de um modelo ou representação de qualquer entidade que será construída
posteriormente. O projeto de software modifica-se continuamente à medida que
novos métodos, uma melhor análise e um mais amplo entendimento se
desenvolvem.
Sommerville (2011) descreve que as atividades no processo de projeto podem variar
dependendo do tipo de sistema a ser desenvolvimento e cita quatro atividades que
podem fazer parte desse processo: 1) Projeto de arquitetura; 2) projeto de interface;
3) Projeto de componente; 4) projeto de banco de dados.
2.2.2.1
Modelagem de sistemas
A modelagem é um processo de desenvolvimento de modelos abstratos, onde cada
modelo apresenta uma visão ou perspectiva diferente do sistema, e normalmente
representa o sistema com algum tipo de notação gráfica. Sommerville (2011)
complementa que os modelos são utilizados em três fases do processo: durante o
processo de engenharia de requisitos, de forma a ajudar extrair requisitos do
sistema, durante o processo de projeto, de forma a descrever o sistema para os
engenheiros que o implementam, e após o desenvolvimento, como forma de
documentação.
De acordo com Paula Filho (2009), a disciplina de análise reúne as atividades que
visam modelar de forma precisa os conceitos relevantes do domínio do problema,
servindo tanto para verificar a qualidade dos requisitos obtidos pelas atividades da
disciplina de requisitos, quanto para tornar esses requisitos precisos e detalhados o
suficiente para que sirvam de base para as atividades de desenho.
2.2.2.2
Projeto de arquitetura
Segundo Pressman (2009), a arquitetura de software é composta pela estrutura
hierárquica dos componentes procedimentais e estrutura de dados. A arquitetura
deriva de um processo de divisão em partições, relacionando elementos de uma
solução de software a partes de um problema do mundo real, definidos durante a
análise dos requisitos. Além disso, o projeto arquitetural junto à estrutura de
programa e a estrutura de dados, definindo interfaces que possibilitam que os dados
fluam através do programa.
De acordo com Sommerville (2011), projeto de arquitetura é o primeiro estágio no
processo de projeto de software e identifica os principais componentes estruturais de
um sistema e os relacionamentos entre eles. É um processo criativo no qual se
projeta uma organização de sistema para satisfazer aos requisitos funcionais e não
funcionais de um sistema.
2.2.2.3
Projeto e implementação
3347
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
A implementação realiza o desenho de um sistema em termos de diversos tipos de
componentes de código fonte e código binário. Segundo Paula Filho (2009), classes
e outros elementos de desenho interno são transformados em unidades de
implementação, geralmente constituídas de arquivos de código fonte. O núcleo das
atividades de implementação é formado pelas técnicas básicas que formam o ciclo
de programação: desenho detalhado, codificação, teste de unidade e integração.
De acordo com Pressman (2009), as fases de especificação e projeto estão dirigidas
a um objetivo final, que é a tradução de representações de software para uma forma
que possa ser “entendida” pelo computador, através da etapa de codificação, que é
o processo que transforma o projeto numa linguagem de programação.
Segundo Sommerville (2011), projeto e implementação é o estágio em que o
sistema de software executável é desenvolvido. O projeto de software é uma
atividade em que identifica os componentes de software e seus relacionamentos
com os requisitos levantados, e a implementação é a transformação do projeto em
uma série de programas que compõem o sistema.
De acordo com Mecenas e Oliveira (2005), a fase de construção é o coração do
processo de desenvolvimento, e todo o processo de especificação e projeto toma a
forma de código-fonte na linguagem eleita para o processo. O sucesso dessa fase
dependerá da qualidade dos insumos produzidos nas fases anteriores.
2.2.3 Validação de Software
Segundo Sommerville (2011), validação de software tem a intensão de mostrar que
um software se adequa a suas especificações e satisfaz as especificações do
cliente. O processo de validação possui algumas técnicas. Dentre elas, a principal é
o teste de programa, que consiste na execução do sistema com dados de testes
simulados, e há também as técnicas de inspeções e revisões em cada estágio do
processo de software.
De acordo com Pressman (2009), a atividade de teste de software é um elemento
crítico da garantia de qualidade de software e representa a última revisão de
especificação, projeto e codificação. A atividade de teste tem como objetivos
descobrir erros no software e demonstrar que as funções de software estão
trabalhando de acordo com as especificações, proporcionando uma boa indicação
de confiabilidade de software.
Um teste é uma atividade na qual um produto, sistema ou componente é executado
sob condições especificadas, com observação e registro dos resultados e avaliação
de um ou mais aspectos. Para Paula Filho (2009) a disciplina de testes visa verificar
os resultados da implementação, através do planejamento, desenho e realização
das atividades desse processo. As atividades de testes inserem tantos defeitos em
um produto quanto à própria implementação. Segundo Paula Filho (2009), “... os
testes são indispensáveis para detectar os defeitos que ainda escapam das revisões
e para se avaliar o grau de qualidade de um produto e de seus componentes.”.
De acordo com Sommerville (2011), o processo de teste ocorre normalmente em
três estágios, que consistem no teste de desenvolvimento, no qual os componentes
3348
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
são testados pelas pessoas que os desenvolveram, teste de sistema, no qual os
componentes do sistema são integrados para criar um sistema completo, e
finalmente testes de aceitação, que é o estágio final em que o sistema é testado com
dados fornecidos pelo cliente.
2.2.4 Evolução do Software
Segundo Sommerville (2011), as mudanças no software podem ocorrer a qualquer
momento durante ou após o desenvolvimento do sistema, e a distinção entre o
desenvolvimento e a manutenção está cada vez mais irrelevante, já que a
engenharia de software é um processo evolutivo.
2.3
RUP – Rational Unified Process
Para Sommerville (2011), Rational Unified Process (RUP) é um processo híbrido que
reúne elementos de modelo de processos genéricos, ilustra boas práticas das fases
de especificação e projetos, e apoio a prototipação e a entrega incremental.
De acordo com Paula Filho (2009), o RUP une as disciplinas de análise e desenho
em uma única disciplina e acrescenta disciplinas adicionais de modelagem de
negócios, implantação, gestão de configurações e alterações, gestão de projetos e
ambiente. O RUP não pode ser considerado como um processo único, mas uma
plataforma que permite construir uma grande família de processos padronizados
para muitos portes de projetos e aplicações diferentes.
O RUP é um modelo que identifica quatro fases distintas no processo de software,
de acordo com Sommerville (2011):
a) Concepção: Identificação das entidades externas (sistemas e pessoas)
que vão interagir com o sistema e definir essas interações;
b) Elaboração: Compreensão do problema dominante, definição de
arquitetura do sistema, e desenvolvimento do plano do projeto;
c) Construção: Esta fase envolve o projeto, programação e teste do sistema;
d) Transição: Transferência do sistema do ambiente de desenvolvimento
para o ambiente de produção.
Ainda segundo Sommerville (2011), o RUP prioriza as atividades que ocorrem
durante o processo de desenvolvimento, denominando essas atividades de
workflows, sendo seis workflows centrais, identificados no processo, e três workflows
de apoio. Os workflows são estáticos e são atividades técnicas que não são
associadas a uma única fase, mas podem ser utilizadas durante todo o
desenvolvimento para alcançar metas específicas. Os workflows centrais de
engenharia e de apoio estão descritos na Tabela 1.
TABELA 1
Workflows estáticos no Rational Unified Process
WORKFLOW
Modelagem de negócios
Requisitos
DESCRIÇÃO
Os processos de negócio são modelados por meio de casos de
uso de negócios
Atores que interagem com o sistema são identificados e casos
de uso são desenvolvidos para modelar os requisitos do sistema
3349
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
Análise e projeto
Implementação
Teste
Implantação
Gerenciamento de configuração
e mudanças
Gerenciamento de Projeto
Meio Ambiente
Um modelo de projeto é criado e documentado com modelos de
arquitetura, modelos de componentes, modelos de objetos e
modelos de sequência.
Os componentes do sistema são implementados e estruturados
em subsistemas de implementação. A geração automática de
código a partir de modelos de projeto ajuda a acelerar esse
processo.
O teste é um processo interativo que é feito em conjunto com a
implementação. O teste de sistema segue a conclusão da
implementação.
Um release do produto é criado, distribuído aos usuários e
instalado em seu local de trabalho.
Esse workflow de apoio gerencia as mudanças do sistema.
Esse workflow de apoio gerencia o desenvolvimento do sistema.
Esse workflow está relacionado com a disponibilização de
ferramentas apropriadas para a equipe de desenvolvimento de
software.
Fonte: Sommerville, 2011, p. 35.
2.4
Gestão do conhecimento
Vive-se hoje em uma nova ‘era’ chamada de pós-capitalismo. Dowbor (2008)
esclarece que já é possível substituir o individualismo e a competição, bases do
capitalismo, pelo Paradigma da Colaboração. A transição pode ser vista de forma
transparente nas comunidades de Softwares Livres aonde, já, em vários âmbitos,
vem se sobre saindo a ideia colaborativa no desenvolvimento de softwares em cima
de propriedades intelectuais e patentes. A inteligência coletiva vem se mostrando
cada dia mais forte e podemos observar de forma concreta esta afirmação através
da Wikipédia.
Este mesmo autor cita uma passagem interessante sobre o Paradigma da
Colaboração: “A colaboração para criar coisas novas ou simplesmente úteis é uma
das fontes mais importantes de prazer (…). O paradigma da colaboração, além de
constituir uma visão ética e de materializar valores das pessoas que querem gozar
uma vida agradável e trabalhar de maneira inteligente e útil — em vez de ter de
matar um leão por dia — constitui hoje bom senso econômico em termos de
resultados para o conjunto da sociedade”.
Através desta reflexão, é possível notar que tal mudança se faz necessária devido
aos benefícios no ambiente do trabalho, tanto das diretrizes quanto dos funcionários.
Logo a Gestão do Conhecimento é crucial para o avanço do Paradigma da
Colaboração de forma concreta e inteligente.
Para entender um pouco sobre o que é Gestão do Conhecimento deve-se iniciar a
apresentação de alguns conceitos sobre dados, informação, conhecimento. Dados
de uma forma bem genérica podem ser definidos como “conjunto de fatos distintos e
objetivos, relativos a eventos” (DAVENPORT; PRUSAK, 1998, p. 2). É a matéria
prima de maior relevância da informação, porém o dado sozinho não representa um
evento em si, não tem muito significado já que sem contexto ficam muito vagos
determinados conjuntos de caracteres.
Já a informação é um conjunto de dados que faz a diferença para o meio, e existem
dois pontos de comunicação, um emissor e outro receptor, e esta pode ser de
3350
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
caráter visual ou sonoro. Segundo Drucker (1999, p.32), as informações: “São dados
interpretados, dotados de relevância e propósito” e lembrando que esta tem
capacidade de produzir conhecimento.
Davenport e Prusak (1998) entendem que o conhecimento é a informação tratada,
assim como informação é um dado tratado. Para que a informação torna-se
conhecimento “[...] os seres humanos precisam fazer virtualmente todo o trabalho.”
Através de comparações, implicações, relações entre os conhecimentos novos e
antigos e um alinhamento entre pessoas sobre determinada informação são
responsáveis pelo conceito de transformação entre uma informação para um
conhecimento.
Ainda Davenport e Prusak (1998), citam que o conhecimento é a mais valiosa
informação de uma organização, porém tem por confronto direto ser a mais difícil de
gerenciar, porque seu valor é diretamente ligado ao ser humano que por ora é uma
variável inconstante, mas responsável por ideias inovadoras, percepções novas e
interpretações a partir destas informações sendo aplicadas diretamente no rumo da
empresa, dos novos projetos e se bem direcionada em um pró de grande valia para
as organizações.
Segundo Zaidan (2008), a retenção do conhecimento tem por objetivo dar um
suporte as atuais organizações, transformando o conhecimento e capacidade de
intelecto dos seus funcionários em vantagens competitivas através da Gestão do
Conhecimento, sendo que desta forma não permite a dissipação e até mesmo a
perda do mesmo. Porém reter este conhecimento é um grande desafio para as
organizações.
Para Felix (2003), a definição da qualidade da informação é auditada e verificada
através de medições como forma de avaliação, como pode ser verificada na Tabela
2. Para este autor uma informação é de qualidade para uma organização quando
todos os dados do quadro acima são preenchidos de forma sistemática, completa e
com seriedade dado que a importância da qualidade de uma informação é de
extrema importância para competitividade no atual mercado.
TABELA 2
Dimensões da qualidade da informação
Fonte: Felix, 2003, p. 37 e 38.
3351
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
2.5
Gestão do conhecimento e processo de desenvolvimento de software
Os patrimônios das empresas de desenvolvimento de software não consistem em
construções ou máquinas. O principal ativo dessas empresas está no capital
intelectual de seus colaboradores, e o grande problema é que esses colaboradores
vão para casa todos os dias, e as empresas de software enfrentam o grande desafio
de manter esse capital intelectual. Rus e Lindvall (2002) complementam que a
gestão do conhecimento se torna única porque o papel principal é desempenhado
pelas pessoas, como importantes portadoras do conhecimento que pode ser
sistematicamente compartilhado em uma organização.
Para Zaidan, Jamil e Libério (2010), considerar o processo de desenvolvimento de
software com apoio da gestão do conhecimento é extremamente oportuno, pois o
processo de desenvolvimento é uma atividade de intensa comunicação e que
estrutura ideias e procedimentos muitas vezes não documentados formalmente. As
empresas de desenvolvimento de software possuem uma expressiva demanda por
informações para a execução de seus processos e o uso adequado da gestão do
conhecimento pode gerar uma grande vantagem competitiva para essas
organizações.
Segundo Ward e Aurum (2004), a gestão do conhecimento e experiência são meios
fundamentais pelos quais o desenvolvimento de software e as melhorias do
processo ocorrem. Dentro do domínio da engenharia de software, a qualidade
continua a ser uma questão de preocupação, e a gestão do conhecimento oferece
às organizações a oportunidade de apreciar os desafios e complexidades inerentes
ao desenvolvimento de software.
De acordo com Dingsoyr (2002), as empresas de desenvolvimento de software tem
uma grande pressão dos clientes para oferecer melhores soluções, mais baratas, e
em um menor prazo. Muitos pesquisadores têm trabalhado com ideias de como
melhorar o processo de desenvolvimento. Como o desenvolvimento de software é
uma tarefa de muito conhecimento intensivo, recentemente tem aumentado muito a
utilização da gestão do conhecimento como meio de melhorar o desenvolvimento de
software.
O conhecimento na engenharia de software é disperso, de proporção imensa e de
crescimento contínuo. Rus e Lindvall (2002) descrevem algumas necessidades de
conhecimento de organizações ligadas ao desenvolvimento de software:
a) Aquisição de conhecimento sobre novas tecnologias: a necessidade de
monitoração do ambiente em busca de novas tecnologias é constante nas
organizações que desenvolvem software;
b) Acesso a novos domínios de conhecimento: o desenvolvimento de
software não envolve só conhecimento sobre o software ou as tecnologias
relacionadas. Envolve também o domínio do conhecimento do campo para
o qual o software está sendo desenvolvido, como por exemplo,
conhecimento médico no caso de um software para a área de medicina;
c) Compartilhamento do conhecimento sobre políticas e práticas
institucionais: novos membros de uma organização precisam conhecer
3352
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
sobre a cultura da organização, assim como a infraestrutura de trabalho e
as práticas institucionais;
d) Captura de conhecimento e saber quem faz o quê: o indivíduo é o ponto
chave para o sucesso de qualquer projeto de engenharia de software.
Saber o tipo de conhecimento possuído por cada empregado é
indispensável na criação de uma estratégia que previna o
desaparecimento de conhecimentos valiosos;
e) Colaboração e compartilhamento do conhecimento: a colaboração está
relacionada com a troca mútua de conhecimento. Membros de uma equipe
de desenvolvimento de software precisam de um meio de colaboração e
troca de conhecimento independente de tempo e espaço.
Para a implantação da gestão do conhecimento em empresas de desenvolvimento
de software, muitos desafios e obstáculos devem ser superados. De acordo com
Zaidan, Jamil e Libério (2010), três questões são particularmente importantes:
a) Questão tecnológica: A tecnologia de software suporta a gestão do
conhecimento? É possível integrar todas as ferramentas para alcançar o
nível planejado de compartilhamento?
b) Questão organizacional: É um erro focar somente na tecnologia e
esquecer a metodologia. É um risco cair na cilada tecnológica sem um
planejamento adequado para a implementação da gestão do
conhecimento;
c) Assuntos individuais: Funcionários frequentemente não têm tempo de
entrar ou procurar por conhecimento, ou não desejam disponibilizar seus
conhecimentos. E não querem reusar conhecimentos dos outros.
O conhecimento acumulado pelos vários membros de uma equipe de projeto pode
ser útil em projetos futuros, e apresenta uma fonte potencial de aprendizado
organizacional na engenharia de software. No entanto, a identificação, organização,
armazenamento, utilização, evolução e difusão do conhecimento são tarefas bem
complexas. Conforme complementa Garcial, Zambalde e Costa (2008), a gestão do
conhecimento melhora o trabalho de processo de desenvolvimento de software
através de uma gestão explícita e sistemática do conhecimento organizacional,
como aquisição, armazenamento, organização, evolução e acesso eficiente.
Rus e Lindvall (2002) acreditam que é de suma importância a elaboração de
documentos no desenvolvimento de um software, pois é através destes que são
feitas as “capturas do conhecimento produzido”. Se este processo for bem
executado, o conhecimento será retido em forma de documentos e disponibilizado
para os membros das equipes desenvolvedoras nos projetos futuros permitindo a
reutilização de códigos, soluções para determinados problemas assim diminuindo o
tempo e o gasto nestes projetos. Caso isto não seja feito será necessário um contato
com a pessoa detentora daquele conhecimento específico e como disse Fernando
Zaidan (2008), “Conhecimento tem pernas e caminha para casa todos os dias”.
Ainda Rus e Lindvall (2002) sem está Gestão do Conhecimento a estruturação dos
processos nas organizações, principalmente as de Tecnologias da Informação
acaba sendo comprometidas quanto à produtividade e competitividade.
3353
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
Para Zaidan, Jamil e Libério (2010), as organizações podem utilizar da gestão do
conhecimento para fornecer soluções em seus negócios, evitando erros e
retrabalho, redução no tempo de custo de desenvolvimento, e aumento de
qualidade, através da utilização em projetos futuros de bases de conhecimento
obtidas em projetos anteriores. De acordo com esses autores, as atividades da
gestão do conhecimento suportadas no desenvolvimento de software são:
• Gestão de documentos: muitos documentos, processos e atividades são
envolvidos na engenharia de software. Estes documentos são
frequentemente criados, revisados e utilizados. Existem diversas
ferramentas para a gestão de documentos;
• Gestão de competência: ou gestão de habilidades; quem sabe o quê – uso
do conhecimento não documentado;
• Reuso de software: programadores não se cansam de implementar a
mesma solução; o reuso é para evitar o retrabalho; incentivo ao repositório
de reuso. Somente será desenvolvido algo novo caso não se encontre nada
para reusar;
• Aprender com experiências necessita de um suporte à memória do
produto e do projeto. As práticas da engenharia de software que ajudam a
construir memórias são: controle de versão, gestão de modificações,
documentação de padrões e rastreabilidade de requisitos.
Em todas estas práticas, a retenção do conhecimento é altamente indicada
(ZAIDAN; JAMIL; LIBÉRIO, 2010).
Para Garcial, Zambalde e Costa (2008), as organizações que desejam melhorar a
capacidade de uma equipe de desenvolvimento de software devem administrar as
tarefas que asseguram que o conhecimento adquirido durante o projeto será
armazenado para utilização nos próximos projetos. O conhecimento adquirido deve
gerar novos conhecimentos, através de lições aprendidas e análises posteriores que
identificam o que foi considerado certo, para ser reutilizado, e o que foi considerado
errado, para ser reavaliado, no produto ou processo. Ainda segundo os autores,
essas atividades incluem análise dos dados do projeto, como comparações entre
custos estimados e custos gastos, e tempo estimado e tempo gasto, ou análise das
mudanças históricas que refletiram nos eventos dos projetos.
2.5.1 A Organização Fábrica de Experiência (OFE)
Um modelo de implementação de gestão do conhecimento e processo de
desenvolvimento de software, proposto por Basili (1989), citado por Rus e Lindvall
(2002) e Zaidan, Jamil e Libério (2010), é o conceito de Organização de Fábrica de
Experiência, que visa à aquisição de conhecimento de lições aprendidas e melhores
práticas em projetos através de experiências em projetos anteriores. Esse modelo
pode ser verificado na Figura 1.
Como o dia a dia de um projeto envolve a utilização de cronogramas, expectativas
quanto à qualidade e produtividade, e desafios técnicos, a equipe envolvida
diretamente no projeto não tem disponibilidade para o trabalho de explicitação do
conhecimento. Nesse modelo proposto, essa atividade fica com a equipe
denominada de Fábrica de Experiência, que analisa e sintetiza todos os tipos de
experiência, incluindo lições aprendidas, dados de projetos, relatórios, e explicitam
estas experiências através da criação de repositórios.
3354
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
De acordo com Zaidan, Jamil e Libério (2010), o que é mais essencial na OFE não é
a experiência, mas os novos conhecimentos gerados a partir da experiência. As
OFE precisam empacotar a experiência, por meio de análise, síntese e avaliação da
experiência bruta, e construir modelos que representam a abstração dessas
experiências.
FIGURA 1 – Organização de Fábrica de Experiência
Fonte: Victor Basili, 1989, adaptado por Zaidan, Jamil e Libério, 2010.
3 PROCEDIMENTO METODOLÓGICO
Para essa pesquisa, realizou-se um estudo de natureza exploratória, utilizando a
abordagem qualitativa, através do método de estudo de caso, de forma identificar o
processo de desenvolvimento de software de uma empresa de TI de médio porte, e
verificar como esse processo de desenvolvimento pode ser implementado, difundido
e melhorado através da colaboração de seus funcionários.
O paradigma qualitativo se justifica na medida em que a investigação se deu em
uma ótica compreensiva e interpretativa, o que exigiu dos pesquisadores uma
postura puramente crítica (GIL, 2010; VERGARA, 2011).
Acerca do estudo de caso, Yin (2010) assevera que é uma estratégia escolhida para
examinar acontecimentos contemporâneos inseridos nos contextos da vida real. Gil
(2010) complementa que o estudo de caso caracteriza-se por grande flexibilidade na
forma de desenvolver a pesquisa.
Foi realizada uma busca em livros e em trabalhos técnicos e científicos, a fim de
examinar as práticas e ferramentas da Gestão do Conhecimento, assim como
3355
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
identificar os conceitos e modelos da Gestão do Conhecimento e sua aplicabilidade
no processo desenvolvimento de software.
A amostra, escolhida por conveniência, é uma empresa que atua no mercado de
software. A seguir tem-se a descrição completa da empresa e a proposta elaborada
para este estudo.
4 PROPOSTA DE UTILIZAÇÃO DA GESTÃO DO CONHECIMENTO EM UMA
EMPRESA DE TI
A empresa sob a qual será realizada a proposta do modelo de gestão do
conhecimento como forma de otimização do processo de desenvolvimento de
software, é uma empresa que está sediada em Belo Horizonte/MG com filiais em
São Paulo/SP, Rio de Janeiro/RJ e Vitória/ES e tem atuado no mercado de software
há mais de 20 anos. A empresa é especializada em projetos sob medida,
infraestrutura e outsourcing, mas nos últimos anos se firmou como uma das grandes
empresas brasileiras fornecedoras de sistemas integrados para Instituições
Financeiras, Fundos de Pensão e Sistema Corporativo de Assistência.
Apesar de manter uma posição solidificada no mercado, a empresa está passando
por uma fase de transição, com grandes investimentos de forma a modernizar e
reestruturar seus principais produtos. Para isso foi criado um Centro de Excelência,
cujo objetivo principal é a criação de um processo padronizado de desenvolvimento
de software, utilizando de seu excelente nível do quadro técnico e da expertise do
conhecimento adquiridos durantes esses anos nas áreas de negócio em que atua.
Além do centro de excelência recém-criado, a empresa possui uma área de apoio,
GTA (Gerência de Tecnologia), que possui um quadro altamente qualificado de
arquitetos com grandes conhecimentos nas mais diversas tecnologias.
O primeiro passo criado pela empresa em questão para o processo de
reestruturação de seus produtos e concepção de novos módulos foi a criação de
uma nova metodologia de desenvolvimento de sistemas, baseada no RUP e UML.
Essa metodologia atua nas seguintes fases do processo de desenvolvimento:
especificação, análise, projeto e desenvolvimento. De acordo com Zaidan, Jamil e
Libério (2010), o que é mais essencial na OFE não é a experiência, mas os novos
conhecimentos gerados a partir da experiência. As OFE precisam empacotar a
experiência, por meio de análise, síntese e avaliação da experiência bruta, e
construir modelos que representam a abstração dessas experiências.
Dentre vários autores estudados, a maioria possui a mesma ideia, de que no
processo de software é fundamental de que o conhecimento adquirido em projetos
realizados seja utilizado em projetos futuros, de forma a evitar retrabalho, reduzir
custo e prazo, e melhorar a qualidade. Porém isso não é uma tarefa fácil, e de
acordo com os mesmos autores, foram identificados quatro pontos principais que
devem ser trabalhados para a implementação de uma gestão de conhecimento no
processo de desenvolvimento, e a proposta desse estudo é a atuação nesses quatro
pontos:
3356
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
a) Questão tecnológica: integração de ferramentas de forma que o
conhecimento fique centralizado em um único lugar;
b) Questão organizacional: criação de metodologia e atuação da gerência
para garantir que o processo esteja sendo feito conforme planejado;
c) Captura do conhecimento: criação de métodos de documentação de forma
que conhecimentos adquiridos sejam disponibilizados em algum
repositório;
d) Compartilhamento do conhecimento: criação de métodos de controle de
forma que os conhecimentos adquiridos e armazenados sejam
efetivamente utilizados.
Em relação à questão tecnológica, a empresa do estudo já deu um grande passo na
questão da centralização das informações, que é a utilização da ferramenta
Enterprise Architect – EA. O EA é uma ferramenta que é fornece um ambiente de
modelagem que contempla o pleno desenvolvimento do ciclo de vida de um produto,
com ferramentas para modelagem de negócios, engenharia de sistemas, arquitetura
corporativa, gerenciamento de requisitos, projeto de software, geração de códigos,
etc. A ferramenta permite que todos os artefatos gerados no processo de
desenvolvimento fiquem no mesmo local, e permite a criação de matrizes de
rastreabilidades entre esses artefatos, permitindo o controle de alterações e os
impactos gerados por essas alterações, durante o ciclo de vida do projeto. Além
disso, a ferramenta possui várias funcionalidades referentes a documentações e
relatórios, de forma que a documentação do projeto fique concentrada no mesmo
ambiente do projeto.
Para o controle dos processos e andamento dos projetos, a empresa utiliza uma
ferramenta desenvolvida internamente de controle de atendimento técnico. Através
dessa ferramenta é possível registrar fluxos com todas as tarefas de execução do
processo de desenvolvimento, anexando artefatos gerados e arquivos relevantes.
Essa ferramenta permite também a apropriação de horas trabalhadas pelos recursos
em cada fase de cada projeto.
Com relação à base de conhecimento gerada pelos projetos, é proposta a criação de
um portal único de memória técnica, utilizando a ferramenta SharePoint, de fácil
acesso a toda empresa, contendo instruções, exemplos e melhores práticas para
cada item da metodologia de desenvolvimento criada. A ideia é de que esse portal
seja atualizado de acordo com o andamento dos projetos, de forma que cada etapa
da metodologia fique bem documentada e padronizada, para a utilização nos
projetos futuros. De acordo com Falconi (2004) as funções operacionais ocupam
muito tempo das pessoas de uma empresa e são centradas na padronização.
Para a questão organizacional, a proposta desses autores é de que haja uma forte
ação da gerência nesse processo, o que pode até alterar a cultura organizacional da
empresa. A proposta é a utilização de um modelo semelhante ao conceito de
Organização de Fábrica de Experiência – OFE, proposto por Basili (1989), citado por
Rus e Lindvall (2002) e Zaidan, Jamil e Libério (2010). Para a empresa em questão,
o papel da OFE seria executado pela equipe de arquitetura GTA da empresa, que
ficaria responsável por externalizar os conhecimentos adquiridos durante os
andamentos dos diversos projetos da organização. Essa equipe seria encarregada
de analisar e sintetizar os diversos tipos de experiências para cada fase da
3357
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
metodologia da empresa, além de lições aprendidas no contexto geral, de forma a
criar os procedimentos operacionais padrão para cada fase da MDS. O modelo
proposto pelos autores pode ser verificado na Figura 2.
Não adianta apenas capturar o conhecimento. Deve se certificar que o mesmo
esteja sendo útil nos novos projetos. A proposta dos autores desse trabalho é de
que a OFE libere e divulgue periodicamente as atualizações no portal criado de
forma que os procedimentos operacionais padrão sejam de conhecimento de toda a
equipe de desenvolvimento.
Os gerentes de projetos devem ter o controle do andamento de cada projeto sob sua
coordenação, verificando se os procedimentos operacionais, considerados ‘padrão’,
disponibilizados no portal, estejam sendo utilizados pela equipe nos novos projetos,
além de fazer o monitoramento de tempo e esforço gasto em cada fase da
metodologia, de forma que esses dados também sejam utilizados para
dimensionamento de futuros planejamentos de projetos. Os gerentes devem ficar
atentos a todos os eventos que fogem dos procedimentos operacionais ‘padrão’
definidos. Para Falconi (2004), esses eventos são denominados anomalias, que não
agregam valor para a empresa e devem ser eliminados, para aumento de
produtividade. As anomalias devem ser eliminadas através de ações corretivas, e a
causa dos problemas deve ser estudada, para identificar se sua origem foi pela não
adoção do procedimento ‘padrão’ ou se o procedimento deve ser revisado,
documentado e divulgado pela OFE. Dessa forma, acredita-se que a cultura do
conhecimento coletivo se sobressairá ao conhecimento individual. A figura abaixo
representa o que foi discutido nesta proposta.
FIGURA 2 – Organização de Fábrica de Experiência Proposta
Fonte: Victor Basili, 1989, adaptado pelos Autores.
3358
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
5 CONSIDERAÇÕES FINAIS
Após serem identificadas e analisadas as necessidades da empresa quanto ao
processo de implementação, propagação e evolução de um novo processo de
desenvolvimento de software, foi possível verificar que a Gestão do Conhecimento
pode contribuir para melhorar esse processo, para o gerenciamento e para a gestão
de novos projetos.
As práticas da Gestão do Conhecimento conduzem a uma memória organizacional,
documentação do conhecimento existente, troca de informações e trabalho
colaborativo, que são fundamentais para toda organização, principalmente para as
empresas de software, cujos patrimônios não consistem em construções ou
máquinas, e sim no capital intelectual de seus colaboradores.
A partir do estudo da Gestão do conhecimento no Processo de Desenvolvimento de
Software, foram definidos procedimentos para atuação nos quatro pontos principais
que devem ser trabalhados para a implemetação de uma gestão de conhecimento
no processo de desenvolvimento: i) questão tecnológica; ii) questão organizacional;
iii) captura do conhecimento; iv) compartilhamento do conhecimento.
A utilização de uma ferramenta que abrange as fases de Especificação, Modelagem
e Projeto, que no caso é o EA - Enterprise Architect, permite que os artefatos
gerados no processo de desenvolvimento fiquem em um mesmo repositório,
permitindo a rastreabilidade entre os artefatos e documentação do sistema em um
único lugar. A utilização de uma OFE permite que o conhecimento de lições
aprendidas e melhores práticas em projetos anteriores sejam guardados e utilizados
nos novos projetos, de forma a evitar retrabalhos e agilizar o processo.
No entanto, foi verificado que um dos fatores mais importantes para implementação
da Gestão do Conhecimento reside na cultura organizacional da empresa. Conforme
descrito nesse estudo, deve ser feito um processo de sensibilização dos
colaboradores de forma a contribuir efetivamente para utilização e evolução da base
de conhecimento gerada, pois a Gestão do Conhecimento tem nas pessoas a chave
para seu sucesso.
Como perspectivas futuras, espera-se que o modelo de Gestão do Conhecimento
aqui apresentado seja implementado e seguido na empresa que foi o objeto desse
estudo de caso, de forma a avaliar os impactos da Gestão do Conhecimento no
processo de desenvolvimento. Esse estudo também pode ser utilizado como base
para outras empresas de desenvolvimento de software que precisam melhorar seus
processos de forma a obter maior qualidade, agilidade e competitividade.
REFERÊNCIAS
BASILI, V. R. Software Development: a paradigm for the future. Computer Software
and Applications Conference, 1989. COMPSAC 89., Proceedings of the 13th
Annual Internacional. In IEEE Internet Computing, 1989.
3359
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
DAVENPORT, T.H., PRUSAK, L. Conhecimento empresarial. Rio de Janeiro:
Campus, 1998.
DINGSOYR, T. Knowledge Management in Medium-Sized Software Consulting
Companies. Trondheim: Norwegian University of Science and Technology. 2002
DOWBOR, L. Democracia Econômica – alternativas de gestão social. Petrópolis:
Vozes, 2008.
DRUCKER, P. Desafios gerenciais para o século XXI. São Paulo: Pioneira, 1999.
FALCONI, V. Gerenciamento da rotina do trabalho do dia-a-dia. 8 ed. Nova Lima:
INDG Tecnologia e Serviços Ltda., 2004.
FELIX, W. Introdução à gestão da informação. Campinas: Alínea, 2003.
GARCIA, V. de O. C.;ZAMBALDE, A. L.;COSTA, H. A. X. Práticas e Ferramentas
de Gestão do Conhecimento Aplicadas à Engenharia de Software – Um Estudo
de Caso. IV Workshop Um Olhar Sociotécnico sobre a Engenharia de Software –
WOSES. Florianópolis, 2008.
GIL, A. C. Como elaborar projetos de pesquisa. 5. ed. São Paulo: Atlas, 2010.
LIMA, A. da S. UML 2.0: do requisito à solução. 4 ed. São Paulo: Érica, 2009.
MECENAS, I; OLIVEIRA, V. Qualidade em Software: uma metodologia para
homologação de sistema. Rio de Janeiro: Alta Books, 2005.
PAULA FILHO, W. de P. Engenharia de Software: fundamentos, métodos e padrões.
3 ed. Rio de Janeiro: LTC, 2009.
PRESSMAN, R. S. Engenharia de Software. São Paulo: Pearson Makron Books,
2009.
RUS, I; LINDVALL, M. Knowledge Management in Software Engineering.Fraunhofer
Center for Experimental Software Engineering, 2002, Maryland.In IEEE Internet
Computing, 2002.
SOMMERVILLE, I. Engenharia de Software. 9 ed. São Paulo: Pearson Prentice
Hall, 2011.
VERGARA, S. C. Projetos e relatórios de pesquisa em administração. 13. ed.
São Paulo: Atlas, 2011.
YIN, R. K. Estudos de caso: planejamento e métodos. 4. ed. Porto Alegre:
Bookman, 2010.
3360
10th International Conference on Information Systems and Technology Management – CONTECSI
June, 12 to 14, 2013 - São Paulo, Brazil
WARD, J; AURUM, A. Knowledge Management in Software Engineering – describing
the process. Software Engineering Conference, 2004, Proceedings Australian.In
IEEE Internet Computing, 2004.
ZAIDAN, F. H. Processo de Desenvolvimento de Sistema de Informação como
Forma de Retenção do Conhecimento Organizacional para Aplicação
estratégica: Estudo de Casos Múltiplos. 2008. 129f. Dissertação (Mestrado em
Administração) – Universidade FUMEC, Belo Horizonte, 2008.
ZAIDAN, F. H.; BAX, M. P. WIKI Ferramenta de colaboração corporativa da WEB
2.0: estudo de caso. In: 7º CONTECSI Congresso Internacional de Gestão de
Tecnologia e Sistemas de Informação, 2010, São Paulo: Centrografica Grafica &
Editora Ltda, 2010.
ZAIDAN, F. H.; JAMIL, G. L.; LIBÉRIO, L. Organização Fábrica de Experiência:
obtendo vantagens competitivas nas empresas desenvolvedoras de software.
Engenharia de Software Magazine. Ano 2. 21 ed. 2010.
3361