その3はコチラです。
2日目、後半のセッションです。
先進技術の適用
このテーマは、現場の工夫による改善というよりは、大きな一歩を踏み出してみた感のある内容。実験のコストもかかっているだろうなあという内容で、聞く方にとってもありがたい知見です。
このシンポジウムでは、将来きっと役に立つであろうという評価を受けた発表に対して「SQiP Future Award 」が授与されます。わたしはこの「先進技術の適用」スロットの3つ目の、大野さんの発表に投票しました。
このシンポジウムでは、将来きっと役に立つであろうという評価を受けた発表に対して「SQiP Future Award 」が授与されます。わたしはこの「先進技術の適用」スロットの3つ目の、大野さんの発表に投票しました。
B4-1:Webアプリケーション開発における画面仕様書およびテスト仕様書の自動生成手法と開発プロセス改善の提案
早稲田大学の坂本さんの発表です。若さに嫉妬!
端的に言うと、画面モックをマスターとして、画面仕様書とテスト仕様書はそこから抽出しては?という内容です。モックもプロトタイプも、上流工程でお客様との意識合わせをするためなどに使われますが、そのまま作り込みを進めて最終製品になるプロトタイプと違って、モックは使い捨てという位置づけにあります。
端的に言うと、画面モックをマスターとして、画面仕様書とテスト仕様書はそこから抽出しては?という内容です。モックもプロトタイプも、上流工程でお客様との意識合わせをするためなどに使われますが、そのまま作り込みを進めて最終製品になるプロトタイプと違って、モックは使い捨てという位置づけにあります。
このモックを、書き殴りでなく、一定の記法に基づいて記述することで、画面上の各コンポーネントのGUI的な属性、値の制約をソースから抽出することができます。そこからさらに画面仕様書・テスト仕様書も、機械的に生成できる、というアイデアです。
会場からは、「画面仕様書の方をマスタとして、そこから画面やテスト仕様書を生成する方が一般的と思うが、何故モックから生成しようと考えたのか」という質問がありました。わたしも同じ疑問があり、モックと、本来の製品を両方メンテナンスし続けるという運用は難しいと思います。仕様変更のたびに画面ベースでお客様と意識合わせをするので、まず画面から手を入れるんです、というところであれば、可能かも知れません。
わたしからも「画面上の複数の項目が依存関係にある場合をカバーできるか」という質問をしました。たとえばアンケートで「その他」を選ぶと、「理由」欄に何か書け、というようなケースですが、その部分はまだ未検討とのこと。選択肢の内容自体をDBから引いてくるような設計もあるでしょうから、チェックの対象は、クライアント側でチェック処理を実装するような範囲になるかと思います。
今後の研究に期待ですね。
今後の研究に期待ですね。
B4-2:WebシステムにおけるVDM++による設計血管除去効果について
株式会社 NTTデータの田端さんの発表です。
仕様書の曖昧さを排除するために、自然言語ではなく形式手法で記述しようという試みは増えてきているようです。ただ、新しい記法で最初からすべてを書くというのは、どうしても敷居が高い。
この発表では、まずは設計チームが自然言語で外部仕様書を書く。それを専門部隊が、形式仕様記述言語「VDM++」で記述しなおして、欠陥を摘出するという流れになっています。
この発表では、まずは設計チームが自然言語で外部仕様書を書く。それを専門部隊が、形式仕様記述言語「VDM++」で記述しなおして、欠陥を摘出するという流れになっています。
このプロセスで欠陥の除去が期待できるタイミングは以下の3つ。
|
このうち、費用対効果が高いのは、2つ目まで行った場合とのこと。3つ目は完全に、いわゆる「テスト」なので、作るべきものがまたたくさん増えていくんでしょうね。また、形式手法の熟練者であればある程度、記述しながら実際の動作を想定することで欠陥をある程度、先出しできるようです。
B4-3:テキストマイニングを活用したSWプロジェクトの品質管理事例
バグ票の分析に興味のある人にはぜひ、公開されるであろう資料を読んでほしい。NECカシオモバイルコミュニケーションズ 株式会社の大野さんの発表です。
バグ票で利用しやすいのは、たとえば「欠陥の摘出工程」「重要度」のように、分類が用意されていて、それを選択するもの。件数や、全体からの比率など簡単にわかります(正しく分類されていればね・・・)。
一方でなかなか活かせないのが、「現象」「原因」など、各担当者が自由記述で書くところ。本当に大事なことは、こっちに書いてあったりもします。
一方でなかなか活かせないのが、「現象」「原因」など、各担当者が自由記述で書くところ。本当に大事なことは、こっちに書いてあったりもします。
この発表は、テキストマイニングにより自由記述部分を分析し、抽出した単語とその関係から、欠陥の傾向やプログラムの弱点を見出そうというものです。わたしはテキストマイニングの手順について詳しくないのですが、単純に単語を拾うだけではなく、同義語や関係性を定義したり、その関係性をネットワークグラフにしたり、色んなことができると知りました。
この技術を使って、単語の発生頻度の時系列変化から、個々の機能に閉じない全体的な欠陥の収束状況を把握することができるとしています。また、バグ票の他の要素を組み合わせての分析も可能と。
この技術を使って、単語の発生頻度の時系列変化から、個々の機能に閉じない全体的な欠陥の収束状況を把握することができるとしています。また、バグ票の他の要素を組み合わせての分析も可能と。
わたしはこの発表がとても好きで、このような技術が浸透すれば、バグ票の立場が大きく向上するのでは、と期待しています。自由記述が有効に活かされると明らかになれば、書く方もそれを意識するようになるのではないでしょうか。
ちなみにわたしは、バグ票に「タグ」という欄を設けて、似たようなことを手動で行うこともあります。このタグとは、ブログ記事についていたりするものと同じです。1つのバグ票の特徴を表す単語を最大3つくらい書いておく。ここでいう「特徴」は、起こった事象についてでもいいし、その原因でもいい。
これをすべてのバグ票を通して眺めてみて、類似単語を整理したうえで、傾向を見出すということです。この人力データマイニング、異様に泥臭いのですが、品質向上の観点としてけっこう役に立つものです。ただし、疲れる。本当に気合いが必要。
これをすべてのバグ票を通して眺めてみて、類似単語を整理したうえで、傾向を見出すということです。この人力データマイニング、異様に泥臭いのですが、品質向上の観点としてけっこう役に立つものです。ただし、疲れる。本当に気合いが必要。
その5はコチラです。