グループウェアの ソフトウェア開発への応用 グループウェアと ソフトウェア工学(SE)とのかかわり ◗ グループウェアをどう開発するか (SE for Groupware) → 特に、ユーザの多様性が問題になる 教科書の6.4節 ◗ グループウェアによるソフトウェア開発支援 (Groupware for SE) → ここで解説する Groupware for SE 分散開発の問題点 ◗ 開発作業という作業の特性に着目 ◗ インフォーマルコミュニケーションの不足 ◗ コンタクト先に関する知識の不足 ◗ コミュニケーションの開始が困難 z z z z 技術文書管理 顧客との折衝 プロジェクト管理 プロセス評価と品質保証 ◗ 特に扱う対象がソフトウェアであることに着目 z z マルチユーザのプログラムエディタ コードインスペクション支援 Design Rationale (設計理由、設計動機) z z z 誰がコンタクト可能か(awareness) 時差 反応が悪い ◗ コミュニケーション技術 z ツール、文化、言語 ◗ コミュニケーション意欲 Design Rationale と 議論支援システム z z z z 要求項目の優先度づけ 複数の対案の比較 設計の修正履歴 ... 設計 議論支援 システム システム稼動 ◗ 設計結果(Artifact: 仕様書、設計図、プログ ラム) を導くまでに行われた活動 保守 ◗ 保守の際重要な情報であるにもかかわらず、 これまでは捨てられていた。 Design Rationale 1 設計理由記録の利点 設計理由記録の利点 [垂水, 92] [垂水, 92] ◗ システム保守の際、変更可能な設計と不可 能な設計を識別できる。 ◗ 特に深い理由のない設計結果を過剰に重要 視して設計の見直し機会を逸することを防ぐ。 ◗ 過去の事例や他人の設計を再利用する際の 資料になる。 ◗ 議論の経緯を忘れることによって発生する議 論の蒸し返しを防止する。 ◗ 問題点の議論の積み残しを防止する。 ◗ 議論の記録を意識することで、議論そのもの が合理的・論理的になる。 問題点 議論記録モデル ◗ 現場では、「結果」のドキュメントすら残してい く余裕がない。まして「過程」の記録は? → ツールの使い勝手、議論との連携、... ◗ IBIS 系 z z z ◗ 「過程」をどのような構造で表現したらよいの か? → 議論モデル gIBIS システム Potts のモデル QOC モデル ◗ 知識処理指向 z z 推論との相性 SIBYL システム (DRLモデル) IBIS モデル (既出) IBIS モデルによる議論の例 (Issue Based Information System) GE NERALIZES or SPECIALIZES ISSUE REPLACES, Q UESTIONS, or IS-SUGGESTED-BY 問題1 (Issue) 応答 賛成 案1 意見1 (Position) (Argument) 反対 Q UESTIONS, or IS-SUGGESTED-BY Q UESTIONS, or IS-SUGGESTED-BY RESP O N DS-TO 質問 意見2 案2 問題2 賛成 特殊化 意見3 SUPP ORTS POSITION ARGUMENT O BJECTS-TO 案2‘ 特殊化 意見3‘ 2 IBIS の適用実験 議論支援システムの例 [Yakemovic, CSCW90] gIBIS (MCC) Jeff Conklin, et al.: gIBIS: A Hypertext Too Policy Discussion; Proc. CSCW’88, pp. 140-1 概要: IBIS モデルに基く議論をグラフィカルユーザ インタフェースで支援。 ◗ itIBIS (gIBIS のテキストI/F版) をソフト開発現場に 適用(18ヶ月,8000ノード) ◗ 利点 z z z z z Potts のモデル 議論の整理が容易 問題点の早期発見によるコスト削減 視点の異なるレビュー Agenda 作成が容易で会議が生産的に チーム内外とのコミュニケーションに有効 QOC モデル [MacLean, 91] M O DIFIES Artifact Step O: Permanent O: Appearing RAISES REVIE WS Q: How to make it appear? RESP O N DS-TO SUPP ORTS C: Low user effort C: Screen compactness C: Continuous feedback to user C O NTRIBUTES-TO Issue CITES Q: How to display? O: Natural cursor movement C:..... O: Scroll button C:..... Position Argument O BJECTS-TO SELECTED? QOC モデル Q: Question O: Option C: Criteria Positive Assessment Negative Assessment Question の派生 QOC と IBIS の比較 [MacLean, 91] ◗ QOC は ... Option1 z Option2 Criterion1 Argument1 z Argument2 z Argument3 Argument4 「設計判断」に用途を限定 Argument は個々の意見表明であるのに対し、 Criteria は判断基準を与える IBIS は議論したその場でモデルを構成するのに 向いているが、QOC は議論を整理しながら作成 する。 Supports Challenges 3 DRLモデルのオブジェクト(一部) 議論支援システムの例 SIBYL (MIT) Alternative Jintae Lee: SIBYL: A Tool for Managing Group Rationale; Proc. CSCW’90, pp. 79-92 (1990) DRL Object 概要: DRL モデルに基く議論支援システムを OVAL 上で構築。設計対案比較の自動化も 狙った。 Achieves(alternative, goal) Goal Decision Proble m Claim Is Related to Is a Good Alternative for (alternative, decision proble m) Supports(claim,claim) Denies(claim,claim) Presupposes(claim,claim) Is A Subgoal Of (goal,goal) Question Is a Subdecision of (decision proble m, decision proble m Group Viewpoint Answers(claim,question) Procedure Suggests(object,object) Raises(object,question) Status DRLモデルによるグラフの例 問題 副目標 Decision Problem is-a-subgoal-of 目標2 Goal 解決案 is-a-goodalternative-for 副目標 目標1 Goal is-a-subgoal-of 賛成 supports 目標達成 achieves 否定 denies 案1 Alternative 目標1‘ Goal ウィンドウ コマンド の与え方 主張3 Claim 影響 influences 質問 Question dim状態でも 見えているだけで 邪魔だ。 スクリーントップ のメニューバー にて denies カレントウィンドウに 適用できないコマンド が表示されて邪魔だ。 コマンドがいつ も決まった場所 で見つけられる。 achieves is-a-goodalternative-for ウィンドウ コマンド とは? 使いやすい 各ウィンドウ にて achieves is-a-goodalternative-for 解答 answers Mac のメモリ は増えている のでgoalに すべきでない。 answers ウィンドウの コンテンツ についての コマンド is-a-subgoal-of コマンドに アクセス しやすい スクリーンを 散らかさない 実装が 小規模 achieves スクリーントップ のメニューバー にて 主張4 Claim DRL モデルによる議論例 denies suggests denies 賛成 supports 目標達成 achieves 不要なコマンドは dim 状態に すれば良い。 Co m m ents(claim,object) DRLモデルによる議論の例 主張2 Claim 目標達成 achieves 案2 Alternative 主張1 Claim Decided achieves achieves DRLモデルの特徴 コマンドに アクセス しやすい denies supports ◗ 豊富な関係語彙・柔軟な構造で議論を忠実 に再現 ◗ claim に対する claim と、claim と claim との 関係に対する claim を区別できる。 ◗ 語彙の拡張が容易 ◗ 欠点 z z 関係の語彙が ad hoc に決められている 記録に熟練を要する 4 GIMMe (コロラド大) 演習問題(A) ◗ 開発者間の電子メールをそのまま蓄積 ◗ 自然言語処理による索引づけ ◗ Web インターフェースで検索 ◗ 教官・学生を含め研究室の多くの人が満足 するコンパの会場を選定したい。3つの会場 候補を挙げ、 IBIS, QOC, DRL のモデルを用 いて各会場候補を比較・議論せよ。 演習問題(B) スパイラルモデルとネゴシエーション (WinWin) ◗ 研究室での研究開発・業務などで最近行った 設計上あるいはその他の業務上の比較判断 について、IBIS モデルを用いて議論し直し、 QOC モデルを用いた表記で結果を整理せよ。 ◗ 過去の自分の判断過程と今回の判断過程を 比較して、反省点があれば述べよ。 オリジナルのスパイラルモデル WinWin のスパイラルモデル コードインスペクション支援 ◗ ICICLE z z z X Windows 上のツール、対面型 インスペクタ、司会、書記などの役割を支援 コメントの共有 ◗ hypercode z z Web 上のツール、分散型 ソースをハイパーテキスト化し、コメントをつける 5 ユーザ参画型設計 (Participatory Design) JAD (Joint Application Design) と PD (Participatory Design) JAD ◗ 発注の最初と納品時だけでなく、途中の設計 過程にもユーザが参画する。 ◗ POLITeam が良い例。 ◗ スカンジナビアンアプローチとも言う 評価基準 背景と理論 目標 はじまり テーマ PD 量 質 ソフトウェア工学 グループダイナミクス 労使関係 グループ学習 システムの改善 作業環境の改善 北米産業界 スカンジナビアの政府、組合、 大学 チームワーク、すばや い設計 民主的作業環境・企業経営、 人間性など ユーザの立場 有力なユーザの意見も エンドユーザの意見を必ず反 参考にする POLITeam における Participatory Design 1. システム導入の準備: ユーザインタビューによる要求分析、システムの調整 2. システムの導入: トレーニング、インストール、現場訪問 3. 現場実用による評価: 現場訪問、ユーザワークショップ、インタビュー 4. システム設計: 再設計と新機能の設計のためのデザインワークショッ プ 5. ステップ2に戻る 映 POLITeam の開発 ◗ ユーザの代弁者 ◗ ワークショップの繰り返し Copied from GMD 総合的支援環境 ◗ Flecse (Purdue) ◗ PACT (Stanford) z マルチエージ ェントの連邦 アーキテク チャの例と して有名 PACT ◗ コンカレントエンジニアリング ◗ 連邦アーキテクチャ z z ラッパー （ツールを包む） ファシリテータ （分野間通信と分野内通信のゲートウェィ） メッセージの階層化 メッセージ宛先の決定 メッセージの翻訳 初期化、監視 ◗ 31種類のエージェント、15のワークステーション 6 プロセス中心型 ソフトウェア開発環境 ◗ PSEE (Process-centered Software Engineering Environment) 7
© Copyright 2024 Paperzz
