摘自：《Web设计大全》 作者：Thomas A. Powell

　　创建一个好的Web站点极具挑战性，从外观设计到数据库集成，那么多不同的部分都会留下很多犯错误的空间。为了减少Web项目失败的风险，我们需要有一个进程模型来指导开发过程。不幸的是，很多Web设计者采用了一种可能被称为N I K E的开发方法—他们只是做，而很少考虑前景和计划。这种建设网站的过程是不符合方法学的；站点的目标定义得很松散，整个进程依靠的是直觉，没有严格的过程定义而缺乏可预见性。以这种方法开发的站点像植物一样，它们自然地生长，偶尔会变成美丽的花卉，但更多的情况却是一团乱草。复杂的Web设计需要认真地计划。应该采用适当的进程模型或方法学来指导Web的设计和开发。

2.1 进程需求

　　与2 0世纪6 0年代相似的“软件危机”今天也同样出现在Web开发中。几年前，大多数Web站点只不过是数字化的小册子，或被人称为“小册子软件”。开发那样的站点并不需要大量的计划 —经常是简单开发好界面后，再用内容填充就足够了。今天的站点变得更复杂更庞大。随着电子商务和动态网页的引入。站点已经从“小册子软件”变为完全的软件应用。然而，很多开发者仍然还没有采用一种健壮的开发方法，继续依赖于特定的方法。

　　注意“软件危机”指的是在一段时间内，在软件开发领域，硬件能力的提高容许构建更复杂的程序。然而，开发和维护新的程序极具挑战性。因为过去几乎不采用什么方法学，结果很多项目失败，导致专家宣布“软件危机”发生。结构化的开发方法和“自顶而下”的设计方法的引入可以解决这种危机。

　　Web开发实践的危机广泛存在。不像过去内部的客户机/服务器项目会得到保密，现在很多失败的Web项目都会受到大家的关注。始终处于开发状态或者即将需要开发的网页的数目显示了 Web站点设计的糟糕。不幸的是，黄黑色的仍在建设的标志以及动画的手提钻很少被删除。如果从它们的内容和最后修改日期来判断，一些站点好像几年来一直处于建设之中。一些半死的站点，被陈旧的内容和风格陈旧的网页所充斥，过时的技术、断开的链接体以及运行不当的脚本，这些站点就像在线的鬼城一样。不要把这些错误简单地归结为疏忽和印刷错误。断开的链接体是一种严重的错误，想像一下如果某个软件存在功能缺失的菜单，情况又会怎样。

　　站点出现这些问题的原因多种多样。一些站点逐渐恶化，是因为站点设计者感到厌倦逐渐退出。另外一些站点则是因为站点被废弃或资金被撤离。还有一些站点未能完成，则是因为站点太复杂拖垮了设计者。有时候，开发者未能很好地理解他们使用的工具，或未能充分地理解媒体的限制。项目失败的原因多种多样，很多网站的倒闭则是因为项目太冒风险。

2.2 特别的Web进程

　　通常Web站点的开发方法很简单：实现网站，用浏览器完成外观测试并发布。这与软件小项目开发中的先开发后测试的过程非常相似。并不令人惊讶的是，用非正规的方法开发站点会遇到很多问题。今天的Web开发太快以至于仅分为两个阶段：实现和发布。值得注意的是，很多 Web开发工具鼓励这种在线的设计方法。一些工具鼓励开发者直接从构建用户界面着手，并逐渐用自动化工具增加功能。另外一些则先写代码再添加用户界面。勿须质疑的是，考虑到Web的时间需求，Web开发的速度非常重要。然而发布一个蹩脚而设计拙劣的站点也会成为问题，尤其是当用户对站点中出现的问题感到沮丧时。

　　在软件行业，很多专业人员倾向于认为非正规的方法仅适合于小项目，通常只有一个程序员，并且将来的软件维护工作量非常小。经常用这种缺乏计划的方法开发程序会产生糟糕的编程逻辑—所谓的“意大利细面条式的代码”。这种代码极其难以维护，因为除了初始的设计者外，没人能够解开这个疙瘩。即使是原来的程序员也会随时间忘记这些代码的意义。Web站点存在同样的问题。生存周期很短的小型Web站点，通常由一个人设计时很少采用方法学来进行。观察这些站点的H T M L网页、J a v a S c r i p t和导航结构，会发现“意大利细面条式的代码”也被采用，不过增加了一道被称为“杂乱的H T M L标记色拉”的副食。

　　在Web开发项目中计划能够解决一些问题。不幸的是，对特别的Web进程来说，计划仅仅局限于简短的交流，简单而又不完全的潜在内容的收集，或者一些仓促写就的流程图，花在计划上的时间与花在实现上的时间相比之下微忽其微。当然，也可能计划得太多而患上“分析麻痹症”，这阻碍了网站的建设，但这种情况并不普遍。一定要记住，计划的时间量正比于计划的复杂性，应付项目管理挑战的关键在于创建一个正规的进程，借助它进行计划、测试，并用结构化的方式配置站点。

2.3 基本的Web进程模型

　　为了减轻站点建设的困难，应该采用一种进程模型来描述Web站点开发中涉及到的不同阶段。通过使用指导准则、文档和确定开发步骤以确保每一步顺利完成。理想的Web进程模型能帮助用户解决站点的复杂性，减小项目失败的风险，处理项目中几乎不可避免的改变，在开发过程中快速发布站点并得到及时的反馈信息。当然，理想的进程模型也应该容易学习和操作，这是一个相当苛刻的要求，任何一个单一的模型都不能适应项目的所有特定需求。

　　Web站点开发中使用的最基本的进程模型为大多数人所熟悉，至少在思想上是这样的，因为它是可演绎的。基本模型从大的背景开始逐渐向特定的步骤细化，以便完成整个站点的设计。在软件工程中，这个模型称为瀑布模型，或者有时称为软件生存周期模型。因为它描述了软件生存周期的不同阶段，各个阶段逐步进行直到结束。模型的第一阶段是计划阶段，接着是设计、实现、测试，最后为维护阶段。每个阶段都有独特的步骤，但相连阶段的边界并不明显。进一步说，每一阶段并不总是有一个固定的目标。有时候，前一阶段可能会因为项目中未曾预料的改变而修改。步骤的实际数目和名称因人而异，但瀑布模型的思想如图2 - 1 所示。

　　注意尽管Web的开发模型可能是相同的，但仍有很多Web开发者认为他们创造了新的模型。他们在自己的站点上把它作为没确定归属的专利介绍，而实际上并没有新的东西。

　　无论是五个步骤还是七个步骤，或者名称是复杂还是简单，需要记住，真正重要的是模型能否加速站点的开发或提高最终结果的质量。

　　单纯的瀑布模型的好处在于它使得用户能够在前端计划一切，这也同时是它的最大弱点。在Web项目里，完成一个项目需要做些什么具有非常大的不确定性，尤其是当Web开发者没有太多的经验时。另一个与这个模型相关的问题是，像软件开发一样， Web开发的每一过程也相互重叠，并且前后相互影响，而且经常不得不重复。不幸的是，瀑布模型过于严格。如果发生过多的改变，可能要求开发者停止项目，并重复原来的过程。简言之，这一过程不能很好地适应变化。然而对于Web站点来说，瀑布模型因为便于理解和实施，仍然继续使用。进一步说，进程模型中每一阶段的分离有利于管理，因为它们便于监理和一步一步地实施。

2.3.1 修正瀑布模型

　　瀑布模型的一个重要方面在于它要求在前端做计划。然而由于在进程中需要有所有的步骤，开发者早期仓促地略过每一步骤，结果事后不得不重复，或者继续建造有缺陷的站点。进程也过于严格，不支持进一步的探索，导致不必要的风险。一种可能的提高方法是在瀑布模型的早期阶段花更多时间，并重复几次，在进入设计与实现阶段后反复挖掘目标和需求。因为进程的周期性，经常发现伴有涡旋的修正瀑布模型更加自然。当你解决带有很高的不确定性的项目时，图2 - 2显示的带有涡旋的修正瀑布模型是个很好的主意。

2.3.2 联合应用开发模型

　　最后提到的软件开发进程模型对站点开发很有意义，它就是联合应用开发设计，简称 JAD(Joint Application Development)，也称为进化原型法，原型系统通过一系列的演变得到最后的形式。原型不是创建用来测试理论的一个模拟站点，而是为用户创建的。用户直接的反馈信息将用来指导产生新版本的站点，反复如此，直到系统最终定型。JAD 的基本概念如图2 - 3所示。

　　J A D的很多方面非常适合Web开发，尤其是当非常难以确定项目的规范说明书时。与瀑布开发模型相比， J A D模型是渐进的，因此它也显得很快。然而J A D也有着严重的缺陷。首先，让用户看到尚未完成的站点会危害开发者和用户之间的关系。即使让用户参与指导项目，我们也一定要记住用户不是设计者，如第1章所指出的，这种Web设计指导准则会因为用户提出不合理要求而偏离轨道。以J A D运作的Web项目很难作出预算，因为修正的版本数很难预测。如果用户变幻无常，成本会螺旋上升而失控。记住，隐藏在J A D之后的核心概念就是在得到正确的设计之前反复试验。撇下它的缺陷不说， J A D在Web开发中有自己的位置，尤其在软件维护项目之中。然而，最初的J A D项目开发最好让有经验的开发者来完成—尤其是那些能与用户很好沟通的设计者。

　　其他一些指导Web开发的方法也讨论过。还存在一些能为用户服务的方法。记住，建设站点是先标识好等待解决的问题或达到的目标，并以一致和启发的方法得到结果。站点的开发应该是挑剔的和深思熟虑的，而不是随便的和被动的。一个挑剔的方法并不意味着完全抛弃机遇和灵感，相反，它提供了机会。设计者不应该把站点工程的一些概念当作限制的因素，而应该把它们当作指导准则。