1、技术参数:规格说明:22倍变焦摄象机元件:1/3 SONY CCD摄像元件尺寸:4.34mm*3.69mm(V)影象像素:512(H)*582(V)水平清晰度:480线镜头配置:f=3.9-85.8mm视角:水平55扫描方式:lnteriale 2:1视频输出:1.0Vp-p/75BNC对焦:自动对焦白平衡:自动平衡开/关信噪比:48db电子快门:PAL:1151/10000s NTSC:1/601/10000s最低照度:0.1Lux/F1.2增益控制:自动增益开/关背光补偿:手动/自动可选同步系统:INTERNAL电源:DC12V工作温度:-10- 504变倍一体机 VST-PV470 技术
2、参数: 规格说明:27倍变焦摄象机元件:1/3 SONY CCD摄像元件尺寸:4.34mm*3.69mm(V)影象像素:512(H)*582(V)水平清晰度:480线镜头配置:f=3.9-85.8mm视角:水平55扫描方式:lnteriale 2:1视频输出:1.0Vp-p/75BNC对焦:自动对焦白平衡:自动平衡开/关信噪比:48db电子快门:PAL:1151/10000s NTSC:1/601/10000s最低照度:0.1Lux/F1.2增益控制:自动增益开/关背光补偿:手动/自动可选同步系统:INTERNAL电源:DC12V工作温度:-10- 505、彩色枪式摄像机 VST-Y820技术
3、规格： 摄像元件：1/3 SONY CCD 像素：795（H）*596（V）所有像素752（H）*582（V）有效像素 图像结构：无几何扭曲、失真现象 同步系统：内同步 交叉（交错）扫描：2：1交叉 分辨率：水平：420线，垂直：350线 视频输出幅度：VBS1.0Vp-p,(75欧姆，复合视频信号) 信噪比（S/N）：大于48分贝 最低照度：0.8Lux 电源要求：12伏特直流，1A，稳压电流 耗电量：约6瓦特6、红外远距离防水摄像机 VST-101A 技术规格： 摄像元件：SONY CCD 图像大小：1/3英寸（约3.6*2.7毫米） 像素：795（H）*596（V）所有像素752（H）*
4、582（V）有效像素 图像结构：无几何扭曲、失真现象 同步系统：内同步 交叉（交错）扫描：2：1交叉 分辨率：水平：480线 视频输出幅度：VBS1.0Vp-p,(75欧姆，复合视频信号) 信噪比（S/N）：大于48分贝 切换方式：自动感光，昼夜切换 最低照度：0Lux/F1.2（红外灯开启） 红外灯规格：6颗F30 LED 11颗F8 LED 红外距离30-50M Y校正（伽玛）：0.45 环境条件：操作温度：14度-122度F（-10度-50度） 电源要求：12伏特直流，1A，稳压电流六、系统供电与控制室要求 为保证监控系统正常稳定工作，系统采可用在线式UPS集中供电； 监控系统和中心控制
5、室采用单独电源供电回路； 主干采用AC220V供电,在摄像机前端采用变压器就近供电； 中心控制室必须配备有通讯、安全和消防等设备； 中心控制室必须单独安装空调装置，保证控制室的温度在1628之间，相对湿度不大于85%； 控制室室内光线充足，其照度应不小于300Lux； 控制室的其它设备和金属外壳也必须做好等电位连接，以保证控制室内的人身和设备安全。七、售后服务体系7.1 售后服务承诺凭借公司多年从事安防监控管理系统的经验，依托公司强大的资金、技术、管理等实力，有能力针对监控系统的售后服务作出如下承诺：1、整体监控系统（包括各类监控产品等）由我公司免费质保壹年，为用户免费提供壹年的技术支持服务和
6、软件升级服务；2、在质保期内，如果监控系统设备出现故障，我公司将为用户提供性能指标不低于该设备的备用设备，以保障用户对监控系统不间断使用的要求；3、在质保期内，如用户提出其他的各类特殊技术支持或现场服务要求，均保证在最短时间内服务；7.2 售后服务类别1+1售后服务为客户提供最佳的技术服务，在您开始使用我们的监控系统时，我们将以“一个销售人员 + 一个技服人员”为您提供免费培训和技术支持 。监护服务对于需要一套完整的一揽子现场支持的用户来说，它是服务的首选。包括电话支持、现场支援、备件先行更换和软件更新。对在关键场所使用我们提供的监控系统产品的行业用户而言，监护服务是一种极好的选择。作为一名监
7、护服务的用户，您将在技术升级过程及一系列服务中获得最高的优先权。壹年保修，终身维护壹年内免费更换因质量问题损坏的配件；壹年内免费软件升级：软件更新服务可以简化对系统维护的预算，用户将收到软件更新的最新消息。壹年以后提供收费维护。备件先行更换服务对于那些运行于关键性场所或者不具有库存备件的用户来说，选择备件先行更换服务可减少因硬件故障给您的日常管理带来的影响。用户可以在指定的响应时间内，预先得到提供的更换备件，不必担心因部件的损坏而导致整个系统无法再使用。软件升级服务对所售出的系统在三年内享受免费软件升级；软件更新服务可以简化对系统维护的预算，用户可在网上下载最新的更新软件，并收到软件更新的最新
8、消息。特殊需求定制服务每个行业、每个客户都可能因其业务需要有不同要求，满足客户日益增长的需要是的不懈追求,凭借强大的技术实力配合生产厂商为您量身定做，提供特殊需求订制研发服务。电话咨询服务它帮助您的内部支持人员迅速有效地解决问题。不管您是希望了解经营的产品，还是在已使用经营的产品中遇到技术问题，训练有素的技术支持代表将迅速回答您的问题，并对服务请求进行分析将它们转给适当的技术工程师。网络查询服务网络是最快最实用的方式,用户可以随时随地通过打开QQ或E-mail获取您需要的资料，下载有关驱动程序和最新版本的软件工具：包括产品说明书、产品技术规格、常见问题解答等。7.3 售后服务响应服务费用：A、
9、在保修期内，无论次数有多少、时间有多长，全部免费提供服务。B、保修期满后，仅收取需更换的元器件、零配件的材料费。7.4 质保期满后的售后服务为保障其用户利益，保障产品的质量，在用户购买的产品超出保修期后向用户提供下列有偿技术服务。A、保修期后我公司负责设备的终生维护和维修，其零部件仅按厂家或国家标准收取合理成本。B、提供系列综合服务：项目协调、一级热线电话技术支持、根据用户要求提供到点维修服务、坏损件维修、软件维护。八、监控系统培训在整个系统完工后提供对业主方操作人员的免费培训。培训的目的是训练系统操作员。通过训练后使他们能够熟练的操作监控系统，并能处理一些基本故障。将指定具有中级职称的、多年
10、从业经验的专业人员作为培训讲师。8.2 现场培训这项培训着重培训操作员对系统的操作与问题的处理，培训的主要内容包括：n 系统的软件安装n 设备在系统中的作用及正确使用方法n 设备的检查、调整及测试，常用测量仪表和仪器的使用方法n 设备的接地与防雷n 监控信息的日常维护n 简单的软件故障处理n 简单的硬件故障处理n 设备的维护保养n 提供培训教材n 参加安装培训地点在施工现场，培训内容随系统安装调试一起进行，要求系统操作员一起参与系统软硬件的安装与调试。九、监控系统工程质量管理9.1 设计质量标准措施1.严格依据国家安全防范技术工程设计、安装、维修的行业标准及规范，按照客户对系统工程的任务书及要
11、求做好设计方案。2.密切沟通客户,从技术可行、经济适用、合理的角度对设计方案进行调整和修改，直至完全理解和符合客户要求。3按照方便、舒适、安全、环保、节能的原则，在客户确认设计方案的基础上完成施工图设计。4实行设计目标管理责任制和项目设计专人制，按国家对设计行业管理的标准，推行全面质量管理，认真严谨的把好校对审核关。9.2 工期保证措施1实行项目管理，形成快速决策、指挥灵活的管理系统，我们承诺在合同规定日期内完成本工程。2重视图纸会审工作及时提前将施工图中的问题提出，避免设计方面影响到施工进度。3严格按施工进度计划组织施工，采用网络计划控制工期，项目编制作业计划，确保施工计划顺利实现。4及时提
12、出材料、机具计划，加强机具的维修及保养工作，杜绝因材料、机具等情况影响工期。5合理安排施工计划，选用精兵强将，组织施工，提高工作效率，加快工程进度。6加强施工现场组织领导，做到统一指挥，统一协调，与甲方积极配合，尽可能的消除施工相互干扰现象；工程进度款按时拨款，材料计划精心安排，保证工程正常施工。甲方应当及时提供必要的器具或协助，以免耽误工期。9.3 质量保证措施1根据规定提供相关工程项目质量标准技术服务。2严格实行技术交底制度，建立健全质量检验制度和工序交接检制度。3完善技术管理、质量管理责任制，加强项目机构人员、岗位、责任的落实，对工程质量实施全面的控制。4严格按国家施工及验收规范，质量检
13、验评定标准及有关规范规定，对工序进行质量检查和控制。5施工人员必须认真审核图纸，工程变更必须有书面通知。6坚持按级10软件项目风险管埋计划210.1软件项目风险管理概述210.1.1风险概念210.1.2风险类型410.1.3风险的基本性质510.1.4风险管理概述510.1.5风险管理的意义510.2风险识别610.2.1概念710.2.2德尔菲方法710.2.3头脑风暴法710.2.4情景分析法710.2.5风险条目恼查表710.2.6真他方法1310.2.7风险识别的结果1310.3风险评估1310.3.1概念1410.3.2定性风险评估1410.3.3定量风险评估1510.3.4风险分
14、析结果表1710.4风险规划1810.4.1概忿1810.4.2回避风险1810.4.3转移风险1910.4.4损失控制1910.4.5自留风险1910.4.6风险规划结果1910.5风险控制2010.6风险管埋的建议2010.7案例说明2110.8小结2110.9习题2210 软件项目风险管埋计划任何项目都有一定的不确定性，如果没有很好的风险管理，项目就可能遇到麻烦。所以，在软件项目管理过程中，风险计划也是一个重要的计划，只有进行合理的风险管理，制定及时的风险计划，才能防崽于未然，做到主动控制风险，而不是被动地被风险所控制。本章我们进人路线图的第9站：风险计划，如图101所示。图10-1路线
15、图第9站：风险计划10.1 软件项目风险管理概述在软件项目的开发过程中，必然要使用一些新技术、新产品，同时由于软件系统本身的结枸和技术复杂性的原因，需要投人大量人力、物力和财力，这就造成开发过程中存在某些“未知量”或“不确定因素”，这必然给项目的开发带来一定程度的风险，也可能会使项目计划失败或不能完全达到预期目标。因此，对项目风险进行科学、准确的判别，为项目决策层和管理人员提供科学的评估方法，是十分必要的。项目中的风险有很多种，没有风险的项目几乎是不存在的，只是风险的多少、严重程度不同而已。10.1.1 风险概念风险是损失发生的不确定性，是对潜在的、未来可能发生损害的一种度量。如果风险确实发生
16、了，则它的发生会对项目产生有害的或者负面的影响。例如，在软件测试期间经常会发现故障，因此一个合理的项目必须做好发现故障时对它们进行修复的计划。同样，项目开发过程中几乎总悬会出现某些变更申请，因此项目管理必须相应地准备好变更计划，以处理这些事件。另一方面，风险是一种概率事件它可能发生也可能不发生。因此，我们通常会表现出很乐观，不是看不到风险就是希望它们不会发生。如果风险真出现了，这种态度会使项目陷入困境，这是一个大型项目中很可能发生的事情。因此，风险管理被认为是管理大型软件项目的最佳实践。风险管理旨在识别出风险，然后采取措施使它们对项目的影响最小。风险管理是软件管理中相对较新的领域，它首次出现于
17、贝姆（Bochm）关子风险管理的指商中。自那以后，软件的风险管理逐渐被人们所认识。软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。一个项目的损失可能有不同的后果形式，例如软件质量的下降、成本费用的超出、项目进度的推迟等。风险关注未来的事情，这意味着，风险涉及选择本身包含的不确定性，软件开发过程及软件产品都要面临各种决策的选择。风险发生的过程如图10度量2所示，首先有风险因素的存在，风险因素导致风险事件的发生，从而造成损失，而损失又引起了实际与计划之间的差异，从而得到风险的结果。风险事件是指那些人们不愿意它发生的或者没有规划的事件。这些风险事件可能导致无法实现项目目标。风险因素是指
18、能够引起风险事件发生或者增加风险事件发生机会或影响损失严重程度的因素，是造成损失的内在或者处在的原因。需求的变化，设计镨误、疏漏和理解镨误，狭隘定义或理解镨误，不充分估计，不胜任的拈犬人呙等等、都旱风除冈葚。图l0弓2风险发生过程一般说，项目风险应具有三要素：首先风险是一个事件，其次风险应具有事件发生的概率，最后风险事件可能造成一定的影响。如图103所示，风险发生的概率越高，造成的影响越大，就越是高风险，否则就是中等风险或者低风险。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。当没有办法消除风险甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。在我们能够标识出
19、软件项目中的真正风险之前，识别出所有对管理耆和开发者而言均为明显的风险是很重要的。图10亏3风险图示10.1.2 风险类型从范围角度上看，风险主要分为下述三种类型：项目风险、技术风险和商业风险。1）项目风险项目风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，例如时词和资源分配的不合理、项目计划质量的不足、项目管理原理使用不良所导致的风险、资金不足、缺乏必要的项目优先级等。项目的复杂性、规模的不确定性和结构的不确定性也是构成项目风险的因奏。2）技术风险技术风险是指潜在的设计、实现、接口、检验和维护方面的问题。规格说明的多义性、技术上的不确定性、技术陈旧也是技术风险因
20、素。复杂的技术、项目执行过程中使用技术或者行业标准发生变化所导致的风险也是技术风险。3）商业风险商业风险主要包括：市场风险、策略风险、管理风险和预算风险等。例如：如果开发的软件不是市场真正所想要的，就发生了市场风险。如果开发的软件不再符合公司的软件产品策略，就发生了策略风险。由于重点转移或者人员变动而失去上级管理部门的支持，就发生了管理风险。如果没有得到预算或者人员的保证，就发生了预算风险。从预测角度看，风险可以分为下面三种类型：已知风险、可预测风险、不可预测风险。1）已知风险已知风险是通过仔细评佑项目计划、开发项目的商业和技术环境以及其他可靠的信息来源之后可以发现的那些风险（如：不现实的交付
21、时间，没有需求或软件范围的文档，恶劣的开发环境）。2）可预测风险可预测风险是指能够从过去项目的经验中推测出来的风险（如：人员调整，与客户之间无法沟通，由于需要进行维护而使开发人员精力分散等）。3）不可预测风险不可预测风险是可能、也会真的出现、但很难事先识别出来的风险。项目管理者只能对已知风险和可预测风险进行规划，不可预测的风险只能靠企业的能力来承担了。10.1.3 风险的基本性质风险具有如下的基本性质：1）客观性风险客观性首先表现在它的存在是不以人的意志为转移的，因为决定风险的各种因素对风险主体是独立存在的，不管风险主体是否意识到风险的存在，在一定的条件下风险就可能变为现实。其次，风险客观性还
22、表现在风险元时不有，无所不在，它潜在各种活动之中。2）不确定性风险发生的不确定性表现为风险的程度有多大以及风险何时何地有可能变为现实，这些都是不肯定的。由于人们对客观世界的认识受到各种条件的限制，不可能准确地预测风险的发生，不确定性要求我们运用各种方法进行测度。3）不利性风险一旦产生时，就会使风险主体产生挫折、失败甚至损失，对风险主体不利。因此我们应该在承认风险、认识风险的基础上，做好决策，尽可能避免风险，将风险的不利性降到最低。4）可变性 度量风险的可变性表现在一定条件下可以转化，风险事件可以转化为非风险的事件，非风险的事件可以转化为风险事件。5）相对性风险的相对性是针对风险的主体而言的，在
23、相同的风险情况下，不同的风险主体对风险的承受能力不同，不同的组织和个人往往对风险有着不同的容忍限度。例如，一个高利润高收益的公司也许愿意为一个10亿美元的合同花费50万美元制作一份计划书，而亠个收支相抵的公司则不会。一个组织也许认为15的误差几率是高风险的，而其他组织却认为这个几率风险很低。6）风险和利益的对称性风险和利益是同时存在的，风险是利益的代价，利益是风险的报酬。没有利益只有风险，没人会做；实现利益必须承担一定的风险。10.1.4 风险管理概述风险管理是指在项目进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合
24、理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的实现。风险管理是一系列对未来的预测，伴随着一系列的活动和处理过程以便控制风险，减少其对项目的影响。风险管理是项目管理的一个重要组成部分，贯穿于项目生存期的始终。1）从项目进度、质量和成本目标看，项目管理与风险管理的目标是一致的。通过风险管理来降低项目进度、质量、成本方面的风险，实现项目目标。2）从计划的职能看，项目计划考虑的是未来，而未来存在不确定因蓁，风险管理的职能之一是减少项目整个过程中的不确定性，有利子计划的准确性。3）从项目实施过程看，不少风险是在项目
25、实施过程中由潜在变成现实的，风险管理就是在风险分析的基础上拟定具体措施来消除、缓和及转移风险，并避兔产生新的风险。10.1.5 风险管理的意义目前，风险管理被认为是软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理，这就提高了项目成功的机会并减少了不可避免风险所产生的后果。只有进行很好的风险管理才能有效地控制项目的成本、进度、产品需求，同时可以阻止意外的发生。这样，项目经理可以将精力更多地放到项目的及时提交上，不用像救火队员一样，处于被动状态。
26、同时，风险管理可以防止问题的出现，即使出现问题，也可以降低其危害程度。可以说你不跟踪风险，风险就跟踪你。正如Tom Gilb所说，“女口果你不主动攻击风险，风险就会主动攻击你”。风险管理可以分为四个层次：危机管理：是在风险已经造成麻烦后才着手处理它们。风险缓解：事先制定好风险发生后的补救措施，但不制定任何的防范措施。着力预防：将风险识别与风险防范作为软件项目的一部分加以规划和执行。消灭根源：识别和消灭可能产生风险的根源。作为一个优秀的风险管理者，应该采取主动的风险管理策略，即着力预防和消灭根源的管理策略，而不应该采取被动的方式，被动风险策略是直到风险变成真正的问题时才会拨出资源来处理它们。更普
27、遍的是，软件项目组对风险不闻不阆，直到发生了错误才赶紧采取行动，试图迅速地纠正镨误，这种管理模式常常被称为“救火模式”。当补救的努力失败后，项目就会处在真正的危机之中。风险管理的一个聪明的策略是主动策略。主动策略早在技术工作开始之前就已经启动了：标识出潜在的风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后软件项目组建立一个计划来管理风险。主动风险管理策略的目标是预防风险。但是，因为不是所有的风险都能够预防，所以项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式做出反应。软件风险管理要求在风险成为影响项目成功的因素之前识别、着手处理卉消除风险的源头，所有
28、的项目都有风险，如果忽视风险，就可能增加项目失败的可能性，或者导致项目不成功。虽然如此，但风险的大小是可以评价度量的，确定可接受风险和不可接受风险，对不可接受风险做进一步分析，制定补偿措施，将风险减至最小或可以接受的水平。软件风险管理过程主要包括风险识别、风险评估、风险规划、风险控制四个步骤。了解和掌握项目风险的来源、性质和发生规律，强化风险意识，进行有效的风险管理，这些对项目的成功具有很重要的意义。10.2 风险识别风险识别是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁，识别已知和可预测的风险，只有识别出这些风险，项目管理者才有可能避免这些风险，且在必要时控制这些风险。每一类风险
29、可以分为两种不同的情况：一般性风险和特定性风险。一般性风险对每一个软件项目而言都是一个潜在的威胁。特定性风险只有那些对当前项目的技术、人员及环境非常了解的人才能识别出来。为了识别特定性风险，必须检查项目计划及软件范围说明，从而了解本项目中有什么特性可能会威胁到项目计划。一般性风险和特定性风险都应该被系统化地标识出来。风险识别要识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。外在风险是指超出项目工作组控制能力和影响力之外的风险，如市场转向或政府行为等。严格来说，风险仅仅指道受创伤和损失的可能性，但对项目而言，风险识别还窑涉机会选择（积极成本）和不利因
30、素威胁（消极结果）。项目风险识别应凭借对“因”和“果”（将会发生什么和导致什么）的认定来实现，或通过对“果”和“因”（什么样的结果需要予以避免或促使其发生以及怎样发生）的认定来完成。风险识别不是一次性行为，而应有规律地贯穿整个项目中。10.2.1 概念风险识别过程见图10-4，其中，风险识别的输入可能是项目的WBS、SOW、项目相关信息、项目计划假设、历史项目数据，其他项目经验文件、评审报告、公司目标等。风险识别常用方法是建立风险条目检查表”，利用用一组提问来帮助项目风险管理者了解在项目和技术方面有哪些风险。此外，还有德尔菲方法、头脑风暴法、情景分析法、面谈法等。风险识别的输出是风险列表。图1
31、0度量4风险识别过程10.2.2 德尔菲方法德尔菲方法又称专家调查法，它起源于20世纪40年代耒期，最初由美国兰德公司首先使用，很快就在世界上盛行起来，目前此法的应用已遍及经济、社会、工程技术等各领域。我们在进行成本估算的时候也用到这种方法。用德尔菲方法进行项目风险识别的过程，是由项目风险小组选定与该项目有关的领域专家，并与这些适当数量的专家建立直接的函询联系，通过函询收集专家意见，然后加以缤合整理，再匿名反馈给各位专家，再次征询意见。这样反复经过四至五轮，逐步使专家的意见趋向一致，作为最后预测和识别的根据。10.2.3 头脑风暴法所谓头脑风暴法，就是以专家的创造性思维来获取未来信，a的一种直
32、观预测和识别方法。此法是由美国人奥斯本于1939年首创，它从20世纪50年代起就得到了广泛应用。头脑风暴法一般是在一个专家小组内进行，通过专家会议，激发专家的创造性思维来获取耒来信息。这就要求主持专家会议的人在会议开始时的发言应能激起专家们的思维“灵感”，促使专家们感到急需回答会议提出的问题，通过专家之间的信息交流和相互启发，从而诱发专家们产生“思维共振”，以达到互相补充并产生“组合效应”，获取更多的未来信，a，使预测和识别的结果更准确。10.2.4 情景分析法情景分析法是根据项目发展趋势的多样性，通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系
33、统发展态势做出白始至终的情景和画面的描述。当一个项目持续的时间较长时，往往要考虑各种技术、经济和社会因素的影响，对这种项目进行风险预测和识别，就可用情景分析法来预测和识别其关键风险因素及其影响程度。情景分析法对以下情况是特别有用的：提醒决策者注意某种措施或政策可能引起的风险或危机性的后果；建议需要进行监视的风险范围；研究某些关键性因素对未来过程的影响；提醒人们注意某种技术的发展会给人们带来哪些风险。情景分析法是一种适用于对可变因奏较多的项目进行风险预测和识别的系统技术，它在假定关键影响因素有可能发生的塞础上，构造多重情景，提出多种未来的可能结果，以便采取适当措施防息于未然。10.2.5 风险条
34、目检查表“风险条目检查表”是最常用也是比较简单的风险识别方法，它是利用一组提问来帮助管理者了解项目在各个方面有哪些风险。在“风险条目检查表”中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险（如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等）。“风险条目检查表”可以以不同的方式组织，通过判定分析或假设分析，给出这些提问的回答，就可以帮助管理或计划人员估算风险的影响。风险条目检查表一般根据风险要素进行编写，包括项目的环境、管理层的重视度、技术情况以及内部因素（如团队成员的技能或技能缺陷等）。风险识别中的风险条目是项目经验的积累，风险条目
35、检查表可以以不同的方式组织。一般说，作为项目经理可以将主要的精力放在以下几方面：产品规模商业影响项目需求客户特性过程定义技术情况开发环境人员数目及其经验其中每一方面包含很多的风险检查条目，通过对每个条目的回答，可以识别项目可能存在的风险。1）产品规模风险检查表项目风险是直接与产品规模戌正比的。下面的风险检查表中的条目标识了与软件规模相关的常见风险：是否以LOC或FP估算产品的规模？对于估算出的产品规模的信任程度如何？是否以程序、文件或事务处理的数目来估算产品规模？产品规模与以前产品的规模的平均值的偏差百分比是多少？产品创建或使用的数据库大小如何？产品的用户数有多少？产品的需求改变多少？交付之前
36、有多少？交付之后有多少？复用的软件有多少？2）商业影响风险检查表下面的风险检查表中的条目标识了与商业影响相关的常见风险：本产品对公司的收人有何影响？本产品是否得到公司高级管理层的重视9交付期限的合理性如何？将会使用本产品的用户数及本产品是否与用户的需要相符合？本产品必须能与之互操作的其他产品系统的数目？最终用户的水平如何？政府对本产品开发的约束是什么？延迟交付所造成的成本消耗是多少？产品缺陷所造成的成本消耗是多少？对于上述产品规模和商业影响的风险检查表中的每一个回答都必须与过去经验加以比较。如果出现了较大的百分比偏差或者如果数字接近过去很不令人满意的绪果，则风险较高。3）需求相关风险检查表很多
37、项目在确定需求时都面临着一些不确定性和混乱。如果在项目早期容忍了这些不确定性，并且在项目进展过程中得不到解决，则这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生锴误的产品或者拙劣地建造正确的产品。每一种情况都会使人不愉怏。例如，需求中潜在的问题包括：对产品缺少清晰的认识。对产品需求缺少认同。在确定需求时客户参与不够。没有优先需求。不确定的需要。新的市场不断变化需求。缺少有效的需求变化管理过程。对需求的变化缺少相关分析。如果对于这些问题中的任何一个问题的答案是肯定的，则需要进一步的研究，以评估潜在的风险。4）客户相关风险检查表不同的客户有不同的需要。有些人
38、只知道他们需要什么，而有些人知道他们不需要什么。一些客户希望迹行详细的讨论，而另外的客户则满足子模糊的承诺。不同的客户有不同的个性。亠些人喜欢享受客户的身份，而另一些人则根本不喜欢作为客户。一些人会高兴地接受几乎任何交付的产品饣并能充分利用一个不妤的产品；而另一些人则会对质量差的产品猛烈抨击。一些人会对质量好的产品表示赞赏，而另一些人则不管怎样都抱怨不休。客户和供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商！而另一些人则可能綦未谋面，仅仅通过信件来往和电话与生产厂商沟通。一个“不好的”客户可能会对一个软件项目组能否在预算内完成项目产生很大的影响。对于项目管理者而言，“不好的”客
39、户是对项目计划的巨大威胁和实际的风险。下面的风险裣查表中的条目标识了与客户特征相关的常见风险：你以前是否曾与这个客户合作过？该客户是否很清楚薷要什么；他能否花时间把需求写出来？该客户是否同意花时间召开正式的需求收集会议，以确定项目范围？该客户是否愿意建立与开发者之间的快速通信渠道？该客户是否愿意参加复审工作？该客户是否具有该产品领域的技术奏养？该客户是否愿意让你的人来做他们的工作？该客户是否了解软件过程？如果对于这些问题中的任何一个问题的答案是否定的，则需要进一步的调研，以评估潜在的风险。5）过程风险检查表如果软件过程定义得不清楚，如果分析、设计、测试以无序的方式进行，如果质量是每个人都认为很
40、重要的概念但没有人切实采取行动来保证它，那么这个项目就处在风险之中。过程问题包括：高级管理层是否有一份已经写好的政策陈述，该陈述中强调了软件开发标准过程的重要性？开发组织是否已经拟定了一份已经成文的、用于本项目开发的软件过程的说明？开发人员是否同意按照文档所写的软件过程进行开发工作，并自愿使用它？该软件过程是否可以用子其他项目？管理者和开发人员是否接受过一系列的软件工程培训？是否为每一个软件开发者和管理者提供了印妤的软件工程标准？是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？是否定期对需求规约、设计和编码进行正式的技术复审？是否定期对测试过程和测试情况进行复审，是否对每一次正
41、式技术复审的结果建立了文裆，其中包括发现的错误及使用的资源？有什么机制来保证按照软件工程标准来指导工作？是否使用配置管理来维护系统软件需求、设计、编码、测试用例之间的一致性？是否使用一个机制来控制用户需求的变化及其对软件的影响？对子每一个承包出去的子合同，是否有一份文档化的工作说明、一份软件需求规约和一份软件开发计划？是否有一个可遵循的规程，来跟螓及复审子合同承包商的工作？技术问题包括：是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信？b是否使用特定的方法进行软件分析？是否使用特定的方法进行数据和体系结构的设计？是否90以上的代码都是使用高级语言编写的？是否定义及使用特定的规则进行代
42、码编写？是否使用特定的方法进行测试用例的设计？是否使用配置管理软件工具控制和跟踪软件过程中的变化活动？是否使用工具来创造软件原型？是否使用软件工具来支持测试过程？是否使用软件工具来支持文档的生成和管理？是否收集所有软件项目的质量度量值？是否收集所有软件项目的生产率度量值？如果对于上述问题的答案多数是否定的，则软件过程是薄弱的且风险很高。6）技术风险检查表采用新技术是具有挑战性和令人兴奋的，但这也是有风险的。下面的风险检查表中的条目标识了与建造的技术相关的常见风险：该技术对于你的公司而言是新的吗？客户的需求是否需要创建新的算法？待开发的软件是否需要使用新的或未经证实的硬件接口？待开发的软件是否需
43、要与开发商提供的未经证实的软件产品接口？待开发的软件是否需要与功能和性能均未在本领域得到证实的数据库系统接口？产品的需求是否要求采用特定的用户界面？产品的需求中是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同？需求中是否要求采用新的分析、设计、测试方法？ 需求中是否要求使用非传统的软件开发方法？需求中是否有过分的对产品的性能约束？客户能确定所要求的功能是可行的吗？如果对于这些问题中的任何一个问题的答案是肯定的，则需要进一步的调研，以评估潜在的风险。7）开发环境风险检查表软件工程环境支持项目组、过程及产品，但是，如果环境有缺陷，它就有可能成为重要的风险源。下面的风险检查表中的条
44、目标识了与开发环境相关的风险：是否有可用的软件项目管理工具？是否有可用的软件过程管理工具？是否有可用的分析及设计工具？分析和设计工具是否适用于待建造产品？是否有可用的编译器或代码生成器？是否有可用的测试工具？是否有可用的软件配置管理工具？环境是否利用了数据库或数据仓库？项目组的成员是否接受过每个所使用工具的培训阳是否有专家能够回答有关工具的问题？工具的联机帮助及文档是否适当？如果对于上述问题的答案多数是否定的，则软件开发环境是薄弱的且风险很高。8）人员数目及经验风险检查表下面的风险检查表中的条目标识了与人员数目及经验相关的常见风险：是否有最优秀的人员可用？人员在技术上是否配套？是否有足够的人员
45、可用？开发人员是否能够自始至终地参加整个项目的工作？项目中是否有一些人员只能部分时间工作？开发人员对自己的工作是否有正确的期望？开发人员是否接受过必要的培训？开发人员的流动是否仍能保证工作的连续性？如果对于这些问题中的任何一个问题的答案是否定的，则需要进一步的调研，以评估潜在的风险。当然，检查表的类别和条目可以根据企业或者项目的具体情况来选择或者开发。例如，美国的软件工程研究所（简称SEI）的一份研究报告对于软件风险提出用Class、Elcment、Attributc三个层次描述风险列表（见图105）。对于Class（类）层分三组，即ProductEnginccring、Dcvclopment
46、 Environmcnt和Program Constraints。每个Class组下包含若干Elemcnt（元素），每个Elemcnt组下又包含若干Attributc（属性）。它们共同构成了风险检查表条目，通过Attributc属性值来识别和评估风险。具体条目要素见表101。图10度量5风险三层分析结构表亻0丬 三层风险检查表类（Class）元素（ElCmcnt）属性（Attributc）产品工程（Product Enginccring）需求（RCquiremcnts）稳定性Stability）完整性（Completencss）清晰性Clarity）有效性（validity）可行性（Feasibility）前瞻性（Precedent）衡量性（ScalC）设计（DCsign）功能性（Functionality）难度（Difficu1ty）接口（Intcrfaccs）性能（PCrforman）易讽！性（Tcstability）硬件的限制（Hardwarc constraints）非开发软件（Non Devclopmcntal software）编码和单元测试（Codc and unittc
