浅谈软件项目开发过程

和软件产品不同，软件项目的目标用户或客户群体相对单一；软件项目一般会有确定的起始时间，之后会移交进入维护阶段。如下图所示软件项目会经历启动、计划、构建与移交这 4 大阶段。

项目过程

在整个项目过程中，开发人员之间、开发人员与领域专家进行沟通能否进行顺畅的沟通很大程度上决定着项目的成败。而 UML 作为独立于开发过程的统一建模语言可以有效的促进项目成功所需要的沟通。UML 包括很多的内容，但是一般情况下只需掌握类图、交互图，包图、活动图、物理部署图以及状态图就足以支撑必要的沟通了。

启动阶段

根据项目的规模、复杂程度等，项目启动阶段有多种表现形式。对于简单的项目可能仅仅只是领导的简单指示，而对于复杂、投入较大成本的项目则需要更正规的启动流程。无论以什么形式进行，本阶段的主要目标是确定项目高层次的目标和需求，能够勾勒出项目的整体轮廓，知道项目要做什么，达成什么业务目标，大概需要投入到少，能赚多少钱或节约多少成本。

UML 的用例能够捕获高层次的功能性与非功能性需求。列出主要步骤的用例文档可以促进与领域专家的沟通，捕获高层次的需求概要。

计划阶段

启动阶段获取高层次的需求与目标之后，如果决定继续项目则需要对需求进行进一步的细化，搞清楚具体要实现哪些功能性与非功能性的需求以及怎样实现这些需求，也就是需要有一个蓝图。通过这个蓝图

1. 客户可以知道移交后的系统是怎样的，能否实现业务目标

2. 开发团队知道整个系统由哪些组件组成，自己负责的部分如何与其它组件协助

3. 出资方能预估开发、部署、运维成本

4. 管理人员知道项目的范围，能够进行进度管理，成本管理等相关管理工作确保成功交付

在本阶段，其中一个很重要的任务是识别风险，并且制定风险应对方案。软件项目的风险可以分为以下 4 大类：

1. 需求风险：开发出的系统不是客户需要。

2. 技术风险：技术选型能否实现系统功能性与非功能性需求？选择的技术能否相互兼容？

3. 技能风险：研发团队能否熟练使用选择的技术以及拥有相关的专业知识？

4. 政治风险：相关方会给项目带来什么阻碍？

应对需求风险

用例是用户为了达到某一目标和系统进行的典型交互，每一个用例表示用户可以理解并对该用户有价值的功能。用例以客户能够理解的文字列出交互步骤，所以开发人员可以使用用例与客户确定软件系统需要实现的功能。根据用例文档整理出 UML 用例图，可以俯瞰整个系统的需求范围。这些用例模型可以辅助各种沟通需求。比如”第阶段只有 2 个星期的时间，用户管理用例和文档搜索用例都需要 2 周进行开发，你（客户）到底要先开发什么?"

随着需求分析逐渐深入，系统分析设计人员会根据与领域专家沟通确认后的用例模型在概念层面使用 UML 类图产出领域模型。驱动软件持续变更的原因是业务逻辑的改变，初期客户沟通、确认的功能随着业务环境（组织机构、人员、市场环境等）的变化已经不能满足业务目标了，这时就需要对软件提出变更。如果没有领域模型，就没办法从整体上把握变更的影响范围，也没法指导开发团队设计最优的变更方案。随着时间的推移项目熵不断增加，最后变得非常难以维护。

当需要分析业务比较复杂的步骤或算法的时候，UML 活动图或交互图可以帮助需求分析与软件设计人员与领域专家沟通领域模型里各个对象如何进行交互，正确把握应该把握的关键细节，并把相关的知识记录下来形成设计文档指导后续的开发工作。

UML 用例、领域模型类图、活动图以及交互图可以帮助系统分析设计人员与领域专家进行高效沟通，并且把握住系统的整体需要和重要的细节。让团队有信心快速进入下一个阶段而不会因为过度担心纷繁复杂的细节而裹足不前、耽误工期。

应对技术风险

原型构建是应对技术风险最有效的方式，团队可能对单个技术都比较熟悉，但是没有试过把它们放在一起作为整体解决方案，这时就需要使用原型开发方法尽早验证技术方案的可行性。越早掌握技术方案的优缺点，并且对比替代方案可以提高团队应对后期可能出现的意料外变更的应对能力，增强团队的信心。

团队可以使用 UML 实现层面的类图、交互图、包图以及部署图沟通记录设计方案的技术挑战、解决方案、方案对比等工作。

应对技能风险与政治风险

书籍和培训可以帮助团队成员获得相关的技能，但因为各个项目的情况差异很大，更有效的方式是聘用有相关经验的开发人员指导团队进行开发。应对政治风险的方法主要是识别相关方并且制定合适的沟通以及参与计划，平衡各个相关方的诉求。

构建阶段

构建阶段占整个项目周期的时间最长，为了应对市场环境的变化交互实现业务目标的软件，现在基本都会使用迭代增量方式进行项目的构建。

每个迭代都会从用例池中挑选对业务来讲可以产生最大价值的用例进行开发。确定当前迭代的范围后会进行需求分析、方案设计、编码与测试工作。在构建阶段每个迭代的设计都会依赖于计划阶段产出的总体概要设计以及之前迭代的成果，有必要的化需要对这些文档或代码进行重构与更新。在此阶段 UML 类图（概念和实现层次）、交互图、用例、活动图、状态图、组件图和部署图仍然可以促进团队进行有效的沟通。

现有可工作的软件在新的迭代加新功能的时候需要进行重构。除非进行过度设计或已经添加过类似的功能，现有系统大概率是不会有扩展点优雅的兼容新需求的。此时需要对照领域模型，评估影响的范围。然后在不改变现有功能的情况下实现扩展点设计编码，测试通过后添加新功能再进行测试，通过后就完成了本次迭代的开发。

测试在迭代增量开发中有举足轻重的作用，有单元、功能测试兜底，开发人员就敢大胆的改动现有代码。改动后测试通过了就说明本次改动没有影响现有功能，开发人员可以丢掉包袱，全心投入新功能的开发。开发人员有信心了，开发效率自然就更高了。否则开发人员就不知道什么时候需要投入大量的时间排查几个迭代之前改出来的 Bug。开发人员就不愿意修改现有代码生成扩展点，而是简单粗暴的增加新功能的代码了。自动化测试还可以加快反馈时间，开发人员马上就知道结果，如果不行进行代码回退（因为花费时间不多），寻求新的方案。

构建阶段有意识的使用分析与设计模式可以大幅增加分析与开发的效率。

构建阶段需要关注团队的产能（velocity），在团队成员稳定的情况下产能一般不会有大幅的波动，初期迭代任务连续几次无法按时完成，就需要根据团队的实际产能制定可行的进度计划，否则，团队长时间超负荷运转会让团队更不稳定，增加项目延期的风险。

移交阶段

此阶段功能开发已经完成，只会增加小范围更改的小功能。开发团队在移交阶段需要关注的是性能优化相关的工作，需要对系统进行性能测试、负载测试和压力测试。如果性能指标达不到要求则需要进行相应的优化。

移交阶段的测试