ブック「神話のマンマンス、またはソフトウェアシステムの作成方法」

こんにちは住民！プロジェクト管理に関する本は、The MythicalMan-Monthほど重要なものはほとんどありません。実際のソフトウェア開発の例、意見、考えを組み合わせることで、複雑なプロジェクトを管理する様子が鮮明になります。これらのエッセイは、IBM System / 360、次にOS / 360でのプロジェクトマネージャーとしてのブルックスの50年の経験を利用しています。この本の初版は45年前に出版され、2番目の版は25年前に出版されました。新しい方法論が出現し、新しいプログラミング言語が出現し、プロセッサの数が増えていますが、この本は引き続き関連性があります。どうして？半世紀後、私たちはブルックスが説明した過ちを繰り返し続けています。この本で議論されているトピックのいくつかは時代遅れのようですが、これは見た目だけです。それらの背後にある根本的な問題は、今日でも関連しています。理解するためにはあなたの過去を知ることが重要ですソフトウェア開発業界が発展しているところ。したがって、45年後、私たちはブルックスを読んでいます。世界では多くの変化がありますが、9人の女性はまだ1か月で赤ちゃんを産むことができません。

. ,

. , , , …



, , , , .



, ', , , . .

ヨーロッパの大聖堂のほとんどは徐々に建設されており、世代の異なる建設業者によって建設された部品は、建築様式が異なります。その後のビルダーは、建築の「ファッション」と個人的な好みの変化に導かれて、以前のビルダーのデザインを「洗練」するように誘惑されました。したがって、平和なノーマントランセプト*は、高騰するゴシックネイブに隣接し、矛盾します。その結果、建設業者のプライドと同様に、神の栄光を称賛することになります。



彼らの背景に対して、Reimsの建築的統一は非常に対照的です。視聴者を興奮させる喜びは、デザインの完全性と個々のメリットの両方からもたらされます。ガイドに記載されているように、この完全性は、全体的なデザインの純粋さのためにそれぞれのアイデアの一部を犠牲にした8世代のビルダーの自己否定によって達成されました。その結果は、主の栄光だけでなく、罪深い人々を彼らのプライドから救う主の力も宣言しています。



ほとんどのプログラミングシステムは構築に何世紀もかかりませんでしたが、大聖堂よりもはるかに悪い概念の不一致を示しています。これは通常、設計者の変更によるものではなく、プロジェクトが多くの人々によって実行される多数のタスクに分割されたために発生します。



私は、概念の整合性がシステム設計において最も重要な考慮事項であると主張します。いくつかの機能や改善点が欠けているが、1セットの設計アイデアを反映しているシステムを使用する方が、優れているが独立した一貫性のないアイデアを多数含むシステムよりも優れています。この章と次の2つの章では、プログラミングシステムの設計に対するこのトピックの影響を見ていきます



。-概念の整合性を実現する方法は？



-この議論は、創造的な才能やアイデアが抑制されているプレビアンの実装者の大群の前にいる建築家のエリチズムや貴族の言い訳ではありませんか？



-未実装または高価な仕様でアーキテクトが青に流されないようにするにはどうすればよいですか？



-アーキテクチャ仕様の細部がすべて実装者の注意を引き、製品に正しく正確に埋め込まれていることを確認するにはどうすればよいですか？

概念の整合性の達成

プログラミングシステムの目的は、コンピューターを使いやすくすることです。これを行うために、言語とさまざまなサポートツールを提供します。これらは実際には、言語機能によって呼び出され、駆動されるプログラムです。ただし、これらのツールには代償が伴います。プログラミングシステムの外部記述は、コンピュータシステム自体の外部記述よりも10〜20倍大きくなります。ユーザーが単一の機能を設定するのははるかに簡単ですが、選択肢は豊富であり、覚えておくべきオプションや形式は他にもたくさんあります。



機能仕様で得られた時間がリファレンスマニュアルの同化、記憶、​​検索で失われた時間よりも長い場合にのみ、使用法が簡略化されます。最新のプログラミングシステムでは、このゲインはコストを上回っていますが、近年、より複雑な機能が追加されるにつれて、ゲインとコストの比率が低下しているようです。アセンブリ言語やその他のソフトウェアがまったくなくても、IBM650の使いやすさの記憶に悩まされています。



使いやすさが目標であるため、機能と概念の整合性のこの関係は、システム設計の究極のテストです。機能性とシンプルさだけでは、優れたデザインを定義することはできません。

この論文は広く誤解されています。 OS / 360オペレーティングシステムは、間違いなく最も機能的であるため、これまでに設計された最高の製品として作成者から高く評価されています。設計者にとって常に卓越性の尺度であるのは、単純さではなく機能です。一方、PDP-10のタイムシェアリングシステムは、コンセプトのシンプルさと抑制のために、その作成者から最高のものとして歓迎されています。ただし、いずれにしても、その機能はOS / 360と同じクラスには属していません。使いやすさを基準にすると、これらのアプローチはそれぞれ不均衡になり、目標の半分になります。



ただし、特定のレベルの機能に対して、最適なシステムは、最も単純でわかりやすい方法で指定できるシステムです。シンプルさだけでは十分ではありません。言語TRACMooersとAlgol68は、異なる基本概念の数によって測定される単純さを実現します。ただし、即時性はそれらの特徴ではありません。多くの場合、意図を表現するには、基本的なツールを複雑で予期しない方法で組み合わせる必要があります。要素とそれらの組み合わせのルールを研究するだけでは十分ではありません。要素が実際にどのように組み合わされているかについての知識全体を吸収するために、慣用的な使用法を研究することも必要です。シンプルさとわかりやすさは、概念の整合性に由来します。各ピースは、同じ哲学と同じバランスを取る行為を反映する必要があります。各部分は、構文では同じ手法を使用し、セマンティクスでは同様の概念を使用する必要があります。したがって、使いやすさによって、設計の統一性、概念の整合性が決まります。

貴族と民主主義

次に、概念の整合性には、プロジェクトが1人の開発者または少数の開発者からのものであり、協調して協調して動作する必要があります。

スケジュールのプレッシャーは、順番に、より多くの労働者の関与を必要とします。この問題を解決するには2つの方法があります。1つ目は、アーキテクチャと実装の間の慎重な分業です。2つ目は、前の章で説明したプログラミング実装命令を構造化する新しい方法です。



アーキテクチャの取り組みを実装から分離することは、大規模なプロジェクトで概念の整合性を実現するための強力な方法です。私自身、IBM Stretch and System / 360製品ラインのコンピューターで大成功を収めているのを見てきました。そして、それが十分に使用されていなかったために、オペレーティングシステム/ 360の開発でどのように機能しないかを目撃しました。



システムアーキテクチャとは、ユーザーインターフェイスの完全で詳細な仕様を意味します。コンピュータの場合は、プログラミングリファレンスマニュアルに具体化されています。コンパイラの場合-言語リファレンスマニュアル。制御プログラムの場合、その関数を呼び出すために使用される1つまたは複数の言語のリファレンスマニュアル。システム全体で、ユーザーが目標を達成するのに役立つリファレンスガイドのコレクションです。



システムアーキテクトは、ビルディングアーキテクトと同様に、ユーザーエージェントです。その責任には、売り手、製造業者などの利益ではなく、消費者の利益のための専門的および技術的知識の使用が含ま



れます。アーキテクチャは、実装と明確に区​​別する必要があります。 Blaauwが指摘したように、「アーキテクチャが何が起こるかについて話すのに対し、実装はそれを実現するためにどのように行われるかについて話します。」簡単な例として、彼はそのアーキテクチャが文字盤、手、王冠で構成されている時計を引用しています。子供がこの建築を学ぶとき、彼は腕時計と教会の塔の時計の両方で同じように簡単に時間を伝えることができます。実装とその実装は、内部で何が起こるかを説明します。つまり、多くのメカニズムのそれぞれによる努力の伝達と精度の制御です。



たとえば、System / 360では、9つのモデルのそれぞれで個別のコンピュータアーキテクチャが非常に異なる方法で実装されています。次に、モデル30システムの個別の実装、データフロー、メモリ、およびマイクロコードは、異なる時点で4つの異なるアーキテクチャに対応します。システム/ 360コンピュータ、論理的に独立した224のサブチャネルを持つ多重チャネル、セレクタチャネル、および1401コンピュータです。



同じ区別がプログラミングシステムにも同様に当てはまります。米国はFortranIV規格を採用しています。これは多くのコンパイラのアーキテクチャです。このアーキテクチャ内では、メモリ内のテキストまたはコンパイラ、高速または最適化、構文またはアドホックなど、さまざまな実装が可能です。同様に、アセンブリまたはジョブ制御言語では、多くのアセンブリまたはスケジューラの実装が可能です。今、私たちは貴族と民主主義の深く感情的な問題に取り組むことができます。貧しい、頭の悪い実装者に何をすべきかを教えるために設立された新しい貴族、知的エリートを設計者はしませんか？このエリートはすべての創造的な活動を引き継いで、パフォーマーをメカニズムの歯車だけにしませんでしたか？より良い製品を手に入れることはできません仕様の開発を選択した少数に制限するのではなく、民主主義の哲学に従って、チーム全体から優れたアイデアを実装しますか？



最後の質問は、最も単純な質問です。私は建築家だけが良い建築思想を持っていると言っているのではありません。多くの場合、新しい概念は実装者またはユーザーからもたらされます。しかし、私のすべての経験は私を納得させ、システムの概念的な完全性がその使いやすさを決定することをこれを示しようとしました。システムの基礎となる概念と統合されていない優れた機能やアイデアは、残しておくのが最善です。そのような重要であるが互換性のないアイデアがたくさん現れると、システム全体が全体として破棄され、他の基本的な概念を備えた統合システムで作業が再開されます。



貴族の告発については、答えは「はい」と「いいえ」でなければなりません。はい、アーキテクトは少なく、その製品は実装者の製品よりも長持ちする必要があり、アーキテクトはユーザーの利益のために最終的に指示しなければならない力の中心にあります。システムに概念的な整合性を持たせるには、1人が主導権を握る必要があります。これは謝罪を必要としない貴族です。



外部仕様の開発は、実装の設計と同じくらい創造的な作業です。それは創造性であり、まったく別の種類です。アーキテクチャを意識した実装設計には、外部仕様の設計と同じくらい多くの設計の創造性、新しいアイデア、および技術的な輝きが必要であり、それを可能にします。実際、使いやすさがアーキテクトに最も依存しているのと同様に、製品のコスト対パフォーマンスの比率は実装者に最も依存します。



規律が職人技を向上させるという信念につながる芸術や工芸品からの多くの例があります。確かに、アーティストの嫌悪感は「形が解放される」と述べています。最悪の構造は、予算が大きすぎてサービスを提供できない構造です。バッハの創造的な活動は、形式が限定された毎週のカンタタをリリースする必要性によってほとんど抑制されませんでした。 Stretchコンピュータのアーキテクチャがもっと制限されていれば、もっと良いアーキテクチャになると確信しています。私の意見では、システム/ 360モデル30の予算の制約は、あらゆる点でモデル75アーキテクチャに有益でした。



同様に、アーキテクチャのアウトソーシングは、実装チームの創造的なスタイルを否定するのではなく、強化することがわかりました。彼らはすぐに誰も解決しなかった課題の部分に焦点を合わせ、発明は川のように流れ始めます。無制限の実装グループでは、ほとんどの考えと議論はアーキテクチャソリューションに向けられ、実装期限は短くなります。



私が何度も見たこの効果は、CornellのグループがPL / 1用のPL / Cコンパイラを構築したRWConwayによって確認されています。彼は次のように述べています。「言語の議論は私たちのすべてのエネルギーを必要とするため、最終的には、変更や改善なしで言語を実装することにしました。」

実装者は待っている間に何をすべきですか？

百万ドルの間違いを犯すのは恥ずべきことですが、それはとても印象的です。 OS / 360の外部仕様書の実際の作成方法を決定した夜を鮮明に覚えています。アーキテクチャマネージャーと制御プログラムのマネージャーと私は、計画、スケジュール、および責任の割り当てを作成しました。



建築マネージャーには10人の才能のある人がいました。彼は、彼らが仕様を書いてそれを正しく行うことができると主張した。これには10か月かかり、スケジュールが許すより3か月長くなります。



制御プログラムの実施のためのマネージャーは150人でした。彼は、彼らが建築チームと協力して仕様を準備できると主張した。それはよくできていて実用的であり、スケジュールに合うでしょう。さらに、アーキテクチャチームがこれを行うとすると、150人が10か月間ぼんやりと座っていました。



これに対して、アーキテクチャマネージャーは、私が管理プログラムチームに責任を移すと、実際には3か月後に結果が届き、品質が大幅に低下すると回答しました。私はその責任を制御プログラム実施チームに引き渡したが、彼が言ったようにそれが判明した。彼はどちらの場合も正しかった。さらに、概念の整合性が欠如しているため、システムの構築と変更にはるかに費用がかかり、デバッグが1年遅れたと推定されます。



もちろん、多くの要因がこの誤った決定に影響を与えました。しかし、圧倒的なものは、スケジュールの時間的制約と、これら150人の実装者全員を働かせたいという魅力でした。私が今目に見えるようにするのは、致命的な危険に満ちたこのサイレンの歌です。



小規模なアーキテクチャチームが実際にコンピュータまたはプログラミングシステムのすべての外部仕様を作成するという提案に対して、実装者は3つの異議を唱えます。

• スペックは機能が多すぎて、実際のコストを反映しません。
• アーキテクトはすべての創造的な喜びを持ち、実装者の創意工夫を放棄します。
• 仕様が建築チームのボトルネックを通過する間、多くのパフォーマーはぼんやりと座らなければなりません。

最初は本当の危険であり、次の章でそれを見ていきます。他の2つは、純粋で単純な幻想です。上で見たように、実装も一次クリエイティブアクティビティです。デザインにおいて創造的で独創的である能力は、与えられた外部仕様の範囲内で作業する必要性によってわずかに制限され、この分野は創造性を高めることさえできます。これは間違いなくプロジェクト全体に当てはまります。



最後の異議は、タイミングとフェーズに関するものです。簡単な答えは、仕様が完了するまで実装者を雇わないことです。建設では、それらは同じ原理で動作します。



しかし、コンピュータシステム事業ではペースが速く、誰もが可能な限りスケジュールを絞りたいと考えています。仕様と開発はどの程度重複できますか？



Blaauが指摘するように、全体的な創造的な取り組みには、アーキテクチャ、実装、実装という3つの異なるフェーズが含まれます。それらは実際に並行して開始し、同時に継続できることがわかりました。



たとえば、コンピュータの設計では、実装者は、リファレンスマニュアルについて比較的漠然とした仮定、テクノロジーについての多かれ少なかれ明確なアイデア、およびコストとパフォーマンスの明確な目標を持っているとすぐに開始できます。彼は、データストリーム、制御シーケンス、大まかなパッケージングの概念などを設計できます。彼は、必要なツール、特に設計自動化システムを含む会計システムを開発または適合させます。



同時に、実装レベルでは、回路、カード、ケーブル、フレーム、電源、およびメモリの設計を作成し、改善し、文書化する必要があります。この作業は、アーキテクチャと実装と並行して行われます。



プログラミングシステムの設計についても同じことが言えます。外部仕様が完成するずっと前に、実装者はやるべきことがたくさんあります。システムの機能が大幅に単純化され、最終的には外部仕様で具体化されるため、彼は作業を続けることができます。明確に定義された空間的および時間的ターゲットが必要です。彼は、自分の製品を実行するシステムの構成を知っている必要があります。次に、モジュールの境界、テーブル構造、パスとフェーズの内訳、アルゴリズム、およびあらゆる種類のツールの設計を開始できます。アーキテクトとのコミュニケーションにもある程度の時間を費やす必要があります。



実装レベルで行うべき作業はまだたくさんあります。プログラミングにもテクノロジーがあります。マシンが新しい場合は、サブルーチンの呼び出し規則、スーパーバイザーテクノロジー、検索および並べ替えアルゴリズムについて多くのことを行う必要があります。



概念の整合性には、システムが単一の哲学を反映していること、およびユーザーに表示される仕様が複数の人によって作成されていることが必要です。ただし、実際の作業はアーキテクチャ、実装、実装に分割されているため、このように計画されたシステムの組み立てに時間がかかることはまったくありません。経験からすると、逆のことがわかります。システム全体がどんどん収束し、テストにかかる時間が短くなります。実際、広範囲にわたる水平方向の分業は、垂直方向の分業によって大幅に削減され、その結果、コミュニケーションが大幅に簡素化され、概念の整合性が向上しました。





»本の詳細については、出版社のウェブサイトをご覧ください

»目次

» 住民のための抜粋



クーポンの25％割引-ブルックス



本の紙版の支払い時に、電子書籍が電子メールで送信されます。