ITプロジェクトの要件の品質について、率直に言って（開発チームの立場から）。 パート1

以前に公開された私の記事に基づいて...

エントリー

メダルを獲得するには、裏側で何をすべきかを見つけます。

（ジョージアレクサンドロフ）

私が[1]、[2]、[3]などを読んだ要件管理に向けられた圧倒的多数の作品で、著者は顧客を中心に踊り、読者との最も効率的な仕事の整理方法に焦点を当てています。 そしてもちろん、仕事の大部分は通常、収集された情報を、開発中のシステムをモデル化する特定の設計ソリューションに変換する問題、および特殊効果、弓、フリルを使用して設計する問題に当てられます。 もちろん、これはすべて重要であり、要件の形成のこれらの側面の重要性を決して主張したくはありませんが、欠点もあります。 結局のところ、さらなる要件は、ソフトウェアの生産のための「ワークショップ」に直接分類されるべきです。 そして、彼らは、対象製品が誕生するまで、それが生まれて世界に現れる法と規則の主体であり続けるだろう。 この事実自体が、要件を最終製品に変換するために呼び出される専門家の利益にどれほど正確に要件を適合させる必要があるかという重要性を決定します。



そのため、開発者、品質管理スペシャリスト、プロジェクトマネージャーなどのパフォーマーのチームの目を通して要件の品質を見てみましょう。 結局のところ、アナリストの仕事の主な消費者はこれらの人々です。 また、この製品の品質と最終コストは、作成された仕様が特定のチームが完成したソフトウェア製品に加工するのにどれだけ正確であるかによって異なります。

この記事を書き始めた理由

それは、顧客に彼の夢の産物を示すように設計されたITプロジェクトのアナリストの仕事です。

プログラマにとって、ほとんどの場合、このタスクに対処しません。

あなた自身について少し。 キャリアの初めに、プログラマーとして、その後開発グループの責任者として働きましたが、18年後、コーディングに興味がなくなったため、システム分析とプロジェクト管理の分野に突入して、活動の種類を変更することにしました。 この分野では、10年目も一生懸命働いています。



さまざまなソフトウェア会社でこれらの3つの役割すべてで働く機会があったので、この勝利の優先順位に偏見があることがよくありました。 私はシステムアナリストがまったくいないチームで働いており、彼の役割はプログラマーに分散されていました-「無料のアーティスト」。 私は、システムアナリストがリーダーであり、開発者をさまざまな図表で占いし、対象領域の詳細から見れば取るに足りない「没入」で拷問を行うチームで働いていました。 私の練習にはチームがあり、そのリーダーはアナリストと開発者の両方の仕事の内容についてほとんど知らなかったので、彼は製品をうまく売る方法を知っていたので、彼はこのキッチンの詳細には触れず、誰もが「安心して調理」しました。



私は何を得ていますか？ ソフトウェア開発チームには、少なくともアナリストのグループ、開発者のグループ、およびプロジェクトマネージャーの間で健全な利益相反があります。 また、競合と同様に、ソフトウェア作成プロセス自体の品質を絶えず改善する機会として使用できます。

この記事はなぜ誰のために書かれたのか

小さな開発チームは社会の個々のグループの生活を複雑にし、大規模な野心的なチームは進歩的な人類の生活を台無しにします

この記事の主なアイデアは、アナリストまたはアナリストに積極的に影響を与える人々の注意を次の側面に引き付けることです。



この記事の目的は、アナリスト（特に若いアナリスト）がソフトウェア開発チームとともに、構成、詳細レベル、フォーム、情報提示の手順などを含む要件仕様の理想的なバージョンを見つけるのを支援することです。

この効果は、チームメンバーがアーティファクトの要件で使用されるエッセンスを解読し、アナリストのプライドを楽しませる形式から自分の使用に最も適した形式に変換するのに時間を費やすことがなくなるためです。 要件に応じて必要な情報を「広げる」必要はありません。 それどころか、各参加者に提供される資料である剣は、リリースからリリースまでプロジェクトでの作業を遂行する過程で慎重に指導します。



この記事で検討されているトピックは、ソフトウェア開発プロセスをフローに組み込み、ソフトウェア製品の生産のための技術ラインを構築したいチームに特に関連しています。 理想的には、このようなチームには、ある種の「コンベヤー」が必要です。この生産ライン内で作業結果をステージからステージ、参加者から参加者、問題ドメインモデルからソリューションドメインモデルに転送する仮想ツールです。 このアプローチにより、チームのすべての活動が規制され、作業はリソースの集約度の観点から明確に関税が課されます。 この調整されたメカニズムは、計画と見積もりに従って、定期的に「ホットケーキ」などのソフトウェア製品を発行します。 それは幻想のように聞こえますが、私は本当にそのようなチームが自然に存在できると信じたいです。



「パイプライン」とソフトウェア開発の技術ラインについての議論は、それ自体が別の記事に値するものです。



魅力的ですか？ 次に進む...



この出版物で取り上げられたトピックに戻り、利害関係者の主要な輪を強調し、彼らのニーズに言及します。

1. 要件仕様の主な消費者は開発者です。 これらの仕様がプログラムコードに迅速かつ正確に変換されるという点で、これらの仕様の収益性がどの程度異なるかが重要です。
2. プロジェクトマネージャーにとって、他のチームメンバーの仕様をアトミックタスクに「カット」することがいかに便利であるかが重要です。 アトミックタスクは、一方では、エグゼキューターにとって明確で明確なタスクである必要があり、他方では、詳細なプロジェクト計画を作成するためのリソースの使用の予測可能な尺度である必要があります。
3. 製品の品質を保証する専門家にとって-テストスクリプト、受け入れカードなど、要件に応じて形成することがどれほど便利であるかが重要です。

この強調の配置では、要件を形成するプロセスで、開発チームが使用する技術に非常に明確に導かれる必要があります。 ある記事では、対象分野と応用技術の最大範囲をカバーするのが難しいため、既成のコンポーネントを使用できるリレーショナルデータベースと技術プラットフォームを使用した会計システムのクラスターを例に考えます。 この場合、コンポーネントは、一般的なサービスの機能を集約する決定テンプレートとして理解する必要があります（例：リストを操作するためのコンポーネント、データを編集するためのフォームを送信するためのコンポーネント、検索サブシステム、アクセス権を制限するためのサブシステムなど）。 マテリアルのプレゼンテーションをより視覚的にするために、トレーニングプロジェクトの要件仕様の断片「要件管理プロセスの自動化」を含めました。

特定のドキュメント構造に適したオプションを決定する

低品質の要件の場合、顧客は常に支払います。 時々すぐに、時々分割払いで

おそらく次のステートメントの後、私は多くの批評家を抱えることになりますが、アナリストと開発者の間のインターフェースとして要件の仕様を検討する自由を取ります。 はい、この声明には「ストレッチ」があります。したがって、用語を百科事典に明確にすることにします。 「インターフェース-特性、接続の特性、交換信号によって決定される、情報システム、デバイス、またはプログラムの共通の区別、つまり線形に接続されていない2つの同時動作（それらの間の情報交換を含む）の機能、方法、および方法のセットなど。」 すでに感じている？



アナリストと開発者の情報システムを検討すると想定します。 これにより、要件仕様を「2つのシステム間で同時に相互作用する、またはシステムのコンプライアンスを確保する、統一されたハードウェアおよびソフトウェアツールとルール（説明、合意、プロトコル）のセット」として識別できます。 そして、これは、この記事で提案されている要件仕様を提示する構造が、アナリストと開発者のグループの相互作用を保証する交換プロトコルとして機能することを意味します。 これにより、ターゲット製品の最終仕様の実装層から分析および設計の設計層を分離できます。 そのため、テキストを読んでいるときに、図1で修正したのと同じ写真を想像することになります。





図1.-ITプロジェクトチームの相互作用の拡大図



アナリストによって開発され（図では「要件」として示されている）、設計段階で要求されたが、役に立たず、時には開発者への表示に有害な不要なアーティファクトをすべて破棄するために、インターフェイスで使用するオブジェクトを決定します（仕様）。 これを行うには、質問に答える必要があります：開発者は最終製品を作成するために何を使用しますか？ プラットフォームに基づくソフトウェア開発の例が例として選択されたため、ターゲットシステムは、図2に示すように、一定の調整された相互作用が「動作プログラムの効果」につながるコンポーネントのセットとして表すことができます。





図2.ターゲットシステムのコンポーネントモデル。



したがって、選択されたオプションの仕様は、図に示されている要素のインスタンスを必ず詳細に記述する必要があります。 2およびその実装方法。 つまり、システムアナリストは、自分の仕事（またはビジネスアナリストの仕事）の成果を開発者が使用するテクノロジのトラックに変換し、選択したプラットフォームの用語と概念で特定の要素、その動作のアルゴリズムなどを記述する必要があります。 翻訳の深さの程度は、システムアナリストの能力と開発チームのニーズによって異なります。



仕様の要素の構成を決定したので、ドキュメントでの表示の可能な順序を見つけましょう。 実行のさまざまな段階は相互に、またはそれらのアクティビティの結果に依存するため、実行するのに最も便利で合理的な順序を確立します。 図3は、考えられるプロセスのモデルを示しています。前述のテクノロジープラットフォームを使用して、要件に基づいてソフトウェアを作成しています。





図3.メインソフトウェア作成プロセスのバリアントのモデル



この図は、順次実行される機能を含むプロセスを示しています（大きな矢印のような図の形で表示されます）。 上の部分はこれらの機能を実行するリソース（開発者）を示し、下の部分はプロセスに関係するターゲットシステムの要素を示します。 矢印は、機能から機能へのデータの転送を保証する情報の流れを示します。 すべてがシンプルで明確です。



したがって、次のセクションをドキュメント構造のバージョンに含める必要があります。

1. サブジェクトエリアのエンティティ。
2. ユーザーインターフェース
3. ユーザーインターフェイスイベントに関連する手順。
4. 補助プロセス（トリガー、後処理など）;
5. 定期的なタスク
6. レポートテンプレート。
7. アクセス権;

必要に応じて、プラットフォームがサポートするワークフロー、コンテキスト検索条件などの説明を含むセクションを含めることもできます。



可能であれば、アナリストによって開発された他のすべてのデザインオブジェクトは、注意を分散させず、ドキュメントの量を増加させないために、開発チームに転送される要件から除外する必要があります。



以下のパートでは、この方法で準備されたリンク要件の仕様がどのように見えるかの例を示します。 また、専門家によるPMとQAによる効果的な使用のオプションを例で示します。



トピックに関する著者のトレーニングについて：「ITプロジェクトでの要件の形成の実践」は、 IC Tavrida LLC会社のWebサイトで見つけることができます。