工學博士學位論文

에이전트기반 다구찌 실험계획 의사결정지원시스템

Agent-Based Decision-Support ing System

for Taguchi Experiment Planning

2001 年 8 月

仁荷大學校 大學院

自動化工學科

趙 星 晉

工學博士學位論文

에이전트기반 다구찌 실험계획 의사결정지원시스템

Agent-Based Decision-Support ing System

for Taguchi Experiment Plann ing

2001 年 8 月

指導敎授 李在元

이 論文을 工學博士學位 論文으로 提出함

仁荷大學校 大學院

自動化工學科

趙 星 晉

이 論文을 趙星晉의 博士學位 論文으로 認定함

2001 年 8 月

主番

副番

委員

委員

委員

i

요약문

본 논문은 에이전트기반 다구찌 실험계획 의사결정지원 시스템의 개발에 관

해 다루고 있다. 다구찌 실험을 구성하는 4 개의 단계 중 실험계획단계는 실험

목적, 품질특성, 인자선정 등과 같이 실험의 근간이 되는 가장 중요한 의사결정

을 포함하고 있으면서도 지금까지 그 중요성이 간과되어 왔다.

본 연구에서 개발된 시스템은 에이전트를 기반으로 하는 2 개의 의사결정지

원 메커니즘을 통해 실험설계자의 다구찌 실험계획을 지원 한다. 첫 번째로, 도

메인 지식제공 메커니즘은 수집 에이전트라는 인터넷 에이전트를 이용하여 분

산된 지식제공자들로부터 실험의 대상이 되는 분야의 지식을 수집하고, 보고 에

이전트를 이용하여 이를 정리 및 가시화하여 실험설계자에게 보고함으로써 다

구찌 실험계획의 의사결정을 지원한다. 이 메커니즘을 이용하면 시간적, 지리적

으로 회의를 갖기 어려운 지식제공자들도 동일한 실험 팀을 이루어 브레인스토

밍을 통한 실험계획의 의사결정에 기여할 수 있다. 두 번째로, 상황감지 도움말

메커니즘은 도움말 에이전트라는 지능형 에이전트를 통하여 실험설계자의 설계

행위를 관찰하고 그 상태를 파악하여 상황에 알맞은 도움말을 적절한 시점에

제공한다. 상황감지 도움말 메커니즘은 도메인 지식제공 메커니즘과 더불어 실

험설계자의 의사결정오류를 줄여 실험의 신뢰성을 증가시키며, 불필요한 시간과

자원의 낭비를 막을 수 있다.

ii

Abstract

This paper deals with an agent-based decision-supporting system for

Taguchi experiment planning. Among the four major parts of Taguchi

experiment, the planning phase includes the most important decision-

making issues such as determination of experiment objectives, quality

characteristics, and control factors. The planning phase, however, has not

been paid proper attention by experiment designers. In this research, an

agent-based decision-supporting system for Taguchi experiment planning

has been developed to facilitate the planning tasks of experiment designer.

The decision-supporting system is composed of two agent-based

mechanisms. The first employs an Internet agent that collects the domain

knowledge from knowledge providers who may be distributed in remote

places. Another agent then visualizes the collected knowledge and reports it

to the experiment designer. Engineers who would normally have difficulties

in collaborating because of limitations on their time or because they are in

different places can easily work together in the same experiment team and

brainstorm to make good decisions. The second agent-based mechanism

offers context-sensitive advice generated by another intelligent agent

during the experiment planning process. It prevents the experiment

designer from making improper decisions, which will increase the feasibility

of the experiment and minimize the unnecessary expense of time and

resources.

iii

목 차

요약문

Abstract

목차 그림목차

표목차

제 1 장 서 론 .........................................................1

1.1 연구배경 ................................................................. 1

1.1.1 강력한 품질구현 도구: 다구찌 방법 ..................................... 1

1.1.2 다구찌 방법이 실패하는 원인............................................... 1

1.1.3 다구찌 방법의 전산화 사례.................................................. 3

1.2 연구목적 ................................................................. 5

1.3 연구내용 ................................................................. 5

제 2 장 이론적 배경................................................8

2.1 다구찌 방법(Taguchi Method) ................................. 8

2.1.1 다구찌 방법의 개요.............................................................. 8

2.1.2 다구찌 방법의 수행.............................................................13

2.1.3 다구찌 방법 수행절차의 비교..............................................16

2.2 소프트웨어 에이전트...............................................21

2.2.1 소프트웨어 에이전트의 정의 ...............................................21

2.2.2 소프트웨어 에이전트의 종류 ...............................................23

2.2.3 소프트웨어 에이전트의 이점 ...............................................24

2.2.4 에이전트기반 의사결정지원 시스템 .....................................25

2.3 인터넷기반 설문조사시스템 .....................................25

2.3.1 인터넷기반 설문조사시스템의 개요 .....................................25

2.3.2 인터넷기반 설문조사시스템의 장단점..................................26

2.3.3 인터넷기반 설문조사시스템의 개발 .....................................27

2.4 상황감지 도움말 시스템..........................................30

2.4.1 상황감지 도움말 시스템의 개요 ..........................................30

iv

2.4.2 상황감지 기술의 개요 .........................................................31

제 3 장 다구찌 실험계획........................................ 33

3.1 실험 팀의 구성.......................................................33

3.2 품질문제의 인식 .....................................................34

3.3 실험목표의 설정 .....................................................35

3.4 품질특성의 결정 .....................................................36

3.5 측정계획 ................................................................37

3.6 인자의 선정............................................................38

3.7 실험전략의 수립 .....................................................39

제 4 장 실험계획 의사결정지원 시나리오의 설계...... 41

4.1 의사결정지원 시스템의 개념설계 .............................41

4.1.1 다구찌 실험계획의 의사결정 특징 분석...............................41

4.1.2 실험계획에 필요한 지식의 전달 방법 설계..........................42

4.1.3 의사결정지원시스템의 전체 레이아웃 설계..........................43

4.2 도메인 지식제공 메커니즘.......................................45

4.2.1 도메인 지식제공 메커니즘의 개요.......................................45

4.2.2 도메인 지식제공 메커니즘의 세부동작 ................................45

4.2.3 도메인 지식제공 메커니즘의 이점.......................................49

4.3 상황감지 도움말제공 메커니즘 ................................50

4.3.1 상황감지 도움말제공 메커니즘의 개요 ................................50

4.3.2 상황의 표현 ........................................................................51

4.3.3 상황 파악 및 행동 결정......................................................52

제 5 장 실험계획 의사결정지원 시스템의 구현......... 57

5.1 UML을 이용한 응용프로그램 설계...........................57

5.1.1 UML (Unified Modeling Language)의 개요 ........................57

5.1.2 UML을 이용한 시스템의 설계.............................................66

5.2 프로토타입 시스템의 개발.......................................82

5.3 시스템의 동작 ........................................................82

제 6 장 사례연구................................................... 97

v

6.1 사례연구 (1) - 용접봉의 다발압출공정 최적화 .........97

6.1.1 압출 가공의 개요................................................................97

6.1.2 도메인 지식제공 메커니즘을 이용한 인자수집.....................98

6.1.3 인자수집 결과의 검토 .........................................................99

6.2 사례연구 (2) - 점 용접 표면의 요철 최소화 ..........100

6.2.1 점 용접 가공의 개요.........................................................100

6.2.2 도메인 지식제공 메커니즘을 이용한 인자의 중요도 조사..101

6.2.3 인자의 중요도 조사 결과의 검토.......................................102

6.3 사례연구 (3) - 사출성형 병 뚜껑의 누수 최소화....103

6.3.1 병 뚜껑 사출성형 사례의 개요..........................................103

6.3.2 상황감지 도움말 제공 메커니즘의 작동.............................104

6.3.3 도움말 제공에 대한 검토 ..................................................106

제 7 장 고찰........................................................107

7.1 의사결정지원 시스템의 활용성에 대한 고찰 ...........107

7.2 시스템 개발과정에 대한 고찰................................108

7.3 관련 연구와의 비교 ..............................................110

제 8 장 결론 및 향후연구사항...............................114

8.1 결론.....................................................................114

8.2 향후 연구사항 ......................................................115

참고문헌................................................................117

vi

그림목차

Figure 1-1 Causes of failure in Taguchi method ......................................... 2

Figure 1-2 User interface of RIPSES in selecting L18 orthogonal array

(upper), entering experiment results (middle), and showing

analysis result in graph (under)............................................... 4

Figure 1-3 The significance of planning phase covered in this research.... 7

Figure 2-1 (a) conventional quality loss function, (b) quadratic quality loss

function of Taguchi.................................................................11

Figure 2-2 Threshold of Intelligent Agency ...............................................23

Figure 2-3 An example of internet survey .................................................26

Figure 2-4 An example of context-sensitive help system .........................30

Figure 4-1 The framework for decision makings in Taguchi experiment

planning ..................................................................................44

Figure 4-2 The structure of collector agent...............................................46

Figure 4-3 The structure of reporter agent ...............................................47

Figure 4-4 A part of user interface for question configuration..................49

Figure 4-5 The structure of advisor agent .................................................51

Figure 4-6 An example of context for the current situation ......................53

Figure 4-7 The context updated from Figure 3-6......................................56

Figure 4-8 The threshold of advice............................................................56

Figure 5-1 An example of use case diagram ..............................................61

Figure 5-2 An example of sequence diagram.............................................62

Figure 5-3 An example of collaboration diagram .......................................63

Figure 5-4 An example of a class...............................................................64

Figure 5-5 An example of class diagram ....................................................64

Figure 5-6 An example of activity diagram ................................................65

Figure 5-7 Use case diagram for experiment designer..............................68

Figure 5-8 Main use case diagram..............................................................69

Figure 5-9 Activity diagram for the use case: ‘Create New Experiment’ ..71

Figure 5-10 Icons representing 3 types of class........................................74

Figure 5-11 Six packages and including classes ........................................75

vii

Figure 5-12 Collaboration diagram for the use case: ‘Answer to Survey’ .76

Figure 5-13 Sequence diagram for the use case: ‘Create New Survey’ ....77

Figure 5-14 Class diagram for the use case: ‘Answer to Survey’ .............78

Figure 5-15 Attributes and operations of the class: ‘Answer’ ...................80

Figure 5-16 Statechart diagram for the class: ‘MainProgramManager’ .....81

Figure 5-17 Main program of experiment planning ....................................83

Figure 5-18 Experiment planning wizard 1 of 6 – Forming Experiment

Team.......................................................................................83

Figure 5-19 Experiment planning wizard 2 of 6 – Identifying Quality

Problem ..................................................................................84

Figure 5-20 Experiment planning wizard 3 of 6 – Determining Experiment

Objective.................................................................................85

Figure 5-21 Experiment planning wizard 4 of 6 – Determining Quality

Characteristic .........................................................................86

Figure 5-22 Experiment planning wizard 5 of 6 – Selecting Control/Noise

Factors ....................................................................................87

Figure 5-23 Experiment planning wizard 6 of 6 – Determining Experiment

Strategy ..................................................................................88

Figure 5-24 Main interface for Domain Knowledge Providing Mechanism 89

Figure 5-25 User interface for Create new survey 1 of 4 – Enter Survey

Information .............................................................................89

Figure 5-26 User interface for Create new survey 2 of 4 – Select Survey

Type .......................................................................................90

Figure 5-27 User interface for Create new survey 3 of 4 – Enter Option

Items .......................................................................................90

Figure 5-28 User interface for Create new survey 4 of 4 – Select Report

Type .......................................................................................91

Figure 5-29 An example of newly generated survey .................................92

Figure 5-30 An example of report for survey result..................................93

Figure 5-31 An example of current experiment plan .................................94

Figure 5-32 User interface of advisor agent ..............................................95

Figure 5-33 Advisor agent gives advice after a few additional questions .96

viii

Figure 6-1 Overview of multi-extrusion process.......................................98

Figure 6-2 Extrusion die .............................................................................98

Figure 6-3 Overview of spot welding operation .......................................100

Figure 6-4 An example of report generated by DKPM.............................102

Figure 6-5 The section view of injection molded bottle cap ....................104

Figure 6-6 A part of user interface for determining quality characteristic

..............................................................................................105

Figure 6-7 An example of advice suggested by CSAM ............................106

ix

표목차

Table 2-1 Tasks in Taguchi method process .............................................13

Table 2-2 Selecting orthogonal array considering the number of control

factors and their levels ...........................................................14

Table 2-3 L18 orthogonal array...................................................................15

Table 2-4 Taguchi experiment process proposed by Phadke ....................17

Table 2-5 Taguchi experiment process proposed by Ross ........................19

Table 2-6 Taguchi experiment process proposed by Peace......................20

Table 2-7 Comparison between intelligent agents and expert systems.....22

Table 2-8 Benefits of intelligent agent.......................................................24

Table 2-9 Comparing methodologies implementing Internet survey..........29

Table 3-1 Organization of an experiment team ..........................................34

Table 4-1 Question types and options supported in this research.............49

Table 4-2 The structure of context............................................................52

Table 5-1 Event flow of the use case: ‘Create New Experiment’ ..............70

Table 6-1 Comparison between conventional interview and DKPM...........99

Table 7-1 Comparison of Taguchi software systems...............................112

1

제 1 장 서 론

1.1 연구배경

1.1.1 강력한 품질구현 도구: 다구찌 방법

다구찌 방법(Taguchi method)은 경제적인 비용으로 잡음에 강건한 품질을

구현할 수 있는 체계적이고 효율적인 제품/공정의 설계 방법론이다. 흔히 강건

설계(robust design)라고도 하는 이 방법은 1920년대 R. A Fisher가 제안한 통

계적 실험계획법을 기초로, 다구찌(田口玄一, Genichi Taguchi)를 필두로 한 많

은 통계학자 및 공학자들에 의해 발전되어 왔다. 통상적인 실험은 시행착오에

근거하여 보통 한번 실험에 한 개의 변수의 최적화를 고려하기 때문에 제품설

계를 완성하기 위해서 많은 시간과 비용을 필요로 하며, 종종 최적화에 실패한

다. 결과적으로 생산자는 소비자에게 불완전한 제품을 비싸게 공급할 수 밖에

없고, 경쟁력을 잃게 된다. 다구찌 방법에서는 ‘직교배열(orthogonal array) ’이

라는 수학적 방법과 ‘신호 대 잡음비(signal to noise ratio, S/N ratio) ’라는 품

질평가 개념을 이용하여 다양한 사용환경에서 원하는 품질을 유지할 수 있는

제품이나 생산공정을 적은 실험 횟수를 통하여 설계할 수 있다. 다구찌 방법은

1960년대 이후 일본의 급속한 산업성장의 원동력이 되었으며, 1980년대 이후

미국으로 전파되어 그 효용성을 유감없이 드러내어 현재까지 전 세계적으로 가

장 유용한 품질공학 도구 중 하나로 널리 사용되어 오고 있다(Taguchi, 1987;

Phadke, 1989; Peace, 1993; Fowlkes, 1995; Ross, 1996).

1.1.2 다구찌 방법이 실패하는 원인

다구찌 방법이 강력한 품질구현 도구이며, 그 수행이 기본적으로 쉽다는 것

은 대다수의 사람들이 인정하는 바이다. 그러나 모든 사람이 다구찌 방법을 통

해 만족스러운 결과를 얻는 것은 아니다. 많은 사람들이 다구찌 방법에서 실패

2

를 경험했으며, 이 들 중 일부는 다구찌 방법 자체를 불신하게 된 경우도 있었

다. 다구찌 방법이 실패하는 원인은 여러 가지가 있을 수 있다. Figure 1-1은

다구찌 방법의 실패 요인을 변형된 cause-and-effect diagram의 형태로 도시

한 것이다. 그림에서 볼 때, 실험계획 단계의 오류는 지속적으로 이후 단계에

이어져 결국 실험 실패의 근원으로 작용함을 알 수 있다. 이는 다구찌 방법이

순차적으로 진행되는 프로세스를 가지고 있어 이전 단계의 오류가 이어지는 단

계로 전파되기 때문이다.

Improper Planning

Has t y Dec is ion

Mak ingLack o f D o m a n

Know l edgeLack o f

Taguch i Know l edge

Improper

Orthogonal Array

ImproperAssigning

of Factors

Bad Environment

Unskillful Operator

Bad Measurement

Improper

S/N Ratio

Calculation Error

Wrong

Interpretation

Failure in Taguchi

Experiment

Improper Design

Improper Experiment

Improper Analysis

F i g u r e 1-1 C a u s e s o f f a i l u r e i n T a g u c h i m e t h o d

3

Peace (1993) 는 다구찌 실험이 (많은 노력을 경주한 경우라 할지라도) 종종

실패하는 원인이 기술의 부족이나 통계적 수식의 오용, 계산상의 오류가 아니라

주로 부적절한 실험계획 때문이라고 설명하였다. 이러한 사실에도 불구하고 많

은 실험설계자 들은 실험계획 단계의 중요성을 간과하고, 이 단계에 많은 시간

을 할애하지 않아왔는데, 이는 다구찌 방법의 효율적인 사용을 위해 반드시 극

복되어야 할 사항이다.

1.1.3 다구찌 방법의 전산화 사례

다구찌 방법의 광범위한 활용에 비하면 컴퓨터를 이용하여 다구찌 방법 수

행의 효율을 높이려는 노력은 그리 많이 이루어지지 않았다. 단지 소수의 공학

자들과 소프트웨어 개발자들에 의해 부분적인 전산화 시도가 이루어졌을 뿐이

다. Dermiggio에 의해 개발된 WinRobust (Fowlkes, 1995), 상용 소프트웨어인

ANOVA-TM (Advanced Systems & Designs Inc. 1986) 과 STN (InfoMate,

1989), 그리고 일본에서 개발된 RIPSES (Nojima, 1996) 등이 그 대표적인 예

이다. 이들 도구는 모두 행렬실험의 설계와 결과분석을 위한 spreadsheet와 같

은 연산을 수행하는 데 중점을 두고있다. Figure 1-2는 RIPSES의 실행 모습으

로 전형적인 ‘행렬실험설계 및 결과분석’ 시스템들의 기능을 보여주고 있는데,

이러한 기능은 Microsoft Excel과 같은 도구로 충분히 대치할 수 있는 것이다.

그 밖에 다구찌 실험설계에 인공지능을 적용한 예로 Lee (1989) 등이 개발한

행렬실험설계 전문가시스템이 있다. Prolog 언어를 이용하여 개발된 이 시스템

은 제어인자와 그 수준에 관한 정보를 입력 받아 적절한 직교배열을 선택하고

행렬실험을 설계해주는 기능을 가지고 있다. 국내에서도 드물지만 다구찌 방법

을 전산화하려는 연구를 찾아볼 수 있다. 이인배(1993)는 변수 및 허용차 설계

를, 이종훈(1997)은 동적 변수 설계를 전산화 하였다. 정환종 등(1999)은 직교

배열을 선택하고 인자할당을 위해 이를 변형하는 전문가시스템을 개발하였다.

앞 문단에서 소개한 몇 가지 상용 소프트웨어 시스템과 전문가시스템은 모

4

두 다구찌 실험단계 중 행렬실험 및 그 이후의 과정에 중점을 두고 있으며, 다

구찌 실험의 초기단계이자 가장 중요한 단계인 ‘실험계획’에 관하여 다루지 않

고 있다. 이는 실험계획 단계의 중요성이 인식되지 못했을 뿐 아니라, 실험계획

단계의 전산화가 그리 용이하지 않았기 때문으로도 풀이된다.

Figure 1-2 User in te r face of RIPSES in s e l e c ting L18 orthogonal array

(upper), enter ing exper iment resul ts (middle), and showing analys is resul t in

g r a p h ( u n d e r )

0000

5

1.2 연구목적

본 연구의 목적은 다구찌 방법 중 실험계획 단계의 의사결정을 지원하기 위

한 소프트웨어 시스템을 개발하는 것이다. 실험계획 단계는 실험목표, 품질특성

의 결정, 제어인자의 선정 등 실험의 근간이 되는 사항을 결정하는 단계이다.

다구찌 실험단계는 실험대상이 되는 분야에 대한 지식과 더불어 다구찌 방법

자체에 대한 지식도 필요로 한다. 본 연구에서는 이 두 가지 지식을 실험설계자

에게 제공함으로써 다구찌 실험계획의 올바른 의사결정을 지원하고, 나아가 실

험 전체의 신뢰성을 향상시켜 불필요한 시간과 자원의 낭비를 최소화하며, 원하

는 품질을 구현하기 위한 성공적인 실험이 되도록 지원하고자 한다.

1.3 연구내용

본 연구에서는 다구찌 실험계획을 위한 에이전트기반 의사결정지원시스템

을 연구하고, 타당성 확인을 위하여 ADTEP (Agent-based Decision-

supporting system for Taguchi Experiment Planning)을 개발하였다. 세부 연

구사항은 다음과 같다.

n 다구찌 방법 수행 절차에 관한 연구: 소프트웨어를 통한 다구찌 방법 지

원 시나리오를 수립하기 위해 다구찌 방법의 수행 절차를 분석하고, 여

러 학자들이 제안한 절차를 비교.

n 다구찌 방법 지원 소프트웨어 및 관련 연구에 대한 조사: 다구찌 방법을

효과적으로 지원하는 소프트웨어를 개발하기 위해 기존의 관련 시스템

들을 조사하고, 장단점, 개선 사항 등을 분석.

n 다구찌 실험계획에 대한 연구: 실험계획 단계의 중요성을 파악하고, 이

단계의 의사결정을 지원하기 위해 요구되는 지식의 종류 및 특징, 제공

6

방안 등을 모색.

n 소프트웨어 에이전트(software agent)에 관한 연구: 실험계획에 필요한

지식을 제공하기 위한 도구로 소프트웨어 에이전트를 선정하고, 그 개요

와 종류, 활용 방안에 관해 연구.

n 인터넷기반 설문조사시스템(Internet-based survey system)에 관한 연

구: 실험대상 분야에 대한 지식제공을 위해 인터넷기반 설문조사시스템

을 연구.

n 상황감지 도움말 시스템(context-sensitive help system)에 관한 연구:

다구찌 방법에 대한 지식제공을 위해 상황감지 도움말 시스템을 연구.

n UML (Unified Modeling Language)을 이용한 시스템 설계: 체계적이고,

개발과 보완이 용이한 시스템을 설계하기 위해 UML을 도입.

n 개발 기술에 관한 연구: 윈도우와 인터넷 환경에서 동작하는 시스템을

구현하기 위해 윈도우 프로그래밍, COM, ASP (Active Server Page),

IIS (Internet Information Server) 등에 관해 연구.

n 프로토타입 시스템(prototype system)의 개발 및 검증: 프로토타입 시

스템을 구현하였으며, 사례연구를 통하여 그 유효성과 활용도 등을 평가.

n 향후 연구사항 정리: 시스템의 개선점을 정리하고 확장 가능성을 검토.

본 연구는 다구찌 방법의 수행절차 중 실험계획 단계만을 다루고 있다. 이는

다른 단계의 경우 이미 개발된 시스템이 있으며, 해당 부분의 중요도가 실험계

획 단계에 비해 상대적으로 낮은데 비해 개선의 여지는 많지 않기 때문이다.

Figure 1-3에 다구찌 방법의 수행절차 중 본 연구가 다루고 있는 부분과 그 중

요도를 개략적으로 도시한다.

7

EffectOf

WrongDecision

ExperimentProcedurePlanning

PhaseDesigning

PhaseConducting

PhaseAnalyzing

Phase

Previous Works

Covered in this research

F i g u r e 1-3 The s i gn i f i cance o f p l ann i ng phase cove red i n t h i s r esea rch

8

제 2 장 이론적 배경

2.1 다구찌 방법(Taguchi Method)

본 절에서는 다구찌 방법에 대해 설명한다. 먼저 다구찌 방법의 정의, 역사

와 기원을 소개하고, 다구찌 방법을 구성하는 기본적인 개념, 용어에 대해 언급

한다. 또한 학자들이 제안한 몇 가지 다구찌 방법의 수행 절차들을 간략하게 비

교하고, 마지막에 본 연구에서 모델로 채택한 Peace (1993)의 절차에 대해서

설명한다.

2.1.1 다구찌 방법의 개요

2.1.1.1 다구찌 방법의 정의

다구찌 방법(Taguchi method)은 잡음(noise) 조건에서도 제품의 품질특성

(quality characteristic)이 바람직한 값을 유지할 수 있도록 제품이나 공정을

경제적으로 설계 또는 개선하기 위해 최적 인자조합을 찾는 off -line 품질관리

기법이다1 (Taguchi, 1987; Phadke, 1989; Peace, 1993).

2.1.1.2 다구찌 방법의 역사적 조망

일본이 제 2 차 세계대전 패망 후 재건을 시작했을 때, 고품질 원료, 고성능

제조 시설장비와 숙련기술자가 절대적으로 부족하였다. 이런 상황에서 고품질의

제품을 생산하고, 또한 품질의 지속적인 향상을 이루어야 하는 과제를 해결하는

방법론을 다구찌(Genichi Taguchi) 박사가 제안하였는데 이것이 바로 강건설계

1 이 절에서의 정의는 산업계와 학계에서 일반적으로 통용되는 좁은 의미의 다구찌 방법

을 말한다. ASI (American Supplier Institute)는 다구찌 방법을 robust design과 기존의 설계방법을 포괄적으로 포함한 제품원가 절감을 위한 품질공학(quality engineering)이라

고 정의하고 있다. Robust design은 ASI의 등록 상표이다.

9

(robust design)라고도 불리는 다구찌 방법이다. 다구찌 박사는 1950년대와

1960년대 초에 다구찌 방법의 기초를 만들었으며, 여러 가지 제품의 개발에 이

를 적용함으로써 그 원리의 타당성을 증명하였다. 이 업적에 대한 보답으로

1962년에 다구찌 박사는 품질분야의 가장 권위 있는 상 중 하나인 Deming상

을 수상하였다. 1980년대 이후 AT&T, Ford 자동차 회사, 제록스 사를 포함한

미국의 많은 유수 기업들이 다구찌 방법을 실제 현장문제에 적용하여 제품생산

에 있어서 혁신적인 품질향상의 효과를 얻은 바 있다 (Phadke, 1989).

다구찌 방법은 1920년대 영국의 Ronald Fisher 경이 연구한 ‘통계적 실험계

획법(statistical experimental design)에 기초를 두고 있다. Fisher는 실험계획

법의 기초원리와 더불어 분산분석(Analysis of Variance, ANOVA)이라는 자료

해석법을 수립하였다. 다구찌 방법이 통계적 실험계획법의 기본 원리를 사용하

였기 때문에 이 두 방법은 많은 공통점을 가진다. 그러나 다구찌 방법은 통계적

실험계획법과 비교할 때,

n 능동적인 품질특성 및 S/N비의 선택,

n 분산(variance)의 감소에 대한 강조,

n 제어인자(control factors) 간의 교호작용(interactions) 무시에 따른 효

율성 확보,

n 2 단계 최적화 (2 step optimization)

등으로 대표될 수 있는 많은 차이점을 가지고 있는데, 이는 다구찌 방법이

통계적 실험계획법과 다른 목적을 가지고 있는 점에 기인한다고 알려져 있다.2

다구찌 방법과 통계적 실험계획의 자세한 비교는 Phadke (1989) 의 저서에서

2 실험계획법의 목적이 평균응답과 모델인자의 수준에 대한 수학적 관계를 찾는데 있는

반면, 다구찌 방법은 제품기능의 분산을 줄이는데 그 주된 목적을 둔다. (용어에서도 나타나 있듯이, 전자가 다분히 수학적인 관점을 가지고 있는 반면, 후자는 공학적 혹은 품

질위주의 관점을 가지고 있음을 알 수 있다.)

10

찾을 수 있다.

2.1.1.3 다구찌의 품질개념

종전까지의 품질관리에서는 “주어진 특성이 허용범위 내에 들어가는가, 그렇

지 않은가?”, 또는 “허용범위를 어떻게 선택할 것인가?” 등이 중요한 문제로 인

식되었다. 그러나 다구찌 품질 개념에 의하면 제품의 품질특성(quality

characteristic)이 목표 값(m)과 정확히 같고 제품마다 품질의 편차가 없는 경

우에 손실이 최소 즉, 제로(zero)가 되고 특성이 목표 값에서 벗어나면 그때부

터 손실이 생긴다고 보았다. 품질관리 개념으로 주어진 허용범위를 기준으로 불

량률이 제로라고 해도 다구찌 품질관리 개념으로는 아직도 특성 값이 목표 값

혹은 이상적인 값에 벗어나는 한 손실이 있기 때문에 손실을 줄이기 위한 개선

의 여지가 있는 것이다. Figure 2-1은 기존의 품질개념에 의한 품질손실함수와

다구찌의 품질개념에 의한 품질손실함수를 보여준다.

품질 손실의 원인인 분산을 줄이기 위한 방법에는 다음과 같은 3 가지가 있

다.

n 불량품 선별: 한계 허용차(m±Δ0)를 벗어나는 불량품을 제거하는 방법으

로 비용이 많이 든다.

n 불량원인의 발견과 제거: 이상기능의 원인을 발견하여 제거함으로 품질

의 분산을 줄인다. 이 방법도 역시 상당한 비용을 요구한다.

n 강건설계(다구찌 방법)의 적용: 설계자가 조절 가능한 설계 변수

(parameter) 값을 조정하여 품질특성의 평균값에 대한 분산을 줄이고

(잡음인자에 민감하지 않도록 하고), 평균값 자체도 목표 값에 근접되도

록 유도한다. 가장 비용이 적게 든다.

11

L(y) 품질손실

ymm-∆0 m+∆0

A0

L(y) 품질손실

ymm-∆0 m+∆0

A0

(a) (b)

Figure 2-1 (a) convent ional qual i ty loss funct ion, (b) quadrat ic qual i ty loss

f u n c t i o n o f T a g u c h i

세 번째 강건설계 방법은 허용차(tolerance) 자체를 엄격하게 설정하지않고

도 단순히 설계 변수 값만을 조정 함으로서 품질을 개선할 수 있어, 추가 비용

이 많이 들지 않는 장점도 있다 (Phadke, 1989).

2.1.1.4 잡음인자(noise factor)와 제어인자(control factor)

제어인자(control factor) 는 설계변수 혹은 파라미터(parameter)라고도 하며

설계자가 자유롭게 조절할 수 있는 인자를 말한다. 제어인자는 실험을 통하여

최적 값을 결정하고자 하는 대상이다. 잡음인자(noise factor) 는 설계자가 통제

할 수 없는 인자(uncontrollable factor)이거나, 제어하려면 비용이 많이 드는

인자로, 제품의 품질특성을 목표 값으로부터 벗어나게 하는 원인이다 (Phadke,

1989).

2.1.1.5 품질특성

품질특성은 제품의 품질을 측정할 수 있는 특성 값이다. 품질 특성은 크게

정적특성과 동적특성으로 나누어 진다. 동적특성이란 품질특성(출력)이 입력신

12

호에 대응, 여러 가지로 바뀌는 경우를 말한다. 이에 비해 정적특성은 품질특성

의 목표 값이 어떠한 경우에도 일정한 경우를 말한다. 정적문제는 품질특성의

성질에 따라 주로 다음과 같이 분류된다 (Phadke, 1989).

n 망소특성: 품질특성이 0∼∞ 사이의 임의의 값으로 작을수록 좋은 특성

ex) 마모, 진동, 불량률 등

n 망대특성: 품질특성이 0∼∞ 사이의 임의의 값으로 클수록 좋은 특성

ex) 단면적당 철사의 기계적강도, 자동차가 갖는 단위 연료 당 운행거

리

n 망목특성: 품질특성이 0∼∞ 사이에 한 목표 값에 가까우면 가까울수록

좋은 특성

ex) 여러 공학적 문제에서 목표 두께나 수치, 특정온도

n 백분율특성: 열효율같이 0에서 100%의 값밖에 취하지 않는 특성

위에서 언급한 품질특성의 종류는 정적인 품질특성의 일부이다. 이 밖에도

순차적 범주형, 부호형 등 다양한 정적특성과 본 절에서 소개하지 않은 동적특

성에 대한 분류가 존재한다. 품질특성의 종류에 관한 자세한 내용은 Phadke

(1989), Peace (1993), Ross (1996) 등의 저서를 참고하기 바란다.

13

T a b l e 2-1 T a s k s i n T a g u c h i m e t h o d p r o c e s s

단계 주요 작업 내용

실험 전

n 실험목표 설정

n 품질특성 및 S/N비의 결정

n 실험조건의 결정 및 측정계획

n 제어인자 및 잡음인자 설정

n 행렬실험설계

실험 n 실험 수행

실험 후

n 결과 분석

n 확인 실험

n 후속 조치 계획

2.1.2 다구찌 방법의 수행

다구찌 방법의 수행은 크게 실험 전, 실험, 실험 후의 작업으로 이루어진다.

Table 2-1은 각 단계별 주요 작업내용을 보여준다. 다구찌 방법의 수행에 있어

실험 전 단계에 할 일은 당연히 실험을 준비하는 일이다. 이 단계의 작업을 총

칭하여 보통 ‘실험계획’이라고 한다. 실험계획 단계는 크게 두 부분으로 구분할

수 있다. 첫 번째는 시작에서 행렬실험설계의 직전까지의 부분이고, 두 번째는

행렬실험설계 부분이다. 학자들 중에는 첫 번째 부분을 통칭하여 ‘실험계획’으

로, 두 번째 부분을 ‘실험설계’로 분류하는 경우도 있으며, Table 2-1에 소개한

작업 내용 이외의 것들을 포함시키는 경우도 있다. 학자들 간의 이러한 차이는

다음 절에서 상세히 다루고자 한다 (Phadke, 1989, Peace, 1993).

행렬실험의 설계는 실험에 사용할 직교배열을 선택하고, 직교배열의 각 열에

14

제어인자를 할당하는 작업으로, 이 작업이 완료되어야만 실험회수, 실험일정 등

실험수행의 구체적인 내용이 결정되며, 실험결과 분석을 위한 준비도 이루어질

수 있다. 실험회수는 제어인자의 개수와 각 인자의 수준 수와 관계가 있는데,

다구찌 실험설계자는 Table 2-2를 참고하여 적절한 직교배열을 선택해야 한다.

예를 들어 2 수준 인자가 1 개, 3 수준 인자가 6 개인 경우에는 L18 직교배열

이 가장 적당하다.

Table 2-2 Se l ec t i ng o r t hogona l a r r a y cons ide r i ng t he numbe r o f con t ro l

f a c t o r s a n d t h e i r l e v e l s

수준별 열의 최대수 직교

배열

행수

(실험 수)

최대

인자 수 2 3 4 5

L4

L8

L9

L12

4

8

9

12

3

7

4

11

3

7

11

4

L16

L’16

L18

L25

16

16

18

25

15

5

8

6

15

1

7

5

5

6

L27

L32

L’32

L36

L’36

27

32

32

36

36

13

31

10

23

16

31

1

11

3

13

12

13

9

L50

L54

L64

L’64

L81

50

54

64

64

81

12

26

63

21

40

1

1

63

25

40

21

11

15

T a b l e 2-3 L 1 8 o r t h o g o n a l a r r a y

A B C D E F G H 실험

번호 1 2 3 4 5 6 7 8

1

2

3

4

5

6

1 1 1 1 1 1 1 1

1 1 2 2 2 2 2 2

1 1 3 3 3 3 3 3

1 2 1 1 2 2 3 3

1 2 2 2 3 3 1 1

1 2 3 3 1 1 2 2

7

8

9

10

11

12

1 3 1 2 1 3 2 3

1 3 2 3 2 1 3 1

1 3 3 1 3 2 1 2

2 1 1 3 3 2 2 1

2 1 2 1 1 3 3 2

2 1 3 2 2 1 1 3

13

14

15

16

17

18

2 2 1 2 3 1 3 2

2 2 2 3 1 2 1 3

2 2 3 1 2 3 2 1

2 3 1 3 2 3 1 2

2 3 2 1 3 1 2 3

2 3 3 2 1 2 3 1

Table 2-3은 직교배열의 예로 L18 직교배열 이다. 이 표에서 임의의 두 열

에 있는 수준을 살펴보면, 모든 조합이 존재하며, 각각의 조합이 같은 회수로

나타남을 알 수 있다. 이러한 직교성(orthogonality)은 적은 실험회수로 많은

수의 인자를 연구하는 것을 가능하게 할 뿐 아니라, 결과해석을 간단하게 하며,

가법모델(additive model)의 타당성을 파악할 수 있게 한다.

행렬실험의 설계에는 앞 문단에 간략히 소개된 내용 이외에도, 자유도

(degree of freedom)의 계산, 교호작용(interaction)의 파악, 직교배열의 변형

등의 사항이 고려되어야 한다. 자세한 내용은 Phadke (1989), Peace (1993) ,

Fowlkes (1995) 등의 저서를 참고하기 바란다.

실험에 관한 모든 준비가 끝나면 정해진 실험순서와 반복 수에 따라 실험을

16

수행하며, 결과를 기록한다. 직교배열에 있는 모든 실험은 빠짐없이 수행되어야

하며, 잡음조건을 제외한 모든 실험조건은 동일하게 적용되어야 한다.

실험이 끝나면 분산분석(ANOVA: Analysis of Variance) 등의 방법으로 결

과를 분석하여 최적의 인자조합을 결정한다. 여기서 최적의 인자조합은 최상의

품질특성을 만드는 조합과 반드시 일치하지 않는데, 그 이유는 다구찌 방법의

목적이 일단 품질의 편차(분산)을 줄이는데 있기 때문이다. 최적 인자조합은 확

인실험에 의해 그 타당성이 검증되며, 그 결과에 따라 후속 조치가 마련된다.

한 번의 다구찌 실험을 통해 모든 문제를 해결할 수 없기 때문에 보통 반복적

인 실험이 요구되는 경우가 많다.

2.1.3 다구찌 방법 수행절차의 비교

다구찌 방법을 연구하는 학자들 중 일부는 그들의 저서에서 나름대로의 다

구찌 방법 수행절차를 제안하고 있다. 이들이 제안한 절차는 큰 흐름에 있어서

는 동일하지만, 실험 이전 부분의 작업 내용에 있어서는 약간의 차이를 보이고

있다 (Phadke, 1989; Peace, 1993; Ross, 1996). 본 절에서는 몇 가지 절차를

소개하고, 본 연구에서 모델로 삼은 Peace (1993) 가 제안한 절차가 다른 학자

들의 절차에 비해 부분적으로 우수함을 설명한다.

첫 번째로, Phadke (1983)가 제안한 절차는 실험계획, 실험수행, 결과분석

및 확인의 3 단계로 이루어져 있으며 전체는 Table 2-4와 같이 8 단계로 세분

할 수 있다.

17

T a b l e 2-4 T a g u c h i e x p e r i m e n t p r o c e s s p r o p o s e d b y P h a d k e

수행단계 세부 의사결정 및 작업 내용

1) 실험계획

n 주요기능, 부작용, 기능상실의 유형 등을 정리한

다.

n 품질손실을 평가하기 위해 잡음인자와 시험조건을

결정한다.

n 측정할 품질특성과 최적화 시킬 목적함수를 설정

한다.

n 제어인자와 그 수준을 결정한다.

n 행렬실험을 설계하고 결과분석 과정을 결정한다.

2) 실험수행 n 행렬실험을 실시한다.

3) 실험결과분석

n 실험결과를 분석하여 제어인자의 최적조건을 결정

하고 결과를 추정한다.

n 확인실험을 수행하고 다음 조치를 계획한다.

이 절차에서는 잡음인자를 결정한 이후에 시험조건(실험조건)과 품질특성을

결정하므로 잡음에 강건한 인자를 결정하는데 유리하다는 장점이 있다. 다만 초

기부터 인자를 잡음인자와 제어인자로 구분하므로 설계자가 인자에 대해 선입

관을 가질 소지를 가지고 있으며, 실험전략에 대한 고려가 없다는 단점이 있다.

두 번째로, Ross (1996)가 제안한 절차를 Table 2-5에 나타내었다. 이 절차

는 품질에 영향을 주는 인자를 선정한 후 나중에 제어인자와 잡음인자로 분류

하므로 인자에 대한 선입관을 줄일 수 있다는 장점이 있으나, 측정방법을 결정

한 이 후에 잡음인자가 결정되므로 실험조건의 잡음에 대한 강건성이 부족할

수 있는 단점이 있다. Ross의 절차 역시 실험전략에 대한 고려를 포함하고 있

지 않다.

18

세 번째로, Peace (1993)가 제안한 절차는 Ross의 절차와 유사하지만,

Phadke와 Ross의 절차와는 다른 몇 가지 중요한 특징을 가지고 있다. Table

2-6에 Peace가 제안한 절차를 나타내었으며, 다음 항목들은 이 절차가 다른

학자들이 제안한 절차와 구별되는 점을 설명한 것이다.

n 일단 Peace의 절차는 실험 전(前) 단계를 더 세분화하여 ‘실험계획’ 단

계3와 ‘실험설계’ 단계로 양분하였다. 전자는 행렬실험설계 이전의 작업

을, 후자는 행렬실험설계를 담당한다. 이 세분화는 Peace가 종전까지

간과되었던 실험계획 단계의 중요성을 인식한 결과이며, Peace는 실험

계획 단계의 올바른 의사결정을 지원하기 위해 다음의 두 가지 방안을

제시하였다.

n Peace는 실험 팀(team)의 구성을 통한 실험계획 단계의 공동 의사결정

을 제안하였다. 이는 많은 엔지니어 들이 실험계획의 의사결정에 참여함

으로써 아이디어를 최대한 끌어내고 오류를 최소화하려는 목적을 가지

고 있다.

n Peace는 실험계획 단계의 의사결정에 품질도구의 사용을 제안하였다.

Pareto chart, cause-and-effect diagram, FMEA (Failure Mode and

Effect Analysis) 등의 도구를 사용하여 실험 팀으로부터 수집된 정보를

체계적으로 분석, 효과적인 의사결정지원이 가능하다.

3 본 논문에서 계속 언급되는 ‘실험계획’ 단계는 Peace가 제안한 절차에서의 실험계획

단계로, 행렬실험 전까지의 작업을 포함한다. 본 절에서 Phadke와 Ross가 제안한 절차에서의 ‘실험계획’ 단계는 실험전의 모든 작업을 포함한 것으로 Peace의 절차에서 ‘실험

계획’과 ‘실험설계’ 모두를 의미한다.

19

T a b l e 2-5 T a g u c h i e x p e r i m e n t p r o c e s s p r o p o s e d b y R o s s

수행단계 세부 의사결정 및 작업 내용

계획단계

n 문제 혹은 관심영역의 정의

n 실험 목적의 결정

n 품질특성 및 측정방법의 선택

n 선택된 품질특성에 영향을 미칠 수 있는 인자들을

선정

n 제어인자와 잡음인자로 분류

n 인자들의 수준을 결정

n 직교배열의 선택

n 품질특성에 영향을 미칠 수 있는 교호작용을 선정

n 직교배열에 인자와 교호작용을 배치

실험수행단계 n 직교배열에 정해진대로 실험을 수행

분석단계 n 실험결과의 분석

n 확인실험의 수행

본 연구에서는 이 Peace의 절차를 모델로 선정하였는데, 그 이유는 Peace

의 절차가 실험계획 단계의 중요성을 잘 반영하고 있으며, 이 단계의 의사결정

을 지원하기 위한 방법론을 제시하고 있기 때문이다. 본 연구에서는 실험 팀으

로부터 실험 대상 분야에 대한 지식을 수집하여, 품질도구를 이용 분석, 정리하

여 실험설계자에게 제공함으로써 다구찌 실험계획의 의사결정을 지원하고자 한

다.

20

T a b l e 2-6 T a g u c h i e x p e r i m e n t p r o c e s s p r o p o s e d b y P e a c e

수행단계 세부 의사결정 및 작업 내용

실험계획

n 실험 팀의 구성

n 실험 목적의 결정

n 품질특성의 결정

n 측정방법의 결정

n 독립변수의 결정

n 제어인자와 잡음인자로 분류

n 인자들의 수준을 결정

n 잠재적 교호작용의 파악

n 실험전략의 수립

실험설계

n 자유도(DOF: Degree Of Freedom)의 계산

n 직교배열의 선택

n 인자의 배치

실험수행

n 시험 계획수립

n 실험 준비

n 실험 수행

n 시험 및 검사

결과분석

n 표 및 그래프에 의한 분석

n 인자의 주효과 및 최적인자조합 파악

n 최적조건 예측

n 확인실험의 수행

21

2.2 소프트웨어 에이전트

2.2.1 소프트웨어 에이전트의 정의

소프트웨어 에이전트는 사용자를 위해 어떠한 작업을 대행해주는 컴퓨팅 개

체(computing entity)이다. 학자들에 따라 그 정의와 특징에 다소 차이가 있으

나, 공통적으로 다음과 같은 사항이 에이전트의 주요 특징으로 받아들여지고 있

다 (Caglayan and Harrison, 1997; Wooldridge and Jennings, 1995; Knapik

and Johnson, 1998).

n 위임(delegation): 에이전트는 사용자나 다른 에이전트를 대신하여(위임

받아) 특정한 작업을 수행한다.

n 자율성(autonomy): 에이전트는 스스로 혹은 간단한 지시에 의해 동작한

다. 자율성은 인간과 컴퓨터의 상호작용(CHI: Computer Human

Interactions)에 있어 사용자로 하여금 간접적인 관리(indirect

management)를 가능하게 함으로써 많은 시간과 노력을 절약하게 한다.

n 통신기능(communication skill): 에이전트는 사용자와 혹은 다른 에이전

트와 상호작용을 하는 경우가 있다. 이는 에이전트간의 협동

(collaboration)을 가능하게 하여 그 기능과 효율을 크게 증가시킨다.

n 관찰능력(monitoring): 자율적인 작업수행을 위해 주위 상황을 관찰하는

기능을 가질 수 있다.

n 지능(intelligence): 상황을 해석하고, 수행해야 할 일을 스스로 결정하

는 기능이 필요할 수 있다.

그 밖에도 에이전트는 이동능력(mobility), 보안기능(security), 개별성

(personality) 등의 다른 특성을 가질 수 있다.

소프트웨어 에이전트는 위의 정의와 특징으로부터 유추할 수 있듯 그 범위

22

가 매우 넓다. 또한 그 경계도 분명치 않아 어떤 소프트웨어가 에이전트의 범주

에 포함되는가, 그렇지 않은가는 쉽게 판단할 수 없는 경우가 많다. Caglayan과

Harrison (1997)은 대행성(agency)와 지능(intelligence)를 기준으로 에이전트

의 판정기준을 제시하고 있으나, 그 경계(threshold of intelligent agency) 역시

다분히 주관적이다. Figure 2-2에서 볼 때, 평면의 두 축을 이루는 대행성과 지

능은 원점에서 멀어질수록 그 심도(degree)가 높아지며, 그 두 가지 특성이 어

느 정도 갖추어져 기준을 넘어섰을 때 에이전트의 범주에 포함시킬 수 있음을

알 수 있다. 더불어 원점에서 우측상단으로 멀어질수록 에이전트의 성능이 우수

하며, 반대로 원점에 가까울수록 그 수준은 낮다고 할 수 있다.

처음 에이전트의 개념을 접한 많은 사람들은 지능형 에이전트와 전문가시스

템의 차이를 질문 한다. 전문가시스템도 에이전트와 마찬가지로 인공지능 프로

그램의 한 종류이며, 어떤 의미에서는 사람을 대신하여 문제를 해결한다고 할

수 있기 때문에 그 차이는 상당히 모호하다. Maes (1997) 는 Table 2-7와 같이

주된 사용자와 주로 다루는 문제의 차이로 지능형 에이전트와 전문가시스템을

비교하였다. 에이전트 기술이 최근 인공지능의 적용 대상 분야와 수혜자를 많이

넓히고, 대중화하였다는 결과론에서 볼 때, 이 비교는 타당성이 있다고 판단된

다.

T a b l e 2-7 Compa r i s on b e tween i n t e l l i g e n t a gen t s a nd e xpe r t s y s t ems

주된 사용자 주로 다루는 문제

지능형 에이전트 초보자 일상적이고 쉬운 문제

전문가시스템 전문가 전문적, 고 수준의 문제

23

AgentInteractivity

ServiceInteractivity

ApplicationInteractivity

DataInteractivity

UserRepresentation

Asynchrony

Preference Reasoning Learning

Agency

Intelligence

Threshold of Intelligent AgencyIntelligent Agent

Not Intelligent Agent

F i g u r e 2-2 T h r e s h o l d o f I n t e l l i g e n t A g e n c y

2.2.2 소프트웨어 에이전트의 종류

소프트웨어 에이전트를 분류하는 기준은 크게 세 가지가 있다. 각각의 기준

을 간략히 살펴보고, 각 분류마다 어떤 에이전트가 존재하는지 몇 가지 예를 살

펴보겠다. 첫 번째가 환경(environment)에 의한 분류이다. 에이전트가 동작하는

환경의 특징에 따라 에이전트의 기능적 특징이 일반적으로 달라지기 때문에 이

는 좋은 분류기준이 된다. 동작환경에 따라 에이전트는 흔히, 데스크탑 에이전

트(desktop agent), 인터넷 에이전트, 인트라넷 에이전트, 웹 에이전트 등으로

분류된다.

두 번째로, 작업내용(task)에 의한 분류가 있다. 말 그대로 에이전트가 하는

일에 따른 분류이다. 정보 필터링 에이전트(information filtering agent), 정보추

24

출 에이전트(information retrieval agent), 검색 에이전트(search agent), 통보

에이전트(notification agent) 등이 그 예이다.

세 번째로, 지식구조(architecture)에 의한 분류가 있다. 이것은 작업을 수행

하기 위해 에이전트 내부의 지식이 어떻게 조직화되고 동작하는가에 따른 분류

이다. 학습 에이전트(learning agent), 신경망 에이전트(neural agent) 등의 예

가 있다 (Caglayan and Harrison, 1997).

2.2.3 소프트웨어 에이전트의 이점

에이전트는 사용자를 대신하여 특정한 작업을 수행하기 때문에, 사용자의 시

간과 노력을 절약해 준다. Caglayan과 Harrison (1997)은 에이전트가 수행하는

작업의 종류에 따라 어떠한 이점을 사용자에게 제공하는지 Table 2-8와 같이

분류한다.

T a b l e 2-8 B e n e f i t s o f i n t e l l i g e n t a g e n t

수행작업 분류 이점

자동화(automation) 반복적인 작업을 수행함으로써 생산성을 증대.

맞춤화

(customization)

사용자에게 맞춤 서비스를 제공함으로써 불필요한 노력

을 감소.

통보(notification) 중요한 이벤트(event)를 알려줌으로써 편이를 증대.

학습(learning) 사용자의 행동양식을 학습함으로써 사전 대비책을 마련.

교습(tutoring) 사용자를 상황에 따라 지도하여, 훈련량을 감소.

메시징(messaging) 원거리 작업을 가능하게 한다.

25

2.2.4 에이전트기반 의사결정지원 시스템

소프트웨어 에이전트는 최근 가장 주목 받는 연구분야의 하나로 전산학의

거의 전분야에 걸쳐 활발한 연구가 이루어지고 있다. 본 절에서는 에이전트기반

의사결정지원시스템에 관련된 연구사례를 소개하고자 한다. Wang (1997)은 데

이터마이닝(data mining)과 에이전트 기술을 이용한 의사결정지원시스템을 개발

하였다. 이 연구에서는 분산된 환경에 존재하는 이질적(heterogeneous)인 데이

터베이스 시스템들로부터 데이터를 추출하고 패턴(pattern)을 발견하여 그룹차

원의 의사결정을 지원하기 위해 자바(Java) 기술을 사용하고 있다. 에이전트 기

술의 적용은 데이터마이닝의 효율과 소요되는 노력을 크게 줄여줄 뿐 아니라

그룹간에 지식의 공유를 용이하게 한다는 장점이 있어, 현재도 활발한 연구가

진행되고 있으며 (Rose, 1996; Ekenberg, 1997), 향후 많은 발전 가능성을 가

지고 있다. Bui와 Lee (1999) 는 의사결정지원시스템 개발을 위한 에이전트기반

프레임워크를 제안하여 이 분야에 에이전트의 활용 가능성을 넓혔다. 이들은 의

사결정지원시스템에 이용하기 위한 에이전트의 특성과 행동양식을 언급하고, 이

를 위한 멀티 에이전트 시스템 아키텍쳐를 제안하였다. 이 들의 연구는 지능형

에이전트를 이용하여 정보를 ‘수집’하고 의사결정을 지원한다는 점에서 본 연구

에 중요한 아이디어를 제공하였다.

2.3 인터넷기반 설문조사시스템

2.3.1 인터넷기반 설문조사시스템의 개요

설문조사(survey)는 다수의 사람들로부터 의견을 추출하는데 널리 이용되어

왔다. 설문조사에 이용되는 매체(media)는 꾸준히 발전되어 왔는데 최근에는

종이와 OMR 카드에서 벗어나 인터넷으로까지 그 활용이 확대되고 있다. 즉,

e-mail, WWW (World Wide Web) 등 인터넷을 이용한 설문조사를 인터넷 설문

26

조사 혹은 인터넷기반 설문조사라고 한다. 인터넷 설문조사를 흔히 온라인 설문

조사라고 하는데 온라인 설문조사가 일반전화에 의한 조사, ARS에 의한 조사를

포괄한다는 점에서 보면, 인터넷 설문조사는 온라인 설문조사의 범주에 포함된

다고 볼 수 있다 (Korea Research Center, 1998). Figure 2-3은 웹에서 진행

되고 있는 인터넷 설문의 예를 보여준다.

인터넷 설문조사는 인터넷의 급속한 성장과 더불어 크게 발전하고 있다.

Gartner Group (1997)과 같은 유명한 리서치 기관을 비롯하여 수 많은 조사

기관이 인터넷 설문조사 시스템을 도입하고 있으며, 국내에도 수 십여 개에 달

하는 인터넷 설문조사 기관이 운영되고 있다 (Korea Research Center, 1998;

한국인터넷리서치연구소, 1999).

2.3.2 인터넷기반 설문조사시스템의 장단점

인터넷기반 설문조사는 인터넷이 아닌 다른 매체를 사용하는 설문조사에 비

해 다음과 같은 장점을 갖는다 (Korea Research Center, 1998; 한국인터넷리

서치연구소, 1999).

F i g u r e 2-3 A n e x a m p l e o f i n t e r n e t s u r v e y

27

n 저렴한 조사비용: 대인면접조사에 비해 약 1/10, 전화조사에 비해 약

1/5 정도의 비용으로 조사가 가능하며, 표본의 수가 증가해도 비용이 거

의 증가하지 않는다.

n 조사집단에 접근이 용이: 지역적으로 혹은 시간적으로 접근하기 어려운

집단이나, 일반 조사로 접근하기 어려운 전문가 집단에 대한 접근이 용

이하다.

n 빠른 응답회수 및 결과 분석: 설문 응답을 회수하여 결과를 분석하는 과

정이 모두 컴퓨터에서 이루어지므로 거의 시간이 소요되지 않는다. 설문

응답자는 실시간으로 응답 결과를 볼 수 있다.

n 조사 방법의 다양성: 기존의 단순 나열과 선택에 의한 방법에서 벗어나,

응답자가 다양한 방법으로 설문과 상호작용 할 수 있으며, 자료 제시에

멀티미디어 데이터를 이용할 수 있어 응답자의 설문에 대한 이해를 높

일 수 있다.

단점으로는 인터넷에 접속된 컴퓨터를 사용할 수 있는 사람만을 대상으로

하므로, 매체의 폐쇠성을 들 수 있다. 또한, 일반조사와는 달리 조사기관에서

표본을 선택하는 능력이 제한되어 있어 단시간에 대표성 있는 표본을 추출하기

어려우며, 자료의 정확성도 검증하기 어렵다는 단점도 제기되고 있다. 학자들은

인터넷 설문조사가 아직 도입단계에 있으며, 인터넷의 발전과 일반화에 따라 많

은 문제가 해결될 수 있을 것으로 전망하고 있다.

2.3.3 인터넷기반 설문조사시스템의 개발

인터넷기반 설문조사의 가장 간단한 형태는 전자우편(e-mail)을 이용하는

것이다. ASCII형태로 배포된 e-mail 설문지는 응답자에 의해 역시 ASCII의 형

태로 회신 된다. 이 방법은 설문의 형태가 매우 간략한 형태로 제한되어 있고,

응답 회수 및 분석의 자동화 역시 용이하지 않다 (한국인터넷리서치연구소,

28

1999). 이것을 발전시킨 형태로 ‘disk by e-mail 방법’이 있다. 이것은 전자우

편에 설문프로그램을 첨부하는 형태로, 응답자들이 첨부된 프로그램을 다운로드

한 후, 실행시켜 질문에 응답한 후 다시 발송하는 방법이다. 단순 전자우편 방

법보다 조금 복잡하지만, 설문의 혼합과 문항의 통제 등이 자유로운 장점이 있

다. 이 방법은 파일의 크기와 방화벽에 의해 거부되는 등의 문제가 있기 때문에

그리 많이 사용되지 않는다. HTML을 이용한 설문조사는 전자우편을 이용하는

방법에 비해 사용자 인터페이스가 뛰어나며, 웹의 광범위한 사용에 편승하여 응

답자에게 쉽게 접근할 수 있다는 장점 외에도, 사용자의 DNS 및 IP주소, 사용

브라우저(browser), 운영체제, 설문조사 시작시간, 응답자의 e-mail 등의 부대

정보를 수집할 수 있는 장점을 가진다. HTML기반, 즉 웹 기반 설문조사방법은

CGI (Common Gateway Interface), ASP (Active Server Page), 자바(Java),

ActiveX 등 다양한 기술로 구현될 수 있는데, 최근에는 ASP와 Java를 기반으

로 설문을 생성해 주는 웹 설문 시스템(web survey system)이 많이 사용되고

있다 (한국인터넷리서치연구소, 1999).

Table 2-9는 Watt (1997)가 인터넷기반 설문조사 구현 방법론을 몇 가지

기준에 의해 비교한 결과를 보여준다. 여기서 ‘변환된 CATI’는 본래 stand

alone 환경이나 client/server 환경에서 동작하는 전문 설문조사 프로그램인

CATI (Computer-Assisted Telephone Interviewing: Sawtooth Technologies,

1999)를 웹에서 동작하도록 한 것으로 단순 e-mail 설문의 단점을 어느 정도

극복한 형태이다. ‘변환된 disk-by-mail’ 역시 ‘disk-by-mail 방법’을 웹 환경

으로 옮김으로써 발전을 시도한 것으로 볼 수 있다. 그러나 이 두 가지 방법은

설문 프로그램이 별도로 필요하기 때문에 특정한 설문작성 언어를 사용해야 하

는 등의 제한이 있다. CGI는 웹 서버에서 동작하여 클라이언트에 부담을 주지

않을 뿐 아니라 PERL과 같은 스크립트 언어로 직접 프로그램 될 수 있어 유연

하고, 특정 설문언어 등에 구속되지 않는 장점으로 널리 사용되었다 (Watt,

1997). 그러나 CGI는 매 접속마다 독립 프로세스를 생성하기 때문에 서버에 많

29

은 부담을 줄 소지가 있고, 매번 설문을 만들 때마다 프로그램을 해야 하는 불

편함 때문에 점차 자바나 ASP에 의해 대치되고 있다. 자바 애플릿(applet)이나

ActiveX는 클라이언트에서 대부분의 작업을 수행하므로 서버에 부담을 주지 않

지만, 자바는 속도가 느리고 ActiveX는 브라우저에 제한적이다. 이에 비해

ASP는 Vbscript로 이루어져 작성과 쉬우며, 강력한 확장성과 데이터베이스 연

동능력을 가지고 있다. 더불어 ASP는 서버측에서 작업을 처리하므로 클라이언

트에 부담을 주지 않으며, CGI와는 달리 매 연결마다 별도의 프로세스를 생성

하지 않으므로 서버의 부담도 휠씬 줄여준다 (주병진 외, 1999).

T a b l e 2-9 C o m p a r i n g m e t h o d o l o g i e s i m p l e m e n t i n g I n t e r n e t s u r v e y

평가 기준 E-mail Converted

CATI

Converted

Disk-By-

Mail

Web CGI

Program

Web

Survey

System

작성 및

수정의 용

이성

Excellent Fair Good Poor Excellent

데이터 사

용의

용이성

Poor Fair Good Excellent Excellent

표본할당

통제 Poor Excellent Fair Excellent Excellent

데이터 신

뢰성

확인

Poor Good Good Excellent Excellent

응답자의

관심정도 Excellent Good Good Good Good

설문의 개

인화 Fair Fair Poor Excellent Excellent

설문의 변

환 Fair Excellent Good Good Good

작성자에

게 요구되

는 전문성

Low High Moderate Very High Moderate

30

2.4 상황감지 도움말 시스템

2.4.1 상황감지 도움말 시스템의 개요

상황감지 도움말 시스템(context-sensitive help system)은 특정 응용 프로

그램에 부가된 기능으로 사용자에게 상황에 맞는 유용한 도움말 정보를 제공하

여 응용 프로그램의 사용을 돕는데 목적을 갖는다. 잘 설계된 사용자 인터페이

스(user interface)와 더불어 상황감지 도움말 시스템은 익숙하지 않은 소프트

웨어를 사용하는데 많은 도움을 준다. 상황감지 도움말 시스템의 가까운 예로

‘마이크로소프트 오피스 길잡이’를 들 수 있다. 이 길잡이는 응용 프로그램을

사용하는 도중에 스스로 출현하여 상황에 알맞은 도움말이나 제안사항을 내놓

거나, 사용자의 실수에 대해 경고를 하기도 한다. 길잡이는 움직이는 캐릭터

(character)의 형태로 되어 있는데 이것은 ‘마이크로소프트 에이전트’라는

ActiveX 컨트롤로 구현된 것이다 (Microsoft Press, 1998). Figure 2-4는 마이

크로소프트 길잡이의 동작 예를 보여준다.

F i g u r e 2-4 A n e x a m p l e o f c o n t e x t-s e n s i t i v e h e l p s y s t e m

31

2.4.2절에서는 상황감지 도움말 시스템의 핵심이 되는 상황감지 기술에 대

해 간략히 소개한다.

2.4.2 상황감지 기술의 개요

상황감지는 모든 자율 시스템(autonomous system)에 필수적으로 요구되는

기능이다. 스스로 무엇을 할지를 결정하기 위해서 먼저 주어진 상황을 감지하고

파악해야 함은 당연한 일이다. 올바른 상황감지를 위해서는 먼저 파악하고자 하

는 상황에 대한 정보 수집이 선행되어야 한다. 하드웨어와 연계된 시스템에서는

센서(sensor)가, 소프트웨어 시스템에서는 이벤트(event)의 발생, 데이터베이스

의 갱신(update), 사용자와 응용 프로그램간의 상호작용 등 필요한 모든 정보를

낚아챌 수 있는 메커니즘이 필요하다. 이렇게 수집된 정보는 상황을 저장하고

판단하기에 적합한 데이터 구조에 의해 표현되고 적절한 평가 방법에 의해 특

정 상황으로 정의되어진다. 따라서 상황감지는 크게 다음의 두 가지 문제로 볼

수 있다.

n 상황표현구조(context architecture)를 어떻게 구성하는가?

n 관찰된 상황을 바탕으로 자율 시스템의 행동(behavior)을 어떻게 결정

하는가?

상황표현구조는 도메인의 특성에 따라 현재 상황을 표현하기 적절한 것이어

야 하며, 이로부터 자율 시스템의 행동을 결정하기 위한 작업에 적합한 형태여

야 한다. 예를 들어, 행동결정의 방법이 규칙기반 추론(rule-based reasoning)

인 경우와 신경회로망인 경우 상황표현구조는 확연히 다를 것이다. 이러한 상황

감지 및 대처 모델에 관해서 최근 다양한 연구가 이루어지고 있다. Taboada 등

(1996)은 온라인 능동적 보조 시스템 개발을 위한 계층적 지식구조를 제안하였

으며, 블랙보드(blackboard) 데이터 구조를 이용하여 사용자의 작업 상태와 상

32

호작용 상태를 저장하는 방법을 사용하였다. Turner(1998)는 C-schema라는 상

황표현 방법론을 통하여 자율 에이전트의 상황고려 행동을 설계하였다. Turner

는 이 연구에서 프레임(frame)과 유사한 지식 구조를 사용하였는데, 이 프레임

혹은 객체지향방법은 기호적 지식표현(symbolic knowledge representation)의

대표적인 방법론이다 (Winston, 1992; Badiru, 1992). 국내에서는 박성룡

(1999)이 고속도로의 돌발상황을 신속히 판단하기 위해 신경회로망을 사용한

연구사례가 있다.

33

제 3 장 다구찌 실험계획

본 장에서는 다구찌 방법의 수행 단계 중 본 연구의 대상이 되는 실험계획

단계에 대해 설명하고자 한다. 다구찌 실험계획은 실험 팀의 구성에서, 실험목

표의 설정, 품질특성의 결정, 인자의 선정, 실험전략의 수립 등 실험의 기반이

되는 중요한 의사결정을 포함하고 있다.

3.1 실험 팀의 구성

다구찌 실험설계의 의사결정에 필요한 지식은 크게 다음과 같이 구분 할 수

있다.

n 다구찌 실험 자체에 대한 지식

n 품질을 개선하고자 하는 해당분야에 대한 지식

이 두 종류의 지식을 모두 충분히 가진 사람이 있다면 좋겠지만, 다구찌 실

험 자체에 대해서도 정확한 개념을 가지고 있고, 다구찌 실험을 적용할 수 있는

광범위한 분야에 대해서도 지식을 가진 사람은 현실적으로 존재하기 어렵다. 또

한, 실험을 통하여 품질을 개선시킬 정보를 얻고자 하는 분야에 대해 잘 정리된

지식이 존재하기도 어려울 것이므로, 다구찌 실험설계에서 이용할 해당 분야에

대한 지식이 충분하지 못한 상황은 자주 발생할 것이다. 일반적인 실험에서도

그렇지만 다구찌 실험에서도 실험대상에 대한 불충분한 정보는 실험의 방향설

정에 어려움을 가져와 자원의 낭비를 가져오기 쉽고, 종종 실험의 실패를 야기

한다. 이러한 문제를 해결하고자 Peace (1993)는 실험 팀을 구성하여 해당 분

야에 관련된 다수의 참여자들의 지식을 취합하여 실험설계에 이용하는 방법을

34

제안한 바 있다.

본 연구에서는 다구찌 실험설계의 첫 단계로 Table 3-1과 같이 실험 팀을

구성하도록 하였다. 실험설계자는 다구찌 실험의 모든 의사결정을 행하는 자로,

다구찌 방법과 그 적용 분야 양쪽 모두에 대해 적어도 기본적인 사항을 이해하

고 있는 사람이면 좋다. 지식제공자는 실험 대상분야에 대한 지식을 제공하는

사람으로, 다수의 지식제공자가 그룹을 이루어 실험설계자의 의사결정을 지원하

게 된다. 본 연구에서 지원하는 지식수집 기능은 인터넷을 기반으로 하고 있기

때문에 기업내의 연구개발부서 및 지역을 달리하는 공장이나 생산부서뿐 아니

라 사외(社外)의 연구기관이나 학교에 소속되어있는 전문가들의 의견을 편리하

게 수집할 수 있다. 특히 유사한 업종의 기업들이 기술협조를 위한 공동체를 구

성하는 경우 지식제공자 확보의 가장 바람직한 모델이 될 수 있다.

3.2 품질문제의 인식

다구찌 실험계획에서 문제인식 단계는 해결해야 하는 품질문제가 무엇인가

를 파악하고, 제품이나 공정에 대한 지식을 수집하여 실험의 목표와 품질특성

등 실험의 기반이 되는 사항을 결정하는데 기초가 되는 단계이다.

T a b l e 3-1 O r g a n i z a t i o n o f a n e x p e r i m e n t t e a m

실험 팀 구성원 실험설계 행위

실험설계자(Team leader) 다구찌 실험설계의 모든 의사결정을 행한다.

지식제공자 그룹(Domain

knowledge Provider Group)

실험설계자가 요구하는 사항에 대한 의견을 제

출함으로써 의사결정을 보조한다.

35

많은 경우 실험설계자들은 실험의 목표나 품질특성의 결정을 즉흥적이고 습

관적으로 처리하며, 이러한 작업들에 많은 시간을 투자하지 않는다. 그러나 실

험설계의 초기단계에서의 잘못된 의사결정은 근본적인 문제점을 만들어내는 것

으로, 실험을 비효율적으로 만들어 시간과 비용의 낭비를 초래하는 등 이어지는

실험과정에 지속적인 악영향을 미친다. 따라서 품질문제에 대해 충분한 정보를

수집하고 검토하는 것은 매우 중요한 일이다 (Peace, 1993).

3.3 실험목표의 설정

실험목표의 설정은 다구찌 실험계획의 의사결정 중 첫 번째이자 실험의 성

패를 좌우하는 가장 기본적이고 중요한 작업이다. 부적절한 실험목표가 야기하

는 문제에 대해서는 이미 3.2 절에서 언급한 바 있다. 다음은 실험목표를 설정

하는데 주의해야 할 사항들이다 (Peace, 1993).

n 많은 실험설계자들이 흔히 범하는 실수는 성급한 판단을 하는 것이다.

설계자는 최종적으로 원하는 결과를 목표로 하지 말고, 현실성 있는 목

표를 설정하여야 한다. 무리한 목표설정은 실험을 복잡하게 만들며, 성

공 가능성을 낮춰, 결국 제품이나 공정에 관해 아무런 지식을 얻지 못하

는 결과를 초래할 수 있다.

n 목표는 구체적이어야 한다. 애매한 목표는 얻고자 하는 정보의 초점을

흐리게 하고, 실험의 성패 판단(측정)을 어렵게 한다. 예를 들어, 전자부

품의 조립에서 잦은 결함발생이 문제일 때, 목표를 “결함을 줄이는 것”

으로 하기보다는 “납땜의 부피를 2mg으로 균일하게 유지하는 것”으로

정하는 것이 좋다. 구체적인 목표는 실험설계자로 하여금 구체적인 주제

에 초점을 맞출 수 있게 하며, 문제의 새로운 면을 이해할 수 있는 기회

를 제공한다.

36

n 한 번의 실험에 모든 것을 해결하려는 생각을 버려야 한다. 한 번에 실

현 가능한 단계를 하나씩 밟아 나아가는 것이 좋다. 이어지는 작은 성공

은 다른 기회를 낳고, 미온적이었던 지지자들을 적극적으로 동참하게 만

들 수 있다. 그러나 첫 번째 시도에서의 실패는 더 이상의 응용을 위한

길을 막아버릴 수 있다. 첫 실험에서는 제품이나 공정에 대한 최적인자

의 값을 구하지 못해도 좋다. 첫 실험을 통해 얻어진 유용한 정보들은

다음 실험에서 더 많은 정확한 정보를 얻는데 사용될 수 있다.

3.4 품질특성의 결정

품질특성은 제품의 품질수준을 정량적으로 표시하는 특성 값이며, 다구찌 실

험의 성패를 측정하는 기준이다. 품질특성을 잘못 결정하면 교호작용을 만들어

실험을 복잡하게 만들며 잘못된 결과를 가져오기 쉽다. 다음은 품질특성이 갖추

어야 할 일반적인 조건이다.

n 연속이고, 정량적이고, 측정이 용이해야 한다. 어떠한 품질특성의 정확

한 측정을 위하여 특정한 환경이 필요한데 그 환경을 만들 수 없다면

그 품질특성은 적절한 것이 아니다.

n 절대 영(0)의 값이 존재해야 한다. 즉, 음의 값이 존재하지 않아야 한다.

n 인자들의 영향에 대해 가법성(additivity)이 있거나 최소한 단조성

(monotonicity)이 있어야 한다.

n 완전해야 한다. 즉, 이상적 기능이나 입출력 관계의 모든 부분을 포함해

야 한다.

n 제품 혹은 공정의 기본구조에 따른 에너지 전달(energy transfer)에 직

접적으로 관련된 것이어야 한다.

n 품질특성의 값이 사용자의 허용차나 기대치에 따라 달라져서는 아니 된

37

다. 이 같은 경우 교호작용이 존재할 가능성이 크다.

3.5 측정계획

모든 종류의 실험에 있어서 결과 측정의 중요성은 아무리 강조되어도 지나

치지 않을 것이다. 측정에 대한 완벽한 준비가 이루어지지 않은 경우, 작게는

실험일정의 지체나 필요치 않은 비용의 발생을, 크게는 실험을 통해 잘못된 정

보를 얻는 결과를 불러올 수 있다. 측정계획은 앞으로의 실험수행에 대한 준비

일 뿐 아니라 전 단계에서 결정된 품질특성의 타당성을 평가하는데 있어 중요

한 의미를 가진다. 따라서 측정계획은 품질특성 결정 직후에 이루어져야 한다.

다음은 측정계획에서 일반적으로 고려하는 사항이다.

n 측정장비(보유여부, 정밀도, 신뢰도, 보조도구의 필요유무 등)

n 측정자

n 측정환경

n 시험측정

품질특성을 측정할 적절한 장비나 인력을 보유하고 있지 않은 경우, 실험에

필요한 측정환경을 제어할 수 없는 경우 등에는 부득이하게 품질특성을 재정의

해야 하는 경우도 있을 수 있다. 시험측정은 불필요한 일정지체나 비용낭비 등

을 막기 위해서 꼭 필요한 것으로 다음과 같은 이득을 가져온다.

n 선택된 품질특성과 실제 제품/공정의 성능 사이의 관계를 이해할 수 있

다.

n 품질특성의 측정이 실제로 가능한지, 측정장비가 적절한 정밀도를 가지

고 있는지 등을 알 수 있다.

n 외부 환경에 대한 특정 민감도를 알 수 있다. 즉, 환경에 대한 제어가

38

필요한 가를 파악할 수 있다.

n 고정된 조건에서 측정값의 변동이 심할 경우, 품질특성의 재정의를 고려

할 수 있다.

품질특성이 순차적 범주형(classified attribute)인 경우나 수율(yield)인 경우

에는 보통 주관적인 관측에 의존하는 경우가 많다. 이러한 경우, 사진, 도면, 견

본 등 측정에 시각적으로 도움을 줄 수 있는 보조도구가 필요하다.

3.6 인자의 선정

실험의 목표를 설정하고, 품질특성을 결정하였으면 품질특성에 영향을 미치

는 인자를 선정해야 한다. 일반적으로 인자를 결정하고 적절한 인자 수준을 정

해서 할당하는 것은 실험계획에서 가장 시간이 소요되고 정신적으로 소모적인

부분이다. 실험설계자는 잠재적으로 품질특성에 영향을 미치는 모든 인자에 관

해 조사하도록 습관을 들여야 한다. 이것은 장기적으로 볼 때 바람직한 일이며,

지름길로 가려 한다면 잘못된 결론에 이르기 쉽고, 연구를 반복해야 하는 경우

가 흔히 발생한다. Peace (1993) 는 인자를 선정하는 절차를 다음과 같이 제안

하였다.

n 일단 모든 잠재적인 인자들을 열거한다. 브레인스토밍과 cause-and-

effect diagram을 사용하는 것도 효과적이다.

n 어떤 인자들을 실험에 포함시키고, 어떤 인자들을 추후 고려대상으로 남

겨둘 것인지를 결정한다. 이 때도 실험 팀의 구성원들이 중복된 인자나

비슷한 인자에 대해 논리적인 그룹화를 할 것인지, 또한 어떤 인자가 다

른 인자에 포함될 수 있는 것인지를 신중하게 검토해야 한다.

n 인자를 제어인자와 잡음인자로 분류한다. 제어인자는 값이 설정되고 유

39

지될 수 있는 인자나 그렇게 하기를 원하는 인자이다. 잡음인자는 값이

설정되거나 유지될 수 없는 인자나 그렇게 하기를 원하지 않는 인자이

다.

실험계획의 다른 의사결정도 그렇지만 인자의 설정은 실험 팀의 모든 구성

원들이 동의하는 것이어야 한다. 실험설계자의 독자적인 결정은 실험 팀 구성원

들의 참여 의욕을 저하시키는 원인이 될 수 있다.

3.7 실험전략의 수립

다구찌 실험의 최종목적은 잡음에 강건한 품질을 구현하기 위해 인자의 중

요도와 효과를 알아내는 것이다. 그러나 3.3 절에서도 언급하였듯이 한 번의 실

험을 통하여 모든 인자의 효과를 파악하고 최적인자 조합을 찾아내려는 시도는

무모한 것이다. 중요한 것은 실험을 통하여 정보를 얻어내는 것이다. 무모한 시

도는 시간과 자원을 투자한 실험에서 아무것도 얻어내지 못하는 결과를 불러올

수 있다.

따라서 모든 실험은 현실적인 전략을 토대로 이루어져야 한다. 실험계획 단

계에서 실험의 토대를 수립하고 본격적인 행렬실험으로 돌입하기 전에, 조사된

정보를 바탕으로 실험전략을 세우는 것이 바람직하다. 다음은 몇 가지 대표적인

실험전략의 예이다 (Peace, 1993).

n 한 번의 실험을 통하여 모든 정보를 얻어내고자 하는 단발 실험. 이 경

우 시간과 자원을 아끼지 말고 투자해야 하며, 신중한 검토를 통해 실수

가 발생하지 않도록 해야 한다.

n 실험을 반복하면서 지속적인 품질향상을 도모하는 계속 실험. 초기 실험

에서는 큰 경향을 파악하는데 주력하고, 품질의 허용범위를 점차 줄여나

40

가면서 미세조정을 통하여 최적의 품질을 얻고자 하는 방법이다. 중장기

적인 연구개발에 적합하다.

n 실험을 반복하면서 불필요한 요소를 잘라나가는 가지치기 실험. 고려할

인자의 수가 많은 경우 등에 적합한 방법으로, 품질의 개선이 목적이 아

니라 인자의 중요도 파악이 목적이다.

n 실험을 반복하면서 문제의 초점을 파악해 나가는 실험. 품질문제가 무엇

인지 조차 파악되지 않은 미개척 분야의 연구에 적합하다.

n 계속되는 실험을 통해 여러 가지 문제를 해결해 나아가는 순차 실험. 복

합 제품의 품질 개선에 적합한 방법이다.

41

제 4 장 실험계획 의사결정지원 시나리오의 설계

4.1 의사결정지원 시스템의 개념설계

본 절에서는 먼저 다구찌 실험계획의 의사결정 특징을 분석하여 이에 요구

되는 지식의 종류와 특징에 대해 다루며, 이 지식을 실험설계자에게 전달하는

시나리오를 결정하는 과정을 통해 본 연구의 핵심인 두 가지 지식제공 메커니

즘에 대해 소개한다. 또한 이 두 가지 메커니즘을 포함한 전체 시스템의 구성요

소와 레이아웃에 관해 설명한다.

4.1.1 다구찌 실험계획의 의사결정 특징 분석

다구찌 실험계획의 의사결정의 가장 큰 특징은 두 가지 종류의 지식을 요한

다는 점이다. 일단 다구찌 실험 자체에 관한 지식이 필요하며, 실험대상분야에

대한 지식도 당연히 요구된다. 두 가지 지식 중 전자의 경우 어느 정도 한정된

범위를 가지고 있으므로 규칙과 같은 특정한 지식표현방법으로 저장이 가능하

다. 즉, 지식베이스의 구축이 가능하다는 의미이다. 그러나 후자는 실험이 어떤

것인가에 따라 달라지므로 어떠한 형태로든 정형화하여 저장하는 것은 용이하

지 않다. 이러한 특징은 전문가시스템 기술을 이용한 다구찌 실험계획의 의사결

정을 어렵게 한다. 전문가시스템의 그 광범위한 적용사례에도 다구찌 계획의 의

사결정을 다루는 예가 없다는 사실은 그 적용의 어려움을 단적으로 증명하고

있다. 본 연구에서는 구현자체가 비현실적인 전문가시스템에 의한 의사결정대신,

에이전트기반 의사결정지원 시스템이 인간 실험설계자의 의사결정을 돕는 방법

을 대안으로 채택한다. 의사결정지원 시스템은 다구찌 실험계획에 필요한 두 가

지 지식을 실험설계자에게 제공함으로써 실험설계자의 의사결정을 지원하게 된

다. 4.1.2절에서 의사결정지원 시스템이 이 두 가지 지식을 어떻게 실험설계자

에게 전달하는가를 설명한다.

42

4.1.2 실험계획에 필요한 지식의 전달 방법 설계

4.1.2.1 실험대상 분야의 지식의 전달

먼저 실험대상 분야의 지식을 살펴보자. 실험대상 분야의 지식을 얻는 방법

은 해당분야에 대한 자료를 통한 방법과 해당분야의 전문가 혹은 관련자들로부

터 지식을 추출해내는 방법이 있다. 첫 번째 방법은 실험대상 분야가 어느 정도

연구되어 그에 대한 문서자료가 존재하는 경우에 가능하다. 그러나 실험을 통하

여 정보를 얻으려는 분야인 만큼 충분한 자료가 항상 존재한다고 볼 수는 없을

것이다. 두 번째 방법은 실험대상 분야의 전문가나 해당 분야의 종사자와 같은

지식제공자들이 존재하는 경우에 가능하다. 이 들이 제공하는 지식은 문서자료

에 비해 신뢰성은 떨어지겠지만 잘 수집되고 정리된다면 의사결정에 결정적인

도움이 된다. 특히, 실험계획에 참고할 자료가 존재하지 않는 경우가 빈번한 만

큼 이 들이 제공하는 자료가 유일한 판단 근거로 작용하는 경우가 많다. 2.1.3

절에서 언급하였듯이 Peace는 실험 팀을 구성하고 여러 가지 품질도구를 이용

하여 이 들의 지식을 체계적으로 수집하고 분석하는 방법을 제안하였다. 본 연

구에서는 의사결정지원 시스템 내에 ‘도메인 지식제공 메커니즘’을 두어 지식제

공자들로부터 지식을 수집하고 분석하여 실험설계자에게 제공하는 작업을 수행

하도록 하였다.

4.1.2.2 다구찌 실험에 관한 지식의 전달

다음으로 다구찌 실험에 관한 지식을 살펴보겠다. 다구찌 실험계획의 결정사

항의 종류나 절차에 관한 지식은 잘 설계된 사용자 인터페이스로 쉽게 전달할

수 있다. 본 연구에서는 마법사 형태의 사용자 인터페이스를 이용하여 실험설계

자가 무엇을 어떠한 순서로 결정해야 하는지 직관적으로 알 수 있도록 배려하

였다. 그러나 실제 다구찌 실험계획에서 주의해야 할 사항이나 지켜야 할 지침

43

등은 사용자 인터페이스 만으로는 전달할 수 없다. 또한 다구찌 실험에 관한 지

식이 양적으로도 적지 않은 만큼 실험설계자가 필요로 하는 지식을 적절한 시

기에 제공하는 일도 용이한 일은 아니다. 본 연구에서는 의사결정지원 시스템

내에 ‘상황감지 도움말 메커니즘’을 두어 실험설계자와 사용자 인터페이스의 상

호작용을 관찰하여 도움이 필요할 시 적절한 도움말을 제공하도록 하였다.

4.1.3 의사결정지원시스템의 전체 레이아웃 설계

Figure 4-1은 본 연구에서 제안한 다구찌 실험계획을 위한 의사결정 프레임

워크 이다. 그림에서 볼 수 있듯이 프레임워크는 크게 5 개의 요소로 이루어져

있으며 그 기능은 다음과 같다.

n 실험설계자: 다구찌 실험계획의 모든 의사결정을 행하는 자로 실험 팀의

리더이다.

n 지식제공자: 실험대상분야 종사자로서 실험 팀의 구성원이다. 요청이 있

을 때 지식을 제공한다.

n 에이전트 기반 의사결정지원 시스템: 두 가지 방법으로 실험설계자의 의

사결정을 지원한다. 첫째는 지식제공자들로부터 실험대상분야의 지식을

수집하여 실험설계자에게 제공하는 방법이고, 둘째는 실험설계자의 실험

계획행위를 관찰하여 적절한 다구찌 방법에 대한 지식을 제공하는 방법

이다.

n 사용자 인터페이스: 단순히 실험계획의 내용을 입력하고 계획완료 시 문

서로 출력하는 기능을 한다.

n 웹 서버: 지식수집 및 보고에 이용되는 웹 문서를 담는다.

44

Web Server

Decision-Supporting System

Context-Sensitive Advice Mechanism

AdvisorAgent

AdviceRepositoryU

ser Interface

Advice

ExperimentDesigner

KnowledgeGathering

Configuration

KnowledgeProviders

Response

Domain Knowledge Providing Mechanism

CollectorAgent

ReporterAgent

CollectedKnowledge

InteractiveQuestionnaire

Page

DynamicWeb Report

Planning

ExperimentPlan

Document

DomainKnowledge

KnowledgeRequest

Observedactivities

Figure 4-1 The framework for decision makings i n T a g u c h i experiment

p l a n n i n g

이들 중 본 연구의 핵심인 의사결정지원 시스템은 4.1.2절에서 언급하였듯

이 두 개의 에이전트기반 메커니즘으로 이루어져 있다. 4.2절과 4.3절에서 각

메커니즘에 대해 자세히 설명한다.

45

4.2 도메인 지식제공 메커니즘

4.2.1 도메인 지식제공 메커니즘의 개요

이 메커니즘의 목적은 다수의 지식제공자들로부터 실험설계자가 원하는 정

보를 수집하여 실험설계자에게 제공하는 것이다. 다구찌 실험계획의 의사결정에

이용되는 지식은 절대적인 법칙이나 증명된 지식이 아닐 수 있다. 오히려 실험

을 통하여 정보를 얻으려는 분야인 만큼 전문가의 경험이나 감각에 의존한 지

식일 경우가 많을 것이다. 전문가들마다 경험과 생각이 다르므로 그 들이 가지

고 있는 지식에도 분명 차이가 있을 수 밖에 없다. 그렇다면, 한 두 명의 전문

가로부터 얻은 지식보다는 가능하다면 다수로부터 얻은 지식으로부터 공통분모

를 찾아내는 것이 더 올바른 의사결정에 도움이 될 것이다. 앞서 수 차례 언급

한 바와 같이 Peace (1993) 는 실험 팀 구성을 통하여 다수의 의견을 모으고

품질도구를 이용한 분석으로 의사결정에 참고가 되는 정보를 만드는 방법을 제

안한 바 있다. 그러나 각자 업무가 있는 많은 사람들을 같은 시간, 같은 장소에

모으는 데는 많은 어려움이 따른다. 또한 많은 사람들로부터 지식을 수집하고

분석하여 의사결정에 도움이 될 만한 정보로 가공하는 것도 많은 시간과 노력

을 요하는 일이다. 본 연구에서는 이러한 문제점 들을 해결하고자 인터넷 환경

에서 동작하는 수집 에이전트와 보고 에이전트로 이루어진 도메인 지식제공 메

커니즘을 설계하였다. 각 에이전트의 구성을 Figure 4-2와 Figure 4-3에 각각

도시한다.

4.2.2 도메인 지식제공 메커니즘의 세부동작

도메인 지식제공 메커니즘은 수집 에이전트를 이용하여 실험설계자가 알고

자 하는 지식을 지식제공자들로부터 수집하고, 보고 에이전트를 이용하여 이를

가시화하여 실험설계자에게 제공한다. 실험설계자는 실험계획의 의사결정을 위

해 도메인 지식이 필요할 때마다 지식제공 메커니즘을 가동시켜 해당 지식에

46

대한 지식제공자들의 의견이 종합된 보고서를 얻을 수 있다. 이제 이 두 에이전

트를 통하여 도메인 지식제공 메커니즘이 어떻게 동작하는지 한다. 먼저 수집

에이전트의 작업 절차는 다음과 같다.

Collector Agent

User Interface

QuestionnaireBuilder

CollectingProgressMonitor

E-MailSender

ExperimentDesigner

Web Server

KnowledgeProviderGroup

QuestionConfiguration

CollectedKnowledge

InteractiveQuestionnaire

Page

F i g u r e 4-2 T h e s t r u c t u r e o f c o l l e c t o r a g e n t

47

Reporter Agent

Data Retriever

ReportBuilder

E-MailSender

ExperimentDesigner

Web Server Notification

DynamicWeb Report

CollectedKnowledge

F i g u r e 4-3 T h e s t r u c t u r e o f r e p o r t e r a g e n t

n 질문설정: 실험설계자는 지식을 얻기 위해 지식제공자들에게 던질 질문

과 응답의 형태를 설정한다. 예를 들어, “병 뚜껑 누수의 가장 큰 원인

은 무엇인가?”와 같은 질문을 보기선택형(multiple choice)으로 던질 수

있다. 실험설계자는 질문과 응답의 형태와 더불어 지식수집의 종료조건

과 보고서 작성형식에 대해서도 설정 해주어야 한다. Table 4-1에 본

연구에서 지원 가능한 질문의 형태와 응답의 설정사항을 참고로 나타내

었다. Figure 4-4는 질문설정을 위한 수집 에이전트의 사용자 인터페이

스의 일부이다.

n 질문배포: 수집 에이전트는 설정된 질문을 분산된 지식제공자들에게 배

포하기 위해 대화식 질문내용이 담긴 대화형 웹 페이지를 생성한다. 또

한 지식제공자들에게 e-mail을 보내 질문에 답해 줄 것을 요청한다.

48

n 질문응답: 지식제공자들은 대화형 웹 페이지에 접근하여 질문에 응답한

다. 지식제공자들이 Outlook Express와 같은 메일 클라이언트 프로그램

(mail client program)을 사용하고 있다면 e-mail에 있는 하이퍼링크를

통해 쉽게 웹 페이지에 접근할 수 있을 것이다. 각각의 응답 들은 지식

저장소에 저장되며, 응답 진행 상황이 관찰된다.

n 응답종료: 응답은 위의 질문설정 단계에서 미리 정해진 종료조건을 만족

할 때 까지 계속된다. 종료조건은 종료시간이나 종료응답률 등으로 설정

할 수 있다. 응답이 종료되면 수집 에이전트는 보고 에이전트를 호출하

여 실험설계자에게 제공할 보고서를 작성하도록 한다.

수집된 지식을 실험설계자에게 제공하기 위해서는 적절한 형태로 정리되고

가시화되어야 한다. 보고 에이전트는 다음과 같은 과정을 거쳐 보고서를 생성하

여 실험설계자에게 제공한다.

n 응답추출: 보고 에이전트는 지식저장소 데이터베이스에 접근하여 해당

지식제공 세션에 대한 응답들을 추출한다.

n 보고서 생성: 추출된 응답들을 정리하고 미리 설정된 형식에 따라 가시

화하여 보고서를 생성한다. 본 연구에서는 수집된 도메인 지식의 가시화

방법으로 히스토그램(histogram), 파레토 차트(Pareto chart), 파이 차트

(pie chart)의 세 가지를 지원한다

n 보고서 제출: 보고 에이전트는 보고서가 완성되는 즉시 실험설계자에게

e-mail을 보내 이 사실을 통보한다. 실험설계자는 e-mail에 포함된 하

이퍼링크를 통하여 보고서에 접근할 수 있다.

49

T a b l e 4-1 Q u e s t i o n t y p e s a n d o p t i o n s s u p p o r t e d i n t h i s r e s e a r c h

질문형태 선택사항

보기선택형 다중선택 허용

신규 사항추가 허용

기입형 단어 혹은 구

문단

배열형 항목별 중요도 배정

선택 및 배열

4.2.3 도메인 지식제공 메커니즘의 이점

도메인 지식제공 메커니즘은 인터넷을 기반으로 하고 있으므로, 넓은 지역에

분산되어 있거나, 시간적으로 한 곳에 모여 회의를 갖기 어려운 지식제공자들을

단일한 실험 팀으로 조직하여 지식을 제공할 수 있도록 유용한 환경을 제공한

다.

F i g u r e 4-4 A p a r t o f u s e r i n t e r f a c e f o r q u e s t i o n c o n f i g u r a t i o n

50

4.3 상황감지 도움말제공 메커니즘

4.3.1 상황감지 도움말제공 메커니즘의 개요

다구찌 실험계획은 크게 7 개의 영역으로 이루어져 있으며, 세부적으로는

수 십 개의 개별적인 의사결정을 포함하고 있다(본 연구에서는 Peace가 제안한

절차를 참고하였으며, 학자들에 따라 다구찌 실험설계절차는 다소 다를 수 있

다). 다구찌 실험계획의 의사결정 영역은 나름대로의 목적과 특징 및 주의할 점

들을 가지고 있다. 이러한 특징을 고려하여 올바른 의사결정을 하려면 다구찌

방법에 대해 잘 이해하고 있어야 함은 물론이다. 그러나 앞서 언급했듯이 초심

자는 지식의 부족으로, 경험자는 성급함으로 종종 의사결정의 실수를 범하곤 한

다. 그렇다고 매 실험계획 때마다 다구찌 방법에 대한 공부를 선행할 수는 없는

일이다. 우리는 실험설계자에게 다구찌 방법에 대한 지식을 효과적으로 제공하

기 위하여 필요한 시점에 필요한 다구찌 지식을 제공하도록 이른바 상황감지

도움말 메커니즘을 구현하였다.

상황감지 도움말 기술은 사용자와 인터페이스와의 상호작용을 관찰하여 사

용자의 상태를 파악하는데 그 핵심이 있다고 할 수 있다. 본 연구에서는 2.4.2

절에서 언급한 바와 같이 Turner (1998)의 C-schema 개념과 Taboada (1996)

등의 블랙보드 데이터 구조의 개념을 참고하여 context의 구조를 설계하였다.

그럼 이제 상황감지 도움말 메커니즘이 실험설계자의 행위를 어떻게 관찰하고

해석하여 도움말을 생성해 내는지 설명하겠다. 상황감지 메커니즘은 도움말 에

이전트와 도움말 저장소(advice repository)로 구성되어 있다. Figure 4-5에 도

움말 에이전트의 구조를 도시한다.

51

Advisor Agent

User Interface

Observer

User's Activity

Translator

AdviceGeneratorRulebase

AdviceRepository

Context Memory

Event Log

F i g u r e 4-5 T h e s t r u c t u r e o f a d v i s o r a g e n t

4.3.2 상황의 표현

상황을 파악하는 것은 일종의 진단이다 (Turner, 1998). 실험설계자가 처한

상황을 진단하고 적절한 도움말을 제공하기 위해서는 우선 그 상황을 적절히

표현해야 한다. 본 연구에서는 Table 4-2와 같이 context를 구성하였다. 실험

설계자 관련 항목은 실험설계자가 실험계획의 어떤 단계에서 어떤 증상을 보이

고 있는가 하는 상황과 더불어 실험설계자의 다구찌 실험계획 능력을 표시한다.

예를 들어, ‘실험설계능력지수가 30인 실험설계자가 현재 품질문제인식 단계에

서 성급한 의사결정을 하고 있으며 그로 인한 도움말 필요지수가 60이다’와 같

은 내용이 있을 수 있다. 실험계획 관련 항목에는 실험계획의 각 단계별 진척상

황 및 도메인 지식제공 메커니즘의 사용기록 등이 포함된다. 실험계획의 진행상

황은 실험설계자의 상황을 판단하는 데 중요한 근거가 된다. 이것은, 예를 들어,

실험계획이 거의 완료된 상황에서 실험목표를 수정하는 등의 행위에 대해 경고

52

하려면 실험계획의 진척도에 관한 정보가 필요하기 때문이다. 또한 도메인 지식

제공 메커니즘의 사용기록은 실험설계자가 독단적이고 성급한 의사결정을 했는

지 판단하는 자료로 사용된다. Figure 4-6은 추론을 위해 CLIPS 형식으로 변환

된 context의 예이다.

4.3.3 상황 파악 및 행동 결정

Figure 4-5에서 볼 수 있듯이 상황감지 도움말 메커니즘은 크게 도움말 에

이전트와 도움말 저장소로 이루어져 있다. 도움말 에이전트는 다음과 같은 일련

의 과정을 통해 실험설계자에게 시의 적절한 도움말을 제공한다.

T a b l e 4-2 T h e s t r u c t u r e o f c o n t e x t

분류 항목 속성

증상(Symptom)

명칭(Name)

도움말 필요지수

(DOA: Demand On Advice)

현단계(Current step) 명칭(Name)

시작시점(Start time)

실험설계자

관련 항목

실험설계능력

(Planning ability) 지수(Value)

계획진행(Planning progress)

단계(Step name)

시작시점(Start time)

상태(Status)

실험설계

관련 항목

DKPM 사용기록

(DKPM use record)

명칭(Name)

사용단계(Step)

시작시점(Start time)

종료시점(End time)

53

n 사용자와 인터페이스의 상호작용 관찰: 도움말 에이전트는 사용자(실험

설계자)와 사용자 인터페이스와의 상호작용을 이벤트 로그(event log)에

저장한다.

n Context 메모리 갱신: 이벤트 로그에 저장된 이벤트 목록과 context 메

모리에 있는 내용을 바탕으로 현재 상황을 파악하여 context 메모리에

갱신한다. 도움말 에이전트의 규칙 베이스에는 실험설계자와 인터페이스

의 상호작용과 현재 상황을 해석하여 실험설계자의 상태로 변환하는 지

식이 포함되어 있다.

;;--------------------------------------------------------------------- ;; Features for experiment designer ;;--------------------------------------------------------------------- (symptom (name "LackOfKnowledge:DeterminingQualityCharacteristic") (DOA 40)) (symptom (name "HasteInDecision:DeterminingQualityCharacteristic") (DOA 74)) (currentStep (name "DeterminingQualityCharacteristic") (startTime "2000-06-02 PM 9:22:06")) (planningAbility (value 75)) ;;--------------------------------------------------------------------- ;; Features for experiment plan ;;--------------------------------------------------------------------- (planningProgress (stepName "RecognizingQualityProblem") (startTime "2000-05-29 AM 11:23:12") (status "finished")) (planningProgress (stepName "DeterminingExpObjective") (startTime "2000-06-01 PM 8:03:34") (status "finished")) (planningProgress (stepName "DeterminingQualityChracteristic") (startTime "2000-06-01 PM 8:12:40") (status "planning")) (planningProgress (stepName "SelectingFactors") (startTime "") (status "notStarted")) (planningProgress (stepName "DeterminingExpStrategy") (startTime "") (status "notStarted")) (DKPMRecord (stepName "RecognizingQualityProblem") (startDate "2000-05-29 AM 11:24:22") (endDate "2000-05-30 PM 2:03:55")) ;;---------------------------------------------------------------------

F i g u r e 4-6 A n e x a m p l e o f c o n t e x t f o r t h e c u r r e n t s i t u a t i o n

54

n Context의 평가: 갱신된 context를 평가하여 실험설계자에게 도움말을

제시할 필요가 있는지, 만일 그렇다면 어떤 도움말을 제시할지를 결정한

다.

n 도움말의 생성과 제공: 도움말 저장소에서 적절한 도움말 들을 추출하여

실험설계자에게 제공한다.

도움말 에이전트의 작업 cycle은 실험설계자와 사용자 인터페이스간의 상호

작용을 관찰하는 데서 시작한다. GUI 환경에서 사용자가 발생시킬 수 있는 이

벤트는 수백 가지에 이른다. 이러한 모든 이벤트를 발생될 때 마다 기록하는 것

은 기억공간과 효율의 낭비이므로, 도움말 에이전트는 미리 정의된 실험설계자

의 행동 패턴과 관계된 이벤트만을 가려서 이벤트 로그에 저장한다. 본 연구에

서는 이벤트 로그에 queue의 자료구조를 이용하여 가장 최근의 100개만을 저

장하도록 하였는데, 이는 기억공간의 낭비를 막고 실험설계자의 설계행위를 관

찰하는데 적절하다고 고려된 크기이다.

이벤트 로그에 이벤트가 들어올 때마다 도움말 에이전트는 context 메모리

에 있는 내용과 이벤트 로그를 바탕으로 context를 갱신한다. 예를 들어,

Figure 4-6의 context 예와 같이 ‘품질특성결정’ 단계를 진행하던 중에 이벤트

로그에 ‘실험목표결정’ 단계로 이동했다는 이벤트가 들어오면 도움말 에이전트

는 실험목표결정이 지식이 부족한 상태에서 성급하게 이루어졌다는 판단으로

관련 규칙에 의해 ‘실험목표결정’ 단계에 대한 지식부족증상에 대한 도움말요구

지수를 30, 졸속의사결정증상에 대해 해당 지수를 30 증가시킬 수 있다. 즉

Figure 4-6의 context 중 실험설계자 항목이 Figure 4-7과 같이 갱신되게 된

다.

Figure 4-6과 Figure 4-7의 context 예에서 알 수 있듯이, 사실상 본 연구

에서 설계한 context는 실험설계자가 어떤 도움말을 필요로 하는 상황인지를

55

직관적으로 나타내고 있다. 도움말 에이전트는 간단한 수치 비교를 통하여 도움

말을 제공할 것인지, 아니면 도움말을 제공하지 않고 작업 cycle을 마칠 것인지

를 결정한다. Figure 4-8에 본 연구에서 사용한 도움말 제공여부 판단 근거를

도식적으로 나타내었다. Figure 4-8의 (a)는 도움말필요지수를 평면상의 한 축

에, 100에서 실험설계능력지수를 뺀 ‘미숙정도’를 한 축으로 설정했을 때 도움

말 제공에 해당하는 영역을 표시하고 있다. 이 그림은 실험설계능력지수가 낮을

수록 도움말필요지수가 더 낮은 증상에 대한 도움말의 제공을 허용하는 것을

나타낸다. 즉, 실험설계능력지수가 낮을수록 더 많은 경우에 도움말을 제공 받

게 되는 것이다. 실험설계능력지수는 실험설계자 자신이 실험계획의 초기에 설

정한다. Figure 4-8의 (b)는 실험설계자가 ‘도움말경계’를 통하여 도움말제공전

략을 설정할 수 있음을 나타낸다. ‘도움말경계’를 오목하게, 혹은 볼록하게 함으

로써 도움말제공의 민감도를 조절할 수 있다. 즉, ‘도움말경계’를 볼록하게 만들

면 도움말 제공에 해당하는 영역이 줄어들기 때문에 도움말기능이 사용자의 행

위에 덜 민감하게 동작하고, 오목하게 만들면 더 민감하게 동작하는 것이다.

이와 같은 과정을 통하여 실험설계자에게 제공할 도움말과 제공여부가 결정

되면 도움말 에이전트는 도움말저장소로부터 도움말을 추출하여 실험설계자에

게 제공한다. 본 연구에서는 다구찌 실험계획의 6 단계 의사결정과정에서 유의

해야 할 30 여 가지 경우에 대한 도움말을 도움말 저장소에 구축하였다.

56

;;---------------------------------------------------------------------

;; Features for experiment designer

;;---------------------------------------------------------------------

(symptom (name "LackOfKnowledge:DeterminingExpObjective") (DOA 30))

(symptom (name "LackOfKnowledge:DeterminingExpObjective")

(DOA 30))

(symptom (name "LackOfKnowledge:DeterminingQualityCharacteristic")

(DOA 40))

(symptom (name "HasteInDecision:DeterminingQualityCharacteristic")

(DOA 74))

(currentStep (name "DeterminingExpObjective")

(startTime "2000-06-02 PM 9:25:34"))

F i g u r e 4-7 T h e c o n t e x t u p d a t e d f r o m F i g u r e 3-6

100

100

x: DOA (Demand On Advice)y: Novice-hood = (100 - Planning ability)

x

y Area ofAdvice

Threshold ofAdvice

100

100x

yLess Sensitive

Normal

More Sensitive

(a) (b)

F i g u r e 4-8 T h e t h r e s h o l d o f a d v i c e

57

제 5 장 실험계획 의사결정지원 시스템의 구현

본 장에서는 다구찌 실험계획 의사결정지원 시스템의 구현에 관해 기술한다.

5.1 절에서는 UML (Unified Modeling Language)을 이용한 시스템의 설계에

관하여, 5.2 절에서는 프로토타입 시스템의 개발도구에 관하여 설명한다.

5.1 UML을 이용한 응용프로그램 설계

5.1.1 절에서는 UML의 개요에 관하여, 5.1.2 절에서는 UML을 이용하여

ADTEP을 설계하는 과정에 대해 간략히 기술한다.

5.1.1 UML (Unified Modeling Language)의 개요

UML (Unified Modeling Language)은 객체지향 시스템의 개발 중에 생기는

산출물들을 명세화, 시각화, 문서화하는데 사용되는 언어이다. UML은 객체지향

시스템에 대한 효과적인 비주얼 모델링을 가능하게 한다. 비주얼 모델링(visual

modeling)이란 복잡하고 개념적인 시스템과 그 주변의 요소들을 모델(model)을

이용하여 이해하는 방법이다. 모델은 복잡한 것을 조직화(organize), 시각화

(visualize)하여 문제를 이해하고 해결방안을 생성하는데 도움을 준다. 모델은

프로젝트와 관련된 모든 사람들과의 의사소통, 기업의 모델링, 문서화 준비, 프

로그램과 데이터베이스 등을 설계하는데 매우 유용하다. 모델링은 요구사항을

보다 깊게 이해하게 하고, 명확한 설계를 도와 유지보수가 쉬운 시스템의 구축

을 가능하게 한다 (Schmuller, 1999; Sturm, 1999; Conallen, 1999; Quatrani,

2000).

58

5.1.1.1 UML의 출현 배경

소프트웨어 기술이 발전하고, 소프트웨어의 기능과 규모가 방대해질수록 효

과적이고 표준화된 설계 및 개발의 방법론이 요구된다. 소프트웨어 공학자들은

복잡한 소프트웨어를 설계하고, 개발 프로젝트를 관리하는데 편리한 방법론을

발전시켜 왔다 (최영근 외, 1995; 최은만, 1996). 예를 들어, 가장 기본적인 흐

름도(flow chart), 의사코드(pseudo code)에서부터 자료흐름도(data flow

diagram), IDEF 시리즈에 이르기 까지 수 많은 소프트웨어 설계의 방법론이 개

발되었고, 지금도 많은 방법론들이 개발되고, 개선되고 있다 (왕창종, 1998).

객체지향(object orientation)의 개념이 나온 이후로 소프트웨어 공학은 객체

지향을 중심으로 발전하여 왔다. 특히 Grady Booch, James Rumbaugh, 그리고

Ivar Jacobson은 1980년대 전반부터 1990년대 초반까지 객체지향 분석설계 분

야의 트로이카로써 각자의 독자적인 방법론을 발전시켜왔다. Rumbaugh의

OMT, Booch의 Booch, Jacobson의 OOSE는 각기 고유의 장점들을 가지고 있

었으나 어느 하나도 나머지 둘을 압도할만한 장점을 가지지는 못하였다. 1990

년대 중반 이 세 사람은 아이디어를 교환하기 시작하였으며, Rational Software

Corporation을 설립하면서 결국 각자의 방법을 모아 하나로 합치기에 이른다.

1995년 10월 UML의 초안이 공개된 이래, 일반 대중으로부터의 피드백

(feedback)과 보안을 거쳤으며, 1997년 UML은 OMG (Object Management

Group)에 제출되어 표준 모델링 언어로 채택되기에 이른다 (Schmuller, 1999;

Sturm, 1999; Conallen, 1999; Quatrani, 2000).

OMG에는 Microsoft, IBM, Computer Associates, Oracle, Sun, Compaq 등

거의 모든 큰 소프트웨어 회사들이 회원으로 참여하고 있다. 이러한 강력한 산

업 연합을 통해 UML은 산업 표준으로 받아들여지고 구현되었다는 점은 UML

자체의 우수성과 더불어 1990년대 후반부터 현재에 이르기까지 UML이 가장

널리 사용되는 객체지향 표준 모델링 언어가 되는데 결정적인 작용을 했다고

볼 수 있다.

59

5.1.1.2 UML의 과정

UML 과정은 반복적이며 점증적인 개발을 지향한다. 즉, 비즈니스 모델링,

요구사항 분석, 설계, 구현 등의 모든 절차를 반복적으로 수행하면서 위험요소

를 완화시켜 프로젝트의 완성에 이르게 되는 것이다. UML은 이러한 과정 중에

개발 팀의 의사소통을 위한 표준적인 모델의 역할을 하게 된다. Rational

Unified Process (RUP) 는 반복적, 점증적 개발과정의 제어를 위한 지침으로,

프로젝트를 시간적 차원과 프로세스적 차원으로 고려한다. 우선 프로젝트를 시

간적인 측면으로 보면 다음과 같은 단계로 나눌 수 있다 (Quatrani, 2000).

n 도입(inception): 프로젝트의 비전을 명시

n 구체화(elaboration): 필요한 활동과 자원을 계획하고 시스템 아키텍쳐

를 설계

n 구축(construction): 일련의 점증적 반복과정으로 제품을 생성

n 전이(transition): 사용자에게 제품을 인도(제조, 배달, 교육)

반면에 프로젝트를 프로세스 측면에서 보면 다음과 같은 활동으로 구성할

수 있다.

n 비즈니스 모델링: 대상 시스템의 능력과 사용자 요구 식별

n 요구사항: 기능 및 비기능적 요구사항의 집합과 함께 시스템 비전의 서

술

n 분석 및 설계: 구현 단계에서 어떻게 시스템이 실체화될 것인가를 기술

n 구현: 실행 가능한 시스템을 만드는 코드의 생산

n 테스트: 전체 시스템의 검증

60

n 배치: 시스템의 인도 및 고객에 대한 사용자 교육

본 논문에서는 UML의 개괄적인 내용만을 소개한다. UML에 대한 자세한 사

항은 Schmuller (1999), Sturm (1999), Conallen (1999), Quatrani (2000) 등의

저서나 Rational사의 홈페이지(http://www.rational.com)를 참고하기 바란다.

본 연구에서는 간소화된 RUP를 이용하여 UML기반의 설계를 수행하였다.

5.1.1.3 UML을 구성하는 다이어그램의 종류

UML을 기본적으로 구성하는 것은 사물(things)과 관계(relationships)이다.

사물은 응용 프로그램 도메인에 있는 모든 개념적으로 물리적인 요소들을, 관계

는 사물들간의 연결을 의미한다. 이 기본적인 두 가지 요소는 다음과 같은 몇

가지 UML 다이어그램을 통해 표현된다 (Sturm, 1999).

n 유스케이스(use case) 다이어그램

n 상호작용(interaction) 다이어그램 (시퀀스 다이어그램, 협력 다이어그

램)

n 클래스(class) 다이어그램

n 액티비티(activity) 다이어그램

61

F i g u r e 5-1 A n e x a m p l e o f u s e c a s e d i a g r a m

유스케이스 다이어그램은 시스템과 상호작용을 하는 액터(actor)와 액터가

시스템과 상호적용을 통하여 사용하는 기능인 유스케이스들로 이루어지는데, 액

터는 사람모양의 도형으로, 유스케이스는 타원형으로 표기된다. 이 다이어그램

을 통하여 설계자는 사용자의 입장에서 시스템이 하는 일, 즉 시스템의 기능을

명시할 수 있다. 유스케이스는 시작과 종료가 분명한 하나의 단위기능을 표현해

야 하며, 액터에게 의미 있는 값을 전달해야 한다. Figure 5-1은 유스케이스 다

이어그램의 예를 보여준다.

상호작용 다이어그램은 시스템을 동적으로 볼 수 있도록 하기 위해 시스템

에 있는 객체나 사물들이 다른 것들과 어떻게 상호작용 하는가를 중점적으로

보여준다. 상호작용 다이어그램에는 다음과 같은 두 가지가 있다.

n 시퀀스(sequence) 다이어그램

n 협력(collaboration) 다이어그램

62

시퀀스 다이어그램은 시간적인 순서로 나열된 객체간의 상호작용을 나타낸

다. 이 다이어그램은 특정한 기능을 수행하기 위한 시나리오를 통해 객체간에

메시지(message)를 교환하는 순서를 묘사한다. 시퀀스 다이어그램에서 수직 점

선은 시간의 흐름을 나타내고, 화살표는 객체간에 주고 받는 메시지를 나타낸다.

협력 다이어그램은 시나리오를 표현하는 또 다른 방법으로, 시간의 흐름보다는

객체간의 연결을 중점적으로 묘사한다. 협력 다이어그램은 시퀀스 다이어그램과

완전히 동일한 정보를 표현하는데, 전자는 시간적인 순서를, 후자는 시나리오의

큰 그림을 파악하는데 적합하다. Figure 5-2와 Figure 5-3에 시퀀스 다이어그

램과 협력 다이어그램의 예를 각각 나타낸다.

F i g u r e 5-2 A n e x a m p l e o f s e q u e n c e d i a g r a m

63

F i g u r e 5-3 A n e x a m p l e o f c o l l a b o r a t i o n d i a g r a m

클래스 다이어그램은 시스템을 구성하는 객체(object), 혹은 객체의 템플릿

(template)이라 할 수 있는 클래스(class)와 객체간의 혹은 클래스간의 관계를

보여준다. 클래스는 애트리뷰트(attribute)와 오퍼레이션(operation)4으로 이루어

지는데, 각각은 클래스의 정보와 행동을 나타낸다. Figure 5-4는 클래스의 예를

보여준다. 그림의 사각형들 중 상단은 클래스의 이름을, 중단에 ‘-‘가 붙은 항

목들은 애트리뷰트를, 하단에 ‘+’가 붙은 항목들은 오퍼레이션을 나타낸다.

Figure 5-5는 클래스 다이어그램의 예로, 클래스들간의 관계(relationship)와

다중성(multiplicity)이 표시된 모습을 보여준다. 다중성은 객체들간의 수적인 관

계를 나타내는데, 어떤 객체에 연결되어 있는 객체의 수를 표기한 것이다.

4 애트리뷰트(attribute)와 오퍼레이션(operation)은 UML에서 사용하는 용어이다. 일반

적인 객체지향 프로그래밍에서는 애트리뷰트를 속성(property) 혹은 데이터 멤버(data member)라고 하며, 오퍼레이션을 메소드(method) 혹은 멤버함수(member function)이

라고 한다. 명칭은 다르지만

64

F i g u r e 5-4 A n e x a m p l e o f a c l a s s

F i g u r e 5-5 A n e x a m p l e o f c l a s s d i a g r a m

액티비티 다이어그램은 시스템의 워크플로우(workflow)를 보여주기 위한 플

로우 차트(flow chart)이다. 이 다이어그램은 시스템내의 액티비티와 액티비티

간의 제어의 흐름을 보여주며, 어떤 액티비티들이 병렬로 수행될 수 있는지 등

65

을 보여준다. 액티비티 다이어그램은 하나의 유스케이스 내의 작업 흐름을 표현

할 수도 있고, 하나의 오퍼레이션의 작업 흐름을 표현할 수도 있다. Figure 5-6

에 액티비티 다이어그램을 예시한다.

Enter Answer to Survey

Submit or Cancel?

Validate

Valid?

Store Answer

[ Yes ]

[ No ][ Submit ]

[ Cancel ]

F i g u r e 5-6 A n e x a m p l e o f a c t i v i t y d i a g r a m

66

5.1.2 UML을 이용한 시스템의 설계

본 절에서는 UML을 이용하여, 즉 간소화된 RUP (Rational Unified

Process)를 사용하여 ADTEP을 설계하는 과정을 기술한다. ADTEP의 전체

UML 다이어그램의 수가 수 십여 개에 이르고, 관련된 문서 또한 방대한 내용

이므로, 본 절에서는 이 중 일부만을 예시하여 설계과정을 간략히 소개하고자

한다.

5.1.2.1 유스케이스 만들기

유스케이스 모델링은 사용자측면에서 시스템의 기능을 파악하고자 유스케이

스 다이어그램을 만드는 과정이다. 먼저 제 3 장에서 기술한 시스템의 개념설

계와 시나리오를 바탕으로 다음과 같이 액터를 결정하였다.

n 실험설계자(experiment designer): 다구찌 실험계획의 모든 의사결정을

행하는 자로 실험 팀의 리더이다. 실험설계자는 실험을 계획하는 일 이

외에도 설문(survey)을 작성하거나, 완료된 설문결과를 확인할 수 있으

며, 실험계획을 인쇄할 수 있다. 지식제공자 그룹을 관리하거나 시스템

에 대한 선택사항을 변경하는 일도 실험설계자가 하는 일이다.

n 지식제공자(knowledge provider): 실험대상분야 종사자로서 실험 팀의

구성원이다. 지식제공자는 설문에 응답하거나, 완료된 설문결과를 확인

할 수 있으며, 실험계획의 진행상황을 웹을 통하여 열람할 수 있다.

n 수집 에이전트(collector agent): 지식제공자들로부터 실험대상분야의 지

식을 수집하기 위해 만들어진 설문을 배포하며, 설문의 진행상황을 주기

적으로 파악하여 설문의 종료를 알려준다.

n 보고 에이전트(reporter agent): 완료된 설문의 응답내용을 데이터베이

스로부터 추출, 정리하여 보고서를 작성하여 실험설계자에게 제공한다.

67

n 도움말 에이전트(advice agent): 실험설계자의 실험계획행위를 관찰하여

실험설계자의 상태를 파악하여 적절한 도움말을 제공한다.

위와 같이 액터들이 결정되면 분석을 통하여 각각의 액터들이 나름대로의

역할을 수행하기위해서 시스템에 어떠한 기능이 필요한지를 결정해야 한다. 예

를 들어, 실험설계자의 경우 시스템에 다음과 같은 기능을 요구한다.

n 새로운 실험 생성

n 실험계획 수행

n 새로운 설문 생성

n 설문의 결과 확인

n 실험계획을 프린터로 인쇄

n 시스템의 선택사항 설정

Figure 5-7은 이러한 기능들을 유스케이스로 정의하여 관계를 설정한 유스

케이스 다이어그램이다. 화살표는 실험설계자(experiment designer)가 각각의

유스케이스들로 표현된 기능을 사용한다는 의미이며, “<< extend >>”는 ‘새로운

설문 생성’이나 ‘설문의 결과 확인’이 실험계획을 수행하는 기능에서 확장된 것

임을 의미한다. 즉, ‘새로운 설문 생성’은 ‘실험계획 수행’을 하는 중에만 사용할

수 있는 기능으로, ‘실험계획 수행’의 기능을 확장하는 것이다. Figure 5-8은 시

스템의 모든 유스케이스를 포함하는 메인 유스케이스 다이어그램이다.

68

Create New Experiment

Create New Survey

Print Experiment Plan

Plan Experiment

<<extend>>

Review Survey Result

<<extend>>

Set Up Options

ExperimentDesigner

F i g u r e 5-7 U s e c a s e d i a g r a m f o r e x p e r i m e n t d e s i g n e r

69

Collector Agent

Create New Survey

<<communicate>>

Monitor Survey Progress

Review Survey Result

Answer to Survey

Distribute Survey

Create New Experiment

Plan Experiment

<<extend>>

<<extend>>

Print Experiment Plan

Set Up Options

Reporter Agent

<<communicate>>

KnowledgeProvider

<<communicate>>

ExperimentDesigner

Report Survey Result

<<communicate>>

<<communicate>>

Observe and AdviseAdvisor Agent

F i g u r e 5-8 M a i n u s e c a s e d i a g r a m

이 유스케이스 다이어그램을 통하여 시스템이 가져야 할 기능과 액터들과의

관계가 정리된다. 이제 한 단계 구체적인 설계를 위해 각각의 유스케이스들이

어떠한 세부 과정을 통하여 기능을 수행하는지를 정의할 필요가 있다. Table

5-1은 ‘새로운 실험 생성’ 유스케이스의 이벤트 플로우를 문서화한 것이다.

70

T a b l e 5-1 E v e n t f l o w o f t h e u s e c a s e : ‘C r e a t e N e w E x p e r i m e n t’

USE CASE: Create New Experiment

Overview 이 Use Case의 목적은 새로운 실험을 만드는 것이다.

Primary Actor Experiment Designer

Secondary Actor 없음

Starting Point Actor가 새 Experiment의 생성을 요구할 때

End Point Actor가 Experiment의 생성을 완료하거나 취소할 때

Measurable

Result 새로운 Experiment가 생성된다.

Flow of Events

n System이 Actor에게 새 Experiment에 대한 정보입력을

요구.

n Actor는 정보를 입력하고 새 Experiment 생성을 승인하

거나 취소할 수 있다.

n Actor가 새 Experiment의 생성을 승인하면 새

Experiment가 추가되고 Experiment List가 갱신된다.

Alternative Flow

of Events

n Actor가 field에 부적절한 값(중복되는 값 등)을 입력하면

System은 적절한 값을 입력할 것을 다시 요구한다.

Use Case

Extensions 없음

Outstanding

Issues 없음

71

Validate Information

Enter Elementary Information

Submit or Cancel?

[ Submit ]

[ Cancel ]

Valid?

Store New Experiment

[ Yes ]

Update Experiment List

Error Message

F i g u r e 5-9 Ac t i v i t y d i ag ram fo r t he use case : ‘Create New Exper iment’

Table 5-1의 내용을 살펴보면 시작시점과 종료시점을 비롯하여, 상세한 흐

름과 예외적인 상황, 가시적인 결과 등 유스케이스의 모든 것을 상세히 문서화

하고 있다는 것을 알 수 있다. 이와 같은 양식의 유스케이스 이벤트 플로우 문

72

서는 시스템의 모든 유스케이스에 대하여 작성되어야 한다.

Figure 5-9는 Table 5-1의 작업흐름을 액티비티 다이어그램으로 표현한 것

이다. 액티비티 다이어그램은 작업 흐름을 시각적으로 보여줄 뿐 아니라, 병렬

적으로 수행해야 할 작업과 선택적으로 수행되어야 할 작업을 알기 쉽게 표현

해준다.

5.1.2.2 클래스 찾기

객체는 응용 프로그램에서 잘 정의된 의미와 경계선을 갖는 개념적인 것, 추

상적인 것, 혹은 실체적인 것이다. 시스템의 각 객체는 상태(state), 행동

(behavior), 신원(identity)의 세 가지 특성을 갖는다. 클래스는 객체를 생성하

기 위한 템플릿이며, 객체는 어떤 클래스의 인스턴스(instance)이다. 본 절에서

는 5.1.2.1 절을 통하여 정의된 시스템의 기능을 구체화하기 위해 필요한 클래

스를 정의하는 과정에 대해 기술한다.

클래스를 찾는 정형화된 방법은 존재하지 않는다. RUP (Rational Unified

Process)에서는 클래스를 이미 정의한 유스케이스와 이벤트 플로우 등의 문서

에 언급된 ‘명사(名詞)’들 중에서 다음과 같은 세 가지로 나누어 찾는 것을 권

하고 있다.

n 실체 클래스(entity class): 지속적으로 존재하는 정보와 그에 관련된 행

동을 모델링 한다. 실세계의 실체를 추상화 하므로 흔히 도메인 클래스

라고도 불린다.

n 경계 클래스(boundary class): 시스템의 주위환경과 시스템 내부간의 통

신을 담당한다. 사용자 또는 다른 시스템에 대한 인터페이스를 담당한다.

n 제어 클래스(control class): 하나 이상의 특정한 유스케이스의 이벤트

플로우를 모델링 한다. 제어 클래스가 유스케이스를 실행시킨다고 생각

73

할 수 있다.

RUP에서는 위의 세 가지 클래스를 각각 다른 아이콘으로 구분하고 있다.

Figure 5-10에 실체 클래스, 경계 클래스, 제어 클래스를 나타내는 세 가지 아

이콘을 도시하였다.

패키지(package)는 서로 관련된 클래스들의 집합으로, 클래스를 효과적으로

관리하기 위해 만들어진다. 본 연구에서는 다음과 같이 패키지를 구성하였다.

n Experiment Info: 실험계획과 관련된 패키지로 실험계획 자체를 담는

실체 클래스 한 개와, 실험의 생성과 실험계획의 수행을 각각 담당하는

제어 클래스 두 개로 이루어져 있다.

n Survey Info: 설문과 관련된 패키지로 설문과 응답을 담는 실체 클래스

들과 설문의 생성과 응답을 수행하는 제어 클래스들로 이루어져 있다.

n Advice Info: 도움말에 관련된 패키지로 도움말을 담는 실체 클래스와

도움말을 관리하는 제어 클래스로 이루어져 있다.

n Interface: 시스템의 모든 사용자 인터페이스, 즉 경계 클래스를 포함한

다.

n People Info: 사람에 관한 패키지로 지식제공자와 실험설계자를 나타내

는 실체 클래스로 이루어져 있다.

n Application: 메인 프로그램의 실행을 담당하는 두 개의 제어 클래스를

포함한다.

74

Answer MainForm OptionSettingManager

Entity Boundary Control

F i g u r e 5-10 I c o n s r e p r e s e n t i n g 3 t y p e s o f c l a s s

Figure 5-11은 위에서 소개한 패키지에 의사결정지원 시스템을 구성하는 모

든 클래스를 배치한 모습을 보여준다. 그림에 있는 Rational Rose는 UML 설계

를 위해 널리 사용되는 도구로 Rational사의 제품이다. 본 논문의 모든 다이어

그램은 Rational Rose를 사용하여 제작한 것이다.

75

F i g u r e 5-11 S i x p a c k a g e s a n d i n c l u d i n g c l a s s e s

5.1.2.3 객체간 상호작용 찾기

유스케이스 다이어그램은 시스템의 외부적 관점을 나타낸다. 유스케이스의

상세한 기능은 이벤트 플로우에 명시되어 있다. 본 절에서는 5.1.2.2 절에서 찾

76

아낸 클래스 혹은 객체들이 유스케이스로 표현된 시스템의 기능을 구현하기 위

해 어떻게 상호작용 하는가를 정의하고자 한다. 이 객체들간의 상호작용은 시퀀

스 다이어그램과 협력 다이어그램으로 표현할 수 있다. 이 다이어그램들을 통해

객체간에 주고 받는 메시지를 알 수 있으며, 이 메시지들은 객체의 행동, 즉 객

첵의 오퍼레이션을 설정하는데 중요한 역할을 한다.

Figure 5-12에 ‘Answer to Survey’ 유스케이스에 해당하는 협력 다이어그

램을, Figure 5-13에 ‘Create New Survey’ 유스케이스에 해당하는 시퀀스 다

이어그램을 각각 나타낸다.

: Knowledge Provider

: AnsweringForm

: Survey

: AnsweringManager

: Answer

1: access

2: get survey info

3: get survey info

4: display

5: submit answer

6: store answer

7: store answer

8: close

F i g u r e 5-12 Col laborat ion d iagram for the use case: ‘Answer to Su rvey’

77

: E

xper

imen

tD

esig

ner

: P

lanE

xper

imen

tFor

m :

Cre

ateN

ewS

urve

yFor

m :

Sur

veyC

reat

ingM

anag

er :

Sur

vey

: C

olle

ctor

Age

nt :

Sur

veyU

seR

ecor

d

requ

est t

o cr

eate

new

sur

vey

disp

lay

set n

ew s

urve

y in

fo

subm

itst

ore

new

sur

vey

stor

e ne

w s

urve

y stra

t sur

vey

hide

upda

te S

urve

yUse

Rec

ord

F i g u r e 5-13 Sequence d i ag ram fo r t he u se case : ‘Crea te New Su rvey’

78

5.1.2.4 관계의 설정

유스케이스, 즉 시스템의 기능은 객체들간의 관계에 의해 구현(realization)

된다. 다시 말해서 관계는 객체간의 상호작용에 대한 통로를 제공하는 것이다.

관계에는 연관(association)과 집합(aggregation)의 두 가지가 있다. 연관은 양

방향적 의미의 연결이며 데이터는 연관을 통해 양방향으로 흐를 수 있다. 연관

은 관계의 이름이나 역할이름(role name)에 의해 그 성격이 구체적으로 명시되

며, 다중성(multiplicity)에 의해 관계하는 객체의 수가 제한된다. 집합은 전체와

부분의 관계로 연관의 특수한 형태로 볼 수 있다. 집합은 “~의 부분(part of)”

또는 포함으로 표현된다. 이 밖에 반사(reflective) 관계가 있는데 이것은 같은

클래스내의 객체들간의 관계를 나타낸다.

AnsweringForm

(from Interface)

Answer

(from Survey Info)

Survey

(from Survey Info)

0..n

1

0..n

1

AnsweringManager

(from Survey Info)

+Manager

1

1

1

1

F i g u r e 5-14 C l a s s d i a g r a m f o r t h e u s e c a s e : ‘A n s w e r t o S u r v e y ’

79

Figure 5-14는 ‘Answer to Survey’ 유스케이스와 관련된 객체들간의 관계

를 나타내는 클래스 다이어그램이다. 이 다이어그램에는 모든 연관관계에 대한

관계이름이나 역할 등이 표시되어 있지 않은데, 이것은 다이어그램을 간략하게

하기 위해 표시하지 않아도 알 수 있는 관계나 역할은 보통 표시하지 않기 때

문이다.

5.1.2.5 구조와 행동의 표현

클래스의 구조는 애트리뷰트에 의해 묘사된다. 애트리뷰트는 클래스가 추상

화하고 있는 실체나 개념에 대한 정보를 표현한다. 클래스의 행동은 오퍼레이션

으로 정의되는데, 이것은 클래스가 추상화하고 있는 실체나 개념의 기능을 묘사

한다. 객체지향 프로그램에서 클래스의 구조와 행동을 정의하는 것, 즉 애트리

뷰트와 오퍼레이션을 정의하는 것은 응용 프로그램의 설계가 마무리 단계로 접

어들었음을 의미한다. 일반적으로 애트리뷰트와 오퍼레이션을 정의할 때는 각각

의 의미가 충분히 전달되는 단어나 구(phrase)를 사용해야 하며, 동일한 스타일

가이드를 사용해야 한다. 본 연구에서는 소문자로 시작하여 모든 단어를 공백

없이 붙여 쓰며, 각 단어의 첫 글자를 대문자로 쓰는 가장 일반적인 방법을 사

용하였다.

Figure 5-15은 Rational Rose를 이용하여 ‘Answer’ 클래스에 애트리뷰트와

오퍼레이션을 정의한 예이다.

5.1.2.6 객체의 행동 분석

유스케이스와 이벤트 플로우는 시스템의 객체간 상호작용을 기술하는 방법

을 제공한다. 클래스 다이어그램은 객체의 구조와 행동, 그리고 관계를 명시한

다. 객체의 내부 행동변화나 상태변화는 어떻게 기술하고 분석할 것인가에 대한

대답은 상태차트(statechart) 다이어그램이 가지고 있다. 상태차트 다이어그램

80

은 한 객체의 상태, 상태의 전이, 상태 변화로 일어나는 액션 등을 표시한다.

상태차트 다이어그램은 시스템의 모든 클래스에 대해 만들 필요는 없으며, 상태

변화를 파악할 필요가 있는 클래스에 대해서만 만들면 된다.

Figure 5-16은 시스템의 전체 흐름을 제어하는 ‘MainProgramManager’ 클

래스의 상태차트 다이어그램이다.

F i g u r e 5-15 A t t r i b u t e s a n d o p e r a t i o n s o f t h e c l a s s : ‘A n s w e r ’

81

Main

Experiment Planning

Set Up Options

Knowledge Provider Group Management

Initialization

Create Survey

Review Survey Result

Termination

F i g u r e 5-16 S t a t echa r t d i ag r am fo r t h e c l a s s : ‘Ma inP rog ramManage r’

5.1.2.7 반복과정 실행 및 마무리

5.1.2.1 절에서 5.1.2.6 절까지의 시스템 설계 과정은 단발로 완성되는 것이

아니라 반복과정을 통하여 개선되는 것이다. 반복적인 분석과 수정을 통하여 위

험요소를 줄이고, 개발과 유지보수가 용이한 시스템 설계의 구축이 가능하기 때

문이다.

지금까지의 과정을 통하여 시스템 설계에 필요한 모든 다이어그램과 관련문

서가 완성되었으며, 본 연구에서는 이들을 바탕으로 의사결정지원 시스템을 구

현 하였다. 이 설계안은 다소의 개선점과, 더 상세화 시킬 수 있는 여지를 가지

고 있지만, UML 설계의 상세화 정도나 형식은 설계자의 재량으로 결정하는 것

이며, 프로토타입 시스템의 개발이란 점을 감안하여 더 이상의 최적화를 진행하

지 않았음을 밝힌다.

82

5.2 프로토타입 시스템의 개발

다음은 본 연구에서는 다구찌 실험계획의 의사결정지원 시스템의 프로토타

입을 개발한 도구와 개발환경이다.

n Application design: Rational Rose 2000

n Operating system: MS Windows NT 4.0.

n Web server: MS Internet Information Server 4.0.

n Web browser: MS Internet Explorer 5.0.

n Agent implementation: MS Visual Basic 6.0, MS Visual C++ 6.0.

n Communication between agents: COM/DCOM.

n Dynamic generation of interactive web page and report: MS Active

Server Page (ASP) 2.0.

n User interface: MS Visual InterDev 6.0 and MS Visual Basic 6.0.

n Knowledge storage: MS SQL Server 7.0.

5.3 시스템의 동작

본 절에서는 개발된 프로토타입 시스템의 사용자 인터페이스 소개를 통하여

시스템의 동작이 어떻게 진행되는지 기술하고자 한다.

Figure 5-17은 본 연구에서 개발된 시스템의 메인 프로그램으로 처음 시작

시 볼 수 있는 인터페이스이다. 실험설계자는 기존에 계획이 진행 중인 실험을

불러내거나 새로운 실험을 생성할 수 있다. 일단 계획을 수행하고자 하는 실험

이 선택 혹은 생성되면 Figure 5-18의 화면으로 이동하여 본격적인 실험계획을

진행시키게 된다. 실험계획에는 마법사 형태의 사용자 인터페이스를 도입하여

순차적으로 실험계획의 의사결정을 진행하도록 하였다.

83

F i g u r e 5-17 M a i n p r o g r a m o f e x p e r i m e n t p l a n n i n g

F i g u r e 5-18 Exper iment p lanning wizard 1 of 6 � Forming Exper iment Team

84

Figure 5-18은 실험계획의 단계 중 ‘실험 팀의 구성’을 위한 사용자 인터페

이스이다. 이미 ‘지식제공자 그룹’에 등록된 사람들 중, 해당 실험에서 필요로

하는 사람들을 ‘실험 팀’에 포함시키거나 제외시킬 수 있다.

Figure 5-19은 다음 단계인 ‘품질문제 인식’을 위한 사용자 인터페이스이다.

실험설계자는 보통 ‘도메인 지식제공 메커니즘’ 등을 통하여 얻어진 지식을 바

탕으로 품질문제에 대한 기술을 하게 된다.

F i g u r e 5-19 Exper iment planning wizard 2 of 6 � Ident i fy ing Qual i ty Problem

85

Figure 5-20 Expe r imen t p l ann i ng w i za rd 3 o f 6 � Determin ing Exper iment

O b j e c t i v e

Figure 5-20은 ‘실험목표의 결정’을 위한 사용자 인터페이스로, 역시 ‘도메

인 지식제공 메커니즘’ 등을 통하여 결정된 실험의 목표를 기술하는 부분이다.

86

Figure 5-21 Exper iment planning w i z a r d 4 o f 6 � Determining Quality

C h a r a c t e r i s t i c

Figure 5-21은 ‘품질특성의 결정’을 위한 사용자 인터페이스로, 측정계획에

해당하는 부분을 포함하고 있다. 품질특성 및 그 유형과 관련하여 적절한 측정

계획은 반드시 필요하다. 이 단계는 ‘상황감지 도움말 메커니즘’이 가장 많이

작동되는 단계이기도 한데, 그 이유는 품질특성의 결정과 측정계획에서 주로 다

구찌 방법에 대한 지식부족이나 이해부족으로 인한 실수가 많이 발생하기 때문

이다.

87

Figure 5-22 Expe r imen t p l ann i ng w i za rd 5 o f 6 � Select ing Contro l/Noise

F a c t o r s

Figure 5-22는 ‘인자선정’을 위한 사용자 인터페이스로 3개의 리스트와 이

동 버튼으로 이루어져 있다. 실험설계자는 일단 왼쪽의 리스트에 품질특성에 영

향을 주는 인자들을 수집하고, 이를 제어인자와 잡음인자로 분리하게 된다.

88

Figure 5-23 Expe r imen t p l ann i ng w i za rd 6 o f 6 � Determin ing Exper iment

S t r a t e g y

Figure 5-23은 ‘실험전략 수립’을 위한 사용자 인터페이스이다. 실험설계자

는 단발 실험으로 모든 것을 결정할 것인지, 계속되는 실험을 통하여 미세조정

을 해 나아가는 전략을 선택할 것인지 등의 실험전략을 선택하게 된다.

Figure 5-18에서 Figure 5-23까지의 6 개의 그림은 실험계획을 위한 사용

자 인터페이스이다. 실험설계자는 순차적으로 의사결정을 진행시키다가 ‘도메인

지식제공 메커니즘’ 등을 이용하거나 의사결정을 보류할 시, 우측하단의 ‘Save

& Suspend ’ 단추로 실험계획을 잠시 멈출 수 있다. 또한 하단에서 두 번째 위

치한 ‘Give Me Domain Knowledge’ 단추를 누르면 ‘도메인 지식제공 메커니

즘’을 이용할 수 있는데 이 메커니즘의 동작을 위한 사용자 인터페이스를 아래

소개한다.

89

F i g u r e 5-24 Ma in i n t e r f ace fo r Doma in Know ledge P rov id i ng Mechan i sm

Figure 5-24는 도메인 지식제공 메커니즘의 메인 화면이다. 실험설계자는

기존에 만들어진 설문의 결과를 확인하거나 새로운 설문을 생성하여 지식제공

자들에게 배포할 수 있다.

Figure 5-25 Use r i n t e r f ace fo r C rea te new su r vey 1 o f 4 � Ente r Survey

I n f o r m a t i o n

90

Figure 5-25는 새로운 설문을 생성하기 위한 사용자 인터페이스 중 일부이

다. 실험설계자는 시작/종료 일시, 종료조건, 질문기술과 같은 기본적인 사항을

설정한다.

F igu re 5-26 User interface for Create new survey 2 of 4 � Select Survey Type

F igu re 5-27 User interface for Create new survey 3 of 4 � Enter Option Items

91

Figure 5-26은 새로운 설문 생성의 다음 단계로 질문의 형태를 설정하는,

Figure 5-27은 질문이 항목을 선택하는 종류일 때, 항목들을 삽입/제거 할 수

있는 사용자 인터페이스이다.

Figure 5-28은 새로운 설문 생성의 마지막 단계로 보고서의 형태를 설정하

는 사용자 인터페이스이다.

F igu re 5-28 User in ter face for Create new survey 4 of 4 � Select Report Type

92

F i g u r e 5-29 A n e x a m p l e o f n e w l y g e n e r a t e d s u r v e y

Figure 5-29는 Figure 5-25에서 Figure 5-28까지의 4 단계를 통하여 생성

된 설문의 예이다. 지식제공자들은 이 설문에 응답을 함으로써 실험설계자의 의

사결정에 도움을 줄 수 있는 지식을 제공하게 된다.

93

F i g u r e 5-30 A n e x a m p l e o f r e p o r t f o r s u r v e y r e s u l t

Figure 5-30은 설문의 결과가 보고서로 생성된 예이다. 실험설계자나 지식

제공자들은 설문이나 보고서의 실험제목 (밑줄 부분)을 클릭하여 현재 진행되고

있는 실험계획 상황을 확인할 수 있다. 이는 웹을 통하여 실험 팀 내의 효과적

94

인 실험계획 정보 공유를 구현한 것이라 할 수 있다.

F i g u r e 5-31 A n e x a m p l e o f c u r r e n t e x p e r i m e n t p l a n

95

F i g u r e 5-32 U s e r i n t e r f a c e o f a d v i s o r a g e n t

96

F i g u r e 5-33 Adv i so r agen t g i ves adv ice a f te r a few add i t i ona l ques t ions

Figure 5-32와 Figure 5-33은 도움말 에이전트의 동작 예로, 전자는 실험

계획 도중에 출현하여 직접 도움말을 제공하고 있는 모습을, 후자는 몇 가지 부

가 질문 후에 상황에 맞는 도움말을 제공하고 있는 모습을 보여주고 있다.

97

제 6 장 사례연구

의사결정지원시스템의 성능을 정량적으로 평가하는 것은 그리 용이한 일이

아니다. 본 연구에서는 몇 가지 사례연구를 통하여 시스템의 유효성을 평가하고

자 한다. 본 장에서 소개하는 사례연구들은 다구찌 실험의 전(全)단계를 포함하

고 있지는 않는데, 이는 실험의 모든 사항을 기술하는 것이 양적으로 방대하여

사례연구에서는 본 연구에서 개발된 시스템이 사용된 부분만을 (다시 말해서

시스템의 효용성을 평가할 수 있는 부분만을) 기술했기 때문이다. 아울러 본 논

문에서 예시한 사례는 그 최종결과가 모두 성공적인 것은 아니며, 단지 실험계

획 도중 실험설계자의 의사결정에 도움이 되는 것이었음을 아울러 밝히는 바이

다.

6.1 사례연구 (1) - 용접봉의 다발압출공정 최적화

본 사례연구에서는 용접봉의 다발압출공정 최적화를 위한 다구찌 실험계획

중 전통적인 인터뷰를 이용한 결과와 본 연구에서 개발한 도메인 지식제공 메

커니즘을 이용한 결과를 비교하여 이 메커니즘의 유효성을 평가하고자 한다.

6.1.1 압출 가공의 개요

압출(押出)은 Figure 6-1과 같이 가열한 재료를 금형 속에서 압축하여 금형

의 구멍을 통하여 재료가 빠져 나오게 하여 원래보다 단면적을 작게 하고 원하

는 형태를 만드는 가공법이다 (김낙수 외, 1995, 강명순, 손명환, 1995). 압출

가공의 공정 설계는 크게 압출금형 (Figure 6-2 참조)의 설계와 공정변수 (빌

렛온도, 압출속도 등)의 결정으로 나눌 수 있다. 압출 가공의 공정 설계는 현장

전문가의 감각적인 지식과 실험에 크게 의존하고 있으며, 특히 실험으로 여러

가지 공정 설계 변수들을 결정하는 데는 많은 시행착오를 겪고 있는 상태이다.

98

stem billetram

disk

sleeve

dieextruded

wire

F i g u r e 6-1 O v e r v i e w o f m u l t i -e x t r u s i o n p r o c e s s

소재유입방향

Die

Die Holder

F i g u r e 6-2 E x t r u s i o n d i e

6.1.2 도메인 지식제공 메커니즘을 이용한 인자수집

이 실험을 계획하는 단계에서 압출공정에 영향을 미치는 인자들을 조사할

필요성이 대두되었다. 본 연구에서는 이를 위해 10년 경력의 기술자와 3년 경

력의 조작자를 대상으로 인터뷰를 수행하였다. 몇 달 후 도메인 지식제공 메커

니즘을 이용하여 5년 미만의 경력을 가진 8 명의 지식제공자로부터 다시 인자

를 조사하였다. 그 결과를 Table 6-1이 보여준다.

99

6.1.3 인자수집 결과의 검토

더 짧은 시간동안 더 다양한 인자를 찾아낸 이 사례연구의 결과는 도메인

지식제공 메커니즘이 브레인스토밍(brain storming)을 효과적으로 수행하는데

도움을 주는 도구임을 보여준다. 경험이나 전문지식의 유무에 관계없이 다수의

자유로운 의견개진은 얻을 수 있는 아이디어의 폭을 넓혀주는 것이다. 본 연구

에서는 10년 경력자의 경험이나 지식이 부족하다고 판단하지 않는다. 다만 그

가 업체의 사정(설비, 기술, 환경 등)을 너무 잘 알고 있었기 때문에 이것이 오

히려 스스로에게 제약으로 작용했다고 본다. 이에 반해 경험이 적은 기술자들은

다양한 의견을 자유롭게 개진함으로써 더 좋은 결과를 이끌어 냈다. 다수의 의

견을 지역이나 시간에 구애 받지않고 신속히 수집할 수 있는 도메인 지식제공

메커니즘의 도움을 받았음은 물론이다.

T a b l e 6-1 C o m p a r i s o n b e t w e e n c o n v e n t i o n a l i n t e r v i e w a n d D K P M

방법 기존 인터뷰 도메인 지식제공 메커니즘 이용

실험팀 전문가 1인, 작업자 1인,

다구찌 방법 전문가 1인

지식제공자 8인.

다구찌 방법 전문가 1인

소요시간 3 주 (회의 2 번) 4 일

수집된 인자

- 6 dimensional parameters

- Billet temperature

- Sleeve temperature

- Die temperature

- 6 dimensional parameters

- Billet temperature

- Sleeve temperature

- Die temperature

- Billet exposure time

- Sleeve temperature

deviation

- Wire speed

총계 9 개 12 개

100

판재간극

압입량

전극

전극팁

용접너겟

F i g u r e 6-3 O v e r v i e w o f s p o t w e l d i n g o p e r a t i o n

6.2 사례연구 (2) - 점 용접 표면의 요철 최소화

6.2.1 점 용접 가공의 개요

점 용접(spot welding)은 저항용접(resistance welding)의 일종으로 Figure

6-3과 같이 마주보는 두 원통형 전극(electrode)의 끝을 두 금속판재의 겹치기

이음매 부위에 접촉하여 발생되는 저항 열을 이용하는 용접 방법이다 (김낙수

외, 1995 ). 점 용접은 자동차 후드(hood) 등의 제작에 많이 이용되며, 주로 로

봇에 의해 용접이 이루어 진다. 이 때, 점 용접이 일어나는 지점은 약간 압입이

일어나며 열에 의해 주위가 변형, 변색되어 ‘압흔’ 이라는 흔적을 남기게 된다.

이 압흔은 표면거칠기 측정기(surface roughness tester)를 이용하지 않으면 측

정이 불가능할 정도로 미세한 요철이지만, 표면 도장 후에는 눈에 띄는 흔적으

로 발전하기 때문에 추가로 연삭 작업을 통하여 제거해야 한다. 따라서 요철을

최소화하여 추가 연삭 작업이 생략되면 많은 생산비용을 절감할 수 있다.

101

6.2.2 도메인 지식제공 메커니즘을 이용한 인자의 중요도 조사

완벽한 실험을 위해서 되도록 많은 인자를 실험에 포함시켜야 한다는 것은

당연한 일이다. 그러나 보통 비용의 한계 때문에 어떤 인자들을 실험에서 제외

해야 할 경우가 드물지 않다. 본 실험에서는 L18 직교배열을 사용하기 위해서

지금까지 조사된 9 개의 인자 중 한 개를 실험에서 제외해야 하는 상황이었다.

8 개의 인자를 사용할 경우 18 번의 실험이 요구되는 반면, 9 개의 인자를 사

용할 경우 27 번의 실험이 필요하다 (Table 2-2를 참고하라). 그렇다면 어떤

인자를 실험에서 제외할 것인가? 물론 품질에 영향이 가장 적다고 판단되는 인

자를 제외시켜야 할 것이다. 본 실험에서는 이를 알아내기 위하여 도메인 지식

제공 메커니즘을 이용하였다. Figure 6-4는 “점 용접면의 품질향상에 영향을 주

는 다음 인자들을 영향이 큰 순서대로 나열하라”라는 설문에 대한 응답을 보고

에이전트가 보고서로 생성한 것이다. Figure 6-4에 나타난 그래프는 각 인자들

간의 예상 중요도 차이를 명백하게 보여주고 있어 어떤 인자를 제어인자에 포

함시키고 어떤 인자를 포함시키지 않을지를 판단하는데 결정적인 근거가 될 수

있다. 본 실험에서는 당연히 ‘off time’을 제어인자에서 제외하였다.

102

F i g u r e 6-4 A n e x a m p l e o f r e p o r t g e n e r a t e d b y D K P M

6.2.3 인자의 중요도 조사 결과의 검토

이 사례연구에서 얻고자 한 인자의 중요도와 같은 정보는 경험이 많은 전문

가라 할지라도 정확하게 알지 못하는 경우가 많다. 따라서 다수의 의견을 모으

103

는 것이 의사결정에 큰 도움이 될 것이다. 그러나, 전문가도 정확히 모르는 정

보를 많은 사람들로부터 수집한다고 해서 정확한 정보가 얻어진다는 보장은 없

다. 또 인자의 중요도가 모두 비슷비슷하게 조사될 수도 있을 것이다. 실험설계

자는 도메인 지식제공 메커니즘을 통하여 항상 올바른 정보를 수집할 수는 없

다. 그러나 최소한 조사에 참여한 사람들의 생각은 알 수 있다. Figure 6-4에

나타난 인자의 중요도가 정확하다는 보장은 없지만 실험설계자는 최소한 선택

의 막연함을 덜 수 있을 것이다. 더구나 Figure 6-4와 같은 자료는 실험설계자

개인에게는 만일에 있을지 모르는 실험 실패의 책임을 모면할 수 있는 근거가

될 수 있다 (다수에게 의견을 물어 결정한 사항을 누가 추궁하겠는가?).

6.3 사례연구 (3) - 사출성형 병 뚜껑의 누수 최소화

6.3.1 병 뚜껑 사출성형 사례의 개요

사출성형(injection molding)은 용융된 플라스틱 재료를 금형(cavity)안에 사

출시켜 원하는 형상으로 만드는 가공 방법으로, 생산성이 높아 비금속 재료의

가공에 가장 많이 이용되는 기술이다 (조용무, 1992).

이 실험에서는 사출성형을 이용하여 Figure 6-5와 같은 병 뚜껑을 가공해야

하며, 뚜껑 상단의 구멍 직경은 공차 0.02mm를 유지해야 한다. 만일 직경이

공차 한계보다 커지게 되면 내용물이 새는 현상이 발생하고, 공차 한계보다 작

게 되면 조립이 이루어지지 않는다. 따라서 구멍 직경의 편차를 최소화 하는 것

이 이 실험이 목적이다.

104

F i g u r e 6-5 T h e s e c t i o n v i e w o f i n j e c t i o n m o l d e d b o t t l e c a p

6.3.2 상황감지 도움말 제공 메커니즘의 작동

본 사례연구에서는 앞의 두 사례연구와는 달리 상황감지 도움말 메커니즘의

동작 예를 살펴보고자 한다. 상황감지 도움말 메커니즘은 실험설계자와 사용자

인터페이스의 상호작용 중에 동작하므로 먼저 그 발단이 되는 상황에 대해 묘

사하겠다. 실험설계자는 실험계획 중 ‘품질특성 결정’ 단계를 수행하고 있으며,

Figure 6-6은 당시의 사용자 인터페이스 이다. 실험설계자는 품질특성의 결정

단계에서 측정도구를 명시하지 않고 다음단계로 진행하려 했다. 상황감지 도움

말 메커니즘은 다음과 같은 추가질문을 실험설계자에게 차례로 던지고, 그 응답

에 따라 Figure 6-7과 같은 도움말을 제시하였다.

n 측정이 인간의 감각에만 의존하여 이루어지는가?

n 인간의 감각으로 요구되는 정밀도를 만족시킬 수 있는가?

105

F i g u r e 6-6 A pa r t o f use r i n te r face fo r de te rmin ing qua l i t y cha rac te r i s t i c

106

F i g u r e 6-7 A n e x a m p l e o f a d v i c e s u g g e s t e d b y C S A M

6.3.3 도움말 제공에 대한 검토

실험 결과의 측정은 초보자들이 간과하기 쉬운 부분이다. 초보자들은 (어떻

게 하던지) 결과를 측정하는 것은 문제가 아니라고 생각한다. 그러나 객관적이

고 정밀한 측정도구가 없는 경우, 나중에 큰 곤란을 겪을 수 있다. 예를 들어

결함의 정도나 양/불량의 판정 같은 작업은 사람에 따라 기준이 달라질 수 있

는 것이다. 만일 측정에 대해 신중히 고려하지 않고 실험에 들어갔다면, 감당할

수 없는 양의 측정을 혼자 처리하거나, 일관성 없는 측정으로 분석의 오류를 만

드는 상황에 처할 수 있다. 다구찌 방법의 두꺼운 교과서를 읽지 않거나 경험이

부족한 실험설계자 들은 이러한 도움말로부터 돌이킬 수 없는 실수를 다소나마

예방할 수 있을 것이다.

107

제 7 장 고찰

본 장에서는 시스템의 개발과정, 사례연구, 사례연구에 협조한 동료들과의

토의 등을 통해 얻어진 평가를 비롯하여 본 시스템의 개선점, 한계 등에 대해

언급 한다.

7.1 의사결정지원 시스템의 활용성에 대한 고찰

사례연구를 통하여 본 연구에서 개발된 시스템의 활용가치를 어느 정도 확

인할 수 있었다. 특히 도메인 지식제공 메커니즘의 경우 수집된 정보의 신뢰성

에 대해 많은 논란이 있었으나, 실험설계자의 의사결정에 큰 도움이 된다는 사

실에는 이론이 없었다. 이것은 도메인 지식제공 메커니즘에 의해 수집된 정보가

지식제공자들의 의견을 반영하기 때문이다. 정보의 정확성을 떠나 지식제공자들

의 생각, 즉 해당 분야에 몸담고 있는 사람들의 생각을 안다는 것은 매우 중요

한 일이다. 더구나 지역이나 시간에 큰 제약을 받지않고 많은 사람들로부터 정

보를 수집할 수 있다는 것은 큰 장점이라 할 수 있다. 상황감지 도움말 메커니

즘의 경우 초보자들의 실수 예방에 큰 도움을 줄 수 있다고 평가된다. 숙련자로

갈수록 도움말의 효과는 감소하게 마련인데, 이 점은 실험설계자의 능력을 고려

한 도움말 제공 전략(Figure 4-8 참조)으로 어느 정도 조정이 될 수 있다.

다음은 사례연구에 참여한 사람들과의 토의를 통해 얻어진 시스템에 대한

개선점이나 활용에 있어서의 제안 등을 나열한 것이다.

n 한 사람의 올바른 의견이 두 사람의 틀린 의견에 의해 묻혀버릴 수 있

다. 이러한 문제점을 줄이기 위해 지식제공자의 교육정도, 경험, 전문분

야 등에 따라 응답의 중요도(weight)에 차등을 두는 방법을 쓸 수 있다.

n 도메인 지식제공 메커니즘이 보고한 내용이 유효하려면 지식제공자의

108

수가 어느 정도 이상이어야 한다. 따라서 중대형 규모 이상의 기업이나

연구소에서 그 유용성을 발휘할 수 있다. 소규모의 기업인 경우, 유사한

기술에 관심이 있는 몇 개의 기업이 지식공유공동체를 구성하는 것이

바람직하다.

n 얼굴을 맞대고 하는 회의가 아니므로 지식제공자들이 지식수집과정에

열심히 참여하지 않을 수 있다. 이런 경우, 참여율을 높이기 위한 장려

책이 필요하다. 상위직 관리자의 지원도 지식제공자들에게 보다 많은 관

심을 갖도록 유도할 수 있는 좋은 방안이다.

n 설문의 형식과 응답의 형식이 몇 가지로 제한되어 있다. 지식제공자와

실험설계자 사이에 명확한 의사전달을 위해서는 보다 다양한 설문과 응

답의 방법이 필요하다.

7.2 시스템 개발과정에 대한 고찰

본 절에서는 시스템의 설계 및 구현에 관하여 간략히 언급 한다. 먼저 본 연

구에서 시스템 설계 방법론으로 사용한 UML은 복잡한 시스템을 모델링 하는데

유용한 도구임을 확인할 수 있었다. 그러나 본 연구에서는 UML의 장점을 충분

히 살리지 못하였다고 판단되는데, 그 이유는 다음과 같이 분석된다.

n 기존 설계 방법에 길들여진 습관을 벗어나지 못하고, UML 설계 경험의

부족으로 인하여, 설계의 각 단계의 목적과 특성에 알맞은 충실한 설계

행위를 실천하지 못하였다.

n 시스템의 설계를 한 사람이 감당하였기 때문에, 팀 단위의 의사소통의

표준이라 할 수 있는 UML의 장점을 충분히 살리지 못하였다.

n 충분한 반복작업을 통하여 위험요소를 감소시키려는 시도가 부족하여,

시스템을 최적화 시키지 못하였으며, 코딩작업에 충분할 만큼의 상세화

109

를 시키지 못하였다.

n Rational Rose의 소스코드생성 기능을 활용하지 않아 수작업의 양을 줄

이지 못하였다.

UML 설계는 다양한 다이어그램을 사용하고, 객체지향 분석을 포함하고있어

기존의 소프트웨어 설계 방법론에 비해 다소 복잡하게 느껴진다. 또한 UML이

다른 방법에 비해 많은 시간과 노력을 요구하기 때문에 혼자서 작업을 하는 경

우 쉽게 지루함을 느낄 수 있고, 집중력을 잃어버리거나 반복작업을 엄정하게

실행하는 것이 어렵다. 따라서 UML의 장점을 충분히 살리려면 많은 훈련이 필

요하며, 팀 단위의 작업체계가 적합하다 생각된다.

본 연구에서 도메인 지식제공 메커니즘을 구현하는데 사용된 ASP (Active

Server Page)는 CGI (Common Gateway Interface)나 Java에 비해 구현이 용

이하며, 서버나 클라이언트에 주는 부담도 적어 인터넷기반 설문조사 시스템을

개발하는데 적합하다고 할 수 있다. 다만 웹 서버가 마이크로소프트 IIS

(Internet Information Server) 로 제한되어 있다는 점이 단점이라 할 수 있다.

그러나 다구찌 실험계획 의사결정지원 시스템의 경우 동시접속자가 그리 많지

않으므로, 고성능 서버를 따로 운영하는 것 보다는 실험설계자의 개인 컴퓨터에

서 직접 운영하는 것이 관리의 측면에서 더 유리한 경우가 많을 것이라 생각된

다.

상황감지 도움말제공 메커니즘에서 도움말 에이전트는 메인 프로그램과 독

립된 ActiveX EXE로 구현되었으며, 추론과정을 위해 CLIPS ActiveX 컨트롤을

내장하였기 때문에 다소 큰 백그라운드 프로그램이다. 더구나 event log와

context memory를 CLIPS에서 읽을 수 있는 ASCII 파일로 구현하였기 때문에

이 파일들을 매번 읽고 쓰는데 많은 리소스가 할당된다. 이렇게 상황감지 도움

말 기능이 발생시키는 시스템의 부하(load)는 메인 프로그램의 작업 중 빈번한

대기상태를 만들어 내는데 이는 시스템의 주기능과 무관하다 하더라도 매우 바

110

람직하지 않은 현상이다. 이러한 현상을 극복하기 위한 가장 확실한 방법은 상

황감지 도움말 메커니즘을 메인 프로그램과 통합하여 Visual Basic 으로 구현하

는 것이다. 그러나 이 통합은 시스템을 복잡하게 만들고 유지 보수를 어렵게 하

며, 지식의 추가나 갱신이 어렵다는 단점을 가지고 있다.

도메인 지식제공 메커니즘에서 보고서 생성에 처음 시도한 방법은 마이크로

소프트 차트 ActiveX 컨트롤을 ASP에 포함시킨 방법이다. 그러나 ActiveX 컨

트롤은 웹 페이지에 포함시키기에 다소 무겁고5, 그래프의 모양도 미려하지 못

해 만족스럽지 못하였다. 현재 이 기능을 국산 홈페이지 저작 도구인 나모 웹

에디터의 내장 기능인 차트 마법사를 이용하여 대치하고자 하는데, 이 마법사는

그래프를 그림 파일로 만들어 주기 때문에 웹 페이지에 포함시켜도 부담이 없

으며, 생성하는 그래프의 모양도 미려하다. 참고로 이 마법사는 CGI 기술을 이

용한 것이다.

수집 에이전트는 ActiveX EXE로 구현되어 메인 프로그램과 독립적으로 구

동 되며, 메인 프로그램이 종료된 이후에도 설문의 진행 상황을 백그라운드에서

관찰한다. 소프트웨어 릴리즈(release)를 위하여 크기가 최적화되지 않은 구성

요소가 메모리에 상주한다는 것은 컴퓨터의 성능에 분명 부담을 주는 것이다.

본 연구에서는 수집 에이전트의 설문 진행상황 관찰기능을 시스템 서비스에서

주관하도록 하는 방안을 검토하고 있다.

7.3 관련 연구와의 비교

본 절에서는 개발된 에이전트기반 다구찌 실험계획 의사결정지원 시스템과,

관련 연구와의 차이점에 대해 기술하겠다. 제 1 장과 제 2 장에서 이미 언급한

내용도 있으나 여기서 종합하여 정리하고자 한다. 본 연구에서는 다구찌 방법,

5 ‘무겁다’는 표현은 소프트웨어 구성요소의 크기가 커서 웹 페이지에 삽입하였을 때, 전

송 시간을 많이 요구하는 상태를 말한다. 반대의 경우 ‘가볍다’고 이야기 한다.

111

지능형 에이전트, 상황감지 도움말 시스템, 인터넷기반 설문조사 시스템 등 다

양한 분야의 기술을 사용하였다. 이 모든 기술을 사용한 사례가 없는 관계로 각

분야별로 본 연구와 부분적으로 관련된 연구사례를 찾아 비교하였다.

첫 번째로, 컴퓨터 기술을 이용하여 다구찌 방법을 지원하는 시스템 들을 살

펴보겠다. 1.1.3 절에서 다구찌 방법의 전산화 사례를 몇 가지 소개한 바 있다.

여기서 소개한 기존 시스템들과 본 연구에서 개발된 시스템과의 차이점은 다음

과 같다.

n 다구찌 방법의 수행단계 중 의사결정을 지원하는 단계가 다르다. 1.1.3

절에서 소개한 몇 가지 상용 소프트웨어 시스템과 전문가시스템은 모두

다구찌 실험단계 중 행렬실험 및 그 이후의 과정에 중점을 두고 있으며,

다구찌 실험의 초기단계이자 가장 중요한 단계인 ‘실험계획’에 관하여

다루지 않고 있다. 이는 실험계획 단계의 중요성이 인식되지 못했을 뿐

아니라, 실험계획 단계의 전산화가 종전까지의 컴퓨팅 환경에서는 그리

용이하지 않았기 때문으로도 풀이된다. Table 7-1에 각 시스템별 의사

결정지원 부분을 나타내었다.

n 본 연구에서 개발된 시스템은 도메인 지식을 제공하는 기능을 가지고

있다. 기존 시스템들은 지식을 제공하지 않거나, 다구찌 방법에 대한 부

분적인 지식만을 간접적으로 제공하였다.

112

T a b l e 7-1 C o m p a r i s o n o f T a g u c h i s o f t w a r e s y s t e m s

지원하는 의사결정 항목

수행단계

세부 의사결정

및

작업내용 WinRobust,

ANOVA-TM,

STN,

RIPSES

Lee et al. 정환종 본 연구

실험 팀의 구성 O

실험 목적의 결정 O

품질특성의 결정 O

측정방법의 결정 O

독립변수의 결정 O

제어인자와 잡음인

자로 분류 O

인자들의 수준을

결정

잠재적 교호작용의

파악

실험계획

실험전략의 수립 O

자유도 계산

직교배열의 선택 ∆ O O

직교배열의 변형 O O 실험설계

인자의 배치 ∆ O O

시험 계획수립

실험 준비

실험 수행 실험수행

시험 및 검사

표 및 그래프에 의

한 분석 O

인자의 주효과 및

최적인자조합 파악

최적조건 예측

결과분석

확인실험의 수행

두 번째로, 에이전트기반 의사결정지원 시스템에 관해 살펴보겠다. 일반적인

에이전트기반 의사결정지원 시스템과 본 연구의 에이전트기반 의사결정지원 시

스템은 큰 차이를 가지고 있지 않다. 다만 일반적인 에이전트기반 의사결정지원

113

시스템의 정보의 출처는 보통 데이터베이스 인 것과는 다르게 본 연구에서 개

발된 시스템은 사람으로부터 정보를 수집한다는 차이점이 있다. 참고로 일반적

인 의사결정지원 시스템에서 에이전트들은 보통 이질적인(heterogeneous) 환경

의 다수의 데이터베이스로부터 데이터를 검색하여 특정한 패턴(pattern)을 찾아

내고, 보고하는 역할을 한다.

세 번째로, 인터넷기반 설문조사 시스템에 관해 살펴보겠다. 본 연구에서 개

발한 설문조사 시스템은 일반적인 웹 기반 설문조사 시스템에서 아이디어를 얻

어왔으며, 이를 바탕으로 하고 있다. 따라서 본 연구에서 개발된 시스템은 다음

의 특징을 제외하면 일반적인 웹 기반 설문조사 시스템과 대동소이 하다고 할

수 있다.

n 본 연구에서 개발한 인터넷기반 설문조사 시스템은 에이전트기반 구조

를 가지고 있다. 설문의 배포와 수집에서 결과의 보고에 이르기까지의

작업을 에이전트가 처리한다.

n 모집단이 정해져 있지 않은 일반적인 설문조사와 달리 정해진 지식제공

자 그룹이 존재한다.

네 번째로, 본 연구에서 개발된 상황감지 도움말 시스템은 기존의 상황감지

도움말 시스템과 비교하여 주목할만한 특징을 가지고 있지 않다. 이는 본 연구

에서 상황감지 도움말 기술을 도입했을 뿐, 특별한 개선을 이루지 않았다는 의

미이다.

본 절에서 살펴본 관련 시스템들과의 비교 중 다구찌 방법의 전산화를 제외

한 나머지 분야는 본 연구가 기존 기술들과 큰 차이가 없음을 보여준다. 이는

본 연구에서 소프트웨어 에이전트, 인터넷기반 설문조사, 상황감지 도움말 기술

을 ‘도입’하여 ‘다구찌 방법의 수행을 지원하는 소프트웨어를 개발’ 하고자 한

것이지, 이 기술들 차체를 ‘개선’하고자 한 것이 아니기 때문이다.

114

제 8 장 결론 및 향후연구사항

8.1 결론

본 연구에서는 다구찌 실험계획의 의사결정을 위한 에이전트기반 의사결정

지원시스템 프레임워크를 제안하고 프로토타입 시스템을 개발하였다. 본 연구에

서 개발된 시스템의 특징은 다음과 같다.

n 다구찌 방법의 수행단계 중 ‘실험계획’ 단계의 의사결정을 지원하는 최

초의 소프트웨어 시스템이다. 실험계획 단계는 그 중요성에 비해 그 동

안 주목 받지 못하였고, 다구찌 방법의 지원을 위해 개발된 소프트웨어

들도 이 단계의 의사결정을 지원하려는 시도를 하지 않았다.

n 다구찌 실험계획의 의사결정에 필요한 두 가지 지식인 도메인 지식과

다구찌 방법 자체에 관한 지식을 모두 제공하기 위해 두 개의 에이전트

기반 메커니즘을 개발하였다. 각각은 ‘도메인 지시제공 메커니즘’과 ‘상

황감지 도움말제공 메커니즘’이다.

n 도메인 지식제공 메커니즘은 수집 에이전트와 보고 에이전트로 구성되

어 기업내의 지식제공자들로부터 실험대상 분야에 관한 지식을 수집, 제

공함으로써 실험설계자의 의사결정을 지원한다. 이 메커니즘은 인터넷

환경에서 동작하기 때문에 기존의 맞대면을 통한 회의가 갖는 시간적,

공간적 제약을 극복한 신속하고 효율적인 지식의 수집이 가능하다.

n 상황감지 도움말제공 메커니즘은 실험설계자의 상황을 파악하고 적절한

도움말을 제공함으로써 부적절한 의사결정을 최소화하도록 도와준다.

n 도메인 지식제공 메커니즘을 통해 수행된 설문의 결과 및 실험계획의

진행상황이 웹을 통하여 게시되기 때문에, 실험 팀 내에 실험에 대한 정

보 공유가 용이하다.

115

본 연구에서 개발된 의사결정지원시스템을 사용함으로써 얻을 수 있는 이점

은 다음과 같다.

n ‘도메인 지식제공 메커니즘’을 사용함으로써 실험 팀 내의 지식 수집을

빠르고 경제적으로 수행할 수 있다.

n ‘상황감지 도움말제공 메커니즘’을 이용함으로써 다구찌 실험계획에 필

요한 지식을 효과적으로 제공받음으로써 실험설계자는 의사결정의 오류

를 크게 줄일 수 있다.

n 의사결정지원시스템은 실험설계의 타당성을 높여 실험의 후속과정에 있

어 불필요한 시간과 자원의 낭비를 최소화한다.

n 실험의 성공율을 높임으로써 제품 개발 기간을 단축하고, 품질을 개선하

는데 기여한다.

n 실험의 제반 사항을 웹을 통하여 게시함으로써 팀 내의 지식 공유가 용

이해지고, 실험 팀의 기술 수준을 전반적으로 향상시킬 수 있다.

n 실험 팀을 구성하고 실험의 의사결정에 참여 시킴으로써 다구찌 방법을

모르는 사람들에게는 자연스러운 소개의 기회를, 다구찌 방법을 접해본

사람들에게는 이를 더 깊이 이해할 수 있는 기회를 제공한다.

덧붙여 ADTEP의 사용이 유용한 동시공학 구현도구 중 하나인 다구찌 방법

의 사용을 더욱 활성화하는데 기여할 것으로 기대된다.

8.2 향후 연구사항

본 연구에서 개발된 시스템은 다구찌 실험계획의 의사결정에 큰 도움을 줄

것으로 기대되나, 몇 가지 한계와 개선점을 가지고 있다. 제 7 장에서 언급한바

있는 시스템의 활용성, 개발과정, 관련 연구와의 비교를 바탕으로 다음과 같은

116

향후 연구사항을 도출하였다.

n 도메인 지식제공 메커니즘의 신뢰도를 높이기 위해, 지식제공자의 교육

정도, 경험, 전문분야 등에 따라 응답의 중요도(weight)에 차등을 두는

기능을 추가한다.

n 도메인 지식제공 메커니즘의 참여를 진작시키기 위해 응답에 참여한 회

수와 기여도를 평가하기 위한 방안을 마련한다.

n 실험설계자(설문작성자)와 지식제공자 사이에 보다 명확한 의사전달을

구현하기 위해 설문과 응답의 형식을 다양화한다.

n 보다 유연하고 효율적인 지식수집 환경을 구현하기 위해 PDA

(Personal Digital Assistant)나 휴대전화 등을 이용한 무선인터넷

(Wireless Internet) 기술을 도입한다.

n 다구찌 실험의 각 단계별로 적절한 컴퓨터 응용 지원도구를 개발, 통합

함으로써 다구찌 실험의 전체 과정을 지원할 수 있도록 한다.

117

참고문헌

n 강명순, 손명환 1995, 최신 기계공작법, 문운당.

n 김낙수, 임용택, 진종태 공역 1995, 공업재료가공학, 반도출판사.

n 박성룡 1999, “신경회로망을 이용한 도시고속도로 돌방상황감지모형의

적용에 대한 연구,” 한양대학교 석사학위논문.

n 왕창종 1998, 소프트웨어 공학, 정익사.

n 조용무 1992, 플라스틱 사출성형의 이론과 설계, 일진사.

n 주병진, 남대우 공역 1999, Beginning Active Server Pages 2.0,

정보문화사.

n 최영근, 허계범 1995, 객체지향 소프트웨어공학, 한국실리콘.

n 최은만 1996, 소프트웨어 공학, 희중당.

n 한국인터넷리서치연구소 1999, 인터넷설문조사론, http://www.kisri.re.kr.

n Advanced Systems & Designs Inc. 1986, Users Guide: ANOVA-TM for

Windows, Advanced Systems & Designs Inc.

n Badiru A. B. 1992, Expert Systems Applications in Engineering and

Manufacturing, Prentice Hall.

n Bui T. and J. Lee 1999, “An Agent-Based Framework for Building

Decision Support Systems,” Decision Support Systems, 25: 225-237.

n Caglayan A. and C. Harrison 1997, Agent Sourcebook, John Wiley &

Sons.

n Conallen, J 1999, Building Web Applications with UML, Addison Wesley.

118

n Ekenberg L., M. Danielson, and M. Boman 1997, “Imposing Security

Constraints on Agent-Based Decision-Support,” Decision Support

Systems, 20: 3-15.

n Fowlkes, W. Y. and C. M. Creveling 1995, Engineering Methods for

Robust Product Design: Using Taguchi Methods in Technology and

Product Development, Addison-Wesley.

n Gartner Group 1997, Data Quest Interactive,

http://gartner11.gartnerweb.com/dq/static/dq.html.

n InfoMate 1989, STN for Windows: Quality Engineering Software,

InfoMate.

n Knapik M. and J. Johnson 1998, Developing Intelligent Agents for

Distributed Systems: Exploring Architecture, Technologies, and

Applications, McGraw-Hill.

n Korea Research Center 1998, 온라인리서치 이해, http://www.kric.com.

n Lee J. W. and S. J. Cho 2000, “An Agent-Based Decision-Supporting

Framework for Taguchi Experiment Planning,” Advances in Concurrent

Engineering: CE2000.

n Lee N. S., M. S. Phadke, and R. S. Keny 1989, “An Expert System for

Experimental Design in Off-Line Control,” Expert Systems, 6(4): 234-

249.

n Maes P. 1997, General Tutorial on Software Agents, http://

pattie.www.media.mit.edu/people/pattie.

n Microsoft Press 1998, Developing for Microsoft Agent, Microsoft Press.

n Nojima T. 1996, RIPSES home page, http://www.ripses.com.

n Peace G. S. 1993, Taguchi Methods: A Hand-On Approach, Addison-

Wesley.

119

n Phadke M. S. 1989, Quality Engineering using Robust Design, Prentice

Hall.

n Quatrani T. (서기원, 김효수 공역) 2000, Visual Modeling with Rational

Rose 2000 and UML, 인터비젼.

n Rose R. 1996, “Intelligent Agents Framework for Developing

Knowledge-Based Decision Support Systems for Collaborative

Organizational Process,” Expert Systems with Applications, 11(3): 247-

261.

n Ross P. J. 1996, Taguchi Techniques for Quality Engineering 2nd

Edition, McGraw-Hill.

n Sawtooth Technologies 1999, What is CATI?,

http://www.sawtooth.com/products/cati.

n Schmuller, J (곽용재 역) 1999, 초보자를 위한 UML 객체지향설계, 인포북.

n Sturm J. (최광일 역) 1999, Professional VB UML, 정보문화사.

n Taboada M., R. Marin, and J. Mira 1996, “On-Line Automatic Help

Generation Systems,” Cybernetics and Systems: An International

Journal, 27: 303-315.

n Taguchi G. 1987, Introduction to Quality Engineering, Asian Productivity

Organization.

n Turner R. M. 1998, “Context-Mediated Behavior for Intelligent Agents”,

Int. J. Human-Computer Studies, 48: 307-330.

n Wang H. 1997, “Intelligent Agent-Assisted Decision-Support Systems:

Integration of Knowledge Discovery, Knowledge Analysis , and Group

Decision Support,” Expert Systems with Applications, 12(3): 323-335.

n Watt J. 1997, Using the internet for quantitative survey research,

http://www.quirks.com.

120

n Winston P. H. 1992, Artificial Intelligence 3rd Edition, Addison Wesley.

n Wooldridge M. and N. Jennings 1995, “Intelligent Agents: Theory and

Practice” The Knowledge Engineering Review, 10(2): 115-152.