イベント / EVENT
平成23年度 第8回 Q&A
第8回 2012年2月15日(水)
作るのは簡単、検査が難しい、そのわけは?
ソフトウェアの品質保証
中島 震(国立情報学研究所 情報社会相関研究系 教授)
講演当日に頂いたご質問への回答(全26件)
※回答が可能な質問のみ掲載しています。
プログラム作成は人に依存しています。ルールや規約を作っても作成者の意識にゆだねられてしまいます。どうすれば人に依存しないプログラム開発ができるのでしょうか? 何か良い方法がありましたら教えてください。チェックしていくしかないのでしょうか?
極端な話ですが、きちんとプログラム開発ができる人だけに、開発をお願いするというのが良い方法といわれています。
V型モデルの開発プロセスでも、「想定外」の事象(ご講義では障害(3)のようなケース)に対するテストをいかに行うかが課題のように思います。この「想定外」に対するロバスト性をいかにして担保するか何か良い方法はありませんか。(例えば最近のdocomoやauの障害のケース: これはソフトウェア単体でなく、ネットワークやサーバの構成の問題もあるでしょうが、spec(仕様書)に書かれているtraffic以上の負荷を与えてテストしたとしても障害が発生しています。つまりテストする際の想定負荷は設計負荷の何倍もの負荷(つまり想定外)を与える必要があると思います。)
「想定外」と言われているものがあるとき、それを「想定外」としないような工夫や考慮が、開発時になされている必要があります。ご質問にあるような、性能上の想定外については、現状でも、運用中に監視していると思います。だからこそ、原因がわかって、「サーバを増強しよう」という対策がとれるのだと思います。
論理的な不具合は検査で発見可能ですが、タイミングクリティカルな事象での不具合は現象を再現させることが困難。再現する方法が発見できればバグ修復は可能ですが、そう再現させたら良いのでしょうか? このようなバグの検出方法は?
再現性の低い不具合は発見が困難なことからもわかるように、事後検査では対応することが難しいです。上流工程から開発を着実に進めていく必要があります。「設計検証」のような方法があります。
今回の「品質保証」とは異なりますが、「システム監査」という資格も存在します。「システム監査学会」等との連携は考えられませんか? この「システム監査」は経営のチェックの視点からのものですが、したがって誤りの発見が目的ではないのですが。
システム監査については詳しくはありません。経営の視点からのチェックも大切なことかと思います。
行政機関におけるシステムを導入した場合、導入検査はどの程度行うべきか。検査は第三機関に委託すべきか。委託する場合、どのような機関が想定されるのでしょうか? また、開発業者の完成検査基準は誰がどのように作るのでしょうか。その基準をオープンにすることは可能でしょうか?
最近では、一般に、第三機関がシステムの確認を行うことの重要l性が認識されています。その際、検査のよりどころとなる文書、設計書、仕様書などが客観的に、系統的に、誤りなく書かれている必要があります。今回のお話「検査が難しい」は依然として残る問題と思います。
ソフトウェアの開発者とテストする人は別にすべきと考えますがいかがでしょうか? ソフトウェアのプログラムに不具合が発生した時に自律的な回復機能が必要だと思いますがどうでしょうか?
開発とテストの部門を分ける方法は、以前から、行われています。
自律的な回復機能があれば大変役に立ちます。ソフトウェア工学の分野で重要な研究テーマになっています。
組み合わせるハードウェアにより不具合が発生することがあります。しかも、ソフトウェア開発後にリリースされたハードウェアに対しても動作を保証することは可能でしょうか? 可能でないとするとどうしているのでしょうか? またハード故障によりソフト不具合が誘発されることがありますが、これらの検証(検査)はどのように行われているのでしょうか?
動作保障は困難と思います。現状できることは、ソフトウェア開発側で使用される状況でのテストを継続的に行うことだけです。プログラム開発時の工夫としては、可搬性という観点からの信頼性向上を実施するという方法があります。
図1でウォーターフォール型での検査を説明されていましたが、スパイラル型やアジャイル型では検査はどうなるのでしょうか?
スパイラルやアジャイルという開発の方法は、単体テストに相当する試験を行いながら、プログラムを作成するというアプローチかと思います。一般に、「global design,incremental building」といいますが、プログラム作成に先立って、大局的な観点からの設計(上流工程になります)が必要です。実施したい検査の視点に応じて、適切な方法を採用する必要があります。
ソフトウェアの品質保障について、その考え方としては、昔(例えば20年前等)と比較してどのような点で大きな進歩をしましたか? その進歩した成果は実際の開発現場に対して確実にフィードバックされるようにどのような工夫がなされたのでしょうか?
プログラムのテストについて、調べた範囲を議論するテスト網羅率の考え方が一般的に用いられるようになってきたことかと思います。もうひとつは、部品化や共通化によって、「おそらく不具合がないであろうと信じるソフトウェア」を使えるようになってきたことでしょうか。
結論としては既存の手法では解決は困難ということでしょうか? 根本的解決となるようなキーワードや現存の取り組みについてのお話を伺いたいです。
原理的な困難がありますので、その範囲の中で、品質向上の技術が研究されています。形式手法という呼ばれる技術が興味深いと思います。
(1)作れば作るほど不具合が多くなる→作らない工夫が必要ではないか?(部品化など)
(2)検査で不具合をたたき出すには限界がある→作る工夫が必要ではないか(訓練など)
(1)作らない工夫は良いアプローチですが、それでは、新しい要求などにこたえることができないので、やぱり作る必要があります。
(2)作る工夫として、検査しながら作るという方法が良いかと思います。
ソフトウェアのバグはソフトウェアの修正とともに、使う人が運用においても修正するというのが望ましいという認識でよろしいでしょうか?
運用する人が気を付けて使うという意味でしょうか?大型コンピュータの時代は、専任のオペレータがいて、運用の教育訓練をうけていました。最近は、ソフトウェアがどこにあるかわからないほど一般化して浸透しています。専任オペレータだけが使う状況ではないことが、問題を難しくしているように思います。
品質改善の為の具体的な手法が知りたいです。
多くの手法が提案されているかと思います。もっとも大切なことはご自身の開発組織あるいは開発プロジェクトに合った方法を採用するということです。万能の解決策をみつけることは難しいかと思います。
形式手法を使えばバグの発生を少なくすることができると聞いていますが、真偽のほどは?
どのように形式手法を使うか、という適用の方法が大切です。適切に使えばバグの発生を少なくできた、という報告はたくさんあります。
6つの話題の3番目「ソフトウェアは変化しなければならない」といいますが、どうしても改良したくなった時に抜けのないような完璧な設計が期待できないのでしょうか? これなら絶対大丈夫という設計が不可能ならリスク発生を恐れ、システムをいじらせないようにすべきでないでしょうか?
大規模システムであればあるほど、長期間の運用ではじめて、開発コストを回収できるようになりますので、「進化」は必然なことです。
(1)根拠のない信頼感を抱かない事→ソフトウェアを販売する側である場合、ユーザー側にこの認識を持って頂くことは難しいのでは?
(2)また、ソフトウェアを複雑化させないようにすることは可能ですか?
(3)被害を最小限にする方法はありますか?
(1)情報処理学会からの言葉を引用しましたが、それは、「IT系に対する一般的なリテラシ」として、理解しなければならないこと、という話かと思います。
(2)最初はきれいに作っていても、進化の過程で複雑化するという話はよくあります。進化の技術が未熟なためかと思います。
(3)「被害」を何と定義するかに依存するかと思います。
ソフトウェアの品質保証が完全でないことはよく分かりましたが、あらゆる製品(人工物も天然物も)についても同じことが言えるのではないでしょうか?
同じように考えます。しかし、ソフトウェアの場合は、そのような問題点が起きやすいことにあります。
ネットワーク経由でどんどん改良されるソフトウェア(windows etc.)は本当に信頼できるのでしょうか?
提供者を信頼することになります。
要求仕様(システム設計)でヌケがないようにする具体的な方法はありますか?
要求工学という研究分野で盛んに研究されています。100%という方法はないようです。
(1)「バグを無くす(0%にする)」のはコストが高いので、「致命的なバグを無くす」事を目指して、そこにかけるコストは惜しまないというアプローチが現実的と思いました。その観点での研究はされていますでしょうか?
(2)建築の構築の安全性と比べてソフトウェア開発が洗練されていないのはなぜでしょうか?
(1)信頼性向上の研究は、そのような観点から進められています。
(2)ソフトウェアが目に見えないことが理由かと思います。複雑化していることに気付かないのではないでしょうか。
結局、バグのないソフトウェアを作ることは不可能なのでしょうか?不具合を起こさない為にはどうすれば良いのでしょうか?
実用的な規模のシステムであれば、不可能に近いと思います。不具合を論じるときには、必ず、正しさの基準が何であるかを考える必要があります。このような基準を明確に、さらに、客観的に判断できる形で表現できれば、問題は少なくなると思います。
(1)受手(利用者)と送手(開発者)とのコミュニケーション不足と何を求めているかという相互理解があればバグ(不具合)は想定されうるのではないしょうか?
(2)また精度あるいは保証付きプログラム設計(要求を含め)を考えることが逐次行われていれば、予想されうるのではないでしょうか?
(3)プログラム(システムを含め)内容を理解しないで開発しているし、利用者も業務を知らないで業務作業をしていることが問題ではないでしょうか?
(4)市民と政府との関係と同じなのでは?
(1)相互理解が大切なことはその通りです。どのようにすれば、相互理解ができるか、が問題になっています。
(2)大変興味深い研究テーマになるかと思います。
(3)その通りかと思います。ご質問の(1)と関係します。
プログラム言語設計時に検査しやすいようにするとか、エディターもテストしやすいようにはできないのでしょうか? コーディング起因のバグのお話をされましたが、実はOSやフォームウェア起因で、その場合は理論的に検査できないと思うのですが。
プログラミング言語の研究、開発支援ツールの研究、など、長い歴史があり、すこしずつ改善していると思います。開発対象プログラムの動作環境に起因する不具合は、もっとも難しいもののひとつです。
1000行に1つ含まれるバグは受入検査後のソフトウェアに、1000行に1つ含まれるという事でしょうか? V字と1000行に1つのバグ(統計値)の関係を知りたいです。
通常は、単体テストでの不具合発生率のことです。
不具合を見つける為にもテストは必要だと思いますが、もっと上流工程で問題を見つけられる方法はないでしょうか?
開発上流工程から、厳格に設計を進めるという方法があります。形式手法と呼ばれる技術です。
(1)不具合の評価手法が体系化されているのでしょうか?
(2)分類や深刻度の指標があるのでしょうか?
(3)不具合自体のレベルと影響度が分離して観測されているのでしょうか?
ご質問にあるような尺度(メトリックス)を整理するアプローチは非常に大切なことかと思います。
バグの少ないソフト開発は決められたことをきちんとやる事、とすると日本人に向いていると思います。日本人の開発は品質が良いのですか?
講演で話題にした不具合は、すべて、日本で開発されたソフトウェアかと思います。
コストを下げる為に用いられる手法であるモジュール化(パーツ化)という手法は統合後という意味合いではテストの「複雑さ」を招くのでしょうか?
複雑さをまねくことがあります。21番のご質問と関係しますが、
中身のわからないモジュールが関わるシステムで生じる不具合は発見が難しいです。