ソフトウェア開発における制約
this によると
構築できるものの制約が物理システムの制約である他の種類のエンジニアリングの制約とは対照的に、大規模なソフトウェアシステムの構築に課される制約は、私たち自身の限界です。
これは紙の上で面白いように聞こえますが、それも私に考えさせられました。
- メモリの制約はどうですか？リークを防ぐためにメモリを管理する方法も考えるべきではないでしょうか。
- 再帰関数を呼び出す場合、TCOが不可能であればスタックのサイズを考慮すべきではないでしょうか？
上記の状況は、物理的な制約がビデオで話しているのと同じくらい難しいですか？
誰かがこれが何を意味するのか説明できますか？
はい、しかし、それは他の工学分野の物理的な制約のように制約の難しくはありません。
メモリ使用量、プロセッサ能力、ハードディスク容量、ネットワーク速度などが制約です。ただし、2つの考慮事項があります。まず、簡単に拡張できます。たとえば、リソースを追加したり、問題を複数のノードに分散したり、ハードウェアコンポーネントをアップグレードしたりできます。第2に、ソフトウェアは非常に簡単にコピーしてさまざまな異なる環境に配置できるため、異なる特性を持つ複数のプラットフォームに存在できます。これらのどちらも、多くの物理的な事柄には当てはまりません。
さらに、これらの制約を無視してコードを書くことができます。最終的には、より適切な環境に移動したり、ハードウェアが追いつくのを待ったりすると機能する可能性があります。たとえば、橋を最初に建設した場所では機能しなかったため、橋を渡って新しい川の交差点に移動することはできません。
whatsisname が another answer で指摘しているように、一部のソフトウェアエンジニアリングの取り組みには物理的な制約があります。物理的な世界に存在するものには、物理的な制約がある可能性があります。たとえば、多くの組み込みシステムや制御システムなどです。ただし、記述されたすべてのコードに関して、これはそれほど多くありません。
ソフトウェアエンジニアリングは、物理的な世界に根ざした他のエンジニアリング分野とは異なることに一般的に同意しますが、私たちには、心以外の制約があります。エンジニアリングプロジェクトに影響を与える プロジェクトの三角形 を超えて、私たちはしばしばレガシープロジェクトの改善に取り組み、さまざまな過去の決定に制約されています。
上記の状況は、物理的な制約がビデオで話しているのと同じくらい難しいですか？
それらは可能ですが、ほとんどの開発者やプロジェクトにとってはそうではありません。
一部のソフトウェアは、速度、メモリ、スペースなどに深刻な厳しい制限を課して書かれています。スペースシャトルガイダンスコンピューター用のソフトウェアを作成している場合、特定のタスクを実行する必要があり、実行する特定のハードウェアと、 「ビジネスロジック」は、物理方程式の操作のみで構成され、そのプロジェクトのソフトウェア開発者が直面する制約は、ロケットモーターのエンジニアと同じように物理的な制約に直面します。
一方、歯科医の予約をスケジュールするソフトウェアを作成している会社で働いている場合、ほとんどの場合、身体的な制約は完全になくなります。プログラムが使用しているスペースやメモリの量についてはほとんど何も考えることができず、大丈夫でしょう。日付と時刻は、多くのソフトウェア開発者にとって非常に悲惨な問題ですが、ほとんどの歯科医院は通常の営業時間中にしか開いていないため、日付をかなりずさんに扱い、何年もうまくいくことがあります。請求を結び付けて保険プロバイダーに接続するときは、宇宙の法則によって規定されていない制約を処理する必要があります。代わりに、あなたの制約は現実にはほとんど根拠がなく、代わりに、あいまいに関連する主題に関して、何十もの異なる時点で何十ものMBAの種類が良いアイデアであると考えられたものの理解できない不誠実な集まりです。これらはすべて、マネージャーの承認を得て、曲げたり上書きしたりできます。
ほんの一握りのソフトウェア開発者がスペースシャトルソフトウェアのようなものに取り組んでいます。大多数は、スケジューリングソフトウェアなどに取り組んでいます。スペースシャトルの規格に合わせて歯科医のソフトウェアを構築しようとすると、70年かかり、1兆ドルの費用がかかり、競合他社よりもはるかに優れているとは言えません。