SIG
先号   次号

「SWEBOKガイドを読む」

塚原情報技術事務所 塚原 壑 [プロフィール]  :2月号

1.はじめに

 システムは、「ある定義された目的を達成するため、相互に作用する要素の組み合わせである。要素には、ハードウェア、ソフトウェア、ファームウェア、人、情報、技法、設備、サービス、その他の支援要素が含まれる。」とINCOSE1が定義しています。ここで、達成すべき“ある定義された目的”2は、システムを利用する(あるいは必要とする)社会や企業等のビジネス(事業、含むサービス)によって示されます。その目的は、関連する人々(利害関係者)のニーズ(必要や要求)との間を双方向に整合させて、共有されなければなりません。このような“ある定義された目的と要求”を明確化するには複雑な手続きが必要です。
 システムへの目的と要求を達成するには、これらをシステム仕様化して、必要な要素を選択します。そして、相互に作用する組み合わせ(システムおよびその構成)を決定します。ほとんどのシステムは、ソフトウェアが構成要素となっていて、システムへの要求仕様、とりわけ機能仕様の実現には、ソフトウェアが大きな役割を担っています。そのため、ソフトウェア開発の良・不良がシステム開発の成否に直結しています。

 このようなソフトウェア開発の重要性を認識して、日本では、ソフトウェアを中心としたシステム開発をテーマにしたガイドブック『共通フレーム』および『ITプロジェクトの「見える化」』が刊行されています。『共通フレーム』は、2007年第2版が最新版で、取得者(ユーザ)と供給者(ベンダ)との二者間取引の適正化と可視化を図り、業界の共通フレームとして利用されることを主目的に刊行されています。
『ITプロジェクトの「見える化」』は、システム開発工程を上流・中流・下流に3区分して、プロジェクトの作業と生産物を可視化して、プロジェクトマネジメントの問題解決手法を見出し、普及させることを目的としています。上流・中流・下流の各編および総集編(2008.10)が刊行されています。

 本稿は、これら2つのガイドブックとは視点を変えて、ソフトウェア開発をエンジニアリングの視点から考察します。具体的には、多くの国で事実上の標準と目されている『ソフトウェアエンジニアリング基礎知識体系(Guide to the Software Engineering Body of Knowledge 2004 Version)』(以下はSWEBOKガイドと略す)を読んで、内容を考えます。

2.SWEBOKガイドの概要

 ソフトウェアは「情報処理システムのプログラム、手続き、規則および関連文書の全体または一部分。」(JIS,1994)と定義され、エンジニアリングは「科学的知識を実用的な問題に適用する芸術あるいは科学に対処する規律」(ウェブスターオンライン辞書)と定義されています。
 では、ソフトウェアエンジニアリングとは、どのような内容なのでしょうか。

 IEEE (米国電気電子学会)とACM(アメリカ計算機学会)が共同して設立した団体SWECC (SoftWare Engineering Coordinating Committee)は、1998年にSWEBOKプロジェクトを開始して、連続した3つのプロジェクトフェーズを経て、SWEBOKガイド2004年版を公開しました。公開にいたる3つのプロジェクトフェーズの開発工程では、数十カ国、数百人の専門家が参加し、査読に加わったこと、関連する機関の参加を得たことを紹介して、SWEBOKガイドが多くの関係者・関連機構から支持されているという認識を示しています。

---------------
1 SWEBOKガイドでは、INCOSE(International Council on Systems Engineering)の定義を引用している。
2 本稿では、SWEBOKガイドのおもな項目名および記述文に“  ”をつけて引用する。

2.1 SWEBOKガイドの全体構成
 SWEBOKガイドは、全体が12の章で構成され、第1章“ガイドへの序説”から始まっています。続く第2章から第11章には、1つの知識領域を1つの章にして、10の知識領域が記述されています。そして、第12章“ソフトウェアエンジニアリングに関連するディシプリン3”が終章となっています。

第1章は、つい最近になって、ソフトウェアエンジニアリングがようやく正統なエンジニアリング・ディシプリンであり、専門職業であると認められる地位に到達したと述べています。そのうえで、このように認知されるためには、中核となる知識体系についての合意が必須であるという認識を示しています。
 知識領域の第2章から第6章は、ソフトウェア開発・保守に適用する5つのプロセスに関する知識が記述されています。第7章から第11章は、ソフトウェア開発・保守の全プロセスで適用する5つの知識が記述されています。
 終章の第12章には、次の8つのディシプリンをあげて、解説的な定義と知識領域のリストを説明しています。
《関連するディシプリン》
“コンピュータエンジニアリング”、“コンピュータサイエンス”、“マネジメント”、“数学”、“プロジェクトマネジメント”、“品質マネジメント”、“ソフトウェア・エルゴノミクス”、“システムエンジニアリング”

2.2  SWEBOKガイドの作成目標および目的
 SWEBOKガイドは、作成にあたって、次の5つの目標を掲げました。
1) ソフトウェアエンジニアリングに関して、一貫した考えを世界に広めること
2) 関連する他のディシプリンに対して、ソフトウェアエンジニアリングの位置づけを明らかにして境界を置くこと
3) ソフトウェア・ディシプリンの内容を特徴づけること
4) ソフトウェアエンジニアリング知識体系へ、トピックスに従ってアクセスできるようにすること
5) カリキュラムの開発、個人の資格認定、および免許のために必要となる基礎を提供すること

 目標1)に関して、多くの専門家と関連機関から支持を受けて公開されたSWEBOKガイドは、今後も進化をつづける方策が検討され、普及活動が推進されています。
 目標2)の関連する他のディシプリンとは、第12章で示した内容です。これらの分野との間に明確な境界を置くという目標2)、および自らのディシプリンの内容を特徴づけるという目標3)は、目標4)を具体化する方法などによって実現されています。このことは、次節で、もう少し詳しい説明をします。
 目標5)は、ソフトウェアエンジニアリング学部卒業後4年間の実務経験を経た人が身につけていなければならない知識レベルをSWEBOKガイドの各トピックスに対して示しています。

 ここまで概観してきたことを次のように要約します。
 “ソフトウェアエンジニアリング・ディシプリンという領域のもつ、合意によって妥当化された特質の範囲を紹介し、このディシプリンをサポートする知識体系への、その都度必要とされるアクセス手段を提供することにある。”
 実は、この一文はSWEBOKガイドの序文に述べてある“本書の目的”です。SWEBOKガイドは、目的・目標を忠実に達成して作成された文書です。

 以上が、SWEBOKガイドの経緯、目的・目標、および全体構成のあらましです。

3.SWEBOKガイド知識領域の内容

 次に、知識領域では、何が取り上げられ、どのように扱われているかを説明します。

---------------
3 “ディシプリン”:方法論に基づいた教育・訓練によって形成された規律(用語説明は日本語訳書に従った)。

3.1 全体知識領域の内容
 前半の5つの章(第2章から第6章)には、ソフトウェアエンジニアリングが対象とするライフサイクルプロセスを次の内容で記述しています。
《プロセスの知識領域》
“ソフトウェア要求(software requirements)”、“ソフトウェア設計(software design)”、“ソフトウェア構築(software construction)”“ソフトウェアテスティング(software testing)”、“ソフトウェア保守(software maintenance)”

 後半の5つの章(第7章から第11章)には、次の内容を記述しています。
《マネジメントとツール・技法の知識領域》
 “ソフトウェア構成管理(software configuration management)”、“ソフトウェアエンジニアリング・マネジメント(software engineering management)”、“ソフトウェアエンジニアリングプロセス(software engineering process)”、“ソフトウェアエンジニアリングのためのツールおよび手法(software engineering tools and methods)”、“ソフトウェア品質(software quality)”

 1つの章では、1つの知識領域を次のように構成して説明しています。
 最初に、“序説”で、知識領域の概要、対象としている範囲の展望、他の知識領域に対する関係を記述しています。次に、“トピックス要素分け”という作業によって、知識領域を、副知識領域、トピックス、サブトピックスに分けて記述しています。トピックス、サブトピックスには、それぞれに短い説明文を付しています。トピックスとサブトピックスの説明文の後に、トピックスおよびサブトピックスと参考文献との関連表および参考文献リストが掲載されています。参考文献は、推奨文献、関連文献、標準の区分をつけたリストを表示しています。

 SWEBOKガイドをハブとする参考文献の適量は、5,000ページとデザインされています(日本語訳書p230)。ソフトウェアエンジニアリングを専門職業とするための知識を取得するには、この文書量に相応する覚悟と努力が必要です。

3.2 個別知識領域の内容
 前項の3.1で述べた10の知識領域は、46の副知識領域に区分され、副知識領域は178のトピックスに展開されています。副知識領域、トピックスのそれぞれが簡潔に説明されていますが、トピックスが大量なので、知識領域の内容をさらにまとめて、簡潔な要旨とすることが困難です。
 本稿では、2つの知識領域(“ソフトウェア要求”と“ソフトウェア品質”)を選択して、副知識領域およびトピックスの項目名を示します。そして、いくつかのトピックスに関する記述の一部を引用します。こうして、SWEBOKガイドの特徴と内容の一端がお伝えできないかを試みます。

3.2.1 知識領域“ソフトウェア要求”の内容
 第2章の知識領域“ソフトウェア要求”は、7つの副知識領域に区分されて、それぞれの副知識領域は次のようなトピックス(全28)で構成されています。

 第1の副知識領域は“ソフトウェア要求の基礎”です。ここでは、ソフトウェア要求の定義、主な要求の型、定量化が可能な要求の重要性がトピックスになっています。主な要求の型は、プロセス要求とプロダクト要求、機能的要求と非機能的要求、創発的性質の要求、システム要求とソフトウェア要求などが記述されています。

 第2の副知識領域“要求プロセス”では、プロセスモデル、プロセスアクタ、プロセス支援およびマネジメント、プロセス品質および改善がトピックスとなっています。ここでは、要求プロセスがどのようにして、ソフトウェアエンジニアリングプロセス全体の要(かなめ)になっているかを記述しています。

 第3の副知識領域は、“要求抽出”です。要求の生成源、抽出の技法がトピックスになっています。要求はどこから生まれるか、またソフトウェアエンジニアはどのようにこれらの要求を収集すべきかを記述しています。

 第4の副知識領域は“要求分析”です。要求のクラス分け、概念モデル作成、アーキテクチャ設計、要求割り付け、そして要求折衝がトピックスです。この副知識領域は、次のような目的をもった要求分析のプロセスに関与します。
・要求相互間の競合を見出して解決すること
・ソフトウェアの境界を発見してどのように周囲の環境と相互に作用すべきかを見つけること
・システム要求からソフトウェア要求を練り上げること

 第5の副知識領域は、“要求の仕様化”です。ここでは、システム定義文書、システム要求の仕様化、ソフトウェア要求の仕様化がトピックスです。“要求の仕様化”に関して、次のように記述しています。
 “複雑なシステムにおいては、とくにかなりのソフトウェアでない部分要素を巻き込んでいる場合には、3つの型の文書、すなわち、システム定義、システム要求仕様、およびソフトウェア要求仕様が作成される。”“大量のソフトウェア部分、および定期旅客機のような大規模な非ソフトウェア部分からなるシステムの開発者は、しばしば、システム要求記述をソフトウェア要求記述から切り離している。この考えに従えば、システム要求が仕様化された後、ソフトウェア要求がシステム要求から導出され、その後でソフトウェア部分要素に対する要求が仕様化されるものとする。厳密にいえば、システム要求の仕様化は、システムエンジニアリングのアクティビティに属し、本書(SWEBOKガイド)の範囲外とされなければならない。”

 第6の副知識領域は、“要求の妥当性確認”です。ここでは、要求の文書が妥当なシステム(すなわち、ユーザが求めるシステム)を定義しているかを確証するために、要求文書を検査するプロセスを扱っています。要求レビュー、プロトタイピング、モデル妥当性確認、および受け入れテストがトピックスになっています。

 第7の副知識領域は、“実践上考慮すべきことがら”です。ここには、実際上理解しておく必要のある5つのトピックスが記載されています。
 要求プロセスの反復性のトピックスには、次の記述があります。“おそらくソフトウェアエンジニアリングを理解するための最も重要なポイントは、要求の大部分が変更になるだろうということにある。”“原因はともかくとして、変更が不可避であることを認識し、その効果を軽減するような手を打たねばならない。”
 また、要求追求のトピックスには、“要求は、それを生成した元の要求、および利害関係者にまで(たとえば、ソフトウェア要求からそれによって満たされようとするシステム要求まで)遡って追跡されなければならない。逆に、要求を前方に向けて追跡し、それを満たすために生じた新たな要求、および設計上の実在(たとえば、システム要求から作り上げたソフトウェア要求、およびそれを実現するためのコードモジュール)に至るまで追求できなければならない。”このほか、変更管理、要求属性、要求の計量のトピックスが記述されています。

 以上の内容から、次の重要な事項を読みとることができます。
・ソフトウェアエンジニアリングを実践するには、システムを取り巻く環境が常に進化し、要求変更が起こるので“要求プロセスの反復性”に備えること
・ビジネス、システム、ソフトウェアの境界を明らかにして、それぞれの“要求の仕様化”を行うこと
・“要求追跡”は、後方(システム要求、利害関係者要求)および前方(コードモジュール要求)の双方向への追跡可能性を確保すること

3.2.2 知識領域“ソフトウェア品質”の内容
 第11章“ソフトウェア品質”の知識領域は、3つの副知識領域に区分されて、それぞれの副知識領域は次のようなピックス(全11)で構成されています。

 第1の副知識領域は“ソフトウェア品質の基礎”です。ここでは、ソフトウェアエンジニアリング文化および倫理、品質の価値およびコスト、モデルおよび品質特性、品質改善がトピックスになっています。
 モデルおよび品質特性のトピックでは、次の記述があります。
“すべてに先んじて、ソフトウェアエンジニアは、ソフトウェアの目的を決定しなければならない。このことに関して、顧客の要求を第一優先に考え、そのなかには機能的な要求だけでなく、品質に関する要求も含まれているのだということを心しなければならない。したがって、ソフトウェアエンジニアは、初期の段階では明確ではないと考えられる品質要求を抽出する責任があり、その重要度を、それを達成するための難しさと組にして議論する責任がある。”

 第2の副知識領域は“ソフトウェア品質マネジメントプロセス”です。ここでは、ソフトウェア品質保証、検証と妥当性確認、レビューおよび監査がトピックスになっています。
 ここで説明されるソフトウェア品質マネジメント(SQM: Software Quality Management)は、ソフトウェアのプロセス、プロダクトおよび資源の全体的な観点に適用されます。SQMの主なプロセスには、品質保証プロセス、検証プロセス、妥当性確認プロセス、レビュープロセス、監査プロセスがあります。これらのプロセスは、ソフトウェア計画(たとえば、マネジメント、開発、構成管理)がいかに実現されているか、そして、いかに中間成果物および最終プロダクトが仕様化された要求に合致しているかを示すためのタスクと技法から成り立っています。これらのタスクから得られた結果は、マネジメントのための報告書にまとめられます。SQMプロセスには、この報告書の結果が間違いのないようにすることが課せられています。

 第3の副知識領域は“実践上考慮すべきことがら”です。ここでは、ソフトウェア品質要求、欠陥の特徴づけ、ソフトウェア品質マネジメント技法、ソフトウェア品質計量がトピックスになっています。
 ソフトウェア品質計量のトピックでは、次の記述があります。
“ソフトウェアが精巧化するに従って、品質の問題は、ソフトウェアが動くかどうかではなく、どれだけ計量可能な品質目標を達成するかに移っている。計量がSQMを直接に支援することに関して、さらにいくつかのトピックスがある。そのなかの1つは、テスティングをいつ終了(stop)すればよいかを決定するための助言である。”

 ソフトウェア品質の知識領域は、ライフサイクルプロセスの枠を超えたソフトウェア品質の問題をとり扱っています。ソフトウェア品質は、ソフトウェアエンジニアリングのいたるところにおける関心事なので、他の多くの知識領域でも論じられています。

4.おわりに

 本稿は、SWEBOKガイドを題材にして、ソフトウェア開発をエンジニアリングの視点から考察しました。内容を読み進むにつれて、「ソフトウェアはシステムの構成要素であり、システムはビジネスの目的を達成するために開発・保守・運用される。」という枠組みを前提にして、SWEBOKガイドの知識体系が構成されていることを感じました。
 にもかかわらず、SWEBOKガイドは、ソフトウェア要求プロセスの“要求抽出”を知識領域の開始点としています。そのうえで、ソフトウェア要求はシステム要求から抽出し、システム要求はビジネス要求(および目的)から得ると説明しています。そして、このようなソフトウェアエンジニアリングの境界では、システムエンジニアリングと統合したマネジメントの必要性を示唆しています。
 ソフトウェアエンジニアリングの境界をどのように取扱うかは、関連するディシプリンすべてに関わる課題となります。したがって、SWEBOKガイドを作成するための目的と目標は、この課題を解決しようという取組みへの意思表示なのだと、筆者は理解しています。
 ソフトウェアを中心とするシステム開発をプロジェクト組織で行おうとするときには、ソフトウェア開発プロセスにおいて、エンジニアリングをマネジメントするという意識が必要であることを喚起しているのだと感じています。

〔参考文献〕
  • 松本吉弘 訳、ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK2004―、2005 (IEEE Guide to the Software Engineering Body of Knowledge 2004 Version, 2004)
    (原文は、 こちら で入手できます。 現在(2010年)、HTMLは無料、PDFおよびBOOKは有料です。)
  • 松本吉弘 著、ソフトウェア開発へのSWEBOKの適用、2005
    (SWEBOKガイドを実務に適用するための案内書です。第1部はソフトウェア開発事例、第2部はSWEBOK2004解説 の2部構成となっています。)
  • 榊原彰 執筆、SWEBOKで学ぶソフトウェア・エンジニアリング、2006
     (Part1 ソフトウェア・エンジニアリングとは、Part2 ソフトウェア・エンジニアリングの体系、という内容で解説された記事が入手できます。 こちら
    なお、この記事は、ソフトウェアエンジニアリングの知識体系に関する代表的な書籍を紹介しています。本稿筆者の判断で、この記事の掲載以降に発刊された書籍を1つ、下記に追加しておきます。
  • ITトップガン育成プロジェクト 著、ソフトウェアエンジニアリング講座1ソフトウェア工学の基礎、2007
     (この書籍でもSWEBOKを紹介しています。この講座は、2システム開発プロジェクト、3プログラミング、4オープンシステム技術の4冊で構成されています。)

  IT-SIG,内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。

SIG推進部会は こちら
ITベンチマーキングSIGホームページは こちら
ページトップに戻る