需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan.

admin 产品项目流程和规范 产品原型, 产品经理, 需求分析

[#2: Edit Options>MightyAdsense>Adsense Code]

每个用例表示用户为实现某个目标与系统的一次交互，而事件流程则是对实现该目标的描述，事件流程包括基本流程（又称为主成功流程）和可选流程（又称为扩展流程）；对这部分的编写应该清晰的描述不同的对象（用户、系统）完成目标的活动序列，例如，像这种方式：球员甲将球传给球员乙，球员乙运球，球员乙将球传给球员丙。
编写一个良好的事件流程有以下准则：
准则一：使用简单语法
主语＋谓语＋宾语，例如： “系统从帐户余额扣除一定数量金额“，简单的语句与用户沟通起来对需求的理解会更准确。
准则二：明确写出“谁控制球”（比喻）
控球的执行者会做下列事情：自己运球或将球传给别人，在步骤结束时要问问“把球给谁了”。
准则三：从系统外部的角度来编写用例
始终站在用户的角度来编写，而不是系统的角度，例如，不要出现这样的描述“系统读取卡号和密码，并从帐号余额中扣除一定的金额”，而要从系统外部的角度来编写，如：
1）用户输入ATM卡并输入密码
2）系统从帐号余额中扣除一定的金额
准则四：描述过程向前推进
每一个步骤都要离目标更进一步，步骤不要太细，也不能太粗，一般对基本流程3-10步是合适的，过多则会使用例文档显得太长。
准则五：描述执行者的意图而不是动作
编写用例常见的问题就是在操作界面来描述，这应该需要避免，例如：
用例1
1） 系统要求用户输入名字；
2） 用户输入名字；
3） 系统要求用户输入地址；
4） 用户输入地址；
5） 用户点击“确认”
6） 系统显示用户简介
修改后：
1） 用户输入名字和地址
2） 系统显示用户简介
虽然在操作界面进行描述能很精确的定义需求，但过多关注细节会花费大量的精力，同时文档也会变得很长，难以维护。
准则六：包含“合理”的活动集
对场景的描述可以把每个部分作为一个单独的执行步骤，也可以以不同的方式合并其中的几个部分，如何分隔要尽量按“是否合理”进行。一个常用的步骤模板如下：
1） 用户向系统发送请求数据
2） 系统验证请求
3） 系统更新内部状态
4） 系统显示成功处理结果
任何用例流程的描述，都可以在上述基础上进行适当的扩展完成。
准则七：“确认”而不是“检查与否”
描述中不要出现“如果”字句，例如
2） 系统检查密码是否正确
3） 如果密码正确，系统显示主页面
要修改为：
2） 系统确认密码正确
3） 系统显示主页面
对于密码错误的流程，则放到可选流程中处理
准则八：习惯描述“循环执行步骤X到Y，直到条件满足”
例如“用户重复步骤3－4，直到完成选购”
准则九：对于可选流程，格式如下：
如准则七的中的例子
2a：无效密码：
1）系统显示登陆失败页面
2b：用户没有响应（超时）
1）系统自动关闭该页面
参考资料：
《编写有效用例》

admin 产品项目流程和规范, 网站项目开发, 需求分析 用例, 需求分析

[#3: Edit Options>MightyAdsense>Adsense Code]

需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分析员建立并在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择的解决方案。
在可行性研究之后，我们对值得开发的软件进行需求分析。

3.1.1 需求分析

需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。需求分析为软件设计师提供了可被翻译成数据、体系结构、界面和过程设计的模型，最后，需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。

1.软件需求的概念和分类
在我们分析需求之前，先要了解需求的类别，在获取需求时，按类别来处理就不容易遗漏。对需求有很多种不同的分类方法，其中的一种分类方法告诉我们需求应该包括：

1. 第一是功能需求，这方面的需求指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；
2. 第二是性能需求，性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求；
3. 第三是可靠性和可用性需求，可靠性和可用性需求即需求定量地指定系统的可靠性与可用性；
4. 第四是出错处理需求，这类需求说明系统对环境错误应该怎样响应，例如，如果一个系统接收到从另一个系统发来的违反协议格式的消息，该系统应该做什么？
5. 第五是接口需求，接口需求描述应用系统与其环境通信的格式，常见的接口需求有用户接口需求、硬件接口需求、软件接口需求和通信接口需求；
6. 第六是约束，约束描述了应用系统应遵守的限制条件，在需求分析阶段提出这类需求，并不是要取代设计（或实现）过程，这只是反映了用户或环境强加给项目的限制条件，常见的约束有：精度约束、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台等；
7. 第七是逆向需求，逆向需求说明了软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求；
8. 第八是将来可能提出的要求，应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求，这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

2.需求分析的任务
需求分析的任务是借助于当前系统的物理模型（待开发系统的系统元素）导出目标系统的逻辑模型（只描述系统要完成的功能和要处理的数据），解决目标系统“做什么”的问题，所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求，通过逐步细化对软件的要求，描述软件要处理的数据，并给软件开发提供一种可以转化为数据设计、结构设计和过程设计的数据与功能表示。必须全面理解用户的各项要求，但这些要求不能全盘接受，只能接受合理的要求；对其中模糊的要求要做进一步澄清，然后决定是否采纳；对于无法实现的要求要向用户作充分的解释。最后，将软件的需求准确地表达出来，形成软件需求说明书。其实现步骤如图3.1所示。
 

图3.1 参考当前系统建立目标系统模型

（1）获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，了解当前系统的组织机构、输入/输出、资源利用情况和日常数据处理过程，并用一个具体的模型来反映自己对当前系统的理解。此步骤也可以称为“业务建模”，其主要任务是对用户的组织机构或企业进行评估，理解他们的需要及未来系统要解决的问题，并用一个具体模型来反映自己对当前系统的理解。这一模型应客观地反映现实世界的实际情况。当然，如果系统相对简单，也没必要大动干戈地进行业务建模，只要做一些简单的业务分析即可。
（2）抽象出当前系统的逻辑模型：在理解当前系统“怎样做”的基础上，取出非本质因素，抽取出“做什么”的本质。
（3）建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。
（4）对目标系统逻辑模型进行补充，具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。

3．需求分析的主要工作
软件需求分析可被划分成5个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。
例1. 汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工系统相关的问题包括：（1）不能快速地获得部件的状况；（2）更新卡片文件需要2至或3天的工作量；（3）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以及将提供什么信息。
例2. 客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题和希望的信息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。
例3. 在例1与例2的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户/服务器方法似乎是合适的，但是它确实属于在软件计划中概括的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户/客户需要的吗？继续评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当地刻划了。
例3. 说明了在贯穿整个评估和综合过程，分析员的主要焦点是“做什么”，而不是“怎么做”，即应该思考的是：系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会应用什么约束？。在问题评估和综合解决方案的活动中，系统分析员创建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内容。

4. 系统分析员的主要能力
毫无疑问，在整个系统分析活动中，系统分析员起着关键的作用，这意味着我们对系统分析员有着较高的期望，其本人也应该具备各项突出的能力。这些能力的主要表现如下：

1. 能掌握抽象概念，能对其进行分类，能从中综合出解的能力；
2. 能从冲突或者混淆中吸取恰当事实的能力；
3. 能弄清用户环境的能力；
4. 能伪用户系统恰当配置软硬件的能力
5. 能较好地用书面和口头形式进行沟通的能力；
6. 有“从树木见森林“的能力。

3.1.2 需求获取

软件需求分析中的相互沟通，总是要在两方或多方间进行。系统分析员所问的第一组问题可以关注客户、整体目标和收益。接下来的下一组问题使得系统分析员能够对问题做更好的理解，使得客户能够表达其关于解决方案的感觉，例如：如何刻画由某成功解决方案所产生的“好的”输出？该解决方案强调了什么问题？能向我显示或描述解决方案所应用的环境吗？系统分析员所问的最后一组问题关注于会议的效果。例如：你是回答这些问题的合适人员吗？你的回答是“正式的”吗？我的提问和你想解决的问题相关吗？其他人员可以提供附加信息吗？其他我应该问你的问题吗？
除了上述做法之外，也可以采用一种面向团队的需求收集方法，该方法被应用在分析和规约的早期阶段，被称为便利的应用规约技术，即FAST技术，该方法鼓励建立客户和系统分析员之间的合作，由他们共同工作来标识问题、提出解决方案的要素、商议不同的方法以及刻画出初步的解决方案需求。
FAST方法的基本原则是：

1. 在中立的地点举行会议，由系统分析员和客户出席。
2. 建立准备和参与会议的规则。
3. 建议一个足够正式的议程，以便可以对所有重要点的、而又是足够非正式的问题进行自由交流。
4. 有一个“协调者”控制会议过程。
5. 使用一种“定义机制”（它可以是工作表、图表、墙上胶黏纸或墙板）记录有关信息。
6. 会议的目标是标识问题、提出解决方案的要素、商议不同的方法以及在有利于完成目标的氛围中，刻画出初步的解决方案需求。

3.1.3分析原则

在过去20年，研究者已经开发出一些实用分析方法及相应的建模符号，每种分析方法有独特的观点，然而，所有分析方法都遵循以下操作原则：

1. 必须表示可理解的问题信息域。
2. 必须定义软件将完成的功能。
3. 必须表示软件的行为（作为外部事件的结果）。
4. 必须划分描述信息、功能和行为的模型，从而能以层次的方式揭示细节。
5. 分析过程应该从要素信息移向细节实现。

3.1.4 需求规格说明

软件需求规格说明是分析任务的最终产物，美国国家标准局、IEEE（标准号830－1984）以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。
编写需求的人必须描述的基本问题是：

1. 功能——所设计的软件要做什么；
2. 性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；
3. 强加给实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；
4. 属性——可移植性、正确性、可维护性及安全性等方面的考虑因素；
5. 外部接口——与人、硬件、其他软件和其他硬件的相互关系。

下面给出一种软件需求规格说明的撰写大纲。
表3.1 软件需求规格说明的大纲

3.1.5 评审

下面的问题会被提出并确认：

1. 叙述的软件目标与系统的目标是否保持一致？
2. 已经描述了所有系统元素的重要接口吗？
3. 已经定义了合适的问题域的信息流和结构吗？
4. 图是否清楚？每个图可以没有文字补充而单独存在吗？
5. 是否主要的功能保留在规定范围中，并且均已合适地描述？
6. 软件的行为和它所必须处理的信息及必须完成的功能是否一致？
7. 设计约束是可现实的吗？
8. 是否考虑过开发的技术风险？
9. 是否考虑过其他可选的软件需求？
10. 校验标准是否被详细地陈述？它们对成功描述的系统是合适的吗？
11. 是否存在不一致性、是否信息被忽略或存在冗余？
12. 和客户全面接触过吗？
13. 是否用户复审过初步的用户手册或原型？
14. 计划的估算受到什么样的影响？

下面的指南是针对详细的规约复审而提出的：

1. 着重于说服性的连接词（例如，当然、因此、明确地、显然地、紧随的），并问“为什么”。
2. 观察含糊的术语（例如，一些、有时、经常、通常、一般地、大多数、大多数的），并进行澄清。
3. 当给出了不完整的列表时，确定已理解了所有的项。关键是查找“等等、如此这样”。
4. 确定陈述的范围没有包含未陈述的假设（例如，从10到100的校验代码范围究竟是整数？实数？还是复数？）
5. 小心含糊的动词如“处理、拒绝、处制、跳过、限制”等，它们可以以很多方式来解释。
6. 小心含糊的代词（例如，I/O模块与数据校验模块通信，且设置它的控制标志，那么标志是谁的？）
7. 查找蕴含了确定性的语句（例如，总是、每次、所有、无、永不），然后要求证明它们。
8. 当某术语被明确地定义在某地方，力图用该定义去替换其他的出现术语。
9. 当用语句描述某结构，画出图以帮助理解。
10. 当刻画计算时，至少试验两个例子。

一旦复审完成，软件需求规格说明就变成了客户与软件工程师之间的软件开发“合约”。但在软件需求规格说明完成后也可能被修改，但是，客户应该注意，每个事后的修改是对软件范围的扩展，因此可能存在着增加成本或延长项目进度等情况。

admin 产品和项目开发流程 需求分析, 需求收集

一、CRM的概念

客户关系管理（即CRM，Customer Relationship Management）简单地说，就是一套拥有完整客户资料，然后根据其特点量体裁衣，进而提供最优服务的信息系统。

我国市场经济的快速发展，买方市场的迅速形成，使制药企业面临着巨大的竞争压力。由于国内制药公司整体上缺乏研发能力，导致产品的竞争力不强，随着中国加入WTO和知识产权的保护，这种局面短期内难以改变，因此如何在短期内提高对客户的服务能力，是制药企业提高竞争能力的另外一个途径。

首先从客户的角度看：客户需要享受高质量的服务，企业所做的一切都必须让客户满意，满足客户需求。公司不仅要提供给客户优质的产品，而且应在从售前到售后的过程中提供全方位的用药咨询、技术支持、客户投诉等个性化服务，而这一切都需要建立完整的客户信息。通过这些信息获得客户的背景资料，然后从数据中分析出关于客户的知识，从而设定下一步的行动。然后通过客户的反馈提出进一步的行动计划因此这样的过程可使企业更直接地面对市场飞面对客户飞面对客户需求，进而提供满意的服务。

其次从制药企业内部看：营销管理层需要知道更及时、更准确的客户资料及销售反馈，以支持市场决策，并努力提高客户的忠诚度，而这些也需要使用全面的客户管理工具来支持。

随着制药行业巾场的竞争日趋激烈，营销系统人员流动频繁。以往公司花费大量资金建立起来的客户资源通常掌握在医药代表手中，他们一旦离职，公司不仅损失巨大的客户资源，而且后继者又不得不重新对客户进行投入，造成销售费用的大量增加，因此应努力将客户资源转变为真正的公司资源。

没有真正掌握客户资源的企业是非常危险的，营销管理层、甚至一个销售代表的更迭都可能给整个企业的销售业绩带来剧烈的波动。因此可以通过将掌握在医药代表手重的客户资料放入CRM系统中使之成为公司的资源，这样就可能避免由于他们的离职而出现的客户资源真空期。

客户关系管理系统正是推动企业在销售活动中不断地加强和深化企业与客户之间关系的有利武器。比如：在一个产品的推广活动中，将得到客户信息、商业发货情况、竞争对手的活动情况和药品价格情况记录等输入系统医药代表就可通过系统随时掌握客户销量的变化情况，而招标的价格情况、产品使用反馈、购买心理等信息也可通过系统传递给市场部和营销管理层，后勤部门也可了解产品的质量情况等。因此，在这个过程中CRM利用信息技术工具帮助企业拉近与客户之间的关系，并保证客户资源尽可能地稳定增长。

客户群如同一个端斗，潜在客户位于漏斗的顶部，最终用户的数量取决于漏斗口的大小，CRM系统的目标就是让漏斗口越张越大，如下图。

图1 CRM的目标就是扩大漏斗口

企业的竞争优势在很大程度上将取决干企业的CRM水平，即取决于企业对其客户的了解程度以及企业对客户需求的反应能力，要实现这个目标就应建立以客户为中心的信息系统，这是实施CRM的主旨。

二、制药企业的客户是谁？

毫无疑问，病人是制药企业产品的最终客户。但由于医药行业的特殊性，绝大多数药品必须在医生的指导下使用，因此医院和医生对药品的认知程度是影响药品销售的关键因素。总体上制药企业的客户可以分为这么三类：

1、医院和医生

药品通过医院销售到病人的手中，医院信息是制药企业客户信息的重要内容。

医生具有处方权，同时他们也最熟悉药品在临床的应用情况。因此企业对医生客户的服务情况是当前药品销售最关键的因素，而医生客户的外延还应当涵盖医院院长、药剂科主任、专家等重要人员。

2、商业客户

目前药品流通的主要渠道是通过药品经销商或药材站销往医院，同这些商业客户保持良好的商业合作关系也是制药企业CRM系统的主要目标。

3、政府客户

随着医疗体制的改革，为了降低医疗费用，国家对医院的药品采购进行r大规模的招标，因此各地区社保、卫生部门的相关人员是政府客户中的主要内容。企业在与他们打交道的过程中不仅可以熟悉和掌握招标信息，同时可以尽快地适应国家在医药行业的政策变化，迅速寻找解决方案。

由于以上客户分别由企业不同部门的相关人员与之联系，因此客户管理系统应能有效地实现各部门之间的信息沟通，使医药代表从不同的方面了解客户情况，进而为客户提供最优的服务。

图2 制药企业CRM的主要内容

制药企业客户关系管理系统应至少包含以下几个模块：

1、医院和医生管理

主要记录医院和医生的详细资料。

在医院管理中，除反映一些基本信息外还应有医院各科室的情况、专业特长、进药渠道、对公司的用药情况，此外也可记录其目前产品的研究水平和使用情况，并对各地区的重点医院进行分析，以及定期组织医药代表进行数据统计和上报。

在医生管理中，应建立主要临床医生的档案，同时对VIP医生做重点跟踪，记录其学术情况、参加的主要市场活动及访谈情况、对用药情况的反馈等。

2、商业客户管理

建立商业客户的档案，同时分析商业库存及其流向情况，以便更准确地把握医院推广数据的准确性。

3、招标管理

招标采购正逐渐成为各地区药品采购的主要形式之一，这样就形成另外一个客户群体——政府客户。在此模块中除记录人员信息外，还应记录招标公告（如招标上体、时间、品种和规格，数量等）以及中标情况（中标价格、中标单位或代理商等），如果需要也可将其它资料甚至产品的注册信息记录在案。

4、竞争对手分析

知己知彼，方能百战不殆。竞争对手的产品、价格、销量、重要客户、市场投入及推广活动等都是分析的资料，同时系统应能够给出市场占有率、变化趋势等重要数据。

5、销售数据统计和分析

为医药代表和地区经理提供一套数据上报和汇总查询的工具，使他们及时地了解最新的销售情况，同时，医院数据、商业数据的比较分析，也可帮助管理层发现问题和解决问题。

6、售后服务

应利用各种信息技术的手段为客户提供全方位的服务，如800电话、呼叫中心等解决客户投诉，并提供技术支持、疑难问题解答等。同时应建立知识库，记录对客户的服务内容及处理经验，进而降低售后服务的成本，提高服务质量。

四、CRM系统的实施

CRM系统的实施与（企业资源计划）的实施有很多相似的情况，但前者更多的是对客户和市场等外部信息进行管理，同时所涉及的人员和部门更加分散，信息收集和过滤更加困难，因此从某种程度上说其实施难度更高。

总体上，CRM系统的实施应考虑以下几个方面的问题：

1、要准确地勾画出信息流向，并解决信息的传递问题。一般而言，医生和医院信息由医药代表负责收集。商务代表负责商业客户的信息，政府客户由相关的医药代表和招标主管负责，市场部则需要将竞争对手情况及市场推广活动悄况的信息补充到系统中。这此信息实际上是相互关联相互渗透的，大多数情况下它们又分散在不同的地域中，需要集中起来进行整合，因此要依靠信息技术手段解决通讯或网络连接问题，以便使软件系统顺利地运行。

2、要解决在项目实施中如何让每个部门将各自拥有的信息拿出来进行整合，并且约定谁来录入这些信息的问题。要告诉医药代表可以通过系统开发出更多的客户，告诉商务代表其销售的药品流向了那些医院，告诉市场人员可以通过系统了解市场的第一手信息。只有当这些人员觉得他们能从这些系统中得到更多，才能在实施中得到更多的支持，另外还要解决信息的及时输入，这是系统能否正常运行的关键。

3、要选择合适的供应商或开发商。目前，有众多的软件商提供CRM解决方案，但由于他们缺乏对医药行业和医药企业运作的了解，其软件系统很难满足实际需要，因此在实施前对他们进行一定的评估是非常重要的。

4、要充分意识到CRM系统实施的艰巨性，项目经理的选择、项目组人员之间能否相互协作都会影响项目的实施。因此如何发挥团队精神、加强集中领导，也是实施中要注意的关键。

庄子曰：“多算胜，少算不胜。而况于无算。”要想在激烈的市场竞争中立于不败之地，只有比对手更了解客户，比对手更了解客户需要什么，同时提供更优质的服务，提高客户满意度，只有这样才能取得持久的胜利，这就是建立客户关系管理系统的主要目的。（万方数据）

admin CRM CRM, 需求分析

网站项目管理（WPM）是如何完成的？之四

前言

　　随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。
　　网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web 服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。
　　在本文中，笔者将网站项目管理（WPM）与软件工程的统一过程管理（RUP）进行参照比较，并结合实际工作经验，力求将网站工程管理（WPM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。
　　按照笔者的经验，网站项目管理可以分为以下六个阶段进行控制：
1. 需求分析及变更管理
2. 项目模型及业务流程分析
3. 系统分析及软件建模
4. 界面设计、交互设计及程序开发
5. 系统测试和文档编写
6. 客户培训、技术支持和售后服务
　　需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（四）界面设计、交互设计及程序开发

　　在网络项目开发过程中，这个阶段也叫做构建阶段，是工作量最大、最艰苦也是最难以控制的阶段。不管一座大楼的设计蓝图多宏伟，若没有管道工、泥瓦匠、水电工等各种工匠一砖一瓦地艰辛积累，密切协作，这座大楼始终是空中楼阁、海市蜃楼。

本章包括以下内容：
一：界面设计打开用户之门
二：交互设计建立沟通的桥梁
三：程序开发是系统的基石
四：本阶段的重点工作
五：总结

一：界面设计打开用户之门
　　对于以Web服务为模式的项目，无论是访问用户还是系统管理员，主要工作都是通过浏览器的界面交互完成。给系统设计合理友好的操作界面就像给人穿衣服一样，合体舒适的搭配能给人耳目一新的感觉，反之则令人敬而远之，甚至失去进一步深入了解的兴趣，这无疑不是开发人员所期望的结果。
　　以网站为表现方式的系统界面设计所涉及的知识远远超过了美术的范畴，作为一个优秀的Web界面设计师来说，需要掌握的不仅仅是电脑制图的能力，还应该具备心理学、广告创意、美术工艺、排版艺术等多方面的综合素质，系统界面绝不是孤芳自赏令人难以理解的抽象画，而应该成为绝大多数用户共同接受的最方便的日用品。
　　关于Web美工创作的操作技巧不是本文所关注的，我们希望知道的是用户最需要的是什么样的界面？根据笔者的经验，在进行产品设计和项目开发的界面设计中是有所不同的。产品通常是指可大量分发销售的成熟性的产品，具体用户是不确定的，而项目大多是针对具体客户的需求进行开发，不具备二次销售的条件，当然，在二者之间总还是能找到共同点的。
　　产品设计由于面对的是未知的用户，因此界面设计必须挖掘的是用户习惯和观念的共性，大众化产品（例如邮件系统、BBS、门户网站等）、商业应用产品（例如交易系统、电子办公系统）或专业应用产品（例如财务系统、杀毒系统）等等，需要考虑的是所有人或某一类的人的共同习惯和审美观念，而不是刻意地出奇招、不断地考验用户的智商和耐心。
　　项目开发则相反，面对明确的具体用户考虑更多的是个性化设计，也许有些是非常规的要求，但是用户已经具有特殊的偏好和习惯时，应尽可能满足用户的需求进行设计。在笔者参与某个行业的办公系统设计过程中，用户就提出了非常特别的要求，所有的界面不能出现外国人和外国场景的形象，每一页都需要变换颜色，另外站点标题要大得出乎寻常，失去比例，这时候美工只能迁就用户的心理和习惯，可是这样的设计用到产品设计上，大多人都会感到不舒服。
　　不管是产品设计还是项目开发，界面设计都应该遵循以下共同的规则：
* 界面风格需要一致：
　　每个新的系统对用户来说都是一次新的学习过程，如果界面风格经常变化，不保持统一，无疑更增加了用户的学习难度，也许会导致用户的厌烦。比如：第一页的导航条是图片型的放在页面顶部横排的，而在第二页导航条却成了文字型居左竖排，用户会为了捉摸不清设计师的意图而大光其火。再比如，有些设计师考虑到用户方便，在页面上放置了后退的按钮，但是要是不注意保持一致的话，用户也许会糊涂后退、回首页、BACK、上一页这些按钮究竟有什么区别?也许非常恼火你是不是拿他在开涮！
* 界面元素对象化：
　　在程序设计中需要注重模块化，而界面设计中对象化同样非常重要。将界面元素对象化，比如底部版权信息、导航条等，图片、JS也尽可能复用，比如站点标志、搜索按钮、滚动信息的JS文件等等；
* 建立标准的文档管理和设计规范：界面设计涉及的要素比较多，文件类型复杂，而界面文件往往还需要另外通过程序进行编译，这就要求了界面设计人员必须建立规的设计规范和标准的文档管理方法：
* 制定文件命名标准
* 设定文件统一路径
* 保存原始创作文件（例如PSD、Fla源文件）
* 最终完成文件（经过用户认可的文件）
* 单独管理摸版文件（经过编译或嵌入程序的文件）
* 考虑用户偏好习惯和方便性：
　　我们经常可以听到界面设计师说：“怎么在我机器上看得好好的，怎么在你那里就变样了？”其实道理很简单，用户的操作环境和习惯与设计环境是有差别的，界面设计同程序一样需要进行测试，主要测试的对象为：
* 浏览器类型和版本兼容问题：假如有个很重要的菜单是需要IE5.5支持的，但是用户万一使用的是IE4.0版本，那么这个菜单就再也打不开，结果可想而知；
* 分辨率：界面设计师的屏幕也许是17寸的，分辨率甚至做到1280×960都是可以接受的，但是用户的如果用的14寸显示器，分辨率只能达到640×480，界面布局看起来会很可笑；
* 字体大小：利用样式表精确控制页面元素，特别是字体是很重要的。有不少用户喜欢更改浏览器默认的字体显示大小，当设计师看到用户将字体显示调整成最大而将表格撑得乱七八糟的时候，或许会痛心疾首的；
* 考虑特殊情况：用户或许在浏览器设置了禁止显示图片或禁止JS脚本等，有必要为图片设置好尺寸以免影响其他元素的显示，并有其他的方式代替JS需要显示的效果和信息。
* 编写帮助：
　　无论多么出色的界面设计对用户来说都是陌生的，那么编写站点帮助或软件帮助是个非常有效的办法，把你的设计意图和使用介绍明明白白地告诉用户，在用户遇到困难的时候能够得到最快的帮助，不但可以降低用户的不满程度，同时可以帮助用户更加系统深入地学习和掌握。

二：交互设计建立沟通的桥梁
　　作为交互设计人员应该读读Alan Cooper的《软件创新之路》，被誉为“VB之父”地Alan Cooper明确地提出了将程序开发划分为交互设计和编码设计两大部分，笔者非常赞同。
　　“软件越来越难用，越来越难学。”我们不止一次地听到用户如此地抱怨，也许程序员认为机器就是如此理解程序的，随着系统的日益复杂和功能的不断强大，软件原来越难用，门槛越来越高是很正常的，但是别忘记用户才是系统的所有者和使用者，期望用户成为计算机专家的要求显然是难以接受的。在国内无论是从事商务的技术人员还是技术型的商务人员都极其缺乏，交互设计师就理所当然地应该成为彼此沟通的桥梁。
　　
　　程序员和用户的差别是很明显的，因此通过交互设计建立良好的沟通是非常需要的。

（一）交互设计师的侧重点并不在程序的编码实现，而注重于用户如何最好地与系统交互操作，在设计中重点需要考虑的是：
* 系统易用性：
　　并非每个用户都是计算机的熟练用户，面对隐藏的层和特殊设计的菜单可能会抓瞎，用户不见得能明白双击左键能自动滚屏或者怎样能让自动滚屏停下来、直接看最下面的结果？交互设计师特别需要重视的就是系统的易用性。有条件的话，可以让不同的陌生用户从首页开始操作，不给予任何提示和帮助，观察用户的上手和熟练程度，记录并查找所有的陷阱和缺陷，加以改进。
* 流程简便：
　　“简单就是美”，在系统交互设计方面更是如此，如何用最少的操作，最明显的提示和帮助，完成一项流程的操作是需要花大力气进行优化的。
* 盲点测试：
　　用户的操作并不是严格的按照系统的提示顺序进行，也不一定会按照系统的提示要求去做，而程序员在设计的过程中是按照既定的逻辑进行开发的，测试中也难免以自己的习惯操作，这时就可能出现盲点，即系统存在未被测试到的状态环境。编写测试软件或利用其他测试工具可以大大提高测试的可靠性。
　　例如一份表单正常提交以后，假如用户利用历史记录后退，回到提交前的状态，这时候修改了提交内容，又再一次提交，那么结果是什么呢？再比如，假如设计的弹出窗口的尺寸是700×500，且不可改变大小，隐藏滚动条，而用户万一使用640×480的分辨率，那么弹出的窗口中，用户如何能点击到最下面的按钮？
* 出错及异常提示：
　　凡是软件都是有BUG的，因此对各种出错或异常状态给予用户一个友好的提示和帮助，并提示用户大概是由于什么原因，那么用户会愉快的多。
　　笔者遇到过一个用户注册系统，用户注册后希望修改密码，有的能做成功，而有些人怎么也改不了，检查了很长时间才发现由于密码设置的是不少于三位不大于八位，许多用户密码超过了八位，因此无法修改成功，但是由于没有提示出错原因，所以用户就不断拼命地提交，最后只好愤怒地去投诉。
　　再例如发布信息的时候，可能会因为填写时间过长，提交时被系统拒绝数据丢失，那么用户辛辛苦苦撰写的内容永远消失了，还有什么比这个更令用户沮丧的吗？在填写的输入部分给用户一个时间提示，或允许后退找回刚才的内容，至少可以让用户容易接受一些。
* 利用用户环境测试
　　利用用户的操作环境进行测试，用户的服务器、网络线路和客户机也许跟开发环境差别巨大，用户的机器配置、网络环境对系统的要求是不一样的。比如设计客户端的APPLET时也许会因为客户机的内存不足而崩溃，也可能因为文件过大，远程访问时处理时间过长而响应失败，。

　　（二）Web的交互设计师需要掌握的技能主要是Javascript、VBscript、Dhtml、Flash等，还需要了解心理学、人因工程学、系统工程等方面的经验和知识，认真把握每个交互动作的合理性和可行性，这个交互也许是个链接，也可能是个表单、提示窗口或者是滚动条的拉动距离，检查是否最优化和最合理的方式。
　　举个很简单的例子，在链接列表过多出现翻页的时候，程序员很自然地会将上一页、下一页的翻页按钮放在了最底下，但是列表很长的时候，用户每次翻页的时候都需要把滚动条拉到最下面才可以点击到翻页按钮，用户可能就会抱怨，明明知道在某一页，却每次要点击后拉滚动条寻找翻页按钮，而如果将翻页按钮在列表的上面也放一条，并且设置直接跳转到某页的按钮，则大大减轻了用户的工作量，类似的例子在我们的设计中屡见不鲜。
　　
三：程序开发是系统的基石
　　程序员进行编码，构成了系统的基础。在进行系统分析和软件建模以后，程序开发便进入实质性的过程。但是在程序员动手之前不单需要和系统分析员打交道，还要和界面工程师，交互设计师，业务流程分析员以及客户交流，除了理解程序逻辑以外，同时需要理解界面设计和交互设计的要求，使得程序开发成功的可能性大大提高，达到事半功倍的效果。
　　随着网络开发技术的日益发展和用户需求的不断增长，系统开发中的编码工作日益繁重，不仅仅需要考虑性能和功能的实现，而且需要考虑今后的维护和扩展，需要考虑到系统的集成和稳定，许多稍微复杂一些的系统开发便不再是一个人能独立完成的，因此程序开发需要遵照严格规范的开发过程。
* 文档规范：软件即文档。
　　良好的文档习惯是系统开发极其重要的，文档是程序的一部分，程序员花一定时间进行文档编写是份内的工作。具备完整的文档记录，对于系统今后的二次开发、查错、升级具有重大的作用。可以说即使代码全部扔掉，只要文档完整，很快就可以再造一个系统出来，而只保留了代码，缺乏文档的时候，就像被抽了脊梁的标本，再难站起来恢复原样。
* 编码规范：编码规范包含了程序排版、注释、命名、可读性、变量、程序效率、质量保证、代码编译、代码测试和版本控制等等注意事项。
　　程序员最常见的问题之一：“别人写的代码看不懂，与其改写不如重写”。基本上都是没有按照编码规范开发的缘故。所以我们经常听说某个程序员离职以后，他所写的那些模块就没法维护和管理了。
* 代码复用：代码复用是程序员的梦想，也是系统成熟度的重要标志，关于代码复用方法的讨论不在本文之列，但是做为代码复用是程序员走向成熟和提升的必经之路。
* 测试测试再测试：笔者在软件工程的讨论会上，微软的一位项目经理在介绍微软如何保证产品质量时说：“微软质量保证的秘密就是：测试测试再测试！”在IE4.0的开发小组中，200名开发程序员意外还有200多名测试工程师，而且测试工程师的水平甚至高于开发工程师。测试是系统质量最直接有效的手段。在国内的开发环境达到这样的投入和水平显然是不太现实的，但是尽可能提高测试环境和加强测试管理，是程序员和测试工程师共同的方向。

四：本阶段的重点工作：
　　在这个阶段是整个项目组参与角色最多，也是协作最密切最难控制的过程，笔者认为做为项目经理特别需要关注以下问题：
　　1：建立项目小组的沟通渠道：
　　沟通是项目小组具有密切协作形成凝聚力的最重要的手段，在项目开发过程随着各个角色的工作进展，冲突和矛盾是必不可少的，无论是通过论坛、邮件、会议、口头还是私下沟通，项目管理人员有责任和义务建立小组通畅及时的沟通渠道，根据有经验的HR经理分析：有效的沟通应该是在问题发生的48小时之内，否则解决的效率会降低75％。
　　2：建立文档规范和管理办法，借助PVCS、WINCVS等相关工具建立整个项目小组的文档；
　　2：建立BUG报告系统，在内部预先创建测试环境，将BUG尽可能早地消除掉。
　　3：测试和文档工程师的工作自始自终地贯穿着项目开发过程，这在以后的文章中会继续介绍。

五：总结
* 沟通是本阶段最需要注意的问题；
* 建立文档管理体系；
* 建立测试环境和测试标准；
* 界面设计是为用户设计的，不是用来自己欣赏的艺术品；
* 为用户着想，人性化设计是项目成功的保证；
* 代码复用，对象化模块化设计是界面设计、交互设计和程序开发共同追求的目标。

admin 网站项目开发 产品经理, 需求分析, 项目流程

如果眼光仅仅放在满足客户眼下的需求，当问题不断出现时再不断修补，头痛医头，脚痛医脚，甚至系统构架需要不断调整或重新设计，那么，很快就会陷入代码泥潭或坠入系统重复开发的无底深渊，当初项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败，软件建模使系统开发走向成熟。

本章包括以下内容：
一：系统分析在网站项目管理中的地位
二：系统分析所要做的工作
三：系统分析的难点和技能要求：
四：软件建模使系统开发迈向成熟
五：总结

一：系统分析在网站项目管理中的地位
在进行了需求分析和业务流程分析并得到客户的认可之后，对项目进行系统分析是极其重要的。系统分析是能体现整个系统的灵魂的文档，将客户的需求从具体到抽象的一个过程，并制定编码人员可实施的规范和标准。
由于Web应用技术发展的历史相对与软件的历史短得多，在开发网络应用系统尤其是网站制作的系统设计中设计人员往往对系统分析重视的不够，特别是设计一些初期比较简单的或交互及功能较少的网站时，主要原因通常为：
 客户初期的需求比较简单，忽略了客户潜在的巨大需求；
 项目实施周期短，初期阶段采用最快的而不是最合理的实现手段；
 经费有限，难以支付高质量的人力费用；
 Web编程技术手段多样，容易上手，设计人员参差不齐；
从现实中来看，网站项目的开发与管理和实施远不如软件工程规范，在编程语言、数据库、通信协议、应用服务器等相关环境都在不断快速发展和完善的情况下，的确很难期望每一个设计师都能网站项目进行系统的合理的分析，从而制定一套跨平台、健壮的、易扩展和升级的系统方案。
但是，这并不能成为系统分析员逃避或懈怠的借口，如果把一个系统比做一部汽车，系统分析的工作相当于设计发动机，也许很容易就想像的出用125cc的摩托车发动机去牵引10吨重载卡车会是一个什么样的后果。
在系统分析的过程中需要对需求分析进行进一步的深化和分析，通常客户及业务人员在需求分析和流程分析的过程中比较注重功能上的表现和定义，即使是做出正规的用户界面原型，对系统的需求也是不完整的，处于非技术人员的缘故，很难苛求能提出完整清晰专业的性能需求，但不意味着这需求不存在，而且这隐藏的需求对编码人员来说是极其重要的。
因此，客户的需求能否在系统中得到真正的体现和实施，系统分析是至关重要的。

二：系统分析所要做的工作：
把系统分析和详细设计阶段分开，针对不同项目的具体情况再决定采用什么方式进行开发。
那么在系统分析过程中重点要做的是：
 对客户的需求分析进一步完善和补充，尤其是性能需求：让客户更加清楚这是一个什么样的系统，所要达到的功能和性能指标是什么，系统的扩展性和适应性如何，如何为客户今后的升级或维护提供最有效的方法。
 系统运行所需要的的环境：系统能正常运行所需要的硬件、软件、网络环境；
 系统的资源说明：系统所需要的各种成本。包括人员、时间、工作环境、一次性投入资金、持续性投入资金等所有资源。
 系统可行性分析；
对于系统分析员比较苦恼的是大多客户在系统的要求上提不出独立的或成熟的意见，而将烫山芋交给了系统分析员的手上，为了避免在系统论证方面难以把握的失控和无从下手，设计几种不同类型的方案供客户选择不失为一个好的方法：
“比如通常至少应该考虑下述几类可能的方案：
　　1：低成本的解决方案
　　系统只能完成最必要的工作，不能多做一点额外的工作。
　　2：中等成本的解决方案　
　　这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。
　　3：高成本的”十全十美”的系统
　　这样的系统具有用户可能希望有的所有功能和特点。系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上，推荐一个较好的系统（最佳方案），并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。”（引用《如何写系统分析书》一文）
经过系统分析的阶段，我们就比较容易和客户在系统如何部署、采用的数据库类型、设计模型和分析模型等方面达成一致的认识，如果能顺利地将客户的需求业务逻辑分析转化为程序逻辑，把原先用户可视化的界面原型和业务流程图映射成编码人员理解的模型和规范时，那么恭喜你，项目已经成功了一半。

三：系统分析的难点和技能要求：
网络应用的开发技术在日新月异地进步，从而使网站应用系统的开发模式具有多种选择性，达到同样的目标可以采用很多不同的方式，现代的应用系统越来越成为一个庞大的集成方案，需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等，无疑对系统分析员来说是个严峻的考验，任何人都不可能精通甚至说掌握全部的技术，简单例子：现在有Windows，Unix，Linux等各种服务器操作平台，有SQL Server，Oracle，DB2，Sybase，MySQL等数据库，有JAVA，PHP，ASP，CGI，JSP，C++，VB，Delphi等等工具，谁能全部精通呢？如果不能，那么如何确定是Windows+SQL Server+ASP好还是Unix+Oracle+JAVA合适？况且各种软件和语言还在不断发展进步之中，超越窄带的互联网，今后还可以涉及到宽带所带来的变动，或者增加与无线移动的接口，因此系统分析员能否出色的胜任工作很大程度上决定了系统开发的成败。
系统分析的主要难点在于：
 对客户隐藏的性能需求的分析：由于客户对尚未实施的系统无法预见，对今后的业务发展也无法预知，对性能需求的分析和定义更需要系统分析员协助客户去确定和挖掘；
 确定项目设计方法：根据项目需求和资源的配置选择最合适的设计方式。
 对系统模块的划分和代码复用的设计：模块最大化，代码复用度最高，是一个成熟的系统不断致力追求的，将大型复杂的应用系统分解成相对独立，具有高度复用的模块，各个模块之间采用规范的参数接口，将大大提高系统的开发效率和维护升级的方便性。即使在网站的模版设计或交互设计上，也尽可能采用嵌套可复用的模版或调用统一的样式表、JS文件等。
 项目整体评估：系统分析员绝不应成为孤立的完美主义者，而需要根据项目的大局出发，比如公司的资源配置、人力状况、客户要求等因素评估项目整体和各个模块的工作量、进度和分配资源，制定出最合理的可行的实施方案。
系统分析员不但需要具备良好的沟通协调能力，更需要具备业务和技术领域两方面的专业技能，在项目小组中是非常关键的角色之一。

四：软件建模使系统开发迈向成熟
Web应用系统往往随着客户的需求增长，开发不断深入，最终变得非常复杂，而且以Web为核心的网站系统通常都具有高度的动态扩展和交互，要在不完整和不断改变的需求情况下，在有限的时间内完成一套容易修改和维护的健壮的系统，在UML（统一建模语言）出现之前是极其困难的。
大多的Web设计师或程序开发员为了让客户尽快看到可运行的应用系统，经过界面设计或简单的系统分析后直接进入编码阶段，甚至各个模块分头开发，服务器段代码随意编写、数据库任意添加、参数定义没有规范，整个应用系统处于一种无序混乱的状态，当我们采用建模及按照软件工程的方式进行管理的时候，情况马上就会好的多。
什么是建模？
 建模是使你逐层深入解决问题的办法；
 确认应用系统的功能需求并为事务处理原则建模；
 对抽象的对象映射需求，辨认和提供设计模版并创建惯用的模版；
 分辨和设计对象或划分三层模型的服务；
 对软件的组成部分映射成对象并设计组件在网络上如何分布；
UML（Unified Modeling Language，统一建模语言）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，同样，在网站设计或以网站为表现形式的各种网络应用项目中，UML也表现出强大的作用。UML能够描述系统的静态结构和动态行为：静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系；动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言，但我们可以用代码生成器将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML模型。
我们可以看的出，建模并不等同于程序编码，利用同样的UML模型可以生成不同语言的框架代码，而且可以通过反向生成，在编写代码过程中及时更新UML模型，这对系统分析员和项目管理人员来说是梦寐以求的。只要能够仔细地把握客户的需求，不断改进UML模型，那么采用什么样的语言开发已经成了次要，大量的需求积累和分析工作能在客户需求变化时得到高度的复用，即使系统采用新的语言重新开发，需要的也仅仅是编码部分的工作。
虽然软件建模可以在开发的任何阶段进入，但是在设计初期，应该将精力更加集中在系统功能及性能分析、系统运行环境、选择编程语言等，而不是考虑考虑程序的细节，如在屏幕上的什么位置放置按钮等。在项目开发的中期引入建模是非常有意义的，通过建模把握程序开发的方向，准确完成需求分析中所要求的任务。
在高展先生的《全程建模》一文中阐述的“全程镜像一体化建模方式“，整个建模过程依靠业务驱动，在模型设计中利用盒子的上下两部分分别代表业务组织结构和软件逻辑结构，将客户可视的具体的需求与系统抽象的逻辑流程一一对应，这对缺乏技术背景的客户代表和经验不足的系统分析员之间的沟通具有明显有效的作用。

五：总结
系统分析是项目开发中最艰巨的工作，本阶段需要特别注意的工作重点在于：
 补充完善上一阶段可能欠缺的系统的性能需求；
 系统分析员需要站在全局出发，设计合理可行的设计方案；
 在需求不明的情况下设计多种解决方案供客户选择，
 将系统分解模块，最大限度地设计代码复用；
 使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率

admin 网站项目开发 产品经理, 需求分析, 项目流程

　　随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。
　　网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web
服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。
　　在本文中，笔者将网站项目管理（WPM）与软件工程的统一过程管理（RUP）进行参照比较，并结合实际工作经验，力求将网站工程管理（WPM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。
　　按照笔者的经验，网站项目管理可以分为以下六个阶段进行控制：
1. 需求分析及变更管理
2. 项目模型及业务流程分析
3. 系统分析及软件建模
4. 界面设计、交互设计及程序开发
5. 系统测试和文档编写
6. 客户培训、技术支持和售后服务
　　需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（二）项目模型及业务流程分析

　　网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程，也不是对传统工作流程的简单复制，而需要对传统的工作流程进行合理的优化、改进和重组。

本章包括以下内容：
一. 编写项目模型文档，使所有人都一目了然
二. 业务流程分析员进行流程设计
三. 界面工程师设计用户界面原型
四. 以用户为中心的设计思考
五. 制作设计计划书
六. 总结

一. 编写项目模型文档，使所有人都一目了然

　　为什么要制作项目模型文档？
　　通常用户提出的需求是凌乱的，不完整的，甚至是不正确的，而且更细致的需求经常是在项目开发进行中才被挖掘发现的，这对于开发人员来说是个极其困扰的问题。那么，在进行需求分析后制作项目模型文档，能在项目进入开发前，双方对即将要开始完成的项目的结果有个共同的认识，并提早暴露可能出现的需求变更，那么将大大提高开发的效率和质量。
　　缺乏经验的项目人员往往在接受任务后迫不及待地进行系统分析和开发，而不愿意多一点时间在和客户反复推敲项目需求和模型，开发过程中想当然地凭空为客户做了很多假想，费了九牛二虎之力却吃力不讨好，可想而知，在不知道终点在哪里的马拉松比赛中，你会跑到哪里去？！
　　因此在确认了客户的初步需求以后，业务人员应该进行项目模型的设计描述。
　　首先，我们要定义一下词汇表，并非每个客户或者项目小组成员都能够明白“用户”、“角色”、“用例”之间的差别，也不见得都能很好地理解“通道”、“前台”、“后台”到底是什么含义，为了让项目模型文档使每个浏览者正确地理解，定义词汇表是非常需要的，尤其是面对传统行业初次进行信息化设计的用户。
　　
　　模型描述采用最自然的语言进行描述，这份文档是对需求分析报告的进一步描述。使得客户代表、项目经理、开发人员对即将展开的项目通过项目模型的描述产生最直观的印象，并针对关键的问题进行讨论并达成统一认识，比如功能要求、性能指标、运行环境、投资规模等等。
　　

二. 业务流程分析员进行流程设计

　　业务流程分析员的人员应该善于简化工作，担任此角色的人员中必须要有具备广博的专业领域知识，并且具有良好的沟通技巧。
　　业务分析人员重点需要协助客户将需求进行归纳分析，查找出所有的业务主角，确定业务主角后，每个主角的相关活动及流程应清晰地制定出来，最终设计出逻辑视图、用户界面示意图。比如一个电子商店系统，除了系统管理员、业务经理、业务员、物流配送员、客户服务人员等角色以外，可能还存在外部协作单位的不同角色，比如供应商、分销商、广告客户，还有购买用户，甚至再细分为普通消费用户、VIP消费用户、集团消费用户等等，每一类角色参与系统活动时的入口和流程都有所不同，通过逻辑图和示意图，业务流程分析员将系统的机构简要明确地进行描述。
　　在进行业务流程设计，需要注意以下事项：
* 调查用户网络环境和配置，使架构设计师能够制定合理可行的系统架构；
* 调查用户偏好和技能水平，这将直接影响到项目开发的深度和用户界面的设计；
“虽然开发人员和管理人员很容易自认为他们了解用户需要，但实际情况常常不是这样。人们往往关注于用户应该如何执行任务，而不是用户偏好如何执行。多数情况下，偏好问题不仅仅是简单地认为已掌握了用户需要，尽管这本身就很值得研究。偏好还要由经验、能力和使用环境决定。”
* 预测并制定系统的性能指标，为测试人员编写测试计划提供依据。
许多项目设计中比较重视功能的实现，测试阶段看似满足了客户的需求，但一旦投入使用的时候，便会发现性能上面临着一个个瓶颈。客户由于对专业知识的了解程度有限，也往往忽略了这方面要求，因此为了避免日后陷入纠纷，事先预测并制定性能指标是非常重要的。

三. 界面工程师创建用户界面原型

　　为了在实际系统开发投入之前，创建用户界面模型是非常重要的，开发原型的成本远远低于实际开发的成本，在项目初期，创建完整的用户界面揭示和测试系统的所有功能和可用性，并能够使客户代表参与讨论及修改，可以大大提高项目的成功几率。
　　创建正确可行的原型以后，系统分析、设计及代码的编写都必须遵照原型进行，确保构建的系统是正确的，测试人员和客户也能够在开发过程中即实时地参与检查，可以有效地保障了项目的质量。
　　根据业务流程分析员所提供的流程分析逻辑图及示意图，界面设计工程师开始设计制作用户界面原型，目前这个阶段，对于界面设计人员来说还没有进入精细设计的阶段，所以最重要的是将业务流程完整地表现出来，并和客户就设计风格，设计规范进行确认和定义。
　　界面工程师在充分理解客户需求和所有的业务流程之后，利用合理的布局设计用户界面。比如网站的首页风格、首页需要显示的各个元素、导航的分类和表现方法、各类业务角色的入口等等。
　　在此需要注意的是，用户界面不仅仅是网站访问者所浏览的界面，也包括了特殊用户、管理员、业务伙伴等不同的用户界面，甚至还有提示界面、警告界面、出错界面等等，设计完整的用户界面原型不仅能够使客户及测试人员更容易明确需求，也对项目的质量起到不可忽视的作用。
　　
　　
四. 以用户为中心的设计思考

　　无论项目设计开发人员的水平多么精尖，毕竟不是系统的最终用户，最大限度地满足客户的需要才是关键，系统设计人员往往口头上挂着以用户为中心的口号，而实际上工作中又在大量地假想，或是出于懒惰或是出于条件限制，对于将来使用系统的不同用户来说都可能产生意想不到的障碍。
　　真正做到以用户为中心，就要先放弃沉淀在脑子里的经验和想象，到客户工作的地方去、观察记录客户如何工作、然后与客户谈论他们的工作。
　　在团队拓展训练中有一项叫做“盲人方阵”的课程，可以想象一群什么也看不见的人如何把一根长绳子拉成正方形景象吗？目中无人的人会懂得倾听和服从吗？我们不能假设用户到底是个健全人还是盲人，也不能假想用户应该会怎么做不该会怎么做，只有去仔细观察和沟通，才能制定出真正符合用户需要的计划。
　　有专家提出：开发人员应决定用户的组成，并让用户尽可能早地涉入，并提出了几种熟悉用户、他们的任务以及需求的方法：
* 与用户交谈
* 到办公地点拜访用户
* 观察用户工作
* 将用户工作录像
* 了解工作组织
* 自我尝试
* 使用户在工作时边想边说
* 让用户参与设计
* 在设计小组中包括专家级用户
* 执行任务分析
* 利用调查和问卷
* 制定可测试的目标
　　在有可能的情况，在需求和流程设计中努力做到精确、客观和细致，不但能保证系统开发的质量和成熟度，也会使你得到客户高度的满意和信任，为今后更多的业务合作敞开大门。
　　
　　
五. 制作设计计划书
　　到了这个阶段，可以说掌握了客户的需求并对计划实施的系统开发有了清楚地认识，与客户之间达成了共识，那么在进入下个阶段的工作时，制作设计计划书是非常必要的。
　　设计计划书是全面描述整个系统的全貌，作为系统分析、测试人员工作的基础，同时也是客户验收的标准，作为业务合同的内容之一，因此，应该仔细谨慎地撰写设计计划书。
　　根据项目的不同，设计计划书的内容或许有所不同，以下笔者提供一份样本供大家参考，该份样本基本涵盖了需要在计划书中进行确认和描述的核心要素。

六. 总结
　　在本阶段的工作过程中，核心的任务是通过上个阶段的需求分析，进行项目模型设计和业务流程分析，并制作用户界面原型得到用户的确认，最终完成双方认可的《设计计划书》，作为下一阶段系统设计和软件建模的依据。
如何高质量地完成业务流程分析阶段的工作，笔者总结的经验如下：
* 真正以用户为中心的设计，到客户的实际工作环境中观察和记录；
* 仔细查找各种业务主角，并表述不同主角的各种操作流程步骤；
* 简化需求，将客户的需求归纳整理，抓住核心问题；
* 细化需求，针对核心问题，模拟用户角色，进一步确认流程和规范；
* 认真制定设计计划书，为下阶段的工作打好基础；

admin 网站项目开发 需求分析, 项目流程, 项目管理

前言

    随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。

    网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web
服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。

    在本文中，笔者将网站项目管理（WPM）与软件工程的统一过程管理（RUP）进行参照比较，并结合实际工作经验，力求将网站工程管理（WPM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。

    按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：

    1. 需求分析及变更管理

    2. 项目模型及业务流程分析

    3. 系统分析及软件建模

    4. 界面设计、交互设计及程序开发

    5. 系统测试和文档编写

    6. 客户培训、技术支持和售后服务

    需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（一）如何做好需求分析及变更管理？

    业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。

    本章包括以下内容：

    一. 让客户畅所欲言，罗列出所有的需求

    二. 透过现象分析潜在的需求

    三. 利用自然的语言描述项目模型

    四. 利用示意图和图表将用户的需求表现出来。

    五. 什么人要看需求分析报告？

    六. 建立需求变更日志，制作新版本的需求分析报告。     

    七. 本阶段重点工作角色

    八. 总结

一：让客户畅所欲言，罗列出所有的需求

    让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕”勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。

    很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！

二：透过现象分析潜在的需求

    很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。

    客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

    比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下了更好的基础。

    笔者曾负责一个大型新闻网站的设计，当客户拿着将近五十页厚的一本设计要求报告时，我发现有四十页的内容对程序开发来说都是重复的，而在其中一页的角落却画了个”搜索其他网站相关新闻”的按钮，并且没有做任何说明，仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作，客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发，通过协商，客人同意了修改成站内搜索的引擎。

三：利用自然的语言描述项目模型

    在业务员与客户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然客户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对客户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。

    请比较以下两份关于需求的描述，

    ”用户在访问首页的时候可以在点击’客户通道’按钮，弹出填写’用户名’和’密码’的窗口，输入正确后在新窗口打开客户通道的首页，在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表 ”

    ”站点分为公开和加密两种状态，通过身份验证机制使特有的用户可以访问到加密信息，并提供不同于普通用户的功能。”

    前段描述我们就很容易想象的出来设计完成的网站是什么样子，而后一段的描述可能会做出无数不同的版本，造成对需求理解的歧意。

四：利用示意图和图表将用户的需求表现出来。

    需求分析无论文字上怎么样表述都还是抽象的，对客户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。

    制作示意图可以有很多种方式，用PowerPoint或Visio制作流程示意，用Html文档制作界面示意都是可行的，最简单利用画图和Word表格方式也完全可以，关键是利用示意图将客户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，换言之，就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时客户更容易地参与到项目的开发过程，保证项目往正确的方向进行。

    在RUP中有这样的描述：

“利用电影、卡通、图片、表格和动画片等制作示意图开始，告诉我们用户是谁，要发生什么事情，如何发生。

• 以用户友好的方式帮助收集并改进用户需求。
• 鼓励更有创造性、更加创新的设计解决方案。
• 鼓励团队复审，并避免所有人都不希望出现的特征。
• 确保以可理解、直观的方式实施特征。
• 使访谈过程变得轻松，避免出现访谈没有结果的现象。

    简单地说，制作示意图就是使用工具向用户 (主角) 说明（有时是动画演示）系统如何适应组织的需要，并表明系统将如何运转。协调员将初始示意板展示给小组，小组成员提供意见。之后，在举办研讨班期间，示意板也进行”实时”演进。所以，您需要一种可以轻松更改示意板的画图工具。为了避免分散注意力，一般最好使用简单的工具，比如图表、白板或
PowerPoint。”

五：什么人要看需求分析报告

    项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。

    我们经常会遇到业务人员辛辛苦苦谈下来的项目，对开发人员来说却是难以实现的，而技术人员设计的产品却常常得不到客户的认可，甚至发生纠纷，因此参与项目开发的人员都应该对这份需求有统一清晰的认识，并根据自己的工作对需求提出意见，通过与客户的沟通修订，最终确定项目实现的目标。

    例如：

• 项目经理通过需求分析才能组建所需要的团队包括配置工作环境，制定开发周期。
• 开发周期的限制和功能上的要求可能会影响到程序员采用什么样的语言和工具进行编写；
• 操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度；
• 界面设计人员根据项目的性质和定位确定表现方式。
• 测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测；

    通过下表，我们可以看的出不同角色根据需求的变更所进行的工作流程：

六：建立需求变更日志，制作新版本的需求分析报告

    尽管我们费了许多功夫在需求分析进行了最大可能的努力，但几乎可以肯定的是，这份需求分析在开发过程中一定会发生变化，也许是出自客户的遗漏，也可能是在开发过程中被激发出来的，这种变更有时是如此的频繁和琐碎，以至于往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。

    在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。

    在新版本的需求分析中，将变更多部分用特殊方式表明出来，并在日志中记录变更多重的明细。

    关于需求分析和变更管理可以参照下图示意：

七：本阶段重点工作角色

    在需求分析和变更管理的过程中，工作量最大的角色为客户代表、业务员和项目经理。

    客户代表提出需求，业务员帮助整理和分析，项目经理对整个项目进行评估。

    在实际工作中，很多项目失败的起因都和需求分析有关。 客户代表和业务员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行参谋。

    为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，帮助客户代表和业务员更好的完成任务。
以下提供一份需求管理计划的模板可作为参考：

八：总结

    根据笔者的经验，要尽快做好需求分析掌握以下要点，也许能事半功倍：
 

• 仔细聆听，罗列客户的所有要求；
• 将需求进行分析，确认可操作的系统模型；
• 利用最自然的语言将系统进行描述，使每个开发人员不会产生歧意；
• 迅速确定网站的用户角色；

  比如访客、会员、重要客户、前台管理员、网站管理员、业务员等；

• 分析确定每个角色的权限及可操作的功能；

  比如会员可以查看特别信息、修改个人信息、退出登陆等；

  前台管理员能够登录管理系统，能够发布编辑修改信息，能够审查会员资格等；

  网站管理员可以更改栏目、修改网站界面等；

• 制作流程图和示意图将需求表现出来；
• 让客户参与到示意图的设计中，及时正确的反应出需求变更。
• 制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
• 通过需求《管理计划书》使每个参与人员看到共同的努力目标。

附注：本文图表引用于RUP2000中文版。

admin 网站项目开发 需求分析, 项目流程