Hatena::Groupprogram

桜、抹茶、白、日記(支店)

2010-05-03

[Memo] MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMSの翻訳 はてなブックマーク -  [Memo] MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMSの翻訳 - 桜、抹茶、白、日記(支店)

g:program:id:youandi:20100502

頑張って翻訳してみましたが、直訳すぐるwww。

名古屋アジャイル勉強会 > ウォーターフォール調査/Royce論文

http://groups.google.co.jp/group/nagoyaagile/web/royce

http://sites.google.com/site/nagoyaagile/Home/katsudou/u-otaforuchousa


*1

大規模なソフトウェアシステムの開発の管理

ウィンストン・ロイス博士

序論

私は、大規模ソフトウェア開発についての個人的な見解を述べたいと思う。

私は過去9年の間にいろいろな任務を持ちました。主に宇宙船のミッション計画・ミッション指示や飛行後解析のソフトウェアパッケージの開発に携わっていました。

これらの任務において、私は稼働状態・納期・予算の達成に関して異なる度合いの成功を経験しました。

私は自身の経験から偏見を持つようになり、私はこの発表でこれらの偏見について話をしたいと思う。

コンピュータプログラム開発の役割

全てのコンピュータプログラム開発には、規模や複雑さに関係なく共通して2つの重要な工程がある。

図1に示すように、最初は分析工程で、続いて2つ目に実装工程である。

この種の非常に単純な実施概念は、実の所、成果が充分に小さい事と、典型的な社内向け用途のコンピュータプログラムのように最終的な製品の作成者が利用者となる事が必要とされる。

両工程が直接最終製品の有用性に寄与する純粋に創造的な作業の要件となるが故に、これはまた多くの顧客が喜んで支払いを行うある種の開発成果である。

大規模ソフトウェアシステム製造の実施計画が、これらの工程にのみに合わせるのであれば、失敗する運命にあるだろう。

多くの付加的な開発工程が必要となるが、それらは最終製品の分析・実装に直接的に何も寄与しないし、全て開発コストを吊り上げる。

顧客側の人々は、一般的にそれらの工程に支払いたくないであろうし、開発側の人々はそれらの工程を実施したくないだろう。

経営陣の主要な役割は、これらの概念を顧客側と開発側の両陣営に売り込み、そして開発側の人々の一部に遵守を徹底させる事である。


図1. 社内向けの小規模のコンピュータプログラムを達成する為の実行工程


より壮大なソフトウェア開発の手順は図2に図示した。

分析・実装工程はまだ見えているがしかし、両工程は2段階の要求分析の後にあり、そして間にプログラム設計工程があり、続いてテスト工程がある。

これらの付加工程は、プログラム資源の効率的な利用の為に計画・人員配置される。

図3は、この体系の為に連続した開発フェーズ間の反復的な関係を描写します。

各工程の順序は次の概念に基づく:

一連の順序における前後の工程の反復や稀により離れた工程との反復を通して、各工程が進むにつれて設計は更に詳細なものとなる。

これらの長所は、設計の進行において、変更工程が対処可能な限度まで機会がある事である。

要求分析完了後の設計工程のどの時点においても、確認や監視、不測の設計障害の場合にいずれかの工程に戻る為に基線への移動がある。

我々が持っているものは、救出・保護可能な初期の作業の範囲を最大にするのに役立つ効果的な予備の見解である。


*2

図2. 顧客へ受け渡す大規模コンピュータプログラムを開発する為の実施工程


私はこの概念を信じます、しかし上述の実施は危険で、失敗を招く。

問題は、図4の中で図示する。

開発サイクルの最後に行われるテストフェーズは、タイミング・記憶装置・入出力転送等が分析から分類されたと感じる最初のイベントである。

これらの事象は、正確に分析可能ではない。

これらは、例えば数理物理学の標準的な偏微分方程式の解答でない。

まだこれらの事象が様々な外制約を満たすことができないならば、例外なく大幅な再設計が必要である。

単純な8進値のパッチや幾つかの隔離したコードの再実装ではこの種の障害を修復できないだろう。

全てを冒涜する為の基礎設計や論理的根拠を規定したソフトウェア要求により必要となる設計変更は破滅的になるだろう。

要求の修正又は設計の相当な変更のどちからが必要である。

事実上、開発工程は開始点に出戻り、それはスケジュール超過や予算超過を100%予測させるだろう。


人は、分析・実装フェーズを飛ばす事に気が付くかも知れない。

もちろん、人はこれらの工程なしでソフトウェアを製造する事は出来ない。しかし通常これらの工程は、比較的安易に管理されており、要求・設計・テストの比重は小さい。

私の経験上、これらは軌道力学宇宙船飛行姿勢決定・ペイロード活動の数学最適化等の分析に費やされる全部門である。しかしこれらの部門は難題かつ複雑な作業を完了した時、結果としてのプログラム工程には数行の一連の算術コードが含まれます。

彼らの難題かつ複雑な作業の実行において、分析工程担当者が間違いを犯したならば、その訂正は他の開発基盤に破壊的な影響を与える事のないちょっとしたコードの変更で実施される。


しかしながら、私が図示した手順は、基本的な事であると思っている。

この議論の残りでは、開発リスクと取り除く為にこの基本手順に追加されるべき5つの付加的な特徴を明らかにしている。


*3

図3. 願わくば、種々の段階の反復的な相互作用は連続した工程に限定する


図4. 残念ながら、図示した工程のように、設計の反復は連続した工程に限定される事はない


*4

STEP 1: プログラム設計を最初に行う

理解の為の第一歩を図5に図示する。

プログラム前設計フェーズはソフトウェア要求作成フェーズと分析フェーズの間に挿入される。

この手順は、プログラム設計担当が分析結果が存在しない最初のソフトウェア要求に比例して白紙の設計を強制される根拠に関して非難している。

その結果、前設計は設計担当が分析完了を待った設計結果と比較すると、かなり間違っているかも知れない。

この非難は正しいが、それは論点が間違っている。

この手法によって、プログラム設計担当はソフトウェア記憶装置・タイミング・データ等の流動的要因によって失敗しない事が保証される。

分析が後続の工程に進むにつれて、プログラム設計担当は自信が重要だと感じるような記憶装置・タイミング・操作上の制約を分析担当に貸す事になる。

プログラム設計担当は自信の方程式を提供する目的でより多くのこの種の資源を正当に要求する時、それは同時に彼の分析担当の同僚から奪い取らなくてはなりません。

このように、全ての分析担当とプログラム設計担当は、処理時間と記憶装置の資源の適切な配分を完結させる重要な設計工程に貢献する。

もし注がれるだろう資源量が不十分だったら、あるいは、もし初期の操作上の設計が間違っていたら、初期段階や要求の反復作業が評価され、最終設計・実装・テストを始める前に前設計はやり直しだろう。


どのように、この手順は実行されるのか?以下の工程が必要である。

  1. 分析担当やプログラマーではなく、プログラム設計担当により設計工程を開始する。
  2. 間違う危険を冒してでも、データ処理モードを設計・定義・配分する。処理・機能・データベース設計・データベース処理定義を配分し、時間配分し、OSインターフェースや処理モードを定義し、入出力処理を記述し、事前処理手順を定義する。
  3. 理解でき、有益で、最新の概要文書を書く。どの担当者にも、システムの基本的な理解がなければなりません。少なくとも、一人は概要文書を書く為にシステムの深い理解を持たなくてはならない。

図5. Step 1 : 分析が始まる前に、プログラム前設計が完全である事を保証する


*5

STEP2: 設計の文書化

この時点で「文書作成は幾らになる?」という問題を持ち出すのは適切である。私自身の見解は「実に膨大」である。それは勿論、大半のプログラマ・分析担当・プログラム設計担当が、自身の意向通りに事を運ぼうとするならば。

ソフトウェア開発の管理の最初のルールは、断固とした要求の文書化の徹底である。


時折、私は他のソフトウェア設計成果の進捗を精査するように求められる。

私の最初の工程は、文書化の状態を調査する事である。

もし文書化が重度に不履行であるならば、私の最初の忠告は簡単なものである。

プロジェクト管理方法を取り替える。

文書化に関連しない全ての活動を停止する。

文書を標準として許容できる所まで持って行く。

ソフトウェアの管理は、文書化のとても早い段階では絶対に不可能である。

例えば、比較の為に次の見積を示す。

500万ドルのハードウェア装置を入手するとして、私は30ページの仕様書が提供されれば調達物を管理する為には充分詳細であると思う。

500万ドルのソフトウェアを入手するとして、私はハードウェアと同様の管理を成し遂げるには1000ページの仕様書が妥当だと見積もるだろう。

※500万ドル・・・当時は1ドル=360円として、18億円。


何故そんなに文書化するのか?

  1. 各設計担当は、インターフェース設計担当や、経営陣、おそらく顧客ともやりとりを行わなければならない。口頭のやりとりの記録は、インターフェースや管理の決定の為の十分な土台とするにはあまりにもあいまい過ぎる。許容し得る説明文は、設計担当に明確な見解を示し、完成の具体的な証拠を提供することを強制する。それは、設計担当が毎月「9割完了しました」症候群の後ろに隠れてしまうのを防ぐ。
  2. ソフトウェア開発の初期フェーズの間では、文書は仕様書や設計書である。実装が始まるまで、これらの3つの名詞(文書・仕様書・設計書)は一つのものを意味する。もし文書が悪ければ、設計は悪くなる。もし文書がまだ存在していないのなら、設計書は存在しない。設計の幾つかについて考え話している人々のみに存在するが、あまり多くではない。
  3. 本当の良い文書の金銭的価値は、テストフェーズ中の開発プロセスの下流で始まる。そしてそれは操作・再設計工程にも続く。ドキュメントの価値は、3つの具体的な、全てのプログラム管理者が直面する実際の状況で説明する。
    1. テストフェーズ中において、良い文書があるのなら、管理者はプログラムのミスに人員を集中させる事ができる。良い文書がないのなら、全てのミスは大小問わず、多分まず第一にミスを犯した人により解析が行われる。なぜならそのプログラム部分を理解しているのは彼だけであるからである。
    2. 操作フェーズ中において、良い文書があるのなら、管理者はプログラム操作する事にオペレータ要員を使う事ができ、それはより良い仕事であり、安上がりである。良い文書がないのなら、ソフトウェアはその作成者によって操作されなくてはならなくなる。通常これらの人々は操作には比較的無関心であり、オペレータ要員に比べると効果的な仕事ではない。もしソフトウェアハングアップがいつも最初に非難されるのなら、操作の状況のこの点においてこれは指摘されるべきである。ソフトウェアを免責したり非難を修繕する為に、ソフトウェア文書は明確になっていなければならない。
    3. 最初の操作の後で、システムが適切に改善された時、良い文書は効果的再設計やフィールドの改良をもたらすだろう。もし文書が存在しないのなら、通常操作ソフトウェアの既存フレームワーク全体は、例えそれが比較的小規模な変更であってもゴミくずになるだろう。

図6は以前示した工程のキーとなる文書計画を示す。

6つの文書が作成去れる事に注意すべきである。最終製品の納入の時点で、文書1, 3, 4, 5, 6は更新され最新となる。


*6

図6. Step 2: 文書が最新かつ完成であると保証する。 - 少なくとも6つ異なる独自の文書が必要である。


*7

STEP 3: 2度行う

文書化後、成功の為に次に重要な標準は、製品が全体として独自なものであるかどうかが主題となる。

もし問題のコンピュータプログラムが初めて開発されたものならば、運用の為に顧客に最終的に納入されるバージョンは、重要な設計・操作の領域に関する範囲においては、実際には2つ目のバージョンとなるよう、事を前もって準備せよ。

図7では、この事がシミュレーションによってどのようにもたらされるのかを図示している。

これは、全体のプロセスを単に全体の結果に関して比較的小さな期間に合わせて小規模に行ったものである事に注意すべきである。

この努力の特質は、主に期間全体やモデル化されるべき重大な問題部分の本質に広く依存しているのを修正できる。

この努力が30ヶ月間の予定なら、試行モデルのこの初期開発の期間は、10ヶ月間となるかも知れない。

この予定の為に、相当に正式な管理、文書手順等が有用である。

しかし、全体的な努力が12ヵ月間になるならば、本線の開発において十分な力がつく為に、試行努力は3ヶ月に短縮できる。

この場合、関係する人員の一部には非常に特別な種類の広大な能力が要求される。

彼らは、分析、実装とプログラム設計に対する直観的な感覚を持たなければならない。

彼らは、設計から問題箇所を素早く感知し、それらをモデル化し、その代替手段をモデル化し、調査する価値のないこの初期工程の設計の方向性を忘れ、最終的にエラーのないプログラムに到達しなくてはならない。

どちらにしても、この点において、シミュレーションを行う事により、別の判断の問題となるタイミング・記憶領域等の質問は、今や精確に調査できる。

このシミュレーションなしでは、プロジェクト管理者は、人間の判断のなすがままとなる。

シミュレーションを行う事で、プロジェクト管理者は、幾つかの鍵となる仮説や、コンピュータプログラム(離陸総重量、総予算または競馬重勝式の見積のように)がほぼいつも深刻に楽観的であるように人間の判断の為に残された分野の実験的なテストを実行できる。


図7. Step 3: 2回作業をする試み - 最初の結果は、最終製品の早めのシミュレーションを提供する。

*8

STEP 4: テストを計画、管理、監視する

疑いもなく、プロジェクト資源の最大の使用者は、時にそれが人的資源、コンピュータの処理時間または管理判断であろうとなかろうと、テストフェーズである。

テストフェーズは、費用と開発期間に関するもっとも危険なフェーズである。

いやしくも、開発期間の最終段階において、予備の代替手段が少しもない時にそれは起こります。


分析・実装の開始前にプログラムを設計する事、完璧な文書を作成する事、試行モデルを作成する事という前述した3つの提案は、全てテストフェーズに入る前に問題を発見・解決する事を目的としている。

しかしながら、これらの2つの提案を行った後でも、まだテストフェーズがあり、まだやらなくてはならない重要な事がある。

図8はテスト時における幾つかの追加の側面を列挙している。

テストの計画において、私は、次の事を考慮すべきであると提案する。

1) テスト工程の多くは、元の設計に寄与していないテスト専門家によって実施されるのがもっとも良い。

もし、作った本人だけがその部分を理解しているので、設計担当者だけが徹底的なテストを行う事ができると主張するのであれば、これは適切な文書化が失敗した事の現れである。

良い文書があるのなら、私の見解では、設計担当よりもより良いテストをを行うであろう、ソフトウェア製品保証の専門家を使う事が可能である。

2) 多くのエラーは目視による検査で簡単に発見することができる見てすぐに分かる性質のものである。

全ての分析や実装コードは、元の分析や実装を行っていない、がしかしマイナス符号の落とし忘れ、2乗の指数指定ミス、間違ったアドレスへのジャンプといったを発見できる別のグループによって、分析や実装コードの校正を目的とする単純な目視による走査を受けるべきである。

この種のエラーを見つける為に、コンピュータを使うものではない - それは、あまりに高価である。

3) 何らかの数値チェックにて、少なくとも1回はコンピュータプログラムの全ての論理パスをテストしなさい。

私が顧客であるなら、この手順が完了・保証されるまでは納入を受け付けないだろう。

この工程は、大多数の実装エラーを発見するだろう。

このテスト手順が単純であると聞こえている内は、大規模で複雑なコンピュータプログラムにおいて、管理された入力値で全ての論理パスを通す事は、割合に難しいだろう。

実際、それは殆ど不可能だろうと主張する人々もいる。

この事にもかかわらず、私は全ての論理パスは少なくとも1回は本物のチェックを受けるべきという自信の提案を断固として貫くのである。

4) 単純なエラー(大多数、そして大問題を分かり難くしてしまう)が取り除かれた後は、検査目的の為のテスト工程でソフトウェアをひっくり返して調べる時期である。

開発中に適切な時期かつ適切な人の手による事で、コンピュータ自身は検査の為の最高の装置です。

鍵となる経営者の決断事項は次の通りである:その時期はいつか?、最終検査を行うのは誰か?


STEP 5: 顧客を巻き込む

何らかの理由で、ソフトウェア設計は、以前の合意の後でさえ、かけ離れた解釈を受けやすい。

最終納品の前の早い時期に、顧客自身にすべてを任せる為に正式な方法で、顧客を巻き込む事は重要である。

契約者に要件定義と運用の決定の自由を与える事は、問題を引き起こす。

図9は、要件定義の後における顧客の識見・判断・関与が開発成果を強める3つのポイントを示している。


要約

図10は、私が危険な開発プロセスを、望ましい製品を提供できるものに変える為に必要だと感じる5つの工程をまとめる。

私は、各々の事項が若干の追加費用が発生する事を強調する。

比較的単純なプロセスが、ここで言及した5つの複雑な工程なしでうまく機能するならば、もちろん追加費用は発生しない。

私の経験において、しかしながら、単純な手法は大規模ソフトウェア開発成果で今まで一度も機能しなかった。そして復旧する為の費用は、記載した5つのプロセスに必要となる費用を遥かに上回るだろう。


*9

図8. Step 4: コンピュータプログラムのテストを計画、管理、監視する。


*10

図9. Step 5: 顧客を巻き込む - 関与は正式かつ綿密で継続的であるべきである。


*11

図10. 要約

*1:P.1

*2:P.2

*3:P.3

*4:P.4

*5:P.5

*6:P.6

*7:P.7

*8:P.8

*9:P.9

*10:P.10

*11:P.11