ISO/IEC_25030品質要求定義のシステムデザインへの適用に関する考察
8
0
0
全文
(2) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. 設計，設計結果に基づくシステム実現性の検証という「源. 受たり，システムから発信された情報やサービスなど. 流管理」が，かならずしも充分に実施されていない場合も. の間接的な影響を受け，システムから何らか間接的な. ある．ソフトウェアの構造的な欠陥に起因する性能問題の. 影響を受ける利害関係者. 解決のために，最悪のケースでは，開発を完了したソフト ウェアの作り直しにつながることもある．従って，システ. 2.3 顧客の要求のカテゴリー. ムの品質や生産性向上のためには，システムデザインの段. 顧客のシステムに対する要求には明示的な要求，暗黙的. 階で，システムに対する要求の明確化と実現性の検証を行. な要求，無意識の要求がある．ここで顧客が，必要性を表. い，品質を作り込むことによって PDCA サイクルを回すこ. 明する明示的な要求には，以下の特質が考えられる．. とが極めて重要である． ① 2.2 システムの利害関係者. ソフトウェアに対する要求と，それ以外のハードウェ アなどに対する要求がある．. システムの顧客にはシステムのライフサイクル全体の. ②. システム固有の要求と付加された要求がある．. 夫々の局面で，システムデザインに関与する利害関係者が. ③. かならずしも完全ではなく，要求の過不足や，要求間. 存在し，これらの顧客の持つ意識や行動の結果がシステム デザインの品質に影響を及ぼすと考えられる．. 表 1 は，. の矛盾が存在する場合がある． ④. 存在する場合がある. システムデザインの品質と，これに関係する利害関係者の. 要求には広さだけで無く，深さがあり，この両面の要求を. 相互の影響関係を整理したものである．. 適切に満足していない． ⑤システムが顧客の要求に適合しない．. 表 1 顧客のカテゴリー とシステムデザインへの影響 顧客 の 分類 直 接. 間 接. 設計 開発 保守 運用 利用 設計 開発 保守 運用 利用. システムデザイン への影響. 与える. 受ける. ◎ ○ ○ ◎ ◎. ◎ ○ ○ ◎ ◎. ○ ○ ○ ○ ○. ○ ○ ○ ○ ○. ◎：影響度が大きいと考えられる. 利害関係者 の具体 例 設計エンジニア 開発・試験担当者 保守担当者 保守担当者・オペレータ 業務担当者，管理者，経営者 一般利用者 設計エンジニア 開発・試験担当者 保守担当者 保守担当者・オペレータ 他部門管理者，取引先，株主 ○：影響度があると考えられる. ⑥システムの利用時に，役に立たない． ⑦必要性はあるが，実現性が無い ⑤. 必要性も実現性も無い. ⑥. 不必要にも関わらず明示されている. ⑦. 顧客が不必要なことを知らない. ⑧. 設計者が不必要なことを知らない. ⑨. 顧客も設計者も不必要なことを知らない 次に暗黙的な要求には，以下の特徴がある．. ⑩. 顧客も設計者も常識的に知ってはいるが明示されない. ⑪. 顧客は知っているが明示さず，設計者が知らない. ⑫ 表 1 で，システムデザインの品質に関係する利害関係者 には，直接的に関与する場合と間接的に関与する場合があ り，さらに，これらの利害関係者がシステムデザインの品 質に影響を与える場合と，システムデザインの品質から影. 顧客が知らないために明示さず，設計者は知っている さらに，意識されない要求には，. ⑬. 必要だが，明示もされない. ⑭. 将来必要だが，顧客も設計者も気づかず明示されない. 2.3 要求の仕様化. 響を受ける場合があると考えられる． 一般的に，顧客の要求に対する意識の有無，及び意識し 1). 組織や業務目的のためにシステムの設計・開発・保守・. た場合の要求の必要性に対する認識と，要求が仕様化され. 運用に携わるベンダーや特定の利用目的でシステムを. るか否かは必ずしも一致しない．いずれにしてもシステム. 操作し，システムに影響を与えるオペレータや利用者. デザインでは，システムの設計者があるべきシステムの姿. 及び特定の利用目的のためにシステムから出力された. の実現に向けて，要求の抽出に必要と認められる全ての関. 結果を利用し，支援や情報の提供を受けてシステムか. 係者を対象として顧客の意識や認識に関わらず，要求の網. ら何らかの直接的な影響を受ける利害関係者. 羅性を確保し，明確化しなければならない．. 組織や業務目的のために，システムの設計・開発・保. 用目的に対する必要性と目的適合性，技術的な実現性，期. 守・運用に間接的に影響を及ぼす要求者や，何らかの. 間や費用の制約を考慮して要求分析を行い，最終的な仕様. 利用目的でシステムに影響を与える利用者，及び特定. 化を行う責任がある．一方，顧客はシステム設計者から提. の利用目的で，システムから出力される結果に影響を. 示されたシステム仕様の案に対して説明を求め，十分に理. 次に，システムの設計者は，システムに対する要求の利 2). ⓒ 2016 Information Processing Society of Japan. 2.
(3) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. 解する要がある．システムで実現する仕様に対して最終的. 分に行われていない．結果的に製品納入後，できあがった. な決定を下すのは顧客であり，顧客は，この決定に際して，. システムで，以下のような問題を引き起こしている．. 費用，期間にコミットし，システム設計者との合意が必要. ①効率性の視点を欠くと，ソフトウェア開発完了後に性能. である．そこで，ISO/IEC_25030 では顧客のシステムに対. 問題を引き起こし，開発期間や予算の超過が発生する．. する要求をできる限り網羅的，客観的に把握するために，. ②使用性の視点の欠如は，使い勝手の悪い使われないシス. JIS_X0129-1 の 6 つの品質特性の視点から収集し，さらに，. テムを実現し，投資が回収できないこともある．. これらの定性的な要求をソフトウェア製品に対する 6 つの. ③保守性の視点を欠くと，システム機能は動作しても，保. 品質特性の定義に基づいて識別し，6 つの品質特性に対す. 守・運用に膨大な労力と費用を費やし，かえって業務効率. る要求と，それ以外の要求に識別し，分類する．. を悪化させてしまう場合がある．そこで ISO/IEC_9126-1. この際に考慮しなければならないことは，顧客の要求は. :2001[4] （JIS_X0129-1:2003[5]）（ISO/IEC_25010：2011[6]. IT の技術的な制約により，実現できない要求であったり，. （JIS_X25010:2013[7]）に改訂）では, システムに対する顧. 利用者の嗜好であったり, 勘違い，実現費用を無視するな. 客の非機能要求に含まれる品質要求を従来あつた. ど，必ずしも適切で，妥当性のある要求とは限らない場合. B.W.Boehm[8]や J.A.McCall[9]のソフトウェア品質構造モ. もある．従って，システムデザイナーは，顧客の明示され. デルを利用者の視点から整理し，品質特性を図 1 に示すよ. た要求を網羅的に把握するだけでなく，暗黙の要求，意識. うに機能性，信頼性，効率性，使用性，保守性，移植性の. していない要求も含めて，把握し，ソフトウェアの実現に. 6 つの品質特性の視点から定義している．さらに，利用者. 向けて合目的性のある妥当性な要求を定義する必要がある．. はソフトウェア導入後の利用効果にこそ興味を持つことか. さらに，これらの合目的的な要求をシステムの実現に向. ら，利用時の品質を有効性，生産性，安全性，満足性の 4. けての諸々の技術的，費用的，期間的，製品競争力，利用. つの品質特性として定義している．システムの品質は，こ. 時に求められる品質レベルなどの視点から，適格に判断し，. の品質モデルの視点から，品質特性毎に対応する義測定法. システム要件として定義しなければならない．. を用いて要求を具体的に定義し，定量的に評価することで， その品質を保証し，改善することができると考えられる．. 3. システムの概念. 3.1. システムの属性. ISO/IEC15288[17]のシステムの定義によると，システム は「特定の目的のために複数の要素で構成される」となっ ているが，本論文では，これらの構成要素の最小単位を属 性と呼ぶ．通常，システムの属性は多数, 存在するが，シ ステムが保有する属性には，システム固有の属性と，シス テムに付加される属性の 2 つがある．さらに，システムの 保有する属性にはハードウェアの属性と，ソフトウェアの 属性が存在し，ハードウェアの属性とソフトウェアの属性. 図 1 システム製品の品質モデル -JIS_X0129:2003[4]. は，システムの利用目的に対する手段の視点からは，トレ 以下が 6 つの品質特性の定義である.. ードオフの関係がある．. ①機能性： 指定された条件の下で利用されるときに, 明示 3.2 システム品質の概念 システムに対する要求にはハードウェア属性に対する. 的及び暗示的必要性に合致する機能を提供する能力. ②使用性： 指定された条件の下で利用するとき, 利用者に. 要求と，ソフトウェアに対する属性が存在する．さらにシ. とっての使用しやすさの能力.. ステムの良し悪しには，システムに組み込まれたソフトウ. ③信頼性： 指定された条件下で利用するとき, 指定された. ェアの属性が大きく影響すると考えられる．. 能力が維持する能力.. 従来，製品の品質といえば，主に信頼性のことを指して いたが，ソフトウェアは多面的な性質を持つため信頼性だ けでは，ソフトウェアの品質全体を捉えることができない． ここで，ソフトウェア開発における品質要求定義の問題. ④効率性： 明示的な条件の下で, 適切な性能提供及び必要 な資源に関係する能力. ⑤移植性： ある環境から他の環境に移す際の適応力. ⑥保守性： メンテナンスや修正しやすさの能力.. 点について触れておきたい．これまでのソフトウェア開発. さらに，本論文では, 顧客の不満を網羅的に捉えるため. では，システムデザインの段階でソフトウェアに対する機. に，製品固有の属性の視点だけでなく，製品に付与された. 能要求を洗い出し，機能要求の定義は行われてきたが，非. 下記に定義する経済性も加えた.. 機能要求に含まれる品質要求の定義については必ずしも充. ⑮. ⓒ 2016 Information Processing Society of Japan. 経済性： コストパーフォーマンス. 3.
(4) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. 3.3 顧客満足度とシステムの品質特性及び属性の関係. 品質評価プロセスを経て，ソフトウェア品質評価報告書を. 図 2 にシステムの 6 つの品質特性及び経済性の視点から. 作成する流れとなる．ここで，評価のための制約条件は顧. 分類した顧客のシステムに対する要求（クレーム）[1]と品. 客のニーズに含まれる開発コストや期間への要求，支援基. 質特性別の顧客満足度の関係及び，顧客の品質特性別の要. 盤は ISO/IEC_2501n （n は規格の枝番号），ISO/IEC_2502n[20]. 求とシステムが実現すべき複数の属性との関係を示す．. 等の品質モデルや測定法から構成される．. ソフトウェア. 図 2 に示すように，実現されたシステムの固有の属性及. 開発プロセス全体における品質要求と評価の枠組み支援す. び付加された属性と顧客のシステムに対する品質特性別の. るために，現在，第 2 世代標準として策定を進めている. 満足度には密接な因果関係が存在すると考えられる．. SQuaRE 全体の規格の体系は，以下の大きく 5 つの部分か. そこで，顧客のシステムに対する要求を 6 つの品質特性. ら構成されている．. の視点から分類することで，6 つの品質特性別の顧客要求 を洗い出すことができると考えられる．. ①. ISO/IEC 2500n 品質管理部門. ソフトウェア品質の要求と評価技術全体の基本概念を 示し，標準の体系，SQuaRE シリーズ共通用語の定義， SQuaRE に基づき，品質の要求定義と評価を行うための計 画と管理に対する要求事項などを規定している． ②. ISO/IEC_2501n 品質モデル部門 ソフトウェア品質のモデルであり，ソフトウェアを利用. 者の視点から見た 6 つの品質特性 (機能性，使用性，信頼 性，効率性，保守性，移植性) ，品質副特性及びソフトウ 図 2 システム製品の属性と顧客満足度の概念[15]. ェア利用時の効果を評価する 4 つの品質特性（有効性，生 産性，安全性，満足性)について，規定する．. そこで，ISO/IEC_25030 では，これらの仮説に基づいて， システムが実現すべき固有の属性と付加された属性を，シ ステムに対する品質特性別の顧客満足度の視点から把握し， 抽出した属性には妥当性があると考えている．. ③ISO/IEC_2502n 品質測定部門 ソフトウェアの品質を測定するための内部品質測定法 （Internal Quality Measurement）．ソフトウェアの品質をシ ステムの振る舞いを通して測定する外部品質測定法 （External Quality Measurement）．ソフトウェアの利用時の. 4. ISO/IEC 25030 の概容. 効 果 を 測 定 す る 利 用 時 の 品 質 測 定 法 （ Quality in Use. 4.1 SQuaRE における ISO/IEC 25030 の位置づけ 現在，第 2 世代標準として策定を進めている ISO/IEC_25000 シリーズ（SQuaRE）[11-13]が想定するソフ トウェア開発プロセスの枠組みを図 3 に示す． 制約条件 要求、資源、時間、予算. ソフトウェア. 品質 要求 定義 プロセス. 開発. ④ISO/IEC_25030 品質要求部門 ISO/IEC_ 25010 で規定するソフトウェア品質モデル及び， ISO/IEC_2502n の品質測定法を利用して，ソフトウェアの 品質要求定義を行うための要求事項を規定している． ⑤ISO/IEC_2504n 品質評価部門[18-19]. 品質要求 ・評価仕様書 顧客の 品質 要求. Measurement）を定義する．. 品質 評価 プロセス. ソフトウェア. 品質評価 報告書. 品質モデルや品質測定法を用いて，ソフトウェア品質の 評価を行う場合の要求事項を規定する．. 評価対象 ソフトウェア. 4.2 規格の構成. 中間製品 最終製品. ISO/IEC_25030の目次構成を図4に示す．第5章にソフト 各種ソフトウェア品質評価技術 ISO/IEC １５２８８システムライフサイクル. 2. 図 3 ソフトウェア開発プロセスの枠組 み [9]. 顧客のニーズは品質要求定義プロセスを経て品質要求 仕様書に変換され，さらに品質要求仕様書に基づき開発さ れた評価対象ソフトウェアと品質評価仕様書を入力とし，. ⓒ 2016 Information Processing Society of Japan. ウェア品質要求定義の前提となる利害関係者やシステムの 基本概念，第６章に品質要求を仕様化するための基本要求 事項を規定している．ソフトウェアの品質評価では，既に 存在するソフトウェアの属性に着目し，ソフトウェアの品 質を評価すればよい．一方，ソフトウェアの品質要求定義 では，諸々の利害関係者からの要求が必ずしもソフトウェ. 4.
(5) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. アのみに限定されない．. ソフトウェア品質の要求と評価には表裏一体の関係が. 1 Scope 2 Conformance 1 Scope 3 Normative references 2 Conformance 4 Terms definitions 3 and Normative references 5 品質要求の基本概念 4 Terms and definitions 5 品質要求の基本概念 5.1 ソフトウェア及びシステム 5.1 ソフトウェア及びシステム 5.2 ステークホルダーとステークホルダーの要求 5.2 ステークホルダーとステークホルダーの要求 5.3 ステークホルダー要求及びシステム要求 5.3 ステークホルダー要求及びシステム要求 5.4 ソフトウェア品質モデル 5.4 ソフトウェア品質モデル 5.5 ソフトウェアの特質 5.5 ソフトウェアの特質 5.6 ソフトウェア品質測定モデル 5.6 ソフトウェア品質測定モデル 5.7 ソフトウェア品質要求 5.7 ソフトウェア品質要求 5.8 システム要求の分類 5.8 システム要求の分類 5.9 品質要求のライフサイクルモデル 5.9 品質要求のライフサイクルモデル 6 品質要求に対する要求 6 品質要求に対する要求 6.1 一般要求事項とその前提 6.1 一般要求事項とその前提 6.2 ステークホルダー要求 6.2 ステークホルダー要求 6.3 ソフトウェア要求 Annex A (normative) Terms and definitions 6.3 ソフトウェア要求 Annex Annex B (informative) Processes from ISO/IEC 15288 Bibliography Bibliography. 図 4. ある．開発初期の段階で，下記の3つの測定法に基づき，ソ フトウェアに対する定量的な品質目標を定義することがで きれば，この全く同じ視点から，ソフトウェア品質の評価 を行うことができる． 基本概念. 基本要求事項 25030より引用. ①. 「利用時の品質測定法」による利用時品質の評価. ②. 「外部品質測定法」による外部品質の評価. ③. 「内部品質測定法」による内部品質の評価. 4.4 システムへの要求の構造 4. システム全体の品質モデルの概念に基づき， ISO/IEC_. JIS X25030 の目次構成 [9]-ISO/IEC X25030[7-8]引 用. 25030に規定したシステム要求の構造を図7に示す．. そこで， ISO/IEC_25030では，ビジネスプロセス，シス. 諸々の利害関係者が持つ問題点や課題から派生したシ. テムに対する要求も含めて，ソフトウェアを含む広義のシ. ステムに対する明示的，暗黙的ニーズから，ソフトウェア. ステム全体の品質モデルの明確化が必要となり，システム. への要求を抽出する．ソフトウェアに対する要求は，機能. の領域に踏み込んで定義した． ISO/IEC_25030に規定され. 要求と非機能要求に分解することができる．非機能要求は，. た，ソフトウェアを取巻くシステム全体の品質モデルを図5. さらにソフトウェアに対する品質要求と，それ以外の価格. に示す．システム全体の品質モデルでは，ソフトウェアを. や納期などの要求に細分化できる．. コンピュータシステムの構成要素の一部とみなし，ソフト ウェア以外のハードウェアやデータの品質モデル，情報シ. 機能要求. ステムを取り巻く人間系業務プロセス，機械系システムな どの品質モデルの相互の位置づけなどを示している． ソフトウェア 品質モデル. 利用時の 品質モデル. その他 のシステム（ﾋﾞｼﾞﾈｽシステム・ガバメントシステム・組 込みシステム）. システム. シ ス テ ム へ の 要 求. ソ フ ト ウ ェ ア へ の 要 求. 情報システム コンピュータシステム 評価対象 ハードウェア. 評価対象 ソフトウェア. 評価対象 データ. 人間系 プロセ ス. 機械系 システム. ソフトウェア 以外 に対する要求. ソフトウェア 製品への 要求. ソフトウェア 固有の 特質への 要求. 利用時品質への要求 ソフトウェア. 品質 要求. 外部品質への要求. 内部品質への要求 付加された 特質への要求. 開発への 要求. 価格、納、製品の将来性、供給ベンダー などに対する管理的な要求. 開発プロセスへの要求 開発組織への要求. コンピュータハードウェア、データ、機械部品、 人的ビジネスプロセスを含む要求など. 7. 図 7 システム要求の 構造 [9]. 4.5 品質要求定義のプロセス その他の 品質モデル. ハードウェア 品質モデル. 図5. データ 品質モデル. 人 間系 プロセスの 品質 モデ ル. 機械 系 シ ステムの 品質モデル. システム全体の 品質モデルの概念 [9]. ISO/IEC_25030に規定されたソフトウェア品質要求と評. トウェア機能に対する要求，人間系業務プロセス対する要. ニー ズ. 求などに分解する．. 製品 検証. 仕様化. 利用時の品質. 利 用時 の 品 質. 評価. 仕様化. ソフトウ ェア 品 質要 求. 検証 外部品質. 評価. の品質に対する要求と，ソフトウェア品質以外のハードウ. 確認. ェア品質に対する要求などに識別する．. 決定 内部品質 測定法. 次に，抽出したシステム品質に対する要求を ISO/IEC 2502n：ソフトウェア品質測定法の視点から，ソフトウェア. 決定. 外部品質 測定法. ISO/IEC_25010：ソフトウェア品質モデルの視点から仕訳し， システムの品質に対する要求と，システム品質以外のソフ. 価のライフサイクルの概念を図6に示す．. 要求. まず，諸々のニーズ全体を洗い出す． 次に図7に示すように，洗い出したニーズを. 4.3 ソフトウェアライフサイクルモデル. 利用時の 品質測定法. 図 8 に，ISO/IEC_25030 に規定されたソフトウェア品質 要求定義プロセスを示す．. 仕様化. ソ フ トウ ェ ア 品質要求. 内部品質. 評価. 確認. こで，ソフトウェア品質要求については， ISO/IEC_25010：ソフトウェア品質モデルの6つの品質特性，. 実装. 図6. ソフトウェアラ イフサイクル [9]. 副特性の視点から要求の過不足を明確化すると共に，要求 の網羅性を確保し，ISO/IEC_2502nの品質測定法に基づいて，. ⓒ 2016 Information Processing Society of Japan. 5.
(6) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. 各品質特性，副特性毎に具体的な測定法を選択し，定量的. e.測定法の選定，f. 測定のための判定基準の明確化，g.. な品質目標と評定水準を定義する．各品質特性，副特性に. 評価のための判定基準の明確化を実施する．このプロセス. 対応する測定法毎に設定した具体的な品質目標を，品質要. では，e.f.g.の全てのアクティビティで，ISO/IEC_25030を. 求仕様書として仕様化する．以上が要求定義プロセスの概. 活用した定義済の品質目標，品質測定法を再利用すること. 要であり，ISO/IEC_25030にはアクティビティ毎に，ソフト. ができる．. ウェア品質モデルの視点から適切な品質要求定義のための 要求事項を規定している．. ③ 評価の設計 h.品質評価計画の作成を行う．品質評価計画書には，前. ニーズ. システム に対する 要求. 要求. 要求抽出 プロセス. ステーク ホルダー からの 品質 に対する ニーズ. ソフトウェア に対する 要求. 要求分析 プロセス. ステーク ホルダー からの 品質 に対する 要求. ISO25010 ソフトウェア. 品質 モデル. ソフトウェア の品質 に対する 要求 ISO2502n ソフトウェア. 品質 測定法. システム品質 に対する要求. 記，評価の仕様化で明確化した品質目標や評価項目，品質 測定法，判定基準などが含まれる． ④評価の実施 評価の仕様化で明確化した品質要求や評価項目，品質測 定法，判定基準などを活用して i. 測定，j. 測定のための判 定基準の適用，k.評価のための判定基準の適用を行う． ⑤評価の終結. 図 8 品質要求定義の プロセス -JIS X25030引 用. 本規格はソフトウェア品質要求定義プロセスとして， ISO/IEC_15288：System Life Cycle Processes（システムライ フサイクルプロセス）に規定されたシステムの要求定義や 分析プロセスも参照している． 4.6 システムデザインの品質の評価 図9にISO/IEC_25030に準拠して，品質要求定義が行われ た場合のソフトウェア開発で想定できる品質評価のための プロセスを示す． 評価要求の定義. 評価の仕様化. l. 評価結果の審査，m.評価報告書の作成，n.評価データ の蓄積を行う． 一般的に，システムデザインの良し悪しの評価は，要求 者や設計者，第三者の評価者によって，製品の利用時に行 われる．一方，「源流管理」の考え方に基づけば，開発初 期のシステムデザインの段階でも，要求者と設計者との間 におけるシステムに対する品質要求に関する合意の形成， 設計者による実現システムの要求定義の目的適合性と実現 性の見極めが重要である．ここで，開発前のシステムデザ インでは，品質要求仕様書に仕様化された実現要件（シス. a. b. c. d.. 評価目的の確立 ソフトウェア製品評価要求の取得 評価対象製品の 特定 評価の 厳格性の定義. e. 測定法の選定 f. 測定のため の判定基準の明確化 g. 評価の ための 判定基準の明確化. 評価の設計. h. 評価計画の 作成. 評価の実施. i. 測定 j. 測定のため の判定基準の適用 k. 評価のため の判定基準の 適用. 評価の終結. l. 評価結果の審査 m. 評価報告書の作成 n．評価データの 蓄積. 図 9 ソフトウェア品 質評価のプロセス. テムが保有すべき属性）の妥当性を利用時の品質測定法， 外部品質測定法，内部品質測定法の視点から評価すること ができる．品質要求定義では品質測定法に基づく定量的な 品質目標の明確化と仕様化が可能である．又，品質評価で は，評価対象ソフトウェアを品質評価仕様書に記述された 品質測定法を用いて測定し，設定した品質目標値と測定値 との差異を分析することによって可能である． 上記のプロセスにより，ISO/IEC_25030 に準拠して仕様 化された品質要求仕様書の存在を前提とするシステムデザ インの品質要求に対する評価作業が可能になる．. ① 品質要求の定義 ソフトウェア品質の評価に対する要求の定義では，図9 に示す，a.ソフトウェア評価目的の確立 ，b.ソフトウェア への品質要求の取得，c. 評価対象ソフトウェアの特定，d. 品質評価の厳格性の定義などを実施する必要がある．. 5. システムデザインへの適用 5.1 システム要求定義における適用 ISO/IEC_25030 は非機能要求に含まれる品質要求の定義 を主目的とするが，その基本概念は，機能要求の分析，網. このプロセスでは，b.c.d.のアクティビティで，既に，. 羅性の確保などにも適用できると考えられ，システムデザ. ISO/IEC_25030に準拠して設定された品質目標の存在を前. インの品質や生産性の向上に利用できる手段として有効性. 提とした作業が可能となる．この結果，評価仕様の作成が. が高いと考えられる． システムデザインでは，顧客の要求. 容易になり，大幅な作業精度の改善が期待できる．. に対してシステムが実現すべき固有の属性と付加された属. ② 評価の仕様化. 性を具体的に定義する必要がある．さらに，定義された固. ⓒ 2016 Information Processing Society of Japan. 6.
(7) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. 有の属性と付加された属性には，与えられた制約の中で実. 目的とするものと，品質確保を目的とするもの，及び，そ. 現性が確保されていなければならない．すなはち，システ. の両方をカバーするものが存在すると考えられる．そこで，. ムデザインでは，システムに対する要求の定義（機能と非. 洗い出された品質要求を達成するために必要な機能要求の. 機能要件の設計）と，定義された要求を実現するための実. 抽出も必要と考えられる．次に，新たに実現するシステム. 装方法の定義（実現方式の設計）が必要となる．. の機能が，既存のシステムが実現している機能を下回らな いようにするためには，類似したシステムや既存のレガシ. 1). 要求の抽出. ーシステムが保有する機能を参考にして，機能の漏れを防. システム要求定義プロセスでは，機能要求の定義につい. ぐ必要がある．又，このプロセスでは，ソフトウェアに対. ても，品質要求定義と同様のアプローチで機能要求を抽出. する要求以外のハードウェアや業務に関する要求とソフト. できると考えられる．ここで，ISO/IEC_25030をソフトウェ. ウェアに対する要求の間に，トレードオフの関係が存在す. ア品質以外の機能要求に適用した場合のプロセスを紹介す. るため，ソフトウェアに対する固有の機能要求の必要性に. る．システムに対する機能要求の定義プロセスは，ソフト. 付いてのハードウェアや業務処理による代替機能実現の可. ウェア品質に対する要求と同じように，顧客からの機能要. 能性も含めて，ハードウェアや業務担当者などの専門家を. 求の抽出と機能要求分析の2つのプロセスが必要と考えら. 交えた慎重な検討による決定プロセスがと考えられる．. れる．表2はISO/IEC25030のシステムに対する要求抽出の適 用事例を示している．まず機能要求の抽出では，利用者や. 最終的な機能要求の特定には，システムデザイナーの優れ た洞察力やバランス感覚が必要になる．. オペレータなど，対象システムの直接的な利害関係者だけ ではなく，得意先や株主，経営者等を含む間接的な利害関. 2). 要求の分析. 係者のニーズを広範に把握し，ニーズに基づいて，表2に含. 要求の分析では，システムの実現に向けた技術的，管理. まれる要求のカテゴリーに対する諸々の要求を特定する．. 的な制約の視点を踏まえて，システム化への要求を具体化. 要求の定義では表 2 に示す要求のカテゴリーに対応して，. する．機能及び品質を実現するための実装方法の設計では，. 顧客が欲する自らの要求を認識し，網羅性のある要求を洗. アーキテクチャが機能及び品質目標を達成する上での実現. い出すことにより，暗黙的要求や意識しない要求を定義で. 手段として，相応しいか否かという視点からのデザインが. きる可能性がある．. 重要である．システムは様々な構成要素から構成されるた. 一方，設計者は顧客の要求に網羅性が無い場合でも，同. め，ソフトウェア以外のハードウェア，データ，機械系の. 様のアプローチで暗黙の要求や意識しない要求を把握し，. システム，人間系の業務処理プロセスや組織体制に対する. 定義できる可能性がある．さらに，このプロセスでは，. 要求も対象となり，それぞれの属性に対応した要求定義の. ISO/IEC_9126-1に規定されたシステム品質モデル及び6つ. 手法によって具体化する必要がある．そこで，. の品質特性の視点からのソフトウェア品質要求及び機能要. ISO/IEC_25030の適用では，システム要求の分類に対応する. 求の洗い出しにより，要求の抜けや漏れを防ぐためのチェ. 要求に対して，表2の左欄に示す標準や他の構成要素に関す. ックリストとして活用できる．又，この段階では，システ. るデザインの視点から定義できると考えられる．. ムに対して顧客が明示した要求だけでなく，暗黙的な要求， 意識しない要求の存在も考慮して，網羅的に要求の洗い出. 6. おわりに. しを行う必要があり，システムデザイナーの過去の類似シ. 本論文では顧客満足度の高いシステムを実現するため. ステムのデザイン経験や能力，複数の専門家からの要求の. に，システムが具備すべき属性を諸々の利害関係者の要求. 把握と必要性の可否に対する意見の集約が必要になると考. に基づいて定義するプロセスにISO/IEC_25030の品質要求. えられる．顧客が自らの要求に気づかずにシステムを利用. 定義プロセスの概念を適用し，思考実験の結果，その有効. し，業務を試行して初めて気づく意識しない要求を特定す. 性を検証した．顧客満足度の高いシステムを実現するため. るためには，シナリオ，ユースケース，プロトタイピング. には諸々の利害関係者の視点から，システムデザインの段. 等の手法を用いるアプローチも有効と考えられる．要求抽. 階でシステムに対する過不足の無い機能及び非機能要求，. 出のプロセスでは，表2に示すようにシステム対する諸々の. その他の要求を，システムプロダクトの構成要素として定. 利害関係者からの要求の中から，ソフトウェアに対する要. 義するシステムズ・エンジニアリングのアプローチに効果. 求だけでなく，それ以外の要求も洗い出す必要がある．さ. が期待できると考えられる． このような視点から見ると，. らに，ソフトウェアに対する要求については，要求の中か. 近年，取り組まれているスパイラルやアジャイル開発な. らソフトウェアに対する固有の要求と付加される要求を洗. どの開発者がシステムデザインの要求定義の品質向上を放. い出し，ソフトウェアに対する固有の要求から品質要求を. 棄した取り組みは，システムデザイナーの利用目的や適用. 除くことにより，ソフトウェアに対する固有の機能要求が. 業務に関する知識や経験及び能力や洞察力の不足に起因す. 鮮明になる．ここで，ソフトウェアの機能には業務処理を. るとも考えられる．. ⓒ 2016 Information Processing Society of Japan. 7.
(8) 情報処理学会研究報告 IPSJ SIG Technical Report. Vol.2016-IS-137 No.7 2016/8/26. 表 2 システムに対する 要求の分類，及 び対応する要求定義書の構成 と設計 視点の適 用 例 システム要求事項 の分類 ソフトウ ェアへ の 要求. ソフトウ ェア 製品 そ のもの への 要求. システムへの要 求. ソフトウ ェア開 発要求 その他 のシス テム への 要求. 固有の 属性 へ の要求. 付加さ れた 属 性へ の 要求. 機能要求 非 品質への 利用時品質要求 機 要求 外部品質要求 能 内部品質要求 要 管 製品の将来性 求 理 経済性 初期導入費用. 的 への 保守費用 側 要求 運用費用 面 納期に対する要求 開発プロセスへの要求 保守・サービスプロセス に対する要求 供給者への要求. コンピュータ，ハードウェア 機械・設備への要求 データへの要求 人手による業務プロセスへの要求．. 近年，システムの品質・生産性の向上策として，システ ムライフサイクルプロセスに着目し，プロセスを改善する 取組みが活発である．しかしながら，システムデザインの 改善は本質的にデザインプロセスで定義された要求と結果 的に実現されたシステムの顧客満足度との関係を解明する ことで，はじめて可能と考えられ，今後，プロダクト志向 のシステムデザインアプローチが重要と考える． 参考文献 1) 江崎和博，システム品質モデルに基づく自動車の顧客 不満足度推定手法の開発，電子情報通信学会論文誌， vol.J98-A，no.9，pp.563-570 (September 2015) 2) Esaki，K.，Analysis of Influence of Price to Customer Satisfaction Based on the Prediction Models，Intelligent Information Management，vol.5，no.3，pp .93-102 (May 2013) 3) Esaki，K.，Global Assessment Method for System Quality， American Journal of Systems and Software，vol.1，no.1， pp.11-20 (May2013) 4) ISO/IEC 9126-1: Software engineering-Product QualityPart1: Quality model (2001) 5) 日本規格協会:JIS X 0129-1 第 1 部:品質モデル (2003) 6) ISO/IEC 25010: System and software engineering-System and software Quality Requirements and Evaluation (SQuaRE)- System and software quality models (2011) 7) 日本規格協会:JIS X 25010: システム及びソフトウェ ア製品の品質要求及び評価（SQuaRE） ― システム及 び品質モデル (2013) 8) Boehm,B.W.et al,Quantative Ev. of Software Quality,2nd ICSE pp.596-605,1976 9) McCall,J.A.et al,Factors in Software Quality,RADC TR-77369,1977 10) 江崎和博,ISO/IEC9126 のシステム品質特性に基づく要 求定義手法の開発,研究報告 情報システムと社会環 境,IPSJ 情報システムと社会環境研究会, 第 120 回研究 発表会,vol.2012-IS-120, no.2,pp.1-7 (Jun_2012). ⓒ 2016 Information Processing Society of Japan. 適用できる視点 ・ 手法 ISO/IEC25030 ISO/IEC25030 ISO/IEC2501n ISO/IEC2502n. の要求定義プロセス，3 次元統合価値モデル[21-22] の品質要求定義プロセス，3 次元統合価値モデル の品質特性の視点 の品質測定法の視点. 競合製品のベンチマーク 設備導入計画，経済性工学 CCOMO 競合製品のベンチマーク， PMBOK(WBS) ISO/IEC12077 のソフトウェアライフサイクルプロセスの視点 ISO/IEC15288 のシステムライフサイクルプロセスの視点 SLA 供給者の競合とのベンチマーク，TQM 機械設計，建築のデザインと同様のアプローチ 機械設計 ISO/IEC25012 のデータ品質の視点 ISO/IEC25024 のデータ品質測定法の視点 BABOK，ビジネスプロセス，業務設計. 11) ISO/IEC 25000: Software engineering–Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE，Int’l Organization for Standardization (2005) 12) 日本規格協会:JIS X 25000: ソフトウェア製品の品質 要求及び評価（SQuaRE） ― SQuaRE の指針 (2010) 13) 江崎和博,坂本健一,安原典子,システムおよびソフトウ ェアの品質評価- SQuaRE 適用の実際と今後の展開,情 報処理学会 情報処理：特集 システムとソフトウェア の品質, vol.55, no.1,pp.24-30 (January 2014) 14) ISO/IEC 25030: Software engineering–Software product Quality Requirements and Evaluation (SQuaRE)–Quality requirement，Int’l Organization for Standardization (2007) 15) 日本規格協会:JIS X 25030: ソフトウェア製品の品質 要求及び評価（SQuaRE）品質要求事項 (2012) 16) 江崎和博，ソフトウェア開発の品質，生産性向上に向 けた ISO/IEC 25030 制定の意義，情報処理学会誌ディ ジタルプラクティス，vol.1, no.2,pp.94-100 (April 2010) 17) ISO/IEC15288: Systems and software engineering -System life cycle processes- System Life Cycle Processes, Int’l Organization for Standardization (2008) 18) ISO/IEC 25040: System and software engineering-System and software Quality Requirements and Evaluation (SQuaRE)- Evaluation process (2011) 19) ISO/IEC 25041: System and software engineering-System and software Quality Requirements and Evaluation (SQuaRE) - Evaluation guide for developers, acquirers and independent evaluators (2012) 20) ISO/IEC 25020: Software engineering–Software product Quality Requirements and Evaluation (SQuaRE)– Measurement reference model and guide，Int’l Organization for Standardization (2007) 21) Esaki ， K. ， Three Dimensional Integrated Value Models Based on ISO/IEC9126 System Quality Model，American Journal of Operations Research， vol.3，no.3，pp.342-349 (May2013) 22) 江崎和博，3 次元統合価値モデルに基づく要求定義手 法の提案，研究報告 情報システムと社会環境，IPSJ 情報システムと社会環境研究会，第 121 回研究発表会， vol.2012-IS-121 ， no.2 ， pp.1-8 ， 甲 南 大 学 ， (September2012). 8.
(9)
関連したドキュメント
水道水又は飲用に適する水の使用、飲用に適する水を使
Iso= 0.8 × 0.8 × 1.00 = 0.64
あらまし MPEG は Moving Picture Experts Group の略称であり， ISO/IEC JTC1 におけるオーディオビジュアル符号化標準の
LC06111TMT Battery Protection Controller with Integrated MOSFET, 1-Cell Lithium-Ion LC05711ARA Battery Protection Controller with Integrated MOSFET, 1-Cell Lithium-Ion
*1) ISO 4414: Pneumatic fluid power -- General rules relating to systems ISO 4413: Hydraulic fluid power -- General rules relating to systems.. IEC 60204-1: Safety of machinery
[r]
12―1 法第 12 条において準用する定率法第 20 条の 3 及び令第 37 条において 準用する定率法施行令第 61 条の 2 の規定の適用については、定率法基本通達 20 の 3―1、20 の 3―2
スタンドアロン モードでの Cisco DCNM ISO のインストール 46 ネイティブ HA モードで Cisco DCNM ISO をインストールする 50.. Cisco APIC SE で Cisco DCNM
