web|进程|设计|问题
2.4 Web站点项目的途径
理论上，Web站点工程很有道理，但在实践中，它是否奏效呢？答案是完全奏效。然而，由于Web是一个新兴的领域，站点开发很少一致，如显著的时间限制以及项目不断改变的特性。开发者应该小心地继续。为了指导开发，在项目之初，就应该采用某个进程模型。如果站点是崭新的或增加起来非常困难，就应该采用瀑布模型或带有涡旋的修正瀑布模型。如果项目是有关维护的，比较简单并有很多未知的因素，那么联合应用开发方法就比较适合。不考虑项目本身，第一步通常都是相同的：那就是确定项目的整体目标。
2.5 目标和问题
很多站点因为缺少清晰的目标而最终失败。在Web开发的前几年，很多公司创建站点的目的很单纯，就是为了显示公司有站点。不知何故，没有站点的公司会被认为缺乏改革精神，不能作为市场领导者。有站点的竞争者会被认为危险。很多时候，站点很少赢利，而建设的原因仅是为了显示公司的存在。随着Web站点的盛行，创建站点的原因越来越明显。今天，站点的目标变得更重要，而且显示的方式越来越清晰。然而并不能因此主观地认为理念统治了站点—很多的站点项目开发纯属出于乐趣或因为察觉受到了危险，而不是为了解决真实的问题。为Web站点提出一个目标并不很困难；问题在于提炼目标。警惕诸如“为用户提供更好的服务”或“通过开发在线市场而赚更多的钱”这样非常模糊的目标。这些可以作为项目的合理想法或一般目标，但目标需要更详细的陈述。好的目标陈述可能有以下的内容：
- 建立支持用户的站点，通过提供全天候的用户问题答复，提高用户满意程度，从而降低 2 5 %的电话技术支持。
- 创建一个在线的汽车零部件商店，每个月直接向用户销售一万美元的零部件。
- 建立一个日本餐馆站点，通知用户有关时间、菜单、氛围以及价格等信息，以鼓励用户通过电话预定或访问站点。记住，以上三个目标的陈述中，有两个目标是可度量的。这在做实际的财政预算时，非常便于确认项目的成功与失败。第三个站点目标的陈述无法度量。这么做非常冒风险，因为不能让别人确信站点是成功的，或以某种方式度量站点。在餐馆信息站点中，站点访问者的预定数目或用优待券来度量站点访问人数会很有帮助。考虑以下修正的目标：
- 建立一个日本餐馆站点，每个月通知3 0 0个潜在用户有关时间、菜单、氛围以及价格的信息，以鼓励用户通过电话预定或访问站点。简单的增加特定的访问人数会让目标更起作用。通过规定期待的访问人数，餐馆拥有者可以在效率相同的调查速度下比较通过印刷品或收音机做广告和运营站点之间的优劣。
2.5.1 集体讨论
一般来说，提出目标是非常简单的事情。最重要的问题是让目标的陈述简明和可现实。在很多Web项目中，有在站点中包容一切的倾向。记住，一个站点不可能满足所有人的所有需求；在心里一定要有特定的用户和特定的任务。为了确定目标，集体讨论是必要的。集体讨论的目的是尽可能提出有关站点的想法。在集体讨论时，一张黑板是非常有用的，可以用来快速记下和修改有关站点的想法。
通常，集体会议会偏题，因为参与者离题太远或讨论了太多的关于站点的哲学问题。在这种情况下，最好集中于大家一致感兴趣的问题。通过让大家讨论在站点中不希望见到的特性，以确定关于站点的一般设计哲学。让参与讨论者意识到他们不希望站点太慢，或难于使用，这些通常很容易。一旦集体统一了一致目标，哪怕这些只不过是一些关于站点不应该太慢的看法，未来的探讨以及关于站点应该做些什么的陈述都会更加顺利。
注意在指导重做某个站点的项目时，一定要注意不要召开集体会议来斥责既存站点中出现的问题，除非项目中的参与者与站点没有任何关系。一个万无一失的防止项目偏离的方法是让站点的原来设计者来为自己遭到的批评进行辩护。记住，人们不得不设计站点，所以组织一支积极的设计队伍是非常重要的。
2.5.2 缩小目标
在集体会议中，所有想法都是很了不起的。会议的要点是挖掘各种各样的被称为“愿望清单”的想法。“愿望清单”就是描述各种不考虑价格、可行性、可应用性的有关站点的想法的文档。然而，最终的“愿望清单”会缩小为有关站点的合理和合适的部分。这对有着各种各样可能目标的站点来说非常具有挑战性。例如，考虑某个公司的站点，包括产品信息、投资者信息、新闻稿、职位申请以及技术支持等部分。每一个负责相关部分的人都会认为他们的那部分是最重要的。每个人都希望把他们的那部分的链接体放在主页上。在那么多方案中权衡确实是非常困难的。
另外一种缩小目标的方法是使用小的纸片或3×5的卡片。把每一个想法写在卡片上并堆起来。接着再让每一个人依据重要性，每次从卡片堆里抽出一张。当然，一定要限制从卡片堆里抽出的卡片数量。以这种方式非常有希望挑出重要的想法。不幸的是，依靠集体，这种运作很可能失败—尤其是当参与者在各自的领域扮演着很重要的作用时。
2.6 访问者
缩小目标的最好方法是始终考虑访问者。集体会议所需要的与用户所想得到的并不一定一致。首先要做的是精确描述站点的访问者以及访问站点的理由。然而，不要寻找“美国在线” 上的某个名为Joe Enduser或者某个偶然使用5 6 k调制解调器访问你的站点的访问者。对大多数站点来说，这种用户是无法标识的，而大多数用户在心中都有一个特定目标。首先考虑一下你的用户是些什么样的人，并向他们问以下问题：
他们在什么地方？他们有多大年纪？他们的性别是什么？他们说什么语言？他们技术熟练程度如何？他们采用什么样的因特网接入设备？他们使用什么样的计算机？他们可能使用什么样的浏览器？接着，考虑用户访问站点时干什么：他们怎么访问到站点的？用户想在站点上实现什么样的目标？他们在什么时候访问站点？他们会在站点上呆多长时间？他们从哪个网页退出站点？他们什么时候会再返回站点，是否可能？
当你可以从这些问题的回答中描述出用户的特性时，你应该能够快速地确定访问你的站点的可能不只是具有单一目标的单一类型用户。对大多数站点来说，有很多类型的用户，每种类型的用户都有着不同的特征和目标。
用户特征
最好的了解用户的方法是和他交谈。如果可能，你应该直接和你的用户交流以验证关于用户特征和想法的设想。一个调查可能是合适的，但现场交流更可能提供了探索超越预先确定的问题的可能。不幸的是，现场交流或调查用户非常消耗时间，不可能考虑每一种特征或想法的用户类型。从用户调查、现场交流或有关用户的一般思考中，你应该建立综合但详细的关于用户的特征。考虑至少三种类型的用户。对大多数站点来说，这三类用户大致对应于没有经验的用户、有Web经验但不经常访问站点的用户、能力强经常访问站点的用户。大多数站点有三类用户，能力中等但不经常访问站点的用户群是规模最庞大的一群。确信分配恰当的比率给相应类型的用户群，从而以合适的份量考虑他们。现在开始命名你的用户。在每交流完一个真实的用户后，你可能想命名他，或采用一般的名字如名叫B o b初学者、名叫Irene 一般用户和名叫P a u l 超级用户。接着利用前面章节的问题描述出各种综合用户的概况。尽量把每一个答案对归类。这样，如果交流的用户中有快速接入设备的很少，大多数的接入设备很慢，我们就把后者当作更为一般的情形。第3章将更详细地讨论一般的用户特征和个性化的特征。
一旦完成了对一般站点访问者的特征的描述，就应该开始设计访问方案。当名叫B o b初学者访问站点时，他会干些什么？什么是他希望完成的任务？什么是他的目标？方案设计有助于你集中于每一个用户实际希望完成的任务。从这种实践中，可能发现你的目标陈述与用户想做的不一致。如果是这样，可能仍需要反复做设计。返回到你的初始步骤之中，根据新的信息修改你的目标。
2.7 需求
根据站点的目标和访问者的类型，站点需求应该有所不同。需要什么样类型的内容？站点应该具有什么样的外观？应该需要开发什么样的程序？为了满足访问者应该需要多少服务器？用户在带宽、屏幕尺寸、浏览器等方面有什么样的限制？等等。需求会显示站点的成本和潜在的实现问题。需求会显示需要多少开发者并显示缺少什么样的内容。如果需求相对未来的回报来说过多，就应该重新回到目标阶段，并重新定义访问者类型。进程的前三个阶段可能要重复多次，直到形成站点规划或规范说明书。
2.8 站点规划
一旦讨论了目标、访问者和站点需求，并形成了文档。就应该起草一个正式的站点规划。站点规划应该包括以下部分：
1) 简短的目标陈述。应该包括对站点整体目标的简短讨论和对站点成功与否的基本度量。
2) 详细的目标讨论。应该详细讨论并提供可度量的站点目标，以验证站点的收益。
3) 用户方案讨论。讨论用户各种各样的访问方案。首先从用户怎样访问站点开始，直到达到目标。本节包括对度量方法的讨论，如下载量、每次访问的网页数、填写的窗体数，以及诸如此类的有关详细目标讨论的内容。
4) 内容需求。应该提供一个有关文本、图像以及站点中需要的其他媒体的清单。一个显示需求的内容、形式、存在性以及潜在的拥有者和创造者的矩阵是有用的，因为这个矩阵能显示哪些内容非常重要。简单的矩阵如表2 - 1所示。
5) 技术需求。提供站点所使用的技术的综述，如H T M L、J a v a S c r i p t、C G I、J a v a、插入件等等。技术需求应该与用户的能力直接相关。更多的技术上的考虑在第1 3章中可以找到。
6) 外观需求。应该给出用户界面设计的轮廓。应该详细地给出站点与既存的宣传材料之间的关系，并给出用户在图形以及诸如屏幕尺寸、颜色深度、带宽等多媒体应用方面的限制。本小节也应该给出特定的字体和颜色使用的细节，但很多站点外观的细节应该留在开发过程中确定。
7) 发布需求。指出发布需求，特别是主机方面的考虑。该小节应该包括多少用户访问站点、一个典型网页会消耗多少页以及典型页的尺寸。即使那些仅是一些设想，也可能借此进一步对服务器和发布站点的带宽需求进行简短的分析。
8) 站点结构图。该小节应该给出站点的结构或详细描述站点不同部分的流程图。应该根据前面小节分析的各种各样的用户方案，给出每部分适当的标题和一般想法。站点每部分的组织也是重要的，应该始终进行提炼。站点结构的选择在第4章中会讨论，但一般来说，站点结构图应该与图2 - 4相似。
9) 资源。站点应该给出运行时需要的各种资源。度量方法可以用简单的人-小时法表达，并且应该与四种资源相关：内容、技术、外观设计和管理。
10) 时间表。应该结合前面章节描述的典型瀑布模型和前面叙述的资源，显示项目的进展程度。
11) 财政预算。财政预算主要决定于资源需求和发布需求。然而，市场成本和内容版权也应该包括在财政预算中。站点规划的实际组织和内容由设计者决定。记住，规划的目的是在从事该项目的各种各样的人们之间交流站点的目标。不要忽略站点规划的撰写，尽管它很令人沮丧。如果没有这种文档，你就只能以一种进化或J A D的方式开发项目。进一步说，没有规范说明书，你不可能从投资商中获得任何现实的投标。然而，一个完成的计划并不允许你立刻着手实现。一旦规范书形成，就应该审视一次。完成的规范说明书可能暴露不现实的估计，从而让你陷入反复修改初始目标和定义访问者特征的过程之中。如果不是，就可以进一步，沿瀑布模型开始原型设计阶段。