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            
無料ブログはココログ

« 2009年12月 | トップページ | 2010年2月 »

2010年1月

2010年1月29日 (金)

【共通フレーム2007第2版】「選ばれた」と「選定された」の使い分け

P180「2.7 監査プロセス」において、旧版では「選ばれた成果物及びプロセスが・・・」と「選ばれたソフトウェア成果物及び/又はサービス若しくはプロセスが・・・」となっていたものが、第2版では後者のみ「選定されたソフトウェア成果物及び/又はサービス若しくはプロセスが・・・」となっている。

なぜ後者のみ「選ばれた」から「選定された」に変わったのであろう。

2010年1月26日 (火)

【共通フレーム2007第2版】「いわゆるプログラミング」とは

P118「ガイダンス 1.6:5」にて「『ソフトウェアコード作成及びテスト』とは、いわゆるプログラミングのことを指す」とある。

「いわゆるプログラミング」とは何か。
「コード作成のことに決まっているだろう」という人もいれば「コード作成とデバッグ」という人もいよう。

これらを否定し、「ソフトウェアコード作成及びテスト」が「いわゆるプログラミング」と言い切るのは適切なのだろうか。

しかも「モジュールテスト」「単体テスト」「ユニットテスト」等ではなく一般名詞の「テスト」。
システムテストも「いわゆるプログラミング」なのだろうが。
親切に読めば「ソフトウェアコード作成及びソフトウェアテスト」となるが、ここは用語の解説部分のはずなのに色々な意味に取れるのはよくない。

用語を統一するのも共通フレーム2007の目的のはずなので「いわゆる」という語は使うべきではなかろう。

ということで、このガイダンスは不要である気がする。
これが無いと何が困るのであろうか。

2010年1月22日 (金)

【共通フレーム2007第2版】「全利害関係者間」と「利害関係者の組織間」の違い

P115「1.5.3.2 要件変更ルールの決定」において「また、その後に変更が発生した場合、対象となるシステムの機能、費用、品質、運用開始時期に影響することを踏まえた上で、変更に関する基本方針や変更のために必要な手続き等について、利害関係者の組織間で合意を得る」とある。

旧版には「機能」はなかった。
これを増やしたことの意図は何であろうか。
機能と費用、品質、運用開始時期に影響する。

「変更が発生した場合、対象となるシステムの機能に影響することを踏まえた上で、利害関係者の組織間で合意を得る」ことが必要だからなのであろうが・・・。
要件変更があれば、対象となるシステムの機能に影響することは自明ではなかろうか。まあ、自明だから書いてもよいのであるが。

P116の「ガイダンス 1.5.3.2 」を見ると、どうも要件変更に伴って発生する「機能の削減」等のことらしい。しかし、機能って要件から導き出されると思う。
だから「・・・その後に変更が発生した場合、関連するシステムの要件、・・・」とした方が良いのではなかろうか。

ここではそれよりも、旧版の「全利害関係者間で合意を得る」が「利害関係者の組織間で合意を得る」に変更されていることに注目する。
「全利害関係者間」と「利害関係者の組織間」ではどう違うのか。

「全」を取って「組織」を入れた意図。
「全」を取ったのは、有っても無くとも同じ意味だからだろう。
一方「組織」を入れたのは、通常の利害関係者(≒利害関係を有する組織の代表としてプロジェクトに関与する者)ではなく、その属する組織自体を指し、意味が変わる。
なぜ「組織」を入れたのだろうか。
利害関係を有する組織の代表としてプロジェクトに関与する者には、現実問題として要件変更の決定権までは無いことが多いためだろうか。
仮にそうだとして、それもわからなくは無いが、モデルとしての共通フレームの位置づけから考えると、そこまで配慮することは不要ではなかろうかと考える。

なぜ「組織」をわざわざ入れたのだろうか。

尚、「ガイダンス 1.5.3.2」は旧版より厚く書かれている。

2010年1月19日 (火)

【共通フレーム2007第2版】「用語は残らず定義」の理想と現実

P114 「ガイダンス 1.5.2.2」において、「用語の定義では、特に組織特有の意味をもつ用語は残らず定義するとよい」とある。

これは旧版でもそうであったが、「残らず定義するとよい」という表現はわかりづらい。

言わんとすることは分かるが、「残らず」と「するとよい」がなじまない。単に「定義するとよい」や「定義するべきである」「定義しなければならない」ではタメなのだろうか。なぜ「残らず」がいるのか。全て挙げきることに意味があるのならば「残らず定義すべきである」のようになるはずである。

これは恐らく著作者側で「残らず定義すべきであるが、現実にはそれは無理」と考えているからではないか。

「残らず定義」には、「予め」全て定義しなければという意味が込められているように個人的には感じる。これが「しかし現実には無理だから」という感覚とあいまって、「残らず定義するとよい」という文になっているのではないか。

わざわざ「残らず」などと入れなくとも、「用語の定義では、特に組織特有の意味をもつ用語は定義しなければならない」で意図は伝わると思われる。

2010年1月15日 (金)

【共通フレーム2007第2版】「望ましい」から必須事項への変更

P112「1.5.1.6 要件定義プロセス実施計画の作成」において、

旧版では、
「・・・この計画には、標準、方法論、手順、及び関係者間の要件定義に関する役割分担(要件ごとの責任の所在を含む)を記載することが望ましい」

となっていた箇所が、

第2版では、
「・・・この計画には、標準、方法論、手順、及び関係者間の要件定義に関する役割分担(要件ごとの責任の所在を含む)を決定して、記載する」

と変更されている。

これは妥当であろう。
共通フレームの位置付けとして、「望ましい」という語は使うべきではないから。

2010年1月12日 (火)

【共通フレーム2007第2版】句の入れ替えの意味

P111「1.5.1.1 要件定義作業の組立て」は、旧版では「1.5.1.1 要件定義作業の定義」となっていた。これは、P102 「1.4.1.1 企画作業の組立て」と同じ理由によるのであろう。

ここでは「備考」についてみてみる。

第2版では、
「これらのアクティビティ及びタスクは、要件定義作業に当てはめたとき、数か所に重複して現れていてもよいし、又は相互に影響しあう形であってもよい」

となっているが、

旧版では、
「要件定義作業に当てはめたとき、これらのアクティビティ及びタスクは、複数か所に重複して現れていてもよいし、相互に影響しあう形であってもよい」

となっている。

「これらのアクティビティ及びタスクは」と「要件定義作業に当てはめたとき」が入れ替わっている。意味がそれほど変わるのであろうか。国語的な厳密性なのかもしれないが、わからない。

「複数か所に重複して」が「数か所に重複して」になったのは、理解できる。
「複数」と「重複」で意味が文字通り重複しているからだろう。

「又は」を入れた意図も良くわからない。有ると無いとでどう意味が変わるのだろう。
「数か所に重複して現れること」と「相互に影響しあう」ことが両立しないことを強調しているのであろうか。

この部分の修正はかなり慎重に語句を選んでいるように思えるが、なぜここなのかという気がする。

2010年1月 8日 (金)

【共通フレーム2007第2版】「経営要求」から「経営ニーズ」へ

P103 「1.4.2.1 経営上のニーズ、課題の確認」は、旧版では「1.4.2.1 経営要求、課題の確認」となっていた。

これは、P34~35の「要求」「要件」「ニーズ」の定義変更に伴うもので、妥当である。

2010年1月 5日 (火)

【共通フレーム2007第2版】企画作業の「定義」と「組立て」

P102 「1.4.1.1 企画作業の組立て」は、旧版では「企画作業の定義」となっていた。

確かに、「・・・企画作業を定義、あるいは選択する。さらに、・・・」となっているので、内容は「定義」だけではない。

しかし、だからといって「1.4.1.1 企画作業の組立て」というのも何かしっくりこない。
とはいえ、改善されていると言えよう。

同じような視点の改定は次の、「1.4.1.2 必要な支援プロセスの組込み」にもあって、これは旧版では「必要な支援プロセスの実施」となっていた。

こちらは、旧版のままの方が良かったように感じる。

「組立て」とか「組込み」と「組」という字が好んで使われているが、皮肉なことに、これはエンタープライズ系開発のフレームなのです。

« 2009年12月 | トップページ | 2010年2月 »