良いソフトウェア開発計画とは何ですか？

Question

私は、私の見解では、より頻繁に起こるソフトウェア開発管理誤解の1つである何かを見つけました。「[ソフトウェア開発]計画は、あなたが引き受ける必要があるすべての活動の合理的な詳細な記述です。

したがって、質問：良いソフトウェア開発計画は何ですか？それは仕事のブレークダウンの構造にちょうど煮沸することができますか？とにかくWBSはソフトウェア開発計画にとって最も重要なことですか？

Answer 1

ソフトウェア開発計画は、開発および提供する際にどのようにソフトウェアを開発するかについての計画です。

私はあなたが若いwhippersnappersすべてが軍隊はバカの束だと思いますが、彼らは実際にこの分野で多くの経験を持っています、彼らは商業会社の多くとは違って、完了しました。それには、考慮しなければならないものには非常に苦痛な教訓の束が含まれていました。

私はこれを2010年4月10日に更新しています。上記のDOD-STD-2167Aソースは暗くなっていますので、代わりにMIL-STD-498を指示するのが理にかなっています。残念なことに、MIL-STD-498は1998年に取り消され、国防総省は請負業者がIEEE/EIA-12207を代わりに使用することを期待しています。しかし、IEEE規格は、ビールのように自由ではありません。

ソフトウェア開発計画の概要については、DI-IPSC-81427Aを参照してください。

対処が必要な事項のリストを読んでいると、それらの段落の一部が、海軍の規制のように、血で書かれているような印象を受ける可能性があります。その印象には理由があります。プロジェクトは、時間内にそれらの分野に対処しなかったために失敗しました。

も参照してください。http://sepo.spawar.navy.mil/SW_Standards.html：標準とすべてのデータアイテムの説明（個々のドキュメントの仕様）を持つ.zipをダウンロードできます。

（はい、私はDoDがDOD-STD-2167AからIEEE商業標準に賛成であることを認識していますが、IEEEは左腎臓の腕、脚、その基準。DOD基準は、ビールのように自由である）

編集： 固定第一リンク

Answer 2

Artifact: Software Development Plan

ソフトウェア開発計画は が に必要なすべての情報を収集することを 包括的、複合アーティファクトは、プロジェクトを管理しています。それは の間に開発された 個のアーティファクトを囲み、プロジェクト全体を通して に維持されます。

ソフトウェア開発計画は

1. Problem Resolution Plan
2. Product Acceptance Plan
3. Measurement Plan
4. Risk Management Plan
5. Quality Assurance Plan

が含まれています

Guidelines: Software Development Plan

Answer 3

Aソフトウェア開発計画は、プロジェクト計画の具体的なタイプです。 WBSは重要ですが、表面を傷つけるだけです。

包括的なプロジェクト計画を持っている必要があります。

1. スコープ計画を
2. スケジュール計画
3. コスト計画
4. 品質計画
5. 人材派遣計画
6. コミュニケーション計画
（WBSが含まれています）
7. リスクプラン
8. 調達計画。これらの計画のそれぞれの

詳しい情報はCode Complete 2を参照してください、より具体的な義務づける方針については

The project Management Body of Knowledge.

で見つけることができます。

Answer 4

"[ソフトウェア開発]計画は、あなたが引き受ける必要があるすべての活動の合理的な詳細な説明です"。

一般に存在することはできません。

あなたが実際に理解し、すべての要件完全を持っている、とあなたは完全にが理解すべての技術上の問題がある場合は、そのような文書を書くことができます。

新しい - ユーザーがまだインストールしていないもの、または新しい技術を使用している場合は、「合理的に」詳細な説明を入力することはできませんあなたは引き受ける必要があります。

あなたは何をすべきかを要約した概要を提供することができます。しかし、要件を調べると、ユーザーは物事を発見し、学習し、心を変えます。計画を改訂する。技術を掘り下げていくうちに、開発者は物事を発見し、計画を学習し、改訂します。

これほど難しいことではありません。

プランの視聴者は管理者です。管理者は、すべての活動の「合理的」な詳細な記述が必要です。ユーザーと開発者が要件とテクノロジについて知ると、詳細が変化します。これは "合理的な"テストを非常に難しくします。詳細が絶えず変化するとき、どの程度詳細が「合理的」ですか？

プランの変更は、毎日行うことができます。ほとんどの管理職は、計画を毎日変更したくないでしょう。あまりにも細部が「不合理」になります。頻繁に変更されない計画を作成するには、計画は実際にはアクティビティの要約である必要があります。「ソフトウェア開発計画」の実行可能な唯一のバージョンは、ユーザーにリリースされる機能面で、活動の観点ではなく定義された一連の目標です。

つまり、人々はそれをひどくとしています。 30年以上のソフトウェア開発（軍事請負業者としての大部分）には、単に事実によって生まれたものではない計画についての幻想があります。プロジェクトは「合理的に詳細な」計画、過度に詳細な計画、計画なしでは取り消されます。

実際、計画はしばしばキャンセルの主な原因です。どうして？ 「合理的に詳細な」活動リストでは、学習は計画が間違っていることを意味します。計画は実際の実行とは異なるので、何かが間違っていなければなりません。コインを投げる。実行が間違っていると思われる場合は、プランに従わないプロジェクトをキャンセルします。計画が間違っていると判断した場合は、現実の世界に合うように計画を修正してください。計画が詳細になればなるほど、それは「正しい」ように見え、実行が不完全であると考える可能性が高くなります。

ボトムライン。

ソフトウェア開発計画は、すべての種類のものが前面に指定されていて、チームの進捗状況に応じて変更されたものが処罰される「ウォーターフォール」開発メソドロジの一部として書かれたファンタジードキュメントです。

OR

Aソフトウェア開発計画は、単純に完成するスプリントを示しAgile burndown chartです。 「妥当な」レベルの詳細は、実際には非常に低いです。これは単なる要約です。そしてそれは各スプリント回顧の間に変わります。私は、ソフトウェアの開発効率向上プロジェクトでは二つの部分のプロジェクト管理で

1. ソフトウェア管理
2. ソフトウェア開発効率向上

会社の目標、プロジェクトなどのすべての余分な可能性のものに分けすべきであると感じるもの

Answer 5

計画、プロジェクトの監視、見積もり、タイムシートの予約、欠陥の追跡などをカバーすることができます。

In Project Deveプロジェクトのライフサイクルは完全な滝のように維持されます