决策分析实施指南.docx
《决策分析实施指南.docx》由会员分享，可在线阅读，更多相关《决策分析实施指南.docx（14页珍藏版）》请在冰豆网上搜索。
决策分析实施指南
决策分析实施指南
有限公司
变更记录
版本号
修改说明
变更日期
变更人
审批人
V1.0
创建
V1.1
修改进入准则与评价准则
V1.2
修改决策相关方法
V1.3
修改文档格式
修改点说明的内容有如下几种：
创建、修改（+修改说明）、删除（+删除说明）
1.概要
目的与范围:
本指南的目的在于指导本公司的决策分析过程。
本规范适用于本公司项目组的重大决策分析活动和公司培训的采购决策分析活动。
2.正式决策的进入准则
组织内部或项目内部在需要做重大决策时均可依据本过程。
1）对于组织而言，一般组织内部在如下情况下可能需要做决策分析：
∙项目立项论证
∙架构的选择
∙构造/复用的权衡分析
对于组织，由该事件发起人根据本过程确定是否需要进行决策分析。
2）对于项目而言，一般项目在如下情况下可能需要做决策分析：
∙识别和选择软件/系统开发生命周期
∙识别和选择软件/系统工程的工具
∙关键技术方案的确定
∙项目重大需求变更
对于项目，项目经理和质量人员识别项目中需要做决策分析的地方。
下面列出典型的正式决策的进入准则。
2.1.项目的软硬件及服务的采购
本条目包含项目成本范围内的软硬件及服务的采购。
Ø预计决策结果对项目的工期或成本或工作量的影响在20%及以上。
2.2.公司培训的采购
Ø预计本次培训成本占年度培训预算的20%或以上。
2.3.重大技术方案的选择
重大技术方案的选择包括平台方案选择、系统方案选择、技术方案选择。
本决策要满足以下所述的条件之一：
Ø数据库选择
Ø中间件选择
Ø客户对性能、可靠性，稳定性，健壮性有特殊要求的架构选择。
Ø在项目组内有争议的技术方案的选择。
2.4.变更的决策
Ø预计决策结果对项目的工期或成本或工作量的影响在10%及以上。
3.建立评价准则
3.1.建立评价准则的要点
1）评价准则对最终的决策有着至关重要的影响，决策组和发起方必须对评价准则进行充分的讨论，并达成共识。
2）不但要确定评价准则主体的描述，还必须确定各评价准则的重要度。
Ø有些评价准则是对最终方案的强制性的要求，称为决定性评价准则，不满足决定性评价准则的候选方案，不可能成为最终方案。
对于决定性准则的评价，只有满足和不满足两种情况。
Ø另外一些评价准则不能独立确定或否决最终方案，但因其重要性不同各自具有不同的权重，称为非决定性评价准则。
非决定性评价准则的权重一般用数字表示，该数值的大小与权重成正比例。
对于非决定性准则的评价一般用数字表示，该数值的大小与侯选方案满足准则的程度成正比例。
Ø如果非决定性评价准则的数量很多，可按80/20原则进行筛选。
✧将各非决定性评价准则的权重除以所有非决定性评价准则的权重之和，得到各非决定性评价准则的权重率；
✧按权重率从大到小的原则对各非决定性评价准则进行排序；
✧从1开始，从小到大寻找数字N：
前N项的非决定性评价准则的权重率之和第一次超过所有非决定性评价准则的权重率之和的80%；
✧选取前N项作为筛选后的非决定性评价准则。
3）评价准则及其重要度必须清晰准确地反映发起方对候选方案的期望以及现实的约束条件。
以下各小节的内容只供决策时参考.决策组要根据决策实际需要对准则进行裁剪。
3.2.项目的软硬件及服务的采购
序号
评价准则
决定性
权重
1
指定的产品或产品组件是否满足功能要求（列出每一个功能需求）
2
指定的产品或产品组件是否满足性能要求（列出每一个性能需求）
3
按期交付的能力
4
指定的产品或产品组件的易维护性
5
指定的产品或产品组件的稳定性
6
指定的产品或产品组件与当前系统接口的难易程度
7
是否是原来的合作伙伴
8
如果是原来的合作伙伴，合作关系的评价
9
业界的评价
10
企业或公司的规模
11
产品、产品组件或服务对成本的影响程度
12
产品、产品组件或服务的售后服务的质量
13
产品、产品组件、或服务的质量
14
指定的产品或产品组件的人机界面的友好程度
15
指定的产品或产品组件的帮助文件的覆盖率
16
指定的产品的通用性
3.3.公司培训的采购
序号
评价准则
决定性
权重
1
是否提供培训教材和培训成绩测试
2
培训公司是否使用中文进行授课
3
培训费用
4
培训内容、案例详实程度
5
培训公司的师资能力
6
师资已经过相应的资格认证的人数
7
业界的评价
8
培训公司是否在本地
9
是否允许在授课时进行录音，录像
3.4.重大技术方案选择的评价准则
3.4.1.平台选择方案
序号
评价准则
决定性
权重
1
指定的平台选择方案实施后，达到功能要求程度（列出每一个功能需求）
2
指定的平台选择方案实施达到性能要求程度（列出每一个性能需求）
3
指定的平台选择方案实施后，达到客户要求程度
4
指定的平台选择方案对成本的影响程度
5
指定的平台选择方案的技术难度
6
指定的平台是否具有长远的发展潜力
7
指定的平台选择方案对工作量的影响程度
8
指定的平台选择方案对交付期的影响程度
9
指定的平台选择方案对质量的影响程度
10
指定的平台选择方案实施时的技术风险度
11
指定的平台选择方案实施后，产品扩展和升级的难易度
12
指定的平台选择方案是否考虑了竞合管理
3.4.2.系统选择方案
序号
评价准则
决定性
权重
1
指定的系统选择方案实施后，是否达到功能要求（列出每一个功能需求）
2
指定的系统选择方案实施后，是否达到性能要求（列出每一个性能需求）
3
指定的系统选择方案实施后，可达到客户要求的程度
4
指定的系统选择方案对需求变化的敏感程度
5
指定的系统选择方案的技术的难度
6
指定的系统选择方案对成本的影响程度
7
指定的系统选择方案实施对工作量的影响程度
8
指定的系统选择方案实施对交付期的影响程度
9
指定的系统选择方案实施对质量的影响程度
10
指定的系统选择方案实施后，产品扩展和升级难易度
11
指定的系统选择方案中的子系统（子模块）重用于其它软件系统可能性
12
指定的系统选择方案实施时的技术风险度
13
指定的系统选择方案的可维护性
14
指定的系统选择方案实现竞合管理的难易度
15
指定的系统选择方案实施时，开发管理的难易度
16
指定的系统选择方案实施后，满足需求限制的程度
3.4.3.技术选择方案
序号
评价准则
决定性
权重
1
指定的技术方案满足功能、性能和进度要求程度（列出每一个需求）
2
指定的技术方案满足需求限制程度（明确指出或默认的）
3
指定的技术方案对需求变化的敏感程度
4
指定的技术方案对成本的影响程度
5
指定的技术方案实施对交付期的影响程度
6
指定的技术方案实施中存在技术实现的难度
7
指定的技术方案实施后，产品扩展和升级难易度
8
指定的技术方案增加可维护性可能性
9
指定的技术方案实施对工作量的影响程度
10
指定的技术方案实施对质量的影响程度
11
指定的技术方案实施后的风险度
3.5.变更决策的评价准则
序号
评价准则
决定性
权重
1
变更对长期的合作战略的影响
2
变更对交付期的影响程度
3
变更对成本的影响程度
4
变更对工作量的影响程度
5
变更对质量的影响程度
6
变更对员工士气的影响
4.识别候选方案
一般地，候选方案由发起方提供，不在决策组的工作范围之内。
这里给出识别候选方案的一般性步骤，供参考。
1）确定待决策问题的背景（Context），包括限制条件、需求、场景、业务案例假设、业务目标等。
2）进行领域研究，对相关领域进行调查。
Ø文献查询：
可在网上和组织资产库中查找与问题有关的领域资料。
Ø咨询：
可咨询有问题领域知识的人或组织，收集问题可能用到的解决方法和这些解决方法的约束条件。
Ø原系统的调研：
可通过对原系统的调研了解原系统的解决问题的方法及他们的优缺点。
3）找出或开发一个或多个候选方案。
4）将候选方案文档化。
5.决策相关的方法
5.1.确定评价准则/候选方案的方法
5.1.1.头脑风暴法
当一群人围绕一个特定的兴趣领域产生新观点的时候，这种情境就叫做头脑风暴。
头脑风暴法是在自由的环境下，决策组发现尽可能多的决策准则或候选方案。
头脑风暴法适用于上级经理不是决策组成员或决策组长的情况下。
头脑风暴的实施步骤：
1.决策组长指定记录员。
决策组长指定一位决策组成员或自己担当记录者。
2.在进行头脑风暴法前确保每人对将要决策的问题都有清晰的了解。
3.在进行自由讨论会议前使决策组成员理解下面的规则：
Ø规则1在自由讨论结束前对所有决策准则或候选方案不进行评判。
Ø规则2鼓励狂热的和夸张的决策准则或候选方案提出。
Ø规则3在现阶段量有价值，而不是质。
Ø规则4在他人提出的决策准则或候选方案之上建立新的决策准则或候选方案
Ø规则5每个人和每个决策准则或候选方案都有相等的价值
4.决策组进行自由讨论会议。
由决策组长主持，决策组成员各抒己见。
记录员记录下所有的决策准则或候选方案，并使得每个决策组成员能够看到这些决策准则或候选方案。
确保在讨论结束以前不要评价或批评任何决策准则或候选方案，
5.自由讨论会议结束后，检查记录结果并对各种决策准则或候选方案进行评价。
评价后的结果写入决策报告中。
在检查决策准则或候选方案记录的时候应注意如下几点。
Ø寻找任何重复或者相似的决策准则或候选方案；
Ø将相似的概念聚集在一起；
Ø剔除明确不合适的决策准则或候选方案，
5.1.2.调查法
调查通过网上查寻、咨询、现场考查或原系统的调研方式等方式取得决策所需的资料。
5.2.评价候选方案的方法
5.2.1.独立打分法
领域专家背对背地给候选方案打分并选择最科学的候选方案。
独立打分法适用于上级领导是决策组成员或决策组长且决策问题比较简单的情况下。
1.采用不记名的方式，决策组成员按选择准则对各候选方案进行打分。
2.决策组长将决策组成员的评分汇总打分结果，并确定最终方案。
5.2.2.打分讨论法
打分、讨论，再打分、再讨论，直到决策组成员的意见一致。
打分讨论法适用于上级领导不是决策组成员或决策组长的情况下。
1.决策组成员按决策准则对各候选方案进行打分。
2.决策组长汇总决策组成员的评分结果并反馈给决策组成员。
3.评分偏差较大之处，（偏差两个极端的）决策组成员对自己评分的理由进行说明。
4.淘汰决策小组一致同意淘汰的候选方案。
5.决策组进行再次评分。
如此反复直至决策组成员意见稳定或趋于一致。
5.2.3.实验法
实验法适用于辅助软件、硬件产品及产品组件的候选方案的选择。
实验法是对每一个候选方案的功能、性能等进行测试，验证产品或产品组件的优劣，为决策组的评价提供有力的支持。
实验法的实施步骤：
1.根据将要选择的产品或产品组件的选择准则及其所要求的详细需求（技术性的和非技术性的）编写测试用例。
2.按照测试用例对产品或产品组件进行测试，并形成测试报告。
3.决策组成员对照测试结果对各个评价准则进行评价。
6.其它
6.1.系统设计方案应考虑的方面
系统方案设计、选择可以重点从以下几个方面考虑：
Ø成本：
如果开发成本要求苛刻：
●平台选择时应该考虑到License等费用因素；
●平台的不同引发开发周期等开发成本也不同，应该考虑公司/项目组成员较熟悉的平台，以压缩开发周期、降低成本。
Ø性能：
如果需求对系统性能要求较高，那么：
Ø平台选择：
首先平台选择时应充分考虑该类要求是否能的到满足。
●如：
技术平台不支持多任务，那么可能有的性能根本就无法满足。
Ø系统架构设计：
应该考虑相关的性能指标是否能否的到保证。
●如：
对大容量信息（电话本）的频繁访问，可能需要考虑该部分内容常驻内存处理。
●如：
对于网络交互、NV读写等响应慢的操作，应该考虑在系统中采用独立于UI的Task执行。
Ø硬件架构设计：
要作相应考虑如：
RAM配置上可能也要加大。
Ø接口设计：
跟性能指标相关的接口，设计时要充分考虑调用效率。
Ø系统性能要系统分析：
如：
要求照相机功能1秒内响应：
首先摄像头硬件的响应时间必须在1秒以内，而且加上软件操作的响应时间应该在1秒以内，才能使该功能的系统整体响应时间达到1秒的性能要求。
Ø采用新技术的风险：
对该类项目，最好系统架构设计时，能够较好的降低该风险。
如：
能够让技术风险较大的模块尽可能独立，便于分布开发、增量集成、充分测试，降低耦合度，便于控制。
如：
系统设计及后续的概要设计等阶段可以考虑对关键技术、设计，编写部分程序进行可行性验证。
Ø技术限制：
如果平台/技术有已知的限制，系统架构设计时应充分考虑到这些限制因素对需求实现可能的影响。
如：
Brew平台不支持重入，那么系统架构设计时，应该意识到它对某些需求的影响。
Ø对需求变化的敏感程度：
系统的架构设计应该尽可能降低对需求变化的敏感度，以便较好的消化需求在项目的后续生命周期中变更时引起的潜在风险。
Ø产品扩展和升级：
主要指系统架构的设计，应该能适应系统今后功能/构件扩展的要求。
Ø重用性：
如果有该方面的要求，系统设计时应有相关考虑。
如：
公用的功能、控件等应尽可能独立设计、封装。
如果技术平台能支持跨平台移植，也要考虑。
Ø可维护性：
系统方案设计应该多考虑面向对象的设计思想，在平台技术特点许可的范围内，尽可能模块化。
如：
Brew平台的菜单、Pop,Softkey可以封装为控件，相关的需求变更时，只需在这些控件内部作一次修改、调整，而不必在几十处使用Menu,Pop,Softkey的地方逐一修改。
Ø竞合管理：
对手机类项目的开发，系统架构设计时，需要充分考虑到方案是否能满足竞合管理的需要。
如：
可以考虑系统架构/模块增加状态机来管理等。
Ø开发管理：
架构设计、模块划分时，最好能够为项目管理做些考虑，便于后续的设计、开发、集成等阶段分工及管理。
Ø需求指明的限制：
在技术平台选择、方案设计时作相应的考虑。
如：
对内存有较苛刻的要求，那么在支持模块动态加载与不支持模块动态加载的技术平台中选择时，优先选择支持动态加载模块的平台。
6.2.相关文档
《决策分析过程》
升级会员 