「ドリテク」といって、意味が通じる人に。。

　ＹＡＨＯＯの掲示板、替え歌がわらえる。。。って、ホルダーは笑い事じゃないだろうけど
　（意味通じない人には、意味わかんないと思います。わかる人のみのはなし）

２万２千の別れ （２２歳の別れ）

なごり玉（なごり雪）

なごり玉（なごり雪）２番

で、「ドリテク」わかる人もわかんない人も、この話は。。。

コンピューターに関係ないじゃん（＾＾；）

まあ、ドリテクということで。。。

ソフトウエアの構成管理に関して、分散型ＳＣＭ

　ソフトウエアの構成管理に関しては、集中型のCVSやSubversionを中心にＯＳＳの人たちは言うけれど、現実的な開発において、ネットワークを３次請けや４次請け（＝１次請けの人には会社も名前も知らない人たち）に開放し、CVS等に入れるようにすることは、セキュリティ上、まず考えられない。

　ただ、分散型ＳＣＭ（ソフトウェア構成管理システム）なら、ありなのかなあと思っていて、あるサイトの文をめっけたのでとっておいたものを、以下に書いておきます

（要するに、今、ブックマークを整理していて、今、ブックマークからはずしたいんだけど、まだ読んでいないので、ここに書いているだけの話）

オープン系ソフトウェア構成管理システム(SCM)へのコメント
http://subversion.bluegate.org/wheeler.html

要求仕様（分析）から外部仕様（設計）に落とし込む方法が、昔と今では違う＆ＳＤＬＣの断層の話

以前、IEEE830（要求仕様のIEEEの規格）の話の中で、IEEE 1016（機能仕様書の規格）があまりよくなく、あわせて使いにくいという話を書きましたが、その話をするための前提となる話です。

---

　要求仕様書から、外部仕様書、詳細設計書に落とし込む場合、昔の方法は(IEEE1016でも）、要求仕様を分割して、実現していく方法が提唱されていました。
で、むかしは、この方法でできました。たしかに

　ただ、この方法は、要求仕様と、外部仕様への落とし込みの本質的な問題について答えていません。

　要求仕様とは、「なにを作ってほしいか」であり、
　外部仕様を書く段階になると、「それを、どうやって作るか」という話になります。

　つまり、要求仕様はWhat 外部仕様は、How toにあたります。

　なにを作ればいいかがわかったら、どうやって作るかが、自動的にわかる場合はいいのですが、そうでない場合（やり方がわからないか、やり方がいっぱいある場合）は困ります。分割してもできません。

---

　例を挙げましょう。

　もしも、私が、家を建てたなら、

（分割して詳細化・具体化）

　小さな家で、
　おおきな窓と
　小さなドアにして
　部屋には古い暖炉があって、
　（庭があって）そこに真っ赤なバラと白いパンジーを植えて
　子犬を飼う
　あなたがいる

はい、詳細化しました。でも、家建ちませんよね。

気づいた人は、ある程度、年齢の方？
これ、小坂明子のあなたという歌ですけど、これ、どんなに「家のモノ＝リソース」を詳細化しても、家が建ちませんよね。

　家を建てるには、

１．お金をためる
２．（この次のステップをウィリアムのいたずらは知らない。
　オリジナルの家を建てるのも不動産屋さんに頼むの？）
３．建築家が設計図をつくる
４．大工さんが家をつくる
５．いろんな人が、内装、外装する

っていう、「業務（イベント）」フローをつくんないといけません。


　いま、気がついたんだけど、あなたという歌、「いとしいあなたは今どこに」って言って、結局、家建たないわけだけど、あれ、「あなた」は、１．のお金を持っていたから、その金づるがいなくなって、家が建てられなくなって、だから、「あなたがいて欲しい」なのかなあ？？

---

　つまり、何をするかから、どうやってするかの手続きに変換する必要があります。
　このように、
　　　分析で「何をする」を定義するんだけど、
　　　設計ではそれを「どうやってする」に変換する行為が必要で、
　ここは、連続的ではないですよね。
　そこで、これをＳＤＬＣ（そふとうえあでざいんらいふさいくる）の断層とよばれます。

　佐藤氏のページをみると、ＳＤＬＣの断層って言う言葉、いきなり出てる気がするんだけど。。
　今の人は知ってるんだろうか。。。
　（たぶん、佐藤氏は、「あなた」の歌を知ってるだろう。。関係ないって　＾＾；）

---

　でも、「どうやってする」の手続きが、明白な場合、詳細化してもＯＫです。
　手続きの方法がいろいろある場合、まず、どの方法で行くかをきめないといけません。

　っていうことで、詳細化する前に、フレームワークをきめないといけません。

　もし、先に詳細化してしまうと、詳細化した所から始められてしまい、あとで、つじつまが合わなくなります。さっきの「あなた」の例だと、ドアと、暖炉を先に買われても、家を設計するとき、こまっちゃいます。パンジーを先に買われても、枯れちゃいます。

　なんで、先に、大づかみに全体をつかんで、フレームワークを決めてから、詳細化にはいるということになります。

　昔、ＣＯＢＯＬの場合、画面の作り方や帳票の作り方は、メーカーによって、たいてい決まっていたので、このようなことを（フレームワークを）考えなくても、できました＝できるようなことしか、コンピューター化しようと思いませんでした。

---

　まとめると、要求仕様から、外部設計などの設計段階の仕様書に落とすのに
　　　昔は、（フレームワークが決まっていたから）分割していった。
　　　今は、フレームワークをまず選んで、それから、詳細化する

　で、（実は今も昔も）分析から設計の間には、WhatからHow toへのギャップがある（自動的にでてくるわけではない）。これをＳＤＬＣの断層という。

　ただし・・これは手続き型言語を使っているからで、たとえば、形式仕様記述言語（Ｚ言語など）がそのまま動くマシンがあって、形式記述言語で書けば、こういう断層は「理論上」存在しないけど。。。まあ、そんなもんは、できないだろう（ごめん、Ｚ言語を研究している人たち　＾＾；）

---

以下、自分へのメモ（意味通じなくっても無視してね・・）

IEEEの説明が書いてあるサイト
http://www.metabolics.co.jp/SoftwareProcess/ieee-scsm.html

IEEE 1016の内容とサンプル
http://www5f.biglobe.ne.jp/~hotta/furui/siyousho/032des.html

要求工学のページ
IEEE 830　＝　第三回
要求プロセス工学の比較　＝　第四回
シナリオ分析　＝　第１２回　よまなきゃ