中小型软件项目的一种过程管理模型

中小型软件项目的一种过程管理模型

作者：赵彦锋 刘世伟

来源：《现代电子技术》2008年第20期

摘 要：软件工程化的概念已提出多年，其发展已经进入成熟阶段，但软件项目的问题却层出不穷。在根据实际工作中出现的问题，结合软件工程中的几种常用过程模型，融入过程管理的理念及要素，并借鉴敏捷开发思想，总结一套适用于中小型非军方项目的过程管理模型；采用调查分析法、实践法经过一年半的软件开发实践及过程管理实践，得出一套这样的过程管理模型。内部的QoD项目的开发数据证明该方法对于中小型软件的有效性。模型的优点在于结合多种模型在中小型项目中的优势。

关键词：过程模型；代码先行；顾客包含；功能性WBS；模块性WBS 中图分类号：TP311文献标识码：B文章编号：1004373X(2008)2008603

Development Management Process for Small and Medium Scale Non-military Software Project ZHAO Yanfeng1,LIU Shiwei2

(1.Xi′an University of Finance & Economics,Xi′an,710061,China;2.College of Software,Northwestern Polytechnical University,Xi′an,710065,China)

Abstract：The software engineering concept is put forward many years ago and has stepped into its mature phase.But increasing types of issue have emerged in software development

engineer.According to the problem aroused in actual work,some of usually used software developing process,elements of process management and principles of agile development are combined.Goal of this paper is to find a set of software development process for small and medium scale non-military software projects.The investigation method and practice method are adopted during the past one and half years.Afterwords a model which satisfies our purpose is found.Internal project QoD can prove the effiencecy of such model.The advantage of this model is many advantages of each process management model is combined in the small and medium scale software projects.

Keywords：process model;code first;customer-involved;functional WBS;modular WBS 1 引 言

软件工程发展到现在，最缺的不是一个开发框架，而是真正的把某一个框架运用到实际当中去

［1］

。然而，瀑布模型过于单向，处理变更比较困难；国标GB 8567-88的陈旧及数据的冗

余有些不适合快速的项目开发；CMM的实施不菲的成本及灵活性差的特点把很多团队拒之门外；V模型没有加入对迭代的处理；RUP大量文档及角色只学习就需要很多的时间，其所要求的剪裁又需要一定的实际项目管理经验，诸多因素使得软件过程的管理一直处于混乱之中。各

龙源期刊网 http://www.qikan.com.cn

种开发模型有各自的阶段划分方法和忧缺点，如何选择和剪裁适合本团队的开发过程是个普遍存在的问题。

本文就中小型项目的开发，结合瀑布模型及敏捷开发的思想，加之对RUP的理解，对软件过程进行了一次适当的剪裁并加入了一些个人的观点。本文所讨论的软件开发是针对外部项目，而非自主研发式的项目。 2 项目开发各阶段的主要工作 2.1 项目定义阶段

本阶段的主要目标是确定本项目的名称、范围、利益相关方、风险、约束和经济可行性等。

2.2 需求获取阶段

首先，当接到任何一个项目时，域分析是必要的步骤，这是以顾客为导向的项目的初始表征，因为听不懂顾客的语言就跟本不可能深入了解顾客在各自专业内的需求。在这个阶段可以采用把顾客加入到开发团队中的做法，每天利用50%的时间与顾客进行沟通交流。剩余50%时间的主要工作，做出原型，并准备第二天要沟通的问题。每天是一个迭代的过程，直到把顾客本次要完成的需求记录完善。

第二步则是对整体的需求进行分析，这种分析主要包括以下内容：

（1） 把顾客提出的需求进行归纳整理，并用顾客语言进行描述，确保无二义性。 （2） 分析有那些是顾客提出但不正确的条目。“需要不等于需求”，软件项目工作者在与顾客一起工作的过程中如何有效地导出顾客需求，在需求过程中起到极其重要的作用。 （3） 对相应的过程提出改进建议。“没有流程再造的IT不是真正的IT”，企业的机构经常调整，管理流程随时有可能变化，这时有一个资深的企业管理咨询专家将会给顾客的产品提供很高的附加值以及增加更多的无形利润。

（4） 需求归类，形成初步的功能性WBS(Work Breakdown Structures )，即按照功能模块把需求分类，然后根据顾客提供的优先级进行初步的版本划分，这也是在本阶段第三步中要与顾客共同确定的项目主要里程碑之一。

第三步则把分析的结果反馈给顾客，共同确定好一套要实施的工作方案，此过程仍然为一个迭代过程，直到达到顾客满意。此时可以签署需求合同及相应的版本开发计划。最后把所有的需求加入《顾客需求列表》

龙源期刊网 http://www.qikan.com.cn

2.3 提出项目解决方案及计划阶段

本阶段最终的目的是向顾客提供可供选择的解决方案。每条解决方案至少应该包括，预计采用的软件语言、参照的（网络）协议、配套的硬件设施、该方案的紧急度、重要程度、优先度、易用性、可扩展性、实现复杂、技术难度等。每项可以按分数1~10逐步增强进行打分，在把每项加权系统相乘的结果累加。

理论上，希望把所有的解决方案都提交给顾客并进行讨论，确定最终采用的方案。在实际运行中，往往是先把最好的一套方案拿给顾客，如果不能说服顾客同意，则根据顾客的关注焦点从剩余的方案中选择，多套方案在竞标中也是相当有益的。

在本阶段进行的不仅是与顾客交流方案的选择问题，还有一点很重要的是要根据已做好的计划，参照顾客的时间表讨论是否能在必要的时间参与到项目中。如每周进行一次细节上的需求确认及偏航纠正，这种会议是减小项目失败可能性的一种较易现实的途径。 2.4 设计阶段

设计阶段最重要的是要有经验丰富的系统分析师及系统架构师。在设计阶段可以采用结对设计的方式，融合众人之长，设计一个易扩展的软件框架。对已知的工作进行分解，做出模块性WBS，并明确每个版本必须实现的功能。

设计所产生的文档只需要记录模块之间的关系，而不需要过多地考虑繁琐的细节，这也是下一个阶段推荐敏捷开发的原因之一。对于项目的估算，建议采用功能点估算法，如图1所示。

2.5 实现阶段

实现阶段最重要的就是按照本团队的编码规范进行编码工作。作者建议在编码阶段采用结对编程的方法，采用每日站立会议、顾客故事、测试先行、代码重构、代码共有、每日集成的文法，在此期间，代码的规范性是一定要保持，并应采取一定的监督机制

［2］

。

本阶段不建议采用大量的软件过程文档，而是采用“代码说话”（code talk）的方法，这一方面取决于变量、方法的命名规范，即前面所提到的编码规范；另外一方面，多用注释以代替文档，而只在文档中记录重要的模块间及重要类之的相互关系，其他细节放在注释中阐明，这样就尽可能地减少了文档与代码之间的互相查找，也在最大程度上避免了代码与文档之间不匹配的问题。

另外，在模块间相关代码发生更改之后，要对设计中的文档进行更新，此谓“先代码，后文档”。

龙源期刊网 http://www.qikan.com.cn

在本阶段要定期（每周）与顾客会面，对上一周所遇到的尚未讨论的细节问题进行确定。此时，顾客可能会提出一些新的想法，这也就是主动“拥抱变化”，而非死扣合同

［2］

。

伴随着每日的集成，对于特定的内部版本需要进行内部测试，至少应每周1次，并记录BUG出现的次数、级别、类别，并于下周会议上查看修复了多少，尚存多少没有修复，记录没有修复的原因。以数据和事实说话，统计有多少BUG是在编码时可以避免的，有多少是由于设计失误等引起的返工。这些数据可以协助建立本组织的知识库，这是属于知识管理的一部分，在此不做深入讨论。经过若干迭代，实现了第一版本中的所有需求后，α版已经可以发布。

2.6 顾客测试阶段

对于顾客，很少会知道如何对软件进行验证测试，这时把测试团队在开发阶段写的测试用例修改整理为顾客语言，就是一个很好的范本。把这个文档提交给顾客，并指导顾客进行测试。另外，有些顾客也会拥有自己的测试团队，他们会用自己的方式进行测试。如果通过，则β版可以准备发布。

在交付前还要提供给顾客相应的《顾客手册》、《版本发布说明》，这也是产品交付时的必要部分，有时还需要根据顾客的要求或合同做相应的技术培训。 2.7 维护阶段

维护阶段主要工作是对β版中没有发现的BUG进行修改，并根据新的需求对系统进行升级。对于新的需求，要做的是从提出项目解决方案及计划阶段开始迭代执行此过程模型。如果是较大的调整或升级，则从需求获取阶段开始迭代执行此过程模型。 3 应用实例

作者应用此过程模型开发了QoD（Quality of Delivery）数据统计分析软件，该项目属于公司的内部管理软件。在开发中，把如上过程框架应用到了实际工程中。结果如图2所示： （1） 由1.0α版当初的4条需求，发展到2.0β版的19条需求；

（2） 由项目初始时，项目提出者一人的支持，发展到2.0β版本12名顾客经常使用； （3） 项目组共3人，采用瀑布模型的开发估算,项目周期8周，预计开发中产生5个新需求。采用本开发框架后，实际周期为5周，共 15个新需求。 4 结 语

龙源期刊网 http://www.qikan.com.cn

本软件开发过程模型，结合了很多软件开发过程的特点，目的是最短时间内交付以顾客为中心的软件产品。实际应用的统计数字证明，本项目仅在时间上就节约了37.5%，顾客需求导出度提升了200%，代码返工率大大减小。在中小型项目的开发中起到了一定的增效剂作用。本软件开发过程的重要里程碑和主要文档列表如表1所示。 参考文献

［1］Anon.The Mythical Man-Month ［M］．北京:清华大学出版社，2002．

［2］Laurie Williams.Pair Programming Illuminated ［M］．北京:清华大学出版社，2003． ［3］ISO9000-2000标准 ［S］．2002.

［4］Anon.Software Project Management-A Unified Framework ［M］．北京:清华大学出版社，2000．

［5］冯平鸽，杨民献．软件过程改进的CMM模型［J］．中小企业科技,2007(3):22-23. ［6］韩晓鸿，申艳光，张艳丽，等．探讨CMM，PSP和TSP对软件过程持续改进的意义和方法［J］．科技资讯,2007（4）：109.