SEKE 2012 Proceedings - Knowledge Systems Institute

A Process-Based Approach to Improving
Knowledge Sharing in Software Engineering
Sarah B. Lee Ph.D., Kenneth Steward
Department of Computer Science and Engineering
Mississippi State University
Mississippi State, MS, USA
sblee@cse.msstate.edu, kcs111@msstate.edu
Abstract—Information technology organizations often
assume that to improve knowledge sharing, a knowledge
management system must be independently developed or
purchased. Also often assumed is the idea that
implementing tools for knowledge sharing will provide a
foundation for the evolution of processes and culture
that support knowledge sharing. The intent of this
research is to illustrate that an effective approach to
increased knowledge sharing and collaboration must
consider first the processes that make up a knowledge
workers daily context, and the knowledge that supports
that workflow. Organization of people and process must
be considered in order for knowledge creation to be
efficient and effective.
Keywords- knowledge management; process
improvement
I. INTRODUCTION
Knowledge has becom e increasingly releva nt for
organizations since the shift from an industrial economy to a
global, decentralized, and knowledge-based econom y.
Organizations now work, compete, and cooperate on a
worldwide scale [1]. T oday, employees are often
geographically separated within a si ngle city or on a
corporate campus. Loss of knowledge in the ha ndoff of
work products is an area of concern. Offices in different
locations may use different terminology and tools, making
knowledge sharing across departmental boundaries a
challenge [2]. A variety of technologies have been
employed to attempt to close t his communication gap
including company intranets, directories, and groupware [3].
When applied to software engineering, knowledge
management deals with a wide domain including projec t
management, communication with clients and e nd users,
problem solving, c ode reuse, staff development, and
maintenance and support. Project success rates continue to
be an area of concern, and one reason given for repeated
failures is that organizations do not adequately use existing
experience to avoid prior mistakes. This occurs when
knowledge created during a project is not captured or shared
for later use [4]. To avoid this continuous cycle,
organizational knowledge produced during the software
development lifecycle (SDLC) must be recognized as a
valuable asset and leveraged to meet objectives.
II. BACKGROUND
While software development shares many characteristics
with other engineering disciplines, it prese nts new
challenges due to its relian ce on the knowledge and
creativity of individual software developers and their
interactions. In addition to the engineering aspects of
software development, cognitive aspects and human activity
must be considered. The development of a software system
requires integration of knowledge from a variety of sources.
Software development can be thought of as “t he
crystallization of knowledge into the software systems” [5].
With a global software development model, the gathering
of requirements may involve a co-located team of analysts
and users. B usiness requirements must be tra nslated to
software requirements specifications, leading ultimately to
development work which may be perf ormed by a team
located separately from the team that worke d on
requirements analysis and development. Throughout the
software development process, knowledge producer and
consumer roles emerge.
A Software Requirements Specification (SRS) is
produced that includes all re quirements needed by the
developers to address the business requirements. The SRS
must be reviewed to validate that it meets the business need
as defined, with traceability to the business requirements
documented. The de velopment and infrastructure support
teams should collaborate to confirm if the SRS is feasible
and verifiable. The SRS is typically used to validate
technical designs, code, and test cases.
The importance of the software architecture design which
documents the com ponents and t heir connectors that
comprise a software system should not be ignored.
Typically all the knowledge regarding the design decisions
on which the architecture is based are implicitly embedded
in the architecture. This lack of explicit representation leads
to increased complexity, a high cost of making changes, and
design erosion. In the design phase, the main concern is on
which design decision should be made. In the coding phase,
700