D-CaseとSysML／UMLの連携

・実証実験
・D-Case作成

D-CaseとSysML／UMLの連携の実証実験

・実証実験の適用対象としたシステムの概要
　SysMLを用いたシステム開発の事例紹介
　　　　ジェスチャする
　　　　　↓
　　　　Kinectを使って読み込み
　　　　　↓
　　　　PCで処理
　　　　　↓
　　　　ルンバの走り方が変わる

・開発プロセスと成果物
　　分析
　　システム開発
　　ソフト開発
　　製造
　　運用

・分析フェーズ
　　プロジェクトコンテキストの定義
　　　　成果物：プロジェクトコンテキスト
　　　　→D-Case：デモ用で十分
　　ステークホルダー分析
　　　　成果物：ステークホルダーリスト（ユースケース図）
　　　　→D-Case：トップゴールのコンテキスト
　　要求分析
　　　　成果物：要求図、要求テーブル
　　　　　　非機能要求安全性
　　　　→D-Case：ゴールを達成するために満たすべき要求や
　　　　　　　　　どの要求とリンクしているか
　　　　　　　　　ゴール～要求～ブロックのトレーサビリティ確保
　　システムコンテキスト定義
　　　　成果物：システムコンテキスト
　　　　→D-Caseトップゴールのコンテキスト

　　ユースケースの特定
　　　　成果物：SysML：ユースケース図
　　　　→

・システム設計フェーズ
　　ユースケース分析
　　　　成果物：ステートマシン図
　　　　　　　　アクティビティ図
　　　　→D-case：

　　システムアーキテクチャ設計
　　　　成果物：ブロック定義図
　　　　　　　　内部ブロック図
　　　　　　　　構造図
　　　　→D-case：要素を結びつけ？

・ソフトウェア設計フェーズ
　　構造設計
　　　　クラス図

　　振る舞い設計
　　　　ステートマシン図
　　　　→D-case：ゴールの構造と振る舞い？

・製造
　　成果物：部品、パーツ、ソースコード
　　　　→D-case：成果物と？

・検証・妥当性確認とD-Caseの連携
　　　　→D-case：検証・妥当性確認と？

・運用

考察
　D-CaseとSysML／UMLによるモデルベース開発の親和性は高い

・D-CaseとSysML/UML連携の構想
　　作成負荷
　　効果的な連携
　影響分析
　要求の立証カバレッジ分析　　　　
　参照容易性
　　表形式による表示　　　　
　モデルからの展開
　　モデル構造の展開

・実証実験
　　時間がかかった
　論点
　　記載する粒度および重複記載
　　機能充足性の立証
　　機能要求の立証の位置づけは？
　　　　→指針を示さば迷いなくなる
　　ディペンダビリティ属性の定義
　　公開されているサンプルが少ない
　　テンプレート

ディペンダビリティを見える化するD-Caseの話を聞いてきた

ディペンダビリティを見える化する手法？ツールにD-Caseってのがある。
今日、第3回D-Case実証評価研究会のはじめのほうを、慶応の日吉で聞いてきたので、
そのメモメモ

第一弾は、
「D-Case、DEOSへの期待 ～品質説明力の強化に向けて～」
　　IPA　SEC　田丸氏

---

・組み込みソフトウェア開発の課題
　１位：設計品質が２００６年～２０１２年までトップ
　それ以下は、景気によって変わる（新製品／経費削減）

・製品出荷後の不具合発生製品率の推移
　リーマンショック前
　　　４０数パーセントがないと答えた
　　　　　→品質改善された
　その後
　　　なしと答えた人半減
　　　　　→品質悪くなったまま、改善しない
　理由
　　　開発費削減→自分たちで開発して
　　　ベテラン技術者が定年、新入社員増えてきた

・製品出荷後に発生した不具合の原因
　　３分の１はソフトだが、
　　他製品との接続など、
　　　　マーケットに出て、使用環境における不具合
　　　　が増えてきた

・組み込みシステムの変遷
　　バブル前：
　　　　半導体中心（特注のLSI)：電子立国日本
　　バブル崩壊：
　　　　組み込み用マイコン
　　　　　価値の源泉がソフトウェアへ
　　９８年
　　　　OS、ミドルウェア（I-TRON)
　　ITバブル崩壊
　　　　プラットホーム化（BREW、Android）
　　リーマンショック
　　　　つながる時代？
　東芝とルネサスが半導体ベスト１０に残っている

　組み込みXクラウドXモバイル

・「組み込みXクラウドXモバイル」の役割分担
　　　機械系－組み込み系（センサー入力など）
　　　人間系－モバイル系（ヒューマンインターフェース／利用状況）
　　　クラウド系－非リアルタイム処理、データ管理
　システム全体の信頼性は？

・スマホで車を操作
　　車の信頼性とスマホの信頼性は違う

・組み込み、クラウド、モバイルの特性の違い
　　結構、違う（開発の方向性とか）
　　なんか、一工夫しないと、できそうにない

・統合システム関連の対応状況と課題認識
　　組み込み：統合か進む　４～６割
　　　　ビジネスモデル
　　　　全体品質の確保

・電気法品安全法技術基準体系等の見直し
　　「組み込みソフトウェアの安全性」が入ってくる
　　　（国際標準に書いてある）

・消費者教育推進法
　　事業者、事業者団体の努力義務

・消費者事故などの調査機関の設置
　　運輸は事故調査委員会を作ることが法律できまっている
　　消費者庁が設置するもの
　→いままで以上に企業がしっかり作ったということ

・組み込み、クラウド、モバイルの実現に向けて
　全体システムを重視したハザード・リスク分析
　　・ハザードリスク分析のスコープ
　　・ハザード・リスク分析の潜在リスク
　品質の見える化、見せる化
　　見える化、見せる化の対象
　　見える化、見せる化の技術
　　　トレーサビリティマネジメント
　　　アシュアランスケース
　　→D-Case：第三者が内容をみる

・関連する政府など（D-Caseのお客様？）
　ソフトウェア品質説明のための制度ガイドラインの策定
　自動車向け機能安全規格（２６２６２）のガイドラインの整備
　トレーサビリティ管理基盤の開発
　TERAS
　スマートシステム検証技術協会（SVA)
　モバイルIIOT
　利用者TIDAコンソーシアム

・制度ガイドラインの公開について
　　品質説明

---

「警視庁犯罪抑止対策本部」をテキストマイニングしたら、なんか出てくるかも・・・

警視庁犯罪抑止対策本部
https://twitter.com/MPD_yokushi

のツイートを見てて思った
（見てない人に・・・起きている犯罪の手口のツイートが多い）

これ、テキストマイニングしたら、なんか出てくるかなあ・・
共起関係をみて（変換間違いじゃないよ）、犯行の手口の類型化とか・・
もう、だれか、やってるのかなあ・・

ベンダー各社の上流工程の開発手法（NTTデータのTERASOLUNA等）が載ってる

今月号の情報処理学会が出している、情報処理　デジタルプラクティス　Vol.4 No.2

デジタルプラクティス ＞ Vol.4 ＞ No.2
https://ipsj.ixsq.nii.ac.jp/ej/index.php?action=pages_view_main&active_action=repository_view_main_item_snippet&index_id=7034&page_no=1&list_view_num=20&sort_order=7&page_id=13&block_id=8

（以下太字は、上記の号の中の論文のタイトル）

要求工学特集なんだけど、その中に、SIベンダー各社の上流工程の開発方法が載っている

【ＮＴＴデータ】

TERASOLUNA：上流プロセスの整備・体系化の取り組み−システムの目的と要求の明確化に向けて−

はTERASOLUNA

目的と手段の断絶を解消するビジネスモデリング方法論の実践-気づきから要求を導く-

はＭＯＹＡ

【富士通】

要求工学の実践ノウハウを集大成した要件定義手法Tri-shapingの実践

は、Tri-shaping（最近は、C-NAPしてない？）

【日立】

要求開発手法HyThologyの開発と実践−REBOK実践の取り組み−

がHyThology

超上流工程における合意形成手法「Exアプローチ」

がＥｘアプローチ

【その他】
SIerではないけど、有名どころ・・・

人事・給与システム：大規模シェアード型府省共通業務情報システムの開発−ユーザ参画型の業務要求定義から−

が、電子政府の人事院の最近のほう
（人事院のシステムは、電子政府のＥＡの手法で、一回失敗している。その後、ユースケースを中心とした、まったく違った手法で成功している。上記論文は、その成功した手法のほう。ちなみに失敗したＥＡの手法は、その後、経済産業省のページからひっそりと消え、国立国会図書館の魚拓上でしか見えなくなった。ただし、地方自治体は（その失敗した）ＥＡ手法で、今もやっているので、各地方自治体のサイトで、その内容は見ることができる）

---

デジタルプラクティスは、タダでダウンロードできる
（ただし、ログインが必要なので、いっちばん上の右側にひっそりとある、新規登録を
しないといけないのかな？）