1 グループウェアの ソフトウェア開発への応用 グループウェアと

グループウェアの
ソフトウェア開発への応用
グループウェアと
ソフトウェア工学(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