软件项目管理课件

软件项目管理

第2讲：立项

主要内容立项的概念项目的来源项目的范围项目的收益项目立项协议案例分析立项的前提1.市场需要一家游戏软件公司鉴于目前网络游戏市场火爆，建议开发一个新的网络游戏软件。2.经营需要移动通讯公司为了增加增值业务的收入而启动一项新的增值业务服务的项目。3.顾客需求银行为了方便用户网上交易而准备开发的网上银行项目。4.技术进步把一个DOS下的软件升级到Windows平台上的项目。5.法律要求为了确保网上交易的安全性而开展的数字证书项目。项目的来源合同项目公开竞争性招标有限竞争性招标直接签订合同研发项目公司的决策市场人员的建议技术人员的建议合同项目招标招标准备阶段投标准备阶段开标评标阶段决标签约阶段研发项目的决策项目申请书项目可行性分析技术委员会的评审项目范围项目范围的主要内容1.项目的合理性说明2.项目目标3.项目可交付成果项目范围的依据合同规范SOW确定项目范围的作用确定项目的基本框架，使项目所有者或项目管理者能够系统地、逻辑地分析项目关键问题及项目形成中的相互作用要素，使得项目的有关利益人员在项目实施前或项目有关文件书写前，能就项目的基本内容和结构达成一致。产生项目有关文件格式的注释，用来指导项目有关文件的产生。(形成项目结果核对单，作为项目评估的一个工具，在项目终止以后或项目最终报告完成之前使用，以此作为评价项目成败的判据。可以作为项目整个寿命周期中监督和评价项目实施情况的背景材料，作为有关项目计划的基础。明确项目范围的重要性后期维护是否属于软件开发项目范围必须在项目责任书里明确不属于项目范围以内的事，尽量不要做，搞不好是费力不讨好项目的收益项目成本预算收益分析风险评估项目成本预算预算步骤确定项目的总成本要对项目每一个工作包的成本分摊进行细化在整个期间进行每一个工作包的预算分配预算方法自上而下法自下而上法收益分析公司的收益项目开发出来的软件产品直接带来经济效益为公司积累了项目经验和软件资产为公司锻炼和培养了开发团队建立了客户关系项目组的收益通过做项目而获得报酬积累了做项目的经验学习了新的知识实现了自我的价值建立了客户关系风险评估项目目标是否明确项目验收标准不明确项目经费或项目经费支付方式不明确

项目组成员不稳定项目收益的准则利益的一致性先小人后君子项目管理经费的含义项目立项协议项目合同总额支付合同可报销成本加酬金合同直接报销费用工资及劳务费奖金项目责任书项目合同组成合同目的责任与义务实施方式付款条件违约责任保密责任版权及版权收益分配项目验收标准项目责任书项目基本情况技术方案主要功能要求主要文档资料要求主要技术要求项目进度要求项目验收要求及办法项目组人员薪酬项目组人员组成项目立项确认赵晓东的烦恼海正公司签了一个100多万的单子，但没有签订合同客户部门不配合内部管理无职权解决的办法造势：创造良好的施工环境尚方宝剑：明确责权利合同的评审主要内容项目策划的基础项目组的需要计划与安排立项的复习案例分析有一个客户有开发进销存管理系统，你为一个软件公司的技术骨干，你了解了这个信息，你如何获得该项目，并进行有效的立项运作。项目策划的概念项目策划的概念软件项目策划是为了完成软件工程和管理软件项目而制定合理的计划、规章与规范，并根据计划落实开展项目所需要的各种资源。项目策划的主要内容策划内容包括对工作产品和任务的估算、资源需求、谈判约定等内容，最终产生计划文档、时间表及相关其他文档。项目策划的难处公司的难处软件难以卖起价不合理的交付时间为他人作嫁衣裳糟糕的市场环境项目组的难处生活的压力日益激烈的竞争与时间赛跑不规范的职场克服困难的办法周密的计划，细心的管理，实时的监控，再加上合理的加班。项目策划的对象人财物关系人人的需要分析项目人员真正的需求，确定项目需要的岗位和职能人的选用能够选用合适的人员是项目经理的一个很大的能力人的需要（1）核心人员项目经理系统分析师架构设计师紧缺人员公司所缺乏的，但业界不缺乏业界缺乏的人员测试人员测试工程师测试程序员人的需求（2）项目经理系统分析师架构设计师软件设计师程序员测试工程师测试员配置管理员质量保证员产品发布工程师项目实施工程师培训师美工……人员需求样例岗位数量知识和技能工作和责任需求时间已选用人员系统分析员2清楚远程教育资源规范熟悉远程教育应用精通java编程，熟悉J2EE方案、Weblogic及XML技术，能熟练使用RationalRose进行分析设计解析远程教育规范需求分析业务指导……2001-2-1张三系统设计员3精通java编程，熟悉J2EE方案、Weblogic及XML技术，能熟练使用RationalRose进行分析设计了解远程教育资源规范系统结构设计模块设计组件设计类设计2001-3-10李四模块开发人员A21、有JAVA和数据库开发经验，熟悉JDBC开发，能熟练用JBUILDER开发数据库事务处理的EJB组件数据管理组件的实现单元测试……2001-6-1王五模块开发人员B3有JAVA开发经验、熟悉XML规范，掌握用DOM和SAX处理XML文档技术熟悉servlet和javabeans业务组件的实现单元测试……2001-6-1页面设计人员4熟悉Java编程熟悉JSP熟悉利用样式表开发页面页面设计单元测试……2001-5-1美工1有美术功底能够制作gif和flash……页面布局设计页面中的图片设计界面美化2001-5-1测试员3有JAVA开发经验熟悉Junit……集成测试系统测试配置管理相关文档整理赵六人的选用从组织内部选用人员招聘人员合同工临时工培训人员财落实项目经费预算确定预算授权启动经费项目经费的使用计划预算分配使用标准授权制度项目的成本效益分析物计算机资源网络环境软件资源技术资料关系上级关系合作部门关系客户关系项目组成员关系项目需要的建议选人宁缺勿滥选同事，不要选朋友不要轻易承诺，重在行动不做无米的巧妇项目工作分解结构项目分解的概念项目组在项目实施期间要完成的工作或要开展的活动的一种层次性、树状的项目活动描述。项目分解的工作和活动指明各种软件分量如何安置在软件系统中；反映软件产品的基本结构，由软件设计者确定；分量有：程序(routine)、模块、子系统等。项目分解的方法纵向分解按照软件工程的阶段划分工作任务，然后在每个阶段中对工作进行细化，可以按照软件功能模块进行细化，也可以按照工作性质进行细化，还可以两者相结合。横向分解软件项目横向分解方法是根据软件系统的功能模块组成来分解工作任务。首先确定软件系统的第一层大的模块，然后大的模块下面有可以分为一些小型模块。纵向分解横向分解工作量的估算估算的类型类比。使用一个和多个类似项目的实际工作量来对本项目进行估算。经验方法。使用组织上的或个人（专家）方面的经验和指导，以组织内的大量项目作为基础，导出本项目的估算。例如德而费（Delphi）估计就是采用是经验方法。参数模型。使用产品的一些性质如代码行数，作为模型的参数（或输入），预测该产品的所需的工作量。估算的方法代码行的估算方法德而费估算法功能点估算对象点方法代码行估计从上到下细化模块凭经验估计最小模块的代码行项目的技术方案和需求已基本确定德而费估算法组成项目估算小组。提供软件系统的相关情况项目估算小组每一个成员对每一个成员对项目的每个部分进行独立估计调整汇总评估结果工作或活动最小估计最大估计最可能估计％差别最终估计值＝（最小估计值＋4×最可能估计值＋最大估计值）/6功能点估算评估产品所需要的内部基本功能和外部基本功能的复杂度基于复杂性因子（也称为权）对它们进行量化使用一个刻度因子把它转化为代码行功能点估计（1）项目低中高外部输入346外部输出457外部查询346外部界面5710内部文件71015评估产品所需要的内部基本功能和外部基本功能的复杂度（UFC）功能点估计（2）基于复杂性因子（也称为权）对它们进行量化（TCF）序号影响因素（Fi）影响程度（0-没有，1-偶有，2-轻微，3-平均，4-较大，5-严重）1系统是否需要可靠的备份和恢复？2是否需要数据通信？3是否有分布处理的功能？4性能很关键吗？5系统是否运行在一个既存的高度民实用化的操作环境中？6系统是否需要联机数据项？7联机数据项是否需要建立多重窗口显示和输入,处理？8主文件是否联机更新？9输入、输出、文件或查询是否复杂？10内部处理过程是否复杂？11程序代码是否可复用？12设计中是否包括了转移和安装？13系统是否设计成可以重复安装在不同机构中？14系统是否设计成易修改和易使用？复杂度调整值（合计）功能点估计（3）最终复杂性因子：TCF＝0.65＋0.01×∑14i=1Fi功能点的计算公式：FP＝UFC＋TCF功能点与代码行转换表语言Fi语言FiASSEMBLY320ADA71C150PL/165COBOL105PROLOG/LISP64FORTRAN105SMALLTALK21PASCAL91SPREADSHEET6对象点估计分析对象点的复杂性分析功能对象的复杂性对象点估计表(LOC)方法种类很小小中大很大计算2.345.1311.2534.6654.04数据2.604.798.8416.3130.09I/O9.0112.0616.1521.6228.93逻辑7.5510.9815.9823.3533.83设置3.885.046.568.5311.09文本3.758.0017.0736.4177.66功能对象矩阵(CNT)的构造方法使用产品需求，构建一个体系结构或概念设计；对该设计中每一类（面向对象方法中的class）的输入和交互，标识所涉及的对象属于对象估计点表中的哪类方法；估算以上标识的每一方法的复杂性；将结果填入到矩阵CNT相应的表格中。对象点估计计算公式LOC为对象点估计表CNT为功能对象矩阵主要内容项目估算计划的内容软件项目策划存在主要问题分析案例分析立项的复习项目策划的对象工作量的估算估算的类型类比。使用一个和多个类似项目的实际工作量来对本项目进行估算。经验方法。使用组织上的或个人（专家）方面的经验和指导，以组织内的大量项目作为基础，导出本项目的估算。例如德而费（Delphi）估计就是采用是经验方法。参数模型。使用产品的一些性质如代码行数，作为模型的参数（或输入），预测该产品的所需的工作量。估算的方法代码行的估算方法德而费估算法功能点估算对象点方法代码行估计从上到下细化模块凭经验估计最小模块的代码行项目的技术方案和需求已基本确定德而费估算法组成项目估算小组。提供软件系统的相关情况项目估算小组每一个成员对每一个成员对项目的每个部分进行独立估计调整汇总评估结果工作或活动最小估计最大估计最可能估计％差别最终估计值＝（最小估计值＋4×最可能估计值＋最大估计值）/6功能点估算评估产品所需要的内部基本功能和外部基本功能的复杂度基于复杂性因子（也称为权）对它们进行量化使用一个刻度因子把它转化为代码行功能点估计（1）项目低中高外部输入346外部输出457外部查询346外部界面5710内部文件71015评估产品所需要的内部基本功能和外部基本功能的复杂度（UFC）功能点估计（2）基于复杂性因子（也称为权）对它们进行量化（TCF）序号影响因素（Fi）影响程度（0-没有，1-偶有，2-轻微，3-平均，4-较大，5-严重）1系统是否需要可靠的备份和恢复？2是否需要数据通信？3是否有分布处理的功能？4性能很关键吗？5系统是否运行在一个既存的高度民实用化的操作环境中？6系统是否需要联机数据项？7联机数据项是否需要建立多重窗口显示和输入,处理？8主文件是否联机更新？9输入、输出、文件或查询是否复杂？10内部处理过程是否复杂？11程序代码是否可复用？12设计中是否包括了转移和安装？13系统是否设计成可以重复安装在不同机构中？14系统是否设计成易修改和易使用？复杂度调整值（合计）功能点估计（3）最终复杂性因子：TCF＝0.65＋0.01×∑14i=1Fi功能点的计算公式：FP＝UFC＋TCF功能点与代码行转换表语言Fi语言FiASSEMBLY320ADA71C150PL/165COBOL105PROLOG/LISP64FORTRAN105SMALLTALK21PASCAL91SPREADSHEET6对象点估计分析对象点的复杂性分析功能对象的复杂性对象点估计表(LOC)方法种类很小小中大很大计算2.345.1311.2534.6654.04数据2.604.798.8416.3130.09I/O9.0112.0616.1521.6228.93逻辑7.5510.9815.9823.3533.83设置3.885.046.568.5311.09文本3.758.0017.0736.4177.66功能对象矩阵(CNT)的构造方法使用产品需求，构建一个体系结构或概念设计；对该设计中每一类（面向对象方法中的class）的输入和交互，标识所涉及的对象属于对象估计点表中的哪类方法；估算以上标识的每一方法的复杂性；将结果填入到矩阵CNT相应的表格中。对象点估计计算公式LOC为对象点估计表CNT为功能对象矩阵项目计划内容定义项目的物质设施和开发环境制定项目进度安排制定项目相关的规章和规范软件测试计划制定项目进度安排进度安排的前提软件需求基本明确项目资源基本确定项目工作分解结构足够清晰和细化项目工作量的估算认为可靠人员工作分配项目工作量的分配项目阶段的划分和项目里程碑的确定人员工作分配任务分配责任要明确信任项目成员的能力敢于让项目成员挑担子给项目成员分配稍大于其能力的任务人员组织结构形式主程序员制功能项目组织矩阵项目组织主程序员制功能项目组织矩阵项目组织项目工作量的分配瀑布型生命周期的阶段工作量分配UML统一建模的阶段工作量分配各阶段的工作概述：分析阶段，设计阶段工作分配要考虑风险和纠正错位的工作量项目阶段的划分和项目里程碑的确定项目的阶段划分是与软件项目采用的生命周期相一致里程碑的设计应具有二分性里程碑建立完整的里程碑清单里程碑的好处规范和明确开发人员的工作任务跟踪和检查工作任务的完成情况高级主管进行汇报项目进度，体现项目成绩的有效手段制定项目相关的规章和规范没有规矩不成方圆提高项目工作效率；降低项目运行成本；提高软件开发质量。项目规范和规章的内容办事程序。工作产品提交制度，费用报销制度等沟通方法和方式。周例会制度，定期汇报制度。制定规范和规章的原则一看就能明白一看就能记住考虑到70％～80％的情况对事不对人让规章说话需求的确定错误的修正测试计划软件测试过程制定测试计划编写测试方案执行测试用例测试总结测试驱动开发需求分析—确定测试概要设计—集成测试详细设计—单元测试软件项目策划存在主要问题分析需求内容不明确、把握不充分项目工作量化程度较低出于客户和公司上层的压力在工作周期估算上予以妥协。设计者过于自信或出于自尊心问题，对一些技术问题不够重视，或者担心估算多被嘲笑。过分凭经验。由于有过去的成功经验，没有具体分析就认为这次项目估计也差不多，而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多，而且是一个新的行业。项目组织成员数量与其技术素质的关系开发计划安排不充分工作分担责任范围不明确每个开发阶段的提交结果定义不明确开发计划没有指定里程碑或检查点开发计划没有规定进度管理方法和职责设计人员能力不足一个客户服务中心项目的策划B计算机公司（以下简称B公司）了解到A企业要建设一个客户服务中心，向客户提供有关本企业产品的咨询、查询、委托、投诉等服务，并希望能够尽可能采用各种计算机和通信技术，为客户提供快速、准确和渠道多样（包括电话、传真、WEB、邮件等）的服务。项目背景分析A企业的原有业务运作只有一小部分采用计算机处理，而且原来并不存在客户服务中心这样的机构。B公司擅长的领域是典型的基于UNIX与TCP/IP的交易处理系统，对于建立客户服务中心所需要的CTI知识知之甚少，WEB开发也从来没有尝试过。项目过程起始阶段查阅资料确定助手制定下一步计划建立良好关系。与客户，与销售经理策划阶段保持人员的连贯性组建项目团队细化WBS确定测试计划项目组织结构和角色WBS结果B公司在项目中采用多种从未使用过的技术和产品：Browser/WebServer/DatabaseServer结构、CTI技术、排队机，并独立开发语音传真服务器，最后按时完成项目。该项目的完成为后续合作奠定基础，在第二年很快就签署二期合同。无论是客户还是公司，都对项目的结果表示满意；项目成员也对能参与这个项目表示高兴。好的实践充分的准备良好的关系人员的稳定实在的计划积极性的调动客户的参与和配合主要内容项目进度管理方法概述里程碑项目进度的度量案例讨论复习项目策划中觉得最重要的工作是哪些你认为项目策划中最可能出现的问题有哪些好的实践充分的准备良好的关系人员的稳定实在的计划积极性的调动客户的参与和配合进度管理的概念项目进度管理的内容包括确保项目准时完工所必需的一系列的管理过程和活动。项目工作分解，项目工作时间的估算，进度安排，进度跟踪和检查等重点介绍项目进度安排和在项目开始开发到项目产品发布之间所进行的为确保项目准时完工所必需的一系列的管理过程和活动。工程监理监理工程师影响项目进度管理的因素质量、进度和成本的对立统一进度快，投资省，质量好是项目管理追求的最佳目标影响进度管理的因素各部门的配合和协作人为因素、技术因素、设备因素，网络因素、资金因素、环境因素等进度管理的主要干扰因素错误估计了项目的特点及项目实现的条件项目参与者的工作错误不可预见的事件发生描述项目进度的方法关键日期法。列出一些关键活动和进行的日期甘特图。由HenryL.Gantt于1917年提出。它主要的方法是在一个面向日历的图上划出一个直线代表项目活动，并用一些符号指示活动的主要里程碑，并用不同颜色的线或不同类型的线表示进展。关键路线法和计划评审技术（CPM/PERT）。用网络图来表达项目中各项活动的进度和它们之间的相互关系关键日期法阶段一业务需求调研和理解开始日期2002-10-16结束日期2002-10-30任务描述(1)与客户实际交流，确定要做什么；(2)详细了解客户现有的办事流程；(3)确定开发地点、人员及进度安排；(4)理解和分析现有的业务流程的基础上，提出我们要改进的方式。提交的工作产品业务需求说明的理解负责人张三参与人……阶段二需求分析及业务流程整理开始日期2002-10-31结束日期2002-11-25任务描述(1)认真分析客户需求及业务流程；(2)与客户作深入的交流，确定业务需求；(3)画出业务主要界面；(4)初步确定系统的数据模型。提交的工作产品(1)系统正式的业务需求说明书；(2)主要界面的操作风格与操作流程的初步确定。负责人张三参与人……甘特图关键路线法和计划评审技术CPM和PERT的编制步骤(1)把项目分解为一系列活动（WBS）；(2)用一个有向无回路的图来描述项目的活动之间先后相互关联的关系；(3)利用网络分析技术，根据活动的权值（时间）及先后关联关系找出图中的关键路径；(4)利用统计和概率分析技术，计算关键路径的预定长度。计划活动网络图里程碑里程碑的划分原则与方法如何确保里程碑的到达好的实践经验里程碑的划分原则与方法里程碑应该长短结合，更应关注短期的里程碑里程碑应该全局和个人相结合。里程碑应该是检查和肯定相结合里程碑应该逐阶段进行制定第一阶段第二阶段里程碑工作任务完成应注意的问题没有例外和部分完成的里程碑产品技术学习和钻研的里程碑好为人师并不都是好的先紧后松和先松后紧如何确保里程碑的到达不要制定不实际的里程碑主观上草率应付客观上创造奇迹里程碑的理解一致性具有约束机制开评审会对里程碑的工作产品进行评审，或者开发人员相互进行检查质量保证员进行规范性检查定期的工作汇报个别的访谈制定有效的补救措施避免形式主义好的实践经验及时准确地向自己上司汇报自己工作情况的人必将会取得成功；只存在于人大脑中的思想和知识是不能算作任何工作成果的；对于项目经理而言，大多数情况应采用基于结果的管理方式，而不要过多干预开发人员具体的做事方式。项目进度的度量项目进度度量的好处项目进度度量的主要方面项目进度度量的主要方式项目进度度量的好处更好地了解项目和产品的进展，并能根据以前的工作所用的时间和成本，更准确地对项目以后工作做出估计，从而更能有效地安排项目后期工作；确定产品和项目的复杂性，为以后的维护工作提供参考；分析缺陷，能够为更好开展项目以后的工作提供借鉴；通过度量的数据更能具体说明项目的进展，向高级主管汇报时，数据是比较有说服力，对项目组能及时拿到项目经费很有帮助；为估算未来的项目和类似的开发工作提供一个基础。项目进度度量的主要方面所花的时间规模的大小。规模的大小主要指需求的数目，对象和组件的数目，文档的页数、代码行数，测试用例数等等。缺陷的统计。缺陷的统计主要指工作延迟的多少、返工的多少和测试的BUG数等。异常的统计。包括缺工的统计、变更的统计、风险出现的统计等等。对异常的度量能够有助于更好的识别风险。工作时间度量表姓名任务项工作量（时）完成情况存在的问题…项目管理8完成详细设计评审16完成100%山东出差20完成…详细设计评审、修改40完成100%…详细设计评审24完成100%…详细设计评审、工具熟悉40完成100%前端展现工具有待熟悉…编程环境准备、详细设计评审40完成Weblogic配置有待熟悉…熟悉环境12培训12规模度量表模块名源代码行文档页资源管理服务器109731013源调度中心1703资源注册工具1175资源编辑发布工具3557合计17408项目进度度量的主要方式表格方式图形方式度量软件。ScientificToolworks,Inc.提供的一系列用于Ada83,Ada95,FORTRAN77,FORTRAN90,FORTRAN95,K&RC,ANSICandC++,andJava的代码和文档的度量工具。软件设计度量表项目时间度量表主要内容如何进行进度跟踪如何应对发生的延迟案例讨论复习如果一个收费管理系统项目工期为3个月，包括你一共4个人，其他三个一个有经验的高级程序员，另外两个刚毕业的学生，谈谈如何进行进度管理确保按期完成开发任务。如何进行进度安排如何确保进度按期进行进度跟踪一小时管理个人计划日清日结项目经理的苦恼项目的慢性病不知不觉的延迟没有出现大的风险没有人偷懒慢性病因人的不确定性情绪的不稳定性干扰因素一小时管理方法安排工作到小时做事安排有条理。一个小时一个小时连接起来的任务序列。约束人的不确定性工作检查结果以小时为单位个人计划周工作计划日工作计划周工作计划时间主要工作任务主要工作对象星期一数据库管理组件中DBManager类的方法writelob的编码DBOperate工程项目星期二数据库管理组件中DBManager类的方法writelob的测试DBOperate工程项目星期三…………星期四…………星期五…………日工作计划序号任务预计时间1召开一个项目会议，讨论建立系统测试环境问题1小时2与网络技术部联系，解决与外网连通问题0.5小时3与小卢安装测试服务器的环境4小时4与财务联系一下报帐事情10分钟日清日结海尔的“3E”管理everyone，everyday，everything执行力活在当下“3E”管理在软件开发中应用每日提交每日构造每日测试执行力什么是执行力海湾战争擦桌子为什么强调执行力5％的人看不出来是在工作，而是在制造矛盾，无事必生非=破坏性的做。10％的人正在等待着什么=不想做。20％的人正在为增加库存而工作=“蛮做”、“盲做”、“糊做”。10%的人由于没有对公司做出贡献=在做，而是负效劳动。40％的人正在按照低效的标准或方法工作=想做，而不会做。只有15%的人属于正常范围，但绩效仍然不高=做不好，做事不到位。什么是执行力执行就是把事情做完。执行是有与公司的经营、构想或规划是相对的。执行是去实践我们的目标。所谓执行力就是务实运作的细节（韦尔奇语）。执行就是把战略转化为行动计划，并对其结果进行测量（郭士纳语）。执行力就是坚持，坚持，再坚持（阳王东语）项目管理增加执行力的方法让开发人员能够理解计划，增加他们的自觉性，任何好的制度都比不上自觉；建立一套规范有效的质量保证体系；如何事情要要列出一个轻重优先级表；项目经理要“反复抓，抓反复”，也就是说项目经理要把管理监控工作做到细处，并且要长此以往，不能一时紧一时松；项目经理做事情要内行。活在当下关注手头上的工作检查刚完成的工作及时提交已完成的产品计划要开展的工作如何应对发生的延迟认清形势明确任务亡羊补牢认清形势项目进度计划安排不合理工作任务的定义不合理影响项目进度风险的发生开发人员没有全神贯注于自己的工作开发人员不恰当的工作方式项目经理过多干预开发人员的工作明确任务任务不能按时按质完成的主要原因开发人员与项目经理不能很好地配合，各自做各自的。项目经理专注于项目中的某项工作而没有看到项目全局。解决办法要让大家都清楚项目当前的严峻局面，同时也要向高级主管汇报真实的情况，并通告客户。要认真实在地分析在项目所有的工作中，哪些是已经完成的，哪些正在进行中，哪些还没做的。与公司和客户进行协商重新定义工作任务，重新进行工作任务的分配并执行新的进度计划安排。如果项目组确实存在不能胜任工作或不愿意把心思放在工作上的人员，要坚决从项目组清除掉。亡羊补牢控制需求明确技术提高熟练程度减少依赖保证人员稳定加强测试敏捷开发敏捷开发方法减少不必要的文档关注功能的实现加强面对面的沟通增加客户的参与迭代和增量开发案例讨论A公司是一家美资软件公司在华办事机构，其主要的目标是开拓中国市场、服务中国客户，做一些本地化和客户化的工作。它的主要软件产品是由总部在硅谷的软件开发基地完成，然后由世界各地的分公司或办事机构进行客户化定制、二次开发和系统维护。这些工作除了日常销售和系统核心维护之外，都是外包给本地的软件公司来做。东方公司是A公司在中国的合作伙伴，主要负责软件的本地化和测试工作。Bob先生是A公司中国地区的负责人，Henry则是刚刚加入A公司的负责此外包项目的项目经理。东方公司是由William负责开发和管理工作，William本身是技术人员，并没有项目管理的经验。进度与现状第一阶段。项目开发成本非常高，每人每天130美金，但客户的满意度较差，并且每次开发进度都要拖后，交付使用的版本也不尽如人意。第二阶段制定了详细的项目计划和进度计划成立了单独的测试小组，将软件的开发和测试分开硅谷和东方公司之间建立了一个新的沟通渠道采用了里程碑管理六个月后，软件交付使用。但是客户对这个版本还是不满意，认为还有很多问题。问题分析软件本地化产生的问题并不多，但A公司提供的底层软件本身存在一些问题；软件的界面也存在一些问题，这是由于测试的项目不够详细引起的；开发的周期还是太短，没有时间完成一些项目的调试，所以新版本还是有许多的问题。第三阶段们采用大量的历史数据进行分析，制定出更详细的进度计划；要求东方公司提供详细的开发文档和测试文档（之前William的团队做的工作没有任何文档，给其他工作带来了很多困难）；重新审核开发周期，对里程碑进行细化。效果客户对它的评价比前两个版本高得多，基本上达到项目运行的要求。但客户还是对项目进度提出了疑问，认为实时推出换代产品不需要那么长的时间。存在问题与改进建议缺乏项目管理方面的专业知识的技巧，往往只是凭借以前的少量经验盲目去做，容易出现各种问题。东方公司没有专门的项目经理，是由技术人员William兼做管理。沟通障碍没有贴近客户质量与进度的平衡敏捷开发复习进度延迟如何应对主要内容项目成本管理概念与现状项目成本预算项目成本控制如何控制成本案例分析项目成本管理概念什么是成本会计学上的定义是为达到一个特定的目标而牺牲或放弃的资源。项目中消耗的人力、财力和物力。项目成本管理是为了确保在批准的预算范围内完成项目所需要的各个过程所采取的一系列活动。什么人最关注成本软件项目成本管理现状恶性价格竞争软件企业难过的坎如何过冬项目成本预算软件项目的总成本预算分摊工作任务的预算成本制定项目的累计预算成本利益的平衡软件项目的总成本预算生产成本的构成直接材料直接工资其他直接支出制造费用期间费用管理经费财务费用销售费用分摊工作任务的预算成本分摊预算成本的工作分析结构软件项目的网络图人事档案管理系统的项目的工作分析结构制定项目的累计预算成本分摊预算成本的工作分析结构软件项目的网络图人事档案管理系统的项目的工作分析结构

制定项目的累计预算成本从时间上分配和安排每个工作任务的预算，即在工作实施工期中如何分布这一工作任务的成本预算月份办公费用基本工资交通补助通讯费补助生活补助合计2002-1050020800360800900233602002-1130020000300700750233602002-123001100030070075013050合计1100518009602200240059770利益的平衡要从对项目成败的影响程度考虑要考虑从技术含量方面要考虑经验积累方面要从工作岗位方面考虑项目经理：2；系统分析员：2；数据仓库工程师：2；高级程序员：1.5；高级测试员：1.5；数据库设计员：1.5；程序员：1；测试员：1；文档员：0.5。要从项目进度上考虑要从所承当的责任方面考虑要从人才市场上的供需关系方面考虑项目成本控制项目成本控制活动事前控制事中控制事后控制项目变更项目成本变动控制规避控制项目成本绩效度量项目成本管理的附加计划项目成本绩效度量项目计划作业的预算成本。按照预算价格和预算工作量计算的某项作业的成本，BCWS。项目已完成作业的实际成本。按照实际发生的价格计算得到的实际已经完成作业的成本，ACWP。挣值。按照预算价格所计算的某项作业实际已完成作业的成本，BCWP。项目成本绩效度量（续）项目成本差异（CostVariance，CV）的计算公式：CV=BCWP-ACWP项目进度差异（ScheduleVariance，SV）的计算公式：SV=BCWP-BCWS成本绩效指数（CostPerformanceIndex，CPI）的计算公式：CPI=BCWP/ACWP。已完成作业量的实际成本与预算成本的相对关系。它衡量的是正在进行的项目的成本效率。项目成本绩效度量（续）设计网页的工作任务的成本绩效报告工作任务网页设计工作任务网页设计数目20张成本差异2400－3000＝-600元计划时间60天成本进度差异2400－6000＝-3600元计划预算成本6000元成本绩效指数2400/3000＝0.8已用时间30天目前完成数8张实际成本3000元挣值（6000/20）×8＝2400元建议与忠告成本控制并不是不用钱，而是要合理地用钱，有效果地用钱。成本控制不是要降低项目组开发人员的收入为代价，而是减少不必要的开支，增加开发人员的收益。成本控制是要在保证项目能按照目标完成的基础上，实现项目组和公司的利益双增长。如何控制成本精打细算确保项目能够继续项目的收成个人的利益砍掉成本如何应对超支的成本经费总是不够无尽头的维护什么是该结算的时候确保项目能够继续事先必须进行预算要公布开支标准严格控制未经授权的开支项目经理要带头节省项目经费的开支要定时公布项目经费开支情况让客户参与成本控制让公司的其他部门理解项目的成本控制规程项目的收成多劳多得要树立先做事，再要钱的观念要进行差异化的分配方式在进行项目奖金分配时，要有客观依据树立多种收成的观念个人的利益为客户服务工作与事业软件与产品卖产品与做服务个人的、公司的、客户的砍掉成本合同与利润的变化关系销售额与利润的关系成本与利润的关系6把砍刀砍人手砍开发砍形式砍项目设备砍办公费用砍无关紧要的会议活动经费总是不够绩效挂钩风险共担成功的价值无尽头的维护加强客户对软件的维护在软件应用中重要性的认识。在签订软件合同时，应增加对软件维护的成本预算。软件市场中对软件维护的规范性要有一个统一科学的认识和约束，要形成规范的软件服务市场。坚持有偿服务的原则。软件开发人员也要加强对软件维护工作重要性的认识加强软件开发中的软件测试、软件复用，组件化，标准化、泛性模式的运用什么是该结算的时候公司内部开发的软件产品，但一直没有找到使用的客户，也就是一直没有签到单。当软件已经投入使用后，客户的需要总是不断的变化和增加，而事先没有明确规定客户需求的范围。造成软件无休止地修改和升级。敢于放弃一个收费管理系统项目的开发成本管理有一家中小型的计算机公司，和我国大多数计算机公司一样主要业务是承接系统集成和行业业务系统的开发，公司采用项目核算制，公司与项目开发组也签订项目开发协议，项目经费在协议中进行明确。项目开发组采取项目经理负责制，由项目经理进行项目经费的分配。项目经费分为三部分：基本工资、项目直接费用和项目奖金。基本工资由项目经理核算后按月发放，直接费用在一定范围内进行报销，项目总预算经费扣除基本工资和直接费用后的结余经费作为项目奖金发放，等项目的开发结束后进行核算发放。成本管理软件开发合同的50%划为项目的软件开发费用在软件开发合同中并没有明确系统软件和网络软件的安装、部署和调试是由哪一组负责没有明确维护的边界第一个月基本工资就占去了整个项目经费的三分之一第二个月项目组的基本工资的开销已经用去了项目经费的三分之二基本工资占了四分之三，直接开支的各项费用却占了近四分之一，比预算时几乎多了一倍复习成本管理的目标是什么如何有效地砍掉成本？一个公司砍掉办公经费的方法总结项目的成本管理要注意三个方面成本边界要划分清楚项目要进行合理预算要为项目建立专门的帐目主要内容项目质量管理的概念项目质量管理过程质量管理执行者与执行方法评审案例分析质量概念质量的定义来源于物理学质量的概念，质量是一种产品（或工程、服务等）本身所具有的某些方面的物质特性。一种产品（或工程、服务等）对其相应消费者期望值的满足度。两种质量观。符合性质量和适应性质量质量特性完整性可信性安全性适应性经济性时间性质量管理概念质量管理定义ISO的定义：确定质量方针、目标和职责并在质量体系中通过诸如质量策划、质量控制、质量保证和质量改进使其实施全部管理职能的所有活动。狭义的定义：确保项目满足它所应满足的需求所开展的所有活动。质量结构体系质量方针。由组织的最高管理者正式发布的该组织总的质量宗旨和方向。质量目标。质量方针和质量目标是工厂经营战略的重要组成部分，是对客户的承诺，是工厂为之奋斗的质量宗旨和行为准则质量体系。为了实施质量管理的组织机构、职责、程序、过程和资源。ISO9000海尔质量方针：进行领先市场的设计，用最低的成本生产最好的产品，竭诚为用户提供满意的服务湖南城市学院质量方针：品学兼修，知行统一质量管理过程ISO质量管理过程 质量策划。确定质量以及采用质量体系要素的目标和要求的活动。质量控制。为达到质量要求所采取的作业技术和活动。质量保证。为了提供足够的信任，表明实体能够满足质量要求，而在质量体系中实施并根据需要进行证实的有计划和有系统的活动。质量改进。为了达到质量要去，而开展对产品的完善和修复的活动管理。质量管理活动要求从用户需求出发，向用户保证按时按质交付项目工作成果，满足或超越用户的需求；从保证和提高产品质量出发，对项目执行的全过程进行质量控制；从调动项目组所有成员积极性出发，实行项目团队的质量管理；全面地综合运用统计质量控制及其他多种方法进行管理。谁来保证质量项目经理质量保证员开发人员测试人员其他相关部门和人员质量管理执行的方法质量是条例。在项目实施过程中，必须把质量量化为一个个具体的质量指标。制定简单明了的工作的规程和准则制定需要检查的和测试的条例质量条例表样例阶段质量准则表质量检查表阶段质量准则表所需要某个质量子特性阶段需求分析概要设计详细设计编码测试准则1、需求分级编号1、模块的扇入不超过51、每个函数提供流程图1、注释量达到30%1、每个功能至少提供两个测试用例·············································

质量检查表质量特性需求质量可操作性缺省项比率重复输入项比率打入项数打入字符数出错发现时间自动修正率出错信息亲切度同样的东西不要重复输入XX打入简单XXX打入方式灵活XX打入量少XXXX无需计算X可立即知道XX能当场修改XXX评审评审的概念评审是一个过程或会议，其间，项目人员、经理、用户、客户或其他有关部门，针对所提出的一个工作产品或一组工作产品，进行评议或批准。评审的目的让项目相关人员了解项目采用的技术和项目执行的状态；为项目相关人员提供一个就项目的有关事宜进行研讨的机会；确定项目所处的里程碑；评估项目某一方面或一个工作产品所使用的技术是否适当。评审的形式特定时间发生的单独评审。当特定条件发生时所出现的单独评审。按照确定的周期性工作的多重评审。当特定条件发生时所进行的多重评审。评审的类型管理评审技术评审走查审查审核管理评审管理评审是对项目组的计划或相对于该计划的项目进展所作的正式评审。目标通报项目状况、进展方向、达成的技术协议以及项目的总体状况等方面信息；解决在技术评审期间悬而未决的问题；制定在技术评审期间悬而未决的、缓解近期和长期风险的一致同意策略；标识和解决在技术评审期间没有出现的、管理上的问题和风险；为管理层或客户提供所需要的项目背景，以得到完成项目所要求的承诺和认可。结果为保证项目符合已建立的组织和项目过程，所要进行的改进活动。项目资源分配的变更；项目方向或范围的变更；进度的变更。技术评审技术评审的对象则主要是规范和设计文档。目标软件产品是否符合技术规范；软件产品是否遵循项目可用的规定、标准、指导方针、计划和过程；软件产品的变更是否被恰当地实现，这些变更的实现是否影响哪些被变更规范标识的系统方面。确保评审的主体可跟踪到适当的需求；为技术工作提供理解和反馈；维护客户技术人员和开发组织技术人员之间以后的通讯；验证满足要求的技术约定。走查走查是一类同级评审，是软件产品的一次系统的评估。走查的主要目标是发现异常和评估与标准和规范的符合程度。走查人员质量保证员小组其他开发人员项目经理走查对象设计文档源代码测试文档用户文档审查审查是一种更为正式的走查目标标识文档或系统存在的特定错误；标识开发过程中系统化方面的错误；标识与标准和规范的偏离；收集软件工程错误（例如：异常和工作量数据）；使用所收集的软件工程数据，改进审查过程本身以及它的支持文档（例如，检查清单等）。过程概述。工作产品的作者概述接受审查产品的目的和范围；准备。作者的同事或同行专家以充分理解产品、发现错误为目的，对产品进行研究；审查会议。审查小组举行会议，在作者说明其工作产品的同时，指出错误；返工。作者按照审查期间产生的错误列表修订该工作产品；后续工作。审查的领导验证作者返工的质量，并确定是否有必要进行再一次的审查。审查人员同行技术专家审核审核是对过程和/或产品的一次独立性评估。把审核的主体与该主体以前建立的一组规程和标准进行比较，目的是确保真正地遵循了这一过程，产生了合适的文档和精确反映实际活动的报告。类型项目审核后项目审核功能配置审核物理配置审核过程内审核独立或外部审核评审的建议所有评审的手段都是为了及时发现软件中存在的缺陷，降低软件修正的成本。开发人员在评审过程中，要有良好的心态，发现软件中存在的错误，并不是否定开发人员的劳动成果，而是有助于提高软件开发人员的开发水平，减少开发人员不必要的工作量。项目经理在评审过程中，提高软件质量要在自己脑子里是摆在首要位置，不要动不动就怕增加成本，提高了软件质量最终会为项目减少成本带来重大作用。复习项目计划的质量特征是什么如何评审一个项目计划主要内容软件质量保证过程软件测试质量成本一个印度软件公司的质量管理体系剖析软件质量保证过程需求分析质量保证软件架构设计的质量保证软件编码的质量保证需求分析质量保证判断需求是否符合愿景目标判断产品需求能够给企业带来多大的利润与竞争对手相比核心竞争力有哪些保证需求描述的质量句子和段落是否简短句子是否有语法错误，还要注意标点符号注意是否存在形容词及比较性词语需求是否细化是否可以将需求写出相应的测试用例软件架构设计的质量保证功能性效率维护性可移植性可靠性使用性软件编码的质量保证代码走查精简可读性低耦合，高内聚单元测试白盒测试。覆盖测试测试驱动软件测试软件测试过程测试中人的因素软件评价软件测试过程

测试计划测试方案测试用例测试执行测试总结测试中人的因素认识要一致测试是根据测试用例来执行的测试要对事不对人统一测试标准测试结果处理要及时加强交流利益挂钩软件评价软件评价的前提存在评价标准评价标准是有度的满足客户对项目开发软件的功能性需求和非功能性需求是制定项目软件质量标准的最重要的标准项目的质量标准必须是基于公司制定的关于项目过程和软件质量的质量标准而制定的。项目组内部为了让所有的开发人员提高软件开发水平，以及提高项目质量管理的效率而制定的有关技术和软件活动的质量标准软件测试的建议与忠告软件测试并不能保证一个软件产品100％没有错误，如果软件测试能达到“放心”二字，就足够了。在很多情况下，软件开发人员与软件测试人员的争执，通常是软件测试人员的观点更合适一些，可能是因为“不识庐山真面目，只缘身在此山中”。发现和改正了越多的软件错误，不要以为软件质量就更可靠了，反倒说明软件中仍然存在着越多的错误。质量成本质量成本的概念质量成本的组成质量成本分析与细微之处见功夫质量成本的概念质量成本”这一概念是朱兰（Juran）博士于1951年出版的《质量控制手册》中提出来的。研究质量成本的问题，其最终目的是要使花费在产品质量上的总成本达到最小，从而增加企业的利润，提高企业的经济效益。控制质量成本的目的，是想根据与产品质量有关的各项成本的相互关系，有目的地、有针对性地降低其中某些成本，从而使与产品质量有关的各项质量成本之总和，也就是质量成本总额降低到最小值。质量成本的组成工作质量成本。企业为达到和保证规定的质量水平所耗费的那些费用。预防成本鉴定成本损失成本外部质量保证成本。向用户提供所要求的客观证据而作的论证和证明所支付的费用。质量成本分析质量成本分析（续）区域Ⅱ称之为最佳区。质量损失成本占质量成本总额的一半左右，而预防成本约占全部质量成本的10％左右。区域I是质量损失成本占质量成本总额的70％以上，而预防成本低于总额的10％。需求调研和分析的时间不够，造成对客户需求没有了解和分析清楚；项目组没有花时间认真制定项目组软件开发的相关规范；设计没有经过认真的技术评审或没有聘请高水平的设计人员，造成设计时考虑不周到，留下重大设计缺陷；公司或项目组没有对软件开发人员进行软件开发过程或技能上的培训，造成软件开发质量差；开发人员由于过度加班造成开发质量差；项目组没有质量保证员；项目组没有在软件测试上投入足够精力；项目组没有聘请有经验的高水平技术人员参与技术评审；项目组没有在软件配置上投入足够精力。区域Ⅲ的特点是鉴定成本超过了质量损失成本，且占质量成本总额一半以上。对产品质量提出了过分高的要求过于完美主义技术至上与细微之处见功夫标准一致工作细致到位重复熟练认真细心建议与忠告在软件测试当中，发现第11个错误的时间比发现前10个错误所花的时间可能还要多；有时候向市场上推出完美的产品时，却发现市场已经没有了；利润对于任何企业都是第一位的，没有利润就不可能有高的质量；人人都说生意人精明，其实精明就是做事细致、想事周到、行事稳靠，因此精明就是能够减少损失成本的一种难得品质。一个印度软件公司的质量管理体系剖析软件企业的组织结构项目计划项目管理项目经理软件企业的组织结构项目组结构汇报关系为:项目成员->模块负责人->项目负责人->开发经理->研发总负责人工程师分为7级，半年一次考评，即半年有一次升级机会1级:软件工程师，一般是刚毕业的本科生和研究生；2级:高级软件工程师；3级:项目负责人；4级:项目经理；5级:高级项目经理。项目计划动员会议(KickoffMeeting)项目策划项目估算以周为单位安排颁布项目工程任务书总结会议(CloseoutMeeting)项目管理流程计划审查质量保证度量数据团队精神培训配置管理记录项目经理对本项目进展非常了解对项目组员的能力比较了解对组员的工作安排都比较细致饱满在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制项目组例会一般一周一次当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛善于鼓励手下，发挥员工的潜能复习如何定义一个电子商务网站的质量特性如何看待windowsvista的质量问题主要内容风险识别风险控制风险应对案例分析风险的概念什么是风险。风险是其损益结局具有不可确定性的活动。任何可能出现的条件或事件，一旦发生，对项目会造成损害；风险是不确定的条件或因素，不同于“测试中肯定会发现缺陷，但不知道是何时”。风险的特征所涉及的不确定性，这一不确定性通常被表示为可能性，也就是有发生的概率；与风险相关的损失，如生活、健康、金钱、财产、名誉或机会等方面的损失；它是可管理的，在这一意义下，人类活动可以改变风险的形式和程度。风险识别的方法问询和探讨头脑风暴法咨询分析历史数据流程图法逆向推导法流程图法逆向推导法逆向推导法是从项目的结果出发，去推导导致结果的可能存在的风险因素项目失败项目中途终止；当完成了项目开发的软件产品后，而客户或公司却放弃了对软件开发合同履行逆向推导法（续）导致第一种情况出现的风险可能有：项目的经费供应终止。可能是投资方撤资或倒闭。公司决策层放弃。可能由于市场、技术或者业务方向等问题，导致公司放弃了项目所开发的软件产品。由于项目组主要的关键人员离开项目组，可能是被竞争对手挖走，或者是疾病与死亡等，而项目组一时找不到可替代的人员，并且项目缺乏这些人员不能继续。项目开发的软件产品违反国家有关法律或法规，被勒令终止。逆向推导法（续）可能导致第二种情况出现的风险可能有：客户的业务发生重大变化，项目组开发的软件产品已经不能适应新的业务需要。客户的组织发生了重大变化，新的组织不再履行以前组织签订的软件合同。这一方面在客户是行政事业单位更为明显。项目组开发的软件产品存在重大质量问题，使得客户根本无法开展业务工作，从而导致客户根据软件合同相关条款终止合同的履行。项目进度严重滞后，当项目组把软件产品开发出来后，客户已经不需要了。由于硬件提供商违约，既定的硬件基础不能到位，导致客户根本无法运行项目开发的软件产品，并且不能在短时期能得到解决，因而客户终止对软件合同的履行。也可能是客户在软件合同经费的支付上违反合同的相关条款，公司放弃了对客户的软件合同的履行。软件项目中常见的风险需求风险计划编制风险组织和管理风险人员风险开发环境风险客户风险产品风险设计和实现风险过程风险需求风险需求已经成为项目基准，但需求还在继续变化；需求定义欠佳，而进一步的定义会扩展项目范畴；添加额外的需求；产品定义含混的部分比预期需要更多的时间；在做需求中客户参与不够；缺少有效的需求变化管理过程。计划编制风险计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；计划是优化的，是“最佳状态”，但不现实，只能算是“期望状态”；计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；完成目标日期提前，但没有相应地调整产品范围或可用资源；涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。组织和管理风险仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；低效的项目组结构降低生产率；管理层审查、决策的周期比预期的时间长；预算削减，打乱项目计划；管理层作出了打击项目组织积极性的决定；缺乏必要的规范，导致工作失误与重复工作；非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。人员风险作为先决条件的任务(如培训及其他项目)不能按时完成；开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；缺乏激励措施，士气低下，降低了生产能力；某些人员需要更多的时间适应还不熟悉的软件工具和环境；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；没有找到项目急需的具有特定技能的人。开发环境风险设施未及时到位；设施虽到位，但不配套，如没有电话、网线、办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；新的开发工具的学习期比预期的长，内容繁多。客户风险客户对于最后交付的产品不满意，要求重新设计和重做；客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；客户对规划、原型和规格的审核决策周期比预期的要长；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。产品风险矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；开发额外的不需要的功能(镀金)，延长了计划进度；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；开发一种全新的模块将比预期花费更长的时间；依赖正在开发中的技术将延长计划进度。设计和实现风险设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。过程风险大量的纸面工作导致进程比预期的慢；前期的质量保证行为不真实，导致后期的重复工作；太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。建议和忠告考验一个项目经理和项目开发团队，不仅要看其在没有什么风险的环境中的做事的能力；更要看其在出现各种风险的环境下的做事能力；风险并不可怕，可怕是不知道有风险；不能因为有风险就不去做，风险是锻炼一个人的最好的机会；一般是高风险才能有高的回报。风险控制风险管理模型风险控制计划十个风险清单风险控制方法风险管理模型BarryBoehm模型。RE=P(UO)*L(UO)。其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生破坏性的程度。Boehm思想的核心是10大风险因素列表。SEI的CRM模型。它将风险管理划分为五个步骤：风险识别、分析、计划、跟踪、控制。

SERIM模型。从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。风险控制计划风险管理计划应急计划应急储备风险管理计划(1)项目中存在哪些风险；(2)风险的发生可能性大小；(3)不同风险对项目的影响程度；(4)风险可能出现的阶段及其影响的阶段；(5)谁对哪些风险具体进行跟踪和负责。计划表中风险类别BU-商业风险，CU-客户特性风险，DE-开发环境风险，TE-人员经验风险，ST-建造技术风险，PS-产品规模风险，PU-过程风险。风险管理计划表风险因素类别概率影响RMMM负责人发生阶段开发的产品不再符合公司的整体商业策略BU5%5监控高级经理全程人力需求估计过低TE50%4监控项目经理详细设计与编码没有得到预算或人力上的保证BU50%4监控项目经理全程与BOSS开发组之间无法协调DE20%4缓解高级经理设计阶段复用程度低于计划PS65%3风险软件经理编码阶段规模估算可能和实际差别很大PS60%3监控项目经理设计编码缺少对工具的培训DE50%3缓解项目经理编码阶段测试和编码的具体监控难以落实PU40%3监控项目经理编码测试四层结构新技术的尝试可能导致技术力量不够ST30%3缓解软件经理设计编码参与人员的流动TE30%3缓解项目经理全程数据仓库新技术的尝试不能保证成功ST20%3缓解软件经理分析设计OO分析和设计新技术的尝试可能与传统的过程冲突ST20%3缓解项目经理分析设计交付期限将被紧缩BU10%3监控项目经理全程风险管理计划表（续）风险因素类别概率影响RMMM负责人发生阶段开发人员工作的短时中断PU90%2计划项目经理全程与客户之间无法沟通CU90%2缓解项目经理需求\分析产品创建和使用的数据库很大PS80%2监控软件经理测试交付用户需求发生较大的改变PS65%2计划项目经理分析之后测试工具欠缺不能保证测试的效率DE50%2缓解软件经理测试交付交付期限不能保证产品的完整性BU50%2监控项目经理设计编码技术达不到预期的效果ST50%2监控软件经理设计开发人员不能严格遵守过程规范PU50%2监控项目经理全程合作者或合作关系的重大变化DE40%2缓解高级经理全程参与人员缺乏经验TE40%2缓解软件经理全程最终用户可能抵制该系统BU10%1缓解项目经理交付维护十个风险清单本周上周上榜周数风险风险解决进度115拖泥带水的需求利用快速原型工具创建界面原型来收集高质量需求规格需求规格纳入明确的变更控制，里程碑完成的工作产品有助于稳定需求。255不切实际的需求或开发人员华而不实的毛病软件范围描述中应当具体说明软件中不包括哪些东西检查项目清单来检查“额外的设计和功能”324发行软件质量太低确定采用规范的开发过程对需求、设计和程序进行技术检查测试规划确认所有功能都涵盖在系统测试中有独立的测试员进行系统测试475不可能实现的时间表避免完成需求规格前已决定了日程安排在最省事的上游时期进行寻找和更正问题的检讨在项目进行中要不断校正时间表积极追踪项目进度，确保进度延迟及早发现当整个项目花费的时间比预期要久时，阶段完成的做法可以让部分功能先被完成542不稳定的工具延误时间只在项目中使用一两项新工具，其余都沿用前面已经熟悉的工具6-1人员流动率高把开发人员的目标统一到项目目标上确定阶段性工作完成，明确期望目标定期重新估计，修订计划，避免大量加班提供好的工作环境项目经理应该主动为开发人员提供工作和生活上的帮助735开发人员与客户间的摩擦使用者界面雏形让开发人员和客户在细节看法上达成一致用阶段性完成的方式让客户看到渐进的项目进度865不良的工作环境在完成使用者界面雏形后。项目组进行封闭式开发需要增加来更换工作处所的经费风险控制方法为了有效的风险控制，项目组和项目经理必须具备：衡量项目进展状态的标准；监视项目实际进展所需要的信息；必要时采取调整和纠正行动的权限；从各种备用措施中选取最优者加以实施的能力。风险控制策略降低风险发生的概率为事件的发生做好准备，减轻风险的影响制度化、规范化的运作，可以降低人为因素的风险转移风险有时也是一种好的方法凡是留有回旋余地，不至于到时一筹莫展惹不起，躲得起默默得承受有时既是无奈的选择，但可能是明智的选择降低风险发生的概率公司在制定开发流程一定要从实际出发，是真正为了提高开发效率与质量而制定的，而不是为了制度而制度；项目经理要根据项目的实际情况进行适当裁减；要对开发人员进行培训，让他们能够掌握开发流程的精髓；在执行过程中，能够不断进行改进，让开发人员切实感觉到遵照开发流程进行开发，确实能够提高效率，还能保证质量。转移风险的方式出售发包开脱责任合同保险担保。回避的项目开发的软件系统存在法律障碍。客观上不需要的项目，没有必要去冒险。一旦造成损失，软件公司无力承担后果的项目。建议与忠告将风险管理集成到项目管理；使用工具；开始时不要对量化过于强调；不要期待实施风险管理的费效分析；记住风险计划可能引入新的风险或增加成本。风险回避应是最后一招，采用时应非常清醒使用组织层的风险数据库以便项目间相互借鉴风险的应对关注风险，但不焦虑风险发现苗头，及时处理当风险变成现实时，不要回避关注风险，但不焦虑风险要有一个良好的心态要树立能解决风险所带来影响的信心要树立能解决风险所带来影响的信心让项目组每个人都能够了解风险记录风险，并不是时时刻刻讲风险不同风险让专人去跟踪周期性汇报风险的状态发现苗头，及时处理发现苗头，及时处理客户需求不确定客户推迟项目验收开发人员的变动模块质量不过关开发进度延迟建议与忠告承认风险是不可避免的；公开交流风险—讨论本身似乎能减少风险的影响；奖励阻止风险发生的人，而不仅仅是惩罚那些造成风险的人；同一时刻不要管理太多风险；记下风险；不要仅关注容易处理的风险。当风险变成现实时，不要回避要承认风险发生的现实要有一个良好的心态要迅速的行动要有针对地行动事态严重必须向上级汇报事故的处理结果要及时公布风险的处理要有记录，并且要形成正式的处理报告高风险数据分析项目的风险管理