開発者視点によるシステム構成要素

　ファンクションポイント法の意図を解読し、社内でのシステムの開発に適用できないことを論証してしまった私であるが、廃物利用も考えてみた。なにしろここまでしぶとく残ってきた考え方だ。見当はずれではあっても、何らかの現実を切り取っていることは違いあるまい。

　システムの基本的構成要素を洗い出すときに使えないか、と思ったわけだ。ファンクションポイント法はカウント対象として、外部から見える要素だけを洗い出した。システムとはそういうものだと割り切って考えた結果としては悪くない。特に外部入力をデータとアクションに分けて考えたところはなかなかである。では、ファンクションポイント法で捨象された要素は何か、を考えてみたわけである。

　その結果、作った図はこんなもん。

　各項目の解説はこういう感じ。（ファンクションポイント法と同じ用語でも、説明が違います。この方がシステム屋にとっては分かりやすいと思うんだけどなあ。）

プログラム集合体

データ処理のためにフィルタリング処理を含むアルゴリズムを作り込んだもの。（いわゆるプログラム。JCLはフィルタリングがないので、外部入力ないし、外部メンテになる。）

外部入力

システムを起動する際の動作および起動設定。制御情報。（ＪＣＬ。運用管理ツール。）

外部インターフェースファイル

分析対象とするシステム（サブシステム）がシステム外部から取り込むReadOnlyのファイル。主にデータ。媒体は、問わない。（画面入力、ファイル入力、電文受信）データ形式も問わない（シーケンシャルファイル。ReadOnlyであればデータベースも。）

外部出力ファイル

分析対象とするシステム（サブシステム）がシステム外部にはき出すファイル。媒体は、問わない。（画面描画、ファイル出力、電文発信、計表）データ形式も問わない（シーケンシャルファイル。データベース。印刷。）

内部論理ファイル

システムで更新されるデータ集合体。（更新／削除の可能性があるデータベース。シーケンシャルファイルも削除／追加の機能があればここに入る。）

中間ファイル

プログラム集合体が分析対象システム内でデータ受渡し／内部処理のために使用するファイル。プログラムの内部テーブルを含む。

外部メンテ

システム構成要素の状態を変化させるユーティリティ。（ファイルのバックアップとか、データベースの再編成といったもの。）

ファンクションポイント法でいう「外部照会」はプログラムの機能となるため、不要となる。

　想定した用途は、大げさなプロジェクトを組成するまでもない、小さな案件。例えばEUC支援といったもの、をデザインするときに「どういうものがあるから、どこに気をつければよいか」を洗い出すのに使う道具、である。小さなシステムでは、上流がから下流へ段階的詳細化を経てシステムを構築して行くよりも、見取り図の雛形に具体的名称、ファイルや帳票の一覧を書き込みながらデザインして行く方が適している場合もあると考えたわけである。これも一種のストレスマトリックスかな？で、設計のガイドラインやチェックリストも、基本的構成要素が洗い出せれば、それに沿って作っていった方が役立ちやすいと、考えたわけだ。
　で、さらさらとガイドを書き込んでいったわけだが、、、

　自分では悪くないと思うんだけどな。最近気にしなくなりました。また何年後かに似たようなアイディアをどこかで知ることになるでしょう。（派手さはないので報道はされないな。）