工程软件开发之团队开发规范FB.docx

上传人:b****6 文档编号:15508692 上传时间:2023-07-05 格式:DOCX 页数:22 大小:137.50KB
下载 相关 举报
工程软件开发之团队开发规范FB.docx_第1页
第1页 / 共22页
工程软件开发之团队开发规范FB.docx_第2页
第2页 / 共22页
工程软件开发之团队开发规范FB.docx_第3页
第3页 / 共22页
工程软件开发之团队开发规范FB.docx_第4页
第4页 / 共22页
工程软件开发之团队开发规范FB.docx_第5页
第5页 / 共22页
工程软件开发之团队开发规范FB.docx_第6页
第6页 / 共22页
工程软件开发之团队开发规范FB.docx_第7页
第7页 / 共22页
工程软件开发之团队开发规范FB.docx_第8页
第8页 / 共22页
工程软件开发之团队开发规范FB.docx_第9页
第9页 / 共22页
工程软件开发之团队开发规范FB.docx_第10页
第10页 / 共22页
工程软件开发之团队开发规范FB.docx_第11页
第11页 / 共22页
工程软件开发之团队开发规范FB.docx_第12页
第12页 / 共22页
工程软件开发之团队开发规范FB.docx_第13页
第13页 / 共22页
工程软件开发之团队开发规范FB.docx_第14页
第14页 / 共22页
工程软件开发之团队开发规范FB.docx_第15页
第15页 / 共22页
工程软件开发之团队开发规范FB.docx_第16页
第16页 / 共22页
工程软件开发之团队开发规范FB.docx_第17页
第17页 / 共22页
工程软件开发之团队开发规范FB.docx_第18页
第18页 / 共22页
工程软件开发之团队开发规范FB.docx_第19页
第19页 / 共22页
工程软件开发之团队开发规范FB.docx_第20页
第20页 / 共22页
亲,该文档总共22页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

工程软件开发之团队开发规范FB.docx

《工程软件开发之团队开发规范FB.docx》由会员分享,可在线阅读,更多相关《工程软件开发之团队开发规范FB.docx(22页珍藏版)》请在冰点文库上搜索。

工程软件开发之团队开发规范FB.docx

工程软件开发之团队开发规范FB

 

水利水电工程XXXXX辅助决策支持系统

团队开发规

 

XXXXX设计

二XXX年十二月

文档信息:

文档名称

水利水电工程XXXXX辅助决策支持系统团队开发规

描述

该文档详细定义了团队开发的角色及职责、项目开发流程、开发过程控制的约定、协作开发的约定、代码版本控制、交流机制等

负责人

XX

状态

最终版

文档变更历史:

时间

修改人

章节

描述

2008-8-29

XXX

所有章节

创建文档初稿

2008-12-10

XXX

所有章节

修改

文档名称:

团队开发规.doc

审核结果:

审核人

意见

签名档

 

1团队组成1

1.1产品管理1

1.2项目管理2

1.3开发3

1.4测试4

1.5角色共享5

1.6开发小组5

1.7专家小组6

2开发流程7

2.1达成共识7

2.2完成项目计划8

2.3完成功能8

2.4稳定与发布8

3代码管理10

3.1编码规10

3.2版本管理10

3.2.1概述10

3.2.2代码管理10

4附录:

系统开发编码规11

4.1类型级单位的命名11

4.1.1类11

4.1.2枚举和结构12

4.1.3委派类型12

4.1.4接口12

4.1.5模块13

4.2方法和属性的命名13

4.2.1方法13

4.2.2属性13

4.2.3事件13

4.3变量和常数14

4.4前缀15

4.4.1对象15

4.4.2变量/常量的围15

4.5标签16

4.6名字空间17

4.7格式化17

4.7.1块17

4.7.2缩进17

4.7.3流17

4.8注释18

4.8.1注释规18

4.8.2类(包括Form等)、模块、组件、控件19

4.8.3方法、函数、事件与属性19

4.9完整性20

4.10安全性20

1团队组成

我们的整个软件开发团队由4种角色组成,分别为:

∙产品管理(ProductManagement)

∙项目管理(ProgramManagement)

∙开发人员(Development)

∙测试人员(Test)

各角色在团队的地位相当,各司其职。

各个角色的具体目标、职能以及责任在以下的小节中进行详述。

1.1产品管理

(1)目标

满足客户需求。

产品管理的目标就是满足客户需求。

一个成功的项目必须要能够满足客户和用户的要求。

即使项目达到了预算和时间的目标,只要未能满足客户需求,那这就是一个失败的项目。

首先必须认清和理解客户。

有时,使用方和投资方的目标需求并不完全相同,因此就需要清晰地区别和分析所有的需求。

 

(2)职能

∙市场

▪推动市场和公关,以对目标客户发生效用

▪突出产品与其他竞争对手的区别性,以利于竞争

▪分发解决方案,以便用户能够容易地获得

▪为用户提供支持,以使其无论在购买还是使用过程中都留下正面的印象

∙业务价值

▪定义并维护项目的业务正确性

▪定义并衡量业务价值的实现和评价

∙发展客户

▪推动项目和解决方案的远景目标

▪负责客户期望值和沟通

∙产品计划

▪收集、分析客户和业务需求,并区分其优先级

▪执行市场调查、市场开拓和竞争对手分析

▪确定业务和成功的标准

▪识别多目标的发布计划

1.2项目管理

(3)目标

在项目的约束条件下完成解决方案。

整个团队的一个主要目标就是在项目的约束条件下完成项目。

项目的约束条件包括预算和进度等。

大部分项目会根据时间和资金的使用来衡量项目的结果。

为了实现这个目标,项目管理负责并推动进度表、功能集和预算资金。

他必须保证能够在正确的时间发布正确的项目或产品,保证正确理解了项目投资方的期望,并自始至终贯穿于项目执行过程中。

(4)职能

∙项目管理

▪跟踪和管理预算资金

▪管理控制进度表

▪推动风险管理流程

▪加强团队沟通和协调

▪跟踪进度和报告项目状态

▪管理资源分配

∙解决方案构建

▪推动整体项目设计

▪负责功能规

▪负责解决方案围和重要决定

∙流程控制

▪推动流程质量控制

▪定义并推荐可改进处

∙管理服务

▪实现项目的管理流程并提供支持

▪提供管理服务以保证高效的团队运作

1.3开发

(5)目标

按照功能规说明、《软件开发需求分析报告》和《总体结构设计》的要求进行开发。

功能规说明详细描述了整个团队将要提供给客户的交付物。

对整个团队来说,应该尽可能精确地按照功能规说明来实现整个项目,因为功能规说明可以看成是整个团队和客户之间所达成的共识。

开发人员必须按照客户需求和功能规说明来构建整个解决方案。

同时,开发人员还需要为整个团队提供技术方面的咨询,这样在设计和技术选择时可以尽量减少开发风险。

开发人员提供较低层次的功能设计,并预估完成设计所需的时间。

(6)职能

∙技术咨询

▪为团队提供技术咨询服务

▪评估并验证所用技术

▪积极参与功能规说明的创建和审核

▪定义开发标准

∙实现架构和设计

▪提供针对解决方案的应用程序、数据和技术细节,以便将企业架构映射到解决方案架构的实现上

▪负责并实现解决方案的逻辑和物理设计

∙应用程序开发

▪根据设计规编写代码以实现功能

▪在开发过程中进行代码审核,并共享知识和经验

▪在测试人员的帮助下,根据测试计划执行单元测试

∙架构开发

▪为自动安装开发脚本

▪开发安装文档

1.4测试

(7)目标

在确认所有的产品质量问题都得到妥善处理后,批准产品发布。

所有的软件产品在发布时都存在着缺陷。

最重要的是,在发布前,必须清楚地认识和鉴别出这些问题,可以以问题的形式给出解决方法,或者是给出如何绕开该问题的文档记录。

宁愿对于已知的问题,提供了文档或解决方法,也不要存在一些未知的问题。

因为这些未知的问题,可能会带来不可预知的后果。

(8)职能

∙计划测试

▪开发测试方法和计划

▪参与设置质量标准

▪开发测试说明

∙测试

▪开发并维护自动测试案例、工具和脚本

▪执行测试,以确定产品开发过程的状态

▪负责定义构造流程

∙测试报告

▪为团队提供与产品质量相关的数据

▪跟踪所有缺陷,并保证在发布前得到妥善处理

1.5角色共享

尽管团队组成包含了4种角色,但并不意味着一个团队至少需要4个成员,也不意味着一个人只能承担一种角色,重要的是这4种角色必须在一个团队中体现。

一般情况下,团队成员常常共享角色。

在一些较小的团队中,不同的角色只能进行兼任。

角色共享有两条重要原则:

一是开发组成员不能共享角色。

开发人员是项目的构建者,他们不应该从他们的主任务中分身。

如果对开发组成员要求额外的角色,往往会使得他们无法按时完成进度要求。

二是不要试图组合具有一定利益冲突的角色。

比如,产品管理和项目管理的利益具有冲突点,所以他们的角色不能组合。

产品管理注重满足客户需求,而项目管理主要关心在时间和预算的限度完成项目。

如果这两个角色组合在一起,那么在需求发生变更时,可能会发生一些情况,诸如没有足够地考虑客户满意度而忽略该变更,或者是没考虑对项目的冲击盲目地接受变更。

让不同的团队成员担任这样的角色有助于确保每个方面得到相当的考虑和重视程度。

同样,这也适用于组合开发人员和测试人员。

1.6开发小组

开发小组成员组成

性别

年龄

职务/职称

业务专业

本项目分工

所在单位

1.7专家小组

性别

年龄

职务/职称

业务专业

本项目分工

所在单位

专家小组负责系统开发过程中重要阶段的评审、导截流技术问题的解答和指导等。

主要目标是保证系统的理论先进性、更好的满足客户需求和保障开发质量。

2开发流程

在开发过程中,采用多里程碑式的过程模型,如图1所示。

而其中每一个循环均包含四个里程碑。

图1多里程碑模型

这四个里程碑组成的循环放大后如图2所示,称为“过程模型”。

图2过程模型

2.1达成共识

∙基本完成需求调研和分析(产品管理负责)

∙确定大方向和长中短期目标

∙所有角色都参与讨论并真正认同结论

∙产生的文档

▪常见用户情景:

覆盖80%以上功能

▪前景:

言简意赅地说明大方向,并有激励团队的作用

2.2完成项目计划

∙编写详细的功能规(项目管理)

∙在编程前想清楚所有功能流程,并引导用户明确需求

∙所有角色都参与审阅功能规

∙制订开发计划和进度表(开发团队)

∙制订测试计划和进度表(测试团队)

∙分配资源(人力和预算)

∙形成项目综合计划和综合进度表

2.3完成功能

∙开发人员分别完成自己的功能

∙进行版本合理的控制

∙对每一项可测试的功能进行测试,无需等待

∙通过测试用例,对功能进行完整和重复的检验

∙记录所有程序问题

∙实现解决缺陷的自动流程

∙按照综合进度表不断检查进度

2.4稳定与发布

∙测试组全面地测试功能,包括性能和稳定性

∙开发组全力配合解决缺陷

∙监测质量情况

∙预测发布日期

∙专家会诊机制

▪决定缺陷的优先度

▪决定哪些缺陷可以在下个里程碑或版本中解决

▪决定由谁解决某个缺陷

3代码管理

3.1编码规

请参看附录,系统开发编码规。

3.2版本管理

3.2.1概述

版本控制有如下好处:

∙可以获得连续的受版本控制的项目,并保存不同版本的区别以作比较

∙能获得版本控制工具中保存的任何版本

∙能够把出错或误操作的最新版的项目恢复到正确的历史版本

∙获得历史版本的详细信息

在开发过程中,核心程序员对版本进行控制、对系统源代码进行集中管理,并做好程序的备份和工作。

3.2.2代码管理

核心程序员根据系统结构设计和详细设计,对系统实现的功能进行分解,将实现各功能的小模块分配给项目组的开发人员,并事先设计好各模块的接口。

开发人员根据接口要求进行编码。

编码完成后进行单元测试。

单元测试由开发人员完成。

单元测试后开发人员将本部分模块代码上交给核心程序员,核心程序员负责加入模块后的系统测试。

系统的全部代码由核心程序员管理,其它开发人员负责配合进行各模块的开发。

4附录:

系统开发编码规

在开发中保持良好的编码规是十分重要的。

程序开发人员应该严格遵循系统开发编码规进行编码。

4.1类型级单位的命名

4.1.1类

在为类(class)命名前首先要知道它是什么,如果通过类名的提供的线索,你还是想不起这个类是什么的话,那么你的设计就还做的不够好。

超过三个词组成的混合名是容易造成系统各个实体间的混淆。

对于派生类的命名应该避免带其父类名,一个类的名字只与它自身有关,和它的父类叫什么无关。

1类命名

以Class声明的类,都必须以名词或名词短语命名,使用大写字母作为词的分隔,其他的字母均使用小写,名字的首字母使用大写不要使用下划线(_)。

如:

ClassIndicator

当类是一个特性(Attribute)时,以Attribute结尾,当类是一个异常(Exception)时,以Exception结尾,如:

Class ColorSetException

Class CauseExceptionAttribute

当类只需有一个对象实例(全局对象,比如Application等),必须以Class结尾,如:

Class ScreenClass

Class SystemClass

当类只用于作为其他类的基类,根据情况,以Base结尾:

MustInheritClassIndicatorBase

如果定义的类是一个窗体,那么名字的前面或后面必须加Frm。

在本系统编码中,对于前处理和处理器模块使用的窗体,在名字的后面加后缀Frm,在后处理模块中使用的窗体在名字的前面加前缀Frm。

如果是Web窗体,必须加后缀Page:

ClassPrintFrm:

InheritsForm ‘*Windows窗体

ClassStartPage:

InheritsPage ‘*Web窗体

2类库命名

目前命名空间正在越来越广泛的被采用,以避免不同厂商和团体类库间的类名冲突。

当未采用命名空间的时候,为了避免类名冲突,一般的做法是在类名前加上独特的前缀,两个字符就可以了,当然多用一些会更好。

例如:

John Johnson的数据结构类库可以用Jj做为前缀,如下:

class JjLinkList

4.1.2枚举和结构

同样必须以名词或名词短语命名。

最好体现枚举或结构的特点,如:

EnumColorButtons ''以复数结尾,表明这是一个枚举

StructureCustomerInfoRecord ''以Record结尾,表明这是一个结构体

4.1.3委派类型

普通的委派类型以描述动作的名词命名,以体现委派类型实例的功能:

DelegateSubDataSeeker(ByValSeekStringAsString)

用于事件处理的委派类型,必须以EventHandler结尾,如:

Delegate SubDataChangedEventHandler (ByValSenderAsObject,ByValeAsDataChangedEventArgs)

4.1.4接口

与其他类型不同,接口必须要由I作为前缀,并用形容词命名,突出表现实现接口的类将具有什么能力:

InterfaceISortable

4.1.5模块

模块不是类型,他的名称除了必须以名词命名外,必须加以后缀Module:

ModuleSharedFunctionsModule

上述所有规则的共同特点是,每个组成名称的词语都必须是大写开头,禁止完全大写或小写的名称。

4.2方法和属性的命名

4.2.1方法

最好采用与类命名一致的规则,无论是函数还是子程序,方法都必须以动词或动词短语命名。

无需区分函数和子程序,也无需指明返回类型。

SubOpen(ByValCommandStringAsString)

FunctionSetCopyNumber(ByValCopyNumberAsInteger)

参数需要指明ByVal还是ByRef,这一点写起来会让程序变长,但非常必要。

如果没有特别情况,都使用ByVal。

参数的命名方法,参考后面“变量的命名方法”。

需要重载的方法,一般不写Overloads,根据需要编写重载方法。

4.2.2属性

原则上字段(Field)是不能公开的,要访问字段的值,一般使用属性。

属性以简洁清晰的名词命名:

PropertyConcentrationAsSingle

PropertyCustomerAsCustomerTypes

4.2.3事件

事件是特殊的属性,只能在事件处理上下文中使用。

命名的原则一般是动词或动词的分词,通过时态表明事件发生的时间:

EventClickAsClickEventHandler

EventColorChangedAsColorChangedEventHangler

4.3变量和常数

常数以表明常数意义的名词命名,一般不区分常数的类型:

ConstDefaultConcentrationAsSingle=0.01

在严格要求的代码中,常数以c_开头,如c_DefaultConcentration,但最好不要用它,它会带来输入困难。

普通类型的变量,只要用有意义的名字命名即可,不可使用简称和无意义的名称诸如A,x1等,下面给出了良好的例子:

DimIndexAsInteger

DimNextMonthExpenditureAsDecimal

DimCustomerNameAsString

不能起太长的名字,应该尽量简洁,如下面的例子:

DimVariableUsedToStoreSystemInformationAsString ''*太复杂了

DimSystemInformationAsString ''* 正确,简单明了

DimsysInfoAsString ''* 错误,过于简单

特殊情况可以考虑一个字母的变量:

DimgAsGraphic

对于控件,应该指明控件的类型,方法是直接在变量后面加以类名:

FriendWithEventsNextPageButtonAsButton ''* 按钮

FriendWithEventsColorChoicerPanelAsPanel ''* 面版

FriendWithEventsCardFileOpenDialogAsFileOpenDialog''*文件打开对话框等等,无需规定某种类型的变量的前缀,只需把类型写在后面就行了,试对比下列代码:

btnCancel.Text=&Cancel

CancelButton.Text=&Cancel

显然后者更能使阅读者明白变量的类型是一个按钮。

4.4前缀

4.4.1对象

1标准对象

名称前缀例子说明

System.ArrayarrarrUsers用户集合

System.BooleanblnblnDoesUserExist用户是否存在

System.BytebytbytStreamContent字节流容

System.CharchrchrKeyPress按键

System.DateTimedtedteCreatedDateTime创建日期

System.DecimaldecdecYearlySaleQuota年度销售额

System.DoubledbldblTotalPrice总金额

System.IntergerintintMessages消息数

System.ObjectobjobjExternalFunction外部功能

System.SinglesngsngFinishRate完成率

System.StringstrstrLoginName登陆名称

System.ExceptionexcexcRet错误

System.EnumenmenmUserStates用户状态

StructurestustuEmployees员工类型

System.Data.SqlClient.SqlConnectionnnDatabase数据库连接

System.Data.SqlClient.SqlDataReadersdrsdrUserData用户数据读取器

2自定义对象

我们规定应该根据自定义对象的名称来确定该对象类型的前缀,例子如下:

对象:

SysSet

前缀:

ss

例子:

ssSafety

4.4.2变量/常量的围

根据变量与常量的生存周期,我们应该定义不同的生存周期前缀以示区别,以便我们清楚该变量/常量的围。

1类、模块、组件、控件

我们规定在类、模块、组件、控件围,变量的生存周期前缀应该添加“m_”(Module-模块)。

例子如下:

名称前缀例子说明

System.Arraym_arrm_arrUsers用户集合

System.Booleanm_blnm_blnDoesUserExist用户是否存在

System.Bytem_bytm_bytStreamContent字节流容

System.Charm_chrm_chrKeyPress按键

System.DateTimem_dtem_dteCreatedDateTime创建日期

System.Decimalm_decm_decYearlySaleQuota年度销售额

System.Doublem_dblm_dblTotalPrice总金额

System.Intergerm_intm_intMessages消息数

System.Objectm_objm_objExternalFunction外部功能

System.Singlem_sngm_sngFinishRate完成率

System.Stringm_strm_strLoginName登陆名称

2过程、函数、属性、事件

我们规定在过程、函数、属性、事件围,变量的生存周期前缀应该添加“o_”(Owner-私有)。

例子如下:

名称前缀例子说明

System.Arrayo_arro_arrUsers用户集合

System.Booleano_blno_blnDoesUserExist用户是否存在

System.Byteo_byto_bytStreamContent字节流容

System.Charo_chro_chrKeyPress按键

System.DateTimeo_dteo_dteCreatedDateTime创建日期

System.Decimalo_deco_decYearlySaleQuota年度销售额

System.Doubleo_dblo_dblTotalPrice总金额

4.5标签

标签就是用于Goto跳转的代码标识,由于Goto并不推荐使用,所以标签的使用也比较苛刻。

标签必须全部大写,中间的空格用下划线_代替,而且应该以_开头,比如:

_A_LABEL_EXAMPLE:

如此定义标签是为了与其他代码元素充分区别。

4.6名字空间

通常,一个工程使用一个名字空间,通常不需要用Namespace语句,而是在工程选项的“RootNamespace”中指定,使用根名字空间可以使代码更加整齐,容易修改,这一点是VB十足的优点。

名字空间的语法是:

公司名.产品名[.组件名的复数]

如:

NamespaceCOM.NET

NamespaceCOM.File.IO.Files

随便起一个名字空间的名字绝对不是一个好主意,一定要遵守上述规定。

4.7格式化

良好的格式化代码对我们的浏览与维护有相当的好处。

4.7.1块

.NET提供了#Region...#EndRegion块控制。

我们应该根据代码所实现的功能分类并以块组织起来。

4.7.2缩进

每个层次直接都应该以Tab进行缩进,而不是Space(空格键)。

4.7.3流

每个方法、函数、属性、事件应该有且只有一个入口和一个出口。

如果遇见多层嵌套而需要直接跳出的时候,请使用局部Boolean或者

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2