形式仕様とユーザー中心とアジャイルの関係

この記事、表題に無理ないか？


「バグ無し」は可能、ソフトの先頭走る
http://itpro.nikkeibp.co.jp/article/COLUMN/20120719/410078/


形式仕様やれば、バグなしといいたいようだが、形式仕様をやってもバグは出る
たとえば、変数Ａの定義として、１以上の整数だったとしよう。
そして、完璧なプログラムをつくり、すべて証明したとする。

ところが、実は変数Ａは０以上の整数だったとしたら、今証明したものは、正しいとはいえない。
０だけで成り立つ／成り立たないケースがあるから。

つまり、形式仕様の証明は
　　ＡならばＢのかたち
この場合、前提のＡが偽ならば、（上記の例で、変数Ａは１以上が偽で０も含む）
その後の証明は、意味がない

---

この前提が間違っているかどうかを確認するのが、妥当性確認で、
形式仕様は、そちらではなく、検証に有効。

バグをなくすには、検証だけでなく、妥当性確認も必要（Ｖ＆Ｖ）

妥当性確認を早く行うには、ユーザー中心設計のように、ユーザーに早期に確認する必要があり、

その開発手法としては、アジャイルがある。

ってかんじじゃないかな。

ただ、アジャイルで形式仕様をやるには、たいへんだ。

「iPhoneで900MHz プラチナバンドを確認する方法」なんてのがあるらしい

ここ


iPhoneで900MHz プラチナバンドを確認する方法
http://technomado.blogspot.jp/2012/07/iphone900mhz.html?m=1


へ～

ＰＭって、何をする人なの？

っていう質問も出た

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

高信頼度設計を実現する人材像とその育成について

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

---

ＩＴ人材育成の取り組み
　　スキル標準と情報処理技術者試験
　　優れたＩＴ人材の発掘と育成
　　産学連携
　　人材育成で成果を挙げた中小企業の表彰

人材を取り巻く環境
　　ＩＴ人材白書
　　ソフトウェア産業の実態把握に関する調査

人材を取り巻く状況（１）
　　情報処理関連の人
　　　　１９８０年代　　３０万人
　　　　現在　　　　　　９０万弱

人材を取り巻く状況（２）
　　ＩＴ提供側の人材数推移　約８０万
　　雇用の状況
　　　　昔は良かった
　　　　リーマンショック後は、全産業と同様
　　　　　　今までとは違う：グローバル化

人材を取り巻く状況（３）
　　一番多いのはアプリケーションスペシャリスト
　　リーマンショックの影響受けた

人材を取り巻く状況（４）
　　過去五年：量に関しては２００９年から要求下がる
　　　　→むしろ、あまっている
　　質に対しては、依然として高い

人材を取り巻く状況（５）
　　人材の確保、育成
　　　　プロジェクトマネジメントなどは社内育成
　　今後
　　　　おおかた昨年度と変わらない
　　　　１０００名以上は減る？
　　　　３０名以下は、７割が採用０
　　外国籍ＩＴ人材の就労状況
　　　　国籍に関わらず、技術力の高い人がほしいから

人材を取り巻く状況（６）
　　組み込みの課題
　　　　設計品質の向上（過去５年、いつもＮＯ１）
　　　　開発コストの削減
　　　　開発期間の短縮
　　有効な解決策
　　　　技術者のスキル向上（過去５年、いつもＮＯ１）
　　　　開発手法・開発技術の向上
　　　　新技術の開発導入

組み込みソフトウェア開発を取り巻く事業環境の変化
　　高信頼設計での人材
　　　　国内における開発の中心が上流工程へと移行
　　　　　　上流工程の中核技術はモデルベース（モデル駆動）開発技術
　　　　システムの統合化
　　　　　　全体システムとしての安全性・信頼性の確保
　　　　　　共通モデルによる上流段階での検討
　　　　開発のグローバル化

使用しているプログラミング言語
　　使用しているプログラミング言語（人手）
　　　　Ｃ　　　　　　５７．４％
　　　　Ｃ＋＋，Ｃ＃　２４％
　　　　Ｊａｖａ　　　７．４％
　　使用しているモデルベース言語（自動コード生成）
　　　　ＵＭＬ　　　１８．５％
　　　　ＳｙｓＭＬ　１．７％

モデルベース開発技術の利用状況
　　　状態遷移モデル（図／表など）
　　　ＵＭＬ／ＳｙｓＭＬ
　　　制御モデル
　　　形式的使用言語
　　　→ＳＩＬＳ、ＨＩＬＳはあまりない（一部のプロジェクト）
　　　　エンジンのシミュレーション：数億円

国の取り組みとモデルベース開発
　　「組み込み産業イノベーション協議会設立に関する委員会」
　　「統合システム設計環境に関する検討員会」における課題の検討

企業における実態
　　理由
　　　　コスト削減など
　　ツール
　　　　ＭＡＴＬＡＢなど

人材育成
　　スキルの可視化
　　技術の可視化、明確化

ＥＴＳＳスキル基準
　　スキルフレームワーク

モデルベース開発技術者スキル検討
　　モデリング（モデルを作成する）
　　　　抽象化する
　　　　分解、分析できる
　　　　再構築できる
　　　　表現（出力）できる
　　　　検証できる
　　モデルを活用する


　　すり合わせ開発

モデルベース開発技術者スキル標準検討方針
　　組み込みスキルマネジメント協会

企業価値と人材
開発企業の収益向上策
　　収益向上
　　　　生産性向上
　　　　　　エンジニアリング強化
　　　　　　　　　自動化
　　　　　　　　　ルール化
　　　　　　スキル強化
　　　　　　　　　育成
　　　　　　　　　調達

人材育成による企業価値向上


質問
・ＰＭって、何をする人なの？
　　かりにＡＰＳ，ＳＷＤをたばねるとすると、３．５人に１人ＰＭ
　　今後もＰＭを養成したいって・・・
　　ＰＭ神話では？

質問
・海外の求めている人材とは違うのでは？

質問
・ＣＯＢＯＬならＩＴＳＳレベル４だけど、形式仕様はさっぱり判らない
　という人が、形式仕様の仕事の指導をして、新人にビシバシ教えて
　いいんかい？

答え
・そういうことにならないように技術を可視化する。
　可視化すると
　　　ＣＯＢＯＬ　４
　　　形式仕様　　１
　となり、形式仕様をやらなければいけないことが分かる。

アジャイルモデリングで作るドキュメントなどの全体像

ここにあるらしいよ


http://www.ss.com.au/articles/Agile%20Modeling.pdf


アジャイルなので、ユーザー中心指向に近い考え方ですよね。
そいうえば、アジャイルで使うユーザーストーリーマップに、

　　「ユーザーの気持ち」をいれると、

ユーザー中心指向の
カスタマー・ジャーニー・マップになるのかしら？

Oracle互換ＲＤＢＭＳ「Tibero」

っていう記事が、

　　「日経ＳＹＳＴＥＭ」　２０１２年８月号　６０ページ

から出てるけど、
Oracle買う人って、値段が高くても、安全性とか安心感を求める人っていう
イメージ強いんだけど（じゃなきゃ、ＭｙＳＱＬ，PostgreSQLを使う）・・・

１００％互換したとしても、値段にあまり差がなかったら、
Oracle使うユーザーは、Oracle買う気がするけど、どうなんだろう・・・？

ソフトウェア工学のコペルニクス的転回

昨日書いた、「ソフトウェア工学のコペルニクス的転回」について、ちょっと詳しく書いてみる。

これは、プログラマ、システムエンジニアがシステムを決定し、機能要件をもとにトップダウンに決めていくソフトウエア開発から
ユーザー、デザイナーが、システムを決定し、非機能要件である操作性などを重視して、どちらかというとボトムアップに決まっていくソフトウェア開発への移行の話。

昔は、ウォーターフォールとかの開発方法で、機能要件を出して、それを元に、設計に落とし込み、実装、テストするという方法だった。
この場合、機能要件から設計に落とし込むところ、設計から実装に落とし込むところが重要で、そこを担当するシステムエンジニア、プログラマが中心となってシステムを構築した、ユーザーはその間、確認は受けるものの、主体的に動いているとは言えない状況だった。

　その後、ベームがでてきて、スパイラルとかになったり、イテラティブな開発になったりはしたけれど、
　　・要求を決める
　　　　　特に機能要件重視
　　　　　曖昧さを許さない
　　・システムエンジニア、プログラマが中心
　　・トップダウンに作っていく。
　という点は、変わっていない。



　その結果・・・ユーザーの要望とは遠いシステムになって言った。
　たしかに、機能はある。しかし、このようなものは、要求していない。
　そもそも、このパラダイムは、曖昧さがあったら開発できないことになってしまうが、
　世の中、普通、曖昧だ。


　そこで、ユーザーの体験（エクスペリエンス　ＵＸ）を重視した、ユーザー中心設計が出始めてきた。

　　この場合、システムの部品は既にあって（画面の部品とか）それらをユーザーとデザイナーが中心になって組み合わせていく。
　　プログラミングは、最後のモデル部分と、はじめの部品を作る部分くらい。
　　操作性が重視されるので、非機能要件中心といえる。
　　ボトムアップに近く、曖昧だろうが、作り始めてしまう。

　といった、今までとは、反対の開発方法になっていった。
　この開発方法になじむのがアジャイルとなる（ユーザーを巻き込んで開発するので）

　つまり、まとめると、アジャイル＋ユーザー中心設計は
　　・操作感を決める
　　　　　特に非機能要件の操作性重視
　　　　　曖昧でも、突っ走る（＾＾；）
　　・ユーザー中心（ＳＥ，プログラマーはユーザーの夢の実現を支援、応援）
　　・ボトムアップでも作れる。
　というかんじで、こちらに、移ってきている。そういう意味で、"software is dead."
　かもしれない。

いつの間に「ソフトウエア工学からアジャイルが脱却した」んだろう（＾＾；）

ひらなべさんのTweet

ダライ・ラマは、東洋医学の9割は患者と医者の関係にあり薬のみの分析は役に立たない、と。西洋医学はプラシーボ効果を除くのが常識。このことと、ソフトウエア工学からアジャイルが脱却したことは、似ている
https://twitter.com/hiranabe/status/226507258291429376


いつの間に、「ソフトウエア工学からアジャイルが脱却した」んだろう（＾＾；）


ただ、これが、今の学会や大企業、経団連とかが意識している意味での「ソフトウェア工学」の意味、つまり、ソフトウェア技術者と言う人たちがソフトウェアを作り、その人たちのための工学としてのソフトウェア工学なら、そのとおり。

アメリカで使われるテキスト

Software Engineering: A Practitioner's Approach

の１ページ（Ｃｈａｐｔｅｒ１の章の表紙）に、

"software is dead."

って出てくるけど、それと同じだと思う。
そのあとで、

"No it's dead... at least as once knew it"

once knew it（knewは「過去形」！で、現在完了でない！！）のソフトウェア工学はたしかに死んだし、その中にアジャイルはないんだよね。

　実際、死んだソフトウェア工学のあとの（ソフトウェア工学の）話が、このテキストでは展開され、３章では、日本には、あまり紹介されていないようなアジャイル（ＤＳＤＭやＡＳＤとか）が出てくる。あ、もちろん、ＸＰやScrumもでてくる。

　いまや、このテキストも古くて、「ユーザー中心設計」になり、デザイナーが力をもち、彼らのためのソフトウェア工学にいまやなりつつある。
　つまり、ソフトウェア工学のコペルニクス的転回（エンジニアのためのソフトウェア工学から、ユーザーのためのソフトウェア工学へ）が起こり、ソフトウェア工学が学際的になって、社会学との融合が進んできている。
　その結果、儲かるためのソフトウェア開発から、ソフトウェアをとりまく環境を構築するためのソフトウェア工学（社会学？）に変わりつつあるっていうのが、ソフトウェア工学の「いまここ」なんじゃないかな、と思います。

7月20日(金)のつぶやき

22:36 from gooBlog production
SysMLとＭＢＳＥ blog.goo.ne.jp/xmldtp/e/8efbc…

by xmldtp on Twitter

SysMLとＭＢＳＥ

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


高信頼設計を実現するモデルベース開発

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

---

平成２３年度も出るベース開発技術部会
　・統合システムモデリング技術ＷＧ
　・ユーザーモデリング技術ＷＧ
　・消費者機械安全標準化ＰＴ

統合システムモデリングＷＧ
・代表的なモデリング手法を検討
　　ＭＤＤ
　　ＭＢＤ
・ＭＤＤとＭＢＤの統合
　　→ソフトウェアだけでなんとかなるものではない
　　→システムズエンジニアリング

２０１２年度部会構成

システムズエンジニアリング
・システムエンジニアリングは聞いたことある
　　→混同されがち
　　→勘違いされがち

現在のシステム開発の特徴
・あらたなエンジニアリング領域への対応
　　・機能安全（ディペンダビリティ）
　　　ＩＥＣ６１５０８、ＩＳＯ２６２６２
　　　　　→２年後、規格とってナイト、自動車欧州に輸出できなくなる
　　・環境工学
　　・ＱＣＤＳＥ

現在のシステム開発の特徴（２）
・大規模複雑化の加速
　　　・統合システム（Ｓｙｓｔｅｍ－ｏｆ－Ｓｙｓｔｅｍ）

システム開発の課題
・エンジニアリング領域の拡大と大規模複雑化
　　　→ドキュメントの増加
・効果的な記述言語とコミュニケーション方法
　　　モデルの導入
　　　ＭＢＳＥ（Ｍｏｄｅｌ　Ｂａｓｅｄ　Ｓｙｓｔｅｍｓ　Ｅｎｇｉｎｅｅｒｉｎｇ）
　　　導入のためのマップ

ＭＢＳＥ
　　　モデルを活用したシステムズエンジニアリング
　　　ＳｙｓＭＬ

ＭＢＳＥの基本構造

　　　　　　　　検証モデル
　　　　　　　　　　↑　アシュアランスモデルも？
　　要求・制約→対象モデル→構成要素モデル
　　　　　　　　　　↓
　　　　　　　　　分析モデル

ＭＢＳＥのスコープ
　　Ｓｙｓｔｅｍ　ｏｆ　Ｓｙｓｔｅｍ
　　Ｓｙｓｔｅｍ
　　エレメント（ハードソフト）
　　コンポーネント

Ｄｕａｌ　Ｖｅｅ　Ｍｏｄｅｌ
　　それぞれのレベルでＶ（必要な開発と検証）

Ｓｙｓｔｅｍ　Ｏｆ　Ｓｙｓｔｅｍレベル
　　システムに分割
　　複数のシステムがくみあわさった

Ｓｙｓｔｅｍレベル
　　ハードとソフトにわけていく

エレメント（ソフトウェア）レベル

ＭＢＳＥの手順
　要求・制約
　ユースケースモデル
　相互作用、振る舞い
　オントロジー
　ＨＷとＳＷの分割モデル

システムレベルのＳｙｓＭＬ４本柱
　　構造
　　振る舞い
　　要求
　　パラメトリック
　　　　数式
　　　　運動方程式

オープンモデリカでじっこう

パラメトリックとシミュレーション
　　ＥＡ→シミュレーション

ＳｙｓＭＬとトレードオフ

ＭＢＳＥの利点
　・要件ヤッケ意の共通理解が容易
　・複雑なシステム設計過程の管理が容易
　・設計品質が向上
　・早い段階から継続的にＶ＆Ｖでリスク低減
　・ライフサイクルを通じて価値を提供
　・モデルにより知識の獲得が容易」

　→形式手法連携（ＳＰＩＮに持っていったりとか）できる
　→粒度を決めておかないと・・・
　→ツールをどう組み合わせていくか
　　ＩＰＡにピーターホフマンがきた。

ステークホルダーにとって
　　早い段階で意識あわせ
　　ほしいものを明確にしてくれる
　　成果物を作る手順が明確になる

日本の減少
　ＥＳＥＣ２０１２のＩＰＡブースアンケート
　　２／３がＳｙｓＭＬを使っている

ビューポイントとビュー
　　アイデアや要求、制約を扱う
　　　idea view
　　システムの使い方や運用方法などを扱う

　　機能の構造や振る舞いを定義する
　　構成要素への分割を定義する
　　Dependanbility Assuranceを扱う
Safety view

MBSEの４＋１ビュー

代表的なＭＢＳＥ手法
・汎用的なもの
　　　ＲＵＰ　Ｆｏｒ　ＳＥ
　　　ＨａｒｍｏｎｙＳＥ（ＭｂＳＥ）
　　　ＯＯＳＥＭ
・ドメインを明確
　　　ＥＡＳＩＳ　自動車
　　　ＡＳＳＥＲＴ高信頼性システム
　　　ＧＥＮＥＳＹＳ　クロスドメイン

本
　英語の本
　システムズモデリング言語ＳｙｓＭＬ

Ｉｄｅａ　Ｖｉｅｗの考え方
　　アイデアから要求は難しい

指向からのトレーサビリティ
　　マインドマップによる指向の構造化
　　ＧＳＮによるゴールの構造化
　　要求図による要求の構造化

ステークホルダー要求の場合
　　ステークホルダー要求マップ→ニーズに近い
　　マインドマップによる指向の構造化
　　ＧＳＮによるゴールの構造化

Safety Viewも同様
　　ハザード分析結果
　　マインドマップによる指向の構造化
　　ＧＳＮによるゴールの構造化

要求からユースケースへ
　　構造化された要求～ユースケースを導く
　　ここから先はＯＯＳＥＭやＨＡＲＭＯＮＹ　ＳＥでも

ＧＳＮからユースケースへ
　　名古屋の高田先生は、
　　あまりこまかいことをやると、とんでもないことに
　　　　→要求を図にあらわすと、とんでもない量に！

ＭｉｎｄＭａｐの例
　　スマートグリッド
指向からゴールへ
Ａｓｓｕａｒａｎｃｅ　Ｃａｓｅ（ＧＳＮの例）
Ｃｌａｉｍ　　Ａｒｇｕｍｅｎｔ　　Ｅｖｉｄｅｎｃｅ
（ＧＳＭ）
ゴール　　　　ストラテジー・サブゴール


アシュアランスケース
　　　ディペンダビリティケース
　　　　Ｄ－ＣＡＳＥ
　　　セキュリティケース

アシュアランスケースの表記

アシュアランスケースと信頼性評価

ＭＢＳＥ導入マップ
　　（１）システムズエンジニアリング実施における
　　　　モデリングと基本タスクの対応モデル
　　（２）システムズエンジニアリングを日本の産業界に導入するための


　　　

ユーザー中心設計を実現するには、アジャイルになる？

　ユーザー中心設計という概念がある。
　Wikipediaによると(以下太字は引用）


ユーザー中心設計は言わば問題解決を繰り返す過程であり、単に設計者がインタフェースがどのようにユーザーに使われるかを解析し予測するだけでなく、前提が正しいかどうかを実際のユーザーによる試用で確認するということも行う。ユーザーが初めてそのデザインに触れたときどう感じるかを、設計者が直観的に理解することは非常に難しいため、そのような試用が必要となる。また、ユーザーの習熟曲線がどのようになるかということが試用によって初めて明らかとなる。


ユーザーが設計に大きく関与する点、試用によって繰り返しを行う点を考えると
　　・ウォーターフォールは繰り返さない
　　・スパイラルモデルは、ユーザーが大きく関与しない
　　・インクリメンタルも、ユーザーの関与は小さい
なので、この開発プロセスは、アジャイルということになる？

アジャイルは、まさにこれですよね。

大学は、電気たりなくて、とめられると、やばいよね・・

立教大学は、イッてしまったようだ・・・


立教大学‏@rikkyouniv

【学内の方へ】本日13時22分池袋キャンパス構内で広い範囲にわたり停電が発生しました。原因は電力使用量が許容量を超過したためです。13時48分現在復旧しておりますが、再度停電する恐れがありますので、節電にご協力ください。


https://twitter.com/rikkyouniv/status/225095558258376704


でも、大学で急に電気がとまると、やばいよね。
実験中の場合や計算機処理中の場合。

病院とかだと、発電機あるだろうけど・・・あるよねえ（＾＾；）

ソーシャルゲームのＫＬａｂが発表した決算が想像以上にヤバイ

なにが、どうなると、こうなるの？

ここの記事

成長企業が突然失速して傾きはじめる瞬間、ソーシャルゲームのＫＬａｂが発表した決算が想像以上にヤバイ
http://kabumatome.doorblog.jp/archives/65693961.html


第３四半期は絶好調なんだけど、第４四半期に急激に落ち込む・・・

・・・コンプガチャ規制のため？

IPAは、形式仕様、とりあえずＶＤＭが中心みたい・・・

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


ソフトウェアの高品質を実現するアプローチ
～開発ライフサイクルを通して正しさを議論するための形式手法等～

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

---

※まだ発表していないものの一部なので、ＳＥＣのＨＰにまだ上がっていません

トラブルは開発中でなくリリース後に発生
・いくら開発中のバグフィックスをしても、クリープは発生しがち
・Ｖモデルのいける検証の考え方はリリース後に出るエラーは開発当初のステージで組み込まれた潜在バグ
・ということは、最初に組み込まれたか、リリース後の運用を考慮しない仕様にしたものは、リリース後にエラーとして出現

ソフトウェア産業の実態把握に関する調査
・ＱＣＤ未発達の原因（１）
・エンタ系ＳＷベンダ８９社、ユーザー１１１社
・ユーザー系、ベンダー系で明らかな違い
　　・ユーザー：要求定義問題
　　・ベンダー系：要求定義以前

ソフトウェア産業の実態把握に関する調査
・ＱＣＤ未発達の原因（２）
・ユーザーは「業務・システム要求定義工程における問題」が圧倒的に一番問題があると感じ
・ベンダは、「要求定義工程以前における問題」についで、「システム／ソフトウェア設計工程」における問題に感じている
・上流工程において問題が根源があると感じている

ＳＷ開発ライフサイクルの調査統計データ

ソフトウェア産業の実態把握に関する調査
・設計や実装に不具合原因のピークが来る
・組み込みとエンタープライズではピークが違う

海外との比較
・ＮＩＳＴ　planning report 02-3 May 2002\
　　→海外は前段階に投入するeffortが増えている
・日本の品質の高さ
　　コスト、納期に比べると・・・

Standishレポート２０１０年
　　failed 21%
　　Successful 37%

日本の調査対象プロジェクトのサイズ
白書
　　Ｎ＝１０８９　中央値 48.3KSLOK
実態把握に対する調査
　　規模小さい

Standishレポート２００２～２０１０年
・あんまり変わっていない
　　　→ソフトウェア工学は？
・デッドコードの問題

ＳＥＣでは、しゅしゅの上流工程への改善策をしさく

上流プロジェクトの例
・企画プロセスの規格化のためのガイド
・ＧＱＭ＋ストラテジー
・機能要件合意形成ガイド
・非機能要求グレード
・形式手法

情報系の実稼動システムを対象とした形式手法適用実験報告書
・５～６００ページの仕様書
・形式仕様で書いて評価
　　　→５５件見つかった
　　　→２２件は修正が必要
　　　→設計内容の衝突　１５件
　　　　設計内容の不足　２５件
　　結構見つかる・・・

「ＳＥＣによる対象のモデル化調査」からの成果
　　要求から方法論を検討

「ＳＥＣの厳密な仕様記述ＷＧ」からの成果
　　２０１２年度末にガイドとして発行予定
　　発注者と受注者のしゃべる言葉が違う
　　　　→日本語とＣ言語
　　アジャイルとかもそう
　　あすどっく：日本語の品質

「ＳＥＣ形式手法人材育成ＷＧからの成果」
　　近々 SEC HPからリリース予定

　　心理的ハードルを除去する入門教材

　　でーびっと・ぱーなす　ＳＤＩは意味ないと発言
　　　　　ＩＥＥＥ　かばーふぃーちゃー
　　　　　Rethinking Formal Methods
　　誤解を短くしたい


事例

私たちの現実
　　・普通のチームとメンバ
　　・現場にプレッシャーをかけても品質は高くならない
　　・銀の弾丸はない

情報技術セキュリティ評価基準ＩＳＯ／ＩＥＣ　１５４０８
　・ヨーロッパでのビジネス：標準
　　２６２６２が有名

機能安全　ＩＥＣ６１５０８

なぜ形式手法か？理論的根拠
・ベーム　２００７
　　欠陥修正コストが10分の１から２００分の1
　早い段階で難しい理由
　　自分たちが何がほしいか、明確にいえない
　上流のレビューと下流のテスト

開発プロセスと形式手法
　　・形式手法を克明にヒアリング

　　どの開発工程に形式仕様を適用するか
　　適用工程とほかの開発工程との関係をどうするか
　　適用公邸内で形式手法とほかの手法の関係をどうするか
　　複数の形式手法を用いる場合

間接的効果の重要性
　　ドメインの再構築
　　　　暗黙の全体、常識＝共通ではない
　　　　あいまい性の顕在化
　　コミュニケーションの道具
　　　　論点が明確
　　建設的な議論のたたき台
　　　　参照モデル
　　知識の共有、継承
　　　　理解と修得の早さ　　　　

実践のポイント
　　管理職の意識
　　厳密な記述と議論
　　コミュニティ

２つのおねがい
　　ＳＥＣのホームページに登録してね！
　　　　→今、５万人
　　ＳＥＣのホームページＳＷＥ　Ｉｐｅｄｉａv

TCPを超える次世代通信プロトコル

って、どんなのなんだろう？
あとで見る。

TCPを超える次世代通信プロトコル
http://www.datahotel.co.jp/release/detail/?nid=20

筑波大学発のコーラスパート生成サービス「vocarus」が公開

だって！


初音ミクみく
出た！筑波大学発のコーラスパート生成サービス「vocarus」が公開
http://vocaloid.blog120.fc2.com/blog-entry-12331.html

によると（以下太字は上記サイトより引用）

先日、「筑波大学ボーカロイドUGC創作支援プロジェクト2012」から、2012年7月9日に、WEBサービス「vocarus」が公開されるという告知がきていたが、情報によれば、特設サイトが実際に公開になっているもよう。「ボーカロイドファイルからコードを推定し、自動でコーラスパートを生成」できるらしいので、興味ある人は実験…よのさ＾＾

とのこと。