富士通のBig Data対応のプラットフォームだけど・・・

　まあ、やっとまともな話になってきたのかしら、Big Data。
　２月に出たときは（Interstage Big Data Parallel Processing Server V1）Hadoopいれてみましたあ！
　位の話に見えたけど、今度は、

Interstage Big Data Complex Event Processing Server V1

でＣＥＰ（複合イベント処理）やるし、

Interstage eXtreme Transaction Processing Server V1

で、インメモリ分散キャッシュやるみたいだし・・・

まあ、もっとも、

Interstage Business Analytics Modeling Server

で、データ分析処理部品が載ってくるみたいなので、それを見ない限りには、評価できないけどね・・・
5月17日、18日「富士通フォーラム2012」でなんかやるみたいなので、まずは、それを見てってことですかね・・


ビッグデータ活用を支援するソフトウェア群を体系化し販売開始
クラウドサービスで提供している技術をオンプレミス向けに製品化
http://pr.fujitsu.com/jp/news/2012/04/23.html

プロセス改善（１５５０４とか、ＳＰＩＣＥ，ＳＰＥＡＫ，すぴなっちとか）

SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第四回

ソフトウェア開発におけるプロセス改善
良い成果を得るためのプロセス改善の概要と勘所

を聞いてきたのでメモメモ

---

■（１）プロセス改善とは？

・改善とは
　良い状況に「何かを」変更する
　何かとは
　　製品、サービス・・・・”プロセス”

・ソフトウェアを支える３要素
　　人、技術、プロセス→プロダクト

・プロセスとは
　ＩＳＯ　１５５０４－１／１２２０７
　　インプットアウトプット・・・・
　　　　→ようするに仕事そのもの
　分割統治：細分化
　　→プロセス改善
　　　　プロセスと言う単位に区切って問題を見つける

・プロセスの詳細化の仕方（例）
　　目的は
　　誰が
　　入力は
　　成果物は
　　いつ開始
　　　：
　　　：

・ＪＩＳＸ０１６０　１ＳＯ／ＩＥＣ１２２０７
　　ソフトウェアライフサイクルプロセス
　　　→だれが、いつは規定していない

・プロセス改善の仕組み
　　インプット→アウトプットをフィードバック

・プロセス改善が目指すもの
　　診断、改善：ＱＣＤ工場

・プロセス能力の改善
　　予測能力の改善、
　　制御能力の改善＝ばらつきへらす
　　効率の改善＝生産性向上

■（２）改善へのアプローチと効果

・プロセス改善のアプローチは多々あり
　　言葉を知らなくても改善している
　　経験を持っていると、うまくいくことがある
　　もってなくても、いろいろある

・改善のアプローチ
　　２つ
　　　問題解決型：失敗を契機
　　　目標達成型：ゴールをブレークダウン
　　アセスメントモデルベースの改善
　　　　→ベストプラクティスをもとに

・問題解決型：失敗を契機とした改善
　　障害発生
　　　　→応急手当
　　　　→原因究明
　　　　→根本原因追求（なぜなぜ分析）
　　　　→再発防止策（人に着目した施策、技術に着目した施策、プロセス改善）

　　障害：氷山の一角→原因はいっぱい
　　起こった問題に対して手を打っている
　　　→違う問題は起こり得る

・目標達成型
　　ＧＱＭ（Goal Question Metric Method)

・アセスメントモデルベース
　　　ＣＭＭＩの組織成熟度：段階表現
　　　連続表現：プロセスごとにちゃんとできているか
　　　改善例：プロセス改善ナビゲーションガイド

■（３）プロセス改善の進め方とプロセス評価
・プロセス改善の進め方　８ステップ（１５５０４　ＰＡＲＴ４：推奨）
　　検討：目標をもつ
　　開始：
　　診断：今どうなっている？
　　計画：何を、どう改善→ベンチマーク
　　実装：
　　確認：よくなってる？
　　維持：横展開
　　定着：

・８Ｓｔｅｐの適用は柔軟に
　　できる範囲から取り組む
　　順番を変える
　　改善ステップの適用方法も改善

・改善の推進体制

・プロセス改善（現状の把握）
　　アセスメントモデルの利用
　　　ＣＭＭＩ
　　　ＩＳＯ／ＩＥＣ１５５０４
　　　　　ＩＳＯ／ＩＥＣ　１５５０４－５（ＳＰＩＣＥ）
　　　　　オートモーティブＳＰＩＣＥ
　　　　　ＳＰＥＡＫなど

・アセスメントモデル
　　ＳＰＥＡＫ－ＩＰＡの公開
　　ＳＰＥＡＫ：新日鉄社内用→ＩＰＡのワーキンググループで汎用化
　　　　１５５０４準拠の日本発
　　　　標準モデルと軽量モデル
　　　　　　軽量：ＪＩＳＡ　ＳＰＩＮＡＣＨ
　　　　アセスメント手順も含む
　　　　フリー

・なぜ１５５０４？
　　ＣＭＭＩ：このモデルをこうしろとはいえない
　　　→自由に使えるのは１５５０４
　　Ａのアセスメントモデル、Ｂのアセスメントモデル・・・
　　　→結果が同じかわからない：一本化
　　　→統一フレームワーク１５５０４

・１５５０４の規定要素
　　プロセス参照モデル
　　測定の枠組み
　　プロセスアセスメントモデル
　　アセスメントプロセス
　　　　初期入力
　　　　出力
　　　　役割と責任

・１５５０４準拠モデルの構成
　　能力の尺度とプロセスの２次元

・能力水準
　　０：未定義
　　１：実施
　　２：管理
　　３：確立
　　４：予測可能
　　５：最適化

・プロセス属性
　　９つの属性に分ける

・評定（レイティング）
　プロセスの達成度合いを４段階で評価する
　　ＦＬＰＭ

・アセスメント指標
　　主張するための客観的根拠

・評定ルール
　　下の方ができていないと、上がっていかない

・アセスメント手法
　　アセスメント実施の必要な手順を定める
　　　プラクティス指標を集める：エビデンス
　　　プロセス属性
　　　能力水準

・アセスメントと監査
　　似て非なるもの
　　　監査：できてないところを直す
　　　評価：直すかどうかは自分たちで考える
　　　　　アセスメントモデルは、要求事項ではない

■（４）プロセス改善１０の勘所と自律改善メソッド
・継続的に取り込む

・１０の勘所
　　目的目標の明確化：納得、共感できる
　　計画的に：計画は生きたもの
　　現実を直視：実現できるもの
　　事実に基づく：マネージャーのバイアス（そうだろう）
　　認識共有：やらされ感
　　主体的に：自分が変わる
　　成功共有：小さなところからはずみをつけて
　　全員参加：関係者が
　　継続的に取り組む：
　　人間中心：なんだかんだ、結局人

・プロセス改善の課題
　　・主体的、持続的に推進されない場合がある
　　　　トップダウンが強調
　　　　ＳＰＩの意義がつかみきれていない
　　　　銀の弾丸を求めてしまう
　　　　適切なガイドがない
　　　　課題の把握が場当たり的
　　→当事者が主体的にプロセス改善を推進するための
　　　ガイド、支援ツールＳＰＩＮＡ3ＣＨ（スピナッチ・キューブ）

・目指すところ
　現場やプロジェクトリーダー無図からが課題を分析し、解を導く
　入り口は課題ベース＋世間の経験・蓄積も生かす
　ワークシートを使ったプロセス改善のナビゲーション

・ＳＰＩＮＡ３ＣＨ自律改善メソッド
　仕事のやりかたを改善、向上
　　チーム、個人、いろいろ使える

　自主的な努力と追求
　手がかりのヒントも

・構成
　　問題気づきシート：
　　問題分析・絞込みシート
　　改善検討ワークシート
　　
・ステップ
　１．問題気づきシートでチェック
　２．問題の詳細化と因果関係の分析→全体像
　３．改善対象を絞る：上流に行き過ぎると自分で解決できない
　４．さらにワークシートを選択する
　５．改善検討ワークシートを作成する：自ら改善計画を導き出す

・継続的に改善を進めるために
　現場とプロセスオーナーとの合意形成
　　　
■（５）プロセス改善の動向

・プロセス改善活動動向
　　１５５０４　ＴＲ→規格になる→０１４５でＪＩＳ化
　　オートモーティブすぱいす：受け入れないと仕事できない
　　ＮＳＯＬさん
　　ＪＩＳＡさん
　　日本すぱいすネットワーク
　動向：ＣＭＭＩ1.3
　　ＶＳＥ規格：慶応さんも絡んでる。
　　システム、セーフティへ

・ＩＳＯ／ＩＥＣ　３３０００ファミリへの再編
　　プロセス改善

・活用状況
　　ヨーロッパでは車関係
　　　　→レベル３、２くらいでＯＫ
　　宇宙関係も　ＪＡＸＡさん

■（６）ＳＥＣ成果の活用（書籍とツール）

書籍：
　プロセス改善ナビゲーションガイド（４冊）

位置づけ
客観的・モデルベース：ＳＰＥＡＫ－ＩＰＡ
主観的・課題ベース：ＳＰＩＮＡ３ＣＨ
　　→ＳＰＥＡＫ－ＩＰＡの軽量版

---

■質問

Ｑ．改善が続けられるのは、どういう人がいれば？
Ａ．親しみやすい人
　　→人を引き込んでいける人

Ｑ．業態とかで違うと思うけど、標準ってある？
Ａ．ない。
　　たとえば、ＹＥＳが８５％だから、いいといえるか？
　　あまり数字にこだわると、いい結果がでない
　　でも、こだわり人が多い

ＯｐｅｎＦｌｏｗは、ＯＳＳ主導だそうですね － ソースは日経コンピューター

日経コンピューター２０１２年４月２６日号の特集

　　　主役交代　ＩＴの未来はＯＳＳが決める

の２６ページ

「図２　様々な分野で利用が進む主なＯＳＳ」

にいろんなＯＳＳが載っている。

　　ＰａａＳ構築　　Cloud Foundation
　　Open Flow　　　Floodlight,NOX,Open vSwitch

とか書いてある。

で、Ｏｐｅｎ　Ｆｌｏｗについては、３４ページ、
「ＯＳＳが新市場を創る」
の中で、詳しく書いてある。

ＯｐｅｎＦｌｏｗ市場は今後も、ＯＳＳがリード

だそうな。

（太字は、日経コンピューター２０１２年４月２６日号より引用）

要求仕様はＲＥＢＯＫかISO/IEC/IEEE 29148か？

日経コンピューター２０１２年４月２６日号の８ページ
一番最後のニュースに

日立ソリューションズ、「ＲＥＢＯＫ」技術者を３年で５００人養成

とあるけど、要求仕様＝ＲＥＢＯＫっていう考えで、大丈夫ですかねえ・・・

国際的な基準としては、
　　ドキュメント系は、ＩＥＥＥ　Ｓｔｄ　８３０
　　ライフサイクルは　ISO/IEC/IEEE 29148
ってかんじなんでしょうか？


　ISO/IEC/IEEE 29148
http://www.iso.org/iso/catalogue_detail.htm?csnumber=45171

が、将来的には共通フレームに入ってくるとなると、これとＲＥＢＯＫの
整合性も気になるところ。。。
　「ISO/IEC/IEEE 29148」のレビュー記事が少なすぎるのよね。

　いや、上記リンク先から、買えばいいっていう意見もあるだろうけど（＾＾；）

文脈指向プログラミング

　オブジェクト指向プログラミング、アスペクト指向プログラミングときて、
　どうも、将来的には、「文脈指向プログラミング」と来そうな気配？

　オブジェクト指向プログラミングは、
　クラスやオブジェクトの構造が決まっているとき、
　機能要件を表現するのには、うまくいった。

---

　しかし、速度低下のため、ＤＢアクセス手法を変えたいとか、
　セキュリティが弱いので、セキュリティをいっせいに高めたいといった
　非機能要件を考えた場合、
　その該当箇所は、クラスのメソッド内にさまざまに、「横断的に」散らばっているので
　オブジェクト指向で行う場合困難なこともある。

　このようなときに、「横断的関心事」をバサッと切り出し、入れ替えてしまう
　のが、アスペクト指向。

---

　オブジェクト指向には、もうひとつ問題がある。
　クラスやオブジェクトの構造はあらかじめ決まっている。
　しかし、現実には、できるだけ、動的に決めたい。
　（そのために依存性の注入などがある）

　もっといえば、文脈に応じて、振る舞いを変えて欲しいわけだ。
　車で、「進め」という命令が来たとき、
　　　目の前に何もなければ進んで欲しいし、
　　　人がいれば、「止まって」欲しい（同じ進めでも）

　こんな、状況に応じた振る舞いができるのが、
　「文脈指向プログラミング」
　らしい（はっきりわかっていない）。

どうも、このへん

http://www.graco.c.u-tokyo.ac.jp/~masuhara/papers/jssst2011-aotani.pdf

に参考になる論文があるらしいよ・・・

共通フレーム２００７

SDM公開講座「現代ソフトウエアエンジニアリングの俯瞰図」
の第三回

システム／ソフトウェアのライフサイクルプロセス
～ソフトウェア・エンジニアリング導入の第一歩を踏み出そう～

を聞いてきたので、メモメモ

---

・ソフトウェアエンジニアリングとは
ＳＷＥＢＯＫ（すえぼっく）の定義：ソフトウェアへの工学の適用
　　・・・よくわからない・・・

つまり、
　体系化し
　手順を作成し作業し
　データを収集してフィードバック
→プロセスが「きも」

第一部「共通フレーム２００７」の概要
　　→ＩＳＯ／ＩＥＣ１２２０７（ＪＩＳＸ０１６０）

第二部　日本独自のプロセス拡張の狙い
　→超上流の重視

第三部　ＳＬＣＰと共通フレームの最新動向

---

■共通フレームとは
・ライフサイクルを通じて、必要な作業項目、役割等を包括的に
　規定した共通の枠組み

・目的
　ソフトウェアに関わる人が共通の言葉で

・背景
　認識のズレによるトラブルの発生
　取引（二者間）の作業役割が明確化されない

・作成者
　ユーザー企業、ベンダー企業、大学、経産省、ＩＰＡ／ＳＥＣ
　　→産官学

・ソフトウェア開発方法論との関係
　ウォーターフォール、スパイラル、アジャイルなんでも適用可能
　　→開発方法論に共通

・ＪＩＳ　Ｘ　１６０（ＩＳＯ／ＩＥＣ１２２０７）との関係
　　逐次参照している。プラスアルファして作っている。
　ソフトウェアライフサイクルプロセス
　　ＩＳＯ／ＩＥＣ１２２０７＋追補→ＪＩＳ化
　　　→共通フレーム９８
　　　＋超上流→共通フレーム２００７

　システムライフサイクルプロセス
　　　ＩＳＯ／ＩＥＣ１５２８８　ＪＩＳＸ１７０　２００４

・プロダクトの品質はプロセスの品質から→ソフトウェアにも適用
　プロセスをきちっと作り上げ、品質を上げる
　　プロセス：ＪＩＳ　Ｑ　９０００
　　　　インプットをアウトプットに変換する活動
　　　　　　開発者が使うプロセス：開発プロセス
　　　　　　運用者が使うプロセス：運用プロセス
　　　　Whatがかいてあり、Howではない

・プロセスが確立されていないと：ＱＣＤが安定しない

・共通フレームの特徴
１番以外は、ＳＬＣＰの特徴
　　１．超上流の重視
　　２．モジュール製の採用
　　　　：
　　５．工程、時間からの独立性
　　６．開発モデル、技法、ツールからの独立性
　　　　：

・共通フレームのプロセス体系
　　黄色のところが追補
　　青が日本独特

・共通フレームの要素と階層

　　　プロセス：アクティビティをまとめたもの
　　　アクティビティ：関連タスクをあつめたもの
　　　タスク：作業内容
　　　　　リスト：例示
　　　　　ガイダンス：説明
　　　　　黒の太字が国際規格（細字が日本独自）

・プロセスのトピックス
　（１）　契約と合意の視点
　　・取得プロセス
　　・供給プロセス
　　・契約の変更管理：日本で作って、国際規約に入れられた

　取得供給は、ユーザーベンダーとは限らない。
　　ユーザー企業内にもある（業務部門と情報システム部門）
　　ベンダーにもある（一次ベンダーと二次ベンダー）

　（２）　運用の視点
　　・運用プロセス

　（３）　組織に関するライフサイクルプロセス
　　　　→ＰＭＢＯＫとかを参考にしたほうがいいかも
　　・人的資源のプロセス
　　　　→教育訓練プロセスが変わった
　　　　　プロジェクトの成功：人の能力→人を調達するのもアリ
　　　　　　　教育＋調達
　　・情報資産の再利用プロセス：９５年版にはない
　　　　再利用が重要視されている
　　　　　　・資産管理
　　　　　　・再利用施策管理
　　　　　　・ドメイン技術
　　　　すべて再利用は考えられない、ドメイン（適用の場面）に分けて範囲をきめる
　　　　なかなか再利用は難しい：組み込みは結構うまく回っている？

　（４）　支援ライフサイクルプロセス
　　主ライフサイクルプロセスから呼び出される。
　　　・検証プロセス：正しく製品を作っているか
　　　　　　→設計が間違ってたら、間違ってプログラムに反映されているか
　　　・妥当性確認プロセス
　　　　　　→正しい製品を作っているか

・テーラリング（修整）の適用について
　　身の丈にあわせたものになているか？

・テーラリングのポイント
　　共通フレーム全部やらないといけないわけではない
　　自分たちのプロジェクトに合わせた形
　　省略する場合、省略して大丈夫か確認

・テーラリングしないと・・
　　小規模では冗長
　　品質を高める場合には足りない
　　　　→自分たちの属性に合わせて

・テーラリング方法
１．作業工程を定義する
　　　工程名称は変わってもかまわないが、アクティビティの中身はあわせたほうが・・
　　　　→認識のズレがないように
　　　時間軸に並べて

２．開発モデルの選択

３．プロセスの利用者を具体化
　　誰がやるのか、責任者は？をマッピング

---

■日本独自のプロセス拡張の狙い

・プロセス拡張の狙い
　・国際規約は要件が確定しているところから
　　　→要件を確定するところが大事でしょう
　・日本ではそこを拡張
　　　→どういう形でつかうのかが必要：超上流（２００５年あたり）
　・上流工程の上に大事な工程：超上流
　　　→菊島さんが話します

・開発に入る前の「要求品質の確保」が大事
　　→「経営者が参画する要求寝室の確保」という本に

・超上流プロセス
　　経営戦略→システム化の方向性→システム化の計画

・もし超上流を軽視したら
　　システム開発における手戻り発生、コスト増加などのリスク
　　超上流でのトラブルの原因
　　　・システム化の方針・目的があいまい
　　　・要件が固まらない
　　　・あいまいな見積もり

・共通フレームに考えられている考え方

　　「利害関係者の役割と責任分担の明確化」を提唱
　　　　事業要件、業務要件、システム要件を定義できるのは
　　　　経営者、業務部門、情報システム部

　　「多段階の見積もり方式」を提唱
　　　　初期：ブレが大きい
　　　　→見積もりは、何段階に分けて
　　　　　　　→これができないのが、政府関係
　　　　　　　　分割発注は違う業者という規定
　　　　　　　→一括発注になってしまう

　　「Ｖ字モデルの採用」を提唱
　　　　品質の担保：Ｖ字の右と左であわせる

　　「超上流における準委任契約の採用」を提唱
　　　　→「モデル契約」でも

　　「要件の合意及び変更ルールの事前確立」を提唱
　　　　→要件の変更ルールをきめておく
　　　　　　見積もりをとるとか

　　「非機能要件の重要性を認識すること」を提唱

　　「運用・保守を含めたＳＬＣＰを考えること」を提唱

---

■ＳＬＣＰと共通フレームの最新動向

・ライフサイクルプロセスの動向
　　国際標準の２つのライフサイクルプロセス
　　　　ソフトウェア：１２２０７
　　　　　　１９９５　制定
　　　　　　２００２　追補１
　　　　　　２００４　追補２
　　　　　　２００８　改定

　　　　システム：１５２８８
　　　　　　２００２　制定発行
　　　　　　２００８　改定→ＪＩＳ化：２０１２か２０１３予定

・問題点と解決
・２つのライフサイクルプロセスの内容に整合性が取れていない
　　　プロセス、アクティビティ、タスクの粒度がまちまち

・ソフトウェアアセスメント１５５０４で求められている成果が
　記述されていなかった→追補１，２で解決

・２００８年版　ハーモナイズの中間結果
　　→まとまるのは数年先

・改訂版
　　ソフトウェアライフサイクルプロセスは変わっていない
　　組織、テクニカルの部分、システムの考え方を入れている
　　　→テクニカルの部分、抽象度が上がっている

・２００７の位置づけと今後
　　　ＪＩＳＸ０１６０　２０１２と、システムを取り入れて
　　　　共通フレーム２０１Ｘ
　　　ＩＳＯ/IEC　２００００（ＩＴＩＬ）
　　　ＩＳＯ/IEC　２９１４８（要求工学）
　　　　→今年度のＳＥＣの成果で出てくる？
　　

プロブレムフレームにおける要求と仕様

第五回　要求工学ワーキンググループ 東京サブワークショップ
にいってきた。聞いた内容のメモメモのつづき。

---

プロブレムフレームにおける要求と仕様

■プロブレムフレームってなに？
・要求分析の技法
　→システム設計技法的なところも

・フレーム
　問題の分類、パターン化
　著者：マイケルジャクソン（：歌、歌ってる人じゃない）
　　ジャクソン法：１９７５年ごろ、一世を風靡した
　　　→alloyのダニエル・ジャクソンのお父さん

・ジャクソン法（ＪＳＰ）
　・構造化プログラミングの時代
　・どう構造化するかに言及
・事務処理バッチプログラムの作成手法
　　・問題（入出力データ）の構造を下記らかにする

・ＪＳＰの手順
　　・入力と出力データの構造を正規表現木で記述
　　・入力と出力データの対応関係を把握
　　・対応関係からデータ構造を合成＝プログラム構造
　　・合成した構造に必要な処理を配置

・プロブレムフレーム概要

マシン－（現象）－ドメイン←（現象）－　要求

　　プロブレム図
ドメインと要求にわける
・ドメインプロパティ：given（所与）
・仕様はマシンがのぞまし振る舞い：願望法
・要求はドメインがそうなってほしい様子：願望法
　　→givenと願望をはっきりとわける
　　　考えるもの、調べるものの区別

問題の分類
・必要な振る舞い問題　状態遷移：
・命令された振る舞い問題　状態遷移：
・情報表示問題　正規表現：ＪＳＤ
・変換問題　　　正規表現：ＪＳＰ
・データ編集問題

ドメインの見え方
・要求から見たドメイン　ＶＳ　マシンから見たドメイン
・共有現象：要求現象ＶＳ仕様現象
・要求は要求現象によって表現、仕様は仕様現象によって表現

要求現象と使用現象
＜＜信号＞＞
仕様現象：赤と緑のランプへのパルス
要求現象：進め、とまれ
仕様現象→イベント、要求現象→状態

要求と仕様の特徴
・要求：人間の関心：状態→総合的
・仕様：マシンの関心

ドメインプロパティ
・状態とイベントの関連

要求の表現
　・マンガで描ける？ＳＤＬ→ＵＭＬ２．０　状態マシン
状態指向＝要求
　要求現象（状態）を使った表現(Kripke構造）
遷移指向＝仕様
　イベントを使った表現（ＵＭＬの状態マシン）

要求から仕様への変換
・深いドメインの要求
・浅いドメインの要求
・仕様

サブプロブレムへの分割

要求抽出プロセスの検証手法とか

第五回　要求工学ワーキンググループ 東京サブワークショップ
にいってきた。聞いた内容のメモメモ。

---

■要求抽出プロセスの検証手法～実事例による評価～

＜＜問題点＞＞
・要求仕様の定義網羅性は妥当
・要求間に不整合が発生

＜＜プロダクト品質、プロセス品質＞＞
・プロダクト品質：プロダクトは適切か
・プロセス品質：適切な時期かどうか

＜＜アプローチ：エンピリカルに＞＞

＜＜要求抽出プロセスの検証方法＞＞
（１）理想的な要求抽出プロセスモデル（理想モデル）
　　メタモデル

（２）要求抽出プロセスの品質評価プロセス
　　手順が妥当か：理想モデルとのずれ

＜＜理想モデル＞＞
　　業務分析～要求抽出のメタモデル
　　→２つの事例：インデント開発／パッケージ利用

　　　仕掛期＝ゴール
　　　充実期１＝問題点
　　　充実期２＝解決法
　　　完成期＝機能・非機能要件→合意

＜＜２つの理想モデル＞＞
　　課題発見型
　　解決策優先型
　　　　違いは問題と現行業務へのリソース配分

＜＜検証＞＞
・計画：計画が理想モデルと合致→工程表
・経過：立案どおりに進んでいるか→過程
・完了：立案どおりに完了したか→定義結果


＜＜適用結果＞＞
・２つのプロジェクトを比較
　　課題解決型ＰＪ３と解決策優先型ＰＪ４

　ＰＪ３
　　　機能要求が解決策より先
　　　業務フローに記載されているデータの定義がない
　　　　　→不整合あり
　ＰＪ４
　　　ほぼ一致
　
＜＜課題＞＞
・詳細化が必要
・定義量を加味したルール
・クラス単位のきめ細かいプロセス定義とプロセス検証ルール
・プロセス評価方法のツール化

＜＜質問＞＞
Ｑ：仕掛期、充実期１、充実期２、完成期の期間は等間隔？
Ａ：ではない。

Ｑ：課題の「クラス単位」のクラスとは？
　　　（要求分析段階ではまだ、クラスができていないはず）
Ａ：メタモデルのクラス

---

■貢献度と顧客のニーズに関する妥当性の間のコンフリクト検出における
　応用上の問題とその解決方法

＜＜はじめに＞＞

・The Standish Group：要求どおりに作ると、全体の３分の２近くは
　ほとんど、まったく利用されていない。
　　→顧客のニーズを反映していない
・ＩＥＥＥ８３０：妥当性
　　開発される内容と一致していれば妥当
　　　→満たすべきでないような要求が要求仕様書に含まれると妥当でない
　　　　妥当性を津0るや手続きによって検証することはむずかしい
　　　　　　　→顧客に確認：手戻りの可能性あり

＜＜顧客のニーズを満たすようだからと言って開発されるべきソフトか？＞＞
　　ニーズと開発目標は、イコールか？

＜＜要求獲得＞＞
　目標に整合し、顧客ニーズを満足する要求を獲得することが大事
　ゴール指向分析：ゴールを詳細化し、ソフトウェアで実現できたら要求
　　　　→貢献度：（AGORA）－１０～１０
　　　　　　→顧客のニーズを満足していない：

＜＜満足度行列＞＞
　　ユーザー、オーナー、サプライヤーが自分と他の人に対しても満足度を評価して
行列を作る
　自分の立場から考える。

　　　　Ｕ　　Ｏ　　Ｓ
評　Ｕ　　８　－１　　０
価　Ｏ　１０　１０－１０
者　Ｓ　　５－１０　　０

（満足度行列は顧客を含む：平均値が妥当性）。
ゴールの貢献度Cov(g)、顧客のニーズCup(g)
（からてしあんぷろだくと）


＜＜コンフリクトがおこる応用上の評価＞＞
検出できないケース
・最終ゴール
・ＡＮＤ分解のみ
・子ゴール１つのみ
・ＡＮＤ分解とＯＲ分解がともに存在
　　→属性値の伝播をともなうゴールグラフの簡約化
　　　　単層化：２階層になるまで
　　　　標準化：ＯＲ分解
　　　まとまられたときの、貢献度、満足度の処理

＜＜ＢＲＡＨＭＳ＞＞
・任意のゴールグラフにたいして、コンフリクトがある場合
　わかるようなツールを作ってる？？

＜＜おまけ＞＞
多属性意思決定手法：AHP

「情報処理」の表紙が初音ミクな件

　情報処理学会の会報誌？「情報処理」の５月号の表紙が初音ミクです。


http://www.bookpark.ne.jp/ipsj/


　初音ミクがすごいのか、情報処理学会が、ウケを狙っているのか？

　そういえば、気のせいかな、最近「情報処理」、やたら教育系が多くありません？
　（「ぺた語義」が教育系）

　その割りに、現場の開発的な話題、

　　たとえば、
　　　・フレームワークの現状を各言語ごとにまとめ、
　　　　フレームワークがどこに行こうとしているのか？

　　とか、
　　　・ビッグデータを集めたあとの処理事例に関して、
　　　　どのような処理にむかっているのか

　　とか、
　　　・ＮｏＳＱＬとＳＱＬの使い分け、
　　　　スケールアップとスケールアウトの使い分け

　　とか、そういう話がないから、あんまり、読むところないのよね。

　あ、ただし、今回の特集は、

　"歌声合成の過去・現在・未来　「使える」音声合成のためには"
　剣持　秀紀（ヤマハ（株））

　は、おもしろいかも・・

4月17日(火)のつぶやき

02:33 from gooBlog production
ブログに市のＨＰをコピペ→逮捕だって！ blog.goo.ne.jp/xmldtp/e/135ed…

by xmldtp on Twitter

ブログに市のＨＰをコピペ→逮捕だって！

ブログにコピペしただけで、著作権違反で逮捕されるなら、
かなり多くの人が、やばいんでないかい。
留置所、足らなくなるよねえ・・・


個人ブログに市のＨＰをコピペ　著作権法違反容疑で無職男を逮捕
http://sankei.jp.msn.com/affairs/news/120416/crm12041623070021-n1.htm

テスト設計手法PROST

SEA SPIN Meeting April 2012の「テスト設計を考える」で聞いてきたことのメモメモ
その２「テスト設計手法PROST」の話

---

問題意識
・テスト技法→テスト設計
・テストの２つの側面
　　バグを出す　＊　こっちを増やしたい
　　正しく動く
・どれを削ったら・・？

全体像

仕様書＋設計書→テストアーキテクチャ設計
　　　↓
テストケース設計
　　↓
テスト実施

テストアーキテクチャ設計
　・抜け漏れをなくす
　・守備範囲を特定
　　　テストケースの関係性
　　　テスト観点を出しながらツリー上に
　・テストのポジショニング
　　　位置情報として可視化したほうが
　　　ＬＴマップ
　　　→組織が持っている観点をうまく使う

・テスト観点の洗い出し
　　要求仕様→これはやる。以下３つが抜けがち
　　品質管理
　　設計実装
　　過去トラブル

・ＴＲＭａｏ
　　１つの観点：因子と水準


・テスト管理システムＴＥＴＲＡ
　　テスト情報の集約と可視化
　　テスト項目の構造化による重複や抜けもれ
　　テスト設計とテスト管理の連動

「テスト設計コンテスト」の最優秀賞の人の話を聞いてきた！

SEA SPIN Meeting April 2012の「テスト設計を考える」で聞いてきたことのメモメモ
その１「テスト設計コンテスト」の話

---

テスト設計コンテスト最優秀賞　河野さん

→社内のものではない。
　チームと言っているけど、一人でやってる

■テスト設計って何なの？
・テストとは？
　　テスト：ひとつ以上のテストケースの組み合わせ[IEEE829]
　　テスティング：静的なテスト／動的なテストのプロセス

　テスト設計とは
　　テストの設計？テスティングの設計？

・テストのライフサイクル
　　テスト分析
　　　　テストの要求獲得・テストスコープ設定
　　　　テストの全体像（テストアーキテクチャ設計）
　　テスト設計
　　　　テストのモデリング
　　　　テスト項目の作成
　　テスト実装
　　　　テスト手順・テストデータの作成
　　テスト実行

・テスト設計の概念整理
　　テスト設計
　　　　test設計(test design)
　　　　　　テスト設計でできた成果物：テスト設計仕様
　　　　　　　　　ハイレベルテストケース：期待結果を書いていない抽象度高い
　　　　　　　　　　　→テスト設計（モデル：図／表、仕様：べた書き）
　　　　　　　　　ローレベルテストケース：入力データと、期待結果を書いている
　　　　　　　　　　　→テスト実装（項目：テストケース）
　　　　　　テスト設計の行為(testing設計）

■テスト設計コンテスト
・３つの成果物
　　　　成果物１：テスト設計仕様
　　　　成果物２：テスティングの成果物ＰＦＤ，ＤＦＤ
　　　　成果物３：テスト分析の成果物

　テスト分析：成果物３

・テスト設計
　　test設計
　　　　ハイレベル：成果物１
　　　　ローレベル
　　testing設計：成果物２

　成果物１が重要
　モデルで表現できないものは、対象にしない

・テスト分析設計の方針
　　狙い：仕様と実装のズレを確認
　　戦略：全体から詳細へ
　　　　　設計：トップダウン
　　　　　テスト：ボトムアップ

・テストスコープ
　　ハードウェアをインターフェースとし、ソフトをテスト

・テスト分析の流れ
　　ＤＦＤで全体を理解
　　テスト設計の塊（単位）を決めて、構造的に整理する
　　テスト設計単位の検討：→が集中しているところはひとつの塊に
　　テスト設計方針：層で分けている
　　　　箱上部はテスト対象
　　　　箱下部はテスト設計の方針
　　下のテストができている→上のテストができる
　　レイヤー：下から上を実施
　　　　→ただし、線で結ぶよりは弱い
　　　　→ただし、テスティングのことも考えてしまっている。

・テスト設計の流れ
　　テスト要素抽出：テスト観点
　　テスト技法選択
　　テスト設計
　　　　安全性確認：無則のテスト(all pare)→２因子
　　　　　　　　　　ペアワイズ法
・テスト
　　ソフトウェアのつくりに依存する
　　レビューしやすいようにモデルで表現する
　　レビューをただの読み合わせにしない
　　モデル：行間をよめというのがなくなる
　　テスト設計→テスト項目の自動生成

・まとめ

外部設計で作るドキュメントについて

ＩＰＡの「機能要件の合意形成ガイド」の話を聞いてきた！

この「機能要件の合意形成ガイド」は、外部設計での合意形成で
（「機能要件の合意形成」ってあるけど、要求仕様の機能要件じゃなくって、
　それが決まった後の話）途中に、外部設計でつくる、工程成果物の話が出てくるよ！

---

機能要件に関する発注者と開発者の合意形成を目指して

・要件定義を終わって、外部設計を出すときのノウハウ

■「機能要件の合意形成ガイド」の開発背景

・機能要件の合意形成ガイドって何？
　　合意形成のためのコツ
　　手戻りを防止するコツ
　　コンテンツ：７つのドキュメント
　　　　概要
　　　　画面
　　　　業務フロー
　　　　データモデル
　　　　帳票
　　　　バッチ処理
　　　　外部インターフェース

・作った背景
　システム開発における手戻りコスト
　あとで見つかるほど、戻る
　　　設計工程でしっかり物を作る

　昔は業務要件は簡単
　　人
　　システム
　→システムが複雑になってきた
　→ステークホルダー：利害関係者がいっぱい

要件定義：発注者＝きめるところまで
外部設計：開発ベンダー
　　→作業者も変わる、組織も変わる
　　→認識の合意：難しい→これを作った

・開発の歩み
　　発注者ビュー検討会
　　　発注者ビューガイドライン
　　ＩＰＡ　機能要件の合意形成技法ＷＧ

　→ＣＤ－ＲＯＭの中に入っている
　　Ｗｅｂでも公開：月７００～８００件も見てもらっている

■機能要件の合意形成ガイドの目的
・認識のそごうを防ぐためのノウハウ
　　→体系的に示しているものではない
　　→どんな場面でもよいわけではない
　　→事例

技術領域：６つにわけて纏めている
　　→工程成果物を想定
・システム振る舞い編
　：業務フロー／業務説明／業務一覧／共通ルール
・画面編
　：画面遷移／画面アクション明細／画面レイアウト／画面入出力項目一覧
　　画面一覧／画面遷移・レイアウト共通ルール
・データモデル編
　：ER図／エンティティ一覧／エンティティ定義／ＣＲＵＤ図
　　その他資料（データ辞書／ファイル一覧・定義等）
・外部インターフェース編
　：外部システム関連図、外部インターフェース一覧／外部インターフェース項目説明
　　外部インターフェース処理説明
・バッチ編
　：バッチ処理一覧／バッチ処理定義／バッチ処理フロー／バッチ処理共通ルール
・帳票編
　：帳票概要／帳票一覧／帳票編集定義／帳票項目説明／帳票レイアウト

・合意形成とは：合意成熟度と４つの作業

　合意成熟度
　　　仕掛
　　　　言い切った・聞ききった→要件定義が完了
　　　充実
　　　　図表に書いてレビュー
　　　完成
　　　　合意内容を確認・管理

　４つの作業
　　・言い切る／聞ききる
　　　　目的範囲・制約条件（法律とかも）
　　・図表に書く
　　　　共通ルール／整理して書く
　　・もれ矛盾なくチェック
　　　　共通ルールにもれ・矛盾はないか？他の工程との整合性
　　　　複数のドキュメントを付け合せて
　　・レビュー
　　　　そごうがない／想定・前提

・中身（目次構成）

　３章構成
　　１．工程成果物の定義
　　２．工程成果物の詳細説明
　　３、コツの紹介

　メリットが書かれている

・適用例
　ユーザー役割ごとに書くとか
　画面レイアウトと遷移図を付き合わせる
　データモデル：データを入れてチェック

・事例のまとめ
　どの局面でも通用するわけではない
　唯一の階ではない
　全体を俯瞰するコツではない

・発注者側の要求確認編
＜＜問題事例＞＞
　　ドキュメントを比較していない
　　レビューを１つしか見ていない
　　申請と承認を同じ人でできるようにしてしまった
　　　　→ロールの説明がしてなかった
　　　　→開発にどんどん進んだ
　　→対応：業務要件が満たされていることをレビューすること！
　　思ったものとできたものが違ってた
　　　　→ラフスケッチを見せていない
　　　　：
　　　　：
　　（以下、にたような事例なので、省略）
＜＜まとめ＞＞
　・あいまいな発注→言い切るコツ（ID02T001)
　　　　事前に文書にまとめて伝える
　　　　文書：要件定義にあるもの
　　　　　　　システムを利用する組織・拠点と役割
　　　　　　　システムに対するイメージ
　　　　　　　システム対象範囲
　　　　　　　業務の流れ、手順
　　　　　　　重要な日付・期間
　　　　　　　目的、効果
　　　　　　　方式、制度、準拠すべき規則
　・正確に伝えたつもりでも、伝わっていない→レビュー


・まとめ
　　４つのコツを纏めたもの
　　６つの技術領域
・利用場面
　　開発標準
　　社内教育・グループレビュー

クラウドの評価に、IPAの「非機能要求グレード」を利用できる？

IPAの「非機能要求グレード」について、きいてきた！
ので、メモメモ

---

・非機能要求の重要性
　情報システムの障害件数：平均して１～２件／月報道

・システム障害の原因
　　ＪＩＳＡしらべ：
　　　　要件定義が問題
　　日経コンピューター：プロジェクト実態調査
　　　　要件定義、システム設計が問題
　要件定義でも、非機能が重要
　　→ＩＴ　Ｐｒｏにある

・非機能要件
　　機能要求：プロセス、データ、インターフェース
　　非機能要求：とりあえず、非機能要求グレードでは６つにまとめている
　ここでは、要求と要件をいっしょくたにしている。

・非機能要求は、抽象的
　→非機能要求の難しさ：
　　　お客様とベンダ間で認識のギャップがある
　　　　　→期待レベルが把握できない
　具体化が進んでいない上流工程で決めることが困難
　共通認識がもれない合意できない
　　　→リスク誘発

・要件定義書における非機能要求の課題
　　レベルあいまい
　　要求間に矛盾
　　思いつき（網羅的でない、一貫性がない）
　　優先順位？
　どういう要求をどの程度が難しい

・非機能要求グレード
　　利用ガイド
　　　解説編：目的と用語集
　　　利用編：例
　　３つの図表
　　　要求項目の一覧
　　　グレード表（推奨値）
　　　樹形図：階層的に
　　活用シート（Ｅｘｃｅｌ）カスタマイズ可能

　　システム基盤に関する非機能要求を大きく６つに分類
　　　　可用性
　　　　性能・拡張性
　　　　運用・保守性
　　　　移行性
　　　　セキュリティ
　　　　システム環境・エコロジー
　　→システム基盤に対するもので、業務アプリに対するものではない
　　→４階層
　　　　　重要項目：影響が大きいメトリクス

・ＩＳＯ９１２６
　　範囲が違う（９１２６は業務）

・要求レベル：レベルの差はアーキテクチャの差
　　→値段が違ってくる
　→レベル選択が難しい人に：モデルシステム３つ

　モデルシステム：１６の特徴を示したので、そこから選ぶ
　項目：重複しているものがわざとある
　　　「運用コストへ影響」というチェック項目がある

・使い方
＜＜一般的に＞＞
　　モデルシステムの選択（１６項目）
　　重要項目のレベル決定（９２項目）
　　重要項目以外のレベルの決定（１４４項目）
　　　　→全部決める必要はないが、決めない項目は、「決めなくていい」ことを決める

＜＜別の使い方＞＞
　　要求仕様書のチェックリストとして

　
・まとめ
　選択すればいい→具体的に決められる
　もらさずに決められる
　　現状：５０項目くらい

＜＜開発と評価＞＞
・「非機能要求の見える化」からはじまった。

・クラウドに、非機能要求グレードを利用できる
　　・利用者の要求を明確にする→非機能要求グレードを使って
　　・クラウドのサービスを評価する→非機能要求グレードを使って
　　・双方の要件のすり合わせ
　　　　　→割り切りも必要
　　　　　　　　高価でもいいから、全て満たしたいならオンプロミス
　　　　　　　　ただし、ＩＴリスクの把握は必要：止まったら？