翻訳 第6, 7章 : Software engineering - Wikipedia

6 Related fields 関連分野

Software engineering is a direct sub-field of engineering and has an overlap with computer science and management science[citation needed]. It is also considered a part of overall systems engineering.

ソフトウェア工学は工学の直接的な下位の分野でコンピュータサイエンスと経営科学と部分的に一致する。システム工学の一部を共有するとも考えられる。

6.1 Computer Science　コンピュータサイエンス

In general, software engineering focuses more on techniques for the application of software development in industry,[43][44] while computer science focuses more on algorithms and theory.[45]

一般的に、ソフトウェア工学では産業へソフトウェア開発を応用するための技術に重点を置いている。一方でコンピュータサイエンスはアルゴリズムと理論と重点を置いている。

7 Controversy　論争

7.1 Criticism　批判

Software engineering sees its practitioners as individuals who follow well-defined engineering approaches to problem-solving. These approaches are specified in various software engineering books and research papers, always with the connotations of predictability, precision, mitigated risk and professionalism. This perspective has led to calls for licensing, certification and codified bodies of knowledge as mechanisms for spreading the engineering knowledge and maturing the field.

ソフトウェア工学は上手に定義された問題解決への工学的なアプローチを追求した個々の集まりとして見られる。これらの方法は様々なソフトウェア工学の本、研究論文で明記され、常に予測性、正確さ、リスクの軽減、専門家の技術を含んでいる。この観点からエンジニアリングの知識を広めて分野を成熟させるメカニズムとしてのライセンス、証明書、知識体系を必要とする。

Software craftsmanship has been proposed by a body of software developers as an alternative that emphasizes the coding skills and accountability of the software developers themselves without professionalism or any prescribed curriculum leading to ad-hoc problem-solving (craftmanship) without engineering (lack of predictability, precision, missing risk mitigation, methods are informal and poorly defined). The Software Craftsmanship Manifesto extends the Agile Software Manifesto[46] and draws a metaphor between modern software development and the apprenticeship model of medieval Europe.

ソフトウェアクラフトマンシップは専門家の技術やエンジニアリングなしで（予測性、正確性の欠落、リスク軽減の失敗、非公式で十分に定義されていないメソッド）アドホックな問題解決（クラフトマンシップ）を導く定められたカリキュラムもなくコーディングスキルとソフトウェア開発者の責任性を強調する代替案としてソフトウェア開発者の大勢によって提案された。ソフトウェアクラフトマンシップはアジャイルを拡張して現代的なソフトウェア開発と中世ヨーロッパの見習いモデルの間のメタファーを描いた。

Software engineering extends engineering and draws on the engineering model, i.e. engineering process, engineering project management, engineering requirements, engineering design, engineering construction, and engineering validation. The concept is so new that it is rarely understood, and it is widely misinterpreted, including in software engineering textbooks, papers, and among the communities of programmers and crafters.

ソフトウェア工学は工学を拡張して工学モデル、つまり、エンジニアリングプロセス、エンジニアリングプロジェクトマネジメント、エンジニアリング構築、エンジニアリングの確認にもとづいて作られている。新しい概念であるため滅多に理解されず、ソフトウェア工学の教科書、論文、さらにはプログラマーのコミュニティーのなかなど、広く誤解されている。

One of the core issues in software engineering is that its approaches are not empirical enough because a real-world validation of approaches is usually absent, or very limited and hence software engineering is often misinterpreted as feasible only in a "theoretical environment."

ソフトウェア工学の中心的な問題の一つはそのアプローチが現実世界で正当性があるのかは通常はぼんやりとしているか、とても限られていて、それゆえにソフトウェア工学はしばしば「理論的な環境」でのみ適すものとして誤解されるので経験的で十分ではない。

Edsger Dijkstra, the founder of many of the concepts used within software development today, refuted the idea of "software engineering" up until his death in 2002, arguing that those terms were poor analogies for what he called the "radical novelty" of computer science:

今日のソフトウェア開発で数多く使われる概念の考案者である、Edsger Dijkstraは彼が2002年までに「ソフトウェア工学」がコンピュータサイエンスの「ラディカルな新しさ」と呼ばれるものの安易なアナロジーであると主張して考えの誤りを指摘した。

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."[47]
これらの多くの現象が「ソフトウェア工学」の名のもとにまとめられてしまった。経済学が「不十分な科学」として知られるように、ソフトウェア工学も「不運な学問」として知られるべきだ。目標が自己矛盾しているために目標に近づくことすらできないからだ。もちろんソフトウェア工学は別の価値があると主張するがそれはでたらめだ。もしその主張を注意深く読み支持者が実際にしていることを分析すれば、ソフトウェア工学が「できないときにどうやってプログラムするか」という憲章として受け入れられていることを発見するだろう。

 

 

  • この記事は、コンピュータサイエンスに関する技術および英語についての正確な知識のない翻訳者が個人的な勉強を目的として、ほぼ全てを意訳によって翻訳したために、極めて多くの誤訳が含まれていると想定される決して質が高いとは言えない文章を公開しているものです。ここに掲載されている情報を使用したことによる、読者の方または第三者に生じる損害および損失について、翻訳者は一切の責任を負いません。正しい情報が必要な場合は原文を参照してください。