Fact 9 Most software estimates are perfomed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. (p.31)
Why are missing requirements hard to detect and correct? Because the most basic portion of the error removal process in software is requirements-driven. (p.74)
要求がはっきりしないなんていうのは、テクノロジーに疎い人たちが「伝票整理を楽にしたい」みたいことを言う場合だけだと思っていました。ですが、要求を明確にするというのは、思ったよりも難しいことを、最近知りました。サンプリングレート 1000Hz で電圧を取りたいという要求があって、CPU サイクルを節約するために DMA でまとめて転送しましょうと提案します。ところが、後になって、いやフィードバックをしたいので1 サンプルごとに値を確認したい、と言われたり。
Fact 21 For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That's not a condition to try to change (even though reducing complexity is always desirable thing to do); that's just the way it is.""" (p.58)
数字の妥当性はともかく、問題の複雑さの増加よりも、解決ソフトウェアの複雑さが大きくなることは、なんとなく同意できます。特に、ハードウェアに強く依存するようなシステムの場合には。うまく問題を抽象化すれば、ある程度簡単になりそうな気はしますが、それでもシステム側の複雑さは大きくなりそうです。使用するハードウェアの制約が問題を複雑にするのではないでしょうか。
