智能手机软件设计方案快速重建模式的研究

开篇：润墨网以专业的文秘视角，为您筛选了一篇智能手机软件设计方案快速重建模式的研究范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘 要目前市场上流行的智能手机软件设计方案很多，各种方案不光是由主芯片的供应商决定，比如联发科（MTK）方案，或者展讯（Spreadtrum）等。在这个基础上还有可能会牵涉到各种手机系统软件提供商的支持，比如YunOs操作系统，360操作系统等。这样对手机设计项目方案提供商来说有利有弊，好处在于软件开发上的压力会变小，因为这里有手机系统软件供应商如YunOs等的技术支持。坏处是软件项目过程涉及过多环节过多，涉及不同公司参与需要良好的协调，否则软件项目过程不受控，而且软件质量也不能很好被管控，参与的各方都有可能引入问题到最终的软件中。但是目前手机方案的市场竞争又很激烈，基本的要求就是在短期内要实现有一定参考基础的软件衍生项目的开发，使其市场化。这个^程中要使得项目既能保持软件质量又要短期内实现这个目标，对于这种软件项目的开发就需要开发模式上做一些改进，本文探讨了这种软件快速重建模式的设计。

【关键词】手机软件设计 软件快速重建模式 软件项目过程 软件质量

1 软件需求继承性的管理

对于目前的手机设计公司来说承接的业务大多数是需求有继承性的项目，对于需求的差异性很大，开发需求很复杂且之前不是很有积累的需求，无论是手机设计方案商还是手机制造商来说都是很谨慎的。大家对于这里的风险意识都是一样的强烈。所以一般情况下手机设计公司承接的都是有软件需求可以继承之前有积累的项目。而对于这些需求的继承性的管理是快速实现这些需求的软件项目的关键。如何实现这些软件需求的高效继承使用呢？

1.1 使用合适的软件项目版本管理工具

软件项目的版本管理工具中CVS， Git， Repo等都可以用来管理手机软件项目的开发过程。其中Git和Repo是用于多方合作的分布式版本控制系统，它就适合于类似目前的智能手机开发管理的现状。这里涉及手机硬件平台的方案提供商，手机软件提供商，还有手机设计公司共同开发一个项目。关键是Git 和Repo能够方便的实现各种需求在软件版本上的继承和快速的合入。一般Git和Repo上会建有主线（master）工程，这里主要是平台的基础内容，各种软件平台上开发出的新内容都往上添加，是平台发展的基础。当然主线上的内容由于来自各种开发的新内容的导入，往往存在有各种问题，而且主线是实时被更新，也来不及测试它的稳定性。鉴于上述的状况一般真正要实现的项目都是在一定状态的主线上建立起来的分支进行单独管理的，对于分支（branch）上的管理是需要软件项目负责人（SPL）来管控的。SPL（Software Project Leader）对于开发（包括MMI和Driver ）的工作成果，根据各个项目的需求点对点地合入各自项目的分支，如：用Git指令git cherry-pick。每种不同的软件需求，这里主要是指人机交互（MMI）上的功能需求，在某个平台上有了一个完整的需求功能分支，并且这个分支的软件产品已经量产且被市场认可验证过，那么后续相似的项目都可以用来继承该分支。那么越是后来的项目越是能继承之前项目的成果，它实现的过程就能更加的快捷和可靠，实现软件的复用。

1.2 对于需求和共性Bug建立良好的文档管理机制

对于需求的继承光有版本管理工具的分支管理是不够的，毕竟管理工具上记录的每条提交记录（Commit Infomation）都是离散的，同时由于提交时的不谨慎，可能导致相同功能模块的多次提交，这样就要求SPL（Software Project Leader）在合入时要清晰了解合入的顺序和具体的Commit ID信息。所以有一份详细的功能合入文档信息就很有必要了。文档里需要记录的内容有：

（1）需求或者Bug的详细描述，需求和Bug在他们各自管理系统里的信息记录。

（2）Bug处理责任人的信息。

（3）对应修改所涉及的makefile里的宏控制信息。

（4）提到到软件管理工具（Git）的Git log信息，按提交顺序记录。这里的信息要具体到文件和其目录。

（5）简单描述修改处理的方法。

这样的信息要根据不同的需求分别建立起来，开发人员要在对应的文档里更新迭代。上面提到的Bug主要是共性Bug。

1.3 需求共性Bug核对自动化点检机制

运用脚本工具在软件编译前对一些关键需求和重要共性Bug的合入情况做自动化的点检工作，在编译的初期就对相关内容在整个软件工程里的配置情况进行自动化点检。如果软件配置有问题就可以在编译开始时就被检查出来，让SPL尽早发现和修改。这里就需要前面的文档管理工作做的好一些，既可以作为记录让那个项目参与人员查阅，同时也要适合自动化点检工具用来查询比较使用。这里可以被自动化工具用来点检的项有：

（1）平台的共性bug；

（2）硬件资源的配置状态如：PCM（phase change memory），G-sensor；

（3）平台共性修改需求，如：YunOS系统验收规则。

1.4 对于不同项目间进行需求分析，准确判断之间的继承性关系

要让上面3点发挥作用，首先要对于需求之间是否有继承性要有精准的判断。对于同一个客户的需求往往判断其继承性很容易，因为同一个客户他们的某个需求在不同项目间会有继承。但是对于不同客户之间的需求往往也存在的很大的相似性，那么如果能准确找出从一个合适的成熟量产项目的分支上进行继承做，自然也会事半功倍。当然并非说成熟量产项目就一定没有问题，如果主线（master）上确认有很重要的内容需要合入分支，那也是要在各个项目分支上实时合入的。比如MTK或者Spreadtrum释放的重要平台patch等。这也可以用类似被上面第1.2点提到的文档进行管理的。需求的共性特性需要前方的客户经理来主导判断，因为他们更熟悉客户需求，后端的SPL当然是这个继承行为的实施者。

2 项目系统配置和驱动配置的敏捷切换

实践当中项目部门在立项过程中有意识的做一些固定的切换来适应市场的需要，比如软件需求基本不变的情况下引导客户做手机频道的切换，比如从TDD的三模（如表1）切换成五模（如表2）或者6模（全网通）。

对于这样项目的切换，如果总是从方案商提供的默认的频段配置方式出发来配置工程，那么对于一个三模切换到五模的项目总是要从五模配置的方案商提供的Release参考makefile和工程目录配置方式出发，那么原来三模配置项目中的makefile里的关于软件项目的配置选项，比如宏，比如工程目标目录里的配置项涉及到该客户的软件需求的都要移植过来，当然就还要在重新测试需求。因为这个过程中需求相当于重新移植配置。这个过程对于一个项目来说本身无可厚非，但是对于敏捷实现一个项目来说，它不但当SPL重新移植了客户需求，同时增加了客户需求测试点检的需要，从整体上讲这种重建工程的方式对于该项目的重建的成本投入就很高了。如果换种思路，如果开发中的驱动工程师能从根本上就总结好从三模的项目配置改成五模的项目配置过程中需要修改的配置项，只要总结好一次且验证OK的情况下，下一次配置的时候就能轻松重建，这样的总结对于不断有这种项目切换的项目团队来说是很有益处的。它使得项目重建过程更为简单且引入的问题控制在一个范围里。即便真有频段配置的问题项目团队也能清晰知道问题所在的范围。如果过分坚持驱动工作的流程就是要从方案Release状态的五模参考配置方式出发，虽然从驱动工作的角度出发，可能提高的配置的正确性，但是对于整体项目的推进却是添加了阻力的。相反针对项目需要敏捷切换的显示做一些系统配置工作的方式切换却可以使得原来三模项目的客户需求修改被更好的被继承，同时测试的反复缺失需求也可以不那么必要了，整体上来说就有进度推进的优势，而对于驱动本身来说，只要做一次这样的认真切换工作的研究，下一次也是可以很快的重建这个过程，所需要的只是一次认真的总结。这种各种需求的来回切换需要不同的支持不能综合考虑支持，尽量从整体项目进度推进的角度出发来综合考虑问题，而不是单个从某项工作的角度的出来来判断这样做是否合理。即便需要某项工作做一些较难的整理总结，但是对于后续项目切换过程中能给更多的项目带来便利的话，这样的总结也是应该去做的。

3 对于有需求继承性的项目快速重建过程中配套的软件测试策略的改进

对于这种继承性很强的项目来说，如果项目本身确实是有效继承于一个成熟的量产项目。针对这样项目的测试流程也应该和普通项目的流程不一样。首先针对这样的项目应该在前期先要安排这个项目的客户需求的逐项点检确认，看看需求是不是继继承好。一旦项目继承前面的需求分支后，出的初期软件就应该可以点检了，测试部门应该在之前做项目的时候可以对于项目的需求做好测试文档记录规律工作，对于已经做过的共性需求记录好点检的测试案例，后面找测试工程师点检需求的时候可以快速的根据之前的记录进行点检，设置可以开发自动化测试工具来点检。同时需求确认后就可以判断验证已知的平台共性Bug的合入修改情况。如果这两点能在测试首轮就确认好，软件质量的基调就能定下来了。当然如果项目的器件做了切换，也要尽早确认器件的功能性测试，也可以适当关注这些的性能表现。如果第一轮的这些测试都做好且效果OK，当然即便有一些问题，也能让软件团队尽早先修改继承需求过程中产生的问题。也可以把器件的问题也在较早的时间段就发现出来。这样的软件基本也可以和客户一起同步测试了。客户拿到的软件感觉继承性较好的话，对于软件开发的进程也会较有信心。第二轮的时候选着适当的测试强度的固有测试用例跟进这个项目的软件测试。如果机器数量可观且状态良好的情况下可以尽早安排模拟终端用户使用的alpha测试。这样的模拟能找到正常测试案例里找不到的问题，同时客户也是更多的偏向于这种方式发现问题的。

4 总结

为了做到手机软件项目的有效继承需求，快速实现衍生项目的工程重建。要在以下各个方面做了些努力：

（1）做好软件项目需求继承性的管理工作，对于有继承性的项目要做好软件版本分支管理，Bug管理，共性需求分析工作。开发使用一下自动化检查工具来实现共性需求和Bug的合入情况的检查。

（2）同时对于重建概率加高的一些开l需求做一些总结整理，确认整理的内容有效后可以使得后续项目对于这些需求在SPL的需求分支上复现的过程可以快捷高效。

（3）配合这种需求继承性强的项目以合适的测试流程。从需求继承和Bug修改继承出发，先验证已知的问题和需求的继承情况，再确认系统稳定性的测试策略。

通过上述环节综合作用使得项目的进度能快速推进并且项目质量也能得到一定的保证。

参考文献

[1]萨默维尔著；程成等译.软件工程（原书第9版）[M].北京：机械工业出版社，2011（04）：144-146.

[2]Leszek A.Maciaszek著；马素霞，王素琴，谢萍等译.需求分析与系统设计[M].北京：机械工业出版社，2009（05）：60-61.

[3]杨芙清，梅宏，李克勤.软件复用与软件构件技术[J].电子学报，1999，27（02）：68-75.

作者简介

严王君 （1981）男，大学本科学历。学士学位。中级工程师，软件集成主管。主要研究方向为嵌入式系统软件MMI开发，软件系统集成。

作者单位

宁波波导软件有限公司 浙江省宁波市 315500