软件研发管理方案（草案）

1、软件研发管理方案(java)石油数据应用研发部文件状态:v草稿正式发布正在修改文件范围：部门内部使用当前版本：0. 1作者：徐磊版木历史版木/状态作者参与者起止日期备注0. 1徐磊2012 年 11 h 20 n目录一、文档目的1二、缩略语说明1三、研发过程管理11. 综述12. 需求确认13. 架构设计34. 迭代开发65. 测试验收8四、部门交接及岗位说明91、部门交接92、测试人员93、开发人员94、项目经理10五、源代码管理101. 代码的风格102. 代码的提交12六、项目部内部交流141. 定期交流142. 不定期交流14七、项目文档管理（含代码）15附录：捉交的文档模板17一、

2、文档目的作为项目开发的指导，可以根据具体项目大小进行裁剪，忽略其 中部分步骤。（10人月以上的项目，必须遵照执行。10人月以下的项 目可以省略迭代开发中的uc文档和详细设计过程以及内部的交叉测 试，但是必须在开发过程中进行2次的集成测试，测试人员需要参 与。）缩略语说明uc： usercase用例文档三、研发过程管理1. 综述研发过程分为需求、架构、开发、测试四个阶段，每个阶段需要 提交特定的文档，并通过负责人组织评审验收，才能进入下一阶段。2. 需求确认2. 1需求具体分为两个部分，功能性需求和非功能性需求。功 能性需求为用户提出的具体功能，非功能性需求包括了系统的硬件要 求、性能【启动时间

3、，页面刷新时间，每个功能的完成时间】、并发 数量，吞吐量【单位时间处理事务的能力】、可靠性：7*24 99.9% 全 年当机吋间不超过8小吋】、健壮性：系统出问题之后的恢复能力【5 秒内恢复】等方面的需求。【括号内为举例】2. 2需求收集阶段细分为三个阶段：2. 2. 1、大目标：系统做完之后需要达到的状态。根据甲方项 目发起人的概念性描述产生的功能范围界定。2. 2. 2、功能：由第一点拆解而来。（部门（科室）负责人）产 生条目化的功能列表，并归类为业务模块，包括和甲方单位现有的其 它系统之间需要调用的功能。根据描述产生功能栏图（各模块之间的 关系）和功能列表，根据系统需求，必要时列出甲方的

4、组织机构图。 完成之后要评审，参与者为：用户、需求调研团队（包括项目经理）， 进行查漏补缺。产生的文档可以作为合同的附件。2. 2. 3、场景：每个功能的流程描述，是具体工作的文字实现。 包括该功能的输入、输岀、具体工作流程。主要是业务的细节的体现， （具体业务人员）细化第二点的每个条目，分为小的功能点，对功能 点进行具体的业务描述，根据情况加入数据量的分析，比如一次需要 操作多少数据。场景描述不能只描述用户的日常工作流程，更重要的是捕获工作 中的困难。比如井的管理，不仅要有直井的输入，还要考虑到分支井 的处理，否则用户使用系统，就会有许多限制，无法完成所有的工作。针对以上的业务描述，评估开发

5、语言和存储方式（数据库或文件）。 产生的输出为业务场景描述。以上三个部分的输岀综合产生需求定义，包括三个层次的需 求说明。具体格式参见附表。2. 3需求的变更必须甲方和项目经理协商，经过成本核算，评 估时间后，决定是否变更。需求变更的评估：2. 3. 1、价值评估：变更能产生多少价值。需要和用户沟通。2. 3. 2、架构评估：产生设计变更的任务，变更任务的工作量。2. 3. 3、影响面：变更会影响其他那些模块。2. 3. 4、开发人员评估变更成本。需要多长时间。2. 3. 5、进行总体的成本评估。（所有开发人员的成本）人/日。需求的变更需要产生变更评估文档，一个项目产生一个评估文档, 每次变更

6、之后，记入文档，项目完结吋可以作为和甲方追加经费的根 据或者是项目延期的说明。使用的工具为 word、visio> powerdesigner。其屮1、2两点必须由对外协作部（对外协作部负责的项目）或 项口经理负责实施。第3点可以根据项口情况，由项口经理或开发人 员实施。3. 架构设计架构设计阶段需要针对需求定义文档，从开发的角度，对软件功 能划分模块，设计模块之间的接口，并分析可以通用的功能模块，设 计领域模型，完成数据库的表结构划分，根据非功能性需求中性能要 求，决定是否对表进一步划分。通过功能划分和具体的性能要求，对需求阶段决定的开发语言和 存储方式（数据库或文件）或第三方的组件进

7、行调整，对部署方式进 行规划，并对项冃进度做出预先评估，给出每个模块的大致开发进度 表。模块的划分原则上按照业务逻辑来划分。模块接口设计原则：1、根据功能设计接口，分析功能，考虑那些功能会被其他功能 调用，针对每个功能设计一个接口。2、不要根据调用方设计接口。会导致接口不稳定。3、接口设计的传入和传出参数，尽量要具备业务含义，避免基 木数据类型，使用领域模型作为接口参数。4、避免接口的泛化，尤其是要避免map、object类型。需要使 用的时候必须map内的参数进彳亍注释说明，对每个key和value的类 型和业务含义进行说明。5、接口设计使用接口单一原则，保障接口小，功能单一。未来 通过对接

8、口组合，委让形式，调用方组合使用接口，同吋使用多个接 口。把接口作为属性。6、接口名称定义一定要清晰。领域模型设计原则：1、领域模型一般都有一个基类，其他都继承。使用贫血模型， 里面只包含数据和非功能性方法，例如guid, clone,比较等方法。2、关键是pojo需要业务原生，比如井和组织机构，井就是一个 领域模型对象，组织机构也是一个领域模型对象。要现实井树的逻辑， 需耍在业务层组合两个数据。而不是用sql语句的join来实现，让领 域模型暴露出一个给111混合数据的方法。这样可以方便领域对象的复 用，和领域模型的伸缩性。同时也简化了领域模型的实现。持久层设计原则：非性能要求特别高，-般不

9、要使用内存数据库，即使要使用也要 用在读多写少的场景。现阶段推荐使用mybatis、hibernate这样的轻量级框架。该阶段的输出为模块划分图（含接口描述和并发描述以及分层的 描述，要到业务类的级别）、部署视图、项目进度表（project）、需要 使用第三方工具和底层框架、数据字典、领域模型（需求收集人员对 模块做领域模型，项冃经理开会汇总评审确定，输d java代码），需 要的话，可以加上模块间的调用时序图。输出文档在确定z前，项目 经理要和团队一起确认该文档，确保团队内部对开发工作的整体了解。 模板参见附件。使用的丄具为powerdesinger（数据字典）、java代码（领域模型）、

10、project o*现阶段暂时不考虑框架设计，直接使用ssh的开源框架，持久 层的设计可以选择 hibernate、mybatis, mvc 使用 struts2 或 spring mvc, 日志使用log4j、slf4jo 贝面展示组件：前台显示：jquery> layeroajax 组件:jquery, dwr。树:ztree, dtree, mztreeview（梅花雪树）,可选：dhtmlxtree表格：gtgrid （js组件），ectable （jsp标签实现）绘图：jfreechart （服务器端组件）扌艮表：jasperreports+ireport> jrepor

11、t> poiweb service： axis, cfx, xfire 或者 jdk6 自带4. 迭代开发原则上所有项目都要使用迭代式开发，以保障项目的进度和质量。项目经理根据架构设计，确定每个迭代周期的模块开发顺序。迭 代开发周期的时间分为两个部分：编写文档和编写代码。文档写完之 后评审，确认文档才能进入编码阶段。uc文档包含页面的元素的来源、约束。详细设计文档必须包含具体业务类的实现方法，处理流程、时序。（不需要类似action类和pojo类的描述）迭代周期内工作如下（迭代周期1-2周，一日写uc、一fi写详 细设计，3日开发，半日测试）：召开项冃组内部会议，由项冃经理和开发人员一同

12、决定木周期开 发任务的计划安排。开发人员根据自己负责的任务和框架设计文档，编写uc文档和详细设计文档。模板参见附件。编写完毕之后，组织内部会议，对每个开发人员编写的uc文档 和详细设计文档进行评审，项目经理和用户沟通，确认文档（在用户 无法快速沟通确认的情况下，由需求收集人员确认）。项目经理根据详细设计文档，将开发任务划分到3个工作日，并 根据开发人员自己的意愿，确认每个开发人员的任务。每迭代周期的第一个工作日上午和第三个工作h下午，组织内部 会议，开发人员汇报各自的开发进度。迭代完成之后，开发人员提交代码，团队内部要对代码进行交叉 评审，有问题的代码要重新编写提交。根据项口情况，若干个迭代周

13、期之后（1个月），由构建服务器 打包发布到测试服务器，测试人员根据uc文档编写测试用例进行测 试，测试结果由测试人员,提交bug记录（暂定使用bugzilla）o测试 完成之后，下一个迭代周期之前，完成功能性bug修正，轻微bug 可以集屮在一个阶段z后集屮修正，具体时间由项目经理决定。测试人员向项目经理，提交测试报告。项目经理根据测试报告、实际开发时间，编写项目阶段性汇总报 告。以word文档形式提供，包含bug统计、实际延期情况、本阶段 完成关键点。该阶段的输出为uc文档、详细设计、测试用例、bug记录（在 线提交）、阶段性汇总报告以及代码。模板参见附件。使用的工具为 word、excel

14、、eclipse。*迭代式开发关键：1、任务的细分，细分的任务一方面可以精确的控制精度和开发 质量，另一方还可以作为绩效考核的根据。2、及时的测试，提早进行的测试可以确保后期尽量少的修补bug, 提高质量，缩短开发进度。3、制定合理的开发计划，开发任务的粒度在8小时内（现阶段 暂定为3个工作日）。包括uc编写、dd设计、代码的编写。项目经 理一定要与开发人员交流，来确定时间。计划重点是要合理，而不是压缩时间。4、ci+bv保障代码的每日提交和构建（现阶段暂定为一个迭代周 期完成之后构建）。5. 测试验收迭代开发完成之后，需要进行一次内部测试（alpha测试，在内 部测试服务器上运行）和用户参与

15、试运行测试（beta测试，在甲方的 生产环境上测试）。alpha测试包括了功能测试、性能测试两个方面，测试的依据为 开发阶段编写的测试用例。完成测试并修正bug之后，需要测试人员 编写出用户手册。beta测试只包括功能测试，测试依据为上一阶段编 写的用户手册和需求确认文档（由项目组提交）。内部测试时，需要先确定测试计划：1、执行哪些测试用例，确定测试的范围。2、测试用例的列表,谁来执行,具体时间。测试的原则：1、一次测试计划下来，不要重启软件，避免状态改变。2、测试用例要按功能栏图的流程来。该阶段输出为用户手册、bug列表。使用的工具为wordo四、部门交接及岗位说明1、部门交接对外协作部负责

16、需求确认的2.2.1和2.2.2两个部分，提交“需求 定义”文档。2、测试人员迭代开发阶段，对外协作部的测试人员参与集成测试。提交“测 试用例”和“测试报告”，并在bugzilla里提交bug。测试阶段，对外协作部的测试人员全程参与，提交“用户手册” 和“测试报告”。3、开发人员迭代开发阶段，提交“uc文档”、“详细设计”以及编写的代码。4、项目经理架构设计阶段，提交模块划分图、分层设计图、部署视图、项目 进度表、架构设计文档、领域模型。五、源代码管理1 代码的风格必须按照规范编写注释和代码java：代码必须使用eclipse的代码格式化工具（ctrl+shift+f）格 式化之后才能提交（暂

17、定eclipse默认的风格）。能够通过pmd的验证。jsp：样式、数据分离。html：样式与标签分离xml：如果数据中有大于小于号，用!cdata覆盖内容java代码参考规范：命名规则：包名全部以小写字母组成，以点号分隔。首个包名单词为：como 第二个单词可以为jpsofto第三个单词为工程或项目简称（必须有）。 如：油井远程测控:wrm0结杲可以为以下几种：com.jpsoft.wrm其后的包名单词，遵循以下两种顺序中的一种。1）、先分层,后分模块。如:com.jpsoft.wrm>com.jpsoft.wrm.2）、先分模块后分层如：com.jp.wrm.alarm|ervicea

18、）类名首字母大写，其后每个单词的首字母大写其余小写。类名要具有名词性质。接口名首字母为大写i,接口实现类不需要大写字 母i,其余部分与接口名相同，最后加上impl.如：lalarmdaoalarmdaoimpib）方法名首字母小写，其余单词首字母大写。方法名应具有动词 性质。c）变量名首字母小写，其余单词首字母大写注：所有的命名要尽量体现业务含义，用途。可以使用通用的缩 写形式或易于理解的缩写。1.2注释规则：1.2.1java类文件的注释，要统一格式可以在eclipse中预先设定 好。如：/ * *项油井远程测控系统*公司：湖北荆鹏* 作者：陈文,2012-11-19 上午 10:10:35

19、*描述：短信报警屮的短信发送*说明:*/1.2.2方法注释采用多行注释法，写明方法用途，参数，返回值， 异常等信息。对应接口方法与实现类方法,可以只在接口中写明注释。 如*更新已发送的报警短信内容* gparamusld string用户编码* paramalarmld string扌艮警定.义主键1.2.3代码注释。方法内的代码，关键变量，关键流程控制，关键算法需要有必要注释。注释形式可以为单行或多行。1.3编码规则 1.3.1类文件中的代码行数不超过800行，特殊情况除外。1.3.2单个方法中的代码行数不超过100行，特殊情况除外。1.3.3代码中未使用到的变量，未使用到的导包语句要清理掉。1.3.4代码中设置的断点，使用system, out. print等语彳ij做调试的，在代码提交前清理掉。并在清理完成后，再做一次测试，确认无 误再提交代码。1.3.5方法的定义中，参数的个数最多不超过5个，特殊情况除外。2.代码的提交开发人员在迭代开发的每个工作日下午5点半之前，捉交当日完 成的代码（可以正常运行，没有完成的方法，可以在注释方法内部的 代码之后提交），下一个工作日编码之前，必须下载新的