第3章 2回測って一度で切る：上流工程の必要性
コンストラクションの準備は品質向上のため。
品質向上のためには
プロジェクトの
- 終わり＝システムテストの強化
- 途中＝コンストラクションのプラクティスの強化
- 最初＝高品質な製品計画、要求、設計
上流工程（アーキテクチャ、設計、プロジェクト計画）
この工程の目標は、リスクを減らすこと
例えば、組み込み医療システムのライフサイクルモデルは、
- 段階的デリバリー
- スパイラル型開発
- 進化型デリバリー
がある。他にも、進化がプロトタイプなど、規模が小さいもの向けのモデルが有る。
要求の80%を事前に指定し、後から要求を追加する時間を設ける（逐次性）
要求の最重要な20%を指定し、残りを少しずつ開発しながら、要求設計を追加していく（反復性）
という２つの手法がある。
形式や環境、スキル、ビジネスゴール似合わせて選択すると良い。
コンストラクションの準備
１．課題定義：ユーザーの立場での課題の説明
２．要求：ソフトウェアシステムが何をすべきか
３．アーキテクチャ：システムの概念的な整合性に必要な構造を提供する
良いアーキテクチャ：分割できるので、複数の開発者、複数の開発チーム、それぞれが個別に作業できる。
悪いアーキテクチャ：コンストラクションはほぼ無理
優れたアーキテクチャの要素
- プログラムの構成：システム全体像を説明する概要
- 主要なクラス：主なクラスの役割と、他のクラスとのやり取りする方法、クラス従属、状態遷移図、オブジェクトの永続性について
- データ設計：使用する主なファイルやテーブル設計の説明。他に検討されたデータ構造の説明と選ばなかった理由の説明
- 業務ルール：よくわからない！！！
- ユーザーインターフェースの設計：インターフェースは要求か、アーキテクチャで説明する。
- リソース管理
- セキュリティ：脅威モデルの構築
- パフォーマンス
- スケーラビリティ：将来の要求に応えてシステムを拡張できる
- 相互運用性
- 国際かと地域化：文字などローカルサポート
- 入出力
- エラー処理
- エラーを修正するか、検出するか。修正するなら回復、検出するなら継続、中止どうするか
- エラー検出は能動的？受動的？
- エラーをどのように伝達するか
- エラーメッセージのための規約
- 例外は度のタイミングでどのように処理されるのか
- 入出力データをどの程度検証するのか
- どの例外処理メカニズムを使うのか（独自のものか、実環境のものか）
- フォールトトレランス：どのようなフォールトレランスが想定されているのか）フォールトレランスとは、障害の検出をし、回復を試み、失敗したら除外の悪影響を阻止。例えば、部分的運用二変更、機能セーブ、自動シャットダウン・再起動）
- アーキテクチャの実現可能性
- オーバーエンジニアリング（堅牢性）：エラーが検出された後でも、システムを継続的にどれだけのレベルで運用できるか
- 購入か、構築か
- 再利用の決断：前も使っていたからは不十分
- 変更方針：変更できるような柔軟性
- アーキテクチャの全体的な品質