从Java谈软件开发流程

流程关乎项目预算与时间控制

「程序」指的是软件开发流程或是项目流程，定义流程的目的是要掌控所有的情况。项目的最大敌人是时间及预算，这两者都是有限的，如何在有限预算内准时完成项目，可说是一项艺术。

幸运的是，时间和预算都是可控制的，并不是指我们可以控制时间快慢或长短，而是如何明确知道哪一个时间点，需要何种产出物，而我们有多少的预算可以完成。为有效控制，我们需要一个标准的流程，只要照着规矩走，一切都好办。

RUP(Rational Unified Process)就是一种业界常用的不成文规矩，在多数软件项目中几乎都会使用的一项语言、方法与工具。 RUP的精神在于反复（iterative）与渐近的（incremental）。

在渐进式的开发过程中，透过不断的提炼（refine），可趁早发现问题且找出解决方法，也确保每一工作项目的进度。不过，在架构(Architecture)方面，RUP确实着墨较少，而架构优劣也是足以影响软件系统成败的关键因素。

QoS(Quality of Service)或是SLR(Service Level Requirement)，我想是每个系统最基本的要求，它包含可用性（Availability）、可管理（Manageability）、可信赖（Reliability）、可扩充（Scalability）和安全性（Security）等条件。

当系统架构进行规划时，就应同步考虑这几项条件。举例而言，先前某家外商银行因系统设计不良而导致外人可轻易猜出参数设定的方式，直接入侵系统窃取消费者隐私数据；也有某家电信业者为没考虑系统的负载量，而导致在耶诞、跨年等重要节日时，涌入大量简讯的尖峰时期造成服务塞车、系统当机。

在电视新闻中，我们常常可见类似的新闻报导，而背后隐藏的意义是，「当初没做好系统架构规划」，看得不够远、想得不够深，等系统开发到一半，或是系统上线后才发现问题，此时再东补西补，为时已晚。

虽说不同的程序技术皆有其满足QoS的方法，相较之下，Java对上述五大项功能的支持应该算是最为丰富。如在J2EE的设计模式（Design Pattern）中，几乎都是为解决此几项问题而设计，之后再配合程序语言本身的强固性，开发而成的企业级应用系统，我想应可满足客户对于QoS的严格要求。

话说回头，企业一旦使用Java开发一套系统，就一定会是百分百稳定且满足QoS吗？我想，设计模式跟程序语言无关，将J2EE 设计模式作为C#实作的架构，也未尝不可，只要能建构出相同安全稳定的环境执行该系统，都是可行的。就像会说国语，未必可写出漂亮的文章一样，训练、经验再加上一点天份才是最重要的。

专业技术认证可供参考

「人」是项目中最难预料与掌控的一项要素。人可分成两部份，一是客户，二是研发人员。客户是最难掌握的，不同的客户有不同的个性，没有任何人能教导你，如何应付不同的客户，除了靠运气，还要靠经验。

暂不谈客户，先看研发人员这部分。我想，要满足技术与流程两项因素，关键都是人。如何选择对且合适的技术，要有专业人才；如何有效管理流程？如何规划满足AMRSS五项需求的系统架构？这都是需要有经验的管理人才及架构师（architect）。当然，能不能写出漂亮且可完善运作的程序代码，也是需要有一定水平的研发人员。

开发程序人员的水平是较容易被认证。Java有几项专业认证，如SCJP、SCJD、SCWCD，都可用以鉴定开发人员基本的功力。另有SCEA、 SCBCD等认证可评鉴程序架构人员的素质。除专业训练之外，经验也是一位优秀的架构师所应具备的条件，而程序部份其实也有认证，如PMP。

也许你会觉得Java很八股，写程序为什么需要一大堆文件、设计模式、程序与方法论（methodology），边写边设计，且战且走不行吗？对于小型系统，或是没有营运压力系统而言，是可以的。如果是人力不足、预算有限、结案期限已在眼前，当然也该直接动工。

但依我接触过案子经验的深刻体验，宁愿花费较长时间与心力，在项目初期就先详细规划，才可节省后期开发的时间，系统上线后也更容易维护与扩充。虽然耕耘过程会较辛苦，但所得好处也会是倍增的。

查看本文来源