软件设计美学之道第7回──随着UP的乐章，让软件美学起舞

　　秀出设计，才能让人感受思维的美，而实作出来，才能满足现实的世界，软件设计有其美学之道，它和建筑一样，可以利用「工程方法」，让美学之道和实际需求接轨。在前一篇所介绍的三大UP（Unified Process）精神之下，还有许多在实践项目时会遇到的开发阶段和工作科目，其相互的运作流程与软件设计之间的关系，是最难想象与实作的部份。

　　关于这些开发阶段与工作科目，我想曾经读过这个方法论的人都会很熟悉一个诡异的波浪图（如右图所示），这张图是UP的精华，不过我个人觉得对于刚踏入UP的人来说，如果没有好好地理解它，这张图会像个镇煞避邪的石敢当，反而就会把大家吓跑了。

　　简单地来解释这张图，它的X轴所代表的是四大开发阶段以及许多的反复期（Iteration），也代表着时间轴；Y轴则代表工作科目，而在此图表上的大大小小波浪，则是代表项目随着时间进行时，各个工作科目在各开发阶段上的比重，其实这也隐喻着这四个阶段有着不同的核心任务，只要能掌握这些灵魂，执行UP就能简单不少。

　　是大饼，还是焦油坑－－Inception阶段

　　项目的一开始，绝对不是一头埋进成堆的客户需求之中，然后埋头苦干地开工实作，因为你不一定会知道，前面的路是个焦油坑还是一块大饼。虽然有时迫于情势，就算是个焦油坑项目，我们还是得做，不过起码我们可以先实行一些预防措施，例如使用符合成本的技术、资源，或者尽早另觅他处等等。

　　在这个阶段的时间会比较短，因为重点在于确立产品范围，了解项目关系人是否对项目愿景有基本的认同。因此，在这个阶段里，我们可能会只先列出大部份使用案例的名称，描述其中小部份，但却非常重要、有疑虑或者风险较高的使用案例，甚至建立一些简单的使用者界面prototype来验证需求，然后针对一些不确定或者难度高的技术做POC（Prove of Concept）测试。

　　真正的需求开发以及软件架构的建立，会是在下一个阶段，而在Inception阶段可能的唯一一个反复期（Iteration）里，是要能了解项目未来的路是通住天堂，或者是条令人心惊胆寒的天堂路。

　　给我架构，踏出美的第一步──Elaboration阶段

　　当完成了Inception阶段的工作并通过里程碑（milestone）的查核后，也不代表我们就可以放心地往前冲了。在这个阶段里，我们必需要厘清大部份的需求，但最重要的，是要能产出一个能够解决高风险元素的「架构原型（architectural prototype）」。这也是整个UP流程和传统的开发流程最不一样的地方了。

　　实作此阶段的关键概念就是要进行短时间且长度固定的多个反复（Iteration）、优先厘清重要或高风险的需求，然后及早开始写程序并测试，最后再将测试结果以及需求变化回馈到下一个反复（Iteration）之中。除此之外，我们要记得另一个重要观念－「建立软件架构的关键在于能够提供软件系统未来实用而稳固的发展基础」。

　　架构原型只是整个系统的骨干及部份肌腱，因此，及早开始写程序的意思是在于及早开始实作「架构原型」，并不是开始实作出系统的大部份哦。因为唯有不断地透过开发、测试人员，甚至是使用者的回馈，架构原型才能真正的确定系统风险的解决，并成为下一个阶段的稳定发展蓝图。

　　实作这个阶段使用到许多软件美学的重要技术及设计工具，例如，使用Use Case来描述需求细节、利用Domain Modeling来找寻软件对象灵感、利用Pattern来设计软件架构中的逻辑观点等等。因此这个阶段可说是整个流程的重心，也是软件架构师最重要挑战以及最大的舞台了。

　　开工、发包──Construction阶段

　　这个阶段会是整个流程里面最热闹的一段时期，因为在成本可行并且有计划的情形下，会有越来越多的人可以在这个时期里加入团队，甚至可以多个团队一起工作，包括外包。为什么呢？因为上一个阶段的结束，代表我们已经了解了大部份的需求，解决了高风险的问题并且完成软件架构原型、软件架构书（SAD）以及架构原型的系统设计相关文件等等重要产出。因此，我们也比较能预估项目接下来所需要的工作量及时间，而现阶段的开发团队可以依样画葫芦地照着架构原型的程序代码及其程序风格来开发建构系统其余的部份。

　　软件架构师在这个时期所扮演的角色就是开发团队的领导以及教练了。软件架构师此时必须掌握开发团队所发展的程序是否遵循着软件架构书所设计的大方向，并且时时利用架构原型都各部份为范本，教导开发团队来建构系统尚未完成的部份，如此这般的，一个反复一个反复地往下走。这个阶段的工作有时会有点像在填补Elaboration阶段所建构出来的骨架的肉，也就是架构原型以外的所有东西。因此，这个阶段的成功，和上个阶段的结束，有着非常重要的关系，而这个阶段的后期，团队也该完成一些如使用者手册等文件以及alpha测试，以便能替下一个阶段的beta测试做好准备。

　　完美的收尾－－Transition阶段

　　在经过前面三个阶段之后，在这个最后的阶段当然就是要做个漂亮的收尾了。这个阶段的主要目的是将系统变成真正的产品，工作的内容可能包含了最后测试、针对测试结果所做的响应、展示、教育训练以及将产品交付客户等等。最后，当然就是希望能撇开一些可能的政治问题，顺利结案并且拿到钱了。

　　在执行这些开发阶段时，还有一个重要观念：每个阶段的结束，都是为了下一个阶段的开始，因此每个阶段的结束，都会有一些确实的，可以衡量的产出物（deliverables），例如，文件、程序代码、测试结果等等，这些产出物就是下一个阶段最重要的输入，这是个容易影响UP执行顺畅度的观念。

　　近两期文章的种种，仅是极精简的UP内容，UP方法论的细节的确很繁多，不过，规则永远是人定的，只要能理解UP的三大精神及四大核心，再找出一个适合你所属团队的工作科目，才是真正的王道。

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