ソフトウェア工学
ソフトウェア工学（ソフトウェアこうがく、英語: software engineering）はソフトウェアを対象とした工学である。すなわち、有用なソフトウェアが持つ特性・構造を探り、その構築・維持・管理に有用なプロセスを見出す学問である。
概要
[編集]ソフトウェア工学はソフトウェアの開発・運用・保守に関して体系的・定量的にその応用を考察する分野である[1]。ソフトウェア工学は「工学」であり、ソフトウェアの信頼性・保守性・開発効率の向上などを目的とする[2]。
ソフトウェア工学には、設計法と生産法の2領域がある。設計法はソフトウェア構造（ソフトウェアアーキテクチャ）を扱う。ソフトウェア生産法はソフトウェアライフサイクルプロセスを扱う。これら二つの領域は利点と制約の面で相互関係がある。
ソフトウェア工学には、要求分析、ソフトウェア設計、プログラミング、ソフトウェアテスト、ソフトウェア保守といった作業に関する知識・ツール・手法が含まれる[3]。ソフトウェア工学に関連する学問分野として、コンピュータ科学、コンピュータ工学、経営管理論、数学、プロジェクトマネジメント (ソフトウェアプロジェクト管理) 、品質管理、人間工学、システム工学がある[4]。また、他分野とクロスオーバーしていたり、もしくはソフトウェア工学の1分野だったものが独立して別分野を形成したり（例：データベース設計）、別分野で培われた技術や概念がソフトウェア工学の対象となることもある（例：オブジェクト指向技術）。
software engineering という用語は Brian Randell (英語版) が考案し、1968年の NATO ソフトウェア工学会議 で F.L. Bauer (英語版) が使ったことで一般に広まった[5]。
構造
[編集]人が臓器からなるように、ソフトウェアもコンポーネントからなる構造をもつ。この構造をソフトウェアアーキテクチャという。デザインパターン/アンチパターンはアーキテクチャより詳細度の高い構造である。またプログラミングの指針をプログラミングパラダイムという。パラダイムは結果として構造に影響を与える。例えば構造化プログラミング、オブジェクト指向プログラミングが挙げられる。
ライフサイクル
[編集]ソフトウェアは生まれ、仕事をして、死ぬ。すなわち構想から廃止までの漸進的な発展、ライフサイクル[要曖昧さ回避]（英語: life cycle）を持つ[6]。ライフサイクルをプロセスとして認識したときによく見られるライフサイクルの型をライフサイクルモデル（英語: life cycle model）という[7]。ライフサイクルを構成するプロセスはライフサイクルプロセス（英語: life cycle process）と呼ばれる[8]。
例えばライフサイクルプロセスはしばしば「開発・運用・保守」に分けられ、そのうち開発プロセスはよく研究がなされている。開発プロセスモデルの例には、要求分析からテストまで順次1つずつおこなうウォーターフォール・モデル、開発期間を短く分け短期間に各開発工程を行いそれを繰り返すスパイラル・モデルが挙げられる。
ソフトウェアライフサイクルを定義する規格にはISO 12207がある。
方法論
[編集]ソフトウェアシステムをより良くする様々な方法論（英: methodology）がソフトウェア工学として研究されている。ライフサイクルごとの方法論や、アーキテクチャ実現に関する方法論などがある。特定の設計を採用しそれが開発プロセスと強くリンクするような方法論も当然存在する。オブジェクト指向開発方法論、ドメイン駆動設計がその例である。
設計方法論
[編集]ソフトウェアがより良い構造をもつための様々な方法論が研究されている。規格としてはUMLが挙げられる。
開発方法論
[編集]ソフトウェアライフサイクルプロセスの1つである開発プロセスをより良く進めるための方法論・その研究をソフトウェア開発方法論という。方法論（良くする方法）であり、典型的なパターンを見出しモデル化する分野とは区別される。
プロセスに着目した方法論には、ウォーターフォール・モデルに従うウォーターフォール開発、スパイラル・モデルに従う反復型開発、アジャイルソフトウェア開発などが挙げられる。 アジャイルソフトウェア開発のいくつかの開発手法（エクストリーム・プログラミングなど）では、例えばコーディング前に（あるいは同時に）テスト用のコードを書き、コーディングはそのテストに通過することを目標にして行う（テスト駆動開発、テストファースト）など、順序や各工程の意味づけを大きく変更している。ライフサイクル全体のマネジメント規格にはCMM/CMMI、ISO9001、ISO 12207、SLCP、IEEEソフトウェア規格、ファンクションポイント法、PMBOK、ISBOK、ISO/IEC9126などがある。
開発プロセスと運用プロセスの統合を目指す分野・方法論にはDevOpsがある。
主な研究分野
[編集]- ソフトウェア解析
- プログラム意味論
- ソフトウエア検証論
- ソフトウエア開発環境
ソフトウェア工学の曖昧性と論争
[編集]ソフトウェア工学の典型的な定義として、以下のようなものがある。
- 「ソフトウェアの開発・運用・保守に体系的・学問的・定量的手法を応用する分野」[9]
- 「ソフトウェア開発のあらゆる面を扱う工学分野」[10]
- 「実際の機械上で機能する信頼性のあるソフトウェアを経済的に得るための確かな工学原則の確立と利用」[11]
ソフトウェア工学が工学であるかの議論
[編集]software engineering という英語の場合、必ずしも工学の一分野を指すわけではなく、以下のような用法もある。
- 元々、プログラミングおよびシステム分析と呼ばれていた活動などを総称的に software engineering と呼ぶ[12]。
- プログラミングに必要とされる理論的側面をコンピュータ科学と呼び、そうでないあらゆる面を software engineering と称する[13]。
- 「プログラミング」を単なる技巧や技能ではなく工学として扱うことを主張する用語であり、そのような指針を文書化したもので使われる[14]。
software engineering は、ある種の学問的訓練、専門教育が必要であり、それにはソフトウェア開発には必ずしも使われないものも含まれるとする人もいる。よく言われる喩えとして、建築に携わる全ての人が建築学者ではないのと同様、ソースコードを書く人が常にソフトウェア工学者とは限らない。また、カナダの Professional Engineers Ontario という団体は、software engineering という呼称自体に反対している。すなわち、ソフトウェア開発は工学と呼ぶには未成熟で、それに携わる人々はプロのエンジニアとは呼べないという[15]。
「ソフトウェア工学」を工学の一分野としてどう定義するかは、人によって異なり、論争が行われてきた。デイビッド・パーナスは、ソフトウェア工学は実際に工学の一形式であるとした[16][17]。スティーブ・マコネルは工学ではないとしたが、工学へと進化すべきだと主張した[18]。ドナルド・クヌースは、プログラミングは技であり科学だとした[19]。エドガー・ダイクストラは、software engineering と software engineer という用語が特にアメリカ合衆国で誤用されていると指摘した[20]。
ソフトウェア工学はコンピュータ科学であるかの議論
[編集]ソフトウェア工学が工学であるとした場合、ソフトウェア工学がコンピュータ科学の一分野であるか、という命題も長年の議論の対象となっている。
ソフトウェア工学はコンピュータ科学の一分野であると信じている者もいる。コンピュータ科学が数理論理学や計算複雑性理論などを含む計算全般を扱う学問であるのに対して、ソフトウェア工学はあくまで実用目的でコンピュータ処理を設計するものであり、異なる分野であると考えている者もいる。
ソフトウェア工学はコンピュータ科学でない、という意見の中には、科学か否か以前に、ソフトウェア工学はそもそも工学としての性質すら全く持っていないという考えさえある。
デイビッド・パーナスは「私はソフトウェア工学をコンピュータ科学の一分野としてではなく、土木工学、機械工学、化学工学、電気工学などなどの要素を組み合わせたものとして扱う」としている[21]。
歴史
[編集]1949年のEDSACにおいて既に、ローダが初歩的なアセンブラの機能を備えていたことが知られる[22]。1950年前後には、EDSACやEDVACといった初期のコンピュータにおけるプログラミングについて文献が公刊され、初歩的なプログラミング手法が知られるようになった。言語としては、直接バイナリで機械語を記述する煩雑さから、すぐにアセンブリ言語が生まれた。1950年代中ごろには Autocode、FORTRAN、LISPといった初期の高水準言語があらわれた。プログラミング言語の実用性を疑う向きも多かったことから、IBMが開発したFORTRANコンパイラは、初めての試みであるにもかかわらず、生成コードの最適化のために多大なコストが掛けられ、結果としてプログラミング言語の有効性を納得させた。
software crisis（日本語訳は「ソフトウェア危機」）というフレーズは、1968年に開催されたNATO Conference on Software Engineeringで現れたものとされている。
1970年代になると、UNIX、コードリポジトリ、make などの協調的ソフトウェアツールが登場する。1980年代、パーソナルコンピュータが登場し、急速に広まり、市販ソフトウェアも大量に販売されるようになっていった。Smalltalk-80が公開され、オブジェクト指向が新たなパラダイムとして徐々に注目されていった。1990年代になると、オブジェクト指向プログラミング、アジャイルソフトウェア開発、エクストリーム・プログラミングが徐々に主流になっていった。2000年代になると、Java、Ruby、Python、PHP といったインタプリタベースの言語や .NET Framework の マネージコード などが多用されるようになった。
ソフトウェア工学の最近の傾向
[編集]ソフトウェア工学はまだ若い分野であり、今も発展し続けている。最近のソフトウェア工学の重要な傾向を以下に示す。
- アスペクト指向プログラミング
- ソースコードの様々な場所に定型的コードを追加・削除するツールを提供することで、品質を高める支援をする。アスペクトには、あらゆるオブジェクトや関数が特定の状況でどう振舞うべきかを記述している。例えば、アスペクトを使って、特定の型の全オブジェクトにデバッグ機能、ロギング機能、ロック機能などを追加できる。現在は、アスペクトを使って汎用コードを設計する方法の研究が進んでいる。関連する概念として、自動プログラミングやテンプレートがある。
- アジャイルソフトウェア開発
- 目まぐるしく変化する市場に素早く対応できるソフトウェア開発の手法。この手法の信奉者は、従来型の文書を多用する手法は徐々に消えていくと信じている。関連する概念として、エクストリーム・プログラミングやリーンソフトウェア開発がある。
- 実証的ソフトウェア工学
- ソフトウェア上で実験を行うことを重視する分野。実際の，もしくは実験的なソフトウェア開発作業やその開発履歴からデータを収集および分析し、そこから法則や理論を導き出そうとする。この手法の信奉者は、実用的な知見を得るためには、現実に存在するソフトウェアやその開発作業に対して手法を適用しその結果を評価することが必要であると考えている。
- DevOps
- 開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）ソフトウェア開発の手法。ソフトウェアを迅速にビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻繁で可能とする組織体勢の構築を目指している。さらにDevOpsとセキュリティ（Security）を融合させるDevSecOpsに発展している。
- モデル駆動工学
- 設計段階でテキストと図を使ったモデルを構築する。モデル変換やコード生成のツールを使って、モデルからコードの断片を抽出し、その後の開発に役立てる。
- ソフトウェアプロダクトライン
- 一連のソフトウェア製品群を体系的に構築する手法。コードの再利用を発展させ、ソフトウェア開発工程を工業化しようとする試み。
出典
[編集]- ^ “IEEE Standard Glossary of Software Engineering Terminology,” IEEE std 610.12-1990, 1990, quoted at the beginning of Chapter 1: Introduction to the guide “Guide to the Software Engineering Body of Knowledge” (February 6, 2004). 2008年2月21日閲覧。
- ^ Pecht, Michael (1995年). Product Reliability, Maintainability, and Supportability Handbook. CRC Press. ISBN 0-8493-9457-0
- ^ Table 1 in Chapter 1,“Guide to the Software Engineering Body of Knowledge” (2004年2月6日). 2008年2月21日閲覧。
- ^ Table 2 in Chapter 1,“Guide to the Software Engineering Body of Knowledge” (2004年2月6日). 2008年2月21日閲覧。
- ^ Dijkstra, Edsger W; transcribed by Mario Béland (1993年12月3日; transcription last revised 2004年11月23日). “There is still a war going on (manuscript Austin, 3 December 1993)”. E. W. Dijkstra Archive. The University of Texas at Austin, Department of Computer Sciences. 2007年2月17日閲覧。 “When the term was coined in 1968 by F.L. Bauer of the Technological University of Munich, I welcomed it.”
- ^ "ライフサイクル（life cycle）システム，製品，サービス，プロジェクト又は人が作った他の実体の構想から廃止までの漸進的な発展。… 全てのソフトウェアシステムにはライフサイクルがある。" JIS X 0160:2021
- ^ "ライフサイクルモデル（life cycle model）段階に編成されることもあるライフサイクルに関係するプロセス及びアクティビティの枠組み" JIS X 0160:2021
- ^ "ライフサイクルプロセスと呼ばれる，システムのライフサイクルの定義に使用できる，一まとまりのプロセスの集合" JIS X 0160:2021
- ^ “IEEE Standard Glossary of Software Engineering Terminology,” IEEE std 610.12-1990, 1990.
- ^ Sommerville, Ian (2007年) [1982年]. “1.1.2 What is software engineering?”. Software Engineering (8th ed. ed.). Harlow, England: Pearson Education. pp. P. 7. ISBN 0-321-31379-8. "Software engineeering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use. In this definition, there are two key phrases:
1. Engineeering discipline Engineers make things work. They apply theories, methods and tools where these are appropriate [. . .] Engineers also recognise that they must work to organisational and financial constraints. [. . .]
2. All aspects of software production Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, methods and theories to support software production." - ^ F. L. Bauer (1972年). “Software Engineering”. Information Processing (North-Holland Publishing Co.) 71: 530–538.
- ^ Akram I. Salah (2002年4月5日). “Engineering an Academic Program in Software Engineering”. 35th Annual Midwest Instruction and Computing Symposium. 2006年9月13日閲覧。: "For some, software engineering is just a glorified name for programming. If you are a programmer, you might put 'software engineer' on your business card—never 'programmer' though."
- ^ Mills, Harlan D., J. R. Newman, and C. B. Engle, Jr., "An Undergraduate Curriculum in Software Engineering," in Deimel, Lionel E. (1990年). Software Engineering Education: SEI Conference 1990, Pittsburgh, Pennsylvania, USA, April 2-3,.... Springer. ISBN 0-387-97274-9, p. 26: "As a practical matter, we regard software engineering as the necessary preparation for the practicing, software development and maintenance professional. The Computer Scientist is preparing for further theoretical studies..."
- ^ David Budgen, Pearl Brereton, Barbara Kitchenham, Stephen Linkman (2004年12月14日). “Realizing Evidence-based Software Engineering”. 2006年10月18日閲覧。: "We believe that software engineering can only advance as an engineering discipline by moving away from its current dependence upon advocacy and analysis...."
- ^ Sayo, Mylene, What's in a Name? Tech Sector battles Engineers on "software engineering" 2008年7月24日閲覧。
- ^ Parnas, David L. (1998年). “Software Engineering Programmes are not Computer Science Programmes”. Annals of Software Engineering 6: 19–37. doi:10.1023/A:1018949113292., p. 19: "Rather than treat software engineering as a subfield of computer science, I treat it as an element of the set, {Civil Engineering, Mechanical Engineering, Chemical Engineering, Electrical Engineering,....}."
- ^ Parnas, David L. (1998年). “Software Engineering Programmes are not Computer Science Programmes”. Annals of Software Engineering 6: 19–37. doi:10.1023/A:1018949113292., p. 20: "This paper argues that the introduction of accredited professional programmes in software engineering, programmes that are modelled on programmes in traditional engineering disciplines will help to increase both the quality and quantity of graduates who are well prepared, by their education, to develop trustworthy software products."
- ^ McConnell, Steve (2003年8月). Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers. Boston, MA: Addison-Wesley. ISBN 0-321-19367-9, p. 39: "In my opinion, the answer to that question is clear: Professional software development should be engineering. Is it? No. But should it be? Unquestionably, yes. "
- ^ Knuth, Donald (1974年). “Computer Programming as an Art”. Communications of the ACM 17 (12): 667–673. 1974年のチューリング賞講演
- ^ Dijkstra, Edsger W; transcribed by Mario Béland (1993年12月3日; transcription last revised 2004年11月23日). “There is still a war going on (manuscript Austin, 3 December 1993)”. E. W. Dijkstra Archive. The University of Texas at Austin, Department of Computer Sciences. 2007年2月17日閲覧。 “When the term was coined in 1968 by F.L. Bauer of the Technological University of Munich, I welcomed it. [. . .] I interpreted the introduction of the term “software engineering” as an apt reflection of the fact that the design of software systems was an activity par excellence for the mathematical engineer. [. . .]. As soon the term arrived in the USA, it was relieved of all its technical content. It had to be so for in its original meaning it was totally unacceptable [. . .] In the mean time, software engineering has become an almost empty term, as was nicely demonstrated by Data General who overnight promoted all its programmers to the exalted rank of “software engineer”!”
- ^ Parnas, David L. (1998年). “Software Engineering Programmes are not Computer Science Programmes”. Annals of Software Engineering 6: 19–37., p. 19
- ^ EDSAC#システムソフトウェアを参照
参考文献
[編集]- Jalote, Pankaj (2005年) [1991年]. An Integrated Approach to Software Engineering (3rd ed. ed.). Springer. ISBN 0-387-20881-X
- Sommerville, Ian (2007年) [1982年]. Software Engineering (8th ed. ed.). Harlow, England: Pearson Education. ISBN 0-321-31379-8
- Pressman, Roger S (2005年). Software Engineering: A Practitioner's Approach (6th ed. ed.). Boston, Mass: McGraw-Hill. ISBN 0072853182
- Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: Fundamentals of Software Engineering, 2nd (International) ed.: 2003 (1st ed.: 1991), Pearson Education @ Prentice-Hall
- Colin Hood,Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 354047689X
関連項目
[編集]- コンピュータ科学
- ソフトウェアプロジェクト管理
- ソフトウェアアーキテクチャ
- ソフトウェア開発
- 構造化プログラミング
- オブジェクト指向
- デザインパターン
- アスペクト指向プログラミング
- アジャイルソフトウェア開発
- エクストリーム・プログラミング (XP)
- ソフトウェアテスト
- 能力成熟度モデル統合 (CMMI)
- 人月の神話
- 銀の弾などない
- 銀の弾丸
- 伽藍とバザール
外部リンク
[編集]- Guide to the Software Engineering Body of Knowledge
- ICSE 2000、ICSE 2007
- Big Ball of Mud A "yes but why not" point of view by Brian Foote and Joseph Yoder, Department of Computer Science, University of Illinois at Urbana-Champaign
- A Student's Guide to Software Engineering Projects - a free online guide for students taking SE project courses
- ソフトウェア工学コース - 研究人材のためのe-learning（科学技術振興機構）
- 『ソフトウェア工学』 - コトバンク
| 分野 | |||||||
|---|---|---|---|---|---|---|---|
| コンセプト | |||||||
| 指向 | |||||||
| モデル |
| ||||||
| 主な人物 | |||||||
| 関連項目 | |||||||
| 分野 | |
|---|---|
| プロセス | |
| コンセプト | |
| 手法 | |
| 関連分野 | |
| 関連項目 | |
 | この項目は、ソフトウェアに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |
