Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Scenarios  Homepage  
SC.6 Development of Knowledge-Based Systems  

  SZ.6 Entwicklung wissensbasierter Systeme

  • SC.6.1 Operational Sequence Description for the Activities in Submodel SD
  • SC.6.2 Cooperation with the Other Submodels
  • SC.6.3 Criteria for the Selection of the Scenarios
  • 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:

    Figure SC.6
    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:

    As a result of activity SD2.1 - Technical System Design, the fields of the first increment are described in their technical realization (in the System Architecture and in the Technical Requirements).

    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.


    Disadvantages: Requirements: The mentioned advantages and disadvantages must be assessed and evaluated in every individual case. They are not applicable for all projects, but have to be assessed with regard to the user-level and Technical Requirements as well as the marginal conditions to be observed.

    (1) It is possible that new user-level fields are added in the course of development. This can be problematic for contractual reasons.

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks