ディレクトリ
-
スコープ
-
一般要件
2.1一般的な機能要件
2.2ソフトウェア開発プラットフォームの要件
開発とプロセス管理ソフトウェアプロジェクトの実装では、2.3が必要です
プロジェクトの一般的な要件の2.3.1ソフトウェア実装
2.3.2ソフトウェアプロジェクトの要件の変更
2.3.3ソフトウェアプロジェクト実施のマイルストーン制御
- ソフトウェア開発
3.1ソフトウェア要件の分析
3.1.1要求分析
作成者は、分析レポートを必要と3.1.2
3.1.3ニーズ調査報告書
3.1.4オンデマンドレポート形式
設計ソフトウェアの3.2まとめ
デザインの3.2.1概要
3.2.2の設計要件の書かれた要約
3.2.3作家アウトラインデザインレポート
3.2.4設計・要件分析、関係の概要と詳細設計との違い
デザインレビューの3.2.5概要
デザインフォーマットの3.2.6概要
詳細設計3.3ソフトウェア
3.3.1詳細設計
3.3.2 特例
3.3.3詳細な設計要件
3.3.4データベース設計
3.3.5詳細設計レビュー
3.3.6詳細設計・フォーマット
3.4エンコードソフトウェア
コーディング3.4.1ソフトウェア
3.4.2ソフトウェアのコーディング要件
3.4.3エンコードされたレビュー
3.4.4プログラミング仕様と要件
3.5ソフトウェアテスト
3.5.1ソフトウェアテスト
3.5.2テスト計画
3.6ソフトウェアが提供する準備ができています
3.6.1配信リスト
同定と受け入れ3.7ソフトウェア
同定と受け入れ3.7.1ソフトウェア
3.7.2検査要員
3.7.3受け入れ詳細
3.7.4ソフトウェアの受け入れテストの概要
3.8トレーニング
3.8.1システムアプリケーショントレーニング
トレーニング管理システム3.8.2（オプション）
付録Aは、分析文書テンプレートのソフトウェアを必要とします
付録Bソフトウェアの設計レポート要約文書テンプレート
付録Cは、詳細設計ドキュメントテンプレートのソフトウェアを報告します
付録Dドキュメントテンプレートソフトウェアデータベース設計レポート
付録Eソフトウェアテスト（受け入れ）概要5
- スコープ
ソフトウェアの品質を向上させるために、ソフトウェア開発のユニットの特定処理によって行わ交通プロジェクト、メンテナンスコストを削減する目的の南京部門のプロセスのためのソフトウェアを開発するソフトウェア開発者に、このガイドを使用してください。開発者は、これらのガイドラインに従い、ソフトウェア開発とソフトウェア開発ドキュメントのために準備されるべきです。このガイドでは、ソフトウェアプロジェクトの単位のための基本的な要件を仮定することです。このガイドは、参照する開発者向けのドキュメントテンプレートの作成にEの付録Aで提供され、開発中に、開発者の回復可能で、特定のソフトウェアの実際の状況に応じて調製したが、当事者間で合意された文書を提供しなければならない、文書の内容が合意しなければなりません明確に説明。
2.一般要求事項
2.1一般機能要件
コアとして、インターネット/イントラネット技術のためのネットワークのアプリケーション環境。
開発者はニーズの完全な分析、B / SのOPTまたはC / S構造に基づくべきです。
データベース・ソフトウェア・システムを設計し、に従って構築されなければならない「南京運輸省の情報データベース構築の規範。」
このガイドでは、どのような具体的な方法指定された現像剤を用いたエンジニアリング・ソフトウェアの開発を、プロジェクトの特定の特性に応じて、開発者は、プロセス指向、オブジェクト指向方法やデータ指向のアプローチの方法を使用してで自分の利益を選択することではない、開発者が使用することをお勧めします現在広く使用されRUP（ラショナル統一プロセス）の分析、設計・開発のための方法の使用次のようなオブジェクト指向ソフトウェア工学、。
2.2ソフトウェア開発プラットフォームの要件
ソフトウェアを開発する開発者は、交通・ソフトウェア・プラットフォームの南京部門の規定に適切に実行できなければなりません。現在、ソフトウェアプラットフォーム：
データベース管理システム：
オラクル9iまたはそれ以降の
ミドルウェア（アプリケーションサーバ）システム：
IBMのWebSphere
OAシステム：
ロータスノーツ/ドミノ
ネットワークアーキテクチャ：
完全にTCP / IPプロトコルをサポートしています
開発ツールや技術システム：
上下のソフトウェアの互換性の発展を確保するために、開発者は、MicrosoftのVisual Studio.Net、Borland Delphiの、Cのような、より一般的な開発ツールの新しいバージョンを選択する必要があり ++ Builderでは、 またはJ2EE（Java2のP1atform Enterprise Editionを）というように。
2.3開発およびプロセス管理ソフトウェアプロジェクトの要件の実装
2.3.1ソフトウェアプロジェクトの実施プロセス、一般的な要件
（一）开发者提交软件开发工作大纲，交通局组织专家组对工作大纲进行评审，并提出整改意见。
（二）通过评审后，开发者根据整改意见完善工作大纲，经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，开发者需分阶段提交相关文档。
（三）在软件开发工作完成后，开发者应向交通局提交完整的软件文档，交通局组织验收组对软件进行验收审查。
2.3.2ソフトウェアプロジェクトの要件の変更
開発プロセスでは、要件や設計変更が必然的に発生する必要がある、これらの変更は、交通局を通じて進む前に書面で同意しなければなりません。要件や設計変更は、必要性が、元の文書を変更して、完全な変更履歴を提供するときにその状態の制御の変化。次の表の順番を変更します：
2.3.3ソフトウェアプロジェクト実施のマイルストーン制御
運輸省は4つの段階に分けることになる専門家検討会を招集し、確認してください。
（一） 需求分析（结合原型进行审查）确认；
（二） 概要设计+数据库设计；
（三） 预验收（试运行后）；
（四） 正式验收（推广使用后）。
- ソフトウェア開発
契約書に署名した後、プロジェクトの事業ユニットは、ソフトウェア開発作業のためのプロジェクトチームを編成します。ソフトウェア開発はソフトウェアエンジニアリングの要件に厳密に従ったものでなければなりません。開発プロセスでは、アクティビティとタスクの開発者が含まれています。このプロセスは、構成するソフトウェア要件、概要設計、詳細設計、コーディング、テスト、検査、評価と他の活動によって分析されます。
3.1ソフトウェア要件分析
3.1.1要求分析
まず、開発者は、運輸および完全な調査のための交通アプリケーションの学科のために一緒に働くの完全なニーズ分析を提出しなければなりません。基本的な問題は、ニーズ分析報告書に記述されている必要があります：機能、パフォーマンス、実装、属性、外部インターフェイスに課せられた設計制約。あなたは、設計やプロジェクト要件のニーズ分析を書いて避ける必要があります。それはない手段は、これらの結果を得るために、ソフトウェアによって得られた結果を記述しなければなりません。
ソフトウェア要件は、入力と出力の指示によるような、いくつかの方法で表現することができ、使用の代表的な例として、標準化されたモデルと。それは複雑なニーズを表現するために、正確かつ効果的な方法であるため、開発者は、可能な限りの方法のモデルを使用する必要があります。例えば、要件を記述するために、統一モデリング言語（UML）を使用しました。
これは、分析レポートのニーズを必要とし
A。あいまいありません
用語によって記述される最終製品の特性の各々について、特定の用語は、適切な使用アウト説明する各用語の意味と点に対処次いで、特定の表現で使用される場合、複数の意味を持ちます。
B。整合性
入力データのすべての可能な応答のために定義されるように、かつ合法的であることが、分析は、それが機能、性能、設計上の制約や外部インタフェース局面に関連する要件に関連しているかどうか、すべての意味のある要件を含むべきである必要が合法的には、所定の入力値に応答して行わ;フィル全ての図、表、及び他の数字を示し、すべての用語及び測定単位の定義。
C。検証可能性
各レポートには、ニーズ分析のニーズは検証する必要がありますについて説明します。あなたは、製品が限定されたプロセスを通じて需要を満たしているソフトウェアを確認することができます。
D。一貫性
ニーズ分析レポートの各要件の説明は互いに矛盾することはできません。
電子。修正可能
ニーズ分析は、使いやすい整然とした、コンテンツの組織を持っている必要があります。ある冗長性は、ない同じ需要は、より多くのニーズ分析レポートで何度も表示されません。
F。トレーサビリティ
各要件の起源は明確でなければならない、さらにドキュメントが生成され、変更されたとき、あなたは簡単にすべての必要性を挙げることができます。
グラム。ユーザビリティの運用・保守フェーズ
ニーズ分析レポートは、運用・保守フェーズのニーズを満たす必要があります。ニーズ分析では、送信元と宛先の機能を指定する必要があります。
作成者は、分析レポートを必要と3.1.2
ニーズの分析レポートは共同で完成交通と開発者の部門でなければなりません。どこに：;運輸省の性能要件に基づいて、ソフトウェア開発者に書かれたソフトウェアの開発ニーズ分析の組み合わせを提案した運輸省は、実際のニーズに責任があるソフトウェア機能はという希望を表明しました。
3.1.3ニーズ調査報告書
ソフトウェア要件の分析が完了した後、ソフトウェア開発者は、運輸省に提出しなければならない「ソフトウェア要件分析レポート。」ソフトウェアは改善し、適切なを必要とするかどうかを判断するために見直しの必要性についての輸送人員団体の教室。レビューが完了したら、ソフトウェアの設計段階に入ることができます。
3.1.4オンデマンドレポート形式
「ソフトウェア要件分析レポート」根拠は付録の特定に示すテンプレートを書くために、書き込みに特定のフォーマットを有する文書A「ソフトウェアは、分析が必要です」
ソフトウェア設計の3.2概要
3.2.1デザインサマリ
作業ステップ-運輸省と両当事者が合意された開発者には、開発者の下、基礎「分析を必要とします」。まず、開発者はソフトウェアシステム、そのシステム設計の予備設計を実施する必要があります。基本的なプロセスフローは、システムの組織構造、モジュール分割、機能割り当て、インターフェース設計、操作デザイン、デザインを扱うデータ構造設計およびエラーを含むシステムにおいて考慮設計ソフトウェアシステムの概要設計のニーズを、詳細設計ソフトウェアを提供基盤。
3.2.2の設計要件の書かれた要約
A。一貫性
設計要件の概要は、報告書に記述ニーズと要件分析と一致する必要があります。同時に、それはアウトライン設計の要件との整合性でなければなりません。
B。合理性
提案した設計法と設計基準の概要は、合理的かつ適切でなければなりません。
C。トレーサビリティ
提案された設計の要件の概要は、すなわち、顧客が分析レポートは、明確な要求仕様を持っている必要があり、それをクリア起源を得ることができる必要があります。
D。フィージビリティ
詳細設計、運用、保守には、アウトラインの設計に応じて実行可能でなければなりません。
3.2.3作家アウトラインデザインレポート
概要設計報告書は、要求分析のニーズに合わせて開発することにより調製しました。
3.2.4設計・要件分析、関係の概要と詳細設計との違い
ニーズ分析は、マクロの枠組みの外にまで来て上の特定の技術的な実装、およびアウトライン設計の焦点を伴い、技術がこれらの要件を達成するための方法を採用するかを説明しません。詳細設計は、マイクロの枠組みの中で設計概要設計に比較的より重視とに従って符号化されます。設計の概要は、指導の詳細設計に基づいています。
デザインレビューの3.2.5概要
ソフトウェアのアウトライン設計作業が完了すると、ソフトウェア開発者は、「ソフトウェアのシステム設計レポートの概要を。」トラフィックを提出してください 「デザインサマリレポート」レビューに関する運輸省後には、詳細設計の段階に入ることができる、で。
デザインフォーマットの3.2.6概要
「ソフトウェアシステム概要設計報告書」の書き込みに特定のフォーマットを有する基礎、特定の「ソフトウェア・システムの設計概要レポート」の文書テンプレートをオーサリング、付録Bを参照してください。
詳細設計3.3ソフトウェア
3.3.1詳細設計
アウトライン設計に基づき、ソフトウェア開発者の詳細な設計は、体系的にする必要があります。詳細設計では、特定のアルゴリズムは、関与するメインモジュール、データ構造を達成する記載、及び、各プログラムのすべてのレベルでのソフトウェア・システムの説明（各モジュールまたはサブルーチン）設計上の考慮事項階層関係クラスを呼び出しますコーディングとテストのために。これは、ソフトウェアのニーズは完全にソフトウェアに割り当てられていることを確認する必要があります。詳細設計十分な詳細は、詳細な設計レポートに従って符号化することができます。
3.3.2特殊なケース
ソフトウェアシステムは比較的単純である場合は、低レベル、特別に一緒に設計、およびアウトラインの設計を詳細に説明する必要はありません。
3.3.3詳細な設計要件
A。一貫性
設計要件を詳細かつ外形デザインと一致し、報告書に記述されるように、分析ニーズを必要とします。同時に、詳細設計の要件の間で一致している必要があります。
B。合理性
提案した設計方法や基準の詳細設計は、合理的かつ適切なはずです。
C。トレーサビリティ
提案された要件の詳細設計は、ニーズ分析、予備設計報告書に、それを明確に起源を得ることができる必要がありますについては、明確な需要の記載があります。
D。フィージビリティ
コード、テスト、運用、保守は、詳細設計に基づいて可能でなければなりません。
3.3.4データベース設計
データベース・ソフトウェア製品を使用する必要がある場合は、ソフトウェア詳細設計では、データベースの設計を含める必要があります。データベースの設計ソフトウェアは、アウトラインの設計が完了した後に、詳細な設計作業は、他の前に行って、分析を要求すべきです。データベースの設計時には「南京運輸省の情報データベース構築標準」の要件を開発するために運輸省に従うべきです。
3.3.5詳細設計レビュー
詳細設計ソフトウェアの完了後、ソフトウェア開発者は、運輸省に提出しなければならない「ソフトウェアシステムのデータベースデザインレポート」および「ソフトウェア・システムは、設計報告書を詳細に。」「ソフトウェアシステムのデータベースデザインレポート」に運輸省後、認定を通じて「ソフトウェアシステムが設計報告書を詳細に」、あなたは、ソフトウェアのコーディング段階に入ることができます。
3.3.6詳細設計・フォーマット
「ソフトウェアシステム詳細設計報告書」、「ソフトウェアシステムのデータベースデザインレポート」ベースの書き込みに特定のフォーマットを有する、特定の「ソフトウェア・システム詳細設計報告書」文書オーサリング・テンプレートおよび「ソフトウェアシステムのデータベースデザインレポート」文書のオーサリング・テンプレートは、付録Cを参照してください付録D.
コーディング3.4ソフトウェア
のコーディング3.4.1ソフトウェアを
ソフトウェアコーディング段階では、開発者は、要件「ソフトウェアシステム詳細設計レポート」データ構造、アルゴリズム、分析、設計及びモジュールは、ターゲット・システムを実現するために、各モジュールの機能を達成するために、それぞれ、特定のプログラミング作業の開始の他の態様を実施するために記載します機能、性能、インターフェイス、インターフェイスの要件の観点。
3.4.2ソフトウェアのコーディング要件
A。モジュラーコーディング
B。コードの可読性
C。保守性
D。モジュールのインタフェースの標準化
電子。統一されたインタフェースのスタイル
電子。アプリケーションノート
3.4.3エンコードされたレビュー
ソフトウェアの障壁にできるだけ早く発見し、ソフトウェア製品の品質を向上させるためには、符号化プロセスでの開発者がコードレビュー作業することを強調すべきです。コードレビューは、運輸省に提出した文書の一部として報告します。
3.4.4プログラミング仕様と要件
プログラミングの品質を向上させるために、ソフトウェア・プログラミング・プログラミングは州によって発行された、関連する規範を遵守しなければなりません。
主な内容は次のとおりです。コーディング標準を標準化した手順のデータの構造を詳述内部文書、明確な文の構造を、。コンテンツのエンコーディング仕様は、命名規則、インタフェース仕様、ヒントやヘルプ情報慣行、ホットキー定義が含まれています。
データベースのどの部分が「南京運輸省の情報データベース構築の規範」要件に準拠する必要があります。
ソフトウェア・コードの同じ時間手段で試験しなければなりません。
3.5ソフトウェアテスト
3.5.1ソフトウェアテスト
U2FsdGVkX1 + 49E9dnJN + zt3yVXb7pFchHTTbqX8ov5FLkgFtLnuAnPvsv3zr762e
A6kZnja8xORlrQESAVrH846PE4SDcMTOHdmYuI5kqb8ka5INi3WxUvFKjlDhq5wf
H4m8PVbNaI4GTwsa4pV0ZYXZmbKBjXIOUi1gLkMyTXnDvV6dar + aoRihZc2TDQ9u
1sEsp + 0°+ TTomdpzQE4iMN8KFdt75f5UxjL6acN2IKdbLvHkC3fnIAMbhaOkZOTD
Bp77mINHCnlrSJrILiKbD28BbW / ww6Hip0mPyA8ipsd8VreWMEwcqxDgofcQNHlT
uqEnDFzOW + oqRGUyZV9PFF1Sf8iveTWza4cmXLZlK9vl3flovuXZFaye8pBLjwOl
ソフトウェアの品質を向上させ、ソフトウェアメンテナンスのコストを削減するように、できるだけ早く、ソフトウェア製品のエラーを見つけるために、開発者は、ユニットは、符号化プロセスの各モジュールのプログラムコードをテストする必要があり、システム統合時の統合テストは、システム統合が完了します全体のソフトウェアシステムのテスト。ユニットテストは、ソフトウェア開発プロセスのためのプログラムモジュールの正しさをテストしています。統合テストユニットテストは、システムまたはサブシステム、およびモジュールインタフェースの正しさを検証するためのモジュール組立工程で組み立てられるすべてのモジュールの設計要件に基づいています。ソフトウェアのテストだけではなく、全体的な挙動検出ソフトウェアのパフォーマンスは、他の側から、ソフトウェア開発と設計の別の確認です。ソフトウェアシステムは、テストするとき。試験はインタフェース試験、ユーザビリティテスト、機能テスト、安定性（強度）試験、性能試験、ロバスト性（回復）試験、テストロジック、非破壊検査、セキュリティテストを含みます。
