「ソフトウェアファクトリー」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
Addbot (会話 | 投稿記録)
178,576 回編集
m ボット: 言語間リンク 4 件をウィキデータ上の d:q3112065 に転記
Melan (会話 | 投稿記録)
25,487 回編集
en:Software factory（2013年2月28日 18:27:26(UTC)）の翻訳をマージ
タグ: サイズの大幅な増減
1行目: 1行目:
'''ソフトウェアファクトリー'''（Software Factory）とは、ある厳密な[[方法論]]に従った[[仕様]]に基づいて（コードではなく）[[ソフトウェア]]アプリケーションを集めるファシリティである。[[マイクロソフト]]社が[[2004年]]に発表した[[ソフトウェア開発工程]]の進化を目指したビジョンに基づいている<ref>Rashid Rick, [http://www.oopsla.org/2004/ShowEvent.do?id=801 The Future of Programming] [[OOPSLA]]'04 キーノート </ref>。かつて、職人芸的プログラミングから脱却した[[ソフトウェア工学]]に基づくソフトウェア開発を指して'''ソフトウェア工場'''と称したこともあるが、（概念はともかく）直接の関係はない。
'''ソフトウェアファクトリー'''（Software Factory）とは、関連するソフトウェア資産の構造化された集合体であり、特定の外部インタフェース定義に従ったソフトウェアアプリケーションまたはソフトウェアコンポーネントの製造を助ける<ref name="MSDN">{{Cite web | publisher = MSDN | url = http://msdn.microsoft.com/en-us/library/ff699235.aspx | title = Software Factories |accessdate=2013-04-16}}</ref>。ソフトウェアファクトリーは、[[製造業]]の技法と原則を[[ソフトウェア開発]]に適用するもので、それによって製造業の長所を模倣しようとするものである。ソフトウェアファクトリーは一般にソフトウェア製造の[[アウトソーシング]]と関係が深い。


== 概要 ==
== 概要 ==
[[ソフトウェア工学]]と[[エンタープライズアーキテクチャ]]や[[ソフトウェアアーキテクチャ]]において、ソフトウェアファクトリーは、様々なツール、プロセス、コンテンツを定型的な方式で設定するソフトウェアであり、フレームワークに基づいた適応・組み立て・設定により原型となるソフトウェア製品からの派生品の開発と保守を自動化するものである<ref name="Greenfield">{{Cite book | first1 = Jack | last1 = Greenfield | first2 = Keith | last2 = Short | first3 = Steve | last3 = Cook | first4 = Stuart | last4 = Kent | title = Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools | year = 2004 | isbn = 0-471-20284-3 }}</ref>。
標準化されたコンポーネント、特殊化されたスキルセット、並行プロセス、予測可能でスケーラブルな一貫した品質といった製造業的基盤にならって、[[ソフトウェア開発]]のレベルを高度化することがソフトウェアファクトリーの目的である。自動車製造の工業化によって生産性が向上して低価格で高品質の製品ができるようになったように、[[ソフトウェア開発工程]]の工業化でも同様の利点が期待されている。ソフトウェアファクトリーはソフトウェア開発工数を削減する手法として注目されている。概念的には、ソフトウェアファクトリーは、ドメインごとに事前に作られた標準機能を探し出す方法論である。


[[プログラミング (コンピュータ)|コーディング]]は（製造業における職人のような）専門的技量を必要とするので、アプリケーション層ではコーディングの必要性を排除し、[[統合開発環境|IDE]]を使う代わりに事前定義されたコンポーネント群を組み合わせることでソフトウェアを構築する。コーディングは新たなコンポーネントやサービスを開発するときのみ必要とされる。[[製造業]]と同様、コンポーネント（部品）の開発とシステムの構築には技術が必要である。ソフトウェアファクトリーによって得られるのは、{{仮リンク|複合アプリケーション|en|composite application}}である。
ソフトウェアファクトリーは Software Manufacturing（ソフトウェア製造）プロセスとそれを支える生産性ツールから構成される。


== 目的 ==
Software Manufacturing とは、任意の水平型[[ビジネスソフトウェア]]・アプリケーションを完全に検証済みで再利用可能なコンポーネントを使って組み立てる（コード作成を伴わない）手法であり、一定の予測可能な期間でエンドユーザーに提供する。Software Manufacturing プロセスでは必ず生産性ツールを使用し、既存のコンポーネント/アプリケーション/システムを容易に利用/統合して新たなコード作成をせずに製品を完成させる。アプリケーション層に既存部品にない部分があってコードを作成しなければならないとしたら、正規の定義では Software Manufacturing ではないが、2006年現在の実装ではこれを厳密に守るようなツールの実装にはなっていない。
ソフトウェアファクトリーは、従来のアプリケーション開発において、似たようなアプリケーションの開発で得られた知識や資産を生かしていなかったという問題への対処である。ソフトウェアファクトリー以外にも、トレーニング、文書化、フレームワークといった対策がとられてきたが、様々なアプリケーション開発で得られた貴重な知識の伝達という意味では、間違いやすいプロセスでもある。


ソフトウェアファクトリーは、特定スタイルのアプリケーション開発の成果を再利用しやすいパッケージ内に統合することでこの問題に対処する。適切なソフトウェアファクトリーを使ったアプリケーション開発には、生産性や品質の向上、機能の発展性といった多くの長所がある<ref name="MSDN" />。
生産性ツールはコード作成をせずにソフトウェアを組み立てるためのツールである。


== コンポーネント ==
ソフトウェアファクトリーは多数のコンポーネントを統合する手法であるため、それを実際に行う開発者には高度な帰納的推論の才能が要求される。
個々のソフトウェアファクトリーは特定種類のアプリケーションの構築に特化しており、そのために設計された独自の資産を含む。一般に、多くのソフトウェアファクトリーは次のような相互に関連する資産を含む<ref name="Greenfield" />。
; ファクトリースキーマ
: システムの構築や保守に使用する資産群を分類し説明した文書（XML文書など）であり、整理されており、資産間の関係が定義されている。
; リファレンス実装
: そのソフトウェアファクトリーで構築できる具体的製品の例。
; アーキテクチャのガイダンスとパターン
: アプリケーション設計における選択とその理由について説明する。
; [[ハウツー]]
: タスク完成のための手順や指示。
; レシピ
: ハウツーにある手順（全体または一部）を自動化したもの。定型的なタスクを最小の入力で完成させることができる。
; テンプレート
: 事前に組み立てられたアプリケーションの一部。プロジェクトに起点として使うことができる。
; デザイナー
: 開発者がより高い抽象レベルでアプリケーション作成に使える情報を提供。
; 再利用可能コード
: 一般的な機能や機構を実装したコンポーネント群。再利用可能コードを組み合わせることでコーディングの必要性を削減し、アプリケーション間の再利用性を高める<ref name="MSDN" />。


== 影響と批判 ==
== 製品開発 ==
ソフトウェアファクトリーによる製品構築には、以下のような活動が関与する。
[[日本]]では、[[2006年]]11月27日、[[京都高度技術研究所]]が「ソフトウェアファクトリ研究会」を発足させた[http://itpro.nikkeibp.co.jp/article/NEWS/20061128/255087/]。これはマイクロソフトの動きに直接関係したものではないが、マイクロソフトの動きに刺激されて、かつての「ソフトウェア工場」のコンセプトが甦ってきたものと言える[http://itpro.nikkeibp.co.jp/article/OPINION/20061031/252274/]。
; 問題分析
: 製品がソフトウェアファクトリーの対象範囲内のものかどうかを判定する。この判断により、製品全体または一部をソフトウェアファクトリーで構築するかどうかが決定される。
; 製品仕様
: ソフトウェアファクトリーの提供する機構と製品の要求仕様から、差異、すなわち実装すべき要件を定義する。
; 製品設計
: その差異をどう実装するかを設計する。
; 製品実装
: 様々な機構を利用して実装する。
; 製品配備
: デフォルトのインストール方式を使うか、必要な拡張を施す。
: 製品試験
: ツールを利用し試験用資産（テストケース、データ、スクリプトなど）を再利用または開発する。<ref name="Greenfield" />

== 利点 ==
ソフトウェアファクトリーによるアプリケーション開発は、従来の[[ソフトウェア開発]]に比べて様々な利点がある。
; 一貫性
: ソフトウェアファクトリーは似たような機能やアーキテクチャのソフトウェア製品群の構築に利用でき、それらの一貫性を容易に達成できる。それによって運用が単純化され、トレーニングや保守のコストが削減される。
; 品質
: 有効であることが証明済みの慣習を容易に学習・実装できる。再利用可能コードを組み合わせるので、開発者はそのアプリケーションの独自な部分に集中することができ、設計やコードの問題点を発見しやすくなる。配布前の検証も容易である。
; 生産性
: 開発工程の多くの部分が定型化され自動化される。<ref name="MSDN" />

これらの利点は以下に示すように関係者の立場によって異なる価値を提供する。

=== 事業にとっての価値 ===
ビジネスタスクは簡素化でき、それによってユーザーの生産性を増大させることができる。これは共通の一貫したユーザインタフェースを使うことにより達成され、エンドユーザーのトレーニングの必要性を低減させる。新たな機能の配備が容易でユーザインタフェースが柔軟であるため、エンドユーザーはビジネス[[ワークフロー]]に従った方法でタスクを実行可能である。データ品質が改善されるため、コピー・アンド・ペーストなどでアプリケーションのパーツ間でデータをコピーする必要性が低減される<ref name="MSDN2">{{Cite web | publisher = MSDN | url = http://msdn.microsoft.com/en-us/library/ff699279.aspx | title = Software Factories: Scenarios and Benefits |accessdate=2013-04-17}}</ref>。

=== アーキテクトにとっての価値 ===
アーキテクトにとっては、アプリケーションやシステムの設計にソフトウェアファクトリーを使うことで、品質と一貫性を向上させることができる。最重要な機構と共通の要素だけを含む部分的な実装が可能なためである。これはベースラインアーキテクチャなどと呼ばれるもので、設計と開発を容易にし、アーキテクチャ上の決定を明確化し、開発の初期段階でのリスクを低減させる。ソフトウェアファクトリーはまた、一貫した予測可能な形でビジネスコンポーネントを開発・パッケージ・配備・更新可能で、ビジネスロジックとは独立なアーキテクチャ上の標準を実施可能である<ref name="MSDN2" />。

=== 開発者にとっての価値 ===
開発者はソフトウェアファクトリーを使うことで立ち上がり時間を短縮して生産性を増大させることができる。これは、コードとパターンを含むアプリケーションの高品質な出発点（ベースライン）を作成できるためである。つまり、プロジェクトが従来の開発方式より高いレベルから始まることを意味する。再利用可能な資産、ガイダンス、例などにより、典型的なシナリオやタスクに容易に対応でき、一貫した形で応用可能である。ソフトウェアファクトリーはアプリケーションの複雑さを隠蔽する抽象化層を提供し、[[関心の分離|関心を分離]]する。そのため個々の開発者はビジネスロジックやユーザインタフェースなどそれぞれ異なる分野に集中でき、根底にあるサービスについて深い知識を必要としない<ref name="MSDN2" />。

=== 運用にとっての価値 ===
ソフトウェアファクトリーで構築されたアプリケーションは操作が一貫していて習得しやすい。そのため共通のビジネス要素とモジュールを容易に展開でき、一連のアプリケーションを通じた一貫した構成管理を可能とする。アプリケーションは相互に組み合わせ可能なアーキテクチャになっており、運用チームが基本的なサービスを制御可能である<ref name="MSDN2" />。

== 他の定義 ==
ソフトウェアファクトリーという概念についてはいくつかの対照的な見方があり、ツール指向な見方やプロセス指向な見方など様々である。以下では、日本、ヨーロッパ、北米で生まれた見方について解説する<ref name="Aaen"/>。

=== 製造業化されたソフトウェア開発組織（日本） ===
このアプローチのソフトウェアファクトリーで生み出されたソフトウェアは主に原子炉、タービンなどの制御システムである。主な目的は生産性に見合った品質の確保であり、コストが増大しても競争力が弱まらない分野に適用された。設計・プログラミング・テスト・インストール・保守を一貫した形で実施するための環境を整備するという目的もある。

品質と生産性向上の鍵は、ソフトウェアは再利用である。組織的設計では、運用業務を規定通りな簡単で反復的なものにする断固とした努力を含み、業務プロセスの標準化を伴う。

代表例として[[東芝]]が適用したソフトウェアファクトリーの概念があり、1981年と1987年に論文が発表されている。

=== 汎用ソフトウェアファクトリー（ヨーロッパ） ===
[[EUREKA]]プログラムの下で資金提供された Eureka ソフトウェアファクトリーと呼ばれるものである。ヨーロッパの大企業、コンピュータメーカー、ソフトウェアハウス、研究機関、大学がプロジェクトに参加している。個別の供給業者が販売するコンポーネント群を集積してソフトウェアファクトリーを構築するために、技術、標準、組織的サポート、その他の基盤を提供することを目的としている。

[[統合開発環境]]のアーキテクチャとフレームワークを生み出すことを目的としている。汎用ソフトウェアファクトリーは、その一部となるコンポーネント群や生産環境だけでなく、ソフトウェアコンポーネントの標準とガイダンスも開発する。

=== 経験ベースのソフトウェアファクトリ（北米） ===
[[ゴダード宇宙飛行センター]] (NASA) のソフトウェア工学研究所で開発された。このアプローチの目的は「生産環境におけるソフトウェアプロセスを理解し、入手可能な技術の影響を判定し、改良した技法を開発プロセスに吹き込むこと」である。生産環境で新技術を試し、それによって得られた経験とデータを適用し、コスト、信頼性、品質への影響を測定した。

このアプローチは継続的な改良に主眼が置かれており、プロセス特性と製品品質の関係を理解することで改良していく。長所と短所を把握することでその後のプロジェクトで活用できる経験を蓄積する。

=== 成熟したソフトウェア開発組織（北米） ===
[[能力成熟度モデル統合|能力成熟度モデル]]で定義されたもので、予測可能で信頼できる、自律的に改善するソフトウェア開発プロセスを達成するフレームワークを生み出すことを意図していた。その戦略はソフトウェア開発組織の段階的改善から成り、どの工程が開発における鍵であるかを定義する。測定可能な範囲にとどめようとするので、開発工程と品質は予測可能となる。

== 歴史 ==
ソフトウェアファクトリーという用語を最初に採用したのは[[日立製作所]]で、1969年のことである。その後1975年には System Development Corporation などの企業が採用した<ref>{{Cite journal | first1 = H. | last1 = Bratman | first2 = T. | last2 = Court | title = The Software Factory | journal = Computer | volume = 8 | issue = 5 | year = 1975 | pages = 28–37 }}</ref>。1976年から1977年にかけて、[[日本電気]]<ref>[http://www.nec.com/en/global/prod/pflow/images_documents/NEC_Software_Factory.pdf NEC Software Factory]</ref>、[[東芝]]、[[富士通]]といった企業が追随した<ref name="Cusumano 1989">{{Cite journal | first = Michael A. | last = Cusumano | title = The Software Factory: A Historical Interpretation | journal = IEEE Software | date = March 1989 }}</ref><ref>{{Cite journal | first = M. L. | last = Griss | id = {{Citeseerx|10.1.1.88.2855}} | title = Software reuse: From library to factory | journal = IBM Systems Journal | volume = 32 | issue = 4 | year = 1993 }}</ref><ref name="Aaen">{{Cite conference | first1 = Ivan | last1 = Aaen | first2 = Peter | last2 = Bøttcher | first3 = Lars | last3 = Mathiassen | url = http://www.larsmathiassen.org/17.pdf | title = The Software Factory: Contributions and Illusions | booktitle = Proceedings of the Twentieth Information Systems Research Seminar | location = Scandinavia, Oslo | year = 1997 }}</ref>。

Cusumano はソフトウェアファクトリーを6つの段階に分けられるとした<ref name="Cusumano 1991">{{Cite journal | first = Michael A. | last = Cusumano | title = Factory Concepts and Practices in Software Development | journal = Annals of the History of Computing | volume = 13 | issue = 1 | year = 1991 }}</ref>。
* 基本的な組織と管理の構造（1960年代中ごろから1970年代初め）
* 技術的標準化（1970年代初めから1980年代初め）
* 工程の機械化（1970年代後半）
* 工程の改良と発展（1980年代初め）
* 統合された柔軟な自動化（1980年代中ごろ）
* 段階的な製品開発と様々な改良（1980年代後半）


== .NET のソフトウェアファクトリー ==
ソフトウェアファクトリーに対しては批判も多く、生産性が劇的にあがるはずがないとする見方もある。<!-- 批判的なブログ等は数々あるのだが、リンクを貼るほどのものでもないので -->
[[マイクロソフト]]の Software Factory は、[[2004年]]に発表した[[ソフトウェア開発工程]]の進化を目指したビジョンに基づいており<ref>Rashid Rick, [http://www.oopsla.org/2004/ShowEvent.do?id=801 The Future of Programming] [[OOPSLA]]'04 キーノート </ref>、[[.NET Framework]] の一部である。
<!-- 以下、おそらく英語版に荒らし的に書き込まれていた一文。詐欺呼ばわりしている。（訳者）
Of course, any software company who promises to build enterprise applications in far less time than the industry standard using the concept of a Software Factory as its sole reasoning is likely employing a scam. The old adage still stands: If it sounds too good to be true, it probably is. -->


==実装例==
=== 実装例 ===
[http://msdn.microsoft.com/practices/ Microsoft Patterns & Practices Team] は以下の4つのソフトウェアファクトリを開発している:
[http://msdn.microsoft.com/practices/ Microsoft Patterns & Practices Team] は以下の4つのソフトウェアファクトリを開発している:
* [http://msdn2.microsoft.com/en-us/library/aa480482.aspx Smart Client Software Factory] （以前の名称は ''Smart Client Baseline Architecture Toolkit''）（[[2006年]][[6月30日]]リリース）
* [http://msdn2.microsoft.com/en-us/library/aa480482.aspx Smart Client Software Factory] （以前の名称は ''Smart Client Baseline Architecture Toolkit''）（[[2006年]][[6月30日]]リリース）
35行目: 121行目:
* [http://www.nconstruct.com NConstruct - Intelligent Software Factory]
* [http://www.nconstruct.com NConstruct - Intelligent Software Factory]


=== 影響と批判 ===
==参考文献==
[[日本]]では、[[2006年]]11月27日、[[京都高度技術研究所]]が「ソフトウェアファクトリ研究会」を発足させた[http://itpro.nikkeibp.co.jp/article/NEWS/20061128/255087/]。これはマイクロソフトの動きに直接関係したものではないが、マイクロソフトの動きに刺激されて、かつての「ソフトウェア工場」のコンセプトが甦ってきたものと言える[http://itpro.nikkeibp.co.jp/article/OPINION/20061031/252274/]。
<references />

ソフトウェアファクトリーに対しては批判も多く、生産性が劇的にあがるはずがないとする見方もある。

== 参考文献 ==
* Jack Greenfield, Keith Short, Steve Cook, Stuart Kent, John Crupi, <cite>Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools</cite>, ISBN 0-471-20284-3 （日本語版 ISBN 4-89100-472-X ）
* Jack Greenfield, Keith Short, Steve Cook, Stuart Kent, John Crupi, <cite>Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools</cite>, ISBN 0-471-20284-3 （日本語版 ISBN 4-89100-472-X ）
* Jack Greenfield, [http://msdn2.microsoft.com/en-us/library/ms954811.aspx Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools] (Microsoft, 2004)
* Jack Greenfield, [http://msdn2.microsoft.com/en-us/library/ms954811.aspx Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools] (Microsoft, 2004)


==関連項目==
== 脚注 ==
{{Reflist}}
<!-- * [[Factorette]] -->

== 関連項目 ==
* [[ISO 12207]]
* [[ソフトウェア工学]]
* [[システム工学]]
* [[ソフトウェア開発工程]]
* [[自動プログラミング]]
* [[ソースコード生成]]
* [[ソースコード生成]]
* [[ドメイン固有モデリング]] (DSM)
* [[ドメイン固有モデリング]] (DSM)
* [[モデル駆動工学]] (MDE)
* [[モデル駆動工学]] (MDE)


==外部リンク==
== 外部リンク ==
* [http://www.microsoft.com/japan/msdn/architecture/sf/whatis.aspx ソフトウェアファクトリーとは何か？] （Microsoft .NET Architecture Center、日本語版）
* [http://www.microsoft.com/japan/msdn/architecture/sf/whatis.aspx ソフトウェアファクトリーとは何か？] （Microsoft .NET Architecture Center、日本語版）
* [http://msdn.microsoft.com/vstudio/teamsystem/workshop/sf/ Software Factories] （Microsoft .NET Architecture Center）
* [http://www.tangiblearchitect.com tangible architect - .NET Software Factory with DSL Modeller]
* [http://www.nconstruct.com NConstruct - Intelligent Software Factory]


{{DEFAULTSORT:そふとうえあふあくとり}}
{{DEFAULTSORT:そふとうえあふあくとり}}

2013年4月17日 (水) 23:48時点における版

ソフトウェアファクトリー（Software Factory）とは、関連するソフトウェア資産の構造化された集合体であり、特定の外部インタフェース定義に従ったソフトウェアアプリケーションまたはソフトウェアコンポーネントの製造を助ける[1]。ソフトウェアファクトリーは、製造業の技法と原則をソフトウェア開発に適用するもので、それによって製造業の長所を模倣しようとするものである。ソフトウェアファクトリーは一般にソフトウェア製造のアウトソーシングと関係が深い。

概要

ソフトウェア工学とエンタープライズアーキテクチャやソフトウェアアーキテクチャにおいて、ソフトウェアファクトリーは、様々なツール、プロセス、コンテンツを定型的な方式で設定するソフトウェアであり、フレームワークに基づいた適応・組み立て・設定により原型となるソフトウェア製品からの派生品の開発と保守を自動化するものである[2]。

コーディングは（製造業における職人のような）専門的技量を必要とするので、アプリケーション層ではコーディングの必要性を排除し、IDEを使う代わりに事前定義されたコンポーネント群を組み合わせることでソフトウェアを構築する。コーディングは新たなコンポーネントやサービスを開発するときのみ必要とされる。製造業と同様、コンポーネント（部品）の開発とシステムの構築には技術が必要である。ソフトウェアファクトリーによって得られるのは、複合アプリケーション（英語版）である。

目的

ソフトウェアファクトリーは、従来のアプリケーション開発において、似たようなアプリケーションの開発で得られた知識や資産を生かしていなかったという問題への対処である。ソフトウェアファクトリー以外にも、トレーニング、文書化、フレームワークといった対策がとられてきたが、様々なアプリケーション開発で得られた貴重な知識の伝達という意味では、間違いやすいプロセスでもある。

ソフトウェアファクトリーは、特定スタイルのアプリケーション開発の成果を再利用しやすいパッケージ内に統合することでこの問題に対処する。適切なソフトウェアファクトリーを使ったアプリケーション開発には、生産性や品質の向上、機能の発展性といった多くの長所がある[1]。

コンポーネント

個々のソフトウェアファクトリーは特定種類のアプリケーションの構築に特化しており、そのために設計された独自の資産を含む。一般に、多くのソフトウェアファクトリーは次のような相互に関連する資産を含む[2]。

ファクトリースキーマ
システムの構築や保守に使用する資産群を分類し説明した文書（XML文書など）であり、整理されており、資産間の関係が定義されている。
リファレンス実装
そのソフトウェアファクトリーで構築できる具体的製品の例。
アーキテクチャのガイダンスとパターン
アプリケーション設計における選択とその理由について説明する。
ハウツー
タスク完成のための手順や指示。
レシピ
ハウツーにある手順（全体または一部）を自動化したもの。定型的なタスクを最小の入力で完成させることができる。
テンプレート
事前に組み立てられたアプリケーションの一部。プロジェクトに起点として使うことができる。
デザイナー
開発者がより高い抽象レベルでアプリケーション作成に使える情報を提供。
再利用可能コード
一般的な機能や機構を実装したコンポーネント群。再利用可能コードを組み合わせることでコーディングの必要性を削減し、アプリケーション間の再利用性を高める[1]。

製品開発

ソフトウェアファクトリーによる製品構築には、以下のような活動が関与する。

問題分析
製品がソフトウェアファクトリーの対象範囲内のものかどうかを判定する。この判断により、製品全体または一部をソフトウェアファクトリーで構築するかどうかが決定される。
製品仕様
ソフトウェアファクトリーの提供する機構と製品の要求仕様から、差異、すなわち実装すべき要件を定義する。
製品設計
その差異をどう実装するかを設計する。
製品実装
様々な機構を利用して実装する。
製品配備
デフォルトのインストール方式を使うか、必要な拡張を施す。
製品試験
ツールを利用し試験用資産（テストケース、データ、スクリプトなど）を再利用または開発する。[2]

利点

ソフトウェアファクトリーによるアプリケーション開発は、従来のソフトウェア開発に比べて様々な利点がある。

一貫性
ソフトウェアファクトリーは似たような機能やアーキテクチャのソフトウェア製品群の構築に利用でき、それらの一貫性を容易に達成できる。それによって運用が単純化され、トレーニングや保守のコストが削減される。
品質
有効であることが証明済みの慣習を容易に学習・実装できる。再利用可能コードを組み合わせるので、開発者はそのアプリケーションの独自な部分に集中することができ、設計やコードの問題点を発見しやすくなる。配布前の検証も容易である。
生産性
開発工程の多くの部分が定型化され自動化される。[1]

これらの利点は以下に示すように関係者の立場によって異なる価値を提供する。

事業にとっての価値

ビジネスタスクは簡素化でき、それによってユーザーの生産性を増大させることができる。これは共通の一貫したユーザインタフェースを使うことにより達成され、エンドユーザーのトレーニングの必要性を低減させる。新たな機能の配備が容易でユーザインタフェースが柔軟であるため、エンドユーザーはビジネスワークフローに従った方法でタスクを実行可能である。データ品質が改善されるため、コピー・アンド・ペーストなどでアプリケーションのパーツ間でデータをコピーする必要性が低減される[3]。

アーキテクトにとっての価値

アーキテクトにとっては、アプリケーションやシステムの設計にソフトウェアファクトリーを使うことで、品質と一貫性を向上させることができる。最重要な機構と共通の要素だけを含む部分的な実装が可能なためである。これはベースラインアーキテクチャなどと呼ばれるもので、設計と開発を容易にし、アーキテクチャ上の決定を明確化し、開発の初期段階でのリスクを低減させる。ソフトウェアファクトリーはまた、一貫した予測可能な形でビジネスコンポーネントを開発・パッケージ・配備・更新可能で、ビジネスロジックとは独立なアーキテクチャ上の標準を実施可能である[3]。

開発者にとっての価値

開発者はソフトウェアファクトリーを使うことで立ち上がり時間を短縮して生産性を増大させることができる。これは、コードとパターンを含むアプリケーションの高品質な出発点（ベースライン）を作成できるためである。つまり、プロジェクトが従来の開発方式より高いレベルから始まることを意味する。再利用可能な資産、ガイダンス、例などにより、典型的なシナリオやタスクに容易に対応でき、一貫した形で応用可能である。ソフトウェアファクトリーはアプリケーションの複雑さを隠蔽する抽象化層を提供し、関心を分離する。そのため個々の開発者はビジネスロジックやユーザインタフェースなどそれぞれ異なる分野に集中でき、根底にあるサービスについて深い知識を必要としない[3]。

運用にとっての価値

ソフトウェアファクトリーで構築されたアプリケーションは操作が一貫していて習得しやすい。そのため共通のビジネス要素とモジュールを容易に展開でき、一連のアプリケーションを通じた一貫した構成管理を可能とする。アプリケーションは相互に組み合わせ可能なアーキテクチャになっており、運用チームが基本的なサービスを制御可能である[3]。

他の定義

ソフトウェアファクトリーという概念についてはいくつかの対照的な見方があり、ツール指向な見方やプロセス指向な見方など様々である。以下では、日本、ヨーロッパ、北米で生まれた見方について解説する[4]。

製造業化されたソフトウェア開発組織（日本）

このアプローチのソフトウェアファクトリーで生み出されたソフトウェアは主に原子炉、タービンなどの制御システムである。主な目的は生産性に見合った品質の確保であり、コストが増大しても競争力が弱まらない分野に適用された。設計・プログラミング・テスト・インストール・保守を一貫した形で実施するための環境を整備するという目的もある。

品質と生産性向上の鍵は、ソフトウェアは再利用である。組織的設計では、運用業務を規定通りな簡単で反復的なものにする断固とした努力を含み、業務プロセスの標準化を伴う。

代表例として東芝が適用したソフトウェアファクトリーの概念があり、1981年と1987年に論文が発表されている。

汎用ソフトウェアファクトリー（ヨーロッパ）

EUREKAプログラムの下で資金提供された Eureka ソフトウェアファクトリーと呼ばれるものである。ヨーロッパの大企業、コンピュータメーカー、ソフトウェアハウス、研究機関、大学がプロジェクトに参加している。個別の供給業者が販売するコンポーネント群を集積してソフトウェアファクトリーを構築するために、技術、標準、組織的サポート、その他の基盤を提供することを目的としている。

統合開発環境のアーキテクチャとフレームワークを生み出すことを目的としている。汎用ソフトウェアファクトリーは、その一部となるコンポーネント群や生産環境だけでなく、ソフトウェアコンポーネントの標準とガイダンスも開発する。

経験ベースのソフトウェアファクトリ（北米）

ゴダード宇宙飛行センター (NASA) のソフトウェア工学研究所で開発された。このアプローチの目的は「生産環境におけるソフトウェアプロセスを理解し、入手可能な技術の影響を判定し、改良した技法を開発プロセスに吹き込むこと」である。生産環境で新技術を試し、それによって得られた経験とデータを適用し、コスト、信頼性、品質への影響を測定した。

このアプローチは継続的な改良に主眼が置かれており、プロセス特性と製品品質の関係を理解することで改良していく。長所と短所を把握することでその後のプロジェクトで活用できる経験を蓄積する。

成熟したソフトウェア開発組織（北米）

能力成熟度モデルで定義されたもので、予測可能で信頼できる、自律的に改善するソフトウェア開発プロセスを達成するフレームワークを生み出すことを意図していた。その戦略はソフトウェア開発組織の段階的改善から成り、どの工程が開発における鍵であるかを定義する。測定可能な範囲にとどめようとするので、開発工程と品質は予測可能となる。

歴史

ソフトウェアファクトリーという用語を最初に採用したのは日立製作所で、1969年のことである。その後1975年には System Development Corporation などの企業が採用した[5]。1976年から1977年にかけて、日本電気[6]、東芝、富士通といった企業が追随した[7][8][4]。

Cusumano はソフトウェアファクトリーを6つの段階に分けられるとした[9]。

  • 基本的な組織と管理の構造（1960年代中ごろから1970年代初め）
  • 技術的標準化（1970年代初めから1980年代初め）
  • 工程の機械化（1970年代後半）
  • 工程の改良と発展（1980年代初め）
  • 統合された柔軟な自動化（1980年代中ごろ）
  • 段階的な製品開発と様々な改良（1980年代後半）

.NET のソフトウェアファクトリー

マイクロソフトの Software Factory は、2004年に発表したソフトウェア開発工程の進化を目指したビジョンに基づいており[10]、.NET Framework の一部である。

実装例

Microsoft Patterns & Practices Team は以下の4つのソフトウェアファクトリを開発している:

Project Glidepath はマイクロISV指向のソフトウェアファクトリー。マイクロソフトからもリリースされている。

EFx Factory は Microsoft Services が他に先駆けてリリースしたアーキテクチャ的ソフトウェアファクトリーであり、モデル駆動開発と統合実行環境ツールによってサービス指向の企業アプリケーションを構築する。

.NET Database Application Development

影響と批判

日本では、2006年11月27日、京都高度技術研究所が「ソフトウェアファクトリ研究会」を発足させた[1]。これはマイクロソフトの動きに直接関係したものではないが、マイクロソフトの動きに刺激されて、かつての「ソフトウェア工場」のコンセプトが甦ってきたものと言える[2]。

ソフトウェアファクトリーに対しては批判も多く、生産性が劇的にあがるはずがないとする見方もある。

参考文献

脚注

  1. ^ a b c d “Software Factories”. MSDN. 2013年4月16日閲覧。
  2. ^ a b c Greenfield, Jack; Short, Keith; Cook, Steve; Kent, Stuart (2004). Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. ISBN 0-471-20284-3 
  3. ^ a b c d “Software Factories: Scenarios and Benefits”. MSDN. 2013年4月17日閲覧。
  4. ^ a b Aaen, Ivan; Bøttcher, Peter; Mathiassen, Lars (1997). "The Software Factory: Contributions and Illusions" (PDF). Proceedings of the Twentieth Information Systems Research Seminar. Scandinavia, Oslo.
  5. ^ Bratman, H.; Court, T. (1975). “The Software Factory”. Computer 8 (5): 28–37. 
  6. ^ NEC Software Factory
  7. ^ Cusumano, Michael A. (March 1989). “The Software Factory: A Historical Interpretation”. IEEE Software. 
  8. ^ Griss, M. L. (1993). “Software reuse: From library to factory”. IBM Systems Journal 32 (4). CiteSeerx: 10.1.1.88.2855. 
  9. ^ Cusumano, Michael A. (1991). “Factory Concepts and Practices in Software Development”. Annals of the History of Computing 13 (1). 
  10. ^ Rashid Rick, The Future of Programming OOPSLA'04 キーノート

関連項目

外部リンク

「https://ja.wikipedia.org/w/index.php?title=ソフトウェアファクトリー&oldid=47513266」から取得