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年5月 | トップページ | 2008年7月 »

2008年6月

2008年6月30日 (月)

【共通フレーム2007】取得計画を準備することが望ましいの意味するところ

P74「1.1.1.8 取得計画の作成と実行」において「取得者は、取得計画を準備、文書化し、実行することが望ましい」とある。

この文を分解すると、
①取得者は、取得計画を準備することが望ましい

②取得者は、取得計画を文書化することが望ましい

③取得者は、取得計画を実行することが望ましい
となる。
P71では「望ましい」は、「いくつもの可能性の中から一つを推奨する際に使う」と定めているが、そのように考えると①と③は違和感がある。

①取得計画の準備はどんなときも必要でしょう
②取得計画の文書化は、無いと絶対ダメとまでは言えない
③取得計画の実行も、実行する積もりのない計画は立てる意味がないからどんなときも必要でしょう

「取得者は、取得計画を準備、文書化し、実行することが望ましい」は、次の文と同じ意味となるはずだが、共通フレームでは本当にそう言っているのだろうか。

「取得者は、望ましくはないが、取得計画を準備、文書化し、実行しなくても良い」。

2008年6月29日 (日)

【共通フレーム2007】ソフトウェアサービス

P73、74その他で出てくる「ソフトウェアサービス」という言葉。
分からない・・・と思って索引を調べても、P73、74としか書かれていない。

しかしP73、74には「ソフトウェアサービス」という言葉を当然のように使っているだけで定義が書かれていない。

だからといって定義されていないわけではなく、P16で、「ソフトウェアサービスとは、例えばシステムインテグレーションサービスを受けるような場合をさす」と書かれている。

何故、肝心の定義部分が索引に書かれていないのかは分からない。

その意味では、「サービス」と「ソフトウェアサービス」の使い分けもよくわからない。
例えば、以下の例が挙げられる。

P72「1.1 取得プロセス」の目的における「サービス」は「ソフトウェアサービス」のことなのか違うのか。

P73「1.1.1.1 概念又はニーズの記述」では「システム、ソフトウェア製品又はソフトウェアサービス」とあるが次ページの「1.1.1.6 選択肢の検討」では「システム、ソフトウェア製品又はサービス」とある。どのような意図で使い分けているのか。

2008年6月28日 (土)

【共通フレーム2007】ソフトウェア要件の定義と分析

P73から74にかけて、「システム要件の定義と分析」「ソフトウェア要件の定義と分析」が定められているが、なぜか記述方法が異なる。

「システム要件の定義と分析」が比較的丁寧に記述しているのに対し、「ソフトウェア要件の定義と分析」は、説明をはしょった感じがして、記述の粒が揃っていない。

これは、「ソフトウェア要件の定義と分析」は「システム要件の定義と分析」を転用するのは自明だからはしょっていると思われる。

ただ、共通フレームとしては、それならそうと書くべきだし、本来的には自明でも書くべきだと個人的には考える。

2008年6月27日 (金)

【共通フレーム2007】取得プロセスの概念又はニーズはシステム要件の定義で使うか否か

P73 1.1.1 で取得プロセスの開始アクティビティが示される。

1.1.1.1 概念又はニーズの記述
1.1.1.2 システム要件の定義と分析

この両者、「1.1.1.1 概念又はニーズの記述」で記述されたニーズに基づいて「1.1.1.2 システム要件の定義と分析」を行うはずであるが、そのことに言及されていない。ISOの記述を極力そのまま使うのであれば、せめてガイダンスにでも書いておいた方が良い。

2008年6月26日 (木)

【共通フレーム2007】システム要件定義とソフトウェア要件の定義

P72~73において「1.1.1.2 システム要件の定義と分析」と「1.1.1.4 ソフトウェア要件の定義と分析」について記述されている。これらは単に「システム要件」「ソフトウェア要件」と定義対象が異なるだけで、同じく要件定義をするプロセスであるはずであるが、記述方法が全く異なっている。共通フレームの「1.1.1.4 ソフトウェア要件の定義と分析」を活用する場合は、それ単独ではなく「1.1.1.2 システム要件の定義と分析」と「1.1.1.3 システム要件定義の依頼と結果の承認」の内容を「ソフトウェア要件」に準じて読み込んだ上で適用すべきであろう。

また、「1.1.1.2 システム要件の定義と分析」「1.1.1.3 システム要件定義の依頼と結果の承認」では、全社が「システム要件の定義」とあり後者では「システム要件定義」とあるがこれは同じと考えてよい。

同様にP25のV字モデルでは「システム要件定義」「ソフトウェア要件定義」とあるが、この2つのタスクを実際に定義しているのは1.1.1.2、1.1.1.4の「システム要件の定義」「ソフトウェア要件の定義」であると考えてよい。

2008年6月25日 (水)

【共通フレーム2007】取得プロセスの「ニーズ」

P72「1.1取得プロセス」において、4つの「ニーズ」表現があるがこれは同じか。

①顧客が示したニーズ
②顧客ニーズ
③取得ニーズ
④顧客が記述したニーズ

①④は同じであろう。
②が①④を含むが、顧客の潜在ニーズ等の「示されない」顧客ニーズも含むと思われる。
③は①②④とは切り口が異なるニーズであろう。

・・・、と国語上は区別できる。

実際の記述は、この区別を満たしているようにも見えるが、もう少しそれぞれの差をわかりやすく書かないと、「共通フレーム」に準拠しようとする者は間違えた解釈をしてしまうであろう。

そもそも、上で示した解釈が合っていたらの話であるが。

2008年6月24日 (火)

【共通フレーム2007】共通フレームにおける「顧客」

P72「1.1取得プロセス」の目的で「取得プロセスは、顧客が示したニーズを満足する製品及び/又はサービスを得ることを目的とする」とあるが、共通フレームにおける「顧客」とは何であろうか。

P22の表2-1に「共通フレーム上の役割、および共通フレームを利用する実際の組織/役割との関係の例」があるがここにも「顧客」は定義されていない。この表2-1で探せば、「取得者」か「利用者」のことであろう。

さらに、この「1.1取得プロセス」では、次のページで「所有者」という語も出てくる。
これも表2-1「共通フレーム上の役割、および共通フレームを利用する実際の組織/役割との関係の例」には無いのであるが、「顧客」と「所有者」とはどのような関係なのであろうか。

2008年6月23日 (月)

【共通フレーム2007】「発展的に解消」

共通フレーム2007では散見されるのであるが、記述が主観的であるにも関わらず、十分説明されていないためよくわからないものがある。
特に著作者の「思い」がこめられていると思われる部分にそれが顕著に現れる。

P72「ガイダンス」における記述もその一例。

「更に発注側の作業である開発プロセスの業務詳細アクティビティを発展的に解消し、企画プロセス及び運用プロセスへアクティビティ、タスクとして入れ込み強化を図った」

とある。
しかし、どうしてこれが「強化を図った」ことになるのであろうか。
「発展的に解消し」と「入れ込み」のどちらの行為が「強化を図った」ことになるのだろうか。

「発展的に解消し」の「発展的」の表現に「強化」のにおいは感じられるが、「発展的に解消し」という表現では読者は何がどうなったため「強化」されたのかわからない。

そもそも論になってしまうが、「そもそも何が強化された」のかわかりづらい。
よく読むと、強化されたのは発展的に解消した「開発プロセスの業務詳細アクティビティ」とも思われるが、「発展的に解消したものを強化する」というのも難しい文章である。

「更に発注側の作業である開発プロセスの業務詳細アクティビティを発展的に解消し、企画プロセス及び運用プロセスへアクティビティ、タスクとして入れ込んだ」では、なぜ駄目だったのだろうか。

共通フレームを共通のフレームとして活用する者には、「強化を図った」か否かは関係の無い話である点からも「強化を図った」の記述は要らなかったと思われる。

2008年6月22日 (日)

【共通フレーム2007】「Shall」と「Should」

P71では、共通フレームにおいて、「Shall」と「Should」は次のように日本語に訳されているとのこと。
英語では、その2つでしか書かれていないものが、日本語では複数で書かれていることを意識して読むと良い。

Shall : 「とする」「による」「すること」「する」
           =>二人以上の当事者間で定められた規定を表す

Should : 「することが望ましい」「ほうがよい」「するとよい」
           =>いくつもの可能性の中から一つを推奨する際に使う

・・・・、「Shall」と「Should」共に矢印以降の記述は「?」な気もする。
本当にその定義でよいのだろうか・・・と。

2008年6月21日 (土)

【共通フレーム2007】「要件」と「要求」

P49で共通フレームの98、2007の新旧対比があるが、98では「要求」となっていた一部が「要件」となり、「要件」と「要求」で使い分けられている。

この使い分けは、P32で定義されているので再確認すると良い。

2008年6月20日 (金)

【共通フレーム2007】共通フレームの適用例

P47に「図2-16 共通フレームの適用例」という図がある。

しかし、図中のどこにも「共通フレーム」という言葉が出ていない。

この図は、それだけを見れば「共通フレームを適用しない場合の例」としか解釈できないのであるが、どのように見ると、共通フレームが適用されていることがわかるのであろうか。

図中の「JIS X 0160」と書かれた部分を「共通フレーム」と置き換えればしっくりくるので、共通フレームを活用しようとする者はそのように読み替えれば良い。

2008年6月19日 (木)

【共通フレーム2007】ソフトウェア製品の型

P44において「ソフトウェア製品の型」という語が出てくるが、これは何か。

「ソフトウェア製品の型が異なれば修正の仕方も変わってくるので、事前にその型を決定する」とまず書かれており、その「ソフトウェア製品の型の例」として、次の6つが挙げられている。

①新規開発
②既製のソフトウェア製品をそのまま使用する場合
③既製のソフトウェアを修正して使用する場合
④システムに埋め込まれたり、又は結合されたりするファームウェアを含むソフトウェア製品の場合
⑤単体のソフトウェア製品の場合
⑥非納入ソフトウェア製品の場合

まず、これらは排他的ではないので、②および⑤という考えが許される。

それは良いとして、①から⑥は列挙の粒が揃っていない感じがする。
何故①のみ「の場合」が付いていないのか。
①②③はそれぞれ相補関係にあるように見えるが、⑤や⑥については、「単体ではないソフトウェア製品の場合」や「納入ソフトウェア製品の場合」という相補関係となる型が書かれていないのは何故なのであろうか。

型の例はともかく、「ソフトウェア製品の型が異なれば修正の仕方も変わってくるので、事前にその型を決定する」という記述は重要であり、そのためには事前に型のパターンを良く整備しておくことも合わせて重要であることは留意すべきである。

2008年6月18日 (水)

【共通フレーム2007】・・・しているだけ

P43「(4)共通フレームの修正及び適用に際しての考慮点」において、「以下の項目は、主なプロジェクト特性を考慮しているだけであり、必ずしもすべてを言い尽くしているわけではない」とある。

「以下に、考慮すべき主なプロジェクト特性を列挙する」とだけ書いても良いように思われるが、何故このような回りくどい表現をしているのであろうか。

特定の開発対象では最優先で考慮すべきである一方で、別な開発対象では考慮すら不要というプロジェクト特性が、たくさんあるが、それらを列挙するわけにもいかないと判断し、ソフトウェア開発において普遍的に考慮すべきもののみを挙げたためこのような表現になったということが考えられるが、単に表現だけの問題かもしれない。

2008年6月17日 (火)

【共通フレーム2007】品質保証の品質保証

P42「(d)品質保証」では「品質保証は、ソフトウェアの開発又はプロセスの実行に直接責任を持つ者とは無関係の者が実施する」とある。

ここで、共通フレームでは明示的に書かれていないが、「品質保証」自体が共通フレームの「支援ライフサイクルプロセス」であることに注意が必要である。

つまり、「ソフトウェアの開発又はプロセスの実行」の中に「品質保証」プロセスが含まれる。
よって、「品質保証」に対する「品質保証」が共通フレームを「モデルとして厳格に適用した場合」必要となる。

尚、CMMIにおいてはこの「品質保証の品質保証」は明文化されている。

さて、言うまでもないことであるが、念のため品質保証を行える者について言及する。
「品質保証は、ソフトウェアの開発又はプロセスの実行に直接責任を持つ者とは無関係の者が実施する」とあるが、これは、対象プロセスに対して直接的な責任がなければ良いのであって、品質保証チームをプロジェクト内に置くことはもちろん構わないし、同一プロジェクト内で自分が実施・責任の担当となっていないプロセスに対して「品質保証」を行うことも構わない。

2008年6月16日 (月)

【共通フレーム2007】「プログラム」の意味

P39「(3)組織に関するライフサイクルプロセス(f)再利用プログラム管理プロセス」において「組織として、資産(ソフトウェア、テストデータ、メトリクス等)を再利用する活動の計画、管理、制御、監視を体系的に実施するアクティビティからなる。ここでいうプログラムとは実施計画をさす」とある。

第2文の「ここでいうプログラムとは実施計画をさす」はつまり「プログラム」=「実施計画」であり、ならば(f)じは「再利用実施計画管理プロセス」となるが、何かピンと来ない。

ここでいう「プログラム」は、第1文中の「資産(ソフトウェア、テストデータ、メトリクス等)」と解釈して問題ないのではないか。

ソフトウェア開発関連の標準書の中で、わざわざ「コンピュータ用語」である「プログラム」を別の意味で使う必要はないと考える。どうしても何かの語で表したいのであれば、別な言葉で書くべきである。

「ここでいうプログラムとは実施計画をさす」とわざわざ書くのではなく「プログラム」と書かず「実施計画」と最初から書いておけば良いだけであると思うのであるが・・・何かそうすべき意味があるのであろう。

2008年6月15日 (日)

【共通フレーム2007】なぜISOにはあまり反映できなかったのか

P31「(1)共通フレームで拡張、変更した点(c)作業項目の追加①」であるが、「これもISOの場で日本から提案した点であるが、国際規格にはあまり反映できなかった点でもある」とわざわざ書かれている。

これは何を意味するのか。
「なぜ国際規格にはあまり反映できなかったのか」が書かれていない。

この理由が無いと「どうしてISOでは採用されていないのに共通フレームでは勧めるのか」がわからないことになるのではないか。

付け加えると、「これもISOの場で日本から提案した点であるが・・・」とあるが、他の「ISOの場で日本から提案した点」がどこなのかこの文章の周辺では明示されていないため、どのような点のことであるかわからない。

2008年6月14日 (土)

【共通フレーム2007】個別フレームの定義

P28「共通フレームの位置づけ(1)共通フレームと組織標準との関係」において、「組織やプロジェクトには固有の作業標準が存在する」とあり、これを「個別フレームと呼ぶことにする」と書かれている。
そしてその直後に「個別フレームは各社ごとに存在する」と書かれている。

「個別フレーム」に対するこの2つの記述は矛盾しないか。

第一の文では「数社の共同プロジェクトの作業標準」は「個別フレーム」にあたるが、第二の文では「個別フレーム」では無いことになるように見える。

また、第一の文では「ある会社内の部署毎の作業標準」は「個別フレーム」にあたるが、第二の文では「個別フレーム」は会社に一つしか無いように見える。

第一の文と第二の文の意味するところは何なのであろうか。

2008年6月13日 (金)

【共通フレーム2007】動作の主体

P28「5.2共通フレームで取り決めていないこと」では2つのことが列挙されている。

(1)文書化の詳細を規定していない
(2)ソフトウェアの尺度を規定していない

そして、
(1)では、
     「共通フレームを適用する組織又はプロジェクトでは、
      それぞれの特性に応じて文書化の規定を設ければよい」
とあるが、
(2)では、
     「共通フレームを利用する人達が、たとえば品質特性に関する
      規格を利用して、自社の標準に組み入れていけばよいということになる」
と書かれている。

「(1)文書化の詳細を規定していない」のときの主体は「共通フレームを適用する組織又はプロジェクト」で、「(2)ソフトウェアの尺度を規定していない」のときの主体が「共通フレームを利用する人達」と異なるのは、単に繰り返しを避けたためか。

実は、(2)では「共通フレームの利用者」という表現もある。

もし、同じ意味であれば同じ語を使用した方がわかりやすいと思われる。

2008年6月12日 (木)

【共通フレーム2007】「この部分がとりわけ重要である」

P27「(9)修正(テーラリング)の採用」において「共通フレームの適用にあたり、アクティビティ、タスクを取捨選択したり、繰り返し実行したり、複数を一つに括って実行してもよい。この部分がとりわけ重要である」とある。

この「この部分がとりわけ重要である」という記述は何故あるのであろうか。
「共通フレーム2007」における他の部分に比べ、何故「とりわけ重要」なのかが記述されずに重要と言われても読者は読み取れない。

共通化文書として、敢えて「価値的意味」を含む「とりわけ重要」というのであれば、その理由を明記すべきであろう。

2008年6月11日 (水)

【共通フレーム2007】「ソフトウェアに分解」に対する二重の意味付け

図2-6のV字モデルに対する解説において、「システム方式設計によってハードウェア、ソフトウェア、手作業に分解された後、そのソフトウェア部分に対して下段のソフトウェアの要件定義以下、ソフトウェアの開発に移る」とあるが、その4行後に「V字の左半分がシステムをソフトウェアに分解していく設計の過程」とある。

この両者での「ソフトウェアに分解」の意味は異なる。
後者の方が範囲が広い。
ほんの数行の間しかあいていないので注意が必要。

2008年6月10日 (火)

【共通フレーム2007】「システムはソフトウェアを包含する」は定義なのか検証が必要な事項なのか

P24において「『システム』は『ハードウェア』と『ソフトウェア』、『その他設備』から構成される」とある。これは、「システム」「ハードウェア」「ソフトウェア」「その他設備」の関係を定義したものと思われる。

一方、次のP25において、V字モデルの説明をしながら、最後に「この流れからソフトウェアを包含するものがシステムであることがわかる」とソフトウェアとシステムの関係を証明したかのような記述がある。

これは、どう理解すべきであろうか。
P24の定義を図式化したものの一例がV字であると考えることが自然な気がする。

P24の「『システム』は『ハードウェア』と『ソフトウェア』、『その他設備』から構成される」から、「システムはソフトウェアを包含する」というのは定義である。

そうなると、P25「この流れからソフトウェアを包含するものがシステムであることがわかる」というのは、定義をV字モデルを使って再説明した文ということであろうか。

2008年6月 9日 (月)

【共通フレーム2007】ソフト・サービス業者とベンダ企業

ソフトウェアの供給者としての立場である企業を本書では、「開発ベンダ」または「ベンダ企業」と呼んでいる。

この2つはあちこちで出てきており、ほぼ同一の意味として区別されず使用されていると思われる。

一方、P18においては「ソフト・サービス業者」という語が出てくるが、これは他では使われていないようだ。

これも「開発ベンダ」、「ベンダ企業」と同じ意味なのであろうか。
よく読むと違うような気もしてくるので、同じなら「開発ベンダ」か「ベンダ企業」としてほしかったし、違うなら「開発ベンダ」、「ベンダ企業」との違いを書いて欲しい。

尚、「開発ベンダ」、「ベンダ企業」、「ソフト・サービス業者」の3つとも同じ意味であれば、どれか1つに統一するのがより良い選択であると思われる。

2008年6月 8日 (日)

【共通フレーム2007】論理的に説明できるもの

P20「(3)責任範囲の明確化」において、

「企画者、開発者、運用者、保守者などは役割が明確である。しかし、企画した内容が運用に供するか、逆に言えば運用に供せられるように要求仕様を明示したか、それは本来、誰の責任かということを論理的に説明できるものは少ない」

とある。
この文の意味は何であろう。

「論理的に説明できるものは少ない」の真意がわからない。
「論理的に説明できるもの」は1つあれば良くて、複数は要らないと思うのだが。

しかも、「論理的に説明できるものは少ない」と書くだけでその少ないものの手がかりも提示されていないので、読者はそれにあたることもできない。

・・・と思うのであるが、自明であるのであろうか。

2008年6月 7日 (土)

【共通フレーム2007】企画プロセスは誰が行うのか

P20「(3)責任範囲の明確化」において、

経営層は「事業」を行うと記述されている。
この括弧つき「事業」には、図2-2において「システム化の方向性・システム化計画」と「運用・評価」が含まれることが図示されている。
さらに本文中で「企画(システム化の方向性・システム化計画)」と書かれているので、つまり、経営層は「企画」を行うことになる。

一方で、

業務部門は「業務」を行うと記述されている。
この括弧つき「業務」には、図2-2において「要件定義」と「運用テスト」が含まれることが図示されている。

さて、次のページ(P21)まで読み進むと「企画プロセスは、業務部門を含むシステムの企画者の作業」と書かれている。

これは何を意味するのであろうか。

当初の定義では「企画」の主体は経営層であったはずだ。
そして業務部門の説明にサポートとしても「企画」が触れられていないのであるから、業務部門は「企画」に関与しないはずだ。

それが「企画プロセスは、業務部門を含むシステムの企画者の作業」となっている。

どういう意味なのであろうか。
「企画」と「企画プロセス」は別なのであろうか。

「企画」は経営層が主体であるが、サポートとして関与するために「業務部門を含む」と入れたのだ、という理屈は通らなくも無い、しかし、普通に「企画プロセスは、業務部門を含むシステムの企画者の作業」と書かれたら「企画プロセスは業務部門が主体」と逆の意味に取られなくもないはず。

さらに、P21を読み進むと、図2-3で「例」として役割が整理されているが、そこでは「この例では、企画プロセスにおける経営層や業務部門、あるいは情報システム部門がそれぞれ企画者として関与することを想定している」となっている。

前のP20では「ソフトウェア」「システム」「業務」「事業」の「ソフトウェアの4つの層」のうち、「事業」が「企画」の所管であったはずが、P21では例とはいえ、経営層・業務部門・情報システム部門がそれぞれ企画者として関与することになっている。

このあたりの関係はよく理解できない。

2008年6月 6日 (金)

【共通フレーム2007】V字モデルを使って説明する必然性

P20「(3)責任の範囲の明確化」において、「事業」「業務」「システム」「ソフトウェア」各担当の責任を定義しようとしているのであるが、ここでV字モデルを使用して説明がされている。

しかし、これはV字モデルを使わなくとも説明できるものである。
なぜなら、このV字モデルに続く記述で、「企画者、開発者、運用者、保守者」という役割と「企画、要件定義、開発、運用テスト、運用・評価」という責任を負うべき範囲が書いてあるので、それらをマトリクスで表現すれば、ここで言いたかったことは言い尽くせるのではないか。

何故ここでV字をわざわざ使って説明しているのであろうか。
5ページあとでまたV字が出てくるのにも関わらず(しかもここで出たV字と違う表現で)。

2008年6月 5日 (木)

【共通フレーム2007】サービス業者とユーザ企業の相互理解は誰のメリットか

P18に「ソフトウェア・サービス業者の立場からすれば、仕事を受注する場合、作業内容や範囲をサービスメニューとしてユーザ企業に提示するときに共通フレームを参照すれば、相互の理解が深まることになる」とある。

この相互理解のメリットは、「ソフトウェア・サービス業者の立場」だけではなく「ユーザ企業の立場」でも同じく享受できるものであると思える。

何故これが「ソフトウェア・サービス業者の立場」のメリットなのであろうか。
「ソフトウェア・サービス業者の立場」は「ユーザ企業の立場」より弱いということが暗黙の前提にあるからなのだろうか。

もし、「ソフトウェア・サービス業者の立場」のメリットと敢えて書くのであれば、「ソフトウェア・サービス業者の立場からすれば、仕事を受注する場合、作業内容や範囲をサービスメニューとしてユーザ企業に提示するときに共通フレームを参照すれば、ユーザ企業の理解が深まることになる」とした方がしっくりくる。

2008年6月 4日 (水)

【共通フレーム2007】国際取引への対応

P17「4.2 利用方法」に。「(共通フレームの)利用方法を通して、『取引の明確化』,『国際取引への対応』の道が開かれていくことになる」とあるが、何故「国際取引への対応」の道が開かれていくのであろうか。

共通フレームは、国際標準だからということなのであろうか。

もし、ISO12207を基盤にしていることを言うのであれば、共通フレームはISO12207そのものではないので「国際取引への対応」と、ISOに関し何の言及も無く書くのは、共通フレームをこれから学ぼうという者に対しては少々不親切な感じがする。

推測であるが、「共通フレームはISO12207そのものではない」ことを著作者も意識しているので「『国際取引への対応』の道が開かれていくことになる」という少々奥歯にモノがはさまったような表現をしているのかもしれない。

もしくはISO12207に関係なく「国際取引への対応」の道を開く何かがあるのかもしれない。

2008年6月 3日 (火)

【共通フレーム2007】システム開発を直接に取得する組織

「システム開発を直接に取得又は調達する組織」とは何であろう。

P16「4.1(1)直接取引に関わる組織」において、「取得者」の説明に「システム開発を直接に取得又は調達する組織」とあるが、意味が把握しづらい。定義の原文が英語であるのかもしれないが、それならば出典を示したほうが良いと思われる。

これで定義が良いとして、次の(2)において、

「・契約関係作業(システム、ソフトウェア製品、サービスの取得、供給など)」

という記述がある。
ここでの「システム、ソフトウェア製品、サービス」の取得と先の「システム開発を直接に」取得とで、取得する対象範囲はどう違うのであろうか。

同じであれば、最初の記述は、

「システム、ソフトウェア製品、サービスを直接に取得又は調達する組織」

となっているはずなのだけれど・・・・なぜ記述を変えているのだろうか。

2008年6月 2日 (月)

【共通フレーム2007】共通フレームの目的

共通フレームの目的についての厳格な解釈を考えてみる。

P15「1.共通フレームの目的」では、「『ソフトウェア開発及び取引の明確化』が可能となるだけでなく・・・」と書かれている。

一方、P17「4.2 利用方法」においては、「『共通フレーム』は、ソフトウェアを中心としたシステムの開発及び取引の明確化のために利用することが目的であるから・・・」と書かれている。

厳密に解釈をすると、「ソフトウェア開発及び取引の明確化」と「ソフトウェアを中心としたシステムの開発及び取引の明確化」では目的の範囲が異なる。

読み進めば「ソフトウェア開発及び取引の明確化」に限定されていると思われるが、これは単なる書き間違いか、それとも書き分ける意図があるのか。

2008年6月 1日 (日)

【共通フレーム2007】V字モデル(その2)

共通フレーム2007に掲載されているV字モデル(P20でもP25でも良い)は、良く見ると、矢印が書かれている。

一見「ウォーターフォール開発」を示しているように見えるが・・・・共通フレームは特定の技法やツールに無依存として定められている。

矢印が無ければ、仮にこの線が単に直線で結ばれているだけなら、横のレベルでの対応性を示す図として理解できる。しかし矢印であるので、何かの流れを表していることになる。

この矢印は何の流れを表すのであろうか。

実は、2つ目のV字では本文中に「一般的なシステム開発の流れを想定し」と断りがある。
さらに、共通フレーム98では、図中にも矢印に関する注があり「一般的な開発の流れを表す」と書かれていた。

それだけ気にかけているのであれば、最初に出てくるV字の図でも矢印について言及するべきだと思うのであるが、どのような意図で最初に出てくるV字の図にはこの言及をしていないのであろうか。

« 2008年5月 | トップページ | 2008年7月 »