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

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

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

【内容摘要】1引子太多了！终于签下合同–>得到了“正式”的客户提供的“需求书”的几片纸–>凭借自己的理解立即投入开发–>“木已成舟”，生米终于熬成粥–>用户拒绝接受？–>艰难地修改，反复修改，开发人员厌倦了，而用户对系统用之无味，弃之可惜，遂成鸡肋。– ……
—————————————————————————–

1 引子
              
 太多了！终于签下合同–>得到了“正式”的客户提供的“需求书”的几片纸–>凭借自己的理解立即投入开发–>“木已成舟”，生米终于熬成粥–>用户拒绝接受？–>艰难地修改，反复修改，开发人员厌倦了，而用户对系统用之无味，弃之可惜，遂成鸡肋。–>由此后期收款遥遥无期，软件公司不再和用户保持沟通–>互相埋怨，扯皮由此而生。或者，一个项目拆成为多期，从而收取一部分款项，而很多的开发都作废。这样的案例真是何其多也！
 究其主要原因，与其说是没有搞定关键客户，或者项目管理不当，不如说是没有帮助客户解决其问题，对客户真正的需求研究不够。实际上，原型方法是解决此类问题、确保项目成功的最佳途径。
 
 我在写此文的同时，也试图寻找资料，不知道是本就没有，还是自己所不幸而未找到。看来原型并没有明确的标准，而目前不同软件公司的理解和做法各不相同也就不奇怪了。但从软件过程的角度来考察，原型法仍有着通用的优化的做法。本文试图从作者的实践经验出发，对原型方法进行思考与探讨。
 另外，本文是发散型的，在研究原型的同时，也讨论了原型相关的内容。原型本质上有些象是抛砖引玉，而本文也旨在抛砖引玉，但无意于一概地论定什么。              
2 什么是原型             
2.1 原型的定义
              
 原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。
 
 2.2 原型的主要价值
 
 原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，原型通过充分和客户交流，还可以提高客户满意度。
 
 2.3 基本要求
 
 对原型的基本要求包括：
 
 * 体现主要的功能；
 * 提供基本的界面风格；
 * 展示比较模糊的部分，以便于确认或进一步明确，防患于未然。
 * 原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
 
 2.4 处理方法
 
 原型的处理方法基本上有2种不同类型，即抛弃型和演化型（不同的软件工程书籍称发不同，实质意义则类似）。可以抛弃原型，在取得的明确需求基础上重新开始设计与开发；也可在原型的基础上继续开发。一般小项目不采用抛弃型原型，否则成本和代价似乎会偏高。
 
 2.5 表达工具
 
 原型的表达工具可以有很多，如果是演化型的原型，当然优先选用软件本身的开发工具。否则还可以应用各种快速显示的工具，例如，HTML，Powerpoint等等，只要能够充分而形象地表达就可以了。
 根据笔者的经验，在原型系统中，可以采用一些与常规不同的做法，例如，可以在界面上比较显著的地方写明当前模块或界面的主要目的，由哪些角色操作，能解决其什么问题。这么做可以使得用户或开发团队成员一开始就有非常清楚的概念；又如，对于决策分析，你可以直接把一些分析结果画成图，并且配上一些文字说明，这样可以避免输入大量初始数据，等等。              
3 原型在软件过程的地位
              
 软件的根本目的是实现用户的需求，提供用户日常使用，解决用户工作中有所不便的问题，提高其工作效率，改进质量，加强管理控制，最终直接或间接地提高其效益。因此软件开发本质上就是需求的处理和实现，而软件原型对需求确定来说具有非常重要的意义。原型方法包括2个基本过程，即原型制作和原型评价。              
如果从需求角度看软件过程，我们不妨可以把软件过程这样划分：
                
                 3.1 需求收集和分析
                
                 搜集需求得到需求说明书，了解软件要做什么，做成什么样，解决用户什么问题。
 这时候软件公司以书面文档方式提出，例如需求问询表等。
 
 3.2 提供原型并进行评价
 
 制定原型开发计划，根据用户需求及不确定的高风险部分进行原型开发，在内部进行原型评价，请客户进行原型评价，以保证确实反映了用户的真正想法。
 
 3.3 实现需求
 
 当前的软件开发过程常常采用迭代方式进行开发，逐步求精，以降低风险和成本。对迭代的次数，每次迭代的里程碑，要实现的目标，及可提交的成果必须有可验证的清晰的计划。项目管理是一种艺术，迭代规划及里程碑定义都是一种挑战、一种艺术，但项目管理不在本文讨论范围。
 
 3.4 需求变更
 
 需求变更是正常的，也是难免的，应允许用户和开发团队自身对需求进行变更。变更处理的关键在于跟踪和控制，如何使产生的影响应得到控制，这属于配置管理的内容，也不在本文讨论范围。
 
 原型在软件过程中的定位如下图所示：              

                
                
                
 图1 软件原型的定位              
实际上我们可以把原型看得更为广义一些。任何用户或者内部演示的材料，都可以看作为原型。例如，如果你的产品是某种通用的或者行业解决方案，虽然你其实还没有产品，但先做出一个原型，再加一个漂亮的白皮书，就可以在市场上进行预销售了。
                
 对于抛弃型和演化型原型来说，也不是绝对的。演化型原型中必然会不断抛弃一些内容，而抛弃型原型，尽管在完成历史使命后不再使用，但很多思想以及部分设计还是可以继承的。              
4 原型方法的一般过程             
基于原型方法在整个需求过程中的地位，我们需要把原型法和需求处理放在一起进行讨论。采用原型法的一般过程如下图所示：              
             
图2：原型法的处理过程              
在上图中已经清楚地描述了原型的处理过程，值得一提的是，原型不仅用于给用户或者最终用户进行评议，同时完全可以在公司内部组织评议，看看我们周围吧，多数程序员对技术的兴趣远远高于对需求的兴趣，因此其对系统的理解并不会比市场人员或者项目经理理解的深多少。这里的公司内部人员角色可以包括很多，系统分析员/程序员自身、项目经理、部门经理、用户代表、领域专家、测试人员等等，不同的角色往往会在其不同立场对系统提出中肯的意见来。
 另外值得注意的是界面设计的引入。我们认为将界面风格在原型阶段即进行基本确定是一种优化的做法，因为软件前期对界面的确定可以避免后期开发时对界面进行统一调整所带来的不必要的成本花费，良好的界面也可以使客户增加对系统的好感，当然，但愿用户不要只是欣赏界面而忽略了他们对系统功能的思考。要知道，如果仅仅是让用户看到美观的界面，那么整个原型几乎是白做了。
 
 
 5 使用原型方法的相关问题探讨             
5.1 为什么要采用原型法？
                  
               原型对一个项目取得成功具有重要的意义。俗话说：隔行如隔山，实际上软件公司很难保证其制作的软件正好就是用户所需要的，用户也很难一次性把其真实的要求完全提交，开始阶段提出的往往只是对系统的期望，和比较模糊的设想而已。而原型系统为用户提供了一个靶子，看着原型系统，用户往往就能进一步提出他们的真正想法。显然软件公司明确用户需求的最佳方式就是为用户提供原型并由用户进行评价。
 也许，跳过原型可以节省时间和前期成本，但你应该注意到，跳过原型的话，后期变更的成本会明显增加。
 
 5.2 为什么在需求说明书之外需要原型？
 
 1）眼见为实，文字具有歧义性，不同的人理解都不相同；
 2）最终用户往往在看到一套可运行的系统的基础上，才可能提出其真实的意见，如果到最终提交时才看到这样的系统就为时太晚。这也是以前无数软件开发留下的教训；
 3）便于发现问题，及时纠正；
 4）便于进一步展开，并取得用户的细节需求；
 5）体现原型的其它功能：便于公司内部如经理、市场部等对软件提出意见，便于开发人员对整个产品达成统一认识，等等。对内部人员来说，同样地，一套形象的原型也远胜过一堆专业术语文字；也就是说，原型对软件公司内部也十分重要。这些评价工作无形之中改进了项目质量。              
5.3 原型方法有什么风险？
              
 任何方法都是有利有弊，在我们可以探讨一下原型方法可能存在的风险。以下是一般软件公司所担心的风险：需要付出前期进度和人力成本；由于程序员对问题的不了解而效率低下，受客户牵制而在原型上反复修改；因为仓促设计而做不利于进一步在其基础上继续开发；由于过早展示原型给客户，使得客户可能提高其期望值，并提出更多离谱的要求，等等。
 
 值得一提的是原型方法的主要价值之一就是尽早揭示软件中可能存在的风险及不确定因素，尤其是关于用户需求一致性方面的风险。              
5.4 原型方法和其它方法或过程的关系如何，是否一致？
              
 生命周期法中并不包括原型，或者说没有明确提供原型的概念和定义。原型可以认为是需求分析中的一个子部分。另外，应该说原型方法是对生命周期法的有益补充和完善。
 RUP中是最优化的统一软件过程，但RUP中似乎没有提到原型，RUP的核心过程是在迭代中精化。我个人的见解是，原型非常类似于第一次迭代的过程和结果。实际上，如果把原型看作为第一轮交付的成果，那么原型的很多不利之处，诸如花费前期成本等等，这些担心都将变得不复存在。
 XP方法对原型非常推崇，这是因为XP方法非常强调需求的重要性，甚至要求客户参与开发过程。但原型方法和XP也有区别。XP是分批交付，先做一个几个功能点的版本，完成后再每个开发周期往上面加其它功能点，而原型法一般要求做出比较完整，能覆盖主要功能点的粗略的版本。XP方法仁者见仁，智者见智，不一而举。              
5.5 如何避免项目团队做原型的时候出现部分人员闲置？
              
 在项目管理中，对人力资源的调配应和项目进展相匹配。实际上在用户接触到原型制作的同时，可以进行项目计划、架构设计、技术培训以及技术难点攻关等等。
 如果从广义上理解原型的话，架构设计者甚至可以设计出一种用户开发团队使用的所谓框架原型，包含了主要的设计成分、模板和示例。
 比较理想的结果是，当原型完成后，需求分析、架构设计和界面风格设计都趋于完成，从这一点可以看到，原型方法可以作为快速软件开发的重要手段。              
5.6 如果避免项目在原型上停滞不前？
              
 应使用有经验的开发人员，避免因为程序员不熟悉业务而延误进度；不要在界面设计上犹豫不决而占据时间；如果用户对原型提出了很多意见，其中部分比较明确的意见可以在开发过程中进行实现；和客户的交流应该简洁明了，而不是似是而非；另外，原型方法在项目过程中占据的时间应该在项目计划中保留出来，而不仅仅是隐含在需求调研与分析的一个部分。              
5.7 如何避免用户看了原型后漫无边际地提要求？
                
 首先，应该充分尊重客户，想想其它行业的服务质量吧。有没有听说过这样的说法，项目管理也是客户满意度的管理；软件是一种对客户的关怀，等等。确实，客户提出的思路可能和你已经形成的思路不同，一下子打乱了你的思路，也许项目经理并不介意，但这确是让设计者特别心烦的事情。如果确有把握，或者你可以不做到原型中去。有时候，即使原型很完美，用户也会额外地提出一些意见，这也是人之常情。但不管怎样，你不能认为用户根本不懂软件，让他们到时用就行了，抱这样想法的多半会付出代价。
 
 其次应该进行坦诚协商，多数用户其实都是通情达理的。如果你在签订合同时答应满足任何要求，而此时又无法忍受用户的要求，那么孰是孰非应是题外之意了。一般来说，比较合理的做法可以通过增加费用、延长进度或者把需求实现分阶段来提交，以保持工作的延续性。对有些软件，尤其是信息管理系统来说，客户的实施时间其实并不是主要的，客户最需要的不是及时，而是合用。
 
 其实，客户有着很多种类型，确实，个别客户会参考同类产品来提要求，极个别用户并不真正懂得计算机技术而对技术路线、技术手段等提出其意见，等等。但我们为什么还可以反过来想一下，如果是等到软件全部提交的时候，这部分用户仍有会提出同样的意见。提早暴露并解决分歧，对双方睹是有利的。如果软件公司明知可能存在矛盾，仍然先做好，然后等到用户提出反对后，再提出补充收费，如果喜欢，也无话可说。
 
 总之，原型应本着对软件需求的基本理解来做，这样才能预防不一致性的发生。尤其应该针对不清楚的地方制作原型，从而尽量暴露问题，引发用户的联想，不能回避问题，掩盖问题（以免用户提出太多的想法），很多问题虽然一时掩盖了，但最终还是要发生的。              
5.8 如何避免在原型基础上继续开发时的可维护性降低？
              
 问题是这样的，制作原型时常希望快速提供原型，往往不及对软件结构或者数据库进行细致设计。所以在此基础上继续设计和开发的话，有必要在开发前先进行调整。同时，在设计原型前就有必要确定，该原型是要抛弃的，还是要演化要继承的。对于要演化的原型，其设计不能过于粗略，显然这直接影响到今后的开发成本。              
6 小结
              
 原型方法是可视化的方法，已成为快速软件开发常用的手段。软件公司或部门一旦得到了原型方法的回报，就会坚持使用。原型不是绝对必要，但非常有意义。
本贴来自天极网群乐社区–http://q.yesky.com/group/review-17600505.html

admin 产品项目流程和规范 UML, 产品原型, 产品经理

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

一直在用visio做交互原型和画pageflow的同事建议了解一下Axure RP 5。

http://www.3ddown.com/soft/34.htm 下载

http://www.axure.com/downloadBeta.aspx 5.5测试版下载

*介绍*

　　互联网行业产品经理的一项重要工作，就是进行产品原型设计(Prototype

Design)。而产品原型设计最基础的工作，就是结合批注、大量的说明以及流程图

画框架图wireframe，将自己的产品原型完整而准确的表述给 UI、UE、程序工程

师，市场人员，并通过沟通会议，反复修改prototype 直至最终确认，开始投入执

行。

　　进行产品原型设计的软件工具也有很多种，所介绍的Axure RP，是taobao、

dangdang等国内大型网络公司的团队在推广使用的原型设计软件。同时，此软件也

在产品经理圈子中广为流传。之所以Axure RP得到了大家的认同和推广，正是因为

其简便的操作和使用，符合了产品经理、交互设计师们的需求。

　　在正式谈Axure RP之前，我们先来看看做产品原型设计，现在大致有哪些工具

可以使用，而他们的利弊何在。

*　　纸笔：*简单易得，上手难度为零。有力于瞬间创意的产生与记录，有力于对

文档即时的讨论与修改。但是保真度不高，难以表述页面流程，更难以表述交互信

息与程序需求细节。

*　　Word：*上手难度普通。可以画wireframe，能够画页面流程，能够使用批注

与文字说明。但是对交互表达不好，也不利于演示。

*　　PPT：*上手难度普通。易于画框架图，易于做批注，也可以表达交互流程，

也擅长演示。但是不利于大篇幅的文档表达。

*　　Visio：*功能相对比较复杂。善于画流程图，框架图。不利于批注与大篇幅

的文字说明。同样不利于交互的表达与演示。

*　　Photshop/fireworks：*操作难度相对较大，易于画框架图、流程图。不利于

表达交互设计，不擅长文字说明与批注。

*　　Dreamweave：*操作难度大，需要基础的html知识。易于画框架图、流程图、

表达交互设计。不擅长文字说明与批注。

　　以上这些工具，都是产品经理经常会使用到的，但是从根本上来说，这些工具

都不是做prototype design的专门利器，需要根据产品开发不同的目的，不同的开

发阶段，选择不同的工具搭配使用，才能达到表达、沟通的目的。

　　比如使用纸笔，更适合在产品创意阶段使用，可以快速记录闪电般的思路和灵

感；也可以在即时讨论沟通时使用，通过图形快速表达自己的产品思路，及时的画

出来，是再好不过的方法。而word则适合在用文字详细表达产品，对产品进行细节

说明时使用，图片结合文字的排版，是word最擅长的工作。而 ppt自然是演示时更

好。visio则可以适用于各种流程图、关系图的表达，更可通过画use case 获取用

户需求。PS/FW是图片处理的工具，DW则是所见即所得的网页开发软件，这些是设

计师的看家本领，对于普通的产品经理来说，需要耗费太多的精力去掌握。

　　其实每件工具，每个软件，在创造它的初期，软件设计师们都给它赋予了性

格、气质。因为每个工具的产生，都是为了满足人类的某一方面需求。比如锄头是

锄土的，起子是起螺丝的，电熨斗是烫衣服的。但是不同的工具都有自己的工作领

域，在其他领域它并不擅长。而以上的软件在创造的初期，并非为了帮助产品经

理、ue完成产品原型设计，因此他们都不能在prototype design 这件工作上得心

应手。而Axure RP正是在互联网产品大张其道的前提下，为满足prototype design

创建的需求，应运而生。

　　Axure RP 能帮助网站需求设计者，快捷而简便的创建基于目录组织的原型文

档、功能说明、交互界面以及带注释的wireframe网页，并可自动生成用于演示的

网页文件和word文档，以提供演示与开发。

　　Axure RP 的特点是：

    * 快速创建带注释的wireframe文件，并可根据所设置的时间周期，软件自动

      保存文档，确保文件安全。

    * 在不写任何一条html与javascript语句的情况下，通过创建的文档以及相关

      条件和注释，一键生成html prototype演示。

    * 根据设计稿，一键生成一致而专业的word版本的原型设计文档。

　　说到这里相信很多人已经激起了兴趣，了解一下软件短短的历史，创造这一软

件的公司—Axure Software Solutions, Inc.该公司创建于2002年五月，Axure RP

是这一软件公司的旗舰产品，2003年一月Axure RP第一版本上线发表，至今已经正

式发行到了第四个版本，Axure 5.5版本beta版本已经正式提供下载试用。

　　分几个步骤对Axure的认识，

　　一、 界面与功能

　　二、 工具栏

　　三、 站点地图

　　四、 组件与使用方法

　　五、 复用模板与使用

　　六、 交互功能与注释

admin 产品项目流程和规范, 提高个人效率的软件或服务 产品原型设计, 产品经理

by Dan Brown on 2002/07/01 | [26 Comments]

In 1998, I was working for USWeb/CKS, perhaps the largest Internet consulting firm at the time. Information architecture was new to the organization, and I was the only one in the Washington, D.C. office who had the chutzpah to call himself an IA. At that point, we hired a new creative director, and together he and I formalized the user experience group in our office. As part of that process, and based on our own bad experiences, he told me that I needed to find a way to take design out of information architecture.

He was referring, of course, to wireframes, though at the time we called them page schematics. We’d been burned too many times, and it started creating a rift between the visual designers and me. A wireframe, as you probably know, describes the contents of a web page by illustrating a mock layout. Usually wireframes are rendered in some kind of drawing program, like Visio or Illustrator, but can also appear as bitmaps or even HTML.

It would have been easy for me to resent the directive. After all, I’m an IA, that’s what we do! But I could see the value in his suggestion, particularly since I’d experienced conflict on projects where I’d trod a bit too heavily on designers’ toes.

The conflict arose after clients had seen the wireframes. The layout, even explicitly caveated, would set their expectations, and they did not appreciate screen designs that strayed too far from them, no matter how carefully crafted. Clients also struggled to talk about information priorities, taxonomies, and functionality. Placing these concepts in a layout made them more accessible, but our conversations were too tactical, and their feedback had more to do with design than with structure.

We tried using wireframes as a strictly internal tool: no client viewing allowed. But as much as a wireframe helped designers visualize the functionality and interaction of the site, it cramped their style. Designers who stuck close to the wireframes did not exercise their creativity, and all our sites started to look the same.

These are the two main risks associated with wireframes: client expectations and designer innovation. (There are others. See below.) While strategies exist to mitigate these risks, they are not 100% avoidable. When the creative director asked me to “take design out of IA,” I had to make a choice:

I could pursue risk mitigation strategies, learning how to set client expectations better and work with designers to avoid compromising their creativity.
OR

I could develop a different approach to documenting information architecture, one that would avoid these issues completely. Devising a way to communicate issues that sit squarely in my court means no more conflict with designers over client expectations or layout. Such an approach would also force clients (and designers for that matter) to talk about content, priorities, and functionality —the issues we needed to address in early stages of the project.

The first option felt desperate, as if I were the little boy trying to plug the dam with no end in sight to the number of leaks. (In college, I took a class in social ethics. The professor, Gary Comstock, once said that if people are fighting over pie, make a bigger pie.)

It was on the redesign of USAirways.com in 1999 that I decided to try a different approach. After building a site map, which described the relationships between the web pages, I created the first “page description diagram” —a bigger pie, as it were.

In a page description diagram, the content areas of the page are described in prose, as in a functional specification. The content area descriptions are arranged on the page in priority order. Typically, I will define the horizontal axis of the diagram as the page priority. Thus, content areas described on the left side of the page are higher priority than those on the right side of the page.

Page Description Diagram Mock-Up

Page Description Diagram Mock-Up with Component Layouts. Click to open a high fidelity PDF of diagram.

With this approach, the diagram represented the two main issues: priority and content. I found that I could include layouts of individual content areas to show, for example, how the “check flight status” form might look. These mini-layouts helped our client visualize the interactivity, but did not lock the designer into any particular approach. Our conversations with the client focused on the nature of the content and functionality and the relative priority of the page contents.

On this particular project, the art director appreciated the approach. He found he could focus more on creating a synergy between the brand and the functionality, rather than being forced into wrapping colors around a predetermined layout. At the risk of speculating on his thoughts too much, I wonder if he had to spend less effort than he would have with a wireframe, which predisposed him to a particular layout.

The page description diagram, by demonstrating priorities and providing a context for the content and functionality, gives visual designers the information they need to create an effective layout. On any given web page, a piece of information can have more or less visual weight depending on the use of color, contrast, typography, and position. But these are the tools of a visual designer, the fundamentals of graphic design, and no business of the information architect.

If a project requires an information architect, the scale of information must be vast. Without a person who understands the nature of the information, other people on the team would spend their valuable time trying to get their heads around it, preventing them from focusing on their own tasks. Information architects who have to worry about layout are distracted from their tasks: defining functionality, content, and structure.

Ultimately, designers are paid because they are good at thinking about visual relationships. Presumably, an information architect focuses on relationships among information, categories, and content, not among shapes, color, and contrast. The page description diagram is a tool to allow designers and information architects to stay comfortably within their own realms without compromising communication.

(This idea, of course, reopens the “defining the damn thing” discussion. Perhaps some definitions of information architecture include page layout, but as a creative director who must consider the interests of both architects and designers, I need to draw a discrete line between the two.)

Whenever I show a page description diagram to designers, they love it. It provides more information without compromising their processes. Information architects, on the other hand, have mixed responses. Some latch onto the concept, eager for some relief from common project problems. Others do not see value in the approach, perhaps because they have not faced the same issues, or perhaps because they have associated their craft with wireframes, they cannot conceive of one without the other.

Page description diagrams do not have to replace wireframes. Indeed, if we are to grow as a craft, we must find additional means for communicating information architecture ideas. Just as laptop computers and desktop computers do similar things but are used in different situations, wireframes and page description diagrams can also peacefully coexist as useful information architecture tools.

admin 产品项目流程和规范, 提高个人效率的软件或服务 Wireframe, 产品经理

从事网站建置工作的人想必一定对Wireframe(以下简称WF) 这个字不陌生。

WF简单来说就是网站页面的蓝图，主要的功能IA是让用来(信息架构分析人员，时常会是网站必须企划兼任的角色) 与网站置作团队的其它成员沟通想法的工具。

WF的表现形式有很多种，可以精细也作出与真实页面相近的WF，也可以用很简略方式表达页面中应具备的元素，对麦斯而言，WF是一种沟通的工具，因此最重要的是能够让看WF的人了解你的想法，要用那种形式来表现，应该视当时的需要，以及合作的对象。

麦斯有时会被要求制作一些十分接近真实页面的WF，精细形式的WF表面上看来似乎会让工作流程变得顺利，但实际上，在看不到的地方却有许多潜在的危机。

l .首先，WF是用来沟通IA的工具，但一个拟真的WF常会让讨论的焦点转移到页面的视觉设计，然而那是创意人员的工作而不是IA人员的专业。因此，当一份拟真的WF出现后，常会出现两种情形：
(1)创意人员觉得WF 阻碍了他们发挥的空间。
(2)上面那点是对比较勤劳的人来说，至于比较懒的，就会直接把这个WF加上图片颜色做出网页。

2.再者，也许因为拟真的WF容易让非专业的人也看懂网页设计，因此这样的wf常被拿去与客户沟通，这样的作法也许对能让客户看到一些实质的产出，因而签下合约，但却是非常不正确的作法。
(1) 让客户看到拟真的WF会让他对页面中会出现什么产生不当的期待。我们知道WF只是页面的IA架构，最后完成的网站通常会与wf有许多不同之处，如果客户在一开始就看到拟真的WF，而之后完成的网站却与他心中的期待不同时，客户常会认为一开始所看到的wf是一个不实广告，这样一来会为自已制造许多不必要的麻烦。
(2)如果客户太早看到拟真的WF，那么他的会将焦点放在接口视觉设计上，这时从客户口中听到的就会是：我要这个在这里，这个页面中应该有这个功能，还有，某个图应该要出现在页面上。
但是，在未进入实际的制做前，我们所应该了解的是到底有那些信息是重要的? 这些信息之间又有那些关系? 通常客户对这方面的想法会是散乱的，IA人员需要有些技巧才能让了解客户真正的想法，然而过早秀出拟真的WF只会让客户的想法失焦，这样一来我们就更无法得到设计IA时所需要的信息。

Dan Brown (http://www.boxesandarrows.com/archives/where_the_wireframes_are_special_deliverable_3.php) 提出了一个用Description Diagram 来代替WF的沟通方式，这种方式感觉上似乎更能让创意与客户focus在IA的设计上进行讨论。

与其用WF来与创意及客户讨论网站的信息架构，Dan Brown则改用以内容描述为主的Description Diagram，这种方式是将网站可能会有的内容以文字描述的方式，依重要性不同列在一份文件上来进行讨论，这样一来，文件中少了视觉的要素，因此讨论的内容就可以专注在IA议题上，较可能针对内容类形与重要性与客户进行讨论。

Dan Brown在其文章中只谈到这两个例子，麦斯认为，如果能先以这样的Description Diagram来沟通想法，那么IA人员接下来，只需将网站中会出现的各个分页标定出来，然后将每一页中将出现的内容以描述的方式说明，剩下的就可以让创意自由发挥了。

网站的建构通常需要的是team work，而这种team就像是一个Jazz Band，其中每个人都有不同的专长，要让team的效能发挥到淋漓尽致，就要让不同才能的人都能在自已的领域尽情的发挥，彼此之间能够多一点互补，少一点干扰，而以Description Diagram进行沟通最大的好处正在于此。

再进一步，可以依内容的不同放入一些初步的功能设计，这些功能设计在视觉上都以灰阶的方式呈现，如此一来，对创意人员而言，既能达到沟通内容的目的，又能保有很大的创意空间。

admin 产品项目流程和规范 Wireframe, 产品经理

网站项目管理（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 网站项目开发 产品经理, 需求分析, 项目流程