オブジェクト指向プログラミング
Simula 1962年 オブジェクトとクラスを導入した最初の言語。また、C++が再定義したオブジェクト指向プログラミング言語の要件を満たすことから、最初のオブジェクト指向プログラミング言語とされることもある。クラスベース。当初はシミュレーション記述用に開発されたものであったが、後に汎用化された。 Smalltalk 1972年 オブジェクト間の相互作用に<b data-parsoid='{"dsr":[7033,7044,3,3]}'>メッセージ</b>という機構を導入した最初の言語。オブジェクト指向と言う言葉は、Smalltalkのプログラミングスタイルを説明するために作られた。動的な型付けにより高い柔軟性を持つ。 C++ 1979年 C言語のオブジェクト指向拡張。Simula言語風にクラスを定義でき、C言語の型システムを強化している。当初はC言語に対して上位互換であった。また、強い型付けによりC言語譲りの実行効率の高いコードが生成できる。 Objective-C 1983年 C言語のオブジェクト指向拡張。C言語のコードとSmalltalk型のオブジェクトシステムを混在させたもの。オブジェクトシステム自体はCで書かれたランタイム。 Eiffel 1986年 強い型付けを行う型システムや表明など堅牢性を強く意識して設計されたオブジェクト指向プログラミング言語。C++にテンプレートが導入される前に総称型を導入していた。 Self 1987年 最初のインスタンスベースのオブジェクト指向プログラミング言語。 CLOS 1988年 関数型言語Common Lispのオブジェクト指向仕様。 Modula-3 1988年 モジュールを実現していたModula-2言語のオブジェクト指向拡張。 Python 1990年 最初のオブジェクト指向スクリプト言語。 Sather 1990年 Eiffelを拡張したもの。実行効率面での工夫が見られる。 NewtonScript 1993年 PDA環境用に修正されたSelf言語。PDAの性質を生かすため永続オブジェクトをサポートしている。 Ruby 1993年 オブジェクト指向スクリプト言語。クラスのMix-inなどのユニークな機能を持つほか、正規表現に渡るまで全てがクラスとして実装されていることが特徴。 Perl 1994年 Perl 5.0にてオブジェクト指向に対応。既存のPerl言語に後付けで拡張されたため記法は特殊だが、機能面では他のオブジェクト指向言語に引けを取らない。 Adaのオブジェクト指向拡張 1995年 恐らく最も仕様が複雑なオブジェクト指向プログラミング言語。 Java 1995年 仮想マシン（Java仮想マシン）上で動作することによる高い可搬性、リフレクションやスレッドの標準サポートと充実したライブラリ群で知られているオブジェクト指向プログラミング言語。 Object Pascal (Delphi) 1995年 Pascal言語のオブジェクト指向拡張。 JavaScript 1996年 ウェブページ上で実行することを主目的に開発されたスクリプト言語。プロトタイプベースの言語である。 OCaml 1996年 関数型言語MLのオブジェクト指向拡張。クラスが型推論機構に組み込まれているという特徴がある。 PHP 2000年 動的にWebページを生成することを主目的としたスクリプト言語。バージョン4からオブジェクト指向に対応し、バージョン5でアクセス権やインターフェースなど、オブジェクト指向の強化が行われている。 C# 2000年 Javaとよく似た作りでJavaと同じく仮想マシン上で動作するが様々な部分で拡張されている。.NET Framework上で動く。 Visual Basic.NET 2002年 既存のVisual Basic（6.0以前）を大きく改訂してオブジェクト指向に対応。C＃同様.NET Framework上で動く。 COBOL 2002年 2002年に制定された国際規格に、オブジェクト指向機能が採用された。1994年には、国際規格案を先取りした商用コンパイラ上で利用可能になった。オブジェクト指向構文を使わないCOBOLプログラムと混在できる。 Ceylon 2011年 Java をもとにつくられ、Java のもつ長所と短所を考慮しつつ、商用言語として再設計された言語。 Swift 2014年 Objective-Cのオブジェクトを引き継ぎながらも、ベースのC言語を取り除いて新しく再設計された言語。
ソフトウェアプロジェクト管理
ソフトウェアプロジェクト管理の歴史は、ソフトウェアの歴史と密に関係している。
1960年代に「再利用可能な解決方法」を実現するオブジェクト指向プログラミングの概念が知られ始めるより以前では、ソフトウェアは特定の用途の向けに開発され、また特定のコンピュータ向けに開発されていた。
特定用途のシステムは、コンポーネントに基づくソフトウェア工学のおかげで、他の用途に適合することができるようになった。
企業は、ソフトウェアプログラミングがハードウェアの電気回路の明細図よりも相対的に簡単であることを、すぐに理解するようになった。
そして、1970年代と1980年代にソフトウェア産業は急速に成長した。
ソフトウェアを新しく開発する作業を管理するために、企業は、有効性が証明されたプロジェクト管理手法群を、ソフトウェアプロジェクトに適用した。
しかしソフトウェアテストをする過程で、とりわけ、ユーザ仕様と出荷されたソフトウェアの間に広がるグレーゾーンに起因する混乱が発生したときに、プロジェクトのスケジュールを遅延させてしまうことが多かった。
こうした問題を回避するために、ウォーターフォールモデルとして知られるソフトウェアプロジェクト管理の手法群では、ユーザの要求仕様を出荷されるソフトウェア製品に対応づけることを、重点的に扱った。
ウォーターフォールモデルが採用されるようになってから、ソフトウェアプロジェクト管理の失敗が分析されることによって、以下のことが多くのソフトウェアプロジェクトに共通する失敗の原因として示された。上記のうち最初の3項目は、顧客のニーズを明瞭にすることが困難であることを示している。
特定のプロジェクト管理ツールは有用でありまた必須であることが多いが、ソフトウェアプロジェクト管理において真に有効な技法は、正しい手法 (方法論、メソドロジ) を適用しその手法を支援するツールを採用することである。
なんらかの手法が適用されないのであれば、ツールの採用は無価値である。
1960年代から、いくつかのプロプライエタリなソフトウェアプロジェクト管理手法群が、ソフトウェア開発企業によりその企業自身のために開発された。
同時期に、いくつかのコンピュータコンサルティング企業もまた、彼らの顧客のために似たような手法を開発した。
ソフトウェアプロジェクト管理手法群は、こんにちにおいても、発展途上である。
しかし現在の流行は、ウォーターフォールモデルから脱却し、ソフトウェアリリースライフサイクルを模倣した、より循環的なプロジェクトリリースモデルが牽引している。