本研究は、ソフトウエア開発の上流工程において、分析モデルの詳細化過程を支援することで、支援なしの場合に比較して、人間が行なうシステム分析時の見落としや正確性がどのようになるかを調査するものである。

　ソフトウエア開発の下流工程への支援ツールの適用研究や実現は盛んに行なわれてきた。上流工程への支援ツールの適用に関しては、研究段階のものが多く、特に概念モデルを表現する構造化分析などにおいては、分析過程自体を支援するものはほとんど見受けられない。

　概念モデルなどは、グラフによる意味表現に加え、それぞれのグラフアイテムをどのような機能を持つかを表現する手段として、"自然言語"を利用して表現するか、あるいは、形式的手法として、数学的な表記を用いた無矛盾な表現を行なうかの、2つの表現形態がとられる。

　自然言語を利用すると、一般に記述したり、理解したりするのは容易であるが、曖昧な解釈がされるという欠点が指摘されている。その反省から、形式的な記述が研究されてきているが、基本的な表現を数学基礎論にたよっているために、利用するには、特別な訓練を必要とし、実際の開発現場で利用することを考えると、一般に困難が予想される。

　分析過程を支援するための有効な手段として、過去に作成された事例の再利用がある。自然言語で書かれた過去の設計例に対して、事例をどのように見つけ出すかという問題と、どのように事例を修正するかという問題は大きな問題である。制限された述語を用いた記述や、形式的な記述でも、過去の事例をどのように表現し、どのように検索するかがおおきな問題となる。

　本研究では、実際の設計で利用される仕様は"自然言語"で書かれるもの、ということを前提として、事例の表現方法と、検索方法に関する検討を行なった。研究の対象とした概念モデルは、要求分析で利用されるデータフローダイアグラムである。データフローダイアグラムは、構造化分析[DeMarco86]で利用されるダイアグラムであり、段階的に詳細化を行なうことで、分析をすすめていくためのツールである。この構造化分析における段階的な詳細化の過程を支援する手法と、そのシステムSpecRefinerを構築した。段階的詳細化の過程の成果物を事例として将来の分析の際に再利用する。

　開発した手法では、ソフトウエア開発工程を、発見(finding)-修正(revising)-詳細化(refining)という3段階と考え、その各段階を支援することを目的としている。過去に分析された事例を発見し、その事例を修正し、さらに詳細化を継続する。また、設計理由の保持や設計履歴の参照機能で、非同期的な協調設計における支援を行なう。

　Visser[Visser90]は、設計の際の困難さについて研究をおこない、重要な知見を示した。一般に初期問題の仕様は、ゴールを定義するのには十分ではない。Stepwise definitionが重要である。実験によると、トップダウンによる詳細化が困難なこと、またその支援が重要であることが示された。開発した手法では、Visserの主張するトップダウンによる詳細化を支援する。

　ソフトウエア開発を支援するツールとして、各種のCASE(Compute-Aided Software Engineering)ツールが開発されている。従来型の手法では、構造化分析に、近年ではオブジェクト指向に対するツールが多く開発されている。これらの多くのツールは、主として作図支援や一貫性検査などの支援を行っているのがほとんどであり、仕様化の過程を直接支援するツールは無いと思われる[IPSJ92]。

　玉井[panel90]は、CASE環境シンポジウムにおいて、CASEツールの夢について、AIという切口からコメントしている。自分と共に成長するようなCASEツールがあって、終了したプロジェクトについて失敗事例と共に要領良く覚えておいてくれて、いろんな場面で関連する過去の経験を思い出してくれるものへの期待を述べている。

　再利用に関しては、コードレベルの再利用は盛んに研究されている。下流のプログラミングレベルで注目すべき研究として、河野[Koono97][Chen97]等の研究がある。河野等は、詳細化の過程自体に着目し、知識工学的な手法で、プログラミングの自動設計を行う。

　Maiden等は、アナロジーを用いた仕様の再利用のための認知科学的な研究を行なった[Maiden92]。Maiden等は、ある問題に対して、何も与えずに設計させるSEグループ、抽象的な仕様を与えたSEグループ、具体的な仕様を与えたSEグループを作り、その効果を測定した。抽象的な仕様は、新しい問題への類似性を理解する助けとはなるが、正確性という点では、具体的な仕様に劣る。具体的な仕様の再利用では、一度類似性が認識されると、抽象的な仕様を与えた場合よりも仕様の正確性が向上することが示された。ここから含意されるのは、類似仕様の検索により、具体的な仕様をすぐに参照できる機能がCASEツールに必要ということである。

　最近注目されているのが、溝口等によるオントロジーの研究[Mizoguchi93]である。オントロジー研究では、領域に依存しないレベルでオントロジーを整理し、SEとエンドユーザの間でオントロジーを用いたインタビューを行うことで、オントロジーと対応したビルディングブロックを利用した設計を行うことを可能とする。

　これとは逆に、領域に依存したツールを構成することにより、専門家が専門家自身でそのツールを利用して、その領域のアプリケーションを構成させることが容易になるという立場に立った研究に、Fischer[Fischer94]、中小路[Nakakoji93]のアプローチがある。

　提案する手法は、溝口等のオントロジーと、領域に依存する世界を対象としたFischer等の中間に位置づけられると考えている。領域独立のオントロジーや記号レベルの知識と、領域依存の知識をシームレスにつなぐことにより、領域依存の世界と実装レベルの世界を翻訳するSEの、認知的な負荷を大幅に減らすことが可能となる。結果として、分析時の見落としを減らし、分析時間を有効に利用できる。

　角[Sumi95]は、ソフトウエアの要求モデルを構築する際に、発想支援系を用いて、要求仕様の獲得支援を行なう。構造化分析におけるコンテクストダイアグラムの仕様獲得にあたる。したがって、提案する手法は、角の後工程を支援する系として位置付けられると考えられる。

　堀[Hori97]は、AIをシステム統合に役立たせるための方向を提案しており、システムの扱う問題のいろいろな視点からの把握、把握した問題を忘れない仕組み、新しい問題への過去の問題の適用、の3点の重要性について主張している。提案する手法では、特に後者2点について支援するものと考えている。

　Fischerは、知識ベースソフトウエア工学(knowledge-based software engineering)が、自動設計から人間の支援にその重点が移行しつつあると主張する[Fischer94]。提案する手法も自動設計ではなく、支援する立場を目指した。

　本研究では、構造化分析の段階的な詳細化過程を支援するSpecRefinerを利用して、2名の被験者で実際の教育ビジネスにおける管理業務の開発問題に適用した。実験は、

　1.支援なし1回目

　2.支援あり

　3.支援なし2回目

　の3回の実験を行なった。支援なし1回目と支援ありの実験は、当日かあるいは数日程度の空きで実施した。支援ありの実験と支援なし2回目の実験は、半年の空きで実施した。支援なし1回目と支援ありを比較すると、支援ありの場合には、概念モデルの見落としが減ることが観測された。支援なし2回目と支援ありを比較すると、同様な傾向が得られたが、支援なし2回目の分析解は、分析の質の点で問題があることが観測された。すなわち、機能レベルでの記述を要求されているにもかかわらず、処理記述になってしまっているなどの欠点が現れている。処理記述の問題点は、記述内容が抽象的過ぎて、再利用に不向きな点である。

　実験の結果、詳細化過程の支援の必要性と重要性、さらにシソーラスを構成する必要性、分析の質を処理記述レベルから機能記述レベルにする支援を行なう重要性が明らかになった。実験後、支援系に対して、これらの改良を加えている。

　本論では、ソフトウエア上流工程の詳細化過程の支援の重要性と、それを支援する支援系SpecRefinerの概要、支援系を用いた実験と実験結果について考察した結果を論ずる。

　本論文は、「ソフトウェア開発上流行程における詳細化過程の支援に関する研究-構造化分析を中心として-」と題し、9章からなる。

　ソフトウェアの開発は、その大部分が人手でおこなわれているため、その効率化が重要な課題となっている。従来、ソフトウェア開発下流工程のプログラムのコーディングの段階においては、CASE(Computer Aided Software Engineering)ツールと呼ばれる支援システムをはじめとして、さまざまな研究がなされてきた。しかし、ソフトウェア開発の上流工程においては、その効率化のためのいくつかの思想が提案されるにとどまり、具体的な支援システムの研究は、十分に進んでいなかった。本論文は、ソフトウェア開発の上流工程においてソフトウェアの仕様を詳細化する過程を支援するためのシステムを提案し、その有効性を実験により確認した結果を述べたものである。

　第1章は序論であり、研究の目的、研究の背景と位置づけ、および論文の構成について述べている。

　第2章では、ソフトウェアの開発を支援するための手法について、上流工程から下流工程までの従来の研究を概観し、その限界を指摘している。特に、上流工程において有効な支援システムが存在していないことをとりあげ、発想支援系と知識処理系を結合したシステムにより従来不可能だった支援が可能であるとする本論文の基本的な考え方が示される。

　第3章では、ソフトウェアの開発上流工程において、仕様の詳細化を支援するSpecRefinerと称するシステムを、提案している。従来、たとえ経験豊かなSE(Software Engineer)であっても、顧客の要求仕様を思い違えたり、仕様に盛り込むべき機能を考え忘れたり、ソフトウェア要素間の関係を勘違いしたり、というミスが避けられないことが知られていた。これに対して、本論文で提案するシステムでは、過去の仕様の例を自然言語およびソフトウェアの構造を媒介として検索・再利用することにより、それらのミスを減らすことを提案している。過去の仕様の例を有効に活用するための、発見、修正、詳細化の過程を定義し、それぞれについてシステムによる支援の方法を提案している。

　第4章では、ソフトウェアの扱う問題について類似した事例が存在する場合について行なった実験のセッティングを詳述している。実験で確認するシステムの効果として、仕様に盛り込むべき機能の見落としの低減の効果と仕様分析時間の短縮の効果を想定して、その効果を測定するための実験方法が示されている。

　第5章では、前章で提案した方法に従って実験を行なった結果を示し、システムの効果を詳細に検討している。システムによる支援がない場合に比べて、仕様の考え落しが減ることなどが、システムの支援の内容との関連を示しながら、実証されている。

　第6章では、システムの拡張について述べている。前章まででは、比較的近い領域の仕様の前例の再利用を検討してきたが、近い領域の前例がない場合についても支援を可能にするために、仕様記述に用いられる述語のシソーラスを構築することを提案し、実装している。

　第7章では、前章で提案したシステムの拡張の効果を確かめるための実験の設定を与えている。「大学の講座申し込み」「劇場の座席予約」「レンタカーの貸し出し」という3つの例題について、システムの仕様を記述する実験を行なうことを検討している。

　第8章では、前章で提案した実験を行なった結果を詳細に述べている。先行研究に比べて、本論文で提案したシステムが仕様記述の支援を効果的に行なえることを、さまざまな観点から実証している。

　第9章は、結論であり、本研究の成果をまとめ、今後の課題を述べている。

　以上を要するに、本論文は、ソフトウェア開発の上流工程において仕様記述を支援するための新しい方式を提案し、実験によりその有用性を実証したものであり、工学上、寄与するところが大きい。

　よって、本論文は博士(工学)の学位請求論文として合格と認められる。