一、软件项目管理概述

1.项目的概念

1.1项目的概念和特点

1.1.1项目的概念

• 什么是项目？
  项目是为了创造独特的产品、服务或其他成果而进行的一场一次性工作。

1.1.2项目的特点

• 临时性
• 独特的产品或服务

1.1.3项目与日常运作的区别

• 项目是一次性的，日常运作是重复进行的。
• 项目是以目标为导向的，日常运作是通过效率和有效性体现的。
• 项目是通过与项目经理及其团队工作完成的，而日常运作是职能式的线形管理
• 项目存在许多变更管理，日常运作保持持续的连贯性。

1.2项目的生命周期

• 项目的启动
  主要任务是确认需求，分析投资收益比、研究项目的可行性、分析自己应具备的条件。
• 项目的计划
  项目经理为项目制定项目计划、核算成本等。
• 项目的实施
  项目经理细化目标，制定工作计划，协调人力和其他资源，定期监控进展，分析项目偏差，采取必要措施以实现目标。
• 项目的结束
  项目组移交工作成果，帮助客户实现商务目标，将系统交接给维护人员，结清各种款项，还应进行项目总结、项目评估和文件归档。

2.什么是软件

2.1软件的概念

软件包括：程序、数据及相关文档的集合。

• 程序：是按事先设计的功能和性能要求执行的指令序列。
• 数据：是使程序能正常操作信息的数据结构。
• 文档：是与程序开发、维护和使用有关的图文资料。

2.2软件的角色

• 软件本身是一种产品
  将计算机硬件的计算能力发挥出来
• 软件是一种传递产品的工具
  软件传递了我们这个时代最重要的产品：信息

2.3软件的特征

• 软件是一种逻辑元素而不是物理元素
• 软件是开发出来的，而不是用传统的方法制造出来的
• 软件****不会被用坏
• 工业界已经走向了标准化装配时代，而绝大多数软件还是定制出来的。
• 软件本身是复杂的。
• 软件开发的成本相当昂贵。
• 很多的软件工作涉及社会的因素，要受到机构、体系和管理方式等问题的限制
  
  

3.软件危机

3.1 软件危机概念

• “软件危机”是1968年在NATO（北大西洋公约组织）工作会议上作为一个正式的议题被提出来的，他们主张用工程化的方法开发软件解决软件危机，并提出“软件工程”这一术语

3.2 软件项目不成功的例子

• 1999年10月，耗资1.25亿美元的NASA的火星气象卫星失踪，据信这是由于简单的数据转换错误所导致的，人们发现卫星软件中，有些数据使用英制，它们应被转换成公制。这个卫星应当充当另一项任务中的火星极地着陆项目的通信转发器，那个任务也失败了，原因不明
• 美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序……据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果……
  这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训说：“……正像一只逃亡的野兽落到泥潭中做垂死挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难……程序设计工作正像这样一个泥潭……一批批程序员被迫在泥潭中拼命挣扎……”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。

3.3 软件危机的一些数据

• 大约**70%的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20%到50%，90%**以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高
• 美国政府统计署的数据：全球最大的软件消费商——美国军方，每年要发费数十亿美元购买软件，而在其所购买的软件中，直接可用的只占2%，另外3%需要进行一些修改，其余95%都成了垃圾。

4.项目管理基本概念

4.1项目管理的定义

• 项目管理是以项目为对象，通过使用知识、技能、工具和方法来组织、计划、实施并监控项目，使之满足项目目标需求的过程

4.2项目管理的6要素

• 客户满意度
  “客户满意，自己获利”。
• 工作范围
  指为了实现项目目标必须完成的所有工作。
• 组织
  项目组人员结构。
• 时间
  用进度计划描述完成项目工作范围内所有工作需要的时间。
• 质量
  项目满足明确或隐含需求的程度。
• 成本
  完成项目需要的所有款项，包括人力成本、原材料、设备租金、分包费用和咨询费用等。

4.3项目管理知识体系

4.3.1两大项目管理研究体系

• 国际项目管理协会（IPMA）
  成员主要代表各个国家的项目管理研究组织，该组织于1965年在瑞士注册，是非盈利组织，重视专业人员的资格认证工作。
• 美国项目管理学会（PMI）
  成员主要以企业、大学、研究机构的专家为主，它开发了一套项目管理知识体系（Project Management Body of Knowledge,PMBOK）

4.3.2 项目管理知识体系（PMBOK）

4.3.2.1 PMBOK 9 大知识领域

• 项目范围管理
  是为了实现项目的目标，对项目工作内容进行控制的管理过程。它包括范围的界定，范围的规划，范围的调整等是为了实现项目的目标，对项目工作内容进行控制的管理过程。它包括范围的界定，范围的规划，范围的调整等。
  一般通过定义交付物和交付物标准来定义工作范围。
  工作范围根据项目目标分解得到，它指出了"完成哪些工作就可以达到项目的目标"，或者说"完成哪些工作项目就可以结束了"。后一点非常重要，如果没有工作范围的定义，项目就可能永远做不完。要严格控制工作范围的变化，一旦失控就会出现"出力不讨好"的尴尬局面：一方面做了许多与实现目标无关的额外工作，另一方面却因额外工作影响了原定目标的实现，造成商业和声誉的双重损失。
• 项目时间管理
  是为了确保项目最终的按时完成的一系列管理过程。它包括具体活动界定，活动排序，时间估计，进度安排及时间控制等项工作。
• 项目成本管理
  是为了保证完成项目的实际成本、费用不超过预算成本、费用的管理过程。它包括资源的配置，成本、费用的预算以及费用的控制等项工作。在IT项目中人力成本比例很大，而工作量又难以估计，因而制定预算难度很大。
• 项目质量管理
  是为了确保项目达到客户所规定的质量要求所实施的一系列管理过程。它包括质量规划，质量控制和质量保证等。是指项目满足明确或隐含需求的程度。一般通过定义工作范围中的交付物标准来明确定义，这些标准包括各种特性及这些特性需要满足的要求，因此交付物在项目管理中有重要的地位。另外，有时还可能对项目的过程有明确要求，比如规定过程应该遵循的规范和标准，并要求提供这些过程得以有效执行的证据。时间、质量、成本这三个要素简称TQC。在实际工作中，工作范围在《合同》中定义；时间通过《进度计划》规定，成本通过《预算》规定，而如何确保质量在《质量保证计划》规定。这几份文件是一个项目立项的基本条件。一个项目的工作范围和TQC确定了，项目的目标也就确定了。如果项目在TQC的约束内完成了工作范围内的工作，就可以说项目成功了。
• 人力资源管理
  是为了保证所有项目关系人的能力和积极性都得到最有效地发挥和利用所做的一系列管理措施。它包括组织的规划、团队的建设、人员的选聘和项目的班子建设等一系列工作。
• 项目沟通管理
  是为了确保项目的信息的合理收集和传输所需要实施的一系列措施，它包括沟通规划，信息传输和进度报告等。
• 项目风险管理
  涉及项目可能遇到各种不确定因素。它包括风险识别，风险量化，制订对策和风险控制等。
• 项目采购管理
  是为了从项目实施组织之外获得所需资源或服务所采取的一系列管理措施。它包括采购计划，采购与征购，资源的选择以及合同的管理等项目工作。
• 项目集成管理
  是指为确保项目各项工作能够有机地协调和配合所展开的综合性和全局性的项目管理工作和过程。它包括项目集成计划的制定，项目集成计划的实施，项目变动的总体控制等。

4.3.3项目管理资格认证PMP

• PMP（Project Management Professional）指项目管理专业人员资格认证
• PMP是由美国项目管理协会Project Management Institute(PMI)发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。其目的是为了给项目管理人员提供统一的行业标准。作为项目管理资格认证考试，已在国际上树立了其权威性.

4.3.4项目管理专业资质认证IPMP

IPMP即国际项目经理资质认证(International Project Manager Professional)的简称，是国际项目管理协会（International Project Management Association，简称IPMA）在全球推行的四级项目管理专业资质认证体系的总称。

• A级(IPMA Level A)证书是国际特级项目经理
• B级(IPMA Level B)证书是国际高级项目经理
• C级(IPMA Level C)证书是国际项目经理
• D级(IPMA Level D)证书是国际助理项目经理

二、软件项目合同管理

2.1合同管理概述

2.1.1合同的概念

• 合同是使卖方负有提供具体产品和服务的责任，买方负有为该产品和产品服务付款的责任的一种双方相互负有义务的协议
• 合同定义了合同签署方的权利与义务，以及违背协议会造成的相应法律后果；
• 合同监督项目执行的各方履行其权利和义务，它是具有法律效力的文件
• 围绕合同，存在合同签署之前和合同签署之后的一系列工作。

2.1.2合同的生命周期

2.1.3合同技术

• 软件项目合同主要是技术合同；
• 技术合同是法人之间、法人和公民之间、公民之间以技术开发、技术转让、技术咨询和技术服务为内容，明确相互权利义务关系所达成的协议
• 技术合同有三种环境：需（甲或买）方环境、供（乙或卖）方环境和内部环境；
• 技术合同一般包括主合同和合同附件

2.1.3.1主合同

主合同至少应包括以下内容：

• 项目名称；
• 项目的技术内容、范围、形式和要求；
• 项目实施计划、进度、期限、地点和方式；
• 项目合同价款、报酬及其支付方式；
• 项目验收标准和方法；
• 各方当事人义务或协作责任；
• 技术成果归属和分享及后续改进的提供与分享规定；
• 技术保密事项；
• 风险责任的承担；
• 违约金或者损失赔偿额的计算方法、仲裁及其它。

2.1.3.2合同附件

• 系统的商务报价表；
• 系统的需求规格说明书；
• 项目的工程进度计划书；
• 技术服务承诺；
• 培训计划；
• 移交的用户文档和技术文档；
• 场地和环境准备要求；
• 测试与验收标准；
• 初验与终验报告样式范本；
• 工程实施的分工界面定义。

2.1.4软件项目合同条款分析

软件项目合同的一般性条款有六大类：

• 与软件产品有关的合法性条款：
  主要包括软件的合法性条款和软件产品的合法性等内容。
• 与软件系统有关的技术条款：
  主要包括与软件系统匹配的硬件环境、软件环境，有关软件安全性、稳定性、容错性方面的相关保证等。
• 与软件适用标准体系有关的条款：
  主要包括产品分类与代码方面的标准，通用语言文字方面的标准，计量单位、通用技术术语、符号等方面的标准，国家强制性质量认证标准等。
• 与软件产品实施有关的条款：
  主要包括项目实施的定义与目标，项目实施的计划，甲乙双方的权利与义务，项目实施的内容与步骤，项目实施的修改与变更，项目的验收等。
• 与软件产品技术培训有关的条款
• 与软件产品后续技术支持和服务有关的条款

2.2需方合同环境

2.2.1合同准备

2.2.1.1招标书定义(采购需求定义)

启动一个项目主要是由于存在一种需求，招标书定义主要是需方的需求定义，也就是甲方(买方)定义采购的内容。
软件项目采购的是软件产品，需要定义采购的软件需求，即提供完整清晰的软件需求和软件项目的验收标准。

• 招标书定义过程：
  

2.2.1.2 供方选择

招标文件确定后，就可以通过招标的方式选择供方（乙方或者卖方）。
招标文件应该对供方的要求做明确的说明，获得招标文件的供方根据招标文件的要求，编写项目建议书，并提交给需方，需方根据招标文件确定的标准对供方资格进行认定，并对其开发能力资格进行确认，最后选择出最合适的供方。

• 供方选择过程
  

2.2.1.3合同文本准备

如果需方选择了合适的供方（软件开发商），需方应该与供方（软件开发商）签订一个具有法律效力的合同；签署合同之前需要起草一份合同文本。

• 合同文本准备过程
  

2.2.2合同签署

• 合同签署过程就是正式签署合同，使之成为具有法律效力的文件；
• 同时，根据签署的合同，分解出合同中需方(甲方)的任务，并下达任务书，指派相应的项目经理负责相应的过程。
• 合同签署过程：
  

2.2.3合同管理

• 对需求对象（采购对象）的验收：
  验收过程是需方对供方交付的产品或服务进行验收检验，以保证它满足合同条款的要求
  违约事件处理过程：
  
• 对违约事件处理
  在合同的执行过程中，如果供方发生与合同要求不一致的问题，导致违约事件，需要执行违约事件处理过程。
  验收过程：

2.2.4合同终止

• 当项目满足结束的条件，项目经理或者合同管理者应该及时宣布项目结束，终止合同的执行，通过合同终止过程告知各方合同终止
• 合同终止过程：
  

2.3供方合同环境

2.3.1合同准备

2.3.1.1项目分析

项目分析是供方分析用户的项目需求，并据此开发出初步的项目计划，作为下一步能力评估和可行性分析之用。

• 项目分析过程
  

2.3.1.2项目竞标

• 能力评估；
• 可行性分析；
• 参加竞标。
• 项目竞标过程：
  

2.3.1.3合同文本准备

一般是需方(甲方)提供合同的框架结构，并起草主要内容，供方(乙方)提供意见。

• 合同文本准备

2.3.2合同签署

• 供方的合同签署过程也类似于需方的合同签署过程，但是这个阶段对于供方的意义是重大的，它标志着一个软件项目的有效开始，这个时候，应该正式确定供方的项目经理
• 这里需要说明的是项目任务书，项目任务书明确项目的目标、必要的约束，同时授权给项目经理
• 项目任务书是项目正式开始的标志，同时也是对项目经理有效授权的依据
• 项目经理需要对这个任务书进行确认
• 具体活动描述可以参见需方的合同签署过程。

2.3.3合同管理

• 合同跟踪管理过程
  合同跟踪管理过程是供方跟踪合同的执行过程
  
• 合同修改控制过程
  合同修改控制就是管理合同变更的过程
  
• 违约事件处理过程
  类似需方的情况，在此不再赘述
• 产品交付过程
  产品交付过程是供方向需方提交最终产品的过程
  
• 产品维护过程
  产品维护过程是供方对提交后的软件产品进行后期维护的工作过程
  

2.3.4合同终止

在合同终止过程中，供方应该配合需方的工作，包括：项目的验收、双方认可签字、总结项目的经验教训、获取合同的最后款项、开具相应的发票、获取需方的合同终止的通知、将合同相关文件归档.

2.4企业内部合同环境

2.4.1内部环境概述

企业内部项目实施管理的核心是确定任务范围和确保相关各方进行有效的配合，这可以通过相关各方之间的“协议”来保证，此处“协议”可视为“合同”。

三、软件开发过程管理

3.1软件质量

• 质量是产品的固有属性
• 用户会认为是软件运行可靠，不死机，界面友好，系统运行速度快，结果正确，产品交付及时以及服务好。
• 软件开发人员会认为质量好的软件应该是技术上没有差错，符合标准及规范的要求，技术文档齐全正确，并且系统容易维护。
• 还有一种用以衡量软件质量的指标，那就是每千行代码中包含的缺陷数。

3.1.1软件产品质量与过程质量

• 软件产品的质量是开发者和用户都十分关心的问题
• 传统的质量管理注重的是最终的产品质量，实现的是如软件测试一类的质量检验方法。
• 随着软件技术与用户需求的发展，软件的规模与复杂性导致了软件缺陷的增加，单纯依靠软件测试来纠正错误无论在时间，还是经济方面都是用户和开发组织所无法承受的
• 近年来质量管理向过程管理的控制发展，它所遵循的思想是，开发过程的质量直接影响着交付产品的质量，过程的改进自然就会得到高质量的产品。

3.2CMM、CMMI和ISO9000

3.3传统软件开发生命周期模型

3.4扩展软件开发生命周期模型

四、软件质量管理

4.1软件质量和质量保证

4.1.1质量的定义

• 内在质量，即产品本身的缺陷率和可靠性；
• 客户满意度，即产品与用户需求的一致性；
• 过程质量，即为了确保产品的内在质量和客户满意度，而对产品的设计与开发过程中所进行的监管和改进措施的效果。

4.1.2软件质量定义

• 我们可以这样定义软件质量：软件质量等于软件内在质量、过程质量与客户满意度的总和。

4.1.3软件质量工作

• 软件质量控制（SQC）
• 软件质量保证（SQA）
• 软件质量管理（SQM）

4.2软件质量度量

4.2.1软件质量度量的一般过程如下：

• 获取数据：按照一定周期、根据指定格式和量纲、收集与度量值相关的基础数据，作为度量的基础。常用工具包括各种报表、数据库等。
• 值转换：对原始数据进行数值转换，以便于后续的解释分析。
• 解释：根据度量目标和度量模型对度量值进行解释和分析，得到度量结果。常用工具包括检查表、Pareto图。
• 决策分析：识别是否符合质量要求。

4.2.2软件质量模型

4.2.2.1基于经验的模型

• McCall质量模型
  

• Boehm质量模型

• ISO 9126质量模型
  功能性：包括软件产品提供的用来满足用户需要的功能。
  a. 适合性suitability
  b. 准确性accuracy
  c. 保密安全性security
  d. 互操作性interoperability
  e. 功能性的依从性functionality compliance
  可靠性：与软件维护其性能等级的能力相关。
  a. 成熟性maturity
  b. 容错性fault tolerance
  c. 易恢复性recoverability
  d. 可靠性的依从性reliability compliance
  可用性：与使用软件所要花费的工作量相关。
  a. 易理解性understandability
  b. 易学性learn ability
  c. 易操作性operability
  d. 吸引性attractiveness
  e. 易用性的依从性usability compliance
  有效性：与软件执行过程中所占用的物理资源相关。
  a. 时间特性time behavīor
  b. 资源利用性resource utilization
  c. 效率的依从性efficiency compliance
  可维护性：与进行软件变更所需要的工作量相关。
  a. 易分析性analyzability
  b. 易改变性changeability
  c. 稳定性stability
  d. 易测试性testability
  e. 维护性的依从性maintainability compliance
  可移植性：与把软件转换到不同环境的能力有关。
  a. 适应性adaptability
  b. 易安装性install ability
  c. 共存性co-existence
  d. 易替换性replace ability
  e. 可移植的依从性portability compliance

4.2.2.2基于构建的模型

根据实际需要来构建合适的质量模型。

• Dromey质量模型
  1995年，由Dromey提出了一种通用软件质量模型，该模型的基本思想仍然是通过质量属性来描述软件质量，但并未简单的根据经验给出一组固定的质量特性或质量子特性，而是基于构建的思想，详细描述如何根据不同的需求来定义质量特性和建立对应的软件质量模型。
  该模型的重点在于自适应构建质量模型。
  

4.2.3软件质量度量的内容

4.2.3.1软件内在质量度量

• 缺陷密度：是指软件缺陷在一定软件规模下的分布，软件规模可采用代码行、功能点、对象点、数据点等。缺陷密度越低，产品质量越高。
• 平均失效时间：两次失效之间的时间间隔
• 复杂性：可用于评估软件系统的可测试性、可靠性和可维护性，可以提高工作量估计的有效性和精度
• 文档缺陷密度：是对在文档评审中发现的各种文档中的缺陷进行计算，包括文档规范相关的缺陷和文档内容方面的缺陷。
• 用户问题度量：是指一段时间内的用户上报的平均问题数，可称其为用户问题率
• 用户满意度度量：不同的公司给出的客户满意度指标各不相同。一般采用五分制等，由个用户代表进行评分，采取的方式有问卷调查、用户采访等。

4.2.3.2软件过程质量度量

4.2.3.2.1软件成熟度度量

4.2.3.2.2管理度量

4.2.3.2.3生命周期度量

• 需求分析过程质量度量：主要体现在需求文档（即需求规格说明书）质量和需求稳定性（即需求变更）的度量。
• 开发过程质量度量：过程生产率、累计缺陷总数。
• 测试过程质量度量：测试用例深度、效率、质量、执行质量、执行效率；缺陷报告有效性、质量；缺陷清除率。

4.2.3.3软件维护质量度量

• 缺陷积压处理度量
• 缺陷修复响应时间度量
• 缺陷修复响应度量
• 缺陷修复质量度量

4.2.4软件质量工具

4.2.4.1表格类工具

主要是指检查表，又称调查表、统计分析表，是一种列表形式，列表中列出了需要进行检查的所有项目，广泛用于软件开发各个阶段的同行评审过程中，主要用于问题识别，在软件开发中起到非常重要的作用。

4.2.4.2柱状图类工具

• 直方图：又称柱状图、质量分布图，是对一个群体或一个样本集出现频率的图形表示，由一系列等宽不等高的矩形表示数据分布的情况
• 帕累托图：又称排列图或主次图。可看做是一种特殊的直方图，所不同的是，帕累托图必须按照发生频率的大小进行降序排列。

4.2.4.3折线图类工具

• 游程图：又称趋势图或统计图，是表示某个参数随时间变化而变化的图形。游程图主要用于问题识别和问题分析
• 控制图：又称管制图，可看做是游程图的一个高级形式，它是通过测量、记录和评估过程质量特性值来判断过程是否处于控制状态的一种图，包括对某参数的测量值折线图、中心线、上控制限和下控制。

4.2.4.4枝状图类工具

• 因果图：又称鱼骨图，用来表示一个质量属性（即结果）与影响该属性的因素（即原因）之间的关系，其分布像鱼的骨架。

4.2.4.5离散点图类工具

• 散点图：是以点的序列来表示两个变量之间关系的一种图。主要用于展示和发现两组相关数据之间的关系类型和程度，并对未来的发展趋势进行预测。

4.3软件质量保证的措施

4.3.1质量保证计划

• 质量计划
• 质量体系
• 质量手册
• 质量体系、质量手册和质量计划之间的关系
  质量体系好比一个国家的法制机构，质量手册就如同宪法，是质量体系的文档化的体现。而为每个项目制定的质量计划类似地方法规，它在符合质量手册的前提下，根据自身的要求与特殊性，通过适当的裁减修正而来。
  
• 项目实施总体目标
• 项目分类
  质量倾斜型体系
  工期倾斜型体系
  成本倾斜型体系

4.3.2软件评审

4.3.2.1同行评审

• 审查
• 团队评审
• 走查
• 结对编程
• 同行桌查
• 轮查
• 特别检查

4.3.2.2同行评审过程

4.3.2.3同行评审的结果

• 正常
• 延期
• 取消

4.4软件测试过程管理

4.4.1软件测试过程模型

4.4.1.1V模型

• V模型的优缺点:
  优点:
  应用和管理简单
  可以把执行测试与测试设计分离
  可以尽可能早地找出缺陷，从而帮助改进项目内部的质量，并节约成本。
  缺点：
  测试滞后
  测试与开发文档难以一一对应
  缺少静态测试
  质量折扣

4.4.1.2W模型

• W模型的特点:
  强调尽早测试
  强调不断测试
  体现静态测试
• W模型的优缺点:
  优点:
  测试的活动与软件开发同步进行
  测试的对象不仅仅是程序，还包括需求和设计
  尽早发现软件缺陷可降低软件开发的成本
  缺点：
  需求、设计、编码等活动被视为串行的
  测试和开发活动保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作，这样就无法支持迭代的开发模型
  对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑.

4.4.1.3X模型

4.4.1.4H模型

4.4.2软件测试过程管理实践

• 测试人员的管理
• 工作产品的管理
• 测试用例的管理步骤：
  
• 缺陷的管理
  

五、软件项目团队管理

六、软件项目需求管理

6.1软件项目需求管理概述

6.1.1需求的定义

• IEEE软件工程标准词汇表(1997年)中将需求定义为：
  用户解决问题或达到目标所需的条件或权能(Capability)；
  系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能；
  一种反映上面(1)或(2)所描述的条件或权能的文档说明；
• 软件需求包括以下几个层次：
  业务需求（business requirement）
  用户需求（user requirement）
  功能需求（functional requirement）
  同时也包括非功能需求、软件需求规格说明（software requirements specification，SRS）等。

6.1.2软件需求各组成部分关系

6.2需求开发和管理过程

6.2.1需求工程所涉及的工作

6.2.2需求的来源

• 访问并与有潜力的用户探讨
• 把对目前的或竞争产品的描述写成文档
• 系统需求规格说明
• 对当前系统的问题报告和增强要求
• 市场调查和用户问卷调查
• 观察正在工作的用户
• 用户任务内容分析

6.2.3需求分析

需求分析包括提炼、分析和仔细审查已收集到的需求，为最终用户所看到的系统建立一个概念模型以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。
分析用户需求应该执行以下活动：

• 绘制系统关联图
• 创建用户接口原型
• 分析需求可行性
• 确定需求的优先级别
• 为需求建立模型
• 建立数据字典
• 使用质量功能调配

6.2.4需求规格说明

• 软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。
• 需求分析完成的标志是提交一份完整的软件需求规格说明书（SRS）。
• 软件需求规格说明作为产品需求的最终成果必须包括所有的需求。
• 在开发人员的组织中要为编写软件需求文档定义一种标准模板。
  

6.2.5需求验证

• 验证是为了确保需求说明准确、无二义性并完整地表达系统功能以及必要的质量特性
• 需求验证要求客户代表和开发人员共同参与，对提交后的需求规格说明进行验证，分析需求的正确性，完整性以及可行性等等
• 需求验证中的活动一般包括：
  审查需求文档
  以需求为依据编写测试用例
  编写用户手册
  确定合格的标准
  最后的签字

6.2.6需求变更管理

需求变更管理是项目管理中非常重要的一项工作。有效的需求变更管理能对变更带来的潜在影响及可能的成本费用进行评估。

需求变更管理中活动一般包括：

• 确定需求变更控制过程
  

• 建立需求变更控制委员会

• 进行需求变更影响分析
  

• 建立需求基准版本和需求控制版本文档

• 维护需求变更的历史记录

• 跟踪每项需求的状态
  
  

• 跟踪所有受需求变更影响的工作产品

• 衡量需求稳定性

6.2.7案例分析

题目描述：某软件开发项目已进入编码阶段，此时客户方提出有若干项需求要修改。由于该项目客户属于公司的重点客户，因此项目组非常重视客户提出的要求，专门与客户就需求变更共同开会进行沟通。经过几次协商，双方将需求变更的内容确定下来，并且经过分析，认为项目工期将延误二周时间，并会对编码阶段里程碑造成较大的影响。项目经理将会议内容整理成备忘录让客户进行了签字确认。随后，项目经理召开项目组内部会议将任务口头布置给了小组成员。会后，主要由编码人员按照会议备忘录的要求对已完成的模块编码进行修改，而未完成的模块按照会议备忘录的要求进行编写。项目组加班加点，很快完成了代码编写工作。项目进入了集成测试阶段。
题目：

1. 请说明此项目在进行需求变更的过程中存在的问题
2. 请分析该项目中的做法可能对后续工作造成什么样的影响。
3. 请简要说明整体变更控制流程。
   问题解析：首先，说明中提到“与客户就需求变更共同开会进行沟通”、“经过分析，认为项目工期将延误二周时间，并会对编码阶段里程碑造成较大的影响”、“将会议内容整理成备忘录让客户进行了签字确认”，这些都说明，对于这次需求变更，项目组是做了一些控制工作的。但是做得是不是到位呢?仔细分析一下，我们可以得出的结论是这些措施并不严谨和到位。不到位的地方主要是：没有提出一个正式的变更申请，因此项目也就没有安排正式的评审，也没有经过相应级别领导的批准，尤其是题目中提到了“对编码阶段里程碑造成较大的影响”，这种情况下由于关系重大(可能造成项目的延误)，是需要由一定级别的领导来进行批准的；项目组经过分析，得到结论“项目工期将延误二周时间，并会对编码阶段里程碑造成较大的影响”，这说明项目组分析了变更可能造成的影响，但是变更产生的影响是多方面的，不仅仅是进度，可能还有质量、人力资源、成本等，还有可能对项目已产生的工作产品造成影响，如需求文档、设计文档、代码，因此对于变更产生的影响分析是不全面的。
   其次，题目中提到“项目经理召开项目组内部会议将任务口头布置给了小组成员”，这也是一种不合适的做法。因为，通过题目说明我们已经了解到，这次变更造成的影响是比较大的，因此，项目经理应该制定出新的项目计划来指导后续项目的实施。接下来，题目中提到：项目组直接按照备忘录的要求来修改程序代码，修改完成后直接进入集成测试。这里面存在两个问题，第一，备忘录只是一个会议纪要性质的文件，并不能代替需求和设计文件，所以不能直接用来做开发。正确的做法是，根据客户新的需求修改需求文件和设计文件，并且这两个文件要通过客户的评审和确认，然后才能去修改程序代码；第二，程序代码修改完成后应该先进行单元测试，然后才能做集成测试。另外，从这一段题目说明中，我们也没有看到项目组进行了配置管理和版本管理的工作，所以，这也可能是一个做的不对的地方。

参考答案：
问题1：

1. 没有按照严谨的变更控制流程对整个需求变更做完整的记录和跟踪(对于需求变更请求没有记录、没有对变更进行正式的评审和批准、对于变更的结果没有验证）
2. 对需求变更可能造成的影响没有进行全面的评估和分析(只分析了需求变更对于工期的影响)
3. 没有修改项目管理计划并重新评审(项目经理不应口头布置任务，同时里程碑的调整没有通知相应的管理层)
4. 配置管理工作没有做好(没有对需求文件和设计文件进行修改，并升级相应版本；相应的模块编码的修改也没有进行版本控制)。
5. 变更结果没有跟客户沟通(需求变更实施完成后，没有让客户对最终结果进行确认)

问题2：

1. 没有遵循正式的变更控制流程可能导致需求变更的过程失控和不可追溯。
2. 没有对变更的影响进行完整的分析可能导致无法全面了解这次变更对项目的进度、范围、成本、质量等造成多大的影响。
3. 没有修改项目管理计划可能导致实际工作内容与计划有较大的偏差，使项目管理计划无法指导项目实施。
4. 没有对相应技术文档进行修改可能导致需求、设计与编码无法对应，不利于后期的测试和以后的维护工作。版本管理和配置管理没有做好可能导致在变更失败后无法将项目恢复到变更前的状态
5. 没有让用户对最终结果进行确认可能导致双方对变更结果的意见不一致，不利于项目验收和最终交付

问题3：

1. 提出书面的变更申请
2. 对变更可能造成的影响进行评估；
3. 提交CCB进行审批；
4. 获得批准后，安排相关人员实施变更
5. 对变更的结果进行验证。

6.3需求获取方法

• 访谈和调研
• 专题讨论会
• 脑力风暴
• 场景串联

6.4需求分析建模方法

• 用例分析方法
• 原型分析方法
• 结构化分析方法

6.5需求管理工具

七、软件项目开发计划

7.1 软件项目分解

7.1.1WBS （Work Breakdown Structure）定义

• WBS ——Work Breakdown Structure主要是将一个项目分解成易于管理的几个部分或几个细目，以便确保找出完成项目工作范围所需的所有工作要素，它是一种在项目全范围内分解和定义各层次工作包的方法
• WBS ——结构层次越往下层则项目组成部分的定义越详细，WBS最后构成一份层次清晰，可以具体作为组织项目实施的工作依据
• WBS ——通常是一种面向“成果”的“树”，其最底层是细化后的“可交付成果”，该树组织确定了项目的整个范围。但WBS的形式并不限于“树”状，还有多种形式。

7.1.2WBS分解类型

• 基于可交付成果的划分
  

• 基于工作过程的划分

7.1.3WBS表达形式

• 层次结构图（图形)
  

• 锯齿列表（清单）

• 

7.1.4WBS分解的一般步骤

• 总项目
• 子项目或主体工作任务
• 主要工作任务
• 次要工作任务
• 小工作任务或工作元素

7.2软件项目估算概念

7.2.1软件项目估算

• 软件项目估算——是指预测构造软件项目所需要的工作量以及任务经历时间的过程。主要包括三个方面：
  1.规模（即工作量）的估算确定每个软件功能所必须执行的一系列软件工程任务.
  2.成本的估算确定完成软件项目规模相应付出的代价.
  3.进度的估算估计任务的持续时间，即历时估计.

7.3软件项目规模估算

7.3.1LOC估算法

• LOC是常用的源代码程序长度的度量标准，指源代码的总行数。
• 代码行可以分为无注释的源代码行（NCLOC, Non-Commented Source Lines Of Code）和注释的源代码行（CLOC: Commented Source Lines Of Code），源代码的总行数LOC=NCLOC+CLOC
• 实际工作中常用KLOC（千代码行）来表示程序长度
• 虽然根据高层需求说明估计LOC非常困难，但这种度量方法确实有利于估计准确性的提高
• 随着开发经验的增加，软件组织可以积累很多LOC估计的功能实例，从而为新的估计提供了比较的基础
• 1代码行（1LOC）价值和人月均代码行数可以体现一个软件生产组织的生产能力，组织可以根据对历史项目的审计来核算组织的单行代码价值.

7.3.2FP估算法

• 功能点FP度量是在需求分析阶段基于系统功能的一种规模估计方法
• 该方法通过研究初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点数量.

7.3.2.1FP的计算

• 首先要计算未调整的功能点数UFC
• UFC的计算步骤如下:
  1.计算输入、输出、查询、外部文件和内部文件的数量
  2.判断项目复杂性，计算UFC

7.3.3PERT估算法

• 其理论基础是假设项目持续的时间以及项目完成时间是随机的，且服从某种概率分布
• PERT可以估计整个项目在某个时间内完成的概率。

7.3.3.1PERT估算法的计算

一种简单的PERT规模估算技术是假设软件规模满足正态分布

• 其一是软件可能的最低规模a
• 其二是软件可能的最高规模b
• 然后计算该软件的期望规模和标准偏差
  期望值=（最大规模+ 最小规模）/ 2
  标准偏差=（最大规模-最小规模）/6

较好的PERT估计技术是一种基于β分布和软件各部分单独估算的技术

• 对于指定的估计单元（可能是规模、进度、工作量等），由直接负责人给出估计结果，估计结果由3个值构成：最小值、最大值、最可能值。
  期望值=（最大规模+ 4* 最可能规模+ 最小规模）/6
  标准偏差=（最大规模-最小规模）/6
  总的软件规模和标准偏差为：
  

7.4软件项目成本估算

7.5软件项目进度估算

7.6软件项目进度计划

八、软件项目风险管理

8.1软件项目风险管理概述

8.1.1风险的定义

• 美国软件工程研究所将风险定义为损失的可能性
• 风险具有两大属性：可能性和损失，可能性是风险发生的概率，损失是指预期与后果之间的差异，我们用可能性(Likelihood)和损失(Loss)的乘积来记录风险损失。
• 风险的根源在于事物的不确定性，虽然无法避免不确定性，但是可以通过适当的方法对其进行控制与管理。

8.1.2风险的分类

• 项目风险
• 技术风险
• 商业风险

8.2风险识别

8.3风险评估

8.4风险计划

8.5风险控制与管理

九、软件项目跟踪控制

十、软件项目配置管理

十一、软件项目收尾