« 危ういデータモデルを見破るコツ | トップページ | ブラウザアプリと3階層型デスクトップアプリ »

2012.03.30

成果物のサイズとシステムの保守性

 「CONCEPTWARE/販売管理」として公開している卸売業向け販売管理システムの基本設計情報ファイル(SalesOrosi.xead)のサイズは、1.8MBである。

 システムの規模感としては、テーブル定義が68個、機能定義が280個、業務定義が60個。これは小~中規模の業務システムに相当するが、機能設計書、DB設計書、ER図、業務マニュアル、データフロー図までを含めてのサイズなので、かなり小さい。それは、基本設計書を書くための専用エディタ(XEAD Modeler)を使って書いたからだ。EXCEL方眼紙あたりを使えば50MBは下らないだろう。

 そして、この基本設計書に沿って作られた詳細設計書(SalesOrosi.xeaf)のサイズは1.5MBである。その実体はXMLセグメントとJavaScriptコードがまとまったテキストファイルなのだが、この小ささで済んでいるのも、詳細設計書(仕様書)を書くための専用エディタ(XEAD Editor)で作ったからだ。EXCEL方眼紙で書けば、やはり50MBは下らないだろう。

成果物   成果物のサイズ 専用エディタを使わない場合
基本設計書    1.8MB      50MB
詳細設計書    1.5MB      50MB
-------------------------------------------------------
合計         3.3MB     100MB

 専用エディタであるゆえに作成が容易だし、ドキュメントのサイズも小さく済む。もっと顕著な効果は、専用エディタで書かれた詳細設計書は、専用の翻訳ソフトによって実行可能な仕様情報となる点だ(そうでないとしたら専用エディタであることの意義は小さい)。つまり、1.5MBは正確には「詳細設計書のサイズ」ではなく「詳細設計書とコードと実行モジュールの合計サイズ」なのである。

 詳細設計書のサイズを無視して、この程度の規模のシステムが1.5MB程度のコードと実行モジュールで動いていること自体は特段変わったことではない。Javaで手作りすれば、コード(.java等のテキストデータ)のサイズは1MBくらいにはなっただろうし、実行モジュール(.class等)も1MBくらいにはなっただろう(フレームワークのサイズは勘定外)。専用エディタを使うことによって、「コードと実行モジュールが要らなくなった」とも解釈できるし、「詳細設計書の中にコードと実行モジュールが吸収された」とも解釈できる。

成果物   成果物のサイズ 専用エディタを使わない場合
基本設計書    1.8MB      50MB
詳細設計書    1.5MB      50MB
コード          0MB       1MB
実行モジュール    0MB       1MB
-------------------------------------------------------
合計         3.3MB     102MB

 いずれにせよ、基本設計書と詳細設計書とコードの合計サイズが30分の1になったということではある。システムの保守性を考えた場合、その意義は大きい。これらはまさに保守フェーズで維持されてゆく要素だからだ。プレーンテキストのデータサイズとして比較すれば、保守対象のサイズが小さければ小さいほど保守性が良いとは言えるだろう。

 しかし、サイズの比率だけから「保守性が30倍良くなった」と主張するのは間違いだ。じっさい、基本設計書や詳細設計書を用意せずに、コードだけを保守対象とすればさらに保守対象のサイズが小さくなる。それでさらに保守性が向上するとは言えない。

 なぜか。業務システムのような「担当者が交代しながら長期間保守されてゆくソフトウエア」には、データモデルや業務マニュアルを含めた基本設計書や詳細設計書が必要だからだ。それらの資料は保守担当者が「設計者」として職責を果たすために必要なもので、それらが維持されていないばかりに保守しづらくなっているシステムがたくさんある。「アジャイル」はその傾向に拍車をかけていないだろうか。

 システムの保守性の鍵は「可読性(読みやすさ)」だ。システムやドキュメントのサイズが大きかろうが小さかろうが、仕様がわかりやすく編集しやすければ保守性は高い。同時に、仕様要素が雑多な形式をとりながら寄せ集まっているのでなく、単一のツールで読み取れるように凝集している点も重要である。読み取るためにいろいろなツールやプラグインが要るというのではやりにくいからだ。つまり、可読性が同等なら、読解されるべき諸要素がコンパクトにまとまっているほうが保守性が高い。

 今回、販売管理システムに「セット商品」に関する仕様を組み込んだのだが、基本設計の検討・修正で延べ3日、詳細設計(実行可能な仕様書)の作成・テストで延べ5日といったところだった。これは、実装者が設計者でもあったことの効果でもあるのだが、保守フェーズでこの生産性を維持するためにも、基本設計書と詳細設計書は必須である。システム開発プロジェクトのほんとうの品質や生産性は保守フェーズで現れる。

 そしてそれゆえにこそ、「基本設計情報とこれにもとづく実システムのライブラリ」が充実しなければならない。スクラッチ開発よりも、それらを叩き台とするカスタマイズ開発のほうが容易なことは論をまたない。次はいよいよ「CONCEPTWARE/生産管理」の実装に取り掛かる。世界初の「実行可能な仕様書で出来ている生産管理システム」の登場だ。

このブログでの関連記事:
キレイなコードでも仕様書の代わりにはならない

|

« 危ういデータモデルを見破るコツ | トップページ | ブラウザアプリと3階層型デスクトップアプリ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 成果物のサイズとシステムの保守性:

« 危ういデータモデルを見破るコツ | トップページ | ブラウザアプリと3階層型デスクトップアプリ »