ソフトウェア工場

ソフトウェアファクトリーは、関連するソフトウェア資産の構造化されたコレクションであり、組み立てプロセスを通じて、特定の外部で定義されたエンド ユーザー要件に従ってコンピューター ソフトウェア アプリケーションまたはソフトウェア コンポーネントを作成するのに役立ちます。^{[1]ソフトウェア ファクトリーは、従来の製造の利点を模倣するために、}製造技術と原則をソフトウェア開発に適用します。ソフトウェア ファクトリーは通常、アウトソーシングされたソフトウェアの作成に関与しています。

ソフトウェアエンジニアリングとエンタープライズ ソフトウェアアーキテクチャにおいて、ソフトウェアファクトリーとは、フレームワークベースのコンポーネントを適応、組み立て、構成することで、典型的な製品のバリアントの開発と保守を自動化するために、スキーマに基づくテンプレートを使用して広範なツール、プロセス、コンテンツを構成するソフトウェア製品ラインです。^[2]

コーディングにはソフトウェア エンジニア(または従来の製造業で言う熟練した職人) が必要なので、アプリケーション レイヤーのプロセスからはコーディングが排除され、従来のIDE を使用する代わりに、定義済みのコンポーネントを組み立てることでソフトウェアが作成されます。従来のコーディングは、新しいコンポーネントまたはサービスを作成するためだけに残されています。従来の製造業と同様に、エンジニアリングはコンポーネントの作成とシステムの要件収集に残されています。ソフトウェア ファクトリーでの製造の最終結果は、複合アプリケーションです。

ソフトウェア ファクトリー ベースのアプリケーション開発は、従来のアプリケーション開発の問題に対処します。従来のアプリケーション開発では、類似のアプリケーションの開発で得られた知識や生成された資産を活用せずにアプリケーションが開発および提供されます。この問題に対処するために、トレーニング、ドキュメント、フレームワークなどの多くのアプローチが使用されていますが、これらのアプローチを使用して、複数のアプリケーションの開発中に以前に得られた貴重な知識を一貫して適用することは、非効率的でエラーが発生しやすいプロセスになる可能性があります。

ソフトウェアファクトリーは、プロジェクトチームが簡単に採用できる統合ガイダンスパッケージ内に、特定のスタイルのアプリケーションを開発するための実証済みのプラクティスをエンコードすることで、この問題に対処します。適切なソフトウェアファクトリーを使用してアプリケーションを開発すると、生産性、品質、進化能力の向上など、多くの利点が得られます。^[1]

ソフトウェア ファクトリは固有のものであり、特定の種類のアプリケーションの構築に役立つように設計された固有の資産セットが含まれています。一般に、ほとんどのソフトウェア ファクトリには、次の種類の相互に関連する資産が含まれています。

• ファクトリスキーマ：システムの構築と維持に使用される資産（ XML文書、モデルなど）を整理して分類し、要約し、それらの関係を定義する文書。 ^[2]
• リファレンス実装:ソフトウェア ファクトリーが開発者の構築を支援する現実的な完成品の例を提供します。
• アーキテクチャのガイダンスとパターン:アプリケーション設計の選択とその選択の理由を説明するのに役立ちます。
• ハウツートピック:タスクを完了するための手順と指示を提供します。
• レシピ:ハウツートピックの手順を、全体または特定のステップで自動化します。これにより、開発者は最小限の入力で日常的なタスクを完了できるようになります。
• テンプレート:引数のプレースホルダーを備えた事前に作成されたアプリケーション要素。初期プロジェクト項目の作成に使用できます。
• デザイナー:開発者がより高い抽象レベルでアプリケーションをモデル化するために使用できる情報を提供します。
• 再利用可能なコード:共通の機能やメカニズムを実装するコンポーネント。ソフトウェアファクトリーに再利用可能なコードを統合すると、手動で記述するコードの必要性が減り、アプリケーション間での再利用が促進されます。 ^[1]

ソフトウェア ファクトリーを使用して製品を構築するには、次のアクティビティが必要です。

• 問題分析:製品がソフトウェア ファクトリーの範囲内にあるかどうかを判断します。適合性により、製品のすべてまたは一部がソフトウェア ファクトリーで構築されるかどうかが判断されます。
• 製品仕様:さまざまな製品仕様メカニズムを使用して、製品ライン要件との違いを概説することにより、製品要件を定義します。
• 製品設計:要件の違いを製品ラインのアーキテクチャと開発プロセスの違いにマッピングして、カスタマイズされたプロセスを作成します。
• 製品の実装:差異の程度に応じて、さまざまなメカニズムを使用して実装を開発できます。
• 製品の展開:デフォルトの展開制約を作成または再利用し、展開される実行可能ファイルをインストールするために必要なリソースを構成します。
• 製品テスト：テスト資産（テストケース、データセット、スクリプトなど）の作成または再利用と、計測および測定ツールの適用が含まれます^{。 [2]}

ソフトウェア ファクトリーを使用してアプリケーションを開発すると、従来のソフトウェア開発アプローチに比べて多くの利点が得られます。これには次の利点が含まれます。

• 一貫性:ソフトウェア ファクトリを使用すると、ソフトウェア製品ライン (類似の機能とアーキテクチャを共有するアプリケーションのセット) の複数のインスタンスを構築できるため、一貫性の実現が容易になります。これにより、ガバナンスが簡素化され、トレーニングとメンテナンスのコストも削減されます。
• 品質:ソフトウェア ファクトリを使用すると、開発者は実証済みのプラクティスを学習して実装しやすくなります。再利用可能なコードが統合されているため、開発者は各アプリケーションに固有の機能の開発に多くの時間を費やすことができ、設計上の欠陥やコード欠陥の可能性が減ります。ソフトウェア ファクトリを使用して開発されたアプリケーションは、展開前に検証することもできるため、開発中にファクトリ固有のベスト プラクティスに従っていることを確認できます。
• 生産性:ソフトウェア資産の再利用や、アプリケーション要素とメカニズムの抽象化からのコード生成など、多くのアプリケーション開発活動を合理化および自動化できます。^[1]

これらの利点は、次のようにさまざまなチームに価値をもたらします。

ビジネスタスクを簡素化することで、ユーザーの生産性を大幅に向上させることができます。これは、エンドユーザーのトレーニングの必要性を減らす、共通で一貫性のあるユーザーインターフェイスを使用することで実現されます。新しい機能や更新された機能を簡単に導入でき、ユーザーインターフェイスが柔軟であるため、エンドユーザーはビジネスワークフローに従ってタスクを実行できます。データ品質の向上により、ALT + TABやコピーアンドペーストのテクニックを使用してアプリケーションパーツ間でデータを交換する必要性が減ります。^[3]

ソフトウェア ファクトリーは、品質と一貫性を向上させたアプリケーションやシステムを設計するために設計者が使用できます。これは、最も重要なメカニズムと共有要素のみを含むソリューションの部分的な実装を作成する機能によって実現されます。ベースライン アーキテクチャと呼ばれるこのタイプの実装は、設計と開発の課題に対処し、アーキテクチャ上の決定を明らかにし、開発サイクルの早い段階でリスクを軽減できます。ソフトウェア ファクトリーを使用すると、ビジネス ロジックとは無関係にアーキテクチャ標準を適用するために、ビジネス コンポーネントの開発、パッケージ化、展開、更新を行う一貫性のある予測可能な方法を作成することもできます。^[3]

開発者は、ソフトウェア ファクトリーを使用して生産性を高め、立ち上げ時間を短縮できます。これは、コードとパターンを含むアプリケーションの高品質な開始点 (ベースライン) を作成することで実現されます。これにより、従来の方法で開発されたアプリケーションよりも高い成熟度でプロジェクトを開始できます。再利用可能なアセット、ガイダンス、および例は、一般的なシナリオと課題に対処するのに役立ち、一般的なタスクの自動化により、開発者は一貫した方法でガイダンスを簡単に適用できます。ソフトウェア ファクトリーは、アプリケーションの複雑さを隠し、懸念を分離する抽象化レイヤーを提供します。これにより、開発者はインフラストラクチャやベースライン サービスに関する詳細な知識がなくても、ビジネス ロジック、ユーザー インターフェイス (UI)、アプリケーション サービスなどのさまざまな領域に集中できます。一般的な開発者タスクの抽象化とインフラストラクチャ コードの再利用性の向上は、生産性と保守性の向上に役立ちます。^[3]

ソフトウェアファクトリーで構築されたアプリケーションは、運用作業の統合をもたらします。これにより、共通のビジネス要素とモジュールの展開が容易になり、アプリケーションスイート全体で一貫した構成管理が可能になります。アプリケーションは、運用チームが基本的なサービスを制御できるプラグ可能なアーキテクチャで集中管理できます。^[3]

ソフトウェアファクトリーの概念については、ツール指向からプロセス指向まで、対照的な視点を表すアプローチがいくつかあります。以下のアプローチは、日本、ヨーロッパ、北米の取り組みをカバーしています。^[4]

このアプローチでは、ソフトウェアファクトリーで生産されたソフトウェアは、主に制御システム、原子炉、タービンなどに使用されます。このアプローチの主な目的は、コストの増加によって競争力が低下しないように、生産性と品質を一致させることです。また、設計、プログラミング、テスト、インストール、メンテナンスを統一的に実行できる環境を構築することも目的の1つです。

品質と生産性を向上させる鍵は、ソフトウェアの再利用です。組織設計の主な特徴には、運用作業をルーチン化、単純化、反復化し、作業プロセスを標準化するための断固たる努力が含まれます。

このアプローチの代表例は、東芝のソフトウェア ファクトリー コンセプトです。これは、1981 年と 1987 年当時の同社のソフトウェア部門と手順を表しています。

このアプローチは、ユーレカ プログラムによって資金提供され、ユーレカ ソフトウェア ファクトリーと呼ばれています。このプロジェクトには、ヨーロッパの大手企業、コンピューター メーカー、ソフトウェア ハウス、研究機関、大学などが参加しています。このアプローチの目的は、独立したサプライヤーが販売するコンポーネントからソフトウェア ファクトリーを構築し、カスタマイズできるように、テクノロジ、標準、組織的サポート、その他の必要なインフラストラクチャを提供することです。

このアプローチの目的は、統合開発環境のアーキテクチャとフレームワークを作成することです。汎用ソフトウェア ファクトリーは、ソフトウェア ファクトリーの一部であるコンポーネントと運用環境を、ソフトウェア コンポーネントの標準とガイダンスとともに開発します。

経験に基づくコンポーネント ファクトリーは、NASA ゴダード宇宙飛行センターのソフトウェア エンジニアリング研究所で開発されています。このアプローチの目標は、「生産環境におけるソフトウェア プロセスを理解し、利用可能なテクノロジの影響を判断し、特定/改良された方法を開発プロセスに再び取り入れること」です。このアプローチでは、生産環境で新しいテクノロジを試し、実験から経験とデータを抽出して適用し、コスト、信頼性、品質に関する影響を測定します。

このアプローチでは、特定のプロセス特性と製品品質の関係を理解することによる継続的な改善を重視します。ソフトウェア ファクトリーは、長所と短所に関するデータを収集して改善のベースラインを設定し、新しいプロジェクトで再利用する経験を収集するために使用されます。

能力成熟度モデルによって定義されたこのアプローチは、高品質のソフトウェアを生み出す、予測可能で信頼性が高く、自己改善するソフトウェア開発プロセスを実現するためのフレームワークを作成することを目的としています。この戦略は、ソフトウェア編成の段階的な改善で構成され、開発においてどのプロセスが重要かを定義します。ソフトウェア プロセスとソフトウェア製品の品質は、測定可能な制限内に維持されるため、予測可能です。

• この用語を最初に採用したのは、 1969年に日立製作所が日立ソフトウェアワークスで採用した企業である。その後、 1975年にシステム開発株式会社などの企業が採用した。 ^[5]
• NEC、東芝、富士通は1976年と1977年に同様の組織アプローチを採用した。^{[6] [7] [4]}

Cusumano ^[8]はソフトウェア工場には6つのフェーズがあると示唆している。

• 基本的な組織と経営構造（1960年代半ばから1970年代前半）
• 技術のカスタマイズと標準化（1970年代前半から1980年代前半）
• プロセスの機械化とサポート（1970年代後半）
• プロセスの改良と拡張（1980年代初頭）
• 統合された柔軟な自動化（1980 年代半ば）
• 漸進的な製品/品種改良（1980年代後半）

• ソフトウェア製品ライン
• ソフトウェアライフサイクルプロセス
• ソフトウェアエンジニアリング
• システムエンジニアリング
• ソフトウェア開発プロセス
• 自動プログラミング
• ドメイン固有モデリング(DSM)
• モデル駆動エンジニアリング(MDE)

• ハーバード・ビジネス・レビュー ウィプロ・テクノロジーズ: ファクトリー・モデル
• オフショアリングなしのアウトソーシングが「ソフトウェア ファクトリー」の目的である PJ コノリー著