软件开发规划项目规范标准

1、 11/11软件开发规划项目规范标准 软件项目开发和管理规范 本文阐述软件项目开发和管理的流程规范，作为软件项目开发的高级指引，本规范定义了软件开发的各个阶段以及每个阶段的工作活动和工件，但不对活动和工件的细节作过多规定。在项目开发过程中，每个项目根据自身的需要确定这些活动和工件的细节。 项目阶段 图2-1 项目开发的五个阶段 ?启动阶段 这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的，首先要明确项目的总体战略目标，对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务，以及需要解决什么样的问题和需要满足客户或市场的什么要求等，同时还要总结项目工作的范围、所需资

2、源、大约开支、各种风险，以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析，通过项目的意向书总结出来，由此确证客户或项目发起人和赞助者的要求与期望，并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。 ?计划阶段 这个阶段的工作是为整个项目做计划。项目开始后，首先要确定项目的具体范围，明确定出项目到底要做什么，总结、归纳并定出产品的功能。然后进一步制定项目的计划，列出每项具体工作，并建立所有工作任务的重要性及顺序；确定每项工作的执行人和所需资源；根据人员的配置和能力设定各项工作和整个项目的完成时间表。 ?执行阶段 这个

3、阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源，如：人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度，定期向全体项目人员及项目的发起人报告项目状态。 ?控制阶段 这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核，与项目计划所期望的结果进行比较，找出实际结果与计划的差别，并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题，如：对缺乏的资源的补偿调节；对项目的进度表及各项具体工作的优先级或顺序的修订。 ?结束阶段 这个阶段的

4、工作是确保项目的最终结果或提交物达到计划的要求，并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作，对整个项目的经历进行总结，修订项目文档，用户培训等。 阶段完成标志 在项目开发过程中，当一个阶段完成后才会开展下一个阶段的工作；另外，“某个阶段完成”通常被定义为项目的一个里程碑，里程碑标识了项目的进度，它是项目开发和控制的重要参考，对整个项目有重要的意义。因此，“确证某个阶段是否已经完成”的工作非常有重要。 ?每一个阶段的结束以它特定任务的完成为象征 只有当某个阶段中被规定的所有工作任务都完成了，这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去。反过来说，要是阶段中某个任务没

5、有全部完成，按照项目的定义，整个阶段就不能算是完成，因此项目就不能进入到下一个阶段去。 ?衡量阶段结束的工作结果必须是实在的交付品 阶段中的任务是否完成是透过任务活动中产生的交付品来体现的，交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如：某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束，都应该有这样的实质性东西的完成作为象征。 ?跨阶段的进程以阶段结尾的合格验证和审核来决定 当一个阶段结束时，在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证，并检查这一阶段的工作质量和效率，由此判断是否可以进入到下一个阶段

6、。这些检验象征了一个阶段的结尾终点，表示项目的进程离开了上一个阶段而进入了下一个阶段。 启动阶段 图3-1 启动阶段的任务和工件 ?产品领域研究 研究产品所在领域的状况，为项目论证提供依据。研究内容包括： ? o产品领域的现状和前景 o产品领域的商业模式和业务流程 o产品的价值和盈利空间 o产品的特性和复杂度 ?技术可行性研究 研究产品的实现技术，总结技术可行性。研究内容包括： o o类似产品的当前实现技术和技术趋势 o实现技术的候选方案 o各个方案的优点、成本和风险 o开发团队与实现技术的匹配情况 图4-1 计划阶段的任务和工件 ?规模、工作量评估 围绕各项计划的制定工作对项目的规模、工作量

7、等进行评估，评估的内容包括： o o模块数量与复杂度 o输入、输出和对外接口等数量与复杂度 o SLOC和功能点 o非生产性的支持工作量 o开发工作量（人月） o进度与里程碑 o进度风险 ?定制项目开发计划 项目开发计划体现了项目组对整个开发周期的预期，指定了项目开发的总体方针。与其 他计划一样，项目开发计划不是固定不变的，在执行过程中要对计划进行监控，可能会根据 实际情况修改计划并重新发布。 项目开发计划的内容包括： 用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责 图4-2 风险管理任务 风险管理计划定义这些任务的执行流程和人员分配。 风险管理计划的内容包括： 用文字和图表

8、概述风险管理任务的总体执行流程。 详细说明“风险识别”任务的实施细节和各项工作的负责人。 详细说明“风险分析”任务的实施细节和各项工作的负责人。 险优先级详细说明“确定风险优先级”任务的实施细节和各项工作的负责人。 险化解方案详细说明“定制风险处理方案”任务的实施细节和各项工作的负责人。 当风险发生时，需要采取相应的措施化解风险。这部分的内容是描述风险 工作的操作规范和流程。 详细说明风险监控任务的实施细节和各项工作的负责人。 表4-2 风险管理计划 常规开发活动（需求分析、架构设计、详细设计、编码和测试、发布和实施等） 会议（工作例会、进度会议、审查会议等） 评审（方案评审、技术评审、质量评

9、审等） 测量（产品规模测量、进度测量、缺陷率测量、测试覆盖率测量等） 其他活动（技能培训、资料收集、内部流、客户沟通等） 表4-4 工作规范 ?定制开发进度计划 基于当前对项目的规模和工作量评估，定制初步的开发进度表，作为项目开发计划的组 成部分。 开发进度表的内容包括： o o项目的开始和结束时间 o项目各个阶段的开始和结束时间 o每个阶段的工作任务及其开始和结束时间 o每个工作任务的子任务的及其开始和结束时间 o里程碑和同步点 o角色的定义和任务分配 作为跟踪项目进度的重要依据，进度表在项目推进过程中需要不断细化。另外，当实际 进度与计划进度出现偏差时，需要修改进度表并重新发布。 执行阶段

10、 5.客户的特别要求 开发的局限 对开发的成功与否起很大影响的因素，是开发能力的局限： 1.人员的局限 2.技术的制约和局限 3.客户的特别要求 表5-1 需求分析告 需求分析报告的编制方式可以是多样的，例如把所有“非功能性需求”组织成“外部接 口需求”、“质量属性需求”和“需求约束”。【如：图5-2】 图5-2 需求规格说明书 ?界面原型设计 明确了系统的关键需求后，就可以进行界面原型设计工作，获取用户的反馈，尽快确定产品的界面基调。同时要编写一份界面设计概要文档，作为后续的界面设计工作的指导。 界面设计概要的内容包括： o设计的理念 o理念的来源或参考 o设计的要点 o与类似产品界面的对比

11、 ?架构设计 架构设计从关键需求开始，建立概念性的架构，并逐步细化和验证。最终生成架构设计说明书和架构基线代码。 架构设计的方法：可以从几个不同的视角进行架构设计，然后汇总综合得出完整的设计。（架构设计的五个视图【如：图5-3】） o所有工程项目 o工程目录结构 o软件包结构 o导入所有依赖包 o基础公共代码 o架构框架代码 o架构框架示例代码和测试代码 o数据库框架 图5-4 和图5-5 展示了软件架构师的工作和成功的软件架构设计包含的内容： 图5-4 软件架构师的工作 图5-5 成功的软件架构设计 1 软件构建 软件可以分阶段进行构建，每个阶段可以使用增量的方式开发，用通过若干个Build

12、构建，最后发布阶段性产品成果。 （注意：在这里，名词“阶段”的含义和本文其他地方的含义不一样） ?阶段计划 构建阶段计划的内容包括： o确定本阶段要实现的功能 o列出阶段任务 o计划Build构建数量 o细化开发进度表中本阶段的工作内容 ?Build 构建 详见：下一节 ?阶段产品发布 构建阶段完成后发布阶段产品成果，向用户展示并接受用户反馈，同时做好阶段总结。 发布清单的内容包括： o产品版本号和日期 o改正的Bug o修改的功能 o实现的新功能 o其他说明 阶段总结报告的内容包括： o阶段任务的完成情况 o进度计划的执行情况 o用户的反馈情况 o本阶段碰到的主要问题 o下一阶段的改进建议

13、2 Build 构建 Build构建以增量的方式执行阶段的开发任务，每个Build构建的周期一般不超过两星期，每一次Build构建都会发布为一个内部版本，并提交测试。测试发现的问题留待以后的Build构建解决。 ?Build计划 Build计划的内容包括： o本次Build的版本号 o本次Build的历时 o本次Build的工作任务 ?要解决的遗留Bug ?本应由以前的Build实现的，但推迟到本次Build实现的功能 ?要实现的新功能 ?其他工作任务 o工作任务分配 ?需求细化 根据Build计划，细化本次Build要实现的需求，细化到能进行详细设计为止。有了细化的需求后就编写本次Build

14、的测试计划。 测试计划的内容包括： o功能测试 ?要测试的功能 ?测试时间 ?测试方式 ?验收标准 o其他测试（性能测试、边界测试、使用界面测试、可用性测试、安全性测试等） ?要测试的内容 ?测试时间 ?测试方式 ?验收标准 o。 ?界面设计 根据细化的需求设计用户界面，当界面确定后即可编写测试用例。 测试用例的内容包括： o测试用例对应的功能模块 o测试用例的性质（功能测试用例、性能测试用例、。） o输入（或操作步骤） o期望输出 o实际输出（执行测试后再填写） o是否通过（执行测试后再填写） ?详细设计 详细实际每项需求的实现方法，对于重要的设计决策、算法、公共模块和外部接口等必须以模块设

15、计文档的形式进行记录。模块设计文档的内容包括： o模块名称 o设计思想 o设计图表（类图、流程图等） o要点描述（包、接口、类、方法、算法、设计模式） o测试方式 ?编码、单元测试 编码和单元测试是开发人员的工作，对于重要的代码都必须进行单元测试，编写代码必须遵守下列准则： o遵守编码规范 o编码前必须充分理解相关的需求 o编码前先进行设计，把流程理顺 o注意设计方法和设计模式的灵活运用 o总体考虑问题，使代码遵从架构并容易测试 o设计时要充分考虑异常情况和临界条件 o严禁Copy-Paste，注意提取公共代码，在编码过程中实现重构 o异常处理必须记录日志，严禁草率地直接打印异常信息 o灵活运

16、用ASSERT() / VERIFY()等断言来帮助调试程序 o单元测试是程序员的工作，所以编码完成后必须对代码严格测试 o功能代码完成后必须先做以下4件事情： ?编译代码，保证编译通过 ?（不运行程序）对代码进行全面检查 ?用调试模式启动程序，一行一行单步执行代码，并注意调试输出 ?改变条件，让代码尽可能走遍所有程序分支 o Check In代码前必须保证能编译通过 ?创建Build 代码集成发布前需冻结代码，所有人把要提交的代码Check In，并保证编译后的程序能在测试服务器上正常启动，界面能正常打开。同时还要提交Build清单。 Build清单的内容包括： o Build版本号和日期

17、o改正的Bug o修改的功能 o实现的新功能 o其他说明 ?集成测试 按照测试计划针对Build清单执行测试用例，测试完成后编写测试报告。 测试报告的内容包括： o测试用例汇总（用例数量、通过的用例数量、未通过的用例数量等） o Bug汇总（Bug总数、新增Bug数量、关闭Bug数量、Bug趋势图表等） o测试计划执行情况 o测试总结 控制阶段 图6-1 控制阶段的任务和工件 ?风险管理 开发期间要对风险进行监控，定期检查、更新和发布风险列表。 ?质量管理 1）评审 评审是质量保证的重要环节，原则上每个重要的工作任务或阶段结束前都必须经过评审，如：方案评审、计划评审、需求评审、设计评审和代码评

18、审等，工作是否被通过、是否需要修改或重做均由评审结果决定，评审结果以评审报告的形式发布。 评审报告的内容包括： 评审主题、时间、提交者、评审者等 评审内容的列表和简述 评审过程中重要的问答记录 整个评审的结果，如： 1.完全通过，无需修改 2.基本通过，需要作小量修改，但不必再评审 ?测量 在项目开发过程中，收集一些关键的测量，对了解项目状态和进行项目决策很有帮助，同时也为以后的项目提供历史数据参考。每个测量都要生成测量报告并存档。 测量报告的内容包括： 1.基本信息，包括测量主题、测量时间、测量者等 2.测量内容和测量值 3.测量分析 结束阶段 图7-1 控制阶段的任务和工件 ?产品测试 因

19、为产品即将验收和发布，所以必须对产品进行完整测试，产品测试比其他测试要求更严格，当产品的质量达到发布的要求后才能发布。产品的质量由测试报告体现。 ?RC版本发布 发布RC版本让用户体验并收集反馈意见，为产品验收作准备。RC版本发布后，产品不应该有大改动，一般只是界面的局部调整。 ?编制用户文档 针对不同的使用者角色，编制相应的用户文档，对管理者用户需要提供安装、维护指南，对普通用户需要编制产品使用手册。 安装、维护指南的内容包括： 1. 1.产品各组件的说明 2.产品部署架构 3.安装、配置和卸载等步骤 4.启动、停止和重启等操作 5.其它操作：日志、备份、还原等 产品使用手册的内容包括： 1

20、.产品介绍 2.各个功能的介绍 3.通过实际案例介绍各个功能的使用方式和操作步骤 ?产品使用培训 对于为特定客户开发的软件产品，在发布前需要对用户进行产品的使用培训。培训前需要部署好操作环境，编写培训资料，然后组织培训会议。 ?产品验收 对于为特定客户开发的软件产品，通常根据签订的开发合同和产品方案等条款逐项验收，验收时，用户通常会执行验收测试案例。 ?最后修订 在产品验收通过后，正式发布前对产品作最后的修订，可能包括： 1. 1.开发文档修订 2.用户文档修订 3.代码整理 ?正式版发布 正式版的发布标志着开发阶段的结束，产品从此时起进入维护阶段，正式发布前可能要做一些准备工作，如：数据迁移

21、和环境配置等。 ?项目总结 项目结束后需要对整个项目开发阶段的工作进行总结，交流心得，吸取经验和教训，并归档为项目总结报告。 项目总结报告的内容包括： 1. 1.总体评价 2.成本、收益汇总 3.重要心得 4.管理总结 5.技术总结 总结 图8-1 项目阶段 软件项目开发经历多个阶段，每个阶段包含多个任务，每个任务会产生相应的工件。需要相应的质量保证措施对任务进行监控，保证任务的执行。任务完成后也需要对任务进行评审，保证任务的质量。 这些工作均由开发团队和相关人员按照工作流程执行。因此，合理的角色任务分配和沟通制度是软件项目成功的重要保障。 图8-2 列出几种比较普遍的角色和任务划分方案： 图

22、8-2 角色和任务划分方案 职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因，一个好的软件团队必须根据团队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分，这样团队中的每个成员才可能有清晰的责任和目标。 软件开发不管采用哪种生命周期模型和开发方法论，整个过程都会包含需求，设计，开发，测试，配置管理等各项活动。而这些活动会对应到项目中的不同角色，项目中进行岗位划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。 方案一项目负责人总览全局 对于小作坊的软件开发团队，可以由一个项目负责人总览全局。项目负责人承担从用户需求-软件需求-总体设计的所有工作。同时还需要做到

23、整个团队进度规划，质量保证，配置管理和沟通协调等相关工作。所以小型项目团队对项目负责人的业务，技术和沟通管理等技能都要求较高，项目负责人是项目中的总体方案确认者和架构师。项目负责人能力和技能往往决定了整个软件项目的成败。 我们这里指的小型团队并不是只一个人单打独斗的项目，所以项目负责人最好不要介入到模块设计和编码活动中，而是应该把重点放在进度的控制和质量的保证上面。由于项目负责人一般有较强的技术能力，所以项目负责人可以承担项目中要使用的一些新技术的研究，项目中一些疑难问题的解决等相关工作。项目负责人还应该有计划的设计开发人员的代码进行Review，对发现的规范性，性能，复用差等问题跟项目成员确

24、认，并写入到项目开发规范中。 方案二项目负责人和开发负责人分离 在这种方案下项目负责人和开发负责人在软件需求和架构上的工作是重叠的。这两个岗位的人员共同来确认项目的总体方案和架构。项目负责人的重点在项目管理和与客户交流沟通上，只有确认清楚第一手的用户需求，才能开发出用户满意度高的软件。对于很多小型项目往往是用户需求都没有搞清楚就开工，项目成员完全凭借着自己的感觉在做系统，过程中又不注意与用户及时反馈和迭代，导致开发出完全不能使用的系统；开发负责人的重点是对整个开发过程负责，包括对项目经理确认的进度目标进行任务的进一步分解，安排后续的增量和迭代计划。方案二的重点是第一次解放项目经理，架构的核心移动到了开发负责人，而项目经理仅仅是参与讨论和评审。而单独剥离出开发负责人后