CMS项目内容管理系统课件.pptx
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《CMS项目内容管理系统课件.pptx》由用户(三亚风情)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMS 项目 内容管理 系统 课件
- 资源描述:
-
1、 手把手教程CMS项目内容管理系统Content Management System 手把手教程Project学习内容 WEB项目开发一般流程 CMS项目流程详解手把手教程ProjectWEB项目开发的一般流程总纲1. 需求分析的确定2. 架构与设计 架构分析与设计 业务逻辑分析 业务逻辑设计 界面设计3. 开发环境搭建4. 开发-测试-开发-测试5. 培训文档编写手把手教程Project开发的一般流程需求分析 为什么需求分析 需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程,在这个过程中,用户的确是处在主导地位,需求分析工程师和项
2、目经理要负责整理用户需求,为之后的软件设计打下基础。需求分析阶段结束后,要求得到相关的需求文档, 需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 手把手教程Project需求分析的任务 需求分析的任务就是解决“用户要做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求 ,并且能够根据自己对用户需求的理解,劝说并诱导客户剔除不合理的需求。手把手教程Project 需求分析过程需求分析过程手把手教程Project 需求开发过程域
3、 需求开发的目的是通过调查与分析,获取用户需求并定义产品需求。 需求调查的目的是通过各种途径获取用户的需求信息(原始材料),产生用户需求说明书。 需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需求定义的目的是根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。 手把手教程Project 需求管理过程域 需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。 需求确认是指开发方和客户共同
4、对需求文档进行评审,双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更,防止需求变更失去控制而导致项目发生混乱手把手教程Project需求开发过程中困难 知识技能问题 行业知识是无边无际的。俗话说“隔行如隔山”,需求分析员可能是某一领域的专家,但当他接手陌生的业务时,他该怎么办? 首先他要有勇气做事,否则连实践的机会都没有。 其次他应当赶紧补习这一领域知识,不论是通过自学还是培训的方式,否则他很难
5、与用户交流。如果可能的话,开发方最好请既懂软件又懂应用域知识的行家来帮忙。手把手教程Project需求开发过程中困难 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时,他们会发牢骚,找出一堆用户的毛病。很多开发人员错误地以为: 需求是用户的事情,不是我们的事情。我们为用户开发软件,难道用户不该告诉我们应当开发什么吗?如果用户说不清楚需求,或者经常变更需求,这类问题是用户产生的,应当由他们自己负责。 用户说不清楚需求或者需求发生变更,这些都是常见的问题,并不是绝症,是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口,不愿主动攻克问题,导致需求问题扩散到整个软件开发
6、过程,产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑:需求分析员的天职就是在有限的时间内获取准确而细致的用户需求,如果做不到就是失职,不要找借口。 手把手教程Project合作关系 如果需求分析员不能与用户建立良好的合作关系,那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员,那并不表示他是个坏蛋。因为用户有他自己的想法: 我回答了你们的问题,讲了该讲的。我们付钱给你们,难道还要我伺候你们不成?我还要干自己的事情,别打扰我了。你们自己想办法把活干好吧 。 需求分析员不是销售人员,他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要
7、有过硬的专业知识,还要具备较强的交流、沟通能力。 开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目,我们不能完全期望双方能够自发地建立起良好地合作关系,这样风险太大。 开发方和用户方在开展需求开发之前,双方协商并撰写“用户在需求工程中的权利与义务”,即以协议的方式确定合作关系。“好话”和“丑话”都说在前头,这样能减少今后的摩擦。如果条件允许的话,开发方最好为用户举办关于需求工程的培训,这样的培训将使用户明白需求的重要性以及忽视需求的危害性,从而促使他们积极友善地参加需求工程中的各项活动。 手把手教程Project用户在需求工程中的“权利” 用户在需求工程中的“权利” 1
8、. 有权要求开发方派遣资质合格的需求分析员和相关人员。 2. 有权要求开发方采用用户熟悉的语言来描述需求,即开发方必须提供用户看得懂得需求文档。 3. 有权审查需求文档,并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿,可以拒绝在需求文档上签字。 4. 如果用户想要变更需求,有权要求开发方对该变更将产生的影响作出真实可信的评估,以便用户决定是否变更需求。手把手教程Project用户在需求工程中的“义务” 用户在需求工程中的“义务” 1. 以积极友善的态度与开发方人员交流、协作,尽可能地为开发方人员提供工作和生活上的便利。 2. 乐意接受需求分析员的采访,在不泄漏机密的前提
9、下尽可能地回答需求分析员的问题。 3. 在不泄漏机密的前提下,尽可能地向需求分析员提供与需求相关的材料。 4. 与需求分析员共同评审需求文档,确保需求文档准确地反映用户真实的意愿。 5. 对专业性太深入的知识领域,用户有义务组织开发人员进行简单的培训。手把手教程Project 需求没有做好的后果 手把手教程Project如何准备调查需求 需求分析员应当确定需求调查的方式,例如: 与用户负责人交谈,向用户提问题。 同未来此软件的目标用户交谈,了解他们的目前的工作状况. 参观用户的工作流程,观察用户的操作。 与同行、专家交谈,听取他们的意见。 分析已经存在的同类软件产品,提取需求。 从行业标准、规
10、则中提取需求。手把手教程Project如何做好需求分析 为了得到用户的金钱,企业不得不鼓吹:用户就是上帝,用户永远是正确的。 谁都知道这不是真的。事实上,很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。 需求分析是指在需求开发过程中,对所获取的需求信息进行分析,及时排除错误和弥补不足,确保需求文档正确地反映用户的真实意图。 需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类:“问答分析法”和“建模分析法”。后者技术性比较强,写出来有学术味,故大多数软件工程书籍都有论述。前者就是一些常识而已,虽然写不成文章,但是简单易用(保你一学就会),很有实用价值。 “问答分析法”比较
11、适合于用户需求调查阶段 “建模分析法”比较适合于产品需求定义阶段。手把手教程Project问答分析方法 问答分析方法 问答分析方法很简单:刨根究底地问,如果问题都被解答了,那么需求也就分析清楚了。一个人可以“自问自答”地分析需求,几个人分析需求则称为“研讨”。 问答分析最重要的问题是:“是什么”,”做什么”和“为什么”。每个需求都应当用陈述句说明“是什么”,如果“是什么”的内涵不够清晰,则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的,那么应当解释“为什么”,以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。 其它常见的问题有: 需求存在二义
12、性吗? 需求文档的上下文有矛盾吗? 需求完备吗? 需求是必要的吗? 需求可实现吗? 需求可验证吗? 需求的优先级确定了吗? 手把手教程Project建模分析法 人们都有这样地感受:有些时候用语言描述某个问题特别费劲,而采用图形则使人一目了然. 在需求开发过程中,对于某些类型的信息,用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。 需求建模就是指用图形符号来表示、刻画需求。 建模分析方法主要有两大类:“结构化分析法”和“面向对象分析法”。 恰当地使用图形符号: 现代建模工具如Rose、Jude有非常丰富的图形符号和文字标注,能很好地表达模型的细节。要注意的是:在建
13、模时使用花样过多的图形符号或文字意味着模型表示的复杂化,将使开发人员更难掌握,而且使图形文档更加杂乱。 世上不存在一个包罗万象的图它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中,文字描述是第一重要的,建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中,便于正文引用。 手把手教程Project 分析决策 当需求从四面八方收集来后,需求的冲突在所难免。对于那些难以达成共识的需求而言,经常会发生“公说公有理,婆说婆有理”的现象。那么需求分析员究竟应该听谁的呢? 如果一群人对需求有争议,并不是谁声音最响就听谁的。根据生活经验,最保险的办法是:先听官儿大的或者威望高的,如果大家的
14、职位和威望都差不多,那么采用“少数服从大多数”的原则。 如果一个产品可以卖给几类客户,但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策应当以商业利益为导向, 即哪一类客户出钱最多就先满足他们的需求,以后再做那些获利相对较少的需求。 当开发者想象中的产品与客户所提的需求有冲突时,一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里,需求分析员应当纠正明显不合理的客户需求。如果产品很复杂,双方都不太明白需求,此时最好请开发人员快速构造软件的原型,双方看着软件原型再分析需求手把手教程Project什么是好的需求规格说明书 正确 需求规格说明书应当正确地反映用户的真实意图,“正确”是
15、产品需求规格说明书最重要的属性。如果“不正确”仅仅是由于错别字造成的,那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的,开发方和用户必须对需求规格说明书进行确认。 清楚 清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚:文档的结构、段落是否乱七八糟?上下文是否不连贯? 文档的语句是否含糊其词、罗里罗嗦? 看了半天是否还不明白需求究竟是什么? 无二义性 “无二义性” 是指每个需求只有唯一的含义。如果一个人说的话,不同的人可能有不同的理解,那么这句话就有二义性。如果需求存
16、在二义性,将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性,人们在写产品需求规格说明书时措词应当准确,切勿模棱两可。 手把手教程Project什么是好的需求规格说明书 一致 “一致”(Consistent)是指产品需求规格说明书中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 必要 产品需求规格说明书中的各项需求对用户而言应当都是必要的。 可以把“必要”比喻为“雪中送炭”。“必要”往前一步,要么是“画蛇添足”要么是“锦上添花”。 “画蛇添足”显然是坏事,会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。 “锦上添花”是好事
17、,可能会让用户获得比期望更多的喜悦,但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求,如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒,应当在产品需求规格说明书中将那些“锦上添花”的需求设置为较低的优先级。手把手教程Project什么是好的需求规格说明书 完备 “完备”(Complete)是指产品需求规格说明书中没有遗漏一些必要的需求。 人们往往倾向于关注系统的特色功能,而忽视了其它一些不起眼的但却是必需的功能。 不完备的产品需求规格说明书将导致产生功能不完整的软件,用户在使用该软件时可能无法完成预期的任务。 手把手教程Project什么是好的需求规格说明书 可实现 产品需
展开阅读全文