情報システムの生産のためのプロセスの組織。 パート4.情報システムの実装

IX情報システムの実装

新しいイノベーションの導入を先導することほど難しいもの、危険なもの、不確実なものはありません。なぜなら、それぞれのイノベーションには、古い方法でうまく生きた熱烈な敵と、新しい方法で生きることができるかどうかわからない緩慢な支持者がいるからです。

N.マキャベリ

そして今、プロジェクトの興味深い飽和部分、プロジェクトの投影、創造性、創造が終わります。 あなたの決定を守るという厳しい日常生活は、特定の企業の本当の雰囲気の中で始まります。そして、それほど重要ではないことは何でも、すべてが現在の法律の枠組みの中にあります。



そもそも、販売された製品は、パイロット運用の組織向けに準備された機器に展開する必要があります。

1.テストサイトでのシステムの展開

ドキュメントに反映された設計された技術アーキテクチャに従って、サーバー、通信、その他の機器、およびシステムソフトウェアが購入されます。 情報システムのコンポーネントは、その産業利用が計画されているサイトの単一のハードウェアとソフトウェアの複合体にマウントされています。



大規模プロジェクトでは、ソフトウェアがノード、ノード、さらにはクラウドに散らばっている大量の機器が関係するという事実のため、このプロセスには本格的なドキュメントが必要です。 たとえば、サーバー、ワークステーション、アクセス方法などのアドレスを含むテーブルは、技術文書に含まれています。 視覚的な表示のために、ネットワークノードの場所、それらの相互作用のコンポーネントの分布などを理解するコンポーネント図が使用されます。 ただし、インフラストラクチャのあらゆる種類の変更を規制する手段を定義する必要があり、システムのさまざまな要素の障害の結果を排除することができます。





図19.-実装フェーズの技術的な説明の例



これらの運用サイトの次の段階では、実装およびサポートチームから多くの専門家を押し出すため、これはすべて非常に重要です。また、毎回異なる情報源から作業に必要な情報を取得すべきではありません。 したがって、ドキュメントは最新の状態に保ち、システム設定の変更、アーキテクチャソリューションの変更などと同時に変更する必要があります。



システムの産業運用のためにサイトと「戦闘」し、実際に近い作業をシミュレートするスタンドを展開およびテストするのに役立ちます。 まあ、突然、新しいリリースのリリースを要求するコメントがまだあります。 もちろん、専門家、責任者などすべてですが、それでも最初にテストベンチで更新を行う方が良いでしょう。 念のため。



一方、時間の90％はすでに過ぎています...

2.情報システムを操作するための顧客担当者のトレーニング

何度も言及されているように、大規模なプロジェクトでは、システムのユーザーの指示を含むドキュメントの品質に特別な注意が払われます。 ほとんどの場合、ユーザーの指示は、アクティビティの種類、専門性などによってセグメントに分割されます。 これにより、重要なポイントにドキュメントの注意を集中させることができ、不必要な情報をユーザーにロードすることはありません。



多数のさまざまな顧客従業員がトレーニングに関与する可能性があり、その結果、ビジネスプロセスの継続性を確保するためのトレーニングを同時に保証できないため、さまざまな機能的責任およびその他の正当な理由でトレーニングする必要があるため、トレーニングプロセスを慎重に計画する必要があります。 初期準備のレベルに基づいて、さまざまなアプローチの使用とトレーニングの深さを必要とするカテゴリに従って、学生をグループに分けることも役立ちます。 その結果、コンパイルされたトレーニングスケジュールは、すべての関係者と合意し、必須として顧客の経営陣によって承認される必要があります。







そして、設計段階で、お客様の従業員のトレーニングは非常に責任ある作業であるだけでなく、非常に時間がかかることを警告しました...

3.情報システムの欠陥と欠陥の特定

大規模なプロジェクトでは、最終リリースをテストしても、ソリューションのすべての問題領域が明らかになるわけではありません。 その理由は、「戦闘」状態の実際の大量のデータ、実際のビジネスプロセスでのビジネスルールの一意の組み合わせの明示、特定の機器の動作の特徴、システムコンポーネントの特定の組み合わせ、分散ノード間の負荷分散などです。



多くの場合、初期段階で新しいシステムを導入しても、古いシステムで作業する必要がなくなるわけではないため、状況はさらに複雑になります。 つまり、ユーザーは両方のシステムでデータを複製します。 既存の関連データを古いストレージから新しいストレージに移行する必要がある場合があり、通常、情報の構造と形式は非常に異なります。 たとえば、新しいデータ構造に必要な詳細を入力するための十分な情報がない場合、デフォルトで割り当てられたデータが入力され、ユーザーが手動で調整します。 そして、これは実際のプロジェクトで対処しなければならないことのほんの一部です。



別のトピックは統合ソリューションです。このソリューションでは、2、3、またはそれ以上のチームによって開発されたさまざまなコンポーネントを使用して、チェーンで障害が発生する可能性があります。 実装中に特定された不整合により、統合要素の接合部で欠陥が最も頻繁に発生するため、この状況で有罪を見つけることは非常に困難です。 そして、ここでは、罰の有罪を探すのではなく、ドッキングされたコンポーネントの開発者の共同譲歩に迅速かつ建設的に同意し、問題を効果的に解決することが重要です。



上記のすべてを考慮すると、ほとんどの場合、試験運用フェーズは、開発チームと顧客の両方で、感情的な爆発と相互の不満で飽和します。 この場合、アーキテクトとシステムアナリストの役割は非常に重要です。アーキテクトは問題を迅速に特定し、解決策を提案し、すべての関係者と調整する必要があります。 このような作業を実行するには、基本的な専門的スキルに加えて、交渉担当者の才能と管理の基本に関する知識も必要です。



一方、私たちはプロジェクト時間に割り当てられた底に達しました...

4.情報システムの実装プロセスにおける変更の調整

情報システムの一部の機能モジュールの作業が顧客のニーズと期待を大きく満たさない場合、およびこれらの問題を解決するソリューションが見つかった場合、それらを修正して顧客と合意する必要があります。



新しいソリューションに同意する段階は、少なくとも2つの理由から非常に重要です。



まず、変更の実装量がプロジェクト計画でそのようなリスクに対して定められた量を超える場合、追加の契約を締結するか、エグゼキュータのチームが損失を出して作業する必要があります。 多くの場合、パフォーマーはすぐに変更を行うように促されますが、後でそれらを考慮して、1つのパッケージでそれらの作業に対して支払います。 しかし実際、そのような場合は通常、顧客が自分の約束を完全に忘れて、完了した作業を発表するという事実につながります-自分の間違いの実行者を修正することによって。



第二に、システムの一部のコンポーネントの変更は、相​​互依存コンポーネントの不可避な変更につながる可能性があり、慎重な分析と、場合によってはサブシステムのチェーン全体の再設計が必要です。 そうでなければ、システム全体の動作の欠陥は避けられません。 これは、たとえば、隣接するパフォーマーのチームのモジュールが故障した場合に発生する可能性があり、顧客は既にそれらをハックワーカーおよびブリーダーとして発表しています。 真実は確かに浮かび上がりますが、堆積物は残ります。



そして、Jerzy Lecの言い換え：「割り当てられた時間の底に達したとき、下からノックしました...」







時間が過ぎているので、顧客と交渉し、彼がプロジェクトの贈り物ではなく、責任の一部が彼にあることを彼に納得させる必要があります。

5.試運転の結果に基づく情報システムの最終化

試運転中に、開発されたソフトウェアとハ​​ードウェアの複合体を修正する決定がなされ、合意された場合、それらに基づいて、実行者がそれらを実装するためのタスクが設定されます。 セクションパート3で説明したプロセス。 設計ソリューションの実装が繰り返されます。 しかし...



システム設計の段階で、大規模プロジェクトでスクラム（1）方法論を全面的に使用することのマイナスの影響について議論した場合、この段階で完全に適合します。 これは、顧客に移された製品がほとんどの場合彼に合わないプロジェクトで特に顕著です。 言い換えれば、パニックに陥り、非常に迅速に、「悪用」されて、既に悪用されている製品に変更を加えるときです。



実際、次の条件が関係するときが来ました。

1. 顧客はすでにシステムを実際に使用し始めており、このために時間を割り当て、今では本当に必要なものを明確に視覚化しています。 したがって、彼はパフォーマーのチームと緊密に連携する準備ができており、これに対する重要なニーズがあります。
2. ほとんどの部分のドキュメントはすでに準備ができており、その変更と追加は可能な限り迅速に行われない場合がありますが、実装が成功した後は、事後に作成されます。
3. ほとんどの部分の改善は、セグメントを担当するパフォーマーの特定のチームを持つ個別のモジュール、サブシステム、回路で発生します。 したがって、開発者とのユーザーコミュニケーションはすでにローカライズされており、高品質のフィードバックを簡単に確立できます。
4. 改善と修正は非常に迅速に、小さなキューで実行する必要があります。その結果は、非常に関心のある顧客に結果を転送します。

最終的に、プロジェクトのドキュメントがイノベーションに完全に準拠し、チームがその後の変更の分析と設計のための実際のソリューションを簡単に見つけることができることが非常に重要です。





図20.-情報システムの実装段階



コメントなし...

6.情報システムの商業運用への移行

試運転中に、実装されたシステムがどのように機能するか、およびその開発契約にどの程度準拠するかについての論争のある問題と誤解がすべて解決されると、当事者は契約の履行に基づいて行動します。 顧客は、実行された作業の全額を支払います。 情報システムの開発と実装に関する合意は満たされているとみなすことができます。



実装は、産業運用の段階に入ります。 これらの関係は、多くの場合、システムの産業運用をサポートするための別個の契約または追加の契約によって法的に規制されています。 この契約の下では、システムコンポーネントの動作、それらの相互作用を診断し、軽微な障害を排除するなどの予防作業を行うことができます。

7.セクションの要約

情報システムの実装段階は、その生産プロセス全体の真実の瞬間であり、すべてのプロジェクト参加者にとって最も困難な時期の始まりとなります。 次のアクティビティが含まれる場合があります。

1. 機器の供給、システムソフトウェアのインストール、実装されたシステムの現在のリリースのインストールなどを含む、産業運用サイトでのシステムの展開。
2. 管理者、機器メンテナンスの専門家など、システムを使用するためのユーザーのトレーニング。
3. 試運転中に特定された欠陥と欠陥の特定と除去。
4. システムの変更の調整および契約上の義務に沿ったシステムの提供。
5. 契約上の義務の履行に関する文書の署名。 実行された作業の完全な計算。
6. システムを商用運用する。