ソフトウェア開発方法論
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2023/12/12 01:57 UTC 版)
関連する話題
ビュー・モデル
ビュー・モデルはシステムとそれを取り巻く環境のビューポイントを提供するフレームワークであり、ソフトウェア開発工程で使われている。ビューの根底にある意味論をグラフィカルに表現する。
ビューポイントとビューは、技術者が非常に複雑なシステムを理解できるようにすることを目的としており、そのシステムが対象としている領域の専門知識を必要とする課題や解法を理解しやすくすることを目的としている。物理的に集中したシステムの工学においては、ビューポイントは工学組織内の機能や責任に対応していることが多い[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.
- ソフトウェア開発方法論のページへのリンク