自行开发软件操作规程.docx

自行开发软件操作规程.docx

《自行开发软件操作规程.docx》由会员分享，可在线阅读，更多相关《自行开发软件操作规程.docx（10页珍藏版）》请在冰点文库上搜索。

自行开发软件操作规程

自行开发软件操作规程

第一章总则

第一条为加强自行开发软件项目管理，实现软件工程标准化，提高软件开发质量，提升文档管理水平，特制定本操作规程。

第二章软件开发阶段

第二条可行性分析。

可行性分析就是分析项目的主要依据，确定系统的目标和规模，从技术、经济和社会因素等方面分析论证软件项目的可行性，用最小的代价在尽可能短的时间内确定问题是否能够解决，避免时间、资源、人力和资金等浪费，并最后生成可行性分析报告，作为是否继续进行软件开发工程的重要依据。

第三条需求分析。

项目立项后项目组与系统需求部门召开会议，组织相关人员共同探讨，明确、汇总整理开发需求，并将实际需求用书面形式表达出来，形成《业务需求说明书》，并确保《业务需求说明书》中包含了所有要求的业务需求，为评价软件质量提供依据。

经信息办批准确认，作为业务需求基线。

第四条系统设计。

项目组获得《业务需求说明书》后，提出技术需求和解决方案，并对系统进行定义，出具《系统需求规格说明书》。

《系统需求规格说明书》需详细列出业务对系统的要求（界面、输入、输出、管理功能、安全需求、运作模式、关键指标等）并交信息办负责人确认。

项目组应对需求变更影响到的文档及时更新。

第五条概要设计和详细设计。

（一）在软件设计阶段，要在《业务需求说明书》的基础上建立软件系统的“架构”，包括数据结构和模块结构，一般可以分为两步：

概要设计和详细设计，系统设计要求遵循完备性、一致性、可扩展性、可靠性、安全性、可维护性等原则。

在系统设计阶段，要求有软件需求部门的参与，确保软件设计能满足业务需求。

（二）项目组进行概要设计和详细设计，出具《概要设计说明书》合《详细设计说明书》。

《设计说明书》中需要定义系统输入输出说明和接口设计说明。

信息办对概要设计和详细设计进行评审，出具《设计评审报告》。

设计评审均以《业务需求说明书》和《系统需求规格说明书》为依据，确保系统设计满足全部业务需求。

第六条软件编码。

（一）系统实现包括程序编码、单元测试、集成测试。

制定代码编写规范，要求开发人员参照规范编写代码。

项目组根据《详细设计说明书》制定系统实现计划，并提交项目负责人对计划可行性进行审批。

（二）在自行开发信息系统时，要求开发环境与实际运行环境做到物理分开，建立完全独立的两个环境，开发及测试活动也要分开，开发人员与测试人员分离，测试数据和测试结果受到控制。

如果环境的分隔是通过逻辑形式实现的，应定期检查网络设置。

项目组对已授权访问项目环境的人员进行详细记录，并对该记录进行定期检查，确保只有经授权的人员才能访问到项目环境。

项目组进行单元测试和集成测试，测试人员签字确认测试结果。

第七条软件测试。

（一）软件测试是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终审核，发现和修正错误的过程，是软件质量保证的关键步骤。

（二）测试的目标是用最少的时间和人力找出软件中潜在的各种错误和缺陷，应当运用科学规范的测试方法，常用的有黑盒测试和白盒测试。

（三）测试过程一般按四个步骤进行，即单元测试、集成测试、确认测试和系统测试，通过所有四步测试之后的软件才能交付用户使用。

（四）项目组编著系统帮助文档（包括《操作手册》、《安装维护手册》）。

凡涉及系统的变更，应对系统帮助文档及时更新。

第八条试运行。

（一）由于软件系统经过测试后仍然可能隐含错误，实际需求和系统的运行环境也可能发生变化，因此在软件运行阶段仍需要对软件继续进行排错、修改和扩充。

（二）系统主要使用部门根据项目规模及影响决定试运行策略。

项目组制定《试运行计划》，并制定试运行验收指标，上报信息办审批。

《试运行计划》中包含问题应对机制，明确问题沟通渠道和职责分工。

（三）项目组联合试运行部门进行相关系统部署工作，准备培训资料，对相关用户和信息技术人员进行培训。

用户培训的完成度应为实施后评估的指标之一。

（四）项目组根据《试运行计划》进行系统转换和数据迁移。

系统转换前，检查系统环境，确保运行环境能满足新系统的需要。

系统转换时必须详细记录原系统中的重要参数、设置等系统信息，并填写试运行报告相关内容。

系统参数、设置的转换工作作为系统上线验收的评估指标之一。

（五）数据迁移前，应制定详细的《数据迁移计划》，《数据迁移计划》中应包含迁移方案、测试方案、数据定义、新旧数据对照表、迁移时间、回退计划等信息。

数据迁移计划需经项目负责人、系统使用部门、信息办领导签字审批。

（六）数据迁移后，项目组对数据迁移的完整性和准确性做出检查，出具《数据迁移报告》，其中包括数据来源、转换前状态、转换后状态，数据迁移负责人、对完整性检查情况、对准确性检查情况等内容。

（七）各相关部门验收转换结果后在该报告上签字确认。

系统转换和数据迁移由试运行部门和信息办共同监督并进行验收。

（八）系统转换和数据迁移验收通过后，正式启动试运行。

在试运行过程中，试运行部门把系统试运行情况（系统资源使用，反应速度等）记录到试运行报告中。

必要时，项目组应根据系统运行情况对系统进行优化。

（九）试运行达到试运行计划规定的终止条件时，项目组编写《试运行报告》。

此报告应有项目组和试运行部门签字确认，并提交信息办审阅。

信息办审阅试运行结果，决定试运行结束或延期。

第九条验收。

系统主要使用部门及信息办联合组成独立的系统验收小组，也可授权原项目组作为验收小组。

验收小组从功能需求及技术需求层面对系统进行综合评估。

验收小组应根据验收情况整理成《系统验收报告》提交系统主要使用部门和信息办审阅。

系统主要使用部门和信息办负责人根据系统测试、试运行情况签署验收意见。

第十条系统部署。

系统上线应遵循稳妥、可控、安全的原则。

通常情况下，系统上线包含数据迁移工作。

项目组制定《系统上线计划》，上报信息办审批。

在上线计划得到批准后才能开始部署上线工作。

《系统上线计划》内容应包括：

（一）部署方式和资源分配（包括人力资源及服务器资源）；

（二）上线工作时间表；

（三）上线操作步骤以及问题处理步骤；

（四）项目阶段性里程碑和成果汇报（项目执行状态的审阅、进度安排等）；

（五）数据迁移的需求和实施计划；

（六）完整可行的应急预案和“回退”计划；

（七）用户培训计划（包括：

培训计划、培训手册、培训考核等）；

（九）系统标准参数配置。

第十一条上线部门在上线初期需加强日常运行状态监控，出现问题时应及时处理，对重大问题应启动紧急预案。

在完成上线后要填写《系统验收评估报告》，上报项目组汇总整理。

第十二条《系统验收评估报告》内容包括：

数据准确性、系统性能及稳定性、接口问题、权限问题、业务操作影响度、问题处理情况、备份、审批处理等。

上线单位管理层要对《系统验收评估报告》进行审批签字。

第十三条信息办批准项目完成后，使用部门，项目组将整理软件设计，使用说明等相关文档交到档案管理部门由专人负责统一管理；系统开发文档应当受到保护和控制，经信息办批准，才允许使用系统开发文档。

第三章文档管理

第十四条可行性研究报告：

说明该软件开发项目在技术、经济和社会条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论证所选定的方案。

第十五条项目开发计划：

记录在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题做出的安排，以便根据本计划开展和检查本项目的开发工作。

第十六条软件需求说明书：

软件需求人员和软件开发者双方对该软件的业务需求作出的共同的理解，是整个开发工作的基础。

第十七条数据要求说明书：

向整个开发过程提供关于被处理数据的描述和数据采集要求。

第十八条概要设计说明书：

说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。

第十九条详细设计说明书：

说明一个软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关内容合并入概要设计说明书。

第二十条数据库设计说明书：

对于设计中的数据库的所有标识、逻辑结构和物理结构做出具体的设计规定。

第二十一条使用手册：

使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。

使用人员通过本手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。

第二十二条操作手册：

向操作人员提供该软件每一个运行的具体过程和有关知识，包括操作方法的细节。

第二十三条测试计划：

对整个程序系统的组装测试和确认测试的计划安排，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。

第二十四条测试分析报告：

记载组装测试和确认测试的结果、问题及分析、结论。

第二十五条开发进度月报：

项目组向有关管理部门汇报项目开发的进展和情况的报告，以便及时发现和协调处理开发过程中出现的问题。

开发进度月报是以项目组为单位每月编写的。

第二十六条项目开发总结报告：

总结项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。

第二十七条软件开发各阶段的文档编写情况。

（一）可行性研究与计划阶段：

编写可行性研究报告、项目开发计划。

（二）需求分析阶段：

编写软件需求说明书、数据要求说明书、用户手册。

（三）设计阶段：

编写概要设计说明书、详细设计说明书、测试计划初稿。

（四）编码阶段：

编写用户手册、操作手册、测试计划。

（五）测试阶段：

编写测试分析报告、项目开发总结报告。

（六）在整个开发过程中，项目组要按月编写开发进度月报。

第二十八条文档的使用者的具体工作安排。

（一）管理人员：

可行性研究报告、项目开发计划、开发进度月报、项目开发总结报告。

（二）开发人员：

可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、测试计划、测试分析报告。

（三）维护人员：

概要设计说明书、详细设计说明书、测试分析报告。

（四）使用用户：

用户手册、操作手册。

第二十九条不同规模开发项目的文档要求。

（一）系统（大规模）开发：

可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书（可选）、概要设计说明书、详细设计说明书、数据库设计说明书（可选）、用户手册、操作手册、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

（二）子系统（中规模）开发：

项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、用户手册、操作手册、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

（三）模块（小规模）开发：

项目开发计划、软件需求说明书、概要设计说明书、用户手册、测试分析报告。

（四）补丁开发：

软件需求说明书、概要设计说明书、测试分析报告。

第三十条文档的质量要求。

（一）针对性：

文档编写应分清使用对象，按不同类型、不同层次的使用者，决定如何适应其要求。

（二）精确性：

文档的行文应当准确，不能出现多义性的描述，同一项目多个文档的内容应当协调一致，没有矛盾。

（三）清晰性：

文档编写应力求简明，并配以适当的图表，以增强其清晰性。

（四）完整性：

任何一个文档的内容必须是完整、独立的，并自成体系，同一项目的几个文档之间可能有部分内容相同，应当全文复制，不应出现转引其他文档内容的情况。

（五）灵活性：

不同的软件项目，其规模和复杂程度差异很大，应当根据情况编制文档种类，内容多的可以分卷编写，内容少的可以则合并编写。

（六）可追溯性：

由于各开发阶段编制的文档与完成的工作有密切联系，前后两阶段生成的文档随开发工作的延伸，具有一定的继承关系，因此文档间也存在一定的可追溯性，必要时应能做到跟踪追查。

第三十一条在软件生存期中，各种文档会不断生成、修改和补充，必须加强文档的管理：

（一）项目组和系统使用部门都应设置文档管理员，负责项目文档的集中保管、更新和借阅，项目文档应当妥善保管，不得遗失。

（二）软件开发过程中，已完成文档的修改应当非常慎重，特别是对主文档的修改，应充分评估可能带来的影响，严格控制风险。

（三）项目结束时，文档管理员应汇总整理所有文档，收回开发人员个人文档，如发现个人文档与主文档有差别，应对主文档认真校对修订，形成最终版本交付系统使用部门。

（四）当文档内容有变更时，文档管理员应及时修订，并记录修订日志；当有新文档替代旧文档时，文档管理员应立即注销旧文档，避免混淆。

第四章项目管理

第三十二条对于中等规模及以上的软件开发项目，应成立专门的项目组，大规模的软件项目可根据软件功能域成立多个项目组；对于小规模和补丁软件项目，应指定专门的开发人员负责。

第三十三条项目组的人员组成应包含管理人员、系统分析员、软件设计员、代码编程员和文档整理员。

项目组成员必须具备相应资质，特别是核心人员必须经验丰富，品质优良，敬业爱岗。

根据软件项目的规模和特点，在项目组内部各类人员可专职或兼职，应合理搭配，职责明确，相互配合，高效工作。

第三十四条软件开发项目启动前，必须将项目组成员名单提交系统使用部门，如有必要系统使用部门有权面试部分成员，有权要求更换项目组成员。

第三十五条软件开发项目实施过程中，保持项目组成员的稳定，项目组成员的调整必须征得系统使用部门同意，特别是核心成员的变动，必须书面说明情况并采取完善的补救措施，确保项目实施不受影响。

第三十六条软件开发项目启动前，应根据项目技术指标和时间要求，结合项目组织结构、任务分工、资源情况和风险评估，制定出软件项目计划，绘制项目进度甘特图，提交系统使用部门审阅。

系统使用部门有权根据项目实际情况要求做出合理修改。

第三十七条项目计划确定并得到双方认可后，开发方必须调配充足的资源，保障项目按计划执行。

每个任务节点完成后，开发方必须向系统使用部门报告，系统使用部门验收审核后方可继续执行，若不满足计划要求，开发方必须认真整改，且不能影响后续计划执行。

第三十八条项目实施过程中，开发方如果预测到项目不能按计划执行，必须立即向系统使用部门报告，双方应召开项目协调会，分析问题原因，协调各方关系，尽量按原计划执行；如确实无法按计划执行，则必须写出书面报告，由相关领导批准后，方可对项目计划做出调整。

第三十九条软件开发项目中，开发方和系统使用部门以及最终使用者之间应建立快捷有效的沟通机制，各方应明确项目负责人和联系方法，对项目进展情况和需要协调的事宜及时进行沟通。

第四十条根据项目的规模，系统使用部门和开发方应商定合适的定期报告（周报、月报或总结报告）制度，定义规范的报告模板。

项目实施过程中，开发方必须严格按制度定期向系统使用部门汇报项目进展情况，报告内容必须真实全面，严禁弄虚作假、虚报瞒报。

第四十一条软件项目实施过程中，如遇重大事件，如任务节点竣工、软硬件上线、系统联调测试或项目组织变动、项目计划调整、业务需求变更等，应及时写出专题报告，提交项目对方，对方认可后方可实施。

必要时可召开项目协调会议，听取当事方陈述，讨论并决定进一步的措施。

第五章软件开发过程安全注意事项

第四十二条信息系统的应用开发应当与系统安全控制的开发同步设计、同步实施，而应用系统一旦开发完成后，再增加安全措施会造成很大的成本投入。

因此，在应用系统开发的同时，要依据安全详细设计方案进行安全控制的开发设计，以保证系统应用与安全控制同步建设。

第四十三条安全需求分析。

以规范的形式准确表达安全控制的指标要求，确定软件设计的约束和软件同其他系统相关的接口细节。

第四十四条安全概要设计。

概要设计要考虑安全方案中关于身份鉴别、访问控制、安全审计、剩余信息保护、通信完整性、通信保密性、抗抵赖等方面的指标要求。

设计安全控制的体系结构，定义安全控制的模块组成，定义每个模块的主要功能和模块之间的接口。

第四十六条安全详细设计。

（一）依据概要设计说明书，将安全控制开发进一步细化，对每个安全功能模块的接口，函数要求，各接口之间的关系，各部分的内在实现机理都要进行详细的分析和细化设计。

（二）按照功能的需求和模块划分进行各个部分的详细设计，包含接口设计和管理方式设计等。

第四十七条编码实现。

按照设计进行硬件调试和软件的编码，在编码和开发过程中，要关注硬件组合的安全性和编码的安全性，并通过论证和测试。

第四十八条安全测试。

开发基本完成后要进行测试，保证功能的实现和安全性的实现。

测试分为单元测试、集成测试、系统测试和以用户试用为主的用户测试四个步骤。

第四十九条安全控制开发过程文档化。

安全控制开发过程需要将概要设计说明书、详细设计说明书、开发测试报告以及开发说明书等整理归档。