影響分析文書に何を入れましたか？

したがって、バグを修正しているときに、ソフトウェア製品の他のモジュールに影響を与える可能性のあるバグに遭遇しました。あなたのデータは、修正の影響についてのあなたの主張をサポートするのに十分ではなく、影響分析文書を作成するように求められました。

1. これを行う方法について定義されたプロセスはありますか？
2. 必要な重要な情報は何ですか？
3. このドキュメントの既知のフォーマット/テンプレートはありますか？

私が働いている会社内で作成された影響分析用に見たテンプレート。変更リクエストを評価する前、および変更リクエストに取り組む前に（場合によっては一部を拒否するために）使用します。次のようなセクションがありました：

• 要件への影響：このセクションでは、アナリストは、要求された変更をサポートするために、ユースケースで変更が必要なものを記述します。
• 設計とアーキテクチャへの影響：このセクションでは、設計者と設計者が、変更をサポートするためにモデルのどの部分を変更またはやり直す必要があるかについて説明します。
• テストへの影響：QCは、更新が必要なテストケースを記述します。
• 見積もりとスケジュールへの影響：プロジェクトマネージャーは、必要な労力と変更のコスト、およびプロジェクトスケジュールへの影響を見積もります。

考えられるすべての影響をカバーするには、依存関係を確認する必要があります。双方向トレーサビリティマトリックスがある場合は、それが容易になります。

上記の順序を使用したのは、設計者が変更をより深く理解するためにアナリストの視点からの影響を知る必要があり、テスターがアナリストとアーキテクトの意見を知る必要があるためです。同様に、PMはコストとスケジュールを知るためにすべての情報を必要とします。

これはCRで使用しましたが、バグでも同じように使用できます。また、バグを解決するためにいくつかの修正ソリューションから選択するためにこれを行う必要がある場合は、考えられるすべてのソリューションに対して影響分析を繰り返し、すべてのデータを1つの意思決定分析および解決（DAR）フォームに統合して、どのソリューションが正しいかを知る必要があります。最高の。DARフォームでは、将来の保守性や影響分析に暗黙的に含まれていないその他の要素など、いくつかの評価要素を追加する必要があります。次に、各因子に重みを付け、各因子のすべての解スコアを与えます。最後に、score * weightを掛けて合計し、最適なものを選択します。コストが要因に含まれている場合や、PMが別の意見を持っている場合があることに注意してください。

どんなドキュメントでも、アジャイルアプローチは良いものだと思います。現在、アジャイルは「文書化も分析もまったくない」という意味で誤解されていますが、そうではありません。私がアジャイルについて読んだことは、「機能するものを使う」と言っています。私は、ドキュメントがタスクに見合った長さと詳細であるべきだと考えています。

テンプレートはチェックリストとして役立ちますが、小さな変更やリスクの低い変更については、すべてのセクションに記入する必要はありません。1行の変更の場合、おそらくドキュメントは必要ありません。私は影響分析ドキュメントのテンプレートを使用したことがありませんが、ビジネス要件や技術仕様を定期的に扱っています。テンプレートは制限が多すぎる可能性があります。代わりに、適切なガイドラインは、聴衆が誰になるかを検討することです。技術的でないマネージャー向けの場合は、変更のビジネス上の正当化に焦点を当てます。技術者向けの場合は、チームの新しい人物が失われることがないように、背景を少し説明し、変更をサポートする必要がある場合に十分に対応できるようにします。また、さらに摩擦が少なく軽量なものが必要な場合は、ドキュメントをまったく使用せずに、wikiに配置してください。

含める情報：

• 問題の簡単な説明
• 欠陥がどのようにして失敗や非効率を引​​き起こしているのかを説明または例を示してください
• 複雑さの見積もりを含める
• 修正のコストと時間の見積もりを含める

それはまともな最小値です。もう1つの投稿では、IBMからのかなり重いCMMiのものが強調されました。時間とリソースがあれば（そして人間の生命が危機に瀕しているNASAのシステムを構築しているときは、人々はそれについて真剣に考えるべきです）素晴らしいですが、小規模なチームではそれほど重い必要はないでしょう。 。いつものように、見積もりに注意してください。マネージャーは見積もりが実際のものであると想定する傾向があります。

アジャイルアプローチには危険があることに注意してください。一部の開発者は、「ドキュメントは不要で、ハッキングを開始するだけ」という意味だと考えています（状況によっては問題ないかもしれません）。また、他の人は、タスクを与えられて寛容で、本当に役に立たない本当にくだらないドキュメントを書くだけです（ほとんどの状況では必ずしも問題ありません）。問題の一部は、上手に書くにはいくらかの努力、スキル、そして時間がかかるということです。私たちのほとんどは、これらのうち少なくとも2つが不足しています;）

少なくとも計画を立てる資格を得るのに十分な考慮を払っていることを証明するので、私は常にドキュメンテーションに熱心に取り組んできました。しかし、私が老後になると、ドキュメントが多すぎると、それ自体がメンテナンスの煩わしさになる可能性があり、ドキュメントを更新し続けるのに十分なほど多くの人が気にかけないことを理解するようになりました。

影響分析ドキュメントは確かに、プログラマーが地理的に異なる場所で作業している大規模プロジェクトで特に必要です。

変更が本番環境で正常に機能している他のコンポーネントに影響を及ぼさないようにするため、影響分析ドキュメントはリードによって承認される必要があります。

要件を完全に理解し、再作業を回避するために変更するすべてのコンポーネントを特定するために、影響分析が必要です。

影響分析は、クライアントの利害関係者からの説明責任のためにも必要です。それ以外の場合、展開後に問題が発生すると、開発者はスケープゴートになります。

影響分析は推定のベースです。それがなければ、推定には根拠がありません。高すぎるか、低すぎる可能性があります。インパクト分析を使用すると、実際の労力が超過した場合でも、簡単に説明できます。

ここに、影響分析レポートの標準テンプレートがあります。業界の特定の分野に合わせてカスタマイズされていますが、独自のドキュメントを作成するためのインスピレーションとして役立つ有用なセクションがあります。

リンク：http : //www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

乾杯