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

共通フレーム2007第2版

2010年6月15日 (火)

【共通フレーム2007第2版改訂情報】「要件」と「要求」の交錯

「共通フレーム2007第2版改訂情報」P13の「、「『要求』と『要件』の概念整理に基づく用語変更」について再び考察する。

第1版P240の「機能要求」が第2版では「機能要件」となっているように、要求と要件では、この改訂に当たっては、「要求」の一部が「要件」に変更になっている。

しかし、1箇所だけ「要件」が「要求」になっているところがある。
第1版P232の「契約の変更要件」が第2版P244の「契約の変更要求」になっている箇所だ。

第2版の定義、
   「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を
   強調したいときに使う。
から、この変更はわからないでもない。

しかし、開発者にとってはどうでも良いことのようにも思える。
これは「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う・・・という「共通フレーム第2版」の定義は業界に定着するか否かにかかっているだろう。

英語では同じ語である「要求」と「要件」を分けて考えることについて、実際に開発に携わる者たちが必要性を感じるか、加えて感じる場合に「共通フレーム第2版」の定義でしっくりくるか、自然に理解できるかにかかっていよう。

ちなみに、以前のエントリでも書いたが、「共通フレーム第2版」では、次の定義を頭に入れておくことをフレーム使用者に求めている。

-------
①「要求」「要件」は、ともにrequirementの訳語である。
②「要求」を一般的な訳語とする。ただし、「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う。
③「要求」「要件」以前のものを、「ニーズ」という。
 期待(expectation)、要望(desire/wants)、思い(wish)、夢(dream)、
 意図(intension)などは、ニーズの類義語である。
-------

2010年6月 4日 (金)

【共通フレーム2007第2版改訂情報】「要求」「要件」「ニーズ」の交錯

引き続き「共通フレーム2007第2版改訂情報」について。

P12~13に、「『要求』と『要件』の概念整理に基づく用語変更」として初版と第2版における要求・要件・ニーズに対する変更点が書かれている。

これはちゃんと整理して公開したという点では評価できる。
しかし、内容的にはなぜそのように変えたのだろう、変える必要があったのであろうかと思える箇所もいくつかある。

1.「要求事項」と「要求」と「要件」
 P43「契約上の要求」は「契約上の要求事項」に変更されており、
 P43「システム要求事項」は「システム要件」に変更されている。

 「要求事項」は前者では採用され、後者では否定されている。

2.「要求仕様」は「要件」なのか「仕様」なのか
 P80「要求仕様を反映している」は「要件を反映している」に変更されている。
 P83「要求仕様の変更」は「仕様変更」に変更されている。

 後者はなぜ「要件変更」ではダメだったのであろうか。

上記2つについては何故なのか変更履歴に説明が欲しいところ。

2010年6月 1日 (火)

【共通フレーム2007第2版改訂情報】「要求」「要件」「ニーズ」はなぜ別々に定義される必要があったのか

「共通フレーム2007第2版」について「共通フレーム2007第2版改訂情報」なる資料がIPAのHPで公開されていた(http://sec.ipa.go.jp/publish/index.html#ent)。

気づかなかったのでこれに触れずに「共通フレーム2007第2版」についてななめ読みしてきたが、ここでこの「改訂情報」に触れたい。

「共通フレーム2007第2版改訂情報」P11の背景において「国際標準で使用されている『requirement』の訳語として、要求と要件がある。この2つの用語の概念を整理した上で、『共通フレーム2007』の全文書全般にわたって使用箇所を見直し、適切な訳語を当てはめる」と書かれている。
「国際標準で使用されている『requirement』の訳語として、要求と要件がある」が前提のようになっているようだが、そもそもそれで良いのだろうか。
「ニーズ」という新しい概念まで加えており、要求に関しては国際標準の3倍のバリエーションとなってしまっている。

どうしても定義しないといけないと考えるのであれば、それはそれでよいのであるが、ならば何故旧版の「要求」と「要件」の定義を変える必要があったのであろうか。

「共通フレーム2007」では、「要件」「要求」「ニーズ」の3つについて、国際標準ではなく「共通フレーム2007」独自の定義を頭に入れておけと言っているのである。
それだけでも重要な差異であるのに、旧版から2年で定義を大きく変えてしまうというのでは、「共通フレーム2007」のスタンダードという位置づけとして好ましくないのではないだろうか。

これら定義として、「共通フレーム2007第2版改訂情報」には次のように書かれている。
 

【プロセス共有化WGにおける合意事項】
①「要求」「要件」は、ともにrequirementの訳語である。
②「要求」を一般的な訳語とする。ただし、「要件」は要求プロセスのアウトプットに対して、特に「固まった文書」を強調したいときに使う。
③「要求」「要件」以前のものを、「ニーズ」という。
 期待(expectation)、要望(desire/wants)、思い(wish)、夢(dream)、
 意図(intension)などは、ニーズの類義語である。

さて、②のように、requirementの訳語を「要求」と考えるのであるなら、「要件」「ニーズ」などと新しい語を定義するのではなく、「要求」に対する相対的位置付けを簡潔に記述する方法で定めればよかったのではないか。

詰めは甘いであろうが、例えば次のような感じで。
「要件」の代わりに「要求が固まった文書」とし、
「ニーズ」の代わりに「要求のインプットとなるもの」とする。

このようにすれば「要件」「ニーズ」などという語をわざわざ定義しなくとも良いのではないか。

なぜ国際標準では1つでこと足りる定義を複数定める必要があったのであろうか。
しかも、それを知りながら定め、かつその定義自体を自ら変更してしまう確信犯。

どうしても定義が必要だというのであれば、なぜそのようにする必要があるのかについての説明が必要であろう。
しかし、この理由がどこにあるのか、「共通フレーム2007第2版」だけでなく、「共通フレーム2007第2版改訂情報」においても分からなかった。

「共通フレーム2007」は、多くの人に共通認識のための定義として使ってもらうことを目的としていたはずである。
だから、定義すれば良いというものではないと思うのだが・・・。

2010年3月26日 (金)

【共通フレーム2007第2版】「要求」「要件」「ニーズ」&「要望」

P290「1.2 要件の定義と役割(ロール)」において「従来のシステム開発は、・・・業務部門から要望を聞いて作ることができた」とある。
「要望」・・・。共通フレームでは、P34で「要求」「要件」「ニーズ」を定義している。
その上で「要望」という語がでてきているが、どのような意味であろうか。

実は「ニーズ」の定義に「要求/要件以前のステークホルダの意図、要望、思い、夢などである」と書かれている。
故に、「要望」は「ニーズ」のことであると思われるが、わざわざ「要望」と書く必要はなく、共通フレーム内で定義された「ニーズ」を使えば良かったのではないだろうか。

2010年3月24日 (水)

【共通フレーム2007第2版】保守プロセスを中心とした、問題解決に関するプロセス連関

P282「4.保守プロセスを中心とした、問題解決に関するプロセス連関について」は、第2版で追加された。
エンタープライズ系開発における保守の重要性からみて、これは良いことであろう。

中身については、共通フレームの位置づけから考えて妥当なのかどうか良くわからない。

ただ、他に比べて記述方法というかレベルというか、芸風とでもいうか・・・そのようなものが大きく違う感じがする。

2010年3月19日 (金)

【共通フレーム2007第2版】「再利用施策管理プロセスの概要」の大幅変更

P262「図4-19 再利用施策管理プロセスの概要」は、P261「図4-18 管理資産プロセスの概要」同様、本文の変更は軽微であるにも関わらず、大きく見直されている。

図4-18同様、P212「3.6 再利用施策管理プロセス」のアクティビティ一覧に合わせたものである。

2010年3月17日 (水)

【共通フレーム2007第2版】公平なコミュニケーションの経路と制度

P261「(f)再利用施策管理プロセス」において「再利用施策管理は、プロジェクト単体だけではなく、組織的に計画、実施されなければならないために、各プロジェクトに共通で公平なコミュニケーションの経路と制度が必要になる」とある。
「各プロジェクトに共通なコミュニケーションの経路と制度」はわかるが、「公平なコミュニケーションの経路と制度」とは何だろう。

コミュニケーションの経路と制度の例として「例えば、対象ドメインの連絡、特定の製品や資産の利用制限や解除の通告、各プロジェクトでの利用状況のフィードバック等である」と書かれている。
ここからは、「公平」性は読み取れない。

公平というのは、各プロジェクト内の話だろうか、それともプロジェクト間での話なのだろうか。
これは自明なのだろうか。

他の管理よりも「再利用施策管理」において、公平性を敢えて言わなければならないという視点で考えると良いのかもしれない。

2010年3月12日 (金)

【共通フレーム2007第2版】「管理資産プロセスの概要」の大幅変更

P261「(e)資産管理プロセス」の「図4-18 管理資産プロセスの概要」は、第2版で大きく変わった。

「(e)資産管理プロセス」の本文は変わっていないにも関わらず、なぜここまで変える必要があったのか。

答えは、P208「3.5 資産管理プロセス」にある。
第2版では「3.5 資産管理プロセス」のアクティビティ一覧に合わせているのだ。
旧版では、これがなされておらず、独自に定められていた(?)ので「大きく変わった」ように見えたのだ。

その意味でこの改定は、共通フレームの一貫性を高めたものであろう。

2010年3月10日 (水)

【共通フレーム2007第2版】V&Vにおける更なるV字モデル

P256「(e)妥当性確認プロセス」の(注)において「上記の検証(Verification)と妥当性確認(Validation)を対で考えるV&Vと称している」とある。
「称している」?

なにか他に言い様があると思われる。
この「(e)妥当性確認プロセス」では、それはどうでも良いことである。

考えるべきはその後に出てくる図4-15である。
またも、またも新しいV字モデルが出てくる。
これはもう確信犯である。

図4-10では、箱の構成は同じであるが、箱の中身の記述が異なっている。
ある意味マイナーバージョンといえる。

これは、著作者が「変えたほうが良い」と考えるから変えているのであろう・・・おそらく。
しかし、歩み寄って考えても、「変えたほうが良い」理由が分かるものもあれば何故変えているのかわからないものもある。

「事業評価」が「投資効果、業務効果(運用)」と替わったのはV&Vではより詳細化した等の理由がつきそうなので分からなくもないが、「(業務)運用テスト」を「運用テスト(運用)」に変えねばならないのかちょっと分からない。
「プログラミング」を「詳細設計・作成」とするのも同様。

そもそも、詳細設計・・・?この後を共通フレームで使ってよいのであろうか。
「詳細設計」という語はP26「(6)開発モデル、技法、ツールからの独立性」でいう「開発モデル」の語に近いのではないだろうか。

「詳細設計」ではなく「プログラム設計」とすれば、個人的には、ぎりぎり問題ないと思われる。但し著作者の意図から離れるかもしれないが・・・。

2010年3月 5日 (金)

【共通フレーム2007第2版】ベースラインについての記述変更

P255「(b)構成管理プロセス」において「構成品目は、そのライフサイクル上の決められた時期に、関係者間で正式版として承認したもの(共通フレームでは、JIS規格に合わせて『基準線(ベースライン)』と表現している)を定め」とある。
これは、旧版では「構成管理の対象が、そのライフサイクル上のある決められた時点で元の状態と取り決めたものをベースラインとする」となっていた。

旧版の「ある決められた時点で」が第2版の「決められた時期に」になったが、「ある」はあいまいであることから削除されたことは理解できる。
一方、「時点」「時期」の違いは意味的にはどちらでも良いであろう。

旧版の「元の状態と取り決めたもの」が第2版の「関係者間で正式版として承認したもの」となったのは、かなりわかりやすくなった。「元の状態」というのが非常にミスリーディングであったので。
しかし、それでも「正式版として承認」という表現は、実はベースラインの意味を既に知っているから理解できるだけかもしれない。

この箇所は、初めてベースラインという語に触れるもののための記述であるが、これで理解できるかどうかはちょっと微妙な気もする。
引っかかるのは「正式版」という語の受け取り方。

最終リリース版を指すと誤解されるのではないだろうかと。

「決められた時期」とは、それに限らず、ソフトウェアテスト完了後、システムテスト完了後等、開発中、色々な切り口で定めて良いものである。

「構成管理の対象」が「構成品目」と変更されたのは、まあ、どちらでも良いのではないだろうか。

より以前の記事一覧