Wikipedia

「ソフトウェア開発方法論」の版間の差分

情報システムの開発工程を構造化・計画・制御するフレームワーク
新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
Melan (会話 | 投稿記録)
25,487 回編集
en:Software development methodology（2013年3月23日 6:00:43(UTC)）の翻訳
(相違点なし)

2013年5月7日 (火) 00:47時点における版

ソフトウェア開発方法論またはシステム開発方法論は、ソフトウェア工学におけるフレームワークであり、情報システムの開発工程を構造化し、計画し、制御するのに使われる。SDM（software development methodology または system development methodology）と略記される。

歴史

ソフトウェア開発方法論 (SDM) のフレームワークが生まれたのは1960年代のことである。Elliott (2004) によれば、情報システム構築のための最古の定式化された方法論フレームワークはシステム開発ライフサイクル (SDLC) だという。SDLCの根幹をなすのは、情報システムを計画的に構造化された整然とした形で開発するには、アイデアの誕生から最終的なシステムの配備まで、適用するフレームワークの文脈の中で開発工程の各段階を着実に逐次的に実行しなければならないという考え方である[1]。1960年代におけるこの方法論フレームワークの主な対象は、巨大企業の大規模ビジネスシステム開発だった。当時の情報システムは多大なデータ処理と数値処理を中心としたものだった[1]。

フレームワークとしてのSDM

ソフトウェア開発方法論は、情報システムの開発工程を構造化し計画し制御するためのフレームワークであり、プロジェクトチームがアプリケーションの開発や保守のために作成・構築する成果物の事前定義なども含まれる[2]。

 
SDMのフレームワークに適用される3つの基本的技法

そうしたフレームワークは長年の間に様々なものが考案されてきており、それぞれに長所と短所がある。あるソフトウェア開発方法論フレームワークは、すべてのプロジェクトに適しているわけではない。技術的・組織的などの面を考慮すると、それぞれの方法論フレームワークにはそれぞれ適した種類のプロジェクトがある[2]。

そうしたソフトウェア開発フレームワークには、それをさらに発展させ、使用をサポートし、その方法論フレームワークの普及に努める組織が存在する。方法論フレームワークは、ある種の公式な文書で定義されることが多い。ソフトウェア開発方法論フレームワークの具体例としては、以下のものがある。

個々のSDM

SDMフレームワークを個々の組織やプロジェクトに適用する場合、具体的なソフトウェア開発方法論が使われる。年代順に次のようなものがある。

1970年代
  • 構造化プログラミング - 1969年から
  • Cap Gemini SDM - オランダのPANDATAという企業で生まれた。英語圏にもたらされたのは1974年。この場合のSDMは System Development Methodology の略である。
1980年代
1990年代

具体例

どのソフトウェア開発方法論も特定のフレームワークをソフトウェアの開発・保守に適用する際の基盤となる。情報技術の生まれたころから、いくつかのソフトウェア開発手法が使われてきた。主なものを以下に挙げる[2]。

  • ウォーターフォール - 直線的なフレームワーク
  • プロトタイピング - 反復的なフレームワーク
  • インクリメンタル - 直線的な要素と反復的な要素を組み合わせたフレームワーク
  • スパイラル - 直線的な要素と反復的な要素を組み合わせたフレームワーク
  • RAD - 反復的なフレームワーク
  • エクストリームプログラミング

ウォーターフォール

ウォーターフォール・モデルは逐次的な開発手法であり、要求分析・設計・実装・テスト（評価）・統合・保守と、水が低いところに流れていくように上流工程から下流工程へと順次移行していく。この手法を最初に定式化したのはウィンストン・W・ロイス（英語版）の1970年の論文とされているが[3]、ロイス自身は「ウォーターフォール」という用語をこの論文で使ってはいない。

基本原則は次の通り[2]。

  • プロジェクトは逐次的な工程に分けられ、工程間の若干の重なりと戻りは許容される。
  • 計画、スケジュール、日程、予算などを重視し、システム全体を一度に実装することを特徴とする。
  • 様々な文書を作成し、公式なレビューを行い、ある工程から次の工程へ移行する際にはユーザーまたはIT管理者による承認を必要とする。

ウォーターフォール・モデルは従来からの工学的手法をソフトウェア工学にそのまま適用したものである。大規模なプロジェクトで採用され、予算超過、納期遅延、要求仕様を満たさないものを生み出すなどして非難されてきた。契約条件にされた場合を除き、ウォーターフォール・モデルよりも柔軟な手法を採用することが多くなっている。

プロトタイピング

ソフトウェアプロトタイピングは、開発すべきソフトウェアの不完全なバージョンであるプロトタイプを（何度か）開発中に作成する開発手法である。

基本原則は次の通り[2]。

  • 単独で使える完備した開発方法論ではなく、他の開発方法論に加えて使用される。
  • 大型プロジェクトにつきもののリスクを低減させるため、プロジェクトを小さな部分に分割し、開発中の修正を容易にする手段を提供する。
  • プロトタイプはユーザーに提示するものであり、ユーザーが開発プロセスに長期的に関与することになる。そのため、最終的な実装をユーザーが受容しやすくなる。
  • プロトタイプに反復的に修正を加えていき、ユーザーの要求を満たすようにしていく。
  • プロトタイプは最終的に捨てられることが多いが、最終的なシステムがプロトタイプを発展させることで作られることもある。
  • プロトタイピングにより、開発者とユーザー間の根本的な誤解を早期に解決することができる。

反復型

反復型開発はプロジェクトを小さな部分に分割し、開発工程中の修正を容易にし、プロジェクトのリスクを低減させる。

基本原則は次の通り[2]。

  • ウォーターフォールを小規模に何度も繰り返す。一回のウォーターフォールはシステム内の小さな部分を完成させるものである。
  • 全体の要求仕様は反復を行う前に定義される。

スパイラル

 
スパイラルモデル

スパイラルモデルはトップダウン設計とボトムアップ設計のそれぞれの利点を生かしたもので、設計とプロトタイピングの工程を繰り返す手法である。これは一種のメタモデルで、他のモデルが利用することができる。

基本原則は次の通り[2]。

  • プロジェクトのリスクを最小化することを主眼としており、小さな部分に分割して開発工程での修正を容易にし、リスクの再評価の機会を提供し、プロジェクト継続の検討を可能にする。
  • 各サイクルは同じ一連の工程からなり、製品全体の概念を個々のプログラムのコーディングにまで落とし込み、一回のサイクルで1つの部分を完成させたり、全体の改良を施したりする[4]。
  • 1つのサイクルは、(1) その反復の目的・選択肢・制約の決定、(2) 選択肢の評価、リスクの識別と解決、(3) 具体的な開発とそのサイクルの成果物の評価、(4) 次の反復の計画立案、という4つに分けられる[5]。
  • 各サイクルは利害関係者と彼らの勝利条件の識別で始まり、レビューとコミットメントで終わる[6]。

RAD

RAD (Rapid Application Development) は、プロトタイプを反復的に開発・構築していくソフトウェア開発方法論である。本来は、1991年にジェームス・マーティン（英語版）が提唱したソフトウェア開発工程を指した言葉である。

基本原則は次の通り[2]。

  • 高品質なシステムを相対的に低いコストで素早く開発することを目標とする。
  • プロジェクトにつきもののリスクを低減させるため、小さい部分に分割し、開発中の修正を容易にする。
  • 高品質なシステムを素早く生み出すため、反復的プロトタイピングを行い、ユーザーに活発に関与させ、高度な開発ツールを利用する。ツールとしては例えば、GUIビルダー、CASEツール、データベース、4GL、コードジェネレータ、オブジェクト指向のテクニックなどを活用する。
  • ビジネスのニーズを満たすことに主眼を置き、技術的に洗練されているかはあまり重視しない（自動生成したコードは一般に洗練されていない）。
  • 開発すべき機能群を優先順位付けし、いくつかの機能ごとに納期を定める。プロジェクトが遅延してきたら、納期は順延させず、実装する機能を減らす。
  • 一般に JAD (joint application design)  を含む。JADはユーザーがシステム設計に積極的に関与する手法であり、ユーザーの要望を反映させやすい。
  • プロトタイプを捨てることはなく、製品を反復的に改良していくと考える。
  • 将来の開発や保守で役立つ文書を作成する。
  • 標準的なシステム分析・設計技法をこのフレームワークに導入可能である。

その他

他にも次のような方法論がある。

関連する話題

ビュー・モデル

 
TEAF（英語版）におけるビューとパースペクティブのマトリクス

ビュー・モデルはシステムとそれを取り巻く環境のビューポイントを提供するフレームワークであり、ソフトウェア開発工程で使われている。ビューの根底にある意味論をグラフィカルに表現する。

ビューポイントとビューは、技術者が非常に複雑なシステムを理解できるようにすることを目的としており、そのシステムが対象としている領域の専門知識を必要とする課題や解法を理解しやすくすることを目的としている。物理的に集中したシステムの工学においては、ビューポイントは工学組織内の機能や責任に対応していることが多い[8]。

非常に複雑なシステム仕様は広範囲に及ぶため、1人の人間がその仕様のあらゆる観点を理解することが困難である。さらに、ある人があるシステムのどういう点に関心を持つかは様々であり、システムの仕様を検討する観点も人それぞれである。経営者はシステム実装者とは異なる観点でシステム構成について質問するだろう。したがってビューポイントのフレームワークの概念は、ある複雑なシステムの仕様に別々のビューポイントを提供することである。そうしたビューポイント群により、システムの様々な観点に関心を持つ人々を満足させる。各ビューポイントにはビューポイント言語が対応しており、語彙や表現方法をそのビューポイントの観衆に最適化している。

ビジネスプロセスとデータモデリング

情報の現在状態のグラフィカル表現（英語版）は、ユーザーとシステム開発者の双方にとって効果的に情報を表現する手段を提供する。

 
ビジネスプロセスとデータモデルの相互作用の例[9]
  • ビジネスモデルは、対象とするビジネスプロセスの機能とその機能を実現する組織を表現したものである。組織の活動と情報の流れを表現することで、視覚的に理解でき、そのプロセスの妥当性を評価する基盤を提供する。
  • データモデルは、格納する情報の詳細を提供するもので、最終的にアプリケーションのコードを生成するためや、ソフトウェアを作るか購入するかを判断する際に主に使われる。右図はビジネスプロセスとデータモデルの相互作用の一例を示している[9]。

通常、ビジネス分析（英語版）と呼ばれるインタビューを行った後、モデルを作成する。このインタビューは、プロセスを説明するのに必要な情報を引き出すよう設計された一連の質問で構成される。インタビュアーは関係者から情報を引き出す役目があるため、ファシリテーター（世話役、まとめ役）と呼ばれる。ファシリテーターは対象となるプロセスにある程度の知識を持っているべきだが、専門家に対する質問群の構造化された方法論の方が重要である。実際インタビューはファシリテーターのチームが分担して行うので、最終的にその内容をまとめたときに矛盾が生じないことが重要であり、インタビューの方法論は重要である[9]。

モデルは、プロセスの現状をそのまま表現したものか、こうなるべきだというアイデアをまとめたものかのどちらかになる。プロセスモデルとデータモデルを生成することで、現状の情報システムが妥当なものでほとんど修正を必要としないことが明らかとなったり、どういう改造が必要かが明らかとなったりする。ビジネスモデルの作成は、情報プロセスを見たり自動化したりといった以上のものを含んでいる。分析によってビジネスやそれを運営する組織のやりかたを根本から考え直すきっかけにもなりうる[9]。

CASE

Computer Aided Software Engineering (CASE) は、高品質で保守が容易なソフトウェア製品を作るためにツール群などを利用するものである[10]。情報システムのソフトウェア開発工程で自動化ツール群を利用する手法を指す[11]。CASEツールには、分析用、設計用、コード生成用などがあり、所定のプログラミング言語の構造化されたコードを生成したり、文書を生成したりする[12]。

CASEの基本となる考え方は次の2つである[13]。

主なCASEツールとしては、構成管理、データモデリング、モデル変換、リファクタリング、自動プログラミング、UMLといったツールがある。

統合開発環境

 
Anjuta - CおよびC++用IDE（GMONE）

統合開発環境 (IDE) はプログラマがソフトウェアを開発する際の包括的ファシリティを提供するソフトウェアアプリケーションである。IDEには通常、次のような機能が備えられている。

IDEはプログラマの生産性を最大化するよう設計されており、そのために統一感のあるユーザインタフェースのコンポーネント群が緊密に連携するようになっている。一般に特定のプログラミング言語専用に作られているため、その言語のプログラミングパラダイムにマッチした機能群を提供できる。

モデリング言語

モデリング言語は情報・知識・システムを構造的に表現するのに使われる人工言語であり、一貫した規則群で定義されている。それら規則群は構造内の各コンポーネントの意味を表すためのものである。モデリング言語はグラフィカルなものと文字のみから成るものがある[14]。グラフィカルなモデリング言語は何らかの概念を表す名前付きのシンボルとそれらの関係を表すシンボル間を繋ぐ線によるダイアグラムを表現として採用しており、そこに制約を表すグラフィカルな注釈を加えている。文字のみのモデリング言語は、パラメータを伴う標準化されたキーワードを使うのが一般的で、コンピュータが解読可能な表現にしている。

ソフトウェア工学分野のグラフィカルなモデリング言語としては、以下のようなものがある。

モデリング言語は必ずしも実行可能ではなく、もし実行可能であったとしても、それを使うことで人間のプログラマが不要になるということはない。むしろ実行可能なモデリング言語は熟練したプログラマの生産性向上を意図しており、特に並列計算や分散コンピューティングといった難しい問題を扱いやすくするものである。

プログラミングパラダイム

プログラミングパラダイムはコンピュータプログラミングの根本的なスタイルであり、対照的にソフトウェア開発方法論は特定のソフトウェア工学問題を解く際のスタイルである。個々のパラダイムは、（オブジェクト、関数、変数、制約などの）プログラムの要素と（代入、評価、処理フロー、データフローなどの）処理ステップを表現する概念と抽象化がそれぞれ固有のものとなっている。

プログラミング言語は何らかのプログラミングパラダイムをサポートすることができる。例えばC++や Object Pascal でのプログラムは、純粋に手続き的に書くこともできるし、純粋にオブジェクト指向的に書くこともでき、両方のパラダイムの要素を含むプログラムとして書くこともできる。オブジェクト指向プログラミングでは、プログラマはプログラムを相互作用するオブジェクトの集まりと考えることができ、関数型プログラミングでは状態を持たない関数評価の並びと考えることができる。多数のプロセッサを有するコンピュータやシステムでのプログラミングでは、プロセス指向プログラミング（英語版）を採用することで、データ構造を論理的に共有し並行動作するプロセス群と考えてプログラミングすることができる。

ソフトウェア工学に様々な「方法論」があるように、プログラミング言語はそれぞれ異なる「プログラミングパラダイム」を推奨している。単一のパラダイムをサポートするよう設計された言語（例えば、オブジェクト指向プログラミングをサポートするSmalltalk、関数型プログラミングをサポートするHaskellなど）もあれば、複数のパラダイムをサポートする言語（Object Pascal、C++、C#、Visual Basic、Common Lisp、Scheme、Python、Ruby、Ozなど）もある。

多くのプログラミングパラダイムには、それによって可能になることと引き換えに「禁止」されていることがある。例えば、純粋な関数型プログラミングでは副作用の利用が禁じられている。また、構造化プログラミングではGoto文の利用が禁じられている。そのためもあり、新たなパラダイムが登場した際、それまでのスタイルに慣れた人々からは教条的だとか制限がきつすぎると批判されることが多い[要出典]。一定の方法を避けることは、プログラムの正しさを証明しやすくし、その挙動を理解しやすくする。

ソフトウェアフレームワーク

ソフトウェアフレームワークは、ソフトウェアのシステムまたはサブシステムの再利用可能な設計である。ソフトウェアフレームワークは、支援プログラム、ライブラリ、スクリプト言語、コンポーネント群の結合を支援するソフトウェアなどから成る。フレームワークの各部はAPIを公開していることがある。

ソフトウェア開発工程

ソフトウェア開発工程はソフトウェア製品開発の枠組みである。同義語として「ソフトウェアライフサイクル」や「ソフトウェアプロセス」がある。ソフトウェア開発工程にはいくつかのモデルがあり、ソフトウェア開発方法論に対応している。特にアメリカ合衆国の軍需産業で、契約の条件として明確なプロセス・モデリングを要求されたために発展した。国際規格としては ISO/IEC 12207 がソフトウェアライフサイクルにおける手法の選択・実装・監視について規定している。

数十年来の目標は、生産性と品質を向上させる、反復可能で予測可能なプロセスを見出すことだった。いくつかは、ソフトウェアを書く際の一見したところ手に負えないタスクを体系化・定式化しようとしている。その他は、プロジェクト管理の技法をソフトウェア開発に適用している。プロジェクト管理しなければ、ソフトウェアプロジェクトは容易に遅延し、予算を超過する。機能・コスト・納期の面で期待通りとならなかったソフトウェアプロジェクトの多くは、プロジェクト管理の面で問題を抱えていた。

脚注

  1. ^ a b Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87.
  2. ^ a b c d e f g h Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). Selecting a development approach. Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008. Retrieved 27 Oct 2008.
  3. ^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.
  4. ^ Barry Boehm (1996., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986
  5. ^ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130
  6. ^ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1.
  7. ^ Georges Gauthier Merx & Ronald J. Norman (2006). Unified Software Engineering with Java. p.201.
  8. ^ Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration NIST 2003.
  9. ^ a b c d Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group.
  10. ^ Kuhn, D.L (1989). "Selecting and effectively using a computer aided software engineering tool". Annual Westinghouse computer symposium; 6-7 Nov 1989; Pittsburgh, PA (USA); DOE Project.
  11. ^ P. Loucopoulos and V. Karakostas (1995). System Requirements Engineering. McGraw-Hill.
  12. ^ CASE definition In: Telecom Glossary 2000. Retrieved 26 Oct 2008.
  13. ^ K. Robinson (1992). Putting the Software Engineering into CASE. New York : John Wiley and Sons Inc.
  14. ^ Xiao He (2007). "A metamodel for the notation of graphical modeling languages". In: Computer Software and Applications Conference, 2007. COMPSAC 2007 - Vol. 1. 31st Annual International, Volume 1, Issue , 24–27 July 2007, pp 219-224.

関連項目

外部リンク

 
ウィキメディア・コモンズには、ソフトウェア開発方法論に関連するカテゴリがあります。
「https://ja.wikipedia.org/w/index.php?title=ソフトウェア開発方法論&oldid=47754550」から取得