虽然之前的文章都在谈论软件美学，但是在这篇文章，让我们暂时先丢开这个浪漫传说，回头来看看真实世界的软件项目。公司接案的最大目的是什么呢?当然就是要能赚钱，这也许很俗气，不过却是事实。
软件开发的项目有四个重要的变量-成本、时间、质量及规模，如果以企业生存游戏的角度来看，那成本一定是最难控制的变量，而质量是客户坚持的，时间是客户规定的，相对之下，只要能符合客户的业务需求，最容易控制的，我想就是「规模」了。因此我们可以假设在质量及时间不变的情况之下，若受到规模冲击的影响变小，则成本也会下降，而在成本越小的情况下，公司的获利当然也就会越多了。
只要能积极地管理规模变量，团队及客户对于其它三个变量的控制能力也能增加。因为通常客户不会太清楚他们要的是什么东西，真正的规模到那里，当然，这不是他们的错，软件的本质本来就是恒变的需求，而软件项目的开发本来就常处于「一寸以前，才是光明的」的状况，开发团队必需要协助客户，帮助客户找到他们真正的需求，帮助他们厘清可能的风险，一寸一寸地走，一点一点地将整个光明都找出来。
当一个团队千辛万苦地将一个软件项目完成后，最重要的事情除了收钱之外，还有什么呢?答案是「累积与再利用」，如果你是老板，你会不会希望看到下次在接到相似类型的项目时，开发团队可以利用更少的时间完成项目呢?因此，如何让团队能够在每个案子产生一个正向的回馈，让下次同类型的项目可以减低规模的冲击，进而减少成本，最后提高项目的利润，是一个非常重要的课题，而软件组件重用(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在执行对象导向项目的支柱。
文章来源于领测软件测试网 https://www.ltesting.net/
