intellipse: towards knowledge-based tools for the design of commercial data processing systems

systems

Intellipse: towards knowledge- based tools for the design of commercial data processing

systems by JON BADER, DAVID HANNAFORD*, ALASTAIR COCHRAN and

JOHN EDWARDS

Abstract." This paper discusses Intellipse, a knowledge-based tool [br supporting the design and implementation ~)l c commercial data processing (DP) systems. Intellipse is based on the BIS Applied Systems Ltd structured systems design methodology. Also eonsidered are several issues concerned with the introduction ~?[knowledge-based tools into the commercial DP environment. The work discussed in this paper is Junded under the UK governments's [ive-year Alve)' programme.lbr research into advanced in[ormation technology. ( Pr~)/ect No. SE057.) It is a three-year collaborative project, begun in October 1985, involving Aston University, BIS Appl&d Systems Lid and the British Steel Corporation (Strip Products Group).

Keywords: knowh, dge-based systems, e.wert £vstems, s~[?ware engineering, data processing, structured systems development, PROLOG, lntellipse.

T here are several features of current commerical DP systems development which suggest that knowledge-based systems can play an important

role.

S y s t e m fa i lu re

The problems of building medium to large DP systems on time, within budget and meeting end-user requirements are well documented. A frequently quoted statistic, for example, is that, typically, 50-80 % of the budget for a systems development project is spent maintaining the system after it has been delivered to the user 1"2. However,

Aston University, Aston Triangle, Birmingham B4 7ET, UK. *BIS Applied Systems Ltd, Ringway House, 45 Bull St, Colmore Circus, Birmingham B4 6AF, UK.

despite its reputation for failure, the DP industry can point to a number of highly successful systems in wide- spread everyday use. The international airline booking system or the many plastic card operations are two highly visible examples. The existence of high quality DP systems is an important observation since any attempt to build knowledge-based tools for supporting DP systems design must be predicated on the assumption that techniques exist which can adequately cope with the problems of DP systems design and that people exist who know how to apply those tecniques successfully.

End-user invo lvement

A major problem in commercial DP is the large backlog of development work which exists in many DP departments. This means that the DP industry is perpetually looking for ways to improve analyst and programmer productiv- ity. This fact, together with the desire of DP managers to deliver systems which satisfy end-user expectations, has led to the idea that end-users should play a more active role in information systems development 3'4. It follows that if end-users are to play this more active role, intelligent development tools will be required which do not depend for their success on a high level of design expertise on the part of the tool-user.

M o v e m e n t ~?] D P personne l

Another long-standing problem in the computer industry which a knowledge-based approach can address is the rapid movement of DP personnel between companies. When a person leaves the DP department of one company to join another he/she takes with him/her not only his

vol 29 no 8 october 1 9 8 7 0950-5849/87/080431-09503.00 :C) 1987 Buttcrworth & Co (Publishers) Ltd. 431

technical skills but, more importantly, his accumulated knowledge of the company's development environment and computer-based information systems. Knowledge- based tools able to retain this knowledge within the company so that it could be used, for example, to speed up the induction and training of new personnel would be invaluable.

Commonality between systems

Many information systems in use in diverse organizations possess a high degree of commonality, especially in relation to their functional specification. A knowledge- based design tool could exploit this commonality by providing the designer with a knowledge base containing generically classified design templates. The template knowledge base could be used as a basis for a new design built up using proven design elements from systems already built and tested.

Current research

The Alvey Software Engineering Directorate noted in a report published in 1984 that:

IKBS offers a somewhat different paradigm for system developm.ent... However, the IKBS paradigm is immature and unproven. It may not deliver as much as it promises when exposed to the commercial and technical constraints of the market place 5.

Details of research into the application of knowledge- based techniques to software engineering have recently begun appearing in the literature 6- t9. The particular issues which are addressed in the authors ' work are summarized as follows. First, the need for knowledge- based tools which can support a particular structured development methodology. Second, the need to integrate knowledge-based tools with current system development tools and existing DP systems and languages. Third, the need to integrate knowledge-based tools with conventional software packages and fourth the need for knowledge-based support environments to have the usa- bility, robustness and reliability demanded by an industrial or a commercial environment.

Domain maturity

An important issue that must be considered when assess- ing the potential of knowledge-based systems in a particular domain is whether the application area is mature enough to be the basis for a knowledge-based system. Many of the application areas covered in the literature are, historically, a product of many hundreds of years of development, in which highly sophisticated systems of training, engineering and heuristic knowledge have been built up. Information systems engineering when com- pared with more mature areas such as the legal, medical

or geological domains, has had a very short evolutionary span - measuring, at most, forty years. As a result, it has not yet evolved a rigorous system of heuristics or es- tablished a standard engineering methodology. Reinforc- ing this domain immaturity is the lack of a widely accepted formal, scientific foundation to the software development process. Another factor leading to the instability of methods and standards in software engineering is the rapidly changing nature of computer technology. Other authors have noted this immaturity in the software engineering process 2°'2~.

While recognizing the problem of domain immaturity the authors have sought to overcome it by basing their tools on a structured design methodology which has a sound theoretical basis and has been used commercially for a relatively long period of time.

Structured systems design methodology

The BIS structured systems design (SSD) method is a formalized development method based on the structured systems approach to software engineering formulated during the 1970s 22- 24. It is one of a number of development methodologies available to the UK software industry and has several major commercial and government users. SSD is part of the BIS Modus standards and methodologies which cover the whole of the DP development life cycle.

The philosophy behind the use of a structured approach to D P systems development is that effort spent in ensuring that a good logical and physical design is produced is repaid by improved system performance, fewer errors and easier system maintenance. However, there are a number of common problems associated with the implementation of any of the various forms of structured design (SD) methods, the more important of which are described below.

First, the introduction of SD methods can slow down, to some extent, the design phase of the software life cycle. Commercial pressures on DP deparmtments to deliver systems quickly often lead to the abandonment of SD in favour of ad hoc approaches. The long-term benefits of SD, of reliability and maintainability, are lost in order to gain the short-term advantage of early delivery.

Second, SD methods require the production of in- creased volumes of support documentation which can be difficult and tedious to manage effectively, but which are central to the SD philosophy.

Third, inexperienced SD users find that the step from a SD training course or manual to the application of SD to a 'real ' project in their own DP environment may require experienced support and if this is not available then the designer may revert to inferior, ad hoc methods.

432 information and software technology

systems Fourth, maintaining the standards and disciplined

approach of a SD methodology is very much dependent on the expertise of the designer. Current support tools rely almost entirely on this expertise and on the designer's knowledge of the development methodology. The tools lack any 'intelligence' and essentially record information, help with word and diagram processing and carry out simple consistency checking. The shortage of expert support for the inexperienced designers using SD methods often leads to a reduction in the standard of results obtained.

Fifth, the existing systems and methods of a DP department often represent many man-years of investment. The introduction of SD techniques, and the latest generation tools, must take account of this investment and allow essential parts of the old systems and methods to be incorporated into the new development environment.

Development phases for Intellipse

To build a knowledge-based support environment, cap- able of meeting some or all of the objectives implied above, the authors have been through the following initial phases of development:

• The definition of a functional specification for the system.

• The establishment of a unified system architecture possessing a high degree of modularity and allowing for incremental development over a period of time.

• The identification and classification of the discrete tasks performed within SSD and their precise relationship within the overall SSD hierarchy.

• The adoption of a suitable, umbrella knowledge representation formalism for the system.

• The development of a structured knowledge engineering approach able to cope with the demands of a very wide application domain.

Advisor/Designer concept

The functional requirements of lntellipse are to advise a designer about the SSD method in general, by answering specific questions about objects and activities which are relevant in the domain. Second, to offer active support to the designer in the form of intelligent advice about a specific task within design. This advice should actively assist the designer to make design decisions and perform specific design tasks. Third, to automatically execute tasks or processes within the design phase of SSD which are currently executed manually. Finally, to build and maintain a unified project database and data dictionary which can be linked efficiently with any existing

systems and proprietary data dictionaries which are appropriate to a particular DP environment.

Following on from this general specification, two concrete modes of operation for Intellipse have emerged. 'Advisor-mode' is a passive, knowledge-based question- answering system dealing with the SSD domain. Essenti- ally, it is a collection of knowledge bases containing facts, rules, techniques and descriptions relating to all of the objects and activities with which the SSD method deals. In this context, examples of objects are 'data relations', 'keys' and 'transaction profiles'; examples of activities are 'data analysis' and 'extracting the system inputs'.

In advisor-mode the designer is able to interrogate the knowledge base about any object or activity known to the system. Information can be obtained, for example, about what an object is or why a particular activity is necessary. A description of how to perform an activity, and the rules which apply to that activity, are also available. However, in this mode Intellipse is only a passive advisor. It cannot execute, in relation to a real application, any of the design activities it knows about or manipulate any of the objects it describes.

The Advisor-mode knowledge base will act as an explanation facility while the user is in designer-mode.

The advisor-mode system was built first. This was the easiest course as Advisor is a passive system dealing with the SSD method and does not have to cope with data from a live project. However, it became clear that the implementation of Designer would be dependent on the prior existence of Advisor. In fact, the construction of Advisor was a key step in identifying the activities that the Designer system would have to support.

Knowledge bases and system architecture

Knowledge bases ( KB)

The SSD domain has been divided into six separate knowledge bases corresponding to the six phases of design defined in the SSD method. Each of these knowledge bases is made up of several distinct components. These include meta-level knowledge describing the objects and activities within a domain and their inter-relationships. Also, intermediate-level knowledge describing the types and categories of knowledge recorded for a particular topic. Another component is the low-level knowledge corresponding to the facts, heuristics and techniques for a given topic which is stored in the system as text or activity program modules (A PMs). Another distinct component is partially instantiated design templates appropriate for specific tasks within SSD and based on past applications or the design experience of BIS experts. This KB will exploit the commonality which exists between the designs of systems built for different application areas but whose functionality is broadly similar. A template-based appro-

vol 29 no 8 october 1987 433

ach to specification and design is discussed by Harandi and Young 2S.

The other knowledge bases which the system will require are the current systems KB, the physical constraints KB and the reusable components KB. The first two will contain knowledge about the particular DP environment in which Intellipse is installed. This would include data about the storage and processing constraints which the design had to meet. The reusable components KB, which would be linked directly to the current systems KB, will contain details about programs and other modules available to the designer.

The architecture of Intellipse has been designed with the maximum degree of modularity allowing development of the system to take place in an incremental fashion. Incremental development ensures that discrete elements of the system can be prototyped, evaluated and implemented without waiting for the system as a whole to be completed. In addition, the modular architecture allows individual components of lntellipse's knowledge bases to be revised as developments take place in the SSD method.

Central to the modular architecture are the activity program modules. The APMs will be executable modules which, together with the meta-level knowledge base, will govern the operation of Intellipse in Designer-mode. They will be either 'mini IKBSs' embodying the facts and rules governing a specific design task, or non-IKBS, algorithmic-based programs where the specific task in question can be completely automated. An APM may also be an existing tool such as an editor or compiler which can be invoked by the system. A schematic overview of the knowledge base hierarchy and system architecture is given in Figures la and lb.

Knowledge representation

Knowledge about an activity or object is classified into five categories:

• descriptive - what • procedural - how • justificational - why • conditional - when • illustrative - example

For activities, within the advisor system, there is knowledge of all categories. However, for objects the knowledge categories used are just descriptive and illustrative since the other categories are not usually appropriate. Within the Designer system, the knowledge categories used are procedural and conditional reflecting the active nature of the Designer system.

The knowledge representation used to codify the knowledge bases is a frame-based system illustrated in Figure 2. The frame-like knowledge representation ex-

/

KB Knowledge base DBMS Data base rnanagel DD Data dictionary IPSE Integ ated project support environment

Figure la. Schematic view of lntellipse's architecture

meta-level frames intermediate-level frames

low-level frames

ru les Active rules

Structuring processes-KB

Figure lb. Exploded view of a component of the SSD-KB

Domain: Topic: Structurin, data Data analysis

Top-level frame-key-number:

XXX1234

IS: activity

Intermediate frame-key-number:

YYY3456

Knowledge- type:

What How Why When Example

Related objects:

Related activities:

Sub-activities:

Record data and select key Remove repeating groups Remove part-key dependencies Remove other item dependencies Optimize and re-check

Figure 2. Some partially instantiated frames and their interrelationship


systems ploits some of the features usually associated with frame- based systems as proposed by Minsky in 197526. The use of multiple-valued slot categories in the frames enabled the authors to construct a complex, hierarchical structure, which can be implemented relatively easily in PROLOG.

The pattern matching power of the PROLOG language can then be exploited to achieve efficient interrogation of the domain.

Although a frame-based representation has been chosen as an umbrella for the system, individual APMs will use different knowledge representation formalisms tailored to the requirements of the particular design task which the APM is supporting. For example, the physical design KB may contain production rules of the form:

IF data transmission time + CPU processing time + disc i/o time < acceptable transaction time

T H E N consider optimization of disc accessing

in general, when developing knowledge-based systems in a wide domain a variety of different knowledge representation formalisms are likely to be necessary to meet the wide range of expertise required in the domain. This is an important observation since it is easy to gain the erroneous impression from many of the vendors of expert systems shells that expert systems are synonymous with production rule sytems, or that a single knowledge representation approach will always be adequate.

Knowledge engineering methodology

Two-stage process

A structured approach to the knowledge engineering for lntellipse has been used. The need to adopt a structured approach for building IKBSs has been discussed in two recent papers on methods for building knowledge-based systems the authors ' findings concur particularly with those reported by Zack 27'28. The procedure the authors have followed is outlined in Figure 3.

Stage one involved a 'first-pass' examination of the SSD manuals and standards documents by the knowledge engineers with a limited involvement of domain experts. This provided the basis for the meta-level knowledge bases and the low-level text required by the Advisor-mode system as well as a comprehensive domain taxonomy. The main purpose at this stage was to identify the tasks or activities described within the SSD method and to analyse the hierarchical relationship of these activities. This stage also helped familiarize the knowledge engineers with the domain.

Stage two involves an on-going study of the SSD method as it is used by expert practitioners in a 'live' D P

First pass examination ]

activity/task analysis

z

Detailed I activity/task

analysis

Figure 3. Knowledge engineering phases

environment. It involves detailed knowledge engineering sessions with senior BIS experts as well as other users of the SSD method using case studies and examples in an attempt to establish a thorough understanding of the design process. At this stage it is important to look at individual tasks, or logical groups of tasks, and to:

• classify the nature of the task, • ascertain the type of support appropriate, • establish the heuristics and procedures, • choose a suitable knowledge representation formalism, • devise and define design templates, • identify illustrative design examples.

The second step above is crucial since not all tasks are suitable for knowledge-based support. It may be possible, for example, to represent a task using a closed set of deterministic algorithms. In this case a task could be completely automated and the need for knowledge-based support would not arise. Successful development of knowledge-based systems depends on a critical assessment of the appropriateness of the problem for a knowledge-based approach.

Another objective during stage two is to enrich the knowledge bases built during stage one by incorporating


knowledge obtained from senior designers during the knowledge engineering sessions. This is knowledge which cannot be gleaned from purely documentary sources.

A knowledge acquisition module (KAM) has been developed in PROLOG to enable the knowledge engineers to create and revise frames and enter data into the knowledge bases. The KAM is required to manage the knowledge bases by maintaining links between frames and ensuring internal consistency.

Hierarchy sheets

The domain-hierarchy-sheets and topic-hierarchy-sheets referred to in Figure 3 are an important by-product of the knowledge engineering process. The sheets represent the hierarchical set of activities or tasks which are required to complete a specific design process. The domain- hierarchy-sheets deal with activities relevant to a whole sub-domain (like 'structuring data'), whereas the topic- hierarchy-sheets describe sub-activities within an higher level activity. The resulting tree-like structure of activities is codified in the knowledge bases and dictates the way a user is guided through the whole design process.

The hierarchy sheets can be likened to the activity diagrams which are usually generated during the systems analysis phase of a DP systems development project. In fact, the authors have found several analogies between conventional systems analysis and the knowledge engineering process associated with knowledge-based systems development. This is discussed later in the paper.

Implementation of Advisor

PC environment

The Advisor mode system has been implemented in PROLOG on an IBM PC/AT under PC/DOS. The choice of delivery vehicle was dictated by the desire to make the Intellipse tools available in the most accessible environment. The PC also offers scope for the incorporation of windows and mouse-driven menus in the user-interface. However, the use of a PC presents problems particularly in relation to the integration of the tools with other DP systems running in a mainframe or mini environment. For example, an installation may want to transfer work prepared on a PC to its mainframe data dictionary or use PC-based tools to work on data currently held on the mainframe. The effective linking of lntellipse with a mainframe environment has been identified as an essential requirement and particular attention will be paid to this in the construction of Designer.

In addition to the interface requirements identified above, it will be advantageous if Intellipse components are compatible with the BIS IPSE. The latter is a fully integrated project support environment for commercial

applications systems development covering methodology support, project management and documentation management. It is desirable that data generated by Intellipse can be transferred to BIS IPSE and that the IPSE can exploit the capabilities of Intellipse.

Query analyser

The use of PROLOG to implement the frame-based knowledge bases has allowed the authors to build a simple, pattern-matching natural language interpreter. The user is able to enter free-form, English-like queries to interrogate the knowledge bases allowing the experienced user to bypass the multiple-level menu system. This capability is essential since the system will contain knowledge bases covering over one hundred individual topics; each topic having, potentially, several categories of knowledge. The menu structure, which is governed by the frames themselves, will therefore reflect the breadth and complexity of the knowledge bases. Although this is an advantage for the naive user who can be guided through the domain, step by step, using the interactive menu system, this could be an inhibiting interface for the experienced user who is already familiar with the system, or with the SSD method.

Some examples of the free-form queries which can be processed by the system are:

• What is a prime key? • How do I perform first normal form analysis? • When do I start the physical design stage? • Show me an example of a transaction profile.

The authors found that an effective and practical 'natural language' capability can be achieved without restoring to the construction of a sophisticated set of grammar rules with their accompanying translation and interpretation modules. The latter approach inevitably leads to a severe cost in processing speed and consequent degradation in performance as seen by the user. The analyser the authors have built is designed to detect only key words or phrases in the input query and will therefore cope with un- grammatical sentences. This method also means that the user who has become familiar with the system can access the knowledge bases using a 'fast-path' by simply entering queries which only contain appropriate keywords.

User evaluation of Advisor

The Advisor system has been evaluated by two principal users, the BSC team who are formally attached to the project and a small development group within BIS Banking Systems Ltd. (BIS Banking is an independent company within the BIS group.) Senior analysts at BSC looked at Advisor from a general viewpoint to evaluate its


systems potential role within the DP installation at Port Talbot. They were particularly interested in the potential of Advisor to assist with the induction of new personnel.

The group at BIS Banking Systems Ltd were involved in a 2500 man-day project building bank back-office system software software for an IBM System 38 environment. The project team as using the BIS SSD methodology backed up by the BIS IPSE running on an IBM PC/AT. Members of the team had attended BIS courses on SSD but apart from this they were relatively inexperienced users of the BIS methodology. Their particular emphasis during the evaluation was to see how successfully Advisor was able to answer queries concerned with the SSD methodology in comparison with the use of the manuals or referring back to a senior BIS consultant.

Apart from the two principal evaluators above, several experienced DP personnel from different installations have also been asked to look at and comment on Advisor. The main conclusions of the evaluation are as follows.

Users want an extensive set of example problems to be available in the knowledge base. These examples should cover as many typical design problems as possible. If these examples number more than ten it will be necessary to develop a generic classification scheme which will allow an intelligent front end to be developed which can be used by the designer to locate the particular problem of relevance. Research is now in progress to add this facility to lntellipse.

Installations want to be able to tailor the Advisor knowledge bases to fit their own methodologies or variations to the BIS SSD standards. This means that the lntellipse tools will need to include a facility which will allow end users to amend or add to the Advisor KBs.

DP installations are very keen to capture their accumulated experience and technical expertise in a ma- chine form. In addition, they would like to store in an accessible form knowledge about the information systems, hardware and software within the company. This knowledge could then be used for general advice-giving within the installation and, in particular, for the training of new personnel. This is also seen as a way of mitigating the effects of high staff turnover. Linked with the above is the idea that a tool like Advisor can significantly reduce the support required from senior staff for education and training.

Life cycle for IKBS development One of the key lessons we have learnt during the first half of the Intellipse project is that any serious attempt to build an IKBS for use in an industrial or commercial environment must be managed using some form of the life-cycle model currently adopted for many large-scale commercial software engineering projects. However, the conventional

life-cycle model 29, consisting of feasibility, analysis, design, implementation, testing and maintenance phases, will need to be significantly adapted to meet the particular needs of an IKBS development project. The adapted conventional life-cycle model which we have evolved is illustrated in Figure 4. Two of the phases in the authors ' adapted model will be discussed in more detail.

Testing

A distinction has been drawn between the requirements analysis and systems analysis phases. The latter is synonymous in the authors ' model with knowledge engineering. It is important when building an IKBS to define precisely the desired objects for the system. This definition must be precise enough to be used as a basis for later testing of the system.

Current techniques used for the testing of conventional software are not suitable for the testing of a knowledge- based system since, by definition, the latter is a computer- based model of a particular human expert's behaviour.

I Initial feasibility ]

Requirements i analysis I

I Domain analysis

I Task analysis

{ I Secondary feasibility

I Detailed knowledge engineering

Establish the boundaries of the problem domain and its general suitability for an IKBS approach. An early demonstrator or prototype of the proposed IKBS may be required at this stage. A detailed statement of the qualitative and quantitative objectives (performance factors) desired for the IKBS solution.

Identification of tasks

Classification of tasks

Identification of tasks suitable for IKBS support

Establish rules, examples, templates

Systems analysis

Internal consistency testing and testing against objectives defined during the initial feasibility stage

Full-scale ] implementation I I ] I (possibly using ~ Testing conventional ] I

languages) I

Figure 4. IKBS development life cycle

Choose knowledge representation

Choose tools (shell, language, scratch-build etc.)

Periodic updating of knowledge bases

Maintenance ]


The testing criteria for the system must address the issue of whether the system is modelling accurately the expert's behaviour for a given set of 'input data'. However, this begs the question of whether a particular expert is successfully or adequately addressing the problem domain.

To overcome this problem it is therefore necessary to establish another set of objective criteria, unrelated to the views of the experts used to build the system, against which the IKBS can be measured. These objectives should include several factors which measure the success with which the system addresses the problems which led to the desire to build an IKBS in the first instance. These factors could, for example, deal with issues like the speed of decision making, the consistency of diagnosis and the reduced work load on the expert.

Feasibility

Two feasibility stages have been identified. The need for a second feasibility assessment during the systems analysis phase arises because of the need to evaluate critically the suitability of individual tasks identified within the application domain for a knowledge-based approach. As noted earlier in the paper, some tasks can be more easily supported using conventional techniques and it is important to concentrate the application of knowledge-based techniques solely to those tasks which cannot be addressed using a conventional approach. Where conventional techniques are used in conjunction with IKBS techniques, it is important to give careful consideration to the interfacing of the IKBS and non-IKBS components.

Summary and conclusions

A functional specification and architecture for a knowledge-based support environment has been described to aid the design of electronic data processing systems. The potential role of knowledge-based systems in such a domain has been discussed and a structured approach to building IKBSs has been proposed. A technical description of the parts of the system so far implemented has been given, together with the results of the user evaluation carried out on the Advisor system.

The authors' work to date has led to several conclusions. First, when trying to apply knowledge-based techniques in a wide domain it is necessary to identify carefully those domain tasks which are suitable for an IKBS approach.

Second, expert support environments for a wide domain will have to encompass IKBS and non-IKBS modules under a unified umbrella.

Third, wide domains are likely to require several different knowledge representation formalisms since no

one formalism can successfully reflect the breadth of' expertise which exists in such domains.

Fourth, a structured approach to IKBS development is essential when attempting to cope with the extensive knowledge engineering demanded in a wide domain. Finally, IKBS development should be managed using an amended form of the conventional software engineering lifecycle to ensure that the resulting systems have the reliability and robustness required in an industrial or commercial environment.

References

1 The Report of the Alvey Committee HMSO, London UK (1982)

2 Ramamoorthy, C V, Prakash, A, Tsai, W and Usuda, Y 'Software engineering: problems and perspectives. IEEE Computer (October 1984) pp 191-209

3 Mumford, E 'User participation in a changing environment why we need it' Proc. Unicom Seminar Participation in Systems Design London Business School (April 1987) Unicom Seminars Ltd

4 Corder, C R Ending the Computer Conspiracy McGraw Hill, UK (1985)

5 Dignan, A Software Engineering/IKBS Strategy for Knowledge Based IPSE Development Alvey Directo- rate, London UK (August 1984)

6 Basili, V R and Ramsey, C L 'Arrowsmith-P: A prototype expert system for software engineering management' Expert Systems in Government Sym- posium McLean VA, USA(October 1985)pp 252-264

7 Bium, B I and Sigillito, V G 'An expert system for designing information systems' Johns Hopkins APL Tech. Dig. (USA) Vol 7 No 1 (January-March 1986) pp 23-30

8 Dunning, B B 'Expert system support for rapid prototyping of conventional software' Proc. A utotest- con "85 IEEE Automatic Testing Conference, NY USA (October 1985)

9 Dyer, C A 'Expert systems in software maintainability' Proc. Annual Reliability and Maintainability Symp. San Francisco, CA USA (January 1984) pp 295 299

10 Frenkel, K A 'Toward automating the software- development cycle' Comm. ACM (USA) Vol 28 No 6 (June 1985) pp 578 589

I 1 Grindley, K 'Applying expert principles to computer systems development' Data Processing Vol 28 No 1 (January February 1986) pp 10 14

12 Hurst, R S, Frewin, G D, Hamer, P G 'A rule-based approach to a software production and maintenance management system Esprit '84, Status Report of Ongoing Work Brussels, Belgium (September 1984) pp 127 144. North-Holland, Amsterdam (1985)

,138 information and software technology

systems 13 Kampen, G R 'Expert specification tools' Third Int.

Workshop Software Specification and Des. London, UK (August 1985) pp 120-121

14 Leung, C H C 'A knowledge-base for effective software specification and maintenance Third Int. Workshop Software Specification and Des. London, UK (August 1985) pp 139 142

15 Lubars, M D Harandi, M T 'Intelligent support for software specification and design IEEE Expert (Win- ter 1986) pp 33 41

16 Owen, K 'Can advanced research help today's DP manager?' Alvey News (UK) No 10 (April 1985) pp 13 15

17 Robillard, P N and St-Denis, R 'How artificial intelligence can enhance software engineering' CIPS Rev. (Canada) Vo110 No 3 (May-June 1986) pp 14 15

18 Schachter-Radig, M J 'Development of knowledge- based systems - new ways for the development of software systems Proc. Arti£ Intell. Software Eng. Third European Seminar and Tutorial Ind. Software Technol. EWICS (June 1986) Freiberg, FRG

19 Zuaikernan, I, Tsai, W T and Volovik, D 'Expert systems and software engineering: ready for marriage?' IEEE Expert (Winter 1986) pp 25-31

20 Basili, V R and Zelkowitz, M V 'Analysing medium- scale software development' Proc. Third Int. Conf on Software Eng. Atlanta, GA, USA (May 1978)

21 Pidgeon, C W and Freeman P A 'Development concerns for a software design quality expert system'

Proc. 22nd ACM/IEEE Des. Automation Conf. Las Vegas, USA (June 1985)

22 Jackson, M A Principles of Program Design Academic Press, New York, USA (1975)

23 Steven, W P Myers, G J and Constantine, L L 'Structured design' IBM System J. Vol 13 No 2 (1974) pp 115 139

24 Yourdon, E and Constantine, L L Structured Design Prentice-Hall (1979)

25 Harandi, M T and Young, F H 'Template based specification and design Third lnt. Workshop Software Specification and Des. London UK (August 1985) IEEE Computer Society Press (1985)

26 Minsky, M 'A framework for representing knowledge' The Psychology of Computer Vision (Ed. Winston, P H) McGraw-Hill (1975)

27 Breuker, J A, Wielinga, B J and Hayward, S A 'Structuring of knowledge-based systems development' ESPRIT '85." Status Report of Continuing Work The Commission of the European Communities, Elsevier Science Publishers, The Netherlands (1986)

28 Zack, B A 'Selecting an application for knowledge- based system development' Proc. Third Int. Conf. on Expert Systems London (June 1987) UK Learned Information (Europe) Ltd. (1987)

29 Maddison, R. N, Baker, G. J et al Information System Methodologies Wiley Heyden Ltd on behalf of The British Computer Society (1983) []


intellipse: towards knowledge-based tools for the design of commercial data processing systems

Documents