顧客の視点からのソフトウェア製品の技術仕様（TOR）の開発

仕事中に、ソフトウェア製品の技術仕様を開発するプロセスをいくつかの観点から見ることができました。 アナリストの観点から-直接請負業者、TKを作成するプロセスを組織する請負業者側のプロジェクトマネージャーの観点から、これらのTKを実装する開発者グループの長の観点から、および以前に開発されたTKについてその後決定を下す顧客の観点から。



これらの利害関係者はそれぞれ、「よく書かれたTK」がどうあるべきかという独自の要件とビジョンを持っていると言わなければなりません。 たとえば、顧客と請負業者は、この件に関してまったく反対の意見を持つ場合があります。 請負業者は、作成されたソリューションの機能に関する義務を可能な限り形式化するために、最も詳細なTORに関心を持つ場合があります。 同時に、将来のシステムのパラメーターを正確に決定していない、または「頭に風」がある顧客は、合意された予算の枠組みに新しい要件を含めるために、より一般的な定式化、大ストロークでのシステムの説明が必要になる場合があります。 もちろん、顧客と請負業者の「メンタリティ」が異なると、すべてがまったく逆になる可能性があります。 次に、可能な状況、目標、および行動の戦術を考慮して、顧客の観点からTKの開発について詳しく説明します。



まず、TKの開発に影響を与える要因を判断しましょう。 まず第一に、これは顧客が要件を理解する度合いです。 前述のように、TKでの作業を開始した時点では、どのようなシステムを作成したいか想像することはできません。 初期データとして、新しいシステムの作成に関心のある部門からの断片化された、しばしば競合する要求があるかもしれません。 ITサービスがそれらを構造化できた場合、矛盾を解決して、請負業者とのコミュニケーションの準備をします。 そうでない場合、最良のオプションは、最初に非常に一般的なTORを開発することです。これは、システムのビジョンを大まかに記述し、必要なモジュール（サブシステム）を機能の詳細に入らずにリストし、次に請負業者と協力してそれらの要件を詳述することです。 TKの後続のバージョンは、元のTKへの追加の形で、またはいわゆるの形で実行できます。 ソリューションモジュールの「プライベート参照条件」（ChTZ）。 これにより、最終的に何を取得したいのかをよりよく理解し、プロジェクトの作業のために会社の部門を動員し、必要な情報を収集し、作成されたソリューションのトピックが新しい場合は基本的な概念を習得する時間ができます。 また、請負業者はあなたの会社の活動をよりよく知ることができます。



重要なポイントは、ドリフト要件の確率です。 企業は変化し、外部の課題に適応します。そして、これはしばしば非常に迅速に起こります。 今日開発されたものは、その目的に役立ち、明日、元の形では完全に不要になる可能性があります。 将来の不必要な問題を回避するために、すぐに請負業者と話し合い、長期的な協力に同調する必要があります。 これらの条件の有能なパフォーマーは、いわゆる ソフトウェア開発のスパイラルモデル。このフレームワークでは、実際、TKは新しいスパイラルラウンドごとに開発され、ソフトウェア製品の次のバージョンで発生する変更を記述しています。 この場合、面倒な初期TKの作成を拒否して、最初のバージョンに限定することができます（反復）。



実際、プロジェクトの予想期間は、要件のドリフトの要因の1つです。 長期的には、かなり不器用な会社であっても、多くは変化する可能性があります。たとえば、新しいビジョンを持つ新しいリーダーシップが現れます。 反対に、プロジェクトが小さくて速い場合、最良のオプションは、1つの小さくてかなり詳細なToRを開発、調整、実装することです。



個々のソリューションコンポーネントを作成するプロジェクト参加者のかなりの数が、技術タスクの段階で隣接モジュールの仕様と実装機能を考慮するだけでなく、彼らが開発した技術タスクの詳細を必要とします。 これは将来、モジュール間の不一致のリスクを最小限に抑え、それに応じて、やり直しのための不必要な心理的および物質的コストを回避するのに役立ちます。



タスクの複雑さもTKの作成方法に影響します。 残念なことに、このタスクは、顧客だけでなく請負業者にとっても複雑すぎる可能性があります。請負業者は、このクラスのソリューションを作成した経験があると思われます。 困難は通常、作成されたソリューションが典型的でなく、プロジェクト参加者がその実装とビジネスでの使用の結果を事前に予測できないという事実にあります。 この場合、プロジェクトをステージ（ステップ）に正しく分割することが非常に重要です。これは、次の各ステップが前のステップで達成された結果に従って調整されることを意味します。 したがって、参照の条件は、前の段階の経験に基づいて、各段階の開始時に作成されます。



企業は実際の環境で働いており、多くの場合、以前に働いたことのない新しいパートナーに対処する必要があります。 ITソリューションの開発者にも同じことが当てはまります。 もちろん、あなたのビジネスのすべての詳細を完全に知っており、あなたを完全に理解し、あなたが100％確信している請負業者を持つことは良いことです（この場合、あなたはTKの開発を拒否することができます）が、実際にはこれはあなたにとって完全に未知であることが判明するかもしれません会社。 この場合、もちろん、可能であれば小規模なプロジェクトと、ToRで指定された要件を明確かつ詳細に表現して、協力を開始することをお勧めします。



もちろん、技術仕様の詳細度とその開発時の多様性は、顧客にとって重要な唯一のポイントではありません。 TKの開発を開始する前に、その構造を決定することを強くお勧めします。実際、TKでの作業を開始する前に、プロセス中または後ではなく、コンテンツ、段落およびサブパラグラフのリストを含むページをコンパイルします。 この場合、あなたと請負業者の両方が、この段階でどの問題を考慮する必要があるかについて同意します。 あなたは最終的に何を得るかをよく理解し、パフォーマーはあなたに彼に期待することを理解します。 見かけの単純さにもかかわらず、これは大規模で複雑なプロジェクトであっても常に行われるとは限りません。 その結果、TKはさらなる作業に対して完全に無作法であることが判明する場合があります。



ご存知のように、プロジェクト文書の形式の程度が異なるなど、さまざまなソフトウェア開発方法論があります。 ただし、TKはそれらのいずれかに明示的または暗黙的に存在します。 同時に、このドキュメントのテンプレートは、企業やソフトウェア開発プロセスによって大きく異なる可能性があります。 システムの将来の開発者は、自分が採用したTKテンプレートを課すことができますが、この場合、まず、TKは請負業者だけでなく、その構造を決定する完全な権利を持つ顧客にとっても最も重要なツールであることを理解することが重要です。 そして、第二に、顧客とエグゼキュータがソフトウェア製品の共通のビジョンを形成することにあるTKの常識と主な目的は、開発方法論のいずれも打ち消しません。



現在、ロシア連邦ではGOST 34.602-89「自動システムの作成に関する参照条件」が施行されており、作成89年目にもかかわらず、TKの一般的な構造をよく反映しています。 それにもかかわらず、多くの場合、それは十分に詳細ではなく、最新のソフトウェア製品の開発の詳細を十分に説明しています。



私自身の経験から、他の問題の中でも特に、ToRでの検討の必要性に請負業者の注意を向けることを推奨できます。



システムで作業しているユーザーのカテゴリ（ロール）-ロールをリストし、どの部署のどの投稿に対応するかを簡単に説明します。

システムの機能は、階層構造を構成することです。この構造では、大きなモジュール（サブシステム）が上位レベルにリストされ、さらに小さな機能ブロックや個々の機能まで詳細に説明されます。

システムを使用するモデルは、システムのユーザーのカテゴリーと、上記のユーザーが使用する機能ブロックを比較することです。

基本的なビジネスプロセスを実行するときにシステムを使用するシナリオは、実際のプロセスにソリューションのビジョンを課し、どの段階でどのように使用されるかを説明することです。 時間をかけて、請負業者と一緒に、少なくとも主要なビジネスプロセスのシナリオをグラフィカルにスケッチし、関係者と調整します。

ユーザーインターフェイスのプロトタイプ-たとえば、Microsoft Visioを使用して、将来のソフトウェアの基本的なフォームを模式的に示します。

論理データモデル-サブジェクトエリアの主要なエンティティとそれらの間の関係を示します。 これにより、あなたとパフォーマーは共通の用語を使用して同じ言語を話すことができます。

データソースと他のシステムとの相互作用-システムが導入されたときに初期データがロードされる場所と、後でどの外部ソースから取得されるかを説明します。

TKにおけるこれらの問題の検討は、上記の要件の不確実性を考慮して、「狂信なし」にアプローチする必要があります。 それらの詳細な研究は、システムを作成する後の段階に任せることができますが、ToRの開発で少なくともそれらの概要を説明する場合は、請負業者と自分自身に、紙にのみ存在し、まだ変更されていないソリューションについてよりよく考えさせますグローバルな財務および時間コストに関連しています。



結論として、私の経験では、最良のTKは、顧客自身または顧客の最も積極的な参加によって書かれたTKです。 あなたの会社の従業員ほどあなたのニーズや仕事の詳細を知っている人はいないので、インタビューで見つけることは常に不可能です。 もちろん、このためには、十分な資格のあるIT専門家をスタッフに配置するか、ITコンサルタントのサービスを使用する必要があります。 取得したTKは、多数の潜在的な請負業者に必要な結果を明確に理解し、提案を受け取るために、入札書類の一部として使用できます。



独自に開発されたTKのもう1つの利点は、お客様のニーズのみを反映し、請負業者が使用するテクノロジープラットフォームの制限や再利用の経験を反映しないことです。 もちろん、請負業者は追加の調査を実施して独自のプロジェクト文書を作成する必要がありますが、これらの文書はすべて、開発したTKの要件に準拠する必要があります。 特定のパフォーマーにとって要件のいずれかが実現不可能であることが判明した場合、あなたは確かにこれについて知り、適切な決定を下すことができます。