| ■１．ソフトウェア工学とは■ Q1.規模、実時間性以外に、どのような視点がありますか？ Q2.上流工程とはどのようなものですか？ Q3.ソフトウェアが破棄されるのは、どのような場合ですか？ Q4.ここで述べるモデルとは何ですか？また、どのように表現しますか？ Q5.ISBOKの専門知識には、どのようなものがありますか？ ■２．ソフトウェア開発プロセス■ Q1.開発工程ごとにレビューを行うと、開発費用が増大するのではないですか？ Q2.ウォータフォール型開発プロセスと反復／漸進型開発プロセスを組み合わせて使うことはできますか？ Q3.反復／漸進型ソフトウェア開発プロセスのリスク分析とは何ですか？ Q4.CMMの評価は、どのようにして行うのですか？ ■３．ソフトウェア構造とモジュール分割■ Q1.構造化設計手法とオブジェクト指向設計手法でソフトウェアを開発するときに使われるプログラミング言語は？ Q2.機能が変化を受けやすいことがなぜ構造化設計手法の問題なのですか？ Q3.実世界の実体と対応つけるような直感的な設計の延長で、実行可能なソフトウェアが開発できるのですか？ Q4.３つの区画に区切られた長方形の意味を教えてください。 Q5.オブジェクト指向設計手法では仕様変更にどのように対応していますか？ ■４．オブジェクト指向とモデリング言語■ Q1.オブジェクト指向言語を利用するとカプセル化は実現されるのですか？ Q2.カプセル化のメリットは何ですか？ Q3.継承するとは、プログラムを書くときはどんな作業になるのですか？ Q4.配置図とコンポーネント図の違いは何ですか？ Q5.配置図は、物理的な処理単位をノードと捉えてとあるが、プログラムを処理するCPUはノードでないのか？ Q6.分析モデルと設計モデルの違いは何ですか？ Q7.操作パネルに属性がないのはなぜですか？ ■５．オブジェクト指向分析と設計■ Q1.責務とは何ですか？ Q2.オブジェクトの振る舞いを、ステートチャート図として作成した後、どのような作業をするのですか？ Q3.プログラムの作成の図にあるプログラムの言語は何ですか？ Q4.ソースコードを基にUMLモデルを作成する機能はどんなときに利用するのですか？ Q5.統合開発環境IDEはどのようにして入手するのですか？ ■６．ソフトウェアの品質保証■ Q1.ソフトウェアとハードウェアでは、品質保証について違いがありますか？ Q2.ISOの品質特性が制定された経緯と意義は？ Q3.品質特性、品質測定の尺度、品質評価の関係は？ Q4.結合度と凝集度の違いを教えてください。 Q5.CKメトリクスの各尺度の具体的イメージはどんなものですか？ ■７．ソフトウェア開発のマネージメント■ Q1.Putnum法とはどんな特徴があるものですか？ Q2.UCP法の特徴と、今後の方向はどんなものですか？ Q3.COCOMOにはバリエーションがありますか？ Q4.QCDとは、具体的になんですか？ Q5.ソフトウェアの開発にPMBOKが採り入れられた経緯は？ ■８．ソフトウェア工学の発展■ Q1.XPにはどのような特徴がありますか？ Q2.なぜパターンが注目されているのですか？ Q3.パターン化により作成されたプログラムの実行時の効率は悪くないのですか？ Q4.コンポーネントベース開発の特徴はどんなものですか？ Q5.コンポーネントの設計段階で注意するところはどんな点ですか？ ■１．ソフトウェア工学とは■ Q1 規模、実時間性以外に、どのような視点がありますか？ A1 規模の大小は、管理の視点から開発対象の難しさを表す１つの視点ですが、この管理的な視点に着目すると、それ以外に開発期間の長さや開発に関わる人の人数が挙げられます。 実時間の性能は、技術的な視点から開発対象の難しさを表す１つの視点ですが、この技術的な視点に着目すると、それ以外にシステムの分散度や、セキュリティの程度、障害に対する耐性などが挙げられます。
上流工程とはどのようなものですか？ A2 ソフトウェアの開発は一般的に、要求分析、システム設計、プログラム設計、コーディング、テスト、保守の６工程に分類されます。ユーザが要求する側に近い工程を上流工程と呼びます。
ソフトウェアが破棄されるのは、どのような場合ですか？ A3 運用されているソフトウェアで、簡単な修正により機能や性能が向上するなら改良が行われますが、システム設計のやり直しなどかなりの変更が必要となる場合に、そのソフトウェアは破棄されることになります。
ここで述べるモデルとは何ですか？また、どのように表現しますか？ A4 モデルとは、プロダクトの特定の側面、たとえば、機能や構造や振る舞いの一部を表現したものです。 モデルの表現方法としては、情報の流れに着目したデータフロー図、構造に着目した実体関連図、状態に着目した状態遷移図、他に流れ図（フローチャート）や構造チャートなどがあります。
ISBOKの専門知識には、どのようなものがありますか？ A5 情報処理学会の情報工学部会では、専門家を教育するコースとして、コンピュータ科学、コンピュータ工学、ソフトウェア工学、情報工学の４つの領域を提示しています。
■２．ソフトウェア開発プロセス■ Q1 開発工程ごとにレビューを行うと、開発費用が増大するのではないですか？ A1 レビューにおいては、各工程における成果物をチェックし、不具合を見つけて修正し、品質を高めます。不具合が後の工程で見つかるほど、後戻りのコストがかかり、全体の開発コストを押し上げてしまいます。 そのため、早い段階で不具合を見つけだして対応することにより、コストを抑えることができます。また、プロジェクトの管理者や品質管理部門の担当者が参加することにより、進捗状況や品質を把握できるので、全体のコスト管理に役立ちます。
ウォータフォール型開発プロセスと反復／漸進型開発プロセスを組み合わせて使うことはできますか？ A2 可能です。 例えば、最初に小規模な試作品(プロトタイプ)を開発して、操作性を利用者に確認してもらったり、性能などを開発者が確認してから、本来のソフトウェアをウォータフォール型開発プロセスで開発する方法があります。 別の例としては、非常に大規模なソフトウェア開発をフェーズ１、フェーズ２、．．という形で段階的に開発するとき、個々のフェーズではウォータフォール型開発プロセスを活用することができます。 このように、ウォータフォール型開発プロセスと反復／漸進型開発プロセスは互いに相反するものではなく、それぞれの利点を組み合わせた開発プロセスを活用することができます。
反復／漸進型ソフトウェア開発プロセスのリスク分析とは何ですか？ A3 仕様の変更による工程の遅れ、予算の超過など、ソフトウェア開発にとっての障害やそれに伴う損失がリスクです。 これらのリスクについて、発生する要因や確率、損失、回復の手段などについて明らかにしておくことをリスク分析といいます。
CMMの評価は、どのようにして行うのですか？ A4 CMMを開発した米カーネギーメロン大学のソフトウェアエンジニアリング研究所から資格認定された評価者（リード・アセッサ）がレベルを判定します。
■３．ソフトウェア構造とモジュール分割■ Q1 構造化設計手法とオブジェクト指向設計手法でソフトウェアを開発するときに使われるプログラミング言語は？ A1 構造化設計手法で設計した結果は、一般には、Fortran, Cobol, C のような手続き型プログラミング言語での実装が適しています。 オブジェクト指向設計手法で設計した結果は、一般には、Java, C++, C# のようなオブジェクト指向プログラミング言語での実装が適しています。
機能が変化を受けやすいことがなぜ構造化設計手法の問題なのですか？ A2 構造化設計手法では、機能がモジュール分割の観点なので、機能が変わればモジュール分割の観点も変わります。 そして、機能同士の結びつきが強いために、変更箇所を局所化できなくて、ある機能の変更によって他の多くの機能も変更が必要になり、システム構造の変化に波及してしまうのが問題となります。
実世界の実体と対応つけるような直感的な設計の延長で、実行可能なソフトウェアが開発できるのですか？ A3 できます。 分析段階では実世界の実体同士の構成ややり取りを考えますが、設計段階では、それらを「実世界の実体を制御するソフトウェア」と読み替えています。 たとえば、自動販売機の例で「商品スロット」オブジェクトは分析初期段階では自動販売機の商品スロット装置と考えていますが、設計段階では自動販売機の商品スロット装置を制御する商品スロット制御ソフトウェアであると考えてそのために必要な操作や属性を定義していきます。 このようにして、実世界の実体の構造や振る舞いを実行可能なソフトウェアの構造や振る舞いに対応する形で、ソフトウェアを開発できる点がオブジェクト指向開発の特徴です。
３つの区画に区切られた長方形の意味を教えてください。 A4 この長方形は、「クラス」を表します。クラスとは、オブジェクトを共通の特徴に基づいて分類したもので、抽象的な概念です。詳しくは、レッスン４、レッスン５で学習します。 長方形は３段に分かれていて、上段はクラス名です。そのクラスが役割を果たすのに必要となるデータを中段に「属性」として中段に記入します。そして、動作（振る舞い）に関わる情報を「操作」として下段に記入します。
オブジェクト指向設計手法では仕様変更にどのように対応していますか？ A5 構造化設計手法における機能は、トップダウン方式に階層化して表現されているため、あるレベルの機能や機能間のデータの流れを変更しようとすると、それに伴って上位／下位の変更の手間が大きくなります。 つまり、ダイアグラムの記述の変更のたびに、他の多くのダイアグラムの見直しが必要になってきます。 これに対して、オブジェクト指向設計手法では、個々のダイアグラムの記述範囲と、他のダイアグラムの独立性を高めることによってこの問題を解決しています。
■４．オブジェクト指向とモデリング言語■ Q1 オブジェクト指向言語を利用するとカプセル化は実現されるのですか？ A1 オブジェクト指向言語を用いてプログラムを作成してもカプセル化が実現されるとは限りません。 カプセル化を実現するには、どのような操作と情報を１つのオブジェクトにグルーピングすべきかを、理解容易性や保守性を考慮して注意深く設計する必要があります。
カプセル化のメリットは何ですか？ A2 オブジェクトを利用する人にとっては、その内部のデータの構造を知らなくても、外部に公開された操作の呼び出し方さえ知っていれば、そのオブジェクトを利用できる点がメリットです。 他方、オブジェクトのクラスを定義する人にとっては、内部のデータの構造を変更しても、外部に公開する操作群の仕様を変えない限り、そのオブジェクトを利用する他のプログラムに対して、内部データ構造の変更が波及しないでいられる点がメリットです。
継承するとは、プログラムを書くときはどんな作業になるのですか？ A3 継承する場合は、スーパークラスに相当するクラスは通常のクラスと同様に定義し、スーパークラスを継承するサブクラス側に、対象となるスーパークラスを継承していることを記します。 また、サブクラス側のクラスには追加すべきデータや操作だけを書くことで、スーパークラスと重複する記述を行う必要がありません。
配置図とコンポーネント図の違いは何ですか？ A4 配置図はハードウェアとその構成を描いたもので、コンポーネント図は実行環境に配置されるバイナリのコンポーネント群とその構成、構造を書いたものです。 配置図の記述要素とコンポーネント図の記述要素は同じ１枚の図上に描かれることもあります。
配置図は、物理的な処理単位をノードと捉えてとありますが、プログラムを処理するCPUはノードでないのですか？ A5 物理的な処理ノードには、計算機とデバイスがあります。CPUは計算機の構成要素であり、ノードとしては認識しません。
分析モデルと設計モデルの違いは何ですか？ A6 分析モデルは現実世界の語彙や構造をモデル化したものです。これに対して、設計モデルは実行環境や、理解しやすさ／保守しやすさ等の非機能要件を考慮して設計者の設計上の判断に基づいてモデル化したものです。
操作パネルに属性がないのはなぜですか？ A7 詳細に見れば、操作パネルに配置されている缶飲料のボタンや展示表示のレイアウト情報などを属性情報として持つ必要があります。レッスンで行ったモデル化では、これらは重要な意味を持たないため、クラス図上には明記していません。 モデルは、そのモデル化する対象となるモノの重要な側面を捉えたものであり、モデル化の目的によって、表現されるモデルは変わり得るものであることに注意する必要があります。
■５．オブジェクト指向分析と設計■ Q1 責務とは何ですか？ A1 各クラスに割り当てられた義務です。 責務(responsibility)とは、もともと反応／返答する(response)ことができること(ability)を意味します。外部から当該クラスのオブジェクトに対してメッセージが送信されたときに、反応／対応することができる処理一式が、そのクラスの責務です。
オブジェクトの振る舞いを、ステートチャート図として作成した後、どのような作業をするのですか？ A2 ステートチャート図には、クラスの持つ状態と外部やり取りされるメッセージが記載されます。 クラス図とステートチャート図を用いてソースコードの記述を開始することができます。このとき、状態を保持するために必要な変数の割り出しはステートチャートを用いて行います。
プログラムの作成の図にあるプログラムの言語は何ですか？ A3 Java言語です。Java言語はC++言語など、既存の言語の欠点を踏まえて設計された言語です。 また、強力なセキュリティ機構や豊富なネットワーク関連の機能が標準で搭載されており、ネットワーク環境で利用されることを意識しています。
ソースコードを基にUMLモデルを作成する機能はどんなときに利用するのですか？ A4 大きく２つ考えられます。 １つは、既存のソフトウェアの分析を行う場合です。 もうひとつは、ソフトウェアの分析作業とソースコードの記述を並行して行う場合です。 分析結果を基にソースコードを記述しますが、このとき、クラス構成などを変更してしまうと、分析モデルとソースコードの記述内容にずれが生じます。このため、下流工程にあるソースコードからUMLモデルを作成する機能を利用して、モデルとソースコードの記述内容の同期を取ります。
統合開発環境IDEはどのようにして入手するのですか？ A5 大手開発ツールメーカーから発売されています。 また、オープンソースの開発環境では、eclipseやNetBeans IDEなどがあります。オープンソースの開発環境はネットワークを利用してダウンロードすることが可能です。
■６．ソフトウェアの品質保証■ Q1 ソフトウェアとハードウェアでは、品質保証について違いがありますか？ A1 ユーザに対し、製品の品質を保証するという考えの基本は同じですが、具体的な品質を特定しがたいソフトウェアでは、保証する手段については違いがあります。
ISOの品質特性が制定された経緯と意義は？ A2 ソフトウェアはハードウェアに比べ、目に見えない物でもあり、その評価は非常に困難です。反面、評価することは重要な問題となります。 その難題の一つのガイドラインとして、ISO/IEC 9126 (JIS X0129)ソフトウェア品質特性(Quality Characteristics)が制定されました。 経緯としては、1976年にアメリカ国防省の要請を受けたベーム(Boehm)により、ソフトウェア品質モデルの基礎となる階層構造（主たる特性が複数あり、その一つ一つの特性には複数の副特性があるという考え方）を採用した「ベームのソフトウェア品質モデル」が発表されました。 それ以外にも「SQM：Software Quality Metrics」や、1985年日本電気で開発された「SQMAT」、IBMで開発された「SQUALAS」、1987年バージニア工科大学のOPA、1988年バシリ(Basili)のGQM(Goal・Quality・Metrics)モデル等の品質モデルが提唱されました。 それらの提唱された品質モデルの良い点・問題点を吸収し、世界共通の品質モデルの必要性を満たすISO/IEC 9126が1991年発行されました。日本ではこの世界規格を1994年1月にJIS X0129として発行しました。 現在、その難解さゆえに、利用されることは少ないといわれていますが、ソフトウェア工学の基盤となる項目であり、ソフトウェアに携わる関係者は運用やその内容の改善に取り組むことが今後のソフトウェア工学の発展に重要なことと思われます。
品質特性、品質測定の尺度、品質評価の関係は？ A3 ソフトウェアの品質を評価するために対象とすべき特性を、ISOの品質特性として、枠組みを規定しています。 実際に適用する際には、対象とするソフトウェアに対応する品質特性を抽出して、抽出された特性ごとに数値化して基準値を定め、品質測定の尺度として、実際に作り上げたソフトウェアで測定し、品質を数値で評価します。 標準規格に基準値や測定方法までも記述されているわけではありません。
結合度と凝集度の違いを教えてください。 A4 結合度はシステムを構成する構成要素同士の結びつきの強さを表します。オブジェクト指向の場合は、クラスが構成要素です。クラス同士は互いに結合度が低いほうが、差替えや再利用が容易となります。 他方、凝集度とは構成要素を構成する構成要素同士の結びつきの強さを表します。 オブジェクト指向で開発する際のクラスに関しては、クラス内に定義されているデータや操作は、無関係なもの同士が集まっているよりも互いに関係強いもの同士が集められている方が、つまり凝集度が高い方が、クラスの変更や利用が容易となります。
CKメトリクスの各尺度の具体的イメージはどんなものですか？ A5 尺度の１つである「重み付きメソッド数」に対するクラス図上のイメージは、6.3の学習画面に赤い破線で示してあります。 「クラス階層の深さ」は、クラスの派生関係が木構造であるときは、そのクラスの木の中での深さを表します。 「サブクラス数」は、そのクラスから直接派生しているクラスの数を表します。 「クラス間結合度」は、あるクラスが他のクラスのインスタンス変数やメソッドを参照しているクラス数を表します。他のクラスのインスタンス変数やメソッドを参照することを「結合」といいます。 「オブジェクト指向クラスが持つメソッドの凝集欠如度(LCOM)」は、あるクラスの凝集性の欠如を計測します。LCOMが小さいほど凝集性が高く、メソッドの強度が高いことを表します。LCOMが大きいものは、変数を共有している部分が多いことを表し、メンテナンス性が低いことを示唆します。
■７．ソフトウェア開発のマネージメント■ Q1 Putnum法とはどんな特徴があるものですか？ A1 経験データによるモデルからではなく、仮説から出発しプロジェクトの工数を表現することを特徴とするモデルです。開発規模と要員計画からコストを算出します。
UCP法の特徴と、今後の方向はどんなものですか？ A2 近年、設計段階での見積もりでは受注競争に間に合わなくなってきており、プロセスのさらに早期である要求分析段階での効果的な見積もり手法が必要とされてきています。 代表的なものとして、FP法をベースとし、オブジェクト指向開発の要求分析段階で作成されるユースケースモデルに基づいて、開発規模および開発工数を見積もるのが、ユースケースポイント(UCP)法です。 しかしこの手法を実際に適用して見積もりを行うには、モデル内の要素を重み付けする際にある程度の熟練度を必要とし、また同一プロダクトに対する計測でも、計測者によって誤差が生じるといった問題点も存在します。 そのため、アクターとユースケースに対する重み付けの部分にいくつかのルールを設定し、モデル内の情報から半自動で見積もりのためのパラメータを自動付与する方法など、できるだけ熟練度を取り除く方法が研究されています。
COCOMOにはバリエーションがありますか？ A3 COCOMO法は、実装言語の違いに左右されず、客観的な数値を算出できるといわれています。しかしながら、分析・設計工程の見積もりが不可能なことに加え、組織全体の開発能力の成熟度や、開発・テスト・検証を重ねる「繰り返し型開発プロジェクト」に適していないという問題があります。 そこで、FP法を取り入れ、上流工程の分析・設計工程の見積もりを可能とし、さらに、CMMの概念を取り入れ、組織全体の開発能力の成熟度や開発・テスト・検証を重ねる方式を取り入れたCOCOMO IIが提唱されています。これにより、上流工程の正確な見積もりや反復／漸進型開発プロセスへの適用も可能になっています。 また、コンポーネントベース開発向けである COCOTS (COnstructive Commercial Off-The-Shelf) や潜在的な不具合数の予測向けである COQUALMO (COcomo QUALity MOdels) も提唱されています。
QCDとは、具体的になんですか？ A4 Quality（品質）は、ユーザがソフトウェアを使うときの満足度を満たすものです。先のレッスンで品質特性として示した、信頼性や使用性は、品質を表す代表的な視点です。 Cost（コスト）は、開発に掛かる費用です。開発者の人件費や開発者が使う環境やツールの費用を含みます。 Delivery（納期）は、開発したソフトウェアを発注者に収める期限です。
ソフトウェアの開発にPMBOKが採り入れられた経緯は？ A5 ソフトウェアの開発には、どのような生産物をどのような工程で作るかということと、生産物、製造工程を含め、人、物、金、をどのようにして管理するかということが大きな要素となります。 大規模なシステム開発では、規模や難易度の評価に基づく工数の見積もりの難しさや、人の管理の難しさがあり、納期の遅れの原因になっています。 このような背景から、種々の要因を考慮した総合的な管理技術が求められ、米国のPMI (Project Management Institute) が制定した総合的管理の知識体系であるPMBOKが採用されるようになってきました。
■８．ソフトウェア工学の発展■ Q1 XPにはどのような特徴がありますか？ A1 XPは、要求や仕様は変わるものであることを前提に、開発プロジェクトのメンバーとコミュニケーションをとりながら俊敏な開発、頻繁なプロダクトのリリースを行う、小中規模のソフトウェア開発の方法です。 実際の製品のソースコードを書く前に、テストプログラムを作る「テストファースト」や、開発者２人が１台のマシンで共同でプログラムを開発する「ペアプログラミング」など、特徴的な十数件のプラクティス（実践に基づく原則／作法）に準拠してソフトウェアを開発する点が特徴です。
なぜパターンが注目されているのですか？ A2 大型で複雑なソフトウェア開発では、設計する際に繰り返し現れる要素があり、全てを最初から開発するのは効率が悪いと考えられてきています。 ソフトウェアを設計する際に繰り返し現れる経験的な要素をパターンとして抽出し、効率の良いプログラミングを行うことが、開発工数の削減や、プログラムの信頼性向上などの面から優れた効果を得られるので、パターン化が推進されています。
パターン化により作成されたプログラムの実行時の効率は悪くないのですか？ A3 パターン化を行う時点で、効率を重視した開発を行い、実績に基づいてパターンとして利用するので、パターンの組み合わせであっても、実用に耐えるものと考えられています。
コンポーネントベース開発の特徴はどんなものですか？ A4 コンポーネントベース開発の特徴としては、以下のような項目があります。 ・開発効率性：既存のコンポーネントを再利用することで、目的とするソフトウェアの開発期間を短縮し、開発コストを削減できます。 ・要求への適応性：既存のコンポーネントの置換・修正によって、構成するので要求の変化に即応できます。 ・実績による信頼性：実績のある信頼性の高いコンポーネントを組み合わせることで、ソフトウェア全体の一定の信頼性が得られます。 ・分散配置化：インタフェースが明確なコンポーネントを用いるのでネットワーク上で分散配備が可能になります。 しかしながら、再利用を考慮した個々のコンポーネント自体の開発には、オブジェクト指向におけるクラス開発よりコストがかかり、他人が開発したコンポーネントを活用すれば、カスタマイズできる自由度は低くなるというデメリットもあります。
コンポーネントの設計段階で注意するところはどんな点ですか？ A5 設計段階のポイントは、個々のコンポーネントをさまざまな局面で再利用できるように、「独立性を高める」ことにあります。 設計要素間の依存関係いわゆるインタフェースの類をよく分析し、他との依存が少なくしたり、コンポーネント自体の機能や役割が複合的にならないような設計をする必要があります。
|
