1C：ERPの開発方法（だけでなく）

こんにちは、Habr！

以前の記事の1つでは、1C：Enterpriseプラットフォームの開発プロセスがどのように編成されたかについて説明しました。 そして今日、最も包括的な、おそらく最も包括的なアプリケーションソリューション1C- 1C：ERP Enterprise Management 2を （1C：Enterpriseプラットフォームのツールを使用して）開発する方法をお伝えしたいと思います。

「1C：ERP Enterprise Management」は、大規模および中規模のビジネスを自動化する最良の世界および国内の慣行を考慮に入れて、技術的に洗練された多生産生産を含む、集学的企業の活動を管理するための統合情報システムを構築するための革新的なソリューションです。

少しインフォグラフィック：





今日（2016年3月）で、900を超える企業が1C：ERPのユーザーになり、その数は増え続けています。 同時に、開発者の観点から見ると、数十のプロジェクトが「パイロット」のステータスを受け取りました。 これらの企業および組織は主に新機能の開発に関与し、迅速にフィードバックを提供します。

1Cの一部のユーザーのロゴは次のとおりです。ERP：



1C：ERPソリューションの興味深い機能は、1 つのソリューション （1C：ERP）を開発し、そのソースから4つのソリューションを自動的に取得することです （機能を「切り取り」、機能オプションを切り替える）。

1. 実際には1C：ERP。 最も機能的なソリューションであり、中規模および大規模企業の何千ものジョブに実装できます。
   モジュール1C：ERP

   
   
   
   
   
   
2. 1C：統合オートメーション 。 その使用は、中小企業の成長するビジネスのコンテキストで最も効果的であり、その管理プロセスには、複数の実行者の明確な調整と調整されたアクションが必要です。
   詳細

   「Integrated Automation」構成、バージョン2.0は、「1C：Enterprise 7.7」プラットフォームで複雑な構成を操作した経験があるユーザー、および構成「Enterprise Accounting」 、 「Trade Management」 、 「給与および人事管理。」
   
   
   
   
   
3. 1C：貿易管理 。 運用および管理会計のタスク、取引操作の分析および計画を複雑に自動化できるため、現代の商社の効果的な管理が保証されます。
   
   
4. 1C：貿易管理。 基本バージョン 。 小規模な取引企業向けのソリューションでは、1つの組織（法人または個人の起業家）に代わって記録を保持できます。 構成の変更はサポートされていません。通常の構成のみを適用して更新をインストールできます。一度に1人のユーザーのみが1つのインフォベースを操作できます。1C：Enterprise 8サーバーでの操作はサポートされていません。 それは、実際、悪名高い「失速自動化」です。
   
   

自動化におけるビジネスの拡大または企業のニーズの増加時には、システムの機能の構築を段階的に行うことができ、「貿易管理」構成から「複雑な自動化」構成、そして「ERPエンタープライズ管理2」に移行します。 ソリューションは高度に統合されているため、このような移行は迅速に実行され、情報データベースに蓄積されたデータは保存され、ユーザーの再トレーニングは必要ありません。通常のソフトウェアおよび情報環境で引き続き動作します。

1Cのスペル：ERP

1つの決定から4つの決定方法

開発は1つのブランチ（ERP）でのみ実行されます。 フラッグシップERPソリューションから生成されるプロセスは、機能が制限された軽量の統合オートメーション（以下、略してCA）と2種類の貿易管理（以下、UTおよびUT Basic）が自動化されています。

ERPから「派生」構成（KA、UT、UT Basic）への変更は、 構成を比較および結合するメカニズムを使用して自動的に転送されます 。 このメカニズムはもともと、適用ソリューションの機能を変更/拡張するユーザーの適用ソリューションの新しいバージョンへの移行プロセスを自動化することを目的としていました。 構成を比較および結合するためのメカニズムは、3つの構成の分析に基づいて、3者間のセマンティックマージを実行します。

• ベンダーからの古い構成
• ベンダーからの新しい構成
• 現在のユーザー構成（プロバイダーからの古い構成に加えて、ユーザーが行った変更）

出力では、新しい機能（開発者が導入）を組み合わせ、ユーザーが行った改善（カスタマイズ）を保存する新しい現在の構成を取得します。

私たちの場合、現在の構成の役割は、サプライヤーからの古い構成と新しい構成の役割であるKA、UT、UT Basic、それぞれ古いバージョンと新しいバージョンのERPです。 つまり 機能的に制限された構成（KA、UT、UT Basic）は、ERPの（主に未使用のオブジェクトを削除することによって）カスタマイズされていると考えています。



各ソリューションに対して手動で記述された数少ないオブジェクトの1つは、このソリューションを他の1Cソリューション（1C：Document Managementなど）または外部機器などと統合するためのルールを定義する交換計画です。 ただし、データ交換が単一のEnterpriseData標準に段階的に移行しているため、特定のソリューションに固有の交換計画の数を減らし、単一のデータ交換コードを使用しようとしています。

このアプローチには1つの興味深い機能があります。 ソリューション全体は、ERPブランチに1回書き込まれます。 しかし、ほとんどのコード、フォーム、スクリプト、レポートなど。 4つのソリューションで使用され、まったく異なるソリューション-ERPは数千のユーザーを持つ企業に実装され、UT Basicは個々の起業家にサービスを提供するように設計されています。 製品の使いやすさに多くの注意を払っています。

国際規格ISO 9241-11は、ユーザビリティを次のように定義しています。

特定の使用状況で特定のユーザーが製品を使用して、効率、生産性、満足度を達成して特定の目標を達成できる程度

経験の浅いユーザーでも簡単かつ便利に作業できるようにアプリケーションを作成します。

開発機能

ERPを開発する場合、開発した機能が1つまたは複数のERP派生ソリューション（SC、UT、UT Basic）に関与する可能性があることを常に覚えておく必要があります。 オン/オフ機能を簡単にするために、このようなタスク用に元々作成された機能オプションメカニズムを広範囲に使用します 。 機能オプションを使用すると、アプリケーションソリューション自体を変更せずに、実装中にオン/オフできるアプリケーションソリューション機能を強調表示できます。 機能オプションはソリューション設定、フラグであり、オフにすると、それらに関連するすべての機能が使用できなくなります。 まず、機能オプションを使用して、特定の実装のニーズに合わせてプログラムを微調整します。 ERPでは、（主な目的に加えて）このメカニズムを使用して、ERPから派生した構成を「カット」します。 たとえば、ERPソリューションには、「エンタープライズ管理」という機能オプションがあり、生産管理を担当するすべての機能が関連付けられています-生産スケジュールの作成、生産コストの会計、関連レポートなど。 このオプションは、1C：ERPソリューションでのみ有効になり、宇宙船、UT、UT Basicの「派生」ソリューションでは無効になります。 そして合計で1C：ERPは約600の機能オプションを使用します。

1C：ERP開発者の作業を促進する別のプラットフォームメカニズムはサブシステムです。 サブシステムは、ソリューションの機能をブロックに分割する方法です。 ソリューションの各オブジェクト（リファレンスブック、ドキュメント、レポートなど）は、少なくとも1つのサブシステムに含まれている必要があります。 特に、ERPソリューションには、ERPソリューションの派生物の構築を容易にする3つのサブシステムがあります。

1. 「UP、UT、KAのオブジェクト」-適用されるすべてのソリューションに含まれるオブジェクト：貿易管理、統合自動化、エンタープライズ管理（ロシア語の名前ERP）。
2. 「UP、KAのオブジェクト」-Integrated AutomationおよびERPの構成のみに関連するオブジェクト。
3. 「UEオブジェクト」-ERPソリューションのみに関連するオブジェクト

ERPソリューションのアプリケーションオブジェクトは、3つのサブシステムのいずれかにのみ関連する必要があります。 この状態は、ERPソリューションコードの静的分析中にチェックされます（以下を参照）。

10進数

ERP製品バージョンは、ピリオドで区切られた4つの数字で構成されています。 例-2.1.3.117。

• バージョンの最初の番号（エディション）は、めったに変更されません（たとえば、KA 1.x.x.xとKA 2.x.x.xは、ほぼ8年間分離されています）。
• 2番目の数値（サブリビジョン）は、約1年に1回変更されます。 新しいリビジョンのバージョンでは、新しい機能がリリースされています。 このようなバージョンのリリースは、多くの場合、暦年の初めにタイミングが取られるため、ユーザーは新しいバージョンに「移動」するのに十分な時間があります。
• 新しい3番目の番号（リリース）のバージョンでは、既存の機能が開発されています。 新しいリリースは約2〜3か月に1回リリースされます。
• 4番目の番号が更新されたバージョン（パッチビルド）には、現在の法律に準拠するためのバグ修正と更新のみが含まれています。 2週間ごとに出てきます。

一度に、最大3つの製品バージョンを開発できます。たとえば、

1. 2.1.3.X-前のリビジョンのサポートされたリリース。 2016年末までにリリースされます。 このバージョンでは、エラーの修正と現在の法律に従うための修正のみがあります。
2. 2.2.1.X-現在のリビジョンの現在のリリース。 新しいサブ編集機能があります。 彼にとって、2.2.2.Xリリースのリリース前に、修正アセンブリが発行されます。
3. 2.2.2.X-現在のサブエディションの機能の開発。 このリリースは積極的に開発されています。

ERPの各ブランチから、ERPに加えて、KA、UT、UT Basicの3つのソリューションがさらにあることを考慮すると、12の異なるリポジトリに12のバージョンの製品があります。

開発中、次のような最大4つの計画期間があります。

1. 2.1.3（サポート）、どのエラーを修正するか、私たちが実施する法律の変更に関連するプロジェクトを決定します。 2016年に施行される変更のみが実装されます。 地平線-2016年末まで。
2. 2.2.1（サポート）-2.2.2のリリース前に発効する「外部」エラー+法律の変更が修正されました。 Horizo​​n-リリース2.2.2まで。
3. 2.2.2（積極的に開発中）-「外部」エラーが修正されました+見つかったエラー+新しい機能が実装されました。 Horizo​​n-リリース2.2.3より前
4. 2.2.3（予定）。 プロジェクトが大きい場合は、このバージョン用にすぐに開発できます（以前のバージョンには含まれません）。 Horizo​​n-リリース2.2.4まで、または2017年末まで。

ERPの開発に製品「1C：Applied Solutionsの設計システム」を使用する

すでに述べたように、1Cでは、社内の手順で独自の製品を使用して、 独自のドッグフードを食べるという原則に従うようにしています。 特に、ERPの開発では、 「1C：Applied Solutionsを設計するためのシステム」 （DSSと略記）という製品を広く使用しています。 DSSは、その名前が示すように、1C：エンタープライズプラットフォームでのアプリケーションソリューションの設計を支援し、要件の収集、変更の監視、文書化、バグ追跡など、ソフトウェア開発サイクル全体のタスクを提供できます。

DSSでは、エラー（修正が必要）と要件（新機能のリクエスト）の2種類の要素を作成できます。 エラーがある場合、すべてが多かれ少なかれ明確であるため、新しい要件の作成を検討してください。

要件を作成する理由は次のとおりです。

1. パートナーまたはクライアントからのリクエスト。 特にパートナーセミナーでこのようなリクエストを収集します。 パートナー間で投票することにより、最も優先度の高いパートナーを選び出します。
2. クライアントが彼への重要な希望を持っている場合、パイロットプロジェクト中に新しいバージョンを導入する要求が発生する場合があります。
3. テクニカルサポートサービスからのリクエスト（より正確には、テクニカルサポートを通過するパートナーまたはクライアントからのリクエスト）、パートナーフォーラムまたはアカウントマネージャー（重要なクライアント/クライアントに伴う）からのリクエスト。
4. 1Cからのリクエスト：エンタープライズプラットフォーム開発チーム。 プラットフォームチームは、ERP開発チーム（およびその他の一般的な構成）に、新しいプラットフォーム機能（ タクシーインターフェイス 、 モーダルウィンドウの拒否、同期呼び出しの拒否など）の使用を依頼します。
5. リファクタリング、アーキテクチャの最適化、使いやすさの改善。

リファクタリングの理由（第5項）は、重大なアーキテクチャの変更（たとえば、請求書の代わりに注文が使用され始めた出荷注文の改訂）である可能性があります。



DSS製品はERPの一部として提供されます（ただし、個別に購入できます）。 ERPソリューションは、DSSとの統合モードで起動できます。 この場合、各フォームには「機能モデルを開く」ボタンがあり、クリックすると、DSSのフォームの機能の説明が開きます。



以下が開きます-これはIDEF0の職場モデルです：



その逆も可能です-機能モデルを研究し、それからジョブのフォームを開きます。 このモードは、プログラムの動作を調べるために使用できます。

重要な点は、開くのはDSSではなく、DSSからのデータがロードされるERP内のフォームが開くことです。 つまり 統合は「シームレス」です（ユーザーには表示されません）。 この手法は、他の製品との統合に適用されます。 たとえば、1Cの場合：ドキュメント管理（別のデータベースで機能するメール、タスク、ビジネスプロセスでERPを離れることなく作業できます）。

ERPの開発方法：6つのプロジェクトのマイルストーン

そのため、機能の変更に対する新しい要件を実装することが決定されました。 同じタイプの要件が技術プロジェクトに結合されます。 新しいERPリリースのフレームワークでは、通常100から150の技術プロジェクトが実装され、各プロジェクトには1から数十の要件があります。 技術設計はDSSで開始されます。 実装中のプロジェクトは6つのコントロールポイントを通過し、それぞれがDSSで修正されます。

ERPユニット内でチームに分割することについて少し。 チームリーダー（チームリーダー）は設計に関与し、原則として開発に関与します。 通常、チームにはテスターも含まれます。 開発チームは静的であり、いくつかのサブジェクトエリアが割り当てられています。 プロジェクトに関連分野が含まれる場合、対応するチームの参加者がプロジェクトの期間中関与します。 プロジェクトにはチーム全体が関与しない場合があります。

プロジェクトの責任者-リード開発者またはチームリーダー。 彼の責任はプロセスを制御することです：

• 高品質の設計、あらゆる種類のシナリオを考慮し、隣接するブロックとのインターフェース
• タイミング
• 高品質のアーキテクチャ、ユーザーインターフェイス
• 証明書の作成、プロジェクトの設計、など 機能モデル開発

ポイント1.プロジェクトの開始

Tim-leadは、リリースリストを使用してDSSの技術プロジェクトを開始します。 各プロジェクトでは、目標が説明され、実装されている要件が示されます。 リリースの作業を開始する前のリストは、開発マネージャーと議論されます。 実際、プロジェクトが開かれると、会議は開かれません。DSSのプロジェクトだけが開かれます。

プロジェクトチームはコンセプトの開発を開始します。

ポイント2.コンセプトの調和

コンセプトを調整するために、プロジェクトマネージャー、チームリーダー、開発マネージャー、およびプロジェクトに関係する専門家が参加するオンラインまたはオフラインの会議が開催されます。 通常、この段階では、プロジェクトの責任者が会議中に洗練された「大ブロック」の概念が用意されています。 また、スクリプト（DSSで規定）、ユーザーインターフェイスの説明についても説明します。 要求がパートナーまたは顧客からの要求から生成された場合、ソリューションを評価するためにプロジェクト資料（概念、シナリオ、UI）をパートナー/クライアントに送信できます。

会議中に、プロトタイプの作成の複雑さについて合意します（通常、プロトタイプの作成には最大5営業日かかります）。 チームはプロトタイプの作成を開始します。

ポイント3.プロトタイプの調整

既成のプロトタイプの検討、実装の詳細の議論（特に、どのオブジェクトが追加および変更されるか）、仮説のテスト、フォームのプロトタイプの承認などが行われる会議が開催されます。 最も深刻なユーザビリティテストの目的で、プロトタイプは最も「ハード」なモードで起動されます-Webクライアント、タクシーインターフェース、低解像度のモニター。

IDEF0表記のプロジェクトの機能モデルが開発され、DSSに保存されます。

この段階で、プロジェクトチームはプロジェクトの人件費を可能な限り正確に評価する必要があります。したがって、プロジェクトのすべての側面について議論します（DSSで文書化します）。

• DSSでのプロジェクト記述の正確性の調整（特に、プロジェクトの以前の制御点でのすべてのタスクが完了することが監視されます）。
• ソリューションに追加される新しいメタデータオブジェクト（ディレクトリ、ドキュメントなど）
• 既存のメタデータオブジェクトに行われる変更
• データ交換計画と他のソリューションとの調整（新しい/変更されたデータが他のアプリケーションとのデータ交換に参加するかどうか、参加する場合はどのくらい正確か）

全員が人件費に満足している場合は、開発を開始する前にできるだけ多くのニュアンスを特定するために、プロジェクトで行われたすべてのプレゼンテーションが（DSSプロジェクトの資料に基づいて）開催されます。

そして、開発が始まります！

ポイント4.開発したソリューションの調整

ソリューションが開発され、プレゼンテーションが（PowerPoint形式で）準備されました。対面会議は、多くの場合、開発されたソリューションの「ライブ」ディスプレイで開催されます。

プロジェクトが公開されている場合（1CのWebサイトでパートナーが利用できるプランのリストに公開されている場合）、プレゼンテーションはERPセクションのパートナーフォーラムに投稿されるため、関心のあるすべてのパートナーは自分自身に慣れてコメントを付けることができます。

ポイント5.テストとプロジェクト監査

メイン開発の最後に、手動機能テストが実行されます。本格的なチームメンバーとしてのテスターは、プロジェクトのすべてのコントロールポイントに参加し、プロジェクトの機能と作業シナリオを理解しています。テスターは、使いやすさの基準に対して新しい機能を評価します。これらの標準（コーディング標準やインターフェース開発標準を含む）は、1C Webサイトのパートナーおよび登録ユーザーがアクセスできるリソースで公開されています。

プロジェクトコードはコードレビューを通過します。 ERPのコードレビューは、別のプロジェクトチームのメンバーによって実施されます。コードレビューは、ERPチームのすべての開発者が順番に行う責任です。コードに問題が見つかった場合、エラーはDSSに登録されます。これ

は、ポイント5を渡す前に修正する必要があります。更新は、以前のバージョン（現在リリースされている最新ビルド）で新しいバージョンがチェックされます。

そのため、プロジェクトの準備が整い、テストに合格し、コードをメインリポジトリにアップロードする時間になります（その前に、すべての開発は技術プロジェクトの別のリポジトリで実行されます）。この段階で、新しい機能に関する参照資料の作成も終了します（参照はDSSに保存されます）。

ステージの終わりに（テストに合格し、参照資料の準備ができたら）、プロジェクトはメインリポジトリに注がれます。この後、関連する領域で選択的回帰テストが実行されます。既存の機能を損なわないようにする必要があります。

ポイント6.プロジェクトの終了

DSSでプロジェクトを閉じます-「完了」のステータスを割り当てます。

リリース版

新しいリリースのリリースの約1か月前に、新しいプロジェクトのメインリポジトリへのアップロードが一時停止されます（技術プロジェクトのリポジトリでの開発は継続されます）。この時間までに終了する時間がなかったプロジェクトは、別のバージョンに転送されます。

今月中に、回帰テストが実施されます。コードの変更は、このリリースで導入されたエラーを修正するためにのみ許可されています。未配信のエラー（以前のリリースで再現されたエラー）は、回帰テストの開始までに、ほとんどすべてが修正されます。残っている同じエラーは、次のリリースに引き継がれます。回帰テストの主な目的は、製品の品質が低下しないことを確認することです。

すでに述べたように、同じDSSがバグトラッカーとして使用されます。

修復アセンブリ

2週間ごとにパッチバージョンをリリースします。今日は2.1.3.xです。リリース2.2.1のリリース後、2つの修正アセンブリ-2.1.3.xおよび2.2.1.xがリリースされます。エラーを登録してから修正リリースが表示されるまでに2週間もかかりません。統計によると、ERPのエラーでサポートに連絡してクライアントに連絡してから今日の修正アセンブリで修正がリリースされるまでの平均時間は9日間です。

分岐した開発

ERPのグループ作業では、1C：Enterpriseプラットフォームによって提供されたツールを使用しようとします。構成は構成リポジトリに格納されます ;新しい機能をチェックアウトするとき、ブランチは標準の配信およびサポートメカニズムを使用します。すべての操作は最大限に自動化されています。オブジェクトが開発者の側でのみ変更された場合、コードはプログラマの参加なしでマージされます。ソースを結合するために開発者の介入が必要な場合、通常はプラットフォームの組み込み機能を使用します。ただし、サードパーティの比較/プラットフォームツールからツールを組み合わせて呼び出す可能性もあります（たとえば、KDiff3またはAraxis）ところで、サードパーティの比較/統合ツールを呼び出すこの機能は、ERP開発チームの要求に応じてプラットフォームに追加されました。

その他

新しい機能を開発する際には、ERPの新しいバージョンのリリース時に利用可能になるプラットフォームのバージョンを使用します（今日はプラットフォーム8.3.8です）。

これは、プラットフォームが以前のバージョンとの互換モードを積極的に使用しているという事実により可能です。新しいプラットフォームが表示されたらすぐに切り替えますが、すぐに互換モードを無効にすることはできません。これには3つの理由があります。

1. ユーザーを「ショック」させたくないため、たとえばすべてのユーザーが報告しているときではなく、「静かな」期間に互換モードを無効にしようとします。
2. . , .
3. ERP – , 10 . , .

ライブラリについては別に書くことができます。ライブラリは、さまざまな最終アプリケーションで同じように機能する機能を含む特別に記述された構成です。ライブラリの統合は、プラットフォーム「Configuration Delivery」の前述のメカニズムを使用して実行されます。ライブラリは、公開済み（私たちが公開し、サードパーティの開発者が適用ソリューションで使用できるもの）および内部（個別に公開せず、適用済みソリューションの一部としてのみ使用可能）に分かれています。ライブラリの大部分は公開されています。

ERPには、他のチームによって開発された10個のライブラリが含まれています。それらのコードは、ERPチームの開発者によって変更されていません。

1Cのテスト方法：ERP

ERPから3つのソリューション（KA、UT、UT Basic）を作成した後、4つのソリューションすべての正確性を確認した後、取得した構成の静的および動的分析を実施します。

部分的な静的解析は、宇宙船、UT、UT Basic、UTの構成がERPリポジトリから作成され、独自のリポジトリに注がれるたびに実行されます（このプロセスは1日に2回行われます）。

より詳細な静的分析は、1C：自動構成チェック（1C：APK）構成を使用して行われます。特に、1C：APKチェック：

• ロールの構成。たとえば、すべての定数の読み取りアクセス許可がBasic Rightsロールに含まれていることを確認します。
• 受け入れられた標準へのコード準拠。多数のアプリケーション開発標準（うち数百ある）では、コンプライアンスのためにコード分析手順が書かれています。たとえば、リクエスト内の完全な接続が使用されていない、インターフェースに表示される行が正しくローカライズされているなどです。
• ERP開発の機能に関連する特定のチェック
  
  。たとえば、各アプリケーションオブジェクトがサブシステム「UT、KA、UEのオブジェクト」、「KAのオブジェクト、UE」または「UEのオブジェクト」の1つだけに含まれていることをチェック

動的コード分析には、特に、次の操作が実行される回帰テストが含まれます（操作の結果は、前回の成功したテストに対してチェックされます）。

• すべてのフォームの発見
• 他のアプリケーションソリューションとのデータ交換（たとえば、1C：Enterprise Accounting）
• 経理における保留文書の反映。文書が参照データベースに投稿された後、会計への反映の結果が変更されていないことが検証されます。
• その他

回帰テストでは、さまざまなサイズ（15 GBから70 GB）の10〜20個のデータベースと異なるコンテンツの仕様を使用します。

同じベースで、前のバージョンから新しいバージョンへの更新をテストし、更新がa）正しく、b）妥当な時間内に通過することを確認します。

1Cデータベースを更新する場合、2つの重要な手順があります。

1. 主な時間は、マルチユーザーモードでのデータの更新です。アプリケーションソリューションは、バックグラウンドで更新するデータを準備します。ユーザーはシステムでの作業を続行できますが、システムのパフォーマンスが低下し、一部の機能が限定的に機能する場合があります。通常、新しいバージョンへの更新は週末（ユーザーアクティビティが最小限の場合）に実行されます。
2. 最小時間-排他モードで更新します。すべてのデータがバックグラウンドで準備されると、データベースの構造を変更するときが来ます。これを行うには、ユーザーがシステムで作業できない場合、データベースは排他モードに転送されます。更新速度はユーザーにとって非常に重要です。

近い将来-最大数のシナリオでそれらをカバーするために、セルフテストのゾーンを拡大します。

おわりに

ERPは、当社の最大の製品の1つです。私たちは、その開発に最新の高度な技術を使用し、新しい方法とツールを作成して、一方で迅速に開発し、他方で開発したソリューションの高品質を確保しようとしています。