설계 근거

Design rationale
의사결정 기반 설계 구조. 엔지니어링 설계, 설계 이론적 근거 및 의사결정 분석 영역에 걸쳐 있습니다.
detail of a Tree of Knowledge after Diderot & d'Alembert's Encyclopédie, by Chrétien Frédéric Guillaume Roth
정보 매핑
토픽과 필드
노드 링크 어프로치
「 」를 참조해 주세요.

설계 근거는 시스템 또는 아티팩트를 설계할 때 내린 결정의 이면에 있는 이유에 대한 명시적인 문서입니다.W.R. Kunz와 Horst Rittel에 의해 처음 개발된 디자인 이론적 근거는 사악한 [1]문제에 대처하는 정치적이고 협력적인 프로세스에 논쟁에 기초한 구조를 제공하고자 합니다.

개요

설계근거는 설계과정 중에 이루어진 의사결정의 명시적 목록과 그러한 의사결정이 [2]이루어진 이유이다.주된 목표는 [3]설계 프로세스의 배후에 있는 논쟁과 추론을 기록하고 전달하는 수단을 제공함으로써 설계자를 지원하는 것입니다.따라서 [4]다음을 포함해야 합니다.

  • 설계 결정의 이면에 있는 이유
  • 그 이유,
  • 고려된 다른 대안들,
  • 평가된 트레이드오프
  • 그 결정을 이끌어 낸 논쟁

컴퓨터[2] 과학 인지 과학,[3] 인공지능,[5] 지식 [6]관리와 같은 디자인 합리성의 연구에 관련된 과학 분야들이 있습니다.설계 근거를 뒷받침하기 위해 QOC, DRCS, IBIS 및 DRL과 같은 다양한 프레임워크가 제안되었습니다.

역사

논쟁 형식은 Stephen Toulmin의 1950년대[7] 자료, 클레임, 영장, 뒷받침 및 반박 작업으로 거슬러 올라갈 수 있지만, 설계 근거의 기원은 1970년 W.R. Kunz와 Horst Rittel의 이슈[1] 기반 정보 시스템(IBIS) 표기법 개발로 거슬러 올라갈 수 있다.그 후 IBIS에 대한 몇 가지 변형이 제안되었습니다.

  • 첫 번째는 Procedural Hierarchy of Issues(PHI)로, Ray McCall의 박사학위논문에[8] 처음 기재되어 있었지만 당시에는 이름이 기재되어 있지 않았다.
  • IBIS도 소프트웨어 엔지니어링을 지원하기 위해 [9]Potts & Bruns에 의해 변경되었습니다.Potts & Bruns 접근방식은 의사결정 표현 언어(DRL)[10]에 의해 확장되었으며, 그 자체는 RATSpeak에 [5]의해 확장되었다.
  • 질문 옵션과 기준(QOC)은 Win-Win[13] 및 Decision Recommendation and Intent Model(DRIM)[14]과 마찬가지로 토론 기반의[11][12] 근거에 대한 대체 표현입니다.

첫 번째 근거관리시스템(RMS)은 PHI를 지원하는 PROTOCAL이었고, 다른 PHI 기반 시스템인 MIKROPOLIS와 PHIDIAS가 그 뒤를 이었다.IBIS를 지원하는 최초의 시스템은 Hans Dehlinger의 STIEC였습니다.[15]Rittel은 1983년에 작은 시스템(미공개)과 더 잘 알려진 gIB를 개발했습니다.IS(그래픽 IBIS)는 [16]1987년에 개발되었습니다.

모든 성공적인 DR 접근 방식이 구조화된 인수를 수반하는 것은 아닙니다.예를 들어 Carroll과 Rosson의 시나리오 클레임즈 분석[17] 접근방식은 시스템 사용 방법과 시스템 기능이 사용자 목표를 얼마나 잘 지원하는지를 설명하는 시나리오에서 근거를 포착합니다.Carroll과 Rosson의 설계 근거에 대한 접근방식은 컴퓨터 소프트웨어 및 하드웨어 설계자가 기본적인 설계상의 트레이드오프를 식별하고 잠재적인 설계 [18]개입의 영향에 대해 추론할 수 있도록 하기 위한 것입니다.

설계 근거의 주요 개념

DR 접근방식을 특징짓는 방법은 여러 가지가 있습니다.주요 구별 기능으로는 캡처 방법, 표현 방법 및 사용 방법이 있습니다.

근거 수집

근거 파악은 근거 관리를 위해 근거 정보를 취득하는 프로세스입니다.

캡처 방법
  • "재구성"[4]이라고 불리는 방법은 비디오와 같은 원시 형태로 합리성을 포착한 후 더 구조화된 [19]형태로 재구성합니다.Reconstruction 메서드의 장점은 합리성을 신중하게 캡처할 수 있고 캡처 프로세스를 통해 설계자를 방해하지 않는다는 것입니다.그러나 이 방법은 높은 비용과 합리성을 생산하는 사람의 편견을 초래할 수 있습니다.
  • 「녹음 재생」[4]방법은, 이성이 전개되는 대로 간단하게 캡쳐 합니다.합리성은 화상회의에서 동기적으로 캡처되거나 게시판이나 이메일 기반 토론을 통해 비동기적으로 캡처됩니다.시스템이 비공식 및 반공식 대표성을 갖는 경우 이 방법이 도움이 될 것이다.
  • "방법론적 부산물"[4] 방법은 스키마를 따르는 설계 프로세스에서 합리성을 포착합니다.하지만 그런 스키마를 설계하는 것은 어렵습니다.이 방법의 장점은 저렴한 비용입니다.
  • 미리 작성된 풍부한 지식 기반(KB)[4]을 사용하여 설계자의 행동에 혼란스럽거나 동의하지 않을 때 질문을 함으로써 이유를 파악합니다.이 방법은 사용자뿐만 아니라 시스템에도 도움이 됩니다.
  • 「자동 생성」[4]방법은, 실행 이력으로부터 저비용으로 설계 합리화를 자동적으로 생성한다.일관되고 최신의 합리성을 유지할 수 있습니다.그러나 일부 기계 학습 문제의 복잡성과 어려움으로 인해 실행 이력을 컴파일하는 데 비용이 많이 듭니다.
  • "이력"[20] 방식은 개인이나 컴퓨터 프로그램이 디자이너의 모든 행동을 볼 수 있게 하지만 제안을 하지는 않습니다.합리성은 설계 프로세스 [19]중에 포착됩니다.

이론적 표현

설계 근거 표현의 선택은 우리가 원하는 합리성이며 효율적으로 사용할 수 있도록 하기 위해 매우 중요합니다.형식적인 정도에 따라 설계 근거를 나타내기 위해 사용되는 접근법은 세 가지 주요 범주로 나눌 수 있습니다. 비공식, 반형식 또는 [4]형식입니다.비공식 표현에서는 워드프로세서, 오디오 및 비디오 기록, 심지어 손으로 쓴 글씨 등 전통적으로 받아들여지는 방법과 미디어를 사용하는 것만으로 합리성을 기록하고 포착할 수 있습니다.그러나 이러한 설명은 자동 통역이나 다른 컴퓨터 기반 지원을 어렵게 만듭니다.공식 표현에서는 논리를 컴퓨터에 의해 해석되고 이해할 수 있도록 엄격한 형식으로 수집해야 합니다.그러나 형식적인 표현에 의해 정의된 논리의 엄격한 형식 때문에 그 내용은 인간이 이해하기 어렵고 설계 논리를 포착하는 과정은 완성하는 데 더 많은 노력을 필요로 하기 때문에 더욱 거슬리게 된다.

반형식 표현은 비공식 표현과 형식 표현의 장점을 결합하려고 합니다.한편, 취득한 정보는, 보다 많은 컴퓨터 베이스의 서포트를 제공할 수 있도록, 컴퓨터로 처리할 수 있어야 합니다.한편, 설계 근거의 정보를 포착하는 데 사용되는 절차와 방법은 매우 거슬리지 않아야 한다.반형식 표현을 가진 시스템에서는 예상되는 정보가 제시되며 사용자는 몇 가지 템플릿에 따라 속성을 작성하거나 자연어 기술 [4]중 하나를 입력함으로써 근거를 포착할 수 있다.

인수 기반 모델

툴민 모델
반형식 설계 근거 표현을 위해 일반적으로 허용되는 한 가지 방법은 논의로서 [5]설계 근거를 구성하는 것입니다.많은 설계 이론적 시스템에서 사용된 최초의 논거 기반 모델은 툴민 [7]모델이다.Toulmin 모델은 6가지 단계로 [21]설계 이론적 논거 규칙을 정의합니다.
  1. 클레임이 제기되다
  2. 보충 데이터가 제공됩니다.
  3. Warrant는 기존 관계에 대한 증거를 제공합니다.
  4. Warrant는 지원을 통해 지원할 수 있습니다.
  5. 모델 한정자(일부, 다수, 대부분 등)가 제공됩니다.
  6. 가능한 반박도 고려된다.
툴민 모델의 장점 중 하나는 대부분의 사람들이 쉽게 이해할 수 있는 단어와 개념을 사용한다는 것입니다.
이슈 기반 정보 시스템(IBIS)
설계 근거의 논거에 대한 또 다른 중요한 접근법은 Rittel과 Kunz의 IBIS(문제 기반 정보 시스템)[1]로, 실제로는 소프트웨어 시스템이 아닌 논거 표기법이다.GIB에 의해 소프트웨어 형태로 구현되었습니다.IS(그래픽 IBIS), ITIBIS(테스트 기반 IBIS), Compendium 및 기타 소프트웨어.[22][23]IBIS는 문제, 위치, 주장, 해결과 같은 몇 가지 이론적 요소(노드로 표시됨)와 보다 일반적인 관계(논리적인 후계자), 임시적인 후계자(temporary successor to replacement) 및 이와 유사한 관계(예: 더 일반적인 후계자(temporary successor))를 사용하여 문제의 논의를 연결합니다.
문제의 절차 계층(PHI)
PHI(Procedural Hierarchy of [24]Issues)는 IBIS를 논란의 여지가 없는 이슈로 확장하고 관계를 재정의했다.PHI는 하위 이슈 관계를 추가하는데, 이것은 한 문제의 해결이 다른 문제의 해결에 달려있다는 것을 의미합니다.
질문, 옵션, 기준(QOC)
QOC(Questions, Options, and Criteria)[25]는 설계 공간 분석에 사용됩니다.IBIS와 마찬가지로 QOC는 주요 설계 문제를 질문으로 파악하고 질문에 대한 가능한 답변을 옵션으로 식별합니다.또한 QOC는 조건을 사용하여 충족해야 할 요건이나 원하는 속성 등 옵션을 평가하는 방법을 명시적으로 기술합니다.옵션은 긍정적이든 부정적이든 기준과 연결되며 이러한 연결은 평가로 정의됩니다.
의사결정 표현 언어(DRL)
DRL(Decision Representation Language)[26]은 DR의[9] Potts and Bruns 모델을 확장하고 주요 요소를 의사결정 문제, 대안, 목표, 클레임 및 그룹으로 정의합니다.Lee(1991)는 DRL이 다른 [26]언어보다 표현력이 높다고 주장했다.DRL은 설계상의 근거보다는 의사결정과 그 근거의 표현에 더 초점을 맞춘다.
RATSpeak
RATspeak는 DRL을 기반으로 SEURAT (Software Engineering Using RATionale)[27]에서 표현 언어로 개발되어 사용되고 있습니다.RATSpeak는 의사결정 문제에 대한 대안의 일부로서 요건(기능적 및 비기능적)을 고려한다.SEURAT는 또한 Argument Ontology를 포함합니다.Argument Ontology는 인수 유형의 계층이며 시스템에서 사용되는 클레임 유형을 포함합니다.
WinWin Spiral 모델
그 WinWin 나선 모델은 WinWin approach,[28]에 사용하는 경우,기에, AA는 상호 satisfactor을 이루기로도 나선형 소프트웨어 개발 model[29]의 각 주기의 앞부분에 각 이해 관계자와 협상의 승리 조건을 확인하여 이 시스템의 주요 이해 관계자들을 파악을 포함은 WinWin 협상 활동을 추가한다.y(winwin) 프로젝트의 모든 이해관계자를 위한 합의.
WinWin Spiral Model에서는 각 이해관계자의 목표는 Win 조건으로 정의됩니다.당첨 조건 간에 경합이 발생하면 이슈로 캡처됩니다.그런 다음 이해관계자는 옵션을 고안하고 문제를 해결하기 위한 트레이드오프를 조사합니다.문제가 해결되면 이해관계자의 승소조건을 충족하고 합의된 옵션을 포착하는 합의가 이루어진다.의사결정의 이면에 있는 설계상의 근거는 WinWin 모델 프로세스에서 파악되며, 이해관계자와 설계자가 향후 의사결정을 [28]개선하기 위해 사용합니다.WinWin Spiral 모델은 이해관계자들에게 협상을 위한 잘 정의된 프로세스를 제공함으로써 설계 이론적 근거 파악에 따른 오버헤드를 줄입니다.의사결정 근거의 온톨로지에서는 그 모델이 온톨로지를 사용하여 WinWin 콜라보레이션 프레임워크의 의사결정 유지보수를 지원하는 문제에 대처합니다[30].
설계 권장 및 의도 모델(DRIM)
DRIM([14]Design Recommendation and Intent Model)은 SHARED-DRIM에서 사용됩니다.DRIM의 주요 구조는 각 설계자의 취지, 취지를 충족하는 권고사항 및 권장사항의 정당성으로 구성된 제안서입니다.서로 다른 설계자들의 의도 사이에 충돌이 있을 때도 협상이 필요하다.수용된 권고사항은 설계 결정이 되며, 수용되지 않았지만 제안된 권고사항의 근거도 이 프로세스 중에 기록되며, 이는 반복 설계 및/또는 시스템 유지관리 중에 유용할 수 있다.

적용들

설계 근거는 다양한 방법으로 사용될 가능성이 있습니다.Burge and Brown(1998)[19]에 의해 정의된 한 가지 용도는 다음과 같습니다.

  • 설계 검증 - 설계 결정 및 제품 자체가 설계자와 사용자가 실제로 원하는 것을 반영하는지 여부를 검증하기 위해 설계 근거를 사용할 수 있습니다.
  • 설계 평가 - 설계 프로세스에서 논의된 다양한 설계 대안을 평가하기 위해 설계 근거를 사용합니다.
  • 설계 유지 보수 - 설계 변경에 필요한 변경 사항을 결정하는 데 도움이 됩니다.
  • 설계 재사용 - 설계 근거는 기존 설계를 변경 여부와 관계없이 새로운 요건에 어떻게 재사용할 수 있는지를 결정하기 위해 사용됩니다.설계를 변경해야 할 경우 DR은 설계에서 수정해야 할 사항도 제시합니다.
  • 설계 교육 - 설계와 시스템에 익숙하지 않은 사람들을 교육하기 위한 자료로 설계 근거를 사용할 수 있습니다.
  • 설계 커뮤니케이션 - 설계 프로세스에 관여하는 사람들 간의 커뮤니케이션이 용이하여 더 나은 설계를 도출하는 데 도움이 됩니다.
  • 설계 지원 - 설계 프로세스 중에 이루어진 설계 결정을 검증하기 위해 설계 근거를 사용할 수 있습니다.
  • 설계 문서 - 설계 근거는 회의실 심의, 논의된 대안, 설계 결정의 배후에 있는 이유 및 제품 개요를 포함한 설계 프로세스 전체를 문서화하기 위해 사용됩니다.

DR은 소프트웨어 엔지니어링, 기계 설계, 인공지능, 토목 공학 및 인간-컴퓨터 상호 작용 연구에서 연구 커뮤니티에서 사용됩니다.소프트웨어 엔지니어링에서는 요건 분석, 설계 회의의 캡처 및 문서화, 새로운 [31]설계 접근으로 인한 문제 예측 시 설계자의 아이디어를 지원하기 위해 사용할 수 있습니다.소프트웨어 아키텍처 및 아웃소싱 솔루션 설계에서는 아키텍처 결정의 결과를 정당화하고 설계 [32]가이드 역할을 할 수 있습니다.토목 공학에서는 건축 프로젝트의 여러 영역에서 설계자가 동시에 수행하는 다양한 작업을 조정할 수 있습니다.또한 디자이너들이 서로의 아이디어를 이해하고 존중하며 가능한 문제를 [33]해결할 수 있도록 도와줍니다.

DR은 프로젝트 관리자가 프로젝트 계획 및 프로젝트 상태를 최신 상태로 유지하기 위해 사용할 수도 있습니다.또한 설계 회의에 참석하지 못한 프로젝트 팀원은 DR을 다시 참조하여 특정 주제에 대해 논의된 내용을 확인할 수 있습니다.DR에서 파악된 해결되지 않은 문제를 사용하여 이러한 [31]주제에 대한 추가 회의를 구성할 수 있습니다.

설계 근거는 설계자가 이전 설계에서와 같은 실수를 피할 수 있도록 도와줍니다.이것은 일의 [5]중복을 방지하는 데에도 도움이 될 수 있습니다.경우에 따라서는 소프트웨어 시스템을 이전 [2]버전에서 업그레이드할 때 DR이 시간과 비용을 절약할 수 있습니다.

HCI,[34] 엔지니어링[4] 설계 및 소프트웨어 [35]엔지니어링에 적용된 이론적 접근법에 대한 훌륭한 조사를 제공하는 여러 책과 기사가 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c 쿤츠, W.; Rittel, H.(1970), 정보 시스템의 요소로서의 문제.캘리포니아 대학교 버클리, 도시 및 지역 개발 센터 131호 워킹 페이퍼
  2. ^ a b c Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M.(1992), "소프트웨어 엔지니어링 설계 근거: A Survey", 제25회 하와이 국제 시스템 과학 컨퍼런스, 2, 577-586 페이지
  3. ^ a b Horner, J.; Atwood, M.E. (2006), "유효한 설계 근거:A.H. Dutoit, McCall, R.; Mistrik, I. 등, 소프트웨어 엔지니어링의 이론적 관리, 스프링거 베를린 하이델베르크, 페이지 73-90.
  4. ^ a b c d e f g h i 리, J.(1997)."설계 근거 시스템:문제의 이해」를 참조해 주세요.IEEE Expert 12(3): 78 ~85
  5. ^ a b c d J.E. Burge; Brown, D.C. (2000), J. Gero, J., Design '00의 인공지능: Kluwer Academic Publ., 페이지 611~629.
  6. ^ Xin, W.; Gwangleng, X.(2001), "기업 기술 메모리의 일부로서의 설계 근거", Systems, Man and Cybernetics, 1904 - 1908 페이지.
  7. ^ a b 스티븐 툴민(1958)인수의 사용.케임브리지:케임브리지 대학 출판부
  8. ^ McCall, R. (1978) 디자인에서의 이슈 시스템의 구조와 사용에 관한 박사학위 논문, 캘리포니아 대학교 버클리, University Microfilms
  9. ^ a b Potts, C.; Burns, G.(1988), "설계 결정의 이유 기록", 제10회 소프트웨어 엔지니어링 국제회의(ICSE '1988) 페이지 418-427
  10. ^ Lee, J. (1991), "설계 근거 기록을 위한 Potts and Bruns 모델 확장", 제13회 소프트웨어 엔지니어링 국제회의(ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, 페이지 114-125.
  11. ^ Maclean, A.; Young, RM.; Moran, T.(1989), "디자인 근거: 아티팩트 뒤에 있는 주장", SIGCHI Bull. 20, 페이지 247-252114-125.
  12. ^ Maclean, A., Young, RM; Vellotti, VME; Moran, T. (1996), "질문, 옵션 및 기준:"디자인 공간 분석 요소", 텍사스 주 모란에서; 캐롤, J., 디자인 이론적 개념, 기술, 사용, 로렌스 얼바움 어소시에이츠, 53-106페이지
  13. ^ Barry Boehm, Ross, R(1989)"이론 W 소프트웨어 프로젝트 관리: 원칙과 예시"소프트웨어 엔지니어링에 관한 IEEE 트랜잭션 18(7): 902-916.
  14. ^ a b Pena-Mora, F.; Siram, D.; Logcher, R.(1993), "SHARED-DIMS: SHARED Design Recommendation-Intent Management System", Procedurations Enabling Technologies Infrastructure for Collaborative Enterprise, IEEE 프레스, Morgantown, W22.3, P.
  15. ^ Dehlinger, H.(1978) 프로젝트 STIEC: 유럽공동체 과학기술정보 생성 및 보급 시스템 분석" 보고서 제26호: 배치에 관한 보고서 - 하이델베르크/슈투트가르트 버전
  16. ^ 콩클린, J.; 야켐베게노비치, M. (1988)"GIBIS: 정책 탐색을 위한 하이퍼텍스트 도구"Office Information Systems 6의 ACM 트랜잭션(4): 303-331.
  17. ^ 캐롤, JM; 로슨, M(1992)"태스크-아티팩트 사이클 회피: 클레임 및 시나리오별 설계 방법"ACM 트랜스 정보: 시스템 10 (2): 181-212
  18. ^ 캐롤, J.M., & 로슨, M. B. (2003)이론으로서의 설계 근거.HCI 모델, 이론 및 프레임워크: 다원적 과학을 향해, 431-461.
  19. ^ a b c Burge, J.; Brown, D.C.(1998), 설계 근거: 유형 및 도구, 기술 보고서, Worcester Polytechnical Institute, Computer Science Depart., 2007년 4월 27일 취득
  20. ^ Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T.(1990), "디자인 역사 지식 표현과 그 기본 컴퓨터 구현", 제2회 디자인 이론과 방법론에 관한 국제 회의, 시카고, 페이지 175-185.
  21. ^ 레이놀즈, 크리스(2000), 툴민 모델이란?2007-08-25 의 아카이브는, concentric.net 의 「Wayback Machine Paper」에 게재되어 있습니다.
  22. ^ 콩클린, J.; 야케모비치, K. (1991)"설계 원리에 대한 프로세스 지향 접근법"인간과 컴퓨터의 상호작용 6 (3 & 4): 357 ~391.
  23. ^ Rittel, Horst W. J.; Noble, Douglas (January 1989). Issue-based information systems for design (PDF) (Technical report). Berkeley, CA: Institute of Urban and Regional Development, University of California. OCLC 20155825. 492.
  24. ^ McCall, R.J.(1991)"PHI: 하이퍼미디어 설계의 개념적 기반"디자인 스터디 12 (1): 30~41.
  25. ^ Maclean, A., Young, RM; Vellotti, VME; Moran, T. (1996), "질문, 옵션 및 기준:"디자인 공간 분석 요소", 텍사스 주 모란에서; 캐롤, J., 디자인 이론적 개념, 기술, 사용, 로렌스 얼바움 어소시에이츠, 53-106페이지
  26. ^ a b Lee, J. (1991), "설계 근거 기록을 위한 Potts and Bruns 모델 확장", 제13회 소프트웨어 엔지니어링 국제회의(ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, 페이지 114-125.
  27. ^ Burge, J. (2005), 디자인을 이용한 소프트웨어 엔지니어링, Worcester Polytechnical Institute, 컴퓨터 과학부
  28. ^ a b Berry Boehm; Kitapci, H. (2006), A.H. Dutoit의 "WinWin 접근법: 근거 캡처 및 사용을 위한 요건 네고시에이션 도구 사용", R. McCall, Mistrik, I. 등, Springer의 소프트웨어에서의 근거 관리.
  29. ^ 베리봄(1998)."소프트웨어 개발과 확장의 나선형 모델"컴퓨터 21(5): 61~72
  30. ^ 보스, P. (1995년)"WinWin 콜라보레이션 프레임워크 의사결정 유지 모델"Knowledge Based Software Engineering (KBSE '95).
  31. ^ a b Dutoit, A.; McCall, B.; Mistrik et al., ed. (2006), 소프트웨어 엔지니어링의 이론적 관리, Springer 페이지 1-48.
  32. ^ O. 짐머만, C.Miksovic, J. Küster, IT 서비스의 건축 지식 관리를 위한 레퍼런스 아키텍처, 메타모델 및 모델링 원칙시스템 및 소프트웨어 저널, Elsevier.제85호 2012년 9월 제9호
  33. ^ Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) 프로젝트 정의에 디자인 이론적 시스템 적용– 연구 프로젝트 확립.2007년 4월 27일 취득한 웨이백 머신에서 2007-09-28 아카이브 완료
  34. ^ Moran, T.; Carroll, J., ed. (1996), 디자인 이론적 개념, 기술, 사용, 로렌스 얼바움 어소시에이츠,
  35. ^ Dutoit, 소프트웨어 엔지니어링의 이론적 관리

추가 정보

책들
  • Burge, JE; Carroll, JM; McCall R; Mistrík I (2008). Rationale-Based Software Engineering. Heidelberg: Springer-Verlag.
  • Dutoit, AH; McCall R; Mistrík I; Paech B (2006). Rationale Management in Software Engineering. Heidelberg: Springer-Verlag.
  • Conklin, J (2005). Dialogue Mapping. Weinheim: Wiley-VCH Verlag.
  • Kirschner, PA; Buckingham-Shum SJ; Carr CS (2003). Visualizing Argumentation: Software Tools for Collaborative and Educational Sense-Making. London: Springer-Verlag.
  • Moran, T; Carroll J (1996). Design Rationale Concepts, Techniques, and Use. NJ: Lawrence Erlbaum Associates.
특별한 문제
  • 인공지능 엔지니어링 설계, 분석 및 제조 (AIEDAM), 스페셜 호: 2008년 가을, Vol.22 No.4 디자인 근거 http://web.cs.wpi.edu/ ~aiedam/Special Issues/Burge-Bracewell.html
  • AIEDAM, 디자인 이유의 표현과 사용에 관한 특집호, 1997년, 제11권 제2호, 케임브리지 대학 출판부
워크샵
  • SHARing and Reusing Architecture Knowledge - 아키텍처, 근거 및 설계 의도 (SHAARK/ADI 2007), (RC.rug.nl)에 관한 제29차 워크샵.소프트웨어 엔지니어링에 관한 회의 (ICSE 2007) (CS.ucl.ac.uk
  • 설계이유 워크숍: 문제와 진전(Muohio.edu)
  • 워크숍 의장: Janet Burge와 Rob Braceswell, 2006년 7월 9일 디자인, 컴퓨팅, 인식과 함께 개최.에인트호벤, (wwwfaculty.arch.usyd.edu.au) 네덜란드

외부 링크

  • 비시플리틱.austhink.com: 설계상의 이유와 의사결정의 근거를 보다 폭넓게 고려하여 설계된 상용 소프트웨어 패키지입니다.그래피컬 인터페이스, 공유 기능.
  • 개요:IBIS를 기반으로 한 비주얼 지식 관리 기능을 제공하는 하이퍼 미디어 도구입니다.Java 어플리케이션(바이너리 및 소스)을 무료로 이용할 수 있으며, 매년 만나는 액티브한 사용자 커뮤니티를 이용할 수 있습니다.
  • designVUE: IBIS 및 기타 방법을 기반으로 한 시각적 지식 수집 도구입니다.무료 Java 응용 프로그램.
  • SEURAT: 근거 캡처 및 사용을 소프트웨어 개발 환경과 통합하는 Eclipse 플러그인입니다.SEURAT는 GitHub([1])의 오픈 소스 프로젝트로 이용 가능합니다.