SSL、HTTP/2、レスポンシブWebに対応しました

もっとさっさとやっておくべきであった。

断片 (このサイトのどこかにあるもの)

しかし日本映画が駄目になった原因のひとつはまさにこれであろう。台本通りに喋る技術を持たぬ一方で、科白を勝手に変えられる役者とは、どれほどの偉い役者であろうか。


ホーム > 読んだ >

ソフトウェア構成管理の悪夢
アンチパターン

書誌

authorWilliam J. Brown, Hays W. "Skip" McCormick III, Scotto W. Thomas
editor岩谷宏(訳)
publisherソフトバンク・パブリッシング
year1999
price2400+tax
isbn4-7973-1130-4

目次

1感想
2抄録

履歴

editor唯野
?読了
2017.6.10公開

『アンチパターン』のソフトウェア構成管理(SCM)版である。SCMの扱う範囲が広いのでアンチパターンも割と包括的という印象があり、そのため大雑把という感じも受けた。アンチパターンに限らずパターン本は読むと「それは、あるある」「既に知ってる」となりやすいのだが、本書もそうであるように系統立ててまとめられ全体を俯瞰できるところ、また再利用の容易なところに意義がある。

また、類型化と同時に典型的な原因から解決策まで述べられており、同種の問題に関わる場合には、手がかりを得る上でも有益だと思う。何十年後かにはAIがプログラムを組んでくれる時代が来るのかもしれないが、それでもSCMが不要になることはないだろう。そういう意味では、深みのある話題を要領よくまとめている。

抄録

xiv

-/-なぜなら本書は、ソフトウェアコンフィギュレーションマネージメント(SCM)に関する2つの基本的な事実を明らかにしているからである。

1. SCMは複雑難解ではない。SCMは、人間の常識で理解できる知恵と技法の集まりである。
2. SCMを計画し実施することによって、プロジェクトを大きなしっぱの可能性から護ることができる。

5

アンチパターンの定義は「至る所でよく見かける、必ず否定的な結果をもたらす問題解決手法」である。言い換えるとアンチパターンは、業界の各所で頻繁に繰り返されている愚行、間違い、病的慣行等の総称である。アンチパターンは3つの主要部分から成る。

  • 問題の実例とその名前(たとえば「砂上の楼閣」) : アンチパターンのこの部分は、問題の一般的な性質――至る所で頻繁に起きているという性質を、印象的なネーミングにより指し示す。
  • 問題の再構想解 : 各企業等で再利用可能なソリューション。
  • パターンの一般的な構造と形式を表すテンプレート。

p7~12において本書におけるパターンとアンチパターンのテンプレートが示されている。(再構想解の)名前、別名、頻出スケール、解・再構想解のタイプ、根本原因、対応不全の圧力、挿話証拠。また、これらに対する背景、一般形式、症状と結果、典型的な原因、例外的なケース、再構想解、変種、例、関連解、そのほかの視点やスケールへの適用性、参考文献。

15-16 cf.13

-/-クォリティは、良質なソリューション以上のものである。クォリティは、目標として掲げるべき一連の基準であり、再利用性に富む優れたソリューションに必ず備わっている資質である。そのパタンを読んだ人に現実的な問題への応用性がすぐにひらめき、それらの問題に実際に容易に適用できる、クォリティの高いパターンの制作に、今後のわれわれは努めるべきである。クォリティの現実を支える基準は、パターンの実用性を問う次のような質問に要約できる。 ・現実性 : そのパターンが解決する問題を、現実の中に容易に同定できるか ? ・具体性 : そのパターンは抽象的でない具体的で実際的なソリューションを記述しているか ? ・実用性 : そのパターンは実際に問題を解決したか ?

22

-/-本書でとくに集中して扱う分野は、ソフトウェアコンフィギュレーションマネージメント、要件分析(要件開発、要件管理)、および試験である。これら3つの規律的分野は、システムの全ライフサイクルにわたるソフトウェア開発過程において、最も基盤となる管理と制御の部門である。これらの工程部門は、Software Engineering Institute (ソフトウェア工学協会 、SEI)の Software Capability Maturity MOデl (ソフトウェア能力の成熟度モデル、SW-CMM)の定義の中で、「レベル2の重要工程領域 : 反復性 (Key Process Areas (KPAs) for Level 2, Repeatability)」と名付けられている。 この後にCMMの各レベル定義の表がある。

24 cf.26

ソフトウェアコンフィギュレーションマネージメント(ソフトウェア構成管理、SCM)は、システムを構成するソフトウェア(群)の進化を管理し制御する管理過程である。SCMは、次のような機能から構成される。
    ・コンフィギュレーション成分と機能成分間のインタフェイスの識別同定 ・上記の成分とインタフェイスに関するドキュメンテーション(文書化) ・ソフトウェアのコンフィギュレーションの制御 ・制御の実践をドキュメンテーションに照らして監査

27

ソフトウェアコンフィギュレーションマネージメントの歴史と由来 1970年代には、マイクロプロセッサの普及と共にソフトウェアがハードウェアとは別の独立的な製品と見なされるようになり、それに伴って、ソフトウェアコンフィギュレーションマネージメント(SCM)という課題意識が芽生えた。70年代以前にもさまざまなシステムでコンピュータとそのソフトウェアは使われていたが、その時代にはソフトウェアの構成管理は常識に基いてその場凌ぎ的に行われ、標準工程として確立していなかった。しかしやがて次第に、ハードウェアに適用されていた開発の方法論やパラダイムはソフトウェア製品に適用できないことが、自覚されてきた。 合衆国国防総省(U.S.Department of Defence, DoD)がこの方面でリーダーシップを発揮し、ソフトウェアの開発工程/過程の規格としてDoD-STD-2167を作成した。当時DoDは、システムのメンテナンスが、技術を理解している人材の確保とメンテナンスの費用の2つの点で難しくなりつつあることを自覚していた。そこでDoDは、プログラミング言語の標準規格―Ada―の導入と、開発管理と構成管理の方法に関する標準規格を確立することによって、その事態に対応しようとした。 民間企業も、システムのソフトウェア成分の構成管理のための新しい方法の開発に努力していた。それらの企業の多くが、DoDやそのほかの政府機関の大規模システムの開発に関与していた。最終的には、DoDが民間の慣行の一部を採用することにより、IEEE/EIA12207が生まれた。

28 cf.92

-/-ユーザは要件文書を自分たちのニーズが満たされるための保険証書と見なし、デベロッパはそれらを、ユーザが求める機能性を自分たちが達成した証拠として利用する。要件が頻繁に変わったり、ユーザが新たな技術の導入を要求することの多い長期的な開発事業では、とくにこの点が重要である。要件ベースラインのステータス変化を正しく追跡管理し文書化することによって、ユーザの新たな要求が開発過程の全体に及ぼす複雑な影響をユーザに理解させ、開発の遅れとその理由をユーザに納得してもらうことも可能である。 なお、さまざまな分野の人材によって構成される混成的なプロジェクトチームは、どんなに小さなチームであっても、全員の努力目標を明記した要件文書がなければ成功はおぼつかない。-/-

30

試験はシステムが一応動くことを実証するだけでhなくて、システムが設計と設計意図とユーザのニーズに正しく即して動作することを実証しなければならない。試験にパスすることが、開発チームにとって最終的な報賞であり、またユーザとメンテナーが展開後のシステムの正しい動作を確信できるためにも試験は必要である。すなわち試験は、システムの動作や操作性に関する、受け入れレベルにおける = ユーザサイドに立って行われる検証作業である。試験を経ることによってプロジェクトチームとユーザの双方が、システムのライフサイクルを次のステップへ前進させ、設計がユーザのニーズを満たしていることを確信できるのである。

35

「なんとかなるさ(Nil Desperandum, 絶望無用)アンチパターン」は、ソフトウェアエンジニアリングの欠如を指す。これは男性によくある、傲慢で横柄で尊大な態度であり、あらゆるアンチパターンの源泉である。-/-

36/

アンチパターン群。
    ・なんとかなるさ

38

-/-とにかくこの状況の最大の特徴は、開発過程~工程がいっさい文書化されず、なにもかも雑談的に進行し、したがって一貫性を欠いていることである。この方式では、目的ソフトウェアが完成し引き渡しできる見通しがきわめて危うい。というより、最初から最後まで、何もかもが適当でいいかげんなのである。 不足した工程の追加、アーキテクチャの整理、コーディングルールの適用、試験といった解はp40-43。

58-59

SCMに関わるアンチパターン群。
    ・万能特効薬アンチハパターン(Silver Bullet AntiPattern) 単一ツールでの全問題の解決という誤った信念 ・CM独裁化アンチパターン (CM Takeover AntiPattern) 管理のための管理による組織の硬直化 ・デベロッパがSCMに手を出すアンチパターン (Developper-Software Configuration Management AntiPattern) SCMを専門部署で行わないとき ・CM権限バラバラ化アンチパターン (Decentralized Configuration Management AntiPattern) 開発管理とSCMの中央集権化 ・監査失敗アンチパターン (Failure to Audit AntiPattern) SCMの一部分を実装しなかったとき ・オブジェクト指向CMアンチパターン (Object-Oriented Configuration Management AntiPattern) OOPでのSCMの重要性 ・SCMの自称専門家アンチパターン (Software Configuration Management Expert AntiPattern) SCMを門外漢に任せたとき ・泥縄計画アンチパターン (Postmortem Planning AntiPattern) SCMにおける計画とフォローの重要性

61 cf.62

-/-社長~経営陣の視野の中で、ソフトウェアコンフィギュレーションマネージメントの目標がつねに真っ正面の前方に正しく見えていることが、このパターンの最重要事項である。このことは、プロジェクトの規模の大小とは無関係である。基本的にSCMの目標とは、問題を事前に正しく摘出すること、それらの問題を制御し解決すること、進捗状況を管理すること、そして過程と結果の監査である。社長以下、経営上部機構がこれらの目標を理解していれば、SCM専任組織の使命と目標もまた、自ずから理解できるのである。すなわち、SCMを正しく理解している経営者は、必ずSCM専任組織を社内に設ける。 SCM専任組織は、正規の部署として、最初から企業の組織構造の中に正しく位置づけられていなければならない。個別的なSCM、すなわちここのプロジェクトごとにそのプロジェクトの責任でSCMを行なうという方式は、SCMを担当する者の権限と責任を希薄にするだけでなく、満足な結果を達成できないことが多い。-/-

64

ソフトウェアコンフィギュレーションマネージメントを企業レベルで計画化するときには、規格が重要な検討項目のひとつである。規格は、コンフィギュレーション制御が何と何を制御するのかを明文化していなければならない。ソフトウェアコンフィギュレーションマネージメントに関する企業内規格――“ソフトウェア構成管理計画”とも呼ばれる――は、企業全体の組織構造の中に正しく位置づけられたSCM専任組織の目標を強化する。-/- 規格は、コンフィギュレーション制御の対象となる項目と、それら各項目の制御の基準を明記していなければならない。すなわち各項目に関する制御の規格は、何と何をどこが(誰が)どこまでやったら製品のリリース過程に移行してよい、という点を明瞭に定義していなければならない。また、その判断を行なう有権限者と責任者を明記していなければならない。 計画課にあたってはまた、ステータス(状態、進捗状況)の報告と監査の両方に関しても、議論が行われなければならない。ステータスの報告も、SCMの一環として専任の部署が行うべきである-/- ..67.. ソフトウェアコンフィギュレーションマネージメントの未経験者は往々にして、プロジェクトを失敗に導く無効で非現実的な方法を採用しがちである。最も多い非現実的な手法は、SCMツールに頼ったソフトウェア構成管理計画を実施することである。この方法が失敗であることを、プロジェクトチームが自覚することは容易ではない。またSCM製品のベンダたちは、彼らのツールがすべての問題を解決し、さらに総合的なソフトウェア構成管理計画の確立を支援する、と誇大宣伝している-/- アンチパターン : 万能特効薬の症状。

70

ツールに頼ったコンフィギュレーション管理の結果として、非常に多様な症状が発生し蔓延している。おそらく最も多い症状は、ソフトウェア製品に関する共通的なベースラインの欠如と、ベースラインの変更に関する制御の不在である。-/-

71

再構想解は、ツールを選ぶ前にソフトウェア構成管理計画を策定することである。それによってツールの要件も自ずから決まるし、またソフトウェアコンフィギュレーションマネージメントの過程の中でのツールの使い方も明確になる。-/-

75

-/-往々にして上司の考え方を変えるための唯一の方法は、その特効薬が効かないどころか病気を一層悪化させるという物理的な証拠を提示することである。ただしそのような証拠は、病気が重症化して被害をはっきりと文書化できるような段階にならないと、得られないのである。

76

ソフトウェア開発は、プロジェクトマネージャ以外の人間が引き渡し過程と関連資源(とくに人月資源)を支配すると難航する。-/-

79

このアンチパターン(CM独裁化)の原因。
    ・開発工程が不明瞭 ・管理者が非力 ・CMマネージャの我が強い

80

上記の例外ケース。 本社の管理部門と開発現場が地理的に遠く離れているような場合、たとえばいわゆる“オフショアコーディング(コーディングの海外移住)”のケースでは、むしろ強力な権力を発揮するCMマネージャを見つけだすことが絶対に必要である。 再構想解。 この問題に対しては2つの解決策があり、その2つは互いに、問題のとらえ方の視点が根本的に異なっている。最初の方法は、開発工程を細部まで明確に定義することである。-/- 第二の解決策は、そのCMマネージャを外すことである。-/-

87

アンチパターン : デベロッパがSCMに手を出す -/-デベロッパはソフトウェアを“製品”として開発することが仕事であるが、SCMの業務の中心はドキュメンテーションである。二兎を担わされたデベロッパは、ソフトウェアとその文書表現という二兎をつねに追わなければならない。したがって開発チームにソフトウェアコンフィギュレーションマネージメントの実行を期待すると、開発が成功するために必要なチェック&バランスが達成されず、また関連ドキュメンテーションも不十分になり、悲惨な結果が保証される。

88

-/-開発会議やプロジェクト会議において、チーム内のあるデベロッパやデベロッパ小グループが一方的に設計変更を行い、そのことを正規のコンフィギュレーション制御文書に記載せず、したがって変更が公式化されなかった場合にこのアンチパターンが起きる。-/-

89

開発チームが開発の初期の段階でSCMを忠実に実施していた場合でも、迫り来る納期に追われる開発の後期になると、その努力もおろそかになりがちである。開発チームはそのういうとき無意識の内に、SCMのような管理業務を捨ててプログラミングという実作業に傾注する-/-

91

小さなプロジェクトが、その後次第に大きなプロジェクトへとスケールアップしていくことがある。この変化が徐々に、気づかれない内に進行することもある。そのようなプロジェクトでは、専門担当部門による本格的なソフトウェアコンフィギュレーションマネージメントが執行されなかったことが、後々になってシステムにマイナスの影響を及ぼすことがありえる。

97

アンチパターン : CM権限バラバラ化 -/-リポジトリは、情報の共有化と再利用のための中心的な要素であり、単一の開発はもとより、複数の開発や全企業レベルにわたってもリポジトリの整備は重要である-/-

103

企業のリポジトリの情報。
    ・再利用コンポーネントの依存性(パッケージ図) ・再利用コンポーネントの仕様(インタフェイスクラスのモデルとステート図) ・対顧客インタフェイスの仕様・汎用コンテナの仕様 ・再利用コンポーネントの利用シナリオ(ユースケース図) ・対顧客インタフェイスと汎用コンテナの利用シナリオの統一像

113

アンチパターン : 監査失敗 構成管理は、管理対象の同定、対象の制御、ステータス報告、および監査という4つの基本要素から成り立つ。-/-

114

したがって監査の基本は、次のような条項である。
    ・試験の手続きと試験の結果を検証する-/- ・ドキュメンテーションが完全で規格に適合していることの検査 ・ソフトウェアが設計を正しく反映し、設計が要件を正しく反映していることの検査 ・リポジトリが正しく管理されていて、そこにあるソースファイルからのコンパイルが無事にできることの実証 ・運用マニュアルとサポートマニュアルの内容が完全で正しいことの検証

115

コードを正しく反映していない不正確なドキュメンテーションの結果として、運用費用とメンテナンス費用の増大。これの類似ケースとして、教育訓練ドキュメンテーションの欠如または貧困の結果、ヘルプデスク(カスタマサポート)部門の費用増大と、開発の規格を順守していないコードの生産。

116

-/-また、小規模な開発ならば監査を省いてもよいということは、過去のいかなる事実によっても立証されていない。-/-

121

実際の監査は、鋼製制御と同レベルの権限で行われるべきである。-/-

126

アンチパターン : オブジェクト指向CM -/-しかもまた、オブジェクト指向開発は段階的/反復的な開発過程なので、複雑性が次のような原因で増幅する。
    ・仕様設計が実装設計を支配する。インタフェイスが内部の機能性を決める。 ・実装設計がコーディング――最終的なコード仕様――を支配する。 ・一部の補助的クラス(ヘルパークラス)が設計から漏れていたときには、コーディングが実装設計を支配する。 ・ネイティブ言語の制約によりインタフェイスを変更しなければならないときには、実装設計が仕様設計を支配する。

131 cf.140-141

ソフトウェア開発のすべての側面に対してソフトウェアコンフィギュレーションマネージメントを執行することが、要件を満たしユーザの期待どおりに動作する製品を確実に作り上げるための必須条件である。-/-

132

-/-言い換えると、複数の設計が正しくかみ合っている状態を確立し確認する。設計のあらゆる側面を、統一化という基準に基づいて徹底的に評価検討する。-/-

144-145

チームは、こういうことが二度と起きないようにするために、3つの重要工程 : 計画、設計、およびソフトウェアコンフィギュレーションマネージメントによる監査の過程を抜本的に刷新した。 <h5>計画</h5> 今後の計画はすべて、設計とコードのバージョンを明記し、総合化及び総合化試験に際してのバージョン依存性を詳しく記さなければならない。-/- <h5>設計</h5> 今後の設計はすべて、すべての実装クラスとライブラリに関してクラスモデルを作ることと、すべてのランタイム実行パスに関してイベントトレースを作ること、ならびにすべての複数ステートオブジェクトに関してステート遷移図を作ることを必須とする。-/- <h5>ソフトウェアコンフィギュレーションマネージメントによる監査</h5> 今後の監査過程は、プロジェクトの計画、および設計とコーディングの中の節目的な工程をすべて捕捉する、相当大規模な作業になる。-/-

149

アンチパターン : SCMの事象専門家 -/-しかしこの分野では知識と経験の落差が非常に大きいことを、理解しなければならない。ソフトウェアコンフィギュレーションマネージメントの専門家を自称する人物は、実際にSCMの仕事をするのは今回が初めて、という場合が非常に多い。-/-

151-152

症状。
    ・プロジェクトのドキュメンテーションも鋼製制御の対象である、という認識がない。 ・変更を対象別に個別ばらばらに行おうとする(各文書、コード、要件など)。統一的一貫的な変更管理の概念と方法論がない。 ・ソフトウェアのリリース権限を構成管理部門がもつことを知らない。 ・制御対象項目に関するリポジトリを設けない。 ・制御のレベル(程度、基準)を指定できず、また構成項目を正しく同定できない。 ・鋼製制御過程、SCMスタッフ、変化を知らせるための手続き、およびドキュメンテーションの仕様が正しくない。 ・“ベースライン”要件とは何か ? と問われて説明できない。 ・監査の手続きとスケジュールを指定できない。 ・変更(change)と逸脱(deviation)と部分的放棄(waiver)、この三者の違いを説明できない。 ・ステータス報告について説明できない。 ・要件管理を実施しない。 ・正しい計画書を書けないか、または計画のベース(たとえばIEEE828-90)を説明できない。 ・構成管理の基本要素を正しく列挙し説明できない。

159-160

-/-MaConnellは、要件に求められている機能性の開発に確実に成功するための開発ステップとして、次の項目を挙げている-/-
    ・ユーザインタフェイスとプロトタイプの評価検討 ・ユーザマニュアルと要件仕様書の評価検討 ・アーキテクチャの評価検討 ・詳細設計の評価検討 ・ユニット試験 ・綜合化試験 ・日例負荷試験-/- ・システム試験 ・製品リリース

168

アンチパターン : 泥縄計画 ソフトウェアこふぃぎゅレーションマネージマントの過程は、細心の計画と管理を欠いていた場合には、驚くほど複雑困難な過程に一変する。逆に、細心の計画に基いて毎日の細かい管理が行き届いていた場合には、SCMは非常に楽な仕事のように見え、構成計画なんて本当は要らなかったんじゃないか、という誤解を人びとに抱かせることすらある。-/-

171

このアンチパターンの主な原因は、事前に計画を作らないことである。-/- 症状についてはこの前に説明がある。

174

-/-すなわちその母体的なSCM計画は、具体的なSCM計画を作るためのあくまでもテンプレートである。これらの項目を、プロジェクトの特殊性具体性に合わせて記述していくときには、実際に行なわれている工程を記述するように心がける-/-。次にそれに、現在のデベロッパたちにあまり負担をかけずに導入できる新たな工程を定義して加える。-/-

175

上記の特定化された文書を一般化していく。 またこの計画書の中で、企業の全部門的ないし全社的な鋼製制御委員会(configuration control board, CCB)の設営を明記する。-/-

183

パターン : P2(二乗) ソフトウェア開発は先ず第一に、有能な人材に依存する。そして第二に、適切な組織構造に基づく実践的な工程に依存する。とくに、大規模で分散的な開発では、この2点を重視することが、成功への鍵である。

187

工程は実践的でかつ、目的にマッチしていなければならない。言い換えると工程は、最小の形式で最大の利益をもたらすものでなければならない。工程計画は、以下の項目を定義していなければならない :
    ・開発の各段階(phases)と作業明細(tasks) ・各段階に入るための基準(ゴーサイン基準) ・作業明細とそれら各作業からの引き渡し物(生産物)の間の、関係の明確化と順序化 ・役割分担とそれらの役割が担当する工程/作業の明確化 ・評価検討と決定を行う時点の明確化

195

アンチパターン : 冷戦 開発ライフサイクルの全体にわたって複数の工程間の均衡を図ることは、非常に重要である。往々にして個別の工程が自己を必要以上に過大評価してほかの工程を支配し、開発全体の主導権を握ろうとすることがある。これを避けるためには、各工程のオーナーシップを明確にすること、ランタイムに各工程を調整して、誤認や衝突を未然に防止することが必要である。

204

アンチパターン : 事なかれ主義 「事なかれ主義アンチパターン」は、意思決定者が、衝突を避けることが問題解決よりも優先する、と判断したときに生ずる。-/-

205

このアンチパターンの典型的な主要原因は、衝突は悪いことである、衝突は避けなければならない、という誤った概念である。-/-

207

-/-デベロッパにとって重要なのは、問題と人とをはっきり区別することである。問題は徹底的に議論すべきである。しかし、人間を攻撃してはいけない。-/- 解決方法は二種類ある : それらは、管理的解決と自主的解決である。管理的解決は、適切な技術マネージャまたはラインマネージャの公式の意思決定により、構想を直接的に解決し制御する。自主的解決は、管理職~マネージャが関与せず、衝突の当事者も含む技術スタッフだけで解決を探す。 自主的解決の手段として本書ではこの後に、紙玉投げ(spiwad)、タイガーチーム(tiger team、特殊部隊)、類縁図(affinity diagrams、KJ法)を挙げている。

219

アンチパターン : 企業システムの虚構 現場(ライン)に引きずられ、現場に牛耳られている企業があまりにも多いために、企業システム(エンタプライズシステム)“らしきもの”すら実現している企業はきわめて少ない。-/-

223

対策は2つの部分から成る : 1. 全社的管理 2. 全社的アーキテクチャの実践

224

EAOの役割は、全社的アーキテクチャと全社的ロードマップを定義することである。全社的アーキテクチャ(enterprise architecture)は、次の項目から成る :
    ・システム、アプリケーション、およびエンタプライズコンポーネントのインタフェイスの仕様。 ・既存のシステムやあぷりけーしょんとの情報交換形式。 ・プラットホームの仕様。 ・アーキテクチャのパターン。 ・エンタプライズオブジェックトとエンタプライズコンテナ。 ・エンタプライズコンポーネント。 ・プロジェクトの実装ガイドライン。 ・エンタプライズシステムのために利用する/できる商品製品。 ・企業的/全社的セキュリティ。 ・パートナー企業等との接続性/統合化。

230

したがって企業のロードマップは、どのプロジェクトが全社的コンポーネントを作って、アプリケーション間およびシステム間のインタフェイスを提供するか、ということに関する計画である。-/- ...237. アンチパターン : 要件虐待 不幸にして要件定義は、まったく行われないか、または構成管理に正しく手渡されないことがあまりにも多い。-/-

239 cf.242

自信過剰な開発チームと経験不足なプログラムマネージャが、このアンチパターンの原因であることが多い。-/-

243

このアンチパターンの例外は知られていないし、いかなる文献にも登場していない。このアンチパターンには、いかなる言い訳もありえない。

248

パターン : 情報整合化管理 情報の整合性(information integrity, 情報の真正性)とは、情報の正確さ(accuracy)、時宜性(timeliness)、および適切性(relevancy)を指す。-/-

255

情報管理システムの中身を提供するのが発行者であるから、戦略家とデベロッパは情報の発行を支援するツールやプロセスだけではなく、発行者が情報の真正性と整合性を検証できるためのツール等の普及に努めるべきである。-/- ここでの登場人物としてデベロッパ、発行者、戦略家、ユーザがいる。

259

情報整合化管理のプロセス。 ステップ1 : 情報空間の境界を定義する ステップ2 : 情報空間の目的を定義する ステップ3 : 責任配分の決定 ステップ4 : 情報のフローのプロセスと機構の決定

265

アンチパターン : 開けてびっくり この問題には、3つのお互いに関連した原因がある。まず第一に、工程の各段階の終了基準と開始基準を明確に定義した工程定義(工程計画、工程規格)がないことである。第二は、肯定定義があってもそれが無視されていることである。それが、第三の最後の理由に導く : すなわち、工程のオーナーシップや責任者の不在である。-/-

266

ここ(再構想解 : 唯野注)には、2つの視点がある。第一は、将来のプロジェクト開発でこのアンチパターンが起きないようにすること(すなわち予防)。第二は、今すでにこのアンチパターンが起きているので、そのソフトウェアを無事に引き渡しまでもっていきたい、という状況である。

275 cf.273

アンチパターン : 心頭滅却 このアンチパターンは通常、経験不足または自信過剰な開発チームによってもたらされる。実際には、どんなに単純な開発努力でも、何らかの試験が必要である。-/-

277

ここで注意すべき重要なことは、多くのプロジェクトチーム、とくにプロジェクトリーダーは、システムの失敗を認める前に必ずそれを否認する、ということである。-/-

285

アンチパターン : 期待過剰 副長の忠告を、私は今でも覚えている : 「少尉(当時の私の階級)、きみが確実に知っていることは、きみが自分で検査したことだけだ」。このプロセスの有効性を私が完全に理解したのは、その後もっと歳をとってから(賢くなってから ?)のことである。そして今日の私は、この手法をソフトウェア試験に応用することを考えるのである。

287

このパターンの症状。
    ・試験計画がない。または、あるにはあるが詳細でなく、開発サイクルの中に正規に組み込まれていない。 ・管理者たちは、すべてがスケジュールどおり進んでいると思いたい。デベロッパたちは、彼らに本当のことを言うのを嫌がる。管理者たちにばれる前にスケジュールに追いつくと思って、デベロッパたちは嘘を報告する。 ・デベロッパが自分で書いたコードを自分で検査している。 ・コードの模擬演習(walk-through(s))が行われていないか、行われているとしても、その能力のない非専門家によって行われている。 ・設計の模擬演習を重視して、それにより試験を省略できると信じている。

291 cf.289

以上の方法を忠実に実施するための最良の方法は、試験過程を系統的に計画化することである。それにはある程度の費用と時間を要するが、試験計画は別立ての見積もり項目にするのではなく、むしろ系統的な試験計画をあらかじめ作成し、開発契約の一環として最初から承認を得るべきである。そのために要した費用と時間は、システムの全ライフサイクルにわたる大きな節約をもたらす。

302-310

全体のまとめ。

316-317

訳者あとがき。ここではソフトウェア構成管理 = ソフトウェアコンフィギュレーションマネージメント = SCMの要素として、バージョン・開発環境・ビルド・工程の4つの管理を挙げている。、

Up