By | April 9, 2022

ソフトウェアエンジニアリングの必要性を理解するには、コンピューティングの最近の歴史を振り返るのに少し立ち止まらなければなりません。 この歴史は、60年代後半から70年代前半に明らかになり始めた問題と、ソフトウェア工学の分野の創造につながった解決策を理解するのに役立ちます。 これらの問題は、問題の症状にちなんで名付けられた「ソフトウェア危機」と呼ばれることもありました。 この状況は「複雑さの障壁」とも呼ばれ、問題の主な原因にちなんで名付けられました。 過去形のソフトウェア危機について言及する人もいます。 危機はまだ終わっていませんが、ソフトウェアエンジニアリングというタイトルで現在含まれている多くの新しい技術の開発のおかげで、私たちは進歩を遂げてきました。

コンピューティングの初期の主な関心事は、ハードウェアの構築または取得でした。 ソフトウェアはほとんどそれ自体の面倒を見ることが期待されていました。 コンセンサスでは、「ハードウェア」は「変更が難しい」のに対し、「ソフトウェア」は「ソフト」または変更が容易であるとされていました。 によると、業界のほとんどの人は慎重にハードウェア開発を計画しましたが、ソフトウェアについてはかなり少ない予見をしていました。 ソフトウェアが機能しなかった場合、機能するまで変更するのは簡単だと彼らは信じていました。 その場合、なぜ計画する努力をするのですか?

ソフトウェアのコストはハードウェアのコストのごく一部であり、開発を管理することが非常に重要であるとは誰も考えていませんでした。 ただし、高価なハードウェアで時間を節約できるため、効率的で高速に実行されるプログラムを作成することの重要性を誰もが認識していました。 人の時間は機械の時間を節約するために想定されていました。 人々のプロセスを効率的にすることはほとんど優先されませんでした。

このアプローチは、ソフトウェアが単純だったコンピューティングの初期の頃には満足のいくものでした。 しかし、コンピューティングが成熟するにつれて、プログラムはより複雑になり、プロジェクトは大きくなりましたが、プログラムはその後、すべて同じ人によって日常的に指定、作成、操作、および保守されていたため、プログラムは他の人の期待に応えるためにプログラマーのチームによって開発され始めました。

個人の努力はチームの努力に取って代わった。 かつて一人の頭の中で行われていたコミュニケーションと調整は、多くの人の頭の間で行われなければならず、プロセス全体が非常に複雑になりました。 その結果、コミュニケーション、管理、計画、および文書化が重要になりました。

この例えを考えてみてください。大工は、計画の一般的な概念以上のものなしに、自分のために簡単な家を建てるために一人で働くかもしれません。 彼または彼女は、作業が進むにつれて、物事を解決したり、調整したりすることができました。 それが初期のプログラムが書かれた方法です。 しかし、家がより精巧である場合、またはそれが他の誰かのために建てられている場合、大工は家がどのように建てられるかをより慎重に計画する必要があります。 建設を開始する前に、将来の所有者と計画を確認する必要があります。 また、多くの大工が家を建てる場合は、ある大工が家の一部を建てるときに、別の大工が別の家の反対側を建てないように、作業を開始する前にプロジェクト全体を計画する必要があります。 大工がフレーミングを開始する前にセメント請負業者が地下壁を注ぐように、スケジューリングが重要な要素になります。 家がより複雑になり、より多くの人々の仕事を調整しなければならないので、青写真と管理計画が必要になります。

プログラムがより複雑になるにつれて、青写真(フローチャート)を作成するために使用された初期の方法は、このより大きな複雑さを表すのにもはや満足のいくものではありませんでした。 そのため、プログラムを作成する必要のある人が、他の人、つまりプログラマーに、求められていることを伝えることや、プログラマーが自分のしていることを互いに伝えることが難しくなりました。 実際、より良い表現方法がなければ、1人のプログラマーでさえ自分が何をしているかを追跡することは困難になりました。

プログラムの作成に必要な時間とそのコストは、すべての見積もりを上回り始めました。 システムのコストが見積もりの​​2倍以上になり、完了するまでに数週間、数か月、または数年かかることも珍しくありませんでした。 プログラムが当初の意図どおりに機能するようになる前にお金や時間がなくなったため、クライアントに引き渡されたシステムは頻繁に正しく機能しませんでした。 または、プログラムが非常に複雑だったため、問題を修正しようとするたびに、修正したよりも多くの問題が発生しました。 クライアントが最終的に彼らが得ているものを見たとき、彼らはしばしば彼らが欲しいものについて彼らの考えを変えました。 数億ドルの費用がかかる少なくとも1つの非常に大規模な軍事ソフトウェアシステムプロジェクトは、適切に機能させることができなかったために放棄されました。

プログラムの質も大きな関心事になりました。 コンピュータとそのプログラムが生命維持装置の監視などのより重要なタスクに使用されるにつれて、プログラムの品質は新しい意味を帯びてきました。 コンピューターへの依存度が高まり、多くの場合、コンピューターなしではうまくいかないため、コンピューターが正しく機能することがいかに重要であるかを発見しました。

複雑なプログラム内で変更を加えることは、非常に費用がかかることが判明しました。 多くの場合、プログラムにわずかに異なることを実行させることさえ非常に困難であったため、古いプログラムを破棄して最初からやり直す方が簡単でした。 もちろん、これにはコストがかかりました。 ソフトウェアエンジニアリングアプローチの進化の一部は、簡単な変更を簡単に行えるように、最初は十分に構築されたシステムを開発することを学ぶことでした。

同時に、ハードウェアはこれまでになく安価に成長していました。 チューブはトランジスタに置き換えられ、トランジスタは集積回路に置き換えられ、3000ドル未満のマイクロコンピュータが数百万ドルになるまで続きました。 変化の速さを示すものとして、特定の量のコンピューティングのコストは2年ごとに半分に減少します。 この再調整を考えると、ソフトウェアの開発にかかる時間とコストは、ハードウェアに比べてそれほど小さくなく、無視することができました。

ハードウェアのコストが急落するにつれて、ソフトウェアは賃金が上昇している人間によって書かれ続けました。 アセンブラ、コンパイラ、およびデータベース管理システムの使用によるソフトウェア開発の生産性向上による節約は、ハードウェアコストの節約ほど急速には進みませんでした。 実際、今日のソフトウェアのコストは無視できないだけでなく、ハードウェアのコストよりも大きくなっています。 非手続き型(第4世代)言語や人工知能(第5世代)の使用など、現在の開発の一部は、ソフトウェア開発の生産性を向上させる見込みを示していますが、その可能性はまだ見え始めたばかりです。

もう1つの問題は、過去のプログラムでは、プログラムが何をする必要があるかが完全に理解される前に行われることが多かったことです。 プログラムが作成されると、クライアントは不満を表明し始めました。 そして、クライアントが不満を持っている場合、最終的にはプロデューサーも不幸になります。 時が経つにつれて、ソフトウェア開発者は、始める前に彼らが意図したことを正確に紙と鉛筆でレイアウトすることを学びました。 次に、クライアントと一緒に計画を確認して、クライアントの期待に応えているかどうかを確認できます。 この紙と鉛筆のバージョンに変更を加える方が、システムの構築後に変更を加えるよりも簡単で安価です。 適切な計画を使用すると、プログラムの終了後に変更を加える必要が少なくなります。

残念ながら、数年前まで、今日開発されているシステムほど複雑なシステムを十分に説明するための優れた表現方法は存在しませんでした。 製品がどのように見えるかを示す唯一の良い表現は、完成品そのものでした。 開発者は、クライアントが計画していることを示すことができませんでした。 そして、クライアントは、ソフトウェアが最終的に構築されるまで、ソフトウェアが何であるかを確認できませんでした。 それから、変更するには費用がかかりすぎました。

繰り返しになりますが、建物の建設の例えを考えてみましょう。 建築家は間取り図を描くことができます。 クライアントは通常、アーキテクトが何を計画しているかをある程度理解し、それが適切かどうかについてフィードバックを返すことができます。 ほとんどの人は幾何学的なオブジェクトを表す図面に精通しているため、平面図は素人にとってかなり理解しやすいものです。 建築家とクライアントは、空間と幾何学に関する共通の概念を共有しています。 ただし、ソフトウェアエンジニアは、クライアントに対して、ロジックと情報処理を含むシステムを表す必要があります。 彼らはまだ共通の概念の言語を持っていないので、ソフトウェアエンジニアは彼らが通信する前にクライアントに新しい言語を教えなければなりません。

さらに、この言語は、すぐに習得できるように単純であることが重要です。