Loading article…
ソフトウェア工学は、ソフトウェア開発に対する工学的なアプローチです。[1] [2] [3]ソフトウェアエンジニアと呼ばれる実務家は、工学設計プロセスを適用してソフトウェアを開発します。
プログラマーとコーダーという用語はソフトウェアエンジニアと重複しますが、これらは典型的なソフトウェアエンジニアの作業負荷の構築面のみを意味します。[4]
ソフトウェアエンジニアは、ソフトウェアシステムの定義、実装、テスト、管理、保守、開発プロセスの作成と変更を 含むソフトウェア開発プロセス[ 1] [5]を適用します。
歴史
1960 年代から、ソフトウェア エンジニアリングは独立したエンジニアリング分野として認識されるようになりました。
ソフトウェア エンジニアリングの開発は、苦労の連続でした。問題には、予算を超過したソフトウェア、期限を過ぎたソフトウェア、大規模なデバッグとメンテナンスが必要なソフトウェア、消費者のニーズを満たせなかったソフトウェア、あるいは完成すらしなかったソフトウェアなどがありました。
1968年、NATOはソフトウェアに関連する問題を議論する最初のソフトウェアエンジニアリング会議を開催しました。ソフトウェア開発のガイドラインとベストプラクティスが確立されました。[6]
ソフトウェア エンジニアリングという用語の起源は、さまざまな情報源に帰せられます。この用語は、1965 年 6 月号の「Computers and Automation」に掲載された企業が提供するサービスの一覧に登場し[7]、1966 年 8 月号のCommunications of the ACM (第 9 巻第 8 号) の Anthony A. Oettinger による「President's Letter to the ACM Membership」でより正式に使用されました。[8] [9]また、1968 年にFriedrich L. Bauer教授が NATO 会議のタイトルに使用したとも言われています。[10] Margaret Hamilton は、アポロ計画中に「ソフトウェア エンジニアリング」という分野について説明し、彼らの活動に正当性を与えました。[11]当時は「ソフトウェア危機」があると考えられていました。[12] [13] [14]第40回国際ソフトウェア工学会議（ICSE 2018）は、フレデリック・ブルックス[15]とマーガレット・ハミルトン[16]による基調講演で「ソフトウェア工学」の50周年を祝いました。
1984年、米国ペンシルベニア州ピッツバーグのカーネギーメロン大学キャンパスに本部を置く連邦政府資金による研究開発センターとしてソフトウェアエンジニアリング研究所（SEI）が設立されました。 [17]ワッツハンフリーは、ソフトウェアエンジニアリングプロセスの理解と管理を目的としたSEIソフトウェアプロセスプログラムを設立しました。[17]導入されたプロセス成熟度レベルは、開発のための能力成熟度モデル統合（CMMI-DEV）となり、米国政府がソフトウェア開発チームの能力を評価する方法を定義しました。
ソフトウェアエンジニアリングに関する最新の、一般的に受け入れられているベストプラクティスは、ISO/IEC JTC 1/SC 7小委員会によって収集され、ソフトウェアエンジニアリング知識体系（SWEBOK）として公開されています。 [5]ソフトウェアエンジニアリングは、主要なコンピューティング分野の1つと考えられています。[18]
用語
意味
ソフトウェア エンジニアリングの注目すべき定義は次のとおりです。
- 「科学的および技術的な知識、方法、経験をソフトウェアの設計、実装、テスト、および文書化に体系的に適用すること。」—労働統計局—IEEEシステム およびソフトウェアエンジニアリング–語彙[19]
- 「ソフトウェアの開発、運用、保守に体系的かつ規律ある定量化可能なアプローチを適用すること。」— IEEE 標準ソフトウェアエンジニアリング用語集[20]
- 「ソフトウェア制作のあらゆる側面に関わるエンジニアリング分野」—イアン・サマービル[21]
- 「信頼性が高く、実際のマシン上で効率的に動作するソフトウェアを経済的に得るために、健全なエンジニアリング原則を確立し、使用する。」—フリッツ・バウアー[22]
- 「複雑なコンピュータプログラムの設計、実装、保守を扱うコンピュータサイエンスの分野。」—メリアム・ウェブスター[23]
- 「『ソフトウェア エンジニアリング』には、コードを書くという行為だけでなく、組織が長期にわたってそのコードを構築し維持するために使用するすべてのツールとプロセスが含まれます。[...] ソフトウェア エンジニアリングは、『時間をかけて統合されたプログラミング』と考えることができます。」 — Googleのソフトウェア エンジニアリング[24]
この用語は、より非公式な意味でも使用されています。
- かつてはコンピュータプログラミングやシステム分析と呼ばれていた幅広い活動を指す非公式な現代用語として[25]
- コンピュータプログラミングの実践のあらゆる側面を表す広義の用語であり、コンピュータサイエンスのサブ分野として正式に研究されているコンピュータプログラミングの理論とは対照的である[26]
- コンピュータプログラミングに対する特定のアプローチの提唱を体現する用語として、コンピュータプログラミングを芸術や工芸ではなく工学分野として扱うことを推奨し、推奨されるプラクティスの体系化を提唱する用語として[27]
語源
マーガレット ハミルトンは、アポロ計画に携わっていたときに「ソフトウェア エンジニアリング」という用語を広めました。「エンジニアリング」という用語は、この作業が技術の進歩に向けた他の貢献と同様に真剣に受け止められるべきであることを認めるために使用されました。ハミルトンは、この用語の使用について詳しく述べています。
私がこの用語を初めて思いついたとき、少なくとも私たちの世界では、誰もその言葉を聞いたことがありませんでした。それは長い間、ジョークとして語り継がれていました。彼らは私の過激なアイデアについてからかうのが好きでした。最も尊敬されているハードウェアの第一人者の一人が、ソフトウェアを構築するプロセスもハードウェアと同様にエンジニアリングの分野として考えるべきだという私の意見に同意すると会議の全員に説明した日は、忘れられない日でした。彼が新しい「用語」そのものを受け入れたからではなく、私たちが彼と部屋にいた他の人たちに、それ自体がエンジニアリング分野であると認めてもらったからです。[28]
適合性
ソフトウェアエンジニアリングをどのように定義するか、あるいはエンジニアリング分野としての正当性について、個々の評論家の間では意見が激しく対立している。デイビッド・パルナスは、ソフトウェアエンジニアリングは実際にはエンジニアリングの一形態であると述べた。[29] [30] スティーブ・マコーネルは、そうではないが、そうあるべきだと述べた。[31] ドナルド・クヌースは、プログラミングは芸術であり科学であると述べた。[32] エドガー・W・ダイクストラは、ソフトウェアエンジニアリングとソフトウェアエンジニアという用語は米国で誤用されていると主張した。[33]
作業負荷
要件分析
要件エンジニアリングは、ソフトウェアの要件の抽出、分析、仕様化、検証に関するものです。ソフトウェア要件は、機能要件、非機能要件、またはドメイン要件のいずれかになります。
機能要件は、期待される動作（つまり出力）を記述します。非機能要件は、移植性、セキュリティ、保守性、信頼性、スケーラビリティ、パフォーマンス、再利用性、柔軟性などの問題を指定します。これらは、インターフェイス制約、パフォーマンス制約（応答時間、セキュリティ、ストレージスペースなど）、操作制約、ライフサイクル制約（保守性、移植性など）、経済的制約に分類されます。非機能要件を指定するには、システムまたはソフトウェアの動作方法に関する知識が必要です。ドメイン要件は、プロジェクトの特定のカテゴリまたはドメインの特性に関係しています。[34]
デザイン
ソフトウェア設計とは、ソフトウェアの高レベルの計画を立てるプロセスです。設計は、次のレベルに分けられることがあります。
- インターフェース設計では、システムとその環境間の相互作用と、システムの内部動作を計画します。
- アーキテクチャ設計では、システムの主要コンポーネントの役割、特性、およびコンポーネント間のインターフェースなどを計画します。
- 詳細設計では、プロパティ、関係性、アルゴリズム、データ構造などの内部要素を計画します。[35]
工事
ソフトウェア構築には通常、プログラミング（コーディング）、単体テスト、統合テスト、デバッグなどが行われ、設計を実装します。[1] [5]「ソフトウェアテストはデバッグと関連していますが、異なります。」[5] このフェーズでのテストは、通常、プログラマーによって実行され、コードが設計どおりに動作することを確認し、コードが次のレベルのテストの準備が整っているかどうかを確認することを目的としています。[要出典]
テスト
ソフトウェアテストは、テスト対象のソフトウェアの品質に関する情報を利害関係者に提供するために実施される経験的かつ技術的な調査です。[1] [5]
構築とは別に説明される場合、テストは通常、それを書いたプログラマーではなく、テスト エンジニアまたは品質保証によって実行されます。テストはシステム レベルで実行され、ソフトウェア品質の一側面と見なされます。
プログラム分析
プログラム分析とは、パフォーマンス、堅牢性、セキュリティなどの側面に関してコンピュータ プログラムを分析するプロセスです。
メンテナンス
ソフトウェアメンテナンスとは、リリース後のソフトウェアのサポートを指します。これには、エラー修正、最適化、未使用機能や廃棄機能の削除、既存機能の強化などが含まれますが、これらに限定されません。[1] [5]
通常、メンテナンスはプロジェクトコストの40％から80％を占めます。[36]
教育
コンピュータプログラミングの知識は、ソフトウェアエンジニアになるための前提条件です。2004年にIEEEコンピュータ協会はSWEBOKを作成しました。これはISO/IEC技術レポート1979:2005として公開されており、4年間の経験を持つ大学院のソフトウェアエンジニアが習得することを推奨する知識体系を説明しています。[37] 多くのソフトウェアエンジニアは、大学の学位を取得するか、専門学校でトレーニングを受けてこの職業に就きます。学部レベルのソフトウェアエンジニアリングの学位のための1つの標準的な国際カリキュラムは、IEEEコンピュータ協会と計算機協会のコンピューティングカリキュラムに関する合同タスクフォースによって定義され、2014年に更新されました。[18]多くの大学がソフトウェアエンジニアリングの学位プログラムを提供しており、2010年の時点で[update]、米国には244のキャンパスソフトウェアエンジニアリング学士プログラム、70のオンラインプログラム、230の修士レベルプログラム、41の博士レベルプログラム、69の証明書レベルプログラムがありました。
大学教育に加えて、多くの企業が情報技術分野でのキャリアを目指す学生のためにインターンシップを後援しています。これらのインターンシップでは、典型的なソフトウェア エンジニアが毎日直面する実際のタスクを学生に紹介することができます。ソフトウェア エンジニアリングの兵役を通じて同様の経験を得ることができます。
ソフトウェアエンジニアリングの学位プログラム
今日、すべての実務者の半数は、コンピュータサイエンス、情報システム、または情報技術の学位を取得しています。[要出典]ソフトウェアエンジニアリングの学位を持つ実務者の数は少数ですが、増加しています。1987年、インペリアルカレッジロンドンのコンピューティング学部は、世界初の3年間のソフトウェアエンジニアリング学士号プログラムを導入しました。翌年、シェフィールド大学が同様のプログラムを設立しました。[38] 1996年、ロチェスター工科大学は、米国で最初のソフトウェアエンジニアリング学士号プログラムを設立しましたが、 2003年までABET認定を取得しませんでした。この年、ライス大学、クラークソン大学、ミルウォーキー工科大学、ミシシッピ州立大学と同じ年でした。[39] 1997年、インドのコインバトールにあるPSGカレッジオブテクノロジーは、ソフトウェアエンジニアリングの5年間の統合理学修士号を初めて開始しました。[要出典]
それ以来、多くの大学でソフトウェア エンジニアリングの学士課程が設けられてきました。学部レベルのソフトウェア エンジニアリングの標準国際カリキュラムである SE2004 は、2001 年から 2004 年にかけて、Association for Computing Machinery および IEEE Computer Society の資金提供を受けて運営委員会によって定義されました。2004年現在、米国[update]の約 50 の大学が、コンピュータ サイエンスとエンジニアリングの原理と実践の両方を教えるソフトウェア エンジニアリングの学位を提供しています。最初のソフトウェア エンジニアリングの修士課程は、1979 年にシアトル大学で設けられました。それ以来、大学院レベルのソフトウェア エンジニアリングの学位は、さらに多くの大学で取得できるようになりました。同様にカナダでは、カナダ専門技術者協会の Canadian Engineering Accreditation Board (CEAB) が、いくつかのソフトウェア エンジニアリング プログラムを承認しています。
1998年、米国海軍大学院（NPS）は、世界で初めてソフトウェア工学の博士課程を設立しました。 [要出典]さらに、カリフォルニア州立大学フラートン校のコンピュータサイエンスおよびエンジニアリング学部が提供するソフトウェア工学の理学修士（MSE）学位など、ソフトウェア工学のオンライン上級学位が多数登場しています。スティーブ・マッコーネルは、ほとんどの大学がソフトウェア工学ではなくコンピュータサイエンスを教えているため、真のソフトウェアエンジニアが不足していると考えています。[40] ETS（École de technologie supérieure）大学とUQAM（Université du Québec à Montréal）は、IEEEによってソフトウェアエンジニアリング知識体系（SWEBOK）の開発を義務付けられました。これは、ソフトウェアエンジニアがカバーする知識体系を説明するISO標準となっています。[5]
職業
プロフェッショナル ソフトウェア エンジニアのライセンスや資格認定に関する法的要件は、世界各国で異なります。英国では、ソフトウェア エンジニアという職名を取得または使用するためのライセンスや法的要件はありません。カナダのアルバータ州、ブリティッシュ コロンビア州、オンタリオ州、[41]、ケベック州などの一部の地域では、ソフトウェア エンジニアはプロフェッショナル エンジニア (P.Eng) の資格や情報システム プロフェッショナル (ISP) の資格を取得できます。欧州では、ソフトウェア エンジニアは欧州エンジニア(EUR ING) の専門職称号を取得できます。ソフトウェア エンジニアは、英国コンピュータ協会を通じて公認エンジニアとして専門資格を取得することもできます。
米国では、NCEESが2013年にソフトウェアエンジニアリングのプロフェッショナルエンジニア試験を開始し、ソフトウェアエンジニアのライセンス取得と認定を可能にしました。 [42] NCEESは、参加者不足のため、2019年4月以降試験を終了しました。[43]強制ライセンスについては、現在も依然として議論が続いており、物議を醸していると考えられています。[44] [45]
IEEE Computer SocietyとACMは、米国を拠点とするソフトウェアエンジニアリングの2大専門組織であり、ソフトウェアエンジニアリングの専門職向けのガイドを発行しています。IEEEの「ソフトウェアエンジニアリング知識体系ガイド – 2004年版」（SWEBOK）は、この分野を定義し、IEEEが実務に携わるソフトウェアエンジニアに期待する知識について説明しています。最新のSWEBOK v3は更新版であり、2014年にリリースされました。[5] IEEEは「ソフトウェアエンジニアリング倫理規定」も公布しています。[46]
雇用
2022年現在、世界には2,690万人のプロのソフトウェアエンジニアがいると推定されており、2016年の2,100万人から増加しています。[47] [48]
多くのソフトウェア エンジニアは、従業員または契約社員として働いています。ソフトウェア エンジニアは、企業、政府機関 (民間または軍事)、非営利団体と協力して働いています。ソフトウェア エンジニアの中には、フリーランスとして働く人もいます。組織によっては、ソフトウェア開発プロセスの各タスクを実行するスペシャリストを抱えているところもあります。また、ソフトウェア エンジニアにそれらの多くまたはすべてを実行することを求める組織もあります。大規模なプロジェクトでは、1 つの役割のみに特化する場合があります。小規模なプロジェクトでは、複数の役割またはすべての役割を同時に担う場合があります。多くの企業が、夏休みや外部研修中に大学生などのインターンを雇用しています。専門分野には、アナリスト、アーキテクト、開発者、テスター、テクニカル サポート、ミドルウェア アナリスト、プロジェクト マネージャー、ソフトウェア プロダクト マネージャー、教育者、研究者などがあります。
ソフトウェアエンジニアやプログラマーのほとんどは週40時間働いていますが、2008年にはソフトウェアエンジニアの約15％とプログラマーの11％が週50時間以上働いていました。[49]これらの職業で潜在的な傷害が発生する可能性があるのは、長時間コンピュータ端末の前に座ってキーボードを打つ他の労働者と同様に、エンジニアやプログラマーは眼精疲労、背中の痛み、血栓症、肥満、手根管症候群などの手や手首の問題にかかりやすいためです。[50]
アメリカ合衆国
米国労働統計局（ BLS）は、2018年に米国で1,365,500人のソフトウェア開発者が仕事をしていると数えた。 [51]研究分野としては比較的新しいため、ソフトウェアエンジニアリングの正式な教育はコンピュータサイエンスのカリキュラムの一部として教えられることが多く、多くのソフトウェアエンジニアがコンピュータサイエンスの学位を取得している。[52] BLSは、2023年から2033年にかけてコンピュータソフトウェアエンジニアリングが17％増加すると予測している。[53]これは、2022年から2032年のBLSのソフトウェアエンジニアリングの予測25％から減少している。[53] [54]そして、2010年から2020年のBLSの予測30％からもさらに減少している。[55]この傾向により、米国のコンピュータソフトウェアエンジニアに割り当てられていた仕事が、代わりにインドなどの国や他の外国のコンピュータソフトウェアエンジニアにアウトソーシングされるため、雇用の伸びは過去10年間ほど速くない可能性がある。[56] [49]さらに、米国労働統計局（BLS）職業展望のコンピュータプログラマーのBLS雇用見通しでは、2016年から2026年にかけて-7％の減少、2019年から2029年にかけてさらに-9％の減少、2021年から2031年にかけて-10％の減少を予測しています。[56]そして、2022年から2032年にかけて-11％の減少が予測されています。 [56]コンピュータプログラミングは世界中のどこからでも行うことができるため、企業は賃金の低い国でプログラマーを雇うことがあります。[56] [57] [58]さらに、多くのソフトウェア分野では、他のエンジニアリング分野と比較して女性の割合が長年にわたって減少しています。[59]さらに、最近の人工知能の進歩が将来の世代のソフトウェアエンジニアの需要に影響を与える可能性があるという懸念もあります。 [60] [61] [62] [63] [64] [65] [66]しかし、今後数十年の間に、米国市場の現在のソフトウェアエンジニアの多くが職業から逃げ出したり、年齢を重ねて市場から去ったりするため、この傾向は将来的に変化したり鈍化したりする可能性があります。[56]
認証
ソフトウェアエンジニアリング協会は、セキュリティ、プロセス改善、ソフトウェアアーキテクチャなどの特定のトピックに関する認定を提供しています。[67] IBM、Microsoftなどの企業も独自の認定試験を後援しています。多くのIT 認定プログラムは特定のテクノロジーを対象としており、これらのテクノロジーのベンダーによって管理されています。[68]これらの認定プログラムは、これらのテクノロジーを使用する人々を雇用する機関に合わせて調整されています。
一般的なソフトウェアエンジニアリングスキルのより広範な認定は、さまざまな専門団体を通じて受けることができます。2006年現在[update]、IEEEは575人以上のソフトウェア専門家を認定ソフトウェア開発専門家（CSDP）として認定しました。[69] 2008年には、認定ソフトウェア開発アソシエイト（CSDA）として知られるエントリーレベルの認定を追加しました。[70] ACMは1980年代初頭に専門家認定プログラムを持っていましたが、[引用が必要]関心が低かったため中止されました。ACMとIEEEコンピュータ協会は1990年代に共同でソフトウェアエンジニアをプロフェッショナルエンジニアとしてライセンスする可能性を検討しましたが、最終的にそのようなライセンスはソフトウェアエンジニアリングの専門的な産業実務には不適切であると判断しました。[44 ]ジョン・C・ナイトとナンシー・G・レベソンは2002年にライセンス問題についてよりバランスのとれた分析を発表しました。[45]
英国では、英国コンピュータ協会が、Chartered IT Professional (CITP)という法的に認められた専門資格を開発しており、資格認定を受けた会員 ( MBCS ) が利用できる。ソフトウェアエンジニアは、英国コンピュータ協会または工学技術協会の会員になる資格があり、いずれかの機関を通じてChartered Engineerの資格を取得できる。カナダでは、カナダ情報処理協会が、Information Systems Professional (ISP)という法的に認められた専門資格を開発している。[71]カナダのオンタリオ州では、カナダ工学認定委員会 (CEAB)認定プログラムを卒業し、PEO ( Professional Engineers Ontario )の Professional Practice Examination (PPE) に合格し、少なくとも 48 か月の許容されるエンジニアリング経験を持つソフトウェアエンジニアは、 Professional Engineers Ontarioを通じてライセンスを受ける資格があり、Professional Engineers P.Eng. になることができる。[72]ただし、PEO はオンライン教育や遠隔教育を一切認めておらず、コンピュータサイエンスのプログラムとソフトウェアエンジニアリングのプログラムの間には大きな重複があるにもかかわらず、それらを同等とは見なしていない。これが論争と資格争いを引き起こした。また、この職業における P.Eng 保有者の数も非常に少ないままです。この分野で働く専門家の大多数は、SE ではなく CS の学位を持っています。SE 以外の学位保有者にとって認定の道は難しいため、ほとんどの人はライセンス取得にこだわることはありません。
グローバリゼーションの影響
アウトソーシングの初期の影響と、発展途上国の第三世界における国際的な人材のコストが比較的低いことから、ソフトウェア開発活動は北米やヨーロッパの企業からインド、その後は中国、ロシアなどの発展途上国に大規模に移行した。このアプローチにはいくつかの欠陥があり、主に距離やタイムゾーンの違いにより、顧客と開発者の人間的なやり取りが妨げられ、大規模な転職が行われた。これはソフトウェアエンジニアリングの専門職の多くの側面に悪影響を及ぼした。たとえば、先進国の学生の中には、オフショアアウトソーシング（他国からソフトウェア製品やサービスを輸入すること）や外国人ビザ労働者に職を奪われることを恐れて、ソフトウェアエンジニアリング関連の教育を避ける人もいる。[73]統計では、現在ソフトウェアエンジニアリング自体への脅威は示されていないが、関連する職業であるコンピュータプログラミングは影響を受けているようだ。[74]それでも、フォローザサンワークフローを介してオフショアおよびニアショアのリソースを賢く活用する能力により、多くの組織の全体的な運用能力が向上した。[75]北米人が仕事を終えるとき、アジア人はちょうど仕事に戻ってくる。アジア人が仕事を終えるとき、ヨーロッパ人は仕事に戻ってくる。これにより、残業手当を支払ったり、重要な人的資源である睡眠パターンを乱したりすることなく、ビジネスに不可欠なプロセスを 24 時間体制で継続的に人間が監視できるようになります。
グローバル アウトソーシングにはいくつかの利点があるが、グローバルな (そして一般的に分散した) 開発は、開発者間の距離から生じる深刻な問題に直面する可能性がある。これは、この種の距離の主要な要素として、地理的、時間的、文化的、コミュニケーション (場所によって異なる言語や英語の方言が使用されることを含む) が特定されているためである。[76]過去 15 年間にわたってグローバル ソフトウェア開発の分野で研究が行われており、この複雑な活動に関連する利点と問題を強調した膨大な関連研究が発表されている。ソフトウェア エンジニアリングの他の側面と同様に、この分野と関連分野でも研究が進行中である。
賞品
ソフトウェア エンジニアリングの分野にはさまざまな賞があります。
- ACM-AAAI Allen Newell 賞- 米国。コンピュータ サイエンスの幅広い分野、またはコンピュータ サイエンスと他の分野をつなぐキャリア貢献に対して授与されます。
- BCS ラブレス メダル。コンピューティングの理解や発展に顕著な貢献をした個人に授与されます。
- ACM SIGSOFT優秀研究賞は、「ソフトウェア工学の理論や実践に重要かつ永続的な 研究貢献」をした個人に贈られます。[77]
- その他のACM SIGSOFT賞。[78]
- Codie賞は、ソフトウェア業界における優れたソフトウェア開発に対してソフトウェア情報産業協会が毎年授与する賞です。
- 「ソフトウェア エンジニアリングに重点を置いた情報科学の理論と実践への貢献」に対してHarlan Mills 賞が授与されました。
- ICSE最も影響力のある論文賞。[79]
- Jolt Awardもソフトウェア業界向けです。
- ウェイン・スティーブンスを記念して贈られるスティーブンス賞。
批判
工学知識を広め、分野を成熟させるためのメカニズムとして、ライセンス、認証、体系化された知識体系を求める人もいます。[80]
ソフトウェア工学の概念は非常に新しいため、ほとんど理解されておらず、ソフトウェア工学の教科書、論文、プログラマーや職人のコミュニティなどでも広く誤解されていると主張する人もいます。[81]
ソフトウェアエンジニアリングの根本的な問題は、そのアプローチが十分に実証的ではないということだと主張する人もいる。なぜなら、アプローチの現実世界での検証が通常は存在しないか、非常に限られているため、ソフトウェアエンジニアリングは「理論的な環境」でのみ実行可能であると誤解されることが多いからだ。[81]
今日のソフトウェア開発における多くの概念の創始者であるエドガー・ダイクストラは、2002 年に亡くなるまで「ソフトウェア エンジニアリング」という概念を拒否し、それらの用語は彼が「コンピュータ サイエンスの根本的な新しさ」と呼ぶものに対して不適切な類推であると主張しました。
これらの現象の多くは「ソフトウェア エンジニアリング」という名前でまとめられています。経済学が「悲惨な科学」として知られているように、ソフトウェア エンジニアリングは「破滅の運命にある学問」として知られているべきです。その目標が自己矛盾しているため、目標に近づくことすらできないため、破滅の運命にある学問です。もちろん、ソフトウェア エンジニアリングは別の価値ある大義として自らを売り込んでいますが、それは見せかけにすぎません。その文献を注意深く読み、その信奉者が実際に何をしているかを分析すると、ソフトウェア エンジニアリングが「できないときにプログラムする方法」をその憲章として受け入れていることに気付くでしょう。[82]
参照
ウィキメディア・コモンズには、ソフトウェアエンジニアに関連するメディアがあります。
勉強と実践
役割
専門的な側面
- 情報技術学士
- ソフトウェア工学学士
- ソフトウェアエンジニアリングカンファレンスのリスト
- コンピュータサイエンスジャーナル（ソフトウェアエンジニアリングジャーナルを含む）のリスト
- ソフトウェアエンジニアリング研究所
参考文献
引用
- ^ abcde アブラン他 2004
- ^ ACM (2007). 「コンピューティングの学位とキャリア」 ACM . 2010年11月23日閲覧。
- ^ Laplante, Phillip (2007). ソフトウェアエンジニアリングについてエンジニアが知っておくべきこと。ボカラトン: CRC。ISBN 978-0-8493-7228-5. 2011年1月21日閲覧。
- ^ Bogost, Ian (2015 年 11 月 5 日). 「プログラマーの皆さん、エンジニアと呼ぶのはやめましょう」. The Atlantic .
- ^ abcdefgh Bourque, Pierre; Fairley, Richard E. (Dick) 編 (2014). ソフトウェアエンジニアリング知識体系バージョン 3.0 (SWEBOK) ガイド。IEEEコンピュータ協会。
- ^ 「コーディングとソフトウェアエンジニアリングの歴史」www.hackreactor.com . 2021年5月6日閲覧。
- ^ 「コンピュータとオートメーション：コンピュータディレクトリとバイヤーズガイド、1965」（PDF）。bitsavers.org 。 2023年7月15日閲覧。
- ^ Oettinger, AG (1966). 「ACM会員への会長の手紙」. Commun. ACM . 9 (8). Association for Computing Machinery: 545–546. doi : 10.1145/365758.3291288 . ISSN 0001-0782. S2CID 53432801.
- ^ 「ソフトウェアエンジニアリングの起源」。2013年4月4日。 2017年11月17日閲覧。
- ^ Randall, Brian. 「1968/69 NATOソフトウェアエンジニアリングレポート」 。 2017年11月17日閲覧。
- ^ Lori Cameron (2008 年 10 月 5 日)。「マーガレット・ハミルトン: 最初のソフトウェア エンジニア」。技術ニュース。IEEEコンピューター協会。
- ^ Ian Sommerville (2015年3月24日).ソフトウェアエンジニアリング(第10版). ピアソン教育株式会社. ISBN 978-0-13-394303-0。
- ^ Peter, Naur; Randell, Brian (1968 年 10 月 7 ～ 11 日)。ソフトウェア エンジニアリング: NATO 科学委員会主催の会議レポート(PDF)。ドイツ、ガルミッシュ: NATO 科学業務部。2008年 12 月 26 日閲覧。
- ^ Randell, Brian (2001 年 8 月 10 日)。「1968/69 NATO ソフトウェア エンジニアリング レポート」。Brian Randell の大学ホームページ。ニューキャッスル大学コンピューター サイエンス学部。2008年 10 月 11 日閲覧。
最初の NATO ソフトウェア エンジニアリング カンファレンスのアイデア、特に当時ほとんど知られていなかった「ソフトウェア エンジニアリング」という用語を (意図的に挑発的な) タイトルとして採用するというアイデアは、
Fritz Bauer
教授が最初に考案したものだと私は考えています。
- ^ 2018年国際ソフトウェアエンジニアリング会議は、創立40周年とソフトウェアエンジニアリング50周年を記念しています（2018年5月31日）。「ICSE 2018 – 全体会議 – Fred Brooks」。YouTube 。 2018年8月9日閲覧。
{{cite web}}: CS1 maint: numeric names: authors list (link) - ^ 2018年国際ソフトウェアエンジニアリング会議は、創立40周年とソフトウェアエンジニアリング50周年を記念しています（2018年5月31日）。「ICSE 2018 – 全体会議 – マーガレット・ハミルトン」。YouTube 。 2018年8月9日閲覧。
{{cite web}}: CS1 maint: numeric names: authors list (link) - ^ ab Linda Hutz Pesante (2003 年 1 月 1 日)。Anthony Ralston、Edwin D. Reilly (編)。「ソフトウェア エンジニアリング インスティテュート (SEI)」。Encyclopedia of Computer Science。英国ウェスト サセックス州チチェスター: John Wiley and Sons Ltd .: 1611–1613。ISBN 978-0-470-86412-8
（1）この研究所は、ソフトウェアエンジニアリングの実践状況を改善するために、1984年12月に米国国防総省（DoD）からカーネギーメロン大学に競争入札で委託されました
。...（
2
）
SEIは、実証済みの価値を持つ成熟したソリューションを広く普及させます。例としては、
能力成熟度モデル
（CMM）などがあります...
- ^ ab Joint Task Force on Computing Curricula、IEEE Computer Society、Association for Computing Machinery (2015 年 2 月 23 日)。ソフトウェア エンジニアリング 2014: ソフトウェア エンジニアリングの学部課程向けカリキュラム ガイドライン(PDF)。コンピューティング カリキュラム シリーズの 1 巻。IEEE Computer SocietyおよびAssociation for Computing Machinery。
{{cite book}}: CS1 maint: multiple names: authors list (link) - ^ システムおよびソフトウェアエンジニアリング - 語彙、ISO / IEC / IEEE std 24765:2010(E)、2010年。
- ^ IEEE 標準ソフトウェアエンジニアリング用語集、IEEE std 610.12-1990、1990 年。
- ^ サマービル、イアン(2007) [1982]。「1.1.2 ソフトウェアエンジニアリングとは何か?」ソフトウェアエンジニアリング(第 8 版)。ハーロー、イギリス: ピアソン エデュケーション。p. 7。ISBN 978-0-321-31379-9ソフトウェア エンジニアリングは
、システム仕様の初期段階から使用開始後のシステムの保守まで、ソフトウェア作成のあらゆる側面を扱うエンジニアリング分野です。 この定義には、2 つのキー フレーズがあります。
1.エンジニアリング分野エンジニアは、物事を機能させます。適切な場合は、理論、方法、ツールを適用します [...] エンジニアは、組織的および財務的な制約に従って作業する必要があることも認識しています [...]
2.ソフトウェア作成のあらゆる側面ソフトウェア エンジニアリングは、ソフトウェア開発の技術的なプロセスだけでなく、ソフトウェア プロジェクト管理などのアクティビティや、ソフトウェア作成をサポートするツール、方法、理論の開発にも関係しています。 - ^ 「ソフトウェアエンジニアリング」。情報処理。71 : 530–538。
- ^ 「ソフトウェアエンジニアリングの定義」www.merriam-webster.com . 2019年11月25日閲覧。
- ^ ウィンターズ、タイタス、マンシュレック、トム、ライト、ハイラム (2020)。「序文、時間を超えたプログラミング」。Googleのソフトウェア エンジニアリング。O'Reilly Media, Inc. pp. xix–xx, 6–7。ISBN 978-1-492-08279-8私たちは、
「ソフトウェア エンジニアリング」には、コードを書くという行為だけでなく、組織が長期にわたってそのコードを構築および維持するために使用するすべてのツールとプロセスが含まれると考えています。ソフトウェア組織は、コードを長期にわたって価値あるものに保つためにどのような方法を導入できるでしょうか。エンジニアは、コードベースをより持続可能にし、ソフトウェア エンジニアリングの分野自体をより厳格にするにはどうすればよいでしょうか。
- ^ Akram I. Salah (2002-04-05). 「ソフトウェア エンジニアリングにおける学術プログラムのエンジニアリング」(PDF) . 第 35 回 Midwest Instruction and Computing Symposium . 2006 年 9 月 13 日閲覧。: 「ソフトウェア エンジニアリングは、プログラミングの単なる美化された名前だと考える人もいます。プログラマーであれば、名刺に「ソフトウェア エンジニア」と書くかもしれませんが、「プログラマー」と書くことは決してありません。」
- ^ Mills, Harlan D.、JR Newman、CB Engle, Jr.、「ソフトウェア エンジニアリングの学部課程カリキュラム」、Deimel, Lionel E. (1990)。ソフトウェア エンジニアリング教育: SEI カンファレンス 1990、米国ペンシルベニア州ピッツバーグ、4 月 2 ～ 3 日、.. Springer。ISBN 978-0-387-97274-9。、p. 26: 「実際問題として、私たちはソフトウェア エンジニアリングを、実践的なソフトウェア開発および保守の専門家に必要な準備であると考えています。コンピュータ サイエンティストは、さらなる理論的研究の準備をしています...」
- ^ Barbara Kitchevnham、David Budgen、Pearl Brereton、Stephen Linkman (2005)。「証拠に基づくソフトウェア エンジニアリングの実現」。ACM SIGSOFTソフトウェア エンジニアリング ノート。30 (4): 1–3。doi : 10.1145 /1082983.1083175。
私たちは、ソフトウェア エンジニアリングがエンジニアリング分野として進歩するには、現在の主張と分析への依存から脱却する必要があると考えています。
- ^ ローレンス、スナイダー (2017)。情報技術の流暢さ：スキル、概念、および能力（[第 7 版] ed.）。NY、NY。ISBN 978-0134448725. OCLC 960641978.
{{cite book}}: CS1 maint: location missing publisher (link) - ^ Parnas, David L. (1998). 「ソフトウェア エンジニアリング プログラムはコンピュータ サイエンス プログラムではない」. Annals of Software Engineering . 6 : 19–37. doi :10.1023/A:1018949113292. S2CID 35786237.、19 ページ: 「ソフトウェア エンジニアリングをコンピューター サイエンスのサブフィールドとして扱うのではなく、{土木工学、機械工学、化学工学、電気工学、...} の集合の要素として扱います。」
- ^ Parnas, David L. (1998). 「ソフトウェア エンジニアリング プログラムはコンピュータ サイエンス プログラムではない」. Annals of Software Engineering . 6 : 19–37. doi :10.1023/A:1018949113292. S2CID 35786237.、20 ページ：「この論文では、従来の工学分野のプログラムをモデルにしたソフトウェア エンジニアリングの認定専門プログラムの導入により、教育によって信頼性の高いソフトウェア製品を開発する準備が整った卒業生の質と量の両方が向上すると主張しています。」
- ^ McConnell, Steve (2003 年 8 月)。プロフェッショナル ソフトウェア開発: スケジュールの短縮、プロジェクトの質の向上、製品の品質向上、キャリアの向上。ボストン、マサチューセッツ州: Addison-Wesley。ISBN 0-321-19367-9。、39 ページ：「私の意見では、その質問に対する答えは明らかです。プロフェッショナルなソフトウェア開発はエンジニアリングであるべきです。本当にそうでしょうか? いいえ。しかし、そうあるべきでしょうか? 間違いなく、そうです。」
- ^ Knuth, Donald (1974). 「芸術としてのコンピュータプログラミング」(PDF) . Communications of the ACM . 17 (12): 667–673. doi : 10.1145/361604.361612 . S2CID 207685720.1974 年のチューリング賞講演の記録。
- ^ Dijkstra, Edsger W ; Mario Béland による転写 (2004 年 11 月 23 日) [初版 1993 年 12 月 3 日]。「戦争はまだ続いている (オースティンの原稿、1993 年 12 月 3 日)」。EW Dijkstra アーカイブ。テキサス大学オースティン校、コンピュータサイエンス学部。2007年2 月 17 日閲覧。
この用語が 1968 年にミュンヘン工科大学の FL Bauer によって造られたとき、私はそれを歓迎しました。[...] 「ソフトウェア エンジニアリング」という用語の導入は、ソフトウェア システムの設計が数学エンジニアの卓越した活動であるという事実を適切に反映していると解釈しました。[...]。この用語が米国に到着するとすぐに、その技術的な内容はすべて取り除かれました。元の意味ではまったく受け入れられなかったため、そうする必要がありました [...]。 ] その一方で、ソフトウェア エンジニアリングという言葉はほとんど意味のないものになってしまった。これは、Data General 社が一夜にしてすべてのプログラマーを「ソフトウェア エンジニア」という高貴な地位に昇進させたことでよく示されている。
- ^ 「ソフトウェアエンジニアリング | ソフトウェア要件の分類」GeeksforGeeks . 2018-06-19 . 2021-05-06閲覧。
- ^ 「ソフトウェアエンジニアリング | ソフトウェア設計プロセス」。GeeksforGeeks 。 2019年5月24日。 2021年5月6日閲覧。
- ^ 「ソフトウェアメンテナンスとは何か？ソフトウェアメンテナンスの定義、ソフトウェアメンテナンスの意味」。The Economic Times 。 2021年5月6日閲覧。
- ^ Alain Abran、James W. Moore、Pierre Bourque、Robert Dupuis、Leonard L. Tripp 編 (2005) [2004]。「第 1 章 ガイドの紹介」。ソフトウェア エンジニアリング知識体系ガイド。IEEE Computer Society。2016年 5 月 9 日のオリジナルからアーカイブ。2010年 9 月 13 日に取得。
引用文献の総量は、学部教育の修了と 4 年間の経験を通じて習得できる内容となっています。
- ^ Cowling, AJ 1999. ソフトウェア工学の学部課程の最初の10年間。Ann. Softw. Eng. 6, 1–4 (1999年4月), 61–90。
- ^ 「ABET 認定エンジニアリング プログラム」。2007 年 4 月 3 日。2010 年 6 月 19 日時点のオリジナルよりアーカイブ。2007 年4 月 3 日閲覧。
- ^ McConnell, Steve (2003 年 7 月 10 日)。『プロフェッショナル ソフトウェア開発: スケジュールの短縮、製品の高品質化、プロジェクトの成功率の向上、キャリアの向上』。ISBN 978-0-321-19367-4。
- ^ ウィリアムズ、NSW (2001 年 2 月 19 ～ 21 日)。「オンタリオ州プロフェッショナル エンジニアのソフトウェア エンジニアリング実務者のライセンス取得への取り組み」。ソフトウェア エンジニアリング教育およびトレーニング、2001 年議事録。第 14 回ソフトウェア エンジニアリング カンファレンス。ノースカロライナ州シャーロット: IEEE。pp. 77 ～ 78。
- ^ 「NCEES ソフトウェア エンジニアリング試験仕様」(PDF)。2013 年 8 月 27 日のオリジナル(PDF)からアーカイブ。2012 年 4 月 1 日に取得。
- ^ 「NCEES、PEソフトウェアエンジニアリング試験を廃止」。全米工学・測量試験委員会。2018年3月13日。 2018年8月6日閲覧。
- ^ ab Barbara Simons. 「過去の ACM 会長が ACM への貢献を振り返る」。科学と職業としてのコンピューティングの発展 75 周年を祝う。Association for Computing Machinery。2024年5 月 18 日閲覧。
パネルの勧告が提出された後、ACM 評議会は、もともと土木技術者向けに開発されたライセンス プロフェッショナル エンジニアのフレームワークは、ソフトウェア エンジニアリングの専門的な産業慣行に一致せず、最も資格のあるソフトウェア エンジニアの多くがライセンスを取得できないと結論付けました。
- ^ ab John C. Knight; Nancy G. Leveson (2002 年 11 月1 日)。「ソフトウェア エンジニアはライセンスを取得すべきか?」Communications of the ACM。45 ( 11): 87–90。doi :10.1145/581571.581601。
- ^ 「ソフトウェアエンジニアリング倫理規定」(PDF) 。 2012年3月25日閲覧。
- ^ Labs、Qubit (2022年11月29日)。「世界と米国にはプログラマーが何人いるのか? [2023]」。Qubit Labs 。 2023年2月7日閲覧。
- ^ 「世界の開発者人口と人口統計調査 2016 V2」。Evans Data Corporation 。 2017年1月19日閲覧。
- ^ ab Rosenthal, Rachel (2020年8月4日). 「テック企業はアメリカにスキルギャップがあると信じ込ませたい」ブルームバーグ. 2021年10月8日閲覧。
- ^ 「コンピュータソフトウェアエンジニアとコンピュータプログラマー」。2009年12月17日閲覧。
- ^ 「ソフトウェア開発者」。職業展望ハンドブック。米国労働統計局。2019年9月4日。 2019年12月11日閲覧。
- ^ 「コンピューティングの分野と専攻」(PDF)。Association for Computing Machinery 。 2019年9月6日閲覧。
- ^ ab 「ソフトウェア開発者：職業展望ハンドブック」。米国労働統計局。
- ^ 「コンピュータソフトウェアエンジニア」。労働統計局。2010年3月19日。2013年7月26日時点のオリジナルよりアーカイブ。2012年7月20日閲覧。
- ^ 「ソフトウェア開発者」。労働統計局。2014年1月8日。 2012年7月21日閲覧。
- ^ abcde 「コンピュータプログラマー：職業展望ハンドブック：：米国労働統計局」。2019年5月3日時点のオリジナルよりアーカイブ。 2017年1月17日閲覧。
- ^ 「出版物別アーカイブ：数字を超えて：米国労働統計局」www.bls.gov。
- ^ 「間もなく絶滅する組み込みソフトウェアエンジニア」。designnews.com 。 2018年5月10日。
- ^ 「hp の開発者ポータル | HP 国際女性週間: 1980 年代以降、コンピューター サイエンス分野の女性が減少している」。developers.hp.com。
- ^ 「ChatGPTのようなツールのせいでソフトウェアエンジニアの雇用が危ぶまれる？Google CEOサンダー・ピチャイのコメント」Business Today . 2023-04-06 . 2023-05-12閲覧。
- ^ 「ChatGPT はこれらの仕事を時代遅れにする可能性があります」。2023 年 1 月 25 日。2023 年 5 月 12 日閲覧。
- ^ ケイ、グレース。「ソフトウェアエンジニアはAIに置き換えられることにパニックに陥っている」。Business Insider 。2023年5月12日閲覧。
- ^ ファウラー、ゲイリー。「評議会の投稿：ChatGPTは仕事にどのような影響を与えるか？」フォーブス。 2023年5月12日閲覧。
- ^ 伊藤亜貴。「ChatGPT は私たちが知っているコーディングの終焉を意味する」。Business Insider。2023年 5 月 12 日閲覧。
- ^ Zinkula、Aaron Mok、Jacob。「ChatGPTが私たちの仕事を奪うかもしれない。AIに取って代わられる可能性が最も高い10の役割」。Business Insider 。2023年5月12日閲覧。
{{cite web}}: CS1 maint: multiple names: authors list (link) - ^ Cohen, Mikaela (2023年4月15日). 「ChatGPTとAIによって最も脅かされる技術職」CNBC . 2023年5月12日閲覧。
- ^ 「SEI 認定ページ」。 Sei.cmu.edu 。 2012 年 3 月 25 日閲覧。
- ^ Wyrostek, Warren (2008 年 3 月 14 日)。「2008 年の IT 認定に関する上位 10 の問題」。InformIT。2009年 3 月 3 日閲覧。
- ^ IEEE コンピュータ協会。「2006 IEEE コンピュータ協会の IFIP 総会への報告」(PDF) 。2007 年 4 月 10 日閲覧。
- ^ IEEE. 「CSDA」 . 2010年4月20日閲覧。
- ^ カナダ情報処理協会。「ISP 指定」 。2007年 3 月 15 日閲覧。
- ^ 「Professional Engineers Ontario: PEOのウェブサイトへようこそ」。Peo.on.ca 。 2012年3月25日閲覧。
- ^ Thibodaux, Patrick (2006-05-05). 「アウトソーシングが勢いを増すにつれ、コンピュータサイエンスへの関心は薄れる」 Computerworld.com . 2016-12-06閲覧。
- ^ Robert Mullins (2007 年 3 月 13 日)。「北米ではソフトウェア開発者の成長が鈍化: 調査によると、2010 年までにソフトウェア開発者の雇用はアジアがリードする」。InfoWorld。ソフトウェア開発。
- ^ 「Gartner Magic Quadrant」（PDF） Cognizant.com 。 2012年3月25日閲覧。
- ^ Casey, Valentine (2010-08-20). 「仮想ソフトウェアチームプロジェクト管理」. Journal of the Brazilian Computer Society . 16 (2): 83–96. doi : 10.1007/s13173-010-0013-3 . S2CID 14383734.
- ^ 「Outstanding Research Award」. SIGSOFT . 2024年4月1日閲覧。
- ^ David Lo ( SIGSOFT Awards Chair); Thomas Zimmermann ( SIGSOFT Chair) (2024 年 1 月 17 日)。「SIGSOFT Awards 2024」。ACM SIGSOFTブログ。2024年4 月 1 日閲覧。
- ^ 「ICSE 最も影響力のある論文賞」。ACM SIGSOFT。
- ^ Donald J. Bagert (1999 年 4 月)。「視点: ソフトウェア エンジニアのライセンス取得をリードする」。Communications of the ACM。42 ( 4 ): 27–29。doi : 10.1145 /299157.299163。
- ^ ab Barry Boehm (2002 年 9 月～ 10 月)。 「ソフトウェア エンジニアリングは価値に基づくコンタクト スポーツです」。IEEEソフトウェア。19 (5): 95～96。doi :10.1109/MS.2002.1032863。
- ^ Dijkstra, EW (1988). 「コンピューティングサイエンスを実際に教えることの残酷さについて」2014年1月10日閲覧。
出典
- Pierre Bourque、Richard E. (Dick) Fairley 編 (2014)。ソフトウェア エンジニアリング知識体系バージョン 3.0 (SWEBOK) ガイド。IEEE Computer Society。
- Alain Abran、James W. Moore、Pierre Bourque、Robert Dupuis、Leonard L. Tripp 編 (2004)。ソフトウェア エンジニアリング知識体系ガイド。IEEE Computer Society。2016年 5 月 9 日のオリジナルからアーカイブ。2010年 9 月 13 日閲覧。
- イアン・サマービル（2015年3月24日）。ソフトウェアエンジニアリング（第10版）。ピアソン教育株式会社。ISBN 978-0-13-394303-0。
さらに読む
- Pierre Bourque、Richard E. (Dick) Fairley 編 (2014)。ソフトウェア エンジニアリング知識体系バージョン 3.0 (SWEBOK) ガイド。IEEE Computer Society。
- Roger S. Pressman、Bruce Maxim (2014 年 1 月 23 日)。ソフトウェア エンジニアリング: 実践者のアプローチ(第 8 版)。McGraw- Hill。ISBN 978-0-07-802212-8。
- イアン・サマービル（2015年3月24日）。ソフトウェアエンジニアリング（第10版）。ピアソン教育株式会社。ISBN 978-0-13-394303-0。
- Jalote, Pankaj (2005) [1991]. ソフトウェアエンジニアリングへの統合アプローチ (第3版). Springer. ISBN 978-0-387-20881-7。
- Bruegge, Bernd ; Dutoit, Allen (2009)。オブジェクト指向ソフトウェアエンジニアリング: UML、パターン、Java の使用(第 3 版)。Prentice Hall。ISBN 978-0-13-606125-0。
- オシャナ、ロバート (2019-06-21)。組み込みシステム向けソフトウェアエンジニアリング: 方法、実践的テクニック、アプリケーション(第 2 版)。キドリントン、オックスフォード、イギリス。ISBN 978-0-12-809433-4。
外部リンク
ウィキメディア・コモンズには、ソフトウェア エンジニアリングに関連するメディアがあります。
Wikiversityにはソフトウェアエンジニアリングに関する学習リソースがあります
- Pierre Bourque、Richard E. Fairley 編 (2004)。ソフトウェア エンジニアリング知識体系バージョン 3.0 (SWEBOK) ガイド、https://www.computer.org/web/swebok/v3。IEEE Computer Society。
- オープンシステムエンジニアリングとソフトウェア開発ライフサイクルフレームワーク 2010-07-18にWayback MachineでアーカイブOpenSDLC.org 統合クリエイティブコモンズSDLC
- カーネギーメロン大学ソフトウェア工学研究所