1.1. Retrospective View on Question-Answer Approach
For more than ten years, our research has focused on the use of question-answering in the conceptual design of software intensive systems. This choice was due to the following reasons:
- 1.
Lack of sustained progress in enhancing the success of the development of this class of systems.
- 2.
Availability of long-term statistical reports containing information on the positive and negative factors that influence the success in designing the SISs (reports of the Corporation
- 3.
Our awareness of that very important source negatives is the human factor from the problems of the designer's interaction with available experience and its models.
- 4.
Our research results achieved at that time in the use of QA -reasoning in solving the approach tasks that we could try to evolve in the context of improving the degree of success in the development of SISs.
Beginning this phase of our research, we decided to orient on the best technology used for developing the SISs as sources of typical tasks and workflows as well causes and forms of human-computer interactions and their implementations. As a basic source, we chose Rational Unified Process, developers of which did not use obvious requirements and solutions for interactions of designers with the available experience and models of its items.
After that, stage by stage, the interests of which are reflected in Figure 1, we investigated possibilities and effects of question-answering in the context of positive and negative factors that influence the success in the development of SISs.
Figure 1. Retrospective view of stages of our research
At the first stage, we have created and investigated a set of new models, methods, and means that provide the controlled inclusion of QA-reasoning in conceptual designing the SISs. The use of created way of working had allowed us to define the specialized approach (QAapproach) for conceptual work with tasks in designing. This approach (partially described in chapters 3 and 4) has following features:
- 1.
The dynamics of the QA-approach is being represented with the current state of its tree of task Tr(Z *, t) that is built by the team T* of designers {Dvs} with the use of the stepwise refinement applied to the initial statement St(Z *, t0) of the root task Z*.
- 2.
For each node Z, expressed in the tree Tr(Z *, t) by the statement St(Z, t) of the corresponding task Z, the designer (responsible for this task) performs question-answer analysis (QA-analysis) in the form of the stepwise refinement also.
- 3.
The tree Tr(Z *,t) and the result of QA- analysis for each task of the tree are recorded in a special database (question-answer base, QA-base) in hierarchical forms any of which is visually accessible as a whole and at the level of its nodes (any node or a group of nodes).
- 4.
Tasks of the tree Tr(Z *,t) are distributed among designers of the team, the organizational structure of which is also registered in the QA-base.
- 5.
Designers interpret and apply any indicated artifact, and any component of this artifact as a visual model that helps them to interact with used the natural experience in the real-time.
Figure 2. Relations of Artifacts in QA-approach
For the estimation of the possible diversity of chosen artifacts and their components, we have used the RUP. Estimation helped us:
- 1.
From the viewpoint of questions and answers, to specify the system of types for nodes of hierarchical structures shown in Figure 2. The used viewpoint opened the possibility for the description of any type with sim2ilar models of data in QA-base.
- 2.
Chose for the task its normative question-answer model (QA-model) that can be adjusted by the designer as the example of the QA-model of the task for the definite case.
- 3.
Develop the appropriate net version of the toolkit WIQA.
The QA-model of the task is a model of collaborative reasoning in the real time process of solving the task. Any QA-model is a set of interactive objects such as <question>, <answer> and <Task> with the certain attributes and operations.
Therefore, specifications of the QA-models will be presented from the interactive system viewpoint or another word as specifications of a specialized software intensive system SISQA. Such position gives the possibility to use the experience of the SIS to the SISQA, first of all, the experience of the architectural description. We defined and investigated the QA-model of the task that is architecturally presented in Figure 3.
Figure 3. Architectural description of QA-model
In the scheme, any view indicates the definite set of functions that can be activated when the designer or designers will use this view of QA-model. In this work, the designer will use definite instrumental means, and technics provided a necessary act of modeling that will be useful for the corresponding task. That is why combining all views in a wholeness can be interpreted as the specialized SISQA with the toolkit that was named WIQA.
In such whole, the central occupies following vies:
- 1.
The task view that leads to the model QA(Z(t)) as an interactive task tree including the interactive model of Z(t) with models of all subordinated tasks. This view visually corresponds to the tree Tr(Z*,t) where any node is understood as a question of the <Task> type for which an answer has the type “solution of the task.”
- 2.
The logical-linguistic view that presents QA(Z(t)) within frames of logic and linguistics of questions and answers. The visual representation of the view includes a system of registered QA-reasoning as a set of QA-protocols corresponding to the task tree of Z(t). Each QA-protocol is a tree of questions and answers (QA-tree) which present the reasoning used in the decision process of the corresponding task.
The set of means providing the work of designers with both these views is the kernel of WIQA to extend the functionality of which we have used the mechanism of plug-ins. Let us notice that other views of QA-model of the task explicitly or implicitly concern the central views because they help to solve additional technological tasks. For example, the documenting view is responsible for the development of normative documents each of which defined by the corresponding question-answer pattern. The work with such patterns supports the kernel of WIQA and plug-ins “Documentation.”
The component structure shown in Figure 4 corresponds to one of the versions of the toolkit. In this structure, only a number of components have names indicating on views because the typical way of the view implementation is the use of the kernel and a number of definite plugins.
Figure 4. Components structure of WIQA
The toolkit WIQA is implemented as a client-server system that has been evolved architecturally view by view. The basic programming language is C#. By analogy with a Wordprocessor (for example, Microsoft Word), the toolkit is interpreted as a Question-Answer processor (QA-processor).