文档VIP

积分充值

消息

昵称未设置
文档VIP

未开通
文档积分

0

已下载文档

我的文档

我的专题

订单查询

积分变动

推介奖励

优惠券

收藏

账号安全
后台管理 退出登录
搜索历史
    智库文档 所有分类

    软件工程与软件项目管理.pdf

    下载

    Kdhaan
     |  2013-04-24 11:13 
    628页   |   4.60MB   |   4次下载 |  
    5.0
    (1人评价)
    我要评价：
    用手机看文档

    扫一扫,手机看文档

    下载
    开通VIP
    软件工程与软件项目管理 课时安排01第一一部分：项目管理框架9项目管理的目标与背景9项目管理的环境与职责9项目经理的权利与素质要求第二部分：项目过程控制9项目的范围管理9项目的时间管理9项目的成本管理9项目的质量管理9项目的风险管理第三部分：项目团队建设9项目的团队建设9项目的沟通管理9项目的激励与冲突第四部分：作业与练习 主要参考资料01教材张家浩主编《软件项目管理》机械工业出版社 三个小问题管理的意义切蛋糕的例子——什么是管理管理的方法走钢丝、找平衡——理论联系实际的思维方式学习的心态乘电梯的例子： 理论的意义：用系统研究代替管理者的直觉‡管理的职责之一是控制：‡度量绩效、发现偏差、进行纠正‡管理者的工作大部分是在“解读他人”‡观察别人的言行举止‡解释他为什么要这么做‡预测他下一步会怎么做‡作出必要的干预‡“解读”的方法：‡直觉、经验、推断、预测：人的行为习惯和行为模式‡管理者的知觉差异与解读：为什么联系不上了？‡用系统研究的成果指导管理活动，减少盲目性‡理论需要与实践结合，形成自己的方法‡学习的心态：放松！放松！放松！ 第一部分：项目管理的背景与框架‡什么是项目？项目与日常运作有什么区别？那些活动可以看成是项目？‡什么是项目管理？项目管理与现在的企业管理有什么不同？‡站在组织的角度：‡如何为项目确定目标？‡如何为项目提供资源？‡如何考核项目的绩效？‡如何给项目经理授权？‡如何为项目提供支持？‡第一部分，我们谈谈这几个不能退避的问题 第一部分项目管理框架 ¾引子——项目发展的历史‡项目管理有悠久的实践历史：古代长城、埃及金字塔、古罗马的供水渠‡项目和项目管理起源于工程和工程管理‡传统的项目和项目管理起源于建筑业‡现代项目与项目管理开始于大型国防工业‡国际项目管理学术组织的出现标志着项目管理走向了科学化和成熟化‡国际项目管理协会（International Project Management IPMA），成立于1965年‡美国项目管理学会（Project Management Institution PMI），成立于1969年 ¾项目管理发展的过程‡传统制造业管理的特点：可控、可重复、可预测、可改进‡管理改进的方式：标准、合理安排‡管理的目标：追求预期内的生产率、质量和成本目标。‡信息业管理的特点：‡不确定、不可简单重复、灵活性‡原来的管理方法“失灵”了——产生了项目管理的概念‡美国路易斯维化工厂：‡采用流程分解方法——节省38%‡美国北极星导弹‡采用关键路径方法——节省30% ¾项目管理专业的现状当代的项目管理已发展成为：‡一门学科‡广泛开展“项目管理知识体系”的研究‡一个专业‡在大学开设“项目管理”专业，可授予学士、硕士和博士学位‡一种职业‡职业项目经理‡项目管理专业资质认证 ¾软件项目经理——我的职业生涯设计‰程序员‰系统分析师‰技术管理人员（走上职能部门管理层）‰——光环效应‰专业技术管理人员‰高级职业经理人‰30岁过后的程序员，转向做销售？等着做管理？如果没有更好的去处，项目经理是一个不错的选择。 ¾国际项目管理发展的三个趋向‡项目管理的全球化: 主要表现在国际间的项目合作日益增多、国际化的专业活动日益频繁、项目管理专业信息的国际共享。‡项目管理的多元化: 行业领域及项目类型的多样性，导致了各种各样的项目管理方法，从而促进了项目管理的多元化发展。‡项目管理的专业化: 突出表现在PMBOK的不断发展和完善、学历教育和非学历教育竞相发展、项目与项目管理学科的探索及专业化项目咨询机构的出现。 ¾项目管理科学的双向发展项目管理学科学科化发展：项目管理知识体系学科与体系建设项目管理工具制度实用化发展：标准方法最佳标准化、规范化、实践工具化、制度化工具化制度化凝聚凝聚 项目管理与其他学科的关系项目管理知识体系„应用领域（以软件项目为例）：„现代软件工程，包括：需求工程、体系架构、软件过程、质量保证等„管理知识：„管理学„管理心理学（组织行为学） 应用领域的理论与实践知识基础——软件开发技术与生产过程现代软件工程框架模型：性性性确用济实现可正经软与件维软工程与模型（工程过程）护设件方法与技术（开发过程）计工具与环境（支持过程）分标准与规范（管理过程）析 利益相关者的目标投入员工、消费者、供应商人员、资金、管理股东、政府、其他投入和对投入、技术、其他资源的应用依赖计划保管理的内持理论与部组织系沟外部因素实践知统通和信息识基础人员及机会、制约的因素、其他与动领导外态部性控制联系产出产出产品、服务、利润满意度、目标一致《管理学》对管理的定义 什么是管理者的管理？管理者是在组织中监督他人的活动，并对目标承担责任的人20世纪初，法国工业家亨利.法约尔（Henri Fayol）提出的管理的五大职能：计划（Planning）：确定组织的控制（controlling）：对组织的实目标，制定达成这些目标的总体计划际绩效进行监控，发现偏差并进战略，把计划分解，以便对各部行纠正。分进行实施和协调。控制协调组织组织（Organizing）：决定要完成的任务目标、任务的责任人、领导（Leadind）：激励、指导、领导任务的边界和配合关系、报告关选择/建立/维护沟通渠道、解决系、决策点（授权）等。冲突。 不同的管理理论与不同的管理观：罗伯特.卡茨的法约尔的明茨伯格的三类管理角色五项职能三种管理技能•决策者•人际角色1.计划1.技术技能¾创业者¾代表人物2.组织2.人际技能¾混乱处理者¾提问题的人3.领导3.概念技能¾资源分配者¾教练、倡导人4.控制¾评判、仲裁人•信息传递角色¾信息传播者¾信息筛选者¾渠道建立和维护者 管理者的技能观1、技术技能没有是不可能的有也不是万能的2、人际技能润滑剂3、概念技能判断力：了解问题的根源所在知识与经验能力：提出切实可行的战略决策力：选择一个最佳的解决方案 管理者的人际技能：1）了解自己和管理任务：自身的能力、特长、欠缺？管理的目标和责任、影响力？2）了解团队和他人：团队的构成、人员的情况？3) 人际管理的基本技能：倾听、理解、表达、妥协、激励管理心理学研究作为管理者的行为特征：两种管理者‡科学管理——“应该”——理性管理‡行为管理——“愿意”——人性管理 项目管理的管理职能与管理层次高层管理计划组织控制中层管理领导项目管理基层管理高层管理用在计划和组织上的时间，远远超过其他管理者项目经理作为基层管理者的大部分时间，是领导。领导的概念：激励、指导、选择/建立/维护沟通渠道、解决冲突。 项目管理的管理技能与管理层次高层管理概念技能人际中层管理交往专业技能技术技能基层管理项目管理基层管理者的专业技能最为重要人际技能在哪里都是必须的而概念技能则对高层管理者更重要概念技能：判断力、知识与经验能力、决策力 项目管理：专业知识与管理经验的结合项目管理的九个知识领域人力资源管理范围管理整体管理成本管理时间管理质量管理风险管理采购管理沟通管理一般管理知识专业领域知识目标管理计划管理产品设计需求分析绩效管理组织结构体系结构质量控制项目管理是一般管理和专业知识的结合 项目经理深层次的知识：专业与管理项目管理的九个知识领域人力资源管理范围管理整体管理成本管理时间管理质量管理风险管理采购管理沟通管理软件需求过程一般管理知识UML需求获取体系结构分析目标管理计划管理需求链与追踪变更状态控制绩效管理组织结构管理心理学高级项目经理的能力提升：个体激励团队建设更多的实际经验积累；更多的组织文化领导风格专业与管理知识的补充。 现代软件开发与生产过程的综合与协同特性 ¾项目管理的专业资质认证与证书体系PMBOK/ICB项目PMP/IPMP个人组织OPM3（1）1985年PMI设立项目管理的资质认证制度（PMP）、基准是PMBOK，91年开始正式推广（2）1996年IPMA的四级证书的资质认证制度（IPMP）、基准是ICB（IPMA Competence Baseline），99年开始推出（3）中国的项目管理学科体系C-PMBOK和C-NCB也已经正式出版 项目经理的能力要求国际项目管理协会（International Project Management Association）的专业资质认证（IPMP）考试‡IPMP注重能力考核，能力＝知识＋经验＋个人素质是其基本定义‡IPMP C级以上考核，级别越高对于经验的要求越严格‡IPMP 笔试考核注重于解决实际问题的能力，并且试题考核以案例为导向‡WORKSHOP与案例报告是IPMP特有的考核形式，对于应试者个人素质及解决问题的能力考核非常重要‡IPMP的项目报告和面试着重于对应试者综合素质的考核，全面了解应试者从事项目管理的理念和能力 IPMP对项目经理的能力考核要求‡基本能力：管理，项目和项目管理，项目背景和利益相关者，系统方法和项目管理，项目管理实施，项目目标，项目成功与失败的准则，项目阶段，项目生命期，标准与指南‡方法能力：项目结构，过程和时间管理，资源管理，成本管理，财务管理，实施测量和项目进展，项目控制，多项目管理，创新技术，解决问题 IPMP对项目经理的能力考核要求‡个人素质：沟通能力；首创精神，务实，热情，激励能力；联系的能力，开放性；灵敏，自我控制，价值鉴赏能力，乐意负责任，人格诚实；解决冲突，辩论文化，公正；解决问题能力，全面思考，公正；忠诚，坚强，乐于助人；领导艺术‡社会能力：洞察力，激励，社会化结构，小组和团队，学习型组织，自我管理，领导艺术，冲突管理，特殊交流状况‡总体印象：常理（常识），逻辑和系统，语言／文字表达能力，综合能力，明晰，技能，知识水平，经历（阅历） ¾IPMP的考核标准‡IPMP C级‡笔试160分‡IPMP D级‡案例讨论120分‡仅有笔试‡面试120分‡笔试总分为160分‡总分为400分‡通过标准为110分‡通过标准：‡笔试最低100分‡注重理论与案例相结合的考核‡案例讨论＋面试最低140分‡相对全面的综合考核‡总分最低为280分‡题型以选择题和问答题相结合‡以实际案例为导向‡注重项目管理核心方法的考核‡强调方法的应用‡题型为问答题 ¾IPMP的考核标准‡IPMP B级‡笔试总分为160分（不计入总分，C级以上者免考）‡项目报告200分‡IPMP A级‡答辩+面试200‡项目报告200分‡总分：400分‡答辩+面试200‡通过标准：‡笔试最低100分‡总分：400分‡项目报告120分‡通过标准：‡答辩+面试120分‡项目报告120分‡总分最低为280分‡答辩+面试120分‡总分最低为280分 ¾PMP考试‡PMP考试是以双语，中/ 英文进行(只在中国)。200条选择题於4小时‡PMP的考试内完成。考试范围包括5个项目管‡美国项目管理学会理流程及PMI项目管理知识体系(PMBOK)内之9个知识领域。（PMI）组织‡由2002年起，考试的分布形式如下：‡申请资格‡起始% ‡学士学位者4500小时工作经验/以下‡计划% 7500（3-6年）‡执行% ‡填写申请书‡控制-23% ‡认证费‡结尾-7% ‡考试‡专业责任% ‡笔试 ¾国家信息产业部项目经理考试‡考核共分为两部分——结‡结业考试业考试、结业论文，考核‡一、考试时间：150分钟总分为100分，其中结业考‡二、考试方式：闭卷考试试分数占75%，结业论文分‡三、题型：选择题（四选一）数占25%。考试的及格分数为60分，结业考试和结业‡四、考核范围：系统集成项目管理基论文所得分数超过60分为础、系统集成技术及最新发展、系统及格。集成行业相关法律法规、系统集成项目经理资质管理概论。‡为保证考核的客观性和公正性，项目经理结业考试科目题分由信息产业部指定机构负量数系统集成项目管理基础6060责考试题目的拟定并负责阅卷，考试的题目从信息系统集成典型技术最新发展1020产业部认可的题库中抽法律法规510取；结业论文由信息产业部指定机构组织专家进行系统集成项目经理资质管理概论510评阅。总计77100 第一章•目录项目与项目管理的概念项目的组织与项目经理 § 项目与项目管理的概念 项目的概念‰自从有了人类，人们就开展了各种有组织的活动。‰随着社会的发展，有组织的活动逐步分化为两种类型：y一类是连续不断、周而复始的活动，人们称之为“运作”（Operations），如企业日常的产品生产活动；典型的例子：流水线的生产。y另一类是临时性、一次性的活动，人们称之为“项目”（Projects），如企业的一次技术改造活动、一项建设工程的实施。 典型的项目‡建造一座大楼、一座工厂或一座水库‡举办各种类型的活动，如一次会议、一次晚宴、一次庆典等‡新企业、新产品、新工程的开发‡进行一个组织的规划、规划实施一项活动‡进行一次旅行、解决某个研究课题、开发一套软件在当今社会中，一切都是项目，一切也将成为项目。—美国项目管理专业资质认证委员会主席Paul Grace 项目的定义‰项目：是一个特殊的、将被完成的有限任务，它是在一定时间内，满足一系列特定目标的多项相关工作的总称。‰理解项目的定义，实际包含三层含义：•项目是一项有明确目标并待完成的任务；•项目是在一定的环境下及在一个特定的组织机构内，利用有限资源（人力、物力、财力等）在规定的时间（时间也是有限的资源）内完成任务；•任务的完成要满足一定功能、性能、质量等具体技术指标要求。 项目定义涉及的因素明确界定的沟通工作范围一次性工作团队精神预定的经费项目开始日期临时组织结束日期明确具体的目标 项目的主要属性‡一次性：有明确的开始/结束时间‡独特性：没有以完全相同方式、完全相同的人完成‡目标确定性/过程的不确定性‡活动的整体性/过程的渐进性‡团队的临时性与开发性‡对资源的依赖性 项目与作业的比较项目管理日常运作一次性执行在现有系统基础上重复执行以目标和成果为导向通过改进来追求效率和质量项目经理营造氛围并与项基于管理结构的线形管理目团队一起工作基于绩效度量、计划控制、保持稳定和连贯性变更管理项目团队与职能组织的比较项目团队职能组织人员是临时的人员是固定的人员的技能各不相同人员的技能基本相同原级别关系在项目组无效人员的上下级关系明确项目结束，项目组就解散长期稳定地一起工作 项目的组成要素‡项目的目标与范围基本要素‡项目的组织结构‡项目的质量受制于目标范‡项目的费用围和组织结构‡项目的时间进度 项目的三重约束质量功能要求目标时间费用有限预算质量费用完成期限时间成功的项目必须满足客户、管理层和供应商在时间、费用和性能上的不同要求。 什么是系统集成？‡把多个系统（硬件系统、软件系统或网络系统）组合到一起，为实现某种特定的目标，按照系统设计方案和客户要求，最大发挥出各子系统的功能，使组合后的系统性能达到最优的集成过程。 系统集成项目的特点‡需求不清晰、不明确、易变性很大‡客户要求工期相对很短‡不可预见的费用很高‡客户对实施质量要求较高‡多专业交叉‡技术先进、系统架构复杂‡缺乏有效的项目监理 案例分析王总的困惑：王总经营一家小型的软件公司，为某行业做管理信息系统。早几年，工作非常顺利，哥儿们几个干的得心应手，用户关系王总一人全部搞定。可是，公司发展大了，项目却越来越难做了。倒不是因为用户关系方面，而是项目时间越来越长、迟迟不能结束。在王总看来，手下的几个高手，现在是越来越搞不定了。技术没有什么变化，用户还是老用户，是他们的能力下降了？还是他们不想干了？好象都不是。那是为什么呢？问题：什么时候开始需要项目管理？ 项目管理的相关要素项目管理是通过项目各方干系人的合作，把各种资源应用于项目，以实现项目的目标，使项目干系人的需求得到满足的过程。项目管理的基本要素即：项目的生命周期、项目干系人、资源、目标和需求。 项目管理的要素——项目干系人‡项目参与人‡项目参与人是指项目的直接参与各方。‡简单项目：假日旅行只有自己参与，生日家宴只有主人和客人两方参与。‡大型复杂的项目往往有多方面的人参与‡例如：建筑工程的参与方有：建设方、投资方、贷款方、承包人、供货商、建筑/设计师、监理工程师、咨询顾问等。‡项目参与人：甲方、乙方，第三方：监理‡项目干系人‡项目干系人的概念，比参与人要广泛的多‡项目干系人包括项目参与人和其利益受该项目影响（受益或受损）的个人和组织；也可以把他们称作项目的利害关系者。‡除了项目参与外，项目干系人还可能包括政府的有关部门、社区公众、项目用户、新闻媒体、市场中潜在的竞争对手和合作伙伴等；甚至项目班子成员的家属也应视为项目干系人。 项目管理的要素——资源资源：‡由于项目固有的一次性，项目资源不同于其他生产活动的资源，它多是临时拥有和使用的。‡资金需要筹集，服务和咨询力量可采购（如招标发包）或招聘，有些资源还可以租赁。‡项目过程中资源需求变化甚大，获得的时间和资源质量影响项目。有些资源用毕后要及时偿还或遣散，任何资源积压、滞留或短缺都会给项目增加成本。‡资源的合理、高效的使用对项目管理尤为重要。 项目管理的要素——目标目标：9项目要求达到的目标可分为两类，必须满足的规定要求和隐含或附加的期望要求。9规定要求包括：项目实施范围、质量要求、利润或成本目标、时间目标以及必须满足的法规要求等。这里指的是狭义的质量，如项目及项目成果的技术指标和性能指标等；9在一定范围内，质量、成本、进度三者是互相制约的；9期望要求常常包括对开辟市场、争取支持、减少阻力产生重要影响。譬如：一种新产品，除了基本性能之外，外形、色彩、使用舒适，建设和生产过程有利于环境保护和改善等，也应当列入项目的目标之内。 项目管理的要素——需求需求：项目要求达到的目标是根据需求和可能来确定的。‡一个项目的各种不同干系人有各种不同的需求，有的相去甚远，甚至互相抵触。这就要求项目管理者对这些不同的需求加以协调，统筹兼顾，以取得某种平衡，最大限度地调动项目干系人的积极性，减少他们的阻力和消极影响。‡项目干系人的需求往往是笼统的、含糊的，他们有时缺乏专门知识，难以将其需求确切、清晰地表达出来。因此需要项目管理人员与干系人充分合作，采取一定的步骤和方法将其确定下来，成为项目要求达到的目标。‡项目干系人在提出其需求时，未必充分地考虑了其实现的可能性。项目管理者还应协助用户进行可行性研究，评估项目的得失，调整项目的需求，优化项目的目标。有时可引导用户和其它干系人去追求进一步的需求，有时要帮助他们放弃不切实际的需求，有时甚至要否定一个项目，避免不必要的损失。‡项目干系人的需求在项目进展过程中往往还会发生变化，项目需求的变化将引起项目目标、范围、计划等一系列相应的变化。因此，根据需求进行范围管理自始至终都是项目管理中极为重要的内容。‡在软件项目中，对需求的控制和管理，发展为软件需求工程 项目管理的定义项目管理就是以项目为对象的系统管理方法，通过一个临时性的、专门的柔性组织，运用相关的知识、技术和手段，对项目进行高效率的计划、组织、指导和控制，以实现项目全过程的动态管理和项目目标实现过程的综合协调与优化。 项目管理概念的理解‡项目管理的对象——项目‡项目管理的组织特点——临时性、富有柔性‡项目管理的手段——计划、组织、指导和控制‡项目管理的目标——实现项目全过程的动态管理及项目目标实现过程的综合协调与优化 项目管理的特点◆项目管理的对象是项目或被当作项目来处理的运作。◆项目管理的思想是管理的系统方法论。◆项目管理的组织通常是临时性、柔性、扁平化的组织。◆项目管理的机制是项目经理负责制，强调责权利的对等。◆项目管理的方式是目标管理，包括进度、费用、技术与质量的综合协调优化。◆项目管理的要点是创造和保持一种使项目顺利进行的氛围与环境。◆项目管理的方法、工具和手段具有先进性和开放性。 项目管理与一般作业管理的区别‡一般的作业管理：①目标：注重对效率和质量的考核②方法：注重当前执行情况与前期进行比较‡项目管理：①充满了不确定因素②跨越部门的界限③有严格的时间期限要求‡项目管理在不完全确定的过程中，追求在确定的期限内、生产出不完全确定（需求变化）的产品，进度控制常对项目管理产生很大的压力。‡在典型的项目环境中，尽管一般的管理办法也适用，但管理方式，必须突出以任务（活动）定义为基础来建立，以便进行时间、费用和人力的预算控制，并对技术、风险进行管理。 案例分析：项目管理与产品管理的区别‡项目经理PM‡产品经理PM‡项目管理与产品管理的区别？‡在软件开发企业，什么时候是产品开发，什么时候是项目开发，有什么区别？‡产品经理的考核目标是什么？项目经理的考核目标是什么？如何界定？‡因此，产品管理与项目管理的差别是什么？‡从案例中，如何体现项目管理的特点？ 技术、产品、项目的继承关系技术产品产品产品产品项目项目项目项目项目 技术、产品、项目生命周期的嵌套关系基于产品项目基于基础产品实用产品基于应用成果研究基础产品基于基础技术研究应用成果基于核心技术突破基础研究 项目的生命周期确定需求进度安排项目评估项目实施成本预算项目论证项目总结项目控制验收标准项目选择启动阶段计划阶段实施阶段收尾阶段新的项目设想 项目的生命周期阶段——启动阶段及其主要工作完成工作量时间启动阶段9风险分析9拟订战略方案9明确需求、策划项目9进行资源测算9调查研究、收集数据9提出组建项目组方案9确立目标9提出项目建议书9进行可行性研究9获准进入下一阶段9明确合作关系 项目的生命周期阶段——计划阶段及其主要工作完成工作量时间计划阶段9项目经费及现金流量的预算9确定项目组主要成员9项目的工作结构分解（WBS）9项目最终产品的范围确定9项目政策与过程的制订9实施方案研究9风险评估9项目质量标准的确定9确认项目有效性9项目的资源保证9提出项目概要报告9项目的环境保证9获准进入下一阶段9主计划的制订 项目的生命周期阶段——实施阶段及其主要工作完成工作量时间实施阶段9建立项目组织9执行WBS的各项工作9建立与完善项目联络渠道9获得订购物品及服务9实施项目激励机制9指导/监督/预测/控制：范围、9建立项目信息控制系统质量、进度、成本9建立项目工作包，细化各项技术需9解决实施中的问题求 项目的生命周期阶段——收尾阶段及其主要工作完成工作量时间收尾阶段9文档总结9最终产品的完成9资源清理9评估与验收9转换产品责任者9清算最后帐务9解散项目组9项目评估 项目的生命周期阶段与项目生命周期有关的其他重要概念——（1）检查点‡指在规定的时间间隔内对项目进行检查，比较实际情况与计划之间的差异，并根据差异进行调整。‡可将检查点看作是一个固定“采样”时点，而时间间隔则根据项目周期长短不同而不同，频度过小会失去意义，频度过大会增加管理成本。‡常见的间隔是每周一次，项目经理可通过周报告、召开例会等形式，进行检查。（2）里程碑‡完成阶段性工作的标志，不同类型的项目，里程碑不同。里程碑在项目管理中具有重要意义 项目的生命周期阶段与项目生命周期有关的其他重要概念——（3）基线‡是一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。‡在项目管理中，需求、进度、成本、质量等基线，都是一些重要的项目阶段里程碑，但相关交付物要通过正式评审并作为后续工作的基准和出发点——即达到基线标准。‡基线一旦建立后变化需要受控制。小结：9项目生命周期可以分成项目启动、计划、实施和收尾四个阶段。9项目应该在检查点进行检查，比较实际和计划的差异并进行调整；9通过设定里程碑，来增强控制、降低风险；而基线是重要的里程碑，交付物应通过评审并开始受控。 项目的生命周期阶段——软件项目的项目阶段传统软件工程一般把一个软件生命周期包括六个阶段：（1）计划阶段：定义系统，确定用户的要求或总目标，进行可行性研究，提出可行的方案，包括资源、成本、效益、进度等，并制定粗略的实施计划。（2）需求分析阶段：确定软件功能、性能、可靠性、接口标准等要求，根据功能要求进行数据流程分析，提出初步的系统逻辑模型，并据此修改项目实施计划。（3）软件设计阶段：包括系统概要设计和详细设计。在概要设计中，要建立系统整体结构，进行模块划分，根据要求确定接口。在详细设计中，要建立算法、数据结构和流程图。（4）编码阶段：把流程图翻译成程序，并对程序进行调试。可见编码的实现方式与软件的处理流程是相对独立的。 项目的生命周期阶段——软件项目的项目阶段（5）测试阶段：通过单元测试，检验模块内部的结构和功能；通过集成测试，把模块联结成系统，重点找接口上的问题；确认测试：按照需求的内容逐项进行测试；系统测试，就是到实际的使用环境中进行测试。以上四种测试中，单元测试和集成测试是由开发者自己完成的，而确认测试和系统测试则是由用户参与完成的。这是软件质量保证的重要一环。（6）运行维护阶段：一般包括三类工作，为了修改错误而做的改正性维护，为了适应环境变化而做的适应性维护，为了适应用户新的需求而做的完善性维护，这有时会成为二次开发，进入一个新的生命周期，再从计划阶段开始。可见，维护的工作是软件生命周期中重要的一环，通过良好的运行维护工作，可以延长软件的生命周期，乃至为软件带来新的生命。 对项目阶段的认识——迭代开发的软件阶段 对项目阶段的认识——开发模型对阶段的影响9阶段划分的不同9严格程度的不同9目标要求的不同 项目管理的主要内容时间管理范围管理成本管理采购管理质量管理项目管理风险管理整体管理沟通管理人力资源管理 PMBOK的基本概念¾美国项目管理协会（Project Management Institution, PMI）于1969年在美国宾州成立，是目前全球影响最大的项目管理专业机构，其组织的项目管理专家认证（Project Management Professional, PMP）被广泛认同。PMI的突出贡献是总结了一套项目管理知识体系（Project Management Body Of Knowledge, PMBOK）。¾PMBOK总结了项目管理实践中成熟的理论、方法、工具和技术，也包括一些富有创造性的新知识。 PMBOK的基本概念¾9个知识领域PMBOK把项目管理知识划分为九个知识领域（综合、范围、时间、成本、质量、人力资源、沟通、风险和采购），每个知识领域包括数量不等的项目管理过程。¾过程：产生一系列结果的活动¾项目管理过程：以过程方式，描述并组织项目的活动¾PMBOK的39个过程PMBOK对9个知识领域，按照输入、工具与技术、输出，再分为数量不等的管理过程。因此，所谓过程就是基于一定输入，采用相关工具和技术，产生一定输出的活动集合。项目是由各种过程组成的。PMBOK一共建立了39个过程。 项目管理的39个过程-1过程组启动计划执行控制结束知识领域综合项目计划项目计划整体变更编制实施控制范围启动范围计划范围确认范围定义范围变更控制时间活动定义进度控制活动排序活动历时进度安排成本资源计划成本控制成本估算成本预算质量质量计划质量保证质量控制 项目管理的39个过程-2过程组启动计划执行控制结束知识领域人力资源组织计划团队发展人员获取沟通沟通计划信息分发绩效报告管理收尾风险风险计划风险监控风险识别定性分析定量分析风险应对计划编制采购询价、供合同收采购计划方选择、尾询价计划合同管理 系统集成项目管理的过程及内容阶段启动计划执行收尾资源配置水平5％20％60％15％每市场开拓指定项目经理建立项目组织和原则个需求分析项目范围基准建立沟通机制阶建立：方案的详细设计建立激励制度项目验收准备段 可行性报告合同制定和确立指导与控制：范围、文档的整理中 目标和目的工作分解WBS质量、时间、成本遗留问题的确认完 干系人确认总计划的制定子项目的划分和细化交付物审核成招投标资源/成本计划计划再确认项目初步验收的可能的团队范围计划采购试运行典估计资源风险计划系统集成实施系统运行报告型初步设计方案进度计划网络系统集成终验活提交建议书采购计划软件系统集成项目后评审动下一阶段批准质量计划系统测试时间/项目章程提交项目概要资源成本重新分配资源控制线合同确定批准继续进行解决问题重新分配项目队伍 项目管理的核心——目标管理《管理学》中有关目标管理的理论：‡目标管理（MBO ，Management by Objective），由彼得.杜拉克（Peter Drucker）1954年提出。‡目标管理是这样一种管理系统：‡它将许多关键的活动联系在一起‡通过设定具体、可度量的目标‡以此为依据，定义个人或部门的管理责任‡从而实现组织和个人的目标得以高效率的完成。 《管理学》的目标管理理论‡目标管理的特性：‡目标多层次性：社会、组织、部门、个人‡目标的多样性（大学为例）：教育、研究、人才培养、贡献社会……‡目标的可考核性：不可考核的目标可考核的目标1、获取合理的利润1、在本财务年度内实现12%的投资收益率2、加强部门间的沟通2、在12月30日前，开始发行三期公司内部情况通报，在每期出版前10天，每个部门都必须按规定的内容，提交情况报告内容。3、提高员工的素质3、年底前开办《管理心理学》讲座，通过考试的部门经理和项目经理应达到90%以上。4、采用计算机辅助项4、在11月30日前，完成“***项目管理系统”软件的安装、调目管理试和培训，并将目前正在使用中的项目计划，全部移到该系统上运行。 项目的目标管理‡目标管理最主要的特点，是以目标和成果为导向‡目标管理的优点是：‡通过以目标和结果为导向的计划，改进了管理方法‡有利于根据组织结构和任务，及预期的结果授权‡鼓励员工致力于各自的组织目标和个人目标的完成‡可以建立有效的控制机制、绩效度量机制和采取纠正偏差的措施‡项目管理特别适合采用目标管理的方式：目标和成果导向¾项目组内：‹项目组内部各领域是按目标管理的‹项目各生命周期阶段是按目标管理的¾组织内：‹项目管理方式是以目标为导向的‹项目目标与组织的目标一致‹项目组按目标考核‹项目经理按目标获得责权利的授权 如何为项目确定目标并授权？‡项目目标的外部标准——合同‡项目目标的内部标准——企业规范‡项目目标的案例：‡《公安OA项目任务责任书》‡要点：‡用户确认的交付成果：初验/终验报告‡内部考核的交付成果：程序、文档、评审报告‡项目考核：进度、成本、质量‡项目经理的授权‡《公安OA项目任务与责任描述》 项目管理为企业带来什么价值¾合理安排项目的进度，有效使用项目资源，确保项目能够按期完成，并降低项目成本。通过项目管理中的工作分解结构WBS、网络图和关键路径PDM、资源平衡、资源优化等一系列项目管理方法和技术的使用，可以尽早地制定出项目的任务组成，并合理安排各项任务的先后顺序，有效安排资源的使用，特别是项目中的关键资源和重点资源，从而保证项目的顺利实施，并有效降低项目成本。如果不采用项目管理的方法，我们通常会盲目地启动一个项目，将所有资源平均地安排在项目中，可能会有很多的人员、任务的瓶颈，同时也会造成很多的资源闲置，这样势必会造成资源和时间的浪费。 项目管理为企业带来什么价值¾加强项目的团队合作，提高项目团队的战斗力。项目管理的方法提供了一系列的人力资源管理、沟通管理的方法，如人力资源的管理理论、激励理论、团队合作方法等。通过这些方法的使用，可以增强团队合作精神，提高项目组成员的工作士气和效率。¾降低项目风险，提供项目实施的成功率。项目管理中重要的一部分是风险管理，通过风险管理可以有效降低项目的不确定因素对项目的影响。其实，这些工作是在传统的项目实施过程中最容易被忽略的，也是会对项目产生毁灭性后果的因素之一。 项目管理为企业带来什么价值¾有效控制项目范围，增强项目的可控性。在项目实施过程中，需求的变更是经常发生的。如果没有一种好的方法来进行控制，势必会对项目产生很多不良的影响，而项目管理中强调进行范围控制，变更控制委员会（CCB）和变更控制系统的设立，能有效降低项目范围变更对项目的影响，保证项目顺利实施。¾可以尽早地发现项目实施中的问题，有效地进行项目控制。项目计划、执行状况的检查以及PDCA工作环的应用，能够极早地发现项目实施中存在的问题和隐含的问题，这样项目就能顺利执行。 项目管理为企业带来什么价值¾可以使得项目决策更加有依据，避免了项目决策的随意性和盲目性。¾可以有效地进行项目的知识积累。传统的项目实施中，经常在项目实施完成时，项目就嘎然而止，对于项目的实施总结，技术积累，都是一种空谈。但目前知名的跨国公司之所以能够运作很成功，除了有规范的制度外，还有一个因素就是有比较好的知识积累。项目管理中强调项目结束时，需要进行项目总结，这样就能将更多的公司项目经验，转换为公司的财富。总之，项目管理可以使得项目的实施顺利，降低项目的风险性，最大程度地达到预期的目标。 项目管理与企业管理¾什么样的企业需要按项目管理？¾任务规模大的项目：当一个项目需要更多的资源（人、财、物、技术等）时，就需要项目管理。当然这种更多是相对的，通常判断的依据是：是否在一个组织或者一个部门所能控制的范围之内。例如三峡工程、火箭发射项目、奥运会项目等均需要项目管理。¾新项目：如果项目在以前没有过成功的案例或经验，就需要项目管理。例如：对于现有产品的改进，不设立项目管理，效率可能会比较差，但也能进行；但是对于新产品的设计就必须要项目管理。 什么样的企业需要按项目管理¾重要的项目：一般情况下，当项目有高风险性和不确定因素时，会采用项目管理。同时，当这个项目关系到公司的声誉，对公司的业务发展和未来规划产生重要影响时，也应该采用项目管理。¾一些项目主导型组织，如咨询服务公司、工程建设公司、软件开发公司、系统集成公司等非常需要项目管理，因为它的产品和服务都是通过项目的形式展现出来的，同时几乎所有的项目也都存在以上的某些特点。 项目管理为现代企业管理带来的变革‡现代企业管理的三大支柱‡战略管理——面向未来（决策能力）‡营销管理——面向成果（外部市场执行能力）‡项目管理——面向过程（内部运营执行能力）‡企业管理（MBA）：‡经营战略‡市场营销‡新产品开发‡生产管理‡人力资源管理‡财务管理‡信息技术管理（新增）‡知识管理等（新增）‡项目管理是战略管理和营销管理之间的载体 项目管理为现代企业管理带来的变革‡按专业特点建立的职能型组织结构的弊端‡对市场变化反应慢‡以部门利益为中心‡资源整合困难‡不适合动态管理‡绩效考核的量化困难‡权力结构的僵化‡项目经理的权力与非常具体的目标挂钩‡项目经理的权力是动态的‡项目经理的权力随项目的结束而结束 项目管理为现代企业管理带来的变革‡项目管理为企业的发展带来的变革‡组织的灵活性：‡职能型向项目型转化‡项目型是：‡面向对象（项目）的‡协调（部门间）资源的‡目标管理和协调一致的‡管理责任的分散‡目标分解（以具体可度量的项目为目标，而不是以模糊的部门责任为目标）‡责任明确（时间、成本、质量） 项目管理为现代企业管理带来的变革‡以目标为导向：‡项目目标与企业的目标一致‡多层次、明确的目标‡分阶段、可检查‡责任分工不同、但非常明确清晰‡强调在约束的条件下的实施结果‡对复杂问题集中资源攻关：‡项目一般是涉及需要跨部门解决的复杂的问题‡项目的不确定性因素比较多‡项目干系人的利益协调比较困难‡这些问题在职能模式下无法解决‡项目型企业更关注企业的整体目标 项目管理为现代企业管理带来的变革‡个人发展与组织发展的有效结合‡企业通过项目的成功获得发展，实现企业的目标‡员工随项目的成功而获得个人的发展‡以成功项目为单位‡直接的经济利益‡具体的项目经验‡逐步的能力提升‡发展空间的扩大‡这在职能部门下是非常困难的‡成绩是可视的、可度量的、可比较的‡新型企业文化的变革 企业项目管理的关注点‡企业管理与项目管理的交汇点‡企业为项目：‡设定目标‡明确责任‡提供资源‡进行企业级的控制（变更控制）‡获取成果‡项目组：‡在项目的执行过程中，按目标和要求独立运作‡承担责任 企业项目管理的关注点‡企业管理为项目管理提供的条件‡企业战略：‡影响项目的目标（市场定位、项目优势、项目目标等，是追求利润，还是追求份额）‡资源条件（多项目组合）‡企业级的内部管理制度和流程‡控制方式和方法（例如：评审流程和授权）‡规范和规章（例如：软件开发的内部规范）‡人力资源管理‡财务管理 组织的项目管理成熟度的方向‡企业高层管理的支持‡认识和理解‡启动和推进的责任‡为项目管理提供的条件‡主导企业文化的变革：‡统一的方法‡从项目组级到组织级（统一的方法）‡多项目组合管理（资源的整合）‡项目管理成为企业管理的核心‡权力结构和企业文化的变化‡人力资源和财务管理的变化‡横向负责和纵向负责并行权力的再分配‡绩效考核方法等的变化带来的企业文化的变化‡职能管理和项目管理的新边界‡从以上几个方向，看组织的项目管理成熟度 组织项目管理成熟度的意义‡单个项目管理的成功‡优秀的项目经理个人的贡献‡项目团队的努力‡但可能不能受到企业制度和管理体系的认同和保障‡不具备连贯性‡不具备稳定性‡没有可比较性‡不具备可重复性‡不具有可保障性‡这就是项目管理的初级阶段‡组织项目管理成熟度——定义企业级项目管理的更高级阶段 我们身边项目管理成功的例子¾我自己的例子：¾南京10家系统集成1、2级企业的例子¾国内成功的例子¾国外成功的例子¾问题讨论：项目管理适合我们吗？ 问题讨论：项目管理适合我们吗？¾什么是项目管理？¾以项目（明确的目标、有限的资源、确定的技术要求和责任）为对象¾通过一个临时性、富有柔性的组织¾采用一系列的计划、组织、指导和控制手段¾实现项目的目标¾我们是这样的吗？¾有目标和要求吗？不能说没有！¾是一个项目团队吗？可能就是我一个人，但需要与很多人打交道！¾需要计划、组织、控制、协调、沟通吗？特别需要，就是干这些事！¾达到项目目标是我的压力吗？即使现在不是，马上就要是了！！！¾还有什么问题？这里面不确定因素太多了！ 谢谢！Keep Connecting In The Future 软件工程与软件项目管理 课时安排01第一一部分：项目管理框架9项目管理的目标与背景9项目管理的环境与职责9项目经理的权利与素质要求第二部分：项目过程控制9项目的范围管理9项目的时间管理9项目的成本管理9项目的质量管理9项目的风险管理第三部分：项目团队建设9项目的团队建设9项目的沟通管理9项目的激励与冲突第四部分：作业与练习 § 项目的组织与项目经理 有关组织理论即使项目经理个人领导能力再强，他也是在一定的组织环境中工作，组织对项目的影响是决定性的。组织的定义：现代管理理论认为，组织是一个具有特定目标、资源与结构，时刻与环境相互作用的开放系统。输入输出环境环境转换作为开放系统的组织 什么是组织？组织的存在必须具备的三个条件：‡组织是人组成的集合‡组织通常都有自己存在的理由和既定目标‡组织一般通过内部的专业分工和协调来实现自己目标目标组织约束委托人员 组织管理“为了使人们能为实现目标而有效地工作，就必须设计和维持一种职务结构（a tsructure forloe）s。这就是组织管理的目的。”———————[美aH]rlo dKnoot z 现代管理学的组织理论1、传统的（古典的）组织理论以韦伯（）为代表，该理论又称行政组织理论，认为组织就是是一个金字塔机构。主要观点是：（1）组织有明确规定的职权与等级制度（下级处于上级的严密控制之下）（2）专业化分工（3）不受个人感情的影响（4）规章制度明确（5）职工的选聘和晋升主要依靠技术能力该理论强调组织是一个钢性的封闭系统，严格管理有利于组织规范化，但这种组织概念是一种僵化的缺乏弹性的组织结构。 现代管理学的组织理论2、新古典的组织理论由斯科特（cStot）和莫尔（Mrooe）等提出主要观点是：（1）在集权与分权的问题上，强调分权。集中政策，分散管理（斯隆模式）。（2）在组织形态上，倾向于扁平式的结构（3）强调部门化分工新古典组织理论开始引入了社会学的概念，强调下属参与决策、激励和协调。 现代管理学的组织理论3、现代组织理论代表人物有露曼斯（Homans）卡恩（Kanh）等人。强调系统理论和权变理论在管理和组织方面的运用，核心问题是把组织看作是一个开放的社会技术系统：该理论认为，组织中的任何系统的变化都会影响其他系统的变化，组织是开放的，不断与外部进行物质、能源、信息的交换。因此，不存在一成不变的适应一切的组织管理模式。 系统的动态性现代组织理论投入组织的转换过程产出投入/产出模型外部环境组织系统的运转需求‡资源的需求‡组织行动过程的效率需求‡组织的实际产出需求‡组织的发展需求‡组织与环境相一致的适应性需求‡组织构成要素中人的满足需求 姓名职务组织过程与组织结构姓名姓名姓名工作划分（目标、流程）职务职务职务工作归类（任务、责任）组织结构（岗位、职责）组织设计过程的结果¾组织结构图¾岗位职责说明书 组织过程与组织结构姓名职务z组织结构表现为部门结构和权责z组织结构关系界定了对工作任务姓名姓名姓名进行正式分解、组合和协调的方式职务职务职务‡组织结构的形成要体现出以下几个方面的特征：‡工作专门化：分工导致的工作细化‡结构部门化：职能部门化，产品部门化，地域部门化，过程部门化，顾客部门化‡组织命令链：不间断的报告关系，维护命令的统一性‡控制管理跨度：跨度与层次，跨度与沟通，跨度与能力‡集权与分权：集权与分权的相对性，分权与控制‡结构正规化：正规化，规范化，自主权，灵活性 如何构建一个合理的团队？‡目标的一致性和管理的统一‡有效的管理幅度和层次‡责任和权利对等‡合理分工和密切协作‡集权与分权相结合‡纪律和秩序‡团队精神 影响管理幅度和层次的因素¾工作能力¾工作内容和性质¾工作条件¾工作环境 项目管理组织的特点一般组织的特点项目管理组织项目及项目管理的特点 项目管理的组织形式‡职能型组织形式‡项目型组织形式‡矩阵型组织形式‡弱矩阵‡平衡矩阵‡强矩阵 职能式组织形式—职能主管负责项目协调管理执行主管项目协调evitucex EfeihC职能主管职能主管职能主管Functional ManagerFunctional ManagerFunctional Manager职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS特征：权力在职能经理、协调也需要职能经理 项目式组织形式—项目主管负责项目协调管理执行主管项目协调evitucex EfeihC项目主管项目主管项目主管Project ManagerProject ManagerProject Manager职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS特征：资源全部集中在项目组，只有大型项目才行 弱矩阵式组织形式—联络员+职能主管执行主管evitucex EfeihC职能主管职能主管职能主管Functional ManagerFunctional ManagerFunctional Manager职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS项目联络特征：权力在职能经理、联络员就当是个送信的 平衡矩阵式组织形式—协调员+职能主管执行主管evitucex EfeihC职能主管职能主管职能主管Functional ManagerFunctional ManagerFunctional Manager职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS职员ffatS项目协调项目协调员职员ffatS职员ffatSProject Staff特征：case by case的授权，协调员要多跑几趟 强矩阵式组织形式—项目经理负项目责任执行主管evitucex EfeihC项目管理部职能主管职能主管职能主管Manager ofFunctional ManagerFunctional ManagerFunctional ManagerProject Managers项目经理职员ffatS职员ffatS职员ffatSProject manager项目经理职员ffatS职员ffatS职员ffatSProject manager项目经理职员ffatS职员ffatS职员ffatSProject manager特征：对项目经理一次性授权，资源向项目经理倾斜 选择合适的项目组织形式（1）各种组织形式的区别（2）各种组织形式的作用差异（3）各种组织形式的优劣比较（4）PMBOK所倾向的组织形式—强矩阵（5）选择合适自己的项目组织形式PMBOK的新概念：项目管理办公室办公室：对项目经理提供支持支持活动：工具、方法、培训项目经理的工作地点（娘家） 问题思考：项目管理的组织形式与员工行为例：某企业是以项目为基础的企业，即企业的经营活动是有许多项目活动有机构成。为了适应企业的这一特点，企业组织结构采用了矩阵式组织结构，但是在项目运作过程中，项目的资源如人员经常会受到项目经理及职能经理的双重领导，降低了运作效率和效果。某项目经理为了使项目成员在项目存续期间不受干扰，规定在项目成员进入项目组必须接受这样一条约束，即在项目组工作时不与原属职能部门发生任何联系。请分析这位项目经理的做法是否合理？ 项目管理与项目经理 什么是领导第一种：领导（名词）头面人物、领导人、联络人、监督人、传播人、发言人、企业家、应急人、资源分配者、谈判人¾领导是一种职位象征¾领导是个体行为和人格特征的体现¾领导是一系列的行为过程¾领导是一种直接的人际影响力、是沟通过程所表现出来的一种达成组织目标的能力。¾领导是在期望和交互作用中所表现出来的对组织的创造力和维持才能。 第二种：领导（动词）管理者利用组织赋予的职权和个人具备的能力去指挥命令影响和引导员工为实现组织目标而努力工作的活动过程9领导是一种对组织运行的持久影响力。9领导是一种人际交互作用，即领导的行为可以决定着他人的生产效率。9领导是一种促使下属按照所要求的方式进行活动的过程。9领导是一项程序，使人在选择目标及达成目标上接受指挥、导向和影响。9领导是指引和引导个人或组织，在一定条件下实现其目标的行动过程。 领导者的权利1、法定权——来自领导者的职位、头衔、资历以及传统因素的影响。2、惩罚权（强制权）——来自下属对可能受到惩处的畏惧感。3、奖励权——来自领导者对下属物质、精神上的奖励和诱惑。以上三种又称为：领导者的职位权力。这种权利对领导者来讲，时间和范围都有一定的局限性。 4、专长权（专家权）——来自领导者丰富的知识以及管理技能（技术、人际关系、概念技能）。5、模范权（个人影响权）——来自领导者良好的品德特征和模范行动。以上两种权力属于个人权利（又称非权力性影响力）。对于领导者来说，职位权利和个人权力都是不可缺少的，但后者在领导影响力方面更是长期与持久的因素，对领导行为效果能产生重大影响。项目经理没有职能经理那样的职务权力，只能是依靠后者 不同的领导依靠不同的途径建立自己的权威？‡职能经理——行政权：‡政策颁布权（职务权力）‡薪酬决定权（职务权力）‡岗位调配权（职务权力）‡职责界定权（职务权力）‡项目经理——个人影响权‡资历、人品、感情、知识‡非职务权力 职能经理与项目经理的区别？职能经理偏重于管理项目经理偏重于协调管理和协调的比较管理偏重强调：制定目标，明确责任，优化配置，提高效率，选择策略，有序一致，制度规范，应对“目标”管理更多的是计划和组织（管理职能）协调偏重强调：引导目标，冒险前进，高举大旗，创造氛围，激发情感，保持沟通，维护团结，应对“变化”协调更多的是领导与控制（管理职能） 回顾一下IPMP对项目经理的能力考核要求‡基本能力：管理，项目和项目管理，项目背景和利益相关者，系统方法和项目管理，项目管理实施，项目目标，项目成功与失败的准则，项目阶段，项目生命期，标准与指南‡方法能力：项目结构，过程和时间管理，资源管理，成本管理，财务管理，实施测量和项目进展，项目控制，多项目管理，创新技术，解决问题 回顾一下IPMP对项目经理的能力考核要求‡个人素质：沟通能力；首创精神，务实，热情，激励能力；联系的能力，开放性；灵敏，自我控制，价值鉴赏能力，乐意负责任，人格诚实；解决冲突，辩论文化，公正；解决问题能力，全面思考，公正；忠诚，坚强，乐于助人；领导艺术‡社会能力：洞察力，激励，社会化结构，小组和团队，学习型组织，自我管理，领导艺术，冲突管理，特殊交流状况‡总体印象：常理（常识），逻辑和系统，语言／文字表达能力，综合能力，明晰，技能，知识水平，经历（阅历） 项目经理的能力考查9环境：项目小组9角色：项目经理（招集人）9任务：带领项目团队完成一个具体的项目目标，如：通过讨论和分析，提交一份报告9考察内容：9一般能力：观察力、注意力、记忆力、思维力、判断力、表达力9综合能力：9成果体现：团队意见的表达与组织的正确性、逻辑性、系统性、概括性、结构性9过程体现：团队每个人充分、围绕主题、自由而不受干扰的表达、集中、形成统一意见的过程9氛围营造：善意沟通、友好表达、平等交流9判断方法：负面判断（出现负面事件） 管理心理学的五维度人格模型五维人格因素：‡外向性：测量个体对关系的舒适感程度，外向善于社交和能够做出正确的自我判断，内向倾向封闭、胆小和害羞‡随和性：测量个体服从他人的倾向性，高随和是合作的、热情的和信赖他人的，低随和是冷淡、敌对和不受欢迎的‡责任心：是对信誉的测量，高度责任心的是负责、有条不紊、值得信赖和持之以恒，相反是精力分散、缺乏规划‡情绪稳定性：是个体承受压力的能力，稳定者是平和、自信、安全的，消极的是紧张、焦虑、失望和缺乏安全感的‡经验的开放性：测量个体对新奇的兴趣和热衷程度，开放的人富有创造性、好奇、富有艺术敏感性，另一面则是保守、满足 五维度人格模型与职业要求五维度人格模型的明显倾向性：‡积极、开放、乐观、责任、稳定‡测试：9在你安排别人工作任务的时候，是明确的告诉他你的目的和要求，还是让他去“揣摩”？9当你做出的承诺无法兑现时，你最好告诉他真实的原因，还是讲一套看似正确的大道理？9你是否相信大多数人本质是善良随和的。还是说你如果完全相信别人，那就会经常是自己陷入困境之中？9如果可能有一条你不熟悉的近路，你会尝试去走吗？9在夜深人静的红灯路口，你会停下来，还是穿过去？ 管理的胜任力‡行为胜任力在不确定和风险条件下主动性和承担责任的能力。‡知觉胜任力收集和组织信息，把握不同组织、部门前景的能力。‡情感胜任力理解他人，解决组织成员之间冲突的能力，包括影响和领导他人，与他人一起工作，帮助和授权等。‡思维胜任力组织系统管理的能力，包括计划、尝试新想法、创造新途径，研究替代方案等。 管理胜任力评价结构1.品格特征：诚信、价值观、承诺2.个性特征：“大五”3.动机特征：成就动机、权力动机、关系动机4.管理技能：战略决策、关系协调、授权任用、控制、开拓创新5.管理绩效：过往的实效 项目经理挑选标准‡人际领导技能‡口头及书面沟通能力‡全局观念‡政治敏感性‡乐观精神‡敢作敢为‡不断进取的精神‡统筹规划的能力‡责任心和可靠性 项目经理的条件•（1）管理能力：具有项目的计划、指导、控制和评估项目实施各项活动的能力。•（2）协调能力：具有协调与项目有关的公司内部各部门的工作能力。•（3）判断能力：对项目实施过程中出现的问题能准确的做出判断，并能提出解决办法。•（4）控制能力：对项目实施过程中潜在的问题能及时预测，并能提出预防措施。•（5）沟通能力：善于信息交流和沟通，能处理好各种不同层次的人际关系。•（6）业务能力：项目经理应熟悉项目管理业务，对与项目实施有关的任务有一定程度的了解，尤其是对项目实施各阶段之间的衔接和联系应作到心中有数。 素质要求15秒沟通的例子：条件：与公司CEO在电梯中碰面，从一层到CEO离开电梯，只有15秒时间目的：在正规渠道已经没有可能的情况下，希望获得老板的资源支持思路：（1）你现在面临最大的问题是什么？（2）为解决问题，15秒达到的目的是什么？（3）为达到你目的，方法是什么？没有标准答案，考察的是考虑问题和解决问题的思维过程 项目经理的责任系质统量组人成时织员本间大三角：小三角：通过一系列的领导及管理控制项目的实施在预活动，使项目的目标成功定的质量、成本和时实现，并使项目干系人都间范围内获得满意 项目经理的责任对于所属组织的责任‡保证项目的目标符合于组织目标‡充分利用和保管组织分配给项目的资源‡及时与组织高层就项目进展进行沟通 项目经理的责任对于所管项目的责任9明确项目目标及约束9制定项目的各种活动计划9确定适合于项目的组织机构9招募项目组成员，建设项目团队9获取项目所需资源9领导项目团队执行项目计划9跟踪项目进展及时对项目进行控制9处理与项目相关者的各种关系9项目考评与项目报告 项目经理的任务‡（1）密切保持与用户和本组织上层领导的联系，及时沟通项目合同执行中的重要信息。‡（2）熟悉合同，了解本组织和用户的意图和情况，制定项目计划和项目协调程序，确定项目实施的基本工作方法和程序，经用户和公司批准后执行。‡（3）代表开发商，参加与用户的协调会议。‡（4）根据项目任务范围，确定项目实施组织，落实项目团队的成员，评价项目团队主要人员能否胜任项目工作。‡（5）提出项目的工作分解结构（WBS）和组织分解结构（OBS），并确定其编码系统。‡（6）组织项目内部会议，制定项目的工作任务、范围以及工程进度/费用控制计划。‡（7）协调项目实施过程中的工作关系，包括对外与用户及其他协作单位之间的关系，对内与各有关专业职能部、室的关系。‡（8）委派专人负责文件管理，以保证项目函电、会议纪要、备忘录、图纸资料及时处理，并保证工程档案的完整性。‡（9）审核项目的质量计划、财务计划、设计计划、采购计划、施工计划。‡（10）审查项目的进度计划、费用估算和预算。 项目经理的任务‡（11）从合同目标的角度，审查设计方案。‡（12）审查关键设备和特殊材料的采购活动。‡（13）审查和分析项目进展报告，预测项目实施中可能出现的问题，并提出预防措施及解决办法。重大问题应及时向公司领导和管理部门报告。‡（14）及时处理项目变更和用户变更，同时协调可能涉及的每一个有关方面，必要时做出相应的修改和安排。‡（15）与项目质量经理共同监督保证工程质量，参加质量问题的研究和处理。‡（16）出现有违约事件时，及时参加谈判和参与问题的处理。对于超出合同条款规定的问题的处理，都要经过协商谈判，并写出会议纪要。‡（17）组织编制项目验收申请报告，向用户提出验收申请，协调用户验收，并取得用户对项目验收的正式文件。‡（18）督促检查项目资料的整理入库工作。‡（19）负责审查项目结算，处理与用户及分包单位的遗留问题。‡（20）组织项目的工作总结和回访工作 项目经理的责任——项目经理负一切责任吗？‡9个知识领域中项目经理的职责‡项目经理并不承担所有责任‡范围管理：控制‡时间管理：控制‡成本管理：控制‡质量管理：对项目的质量负责，具体员工负具体责任。‡人力资源管理：综合者——沟通者、领导者、决策者、气氛制造者‡沟通管理：中心作用——主持协调、仲裁、控制沟通‡风险管理：发起人承担项目风险、总经理对最终风险负责、项目经理对项目风险负责。‡采购管理：项目经理对采购需求负责、项目工程师对项目规范负责、采购部门对采购文件负责，而不是对项目经理负责。‡综合管理：控制计划编制、绩效监控和问题解决——管理综合集成 问题讨论：我算什么项目经理？¾怎样才算是真正意义上的项目经理？¾明确的目标——怎么考核项目？（合同、验收标准、进度、成本、质量、等等）¾明确的责任——怎么考核我？（用户签字验收、内部进度、成本、质量指标、等等）¾我的权力——我靠什么完成？（项目组内的工作安排权、费用支配权、方案决策权、人员激励权、等等）¾我的利益——完成与完不成有什么说法？（奖励与惩罚）¾我的风险是什么——不确定因素有多大！¾我是这样的吗？下一部分：过程控制¾如何规范？我能对合同签订说“NO”吗？¾如何度量？计划能定的那么准确吗？¾如何实施？用户不配合是我的责任吗？¾全部跟组织的项目管理机制有关 谢谢！Keep Connecting In The Future 第二章项目范围管理 第二章目录什么是项目范围管理项目启动与项目选择范围计划编制和范围说明书范围定义与工作分解结构范围审核和范围变更控制 第二部分：项目的过程管理‡目标已经制定、责任已经下达，项目已经交给你了。但是还有那么多不确定的因素，怎么办？死透了吗？‡项目经理的工作特点，就是在充满了不确定因素的条件下，完成项目目标。‡站在项目经理的岗位上，考虑一下：‡如何为项目确定范围并守住它？‡如何为项目订一个切实可行的计划？‡如何编制并控制项目的预算？‡项目的质量是什么并如何度量它？‡怎样管理项目的风险，给自己买一个保险？‡第二部分，我们来讨论这几个问题 我们现在所处的位置? 什么是项目范围管理‡范围‡产生项目产品所包括的所有工作及产生这些产品所用的过程——产品、过程‡产品范围界定--包含在产品或服务中的产品功能和特征。‡工作范围界定--为交付一个有特定的功能和特征的产品所完成的项目工作。‡范围管理‡对项目包括什么和不包括什么的定义与控制过程‡意义：‡这个过程用于确保项目组和项目干系人，对作为项目结果的项目产品以及生产这些产品所用到的过程，有一个共同的理解。‡范围管理是项目经理最核心的管理 项目范围管理过程•项目启动—审批和启动项目，确立项目章程，明确项目的目标和范围。•范围计划--写出一份书面报告，作为未来项目决策基础。•范围定义--把主要的项目工作细目分解成更小、更易管理操作的单元。•范围核实—项目干系人正式认可项目范围。•范围控制--对项目范围的变更进行控制。 项目启动：战略计划与项目选择•项目的启动阶段，从项目管理角度看，是正式认可一个新项目的存在，确认项目目标、范围，明确项目团队任务、责任，并承诺给予资源的过程。•项目启动阶段的开始，视具体项目而定，没有一个特别的标志。–在一些组织中，一个项目的正式启动，是在必要的调研、初步的计划，或很多应该划分在项目启动工作完成后才进行的。–有些项目形式，如特殊的内部服务项目和新产品开发项目，它们的启动不是很正规，要受到所做的工作数量的制约，目的是为项目正式启动时，职员能牢固地掌握这些工作方法。–有些项目的启动，往往是仅仅得到一些市场信息，相应的工作就开始了 项目提出的动因•项目通常是由于以下的需要而被提出的：•市场需求（比如：一家电信行业软件公司针对电信运营商的发展需要，决定开发CRM软件。这是基于电信运营商面对日益激烈的用户市场竞争，对CRM的需求，而开展的项目，是企业对长期的市场发展战略作出的反应）。•产品需求（比如：同上的公司，在已经推出电信本地网资源管理系统后，为了扩大市场和技术优势，开始开发长途网的资源管理系统，以增强它们的产品线）。•客户需求（比如：同上的公司，在电信本地网产品中，增加对通用GIS（地理信息系统）的支持。因为这是为了满足用户对多GIS平台支持的要求）。 项目提出的动因·技术进步（比如：同上的公司，在资源系统中，选择通用的GIS平台，代替过去自己开发的地理信息库的方式，这是因为通用平台技术在开发、维护、移植和功能升级等各方面，具有明显的优势）。·法律要求（比如：同上的公司，在采用电子地图方面，已经不再采用自行数据录入的方式，而是购买正式的电子地图。因为考虑尊重相关的知识产权的法律问题）。这些动因也可能被称为是问题、机遇或商家的要求。无论叫什么，其核心的问题是管理部门通常要做出怎样对应的决策出来。 项目选择分析技术‡利润测量方法--比较研究法、评分模型、利润贡献或经济模型。‡制约最优化方法--数学模型、用线性的、非线性的、动态的、完整的及混合目标项目规则系统。‡这些方法通常被作为决策模型。‡决策模型既包括常规技术（决策树、核心选择和其他），也包括特殊技术（历史进程分析、逻辑结构分析及其他）。‡在一个成熟模型中，对项目选择标准的应用通常被作为一个分离独立的阶段。‡专家评审：专家评审通常是要对这个项目的投入进行评估。象这种专家评价，可以通过一个组织或拥有特殊知识和受了专门培训的个人来进行，可以通过许多途径获得。包括：‡这个执行组织中的其他部门‡顾问‡专家和技术委员会 启动阶段的输出——批准项目立项报告（项目章程）•1．立项报告（项目章程）：项目的立项报告是正式认可项目存在的一个文件。它对其他文件既有直接作用，也有参考作用。项目章程应描述：9既定的商业目标9产品描述说明9项目经理的责权利项目的立项报告应该通过管理者对项目及项目所需的条件进行客观的分析后颁发它提供给项目经理运用、组织项目资源，进行项目活动的权力。参考：项目任务责任书 项目启动阶段的输出•2．指定/委派的项目经理。通常，项目经理应该尽可能在项目的早期进行指定和委派是比较合适的。项目经理应该在项目计划实施开始之前被委派，更应该在许多项目规划完成之前就委派好。•3．制约因素。制约因素是限制项目管理团队进行运作的要素。例如：事先确定预算是制约项目团队的操作范围、职员调配和进步计划的一个很重要的因素。当一个项目按照合同执行时，合同条款通常是受合同制约的。•4．假设因素。为了规划目标的准确性，考虑到的假设因素必须具有科学性、真实性和确定性。例如：如果关键人物的到场日期不能落实，那么项目团队就应该设置一个具体的开始时间。假设通常包含有一定程序的风险。在此它们可能被确认或它们可能是一个风险界定的输出。 项目启动阶段的意义•项目生命周期的第一个阶段•启动阶段的结束标志着：–选择并最后决定项目成立/或终止–指定项目经理–产生项目章程（授权）•启动阶段工作的实际意义 范围计划编制和范围说明书•范围计划编制是创立书面文件，阐述项目范围为未来项目提供基础条件的过程，特别是包括了用以确定项目或阶段是否成功完成的标准。•范围说明书的基础是通过确认项目目标和主要项目的子项目，使项目团队与项目客户之间达成一个协议。•如果范围界定的所有要素已经具备（如：主要项目的子项目能够反映项目目标，项目立项报告能证明项目目标），那么，这个过程就仅剩实质性的制定书面文件的工作了。 范围说明书•是一份描述项目输出或可交付成果的文件•是对项目或项目阶段是否成功完成做出决策的依据•是项目和项目干系人对项目范围达成共识的基础•范围说明书至少应包括：–项目论证：项目绩效评估的依据–项目产品：产品描述–可交付成果：各层次交付成果的定义–项目目标：项目绩效度量的定量指标，包括：成本、进度、质量、风险等。 项目范围说明书123456A项目论证项目背市场机客户价风险经济效可行景遇值益分析性分析B产品描述主要功主要性主要质其他能描述能特征量标准C交付成果直接交文档实施过培训与其他定义付物程服务D项目目标进度目成本目质量目其他标标标E风险因素资源需限制与求保证假设 范围定义与工作分解结构‡范围定义范围定义包括分解这个主要工作细目的子项目（象在范围阐述中界定的那样），使它变成更小、更易管理和操作。‡目的是为了：‡提高估算成本、时间和资源的准确性‡为绩效测量和控制确定一个基准线‡使工作变得更易操作的，责任分工更加明确‡正确的范围定义是项目成功的关键。当它是一个很差劲的范围界定时，由于不可避免的变化会使最终项目成本可能会很高，因为这些不可避免的变化会破坏项目节奏，导致重复工作、增加项目运行的时间、降低生产功效和工作人员的士气。 范围定义的输入1、范围说明。2、制约因素。当一个项目按照合同执行时，由合同条款定义的制约因素，在范围定义中通常是重要的考虑因素。3、假设条件。4、其他计划输出。考虑到可能对当前项目范围界定的影响，应该对其他计划的输出进行回顾。5、历史资料。在项目范围界定期间，应该考虑以前项目计划的有关历史资料。 范围定义的工具和方法•1. 工作分析结构样板：一个工作分析结构,从以前的项目到新项目都能用，虽然每个项目是唯一的，但是，WBS经常能被"重复使用"，多数项目间在某种程序上是具有相似性的。 项目管理的重要工具——工作分解结构（WBS）2、WBS‡WBS(WorkBreakdown Structure)主要是将一个项目分解成易于管理的几个部分或几个细目，以便确保找出完成项目工作范围所需的所有工作要素。‡它是一种在项目全范围内分解和定义各层次工作包的方法，WBS按照项目发展的规律，依据一定的原则和规定，进行系统化的、相互关联和协调的层次分解。‡结构层次越往下层则项目组成部分的定义越详细，WBS最后构成一份层次清晰，可以具体作为组织项目实施的工作依据。‡WBS通常是一种面向“成果”的“树”，其最底层是细化后的“可交付成果的任务分配单”，该树型组织确定了项目的整个范围。‡但WBS的形式并不限于“树”状，还有多种形式。 项目任务分解结构SBW‡在项目管理过程中，项目计划和控制是非常重要的一个环节，良好的项目计划能同时对项目进度、质量和投资起到很好的控制作用，失败的项目计划则有可能带来混乱、失控甚至项目的最终失败。‡在项目计划的过程中，人们往往会求助于WBS方法进行项目工作任务的分解。在此基础之上再进行时间资源的估算、进度估计，最后形成项目的成本。‡WBS随着项目规模的差异所起的作用不尽相同。小的项目只需要很简单的WBS结构，结构的划分基本上是一目了然的，获得的结果容易得到认可。项目规模越大，WBS也越重要，从另外一个角度来讲也越难做好。对大型项目而言，确定项目的WBS结构往往不可一蹴而就，需要经过多次反馈和迭代、修正，最后才能得到一个项目各方都能接受的WBS结构。 项目任务分解结构的SBW作用9认知层次站在认知的层次，WBS所起的作用是一目了然的。对项目的认知是协同和控制的基础，如果项目各方对项目本身没有一个清晰的、无歧义的认知话，项目的成功几乎是不可想象的。WBS的层次结构为我们认识、把握复杂项目的逻辑关系提供了良好的工具。9WBS是以下过程的输入：项目计划：WBS是范围、成本、进度和风险计划的基础；状态报告：WBS提供组织对项目的成本、进度状态进行监督的依据；变更管理：WBS可以使项目经理在合适的控制点，度量、评审、控制变更的发生，评估影响，做出变更控制的决定。 项目任务分解结构的SBW作用9协同环境层次在共同认知的基础上，项目的成功还有赖于良好的协同环境。一个复杂的项目往往有许多参与者，项目的顺利进展有赖于这些不同角色的协同工作。由于这些参与者在项目过程中从事不同的工作，需要不同的信息。比如，复杂的项目会遵循先自上而下、后自下而上的计划制定过程。两种计划的粒度和范围都是不一样的，但二者需要有机地结合起来形成统一的计划，WBS结构为这些信息提供了一个结构框架。与邮政系统中的邮政编码类似，WBS结构可以成为进度、资源等信息的标签，使不同层次的信息就可以在预先规定的线路中漫游。 项目任务分解结构的SBW作用9控制层次认知和协同环境并不必然意味着项目的自动成功。项目管理者还必须对项目的进度、范围和资源进行有效的控制。为了进行有效的控制，必须对项目中的工作任务进行范围界定。清楚的范围界定能有效防止出现纠纷时合同双方牵扯不清，同时还有助于用户对项目组进行数量最少但最有效的控制。WBS不但说明项目组应该做什么，还应该能说明，那些事情并不是项目组的工作。实际上，这个问题常常被忽略，项目组做了很多并不属于自己、自己也做不好的事情。这个问题，并不能用“一切以用户满意为”理由。 的SBW总体结构9WBS结构的总体设计对于一个有效的工作系统来说是个关键。结构应以等级状（层次结构）或树状（组织结构）来构成，使底层代表详细的任务信息，而且其范围很大，逐层向上。即WBS结构底层是管理项目所需的最低层次的信息，在这一层次上，能够满足用户、团队成员对的工作交流或监控需要。9从这棵“树”的根开始，结构上的第二个层次将比第一层要宽，而且提供信息的对象层次，也应比上一层的层次要低，以后依此类推，直到具体的任务细节。9结构设计的原则是必须有效和分等级，但不必在结构内，建立太多的层次，因为层次太多了不易有效管理。对一个大项目来说，4到6个层次就足够了。9在设计结构的每一层中，必须考虑信息如何向上/下流入相邻层。原则是从一个层次到另一个层次的转移应当以自然状态发生。此外，还应考虑到使结构具有能够增加的灵活性，并从一开始就注意使结构被译成编码时对于用户来说是易于理解的。 的SBW层次结构WBS的分解操作：‡确认项目的主要要素‡通常，项目的主要要素是根据这个项目的工作内容和项目管理方式决定的。‡例如：项目生命周期的阶段可以当作第一层次的划分，把第一层次中的项目细目在第二阶段继续进行划分。‡决定是否能对开发到这种详细层次的每个要素进行充分的成本和期限估算。‡如果项目工作的要求，要在很久的将来才能知晓的话，那么这种分解也就没了确定性。‡对于一个软件项目，划分项目的WBS结构有许多方法，如：‡按专业划分‡在专业下按阶段划分‡在阶段内按子系统划分‡以上每一种方法都有其优缺点。一般情况下，确定项目的WBS结构需要组合以上几种方法进行，在WBS的不同层次使用不同的方法。 BWS的“粒度”•BWS是一棵基于可交付成果的树–根：项目的交付成果–节点：部门/小组的可交付成果，也称为：工作包–叶：具体任务人的可交付成果，是任务分配、描述、检查的最小任务单元。•那么，这个最小任务单元“小”到什么程度？即所谓WBS的“粒度”问题–（1）识别项目的主要产品、主要阶段–（2）细分的原则9考虑分解对象9考虑使用者9考虑编制者 WBS工作分解的原则•功能或技术的原则：考虑到每一阶段到底需要什么样的技术或专家•组织结构原则：考虑项目的分解应适应组织管理的需要•地理位置原则：主要是考虑实施处于不同地区的子项目•系统或子系统原则：根据项目在某些方面的特点或差异将项目分为几个不同的子项目. 最小任务单元的选择9它们是一个工作产品；9它们只代表自己，没有下属的单元；9它们是没有必要再细分的工作；9它们能比较直观地看出，是通过什么方式实现或获得的，如：外购、设计等；9它们需要达到的目的能直观地被用户、项目组和任务执行者所理解。我们用反问的方法，再来审查我们已经分解到最底层的任务：9由最底层的任务单元来计算和控制成本和进度的精度是否足够？9完成任务单元的责任人能力是否足够，任务是否过重或任务不饱满？9这些任务单元是否还有理由继续再细分下去？9是否有必要更详细地了解内部的过程和产品？9这些工作单元是否具有充分的独立性？9在任务单元内部，是否在时间、资源等方面受其他单元的牵制？9对任务单元的评价、度量尺度是否清楚？9用户、项目组和任务责任个人是否能清楚、完整地理解这些任务？ BWS工作编码方法•由高层向下层用多位码编排，要求每项工作有唯一的编码–1000•1100–1110»1111»1112»1113–1120»1121»1122»1123•1200•WBS编码也称为：帐目编码•是用于唯一确定项目工作分解结构每一个工作单元的编码系统，成本和资源被分配到这一编码结构中 SBW的编码原则不论编码采用什么形式，编码应具备以下基本原则：（1）编码应能反映出任务单元在整个项目中的层次和位置，例如：和显然是在不同层的不同位置。（2）当发生任务增加和删减时，整体的层次结构不会发生巨大变化，只是在恰当的位置，进行增删。（3）编码方便进行任务的索引。（4）编码方便与其他过程管理的相互参照。 SBW工作编码的意义9对WBS的任务进行编码，WBS就不仅是一个任务表示方式，它还可以充当一个共同的信息交换语言，为项目的所有信息建立一个共同的定义。例如：它是计划、成本、风险、监督和评审、考核等过程的基本信息来源和依据。9通过任务编码，我们就能够把项目的所有要素在一个共同的基础（WBS）上建立关联，在此基础上建立各管理过程的所有信息沟通。9应用WBS作为项目信息的共同基础的最大优点是，为监控及预测费用、进度、实施等不同过程，建立了一个统一的项目信息系统，WBS给所有阶段、过程的项目管理人员提供了一个均可以与之作对比的一致基准，并且在大型项目中，由于参加者众多及人员可能发生的变化，使所用的项目概念、阶段、任务对所有的参加者都具有相同意义是很重要的，而WBS通过编码和编码字典（对具体节点、叶任务的描述）的编制可使这一点得到保证。 WBS分解类型•基于工作过程的划分–上层按照工作的流程分解–下层按照工作的内容划分 项目工作分解结构表项目名称：项目负责人：单位名称：制表日期：工作分解结构任务编码任务名称主要活动描述负责人1000110012001x001x10 1x111x12项目负责人审核意见：签名：日期： 范围定义的输出1．工作分解结构WBS采用WBS帮助界定项目的工作范围，是一个很好的办法。通过WBS分解过程，能比较容易地发现，当一个工作不在WBS系统内时，那么，这就是项目范围以外的工作。作为范围说明，WBS通常是项目团队与用户就项目目标和范围达成并维护共识的重要手段和依据。项目的划分每降低一个层次，就要增加一个更详细的项目要素的详细描述。2. 范围说明更新范围定义并不只在项目开始的时候进行，因此，在项目的每个检查点上，都可能需要进行范围检查，或产生范围变更，导致范围说明的更新。 范围确认与范围变更控制•范围确认是通过参与者（倡议者、委托人和顾客等）的行为，正式确定项目范围的过程。它要求检查项目工作和项目成果，以保证所有项目都能准确地、满意地完成。•如果这个项目已提前终止，这个范围确认过程也应该证实并应以书面文件的形式把它的完成情况记录下来。•范围确认与质量控制是不同的，范围确认关注的是有关工作结果的验收标准，而质量控制关注的是有关工作结果正确性、即是否达到了验收标准的问题。 范围确认的方法和结果•方法——检验。检验包括用象测量、测验和考试等这样一系列活动去判断承担的工作任务是否符合计划的要求。检验有各种称呼：评价、产品评价、审查和巡视等；在应用领域，这些不同的词有它自己的使用范围和特定的含义。•结果——正式验收。验收文件是当事人或投资者已经认可了这个项目产品或某个阶段的文件，他们必须为完成这项工作准备条件，做出努力。象这种验收可能是有条件的，尤其是在一个阶段末的时候。 项目范围变更控制过程•范围变更控制系统：范围变更控制系统是一系列正式的、文档化的程序，这些程序定义了对项目绩效进行监控和评价的过程。范围变更控制系统包括正式项目文档变更的步骤，还包括文档系统、跟踪系统、过程和必要的变更批准层次。•项目范围管理的变更控制的具体内容，我们在项目整体管理一章中介绍•作为项目范围管理的补充，我们在下一章，介绍软件项目的需求管理，包括：需求开发、实现与控制 互动交流•在系统集成项目中，与用户界定甲乙双方的工作范围边界，主要有哪些内容？•在系统集成项目中，最难界定的工作范围是什么？怎么改进？•在系统集成项目中，最难保持的工作范围是什么？怎么改进？•如何才能向用户大声的说“不”？ 本章小结与学习要点•什么是项目的范围：产品、过程•什么是项目的范围管理——定义、控制•范围管理的过程——项目启动、范围计划编制、范围定义、范围确认、范围变更控制•项目章程：是一个正式承认项目存在的文件，必须经项目干系人签字一致同意，在启动结束时建立。•项目章程的意义：目标范围、项目经理授权•范围说明书的内容包括……•WBS结构的内容、意义•范围确认是指干系人对范围的正式承认•范围变更控制系统 PMP考试要点•项目启动与项目章程•范围计划编制与范围说明书•工作分解结构与范围定义•范围确认•范围变更控制 谢谢！Keep Connecting In The Future 第二部分项目过程管理软件项目的启动问题的定义可行性研究项目论证案例分析 问题定义的意义比如：客人要求按1000元标准配一桌酒席怎么做到客人吃得满意的同时，还能满足酒店的利润要求，厨房也能在规定的时间里做得出来？问题定义就是厨师长一口报出行，还是不行，不可能先做一遍试一下而需求分析是对具体细节，进行讨论：龙虾是一吃还是三吃，三吃是生、炸、炒……既要懂客人的需求，也知道材料的成本和后厨的能力核心关键：对问题域的认知程度对技术和方法的把握程度理解，什么是系统分析师? 问题定义阶段的目标问题定义阶段的工作目标是：1、理解根本问题——问题背后的问题2、确定涉众和用户3、定义解决方案系统的边界4、确定问题解决方案的约束条件5、在根本问题的定义与理解上与用户达成共识 1、什么是根本问题找到建设系统的根本驱动：要素描述问题描述希望新系统要解决什么问题什么是计算机系统解决的问题，什么是要依靠人自己解决的问题（流程问题、权限职责问题、责任心问题等）影响确定受问题影响的涉众谁是决策者、谁是使用者谁发布命令、谁发布牢骚结果确定解决方案对涉众的影响结果决策者的期望目标、使用者的实际效果评价和检验的目标、方法和依据驱动理解：系统建设的真正动力是什么当发生需求变更的时候，什么是最重要的什么是可以放缓的、什么是不需要的 找出问题背后的问题：找出问题的根本原因：鱼刺图方法： 找出问题背后的问题：找出问题的根本原因：帕累托图方法：20/08定律 2、理解涉众和用户„“用户”（user）是一种泛称，它可细分为„“客户”（customer）„“最终用户”（the end user）„“间接用户”（或称为关系人）。„掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。„某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：„如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。 2、理解涉众和用户„间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。„财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。„市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。 系统从外部哪里得到信息3、定义系统边界：系统如何与外部进行交互系统将做出什么处理那些问题将属于系统处理那些问题将交给其他系统系统由谁操作和维护银行AMT机银行储蓄处理系统业务处理系统银行客户系统边界系统维护员ATM操作员我们的解决方案 4、限制和约束条件：约束是对提供解决方案的我们所拥有的自由度的限制潜在的系统约束可能包括：经济的：财务预算、成本控制、产品价格因素等组织的：内部结构、跨部门协调等技术的：技术选择的限制、技术和平台制约、技术可行性等系统的：集成还是从头开始、与平台的兼容性、采用组件的考虑等环境的：开发环境限制、管理和规范约束、安全和保密要求等进度和资源的：进度要求、资源限制、投入和资源再利用等假设：因为……..，所以，我们假定，在.…….情况下，我们的选择是：为成功建立信心、为失败找好理由！ 5、与用户就根本问题达成共识 问题定义阶段的具体任务¾1、决定是否需要建立一个系统¾2、理解最终的软件系统应该解决那些问题¾3、引出这些问题和系统的相关问题¾4、提供一个与这些问题和系统特征有关的基础¾5、决定系统应该做什么¾6、决定系统不应该做什么¾7、确定系统将能够满足用户的需求和验收标准¾8、为系统开发提供一个基础 问题定义与需求分析的不同：¾在项目的启动阶段，完成问题定义和可行性研究——回答是否建设一个系统¾在计划和实施阶段，完成需求分析——决定建设一个怎样的系统¾传统软件工程问题定义和需求分析过程：¾1、问题定义问题定义过程¾2、可行性研究¾3、系统分析¾4、组织结构与功能分析¾5、业务流程分析¾6、数据与数据流分析¾7、数据字典需求分析过程¾8、功能/数据分析¾9、系统功能划分¾10、数据资源分布¾11、新系统逻辑方案的建立 问题定义阶段的工作问题定义需求分析回忆一下瀑布模型总体设计„传统的生命周期模型与需求有关的二个主要阶段：详细设计„问题定义（系统需求）„需求分析（软件需求）编程调试项目管理过程的启动、计划、实施阶段，对需求的分析的目的和要求各不相同运行维护启动阶段——明确项目目标、进行项目选择计划阶段——继续分析系统，并根据对系统的分解（WBS），确定项目进度计划、成本和质量目标实施阶段——细化系统分析，为系统设计建立基础 （1）系统任务的提出一、根本问题•“要解决的问题是什么？”二、主要结果•提出关于问题的性质、工程目标和规模的书面报告。三、内容及步骤(一)系统任务的提出1. 系统任务的提出者(1)用户提出：一般而言，系统开发的任务由使用者提出，如企业（或组织）的领导和有关的管理人员。(2)课题项目：系统开发人员本身也可以提出系统开发任务。(3)上级领导布置(4)合作开发 2. 系统任务的提出形式1()书面形式：系统任务的提出一般以书面形式，如系统开发任务书或系统开发协议书等形式。2()口头形式3. 系统任务提出的目的„由于绝大多数使用者不可能对以计算机为基础的系统功能全然清楚，对系统任务的要求不可能讲得确切。因此使用者提出的系统任务，仅提供编写系统目标的素材。如果不加分析与加工地当作系统目标，将使系统开发工作盲目，无明确目标。 （2）初步调查(二)初步调查1. 初步调查的目的„初步调查的目的是为了合理地确定系统目标、系统总体分析及系统的可行性分析。„为了这些要求与目的，在初步调查过程中应收集并整理与整个系统有关的资料、及存在问题。2. 初步调查的主要内容„初步调查的内容是调查一个企业（或组织）的总貌、以及其对信息的总需求。 （2）初步调查„主要内容包括：(1)整个企业（或组织）的概况„规模、组织目标、组织机构，产、供、销的概貌，人员、设备与资金的现状，以及目前的管理水平，特别是管理的基础工作的水平。(2)现行系统的概况„功能、人员、技术水平以及管理体制（归属哪一级领导）等。(3)组织对外部的关系„和哪些外部单位（外部实体）之间有哪些物资、资金或信息的来往关系。(4)本组织的领导者、管理部门对系统的态度，支持的程度（包括人力、资料与数据），对新、老信息系统的看法以及对信息的需求。(5)开发系统的资源、人力、资金以及开发周期等资源情况。 需求调查的一般过程如表所示获取用户（客户与最终用户）的需求信息，经过分析后产生相目的应报告。角色与职责系统分析员调查、分析用户的需求，客户与最终用户提供必要的需求信息。启动准则系统分析员已经确定输入任何与用户需求相关的材料主要步骤第一步：准备调查第二步：调查与记录第三步：分析需求信息第四步：撰写报告第五步：需求确认输出报告结束准则系统分析员已经撰写完成《用户需求说明书》，确保无人为错误。度量系统分析员统计工作量和上述文档的规模，汇报给项目经理。 （3）系统目标的确定(三)系统目标的确定1. 系统目标的含义„系统目标是系统最终要达到的目标，是系统开发的宗旨，各个阶段的工作都要以这个宗旨为中心。„如：有了明确的系统目标，然后进行系统的可行性，从而有针对性的作进一步的详细调查。2. 如何确定系统的目标„系统开发人员通过初步的调查，了解企业领导以及主要的管理干部对系统的要求与设想，根据目前组织具备的条件及资源，初步提出系统的目标。„系统目标必须明确提出所开发系统是“干什么”的，它与人工系统之间的界限，哪些信息处理由计算机完成，哪些仍旧由人工完成。„对于一个较大的系统，除了系统目标之外，还应提出各子系统的子目标。 （3）系统目标的确定——案例例1：某大学校园网总体目标„目标：某大学校园网的目标是要建成一个国际一流先进水平的校园网络。„意义：某大学校园网的建设将极大地促进本地和遍布全世界的互联网络之间的信息交流，并让全世界更好的了解该校有关信息，从而使该校进一步地走向世界。„要求：某大学作为我国在**方面的重点大学，建立自己的网络系统，进一步与国际接轨，提高对大学各方面现代化管理的科技含量，促进信息技术的交流和信息资源的有效利用，降低国际交往中长距离、大信息量的通讯成本，提高效率、优化学校管理水平。这样的系统目标可以实现吗？ （3）系统目标的确定——案例例2：某销售公司的系统目标„一般描述：某销售公司的系统目标是实现公司各个销售环节的计算机管理，协调公司三大部门（销售部、财务部、储运部）的工作，极大地提高公司内部的工作效率，使公司的经济效益显著提高。„系统目标：从管理的层次结构来看，信息系统能为公司三个层次的人员服务。„一是为日常事务处理层服务，方便这类人员的日常工作，具体包括营业代表填写供货单，财务人员开发票、发货单、帐款回收，仓库人员配货等；„二是为中层管理者（如各部门经理）服务，便于他们通过系统获得的信息，指导、督促和管理所在部门的日常工作。„三是为高层决策者（如总经理）服务，为他们的宏观决策提供科学的依据。如预测产品的销量，确定合理的订货数量，使库存最优；分析影响产品销量的相关因素，确定最佳的产品价格，制定最优销售方案等。这样的描述是否更明确一些？ （3）系统目标的确定——案例例3：某企业信息系统的系统目标„一般描述：为了实现企业管理现代化的要求，建立一个生产、经营、资金、成本与物资的动态数据收集、处理与控制的信息系统。„系统目标：(1)信息系统为不同层次的管理人员提供日、周、旬、月、季、年的各种单项及综合的报表和计划，并能实现对当前的生产、经营、物资、资金以及项目进度等现状与动态趋势，进行多功能查询、统计和趋势分析。(2)该系统使用同一套数据，提高信息的准确性与一致性。(3)实行生产成本以批号为单位进行核算。对生产质量与数量以批号进行跟踪，提供及时、可靠的信息。(4)建立若干管理的优化功能，包括计划优化、市场预测和财务预测等。(5)设计中考虑与本厂生产线上的实时控制系统的接口，以扩大系统的功能。这样的描述是否更清晰？ （4）问题定义的可交付成果——《系统建设总体方案》‡提交给用户、是以用户为目标的‡以沟通、理解、确认为目标‡系统建设总体方案（概要）‡可能成为下阶段工作的基础‡可能成为招标文件的框架‡可能成为合同的附件‡可能成为验收的标准‡可能依此编制项目计划‡可能什么都不是…… （4）问题定义的可交付成果——产品开发前景文件‡产品前景文件：在较高层次上定义问题、抽象产品和用户需求、描述产品解决方案的文件‡前景文档的读者：‡营销和产品管理团队（客户和用户的代言人）‡项目开发团队‡管理团队（对风险负责）‡前景文档是一种以简洁、抽象、可读、可管理的方式，对未来产品进行定义和表述的文件‡更多的是面向组织内部的项目分析和决策‡是通常的产品/项目开发的立项报告 （4）问题定义的可交付成果——前景文件产品前景文件模板：1、介绍提供整个前景文档的概述 前景文档的目的文档的目的是收集、分析、定义用户的需求和产品特性 产品综述陈述该应用系统的目的、版本、以及应交付的新特性 参考列出在前景文档中引用的全部参考文件清单 2、用户描述简单描述系统用户的观点 用户/市场统计总结根据市场统计所决定的产品动机分析 用户分析描述产品的预期用户 用户环境描述在使用中包括平台、应用系统在内的用户工作环境和具体使用模型 关键用户需求列出用户关注的关键问题或需求点 替代和竞争对手用户认可并可得到的可能的对手的替代产品 3、产品综述 产品前景提供系统或产品预期在市场上的状态描述 产品定位陈述提供一个系统和产品在市场上的独特定位：例如：为了（目标用户）谁（目标用户的特定需要或机遇）产品名（是某一个产品分类）它（对主要优点的陈述、既激起购买热情的原因）不象（主要竞争对手的产品）我们是（与替代品的区别）描述产品的预期用户 能力总结总结产品的主要优点和和特性客户利益支持特性利益1 特性1……. ……. 假定和相关条件 成本和定价4、管理属性描述将来评估、跟踪、划分优先等级等管理特性的属性，例如：状态：建议的、批准的优先级：关键的、重要的、有用的、建议增加的工作量、风险、稳定性：低、中、高5、产品特性产品特性描述6、典型用例以方便读者理解的方式，描述产品最典型的使用方式 7、其他产品需求 可应用产品标准列出产品必须符合的标准 系统需求定义必须满足的系统需求，如：操作系统、网络性能等 许可、安全、安装要求 性能需求8、文档需求 用户手册 在线帮助 安装指南、配置和自述文件 标记和打包9、词汇表 可行性研究一、可行性研究的含义•可行性的含义包括可能性、必要性。•可行性分析的对象是系统目标。评价总体方案（系统目标）的可能性、必要性。•所谓可行性研究，就是按照各种有效的方法和工作程序，对拟建系统项目在技术上的先进性、适用性，经济上的合理性、盈利性，以及项目的实施的可能性等方面进行深入的系统分析。•甲方和乙方不同的立场，可行性分析是不同的。我们主要以乙方的立场进行分析 （1）可行性研究-目的二、可行性研究的目的•可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决，是否有必要去解决。三、可行性分析的内容1.技术上的可行性„使用现有的技术能实现这个系统吗？即分析现有的技术条件实现系统的可能性。包括我们已经掌握或目前市场上可以获得的的计算机硬件、网络、平台软件和开发工具技术条件。„技术可行性并不是我们学生项目实践的最大难题 （2）可行性研究-内容2.经济上的可行性„这个系统的经济效益能超过它的开发成本吗？„经济上的可行性包括两个方面：一是初步估算开发系统所需的投资，目前资金有无落实；二是估计系统开发成本与能带来的效益（包括直接效益、间接效益）。3.操作可行性„系统的操作方式在这个用户组织内行得通吗？4.时间可行性„完成系统所花的时间进度能够满足用户的要求？这三个方面是我们学生最没有能力把握的 （2）可行性研究-内容5.组织与管理上可行性„从一个企业来看，企业内部管理者的素质，他们对管理现代化的认识与支持的程度，成为实现系统最根本的可能条件。„管理基础是开发一个系统的基本条件，没有较稳定、合理的管理制度、管理方法和管理流程，系统是不可能被成功开发和应用的。„同时，开发系统反过来也加强管理。6.社会、政策允许的可行性 可行性研究的步骤1.复查系统规模和目标2.研究现有系统功能循环3.导出新系统模型4.重新定义问题5.导出和分析各种可选解决方案6.推荐行动方针7.草拟开发计划8.书写文档提交审查 （1）复查系统规模和目标„问题定义阶段的成果„系统规模和目标报告书（前景文件）„复查任务„改正含糊的、二义的描述„改正不正确的描述„核查系统限制和约束 （2）研究现有系统功能„分析现有系统„高层系统流程图„确定系统功能„比较新旧系统„新系统必须完成旧系统的基本功能„新系统必须改正旧系统存在问题„新系统必须比旧系统增收入、减支出/人员 （3）导出新系统模型„旧系统逻辑模型新系统逻辑模型„新系统目标和规模„逻辑模型描述工具„数据流图„数据字典„用例图 （4）重新定义问题„复查问题定义、规模和目标„根据新系统模型„查——分析员误解„查——用户遗漏„重新定义问题„循环（定义，分析，求解，重定义） （5）导出和分析可选解决方案„从逻辑模型导出物理系统方案„不同角度„多个方案„分析各种可选方案„技术可行性„操作可行性„经济可行性„为可行方案制定初步进度计划 （6）推荐行动方针„得出可行性研究结果„继续开发„终止项目„推荐解决方案„成本/效益 （7）草拟开发计划„为推荐方案确定开发计划„进度„开发人员„硬件设备„软件工具„各阶段成本估计 （8）书写文档提交审查„可行性研究报告„各步骤结果„推荐方案„开发计划等 （9）成本/效益分析„成本估计„代码行技术„行数*每行平均成本„任务分解技术„人月1*月工资+人月2*月工资 +。。。„自动成本估算„软件工具„成本/效益分析方法„开发成本、实施费用„新系统带来的销售收益„必须考虑„货币的时间价值（利率）„计算投资回收期„纯收入„投资回收率 可行性研究-步骤 „可行性报告主要内容„引言„可行性研究的前提„对现有系统的分析„所建议的系统„可选择的其他系统方案„投资及收益分析„社会条件方面的可行性„结论 1. 3 项目论证与分析 „结论•可以立即开始进行•需要增加资源才能开始，例如增加投资或人力。•需要推迟到某些条件具备后才能开始，例如组织机构的调整。•需要对系统目标作某些修改才能开始。•不能或没有必要进行，例如经济上不合理，投资相差太大。 项目论证工作的完成，标志着：„项目启动阶段结束„项目被启动/终止„项目启动意味着：„项目目标已经被确定„项目的条件和假定被认可„项目进度和成本被初步框定„项目所需资源被批准„项目责任被明确„指定了一个项目经理，开始组织项目团队„那么，我们开始吧！ 1. 4 问题定义过程实例分析定义项目的目标和系统边界 项目实例的背景有一家名叫枪手的销售电动工具的公司正在举行下一年度公司“”业务发展的高层会议，这家公司是一家专门制造和销售用于木工用的枪手牌电动工具的一家公司。会议在座的，有公司总经理王总、“”负责销售的副总经理刘总、负责财务的钱副总和负责技术的张总等。王总首先发言：今年以来，我们的销售形式非常好，打来的订“货电话，已经要把我们的电话都要打爆了，但是，我们没有办法能继续招募到熟悉我们的电动工具、同时还了解我们销售过程的销售人员。而与我们竞争的其他公司，都已经上了自动客户服务系统（Call Center）。所以，我们也要上这个系统，才能保住我们的市场。”我们必须尽快建立这样的系统，否则我们不能保证能完成公司“给我定下的明年的销售目标。刘总响应道。”钱副总建议：难道我们不能把售后服务转给蓝色快车公司（与“公司关系密切的一家公司，以服务为主）做吗？向他们要求一下，看他们是否能把电动工具的服务也接过去？”服务不挣钱，听说明年他们甚至可能会削减一些服务项目。王“”总回答。 项目实例的背景我们需要多少钱才能搞这么一个系统？钱总问道。“”开发商说软硬件加在一起大约需要30万，张总回答“”如果我们不能在春节后就开始启用这个系统，估计我们的定单可能回“减少20%。刘总强调说。”我们除了钱还需要很多东西。我们需要了解是否有更好的方案、开发“这个系统需要多少时间，以及这个系统是不是真的适合我们！王总显然”还没有下决心。哦，我想我们完全可以自己来做这个项目，这将是很有趣的！张总兴“”奋地说。这不是我们的专长，我们不可能自己做好的。王总不同意这个提议。“”钱总说：我们有几个不错的技术人员，虽然不够，但只要再招聘一二“个高手，就可以解决它，并且做好。”项目是我们真正需要的吗？我们上了这个项目以后，公司的销售任务“就能完成了吗？王总问道，此外，我们正在经历一个困难时期，我们”“的资金并不宽余。或许我们应当考虑一下，我们怎样能用较少的资金来运作这件事。例如，我们用这个系统只处理定单，而并不包括服务，。这样系统是不是就会小一点，也省一点、快一点？” 项目实例的背景钱总插话说：哎，对呀，我们可以先完成销售定单的处理，等这“部分完成投入使用后，收到效益以后，再开发客户服务部分。公司可以在改进销售功能的同时，继续开发服务功能。这样，我们就可以省下不少费用，风险也小的多呀。”好了，王总总结道，这些都是好主意，但是我们只有有限的“”“资金和时间，技术人员的专长也不在计算机方面，还是包给外面的公司做吧，我们现在需要做的是，找到一家好公司，确保我们在两个月后不必担心丢失定单。到时候销售计划完不成，你们应该再没有什么理由怪公司不愿意投资了吧。这件事就由张总牵头，你们其他几个配合，就这么定了，散会！”现在你们公司接到了这个信息，开始介入这个枪手公司的Call “”Center系统项目，现在要做的第一件事情，就是对项目进行定义和可行性分析。 项目范围管理——背景和目标分析分析的要点‡进行背景和目标分析，是为了理解项目涉及到的环‡境，确定用户的最初需要，产生初始的解决方案（项目方案和前景视图）。通过这些推理和分析，找出隐藏在问题背后的问题。“”对背景和目标的分析过程中，将通过与用户高层的‡沟通（不同的人，看问题的出发点是不一样的。在我们的例子里），获得对实际问题认识的一致，并确定真正对需求发生影响的有关干系人。初步的解决方案包括：开发项目的理由、项目目标、‡界限和约束。可以从技术和业务两个方面来定义。在适当的时候，项目的商业理由还需要分析期望从系统获得的投资回报。 项目范围管理——目标分析‡分析的结果根据本案例的背景，我们的分析简单描述如下。‡‡由于某些具体的局限有关经济分析，我们就省略了：‡分析的关键，是对系统（业务、技术）二个方面的了解（1）业务需求‡‡1、背景：一家中型的木工电动工具公司，今年以来的销售形势很好，接受定单的电话很多，已经忙不过来了。因此，需要开发自动客户服务系统。‡2、项目机遇：通过自动客户服务系统的开发和投入使用，是公司的销售获得增长。‡3、项目目标：开发一套为公司销售和售后服务使用的计算机自动客户服务系统（Call Center）。‡4、市场需求：（产品推广前景，略）‡5、客户价值：满足公司业务发展的需要。‡6、项目风险：项目目标、方案、时间、资金等。 项目范围管理——目标分析‡（2）方案描述：‡1、系统功能：自动接听电话，对客户的定单和售后服务要求做出响应。‡2、主要特征：自动处理一些原来由人工完成的工作，有可能增加新的服务功能。‡3、假设和依赖：二个月时间内完成，总投资为３0万元。（3）局限‡‡1、可能系统需求只适合这个特定用户。（4）系统环境：‡‡1、用户概貌：‡2、项目优先级：可以先完成定单响应，再完成售后服务功能。（5）成功因素：‡‡１、技术是成熟和现成的（６）风险‡‡用户的理解、参与和配合 项目范围管理——目标分析1、项目目标是什么？‡开发一套为公司销售和售后服务使用的计算机自动‡客户服务系统（Call Center）。2、已识别的需求是什么？‡自动接听电话，对客户的定单和售后服务要求做出‡响应。3、如果有的话，准备开发的项目应具备什么样的假‡定条件？二个月时间内完成，总投资为３0万元。‡4、项目牵涉到的风险是什么？‡项目目标、方案、时间、资金、开发人员等。‡ 项目范围管理——系统需求、规模与边界进一步的分析:给出系统的功能描述、规模定义和系统边界 项目范围管理——系统功能需求系统功能包括：（1）从公司的客户方面看，新系统可以自动支持电话、‡FAX，E_mail、Web等多种通信方式所提供的服务，最大限度的满足客户的需要，最有效地为客户提供快捷方便的服务。（）从公司方面看，新系统要可以支持接入公司的交换机‡2中继线路（２Ｍ24线中继），自动或智能话务分配、坐席画面与电话同步、自动录音等功能。（）从提供服务的内容看，可以有：公司产品查询、合同‡3和定单查询、自动处理定单、产品售后服务信息查询、供货信息查询、方案介绍、产品推介、产品报修、故障咨询、投诉等。进一步的购买洽谈，可以转人工处理。（4）整个系统可以与目前公司已有或以后开发的的客户信‡息系统、产品信息系统等建立连接，形成综合的服务系统（ＣＲＭ）。 项目范围管理——系统规模需求系统规模包括：（１）用户接入方式：电话、FAX，E_mail、Web等‡（２）接入量：同时２０－４０（人工少于２０）‡（３）本地坐席数：２４‡（４）最大人工接入服务等待响应时间：无等待‡（）其他：新业务增加、接入数增加等‡54 项目范围管理——系统描述与系统边界业务需求需求特需求子特性业务描述操作描述性客户访问系系统的电话接受电话访在语音提示下，进行自统的方式接入方问动应答，提供信息和咨式询服务。FAX接受传真访自动为授权用户回复传问真E_mail接受mail根据用户填写的信息要求，自动回复相应的mail。Web接受网上访提供网上交互服务。问公司内部的系统响自动应答模电话、传真、同上系统处理模应模式式MAIL、WEB自式动应答电话转人工客户根据需要，在语音应答提示下，转人工坐席应答模式。人工坐席模一般坐席一般业务人员处理式高级坐席高级咨询顾问处理 系统服务内可响应产品服务自动查询回自动回复有关产品资料容并提供复的服务人工咨询服提供产品介绍和方案建内容务议与产品方案库的接口定单处理接受定单进入定单处理合同洽谈转人工合同洽谈合同处理合同修改转人工合同修改查询合同查询合同处理状态／与合同管理的接口售后服务报修服务记录保修内容，转处理质量投诉记录投诉内容，转处理系统信息构系统处接入24条中继接统一客户服务号码，24成理结构入线排队机自动排队机自动根据坐席忙闲和服制务等级，分配人工响应的坐席。自动坐席根据业务自根据服务请求，自动切动提供画面换到相应内容的处理画信息面和信息。数据库联提供背景数根据服务请求，自动显接据示相应背景信息，如：客户资料、产品信息、备选方案等。 项目实践第二阶段任务——目标与范围定义参考上述案例，完成第二阶段作业（1）目标描述‡‡、项目的用户背景1——本项目的需求来自：‡特定用户：‡假定用户：‡2、项目的客户价值：——对于你的用户，项目的意义是：‡商业价值：‡应用价值：‡服务价值：‡3、项目的目标描述：——给用户带来应用价值体现为：‡系统及运行环境是：‡满足用户的主要业务需求是：可以实现…….‡交付成果包括：程序、文档、….‡完成时间和阶段目标是：‡4、假设与局限——前提条件‡局限与假设条件是：‡需要的资源是：资源、支持……. 项目范围定义——系统描述与系统边界业务需求需求特需求子特性业务描述操作描述性客户访问系系统的电话接受电话访在语音提示下，进行自统的方式接入方问动应答，提供信息和咨式询服务。FAX接受传真访自动为授权用户回复传问真E_mail接受mail根据用户填写的信息要求，自动回复相应的mail。Web接受网上访提供网上交互服务。问（2）系统描述与系统边界‡‡、对业务需求（系统级、用户角度的）进行分解：1‡业务需求、需求特征、子特征、业务描述、操作描述：‡操作描述是我们可以看到、能实际操作实现的功能‡2、定义系统的边界‡在用户操作（应用）一级定义系统做什么和不做什么（系统边界），外部系统包括人和其他计算机系统‡（3）12月8日前交作业，Word文档 项目实践第二阶段任务——目标与范围定义目标与范围定义的作用‡、项目合同的基础‡1交付成果‡验收标准‡成本计算‡报价与投标‡合同签订后，项目实施时与用户达成共识的基础‡2、项目开发与管理的基础‡开发的目标‡进度、成本、质量等管理的依据‡基线控制的依据‡绩效考核的依据‡验收：操作描述-用例分析-测试用例-验收标准‡ 需求开发过程的案例分析我们将以下面这个软件系统需求开发的过程作为案例，对我们已经介绍的《需求分析》方法，作一个归纳。本案例主要内容，来自原Rational软件公司总经理Dean Leffingwell/Don Widrig合著的《软件需求管理用例方法》一书，但有所修改和补充。 需求过程1、项目背景2、问题定义3、需求获取4、需求确认5、需求分析6、需求处理7、需求评审 1、案例的背景Lumenations有限公司：（1）40年历史的商用照明系统供应商，产品主要用于职业的剧院舞台照明。（2）上市公司，但现在市场十分成熟或趋于萎缩、公司销售无力（3）公司需要新的市场，有收入和利润的增长机会，并与公司擅长的业务相差不远（4）经顾问公司充分的市场调研后，决定选择高级住宅系统照明自动化。这个市场的未来增长是25%-35%，市场发育还不成熟，没有一个厂家处于主导地位。（5）公司具有强大的品牌和分销网络、分销商渴望新的产品和市场，这是公司的优势。（6）公司决定开发“家用自动照明系统（Home Lighting Automation System,HOLIS） uLmenations有限公司家用自动照明部软件团队组织结构Emily总经理TracyRick工程部主管市场部主管MarcyMarkGavinAlyssa开发经理架构师QA经理产品经理GeneEarlRussLouise开发人员测试团队软件组长软件组长软件组长文档组长HOLIS产品的软件开发团队 2、问题定义对于将开发的产品，在一开始分析问题述求时，HOLIS团队就发现，实际上存在三个不同的涉众群体，每个群体看问题的角度是不一样的。因此，问题陈述也从三个方面进行。第一个是从公司的角度：元素描述问题……公司核心业务——剧场市场的增长缓慢受影响的是……公司、员工和股东结果是……收入和利润增长缺少实质性机会解决方案的利益公司产品和服务的新产品和潜在市场应将包括：是……9使公司及员工恢复活力9提高公司分销商的忠诚度和凝聚力9更高的收入和利润增长9公司股票价格上扬 2、问题定义第二个涉众群体是未来用户。HOLIS从未来用户的角度，提出问题描述，看自己的理解是否合适：元素描述问题……缺乏产品选择性，功能有限，目前已有的产品成本过高受影响的是……高级住宅系统的房主结果是……所购买的系统性能无法接受，决定不再自动化“正确的”照明自动化解决方案应将包括：解决方案的利益是……9使房主更满意，并以拥有该产品而自豪9提高住所的灵活性和可用性9更安全、舒适、方便 2、问题定义无疑，第三个涉众群体是分销商和潜在的建筑开发商。分销商和建筑开发商是从商业的角度（产品是否好卖，用户能否接受）看问题的：元素描述问题……缺乏产品选择性，功能有限，目前已有的产品成本过高受影响的是……高级住宅系统的分销商和建筑商结果是……与市场其他产品相比差别小，没有新的高端产品的机会“正确的”照明自动化解决方案应将包括：解决方案的利益是……9有差别9更高的收入和利润9增加市场分额 2、问题定义HOILS系统的主角灯具和其他HOLIS系统00000控制开关待定的应急接收器住户中央控制单元PC编程器公司提供的服务房主/程序员 2、问题定义控制开关子系统的主角PC编程器子系统的主角00000房主/程序员房主的PC中央控制单元 中央控制单元子系统的主角 HOILS系统的主角描述（表1）主角描述灯具和其他输出设备、灯和亮度控制，其他待定房主/程序员房主直接或通过程序员PC向CCU编程应急接收器未知：研究中住户住户使用控制开关来改变照明公司服务公司雇员支持远程编程和维护活动房主的PC与房主/程序员相同，可合并 HOILS系统的非主角描述（表2-表3）外部非主角描述分销商公司的直接客户建筑商公司客户的客户，总承包人，向房主最后的结果负责电气承包商负责安装和支持内部非主角描述开发团队公司的开发团队营销/产品管理人员由产品经理Alyssa代表公司综合管理人员成果的考核和奖金发放 HOILS开发团队与公司综合管理人员讨论的假定和约束描述理由1月5日前产品版本发布，进行本年度唯一的产品发布机会制造采用UML建模，基于OO方法以及公司的技术要求，保证开发质量统一开发过程用原型系统参加12月的展示会准备从3月开始接受分销商的定单CCU单元要复用公司原《高级照明已有设计、生产和库存，且稍加修系统》中的部件改后可复用房主PC编程只支持Windows平台减少开发工作量在需求分析阶段后，团队可增加2成本控制需要个全职编制控制开关将使用CH5444单芯片微公司已经开始普遍使用，大量采用处理器可降低采购成本允许采用外购的软件构件以不增加公司总成本为限 3、需求获取：确定HOLIS系统的主角在建立业务和系统模型的时候，HOILS团队再次分析主角找出存在与系统外部，并与系统交互的外部用户和设备。结果，他们发现了新的主角：修改后的HOILS系统主角主角描述灯具和其他输出设备、灯和亮度控制，其他待定房主/程序员房主直接或通过程序员PC向CCU编程应急接收器未知：研究中住户住户使用控制开关来改变照明公司服务公司雇员支持远程编程和维护活动系统支持（Wi-Fi）标准的无线远程控制无线远程控制器动作感应器系统支持动作（自动）感应器的输入 找出HOLIS系统的用例然后，HOILS团队用讨论的方式，找出了HOILS系统的主要用例（7个），以后，被扩展并细化为20多个。他们为每个用例编写了简单的描述。开/关灯用例的简单描述用例属性说明开/关灯名字主角住户描述住户通过按下房间照明控制板上的开关来改变房间的照明 把主角和用例关联起来（图1）在确认了系统的主要用例以后，团队构建了一个可视的用例模型，来灯具展示主角和与其交互的开关灯用例之间的关系。动作感应器激活情景这个用例图，仅仅考虑了系统外部角色与用例发起动作序列的联系，是业务模型。激活空闲模式住户如果增加内部的用例（如：CCU），则构成指示紧急情况系统模型。在需求获取应急接收器阶段，让用户少知道一编程情景点系统内部，可能是件房主/程序员好事。变成空闲序列 找出HOLIS系统的用例HOILS的主要系统级用例的简单描述（表4）用例名描述主角创建客户开灯场景住户创建一种客户开灯的场景住户、灯开启应急接收器住户开启应急装置动作住户控制灯的开关和亮住户开／关灯或设置需求的明住户、灯度暗效果编程开关改变或设置某个开关或按扭的房主／程序员动作远程编程公司服务提供者根据住户的请公司服务求进行编程度假房主为一段较长不在家的时间房主／程序员设置度假设置设置定时序列房主编制基于时间的自动开灯房主／程序员序列 理解用户需求HOILS团队用建立的业务／系统模型，采用专题讨论会的形式，再次征询用户的意见，检查团队对需求的理解是否正确。在会前，团队做了以下准备：有关高档家庭照明系统发展趋势的介绍文章已经出现的一些产品资料到目前为止进行的需求收集和分析、用例图参加讨论会的有：预期的房主、建筑商的代表、分销商的代表公司销售和产品部门的负责人全体HOILS团队成员 理解用户需求会议的结果，是形成了一个按“加权（用户和建筑、分销商权重）”的投票表决结果：票数反映了需求处理的优先级需求特性投票需求特性投票８９客户开灯场景洗手间的门打开自动开灯４３７８灯的自动定时设置瞬时开／关灯４０７３灯的安全特性、报警等可以打开窗帘排气扇３２６３１００％可靠通过电话控制开灯３１６１易于编程与家庭自动化系统的接口２６５４休假设置缓慢地提高或降低亮度２５５１任何灯都可以变暗主控制站２５４６使用自己的ＰＣ编程重新改造时易于扩展１７４６娱乐特性停电后自动恢复８４４关闭车库门语音启动１ ４、用户确认：定义系统根据需求获取阶段的工作，团队将需求进行了组织整理，并形成HOILS系统前景文件。前景文件的编写依据：用例1HOLIS前景文件用例2用例3硬件系统约束主角1HOLIS系统级用例模型中央控制子系统控制开关子系统PC编程子系统用例1用例1用例1用例2用例3用例2用例3用例2用例3主角1主角1主角1 HOLIS产品前景文件1、介绍 前景文档的目的本文档提供IHSOL系列家庭照明自动化系统的当前前景 产品综述本文档提供IHSOL系列家庭照明自动化系统的当前前景 参考…HOILS控制单元用例模型和补充规格说明…HOILS开关用例模型和补充规格说明…HOILSPC编程器用例模型和补充规格说明…“家用安全系统”中的安全和可靠性标准（Overwriters实验室） 2、用户描述简单描述系统用户的观点 用户/市场统计总结根据市场统计所决定的产品动机分析 用户分析描述产品的预期用户 用户环境描述在使用中包括平台、应用系统在内的用户工作环境和具体使用模型 关键用户需求列出用户关注的关键问题或需求点 替代和竞争对手用户认可并可得到的可能的对手的替代产品 3、产品综述 产品前景提供系统或产品预期在市场上的状态描述 产品定位陈述提供一个系统和产品在市场上的独特定位：例如：为了（正在建新的高级住宅的房主）谁（希望提高居住条件、方便、舒适和安全）HOLIS（是一个家用自动照明系统）它（带来前所未有、最时尚的自动照明功能，易于使用、价格合理）不象（Skowron工业控制的Ligthtioomna系统）我们是（把最新的家庭自动化功能与内置安全特性结合起来，具有最小的安装和维护成本） 能力总结总结产品的主要优点和和特性客户利益支持特性利益1 特性1.…… .…… 假定和相关条件 成本和定价4、管理属性描述将来评估、跟踪、划分优先等级等管理特性的属性，例如：状态：建议的、批准的优先级：关键的、重要的、有用的、建议增加的工作量、风险、稳定性：低、中、高5、产品特性产品特性描述6、典型用例以方便读者理解的方式，描述产品最典型的使用方式 7、其他产品需求 可应用产品标准列出产品必须符合的标准 系统需求定义必须满足的系统需求，如：操作系统、网络性能等 许可、安全、安装要求 性能需求8、文档需求 用户手册 在线帮助 安装指南、配置和自述文件 标记和打包9、词汇表 确定HOLIS产品的项目范围范围是产品功能、项目资源的结合体功能范围管理的主要技术，就是为项目范围项目建立需求基线。（1）确定发布软件产品版本的时间资源（时间、成本等）（2）确定发布的功能特性，称为“基线定义”。例如：为了确定基线，我们要：版本应达到：（1）为功能设定优先级功能1（特性1、特性2….）（2）为实现的功能评估工作量功能2（特性1、特性2….）（3）考虑风险因素性能1（特性1、特性2….）（4）为这些要素排序质量要求1（特性1、特性2….）（5）在有限资源条件下，划定范围，确定基线 HOLIS产品的目标范围与边界需求讨论会后，HOILS团队对每条功能特性的工作量、风险进行了评估，根据12月提交原型、1月向制造部门发布的约束条件，确定了项目目标范围和系统开发边界。版产品基线需求特性投票工作量风险市场备注８９客户开灯场景中低尽可能灵活７８灯的自动定时设置低低尽可能灵活７３灯的安全特性、报警等低中市场部要进行调查100%可靠６３尽可能接近100%高高６１易于编程高高提供指定的控制器５４休假设置中低按一定模式设置５１任何灯都可以变暗中低无级调节４６只提供一种配置使用自己的ＰＣ编程高低 HOLIS产品的目标范围与边界需求特性投票工作量风险市场备注国际化的CCU用户接口４６中中需要与欧洲分销协商４６不包含在中娱乐特性高高以上功能是指令性基线，必须在版本中实现，否则将推迟发布４４关闭车库门低低对软件影响较小洗手间门打开自动开灯４３中中瞬时开／关灯４０可以打开窗帘排气扇３２通过电话控制开灯３１以上功能争取在版本中实现，但实现与否，不影响发布。以下功能仅在版本中实现。与家庭自动化系统接口２６重新改造时易于扩展１７停电后自动恢复８语音启动１ 5、需求分析：细化定义实现视图逻辑视图描述HOLIS的不同代码描述HOLIS功能制品，包括源代码和的类、关系和可执行文件构成子系统结构类, 接口,组件协作用SILOH例图过程视图部署视图体现完成任描述在SILOH多个房间务时HOLIS的或子系统上的功能分布多任务能力，控制开关、中央控制单元、编程CP活动类节点HOLIS的四类视图：UML通过多重视图的方法，从用例出发，以不同角度，描述目标系统 逻辑视图：为了支持开发和测试，用例需要进一步被细化和详尽描述，即从用例模型向设计模型转化（实现用例）。MUL以协作作为系统的关键结构，描述用例（问题域）到系统行为（解域）的关系协作有二方面的内容：用例模型设计模型静态结构方面是：类、元素、接口、子系统等，表协作用例示的形式是类图等行为方面是：元素之间的交互动作，表示的形式是交互图等参与的类基于MUL的需求分析就是完成用例模型向设计模型转换 HOLIS的类与类图（图2）首先，为HOILS找出三个系统级的类：9按扭类（界面）9中央控制器CCU类（控制）CCU9灯类（执行）其他类，如：应急控制、11编程等，以后可逐渐填加**按扭灯 细化HOLIS的类（图3）对系统级的类，再进行细化：CCU9按扭类：可以细分为开/关/变暗/变亮/报警等119中央控制器CCU类：暂时不进行**分解按扭灯9灯类：可细分为主环境、背景、主题、氛围、区域等开关变暗变亮报警 划分HOLIS的子系统（包）<<subsystem>><<subsystem>>9HOLIS系统除CCU外，按不同场景（居室）应用，分解为不同的子系统<<subsystem>><<subsystem>>9每个子系统含有开关和灯类的对象实例9它们与CCU协作完成控制<<subsystem>><<subsystem>>***子系统开关对象灯对象<<subsystem>><<subsystem>>切记：理解子系统的含义——不是功能的集合，是对象的集合，是对象的逻辑分布 从需求出发，考虑HOLIS系统的逻辑结构逻辑结构建立过程：开关灯住户角色灯角色用例9需求分析从用例出发9寻找出三个系统级类CCU类开关类灯类9类再被分解为子类9系统按应用场景被分为开关变亮变暗不同的子系统（包）开关子类9子系统实现类的对象灯子类***子系统***子系统***子系统***子系统***子系统开关灯对开关灯对开关灯对开关灯对开关灯对对象象对象象对象象对象象对象象体系结构最后呈树型，还是比较合理的菱型（重用），系统设计中分析 HOLIS用例实例：开关灯简要描述：该用例规定了灯的开关方式和根据用户按下控制开关上按扭的时间长短变明和变暗的方式。基本流程：住户按下控制开关的任何一个按扭开始，如果用户在定时器的规定时间（1秒）内松开，系统改变灯的当前状态。9如果灯是开的，就把灯关上，没有照明。9如果灯是关的，就把灯打开到上次记忆的亮度。意外流程：如果住户持续按下控制开关的开/关变暗按扭超过1秒钟，系统将为按下的控制开关按扭启动一个变暗的活动9被控制的灯的亮度以每秒10%的速度平滑地增大到最大亮度9当达到最大值时，被控灯的亮度以每秒10%速度降到最小值9当达到最小时，继续按上一步骤循环进行9当住户停止按住开关的开/关/变暗按扭时，系统停止改变亮度 HOLIS用例实例：开关灯控制灯用例的前置条件：9所选控制开关的开/关/变暗按扭必须“可以变暗”9所选控制开关的开/关/变暗按扭必须能够扩展灯的明暗程度控制灯用例的后置条件：9在退出本用例时，系统记住所选控制开关的开/关/变暗按扭的当前亮度。扩展点：没有特殊需求：9性能：对于住户任何的可能动作，总控制板到系统响应的时间必须少于50毫秒 开关灯用例的Interaction框图CCU按扭灯准备按按扭持续时间在1秒内显示按扭状态，开/关灯，并采短暂按下按扭按扭被按下用记忆亮度返回信息返回信息显示信息按扭被按下按记忆状态变1持续按下按扭亮或变暗循环秒以上返回信息返回信息显示信息松开按扭按扭被松开停止变化亮度返回信息返回信息显示信息根据用例和类，描述一次按下按扭事件的跟踪图 开关灯用例的状态图：按下开/关灯状态:开/关关/开松开?松开吗变亮/变暗按下时间未松开少于1秒停止变化已松开停止 HOLIS开关灯用例的测试用例在完成对需求详细定义的同时，设计完成测试用例。编号描述灯的状态预期结果基本流：住户按下按扭的时间小1开关并记忆亮度于1秒基本流：住户按下按扭的时间小2关按记忆亮度开于1秒其他流：住户按下按扭的时间大3亮度按10%/秒速度上开于1秒升达到最大后下降并循环其他流：住户按下按扭的时间大4关先开，然后再同上循于1秒环其他流：住户按下按扭的时间大5开停在当时的亮度位置于1秒后松开了开关其他流：住户按下按扭的时间大6关停在当时的亮度位置于1秒后松开了开关 项目第三次作业《需求分析报告》参考老师给出的案例（HOILS系统），项目的《需求分析报告》应包括以下内容：1、给出系统主角/非主角定义与描述（表1、2、3）2、给出系统主角与用例关系定义（表4）、描述每个主要用例（图1）、3、定义至少二级以上（系统级、细化的系统级）的类（类、责任、协作关系）、画出类图（图2、3）4、描述每个主要用例的事件流、意外流、错误流、前置条件、后置条件5、选择一、二个主要用例，用UML方式画出交互图（可选合适的图形表示）6、给出采用测试业务用例验收系统时的全部测试用例提交时间：1月12日，作为项目组的学期成绩（红色为重点） 课堂作业：类与对象分析（静态模型）电梯控制系统¾一个电梯有12个按钮，每个按钮对应一个楼层，按下按钮电梯会显示相应楼层号码，并运行到该楼层¾除了顶层和底层外，其他各层都还有2个请求上或下的按钮，当按下此按钮后，按扭会发亮，直到电梯离开该层后才熄灭（顶层的按扭是下，底层的按扭是上）。¾当没有请求时，电梯停在当前层，门是关闭的根据题目，分析系统的类与对象：9归纳出与电梯系统有关的对象类是什么？9该类可选择的对象是什么？9类与对象可能有的属性（状态）、操作是什么？ 第三章软件需求管理 第三章目录需求工程与需求管理的概念3-1.需求开发阶段的需求管理需求实现阶段的需求管理需求变更控制管理3-4. 需求工程与需求管理的概念¾ 需求的噩梦¾ 需求与需求管理的概念¾ 现代软件工程的需求工程¾ 传统软件工程的局限性 需求工程与需求管理的概念 对大多数软件和系统开发团队来说，与过去自由的日子相比，20 世纪90 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重构的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？ 需求的噩梦为什么要管理需求？简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。也就是说：好的需求管理是项目成功的第一位因素。采用需求管理可以给项目组带来很多的好处，直至项目取得成功。Brooks[1987]：不能得到完整、正确以及无二义性的软件需求仍然是如今导致软件开发失败的一个重大原因 一组数字据Standish Group(1994)的研究表明，在美国：„每年大约花2500亿美元，开发万个应用程序项目„大公司开发项目的平均成本是万美元„中等公司的平均成本是万美元„小公司则是万美元另一方面：„大约31%的项目在完成之前被取消„%的项目成本是项目原来预算的189%因此，Standish Group估计，美国公司和政府机构z在被取消软件项目上的花费，每年大约是810亿美元z同样，他们为超过交付时间而需要多支付590亿美元 软件开发的问题分类ESPITI(欧洲软件过程改进培训倡议）60（1995）所作的一个50调查，3800个被调查40主要问题者认为，软件开发的30次要问题主要问题、次要问题不是问题20和不是问题的问题如10图。0一半以上的人认为，123456软件的二个最大问题是：1、需求规格说明1、需求规格说明4、软件和测试2、管理客户需求2、管理客户需求5、项目管理3、建档6、编码相对而言，编码不是问题问题的重要性依次降低 项目失败的根本原因Standish Group的研究表明，对软件项目的评价因素，可以归纳为：成功（大公司只占9%、小公司有16%）有异议（推迟且没有达到预期的目标）失败（取消）而有异议的三个主要原因是：1、缺乏用户的参与（占所有项目的13%）2、不完整的需求和规格说明（占所有项目的12%）3、不断改变的需求和规格说明（占所有项目的12%）而其他因素，则比例较小，例如：不合理的时间进度和时间分段（4%）人和资源不足（6%）技术技能不够（7%）结论：1/3的项目直接与需求的获取、建档和管理有关 需求变化合理范围内的变化：„用户不了解自己的需求„需求本身易变，市场、技术、竞争因素不合理的变化：„需求文档质量不高„需求分析技能、技术和管理上的缺陷需求变化的原因：„未受控制的需求变更„遗漏需求„用户交流不够„需求规约质量差„低效的需求分析 迭代开发模式下，需求在项目各为什么要管理需求？阶段所占有的比例需要更好地适应需求变化、更好的进行范围控制和管理 需求错误的代价开发阶段需求阶段设计编码1单元测试2验收测试5维护20修复的相对成本 需求与需求管理的概念什么是需求？„需求的基本概念…宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。…需求是对系统要做什么、如何工作、表现出来的特征、必须具备的质量、必须满足的约束的叙述„需求的重要性…需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。…国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。 什么是软件需求？一般把需求定义为“（正在构建的）系统必须符合的条件或具备的功能或能力”。电气和电子工程师学会使用的定义与此类似。著名的需求工程设计师Merlin Dorfman和Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面-但不仅仅限于软件：1、软件需求可定义为：用户需解决某一问题或达到某一目标所需的软件功能。2、系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。 需求全部是来自用户吗？问题领域需要用户需求应用系统需要系统特性软件系统需要系统需求需求的分解 什么是需求管理？由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动过程，就是需求管理。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。这个定义与Dorfman与Thayer 以及IEEE 的“软件需求工程”的定义相似。需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。所以，需求管理包括软件需求过程的整个过程 软件项目和软件过程的需求管理PMBOK的范围管理按照PMBOK的定义，范围是指产生项目产品所包括的所有工作及产生这些产品的过程。范围管理是指对项目包括什么和不包括什么的定义与控制过程。项目范围管理的核心是：为了顺利地完成项目而设置了一些过程，这些过程的目的是确保项目包括且仅仅包括所要求的工作（交付成果）。这一控制过程的含义同时还指：确保项目组和用户（或称为项目利益关系人）对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。从软件项目的需求管理，理解项目管理的范围管理 CMM2的需求管理软件过程能力成熟度模型（CMM）对需求管理作了明确的要求，为达到CMM2级，组织就必须具备满足软件开发与管理的六个关键过程域（key Process Areas，KPA）的能力。而需求管理就是这六个关键过程域中的第一个，是其他五个域实施的前提。CMM2指出，需求管理的目的是在客户和遵循客户需求的软件项目之间建立一种共同的理解。因此，需求管理活动的内容应包括就软件的需求同客户达成一种共识并加以管理。该共识就是“指定给软件的系统需求”。CMM2需求管理的目标是：（1）控制指定给软件的系统需求，为软件工程和管理应用建立基线；（2）保持软件计划、产品和活动与指定给软件的系统需求一致。 CMM2的需求管理CMM对需求管理的定义是：对需求分配进行管理，既要在用户和实现用户需求的项目组之间达成共识；控制系统需求，为研发过程和项目管理建立基线；保持项目计划、产品和活动与系统需求的一致性。从定义出发，需求管理涉及三个方面的内容：需求定义的管理、需求实现的管理、需求变更的管理。一般认为，需求管理并不包括需求的收集和分析，而是假定组织已收集了软件需求或已经明确地给出了需求的定义。或者说，广义的需求管理还应包括用户需求的收集、处理、分析和验证等内容。我们从广义需求管理的概念出发，可以也归纳出需求管理活动的范围主要有需求的开发和需求的管理二个部分的内容。 CMM2的需求管理需求的开发包括：（1）需求获取；（2）需求分析；（3）编写需求规格说明书；（4）需求验证。需求的管理包括：（1）确定需求变更控制的过程；（2）组织变更控制委员会；（3）进行需求变更波及分析；（4）跟踪所有受需求变更影响的工作产品；（5）建立需求基准版本和需求控制版本文档；（6）维护需求变更的历史记录；（7）追踪每项需求的状态并建立数据库；（8）衡量需求的稳定性；（9）使用需求管理工具进行需求管理。从CMM2对需求管理的要求、目标和管理过程中可以看出，CMM2的侧重点在于需求获取以后，如何建立需求基准线，并依据需求基准线，对项目的需求进行的控制和管理。 .现 代软件工程的需求工程‡面对软件工程过程中存在的需求不确定性问题，软件工程进一步获得发展，其中一个具体体现，就是发展出“需求工程”的概念。‡需求工程是提供一种适当的机制，以了解用户想要什么、分析需求、评估可行性、协商合理的解决方案、无歧义地规约解决方案、确认规约以及在开发过程中管理这些被确认的需求规约的过程。‡因此，需求工程的活动也可分为两大过程域，一个过程域是需求开发，另一过程域是需求管理。现代软件工程的需求工程需求开发过程需求管理过程需求工程的需求获取需求实现两大过程域需求分析需求跟踪需求处理需求变更控制需求确认 需求开发过程域„需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。…需求获取的目的是通过各种途径获取用户的需求信息，产生《用户需求说明书》或《产品远景文件》。…需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。…需求处理的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。…需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求管理过程域…需求管理的目的是在客户与开发方之间建立对需求的共同理解的基础上，实现需求并在实现的过程中，维护需求与其它工作成果的一致性，并控制需求的变更。„需求实现是指在系统概要分析、详细分析和系统编码、测试等开发过程中，实现系统的需求。„需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。„需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。 传统软件工程的局限性1、从过程看：现代软件工程的需求过程要求参与整个产品生命周期的需求管理，注重整个产品过程的全部而不是一个阶段需求工程完整产品产品工程的（全局视图）层次图：硬件软件业务和系统建模数据功能行为分析和设计建模构造和集成实现 传统软件工程的局限性——需求管理是全过程的目标环境用户反馈产品使需求处用维护理过程产品需求描述构建反馈系统构建实施需求分析理解设计反馈分析反馈设计规范说明需求确认系统分产品规规格说明析规约划设计需求分析规范说明 传统软件工程的局限性2、从功能看：现代软件工程的需求过程扩大了对需求管理的功能范围传统软件工程的需求现代软件工程的需求工程分析，仅仅是对“用户需求”的计算机术语化需求开发过程需求管理过程“描述”转换。（1）确定对系统的需求获取需求实现综合要求（2）分析系统的数需求分析需求跟踪据要求：需求处理（3）抽象出并确立需求变更控制目标系统的逻辑模需求确认型；（4）编写需求规格需求工程我们可以回忆一下，在软件工程中，需求分析花了说明书。很大的时间和篇幅，介绍具体的需求分析的方法，的结构图：比如：早期面向结构化的分析方法（SA）、数据流图（DFD）等。 传统软件工程的局限性3、从思想方法上看：我们从传统软件工程的定义和计划阶段的工作内容，可以看出，软件工程认定：9“问题”已经是一个明确的、固定的、可获得的；9如果通过可行性分析，认为项目可行，则此“问题”也是可“求解”的。9因此，根据这个假设，可以确定工作内容、产品与成果、验收标准等技术指标，也可以制订工作进度、任务分解，以至可以进行成本预算等，确定了任务的目标。在这个假设下，软件工程的需求分析，是一个“纯”技术性的“转换”。既把用户的需求，准确地描述为“软件需求”的过程。 传统软件工程的局限性传统软件工程的假象前提：（1）软件工程假定：用户需求在需求分析开始之前，是一个基本明确的、固定的、可获得的。（2）需求分析阶段的目的，是“描述”这个已经存在，但还没有用开发者自己的方式“描述”出来的需求。（3）软件工程把这个“描述”工作，做了定义，就是需求分析的四个任务。通过这个任务的完成，获得数据字典、系统的数据流定义、处理逻辑定义等手段，实现对“用户需求”的描述。（4）软件工程更关注这种：“描述”的方法和过程（需求分析方法）。 需求开发管理¾ 需求开发的过程¾ 需求获取阶段¾ 需求分析阶段¾ 需求处理阶段¾ 需求验证阶段 需求开发的过程现代软件工程的需求工程需求开发过程需求管理过程需求获取需求实现需求开发过程或者又可以称之为需求需求分析需求跟踪定义过程，主要包需求处理需求变更控制括：需求确认9需求获取9需求分析9需求处理9需求验证 回忆一下：问题定义阶段的任务和步骤(一)系统任务的提出1. 系统任务的提出者2. 系统任务的提出形式3. 系统任务提出的目的(二)初步调查1. 初步调查的目的2. 初步调查的主要内容(三)系统目标的确定1. 系统目标的含义2. 如何确定系统的目标成果交付物：《需求说明书》或《产品前景文档》 需求开发过程的阶段任务需求开发过程的重要里程碑面向实现的细化需求获取需求分析需求处理面向管理的规范问题需求验证面向成果的验证定义阶段需求分析阶段面向用户确认面向实现的需的需求描述求规格说明用户确认需求评审 需求获取阶段——产品前景文档：确定系统目标123456A项目背市场机客户价风险经济效可行项目论证景遇值益分析性分析B产品描述主要功主要性主要质其他能描述能特征量标准C交付成果直接交文档实施过培训与其他定义付物程服务D项目目标进度目成本目质量目其他标标标E风险因素资源需限制与求保证假设 工具和方法„传统的结构化分析方法…分析模型描述工具„DFD、DD和PSPEC „CFD、CSPEC和STD „E-R图„面向对象的分析方法…标识对象…标识结构…标识主题…定义属性和实例联系…定义操作和消息联系…分析模型描述工具„用例图，对象-关系图，对象-行为图 工具和方法„UML过程：…需求获取——业务建模„建立业务模型和系统模型„以业务用例形式与用户建立共识，获得确认…需求分析——建立系统静态和动态模型„静态模型——类和对象„动态模型——行为和事件流…需求处理和验证„9张图表：…用例图、类图、对象图、状态图、时序图、协作图、活动图、构件图、部署图„5个视图：…用例视图、逻辑视图、构件视图、并发视图、部署视图 编制软件需求规格说明（SoftwarRee quirementSsp ecification，SRS） 需求获取阶段的目标——获得用户的确认建立业务模型的工作主要包括：¾分析领域中的业务角色¾分析角色间的业务功能等关系¾分析业务组织架构¾分析业务规则¾分析业务实体¾分析业务事件¾分析以业务角色为主角的业务用例等；以业务用例为实例，与用户进行沟通：9需求是否被清楚地陈述？9存在错误的理解吗？9需求的来源（人员、规章制度、文件）是否正确？9需求的最终陈述是否得到用户最终责任人确认？ 解决用户和开发人员综合症问题解决方案用户不知道他们需求什么或不将用户当作领域专家来认识和感激，知道如何表达尝试一下其他沟通和启发技术直到开发人员把用户所描述的尽早提供相互选择的启发技术：情节东西给他们，用户才认为知道串联板、原型、角色换位等自己要什么分析人员认为自己比用户更了把分析人员放在用户的位置，试着换解用户的需求位一小时或一天被动式介绍主动式介绍交互式介绍用户讲故事幻灯片放映原型开发介绍游戏规则动画制作交互演示输出结果仿真演示现场演示复杂程度与成本需求诱导的方法（情节串联板） 需求获取过程需求管理的关注点步骤：1、发现和分析问题2、理解用户的需求3、定义系统（用例模型）4、管理范围（项目管理）方法：采用业务建模和系统建模的方法进行问题分析对与系统架构和系统行为有关的用例进行描述和定义目标：‡在问题定义上与用户达成共识‡理解问题背后的根本原因‡确定用户和项目干系人‡定义问题解空间的边界‡确定问题解决方案的约束和假设最终阶段完成标志：用户对系统目标的认可——签字 需求获取过程产品基线管理的关注点技术创新和突破产品特点系统平台与兼容性公司目标与市场需求客户：涉众和用例一个真产品前景文件正伟大的产品分析人员和专家的意见与公司其他产品与对手的竞争性开发团队的状况与的配套和一致性产品差异和优势产品的可持续性 需求获取过程产品路线管理的关注点05/0105/0705/0906/0106/03多平台远程新系统支持基本安保客户维护版本特性功能接口定义中央控制单元户主客户控制开关图例：正在发行发布代码行代码行修改 需求分析阶段需求分析阶段的任务和步骤„复查系统规模和目标„研究现有系统功能循环„导出新系统模型„重新定义问题„导出和分析各种可选解决方案„推荐行动方针„草拟开发计划„书写文档提交审查阶段成果交付物：需求定义文档（需求规格说明） 需求分析——需求获取与需求分析的区别需求获取是面向用户、在较高的抽象级别上对系统特性的定义z可以更多地关注系统的特性以及如何体现用户的需求，以便更好地理解系统的形状和形式z可以对系统的完整性、一致性以及对环境的适应性进行评估z在继续大量投入之前，可以利用这些信息决定可行性和管理系统的范围z可以脱离对具体需求进行取舍和决策所带来的风险z需求获取的目标是用户的认可，因此，阶段的验收标志是用户签字确认的需求描述 需求分析——需求获取与需求分析的区别需求分析是面向系统实现、严格对系统需求的定义z定义系统的输入、输出、功能、属性以及系统环境的属性，决定系统的完整集合z面向系统技术实现，讨论系统应该做什么，因此，应避免受项目进度、计划、预算、设计、测试等的影响z需求和设计是迭代进行的，但需求将引导设计，也受设计方法的制约z需求分析的验收标志是组织的需求评审 需求分析——细化系统定义在需求获取阶段，我们已经通过建立业务模型、系统模型，与用户共同确定了系统的特性：9业务模型，可以映射出软件产品核心的需求，包括与业务功能对应的组织的特性，与业务流程对应的内外部关系特性等；9系统用例模型，是在已经建立的业务模型的基础上，建立系统的模型。9用例——业务模型和系统模型的最典型表示形式‡软件产品本身可能还存在与业务无直接关系的另类需求（一般与硬件、软件环境相关），比如支持多种操作系统、对软件运行的远端监控要求、异常处理（如通讯连接中断等非业务异常）等等。‡另一方面，设计约束和限制，也是系统需求必须要考虑的内容通常这三部分需求构成软件需求的总集。 需求分析——细化系统定义在需求分析阶段，我们不可避免地要当前需求使我们涉及到进行设计决策考虑采用某种设计选项设计决策：‡硬件环境（运行在PC服务器上？还是小型机？）‡平台的选择（只支持Windows平台，是否也支持UNIX平台？）‡工具的限制（采用VB实现？）被选择的设计选‡方法的约束（用XYZ类库实现项可能影响需求数据库访问？）需求分析是在需求获取、需求分析和设计决策之间反复迭代循环的过程 需求分析——细化系统定义系统需求功能性需求非功能性需求设计约束软件需求是具体的：9面向系统设计、编码9面向测试因此，在需求获取的基础上，进一步细化系统需求、明确和细化系统定义，这就是需求分析阶段的任务在传统软件过程方法中，这二个阶段不是非常清晰和明确 需求分析——细化用例在需求获取过程中，我们建立了业务模型和系统模型，引入了角色和用例的概念角色与用例的区别：¾系统的角色是业务之外与业务交互的人或事¾例如：ATM取款机作为一个业务系统，来取款的客户就是一个角色¾用例是业务模型中，业务的活动¾在系统模型中，描述了业务中系统的工作（内部活动）。角色是外部，用例是内部。取款的客户是角色，取款是用例。用例模型开始定义角色之间的关系（关联关系：包括关系、扩展关系、一般化关系等）。用例模型描述事件流，包括主事件流、其他事件流、前提条件、事后条件等等。 需求分析——细化用例细化用例的主要步骤：z审查主角z细化描述z定义和细化事件流程z确定前置条件和后置条件z确定特殊需求z扩展用例 需求分析——细化用例关系为需求处理做准备9在定义系统的用例规约之前，确定一份基本的术语词汇表，以统一项目开发中的用词。9确定系统的用例，通常从寻找系统的主角开始。如果做了业务建模，则可以先从业务对象模型中的业务工人（Business Worker）着手。9系统主要的主角确定后，可以根据为系统主角提供有价值的结果（Result of Value）这一准则（用例是为主角的活动最终提供一个有价值的结果的活动过程）来确定系统的用例。9理清系统用例之间存在的密切关系，具有的内在结构，如泛化关系、包含关系、扩展关系等。9有二种Interaction图，按时间顺序排列的是Sequence图，按对象关系排列的是Collaboration图。二种图从不同的角度，反映了案例中特定情形的流程。 需求处理阶段需求规格说明书项目《用户需求说明书》或《前景文件》提供了业务需求的宏观描述文档，使得公司内部相关部门对项目，有一个全局的了解。Use Case图和Interaction图为用户，为项目组提供了需求的详细描述。为了后续开发阶段（概要设计和详细设计）的需要，在传统模式下，有了用户实例，还必须编写从用户实例派生出来的功能需求规格说明书和非功能需求文档。包括：质量检验标准、接口说明等。这些文件，成为需求分析的成果。CMM2也规定，必须以文档形式，给出给定需求。 需求处理——传统的《需求规格说明书》123456软件需求规格预期的A引言目的文档产品参考说明书阐述一读者和约定的范文献阅读建个软件系统必围议须提供的功能设计和B综合描述产品产品用户运行假设和性能，以及实现上前景的功类和环境和依的限制他们必须考虑能特征赖附录的限制条件。C外部接口需用户硬件软件通信求附录界面接口接口接口这不但是测试附录和用户使用、激励/D系统特性说明功能响应维护文档的基和优需求序列先级础，而且，也E其他非功能性能完全安全软件业务用户是系统的子系需求需求设施性需质量规范文档统规划、设计需求求属性和编码的基础。F其他需求待确定G附件词汇分析问题清表模型单 需求文档：需求的形式化问题需求文档化：需求一旦确定，就需要把它用文档的形式，固定下来。文档化的目的：9首先通过记录（纸质的文字或数据库记录等），使需求被记录下来。任何口头的传误，在文字记录上，会被减少。9其次，形式化最主要的追求，是解决完整性和无歧义性。能真正达到形式化的需求，是需求分解、分配、追踪、评估的条件。20世纪80年代的一项研究表明，20%的错误是对需求的错误解释造成的。IBM公司对需求描述的形式化研究，已经提出了一种保证需求文档更一致的需求描述方法学，使通过使用这种规定的方法建立的需求，不同人写的需求之间的差异，已经降到最小。为了便于需求实现和变更控制管理，需求形式化在形式上，进一步发展为需求数据库化。 需求形式化——消除歧义的努力消除需求描述的歧义性，是软件工程的“软肋”，没有什么更好的方法。因为对需求的描述和定义，不可能像计算机语言的定义那样，做到无二义性。因为，代价太高了。消除歧义的方法：原始：了解和记录用户的最原始需求，不要转述、不要用自己的理解代替。关键：对关键部分、关键字，尽量用大家都理解的、无二义的限定词描述。逆向：对需求试着用其他的（逆向的）思维和理解方式进行解读，看有什么可能得到不同的解释。分解：对需求进行分解，在分解过程中，找到不合理和不符合逻辑的错误。图形：用非自然语言的方法，表述需求，减少理解的差异。需求的形式化处理，可以帮助你实现以上目标。 需求形式化的技术方法：为了规范化需求，使以下各阶段能够在可分解、可追溯、允许增/删改的基础上对需求进行使用和管理，需求形式化的最基本要求，是应该把需求按系统体系结构进行分解，形成类似工作分解的WBS，需求被标上层号和序号。需求记录不仅仅是一篇文字。在很多项目组中，需求就是一篇长文章，有的甚至是事后补写的，更谈不上条理化、数据库化。在这样的情况下，需求的分解和实现，充满了二意性，完全根据实现者的理解。同样，项目任务的分解是模糊不清的，需求变更是界线不清的，变更的影响不但无法评估，甚至涉及的范围都无从知晓。在追求需求形式化的道路上，软件人做了长期的努力，但结果并不尽人意。可以实用的方法有：9伪代码9有限状态机9决策表和决策树9活动图（流程图）9实体联系模型（ER模型）9不成功的方法：形式语言描述 需求形式化的技术方法：需求数据库在需求数据库的支持下，需求是细致的。如果把需求的层、项看成是一个搜索网络的话，借助这个网络，可以全面地捕捉容易疏忽的需求，特别是系统的边界情况。同时需求数据库也是可标记状态、记录活动的。有支持需求数据库化处理的工具，如：Rational的RequisitePro或MS的VSS，来协助进行需求的数据库管理。需求记录和管理的数据库化，先是对需求进行分解，然后，是建立需求项的属性。 需求属性化是需求数据库化的基础需求属性含义说明名称*需求名称用最简洁的语言表示需求的核心含义描述与定义*对需求的描述定义需求的最本质内容可以用模型、图、表表示编号层/序*需求的顺序号可根据系统结构或任务的WBS编排来源*需求的提出来源用户需求的更高层依据、来源提出/决策人需求的提出人当需求变化或受到影响时能最终决定的人优先级需求的优先级表明高、中、低，以备取舍或决定响应次序实体*需求实现的实体表明需求与实现实体的对应关系状态*需求所处的状态包括：提出批准、实施、实现、完成或拒绝、推迟、等待、丢弃等。稳定性需求的稳定性按稳定性定义描述稳定性的高、中、低验收标准验收标准需求实现的验证方式和标准负责人需求实现的负责人备注对需求的附加说明作者需求的提交者版本号*需求的版本号变更记录*本版本的变更内容描述本版本的变更原因、内容、影响更新日期*需求的变更日期 需求形式化与需求数据库‡有了具有信息属性的需求信息，根据这些属性描述，我们可以抽象出需求数据字典，这样，我们就可以建立需求数据库了。‡通过需求数据库，我们可以方便地对需求的变化，增加、修改、变化记录、状态变化等，做出完善的记录。‡更重要的是，借助需求数据库，我们可以：分配资源，‡评估状态，‡计算软件指标，‡管理项目风险，‡估算成本，‡确保用户的安全，‡管理项目规模。‡ 需求形式化与需求分配在上面的这张表中定义的一个需求，对应需求数据库的一个“数据项”，我们称之为一个“需求项”。根据对整个系统需求的分解，我们可获得一棵需求树（WBS树）。“根”需求项，就是对整个系统的需求描述。需求项在需求WBS架构中，处于节点的需求，可以分配给一个部门、小组或个人。他们将根据人员、时间等，再被分解为更细的需求项，直至不需求再进行分解。处于WBS“叶”位置的那些需求项，是需求实现的最低层单位，应根据人员和任务周期计划，进行工作分配。在项目管理中，有了分层次的需求分解，很快，就可以建立根据“需求项”的任务分解和任务分配，这就是需求分配。 需求形式化与需求基线的建立™基线ƒ在软件工程环境中，基线是指在软件开发过程中的里程碑，这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的软件制品的提交。ƒ项目开发过程的制品经过正式评审并被相关人员一致同意，可以作为以后项目开发的基础。对已经基线化制品的修改必须要通过正式的变更控制流程。ƒ不同的基线ƒA. 功能基线(Functional Baseline)ƒB. 已分配基线(Allocated Baseline)ƒC. 开发基线(Development Baseline)ƒD. 产品基线(Product Baseline)ƒ在用户和项目组之间达成共识、并已经按需求属性建立需求数据库的需求，是建立需求基线的基本条件。 需求基线的管理¾配置管理组或委员会（CCB）按照需求基线，对整个项目的进程，进行控制和把握，配置管理员负责把符合基线要求完成的构件，放进配置管理库中。这样确保了整个需求的基线化控制和管理。¾需求基线的核心是按基线进行控制。¾需求基线的条件是需求形式化。因为需求基线是按需求项进行控制的。需求项是必须形式化的。¾需求的跟踪、变更分析、实现控制、配置管理，无不是依靠形式化的需求进行的。¾软件项目经理要督促项目组，提高需求管理水平，就必须从需求形式化开始，至于形式化的形式、细化的程度，则可以根据项目的实际情况，来具体对待和处理。 建立基于软件架构的需求基线以构架为中心的软件开发模式，是近几年来软件界大力推崇的一项最佳实践，它较好地解决了软件开发中以往难于克服的多个难题，如需求的变更问题、系统功能扩展的困难、系统的设计基础脆弱的问题等等。软件构架与系统的软件需求往往不是一一对应的关系，通常软件架构的设计应当基于超出当前软件需求定义的边界之外、更为广泛的需求超集，这个需求超集通常而言就是业务领域模型。真正健壮的软件构架应当面向整个业务领域，因为系统的软件需求不管如何变化，其内容仍然处于原有业务领域的范围之内，这样软件架构将毫不费力地适应这些新的需求变更。 需求验证阶段编写测试计划与测试用例编写用户使用手册编写系统验收标准通过需求评审 需求验证阶段——需求评审对象CMM2就需求评审的对象——“给定需求”的文档依据规定为：（1）影响和决定软件项目活动的非技术需求（例如：协议、条件和/或合同条款）。具体实例有：要交付的产品、交付日期、里程碑。（2）软件的技术需求实例有：最终用户、操作员、支持或综合能力；性能需求；设计约束条件；程序设计语言；界面需求。（3）用于确认软件产品是否能满足给定需求的验收标准。 需求验证阶段——需求评审内容CMM2对评审内容规定为：（1）确定不完整和遗漏的给定需求；（2）评审给定需求以确定他们是否：可行、适用于软件实现、说明清楚、适当、彼此一致、可测试。（3）有负责分析和分配系统需求的小组对确认可能有问题的给定需求进行评审并进行必要的修改。（4）相关小组协商由给定需求所得出的约定。 需求验证阶段——良好的需求规格说明属性具有良好的需求规格说明属性的需求文档，具有如下的属性：（1）不含糊性：如果每一个需求只有唯一的一种解释，那它是不含糊的；（2）完整性：如果需求包括了功能、性能、时间响应要求、限制、接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求，是完整的；（3）可检验性：存在有限的、经济与技术都是可行的检验方法和程序，对需求的实现与否，进行检验，使得用户和组织通过该检验，确认需求被按照需求规格说明实现；（4）一致性：需求作为一种要求是一致的，不存在系统内相互冲突的需求要求；（5）可跟踪性：需求可追踪；（6）可使用性：可为产品的各阶段，特别是维护阶段，提供充分有用的信息。 需求实现管理¾ 系统架构与需求实现的关系¾ 需求状态的变化¾ 需求状态变化的追踪 系统架构与需求实现的关系Application Layer应用层非常紧密Business Logical Layer业务逻辑层较紧密Foundation LayerBusiness Entities Layer基础支持层业务实体层不太紧密Data Access Layer数据访问层不紧密DataBase Layer最不紧密数据库层软件架构与实际业务模型联系的密切程度 把握需求实现的关键是设计良好的软件构架实际上，对于像电信软件等企业级核心应用软件而言，其构架在更大的程度上会决定于其质量、性能、操作环境等非功能特性。例如：高性能与高可靠性的需求，决定了电信等行业应用逐渐向集中型的业务平台模式转变，系统也最终采用了动态均衡的服务集群架构；而支持浏览器用户环境则决定了产品的B/S多层架构。同时，从软件构架的层次结构角度来看，不同层受各类需求影响是完全不一样的：9应用层受功能性需求的影响最大9业务实体层本质上由业务领域模型所决定9业务逻辑层具体的内容受功能需求影响，但其基本结构对功能不敏感9数据访问层等下层架构基本上由非功能需求因素决定，与功能性需求关系不大 需求状态的变化在需求获取、分析、处理、验证阶段，我们已经得到了获得用户和项目组达成共识的需求，并且，已经建立了需求数据库，建立了需求基线。从需求实现阶段来看，需求在这个阶段，仍然受各种因素的影响，产生不可预料的变化。状态定义被建议根据需求来源，责任、相关人提出了需求。被拒绝在一系列需求开发过程后，该需求没有被认可。被批准在需求（特别是变更需求）被分析，评估了合理、可行、成本、影响等要素，被确认可接受，被标注了新的版本号、给出了新的标号等需求属性、被加入到需求基线库中，进入实现过程。被实现已实现设计、编码、单元测试。被验证根据验收标准，已经通过集成以上的测试，被验证实现了需求的要求，被放置进配置基线库。表明需求已经被实现。被丢弃被批准的需求已从基线库中被丢弃。记录下丢弃的原因和决定责任人。被交付通过用户的验收测试，需求以交付物的形式，向用户提交。 需求实现过程——需求状态变化开始设计完成评审集成测试编码完成用户测通过完成单元测试试接收被验证被建议被批准被实现被交付评审未通过取消取消被拒绝被丢弃在需求状态的变化中，软件项目经理第一位需要关注的是那些被拒绝、被丢弃的需求。因为如果不是通过有管理的处理过程，这些需求有可能是应该被接受、并被实现的需求，而成为系统的疏忽而遗漏？项目经理也应该关注被交付的需求，因为作为项目经理，他的主要责任是项目阶段的里程碑控制。项目阶段里程碑是应交付成果，交付成果最主要的内容，就是需求的实现。（其他的交付物还有：文档、培训、服务等）。 需求状态变化的追踪如果我们能够做到软件需求的定义，那么，通过跟踪定义了的需求，我们就能够知道需求在实现过程中的具体实现细节与目标的距离。在可追踪的需求实现过程中，项目经理才能够有把握地说，需求被正确地实现了。 需求实现过程的追踪需求追踪可以在用户需求与系统实现之间追溯和回溯，也可以在系统内部的层次和模块之间追溯和回溯。从用户需求，到具体模块的实现，建立了一条需求追踪链。需求追踪链的源头是用户需求，链的尾端是项目组实现的产品——模块（组件）。建立需求追踪链的前提条件，是必须统一地标识每一个需求，也就是前面我们讲到的，需求的形式化。 需求追踪的步骤建立需求跟踪链：（1）从涉众需求到产品特性（2）从产品特性到用例（3）从用例到实现用例（4）从用例到测试用例涉众需求产品特性补充需求用例用例实现测试用例测试用例 需求追踪链（1）：从涉众需求到特性业务需求需求特需求子特性业务描述操作描述性客户访问系系统的电话接受电话访问在语音提示下，进行自动统的方式接入方应答，提供信息和咨询服式务。FAX接受传真访问自动为授权用户回复传真E_mail接受mail根据用户填写的信息要求，自动回复相应的mail。Web接受网上访问提供网上交互服务。公司内部的系统响自动应答模电话、传真、同上系统处理模应模式式MAIL、WEB自式动应答电话转人工应客户根据需要，在语音提答示下，转人工坐席应答模式。人工坐席模一般坐席一般业务人员处理式高级坐席高级咨询顾问处理 系统服务内可响应产品服务自动查询回自动回复有关产品资料容并提供复的服务人工咨询服提供产品介绍和方案建内容务议与产品方案库的接口定单处理接受定单进入定单处理合同洽谈转人工合同洽谈合同处理合同修改转人工合同修改查询合同查询合同处理状态／与合同管理的接口售后服务报修服务记录保修内容，转处理质量投诉记录投诉内容，转处理系统信息构系统处接入24条中继接统一客户服务号码，24成理结构入线排队机自动排队机自动根据坐席忙闲和服制务等级，分配人工响应的坐席。自动坐席根据业务自根据服务请求，自动切动提供画面换到相应内容的处理画信息面和信息。数据库联提供背景数根据服务请求，自动显接据示相应背景信息，如：客户资料、产品信息、备选方案等。 需求追踪链（2）：从需求特性到用例采用需求追踪矩阵的办法，来跟踪需求的实现，是需求追踪链的具体化。本质上，它是需求实现路径的展开。用例功能需求特性增加用户修改用户终止用户注销用户用户单位属性采用选择〆〆系统属性定义表中属性用户属性可批量修改〆〆〆用户属性检查范围可采〆〆〆用剔除法用户属性统计可按指定〆方法 需求追踪链（3）：从用例到实现用例、测试用例用例参与类子类/对象实现组件单元测试Ucase0021查询Check0021Check0021( )插入Insert0031Insert0031()这张表表明，每一个用例，最终将对应一个和多个测试用例。而中间过程可能有很多设计和实现阶段和层次。中间过程和中间结果在设计阶段，可能是数据库表项、数据字典、流程图、活动图、关系图、类定义等。在代码实现阶段，就是源代码。测试阶段，就是单元/集成测试用例和实际测试报告。 需求追踪链（4）：从用例到测试用例根据用例的事件流分析，针对用例情景，产生系统测试用例。用例编描述灯的预期结果号状态基本流：住户按下按扭的时1开关开关并记忆亮度间小于1秒基本流：住户按下按扭的时2关按记忆亮度开间小于1秒其他流：住户按下按扭的时3亮度按10%/秒速度上升达开间大于1秒到最大后下降并循环其他流：住户按下按扭的时4关先开，然后再同上循环间大于1秒其他流：住户按下按扭的时5开停在当时的亮度位置间大于1秒后松开了开关其他流：住户按下按扭的时6关停在当时的亮度位置间大于1秒后松开了开关 需求实现——需求追踪能力‡如果项目开发的文档化、形式化做的不够，需求追踪链存在于工程师的头脑中，则需求追踪是没有保证的。‡同时，需求追踪强调的是沿需求实现路径的追踪，而不是仅仅检查点与点之间的对应（功能测试），因此，建立完善的需求实现过程的记录，是实现需求追踪的关键。‡现在，有一些需求管理工具，可以帮助进行需求追踪。小结：在需求实现阶段，需求管理的工作要点归纳起来，就是以下几个方面：（1）需求要尽量形式化、数据库化；（2）在需求形式化的基础上，建立需求追踪矩阵，对需求实现，进行追溯和回溯；（3）需求追踪能力的好坏，是软件需求管理水平的标志。 34. 需求变更管理¾ 需求变更管理的重要性¾ 需求变更控制活动¾ 需求变更波及分析¾ 需求稳定性评估 需求变更管理的重要性需求变更的原因多种多样，但管理变更，应确立以下原则：（1）认识到变更是不可避免的，为变更指定计划；（2）确定需求基线；（3）建立控制变更的唯一渠道（4）使用变更控制系统来控制变更过程；（5）分层次地管理变更。时间紧迫压缩需求过程产品不满足需求项目资源恶化维护工作量增加变更需求需求过程的恶性循环 需求变更控制活动6大需求变更控制活动（1）确定需求变更控制过程：确定需求变更的选择、分析、决策、记录的过程，所有需求的变更，都要在选择、分析、决策、记录环节上，受到机制和责任的保证。（2）建立需求变更控制委员会：组织公司、项目组内部和用户利益和风险承担人员，成立需求变更控制委员会，由他们来决定要变更哪些需求，是否在项目范围之内（包括：项目范围和合同范围。因为有时，在项目范围，但不在合同范围，需要项目进行二期合同开发），评估变更的波及，最后决定变更是可以接受，还是放弃。对变更的需求设置优先级、制定版本规定等。 需求变更——6大需求变更控制活动（3）进行需求变更影响分析：波及分析有利于对需求变更要求，进行更深入、精确的理解，帮助变更控制委员会做出科学的决策。波及分析还可以帮助项目组对现有系统做出合理的、有前瞻性的调整，使面对日后新的需求变更，有充足的技术准备。波及分析完全依赖于需求的跟踪能力。没有需求形式化记录、没有需求跟踪链，就没有波及分析的可能。如果有，也是主观的、非定量的。由此对项目计划、成本、质量控制的影响分析，其可信度是有疑问的。系统分析师和架构师应评估变更对系统技术实现的影响。项目经理应根据新需求，明确相关任务，评估新的工作量和相应的要求变化。新需求不但导致分析、编码、测试的工作量增加，项目管理有关的各环节（需求管理、计划管理、成本管理、配置管理、质量管理等）都会有所变化。在需求变更评估分析中，也要做需求稳定性评估。频繁地需求变更，应该超出了需求变化的范围。项目经理要考虑项目组织管理方面，是不是发生了什么问题。 需求变更——6大需求变更控制活动（4）跟踪所有受需求变更影响的工作产品：当确定某一需求发生变更时，根据需求跟踪矩阵，找到与变更需求有关的各层、各环节需求项。例如：涉及需求项的设计模型、代码模块、测试用例等。这些部分全部必须做相应的修改。依据需求跟踪矩阵，可以完整地追踪到需求变更所影响到的所有地方，可以不会发生遗漏，而产生系统BUG，或产品缺陷。甚至包括对软件产品本身以外的影响，如：因需求变更，版本控制没有相应的记录、产品使用手册没有做相应修改等。因为需求变更，需求状态记录应相应地发生变化。每一条记录，反映了需求的现实情况。（5）调整需求基线：需求变化以后，需求变更控制委员会要决定是否调整需求基线。新需求是反映为基线的调整，还是版本的变化。基线是产品的标准，基线变化可以作为产品标准的变化，也可以理解为将发行一个新版本的产品。 需求变更——6大需求变更控制活动但是，版本并不一定就是新产品。因为，当产品面对不同地区、不同用户群的时候，也可以确定不同的版本。因此，需求变更控制委员会要做的工作，是对新需求，决定是全面升版，还是局部更改。是基线变化，还是个别版本变化。有时，这是一个比较难于做出的决定，他依赖于对新需求的分析，评估它对市场、用户和产品本身的影响。（6）维护需求变更记录和文档：决定变更基线或提升版本以后，就要做好记录，修改相应的文档。变更记录要记录变更原因、变更内容、变更影响、变更实现过程、其他相应变更等。变更记录越完整，对于追溯，甚至以后可能发生的回退，就越有帮助。有一些版本控制工具，可以帮助项目经理来做到记录相应的信息。 需求变更波及分析变更波及分析的意义对于项目组来说，一个新的需求提出来以后，这个需求如果接受，可能对系统造成多大的影响？系统结构上的、数据结构上的、涉及的模块、版本上的变更影响有多大？需求波动在技术上有潜伏性，在工程上，也表现为不可预知性。工作量不可预知、成本不可预知。项目经理往往受市场人员的压力，对用户宣称“免费维护”，但在项目组内部，对于需求变更的成本，甚至可能是“巨大”的。这种不理智的“反差”，正好说明了我们软件项目管理的水平，是处在原始和粗放的状态。需求波及分析是软件项目管理的需求管理比较重要的组成部分，在需求变更决策前，通过波及分析，可以达到精确理解需求、评估系统对需求变更要求的接纳程度、变更的代价、变更对系统总体架构、甚至产品发展的影响等。这样的分析，对需求变更委员会做出变更批准还是放弃的决策，具有重要的意义。一旦变更控制委员会批准需求变更的要求，就能比较清晰地知道相应变更的内容、工作范围、需要的时间等。需求变更波及分析也是保证项目组在需求变更以后，可以做到“在计划、成本、质量（不是降低质量标准为代价）范围的变更”。 需求变更——变更波及的内部分析系统元素波及分析包括：（1）所有涉及到的输入界面有关部分；（2）所有涉及到的报表等输出界面有关部分；（3）所有涉及到的外部接口部分；（4）所有涉及到的内部接口部分；（5）所有涉及到的数据库表结构；（6）所有涉及到的系统数据定义；（7）所有涉及到的公用模块定义、公用子程序库、控件库；（8）所有涉及到的系统常量、宏定义；（9）所有涉及到的已经实现的代码；（10）所有涉及到的已经完成的单元、集成测试；（11）所有涉及到的已经编写完成的用户文档（使用手册、维护手册）；（12）所有涉及到的已经编写完成的帮助文件、培训教材；（13）所有涉及到的第三方软件和工具；（14）所有涉及到的项目管理有关的需求管理、计划管理、成本管理、配置管理、质量管理有关的数据库、文档库；（15）所有涉及到的其他应该检查的部分；（16）所有涉及到的………。 需求变更——变更波及的外部分析（1）变更是否与基线（已经实现的部分）相冲突（是否是基线内的）；（2）变更是否存在与虽未实现，但已经决定的需求相冲突；（3）不采纳变更是否会有技术上的风险，或者采纳变更会有什么技术上的风险；（4）不采纳变更是否会有业务上的风险，或者采纳变更会有什么业务上的风险；（5）不采纳变更是否会导致质量降低，或者采纳变更会有多大的质量提升；（6）变更在技术实现上是可行的吗？（7）采纳变更是否会导致用户进一步提出更多不合理的要求？（8）采纳变更对现有项目组在人力、技术、工具等方面，是否能够承受，增加资源是否可能；（9）采纳变更的需求变更量的估计是多少？（以单元为单位、以时间为单位、以成本为单位）（10）采纳变更后，虽然进行了合理安排，包括采用关键路径法，调整进度安排，但最后仍然对进度的影响是多少？（11）采纳变更以后使多少实际已经开发完成的单元被废弃，相关的工作量是多少？（12）采纳变更以后使多少实际已经开发所用的单元时间被浪费，相关的比率是多少？（13）变更对市场、销售、培训、维护的影响有多大？ 需求变更——需求变更波及分析报告标题：变更描述：分析人日期：优先级评定：相关收益：相关代价：相关成本：相关风险：增加耗时：增加人力：对进度的影响：对成本的影响：对质量的影响：直接影响的其他部分：间接影响的其他部分：导致的计划变更：导致的成本变更：其他影响：假定前提：条件与约束：评审人意见： 需求稳定性评估为了了解需求的稳定性情况，可以对需求的稳定性，进行评估。评估的基本过程是：（1）统计基线需求的数量：通过需求数据库，可以按最底层的需求项为单位，统计需求的数量。因为任何上层需求的变化，最终要反映到最底层需求项的变化。比较差的设计，可能使简单的需求变化，带来巨大的系统元素的修改。（2）统计每月/每周基线需求项的增加、删除、修改的数量。如同需求基线一样，根据项目的大小和历史经验，项目经理也要定一个稳定性基线，当需求变化量在一定时间内超过了稳定性基线，项目经理就要分析原因，采取措施。（3）需求变化既可能来自组织外部，也可能来自项目组内部。对需求不稳定的因素和来源进行分析，做出的评估，是获得需求稳定的好办法。这一点，将在以后《配置管理》和《质量管理》中，再做详细讨论。对需求稳定性的关注，是软件项目经理经常需要做的工作。需求不稳定，是项目组的“危险警报”。轻则是项目组工作量的增大，重则可能导致项目的严重延误，甚至失败。 现代软件工程需求管理的关键要点需求开发阶段9业务模型/用例诱导9分析模型9需求形式化9需求评审需求实现阶段9需求分解与需求分配9需求基线化与状态控制9需求可追溯与可跟踪9需求波动分析与需求稳定性评估9需求过程中的质量评估与控制 通过软件需求管理实现项目的范围管理„项目的范围——软件需求、需求控制过程„项目的范围管理——需求定义和用户确认、控制„范围管理的过程——项目启动、范围计划编制、范围定义、范围确认、范围变更控制„WBS结构——需求树„范围确认——需求获取阶段的用户确认，需求确认阶段的内部需求评审„范围变更控制系统——需求基线、需求追踪链、需求状态控制、需求波动分析与稳定性评估 第三部分软件项目的规划 第三部分•目录项目的计划编制与管理项目的成本预算与管理 项目的质量目标与管理 项目的风险分析与管理 项目的计划编制与管理§项 目时间管理的基本问题§如 何制作项目进度计划§如 何做好项目的进度控制§ 的主要工具和技术§项 .5 目进度管理的问题探讨 §. 项目时间管理的基本问题项目计划与时间管理：‡项目进度计划是根据项目的目标，在项目确定的范围内、依据确定的需求和质量标准、并在项目成本预算许可下，制定出的一个周密的项目活动安排。‡项目时间管理是在项目的执行和实施过程中，根据进度计划，检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成的过程。 项目经理的时间管理‡项目进度计划是项目最基本的控制工具‡项目经理最主要的工作，就是制定项目计划，并根据项目计划，安排任务、监督实施、考察进度，识别项目进度方面存在的风险与偏差。‡对不适应计划进度要求的情况，及时进行调整。‡时间是最主要的进度、成本、质量考核依据‡项目计划是组织考核项目经理工作的主要依据。‡计划既是组织对项目组和项目经理实行目标管理和目标考核依据，也是过程控制的依据。项目阶段里程碑的达到与否，是最简单、最直接的检查标准。‡进度延误是项目的最主要问题 为什么要制定一份项目计划？（1）通过制定计划，可以使得项目组和有关管理人员，对项目有关事项，如资源配备、风险化解、人员安排、时间进度、内外接口等形成共识，形成事先约定，避免事后争吵不清；（2）通过计划，可以使得一些支持性工作以及并行工作及时得到安排，避免因计划不周造成各子流程之间的相互牵掣。比如测试工具的研发，人员的培训都是需要及早计划和安排的；（3）可以使项目实施人员明确自己的职责，便于自我管理和自我激励； 为什么要制定一份项目计划？（4）计划可以有效的支持管理，并作为项目经理、业务经理、技术经理、QA经理、测试经理、配置经理对开发工作跟踪和检查的依据；（5）做好事先计划，就可以使注意力专心于解决问题，而不会去想下一步做什么？（6）计划是项目总结的依据之一，项目总结其实就是把实际运行情况与项目计划不断比较，以提炼经验教训的过程。通过计划和总结，项目过程中的经验和教训会获得很好的记录和升华，成为“知识的沉淀，组织的财富”。 项目计划的类型‡项目计划的类型‡项目计划的类型有：总体计划、里程碑计划、实施与进度计划等。‡项目的总体计划应由项目经理的上一级高层经理、大型的项目，甚至需要组织的一个审核委员会来批准。‡一般地，项目的里程碑计划会作为项目合同的附件，因此，签订项目合同时，用户方也会审查项目的计划。‡不同的项目干系人，对项目计划的关注点是不同的：‡作为用户方，所关注的要点是项目的时间进度和交付成果‡作为开发方会，所关注的要点是项目计划的合理性、可行性，更重要的是检查、并承诺项目所需要的资源是否能够保证获得满足。例如：采购到货日期、人力资源、开发设备和环境保障等。 项目实施与进度计划‡项目的全局目标需要用更加简短的期间目标明确表明，并且通过精心策划的计划、进度和预算等来完成。然后实施控制以确保计划和进度按照预期付诸实施。‡项目的实施计划表现为整个项目实施的所有步骤，包括项目管理的各个方面。涉及到要制订完成的目标及其相应的工作，以及怎样为保证工作的实施提供相应的领导支持和指导。其中包括进度计划和成本预算、成本管理计划与风险管理计划等。‡项目进度计划就是根据项目实施具体的日程安排，规划整个工作进展。也把它称为项目初步计划、详细计划或者整体计划和子计划等等。 谁来制定、何时制定项目计划？‡在项目进入到合同签订，正式展开需求获取和分析阶段以后，项目的具体目标和要求将开始逐步了解清楚，在开始建立项目的详细计划（WBS）前，可以先建立项目的里程碑计划。‡里程碑计划一般由项目经理亲自制定。‡里程碑计划是非常粗的WBS计划。在后续阶段，项目经理应根据里程碑计划进行细化，形成WBS计划。‡如果项目的规模较大（例如软件项目组成员超过30人），那么项目经理将工作任务分解到合适的“粒度”并分发给相应的小组，再由小组制订自己的详细计划，项目经理汇总所有小组的详细计划，形成项目的整体WBS计划。 § 如何制作项目进度计划项目进度计划的基本内容：内容：项目进度至少应该包括每项工作的计划开始日期和期望完成的日期，明确确定开始和结束时间的前提，是每项工作所需的资源已被分配。形式：项目进度可以以提要的形式（称为主进度）或者以详细描述的形式表示，尽管项目进度可以表示为表格的形式，但是更常用的却是以多种形式的图形方式加以描述，图形描述常常直观易懂。 项目进度计划项目计划制定程序计划资源获取计划实施计划运行和维护计划确认和验证计划资源选择计划部署计划 项目进度的表达形式（1）——里程碑事件里程碑事件一二月三月四月五月六月七月八月月转包签订▲计划书完成▲设计检查▲子系统测试▲▲单元实现计划完成▲ 项目进度的表达形式（2）提出初步的项目申请——里程碑图组织层最后的预提出预算要技术方案评审算草案求最后的草案评项目管理层财务估算评审审第2阶段设计文档执行层第1阶段设计组合的设计文最后的技术草文档档案十月十一月十二月注: 每一个方块代表一个重要的里程碑；也就是，表示一项或多项任务（在此未画出）被安排在此完成的一个特殊的时间点。 项目进度的表达形式（3）——时间坐标网络图 项目进度的表达形式（4）——带有日历的项目网络图 项目进度的表达形式（5）——条形图或甘特图 项目进度的表达形式—项目任务表（6） 项目进度的表达形式（7）——项目行动计划表递送：完成措施：关键约束条件和假设：任务估计资源前期任务估计持续时间责任人 项目技术实施（硬件）计划里程序工作内容碑描开完备注责任配合号述始成1项目正式启动提交系统解决方案系统解决方案修改、确认详细设计（IP地址规划）2环境平台提交《机房环境条件表》准备机房安装环境3系统安装交货验收设备安装调试系统调试提交测试大纲系统测试 系统割接4提交割接计划割接计划确认、修改割接系统验收提交竣工文档系统验收签署系统验收报告培训制定培训计划编制培训材料使用人员培训维护人员培训审批拟制 ‡项目管理流程项目管理文档参考（1）立项立项作业流程立项申请表销售立项作业指导书（2）合同评审合同评审表合同变更表合同评审作业指导书（3）项目计划与成本预算工程实施计划项目实施预算（4）软件开发内部规范 ‡（5）工程实施安排项目管理文档参考项目实施分工项目执行通知书工程进度周报（6）项目跟踪分析项目阶段分析报告项目跟踪分析作业指导书（7）工程验收工程验收报告工程维护报告工程实施与维护作业指导书（8）项目回款回款通知书付款通知书 § 如何做好项目的进度控制‡明确项目控制的目的‡加强来自各方面的综合、协调和督促‡要建立项目管理信息制度‡项目主管应及时向领导汇报工作执行情况，也应定期向客户报告，并随时向各职能部门介绍整个项目的进程‡项目控制包括对未来情况的预测、对当时情况的衡量、预测情况和当时情况的比较，以及及时制定实现目标、进度或预算的修正方案‡难点‡IT或软件项目的不确定性‡项目内容的隐蔽性与分散性‡计划与变化的关系‡培养按计划工作的习惯‡项目经理的权力 制定基准计划项目控制的流程（进度、预算）开始项目等待，进入下一个报告期每个报告期内收集实际进程数据将变化列入项目计划（进度、成本）（范围、进度、预算）计算出变更后的项目进度、预算和预测分析当前状况并与计划比较（进度、预算）需采取纠正措施吗？识别纠正措施和协调相关变化 项目控制手段和工具可视化图表工具：„重要的关系控制手段：„里程碑图•制定并遵守计划„甘特图•不断监督„费用成本曲线•必要时进行调整„资源负荷图„项目成本记录•沟通„工作绩效图•团队工作„项目报告表 项目进度控制的类型（1）——活动控制‡活动控制就是采取一定措施，保证每一项活动本身按计划完成。‡活动控制是以工作分解结构WBS的具体目标为基础的，也是针对具体的工作环节的。‡通过对每项活动作业的质量检查，以及对其进展情况进行监控，以期发现活动正在按计划进行还是存在缺陷，然后由项目管理部门下达指令，调整或重新安排存在缺陷的作业，以保证其不致影响整个项目工作的进行。 项目进度控制的类型（2）——进度控制„项目进度控制是一种循环的例行性活动。其活动分为四个阶段：编制计划、实施计划、检查与调整计划、分析与总结。 项目进度控制的类型（2）——进度控制‰按照不同管理层次对进度控制的要求分为三类：‰项目总进度控制：项目经理或高层管理部门对项目中各里程碑事件的进度控制‰项目主进度控制：主要是项目经理对项目中每一主要事件的进度控制。在多级项目中，这些事件可能就是各个分项目。‰项目详细进度控制：主要是各业务单元对各具体作业进度计划的控制，这是进度控制的基础。‰项目控制主要解决的问题是克服脱期，但实际进度与计划不符的情况还有另外一种，即工作的过早完成。一般来说，这是有益无害的，但在有些特定情况下，某项工作的过早完成会造成资金、资源流向问题，或支付过多的利息。 项目执行信息的收集‰在整个报告期内，需要收集两种数据或信息：‰实际执行的数据，包括活动开始或结束的实际时间；使用或投入的实际资源和成本等；‰有关项目范围、进度计划和预算的变更信息。 信息数据收集的五种方法i.发生概率统计法：即对某一事件发生的次数进行记录的信息收集方法，主要用于：延误报告次数、无事故天数、运行故障次数等。ii.原始数据记录法：这是对项目中实际资源投入量和项目产出技术指标进行统计。iii.经验法：这类指标的定量或定级来源于人的主观意志。指标法：对一些较难或者甚至无法直接获得的对象的有关信息，寻找一种间接的度量或指标。v.口头测定方式：这种方式常用于测定队员的合作质量、队员士气高低、项目主和业主间合作程度等。 项目进展报告i.项目进展简介：列出有关重要事项。对每一个事项，叙述近期的成绩、完成的里程碑以及其它一些对项目有重大影响的事件（如采购、人事、业主等）。ii.项目近期趋势：叙述从现在到下次报告期间将要发生的事件。对每个将要发生的事件进行简单说明。并提供一份下一期的里程碑图表。iii.预算情况：一般以清晰、直观的图表反映项目近期的预算情况，并对重大的偏差做出解释。困难与危机:困难是指你力所不能及的事情，危机是指对项目造成重大险情的事,同时可提出高层管理人员支持的要求。v.人、事表扬 项目进展报告的形式i.日常报告：日常报告是为报告有规律的信息，按里程碑时间安排报告时间，有时根据资源利用期限发出日常报告，也有时每周甚至每日提供报告；ii.例外报告：此种报告的方式用在为项目管理决策提供信息报告；iii.特别分析报告：常用于宣传项目特别研究成果或是对项目实施中发生一些问题进行特别评述。 各种项目进度控制报表——关键点检查报告关键点名称：检查组名称：检查组负责人：报告人：报告日期：报告份数：对关键点的目标描述关键点结束时间与计划时间相比提交物是否能满足性能要求估计项目以后发展态势检查组负责人的审核意见：签名：日期 项目执行状态报告任务名称任务编码报告日期状态报告份数实际进度与计划进度相比投入工作时间加未完成工作的计划时间和计划总时间相比提交物是否能满足性能要求任务能否按时完成现在人员配备状况现在技术状况任务完成估测潜在的风险分析及建议任务负责人审核意见：签名：日期 任务完成报告任务名称及编码：结束日期：交付物的性能特点：实际工作时间和计划时间相比：实际成本和估计费用相比：实施过程中遇到的重大技术问题及解决办法：评审意见：评审人：日期：紧后工作名称及编码：紧后工作计划及措施：项目负责人审核意见：签名：日期： 重大突发性事件的报告事件发生的时间：事件发生的部位：突发性事件的描述：对项目正常实施影响的程度：事件发生的初步原因分析：建议采取的补救措施：项目负责人审核意见：签名：日期： 项目变更申请报告项目名称：项目负责人：项目变更的原因：项目变更替代方案描述：估计项目变更后对总项目进度的影响：变更时所涉及到的相关单位：项目负责人的审查意见：签名：日期：上级项目主管部门的审查意见：签名：日期： 项目进度报告项目进度报告姓名：项目名称：本周结束日期：关键问题是否任务范围有变化吗？超过目标日期了吗？估算有问题吗？有技术问题吗？有评审问题吗？对跟踪项目的解释：下一周任务计划：问题和办法：评审人/日期：完成人：日期： 项目管理报告项目管理报告:项目号:项目名称:报告日期:项目经理:项目报告数:是否状态总结1．实际进度超过10%吗？2．已投入工作时间加未完成工作的计划时间超计划时间的10%吗？3．完成任务的数量超计划的10%吗？4．交付物能满足性能要求吗？5．项目能按时交货吗？6．满足用户的要求吗？7．与用户的关系被接受了吗？8．附上职员工作总结、资源计划总结、累积完成任务总结报告吗？人员配备状况:技术状况:任务完成估测:附上的用户进度报告:编号:审批项目经理 : 日期:管理人: 日期: § PMBOK的主要工具和技术‡关键线路法CPM：‡关键线路法是可以确定出项目各工作最早、最迟开始和结束时间，通过最早最迟时间的差额，可以分析每一工作相对时间紧迫程度及工作的重要程度。‡这种最早和最迟时间的差额称为机动时间，机动时间为零的工作通常称为关键工作。‡关键线路法的主要目的就是确定项目中的关键工作，以保证实施过程中能重点关照，保证项目按期完成。‡计划评审技术PERT：‡PERT的形式与CPM网络计划基本相同，只是在工作延续时间方面CPM仅需要一个确定的工作时间，而PERT需要工作的三个时间估计。‡即包括最短时间a、最可能时间m及最长时间b，然后按照β分布计算工作的期望时间t。‡PERT的某一具体时间的计算方法，也是CPM方法。 前导图PDM的单代号网络计划PDM是一种用节点表示工作、箭线表示工作关系的项目网络图，这种网络图通常也被称为单代号网络（简称AON）。这种方法是大多数项目管理软件包所使用的方法。ACE开始结束BDF 某产品市场研究项目的单代号网络图 基于MDP网络图的关键路线法技术‡关键路线法（Critical Path Method，CPM）‡关键路线法是项目时间管理中的最常用技术，是以PDM单代号网络图为基础的计划模型。‡它是把完成任务需要进行的工作进行分解，估计每个任务的工期，然后在任务间建立相关性，形成一个“网络”，通过网络计算，找到最长的路线（主要矛盾），再进行优化的计划方法。‡关键路线法技术的最基本的优点，就是运用最优化原理，去揭示整个计划的关键任务，以及巧妙地安排计划中的关键工作，从而使计划管理人员依照执行的情况信息，有科学根据地对未来做出预测，使得计划自始自终在人们的监督和控制之中，达到以最短的工期、最少的资源、最好的流程、最低的成本来完成所控制的项目。 基于MDP网络图的关键路线法CPM技术‡关键线路法CPM的优化策略是，通过确定出项目各工作最早、最迟开始和结束时间，计算出最早最迟时间的时间差，依据时间差，可以分析出每一工作相对时间紧迫程度及工作的重要程度。‡这种最早和最迟时间的差，称为机动时间，机动时间为零的工作通常称为关键工作，由关键工作组成的工作路线，称为关键路线。‡关键线路法的主要目的，就是确定项目中关键路线上的关键工作，以保证实施过程中能重点关照，保证项目按期完成。而自由时间则表示可调节的空间。 基于MDP网络图的关键路线法CPM技术现在，我们先来学习CPM的计算方法。在准备进行CPM计算之前，我们准备了以下一张任务描述表。它是我们在建立WBS、估算了任务完成时间之后获得的。任务编任务名称紧前工作工作延续责任人码（天）1练习剧本5张三2制作服装10李四3制作道具4王五4彩排1、2、32张三项目经理审核意见 最早、最迟时间参数计算示例最早开始时间SE、最早结束时间FE 机动时间（时间差）的参数计算„最早开始时间SE„最早结束时间FE„最迟开始时间SL„最迟结束时间FL„最早开始时间SEES＝MAX{紧前工作的EF}„最早结束时间FEEF＝ES＋工作延续时间t 最早、最迟时间计算示例 最早、最迟时间参数计算（练习）B 2 8EA 3C 7F 6G 5 代号时间示例：D 4 最早开始、结束时间计算10 183 5B 2 8E0 318 233 1010 16A 3C 7F 6G 5 3 7代号时间示例：D 4答案：最早完工时间为23天 最迟时间参数计算„最迟结束时间LFFL＝MIN{紧后工作的SL}„最迟开始时间LSSL＝LF—工作延续时间t 最迟时间参数计算（练习）B 2 8EA 3C 7F 6G 5 代号时间示例：D 4要求完工时间为23天 最早/迟时间参数计算(练习)3 510 18B 2 8E8 1010 180 318 233 1010 16A 3C 7F 6G 5 0 33 1012 1818 233 7代号时间示例：D 4要求完工时间为23天8 12 最早开始结束时间概念清理‰从前往后——最早（ES、EF）序号工期开始结束‰从后往前——最迟（SL、FL）最迟‰左角都是开始时间、右角都是结束时间‰最早开始—SE—多个前项工作的最大最早结束时间、起点为0‰最早结束—FE—最早开始+工期‰最迟结束LF——多个后续工作中最小最迟开始时间，起点为给定的一个要求完工期‰最迟开始LS——最迟结束-工期 时差（机动时间）的概念‰机动时间：每个活动的时间差‰时差（机动时间）的计算时差＝LF—EF或时差＝LS—ES机动时间，又称为自由浮动时间（Free Float） 机动时间计算练习3 5510 180B 2 8E8 1010 1800 3018 2310 1623 100A 3C 7F 6G 5 0 33 1012 1818 2353 7代号时间示例：D 4要求完工时间为23天8 12 机动时间计算的应用——关键路线‰时间差可以帮助我们分析每一工作相对时间紧迫程度及工作的重要程度。‰我们把最早和最迟时间的差额称为机动时间，机动时间为零的工作通常称为关键工作。‰当一个任务的时间差大于0的时候，说明实际开始时间早于最迟开始时间，在时间安排上，存在“富余时间”。当时间差为0时，表明没有富余，当小于0 时，说明已经存在延误。‰因此，CPM通过找到关键工作，确定关键线路，其主要目的就是确定项目中的关键路线上的关键工作，以保证实施过程中，能得到重点关照，保证项目按期完成。‰上例中的A-C-E-G是关键路径。 项目进度的PERT分析‡计划评审技术PERT（Program Evaluation an Review Technique ）是50年代末美国海军部开发北极星潜艇系统时，为协调3000多个承包商和研究机构而开发的，其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。‡PERT可以估计整个项目在某个时间内完成的概率，PERT与CPM一样，在项目的进度规划中应用非常广。‡PERT的形式与CPM网络计划基本相同，只是在工作延续时间方面，CPM仅需要一个确定的工作时间，而PERT需要工作的三个时间估计，包括最短时间O、最可能时间M及最长时间P，然后按照β分布计算工作的期望时间t。 TREP工作时间的分布与计算PERT对各个项目活动的完成时间按三种不同情况估计：O：乐观时间（tpoimitsic time）--任何事情都顺利的情况，完成某项工作的时间。M：最可能时间（mtso likely time）--正常情况下，完成某项工作的时间。P：悲观时间（epissmitsic time）--最不利的情况，完成某项工作的时间。假定三个估计服从=Tβ分布，由此可算（P4+MO+/)6出每个活动的期望T：T=（P4+MO+/)6 完成时间概率的计算PERT的另一个突出特点，就是计算项目在特定时间范围内完成的概率：我们用以下例子，来介绍计算完成任务时间概率：2，3，64，6，83，4，6问题：项目（K+JL+）在天内完成乐观估计，最可能估计，悲观估计的概率是多少？活动编码首先我们定义几个PERT值：均值，又称为平均历时=t（O+M4+P）6/标准差σ=（O-P）6/方差=[（O-P）2]6/ 完成时间概率的计算根据给定的条件，活动的各值计算如下表所示：均值（平均历时）标准差方差O，M，P（4+PO+M）/6（P-O）/6[（P-O）/6]2J2，3， 完成时间概率的计算如果要问：项目在天完成的概率是多少，则：（1）在均值（天）完成的概率是50%；（2）天=均值（天）+1个标准差（天）（3）天的概率是50%+（%/2）5=03+%=%.13%一个简单的计算方法：例题：某项工作悲观估计需要36天完成，最可能21天完成，乐观估计只用6天完成，那么该项工作在16天到26天之间完成的可能性是多少？A、% B、% C、% D、%（1）计算均值：t=（36+4*21+6）/6=21（天）（2）计算标准差σ=（P-O）/（=63-6）6/6=5（天）（3）以21天为均值，5天为一个标准差，16-26天是在1个标准差时间内，所以，答案是B、% PMBOK的时间进度调整方法‡在项目执行过程中，经常出现到项目的某一里程碑或报告期时，项目的进度晚于计划进度、已经发生的实际成本高于计划成本，这时都需要对计划进行相应的调整。‡如果发现项目的进度计划或预算计划需要调整，首先检查以下三方面：‡对近期即将发生的活动加强控制，积极挽回时间和成本——加快节律；‡对工期估计最长或预算估计最大的活动，应进一步审核预估依据，并做好压缩该活动时间和费用的准备工作，因为估计值越大的项目越有压缩的可能——在计划上找机会；‡将某些可以再划分的活动进一步细分，研究细分活动之间可以并行工作或知识重用的可行性——串行改并行。 项目持续时间压缩法‡持续时间压缩是对进度计划进行数学分析的一种特殊情况，即寻找在不改变项目范围的条件下，缩短项目持续时间的途径。‡持续时间压缩的技术有：‡赶工：对费用和进度进行权衡，确定如何通过增加费用的方法，如：增加人手和加班，来使项目总工期压缩最大。一般来说，赶工总是会导致费用增加。‡快速跟进：将一般情况下多项先后顺序实施的活动，改为并行实施。快速跟进有可能导致平行活动的相互干扰、资源冲突甚至返工，一般会增加风险。 §项目进度管理的问题探讨（2）基本思路：‡不断总结经验，使某些行为规范化、标准化‡业务规范——出差：交通、住宿、补贴‡工作规范——设计、勘探、物流、安装、调试、测试、报告、会议、文档、沟通、联系人等等‡行为规范——工作场所、言谈举止、行为标准‡在规范化的基础上，减少项目的不确定因素‡在规范的、确定的过程中，制订项目计划‡希望不断提高这个部分的比例‡如何提高？‡从头做起（领导、项目启动阶段） 项目进度管理的问题探讨（3）计划管理的基本工作：‡对规范化、标准化的部分，不断完善、精细‡对不确定的部分‡与同类项目比，逐步找到不一致的地方，加以规范化‡与自己前一阶段比，逐步逼近准确（打靶）‡纳入风险管理，在必要的时候，要“叫停”！‡最终使不确定部分的比例，越来越小 课堂练习：我们是一个团队我们有一个10个人左右的团队，成员来自各个方面，现在要一起完成一个任务‡目标：‡团队的所以人，共同拉住一根绳子，形成一个正方形‡条件：‡有一块空地，团队成员都被蒙上眼睛（可以一组参与游戏、另一组观察，然后进行轮换）‡只有一根足够长的绳子，再没有其他的工具‡要求：‡以30分钟为限‡把绳子拉成一个正方形 练习的意义：团队合作的重要性‡项目组是一个集体，项目组有一个共同的目标‡项目组成员来自各个方面，项目的组织者（项目经理）不是靠行政任命获得权威的‡项目的顺利实施依靠周密的计划、步骤、分工和责任‡项目的成功需要项目经理团结项目组所有成员，齐心协力地完成项目的任务反之：‡混乱和无组织的团队、人人都是“老大”的团队，只能浪费时间‡不要急于动手，有时需要冷静的思考和适当的计划 第三部分软件项目的规划 第三部分•目录项目的计划编制与管理项目的成本预算与管理 项目的质量目标与管理 项目的风险分析与管理 项目的成本预算与管理§ 项目成本管理的基本问题§ PMBOK的成本管理过程§ 项目评价的挣得值方法 §.项 目成本管理的基本问题项目的成本可控吗？‡项目的成本控制实在太难，按项目预算几乎是不可能的。‡不可能的理由是：‡需求不确定，因此，项目工期不确定、费用无法控制；‡项目采用的技术先进，技术风险很大，因此，费用无法控制；‡软件开发是一个个人行为，因此，人员的积极性、工作效率、配合情况等，不像其他行业的项目那样，可以准确地预测。因此，工作效率无法确定；‡项目具有独特性，没有历史资料可以借鉴。因此，成本估算带有很大的盲目性。等等。 项目的成本可控吗？‡2004年，南京地区《项目管理成熟度调查》表明：‡是否把成本控制作为一项考核指标，项目成本是否成为项目管理的一个最主要的目标‡项目经理是否有成本的控制权和激励权‡项目的成本控制是否与企业的成本管理的衔接配套‡费用控制权是项目经理实质拥有目标管理责任权的标志，成为度量企业项目管理水平和成熟度的最重要尺度 项目的成本考核因素成本按产生和存在的不同形式可分成固定成本；可变成本；半变动成本；直接成本；间接成本和总成本（又称为全寿命期成本）。与项目有关的成本（1）直接材料成本：（2）直接劳动力成本：（3）项目的实施费用成本：（4）其他直接成本：（5）间接成本（分摊成本）：项目经理应该关注的是项目的直接可控成本 项目成本的界定‡原则：‡总额控制‡指标分解‡动态调节‡明确目标，分清管理责任：‡项目的实施成本‡项目采购成本‡销售费用分摊‡管理成本分摊‡公司成本分摊 项目成本的界定‡项目实施成本范围界定：‡项目的考核期的界定：项目的开始与结束‡项目人员的界定：项目组人员编制预算‡项目考核费用科目和预算单位标准的界定：‡工资成本：‡差旅费用：‡通讯费用：‡其他直接费用： §. PMBOK的成本管理过程 （1）资源计划PMBOK的资源计划制订过程，涉及到在项目的实施过程中，项目需要什么样的资源（人、设备、材料）以及什么时候和需要多少资源，因此，资源计划过程的核心，是提出资源需求。此时，PMBOK并不要求考虑资源的来源、成本和获得的可能性等其他因素。这是资源计划阶段的特点。 资源计划过程的输入‡工作分解结构WBS‡项目工作进度计划‡历史信息：历史信息纪录了先前类似工作使用资源的需求情况，这些资料一般是可以获得的。‡范围陈述：范围陈述包括了项目工作的说明和项目目标，这些应该在项目资源计划的编制过程中加以特别考虑。‡资源安排描述：可能获得什么样质量的资源是项目资源计划所必须掌握的，特别的数量描述和资源水平对于资源安排利用效果是特别重要的。‡组织策略：在资源计划的过程中，还必须考虑组织的政策：人事政策、所提供设备是租赁还是购买等策略。 （2）费用估计„PMBOK的费用估计，指的是预估完成项目各工作所需的资源（人、材料、设备等）的费用近似值„当项目在一定的约束条件下实施时，价格的估计是一项重要的因素„费用估计应该与工作质量的结果相联系。„费用估计过程中，应该考虑各种形式的费用交换，比如：…在多数情况下，延长工作的延续时间通常是与减少工作的直接费用相联系在一起的…相反，追加费用将缩短项目工作的延续时间。…因此，在费用估计的过程中，必须考虑附加的工作对工程期望工期缩短的影响。 费用估计过程的输入„工作分解结构WBS„资源需求计划：即资源计划安排结果„资源价格：为了估算项目各工作的费用，必须知道各种资源的单位价格，包括人员工时费、单位材料的费用、额定的实施费用等。如果某种资源的实际价格不知道，就应该给它的价格作出估计。„工作的延续时间：工作的延续时间将直接影响到项目工作经费的估算，因为它将直接影响分配给它的资源数量。„历史信息：同类项目的历史资料，始终是项目执行过程中可以参考的最有价值的资料，包括项目文件、共用的项目费用估计及项目工作的经验知识等。„会计表格：会计表格说明了各种费用信息项的代码结构，项目费用的估计应与企业的会计统计科目相对应。 费用估计的技术和方法„类比估计法：通常是与原有的类似已执行项目进行类比以估计当期项目的费用„参数模型法：将项目的特征参数作为预测项目费用的数学模型的基本参数。如果模型是依赖于历史信息、模型参数已经量化，则它通常是可靠的。„从下向上的估计法：这种技术通常首先估计各个独立工作的费用，然后再汇总，从下往上估计出整个项目的总费用，这一方法，多用在项目的计划阶段，为项目实施，制订绩效考核标准时，精确估算项目的费用。„从上往下估计法：同上述方法相反，是从上往下逐步估计的，多用在项目的启动阶段，在参考类似已完成项目的情况下，估计新项目（招投标需要）的估计成本。„计算工具的辅助：一般采用项目管理软件及电子表格软件可辅助项目费用的估计。 从下向上的估计法（示意图）从下向上估计法: 从下向上的估计法：这种技术通常首先估计各个独立工作的费用，然后再汇总，从·估计进度下往上估计出整个项目的总费用。·估计资源这一方法，多用在项·估计费用目的计划阶段，为项目实施，制订绩效考核标准时，精确估算项目的费用。工作包 从上往下估计法（示意图）从上向下估计法：从上往下估计法：同上述方法相反，是从上往下逐步估计的，多用在项目的启动阶段。·工作范围在参考类似已完成项目的情况下，估计新项目（招投标需要）的估计·进度目标成本。·费用目标 成本估算的级别‡在项目的生命周期中，成本估算也有级别的不同。‡在项目启动阶段的成本估算，称为项目级成本估算‡在项目计划阶段，在工作任务分解WBS完成以后进行的成本估算，称为WBS级成本估算。‡在有些资料中，把项目级的成本估算（包括：项目目标、范围、假设和条件、成本收益分析和内部收益率等）定义为成本估算‡把WBS级的成本估算，定义为对项目的预算‡成本估算多采用自顶向下的方法，‡WBS级的成本预算多采用自下向上的方法‡不同阶段的估算，精确程度和要求也是不同的‡项目级成本估算粗略、但计算过程快‡WBS级成本估算精确，但计算过程慢 费用估计过程的输出„项目的费用估计：…描述完成项目所需的各种资源的费用，包括：人员成本、实施费用、消耗品与材料，及各种特殊的费用项，如：折扣、费用储备等的影响。费用的表示方法，因项目情况不同而各异。„详细的说明：…费用估计的详细说明应该包括：„工作估计范围描述，通常是依赖于WBS作为参考„对于估计的基本说明，比如费用估计是依据什么获得的„各种依据的假设条件说明„指出估计结果的有效范围及变动的判断条件 （3）成本预算„PMBOK的成本预算包括给每一独立工作分配全部费用，以获得度量项目绩效的成本基线„成本预算是费用估计在项目时间、任务上的反向分解，与我们日常的预算概念有极大的不同„IT项目的成本预算可以分为以下三部分：——直接人工费用预算——直接实施费用预算——辅助物品费用预算 费用预算过程‡费用预算的输入包括‡费用估计‡工作分解结构‡项目进度：‡首先，费用的分配和安排是与进度计划相适应的‡其次，成本基线与进度密切联系，是挂钩的‡费用预算的技术和方法：类同于费用的估计。‡费用预算的输出‡费用预算的输出是获得费用线‡费用线将作为度量和监控项目实施过程中，监控费用支出的依据‡通常的费用曲线随时间的关系是一个S型曲线。 费用预算累积负荷曲线（预算基准线）与实际费用发生的检查比较(今天)实际支出总的计费用支出计划划支出当日实际支出与计支出划支出之间的差异时间 （4）成本控制„成本管理不能脱离技术管理和进度管理而独立存在，相反要在成本、技术、进度三者之间作综合平衡。„及时、准确的成本、进度和技术跟踪报告，是项目经费管理和费用控制的依据。„成本控制就是要保证各项工作要在它们各自的预算范围内、即在成本基线内进行。费用控制的基础是事先就对项目进行的费用预算——建立成本基线。„成本控制的基本方法是定期报告费用情况，由项目经理或成本控制部门对其进行费用审核，以保证各种支出的合法性，然后再将已经发生的费用与预算基线相比较，分析其是否超支，找出超支的原因，并采取相应的措施加以弥补。 成本控制的内容„成本控制主要关心的是影响改变费用基线的各种因素、确定费用基线是否改变以及管理和调整实际的改变。„费用控制包括：…监控费用执行情况以确定与计划的偏差…确使所有发生的变化被准确记录在费用线上…避免不正确的、不合适的或者无效的变更发生„成本控制还应包括：…寻找费用向正反两方面变化的原因…考虑与其它控制过程（范围控制、进度控制、质量控制等）相协调，比如不合适的费用变更可能导致质量、进度方面的问题或者导致不可接受的项目风险等。 § 项目评价的挣得值方法‡挣得值方法是对项目进度和费用进行综合控制的一种有效方法。‡挣得值方法的三个基本参数（1）　‡计划工作量的预算费用（BCWS/PV Budgeted Cost for Work Scheduled ）‡BCWS是指项目实施过程中，某阶段计划要求完成的工作量所需的预算工时(或费用)。‡计算公式为：BCWS=计划工作量×预算定额。‡BCWS综合反映进度计划应当完成的工作量二者，而不仅仅反映应消耗的工时（或费用）。‡案例：某项目打算安装一台WEB接入服务器，预计硬件、软件、安装等计划用一周的时间，购买软硬件及请别人安装等的成本预算，批准了3万元。‡即：这一周的计划工作预算费用BCWS就是3万元。　 挣得值方法‡挣得值方法的三个基本参数（2）　‡已完成工作量的实际费用(ACWP/AC Actual Cost for Work Performed) ‡ACWP是指项目实施过程中，某阶段实际完成的工作量所消耗的工时(或费用)。‡ACWP主要反映该阶段项目执行的实际消耗。‡上例中，最后实际用了二周时间，完成了服务器的购买和安装。‡在第一周花万元购买了服务器，在第二周花万元完成了安装工作。‡第一周的ACWP2=.5万元‡第二周的ACWP为万元。 挣得值方法‡挣得值方法的三个基本参数（3）　　‡已完工作量的预算成本（BCWP/EV Budgeted Cost for Work Performed）‡BCWP是指项目实施过程中，某阶段按实际完成工作量及按预算定额计算出来的工时（或费用），即挣得值（Earned Value）。‡BCWP的计算公式为：ＢＣＷＰ=已完工作量×预算定额。　‡上例中，你认为第一周购买了服务器和软件，是完成总计划工作量的70%‡你第一周的计划成本是3万元。‡那么你第一周的挣值就是：‡第一周的BCWP=70%*3万=万元。‡即你在第一周时间点上的挣得值是万元。‡注意：如果原来计划时间不是1周，而是2周、且任务平均分配呢？‡则第一周的BCWS=3万/2=万‡在第一周你就完成了全部任务的70%，换算为当天任务的140%，则你第一周的挣得值BCWP=140%*万=万‡结果是一样的，为什么？ 挣得值方法9挣得值方法的四个评价指标9费用偏差（C VCost aVriance）：9CV是指检查期间BCWP与ACWP之间的差9计算公式为CV=BCWP-ACWP。9当CV为负值时，表示执行效果不佳，即实际消费人工（或费用）超过预算值即超支。9反之当CV为正值时，表示实际消耗人工（或费用）低于预算值，表示有节余或效率高。 挣得值方法9挣得值方法的四个评价指标9进度偏差（S VScehudle aVriance）：9SV是指检查日期BCWP与BCWS之间的差9其计算公式为SB=VCWP-BCWS9当S为V正值时表示进度提前9SV为负值表示进度延误。 挣得值方法„挣得值方法的四个评价指标…费用执行指标（CPI Cost Perofrme dIndex）：…CPI是指预算费用与实际费用（或工时值）值之比…CPIB=CWP／ACWP当CPI＞1表示低于预算CPI＜1表示超出预算CPI＝1表示实际费用与预算费用吻合 挣得值方法„挣得值方法的四个评价指标…进度执行指标（SPI Schedule Performed Index）：…SPI是指项目挣得值与计划值之比…SPI=BCWP／BCWS当SPI＞1表示进度提前SPI＜1表示进度延误SPI＝1表示实际进度等于计划进度 挣得值方法的例子 第三部分软件项目的规划 第三部分•目录项目的计划编制与管理项目的成本预算与管理 项目的质量目标与管理 项目的风险分析与管理 什么是软件项目的质量？„软件系统功能齐全是不是就是质量好？„用户界面友好是不是就是软件的质量好？„没有BUG是不是就是软件的质量好？„什么是用户满意的软件项目？„软件测试是不是软件质量的全部？„那么，什么是软件的质量？ 什么是软件项目的质量管理？¾软件项目管理中的质量管理与软件工程的测试管理，有什么不同？¾项目经理与项目AQ经理有什么不同？¾什么是软件项目的质量管理？¾项目经理在保证项目的质量方面，要做什么工作？我们就来回答这些问题！ 质量的要素与度量¾软件的质量要素¾软件质量评价的准则¾软件质量的度量¾软件质量度量的实施 软件的质量要素什么是软件的质量？•ISO9000的质量定义：•质量的定义：反映实体满足明确和隐含需要能力的特性综合•定义的说明：–明确需要：指合同中用户明确提出的要求与需要–隐含需要：指由生产企业通过市场调研进行识别与探明的要求或需要 质量与等级的关系„等级的含义是：对功能用途相同、但技术特性不同的实体的一种分类或排序„例如：高质量——无错误、可读性强的用户手册低等级——有限的功能低质量——错误百出、编排混乱的用户手册高等级——大量功能„PMBOK强调质量的核心是产品、服务的适用性„什么是适用性？ „质量的要素‡讨论软件的质量定义，一般地从4个角度来看，即用户的角度、开发商的角度、产品的角度和价值的角度。‡美国的.Ｂoemh和 先后提出了三层次的评价度量模型：软件质量要素、准则、度量。‡随后.GMruine提出了自己的软件质量度量SQM技术，波音公司在软件开发过程中采用了SQM技术，日本的NEC公司也提出了自己的SQM工具，即SQMAT，并且在成本控制和进度安排方面取得了良好的效果。‡IEEE标准1061-1998以表格的形式，定义了有关确认和收集与软件质量需求有关一个模型，或称为一个框架。 IEEE定义的软件质量度量框架软件产品质量特性特性特性直接度量直接度量直接度量子特性子特性子特性度量度量度量 IEEE定义的软件质量度量框架度量框架一种用来组织、选择、沟通、评价软件系统要求的质量属性的辅助决策法。它逐层分解为特性、子特性和度量质量特性一个与质量有关的面向管理的软件属性质量子特性质量特性分解出来的技术组件直接度量一种不依赖与任何其他属性测量的度量预计度量一种试用于开发阶段的度量，它用来预计软件质量特性的值软件质量度一个函数、它的输入是软件数据，输出是一个单一数值。它可量解释为给定的软件属性对其质量的影响程度过程质量一种用来测量在软件系统开发、实现和维护过程中使用的方法、技术和工具特性的度量产品度量一种用来测量软件开发过程中任何中间或最终产品特性的度量 „质量需求在四层模型的第一层，软件产品质量层，是产品必须满足的质量需求。它是用用户术语描述的，主要有四点：（1）产品将在用户所在组织当前使用的平台和操作系统上运行。（2）产品将是可靠的并能防止数据丢失的机制。（3）产品将提供完成某些任务所必需的功能。（4）产品将易于使用。„质量特性在模型的第二层，表示与整个质量需求有关的特殊质量特性，它代表了用户的质量需求。它采用从用户角度考虑的立场，把软件质量分解成四类质量特性，这四个质量特性是软件的基本特征。IEEE的四个质量特性是：可移植性、可靠性、功能性、可使用性。 四层模型质量需求质量特质量子特性直接度量度量描述（例子）性产品将在多可移植硬件独立性硬件依赖性计算硬件的依赖性平台和当前性用户正在使软件独立性软件依赖性计算软件的依赖性用的操作系统上运行易安装性安装时间测量安装时间可重用性能够用于其计算能够或已经应用于其他应用软件他软件系统的模块数量中产品将是可可靠性无缺陷性测试覆盖测量测试覆盖度靠的并能提审查覆盖计算已做过的代码审查模供防止数据块丢失的机制容错性数据完整性统计用户数据被破坏情况数据恢复测量恢复被破坏的数据的能力可用性软件可用的软件可用时间除以总的软百分比件使用时间 质量需求质量特性质量子特性直接度量度量描述（例子）产品将提供完功能性完备性测试覆盖计算调用或分支测量覆盖成某些任务所必需的功能正确性缺陷密度计算每一版本发布前的缺陷安全性数据安全性统计用户数据被破坏的情况用户安全性没有被阻止的非法用户入侵数兼容性环境变化软件安装后必须修改的环境变量数量互操作性混合应用环混合应用环境下可正确运行境下软件的的数量可操作性产品将易于使可使用性易理解性学习所用时新用户学习软件特性所花费用间的时间易学性学习所用时新用户学会操作软件提供的间基本功能所花费的时间易操作性人的因素新用户基于人类工程学对软件消极方面的评价数量沟通性人的因素新用户基于人类工程学对软件消极方面的评价数量 软件质量评价准则McCall选择的软件质量要素评价准则共21种，它们是：（1）可审查性(auditability)。检查软件需求、规格说明、标准、过程、指令、代码与合同是否一致的难易程度。（2）准确性(accuracy)。计算和控制的精度，是对无误差程序的一种定量估计。最好表示成相对误差的函数。值越大表示精度越高。（3）通信通用性(communication commonality)。使用标准接口、协议、规范的程序。（4）完全性(completeness)。所需功能完全实现的程度。（5）简明性(conciseness)。程序源代码的紧凑与简洁性。（6）一致性(consistency)。设计文档与系统实现的一致性。（7）数据通用性(datacommonality)。在程序中使用标准的数据结构和类型。（8）容错性(error-tolerance)。系统在各种异常条件下提供继续操作的能力。（9）执行效率(execution Efficiency)。程序运行效率。（10）可扩充性(expandability)。能够对结构设计、数据设计和过程设计进行扩充的程度。 软件质量评价准则（11）通用性(generality)。程序部件潜在的应用范围的广泛性，即部件可重用。（12）硬件独立性(hardware independence)。软件同支持他运行的硬件系统不相关的程度。（13）检测性(instrumentation)。监视程序的运行，一旦发生错误时，能明确地标识错误的程度。（14）模块化(modularity)。程序部件的功能独立性。（15）可操作性(operability)。操作一个软件的难易程度。（16）安全性(security)。控制或保护程序和数据不受破坏的机制，以防止程序和数据受到意外的或蓄意的存取、使用、修改、毁坏或泄密。（17）自文档化(sdlf-documentation)。源代码提供有意义文档的程度。（18）简单性(simplicity)。理解程序的难易程度。（19）软件系统独立性(software system independence)。程序与非标准的程序设计语言特征、操作系统特征以及其他环境约束无关的程度。（20）可追踪性(reacebility)。从设计表示或实际程序构件，追踪到需求的能力。（21）易培训性(training)。软件支持新用户使用该系统的能力。 1985年，国际标准化组织（ISO）建议，软件质量度量模型由三层组成。高层称软件质量需求评价准则（SQRC），中层称软件软件质量需求评价准则（QSRC）质量设计评价准则（SQDC），低层称软件质量度量评价准则（SQMC）。分别对应McCall等人的要素、评价准则和度量。ISO认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成、中层由23个评价准则组成。高层的8个要素为左表的行，中层的23个准则为下表的列。它们之间的关系如左表所示。软件质量设计评价准则（QSDC） 软设计件质量的另一种理解•运行时刻反映出的软件设计质量：•功能•性能•安全性•可用性•运行时刻反映不出的软件设计质量：•可修改性•可移植性•可复用性•可集成性•可测试性•与体系结构有关的质量属性：•概念完整性、理解正确性、设计完备性、结构可构造性 软件质量的另一种理解•ISO/IEC9126-1《产品质量-质量模型》的软件质量模型 ‡内部质量的定义是：‡反映软件产品在规定条件下使用时，满足需求的能力的特性，是软件开发过程中各阶段（需求开发、软件设计、代码编写等）产生的中间软件产品的质量。‡了解软件产品的内部质量，可以预计最终产品的质量。‡外部质量的定义是：‡反映软件产品在规定条件下使用时，满足需求的程度。‡外部特性反映在预定的系统环境中运行时可达到的质量水平。 ‡使用质量的定义是：‡反映软件产品在规定的使用环境下，使特定用户在达到规定目标方面的能力。‡反映的是从用户角度看到的软件产品在特定系统环境下满足其需求的满足程度。‡对内部和外部质量特性的度量描述包括：‡功能性、可靠性、易用性、效率、可维护性、可移植性等；‡对使用质量特性的度量描述包括：‡有效性、生产率、安全性、满意程度等 软件质量度量的实施9在确定要对一个软件（系统）进行度量之后，一般，采取以下5个步骤，来实施对该软件的度量：（1）确定软件质量需求；9在用户需求中，除功能需求外，还有非功能需求，包括：质量需求、环境需求、设计约束、开发策略等。质量需求是用户比较关心的内容。9但是，我们已经知道，软件的功能需求的确定，存在一定的难度。而非功能需求的确定，则难度更大。这些困难包括：需求如何获取，需求冲突如何协调、需求的确认和变更的授权等。过程：9需求获取：首先，你要理解用户的需求，区分哪些是质量需求，把这些需求记录下来，获得用户的确认。9需求分析：拿到用户确认的需求后，你可以开始把用户的质量需求与我们设定的质量特性联系起来，一直区分到子特性。这种联系，就是把用户语言描述的需求，转变为计算机工程师语言的需求。建立了这种关联后，可以根据分类，分级，确定直接度量。 软件质量度量的实施（2）确定直接度量直接度量就是实际的软件质量测量活动，它的输入是软件或软件过程，输出是一个测量值。它通过执行一系列的任务，获得一个质量值。例如：对一个没有经过培训的用户，让他使用软件系统的某一功能，在界面提示、联机帮助、使用手册的帮助下，他学会掌握该功能所花的时间。而用户需求对此项指标的要求（目标）和现实系统所达到的实际值（比如：10个人次测量后统计意义上的）的比较，就是将提交质量评审的质量值。在进行直接度量前，一般应该有以下准备：（1）工具：有助于计算度量值的硬件/软件工具，如：缺陷跟踪工具；（2）应用：描述度量结果的希望值、度量值的意义、作用和对度量结果数据的使用方法；（3）数据：获得度量结果所需的数据、程序、过程等度量对象；（4）计算：度量程序、步骤和方法。（5）费用：测试是要花钱（人力、物力、时间等）的。 度量的实施（3）分析度量结果对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。（4）确认质量度量在度量过程中，进行度量结果的确认非常重要。首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性，例如：在度量中，我们用到很多统计学方法，在这些方法中，我们有一些概率分布假设（例如：某些错误的发生，我们假设符合随机概率分布），当这些假设并不成立时，度量的结果是不真实的。 其他度量•分析模型的度量（对分析模型的度量以测试系统的大小）•设计模型的度量（度量体系结构、数据和系统的复杂度）•源代码的度量（度量程序的长度、层次、开发量、时间等）•对测试的度量（度量测试的宽度、深度、错误的级别）•对维护的度量（度量软件的稳定性） 什么是系统集成项目的质量要素？如何度量和评价？如何管理与控制？ 软件质量保证过程 软件确认与验证的概念‡软件的确认（Validation）与验证（Verification）简称为V＆V 或V2，是软件产品质量度量的具体方法。‡确认是这样一个过程，它评价“在软件开发过程期间（针对单元）或结束（针对系统）时，单元或系统是否满足用户特定的需求”。换句话说，是开发结束期间确认，我们的产品符合用户要求吗？‡因此，确认的产品质量。确认活动围绕三个基本过程来开展，测试、度量和软件可靠性增长‡而验证是这样一个过程，它评价“在一个给定的开发阶段中，单元或系统是否满足在此阶段开始时确定的条件”。因此，它的意思是，我们正在制作的产品符合用户要求吗？‡因此，验证的是产品开发过程质量——工作质量。验证活动也是围绕三个基本过程来进行，审查、度量和配置管理。 测试阶段„根据不同的软件生命周期定义，测试的阶段、方法和类型构成一个层次结构，如下图：测试类型功能、算法、正向反向、可用性、边界测试方法测试结构白盒、黑盒、自顶向下、自底向上、模拟用户操作测试阶段验收测试、确认测试集成测试、单元测试 测试的V模式V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 软件审查/评审的概念回顾：我们在上节介绍软件的确认和验证过程时，已经介绍了软件验证的三个过程是：审查、测量和配置管理。同时，我们也谈到，验证与确认的区别是，确认是在整个软件系统完成交付前或某模块完成交付前的检查，它的检查点是交付前。而验证贯穿于整个开发过程，是对过程的确认。因此，验证的范围包括了整个开发过程，它是软件质量保证并持续改进的强大工具。什么是审查，审查是一个正式的、严格的、具有深度的技术评审过程。因此，评审的目的是：（1）在软件开发过程中，尽早可能地发现问题，特别是过程性的问题；（2）确保对需求保持一致的意见；（3）验证任何修改和变更满足预先定义的准则；（4）为组织提供产品在质量和过程方面是否有效的实际数据；（5）使团队成员之间在技术上建立相互的了解；（6）增加软件确认测试的有效性；（7）提高优秀软件工程师的水准。 评审内容及要求，见下表：审查类型被审查项需提交的资料提交审查条件需求软件需求规格说软件需求规格说明书及确认的需求、已明书在此之前有关的需求分经被分析和形式析文档、需求基线及批化描述，需求基准文档线已经被确定设计软件设计说明软件设计文档设计完成编码源代码模块源程序代码、设计文档、被审查模块已经组织的编码标准与规范编译正确并完成独立测试确认测试测试记录测试结果报告、质量和系统确认及回归验收标准测试已经完成 需求审查需求审查表（问题清单）（1）需求是否定义了要向用户展示的全部信息？（2）需求是否论述了系统对用户错误操作的反映？（3）每一需求项的描述是否清楚、简洁和没有二意性？（4）每一项需求是否都是可测试的？（5）需求是否有隐含或暗示的功能理解？（6）需求项之间是否有自相矛盾的地方？（7）需求是否有应该论述但没有提及的地方？（8）需求对实时性、精确度、负载能力等有没有定义？（9）需求是否包括了性能需求、质量需求等非功能需求？（10）如果需求涉及复杂的关联关系、复杂的算法、复杂的决策机制，用户能完全理解吗？（11）需求对软件升级、版本变更是否有明确的承诺？（12）需求文档是否含有不必要的设计细节？（13）是否可以根据需求，开发出适当的和完整的测试用例集？（14）需求的假设和限制条件是否明确？ 需求审查需求审查过程我们在上一节，已经一般地讨论过审查的过程。需求审查也遵循这样的过程：组织审查组；收集项目组提交的被审查资料；确定审查日期；审查员在获得审查任务分配和开始工作，包括：对资料的阅读和评审、做实地的检查、调查和询问、记录并报告；参加评审会议并报告自己的发现和分析。审查小组首先检查审查活动是否充分和没有偏差、疏漏。审查员对问题的认识有没有片面和主观。主审员根据自己的经验，可能会对年轻的审查员要求做出补充调查。通过讨论，审查小组争取对问题取得一致的意见，并形成审查报告。追踪与改正审查的目的是监督项目组对软件的品质，保持良好的状态和不断地改进。因此，审查小组有责任跟踪项目组对审查结果的利用情况。关注项目组的改进，是项目经理比关注审查结果更重要的事情。 设计审查概要设计审查表（问题清单）详细设计审查表（问题清单）设计审查的目标：概要设计重点审查以下几个方面（概要设计针对需求）（1）概要设计对需求的完整实现；（2）概要设计与需求的一致性；（3）概要设计向需求的反向可追踪；（4）概要设计中，对系统结构设计的逻辑性、合理性和可扩展性；由于概要设计是直接衔接需求的，因此，概要设计审查更多地是把设计与需求相衔接。 设计审查在详细设计中，应重点审查以下方面（详细设计针对实现）（1）设计应符合组织即定的标准；（2）设计结果对下一阶段的编码是可用的。由于详细设计直接提供编码实现，因此，在组织内，应对详细设计的“粒度”做出规定。这样，即明确详细设计与代码实现的界面，同时，也是编码标准化的工作基础。在这方面，应结合实际，进行研究。 代码审查代码的审查与具体实现工具有关，而且与具体实现工具的版本有关，因此，我们在这里就不具体讨论代码审查的内容。有不少文章具体讨论代码的标准化和设计技巧，可以作为审查的范本（如果必要的话）。代码审查的一个办法是走查。就是由审查人员“读”工程师写的代码，然后对照“标准”进行检查，是对软件文档的一种书面检查。它通过人工模拟执行源程序的过程，检查软件设计的正确性。人工模拟也像计算机执行那样，可以仔细推敲、校验和核实每一步的执行结果，进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。走查是一件非常艰苦的工作，同时是需要非常大的毅力和记忆力的工作。因为一个系统程序量之大，组织的规则和要求之多。审查员要做的是N的N次方的核对。现在也有一些计算机程序，按一定的规则，帮助审查员“读”程序，并挑出（有的可以做简单的修改）毛病，VVB就有这样的程序。如果没有计算机程序的帮助，审查员会“疯”掉的。 测试审查测试审查是对测试结果进行审查，它审查的内容包括（1）对测试用例的审查：测试用例的哪些要素（用例名、测试日期、预期测试结果等）是否齐备？（宽度）（2）在概要设计和详细设计中确定的关键点或特殊需求是否都测试到了？（深度）（3）测试过程（步骤、环境、用户模拟等）的设计是否正确、恰当？（4）预期值与结果值的差异统计；（5）测试目的是否达到？ PMBOK与CMM2的质量保证 现代质量管理„现代质量管理是对项目管理的补充„现代质量管理在以下方面，做出更多的强调：（1）以客户满意为质量目标；（2）比注重结果更多地注重过程；（3）管理层对质量负有责任。„这些观点，是以下这些质量管理大师和前辈，在逐步总结质量管理经验的基础上，建立起来的。 9OSI000质量管理体系„ISO9000-94与ISO9000-2000版之间的主要区别（1）在管理思想上的发展：（2）在体系文件管理上变化：（3）更强调内部沟通：（4）更加强调有效的持续改进：（5）增加了一条“允许的裁剪”：（6）数据分析和处理： CMM2的质量保证过程„CMM2质量保证（SQA）的目标CMM2对SQA确定了4个目标，它们是：目标1：对软件质量保证活动做到有计划；目标2：客观地验证软件产品及其活动是否遵守应用的标准、规程和需求；目标3：将软件质量保证活动及其结果及时通知相关小组和个人；目标4：由上级管理部门及时处理软件项目内部解决不了的不一致性问题。 CMM2的质量保证过程„CMM2的质量保证活动CMM2对SQA定义了8项活动，它们是：活动1：与项目总体计划同步地制订SQA计划；活动2：SQA组按SQA计划进行活动；活动3：SQA组要参与制订和评审项目的软件开发计划、标准和规程；活动4：SQA小组要评审软件工程活动，验证其一致性；活动5：SQA小组要审核软件产品，验证其一致性；活动6：SQA小组要定期向软件工程组报告活动结果；活动7：依据规定，归档和处理软件活动和产品中的偏差；活动8：合适时，与用户的SQA人员定期对SQA组的活动和结果，进行评审。 CMM2的质量保证过程„CMM2的测量分析CMM2对SQA活动的成本消耗和进度情况，进行测量和分析，例如：SQA活动的里程碑完成情况，与计划相比较进行分析；SQA活动已完成的工作所花费的工作量和成本与计划的比较分析；产品审核和活动评审的次数与计划的比较分析等。„CMM2的验证执行验证活动主要包括二个方面，一是上级管理部门要实施定期地对SQA活动的评审，适当地、及时地掌握软件过程活动。二是项目负责人要定期和根据实际需要，随时地评审SQA的活动，实行对软件活动的跟踪和监督。 ISO9000与CMM的比较比较内容2000版ISO/DIS9001CMM强调完整的组织体系，可以用管理体系本身对管理体系没有明确要求，来建立符合ISO9000管理的组织默认组织体系是有效的、健全的。管理项目管理技术管理过程的控制以管理侧重组织管理过程管理KPA的形式来强调各环节的管理，但缺乏整个过程的管理。管理职责强调宏观上的管理职责强调项目管理中不同角色职责分为组织层（规范）文件和项文件体系目层文件，并将文件体系化分所有文件同等对待为质量手册、程序文件和作业指导书，层次清楚数据分析加强了数据分析、测量在定量过程管理（KPA）中强调所有行业，但对软件行业的适大型软件企业（500人以上），对适用范围用性不够强，对企业规模无要于500人以下的中小型企业需要进求行裁剪 ISO9000与CMM的比较2000版ISO/DIS9001CMM比较内容管理理念以顾客满意为目标评价承包商的软件成熟能力配置管理弱强强调了合同评审，但对需求对需求管理有很强的控制，但没有对合同需求管理的管理很弱评审进行控制评审有较强的管理评审，但对技有较强的技术评审，但对管理评审的控制术评审管理较弱较弱内部沟通强调内部沟通，并通过组际协调（KPA）强调内部沟通来实现。外部沟通强调内部沟通，并通过组际协调（KPA）强调内部沟通来实现。变更管理弱强（有专门的KPA进行控制，包括技术变更和过程变更） PMBOK的质量管理过程‡项目的质量的二层含义‡从项目作为一项最终产品来看，项目质量体现在其性能或者使用价值上，也即项目的产品质量。‡从项目作为一次性的活动来看，项目管理质量体现在由WBS反映出的项目范围内所有的阶段、子项目、项目工作单元的质量所构成，也即项目的工作质量；‡项目是应业主的要求进行的,不同的业主有着不同的产品质量要求，其意图已反映在项目合同中。因此，项目合同是进行项目产品质量管理的主要依据。　‡PMBOK的项目质量管理是：‡在质量体系中，决定质量工作的策略、目标和责任的全部管理功能有关的所有活动，并通过诸如质量计划、质量保证和质量提高等手段来完成这些活动。 PMBOK的质量管理过程‡PMBOK的质量管理过程是：‡质量计划--确定哪些质量标准适用于该项目，并决定如何达标。‡质量保证--在常规基础上对整个项目执行情况作评估，以提供信用，保证该项目将能够达到有关质量标准。‡质量控制--监控特定项目的执行结果，以确定它们是否符合有关的质量标准，并确定适当方式消除导致项目绩效令人不满意的原因。‡这些工作程序互有影响，并且与其它知识领域中的程序之间也存在相互影响。依据项目的需要，每道程序都可能包含一个或更多的个人或由团队的努力。在每个项目阶段中，每道程序通常都会至少经历一次。 PMBOK的项目质量管理过程一——质量计划„质量计划的目的是：…确定哪些质量标准与项目有关…及如何达到这些质量标准„质量计划回答：…质量管理的目标要素是什么？如何产生和确定这些要素的？…如何度量、评价这些要素，并证实已经达到了这些要素的要求…衡量质量的二个重要指标：„可靠性、可维护性„对产品和服务进行细致的质量计划，可提高产品或服务的可靠性与可维护性 质量计划过程的输入„质量方针：质量方针是对项目的质量目标和方向所作出的一个指导性文件，因此项目管理工作组应制定自己的质量工作方针，同时项目的质量方针应与项目的投资者完全共享。„范围陈述：项目的范围陈述说明了投资者的需求以及项目的主要要求和目标，因此范围陈述是项目质量计划确定的主要依据和基础。„产品描述：尽管产品描述的相关要素可能在范围描述中予以强调，然而产品的描述通常包含更加详细的技术要求和其它的内容，它对于项目质量计划的制定非常有用。„标准和规则：项目质量计划的制定必须考虑到任何实际应用领域的特殊的标准和规则，这些都将影响项目质量计划的制定。„其它工作的输出：除了上述范围陈述、产品描述之外，其他方面的工作输出也会对项目计划的制定产生影响，比如说采购计划就要说明承包人的质量要求从而影响到项目质量管理的计划。„质量成本：质量成本是指为了达到产品/服务的质量标准而进行的全部工作所发生的所有成本。包括一致成本和不一致成本，后者又包括预防、鉴定和故障成本。 质量成本„质量成本包括：…一致成本：计划编制、培训辅导、过程控制、实地测量、设计确认、过程确认、测量评价、质量审计、维护校准…不一致成本：废料、返工、加速处理、额外材料或存货、现场维修、保修服务、投诉处理、责任判定、产品取消、改正措施…质量成本又可以分为：P成本、A、F成本，如下表：预防成本（P-成本培训、过程能力研究、卖主/供应商调查Preventive ）评估成本（A成本-检查和测试、检查和测试设备维护、处理并报告检查数Appraisal）据的成本、设计审查、内部设计审查、走查、费用审查缺陷成本内部缺废料与返工、与推迟付款有关的费用、缺陷存货成本、（F成本-陷成本工程变动成本、设计错误纠正、纠正文档eruliaF）外部缺担保费用、现场服务人员培训、产品责任诉讼、投诉处陷成本理、未来经营损失 质量计划制定的方法和技术„利益/成本分析：质量计划必须综合考虑利益/成本的交换，满足质量需求的主要利益是减少重复性工作，这就意味着高的产出、低的支出及增加投资者的满意度。满足质量要求的基本费用是辅助项目质量管理活动的付出，其基本原则是利益与成本之比尽可能的大。„基准：基准主要是通过比较实际或计划项目的实施与其它同类项目的实施过程，为改进项目实施过程提供思路和提供一个实施的标准。„流程图：——原因结果（鱼刺）图：——系统流程图:„试验设计：试验设计对于分析辨明对整个项目输出结果最有影响的因素是很为有效的，但该方法的应用存在着费用进度交换的问题。 ‡因果（鱼刺）图：‡主要用来分析和说明各种因素和原因是如何导致或者产生主要问题和后果的。‡特点：‡用图表形式表示各因素之间的关系‡是头脑风暴、过程考察等分析活动的常用工具‡有利于刺激思考、、组织思路 系统流程图:主要用来说明系统各种要素之间存在的相互关系，通过流程图可以帮助项目组提出解决质量问题的相关方法。系统流程图 质量计划过程的输出„质量管理计划：质量管理计划主要描述项目管理组应该如何实施它的质量方针。„具体操作说明：对于一些特殊条款需要附加的操作说明，包括对他们的解释及在质量控制过程中如何度量的问题。比如说满足项目进度日期不能足以说是对项目管理质量的度量，项目管理组还必须指出每一项工作是否按时开始或者按时结束，各个独立的工作是否被度量或者仅是做了一定的说明等类似情况。„检查表格：检查表格是一种用于对项目执行情况进行分析的工具，其可能是简单的也可能是复杂的，通常的描述包括命令和询问两种形式。许多组织已经形成了标准的确保频繁执行的工作顺利执行的体系。„其它过程的输入：质量计划过程也有助于对其它领域工作的开展。 KOBMP的项目质量管理过程二——质量保证„质量保证是在质量体系中实施的全部有计划、有系统的活动，它用来树立满足项目相关标准的信心。„质量保证是所有计划和系统工作实施达到质量计划要求的基础，为项目质量系统的正常运转提供可靠的保证，它应该贯穿于项目实施的全过程之中。在ISO9000系列实施之前，质量保证通常被描述在质量计划之中。„检查表„质量保证通常是由质量保证部门或者类似的组织单元提供，但是不必总是如此。质量保证通常提供给项目管理组以及实施组织（内部质量保证）或者提供给客户或项目工作涉及的其它活动（外部质量保证）。 质量保证过程的输入„质量管理计划„质量控制度量的结果：质量控制度量是为了比较和分析所作的质量控制测试的记录和度量。„操作说明 质量保证的工具和方法„质量计划编制的工具和技术（计划编制中已经介绍）„质量审核：质量审核是确定质量活动及其有关结果是否符合计划安排，以及这些安排是否有效贯彻。通过审核：——保证项目质量符合规定要求；——保证设计、实施与组织过程符合规定要求；——保证质量体系有效运行并不断完善，提高质量管理水平。„质量审核的分类包括:——质量体系审核——项目质量审核——过程（工序）质量审核——监督审核——内部质量审核——外部质量审核„质量审核可以是有计划的，也可以是随机的，它可以由专门的审计员或者是第三方质量系统注册组织审核。 质量保证过程的输出„质量改进：„质量改进包括达到以下目的的各种行动：…增加项目有效性和效率以提高项目投资者的利益。„在大多数情况下，质量改进将要求改变不正确的行动以及克服这种不正确行动的过程。 KOBMP项目质量管理过程三——项目质量控制„质量控制主要是监督项目的实施结果，将项目的结果与事先制定的质量标准进行比较，找出其存在的差距，并分析形成这一差距的原因，质量控制同样贯穿于项目实施的全过程。项目的结果包括产品结果（如交付）以及管理结果（如实施的费用和进度）。质量控制通常是由质量控制部门或类似的质量组织单元实施，但是也并非总是如此。„项目管理组应该具有统计质量控制的工作知识，特别是抽样检查和概率方面的知识，以便帮助他们评价质量控制的输出。他们应该清楚以下几个方面的不同：——预防和检查——特征样本和随机样本——特殊原因和随机原因——偏差和控制线 质量控制过程的输入„工作结果：包括实施结果和产品结果„质量管理计划„操作规范„检查表格 质量控制的方法和技术„检查：包括度量、考察和测试„控制图：„帕累托图：„抽样调查统计：„流程图：质量控制中运用流程图有助于分析问题是如何发生的。„趋势分析：趋势分析是应用数学的技术根据历史的数据预测项目未来的发展，趋势分析通常被用来监控：——技术参数：多少错误或缺点已被识别和纠正，多少错误仍然未被校正——费用和进度参数：多少工作在规定的时间内被按期完成 质量控制的工具控制图„可以用来监控任何形式的输出变量，它用的最为频繁，可用于监控进度和费用的变化，范围变化的量度和频率，项目说明中的错误，以及其它管理结果。!!„当点位于控制线内时，我们说质量是处在正常的或期望的偏差范围之内，或处于控制之中，点在界限之外时，过程失去控制„七点原则：当有七个点连续的落在中线的同一侧，虽然没有超过控制线，但这也表明可能存在变动趋势，已经不属于随机因素，可能是特殊因素（故障、问题等）出现的征兆，应加以分析。 质量控制的工具„帕累托（排列图）是一种直方图，由缺陷发生的频率组织而成，用以显示故障后果与故障原因类型之间的比例关系。„项目团队应首先采取措施，查找并解决导致最多缺陷的问题。„排列图是帕累特法则（2/8定律）的实例，帕累特法则认为：大量（80%）的问题或缺陷，是由相应的少数（20%）原因所导致的。排列图（帕累托图）示例 质量控制的工具„抽样统计：包括抽取总体中的一个部分进行检验，适当的抽样调查往往能降低质量控制成本。„与抽样有关的概念：„属性与变量抽样：„属性：可被划分为与要求相符合与不符合，从而决定继续还是停止的质量属性„变量：可以用计量单位测量的质量属性，如：长度、重量等。„属性抽样：通过抽取属性进行检测，建立总体的置信水平。属性抽样可以是变量，也可以不是，关键是检验的结果是“是—继续”还是“不是—停止”。测试简单，但需要多样本。„变量抽样：可以连续测试，只需要少量样本„标准差（SD西格玛）：„在正态分布均值两侧占总体%（1个SD）的偏差。„2SD=%，3SD=% 质量控制过程的输出„质量改进措施„验收决定：每一项目都有接受和拒绝的可能，不被接受的工作需要重新进行„返工：不被接受的工作需要重新执行，项目组的目标是使得返工的工作最少。„完成的检查表：当检查结束的时候，应该完成对项目质量的记录，及完成检查表格。„过程调整：过程调整包括对质量控制度量结果的纠正以及预防工作。 提高质量的途径提高质量的途径的6个步骤1 -建立目标2 -建立诊断分析方法3 -建立行动计划4 –改进5 -行动计划的后续措施6 -定期审查和更新再实现目标改进诊断分析后续措施行动计划定期审查632541 提高质量的途径——风险控制故障任务任务任务任务任务12345故障过程控制保证质量故障故障 =1 -风险控制故障未达到预期的结果2 -过程评估3 -10个标准风险控制4 -预防5 -监督原因原因原因故障临界状态结果结果结果风险控制（找到临界点）客户 提高质量的途径过程评估：两个领域控制错误（外部）：控制错误（内部）：确定客户需求的风险实现过程中的风险在真正需求和参与者理解的需求在理解的需求和产品之间之间的偏差或倾向的偏差或倾向理解的需求产品真正需求理解的需求 提高质量的途径10个标准1过 程被确定，已知其界限，它的所有者、参与者和客户都被确定2客 户的需求被详细说明，并且确定了主要特点3有 具体方法用于测定需求的满意度4评 估了故障的风险，以最少的成本控制它们的起因(预防措施)尽 5早地进行检查和检测，以补救残留的风险实 6施文件中叙述了实施过程及其程序和指令证 7据（记录）已经备案并可用于增强客户的信任参 8与者了解并应用过程及其程序和指令9对 观察的故障采取补救和改进措施，所有的修改都由预防措施所补救10确 定并使用监督系统 提高质量的途径过程评估过程是按10个标准评估的1 2 3 4 5 6 7 8 9 10未达到的标准使用质量管理方法和工具，按照未达到的标准进行调整注意：恰当地使用工具 提高质量的途径质量保证的工具„团队工作一个团队的效率 >个人效率之和„供应者－客户的关系各机构考虑其直接客户的需要„统计过程控制(SPC)和检查卡此工具可监督一个过程的能力 谢谢！Keep Connecting In The Future 第二部分项目的过程管理 第二部分•目录项目的范围界定与管理项目的计划编制与管理项目的成本预算与控制 项目的质量要素与管理 项目的风险分析与管理 项目风险管理概述风险是损失发生的可能性1、损失2、可能性风险管理——一项投资活动 U面对风险的主观承受能力风险的主体：效用函数：决策者在承担风主动的（机会）险因素下，对结果的满意程被动的（风险）度风险承受度：决策者对风险（效用值）的态度的数学量风险‡风险管理具有正负二个方面。厌恶‡正面是使积极事件（机会）的概率和后果最大化风险‡负面则使消极事件（损失、危害）中庸的概率和后果最小化风险‡不同的效用预期和承受度，对风喜好险管理的要求而不同W（财富） 风险的属性‡普遍性：风险是普遍存在的，特别是目前我们的组织普遍地处于内外部的不确定环境下，风险的存在就具有普遍性。‡随机性：风险的发生是偶然事件，发生的时间、地点、形式和内容都是不可准确预知的。‡相对性：同一风险对于不同的组织、项目、不同的人，危险、处置、结果和承受能力都是不同的。‡可变性：在不同的组织和项目，对于风险的承受能力、处置能力的不同，风险就会发生变化。‡可管理性：我们这一章，就是介绍，风险作为一种事件，也是可预测、可识别、可分析、可跟踪和可管理的。 风险的属性„组织外部的不确定性„（1）目标不确定；„（2）需求不确定；„（3）项目的外部干系人的影响和作用不确定；„（4）自然、政治、经济、法律、技术等的环境不确定。 风险的属性„组织内部的不确定性（1）目标不确定：对项目认识不足，造成对项目内容、目标、成本、计划、质量、环境等的认识错误，使项目从开始阶段，就处于目标错误的风险。„（2）管理不确定：由于项目内部的一系列管理处于无序状态，因此，项目运行在一个没有轨迹可循的盲目的状态下，项目的后果不可预测，造成项目的目标实现的不可确定性。„（3）技术不确定：项目关键技术、核心方案不是非常成熟的技术，项目以此技术为核心的实现，有很大的失败可能，项目成功的几率要依赖这个核心技术的成功。因此，项目成功与否，具有很大的不确定性。„（4）变更不确定：项目实施过程中，随时可能发生需求的变更。项目组对于涉及到项目的重大变更，没有有效的控制机制，项目组在用户频繁、巨大的需求变更面前，随波逐流，项目组生存在一个动荡的、没有保证的环境中。 防范风险的重要性既然项目风险确实是不可避免的，组织就必须了解风险来源、性质和发生规律，通过有组织、计划的、有效的项目管理活动，抓住机会风险的机会并导致成功。如果把风险防范和风险管理，看成是实质上类似于一种“保险”的活动，我们就会以一种比较平和的心态，来面对风险。投资当然需要成本，成本因素取决于项目的性质、规模、企业的经验和资源，也取决于项目的风险管理，包括风险的识别、规避、控制等。 风险大小概率（可能性）风险增大高度风险区不论主观因素还中度风险区是客观原因风险= 损失×可能性低度风险区损失 降低风险的思路所以，风险管理的风险增大概率（可能性）基本思路是：降低风险发生的概率（可能性）高度风险区减少危害的影响（损失）中度风险区低度风险区损失 .的KO B2 MP风险管理过程利用科学的方法去识别风险、评价风险并设计、实施有效的方法去控制风险的过程，就是风险管理过程。（1）风险计划编制：决定如何采取和计划一个项目的风险管理活动。（2）风险识别：确认哪些风险有可能会影响项目，并把这些风险的特性整理成文档。（3）风险定性分析：对项目风险和条件进行定性分析，将它们对项目可能产生的影响进行排序。（4）风险定量分析：测量风险出现的概率和结果，并评估它们对项目的影响。（5）风险应对计划编制：开发和制定一些程序和技术手段，用来提高实现项目目标的机会和减少风险对项目的目标的威胁。（6）风险监控：在项目的整个生命周期中，监视残余风险、识别新风险，执行降低风险计划，以及评价这些工作的有效性。 项目风险识别项目风险识别的来源1、与产品有关的来源2、项目其他计划的来源3、历史记录来源项目本身、项目管理、项目历史记录 风险识别的输入„风险管理计划„项目计划输出„风险分类„历史资料 风险识别方法„问讯法（头脑风暴、面谈、德尔菲法）„财务报表（各种财务记录和报表）„流程图法（网络图、WBS图）„现场观察„历史资料„环境分析„文件审核 项目风险产生的来源1、项目的未来性2、项目的复杂性3、项目环境的变化4、项目中人的因素 项目风险产生的来源产品定位——与要建造或要修改的软件的总体规划相关的风险。商业影响——与管理或市场所加诸的约束相关的风险。客户特性——与客户的素质以及开发者和客户定期通信的能力相关的风险。开发体系——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。开发环境——与用以建造产品的工具的可用性及质量相关的风险。开发技术——与待开发软件的复杂性以及系统所包含技术的“新奇性”相关的风险。团队状况——与参与工作的开发人员的总体素质及项目经验相关的风险。 系统集成项目风险产生的原因1、产品的日趋复杂性2、依赖多个厂家的支持和技术来源3、采用产品组合和功能交叉的方法4、项目管理与企业战略的紧密结合5、产品更新周期的缩短6、满足顾客需求7、市场的激烈竞争8、参与者的利益不同9、多方面专业技术的集成10、依赖更复杂的工具 软件项目风险产生的原因1、产品定位错误（包括市场定位）2. 人员流动3. 项目管理失败4. 开发目标不明确或摇摆不定5. 开发计划执行受到严重影响6. 技术方案有缺陷7. 项目经费超支或不足8. 开发环境及过程管理混乱9. 产品质量低劣10.需求发生变化 风险识别的输出1、风险（列表和说明）2、激发征兆（触发器）3、对其他过程的输入 风险分析与评估定性分析：评估已识别的风险的影响和可能性风险分析的原则：•建立一个尺度，以反映风险发生的可能性•描述风险的后果•估算风险对项目的影响•标准风险预测的整体精度，防止产生误解 风险定性分析与评估把识别的风险按概率和影„风险核对识别表响，排在分析矩阵中„风险分类表„风险概率排序表风险分析矩阵„风险影响排序表„综合风险评估表高概率可中*能性低后果影响 定性分析——软件开发各阶段的风险概影初始阶段可能的风险事件：率响1项目目标不清2项目范围不明确（范围太大/小都不可）在这个阶段进行大部分需求分析、3用户参与少或和用户沟通少少部分设计（大部分业务建模和4对业务了解不够需求、少部分分5对需求了解不够析设计）。6没有进行可行性研究设计阶段可能的风险事件概影率响1在这个阶段进行项目队伍缺乏经验，如缺乏有经验的系统分析大部分设计、少员部分编码（大部没有变更控制计划，以至于变更没有依据，该2分分析设计，部变更的不变，不该变的也变，这样得来的设计分实施及测试，势必会失败或者偏离用户需求开始考虑部署）3仓促计划，可能带来进度方面的风险4漏项，由于设计人员的疏忽某个功能没有考虑进去 实施阶段可能的风险事件概影开发环境没有具备好率响12设计错误带来的实施困难在这个阶段进行大部分编码和测3程序员开发能力差，或开发工具不熟试，也涉及少部项目范围改变（突然要增加或修改一些功分设计（大部分4能，需要重新考虑设计）实施及测试，部分部署），如：设计变更或补充5项目进度改变（要求提前完成任务）设计。人员离开，在一个项目内软件开发工作有6一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大开发团队内部沟通不够，导致程序员对系7统设计的理解上有偏差8没有有效的备份方案9没有切实可行的测试计划1测试人员经验不足0 收尾阶段可能的风险事件概影率响在这个阶段1质量差进行安装及维护（大部2客户不满意分部署）。3设备没有按时到货4资金不能回收 项目风险衡量——风险概率表成功的标准权重1用户的参与192高层管理的支持163明确的需求说明书154适当的计划编制115切合实际的预期106更小的项目里程碑97胜任的工作人员88所有权69清晰的前景和目标31努力工作和专注的工作人员30总计100 项目风险衡量——问卷调查对于调查表格，设计了以下5个问题：„（1）我有合适的用户吗？„（2）我是否尽早并且经常让用户参与？„（3）我是否与用户建立了良好的关系？„（4）我是否方便了用户的参与？„（5）我是否发现了用户需要什么？对这5个问题，每回答一个“是”，就给分（总分之和为19分）。因此，检查或自我检查者可以很方便地进行检查或自我评定。 项目风险衡量——风险影响表风险事件影响程度标准评价评价结值果规模估计过低70%1<30%一般>60%严重严重交付期限太紧张50%2<20%一般>40%严重严重用户需求变化频繁>50%严重3<30%一般75% 严重技术达不到预期效果20%4<30%一般>50%严重轻微30%5质量保证体系的措施实施<20%一般>40%严重中等不利40%6软件体系结构设计不合<5%一般>30%严重严重理人员流动30%7<10%一般>20%严重严重 项目风险衡量——风险排序表风险类别概率影响６０％1规模估算可能非常低ＰＳ２2用户数量大大超出计划ＰＳ３０％３７０％3复用程度低于计划ＰＳ２４０％4最终用户抵制该计划ＢＵ３５０％5交付期限将被紧缩ＢＵ２４０％6资金将回流失ＣＵ１８０％7用户将改变需求ＰＳ２３０％8技术达不到预期的效果ＴＥ１８０％9缺少对工具的培训ＤＥ３1３０％人员缺乏经验ＳＴ２01６０％人员流动频繁ＳＴ２1 项目风险衡量——风险形势评估 风险计划制定（1）研究风险管理策略（2）制定风险管理方案（3）确定风险管理计划（4）制定风险应对计划 项目风险应对选择策略„风险规避——用户不满、人员流失„风险转移——保险、外包„风险减轻——…减少风险发生的概率——采用成熟技术、老员工…减少风险的影响——责任分散„风险接受——地震、火灾——备份 风险管理计划制定项目管理计划重点放在整个项目过程全范围的风险管理，它至少应包括：（1）确定项目的风险管理目标：（2）确定项目的风险管理策略：（3）定义项目的风险管理程序：（4）提炼项目的风险应对计划要点：（5）提供项目的风险应对计划模板：（6）定义项目的风险管理验证标准：（7）明确项目管理措施的实施主体和责任人：（8）指明项目风险措施的资源来源与获得方式：（9）明确项目风险过程信息记录的获得和管理机制： 风险管理计划制定Ⅰ.引言文档的范围和目的主要风险综述责任：a.管理者、b.技术人员Ⅱ.项目风险表对项目组而言的项目终验前所有风险的描述影响概率及影响的因素Ⅲ.风险缓解、监控和管理缓解、一般策略、缓解风险的特定步骤监控、被监控的因素、监控办法管理风险事件应对计划特殊的考虑Ⅳ.风险管理计划的迭代时间安排表Ⅴ总结 软件项目风险应对计划（1）在项目计划和项目进度中，标识出可能的延误风险。（2）在建立项目需求定义的过程中，标识出需求不确定或不足的风险，并建立补救措施计划文档，此计划将贯穿整个项目软件生命周期。补救措施计划应包括以下方面的工作：对需求的可选项识别、可选项影响度评估、可选项的技术可行性，和可选项使用时机的决定标准。（3）在软件发行最初版本和主要的修订版时，标识可能的缺陷风险，在项目审查、确认阶段，要经过同行评审后才可发行。（4）在有选择的项目里程碑处、在指定的风险检查阶段点、和在对软件项目有影响的计划重大变更过程中，都应对软件风险进行跟踪、再评估，和重新计划。（5）当软件风险逐渐显著并需要被跟踪时，应在每周、每月或其它定期工作报告中加入风险跟踪表，以便跟踪。（6）在每次检查和评审后，项目经理要检讨并修正风险级别。同时，在平时，应利用风险监控所获得的信息，进一步精化风险评估和软件计划。 项目风险的跟踪控制系统方法管理目标风险管理信息组织项目文化 风险管理过程是一个反复迭代的过程明确目标风险识别风险分析与评估抉择策略、设计规律和应对方案实施方案评估与审核 风险管理与项目管理的关系 项目风险的跟踪控制1.不断的识别新的风险2.不断的分析风险的产生概率3.不断的整理风险表4.不断的规避优先级别最高的风险主动的风险缓解方法是进行风险控制的最有效方法！直到风险消亡！举例：人员流动风险的控制分析外在和内在两种方法的使用 整体风险管理过程风险定性分析陈述应对计划识别定量分析概率影响跟踪监控风险管理计划整个过程的核心依据是需要一个不断优化更新的风险管理计划 谢谢！Keep Connecting In The Future 《第一次作业》点评 项目与项目管理概念的应用„角色：„你是一家大型行业软件开发企业的项目经理（乙方）„或者，你是一家电信运营商运维部门的项目经理（甲方）„背景：„昨天，你听说公司的一个重大软件项目的项目经理辞职了，公司可能要你担任此项目的项目经理。但你知道，这个项目涉及的问题非常多，离职的已经是第2任项目经理了。如果不做一些实质性改变的话，你将重蹈前二位项目经理的覆辙，因此，很多人都劝你不要接这个项目。但是，你认为这对你来说是一个机会。所以，你做了一些准备。„要求：„明天，你的老板将要跟你正式谈接手项目的事情，请你写下准备跟老板见面时，你的谈话要点。„存在问题和你的打算„需要公司作出的支持和承诺„下课前交 （1）可能的问题„用户的问题以下分析全部以乙方为例„需求不确定„接口不明确„合同的问题„合同没有签订„双方的责任、工作界面不清楚„项目团队的问题„人员素质不齐、业务不熟悉„厌倦、疲塌、没有兑现奖励，看不到希望„内部闹矛盾„公司的问题„工资、奖金不兑现或起不到激励作用„给项目组的支持少、指责多„工作、生活等条件不好„领导不重视、公司其他部门不配合„前任项目经理个人的问题 （2）很多同学的答案„用户的问题„需求不确定公司派高手去搞定需求„接口不明确„合同的问题„合同没有签订公司派销售去把合同签掉„双方的责任不清楚„项目团队的问题„人员素质不齐公司允许我要谁，不要谁„厌倦、疲塌„业务不熟悉„公司的问题„工资、奖金不兑现或起不到激励作用公司先发50%„给项目组的支持少、指责多奖金，并答应„工作、生活等条件不好装空调……„领导不重视、公司其他部门不配合„前任项目经理失败的原因这个？想的不多…… （3）政委同志的答案„由于…，本项目是非常重要的，为此，作为项目经理：„要多与员工沟通，听取他们对项目的看法、意见和建议，以及切身体会，从中了解项目的重点、难点和关键问题；„要关心员工，在艰辛的阶段要给予帮助和肯定以及慰问，在关键的阶段要严格要求、以身作则、严把质量关；„在物力方面，要妥善保管和分配查询资料、各阶段的版本、备份，各部分软件的接口，使得各员工能够更方便高效地作好自己的工作，能很好地与其他部门员工协调衔接；„由于项目持续的时间比较长，这不仅仅对员工的新鲜感和积极性有不良影响，还可能使员工感到浮躁、麻木和疲倦，要合理安排员工的作息以及业余娱乐，适当安排假期，使员工从头到尾保持良好的心情和高效的工作状态。 （4）好点子„老板亲自去安抚用户„我先在项目组说要争取奖金，然后再发，这样可以树立我的威信„公司保证不论这个项目最后是否成功，都不惩罚员工，我除外„公司的承诺要有书面的文件„在项目期间，不要随意从项目组中抽人 书生的项目管理目标责任权利资源 （5）问一个问题„用户的问题„需求不确定„接口不明确前面二任项目经理都是笨蛋吗？„合同的问题„合同没有签订你想到的这些措施他都没有„双方的责任不清楚想过，没有试过吗？„项目团队的问题„人员素质不齐你与他比，有什么不同？„厌倦、疲塌„业务不熟悉你不比他强，你来干什么？„公司的问题„工资、奖金不兑现或起不到激励作用„给项目组的支持少、指责多„工作、生活等条件不好„领导不重视、公司其他部门不配合„前任项目经理失败的原因 （6）再问一个问题„用户的问题„需求不确定„接口不明确项目组是不是要负主要责任？„合同的问题„合同没有签订前二任项目经理个人要负什„双方的责任不清楚么责任？„项目团队的问题„人员素质不齐公司的利益在哪里？„厌倦、疲塌„业务不熟悉公司没有利益，要你们干什么？„公司的问题„工资、奖金不兑现或起不到激励作用„给项目组的支持少、指责多„工作、生活等条件不好„领导不重视、公司其他部门不配合„前任项目经理失败的原因 „长时间的思考……„老板的资本人格 （7）特别要考虑的问题„不论什么原因，前二任项目经理的工作一定有不完善的地方，甚至有失职的地方，造成今天的局面，他们不能说没有责任。„前任项目经理失败的原因„最根本的原因是„对我来说，应吸取的经验教训是什么？„他们是做不下去才离开的！„用户„项目团队„公司领导„那么，我的策略是什么？ （8）考虑问题的思路„长时间、反复地考虑与权衡：„（1）给公司以希望„项目组目前的问题„如何维护公司的利益„可以采取的工作措施和有把握短期内取得的成果„（2）才有可能让公司给你机会，才有可能有条件的给予的支持 （9）考虑问题的思路„我的建议方案的基本出发点„坚定地维护好公司的利益„综合协调好项目团队与用户、公司部门之间的关系„按项目管理的方法严格管理„明确奖罚，严明纪律，而在目前阶段重点是给团队以信心 （10）我的承诺„我应该做工作的具体细节，不详细介绍，会给领导有文字汇报„我短期内的工作目标是：„本周内提交新的、调整后的项目计划„二周内，与用户就需求达成协议„本月内配合销售，完成合同草签„本月内完成内部人员调整和交接„争取下个月中旬完成系统上线测试，月底实现主要功能的正式试运行，为按计划6月底正式初验，做好准备 （11）我的请求„为了实现上述目标，我希望公司支持：„下个月底如果能顺利实现主要功能的上线试运行，只要用户签了开始试运行的开工单，公司同意发放前6个月的效益工资（本人不在其内）„为实现上述目标，公司同意增调某某、某某某二人到项目组工作2个月（我已调查过，他们能抽调出来），同时，本项目组刘某等4人退回原部门„希望公司高层到项目组现场视察，对项目组前期的工作给予肯定，并再次明确，按计划完成项目后的项目奖为20万元„公司承诺，如果本项目按时完成，由本项目组主要骨干为主，承接新开工的某某项目。„…… （12）回到项目管理„目标：„目标哪里来？不是老师出的作业题那么简单„什么是目标？不是抽象的、仅仅写在纸上的几个数字„目标有时是冒险，有时是赌博„责任：„与目标相匹配的责任（目标管理的概念）„双方的责任„资源：„与目标对等的资源„争取资源 （13）甲方的情况„如果你是甲方，乙方是公司老总的关系找来的，但现在已经明显不能按要求完成项目了„你怎么办？ 《第二次作业》 软件项目的范围定义与系统边界„角色：„你是一家大型行业软件开发企业的项目经理（乙方）„或者，你是一家电信运营商运维部门的项目经理（甲方）„背景：„针对第一次作业反映的问题，你决定开发一套项目管理软件系统，来帮助你切实对项目实施过程进行控制和管理。„需求：„能实时地反映项目的进展与状态„能帮助你实现项目的进度计划管理与控制„能帮助用户、公司与项目组进行情况交流和沟通„请用案例中给出的方法，进行描述„请注意：包括用户需求、系统需求 项目范围定义——系统描述与系统边界业务需求需求特性需求子特性业务描述操作描述客户访问系统的接电话接受电话访在语音提示下，进行自系统的方入方式问动应答，提供信息和咨式询服务。FAX接受传真访自动为授权用户回复传问真E_mail接受mail根据用户填写的信息要求，自动回复相应的mail。Web接受网上访提供网上交互服务。问系统描述与系统边界‡‡、对业务需求（系统级、用户角度的）进行分解：1‡业务需求、需求特征、子特征、业务描述、操作描述：‡操作描述是我们可以看到、能实际操作实现的功能‡2、定义系统的边界‡在用户操作（应用）一级定义系统做什么和不做什么（系统边界），外部系统包括人和其他计算机系统

    标签

    软件项目管理 软件工程
    未登录

    联系我们

    智库文档公众号

    客服微信

    ©2026 MBAlib.com, All rights reserved.

    闽公网安备 35020302032707号

    分享
    分享至
    微信扫码
    QQ
    微博
    加入专题
    收藏
    用手机看文档

    扫一扫,手机看文档

    TOP
    全屏
    放大
    缩小
    /628
    下载
    开通VIP
    下载即可得无水印文档
    ×
    加入专题
    + 创建新的文档专题
    确定
    开通
    VIP
    微信客服

    微信扫码联系客服
    微信
    服务号
    用户反馈
    下载APP