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年11月 | トップページ | 2010年1月 »

2009年12月

2009年12月18日 (金)

【共通フレーム2007第2版】要件と要求〜主観的定義の限界?

P34「要求と要件」にて、第二版から両者の定義を見直し、両者は同じ意味とし、特に合理性や形式性を伴うことを強調するときに「要件」を用いるとされた。

それをふまえて、P87「ガイダンス 1.1.5.2」を見てみよう。

【旧版】
•納入されるソフトウェア製品が要求仕様を反映している
•契約で規定された受入れレビューとテスト要求事項が、成果物の納入に際して適切である

【第二版】
•納入されるソフトウェア製品が要件を反映している
•契約で規定された受入れレビューとテスト要求事項が、成果物の納入に際して適切である

新旧で微妙に違うが、要求仕様は要件に変更されているが、要求事項はそのまま。
P34の定義に従えば、要求事項も要件にすべきでは無いだろうか。

ただ、元々の要求と要件の定義自体も曖昧な点があるので、これで良いと言われればこれで良いのかも知れない。

「特に合理性や形式性を伴なうことを強調するときに」というのは、完全に主観の話なので。


2009年12月15日 (火)

【共通フレーム2007第2版】品質要求事項とは、ISO9000シリーズを指す・・・わけではなくなった

P51において共通フレームの適用例に触れて、「ISO9001に基づいた要求事項をインプットとして、共通フレームを修正する場合もある」と書かれている。

これは、旧版では「品質要求事項とは、ISO9000シリーズを指す。ISO9001は品質マネジメントシステムに対する要求事項を規定している。こういったものをインプットとして、共通フレームを修正することになる」と記述されていた。

旧版では、ISO9001を絶対視していた印象であるが、第2版ではISO9001も1つの方法であるというに留めている。

妥当な修正であろう。

旧版の言い方では「品質要求事項とは、ISO9000シリーズを名指しし、しかもこれをインプットとして、共通フレームを修正することになるのならば、最初から共通フレームを修正しておいてくれよ」という声が聞こえてしまうだろうから。

2009年12月11日 (金)

【共通フレーム2007第2版】ドメインアーキテクチャ」と「ドメインの基本構造」

P43「(g)ドメイン技術プロセス」において「ドメインアーキテクチャ(これ以降、『ドメインの基本構造』と記述することもある)」と書かれている。

これはいただけない。

著作者は、「ドメインアーキテクチャ」と「ドメインの基本構造」が全く同じだと認識しながら、どちらかに記述を合わせる気は無いと言っているわけだから。

ISO翻訳上の制約なのかもしれないが、「共通フレーム」のモデル的な安定感を損う記述である。

「ドメインアーキテクチャ」「ドメインの基本構造」のどちらでも、まあ良いが、どちらかに合わせるべきである(個人的には前者)。

もしくは、使い分ける理由を書くべきである。

今回の改訂では、このような「分かっているにも関わらず、丁寧に対応していない」という箇所が散見される。

【他の例】 「開発」を「開発又は保守」と適宜読み替えろという記述(P7)
       「要求」と「要件」の定義変更(P34)

本書は、レファレンス的に使用されることを想定すべきであるから、どこかに定義してあればOKという発想はすべきではないと思う。

今回の箇所は、旧版にはなく、なぜか第二版で追加された言い訳。
第二版を発行するに際して、旧版に対する指摘対応の時間が足りなかったのだろうか。

2009年12月 8日 (火)

【共通フレーム2007第2版】「再利用施策管理プロセス」ってわかりますか?

P43「(f)再利用施策管理プロセス」が、旧版の「(f)再利用プログラム管理プロセス」から変更となっている。

旧版における「プログラム」は、わざわざ「ここでいうプログラムとは実施計画をさす」と定義されていたが、これを分かりやすいように「施策」に変えたものだ。

ソフトウェア開発で通常言われる「プログラム」とは違う定義の「プログラム」の使用は混乱のもとなので妥当な処置だろう。

ただし、「再利用施策」というのもイメージしづらいし、「再利用施策」の「管理」となると更に難解。

旧版の「計画」を用いて「再利用計画管理プロセス」とすれば…これもイマイチか。

簡単にプロセス内容を表すことは難しいことが多いとするしかないか。

2009年12月 4日 (金)

【共通フレーム2007第2版】「要求」と「要件」②

要求と要件それぞれの定義も、切り口が、大きく異なる。

【旧版】
「要求」:システム化されるかどうかはまだ決まっていない状態にある要望事項
「要件」:システムに実装すべき、かつ、実現の可能性が立証されている要求事項

【第二版】
「要求」:通常の訳語として使用
「要件」:特に合理性や形式性を伴うことを強調するとき使用

しかし、それ以降の記述が、この定義変更により見直されているようには見えないので、現実的には、あまり意識しなくとも良いだろう(重要な用語の定義変更なのだから本当は何も影響がないのはおかしい気もするが)。

「要求」と「要件」…個人的には、旧版の定義のままで良かったと思う。
国際規格的にどうであろうと、共通フレームにおいては両者は別物としても良かったのではないだろうか。

そもそも第二版の定義はためにする定義で、「『要求』を単なるニーズ(②参照)と誤解する危険があるため、その違いを強調する箇所では『要件』という訳語を用いる」などというのは、定義がうまくできれば、誤解される危険が無いはずだから、何のために定義しているのか理解に苦しむ。。わざわざ同じ意味の別の言葉を定義する必要性は感じられない。

実際問題、「ともにrequirementの訳語である」というのなら「要求」に統一すべきであったが、本書では「要件」という言葉が元々多く使われていたこともあり、変えられなかったというのが実情ではないだろうか。

但し、旧版の定義でも、「要求」における「まだ決まっていない状態にある要望事項」と「要件」における「実現の可能性が立証されている要求事項」の違いは考えてみれば微妙。「実現の可能性が立証され」ても、「まだ決まっていない状態にある」と思えるから。

だからこそ、第二版では同じとしたのかもしれないが、ならば全て「要求」にした方が良かったのではないか。

2009年12月 1日 (火)

【共通フレーム2007第2版】「要求」と「要件」①

P34「①要求と要件」において、要求と要件の定義が旧版対比大きく書き替えられている。

第二版では要求と要件は「ともにrequirementの訳語である」とした上で、

「本書では『要求』を通常の訳語として用い、特に合理性や形式性を伴うことを強調するときに『要件』を用いる…略…『要求』を単なるニーズ(②参照)と誤解する危険があるため、その違いを強調する箇所では『要件』という訳語を用いる」

と定義している。

一方、旧版では、

「システム化に対する『要求』と『要件』という言葉は、ともすれば同義語のように使われてきたが、本書では以下のように定義して、使い分ける…(以下略)」

と、第2版とは全く異なる定義がなされている。
そして、旧版では、要求は「…システム化されるかどうかはまだ決まっていない状態にある要望事項」と定義され、要件は「…システムに実装すべき、かつ、実現の可能性が立証されている要求事項」と定義されている。

これは大きな定義変更だと思われるので、それ以降の記述で書き換えが生じて良さそうであるが、それ以降の記述において、特に「要求」と「要件」の見直しがあった形跡は見当たらない。

詳細に見てみよう。

まず全体の考え方としてそれぞれ次のように書かれている。

【旧版】システム化に対する『要求』と『要件』という言葉は、ともすれば同義語のように使われてきたが、本書では以下のように定義して、使い分ける。

=>「ともすれば同義語のように使われてきた」というのだから、「要求」と「要件」はハナから違うものだという考え方といえよう。

【第二版】要求と要件は「ともにrequirementの訳語である」
=>「要求」と「要件」は同じ英語の訳語で同じ意味だと言っている。その上で、「特に合理性や形式性を伴うことを強調するとき」には「要件」を使用するとしている。

旧版で別物と言っていたものが、第2版では同じだと言っている。

« 2009年11月 | トップページ | 2010年1月 »