2016年04月27日

バージョンについて


初めての方はこちらを「はじめに

型通りの手順でこなしていると深く考えないので応用問題にあたった時に酷いミスに繋がる事があります。
プログラムが持つバージョンはそんな扱いになっているように思えます。

バージョンとは


そもそもバージョンとは一体何でしょう?
辞書にはこんな風に載っています。
説明、解釈、意見、異説、改作、脚色、翻案、…版、異形、変形
日本語で言うと「版」というのが近いようです。例えば「広辞苑 第五版」などの様に。
それではこの「版」というのは何なのでしょう?
何のために必要なのでしょうか?
これは考えるまでも無いですが、もし「版」が無かったら「広辞苑 第五版」も「広辞苑 第六版」同じ「広辞苑」になってしまいます。つまり版というのは同じ名称なのに内容が違う物を区別する為の識別子だという事が言えます。確かに「版」の他の例として、小説を原作とした「ドラマ版」とか「劇場版」とか言ったりもします。この用例でもバージョンに置き換えても問題無いようです。

ソフトウェアの場合でも上の様な用例も含めた広い意味で使われると思いますが、やはり一番メインで使われるのは第一版、第二版と同様に世代の区別という事になるでしょう。世代の区別というのは言うなれば時間的な識別であって、名称を空間的な識別と考えれば、両者をもって時空間で一意に識別するものだとも言えます。従って世代等は無いものに対する名前と同様に時系列で変化するものの場合は「名称+バージョン」が名前と言えます。

どの単位で設定するか


ではバージョンはどの様に設定すれば良いのでしょうか?
まず対象としては世代が発生するものは全て必要なのでソフトウェアの場合はおよそ全ての要素が対象なのではないでしょうか。細かく設定すれば勿論抜けは無いので良いのでしょうけど、それではパワーがかかってしまうのでなるべく少なくしたいところです。そう考えると最低限という意味では外部へ出すタイミングが常に一緒のものは一つのバージョンで管理しても良いと思われます。正式に出荷する以外にもトラブル時にパッチとしてライブラリー等を提供する事を考えると、結局ライブラリー程度の単位ではバージョンを設定しなければならないと思われます。
ここで外部と表現したのはブログラムを組み上げる開発組織から外という意味で、開発中における社内の営業や委託先など全ての場所を含めているからです。バージョンは名前ですから名無しのまま外に出すという事は考えられません。

トレーサビリティ


バージョンの利用の仕方の大きなものの一つはトレーサビリティでしょう。
今時はスーパーで買う牛肉にも識別情報が付いていてトレーサビリティという事は身近になりました。ソフトウェアの場合は牛肉が問題を起こすより圧倒的に頻繁に問題を起こすのでトレーサビリティというのは非常に重要です。牛肉の識別情報にあたるのがバージョンという事になります。

トレーサビリティというのは簡単に言えばその生い立ちを明らかにするという事になります。
つまり「どこそこの畜産農家から出荷されて、どこそこの加工業者で加工されて、○○スーバーに卸された」という事が明らかで辿れるという事です。これにより問題の箇所が速やかに特定されて被害を少なく抑えて原因の究明が容易になります。
ソフトウェアの場合も全く同じなので、ユーザー先で発生した問題に対して確認したバージョンからその生い立ちが全て明らかになる必要があります。その為には一つには内部的にしろ少しでも変わったら確実にバージョンが上がる必要があります。さもないと一意に識別できなくなってしまいます。もう一つはソフトウェアにはライブラリーやスペックファイル等様々な構成要素が存在しますがそれら全てが正しく一意に特定できなければなりません。という事は出荷するその製品のそれら全てのバージョンが把握されている必要があります。

互換性チェック


バージョンのもう一つの大きな使い方は互換性のチェックでしょう。
バージョンが時系列の前後を表しているという事を生かして、ソフトウェアの構成要素の随所で発生する組み合わせに対してバージョンをやりとりして互換性があるかどうかを簡単に確認できます。例えばワープロは文書のバージョンをチェックして自分が扱えるかどうかを判断します。この場合一つ注意しなければならないのはバージョンのフォーマットは変えられなくなるという事です。途中でフォーマットを変えてしまうとその前後の組み合わせでやりとりしようとしてもエラーになってしまいます。バージョンのチェックはどういう単位で行うべきかと考えると、先に検討した単位の通りにバージョンを付けるならば、バージョンを持つ者同士は常に世代がずれる可能性があるのでチェックすべきだと思います。

ところで、バージョンはフィールドで区切って意味を持たせる事も可能です。
例えば「1.2.5」の様に三フィールドにして、一フィールド目は全体の変更、二フィールド目は機能を追加した場合、三フィールド目は問題点を対応した場合、の様な使い方もできます。これを応用してより細かい互換性の情報を載せる事もできます。例えば一フィールド目は互換性が無くなった場合、二フィールド目は新しい部分があるが扱うのは可能な場合、三フィールド目は完全に互換性が有る場合、などです。適切に設計すれば内部処理としては簡単に扱える様になるので便利ですが、バージョンは所詮時系列に対する識別子に過ぎないので本格的に情報のやりとりをするならば別途やりとりをするべきでしょう。

外部向けと内部向け


ユーザーにとっては何も変化が無いのに作り手の事情で中身が微妙に変わってしまう場合もあります。その場合バージョンはどうすればいいのでしょうか?
トレーサビリティの観点からは少しでも変わっていれば当然バージョンは上げなければなりません。しかしユーザーにとっては何も意味が無い...
この様な事情を考えると結局外向けのバージョンと内部的なバージョンの二つが必要になると思われます。実はこれは一般的な製品では普通に行われている事だと思われます。テレビ等家電製品は初出荷後も内部的な改善を行っている場合があります。しかしだからといって製品名がバージョンアップする訳ではなくユーザーは普通はその差を知る事はできません。そこは「製造番号」という言うなれば内部的なバージョンによってのみ識別する事ができます。

一覧


メニュー


記事を広める



品質の最新記事


posted by 善 at 22:05 | Comment(0) | TrackBack(0) | 品質 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック