ソフトウェア開発方法論
| ソフトウェア開発 |
|---|
| 中心となる活動 |
| パラダイムとモデル |
| 方法論とフレームワーク |
| 開発支援 |
| プラクティス |
| ツール |
| 標準と機関 |
| 用語集 |
|
ソフトウェア開発方法論（英: software development methodology; SDM）は、ソフトウェア開発に用いられる一連のルール・ガイドライン、またそれを扱うソフトウェア工学の一分野である[1]。システム開発方法論（英: system development methodology）とも。
概要
ソフトウェア・情報システムは目的を達成するために開発される。開発を1つのプロセス（ソフトウェア開発工程）として捉えると、開発スタイルにより様々な構造・制約（ルール）・原則が見いだされる。一連のルール・ガイドラインからなる1つの開発スタイルがソフトウェア開発方法論である。また様々なスタイルに共通するあるいは特有なルールを研究するソフトウェア工学の分野もソフトウェア開発方法論と呼ばれる。
歴史
ソフトウェア開発方法論 (SDM) のフレームワークが生まれたのは1960年代のことである。Elliott (2004) によれば、情報システム構築のための最古の定式化された方法論フレームワークはシステム開発ライフサイクル (SDLC) だという。SDLCの根幹をなすのは、情報システムを計画的に構造化された整然とした形で開発するには、アイデアの誕生から最終的なシステムの配備まで、適用するフレームワークの文脈の中で開発工程の各段階を着実に逐次的に実行しなければならないという考え方である[2]。1960年代におけるこの方法論フレームワークの主な対象は、巨大企業の大規模ビジネスシステム開発だった。当時の情報システムは多大なデータ処理と数値処理を中心としたものだった[2]。
フレームワークとしてのSDM
ソフトウェア開発方法論は、情報システムの開発工程を構造化し計画し制御するためのフレームワークであり、プロジェクトチームがアプリケーションの開発や保守のために作成・構築する成果物の事前定義なども含まれる[3]。
そうしたフレームワークは長年の間に様々なものが考案されてきており、それぞれに長所と短所がある。あるソフトウェア開発方法論フレームワークは、すべてのプロジェクトに適しているわけではない。技術的・組織的などの面を考慮すると、それぞれの方法論フレームワークにはそれぞれ適した種類のプロジェクトがある[3]。
そうしたソフトウェア開発フレームワークには、それをさらに発展させ、使用をサポートし、その方法論フレームワークの普及に努める組織が存在する。方法論フレームワークは、ある種の公式な文書で定義されることが多い。ソフトウェア開発方法論フレームワークの具体例としては、以下のものがある。
- ラショナル統一プロセス (RUP, IBM) - 1998年から
- アジャイル統一プロセス (AUP) - 2005年、スコット・アンブラーが構築
個々のSDM
SDMフレームワークを個々の組織やプロジェクトに適用する場合、具体的なソフトウェア開発方法論が使われる。年代順に次のようなものがある。
- 1970年代
- 構造化プログラミング - 1969年から
- Cap Gemini SDM - オランダのPANDATAという企業で生まれた。英語圏にもたらされたのは1974年。この場合のSDMは System Development Methodology の略である。
- 1980年代
- SSADM (Structured systems analysis and design method) - 1980年から
- 情報要求分析/ソフトシステム方法論
- 1990年代
- オブジェクト指向プログラミング (OOP) - 1960年代初めからあったが、1990年代中ごろに主役に躍り出た。
- RAD - 1991年から
- DSDM (Dynamic systems development method) - 1994年から
- スクラム - 1995年から
- チーム・ソフトウェア・プロセス - 1998年から
- エクストリーム・プログラミング - 1999年から
具体例
どのソフトウェア開発方法論も特定のフレームワークをソフトウェアの開発・保守に適用する際の基盤となる。情報技術の生まれたころから、いくつかのソフトウェア開発手法が使われてきた。主なものを以下に挙げる[3]。
- ウォーターフォール - 直線的なフレームワーク
- プロトタイピング - 反復的なフレームワーク
- インクリメンタル - 直線的な要素と反復的な要素を組み合わせたフレームワーク
- スパイラル - 直線的な要素と反復的な要素を組み合わせたフレームワーク
- RAD - 反復的なフレームワーク
- エクストリームプログラミング
ウォーターフォール
ウォーターフォール・モデルは逐次的な開発手法であり、要求分析・設計・実装・テスト（評価）・統合・保守と、水が低いところに流れていくように上流工程から下流工程へと順次移行していく。この手法を最初に定式化したのはウィンストン・W・ロイスの1970年の論文とされているが[4]、ロイス自身は「ウォーターフォール」という用語をこの論文で使ってはいない。
基本原則は次の通り[3]。
- プロジェクトは逐次的な工程に分けられ、工程間の若干の重なりと戻りは許容される。
- 計画、スケジュール、日程、予算などを重視し、システム全体を一度に実装することを特徴とする。
- 様々な文書を作成し、公式なレビューを行い、ある工程から次の工程へ移行する際にはユーザーまたはIT管理者による承認を必要とする。
ウォーターフォール・モデルは従来からの工学的手法をソフトウェア工学にそのまま適用したものである。大規模なプロジェクトで採用され、予算超過、納期遅延、要求仕様を満たさないものを生み出すなどして非難されてきた。契約条件にされた場合を除き、ウォーターフォール・モデルよりも柔軟な手法を採用することが多くなっている。
プロトタイピング
ソフトウェアプロトタイピングは、開発すべきソフトウェアの不完全なバージョンであるプロトタイプを（何度か）開発中に作成する開発手法である。
基本原則は次の通り[3]。
- 単独で使える完備した開発方法論ではなく、他の開発方法論に加えて使用される。
- 大型プロジェクトにつきもののリスクを低減させるため、プロジェクトを小さな部分に分割し、開発中の修正を容易にする手段を提供する。
- プロトタイプはユーザーに提示するものであり、ユーザーが開発プロセスに長期的に関与することになる。そのため、最終的な実装をユーザーが受容しやすくなる。
- プロトタイプに反復的に修正を加えていき、ユーザーの要求を満たすようにしていく。
- プロトタイプは最終的に捨てられることが多いが、最終的なシステムがプロトタイプを発展させることで作られることもある。
- プロトタイピングにより、開発者とユーザー間の根本的な誤解を早期に解決することができる。
反復型
反復型開発はプロジェクトを小さな部分に分割し、開発工程中の修正を容易にし、プロジェクトのリスクを低減させる。
基本原則は次の通り[3]。
- ウォーターフォールを小規模に何度も繰り返す。一回のウォーターフォールはシステム内の小さな部分を完成させるものである。
- 全体の要求仕様は反復を行う前に定義される。
スパイラル
スパイラルモデルはトップダウン設計とボトムアップ設計のそれぞれの利点を生かしたもので、設計とプロトタイピングの工程を繰り返す手法である。これは一種のメタモデルで、他のモデルが利用することができる。
基本原則は次の通り[3]。
- プロジェクトのリスクを最小化することを主眼としており、小さな部分に分割して開発工程での修正を容易にし、リスクの再評価の機会を提供し、プロジェクト継続の検討を可能にする。
- 各サイクルは同じ一連の工程からなり、製品全体の概念を個々のプログラムのコーディングにまで落とし込み、一回のサイクルで1つの部分を完成させたり、全体の改良を施したりする[5]。
- 1つのサイクルは、(1) その反復の目的・選択肢・制約の決定、(2) 選択肢の評価、リスクの識別と解決、(3) 具体的な開発とそのサイクルの成果物の評価、(4) 次の反復の計画立案、という4つに分けられる[6]。
- 各サイクルは利害関係者と彼らの勝利条件の識別で始まり、レビューとコミットメントで終わる[7]。
RAD
RAD (Rapid Application Development) は、プロトタイプを反復的に開発・構築していくソフトウェア開発方法論である。本来は、1991年にジェームス・マーティンが提唱したソフトウェア開発工程を指した言葉である。
基本原則は次の通り[3]。
- 高品質なシステムを相対的に低いコストで素早く開発することを目標とする。
- プロジェクトにつきもののリスクを低減させるため、小さい部分に分割し、開発中の修正を容易にする。
- 高品質なシステムを素早く生み出すため、反復的プロトタイピングを行い、ユーザーに活発に関与させ、高度な開発ツールを利用する。ツールとしては例えば、GUIビルダー、CASEツール、データベース、第四世代言語 (4GL)、コードジェネレータ、オブジェクト指向のテクニックなどを活用する。
- ビジネスのニーズを満たすことに主眼を置き、技術的に洗練されているかはあまり重視しない（自動生成したコードは一般に洗練されていない）。
- 開発すべき機能群を優先順位付けし、いくつかの機能ごとに納期を定める。プロジェクトが遅延してきたら、納期は順延させず、実装する機能を減らす。
- 一般に JAD (joint application design) を含む。JADはユーザーがシステム設計に積極的に関与する手法であり、ユーザーの要望を反映させやすい。
- プロトタイプを捨てることはなく、製品を反復的に改良していくと考える。
- 将来の開発や保守で役立つ文書を作成する。
- 標準的なシステム分析・設計技法をこのフレームワークに導入可能である。
その他
他にも次のような方法論がある。
- オブジェクト指向開発方法論。グラディ・ブーチのオブジェクト指向設計 (OOD)、あるいはオブジェクト指向分析設計 (OOAD)。ブーチのモデルでは、クラス図、状態遷移図、相互作用図、モジュール図、プロセス図という6種類の図を含んでいる[8]。
- トップダウン・プログラミング。1970年代、IBMのハーラン・ミルズ（とニクラウス・ヴィルト）が構造化プログラミングを発展させたもの。
- Unified Process (UP)。統一モデリング言語 (UML) に基づく反復型ソフトウェア開発方法論フレームワーク。ソフトウェア開発を inception、elaboration、construction、guidelines という4つのフェーズに分け、それぞれのフェーズを1つ以上の反復可能な工程で構成する。UP向けに様々なツールが存在する。中でも最もよく知られているのがラショナル統一プロセス (RUP) である。
- アジャイルソフトウェア開発。反復型のソフトウェア開発方法論であり、自律的なチーム間の協力によって要求仕様を発展させていく形態をとる。2001年、アジャイルソフトウェア開発宣言が発表され、この呼称が生まれた。
- ユーザーストーリー: 要件定義のもととなる顧客視点のソフトウェア利用体験。対話的な要件理解・定義に利用される。
関連する話題
ビュー・モデル
ビュー・モデルはシステムとそれを取り巻く環境のビューポイントを提供するフレームワークであり、ソフトウェア開発工程で使われている。ビューの根底にある意味論をグラフィカルに表現する。
ビューポイントとビューは、技術者が非常に複雑なシステムを理解できるようにすることを目的としており、そのシステムが対象としている領域の専門知識を必要とする課題や解法を理解しやすくすることを目的としている。物理的に集中したシステムの工学においては、ビューポイントは工学組織内の機能や責任に対応していることが多い[9]。
非常に複雑なシステム仕様は広範囲に及ぶため、1人の人間がその仕様のあらゆる観点を理解することが困難である。さらに、ある人があるシステムのどういう点に関心を持つかは様々であり、システムの仕様を検討する観点も人それぞれである。経営者はシステム実装者とは異なる観点でシステム構成について質問するだろう。したがってビューポイントのフレームワークの概念は、ある複雑なシステムの仕様に別々のビューポイントを提供することである。そうしたビューポイント群により、システムの様々な観点に関心を持つ人々を満足させる。各ビューポイントにはビューポイント言語が対応しており、語彙や表現方法をそのビューポイントの観衆に最適化している。
ビジネスプロセスとデータモデリング
情報の現在状態のグラフィカル表現は、ユーザーとシステム開発者の双方にとって効果的に情報を表現する手段を提供する。
- ビジネスモデルは、対象とするビジネスプロセスの機能とその機能を実現する組織を表現したものである。組織の活動と情報の流れを表現することで、視覚的に理解でき、そのプロセスの妥当性を評価する基盤を提供する。
- データモデルは、格納する情報の詳細を提供するもので、最終的にアプリケーションのコードを生成するためや、ソフトウェアを作るか購入するかを判断する際に主に使われる。右図はビジネスプロセスとデータモデルの相互作用の一例を示している[10]。
通常、ビジネス分析と呼ばれるインタビューを行った後、モデルを作成する。このインタビューは、プロセスを説明するのに必要な情報を引き出すよう設計された一連の質問で構成される。インタビュアーは関係者から情報を引き出す役目があるため、ファシリテーター（世話役、まとめ役）と呼ばれる。ファシリテーターは対象となるプロセスにある程度の知識を持っているべきだが、専門家に対する質問群の構造化された方法論の方が重要である。実際インタビューはファシリテーターのチームが分担して行うので、最終的にその内容をまとめたときに矛盾が生じないことが重要であり、インタビューの方法論は重要である[10]。
モデルは、プロセスの現状をそのまま表現したものか、こうなるべきだというアイデアをまとめたものかのどちらかになる。プロセスモデルとデータモデルを生成することで、現状の情報システムが妥当なものでほとんど修正を必要としないことが明らかとなったり、どういう改造が必要かが明らかとなったりする。ビジネスモデルの作成は、情報プロセスを見たり自動化したりといった以上のものを含んでいる。分析によってビジネスやそれを運営する組織のやりかたを根本から考え直すきっかけにもなりうる[10]。
CASE
Computer Aided Software Engineering (CASE) は、高品質で保守が容易なソフトウェア製品を作るためにツール群などを利用するものである[11]。情報システムのソフトウェア開発工程で自動化ツール群を利用する手法を指す[12]。CASEツールには、分析用、設計用、コード生成用などがあり、所定のプログラミング言語の構造化されたコードを生成したり、文書を生成したりする[13]。
CASEの基本となる考え方は次の2つである[14]。
主なCASEツールとしては、構成管理、データモデリング、モデル変換、リファクタリング、自動プログラミング、UMLといったツールがある。
統合開発環境
統合開発環境 (IDE) はプログラマがソフトウェアを開発する際の包括的ファシリティを提供するソフトウェアアプリケーションである。IDEには通常、次のような機能が備えられている。
- ソースコードエディタ
- コンパイラ と インタプリタ
- ビルド自動化ツール
- デバッガ
IDEはプログラマの生産性を最大化するよう設計されており、そのために統一感のあるユーザインタフェースのコンポーネント群が緊密に連携するようになっている。一般に特定のプログラミング言語専用に作られているため、その言語のプログラミングパラダイムにマッチした機能群を提供できる。
モデリング言語
モデリング言語は情報・知識・システムを構造的に表現するのに使われる人工言語であり、一貫した規則群で定義されている。それら規則群は構造内の各コンポーネントの意味を表すためのものである。モデリング言語はグラフィカルなものと文字のみから成るものがある[15]。グラフィカルなモデリング言語は何らかの概念を表す名前付きのシンボルとそれらの関係を表すシンボル間を繋ぐ線によるダイアグラムを表現として採用しており、そこに制約を表すグラフィカルな注釈を加えている。文字のみのモデリング言語は、パラメータを伴う標準化されたキーワードを使うのが一般的で、コンピュータが解読可能な表現にしている。
ソフトウェア工学分野のグラフィカルなモデリング言語としては、以下のようなものがある。
- Business Process Modeling Notation（BPMN、およびXMLを基盤とするBPML）は、プロセス・モデリング言語のひとつ。
- EXPRESSとEXPRESS-G (ISO 10303-11) は、汎用データモデリング言語の国際規格（STEPの一部）
- Extended Enterprise Modeling Language (EEML) は、多層にまたがるビジネスプロセスのモデリングによく使われている。
- フローチャートは、アルゴリズムや作業工程の概略を表現する図である。
- Fundamental Modeling Concepts (FMC) は、ソフトウェア中心のシステムのためのモデリング言語。
- IDEFはモデリング言語ファミリであり、機能モデリングのためのIDEF0、情報モデリングのためのIDEF1X、モデリングオントロジーのためのIDEF5などが含まれる。
- LePUS3は、オブジェクト指向ビジュアル設計記述言語であり、（Java、C++、C#などで書かれる）大規模なオブジェクト指向プログラムやデザインパターンのモデリングに適した形式仕様記述言語である。
- 仕様及び記述言語 (Specification and Description Language, SDL) は、分散システムなどの挙動を仕様として明確に記述するための仕様記述言語である。
- 統一モデリング言語 (UML) は、業界標準の汎用モデリング言語である。最新版である UML 2.0 では13種類の図をサポートしており、様々なサポートツールがある。
モデリング言語は必ずしも実行可能ではなく、もし実行可能であったとしても、それを使うことで人間のプログラマが不要になるということはない。むしろ実行可能なモデリング言語は熟練したプログラマの生産性向上を意図しており、特に並列計算や分散コンピューティングといった難しい問題を扱いやすくするものである。
プログラミングパラダイム
プログラミングパラダイムはコンピュータプログラミングの根本的なスタイルであり、対照的にソフトウェア開発方法論は特定のソフトウェア工学問題を解く際のスタイルである。個々のパラダイムは、（オブジェクト、関数、変数、制約などの）プログラムの要素と（代入、評価、処理フロー、データフローなどの）処理ステップを表現する概念と抽象化がそれぞれ固有のものとなっている。
プログラミング言語は何らかのプログラミングパラダイムをサポートすることができる。例えばC++や Object Pascal でのプログラムは、純粋に手続き的に書くこともできるし、純粋にオブジェクト指向的に書くこともでき、両方のパラダイムの要素を含むプログラムとして書くこともできる。オブジェクト指向プログラミングでは、プログラマはプログラムを相互作用するオブジェクトの集まりと考えることができ、関数型プログラミングでは状態を持たない関数評価の並びと考えることができる。多数のプロセッサを有するコンピュータやシステムでのプログラミングでは、プロセス指向プログラミングを採用することで、データ構造を論理的に共有し並行動作するプロセス群と考えてプログラミングすることができる。
ソフトウェア工学に様々な「方法論」があるように、プログラミング言語はそれぞれ異なる「プログラミングパラダイム」を推奨している。単一のパラダイムをサポートするよう設計された言語（例えば、オブジェクト指向プログラミングをサポートするSmalltalk、関数型プログラミングをサポートするHaskellなど）もあれば、複数のパラダイムをサポートする言語（Object Pascal、C++、C#、Visual Basic、Common Lisp、Scheme、Python、Ruby、Ozなど）もある。
多くのプログラミングパラダイムには、それによって可能になることと引き換えに「禁止」されていることがある。例えば、純粋な関数型プログラミングでは副作用の利用が禁じられている。また、構造化プログラミングではGoto文の利用が禁じられている。
ソフトウェアフレームワーク
ソフトウェアフレームワークは、ソフトウェアのシステムまたはサブシステムの再利用可能な設計である。ソフトウェアフレームワークは、支援プログラム、ライブラリ、スクリプト言語、コンポーネント群の結合を支援するソフトウェアなどから成る。フレームワークの各部はAPIを公開していることがある。
脚注
- ^ "A software development methodology is a set of rules and guidelines that are used in the process of researching, planning, designing, developing, testing, setup and maintaining a software product." Mihai Liviu DESPA. (2014). Comparative study on software development methodologies. Database Systems Journal vol. V, no. 3.
- ^ a b Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87.
- ^ 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.
- ^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007.
- ^ Barry Boehm (1996., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986
- ^ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130
- ^ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1.
- ^ Georges Gauthier Merx & Ronald J. Norman (2006). Unified Software Engineering with Java. p.201.
- ^ Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration NIST 2003.
- ^ 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.
- ^ 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.
- ^ P. Loucopoulos and V. Karakostas (1995). System Requirements Engineering. McGraw-Hill.
- ^ CASE Archived 2012年2月18日, at the Wayback Machine. definition In: Telecom Glossary 2000 Archived 2005年11月22日, at the Wayback Machine.. Retrieved 26 Oct 2008.
- ^ K. Robinson (1992). Putting the Software Engineering into CASE. New York : John Wiley and Sons Inc.
- ^ 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.
関連項目
外部リンク
- Selecting a development approach at cms.hhs.gov.
- Software Methodologies Book Reviews - ソフトウェア開発方法論に関する書籍のレビューを集めたもの
| 分野 | |||||||
|---|---|---|---|---|---|---|---|
| コンセプト | |||||||
| 指向 | |||||||
| モデル |
| ||||||
| 主な人物 |
| ||||||
| 関連項目 |
| ||||||
「Software development methodology」の例文・使い方・用例・文例
- Software development methodologyのページへのリンク
