ソフトウェアファクトリー

ソフトウェアファクトリー（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. “Software Factories”. MSDN. 2013年4月16日閲覧。
  2. 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. “Software Factories: Scenarios and Benefits”. MSDN. 2013年4月17日閲覧。
  4. 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 キーノート

関連項目

外部リンク
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.