同社のソフトウェア研究開発部門の作業管理を強化し、開発サイクルを短縮し、ソフトウェア開発の品質を向上させ、開発コストを削減し、開発効率を向上させるために、ソフトウェア研究開発部門の管理システムが特別に策定されています。
第1章、一般
日常業務を正常かつ秩序正しく実行し、開発のすべてのリンクをよりコンパクトで制御しやすくするために、ソフトウェアのR＆D部門のプロジェクト管理をできる限り形式化し、ソフトウェアの品質と開発効率を向上させるために作業プロセスを合理化する必要があります。品質と数量に応じてプロジェクトをスケジュールどおりに配信できるという目標。
1.ソフトウェア開発は一般に、プロジェクト管理とソフトウェアエンジニアリングの基本原則に従います。
2.プロジェクト管理には、プロジェクトの確立、プロジェクトの計画と監視、および構成管理が含まれます。
3.ソフトウェアエンジニアリングには、要件分析、システム設計、ソフトウェア実装、システムテスト、ユーザーテスト、試運転、システム承認、システムオンラインとデータ移行、および製品メンテナンスが含まれます。
第II章、ステージ結果
ソフトウェア工学のプロセス理論と企業の現状を踏まえ、以下のワークフローを策定し、重要なリンクごとに提出する成果物を特定します。
1.プロジェクト設立：市場需要分析（または契約）、プロジェクト設立申請書、およびプロジェクトリスク分析リスト。
2.要件分析：ソフトウェア要件レポートまたは設計計画、要件仕様。
3.全体的な設計：要約設計仕様または機能モジュールの説明。
4.詳細設計：ソフトウェアインターフェイスの説明と単体テスト計画を含む詳細な設計仕様。
5.ソフトウェアの実装：ソフトウェア機能の説明、ソースコード、ソースコードの説明またはメモ
6.製品テスト：テストレポート
7.製品リリース：製品マニュアル、ユーザーマニュアル
8.製品のメンテナンス：問題のフィードバックレコード
9.プロジェクトの概要：クライアントのプロジェクトの概要と会社のプロジェクトレポートのPPTを送信します。
ソフトウェアプロセス結果表：
| ステージ |
文書を作成する |
責任と文書の説明 |
担当者 |
備考 |
| 需要段階 |
プロジェクト開始レポート（Word） |
双方の責任と義務を明確にする |
プロジェクトマネージャー |
ほとんどのビジネスモデリングと要件、分析と設計の一部 |
| ビジネス要件仕様（Word） |
要件の定義、ビジネススコープとコンテンツの詳細、開発チームは最適な技術設計計画の策定を担当します |
プロジェクトマネージャー/需要分析エンジニア |
||
| プロジェクト開発計画（プロジェクト） |
すべてのプロジェクト関係者がプロジェクトの進捗状況をタイムリーに理解できるように、プロジェクト開発計画を策定する |
プロジェクトマネージャー |
||
| プロジェクトリスク分析チェックリスト（xls） |
プロジェクトで発生するリスクを分析し、対応する対策を策定する |
すべての利害関係者 |
||
| 設計段階 |
ビジネスプロセス全体の設計図書、詳細設計仕様書（Word / Visio） |
プロジェクトの技術アーキテクチャと起こり得る技術的な問題について話し合い、ビジネスプロセスを整理し、開発ルールとスタイルを統一するなど。 |
プロジェクトマネージャー/アーキテクト |
プログラミングとテストの実装の一部である分析と設計のほとんどは、導入を検討し始めました |
| データベース関係設計図、フローチャート（PowerDesigner） |
プロジェクトに必要なデータベースの構造図とフローチャート |
アーキテクト/シニアソフトウェアエンジニア |
||
| タスク割り当て文書（Word） |
各チームメンバーの開発タスクと責任を明確にする |
プロジェクトマネージャー |
||
| 問題の説明レポート（Word） |
ユーザー、リーダー、チームメンバーが問題をタイムリーに理解して発見できるようにする |
プロジェクトマネージャー |
||
| ビジネス変更文書（Word） |
開発プロセス中にユーザーが提起したビジネス要件の変化を記録する |
需要分析エンジニア |
||
| 実装フェーズ |
ソフトウェア機能説明（Word） |
ソフトウェア開発プロセスで実装されたすべてのソフトウェア機能を記録する |
ソフトウェア開発エンジニア |
最終的なソフトウェア開発製品と説明 |
| ソースコード |
デプロイ可能な実績、および実績を生成するソースコードとデータベースバックアップファイル |
ソフトウェア開発エンジニア |
||
| ソースコードの説明（Word） |
提出されたソースコードの各モジュールを説明してください |
ソフトウェア開発エンジニア |
||
| テストフェーズ |
プロジェクトテスト計画とレポート（Word） |
プロジェクトテストの方法を記録し、システムの機能とパフォーマンスの記録を確認する |
テストエンジニア |
システムが安定するまでテストを繰り返します |
| ユーザーマニュアル（Word） |
ユーザーがソフトウェアを使用するための手順 |
テストエンジニア |
||
| オンラインにして実行する |
システム使用レポート |
システム導入後の運用実績 |
プロジェクトマネージャー |
展開とメンテナンス |
| ユーザートレーニングレポート |
ユーザートレーニングドキュメント |
プロジェクトマネージャー |
||
| プロジェクト承認レポート（Word） |
両当事者が署名した承認レポートを記録する |
プロジェクトマネージャー |
||
| プロジェクト概要レポート |
プロジェクトチームは、このプロジェクトの経験と不備を要約します。 |
プロジェクトマネージャー |
第III章、ジョブの設定
同社の現在の開発プロセスによると、それは主に3つの段階に分けられます：分析、開発、およびテスト。分析段階では、ユーザー要件文書の作成とシステムの全体的な設計を完了し、開発段階では、設計文書の作成、コードの作成、およびコードの保守を完了します。テスト段階でシステムテスト、テストドキュメント、およびその他の資料を完成させます。プロジェクトマネージャー、需要分析エンジニア、上級ソフトウェア開発エンジニア、ソフトウェア開発エンジニア、およびテストエンジニアのポスト設定を徐々に調整し、職務を明確にし、ポスト設定を徐々に実現します。
| 投稿する |
仕事内容 |
責任 |
| プロジェクトマネージャー |
1.プロジェクトチームのメンバーを選択し、プロジェクトチームを設定し、タスクを調整します。 2.顧客とのコミュニケーションと調整（ビジネス要件または非ビジネス要件の観点から）、および調査の要求。 3.これらの段階の要件、設計、コーディング、およびテストを含むプロジェクト開発計画を策定します。 4.プロジェクト開発コストの見積もり。 5.チーム開発スケジュールを作成し、チームメンバーの作業の進捗状況を監視します。 6.ドキュメントの品質を確認します。 7.グループのメンバーの作業をガイドします。 8.定期的なプロジェクト会議を開催して、プロジェクトのリスクと進捗状況を管理します。 |
1.顧客とのコミュニケーションと調整を担当します。 2.ソフトウェア開発の効率、品質、およびコストを担当します。 3.システム全体の設計と詳細な設計ドキュメントの品質に責任を持ちます。 4.プロジェクト全体の進捗、品質、コスト、リスクに責任を持つ。 |
| 分析が必要 エンジニア |
1.顧客と連絡を取り、需要調査の責任を負い、需要分析文書を要約し、システム全体の設計計画を作成します。 2.需要の変化に対応する場合は、需要の変化の内容を分析し、プロジェクトマネージャーと共に需要の変化を評価する責任があります。 3.上級ソフトウェア開発エンジニアと詳細な設計ドキュメントをまとめます。
|
1.ユーザーニーズ分析の質に責任を持ちます。 2.プロジェクトチームのすべてのメンバーがプロジェクトの要件を正しく理解する責任があります。 |
| 高度なソフトウェア 開発エンジニア |
1.システムモジュールの設計、詳細な設計ドキュメントを担当します。 2.インターフェースのプロトタイプデモなどを描き、設計関数、アクター、前提条件、事後条件、UIの説明、ビジネスプロセス/サブプロセス/ブランチプロセス、インターフェースの説明などの使用の具体的な説明を記述し、ほとんどのフロントエンド設計を完了します。バックエンドデザインの一部。 3.技術的に難しいモジュールのコードまたは共通モジュールコードの準備と保守を担当します。 4.モジュールの詳細な設計とコーディングを担当します。 5.チームメンバーに技術的なガイダンスを提供します。 |
1.グループの人々の開発効率に責任があります。 2.製品の全体的なスタイルを担当します。 3.プロジェクトの全体的な設計プロセスを担当します。 4.独自のモジュールの開発効率と品質に責任があります。 |
| ソフトウェア開発エンジニア |
1.プロジェクトマネージャーと連絡を取り、特定のモジュールのニーズと実装方法を確認します。 2.特定のモジュールのコードの作成と保守を担当します。 3.他のモジュールのコードを保守します。 4.テスターとのやり取りとテスターの問題の処理を担当します。 |
1.独自のモジュールの開発効率と品質に責任を持ちます。 |
| テストエンジニア |
1.ユーザーのニーズ分析と全体的なシステム設計に従って、テストドキュメントとテストケースを記述します。 2.システムの機能、性能、異常をテストします。 3.テスト文書と操作説明書を作成します。 |
1.テストの品質に責任があります。 2.テスト文書と操作マニュアルの品質に責任があります。 |
第IV章、プロジェクトの確立
1.需要分析エンジニアがアプリケーションの調査と分析を行い、ソフトウェアのアプリケーション要件を確認します。
2.プロジェクトレビューミーティングを確立するには、開発ディレクター、部門マネージャー、および指定された担当者が参加する必要があります。プロジェクトの実行可能な×××を実施し、プロジェクト提案を準備し、プロジェクトの難易度と作業負荷を評価し、実行可能な×××レポートを作成します。
3.プロジェクト構成の長所と短所に従ってプロジェクト開発チームを設定し、ソフトウェア開発計画を策定し、プロジェクトマネージャーを決定します。また、部門とプロジェクトマネージャーが共同で、特定のプロジェクト構成、知識とスキルの要件、チームメンバーとチームの役割を決定します。
第V章、プロジェクトの計画と監視
1、以项目为单位，项目经理负责整个项目的计划、组织和控制。
2、在整个项目过程中，项目经理定期检查项目进度和完成情况，调整人员分工和安排。
3、项目计划需要变更时，需要明确变更内容并及时汇报。项目经理需要说明客户变更原因并将变更说明提交公司领导审核，以便根据变更内容及时调整计划。。
第六章、需求分析
1、对用户提出的需求进行分析汇总，梳理用户的业务流程和详细的功能定义。
2、做出简单的界面原型，与客户进行有效的沟通， 编写需求详细说明书。
3、根据现有条件进行估计，制定项目进度，制定详细的软件开发计划。
第七章、总体设计
1、在该阶段确定总体结构和软件开发架构，文件命名规范，编码规范。可按软件需求划分成子系统，也可直接定义目标系统的功能模块及各个功能模块的关系。
3、确定软件模块结构，给出每个功能模块的功能描述、数据接口描述，并完成系统概要设计说明书。
4、完成数据库的设计，并编写数据库设计说明书。
5、完成的文档需提交公司进行归档管理。
第八章、详细设计
1、调整前一步设计的不足，确认各模块之间的详细接口信息。
2、设计功能使用的具体描述、行为者、前置条件、后置条件、UI描述、业务流程/子流程/分支流程，界面说明等。
3、确定模块内的数据流或控制流，对每个程序模块必须确定所有输入、输出和处理功能。
4、汇总并提交所有相关文档，审核确认质量和进度。
第九章、软件实现
1、项目组根据概要设计说明书、详细设计说明书制定系统实现计划
2、有条件的情况下保证开发、测试和生产环境独立。选择软件工具，明确项目成员的职责分工，按照编码规范和详细设计实现软件功能。
3、代码应满足结构良好，清晰易读，且与设计一致，符合编码规范。
4、开发人员需要软件实现过程中编写软件功能说明，源代码说明。软件功能说明文档应说明项目名称、编号、软件名称和版本号，软件功能、主要功能实现过程。源代码说明应说明项目编号、源代码类名称、编写人员、编写日期、变更履历、功能、全局变量、数据库字典、函数功能、接口。该文档包含在源代码文件中，以注释形式存在。
5、项目组进行单元测试和集成测试。开发人员处理测试人员反馈的测试问题，并以书面形式反馈主要问题及解决办法，直至系统运行稳定。
6、汇总并提交所有相关文档，提交公司备案，形成项目知识库。
第十章、软件测试
1、根据单据测试和集成测试两个过程，制定测试计划。按阶段设计测试实例，并将测试结果记录，未通过的的反馈给开发人员调整。
2、完成测试文档、操作手册、安装维护手册的编写。
第十一章、用户培训
1、准备用户培训计划、培训手册
2、确定培训时间、培训地点，向用户进行系统使用培训、操作指导及提供软件操作手册。
3、保留培训签到表，用户意见等存档。
第十二章、系统上线
1、 制定上线计划，确定上线工作时间表，部署的环境。
2、上线操作步骤以及问题处理步骤；
3、根据软件特点、客户需求进行软件部署，并记录软件部署和运行结果；
4、项目组根据系统运行请款对系统进行优化，记录系统的运行情况、系统问题和处理后的版本。
第十三章、系统验收
1、验收工作准备，按要求整理项目成果物，打印装订成册，并提交客户方。
2、系统主要使用部门及信息技术部门联合成立项目验收小组，从需求功能及技术需求层面对系统进行综合评估和项目成果物的审核，根据验收情况形成系统验收报告
3、应用部门及信息技术部门负责人根据系统试运行情况签署验收意见。
第十四章、产品维护
1、调出项目主要开发人员，按照合同要求安排维护人员对系统进行技术支持。
2、系统需求变更或调整，记录变更原因和软件及源代码的版本控制，按照软件变更要求对系统进行维护。
第章十五、源码和文档
1、源代码/文档管理采用版本控制软件VisualSourceSafe。
2、按项目的阶段性完成源代码、文档的上传。项目负责人每天对代码进行检查，开发总监或部门经理定期进行抽查。
3、文档分为项目文档和个人文档，文档上传前进行归类和汇总。
第十六章、质量检查
1、项目负责人每天要检查成员的工作完成情况，特别是新员工的工作进展；
2、工作抽查制度：不定期的进行抽检，并将检查对象、检查时间、检查内容、检查结果反馈给被抽检人。
3、内部审核制度：针对业务需求、概要设计(功能界面、数据库)或疑难问题组织评审会，提出意见或解决方案。
第十七章、文档规范
1、需按照软件实施的阶段落实成果物，参照《软件过程提交成果表》。
2、如果客户有特殊要求，请按照客户要求的规范完成。并将最终的问题提交公司归档备份。
第十八章、软件变更
为规范软件变更与维护管理，特制定本制度。本制度适用于应用系统开发完毕并正式上线，移交给客户方之后的运行支持及系统变更工作。
1、系统变更工作可分为功能完善维护、系统缺陷修改、统计报表生成。
2、需求部门提出系统变更需求，项目经理同开发人员一起根据重要性和紧迫性做判断，确定其优先级和影响程度，并进行相应处理，同时将变更需求整理成系统变更申请表。
3、系统变更实现过程按照软件开发过程规定进行，遵循软件开发过程统一的编码标准和版本控制，并经过测试通过才能完成部署和上线。
4、在系统变更完成后，开发人员需将系统变更表的执行结果提交给项目经理，测试人员确认执行结果后，项目经理与需求提出方确认签字后，提交至公司进行归档管理。