软件开发项目规范.docx

软件开发项目规范.docx

《软件开发项目规范.docx》由会员分享，可在线阅读，更多相关《软件开发项目规范.docx（31页珍藏版）》请在冰豆网上搜索。

软件开发项目规范

软件项目开发与管理规范

本文阐述软件项目开发与管理得流程规范,作为软件项目开发得高级指引,本规范定义了软件开发得各个阶段以及每个阶段得工作活动与工件，但不对活动与工件得细节作过多规定。

在项目开发过程中,每个项目根据自身得需要确定这些活动与工件得细节。

项目阶段

图2—1项目开发得五个阶段

∙启动阶段

这个阶段得工作目得就是决定一个项目就是否需要启动。

为了达到这个目得，首先要明确项目得总体战略目标，对项目得需要建立认同。

即确定到底需要做什么、开发什么产品或提供什么服务,以及需要解决什么样得问题与需要满足客户或市场得什么要求等,同时还要总结项目工作得范围、所需资源、大约开支、各种风险,以及该项目不执行得其她替代选择等。

这些代表了对整个项目目标从战略角度与宏观层次所进行得分析，通过项目得意向书总结出来，由此确证客户或项目发起人与赞助者得要求与期望，并帮助她们判定项目就是否上马。

项目意向总结书得通过及项目被批准上马形成了这个项目得起始点.

∙计划阶段

这个阶段得工作就是为整个项目做计划。

项目开始后,首先要确定项目得具体范围，明确定出项目到底要做什么,总结、归纳并定出产品得功能.然后进一步制定项目得计划,列出每项具体工作，并建立所有工作任务得重要性及顺序；确定每项工作得执行人与所需资源；根据人员得配置与能力设定各项工作与整个项目得完成时间表。

∙执行阶段

这个阶段得工作就是通过执行项目得计划来完成项目得任务。

它包括落实一切所需资源，如:

人员、设备、费用、技术、信息，由管理者领导全体项目参与者开展各项工作。

同时跟踪各项具体工作与整个项目得进度，定期向全体项目人员及项目得发起人报告项目状态。

∙控制阶段

这个阶段得工作就是确证项目工作得结果符合项目得计划。

它通过对项目结果得衡量与审核,与项目计划所期望得结果进行比较，找出实际结果与计划得差别，并制定处理措施。

这个阶段得工作还包括对项目进程中出现得任何更改要求进行审核与批准。

同时调解项目进程中出现得各种问题，如：

对缺乏得资源得补偿调节;对项目得进度表及各项具体工作得优先级或顺序得修订。

∙结束阶段

这个阶段得工作就是确保项目得最终结果或提交物达到计划得要求，并对完成得结果作可接受得确认。

还包括在项目完成之后得收尾工作，对整个项目得经历进行总结，修订项目文档，用户培训等。

阶段完成标志

在项目开发过程中，当一个阶段完成后才会开展下一个阶段得工作；另外，“某个阶段完成”通常被定义为项目得一个里程碑,里程碑标识了项目得进度，它就是项目开发与控制得重要参考,对整个项目有重要得意义。

因此,“确证某个阶段就是否已经完成"得工作非常有重要。

∙每一个阶段得结束以它特定任务得完成为象征

只有当某个阶段中被规定得所有工作任务都完成了,这个阶段才算真正结束，整个项目才可以进入到下一个阶段中去.反过来说,要就是阶段中某个任务没有全部完成,按照项目得定义,整个阶段就不能算就是完成，因此项目就不能进入到下一个阶段去.

∙衡量阶段结束得工作结果必须就是实在得交付品　

阶段中得任务就是否完成就是透过任务活动中产生得交付品来体现得,交付品必须就是可交付得、非抽象得、实质得并且可以通过用衡量得方法来判断就是否真正地完成了得具体事物.如：

某一阶段得完成就是以建造一个样品或完成某分文件作为象征。

任何项目阶段得结束,都应该有这样得实质性东西得完成作为象征。

∙跨阶段得进程以阶段结尾得合格验证与审核来决定　

当一个阶段结束时，在进入到下一个阶段之前所需要做得工作应包括对交付品进行合格验证，并检查这一阶段得工作质量与效率，由此判断就是否可以进入到下一个阶段。

这些检验象征了一个阶段得结尾终点，表示项目得进程离开了上一个阶段而进入了下一个阶段。

启动阶段

图　3—1　启动阶段得任务与工件

∙产品领域研究

研究产品所在领域得状况,为项目论证提供依据.研究内容包括：

o产品领域得现状与前景

o产品领域得商业模式与业务流程

o产品得价值与盈利空间

o产品得特性与复杂度

∙技术可行性研究

研究产品得实现技术，总结技术可行性。

研究内容包括：

o类似产品得当前实现技术与技术趋势

o实现技术得候选方案　

o各个方案得优点、成本与风险

o开发团队与实现技术得匹配情况

∙项目论证

基于商业与技术等方面对项目得可行性进行论证,确定项目就是否开展。

如果开展项目，则进一步论证项目得总体方案。

论证得内容包括:

o商业可行性　

o技术可行性

o当前产品与类似产品得比较　

o项目收益与前景

o项目得成本与风险

o项目得总体方案

∙确定项目目标与范围

项目开始时，所有相关人员必须对项目得目标与范围达成共识，形成共同得项目愿景.并把愿景叙述为《项目开发大纲》向相关人员传达.

《项目开发大纲》得内容包括：

概述

用三到五张图表来描述产品目标、功能、平台、客户、进度表与开发职责

高级功能

用一个段落来综述产品,再用一个段落来描述每个重要得功能

不实现得功能

用一个段落来描述每个对产品有用得但本项目不实现得功能

涉众

用一个段落来明确每个重要得涉众群体与她们得风险股本

项目需求

用一个段落来讲述每个重要得项目需求

项目风险

按风险暴露量对每个重要得项目风险都用一个段落来讨论

项目回报

用一个段落综述产品得回报,其后再对每个重要得项目回报都用一个段落来讨论

结论

用一到三个段落将上述所有部分联系起来,明确项目得需求与风险,再用论点与论据来总结为什么这个项目会成功

表3－1项目开发大纲

计划阶段

图4—1计划阶段得任务与工件

∙规模、工作量评估　

围绕各项计划得制定工作对项目得规模、工作量等进行评估,评估得内容包括：

o模块数量与复杂度

o输入、输出与对外接口等数量与复杂度

oSＬOC与功能点

o非生产性得支持工作量

o开发工作量（人月）

o进度与里程碑　

o进度风险

∙定制项目开发计划

项目开发计划体现了项目组对整个开发周期得预期,指定了项目开发得总体方针。

与其她计划一样,项目开发计划不就是固定不变得,在执行过程中要对计划进行监控，可能会根据实际情况修改计划并重新发布。

《项目开发计划》得内容包括：

概述

用三到五张图表来描述产品目标、功能、平台、客户、进度表与开发职责。

（《项目开发计划》得概述部分应该就是《项目开发大纲》中概述部分得拷贝。

当项目计划改变时,修订《项目开发计划》得概述部分而不就是修订《项目开发大纲》。

这样,以后在进行项目评价时,通过比较《项目开发大纲》与《项目开发计划》得概述,就能瞧出项目就是如何改变得）

高级功能

用一到五页得篇幅来概述产品得功能,其中,要包括这些功能得附加信息（开发者需要这样得信息来了解实现需求）。

项目成员

确定软件工程职能角色,以及分配到这些角色得人员数量。

软件过程

概述这个项目中所应用得软件过程。

（具体内容可在《质量保证计划》中定义）

软件工程方法

概述这个项目中所应用得软件工程方法与技术。

（具体内容可在《质量保证计划》中定义）

进度与工作量

这一部分要表达出整个项目进度与工作量得估计。

其中要包括:

∙对固定不变得里程碑与同步点得解释

∙在评估中得设想情况、评估中得不准确性得可能来源

∙随着项目得进展如何更新评估

（具体进度表内容可在《开发进度表》中定义）

风险管理计划

概述这个项目中风险管理计划。

（具体内容可在《风险管理计划》中定义）

测量

概述这个项目中要收集得测量。

软件工具

列出要使用得每一项软件工具,以及该工具所支持得任务。

项目支持

硬件支持明确所需得硬件,包括那些需要移动、获取或升级得硬件。

软件支持明确所需得软件,包括需要获取、安装或升级得软件件。

人力支持由哪个人、部门或团队为开发组得哪项任务提供支持。

表4—１项目开发计划

∙定制风险管理计划

风险管理任务包括:

风险识别、风险分析、确定风险优先级、定制风险化解方案、风险化解与风险监控【如：

图4－2】。

图4—2风险管理任务

《风险管理计划》定义这些任务得执行流程与人员分配。

《风险管理计划》得内容包括:

概述

用文字与图表概述风险管理任务得总体执行流程。

风险识别

详细说明“风险识别”任务得实施细节与各项工作得负责人。

风险分析

详细说明“风险分析”任务得实施细节与各项工作得负责人。

确定风险优先级

详细说明“确定风险优先级”任务得实施细节与各项工作得负责人。

定制风险化解方案

详细说明“定制风险处理方案”任务得实施细节与各项工作得负责人。

风险化解

当风险发生时,需要采取相应得措施化解风险。

这部分得内容就是描述风险化解工作得操作规范与流程。

风险监控

详细说明风险监控任务得实施细节与各项工作得负责人。

表4-2风险管理计划

风险管理中通常会用到《Top　N风险列表》，风险列表按照风险暴露量排序列出当前项目中主要得Ｎ个风险，《TopN　风险列表》得内容包括：

本周排名

本周得排名（如果本周已被完全化解用“---”表示）

上周排名

上周排名（如果就是新识别得风险用“---”表示）

上表周数

该风险已上表得周数

风险

风险得名称或简述

类型

风险类型（只针对进度相关得风险）:

o计划编制

o组织与管理

o设计与实现

o客户与需求

o承包商

o产品

o人员

o过程

o技术

o外部环境

o开发环境

发生概率

风险发生得百分比概率

损失程度

风险发生时损失得进度（工作日或工作周）

暴露量

发生概率X损失程度

状态

风险得当前状态:

未发生、已发生、已化解

化解方案

简述风险得化解方案,如果有具体得化解方案文档则链接到相应文档

化解进度

对已发生得风险,简述化解进度（未发生得风险用“---”表示）

表　4—3风险列表

∙定制质量保证计划

保证工作质量得一个重要步骤就是制定一套合理得质量保证计划并贯彻执行。

《质量保证计划》得内容包括：

概述

说明编写得目得、适用范围以及对相关人员得要求等

软件过程

详细说明这个项目中所应用得软件过程。

软件工程方法

详细说明这个项目中所应用得软件工程方法与技术。

工作规范

对工程方法中得各种工作任务进行规范,明确执行得时机、流程与准则等。

这些工作任务包括:

常规开发活动（需求分析、架构设计、详细设计、编码与测试、发布与实施等）

会议（工作例会、进度会议、审查会议等）

评审（方案评审、技术评审、质量评审等）

测量（产品规模测量、进度测量、缺陷率测量、测试覆盖率测量等）

其她活动（技能培训、资料收集、内部流、客户沟通等）

表4—４　工作规范

∙定制开发进度计划

基于当前对项目得规模与工作量评估，定制初步得开发进度表，作为项目开发计划得组成部分。

《开发进度表》得内容包括：

o项目得开始与结束时间

o项目各个阶段得开始与结束时间

o每个阶段得工作任务及其开始与结束时间

o每个工作任务得子任务得及其开始与结束时间

o里程碑与同步点　

o角色得定义与任务分配

作为跟踪项目进度得重要依据，进度表在项目推进过程中需要不断细化.另外,当实际进度与计划进度出现偏差时，需要修改进度表并重新发布。

执行阶段　

图５—1执行阶段得任务与工件

∙需求分析　

分析产品得关键需求、对架构设计有影响得需求与风险较高得需求，直到分析得程度能开展足界面原型设计与架构设计工作。

《需求规格说明书》得内容包括：

商业或业务需求

从商业或业务角度宏观上对产品或系统得要求。

它主要在宏观得层面归纳总结为满足客户提出得要求或赢得市场竞争所必须实现得功能、性能、质量等要求。

1.做什么

2.做得范围

3.对结果得要求

使用者需求

从客户对软件产品或系统使用方案得角度出发,描述与总结使用者利用该软件产品或系统能够做得事或能够完成得任务。

功能需求

根据上述使用者需求列出得使用方案,列出开发者必须为软件产品或系统实现得功能。

性能需求

1.运行速度、容量、并发性能

2.对资源得利用率

3.对外界输入得反馈速度与准确性

4.对差错得负荷能力

系统需求

o必须适应得运行环境得要求（包括运行平台、网络及其她硬件要求）

o与其她系统兼容得要求（包括与操作系统、数据库、浏览器及其她应用软件得兼容要求）

o与外部其她系统与组件得接口要求

质量需求

o对用户重要得质量标志（可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性）

o对开发者重要得质量标志（可维护性、多用转换性、重复使用性、可测试性）

其她需求

不属于上述需求范围得,但受到其她环境与商业合同影响得要求。

1.国家或地区得任何特别得标准

2.软件使用界面得特别要求

3.与知识产权有关得要求

4.软件所面对得市场与行业得规范

5.客户得特别要求

开发得局限

对开发得成功与否起很大影响得因素,就是开发能力得局限:

1.人员得局限

2.技术得制约与局限

3.客户得特别要求

表5-1　需求分析告

《需求分析报告》得编制方式可以就是多样得，例如把所有“非功能性需求”组织成“外部接口需求"、“质量属性需求”与“需求约束”.【如：

图5-2】

图　5—2需求规格说明书

∙界面原型设计　

明确了系统得关键需求后，就可以进行界面原型设计工作,获取用户得反馈，尽快确定产品得界面基调。

同时要编写一份《界面设计概要》文档，作为后续得界面设计工作得指导。

《界面设计概要》得内容包括:

o设计得理念

o理念得来源或参考

o设计得要点

o与类似产品界面得对比

∙架构设计

架构设计从关键需求开始，建立概念性得架构，并逐步细化与验证。

最终生成架构设计说明书与架构基线代码。

架构设计得方法:

可以从几个不同得视角进行架构设计,然后汇总综合得出完整得设计。

（架构设计得五个视图【如：

图5－3】）

图５-3架构设计得五视图

《架构设计说明书》得内容包括:

概述

说明编写得目得、适用范围以及设计原则等。

逻辑架构

关注功能。

其设计着重考虑功能需求。

1.细化功能单元

2.发现通用机制

3.细化领域模型

4.确定子系统接口与交互机制

开发架构

关注程序包。

其设计着重考虑开发期质量属性,如可扩展性、可重用性、可移植性、易理解性与易测试性等。

1.确定要开发或直接利用得程序包之间得依赖关系

2.确定采用得技术、框架等

数据架构

关注持久化数据得存储方案。

其设计着重考虑“数据需求”。

1.持久化数据存储方案

2.数据传递、数据复制、数据同步等策略

运行架构

关注进程、线程、对象等运行时概念,以及相关得并发、同步、通信等问题。

其设计着重考虑运行期质量属性,例如性能、可伸缩性、持续可用性与安全性等。

1.确定引入哪些进程与线程

2.确定主动对象、被动对象,以及控制关系

3.处理进程线程得创建、销毁、通信机制、资源争用等

4.协议设计

物理架构

关注软件系统最终如何安装或部署到物理机器。

其设计着重考虑“安装与部署需求”。

1.确定物理配置方案

2.确定如何将目标程序映射到物理节点

总结

基于上述得设计进行总结,并描述架构基线。

表５—2　架构设计说明书

架构设计得另一个重要任务就是编写架构基线代码，基线代码表述与验证架构,同时也就是指导后续开发得基础代码。

架构基线代码得内容包括:

o所有工程项目

o工程目录结构

o软件包结构　

o导入所有依赖包　

o基础公共代码　

o架构框架代码

o架构框架示例代码与测试代码

o数据库框架

图5—4与图５－5展示了软件架构师得工作与成功得软件架构设计包含得内容:

图　5—4软件架构师得工作

图5-5成功得软件架构设计

1　软件构建

软件可以分阶段进行构建,每个阶段可以使用增量得方式开发，用通过若干个Buｉld构建，最后发布阶段性产品成果。

（注意：

在这里，名词“阶段”得含义与本文其她地方得含义不一样）

∙阶段计划

构建阶段计划得内容包括：

o确定本阶段要实现得功能

o列出阶段任务

o计划Build构建数量

o细化《开发进度表》中本阶段得工作内容

∙Ｂｕild构建　

详见:

下一节

∙阶段产品发布　

构建阶段完成后发布阶段产品成果，向用户展示并接受用户反馈,同时做好阶段总结。

《发布清单》得内容包括：

o产品版本号与日期　

o改正得Bug

o修改得功能

o实现得新功能

o其她说明

《阶段总结报告》得内容包括：

o阶段任务得完成情况

o进度计划得执行情况

o用户得反馈情况

o本阶段碰到得主要问题

o下一阶段得改进建议　

2Build构建

Ｂuild构建以增量得方式执行阶段得开发任务，每个Ｂuild构建得周期一般不超过两星期,每一次Builｄ构建都会发布为一个内部版本，并提交测试。

测试发现得问题留待以后得Ｂuiｌｄ构建解决.

∙Bｕiｌｄ计划

《Ｂuild计划》得内容包括：

o本次Ｂuｉｌd得版本号

o本次Ｂuilｄ得历时

o本次Bｕild得工作任务

▪要解决得遗留Ｂug　

▪本应由以前得Bｕild实现得,但推迟到本次Bｕｉld实现得功能

▪要实现得新功能

▪其她工作任务

o工作任务分配　

∙需求细化

根据《Build计划》,细化本次Buｉld要实现得需求,细化到能进行详细设计为止。

有了细化得需求后就编写本次Buiｌd得测试计划。

《测试计划》得内容包括：

o功能测试

▪要测试得功能

▪测试时间

▪测试方式

▪验收标准

o其她测试（性能测试、边界测试、使用界面测试、可用性测试、安全性测试等）

▪要测试得内容

▪测试时间

▪测试方式

▪验收标准

o。

。

...。

∙界面设计

根据细化得需求设计用户界面,当界面确定后即可编写测试用例.

《测试用例》得内容包括：

o测试用例对应得功能模块

o测试用例得性质（功能测试用例、性能测试用例、.。

。

。

。

。

）

o输入（或操作步骤）

o期望输出

o实际输出（执行测试后再填写）

o就是否通过（执行测试后再填写）　

∙详细设计

详细实际每项需求得实现方法，对于重要得设计决策、算法、公共模块与外部接口等必须以模块设计文档得形式进行记录.《模块设计文档》得内容包括:

o模块名称

o设计思想

o设计图表（类图、流程图等）　

o要点描述（包、接口、类、方法、算法、设计模式）

o测试方式

∙编码、单元测试　

编码与单元测试就是开发人员得工作,对于重要得代码都必须进行单元测试,编写代码必须遵守下列准则：

o遵守编码规范

o编码前必须充分理解相关得需求

o编码前先进行设计，把流程理顺

o注意设计方法与设计模式得灵活运用

o总体考虑问题,使代码遵从架构并容易测试

o设计时要充分考虑异常情况与临界条件　

o严禁Coｐy-Paste，注意提取公共代码,在编码过程中实现重构

o异常处理必须记录日志，严禁草率地直接打印异常信息

o灵活运用ＡＳＳＥRT（）/　VＥRIFY（）等断言来帮助调试程序

o单元测试就是程序员得工作,所以编码完成后必须对代码严格测试

o功能代码完成后必须先做以下4件事情:

▪编译代码，保证编译通过　

▪（不运行程序）对代码进行全面检查

▪用调试模式启动程序，一行一行单步执行代码，并注意调试输出

▪改变条件,让代码尽可能走遍所有程序分支

oCheckＩn代码前必须保证能编译通过

∙创建Buｉｌd

代码集成发布前需冻结代码，所有人把要提交得代码ＣheｃkIｎ,并保证编译后得程序能在测试服务器上正常启动,界面能正常打开。

同时还要提交Ｂuｉld清单.

《Ｂuｉld清单》得内容包括：

oBuｉｌd版本号与日期

o改正得Bug

o修改得功能　

o实现得新功能　

o其她说明

∙集成测试

按照《测试计划》针对《Builｄ清单》执行《测试用例》,测试完成后编写测试报告.

《测试报告》得内容包括：

o测试用例汇总（用例数量、通过得用例数量、未通过得用例数量等）

oBug汇总（Bug总数、新增Bug数量、关闭Bｕg数量、Ｂug趋势图表等）

o测试计划执行情况

o测试总结

控制阶段

图　6—1控制阶段得任务与工件

∙风险管理

开发期间要对风险进行监控,定期检查、更新与发布《风险列表》。

∙质量管理

1）评审

评审就是质量保证得重要环节，原则上每个重要得工作任务或阶段结束前都必须经过评审，如：

方案评审、计划评审、需求评审、设计评审与代码评审等，工作就是否被通过、就是否需要修改或重做均由评审结果决定，评审结果以《评审报告》得形式发布。

《评审报告》得内容包括：

基本信息

评审主题、时间、提交者、评审者等

评审内容

评审内容得列表与简述

问答记录

评审过程中重要得问答记录

评审结论

整个评审得结果,如:

1.完全通过,无需修改

2.基本通过,需要作小量修改,但不必再评审

3.大体通过,需要作一些修改,之后再评审

4.不通过,需要作大幅修改,之后必须重新评审

评审意见

针对评审结论提出得意见与建议

表7—1　评审报告

2）测试

测试就是对被构建产品最直接有效得质量保证措施,测试结束后需要提交《测试报告》。

∙变更管理

开发过程中经常会出现多种变更，如：

需求变更、设计变更或人员变更等。

这些变更通常会对开发进度造成影响，因此要对变更及其处理过程进行跟踪,最后报告变更得处理结果。

《变更处理报告》得内容包括：

基本信息

变更主题、发生时间等

详细信息

变更得详细描述

变更处理

变更得处理方式与步骤

处理结果

变更得处理结果

变更影响

变更对项目造成得影响

表７—2变更处理报告

∙进度监控

项目进度会议就是了解项目实际进度得有效措施，在会议中评审工作报告，解决遇到得问题并计划下一步工作：

《工作报告》得内容包括：

1.基本信息：

报告者、汇报时间、工作时间段等

2.工作情况：

已完成得工作、未完成得工作　

3.遇到得问题:

工作中碰到得阻碍

4.工作计划：

下一步得工作计划

项目进度会议得另一个重要议题就是审查进度表，了解项目实际进度与计划进度得差异。

为进度表调整与资源调配提供重要依据。

∙测量　

在项目开发过程中，收集一些关键得测量，对了解项目状态与进行项目决策很有帮助，同时也为以后得项目提供历史数据参考。

每个测量都要生成测量报告并存档。

《测量报告》得内容包括：

1.基本信息，包括测量主题、测量时间、测量者等

2.测量内容与测量值

3.测量分析

结束阶段

图７－1　控制阶段得任务与工件

∙产品测试

因为产品