くだらん話が9.5割

寝るために頑張るというのは、非常に気に入らない。

頑張って寝るなら、寝ないでいいじゃないかと思えてくる。と思ってたら寝てしまう。
 むかついてくる。

4年になったからこそ、昔話ができるんだなと、今日は思った。
 木陰の下にあるベンチで一年生の思い出を話していると、あの頃の自分がバカだったと思う。今もバカではあるが、あの頃より良いバカにはなったと思う。

さて、
要求仕様書を書いているわけですが、進むところは進むが、進まないところは本当に進まない。

一番重要の要求と仕様が、さっぱり思いつかない。
知識が足りないのと、まだはっきりと決まっていないことがあるから、と言い訳したい。

Ver.1.0を挙げてみたのはいいけど、かなりひどい。
しかし、とりあえず挙げた。

悩んで、もたもたしてもどうしようもない。
出したモノを基に詳しく決めていくか、ズタズタに破いて考えなおすか…

だけど、ベースライン(1はちゃんと制作しておきたいという気持ちもある。
これがあると、改善(要求の)には役たつはずである。
要求仕様がゴロゴロ変化するならなおさらのことかと。

ただ、自分が書いてる奴は、ボロボロのラインになってるから…。

1)　ベースライン：ものが時間的経過を伴って変化をするとき、変化や実験効果の有無を観察するために、決められた判定基準のこと。要求仕様書のベースラインは「進歩」や「達成」を図る基準とも言える。
　

佐○先生の部屋のドアに貼ってある、ミクさんのポスターが気になる

たぶんだが、これのポスターだと思う。
http://antenna7.com/artdesign/2012/04/the_end.html

VOCALOIDの新境地をみたいとかは特にないが、あのポスターの絵が好きだ。ただで天使の（ｒｙ

しかし、なぜ貼ってるのだろうか。この話に参加しているのだろうか。ありえる話ではあるが･･･。

要求仕様を書こうというところに来たわけで、意外とかけそうな気がしてきた。
と、思いたい。

凍結判断ライン(11月9日)も定めたわけで、がんばって走らないといけないなと。

話変わりまして、ここから、全部持論に等しい話。

要求を仕様化する技術・表現する技術(1、を全部読んでいないが、流し見して、(時間あったらきっちり読むつもりです)なんとなく思ったこと。

ざっと見た感じなんですが、この本は要求に関すプロセスで発生する問題とその解決法について、まとめたものだと思った。

今の自分の状況（開発始まる段階）で使えるものだと思うが、読む時間がない。

350ページくらいで、それほど厚くはないが、字と字の間隔が狭く、意外と内容が多いと感じた。それと、見にくい。

この本で、ちょっと特徴的だと思ったことを一つ。

いままで読んできた本では、要求仕様書について話すとき、要求と仕様の関係は平行にあったのだが、この本ではどうも階層になっている気がする。
以下の図が自分のイメージ。

このことは本にも書いてあったかもしれないが、結構特徴的なものだと思う。

というか、IEEE規約(2から外れている気さえする。(IEEEにかならず当てはまる必要はない)しかし、確かにこの考え方は、漏れを少なくすることができるような気がする。（やってみないとわからない）


(1　要求を仕様化する技術・表現する技術
(http://www.amazon.co.jp/%E8%A6%81%E6%B1%82%E3%82%92%E4%BB%95%E6%A7%98%E5%8C%96%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93%E3%83%BB%E8%A1%A8%E7%8F%BE%E3%81%99%E3%82%8B%E6%8A%80%E8%A1%93-%E5%85%A5%E9%96%80%EF%BC%8B%E5%AE%9F%E8%B7%B5-%E4%BB%95%E6%A7%98%E3%81%8C%E6%9B%B8%E3%81%91%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B-%E6%B8%85%E6%B0%B4-%E5%90%89%E7%94%B7/dp/4774125237)

(2　IEEE830：要求仕様規格
http://www.bcm.co.jp/site/2004/2004Dec/04-youkyuu-kougaku-12/04-youkyuu-kougaku-12.htm


最後にどうでもいいことが一つ。
　OSの成績がどうなっているのか、気になる。
　「さっさと出せよ」。
　いろいろと決めないといけないことが有るのに･･･。
　

お前の知ってる「○○ックス」の種類を数えな。（仮面ライダーW）

問題を発見する前に、まず問題を発見するための方法に問題がないか、検証しないといけない。

と、思っているのだが、放置したい気持ちでいっぱいだ。

さて、今日は、開発初期段階で、プロトタイプの導入という話がチラッと聞こえて、速攻で否定してしまったけど、良く考えたら、前回の反省を活かすのであれば、今らか使うべきなのであろう。

ただ、プロトタイプを導入する場合、どうすればいいのだろうか。

わからん。

開発の話が進んだけど、これからどうすればいいのだろうか。

抽出と分析を行う必要があるでしょうけど、仕様化はどうすればいいのだろうか･･･

疑問しか出てこない。

ががががが・・・・・

どうでもいいことを一つ。

モノを作るとき、道具確認しないと、本当だめだ。設計図ばかりに気をとられていると、アウトなきがする。

ということは、ツール確認したほうがいいのかもしれない。


以下はアイスブレイクのサイト。これから使うから、忘れないように貼っておこう。
http://icebreak.blog102.fc2.com/

http://www.gshift.com/bgComIcebreak.htm

「月がきれいですね」の「月」を「太陽」に置き換えたら、どういう意味になるんだ？

「太陽」に置き換えたら、「暑いんだよ、あっち行けよ」という意味になると思っている。

つい先日、中秋の名月だったわけで(9月30日)、すでに終わっているが。

月は相変わらずまるい。月見する気分にはなれないけど。

というか、雨降ってないか、今（10月2日）？



まぁ、そんなことはいいや。

前回のCEMPEI開発は、要求に問題があると思っているが、はっきりと指摘できるほど問題追求を行っていないため、ゼミで躓く。

前に進めず、ぐるぐる回ってる。

しかし、問題をはっきりとした場合、果たして本当に前に進めるかどうか・・・そんな一抹の不安がある。

そして、そちらの話を考えつつ、始まった第二回の開発。
今回は、要求のことに注意するつもりだが、テストの話とかもあるなと思い出す。

前回の開発を踏まえると、テストで、まず気をつけないといけないことは、

・テストを行う時期より前にテスト計画を立てる。
・テスト項目と要求（仕様かもしれない）項目を関連付けする。

だと、思っていたりする。

内容とかよりも、やり方の話である。

前回はこれがすでにできていない。今考えたら、何をしていたのやら。

気をつけるからといって、できるかどうかというのはわからないが、この二つを心にとどめておくとしよう。

ただ、少し気になるのは、自分たちがかかわっている開発を自分たちで（俺とか）テストするというのは、どうも違うような気がする。

何が違うのかはいまいちはっきりといえない。

本当、はっきりといえないことが多い。つらい。


どうでもいい話を一つ。
ヘルの兄弟たちの名前が、ヴァナルガンド（フェンリルの別名）、ヨルムンガンドだから、
ヘルにも「～ガンド」という別名があるのではないと思って探したが、ないということがわかってむなしい気持ちになったので、ここで終わりにしよう。