top / index / prev / next / target / source

2005-12-21 diary: blanco Frameworkの次期ロードマップ：単体試験工程の自動化

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

blanco Frameworkの次期ロードマップ：単体試験工程の自動化

blanco Frameworkの次期ロードマップを立案作業中です。先月から上司の方々や blanco Frameworkの総会メンバー達と相談しているのですが、次期ロードマップは「単体試験工程の自動化」というものをメインテーマとして据える案に落ち着きそうです。まだ完全に決定ではありませんが、おおむねその方向性にあります。

blanco Frameworkの次期ロードマップ：単体試験工程の自動化

blanco Frameworkの次期ロードマップを立案作業中です。先月から上司の方々や blanco Frameworkの総会メンバー達と相談しているのですが、次期ロードマップは「単体試験工程の自動化」というものをメインテーマとして据える案に落ち着きそうです。まだ完全に決定ではありませんが、おおむねその方向性にあります。

2006年3月末を目標に実現していきたいと考えているのは下記のような仕様です。

ポイントは 自動生成されたソースコードの品質検証および品質担保のために、JUnitソースコードを同時に自動生成して これを用いるという点です。自動生成されたソースコードに着眼しているのです。blancoプロジェクトのツールそのものの品質向上ももちろん大切なのですが、生成後のソースコードに対する試験およびドキュメンテーションまでを自動化することにより、試験工程の爆発的な改善を行うことが出来るであろうから、そちらの優先度を高く設定しているのです。

これ以外にも 単体試験工程の生産性向上のために、下記のようなものを考えています。しかしこれは2006年3月末までには作業が納まらないものと考えます。

blanco Frameworkの効能によって製造工程の生産性・品質は向上しました。そうすると今度は単体試験工程の生産性・品質が目立ってきて、それでは単体試験工程の生産性・品質の向上へと取り組もうという狙いです。ここを自動化できれば、トータルとしての生産性・品質が劇的に向上するものと考えます。これが可能なのは、blanco Frameworkが原則として ドキュメントをメタファイルとして利用しているからだと考えています。なお、ドキュメントの自動生成には blancoReportの次期版を採用する予定です。blancoReport次期版の存在によって、私の選択肢が大きく広がっていることをひしひしと感じます。

この件について 上司の同意を取り付けるとともに blanco Framework総会にかけて議論していく予定です。とはいえ もう今年も残りあとわずかなので、はやいとこ進めなくてはなりません。事前に簡単にヒアリングしたところでは、総会メンバーの方々はこのロードマップについて おおむね了承してくださっている模様です。

ちなみに… 2006年3月末をマイルストーンに設定しているのは、開発規模とか工数といったものを適切な手法によって見積もった結果として得られた日付設定ではありません。某プロジェクトの製造開始までに何とか間に合わせたいという私自身の (そしておそらくプロジェクト進捗上の) 希望納期です。試験工程を自動化しないと とっても悲惨なことが起こるということがハッキリと認識されはじめてたのです。純粋に必死です。ふむ、、、もし これだけのスペックを 2006年3月末までにやり遂げるといった結果を出すことができたら、そうしたら私は私を褒めてあげたいです (苦笑)

関連する日記

blanco Frameworkは 当面の間 現状のような 非テンプレート型によるソースコード自動生成の仕様に落ち着く模様

blanco Frameworkは当面の間、現状のような 非テンプレート型によるソースコード自動生成タイプの仕様に落ち着く模様です。というのも blanco Frameworkの次のロードマップが単体試験工程の自動化に落ち着きそうだからです。非テンプレート型のソースコード自動生成と 単体試験工程の自動化との間には、意外にも密な相関関係があるからなのです。テンプレート型を採用した事による自由度が、試験ソースコードの自動化と相反すると考えています。また、遠い未来にでも blanco Frameworkの各プロダクトを多言語対応させたいというのも 非テンプレート型によるソースコード自動生成を利用し続ける理由のひとつです。

、、、しかし何といっても 私がテンプレート型の処理全般をニガテとしているいうのも大きな理由なのでしょうね。そして本当の理由は やっぱりこれだったりするのかもしれません… (苦笑) ニガテかどうかはさておき、現状ではテンプレート型ソースコード自動生成に取り組むよりは、むしろ blancoResourceBundleやblancoCsvを利用してカスタマイズ性の提供に努めるほうが、メサキの製造スピードの維持という見方からは適しているという、純粋な作業工程効率化という意味合いや狙いが大きいようにも思います。

この日記について