オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

派生開発、保守開発のレビュー

»

過去のバージョンのソフトウェア(母体、流用元、コア資産と呼ばれることもあると思います)をもとに拡張、変更をして次のバージョンのソフトウェアを開発することを保守開発(software maintenance)、ソフトウェア進化(software evolution)と呼んでいます。同一の過去バージョンをもとに、類似のソフトウェア、サービス、製品を同時に開発する場合には、派生開発と呼ぶこともあります。多数のバリエーションがある機器の組込みソフトウェアを想定いただくと派生開発がイメージしやすいと思います。

こういった過去のバージョンをもとに次のバージョンを開発するときの課題の一つは、過去のバージョンとの整合性を保ちながら新しいバージョンでの拡張、変更を実施することです。こうした開発では、拡張、変更した部分が期待通り動くだけでなく、過去のバージョンで提供されていたものも期待通り動くことが前提となっていることがほとんどです。

設計、実装においては過去のバージョンのドキュメントやソースコードの理解が必要になることが新規に開発するときと異なります。バージョンアップを重ねるとドキュメントの記述(ソースコード中のコメントも同様です)とソースコードの記述に乖離が生じてしまい、ドキュメントやコメントの記述が勘違いやミスを引き起こすこともあります。また、当初のアーキテクチャがくずれてしまい特殊なパターンの場合のみの抜け穴があったり、過去の場当たり的な修正により、複雑な変更が必要になったりする場合も少なくありません。

テストでは、拡張、変更した部分が期待通り動作するかを確認するテストに加え、過去のバージョンの動作が損なわれていないかを確認するテストが必要になります。過去のバージョンを確認するテストは拡張、変更した部分の規模とは直接関係がないことが多いため、小さい拡張、変更であっても膨大なテストが必要になる場合もあります。このことが問題になることも少なくありません。

レビューでも同様に、拡張、変更に問題がないかを確認することと既存の部分に問題が引き起こされないかどうかを確認します。設計書、仕様書をはじめとしたドキュメントを対象としたレビューの場合、既存部分に関しては過去のバージョンのドキュメントによって確認することになります。急場しのぎの変更があったりドキュメントを維持していなかったりして、ドキュメントが実際のソースコードと乖離している場合には、レビューの作業がムダになってしまうこともあります。乖離がないかどうかから確認していく必要があります。

保守、派生開発におけるレビューの検出シナリオは、拡張、変更部分に問題がないことを確認するシナリオ、拡張、変更によって既存部分に副作用を及ぼさないことを確認するシナリオに大別できます。さらに今後、保守、派生バージョンの開発が予定される場合には、更改にむけて設計方針やアーキテクチャの一貫性が保たれているかといったこともシナリオに含めることで、将来の保守、拡張コストの肥大化を防ぎます。

こうした保守開発、派生開発のレビューに関して講演する機会をいただきました。タイトルは「派生開発におけるレビュー ― 早期の品質確保を目指して」です。2014/9/5(金) 14:00~ 場所は東銀座です。無料ですが事前登録が必要です。事前登録等の詳細はこちら

国内ではソフトウェアメインテナンス研究会派生開発推進協議会といった団体で検討され、事例や成果が公開されています。また、論文 ソフトウェア進化研究の分類と動向 では、これまでの研究の分類、動向をわかりやすく紹介しています。海外でも重要な問題と位置づけられ、国際会議 International Conference on Software Maintenance and Evolutionや国際ジャーナルJournal of Software: Evolution and Processでも知見が公開されています。

Comment(0)