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

V設計作業のスケジュールの開発

偉大で重要な仕事を成し遂げるには、2つのことが必要です。

明確な計画と限られた時間。

アルバートハバード

そして、顧客とエグゼキュータは握手を交わし、何を生産するかを決定し、おおよその条件とコストを決定しました。 ソフトウェア製品の生産の第2段階が始まります。



プロジェクトマネージャーがプロセスの渦に積極的に関与するときが来ます。 いいえ、彼は前にイベントに参加できました。 たとえば、労働投入の評価、条件の決定などに関連しているが、現在、彼は計画と管理のすべての習熟を完全に実証する機会を得ています。



現在のステップでは、ターゲットシステムの詳細な要件はまだ明確ではなく、現在のアクティビティのフレームワークで特定する必要があるだけなので、計画は便利な部分に分割されます。 開発されたシステムの設計ソリューションを形成するためのタイムテーブルは、すでに詳細に検討することができますが、その実装と実装の計画は、第2段階の完了後、少し後で詳細にすることができます。



プロジェクトマネージャーが計画に最初に含める必要があるのは、自分の仕事です。 他の線は、ガントチャートのこのトラックの長さとほとんど競合できません。 その下には、設計および分析部門の従業員のトラックがあり、一部の場所で中断されています。







あまり手間をかけずに前進しながら、スケジュールの作成に取り組みます。 競合するプロセスと保留中のアクティビティはまだ確認されていません。 トラックの主要な絡み合いは、後でガントチャートに表示されます。これは、設計上の決定が形成されたときに、開発および実装段階にタスクを設定する動機があります。 これについては、順番に詳しく説明します。





図6.-プロジェクトスケジュールの開発

VI情報システムの設計ソリューションの形成

多くの場合、設計上の問題の解決策は妥協で終わります。利点を得るには、欠点を払ってください。 ほとんどなし。

コンスタンチン・フェオクティストフ。

最初の段階では、製品コンセプトのみが開発されたことを思い出させてください。製品コンセプトは、方向-どこへ移動するかを決定する概念的なソリューションです。 ここで、通常の機能をサポートできるソフトウェアパッケージとハードウェアを詳細に設計し、計画の実装のためのリソースを事前に決定する必要があります。

1.要件の明確化と詳細化

骨の折れる作業は、情報の混chaosを通常の民間言語から禁欲的で首尾一貫した音節に変換することから始まります：モデル、図、テンプレートの説明。



自動化が必要なビジネスプロセスの段階的な連鎖。 それらによると、コンポーネント間を流れるシステム機能とデータストリームが形になります。



ストレージのモデルが構築され、情報が群がり、サブジェクト領域の実際のエンティティの相互の影響を反映する論理接続が決定されます。

次に、システムオブジェクトの動作がモデル化され、システム自体とその外部の両方で発生するさまざまなイベントに対する反応を引き起こします。



これらの作業を実行するための私の推奨事項の詳細は、 AからZまでのITプロジェクトでの要件形成の実践の出版物にあります。 パート3-パート6 。



そして今、データ構造が明確になり、ユーザーとこのデータとの相互作用が解決され、これらの影響に対するシステムの応答がわかったら、製品の外部設計に近づくことができます。





図7.-情報システムの生産のためのTKおよびその他の文書の準備



自動化されたサブジェクト領域に応じて、システムセキュリティ、レポートフォーム、およびその他のニュアンスの要件を記述することも必要です。



その間...







理想的には、設計上のすべての決定は、理解しやすくアクセスしやすい方法で顧客の注意を引く必要があります。 そして、彼からの応答で、生産の結果として、ドキュメントに記載されているパラメーターと機能的能力に対応する情報システムを正確に受け取ることを期待しているという承認を受けました。 しかし実際には、これを達成することは非常に困難です。 この複雑さは、いくつかの理由により発生します。

• ドキュメントに記載されている内容を顧客が明確かつ正確に理解していない。
• 問題を解決する他の方法が見当たらないという事実にもかかわらず、疑わしい解決策に同意する責任を負う顧客の代表者への恐れ。
• 製品の製造中に要件が変更される可能性があり、承認されたプロジェクト見積りのコストが大幅かつ重大に上昇する可能性がある。

実行者のチームは、顧客との設計決定の調整の欠如が、プロジェクトのリソース消費を増加させるすべての財政的リスクを彼らに委ねることに注意しなければなりません。 これが何に関連しているのかを詳しく見てみましょう。



アジャイル方法論（アジャイル）（1）で最も重要な原則の1つは、「プロジェクトの後半段階でも要件の変更を受け入れる」ことと、「顧客に血液の署名を強要せず、厳しい契約条件に制限すること」です。 これらの原則とは対照的に、「残酷な」ウォーターフォールモデルは通常すぐに提供され、情報システムの生産を開始する前に必須であるソリューションの詳細な設計と詳細なドキュメントを提供します。 この点について説明しましょう。



私の意見では、スクラムの宣伝者は明らかにistsです。 実際、長い間、純粋な形の滝の使用を実践している人はいませんでした。 おそらく、情報のキャリア-パンチされたカード-が消えたからです。 それにもかかわらず、最新のモデリングツールを使用すると、複雑な作業を一切行わずに、ソリューションおよびあらゆる種類のプラットフォームとフレームワークを非常に効果的に再設計でき、それらを効果的に完成品に実装できます。 つまり、最新プロジェクトの開発の後期段階であっても、製品への変更の導入に関して根本的な問題はありません。 唯一の質問は、ほぼ完成品のこれらすべての縮退に対して誰が支払うのかということです。 2つの基本的なオプションがあります。

1. 顧客は無制限の金融ローンを保有しており、製品開発を計画するときにプロジェクトの合計金額は重要ではありません。 たとえば、以前に合意した決定に新しい変更が加えられるたびに、彼は分厚い小切手帳を取り出し、新しい小切手を書きます。
2. 一定の量の契約を締結した顧客は、試行錯誤によって製品を彫刻し、自分に最適なソリューションを見つけようとし、疲れるまで、または演奏者が壊れるまで、演奏者にモジュールとサブシステムを捨てて再作成させます。

たぶん私はひどく不運だったかもしれませんが、私の練習の最初のシナリオを満たしていませんでした。 彼は二番目の人質でした。 印象は最もひどかった、私はこれに遭遇することを誰にも勧めません。 出版履歴で、同じような状況に置かれた経験を語りました-信頼に関する1つのプロジェクト。 または、どれくらい小さいものが気分を害します。



私はこのようにスクラムの原則を再定式化します：「プロジェクトの後半段階でも要件の変更に対応できますが、これには顧客にとって大きな財政的コストまたは請負業者にとって大きな損失が伴う可能性があります。」 これに従って、選択を行う必要があります。

1. 設計段階で、作成される製品の最適なモデルを開発し、ある程度の確率で、ほぼ予測可能な推定値を満たします。
2. 自社のリスクとリスクで試してみて、製品の実装中に既にソリューションを設計し、探してください。用語と財務面で何がコストになるかを正確に理解していません。

最初のケースでは、顧客は、自分のニーズを完全に満たさない製品を受け取るリスクがあるため、苦しむ可能性があります。 第二に、主に製品を作成するために必要な時間とコストを予測するのが難しいため、すべてが苦しむ可能性があります。 顧客は自分の財務能力を超えるリスクを負い、製品の開発を凍結することを余儀なくされ、実行者は実行された仕事に対して支払いを受けず、評判を失うリスクを負います。



大規模プロジェクトに関して同意できない柔軟な方法論のもう1つの原則は、「誰も読まない洗練されたプロジェクトドキュメントを書く代わりに、製品に集中し始めました」です。 まあ、例えば、小さなプロジェクトの場合。 繰り返しますが、製品開発プロセスを文書化する人は、製品に焦点を合わせていませんか？ 実際、彼らは製品をモデル化し、文書化します。 そして、異なるチームが異なる時期に開発した多数のサブシステムとモジュールで構成されるシステムが構築され、さらにサードパーティのシステムとやり取りする場合はどうしますか？ さまざまなコンポーネント間のこの対話型通信をすべて調整する方法は？ たとえば、一連のイベントの実行シーケンスのバリアントとそれらに対する応答のバリアントはありますか？ 本当に異なる言語で書かれたコードのコメントによると？ そして、ここで、あらゆる段階で要件を変更する意欲を追加します。 チームがモジュールと他のモジュールとのやり取りのためのインターフェイスを実装している間、他のチームはすでに要件を変更しており、現在は古い形式でやり取りする準備ができていません。 チームが製品に「集中」し、ドキュメントが不足しているため、どの形式が現在関連しているのかを見つけるのは困難です。 今後、アジャイル愛好家のために、この手法は、私の意見では、大規模プロジェクトでも効果的に使用できることを明らかにしますが、少し後で説明します。

2.要件仕様の形成

すべてのモデルとスキームが開発され、技術的な説明が生成され、設計段階の成果物の完全なセットが組み立てられると、それらを実装段階に転送するための要件仕様の形成に進むことができます。 これは何のためですか？



技術文書には、設計段階でのみ必要であり、要件を処理する過程で開発者とプロジェクトマネージャーにのみ負担をかけるダイアグラム、モデル、テーブルなどの多くのサポート情報が含まれています。 実際、開発チームの生産的な作業のために、彼らが一連のタスクを取得することが重要です。タスクの一貫した実装は、ターゲット製品の外観につながります。





図8.-要件仕様の形成



たとえば、RUP（2）方法論では、要件分析のワークフローは設計プロセスとは別個のものです。 分析の段階で、より深い形式化が実行され、プログラマー環境の言語の要件を概算することができます。 要件のより明確な構造化も提供され、設計決定の明確かつ明確な理解を提供します。



したがって、要件を実装段階に移す前に、プロジェクト文書を要件の仕様に変換する追加のステップを実行することをお勧めします。開発環境に近い用語で、ターゲットシステムの記述の構造化されたセットです。 たとえば、データベーステーブル、プロシージャ、フォーム、ボタン、メニュー、入力フィールドなど。 同様のセットは、プログラマーのプロダクションに送信するために、実装段階で収集された関連タスクのセットに簡単に変換できます。 同じセットが、テストケースの作成の基礎として、また品質管理のフレームワークの他のアクティビティとして機能します。 詳細については、率直に言って（開発チームの観点から）、ITプロジェクトの要件の品質に関する記事でこのトピックを開示しました。



そして、カウントダウンカウンターは何を示していますか？...

3.セクションの要約

本格的な設計は、大規模な情報システムの実装の品質、タイミング、コストに大きな影響を与える重要な要素の1つです。

1. すべての設計作業を明確に計画する必要があります。 詳細な計画のための十分な情報がない場合、プロセスを部分に分割し、段階的に詳細なスケジュールを作成できます。
2. 設計ソリューションを形成するときは、生産の最初の段階で開発されたシステムを構築するという概念が基礎となります。 情報を明確にし、分析し、構造化する必要があります。
3. 収集した情報に基づいて、システムモデル、説明、アルゴリズム、およびその他のプロジェクト成果物を、企業で受け入れられる量と形式で開発する必要があります。
4. 設計の決定に基づいて、参照条件（TOR）を作成する必要があります。これは顧客と合意する必要があります。
5. プログラムコードで要件を具体化するチームの効果的な作業のために、ソフトウェア製品実装段階にそれらを転送するための技術要件の要件仕様を策定することが望ましい。

図9.-設計ソリューションの開発段階で生成されたアーティファクト