ソフトウェア開発工程
ソフトウェアの内部設計を文書化するタスクは重要だが、しばしば見過ごされている。これは将来の保守と改良に使用される。文書化は外部インターフェイスにとっては最も重要である。
したがって、アーキテクチャとソリューションの機能のほとんどがアプリケーションのバックボーンに選ばれた技術で実現されていると仮定すると(つまり、ミドルウェアで実現されている。)、これらの手法は実際には保守ライフサイクルと同義である。
リファクタリングは、設計を慎重に行って文書化することの代替案としてアジャイル・コミュニティが提案したものである。アーキテクチャ上の問題に対するリエンジニアリングへの代替案は提案されていない。どちらも比較するとコストがかかる。既存のコードへのリファクタリングを1回通して行うと 10% から 15% のコスト増となると言われている。しかし、この値に再評価やリグレッションテストも含んでいるかどうかは不明である。もちろん、既存のアーキテクチャを捨ててしまう方がさらにコストがかかる。実際、アジャイル的手法を利用した開発ではコスト問題に悩んでいるという調査結果がある(Software Development at Microsoft Observed)。ここでは、基本設計の管理よりもプログラミング担当者らによる定常的なリバースエンジニアリングが強調されている点に注意されたい。
テスト駆動開発(TDD)はアジャイル的手法から生まれた便利な手法だが、同時に問題もはらんでいる。TDDではコードを書く前にそのコードに関する単体テストを書く必要がある。したがって、まずどういうコードを書くかを考え、それを書く前にその単体テストを書けるほど十分に詳細を決定しなければならない。アジャイルソフトウェア開発では簡単な設計からコードを書くのであるから、TDDをアジャイル的でない開発工程モデルに取り入れることはアジャイル的なものとは正反対となる。
ソフトウェア開発のプロセスモデルが開発工程モデルである。様々なソフトウェアライフサイクルで共通してみられるいくつかのモデルが存在する。それぞれのモデルには特徴があり、実際の開発ではプロジェクトに応じたモデルを含むソフトウェア開発方法論の選択が重要である。