手机软件开发管理办法

目录

1.      适用范围

2.      工作职责

2.1   软件主管

2.2   项目经理

2.3   系统开发

2.4   驱动调试

2.5   应用开发

2.6   软件质量管理

3.      开发过程管理

4.      软件缺陷管理

4.1   目的

4.2   适用范围

4.3   定义

4.4   缺陷定义

4.5   缺陷生命周期

4.6   缺陷状态说明

4.7   缺陷处理过程

4.8   特别处理过程

4.9   缺陷管理工具

4.10 缺陷属性定义

---

1.      适用范围

本办法适用于公司手机产品的软件开发管理，办法规定了手机产品软件设计开发职责、各阶段的工作内容、运作程序和开发项目计划管理和周期管理要求。

2.    工作职责

2.1   软件主管

统筹安排软件组的工作，人员管理；

根据手机项目开发需求，带领团队为手机项目开发配套的软件系统；

依据公司发展计划，储备软件前沿技术，为新项目提供解决方案；

解决项目开发过程中的流程、制度、资源或管理等相关问题；

了解软件开发方面的市场信息，把握技术发展方向；

2.2   项目经理

组建项目团队，安排任务分工；

组织需求、设计评估；

制定项目软件开发及测试计划，并跟进实施；

管理和协调内外部资源，确保软件按计划，高质量完成；

定时召开项目会议，把控项目风险及进度；

协调解决项目开发过程中的流程、制度、资源或管理等相关问题。

2.3   系统开发

系统功能开发，包括framework、hal、recovery、bootloader、diag等模块；

维护系统稳定，解决包括重启、死机等系统问题；

优化系统性能，包括系统卡顿、发热、第三方功耗等问题；

解决系统bug，包括第三方应用适配、TP、NFC、sensor、GPS、wifi、BT等相关外设的bug，以及系统的疑难杂症；

2.4   驱动调试

参与手机关键器件选型；

负责LCD、TP、Modem、camera、WIFI、BT及其他sensor的驱动调试；

负责对手机各外设性能进行优化；

确保网络、通话、显示及照相等模块的稳定性；

驱动相关bug的分析解决；

2.5   应用开发

负责系统应用开发，包括电话、联系人、短信、Launcher、setting、文件管理器等；

负责工程测试模式、工厂测试模式及自动化测试的开发；

负责三方应用的适配及部分开发工作；

确保应用稳定性及性能优化，解决应用相关bug；

负责软件版本集成及管理；

2.6   软件质量管理

通过监控软件开发过程来保证产品质量; 

保证开发出来的软件和软件开发过程符合相应标准与规程；

保证软件产品、软件过程中存在的不符合问题得到处理,必要时将问题反映给高级管理者；

确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要;

3.      开发过程管理

软件开发过程标准化

软件开发过程：

需求分析---设计评审---编程---测试---发布验收

需求分析：对开发需求进行充分评估，提出修改建议

设计评审：研发、设计及QA共同评审设计（功能、交互、UI）是否能够开发，形成产品规格说明书（软件产品定义）。

编程：研发跟进需求及设计规格进行代码编程，遵循《JAVA编程规范》，编写开发完成并经自测试后提交测试。

软件测试

（1）BVT测试：Base Version Test确认软件版本实现了基本功能，可测安排进一步的测试；——A类测试用例

（2）FC测试阶段：Feature Complete确认软件的基本特征功能实现，如UI核对测试；

（3）CC阶段（Full test）：Code Complete；确认所有功能实现，软件架构无需重大改动；

（4）RC阶段（Full test）：Release Complete；确认软件版本可以用于批量生产并且发布给用户使用；

（5） 模拟用户测试阶段：模拟用户购机后15天的使用情况，确保用户购机后15天不会发生导致退机的故障。如待机功耗、系统稳定性、产品性能等测试；——品质验收阶段+内部用户试用阶段

（6）  FOTA用户在线升级阶段：Fireware Over-The-Air；针对用户投诉的问题/上市后期内部测试发现的问题进行定向修复升级；

（7） 自动化测试：

     软件测试的自动化，是把以人为驱动的测试行为转化为机器执行的一种过程。借助自动化测试可以实现长时间压力测试和采集到高精度的测试数据，是当前手机测试行业的新方向。

（8） 典型的自动化测试（编写自动化测试脚本/apk）如：monkey测试，将adb命令直接运行在Android设备中产生用户或系统的伪随机事件流，一般健壮的系统10台样机经受连续72小时测试而不发生死机（MTBF≥720小时的情况下，可以模拟用户连续使用一个月不死机）。

（9）  自动化测试机器人（稳定性测试、续航自动化、功耗自动化）

      通过机器人模拟人工操作，以机电一体化方式实现终端自动化测试 ，测试用例制作简单，不需要编写测试脚本即可创建自动化测试用例 。

（10） 自动化测试机器人（响应时间测试、流畅度测试）

集成帧率为240帧的工业级相机，采集手机界面元素，捕获运动过程 。

?       视觉图形处理技术，快速、准确识别和分析图像元素轮廓 。

?       追踪画面元素的位移及速度，自动分析运动过程卡帧数据 。

?       有效管理测试机型，便于分析手机流畅度指标，比较竞品性能 。

检查验收

内部循环滚动测试完成，达到大批量生产标准，提交检测中心检测验收。

验收标准：标管部---《Bug严重等级及判定标准》

规范及流程文档

（1）  《软件版本号命名规范》   OS-R-001

（2）      《Bug分类及优先级判断标准》  OS-R-002

（3）    《Bug采集路径及分类等级规范》  OS-R-003

（4）     《Git代码管理工具使用规范》 OS-R-004

（5）     《软件Bug解决绩效管理规范》 OS-R-005

（6）     《软件版本发布流程》 OS-R-006

（7）     《Camera调试规范》OS-R-007

（8）     《重大问题临时版本测试流程》 OS-R-008

（9）    《禅道系统Bug状态流转流程》

（10）     《Bug优先级降级流程》

（11）      《生产正式软件版本发布流程》

4.      软件缺陷管理

4.1   目的

定义软件缺陷管理相关规则，确保软件缺陷管理系统性和规范性，以保证项目研发质量。

4.2   适用范围

适用于部门项目研发过程的缺陷管理，对各个阶段的缺陷管理过程进行指导和规范。

4.3   定义

术语

缺陷：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。

Bug:缺陷的一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。

4.4   缺陷定义

（1）软件未达到需求规格说明书的功能；

（2）软件出现了需求规格说明书指明不会出现的错误；

（3）软件功能超出需求规格说明书的范围；

（4）软件未达到需求规格说明书未指出但应达到的目标；

（5）测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。

4.5   缺陷生命周期

缺陷生命周期图

4.6   缺陷状态说明

4.7   缺陷处理过程

（1）创建问题

         在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。在创建问题时，需要描述清楚，并选择正确选项。

（2）指派问题

         创建问题时，创建者通常要指派给该项目开发负责人，在由其指派任务，或直接指派给相应模块的开发工程师。

如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。

（3）确认问题

         通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。

         当创建者收到确认指派时，需要进行及时确认。如果同意为非Bug，则及时关闭它。如果不同意，则需要注明理由并指派回相关工程师。

如果确认问题指派有异议时，则需要指派给质量工程师（SQA）评定。

（4）解决问题

         此为开发工程师的主要职责，报告Bug的复现、修改、修改验证。

         开发工程师需要及时对确认状态的Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则。在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。

         如果Bug无法修复或者修改影响比较大，可申请进入“延期解决”流程，此类问题需要指派给质量工程师（SQA）评定。

（5）验证问题

         创建者需要及时对解决状态的Bug在对应的版本上面进行验证。如果验证通过，则可备注关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。

验证通过准则：相同的操作步骤，进行一定次数的验证测试都没有发生。

验证不通过准则：相同的操作步骤，全部或部分实际结果还会发生，验证不通过则激活Bug。

（6）关闭问题

         通过验证的Bug，验证者需要注明验证结果并进行关闭操作，系统将指派给Closed。

         如果关闭状态的Bug在之后的版本又会发生，则激活此Bug，系统将自动指派回给解决者。

4.8   特别处理过程

（1）售后问题

         售后客户问题可以由合入直接反馈给售后专员，售后专员将问题反馈给研发测试及项目经理，经过确认问题后提交到缺陷管理系统，按照以上流程处理，由创建者或测试组跟踪验证关闭。

         创建售后问题是，创建者需要在Bug标题开头标记为【售后反馈】，测试组负责检查和更正。

（2）争议处理

         当开发和测试工程师对某问题有争议且多次沟通无果时，可注明双方理由，指派给质量工程师（SQA）评定。项目经理或质量工程师召开评审会议，直接与双方沟通了解，根据项目情况给出最终决定，开发和测试根据项目经理或质量工程师的最终决定执行。

（3）延期解决

         当开发工程师对确认Bug进行解决时，发现或评估其解决时间紧或者风险比较大等，可以说明原因或理由指派给质量工程师（SQA）或项目经理确认。项目经理或质量工程师召开评审会议，根据项目情况给出最终决定。如果不同意，将此Bug指派回开发工程师，开发工程师继续分析和解决。如果同意，处理Bug状态为“延期解决”并且注明解决时间及计划指派回开发工程师，开发工程师根据解决时间来规划解决此Bug。

4.9   缺陷管理工具

         软件测试过程中多有缺陷要提交到缺陷管理系统进行跟踪管理。

（1）管理工具的作用

         a.确保每个被发现的缺陷都能够被跟踪处理。

         b.收集缺陷数据并根据缺陷趋势曲线识别或报告测试状态。

         c.收集缺陷数据并在其上进行数据分析，作为测试评估的依据。

（2）缺陷驱动原则

         缺陷管理系统主要通过指派状态来驱动相关开发工程师、测试人员和项目经理尽快的处理问题，以提高研发效率，所以会特别关注缺陷指派给谁和停留时间，并反馈在定期报告。

所以，缺陷驱动原则：尽量不要人缺陷挂你身上。

4.10 缺陷属性定义

参考禅道系统现有属性及《Bug优先等级判断标准》

质量工程师（SQA）定期对缺陷管理系统的缺陷数据进行汇总分析，及时发现研发过程的问题点，提出预警，通过解决问题的情况反映项目软件当前的质量状况，同时也可对项目研发人员进行绩效考核数据来源，软件开发的标准化，流程执行到位，严格按照软件计划与规范标准执行逐步开发，才能开发出高质量的软件产品，使软件质量得到保证。