「No Silver Bullet: The Essential and Auxiliary Work of Software Engineering」 (英語: ) は、IBM メインフレーム コンピューターの父である Fred Brooks が発表したソフトウェア エンジニアリングに関する論文です。元々は 1986 年のダブリン IFIP シンポジウムで発表されました。 、電気電子学会「C」

特効薬はない

No Silver Bullet: The Essential and Auxiliary Work of Software Engineering」 (英語: ) は、IBMメインフレーム コンピューターの父であるFred Brooksによって発表されたソフトウェア エンジニアリングに関する論文です。元々は1986 年のダブリンIFIPシンポジウム発表されました。招待論文です。この作品は翌年、電気電子学会の「コンピューター」誌にも再版され、「ロンドンの人狼」などの映画の静止画がいくつかイラストとして使用され、「人狼 この議論では、ソフトウェアの複雑な性質のため、本当の特効薬はない、ということが強調されています。いわゆる特効薬がないということは、ソフトウェア エンジニアリングの生産性を 10 年以内に 10 倍に高めることができる技術や方法がないことを意味します。

まとめ

すべてのソフトウェアの作成には、必須のタスク偶発的なタスクが含まれます前者は、抽象的なソフトウェア エンティティで構成される複雑な概念的構造を作成することであり、後者は、プログラミング言語を使用してこれらの抽象的なエンティティを表現し、特定のスペースと速度の制約の下でプログラムをマシンにマッピングすることです。

さて、本質的な作業と比較して、ソフトウェア エンジニアの仕事のうち、付随的な作業にどれだけの時間が費やされているでしょうか? 補助作業が総作業量の9/10以上を必要とする場合を除き、すべての補助作業をゼロにしても、開発作業全体が 1 桁も簡単になるわけではありません。これまで、ソフトウェアの生産性における重要な進歩のほとんどは、厳しいハードウェアの制限、使いにくいプログラミング言語、不十分なマシン時間などの人為的障害の除去によってもたらされていましたが、これらすべてが子会社の作業を困難にする原因となっていまし

問題 – 特効薬とソフトウェア プロジェクト

フレッド・ブルックスは「特効薬はない」の中でこう述べています。

民間伝承では、私たちに悪夢をもたらすあらゆる怪物の中で、普通の人が突然恐ろしい怪物に変身する狼男ほど恐ろしいものはないとされており、人々は狼男を奇跡的に怪物に変えることができる人を見つけようとします。一撃で殺す弾丸。

私たちがよく知っているソフトウェアプロジェクトも同様の特徴を持っており、(テクノロジーを理解していないマネージャーの視点から見ると)通常はシンプルで簡単に見えますが、瞬く間にスケジュールの遅延と予算を伴うプロジェクトに変わる可能性がありますそのため、コンピューターのハードウェアのコストが急速に低下しているのと同じように、ソフトウェア開発のコストを効果的に削減できる特効薬を切望する絶望の叫びが聞こえてきます。

しかし、私たちは、今から 10 年後には、生産性、信頼性、または簡素性の向上を保証する特効薬はなく、技術的にも管理的にも単一の大きなブレークスルーは存在しないと予測しています。

しかし、懐疑論は悲観論ではありません。私たちは大きなブレークスルーを予見していませんし、実際、そのような大きなブレークスルーがあるのはソフトウェアの性質に反すると私は信じています。しかし、まだ多くのエキサイティングなイノベーションが進行中です。柔軟に一歩一歩粘り強く開発・普及・活用していけば、きっと桁違いの進歩を遂げることができるでしょう。近道はありませんが、意志があるところには道はあります。

人類が病気を克服するための最初のステップは、細菌理論を使用して悪魔理論体液理論を排除することです。このステップこそが人類に希望をもたらし、すべての奇跡理論を打ち砕くのです。希望は進歩が一歩一歩、努力によってもたらされることを人々に伝えます。正しい方法は、継続的に清潔さに投資し、良い習慣を身につけることです。今日、私たちはソフトウェア エンジニアリングに同じように直面しています。

「No Silver Bullet」は、今後 10 年間 ( 1986 年の記事の出版から数えて) 以内に、プログラミングの生産性を一桁向上させるようなソフトウェア エンジニアリングの画期的な進歩は存在しないだろうと主張し、主張して​​いますしかし、著者らは、この仮定はもはや有効ではないと考えています。

ソフトウェア開発の総作業量を10とし、必須作業が1 、補助作業が9であるとします。このとき、補助作業を改善して廃止することで、ソフトウェアの作業負荷を1に減らすことができます(補助作業が0になるため)。ソフトウェア開発の容易さは一桁向上したと言えます ( 10から1への改善は10倍の差であるため)。

ソフトウェア開発の難しさ

Brooks はソフトウェア開発の困難を 2 つのカテゴリーに分類しました。この古典的な論文の中心的な議論は、複雑なソフトウェア エンジニアリングの問題は単純な答えでは解決できないと言っていると解釈されることがよくあります。ブルックスは、ソフトウェア開発における本当の難しさは、そのプレゼンテーションに執着したりそのプレゼンテーションの正確さをテストすることではなく、この概念的な構造の仕様、設計、テストにあると信じていました。

  • 本質: ソフトウェア自体は、概念の構築、つまり抽象的な問題から具体的な概念的な解決策を開発する方法に本質的な困難を抱えています。
  • 事故:概念的なアイデアをコンピュータ上で実装する際に遭遇する困難。

ブルックス氏は、 「偶然という言葉と、アリストテレスの古代の用法に由来する「偶然」という言葉の間に混乱があると指摘しています。英語の「:」という言葉に関して言えば、偶然起こることや予期せぬ不幸を意味するものではなく、付随的、二次的なものに近いものです。

本質的な困難の原因

ブルックス氏は、ツールが改良されるにつれて追加的な困難は徐々に薄れていくと考えていますが、逆に、ほとんどの活動は人々の頭の中で起こり、効果的な補助ツールがないため、本質的な困難は解決するのが最も難しいと考えています。ブルックス氏によれば、次のようなことが挙げられます。

  • 複雑さ: ソフトウェアが解決する必要がある問題には、通常、計算ステップが含まれます。これは人工的で抽象的な知的活動であり、ほとんどが複雑です。
  • 不可視性: 未完成のソフトウェアは目に見えないため、たとえ図を使って説明したとしても、その構造を完全には表現できないことが多く、コミュニケーションが非常に困難になります。
  • 適合性: 大規模なソフトウェア環境では、各サブシステムのインターフェイスが一貫している必要があります。このような一貫性を維持することは、時間や状況の変化により困難になることがよくあります。
  • 変更可能性: ソフトウェアが適用される環境は、人材、規制、ハードウェア機器、アプリケーション分野などのさまざまな要素で構成されることが多く、これらの要素は急速に変化する可能性があります。

高級言語

参照:アセンブリ言語マシン言語

高級言語はどのような使命を果たしますか? これにより、プログラムは、もともとプログラムに内在していた複雑さの多くから解放されます。抽象プログラムには、関数、データ型、順序関係、メッセージ送信方法などの概念的な構造が含まれていますが、実際に機械語に関係するのは、ビットレジスタ、条件、分岐、チャネル、ディスクなどです。高級言語は、抽象プログラムに必要な構成要素を具体化し、低レベルのものをすべて回避することができます。この場合、プログラムのコンテンツとは関係のない複雑な層全体が削除されます。

タイムシェアリング技術

タイムシェアリングテクノロジーは、まったく異なる問題に挑戦します。タイムシェアリングによりリアルタイム性が確保され、複雑な概要を頭の中に維持し続けることができるからです。タイムシェアリング テクノロジが貢献できる最終ラインは、直接計算することもできます。その主な効果はシステムの応答時間を短縮することだからです。この時間がゼロに近づき、ある時点で人間が検出できるシステムの応答時間を超えます。反応時間のポイントは約 10 分の 1 秒であり、この値を下回ると利点はなくなります。

統合開発環境

参照:統合開発環境

UnixInterlisp は、広く使用されるようになった最初の統合ソフトウェア開発環境であり、生産性が数倍向上したことが認められています。この側面で挑戦する補助的な問題は、完全なリンク ライブラリ、統一されたファイル形式パイプ(パイプ) およびフィルター (フィルター)を通じてソフトウェアの共有を促進することです。したがって、理論的には、あらゆる概念構造を呼び出し、転送し、別のオブジェクトに適用することができます。 , 実際には、これは簡単に行うことができます。この画期的な進歩は、その後、ツール ソフトウェア全体の開発につながりました。これは、新しいツールは標準仕様を使用している限り、どのようなプログラムにも適用できるためです。

特効薬を探しています

Adaおよびその他の高級言語の進歩

プログラミング言語Ada は、1980 年代の汎用高水準言語です実際、Ada は言語概念の進化を反映しているだけでなく、最新のデザインとモジュール概念を促進するいくつかの機能も実装しています。おそらく、Adaの概念はAda言語自体よりも高度です。この概念は次のとおりです: モジュール性 (modularity ) 、抽象データ型 (抽象データ型)、階層構造 (階層構造)。

オブジェクト指向プログラミング

今日のさまざまな一般的なテクノロジと比較して、オブジェクト指向プログラミングは多くのソフトウェア工学の学生によって期待されています。ダートマス大学のマーク シャーマン氏は、「オブジェクト指向プログラミングには 2 つの異なる概念がある。慎重に区別する必要がある。これら 2 つの概念の違いは次のとおりである」と指摘しました。名前からわかるように、抽象データ型と階層型です。後者はクラスも呼ばれますいわゆる抽象データ型。その概念は、オブジェクトの型は、オブジェクトが格納されている構造ではなく、名前、適切な値のセット、適切な操作メソッドのセットによって定義されるべきであるというものです。部分は、 Adaのパッケージ (プライベート タイプを使用) やModulaのモジュール ( module )など、Hidden で定義する必要があります

  • AI
  • エキスパートシステム
  • 自動化プログラミング
  • ビジュアルまたはグラフィカルプログラミング
  • ソフトウェアの検証
  • 環境とツール
  • ワークステーション

返信のレビュー

マン・ムーンの神話」は多くの議論を引き起こしましたが、論争はほとんどなく、代わりに「特効薬はない」という記事が、ジャーナル編集者への手紙や現在も掲載され続けている記事など、反対意見の多くの記事を引き起こしました。多くの手紙と短いコメントで、そのほとんどが魔法の薬は存在しないという主張に反論しています。

1990 年にBrad Cox は「特効薬はある」という記事を発表し、コンセプトの重要な部分である問題に対処するには、再利用可能で交換可能なコンポーネントを使用する必要があると指摘しました。グラスヴェッシーコンガーは1992年の論文の中で、この特効薬に関する無意味な研究が止まらないことを示す十分な証拠があると指摘した。

ハレルの分析

デビッド・ハレルは、1992 年の記事Biting the Silver Bullet」で、出版された「No Silver Bullet」について非常に注意深く分析しました。ハレルは、記事「特効薬はない」とパルナス1984 年の「戦略防衛システム ソフトウェアの側面」の両方が絶望的すぎると信じていたため、明るい面を詳しく説明するためにこの点に焦点を当てました。また、彼の記事には副題が付けられていました:「レット システム」開発は明るい未来に向けて進んでいきます。」

ハレル氏の観点から、「特効薬はない」という悲観論には 3 つの理由があると考えています。

  • 本質性と依存性の二分法。
  • 考えられる特効薬を個別に検討してください。
  • 10 年間を予測するだけでは、「大きな進歩を予測する」には十分ではありません。

ハレルはまた、「特効薬はない」という命題は変わらないが、出版時期が1986 年ではなく1952年に変更されたという仮説実験を提案しましたこのときに彼が使用したのは、付随的な特性から本質性を切り離す慣行に反論するために使用された「不条理の還元」です。

ジョーンズの視点

ケイパー・ジョーンズはかつて鋭い観察を行っており、最初は一連の非公式のメモに書き留められ、後に本として出版され、ブルックスと文通していた何人かの友人によって言及されました。「特効薬なし」は、ほとんどの論文と同様、生産性、つまり入力コストの単位当たりソフトウェアがどれだけの出力を得ることができるかに焦点を当てています。ジョーンズ氏は「品質と生産性が重視されることになるだろう」と語った。同氏は、コストが高すぎてスケジュールが遅れている限り、仕様、設計、実装における誤りの発見と修正に多くの余分な時間と労力が費やされていると考えています。ジョーンズ氏はまた、体系的な品質管理の欠如と遅延災害の発生との間に強い相関関係があることを裏付けるデータも指摘した。

Caper Jones は、2 つの同一のCobolプログラムがそれぞれ10年間書かれ、一方は構造化アプローチを使用し、もう一方は構造化アプローチを使用しなかった場合、効果は3倍異なるだろうと考えています。

コメント

  1.  ヨーロッパとアメリカの古代の伝説では、銀の弾丸は吸血鬼、狼男、または怪物を殺すために使用できますが、銀の弾丸は問題を解決する効果的な方法へと拡張されました。
  2.  「特効薬はない」というタイトルのこの記事は、Information Processing 1986、Proceedings of the IFIP Tenth World Computing Conference、1069-76 ページからのものです。HJ Kugler 編集。
  3.  編集者 Qian Yiyi の注釈: 伝説によると、満月の夜、狼男は普通の獣から狼に変身し、恐ろしい怪物になります。狼男に対処するには、銀の弾丸を使ってその心臓を突き刺さなければなりません。なぜ特効薬を使うのでしょうか? 銀は月と同じ肉体であり、魔力を持っていると考えられているため、銀の弾丸は狼男を倒すための「涅槃」である。
  4.  細菌理論: 病気が細菌感染によって引き起こされることを発見したフランスの微生物学者ルイ・パスツール (1822~1895) によって提唱された理論。
  5.  悪魔は言いました:あなたが病気なのは、悪魔が問題を引き起こしているから、あるいはあなたが何か間違ったことをして悪魔を怒らせたからです。
  6.  体液性理論:人間の体内には血液、粘液(痰)、胆汁(胆汁)、黒胆汁の 4 つの体液が流れており、これら 4 つの体液はそれぞれ異なる性質を持ち、人の気質や気質を決定する。病気はこれら 4 つの体液の比率のバランスが崩れることによって引き起こされます。
  7.  「アリストテレスとスコラ哲学によれば、付属物は、物事にとって基本的でも必要でもないが、他の原因の影響によって生み出される性質です。
  8. ^ 手紙と返答の一部は、IEEE Computer の 1987 年 7 月号に掲載されました『No Silver Bullet』は受賞しませんでしたが、Bruce M. Skwiersky のレビューが1988 年のComputer Reviewsで最優秀レビューに選ばれました。この賞とレビューは発表され、EA Weiss、「Editrial」、  Computing Reviews (6 月)に転載されました。 、1989)、pp. 283-284。レビューには大きな間違いがあります:「6 倍」は「10^6」であるべきです。
  9.  ブラッド コックスはソフトウェア エンジニアリングの修士でもあり、「ソフトウェア IC」という用語を生み出しました。
  10.  編集者 Qian Yiyi の翻訳注釈: "Reductio ad absurdum": q から開始して、論理結果 r が推定されます。r が矛盾する場合、q は否定されます。

参考文献

引用

    1.  .  [ 2012-07-08 ] . ( 2012-07-05オリジナルからアーカイブ)
    2.  FP ブルックス、「特効薬はないソフトウェア エンジニアリングの本質と偶然、情報処理 86、HJ Kugler 編 アムステルダム: Elsevier Science (北オランダ)、1986 年、1069 ~ 1076 ページ。
    3.  Brooks、FP「特効薬はないソフトウェア エンジニアリングの本質と偶然」、  Computer  20、4 (1987 年 4 月)、10-19 ページ。
    4.  FP Brooks、「特効薬の本質はなく、ソフトウェア エンジニアリングの事故」、  Computer、Vol. 20、10-19ページ、1987年。
    5.  Webster's New International Dictionary of the English Language、第 2 版、マサチューセッツ州スプリングフィールド: GC Merriam、1960 年。
    6.  鄭炳強著、志生文化産業株式会社、2007 年、ISBN 978-957-729-659-7。
    7.  Parnas、DL 、「拡張と縮小を容易にするソフトウェアの設計。IEEE
      Trans. SE、5、2 (1979 年 3 月)、128 ~ 138 ページ。
    8.  Booch、G. オブジェクト指向設計、Ada によるソフトウェア エンジニアリング」。
      カリフォルニア州メンローパーク:ベンジャミン/カミングス、1983年。
    9.  コックス、ブラッド。アメリカのプログラマージャーナル。199511 [ 2012-07-10 ](原文の内容は2018-02-28保存されています(英語)この時代で最も影響力のある本の 1 つである『神話の人月』の中で、フレッド ブルックス博士は、遅れているソフトウェア プロジェクトにさらに人員を加えることは事態を悪化させるだけであるように見えると述べています。そして同様に影響力のある記事、「特効薬はない」。彼は、「ソフトウェアエンジニアリングの本質と事故」の中で、困難は避けられないものであり、ソフトウェアの避けられない本質から生じ、事故とは区別されると主張しました。それを作るときに私たちが何か間違ったことをしたのです。 
    10.  BJ コックス、「銀の弾丸はある」、  Byte  (1990 年 10 月)、209-218 ページ。
    11.  Glass、RL、および SA Conger ,“ソフトウェアのタスクを調査する: 知的ですか、それとも事務的ですか? 情報と管理」、23、4 (1992)、183-192 ページ。
    12.  ハレル、デヴィッド。1992 [ 2012-07-10 ](原文は2013-05-22保存されています(英語)この記事は、Brooks と Parnas の記事がきっかけとなりました。反論ではありません。実際、私は両方の論文で述べられた具体的な論点のほとんどに同意します。その代わりに、この記事の目的は、コインの明るい面を明らかにし、ブルックスとパルナスが原稿を書いたときに影響を与えるにはあまりにも最近または未熟だったこの分野の発展を強調することです。 
    13.  Harel, D.、「銀の弾丸を噛む: システム開発の明るい未来に向けて」、  Computer  (1992 年 1 月)、8-20 ページ。
    14.  DL パルナス、「戦略的防衛システムのソフトウェア側面」、  Communications of the ACM、28 (12) (1985 年 12 月)、1326-1335 ページ。
    15.  Jones, C.、ソフトウェア リスクの評価と制御。ニュージャージー州イングルウッド・クリフス:プレンティス・ホール、1994 年。619.
    16.  T. Caper Jones. . Prentice Hall. 1993-12-17  [ 2012-07-12 ] . ISBN 978-0137414062. ( 2012-09-04のオリジナルからアーカイブ) (英語) 

ソース

ジャーナル記事

  • ブルックス、フレッド P. IFIP 第 10 回世界コンピューティング会議の議事録。1986: 1069 ~ 1076 年。
  • ブルックス、フレッド P. IEEE コンピューター。1987年4月 20日 (4):10~19。

  • Frederick P. Brooks, Jr.. Qian Yiyi 翻訳. 台北市: 経済ニュース協会. 2004-04-01  [ 2012-07-01 ] . ISBN 986-7889-18-5. (オリジナルの内容は2013 年 11 日にアーカイブされました) -08)  (中国語 (台湾))

外部リンク

Wiki上の人間と月の女神に関する引用

見る

  • フレッド・ブルックス
  • 人と月の神話
  • ソフトウェア危機
  • 銀の弾丸→狼男

この記事は Wikipediaから引用しています。このテキストは、 クリエイティブ コモンズ - 表示 - 継承に基づいてライセンスされています。メディア ファイルには追加の規約が適用される場合があります。

 

 

 

Guess you like

Origin blog.csdn.net/weixin_40191861/article/details/132857585