• 1.10 MB
  • 2022-04-29 14:33:18 发布

最新重点海洋产业调查课件PPT课件.ppt

  • 93页
  • 当前文档由用户上传发布,收益归属用户
  1. 1、本文档共5页,可阅读全部内容。
  2. 2、本文档内容版权归属内容提供方,所产生的收益全部归内容提供方所有。如果您对本文有版权争议,可选择认领,认领后既往收益都归您。
  3. 3、本文档由用户上传,本站不保证质量和数量令人满意,可能有诸多瑕疵,付费之前,请仔细先通过免费阅读内容等途径辨别内容交易风险。如存在严重挂羊头卖狗肉之情形,可联系本站下载客服投诉处理。
  4. 文档侵权举报电话:19940600175。
'重点海洋产业调查课件 一、海洋经济海洋经济概念是开发、利用和保护海洋的各类产业活动,以及与之相关联活动的总和。海洋生产总值是海洋经济生产总值的简称,指按市场价格计算的沿海地区常住单位在一定时期内海洋经济活动的最终成果,是海洋产业和海洋相关产业增加值之和。 一、海洋经济增加值是指按市场价格计算的常住单位在一定时期内生产与服务活动的最终成果。 一、海洋经济现代海洋产业体系基本建立。现代产业体系不断完善,产业竞争力显著提升,海洋渔业、海洋化工、石油化工等海洋优势产业带动能力明显,海洋生物、海洋能源、海洋新材料等海洋新兴产业规模不断扩大。2008年全省海洋生产总值5346亿元,占全省生产总值的17%,居全国第二位。”十二五”潍坊的目标是海洋主要产业产值占全市地区生产总值的比重约达30%。 二、海洋产业的分类 二、海洋产业的分类产业是国民经济中以社会分工为基础,在产品和劳务的生产经营上具有某些相同特征的企业或单位及其活动的集合,是具有同一属性的经济活动的集合,是国民经济的一个门类,是居于微观经济的细胞与宏观经济单位之间的“集合概念”。海洋产业的概念是开发、利用和保护海洋所进行的生产和服务活动。也可以说是人类开发利用各种海洋资源,发展海洋经济而形成的生产、生活事业,称为海洋产业。 二、海洋产业的分类海洋科研教育管理服务业是开发、利用和保护海洋过程中所进行的科研、教育、管理及服务等活动,包括海洋信息服务业、海洋环境监测预报服务、海洋保险与社会保障业、海洋科学研究、海洋技术服务业、海洋地质勘查业、海洋环境保护业、海洋教育、海洋管理、海洋社会团体与国际组织等。海洋相关产业是指以各种投入产出为联系纽带,与主要海洋产业构成技术经济联系的上下游产业,涉及海洋农林业、海洋设备制造业、涉海产品及材料制造业、涉海建筑与安装业、海洋批发与零售业、涉海服务业等。 二、海洋产业的分类由于研究目标的多样性,就形成了海洋产业分类的多样性,通常有以下几种:第一种分类:根据三次产业分类法,划分为海洋第一产业、第二产业和第三产业,这是较为常用的分类方法。其中,海洋第一产业以直接利用海洋生物资源为特征,即海洋渔业;海洋第二产业以对海洋资源的加工和再加工为特征,主要包括海洋盐业、海洋药物和食品工业、海洋油气业等;海洋第三产业为海洋服务业,其生产活动以提供非物质财富为特征。 二、海洋产业的分类第二种分类:传统的海洋三大产业——海洋渔业、海洋盐业、海洋交通运输业新兴的海洋产业——海洋油气业、海洋旅游业未来的海洋产业——海水淡化业、海洋能利用、海洋药物等 二、海洋产业的分类第三种分类:(两类三层)即根据海洋产业的定义,将海洋产业分为主要海洋产业,海洋科研教育管理服务业和海洋相关产业。1、主要海洋产业(核心层)2、海洋科研教育管理服务业(支持层)3、海洋相关产业(外围层) 二、海洋产业的分类海洋及相关产业共分两类:海洋产业(A)、海洋相关产业(B)。主要表现在五个方面:①直接从海洋中获取产品的生产和服务活动。如:海产品养殖、海洋捕捞、海洋石油开采、海洋矿产开采、海水制盐等等。②直接从海洋中获取的产品的一次加工生产和服务活动。如:水产品加工、海盐加工、海洋化工、海洋医药等等。 二、海洋产业的分类③直接应用于海洋和海洋开发活动的产品生产和服务活动。如:海洋船舶制造、海洋建筑等等。④利用海水或海洋空间作为生产过程的基本要素所进行的生产和服务活动。如:海水利用、海洋发电、海洋交通运输、滨海旅游等等⑤海洋科学研究、教育、管理和服务活动。 二、海洋产业的分类重点理解海洋相关产业:一是为海洋产业活动提供的产品生产和服务活动。如为各种海洋产业活动提供的机械、设备、零部件制造,海洋产业生产产品的销售,海洋金融服务等等都属此类,这个比较好理解。二是对海洋产业活动的产品(海洋化工产品为原料)进行再加工的生产和服务活动。如:261海洋渔业相关产品制造、262海洋石油加工产品制造、263海洋化工产品制造等。 二、海洋产业的分类---主要海洋产业海洋渔业:包括海水养殖、海洋捕捞、海洋渔业服务业和海洋水产品加工等活动。山东省海洋渔业增加值占全国海洋渔业增加值比重32.6%,继续位居全国第一。海洋油气业:是指在海洋中勘探、开采、输送、加工原油和天然气的生产活动。天津市海洋油气业增加值占全国海洋油气业增加值比重45.5%,位居全国第一。海洋矿业:包括海滨砂矿、海滨土砂石、海滨地热、煤矿开采和深海采矿等采选活动。海洋盐业: 是指利用海水生产以氯化钠为主要成分的盐产品的活动,包括采盐和盐加工。 二、海洋产业的分类---主要海洋产业海洋化工业:包括海盐化工、海水化工、海藻化工及海洋石油化工的化工产品生产活动。海洋生物医药业:是指以海洋生物为原料或提取有效成分,进行海洋药品与海洋保健品的生产加工及制造活动。浙江省海洋生物医药业增加值占全国海洋生物医药业增加值比重37.3%,位居全国第一。海洋电力业:是指在沿海地区利用海洋能、海洋风能进行的电力生产活动。不包括沿海地区的火力发电和核力发电。海水利用业:是指对海水的直接利用和海水淡化活动。 二、海洋产业的分类---主要海洋产业海洋船舶工业:是指以金属或非金属为主要材料,制造海洋船舶、海上固定及浮动装置的活动,以及对海洋船舶的修理及拆卸活动海洋工程建筑业:是指在海上、海底和海岸所进行的用于海洋生产、交通、娱乐、防护等用途的建筑工程施工及其准备活动,包括海港建筑、滨海电站建筑、海岸堤坝建筑、海洋隧道桥梁建筑、海上油气田陆地终端及处理设施建造、海底线路管道和设备安装,不包括各部门、各地区的房屋建筑及房屋装修工程。 二、海洋产业的分类---主要海洋产业海洋交通运输业:是指以船舶为主要工具从事海洋运输以及为海洋运输提供服务的活动,包括远洋旅客运输、沿海旅客运输、远洋货物运输、沿海货物运输、水上运输辅助活动、管道运输业、装卸搬运及其他运输服务活动。滨海旅游业:包括以海岸带、海岛及海洋各种自然景观、人文景观为依托的旅游经营、服务活动。主要包括:海洋观光游览、休闲娱乐、度假住宿、体育运动等活动。上海市滨海旅游业增加值占全国滨海旅游业增加值比重24.0%,位居全国第一。 二、海洋产业的分类海洋及相关产业分类国家标准(29个大类,106个种类,390个小类)与国民经济行业分类的对照 三、重点海洋产业调查 三、重点海洋产业调查1、调查对象:对规模以上工业企业、资质建筑业企业、限额以上批发零售贸易企业(称“三上”企业)调查对象的产业布局 三、重点海洋产业调查第二产业制造业(5个产业规模上企业)海洋生物产业海洋装备制造业海洋能源矿产业现代海洋化工产业海洋水产品精深加工业建筑业(资质建筑企业)海洋工程建筑业第三产业批发零售贸易业(全部限额上企业)涉海批发零售贸易企业 三、重点海洋产业调查什么是海洋产业和海洋相关产业活动确定清楚了,那么海洋产业和海洋相关产业活动的产品和服务我们就确定清楚了,把这种海洋产业和海洋相关产业产品和服务实现的营业收入加总就是涉海的营业收入。 三、重点海洋产业调查1、下面举一个例子:06海洋化工业263海洋化工产品制造061海盐工业2631海洋化工专用产品制造0611氯化钾制造2632海洋化工日用产品制造0612氯化镁制造2633海洋有机化学产品制造0613氯碱产品制造2634氮肥制造0614纯碱制造2635钾肥制造 三、重点海洋产业调查一个是海洋产业,一个是海洋相关产业,大家对照说明注意区别,不要弄反了。很可能一个企业两类产品都生产,除在产业分类上界定清楚以外,还要注意这两类的产品都属涉海的产品,在计算涉海收入时都要加总在一起。类似的还有064海洋石油化工和262海洋石油加工产品制造 三、重点海洋产业调查2、确定企业单位海洋及相关产业性质的基本原则在划分海洋及相关产业类别时,一个企业单位的行业性质是根据该企业单位所从事的海洋经济活动确定的。如果一个单位从事两种或两种以上的海洋经济活动,则按主要活动确定产业分类。什么是主要活动呢? 三、重点海洋产业调查主要活动:当一个企业单位对外从事两种或两种以上的海洋经济活动时,占其企业单位增加值份额最大的一种活动为主要活动。在实际工作中,有些活动的增加值份额较难确定,则可依次按全年营业收入、从业人员确定企业单位的主要活动。 三、重点海洋产业调查3、注意事项对规模以上工业企业、资质建筑业企业、限额以上批发零售贸易企业(下称“三上”企业)在市局返回字典库的基础上,认真对字典库进行整理,凡是有涉海经营活动的“三上”企业有遗漏的,及时予以补充;各县市区及开发区在组织人员填报海洋产业代码时,要反复核对企业的业务活动开展情况,要掌握判断主要业务活动的方式与方法; 三、重点海洋产业调查在审核企业主要经济指标时,尤其要注意对涉海指标的审核评估;各填报企业不得有代填代报现象,指标上报齐全,填报要规范,报表要存档待查。 三、重点海洋产业调查4、调查表式(详见报表)注意:带*号指标批发零售贸易企业不填报,“研究开发费用”建筑企业不填报。07海洋产业类别中的主要海洋业务活动(或主要产品)和海洋产业代码参见海洋及相关产业分类。 三、重点海洋产业调查这次调查采用全面登记的调查方法,9月2日前蓝办、统计局召开培训会议、部署调查任务;各县市区及开发区蓝办和统计部门于9月10日前,完成对相关企业的业务培训并组织填写调查表;9月16日前完成数据录入,形成调查报告,连同基层数据一起上报市统计局农调队;9月20日前市局审核汇总调查数据,形成调查报告,上报省发改委(蓝办)、省统计局。 谢谢! 第九章系统开发中的需求分析与管理一、需求工程概述二、需求开发三、需求管理四、需求工程方法与工具 一、需求工程概述用户需求产品需求系统设计系统实现单元测试集成测试系统测试验收测试 一、需求工程概述1、什么是需求基本概念:宽泛地讲,需求来源于用户的一些“需要”,这些“需要”被分析、确认后形成完整的文档,该文档详细地说明了产品“必须或应当”做什么。需求可能来自以下几个方面:用户(客户)、接口、环境(硬件、组织文化、政策等)。需求的重要性:开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求,包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错,将会给系统带来极大的损害,并且以后对它修改也极为困难。(Brooks:《没有银弹》) 案例——凭空想象的需求一家大型电信设备企业有多个分支机构,A与B是研发机构,B是核心平台的研发机制,A做增值业务的研发,C是整个公司的项目管理机构,负责立项、结项与经费管理,D是销售机构。B研制出一种数据接入服务器的原型,找到A,说该产品市场前景看好,请你们开发网管软件,一起做好产品。D对A,B说“你们把软硬件都做好,我负责销售,挣到钱大家分”。于是A决定参与合作,向C提出立项,立项后,A把该项目外包给一家专业的网管软件开发公司E,预期半年完成。由于网管软件要运行于B的产品上,A与E派出开发人员到B处进行需求分析,而B的产品还是原型并不成熟,不断在变化,最终用了1年时间才完成软件开发。开发完成后,E将软件交付给A后,A付清开发费用,再把软件交付到D,D又卖给某电信局F,结果F对软件的功能不满意,要求按自己的要求修改后才能付钱。D不得不要求A修改软件,而A已经将开发费用付给了E,只能自己吞苦果,结果是A想办法把软件转让给B,希望拿出成本并且以后再也不与B合作。——这在很多大企业中都是普遍发生的事实。产品是闭门造车出来的,根本没有弄清楚要开发的系统应该是什么样的。 一、需求工程概述2、系统需求的来源1)客户:购买系统的人。2)用户:实际使用系统进行日常业务活动的人。3)技术人员:维护系统运行的人。4)其他系统相关者。 一、需求工程概述3、需求工程1)基本概念:在软件开发的生命周期中,与需求直接相关的活动。主要包括:需求开发和需求管理两部分内容。 一、需求工程概述3、需求工程需求开发过程:通过调查与分析,获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息(原始材料),产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。需求定义的目的是根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。 一、需求工程概述3、需求工程需求管理过程:在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审,双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更,防止需求变更失去控制而导致项目发生混乱。 一、需求工程概述3、需求工程2)需求工程的主要内容:需求开发产生的主要文档为《用户需求说明书》与《软件需求规格说明书》。需求管理产生的主要文档为《需求评审报告》、《需求跟踪报告》和《需求变更控制报告》 一、需求工程概述4、需求工程中的主要问题知识技能问题态度问题合作关系用户说不清楚需求双方误解需求开发人员写不好需求文档用户经常变更需求 知识技能问题应用域的知识是无边无际的,任何人都不可能是“万事通”。俗话说“隔行如隔山”,需求分析员可能是某一领域的专家,但当他接手陌生的业务时,他可能是个“无知”者。一个企业要谋求发展,不能总在做老的业务。人一生中会有许多充满挫折的“第一次”,不可以逃避。当需求分析员缺乏应用域知识时,他该怎么办?–首先要有勇气做事,否则连实践的机会都没有。–其次应当赶紧补习应用域知识,不论是通过自学还是培训的方式,否则他很难与用户交流。如果可能的话,开发方最好请既懂软件又懂应用域知识的行家来帮忙。 态度问题相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时,他们会发牢骚,找出一堆用户的毛病。很多开发人员错误地以为:需求是用户的事情,不是我们的事情。我们为用户开发软件,难道用户不该告诉我们应当开发什么吗?如果用户说不清楚需求,或者经常变更需求,这类问题是用户产生的,应当由他们自己负责。用户说不清楚需求或者需求发生变更,这些都是常见的问题,并不是绝症,是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口,不愿主动攻克问题,导致需求问题扩散到整个软件开发过程,产生太多的后患。软件企业的领导应当给具有错误观念的开发人员们洗脑:需求分析员的天职就是在有限的时间内获取准确而细致的用户需求,如果做不到就是失职,不要找借口。 合作关系如果需求分析员不能与用户建立良好的合作关系,那么他们在需求开发过程中会很疲惫。倘若用户不能很好地配合需求分析员,那并不表示他是个坏蛋。因为用户有他自己的想法:我回答了你们的问题,讲了该讲的。我们付钱给你们,难道还要我伺候你们不成?我还要干自己的事情,别打扰我了。你们自己想办法把活干好吧 ……。对于一些竞标项目,在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品,他不会投入很多精力来协助你搞需求开发。需求分析员不是销售人员,他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识,还要具备较强的交流、沟通能力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目,我们不能完全期望双方能够自发地建立起良好地合作关系,这样风险太大。开发方和用户方在开展需求开发之前,双方协商并撰写“用户在需求工程中的权利与义务”,即以协议的方式确定合作关系。“好话”和“丑话”都说在前头,这样能减少今后的摩擦。如果条件允许的话,开发方最好为用户举办关于需求工程的培训 合作关系用户在需求工程中的“权利”–1.有权要求开发方派遣资质合格的需求分析员和相关人员。–2.有权要求开发方采用用户熟悉的语言来描述需求,即开发方必须提供用户看得懂得需求文档。–3.有权审查需求文档,并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿,可以拒绝在需求文档上签字。–4.如果用户想要变更需求,有权要求开发方对该变更将产生的影响作出真实可信的评估,以便用户决定是否变更需求。用户在需求工程中的“义务”–1.以积极友善的态度与开发方人员交流、协作,尽可能地为开发方人员提供工作和生活上的便利。–2.乐意接受需求分析员的采访,在不泄漏机密的前提下尽可能地回答需求分析员的问题。–3.在不泄漏机密的前提下,尽可能地向需求分析员提供与需求相关的材料。–4.与需求分析员共同评审需求文档,确保需求文档准确地反映用户真实的意愿。 用户说不清楚需求用户说不清楚需求是普遍现象,这是让开发人员头痛的大问题。有些用户真的不知道需求是什么,或者对需求只有朦胧的感觉,他当然说不清楚需求。有些用户虽然心里明白想要什么,但却说不清楚需求。系统分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作,否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求,系统分析员必须设法搞清楚用户真正的需求,这是系统分析员的职责,也是职业的挑战。 双方误解需求了解需求的过程中会发生“问非所求,答非所问”的事情。 开发人员写不好需求文档需求调查工作不充分,获取的需求信息太少或者太乱,以至于写不成需求文档。要想写出好的需求文档,前提条件是把需求调查工作做好。企业应当提供合适的文档模板以及比较好的示例文档,尽可能地降低写作难度。 用户经常变更需求需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段,开发人员和用户没有搞清楚需求或者搞错了需求,到了项目开发后期才将需求纠正过来,导致产品的部分内容需要重新开发。毫无疑问,这种需求变更将使项目付出额外的代价。需求变更并不可怕,可怕的是需求变更失去控制,导致项目混乱。所以需求变更控制是需求工程的重要活动。 用户经常变更需求需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段,开发人员和用户没有搞清楚需求或者搞错了需求,到了项目开发后期才将需求纠正过来,导致产品的部分内容需要重新开发。毫无疑问,这种需求变更将使项目付出额外的代价。需求变更并不可怕,可怕的是需求变更失去控制,导致项目混乱。所以需求变更控制是需求工程的重要活动。 一、需求工程概述5、需求工程的层次开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种,只有后两种才有可能开发出成功的产品。–“被动型”是指开发者被动地对待需求工程中的各项活动,能少干则少干,能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更,导致产品迷失方向,不是半途而废就是陷入半死不活的状态。–“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责,会想尽一切办法克服需求开发和需求管理过程中的困难,而不是找借口推卸责任。俗话说“良好的开端是成功的一半”,“主动型”需求工程是开发成功产品的必备条件。–“领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求,导致用户跟着新产品跑而不是新产品围着用户转,这叫引导消费。需求工程做到这个份上,才能使产品立于不败之地,长盛不衰。 二、需求开发1、需求的获取一般地,分析员首先要通过与用户面谈、问卷调查等方式获取需求,通过对这些需求进行记录与定义并进行讨论与修正,将未解决的问题放在一个条目中,等下一次调查解决。通过多次迭代最终得到完整的系统需求。1)需求获取规程现代软件系统分析与开发一般都遵循一定的范式和规程。在需求调查阶段,一般按以下规程进行: 目的获取用户的需求信息,经过分析产生《用户需求说明书》角色与职责系统分析员调查分析需求,用户提供必要的需求信息启动准则系统分析员已经确定输入任何与用户需求相关的材料主要步骤1.准备调查2.调查与记录3.分析需求信息4.撰写《用户需求说明书》5.需求确认输出《用户需求说明书》结束准则完成《用户需求说明书》并确认无误度量统计工作量和文档规模,上报项目经理 二、需求开发1、需求的获取2)调查准备(1)需求分析员应当起草需求调查问题表,将调查重点锁定在该问题表内,否则调查工作将变得漫无边际。问题表可以有多份,随着调查的深入,问题表将不断地被细化。根据经验,用户通常没有耐心回答复杂的论述题,所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。 二、需求开发1、需求的获取2)调查准备(2)确定调查方式,调查的方法有:问卷调查复查现有报表和业务过程的描述与用户面谈与讨论观察与记录业务过程与同行或专家交谈,听取意见与建议分析已经存在的软件系统,提取需求从行业标准和规则中提取需求到Internet上查找相关信息 二、需求开发1、需求的获取2)调查准备(2)确定调查方式,辅助调查的方法有:可通过原型的方法获取需求,这对于“说不出需求”的用户尤其适用。JAD(联合应用开发会议)是加快调查的重要方法,即将相关人员全部召集在一起参加单一会议直接解决需求分析问题。 二、需求开发1、需求的获取2)调查准备(3)需求分析员与被调查者建立联系,确定调查的时间、地点、人员等,撰写需求调查计划。要特别留意的是不要漏掉典型的用户。 二、需求开发1、需求的获取3)调查与记录准备工作完毕后,需求分析员按照计划执行调查。在调查过程中随时记录(或存储)需求信息。通过完成计划的调查任务,系统分析员获取用户需求并将其正确的记录。记录形式一般为表格需求标题调查方式调查人调查对象时间、地点需求信息记录是什么?不是什么?为什么? 二、需求开发1、需求的获取3)调查与记录面谈中要注意的问题:注重时间与礼节,建立与用户的良好关系事先了解用户的身份、背景从宏观入手,然后细化,而不是象侦探那样从蛛丝马迹着手轻松的气氛,不轻意打断用户的谈话不为用户添加必要的麻烦,但也不要因怕麻烦而降低调查力度 二、需求开发1、需求的获取3)调查与记录调查的技术——问答分析法:通过提问与回答了解系统需求。最主要的问题是:“是什么”和“为什么”。每个需求都用陈述句说明“是什么”,如果表达不清,则加上“不是什么”;如果“是”与“不是”不是理所当然的,就必须加上解释“为什么”——目标:获得正确、清晰的需求。其他常见问题:需求存在二义性吗?需求文档的上下文有矛盾吗?需求完备吗?需求是必要的吗?需求可实现吗?需求可验证吗?需求的优先级确定了吗? 二、需求开发2、需求冲突的解决需求从获取渠道收集到以后,可能产生不一致的地方。解决原则主要有:当客户需求与开发方预计需求冲突时,以客户需求为主。用户间需求冲突则以级别大的用户需求为准,同级则少数服从多数。多个客户以出钱多的客户需求为准 二、需求开发3、用户需求说明书对收集到的用户需求进行分析、归纳与总结,然后根据一定的格式撰写《用户需求说明书》,调查过程中的中间资料可作为附件。用户需求说明书完成后,应邀请专家与用户对其进行评审,使其最大限度地符合用户的真实意愿。之后才能进行进一步的需求分析与定义,产生《软件需求规格说明书。》 (模板) 二、需求开发4、需求分析与定义1)概述需求分析的结果是通过建立系统的逻辑模型来定义需求。逻辑模型:详细展示系统要完成的功能,而不依赖具体技术的模型。物理模型:表明系统是如何真正实现的模型。 二、需求开发4、需求分析与定义1)概述结构化分析方法兴盛的时期,软件系统的开发过程是从物理模型到逻辑模型,再从逻辑模型到新的物理模型的过程。这种方法可以保证系统分析能按步就班的完成,但缺点是a)系统分析时间较长,要花费更多时间与资金去分析、了解和记录旧系统的运行,提炼出运行逻辑。b)新系统往往是旧系统的简单自动化,不论原系统的效率有多低,是否合理,都原样地进入新系统,并不能通过信息化改造原来的业务管理流程,提高管理水平。不适合于全新系统的开发,特别是一些WEB项目,如电子商务方面的项目开发,这些项目没有可参考的旧系统。 二、需求开发4、需求分析与定义1)概述现代的需求分析过程,往往是直接在对用户需求进行收集地过程中直接产生新系统的逻辑模型(直接通过对比要解决的商业问题和软件需要实现的功能)。系统分析员只有在需要理解商业业务流程时才去检查现有系统。系统分析员的焦点是:以新系统为中心。提出创新的问题解决之道是系统分析员的素质要求之一。此外,新系统的引入还可能对组织原来的业务流程进行改造——BPR。两种思维方式:还没有坏,就不需要修理总有一种更好的解决方法 案例——Ford的业务流程重组20世纪80年代,福特北美分部的帐目支付部门雇佣了500多名员工。为了提高效率,公司决定引入信息系统,最初的目标是提高20%的效率。在项目小组进行系统分析时发现,马自达公司的帐目支付部门只有5名员工。虽然福特比马自达大得多,但相对于而言也达不到100倍的业务量。在借鉴了马自达的业务过程的同时,项目组设计了全新的自动化系统,将帐目支付功能包含在更大的购买功能中,实现了从购买到支付全程跟踪的自动化,项目结束时,只需求100人即可完成原来500多人才能完成的帐目支付功能,大大超出了预计。 二、需求开发4、需求分析与定义2)系统分析规程目的定义准确的产品需求,产生《产品需求规格说明书》角色与职责系统分析员定义产品需求,用户确认产品需求启动准则《用户需求说明书》撰写完成输入《用户需求说明书》主要步骤1.细化和分析用户需求2.撰写《产品需求规格说明书》3.需求确认输出《产品需求规格说明书》结束准则《产品需求规格说明书》撰写完成并通过确认(评审与承诺)度量系统分析员统计工作量与文档规模,上报项目经理 二、需求开发4、需求分析与定义2)系统分析规程第一步:细化并分析用户需求–需求分析员首先对《用户需求说明书》进行细化,对比较复杂的用户需求进行建模分析,以帮助软件开发人员更好地理解需求。建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明:建模分析的技术难度比较高,分析员应当根据自身水平进行取舍。第二步:撰写产品需求规格说明书–需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话,则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。第三步:进行需求确认–项目经理邀请同行专家和用户(包括客户和最终用户)一起评审《产品需求规格说明书》,尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。–需求评审之后,开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。 二、需求开发4、需求分析与定义3)需求分析方法文字描述(可从问答法直接获得)模型描述有些时候用语言描述某个问题特别费劲,而采用图形则使人一目了然,所谓“一图低千言”就是这个道理。在需求开发过程中,对于某些类型的信息,用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。因此在需求分析中常使用建模的方法来定义需求。 二、需求开发4、需求分析与定义3)需求分析方法模型描述(1)需求建模:就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类:“结构化分析法”和“面向对象分析法”。 二、需求开发4、需求分析与定义3)需求分析方法模型描述(2)结构化分析法结构化分析方法并不是明确地由涉及这个主题的一篇文章或者一本著作引入的,它也不是被所有使用者一致采用的单一方法。相反地,它是几乎发展了20多年的一个混合物。结构化分析方法在70年代和80年代非常流行,相关论著很多。Pressmen对结构化分析方法作了高度概括——“一个中心三种图”: 数据字典实体-关系图数据流图状态-变迁图 二、需求开发4、需求分析与定义3)需求分析方法模型描述(3)面向对象分析法面向对象分析设计(OOAD)方法兴起于20世纪80年代,从90年代起至今它已经在分析设计领域占据了无可争议的主流地位。面向对象分析设计领域有一些比较著名的学派,如:lCoad和Yourdon学派。lBooch学派。lJocobson学派。lRumbaugh学派。UMLRationalRose 二、需求开发4、需求分析与定义3)需求分析方法模型描述(4)建模原则——恰当地使用图形符号现代建模工具如Rose有非常丰富的图形符号和文字标注,能很好地表达模型的细节。要注意的是:在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化,将使开发人员更难掌握,而且使图形文档更加杂乱。–世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中,文字描述是第一重要的,建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中,便于正文引用。 二、需求开发5、产品需求规格说明书1)《用户需求说明书》与《产品需求规格说明书》的主要区别与联系前者主要采用自然语言(和应用域术语)来表达用户需求,其内容相对于后者而言比较粗略,不够详细。后者是前者的细化,更多地采用计算机语言和图形符号来刻画需求,产品需求是软件系统设计的直接依据。两者之间可能并不存在一一影射关系,因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求,例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。 二、需求开发5、产品需求规格说明书2)应按一定规范书写 (模板) 二、需求开发5、产品需求规格说明书3)书写原则(1)正确(2)清楚(3)无二义性(4)一致(5)必要(6)完备(7)可实现(8)可验证(9)确定优先级(10)阐述“做什么”而不是“怎么做” 三、需求管理1、需求验证系统分析员往往认为他们了解与掌握了用户的需求,然而却没有真正把握商业过程的最精妙之处。在项目早期发现和解决这方面的问题,比到了开发与实现阶段解决的代价要小百倍。发现和解决需求分析问题的手段是需求验证。类似于房屋建造,需求分析相当于设计蓝图,在进行设计时可能会存在问题,如果在正式建造前不加以解决可能导致完全的失败,在建造之前首先要验证图纸的正确性。 三、需求管理1、需求验证1)需求验证过程需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审,双方对需求达成共识后作出承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”。 三、需求管理1、需求验证2)需求评审要注意的问题:l需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味,也比较费脑子。刚开始评审时,大家都比较认真,越到后头越马虎。主持人应当控制节奏,将重要内容放在前面。l需求评审涉及的人员可能比较多,有些时候让这么多人聚在一起花费比较长的时间开会并不容易(例如有些人可能出差在外,有些人可能事务缠身)。没有必要把所有事情挤在一块做,需求开发是循序渐进的过程,需求评审也可以分段进行。这样每次评审的时间比较短,参加评审的人员也少一些,组织会议就比较容易。l开评审会议时经常会“跑题”,导致评审效率很低。有时话匣子一打开后关不上,大家越扯越远,结果评审会议变成了聊天会议。主持人应当控制话题,避免大家讨论与主题无关的东西。l开评审会议时经常会发生争议。适当的争议有利于澄清问题,比什么东西都一致赞成要好。控制争议不变为争吵,争吵不仅对评审工作没有好处,而且会无意中伤害同事间及与客户的关系,影响项目组下一步的工作。人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯:不要一棍子打死异己的观点,尝试着让自己站在他人的立场思考问题,这样你会找到比较满意的答案。 三、需求管理1、需求验证3)需求承诺需求承诺是指开发方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺,该承诺具有商业合同的效果。本《产品需求规格说明书》建立在双方对需求的共同理解基础之上,我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化,我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。甲方签字乙方签字人们在作出承诺之前务必要认真阅读文档,一定要明白签字意味着什么。 三、需求管理2、需求验证需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求。需求跟踪有两种方式:–正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。–逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。–正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。 三、需求管理3、需求变更管理1)需求发生变更的起因:–随着项目的进展,人们(包括开发方和客户方)对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足,因此要变更需求。–市场发生了变化,原先的需求文档可能跟不上当前的市场需求,因此要变更需求。“没有软件系统开发中用户需求的变化不超过3次”? 三、需求管理3、需求变更管理2)需求变更管理:提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。对项目开发小组而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话,这个项目也许永远不能按时完成。需求变更控制的目的:如果需求变更带来的好处大于坏处,那么允许变更,但必须按照已定义的变更规程执行,以免变更失去控制。如果需求变更带来的坏处大于好处,那么拒绝变更。需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的,但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”:-开发方与客户方达成“事不过三”的约定(符合中国人的习惯),即允许客户变更三次需求;如果客户第四此变更需求,开发方有权拒绝,除非客户愿意补偿开发方的损失。-如果事先没有“游戏规则”的话,开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。 四、需求工程的技术与工具'