A formalism of ontology to support a software maintenance knowledge-based system

A formalism of ontology to support a software maintenance

knowledge-based system

Alain April1 _{, Jean-Marc Desharnais}1_{, and Reiner Dumke}2 1 _{École de Technologie Supérieure, 1100 Notre-Dame West, Montreal, Canada}

email: [email protected] , [email protected]

2 _{Department of Informatik, Otto-von-Guericke Universtity of Magdeburg, Germany}

email: [email protected]

Keywords: expert system, decision support, software maintenance maturity model, formal definition of process model.

Abstract: Maintaining and supporting the software of an organization is not an easy task, and software maintainers

do not currently have access to tools to evaluate strategies for improving the specific activities of software maintenance. This article presents a knowledge-based system which helps in locating best practices in a

software maintenance capability maturity model (S3m_{). The contributions of this paper are: 1) To formalise}

the software maintenance ontology, 2) to instrument the maturity model with a support tool to aid software maintenance practitioners in locating specific best practices; and 3) to describe the knowledge-based approach and system overview used by the research team.

1. INTRODUCTION

Knowledge transfer of a large number of best practices, described in a maturity model, has proved difficult (Abran et al., 2004). This is especially true during the training stage for an assessor or a new participant in a process improvement activity. It is also challenging to quickly refer to, or access, a specific practice, or subset of practices, when trying to answer questions during or after a maturity evaluation.

It would be beneficial to have a knowledge-based system (KBS) to help access this complex structure and its large amount of information. A potential solution to this problem is to develop a knowledge-based system that the underlying process model used by the maturity model. This paper presents the proposed modeling of a software maintenance KBS based on the van Heijst methodology (Van Heijst et al., 1997), which consists of constructing a task model, building on a formalism of the domain ontology (Uschold and Jasper, 2001), mapping the ontology onto the knowledge roles in the task model and instantiating the application ontology with this

specific domain knowledge. According to van Heijst, there are at least five different types of knowledge to be taken into account when constructing such a system: tasks, problem-solving methods, inferences, the ontology and the domain knowledge1_{. For van Heijst, domain knowledge} refers to a collection of statements about the domain (Van Heijst et al., 1997). The process domain of this specific software maintenance maturity model is presented in section 2. Examples of statements are presented in section 3. At a high level, the ontology refers to a part of the software maintenance ontology proposed by (Kitchenham et al., 1999) presented in section 4. A formalisation of the software maintenance ontology follows in section 5. The inferences, problem-solving methods and tasks are described at length in section 6 showing the task analysis for the proposed knowledge-based system. The tool environment (showing a user interface

1 _{van Heijst uses the different types of knowledge in a}

more generic way than we do in this document, and these have been adapted for us by Desharnais, J.-M.,Application de la mesure fonctionnelle COSMIC-FFP: une approche cognitive, UQAM,2004 Montréal

layout of the knowledge-based system) followed by a conclusion, as well as future work, are presented in sections 7 and 8.

2. THE S

3m

PROCESS MODEL

The software maintenance maturity model (S3m₎

regroups software maintenance processes in three classes (Figure 1), the main idea is to provide a representation similar to that used by the ISO/IEC 12207 standard but with a focus on software maintenance processes and activities:

• Primary processes (software maintenance operational processes);

• Support processes (supporting the primary processes); and

• Organizational processes offered by the IS/IT or other departments of the organization (e.g., training, finance, human resources, purchasing, etc.).

This generic software maintenance process model helps explain and represent the various key software maintenance processes. The key operational processes (also called primary processes) that a software maintenance organization uses are initiated at the start of a software development project, beginning with the Predelivery and

Transition process. These primary processes are not

limited, as is the case with some standards, to the moment when developers hand over the system to maintainers, but rather ensures that the software project is controlled and that a structured and coordinated approach is used to transfer the software to the maintainer. In this process, the maintainer will focus on the maintainability of this new software, and it means that a process is implemented to follow the developer during the system development life cycle.

Figure 1. A classification of the software maintainer’s key processes. Once the software has become the responsibility of

the maintainer, the Event and Service Request

Management process handles all the daily issues,

Problem Reports, Modification Requests, and support requests. These are the daily services that must be managed efficiently. The first step in this

process is to assess whether a request is to be addressed, rerouted, or rejected (on the basis of the SLA and the nature of the request and its size) (April et al., 2001). Accepted requests are

O p s. Suppo rt Pr oc es se s Maintenance Training Measurement Transition Issue and Request Management control Maintenance Planning Operational Support Service Corrective Service Evolutive Services Purchasing and Human Resources Causal Analysis and Problem Resolution O rgani zat . P ro ces ses Verification - Validation Production Surveillance P ri m ary P roc es ses Sup por t P ro ces se s Maintenance Training Measurement Predelivery and Transition Issue and Request Management Event and Service Request Management and version Management Maintenance Planning Maintenance Planning Operational Support Service Corrective Service Evolutive Services Operational Support Corrections Evolutions Purchasing, Supplier agreement and SLA Causal Analysis and Problem Management O rga ni za ti ona l . P roce sse s Verification - ValidationVerification - Validation Changes Monitoring Configuration Software Evolution Engineering and Analysis Maintenanceof Innovation and Deployment HR and Training Production Surveillance Software Rejuvenation RetirementMigration Developers Users Infrastructure and Operations Assurance Process and Product

Quality Reviews andAudits

Documentation Improvement Process Definition, Assessment, Management Improvement O p s. Suppo rt Pr oc es se s Maintenance Training Measurement Transition Issue and Request Management control Maintenance Planning Operational Support Service Corrective Service Evolutive Services Purchasing and Human Resources Causal Analysis and Problem Resolution O rgani zat . P ro ces ses Verification - Validation Production Surveillance P ri m ary P roc es ses Sup por t P ro ces se s Maintenance Training Measurement Predelivery and Transition Issue and Request Management Event and Service Request Management and version Management Maintenance Planning Maintenance Planning Operational Support Service Corrective Service Evolutive Services Operational Support Corrections Evolutions Purchasing, Supplier agreement and SLA Causal Analysis and Problem Management O rga ni za ti ona l . P roce sse s Verification - ValidationVerification - Validation Changes Monitoring Configuration Software Evolution Engineering and Analysis Maintenanceof Innovation and Deployment HR and Training Production Surveillance Software Rejuvenation RetirementMigration Developers Users Infrastructure and Operations Assurance Process and Product

Quality Reviews andAudits

Documentation Improvement Process Definition, Assessment, Management Improvement

documented and prioritized. They are then assigned, to one of the following types of processes:

• Operational Support process (requests that do not necessitate any modification to software and that are also referenced as support interface types of maintenance (Chapin et al., 2001));

• Corrections process; or

• Evolutions process (which includes adaptive, perfective and recently proposed activity types like enhancive, reductive (Chapin et al., 2001)).

They are then processed. Note that certain service requests do not lead to any modification of the software. In the model, these are referred to as “operational support” activities.

In S3m _{operational support activities consist of:}

• Production of a one time extract of information from existing systems;

• Provision of technical information and counselling to developers and operations; and • Helping customers to better understand the

software, a transaction, its data, or its documentation.

The next primary processes concern the Changes

Monitoring, ensuring that the operational

environment has not been degraded by the promotion of a change in production. Maintainers must always monitor the behavior of the operational system and its environments for signs of degradation, especially after a change. They will quickly warn other support groups (operators, technical support, scheduling, networks, and desktop support) when something unusual happens and judge whether or not an instance of service degradation has occurred that needs to be investigated.

The last primary process addresses Rejuvenation activities to improve maintainability, Migration activities to move a system to another environment and Retirement activities when a system is decommissioned.

As in ISO/IEC12207 a process which is used, when required, by an operational process is said to be an operational support process. In most IS/IT organizations today the developers, maintainers and

operations may share these processes. In this classification, we include: a) documentation processes; b) software configuration and version management processes and associated tools use; c) process and product quality assurance processes; d) verification and validation processes; e) reviews and audits processes; and, finally, f) causal analysis and problem resolution processes, that are often shared with operations. Some problems re-occur or disappear before we can identify them. The causal analysis process identifies long standing issues, their causes and need of more dedication from the personnel. These are all key processes required to support software maintenance operational process activities.

Organizational processes are typically offered by other departments in the organization (e.g., the many maintenance planning perspectives, process related activities, measurement, innovation, training, and human resources). While it is important to measure and assess these processes, it is more important for the maintainer to define and optimize the operational processes first. These are followed by the operational support processes and then the organizational processes.

The S3m _{was designed as a customer-focused}

benchmark for either:

• Auditing the software maintenance capability of a service supplier or outsourcer; or

• Supporting the process improvement activities of software maintenance organizations.

3. S

3m

_{AND KNOWLEDGE}

STATEMENTS

Software maintainers experience a number of problems. These have been documented and an attempt made to rank them in order of importance. One of the first reported investigations was conducted by Lientz and Swanson (Lientz and Swanson, 1981). They identified six problems related to users of the applications, to managerial constraints and to the quality of software documentation. Other surveys have found that a large percentage of the software maintenance problems reported are related to the software product itself. This survey identified complex and old source code which was badly documented and structured in a complex way. More recent surveys

conducted among attendees at successive software maintenance conferences (Dekleva, 1992) ranked perceived problems in the following order of importance (see Table 1). These are also examples of knowledge statements about the domain of software maintenance. Key to helping software maintainers would be to provide them with ways of resolving their problems by leading them to documented best practices.

Table 1: Top maintenance problems (Dekleva, 1992)

Rank Maintenance problem

1 Managing fast-changing priorities

2 Inadequate testing techniques

3 Difficulty in measuring performance

4 Missing or incomplete software documentation

5 Adapting to rapid changes in user organizations

6 A large number of user requests in waiting

7 Difficulty in measuring/demonstrating the

maintenance team’s contribution

8 Low morale due to lack of recognition

9 Not many professionals in the field,

especially experienced ones

10 Little methodology, few standards, procedures or tools specific to maintenance

11 Source code complex and unstructured

12 Integration, overlap and incompatibility of

systems

13 Little training available to personnel

14 No strategic plans for maintenance

15 Difficulty in meeting user expectations

16 Lack of understanding and support from IT

managers

17 Maintenance software running on obsolete

systems and technologies

18 Little will for reengineering applications

19 Loss of expertise when employees leave

There is a growing number of sources where software maintainers can look for best practices, a major challenge being to encourage these sources to use the same terminology, process models and international standards. The practices used by maintainers need to show them how to meet their daily service goals. While these practices are most often described within their corresponding operational and support processes, and consist of numerous procedures, a very large number of problem-solving practices could be presented in a KBS which would answer their many questions about those problems. Examples are presented in section 5. When using the software maintenance ontology in the KBS, it was necessary to consider the structure of the maturity model relationship between the many process domains, roadmaps and practices. This problem is addressed next.

Method

constrains

Client organisation

Client Human Resources Process Procedure Modification Activity Maintenance Activity Maint. Manager Management activity Change Control Event Management Human Resource SLA approves Technique Paradigm Users Resource uses is used in

Maint. Human Resources

performs

Customer Maint. Engineer _{negotiates_with}

Maintenance Management Maintenance Planning performs Maintenance Training informs trains trains Method constrains Client organisation Client organization

Client Human Resources Process Procedure Modification Activity Maintenance Activity Maint. Manager Management activity Change Control Event Management Human Resource Human Resources SLA approves Technique Paradigm Users Resources uses is used in

Maint. Human Resources

performs

Customer Customer Maint. Engineer

Maint. Engineer _{negotiates_with}

Maintenance Management Maintenance Planning Maintenance Planning performs Maintenance Training Maintenance Training informs trains trains Method constrains Client organisation Client organisation

Client Human Resources Process Procedure Modification Activity Maintenance Activity Maint. Manager Management activity Change Control Event Management Human Resource Human Resource SLA approves Technique Paradigm Users Resource uses is used in

Maint. Human Resources

performs

Customer Customer Maint. Engineer

Maint. Engineer _{negotiates_with}

Maintenance Management Maintenance Planning Maintenance Planning performs Maintenance Training Maintenance Training informs trains trains Method constrains Client organisation Client organization

Client Human Resources Process Procedure Modification Activity Maintenance Activity Maint. Manager Management activity Change Control Event Management Human Resource Human Resources SLA approves Technique Paradigm Users Resources uses is used in

Maint. Human Resources

performs

Customer Customer Maint. Engineer

Maint. Engineer _{negotiates_with}

Maintenance Management Maintenance Planning Maintenance Planning performs Maintenance Training Maintenance Training informs trains trains

Figure 2: Part of the software maintenance ontology of (Kitchenham et al., 1999)

4. ONTOLOGY OF THE

SOFTWARE MAINTENANCE

BODY OF KNOWLEDGE

We elected to implement only a subset of the ontology developed by Kitchenham et al. (Kitchenham et al., 1999) and Ruiz et al. (Ruiz et al., 2004) for the initial trial of this research project. Figure 2 describes the different maintenance concepts considered surrounding a software maintenance activity. Software maintenance is highly event-driven, which means that some maintenance activities are unscheduled and can interrupt ongoing work. This subset of the ontology represents many, but not all, the concepts involved in responding to the questions related to the first problem identified by Dekleva: ‘Managing fast-changing priorities.’ Maintainers agree that this is the most important problem they face. How can they handle the fast-changing priorities of the customer? Solutions to this problem are likely to be found by using many paths through the maintenance concepts of the ontology. Navigation through these concepts should lead to associated concepts which are conceptually linked and likely to contribute to a solution, like the need for better event management, change control, maintenance planning, Service

Level Agreements, maintenance manager negotiation, training, procedures, and so forth. Many more concepts must be involved to contribute to all aspects of the solution, but our purpose is to show the utility of a KBS in the software maintenance domain, and it therefore starts with a constrained number of concepts. Maturity models typically include the detailed best practices that could be of help in solving this type of problem. The main issue is that the best practice locations and their interrelationships are hidden in the layered architecture of the maturity model, specifically in its process domains, KPAs and roadmaps. It is therefore necessary to find a way to link this layered architecture with the maintenance concepts of the ontology and proceed to analyze the tasks required to build a KBS to support the maintainers in their quest for solutions.

The next section presents a formalisation of software maintenance ontology using a representation based on set theory. The formal rules are used, as part of the knowledge based representation, to better define the maintenance domain concepts of the ontology for the task analysis activity that will be presented in section 6.

5. ONTOLOGY FORMALISATION

‘Processes can be defined at different levels of abstraction (e.g., generic definitions vs. tailored definitions, descriptive vs. prescriptive vs. proscriptive) (Pfleeger, 2001)’. Various elements of a process can be defined, for example, activities, products (artefacts), and resources. SWEBOK (Abran et al., 2004) reports also that ‘detailed frameworks that structure the types of information required to define processes are described in (Madhavji, 1994)’.

There is a number of notations being used to define processes. A key difference among them is in the types of information they each define, capture and use. Common approaches that software engineer use in their daily work are presented in the SWEBOK as: data flow diagrams, Statecharts, ETVX and Actor-Dependency modeling. Looking at recent software engineering process descriptions by Prof. Dr. Dumke (Dumke et al., 2005) reveals the many artefacts that compose a typical software product. Taking the same descriptive approach as Prof. Dr. Dumke the software product maintained can le libeled SPM . This product is now maintained by a

given software maintenance process labeled SM. This software maintenance process is using a number of maintenance activities labeled ASM. These activities are carried out using the maintenance resources labeled RSM.

This expression can be written as:

SM = (ASM, RSM) =

(

{maintenanceActivities, maintenanceResources} _{∪ SP}M)

The software product maintained is initially defined as a (software) system containing a number of artefacts that are sets of programs and sets of documentations:

SPM= (MSP, RSP) =

(

artefacts, RSP

)

=

(

{programs,

documentations}, RSP

)

The two sets are divided in the following elements or components (without achieving completeness):

programs _{⊆ {sourceCode, objectCode, macro,} script, plugIn}

documentations = {userManual, referenceManual, developmentDocumentation}

and RSP describes the set of the relations over the

SPM elements. The given subsets could be

described as follows:

developmentDocumentation =

{documentationElements} ={productRequirements, productSpecification, productDesign,

implementationDescription} documentationElements ⊆ {model, chart, architecture, diagram, sizeEstimation, reviewReport,

auditReport, testCase, testScript, pseudoCode, extensionDescription, qualityReport }

productRequirements = systemRequirement _⊆ {functionalRequirements, qualityRequirements, platformRequirements}

functionalRequirements _{⊆ {businessRule, function} Map, informationSequence, control}

qualityRequirements _{⊆ {maintainability} =} {analysability, changeability, stability, testability} platformRequirements ⊆

{systemSoftwareRequirements, hardwareServerRequirements,

telecommunicationsBandwidthRequirements, peripheralDeviceRequirements}

The software maintenance activities of the ISO/IEC 14764 can also be defined formally. “The maintenance activities are classified, according to ISO/IEC 14764, into investigations, modification and retirement activities. The modification activities consist of basically two types: Correction and Improvement. The first one belongs to corrective maintenance, where mistakes are eliminated. The second one is in charge of preventing problems (preventive maintenance), implementing changes in the requirements (perfective maintenance) or changing aspects of implementation (adaptive maintenance).” (Ruiz et al. 2004, p.335). Software maintenance processes can be defined by describing its activities. In this case the non-managerial

maintenance activities of the software maintenance ontology by Ruiz et al. can be defined as:

SM = (ASM, RSM) =

(

{maintenanceActivities, maintenanceResources} _{∪ SP}M

)

where: maintenanceActivities = {investigation, modificationActivities, retirement} modificationActivities = {corrective, improvement}

improvement = {adaptive, perfective, preventive}

Accordingly, some of the examples of the relations in RSM could be derived in the following manner.

An investigation can be expressed as the requirements identified on a specific investigation request with the use of the software maintenance investigation workflow resulting in findings to answer the questions asked on the request. In this maintenance service the software product is not modified: r ) (investigation SM _{∈ RSM : SPM ×} investigationRequirements × maintenanceInvestigationWorkflow → investigationFindings

The definition of a corrective service to the maintained software can be expressed as the requirements identifying what has to be corrected (corrective requirements) with the use of the correction workflow resulting in a corrected software product still under maintenance:

r

) (corrective

SM _{∈ RSM : SPM × correctiveRequirements}

× maintenanceCorrectionWorkflow → SPM (corrected)

The definition of an adaptive maintenance to the maintained software can be expressed as the requirements that specify what has to be added (new requirements) with the use of the evolution workflow resulting in an adapted software product still under maintenance.

r( adaptiveSM ) _{∈ RSM : SPM × newrequirements ×} maintenanceEvolutionWorkflow _{→ SP}M (adapted)

The definition of a perfective maintenance to the software can be expressed as the requirements identifying the change to an existing requirements (perfective requirement) with the use of the evolution workflow. This results in an optimized software product under maintenance:

r( perfectiveSM ) _{∈ RSM : SPM × perfectiveRequirements}

× maintenanceEvolutionWorkflow → SPM (optimized)

The definition of a preventive maintenance to the software can be expressed as the requirements that do not affect a user requirement but only the implementation of the software with the use of the evolution workflow resulting in a modified software product under maintenance:

r

) ( preventive

SM _{∈ RSM : SPM× preventiveRequirements}

× maintenanceEvolutionWorkflow → SPM (modified)

The definition of a retirement of a software can be expressed as the requirements to retire a software with the use of the maintenance retirement workflow resulting in a retired software product:

r ) migration ( SA _{∈ RSA: SPM × retirementSpecifications} × maintenanceRetirementWorkflow → SPM (retired) The maintainers’ resources RSM are defined using the same approach. To address the concerns specific to the maintainer, a distinct maintenance body of knowledge and ontology needs to be defined formally. This formalisation is also useful for the development of the knowledge-based rules that support the process model.

The next section describes the navigation concepts that have been implemented in SMxpert_{. The user of}

the KBS navigates using a sequence of tasks that will lead him through a further sequence of tasks.

6. TASK ANALYSIS

According to (Van Heijst et al., 1997), the first activity in the construction of a KBS is the definition of task analysis. Task analysis begins, at a high level, with a definition of an index of terms. This index includes words commonly used in software engineering (see Figure 3). From this index, a subset of more restrictive words is

identified. This subset is a list of keywords recognized specifically in software maintenance. Each keyword is then connected to one or more maintenance concepts. A maintenance concept, in software maintenance, is a concept found in the Software Maintenance Body of Knowledge and ontology (see Figure 3). Using the software maintenance ontology, every software maintenance problem identified by Dekleva has been linked to themes (questions) which help the user of the KBS to navigate to the part of the maturity model that will propose recommendations in the form of best practices.

Expanding the 5 high-level tasks in Figure 3, we propose 15 detailed tasks (see Appendix A) which will help identify a best practice related to the

SMmm_{. The link between the maintenance concepts} and the maturity model is made in the themes concept. Themes are questions which have been developed to hop from node to node in the ontology. A close look at Appendix A reveals that the themes concept can send the user to another theme, to another maintenance concept (up arrow), or, finally, to a recommendation of the maturity model (down

arrow). In Appendix A, step 11, a number of

themes, in the form of questions, are presented to the user to guide him through the network of maintenance concepts. For every best practice, there are a number of themes (or choices) from which the user can select (also called facts) which will lead to a specific recommendation. There are also a number of sub-tasks related to the maintenance processes and the maintenance best practices. (see Appendix A). This step-by-step process corresponds to the establishment of a diagnosis on the basis of the identification of symptoms. It indicates probabilities of occurrence of a specific software maintenance problem. No symptom is sufficient by itself to confirm the existence of a specific problem. This is why we should use the word “diagnosis”. The task model is used to help “diagnose” the current maintenance practice and map it to the maintenance model.

Figure 3: High-level view of SMxpert

Appendix A shows how the KBS can help the user answer the following question: How do we accept or reject a new maintenance request?

7. TOOL ENVIRONMENT

The SMxpert _{KBS was built using Java script and}

XML, and supports the SMmm_{. The architecture,}

design and implementation details of this KBS are similar to those of the COSMIC KBS (Desharnais, 2003) which was developed as a diagnostic tool to help IT personnel in the estimation of functional size. The design of the KBS is based on using both the case-based and ruled-based approaches (Desharnais et al., 2002). The SMxpert _{KBS was}

developed by two Master’s degree students from the University of Namur, Belgium, during a research exchange program with our university (Desharnais et al., 2004). There is still a great deal of work required to populate the knowledge base for all the SMmm _{practices to allow users to obtain answers to}

all the software maintenance problems identified by Dekleva. Figure 4 shows an example of the knowledge-based system user interface layout. In this case, the user requests a recommendation in a case where the service request is very costly. A number of questions (themes) are asked by the system. According to the answers, there will be a specific recommendation which could either suggest further research or provide an opinion. There are also interfaces for both the administrator and the expert. The administrator interface manages access to SMXpert_{, while the expert interface gives the}

expert the option of adding new keywords, concepts, cases, themes and recommendations.

Figure 4: SMxpert _{user interface layout}

8. CONCLUSION AND FUTURE

WORK

Identifying the best practices in a maturity model is a difficult task, considering their number and the multiple appropriate answers associated with each of them. Our hypothesis is that a KBS could help in finding an appropriate recommendation. The next step in this research project is to populate the KBS, validate the results with experts in the domain and determine whether or not the KBS is a useful support tool for training on the content of the maturity model. It will be also necessary to improve the interface, mainly for the sake of the expert.

REFERENCES

Abran, A., Moore, J. W., Bourque, P., Dupuis, R. and

Tripp, L.,Guide for the Software Engineering

Body of Knowledge (SWEBOK), Ironman

version, IEEE Computer Society Press: Los Alamitos CA,2004; 6-1-6-15, Montréal, http://www.swebok.org [27 January 2005]. April, A., Abran, A. and Dumke, R. SMCMM Model to

Evaluate and Improve the Quality of the Software Maintenance Process: Improvements, traceability and conformity to standards,

CSMR 2004 8th European Conference on Software Maintenance and Reengineering, (2004a) Tampere (Finland)

April, A., Abran A. and Dumke, R. Assessment of

Software Maintenance Capability: A model and its Design Process, IASTED 2004, Conference

on Software Engineering (2004b), Innsbruck (Austria)

April, A., Bouman, J., Abran, A., Al-Shurougi, D. Software maintenance in an SLA: controlling the customer expectations. Proceedings 4th

European Conference on Software Measurement and ICT control (FESMA-DASMA 2001). Technologisch Instituut vzw:

Heidelberg Germany, 2001; 39–47.

Chapin, N., Hale, J.E., Khan, K.M., Ramil, J.F., Tan W-G. Types of software evolution and software maintenance, Journal of Software Maintenance

and Evolution: Research and Practice 2001; 13

(1):3–30.

CMMi (Ed.) (2002) Capability Maturity Model

Integration for Software Engineering (CMMi), Version 1.1, CMU/SEI-2002-TR-028,

ESC-TR-2002-028, Carnegie Mellon University. Dekleva, S. M. Delphi Study of Software Maintenance

Problems, International Conference on Software

Maintenance (CSM 1992),1992, IEEE Computer Society Press: Los Alamitos CA Desharnais, J.-M., Application de la mesure fonctionnelle

COSMIC-FFP: une approche cognitive,

UQAM, Montréal, 2003

Desharnais, J.-M., Application de la mesure fonctionnelle

COSMIC-FFP: une approche cognitive,

UQAM, Montréal, 2004

Desharnais, J.-M., Abran, A., Mayers, A., Buglione, L. and Bevo, V. Knowledge Modeling for the

Measurement Domain, KES 2002, IOS Press,

Crema, Italy

Desharnais, J. M., Abran, A., Mayers, A., Vilz, J. and Gruselin, F. (2004), Verification and validation

of a knowledge base system, KI, Special Issue

on Software Engineering for Knowledge-based Systems, Germany, 3.

Dias, M. G., Anquetil, N. and Oliveira, K. M. (2003),

Organizing the Knowledge Used in Software Maintenance, Journal of Universal Computer

Science, 9, 7 64-658.

Durkin, J. (1994) Expert system: Design and

Development, Prentice Hall, New York.

Dumke, R.; Schmietendorf, A.; Zuse, H.: Formal Descriptions of Software Measurement and Evaluations, Preprint: Fakultät für Informatik, University of Magdeburg, 2005.

Kitchenham, B. and et al. (1999), Towards an Ontology

of Software Maintenance, J. Softw. Maint:Res.

Parct., 11(6):365-389.

Lientz, B. and Swanson, E. (1981), Problems in

Application Software Maintenance,

Communications of the ACM, 24, 11, 763-769.

Madhavji, N.; Hoeltje, D.; Hong, W.; Bruchhaus, T.: Elicit: A method for eliciting process models, Proceedings of the third international conference on the software process, 1994.

Pfleeger, S.L.: Software Engineering—Theory and Practice. Prentice Hall, 2nd ed., 2001; 659 p. Ruiz, F.; Vizcaíno, A.; Piattini, M.; García,F.: An

Ontology for the Management of Software Maintenance Projects, International Journal of

Software Engineering and Knowledge Engineering, 14(3), 2004; 323349.

Uschold, M. and Jasper, R. (2001), An ontology for the

management of software maintenance projects,

In Industrial Knowledge Management: a micro-level approach,Bedford (UK), pp. 549-563. Van Heijst, G., Schreiber, A. T. and Wielinga, A.,Using

Explicit Ontologies in KBS Development, 2003

University of Amsterdam, Department of Social Science Informatics, Amsterdam, 1997 Vizcaíno, A., Favela, J. and Piattini, M. A multi-agent

system for knowledge management in software maintenance, KES 2003 (2003), Springer

Appendix A: Task description of the KBS using Dekleva’s first problem

NO. TASK EXAMPLE

1. Accessing the index The user enters a word that will identify a suggested keyword. As an example, the user enters: Change in Priority

2. Choosing a resulting keyword

The user will enter a keyword that will help the KBS find the most closely related KPA and roadmap concepts. The system presents the following keywords: Change Management, Change Control, Staff Rotation, Event and Service Request, Service Level Agreement. The user chooses: Event and Service Request

3. Searching for a related software maintenance concept

The KBS presents the maintenance concepts (which are related to the KPA and roadmap) to the user.

4. Giving priority to concepts

The KBS will present the concepts in order of priority to the user. A percentage is related to each concept. The expert has previously established this percentage. As an example: 1) Event, 2) Process, 3) SLA, 4) Resource, 5) Change Control and 6)

Maintenance Manager.

5. Choosing a maintenance topological concept

The user chooses one or multiple maintenance concepts, Event in our example

6. Displaying themes With Event, there are 5 themes presented to the user in the forum of questions:

A) Is there a Service Level Agreement ?

B) Are the software maintenance services/processes defined ? C) Are the services/requests planned ?

D) Are the maintenance personnel aware of agreed priorities and amenable to change?

7. Choosing the status of each theme

The user will find facts for each practice (theme). He can answer yes or no to any of the themes.

8. Rating the status (facts) An algorithm based on Bayesian Theory (Uschold and Jasper, 2001) is used to

calculate the rate (MYCIN approach). The algorithm rates the facts chosen. 9. Displaying the results The resulting percentage relating to the best request management is shown to the

user.

10. Assessing the results The formula is based on Bayesian Theory, as explained by (Durkin, 1994). Case 1 – CF(CP) = CF(Theme1) = q_choice_perc*P_Q_perc Case 2 – CF(CP) = CF(Theme1) *CF(Theme2)

Case 3 – CF1(Theme) = CFcombine[CF(Theme1, CF(Theme2)]

CF(CP) = CFcombine[CF1(Theme), CF(Theme3)]

Etc. 11. Recommendation/explan

ation

no Æ Service Level Agreement

A yes Æ B yes Æ C yes Æ D Æ Improvement

no Æ Process

no Æ Maintenance Training

no Æ Maintenance Planning

no Æ Service Level Agreement

A yes Æ B yes Æ C yes Æ D Æ Improvement

no Æ Process

no Æ Maintenance Training

no Æ Maintenance Planning

The KBS will recommend the following solution (simplified for this paper): 12. Displaying other best

practices

Another part of the recommendation will show a different option, like: route request to account manager, interrupt work and insert in list of work, insert minor

enhancement in list of work. 13. Displaying an

explanation

There is also the possibility of an explanation. In our case, the explanation takes up one page and could not be presented here due to lack of space (April et al., 2004b) 14. Acceptability Depending on the case that the user has to solve, the recommendation/explanation will be accepted or rejected. In our case, the user accepted the recommendation because it was not necessary to refer the change request to another group based on the criteria.

15. Choosing best practices (new)

The process could start again. In this example, the user decided to stop because he considered he had enough information about the case. In a more complex situation, more choices could be necessary.