软件开发管理办法.docx
《软件开发管理办法.docx》由会员分享，可在线阅读，更多相关《软件开发管理办法.docx（50页珍藏版）》请在冰豆网上搜索。
软件开发管理办法
1目的和范围
本管理总则规定本公司软件研制管理所遵循的原则和方法，目的是通过加强开发管理达到如下结果。
1）提高软件质量和每一个项目开发过程的可控性。
2）优化开发资源结构，提高工作效率。
3）优化公司软件管理使产品尽早实现一体化，结构化。
4）通过良好的管理规范和结构使参与人员养成良好的工作素质。
5）引导和组织员工向规范化管理看齐，以使公司尽早实现国际人证。
本条例适用于质量管理组织、部门经理、项目经理等管理人员、系统分析员、系统设计和程序编码人。
2引用文件和术语
●GB/T11457-1995软件工程术语。
●GB/T16260-1996信息技术、软件产品评价、质量特性及其使用指南。
3定义
本篇术语尽量使用标准术语（GB/T11457-1995），另外还对本公司软件管理有如下术语说明：
由公司管理领导小组负责批准软件开发项目的立项。
由主管总经理、部门经理、质量管理员、项目经理、及有关的技术人员依据项目管理有关规定和各自的职能，协作完成。
3.3设计层
由系统工程师以及系统分析员组成。
3.4实施层
由软件开发技术人员组成的编码调试队伍。
全开发型
一个独立的软件开发项目；例如调度命令票的开发，用户提出的调度MIS系统的开发。
增加功能型
在本公司现有某软件系统的基础上新增加一个独立的功能。
3.7功能完善型
将本公司软件系统的已有功能完善。
如调度MIS系统中的电网计算程序中添加图形示意界面，以方便用户。
3.8查错测试型
对本公司的软件系统某种不正常现象进行跟踪查错，找出错误根源。
3.9个体软件过程（psp）
是一种可以用于控制、管理和改进个人工作方式的自我改善过程，是一个软件过程框架。
3.10软件的可靠性
请参看DB/T16260---1996“信息技术软件产品评价质量特性及其使用指南”附录A“质量子特性”
3.11软件的安全性
请参看DB/T16260---1996“信息技术软件产品评价质量特性及其使用指南”附录A“质量子特性”。
4．软件开发方法
4.1软件开发的基本流程及软件开发类型的分析
软件开发的基本流程
1）软件开发的立项，确定系统需求（目的及用途、功能、技术指标、开发及交付时间）；
2）软件的需求调研
3）软件的需求分析；
4）软件开发的概要设计；
5）软件开发的详细设计；
6）软件的实施（编程和单元测试）；
7）软件的组装测试、总体案例测试、性能及验收；
8）软件的交付投运；
9）软件的维护。
不同开发类型的软件开发流程
1）全开发型必须经过所述全部流程；
2）增加功能型必须经过所述全部流程；
3）功能完善型需经过所述的1），及3）—9）；
4）查错测试型需要遵循错误处理规范（见附录z）
软件开发过程的控制
1）软件开发流程的1），2），3），4），5），6）阶段都应该经过质量管理小组和开发顾问组（可以包括用户或公司聘请的有关开发专家）的评审。
2）评审分内部评审和正式评审。
3）内部评审由公司质量管理小组负责实施；正式评审由外部专家及公司的质量管理小组组成的评审委员会进行。
除全开发型的软件验收需要正式评审外，全开发型的软件开发的其它阶段的评审及其它类型的软件开发的各个阶段的评审均采用内部评审。
4）评审前有关人员必须准备好该阶段的技术文档资料，并填写“评审报告”（附表G-1）的有关部分，一并上交公司的质量管理小组申请评审。
5）无论内部评审或正式评审，均由公司的质量管理小组指定评审人选与评审日期，最后由公司总经理批准，同时还要递交一份评审工作安排方案要求总经理批准。
6）评审时首先由有关人员介绍被评审的内容；演示评审内容，再由评审小组测试评审内容，然后由评审小组提问题，有关人员答辩（需填写“软件评审问题记录”（附表G-2））；最后由评审小组给出“通过”和“不通过”的结论；若需要修改，应该填写“软件修改报告单”（内部评审可以适当简化评审程序，免去答辩过程）。
7）软件验收评审前需要填写“评审报告”进行申请外，软件评审要由评审小组或质量管理小组填写专门的软件评审报告（附表E）。
软件开发项目的确立
该阶段的规范依据公司相关的项目确立和项目下达的有关规定（项目的申请和确立规范）。
4.3软件需求分析
该阶段只适用于所述的全开发型及增加功能型的软件开发项目。
目的任务及实施步骤
＊由软件开发的部门经理与有关的设计人员进行软件的需求分析；
＊对于大的或全开发型的软件开发项目需要根据“软件开发项目任务书”进行必要的技术调查，写出《系统调研报告》，调研报告的书写和实施依据公司的系统调研报告实施规范；
＊分析和确定软件开发、运行的环境；
＊确定人机界面及接口说明；
＊编制项目开发计划，填写“软件开发项目安排书”（附表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阶段产品
＊概要设计说明书
＊软件测试计划（初步）
.3评审和批准
4.4.3.1评审
＊ 由负责该软件开发的技术人员向软件开发技术领导小组申报。
申报时应该填写“软件评审报告”（附表G-1）以及提交所列的必需具备的文档资料”。
＊评审的内容:
根据“软件开发任务书”及“软件需求规格说明”针对软件概要设计进行评审。
。
是否符合“软件开发任务书”及“软件需求规格说明”的要求
。
可行性：
是否能按时，按质，交付符合系统需求的软件
。
标准化：
其文档资料是否符合标准
。
可靠性，安全性和可维护性：
其概要设计是否考虑了“软件需求规格说明”中规定的可靠性，安全性和可维护性的要求
＊软件开发评审小组根据软件概要设计必需具备的文档资料及答辩情况进行讨论，并作出评审意见（通过或不通过）。
若有重大修改及评审不通过，应再次举行评审答辩；若有小的修改，需留待详细设计阶段一并进行评审。
4..2批准
＊ 软件开发技术领导小组将评审意见及全部资料提交总经理进行最后审批。
＊ 总经理将审批后，由软件开发人员继续进行软件的下阶段开发。
4．5详细设计
4.5.1目的及内容及步骤
＊详细设计必须符合概要设计说明的功能需求、框架结构、数据结构、数据流程的基本设计要求。
＊详细设计内容及步骤：
。
确定准确的数据结构（必须有准确详细的文字说明）；
。
进行完整的数据库的模式设计（必须有准确详细的文字说明）；
。
进行主程序的结构及过程的准确的描述（可使用文字及类ＰＡＳＣＡＬ语言进行描述）；
。
进行ＡＰＩ的准确的描述（输入参数，输出参数，功能描述）；
。
进行全部子程序或服务的逻辑结构准确的描述（可使用文字及类ＰＡＳＣＡＬ语言进行描述）；
。
进行全部事件（输出事件及接收事件）的描述（事件名，事件体，输出事件何时发出，接受事件的处理流程）；
。
完成详细设计说明书的编写（参看附录D）；
。
拟定子系统及功能模块的调试方案。
＊在软件详细设计过程中若发现框架设计需要修改，应提出修改方案并填写修改报告单。
阶段产品及文档资料
＊详细设计说明书；
＊如有修改，需要具备修改后的概要设计说明及修改报告单；
＊子系统及功能模块的测试计划。
评审；
＊对于中所述的全开发型及增加功能型的软件开发应该进行详细设计的评审,而其它两种类型的软件开发除非概要设计有重大修改一般不进行评审。
＊评审过程参看.1;
4.6软件实现
任务及实施步骤
＊根据软件详细设计说明，进行程序编制、静态分析、自测试、互测试。
阶段产品及文档资料
＊软件概要设计及详细设计文档资料及相应的修改报告单；
＊源程序；
＊自测试大纲及测试结果；
＊软件使用说明书和维护说明书初稿。
程序编制的规范
＊变量名：
必须与其代表的意义或其用途一致，可读（决不允许无实际意义的变量名，如a、b、c、I、j、k等）。
＊每个源程序（包括主程序及各个例程）的行数不得超过５００行。
＊每个源程序必须有程序头说明（程序名称，功能，上一级程序名，调用的子序名，输入参数，输出参数，编制人，完成日期，修改的历史记录）。
＊每个源程序必须有注释行（平均５－８行源程序有一行注释）。
软件的静态分析
该分析为使用人工或自动调试工具对程序代码逐条进行检查、分析，以发现编码错误的过程。
其内容为；
＊检查代码和详细设计的一致性；
＊检查代码的标准性，可读性；
＊检查代码逻辑代码的正确性。
软件的自测试和互测试
软件的自测试是在软件项目开发组内部进行的测试，以保证被开发的软件符合系统需求（功能需求及技术要求），检查软件的容错能力，检查软件的可靠性及安全性；为软件的正式验收测试提供依据和基础。
＊软件开发项目自测试首先可以在比较独立的环境，进行该开发软件的各个软件模块的功能测试。
＊功能测试之后，必须将被开发软件与整个软件系统组装到一起，在完整的运行环境下进行测试。
＊自测成功后，应该由技术部经理（或相应的软件开发部门经理）安排其他与该开发项目无关的技术人员按测试大纲进行互测；
＊自测试及互测试必须有测试大纲、测试用例及测试记录。
＊必须自测试及互测试成功之后，才允许提交正式的测试和验收。
目的及内容
＊根据“软件开发项目任务书”中规定的用户需求以及软件开发人员提交的“软件测试大纲”在相应的系统环境（该系统当前的正式版本）下对已经开发成功的软件进行严格测试。
＊审查软件产品必需具备的文档资料的规范性，完整性及正确性。
＊审查软件产品介质的正确性，完整性及一致性。
＊由软件评审小组对被审查的软件给予“审查评语”，合格的系统进行版本注册登记。
软件验收的执行者
＊执行者为软件开发技术领导小组及其委托的软件评审小组（软件正式验收的评审）、软件质量管理小组（软件产品审查）及版本管理小组（版本注册，复制，发行）。
软件验收的步骤及验收测试小组的组成
.1软件验收的步骤
＊由项目负责人填写“软件开发项目正式验收申请书”（附表E-1），交技术部汇总，由公司质量管理部进行审查，审查内容为：
。
程序编制的规范性（ 如变量命名，程序头，程序注释）；
。
测试大纲及自测试及互测试结果的正确性；
。
软件使用说明书的完整性及规范性；
。
若软件实现过程进行了软件概要设计或详细设计的修改,则应该审查是否具备相应的修改后的设计文档；
若审查不通过；需要技术部（或相应软件开发部门）进行相应的修补工作；然后再进行审查，直至通过为止；
＊审查通过后，由公司总经理批准，然后开始启动软件验收过程。
＊由软件开发人员编写测试大纲的并经评审小组评审；
＊由公司软件质量管理小组委托专门的技术人员建立测试环境；
＊由公司软件质量管理小组委托专门的技术人员建立测试小组按照测试大纲进行严格的测试；
＊测试中若出现重大的错误，则此次软件测试宣告失败；应修改后再进行重新全部测试；
＊测试中若出现一般的错误，可经修改后，进行专项补测；
＊测试小组应该提交软件测试报告；
＊由公司软件质量管理小组委托专门的技术人员建立文档资料审查小组进行文档资料的审查，并提交审查报告；
＊由公司软件质量管理小组委托专门的技术人员建立介质审查小组进行软件介质的审查，并提交审查报告；
＊测试结束由公司软件质量管理小组组织软件评审小组经过认真评议作出“审查评语”。
.2软件验收测试小组的组成
＊软件验收阶段应该组织三个测试审查小组；软件测试小组、软件文档资料审查小组、软件介质审查小组；
＊三个测试审查小组的人员主要由公司工程部技术人员组成
＊测试审查小组由公司公司软件质量管理小组与质管部负责组织
4.7.4软件测试大纲的编制及审定
＊软件测试大纲由负责软件开发的人员编写；
＊评审小组召集会议，听取大纲编写人员的介绍以及与会者的意见，经过讨论，并经大纲编写人员的修改补充，最后由软件评审小组讨论审定该测试大纲。
.1软件测试大纲的内容
详细的格式请参看附录H
4.7.5针对不同软件开发情况的测试要求
.1系统基础级的测试
＊系统的支撑平台的基本服务被修改或全开发型的软件开发项目属于此种类型；
＊必须将该软件系统全部程序（支撑平台及应用软件）进行编译链接。
＊对新的或经过重大修改的软件系统统（必须有数据源的仿真环境）进行所有功能的测试。
.2基本系统的测试
＊系统的支撑平台的部分软件被修改属于此种类型；
＊必须对该系统的有关部分（支撑平台软件）进行编译链接。
＊在当前被修改的软件系统的版本（必须有数据源的仿真环境）下对开发修改的部分及其它应用软件进行测试。
.3应用系统的测试
＊系统的应用软件进行了重大修改或开发了新的应用软件属于此种类型；
＊ 必须对该应用软的有关部分进行编译链接。
＊在当前系统的版本（必须有数据源的仿真环境）下对开发修改的应用软件及其它有关应用软件进行测试。
.4一般修改的测试
＊系统的应用软件进行了一般修改属于此种类型；
＊必须对有关部分进行编译链接。
＊在当前系统的版本（除去开发修改的部分）下对修改的应用软件进行测试。
4.7.6软件测试的一般性合格标准
＊符合该开发项目的“软件需求规格说明书”中规定的用户的功能需求及性能需求。
＊符合测试大纲中规定的各项功能。
＊新开发修改的项目的可靠性标准：
。
人机界面调用１０００次不故障退出，不产生coredump或死机。
。
支撑平台的分布式管理及数据库的基本服务连续访问１００００００次不出错误，不产生coredump或死机。
。
支撑平台的分布式管理及实时数据库的基本功能（如主备机自动切换，子系统的切换，子系统及进程的退出服务和启动，双以太网的自动切换；数据库的安装更新，数据库模式的建立和修改，数据库的同步，实时数据库与关系数据库的同步及捆绑；等等）连续调用１０００次不发生错误，不产生coredump或死机。
。
应用系统在支撑环境下（必须有前置机的仿真环境）连续运行72小时不发生功能性错误，不产生事件堆积，不故障退出,不产生coredump或死机。
软件文档资料
.1文档资料应涵盖的范围
＊该软件开发项目的“软件开发任务书”、“软件需求规格说明”及对上述文档的修改资料；
＊该软件开发项目的概要设计及详细设计的全部资料；
＊该软件开发项目的全部源程序；
＊该软件开发项目的自测试和互测试记录；
＊该软件开发项目的用户使用手册和维护手册；
＊该软件开发项目的测试大纲；
＊资料的详细清单。
.2审查文档资料的手段
＊审查人员检查文档资料的规范性，完整性。
＊可以使用专门的软件去测试源程序的规范性。
软件介质的审查
.1软件介质的定义
＊ 软件介质指的是完整的记录软件的可运行模块及其安装说明的磁带，软盘，光盘。
4.7.8.2软件介质合格的标准
＊介质记录了软件系统全部可运行模块及其安装说明或记录软件系统的升级模块及其安装说明；用此介质安装之后，该软件系统可以立即可靠的运行。
＊该介质应该与提供的用户手册完全一致。
评审
＊软件验收阶段需要经过两次评审；
＊第一次评审是对验测试收大纲的评审；
＊第二次评审是该验收阶段的最终评审；其评审内容为：
。
软件测试报告
。
软件文档资料的审查报告
。
软件介质的审查报告
＊评审结果：
通过或不通过。
软件的交付方式
＊将经过正式验收的软件由开发部或相应的软件开发部门交付质量管理部进行注册登记；
＊由质管部及开发部或相应的软件开发部门共同向工程部门交付经过正式验收的软件系统，以便工程部进行系统集成及进一步测试
软件交付后的完善
＊软件交付工程部门进行系统集成及测试后或进行工程的工厂验收和现场验收后若出现若干不符合用户需求的问题或错误，应该由工程部门填写“软件问题报告单”（针对软件错误和不符合用户需求的问题），并交部门经理汇总；若问题可以由本部门解决，则在本部门安排解决；若本部门不能解决的问题，交公司技术领导小组统一安排软件的修改完善工作。
4.9软件的维护及完善
维护请求的提出
＊维护请求由工程部门以”软件问题报告单”的形式提交并交部门经理汇总；若问题可以由本部门解决，则在本部门安排解决；若本部门不能解决的问题，交公司技术领导小组，统一安排解决。
维护计划的形成
＊对于小的软件问题可以不经过评审,直接形成《软件开发项目任务书》下达给技术人员.
＊对于较大的软件问题应经过评审形成《软件开发项目任务书》然后下达给技术人员（参考”软件开发项目的确立”）.
维护的过程
＊对于”增加功能型”的维护,实际是一个较为独立的软件开发项目,应该按—的阶段进行软件的开发
＊对于”功能完善型”及”查错调试型”的维护,实际是一个修改软件的过程,应该按以下步骤进行：
。
维护人员对维护需求进行分析，修改“软件需求规格说明”或“软件概要设计说明”或“软件详细设计说明”，评审小组对其修改进行评审，然后维护人员根据评审意见进行再修改、再评审，直到通过。
。
维护人员根据修改的设计进行源程序的代码修改及静态分析、自测试、互测试，软件验收。
。
原则上，凡是对现场运行的软件的修改，均应该在实验室先进行模拟修改和测试；成功后，经过项目经理或部门经理批准后，再到现场进行修改；如因为特殊原因，在未经过实验室修改和测试，而对现场运行的软件进行修改，应该事先及时与项目经理或部门经理联系，说明修改的内容及理由，经过同意后，再慎重的进行修改和测试；事后必须填写〈软件问题报告单〉及〈软件修改报告单〉或〈工程修改报告单〉，并经过项目经理或部门经理审查批准；
。
进行维护后，都应该及时经过质管部的注册登记调整软件版本号、保存相应的软件介质，以保证软件版本的一致性。
附录A软件立项报告书写格式
北京思创公司软件开发项目
立项报告
项目名称:
课题名称：
起止时间：
年月至年月
年月日
1目的和意义
1.描述与软件开发内容紧密相关的产品的实际水平和今后的发展方向；
2.阐述课题成果对该现状和技术发展的作用；
3.分析成果应用和推广的途径；
4.分析成果推广后的直接和间接效益。
2国内外研究水平综述
1.与软件开发内容紧密相关的技术发展历史的简要回顾；
2.国内外研究水平的现状和发展趋势；
3.介绍国外研究机构或者公司对本课题的研究情况；
4.介绍国内其他研究单位对本课题的研究情况。
3．课题的理论或实践依据
1.软件开发内容的原理简述；
2.软件开发内容的理论或者实践依据；
3.软件开发的技术关键和难点。
1.软件开发内容的详细说明（可分专题或按内容序号描述）。
2.要描述具体的开发步骤，现场试验的地点和试验计划，需要建设的试验环境；
3.理论研究和试验内容与软件开发总目标的因果关系；
4.写明理论和试验研究的工作量；
5.需要多家单位共同承担的课题，需要写明各家的分工、职责和提供的成果，如何组织和协调；
6.需要与国外合作，要写明与外方的合作方式、知识产权和成果分享的范围，及以前的工作联系；
7.注明本软件开发需要购买设备的型号、产地、性能及需要购买的原因；
8.外委的工作内容和工作量；
5．预期目标和成果形式
1.阐明软件开发预期达到的目标；
2.明确叙述软件产品成果提供的形式；要求成果提供的形式能够被其他技术人员掌握，使成果的使用权具有可转移性。
6试验单位或依托工程情况
1.如需借用其他单位的试验环境，说明选定试验单位的落实情况；
2.如需结合依托工程进行试点研究，说明依托工程及其与本软件开发结合的情况。
7软件开发所需的条件
对课题负责人的要求；
对课题承担人员的专业、特长、工作水平的要求；
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）。
数据库模式的描述
升级会员 