#45 変化か確実か

確実よりも変化についていきたい。
変化するには
要求、設計、ソース解析&実装、試験　→ ☆
各文書を変更する必要がある。

直す箇所が小さければ、修正は小さい。
一つの修正で☆を一回行う。
修正が沢山あると
☆を修正個数分やる必要がある。

☆は即ち
要求を変更する。
設計を変更し、設計が問題ないか
試験を変更し、項目に問題ないか
ソースコードを解析する
ソースコードを変更する
コンパイルして、ソース走査
記述に問題がないか確認する。
試験で動きを確認する。

これを修正個数分、行うことになる。
量はある程度許容できる。
ただ、確実に許容オーバーする量がある。

これをすぐ着手せずに
計画的に進めていきたいのが、
アジャイルのスクラム

どんどん回して、変更要求を0にする幻想をいだく。
どんどん着手する。
ドンドン積み上がる変更要求。

はて、、なぜ終わらぬ？
我に帰る。
積み上がる中で、対応していくと
いずれは、要求は減っていく。
そこまでの辛抱だ。

たた、ソースコードを触ると、
設計書、試験要項書が反映されていく
システムが欲しい。
もしくは要求を入れると、
設計書、ソースコード、試験要項書に
試験までやってくれるシステム。
(そんなんあったらおまんま食えねぇ)

教訓
設計書からソースコードを起こす。
そのあとはソースコードから設計書を自動生成する。
この時、いかに情報量を落とすかが肝