1目的和范围
本管理总则规定本公司软件研制管理所遵循的原则和方法，目的是通过加强开发管理达到如下结果。
1)提高软件质量和每一个项目开发过程的可控性。
2)优化开发资源结构，提高工作效率。
3)优化公司软件管理使产品尽早实现一体化，结构化。
4)通过良好的管理规范和结构使参与人员养成良好的工作素质。
5)引导和组织员工向规范化管理看齐，以使公司尽早实现国际人证。
本条例适用于质量管理组织、部门经理、项目经理等管理人员、系统分析员、系统设计和程序编码人。2引用文件和术语
●GB/T11457-1995软件工程术语。
●GB/T 16260-1996 信息技术、软件产品评价、质量特性及其使用指南。
3 定义
本篇术语尽量使用标准术语（GB/T11457-1995），另外还对本公司软件管理有如下术语说明：
3.1决策层
由公司管理领导小组负责批准软件开发项目的立项。
3.2管理层
由主管总经理、部门经理、质量管理员、项目经理、及有关的技术人员依据项目管理有关规定和各自的职能，协作完成。
3.3 设计层
由系统工程师以及系统分析员组成。
3.4实施层
由软件开发技术人员组成的编码调试队伍。
3.5 全开发型
一个独立的软件开发项目；例如调度命令票的开发，用户提出的调度MIS系统的开发。
3.6 增加功能型
在本公司现有某软件系统的基础上新增加一个独立的功能。
3.7 功能完善型
将本公司软件系统的已有功能完善。如调度MIS系统中的电网计算程序中添加图形示意界面，以方便用户。
3.8 查错测试型
对本公司的软件系统某种不正常现象进行跟踪查错，找出错误根源。
3.9 个体软件过程（psp）
是一种可以用于控制、管理和改进个人工作方式的自我改善过程，是一个软件过程框架。
3.10 软件的可靠性
请参看DB/T 16260---1996 “信息技术软件产品评价质量特性及其使用指南”附录A “质量子特性”
3.11 软件的安全性
请参看DB/T 16260---1996 “信息技术软件产品评价质量特性及其使用指南”附录A “质量子特性”。
4．软件开发方法
4.1 软件开发的基本流程及软件开发类型的分析
4.1.1 软件开发的基本流程
1)软件开发的立项，确定系统需求（目的及用途、功能、技术指标、开发及交付时间）；
2)软件的需求调研
3)软件的需求分析；
4)软件开发的概要设计；
5)软件开发的详细设计；
6)软件的实施（编程和单元测试）；
7)软件的组装测试、总体案例测试、性能及验收；
8)软件的交付投运；
9)软件的维护。
4.1.2 不同开发类型的软件开发流程
1）全开发型必须经过4.1.1所述全部流程；
2）增加功能型必须经过4.1.1所述全部流程；
3）功能完善型需经过4.1.1所述的1)，及3)—9)；
4）查错测试型需要遵循错误处理规范（见附录z）
4.1.3 软件开发过程的控制
1)软件开发流程的1），2），3），4），5），6）阶段都应该经过质量管理小组和开发顾问组（可以
包括用户或公司聘请的有关开发专家）的评审。
2)评审分内部评审和正式评审。
3)内部评审由公司质量管理小组负责实施；正式评审由外部专家及公司的质量管理小组组成的
评审委员会进行。除全开发型的软件验收需要正式评审外，全开发型的软件开发的其它阶段
的评审及其它类型的软件开发的各个阶段的评审均采用内部评审。
4)评审前有关人员必须准备好该阶段的技术文档资料，并填写“评审报告”（附表G-1）的有关
部分，一并上交公司的质量管理小组申请评审。
5)无论内部评审或正式评审，均由公司的质量管理小组指定评审人选与评审日期，最后由公司
总经理批准，同时还要递交一份评审工作安排方案要求总经理批准。
6)评审时首先由有关人员介绍被评审的内容；演示评审内容，再由评审小组测试评审内容，然
后由评审小组提问题，有关人员答辩（需填写“软件评审问题记录”（附表G-2））；最后由评
审小组给出“通过”和“不通过”的结论；若需要修改，应该填写“软件修改报告单”（内部
评审可以适当简化评审程序，免去答辩过程）。
7)软件验收评审前需要填写“评审报告”进行申请外，软件评审要由评审小组或质量管理小组
填写专门的软件评审报告（附表E）。
4.2软件开发项目的确立
该阶段的规范依据公司相关的项目确立和项目下达的有关规定（项目的申请和确立规范）。
4.3 软件需求分析
该阶段只适用于4.1.2所述的全开发型及增加功能型的软件开发项目。
4.3.1 目的任务及实施步骤
＊由软件开发的部门经理与有关的设计人员进行软件的需求分析；
＊对于大的或全开发型的软件开发项目需要根据“软件开发项目任务书”进行必要的技术调查，写出《系统调研报告》，调研报告的书写和实施依据公司的系统调研报告实施规范；
＊分析和确定软件开发、运行的环境；
＊确定人机界面及接口说明；
＊编制项目开发计划，填写“软件开发项目安排书” (附表B_3)、“软件开发项目计划书”(附表B_4)；
＊编写“软件需求规格说明书（附录B）”；
＊评审；
＊下达设计任务。
4.3.2 方法及工具
＊采用面向对象的分析方法（OOA）或结构化的分析方法。
＊若采用面向对象的分析方法（OOA）其标识方法和说明格式应参考“标准建模语言（UML）”的书写及文档格式。
＊若采用结构化的分析方法，请参考附录B“软件需求规格说明书书写格式”。
4.3.3 评审
＊根据“软件开发任务书”针对软件开发计划，软件需求规格说明进行评审。评审内容：?是否符合“软件开发任务书”的要求；
?可行性：是否能按时，按质，交付符合系统需求的软件；
?标准化：其文档资料是否符合标准；
?可靠性，安全性和可维护性：其软件需求规格说明是否规定了可靠性，安全性和可维护性的要求；
＊评审应该作出通过或不通过的结论。可原则通过，但需作部分修改和补充，则需待概要设计评审时对修改或补充部分进行检查评审。
4.3.4 设计任务下达
＊“软件需求规格说明书”、“软件开发项目计划书”和“软件开发项目安排书”经过公司总工程师的批准之后，连同“软件开发项目任务书”和“个人工作任务书”作为正式任务，下
达给设计层人员；
4.4 概要设计
4.4.1 目的和任务和实施步骤
＊根据“软件需求规格说明书”中规定的软件功能需求，建立软件的总体结构和功能模块之间的关系，定义各功能模块的接口，设计数据库模式和数据结构，初步编制测试计划。
＊概要设计是软件开发必须执行的重要阶段（因为软件分析阶段对一些类型的软件开发可以不执行）。
＊其步骤为：
■总体结构设计：将整个软件系统分解为子系统、功能模块；粗略描述子系统和功能模块之间的数据及控制关系，及接口；
■数据库模式及数据结构的设计；
■各个功能模块的功能定义，接口定义；
■编制概要设计说明（参看附录C）；
■初步编制测试计划（参看附录G）。
4.4.2阶段产品
＊概要设计说明书
＊软件测试计划（初步）
4.4.3 评审和批准
4.4.3.1 评审
＊由负责该软件开发的技术人员向软件开发技术领导小组申报。申报时应该填写“软件评审报告”（附表G-1）以及提交4.4.2所列的必需具备的文档资料”。
＊评审的内容:
根据“软件开发任务书”及“软件需求规格说明”针对软件概要设计进行评审。
。是否符合“软件开发任务书”及“软件需求规格说明”的要求
。可行性：是否能按时，按质，交付符合系统需求的软件
。标准化：其文档资料是否符合标准
。可靠性，安全性和可维护性：其概要设计是否考虑了“软件需求规格说明”中规定的可靠
性，安全性和可维护性的要求
＊软件开发评审小组根据软件概要设计必需具备的文档资料及答辩情况进行讨论，并作出评审意见(通过或不通过)。若有重大修改及评审不通过，应再次举行评审答辩；若有小的修改，
需留待详细设计阶段一并进行评审。
4.4.3.2 批准
＊软件开发技术领导小组将评审意见及全部资料提交总经理进行最后审批。
＊总经理将审批后，由软件开发人员继续进行软件的下阶段开发。
4．5 详细设计
4.5.1 目的及内容及步骤
＊详细设计必须符合概要设计说明的功能需求、框架结构、数据结构、数据流程的基本设计要求。
＊详细设计内容及步骤：
。确定准确的数据结构（必须有准确详细的文字说明）；
。进行完整的数据库的模式设计（必须有准确详细的文字说明）；
。进行主程序的结构及过程的准确的描述（可使用文字及类ＰＡＳＣＡＬ语言进行描述）；
。进行ＡＰＩ的准确的描述（输入参数，输出参数，功能描述）；
。进行全部子程序或服务的逻辑结构准确的描述（可使用文字及类ＰＡＳＣＡＬ语言进行描述）；
。进行全部事件（输出事件及接收事件）的描述（事件名，事件体，输出事件何时发出，接受事件的处理流程）；
。完成详细设计说明书的编写（参看附录D）；
。拟定子系统及功能模块的调试方案。
＊在软件详细设计过程中若发现框架设计需要修改，应提出修改方案并填写修改报告单。4.5.2 阶段产品及文档资料
＊详细设计说明书；
＊如有修改，需要具备修改后的概要设计说明及修改报告单；
＊子系统及功能模块的测试计划。
4.5.3 评审；
＊对于 4.1.2中所述的全开发型及增加功能型的软件开发应该进行详细设计的评审, 而其它两种类型的软件开发除非概要设计有重大修改一般不进行评审。
＊评审过程参看4.4.3.1;
4.6 软件实现
4.6.1 任务及实施步骤
＊根据软件详细设计说明，进行程序编制、静态分析、自测试、互测试。
4.6.2 阶段产品及文档资料
＊软件概要设计及详细设计文档资料及相应的修改报告单；
＊源程序；
＊自测试大纲及测试结果；
＊软件使用说明书和维护说明书初稿。
4.6.3程序编制的规范
＊变量名：必须与其代表的意义或其用途一致，可读(决不允许无实际意义的变量名，如a、b、
c、I、j、k等)。
＊每个源程序(包括主程序及各个例程)的行数不得超过５００行。
＊每个源程序必须有程序头说明（程序名称，功能，上一级程序名，调用的子序名，输入参数，输出参数，编制人，完成日期，修改的历史记录）。
＊每个源程序必须有注释行（平均５－８行源程序有一行注释）。
4.6.4 软件的静态分析
该分析为使用人工或自动调试工具对程序代码逐条进行检查、分析，以发现编码错误的过程。其内容为；
＊检查代码和详细设计的一致性；
＊检查代码的标准性，可读性；
＊检查代码逻辑代码的正确性。
4.6.5软件的自测试和互测试
软件的自测试是在软件项目开发组内部进行的测试，以保证被开发的软件符合系统需求(功能需求及技术要求)，检查软件的容错能力，检查软件的可靠性及安全性；为软件的正式验收测试提供依据和基础。
＊软件开发项目自测试首先可以在比较独立的环境，进行该开发软件的各个软件模块的功能测试。
＊功能测试之后，必须将被开发软件与整个软件系统组装到一起，在完整的运行环境下进行测试。
＊自测成功后，应该由技术部经理（或相应的软件开发部门经理）安排其他与该开发项目无关的技术人员按测试大纲进行互测；
＊自测试及互测试必须有测试大纲、测试用例及测试记录。
＊必须自测试及互测试成功之后，才允许提交正式的测试和验收。
4.7软件开发项目的验收
4.7.1 目的及内容
＊根据“软件开发项目任务书”中规定的用户需求以及软件开发人员提交的“软件测试大纲”
在相应的系统环境（该系统当前的正式版本）下对已经开发成功的软件进行严格测试。
＊审查软件产品必需具备的文档资料的规范性，完整性及正确性。
＊审查软件产品介质的正确性，完整性及一致性。
＊由软件评审小组对被审查的软件给予“审查评语”，合格的系统进行版本注册登记。
4.7.2 软件验收的执行者
＊执行者为软件开发技术领导小组及其委托的软件评审小组( 软件正式验收的评审) 、软件质量管理小组（软件产品审查）及版本管理小组（版本注册，复制，发行）。
4.7.3软件验收的步骤及验收测试小组的组成
4.7.3.1 软件验收的步骤
＊由项目负责人填写“软件开发项目正式验收申请书”（附表E-1），交技术部汇总，由公司质量管理部进行审查，审查内容为：
。程序编制的规范性（如变量命名，程序头，程序注释）；
。测试大纲及自测试及互测试结果的正确性；
。软件使用说明书的完整性及规范性；
。若软件实现过程进行了软件概要设计或详细设计的修改,则应该审查是否具备相应的修改后的设计文档；
若审查不通过；需要技术部（或相应软件开发部门）进行相应的修补工作；然后再进行审查，直至通过为止；
＊审查通过后，由公司总经理批准，然后开始启动软件验收过程。
＊由软件开发人员编写测试大纲的并经评审小组评审；
＊由公司软件质量管理小组委托专门的技术人员建立测试环境；
＊由公司软件质量管理小组委托专门的技术人员建立测试小组按照测试大纲进行严格的测试；
＊测试中若出现重大的错误，则此次软件测试宣告失败；应修改后再进行重新全部测试；
＊测试中若出现一般的错误，可经修改后，进行专项补测；
＊测试小组应该提交软件测试报告；
＊由公司软件质量管理小组委托专门的技术人员建立文档资料审查小组进行文档资料的审查，并提交审查报告；
＊由公司软件质量管理小组委托专门的技术人员建立介质审查小组进行软件介质的审查，并提
交审查报告；
＊测试结束由公司软件质量管理小组组织软件评审小组经过认真评议作出“审查评语”。
4.7.3.2 软件验收测试小组的组成
＊软件验收阶段应该组织三个测试审查小组；软件测试小组、软件文档资料审查小组、软件介质审查小组；
＊三个测试审查小组的人员主要由公司工程部技术人员组成
＊测试审查小组由公司公司软件质量管理小组与质管部负责组织
4.7.4软件测试大纲的编制及审定
＊软件测试大纲由负责软件开发的人员编写；
＊评审小组召集会议，听取大纲编写人员的介绍以及与会者的意见，经过讨论，并经大纲编写人员的修改补充，最后由软件评审小组讨论审定该测试大纲。
4.7.4.1软件测试大纲的内容
详细的格式请参看附录H
4.7.5 针对不同软件开发情况的测试要求
4.7.
5.1系统基础级的测试
＊系统的支撑平台的基本服务被修改或全开发型的软件开发项目属于此种类型；
＊必须将该软件系统全部程序（支撑平台及应用软件）进行编译链接。
＊对新的或经过重大修改的软件系统统（必须有数据源的仿真环境）进行所有功能的测试。
4.7.
5.2基本系统的测试
＊系统的支撑平台的部分软件被修改属于此种类型；
＊必须对该系统的有关部分（支撑平台软件）进行编译链接。
＊在当前被修改的软件系统的版本（必须有数据源的仿真环境）下对开发修改的部分及其它应用软件进行测试。
4.7.
5.3应用系统的测试
＊系统的应用软件进行了重大修改或开发了新的应用软件属于此种类型；
＊必须对该应用软的有关部分进行编译链接。
＊在当前系统的版本（必须有数据源的仿真环境）下对开发修改的应用软件及其它有关应用软
件进行测试。
4.7.
5.4一般修改的测试
＊系统的应用软件进行了一般修改属于此种类型；
＊必须对有关部分进行编译链接。
＊在当前系统的版本（除去开发修改的部分）下对修改的应用软件进行测试。
4.7.6 软件测试的一般性合格标准
＊符合该开发项目的“软件需求规格说明书”中规定的用户的功能需求及性能需求。
＊符合测试大纲中规定的各项功能。
＊新开发修改的项目的可靠性标准：
。人机界面调用１０００次不故障退出，不产生core dump或死机。
。支撑平台的分布式管理及数据库的基本服务连续访问１００００００次不出错误，不产生
core dump或死机。
。支撑平台的分布式管理及实时数据库的基本功能（如主备机自动切换，子系统的切换，子
系统及进程的退出服务和启动，双以太网的自动切换；数据库的安装更新，数据库模式的建
立和修改，数据库的同步，实时数据库与关系数据库的同步及捆绑；等等）连续调用１００
０次不发生错误，不产生core dump或死机。
。应用系统在支撑环境下（必须有前置机的仿真环境）连续运行72小时不发生功能性错误，
不产生事件堆积，不故障退出, 不产生core dump或死机。
4.7.7软件文档资料
4.7.7.1文档资料应涵盖的范围
＊该软件开发项目的“软件开发任务书”、“软件需求规格说明”及对上述文档的修改资料；
＊该软件开发项目的概要设计及详细设计的全部资料；
＊该软件开发项目的全部源程序；
＊该软件开发项目的自测试和互测试记录；
＊该软件开发项目的用户使用手册和维护手册；
＊该软件开发项目的测试大纲；
＊资料的详细清单。
4.7.7.2审查文档资料的手段
＊审查人员检查文档资料的规范性，完整性。
＊可以使用专门的软件去测试源程序的规范性。
4.7.8软件介质的审查
4.7.8.1软件介质的定义
＊软件介质指的是完整的记录软件的可运行模块及其安装说明的磁带，软盘，光盘。
4.7.8.2软件介质合格的标准
＊介质记录了软件系统全部可运行模块及其安装说明或记录软件系统的升级模块及其安装说明；用此介质安装之后，该软件系统可以立即可靠的运行。
＊该介质应该与提供的用户手册完全一致。
4.7.9 评审
＊软件验收阶段需要经过两次评审；
＊第一次评审是对验测试收大纲的评审；
＊第二次评审是该验收阶段的最终评审；其评审内容为：
。软件测试报告
。软件文档资料的审查报告
。软件介质的审查报告
＊评审结果：通过或不通过。
4.8软件的交付
4.8.1 软件的交付方式
＊将经过正式验收的软件由开发部或相应的软件开发部门交付质量管理部进行注册登记；
＊由质管部及开发部或相应的软件开发部门共同向工程部门交付经过正式验收的软件系统，以便工程部进行系统集成及进一步测试
4.8.2 软件交付后的完善
＊软件交付工程部门进行系统集成及测试后或进行工程的工厂验收和现场验收后若出现若干不符合用户需求的问题或错误，应该由工程部门填写“软件问题报告单”（针对软件错误和不符合用户需求的问题），并交部门经理汇总；若问题可以由本部门解决，则在本部门安排解决；若本部门不能解决的问题，交公司技术领导小组统一安排软件的修改完善工作。
4.9 软件的维护及完善
4.9.1维护请求的提出
＊维护请求由工程部门以”软件问题报告单”的形式提交并交部门经理汇总；若问题可以由本部门解决，则在本部门安排解决；若本部门不能解决的问题，交公司技术领导小组，统一安排解决。
4.9.2维护计划的形成
＊对于小的软件问题可以不经过评审,直接形成《软件开发项目任务书》下达给技术人员.
＊对于较大的软件问题应经过评审形成《软件开发项目任务书》然后下达给技术人员( 参考
4.2.1”软件开发项目的确立”).
4.9.3 维护的过程
＊对于”增加功能型”的维护,实际是一个较为独立的软件开发项目,应该按4.2—4.4的阶段进行软件的开发
＊对于”功能完善型”及”查错调试型”的维护, 实际是一个修改软件的过程,应该按以下步骤进行：
。维护人员对维护需求进行分析，修改“软件需求规格说明”或“软件概要设计说明”或
“软件详细设计说明”，评审小组对其修改进行评审，然后维护人员根据评审意见进行再修
改、再评审，直到通过。
。维护人员根据修改的设计进行源程序的代码修改及静态分析、自测试、互测试，软件验收。
。原则上，凡是对现场运行的软件的修改，均应该在实验室先进行模拟修改和测试；成功后，
经过项目经理或部门经理批准后，再到现场进行修改；如因为特殊原因，在未经过实验室修
改和测试，而对现场运行的软件进行修改，应该事先及时与项目经理或部门经理联系，说明
修改的内容及理由，经过同意后，再慎重的进行修改和测试；事后必须填写〈软件问题报告
单〉及〈软件修改报告单〉或〈工程修改报告单〉，并经过项目经理或部门经理审查批准；
。进行维护后，都应该及时经过质管部的注册登记调整软件版本号、保存相应的软件介质，
以保证软件版本的一致性。
附录A 软件立项报告书写格式
北京思创公司软件开发项目
立项报告
项目名称:
课题名称：
起止时间：年月至年月
年月日
1 目的和意义
1.描述与软件开发内容紧密相关的产品的实际水平和今后的发展方向；
2.阐述课题成果对该现状和技术发展的作用；
3.分析成果应用和推广的途径；
4.分析成果推广后的直接和间接效益。
2 国内外研究水平综述
1.与软件开发内容紧密相关的技术发展历史的简要回顾；
2.国内外研究水平的现状和发展趋势；
3.介绍国外研究机构或者公司对本课题的研究情况；
4.介绍国内其他研究单位对本课题的研究情况。
3．课题的理论或实践依据
1.软件开发内容的原理简述；
2.软件开发内容的理论或者实践依据；
3.软件开发的技术关键和难点。
4.软件开发内容和实施方案
1.软件开发内容的详细说明（可分专题或按内容序号描述）。
2.要描述具体的开发步骤，现场试验的地点和试验计划，需要建设的试验环境；
3.理论研究和试验内容与软件开发总目标的因果关系；
4.写明理论和试验研究的工作量；
5.需要多家单位共同承担的课题，需要写明各家的分工、职责和提供的成果，如何组织和协调；
6.需要与国外合作，要写明与外方的合作方式、知识产权和成果分享的范围，及以前的工作联系；
7.注明本软件开发需要购买设备的型号、产地、性能及需要购买的原因；
8.外委的工作内容和工作量；
5．预期目标和成果形式
1.阐明软件开发预期达到的目标；
2.明确叙述软件产品成果提供的形式；要求成果提供的形式能够被其他技术人员掌握，使成果的使
用权具有可转移性。
6试验单位或依托工程情况
1.如需借用其他单位的试验环境，说明选定试验单位的落实情况；
2.如需结合依托工程进行试点研究，说明依托工程及其与本软件开发结合的情况。
7软件开发所需的条件
7.1课题负责人
对课题负责人的要求；
7.2软件开发人员
对课题承担人员的专业、特长、工作水平的要求；
7.3验室条件（包括硬件和软件）
说明该软件开发所需的硬件及软件的环境,并开列清单;
8 课题的进度安排
1.列出分年度计划研究内容和人员、设备安排；
2.分年度提供成果的内容和形式，要具有可检查性。
1
2
3
4
5
6
7
8
9
10
11
12
报告编写人：
附录B软件需求规格说明书书写格式
1．任务名称
2．任务来源
3．运行环境
以文字确切的说明该软件在何种环境下运行；
硬件环境：服务器/工作站/PC机/单板机；
软件环境：何种OS，何种数据库系统，以及其它支持软件；
工作环境：调度室/维护工作机房/管理人员办公室/变电站等；
使用人员：调度员/维护人员/开发人员及相应的文化程度；
4．功能需求
详细的以文字和图/表描述该软件应该完成的功能；
5．技术性能要求
说明该软件应该具备的安全性、可靠性、实时响应性、可用性等具体要求；
6．功能模块描述
简要说明该软件的各个功能模块的功能，及与其它模块之间的关系；
7．接口描述
简要说明各个外部及内部接口的功能及输入参数和输出参数；
8．对人机交互的要求
说明该软件是否要求人机交互，以何种方式进行交互，交互欲达到的目的；并简要说明主要人机交互的过程；
附录C 概要设计说明书书写格式
1 概要设计说明书的框架
1．用户需求
2．术语
3．数据结构及事件定义
4．程序的框架结构
5．各个程序模块的描述
6．相关的人机界面的描述
2用户需求的书写规范
参看附A。
3 术语的书写规范
1）。专用术语
逐个列出该概要设计中所使用的专用术语的名称及确切含义；
2）。缩写词
逐个列出该概要设计中所使用的缩写词的名称及确切含义；
4 数据结构及事件定义的书写规范
1）。数据库模式的描述
●该软件所使用的已经建立的数据库及表的名称；
●该软件需要新建立的数据库的模式的概要描述（数据库用途，数据库名、表名及用途、属性
名）；
2）。内部主要数据结构的描述
程序内部需要使用的数据结构的名称、用途、包含的属性；
3）。新定义的事件的描述
说明新定义事件的名称及用途；
5 程序的框架结构的书写规范
1)。程序的层次机构（树状结构）的描述
以文字和图描述该程序的层次机构（树状结构）；结构中包含所有的程序单元（主程序及各层子程序及各个函数）及处理事件的程序模块；
2）。各个程序模块之间的逻辑关系描述
用图形（或类PASCAL语言）描述程序的概要逻辑关系（包括事件处理的源头）；
6 程序模块描述的书写规范
1）。程序模块的功能描述
以文字描述该程序的功能；
2）。程序模块的输入及输出描述
以文字描述该程序的输入参数（变量，数组，指针，常数）及相应的输出参数（变量，数组，指针，常数）；
7 类（CLASS）描述的书写规范
1）。以文字描述该类（CLASS）的功能；
2）。以文字描述该类（CLASS）的继承关系；
3）。类（CLASS）的属性描述
以文字描述该类（CLASS）的各个属性及其含义；
4）。类（CLASS）的函数的描述
以文字描述该类（CLASS）的各个函数的功能及输入输出参数
8 人机界面描述的书写规范
1）。以文字或图形描述各个人机界面的功能
附录D 详细设计说明书书写格式
1 详细设计说明书的框架
1．用户需求
2．术语
3．数据库模式设计
4．内部数据结构设计
5．事件的设计
6．程序的框架结构（若已有概要设计则此节可省略，否则必须书写）
7．程序模块的详细设计
8．人机界面的详细设计
3用户需求的书写规范
参看附A。
3 术语的书写规范
1）。专用术语
逐个列出该详细设计中所使用的专用术语的名称及确切含义；
2）。缩写词
逐个列出该详细设计中所使用的缩写词的名称及确切含义；
4 数据库模式设计的书写规范
详细描述新建立的数据库模式的结构;
●数据库名称及用途
●数据库各个表的名称及用途
●各个表的属性的名称、数据类型、含义
5 内部数据结构的书写规范
●数据结构的名称及用途
●数据结构的属性的名称、数据类型、含义
6 程序的框架结构的书写规范
1)。程序的层次机构（树状结构）的描述
以文字和图描述该程序的层次机构（树状结构）；结构中包含所有的程序单元（主程序及各层子程序及各个函数）及处理事件的程序模块；
2）。各个程序模块之间的逻辑关系描述
用图形（或类PASCAL语言）描述程序的概要逻辑关系（包括事件处理的源头）；
7 事件的设计
1）。新定义的事件的结构描述
详细描述新定义的事件的名称、用途、事件体结构、事件体每个属性的数据类型及含义、在何种条件下发出；
2）。本程序注册的事件的描述
●描述本程序注册的事件的名称、由哪个程序或BOB发出的、该事件的事件体结构；
●对该事件的处理流程的描述：以文字或“类PASCAL语言”描述该处理流程；其详尽程度
要保证程序员可以按照已定义的数据结构及该描述不加任何发挥的编写出程序；
8 程序模块设计的书写规范
1）。程序模块的功能描述
以文字描述该程序的功能；
2）。程序模块的输入及输出描述
以文字描述该程序的输入参数（变量，数组，指针，常数）及相应的输出参数；
3)。程序模块逻辑流程的详细描述
以文字或“类PASCAL语言”描述该程序程序模块的处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该程序模块的详细描述不加任何发挥的编写出程序；
9类(CLASS)设计的书写规范
1）。以文字描述该类（CLASS）的功能；
2）。以文字描述该类（CLASS）的继承关系；
3）。类（CLASS）的属性描述
以文字描述该类（CLASS）的各个属性的类型及其含义；
4）。类（CLASS）的函数的描述
以文字描述该类（CLASS）的各个函数的功能及输入输出参数；
以文字或“类PASCAL语言”描述各个函数的处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该函数的描述不加任何发挥的编写出该函数的程序；
10 人机界面设计的书写规范
1）。该人机界面的名称及用途
2）。用图形将实际使用的界面全部画出来；包括全部的菜单条、图象、符号、光敏点等；
3）。列出菜单条及光敏点对应的回调函数的名称及功能；
4）。详细描述各个回调函数的输入输出参数；并以文字或“类PASCAL语言”描述各个函数的处理流程；其详尽程度要保证程序员可以按照已定义的数据结构及该函数的描述不加任何发挥的编写出该函数的程序；
软件开发管理办法 1 软件开发 1.1软件开发流程 1.2项目策划 根据年度软件开发计划确定的项目或用户提出的需求变更项目，组织进行项目前期策划，确定项目实现目标、内容、质量要求、工期，下达《软件开发任务书》或对用户《需求变更申请》进行审核和任务安排，项目组接到任务后组织实施。项目组根据任务安排，编制《软件开发计划》。 1.3系统需求分析 项目组根据项目内容和目标，编制《需求调研计划》和《需求调查表》，组织用户参加的项目启动会，讨论通过《需求调研计划》，用户按《需求调查表》的内容准备调研材料。开发项目组和用户组成联合项目组，共同推进项目的实施。 调研阶段完成后形成《软件需求规格说明书》，重点明确以下内容：组织机构、岗位职责、业务流程、所需的业务功能，业务功能和岗位的对应关系，业务功能处理的数据项，业务功能的详细描述。 需求分析完成后，由内部组织进行阶段评审，填写《阶段评审记录》。
组织召开需求确认会，《软件需求规格说明书》由用户审查通过后，填写《用户需求确认单》。 依据《软件需求规格说明书》，编制《系统测试计划》初稿。1.4系统设计 依据《软件需求规格说明书》进行系统设计，形成《软件设计说明书》，主要内容包括软件功能设计说明、数据库设计说明、功能的数据处理说明（功能-数据关联矩阵）、程序模块设计说明（后期完善）等。 系统设计完成后，由内部组织进行阶段评审，填写《阶段评审记录》。 依据《软件设计说明书》，补充完善《软件测试计划》。 1.5编码 依据《软件设计说明书》，遵守有关技术规范，在开发平台上进行编码，实现软件功能。 编码完成后，编写《用户操作手册》，补充完善和修改《软件设计说明书》，把编程过程中数据设计、功能设计的变动进行文档修正，补充程序模块设计说明，编制《软件组件清单》、《数据对象清单》，修改完善《系统测试计划》。 1.6测试 项目组内部组织完成单元测试。 编码完成后，由内部组织进行阶段评审，填写《阶段评审记录》。
系统开发安全管理办法
文档说明（一）变更信息 （二）文档审核人
目录 第一章目的 (4) 第二章适用范围 (4) 第三章术语、定义、缩略语 (4) 第四章组织与职责 (4) 第五章安全需求 (5) 第六章安全设计 (5) 第七章安全编码 (5) 第八章安全测试 (6) 第九章安全上线 (6) 第十章开发外包 (7) 第十一章附则 (7)
第一章目的 第一条为规范本单位的应用系统开发过程，提升交付系统的安全性，有效降低安全风险，特制定本管理办法。 第二条系统开发安全管理是指在系统开发阶段，建立若干安全的开发流程，对其进行有效管理，将符合安全需求的安全机制与措施在应用系统中实现，提高交付系统的安全性，减少后续安全更正和维护所产生的成本。 第二章适用范围 第三条本管理办法中应用系统开发安全管理涉及的过程包括：安全需求分析、安全设计、安全编码、安全测试、安全上线、以及应用系统开发外包的安全管理。 第四条本管理办法适用于应用系统开发类项目，以及与项目相关的项目管理人员、项目实施人员。 第三章术语、定义、缩略语 第五条安全需求是指为保障应用系统安全，满足应用系统合规性需求和敏感信息保护需求，而针对应用系统提出的一系列安全要求。 第四章组织与职责 第六条应用系统开发安全管理的统一归口管理部门是技术部，职责包括：
（一）总体负责应用系统开发类项目开发安全管理； （二）组织制定安全开发相关规章制度、流程、实施细则； （三）执行安全需求分析、安全设计、安全编码、安全测试、安全上线的实施工作； （四）参与开发人员安全技能培训。 第五章安全需求 第七条应用系统需求分析阶段必须进行安全需求分析。 第八条安全需求分析应该明确应用系统的业务安全需求，合规性需求以及敏感信息保护需求。 第九条安全需求确定后，应该进行安全需求评审，得到安全需求相关各方的认可。 第六章安全设计 第十条应用系统设计阶段必须进行安全设计。 第十一条安全设计应该明确系统安全逻辑架构，数据安全架构和部署环境安全架构。 第十二条安全设计应该满足系统的安全需求，能够直接指导系统安全功能的编码工作。 第十三条安全设计确定后，应该进行安全设计评审。 第七章安全编码 第十四条应用系统编码前，应该制定安全编码规范，明确代码编写的原则和要求，同时应对开发人员进行安全编码培训。
231 GB 8567－88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567－88中主要软件文档的编写说明，供编写时参考。这些文档主要是：可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明：说明本可行性研究报告的编写目的，指出预期的读者。 1.2 背景 说明： a ．所建议开发的软件系统的名称。 b ．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c ．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料，如： a ．本项目的经核准的计划任务书或合同、上级机关的批文。 b ．属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提，如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求，如： a ．功能。 b ．性能。 c ．输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e ．处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程，并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标，如： a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。
软件开发管理制度 为加强对公司软件研发部门工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高开发效率，特制定软件研发部管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。 5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。 软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
软件开发管理制度 软件开发管理是指根据公司统一的信息系统规划和业务需求，对信息系统的开发进行管理。具体包括组织、规划、需求、分析、设计、编程、测试和投产等环节。 本制度适用于公司公司软件开发项目。 1.1 项目立项 信息系统研发前公司成立项目工作小组，重大项目成立项目领导小组，并指定负责人。 项目领导小组负责项目的组织、协调、检查、监督工作。项目工作小组由业务人员、技术人员和管理人员组成，具体负责整个项目的开发工作。 项目工作小组人员应具备与项目要求相适应的业务经验与专业技术知识，小组负责人需具备组织领导能力,保证信息系统研发质量和进度。 业务部门根据本机构业务发展战略，在充分进行市场调查、产品效益分析的基础上制定信息系统研发项目可行性报告。 1.2. 系统开发 公司业务部门编写项目需求说明书，提出业务需求和系统需求。 信息技术部和业务部门领导组织人员对项目需求进行评审，意见统一后形成定稿后的“项目需求分析报告”和“项目风险报告”，加盖相关部门签章归档。 公司信息技术部根据项目需求编制项目功能说明书。 公司信息技术部依据项目功能说明书分别编写项目总体技术框架、项目设计说明书，设计和编码应符合项目功能说明书的要求。评审通过后加盖部门签章归档。 公司业务人员、技术人员应根据职责范围分别编写操作说明书、技术应急方案、业务连续性计划、投产计划、应急回退计划，并进行演练。 在编码阶段，软件开发人员应有良好的编写习惯，做好代码注释和说明，并做好单元测试工作。 1.3. 测试 公司应建立独立的测试环境，以保证测试的完整性和准确性。测试至少应包括功能测试、安全性测试、压力测试、验收测试、适应性测试。测试不得直接使用生产数据。 公司信息技术部应根据测试结果修补系统的功能和缺陷，提高系统的整体质量。 由业务部门组织人员完成软件的最终测试，并保留软件测试记录，撰写“项目测试报告”并确认签章，原则上要求项目测试人员和项目需求人员是同一批人员。 项目验收应出具由相关负责人签字的项目验收报告，验收不合格不得投产使用。 项目小组编写“软件上线计划”，按计划安全稳妥的实现软件产品的上线实施，对核心业务系统的软件上线由版本控制员实施，没有业务部门提交的“项目测试报告”及“上线确认书”的软件项目不允许上线运行。
软件开发管理制度 版本：V1.0 2013年1月
第一节总则 第一条为规自有软件研发以及外包软件的管理工作，特制定本制度。本制度适用于公司总公司软件研发与管理，分公司参照执行。 第二条本制度中软件开发指新系统开发和现有系统重大改造。 第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进行系统设计、软件开发、集成和相关的技术支持工作，一般仅向外购置有关的硬件 设备和支撑软件平台；合作开发是公司与专业IT公司（合作商）共同协作完 成IT应用的项目实施和技术支持工作，一般形式是公司负责提供业务框架， 合作商提供技术框架，双组成开发团队进行项目实施，IT系统的日常支持由 IT技术中心和合作商共同承担，IT技术中心负责部（一级）支持，合作商负 责外部（二级）支持；外包开发是指将IT应用项目的设计、开发、集成、培 训等任务承包给某家专业公司（可以是专业的IT公司或咨询公司等），由该 公司（承包商）负责应用项目的实施。 第四条软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求管 理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验收、 系统上线和数据迁移。 第五条除特别指定，本制度中项目组包括业务组（或需求提出组）、IT组（可能包括网络管理员和合作开发商）。 第二节立项管理 第六条提出开发需求的信息技术部门参与公司层面立项，进行立项的技术可行性分析，编写《立项分析报告》（附件一），开展前期筹备工作。《立项分析报 告》应明确项目的围和边界。 第七条应用系统主要使用部门将《立项分析报告》上交公司总裁室进行立项审批，以保证系统项目与公司整体策略相一致。 第八条《立项分析报告》得到批准后，成立项目组（如果是外包开发，则成立外包商项目组；如果是合作开发，则与外包商共同成立合作开发项目组，以下统 称“项目组”），项目组应包括业务组（由公司相关业务部门组成）和IT组 （自行开发为办公室网络管理员；外包开发为外包商成员；合作开发为网络
软件项目开发计划书 Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
软件开发计划书 项目名称：图书管理系统 目录
1引言 编写目的 为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，有必要以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容以书面的方式描述出来，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。 本项目开发计划用于从总体上指导图书管理系统项目顺利进行并最终得到通过评审的项目产品。本项目开发计划面向项目组全体成员。 背景 山西农业大学图书管理系统是由沈阳师范大学委托我们开发的大型管理系统，主要功能是实现图书馆的信息化管理，包括读者信息管理，书籍信息管理，借阅信息管理，管理者信息管理等功能。项目周期为六个月，项目背景规划如表所示。 表项目背景规划
图书管理系统是学校信息管理系统的一个重要组成部分，它需要学生基本信息系统提供学生的基本资料，因为很多情况下，图书证号和学生的学生证号是一样的，而且在图书管理中，需要知道学生所在的系别和班级等信息；另外，它还需要教职工信息系统提供基本资料，因为教职工当然也能在图书馆借阅图书。因此，在设计时可以和校园信息管理系统的其他系统使用同一个数据库管理系统，以便系统之间的信息交流和管理。 定义 专门术语： SQL SERVER:系统服务器所使用的数据库关系系统（DBMS）。 SQL：一种用于访问查询数据库的语言 事务流：数据进入模块后可能有多种路径进行处理。 主键：数据库表中的关键域。值互不相同。 外部主键：数据库表中与其他表主键关联的域。 ROLLBACK:数据库的错误恢复机制。 缩写： 系统：若未特别指出，统指本图书管理系统。 SQL：Structured Query Language(结构化查询语言)。 ATM：Asynchronous Transfer Mode (异步传输模式)。 UML：统一建模语言、是一套用来设计软件蓝图的标准建模语言，是一种从软件分析、设计到编写程序规范的标准化建模语言。
XX公司软件开发管理制度 XX公司软件开发管理制度 版本：1.0 SDM审批： QA经理[时间] CTO[时间] 目录 1.目的和作用3 2.适用范围：3 3. 参考文件3 4.适用对象3 5.软件开发流程4 5.1可行性研究与计划4 5.1.1实施4 5.1.2 文档4 5.1.2.1 应交付的文档4 5.1.2.2 提交步骤4 5.2需求分析4 5.2.1实施4 5.2.2要求5 5.2.3交付文档5 5.2.4审批5 5.3概要设计5 5.3.1实施5 5.3.2要求6 5.3.3交付文档6 5.3.4补充说明6 5.3.5审批6 5.4详细设计7 5.4.1实施7 5.4.2要求7 5.4.3文档7 5.4.4审批7 5.5实现7 5.5.1实施与要求7 5.5.2交付文档8 5.5.3审批8 5.6组装测试8 5.6.1实施8 5.6.2要求8 5.6.3交付文档8 5.6.4审批8
5.7确认测试9 5.7.1实施9 5.7.2要求9 5.7.3交付文档9 5.7.4 补充说明9 5.7.5 审批9 5.8发布10 5.8.1过程10 5.8.2 文档10 5.8.3 审核10 5.9 交接10 6. 附录1：项目文档清单11 1.目的和作用 本流程详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 2.适用范围： 公司的软件开发产品均适用。 3. 参考文件 各种文档模板 文档命名规则 交接流程 4.适用对象 软件管理人员，软件开发人员，软件维护人员 5.软件开发流程 5.1可行性研究与计划 5.1.1实施 5.1.1.1 软件开发部分析人员进行市场调查与分析，确认软件的市场需求 5.1.1.2 在调查研究的基础上进行可行性研究，写出可行性报告 5.1.1.3 评审和审批，决定项目取消或继续 5.1.1.4 若项目可行，制订初步的软件开发计划，建立项目日志 5.1.1.5 根据市场环境、公司软硬件情况预测十大风险因素 5.1.2 文档 5.1.2.1 应交付的文档 1）可行性研究报告* 2）初步的软件开发计划 3）十大风险列表* 4）软件项目日志* 5.1.2.2 提交步骤 1) 适用于以后各阶段的文档提交。 2) 项目相关文档用sourcesafe进行版本管理，相关书写人员可根据各文档模板形式撰写文档，正式提交的文档以存入软件管理服务器相关目录时间为准。以后每次修改都应注明修改内容。 5.2需求分析
一、引言 1．1目的 随着计算机应用的广泛普及，计算机安全已成为衡量计算机系统性能的一个重要指标。 计算机系统安全包含两部分内容，一是保证系统正常运行，避免各种非故意的错误与损坏；二是防止系统及数据被非法利用或破坏。两者虽有很大不同，但又相互联系，无论从管理上还是从技术上都难以截然分开，因此，计算机系统安全是一个综合性的系统工程。 本规范对涉及计算机系统安、全的各主要环节做了具体的说明，以便计算机系统的设计、安装、运行及监察部门有一个衡量系统安全的依据。 1．2范围 本规范是一份指导性文件，适用于国家各部门的计算机系统。 在弓I用本规范时，要根据各单位的实际情况，选择适当的范围，不强求全面采用。 二、安全组织与管理 2．1安全机构 2．1．1单位最高领导必须主管计算机安全工作。 2．1．2建立安全组织： 2．1．2．1安全组织由单位主要领导人领导，不能隶属于计算机运行或应用部门。 2．1．2．2安全组织由管理、系统分析、软件、硬件、保卫、审计、人事、通信等有关方面人员组成。 2．1．2．3安全负责人负责安全组织的具体工作。 2．1．2．4安全组织的任务是根据本单位的实际情况定期做风险分析，提出相应的对策并监督实施。 2．1．3安全负责人制： 2．1．3．I确定安全负责人对本单位的计算机安全负全部责任。 2．1．3．2只有安全负责人或其指定的专人才有权存取和修改系统授权表及系统特权口令。 2．1．3．3安全负责人要审阅每天的违章报告，控制台操作记录、系统日志、系统报警记录、系统活动统计、警卫报告、加班报表及其他与安全有关的材料。2．1．3．4安全负责人负责制定安全培训计划。 2．1．3．5若终端分布在不同地点，则各地都应有地区安全负责人，可设专职，也可以兼任，并接受中心安全负责人的领导。 2．1．3．6各部门发现违章行为，应向中心安全负责人报告，系统中发现违章行为要通知各地有关安全负责人。 2．1．4计算机系统的建设应与计算机安全工作同步进行。 2．2人事管理 2．2．1人员审查：必须根据计算机系统所定的密级确定审查标准。如：处理机要信息的系统，接触系统的所有工作人员必须按机要人员的标准进行审查。
软件项目开发计划规范 1 引言 1.1编写目的 ? 阐明开发本软件的目的； ? 说明编写这份项目开发计划的目的； ? 指明软件需求说明书所预期的读者。 1.2背景 ? 表示待开发的软件系统的名称、代码； ? 列出本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； ? C.说明该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 项目概述 2.1 工作内容 简要地说明在本项目的开发中须进行的各项主要工作。 2.2主要参加人员 扼要说明参加本项目开发工作的主要人员的情况，包括他们的技术水平。 2.3产品 2.3.1程序 列出需移交给用户的程序的名称、所用的编程语言及存储程序的媒体形式，并通过引用有关文件，逐项说明其功能和能力。 2.3.2文件 列出需移交给用户的每种文件的名称及内容要点。 2.3.3服务 列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持的级别和服务的期限。 2.3.4非移交的产品 说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。 2.4验收标准 对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。 2.5完成项目的员迟用限 2.6本计划的批准者和批准日期 3实施计划 3.1工作任务的分门与人员分工
软件开发部规章制度及软件项目管理方法 第一部分：软件开发部规章制度 一、日常工作制度： 1、关于休假、加班： 严格遵守公司的考勤制度，如有事，提前书面形式填写请假申请，批准后方可休假，如情况紧急不能提前填写请假申请，要电话请示上级领导，并在休假后补办请假手续。 开发部人员在项目紧张时尽量不提出请假申请。 研发人员原则上不安排加班，研发进度根据公司要求结合项目实际由项目组长负责制定，项目组长协调安排工作。项目组长根据进度需要安排的加班，加班费用由项目奖金中支出。公司工作需要硬性安排的加班，加班费有公司支出。相关标准按照国家相关制度执行。 2、开发部员工守则： 遵纪守法，忠于职守，克己奉公。 维护公司声誉，保护公司利益。 服从领导，关心下属，团结互助。 爱护公物，节约开支，杜绝浪费。 努力学习，提高水平，精通业务。 积极进取，勇于开拓，创新贡献。 3、员工工作日志： ●工作日志制度的目的是形成严格的工作跟踪和积累习惯，要求部门中项目负责人以下 人员按要求每日记录。 ●工作日志是部门员工的工作记录载体，起到部分绩效考核和浮动工资的确定依据的作 用。 ●工作日志包含每日计划和完成情况，每日工作始终时间，每日工作饱和度（5为最高， 1为最低，如为请假，请注明“事假”或“病假”），次周计划，以及问题、意见和建议。 ●工作日志严格要求每日填写，绝不允许在上交前统一填写。填写时注意清空原有内容。 如发现某些栏目多周雷同的情况，将进行警告。 ●每日工作内容如无特殊情况，至少需要写3条以上。叙述工作内容要求尽可能说明清 楚。不允许简单的如“修改错误”的描述。 ●工作日志严格要求在次周上午10:00前提交。不提交工作周报将适当予以惩罚。对于 未提交日志的人员，部门经理保证当周内口头通知。 ●工作日志以Email形式提交给项目负责人和部门经理。部门经理收到后保证第一时间
软件开发管理办法 修订记录 版本编号修订日期主要修订摘要 审核记录 审核人员属于部门审核日期 第一章总则 第一条为规范公司的开发管理流程，使各开发项目的管理进行标准化管理，特制定本管理办法。 第二条本管理办法详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 第三条本管理办法适用于计算机的自主软件开发项目。适用对象：软件开发管理人员，软件开发人员，软件维护人员，系统管理人员。 第二章组织机构与职责 第四条软件开发管理人员职责： 第五条软件开发人员职责： 第六条软件维护人员职责： 第七条系统管理人员职责： 第三章软件开发环境管理 第八条软件建设环境根据项目不同的时期，需要搭建生产运行环境、系统测试环境、系统开发环境三种不同的软硬件网络环境，便于生产、开发、测试等工作的安全、顺畅的进行。 第九条生产环境为系统维护管理人间管理的范畴，是系统正式运行，提交给各业务科室的正式环境，包括系统运行的硬件、网络等设备和进行集群处理的软件系统。 第十条测试环境为测试人员提供功能测试、性能测试的运行环境，包括运行环境模拟、测试工具服务器、测试工具客户端。 第十一条开发环境为系统开发人员提供系统开发需要的软件硬件环境，包括数据库服务器、应用服务器、开发工具客户端。 第十二条生产环境、测试环境、开发环境都存在自己独立的数据库服务器、应用服务器、客户端。在开发环境完成内部测试后，提交发布版本到测试环境中，由专门的测试人
员进行集成测试和功能测试。并进行一定的压力性能测试。在测试环境通过的版本在发布到生产环境。 第十三条生产环境与测试环境、开发环境需要物理隔离，保障生产环境的安全。 第四章开发过程管理 第十四条项目开发流程根据软件工程的流程，分为可行性研究与计划、需求分析、总计设计、详细设计、代码开发、系统测试五个阶段。 第十五条可行性研究与计划 1实施要求 1.软件开发部分析人员进行市场调查与分析，确认软件的市场需求 2.在调查研究的基础上进行可行性研究，写出可行性报告 3.评审和审批，决定项目取消或继续 4.若项目可行，制订初步的软件开发计划，建立项目日志 5.根据市场环境、公司软硬件情况预测十大风险因素 2交付文档 1.可行性研究报告* 2.初步的软件开发计划 3.十大风险列表* 4.软件项目日志* 第十六条需求分析 1实施要求 1.调查被开发软件的环境 2.软件开发提出的需求进行分析并给出详细的功能定义 3.做出简单的用户原型，与用户共同研究，直到用户满意 4.对可利用的资源（计算机硬件、软件、人力等）进行估计，制定项目进度计划（可 有相应的缓冲时间） 5.制定详细的软件开发计划 6.测试人员制订质量控制计划和测试计划 7.编写初步的用户手册 8.进行需求方案评审 2交付文档 1.软件需求说明书 2.更新后的软件开发计划 3.项目进度计划 4.计划
. . 1目的 明确公司信息化及信息资源管理要求，对内外部信息及信息系统进行有效管理，以确保各部门( 单位 ) 和岗位能及时、安全地识别、获取并有效运用、保存所需信息。 2适用范围 适用于公司信息化管理及信息收集、整理、转换、传输、利用与发布管理。 3术语和定义 3.1信息 有意义的数据、消息。公司的信息包括管理体系所涉及的质量、环境、职业健康安全、测量、标准 化、内部控制、三基等和生产经营管理中所有信息。 3.2企业信息化 建立先进的管理理念，应用先进的计算机网络技术，整合、提升企业现有的生产、经营、设计、制 造、管理方式，及时为企业各级人员的决策提供准确而有效的数据信息，以便对需求做出迅速的反应， 其本质是加强企业的“核心竞争力” 。 3.3信息披露 指公司以报告、报道、网络等形式，向总部、地方政府报告或向社会公众公开披露生产经营管理相 关信息的过程。 3.4 ERP 企业资源规划 3.5 MES 制造执行系统 3.6LIMS 实验室信息管理系统 3.7IT 信息技术 4职责 4.1信息化工作领导小组负责对公司信息化管理工作进行指导和监督、检查，对重大问题进行决策， 定期听取有关信息化管理的工作汇报，协调解决信息化过程中存在的有关问题。 4.2 ERP支持中心负责公司ERP系统运行、维护管理，每月召开ERP例会，分析总结系统运行情况， 协调处理有关问题，及时向总部支持中心上报月报、年报。 4.3信息中心是公司信息化工作的归口管理部门，主要职责： a) 负责制定并组织实施本程序及配套规章制度，对各部门( 单位 ) 信息化工作进行业务指导和督促； b)负责信息化建设管理，组织进行信息技术项目前期管理，编制信息建设专业发展规划并组织实施； c) 负责统一规划、组织、整合和管理公司信息资源系统，为各部门( 单位 ) 信息采集、整理、汇总和 发布等环节提供技术支持；对Internet用户、电子邮箱进行设置管理；统一管理分公司互联网出口； d) 负责计算机网络系统、信息门户和各类信息应用系统的安全运行和维护及计算机基础设施、计算
软件开发计划书项目名称：自由游戏平台
参与人员： 软件项目开发计划书自由游戏平台 目录： 1.引言 1.1编写目的 1.2编写背景 1.3定义 1.4参考资料 1.5系统动机 1.6标准.条件和约定 1.7编写文档的WBS 2.项目概述 2.1工作内容 2.2主要参加人员 2.3产品及成果 ①程序
②文件 ③服务 ④非移交产品 2.4验收标准 ①代码的验收 ②文档的验收 ③服务的验收 2.5完成项目的最迟期限 2.6本计划的审查者与批准者 3.实施总计划 3.1开发过程 ①需求分析 ②系统设计 ③编码及测试阶段 ④文档.产品部署 ⑤项目总结 3.2工作任务的分解 3.3接口人员 3.4进度 3.5预算 3.6关键问题 4.支持条件 4.1计算机系统支持 4.2需要用户承担的工作
4.3需由外单位提供的条件 5.专题计划要点 5.1开发人员培训计划 5.2测试计划 5.3质量保证计划 5.4人员配置计划 5.5客户培训计划 5.6安全保密计划
引言 编写目的: 为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，有必要以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容以书面的方式描述出来，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，项目团队开展和检查项目工作的依据。 本项目开发计划用于从总体上指导《自由游戏平台》项目顺利进行并最终得到通过评审的项目产品。本项目开发计划面向项目组全体成员。 背景 《自由游戏平台》主要功能是,为广大用户提供一个面对面的游戏平台；基本可包括所有保单系列产品，以及国内外比较流行的博彩游戏！该项目在计划中... 项目背景规划
软件开发管理办法 第一章总则 第一条为规范公司的开发管理流程，使各开发项目的管理进行标准化管理，特制定本管理办法。 第二条本管理办法详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 第三条本管理办法适用于计算机的自主软件开发项目。适用对象：软件开发管理人员，软件开发人员，软件维护人员，系统管理人员。 第二章组织机构与职责 第四条软件开发管理人员职责： 第五条软件开发人员职责： 第六条软件维护人员职责： 第七条系统管理人员职责： 第三章软件开发环境管理 第八条软件建设环境根据项目不同的时期，需要搭建生产运行环境、系统测试环境、系统开发环境三种不同的软硬件网络环境，便于生产、开发、测试等工作的安全、顺畅的进行。 第九条生产环境为系统维护管理人间管理的范畴，是系统正式运行，提交给各业务科室的正式环境，包括系统运行的硬件、网络等设备和进行集群处理的软件系统。 第十条测试环境为测试人员提供功能测试、性能测试的运行环境，包括运行环境模拟、测试工具服务器、测试工具客户端。 第十一条开发环境为系统开发人员提供系统开发需要的软件硬件环境，包括数据库服务器、应用服务器、开发工具客户端。 第十二条生产环境、测试环境、开发环境都存在自己独立的数据库服务器、应用服务器、客户端。在开发环境完成内部测试后，提交发布版本到测试环境中，由专门的测试人
员进行集成测试和功能测试。并进行一定的压力性能测试。在测试环境通过的版本在发布到生产环境。 第十三条生产环境与测试环境、开发环境需要物理隔离，保障生产环境的安全。 第四章开发过程管理 第十四条项目开发流程根据软件工程的流程，分为可行性研究与计划、需求分析、总计设计、详细设计、代码开发、系统测试五个阶段。 第十五条可行性研究与计划 1实施要求 1.软件开发部分析人员进行市场调查与分析，确认软件的市场需求 2.在调查研究的基础上进行可行性研究，写出可行性报告 3.评审和审批，决定项目取消或继续 4.若项目可行，制订初步的软件开发计划，建立项目日志 5.根据市场环境、公司软硬件情况预测十大风险因素 2交付文档 1.可行性研究报告* 2.初步的软件开发计划 3.十大风险列表* 4.软件项目日志* 第十六条需求分析 1实施要求 1.调查被开发软件的环境 2.软件开发提出的需求进行分析并给出详细的功能定义 3.做出简单的用户原型，与用户共同研究，直到用户满意 4.对可利用的资源（计算机硬件、软件、人力等）进行估计，制定项目进度计划（可 有相应的缓冲时间） 5.制定详细的软件开发计划 6.测试人员制订质量控制计划和测试计划 7.编写初步的用户手册 8.进行需求方案评审 2交付文档 1.软件需求说明书 2.更新后的软件开发计划 3.项目进度计划 4.计划
安全开发过程规范 一、SDL简介 SDL security development lifecycle（安全开发生命周期），是微软提出的从安全角度指导软件开发过程的管理模式。SDL是一个安全保证的过程，起重点是软件开发，它在开发的所有阶段都引入了安全和隐私的原则。自2004年起，SDL一直都是微软在全公司实施的强制性策略。 二、SDL步骤图 SDL中的方法，试图从安全漏洞产生的根源上解决问题，通过对软件工程的控制，保证产品的安全性。 美国国家标准与技术研究所（NIST）估计，如果是在项目发布后在执行漏洞修复计划，其修复成本相当于在设计阶段执行修复的30倍 三、SDL的步骤包括： 阶段1：培训 开发团队的所有成员都必须接受适当的安全培训，了解相关的安全知识，培训对象包括开发人员、测试人员、项目经理、产品经理等。 阶段2：安全要求 在项目确立之前，需要提前与项目经理或者产品owner进行沟通，确定安全的要求和需要做的事情。确认项目计划和里程碑，尽量避免因为安全问题而导致项目延期发布。 阶段3：质量门/bug栏 质量门和bug栏用于确定安全和隐私质量的最低可接受级别。 Bug栏是应用于整个开发项目的质量门，用于定义安全漏洞的严重性阈值。例如，应用程序在发布时不得包含具有“关键”或“重要”评级的已知漏洞。Bug栏一经设定，便绝不能放松。 阶段4：安全和隐私风险评估 安全风险评估（SRA）和隐私风险评估(PRA)是一个必需的过程，必须包括以下信息： 1、（安全）项目的哪些部分在发布前需要威胁模型？ 2、（安全）项目的哪些部分在发布前需要进行安全设计评析？ 3、（安全）项目的哪些部分需要并不食欲项目团队且双方认可的小组进行渗透测试？ 4、（安全）是否存在安全顾问认为有必要增加的测试或分析要求已缓解安全风险？ 5、（安全）模糊测试要求的具体范围是什么？ 6、（安全）隐私影响评级如何？ 阶段5：设计要求 在设计阶段应仔细考虑安全和隐私问题，在项目初期确定好安全需求，尽可能避免安全引起的需求变更。 阶段6：减小攻击面 减小攻击面与威胁建模紧密相关，不过它解决安全问题的角度稍有不同。减小攻击面通过减小攻击者利用潜在弱点或漏洞的机会来降低风险，减小攻击面包括：关闭或限制对系统服务的访问，应用“最小权限原则”，以及尽可能进行分层防御。 阶段7：威胁建模 为项目或产品面临的威胁建立模型，明确可能来自的攻击有哪些方面。
文档控制变更记录
目录 1范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 1.4与其他计划的关系 (1) 2引用文件 (2) 3术语和定义 (2) 3.1术语 (2) 3.2缩略语 (2) 4策划背景概述 (2) 5项目范围 (3) 5.1项目目标 (3) 5.1.1客户目标 (3) 5.1.2组织目标 (3) 5.1.3研究目标（可裁剪） (3) 5.2工作产品与服务 (4) 5.2.1工作产品 (4) 5.2.2服务 (6) 5.3验收标准 (6) 6组织机构与人员 (6) 7开发及运行环境 (8) 7.1软件开发环境 (8) 7.2软件运行环境 (8) 8重用分析 (8)
9软件开发管理 (9) 9.1软件开发方法及标准 (9) 9.2生命周期模型和项目过程定义 (9) 9.3工作任务拆分与估计 (9) 9.4项目进度和里程碑 (10) 9.5风险管理 (10) 9.6外部依赖 (12) 9.7相关方参与计划 (12) 9.8项目培训计划 (13) 9.9项目监督和问题处理 (13) 9.10数据管理计划 (14) 9.11重大事件处理 (14) 10里程碑及评审计划 (14) 11总体测试计划 (15) 12度量分析计划（可裁减单独成文）................. 错误！未定义书签。13安全保密. (16) 14附录 (17)
图 6-1项目软件研制组织结构 (7) 图 9-1软件技术流程图 (9)
表 3-1缩略语表 (2) 表 5-1交付软件 (4) 表 5-2需交付文档 (4) 表 5-3非交付文档 (4) 表 5-4过程记录 (5) 表 6-1软件项目人员配置 (7) 表 8-1重用分析表 (8) 表 9-1项目风险列表 (11) 表 9-2外部依赖跟踪表 (12) 表 9-3 相关方参与计划 (12) 表 9-4 培训计划 (13) 表 10-1软件正式评审计划 (14) 表 14-1 工作任务拆分结构（WBS） (18)
公司软件开发管理规定文件编码（008-TTIG-UTITD-GKBTT-PUUTI-WYTUI-8256）
X X公司软件开发管理制度 XX公司软件开发管理制度 版本： SDM审批： QA经理[时间] CTO [时间] 目录 1.目的和作用 3 2.适用范围： 3 3. 参考文件 3 4.适用对象 3 5.软件开发流程 4 可行性研究与计划 4 实施 4 文档 4 应交付的文档 4 提交步骤 4 需求分析 4 实施 4 要求 5 交付文档 5 审批 5 概要设计 5 实施 5 要求 6 交付文档 6 补充说明 6 审批 6
详细设计 7 实施 7 要求 7 文档 7 审批 7 实现 7 实施与要求 7 交付文档 8 审批 8 组装测试 8 实施 8 要求 8 交付文档 8 审批 8 确认测试 9 实施 9 要求 9 交付文档 9 补充说明 9 审批 9 发布 10 过程 10 文档 10 审核 10 交接 10 6. 附录1：项目文档清单 11 1.目的和作用
本流程详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 2.适用范围： 公司的软件开发产品均适用。 3. 参考文件 各种文档模板 文档命名规则 交接流程 4.适用对象 软件管理人员，软件开发人员，软件维护人员 5.软件开发流程 可行性研究与计划 实施 软件开发部分析人员进行市场调查与分析，确认软件的市场需求 在调查研究的基础上进行可行性研究，写出可行性报告 评审和审批，决定项目取消或继续 若项目可行，制订初步的软件开发计划，建立项目日志 根据市场环境、公司软硬件情况预测十大风险因素 文档 应交付的文档 1）可行性研究报告* 2）初步的软件开发计划 3）十大风险列表* 4）软件项目日志* 提交步骤 1) 适用于以后各阶段的文档提交。 2) 项目相关文档用sourcesafe进行版本管理，相关书写人员可根据各文档模板形式撰写文档，正式提交的文档以存入软件管理服务器相关目录时间为准。以后每次修改都应注明修改内容。 需求分析
软件开发项目管理制度 一、 总则 为保障公司软件开发项目的工作能有效、有序的执行，保证项目的开发质量，维护公司及开发人员的利益特制订本制度。 二、 组织 软件开发项目的实施以软件开发项目组的形式进行，项目组中设有项目责任人（即项目经理）、项目开发工程师、测试工程师、辅助人员等。一般情况下，一个项目组负责一个软件项目的开发工作。对于特大型的项目可以组织多个项目组分块进行实施。项目组人员各负其责，在项目经理的统一领导组织下共同完成项目实施工作。 三、 责任 项目经理： 全面负责项目的开发组织工作，包括需求分析、系统设计、人员分工、进度安排等。项目经理负责组织完成项目系统分析报告、系统总体设计报告、开发进度计划表、系统测试大纲等技术文档编写工作。负责开发进行中的进度检查，联合调试、技术资料文件收集等工作。 开发工程师： 按照项目经理的分工安排完成软件开发项目中自己所承担 的开发工作。负责完成模块设计报告的编写工作。协助完成 软件开发部 项目组 项目组 项目组 项目经理 开发工程师 测试工程师 辅助人员 项目经理 开发工程师 测试工程师 辅助人员
软件的安装调试及售后服务工作。 测试工程师： 按照项目经理的分工安排完成对开发软件的测试工作。负责 完成测试方案设计、测试报告的编写工作。负责完成软件使用手册、培训教材等的编写工作。完成软件的安装调试及售后服务工作。 辅助人员： 按照项目经理的分工安排完成项目开发中的辅助工作，包括文档录入、资料整理等。 四、 流程 软件开发项目应按照以下流程进行 整个软件开发项目可分为四个阶段： A 段： 设计阶段。完成系统分析、总体设计、进度计划等工作。以提交系统分 析报告、系统设计报告及开发计划进度表为完成标志。 立项 建立软件开发项目组 调研用户需求 编写项目系统分析报告 讨论确定系统设计方案 编写项目系统设计报告 制定开发计划 确定人员分工进度安排 分工进行模块设计 编写模块设计报告 软件编程、调试 软件组装、测试 完成测试报告 安装、试运行、培训 验收、售后服务 编写软件用户手册 工作总结 结束 A B C D
软件开发技术文档编写规范 在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 ◇可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 ◇项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 ◇概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 ◇详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 ◇用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 ◇测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 ◇开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 ◇软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 ◇软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 ◇软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。 1可行性分析报告 1 引言 1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象。