C/Sシステムにおけるレビューの方法と範囲

クライアント/サーバー・システムの構築におけるレビューについて記す。

ドキュメント・レビュー

設計書等、ドキュメント上への記載内容をチェックするレビュー。サーバ・アプリケーションは、画面/プロセス単位の、機能仕様と構造、クライアント・アプリケーションは、入出力項目にとどめる。コントロール系は、モジュール・レベルでの機能仕様、I/O仕様(API仕様)等を厳密にチェックする。

実行レビュー(プロトタイプ・レビュー)

実際の利用に供し、稼動状況を観察/確認するレビュー。クライアント・アプリケーションは、並行開発工程において、プロトタイプ的に利用者が利用し、結果を確認することで代替して良い。但し、このレビューは日々行なわれるため、利用者が開発プロジェクトへ参画する事が前提となる。

ソースコード・レビュー

ソース・リストを元に、設計との整合性、ルール準拠状況等をチェック。コントロール系アプリケーション以外は、省略する。ルールベースのチェック・プログラムを開発し、自動化を図る事は可能だが、設計との整合性は、黙視確認が必要である。

データ・レビュー

「任意」は、実行レビューと併用され、処理によって変化するテーブル/カラムの内容チェック等を行なう。「全件」は、DBへの投入後データ、APL実行前後のデータ等をフルダンプし、全データを黙視確認する。データの正確性/妥当性のほか、計算項目は、別途計算した結果との照合も行なう。極めて作業負荷が高いため、勘定系アプリケーションの入出力と、マスタ・データAPL以外は省略する。

  ドキュメント テスト ソース データ(部分) データ(全)
全体システム v        
クライアントAPL v v      
サーバAPL          
登録・参照系 v v      
計算処理系 v v   v  
勘定管理系 v v v   v
運行管理システム v   v v  
データベース          
トランザクション v     v  
システムデータ       v  
業務データ v     v  
マスタデータ v       v
システムの機能/配置に基づくレビュー対象

パワーツールをCASEツール等とリンクさせ、ドキュメントやソース、データ定義などを生成した場合には、サーバ・アプリケーションのソースやデータのレビューは不要となる場合がある。しかし、そのような機能を持つパワーツールはまだ、少ない。各ドキュメントへの記載内容は、今回は割愛するが、パワーツールを用いているクライアント・アプリケーション以外は、ドラスティックに変わる訳ではない。



結論としては、クライアント/サーバ・システム構築でパワーツールを用いても、アプリケーション開発が簡便になった分、システムの設計とプロジェクトの計画・推進は難しくなったと言える。言葉を表面的に捉えて、大いなる幻想や、過大な期待をクライアント/サーバ・システム、あるいは、ダウンサイジングに期待すべきではない。しかし、適切な計画をたて、適切な管理・推進上の処置を施すならば、クライアント/サーバ方式は極めて有効なシステム実現手段であることに変わりはない。そして間違いなく、パワーツールは、これからのシステム開発に、無くてはならないツールへと成長して行くだろう


於:ソフトウェア・シンポジウム’95 滋賀 SEA

コメント