アジャイルでも、規則は大事

組織・・うんたらかんたら～（経営学関係）の
授業の宿題を、ここでやってみる


＜＜講義内容＞＞

・バーナード
・サイモン
・サイアート＝マーチ
・ガルブレイズ　
　　組織：課業の不確実性を処理するメカニズム
　　　課業の不確実性
　　　　＝課業の遂行に必要な業務（の情報）量
　　　　　－組織が既に持っている情報量
・問題解決の方法
　　問題の把握：構造化＝ＭＥＣＥ、なぜ５回

---

＜＜講義に対するフロアからの質問＞＞

・授業では、問題に対して、なぜを問い（５回？）ＭＥＣＥに分割すること大事。
　また、ルール化、標準化が重要という話であるが、

　アジャイルの世界では、現在は、クネビン・フレームワークにおける
　単純・込み入った問題から、複雑な問題に移行しようとしていると考えているらしい。
　そのような問題では、ＭＥＣＥにできず、「なぜ」と尋ねてもよくわからず、
　課業の不確実性が大きい問題を対処しなければならず、
　「とにかくやってみよう」という方針しか立てられない。

　このような社会においても、従来の問題解決の方法は、有効であろうか？

---

＜＜先生の回答＞＞

有効であると考える。２つの意味で。

（１）すべての問題が、不確実性であろうか？
　会社によっては、たしかに不確実性が高い問題を扱っているだろう。
　しかし、そうでない会社もあるだろう
　（ここで、会社の実名が出たが、その会社の人に失礼なので省略）

　複雑な問題は、従来の考え方だけでは解けないかもしれない。
　しかし、従来の考え方で解ける問題、そのように考えたほうが適当な問題までも
　複雑に考えないといけないと唱えて、思考停止することは、ないだろうか？

（２）複雑な問題は、単純化できないだろうか？
　たしかに複雑な問題を複雑なまま捉えないといけない場合もある。
　しかし、従来の学問のように、構造的に分解して、単純化すれば、解ける場合も
　あるのではないか？
　その場合は、分割し、単純化した部分に対しては、標準化、ルール化できる。

　たしかに、複雑な問題は存在し、それを複雑に扱わなければいけない場合も
多いであろう。しかし、単純化できる問題も多くあり、問題解決には、両方の
視点を持つことが必要である。

---

＜＜宿題：この問題を通して考えること＞＞

　今回のフロアからの質問は、アジャイルとウォーターフォールの関係
とも言える。

　問題によっては、単純な問題もあり、ウォーターフォールが向いている
問題もあるだろう。
なんでもアジャイル、アジャイル最高！というのは、
なんでもウォーターフォール、ウォーターフォール最高！
というのと、大して変わらない思考停止状態なのかもしれない。

　また、アジャイルでも、規則はあるわけだし、標準化すべきこと
　（朝にミーティングする。スプリントの期間などなど）はあるわけで、
　それは、問題が複雑だから、決めなくていいということにはならないであろう。
　複雑な問題を扱うとしても、標準化やルールがなくて良いわけではなく、
　標準化するところもあるけど、決まっていない部分もあるというように
しないといけない。

---

なところで、宿題おわり。

組み込みソフトウェアの場合のＵＭＬ導入の問題とSysML

あ、この前

組み込みソフトウェアに対するアジャイル開発やTDDの導入
http://blog.goo.ne.jp/xmldtp/e/438d499fe2e757fc703c1616fd0a6150


で、

ＩＳＯ２６２６２の「準形式仕様」に相当するものとして、仕様をastah*のＵＭＬで書いたとすると、
トレーサビリティが取れるみたいなことを書いたけど、それで、十分なわけではない。

そこをはっきりさせないと、まるで、組み込みにおけるアジャイル開発がすぐにできて、
ＵＭＬだけでＯＫみたいに見えてしまうので、付け足しておく。

---

組み込みにおいては
　　・資源（メモリなど）が少ない
　　・時間制約がある
といった、非機能要求にまつわる問題がある。
ＵＭＬでは、このような非機能要求を記述するところがないので、
非機能要件とＵＭＬの各種図間のトレーサビリティを取ることは
困難である。

---

たとえば、

　　全ての操作は、２秒以内に応答があるものとする

という要求があったとする。

これに関係するクラスは？ユースケースは、アクティビティは？

というと、「全ての操作」と言っているので、すべてだ・・・

このように、非機能要求の要求は、「すべて」となってしまうものがある。

---

このとき、すべてに関連付けること自体は、なんら問題はない。つけりゃーいいだけ。
問題は、

　　　すべての操作は、２秒以内に反応がある

ということを、どうやって検証していくか・・・だ。
いや、モノができているなら、動かせばいい。

でも、要求の段階で検討するには、モノはできていない。
形式仕様のモデル検査では、状態爆発する可能性がある（高い）
そこで、各モジュールを数式（数理モデル）であらわし、シミュレーションするしかない。

---

もし、シミュレーションを書くことができる図があれば、

そのシミュレーションと、要求が結び付けられる

また処理時間のシミュレーションの場合、シミュレーションの数理モデル式
に出てくる変数などが、クラスやアクティビティなどに結び付く

ということで、「シミュレーションを書くことができる図」ができれば、
要求と機能、シミュレーション間でトレーサビリティが取れるし、
方法を変えたり、機能を変えたりしながら、シミュレーションを繰り返すことで、
設計をアジャイルにできる可能性も出てくる。

ここで、シミュレーション的にＯＫで、設計方針が決まれば、
そのシミュレーションを１ケースとしてテストデータが作れるから、
ＴＤＤができる。

---

ということで、「シミュレーションを書くことができる図」が重要なのだが、
これはＵＭＬにはない。
ＳｙｓＭＬのパラメトリック図に相当する。

---

まとめると、組み込みの場合、性能（応答時間など）の非機能要件が
重要で、これを満たすかどうかというのは、現状、シミュレーションするしかない。

シミュレーションは、非機能要求と機能を結び付け、
シミュレーションを行いながら、アジャイル的に機能を決めていき、
シミュレーションを元にテストケースを作るということは考えられるが、

これはＵＭＬでは記述できず、
ＳｙｓＭＬ（のパラメトリック図）で記述することになる。
（ただし、パラメトリック図が、シュミレーションのすべてを記述できると保証したわけではない）

ってなかんじです・・・

まあ、astah*なら、UMLもSysMLも、どっちも書けるんだったっけ？・・・

「ＣとＯｐｅｎＣＬが判れば、ハードレベルでがんばれちゃうよ！」っていう理解でＯＫ？この記事？

ここの記事

2013年中に正式リリース：
FPGAを活用した並列コンピューティングが加速、アルテラがOpenCL向けSDKを発表
http://monoist.atmarkit.co.jp/mn/articles/1211/07/news034.html


むちゃくちゃまとめて、単純に言えば、
「ＣとＯｐｅｎＣＬが判れば、
　並列処理を
　ＦＰＧＡ使って
　ハードレベルでがんばれちゃうよ！」っていう理解でＯＫ？