ImageVerifierCode 换一换
格式:DOCX , 页数:14 ,大小:21.42KB ,
资源ID:7632074      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/7632074.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(决策分析实施指南.docx)为本站会员(b****5)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

决策分析实施指南.docx

1、决策分析实施指南决策分析实施指南有限公司变更记录版本号修改说明变更日期变更人审批人V1.0创建V1.1修改进入准则与评价准则V1.2修改决策相关方法V1.3修改文档格式 修改点说明的内容有如下几种:创建、修改(+修改说明)、删除(+删除说明)1. 概要目的与范围:本指南的目的在于指导本公司的决策分析过程。本规范适用于本公司项目组的重大决策分析活动和公司培训的采购决策分析活动。2. 正式决策的进入准则组织内部或项目内部在需要做重大决策时均可依据本过程。1) 对于组织而言,一般组织内部在如下情况下可能需要做决策分析: 项目立项论证 架构的选择 构造/复用的权衡分析对于组织,由该事件发起人根据本过程

2、确定是否需要进行决策分析。2) 对于项目而言, 一般项目在如下情况下可能需要做决策分析: 识别和选择软件/系统开发生命周期 识别和选择软件/系统工程的工具 关键技术方案的确定 项目重大需求变更对于项目,项目经理和质量人员识别项目中需要做决策分析的地方。下面列出典型的正式决策的进入准则。2.1. 项目的软硬件及服务的采购本条目包含项目成本范围内的软硬件及服务的采购。 预计决策结果对项目的工期或成本或工作量的影响在20%及以上。2.2. 公司培训的采购 预计本次培训成本占年度培训预算的20%或以上。2.3. 重大技术方案的选择重大技术方案的选择包括 平台方案选择、系统方案选择、技术方案选择。本决策

3、要满足以下所述的条件之一: 数据库选择 中间件选择 客户对 性能、可靠性,稳定性,健壮性有特殊要求的架构选择。 在项目组内有争议的技术方案的选择。2.4. 变更的决策 预计决策结果对项目的工期或成本或工作量的影响在10%及以上。3. 建立评价准则3.1. 建立评价准则的要点1) 评价准则对最终的决策有着至关重要的影响,决策组和发起方必须对评价准则进行充分的讨论,并达成共识。2) 不但要确定评价准则主体的描述,还必须确定各评价准则的重要度。 有些评价准则是对最终方案的强制性的要求,称为决定性评价准则,不满足决定性评价准则的候选方案,不可能成为最终方案。对于决定性准则的评价,只有满足和不满足两种情

4、况。 另外一些评价准则不能独立确定或否决最终方案,但因其重要性不同各自具有不同的权重,称为非决定性评价准则。非决定性评价准则的权重一般用数字表示,该数值的大小与权重成正比例。对于非决定性准则的评价一般用数字表示,该数值的大小与侯选方案满足准则的程度成正比例。 如果非决定性评价准则的数量很多,可按80/20原则进行筛选。 将各非决定性评价准则的权重除以所有非决定性评价准则的权重之和,得到各非决定性评价准则的权重率; 按权重率从大到小的原则对各非决定性评价准则进行排序; 从1开始,从小到大寻找数字N:前N项的非决定性评价准则的权重率之和第一次超过所有非决定性评价准则的权重率之和的80%; 选取前N

5、项作为筛选后的非决定性评价准则。3) 评价准则及其重要度必须清晰准确地反映发起方对候选方案的期望以及现实的约束条件。以下各小节的内容只供决策时参考. 决策组要根据决策实际需要对准则进行裁剪。3.2. 项目的软硬件及服务的采购序号评价准则决定性权重1指定的产品或产品组件是否满足功能要求(列出每一个功能需求)2指定的产品或产品组件是否满足性能要求(列出每一个性能需求)3按期交付的能力4指定的产品或产品组件的易维护性5指定的产品或产品组件的稳定性6指定的产品或产品组件与当前系统接口的难易程度7是否是原来的合作伙伴8如果是原来的合作伙伴,合作关系的评价9业界的评价10企业或公司的规模11产品、产品组件

6、或服务对成本的影响程度12产品、产品组件或服务的售后服务的质量13产品、产品组件、或服务的质量14指定的产品或产品组件的人机界面的友好程度15指定的产品或产品组件的帮助文件的覆盖率16指定的产品的通用性3.3. 公司培训的采购序号评价准则决定性权重1是否提供培训教材和培训成绩测试2培训公司是否使用中文进行授课3培训费用4培训内容、案例详实程度5培训公司的师资能力6师资已经过相应的资格认证的人数7业界的评价8培训公司是否在本地9是否允许在授课时进行录音,录像3.4. 重大技术方案选择的评价准则3.4.1.平台选择方案序号评价准则决定性权重1指定的平台选择方案实施后,达到功能要求程度(列出每一个功

7、能需求)2指定的平台选择方案实施达到性能要求程度(列出每一个性能需求)3指定的平台选择方案实施后,达到客户要求程度4指定的平台选择方案对成本的影响程度5指定的平台选择方案的技术难度6指定的平台是否具有长远的发展潜力7指定的平台选择方案对工作量的影响程度8指定的平台选择方案对交付期的影响程度9指定的平台选择方案对质量的影响程度10指定的平台选择方案实施时的技术风险度11指定的平台选择方案实施后,产品扩展和升级的难易度12指定的平台选择方案是否考虑了竞合管理3.4.2.系统选择方案序号评价准则决定性权重1指定的系统选择方案实施后,是否达到功能要求(列出每一个功能需求)2指定的系统选择方案实施后,是

8、否达到性能要求(列出每一个性能需求)3指定的系统选择方案实施后,可达到客户要求的程度4指定的系统选择方案对需求变化的敏感程度5指定的系统选择方案的技术的难度6指定的系统选择方案对成本的影响程度7指定的系统选择方案实施对工作量的影响程度8指定的系统选择方案实施对交付期的影响程度9指定的系统选择方案实施对质量的影响程度10指定的系统选择方案实施后,产品扩展和升级难易度11指定的系统选择方案中的子系统(子模块)重用于其它软件系统可能性12指定的系统选择方案实施时的技术风险度13指定的系统选择方案的可维护性14指定的系统选择方案实现竞合管理的难易度15指定的系统选择方案实施时,开发管理的难易度16指定

9、的系统选择方案实施后,满足需求限制的程度3.4.3.技术选择方案序号评价准则决定性权重1指定的技术方案满足功能、性能和进度要求程度(列出每一个需求)2指定的技术方案满足需求限制程度(明确指出或默认的)3指定的技术方案对需求变化的敏感程度4指定的技术方案对成本的影响程度5指定的技术方案实施对交付期的影响程度6指定的技术方案实施中存在技术实现的难度7指定的技术方案实施后,产品扩展和升级难易度8指定的技术方案增加可维护性可能性9指定的技术方案实施对工作量的影响程度10指定的技术方案实施对质量的影响程度11指定的技术方案实施后的风险度3.5. 变更决策的评价准则序号评价准则决定性权重1变更对长期的合作

10、战略的影响2变更对交付期的影响程度3变更对成本的影响程度4变更对工作量的影响程度5变更对质量的影响程度6变更对员工士气的影响4. 识别候选方案一般地,候选方案由发起方提供,不在决策组的工作范围之内。这里给出识别候选方案的一般性步骤,供参考。1) 确定待决策问题的背景(Context),包括限制条件、需求、场景、业务案例假设、业务目标等。2) 进行领域研究,对相关领域进行调查。 文献查询:可在网上和组织资产库中查找与问题有关的领域资料。 咨询:可咨询有问题领域知识的人或组织,收集问题可能用到的解决方法和这些解决方法的约束条件。 原系统的调研:可通过对原系统的调研了解原系统的解决问题的方法及他们的

11、优缺点。3) 找出或开发一个或多个候选方案。4) 将候选方案文档化。5. 决策相关的方法5.1. 确定评价准则/候选方案的方法5.1.1.头脑风暴法当一群人围绕一个特定的兴趣领域产生新观点的时候,这种情境就叫做头脑风暴。头脑风暴法是在自由的环境下,决策组发现尽可能多的决策准则或候选方案。头脑风暴法适用于上级经理不是决策组成员或决策组长的情况下。头脑风暴的实施步骤:1. 决策组长指定记录员。决策组长指定一位决策组成员或自己担当记录者。2. 在进行头脑风暴法前确保每人对将要决策的问题都有清晰的了解。3. 在进行自由讨论会议前使决策组成员理解下面的规则: 规则1 在自由讨论结束前 对所有决策准则或候

12、选方案不进行评判。 规则2 鼓励狂热的和夸张的决策准则或候选方案提出。 规则3 在现阶段量有价值,而不是质。 规则4 在他人提出的决策准则或候选方案之上建立新的决策准则或候选方案 规则5 每个人和每个决策准则或候选方案都有相等的价值4. 决策组进行自由讨论会议。由决策组长主持,决策组成员各抒己见。记录员记录下所有的决策准则或候选方案,并使得每个决策组成员能够看到这些决策准则或候选方案。确保在讨论结束以前不要评价或批评任何决策准则或候选方案,5. 自由讨论会议结束后,检查记录结果并对各种决策准则或候选方案进行评价。评价后的结果写入决策报告中。在检查决策准则或候选方案记录的时候应注意如下几点。 寻

13、找任何重复或者相似的决策准则或候选方案; 将相似的概念聚集在一起; 剔除明确不合适的决策准则或候选方案,5.1.2.调查法调查通过网上查寻、咨询、现场考查或原系统的调研方式等方式取得决策所需的资料。5.2. 评价候选方案的方法5.2.1.独立打分法领域专家背对背地给候选方案打分并选择最科学的候选方案。独立打分法 适用于上级领导是决策组成员或决策组长且决策问题比较简单的情况下。1. 采用不记名的方式,决策组成员按选择准则对各候选方案进行打分。2. 决策组长将决策组成员的评分汇总打分结果,并确定最终方案。5.2.2.打分讨论法打分、讨论,再打分、再讨论,直到决策组成员的意见一致。打分讨论法 适用于

14、上级领导不是决策组成员或决策组长的情况下。1. 决策组成员按决策准则对各候选方案进行打分。2. 决策组长汇总决策组成员的评分结果并反馈给决策组成员。3. 评分偏差较大之处,(偏差两个极端的)决策组成员对自己评分的理由进行说明。4. 淘汰决策小组一致同意淘汰的候选方案。5. 决策组进行再次评分。如此反复直至决策组成员意见稳定或趋于一致。5.2.3.实验法实验法适用于辅助软件、硬件产品及产品组件的候选方案的选择。实验法是对每一个候选方案的功能、性能等进行测试,验证产品或产品组件的优劣,为决策组的评价提供有力的支持。实验法的实施步骤:1. 根据将要选择的产品或产品组件的选择准则及其所要求的详细需求(

15、技术性的和非技术性的)编写测试用例。2. 按照测试用例对产品或产品组件进行测试,并形成测试报告。3. 决策组成员对照测试结果对各个评价准则进行评价。6. 其它6.1. 系统设计方案应考虑的方面系统方案设计、选择可以重点从以下几个方面考虑: 成本:如果开发成本要求苛刻: 平台选择时应该考虑到License等费用因素; 平台的不同引发开发周期等开发成本也不同,应该考虑公司/项目组成员较熟悉的平台,以压缩开发周期、降低成本。 性能:如果需求对系统性能要求较高,那么: 平台选择:首先平台选择时应充分考虑该类要求是否能的到满足。 如:技术平台不支持多任务,那么可能有的性能根本就无法满足。 系统架构设计:

16、应该考虑相关的性能指标是否能否的到保证。 如:对大容量信息(电话本)的频繁访问,可能需要考虑该部分内容常驻内存处理。 如:对于网络交互、NV读写等响应慢的操作,应该考虑在系统中采用独立于UI的Task执行。 硬件架构设计:要作相应考虑如:RAM配置上可能也要加大。 接口设计:跟性能指标相关的接口,设计时要充分考虑调用效率。 系统性能要系统分析:如:要求照相机功能1秒内响应:首先摄像头硬件的响应时间必须在1秒以内,而且加上软件操作的响应时间应该在1秒以内,才能使该功能的系统整体响应时间达到1秒的性能要求。 采用新技术的风险:对该类项目,最好系统架构设计时,能够较好的降低该风险。如:能够让技术风险

17、较大的模块尽可能独立,便于分布开发、增量集成、充分测试,降低耦合度,便于控制。如:系统设计及后续的概要设计等阶段可以考虑对关键技术、设计,编写部分程序进行可行性验证。 技术限制:如果平台/技术有已知的限制,系统架构设计时应充分考虑到这些限制因素对需求实现可能的影响。如:Brew平台不支持重入,那么系统架构设计时,应该意识到它对某些需求的影响。 对需求变化的敏感程度:系统的架构设计应该尽可能降低对需求变化的敏感度,以便较好的消化需求在项目的后续生命周期中变更时引起的潜在风险。 产品扩展和升级:主要指系统架构的设计,应该能适应系统今后功能/构件扩展的要求。 重用性:如果有该方面的要求,系统设计时应

18、有相关考虑。如:公用的功能、控件等应尽可能独立设计、封装。如果技术平台能支持跨平台移植,也要考虑。 可维护性:系统方案设计应该多考虑面向对象的设计思想,在平台技术特点许可的范围内,尽可能模块化。如:Brew平台的菜单、Pop, Softkey可以封装为控件,相关的需求变更时,只需在这些控件内部作一次修改、调整,而不必在几十处使用Menu,Pop,Softkey的地方逐一修改。 竞合管理:对手机类项目的开发,系统架构设计时,需要充分考虑到方案是否能满足竞合管理的需要。如:可以考虑系统架构/模块增加状态机来管理等。 开发管理:架构设计、模块划分时,最好能够为项目管理做些考虑,便于后续的设计、开发、集成等阶段分工及管理。 需求指明的限制:在技术平台选择、方案设计时作相应的考虑。如:对内存有较苛刻的要求,那么在支持模块动态加载与不支持模块动态加载的技术平台中选择时,优先选择支持动态加载模块的平台。6.2. 相关文档决策分析过程

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1