ITプロジェクトの要件をAからZに作成する方法。パート7。要件を実動に移します。 おわりに

XI要件の指定

要件は、現実世界の問題を解決するための一時的な仲介者にすぎません。

「ソフトウェア開発工場」[8]

メインの設計成果物の準備ができたら、要件の仕様に直接進んで、ターゲット製品に対する顧客のニーズを実現する開発者にそれらを転送できます。 この製品の品質と最終コストは、作成された仕様が特定のチームがそれらを完成したソフトウェア製品に処理するのにどれだけ正確であるかに依存します。



このグループの作業の目的：対象製品に関する収集された情報に基づいて、要件の高品質仕様を準備し、実装を最も効率的に編成できるようにします。



そのような表現を使用するために、サブシステム、ループ、ドメイン、または他のグループの形式で要件に部品を分割します。 それらを個別のドキュメントとして作成します。 サブシステムには、システムのすべてのプロパティ、特に整合性（サブゴールによる）および出現（システムのプロパティの要素のプロパティへの既約性）プロパティが必要であることを明確にします。 しかし、システムのコンポーネントは、サブシステムとは対照的に、サブゴールが定式化されておらず、整合性がない要素のセットにすぎません。



ほとんどのサブシステムは自給自足ではないため、モデルだけでなくその要素も参照して、サブシステム間の相互参照を確立する必要があります。 したがって、プロジェクトで使用されるすべてのアーティファクトの完全なカタログを作成することをお勧めします。 これらの目的のために、彼らは通常、ドキュメント「構成管理計画」を使用します。 以下は、プロジェクトで使用されるドキュメントの説明の例です。







示されたアーティファクトに加えて、「構成管理計画」には、プロジェクトとそのパーツ（プロジェクトチーム）の責任者、使用済みツール、プロジェクト作業スケジュール、ワークステーションとプロジェクトストレージへのリンクなども含まれます。 しかし、このドキュメントはプロジェクトマネージャーの能力の範囲内にあるため、この作業では詳細に説明しません。



このセクションは、私の記事「ITプロジェクトの要件の品質について、正直に（開発チームの立場から）」のほぼ完全に以前に公開されました。 したがって、再入力はしませんが、元のソースを紹介します。 出版物の残りの部分を読んだ後、このセクションが新しい方法で認識されることを望みます。

XII要件をターゲット製品に翻訳します

この出版物のフレームワークでは、要件管理の側面に関連するソフトウェア製品の生産プロセスのみを詳細に分析します。 したがって、要件をターゲット製品に変換するプロセスを「ブラックボックス」と見なし、その入力に仕様が転送され、出力はそれらを満たすソフトウェア製品になります。 ただし、ここでは転送プロセス自体とそのすべての側面について詳しく説明します。

1.ターゲット製品の実装プロセスに要件を転送します

要件のライフサイクルにおける重要な瞬間であるライフサイクルの頂点は、実装のためのプロジェクトマネージャーと開発チームへの移行です。 したがって、このプロセスは、それを漂わせず、要件へのリンクのテキストで示す通常の文字に限定されない方が良いです。 いいえ、私はこれを華やかで特別な効果で行うことをお勧めしませんが、出口で受け取るべきものと実際にそれを行う方法についてチームが誰も誤解しないように手順を編成する必要があります。



要件をターゲット製品に変換するプロセスでさまざまな役割を果たすチームメンバーの調整と効果的な相互作用のために、問題解決のライフサイクルをサポートする多くのシステム（Jira、Mantis、XBTrackなど）のいずれかを使用することをお勧めします。 この出版物では、ツールではなく、開発チームがアナリストの仕事の成果を最も効果的に使用するのに役立つ側面に焦点を当てていることを思い出させてください。



頻繁ではありませんが、一部のチームの要件を開発に移行するプロセスは、形式化されていて官僚的であることがありますが、ほとんどの場合、単に偶然に任されています。 そして、その場合と別の場合には、多くの危険と落とし穴があります。 プロセスが過剰に管理されている場合、変更を行うのに大きな困難があり、それをサポートするコストが増加します。 転送手順がまったくない場合、プロセスは実質的に制御できず、製品が複数のチームを開発する場合、このアナーキーは特に敏感です。



この問題の最適な解決策として、わずかに変更された管理委任ルールを使用することをお勧めします。

1. 開発要件は、適切な権限を持ち、その実装に責任がある特定の従業員にのみ転送できます。 それ以外の場合は、質の高い方法で機能を実行する能力の不足について経営陣に通知してください。 このルールは、無用な24時間会話の時間を節約するのに役立ちます。
2. 各要件の実装中に取得する必要がある最終結果と、タスクを完了するための方法を請負業者に明示的に規定します。 自分が正しく理解されていることを確認し、作業の結果を表示どおりに確認することをお勧めします。 これにより、情報の通信の歪みが回避されます。
3. 必須および望ましい機能を考慮に入れて、要件の実装の優先順位を決定します。 これにより、実行可能なモジュールを取得する可能性が高まり、一部の機能が犠牲になります。
4. 実行者が要件の実装に問題がある場合は、要件を明確化、明確化、または変更するためにすぐに連絡する必要があることに同意します。
5. 作業の進捗を定期的に分析し、要件の実装で発生した問題について話し合います。
6. 制御の強度を徐々に減らし、説明と手順自体を簡素化するために、要件を開発に移行するプロセスを改善および開発します。
7. 既製のソリューションの配信スケジュールを承認する。

概して、このプロセスの責任はプロジェクトマネージャーにあります。 しかし、プロセスが失敗した場合、「誰も理解できないあらゆる種類のごみ」を書いたアナリストが非難されることがほとんどです。 したがって、ストローを適切な場所に事前に広げるためには、アナリストはこの機能を自分で果たさなければなりません。

2.開発した製品をお客様に転送します

開発者からシステム要件を満たす完成品が受け入れられた後、実装チームはターゲット製品を顧客に転送するタスクに直面します。 ここではアナリストなしで行うことができますが、難しいので、このプロセスのいくつかの重要なポイントについて簡単に触れたいと思います。



開発したシステムを顧客に移すとき、開発チームの観点から彼のビジョンをユーザーに伝えるために、作成した製品の哲学について最も完全な理解を彼に提供することが望ましい。 多くの場合、ユーザーは新しいソフトウェアを認識しません。これは、以前の経験によって形成された、必ずしも高度ではないという期待を満たしていないためです。 これは、新製品の導入に対する障壁になる可能性があります。



したがって、ユーザー自身がソフトウェアの「チップ」を見つけ、痛みを伴う試行を通じて、「異常な」インターフェースをナビゲートするためのオプションを見つけるまで待つ必要はありません。 アナログよりもシステムの利点を彼に伝え、ユーザーにそれを心配させます。 また、ユーザーが「上級」の場合-使用するテクノロジーが業界のリーダーによってどのように適用されているかをユーザーに示します。

XIII対象製品の運用中の要件の変更の問題を解決します

要件管理プロセスの非常に重要な特性は、変更への適応性です。 システムの要件を変更するコストは、実装の段階によって大きく異なります。 要件が適切に作成されると、対象製品のプロトタイプが作成される段階であっても、要件を変更するプロセスが容易に実行されます。 また、既存の製品の進化のコストを削減するのにも役立ちます。



私の実践では、プロジェクトに参加した経験があり、そのチームは開発の初めに、高品質の要件を作成するアプローチを完全に使用し、それに基づいてプログラムコードを作成しました。 定性的に開発された要件により、複雑で機能的に正しいデータ構造と処理システムを作成できました。 しかし、製品が運用された後、要件管理プロセスは中止され、製品は小規模ながら頻繁に変更されることにより開発が続けられました。 その結果、1年半後、システムは複雑さを誰も完全には所有していない状態に達しました。プログラマーでもアナリストでもありません。 それに対する各変更は、地雷原を歩いているように見え始めました。変更を行った後、次の瞬間にどこでいつトラブルが発生するかわかりません。

変更のジレンマ：要件を変更して承認した瞬間から、以前のバージョンで開発されたソフトウェア製品は関連性がなくなり、「無効」になり、要件と矛盾します。

1.要件の変更を通じてのみ、製品に変更を加えます

ターゲット製品に変更を加える場合は、要件を変更し、製品への実装のチェーン全体をさらに検討する必要があります。 これはスローガンではありませんが、非常に望ましい必要性です。 このアプローチにより、製品の機能を何度も苦痛なく変更できます。 これは、すでに動作しているソフトウェアを変更すると、システムの他の部分の動作に一連の変更が必要になる可能性があるためです。 現在の要件があるため、これらの追加の変更のほとんどは予測および設計できます。または、製品の安定性のためにイノベーションを単に放棄することができます。



したがって、要件はバージョン管理され、実装のすべての変更とタスクを表示できる必要があります。 開発者にタスクを割り当てる前に、すべてのモデルと仕様に適切な変更を加える必要があります。



しかし、これは理論上であり、設計段階で事前にかなりのリソースが用意されています。 しかし、実際には、たとえば、テストや顧客への予備表示の結果として、プロジェクトで要件の迅速かつ頻繁な変更が発生することが非常に頻繁に発生します。 プロジェクトは開発中であり、基本的な要件はチームの記憶に残っていますが、開発者向けに設定されたタスクに基づいて、ターゲット製品に変更を加えるオプションが可能です。 しかし、事後、すべての変更は必ず要件で「更新」する必要があります。 現時点では、高品質の要件と非体系的なノートの違いは特に顕著です。 体系化された仕様は強度が確保されているため、プロジェクトの作業スケジュールから逸脱し、制御性を大きく損なうことなく要件を後で安定させることができます。 これらの逸脱の規模と期間は、プロジェクトの規模と段階によって異なります。 これは、「プロジェクトの後半段階でも要件の変更を受け入れます」と主張する柔軟な方法論に欠けていることが多いものです。 スローガンは良いですが、残念なのは、そのような注目を集める声明をサポートできるメカニズムの少なくともいくつかの言及によってサポートされていないことです。

2.変更要求を通じてのみ要件を変更します

要件変更のもう1つの非常に重要な側面は、プロジェクト参加者全員との完全な調整なしにそれらを作成してはならないことです。 要件が既に実装されている場合、製品アナリストとアーキテクトは、最初に製品の残りの機能に対する変更の影響を詳細に分析し、関連するコンポーネントとプロセスの可能な変更の範囲を提案する必要があります。 この方法で取得された変更のプールは、すべての関係者によって承認されなければなりません。その後、イノベーションの設計と文書化のプロセスに進むことができます。 設計プロセスの後、受け取ったモデルを顧客に承認し、その後で実装に進むことをお勧めします。



実際のプロジェクトでは、時間が常に不足しているため、このアプローチを順守することは困難です。 したがって、少なくとも、変更に関心のある人からの「要件の変更要求」を使用する実践を導入してください。 この場合、システムは、顧客だけでなく製品の設計者と開発者による承認も必要とする、別個の要件ステータス、またはむしろそのバージョンを持つ必要があります。 変更要求を行うことは、製品の期限を交渉する際に非常に役立ちます。 顧客はほとんどの場合、製品に対する希望を繰り返し変更したことをすぐに忘れてしまい、製品を運用する期限に間に合わないのではないかと考えます。 この場合、作成日、承認日、締め切り日を彼のアプリケーションに提示できます。 このデータをより説得力のあるものにするために、何かを変更する必要が生じた理由、変更のイニシエーター、および環境（変更が重大な影響を与えるべきオブジェクト）の説明を文書に含めてください。

XIVの結論

したがって、この出版物で、あなたと私は、ソフトウェア製品の開発に関する意思決定から、生成された要件仕様を開発者と彼らが開発した製品に顧客に転送することまで、システム要件の形成に大いに貢献しました。



パブリケーション全体をより適切にプレゼンテーションするために、このプロセスのすべてのステップを1つのプレゼンテーションにまとめましょう。







この出版物では、要件をどのように開発するか、プロセス全体を感じて感じる機会をどのくらい与え、ソフトウェア生産の出発点である独自の最高の技術プロセスを開発するようにあなたにプッシュするかを読者に教えたくありませんでした。 私が成功した場合、あなたのフィードバックを待っています。