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