ソフトウェア開発管理技術｜システムアーキテクト試験

作り方の型と、定義と確認を対で見る工程の枠組み

開発モデルは要求の固まり具合で選びます。ウォータフォールは要求が明確な前提で全機能を工程順に一度に作り、段階的モデルは要求を固めたうえで部分ごとに順に作り足し、進化的モデルは作って使いながら要求を育てます。スパイラルモデルは要件定義からテストまでを循環的に繰り返し、未確定の要求に向きます。どのモデルでも稼働後の保守は必要です。

共通フレームでは、定義した内容とそれを確かめるテストが対になっています。システム要件定義に照らすのがシステム適格性確認テスト、ソフトウェア要件定義に照らすのがソフトウェア適格性確認テストです。発注する側を取得者、作る側を供給者と呼び、分析を委託しても要件を承認するのは取得者です。プロセスを事情に合わせて修正することを修整（テーラリング）といい、保守での修正も開発と同じプロセスを開始して行います。

アジャイル開発のスクラムでは、スプリントごとにスプリントレトロスペクティブで進め方を振り返り、Keep・Problem・TryのKPTなどの手法で整理します。INVESTはユーザーストーリーの質を確かめる六つの観点、インセプションデッキは初期に目的やスコープの共通認識を作る道具です。ペアプログラミングでは書くドライバと助言するナビゲータが一台を共有します。リーンソフトウェア開発は製造業の考え方を移したもので、ムダをなくすなどの原則を重視します。

再利用と分割の考え方も区別します。ユースケース駆動開発はユースケース単位で設計からテストまで進めるので要件ごとの進捗が見えます。ドメインエンジニアリングは特定分野の知識や部品を体系的に整え、マッシュアップは公開されたサービスを組み合わせます。ログ出力のように多くの処理にまたがる関心事を一か所に分けて書くのがアスペクト指向です。

言語の性質では、値呼出しは値の写しを渡すので呼出し元の変数は変わりません。純粋関数型の参照透過性は、同じ引数なら常に同じ結果を返すこと、論理型の推論はユニフィケーションによる照合が基本です。