A fomalism of ontology to suppot a softwae maintenance knowledge-based system Alain Apil 1, Jean-Mac Deshanais 1, and Reine Dumke 2 1 École de Technologie Supéieue, 1100 Note-Dame West, Monteal, Canada email: alain.apil@etsmtl.ca, Jean-Mac.Deshanais@etsmtl.ca 2 Depatment of Infomatik, Otto-von-Gueicke Univestity of Magdebug, Gemany email: dumke@ivs.cs.uni-magdebug.de Keywods: Abstact: expet system, decision suppot, softwae maintenance matuity model, fomal definition of pocess model. Maintaining and suppoting the softwae of an oganization is not an easy task, and softwae maintaines do not cuently have access to tools to evaluate stategies fo impoving the specific activities of softwae maintenance. This aticle pesents a knowledge-based system which helps in locating best pactices in a softwae maintenance capability matuity model (S 3m ). The contibutions of this pape ae: 1) To fomalise the softwae maintenance ontology, 2) to instument the matuity model with a suppot tool to aid softwae maintenance pactitiones in locating specific best pactices; and 3) to descibe the knowledge-based appoach and system oveview used by the eseach team. 1. INTRODUCTION Knowledge tansfe of a lage numbe of best pactices, descibed in a matuity model, has poved difficult (Aban et al., 2004). This is especially tue duing the taining stage fo an assesso o a new paticipant in a pocess impovement activity. It is also challenging to quickly efe to, o access, a specific pactice, o subset of pactices, when tying to answe questions duing o afte a matuity evaluation. It would be beneficial to have a knowledge-based system (KBS) to help access this complex stuctue and its lage amount of infomation. A potential solution to this poblem is to develop a knowledgebased system that the undelying pocess model used by the matuity model. This pape pesents the poposed modeling of a softwae maintenance KBS based on the van Heijst methodology (Van Heijst et al., 1997), which consists of constucting a task model, building on a fomalism of the domain ontology (Uschold and Jaspe, 2001), mapping the ontology onto the knowledge oles in the task model and instantiating the application ontology with this specific domain knowledge. Accoding to van Heijst, thee ae at least five diffeent types of knowledge to be taken into account when constucting such a system: tasks, poblem-solving methods, infeences, the ontology and the domain knowledge 1. Fo van Heijst, domain knowledge efes to a collection of statements about the domain (Van Heijst et al., 1997). The pocess domain of this specific softwae maintenance matuity model is pesented in section 2. Examples of statements ae pesented in section 3. At a high level, the ontology efes to a pat of the softwae maintenance ontology poposed by (Kitchenham et al., 1999) pesented in section 4. A fomalisation of the softwae maintenance ontology follows in section 5. The infeences, poblem-solving methods and tasks ae descibed at length in section 6 showing the task analysis fo the poposed knowledge-based system. The tool envionment (showing a use inteface 1 van Heijst uses the diffeent types of knowledge in a moe geneic way than we do in this document, and these have been adapted fo us by Deshanais, J.- M.,Application de la mesue fonctionnelle COSMIC-FFP: une appoche cognitive, UQAM,2004 Montéal
layout of the knowledge-based system) followed by a conclusion, as well as futue wok, ae pesented in sections 7 and 8. 2. THE S 3m PROCESS MODEL The softwae maintenance matuity model (S 3m ) egoups softwae maintenance pocesses in thee classes (Figue 1), the main idea is to povide a epesentation simila to that used by the ISO/IEC 12207 standad but with a focus on softwae maintenance pocesses and activities: Pimay pocesses (softwae maintenance opeational pocesses); Suppot pocesses (suppoting the pimay pocesses); and Oganizational pocesses offeed by the IS/IT o othe depatments of the oganization (e.g., taining, finance, human esouces, puchasing, etc.). Softwae Evolution Engineeing This geneic softwae maintenance pocess model helps explain and epesent the vaious key softwae maintenance pocesses. The key opeational pocesses (also called pimay pocesses) that a softwae maintenance oganization uses ae initiated at the stat of a softwae development poject, beginning with the Pedelivey and Tansition pocess. These pimay pocesses ae not limited, as is the case with some standads, to the moment when developes hand ove the system to maintaines, but athe ensues that the softwae poject is contolled and that a stuctued and coodinated appoach is used to tansfe the softwae to the maintaine. In this pocess, the maintaine will focus on the maintainability of this new softwae, and it means that a pocess is implemented to follow the develope duing the system development life cycle. Pimay Pocesses Developes Pedelivey Tansition and Tansition Uses Issue Event and and Request Sevice Management Request Management Opeational Suppot Sevice Coective Coections Sevice Evolutions Evolutive Sevices Poduction Changes Suveillance Monitoing Softwae Rejuvenation Poduction Suveillance Migation Retiement Infastuctue and Opeations Ops. Suppot Pocesses Documentation Maintenance Planning Configuation and Maintenance vesion Management Taining Pocess and Poduct Quality Assuance Veification - Validation Reviews and Audits Causal Analysis and Poblem Management Resolution Oganizational Oganizat. Pocesses Management Measuement Maintenance and Measuement Analysis Planning of contol Maintenance Impovement Pocess Innovation Definition, and Assessment, Deployment Impovement HR and Taining Puchasing, Puchasing Supplie and Human ageement Resouces and SLA Figue 1. A classification of the softwae maintaine s key pocesses. Once the softwae has become the esponsibility of the maintaine, the Event and Sevice Request Management pocess handles all the daily issues, Poblem Repots, Modification Requests, and suppot equests. These ae the daily sevices that must be managed efficiently. The fist step in this pocess is to assess whethe a equest is to be addessed, eouted, o ejected (on the basis of the SLA and the natue of the equest and its size) (Apil et al., 2001). Accepted equests ae
documented and pioitized. They ae then assigned, to one of the following types of pocesses: Opeational Suppot pocess (equests that do not necessitate any modification to softwae and that ae also efeenced as suppot inteface types of maintenance (Chapin et al., 2001)); Coections pocess; o Evolutions pocess (which includes adaptive, pefective and ecently poposed activity types like enhancive, eductive (Chapin et al., 2001)). They ae then pocessed. Note that cetain sevice equests do not lead to any modification of the softwae. In the model, these ae efeed to as opeational suppot activities. In S 3m opeational suppot activities consist of: Poduction of a one time extact of infomation fom existing systems; Povision of technical infomation and counselling to developes and opeations; and Helping customes to bette undestand the softwae, a tansaction, its data, o its documentation. The next pimay pocesses concen the Changes Monitoing, ensuing that the opeational envionment has not been degaded by the pomotion of a change in poduction. Maintaines must always monito the behavio of the opeational system and its envionments fo signs of degadation, especially afte a change. They will quickly wan othe suppot goups (opeatos, technical suppot, scheduling, netwoks, and desktop suppot) when something unusual happens and judge whethe o not an instance of sevice degadation has occued that needs to be investigated. The last pimay pocess addesses Rejuvenation activities to impove maintainability, Migation activities to move a system to anothe envionment and Retiement activities when a system is decommissioned. As in ISO/IEC12207 a pocess which is used, when equied, by an opeational pocess is said to be an opeational suppot pocess. In most IS/IT oganizations today the developes, maintaines and opeations may shae these pocesses. In this classification, we include: a) documentation pocesses; b) softwae configuation and vesion management pocesses and associated tools use; c) pocess and poduct quality assuance pocesses; d) veification and validation pocesses; e) eviews and audits pocesses; and, finally, f) causal analysis and poblem esolution pocesses, that ae often shaed with opeations. Some poblems e-occu o disappea befoe we can identify them. The causal analysis pocess identifies long standing issues, thei causes and need of moe dedication fom the pesonnel. These ae all key pocesses equied to suppot softwae maintenance opeational pocess activities. Oganizational pocesses ae typically offeed by othe depatments in the oganization (e.g., the many maintenance planning pespectives, pocess elated activities, measuement, innovation, taining, and human esouces). While it is impotant to measue and assess these pocesses, it is moe impotant fo the maintaine to define and optimize the opeational pocesses fist. These ae followed by the opeational suppot pocesses and then the oganizational pocesses. The S 3m was designed as a custome-focused benchmak fo eithe: Auditing the softwae maintenance capability of a sevice supplie o outsouce; o Suppoting the pocess impovement activities of softwae maintenance oganizations. 3. S 3m AND KNOWLEDGE STATEMENTS Softwae maintaines expeience a numbe of poblems. These have been documented and an attempt made to ank them in ode of impotance. One of the fist epoted investigations was conducted by Lientz and Swanson (Lientz and Swanson, 1981). They identified six poblems elated to uses of the applications, to manageial constaints and to the quality of softwae documentation. Othe suveys have found that a lage pecentage of the softwae maintenance poblems epoted ae elated to the softwae poduct itself. This suvey identified complex and old souce code which was badly documented and stuctued in a complex way. Moe ecent suveys
conducted among attendees at successive softwae maintenance confeences (Dekleva, 1992) anked peceived poblems in the following ode of impotance (see Table 1). These ae also examples of knowledge statements about the domain of softwae maintenance. Key to helping softwae maintaines would be to povide them with ways of esolving thei poblems by leading them to documented best pactices. Table 1: Top maintenance poblems (Dekleva, 1992) Rank Maintenance poblem 1 Managing fast-changing pioities 2 Inadequate testing techniques 3 Difficulty in measuing pefomance 4 Missing o incomplete softwae documentation 5 Adapting to apid changes in use oganizations 6 A lage numbe of use equests in waiting 7 Difficulty in measuing/demonstating the maintenance team s contibution 8 Low moale due to lack of ecognition 9 Not many pofessionals in the field, especially expeienced ones 10 Little methodology, few standads, pocedues o tools specific to maintenance 11 Souce code complex and unstuctued 12 Integation, ovelap and incompatibility of systems 13 Little taining available to pesonnel 14 No stategic plans fo maintenance 15 Difficulty in meeting use expectations 16 Lack of undestanding and suppot fom IT manages 17 Maintenance softwae unning on obsolete systems and technologies 18 Little will fo eengineeing applications 19 Loss of expetise when employees leave Thee is a gowing numbe of souces whee softwae maintaines can look fo best pactices, a majo challenge being to encouage these souces to use the same teminology, pocess models and intenational standads. The pactices used by maintaines need to show them how to meet thei daily sevice goals. While these pactices ae most often descibed within thei coesponding opeational and suppot pocesses, and consist of numeous pocedues, a vey lage numbe of poblem-solving pactices could be pesented in a KBS which would answe thei many questions about those poblems. Examples ae pesented in section 5. When using the softwae maintenance ontology in the KBS, it was necessay to conside the stuctue of the matuity model elationship between the many pocess domains, oadmaps and pactices. This poblem is addessed next.
Method Pocess Human Resouces Client oganisation oganization Technique Pocedue Resouces Client Human Resouces Paadigm is used in uses Maintenance Activity Maint. Human Resouces Uses pefoms Modification Activity Maint. Enginee Maint. Manage negotiates_with Custome Event Management tains pefoms tains infoms appoves Management activity Maintenance Taining constains SLA Maintenance Management Change Contol Maintenance Planning Figue 2: Pat of the softwae 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) fo the initial tial of this eseach poject. Figue 2 descibes the diffeent maintenance concepts consideed suounding a softwae maintenance activity. Softwae maintenance is highly event-diven, which means that some maintenance activities ae unscheduled and can inteupt ongoing wok. This subset of the ontology epesents many, but not all, the concepts involved in esponding to the questions elated to the fist poblem identified by Dekleva: Managing fastchanging pioities. Maintaines agee that this is the most impotant poblem they face. How can they handle the fast-changing pioities of the custome? Solutions to this poblem ae likely to be found by using many paths though the maintenance concepts of the ontology. Navigation though these concepts should lead to associated concepts which ae conceptually linked and likely to contibute to a solution, like the need fo bette event management, change contol, maintenance planning, Sevice Level Ageements, maintenance manage negotiation, taining, pocedues, and so foth. Many moe concepts must be involved to contibute to all aspects of the solution, but ou pupose is to show the utility of a KBS in the softwae maintenance domain, and it theefoe stats with a constained numbe of concepts. Matuity models typically include the detailed best pactices that could be of help in solving this type of poblem. The main issue is that the best pactice locations and thei inteelationships ae hidden in the layeed achitectue of the matuity model, specifically in its pocess domains, KPAs and oadmaps. It is theefoe necessay to find a way to link this layeed achitectue with the maintenance concepts of the ontology and poceed to analyze the tasks equied to build a KBS to suppot the maintaines in thei quest fo solutions. The next section pesents a fomalisation of softwae maintenance ontology using a epesentation based on set theoy. The fomal ules ae used, as pat of the knowledge based epesentation, to bette define the maintenance domain concepts of the ontology fo the task analysis activity that will be pesented in section 6.
5. ONTOLOGY FORMALISATION Pocesses can be defined at diffeent levels of abstaction (e.g., geneic definitions vs. tailoed definitions, desciptive vs. pesciptive vs. posciptive) (Pfleege, 2001). Vaious elements of a pocess can be defined, fo example, activities, poducts (atefacts), and esouces. SWEBOK (Aban et al., 2004) epots also that detailed famewoks that stuctue the types of infomation equied to define pocesses ae descibed in (Madhavji, 1994). Thee is a numbe of notations being used to define pocesses. A key diffeence among them is in the types of infomation they each define, captue and use. Common appoaches that softwae enginee use in thei daily wok ae pesented in the SWEBOK as: data flow diagams, Statechats, ETVX and Acto-Dependency modeling. Looking at ecent softwae engineeing pocess desciptions by Pof. D. Dumke (Dumke et al., 2005) eveals the many atefacts that compose a typical softwae poduct. Taking the same desciptive appoach as Pof. D. Dumke the softwae poduct maintained can le libeled SP M. This poduct is now maintained by a given softwae maintenance pocess labeled SM. This softwae maintenance pocess is using a numbe of maintenance activities labeled A SM. These activities ae caied out using the maintenance esouces labeled R SM. This expession can be witten as: SM = (A SM, R SM ) = ({maintenanceactivities, maintenanceresouces} SP M ) The softwae poduct maintained is initially defined as a (softwae) system containing a numbe of atefacts that ae sets of pogams and sets of documentations: SP M = (M SP, R SP ) =(atefacts, R SP ) = ({pogams, documentations}, R SP ) The two sets ae divided in the following elements o components (without achieving completeness): pogams {soucecode, objectcode, maco, scipt, plugin} documentations = {usemanual, efeencemanual, developmentdocumentation} and R SP descibes the set of the elations ove the SP M elements. The given subsets could be descibed as follows: developmentdocumentation = {documentationelements} ={poductrequiements, poductspecification, poductdesign, implementationdesciption} documentationelements {model, chat, achitectue, diagam, sizeestimation, eviewrepot, auditrepot, testcase, testscipt, pseudocode, extensiondesciption, qualityrepot } poductrequiements = systemrequiement {functionalrequiements, qualityrequiements, platfomrequiements} functionalrequiements {businessrule, function Map, infomationsequence, contol} qualityrequiements {maintainability} = {analysability, changeability, stability, testability} platfomrequiements {systemsoftwaerequiements, hadwaeseverequiements, telecommunicationsbandwidthrequiements, peiphealdevicerequiements} The softwae maintenance activities of the ISO/IEC 14764 can also be defined fomally. The maintenance activities ae classified, accoding to ISO/IEC 14764, into investigations, modification and etiement activities. The modification activities consist of basically two types: Coection and Impovement. The fist one belongs to coective maintenance, whee mistakes ae eliminated. The second one is in chage of peventing poblems (peventive maintenance), implementing changes in the equiements (pefective maintenance) o changing aspects of implementation (adaptive maintenance). (Ruiz et al. 2004, p.335). Softwae maintenance pocesses can be defined by descibing its activities. In this case the non-manageial
maintenance activities of the softwae maintenance ontology by Ruiz et al. can be defined as: SM = (A SM, R SM ) = ({maintenanceactivities, maintenanceresouces} SP M ) whee: maintenanceactivities = {investigation, modificationactivities, etiement} modificationactivities = {coective, impovement} impovement = {adaptive, pefective, peventive} Accodingly, some of the examples of the elations in R SM could be deived in the following manne. An investigation can be expessed as the equiements identified on a specific investigation equest with the use of the softwae maintenance investigation wokflow esulting in findings to answe the questions asked on the equest. In this maintenance sevice the softwae poduct is not modified: ( investigation) SM R SM : SP M investigationrequiements maintenanceinvestigationwokflow investigationfindings The definition of a coective sevice to the maintained softwae can be expessed as the equiements identifying what has to be coected (coective equiements) with the use of the coection wokflow esulting in a coected softwae poduct still unde maintenance: (coective) SM R SM : SP M coectiverequiements (coected) maintenancecoectionwokflow SP M The definition of an adaptive maintenance to the maintained softwae can be expessed as the equiements that specify what has to be added (new equiements) with the use of the evolution wokflow esulting in an adapted softwae poduct still unde maintenance. (adaptive) SM R SM : SP M newequiements (adapted) maintenanceevolutionwokflow SP M The definition of a pefective maintenance to the softwae can be expessed as the equiements identifying the change to an existing equiements (pefective equiement) with the use of the evolution wokflow. This esults in an optimized softwae poduct unde maintenance: ( pefective) SM R SM : SP M pefectiverequiements (optimized) maintenanceevolutionwokflow SP M The definition of a peventive maintenance to the softwae can be expessed as the equiements that do not affect a use equiement but only the implementation of the softwae with the use of the evolution wokflow esulting in a modified softwae poduct unde maintenance: ( peventive) SM R SM : SP M peventiverequiements (modified) maintenanceevolutionwokflow SP M The definition of a etiement of a softwae can be expessed as the equiements to etie a softwae with the use of the maintenance etiement wokflow esulting in a etied softwae poduct: ( migation ) SA R SA : SP M etiementspecifications maintenanceretiementwokflow SP (etied) M The maintaines esouces R SM ae defined using the same appoach. To addess the concens specific to the maintaine, a distinct maintenance body of knowledge and ontology needs to be defined fomally. This fomalisation is also useful fo the development of the knowledge-based ules that suppot the pocess model. The next section descibes the navigation concepts that have been implemented in SM xpet. The use of the KBS navigates using a sequence of tasks that will lead him though a futhe sequence of tasks. 6. TASK ANALYSIS Accoding to (Van Heijst et al., 1997), the fist activity in the constuction of a KBS is the definition of task analysis. Task analysis begins, at a high level, with a definition of an index of tems. This index includes wods commonly used in softwae engineeing (see Figue 3). Fom this index, a subset of moe estictive wods is
identified. This subset is a list of keywods ecognized specifically in softwae maintenance. Each keywod is then connected to one o moe maintenance concepts. A maintenance concept, in softwae maintenance, is a concept found in the Softwae Maintenance Body of Knowledge and ontology (see Figue 3). Using the softwae maintenance ontology, evey softwae maintenance poblem identified by Dekleva has been linked to themes (questions) which help the use of the KBS to navigate to the pat of the matuity model that will popose ecommendations in the fom of best pactices. Expanding the 5 high-level tasks in Figue 3, we popose 15 detailed tasks (see Appendix A) which will help identify a best pactice elated to the SM mm. The link between the maintenance concepts and the matuity model is made in the themes concept. Themes ae questions which have been developed to hop fom node to node in the ontology. A close look at Appendix A eveals that the themes concept can send the use to anothe theme, to anothe maintenance concept (up aow), o, finally, to a ecommendation of the matuity model (down aow). In Appendix A, step 11, a numbe of themes, in the fom of questions, ae pesented to the use to guide him though the netwok of maintenance concepts. Fo evey best pactice, thee ae a numbe of themes (o choices) fom which the use can select (also called facts) which will lead to a specific ecommendation. Thee ae also a numbe of sub-tasks elated to the maintenance pocesses and the maintenance best pactices. (see Appendix A). This step-by-step pocess coesponds to the establishment of a diagnosis on the basis of the identification of symptoms. It indicates pobabilities of occuence of a specific softwae maintenance poblem. No symptom is sufficient by itself to confim the existence of a specific poblem. This is why we should use the wod diagnosis. The task model is used to help diagnose the cuent maintenance pactice and map it to the maintenance model. Figue 3: High-level view of SM xpet Appendix A shows how the KBS can help the use answe the following question: How do we accept o eject a new maintenance equest? 7. TOOL ENVIRONMENT The SM xpet KBS was built using Java scipt and XML, and suppots the SM mm. The achitectue, design and implementation details of this KBS ae simila to those of the COSMIC KBS (Deshanais, 2003) which was developed as a diagnostic tool to help IT pesonnel in the estimation of functional size. The design of the KBS is based on using both the case-based and uled-based appoaches (Deshanais et al., 2002). The SM xpet KBS was developed by two Maste s degee students fom the Univesity of Namu, Belgium, duing a eseach exchange pogam with ou univesity (Deshanais et al., 2004). Thee is still a geat deal of wok equied to populate the knowledge base fo all the SM mm pactices to allow uses to obtain answes to all the softwae maintenance poblems identified by Dekleva. Figue 4 shows an example of the knowledge-based system use inteface layout. In this case, the use equests a ecommendation in a case whee the sevice equest is vey costly. A numbe of questions (themes) ae asked by the system. Accoding to the answes, thee will be a specific ecommendation which could eithe suggest futhe eseach o povide an opinion. Thee ae also intefaces fo both the administato and the expet. The administato inteface manages access to SM Xpet, while the expet inteface gives the
expet the option of adding new keywods, concepts, cases, themes and ecommendations. Figue 4: SM xpet use inteface layout 8. CONCLUSION AND FUTURE WORK Identifying the best pactices in a matuity model is a difficult task, consideing thei numbe and the multiple appopiate answes associated with each of them. Ou hypothesis is that a KBS could help in finding an appopiate ecommendation. The next step in this eseach poject is to populate the KBS, validate the esults with expets in the domain and detemine whethe o not the KBS is a useful suppot tool fo taining on the content of the matuity model. It will be also necessay to impove the inteface, mainly fo the sake of the expet. REFERENCES Aban, A., Mooe, J. W., Bouque, P., Dupuis, R. and Tipp, L.,Guide fo the Softwae Engineeing Body of Knowledge (SWEBOK), Ionman vesion, IEEE Compute Society Pess: Los Alamitos CA,2004; 6-1-6-15, Montéal, http://www.swebok.og [27 Januay 2005]. Apil, A., Aban, A. and Dumke, R. SMCMM Model to Evaluate and Impove the Quality of the Softwae Maintenance Pocess: Impovements, taceability and confomity to standads, CSMR 2004 8th Euopean Confeence on Softwae Maintenance and Reengineeing, (2004a) Tampee (Finland) Apil, A., Aban A. and Dumke, R. Assessment of Softwae Maintenance Capability: A model and its Design Pocess, IASTED 2004, Confeence on Softwae Engineeing (2004b), Innsbuck (Austia) Apil, A., Bouman, J., Aban, A., Al-Shuougi, D. Softwae maintenance in an SLA: contolling the custome expectations. Poceedings 4th Euopean Confeence on Softwae Measuement and ICT contol (FESMA- DASMA 2001). Technologisch Instituut vzw: Heidelbeg Gemany, 2001; 39 47. Chapin, N., Hale, J.E., Khan, K.M., Ramil, J.F., Tan W- G. Types of softwae evolution and softwae maintenance, Jounal of Softwae Maintenance and Evolution: Reseach and Pactice 2001; 13 (1):3 30. CMMi (Ed.) (2002) Capability Matuity Model Integation fo Softwae Engineeing (CMMi), Vesion 1.1, CMU/SEI-2002-TR-028, ESC-TR- 2002-028, Canegie Mellon Univesity. Dekleva, S. M. Delphi Study of Softwae Maintenance Poblems, Intenational Confeence on Softwae Maintenance (CSM 1992),1992, IEEE Compute Society Pess: Los Alamitos CA Deshanais, J.-M., Application de la mesue fonctionnelle COSMIC-FFP: une appoche cognitive, UQAM, Montéal, 2003 Deshanais, J.-M., Application de la mesue fonctionnelle COSMIC-FFP: une appoche cognitive, UQAM, Montéal, 2004 Deshanais, J.-M., Aban, A., Mayes, A., Buglione, L. and Bevo, V. Knowledge Modeling fo the Design of a KBS in the Functional Size
Measuement Domain, KES 2002, IOS Pess, Cema, Italy Deshanais, J. M., Aban, A., Mayes, A., Vilz, J. and Guselin, F. (2004), Veification and validation of a knowledge base system, KI, Special Issue on Softwae Engineeing fo Knowledge-based Systems, Gemany, 3. Dias, M. G., Anquetil, N. and Oliveia, K. M. (2003), Oganizing the Knowledge Used in Softwae Maintenance, Jounal of Univesal Compute Science, 9, 7 64-658. Dukin, J. (1994) Expet system: Design and Development, Pentice Hall, New Yok. Dumke, R.; Schmietendof, A.; Zuse, H.: Fomal Desciptions of Softwae Measuement and Evaluations, Pepint: Fakultät fü Infomatik, Univesity of Magdebug, 2005. Kitchenham, B. and et al. (1999), Towads an Ontology of Softwae Maintenance, J. Softw. Maint:Res. Pact., 11(6):365-389. Lientz, B. and Swanson, E. (1981), Poblems in Application Softwae Maintenance, Communications of the ACM, 24, 11, 763-769. Madhavji, N.; Hoeltje, D.; Hong, W.; Buchhaus, T.: Elicit: A method fo eliciting pocess models, Poceedings of the thid intenational confeence on the softwae pocess, 1994. Pfleege, S.L.: Softwae Engineeing Theoy and Pactice. Pentice Hall, 2nd ed., 2001; 659 p. Ruiz, F.; Vizcaíno, A.; Piattini, M.; Gacía,F.: An Ontology fo the Management of Softwae Maintenance Pojects, Intenational Jounal of Softwae Engineeing and Knowledge Engineeing, 14(3), 2004; 323 349. Uschold, M. and Jaspe, R. (2001), An ontology fo the management of softwae maintenance pojects, In Industial Knowledge Management: a micolevel appoach,bedfod (UK), pp. 549-563. Van Heijst, G., Scheibe, A. T. and Wielinga, A.,Using Explicit Ontologies in KBS Development, 2003 Univesity of Amstedam, Depatment of Social Science Infomatics, Amstedam, 1997 Vizcaíno, A., Favela, J. and Piattini, M. A multi-agent system fo knowledge management in softwae maintenance, KES 2003 (2003), Spinge Velag, Oxfod, UK.
Appendix A: Task desciption of the KBS using Dekleva s fist poblem NO. TASK EXAMPLE 1. Accessing the index The use entes a wod that will identify a suggested keywod. As an example, the use entes: Change in Pioity 2. Choosing a esulting keywod 3. Seaching fo a elated softwae maintenance concept 4. Giving pioity to concepts The use will ente a keywod that will help the KBS find the most closely elated KPA and oadmap concepts. The system pesents the following keywods: Change Management, Change Contol, Staff Rotation, Event and Sevice Request, Sevice Level Ageement. The use chooses: Event and Sevice Request The KBS pesents the maintenance concepts (which ae elated to the KPA and oadmap) to the use. The KBS will pesent the concepts in ode of pioity to the use. A pecentage is elated to each concept. The expet has peviously established this pecentage. As an example: 1) Event, 2) Pocess, 3) SLA, 4) Resouce, 5) Change Contol and 6) Maintenance Manage. The use chooses one o multiple maintenance concepts, Event in ou example 5. Choosing a maintenance topological concept 6. Displaying themes With Event, thee ae 5 themes pesented to the use in the foum of questions: A) Is thee a Sevice Level Ageement? B) Ae the softwae maintenance sevices/pocesses defined? C) Ae the sevices/equests planned? D) Ae the maintenance pesonnel awae of ageed pioities and amenable to change? 7. Choosing the status of each theme The use will find facts fo each pactice (theme). He can answe yes o no to any of the themes. 8. Rating the status (facts) An algoithm based on Bayesian Theoy (Uschold and Jaspe, 2001) is used to calculate the ate (MYCIN appoach). The algoithm ates the facts chosen. 9. Displaying the esults The esulting pecentage elating to the best equest management is shown to the use. 10. Assessing the esults The fomula is based on Bayesian Theoy, as explained by (Dukin, 1994). Case 1 CF(CP) = CF(Theme1) = q_choice_pec*p_q_pec 11. Recommendation/explan ation Case 2 Case 3 Etc. CF(CP) = CF(Theme1) *CF(Theme2) CF1(Theme) = CFcombine[CF(Theme1, CF(Theme2)] CF(CP) = CFcombine[CF1(Theme), CF(Theme3)] A yes B yes C yes D Impovement no Pocess no Sevice Level Ageement no Maintenance Taining no Maintenance Planning The KBS will ecommend the following solution (simplified fo this pape): 12. Displaying othe best pactices Anothe pat of the ecommendation will show a diffeent option, like: oute equest to account manage, inteupt wok and inset in list of wok, inset mino enhancement in list of wok. 13. Displaying an explanation Thee is also the possibility of an explanation. In ou case, the explanation takes up one page and could not be pesented hee due to lack of space (Apil et al., 2004b) 14. Acceptability Depending on the case that the use has to solve, the ecommendation/explanation will be accepted o ejected. In ou case, the use accepted the ecommendation because it was not necessay to efe the change equest to anothe goup based on the citeia. 15. Choosing best pactices (new) The pocess could stat again. In this example, the use decided to stop because he consideed he had enough infomation about the case. In a moe complex situation, moe choices could be necessay.