ソフトウェア開発時に絶対決めておくべき開発アプローチ方法

ソフトウェアを開発する時に、そのソフトウェア構造まで考える人ってなかなか見かけません。

ですけど、ソフトウェアの構造…要するに部品構成や組み立て方と言うのは、少なくともソフトウェアそのものの

　試験容易性（EoT：Ease of Testing）
　変更容易性（EoC：Ease of Change）

に深くかかわってきます。これは、ソフトウェア品質（ISO 9126/JIS X 9126）のなかにある品質特性『保守性』の中の副特性「解析性」「変更性」「安定性」「試験性」などに大きく影響を受けます。

　解析性…不具合や改修時の対象箇所の識別のしやすさ
　変更性…実際の不具合解決や改修のしやすさ
　安定性…改修時の予期せぬ影響の出にくさ
　試験性…不具合解決や改修を行った時の妥当性試験のしやすさ

最新のソフトウェア品質（ISO 25010）では『保守性』の副特性には「モジュール性」「再利用性」「解析性」「修正性」「試験性」とあります。かなりオブジェクト指向的な考え方が盛り込まれるようになっています。

　モジュール性…不具合解決や改修を行った時の、他への影響の出にくさ
　再利用性…他の機能や製品を作る際の使いまわしのしやすさ
　解析性…ISO 9126と同じ。
　修正性…ISO 9126の「変更性」と同じ。
　試験性…ISO 9126と同じ。

となります。

そもそも『保守性』と言うのは、運用・保守の保守にも関係しますが、それ以上に、通常の開発期間中の資源に対する保守性と言う意味でも、大いに影響を与えます。いわば、「プロセス品質」や「内部品質」を支える縁の下の力持ち的な存在です。ISO 9126/JIS X 9126を例に挙げると、このような関係図ができるのではないかと思います。

こうした「保守性」を念頭に置いて、ソフトウェア構造を決定していかなくては、あとになってから

　「思った通りのテストを実施しようと思ったら、超面倒くさい！」
　「これ１行修正するだけで、全部テストしなおしなんだけど」
　「この修正、他の人にも影響出んの！？」
　「ちょ…このソースきったねぇ！すっごい読みづらい！！」
　「なんで、共通化してないの…全く同じことする処理なのに」
　「変数 x って何？！何するローカル変数なの？？」

なんてことが多発します。だからこそ、どのような構造で進めていこうかという、開発アプローチはプロジェクトをスマートに進行するという目的において、とても重要な役割を果たします。