Odůvodnění návrhu - Design rationale

Konstrukční struktura založená na rozhodování, která pokrývá oblasti inženýrský design, konstrukční zdůvodnění a analýza rozhodnutí.
detail Stromu poznání po Diderot & d'Alembert's Encyclopédie, Chrétien Frédéric Guillaume Roth
Informační mapování
Témata a pole
Node-link přístupy
Viz také

A zdůvodnění návrhu je explicitní dokumentací důvodů za rozhodnutí vyrobeno kdy projektování A Systém nebo artefakt. Jak původně vyvinuli W.R. Kunz a Horst Rittel, se snaží poskytnout zdůvodnění návrhu argumentace - struktura založená na politickém procesu spolupráce při řešení zlé problémy.[1]

Přehled

Důvodem návrhu je výslovný seznam rozhodnutí vyrobeno během a proces návrhu a důvody, proč byla tato rozhodnutí učiněna.[2] Jeho primárním cílem je podpora návrháři poskytnutím prostředků záznam a komunikovat argumentace a zdůvodnění procesu návrhu.[3] Mělo by tedy zahrnovat:[4]

  • důvody rozhodnutí o návrhu,
  • ospravedlnění toho,
  • další zvažované alternativy,
  • - vyhodnocené kompromisy a -
  • argumentace, která vedla k rozhodnutí.

Do studia racionálních návrhů je zapojeno několik vědeckých oblastí, jako např počítačová věda[2] kognitivní věda,[3] umělá inteligence,[5] a řízení znalostí.[6] Pro podporu konstrukčních důvodů byly navrženy různé rámce, jako QOC, DRCS, IBIS a DRL.

Dějiny

Zatímco formáty argumentace lze vysledovat zpět Stephen Toulmin práce v 50. letech[7] údaje, nároky, rozkazy, podpory a vyvrácení, původ konstrukčních důvodů lze vysledovat zpět k W.R. Kunzovi a Horst Rittel je[1] vývoj Emisní informační systém (IBIS) notace v roce 1970. Od té doby bylo navrženo několik variant IBIS.

  • První byla procedurální hierarchie problémů (PHI), poprvé popsaná v disertační práci Raye McCalla[8] i když v té době nebyl pojmenován.
  • IBIS byl také upraven, v tomto případě na podporu softwarového inženýrství, společností Potts & Bruns.[9] Přístup Potts & Bruns byl poté rozšířen o Language Representation Language (DRL).[10] který sám byl rozšířen o RATSpeak.[5]
  • Možnosti a kritéria otázek (QOC), známé také jako Analýza návrhového prostoru[11][12] je alternativní reprezentace argumentačního argumentu, stejně jako Win-Win[13] a Rozhodovací doporučení a model záměru (DRIM).[14]

Prvním systémem racionálního managementu (RMS) byl PROTOCOL, který podporoval PHI, následovaný dalšími systémy založenými na PHI MIKROPOLIS a PHIDIAS. První systém poskytující podporu IBIS byl Hans Dehlinger STIEC.[15] Rittel vyvinul malý systém v roce 1983 (také nezveřejněný) a známější gIBIS (grafický IBIS) byl vyvinut v roce 1987.[16]

Ne všechny úspěšné DR přístupy zahrnují strukturovanou argumentaci. Například přístup Carrolla a Rossona k analýze scénářů a nároků[17] zachycuje odůvodnění ve scénářích, které popisují, jak se systém používá a jak dobře funkce systému podporují cíle uživatelů. Přístup Carrolla a Rossona k logistice designu má pomoci návrhářům počítačového softwaru a hardwaru identifikovat základní kompromisy designu a vyvodit závěry o dopadu možných designových zásahů.[18]

Klíčové pojmy v logice návrhu

Existuje řada způsobů, jak charakterizovat DR přístupy. Některé klíčové charakteristické rysy jsou způsob, jakým je zachycen, jak je znázorněn a jak jej lze použít.

Zdůvodnění zachycení

Zdůvodnění zachycení je proces získávání logických informací do logického managementu

Zachytávací metody
  • Metoda zvaná „Rekonstrukce“[4] zachycuje zdůvodnění v nezpracované podobě, jako je video, a poté je rekonstruuje do strukturovanější podoby.[19] Výhodou metody Rekonstrukce je, že lze racionálně zachytit rationales a proces zachycení návrháře nenaruší. Ale tato metoda by mohla vyústit ve vysoké náklady a předsudky osoby, která produkuje racionály
  • "Záznam a přehrávání"[4] metoda jednoduše zachycuje zdůvodnění, jak se odvíjejí. Zdůvodnění jsou synchronně zachycena v a video konference nebo asynchronně zachyceny prostřednictvím nástěnka nebo e-mailovou diskusi. Pokud má systém neformální a poloformální zastoupení, bude metoda užitečná.
  • „Metodický vedlejší produkt“[4] metoda zachycuje zdůvodnění během procesu návrhu podle schématu. Ale je těžké navrhnout takové schéma. Výhodou této metody je její nízká cena.
  • S předem vytvořenou bohatou znalostní bází (KB) „Učeň“[4] metoda zachycuje racionální otázky kladením otázek, když je matoucí nebo nesouhlasný s návrhářovým jednáním. Tato metoda přináší výhody nejen uživateli, ale i systému.
  • V „automatické generaci“[4] metoda, návrhová zdůvodnění jsou automaticky generována z historie provádění při nízkých nákladech. Má schopnost udržovat konzistentní a aktuální zdůvodnění. Ale náklady na kompilaci historie provádění jsou vysoké kvůli složitosti a obtížnosti některých problémů se strojovým učením.
  • „Historik“[20] metoda umožňuje osobě nebo počítačovému programu sledovat všechny akce návrháře, ale nedělá návrhy. Racionály jsou zachyceny během procesu návrhu.[19]

Odůvodnění zastoupení

Volba reprezentace zdůvodnění návrhu je velmi důležitá, aby se zajistilo, že rozumíme tomu, co zachycujeme, a co můžeme efektivně využívat. Podle stupně formality lze přístupy, které se používají k vyjádření návrhových důvodů, rozdělit do tří hlavních kategorií: neformální, semiformální nebo formální.[4] V neformální reprezentaci lze racionály zaznamenat a zachytit pomocí našich tradičně přijímaných metod a médií, jako jsou textové procesory, zvukové a obrazové záznamy nebo dokonce ruční zápisy. Tyto popisy však ztěžují automatickou interpretaci nebo jiné počítačové podpory. Ve formálním vyjádření musí být odůvodnění shromážděno v přísném formátu, aby bylo možné důvody interpretovat a porozumět počítačům. Avšak vzhledem k přísnému formátu odůvodnění definovanému formálními reprezentacemi může člověk těžko pochopit obsah a proces zachycení logického návrhu bude vyžadovat více úsilí k dokončení, a proto se stává rušivějším.

Semiformální reprezentace se snaží spojit výhody neformálních a formálních reprezentací. Na jedné straně by zachycené informace měly být schopny zpracovat počítače, aby bylo možné poskytnout více počítačové podpory. Na druhou stranu by postup a metoda použité k zachycení informací o konstrukčních důvodech neměly být příliš rušivé. V systému se semiformálním vyjádřením jsou navrženy očekávané informace a uživatelé mohou zachytit zdůvodnění podle pokynů buď k vyplnění atributů podle některých šablon, nebo pouze k popisu v přirozeném jazyce.[4]

Modely založené na argumentaci

Toulminův model
Jedním z běžně přijímaných způsobů reprezentace zdůvodnění semiformálního designu je strukturování zdůvodnění návrhu jako argumentace.[5] Nejdříve založený na argumentačním modelu, který používá mnoho systémů racionálního návrhu, je Toulminův model.[7] The Toulminův model definuje pravidla argumentace zdůvodnění návrhu šesti kroky:[21]
  1. Nárok je podán;
  2. Jsou poskytnuty podpůrné údaje;
  3. Warrant poskytuje důkazy o existujících vztazích;
  4. Rozkaz lze podpořit podporou;
  5. K dispozici jsou kvalifikace modelů (některé, mnoho, většina atd.);
  6. Zvažují se také možné vyvrácení.
Výhodou modelu Toulmin je, že používá slova a pojmy, kterým většina lidí snadno rozumí.
Emisní informační systém (IBIS)
Dalším důležitým přístupem k argumentaci konstrukčních důvodů je IBIT společnosti Rittel a Kunz (Emisní informační systém ),[1] což ve skutečnosti není softwarový systém, ale argumentační notace. Byl implementován v softwarové podobě společností gIBIS (grafický IBIS), itIBIS (testovaný IBIS), Kompendium a další software.[22][23] IBIS používá některé logické prvky (označované jako uzly), jako jsou problémy, pozice, argumenty, rezoluce a několik vztahů, jako je obecnější než, logický nástupce, dočasný nástupce, nahrazuje a podobně, k propojení diskusí o problémech.
Procedurální hierarchie problémů (PHI)
PHI (Procedural Hierarchy of Issues)[24] rozšířil IBIS na nekontroverzní problémy a předefinoval vztahy. PHI přidává vztah subissue, což znamená, že řešení jedné emise závisí na řešení jiné emise.
Dotazy, možnosti a kritéria (QOC)
QOC (Dotazy, možnosti a kritéria)[25] se používá pro analýzu návrhového prostoru. Podobně jako IBIS identifikuje QOC klíčové konstrukční problémy jako otázky a možné odpovědi na otázky jako možnosti. QOC navíc používá kritéria k explicitnímu popisu metod k vyhodnocení možností, jako jsou požadavky, které mají být splněny, nebo požadované vlastnosti. Možnosti jsou pozitivně nebo negativně spojeny s kritérii a tyto vazby jsou definovány jako hodnocení.
Rozhodovací jazyk (DRL)
DRL (Language Representation Language)[26] rozšiřuje Potts and Brunsův model DR[9] a definuje primární prvky jako rozhodovací problémy, alternativy, cíle, nároky a skupiny. Lee (1991) tvrdí, že DRL je expresivnější než jiné jazyky.[26] DRL se zaměřuje více na reprezentaci rozhodování a jeho zdůvodnění, než na zdůvodnění návrhu.
RATSpeak
Na základě DRL je RATSpeak vyvinut a používán jako reprezentační jazyk v SEURAT (Software Engineering Using RATionale).[27] RATSpeak bere v úvahu požadavky (funkční a nefunkční) jako součást argumentů pro alternativy rozhodovacích problémů. SEURAT také obsahuje Argument Ontology, což je hierarchie typů argumentů a zahrnuje typy deklarací použitých v systému.
Spirálový model WinWin
Spirálový model WinWin, který se používá v přístupu WinWin,[28] přidává vyjednávací aktivity WinWin, včetně identifikace klíčových zúčastněných stran systémů a identifikace podmínek výhry každého zúčastněného subjektu a vyjednávání, do popředí každého cyklu model vývoje spirálového softwaru[29] za účelem dosažení vzájemně uspokojivé (winwin) dohody pro všechny zúčastněné strany projektu.
Ve spirálovém modelu WinWin jsou cíle každého zainteresovaného subjektu definovány jako podmínky výhry. Jakmile dojde ke konfliktu mezi podmínkami výhry, bude to zachyceno jako problém. Poté zúčastněné strany vymyslí Možnosti a prozkoumají kompromisy k vyřešení problému. Když je problém vyřešen, je dosaženo dohody, která splňuje podmínky pro zisk zúčastněných stran a zachycuje dohodnutou možnost. Odůvodnění návrhu rozhodnutí je zachyceno během procesu modelu WinWin a zúčastněné strany a návrháři ho využijí ke zlepšení svého pozdějšího rozhodování.[28] Spirálový model WinWin snižuje režii zachycení logických zdůvodnění tím, že zúčastněným stranám poskytuje přesně definovaný proces vyjednávání. v[30] je definována ontologie rozhodovacího zdůvodnění a jejich model využívá ontologii k řešení problému podpory udržování rozhodování v rámci spolupráce WinWin.
Návrhové doporučení a model záměru (DRIM)
V SHARED-DRIM se používá DRIM (Design Design and Intent Model).[14] Hlavní strukturou DRIM je návrh, který se skládá ze záměrů každého designéra, doporučení, která splňují záměry, a odůvodnění doporučení. Jednání jsou také nutná, pokud existují konflikty mezi záměry různých návrhářů. Přijaté doporučení se stává rozhodnutím o návrhu a během tohoto procesu se také zaznamenávají důvody nepřijatých, ale navrhovaných doporučení, což může být užitečné při iteračním návrhu a / nebo údržbě systému.

Aplikace

Odůvodnění návrhu má potenciál být použito mnoha různými způsoby. Jedna sada použití, definovaná Burge a Brownem (1998),[19] jsou:

  • Ověření návrhu - Odůvodnění návrhu lze použít k ověření, zda rozhodnutí o návrhu a samotný produkt jsou odrazem toho, co návrháři a uživatelé skutečně chtěli.
  • Hodnocení návrhu - Odůvodnění návrhu se používá k vyhodnocení různých alternativ designu diskutovaných během procesu návrhu.
  • Údržba návrhu - Odůvodnění návrhu pomáhá určit změny, které jsou nezbytné pro úpravu návrhu.
  • Opětovné použití návrhu - Odůvodnění návrhu se používá k určení, jak lze stávající návrh znovu použít pro nový požadavek se změnami nebo bez nich. Pokud je potřeba design upravit, navrhne DR také to, co je třeba v návrhu upravit.
  • Výuka designu - Odůvodnění návrhu lze použít jako zdroj pro výuku lidí, kteří nejsou obeznámeni s designem a systémem.
  • Komunikace designu - Odůvodnění návrhu usnadňuje lepší komunikaci mezi lidmi, kteří se podílejí na procesu návrhu, a pomáhá tak přijít s lepším designem.
  • Pomoc s návrhem - Odůvodnění návrhu lze použít k ověření rozhodnutí o návrhu učiněných během procesu návrhu.
  • Návrhová dokumentace - Odůvodnění návrhu se používá k dokumentaci celého procesu návrhu, který zahrnuje jednání zasedací místnosti, diskutované alternativy, důvody rozhodnutí o návrhu a přehled produktu.

DR používají výzkumné komunity v oblasti softwarového inženýrství, strojírenství, umělé inteligence, stavebnictví a výzkumu interakce člověka s počítačem. V softwarovém inženýrství by to mohlo být použito k podpoře návrhářských nápadů během analýzy požadavků, zachycování a dokumentování návrhových schůzek a předpovídání možných problémů díky novému návrhovému přístupu.[31] v softwarová architektura a návrh řešení outsourcingu, může ospravedlnit výsledek architektonická rozhodnutí a slouží jako průvodce designem.[32]Ve stavebnictví pomáhá koordinovat různé práce, které designéři provádějí současně v různých oblastech stavebního projektu. Pomáhá také návrhářům porozumět a respektovat vzájemné myšlenky a vyřešit případné problémy.[33]

Správce projektu může také použít vedoucí projektu k udržení aktuálního plánu projektu a stavu projektu. Členové projektového týmu, kteří zmeškali návrhovou schůzku, se také mohou vrátit zpět k DR, aby se dozvěděli, o čem se diskutovalo na konkrétním tématu. Nevyřešené problémy zachycené v DR by mohly být použity k uspořádání dalších schůzek k těmto tématům.[31]

Odůvodnění návrhu pomáhá návrhářům vyhnout se stejným chybám, jaké učinily předchozí návrhy. To může být také užitečné, aby se zabránilo duplicitě práce.[5] V některých případech by DR mohla ušetřit čas a peníze při aktualizaci softwarového systému z jeho předchozích verzí.[2]

Existuje několik knih a článků, které poskytují vynikající přehledy racionálních přístupů aplikovaných na HCI,[34] Inženýrský design[4] a softwarové inženýrství.[35]

Viz také

Reference

  1. ^ A b C Kunz, W .; Rittel, H. (1970), Problémy jako prvky informačních systémů. Working Paper 131, Center for Urban and Regional Development, University of California Berkeley
  2. ^ A b C Jarczyk, Alex P .; Löffler, Peter; Shipman III, Frank M. (1992), „Odůvodnění návrhu pro softwarové inženýrství: průzkum“, 25. mezinárodní konference o systémových vědách na Havaji, 2, str. 577-586
  3. ^ A b Horner, J .; Atwood, M.E. (2006), „Effective Design Rationale: Understanding the Barriers“, Dutoit, A.H .; McCall, R .; Mistrík, I. a kol., Rationale Management in Software Engineering, Springer Berlin Heidelberg, str. 73-90
  4. ^ A b C d E F G h i Lee, J. (1997). „Systems Rationale Systems: Understand the issues“. Expert IEEE 12 (3): 78–85
  5. ^ A b C d Burge, J. E.; Brown, D.C. (2000), „Reasoning with Design Rationale“, Gero, J., Umělá inteligence v designu '00, Nizozemsko: Kluwer Academic Publ., S. 611–629
  6. ^ Xin, W .; Guangleng, X. (2001), „Odůvodnění návrhu jako součást technické paměti společnosti“, Systémy, člověk a kybernetika, str. 1904 - 1908.
  7. ^ A b Stephen Toulmin (1958). Použití argumentů. Cambridge: Cambridge University Press.
  8. ^ McCall, R. (1978), O struktuře a využití emisních systémů v designu, Doktorská disertační práce, University of California, Berkeley, University Microfilms
  9. ^ A b Potts, C .; Burns, G. (1988), „Zaznamenávání důvodů pro konstrukční rozhodnutí“, 10. mezinárodní konference o softwarovém inženýrství (ICSE '1988), str. 418-427
  10. ^ Lee, J. (1991), „Rozšíření modelu Potts and Bruns pro záznam logických důvodů“, Sborník z 13. mezinárodní konference o softwarovém inženýrství (ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, str. 114-125
  11. ^ Maclean, A .; Young, RM .; Moran, T. (1989), „Odůvodnění návrhu: argument za artefaktem“, SIGCHI Bull. 20, str. 247-252114-125
  12. ^ Maclean, A .; Young, RM .; Bellotti, VME .; Moran, T. (1996), „Questions, Options, and Criteria: Elements of Design Space Analysis“, in Moran, T .; Carroll, J., Koncepty, techniky a použití návrhu, Lawrence Erlbaum Associates, str. 53-106
  13. ^ Barry Boehm Ross, R (1989). „Řízení softwarového projektu Theory-W: principy a příklady.“. Transakce IEEE v softwarovém inženýrství 18 (7): 902-916.
  14. ^ A b Pena-Mora, F .; Sriram, D .; Logcher, R. (1993), "SHARED-DRIMS: SHARED Design Doporučení - systém řízení záměru", Řízení umožňující infrastrukturu technologií pro kolaborativní podnik, IEEE Press, Morgantown, WV, str. 213-221
  15. ^ Dehlinger, H. (1978), Projekt STIEC: Systémová analýza tvorby a šíření vědeckých a technologických informací v Evropském společenství " Zpráva č. 26: Zpráva o šarži - verze STIEC, Heidelberg / Stuttgart
  16. ^ Conklin, J .; Yakem Begemanovic, M. (1988). „gIBIS: Hypertextový nástroj pro průzkumnou diskusi o politice“. Transakce ACM na kancelářských informačních systémech 6 (4): 303-331.
  17. ^ Carroll, JM; Rosson, M (1992). "Obcházení cyklu úkolů a artefaktů: jak vytvářet nároky a navrhovat podle scénáře". ACM Trans. Inf. Syst. 10 (2): 181-212
  18. ^ Carroll, J. M. a Rosson, M. B. (2003). Odůvodnění návrhu jako teorie. Modely, teorie a rámce HCI: směrem k multidisciplinární vědě, 431-461.
  19. ^ A b C Burge, J .; Brown, D.C. (1998), Odůvodnění návrhu: Typy a nástroje, technická zpráva, Worchester Polytechnic Institute, Computer Science Dept., vyvoláno 27. dubna 2007
  20. ^ Chen, A .; McGinnis, B .; Ullman, D .; Dietterich, T. (1990), „Reprezentace znalostí o historii designu a její základní implementace do počítače“, 2. mezinárodní konference o teorii a metodologii designu, Chicago, IL, str. 175-185
  21. ^ Reynolds, Chris (2000), Co je Toulminův model? Archivováno 2007-08-25 na Wayback Machine Příspěvek na soustředění.net.
  22. ^ Conklin, J .; Yakemovic, K. (1991). „Procesně orientovaný přístup k odůvodnění návrhu“. Interakce člověk-počítač 6 (3 & 4): 357–391.
  23. ^ Rittel, Horst W. J.; Noble, Douglas (leden 1989). Emisní informační systémy pro návrh (PDF) (Technická zpráva). Berkeley, CA: Institut městského a regionálního rozvoje, University of California. OCLC  20155825. 492.
  24. ^ McCall, R.J. (1991). „PHI: Koncepční základ pro design Hypermedia“. Designové studie 12 (1): 30–41.
  25. ^ Maclean, A .; Young, RM .; Bellotti, VME .; Moran, T. (1996), „Questions, Options, and Criteria: Elements of Design Space Analysis“, in Moran, T .; Carroll, J., Koncepty, techniky a použití racionálního návrhu, Lawrence Erlbaum Associates, s. 53-106
  26. ^ A b Lee, J. (1991), „Rozšíření modelu Potts and Bruns pro záznam logických důvodů“, Sborník z 13. mezinárodní konference o softwarovém inženýrství (ICSE '13), IEEE Computer Society Press, Los Alamitos, CA, str. 114-125
  27. ^ Burge, J. (2005), Softwarové inženýrství s využitím designu RATionale, Worchester Polytechnic Institute, Computer Science Dept
  28. ^ A b Barry Boehm; Kitapci, H. (2006), „Přístup WinWin: Využití nástroje vyjednávání požadavků pro zachycení a použití zdůvodnění“, Dutoit, A.H .; McCall, R .; Mistrík, I. a kol., Zdůvodnění řízení v softwarovém inženýrství, Springer Berlin Heidelberg, str. 173-190
  29. ^ Barry Boehm (1998). „Spirálový model vývoje a vylepšení softwaru“. Počítač 21 (5): 61–72
  30. ^ Bose, P. (1995). "Model pro údržbu rozhodnutí v rámci WinWin Collaboration Framework". Znalostní softwarové inženýrství (KBSE '95).
  31. ^ A b Dutoit, A .; McCall, B .; Mistrik a kol., Eds. (2006), Zdůvodnění řízení v softwarovém inženýrství, Springer str. 1-48.
  32. ^ O. Zimmermann, C. Miksovic, J. Küster, Reference Architecture, Metamodel and Modeling Principles for Architectural Knowledge Management in Information Technology Services. Journal of Systems and Software, Elsevier. Sv. 85, číslo 9, září 2012
  33. ^ Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Aplikace systémů odůvodnění na definici projektu - založení výzkumného projektu. Archivováno 2007-09-28 na Wayback Machine Citováno dne 27. dubna 2007
  34. ^ Moran, T .; Carroll, J., eds. (1996), Koncepty, techniky a použití racionálního návrhuLawrence Erlbaum Associates,
  35. ^ Dutoit, zdůvodnění řízení v softwarovém inženýrství

Další čtení

Knihy
  • Burge, JE; Carroll, JM; McCall R; Mistrík I (2008). Logické softwarové inženýrství. Heidelberg: Springer-Verlag.
  • Dutoit, AH; McCall R; Mistrík I; Paech B (2006). Zdůvodnění řízení v softwarovém inženýrství. Heidelberg: Springer-Verlag.
  • Conklin, J (2005). Mapování dialogů. Weinheim: Wiley-VCH Verlag.
  • Kirschner, PA; Buckingham-Shum SJ; Carr CS (2003). Vizualizace argumentů: Softwarové nástroje pro spolupráci a vytváření smyslů ve vzdělávání. London: Springer-Verlag.
  • Moran, T; Carroll J (1996). Koncepty, techniky a použití racionálního návrhu. NJ: Lawrence Erlbaum Associates.
Zvláštní vydání
  • Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM), Special Issue: Fall 2008, Vol.22 No.4 Design Rationale http://web.cs.wpi.edu/~aiedam/SpecialIssues/Burge-Bracewell.html
  • Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM), Special Issue on Representing and Using Design Rationale, 1997, Vol.11 No.2, Cambridge University Press
Workshopy
  • Druhý seminář o SHAringu a opětovném použití architektonických znalostí - architektura, zdůvodnění a záměr (SHARK / ADI 2007), (RC.rug.nl ) jako součást 29. Int. Konf. o softwarovém inženýrství (ICSE 2007) (CS.ucl.ac.uk )
  • Workshop o zdůvodnění designu: Problémy a pokrok (Muohio.edu )
  • Workshop Chairs: Janet Burge a Rob Bracewell, konané 9. července 2006 ve spolupráci s Design, Computing a Cognition '06. Eindhoven, (wwwfaculty.arch.usyd.edu.au ) Holandsko

externí odkazy

  • Bcisive.austhink.com: Komerční softwarový balíček navržený pro širší zdůvodnění návrhu a zdůvodnění rozhodnutí. Grafické rozhraní, možnosti sdílení.
  • Kompendium: Hypermediální nástroj, který poskytuje možnosti správy vizuálních znalostí založené na IBIS. Zdarma Java aplikace, binární a zdrojové, s aktivní komunitou uživatelů, kteří se každoročně scházejí.
  • designVUE: Nástroj pro vizuální zachycení znalostí založený na IBIS a dalších metodách. Zdarma Java aplikace.
  • SEURAT: Zásuvný modul Eclipse, který integruje zdůvodnění a použití s ​​vývojovým prostředím softwaru. SEURAT je k dispozici jako projekt open source v github ([1] ).