Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


3. SOFTWARE ENGINEERING: AN OVERVIEW

The primary contribution of software engineering is to identify and describe the various activities involved in the development of a complex software artifact. Figure 2 shows some of these activities. For a small system, activities may be merged, performed implicitly, or even omitted entirely. The development of a large system may require repetition of the activities, and perhaps additional activities.

The second contribution of software engineering is to identify various ways of ordering the activities into a life cycle. The first life cycle proposed was the waterfall (Royce, 1970), which required the activities to be performed sequentially in the order listed above but provided for some feedback between consecutive activities. For example, a specification could be changed during the design phase but not during the implementation phase.

The waterfall is adequate when the people who will eventually use the system (the clients) have a clear idea of their requirements. If the proposed system incorporates novel ideas or techniques, the clients will probably not know what they want until they have gained experience with the system, by which time it may be too late to reconsider early design decisions and rebuild the system. For this reason, the waterfall life cycle is not usually considered to be suitable for expert system development.

Requirements analysis

Specification

Design

Implementation

Testing

Maintenance

Documentation

FIGURE 2 Activities in software development.

The spiral life cycle (Boehm, 1986) avoids some of the problems of the waterfall. Development is a sequence of tasks that leads toward the final product. Each task is preceded by a risk analysis and followed by verification. The risk analysis identifies the things most likely to go wrong during the current cycle; if the problems appear to be insoluble, the project may be abandoned. Verification ensures that the chosen task has been completed successfully. Each cycle -- analyze risk, perform task, verify -- yields a partial product that can be demonstrated to the user. A task in the spiral approach may correspond to a phase of the waterfall, but it is more likely to be the complete development of a component of the system.

For each phase in the development of software, there is a corresponding activity in the development of an expert system. The details of the phase may be different, but the underlying principles and purposes are the same.

In software development, the requirements analysis phase determines the needs of the client. Requirements are often divided into functional and nonfunctional requirements. The functional requirements of an expert system include aspects such as the breadth and depth of the knowledge base, facilities for maintaining and updating the knowledge base, and the form of the user interface. Nonfunctional requirements would include the number of users supported, response times, and the ability to cooperate with other software components.

After obtaining requirements, the supplier develops a specification. The specification plays a dual role, acting as a contract and a blueprint (Batarekh, Preece, Bennett, and Grogono, 1991). As a contract, the specification provides a detailed description of what the system must do and, perhaps, what it must not do. If possible, the specification should include a set of acceptance tests: the client and the supplier agree that the contract has been honored when the expert system has passed all -- or perhaps a specified percentage -- of the acceptance tests.

In software development, it is usually considered undesirable to include implementation information in the specification. Inevitably, however, specifications do contain explicit and implicit hints of possible implementations; if this were not the case, the world would be full of unimplementable specifications. It is particularly difficult to keep implementation information out of an expert system specification. The specification should describe the accessibility of the knowledge in the knowledge base, and this accessibility influences the structure of the knowledge base. In this sense, the specification is a blueprint as well as a contract: it provides the developers with a ground plan for the next phase, design.

A software design is a description of the proposed systems at a level of detail that enables programmers to code the parts for which they are responsible without necessarily understanding the system as a whole. A design typically has at least three components: the architecture shows the modules that constitute the system and the connections between them; the module interface specifications define the external behavior of each module; and the internal module descriptions describe the implementation details of each module.

An expert system design is similar in form but is usually less detailed. The architecture identifies the major components of the expert system; these may include user interfaces, report generators, databases, and other software components, as well as the knowledge base. The knowledge base itself may be divided into modules to simplify its development and maintenance. As in a software design, the module interface specifications define the responsibilities of each module. But the internal module descriptions may be simpler, or even nonexistent, for modules that will be implemented simply as sets of rules.

Building of the system takes place during the implementation phase. (In a business context, "implementation" is often used to mean the installation of existing software within the company (Bradley and Hauser, 1995). In this chapter, "implementation" denotes the construction of a system from its design.) Programmers write code for the software components and knowledge engineers perform knowledge acquisition and then translate declarative statements into rules for knowledge base components.

Testing may be postponed until implementation is complete, but it is usually preferable to start testing as soon as there are individual components to test. When unit tests have demonstrated that all components are functioning correctly, integration tests are run to check the performance of the complete system. Testing a knowledge base is quite different from testing code, and Section 4.1 provides a detailed discussion of this aspect of expert system development.

When the expert system has passed a sufficient number of acceptance tests, it is delivered to the client. The developer does not stop working on the project, however, because all large systems require maintenance. Software maintenance is commonly divided into three categories. Corrective maintenance consists of finding and fixing faults in the system. Even after thorough testing, a complex system will usually still have faults, and they must be corrected as soon as possible after the client has discovered them. Perfective maintenance consists of improving the usefulness or performance of the system, usually in response to requests from the client or users. For an expert system, perfective maintenance might include adding or modifying rules, shortening response times for common requests, or improving the user interface. Finally, adaptive maintenance may be necessary to enable the system to operate in a modified environment: the client may have obtained more user terminals, larger and sharper screens, or have upgraded the hardware or operating system. In each case, the system must be adapted to the new conditions.

If the costs associated with a large system are measured over its entire lifespan, from inception to obsolescence, maintenance costs dominate, often accounting for 80% or more of the total cost. It follows that developers should expend effort during the early phases to simplify maintenance.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.