本篇文章给大家谈谈信息系统项目范围管理，以及软件项目范围管理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
1.蒙托卡罗模拟技术
蒙托卡罗模拟技术是项目风险管理——不确定性分析技术。由于项目中许多因素是变化的，不能用一个固定的值来描述，例如，在软件开发项目中，开发某个子程序到底需要多长时间，一般来说，不能用一个定值(例如20天)描述，但是根据经验，往往可以给出一个范围，例如18-23天。问题是，如果在一个项目中有多个因素都是具有不确定性，如何计算结果呢。这就是蒙托卡罗模拟技术所要做的。本技术中的主要内容包括：
描述不确定性风险因素的方法
如何建立项目模型
抽样技术
数据分析技术
敏感性分析等
2.决策树技术
决策树技术也是项目风险管理中的技术，它是在具有多种方案中如何进行选择决策时使用的。本技术中的主要内容包括：
如何构造决策树
决策点
方案枝
状态点
概率枝
单级(阶)决策树
多级(阶)决策树
3.项目进展评价技术
由于项目中有许多任务组成，在项目进行到一定阶段后就会发现，有些任务工期缩短了，有些加长了;有些任务超出了预算，有些低于预算。如何从整体上评价进展呢?这就是本技术中要讨论的问题。本技术中的主要内容包括：
流逝时间评价法
工期评价法
工时评价法
挣得值法(重点讲述)
4.关键路径法技术
关键路径法是项目时间管理中的技术，简称CPM。它是把完成任务需要进行的工作进行分解，估计每个任务的工期，然后在任务间建立相关性，形成一个“网络”，通过网络计算，找到最长的'路径(主要矛盾)，再进行优化。本技术的主要内容有：
项目目标确定与时间、成本、资源的综合权衡
工作分解结构建立
工期估算影响因素
正向计算
反向计算
时差计算等
5.WBS、OBS、CBS、PBS分解技术
WBS是项目范围管理中的技术，它是确定项目范围的一种主要技术，也是进行成本、资源的估算的基础。本技术的主要内容包括：
分解原则
工作分解结构
组织分解结构
成本分解结构
产品分解结构
6.关键因素分析技术
关键因素分析是质量管理中使用的技术，也称为帕累托法则。它是把质量的缺陷进行归类统计，分析每种引起质量原因所造成不良质量成本，然后找到影响最大的几个予以解决，即“解决20%的因素，得到80%的效益”，有名的二、八理论，80~20原则。
7.用代码行、功能点、人工量进行时间等估算的技术
这是属于软件开发中使用的一项技术。使用这些技术可以估算软件开发项目的时间、人工量，成本等。这个技术的主要内容包括：
代码行估算开发的最短工期、高效工期、正常工期的原理和方法
用功能点估算原理和方法
用人工量估算原理和方法
自底向上估算法
各种估算方法比较
8.项目管理可视化技术
项目管理的不可见属性，为项目团队的沟通、控制带来了很大的障碍。本技术将介绍，如何把项目的进度、成本、风险、质量可视化的方法。
一个项目管理信息系统需要通过项目或者组织的需求来赋予它孕育容量的多少。但是话又说回来，这个系统是否能够按照项目组成员的需求实现所有的功能呢？不一定，以Microsoft Project为平台部署的EPM企业解决方案中，这样一个系统的出现，也并不能满足所有企业或者项目的需求，也可能需要实现二次开发来满足。即一个项目管理信息系统是否能够实现一个组织的所有需求，也是需要考虑的问题。很多企业部署了庞大的系统，但在项目的应用中只能得到部分有价值的、可实现的功能。这样的情况称为项目管理信息系统的可实现功能。你所需求的功能，信息系统要能够实现。
一、项目可行性研究 在一定的组织里，没有完成项目可行性研究，一个项目一般不会正式启动。很多公司在进行项目可行性研究时会出现很多问题，如：研究深度不够，质量不高，不能满足决策的需要；不重视多方案论证和比较，无法进行优选；调查研究得不够，导致项目投资收益计算失真；可行性研究报告的编制缺乏独立性、公正性和客观性；等等。对此，首先我们要正确认识可行性研究的阶段划分与功能定位。其次，按要求进行可行性研究，正确确定其依据。第三，采用科学的方法与先进的技术。第四，建立科学的决策体系和管理机制。 二、项目启动阶段 项目启动阶段需要界定工作目标及工作任务；获得老板或高层的支持；组建优秀的项目团队；准备充足的资源；建立良好的沟通；对客户的积极反应进行适当的监控和反馈。 项目管理最重要、最难做的工作就是界定工作目标及工作任务，也就是确定项目的范围。缺少正确的项目范围定义和核实，是项目失败的主要原因。通过和项目干系人在项目要产出什么样的产品方面达成的共识、产品描述、战略计划、项目选择标准等方面的信息利用项目选择方法和专家判断输出项目的正式审批文件，也就是项目章程。
项目经理关键在于对老板，对客户，对合作伙伴，团队成员的沟通把握好"度"。以下是我的几点积累，如有不妥之处，烦请指正。 一、让老板知道，信息系统的项目是比较独特的、渐进的，是项较复杂的工程 信息系统项目,它不是硬件产品。具有相对可见的、固定的属性。正因为它的可定制性强，才具有活力。一旦接触，就要作好打持久战的准备，公司所有资源要优先供项目组利用。项目推迟验收，客户需求频繁变更也是一个重大原因。 一个公司的成功与否，很大程度上取决于对项目的 管理是否得当。 二、作好项目范围和项目目标控制 项目范围一定要用规范的文档描述。客户大多是用口头描述他们心中所想，而且是相当临散的,尤其是政务项目，他们可能写公文很在行，但是要他把需求用文字有条理的表达出来。一句话很难，就算他们提出来了,也已经是几周之后了。 再者项目范围不清晰，随着项目的进展,项目组所有人员的工作热情很容易被拖垮，双方都觉得项目越作越大，严重超出开始的范围、超出计划完成日期。今天这个功能不完善,明天那个要细化。日子一久，开发工程师都有点怀疑自己的能力了。最好是注明是第几期工程，项目范围和目标提出来了，同时在文档中注明，如超出此项目范围的作何处理。 一定要客户方使用的业务科室和客户领导签字。或许有这种情况出现，客户方有推脱的理由不方便签字，那么请说服他，这是公司的项目流程和规定。 三、严格控制客户需求变更，告诉他并不是所有的变更都必须实现和能实现 客户是上帝,不可否认。项目最终是给客户方使用的。我们是否发现，有时客户提的需求有点奇异，有点脱离实际,或者说暂且实现成本很大。那么你要坚定些，告诉他们.如按照他所做会如何如何,会带来有成本、进度、质量相关实际的问题。给他们这样的感觉，我们是系统解决方案提供者，关注的全局的,关键性的，必要性问题的解决。何况微软还有补丁呢？ 对他们的需求我们实行的方针是:"全部记录，全部评估和控制，部分实施，全部验收" 四、要让客户提供相关的负责人，整些必须的"整"事情 在实际中，有些客户只知道把想要的东西说出来，然后要求完成日期，到时候要用上。之后好象与他无关。客户方很可能是业务科室的工作人员, 毕竟他们有自己的日常工作。 那么，勇敢地告诉他，在上次项目启动会议上，他们领导已发表了他在项目中的职责。并告知他你的实际工作难处。相信他很难再犹豫和推脱了。 五、让开发工程师"走出去",充分理解调研，面对客户沟通 千万不要认为，调研是浪费时间，调研如果方便的话，带上女同事(嘿....嘿....别小看女同事哦)和开发工程师。我不赞成，调研人员中只有项目经理和需求分析人员两种角色。调研中的问题，要生成分析报告。并能根据调研内容，迅速提出重点和难点,及关键性的问题。这样开发工程师是会将大部分精力放在重点模块上，会更好地细化关键性的模块。 我们每个人的理解不一样,开发工程师更关注的编码的技巧和功能的实现。开发工程师代表，参与调研可以很好地保证调研是指导开发，更好地的避免出现业务需求和开发脱节。再者让他们切实感觉用户的所说，所想。让他们也了解下原来有时客户需求表达的不清晰和多变性。平时并不是需求分析人员和调研员故意为难开发工程师。这样比你天天喊提高产品质量,站在用户角度换位思考强多了。 六、作好实施准备，先"跑"为"赢" 系统好了，要人用呀，相信只有用了，才能体现系统的价值和公司的信誉度。也只有系统用了，才能体现你作为项目经理的价值。因此要想法设法，尽一切可能让客户先把数据采集上来。数据上来了， 主动权就掌握在咱手里了。之后的种种修改，不再是系统的功能不完善了。更重要的是公司里，老板会认为你之前所作的各种变更和修改是有意义的。切莫要把所有功能都细化，抱着等先完善好了，再上线采集数据的心态。这样成功的可能性很小， 甚至有可能直到你离开之日，系统功能还在作差不多的修改，里面却因没有客户的业务数据作支撑而变得毫无意义。 很多不大不小的项目，缺少实施方法论。我见过很多软件公司。就只有业务员和软件工程师两中角色，没有专门的实施工程师。可能项目小不觉得，项目稍上一点规模，问题就暴露了。俗话说"三分开发，七分实施"呀。 建议当系统大部分功能经过测试就可以了，先跑起来吧。一些小修改，非关键性目标的，在"跑后"再作为升级处理。这样即使某些功能不够细化,你能可以放心的对客户和老板说项目达到预期目标了，甚至可以说成功了。 七、关于在开发过程中的用户征求意见会议 项目经理或开发公司方负责人一定要掌握会议进展的主动权。但凡有客户方参加的项目会议，介绍完系统之后，客户方领导往往会发表意见，有的是与系统功能有关，有的可能是涉及客户方各职能部门的管理机制，工作流程，甚至是工作上的繁琐。连春晚都众口难调呀。记住,跑题了，及时把话题拉回来, 在这些发表意见中不排除有阻碍项目者的高论。 会议不能太长,凡是与信息系统有关的会议,主题切莫离开中心思想"你们开发的系统是什么,能为他们干什么，是怎么体现和优化他们实际的业务流程"勿需太多地用演示帐户，操作开发的信息系统。他们讨论的时间不能太长（控制在四十分钟左右）。会议结束后，要第一时间内整理出会议报告，最好是开会时，有专人现场作Word文档。现场签完名后，才让他们拍屁股走人。 会议记录之后，回到公司召集项目组所有成员及客户方的支持者，对会议记录中相关问题作出评估和控制，最后生产客户需求变更评估和控制文档。 存档(三份,一份交于客户确认，一份交于公司商务部，当然自己得留份底。到时候老板过问进度，也好有个交代呀)。
九大管理共包含5大过程组44个过程：启动过程组2个，计划过程组22个，执行过程组6个，监督与控制过程组12个，收尾过程组2个。
九大管理快速记忆口诀：（饭食盛至人狗踩风筝563344667），
（饭）范围管理（5个过程：计划过程组3个：范围规划，范围定义，建立WBS；监督与控制过程组2个：范围验证，范围控制。）
（食）时间管理（6个过程：计划过程组5个：活动时间定义，活动时间排序，活动资源估算，活动历时估算，制定进度计划；监督与控制过程组1个：进度控制）
（盛）成本管理（3个过程：计划过程组2个：成本估算，成本预算；监督和控制过程组1个：成本控制）
（至）质量管理（3个过程：计划过程组1个：质量规划；执行过程组1个：执行质量保证；监督和控制过程组1个：执行质量控制）
（人）人力资源管理（4个过程组：计划过程组2个：人力资源计划编制，团队组建；执行过程组1个：团队建设；监督和控制过程组1个：团队管理）
（狗）沟通管理（4个过程：计划过程组1个：沟通计划编制；执行过程组1个：信息发布；监督和控制过程组2个：绩效报告，干系人管理）
（踩）采购管理（6个过程：计划过程组2个：采购规划，计划签约；执行过程组2个:请求卖方回应，卖方选择；监督和控制过程组1个：合同管理；收尾过程组1个：合同收尾）
（风）风险管理（6个过程：计划过程组5个：风险管理计划编制，风险识别，定性风险分析，定量风险分析，风险响应规划；监督和控制过程组：风险监控）
（筝）整体管理（7个过程：启动过程组2个：制定项目章程，制定项目范围说明书；计划过程组1个：项目管理规划；执行过程组1个：指导和管理项目执行；监督和控制过程组2个：监督和控制项目工作，整体变更控制；收尾过程组1个：项目收尾）
附表格可以加深记忆：
项目范围管理的六个过程。一，规划范围管理。编制范围管理计划书面描述将如何定义却让和控制项目范围的过程。二，收集需求为实现项目目标而确定记录并管理干系人的需要和需求的过程。三，定义范围，制定项目和产品详细描述的过程。四，创建工作分解结构。将项目可交付成果和项目工作分解为较小的，更易于管理的组件的过程。五，确认范围正式验收已完成的项目可交付成果的过程。六，控制范围，监督项目和产品的范围，状态管理范围基准变更的过程。前四个属于计划过程组，后两个属于监控过程组。需求是范围的基础。项目管理计划有项目管理计划更新。如果有规律的话就去找一下规律。就需要你花时间去记一记。
关于信息系统项目范围管理和软件项目范围管理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件至举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签： #信息系统项目范围管理
相关文章
