研发执行过程注意事项

为了规范研发过程，提高研发交付物的质量，保证需求、设计、实现、测试的完整链路可追踪，保障生产部署的正确性、可靠性、实时性以及自动化程度，对研发过程及产出物作以下要求：

需求阶段

需求阶段应进行充分需求沟通，给出明确的需求集合、准确的需求描述并文档化；应关注诸多非功能性需求或达成共识；应当给出需求优先级及验收标准（包括但不限于UI风格标准、界面交互标准、功能性标准、性能标准）。

应规范需求变更并将变更文档化，阶段性分析变更原因，持续优化需求过程以降低变更频率、减小变更范围。

设计阶段

应进行需求与设计的分离和边界界定，以明确区分需求变更与设计变更，尤其是系统间接口、交互方式变更。

关键系统架构、接口、流程、数据模型、系统间交互应进行完整描述并文档化：

• 系统架构设计应清晰描述系统整体架构、模块划分、交互、与外围系统的关系及交互，系统部署拓扑应与架构设计保持一致；
• 接口变化应抛出进行讨论、设计不合理部分也应抛出由小组讨论达成一致，接口设计应由上下游评审并形成纪要；评审后接口变更及时与上线游沟通；
• 数据模型定义应有一致的风格和行为习惯，应保证不同表之间的一致性；逻辑模型应与研发过程中的物理模型保持一致；数据模型变更应告知研发小组成员；数据模型应脚本化维护并进行版本管理；

研发阶段

研发阶段与测试阶段同步进行，研发与测试人员应同步与PO确认需求。

• 研发给出接口定义、数据模型定义并将关键部分抛出讨论确认；
• 测试给出测试方案、思维导图并于PO、研发确认沟通；
• 若设计与开发为不同成员，则设计人员也应参与讨论；开发与设计人员需做好充分沟通以防出现遗漏、偏差等；

开发

开发前务必获取最新代码、提交前务必获取最新代码并解决冲突，代码提交应遵循敏捷管理要求。
开发过程中应关心代码结构和效率：实现应尽量简单；避免频繁或大规模数据库操作；避免冗长及高耦合性代码。
开发完整功能提交后应关注编译部署是否成功，及时通知测试并关闭相应task。
配置、数据库脚本、部署脚本应与开发代码同步提交，并满足下述要求。

配置要求

配置项增加调整应同步修改开发、测试、集成、生产等环境，具体配置值可以留空。

数据库脚本要求

数据库（变更）应采用脚本维护并通过svn进行版本管理，集成环境发布一定要使用脚本进行。脚本应满足以下要求：

• 变更前数据备份
• 可重入
• 变更后正确性验证
• 升级失败后的恢复机制
• 规避脚本对执行环境的依赖（防止目标机上脚本执行失败）

部署脚本要求

开发、测试环境应通过Jenkins直接部署；集成、生产环境应通过部署脚本部署，脚本应通过svn进行版本管理，部署脚本应满足如下要求：

• 脚本可重复执行
• 提供标准命名脚本：deploy.sh、start.sh、restart.sh
• 部署包在不同环境的发布不应该对脚本内容进行修改，环境变量参数化
• 完全自动化，不应出现手动文件移动等人为操作
• 执行结果自检

测试

• 测试应关注需求变更，并负责需求变更的记录；
• 测试应绘制思维导图并于需求映射以提供完整的需求及验证视图，思维导图应与需求同步修改。
• 自动化测试脚本应可重入、不依赖系统数据、不影响系统数据；
• 自动化测试脚本应与思维导图对应，并最终映射到原始需求；
• 测试人员应保持独立性，完整记录系统缺陷、未实现功能、无法测试功能等；

延伸

DevOps标准实践
代码提交->review->构建->自动化测试->自动发布(发布策略)
集成&生产环境下多系统级联构建、依赖发布

前期

立项

需求分析&设计

资源准备

人员
外围资源及系统

1、前期工作
2、

工作量评估

软件工作量评估方法：http://www.cnblogs.com/yzbt/p/5266759.html

story point 评估法

敏捷估算方法，比较主观

功能点分析方法

CMMI标准采用
工具无关、项目无关
仅适用于功能性需求工作量评估
适用于管理系统、业务系统等传统领域研发，不适合创意型产品、非功能需求为主产品（如平台、框架）、包含复杂算法和核心技术产品

基于功能点（FP）的工作量估算，是从用户的角度来度量软件。进行工作量估算时，先估计出软件项目的功能点数，然后将功能点数（FP）转换为人天数。其中，估算功能点数的主要方法有3种：IFPUG法、MarkⅡ法、COSMIC FFP法。这三种方法现在都已经成为国际标准，并有详细的操作手册。
将功能点（FP）转换成人天数主要有2种方法。
1）生产率法：要求有开发商每人天开发的功能点数，估算出功能点数后，直接利用功能点数÷功能点/天，即得工作量人天数。对于开发商每人天开发的功能点数，SPR有统计，中国的值大约在5.5个功能点/人月。
2）经验模型法
可以依照本企业的历史数据得到关于功能点和工作量的统计方程；也可以采用已有的经验模型，例如：COCOMOⅡ模型

分类

数据

• ILF：Internal Logical File内部逻辑文件
  可以理解为业务对象，对应多个数据表
• EIF: External Interface File外部接口文件
  其它应用系统提供的接口数据
  操作/逻辑
• EI: External Input外部输入
  对应表单提交等
• EO: External Output外部输出
  仅仅输出，如导出、报表、打印等
• EQ: External Inquiry外部查询
  先要输入，根据输入计算输出

数据和操作应分开计算

调整因子

实际评估非功能性需求对工作量的影响，已整体调整因子的形式使用

代码行估算

基于代码行（SLOC）的工作量估算，是从开发者的技术角度出发来度量软件。代码行数是软件开发者最早进行规模测量的主要方法。进行工作量估算时，先采用WBS法、类比法等统计出软件项目的代码行数，然后将代码行数转换为人天数。其中，将代码行（SLOC）转换成人天数主要有2种方法。
(1）生产率方法：要求有开发商每人天开发的代码行数，估算出代码行数后，直接利用代码行数÷SLOC/人天，即得工作量人天数。
(2）参数模型法：利用模型，将代码行数转换成人天数。
常见的模型有：
Putnam模型
Putnam1978 年提出的一种动态多变量模型。估算工作量的公式是：K = L^3/(Ck3*td^4)

其中：L 代表源代码行数（以行计），K代表整个开发过程所花费的工作量（以人年计），td 表示开发持续时间（以年计），Ck表示技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异。
COCOMOⅡ模型
COCOMOⅡ模型指出，软件开发工作量与软件规模呈指数关系，并且工作量受16个成本驱动因子的影响。COCOMO Ⅱ的计算步骤如下：
1)估算软件规模Size，这里以千代码行（KSLOC）计。
2)评估比例因子SF，求指数E。
3)求成本驱动因子值EMi。求标称进度工作量PM：

IBM模型
IBM模型是1977年IBM公司的Walston和Felix提出的。其中估算工作量的公式如下：E=5.2×L^0.91 ，L是源代码行数（以千行计），E是工作量（以人月计）

专家法估算

即组织专家对任务/拆分后的子任务进行规模评估，最终得到多数认可的软件规模。

• 每位专家提出3个规模的估计值：最小值ai、最大可能值mi、最大值bi
• 组织者整理，计算每位专家的平均值Ei = （ ai +4 mi + bi ）/6 ；计算期望值：E = (E1+……+En)/n
• 综合结果后，再次填写表格，比较估算偏差，找出原因
• 重复多次，最终获得一个多数认可的软件规模

WBS估算法

WBS：work breakdown structure

适合瀑布模型，在敏捷的迭代中也可使用；更多取其思想

拆分后任务工作量可采用专家评估法进行

1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；
2）进行WBS分解，力所能及地将整个项目的任务进行分解；
3）参考类似项目的数据，采用类比法或专家法，估计WBS中每类活动的工作量；
4）汇总得到项目的总工作量；
5）与第1）步的结果进行印证分析，根据分析结果，确定估计结果。

非功能性需求

SNAP：Software Non-functional Assessment Process
APM：Assessment Practices Manual

http://www.ifpug.org/about-ifpug/about-function-point-analysis/