ソフトウェア開発方法論
ソフトウェア開発方法論（英: software development methodology; SDM）は、ソフトウェア開発に用いられる一連のルール・ガイドライン、またそれを扱うソフトウェア工学の一分野である[1]。システム開発方法論（英: system development methodology）とも。 概要ソフトウェア・情報システムは目的を達成するために開発される。開発を1つのプロセス（ソフトウェア開発工程）として捉えると、開発スタイルにより様々な構造・制約（ルール）・原則が見いだされる。一連のルール・ガイドラインからなる1つの開発スタイルがソフトウェア開発方法論である。また様々なスタイルに共通するあるいは特有なルールを研究するソフトウェア工学の分野もソフトウェア開発方法論と呼ばれる。 歴史ソフトウェア開発方法論 (SDM) のフレームワークが生まれたのは1960年代のことである。Elliott (2004) によれば、情報システム構築のための最古の定式化された方法論フレームワークはシステム開発ライフサイクル (SDLC) だという。SDLCの根幹をなすのは、情報システムを計画的に構造化された整然とした形で開発するには、アイデアの誕生から最終的なシステムの配備まで、適用するフレームワークの文脈の中で開発工程の各段階を着実に逐次的に実行しなければならないという考え方である[2]。1960年代におけるこの方法論フレームワークの主な対象は、巨大企業の大規模ビジネスシステム開発だった。当時の情報システムは多大なデータ処理と数値処理を中心としたものだった[2]。 フレームワークとしてのSDMソフトウェア開発方法論は、情報システムの開発工程を構造化し計画し制御するためのフレームワークであり、プロジェクトチームがアプリケーションの開発や保守のために作成・構築する成果物の事前定義なども含まれる[3]。  そうしたフレームワークは長年の間に様々なものが考案されてきており、それぞれに長所と短所がある。あるソフトウェア開発方法論フレームワークは、すべてのプロジェクトに適しているわけではない。技術的・組織的などの面を考慮すると、それぞれの方法論フレームワークにはそれぞれ適した種類のプロジェクトがある[3]。 そうしたソフトウェア開発フレームワークには、それをさらに発展させ、使用をサポートし、その方法論フレームワークの普及に努める組織が存在する。方法論フレームワークは、ある種の公式な文書で定義されることが多い。ソフトウェア開発方法論フレームワークの具体例としては、以下のものがある。
個々のSDMSDMフレームワークを個々の組織やプロジェクトに適用する場合、具体的なソフトウェア開発方法論が使われる。年代順に次のようなものがある。
具体例どのソフトウェア開発方法論も特定のフレームワークをソフトウェアの開発・保守に適用する際の基盤となる。情報技術の生まれたころから、いくつかのソフトウェア開発手法が使われてきた。主なものを以下に挙げる[3]。
ウォーターフォールウォーターフォール・モデルは逐次的な開発手法であり、要求分析・設計・実装・テスト（評価）・統合・保守と、水が低いところに流れていくように上流工程から下流工程へと順次移行していく。この手法を最初に定式化したのはウィンストン・W・ロイスの1970年の論文とされているが[4]、ロイス自身は「ウォーターフォール」という用語をこの論文で使ってはいない。 基本原則は次の通り[3]。
ウォーターフォール・モデルは従来からの工学的手法をソフトウェア工学にそのまま適用したものである。大規模なプロジェクトで採用され、予算超過、納期遅延、要求仕様を満たさないものを生み出すなどして非難されてきた。契約条件にされた場合を除き、ウォーターフォール・モデルよりも柔軟な手法を採用することが多くなっている。 プロトタイピングソフトウェアプロトタイピングは、開発すべきソフトウェアの不完全なバージョンであるプロトタイプを（何度か）開発中に作成する開発手法である。 基本原則は次の通り[3]。
反復型反復型開発はプロジェクトを小さな部分に分割し、開発工程中の修正を容易にし、プロジェクトのリスクを低減させる。 基本原則は次の通り[3]。
スパイラル スパイラルモデルはトップダウン設計とボトムアップ設計のそれぞれの利点を生かしたもので、設計とプロトタイピングの工程を繰り返す手法である。これは一種のメタモデルで、他のモデルが利用することができる。 基本原則は次の通り[3]。
RADRAD (Rapid Application Development) は、プロトタイプを反復的に開発・構築していくソフトウェア開発方法論である。本来は、1991年にジェームス・マーティンが提唱したソフトウェア開発工程を指した言葉である。 基本原則は次の通り[3]。
その他他にも次のような方法論がある。
関連する話題ビュー・モデル ビュー・モデルはシステムとそれを取り巻く環境のビューポイントを提供するフレームワークであり、ソフトウェア開発工程で使われている。ビューの根底にある意味論をグラフィカルに表現する。 ビューポイントとビューは、技術者が非常に複雑なシステムを理解できるようにすることを目的としており、そのシステムが対象としている領域の専門知識を必要とする課題や解法を理解しやすくすることを目的としている。物理的に集中したシステムの工学においては、ビューポイントは工学組織内の機能や責任に対応していることが多い[9]。 非常に複雑なシステム仕様は広範囲に及ぶため、1人の人間がその仕様のあらゆる観点を理解することが困難である。さらに、ある人があるシステムのどういう点に関心を持つかは様々であり、システムの仕様を検討する観点も人それぞれである。経営者はシステム実装者とは異なる観点でシステム構成について質問するだろう。したがってビューポイントのフレームワークの概念は、ある複雑なシステムの仕様に別々のビューポイントを提供することである。そうしたビューポイント群により、システムの様々な観点に関心を持つ人々を満足させる。各ビューポイントにはビューポイント言語が対応しており、語彙や表現方法をそのビューポイントの観衆に最適化している。 ビジネスプロセスとデータモデリング情報の現在状態のグラフィカル表現は、ユーザーとシステム開発者の双方にとって効果的に情報を表現する手段を提供する。 
通常、ビジネス分析と呼ばれるインタビューを行った後、モデルを作成する。このインタビューは、プロセスを説明するのに必要な情報を引き出すよう設計された一連の質問で構成される。インタビュアーは関係者から情報を引き出す役目があるため、ファシリテーター（世話役、まとめ役）と呼ばれる。ファシリテーターは対象となるプロセスにある程度の知識を持っているべきだが、専門家に対する質問群の構造化された方法論の方が重要である。実際インタビューはファシリテーターのチームが分担して行うので、最終的にその内容をまとめたときに矛盾が生じないことが重要であり、インタビューの方法論は重要である[10]。 モデルは、プロセスの現状をそのまま表現したものか、こうなるべきだというアイデアをまとめたものかのどちらかになる。プロセスモデルとデータモデルを生成することで、現状の情報システムが妥当なものでほとんど修正を必要としないことが明らかとなったり、どういう改造が必要かが明らかとなったりする。ビジネスモデルの作成は、情報プロセスを見たり自動化したりといった以上のものを含んでいる。分析によってビジネスやそれを運営する組織のやりかたを根本から考え直すきっかけにもなりうる[10]。 CASEComputer Aided Software Engineering (CASE) は、高品質で保守が容易なソフトウェア製品を作るためにツール群などを利用するものである[11]。情報システムのソフトウェア開発工程で自動化ツール群を利用する手法を指す[12]。CASEツールには、分析用、設計用、コード生成用などがあり、所定のプログラミング言語の構造化されたコードを生成したり、文書を生成したりする[13]。 CASEの基本となる考え方は次の2つである[14]。 主なCASEツールとしては、構成管理、データモデリング、モデル変換、リファクタリング、自動プログラミング、UMLといったツールがある。 統合開発環境 統合開発環境 (IDE) はプログラマがソフトウェアを開発する際の包括的ファシリティを提供するソフトウェアアプリケーションである。IDEには通常、次のような機能が備えられている。
IDEはプログラマの生産性を最大化するよう設計されており、そのために統一感のあるユーザインタフェースのコンポーネント群が緊密に連携するようになっている。一般に特定のプログラミング言語専用に作られているため、その言語のプログラミングパラダイムにマッチした機能群を提供できる。 モデリング言語モデリング言語は情報・知識・システムを構造的に表現するのに使われる人工言語であり、一貫した規則群で定義されている。それら規則群は構造内の各コンポーネントの意味を表すためのものである。モデリング言語はグラフィカルなものと文字のみから成るものがある[15]。グラフィカルなモデリング言語は何らかの概念を表す名前付きのシンボルとそれらの関係を表すシンボル間を繋ぐ線によるダイアグラムを表現として採用しており、そこに制約を表すグラフィカルな注釈を加えている。文字のみのモデリング言語は、パラメータを伴う標準化されたキーワードを使うのが一般的で、コンピュータが解読可能な表現にしている。 ソフトウェア工学分野のグラフィカルなモデリング言語としては、以下のようなものがある。
モデリング言語は必ずしも実行可能ではなく、もし実行可能であったとしても、それを使うことで人間のプログラマが不要になるということはない。むしろ実行可能なモデリング言語は熟練したプログラマの生産性向上を意図しており、特に並列計算や分散コンピューティングといった難しい問題を扱いやすくするものである。 プログラミングパラダイムプログラミングパラダイムはコンピュータプログラミングの根本的なスタイルであり、対照的にソフトウェア開発方法論は特定のソフトウェア工学問題を解く際のスタイルである。個々のパラダイムは、（オブジェクト、関数、変数、制約などの）プログラムの要素と（代入、評価、処理フロー、データフローなどの）処理ステップを表現する概念と抽象化がそれぞれ固有のものとなっている。 プログラミング言語は何らかのプログラミングパラダイムをサポートすることができる。例えばC++や Object Pascal でのプログラムは、純粋に手続き的に書くこともできるし、純粋にオブジェクト指向的に書くこともでき、両方のパラダイムの要素を含むプログラムとして書くこともできる。オブジェクト指向プログラミングでは、プログラマはプログラムを相互作用するオブジェクトの集まりと考えることができ、関数型プログラミングでは状態を持たない関数評価の並びと考えることができる。多数のプロセッサを有するコンピュータやシステムでのプログラミングでは、プロセス指向プログラミングを採用することで、データ構造を論理的に共有し並行動作するプロセス群と考えてプログラミングすることができる。 ソフトウェア工学に様々な「方法論」があるように、プログラミング言語はそれぞれ異なる「プログラミングパラダイム」を推奨している。単一のパラダイムをサポートするよう設計された言語（例えば、オブジェクト指向プログラミングをサポートするSmalltalk、関数型プログラミングをサポートするHaskellなど）もあれば、複数のパラダイムをサポートする言語（Object Pascal、C++、C#、Visual Basic、Common Lisp、Scheme、Python、Ruby、Ozなど）もある。 多くのプログラミングパラダイムには、それによって可能になることと引き換えに「禁止」されていることがある。例えば、純粋な関数型プログラミングでは副作用の利用が禁じられている。また、構造化プログラミングではGoto文の利用が禁じられている。 ソフトウェアフレームワークソフトウェアフレームワークは、ソフトウェアのシステムまたはサブシステムの再利用可能な設計である。ソフトウェアフレームワークは、支援プログラム、ライブラリ、スクリプト言語、コンポーネント群の結合を支援するソフトウェアなどから成る。フレームワークの各部はAPIを公開していることがある。 脚注
関連項目外部リンク
|
|||||||||||||||||||||||||||||||||||||||||
Portal di Ensiklopedia Dunia
