项目风险管理

项目风险管理在现代项目管理中，项目管理人员引入了风险管理技术，强调对项目目标的主动控制，以对项目实现过程中遭遇的风险和干扰因素可以预防作用，从而减少损失。 一、 风险的定义：所有影响项目目标实现的客观不确定性事件或因素的集合，是在项目管理中不希望发生的。二、 风险管理的定义：风险管理是在项目期间识别和控制能够引起不希望的变化的潜在领域和事件的形式、系统的方法。三、 风险管理办法：在项目管理中建立风险管理管理策略和规划，并在项目的生命周期中不断控制风险是非常重要的。通常可以分为四个阶段：风险识别、风险评估、风险量化处理和风险监督。四、 风险管理规划：风险管理规划是规划和设计如何进行项目风险管理的过程。该过程包括定义项目组织及成员风险管理的行动方案以方式，选择适合的风险管理方法，确定风险判断的依据等。风险管理规划的依据：1、项目规划中包含或涉及的有关内容，如项目目标、项目规模、项目利益相关者情况、项目复杂程度、所需资源、项目时间段、约束条件及假设前提等可作为规划的依据。 2、项目组织及个人所经历和积累的风险管理经验及实践。3、决策者，责任方及授权情况。4、项目利益相关者对项目风险的敏感程度及可承受能力。5、可获取的数据及管理系统情况6、风险管理模板，以使风险管理标准化、程序化。风险管理规划的方法及内容：风险管理规划一般通过规划会议的形式制定。风险管理规划将针对整个项目生命周期制定如何组织和进行风险识别、风险评估、风险量化、风险应对计划及风险监控的规划。风险管理规划应包括：方法、人员、时间周期、类型级别及说明、基准、汇报形式、跟踪。 五、 风险识别：风险管理的第一步是识别和评估潜在的风险领域，这是风险管理中最重要的步骤。风险识别要系统地、连续地识别它们；风险识别包括列出所有与项目相关的过程、客户及存在的问题。风险识别包括确定风险的来源、产生条件，风险识别不是一次就可以完成的事，应在项目的自始至终定期进行。项目风险是每个人和风险因素的结合体。风险产生于猜测的结果和现实的偏离。风险可以简单地分为静态风险和动态风险。静态风险是自然力的不规则作用和人们的错误判断和错误行为导致的风险；动态风险是由于人们欲望的变化、生产方式和生产技术的变化，以及企业组织的变化导致的风险。风险的另外一类分法：可以分为纯粹风险和投机风险。纯粹风险是当风险发生时，仅仅会造成损害的风险；而投机风险是当风险发生时，可能造成利润也可能造成损失的风险。当然，他们还可以进一步细分。现在，人们习惯上说的风险是指那些可能对项目产生负面影响的风险源。如技术风险、质量风险、过程风险、管理风险、组织机构风险、试场风险及法律法规变更等。项目的风险种类应能反映出项目所在行业以应用领域特征。风险识别的常用方法是建立：潜在损失一览表。 风险识别的方法：1、 问询法（头脑风暴法、面谈法和德尔菲法等）2、 财务报表法（各种财务报表和记录）3、 流程图法（网络图或 WBS 法）4、 现场观察5、 历史资料（索赔记录及其他风险信息）6、 环境分析法（相关方和社会环境变化趋势，可能变更的法律法规）等。六、 风险评估：风险评估常用的方法有：1、 概率分布（专家预测）2、 外推法（使用历史数据）3、 定性评估4、 矩阵图分析5、 风险发展趋势评价方法6、 项目假设前提评价及数据准确度评估七、 风险量化和处理：依据风险管理计划、风险及风险条件排序表、历史资料、专家判断及其他计划结果，利用面谈、灵敏度分析、决策分析和模拟的方法和技术、得出量化序列表、项目确认研究，以及所需应急资源等量化结果。风险量化后，要进行风险评价，常用方法有：1、 项目风险费用分析2、 项目风险评价准则3、 风险评价的策略分析法4、 风险评价的层次分析八、 风险监控风险监控就是要跟踪识别的风险，识别剩余风险和出现的风险，修改风险管理计划，保证风险计划的实施，并评估消减风险的效果。风险监控依据风险管理计划、风险应对计划、附加风险识别和分析、项目审计，利用核对表、定期项目风险评估、挣值分析、附加风险应对计划和独立风险分析，得出工作计划、纠正计划、项目变更请求、风险应对计划更新等成果。项目遇险的 3 个问题， 4 个因素和 8 个信号作者： BUILDER.COM (ZDNet)April 23 2002 三个问题篇在你的职业生涯里，总有些时候需要你当机立断地终结一个失败的开发项目。当然，那是我们最希望避免出现的结果。从好的方面看失败会令人沮丧，从坏的方面看项目的完蛋或许会威胁到你的职业安全性了。如果你能采取行动拯救一个项目，那么你就可能有机会影响项目的成败。然而，除非你是项目经理，否则你只能束手无策。不过，你倒可以想法了解迫近的问题以便寻找机会逃跑。这篇文章阐述了 3 个同业务有关的预警信号，希望它们能有助于你看清项目是否在走向崩溃。虽然这些总结并不太具备科学意义上的准确性，但是，这些迹象能为你提供一些早期警告。而且，尽管你无法拯救项目但你或许能通过这些警示拯救你自己。在文章的末尾还提出了一些建议性的应对措施，这样一来，万一你发现自己正身陷项目失败的泥沼，那么你好歹可以采取相应的合理行动自救。概述针对成功的 IT 项目的统计报告不具备太大的意义。根据 Standish 商业研究公司的一份报告，将近三分之一的信息系统项目在最终完成之前都被取消了。另外，在所有的项目中几乎有一半左右会超出其预算。令人惊讶的是，项目失败的原因很少同技术有关。在软件管理手册 Peopleware: Productive Projects and Team 一书中，作者之一 Tom Demarco 提醒读者注意，大多数项目都是因为技术以外的其他原因而招致失败的。可是，既然不是技术原因造成的项目失败，那么又该是什么原因令这些项目失败的呢？答案是项目所牵扯的人和工作过程。具有讽刺意味的是，普通开发人员在处理技术问题的时候应对有道但他们在同其他人以及工作流程打交道的时候却不是这样。问题 # 1 ：缺乏有意义的商务案例真的叫人很吃惊，有些项目从一开始就找不出有意义的商务案例来支持它们。商务案例很重要，因为它为项目提供了基础。商务案例应该能提出效益分析，同时还能考虑到商业风险和项目之外事件的影响。机构会采用商务案例把它们有限的资源划分出优先级别从而为其提供最大回报。这样说来，在没有商务案例的情况之下，一个项目该如何起步呢？这也是可能的，因为项目的商业属主也许仅仅是需要实现什么特定的目标，而且有能力达到自己需要实现的目标。另外还有一种可能性，那就是IT 机构认为商业单位需要它因此它们自己先创建出来再说。最近两年，因为许多人相信他们必须开发某些项目来维持竞争力，所以好多同 Web 关联的项目在不存在商务案例的情况下就纷纷上马了。那争先恐后的样子就好象不奋力一搏就赶不上趟似的，“.com”的崩溃意味着商务实践回归原来的基础，这其中自然也包括商务案例。对策：探询你目前着手的项目是否受到了商务案例的支持。找一份商务案例来仔细阅读它。你所在项目的商业动力是什么？这一商务案例符合逻辑而且可理解吗？该商务案例存在怎样的前天条件？其风险是什么？什么外部因素会影响商务案例？如果你无法为自己的项目找到可理解、有意义的商务案例，那么你得知道为什么没有开发出有关的商务案例。问题 #2 ：没有获得同意的需求或系统规范缺乏需求确实是一件非常危险的事情。在 Standish 的报告里，挑战项目正常运行的三个最常见因素都和系统需求有关。系统需求能给出将要创建的系统的大小和结构。它们定义了系统应该和不应该实现的任务。需求管理就是在整个项目周期之内定义、记录、追踪以及管理需求的过程。需求管理保证了最终的解决方案能够满足用户的需要。对策：密切注意你的需求管理过程。如果看起来没人负责管理系统的需求，或系统的需求老是在变，那么你可能会遇到麻烦了。 问题 #3 ：缺乏项目计划有些项目竟然会在没有项目计划的情况下运做。这简直就是不用图纸造房子。每个项目都是一个事业，都应当具备相应的项目计划。项目计划对那些项目决策人来说是非常必要的交流手段，项目计划为项目的进展以及确定需要进一步完成的其他工作提供了指导。有一种说法称不需要告诉有关开发人员具体的计划内容；他们只需要知道做什么就可以。这种看法对只有一个人的项目队伍来说管用，但要做大事就站不住脚了。开发人员确实需要接受计划的指导。他们想要知道什么任务排在前面。他们不想猜测哪些东西是最重要的。仅仅有了一个计划还是不够的：计划必须跟随项目的发展保持最新状态。举个例子吧，有些项目刚开始的时候房间里贴满了五花八门的甘特图和波特图，结果几个月乃至数年过去了这些图表还是老样子放在那里，没有任何变化。这可不是一个当前计划。为了让计划与时俱进，项目计划就必须反映实际完成的工作，同时还要预计将要完成的工作。计划更新的频率倒不至于达到每周一次的程度，但也不能低于每两周一次。计划应该准确地反映完成项目的时间和开销。只有在这样的情况下才可以说计划保持在最新的状态。过于频繁变更的计划同过期的计划一样令人恐惧。我曾经见过这样的项目计划，该项目计划每周都要修改，结果把项目的阶段终止日期超出了一周的范围。计划每周都在更新，但项目工程仍然失去了控制。对策：如果没有公开的项目计划你无论如何得赶快弄出一个来。如果你被告知，因为信息的机密性你不能查阅项目计划，那么，你不妨把这一事件看做一个严重的警示迹象。除非你在开发新一代的原子弹，否则秘密项目计划根本没有存在的道理。保持信息的隐秘通常意味着管理层知道项目出了问题，他们正试着把问题掩盖起来。一定要保证计划常新而且还得具有合理的更新间隔。它不该是个不断变动的目标，但它一定得是最新的。如果你不能保证项目计划的最新状态，那么项目会出问题的。项目快完蛋了，我该怎么办？你发现自己的项目已经出现了以上一个或者多个预警信号吗？对这个问题的回答取决于你的个人状况。如果你感到你能采取行动改变现状，那么你一定要立即行动。同项目经理、顾客或你队伍中的其他成员对话。用一种就事论事、不具威胁性的方式讨论你所关心的问题。试着尽可能提出正面意见。看看你能否给项目带来转机。如果项目濒于失败而且你发现自己没有办法控制事态的发展，那么你最好想办法离开现在的项目。你也许能在同一家机构内找到一个好一些的项目，要不你干脆离开现在的单位算了。反正走为上策。到这份儿上已经不是告诉某人该如何运做项目的时候了。如果你粘在项目上了，或者正等着走人，那你也不妨换个看问题的角度。就当你在长经验吧。比方说，你能从现状中获得什么？如果得到授权你将采取什么行动改变现状？将来你该如何避免撞上这样的项目？从当前项目进展中学到的知识和掌握的经验必定能在你着手的将来项目上给你带来莫大的帮助。仅仅是个开始以上的 3 个问题主要牵扯到业务和计划方面，但是，项目遇险的迹象还并不止于这些。接下来，我们将继续讨论在失败的项目中涉及到用户和项目主管人员的 4 个因素，讨论下这些因素是如何给你提出项目遇险警告的。四个因素篇总有一些项目会最终获得成功，可是，相当大数量的项目却没这么好的命。如果你不幸遭遇到这样的处境，在事情恶化到不可收拾之前你如何知道项目遇到危险了呢？在项目遇险的三个信号一文里，谈到前景不妙的某些项目时，我们已经针对和业务有关的迹象做了阐述。接下来，我们继续探讨一些牵扯到项目人员的危险迹象，它们大致上可以表现为 4 种预警信号。导致项目失败的大部分原因不在于技术而在于同项目有关的人和过程，认为到这些更具“软性”的问题是相当重要的。具体地说，其原因同用户和项目发起人以及缺乏开发人员之间的交流有关（改变管理和工作报告）。如果你发现自己涉及的项目已经出现这样的迹象，那就表明项目正在滑向失败的边缘了。问题#1：你的客户或用户组不跟你说话客户或用户不和你交流只能说明情况不妙。这意味着他们几乎毫无积极性。不过也可能说明业务组太关注于具体的工作或者太忙了，难以同你合作，这就是说。如果正是那样的情况，那么项目正在向灾难迈进了。你必须同客户和用户合作，这样才能成功地实现项目。缺乏用户的参与只能意味着用户抗拒变动。我们知道，所谓的“变动管理”，就其全部领域而言就是建立在赢得最终用户的支持以及接受新系统和过程的基础之上。这一方面不应该与被用来管理项目范围的变动控制过程相混淆。变动管理不在这篇文章所涉及的范围之内。但我们必须清楚地认识到，系统要想得到有效的实现就必须把用户包含进来。其他原因也可能造成客户或用户缺乏参与精神。比如，具体的业务决定了项目不得不取消或者实现一个不同的解决方案。项目赞助者可能让用户远离项目，原因是系统实现之日就是他们失业之时。任何项目都需要获得客户或用户的输入信息，没有它，系统需求和设计就等于在真空中呼吸。最终的解决方案根本不可能满足业务需要。如果你的客户或用户没有在项目上与你一道工作，显然。你的麻烦来了。问题#2：项目发起人效率低或者角色不明确有一位良好的项目发起人是项目成功交付的一个关键因素。他或她有助于项目目标的集中，为团队搬走主要的绊脚石，从企业政治上讲尤其如此。项目发起人必须有清除障碍的能力，他们一定得有权力在利益发生冲突的情况下解决问题。他们还需要做出坚定的决策支持开发队伍。如果项目没有明确的发起人，在开发过程中那些形形色色的障碍就必然会影响项目的进展。企业政治也会开始给团队和工作说事。在项目发起人离开公司的情况下更会产生很多的问题。发起人为什么要离开公司？他或她是被迫出走的吗？发起人的政敌会试图停止项目或者改变其范围吗？你的职业将会受到这些政敌的影响吗？也许你压根就不打算继续逗留在这里非要弄出个子丑寅卯。问题 #3 ：没有管理变动的机制我们都知道，项目发生变动是不可避免，管理项目的变动非常重要。优秀的变动控制过程并难于管理，但是它们确实需要对细节保持关注。高效的变动控制要求同客户或软件解决方案的商务属主密切合作。不幸的是，某些项目仍然在没有管理变动的过程的情况下运转。要不就是项目的范围含糊不清，或者不讨论变动控制，或者客户或业务主人不断地根据自己的意愿改变解决方案。没有变动控制过程的项目是不可能得到准确估计的，这是因为解决方案的规模总在不断地变动之中。另外，变动通常会导致某些重复性的工作，从而进一步推迟了开发过程令项目团队失去动力。记住，客户不是变动的唯一来源。有时团队自身也能引起范围的变动。毕竟，团队成员也是人，而人总会犯错误的。团队的成员可能听说或“假设”解决方案因客户的实际要求而发生了变动。另外还有一种可能，那就是项目需求比较含糊，因此团队成员从不同方面对其进行解释。或者，团队成员可能无意中创造出一个相比客户需求更漂亮或更复杂的解决方案。这就是所谓的“镀金”操作。如果你所在的团队没有执行变动策略，你应该问一下原因何在。如果你找不出答案，那可要警惕了，项目很可能正在失去控制而且失败的风险显著增大了。问题 #4 ：没有准确的工作报告准确的工作报告是项目的活命源。这些报告把有关的信息报告给负责人，同时提供一种有效的机制来确定是否采取正确的行动。准确的工作报告还能起到记分卡的作用，可以显示出项目的计划完成情况。所有的项目都需要工作报告。为什么项目绝对离不开工作报告呢？主要有两个原因：项目经理需要认识到项目的需求，或者工作不妙以至于项目经理决定干脆啥也不说了。在这两个原因之中，后者可能更坏。如果某个项目落在了既定目标之后或者超出了预算而有没有上报，显然这样的项目不如取消。如果你的项目缺乏工作报告，我看也没什么必要找出原因了。你赶快跑吧。项目陷入麻烦该怎么办？如果你不是项目经理，那么你对濒临失败的项目只能无可奈何。然而，如果你确定项目已经遇到麻烦了那么你应该采取一些行动。如果你的用户拒绝参与项目，或者没有给你足够的项目运做时间，那么你应该同项目的用户方做一番开诚布公的对话。虽说不一定就能拯救项目但也不至于给项目造成伤害。寻找可以转移的其他项目（反正比你现在的好一些）。顺便说一句，别到处说你为什么离开当前的项目。事成之后，每个人都会认为你采取了正确的行动。 如果事情糟透了，请打其他公司项目的主意吧。如果你一直坚守在某个一两年之后就濒于完蛋的项目之内，它对你的身体、精神或职业都不会带来半点好处。现在就采取行动。如果你不能拯救项目至少得拯救你自己。八个信号篇作为项目经理，当你面对成堆的 Microsoft Project 工作任务报告时，想到已经花了好几个小时陷入在扯不清、说不明的项目工作会议的泥沼之内，也许这是你感觉最令人恼火和沮丧的时刻。可是，像这样的痛苦会议还不仅仅意味着一种失败感。它们的本质问题可能掩盖得更深，这些问题会最终毁灭你经手的项目。这里我想与你一道分析和了解项目即将陷入困境的一些迹象：没有引人注目的业务案例。那种“超酷”的 Flash 网站在增加业务收入方面的作用值得怀疑。 自作主张地编写代码。如果你不同意业务需求或系统规范，你怎么知道所交付的工作或规范是最新的？实际上你不可能知道。 没有项目规划。这是针对项目经理的。比如说，通过电子邮件交流的内容俨然成为系统的功能规范。这简直是没有蓝图就造房子。 你和你的顾客各说各话。发生这种情况时，你必须打消咒骂项目发起人家庭成员的欲望（比如谁谁母亲的）。 项目发起人生活在“洞穴”里。当你需要额外资源时就知道这将造成多大的损害了！当你的老板要求给项目提供更多资助时，老板的老板却只是眨巴眼睛想想看，这有多糟糕。 不能应对变化的管理系统：调试程序是小儿科。此外，我的代码运行绝对正确！这可能吗 没有进度报告系统。你蹒跚前行，根本没有什么准确的项目进度报告系统，也许唯一的解释就是到目前为止，压根就没人想提到这个项目。 在项目工作会议上，与会人员只会扯皮说“都是接口问题”、“必须采取行动”以及“该找某某人”。 当然，单独地看，出现这些症状并不意味着你的项目必死无疑。但它们确实都是需要你立即采取行动的红色警报。如果你的项目出现了以上 8 个症状，那么只能说你已经在泰坦尼克号上了。准备自救吧。风险评估报告摘自小柯设计工作室 引言 本文档的范围和目的 本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。 由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。 主要风险综述 任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。 软件管理将影响到软件的下列因素： 软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。 软件体系结构影响到软件的如下质量因素： 软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。 软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。 软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。 项目管理的风险 软件项目管理的风险来自于软件项目自身的特点： 软件产品不可见：开发的进展以及软件的质量是否符合要求难于度量，从而使软件的管理难于把握。 软件的生产过程不存在绝对正确的过程形式：可以肯定的是不同的软件开发项目应当采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。 大型软件项目往往是“一次性“ 的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。 一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下： 参与者 项目经理 1 人 主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环节。 项目负责人 1 人 主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发 计划的按时完成和开发策略的真正贯彻落实。 领域专家 1 或 2 人 主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特定检测点进行 算法审核，同时对测试策略和软件操作界面提出参考意见。 质量监督组 1 或 2 人 主要职责：编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文档，监督项目 实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责人审阅；对于项目中出现 的质量问题，主持召开质量复审会议。 系统分析员 1 或 2 人 主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。 程序员 2 或 3 人 主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。 测试员 2 或 3 人 主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。 技术支持 2 或 3 人 主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。 文档组 1 或 2 人 主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进行软件质量监督。 通过适当的人员配备和职责划分，能有效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。 软件技术风险 本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的 COM 组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。 回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时采用“范例“方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。 软件过程风险 软件需求阶段的风险 软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成用户需求这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。 设计阶段的风险 设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完 成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。 设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个