情報システムの生産のためのプロセスの組織。 パート3.設計ソリューションの実装

VII設計ソリューションの実装および実装の計画の開発

デザイナーにとって素晴らしい計画は幸運です。

悪い計画はパフォーマーにとって幸運です。

ウェスラフ・ブルジンスキー。

この段階で、プロセスはプロジェクトマネージャーを中心に展開されます。 繰り返しますが、複雑さの評価、用語の決定、ボリュームの調整、実行順序の承認など。



大規模プロジェクトについて話しているため、設計ソリューションの実装では、情報システムの生産プロセス全体が個々のコンポーネント、サービス、モジュールなどに分割される可能性が高くなります。 これらの部分を実装するプロセスには、さまざまなテクノロジーやツールを使用するチームなど、さまざまなチームが関与する場合があります。 システムの各部分の生産サイクルには、特定の規則と規制が適用されます。 たとえば、他の部品の準備状況、特定の定期メンテナンスの結果、機器の取得などに依存する場合があります。 システムのさまざまなコンポーネントを開発しているチームが時折のダウンタイムを回避し、ターンが最終的に到着する瞬間を無造作に待機するために、製品生産の段階とプロセスを慎重に計画する必要があります。



これらの問題を解決するために、ほとんどの場合、プロジェクト全体でチームと個々のパフォーマーの相互作用を整理および合理化できるスケジュールを作成します。

1.プロジェクトスケジュールの詳細化と詳細化

要件仕様が十分に詳細に作成され、それらに基づいて前のセクションで指定された推奨事項に準拠している場合、プロジェクトマネージャーは、開発チームの技術リーダーと一緒に、不必要な困難なく十分なリアリズムで詳細なプロジェクトスケジュールを作成できます。 先ほど、仕様はシステムの一部の機能を実装するための原子タスクの順序付けられ、構造化されたセットの形式でのシステムの説明であると述べたことを思い出させてください。 例、要件仕様の内容、図10を参照してください。





図10.-要件仕様セクションの例



図からわかるように、セクションの見出しは、プロジェクト計画でそれらを使用し、トラッカーで開発者にタスクを設定するのに最も適しています。 仕様識別子（[FR02.2]など）に従って、請負業者は要件の詳細な説明をテキストで簡単に見つけることができます。



したがって、プロジェクトマネージャーは、作品のプール全体を多数の制御ゾーンに分割する機会を得ることができます。それぞれのゾーンでは、フラグメントを実装するさまざまなチームの開発者にタスクを並列および順次に提供できます。



プロジェクト計画は、図11のようになります。 この場合、タスクヘッダーは要件仕様ヘッダーから単純にコピーされます。





図11.-プロジェクトスケジュールの例



このような詳細な要件に応じて、製品全体の実装のタイミングを高精度で計画し、すべての実行者が作業範囲内で維持することを約束する期間を調整することができます。



プロジェクト計画にマイルストーンを含めると便利です。これにより、プロジェクト自体とその製品の両方の状態を特定の時点で評価できる重要な中間結果が得られます。 マイルストーンを使用すると、機能に制限はあるものの、既に何かが何らかの形で使用できる現実の何かを「手で触る」ときに、イベントの概要を説明できます。 たとえば、マイルストーンは、事前定義された機能を使用して、作成された製品のリリースを指定できます。 また、この機能自体の要件は、ステージを通過して結果を達成する成功を評価するための基準として機能できます。 これらの要件を満たすのは、要件と暫定リリースの形式のドキュメントの組み合わせであり、ビジネスが仕事のペースを実感できるようにします。 結局のところ、私に言ってはいけませんが、実際には、新しいリリースは無形の資産であり、文字通りの意味でビジネスに触れることも見ることもできません。 しかし、その機能の結果を確認し、要件で文書化された類似物と比較することは非常に現実的です。



当然、多数のパフォーマーが関与する非常に複雑な要件を実装する大規模なプロジェクトでは、何かがうまくいかないことがあり、納期を守る上でのオーバーレイと失敗は避けられません。 このようなリスクに対処するために、プロジェクトマネージャーはチームと一緒に計画に遅れをとり、追加のリソースを接続して問題を排除し、それらを平準化するための対策を講じます。 これにより、プロジェクトチームは、非常に標準的なリソースを使用して財務上の問題に陥ることがなくなり、プロジェクト全体の成功を危険にさらすことはありません。



計画では、コンポーネントまたはリリースのテストに関する作業が必ず追加されます。 可能性のあるエラーを修正し、再設計し、可能な限り改善するための時間が用意されています。 作業環境をテストベンチに展開するための計画されたアクティビティ、および製品の品質を保証するその他のアクティビティ。 ほとんどの場合、これらの作業は、プロジェクトの複雑さに応じて係数を考慮して、開発プロセスの総人件費の割合として評価されます。



さらに、この計画では、開発されたソフトウェアとハ​​ードウェアを使用してスタンドの展開と構成に関する作業を追加し、顧客サイトでの試運転を整理できるようにします。



以下は、ユーザートレーニングを含む、システムの実装に関する追加作業です。 大規模なプロジェクトでユーザーをトレーニングすることは非常に高価な記事であり、初期段階でそれを最小限に抑える方法を考えることは非常に重要です。 たとえば、さまざまなユーザーグループの作業を統合するため、プロセスのロボット化などによってユーザーが実行するアクションの数を減らすためです。



これらのすべての活動は、コストを評価し、プロジェクトの全資金を保証するときに見逃さないように、計画に必ず含める必要があります。





図12.-計画の形成-プロジェクトのスケジュール

2.情報システムの生産のための原価見積の精緻化

プロジェクトの詳細なスケジュールに従って、作品の完全なリストが利用可能になり、その範囲と請負業者が決定されると、そのコストを非常に正確に計算できます。



ソフトウェア製品の生産契約で定められた金額の場合、生産コストが契約の金額と重なる場合、この機会は抜け穴を残して、削減の方向に作業を修正します。 たとえば、実装をわずかに変更する、簡素化する、システムの機能を慎重に狭めるなど。



契約が段階的な実装の可能性を伴って締結された場合、作業範囲、実装のタイミング、実装の成功に対する報酬の量を規定する追加の契約を準備および締結できます。





図13.-プロジェクト計画と契約の適合性の評価

3.セクションの要約

プロジェクトソリューションの実装を計画および評価する段階には、次のアクティビティが含まれます。

1. 要件の仕様に基づいて、プロジェクトのスケジュールが作成されます。
2. プロジェクトのスケジュールに基づいて、プロジェクトソリューションの実装と実装に必要なリソースが推定されます。
3. 評価に基づいて、選択した設計決定を実施するための追加の契約（補足契約）が締結されます。

図14.-ソフトウェア製品の生産の第3段階で生成されたアーティファクト



これまでのところ、はい、そして半分の時間が既に過ぎており、その時すでにそれについて緊張し始めています...

VIII情報システムの実装

戦いは、戦いの計画を思いついた人ではなく、その実施に責任を負った人によって勝ち取られます。

ナポレオン

計画スケジュールが作成され、すべての関係者と合意したら、その実装に直接進むことができます。



ソフトウェア製品の作成プロセスを説明および規制する多くの方法論があります。 いずれか1つの手法に対するコミットメントに限定されることはありませんが、異なるアプローチを使用します。 前の手順で説明したプロセスは、ユースケースの作成の拒否を除き、設計プロセスのメシアのランクまで、RUP方法論（2）に傾いています。



最新のソフトウェア開発手法のほとんどには、反復アプローチが含まれます。

ソフトウェア開発における反復アプローチ（Eng。Iteration-“ repetition”）は、得られた結果の継続的な分析と以前の作業段階の調整と並行して作業を実行することです。 開発の各フェーズでこのアプローチを使用するプロジェクトは、PDCAサイクルの繰り返しを通過します：計画-実装-検証-評価（計画、チェック、実行のサイクル）。

つまり、各反復は一連のワークフロー全体をカバーし、後続の各反復では、その実行が循環的に繰り返し繰り返されます。 さらに、各サイクルでは、選択された、限られた対象製品の機能のみが開発されます。 したがって、反復が成功するたびに、製品（半製品）の機能が増加し、徐々にターゲットに引き寄せられます。

1.ソフトウェア製品を作成するための反復プロセス

反復の開始フェーズは、実装プロセスで実装する必要があるタスクの選択から始まります。 当然、プロジェクトのスケジュールと調整されます。 さらに、タスクのキャストは、それらの実装の結果として、製品の中間リリースで推定できる機能の具体的な増加が得られるように実行する必要があります。 ほとんどの方法論では、この段階で、反復作業の構成とその実装に関連する問題を議論するチームを対象とした計画会議が実施されます。 また、重要なことは、チームの精神、調和、チームワークを維持することです。 たとえば、スクラムの方法論（1）では、スクラムラリーを毎日開催することが推奨されています。



次のフェーズでは、これらのタスクは開発に移されます。 つまり、開発者には、指定された機能を実装するタスクが割り当てられます。



開発チーム（プロジェクトチーム全体の特定のモノリシックブロック）の形で個別のユニットであるそれぞれの開発のために、製品をモジュール、回路、サブシステムなどに既に分割しているため、このプロセスの相互作用の問題のほとんどは取り除かれました。 むしろ肩にシフトしました。 それでも、開発チームの効果的な作業を整理するというトピックに触れてみましょう。 私の意見では、この場合のアジャイル（1）の原則のいくつかが最適です。

1. 成功するプロジェクトは、やる気のある人々によって構築されます。 彼らに適切な環境を与え、必要なものをすべて提供し、彼らに仕事を任せる。
2. 情報のやり取りと情報交換の最も効果的な方法は、個人的な会話です。
3. 柔軟なプロセスが継続的な開発に貢献します。 すべてのプロジェクト参加者は、このような一定のペースを維持できなければなりません。
4. 卓越した技術と品質の高いアーキテクチャへの継続的な注意が柔軟性を促進します。
5. 行うべきではない作業を最大化する技術として、シンプルさが必要です。
6. チームは、プロセスをカスタマイズして適応させることにより、より効率的になる方法を常に模索しています。

そして、スクラムチームの一般的な作業スキームは、プロジェクトのこの段階で議論している作業組織の形式に完全に適合しています。



同時に、品質サービスは、現在の反復での実装が承認されている機能を対象としたテストを準備できます。 これにより、メインの開発フェーズが完了すると、次のフェーズに迅速に進むことができます。実装の欠陥を特定し、オープンされている場合は、修正のために説明を開発者に転送します。



エラーを修正し、品質サービスによってこの事実を確認した後、製品の中間リリースが表示されます。





図15.-ソフトウェア開発の反復の本体を実行する

2.反復の要約

反復は、結果の中間製品とその作成プロセスの両方の観点から、実装の評価で終了する必要があります。 プロジェクトスケジュールを作成する段階で、リリースされたリリースに対応するマイルストーンを設定したことを覚えていますか？ したがって、成功した各反復は、機能が制限されたターゲット製品のプロトタイプで終了する必要があります。 成功は、ToRに記載されているリリースの特性への準拠の基準によって評価できます。 顧客の代表者が評価に参加することが望ましい。 たとえば、開発された機能の潜在的なユーザー。



各反復を評価した結果、プロジェクトのスケジュールを変更し、場合によっては要件を変更することが必要になる場合があります。





図16.-ソフトウェア開発の反復の要約



前述のように、反復で実行されるプロセス自体も分析の対象となります。 コミュニケーションの難しさ、技術的プロセスの組織における誤算、実行者の相互作用などが明らかになります。 分析に基づいて、反復のプロセスの組織が調整され、これに関するデータがエンタープライズナレッジシステムに入力されます。 たとえば、変更はドキュメントで行うことができます-プロジェクトの「構成管理計画」、RUP方法論で推奨（2）。



さらに、反復プロセスはリズミカルに繰り返されます。 そして、この単調さがプロセス全体のビートを打ち負かさないことが重要です。 この場合、容赦ないカウンターは落ち着いています...

3.最終リリースの顧客への転送

一定回数の繰り返しの結果、ソフトウェアの公式バージョンが表示されます。これは顧客に転送して、ビジネスニーズを満たすという観点から評価することができます。



顧客は、請負業者の専門家と一緒に、契約に記載されているパラメーターの遵守について得られた結果を分析します。 評価の結果に基づいて、欠点、実装の不便さ、合意された要件からの逸脱などが記録されます。 フェーズの終わりに、要件とプロジェクトスケジュールを修正する必要がある場合があります。





図17.-公式リリースの顧客への転送



この段階は非常に興味深く、さまざまな解決策があります。



たとえば、スクラム方法論（1）は、顧客とのより頻繁なチーム会議および頻繁で継続的な製品配送を促進します。 ただし、大規模で複雑なプロジェクトでは、多くのコンポーネントが開発され、異なるチームによって開発され、異なるプロジェクトブランチで修正され、そのアセンブリにはこれらのブランチのマージなどが必要になります。 -この方法は非常に面倒です。 これに努力することが望ましいが、大規模プロジェクトではこの可能性が制限される可能性が高い。 さらに、華やかな組織構造と複雑なビジネスプロセスを持つ大企業の顧客従業員は、追加の会議やディスカッションに絶えず時間を費やすことはほとんどありません。 このアプローチを使用するのに好ましくないもう1つの要因は、複雑で大規模なプロジェクトのチームの存在に関連しています-アナリスト（またはアーキテクト）の独立した役割であり、実際に顧客と対話し、最も都合のよい合意された時間に情報を受信および更新します。 それでも、決定を下し、それらに対して責任を負うのはアーキテクトです。したがって、チームの役割は大幅に削減されます。 さらに、多くの場合、チームは下請け業者にすぎず、通常は顧客にアクセスできません。 したがって、アクティブな製品開発の段階での大規模プロジェクトの決定に対する集合的な影響は、スクラムのチームが提唱する方法論よりもはるかに弱いです。



合計でさらに5日間ダウン。

4.セクションの要約

設計ソリューションの実装段階には、次の機能があります。

1. 大規模プロジェクトでの設計ソリューションの実装は、ほとんどの場合反復的です。 プロセスは周期的に実行されます。計画-実装-検証-評価。
2. 各反復は、リリースのリリースで終了します。リリースのリリース自体は、機能が制限されたターゲット製品のプロトタイプです。 反復が成功するたびに、機能が成長し、ターゲット（契約で指定されている）に近づきます。
3. 各反復の結果に基づいて、製品自体とその実装プロセスの両方の評価とともに、実装の成功の分析を実行する必要があります。 反復製品は、顧客の担当者と一緒に評価することをお勧めします。

図18.-ソフトウェア製品の実装段階で生成されたアーティファクト