软件设计美学之道第6回──统一流程（Unified Process）

　　虽然之前的文章都在谈论软件美学，但是在这篇文章，让我们暂时先丢开这个浪漫传说，回头来看看真实世界的软件项目。公司接案的最大目的是什么呢？当然就是要能赚钱，这也许很俗气，不过却是事实。

　　软件开发的项目有四个重要的变量－成本、时间、质量及规模，如果以企业生存游戏的角度来看，那成本一定是最难控制的变量，而质量是客户坚持的，时间是客户规定的，相对之下，只要能符合客户的业务需求，最容易控制的，我想就是「规模」了。因此我们可以假设在质量及时间不变的情况之下，若受到规模冲击的影响变小，则成本也会下降，而在成本越小的情况下，公司的获利当然也就会越多了。

　　只要能积极地管理规模变量，团队及客户对于其它三个变量的控制能力也能增加。因为通常客户不会太清楚他们要的是什么东西，真正的规模到那里，当然，这不是他们的错，软件的本质本来就是恒变的需求，而软件项目的开发本来就常处于「一寸以前，才是光明的」的状况，开发团队必需要协助客户，帮助客户找到他们真正的需求，帮助他们厘清可能的风险，一寸一寸地走，一点一点地将整个光明都找出来。

　　当一个团队千辛万苦地将一个软件项目完成后，最重要的事情除了收钱之外，还有什么呢？答案是「累积与再利用」，如果你是老板，你会不会希望看到下次在接到相似类型的项目时，开发团队可以利用更少的时间完成项目呢？因此，如何让团队能够在每个案子产生一个正向的回馈，让下次同类型的项目可以减低规模的冲击，进而减少成本，最后提高项目的利润，是一个非常重要的课题，而软件组件重用（Reuse）的技术也就呼之欲出了，这时，以Pattern为基础，并且以软件架构为中心的开发方式将是关键。这整个过程，势必需要一个软件开发流程来指挥协调。

　　各式软件开发流程

　　最常见的软件开发流程就是线性或「瀑布式」的旧式流程，当然还有相当有名的XP（Extreme Programming）以及我们要讨论的UP（Unified Process）等等。

　　软件开发的方法论有很多，各有其巧妙及适合的时机，端看开发团队的能力、项目类型甚至是文化国情。笔者就曾在某大电信公司，遇过某个开发团队所采用的是「课长流程」（就是以该单位主管心中的喜恶为主的「无定向」开发方式）！相信这在台湾也算是一种流行的开发流程吧。

　　「瀑布式」的旧式开发流程常见的做法依序是收集需求、系统分析、系统设计，最后根据设计结果来实作。这会衍生出一些职位如系统分析师（SA）、系统设计师（SD）以及「最底层」的程序员（Programmer），因此除了开发步骤的每一个阶段是线性的走向之外，时常连开发工作也会依职位的高低而变成官僚作风。有时在同一开发团队的SA甚至会做出和Programmer实作不同的需求文件，因为真正的需求及设计最后是靠SD，甚至是 Programmer以及客户的「提醒」才找出来的。如此的开发方式，不容易应付恒变需求的软件项目，更不容易累积可再利用的软件组件，而开发工作的责任及角色虽然和经验累积有关，但并不全然和职位的线性关系划上等号，因为每一种角色都有其专门的责任及技术深度。

　　UP精神

　　「统一流程（unified process）」对于「管理规模变量」以及「提高软件组件的重用」有着不错的影响，而针对线性流程无法确实掌握需求与实作关系的缺点，也有不错的解决方式。我们暂时抛开在流程里常会令人心烦的工作项目及开发阶段，先体会一下UP精神，这将有助于UP的实作。

　　UP精神最主要围绕在三个方向，分别是Use-Case-Driven、Architecture-Centric以及Iterative & Incremental。以下我先简述其重要观念，针对工作流程及项目的协调运作，将在下一篇的文章提及，而关于UP的详细内容，笔者建议大家阅读「The Unified Software Development Process」这本书。

　　所谓的Use Case「Driven」，就是指团队在执行整个流程时，都是从Use Case开始所有的工作项目。这样可以让开发团队在每次的工作循环里，以聚焦在客户的需求为出发点，避免迷失在项目的规模中。Use Case是大家用来发掘并记录功能性需求的一种技术。换句话说，它的功用在于找出对使用系统的参与者有价值的需求，并且能产生有价值及看的到的结果；例如，买机票、处理退货、结帐等等。而Use Case也可以帮助我们开发使用者界面，让客户清楚他们未来要如何使用系统来完成他们的工作，帮助客户找出他们真正要的东西，也帮助大家控制「规模变量」。

　　Architecture-Centric的概念最容易被想要实行UP的开发团队遗忘。通常大家只会注意到UP所定义出来繁复的工作项目，并拘泥在工作项目的意义及执行时间点，殊不知以软件架构为中心的开发观念是UP在执行对象导向项目的支柱。

　　软件架构的功用及开发步骤在之前的几篇文章之中已经提过了，在此我只再强调其对于「提高软件组件的重用」及「提供稳定的开发基础」有着重要的影响。在Use Case Driven的观念下，Architecture的开发是以支撑Use Case需求为目的，而Architecture的建构则会影响到那些Use Case可以被实现。

　　Iterative & Incremental意谓着透过回馈与调整来拥抱改变。在软件需求的恒变性之下，我们需要反复式的开发，让软件可以在一连串的建构、回馈与调整的循环之中逐步完成，这是线性式的开发流程所欠缺的。而这种短期、固定时间长度以及小规模的开发循环之下，可以让软件开发的复杂性变小，我们也可以用Risk- Driven的观念，先开发风险比较高的部份，让早期的进展减缓风险可能带来的冲击。

　　大部份的人也许会觉得UP是一部很笨重的方法论，拿来做研究还不错，但是对于用在实际的项目上，则是望之却步。其实在了解UP的精神后，再找出自己团队或者项目适合的开发活动与工作流程才是真正的关键。UP其实可以很敏捷，也可以很繁重，端看团队真正的需求。

原文转自：http://www.ltesting.net