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

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

2010年3月

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月15日 (月)

【ソフトウェア品質への期待】漠然と「高度なソフトウェア開発/品質管理をしてくれ」と言われたら

顧客でもユーザ部門からでもよいが、「高度なソフトウェア開発/品質管理をしてくれ」と依頼されたら何をすべきだろうか。

SI会社にとってこの漠然とした問いはきついはず。

もちろんそれまでに付き合いがあれば、それを元に向上案を出すという方法が考えられなくもないが、「高度」みたいな語に込められる「レベル感」というものは曲者である。
初めて関係を持とうとする相手にこれを言われたら、一層難しいものであろう。

まずその問いの真意を聞かねば始まらない。
しかし、
質問に質問返しで答えられそうで難しい。

「なぜ高度な管理を・・・と考えられるのですか?」なんて無防備に聞こうものなら失敗するだろう。
「SIは経営に大きな位置を占めると言われていますよね。でもわれわれはどうすればわからないのです。どうすれば良いですかね」などと返されたら、きつい(と個人的に思う。逆に、それで待っていましたとばかりに回答できるSIerはそういう営業をすべき)。

自組織において、今やっていること、これからやること、やりたいことを常日頃から纏めておくことは重要なことであろう。
後、アンテナ立てて競合レベルの他社状況を把握しておくことも必要であろう。

アドバンスな他社ではなくあくまで自社との競合レベルの他社で構わないだろうが。

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月 8日 (月)

【ソフトウェア開発の定量的管理】なぜか主流はオールドタイプ

ソフトウェア定量的管理に真に有効な手法と皆が認めるものがあれば、ちゃんと国際的に議論され標準マニュアルが定められ公開され、広く活用かつ検証されているだろう。例えばFPの様に。

バグ密度にそれはあるか?

この世界、開発手法や言語は時代の先端を行くものが次から次へとでてくるのに、なぜ定量的管理手法は前世紀からほとんど変わらないのか。

前世紀と変わらないものが多い…と言った方が良いか。
新しいものもあるのに・・・主流は未だに従来型のような気がするのはなぜ。

自分の周りだけなのだろうか。
ならば、私は時代から取り残されている・・・。

2010年3月 5日 (金)

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

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

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

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

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

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

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

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

2010年3月 3日 (水)

【共通フレーム2007第2版】V字モデル再び(適格性確認)

P251「図4-10 適格性確認要求事項と適格性確認テストとの関係」では、またしてもV字モデルが出てくるが、旧版とは異なりそのページの完全オリジナルなV字ではなく、P22「図2-2 品質保証の観点からの設計とテストの対応関係」に似た図となっている。
図2-2を用いているわけではない。なぜかやはり図4-10は図4-1-でオリジナリティが加えられている。

なぜ共通フレームでは、V字モデルを統一しないのであろう。
意図的にばらばらにしているとしか思えない。

図2-2と図4-10を比べてみていただきたい。
そこに共通フレーム策定者の何らかの意図は見えるであろうか。

2010年3月 1日 (月)

【ソフトウェア開発の定量的管理】できるのはそんなものという割切り

やはりよく言われるようにソフトウェア開発には直接測れる物差しが今のところ発見されていないことと人起因およびプロジェクト毎の要件のバラツキが大きくかつ避けられないことが、定量的管理手法を難しくさせる、というかうさん臭くさせるのであろう。

このあたりを解決するためには、現行の管理手法の効率化を探るより、開発手法自体を変えることを考えた方がよいであろう。
自動で欠陥密度が分かり過去データとの統計的比較からプログラムの品質がわかりますといわれても、そもそも欠陥密度の算出方法はそれで良いのか…というような話をまず片付けるべき。

定量的管理の経験発表等で、今後の改善策は測定パラメータを追加し、より詳細に計測していく…というパターンがよくあるが、何か違うと感じる。

パラメータ追加でメトリクスの精度を上げようという試み。気持ちは分かる。しかし、そもそもなぜメトリクス管理を行うか振り返るべき。複雑で混沌としたソフトウェア開発プロジェクトの状況を、特徴的に表すパラメータに着目して人が認識できるようにしようというのが目的のはず。

なのにパラメータ増やしたらまた混沌とするのではないか。バグ密度測るのに2個よりも100個のパラメータ計測したほうが良いと言えるのか。所詮は、発見バグ数を開発規模で割るだけならその程度のものと文字通り割り切った方が良いと思えるのだが。
そもそも、パラメータが多いと何かあったときにどのパラメータの寄与でデータが異常値になっているのかを判別することも難しくなってこよう。

まして1つのメトリクスだけで評価するのではなく複数のメトリクスを見て判断すべきだとか、管理限界を超えた値も一概にダメと決めつけずその原因を追求すべきと予防線をはる定量的管理など労多くして…となりかねない。

大量のパラメータからなるメトリクスデータをこれまた大量に手に入れたとして、それをどうするのか。結局はプロマネやチームで判断するのでしょう。その判断は恐らく定性的に行われると想像される。

ではわざわざ計測した意味はどこにあるのか。定量的管理の使い方を間違っているのではないだろうか。

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