ソフトウェア工学

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
上のシリーズの一部
ソフトウェア開発
中心活動
パラダイムとモデル
方法論とフレームワーク
分野をサポートする
練習
ツール
知識の基準と体系
用語集
概要

ソフトウェアエンジニアリングは、系統分類学アプリケーションのソフトウェア開発におけるエンジニアリングアプローチです。[1] [2] [3]

ソフトウェアエンジニアは、ソフトウェアエンジニアリングの原則を適用して、コンピュータソフトウェアの設計、開発、保守、テスト、および評価を行う人です。プログラマーという用語は、同義語として使用されることもありますが、工学教育やスキルの意味が欠けている場合もあります。

エンジニアリング技術は、ソフトウェア開発プロセス[1] [ 4]を通知するために使用されます。これには、ソフトウェアライフサイクルプロセス自体の定義、実装、評価、測定、管理、変更、および改善が含まれます。ソフトウェア構成管理[1] [4]を多用します。これは、構成への変更を体系的に制御し、システムのライフサイクル全体にわたって構成とコードの整合性とトレーサビリティを維持することを目的としています。最新のプロセスでは、ソフトウェアのバージョン管理を使用しています。

歴史

1960年代以降、ソフトウェアエンジニアリングは独自のタイプのエンジニアリングと見なされていました。さらに、ソフトウェアエンジニアリングの開発は苦労と見なされていました。ハードウェアについていくのが難しく、ソフトウェアエンジニアにとって多くの問題を引き起こしました。問題には、予算を超過した、期限を超えた、大規模なデバッグとメンテナンスが必要な、消費者のニーズを満たせなかった、または完成しなかったソフトウェアが含まれていました。1968年、 NATOは、ソフトウェアに関連する問題が取り上げられた最初のソフトウェアエンジニアリング会議を開催しました。ソフトウェア開発のガイドラインとベストプラクティスが確立されました。[5]

「ソフトウェアエンジニアリング」という用語の由来は、さまざまな情報源に起因しています。「ソフトウェアエンジニアリング」という用語は、COMPUTERS and AUTOMATIONの1965年6月号で企業が提供するサービスのリストに登場し、Communications of the ACM（Volume 9、number 8）の1966年8月号でより正式に使用されました。 ACMプレジデントのAnthonyA。Oettingerによる「ACMメンバーシップ」[6] [7]は、ソフトウェアエンジニアリングに関する最初の会議であるフリードリッヒL.バウアー 教授による1968年のNATO会議のタイトルにも関連付けられています。[8] マーガレット・ハミルトンは、アポロ計画の任務中に、彼らが行っていることを正当性を与えるための規律「ソフトウェア工学」について説明しました。[9] 当時、「ソフトウェア危機」が発生したと認識されていました。[10] [11] [12]ソフトウェアエンジニアリングに関する第40回国際会議（ICSE 2018）は、フレデリックブルックス[13]とマーガレットハミルトンのプレナリーセッションの基調講演で「ソフトウェアエンジニアリング」の50周年を祝います。[14]

1984年に、ソフトウェアエンジニアリングインスティテュート（SEI）は、米国ペンシルベニア州ピッツバーグのカーネギーメロン大学のキャンパスに本部を置く連邦政府資金による研究開発センターとして設立されました。Watts Humphreyは、ソフトウェアエンジニアリングプロセスの理解と管理を目的としたSEIソフトウェアプロセスプログラムを設立しました。導入されたプロセス成熟度レベルは、開発のための能力成熟度モデル統合（CMMI-DEV）になります。これは、米国政府がソフトウェア開発チームの能力を評価する方法を定義しています。

ソフトウェアエンジニアリングの最新の一般的に受け入れられているベストプラクティスは、ISO / IEC JTC 1 / SC 7小委員会によって収集され、ソフトウェアエンジニアリング知識体系（SWEBOK）として公開されています。[15]ソフトウェアエンジニアリングは、主要なコンピューティング分野の1つと見なされています。[16]

定義と用語の論争

ソフトウェアエンジニアリングの注目すべき定義は次のとおりです。

  • 「ソフトウェアの設計、実装、テスト、および文書化への科学的および技術的知識、方法、および経験の体系的な適用」—労働統計局— IEEE システムおよびソフトウェアエンジニアリング–語彙[17]
  • 「ソフトウェアの開発、運用、および保守への体系的で統制のとれた定量化可能なアプローチの適用」—ソフトウェアエンジニアリング用語のIEEE標準用語集 [18]
  • 「ソフトウェア生産のすべての側面に関係する工学分野」— Ian Sommerville [19]
  • 「信頼性が高く、実際のマシンで効率的に動作するソフトウェアを経済的に入手するための、健全なエンジニアリングの原則の確立と使用」— Fritz Bauer [20]
  • 「複雑なコンピュータプログラムの設計、実装、および保守を扱うコンピュータサイエンスの分野」— Merriam-Webster [21]
  • 「「ソフトウェアエンジニアリング」には、コードを書くという行為だけでなく、組織がそのコードを長期にわたって構築および維持するために使用するすべてのツールとプロセスが含まれます。[...]ソフトウェアエンジニアリングは、「長期にわたって統合されたプログラミング」と考えることができます。 。 '"— Googleのソフトウェアエンジニアリング[22]

この用語は、あまり正式には使用されていません。

「ソフトウェアエンジニア」の語源

マーガレットハミルトンは、アポロ計画の研究中に「ソフトウェアエンジニアリング」という用語を宣伝しました。「工学」という用語は、技術の進歩に向けた他の貢献と同じように真剣に取り組む必要があることを認めるために使用されました。ハミルトンは、この用語の使用について詳しく説明しています。

私が最初にこの用語を思いついたとき、少なくとも私たちの世界では、これまで誰もそれを聞いたことがありませんでした。それは長い間進行中の冗談でした。彼らは私の過激なアイデアについて私をからかうのが好きでした。最も尊敬されているハードウェアの達人の1人が会議で全員に説明し、ソフトウェアを構築するプロセスもハードウェアと同じように工学分野と見なされるべきであると彼が同意したのは記憶に残る日でした。彼が新しい「用語」自体を受け入れたからではなく、私たちが彼と部屋の他の人たちをそれ自体が工学分野にいるものとして受け入れたからです。[26]

用語の適合性

個々のコメンテーターは、ソフトウェアエンジニアリングまたはその正当性をエンジニアリング分野として定義する方法について鋭く意見が一致していません。David Parnasは、ソフトウェアエンジニアリングは、実際にはエンジニアリングの一形態であると述べています。[27] [28] スティーブ・マコネルはそうではないと言ったが、そうあるべきだと言った。[29] ドナルド・クヌースは、プログラミングは芸術であり科学であると述べています。[30] Edsger W. Dijkstraは、ソフトウェアエンジニアリングとソフトウェアエンジニアという用語が誤用されていると主張しました[不適切な合成？] そして、特に、アメリカ合衆国。[31]

大規模プロジェクトのタスク

ソフトウェア要件

要件エンジニアリングとは、ソフトウェアの要件の引き出し、分析、仕様、および検証に関するものです。ソフトウェア要件には、3つの異なるタイプがあります。機能要件、非機能要件があります、およびドメイン要件。ソフトウェアの操作を実行し、ユーザーが使用できる適切な出力が期待される必要があります。非機能要件は、移植性、セキュリティ、保守性、信頼性、スケーラビリティ、パフォーマンス、再利用性、柔軟性などの問題を扱います。これらは、干渉の制約、パフォーマンスの制約（応答時間、セキュリティ、ストレージスペースなど）、動作の制約、ライフサイクルの制約（保守性、移植性など）、および経済的な制約に分類されます。非機能要件を指定する場合は、システムまたはソフトウェアがどのように機能するかについての知識が必要です。ドメイン要件は、プロジェクトの特定のカテゴリまたはドメインの特性と関係があります。[32]

ソフトウェア設計

ソフトウェア設計とは、システムまたはコンポーネントのアーキテクチャ、コンポーネント、インターフェイス、およびその他の特性を定義するプロセスに関するものです。これは、ソフトウェアアーキテクチャとも呼ばれます。ソフトウェア設計は、3つの異なるレベルの設計に分けられます。3つのレベルは、インターフェイスデザイン、アーキテクチャデザイン、および詳細デザインです。。インターフェイス設計は、システムとその環境の間の相互作用です。これは、システムの内部動作とともに、高レベルの抽象化で発生します。アーキテクチャ設計は、システムの主要コンポーネントと、それらの責任、プロパティ、インターフェイス、およびそれらの間で発生する関係と相互作用に関係しています。詳細設計は、すべての主要なシステムコンポーネントの内部要素、それらのプロパティ、関係、処理、および通常はそれらのアルゴリズムとデータ構造です。[33]

ソフトウェア構築

ソフトウェア開発の主な活動であるソフトウェア構築[1] [4]は、プログラミング、単体テスト、統合テスト、およびデバッグの組み合わせです。このフェーズでのテストは、通常、ソフトウェアの構築中にプログラマーが実行し、記述された内容を確認して、コードを次のステップに送信する準備ができたことを判断します。

ソフトウェアテスト

ソフトウェアテスト[1] [4]は、単体テストや統合テストなどのさまざまなアプローチを使用して、テスト対象の製品またはサービスの品質に関する情報を利害関係者に提供するために実施される経験的で技術的な調査です。これはソフトウェア品質の1つの側面です。ソフトウェア開発の別のフェーズとして、通常、品質保証スタッフまたはコードを作成した開発者以外の開発者によって実行されます。

ソフトウェアメンテナンス

ソフトウェアメンテナンス[1] [4]は、ソフトウェア製品の出荷後に費用効果の高いサポートを提供するために必要なアクティビティを指します。ソフトウェアメンテナンスとは、配布後にソフトウェアアプリケーションを変更および更新して、障害を修正し、そのパフォーマンスを向上させることです。ソフトウェアは現実の世界と多くの関係があり、現実の世界が変わると、ソフトウェアのメンテナンスが必要になります。ソフトウェアのメンテナンスには、エラー修正、最適化、未使用および破棄された機能の削除、および既存の機能の拡張が含まれます。通常、メンテナンスはプロジェクトコストの約40％から80％を占めるため、メンテナンスに重点を置くことでコストを抑えることができます。[34]

教育

コンピュータプログラミングの知識は、ソフトウェアエンジニアになるための前提条件です。2004年、IEEE Computer SocietyはSWEBOKを作成しました。これは、ISO / IECテクニカルレポート1979：2005として公開されており、4年の経験を持つ大学院のソフトウェアエンジニアが習得することを推奨する知識体系について説明しています。[35] 多くのソフトウェアエンジニアは、大学の学位を取得するか、専門学校で訓練することによって職業に就きます。学部ソフトウェア工学の学位を取得するための1つの標準的な国際カリキュラムは、IEEE ComputerSocietyのコンピューティングカリキュラムに関する合同タスクフォースとAssociationfor ComputingMachineryによって定義されました。、および2014年に更新されました。[36]多くの大学がソフトウェア工学の学位プログラムを持っています。2010年の時点で、米国には244のソフトウェアエンジニアリングプログラムのキャンパス学士号、70のオンラインプログラム、230の修士レベルのプログラム、41の博士号レベルのプログラム、69の証明書レベルのプログラムがありました。

大学教育に加えて、多くの企業が情報技術のキャリアを追求したい学生のためのインターンシップを後援しています。これらのインターンシップでは、一般的なソフトウェアエンジニアが毎日遭遇する興味深い現実のタスクを学生に紹介できます。同様の経験は、ソフトウェアエンジニアリング の兵役を通じて得ることができます。

ソフトウェア工学の学位プログラム

今日のすべての開業医の半数は、コンピュータサイエンス、情報システム、または情報技術の学位を持っています。[要出典]少数ですが、増え続ける開業医の数は、ソフトウェア工学の学位を持っています。1987年、インペリアルカレッジロンドンのコンピューティング学部は、英国と世界で最初の3年間のソフトウェアエンジニアリングの学士号を取得しました。翌年、シェフィールド大学は同様のプログラムを確立しました。[37] 1996年、ロチェスター工科大学米国で最初のソフトウェア工学の学士号プログラムを確立しましたが、ライス大学、クラークソン大学、ミルウォーキー工科大学、ミシシッピ州立大学が取得した2003年までABET認定を取得しませんでした。[38] 1997年、インドのコインバトールにあるPSGカレッジ・オブ・テクノロジーは、ソフトウェア工学の5年間の統合された理学修士号を開始した最初の大学でした。[要出典]

それ以来、ソフトウェア工学の学士号が多くの大学で確立されています。学部ソフトウェア工学の学位を取得するための標準的な国際カリキュラムであるSE2004は、2001年から2004年にかけて、Association for ComputingMachineryとIEEEComputerSocietyからの資金提供を受けて運営委員会によって定義されました。2004年の時点で、米国では約50の大学がソフトウェア工学の学位を提供しており、コンピュータサイエンスと工学の原則と実践の両方を教えています。最初のソフトウェアエンジニアリング修士号はシアトル大学で設立されましたそれ以来、大学院のソフトウェア工学の学位は、より多くの大学から利用できるようになりました。同様にカナダでは、 Canadian Council of ProfessionalEngineersのCanadianEngineering Accreditation Board（CEAB）がいくつかのソフトウェアエンジニアリングプログラムを承認しています。

1998年、米国海軍大学院（NPS）は、ソフトウェア工学の世界初の博士号プログラムを設立しました。[引用が必要]さらに、カリフォルニア州立大学フラートン校のコンピュータサイエンスおよびエンジニアリング学部を通じて提供されるソフトウェアエンジニアリングの理学修士（MSE）の学位など、ソフトウェアエンジニアリングの多くのオンライン上級学位が登場しています。Steve McConnellは、ほとんどの大学がソフトウェアエンジニアリングではなくコンピュータサイエンスを教えているため、真のソフトウェアエンジニアが不足していると述べています。[39] ETS（Écoledetechnologiesupérieure）大学とUQAM（UniversitéduQuébecàMontréal）は、ソフトウェアエンジニアがカバーする知識体系を記述するISO標準となったソフトウェア工学知識体系（SWEBOK ）の開発をIEEEから義務付けられました。[40]

職業

プロのソフトウェアエンジニアのライセンスまたは認定に関する法的要件は、世界中で異なります。英国では、役職ソフトウェアエンジニアを引き受けるまたは使用するためのライセンスまたは法的要件はありません。アルバータ州、ブリティッシュコロンビア州、オンタリオ州[41]、ケベック州など、カナダの一部の地域では、ソフトウェアエンジニアは、プロフェッショナルエンジニア（P.Eng）の指定および/または情報システムプロフェッショナル（ISP）の指定を保持できます。ヨーロッパでは、ソフトウェアエンジニアは、ヨーロッパエンジニア（EUR ING）の専門家としての称号を取得できます。

米国は、2013年以来、ソフトウェアエンジニアリングのためのNCEES プロフェッショナルエンジニア試験を提供しており、これによりソフトウェアエンジニアはライセンスを取得して承認されることができます。[42] NCEESは、参加がないため、2019年4月以降に試験を終了します。[43]強制実施権は現在も大部分が議論されており、物議を醸していると認識されている。[要出典]テキサスなどの米国の一部の地域では、エンジニアという用語の使用は法律によって規制されており、プロフェッショナルエンジニアのライセンスを持っている個人のみが使用するために予約されています。[要出典]

IEEE Computer SocietyとACMは、米国を拠点とするソフトウェアエンジニアリングの2つの主要な専門組織であり、ソフトウェアエンジニアリングの専門家向けのガイドを公開しています。IEEEのソフトウェア工学知識体系ガイド– 2004バージョン（SWEBOK）は、この分野を定義し、IEEEが実践的なソフトウェアエンジニアに期待する知識について説明しています。最新のSWEBOKv3は更新されたバージョンであり、2014年にリリースされました。[44] IEEEは、「ソフトウェアエンジニアリング倫理規定」も公布しています。[45]

雇用

米国労働統計局（BLS）は、2018年に米国で仕事をしている1,365,500人のソフトウェア開発者を数えました。 [46]研究分野としての比較的新しいため、ソフトウェアエンジニアリングの正式な教育は、コンピュータサイエンスのカリキュラムの一部として教えられることがよくあります。 、および多くのソフトウェアエンジニアは、コンピュータサイエンスの学位を取得しています。[47] BLSは、2014年から2024年にかけて、コンピューターソフトウェアエンジニアリングが17％増加すると推定しています。[48]これは、ソフトウェアエンジニアリングの2012年から2022年のBLS推定値である22％から減少しています。[49] [48]そして、2010年から2020年までのBLS推定値の30％からさらに低下しています。[50]この傾向により、米国のコンピューターソフトウェアエンジニアに割り当てられていたであろう仕事は、代わりにインドや他の外国のコンピューターソフトウェアエンジニアにアウトソーシングされるため、仕事の成長は過去10年間ほど速くない可能性があります。[51] [52]さらに、コンピュータープログラマーのためのBLS Job Outlook、2014–24は、-8％（彼らの言葉では減少）を予測し、[51]その後、Job Outlook、2019-29の減少を予測します。コンピューターをプログラムする人にとっては、2020年から2030年にかけて9％[53] 、10％減少します。[54] [55]さらに、多くのソフトウェア分野の女性も、他の工学分野と比較して、長年にわたって減少している。[56]ただし、米国市場の現在のソフトウェアエンジニアの多くは、今後数十年で 専門職を辞めたり、市場から離れたりするため、この傾向は将来変化するか、遅くなる可能性があります。

多くのソフトウェアエンジニアは、従業員または請負業者として働いています。ソフトウェアエンジニアは、企業、政府機関（民間または軍）、および非営利団体と協力しています。一部のソフトウェアエンジニアは、フリーランサーとして働いています。一部の組織には、ソフトウェア開発プロセスの各タスクを実行するスペシャリストがいます。他の組織では、ソフトウェアエンジニアがそれらの多くまたはすべてを実行する必要があります。大規模なプロジェクトでは、人々は1つの役割だけに特化する場合があります。小さなプロジェクトでは、人々は同時に複数またはすべての役割を果たす場合があります。多くの企業は、インターン、多くの場合、夏休み中の大学生や大学生、またはインターンシップを採用しています。専門分野には、アナリスト、建築家が含まれます、開発者、テスター、テクニカルサポート、ミドルウェアアナリスト、プロジェクトマネージャー、教育者、研究者。

ほとんどのソフトウェアエンジニアとプログラマーは週に40時間働いていますが、2008年にはソフトウェアエンジニアの約15％とプログラマーの11％が週に50時間以上働いていました。コンピューター端末の前に座ってキーボードで入力している期間、エンジニアとプログラマーは、目の緊張、背中の不快感、および手足のトンネル症候群などの手と手首の問題の影響を受けやすくなります。[57]

認証

Software Engineering Instituteは、セキュリティ、プロセス改善、ソフトウェアアーキテクチャなどの特定のトピックに関する認定を提供しています。[58] IBM、Microsoft、およびその他の企業も、独自の認定試験を後援しています。多くのIT 認定プログラムは特定のテクノロジーを対象としており、これらのテクノロジーのベンダーによって管理されています。[59]これらの認証プログラムは、これらの技術を使用する人々を雇用する機関に合わせて調整されています。

一般的なソフトウェアエンジニアリングスキルの幅広い認定は、さまざまな専門家団体を通じて利用できます。2006年の時点で、IEEEは575人を超えるソフトウェア専門家をCertified Software Development Professional（CSDP）として認定しています。[60] 2008年に、Certified Software Development Associate（CSDA）として知られるエントリーレベルの認定を追加しました。[61] ACMは、1980年代初頭に専門的な認定プログラムを持っていました。[要出典]興味がなかったため中止されました。ACMは、1990年代後半にソフトウェアエンジニアの専門的な認定の可能性を検討しましたが、最終的に、そのような認定はソフトウェアエンジニアリングの専門的な産業慣行には不適切であると判断しました。[62]

英国では、英国コンピュータ協会が、完全資格のあるメンバー（MBCS ）が利用できるChartered IT Professional（CITP）と呼ばれる法的に認められた専門資格を開発しました。ソフトウェアエンジニアは、Institute of Engineering and Technologyのメンバーになる資格があるため、公認技術者のステータスを得る資格があります。カナダでは、Canadian Information Processing Societyが、 Information Systems Professional（ISP）と呼ばれる法的に認められた専門資格を開発しました。[63]カナダのオンタリオ州では、カナダのエンジニアリング認定委員会（CEAB）を卒業したソフトウェアエンジニア認定プログラムであり、PEO（Professional Engineers Ontario）のProfessional Practice Examination（PPE）を正常に完了し、48か月以上の許容可能なエンジニアリング経験がある場合は、Professional Engineers Ontarioを通じてライセンスを取得する資格があり、Professional EngineersP.Engになることができます。[64]ただし、PEOはオンライン教育や遠隔教育を認識していません。そして、コンピュータサイエンスプログラムは、2つの間に途方もない重複があるにもかかわらず、ソフトウェアエンジニアリングプログラムと同等であるとは考えていません。これは論争と認証戦争を引き起こしました。また、この職業のP.Eng保有者の数は非常に少なくなっています。この分野で働く専門家の大多数は、SEではなくCSの学位を取得しています。SE以外の学位を取得している人にとっては難しい認定パスを考えると、ほとんどの場合、わざわざライセンスを取得する必要はありません。

グローバリゼーションの影響

アウトソーシングの初期の影響と、発展途上国における国際的な人材の比較的低いコストにより、ソフトウェア開発活動は、北米とヨーロッパの企業からインド、そしてその後、中国、ロシア、その他の発展途上国に大規模に移行しました。このアプローチにはいくつかの欠陥がありました。主に、クライアントと開発者の間の人間の相互作用と大規模な転勤を妨げる距離/タイムゾーンの違いです。これは、ソフトウェアエンジニアリングの専門家の多くの側面に悪影響を及ぼしました。たとえば、先進国の一部の学生は、オフショアアウトソーシング（他の国からのソフトウェア製品またはサービスの輸入）およびによって追放されることを恐れて、ソフトウェアエンジニアリングに関連する教育を避けています。外国のビザ労働者。[65]統計は現在、ソフトウェアエンジニアリング自体への脅威を示していませんが、関連するキャリアとして、コンピュータープログラミングは影響を受けているようです。[66] [67]それにもかかわらず、フォロー・ザ・サンのワークフローを介してオフショアおよびニアショアのリソースをスマートに活用する機能により、多くの組織の全体的な運用能力が向上しました。[68]北アメリカ人が仕事を辞めているとき、アジア人はちょうど仕事に到着しています。アジア人が仕事を辞めるとき、ヨーロッパ人は仕事に到着します。これにより、残業代を支払ったり、主要な人的資源である睡眠パターンを混乱させたりすることなく、ビジネスに不可欠なプロセスを1日24時間人間が監視できるようになります。

グローバルなアウトソーシングにはいくつかの利点がありますが、グローバルな（そして一般的に分散された）開発は、開発者間の距離に起因する深刻な問題に直面する可能性があります。これは、地理的、時間的、文化的、コミュニケーション（さまざまな場所でのさまざまな言語や英語の方言の使用を含む）として識別されているこのタイプの距離の重要な要素によるものです。[69]過去15年間、グローバルなソフトウェア開発の分野で研究が行われ、複雑な活動に関連する利点と問題を浮き彫りにする関連する研究が数多く公開されています。ソフトウェアエンジニアリングの他の側面と同様に、この分野および関連分野で研究が進行中です。

賞品

ソフトウェア工学の分野にはいくつかの賞があります：[70]

  • コーディ賞は、ソフトウェア業界内のソフトウェア開発の卓越性に対してソフトウェア情報産業協会によって毎年発行される賞です。
  • Jolt Awardsは、ソフトウェア業界の賞です。
  • スティーブンス賞は、ウェインスティーブンスを記念して授与されるソフトウェアエンジニアリング賞です。

批評

ソフトウェアエンジニアリングは、その実践者を、問題解決のために明確に定義されたエンジニアリングアプローチに従う個人と見なしています。これらのアプローチは、さまざまなソフトウェアエンジニアリングの本や研究論文で指定されており、常に予測可能性、精度、リスクの軽減、専門性の意味が含まれています。この視点は、[誰によって？]工学知識を広め、分野を成熟させるためのメカニズムとしてのライセンス、認証、および体系化された知識体系。

ソフトウェアエンジニアリングはエンジニアリングを拡張し、エンジニアリングモデル、つまりエンジニアリングプロセス、エンジニアリングプロジェクト管理、エンジニアリング要件、エンジニアリング設計、エンジニアリング構築、およびエンジニアリング検証を利用します。この概念は非常に新しいため、ほとんど理解されておらず、ソフトウェアエンジニアリングの教科書、論文、プログラマーや職人のコミュニティなど、広く誤解されています。

ソフトウェアエンジニアリングの主要な問題の1つは、アプローチの実際の検証が通常存在しないか、非常に限られているため、そのアプローチが十分に経験的ではないことです。したがって、ソフトウェアエンジニアリングは、「理論的環境」でのみ実行可能であると誤解されることがよくあります。

今日のソフトウェア開発で使用されている多くの概念の創設者であるEdsgerDijkstraは、2002年に亡くなるまで「ソフトウェアエンジニアリング」のアイデアを拒否し、これらの用語は彼がコンピュータサイエンスの「根本的な目新しさ」と呼んだものとの類似性が低いと主張しました。 ：

これらの現象の多くは、「ソフトウェアエンジニアリング」という名前でバンドルされています。経済学は「悲惨な科学」として知られているので、ソフトウェアエンジニアリングは「運命の規律」として知られるべきであり、その目標は自己矛盾しているため、その目標に近づくことさえできないために運命づけられています。もちろん、ソフトウェアエンジニアリングは別の価値のある原因として現れますが、それは洗眼剤です。その文献を注意深く読み、その信者が実際に何をしているのかを分析すると、ソフトウェアエンジニアリングがその憲章として受け入れられていることがわかります。 。」[71]

も参照してください

勉強と練習

役割

専門的な側面

参考文献

引用

  1. ^ a b c d e f Abran etal。2004年、1〜1ページ
  2. ^ ACM（2007）。「コンピューティングの学位とキャリア」。ACM 。2010年11月23日取得。
  3. ^ Laplante、Phillip（2007）。すべてのエンジニアがソフトウェアエンジニアリングについて知っておくべきこと。ボカラトン：CRC。ISBN 978-0-8493-7228-5。2011年1月21日取得。
  4. ^ a b c d e 「ソフトウェア工学知識体系（SWEBOKバージョン3）、2014年」（pdf）。www.swebok.org。IEEE ComputerSociety 。2016年5月24日取得。
  5. ^ 「コーディングとソフトウェアエンジニアリングの歴史」。www.hackreactor.com 。2021-05-06を取得。
  6. ^ Oettinger、AG（1966）。「ACMメンバーシップへの会長の手紙」。コミュン。ACM。コンピューティングマシナリー協会。9（8）：545–546。土井：10.1145 /365758.3291288。ISSN0001-0782。_ S2CID53432801。_  
  7. ^ 「「ソフトウェア工学」の起源" 。 2017年11月17日取得。
  8. ^ ランドール、ブライアン。「1968 / 69NATOソフトウェアエンジニアリングレポート」。2017年11月17日取得。
  9. ^ ソフトウェアマガジン。「「ソフトウェア工学」という用語を発明した科学者について知っておくべきこと"。2018年11月24日にオリジナルからアーカイブされました。 2019年2月12日に取得されました。
  10. ^ Sommerville 2008、p。26
  11. ^ ピーター、ナウア; ブライアン・ランデル（1968年10月7〜11日）。ソフトウェア工学：NATO科学委員会が主催する会議の報告（PDF）。ガルミッシュ、ドイツ：NATO科学部。2008年12月26日取得。
  12. ^ ランデル、ブライアン（2001年8月10日）。「1968 / 69NATOソフトウェアエンジニアリングレポート」。ブライアンランデルの大学のホームページ。ニューカッスル大学コンピュータサイエンス学部。2008年10月11日取得。最初のNATOソフトウェア工学会議のアイデア、特に当時はほとんど知られていなかった用語「ソフトウェアエンジニアリング」を（意図的に挑発的な）タイトルとして採用するというアイデアは、もともとフリッツバウアー教授から来たと思います。
  13. ^ ソフトウェア工学の40周年と50年を祝うソフトウェア工学に関する2018年国際会議。「ICSE2018–プレナリーセッション–フレッドブルックス」。2018年8月9日取得。
  14. ^ ソフトウェア工学の40周年と50年を祝うソフトウェア工学に関する2018年国際会議。「ICSE2018–プレナリーセッション–マーガレットハミルトン」。2018年8月9日取得。
  15. ^ 「ISO / IECTR 19759：2005」。2012年4月1日取得。
  16. ^ 「2005年のコンピューティングカリキュラムのための合同タスクフォース」（PDF）。2014-10-21。2014-10-21のオリジナルからアーカイブ（PDF）。2020年4月16日取得。
  17. ^ システムおよびソフトウェアエンジニアリング–語彙、 ISO / IEC / IEEE std 24765：2010（E）、2010。
  18. ^ ソフトウェアエンジニアリング用語のIEEE標準用語集、 IEEE std 610.12-1990、1990。
  19. ^ Sommerville、Ian（2007）[1982]。「1.1.2ソフトウェア工学とは？」。ソフトウェア工学（第8版）。ハーロウ、イギリス：ピアソン教育。p。7. ISBN 978-0-321-31379-9。ソフトウェアエンジニアリングは、システム仕様の初期段階から使用後のシステムの保守まで、ソフトウェア生産のすべての側面に関係するエンジニアリング分野です。この定義には、2つの重要なフレーズがあります
    。1。エンジニアリング分野エンジニアは物事を機能させます。それらは、これらが適切である場合、理論、方法、およびツールを適用します[。。。]エンジニアはまた、組織的および財政的制約に対処しなければならないことを認識しています。[。。。]
    2。ソフトウェア制作のすべての側面ソフトウェアエンジニアリングは、ソフトウェア開発の技術的プロセスだけでなく、ソフトウェアプロジェクト管理などの活動や、ソフトウェア生産をサポートするためのツール、方法、理論の開発にも関わっています。
  20. ^ 「ソフトウェア工学」。情報処理。71：530–538。
  21. ^ 「ソフトウェア工学の定義」。www.merriam-webster.com 。2019年11月25日取得。
  22. ^ ウィンターズ、タイタス​​; マンシュレック、トム; ライト、ハイラム（2020）。「序文、時間の経過に伴うプログラミング」。Googleのソフトウェアエンジニアリング。O'Reilly Media、Inc。pp。xix–xx、6–7。ISBN 978-1-492-08279-8。「ソフトウェアエンジニアリング」には、コードを作成する行為だけでなく、組織がそのコードを長期にわたって構築および維持するために使用するすべてのツールとプロセスが含まれることを提案します。ソフトウェア組織は、コードを長期にわたって価値のあるものに保つのに最適な方法を導入できますか？エンジニアはどのようにしてコードベースをより持続可能にし、ソフトウェアエンジニアリングの規律自体をより厳格にすることができますか？
  23. ^ Akram I. Salah（2002-04-05）。「ソフトウェア工学におけるアカデミックプログラムのエンジニアリング」（PDF）。第35回中西部命令およびコンピューティングシンポジウム。2006年9月13日取得。 ：「一部の人にとって、ソフトウェアエンジニアリングはプログラミングの単なる称賛に値する名前です。プログラマーであれば、「プログラマー」ではなく「ソフトウェアエンジニア」を名刺に載せることができます。」
  24. ^ Mills、Harlan D.、JR Newman、およびCB Engle、Jr。、「ソフトウェアエンジニアリングの学部カリキュラム」、 Deimel、Lionel E.（1990）。ソフトウェア工学教育：SEI Conference 1990、米国ペンシルベニア州ピッツバーグ、4月2〜3日、 ..。スプリンガー。ISBN 978-0-387-97274-9。、p。26：「実際問題として、ソフトウェアエンジニアリングは、実践、ソフトウェア開発、および保守の専門家にとって必要な準備であると考えています。コンピュータサイエンティストは、さらなる理論的研究の準備をしています...」
  25. ^ デビッド・バッジン; パールブレレトン; バーバラ・キッチナム; スティーブンリンクマン（2004-12-14）。「証拠に基づくソフトウェア工学の実現」。2006年12月17日にオリジナルからアーカイブされました。2006年10月18日取得。：「ソフトウェアエンジニアリングは、アドボカシーと分析への現在の依存から離れることによってのみ、エンジニアリング分野として進歩できると信じています。...」
  26. ^ ローレンス、スナイダー（2017）。情報技術に精通していること：スキル、概念、および能力（[第7版]版）。NY、NY。ISBN 978-0134448725。OCLC960641978 。_
  27. ^ Parnas、David L.（1998）。「ソフトウェア工学プログラムはコンピュータサイエンスプログラムではありません」。ソフトウェア工学の年報。6：19–37。土井：10.1023 / A：1018949113292。S2CID35786237。_ 、p。19：「ソフトウェア工学をコンピュータサイエンスのサブフィールドとして扱うのではなく、セットの要素として扱います。{土木工学、機械工学、化学工学、電気工学、....}。」
  28. ^ Parnas、David L.（1998）。「ソフトウェア工学プログラムはコンピュータサイエンスプログラムではありません」。ソフトウェア工学の年報。6：19–37。土井：10.1023 / A：1018949113292。S2CID35786237。_ 、p。20：「この論文は、ソフトウェアエンジニアリングにおける認定された専門的なプログラム、つまり従来のエンジニアリング分野のプログラムをモデルにしたプログラムの導入が、教育によって信頼できるものを開発する準備が整っている卒業生の質と量の両方を向上させるのに役立つと主張しています。ソフトウェア製品。」
  29. ^ McConnell、Steve（2003年8月）。プロフェッショナルなソフトウェア開発：より短いスケジュール、より良いプロジェクト、優れた製品、強化されたキャリア。マサチューセッツ州ボストン：アディソン-ウェスリー。ISBN 0-321-19367-9。、p。39：「私の意見では、その質問に対する答えは明らかです。プロのソフトウェア開発はエンジニアリングでなければなりません。そうですか？いいえ。しかし、そうすべきですか？間違いなくそうです。」
  30. ^ クヌース、ドナルド（1974）。「芸術としてのコンピュータプログラミング」（PDF）。ACMの通信。17（12）：667–673。土井：10.1145 /361604.361612。S2CID207685720。_  1974年チューリング賞講演の写し。
  31. ^ Dijkstra、Edsger W ; マリオ・ベランドによる転写（2004年11月23日）[1993年12月3日初版]。「まだ戦争が続いている（原稿オースティン、1993年12月3日）」。EWダイクストラアーカイブ。テキサス大学オースティン校、コンピュータサイエンス学部。2007年2月17日取得。この用語が1968年にミュンヘン工科大学のFLバウアーによって造られたとき、私はそれを歓迎しました。[。。。]私は、「ソフトウェアエンジニアリング」という用語の導入を、ソフトウェアシステムの設計が数学エンジニアにとって卓越した活動であったという事実を適切に反映していると解釈しました。[。。。]。用語が米国に到着するとすぐに、それはすべての技術的内容から解放されました。本来の意味では完全に受け入れられなかったので、そうしなければなりませんでした[。。。]その間、ソフトウェアエンジニアリングはほとんど空の用語になりました。これは、すべてのプログラマーを一夜にして「ソフトウェアエンジニア」の高位に昇進させたデータゼネラルによってうまく示されました。
  32. ^ 「ソフトウェアエンジニアリング|ソフトウェア要件の分類」。GeeksforGeeks。2018-06-19 。2021-05-06を取得。
  33. ^ 「ソフトウェアエンジニアリング|ソフトウェア設計プロセス」。GeeksforGeeks。2019-05-24 。2021-05-06を取得。
  34. ^ 「ソフトウェア保守とは何ですか？ソフトウェア保守の定義、ソフトウェア保守の意味」。エコノミックタイムズ。2021-05-06を取得。
  35. ^ Abran、Alain、ed。（2005）[2004]。「第1章：ガイドの紹介」。ソフトウェア工学知識体系へのガイド。ロスアラミトス：IEEE ComputerSociety。ISBN 978-0-7695-2330-9。2010年9月13日取得。引用文献の総量は、学部教育の修了と4年の経験を通じて習得するのに適していることを目的としています。
  36. ^ 「SE2014ソフトウェアエンジニアリングカリキュラム」（PDF）。
  37. ^ カウリング、AJ1999。ソフトウェア工学の学部課程の最初の10年。アン。Softw。工学 6、1–4（1999年4月）、61–90。
  38. ^ 「ABET認定エンジニアリングプログラム」。2007年4月3日。2007年4月3日取得。
  39. ^ McConnell、Steve（2003年7月10日）。プロフェッショナルなソフトウェア開発：より短いスケジュール、より高品質の製品、より成功したプロジェクト、強化されたキャリア。ISBN978-0-321-19367-4。 _ 
  40. ^ ソフトウェアエンジニアリング—ソフトウェアエンジニアリング知識体系（SWEBOK）のガイド、国際標準化機構、2015年、 2020年1月11日取得
  41. ^ ウィリアムズ、ニューサウスウェールズ州（2001年2月19〜21日）。「ソフトウェアエンジニアリングの実践者にライセンスを与えるためのオンタリオ州のプロフェッショナルエンジニアのアプローチ」。ソフトウェア工学教育およびトレーニング、2001年の議事録。第14回会議。ノースカロライナ州シャーロット：IEEE。pp。77–78。
  42. ^ 「NCEESソフトウェア工学試験仕様」（PDF）。2013年8月27日にオリジナル（PDF）からアーカイブされました。2012年4月1日取得。
  43. ^ 「NCEESはPEソフトウェアエンジニアリング試験を中止します」。工学と測量のための国家審査委員会。2018年3月13日。2018年8月6日取得。
  44. ^ 「SWEBOKガイドバージョン3」。2015年3月9日取得。
  45. ^ 「ソフトウェア工学倫理規定」（PDF）。2012年3月25日取得。
  46. ^ 「ソフトウェア開発者」。オキュペーショナルアウトルックハンドブック。米国労働統計局。2019年9月4日。2019年12月11日取得。
  47. ^ 「コンピューティング分野と専攻」（PDF）。ACM 。2019年9月6日取得。
  48. ^ a b 「ソフトウェア開発者：職業展望ハンドブック」。米国労働統計局。
  49. ^ 「コンピュータソフトウェアエンジニア」。労働統計局。2010年3月19日。2013年7月26日のオリジナルからアーカイブ。2012年7月20日取得。
  50. ^ 「ソフトウェア開発者」。労働統計局。2014年1月8日。2012年7月21日取得。
  51. ^ a b 「コンピュータープログラマー：職業展望ハンドブック」。米国労働統計局。
  52. ^ a b ローゼンタール、レイチェル（2020年8月4日）。「テクノロジー企業は、アメリカにはスキルのギャップがあると信じてほしい」。ブルームバーグ。2021年10月8日取得。{{cite web}}: CS1 maint: url-status (link)
  53. ^ 「コンピュータプログラマー：職業展望ハンドブック::米国労働統計局」。www.bls.gov。
  54. ^ 「出版物によるアーカイブ：数を超えて：米国労働統計局」。www.bls.gov。
  55. ^ 「間もなく絶滅する組み込みソフトウェアエンジニア」。designnews.com。2018年5月10日。
  56. ^ 「hpの開発者ポータル| HP International Women's Week：1980年代以降コンピュータサイエンスの女性が減少」。developers.hp.com。
  57. ^ 「コンピュータソフトウェアエンジニアおよびコンピュータプログラマー」。2009年12月17日取得。
  58. ^ 「SEI認証ページ」。Sei.cmu.edu 。2012年3月25日取得。
  59. ^ Wyrostek、ウォーレン（2008年3月14日）。「2008年のIT認証に関するトップ10の問題」。InformIT 。2009年3月3日取得。
  60. ^ IEEE ComputerSociety。「2006IEEEComputer Society Report to the IFIP GeneralAssembly」（PDF）。2007年4月10日取得。
  61. ^ IEEE。「CSDA」。2010年4月20日取得。
  62. ^ ACM（2000年7月17日）。「ライセンスエンジニアリング専門職としてのソフトウェアエンジニアリングに関するACMの立場の要約」（PDF）。Association for Computing Machinery（ACM）。2008年5月17日にオリジナル（PDF）からアーカイブされました。2009年3月3日取得。2000年5月の会議で、評議会はさらに、元々は民間エンジニアのために開発された、認可された専門エンジニアの枠組みは、ソフトウェアエンジニアリングの専門的な産業慣行と一致しないと結論付けました。そのようなライセンス慣行は、知識体系が成熟している場合でも、能力の誤った保証を与えるでしょう。そして、最も資格のあるソフトウェアエンジニアの多くがライセンスを取得することを妨げるでしょう。
  63. ^ カナダ情報処理協会。「ISP指定」。2007年3月15日取得。
  64. ^ 「ProfessionalEngineersOntario：PEOのウェブサイトへようこそ」。Peo.on.ca。_ 2012年3月25日取得。
  65. ^ ティボドー、パトリック（2006-05-05）。「アウトソーシングが勢いを増すにつれて、コンピュータサイエンスへの関心は薄れています」。Computerworld.com 。2016年12月6日取得。
  66. ^ 「コンピュータプログラマー」。Bls.gov 。2012年3月25日取得。
  67. ^ マリンズ、ロバート（2007-03-13）。「北米ではソフトウェア開発者の成長が鈍化しています」。InfoWorld。2009年4月4日にオリジナルからアーカイブされました。2012年3月25日取得。
  68. ^ 「GartnerMagicQuadrant」（PDF）。Cognizant.com 。2012年3月25日取得。
  69. ^ ケーシー、バレンタイン（2010-08-20）。「仮想ソフトウェアチームのプロジェクト管理」。ブラジルコンピュータ学会誌。16（2）：83–96。土井：10.1007 / s13173-010-0013-3。S2CID14383734。_ 
  70. ^ いくつかの外部リンク：
  71. ^ Dijkstra、EW（1988）。「実際にコンピューティングサイエンスを教えることの残酷さについて」。2014年1月10日取得。

ソース

  • アブラン、アラン; ムーア、ジェームズW。; バーク、ピエール; デュプイ、ロバート; Tripp、Leonard L.（2004）。ソフトウェア工学知識体系へのガイド。IEEE。ISBN 978-0-7695-2330-9。
  • イアン・サマービル（2010）。ソフトウェア工学（第7版）。ピアソン教育。ISBN 978-81-7758-530-8。2013年1月10日取得。

さらに読む

外部リンク

Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_engineering&oldid=1073627440"