网站项目管理(ppt)
网站项目管理
网站项目管理含义
以Web应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。
网站项目管理的必然出现
随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。
网站项目管理流程
需求分析及变更管理
项目模型及业务流程分析
系统分析及软件建模
界面设计、交互设计及程序开发
系统测试和文档编写
如何做好需求分析及变更管理
撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。
需求调研内容
网站当前以及日后可能出现的功能需求。
客户对网站的性能（如访问速度）的要求和可靠性的要求。
确定网站维护的要求。
网站的实际运行环境。
网站页面总体风格以及美工效果（必要的时候用户可以提供参考站点或者由公司向用户提供）。
主页面和次级页面数量，是否需要多种语言版本等
内容管理及录入任务的分配。
各种页面特殊效果及其数量（js,flash等）
项目完成时间及进度（可以根据合同）
明确项目完成后的维护责任。
让用户畅所欲言，罗列出所有的需求
让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。不应该害怕引起用户的潜在需求而增加设计开发的工作量，从而被今后用户无止境的变更拖入泥潭，直接明白地跟用户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来。
透过现象分析潜在的需求
用户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求我们在倾听了用户的详细说明以后，帮助用户进行整理和归纳、分析，整理出重点和技术难关，同时预测用户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。尤其是用户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。
利用自然的语言描述项目模型
在需求调研人员与用户进行沟通和调查时撰写的需求分析，尽可能用自然的语言进行描述，虽然用户的水平和资历有所不同，但是最自然的描述能够使项目开发的各个成员都能清楚地理解需求含义，不至于在理解上产生偏差。对用户而言，这样的模型描述最接近真实，容易参与修订，并能以此为测试和验收的依据。
利用示意图和图表将用户的需求表现出来
需求分析无论文字上怎么样表述都还是抽象的，对用户而言理解毕竟是困难的，将基本确定的需求制作出示意图是最直观有效的。利用示意图将用户的需求和即将开始设计的系统体现起来，在进行系统分析和程序开发之前，双方对今后要完成的产品就能够有直观的认识，也就是在产品还没有真正进入开发阶段的时候，双方就对工作的结果达成统一的意见，这将大大地减轻需求变更所带来的困扰，同时用户更容易地参与到项目的开发过程，保证项目往正确的方向进行。
需求分析报告讨论
项目经理、系统分析员、开发经理、交互设计师、测试人员、文档人员包括用客户代表都应该看需求分析，并进行共同的讨论，达成一致的意见。
项目经理通过需求分析组建所需要的团队，配置工作环境，制定开发周期。 程序员采用的编程语言和工具受开发周期的限制和功能上的要求的影响； 交互设计师进行前台设计时的精度要求受操作用户的技能水平的影响； 界面设计人员根据项目的性质和定位确定表现方式。 测试人员了解测试环境和条件后才能对项目质量进行跟踪和检测。
建立需求变更日志，更新需求分析报告
由于用户的遗漏，或者在开发过程中被激发出来的需求，需求变更有时非常频繁和琐碎，往往不能将变更及时反馈到项目的各个角色中，那么做好需求变更日志就显得非常重要。
在需求分析后面附上变更日志，并将修改后的需求分析制作成新版本，保留每次更改过的版本，而不是覆盖，这样就比较容易地跟踪到需求变更过程中所带来的工作调整。 新版本的需求分析中，将变更多部分用特殊方式表现出来，并在日志中记录变更多的细节。
需求分析和变更管理关系
需求管理计划书
为了降低项目的风险，提高工作效率，有必要设计规范的需求管理计划书，以便更好的完成任务。
要素：
修订记录（日期，版本，说明，修订者）
项目简介（客户资料，项目背景，项目前景）
需求分析（需求记录，用户角色，用户流程）
功能分析（功能描述，模块划分，接口定义）
形象分析（形象定位，特殊标志，色彩定义）
结构规划（网站结构，扩展接口）
界面规范（设计标准，公共参数）
系统规范（硬件环境，软件环境，开发语言）
项目实施（项目阶段，开发周期，验收标准，项目成员）
需求分析阶段重点工作角色
重点角色为用户代表、需求调研人员和项目经理。 用户代表提出需求，需求调研人员帮助整理和分析，项目经理对整个项目进行评估。 在实际工作中，很多项目失败的起因都和需求分析有关。 用户代表和需求调研人员通常并非从事技术开发的专业人员，在讨论需求的时候往往对项目的技术难度、工作量、时间进度把握不准确，这时候需要项目经理或技术人员进行协调。
需求分析阶段总结（一）
仔细聆听，罗列用户的所有要求；
将需求进行分析，确认可操作的系统模型。利用最自然的语言将系统进行描述，使每个开发人员不会产生歧义；
迅速确定网站的用户角色。比如访客、会员、重要客户、前台管理员、网站管理员、业务员等；
需求分析阶段总结（二）
分析确定每个角色的权限及可操作的功能。制作流程图和示意图将需求表现出来；
让用户参与到示意图的设计中，及时正确的反应出需求变更。
制作需求变更日志，保留升级版本，通过版本控制进行需求管理；
通过《需求管理计划书》使每个参与人员看到共同的努力目标。
项目模型及业务流程分析
网络技术的应用所产生的电子流程工作方式既不能彻底更改传统的工作流程，也不是对传统工作流程的简单复制，而需要对传统的工作流程进行合理的优化、改进和重组。
编写项目模型文档，使所有人都一目了然
在进行需求分析后制作项目模型文档，能在项目进入开发前，双方对即将要开始完成的项目的结果有个共同的认识，并提早暴露可能出现的需求变更，那么将大大提高开发的效率和质量。
由需求调研人员进行项目模型的设计描述。
模型描述采用最自然的语言进行描述，这份文档是对需求分析报告的进一步描述。使得客户代表、项目经理、开发人员对即将展开的项目通过项目模型的描述产生最直观的印象，并针对关键的问题进行讨论并达成统一认识，比如功能要求、性能指标、运行环境、投资规模等等 。
业务流程分析员进行流程设计
业务流程分析员的人员应该善于简化工作，担任此角色的人员中必须要有具备广博的专业领域知识，并且具有良好的沟通技巧。
业务分析人员重点需要协助客户将需求进行归纳分析，查找出所有的业务主角，确定业务主角后，每个主角的相关活动及流程应清晰地制定出来，最终设计出逻辑视图、用户界面示意图。
业务流程设计注意事项
调查用户网络环境和配置，使架构设计师能够制定合理可行的系统架构；
调查用户偏好和技能水平，这将直接影响到项目开发的深度和用户界面的设计；
预测并制定系统的性能指标，为测试人员编写测试计划提供依据。
界面工程师创建用户界面原型
为了在实际系统开发投入之前，创建用户界面模型是非常重要的，开发原型的成本远远低于实际开发的成本，在项目初期，创建完整的用户界面揭示和测试系统的所有功能和可用性，并能够使用户代表参与讨论及修改，可以大大提高项目的成功几率。
创建正确可行的原型以后，系统分析、设计及代码的编写都必须遵照原型进行，确保构建的系统是正确的，测试人员和用户也能够在开发过程中即实时地参与检查，可以有效地保障了项目的质量。
创建用户界面原型阶段注意事项
界面设计工程师根据流程分析逻辑图设计制作用户界面原型，这个阶段，界面设计人员还没有进入精细设计的阶段，最重要的只是将业务流程完整地表现出来，并和客户就设计风格，设计规范进行确认和定义。 界面工程师在充分理解客户需求和所有的业务流程之后，利用合理的布局设计用户界面。比如网站的首页风格、首页需要显示的各个元素、导航的分类和表现方法、各类业务角色的入口等等。
用户界面不仅仅是网站访问者所浏览的界面，也包括了特殊用户、管理员、业务伙伴等不同的用户界面，甚至还有提示界面、警告界面、出错界面等等。
以用户为中心的设计思考
无论项目设计开发人员的水平多么精尖，毕竟不是系统的最终用户，最大限度地满足用户的需要才是关键，系统设计人员往往口头上挂着以用户为中心的口号，而实际上工作中又在大量地假想，或是出于懒惰或是出于条件限制，对于将来使用系统的不同用户来说都可能产生意想不到的障碍。
真正做到以用户为中心，就要先放弃沉淀在脑子里的经验和想象，到用户工作的地方去、观察记录用户如何工作、然后与用户谈论他们的工作。
熟悉用户需求的方法
与用户交谈或者到办公地点拜访用户
观察用户工作
了解工作组织
自我尝试
让用户参与设计
在设计小组中包括专家级用户
执行任务分析
利用调查和问卷
制定可测试的目标
制作设计计划书
这个阶段，可以说掌握了用户的需求并对计划实施的系统开发有了清楚地认识，与用户之间达成了共识，那么在进入下个阶段的工作时，制作设计计划书是非常必要的。
设计计划书是全面描述整个系统的全貌，作为系统分析、测试人员工作的基础，同时也是客户验收的标准，作为业务合同的内容之一，因此，应该仔细谨慎地撰写设计计划书。
设计计划书要素
用户情况分析（概况优势，竞争者，网站带来好处）
网站需要实现的目的和目标；
网站形象说明；
网站的栏目版块和结构；
网站内容的安排，相互链接关系；
使用软件，硬件和技术分析说明；
网站测试（方法，目标）
开发时间进度表；
宣传推广方案；
维护方案（软硬件，数据库维护，内容更新，调整）
制作费用；
流程分析阶段总结
真正以用户为中心的设计，到用户的实际工作环境中观察和记录；
仔细查找各种业务主角，并表述不同主角的各种操作流程步骤；
简化需求，将用户的需求归纳整理，抓住核心问题；
细化需求，针对核心问题，模拟用户角色，进一步确认流程和规范；
认真制定设计计划书，为下阶段的工作打好基础；
系统分析及软件建模
系统分析决定系统开发的成败，软件建模使系统开发走向成熟。
系统分析在网站项目管理中的地位
系统分析是能体现整个系统的灵魂的文档，将客户的需求从具体到抽象的一个过程，并制定编码人员可实施的规范和标准。
在系统分析的过程中需要对需求分析进行进一步的深化和分析，通常用户及需求调研人员在需求分析和流程分析的过程中比较注重功能上的表现和定义，即使是做出正规的用户界面原型，对系统的需求也是不完整的，处于非技术人员的缘故，很难苛求能提出完整清晰专业的性能需求，但不意味着这需求不存在，而且这隐藏的需求对编码人员来说是极其重要的。
系统分析所要做的工作
把系统分析和详细设计阶段分开，针对不同项目的具体情况再决定采用什么方式进行开发。
对客户的需求分析进一步完善和补充，尤其是性能需求。
系统运行所需要的的软硬件网络环境。
系统的资源说明，包括人员、时间、投入等。
系统可行性分析。
系统分析几个解决方案
大多用户在系统的要求上提不出独立的或成熟的意见，而将问题交给了系统分析员的手上，为了避免在系统论证方面难以把握的失控和无从下手，有几种解决方案：
低成本解决方案：只完成最必要工作，不能多做一点额外工作。
中等成本的解决方案：系统不仅能够很好地完成预定的任务，而且可能还具有用户没有具体指定的某些功能和特点。
高成本的“十全十美”的系统：系统具有用户可能希望有的所有功能和特点。

系统分析的难点和技能要求
对客户隐藏的性能需求的分析。
根据项目需求和资源的配置选择最合适的设计方式。
对系统模块的划分和代码复用的设计：模块最大化，代码复用度最高。
项目整体评估，评估项目整体和各个模块的工作量、进度和分配资源，制定出最合理的可行的实施方案。
软件建模使系统开发迈向成熟
Web应用系统往往随着客户的需求增长，开发不断深入，最终变得非常复杂，而且以Web为核心的网站系统通常都具有高度的动态扩展和交互，要在不完整和不断改变的需求情况下，在有限的时间内完成一套容易修改和维护的健壮的系统，在UML（统一建模语言）出现之前是极其困难的。 采用建模及按照软件工程的方式进行管理，可以改善一些情况，比如经过界面设计或简单的系统分析后直接进入编码阶段，甚至各个模块分头开发，服务器段代码随意编写、数据库任意添加、参数定义没有规范，整个应用系统处于一种无序混乱的状态。
建模的好处
建模是使你逐层深入解决问题的办法；
确认应用系统的功能需求并为事务处理原则建模；
对抽象的对象映射需求，辨认和提供设计模版并创建惯用的模版；
分辨和设计对象或划分三层模型的服务；
对软件的组成部分映射成对象并设计组件在网络上如何分布。
UML
UML（Unified Modeling Language，统一建模语言）是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，同样，在网站设计或以网站为表现形式的各种网络应用项目中，UML也表现出强大的作用。
系统分析阶段总结
补充完善上一阶段可能欠缺的系统的性能需求；
系统分析员需要站在全局出发，设计合理可行的设计方案；
在需求不明的情况下设计多种解决方案供客户选择；
将系统分解模块，最大限度地设计代码复用；
使用UML建模方式，将客户变化的需求映射到模型中，大大提高系统的扩展性和开发效率。
界面设计、交互设计及程序开发
网络项目开发过程中，构建阶段是工作量最大、最艰苦也是最难以控制的阶段。
界面设计打开用户之门
以网站为表现方式的系统界面设计所涉及的知识远远超过了美术的范畴，作为一个优秀的Web界面设计师来说，需要掌握的不仅仅是电脑制图的能力，还应该具备心理学、广告创意、美术工艺、排版艺术等多方面的综合素质，系统界面绝不是孤芳自赏令人难以理解的抽象画，而应该成为绝大多数用户共同接受的最方便的日用品。
界面设计规则
界面风格需要一致
界面元素对象化
建立标准的文档管理和设计规范
制定文件命名标准
设定文件统一路径
保存原始创作文件
最终完成文件（经过用户认可的文件）
单独管理摸版文件（经过编译或嵌入程序的文件）
界面设计规则（续）
考虑用户偏好习惯和方便性
浏览器类型和版本兼容问题
分辨率
字体大小
考虑特殊情况
编写帮助
交互设计建立沟通的桥梁
交互设计师的侧重点并不在程序的编码实现，而注重于用户如何最好地与系统交互操作。需要考虑几个因素：系统易用性；流程简便；盲点测试；出错及异常提示；利用用户环境测试。
Web的交互设计师需要掌握的技能主要是脚本语言或者Flash等，还需要了解心理学、人因工程学、系统工程等方面的经验和知识，认真把握每个交互动作的合理性和可行性，这个交互也许是个链接，也可能是个表单、提示窗口或者是滚动条的拉动距离，检查是否最优化和最合理的方式。
程序开发是系统的基石
进行系统分析和软件建模以后，程序开发便进入实质性的过程。但是在程序员动手之前不单需要和系统分析员打交道，还要和界面工程师，交互设计师，业务流程分析员以及用户交流，除了理解程序逻辑以外，还需要理解界面设计和交互设计的要求，使得程序开发成功的可能性大大提高，达到事半功倍的效果。
随着网络开发技术的日益发展和用户需求的不断增长，系统开发中的编码工作日益繁重，不仅仅需要考虑性能和功能的实现，而且需要考虑今后的维护和扩展，需要考虑到系统的集成和稳定，许多稍微复杂一些的系统开发便不再是一个人能独立完成的，因此程序开发需要遵照严格规范的开发过程。
开发规范
文档规范：软件即文档。
编码规范：编码规范包含了程序排版、注释、命名、可读性、变量、程序效率、质量保证、代码编译、代码测试和版本控制等等注意事项。
代码复用
测试测试再测试
开发阶段重点工作
建立项目小组的沟通渠道。
建立文档规范和管理办法，借助CVS等相关工具建立整个项目小组的文档。
建立BUG报告系统，在内部预先创建测试环境，将BUG尽可能早地消除掉。
测试和文档工程师的工作自始自终地贯穿着项目开发过程。
程序开发阶段总结
沟通是本阶段最需要注意的问题；
建立文档管理体系；
建立测试环境和测试标准；
界面设计是为用户设计的，不是用来自己欣赏的艺术品；
为用户着想，人性化设计是项目成功的保证；
代码复用，对象化模块化设计是界面设计、交互设计和程序开发共同追求的目标。
系统测试
针对整个系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
系统测试的对象
系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
系统测试的目的
软件测试是为了发现错误而执行程序的过程;
测试是为了证明程序有错，而不是证明程序无错误;
一个好的测试用例是在于它能发现至今未发现的错误;
一个成功的测试是发现了至今未发现的错误的测试。
测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。其次，没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。
Web系统测试方法(一)－功能测试
链接测试。测试链接是否正确指向；测试链接的页面是否存在；保证Web应用系统上没有孤立的页面。
表单测试。测试提交操作的完整性，以校验提交给服务器的信息的正确性。
Cookies测试。Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
设计语言测试。Web设计语言版本的差异可以引起客户端或服务器端严重的问题。
数据库测试。一般是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
Web系统测试方法(二)－性能测试
连接速度测试。响应速度影响用户耐心，页面超时导致提交数据丢失。
负载测试。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
压力测试。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。压力测试的区域包括表单、登陆和其他信息传输页面等。

Web系统测试方法(三)－可用性测试
导航测试。导航是否直观，web系统的主要部分是否可通过主页存取？web系统是否需要站点地图、搜索引擎或其他的导航帮助？
图形测试。确保图形有明确的用途，验证所有页面字体风格是否一致，背景颜色应与字体颜色和前景颜色相搭配，图片的大小和质量 。
内容测试。检验Web应用系统提供信息的正确性、准确性和相关性。
整体界面测试。整个Web应用系统的页面结构设计，是给用户的一个整体感。
Web系统测试方法(四)－兼容性测试
平台测试。需要在各种操作系统下对Web系统进行兼容性测试。
浏览器测试。测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
Web系统测试方法(五)－安全性测试
Web应用系统是否有超时的限制。
相关信息是否写进了日志文件、是否可追踪。
使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
服务器端的脚本测试。服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。
测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
传统测试过程
代码审查。由一组人通过阅读、讨论和争议对程序进行静态分析的过程。
单元测试。集中在检查软件设计的最小单位—模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。
集成测试。将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。
确认测试。目的是向未来的用户表明系统能够像预定要求那样工作。
系统测试。软件开发完成以后，最终还要与系统中其他部分配套运行，进行系统测试。
传统测试的问题
项目进度难于控制，项目管理难度加大。大量的软件错误往往只有到了项目后期系统测试时才能够被发现，解决问题所花的时间很难预料，经常导致项目进度无法控制，同时在整个软件开发过程中，项目管理人员缺乏对软件质量状况的了解和控制，加大了项目管理难度。
对于项目风险的控制能力较弱。项目风险在项目开发较晚的时候才能够真正降低。往往是经过系统测试之后，才真正确定该设计是否能够满足系统功能、性能和可靠性方面的需求。
软件项目开发费用超出预算。
另一种测试过程
尽早测试。将整个软件的测试按阶段划分成开发员测试和系统测试两个阶段。
连续测试。迭代式软件开发模式，将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。
自动化测试。
测试过程总结
测试人员自身素质的培养，保证良好的心态
测试的技巧和方法
测试的时机
每个过程的每一个环节都要进行测试，保证系统在每个阶段可以控制
开发总结
项目总结报告
编写目的
项目背景
程序主要功能和性能
程序处理流程
程序开发进度
开发工作评价（生产效率，产品质量，技术方法，出错原因分析）
经验和教训

网站项目管理(ppt)