ソフトウェア開発がブリッジの構築とどのように異なるかを説明するための良いアナロジーは何ですか？
あなたの上に2つ上のレベルのマネージャーがいる場合、ソフトウェアの構築はブリッジの構築に似ていると言われますが、それにどのように対応しますか？
このマネージャーがシステムを正確に推定して構築できるはずであると本当に信じている場合、なぜこれが当てはまらないのかを説明するための優れたメタファーはありますか？
私はこの比喩を採用し、通常のブリッジ構築のプラクティスが通常のソフトウェア開発のプラクティスとどこが異なるかを簡単に指摘します。
橋の要件は事前に十分に定義されており、建設中に変更されることはありません。建設の途中で橋の始点または終点を移動することは誰も考えていません。道路橋が列車を魔法のようにサポートしたり、2車線の田舎道を8車線のスーパーハイウェイにサポートしたりすることを誰も期待していません。推測して一定の変更を処理するよりも、何を投影するよう求められているかを事前に正確に把握している場合は、正確な予測を行う方がはるかに簡単です。
橋の大部分は、非常に試行錯誤された真の材料、アーキテクチャ、および技術を使用しています。ローマのエンジニアは、2000年後に輸送され、現代の建設現場で何が起こっているかを一般的に認識することができます。もちろん違いはありますが、ロードバランシング用のアーチを構築している、同じマテリアルの多くをまだ使用している、などです。一方、構築されているほとんどのソフトウェアは、多くの目新しさを伴います。 「標準的な」ソフトウェアが必要な場合は、ビルドするのではなく購入するので、何かをビルドすることを選択した場合、それはある意味で斬新であることを強く意味します。目新しさはリスクをもたらしますが、その目新しさはおそらく、価値をもたらしているものでもあります。
土木工学プロジェクトが常に正確に見積もられることも少し神話です。ほとんどの建設プロジェクトは、当初の予測よりも時間がかかり、コストも高くなります。たとえば ボストンのビッグディグ は、予定よりも10年以上長く、当初の2倍をはるかに上回っています（インフレを調整しない場合はさらに高くなります）。そして、家を建てたことがある人はほとんどいませんが、すべてが時間通りに予算通りに完了したことに驚いた様子を語ってくれます。
基本的に、エンジニアリングプロセスとソフトウェア開発プロセスの違いは何かを尋ねています。そして、areにはいくつかの重要な違いがあります。
一番の違いは制約の程度または最終製品に適用される要件です。
- ブリッジには固定の制約があります。 「橋とのギャップは幅###メートルです。」
- ソフトウェアプロジェクトは、制約の流動性で悪名高い。先週のパスワードは4文字である必要がありました。今週は12時です。
次の違いは、最終製品の構築に使用される材料を囲む知識の体系です。
- コンクリート、鋼、木はすべて、よく研究され、理解されている材料です。 ###間隔で3/4 "の鉄筋で補強された18"コンクリートスラブは、異なる固定されたプロパティを持ちます。
- ソフトウェアを使用していて、たまたま点滅しただけだったため、優先フレームワークに新しいメジャーバージョンがリリースされました。使用している言語は、新しい概念またはプログラミングアプローチを導入しています。ソフトウェアツールのプロパティは、はるかに流動的です。
次に、要件を取り巻く具体性の程度を検討します。
- 要件は修正されるだけでなく、エンジニアリングプロセスで指示するのも簡単になります。ブリッジの長さを指定できます。サポートする必要のある最小トン数を指定できます（指定できます！）。これらの仕様には、固定された数値が関連付けられています。要件の検証は、エンジニアリングプロセスで実行する方が簡単です。
- 次に、ソフトウェアのユーザーインターフェースについて考えてみましょう。見た目や操作感、および「応答性」をどのように表現するかを指定することで、用語がどれだけ流動的になるかを考えてみましょう。
次にプロセスの再現性を考えます。
- エンジニアリングプロセスの持ち越しに関する知識は、ソフトウェアプロセスよりもはるかに高くなります。概して、特定のブリッジを構築することは、他のブリッジを構築することとかなり似ています。これはかなりよく修正されたドメインです。
- ソフトウェア...それほどではありません。繰り返されるタスクの複雑さを単純化して軽減するパターンがありますが、パターンはエンジニアリング設計プロセスよりもはるかに抽象的なレベルのままです。
最後に、ドキュメントとレビューのレベルについて検討します。
- 橋を架けるには、膨大な数の設計図、回路図、および関連する図面が必要です。一体、構造の特定の要素（鋼など）を示すためのデザインがあります。
- ソフトウェア製品に関するその程度のドキュメントを最後に見たのはいつですか？あなたがこれまでに持っていた場合、それはウォーターフォールの方法論であり、しばしば「遅い」と「機能しない」と表現されていました。あなたのソフトウェア設計文書は、建設を始める前に外部の第三者によって何度レビューされましたか？コーディングを開始する前に、許可の受信を待たなければならない場合、どのように対応しますか？
建設プロジェクトとソフトウェア構築の背後にあるメタファーには価値があります。しかし、その比喩を過度に取り上げないことが重要です。
システムの見積もりと構築について具体的に質問しました。
プロジェクトに関する具体性がないため、ソフトウェア側の見積もりはより複雑になります。再現性の欠如はまた、ソフトウェアプロジェクトがほとんど常にそのようなものを構築した初めてであるため、見積もりを妨げます。最初の種類のプロジェクトの見積もりでは、常にある程度のエラーが発生します。
ビルドの見積もりは、制約/要件の変化する性質に悩まされています。明らかにソフトウェアの仕様を変更するのはとても簡単なので、その変更要求の影響を理解することはできません。エンジニアリングの観点から見ると、ソフトウェアの構築は驚くほどの変更要求に耐えることができ、それでも生き残ることができます。従来のエンジニアリングプロジェクトではそうではありません。変更リクエストを拒否するか、プロジェクトをやり直す必要があります。
ビルドの見積もりも、知識体系の変化する性質に悩まされています。 XYZ機能が機能しない理由を常に突き止める必要があると、開発時間と正確な見積もりを行う能力が妨げられます。コンクリートは一貫して予測可能な方法で治療されます。一連のUIパネルをまとめることは、予測できるほどにはほど遠いものです。
免責事項：
私はエンジニアですが、私の返答はどれも専門家のエンジニアリング意見として解釈されるべきではありません。
私はエンジニアリング会社で働いていますが、私のコメントは必ずしも私の雇用主のコメントを表すものではありません。
私のバックグラウンドは、エンジニアリングプロセスではなく、ソフトウェア開発です。エンジニアリングプロセスに関する私のコメントに、健全な量の懐疑論と節度を適用します。
私の先生の一人がかつてこれについて話しました、しかし比較は家とでした。主な違いの1つは「目に見えない廃棄物」です。私はソフトウェア業界でほぼ10年になりますが、今までで最高の議論でした。
たとえば、家を建てるときに、間違いをしたり、建築プロセスの要件が変わったりした場合、壁を破壊するか、家を取り壊す必要があります。無駄になった材料はすべて、大きな山の中にあります。
ソフトウェアでも同じように（時々）行いますが、「無駄な資料の山」はありません。それは目に見えません、そしてマネージャーはお金と時間の目に見えない無駄を気にしません。
ソフトウェアは変更を受け入れるはずであり、そのマネージャーはこれを知っているようです（彼らは常に、ソフトウェアは変更が簡単であると私たちに言っているので、変更してください）。この例は、ブリッジとソフトウェアの違いを示しています。
それらが同じである方法はたくさんあります。どちらも量産ではなく仕様に基づいて構築されており、どちらもある程度の計画、見積もり、および技術的な専門知識を必要とし、どちらも大規模な単純な原理の適用を必要とします。これにより、たとえば、組立ラインの製造よりも比較が適切になります。
私にとって最大の違いは、ソフトウェアエンジニアリングに必要な精度と、完成品を簡単に変更できることです。これにより、設計と実装のエラーの対処方法に大きな違いが生まれます。
精度に関しては、3トンの定格のビームが実際に5999ポンドしかサポートできない場合でも、ブリッジはそのままです。ギガバイトから少し間違えると、ソフトウェアアプリケーション全体がダウンする可能性があります。そのビットを必要なだけ2倍にすることはできません。それは正しいか間違っています。
さいわい、その1つの不正なビットが発見された場合、変更は比較的簡単です。構築するまでブリッジ設計の欠陥を発見しないと、修正に非常に費用がかかる可能性があります。
これがプロセスの違いです。ソフトウェアをテストした方法でブリッジをテストした場合は、それを構築してから、ハリケーン、津波、地震、および極度の暑さと寒さを引き起こして、まだ立っているかどうかを確認します。それを再構築して数回再テストした後、最終的にテストに合格し、他の人にそれを実行させることができます。次に、青い車が橋を崩壊させ、橋を再建することがわかります。次に、顧客がゴールデンゲートブリッジのデザインをハワイへの橋のためにコピーしようとすると機能しないと不満を言うでしょう。マーケティングにとっては、問題はまさにそのように思われるため、同じコストで機能させることが期待されます。同じ。
ブリッジの要件は、おそらくユーザーからの変更の傾向がはるかに少ないです。 very複雑なブリッジでない限り、ユーザーはプロジェクト全体を通して同じことをしたいと思うでしょう。
何らかの方法で、より多くの詳細橋の要件could変更（最大負荷容量への変更、車線と歩道の数、橋の高さ、エンドポイントなど）橋の）が、橋の建設が始まった後、それらのいくつかのそれらの変更がはるかに難しいと想像します。そして最終的には、橋は依然として橋です-地理的特徴のある側から別の側へとあなたを導きます。橋のプロジェクトの途中でラジオ塔や養鶏場にすべきだと誰もが決めたとは思いません。
別の考え：ソフトウェアでは、同様の市場との競争がタイムラインと要件を推進する可能性があります。私は通常、互いに隣接して建設された橋が、アクセスのために互いに競合しているのを見ません（その場所と私が住んでいる場所は、インフラストラクチャを担当する政府機関によって建設されています）。
また、リリース日が指定されていて、それらに固執するように指示されたブリッジの数はわかりません。十分にテストされ、使用時に崩壊しないことが確認されるまで、ブリッジはトラフィックに対して開かれないと思います。ソフトウェアについても同じことが言えればいいのですが、ほとんどのソフトウェア（もちろん、ミッションクリティカルなシステムは除外されています）では、「バグ」と欠陥のライフコストははるかに低くなっています。
免責事項：私はエンジニアではなく、ブリッジを構築したことがありません