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

智能手机软件设计方案快速重建模式的研究 　　摘 要目前市场上流行的智能手机软件设计方案很多，各种方案不光是由主芯片的供应商决定，比如联发科（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尽早发现和修改。这里就需要前面的文档管理工作做的好一些，既可以作为记录让那个项目参与人员查阅，同时也要适合自动化点检工具用来查询比较使用。这里可以被自动化工具用来点检的项有：