Knowledge for software maintenance

Proceedings of the Fifth Mexican International Conference in Computer Science (Enc 2004), 2004

Software maintenance is an activity that requires lots of knowledge. For example, maintainers must know what changes should do to the software, where to do those changes and how those changes can affect other modules of the system. Frequently they do not have enough knowledge to make the best decision and must consult other information sources, but these sources are often unknown or difficult to locate. Therefore, knowledge management could be useful to address some of these problems; however, before knowledge management tools could be developed for software maintenance groups, some questions must be answered: such as what kinds of problems could be solved. In this paper a qualitative approach to the identification of knowledge management needs in software maintenance teams is presented. This approach has been applied in two case studies, and an agent-based knowledge management tool has been designed and implemented from the results obtained.

Journal of Universal Computer Science - J.UCS, 2003

Abstract: Knowledge engineering emerged as a very promising area to help improve software engineering practice. One of its possible applications would be to help in solving the numerous,problems,that affect the software maintenance activity. Maintainers of legacy systems developed years ago with obsolete techniques and tools, and not documented, need all kinds of knowledge (application domain, programming skills, software engineering techniques, etc.) It is generally assumed that formalizing all this knowledge and recording it would be a worthwhile effort. However, research is still in a early stage and numerous questions need to be answered: What knowledge should be targeted first? Where to find this knowledge? etc. To answer these questions, one needs a precise understanding of what knowledge is at stake here. We, therefore, propose an ontology of the knowledge needed to perform software maintenance. This ontology would be most useful as a framework for future research in knowledg...

Lecture Notes in Computer Science, 2004

Developing and maintaining software systems is a knowledge intensive task. One needs knowledge of the application domain of the software, the problem the system solves, the requirements for this problem, the architecture of the system and how the different parts fit together, how the system interacts with its environment, etc. More often than not, this knowledge is not documented and lives only in the head of the software engineers. It is, therefore, volatile and an organization may repeatedly pay professionals to rediscover a knowledge it previously acquired and lost. In recognition of this fact, knowledge management techniques such as Postmortem Analysis are being used to help salvage this knowledge. Traditionally, Postmortem Analysis has been applied at the end of software development projects with a focus on organizational aspects such as how to improve the execution of a process. In this paper, we present the application of Postmortem Analysis in a new context: for software maintenance projects. We also apply it, not only for process improvement, but to discover knowledge on the software maintained itself.

Knowledge Management, 2010

KMS for SM has been studied late 1980s by , who introduced a prototype KMS to control database software development and maintenance, mainly to facilitate program comprehension. The KMS is a decision-based approach that facilitates communication across time and among multiple maintainers and users, thus improving maintenance support. However, facilitating program comprehension is not enough as SM is more than just understanding codes and extracting knowledge from codes. Similarly, Deraman (1998) introduced an KMS model for SM which, albeit very simple, could provide us with the main essence of SM knowledge -the Software Knowledge, Change Request Knowledge and their functional interaction. However, these alone, are not enough for users and maintainers. Newer technologies such as software agents are used to capture SM process knowledge in researches conducted by Viscaino et al. and Rodriguez et al. (2004b). However, no KMS framework for SM was conceptualized by these studies. Looking at the wider perspective of software engineering (SE), KMS in SE have been studied by many, including Santos et al. , Rus and Lindval and . Rus and Lindval described the three main tasks of SE (individual, team and organization) and identified the three level of KM support for each task. The 1st level includes the core support for SE activities, document management and competence management. Meanwhile, the 2nd level incorporates methods to store organizational memory using method such as design rationale and tools such as source control and SCM. The 3rd KM support level includes packaged knowledge to support Knowledge definition, acquisition and organization. The above should describes the KMS framework for SE. However, this model do not consider the social, physiological and cultural aspects of KM, as identified by the previous other generic KMS frameworks. In order to propose a suitable KMS framework for SM,, a review of current KMS framework for generic KMS, and related SE/SM KMS are conducted. The theoretical constructs for KM frameworks, KMS frameworks and knowledge components in SM are summarized, and components suitable for SM KMS framework are identified,

Proceedings of the Thirtieth Hawaii International Conference on System Sciences, 1997

A conceptual model for a software maintenance method named COMFORM (Configuration Management Formalization for Maintenance) is presented. COMFORM provides guidelines and procedures for carrying out the maintenance process, while establishing a systematic approach for the support of existing software systems. Incremental documentation, the process of building up the software documentation while the system is maintained, has a key role in this maintenance method. The documentation required by the method consists of keeping the maintenance history and information related to the software modules being maintained. Forms have been created in order to guide the maintainers during the maintenance process. Thus, their task will be of filling in forms for generating the required documentation instead of defining their own document structures. The system information obtained by filling in forms has been formalized according to a data model which provides a common basis for the representation of the method. This paper presents the conceptual model for COMFORM which was obtained using the data model termed Object Representation Model (ORM). ORM has been used because of its enhanced semantic capabilities and it provides the necessary generality and standardization for software representation.

Computer and Information Science, 2009

Knowledge management (KM) become important for organization to take advantage on the information produced and can be brought to bear on present decision. Software maintenance (SM) is a process that requires lots of knowledge. Maintainers must know what changes should do to the software, where to do those changes and how those changes can affect other modules of the system. Knowledge management system (KMS) can support the processes of knowledge creation, storage or retrieval, transfer and application. KMS in SM could help the organization to make tacit knowledge into explicit and therefore decrease the dependency on employees' cognition. This paper is to apply KMS architecture in SM environment to overcome the problem faced by software maintainers during the software maintenance process.

2011 15th European Conference on Software Maintenance and Reengineering, 2011

Knowledge of in-the-field software operation is acquired unsophisticatedly: acquisition processes are implemented ad hoc, application-specific and are only triggered when endusers experience severe failures. Vendors that do acquire such knowledge structurally from their software applications, often are unsuccessful in visualizing it in a consistent and uniform manner. A generic approach to acquisition and presentation of software operation knowledge reduces the time vendors need to integrate acquisition logic into their applications, as well as the time needed to analyze, compare and present uniform software operation data resulting from in-the-field software operation. This paper proposes a technique for software operation knowledge acquisition and presentation through generic recording and visualization of software operation. A prototype tool implementing this technique is presented, as well as an extensive empirical evaluation of the tool using an eclectic set of instruments (an experiment, two case studies and expert focus group discussions) involving three widely-used software applications. Results show that the technique is expected to reduce software maintenance effort and increase comprehension of end-user software operation.

2002

This article is an overview of software maintance, its relevance, the problems, and the available solutions. The focus is on the structure of the maintenance activity, including general models of the maintenance process, existing standards, and management practices and tools. The article also includes a discussion of related areas that support software maintenance, and particularly reverse engineering, reengineering, and legacy systems.

2003

The purpose of this book is to explore the key issues underpinning software change and to discuss how these issues impact on the implementation of changes to software systems. The motivation for the book came from the need for texts dealing directly with challenges that software engineers face when modifying complex software systems. The extent of this challenge can be seen in the cost of modifying software. This cost can reach 70% of the total life-cycle cost [4, 36, 176]. Software maintenance is recognised as a key area in software engineering [9, 163]. Despite this, many mainstream software engineering courses are biased towards the development of new software systems at the expense of issues surrounding changes to these systems after they become operational [70].