 |
 |
 |
|
 |
|||
 |
|||
| SC.6 Development of Knowledge-Based Systems |
SZ.6 Entwicklung wissensbasierter Systeme
 Contents
|
|
|---|
SC.6.1 Sequence Description for the Activities in Submodel SD
User requirements that to a large degree can be formulated as a basis for rules, are characteristic for knowledge-based IT systems. It is expected that, apart from these parts, other conventionally described parts and parts to be developed will be available.
The scenario shows how both knowledge-based and conventional parts can be developed in parallel and how generation and incremental refinement of the rule basis is integrated into the activity sequence according to the V-model. In addition, it contains information about the interpretation of the product designs (in particular for the User Requirements).
The development of knowledge-based systems follows the strategy of incremental development in order to appropriately map the stepwise enlargement and refinement of the rule base in a dialogue with the user.
The sequence of the SD activities during the development of knowledge-based systems is illustrated in Figure SC.6.
Preliminary Remarks:
- The scenario for the incremental system development is the basis for the following descriptions.
- The completion for the development of knowledge-based systems is shown in italics.
Figure SC.6: Sequence of SD Activities during the Development of Knowledge-Based Systems
Time T 0-Start
Initialization of the project and begin of the tasks with regard to the content according to submodel SD.Time T 1-First Increment
A preliminary system description is available as a result of activity SD1.2 - Description of Application System, it describes the core and the overall system functionality. In this connection, knowledge-based parts have to be declared in order to specify the scope of application for the knowledge base.For some of the fields identified in activity SD1.5 - User-Level System Structure (first increment level) the user-level requirements have been completely generated in part (field 1), in other parts they have been incompletely generated (field 2).
The representation of the functionality of the knowledge-based parts is realized as a rule basis that is generated across all fields. The rule basis is found in chapter "Requirements for the Functionality" as part of the "User-Level Requirements".
Together, the results of activities SD1.2 - Description of Application System and SD1.5 - User-Level System Structure are the User Requirements that are available in a first version at time T 1.
The User Requirements have be detailed enough for the following goals to be reached:
- All relevant user-level fields must, if possible, be named and its functions be separated from each other. (1)
- The cooperation of the fields must be clearly defined to all project members.
- It must be clear in which (field-specific) levels the System is to be developed, and which overall functionality is to be covered in the final version. To do this it is necessary to define milestones (possibly as baseline with time and functional scope).
- The knowledge-based parts must be indicated.
The individual fields are defined as detailed as required for the first productive system version. In later levels, the individual fields can be refined and completed by new ones.
A professionally sound and sufficiently defined specification for the realization of the first increment by a contractor is generated by taking into consideration the technical solutions within the scope of SD1 - System Requirements Analysis activities. The System Architecture and the Technical Requirements are completed and all other documents relevant for the realization and development results are generated. After the realization has been completed the first increment is made available to be used.
Normally, the rule basis (part of the user-level User Requirements) is already a relevant part of the implementation for the knowledge-based part. However, a rule basis must also be modularized within the scope of the preliminary design and has to be described within the scope of the detailed design. This is not dependent on the selected representation language.
For the conventional part, the development is realized in parallel to the knowledge-based part. Both parts are combined within the scope of the integration steps.
Time T 2 to T N-1-Further Increments
At the time of T 2, a refined version of the preliminary system description is available as a result of the repeated realization of activity SD1.2 - Description of Application System. Normally, the refinements affect the entire functionality of the System that was defined at the time of T 1. They are a specification of the requirements. However, these refinements may also lead to a new field.The user-level requirements are defined for the parts of the second increment. In this connection it is possible to re-describe fields that were not taken into consideration before, and to refine fields that were already available. In particular, the rule basis of the knowledge-based parts is updated and refined. The first feedback after using the first increment will be taken into consideration. The User Requirements thus available in a second version are the beginning for the refinement and completion of the System Architecture and the Technical Requirements.
The implementor, e. g. a contractor, expands the already productive system version 1 by the newly generated parts and integrates them within the scope of the integration steps. During the integration tasks, it may be necessary to make changes to system version 1. After the realization has been completed, the second increment is made available for use.
These steps are repeated for each increment.
Time T N-Complete System Description
At the time of T N, User Requirements, System Architecture, and Technical Requirements are complete and have all been submitted. After realization and making the System available to be used, the entire System is in use.
SC.6.2 Cooperation with the Other Submodels
The cooperation with the other submodels corresponds with the scenario to apply the V-model in an incremental system development.
SC.6.3 Criteria for the Selection of Scenarios
The following list of advantages and disadvantages and naming the most important requirements supports decision-making for the selection of the represented incremental procedure for the development of knowledge-based systems.
Advantages:
- User-friendly modeling of user-level requirements that are suited to represent the rule basis,
- flexible change of rule bases and problem-free transition to the realization steps,
- early delivery of a basis System and thus early use of an operable System core by the user,
- setting priorities of delivery sequence by the user (possibly on the basis of experience gained with the system parts delivered first),
- simple exchange of system parts (i. e. the increments) for maintenance and modification,
- problem-free change of contractor after realization of an increment,
- refinement of User Requirements during the development (the User Requirements must not be completely available at the beginning),
- distinctly shorter cycles as compared with conventional development during the modification of User Requirements.
- In real life, there is always a mixture of knowledge-based and conventional parts that have to be handled in parallel. Therefore, the above listed advantages of a solution that are only knowledge-based, must possibly be modified,
- unfavorable runtime behavior in rule based solutions in comparison to conventional solutions,
- inflexible reaction to unforeseeable changes in case this refers to delivered system parts or their interfaces,
- necessity of early specification of the overall System scope for the entire development time
- User requirements that are suitable as models for the rule basis,
- it must be possible to separate the System with clear interfaces (modular structure of the System Architecture).
Note: (1) It is possible that new user-level fields are added in the course of development. This can be problematic for contractual reasons.
|
|
|
This page online • GDPA Online • Last Updated 03.Mar.2004 by C. Freericks |