IT業界では、他の業界と同様に、大規模で障害のないプロジェクトを迅速に提供できないのはなぜですか?


509

National GeographicのMegaStructuresシリーズを見て、大規模なプロジェクトがどれほど高速に完了するかを知りました。準備作業(設計、仕様など)が紙の上で行われると、巨大なプロジェクトの実現自体はわずか数年、時には数ヶ月かかります。

たとえば、エアバスA380は 「2000年12月19日に正式に打ち上げられました」、「2005年3月上旬に」、航空機はすでにテストされています。同じことは、巨大な石油タンカー、高層ビルなどにも当てはまります。

これをソフトウェア業界の遅れと比較すると、ほとんどのITプロジェクトがなぜこんなに遅いのか、より正確には、なぜ同じ規模で同じ規模で、十分な人数の人がいるほど速くて障害がないのか疑問に思わずにはいられません。


エアバスA380などのプロジェクトは、両方を提示します。

  • 予期せぬ主なリスク:これは最初に製造された航空機ではありませんが、技術の限界を押し広げており、小さな旅客機でうまく機能したものは、物理的な制約のために大きな旅客機では機能しません。同様に、たとえばボーイング747が完成した1969年には利用できなかったため、まだ使用されていない新しい技術が使用されています。

  • 一般的な人的資源と管理に関連するリスク:プロジェクトの途中で辞める人々、休暇中に人に連絡することができない、通常の人為的ミスなど

これらのリスクにより、人々はまだこれらの大型旅客機のようなプロジェクトを非常に短い期間で達成しており、配達の遅延にもかかわらず、それらのプロジェクトは依然として非常に成功しており、高品質です。

ソフトウェア開発に関しては、プロジェクトは旅客機ほど大きく複雑ではなく(技術的にも管理の面でも)、現実世界からの予期しないリスクがわずかに少なくなっています。

それでも、ほとんどのITプロジェクトは遅くて遅く、プロジェクトにさらに開発者を追加することは解決策ではありません(10人の開発者から2000人のチームに行くと、プロジェクトをより速く提供できる場合があります。計画し、それをまったく完了しないリスクを高めます)。

まだ配信されているものには多くのバグ含まれていることが多く、連続したサービスパックと定期的な更新が必要です(元の製品のバグにパッチを当てて航空機がcrash落するのを防ぐために、週に2回すべてのAirbus A380に「更新プログラムをインストール」することを想定してください)。

そのような違いはどのように説明できますか?それは、ソフトウェア開発業界が若すぎて、大規模でほぼ完璧な製品を非常に高速に提供するために、単一のプロジェクトで数千人を管理できないという事実だけに起因するのでしょうか?


127
興味深い質問。ソフトウェア業界の平均的な労働者の質は、すべてのエンジニアが厳格かつ集中的な学位を取得して公認を受けた土木工学よりもスキルや資格が低いと言わざるを得ません。さらに、大規模なソフトウェア(OS、MS Officeなど)の複雑さの領域は、飛行機よりもはるかに大きいでしょう。間違いなくもっと多くの場所が失敗します!そして最後の重要なポイント:ほとんどのソフトウェアは多かれ少なかれ機能しますが、たとえ不完全に書かれていてバグが多かったとしても...間違いなく失敗のコストは飛行機よりもはるかに少ないです!
ノルドリン

155
他の業界のいずれかで実際に働いている(PRではない)人を見つけて、「大規模な障害のないプロジェクト」について尋ねます。あなたが苦痛の笑い声を獲得することを事実上保証できます。
マイケルボルグワード

151
ソフトウェアプロジェクトの実現には数秒または数分かかります。IDEで「コンパイル」をクリックすると何が起こるかです。一方、プログラミングはデザインです。A380の設計にはどれくらい時間がかかりましたか?
アント

53
そのテレビ番組は誇大宣伝です。彼らは成功したプロジェクトを放映するだけです。どのチャンネルでも視聴者の注意を引くためのプログラムが作成されます。
パンドゥ

117
「すべてのエアバスA380に週に2回「更新プログラムをインストールする」ことを想像してください...」敵ロボットが常に飛行機の脆弱性を探り、訓練されていないパイロットがボタンをランダムに押すことを想像してください。定期的なパッチが必要になると思います。
ネイサンロング

回答:


337

エド・ユアドンの死の行進は、これらのメタタイプの質問の多くに触れています。

一般に、ソフトウェア業界には以下の多くが欠けており、大規模なプロジェクトの邪魔になります。

  • 標準化と作業項目の内訳。

    • これは確かに良くなりましたが、大きなシステムを破壊するための設計構造はまだありません。ある意味では、ソフトウェアは特定のプロジェクトに必要なものに同意することさえできず、物事をコンポーネントに分解することができなくなります。
    • 航空宇宙、ビル建設、自動車などはすべて、非常にコンポーネント駆動型のアーキテクチャを備えており、かなり緊密なインターフェースを備えており、完全に並行した開発が可能です。ソフトウェアは、対応する領域での過剰なブリードスルーを依然として許可します。
  • 成功した同様のプロジェクトの大部分。A380はありませんでした最初の大きな飛行機エアバスが組み込まれています。そこには大きなソフトウェアアプリケーションがたくさんありますが、それらの多くは何らかの面で劇的に苦しんでおり、「成功」と呼ばれるには近づきません。

  • 多数の同様で成功したプロジェクトに携わった多くのデザイナーとビルダー。成功したプロジェクトの問題に関連して、そこにいた人間の才能を持たないことは、再現性の観点から物事を非常に困難にします。

  • 同じことを2回「絶対に」ビルドしない。多くの点で、飛行機は他の飛行機と似ています。翼、エンジン、座席などがあります。大規模なソフトウェアプロジェクトはめったに繰り返されません。各OSカーネルは大きく異なります。ファイルシステムの格差を見てください。それに、本当にユニークなOSはいくつありますか?大きなものは、ある時点で基本アイテムのクローンになります。AIXSolarisHP-UX、... AT&T System Vに戻ります。Windowsには、反復ごとに信じられないほどの量のドラッグがありました。通常、Linuxの亜種はすべて、Linusが開始したのと同じコアに戻ります。バリアントは、真に独自の独自のOSよりも速く伝播する傾向があるため、これを取り上げます。

  • 本当に悪いプロジェクト見積もり。再現性係数は非常に低いため、最終的にどれだけ大きくなり、何かを構築するのにどれくらい時間がかかるかを予測することは困難です。プロジェクトマネージャーと管理者がコードに手を触れて実際に何が行われているかを見ることができないことを考えると、タイムラインに関する非現実的な期待が生じます。

  • QA / QCは、大規模プロジェクト向けに強調されることはありません。これは、コンポーネント間のインターフェイスが緩くなり、コンポーネントの動作方法に関する厳密な仕様がなくなることに戻ります。そのゆるみは、意図しない結果を引き起こし、バグが忍び込むことを可能にします。

  • 一貫して測定可能な資格。一般的に、人々はX言語またはプログラミングで働いた年数について話します。時間は、能力やスキルの質の代わりに使用されています。何度も言及されているように、面接や優れたプログラミングの才能を見つけるのは難しい。問題の一部は、「良い」の定義が非常に主観的なままであることです。

私はすべてが否定的であることを意味するものではありません。ソフトウェア業界は私たちがこれまで行ってきたところから大きく進歩したと思います。このようなフォーラムや他のフォーラムは、設計原則の会話と議論を促進するのに本当に役立ちました。ソフトウェアエンジニア向けの「ベースライン」知識の標準化に取り組んでいる組織があります。確かに改善の余地はありますが、業界はかなり短い期間で大きな進歩を遂げたと思います。


23
いくつかの非常に良い答えの中から受け入れるための答えを選ぶのは困難でしたが、最高の票を持っていないという事実にもかかわらず、私は最終的にこれを選択しました。実際、この答えとm3th0dmanの答えの両方が、まさにIT業界にそのような特異性がある理由であり、ギャップを埋めるために今後をすべきを理解するのに役立ちます。m3th0dmanによる回答と比較すると、これははるかに詳細に見えます。
アルセニムルゼンコ

3
+1ですが、ソフトウェアは心の領域に存在するため、ほとんど無限の可能性がありますが、構築されたすべての飛行機は現実の有限の要件に対処しなければなりません。
スペンサーラス

5
非常によく答えました。面白い例として、大きな飛行機がプロセスや会社の歴史を持たない大勢の人々によって設計および実装されている場合を考えてみましょう。これが、私が見たソフトウェアプロジェクトの90%が完了した方法です。経験豊富なアーキテクトや歴史とプロセスを持つ企業を抱える他の10%は、はるかに成功しているようです。反例として、ソフトウェアが失敗したときに死ぬ原因となるソフトウェアの背後にある開発プロセスを見てください。
ビルK

7
あなたは間違った答えを受け入れたと思います。ダニー・ウッズは正しかった、他の業界の失敗も同じくらい頻繁にあり、プログラミングはその設計を構築していません。ソフトウェアの世界での構築はコンパイラによって行われ、実質的に無料です。あなたの最初の質問は、予備作業(設計、仕様など)が紙上で行われると、物理構造の設計と仕様の作業は、構造を構築する方法の正確な仕様であるということです。ソフトウェアの世界でそれと一致する唯一のものはコードです。コードは設計であり、コンパイルは構築です。
マイケルブラウン

5
しかし、質問自体には欠陥があります。一方で、私たちは自分の欠点に批判的な目を向ける必要があります。プロジェクトが失敗したのはソフトウェア業界だけであるかのように振る舞うのは馬鹿げています。「一度すべての設計が完了した」と言うことも同様に語っています。プログラミングが設計活動であることに同意しなくても、ソフトウェアの前もって行われた詳細で鉄に覆われた設計をどのくらいの頻度で見ますか?ソフトウェアの曖昧な仕様は、仕様が正しくなかった場合にソフトウェア全体をどのように変更するかを気にせずに変更できると予想しているため、曖昧です。
マイケルブラウン

452

答えは驚くほど簡単です。「他の産業」故障率が高いのです。私たちは間違ったものを比較しているだけです。ソフトウェアの作成は「ビルド」と呼ばれることが多いため、他の業界の製造段階や建設段階と比較します。しかしそれを見ると、それは構築ではなく、設計です。ソフトウェア設計はコードで記述されており、ソフトウェアのコンパイルまたはその場で直接解釈することによって、構築はコンピューターによって行われます。

他の業界の多くの設計は、当初の予測よりもはるかに長くかかり、コストがかかるか、単に完成することはありません。おなじみの音?

それでは、ソフトウェアを計画しているときに何をしているのでしょうか?まあ、私たちはまだ設計していますが、初期段階です。

ソフトウェアには、注目すべき製造ラインはありません。最終コンポーネントの構築は(比較的)安価であり、その最終製品の複製は完全かつ効果的に無料です。ビルドアーティファクトをコピーします。


47
OPが言及した業界でさえ、Aerospace、Boeing 787 Dreamliner、JSF F-35の両方とも大幅に遅れています。先週、シドニーの主要なショッピングセンターの1つで駐車場が崩壊しました。シドニーには非常に厳しい建築基準がありますが、間違いが発生します。
チームボブ

23
千倍これ。:でも、質問者のスケジュールリンクは、プロジェクトがソースコードがデザインされ、1988年から開発に実際にあったことを示してdeveloperdotstar.com/mag/articles/reeves_design.html
PKH

2
F-35、ハッブル望遠鏡などの多くの大規模プロジェクトは、開発のソフトウェア側のために遅れました。ハッブルは、ソフトウェアの準備が整っていなかったため、実際には何年もストレージに座っていました。
MrLane

11
@MrLane:現実の世界では、このように機能します。スケジュールは、ハードウェアが実行されることになっており、ソフトウェアが実行されることになっているときに設定されます。ハードウェア設計者は、ソフトウェアチームにICDを提供して、swチームがハードウェアなしでコードを記述できるようにします。ハードウェアは頻繁にスケジュールをずらし、ハードウェアの問題を回避するためにインターフェイスを変更しますが、頻繁にswチームに通知することはありません。最後に、ハードウェアの種類が機能し、配信が遅れます。もちろん、swは予期しないhwの「機能」が無数にあるため機能しません。ハードウェアの問題を修正する方が安価なため
ダンク

11
ソフトウェア、swチームは変更をICDに組み込み、バグのあるハードウェアの回避策を考え出す必要があります。ハードウェアが遅れて配信されていることに加えて、swチームはバグのあるハードウェアの修正も行っています。さて、ソフトウェアチームはまだ完了していません。遅れているのはソフトウェアです。誰もが、swが依存し、swを書き換えて追加の要件を強いた電気、機械、およびシステムのエンジニアリングスケジュールスリップを常に忘れています。彼らが見るすべてはswチームがまだコーディングしているということです。したがって、ソフトウェアは遅れています。
ダンク

180

いくつかの図を指摘するには:

  1. 実装開始後の要件の変更。たとえば、最初のエアバスA380が工場で作成され始めたとき、誰かがさらに200席を欲しければ、そこに置かれるとは信じられません。しかし、プログラマーが開発を開始した後でも、大規模なソフトウェアプロジェクトでは、さらに5種類のユーザーを追加できます。
  2. 複雑さ -大規模なソフトウェアプロジェクトは非常に複雑です。おそらく、人類が設計および開発した最も複雑なプロジェクト。
  3. アーキテクチャおよび設計段階で十分なリソースが消費されていません。
  4. 分野の未熟さ -ソフトウェアエンジニアリングは、他のエンジニアリングの姉妹と比較して比較的若い分野です。これには2つの意味があります。a)ヒューリスティックやグッドプラクティスがそれほど多くない。b)非常に経験のある専門家はそれほど多くない。
  5. 数学的証明の欠如 -ほとんどの場合、数個の形式的な方法は、ソフトウェアが必要に応じて機能することを証明するために使用されません。代わりにテストが使用されます。これは、数学に大きく依存している他の工学分野にも当てはまります。その理由は複雑さです。
  6. ラッシュ -多くのマネージャーは達成できない期限があります。期限のために、コードの品質が2番目になります。

質問に厳密に答える-私は、他の人がプログラマーから非常に高い期待(特に納期)を持ち、大規模なソフトウェアのプログラミングがいかに難しいかを正確に理解していないと信じがちです。


55
ソフトウェアでの正式な数学的証明は、実際には正しく実行できないことが多いという事実に加えて、最終的にはプログラムを2回(実際のプログラミング言語で1回、正式な仕様言語で1回)書き、その両方を検証すること以外ありませんバージョンはまったく同じです。
tdammers

5
tdammers、両方を同時に作成するのに役立つツールがあります。Coqは、認定CoqプログラムからOCamlまたはSchemeのプログラムを抽出する「プログラム抽出」をサポートしています。
jkff

66
「実装開始後の要件の変更」。これを「トイレの移動問題」と呼びます。あなたは家を建てていて、バスルームに最後の仕上げをしていて、所有者はトイレを別の場所に置きたいと思っています。あなたは彼らにコストの見積もりを与えます。彼らは「なぜそんなに、私はトイレを8フィート離れた方がいいの?」と言って、大声で叫ぶ。その後、トイレに移動できるようにするには、新しい配管を取り付けたり、壁や床を開いたりする必要があることを説明します。遅い変更は常に高価です。
レイジーDBA

7
飛行機のテストは、実際にはソフトウェアのテストよりもはるかに難しいと思います。飛行機では、作成したソフトウェアシミュレーターや風力タービンが、実際にそこにいるときの動作を実際に反映していないと考えたときに、あなたが魔法をかけたすべての魔法が役に立たなくなります。ソフトウェアでの形式的な証明は、不可能なエンジニアリングでの形式的な証明と比較して、難しい問題にすぎません。
ライライアン

2
リストの#1は最も重要なIMOです。さらに2つのことを追加します。-多くの大きな変更を短時間で行うことができます(たとえば、「通信プロトコルを切り替えることができます!」)。しかし、これらの多くは、長期的にプロジェクトを管理するのを非常に難しくしています。-ソフトウェアが実行される環境の変化は、短時間で大幅に変化する可能性があります。飛行機の基本的な前提は変わりませんが(嵐の中で飛ばなければならず、しっかりした滑走路に着陸する必要があります)、たとえばOSの新しいバージョンが登場した場合、ソフトウェアは完全に壊れます。
sydd

140

質問の前提には少し欠陥があります。A380とボーイング787の両方が数年遅れで納入されました。

A380の場合、遅延の多くは、CATIA設計ソフトウェアの異なるわずかに互換性のないバージョンを使用しているエアバスのフランスとドイツのユニットが原因で発生しました。これは、互換性のない形で、飛行機に完全に適合しないワイヤリングハーネスとして現れました。

最も広く使用されている航空機設計ソフトウェアであるCATIAには何も問題はありませんでしたが、誰かがソフトウェア構成ボールを落としました。

ボーイング787もソフトウェア関連の遅延に悩まされていましたが、その問題のほとんどは、重量制御やサプライヤーによる標準以下の部品の配送など、より伝統的な新しい飛行機の問題でした。

A380とB787の両方は、最初の航空機に構造的な問題が発生した後、翼の設計を変更する必要がありました。

大規模で複雑なプロジェクトは、すべての分野の人間にとって困難です。


10
同意した。ソフトウェアは物理的なものよりも「だらだらと生産される」という誤った態度があると思います。なぜなら、悪いソフトウェアは非常に目に見える修正に終わり、誰もが壊れたソフトウェアに対処しなければならないからです。飛行機ががらくたであり、彼らがそれを送り返さずに何らかの作業を行わなければならない場合、それは巨大な欠陥でない限り、ほとんどの場合、メカニックが彼ら自身の間で不平を言う何かです。そして、それらも起こります。
ベンブロッカ

6
例に欠陥があるとしても、疑問はまだ残っていると思います。統計的に証明されているように、ソフトウェアプロジェクトの最終コストははるかに大きく、予測よりもはるかに時間がかかります。
陶酔

18
民間航空機システムの設計と実装は、本質的に大規模な、そして大規模複雑、ITプロジェクトの完了、いずれかを含むことに留意すべきであり、完全に、正しく機能することを。
とがった

6
そして、A380が2010年と同じくらい大きなリコールを持っていることを考えると、それでも「完璧」とは呼びません。
ムハンマドアルカウーリ

3
また、多くのコンセプト飛行機、特に軍事契約は長年にわたって資金提供およびキャンセルされてきました。飛行機は良い例ではありません。何年も何十年も経ってから(分類された)失敗の多くを耳にするからです。
SilverbackNet

112

ここに超高層ビルの男。あなたの質問に答えられるかどうかはわかりませんが、スレッドのさまざまな項目に光を当てることはできます。実際、建物は非常に高速で発生します。主な制約はロケール(規制)です。しかし、一般に、高層ビルの最初から最後まで3〜10年かかります。

新しい建物と新しいソフトウェアプロジェクトを比較するのはあまり正確ではないと思います。新しい建物は、カーネルまたはOSの新しいバージョンに近くなります。この点で、ソフトウェア開発ははるかに高速です。ゼロから構築することはありません。これは、クライアントがサインアップしないリスクの高いタスクになるためです。建物のほとんどの設計と開発は、実績のある完成したプロジェクトの派生物です。

個人的な経験から、これまでに構築されたプロジェクトは10分の1です。プロセスは設計主導型ではなく開発主導型であるため、設計がプロセスの安価なコンポーネントであるため、鉄鋼の価格のようなものがプロジェクト全体で上昇する瞬間は窓の外、つまり設計されます。

設計には、構想から回路図まで1か月、設計開発まで2から6か月、建築家、計画コンサルタント、構造エンジニア、風力エンジニア、サービスエンジニア、数量およびコストコンサルタント、測量士のチームによる詳細および建設文書までさらに6か月かかります。アクセシビリティエンジニアとリストが続きます...

仮想対物理の議論はあまり正確ではありません。また、主に仮想ツールを使用し、さらに、最終製品から時間的および規模的に離れています。ほとんどの場合、モックアップスケールで建物の側面をテストすることさえできず、シミュレーションを使用して、発生する可能性のあるものを予測しようとします。

複雑さに関しては違いがありますが、全体的にはほぼ同じです。相互に関連するユニットと、複数レベルの階層化された抽象化とインターフェースだけでなく、コミュニケーションを非常に困難にするプロセスの小さな部分に非常に専門化されています。

設計対開発の議論に関しては、どちらのプロセスも設計されていると思います。これらを分離しておくのは学問的には素晴らしいことですが、物事の仕組みがわからない場合は設計できません。失敗のリスクを高めるだけです。

全体として、OPの質問による私の(潜在的に間違っている)推定は、プログラミングは工学よりも芸術であるということです。なぜ人々は喜びを味わうだけでなく、無料でそれを行い、その中に表現と優雅さを見つけるのでしょうか?また、コンピューターサイエンスは(錫のように)エンジニアリングというよりも科学です。既存のパーツにパッチを当てるのではなく、アルゴリズムを証明して、機能するように努力するのはなぜですか?これが意味をなすかどうかはわかりません。私はソフトウェアの男ではありません。

ソフトウェアの設計と開発で私を襲った1つの側面は、メディア自体についてです。コンピューターは人間中心の仕事を非常に不自然にします。すべてが非常に明確であり、許容値はほとんどありません。精神的にこれを回避するのは難しく、中には複雑さを捨てることでそれを回避する人もいます。他に何もない場合、これは何か関係があるのでしょうか?


2
+1洞察力をありがとう。「物事がどのように機能するかを知っている場合に設計する」->「物事がどのように機能するかを知らない場合に設計する」?
トクランド

ねえビルダー、私はこの投稿にいくつかの編集を提案しました、あなたが優れた点を持っていると思います、私はいくつかの文法をきれいにしようとしました。
スティーブン

私は、プログラミングが工学というより芸術であるという点に間違いなく同意します。私は、創造性がソフトウェア設計の中核的側面であるとよく思います。
ランザフェーム14年

1
大規模なソフトウェアプロジェクトとタワーが同じような複雑さを持っているという主張には同意しません。構造エンジニアとソフトウェアエンジニアの両方として働いた経験から、ソフトウェアの複雑さははるかに高いと思います。おそらくこれには多くの理由がありますが、私がお勧めするのは、エンジニアリングにはかなりの余地があるということです。建設設計の上限はほとんどの場合コストによって与えられ、それはソフトな制約です。コンピューターはあいまいさをうまく処理できないため、ソフトウェアは正確である必要があります。スラブが機能しない?鋼のたわごとを追加し、彼女は正しいでしょう。
サイモンロブ

一部の人々は、喜びのために建物を設計し、構築します。雇用主には言わないでください。しかし、今では私のソフトウェアの一部はサグラダファミリアのようなものだと思います。しかし、興味深いデザインで、構築して使用するのが楽しく、まだ立っています。
ピーターA.シュナイダー

44

それから、それらの設計にはどれくらい時間がかかりましたか?年?二?10年?デザインは何かを構築する上で最も複雑な部分であり、構築自体は簡単です。

この記事に基づいて、ソフトウェア開発はほとんどが設計プロセスであり、設計文書がソースコードそのものであることが徐々に理解されています。また、設計プロセスは生産プロセスとはまったく異なります。わずかな要件の変更でさえ、プロジェクトの全体的なアーキテクチャに大きな変化をもたらす可能性があるため、経験豊富な人材が必要であり、計画することは不可能です。この理解は、風洞で飛行機モデルをテストするのと同様に、最終設計ドキュメントとしてコード品質を改善し、設計プロセスの一部としてテストとデバッグを行うことに焦点を当てたアジャイル方法論の基礎です。

構築自体はコンパイラによって自動的に処理されます。そのおかげで、数分で製品全体を構築できます。

ソフトウェアプロジェクトが大幅な遅延と高コストで終了する理由は、管理者がそのような設計プロセスを推定、予測、計画できるとまだ考えているためです。これは実際に有効であるよりも頻繁に発生します。彼らは依然として、最終結果がコストの増加と期限の遅れでほとんど反対であるにもかかわらず、人々を厳格な建設プロセスに結び付けることにより、何らかの方法で品質を向上させることができると考えています。


2
「この理解がアジャイル方法論の基礎です」。まさに。ウォーターフォール方式は、超高層ビルにとって理にかなっています。基礎を注ぐ前に、設計図のすべての詳細を正確に表示する必要があります。しかし、高層ビルの解体と再構築が無料で、コードのコンパイルのようにほぼ瞬時に行われる場合は、おそらく反復プロセスを使用することになります。
ネイサンロング

22
@NathanLong:特に、3年ごとに新しいコンクリートが出てきて、誰かが複数のエレベーターを単一のシャフトで走らせる方法を考え出し、突然スチールが冷たくなり、誰もがカーボンからフレームワークを構築することに決めた場合ファイバ。そのようなことは、ソフトウェア業界では常に続いています
TMN

2
「ソフトウェア開発は、ほとんどが設計プロセスであり、設計ドキュメントがソースコードそのものである」とあなたは目を開きました。ありがとう。
ブロケビンD.

@TMNスカイスクレイパーを構築しているときに、見た目が悪いためにインテリアのカラーパレットを変更すると想像してください。建物のあらゆるコンポーネントに適用されます。単一軸に複数のエレベーターを実行しようとする一つのことですが、あなたもシャフトにそれらのすべてをフックしようとする前に、別のサプライヤーから20エレベーターをテストする必要があるだろう...
ロイック・フォーレ-ラクロワ

@LoïcFaure-Lacroix:エンジニアは20種類のエレベーターをテストできます。開発は、最初に聞いたブログ投稿で説明されているエレベーターを使用するだけです。その後、建物が開き、エレベーターに問題があると、それらを建設した会社がもはや存在しないことに気づきました。別のサプライヤから交換品を入手しようとすると、元のエレベータが非標準のシャフトを使用
TMN

39

エアバスA380の設計の最中に、誰かが会議でパイプを使い、「それは三葉機として構築できるのか?」と言ったと想像してください。他の参加者は、「うん、そうだ。三葉機。翼が多いほど良い」と言って参加しました。次の3年間は、A380の設計を三葉機に変えることに費やされています。別の会議で、誰かが「三葉機ですか?それは古いです。複葉機が欲しいです。翼の片方を取り除いてください。」と言います。

または、橋の建設プロジェクトの途中で、誰かが「ええ、私たちは海運会社と取り引きをしました。彼らの船はもっと高いので、橋をさらに40フィート高くする必要があります。修正してください。ありがとう。 」

これらは、大小を問わずソフトウェアプロジェクトが驚くべき速度で失敗する理由の一部です。


8
これがまさに起こることです。管理タイプまたはクライアントは10秒ごとに気が変わり、開発者をいらいらさせます。私はこのようながらくたのために最後の仕事を辞めました
エリンドラモンド

3
これが思い浮かびます:youtube.com/watch
BKorP55Aqvg

21

ITで働いている機械工学のバックグラウンドを持つ人として、ITでの成功率が低い理由についてよく疑問に思いました。

このスレッドの他の人たちと同様に、失敗の原因はITの未熟さ、詳細な標準の欠如(はい、真面目です。単純なボルトの標準シートを確認したことがありますか?)コンポーネントとモジュール。

建物の建設や造船のような他の産業も、はるかに「beatられた道」を持っています。特定のソリューションプロトタイプの知識と経験で、カスタマイズされた形で何度も再利用されます。サイズや目的の異なる建物、船、飛行機がどうして似ているのかと疑問に思ったことはありませんか?(もちろんルールには例外があります...)

これは、これらのプロトタイプが十分に研究され、よく理解され、一般的に使用され、実績があるためです。他の方法でできなかったからではありません。ITにおける標準化はほとんどの場合ではありません:(大)のプロジェクトが同時に研究と配信を行って、コンポーネントを再発明する傾向同じ人と!

これらは必然的に1回限りの製品につながります。これは、開発とサービスに費用がかかり、エラーが発生しやすく、不確実な条件下では予測不可能な方法で故障します。そして、このため、もちろん、これらの製品はずっと早く廃止され、書き留められ、わずかに優れたものと同等のコストで置き換えられます。ITが必要とするのは、中世の職人を効率的な工場に変えた産業革命に相当するものです。

ただし、ITを本当にユニークなものにしている要因があります。これらの他の言及された産業とは対照的に、ITは真に遍在しています。現代生活のあらゆる側面で使用されいます。したがって、ITはこの大きな進歩を達成した小さな奇跡であり、ITが成果を上げることができます。


5
+1。標準化の良い例(単純なボルトの標準シート)。ITでは、正規化されるコンポーネントはまれです。登録フォームを取る:すべてのWebサイトが独自に改革を行い、登録フォームがUnicode、空の文字列、文字列が長すぎるなどで動作する方法を知っている開発者はほとんどいません。
Arseni Mourzenko

1
@MainMa:下手な例、あなたはあなたのボタン、テキストボックス、オプションボックス、divからオプションボックスを作成しますか?いいえ、ブラウザのフォーム要素を再利用します。ブラウザはオペレーティングシステムのフォーム要素を使用していました。
ライライアン

4
私はむしろコントロールではなく内部について話していました。いくつかのランダムなウェブサイトを取ります。パスワードに漢字を使用できますか?25文字のパスワードを使用できますか?パスワードまたはユーザー名に空白を入れるとどうなりますか?このすべては、正規化されたかもしれないが、そうではありませんし、すべての人が、16文字(例:MSN)に限らず、ハッシュおよび/または塩漬け、またはパスワードすなわちない、しばしばひどく、すべてのプロジェクトのために車輪の再発明さなど、
Arseni Mourzenko

4
ITを「職人」から「工場」に変更することは不可能かもしれません。工場はすでに作成されたプロセスを実行しています。工場の労働者は、人間の思考をほとんどまたはまったく持たずにプロセスを実行します。この事実により、多くの工場が人間をロボットに置き換えました。ソフトウェアでは、プロセスを実行するのではなく、プロセスを作成します。ソフトウェアの作成は、ファクトリを実行するというよりも、ファクトリとそのプロセスを設計することに似ています。ソフトウェアの作成は標準の恩恵を受ける可能性がありますが、基本的に工場になることはできません。
mike30

@ArseniMourzenkoは、「ボルトのデータシート」(つまり、ツール、機器)を「登録フォーム標準」と比較するのは悪い比較です。登録フォームは、「屋根」または「玄関」のようなものになります(実際、これらを作成する方法は無数にあります)。ボルトと比較すると、プロセッサパイプラインの動作に似ています。信頼性の高いOS(「使用するマウントオプションによってはデータがディスクにヒットする可能性がある」ではなく、厳密に定義された特性を備えています)と同じ開発ツール(標準のコードの90%をチェックできる必要があります)プロパティ)
sehe

15

私はあなたの声明に同意しないことを恐れています。

エアバスとボーイングは、飛行機を製造する会社の2つの例です。飛行機を作る会社はいくつありますか?ソフトウェアを構築する企業の数と比較すると、ごくわずかです。

ソフトウェアプロジェクトをねじ込むのと同じように、飛行機プロジェクトをねじ込むのも簡単です。航空機製造業界の参入障壁がソフトウェア業界と同様に低かった場合、多くの失敗した航空機プロジェクトを確実に目にするでしょう。

車を見てください。非常に耐久性が高く高度な自動車を製造する高品質のメーカーがあり(Land Rover、Mercedesを考えてください)、修理せずに1年も続かない自動車を製造するメーカーがあります(KiaまたはCherryを考えてください)。これは、参入障壁がわずかに低い業界の完璧な例です。これは、プレイヤーが弱くなってきた場合です。

ソフトウェアも同様です。バグの多い製品がたくさんありますが、Windows、Office、Linux、Chrome、またはGoogle Searchは非常に高品質のプロジェクトで、納期どおりに配信され、航空機と同等の品質レベルを備えています。

多くの人々が見逃している他のポイントは、私たちが人生の事実としてとっている車、タンカー、または航空機のメンテナンスにどれだけのメンテナンスが費やされているかです。すべての飛行機は、離陸する前に技術的な検査を受ける必要があります。数キロのマイルごとに車を点検し、オイル交換、タイヤ交換などの定期的な点検を行う必要があります。

ソフトウェアにもそれが必要です。機械/物理製品と同様に、診断、防止、またはソフトウェアの状態と品質の監査に多くの時間を費やした人だけがいるとしたら、こうした声明はもっと少なくなると思います。アプリケーションを起動する前に毎回アプリケーションのログを読みますか?まあ..それが航空機だったら、あなたはしなければならないでしょう;-)


5
Windowsは予定通りに出荷されないことがよくあります(Longhorn、別名Windows Vistaは、当初2003年に出荷される予定でした)。Officeについては知りませんが、あなたが明示的に言及した他のソフトウェアプロジェクトのほとんどはタイムラインを持っていないか、リリーススケジュールが非常に頻繁であるため、リリースで準備ができている機能をすべて含み、準備が整うまで他のすべてをプッシュオフします。
ケンブルーム

2
これは、高品質ソフトウェアのより良い例です。420,000行とバグのない:スペースシャトルに電力を供給したソフトウェアです。念のために言っておくと、この種の品質を得るには莫大な費用がかかりました。
dodgy_coder

@dodgy_coder、安全な航空機を構築することが;-)いずれか安くはない
カリム・アガー

1
@PaulNathanはまともです;)
ジェームズKhoury

3
@KarimA .:安全な航空機を構築することは安くはありませんが、航空機を安全にするものの大部分はソフトウェアです。ですから、航空機設計の重要な部分は実際にはソフトウェア設計です!

10

デジタルビルディングブロックには1または0を指定できます。間にはありません。

機械設計にはある程度の許容度があります。完全ではないリベットをブリッジに1つ入れることができますが、ほとんどの場合、コード内で1が必要な場所に0を置くだけでもプログラム全体が失敗する可能性があります。

コンピューティングの論理的かつインタラクティブな性質により、ごくわずかな変更でも、重大な障害につながる可能性があります。


21
私はかつて、誰かが「最後のドアノブを家に後ろに置いたときに家全体が爆発した場合、建設はプログラミングのようになる」と言うのを聞いたことがあります。
モーガンハーロッカー

9

私はしばしば同じことを疑問に思っています。私たちが何をしているのかまったくわからないアマチュアの束のように感じることは確かです。私はマネージャーやその他の外部要因を非難する説明を嫌います。私たちの開発者は私たちが作成したものに責任を持つべきです。

私たちはエラーが安いビジネスにいると思います。超高層ビルを再構築したり、販売されているすべての携帯電話を思い出したりするのに比べて、ソフトウェアにパッチを当てるのは安価です。

これはバグが日常生活の一部である文化を作成しました。彼らは肩をすくめて受け入れます。いくつかのバグはおそらく避けられないかもしれませんが、それらは日々の仕事支配すべきでしょうか?とにかくバグを期待しているからこそ、QAがトラブルの価値があると感じないマネージャーを完全に理解しています。バグを修正するのはつまらないので、エラーのないコードを作成するために全力を尽くさないプログラマーは理解できません。

本質的に私はそれが文化の問題であると信じており、それが変わることを願っています。


5
エラーのないコードを作成するためにあらゆる努力を払っていないプログラマを理解していますか?それは、2倍の時間がかかり、管理者が昨日
ベータ

4
それは他の産業にも当てはまりませんか?外部要因が存在しないことは否定しませんが、変化は内部から生じなければならないと考えています。ソフトウェアエンジニアがそれぞれの分野の専門家としての役割を受け入れた場合、彼らの推奨事項と見積もりは尊重され、経営陣によって再評価されることはありません。それとも私は世間知らずですか?
ワックスウィング

2
時々顧客を訪ねて、私がプログラミングしている製品を使用しているのを見ると、しばしば驚かされます。バグや機能によって動作が非常に難しくなります。プログラマーとしては、ユーザーにとってはどれほど簡単に改善できるのでしょうか。それを報告する。
we敬の念

7

エンジニアリングの標準と実践は、IT(独立した産業)と航空宇宙では非常に異なります。これはおそらく、航空宇宙ITの標準文書に遭遇したときにIT専門家がどのように反応するかを考慮することで最も簡単に理解できます。たとえば、最近インターネットに登場したジョイントストライクファイターC ++標準

多くの人が娯楽や物欲的な辞任を表明します(そうすればいいのですが)。そして、多くの人がrid笑で対応し、このように消費者向け製品を提供する実用的な方法はないと主張しています。消費者の期待ではなく、経営者の期待を考えれば、これも正しいかもしれません。何もデモをせずに、ほんの数週間コーディングしてコーディングするコーダーには、大きな不信感があります。神は、2週間だけ何かをデザインするコーダーを助けます。飛行機ではそうではありません。

ソフトウェアでは、人々は本当に何かを今すぐに期待しています。確かに、推論が進むと、それを本当にしっかりさせるには少し時間がかかります。しかし、1週間で複雑なことを簡単な言葉説明することはできませんか?また、正直で複雑な用語で記述された複雑なものは、想像力を刺激することはめったにないことを学びます。したがって、多くのエンジニアは、創造的な方法で組み立てられた本当にシンプルなものの想像された世界に共謀することになります(難しいものの世界が本当にうまく行われるのに対して)。


5

私からいくつかのもの:

1-標準と部品:それらは飛行機メーカーであり、開発者ではありません。よくわかりませんが、多くの部品が外部委託されていると思います。彼らは独自の電子機器を構築せず、ある会社から座席を取得し、エンジンはおそらく他の場所で開発されます。

一方、ソフトウェアプロジェクトは、ほとんどの場合、いくつかの小さなフレームワーク/ヘルパーのみを使用してゼロから開始します。

2-市場投入までの時間:飛行機にとって時間は重要な問題ではありません。エアバスの設計は、完成する何年も前に確定し、その間に起こる可能性のある大きなブレークスルーを無視することを選択したに違いありません。(たとえば、自動車メーカーと同じですが、現在開発している最先端の技術は、5〜10年後には市場に出回るでしょう。)

ソフトウェアについては、非常に機敏である必要があります。巨大なプロジェクトを今すぐ開始し、変更せずに開発するのに3年かかる場合、もう利用できない技術に頼っている可能性が非常に高いか、製品が完全に古くなっています。これにより、多くの問題が発生します。

3-リリースサイクルとバージョン。-飛行機は「解放」されたときに完全に完成する必要があります。安定したベータバージョン、ナイトリービルドなどはありません。さらに、一度完了すると、小さな方法でしか変更できません。既存のボーイングに100席のレベルを追加することはできません。それは不可能です。

一方、ソフトウェアには漸進的な変更があり、多くの場合、「機能するビルド」ですが、必ずしも完成した製品ではありません。また、ITでは「飛行機にさらに50トンの荷物を入れる別の荷物室を追加しましょう」と言うのは珍しいことではありません。


5

答えは非常に簡単だと思います:

1)物理的な構築と実装は、人々がいる限り存在します-物理プロジェクトを実装するための方法と技術を開発するのに何千年もかかりました。まったく新しい異なるスキルセットを必要とするソフトウェアの「構築」は、50年以上も前のものではありません。まだ十分に理解できていません。

2)仮想構築はより困難です-物理的な現実がまったくないことを心の中に「見る」必要があります。製品がどのようなものであるか、そして製品を作成するために必要な手順を知る前に、多くの情報を分析して抽象化する必要があります。橋や建物を建てるときはそうではありません。

3)多くの場合、ソフトウェアの障害やバグの原因を見つけることは、物理的なエンジニアリングを行う場合よりもはるかに困難です。桁が座屈する場合、座屈する場所がわかり、それを支えて失敗するなどのサポートが表示されます。物理構造のように物理学と数学の法則。


4

Jack Ganssleの埋め込みミューズからの記事の逐語的なコピーを使用して答えてみます。これはどこでもファームウェアを意味しますが、精神的にソフトウェアに置き換えてください。

何と比較して?

ファームウェアは、世界で最も高価なものです。ロッキード・マーティンの前CEOであるノーマン・オーガスティンは、彼のすばらしい本「アウグスティヌスの法則」で、防衛コミュニティが遭遇した問題について明らかにする物語を語っています。高性能戦闘機は、燃料範囲と性能の相反するニーズの微妙なバランスです。速度対重量。70年代後半には、戦闘機はかつてないほど重くなっていたようです。常により大きな利益を追求している請負業者は、コストを大幅に追加できるものの、重さは何もありませんでした。

答え:ファームウェア。無限のコスト、質量ゼロ。現在、アビオニクスは戦闘機のコストの半分以上を占めています。最新のアメリカの戦闘機であるF-22を考えると、それは大きな変化です。アウグスティヌスは、彼がこの物語を語るとき、ほんとうに歓喜を唱えます。

しかし、なぜソフトウェアはそんなに高価なのでしょうか?トム・デマルコはかつてこの3つの言葉でこの質問に答えました:何と比較して?彼は比較的退屈なビジネスケースについて話し合いましたが、その答えは長年私の心に響きました。何と比較して?ソフトウェアを使用して、前例のない複雑さの製品動作を定期的に作成します。確かに、コードは高価です。しかし、文明の歴史上、これほど複雑なものを構築した人はいません。

ウィキペディアから恥知らずに持ち上げられ、正確性がチェックされていない、次のバブルソートを検討してください。

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

おそらく110時間の非スペース文字であり、おそらく1〜2時間で放り出されます。ソフトウェアがなく、他の戦略を使用してソートを実装する必要があったとします。費用はいくらですか?

機械技術者は、彼の職業がコンピューターよりずっと前にソーターを作ったことを自慢するかもしれません。IBMの1949年モデル82カードソーター(http://www.columbia.edu/acis/history/sorter.html)を検討してください。スループットは毎分650カードであり、コードスニペットが4 MHzでも管理できない場合があります。 Z80。モデル82は、もちろん、一度にカードの1列のみをソートしました。デッキを完全にソートするには、数十回のパスが必要です。

この獣を設計し、構築するのにどれくらい時間がかかりましたか?年、間違いなく。また、非常に高速で巨大なデータセットを処理できるコードと比較すると、その機能は劣っています。しかし、それは1949年でした。FPGAとVHDL、またはCPUなしで、電子部品からバブルソートを作成するのにどれくらい時間がかかりますか?

1時間で、チップレベルの1つ上の大まかなブロック図を管理しました(ブロックには「加算器」、「16ビットラッチ」などの名前が付いています)。しかし、シーケンスロジックは明らかにかなり乱雑であるため、適切な方程式を書くことはそれほど難しくないと仮定して、PLDに放り込みました。そして、はい、おそらくそれはプログラマブルロジックのルールを破りますが、合理的な時間内にゲートを使用してすべてのロジックを設計およびデバッグすることは、1ガロンのガスと同じくらいありそうにありません。

16ビットのワードとアドレスを想定すると、回路には約12個の16ビットラッチ、加算器などが必要になります。プラスメモリ。また、ソートされていないデータがRAMにどのように到着するか、結果がどのようにエクスポートされるかについてもわかりません。これらは不特定の設計要件です。ソフトウェアのみのソリューションでは、関数プロトタイプを書くだけでこれらの要件が自然に解決されます。

大まかなブロック図を回路図に変換するのに1日かかる場合があります。次に、PCBの設計と製造、部品の注文とロード(および予期しないが避けられない寿命末期の問題に対処するための設計の変更)、そしてもちろん回路を動作させる時間があります。数週間の努力と、ボード、部品、および適切なテスト機器のための多額のお金を話すことができました。

これはすべて、7行のコードを置き換えるためのものです。10,000未満の実際の組み込みプログラムはほとんどありません。多くは百万を超えています。実際の超大型コンピュータープログラムを置き換えるには、どのくらいのハードウェアとエンジニアリングが必要ですか?

スプレッドシートのような実際のプログラムを考えてみましょう。プロセッサなしで回路を作成するには、どのくらいの回路が必要ですか?それは都市の大きさかもしれません。

ファームウェアは世界で最も高価なものですが、それは解決する問題の想像を絶する複雑さのためです。しかし、それは他の選択肢よりもはるかに安いです。そのため、上司がソフトウェアにこれほど時間がかかる理由をいらいらせずに尋ねると、何を言うべきかがわかります。 何と比較して?

だから!ソフトウェア/ファームウェアには比類のない複雑さがあります。


3

ソフトウェアのエンジニアリングと管理は、他の多くのエンジニアリング分野と根本的に異なります。成果物は物理的なものではなく、生産プロセス設計および開発プロセスです。ソフトウェアの別のコピーを作成すると、限界費用は本質的にゼロになります。すべてのコストは、最初のコピーの開発にあります。

規律としてのソフトウェアエンジニアリングと管理の相対的な若さのため、ソフトウェア開発とエンジニアリング全体を妨げる事実として誤解と誤解が残っています(このリファレンスを参照)。


3
ソフトウェア開発の未熟さに関する+1。土木工学は、その実践を開発するのに数千年を費やしてきました。航空宇宙産業は100を数え、他のエンジニアリング分野に基づいています。ソフトウェアはまだ若い。また、通常はあまり理解されていません。人々は小川に橋を架けたり、子供のように紙飛行機を作ったりすることができます。これはソフトウェアにも当てはまりません。
アンディバーンズ

3

すべての開発者が平等に作成されるわけではありません。良いものもあれば、そうでないものもあります。

いつも他の人のコードを読んで、私が言っていることを感じてみてください。余分な論理ステートメントが多すぎると、リスクが増える可能性があります。これらのリスクは、悪い行動やバグにつながる可能性があります。論理ステートメントが不足しているため、null参照があります。優れたプログラマーはこれを理解し、いつどこで何をすべきかを知っています。しかし、誰も完璧ではありません。物事は複雑です。よく考えられていない他の人の作業を追加すると、プロジェクトがどのように実行されるかを簡単に確認できます。


3

大聖堂の建設には、最大100年かかりました。

一部のエアバス機では、100万行のコードが必要です。

何かを改善する時間が長くなればなるほど、より多くの改善が得られるので、ソフトウェア業界に数世紀の試行錯誤を加えて改善してください。または欠陥。


ケルン大聖堂は1248年に始まり、1880年に完成しました。632年。
-gnasher729

3

大規模なプロジェクトは、大規模な組織で頻繁に発生します。大規模な組織で働いたことがない場合、パフォーマンスと生産性を損なうことが保証されていることが1つあります。それは官僚主義です。

驚くべきことに、多くの人々は官僚制度が何であるか(しばしば政治と混同されます)、あるいは官僚制度の問題があるかどうかを知りません。

最近、スマートカード認証を実装するプロジェクトを完了しました。当初は3か月と推定されていました。15か月かかりました。遅延の費用、予算、範囲、技術的な理由はありませんでした。スコープは実際にはかなり狭かった-昇格された特権を持つアカウント(管理者アカウント)のみ、合計で約1,200アカウント。

もう1つの重要な要素は、ビジネスパートナーです。これにはベンダーも含まれます。パートナーにプロジェクトの遅延を引き起こす問題がある場合、実際に遅延の問題を解決するオプションは多くありません。彼らはあなたのために直接働きません、そして、あなたは原因であるかもしれないパートナーでその人を解雇できないかもしれません。パートナーは解雇されるか、金銭的罰金または制裁措置の対象となる可能性がありますが、プロジェクトが遅延したという事実は変わりません。これは、ボーイング787ドリームライナーで巨大な調達戦略を引き受けたときにボーイングで発生したものです。


3

私はあなたのために短いバージョンを持っています:

簡単に、または合理化できるものは何でも、私たちの代わりにそれを行うプログラムを作成します。

そして、代わりにメタプロセスと戦います。

それ自体はそれほど真実ではありませんが、ブログエンジンを書く代わりに、毎日何千ものブログが設定されています。毎日仕事をするために、特別に設計されたデータベースアプリケーションを記述する代わりに、数千のExcelマクロが書き込まれます。

他にも多くの要因があります-それらのいくつかはここで言及しました-しかし、私は議論にこの点を加えたかったです。


同意する。大規模なプログラム、30年以上に渡って100回行われているため、問題なくスケジュールどおりに配信できます。たとえば、テキストエディター。
Droogans

それだけでなく、以前に行われた大規模なプログラムを問題なく配信する方法は、Webサイトから古いプログラムをダウンロードしてコピーを作成するだけです。しかし、何らかの理由で、それは大規模なソフトウェアプロジェクトの成功とはみなされません。
bdsl

3

説明責任の欠如...航空機がcrash落すると人々は訴えられます。ソフトウェア業界は、ソフトウェアの欠陥に対する責任を負いません。そのため、堅牢で安全な製品を作成するインセンティブが失われます。


1
私はそれを長い間言ってきました。アプリがクラッシュしたときに訴えられた場合、コードははるかに堅牢になります...そして、MSを例にとると、訴えたい会社がたくさんあります。たとえば、すべての更新とパッチと他のものを壊すバグや修正。それらの失われた時間のためにそれらを訴え、品質が急速に向上します。
ベクトル

その場合、コストが増加し、機能が減少します。
ジムG.

1
@JimG。問題は、機能や価格ではなく、信頼性に関するものでした。もちろん、より信頼性の高い製品を製造する必要があると、設計スペースに多くの制約が導入され、他の側面(機能とコスト)が損なわれる可能性があります。
GreyGeek

4
また、ボーイング737のコストは5,000万〜8,000万ドルです。あなたは1つに乗るたびに支払います-Officeを開くたびに支払いますか?誰かが私のソフトウェアをまっすぐに使用するたびに支払いを受けたら、信頼性に専念します。
FlavorScape

1
@Jim G:5つの安っぽいバージョンではなく、1つの安定したバージョンの製品を使用したいと思います。
ジョルジオ

2

ほとんどの大規模なプロジェクトでは、サブプロジェクトの分離度が高く、少数の設計制約を定義できます。これらのサブプロジェクトがそれぞれ完了すると、プロジェクト全体が機能します。サブプロジェクトで何か問題が発生した場合、すべての努力は問題になりません。サブプロジェクトを完了する別の方法を探すだけです(たとえば、別のエンジンを使用する)。

これは可能ですが、ソフトウェアプロジェクトでは実際的にも人間性の問題としても困難です。

一部では、他の業界は、この種の分離可能性が良いことであるという難しい方法を学んでいます。たとえば、ロールスロイスの航空機エンジンを使用する場合、特定のデザインの翼でのみ機能する特別なロールスロイスのボルトと取り付け点を使用する必要はありません。その後、プラットとホイットニーに切り替えようとすると、翼全体をゼロから再設計する必要があります(そのため、胴体の完全な再設計が必要になり、そのために別の座席を購入する必要があり、その結果、別の機内エンターテイメントシステムを購入する必要があります)これ...)。いくつかのリンケージが存在する可能性があります-注意せずにエンジンを交換することはできませんが、大規模なプロジェクトは一般に、そのようなことが最小限に抑えられている場合にうまく機能します。

大きなプロジェクトが小さなプロジェクトのクラスターによって実際に解決される限り、互いにきれいなインターフェースを持つ小さなソフトウェアプロジェクトのクラスターとして設計された大きなソフトウェアプロジェクトは、特に頻繁に失敗することはありません。(この点について間違える可能性があります。)


2

ソフトウェアシステムの構築は、物理構造の構築とは大きく異なります。つまり、実装は大きく異なります。たとえば、巨大なタンカーを構築している間、ロボットまたは手でパーツを一緒に溶接したり、すべてのナットとボルトを締めたり、塗装したり、すべてを持ち込んで装飾を行うなど、比較的単純な(しかし簡単ではありません!)機器や家具など。これはすべて、本当に簡単なことです。

ただし、ソフトウェアに関しては、はるかに複雑になります。たとえば、製品の一部を保存する安全なログインとユーザー資格情報をどのように正確に実装しますか?どのライブラリとツールを使用できますか?どのライブラリとツールを使い慣れていますか?ハッシュ関数とソルティング関数をどのように正確に記述し、それが安全であることどのように確認しますか?これは非常に多くの方法で行うことができるため、これらの種類の実際の実用的なデザインパターンを設定することは不可能です。はい、前述のデザインパターン「ベストプラクティス」として小規模に存在しますが、すべてのソフトウェアシステムは他のシステムとは大きく異なり、フィールドは非常に速いペースで進歩および変化するため、維持することは本質的に不可能です。

家を建てるとき、メインの支持壁が不適切で交換が必要であると気づくような問題に実際に遭遇することはありません。これまでの進捗を解体し、支持壁をやり直してベースから始める必要があります。設計段階でこのような問題に取り組むのは、建物に必要なサポートウォールの種類を予測するのが比較的簡単だからです。

ただし、ソフトウェアの場合はそうではありません。製品全体を単一のエンティティとして実際に設計してから実装することはできません。通常、ソフトウェア設計プロセスは反復的であり、目標と要件は製品の実装とテストに応じて変化します。ソフトウェア開発は全体として反復プロセスであり、通常は予想以上に物事が変化しますが、そのような変化は多くの場合、より多くの作業、複雑さ、そして残念ながら最終的にはより多くのお金、時間、ハードワークを必要とする課題を課します。

したがって、本質的に、大きなプロジェクトを提供し、プロジェクトのタイムラインとロードマップを見積もることが難しい理由は、ソフトウェア開発と特に実用的な設計が非常に複雑な分野だからです。複雑さが根本的な問題です。


+1、さらに考えを進めると、非現実的な期待、不合理な政策、そしてカフスなデザインにつながる業界外の人々によるその複雑さを理解することは失敗です。英国の公共部門はその好例です。たとえば、公共の建物の場合、経営陣は、芝を切る前に、専門家の意見、詳細な協議、および水密なプロジェクト計画を立てて、設計を完璧にしようとします。しかし、新しいITシステムの前で同じ人を入れて、あなたが要件に直前の変更、DBスキーマを参照してくださいよ、UIは...「?どのようにハードそれができることは、タイピングの少しだけだ」
ジュリア・ヘイワード

1

「大規模プロジェクト」の定義は歪んでいます。

技術的には、大規模なプロジェクトは期日通りに配信でき、何年にもわたって何度も何度も構築されてきたものであると認められています。

  • パックマンクローン。
  • 電卓
  • テキストエディター

きっとあなたは考えているに違いありません... "しかし、これらは小さなプロジェクトです!テキストエディタはシンプルです。" 私はあなたに同意しません。コンピューターはとてつもなく複雑です。オペレーティングシステムにユーザーをインストールして設定するだけでは困難な場合があり、OSの記述やハードウェアの構築さえしていません。

あなたが話しているプロジェクトは、宇宙探査に似た巨大なプロジェクトです。銀河間旅行を開発するのにどれくらい時間がかかるかをどのように知っていますか?どのモデルに基づいていますか?既知の既知、未知の未知、未知の未知、そして最後に未知の未知があり、これらはたまたまソフトウェア開発で登場します。

問題は期待のひとつだと思います。テクノロジーが存在するからといって、しばらく使用しても成功する(または使用するのが賢明)とは限りません。他の産業がソフトウェア産業と同じように振る舞うなら、10年の終わりまでにブラックホール駆動の掃除機を販売することになります。または、一部の「ビジョン」には月面基地を構築するためのリソースがあり、スターバックスは訪問者の体験を実際に「概算する」と判断します。私は問題がソフトウェア業界だとは思わないが、期待さている。


ブラックホール駆動の掃除機?機能安全はどうですか?
ピーターモーテンセン14年

機能安全の欠如?機能です!ブラックホールの掃除機で何かを掃除しようとするときは、不変の構造の使用を推奨します。
Droogans 14年

1

言及できるのはそれだけではありませんが、1つの基本的なことは指摘する価値があると思います。ほとんどの製品は、既存の動作に適合することを目的としています。急進的なブレークスルーの製品(自動車など)でさえ、一般に既存の動作に適合するように構築されており、それを少し簡単/簡単/安く/何でもできるようにします。はい、多くの場合、既存の行動にもいくつかの副作用があります(たとえば、馬の餌の代わりに車の燃料を得る)が、後者のほとんどはかなり軽度の副作用である傾向があります。

対照的に、ユーザーの行動を変えない(たとえば、仕事をかなり簡単にする)ほとんどすべてのソフトウェアは、基本的に1日目から完全に失敗することが保証されています。さらに悪いことに、大規模なソフトウェアプロジェクトは、個々のレベルでのユーザーの行動が含まれますが、大規模なグループ(多くの場合は組織全体)の行動が含まれます。

要するに、多くの場合、ソフトウェア自体の設計が仕事の最も簡単な部分です。難しいのは、彼らのために人々の仕事を再設計することです。それを始めるのは難しいです。うまく機能するだけでなく、受け入れられるような方法でそれを行うことは、依然としてはるかに困難です。


1

あなたが言及したように、エアバスA380は成功したプロジェクトではありませんでした。私はたまたまCAD / CAM会社で働いており、会社ごとに異なるバージョンのソフトウェアを使用していたため、それ(Airbusのプロジェクトもありました)が数年遅れたと言われました。つまり、世界のさまざまな部分でさまざまなパーツが設計されていました。そして、統合中に、彼らはすべての設計が統合されないことを知ったので、彼らは1つのバージョンでそれを再設計しなければなりません。それを見て、私はそれが成功したとは思わない。2〜3年前なら、エアバスのゲームチェンジャーだったでしょう。

また、堅牢なソフトウェアに関しては、飛行機、車(ABS、EPS、気候制御など)またはスペースシャトルを見ると、50%以上のソフトウェアが実行されており、非常に堅牢です。私たちがソフトウェアにもっと近づいているというだけで、さらに多くのソフトウェアプログラムがあるので、エラーが多くなっています。

訪問:http://www.globalprojectstrategy.com/lessons/case.php?id=23 とエアバスA380だったどのくらい成功ご覧ください。


1

ここでは、エンジニアリングのバックグラウンドを持つソフトウェアエンジニアと、建設業で働く妻がいます。私たちは仕事の違いについて長い議論を重ねてきました。

ソフトウェアエンジニアリングとは新しいものを設計することです。基本的なほとんどすべては、どこかのオープンソースライブラリで行われています。ソフトウェアエンジニアが雇用されるほとんどすべての仕事で、彼女は存在しないものを設計する必要があります。

建設やエンジニアリングのほとんどの形式のようなものでは、ソフトウェアの「ライブラリ」にあるものはすでに完全に設計されています。塔を建てたいですか?いくつかの変更を加えて、既存の構造から計画をコピーして貼り付けてください。

実際、私がエンジニアにならないことに決めた主な理由の1つは、既存の発明に対して10%の改善を設計するのにほとんどの時間を費やしていることです。 。

エンジニアリングには多くの新しいデザインはありません。非常に熟練したエンジニアとは、既存の設計を操作して新しいものを作成したり、改善したりできる人のことです。しかし、ほとんどすべてのプログラマーは、設計を変更したり、それらをハックしたり、新しいものを作成したりすることが期待されています。

アセンブリからC、C ++、Java、JavaScript、C#、PHPなどまで、標準がどれだけ完全に変わったかを振り返ってください。10年または20年前からリサイクルできるコードは多くありません。これは、自動車産業や航空産業では何十年も前から設計を改善し続けることができると言うのとはまったく異なります。

プロジェクトの管理はソフトウェアで難しいことで有名です。時間の見積もりは、作業を行う人々によって最もよく行わますが、見積もりの​​作成に忙しいときは、コードを書いていません。これにより、人々はプロジェクト管理を一切避けようとします。

多くの場合、多くのコードは特定の人に依存しており、これらの人が遅れたり実行できない場合、コードは先に進みません。対照的に、車を作りたい場合は、タイヤ、シャーシ、バッテリー、エンジンなどを組み立てるために、さまざまな人を単に雇うことができます。オブジェクト指向および既存のフレームワークによりこれが可能になりますが、すべてをゼロから設計する場合には実用的ではない場合があります。

失敗はソフトウェアで許可される場合があります。テストには費用がかかる場合があります。ソフトウェアでは、クラッシュを修正することができる場合、すべてのテストをスキップするのは非常に魅力的です。エンジニアリングのほとんどの形態では、「クラッシュ」は致命的です。

極端なプログラミング(実際にはソフトウェアメガプロジェクトで使用されていた)など、広範なテストを使用するプログラミング方法があります。しかし、締め切りが厳しくなっているため(意図的に厳しくすることができます)、プログラミングをすべてスキップしてバグを抱えて起動するのは魅力的です。「常にすべてのバグを修正する」というJoel Spolskyスタイルは、長い目で見ればより多くの時間を節約しますが、規律のない人はこれをスキップして失敗します。

小さなプロジェクトの方が良い。私の妻はかつて私に大企業で仕事をするように頼みました。大企業は悪い会社だという議論になりました...彼女にとって、大企業は多くのリソース、経験、機能的なプロジェクト管理、適切な手順を持っていました。私にとって、大企業とは恐竜であり、コードの修正、テスト、ドキュメントの作成にほとんどの時間を費やしています。

私は10人未満で100万ドルのITプロジェクトに取り組んできました。より多くの人々がプロジェクトを遅くし、不必要な官僚主義を加えていただろう。WhatsAppは、数十億ドルの価値がある「小さな」プロジェクトの例です。大規模なプロジェクトが不可能というわけではありませんが、ソフトウェアで何十億ドルもの価値を生み出すために何千人もの人々を必要としないのです。


0

他の質問で実際に取り上げられていない理由の1つは、ソフトウェアの分野がマテリアルベースの世界ではめったに発生しないスピードで革新することです。

その理由の1つは、ソフトウェア(プログラミング言語、ビルドツール、IDE)がソフトウェアのビルドに使用されるため、ソフトウェアの進化は正のフィードバックサイクルであることです。これは、リターンを加速するレイカーツワイルの法則の最も明らかな例であり、指数関数的に成長する速度で進歩を遂げます。あなたは1つのフレームワーク、プログラミング言語、通信プロトコルをマスターしたら、それはだ上で移動する時間の横に。

飛行機がソフトウェアのように構築された場合、他のすべてのモデルで材料を変更し、18か月ごとに能力と速度を2倍にし、新しいモデルごとにエンジンテクノロジーを発明したばかりのものに置き換え、水泳や地球外生物を検索する機能を追加します生活。

ああ、そして理想的には、音声コマンドを聞いて、完全に没入型の映画館、ペイントボールアリーナ、そして仕事の旅行が終わると暗い部屋のあるナイトクラブを兼ねます。同じこと!(AからBに確実に移動できる飛行機を製造した会社は、映画館、ペイントボール、ナイトクラブ機能を備えた飛行機が登場してから1年後には腹を立てました。)


あなたの主張がわかりません。まず、多くの言語はかなり古いです。Javaは20年以上前のものです。Pythonは30歳近くです。はい、新しい言語はありますが、私たち全員が2年ごとに新しい言語に移行するために言語を放棄するわけではありません。新しいフレームワーク、IDE、または言語を採用することは、チームにとって速度低下の要因になる可能性がありますが、使い慣れたツールを特に高速に使用するものも見つかりません。航空機産業ですか?ボーイング787のような飛行機には、実装が難しい新しいものがたくさんあります
Arseni Mourzenko

@ArseniMourzenkoまあ、Javaは登場後のWeb クライアントプログラミングや、swingが登場したときのGUI構築には熱かったが、両方の流行は数年しか続かなかった。ちなみに、1990年代以前にはWWWはありませんでした。Webプログラミングは、飛行機が1910年頃にあった場所です。しかし、このペースは継続しています。
ピーターA.シュナイダー

-1

私にとって、ソフトウェアエンジニアリングが直面する主な問題は、ユースケース、ユーザー、クロスプラットフォームです。

ユースケース

飛行機にはいくつのユースケースがありますか?そのほとんどは、ある場所から別の場所に飛ぶだけです。レーダー、交通管制などのようなものがあるかもしれませんが、ユースケースは明確であまり多くありません。ソフトウェアエンジニアリングでは、不明確な要件と、自分が望むものを知らないユーザーに直面しています。ユーザーごとに異なる設定/フローが必要ですが、ユーザーが望むように飛行機をカスタマイズできますか(テレビと冷蔵庫が欲しい!)?

ユーザー

誰が飛行機を操作しますか?パイロット、副操縦士、スチュワード(数えられる場合)およびタワーオペレーター。彼らはすべてプロであり、職務内容が明確です。ソフトウェアは、悪意のあるハッカーやクラッカーはもちろん、初心者やダミーによって使用されますが、他のモジュール(OpenIDGoogle AdSenseなど)と統合可能である必要があります。ミサイルや忍者強盗に耐えながらダミーで飛行機を操作できる場合、飛行機はソフトウェアと同じ品質であると言えます。

クロスプラットフォーム

飛行機は地球の空を飛ぶだけです。霧や風の強い気候、暑くて寒くて湿度の高い気候をどのように処理するのかはわかりませんが、飛行機は異なる重力レベルで飛行するようには設計されていません(火星に飛ぶことができれば驚かされます)。時々 、アプリケーションは、Internet Explorerの、などの異なるプラットフォーム、存続しなければならないGoogle ChromeのFirefoxのSafariのブラウザのために(すみませんオペラ OSレベルの場合)、またはWindows XP / 7月8日、またはLinuxを。モバイルデバイスと異なる解像度と向きは言うまでもありません。


-1

他の産業が問題なくプロジェクトを完了すると思う場合は、1977年に建設されたシティグループセンターの建物についてのストーリーをお読みください。7年近くの計画と建設の後でも、建物は深刻な設計欠陥で完成しました。 16年ごとに予想される暴風雨。

つまり、シティコープセンターが毎年立っていたため、16分の1の確率で崩壊する可能性がありました。

元のデザイナーは問題に気づいていませんでしたが、幸いなことに、それは建物を勉強している学生に捕まりました。

LeMessurierが言うように、彼は電話を受けました。LeMessurierによると、1978年に建築学部の学生が彼に、LeMessurierの建物についての大胆な主張で、シティコープセンターが風で吹き飛ぶ可能性があると連絡しました。

修理は文字通り夜間に行われ、設計上の欠陥の機密性を維持するために最少の人数で行われました。

建物を囲む半径10ブロックの緊急避難計画が準備されました。

ビルの居住者が仕事に戻ったように、彼らは夜通し溶接し、夜明けに終了しました。

物語は、作家ジョー・モーゲンシュテルンがパーティーで語られるのを耳にし、ルメスリエにインタビューするまで秘密のままでした。モルゲンシュテルンは、1995年にThe New Yorkerの物語を破りました。

疑問を提起します。プロジェクトのその他の致命的な設計上の欠陥が、公の承認なしに密かに修復または無視された件数。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.