ソフトウェア開発はエンジニアリングの分野ですか？
ソフトウェア開発はエンジニアリングと見なすことができますか？いいえの場合、エンジニアリング分野としての資格を得るために欠けているものは何ですか？これに関連するのは プログラマーとソフトウェアエンジニアの違いに関するスタックオーバーフローに関するこの質問 です。
カーニギーメロン大学には、CMMI標準を規定および維持するソフトウェア工学研究所があります。これは開発をエンジニアリングに変えるものですか？
ソフトウェア開発エンジニアリングですか？いいえの場合、資格を得るために欠けているものは何ですか？
はい、ソフトウェアエンジニアリングはエンジニアリング分野です。
ウィキペディアでは、エンジニアリングを「数学の応用と、構造、機械を発明、革新、設計、構築、維持、研究、改善するための科学的、経済的、社会的、実用的な知識として、ツール、システム、コンポーネント、材料、プロセス、ソリューション、および組織。」 ソフトウェアエンジニアリングの結果は、人々の生活を改善できるソフトウェアシステムであり、科学的、数学的、経済的、社会的、または実践的な知識。
学問的および専門的にどのように見られるかという点では、状況はさまざまです。ソフトウェアエンジニアリングプログラムは、エンジニアリングプログラムとして [〜＃〜] abet [〜＃〜] によって認定されます。ソフトウェアエンジニアはIEEEのメンバーになることができます。ソフトウェアエンジニアリングをエンジニアリング分野と見なしている企業もあれば、そうではない企業もあります。
このテーマに関する最良の本は Steve McConnellのプロフェッショナルソフトウェア開発です：スケジュールの短縮、高品質の製品、より成功したプロジェクト、キャリアの向上 。ソフトウェアエンジニアリングを職業、クラフトから職業への進化、ソフトウェア開発の科学、ソフトウェアエンジニアリングとソフトウェアengineering（エンジニアリング手法をソフトウェアに適用することと、偶然にソフトウェアを構築するエンジニアに適用すること、 my alma mater ）、認証とライセンス、および倫理。
Glenn Vanderburgは、「Real Software Engineering」と呼ばれる一連の講演 を行っています。これは、2010年から2015年の間に多くの会議で開催され、関連する2つの講演「Craft、Engineering、そして「プログラミングの本質」（2011年にRailsConfで基調講演として与えられた）と「クラフトとソフトウェアエンジニアリング」（2011年にQConロンドンで与えられた）。これらの講演は、ソフトウェアエンジニアリングがエンジニアリングの分野である理由についてのかなり包括的な議論だと思います。
ヴァンダーバーグが彼の会談で簡単に取り上げた1つの議論は、ソフトウェア設計とは何か、コードがソフトウェアの出力である方法について、1992年に ジャック・W・リーブスによって（そして2005年に再び見直されて）なされたものです工学設計活動 （ これはC2 wiki でも議論されています）。仕様とモデリングがソフトウェア設計であり、コードがソフトウェア設計である古い考え方から離れると、ソフトウェアエンジニアリングと他のエンジニアリング分野との関係の一部がより容易に明らかになります。ソフトウェア開発の経済性が他の多くの分野と大きく異なることを確認すると、いくつかの違いとそれらの違いの理由がさらに明らかになります-設計は安価ですが（多くの場合、ほとんど無料）、デザインは高価な部分です。
それは[CMMI]開発をエンジニアリングに変えるものですか？
いいえ。CMMIは、ソフトウェアを構築するときにどのような種類の活動が役立つかについて組織にガイダンスを提供するプロセス改善フレームワークです。エンジニアリング分野には通常、エンジニアリングプロセスがあります。このようなプロセスを持つことは、高品質のプロジェクトを成功させるために重要です。つまり、CMMI（または他のプロセスフレームワークや方法論）は単一のツールにすぎません。それを使用しても、開発者からエンジニアに魔法のように進歩することはありません。しかし、私の考えでは、ある種のプロセスに従わないことは、エンジニアリングプロジェクトではないプロジェクトの兆候です。
また、ソフトウェアエンジニアリングのコース/証明書についてはどう思われますか？
それは他の人々がそれに入れたのと同じくらいの価値です。便利な講座と役に立たない講座があります。貴重な証明書と、それらが印刷された紙に値しない証明書があります。誰がコースを承認または認定しているのか、誰が現在の雇用業界に現在の仕事でどこに行きたいのかなどの証明書を発行しているのかなど、多くの要因があります。
典型的なエンジニアリングの背景から来ていますが、ソフトウェア開発でキャリアを積んでいる私は、両方の世界の間に大きな類似点があると思います。エンジニアリングの正確な定義とは別に、実際には、ソフトウェアの開発は物理的な製品の開発とそれほど変わらないと思います。少なくとも私はそれはそれほど違ってはいけないと思います。
航空機を設計する場合でも、ソフトウェアアプリケーションを設計する場合でも、どちらの場合も次のことを行う必要があります。
- デザインを作る
- サブシステムとコンポーネントを定義する
- プロトタイプを作る
- テストを指定して実行する
- 等.
プログラミングを始める前にすべてを設計するわけではないため、ソフトウェアの設計は異なるという別の答えをどこかで読みました。まあ実際はそれほどではありませんが、物理的な製品を設計するときもそうです。設計、プロトタイピング、テストは反復的なプロセスです。
また、ソフトウェアプロジェクトのサイズが大きくなると、航空機などの複雑な製品の設計と同様に、明確なサブシステム、コンポーネント、インターフェースを定義することがより重要になります。
そのため、ソフトウェアの開発はエンジニアリングであると考えています。
確かにソフトウェア工学のようなものがあると私は主張します。
エンジニアリングには、問題の解決への科学的知識の体系的な適用が含まれます。今日取り組んでいる問題の複雑さは、回路を作成する際の電気エンジニアや、製造プロセスを考案する際の化学エンジニアやデバイスの作成における機械エンジニアが取り組む問題とそれほど変わりません。
既存の計画（この場合は開発）を適用する実践的なアプローチもあるという事実は、他の分野で他の誰かがそれらの計画を実行するという事実（たとえば、建設作業員）に単純に似ています。
ほとんどの開発者がソフトウェアエンジニアリングの仕事も担っていることは事実です。私たちの教育は、プログラミングではなくソフトウェアエンジニアリングであることがよくあります。土木技師はそうではないので、私たちは手を汚します。
ただし、プログラミング言語とプログラムを適用できるからといって、エンジニアになることはできません。現在のコード以外の複雑さと問題について真に理解していない開発者たちと出会いました。
CMUに関する質問について：標準またはプラクティス（CMMIなど）を適用しても、個人の作業が自動的にエンジニアリングに変わるわけではありません。しかし、科学的研究を行って新しい実践を提供している組織があるという事実は、エンジニアリングのようなものがあることの兆候です。
いいえ、それはエンジニアリングではありません。私たちはそれほど科学的ではないので、これらの国家工学試験に合格する必要はありません。実際、テストが不足しているため、一部の場所でソフトウェアを「エンジニア」と呼ぶのは違法です。
私見では、「ソフトウェアエンジニアリング」という用語は、単に「プログラマ」（思考や創造性のないいくつかの機械的なプロセスの含みがある）ではなく、開発者が行うことの範囲をよりよく説明するために作られたものです。
個人的には、とりわけ実用的なプログラマーによって擁護された「職人」としての開発者の新たなアナロジーを好みます。
歴史的に、人々はソフトウェアの作成と製造を類比しようと試みてきました。 Jack Reevesは彼の記事でこのアイデアを信用しないようにかなり良い議論をしたと思います ソフトウェアデザインとは 。
Wikiから：
エンジニアリング：
ソフトウェアエンジニアリングは、ソフトウェアの開発、運用、保守への体系的で規律のある定量化可能なアプローチの適用と、これらのアプローチの研究です。つまり、ソフトウェアへのエンジニアリングの適用です。
ソフトウェア開発
ソフトウェア開発は、ソフトウェア製品をもたらす一連の活動です。ソフトウェア開発には、研究、新しい開発、変更、再利用、リエンジニアリング、メンテナンス、またはソフトウェア製品をもたらすその他の活動。[1]
特に、ソフトウェア開発プロセスの最初のフェーズには、マーケティング、エンジニアリング、研究開発、および一般管理を含む多くの部門が関与する場合があります。
したがって、それらはかなり類似しており、同じことを意味することもあります。
Dictionary.comから： en・gi・neer・ing /ˌɛndʒəˈnɪərɪŋ /
–名詞1.エンジン、橋、建物、鉱山、船、および化学プラントの建設のように、物理学または化学として純粋科学の知識を実用化する芸術または科学。
ソフトウェアの作成は数学とコンピュータサイエンスの実用的なアプリケーションであり、アプリケーションに応じて他の多くの純粋な科学の潜在的なアプリケーションであると言えるでしょう。
[編集] FWIW、私は自分自身をソフトウェアエンジニアと呼ぶのではなく、ソフトウェア開発者と呼んでいます。
私の見解では、ソフトウェアエンジニアとソフトウェア開発者は2つの異なるものです。
software engineerは、開発にどのようなライフサイクルが必要か、要件/仕様を作成するなど、計画を立てている人だと思います...基本的に、ソフトウェアエンジニアは多くのドキュメントを扱います。これは、ソフトウェア開発者またはプロジェクトマネージャー、あるいはその両方によって実行できます。
ソフトウェア開発者は、プログラマーとより密接に関連しますが、データベース管理などの他の分野でより多くのスキルを持っています。
興味深いのはArchitectureです。プロジェクトのライフサイクルに必要なハードウェア/ソフトウェアの解明にも関与している人。
ここでは「いいえ」で行きます。私の兄は機械技師であり、エンジニアリングを「安っぽい芸術」と表現しています。
「エンジニアは、可能な限り最小のコストで、可能な限り迅速に物事を成し遂げることに関心を持っています可能な限り少ない材料で。 "
反応として、私はソフトウェア開発（ソフトウェアエンジニアリングではなく、実際には基本的に2つの異なる分野です）を「効率的なアート」として説明しました。
「開発者は可能な限り最小限の繰り返しで]可能な限り最短のコストで可能な限り速く物事を成し遂げることに関心があります。 "
違いは、これらの文の最後の部分です。
ソフトウェア開発エンジニアリングですか？
いいえ。エンジニアであるということは、プロジェクトが因果関係のタイムラインに従うということです。つまり、建築基準法に従うので、建物は転倒しません（または、転倒しても非難されません）。ソフトウェアを作成する場合は、すべてのガイドラインに従うことができ（選択できるものは非常に多いので！）、それでもハング/クラッシュ/間違った答えを出す可能性があります（ただし、サイドで証明可能なプログラムを書くという非常に小さな分野に関与している場合を除きます） -効果のない関数型言語）。
私は、エンジニア（機械的、構造的、ソフトウェア）を、理解されたニーズと、そのニーズに対応するために何をどのように材料を適用するかについての理解に基づいて事前に製品を設計する人物だと考えています。
たとえば、構造エンジニアが鋼のさまざまな強度を調べ、物理学の規則を適用して必要な材料を計算し、それらをどのように実装するかをよく見かけます。構造工学は、ビルドする前に、ビルドするものの青写真（仕様）を常に持っているので、典型的な例です。これは、ソフトウェアで常に発生するわけではありません。
私にとってソフトウェアエンジニアとプログラマーの違いは、エンジニアがコードを書く前に何を生成するかの仕様を作成できることです。プログラマーは、誰か他の人の仕様に基づいてコードを書くか、またはそれらの1つです。仕様なしでコードを書く野生の西のプログラマー。同様に、エンジニアは彼の学位を持っています。
建設労働者と構造エンジニアの違いを、プログラマーとソフトウェアエンジニアの違いに例えます。
分かりやすく言うと、私は大学の卒業証書しか持っていないので、自分をエンジニアと呼ぶことはできません。
「エンジニアリング」という用語は、2つの主な理由から、ソフトウェア開発を説明するのに最も適切であるとは考えません。
それは、産業、土木、海軍、または機械工学などの伝統的な工学分野に由来する多くの古いアイデア、概念、およびいわゆる「ゴールデンルール」を伝えます。私は労働部門、生産プロセス、品質基準のルールについて話しています...これらは、ほとんどの場合、ソフトウェアにのみ適用されますわずかに。
プログラミングが他の分野よりも優れている（そして私はそれがはるかに大きく異なっていると私は信じている）と、従来の対応するものと比較して開発者が日々直面しなければならない新しい課題を満足のいく方法で説明できませんenineeringドメイン。ソフトウェアの仮想的で重要でない性質は、その中で大きな役割を果たします。
ソフトウェア開発は、長い間「単なる別のエンジニアリング分野」と見なされてきました。計測されて以来、私たちが知っているソフトウェアプロジェクトの失敗率を考えると、開発はまったく新しい動物であると認識し、まったく特別な素材であるコードとアプリケーションライフサイクルをまったく異なる種類の生産サイクルとして認識し、必死に試すのをやめる必要があります。それらに古いレシピを適用します。
はい、標準と原則を適用してまともな製品に到達できるはずです。困難なのは、クライアントの考え方（コードだけです。変更にそれほどコストはかかりません）、製品がマシンコード（音声/記述言語）に何をすべきかをコード化し、数値化するのが非常に難しいことです。品質"。あなたの品質の定義は私のものではありません。
また、再現性もあります。一連の要件を取り、それを2つのチームに割り当てます。同じことを（チームが互いに話さなくても）できる場合、エンジニアリングにかなり近づいています。
エンジニアリングの他の領域にもペナルティがあり、厳格なレビューとサインオフがあります。説明責任。
いいえ。ソフトウェアエンジニアリングはエンジニアリングではありません。私の意見では、違いは関与する創造性の量にあります。たとえば、土木工学では、創造性がほとんどないか、まったくない場合があります。これは良いことです。
橋を建設するには、一連の仕様があります（この数の車を川の向こう側から反対側まで取得する必要があります）。
これから、私は推測することができます：
- 私が必要とする道路の車線の数（政府が定義した標準計算を使用）。
- サポートする必要がある負荷（政府が定義した計算を使用）
- これらの負荷をサポートするために使用する必要がある材料（さまざまなサプライヤーから入手できる標準的な材料、または非標準的な材料を使用して、それらが正しい特性を持っていることを証明する必要がある）。
次に、設計を承認し、サードパーティ（別の会社）がチェックして、計算が正しく行われたことを確認する必要があります。
次に、実際に橋が建設されると、資格のある人が標準的な方法で作業を行います。彼らは何百、何千回も前にやったことのある仕事をするでしょう。
誤解しないでください、すべての土木工学プロジェクトは異なりますが、新しいアプリケーション/ウェブサイトを開発するたびに、物事は異なる方法で行われるようです。
ソフトウェア開発はエンジニアリングです。
ソフトウェアエンジニアリングがエンジニアの基準を満たさない理由について、他の人が行ったいくつかの議論：
エンジニアは公益のための「もの」を設計するビジネスに従事していると言う人もいます-ICBM、タンクなどは公益ですか？一部の人は「はい」と言います（良い攻撃は良い防御です）他の人は「いいえ」と言います。しかし、次世代の戦車ターゲティングシステムを設計する人がエンジニアであることに誰もが異議を唱えることはないと思います。公益は主観的である場合があります。とにかく、多くのソフトウェアが公益にあるので、どちらにしても意味がありません。
他の人たちは、エンジニアは彼らが構築しないように設計すると言います。 「機械エンジニアは溶接しない」タイプのコメントをいくつか見ました。機械エンジニアは設計図、つまりsomething elseが実装する詳細設計を生成すると主張します。機械エンジニアが設計図を作成し、それをCNCマシンに送ると、機械エンジニアではなくなります。人ではなくマシンが実装を行ったからでしょうか。ソースコードは、実装を行うマシンに供給される詳細な青写真であり、CNCマシンへのMechE供給コードとの違いを理解できていません。そして今、私たちは3Dプリンターを持っていますが、それは機械エンジニアの終わりを意味していますか？彼らは現在機械開発者ですか？
ライセンスは、私が目にするもう1つのトピックです。現在、ソフトウェアエンジニアにライセンスを付与している管轄区域はごくわずかです。 （これまでのところ）ソフトウェアエンジニアの米国全体でのライセンスはありません（私はテキサスだけがそうだと思います）。ソフトウェアエンジニアリングをエンジニアリングと呼ぶべきではないと述べる理由としてこれを使用する人もいます。ソフトウェアエンジニア向けのPEが登場します。しかし、一部の州議会議員がソフトウェア開発エンジニアリングを呼び出すことを選択したかどうかにかかわらず、より哲学的なレベルでは、現実に影響を与えません。
はい、開発はエンジニアリングのサブセットだと思います。
- ソフトウェアエンジニアリングには最初の仕様（「ここでは、どのようなソフトウェアが必要ですか？」）が含まれています。
- 「エンジニアリング」には、たとえば品質保証プロセスの定義。これは確かに開発に関連していますが、間違いなく「構築」自体の範囲外です。
Code Completeは、「構築」を、コーディングとデバッグ（およびコメント）と同義であり、事前の詳細な設計と、ユニットおよび統合でも同義であると定義しています。その後のテスト。 第1章、ソフトウェア構築へようこそ（PDF） は、ソフトウェア開発ライフサイクル全体の多くのトピック（問題定義、ソフトウェアアーキテクチャ、修正保守など）をリストすることから始まり、
図が示すように、構築はほとんどがコーディングとデバッグですが、詳細な設計、構築計画、単体テスト、統合、統合テスト、およびその他のアクティビティも含まれます。もしこれがソフトウェア開発のすべての側面についての本なら、それは開発プロセスにおけるすべての活動のうまくバランスのとれた議論を特徴とするでしょう。ただし、これは建設技術のハンドブックであるため、建設に偏った重点を置き、関連するトピックにのみ触れます。この本が犬である場合、それは構築までこすり、設計とテストでその尾を振る、そして他の開発活動で吠えるでしょう。