研发执行过程注意事项
为了规范研发过程，提高研发交付物的质量，保证需求、设计、实现、测试的完整链路可追踪，保障生产部署的正确性、可靠性、实时性以及自动化程度，对研发过程及产出物作以下要求：
需求阶段
需求阶段应进行充分需求沟通，给出明确的需求集合、准确的需求描述并文档化；应关注诸多非功能性需求或达成共识；应当给出需求优先级及验收标准（包括但不限于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 = L3/(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/
