软件开发过程规范（模版）

第一篇：软件开发过程规范（模版）

软件开发过程规范

1目的为了规范软件研发各个阶段的开发行为，特制定此规范。

2适用范围

本规范适用于研发中心软件产品研发从立项，到开发实施、测试、结项的各个阶段，规定了各开发阶段的文档编制、代码编写和资料备份内容与要求。3术语和缩写

研发项目干系人：公司内部与研发项目有关联的任何人。

项目计划周期：从项目立项到计划完成时间的实际工作日数。

项目实际周期：从项目立项到实际完成时间的实际工作日数。

项目质量目标：项目允许出现的总的缺陷数的加权平均值。

项目实际质量：项目实际出现的总的缺陷数的加权平均值。

软件缺陷：在测试过程中被发现的软件bug，按照不同的严重程度分为四级；一级，系统崩溃，无法自动恢复，加权系数为100。

二级，系统功能无法实现或性能指标无法达到，但不影响其他功能的使用，加权系数为2。

三级，系统功能实现不完整，加权系数为1。

四级，不影响系统功能和性能的小错误，忽略此错误系统可正常运行，加权系数为0.5。

加权缺陷数量：测试中出现的各种缺陷的数量乘以其对应的加权系数，求和。4内容和要求

4.1研发立项

4.1.1立项申请，产品研发经过申请后才能立项，立项申请人可以是公司员工，也可以是公司各职能部门。

4.1.2立项申请人或委托其部门负责人召集相关人员讨论通过，确定项目经理并初步确定项目组成员。

4.1.2.1《研发立项申请书》由项目经理负责编制。

4.1.2.2项目编号规则为，软件项目：PS+编制日期；（硬件项目：PH+编制日期）。如：PS20070902。

4.1.2.3《研发立项申请书》要规定开发的产品的具体名称，以及所属各个系列的规格型号定义。

4.1.2.4《研发立项申请书》规定开发的产品的属性，包括功能详细描述，性能要求详细描述和稳定性要求详细描述。

4.1.2.5《研发立项申请书》明确项目经理和项目组成员。

4.1.2.6《研发立项申请书》明确项目的开始日期和计划完成日期。

4.1.2.7《研发立项申请书》概要说明项目开发的资源需求，包括硬件设备、软件工具、场地环境等。

4.1.2.8《研发立项申请书》确定项目的质量目标，包括各级缺陷的数量和测试周期，所制定的质量目标不允许有一级缺陷。

4.1.2.9《研发立项申请书》的编制格式参照《研发立项申请书模板》。

4.1.3《研发立项申请书》由研发项目经理、主管软件的研发经理、营销中心经理认可，主管研发副总经理最终确认。

4.1.4内容变更：研发项目干系人可对申请对《研发立项申请书》的内容进行变更，变更后按申请的流程进行签字确认，变更后的内容重新填写《研发立项申请书》并附在原申请书后。项目组成员的变更由研发内部掌握，不必进行变更申请。变更可在结项前的任何阶段提出。

4.1.5项目撤销，如遇重大变故造成所研发的项目已经无实际意义或其他原因需要立即停止，可申请撤销，申请人需是项目干系人，并具有中心经理以上的级别，申请人负责编写《研发项目撤销申请书》,说明撤销原因，撤销申请需得到项目经理、主管软件的研发经理、营销中心经理和主管研发副中经理认可，经由总经理批准后生效。撤销申请可在结项前的任何阶段提出。

4.2研发

4.2.1研发立项确定后，项目经理需编写《项目研发计划书》。

4.2.1.1《项目研发计划书》初步制定项目开发的任务列表和模块划分，以及项目组人员的模块归属和工作时间安排。

4.2.1.2《项目研发计划书》可以用通用的项目管理工具来完成，编制格式由项目经理确定，推荐使用Microsoft Project。

4.2.1.3《项目研发计划书》由项目组成员认可。

4.2.1.5项目经理可根据实际情况和设计的深入，随时变更《项目研发计划书》。

4.2.1.6主管软件的研发经理可抽查《项目研发计划书》的编制和实施情况，并给出改进建议。

4.2.2研发设计

4.2.2.1《软件需求分析说明书》

4.2.2.1.1软件项目需编制《软件需求分析说明书》。

4.2.2.1.2《软件需求分析说明书》由项目经理或其委托人编制。

4.2.2.1.3《软件需求分析说明书》确定整个系统的物理结构和部署要求，并根据系统的物理结构进行模块划分，确定各个模块的功能范围和模块间的接口方式。详细说明系统规模要求和运行环境限制，并指出系统运行所需资源的要求。明确开发和系统运行所需软硬件资源的要求。确定项目进行一次全面测试所需要的测试人员人数和测试周期。《软件项目需求分析说明书》的格式参照《软件项目需求分析说明书模板》。在软件需求分析过程中，如果软件有用户界面，要在此阶段进行界面的初步设计，为了提高效率，界面草图的绘制不限定形式和格式。

4.2.2.1.4《软件需求分析说明书》由项目组全体成员认可，主管软件的研发经理最终确认。

4.2.2.1.5《软件需求分析说明书》的变更，在开发过程中，项目组成员可提出对《软件需求分析说明书》的变更申请，变更的范围限于不能违背《研发立项申请书》的要求，即不能有涉及到《研发立项申请书》变更的内容，如果有，需要做《研发立项申请书》变更的流程。《软件需求分析说明书》变更的主要目的是修正其中的错误，或者经过变更可提高产品的品质或性能指标或缩短产品的研发周期。《软件需求分析说明书》的变更需得到项目经理的同意，必要时由项目经理召集相关技术人员和项目组成员召开简短的技术会议进行论证。项目经理将变

更后的内容形成新版本的《软件项目需求分析说明书》，由主管软件的研发经理最终确认。

4.2.2.2《软件概要设计说明书》

4.2.2.2.1软件项目需编制《软件概要设计说明书》。

4.2.2.2.2《软件概要设计说明书》由项目经理或其委托人编制。

4.2.2.2.3《软件概要设计说明书》确定整个系统的逻辑结构，并对需求分析中各物理模块进行逻辑模块划分，详细描述各逻辑模块的业务规则和模块之间的接口以及重要的内部接口，确定系统级的全局变量和数据结构，确定各逻辑模块所包含的程序文件名称和使用的开发工具，描述每个文件中所包含的函数功能。确定数据库的类型和所有数据表名称及数据表的用途，确定数据库的访问方式。详细描述系统的配置方式。如果软件有用户界面，要对界面进行详细设计，确定所有界面的名称、规格及界面上的元素类型及功能，界面设计可在开发工具中直接绘制，也可采用其他绘图方式，但在概要设计文档中要保留图示并进行详细说明。格式参照《软件项目概要设计说明书模板》。

4.2.2.2.4《软件概要设计说明书》由项目组全体成员认可，主管软件的研发经理最终确认。

4.2.2.2.5《软件概要设计说明书》的变更，在开发过程中，项目组成员可提出对《软件概要设计说明书》的变更申请，变更范围限于不得违背《研发立项申请书》和《软件需求分析说明书》的要求，所涉及的变更不至于影响到《研发立项申请书》和《软件需求分析说明书》的变更，如果有，需要做《研发立项申请书》的变更流程或者《软件需求分析说明书》的变更流程。《软件概要设计说明书》变更的主要目的是修正其中的错误，或者经过变更可提高产品的品质或性能指标或缩短产品的研发周期。概要设计说明书的变更需得到项目经理的同意，必要是由项目经理召集相关技术人员和项目组成员召开简短的技术会议进行论证。项目经理将变更后的内容写入新版本的《软件项目概要设计说明书》，主管软件的研发经理最终签字确认。

4.2.2.3软件详细设计

4.2.2.3.1软件详细设计由项目经理指派，项目组成员分担完成。

4.2.2.3.2软件项目详细设计的内容及格式要求，软件项目的详细设计根据《软件概要设计说明书》划分的各个逻辑模块包含的程序文件，确定每个程序文件中所包含的函数的详细描述，要求有函数的功能描述、输入输出说明、使用规则和限制，如有必要，还可以描述函数的实现流程。详细描述软件中所有全局变量的格式、初始值、用途和使用规则。详细描述软件中所有的数据结构和类结构。详细描述数据库中的数据表，确定数据表的的每个字段，以及数据表之间的关系，确定所有的视图、触发器和存储过程。详细设计文档不做具体的格式要求，为了提高研发效率，可以把详细设计作为代码的一部分，直接在程序中编写，编写时要遵循《研发中心软件编码标准》的规定。

4.2.2.3.3项目经理负责组织对详细设计进行审核，审核方式可采用项目经理主审和项目成员互审相结合的方式，主要审核详细设计和概要设计及需求分析的符合性，及详细设计的正确性。主管软件的研发经理可组织相关技术人员对详细设计情况进行抽查。

4.2.2.3.4详细设计的变更，可在项目开发的任何时段进行，由项目成员在得到项目经理的口头同意后进行，要在变更处做好变更记录。

4.2.2.4质量控制

4.2.2.4.1项目组内部互审，在项目的开发过程中，项目经理可组织项目组成员对编制的代码进行互相审核，目的是审查代码是否符合《研发中心软件编码标准》的要求，并在联调前找到代码中的缺陷，审核时要做好审核记录，内容为代码的编写人、审核人、缺陷位置、缺陷描述和改进建议，格式由项目经理决定。根据项目的具体情况，项目经理有权决定不进行代码的互审。

4.2.2.4.2研发中心内部抽查审核，在项目的开发过程中，主管软件的研发经理可组织相关人员对项目组的开发质量进行抽查审核，被审核的代码模块由研发经理确认，审核的主要目的是验证的代码书写的规范性和与设计的符合性。在评审中发现问题，主管软件的研发经理可口头通知项目经理进行整改，问题严重时，可对项目组下达《软件整改通知单》，通知项目组进行整改。具体使用何种方式由主管软件的研发经理确定。《软件整改通知单》下达后，按比例扣除项目组的项目奖金，扣除办法参见《研发软件项目奖金发放制度》。

4.2.2.4.3项目组内部集成验证测试，项目经理可在代码完成后组织内部集成测试，并同时指派项目组成员进行《软件使用说明书》的编制，在内部集成测试结束，《软件使用说明书》完成后，项目经理可申请提交软件的a测试。

4.2.2.4.4《a测试申请书》，项目经理负责编制《a测试申请书》，格式参照《a测试申请书模板》。编制完毕后，与《软件使用说明书》一起提交给主管软件的研发经理进行审核确认，主管软件的研发经理签字同意后，指定项目的测试人员，进行a测试。

4.2.2.4.5测试人员根据《研发立项申请书》和《软件使用说明书》的要求与内容，编制《软件测试大纲》，确定要测试的具体项目以及对这些项目的要求，《软件测试大纲》编制完成后要由项目经理认可，主管软件的研发经理确认。同时项目组负责协助测试环境的搭建。

4.2.2.4.6在一轮测试结束后，测试人员出具《项目测试报告》。项目组对测试出的问题进行修改，然后再申请新一轮的测试，新的一轮测试由项目经理决定是进行验证性测试还是完整测试，如果是验证性测试，可由项目经理确定测试内容范围并和测试经理协商测试周期，循环上述过程直到项目经理认为可以结束测试。为了保证测试质量，要求最后一次测试必须是完整测试。测试结束后，测试人员要编制《测试过程总结报告》。

4.3研发结项

4.3.1测试结束后，项目经理可决定对项目进行结项提交。

4.3.2项目经理负责编制《研发结项申请书》，格式参照《研发结项申请书模板》。

4.3.3《研发结项申请书》要对所存留的问题进行详细描述。

4.3.4《研发结项申请书》说明项目的实际开发周期，与计划周期的差异将作为项目奖金的评定依据。

4.3.5《研发结项申请书》要说明项目质量目标的实现情况，根据《测试过程总结报告》统计出项目的实际质量，与计划质量目标的差异将作为项目奖金的评定依据。

4.3.6《研发结项申请书》中所存留问题部分的内容需由此项目的实际测试人员进行确认。

4.3.7《研发结项申请书》由项目经理、主管软件的研发经理、营销中心经理、技服中心经理认可后，由主管研发副总经理最终确认。

4.3.4项目提交后，项目经理出具《软件项目信息统计表》，由主管软件的研发

经理认可，主管研发副总经理最终确认，作为项目奖金分配的依据。

4.4技术资料的管理与备份

4.4.1项目经理负责技术资料的管理与备份，备份内容包括项目所涉及的文档、代码和其他相关技术资料。

4.4.2项目立项后，项目组要在代码管理服务器上建立专门的项目目录。

4.4.3在研发过程中，项目组不定期的向代码管理服务器进行代码备份，备份时机由项目经理决定。

4.4.4项目提交测试前要进行一次完整备份。

4.4.5项目结项后，要进行一次完整备份，并将最终项目内容刻录光盘备档。

4.4.6备档后的光盘由主管软件的研发经理统一管理。

4.4.7在研发过程中，纸质文档由项目经理负责管理，项目结项后提交到主管软件的研发经理备档。

4.4.8由于项目组备份不及时和备份管理不到位造成项目资料丢失，致使开发周期延误的，每发生一次按比例扣发项目经理的项目奖金，造成重大损失的，全部扣发项目经理项目奖金，并根据具体情况追究其责任,是否为重大损失由主管软件的研发经理确认。奖金的扣发办法参照《研发软件项目奖金发放制度》。5职责和权限

5.1主管研发副总经理负责本规范的编制、发布、维护与解释。

5.2主管软件的研发经理负责推动和监督本规范的实施。

5.3公司所有员工可对本规范提出修改意见。

6历史记录

本规范于2007年9月25日编制完成，形成V1.0版。

V1.0于2007年11月1日开始施行

第二篇：规范软件开发过程——软件配置管理实践

规范软件开发过程——软件配置管理实践

2010-05-19 来源：网络

随着软件系统的规模、复杂度日益上升，软件开发过程管理已经成为保证软件系统开发效率、质量、成本的关键性因素。作为软件开发过程中质量保障的重要组成部分，行之有效的软件配置管理（以下简称SCM，Software Configuration Management）能够显著提高软件开发组织的自身能力、提高软件开发过程的完整性，以及降低软件开发的风险。

软件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983对SCM的定义有不同的描述。ISO9000定义SCM为“一个管理学科，它对配置项的开发和支持生命周期给予技术上和管理上的指导。配置管理取决于项目的规模、复杂程度和风险大小”。

CMM2将SCM定义为一个关键过程域KPA，是“贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现（4）向其他可能有兴趣的人员报告变化。”。SCM包括了配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计等活动，其中以版本控制最为核心和关键。

数据集中工程软件配置管理策略

1、数据集中工程项目背景

中国建设银行数据集中工程的目标是通过建立总行级的数据中心，向全行38个一级分行、20000多个网点提供完整的核心金融服务。其核心应用系统DCC-CCBS包括主机、前置、前端三大部分。主机应用部分部署在总行级数据中心，前置应用部分部署在数据中心前置通信网关、各一级分行业务大前置，前端部分部署在网点。

DCC-CCBS项目的SCM需要实现开发、发布、部署的全过程软件配置管理。开发过程SCM的核心是系统源码版本管理；发布过程的SCM核心是系统目标码版本管理；部署过程以确保系统目标码版本在数据中心、一级分行、网点和外系统的正确部署为首要目标。

2、开发过程软件配置管理

系统源码版本除系统源程序、参数外，还包括需求规格说明书、系统总体架构设计说明书、主机/前置/前端系统结构设计说明书、各子系统的详细设计说明书、各子系统的对外接口规范、业务操作手册、系统使用手册、系统安装维护手册等文档。根据配置项的不同属性，经过评审，形成需求基线、设计基线和源代码基线等不同的基线。开发过程SCM按照子系统的性质，分为主机、前置、前端三部分独立管理。

DCC-CCBS项目总体组负责整个需求和变更的控制。通过审批的需求按照功能分布分解为主机、前置、前端的子需求，再由各部门分别管理和实现。环境及版本控制小组负责向各部门提出形成“系统基线”的要求，以同步主机、前置、前端的源码版本。

3、发布过程软件配置管理

发布过程的系统目标码版本包括系统目标码（执行码）、系统参数及相关文档等。按照用途，系统目标码版本可分为测试版和正式版。以前置平台为例，发布过程SCM的主要活动包括：构建环境管理，保证编译环境的纯净性和正确性；

构建过程管理，保证构建过程的自动化操作，及其正确性和完整性；

版本编号管理，统一版本命名规则，确保目标码版本号的唯一性和可追踪性；

目标码版本生成管理，从各版本管理工具系统收集、整理、打包相应的目标码、参数和文档，形成完整的或部分（补丁）的目标码版本；

配置状态检查，检查目标码版本包中内容的正确性、完整性和一致性；

4、部署过程软件配置管理

部署过程SCM的主要任务是：建立安全、可靠和迅速的传输流程和传输渠道；建立目标码版本记录和追踪机制、版本运行时刻检查机制和版本恢复机制；确保正确的版本、按照正确的渠道、在规定时间递交到正确的用户并生效。

在DCC-CCBS生产环境中，软件开发中心将通过数据中心版本管理系统发布各单位所需的目标码版本，各单位在版本管理系统和数据传输通道的支持下，实现版本/补丁的主动分发、查询、下载和生效。

软件配置管理实施经验

1、树立正确的企业配置管理意识

SCM是一门管理学科。归根结底，其关键是“管理”，然后才是“软件配置”。项目级SCM能否成功实施，与企业的软件配置管理目标、策略、能力、组织和资源息息相关。

2、提高全员的配置管理素质

SCM是规则和流程的集合，需要依靠流程中所有部门和人员共同的支持和努力。任何环节上的疏忽和懈怠，都将直影响SCM的实施效果。

3、采用合适的工具

功能强大的或昂贵的工具未必是合适的工具。往往20%的功能即可解决80％的配置管理问题。目前比较流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在选择具体工具时，往往需要考虑以下因素：（1）工具将要使用的范围；（2）工具自身的功能、稳定性、扩展行，以及对环境的要求；（3）工具使用的复杂度；（4）工具与其他流程和工具的集成度和交互性；（5）工具的投资和维护费用。

4、及时的检查和梳理

大系统开发过程中，配置管理往往采用分步离散管理方式，因此保证整个系统配置管理的完整性成为一件精密细致的工作，需要投入大量人力及时修订基线，防微杜渐，避免混乱，以满足对配置管理正确性、完整性和及时性的要求。

5、系统化思考、分步实施、持续改进

SCM不是一项孤立的管理活动。企业的战略目标、管理能力、文化背景、组织结构，项目的规模、性质、技术、人员等都是影响SCM决策的重要因素。因此需要在项目乃至企业的整体环境中系统的考虑SCM的实施策略和方法。

通过分阶段实施量化的、渐进的配置管理目标，可以避免由于引入复杂管理流程所造成的混乱，有利于方便灵活地优化配置管理流程。同时，阶段性目标的实现将有助于整个团队提高士气、增强信心，并逐步提高开发队伍的配置管理素质。

第三篇：软件开发过程及岗位职责

软件开发过程及岗位职责

本文主要讲述如何组织开发软件项目，使之更加快速、有效的完成。并分成以下几个阶段进行详细讲述：项目计划阶段、需求分析阶段、软件开发阶段、测试阶段、管理软件开发过程、各参与角色的具体职责描述及对人员的要求。最后提供了一些文档标准参考。

本开发过程可以作为中小型（3-7人）软件项目的开发指南，而大型软件项目使用RUP会更好。

总体流程如下：

计划阶段－》需求分析阶段－》软件开发阶段－》测试阶段－》完成一、项目计划阶段

项目计划草案和风险管理计划作为第一步，当有一个商业机会后，根据公司高层负责制定的初步商业计划书来完成项目的计划草案，确定、分析项目风险并确定其优先级，还要制定风险解决方案。本阶段的目的是确立产品开发的经济理由。

当确定开发之后则制定软件开发计划、人员组织结构定义及配备、过程控制计划。

（1）项目计划草案

项目计划草案应包括产品简介、产品目标及功能说明、开发所需的资源、开发时间和里程碑。

（2）风险管理计划

也就是把有可能出错或现在还不能确定的东西列出来，并制定出相应的解决方案。风险发现得越早对项目越有利。

（3）软件开发计划

软件开发计划的目的是收集控制项目时所需的所有信息，项目经理根据项目计划来安排资源需求并根据时间表跟踪项目进度。项目团队成员根据项目计划以了解他们的工作任务、工作时间以及他们所依赖的其他活动。

可将计划分成总体计划和详细计划，总体计划中每个任务为一个里程碑，详细计划中必须将任务落实到个人。

软件开发计划还应包括产品的应收标准及应收任务（包括确定需要制订的测试用例）。

（4）人员组织结构定义及配备

常见的人员组织结构有垂直方案、水平方案、混合方案。垂直方案中每个成员充当多重角色。水平方案中每个成员充当一到两个角色。混合方案则包括了经验丰富的人员与新手相互融合。具体选择根据人员实际技能情况进行选择。

（5）过程控制计划

过程控制计划的目的是收集项目计划正常执行所需的所有信息，用来指导项目进度的监控、计划的调整，确保项目按时完成。

二、需求分析阶段

需求分析阶段的目的是在系统工作方面与用户达成一致。

（1）软件需求规约

详细说明系统将要实现的所有功能。

（2）用户界面原型

可以有三种表示方法：图纸（在纸上）、位图（绘图工具）、可执行文件（交互式）。

三、软件开发阶段

本阶段从物理上实现目标系统。采用了面向对象方法。

（1）软件架构

说明软件的组织结构、部署结构及运行环境。

（2）类设计

定义类之间的关联和类的属性、方法。

（3）数据库设计

定义数据库表之间的关联和各个表的字段。

（4）编码和单元测试

按照设计文档进行编码，每完成一个模块应进行单元测试。

（5）集成系统

按软件组织结构的要求将各个子系统组合起来。

四、测试阶段

测试的目的是在发布之前找出程序的错误。包括：核实每个模块是否正常运行（参考设计文档）、核实需求是否被正确实施（参考需求文档）。

（1）测试计划

收集和组织测试信息，为测试工作提供指导。

（2）测试数据

尽量使用真实数据。

（3）测试报告

记录测试结果，详细描述问题，提出解决办法。

（4）帮助文件和用户操作手册

五、管理软件开发过程

有以下几方面地工作：

（1）组织会议

讨论会议、总结会议等。

（2）评审程序

对各个阶段的工作结果进行审核。

（3）协调人员

（4）配置管理

使用一些配置管理工具进行开发文档管理，如：Visual Sourcesafe，Teamsouce等

六、各参与角色的具体职责描述及对人员的要求

（1）项目经理

职责：

1、制定产品的目标。

2、制定各个工作的详细任务表，跟踪这些任务的执行情况，进行控制。

3、组织会议对程序进行评审。

4、综合具体情况，对各种不同方案进行取舍并做出决定。

5、协调各项目参与人员之间的关系。

人员要求：

对产品有激情，具有领导才能。

对问题能正确而迅速地做出确定。

能充分利用各种渠道和方法来解决问题。

能跟踪任务，有很好地日程观念。

能在压力下工作。

（2）系统分析员

职责：

1、了解用户需求，写出《软件需求规约》。

2、建立用户界面原型。

人员要求：

担任系统分析员的人员应该善于协调，并且具有良好的沟通技巧。担任此角色的人员中必须要有具备业务和技术领域知识的人才。

（3）设计员

职责：

1、定义类的方法和属性以及各个类之间的关联，画出类图。

2、进行数据库设计。

人员要求：

掌握面向对象分析与设计技术，统一建模语言(UML)。

（4）程序员

职责：

按项目的要求进行编码和单元测试。

人员要求：

良好的编程技能和测试技术。

（5）测试员

职责：

执行测试，描述测试结果，提出问题解决方案。

人员要求：

了解被测试的系统，具备诊断和解决问题的技能，编程技能

根据每个人的特长来担任其中的一个或多个角色。最好是每个人都能参与设计和编码工作，每个人都能够建立起系统的全局观。

第四篇：标准的软件开发过程

标准的软件开发过程

软件开发的标准过程包括六个阶段，而六个阶段需要编写的各类文件达14种之多，在每个阶段需要编写哪些文件，以及这些文件的主要内容见下：

1.可行性与计划研究阶段

可行性研究报告：在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。

项目开发计划：编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开 发工作。

2.需求分析阶段

软件需求说明书：软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。内容包括对功能的规定对性能的规定等。

数据要求说明书：数据要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。

初步的用户手册：用户手册的编制是要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。使用户（或潜在用户）通过本手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。

3.设计阶段

概要设计说明书：概要设计说明书又可称系统设计说明书，这里所说的系统是指程序系统。编制的目的是说明对程序 系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计。运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。

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

数据库设计说明书：数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。

测试计划初稿：这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。

4.实现阶段

模块开发卷宗（开始编写）：模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起。编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。

用户手册完工

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

测试计划终稿：

5.测试阶段

模块开发卷宗(此阶段内必须完成)

测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。

项目开发总结报告：项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。

6.运行与维护阶段

开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进展和情况，以便及时发现和处理开发过程中出现的问题。一般地，开发进度月报是以项目组为单位每月编写的。如果被开发的软件系统规模比较大，整个工程项目被划分给若干个分项目组承担，开发进度月报将以分项目组为单位按月编写。

对于一项软件而言，有些文件的编写工作可能要在若干个阶段中延续进行。

鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，本指南认为在文件编制工作中应允许一定的灵活性，并不是14种文件每种都必须编写。文件编制的衡量因素

◆在因素总和较低的情况下,项目开发总结报告的内容应包括：程序的主要功能、基本流程、测试结果和使用说明。

◆测试分析报告应该写，但不必很正规。

◆数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。

例2：为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来，这就是本例的出发点。软件的规模不妨分为四级：

1．小规模软件源程序行数小于5 000的软件；

2．中规模软件源程序行数为 10 000～ 50 000的软件；

3．大规模软件源程序行数为 100 000?500 000的软件；

4．特大规模软件源程序行数大于500 000的软件。

对上述的四级软件的文件编制要求分别列于表O3。

至于源程序行数为 5 000～ 10 000，50 000～ 100 000的软件，其文件编制要求介于两级之间，可根据一个软件产品的具体情况，由项目负责人参照表O3的规定，确定需要编制的文件种类。

对于源程序行数大于500 000的特大规模软件，可进一步把本指南规定的十四种文件按实际需要扩展成更多种类。

第五篇：JAVA学习书籍- 软件开发过程

了解软件开发过程不单纯是提高程序员个人的良好编程习惯，也是增强团队协作的基础。

1、《UML 精粹》

UML 其实和软件开发过程没有什么必然联系，却是软件团队协作沟通，撰写软件文档需要的工具。但是UML 真正实用的图不多，看看这本书已经足够了，完全没有必要去啃《UML 用户指南》之类的东西。要提醒大家的是，这本书的中译本翻译的非常之烂，建议有条件的看英文原版。

2、《解析极限编程拥抱变化》XP

这是Kent Beck 名著的第二版，中英文对照。没什么好说的，必读书籍。

3、《统一软件开发过程》UP

其实UP 和敏捷并不一定冲突，UP 也非常强调迭代，测试，但是UP 强调的文档和过程驱动却是敏捷所不取的。不管怎么说，UP

值得你去读，毕竟在中国真正接受敏捷的企业很少，你还是需要用UP 来武装一下自己的，哪怕是披着UP 的XP。

4、《敏捷建模》AM

Scott Ambler 的名著，这本书非常的progmatic，告诉你怎么既敏捷又UP，把敏捷和UP 统一起来了，又提出了很多progmatic的建议和做法。你可以把《解析极限编程拥抱变化》、《统一软件开发过程》和《敏捷建模》这三本书放在一起读，看XP 和UP的不同点，再看AM 是怎么统一XP 和UP 的，把这三种理论融为一炉，形成自己的理论体系，那么你也可以去写书了。

软件项目管理

如果你突然被领导提拔为项目经理，而你完全没有项目管理经验，你肯定会心里没底；如果你觉得自己管理项目不善，很想改

善你的项目管理能力，那么去考PMP 肯定是远水不解近渴的。

1、《快速软件开发》

这也是一本名著。可以这样说，有本书在手，你就有了一个项目管理的高级参谋给你出谋划策，再也不必担心自己不能胜任的问题了。这本书不是讲管理的理论的，在实际的项目管理中，讲这些理论是不解决问题的，这本书有点类似于“软件项目点子

大全”之类的东西，列举了种种软件项目当中面临的各种问题，以及应该如何解决问题的点子，你只需要稍加变通，找方抓药

就行了。__