分析については、マトリックス表を作成したり、分類を行ったりするなどの作業が行われる。分析した事柄に対して証明を行うためには、演繹法と帰納法による証明が行われる。演繹法が用いられる分析は、既知の定義や公理を用いて証明する方法である。それに対して、未知の定義や公理を証明するためには、帰納法による証明が必要になることが多い。既知ではない概念等を証明するためには、数値的データや定性的データを用いた証明方法が必要だからである。演繹法が用いられる局面は、公理系の内部に矛盾が存在しない場合の系の分析に限られるからである。
分析方法を科学的分析と呼ぶ。分析は、事実解明的分析と規範的分析に分類される。
規範的分析は価値判断を含む分析で、事実解明的分析は価値判断を含まない。
問題空間にあり、「解」は解空間にある。設計とは、活動だと考える。分析とは何か。
実際には、（ソフトウェアでは特に）問題が複雑だったり曖昧だったりすることから、このままではうまく解けない（悪構造 ill-structured problem）。
「問題→解」という問題をモデル化しよう、ということになる。「解空間」という空間と直行する空間軸として、上下に「モデル空間」と「現実空間」を導入する。モデル空間の「分析モデル」と「設計モデル」を置く。ここで、分析モデル＝モデル化された問題 、設計モデル＝モデル化された解である。問題→解という直線的な解き方ではなく、一旦モデル空間に上って遠回りをしてみる。
問題をモデル化する活動を「分析」と呼ぶ。
成果物は、「モデル空間上の問題」（分析モデル）だ。モデル空間上で解決させる活動を、「設計」と呼ぶ。モデル空間から現実空間へと逆変換する。成果物は解、すなわち（ソフトウェア開発であれば）動くコードである。
まとめると、設計とは、問題空間から変換である。
一旦問題をモデル化し（分析）、それをモデルで解決する（設計）。モデル領域で変換する。解のモデルを、再度現実領域にもどしてやる。これで解にたどりつく。問題と解との突合せ、すなわち「テスト」である。
テストによって、「右回りの活動」がもともとの意図である「問題→解決」と合っていることを示す。「テスト」こそが、問題に対する解が正しいことの最終的保障になるのだ。一行は、「だから、ソフトウェア開発は「テスト」を第一級の概念として扱うべきなんだ。テストしやすい設計、は決して本末転倒ではない。 」という文がありました。
「落ち」として不適切だったので、取りました。