网站项目管理分析.doc_第1页
网站项目管理分析.doc_第2页
网站项目管理分析.doc_第3页
网站项目管理分析.doc_第4页
网站项目管理分析.doc_第5页
已阅读5页,还剩21页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

网站项目管理分析第一章 前言随着技术的不断发展和用户对网站功能性的需求不断提高,如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现,与前几年网站设计由一两名网页设计师自由的创作相比,网站项目的设计和开发越来越像一个软件工程,也越来越复杂,网站项目的设计和开发进入了需要强调流程和分工的时代,建立规范的、有效的、健壮的开发机制,才能适应用户不断变化的需要,达到预期的计划目标。网站项目管理(WPM)的含义为WebbasedProjectManagement,即以Web应用程序为主要表现方式的架构来进行的项目设计及管理,这样的架构中包含了浏览器、网络和Web服务器等关键主体,主要体现在网站设计、以浏览器为客户端的Web应用程序开发(例如信息类网站、网上商店、虚拟邮局、客户关系管理)等项目管理中。在本文中,作者将网站项目管理(WPM)与软件工程的统一过程管理(RUP)进行参照比较,并结合实际工作经验,力求将网站工程管理(WPM)的角色、分工、流程进行完整的阐述,使网站项目管理逐渐走向规范化。网站项目管理可以分为以下七个阶段进行控制:1、需求分析及变更管理2、项目模型及业务流程分析3、系统分析及软件建模4、界面设计、交互设计及程序开发5、系统测试和文档编写6、客户培训、技术支持和售后服务需要说明的是,这些阶段虽然具有一定的延续性,但是并非完全隔断的,例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的,许多工作时交叉进行或同时进行的。第二章 需求分析及变更管理业务员与客户进行的沟通,撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心,而不是为技术而迁就需求。2.1 让客户畅所欲言,罗列出所有的需求让用户将所有的想法尽可能的阐述清楚,并把所有的要求罗列出来,不要遗漏。这时候不应该害怕勾引起客户的潜在需求而增加设计开发的工作量,从而被今后客户无止境的变更拖入泥潭,直接明白地跟客户把问题和要求一条条地列出来,把条理、归纳、分析先都扔到一边去,将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。很明显,假如客户的需求做的都不完整,随时可能会产生意想之外的变更,甚至这个变更会破坏已经做的模型及结构,那么这个项目从开始就注定了会失败。比如站点所有的功能都实现了,本地测试起来也没有什么问题了,但是你却不知道客户的系统是要承受每天100万独立IP的访问,而你原来想当然的以为了不起就是1万独立IP访问的访问流量,稍微有经验的开发人员都会明白这样的设计是个灾难,无论是应用服务器、数据库还是程序全部要重新开发!2.2 透过现象分析潜在的需求很多情况下客户并非专业人士,在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关,这需要我们去为客户进行分析、归纳和整理,尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。客户往往对需求的概念是非常模糊的,大多时候给出的需求都是笼统而且尺度难以控制的,这就要求业务人员在倾听了客户的详细说明以后,帮助客户进行整理和分析,同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。比如在为客户设计办公自动化系统的时候,也许就要为客户预留将来与他们的业务单位进行交互的通道;在设计邮件系统的时候要考虑可能会需要广告管理服务器;设计网络电子商店时今后增加库存产品进销存统计分析等等;限于时间财力的考虑,客户通常能够接受分阶段实施的开发过程,在需求分析时,提早为客户设想到今后的需求变更除了使项目开发更加顺利以外,也为今后业务的进一步深入打下了更好的基础。作者曾负责一个大型新闻网站的设计,当客户拿着将近五十页厚的一本设计要求报告时,我发现有四十页的内容对程序开发来说都是重复的,而在其中一页的角落却画了个搜索其他网站相关新闻的按钮,并且没有做任何说明,仅仅这10个字所完成的工作量完全顶的上其他整整四十页重复赘述所做的工作,客户完全不知道这个要求引发的问题实际就是一个搜索引擎的开发,通过协商,客人同意了修改成站内搜索的引擎。2.3 利用自然的语言描述项目模型在业务员与客户进行沟通和调查时撰写的需求分析,尽可能用自然的语言进行描述,虽然客户的水平和资历有所不同,但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义,不至于在理解上产生偏差。对客户而言,这样的模型描述最接近真实,容易参与修订,并能以此为测试和验收的依据。比较以下两份关于需求的描述:用户在访问首页的时候可以在点击客户通道按钮,弹出填写用户名和密码的窗口,输入正确后在新窗口打开客户通道的首页,在该页显示所有可操作的功能的导航条和最新的导读新闻链接列表站点分为公开和加密两种状态,通过身份验证机制使特有的用户可以访问到加密信息,并提供不同于普通用户的功能。前段描述我们就很容易想象的出来设计完成的网站是什么样子,而后一段的描述可能会做出无数不同的版本,造成对需求理解的歧意。2.4 利用示意图和图表将用户的需求表现出来需求分析无论文字上怎么样表述都还是抽象的,对客户而言理解毕竟是困难的,将基本确定的需求制作出示意图是最直观有效的。制作示意图可以有很多种方式,用PowerPoint制作流程示意或用Html文档制作界面示意都是可行的,最简单利用画图和Word表格方式也完全可以,关键是利用示意图将客户的需求和即将开始设计的系统体现起来,在进行系统分析和程序开发之前,双方对今后要完成的产品就能够有直观的认识,换言之,就是在产品还没有真正进入开发阶段的时候,双方就对工作的结果达成统一的意见,这将大大地减轻需求变更所带来的困扰,同时客户更容易地参与到项目的开发过程,保证项目往正确的方向进行。在RUP中有这样的描述:利用电影、卡通、图片、表格和动画片等制作示意图开始,告诉我们用户是谁,要发生什么事情,如何发生。简单地说,制作示意图就是使用工具向用户(主角)说明(有时是动画演示)系统如何适应组织的需要,并表明系统将如何运转,协调员将初始示意板展示给小组,小组成员提供意见之后,在举办研讨班期间,示意板也进行实时演进。所以,需要一种可以轻松更改示意板的画图工具。为了避免分散注意力,一般最好使用简单的工具,比如图表、白板或PowerPoint。2.5 什么人要看需求分析报告项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括客户代表都应该看需求分析,并进行共同的讨论,达成一致的意见。我们经常会遇到业务人员辛辛苦苦谈下来的项目,对开发人员来说却是难以实现的,而技术人员设计的产品却常常得不到客户的认可,甚至发生纠纷,因此参与项目开发的人员都应该对这份需求有统一清晰的认识,并根据自己的工作对需求提出意见,通过与客户的沟通修订,最终确定项目实现的目标。例如:项目经理通过需求分析才能组建所需要的团队包括配置工作环境,制定开发周期;开发周期的限制和功能的要求可能会影响到程序员采用什么样的语言和工具进行编写;操作用户的技能水平将影响到交互设计师进行前台设计时做到什么样的精度;界面设计人员根据项目的性质和定位确定表现方式;测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测;通过下表,我们可以看的出不同角色根据需求的变更所进行的工作流程:2.6 建立需求变更日志,制作新版本的需求分析报告尽管我们费了许多功夫在需求分析进行了最大可能的努力,但几乎可以肯定的是,这份需求分析在开发过程中一定会发生变化,也许是出自客户的遗漏,也可能是在开发过程中被激发出来的,这种变更有时是如此的频繁和琐碎,以至于往往不能将变更及时反馈到项目的各个角色中,那么做好需求变更日志就显得非常重要。在需求分析后面附上变更日志,并将修改后的需求分析制作成新版本,保留每次更改过的版本,而不是覆盖,这样就比较容易地跟踪到需求变更过程中所带来的工作调整。在新版本的需求分析中,将变更多部分用特殊方式表明出来,并在日志中记录变更多重的明细。关于需求分析和变更管理可以参照下图示意:2.7 本阶段重点工作角色在需求分析和变更管理的过程中,工作量最大的角色为客户代表、业务员和项目经理。客户代表提出需求,业务员帮助整理和分析,项目经理对整个项目进行评估。在实际工作中,很多项目失败的起因都和需求分析有关。客户代表和业务员通常并非从事技术开发的专业人员,在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确,这时候需要项目经理或技术人员进行参谋。为了降低项目的风险,提高工作效率,有必要设计规范的需求管理计划书,帮助客户代表和业务员更好的完成任务。以下提供一份需求管理计划的模板可作为参考: 2.8 总结要尽快做好需求分析掌握以下要点,也许能事半功倍: (1)仔细聆听,罗列客户的所有要求。 (2)将需求进行分析,确认可操作的系统模型。 (3)利用最自然的语言将系统进行描述,使每个开发人员不会产生歧意。 (4)迅速确定网站的用户角色。 (5)比如访客、会员、重要客户、前台管理员、网站管理员、业务员等。 (6)分析确定每个角色的权限及可操作的功能。 (7)比如会员可以查看特别信息、修改个人信息、退出登陆等。 (8)前台管理员能够登录管理系统,能够发布编辑修改信息,能够审查会员资格等。 (9)网站管理员可以更改栏目、修改网站界面等。 (10)制作流程图和示意图将需求表现出来。 (11)让客户参与到示意图的设计中,及时正确的反应出需求变更。 (12)制作需求变更日志,保留升级版本,通过版本控制进行需求管理。 (13)通过需求管理计划书使每个参与人员看到共同的努力目标。第三章 项目模型及业务流程分析网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程,也不是对传统工作流程的简单复制,而需要对传统的工作流程进行合理的优化、改进和重组。3.1 编写项目模型文档,使所有人都一目了然通常用户提出的需求是凌乱的,不完整的,甚至是不正确的,而且更细致的需求经常是在项目开发进行中才被挖掘发现的,这对于开发人员来说是个极其困扰的问题。那么,在进行需求分析后制作项目模型文档,能在项目进入开发前,双方对即将要开始完成的项目的结果有个共同的认识,并提早暴露可能出现的需求变更,那么将大大提高开发的效率和质量。缺乏经验的项目人员往往在接受任务后迫不及待地进行系统分析和开发,而不愿意多一点时间在和客户反复推敲项目需求和模型,开发过程中想当然地凭空为客户做了很多假想,费了九牛二虎之力却吃力不讨好,可想而知,在不知道终点在哪里的马拉松比赛中,你会跑到哪里去?因此在确认了客户的初步需求以后,业务人员应该进行项目模型的设计描述。首先,我们要定义一下词汇表,并非每个客户或者项目小组成员都能够明白用户、角色、用例之间的差别,也不见得都能很好地理解通道、前台、后台到底是什么含义,为了让项目模型文档使每个浏览者正确地理解,定义词汇表是非常需要的,尤其是面对传统行业初次进行信息化设计的用户。模型描述采用最自然的语言进行描述,这份文档是对需求分析报告的进一步描述。使得客户代表、项目经理、开发人员对即将展开的项目通过项目模型的描述产生最直观的印象,并针对关键的问题进行讨论并达成统一认识,比如功能要求、性能指标、运行环境、投资规模等等。3.2 业务流程分析员进行流程设计业务流程分析员的人员应该善于简化工作,担任此角色的人员中必须要有具备广博的专业领域知识,并且具有良好的沟通技巧。业务分析人员重点需要协助客户将需求进行归纳分析,查找出所有的业务主角,确定业务主角后,每个主角的相关活动及流程应清晰地制定出来,最终设计出逻辑视图、用户界面示意图。比如一个电子商店系统,除了系统管理员、业务经理、业务员、物流配送员、客户服务人员等角色以外,可能还存在外部协作单位的不同角色,比如供应商、分销商、广告客户,还有购买用户,甚至再细分为普通消费用户、VIP消费用户、集团消费用户等等,每一类角色参与系统活动时的入口和流程都有所不同,通过逻辑图和示意图,业务流程分析员将系统的机构简要明确地进行描述。在进行业务流程设计,需要注意以下事项: (1)调查用户网络环境和配置,使架构设计师能够制定合理可行的系统架构。 (2)调查用户偏好和技能水平,这将直接影响到项目开发的深度和用户界面的设计。 (3)预测并制定系统的性能指标,为测试人员编写测试计划提供依据。许多项目设计中比较重视功能的实现,测试阶段看似满足了客户的需求,但一旦投入使用的时候,便会发现性能上面临着一个个瓶颈。客户由于对专业知识的了解程度有限,也往往忽略了这方面要求,因此为了避免日后陷入纠纷,事先预测并制定性能指标是非常重要的。3.3 界面工程师创建用户界面原型为了在实际系统开发投入之前,创建用户界面模型是非常重要的,开发原型的成本远远低于实际开发的成本,在项目初期,创建完整的用户界面揭示和测试系统的所有功能和可用性,并能够使客户代表参与讨论及修改,可以大大提高项目的成功几率。创建正确可行的原型以后,系统分析、设计及代码的编写都必须遵照原型进行,确保构建的系统是正确的,测试人员和客户也能够在开发过程中即实时地参与检查,可以有效地保障了项目的质量。根据业务流程分析员所提供的流程分析逻辑图及示意图,界面设计工程师开始设计制作用户界面原型,目前这个阶段,对于界面设计人员来说还没有进入精细设计的阶段,所以最重要的是将业务流程完整地表现出来,并和客户就设计风格,设计规范进行确认和定义。界面工程师在充分理解客户需求和所有的业务流程之后,利用合理的布局设计用户界面。比如网站的首页风格、首页需要显示的各个元素、导航的分类和表现方法、各类业务角色的入口等等。在此需要注意的是,用户界面不仅仅是网站访问者所浏览的界面,也包括了特殊用户、管理员、业务伙伴等不同的用户界面,甚至还有提示界面、警告界面、出错界面等等,设计完整的用户界面原型不仅能够使客户及测试人员更容易明确需求,也对项目的质量起到不可忽视的作用。3.4 以用户为中心的设计思考无论项目设计开发人员的水平是多么的精尖,毕竟不是系统的最终用户,最大限度地满足客户的需要才是关键,系统设计人员往往口头上挂着以用户为中心的口号,而实际上工作中又在大量地假想,或是出于懒惰或是出于条件限制,对于将来使用系统的不同用户来说都可能产生意想不到的障碍。真正做到以用户为中心,就要先放弃沉淀在脑子里的经验和想象,到客户工作的地方去、观察记录客户如何工作、然后与客户谈论他们的工作。在团队拓展训练中有一项叫做盲人方阵的课程,可以想象一群什么也看不见的人如何把一根长绳子拉成正方形景象吗?目中无人的人会懂得倾听和服从吗?我们不能假设用户到底是个健全人还是盲人,也不能假想用户应该会怎么做不该会怎么做,只有去仔细观察和沟通,才能制定出真正符合用户需要的计划。有专家提出:开发人员应决定用户的组成,并让用户尽可能早地涉入,并提出了几种熟悉用户、他们的任务以及需求的方法: (1)与用户交谈 (2)到办公地点拜访用户 (3)观察用户工作 (4)将用户工作录像 (5)了解工作组织 (6)自我尝试 (7)使用户在工作时边想边说 (8)让用户参与设计 (9)在设计小组中包括专家级用户 (10)执行任务分析 (11)利用调查和问卷 (12)制定可测试的目标在有可能的情况,在需求和流程设计中努力做到精确、客观和细致,不但能保证系统开发的质量和成熟度,也会使你得到客户高度的满意和信任,为今后更多的业务合作敞开大门。3.5 制作设计计划书到了这个阶段,可以说掌握了客户的需求并对计划实施的系统开发有了清楚地认识,与客户之间达成了共识,那么在进入下个阶段的工作时,制作设计计划书是非常必要的。设计计划书是全面描述整个系统的全貌,作为系统分析、测试人员工作的基础,同时也是客户验收的标准,作为业务合同的内容之一,因此,应该仔细谨慎地撰写设计计划书。根据项目的不同,设计计划书的内容或许有所不同,以下笔者提供一份样本供大家参考,该份样本基本涵盖了需要在计划书中进行确认和描述的核心要素。3.6 总结在本阶段的工作过程中,核心的任务是通过上个阶段的需求分析,进行项目模型设计和业务流程分析,并制作用户界面原型得到用户的确认,最终完成双方认可的设计计划书,作为下一阶段系统设计和软件建模的依据。第四章 系统分析及软件建模如果眼光仅仅放在满足客户眼下的需求,当问题不断出现时再不断修补,头痛医头,脚痛医脚,甚至系统构架需要不断调整或重新设计,那么,很快就会陷入代码泥潭或坠入系统重复开发的无底深渊,当初项目完成时的成就感将被无止境的沮丧所代替。系统分析决定系统开发的成败,软件建模使系统开发走向成熟。4.1 系统分析在网站项目管理中的地位在进行了需求分析和业务流程分析并得到客户的认可之后,对项目进行系统分析是极其重要的。系统分析是能体现整个系统的灵魂的文档,将客户的需求从具体到抽象的一个过程,并制定编码人员可实施的规范和标准。由于Web应用技术发展的历史相对与软件的历史短得多,在开发网络应用系统尤其是网站制作的系统设计中设计人员往往对系统分析重视的不够,特别是设计一些初期比较简单的或交互及功能较少的网站时,主要原因通常为:客户初期的需求比较简单,忽略了客户潜在的巨大需求;项目实施周期短,初期阶段采用最快的而不是最合理的实现手段;经费有限,难以支付高质量的人力费用;Web编程技术手段多样,容易上手,设计人员参差不齐。从现实中来看,网站项目的开发与管理和实施远不如软件工程规范,在编程语言、数据库、通信协议、应用服务器等相关环境都在不断快速发展和完善的情况下,的确很难期望每一个设计师都能网站项目进行系统的合理的分析,从而制定一套跨平台、健壮的、易扩展和升级的系统方案。但是,这并不能成为系统分析员逃避或懈怠的借口,如果把一个系统比做一部汽车,系统分析的工作相当于设计发动机,也许很容易就想象的出用125cc的摩托车发动机去牵引10吨重载卡车会是一个什么样的后果。在系统分析的过程中需要对需求分析进行进一步的深化和分析,通常客户及业务人员在需求分析和流程分析的过程中比较注重功能上的表现和定义,即使是做出正规的用户界面原型,对系统的需求也是不完整的,处于非技术人员的缘故,很难苛求能提出完整清晰专业的性能需求,但不意味着这需求不存在,而且这隐藏的需求对编码人员来说是极其重要的。因此,客户的需求能否在系统中得到真正的体现和实施,系统分析是至关重要的。4.2 系统分析所要做的工作把系统分析和详细设计阶段分开,针对不同项目的具体情况再决定采用什么方式进行开发。那么在系统分析过程中重点要做的是: (1)对客户的需求分析进一步完善和补充,尤其是性能需求:让客户更加清楚这是一个什么样的系统,所要达到的功能和性能指标是什么,系统的扩展性和适应性如何,如何为客户今后的升级或维护提供最有效的方法。 (2)系统运行所需要的环境:系统能正常运行所需要的硬件、软件、网络环境。 (3)系统的资源说明:系统所需要的各种成本,包括人员、时间、工作环境、一次性投入资金、持续性投入资金等所有资源。 (4)系统可行性分析。对于系统分析员比较苦恼的是大多客户在系统的要求上提不出独立的或成熟的意见,而将烫山芋交给了系统分析员的手上,为了避免在系统论证方面难以把握的失控和无从下手,设计几种不同类型的方案供客户选择不失为一个好的方法。经过系统分析的阶段,我们就比较容易和客户在系统如何部署、采用的数据库类型、设计模型和分析模型等方面达成一致的认识,如果能顺利地将客户的需求业务逻辑分析转化为程序逻辑,把原先用户可视化的界面原型和业务流程图映射成编码人员理解的模型和规范时,那么项目已经成功了一半。4.3 系统分析的难点和技能要求网络应用的开发技术在日新月异地进步,从而使网站应用系统的开发模式具有多种选择性,达到同样的目标可以采用很多不同的方式,现代的应用系统越来越成为一个庞大的集成方案,需要考虑不同的操作平台、不同的应用服务器、不同的数据库、不同的编程语言、不同的传输介质等等,无疑对系统分析员来说是个严峻的考验,任何人都不可能精通甚至说掌握全部的技术,简单例子:现在有Windows,Unix,Linux等各种服务器操作平台,有SQLServer,Oracle,DB2,Sybase,MySQL等数据库,有JAVA,PHP,ASP,CGI,JSP,C+,VB,Delphi等等工具,谁能全部精通呢?如果不能,那么如何确定是Windows+SQL Server+ASP好还是Unix+Oracle+JAVA合适?况且各种软件和语言还在不断发展进步之中,超越窄带的互联网,今后还可以涉及到宽带所带来的变动,或者增加与无线移动的接口,因此系统分析员能否出色的胜任工作很大程度上决定了系统开发的成败。对客户隐藏的性能需求的分析,由于客户对尚未实施的系统无法预见,对今后的业务发展也无法预知,对性能需求的分析和定义更需要系统分析员协助客户去确定和挖掘;确定项目设计方法,根据项目需求和资源的配置选择最合适的设计方式。对系统模块的划分和代码复用的设计,模块最大化,代码复用度最高,是一个成熟的系统不断致力追求的,将大型复杂的应用系统分解成相对独立,具有高度复用的模块,各个模块之间采用规范的参数接口,将大大提高系统的开发效率和维护升级的方便性。即使在网站的模板设计或交互设计上,也尽可能采用嵌套可复用的模板或调用统一的样式表、JS文件等。项目整体评估,系统分析员绝不应成为孤立的完美主义者,而需要根据项目的大局出发,比如公司的资源配置、人力状况、客户要求等因素评估项目整体和各个模块的工作量、进度和分配资源,制定出最合理的可行的实施方案。系统分析员不但需要具备良好的沟通协调能力,更需要具备业务和技术领域两方面的专业技能,在项目小组中是非常关键的角色之一。4.4 软件建模使系统开发迈向成熟Web应用系统往往随着客户的需求增长,开发不断深入,最终变得非常复杂,而且以Web为核心的网站系统通常都具有高度的动态扩展和交互,要在不完整和不断改变的需求情况下,在有限的时间内完成一套容易修改和维护的健壮的系统,在UML(统一建模语言)出现之前是极其困难的。大多的Web设计师或程序开发员为了让客户尽快看到可运行的应用系统,经过界面设计或简单的系统分析后直接进入编码阶段,甚至各个模块分头开发,服务器段代码随意编写、数据库任意添加、参数定义没有规范,整个应用系统处于一种无序混乱的状态,当我们采用建模及按照软件工程的方式进行管理的时候,情况马上就会好的多。UML(Unified Modeling Language,统一建模语言)是一种通用的可视化建模语言,用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具,同样,在网站设计或以网站为表现形式的各种网络应用项目中,UML也表现出强大的作用。UML能够描述系统的静态结构和动态行为:静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系;动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言,但我们可以用代码生成器将UML模型转换为多种程序设计语言代码,或使用反向生成器工具将程序源代码转换为UML模型。我们可以看的出,建模并不等同于程序编码,利用同样的UML模型可以生成不同语言的框架代码,而且可以通过反向生成,在编写代码过程中及时更新UML模型,这对系统分析员和项目管理人员来说是梦寐以求的。只要能够仔细地把握客户的需求,不断改进UML模型,那么采用什么样的语言开发已经成了次要,大量的需求积累和分析工作能在客户需求变化时得到高度的复用,即使系统采用新的语言重新开发,需要的也仅仅是编码部分的工作。虽然软件建模可以在开发的任何阶段进入,但是在设计初期,应该将精力更加集中在系统功能及性能分析、系统运行环境、选择编程语言等,而不是考虑考虑程序的细节,如在屏幕上的什么位置放置按钮等。在项目开发的中期引入建模是非常有意义的,通过建模把握程序开发的方向,准确完成需求分析中所要求的任务。在高展先生的全程建模一文中阐述的全程镜像一体化建模方式,整个建模过程依靠业务驱动,在模型设计中利用盒子的上下两部分分别代表业务组织结构和软件逻辑结构,将客户可视的具体的需求与系统抽象的逻辑流程一一对应,这对缺乏技术背景的客户代表和经验不足的系统分析员之间的沟通具有明显有效的作用。4.5 总结系统分析是项目开发中最艰巨的工作,本阶段需要特别注意的工作重点在于:(1)补充完善上一阶段可能欠缺的系统的性能需求。(2)系统分析员需要站在全局出发,设计合理可行的设计方案。(3)在需求不明的情况下设计多种解决方案供客户选择。(4)将系统分解模块,最大限度地设计代码复用。(5)使用UML建模方式,将客户变化的需求映射到模型中,大大提高系统的扩展性和开发效率。第五章 界面设计、交互设计及程序开发在网络项目开发过程中,这个阶段也叫做构建阶段,是工作量最大、最艰苦也是最难以控制的阶段。不管一座大楼的设计蓝图多宏伟,若没有管道工、泥瓦匠、水电工等各种工匠一砖一瓦地艰辛积累,密切协作,这座大楼始终是空中楼阁、海市蜃楼。5.1 界面设计打开用户之门对于以Web服务为模式的项目,无论是访问用户还是系统管理员,主要工作都是通过浏览器的界面交互完成。给系统设计合理友好的操作界面就像给人穿衣服一样,合体舒适的搭配能给人耳目一新的感觉,反之则令人敬而远之,甚至失去进一步深入了解的兴趣,这无疑不是开发人员所期望的结果。以网站为表现方式的系统界面设计所涉及的知识远远超过了美术的范畴,作为一个优秀的Web界面设计师来说,需要掌握的不仅仅是电脑制图的能力,还应该具备心理学、广告创意、美术工艺、排版艺术等多方面的综合素质,系统界面绝不是孤芳自赏令人难以理解的抽象画,而应该成为绝大多数用户共同接受的最方便的日用品。关于Web美工创作的操作技巧不是本文所关注的,我们希望知道的是用户最需要的是什么样的界面?根据作者的经验,在进行产品设计和项目开发的界面设计中是有所不同的。产品通常是指可大量分发销售的成熟性的产品,具体用户是不确定的,而项目大多是针对具体客户的需求进行开发,不具备二次销售的条件,当然,在二者之间总还是能找到共同点的。产品设计由于面对的是未知的用户,因此界面设计必须挖掘的是用户习惯和观念的共性,大众化产品(例如邮件系统、BBS、门户网站等)、商业应用产品(例如交易系统、电子办公系统)或专业应用产品(例如财务系统、杀毒系统)等等,需要考虑的是所有人或某一类的人的共同习惯和审美观念,而不是刻意地出奇招、不断地考验用户的智商和耐心。项目开发则相反,面对明确的具体用户考虑更多的是个性化设计,也许有些是非常规的要求,但是用户已经具有特殊的偏好和习惯时,应尽可能满足用户的需求进行设计。在作者参与某个行业的办公系统设计过程中,用户就提出了非常特别的要求,所有的界面不能出现外国人和外国场景的形象,每一页都需要变换颜色,另外站点标题要大得出乎寻常,失去比例,这时候美工只能迁就用户的心理和习惯,可是这样的设计用到产品设计上,大多人都会感到不舒服。不管是产品设计还是项目开发,界面设计都应该遵循以下共同的规则: (1)界面风格需要一致:每个新的系统对用户来说都是一次新的学习过程,如果界面风格经常变化,不保持统一,无疑更增加了用户的学习难度,也许会导致用户的厌烦。比如:第一页的导航条是图片型的放在页面顶部横排的,而在第二页导航条却成了文字型居左竖排,用户会为了捉摸不清设计师的意图而大发其火。 (2)界面元素对象化:在程序设计中需要注重模块化,而界面设计中对象化同样非常重要。将界面元素对象化,比如底部版权信息、导航条等,图片、JS也尽可能复用,比如站点标志、搜索按钮、滚动信息的JS文件等等。 (3)建立标准的文档管理和设计规范:界面设计涉及的要素比较多,文件类型复杂,而界面文件往往还需要另外通过程序进行编译,这就要求了界面设计人员必须建立规范的设计和标准的文档管理方法:* 制定文件命名标准* 设定文件统一路径* 保存原始创作文件(例如PSD、Fla源文件)* 最终完成文件(经过用户认可的文件)* 单独管理模板文件(经过编译或嵌入程序的文件)* 考虑用户偏好习惯和方便性我们经常可以听到界面设计师说:怎么在我机器上看得好好的,怎么在你那里就变样了其实道理很简单,用户的操作环境和习惯与设计环境是有差别的,界面设计同程序一样需要进行测试,主要测试的对象为:* 浏览器类型和版本兼容问题:假如有个很重要的菜单是需要IE5.5支持的,但是用户万一使用的是IE4.0版本,那么这个菜单就再也打不开,结果可想而知。* 分辨率:界面设计师的屏幕也许是17寸的,分辨率甚至做到1280960都是可以接受的,但是用户的如果用的14寸显示器,分辨率只能达到640480,界面布局看起来会很可笑。* 字体大小:利用样式表精确控制页面元素,特别是字体是很重要的。有不少用户喜欢更改浏览器默认的字体显示大小,当设计师看到用户将字体显示调整成最大而将表格撑得乱七八糟的时候,或许会痛心疾首的。* 考虑特殊情况:用户或许在浏览器设置了禁止显示图片或禁止JS脚本等,有必要为图片设置好尺寸以免影响其他元素的显示,并有其他的方式代替JS需要显示的效果和信息。 (4)编写帮助:无论多么出色的界面设计对用户来说都是陌生的,那么编写站点帮助或软件帮助是个非常有效的办法,把你的设计意图和使用介绍明明白白地告诉用户,在用户遇到困难的时候能够得到最快的帮助,不但可以降低用户的不满程度,同时可以帮助用户更加系统深入地学习和掌握。5.2 交互设计建立沟通的桥梁作为交互设计人员应该读读Alan Cooper的软件创新之路,被誉为VB之父的Alan Cooper明确地提出了将程序开发划分为交互设计和编码设计两大部分。 软件越来越难用,越来越难学。我们不止一次地听到用户如此地抱怨,也许程序员认为机器就是如此理解程序的,随着系统的日益复杂和功能的不断强大,软件越来越难用,门槛越来越高是很正常的,但是别忘记用户才是系统的所有者和使用者,期望用户成为计算机专家的要求显然是难以接受的。在国内无论是从事商务的技术人员还是技术型的商务人员都极其缺乏,交互设计师就理所当然地应该成为彼此沟通的桥梁。程序员和用户的差别是很明显的,因此通过交互设计建立良好的沟通是非常需要的。(一)交互设计师的侧重点并不在程序的编码实现,而注重于用户如何最好地与系统交互操作,在设计中重点需要考虑的是:* 系统易用性:并非每个用户都是计算机的熟练用户,面对隐藏的层和特殊设计的菜单可能会抓瞎,用户不见得能明白双击左键能自动滚屏或者怎样能让自动滚屏停下来、直接看最下面的结果。交互设计师特别需要重视的就是系统的易用性。有条件的话,可以让不同的陌生用户从首页开始操作,不给予任何提示和帮助,观察用户的上手和熟练程度,记录并查找所有的陷阱和缺陷,加以改进。* 流程简便:简单就是美,在系统交互设计方面更是如此,如何用最少的操作,最明显的提示和帮助,完成一项流程的操作是需要花大力气进行优化的。 * 盲点测试:用户的操作并不是严格的按照系统的提示顺序进行,也不一定会按照系统的提示要求去做,而程序员在设计的过程中是按照既定的逻辑进行开发的,测试中也难免以自己的习惯操作,这时就可能出现盲点,即系统存在未被测试到的状态环境。编写测试软件或利用其他测试工具可以大大提高测试的可靠性。例如一份表单正常提交以后,假如用户利用历史记录后退,回到提交前的状态,这时候修改了提交内容,又再一次提交,那么结果是什么呢?再比如,假如设计的弹出窗口的尺寸是700500,且不可改变大小,隐藏滚动条,而用户万一使用640480的分辨率,那么弹出的窗口中,用户如何能点击到最下面的按钮?* 出错及异常提示:凡是软件都是有BUG的,因此对各种出错或异常状态给予用户一个友好的提示和帮助,并提示用户大概是由于什么原因,那么用户会愉快的多。作者遇到过一个用户注册系统,用户注册后希望修改密码,有的能做成功,而有些人怎么也改不了,检查了很长时间才发现由于密码设置的是不少于三位不大于八位,许多用户密码超过了八位,因此无法修改成功,但是由于没有提示出错原因,所以用户就不断拼命地提交,最后只好愤怒地去投诉。再例如发布信息的时候,可能会因为填写时间过长,提交时被系统拒绝数据丢失,那么用户辛辛苦苦撰写的内容永远消失了,还有什么比这个更令用户沮丧的吗?在填写的输入部分给用户一个时间提示,或允许后退找回刚才的内容,至少可以让用户容易接受一些。* 利用用户环境测试利用用户的操作环境进行测试,用户的服务器、网络线路和客户机也许跟开发环境差别巨大,用户的机器配置、网络环境对系统的要求是不一样的。比如设计客户端的APPLET时也许会因为客户机的内存不足而崩溃,也可能因为文件过大,远程访问时处理时间过长而响应失败,。(二)Web的交互设计师需要掌握的技能主要是Javascript、VBscript、Dhtml、Flash等,还需要了解心理学、人因工程学、系统工程等方面的经验和知识,认真把握每个交互动作的合理性和可行性,这个交互也许是个链接,也可能是个表单、提示窗口或者是滚动条的拉动距离,检查是否最优化和最合理的方式。举个很简单的例子,在链接列表过多出现翻页的时候,程序员很自然地会将上一页、下一页的翻页按钮放在了最底下,但是列表很长的时候,用户每次翻页的时候都需要把滚动条拉到最下面才可以点击到翻页按钮,用户可能就会抱怨,明明知道在某一页,却每次要点击后拉滚动条寻找翻页按钮,而如果将翻页按钮在列表的上面也放一条,并且设置直接跳转到某页的按钮,则大大减轻了用户的工作量,类似的例子在我们的设计中屡见不鲜。5.3 程序开发是系统的基石程序员进行编码,构成了系统的基础。在进行系统分析和软件建模以后,程序开发便进入实质性的过程。但是在程序员动手之前不单需要和系统分析员打交道,还要和界面工程师,交互设计师,业务流程分析员以及客户交流,除了理解程序逻辑以外,同时需要理解界面设计和交互设计的要求,使得程序开发成功的可能性大大提高,达到事半功倍的效果。随着网络开发技术的日益发展和用户需求的不断增长,系统开发中的编码工作日益繁重,不仅仅需要考虑性能和功能的实现,而且需要考虑今后的维护和扩展,需要考虑到系统的集成和稳定,许多稍微复杂一些的系统开发便不再是一个人能独立完成的,因此程序开发需要遵照严格规范的开发过程。* 文档规范:良好的文档习惯是系统开发极其重要的,文档是程序的一部分,程序员花一定时间进行文档编写是份内的工作。具备完整的文档记录,对于系统今后的二次开发、查错、升级具有重大的作用。可以说即使代码全部扔掉,只要文档完整,很快就可以再造一个系统出来,而只保留了代码,缺乏文档的时候,就像被抽了脊梁的标本,再难站起来恢复原样。* 编码规范:编码规范包含了程序排版、注释、命名、可读性、变量、程序效率、质量保证、代码编译、代码测试和版本控制等等注意事项。程序员最常见的问题之一:别人写的代码看不懂,与其改写不如重写。基本上都是没有按照编码规范开发的缘故。所以我们经常听说某个程序员离职以后,他所写的那些模块就没法维护和管理了。* 代码复用:代码复用是程序员的梦想,也是系统成熟度的重要标志,关于代码复用方法的讨论不在本文之列,但是代码复用是程序员走向成熟和提升的必经之路。* 测试测试再测试:在软件工程的讨论会上,微软的一位项目经理在介绍微软如何保证产品质量时说:微软质量保证的秘密就是:测试测试再测试!在IE4.0的开发小组中,200名开发程序员以外还有200多名测试工程师,而且测试工程师的水平甚至高于开发工程师。测试是系统质量最直接有效的手段。在国内的开发环境达到这样的投入和水平显然是不太现实的,但是尽可能提高测试环境和加强测试管理,是程序员和测试工程师共同的方向。5.4 本阶段的重点工作在这个阶段是整个项目组参与角色最多,也是协作最密切最难控制的过程,作为项目经理特别需要关注以下问题:1、建立项目小组的沟通渠道。2、建立文档规范和管理办法,借助PVCS、WINCVS等相关工具建立整个项目小组的文档。3、建立BUG报告系统,在内部预先创建测试环境,将BUG尽可能早地消除掉。4、测试和文档工程师的工作自始自终地贯穿着项目开发过程。5.5 总结* 沟通是本阶段最需要注意的问题。* 建立文档管理体系。* 建立测试环境和测试标准。* 界面设计是为用户设计的,不是用来自己欣赏的艺术品。* 为用户着想,人性化设计是项目成功的保证。* 代码复用,对象化模块化设计是界面设计、交互设计和程序开发共同追求的目标。第六章 系统测试和文档编写在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的客户端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。一般软件的发布周期以月或以年计算,而Web应用程序的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。6.1 功能测试6.1.1 链接测试链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。6.1.2 表单测试当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。6.1.3 Cookies测试Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。6.1.4 设计语言测试Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。6.1.5 数据库测试在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。在使用了数据库的Web

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论