Astah GSNが、ＵＭＬ、SysMLと連携してほしい人！ － いっぱい！！

Astah GSNが、ＵＭＬ、SysMLと連携してほしい人！　－　いっぱい！！


第五回D-Case研究会
http://www.dcase.jp/study05.html

に行って来た。その内容の前半をメモメモ

---

はじめに

・国立情報学研究所＝石川先生のおかげ

・石川先生のご挨拶、連絡事項

・今日のアジェンダ

---

■Ｄ－Ｃａｓｅのこれから

Ｄ－Ｃａｓｅ導入の経緯

・ＤＥＯＳ：ＯＳを作るプロジェクト
　　→アシュアランスケース
　共通して理解するなにか
・アシュアランスケース、セーフティケース
　十分にディペンダブルであることを
　提供する構造化された証拠ドキュメント

・アシュアランスケース、セーフティケース
　　　不完全さを確認し、システムのディペンダビリティを合意

・Ｄ－ＣＡＳＥの目指した方向性

研究成果
・ディペンダビリティ・合意形成
　　→本
　　　Ｄ－ＣＡＳＥエディタ
開発と実証

実証実験：いろいろ

国際標準化
・ディペンダビリティをすりあわせで
　　→ＩＰＡなど

Ｄ－ＣＡＳＥの課題　ここでは２つ
・Ｄ－Ｃａｓｅのスケーラビリティ
　　　→Ｄ－Ｃａｓｅのモジュール化
・Ｄ－Ｃａｓｅの再利用
　　　→Ｄ－Ｃａｓｅのパターン化

ＧＳＮパターン
GSN Pattern
→木構造：パラメータ
　ループの導入

Ｄ－ＣＡＳＥのパターン

・Ｈａｚａｒｄ　Ａｖｏｉｄａｎｃｅ　Ｐａｔｔｅｒｎ

アシュアランスケースを形式的に定義
ＧＳＮパターンをツールから利用可能にした

---

■D-CaseとSysMLの連携
連絡事項：DEOSが今月まで→閉鎖→ホームページもお引越しするよ！

１．はじめに
組み込みシステム開発における問題
・開発の現状
　　ソースコードベース
　　上流工程の仕様書が作成されない、更新されない
　　　　→証跡として残っていない

・解決のアプローチ
　D-Case Driven Development With SysML手法

・問題を解決する手法
　　Ｄ－ＣＡＳＥによる課題の解決
　　　　議論分解
　　　　関連付け
　　　　証跡追加

・Ｄ－ＣＡＳＥの議論分解パターン
　　　脅威の明確化
　　　脅威の発生シーンの明確化
　　　原因の明確化
　　　対策の明確化

・Ｄ－ＣＡＳＥに基づく正確な設計仕様の策定
　　　要求図
　　　ブロック図
　　　パラメトリック図
　　　シミュレーション図

・検証結果の確認

・D-Case Driven Development With SysMLを
　実現する開発環境

　　ＯＳＬＣ連携アドオン

具体例
ＩＳＯ２６２６２に準拠した車載システムへの適用

開発フロー
・アイテムの定義
　　トップゴールの設定
　　ディペンダビリティへの脅威の明確化

・ハザードの認識
　　脅威の発生シーンの明確化

・機能安全要求に基づく分解
　　原因の明確化
　　対策の明確化

・技術安全要求に基づく分解
　　対策の明確化

・検証結果による保証
　　検証結果による保証

---

■DEOS要求マネジメント
・アシュアランスケースとＧＳＮ
　　→２００９年８月

・ＳＴＡＭＰ　リーブソン

・議論パターンポケットガイド
　アシュアランスケース入門（ＣＤ）

・ディペンダビリティ
　　→ＪＩＳで標準化されている

・要求ママネジメント条件
・要求状態管理モデル
　　　抽出
　　　合意
　　　通常運用
　　　逸脱

・システム継続性制御
　　→ディペンダビリティ制約
　　　コントロールする

・要求管理技法
　　ディペンダビリティ制御マップ
　　サービス合意形成カード
　　サービスリスク分類構造
　　サービスリスク管理表
　　リスク分析活動

・システムの動作シナリオ
　　→システムリスク：全部

・Ｄ－ＣＡＳＥの全体構成例
　　→Ｄ－ＣＡＳＥパターン
　　　　　→議論パターンポケットガイド

・議論分解パターン
　　説明対象システム
　　説明対象に関係
　　証拠の構造に起因する
　　Ｄ－ＣＡＳＥの再利用に起因する

・ＳＴＡＭＰ階層的制御構造
　なんしーりーぶそんさんたち

　Parnasの変数モデル

・ソフトシステム方法論　再考　その１
　→８年前

・チェックランドの形式システムモデルの構造

・ソフト・システム・方法論→ソフト：人間、社会的

・システム論の制御条件
　　・ゴール条件
　　・活動条件
　　・モデル条件
　　・観測条件

・Ｗｅｂサイト管理のセキュリティ要求分析

・システム論的ＤＥＯＳプロセス

・安全性分析手法の統合化
　　システム論的制御構造　ＳＴＡＭＰ、ＳＴＰＡ
　　高信頼性要求アーキテクチャ　ディペンダビリティ保証ケース
　　システム物理構造　ＦＴＡ，ＦＭＥＡ，ＨＡＺＯＰ

---

■astah* GSN　ご紹介
・astah製品ラインナップ
・ブラジルのユーザーが多い
http://astah.net/editions/gsn
コミニティスタンダードに忠実に
http://astah.net/editions/gsn/download

・みどころ
コミニティスタンダードに忠実に
横に線を引くーコンテキスト用
下に線を引くー普通のせん
参照でハイパーリンク
ＸＭＩ

夏ごろ発売


質問：
UML連携できる？
いまのところできないけど、
ＳｙＳＭＬと連携した話を平鍋さんが話していく

お値段は？
３万円～７万円の間

＊ノードにアイコンがつく
　　→Ａｓｔａｈ　ＡＰＩでがんばれば取れる

アンケート
　　・ＦＴＡと連携してほしい人：すこし
　　・ＨＡＺＯＰと連携してほしい人：すこし
　　・FMEAと連携してほしい人：もっとすこし
　　・ＳｙｓＭＬ，ＵＭＬと連携してほしい人：いっぱい！

「情報ファイルの発見に失敗」の検索でこのブログに来た人へ・・・

このブログの検索ワードをみると

「情報ファイルの発見に失敗」

で検索している人を時々、見かけます。

また、TeXのインストールページを見ている人も、
時々見かけます。

たぶん、このせいだと思うので、その事象と対策を書いておきます。

---

■事象

TeXインストーラー３を使ってインストールしたとき

という画面で始まって、次々画面を遷移させていくと、
途中まで順調に行くのだけれど、

というエラーが出る。ログをみると・・・

「情報ファイルの発見に失敗」
と書かれている。

わたしも、この状態になりました。

---

■対策（私の場合）

たぶん、そのかたは、

20分でできる簡単TeXインストールWindows編(WinShell版・2013年11月改定)
http://did2memo.net/2012/04/23/easy-latex-install-windows-201204/

などを見て、プラグインを入れていませんか？
つまり、

なかんじの画面で、TeXworks以外のプラグイン（ここではispell)が
入っていないでしょうか？

プラグインをいれずに、ダウンロードしてきたものを解凍し、
なにもしないで、そのままabtexinst.exeをダブルクリック
して、実行してみてください。上記の画面は、

なかんじで、TeXworksのみになるはずです。
この状態で、私はインストールできました。

ペルソナを用いたユーザー要求の分析

第１０回　要求工学ワーキンググループ東京サブワークショップ
http://www.fuka.info.waseda.ac.jp/rewg-sub/workshop/201403.html

できいてきた、

ペルソナを用いたユーザー要求の分析
（白銀先生）

をメモメモ

---

■あじぇんだ
ＨＣＤ
ペルソナ／シナリオ手法
ＨＣＤによるアクセシビリティ

■ＨＣＤ
背景
・機器やシステムの高機能化・複雑化
・利用者の多様化
→システムにユーザビリティ上の問題があることも多い
　　操作方法が難しい
　　必要な機能がどこにあるか分からない
　　マニュアルどおりに行かない
→ユーザービリティを確保するには
　　もっと利用者に着目する必要

ＨＣＤとは
日本語：人間中心設計
　　ユーザー中心設計（ＵＣＤ）と似たような感じ
・ユーザビリティやアクセシビリティを満たすシステム開発のためのアプローチ
・設計だけでなく、要求工学に適用可能なプロセスを含む

ユーザーの多様性
・システムのユーザーの多様性
　　直接ユーザー（一次ユーザー【エンドユーザー】、
　　　　　　　　　二次ユーザー【一次ユーザーのサポート】）、
　　間接ユーザー
・ユーザー特性の多様性
・志向性の多様性
　　文化の違い：会社で文化がある
・状況や環境の多様性
　　精神状態：エレベーターに閉じ込められてパニックになった状態で、
　　　　　　　非常ボタンが押せるか？

ＩＳＯ９２４１－１１によるユーザビリティ定義
・ユーザビリティの枠組み
　　有効さ
　　　・指定された目標を達成する上での正確さと完全性
　　効率
　　　・正確さと完全性に費やした資源
　　満足度
　　　・不快感のなさ、肯定的な態度

Ｎｉｅｌｓｅｎによるユーザビリティ定義
・コンピューターシステムの受容性
　受容条件
　　　社会的受容性
　　　実務的受容性
　　　　有用性
　　　　　　実用性
　　　　　　ユーザビリティ
　　　　コスト
　　　　補完性
　　　　信頼性
　　　　その他

・ユーザビリティ定義
　　学習しやすさ
　　効率性
　　記憶しやすさ
　　エラー発生率
　　主観的満足度

ＩＳＯ９２４１－２１０
　ＨＣＤの国際規格
　　ＩＳＯ１３４０７から発展して２０１０年に制定
　　インタラクティブシステムのライフサイクルに対する
　　　人間中心設計の適用の推奨

ＨＣＤでの原則
・ユーザーやタスク、環境を明確に理解して設計すること
・開発全体を通じてユーザが参画して設計すること
・ユーザー中心的な評価手法により設計を行い評価すること
・反復的なプロセスにすること
・ＵＸ全体に着目して設計すること
・設計チームは多種多様なスキルと視点を持つこと

ＨＣＤでのプロセス
ＨＣＤのプロセスを計画する
＊利用状況を理解し特定する
＊ユーザー要求を明示する
ユーザー要求を満たすように設計
設計の評価

＊利用状況の理解と特定
　ユーザーの特性や環境等を理解
　　　ユーザと他のステークホルダを特定
　　　ユーザーやユーザーグループの特性を理解
　　　　：
　　　　：
　利用状況として調査するもの
　　　ユーザ特性
　　　業務内容
　　　設備・環境
　調査方法
　　定量的手法
　　定性的手法


＊ユーザー要求を明示する
　利用状況やビジネス目標の観点からユーザ要求を特定
　　　利用状況を特定
　　　ユーザニーズや利用状況から要求を抽出
　　　　　：
　　　　　：

：ユーザ要求を満たす設計
・インタラクションやユーザインターフェースを設計
　　シナリオ利用、シミュレーションプロと

設計の評価
　・設計内容についてユーザビリティ評価
　　　　ユーザーテスト
　　　　　　ログを採る
　　　　　　思考発話法
　　　　ヒューリスティック評価
　　　　　　専門家による評価

ペルソナ、シナリオ法
・架空のユーザー（ペルソナ）の行動をシナリオとして表し、
　そのシナリオからユーザーの要求を抽出する方法
　　　ペルソナを作成する
　　　作成したペルソナをシナリオ
　　→あらんくーぱーがつくった

ペルソナ
・対象システムのユーザーの代表的な特徴をもつ架空のユーザー
・具体的なユーザーを想定することにより、システムへの要求を具体的に分析
　　　ユーザーについてより深く理解

ペルソナに持たせるべき情報
・ペルソナ基本情報
　「特定の個人」を表現するために必要な情報を含む
　　開発者がユーザーを理解するために必要な情報

ペルソナ基本ｚｙ方法
　　識別情報の詳細
　　役割と仕事
　　ゴール
　　セグメント
　　技術と知識
→ペルソナ戦

略マーケティングにある

ペルソナを利用する主な利点
・対象ユーザーを具体化できる
・ユーザーに対する思い込みを軽減できる

ペルソナ作成方法
・ユーザーデータを収集
　　インタビューやフィールドワーク、アンケートなど
・データからセグメントを作成
・セグメントの情報を元にペルソナを作成

ペルソナ作成方法（ワークモデル）
・フローモデル
　　責任や役割分担、環境、アウトプットなどをコミュニケーションの
　　流れとして記述
・シークエンスモデル
　　１人のユーザーの行動の手順を時系列で表現
・アーティファクトモデル
　　ユーザーが利用する人工物
・文化モデル
　　ユーザーの行動への影響者や影響の範囲・度合いを表現
・物理モデル
　　作業空間のレイアウトなど、物理的な環境を表現

ペルソナの優先度
・ペルソナの人数　３～４人程度
　　プライマリペルソナ
　　　最も優先すべきペルソナ
　　セカンダリペルソナ
　　　プライマリに矛盾しないと実現

ＳＥ分野向けのペルソナ作成手法
・どのようなペルソナになりそうか、仮設を作成
　　仮説に基づき、インタビュー
・キーとなる行動変数を抽出
・行動変数の値の範囲を特定
・行動変数の値をもとにユーザーの回答をグループ化
・ペルソナの基本文書を作成
・行動変数やペルソナの特徴、ゴールの検証
・ペルソナについての物語を作成
・作成されたペルソナに対して、優先順位
・ペルソナ基本文書→ユースケース図
・プロトタイプを作成

シナリオ記述と要求抽出
・記述するもの
　ペルソナがシステムを利用する具体的な流れの物語
　　目的
　　場所
　　使う人
　　流れ

・記述しない
　詳細なインタラクション

必要に応じて各ペルソナごとに複数のシナリオ

シナリオから要求を抽出
・シナリオに隠れたタスクやデータを発見
　　タスク：ペルソナがシステムを利用して行った行動から抽出
　　データ：タスクを行うために必要としたデータ

要求の優先順位付け
・複数のペルソナと複数のシナリオを作成すると、多くの要求が抽出
　　→マトリックスで要求の優先順位付け

ゴールダイレクテッドデザイン
・ステークホルダについての質的データ
・振る舞いパターン抽出
・ユーザーとのゴール？（ごめん、抜けた）
・各種モデルやペルソナの作成
・ペルソナの優先度
・ゴールのタイプを検討
　　エクスペリエンスゴール
　　エンドゴール
　　ライフゴール
・書くペルソナにゴール割り当て
・シナリオ作成
・要求の仕様化
・デザインを詳細化

ＨＣＤによるアクセシビリティ
・システムの利用者の状況は多種多様
　　障害を持っている人
　　高齢者
・異なる利用環境の人
　　大きなディスプレイを使っている人
　　小さなディスプレイを使っている人

ユーザビリティとアクセシビリティ
・アクセシビリティ：利用可能さ
・ユーザビリティ：使いやすさ

ペルソナとアクセシビリティ
・ペルソナ：ユーザーをより深く理解することが大きな目的
　　ユーザーでまとめると、ユーザーの特性がぼやける
・アクセシビリティ：主なターゲットは障害者、高齢者
　　ユーザーでまとめてしまうと理解しにくい

障害とは？
・障害の状況は多種多様
　　盲目、弱視、色覚障害
　　　必ずしも障害者手帳を持っている人だけに限らない
・同じ種類の障害も人によって症状に違い
　　　例：色覚障害
　何がどこまでできる木亜、人による違いが大きい

状況別の対応の基本
・状況
　　目がほとんど見えない
・基本的留意事項
　　音声ガイダンス、展示

・状況
　弱視
・基本的留意事項
　　小さい文字、アイコンを避ける
　　拡大縮小

などなど・・

高齢者
　状況
　　障害者と同じような状況に

あくせすびりてぃに関する企画
ＪＩＳＸ８３４１（やさしい）
リハビリテーション法大５０８条（アメリカ）
ウェブコンテントアクセシビリティガイドライン

ペルソナに必要な情報
・身体的症状
・利用している支援ツール
・スキル、頻度

シナリオ作成（アクセシビリティ）
・ペルソナ基本情報やペルソナ作成のための調査データを下にシナリオを作成
・シナリオ上のペルソナの行動についてアクセシビリティからチェック

おわりに
・またまだ使いにくいシステムも多数
・新たな機器類も登場
・ユーザーの理解にペルソナは有効
・ペルソナ／シナリオ法の主な課題
　　シナリオ構築方法の体系化

---

関係ないけど、自分へのメモ。
あとでみる。
質問ででていた、ペルソナとユーザーモデリングの違い＆動向
についての参考書

利用者品質の確保に向けたユーザモデリング技術実用化調査
http://www.ipa.go.jp/files/000026872.pdf

表記ゆれの指摘は、ソフト工学では形式的なものが多い（NLPでは特徴ベクトル？）

きのう、「要求仕様書の一貫性検証の話って多いよね・・・」という話を書いた。そこで述べたように、全国大会でも


5A-1仕様書特有表現の表記揺れを検出するツールの試作と評価
○久野綾子，平尾英司（NEC），田村一樹，吉川大弘，古橋　武（名大）
https://www.gakkai-web.net/gakkai/ipsj/76program/data/pdf/5A-1.html

や

5A-2ソフトウェア設計に適用する複数ガイドライン間の用語揺れとその対策
○小林大樹，塚本良太，山田　亮，田村孝之（三菱）
https://www.gakkai-web.net/gakkai/ipsj/76program/data/pdf/5A-2.html


というように、仕様書の一貫性（用語のゆれなど）の話がでている。

---

ただ、全国大会のものは、用語のゆれを、形式的にとらえている。
たとえば、5A-1は、以下の３つの指標をもとに、用語の表記ゆれを判断している
１．複合語間の文字列の相違
２．文字列と表記ゆれの確率
３．出現頻度の偏り

また、5A-2は、ガイド用語テーブルというテーブルを利用している。
同義語と包含関係をまとめた、要するに類義語辞書を使っている

昨日の話は、「用語不一致検出ルール」の詳細はわからなかった。

これらの例では、形式的なチェックなので、新出語で意味的には似ているが、表記的にまったく違う用語
（例えば、「カスタマージャーニーマップ」と「ユーザーエクスペリエンスマップ」はほぼ同じものをさすが、
　文字列はまったく違い、新しい語なので、類義語登録していないかもしれない）は、
見つけられないことになる、

　ローカルで利用される用語は略語（仕様変更を、仕変（しへん）と訳す人がいる。
　「３章に、しへんが入ったよ」といわれて、いや、しへん（詩篇）は、２３篇とか、篇って
　数えるだろうと、いってはいけない）もあり、そういうローカルの略語は、類義語辞書に
登録されていない場合も多い。

---

　では、辞書登録されていない類義語をどう見つけるかであるが、
　ちょっと見てみると、

同義語辞書作成支援ツール
http://www.r.dl.itc.u-tokyo.ac.jp/~nakagawa/academic-res/terada-ANLP08.pdf

なんかあるかな・・・

自然言語処理（NLP)的には、
単語の共起関係（特徴ベクトル）の類似性、なんかを見るのが、ふつうなんでしょうね。
ただ、これだと真逆の意味（入力と出力）なんかも、表記ゆれになっちゃうんだよね。
（類義語ではあるのだが。。。）

ただ、そういうアプローチをしないで形式面ばっかり追っていると、
いつまでたっても、表記ゆれ検出というよりは誤字脱字発見の文書校正ツールになってしまう・・・