技能五輪決勝、ビジネス向け IT ソリューションの開発 - それが何なのか、どのようにして起こったのか、そしてなぜ 1C プログラマーがそこで優勝したのか

ワールドスキルズ は、22 歳以下の若者を対象としたプロの競技会を組織する国際的な運動です。

国際決勝戦はXNUMX年ごとに開催される。 今年の決勝会場は、 カザン （前回の決勝は2017年にアブダビで行われ、次回は2021年に上海で行われる予定）。

技能五輪選手権は、プロの技能を競う世界最大の選手権大会です。 彼らはブルーカラーの職業から始まり、近年ではIT分野を含む「未来の職業」にますます注目が集まっており、カザンでの選手権では別の巨大なクラスターが割り当てられました。

ITブロックには、「ビジネス向けITソフトウェアソリューション」と呼ばれるコンピテンシー（特定の「スポーツ」）があります。

各競技では、使用できるツールのリストが制限されています。 そして、たとえば、「ランドスケープ デザイン」の場合、使用可能なツールのリストが限られている場合 (もちろん、明示的なメーカーや色は示されません)、コンピテンス「ビジネス向けソフトウェア ソリューション」では、参加者が使用できる承認されたテクノロジのリストが表示されます。は厳密に制限されており、特定のテクノロジと特定のプラットフォーム (特定のフレームワーク セットを備えた .NET および Java) を示します。

この問題に関する 1C の立場は次のとおりです。情報技術は非常にダイナミックな分野であり、新しい技術や開発ツールが常に世の中に登場しています。 私たちの観点からすれば、専門家が使い慣れたツールを使用できるようにするのは正しいことです。

2018 年の秋、技能五輪の経営陣が私たちの意見を聞きました。 次に、新しいテクノロジーを競技会に組み込むための方法論をテストする必要がありました。 それは単純ではありません。

1C:Enterprise プラットフォームはカザンでのチャンピオンシップのインフラストラクチャ リストに含まれ、ビジネス サンドボックス向けの IT ソフトウェア ソリューションの実験的プラットフォームが組織されました。



チャンピオンシップの公用語は英語ですのでご注意ください。 タスクを解決した結果を含むすべての資料 (ソース コード、付属文書、ソフトウェア インターフェイス) もこの言語で送信される必要がありました。 一部の人は疑問に思っていますが（今でも！）、1C で英語を書くことができます。

この会場では9カ国（フィリピン、台湾、韓国、フィンランド、モロッコ、ロシア、カザフスタン、マレーシア）から8人の若者が競技に参加した。

専門家チームである陪審は、フィリピンの専門家であるジョーイ・マナンサラ氏が率いました。

フィンランド、UAE、コスタリカ、韓国、ロシア、台湾の専門家が出席しました。

これとは別に、ロシア (Pavkin Kirill、Sultanova Aigul) とカザフスタン (Vitovsky Ludwig) の参加者がコンテストの一環として 1C:Enterprise プラットフォームを使用することを決定したことにも注目します。 残りの参加者は、デスクトップには .NET を、モバイル開発には Android Studio を使用しました。 興味深いのは、1Cを選んだ参加者が非常に若いのに対し（キリルはスタヴロポリの学校の学生で、今年11年生になった、アイグルはタタールスタンのカザンに住む大学生）、対戦相手ははるかに経験豊富だった（たとえば、韓国からの参加者は、ライプツィヒで開催された 2013 年技能五輪選手権の優勝者であり、全員が技能五輪への参加経験と業界での数年の専門的経験を持っています。

コンテスト中に参加者がさまざまな最新テクノロジーを使用したことを考慮すると、実際の戦闘条件で 1C:Enterprise プラットフォームをテストし、その支援によって得られるソリューションの品質と、その使用によって達成される開発速度の両方を比較する機会がありました。

これとは別に、特別なビジネス向け IT ソフトウェア ソリューション サンドボックス プラットフォームのフレームワーク内で、参加者はメインのビジネス向け IT ソフトウェア ソリューション プラットフォームの参加者と同じタスクを完了したことに注意してください。

このタスク自体は、特定のビジネスを自動化するための複雑なタスクです。今年のビジネスの例は、架空の会社 KazanNeft でした。

伝説

Kazan Oil はタタールスタン共和国最大の石油企業の XNUMX つであり、国内市場のプレーヤーとして活動しており、この分野では国際的に認められたブランドです。 石油、石油製品、天然ガスの探鉱、生産、生産、精製、輸送、販売および流通を専門とする同社の本社はカザン（ロシア）にあります。

同社はロシア全土で急速な拡大と新しいオフィスの設立戦略を実行しているため、同社の経営陣は特定の業務の維持と管理を目的とした新しいビジネス自動化ソフトウェアを導入することを決定しました。

チャンピオンシップ条件

タスクはモジュール (セッション) の形式で参加者に与えられ、限られた時間内にタスクを完了する必要があります。 合計7つのモジュールがありました。 デスクトップ上で解くための 2.5 つのセッション – 各 3.5 時間。 2.5 つのセッション - クライアントがモバイル アプリケーションであるクライアント/サーバー開発、およびクライアントとサーバー間の通信は WEB-API を介して実行されました。 これには XNUMX 時間かかりました。 最後のセッション – 既存のソフトウェアのリバース エンジニアリングに関するタスク、XNUMX 時間。 リバース エンジニアリングの一環として、参加者は、提供された情報に基づいて、アプリケーション データベースの構造を設計し (ER 図を作成し)、システムを使用するためのシナリオを分析し (ユース ケース図を作成し)、さらに提供された機能要件に従ってソフトウェア ソリューションのインターフェイスを開発および設計します。

使用された主な開発プラットフォームは、.NET (C#) と Java (モバイル開発用の Android Studio を含む) でした。 実験的なサンドボックスでは、.NET、Java、および 1C:Enterprise バージョン 8.3.13 を使用しました。

各セッションの終わりに、専門家は結果、つまりセッションの開始時に設定されたタスクを実装する既成の実行可能なプロジェクトを評価しました。

タスクの特徴はその「活力」、つまり多くの要件と限られた時間です。 問題のほとんどはオリンピックの特別な問題ではなく、実際の産業問題に非常に近いものであり、専門家は毎日それらの問題に直面しています。 しかし、やるべきことはたくさんあり、時間は限られています。 参加者は、ビジネスに最大の利益をもたらす問題を最大数解決する必要があります。 アルゴリズムの観点から見ると、複雑なタスクが初歩的なタスクよりも重要であるということは、まったく事実ではありません。 たとえば、企業にとっては、複雑なアルゴリズムを備えた美しいレポート フォームよりも、XNUMX つのテーブルからなる機能する会計システムを作成することの方が重要ですが、これらのテーブルがなければまったく必要ありません。

私たちは、コンテストの優勝者であるロシアからの参加者であるキリル・パフキン氏に、課題とは何か、そしてその解決策にどのようにアプローチしたかについて詳しく語ってもらいました。

以下はタスクの説明と、このタスクをどのように解決したかについてのキリル自身の物語です。 また、1C の従業員でビジネス サンドボックス向け IT ソリューションの専門家の XNUMX 人である Vitaly Rybalka 氏に、キリルのソリューションについてコメントを求めました。

割り当ての一環として、いくつかのタイプのユーザーのアクティビティを自動化する必要がありました。

• 会社の資産の会計を担当します
• 会社資産の予定外の修理と定期メンテナンスを担当します。
• コンポーネントおよび消耗品の購買管理者
• 石油探査および石油生産部門
• トップマネジメントには分析レポートが必要だった

セッション1

資産 (車両など) の観点から見ると、会計処理 (新しい資産の作成、現在の資産の編集)、情報表示のためのクイック検索とさまざまな種類のフィルター、会社の部門間での資産の移動を実装する必要がありました。そしてアセット自体のグループ。 このような動きの履歴を保存し、将来的には分析を提供します。 資産会計は主にモバイル ユーザー グループを対象に実装されました。

キリル: 興味深いサブタスクは、アセット リストへのボタンの実装でした。 これを解決するために、動的リストを使用しました。任意のリクエストを作成し、サーバーでデータを受信するときに、画像ライブラリから必要なフィールドに画像へのナビゲーション リンクを割り当てます。

慣例により、写真は XNUMX つの方法でアセットに添付できます。写真を撮る (マルチメディア) 方法と、ギャラリーから選択する (ファイル選択ダイアログ) 方法です。

画面を回転すると、いくつかの図形を再描画する必要がありました。

画面パラメータを変更すると、ボタン グループの表示/非表示が変更されます。

面白いながらも単純なタスクには、動的リストのフィルター、XNUMX つのフィールド (番号と名前) での検索、資産のシリアル番号の生成などがあります。

エキスパートコメント: 1C:Enterprise プラットフォーム上のソリューションの観点から見ると、その課題は非常に明確です。 モバイル アプリケーションの実際の作成に加えて、DBMS 「サーバー」 (デスクトップ上の MS SQL) からモバイル アプリケーションへのデータの転送、およびその逆のデータ転送を行う必要がありました。 この目的のために、外部データ ソースと http サービスのメカニズムがデスクトップの「プロキシ アプリケーション」で使用されました。 モバイル プラットフォーム自体の場合、動的なリストに画像を表示すると、複雑さが増します。

セッション2

自社資産の修繕管理を確立する必要があった。 この作業の一環として、(部門およびグループごとに) 修理依頼のリストを管理し、修理の緊急性の優先順位を考慮し、優先順位に従って修理スケジュールを計画し、必要なコンポーネントを注文して修理する必要がありました。既存のものを考慮します。 興味深いサブタスクは、一部のコンポーネントには有効期限があるということでした。 特定の資産の部品がすでに注文されており、期限が切れていない場合、この資産については同じ部品を再度購入する必要はありません。 修復インターフェイスは、同社のソフトウェアのデスクトップ コンポーネント用に開発されました。

また、責任者とサービス マネージャーという XNUMX つの役割に対して、重要な承認フォームを作成する必要もありました。 特徴は、承認後にロールの XNUMX つを自動的に選択する必要があることです。

責任者が利用できるリスト フォームを以下に示します。

キリル: ここで強調表示できるのは、保留中のサービス リクエストの強調表示のみです。 動的リストの条件付き書式設定によって解決されます。

画面の下部にあるボタンをクリックすると、次のフォームに移動できます。

1C の観点から見ると、この形式には複雑なことは何もありません。

サービス マネージャーが利用できるフォームは次のとおりです。

このフォームは優先度とリクエストの日付によって並べ替えられています。 下のボタンをクリックすると、ユーザーは選択したリクエストのフォームに移動できます。

このフォームでは、確実な対応に加えて、修理用のスペアパーツのリストを実装することも提案されています。 このサブタスクは、パーツに有効期限があるため興味深いものです。 これは、この資産ですでに緊急事態が発生しており、有効期限が切れていない部品が注文されている場合は、再利用できることを意味します。 これをユーザーに示す必要があります。

エキスパートコメント: ここではキリル自身がアクセントを正しく配置しました。 1C:Enterprise プラットフォームでの実装の観点から見ると、非常に複雑なことは何もありません。 会計条件とスペアパーツの使用条件を注意深く分析し、タスク全体を適切に実行することが必要でした。 さらに、サービスリクエストを適切に記録する必要がありました。 主な困難は 2.5 時間という時間的プレッシャーだけでした。

さらに、モバイル開発と同様に、参加者は外部 DBMS (MS SQL) からデータを適切に取得する必要がありました。

セッション3

メンテナンス（保守）については、長期計画サービスの実施が提案されました。 ここでの興味深い機能は、タイミングに従って資産のメンテナンス スケジュールを作成する必要があることです (たとえば、隔月の 3 日など)。 同様に、いくつかの定量的な指標によると、たとえば、車の走行距離計によると（オイル交換は 5000 km ごと、タイヤ交換は 20000 km ごと）。 メンテナンス管理者は、期限を過ぎたメンテナンス、現在のメンテナンス、および指定された期間の完了したメンテナンスのリストを動的に表示する便利なモバイル アプリケーションを受け取っている必要があります。 さらに、各種類のメンテナンスは、特別に合意された規則に従って色で塗装する必要がありました。 モバイル アプリケーションは、サーバー上のこの情報を迅速に更新することで、新しいメンテナンス スケジュールの作成と、ワークショップで直接完了したメンテナンス スケジュールのマーク付けを確実に行うことを想定していました。

キリル: 修復には、時間ベースと実行ベースの 13 種類があります。 それぞれの範囲内での変動は許容されます。 たとえば、計画によれば、修理は毎週金曜日、毎月 20,000 日、または XNUMX キロメートルごとに行われます。 タスクの右側にチェックマークが付いている場合、そのタスクは完了したとみなされます。

リスト内のタスクを並べ替えるための条件が提供されました。 また、条件に応じて各行を色で強調表示する必要があります。

下のボタンをクリックすると、新しいサービス プランを作成できます。

選択したグラフの種類に応じて、必須フィールドが表示されます。 週単位のタイムスケジュールを選択した場合は、週番号と曜日の 3 つのフィールドが表示されます。 たとえば、XNUMX 週間ごとの火曜日などです。

エキスパートコメント: 1C:Enterprise プラットフォームでの以前のモバイル開発と同様に、ここでもタスクは 2 つのコンポーネントにグローバルに分割されます。Web API を介した「サーバー」との通信と、条件付き設計とフィルタリング (選択) による動的リストの有能な表示です。データ。 さらに、期間と定量的指標の両方によって修繕を説明するという要件を実装することは興味深いものでした。

セッション4

コンポーネントや消耗品については、在庫を考慮し、経費や将来の購入を計画する必要がありました。 なお、ここでは一括会計が登場しましたが、すべての商品を対象としたわけではありません。 受け取り、支出、移動など、これらすべてを複数の倉庫内で管理する必要がありました。 タスクの条件によれば、現在の株式を扱う際には残高を確実に管理し、競合を回避する必要がありました。 購買マネージャーは、ソフトウェアのデスクトップ バージョンで作業します。

メインフォームを以下に示します。

キリル: 条件による並べ替えに加えて、ユーザーにランダムに並べ替える機能を提供することが提案されました。 1C ではそれについて考える必要さえありません。 請求書では、部品の数量を含むフィールドが緑色で強調表示されます。

このセッションでは、倉庫に残っている商品を管理するように求められました。 したがって、請求書を削除しようとすると、対応するメッセージが表示されるはずです。 ここでプラットフォームスペシャリスト試験を思い出します。 請求書の形式は次のとおりです。

各部品には、特定のバッチに割り当てるかどうかを決定する特性があります。 このようなスペアパーツについては、すべての書類にバッチ番号を記載することが必須です。 これは、部品の残留物を監視する際の追加の測定です。 倉庫間を移動することもできます。

このフォームは、顧客の代わりに配送元の倉庫を指定する必要があるという点のみが前のフォームと異なります。 パーツが選択されると、バッチの選択リストが自動的にコンパイルされます。 ユーザーは、スペアパーツの残高に関するレポートを生成できます。

ここでは、選択した倉庫に残っている商品を表示できます。 ウェアハウスの右側にあるチェックボックスを使用して、フィルタリングと並べ替えを構成できます。 このリストには、ロットによる明示的な分割が必要な部品が含まれていません。 選択したスペアパーツの各バッチ番号の残高は、右側のナビゲーション リンクを使用して表示できます。

エキスパートコメント: このセッション (モジュール) でバッチ会計が初めて登場しました。 参加者は、消耗品や商品を自分自身だけでなくバッチごとに会計処理する必要がありました。 一般に、このタスクは 1C:Enterprise プラットフォームに最適ですが、すべてをゼロから開発し、2.5 時間で完了する必要がありました。

セッション5

5 回目のセッションでは、井戸管理の機能が割り当てられました。 探査グループの場合、石油またはガスの生産井を考慮したモバイル アプリケーションを作成する必要がありました。 ここでは、サーバーから現在の井戸のリストを受信し、各層の深さを考慮して、選択した井戸を層 (土、砂、石、油) ごとにグラフィカルに表示する必要がありました。 さらに、アプリケーションでは井戸に関する情報の更新と新しい井戸の追加を許可する必要がありました。 このアプリケーションでは、顧客はオフライン モードとオンライン モードで特別な動作条件 (サーバーとの通信の制御) を設定します。つまり、サーバーとの通信を XNUMX 秒ごとにチェックし、サーバーの可用性に応じてアプリケーションの機能を変更します。

キリル: 井戸を選択すると、石油またはガスの鉱床までの層を強調表示する棒グラフが表示されます。 レイヤーごとに、その名前、色、出現範囲が保存されます。 設計上の特徴により、プラットフォームに組み込まれている図は役に立ちませんが、スプレッドシート ドキュメントはこのタスクに完全に対応します。 ウェルは作成および変更できます。

複数の確実な保護を除けば、この形式には何も興味深いものはありませんでした。
次に、サーバーへの接続を制御することが提案されました。 5 秒ごとに接続を試みます。 動作しない場合は、アプリケーションの機能が制限され、メッセージが表示されます。

エキスパートコメント: このセッションのタスクは、主にそのグラフィック機能により興味深いものです。 1C:Enterprise プラットフォームを使用する参加者は、5 つの異なる方法で問題を解決しました。ある者はダイアグラム メカニズムを使用し、他の参加者はスプレッドシート ドキュメントを使用しました。 各方法には長所と短所があります。 技能五輪選手権の決定の一環として、時間が鍵でした（制限時間をもう一度思い出してください）。 別の興味深いタスクは、サーバーに XNUMX 秒ごとに ping を送信し、サーバーが利用可能かどうかに応じてモバイル アプリケーションの動作を変更することです。

セッション6

トップマネジメント向けのワークスペース、ダッシュボードを作成することが提案されました。 XNUMX つの画面に、指定期間における会社の一般的な業績指標をグラフ形式および表形式で表示する必要がありました。 主な形式はコスト レポートです。

ダッシュボードに加えて、FIFO/LIFO/「安いものから優先」の償却方法を使用して、資産修理用のスペアパーツの配布を実装する必要がありました。

配布中はバッチ会計が考慮され、残高管理と不正なユーザーの行為に対する保護 (「フールプロテクション」) が使用されました。

キリル：解決するには、任意の数の列が存在する可能性があるため、ソフトウェアで列を生成した値のテーブルが使用されました。

• 最初のテーブルは月ごとの部門の総コストを表します。 最も収益性の低い部門と最も収益性の高い部門は、それぞれ赤と緑で強調表示されます。
• XNUMX 番目の表は、月ごとに最も高価で最も頻繁に使用される部品を示しています。 条件を満たす部品が複数ある場合は、カンマで区切って XNUMX つのセルに表示する必要があります。
• 最も高価な資産 (スペアパーツのコストの点で) が XNUMX 番目の表の最初の行に表示されます。 XNUMX 行目は、上記の資産が属する部門を表示します。 同じコストの最も高価なアセットが XNUMX つある場合は、それらをカンマで区切って同じセルに表示する必要があります。

図はプラットフォームの組み込みメカニズムを使用して表示され、クエリを使用してプログラムで入力されました。

多言語対応への対応も提案された。 プログラムはインターフェイス要素のローカライズを含む XML ファイルをロードします。ドロップダウン リストで言語を選択するとフォームが再描画される必要があります。

画面の左下隅にあるボタンをクリックすると、在庫管理フォームが開きます。

この形でいよいよ修理に部品費をかけ始めます。 ここでは、まず資産を修復するために必要な部品を見つけます。 選択したフィールドと分配方法 (FIFO、LIFO、または最低価格) に基づいて、見つかった一致が表示されるか、一致がない場合はメッセージが表示されます。 その後、パーツをその資産の修復を目的としてマークできます。 バランス制御は現在のセッションに関連します。 すでに詳細を割り当てている場合は、それらを見つけることはできません。

エキスパートコメント：とても興味深いセッションです。 これは、1C:Enterprise プラットフォームの機能を最大限に活用します。ここでは、蓄積レジスタの仮想テーブルを使用した有能な作業と、フォーム要素 (まずテーブル、次に見出し) および図をプログラムで使用します。 在庫分析や損益分析などの場合は、LIFO/FIFO も使用できます。

セッション7

タスク (セッション 7) の最後に、顧客はプロジェクト活動用のソフトウェア (exe ファイル) とその操作に関する短いビデオを提供しました。 リバース エンジニアリングを実行し、これに基づいてユース ケース図とエンティティ関係図の 2 つの図を作成する必要がありました。 さらに、将来ソフトウェアを作成するためにいくつかの要件が提示され、これらの要件に従ってインターフェイスのレイアウトを作成する必要がありました。

競技条件によれば、図の作成には MS Visio のみが必要でした。

エキスパートコメント: このセッションでは、1C:Enterprise プラットフォームの機能は実質的に使用されませんでした。 競技条件の図は MS Visio で作成されました。 しかし、インターフェイスのプロトタイプは、空の 1C 情報ベースで作成できます。

総説

各セッションの開始時に、SQL スクリプトを使用してデータをインポートすることが提案されました。 データを外部データ ソースに抽出し、独自のテーブルを作成し、外部ソースからテーブルに行を移動するのに少なくとも 1 分を費やしたため、これが C# と比較した XNUMXC を使用する主な欠点でした。 残りの作業は、Microsoft SQL Studio の [実行] ボタンをクリックするだけです。

明らかな理由から、モバイル デバイスにデータを保存するのは得策ではありません。 そのため、モバイルセッション中にサーバーベースを作成しました。 そこにデータを保存し、http サービス経由でデータへのアクセスを提供しました。

エキスパートコメント: ここでは 1C/非 1C のバランスが興味深いです - 1C:Enterprise プログラマは外部 DBMS への接続にかなりの時間を費やしましたが (Kirill はこれについて上で別途言及しました)、C#/Java (モバイル開発用 Android Studio) 開発者は他の領域に時間を費やしました -インターフェイス、さらにコードを記述します。 したがって、各セッションの結果は予測不可能であり、すべての専門家にとって非常に興味深いものでした。 そして、この陰謀は最後まで残りました - ポイントの分布を含む最終的な勝者の表を見てください。

キリルは物語を終えました:)

結論として、実行者は「技術仕様に従ってタスクをプログラムするだけ」必要はなかったということを思い出してください。実行者はタスクを分析し、サブタスクを実装するためのブロックを選択し、それらを設計し、正確に何をするかを決定する必要がありました。非常に短い割り当て時間でこれを実装することができます。 4 日間を通して、私は厳しい時間的プレッシャーの中で行動しなければならず、その後の各セッションを最初から開始することがよくありました。 業界で長年の経験を持つ成人スペシャリストであっても、割り当てられた時間内にセッションに割り当てられたタスクを 100% 完了するのは非常に困難です。

特筆すべきはその評価制度の採用だ。

セッションごとに、タスクの作成者は、機能のチェック、正しい操作、アプリケーション インターフェイスの要件、さらにはソリューションを開発している企業が参加者に特別に提供するスタイル ガイドの遵守など、複雑な基準システムを作成します。

評価基準は非常に細かく細分化されており、セッション タスクの総コストは数十ポイントで、何らかの基準を満たすと参加者に XNUMX 分の XNUMX ポイントが追加されます。 これにより、競技に参加する各参加者の成績を非常に高い客観的なレベルで評価することができます。

結果

最終結果は印象的でした。

激しい戦いの末、1C:Enterprise プラットフォームを使用したロシアのキリル パフキン氏が勝利しました。 キリルは17歳で、スタヴロポリ出身です。

文字通り、勝者と追撃者との差は XNUMX 分の XNUMX ポイントでした。 XNUMX位は台湾からの参加者でした。 上位 XNUMX 件の結果をまとめた表は次のようになります。

もちろん、キリルは彼の才能、知識、スキルのおかげで勝利しました。

ただし、1C:Enterprise プラットフォームをツールとして使用した参加者 1 名全員が上位 XNUMX 名に含まれていることには注目します。これは、XNUMXC:Enterprise テクノロジーの世界レベルが無条件に裏付けられたものです。

競技の結果を受けて、KazanExpo メディア センターで優勝者が表彰され、選手たちは純金メダル (順位に応じて) と賞金を受け取りました。 彼らはまた、1C でインターンシップを受けるための証明書も受け取りました。

出所： habr.com