2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2008年8月 | トップページ | 2008年11月 »

2008年10月

2008年10月31日 (金)

【定量的品質予測のススメ】テストに関する測定データの曖昧性は低いか

P28「3.1.1 目的と狙い」において「レビューはテストとは異なり人間的要素が強く、測定基準を設定したとしても、測定データに曖昧性が多く、バラツキガ大きいことが原因である。つまり要求分析・設計の品質予測では、このような人間的要素を、レビューアの質を揃えることや、チェックリストを活用すること等でぶれの少ない数値に変換することがポイントになる」とある。

この記述では、測定データの曖昧性は、テストではあまりないようにみえるが、そうであろうか。

テスト項目1件と言った時の1件とは何を指すかからして曖昧であると思える。
統計的に評価するには、ある1件と別な1件が統計処理において同じ価値をもたねばならないと思うが、そのようにテスト項目を洗い出し計上することは可能であろうか。

本書で再三取り上げられている、信頼度成長モデルであるが、横軸に、時刻を取るにしろ、消化テスト項目を取るにしろ、テスト工数をとるにしろ、どれも測定が曖昧ではなかろうか。左から右へ均一な軸としてデータをみていくことに何の問題もないのであろうか。

時刻では、準備や実際のテスト、結果の評価に時間を要するテストもあればそうでないものもあるが、それも無視して例えば1日はどこで区切っても等価な1日の価値を持つ見なしてよいのであろうか。

消化テスト項目にしても、1件と数える単位もしくは切り口は同じと言えるのであろうか。

テスト工数の場合も、時間と同様、準備や実際のテスト、結果の評価に工数を要するテストもあればそうでないものもあるが、それも無視して例えば1人日はどこで区切っても等価な1人日の価値を持つと見なしてよいのであろうか。

どんなに時間・テスト項目・工数を増やしても、プログラムの中でテストしていない部分があれば、グラフが寝ようが寝まいが関係なくテストすべき事項が残っているはず。

信頼度成長モデルは、一見有用に思えるが、その意味するところを理解しないと危険なツールである。
なぜグラフは初期段階で急に立ち上がり(S字形の場合は一旦もたついた後立ち上がり)、後半で収束するのか。
テストケースは、どう取るべきかについて、少なくとも本書では、さらりと触れられている場所はあるが、具体的記述はない。

ただ、開発を委託する側に「もうこんなに収束していますので」と納得させるには良いツールであろう。
こむずかしい数式や直感的には納得しそうなグラフを見せることでで、開発を委託する側をけむにまくことは可能であろうから。

信頼度成長モデルについては、別途記述する予定である。

【共通フレーム2007】「次の計画された活動の準備ができている」ことの確認は「技術レビュー」なのか

P168「2.6.3.1 技術レビューの実施」では「検討中のソフトウェア製品又はサービスを評価し、次の事項を明らかにするために、技術レビューを実施する」とある。

そして列挙される「次の事項」の1つに「(e)次の計画された活動の準備ができている」がある。

これは「技術レビュー」の対象なのであろうか。

1つ前の「2.6.2 プロジェクト管理レビュー」の方がしっくりする感じがする。

2008年10月30日 (木)

【定量的品質予測のススメ】ソフトウェア開発の品質データが正規分布に従う確率

P27「2.3.7 モデル利用上の注意点 (2)入力データのチェック」において「母集団が正規分布に従う場合、±3σをわずかに超えたデータは管理限界を超えたデータではあってもモデルの対象外のデータとは言えないことが多い。それに対して、±6σを超えるものは明らかに特異なデータとみなすことができるであろう」とある。

P20「コラム モデル化時の注意点」において、「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」と書かれている。

この2つの文が同一の書籍に書かれていることを念頭において本書は読まなければならないことに注意を要する。

ただ、この二つの文が両立しないわけではない。
前者が、「母集団が正規分布に従う場合」という条件を付けており、後者では「正規分布にならない場合が多い」と言っているだけだと解釈すればよいのだから。

しかし、「母集団が正規分布に従う場合」がそうそうあるとは思えないことは、本書が既に書いていることである。

【共通フレーム2007】予定の節目で、定期的なレビューとは

P167「2.6.1.1 レビューの実施」では「プロジェクト計画で指定された予定の節目で、定期的なレビューを実施する。どちらか一方が必要と考えるときは、臨時のレビューを実施することが望ましい」とある。

「予定の節目で、定期的なレビュー」とは何であろうか。

予定の節目でのレビューというのは、普通、工程の区切り等に実施されるものが想定される。
定期的なレビューというのは、普通、プロジェクト進捗とは別に定められた期間間隔で実施されるものが想定される。

「予定の節目で、定期的なレビュー」というのは、上記2つの要素を兼ね備えたレビューと読めるのであるが、わざわざ兼ねたレビューに限る必要はなかろう。

「プロジェクト計画で指定された予定の節目にレビューを実施すると共に、定期的にレビューを実施する。どちらか一方が必要と考えるときは、臨時のレビューを実施することが望ましい」
と書いても構わないはずである。

2つの要素を兼ね備えたレビューもこの中に含まれるのであるからこちらの方が良いと思う。

2008年10月29日 (水)

【定量的品質予測のススメ】無理に指標を定める価値

P26「2.3.7 モデル利用上の注意点 (1)管理限界の設定」において、「もし十分な蓄積データがない場合は」として、2番目に「②既存の品質管理ツールで設定されている値を用いる」とある。

無理にツールを使うメリット・デメリットを書かずに、あっさり「既存の品質管理ツールで設定されている値を用いる」と書いて良いのだろうか。

P20「コラム モデル化時の注意点」の「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」という記述がある同じ書籍の中で「もし十分な蓄積データがない場合は」「既存の品質管理ツールで設定されている値を用いる」などと、どうして簡単に奨められるのであろう。

「十分な蓄積データがない場合」には無理に管理限界を設定する必要が無いと言う判断もあると思うのだが。

しかし、本書は違う。
何が何でも管理限界を設定しなければならないと考えているようだ。

「もし十分な蓄積データがない場合」としての3番目に「③品質管理担当者やプロジェクト管理者の経験から暫定値を設定する等の方法でとりあえずの値を設定し、組織内のデータの蓄積と共に値を修正することが現実的であろう」と書かれている。

「とりあえずの値」を設定することのメリットよりデメリットの方が多いと言うことは考えられないのであろうか。

とりあえずやってみる。
これが「定量的品質予測のススメ」のスタンスである。

先に引用したP20のコラムを考えれば、「とりあえずの値を設定し、組織内のデータの蓄積と共に値を修正」しようとしたら、値が発散しすぎて何がなんだか分からなくなったというケースが出てきそうに思われる。

そして、ここが一番重要なのであるが、それが分かるまでの間、その「とりあえずの値」に基づいて実際のプロジェクトが管理されることになるのだが、このことに何の益があるのであろうか。

「値が発散しすぎて何がなんだか分からなくなった」と分かるまでは、「とりあえずの値」をモノサシに管理限界を超えた場合に是正措置を検討することは意味のあることなのであろうか。

ソフトウェア開発プロジェクトは、管理限界の精緻な設定を目標にしているのではない。
開発すべきソフトウェア作成を計画通り・要求通りに完了させることである。

「とりあえず定めた管理限界の値ではあるが、プロジェクトにおいて管理限界を少しでも超えた場合は、必ず対策を取ってください」ということのメリットを正当に説明できない管理限界は、いらない。

無理に指標を定める価値は何であろう。

品質だとなんとなくイメージできないかもしれない。では、利益指標を考えてみればよい。
業界の売上高対比平均営業利益率は何パーセントだから当社もそれを採用するので、これを下回る場合は必ず対策を取ってくださいということに違和感はないか。

「目標」「目安」に使うには良いかもしれない。しかし、管理限界のような「管理指標」として使う場合は、よくその値の精度を考慮して用いなければならない。

【共通フレーム2007】共同レビューに関する3つの説明

P166「2.6 共同レビュープロセス」では共同レビューを行う期間に関する記述が3個所で書かれている。

本文中その1
「共同レビューは、プロジェクト管理レベル及び技術レベルの沿う方で、プロジェクトの存在する間行われる」

本文中その2
「契約が有効である間は、共同レビューを実施する」

ガイダンス
「共同レビューは、管理面と技術面の両方からなり、契約期間中開催される」

同じページの中で、何度も、しかも、内容をばらばらに記述する必要があるのだろうか。
一度書けばそれで良い気がする。

もちろん3つとも意味が異なるというのであれば、都度言及する必要があるが、そうであればすべてを「共同レビュー」という語で説明するのではなく、それぞれ語を使い分けるべきである。

2008年10月28日 (火)

【定量的品質予測のススメ】管理限界±3σの攻防

P20「コラム モデル化時の注意点」において、「ソフトウェア開発では複数の要因(特に人的要因)が大きく影響するため、測定値に大きなバラツキが出る(すなわち分布の山がなだらかな)傾向が有り、しかも正規分布にならない場合が多い。したがって、実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」と書かれている。

これは、開発に従事する者にとっては、何をいまさらと言う当たり前の話である。

しかし、これをわざわざコラムとして書いていることに注目すべきである。

特に、この「定量的品質予測のススメ」を読んでこれから品質を測るぞと気負っている組織には、くどいほど肝に銘ずるべきである。

繰り返すが、これは、開発に従事する者にとっては、何をいまさらと言う当たり前の話である。
そして、これを踏まえて、P27、P43、P82~83を読まねばならない。

定量的品質予測の世界において、「実際の現場では管理限界±3σでは範囲が広過ぎて利用できないことが多い」は、何をいまさらと言う当たり前の話ではないのかもしれない。

だから、わざわざ書いているのである。

しかし、なぜ本文ではなくコラムとしてなのだろうか。
ちなみに、P27、P43、P82~83は本文に書かれている。

本書の編集に参加した方々の中での意見の衝突があったのではないかと伺える。

【共通フレーム2007】「実環境の領域」と「適宜テスト」

P165「2.5.2.5 実環境でのテスト」では「実環境の領域をいくつか選び出し、ソフトウェア製品を適宜テストする」とある。

「実環境の領域」とは何であろうか。

また、具体的に何をテストするかに関する記述が「適宜テストする」だけでは、淡白すぎると感じる。
ただし、テストに関しては、語るべきことが多すぎて、これ以上踏み込んだ説明を、共通フレームの中で、簡潔に記述することはそもそも無理なのかもしれない。

2008年10月27日 (月)

【定量的品質予測のススメ】代表的名例の例

P14「2.2.2 測定量」において「ここでは、代表的な基本測定量(・・・略・・・)と導出測定量(・・・略・・・)の例を図表2.2-2に示す」とあり、
続く文で「図表2.2-2の『測定方法/算出方法』は例として記載している」とある。

       「基本測定量と導出測定量」
でなく、
       「基本測定量と導出測定量の例」
でもなく、
   「代表的な基本測定量と導出測定量」
でもなく、
   「代表的な基本測定量と導出測定量の例」
であり、更に、
   「代表的な基本測定量と導出測定量の例」として示した「図表2.2-2」の中の「『測定方法/算出方法』は例として記載」
というように、その例の中に記述されたものが更に例であると書かれている。

これは何を示すか。

P6「1.1 今、品質確保が急務」で書かれているように、「開発途中の品質は、標準化された評価には至っていない」ことを本書のこの部分でははわきまえているということを意味する。
「基本測定量と導出測定量の『測定方法/算出方法』は図表2.2-2に示す通り」と書きたいが、書けない、断言する自信がないということが、この記述から読みとれる。
「代表的」と「例」という飾りを付けただけでは足らず、更に「例」ということを書き加えるほどなのである。

「定量的品質予測のススメ」と言われても腰が引ける読者も出るのではないであろうか。
とはいえ、書かれている内容に意味が無いとは思わない。せっかくの記述なのであるから、
   「代表的な基本測定量と導出測定量」として示して「図表2.2-2の『測定方法/算出方法』は例として記載」
とすれば未だ良かった気がする。更には、
   「代表的な基本測定量と導出測定量」として示して「図表2.2-2の『測定方法/算出方法』は例として記載」は書かなくても良い
と思われる。

【共通フレーム2007】「代表利用者」とは

P165「2.5.2.3 テストの実施」の(c)には「代表利用者」という語が使われている。
この語は説明なしに使われているが、どのような者を指すかは自明なのだろうか。

ガイダンスで説明されるべきであろう。

2008年10月26日 (日)

【共通フレーム2007】「テストを行う」と「支援要請である」との結びつき

P165「2.5.2.3 テストの実施」の(b)では「ソフトウェア製品から誤りの影響を分離し、最小化することができるかどうかのテストを行う。すなわち、故障時の穏やかな機能縮退、重負荷・境界状況・異常状態時の運用者への支援要請である」と書かれている。
この中での2つの文は、「すなわち」でつながれている。
通常「すなわち」は、第1の文を第2の文でわかりやすく説明する場合に使われる。

しかし、
「ソフトウェア製品から誤りの影響を分離し、最小化することができるかどうかのテストを行う」
と、
「故障時の穏やかな機能縮退、重負荷・境界状況・異常状態時の運用者への支援要請である」
が同じことを指しているとは思えない。

動詞だけを見ても「テストを行う」と「支援要請である」とは通常結びつかない。

この本文の記述の意味は、ガイダンスにおいて説明されるべきである。

2008年10月25日 (土)

【共通フレーム2007】品質システムの保証は任意のアクティビティなのか

P157「2.3.4 品質システムの保証」では、「このアクティビティは、次のタスクからなる」として、タスクが1つ挙げられている。
その唯一のタスクは、「2.3.4.1」として、「さらなる品質管理活動は、JIS Q 9001の条項に従って保証されてもよい」と書かれている。

「品質システムの保証」の唯一のタスクが「されてもよい」とされている。

「品質システムの保証」は任意のアクティビティなのか。
「品質システムの保証」は、「すべきもの」ではないか。

そして、これは、JIS Q 9001の条項に従うのみしか存在しないわけではなかろう。

「品質システムの保証」は、すくなくとも共通フレームとしては、任意実施項目とすべきではないと思われる。
ここは、記述が甘いと言わざるを得ない。

2008年10月24日 (金)

【定量的品質予測のススメ】本書で想定した各測定単位の規模目安とは何か

P12「2.2.1 測定単位(品質管理単位)」において「測定単位の階層は、以下の通りに考えると良い。なお、各測定単位の規模目安は本書で想定したものである」とある。
「本書で想定した」「各測定単位の規模目安」とは何であろう。

「本書で推奨する」ならば分かる。「本書で想定した」と言われても、想定するモデル開発プロジェクトを提示されないとイメージできないと思われる
具体的に書こうという試みは良いが、どの組織でもそれが使えるかという場合に、「本書で推奨する」ならば分かるが「本書で想定した」では、本書を読んだ組織が「各測定単位の規模目安」を採用することに躊躇してしまうであろう。

【共通フレーム2007】外部委託先・協力会社・ベンダの使い分け

P157「2.3.3.3 要求事項の外部委託先への引継ぎ保証」において、見出しには「外部委託先」という語があるのに、本文には無い。変わりに「協力会社」という語が出てくる。

共通フレームには、更に「ベンダ」という語も出てくる。

「外部委託先」「協力会社」「ベンダ」は、どのように使い分けているのか、説明が必要である。

もし、仮に同じ意味であれば、統一すべきであろう。
共通フレームは、複数のステークホルダがお互いに「共通の言葉」で話すための「共通の物差し」を用意することであったはずであるが、共通フレーム内で既に同じことを3つの違う言葉で言っていることになってしまう。
「共通の言葉」で話すことは難しいことの反面教師的意義はある。

ただ、実際に活用するにあたっては、いこの3つを同じものとして扱っても実質的な弊害は生じないであろう。

2008年10月23日 (木)

【定量的品質予測のススメ】測定単位を細かくすれば詳細な品質管理・分析を行うことができるのか

P11「2.2.1 測定単位(品質管理単位)」において「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」と書かれている。
本当にそうだろうか。

例えば、プログラムソースの「測定単位を細かくして」1論理ステップ毎の欠陥を測定することに何か意味があるのであろうか。
それは極端な話、といわれるかもしれないが、では、「測定単位を細かくして」の細かくする最小単位は何であろう。

詳細な品質管理、分析を行いたいからと何でも「測定単位を細かく」すればよいわけではない。
測りたいものの特性に応じた測定単位で測ることが重要なのである。

これに対しては「細かく測るからこそ、その結果を見てどの単位で測ればよいかが見えてくる」と言うことも出来よう。

本書は、P6で「開発途中の品質は、その組織において経験的に測り得た何種類かの品質関連指標を測定して評価されることが常であり」と書かれているように、まず、とにかくデータを集めてそれから品質指標を考えようというスタンスのようである。
だから「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」という発想が生まれてくるのであろうが、指標に対する仮説を立て、測定し、仮説の妥当性を確認してから指標として採用することも良い方法であると思われる。

尚、P67に、事例として、「テスト密度や欠陥密度の達成率の例が挙げられており、
   テスト密度の達成率 : 136.3%
   欠陥密度の達成率  : 177.8%
とされている。
そして目標ガイドとして、テスト密度80.0~100.0、欠陥密度9.0~12.0と書かれている。

確かに、有効桁数4桁でテスト密度・欠陥密度の達成率を評価できる組織であれば、「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」ということも理解できるが、「定量的品質予測のススメ」という書籍名で本書を手に取った組織にはそれは無理であろう。

しかし、この例で出された組織において、テスト密度79.90、欠陥密度12.15であった場合どう評価するのであろうか。興味深い。
また、前回のプロジェクトで、テスト密度85.10、欠陥密度9.52であったものが、今回のプロジェクトでテスト密度85.22、欠陥密度9.50になったら、改善されたと言うのであろうか。

何でも細かく測定するのが良いというのであれば、ソフトウェア開発の品質レベルに重要な位置を占める開発者のプログラミング時間の測定も、「設計書を読む時間」「どうプログラミングするか考える時間」「実際にキーボードを叩く時間」「書いたコードを読み返す時間」「コンパイルしている時間」等の単位で、かつ各時間を秒単位で、測定したらよいのではないだろうか(冗談で書いています)。

「測定単位を細かくして品質データ(欠陥数等)を測定することにより、詳細な品質管理、分析を行うことができる」という記述は本当は何を言いたいのかもう少し詳細に記述されるべきであろう。

【共通フレーム2007】「ソフトウェアに関する社内慣習」とは何か

P157「2.3.3.2 開発環境、ライブラリの保証」において、「ソフトウェアに関する社内慣習」という句がある。
「ソフトウェアに関する社内慣習」とは何であろう。
なんとなく分かっても、どこまでが「ソフトウェアに関する社内慣習」でどこからがそうでないのかは分からない。

共通フレームでは「社内標準」という語もある。
これとの違いは何であろうか。

「ソフトウェアに関する社内慣習」に「社内標準」も含まれると思われるが、例示もしくは説明がないため、何のことか分かりづらい。
受け取り方による理解のばらつきが生じないように、ガイダンスで説明されるべきであろう。

2008年10月22日 (水)

【定量的品質予測のススメ】代用特性で何が測定できるのか

P6「1.1 今、品質確保が急務」において「ソフトウェア開発の現場では、品質をきちんと測定して客観的な判断を得るために代用特性を使って品質を確保しようと取り組んでいる実状がある」と書かれている。
さらりと書かれているが、「代用特性を使って」というところは注意すべきである。

「代用特性」とは何か。
「代用特性で表されるものが正しく品質を反映しているとは思わない。けれども、他に無いから、これを測ることで品質を測ることにしよう」というものではないだろうか。

この前提を忘れて定量的品質を求めてはならないであろう。

「相撲取りの誰が一番強いかを調べるのに、練習量や食べたちゃんこの量を測って多い順に決めよう」ということをしていないだろうか。

「品質をきちんと測定して客観的な判断を得るために代用特性を使って」という記述は使い方次第と言うことである。

「『客観的な判断を得るために』、練習量や食べたちゃんこの量を『きちんと測定』」しても「相撲取りの誰が一番強いか」は「正確には分からない」ということをちゃんと理解すべきである。
ただ、「正確には分からない」が「おおよその傾向は掴める」と判断できるなら使うことに価値があるのである。

【共通フレーム2007】「構成の評価」とは何をすることか

P153「2.2.5.1 構成品目の完全性の保証」には、「要求事項に対するソフトウェア品目の機能的な完全性及びソフトウェア品目の物理的な完全性(その設計及びコードが最新の技術解説書を反映しているかどうか)を決定し保証する」とある。

そして、そのガイダンスとして「構成の評価は、独立した活動としてあるいは契約で定められた監査プログラムの一部として実施してもよい」とある。

これは、どういうことであろうか。

本文にない「構成の評価」についてガイダンスで言及しているのだ。

「要求事項に対する・・・物理的な完全性を決定し保証する」の「決定」が、「評価」に基づいて行われるということであろうが、もう少し分かりやすいように書かれるべきである。

2008年10月21日 (火)

【定量的品質予測のススメ】開発途中の品質は標準化された評価には至っていない

P6「1.1 今、品質確保が急務」において「開発途中の品質は、その組織において経験的に測り得た何種類かの品質関連指標を測定して評価されることが常であり、標準化された評価には至っていない」とあり、
続いて「とはいえ、ソフトウェア開発の現場では、品質をきちんと測定して客観的な判断を得るために代用特性を使って品質を確保しようと取り組んでいる実状がある」と書かれている。

これは「本書を手にとられた方へ」と題したChapter1に書かれており、ある意味潔い。

「開発途中の品質は、その組織において経験的に測り得た何種類かの品質関連指標を測定して評価されることが常」
「開発途中の品質は、標準化された評価には至っていない」

この二つを言い切っているのだから。

ただ、それでも「定量的品質予測のススメ」という名前を付けているところは、少々あざとい気がする。

「開発途中の品質は、標準化された評価には至っていない」と言っている人に「定量的品質予測」を「ススメ」られても「本書を手にとられた方」は困惑するのではないだろうか。

【共通フレーム2007】「修正されたソフトウェア品目の実装」

P152「2.2.3.1 構成の変更管理」において、遂行すべきものが列挙されている。

(1)変更依頼の識別及び記録
(2)変更の分析及び表化
(3)変更依頼の承認又は不承認
(4)修正されたソフトウェア品目の実装、検証及びリリース

さて、この中で明らかに異質なのは、(1)である。
これのみ、「変更」で書きだされていない。

なぜか。

(1)から(3)は、変更そのものではなく変更の管理作業であるが、(4)は変更そのものの作業なのである。

構成の変更管理という意味で列挙されたものは(4)を含め理解できなくは無い。

ただし、「(4)修正されたソフトウェア品目の実装、検証及びリリース」は、それ自体の意味がつかみづらい。

「修正されたソフトウェア品目の検証」
「修正されたソフトウェア品目のリリース」
これらは分かる。
しかし、
「修正されたソフトウェア品目の実装」
は、わからない。

「変更が承認されたソフトウェア品目の実装」と考えればよかろう。

これは、ガイダンスにて説明されるべきであろう。

2008年10月20日 (月)

【定量的品質予測のススメ】難しいテーマに取り組んだことを評価されるべき書籍

独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センターより「定量的品質予測のススメ」という書籍が発行された。

書籍名の「ススメ」から、いままで定量的品質予測を行ってこなかったもしくはしたいと思うがどうすればよいか分からなかったシステム開発にかかわる組織・人々をターゲットとした入門書と受け取られそうだが、内容的には入門書といえるかどうか難しいところである。
少なくとも「では明日からこれを使って管理を始めよう」というものではない。

P3「はじめに」において「本書の内容には、品質予測の必要性や考え方、システム開発の各工程での品質予測のアプローチや事例が含まれ、企業での実践ノウハウを体系的に整理し、解説を行っています」とあるが、これを読んで、もしくは本書を携えて、自信をもって「わが社も定量的品質予測を始めましょう」とは言える内容ではない。

限られたページ数(100ページ程度)という性格上無理があるが、「定量的品質予測」に用いる手法それぞれに、様々な点で考慮しなければ実際に無からは導入できない。

P14に代表的な基本測定量と導出測定量が挙げられているが、「テスト密度」は有効桁数何桁で使えば良いのかさえ、書かれていない。
有効桁数は自明といえるだろうか。
実際本書では、P67にテスト密度の達成度の例として68.20%、89.72%といった数字が並んでいるが、テスト密度を有効数字4桁で取り扱う意味があるのだろうか。

「それは組織で決めること」と言われてしまうわけであるが、どうすれば良いかわからないから、定量的管理をしたくともできないのに、こう言われるとどうしようもない。

このハードルを越えるための背中を押してあげることが「初心者」には必要なのであるが、それが書かれた入門書は見当たらない。
本書においても残念ながらそれは書かれていない。

これは、コンサルタントの飯の種でもあるし、確立した手法を有する組織は何も競合他社にそれを教える必要も無いから、一般の書籍には出てこないということかもしれない。

おそらくそうではなく、組織によって違うのだから、一般書に書きようがないというのが正論であると思われる。

しかし、自組織に合った決定ができないから「定量的品質予測のススメ」という題名に惹かれて本書を手に取った読者も多いであろう。

「定量的品質予測のススメ」というのは、キャッチーではあるが、なかなか難しい書籍名である。

ただ、難しいテーマに取り組んだことは評価されるべきである。

【共通フレーム2007】「システム構成管理計画」の一部としての「構成管理計画」

P151「2.2.1.1 構成管理計画の立案」において「構成管理計画を立案する」とある。
そして、その備考として、「この計画は、システム構成管理計画の一部であってもよい」とある。

「システム構成管理計画」の一部として「構成管理計画」があるというのは日本語的に違和感を覚える。
「構成管理計画」の一部として「システム構成管理計画」があるというのは日本語的に理解できる。
段階的詳細化の考えで理解できるからである。

「システム構成管理計画」については索引を見ても載っていないのでわからない。
両者の関係がよく分かるような説明が必要である。

2008年10月19日 (日)

【共通フレーム2007】文書化されていない要件の構成管理は可能か

P151「ガイダンス 2.2(4)」において、「要件の品目の例としては、システム化構想、システム化計画書、要件定義書、システム設計書等が挙げられる」とある。

この例示の中に一つ異質なものがある。

「システム化構想」である。
他はすべて「書」が付いており、実際にモノである。

しかし「システム化構想」はモノではない。もしくはモノとは限らない。

モノでは無いものをモノとして捉えるのは無理があるのではないだろうか。
「システム化構想」は「システム化構想書」とすればよい。

「システム化構想」は文書化しなければ単なる頭の中のアイディアなのでこう考えれば良いはずであるが、なぜ「「システム化構想」だけ「書」が付かないのだろうか。

2008年10月18日 (土)

【共通フレーム2007】「ハードウェア、要員、要件」と「ハードウェアや要員、組織、要件」の差

P150「2.2 構成管理プロセス」の「備考」において「このプロセスを他及びソフトウェア製品又は対象とするものに用いる場合、ソフトウェア品目という用語を適宜置き換えること。(例えばハードウェア、要員、要件)」とある。
これはもはや日本語ではないので、だれも理解できないはずである。

「他」とは何か。
また、「このプロセスを他及びソフトウェア製品又は対象とするもの」における「及び」と「又は」はどう使い分けられているのであろうか。

更に、「例えばハードウェア、要員、要件」とあるのに、ガイダンスではなぜか「ハードウェアや要員、組織、要件等」と例示に「組織」が加わっている、しかも「要件」の前に。
これは共通フレームのモデルとしての性格上不整合と言わざるを得ないのではないだろうか。
実務上は1つ例が増えても困ることはないが。

更に更に、「ソフトウェア品目」を例に挙げている「要員」に実際置き換えるとしたらおかしなことになる。

置き換える元の文は次のとおり。

(1)システムのソフトウェア品目を識別し、定義すること
(2)品目の修正及びリリースを管理すること
(3)品目と修正依頼の状況を記録し報告すること
(4)品目の完全性、一貫性、及び正確性を保証すること
(5)品目の保管、取扱い、及び出荷を管理すること

これの「ソフトウェア品目」を「要員」に置き換えてみよう。

(1)システムの要員を識別し、定義すること
(2)要員の修正及びリリースを管理すること
(3)要員と修正依頼の状況を記録し報告すること
(4)要員の完全性、一貫性、及び正確性を保証すること
(5)要員の保管、取扱い、及び出荷を管理すること

(1)が辛うじて理解できるが、(2)以降は、何を言っているのであろうか。
無理に考えれば、それは要員の人格を無視してモノとして扱うことになろう。

例とはいえ、共通フレーム準拠をいう組織は、これを達成しているのであろうか。

もし、日本のどの組織においても「要員」がこのケースに当てはめられないのであるならば、例からは落とすべきであろう。
そして、これを適用する組織がSIerであれば、業務を委託すべきではない。

2008年10月17日 (金)

【共通フレーム2007】「システム」「ソフトウェア製品」「データ」の関係

P129「1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守」において、「システム」「ソフトウェア製品」「データ」の語の使い方が混乱している。

見出しでは、
   「移行のためのソフトウェア製品及びデータ作成時の・・・」
と書かれているが、
本文の始めには、
   「システム又はソフトウェア製品(データを含む)を新しい環境に移行する場合・・・」
と、「ソフトウェア製品」だけでなく「システム」が追加されているし、「ソフトウェア製品」の中に「データ」を含むことになってしまっている。
さらに、次に、
   「いかなるソフトウェア製品又はデータも・・・」
と、再度「ソフトウェア製品」と「データ」は別物になっている。

これは、見出しを含めてたった4行の記述の中で見出されるものである。
共通フレームは、複数のステークホルダがお互いに「共通の言葉」で話すための「共通の物差し」を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っているように思える。
「共通の言葉」で話すことは難しいことの反面教師的意義はある。

2008年10月16日 (木)

【共通フレーム2007】移行を実施せずにシステム運用は実施できるか

P129「ガイダンス 1.7.2.1」において、
「擬似運用環境で運用テストを実施した場合には業務及びシステムの移行(1.7.3)を実施してから運用を始める必要がある。実運用環境で運用テストを実施した場合にはシステム運用(1.7.4)を実施できる」
とある。

これは、明らかにはしょりすぎた記述である。
この文は、
「実運用環境で運用テストを実施した場合には業務及びシステムの移行(1.7.3)を実施せずに、システム運用(1.7.4)を実施できる」
と解釈できるはずであるが、本当だろうか。

「1.7.3 業務及びシステムの移行」には、「1.7.3.2 移行計画の作成及び移行」が含まれるが、これを行わなくてもシステム運用を本当に実施できるのだろうか。

「1.7.3.3 関係者全員への移行計画等の通知」「1.7.3.4 新旧環境の並行運用と旧環境の停止」「1.7.3.5 関係者全員への移行の通知」「1.7.3.6 移行評価のためのレビュー」「1.7.3.7 旧環境関連データの保持と安全性確保」も不要なのだろうか。

結局、
「擬似運用環境で運用テストを実施した場合であろうが実運用環境で運用テストを実施した場合であろうが、業務及びシステムの移行(1.7.3)を実施してから運用を始める必要がある」
というのが正しいのではないだろうか。

推測であるが、ここで言いたかったのは恐らく次のことだったのではないだろうか。

「実運用環境で運用テストを実施した場合は、テストでうまく運用ができることが確認できたら、そのまま本番運用を始めるべきである」

ただし、これは「1.7.3 業務及びシステムの移行」を実施しなくとも良いわけではないのであるが、これを「擬似運用環境」との対比で記述し、こちらでは「1.7.3 業務及びシステムの移行」を持ち出して記述しているから、誤解を生むことになったのであろう。

と、善意で捉えたいところであるが、P130「ガイダンス 1.7.3」において、「本アクティビティは、擬似運用環境で運用テストを実施したシステムを、実運用環境に移行する際に実施する」と、わざわざ繰り返し書かれている。

重要であるからわざわざ二ヶ所に同じことが書かれているのである。

つまり、共通フレームでは、

実運用環境で運用テストを実施した場合には、
    1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守
    1.7.3.2 移行計画の作成及び移行
    1.7.3.3 関係者全員への移行計画等の通知
    1.7.3.4 新旧環境の並行運用と旧環境の停止
    1.7.3.5 関係者全員への移行の通知
    1.7.3.6 移行評価のためのレビュー
    1.7.3.7 旧環境関連データの保持と安全性確保」も不要なのだろうか。
を実施せずに、システム運用(1.7.4)を実施できる

と言っている。

なぜ、このように言い切るのか理解できない。とても自明であるとは思えない。
ガイダンスにおいて、その理由を詳細に書かれるべきである。

共通フレームからは外れることとなるが、テーラリングしてでも、
  実運用環境で運用テストを実施した場合にも、「1.7.3 業務及びシステムの移行」を実施すること
を強く推奨する。

2008年10月13日 (月)

【共通フレーム2007】すべての並行運転のための活動とは

P121「1.6.12.1 ソフトウェア導入(インストール)計画の作成」において、「導入するソフトウェア製品を既存のシステムと置き換える場合には、開発者は契約で要求するとおりに、すべての並行運転のための活動を支援する」と書かれている。

ここでいう「すべての並行運転のための活動」の「すべての」とはいかなる意味なのであろうか。
「契約で要求するとおりに」という語で、既に「並行運転のための活動」の範囲が定義されるのであるから、「すべての」は不要であると思われる。

それとも、本当に「すべての並行運転のための活動」を対象にするという意味であろうか。
しかし、どう考えても、「おたくの会社では共通フレームに従って開発していると言ってましたよね、なら『すべての』並行運転のための活動を支援するってことでしょう。だから・・・」というように開発者がつけこまれるだけの意味しか持たないのではないか。
開発者の方、お気を付けください。

【共通フレーム2007】「契約」がなくとも実施すべきことと「契約」がなければ実施しなくとも良いこと

P121「1.6.12.1 ソフトウェア導入(インストール)計画の作成」において、「契約」がなくとも実施すべきことと、「契約」がなければ実施しなくとも良いことがうまく整理されていない。

ここでは、
「開発者は、契約の中で指定された実環境にソフトウェア製品を導入するための計画を作成する。ソフトウェア製品の導入に必要な資源及び情報を決定し、利用できるようにする。契約で指定された場合、開発者は、立ち上げ作業について取得者を支援する。導入するソフトウェア製品を既存のシステムと置き換える場合には、開発者は契約で要求するとおりに、すべての並行運転のための活動を支援する。導入計画は、文書化する」
と書かれている。
以下に整理して考えてみる。

・開発者は、契約の中で指定された実環境にソフトウェア製品を導入するための計画を作成する。
=>「契約の中で指定された」が、「実環境」にかかるか「計画を作成する」にかかるかでこの行為が「契約がなくとも実施すべきこと」か否かの意味が変わる。

・ソフトウェア製品の導入に必要な資源及び情報を決定し、利用できるようにする。
=>「契約」に関する記述がない。だから「契約がなくとも実施すべきこと」であると思われる。ただし、他の部分では書かれている「開発者は」という行為の主体が書かれていない。つまり、「資源及び情報を決定し、利用できるようにする」必要は有るが、他の部分と異なり、それは必ずしも開発者に負わされた義務ではないと言っている。

・契約で指定された場合、開発者は、立ち上げ作業について取得者を支援する。
=>「契約で指定された場合」と明示されているので、「契約がなければ実施しなくとも良いこと」である。

・導入するソフトウェア製品を既存のシステムと置き換える場合には、開発者は契約で要求するとおりに、すべての並行運転のための活動を支援する。
=>「契約で要求するとおりに」とあるので、「契約がなければ実施しなくとも良いこと」である。

・導入計画は、文書化する
=>「契約」に関する記述がない。だから「契約がなくとも実施すべきこと」であると思われる。ただし、他の部分では書かれている「開発者は」という行為の主体が書かれていない。つまり、「導入計画は、文書化する」必要は有るが、他の部分と異なり、それは必ずしも開発者に負わされた義務ではないと言っている。

共通フレームの記述からは、このように読み取れるが、本当にこの趣旨で書かれているのであろうか。
そして、一読しただけの読者がこのように理解できるであろうか。

せめてガイダンスで補足しないと読者によって解釈が変わってしまうと思われる。

尚、これは「1.6.12.2 ソフトウェア導入の実施」についても同様に言える。

【共通フレーム2007】「実現可能性」「適切性」というのは基準となりうるか

P120「1.6.11.2 システムの評価」において、「システムは、次の基準を考慮して評価する。評価結果は文書化する」とあり、
次の基準が挙げられている。

(a)システム要件のテスト網羅性
(b)期待した結果への適合性
(c)運用及び保守の実現可能性
(d)使用されたテスト手法及び標準の適切性

ここで、(a)(b)は基準と言えようが、(c)(d)は基準と言えるかは微妙である。
特に、「(d)使用されたテスト手法及び標準の適切性」は、観点とはいえるが基準とは言えないと考える。
基準と言うのは、何かを判断・評価する際に使用する物差し的なものであると考えるが、(d)は、人による主観の面が強く、評価の差が他に比べて大きいからそのように考えるのである。

もちろんこれらを評価すること自体には意義が有ると言えよう。

【共通フレーム2007】「開発計画」とは何か

P114「ガイダンス 1.6.5.1」において、「開発計画」という語が出てくるがこれは何であろうか。
「開発計画」とは「開発プロセス実施計画」のことと思われる。
しかし、なぜそう書かれていないのか分からない。

共通フレームは、複数のステークホルダがお互いに「共通の言葉」で話すための「共通の物差し」を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っているように思える。
「共通の言葉」で話すことは難しいことの反面教師的意義はある。

【共通フレーム2007】「詳細設計」と「ソフトウェア詳細設計」

P114「1.6.5.6 ソフトウェア方式設計の評価」において、なぜか列挙項目に(a)(b)・・・のような項番がついていない。
それはともかく、ここでは、かなり言葉の短縮がなされている。

「要件」や「詳細設計」と言われても共通フレーム上は何のことか一意に決まらない。

「要件」は「業務要件」なのか「システム要件」なのか。
「詳細設計」は、おそらく「ソフトウェア詳細設計」のことであろうが、なぜそのように書かれていないのか分からない。

共通フレームは、複数のステークホルダがお互いに「共通の言葉」で話すための「共通の物差し」を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っているように思える。
「共通の言葉」で話すことは難しいことの反面教師的意義はある。

【共通フレーム2007】「工程」ではない「詳細設計」とは何か

P114「1.6.5.1 ソフトウェア構造とコンポーネントの方式設計」において、「ソフトウェア品目に対する要件は、すべてソフトウェアコンポーネントに割り振り、更に細部を明らかにして、詳細設計をやりやすくしなければならない」と書かれている。
ここに「詳細設計」という語が出てくる。

「詳細設計」とは、ソフトウェア開発においては、通常「工程」の一つとして使われる。

一方で、P23「(4)工程、時間からの独立性」にあるように「共通フレームは、工程や時間に依存して定義されたものではない」となっている。

では、「工程」ではない「詳細設計」とは何かということになるが、その他の場所で「詳細設計」という語があちこちに出てくることもないので、よくわからない。

「工程、時間からの独立性」は崩れることになるが、ここでは通常使われる「詳細設計工程」のことと理解して良いであろう。

【共通フレーム2007】「一貫性」と「外部一貫性」

P112「1.6.4.2 ソフトウェア要件の評価」において、ソフトウェア要件の評価基準の一つとして「システム要件との外部一貫性」が挙げられている。

一方、「1.6.2.2 システム要件の評価」では、「取得ニーズとの一貫性」という基準が挙げられている。
また、「1.6.4.3 システム方式設計」では、「システム要件との一貫性」が挙げられている。

これらにおいて、「一貫性」と「外部一貫性」とはどのように使い分けられているのであろうか。

まず、「1.6.4.3 システム方式設計」の「システム要件との一貫性」について「外部」が付かないのは、一貫性を評価するレベルが「システム方式設計」と「システム要件」という共に「システム」という同じレベルであるからと解釈できる。

この考えを使えば、「1.6.4.2 ソフトウェア要件の評価」での「システム要件との外部一貫性」は「ソフトウェア要件」と「システム要件」という、一貫性を評価するレベルが上下の関係になるから「外部がつく」ということで理解できる。

しかし、この考えは、「1.6.2.2 システム要件の評価」の「取得ニーズとの一貫性」においては少し違和感が残る。
「システム要件」と「取得ニーズ」は同じレベルなのか、上下なのかで評価が分かれそうである。

「一貫性」と「外部一貫性」をわざわざ使い分けるのであるなら、その違いがわかるようにガイダンスにでも書かれているとよいと思われる。

そうでなければ、おそらく実際の活用においては、この区別は気づかれず考慮されないであろう。

共通フレームを、体系だったモデルとして使うのであれば、わざわざ使い分けている語を、意識してではなく無意識に混同して使用されることは避けなければならないのであるが、この「外部一貫性」については分かりづらいので、補記が必要であろう。

【共通フレーム2007】システム方式とシステム方式設計

P111「1.6.3.4 システム方式の評価」とある。
また、次に「1.6.3.5 システム方式設計の共同レビューの実施」と続く。

一方、P114「1.6.5.6 ソフトウェア方式設計の評価」があり、「1.6.5.7 ソフトウェア方式設計の共同レビューの実施」が続く。

内容的にほとんど同じ構成のはずなのに「1.6.3.4 システム方式の評価」にだけ「設計」の語が付いていない。

他の3つにはあるのに。

わざわざ変える理由は分からない。

【共通フレーム2007】システム方式設計の段階での利用者文書作成の実現可能性

P111「1.6.3.2 利用者文書(暫定版)の作成」において、「開発者は、利用者文書の暫定版を作成し、文書化することが望ましい」とある。

言いたいことは、分かる。
利用者文書を、開発が進むにつれて段階的に書き上げていけと言っているのである。

しかし、実際にこれをシステム方式設計の段階で作成を開始することは難しいのではないだろうか。

ソフトウェアがどのようになるか分からなければ、ほとんど書く内容が無いと思われる。
もしくは、書けたとしても、本番稼動後に利用者文書を活用する利用者にとっては不要な情報となる可能性が高くなるのではないだろうか。

しかも、共通フレームでは、「1.6.3.2 利用者文書(暫定版)の作成」が書かれている「1.6.3 システム方式設計」よりもV字モデルの順番としては後に来る「1.6.4 ソフトウェア要件定義」の「1.6.4.1 ソフトウェア要件の確立」において、「利用者文書」の要件を確立するとある。

素直に読めば、「利用者文書」の要件を確立する前に、利用者文書の暫定版を作成することを推奨していることになってしまう。

以上から、「1.6.3.2 利用者文書(暫定版)の作成」は、外して考えてよい。

尚、共通フレームでは、利用者文書の例として、システム運用マニュアル、システム運用マニュアルが挙げられている。

【共通フレーム2007】開発者が契約によって実施又は支援しなければならないタスクとは

P111「1.6.3 システム方式設計」において、「このアクティビティは、開発者が契約によって実施又は支援しなければならない次のタスクからなる」とある。
ここで「契約」という言葉がわざわざ書かれているが、これは何を意味するのであろう。

「1.6.2 システム要件定義」においても「開発者が契約に従って…」という文言がある。

これは、普通に考えれば「契約によって」等の記述が無ければ「契約」は無くともよいと解釈できそうだが、開発プロセスにおける他の開発者の作業を見ても、そう言うわけでもないと思われる。

では、なぜ共通フレームの開発プロセスでは「1.6.2 システム要件定義」と「1.6.3 システム方式設計」は「契約」に基づくことをわざわざ記述しているのであろうか。

「1.6.10 システム結合」「1.6.11 システム的確性確認テスト」においては「契約で要求されている場合には、開発者はこれらのタスクを行うか又は支援する」という記述がある。
これは、「1.6.10 システム結合」「1.6.11 システム的確性確認テスト」は開発者が当然実施する作業ではなく、契約があ有ってはじめて実施すべきものであることを言っている。
この記述がヒントになるかもしれない。

共通フレームにおいては、「1.6.10 システム結合」「1.6.11 システム的確性確認テスト」ほど強くではないが、「1.6.2 システム要件定義」と「1.6.3 システム方式設計」は、開発者が当然実施する作業ではなく、契約が有ってはじめて実施すべきものであることをほのめかしているのであると推測可能である。

では、なぜ「1.6.10 システム結合」「1.6.11 システム的確性確認テスト」のように、はっきり書かなかったのか。
「1.6.2 システム要件定義」と「1.6.3 システム方式設計」の方が、「1.6.10 システム結合」「1.6.11 システム的確性確認テスト」よりも開発者が行うケースが多いため、控えめな表現になったということではないだろうか。

実際には、当然であるが、共通フレームにおける記述の有無に関わらず、すべての開発者作業は契約又は合意の上で行われなければならない。

【共通フレーム2007】利用者「集団」とは何か

P110「ガイダンス 1.6.2 システム要件定義」において、「何を要求されているかを十分に理解するためには、利用者集団からのヒアリングを行うとよい」とある。
ここでは「利用者集団」という語が出てくる。

P22の表2-1に挙げられている「共通フレーム上の役割」には、「利用者」しか定められていない。

P22の「共通フレーム上の役割」で定める「利用者」は、ただ一人の利用者を想定しているとは思えないし、P296の用語集における「利用者」の説明も「ある機能を果たす運用システムを利用する個人または組織」と「組織」も書かれているので、ここは「利用者」と書かれても問題ないはずである。

なぜここでは「集団」という語を付け足されたのか。

システムの利用者といっても、大規模システムであれば、様々な利用者の階層があり、階層ごとに特化した要求も有れば、階層によって同じニーズに対する要求が異なることもあるだろう。

「利用者」というと単一のもしくは、きれいに正規化された要求をもつ利用者をイメージしやすいので「利用者集団」と書くことで、広範囲の利用者からヒアリングせよという意味を持たせたと思われる。

尚、「利用者集団」という語は、P113「ガイダンス 1.6.4」にも出てくる。
ここも、要求の聞き込みに関する記述であるので、上で記述した理解で問題はないと思われる。

【共通フレーム2007】「取得ニーズ」を開発者はどこで入手するのか

P110「1.6.2.2 システム要件の評価」において、「次の基準を考慮して、システム要件を評価する」とあり、その基準として挙げられた5つの中に、「取得ニーズへの追跡可能性」「取得ニーズとの一貫性」がある。
索引で「取得ニーズ」を調べても、この1.6.2.2の記述のページしか載っていないので分わからないが、、この取得ニーズは、どこで入手するものであろうか。

「取得ニーズ」はユーザの視点でのもので、1.6.2.2で行う「システム要件の評価」は開発者の視点のものである。
両者は「業務要件」を仲介して関係しているものであるから、ここでは、「取得ニーズ」を「業務要件」と置き換えて考えれば良いのではないだろうか。

それともあえて「業務要件」は見るなというのであろうか。

【共通フレーム2007】「システム要件」と「システム要求仕様」

P110「1.6.2.1 システム要件の定義」において、「システム要件には、次のものを記述する」とあり、また一方で「システム要求仕様は文書化する」とある。
つまり「システム要件」と「システム要求仕様」は別物のように書かれている。

一方で、P73「1.1.1.2 システム要件の定義と分析」では、「システム要件」に、様々な「要求事項」が含まれることが、記述されている。

「1.1.1.2 システム要件の定義と分析」における「要求事項」に「システム要求仕様」は含まないということであれば、つじつまはあうが、これはP73「1.1.1.2 システム要件の定義と分析」の考えを採用したほうが良いと思われる。

【共通フレーム2007】「システム設計」とは何か

P110「1.6.2 システム要件定義」において、「システム設計」という語が出てくる。
共通フレームでは、「システム方式設計」「ソフトウェア方式設計」「ソフトウェア詳細設計」は、定められているが、「システム設計」は無い。
この語は、P112「1.6.4 ソフトウェア要件定義」にも出てくる。
しかし索引にはない。

「1.6.4 ソフトウェア要件定義」では、ソフトウェア要件定義の目的はシステム設計が可能な技術要件に変換することであるとしているので、ここでいう「システム設計」とは、「システム方式設計」のみではなく、「ソフトウェア方式設計」「ソフトウェア詳細設計」も含む概念であるといえる。

共通フレームのモデルとしての分かりやすさから考えれば、「システム設計」などという新しい語を追加するのではなく、既に定められた「システム方式設計」「ソフトウェア方式設計」「ソフトウェア詳細設計」を適宜組み合わせることで表現すべきであった。

【共通フレーム2007】別の計画とは何か

P104「1.6.1.4 開発プロセス実施計画の作成」において、「必要な場合、別の計画を作成しても良い」とあるが、「別の計画」とは何か。
また、どのような時が「必要な場合」なのか。

これはガイダンスの場所でよいので、もう少し分かるように書くべきである。

【共通フレーム2007】「開発プロセスにおける開発者とは

P108「1.6 ガイダンス」において、「開発プロセスにおける開発者とは、実際に成果物を作成する者のみならず、それを支援する者、要求を出す側の業務担当者、運用を行う運用担当者も含まれる」とある。
これは、P22 表2-1でまとめられた「開発者」の実施の組織/役割とほぼ同じであり、わざわざ書かなくとも良いと思われる。

活用者の参考のために記述したというのであれば、この説明内容は、「開発プロセスにおける開発者」に限らず、全プロセスにおける「開発者」が対象であるので、「開発プロセスにおける」という修飾は不要であろう。

もし、他のプロセスと「開発プロセス」で、「開発者」の意味が異なるのであれば、それは別な語を当てた方が良いが、意味が異なることはないと思われる。

【共通フレーム2007】「プロセス」と「ライフサイクルプロセス」

P93「1.4.1.2 必要な支援プロセスの実施」において、「支援プロセス」と書かれているが、次の「1.4.1.3」では「支援ライフサイクルプロセス」とある。
ぱっと見では、その違いはわからない。

両者の違いは、P146「2. 支援ライフサイクルプロセス」の記述から読み取ると、

「支援ライフサイクルプロセス」は、9つの「支援プロセス」の総体を指す

ことがわかる。

【共通フレーム2007】プロセスを呼び出すとは

P91「1.3.5.2 基準線の変更」において、「変更手続きは構成管理プロセス(2.2参照)を呼び出して行う」とある。
「呼び出して行う」とはどのような行為なのか。
他の部分では例えば「監査は2.7(監査プロセス)に従って実施する」(P87)のように「従って実施する」が使われているが、この「従って実施する」と「呼び出して行う」はどのように違うのか書かれるべきであろう。

尚、「呼び出す」という語は「ガイダンス 1.6.4.1」にも出てくる。

【共通フレーム2007】影響の調査分析で望ましいこと

P90「1.3.3.1 影響の調査分析の根拠」において、ガイダンスで「必要に応じて要件定義プロセス(1.5参照)、開発プロセス(1.6参照)を使用することが望ましい」とある。

これに関し、次の二点が不明である。

「1.6 システム要件定義」の使用は不要なのか。

「1.5 要件定義プロセス」は、P22で見ると、ベンダは「責任の主体」のみならず「支援」の役割も担わない。
役割を担わないにもかかわらずプロセスを使用するとはどういうことなのかをもう少し説明されるべきであろう。

【共通フレーム2007】契約の変更要求が与える影響調査の重みの違い

P89「1.3.2 契約の変更要求」において、「当該要求がプロジェクト計画、費用、利益、品質及び予定に与える影響」に関する調査分析が、契約の変更要求者が「供給者の場合」と「取得者の場合」で異なる場所に記述されている。

前者は「1.3.2 契約の変更要求」に、後者は「1.3.3 影響の調査分析」に書かれているのだ。
前者は主となる文に対し付加的に、後者はそれ自体が主となる文になっている。

契約の変更要求者が「供給者の場合」と「取得者の場合」ともに「供給者」が調査分析をするのであるから、記述は分けずに一ヶ所にまとめた方が、モデルとしては良いであろうし、実用においても、理解しやすい。

【共通フレーム2007】契約と合意

P88「1.3 契約の変更管理プロセス」において、「目的」に「二者が合意する結論で終わる」とあるが、P78において契約と合意とは共通フレームでは同じ意味で使うことを示されているし、その他の部分では基本的に「契約」という語が使用され、「合意」と読み変えても良い構成となっている。

なぜここでは「合意」という語が使用されているのであろうか。説明すべきと思われる。
見出しで「1.3 契約の変更管理プロセス」と「契約」という語を使っているのにそのなかで「合意」を使用しているのであるから、なんらかの区別をしているはずだ。

おそらく、この部分では無意識的に「合意」と「契約」は別物として考えてしまい、P78の記述を鑑みなかったのであろう。

個人的には「契約」と「合意」は分けたほうが良いと考える。
「合意」のうち、何らかの形式的行為を伴うものを「契約」として捉えた方が分かりやすいであろう。

あえて同じ意味とするのであれば、「合意」で統一するべきであろう。
「契約」というと、現実のビジネスでは「契約文書の作成」と繋げて考えてしまうことが多いと考えられるが、共通フレームにおける「合意」すべき事項においては、「契約文書の作成」は必然ではないからだ。

2008年10月12日 (日)

【共通フレーム2007】「ソフトウェア製品」の範囲

P131「ガイダンス 1.7.3.1」において、「共通フレーム2007では移行のためのツールやデータも製品の一部としている」とある。
「1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守」では、「製品」という語はなく、「ソフトウェア製品」しかないので、ここで言う「製品」とは「ソフトウェア製品」のことであろう。

尚、P16「3. 共通フレームの適用分野」においては、「(1)に言うソフトウェア製品とは、製品として販売されるソフトウェア及び、家電製品に内蔵される組み込みソフトウェアなどを指す」とあるが、「(1)に言うソフトウェア製品とは」とあるから、これはP16「3. 共通フレームの適用分野」においてのみの定義ととらえなければならない。

「1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守」と「ガイダンス 1.7.3.1」では、同じ意味で違う語を使用し、「1.7.3.1 移行のためのソフトウェア製品及びデータ作成時の共通フレームの遵守」と「3. 共通フレームの適用分野」では、違う意味で同じ語を使用している。

共通フレームは、複数のステークホルダがお互いに「共通の言葉」で話すための「共通の物差し」を用意することであったはずであるが、共通フレーム内で既に同じことを違う言葉で言っている。
「共通の言葉」で話すことは難しいことの反面教師的意義はある。

« 2008年8月 | トップページ | 2008年11月 »