【软件项目管理】期末复习

若本文对你有帮助，请点赞、关注我！

       本课、本教科书、本期末考试都能让我绝望。倒不是担心挂科的问题。期末有一道大题会出自平时的课后作业or课堂讨论，例如我就遇到了下方的第3题。百度不到的题就看PPT或自编。

       这门课需要组队6-7人，每组选一组长，个人觉得（当组长）非常麻烦，无论课上课下，每节课都有任务。不过期末成绩会比普通组员高些。//心里OS：我宁愿当吃瓜群众(￣(工)￣)趁着排版，重新看了遍PPT，实在觉得没什么意思。

课后作业&课堂讨论（没有标准答案，讨论结果已删）

1、软件项目合同周期为5个月，项目款为150万，已经开发了6个月，公司投入了100万，客户首付款仅为30万，现在客户的需求还在经常的变更中，如果不改，客户说其它的款就不付了，如果继续修改，什么时候是个头？如果你是项目经理该怎么办？

2、查阅资料了解国际、国内软件市场的现状。

       收集、整理一家国际或国内知名软件企业的相关资料，包括公司背景、创始人（或现任负责人），主要软件产品，所属领域。和你对这个公司的看法和发展建议等等。

       要求：每小组选择一个主题，课后将相关资料整理成电子文档提交，课上抽查部分同学讲解PPT。

 3、某学院要开发一个小型的教务管理系统，要求对学院的各种教学活动进行管理，例如课程安排、学生成绩统计、学分统计、考试安排、监考安排等等，基本的功能需求可以与教学秘书进行商议，一些管理层面的需求还需要通过开会讨论进一步确定。

       系统由一名教师带领四名学生开发，教师比较熟悉学院的业务流程，也具有开发软件系统的经验，但是需要在完成教学任务之余参与项目开发，四名学生没有项目开发经验，其中两名大三学生、两名大四学生，在课余时间完成相关开发工作。

       项目的开发周期为4个月，预付金为1万元，到项目结束后支付其余费用4万元。

       对以上项目的潜在风险进行分析（应用德尔菲（Delphi）法）和给出相应解决方法。

 4、某公司2018年初承接了一个周期为一年的ERP信息系统项目，并指派项目经理小张负责。该项目属于定制型项目，涉及的用户方较多，小张根据自己的经验预测到项目可能会涉及频繁的需求变更，因此小张在将项目组分成业务组、实施组、开发组后，定义了如下需求管理及控制流程：

（1）指派专门的业务组进行需求分析；

（2）业务组获得需求分析文档后，一周内进行技术方案设计；

（3）技术方案完成后，交到开发组；

（4）需求分析、技术方案完成后，开发组进行开发；

（5）开发组根据开发计划进行定制开发工作；

       项目进行过程中，发生了如下事件，导致项目延期半年才完成：

[事件1]根据2018年初的计划开发完成了ERP信息系统项目并上线，但用户没有真正使用。2018年10月推广使用的时候发现，业务流程有缺失，程序有BUG，于是项目组重新按照以上流程梳理了需求，并重新开发上线，但项目已经延期。

[事件2]项目总结会上，开发组提出需求分析在深度、广度上不够，导致开发经常返工，任务延期。结合案例及你的经验，请说明项目经理小张在需求管理及控制过程中存在哪些不足？如果你是小张的经理，请帮助小张改进需求管理及控制过程中的不足。

5、项目经理小王刚刚完成公司安排的项目开发任务，已上线完成，但让客户签验收文件的时候，客户不同意，理由是没有完成，小王拿到需求功能单与客户逐一对比，小王说需要功能已全部开发完毕，并上线，可以签用户验收单。但客户坚持不签，理由如下：

（1）打开一个业务界面太慢，最长得10秒多；

（2）现在上线一个月，还是偶尔会出系统崩溃的问题，而且解决速度很慢。

       你认为小王的公司在管理上有哪些不足？如果你是小王，你应该怎么做？

6、项目经理小刘接到一个ERP的项目，公司领导让小刘做一下进度估计，小刘对ERP的SRS详细看了后，给领导的时间为6个月。公司领导满意地回了办公室，到6个月的时候，公司领导来问小刘项目是否可以给用户上线，小刘说，项目里边的逻辑特别复杂，用户需求还有变更，现在系统内部刚刚开发完，还没有进行测试，现在不适合上线。

       公司领导说：现在客户那边要系统上线怎么办？

       你认为小刘做的有哪些不足？如果你是项目经理应该怎么做？如果你是公司领导你会有哪些改进？

7、什么时候定义模型，为什么 ？模型为软件项目过程中启到什么作用？你知道那些模型？

8、A公司从事软件开发，与客户前期交往后，客户很认可，通过商务关系和公司公开竞标的方式得到了项目，由于竞标时的总价格，公司按用户需求开发，但开发过程中发现，公司不但不挣钱，反而会赔钱。

       如果你是项目经理，你认为A公司出现的问题有那些，怎么改进？ 

9、项目经理小李负责某热力发电厂MIS项目中的生产数据统计模块，由于整体项目为用户定制开发，生产数据统计处处长为最主要的需求提供者，根据统计处长提供的需求，项目组在加班情况下，2个月成功开发出项目，正准备上线，电厂发生人事变动，生产数据统计处处长和计划处处长对换，由原计划处处长负责生产统计模块，计划处处长看到要上线的软件，提出了很质疑和新需求，项目组在整理新需求确认后，再次加班的情况1个半月的情况，开发出项目，通过数据整合和各部门梳理等4个月准备时间，系统终于上线了。这是电厂人事又发生了变动，原统计处长又调回统计处工作，他上任后 立马要看上线的软件，一看和他提的需求有很大改变，他立即要求，按他的需求更改回去。但小李团队的代码已变更，再更改回去也需要很长时间。

       如果你是小李，你该怎么办？你认为小李那些不足？ 

10、Q公司是一家应用软件开发公司，最近与 A 公司签订了一个财务管理系统开发项目的合同，需要挑选一位项目经理，并组建一个项目团队。由于 Q 公司正同步进行多个项目，没有足够数量的项目经理，而该项目又必须马上开始，于是公司领导决定任命有多次参与类似项目开发经验的程序员薛工承担此项目的管理工作。        

       薛经理接到任命后，立即开始着手组建项目团队，热火朝天地开始了人员的招聘，面试等工作。人员确定以后，团队进入了项目开发阶段，工作进行一段时间后，擅长编程的薛经理发现，管理工作远不如他原来的编程工作来得简单。从项目一开始，整个团队就不断出现问题，成员之间矛盾接连不断，项目的任务也不能按时完成……项目工作一度中止，薛经理急得像热锅上的蚂蚁。

       你认为薛经理下一步怎么样调整自己？ 如果你是公司领导你会怎么作比较合适！ 

 PPT（考前把PPT复制到Word里，考试时搜关键词。当然如果你好好复习过，就无视这句话）

 第一章 导论

1. 软件项目产品特点

       抽象性、缺陷检测的困难性、高度的复杂性、人员管理难度大。

2. 软件失控项目

       指软件项目在进行时遇到困难，导致大大超过可控制范围（时间、费用、功能性需求）的项目。      

       软件项目失控的量化定义：显著未实现目标和至少超出原定预算30％的项目。Robert L.Glass 观点：30％提高到100％

3. 软件项目失控原因

（1）需求不明确        

       需求过多；需求不稳定；需求模棱两可；需求不完整。

（2）不充分的计划

       工作责任范围不明确； 每个开发阶段的提交结果不明确； 开发计划没有指明里程碑或检查点，也没有规定设计评审期； 开发计划没有规定进度管理方法和职责，导致无法正常进度管理。

（3）过于乐观估算

       处于客户和公司上层的压力在工作量估算上妥协； 设计者过于自信或出于自尊心问题，对于一些技术问题不够重视； 过分相信经验。

（4）采用新技术

       技术无法扩展； 技术是错误解决方案； 技术不具有要求的功能性。

（5）管理方法缺乏或不恰当              

       合适的管理可以避免技术障碍、改进计划，稳定需求。

（6）性能问题          

       系统无法快速地运行满足用户的需求。

（7）团队组织不当              

       项目组织过小、缺少资深人员。

（8）人际因素                

       开发商和客户、销售人员和技术人员、项目管理者和开发人员。

4. 软件工程活动

       指生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。它列出了需要完成的一系列任务的框架（Framework），它规定了完成各项任务的工作步骤。

①问题定义     

       关键问题：“要解决的问题是什么”。

②可行性研究     

       关键问题：“上一个阶段所确定的问题是否有行得通的解决办法”。

③需求分析

       关键问题：“目标系统必须做什么”      重要任务：用正式文档(specification)准确地记录对目标系统的需求 。

④概要设计      

       基本任务：“怎样实现目标系统?”      主要任务：设计程序的体系结构。

⑤详细设计

       主要任务： “应该怎样具体地实现这个系统”    

⑥编码和单元测试     

       关键任务：写出正确的容易理解、容易维护的程序模块。

⑦综合测试（确认）   

       关键任务：通过各种类型的测试(及相应的调试)使软件达到预定的要求。

⑧软件维护（支持）   

       关键任务：通过各种必要的维护活动使系统持久地满足用户的需要。  

       4类维护：改正性维护，适应性维护，完善性维护，预防性维护。

5. 软件工程原则

（1）选取适宜的开发模型（2）采取合适的设计方法（3）提供高质量的工程支持（4）重视开发过程管理

6. 软件工程模型

                                                                 图1.6.1 软件工程的演化过程 

       在实际从事软件开发工作时，软件规模、种类、开发环境及开发时使用的技术方法等因素，影响软件工程各项活动。      

       软件工程模型（生命周期模型）规定了把软件工程活动划分成哪些阶段及各个阶段的执行顺序，也称为过程模型。

7. 瀑布模型 (Waterfall)

       20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。

       特点：（1）软件生存周期的顺序性（2）推迟实现的观点（3）质量保证的观点

                                                                 图1.7.1 传统的瀑布模型  线性的 

       思想：从制作时间上按工序把问题化简、将功能实现与制作分开便于分工协作

       优点：（1）奠定了软件工程方法的基础（2）流水依赖，便于分工协作（3）推迟物理实现，易于修改文档，有复审质量保证。

       不足：与用户见面晚，成功率低，一般为25％

       适用范围：适用于系统要求明确的系统，各种应用软件的开发均可使用。

8. 快速原型模型 (Prototype)

       所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

                                                                 图1.8.1 快速原型模型

                                                                 图1.8.2 快速原型开发过程

       快速原型开发途径：（1）仅模拟软件系统的人机界面和人机交互方式。（2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。（3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。

       适用范围：适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员不能很好交流或 通信有困难的情况。

9. 螺旋模型

       基本思想：使用原型及其他方法来尽量降低风险,可以看作在每个阶段之前都增加了风险分析过程的快速原型模型。

                                                                 图1.9.1 简化的螺旋模型  

                                                                 图1.9.2 完整的螺旋模型 

       优点：（1）支持用户需求的动态变化。（2）原型可看作形式的可执行的需求规格说明，易于理解，作为继续开发的基础，为用户参与所有关键决策提供了方便。（3）强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。

       缺点（1）如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；（2）使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。

       适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。

10. 软件项目管理内容

①软件项目管理的定义  

       根据PMI项目管理的定义总结：在软件项目活动中运用一系列的知识、技能、工具和技术，以满足软件需求方的整体要求。

②软件项目管理的过程  

       启动软件项目；制定项目计划；跟踪及控制项目计划；评审项目计划；编写管理文档。

③软件项目管理的内容  

       软件项目需求管理；软件项目估算与进度管理；软件项目配置管理；软件项目风险管理；软件项目质量管理；软件项目资源管理。

第二章 软件项目需求管理

1. 软件需求类别

①用户需求    

       从用户角度描述系统的需求，只描述系统的外部行为，并且只通过自然语言、图表、图形等叙述。

       问题：描述困难，需求混乱。

       原则：标准的格式；使用一致的语言；使用特殊文本强调关键的需求；尽量避免专业术语。

②系统需求    

       从开发人员角度描述系统的需求，是系统实现的依据，通常采用结构化语言、PDL过程设计语言等描述。  

       功能需求： 描述系统应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。功能需求应具有全面性和一致性。

       领域需求：来源系统应用的领域，反应该领域的特点，可能是功能需求或非功能需求。需要领域知识确定。

       非功能需求：指那些不直接与系统的具体功能相关的一类需求。它们与系统的总体特性相关，定义了对系统提供的功能或服务的约束。

2. 软件需求质量评价

①正确性

       当且仅当其中每条需求都代表了构建软件系统所需要完成的事情，则需求是正确的。

②无歧义

       当且仅当需求有一种解释。  

③完备性

       当且仅当需求集合描述了用户关心的所有有意义的需求，包括功能、性能、设计约束、属性及外部接口相关的需求。

④一致性

       当且仅当任意两个需求之间的子集没有矛盾。  

⑤根据重要性和稳定性分级  

⑥可验证性

       当且仅当任意需求集所包含的每条需求都是可验证的。一条需求是可验证的当且仅当存在一个有限的、合算的过程，人或机器可以用它来确定所开发的软件系统是否满足该需求。  

⑦可修改性

       当且仅当每一条需求易于完整、一致性的进行变更，且并不改变需求的结构和风格。  

⑧可跟踪性

       当且仅当每一条需求都是可追溯的（来历清晰），并且存在一种机制使得在以后的工作中引用该需求是可行的。

⑨可理解性

       用户和开发者都完全理解它的整体行为、所提供的功能及其中每条需求的含义。

 3. 需求获取

①确定需求开发过程

       包括确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，并经它们编写成文档。

②编写项目视图和范围文档

       包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。

③用户群分类

       分清客户与用户、用户群分类。

④选择产品代表

       为每类用户至少选择一位能真正代表他们需求并能做出决策的人作为哪一类用户的代表。他们能一直参与项目开发并有权作出决策。

⑤建立核心队伍

       把同类产品或待开发产品的先前版本的用户代表召集起来，建立典型用户的核心队伍，从他们那里收集目前产品的功能需求和非功能需求。

⑥确定使用实例

       从产品代表处收集他们使用软件完成所需任务的描述——使用实例，讨论用户与系统间的交互方式和对话要求。

       使用实例包括完成某项任务的许多逻辑相关任务和交互顺序，描述时列出用户和系统之间交互或对话的顺序。     每个使用实例叙述成详细的功能需求，一个使用实例可以引申出多个功能需求，使用户可以执行相关的任务；并且多个使用实例可能需要相同的功能需求。

       使用实例方法是以任务为中心和以用户为中心的。

⑦召开应用程序开发联系会议

       是范围广、内容简洁的专题讨论会，也是分析人员与产品代表之间一种很友好的合作办法，并由此拟出需求文档的底稿。

⑧分析用户工作流程

       观察用户执行业务任务的过程，有助于明确产品的使用实例和功能需求。

⑨确定质量属性

       确定质量属性和其他非功能需求。例如系统如何很好的执行某些行为或让用户采取某一措施的陈述就是质量属性。

⑩检查问题报告

       通过检查当前系统的问题报告进一步完善需求。

⑪需求重用

       如果用户要求的功能与已有的软件产品相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组织，从而达到需求重用的目的。

 4. 需求分析

       包括提炼、分析和仔细审查已收集到的需求，以确保所有的项目参与者都明白其含义并找出其中的错误、遗漏或其他不足的地方。通常把需求中的一部分用多种形式来描述，分析不同的视图将揭示出一些更深的问题。

①绘制关联图

       用于定义系统与系统外部实体间的界限和接口的简单模型，同时也明确通过接口的信息流。

②创建用户接口原型

       通过原型获取需求。

③分析可行性

       在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险。

④确定需求优先级

       应用分析方法确定使用实例、产品特性和单项需求实现的优先级。

⑤建立需求模型

       图形分析模型是对软件需求规格说明的极好的补充说明。

⑥编写数据字典

⑦应用质量功能调配

5.  编写需求文档

①需求文档的编制与作用

       软件需求文档包括用户需求和详细的系统需求描述，是对软件系统要求的正式陈述。软件需求必须具有综合性，谨慎变更。

       注意事项： 语句和段落尽量简短；表达时采用主动语态；语句完整，语法、标点正确无误；使用术语要与词汇表中保持一致；陈述时采用一致的样式；避免模糊的主观的术语，如“优越”；避免使用比较性词汇，尽量给出定量说明。 

6. 软件需求文档

①需求文档的编制与作用 

②软件需求规格说明    

       需求文档采用软件需求规格说明的形式。规格就是一个预期的或已存在的计算机系统的表示。规格定义系统所必须具备的特性，同时留下很多特性不做限制。

       SRS（Software Requirement Specification) 功能规格说明、需求协议、系统规格说明。

       精确地阐述一个软件系统必须提供的功能和性能以及它所考虑的限制条件，是对外部行为和系统环境接口的简洁完整的描述性文档。SRS包括功能需求和非功能需求。

 7. 需求验证

①需求验证过程

       需求验证分析需求规格说明的正确性和可行性，检验需求能否反映客户的意愿。需求验证关心的是需求文档完整的草稿，而需求分析关心的是不完整的需求。    

       在构造设计开始之前，通过需求验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，能大大减少项目后期的返工现象。

       需求验证的步骤：审查需求文档；依据需求编写测试用例；编写用户手册；确定合格的标准。

       （1）审查需求文档：组织由不同代表组成的小组，对需求规格说明书及其相关模型进行仔细的检查。对团队成员进行培训会提高评审的水平。

       （2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致，同时还可以使用测试用例来验证需求模型的正确性。

       （3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能，而辅助需求如质量属性、性能需求等对用户不可见的功能则在SRS中予以说明。

       （4）确定合格的标准：确定合格的标准是让用户描述什么样的产品满足他们的要求和适合他们使用，合格的测试是建立在使用情景描述或使用实例的基础之上的。

②需求验证的内容

       （1）有效性检查：对于每项需求，首先必须证明它是正确有效的，确实能解决用户面对的问题。

       （2）一致性检查：在需求文档中，需求不应该冲突，即对同一系统功能不应出现不同的描述或相互矛盾的约束。当两条需求不能同时满足时，则定义二者是不一致的。采用形式化的需求规格说明可以用软件工具验证需求的一致性。

       （3）完备性检查：需求文档应包括所有系统用户想要的功能和约束。如果所有可能的状态、状态变化、转入、产品和约束都在需求中作了描述，则说明这个需求集合是完备的。需求的完备性必须由用户来检验，可以通过原型系统来实现。

       （4）现实性检查：指检查需求以保证能利用现有技术实现，还要考虑系统开发的预算和进度安排。分析员可以参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。

       （5）可检验性检查：指描述的需求能够实际测试。为减少在客户和开发商之间可能的争议，描述的系统需求应该总是可以检验的。这意味着能设计出一组检查方法来验证交付的系统是否满足需求。

       （6）可跟踪性检查：指需求的出处被清晰的记录，每一系统功能都能被跟踪到要求它的需求集合，每一项需求都能追溯到特定用户的要求，它能为评估需求变更对系统其他部分的影响提供帮助。

       （7）可调节性检查：指需求变更能够不对系统的其他部分带来大规模的影响。

       （8）可读性检查：指需求说明是否能被系统购买者和最终用户读懂。

8. 需求管理的必要性

①需求供求双方固有的矛盾                

②需求具有易变性和难以表达性

       需求变化被认为是容易的，40％～60％的问题是由于需求分析阶段的问题引起；软件需求难以借助其他方式表述。          

③需求错误出现的高频性和修复的高昂成本    

9. 需求管理活动

       需求管理是在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。进行需求管理的第一步是建立需求管理规划：需求识别；需求变更管理过程；需求跟踪；（需求之间，需求和设计之间）自动化工具。    

10. 需求变更管理

①需求变更的原因    

        在项目的早期所有的问题不可能完全定义；随着软件项目的进行，开发人员对问题的理解发生变化，这些变化反馈到需求中；大型系统的需求可能是冲突或是矛盾的，系统需求是它们之间的妥协，这种妥协可能发生变化；系统购买者和最终用户很少是同一人。           

②需求变更管理过程    

       首先要建立变更控制委员会。 变更控制委员会是一个由软件项目风险承担者组成的小组，负责需求变更的管理工作，需求变更的一切最终裁决都由其来完成。            

③需求变更影响分析    

       进行变更影响分析，应评估每项选择的需求变更，以通过它对项目计划安排和其他需求的影响，同时明确与变更相关的任务并评估完成这些任务需要的工作量。     变更对进度的影响，主要看变更是否处于项目的关键路径。

④需求变更控制流程    

11. 需求状态

①需求的属性    

       需求属性的定义和更新是需求管理的重要内容。需求的属性为需求提供了背景资料和上下文关系，对于大型软件项目尤为重要。创建时间；版本；创建者；批准者；需求状态；需求的原因或根据；需求涉及的子系统；需求涉及的产品版本；需求的验证方法或测试标准；需求的优先级；需求的稳定性。

②需求状态    

       需求状态指某一时间点需求的一种情况反映。建立需求状态是为了表示需求的各种不同情况。客户需求分为四种情况：客户可以明确且清楚地提出地需求；客户知道需要作些什么，但不能明确地需求；需求可以由客户提出，但需求的业务不明确,需要等待外部信息；客户本身也说不清楚。                     

       根据对需求的不同处理，需求状态分为：已建议；已批准；已拒绝；已设计；已实现；已验证；已交付；已删除。

12. 需求文档版本控制

       需求文档版本控制是需求管理的必要方面，是保证开发人员得到最新软件需求的唯一手段。统一确定需求文档的每一个版本，保证每个成员都能得到当前的需求版本；清楚地将变更写成文档，并及时通知项目开发所涉及的人员；为尽量减少困惑、冲突、误传，应只允许指定的人来更新需求文档；

13. 需求跟踪     

①需求跟踪的必要性    

       CMM三级要求团队具备需求跟踪能力：在软件工作产品之间维护一致性。工作产品包括软件计划、过程描述、分配需求、软件需求、软件设计、代码、测试计划以及测试过程。

误解：依照“需求分析——系统设计——编码——测试”的顺序，，每一步的输出就是下一步的输入，因此不必担心设计、编码、测试会与需求不一致，从而省略需求跟踪。

       跟踪能力信息使得变更影响分析十分便利，有利于确认和评估某个建议的需求变更所必须的工作。

②可追溯性信息    

       进行需求跟踪，就要对需求和需求之间以及需求和系统设计之间的许多关系进行追溯，同时还有清楚需求和引起该需求的潜在原因之间的联系。当需求发生变更时，必须追踪这些变更对其他需求和系统设计的影响。可追溯性是需求描述的一个总体特性，反映了发现相关需求的能力。

       分类：源可追溯性信息； 需求可追溯性信息 设计可追溯性信息。

③需求跟踪的实现    

       两种分式：正向跟踪：以用户需求为切入点，检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。

                                                                 图2.13.1 需求跟踪的双向模式——需求链

       通用方法：需求跟踪矩阵，前提条件是标识需求链中各个过程的元素。    

④需求跟踪的作用  

       需求跟踪提供了一个表明与合同或说明一致的方法。完善的需求跟踪能够降低软件产品的生存周期成本，改善软件产品的质量，对于软件组织的长远发展大有裨益。

       在需求验证中便于确保所有需求被应用； 有助于需求变更影响分析； 便于需求的维护； 便于测试时找出问题所在； 便于项目跟踪；减小项目的风险； 简化系统的再设计； 易于软件重用。

⑤需求评审  

       需求评审由开发方和客户方的代表共同完成。  

        (1)评审方式    

       非正式评审由承包商人员与尽可能多的系统项目相关人员讨论需求，力求发现问题，为下一步的正式评审做准备。    

       正式评审时，开发团队要拿着需求遍访客户，逐条解释需求含义。评审团队则检查需求的一致性和完备性等，并把冲突、矛盾、错误和遗漏正式记录下来，然后由用户、系统购买者和开发商三方协商解决方案。

       (2)注意事项

        严格控制每一次评审的文档规模及持续时间  评审工作要分段进行  对讨论的问题进行控制  避免无谓的争吵。

第三章 软件项目成本管理

1. 什么是成本

        “生产一种产品所需的全部费用”——现代汉语词典。“交换中所放弃的东西”——韦伯斯特词典。 “为完成软件项目而支付的货币量”——软件项目。具体包括：人力资源成本，软、硬件成本，商务活动成本，其他成本费用。又可以分为有形成本、无形成本；直接成本、间接成本；还要考虑开发成本和维护成本。

2. 成本管理

        项目成本管理的目标：确保在批准的预算范围内完成项目所需的各项任务。成本管理活动包括：软件系统规模估算、软件项目成本估算、软件项目成本预算制定、软件项目成本监控。

3. 软件项目估算的时机

        软件项目估算是随项目的进行而进行的一个逐步求精的过程。估算的时机和精度是相互矛盾的。

        软件项目估算的时间点：

（1）客户需求：时间点E1的估算可以为软件组织提供初步信息，决定将开发的软件是否对本组织有利。

（2）产品定义：时间点E2的估算有助于软件组织在进入产品开发之前再次权衡产品的可行性。

（3）系统设计：时间点E2的估算主要考虑如何将设计好的系统开发出来及有没有被忽视的问题，不会决定是否终止项目，但会影响以后各阶段资源的分配。

（4）系统实现：E4初步的软件产品可用于系统测试，前面各项活动耗费的资源和软件工作可以获得，从而对原有估算进行调整。

（5）系统运行：E5所有不确定因素成为已知量，估算工作是对估算过程的评价。

4. 软件规模

        即软件的程序量。软件规模是软件工作量的主要影响因素。对软件规模的估计要从软件的分解开始。软件的分层结构对应工作分解结构（WBS）  

5. 软件规模估计过程

        在技术允许的条件下，应从最详细的WBS开始；精确定义度量的标准；估计底层每一模块的规模，汇总以得到总体估计；适当考虑偶然因素的影响。

        常用的度量标准：代码行和功能点。

①代码行（LOC，Lines Of Code）

        指源代码的总行数。无注释的源代码行(NCLOC)和注释的代码行(CLOC)

        LOC = NCLOC + CLOC 常用KLOC表示程序长度。

        特点：准确，可以根据经验进行估计，相应的工具较多，但根据高层需求说明估计较困难。

②功能点（FP，Function Point ）

        基于系统功能的一种规模估算方法，通过研究初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点的数量。 首先计算未调整的功能点数UFC（Unadjusted Function Point Count ）

功能点度量：

        有助于在软件项目的早期作出规模估计，但无法自动度量。一般在早期的估计使用功能点，然后依据经验将功能点转化为代码行，再使用代码行继续进行估计。

        使用情况：估计新的软件开发项目；应用软件包括很多输入输出和文件活动；拥有经验丰富的功能点估计专家；拥有充分的数据资料，可以相当准确的将功能点转换为LOC。

③计划评审技术（PERT）规模估计

        20世纪50年代末由美国海军开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的、用于项目进度计划的一种技术。其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以估计整个项目在某个时间内完成的概率。

6. 软件生产率估算

        估计出软件项目的代码数量之后，需要将其转换为人月数。估算人月数需要分析影响每个人月平均完成代码数量的因素，即确定软件生产率因素。    

①影响因素    

        能够找到影响因素，但不能确定影响因素和生产率之间的定量关系，只能通过比较得到一些结果。另外环境因素对生产率的影响也较为显著，如开发环境面积、安静程度、私密程度、受干扰程度。

②生产率数据的获取  

        （1）选择最近完成的，在规模、语言、应用类型、团队开发经验等方面与待完成项目相似的项目；  

        （2）获得各个项目的LOC数据，各项目使用相同的计数方法；  

        （3）对于更改过的程序，记录更改代码所占比例；  

        （4）计算投入到每个项目上的人员数量，包括设计、实现、测试、文档人员；  

        （5）计算各个项目的软件生产率，LOC/PM，进而求出平均值作为类似项目的典型软件生产率。

        成本估算是对完成软件项目所需费用的估计和计划，是软件项目计划中的一个重要成分。理想的成本估算是根据历史标准估算，但由于软件项目和计划变化多端，把今后活动与现实对比几乎不可能，并且在大型项目中，还应考虑今后几年的员工工资结构和管理费用是否会发生变化。

 7. 成本估算方法——专家判定

        就是与一位或多位专家商讨，专家根据自己的经验和对项目的理解对项目的成本作出估算。最好由多位专家进行估算，并需要采取某种方法合成一个最终的估算值。

        （1）求中值和平均值：方法简单，但易于受到极端估算值的影响产生偏差。

        （2）召开下组会议：小组讨论，统一或同意某一估算值。能去掉一些极端的估算，但易于受权威人士或能言善变人士的影响。

        （3）Delphi技术：1948年Rand公司产生的一种预测未来事件的技术，随后作为在联合规划和成本估算中使专家意见一致的方法。

                 步骤： 协调员给每位专家一份软件规格说明和一张记录估算值的表格； 专家无记名填写表格，可以向协调员提问，但相互间不能讨论； 协调员对专家添在表上的估算进行小结，据此给出估算迭代表，要求专家进行下一轮估算。迭代表上只标明自己的估计，其他估计匿名； 专家重新无记名填写表格。该步骤适当的重复多次，整个过程不得小组讨论。

        （4）Wideband Delphi技术：将小组会议和Delphi技术结合。

                 步骤： 协调员给每位专家一份软件规格说明和一张记录估算值的表格； 专家开会讨论软件产品和任何估算相关的问题； 专家无记名填写表格； 协调员汇总结果，将结果以估算迭代表形式返回给各个专家，迭代表样式与Delphi技术相同，但不包含书面理由； 召开小组会讨论上次估计结果，自愿修改个人估计； 如此反复，直到各个专家的估计逐渐接近，达到一个可以接受的范围。

 8. 成本估算方法——类比

        就是把当前项目和以前作过的类似项目比较，通过比较获得其工作量的估算值。    

        该方法的前提似确定比较因子，即提取软件项目的特性因子作为比较的基础。常见因子有软件开发方法、功能需求文档数及接口数等。    

        类比估算可以在整个项目级和子系统级上进行。    

        类比方法的优点在于估算值是根据某个项目的实际经验得出，可以对这一经验进行研究推断新项目的某些不同之处以及对成本可能产生的影响。缺点是无法弄清以前项目在多大程度上代表新项目的特征。

9.  成本估算方法——自顶向下

        就是从软件项目的整体出发，根据将要开发的软件项目的总体特性，结合以前完成项目积累的经验，推算出项目的总成本或工作量，然后按比例分配到各个组成部分中去。    

        优点：在于其对系统级的重视。

        缺点：难以识别低级别上的技术性困难并且由于考虑不细致，有时会遗漏所开发软件某些部分。

10. 成本估算方法——自底向上

        就是把待开发的软件逐步细化，直到能明确工作量，由负责该部分的人给出工作量的估算值，然后把所有部分相加，得到总工作量。     与自顶向下互补，需要更多精力。

        优点：较为准确。

        缺点：易于忽略许多与软件开发有关的系统级成本，如系统集成、配置管理、质量保证等，所以给出的总估算值偏低。

        常见的方法：任务单元法。

11. 成本估算步骤

①建立目标        

        帮助建立成本估算目标的主要因素是软件项目当前所处的生命周期阶段，它大致对应对于软件项目的认识程度和根据成本估算值而做的承诺程度。

②规划需要的数据和资源        

        把估算看作一个小型项目，初期制定项目计划。    

        具体方法：目的、产品和进度、责任、过程、需要的资源、假定。

③确定软件需求        

        对于估算来说，软件需求说明书的价值由其可检验的程度决定。

④拟定可行的细节          

        尽可能做到软件估算目标所要求的细节。

⑤运用多种独立的技术和原始资料

        避免任何单一方法的缺点且充分利用其优点。

⑥比较迭代各个估算值        

        对各估算值比较，分析得到不同估算值的原因，找出可以改进估算的地方，提高估算的准确度。

⑦随访跟踪          

        收集实际成本及其进展的数据并将它们与估算值进行比较。

---

包括监控成本预算执行情况，确保正在执行的预算计划是有效的，对于不合适的计划进行修改变更后即使通知项目干系人。

12. 成本管理常见问题

        项目成本估算不准确；预算不详细；成本预算变更不及时。

13. 软件项目进度监控要素

        资源计划的完备性；成本估算的准确性；预算计划的有效性；成本控制过程的完备性。

14. 赢得值分析法

        EVA（Earned Value Analysis）是计算实际花费在一个项目上的工作量与预计项目总成本及完成时间的一种方法，主要依赖于被称为“已获值”的一种度量。可以计算出成本和进度表的性能指标，并能了解项目与原定项目计划相比的执行情况及预测未来的执行情况。采用EVA分析是，时间间隔通常为一个月或一周。

第四章 软件项目进度管理

1. 制定项目计划

        软件项目计划定义工作并确定完成工作的方式，对主要任务及需要的时间和资源进行估计，定义管理评审和控制的框架。正确的文档化计划与项目实际的结果进行对比，能够使计划人员发现估计的错误从而改进估计过程，提高估计的准确性。

1. 制定项目计划的原则        

        项目计划在项目开始的时候制定，并随着项目的进展不断发展。开始时由于需求模糊，因此考虑的重点放在需要更多知识的地方以及如何去获取这些知识。

2. 软件项目计划的要素        

        包括目标、合理的概念设计、工作分解结构、规模估计、工作量估计和项目进度安排。

3. 软件项目计划的逻辑要点    

• 需求分析：把模糊的需求准确化    
• 项目的概念设计：项目计划的基础，定义工作分解结构    
• 资源配置和进度安排：必须与需求同步更新    
• 需求足够清晰时，进行详细设计，制定实现策略并纳入计划    
• 充分理解项目各部分后，确定实施细节并在下次计划更新时形成文档    
• 在整个项目周期中，项目计划为各种资源配置提供框架

4. 软件项目计划周期    

5. 软件项目计划的内容  

• 项目的目标：描述作什么，为谁作，何时作，以及项目成功结束的标准  
• 工作分解结构WBS：把项目分解为可直接操作的元素  
• 资源配置：根据经验和相应的原则，确定各部分需要的资源  
• 进度安排：根据资源配置情况和项目的实际背景，制定项目的进度

2. 分阶段交付

1. 必要性

        设计思想：由于用户需求的不断变换，早期只对基本功能进行约定，其余问题的约定推迟。        

        在分阶段交付中，软件功能按照其重要程度的顺序进行交付。分阶段交付没有缩短软件开发的时间，只是降低后期交付的压力。  

2. 分阶段交付过程      

        分阶段交付要求稳定的体系结构、精心的管理和详细的技术计划，能够消除逾期交付、集成失败、软件特征的逐渐增加及客户、经理与开发人员之间的摩擦。      

        使软件达到可交付的质量水平可以防止问题的积累导致交付软件时问题泛滥成灾。

3. 如何分阶段            

        即每个阶段都包含那些软件特征。好的方法是定义每个阶段的主题，然后就主题和用户进行商榷，再根据主题把软件特征分配到各阶段。  

3. 进度安排

1. 进度安排的整体过程            

        在确定项目的资源（总成本和时间）后，就需要把其分配到项目的各个开发阶段中，即确定项目的进度。可以参考类似项目的经验数据或者公开发表的数据。  

（1）根据项目总体进度目标，编织人员计划。

（2）比较所需资源和可获取资源，确定各阶段的初步进度，然后再确定整个项目的初步进度。

（3）对初步进度计划进行评审，确保计划满足要求，否则重复上面的步骤。        

        进度安排的详细程度取决于相应的工作分解结构的详细程度，而工作分解结构又取决于项目当前所处阶段与历史经验。

2. 进度中的并行性

        软件项目的并行性要求进度计划必须确定各任务之间的从属关系、各任务的先后次序和衔接以及各个任务的持续时间，以保证所有的任务都能够按进度完成。

3. 进度安排的方法

        进度是计划的时间表。（1）甘特图（横道图）

        特点：每一任务的完成不以能否继续下一阶段的任务为标准，而是是否交付相应文档和通过评审；清楚表明计划进度，动态反映进展状况；不能表达各任务之间的依赖关系。

第五章 软件项目配置管理

1. 配置管理概念

基本概念

        标识：识别产品的结构、产品的构件及其类型，为其分配惟一的标识符，并以某种形式提供对它们的存取。

        软件配置项：SCI出于配置管理的目的而为软件要素设置的单位。

        基线：开发过程的里程碑，以一个或多个软件配置项的交付为标准；基线由通过正式评审的软件配置项组成，是进一步开发的基础；基线只有通过正式的变更控制过程才能改变。

        版本：一个基线或一个软件配置项的特例。

        控制：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。

        状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。

        审核：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。

        生产：对产品的生产进行优化管理。它将解决最新发布的产品应由那些版本的文件和工具来生成的问题。

软件配置管理——定义

        配置管理（CM）：是在系统生命周期中对系统的配置项进行标识和定义的过程。该过程是通过控制配置项的发布及后续变更、记录并报告配置项的状态及变更请求、确保配置项的完整性和正确性来实现的。

        软件配置管理（SCM）：是应用于由软件组成的系统的配置管理，通过一套工程规范，在整个软件生命周期中跟踪、记录软件，保证全部变更都记录在案，并保证软件的当前状态是已知和可重复的。    

        软件配置管理是软件项目运作的一个支撑平台。它将项目所有成员的工作协同起来，实现高效的团队沟通，使工作成果及时共享。

软件配置管理过程

（1）计划配置管理    

        确定SCM组织和责任，明确CM的过程、工具、技术及方法论，知道如何及如何进行。CM通过软件组织内部的指导及软件合同需求来实现。在发布SCM计划之前，必须先对计划进行验证和确认并开发相关文档。

（2）开发CM方案    

        定义了一个配置标识方案CIS对软件产品进行跟踪，包括建立各个阶段的CM基线、进行配置标识。CIS的文档资料应包含在配置计划中，其中的配置项也应在配置计划中定义。CIS贯穿于整个软件生存周期中。       

（3）配置控制    

        建立软件配置控制委员会，对基线的变更只有得到CCB的同意才能进行；对变更进行跟踪，确保任何时候软件配置都是已知的；在软件生存周期的整个过程中都要清楚基线状态的变更历史，以便于下一步的状态审计。

（4）状态审计    

        对状态进行报告，明确到目前为止改变的次数及最新版本等。

2. 配置管理组织和职责

CMM二级体系

        SCM是CMM二级体系中的一个重要的过程域（KPA），是保证软件项目生成的产品在软件生存周期中完整性的重要手段。SCM与软件质量保证SQA等其他二级KPA联合构筑了项目级的软件过程能力。

SCM的职责

1. 配置经理    

        基本职责对代码开发和测试进行支持和保护，是变更管理的控制中心。

• 制定SCM规程，形成文档并分发给有关人员
• 建立系统基线，包括备份规定
• 确保对基线的变更都经过授权人员的批准
• 确保对基线的所有变更都进行充分细致的记录，以便可以重新生成或回退
• 确保所有基线变更都经过回归测试
• 规定解决异常问题的关注焦点

2. 变更控制委员会CCB    

        SCCB是大中型软件项目中协调变更的集中控制机制，是对每个变更进行评审，做出相关决策的实体，它批准建立软件配置项SCI的软件基线和标识，授权SCM组从软件基线库生成产品，对SCI变更要求的处理给出建设性意见。    

        SCCB是一个常设性组织，项目经理指定SCCB主席，SCM经理一般担任SCCB的秘书，SCCB的成员一般由各个功能组的技术或管理代表组成。    

        根据项目规模的大小，可能需要多个CCB，每个CCB要有某些领域的专业人士或权威人士；每个CCB都必须有一个主席，以解决内部争议，并且建立系统层次的CCB，以解决底层CCB之间的争议。

3. SCM文件体系

        方针：描述SCM的目标、方法、途径和方针的负责人。

        过程定义：支撑顶层方针，将SCM所有共同特性的关键实践予以文件化和制度化。

        规程或模板：支撑上两层次的文件，为具体执行活动提供作业规范或模板（SCMP）。  

4. SCM过程活动

3. 配置管理功能

        SCM指涉及组织和管理各种软件产品及文档、控制其变化的一系列活动，贯穿整个软件生命周期。软件配置管理包括四个主要功能：配置标识、配置控制、配置状态报告及配置审核。

1. 配置标识

        标识软件配置项，使它可用某种方式访问。配置标识的目标是在整个系统生命周期中标识系统的构件，提供软件和软件相关产品之间的追踪能力。

 （1）需要注意的问题    

        “标识”用来确定如何识别产品的所有部件和由部件建造的产品基线。

 （2）配置标识框架    

        ITEM <配置项名称> IS          

                BELONGTO <文档类别名>          

                PROVIDES<供应资源表>                

                        ROPERTIES<供应资源特性描述>          

                REQUIRES<需求资源表>          

                VESION_LINK<版本链>            

                CONTENPONITER <指针>{指向初版内容}      

        END

2. 配置控制

        在软件生存周期中控制软件产品的变更和发布，其目标是建立有助于确保软件质量的机制。

①版本控制        

        在软件产品开发过程中以及产品发布以后可靠地建立和重新创建版本是软件配置管理的必备功能。

         分支、比较和合并

        * 软件配置管理必须确保工作空间的特性

        工作空间：指软件开发人员进行软件开发工作的环境  

        特性：使得开发人员能够编写和调试代码、共享需要的文件、屏蔽正在开发的代码，以保证项目的其他部分不受其影响。

②变更管理    

（1）模块变更管理

        差异代码管理      

        把基本的代码部分和差异代码分开。

        缺点：基本代码部分复杂；变更链中丢失元素重建整个链条困难；生命周期长导致差异代码逐渐变大。

        解决办法：对于临时变更采用差异代码处理，对于永久变更，通过将模块分解为多个部分处理。

        条件代码管理        

        从几种可供选择的模块中选择一种，以实现特定功能。        

        所有情况下的模块都在模块库中，每次只使用一个模块。

（2）基线管理

        基线是软件开发过程中的特定点，其作用是使软件项目各个阶段的划分更加明确，使本来连续的工作在这些点上断开，以便检查和肯定阶段成果。        

        基线由软件配置项组成，是软件配置管理的基础，为以后的开发工作建立一个标准的起点。随着软件配置项的建立，产生一系列的基线。

        各基线间的变更必须记录并文档化；当各模块联系（集成）较多时开始建立基线。

        基本功能      

        对基线进行适当控制，禁止任何未经批准的变更。      

        为程序员提供灵活的服务，确保他们能够比较容易地对自己地代码进行修改和测试。

       对基线变更控制机制的需求：

•  对基线提出的变更必须经过一定层次的评审  
• 必须确定和理解提出的变更对经费、进度、软件开发和生产造成的影响  
• 变更必须获得相关组织的批准  
• 必须正确实施被批准的变更  
• 一旦变更被批准，必须通知所有受影响的部门

       配置状态报告

       提供软件开发过程的历史记录，内容包括软件配置项当前的状态及何时因何故发生了变更，使得相关人员了解配置和基线情况。配置管理人员应定期或在需要的时候提交配置状态报告。配置状态报告主要描述配置项的状态、变更的执行者、变更时间和对其他工作有何影响。          

       配置状态报告的结果存入数据库，管理者和开发者可以查询变更信息并对变更进行评估。另外，还可以对变更数据进行统计分析，有利于评估项目风险，有效控制项目的执行。

       相关文档：配置项状态报告、变更请求、变更日志、变更测试。

       配置审核

1. 概念      

       根据需求标准或合同协议验证软件产品配置，验证每个软件配置项的正确性、一致性、完备性、有效性、可追踪性，以判定系统是否满足需求。        

       目的是检验是否所有的软件产品都已产生并且被正确地识别和描述，以及是否所有地变更要求可以根据确定地SCM过程和程序解决。 正式技术审核和软件配置审核（确定变更是否正确的措施）。         

       正式技术审核在软件交付用户前实施，其目的是在任何软件表示形式中发现功能、逻辑或实现的错误，证明审核的软件已满足定义的软件需求和软件合同的要求。关注的是已变更的配置对象的技术正确性、审核者评估软件配置项的一致性、遗漏及潜在的副作用。        

       软件配置审核是技术审核的补充措施，确保软件变更被正确的实施。

2. 配置审核内容 配置管理活动审核和基线审核        

       配置管理活动审核用于确保项目组成员的所有配置管理活动都遵循已批准的软件配置管理方针和规程，例如检入－检出的频度，工作产品成熟度提升的原则等。        

       基线审核则要保证基线化软件工作产品的完整性和一致性，且满足其功能要求。

3. 配置审核的种类

（1）过程审核        

       目的：验证整个开发过程中设计的一致性  需要的资源：SRS、软件设计说明、源代码预发行证书、批准的变更、软件验证与确认计划、测试结果。        

       活动：硬件、软件接口与SRS、软件设计说明的一致性；根据软件验证和确认计划，代码被完全测试；正在开展的设计与SRS项匹配；代码与软件设计说明一致。          

       结果：表明所有差别的过程审核报告。

（2）功能审核        

       目的：验证功能和性能与软件需求规格说明中定义的需求的一致性。 

       需要的资源：SRS、软件设计说明、源代码预发行证书、测试程序、软件验证与确认报告、测试文档、已完成的测试、计划要做的测试。          

       活动：对照测试数据审核测试文档；审核软件验证和确认报告；保证评审结果已被采纳。        

       结果：建议批准、有条件批准或不批准的功能审核报告。

（3）物理审核        

       目的：验证已完成的软件版本和文档内部的一致性并准备交付。  

       需要的资源：SRS、软件设计说明、源代码预发行证书、测试程序、批准的变更、用户文档、验收测试文档、批准的产品标号、软件版本、功能审核报告。          

       活动：审核SRS；功能审核报告已开始实施；软件设计说明完整性样本；审核用户；完整性和一致性手册；软件交付介质和控制。        

       结果：建议批准、有条件批准或不批准的物理审核报告。

（4）质量系统审核        

       目的：独立评估是否附和软件质量保证计划SQAP。  

       需要的资源：软件保证计划，与软件开发活动有关的所有文档。          

       活动：检查质量程序文档；可选择的一致性测试；采访职员；实施过程审核；检查审核与物理审核报告。        

       结果：总体评价与软件质量程序的一致性情况。

4. 软件发布

       发布的产品应该是从软件基线库中提取出来的；在软件发布给最终用户之前，要准备发布记录，为软件产品分配发布版本号，同时要对它进行发布评审并确认其得到批准。一般来说，高级经理、项目经理、软件质量保证人员和测试组都应该参加发布评审。

4. 基于构件的配置管理

1. 软件复用

       软件项目包括三类成分：      

       基本构件：特定于计算机系统的构成成分，可存在于各种软件西项目中。      

       领域共性构件：是软件项目所属领域的共性构成成分，它们存在于该领域的各个软件项目中。      

       应用专用构件：是每个软件项目的特有构成成分。

       软件复用：指在两次或多次不同的软件开发过程中重复使用“为了服用目的设计的软件元素”的过程。 软件元素的大小被称为“粒度”； 按照复用对象划分：产品复用和过程复用 按照复用方式划分：黑盒复用和白盒复用。

2. 软件构件技术

（1）构件

       传统产业基本模式：符合标准的零部件生产以及基于标准构件的产品生产。

       软件产业形成规模经济必须重视标准构件的生产和构件复用。

       构件：指软件系统中可以明确辨识的构成成分。

       可复用构件：是指具有相对独立的功能和可复用价值的构件。

（2）构件技术的研究内容

• 构件获取
• 构件模型
• 构件描述语言
• 构件分类与检索
• 构件复合组装
• 标准化

       构件从源代码级延伸到用户需求、系统和软件需求规约、文档、测试计划、测试案例和数据以及其他信息。

（3）构件实现规范与标准

• 组件对象模型COM    

       微软开发，以OLE为基础，基于OLE标准开发可在多个应用程序间互操作的可复用即插即用对象。 OLE成为微软OS的一部分，因此应用最广泛。 

• 公共对象请求代理体系结构CORBA    

       由OMG发布，基于分布对象技术，其目的是在分布式环境下，建立一个基于对象技术的体系结构和一组规范，实现应用集成，使基于对象的软件组织在分布异构环境中可以复用、移植和互操作。

       CORBA是一种构件集成技术。一个对象请求代理提供一系列服务，使可复用构件能够和其他构件通信，而不用考虑它们的位置；用CORBA标准建立的构件保证其在系统内的集成；基于CORBA的应用屏蔽了平台语言和厂商信息，使得对象在异构环境中透明的通信。

（4）基于构件的软件开发

3. 基于构件的版本管理

（1）版本管理的粒度

       以构件（多个文件的集合体）为基本粒度。

       对版本管理的要求：

• 应能有效存储和管理构件的演化历史
• 操作模型应有利于体现构件的完整性，降低系统开发的复杂程度
• 需要保证进行开发构件时的正确性，同时不降低项目组协同工作的灵活性    

       以构件（多个文件的集合体）为基本粒度的版本管理的特点：

• 构件的抽象级别比文件高
• 构件的粒度比文件大，逻辑单元与构件相对应，逻辑意义明显
• 在构件基础上可以体系出系统的层次性、构造性等特征，构件版本管理也可以满足文件版本管理的要求，具有灵活性

（2）构件版本的管理  

• 组成

       构件是由多个文件构成的一个逻辑整体。其版本表明了构件的演化过程，不但反映了其组成的变化，同时也反映组成文件的版本变化。    

• 管理的基本模式

       仍然采用“检出－修改－检入”的基本操作模式，基本单位是构件。    

• 分支、构件比较及合并

       与文件的版本管理类似，但比较分为两个层次：文件级和构件级。    

• 构件的增量存储

       构件的不同版本具有较大相似性，为降低存储冗余，不同版本采用增量方式存储。    

（3）并发控制机制

       采用版本控制与并发控制单位分离，即以构件为版本控制单位，以文件为并发控制单位，保证并行开发构件的正确性，同时减少项目组协同工作的灵活性。

4. 基于构件的配置管理

       基于构件的软件开发的特点：新系统通过复用已有构件构造出来；构件在使用之前需要根据需求修改；已有系统的根据需求的变化不断演变成新的系统。

       对配置管理的要求：

• 配置管理应支持构件的概念，对构件进行管理
• 配置管理应能够维护构件修改和开发的历史
• 配置管理反映系统的构件构造方式，维护构件组装的历史
• 提供并发控制
• 对系统和构件的演化进行控制，维护多个演化方向

相关概念      

       构件：通过某种结构组织起来的一组密切相关文件的集合。其支持各种形态的构件。      

       配置：指一组配置项的集合。每个配置项可以是一个构件，也可以是一个配置，具有自包含性。

       配置基线：为配置所有子配置中的构件选定一个版本，就得到一个基线。配置基线表示组合构件或系统的一个版本。

管理系统模型      

• 配置支持    

       在构件的基础上定义配置，在已有构件和配置的基础上定义更大的配置，直至定义出整个系统

• 高层管理  

       在版本控制和配置支持的基础上，进一步满足基于构件的软件开发中的其他管理需求：构造支持，审核控制，统计报告，变化控制，过程控制，团队支持。

优越性      

• 构件具有逻辑含义，记录和维护构件的版本更具有实际意义；
• 粒度较大，适合大规模软件的开发；
• 有结构，构件版本控制可以满足文件的版本控制；
• 构件组装是基于构件的软件开发的一个重要环节，基于构件的配置可直接支持构件组装。

第五章 软件项目风险管理

1. 软件项目风险概述

风险：SEI将风险定义为损失的可能性。

       具体含义：

• 风险同人们有目的的活动有关；  
• 风险同未来的活动有关，风险与行动方案选择有关；  
• 如果活动的后果不理想，则试图改变以往的行为方式或路线，把以后的活动做好，另外客观环境或人们思想发生变化，活动的结果必然发生变化，风险与变化有关。

       两个属性：    

• 可能性：风险发生的概率    
• 损失：预期和后果之间的差异    
• 风险损失＝可能性×损失  
• 风险的根源在于事务的不确定性

软件风险管理主要内容

1. 制定风险管理计划：      

       决定如何着手与计划项目的风险管理活动

2. 风险识别：      

       识别风险和风险来源。

3. 风险分析：      

       在已建立的标准基础上分析风险，估计风险的可能性与后果，评估风险的相对严重程度。

4.风险计划：      

       如何解决风险，制定风险解决方案，并为选择的方法定义行动计划。

5.风险跟踪：      

       监视计划的起点和风险的状态。比较起点和状态以决定变化。

6.风险应对：      

       对触发事件的通知作出反映，执行风险行动计划，报告风险应对措施的结果，直到风险降低到可接受的范围。

7.风险管理验证：      

       保证项目实践无偏差地执行风险管理计划的方法。

2. 风险识别

       1. 头脑风暴法

       2. 德尔菲（Delphi）法

       3. 会议法

       4. SWOT分析法

       5. 匿名风险报告机制

3. 风险管理计划

1.确定风险管理目标      

       目标为项目组成员的工作提供方向和工作重点；描述通过实施风险管理计划希望得到的结果；目标提供风险管理的动机和期望。    

       任务是实现目标的具体行动。    

       范围是风险管理计划主要部分的概述。

2. 制定风险管理策略  

       策略是实施计划的方式。    

       政策是风险管理计划应遵循的依据。    

       途径定义风险管理的原则。建议采取主动的、综合的、系统的和自觉地管理原则。    

       项目角色决定如何计划风险管理的责任和权利。   

3. 定义风险管理过程      

       风险管理过程是系统的、有结构的风险管理方式，它包括一些活动与机制（识别、分析、计划、跟踪、应对），通过这些内容项目知识转变成制定决策的信息。    

       风险管理计划可以指明风险管理过程文档。  

4. 定义风险管理验证      

       风险管理验证是保证项目实践无偏差执行计划的方法。    

       评审标准设定恰当的期望值。    

       审计过程一一验证计划的活动是否得以执行，参加者是否得以培训，是否坚持了风险管理计划。    

       审计报告总结实施表现，并详细说明与计划的所有差异。

 5. 建立风险管理机制      

       风险管理机制是将风险管理活动的输入转变为风险管理成果过程中所用的技巧与工具。    

       风险核对清单将各个侧重点进行分类以理解风险的特点。        

       风险管理表格记录管理风险的基本风险信息。        

       风险数据库模式表明了识别风险和相关信息的组织方式，它将风险信息组织起来供人们查询、跟踪状态和产生报告。

4. 风险识别

       或称风险辨别，是寻找可能影响项目的风险以及确认风险特性的过程。

       参与人员：项目组成员、风险管理专家、学科专家、客户、其他管理人员

       目标：辨别项目面临的风险，揭示风险和风险来源，以文档和数据库的形式记录风险。

1. 风险识别活动依据      

•  风险管理计划  
• 项目计划  
• 历史与经验信息  
• 外部风险  
• 项目内部的不确定性     

2. 风险识别活动的成果      

•  风险陈述（问题、可能性、结果）  
• 风险环境（事件、条件、约束、假定、环境、有影响的因素和其他相关问题。

3. 风险识别过程      

• 风险评估（识别与估计风险）  
• 系统地识别风险  
• 风险定义及分类  
• 将风险写成文档

4. 风险识别工具  

① 核对清单  

• SEI的软件风险分类系统  
• 项目工作细分结构WBS

5. 风险分析

1. 风险分析成果      

• 优先风险列表    

       依据风险影响、时间响应要求的轻重缓急排列风险优先级；也可以按对项目成本、功能、进度、质量等的影响分别提出风险队列表  

• 风险背景    

       经过风险分析提炼出的风险背景增加了风险的背景信息，如风险类别、风险来源、风险触发驱动因素。

2. 风险分析过程      

• 确定风险类别
• 确定风险驱动因素    

       风险驱动因素是引起软件风险的可能性和后果剧烈波动的变量。可通过分析背景输入相关模型得到。

• 判定风险来源
• 定义风险度量准则      

       可能性、后果、行动时间框架。

• 预测风险影响      

       风险影响(RE) = 可能性（P) ×  后果(C)

• 评估风险    

       风险影响和行动时间框架决定了风险的相对严重程度。

3. 风险分析技巧与工具      

1. 因果关系分析法

2. 决策分析法

3. 差距分析法

4. 帕雷托分析法    

5. 敏感度分析法 

6. 风险计划

1. 风险计划的依据    

       是实施风险应对的依据与前提。 目标：制定风险管理政策和过程的活动。     

• 风险管理计划  
• 优先风险列表  
• 风险背景   

2. 风险计划的成果      

• 风险反应计划  
• 残余风险    

       指采取风险行动后仍然留存的风险，包括哪些被接受的小风险。  

• 风险反应阈值  

       定义需要执行风险反应行动的警告阈值

3. 风险计划过程      

① 确定风险设想    

       风险设想指对导致不如人意的结果的事件和情况的估计。风险设想是对风险的进一步认识。

② 确定风险应对策略    

       风险计划小组（2-3人）捕获有关导致风险演变为现实的事件的顺序，然后列出干扰风险情况的条件，理解风险发生的重要性，确定何时需要采取行动以避免问题的发生。    

       风险应对策略包括：避免、转移、缓解、接受、研究、储备以及退避。

③ 选择风险应对途径    

       风险应对策略的取舍标准：

       （1）风险倍率    

              指对执行不同风险应对活动的相对成本和利益的比较。

              风险倍率=风险影响（前）- 风险影响（后）/风险应对成本

       （2）风险多样化    

              通过分散风险来减少风险。

④ 建立风险示警阈值    

       阈值量化目标设定，用于定义风险发生的开端，还可以依据与量化目标的差异大小分级定义。

⑤ 制定风险反应计划  

7. 风险跟踪

       包括动态衡量项目状态，观察项目有关信息，度量判断项目风险，决策何时执行风险反应计划。

1. 风险跟踪的依据      

• 风险设想  
• 风险阈值  
• 风险状态

2. 风险跟踪的成果      

• 风险度量  
• 触发器

3. 风险跟踪过程      

• 监视风险设想  
• 对比项目状态与风险阈值  
• 风险信息的通知  
• 报告风险度量

8. 风险应对

 处置风险的过程。

1. 风险应对的依据      

• 风险行动计划

2. 风险应对的成果      

• 风险状态  
• 校正行动  
• 问题防范

3. 风险应对的成果      

• 对触发事件做出反应  
• 执行风险行动计划  
• 对照计划报告进展  
• 修正与计划的偏差

4. 风险管理回报      

       是所有风险管理的节约除以风险管理活动的总成本。       

9. 风险管理验证

       如何通过独立审计，检验风险管理活动与计划的一致性，同时还描述了如何保证项目实践遵循风险管理计划。

• 评审风险管理计划  
• 审计执行者及其典型产物  
• 生成审计报告  
• 跟踪行动项目

第六章 软件项目资源管理

       人力资源管理是软件项目管理中至关重要的组成部分。

       软件项目中的人力资源管理包括所有的项目干系人：资助者、客户、项目组成员、支持人员及供应商等。    

       人力资源管理就是有效地发挥每个项目干系人作用的过程。

       具体任务：

• 分析人力资源需求，规划人力资源配置状况；
• 获取人力资源信息，招聘员工，确定劳资关系；
• 培训员工、任用员工；
• 评估员工业绩，依据人力资源评价体系奖惩员工。  

       人力资源管理工作主要内容：

1. 人力资源规划过程

2. 人力资源分析与策划

       软件项目中人员的获取、选择分配和组织是涉及软件开发效率、软件开发进度、软件开发过程管理和软件产品质量的重大问题。    

       在开发各阶段所需要的技术人员类型、层次和数量是各不相同的。    

       软件开发管理人员和各类专门人员逐渐增加，直到测试阶段结束时，软件项目开发人员的数量达到顶峰，然后逐渐下降。    

3. Brooks定律        

       “向一个已经拖延的项目追加新的开发人员，可能会使这个项目完成得更晚”      

       原因： 人员以算术级增长时，人员之间的通信将以几何级数增长。          

       软件开发中人员与时间的非线性替换关系。      

4. 人力资源计划的平衡    

       在制定人力资源计划时，由于系统开发人员不容易得到，因此，在基本按照N-R曲线配备人力的同时，尽量使某个阶段的人力稳定，确保整个项目期人员的波动不要太大。                            

                                                     人力资源需求网络图      

       项目的每一活动都在其最早开始时间执行。

                                                    人力资源计划图

       减少人员波动，调整人力资源计划。

                                     基于资源平衡的人力资源计划图

5. 人力资源的获取    

       途径：组织内部选拨、招聘、熟悉人员介绍    

       项目经理应具备的基本素质： 良好的沟通能力； 良好的文档能力； 解决冲突的能力； 项目实践经验。

6. 团队组织分工    

       组建软件团队取决于可供选择的人员、项目需求以及组织的需求。    

1. 软件团队中的角色：        

       项目经理、系统分析员、系统架构师、数据库管理员、程序员、配置管理员、系统测试员。    

2. 开发人员组织

• 水平团队方案（各方面专家）；
• 垂直团队方案（多面手）；
• 混合型团队方案 （多面手和专家）                  

       团队组织方案选择着重考虑可供选择的人员。

7. 团队建设    

       提高团队运作水平而进行的管理和采用的措施。  

1. 制度建立  

• 对于异地同时开发的项目，一定要事先统一好代码检入（check in）的时间，否则进行日常构建（build）的时候，很容易因为不同步的问题造成失败。
• 在项目制定计划过程中由团队成员参加，建立一套用于发现和处理冲突的基本准则。比如：麦肯锡解决问题的“七步法”。
• 根据项目开发经营或者项目特点总结出可供参考的过程模型，如微软软件开发解决方案框架（MSF）、IBM统一过程模型（RUP）等。
• 对于规模大或复杂的项目，建立监督、控制委员会，以便项目协调管理和统一决策。 …         

2. 建立沟通机制

• 会议沟通
• 文件沟通
• 电子邮件
• 电话    

       沟通原则：  

• 原则之一：学会倾听
• 原则之二：表达准确
• 原则之三：及时沟通
• 原则之四：双向沟通
• 原则之五：换位思考   

3. 建立培训与学习型组织氛围

• 项目本身具有的特性；
• 项目组成员自身提高的愿望；   

4. 工作氛围建设

• 开放
• 真诚
• 平等
• 信任

8. 激励机制

1. 马斯洛的需求层次论

2. 麦克利兰的成就需要理论 

       成就需求（Need for Achievement）：争取成功希望做得最好的需求。

       权力需求（Need for Power）：影响或控制他人且不受他人控制的需求。

       亲和需求（ Need for Affiliation）： 建立友好亲密的人际关系的需求。

3. 激励步骤

• 分析激励 
• 创建激励环境
• 实现激励

4. 激励技巧

• 目标激励
• 及时认可
• 信任激励
• 荣誉和头衔
• 情感激励
• 给予一对一的指导
• 参与、授权激励
• 集体激励、奖励
• 自我激励 ……

9. 绩效考核  

       绩效管理是指各级管理者为了达到组织目标，在持续不断沟通的前提下，与员工共同进行绩效计划制定、绩效辅导实施、绩效考核评价、绩效反馈面谈、绩效目标提升的持续循环过程。

1. 项目绩效        

       从项目成本、利润、计划完成情况、项目质量、规范程度、文档水平、技术、产品化和共享度等方面评价

2. 个人绩效      

       从敬业精神、工作责任感、个人技能、个人贡献、团队合作、工作效率及完成情况等方面评价。

第七章 软件项目质量管理

1. 软件质量

用户角度：

       软件运行可靠，不死机，界面友好，系统运行速度快，结果正确，产品交货及时，服务好。

开发人员角度：

       技术上没有差错，符合标准及规范的要求，技术文档齐全正确，系统容易维护。

专业人员标准：

       每千行代码中包含的缺陷数。

2. McCall提出的软件质量的11中特性

3. 国际标准化组织和国际电工委员会制定ISO/IEC9126-1191和GB/T16260-1996国家标准

       软件质量六大特性：功能性、可靠性、可用性、效率、可维护性、可移植性

1. 功能性

       与一组功能及其指定的性质有关的一组属性，包括适合性、准确性、互操作性、依从性、安全性。

2. 可靠性

       与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性，即一个系统按照用户需求和设计者的相应设计，执行其功能的正确程度。包括成熟性、容错性、易恢复性。

3. 易用性

       以一组规定或潜在的用户为软件使用对象，所需要作的努力和对这样的使用所作的评价相关的一组属性。包括易理解性、易学习性、易操作性。

4. 效率

       与在规定的条件下，软件的性能水平与所使用资源量之间的一组属性。包括时间特性、资源特性。

5. 可维护性

       与进行指定的修改所需的努力有关的一组属性，包括易分析性、易更改性、稳定性、易测试性。

6. 可移植性

       与软件从一环境转移到另一环境的能力有关的一组属性，包括适应性、易安排性、一致性、易替换性。

4. 软件产品质量和过程质量

1. 传统的质量管理观点：

       注重最终的产品质量，通过测试检验软件质量。

2. 现代的质量管理观点：

       开发过程的质量直接影响交付产品的质量，过程的改进自然就会得到高质量的产品。

5. 软件质量和过程改进的关系

• 过程质量控制是主动的、系统的、先期的；    
• 产品质量控制是被动的、个体的、后期的；    
• 两者都要重视。

6. 软件质量保证SQA (Software Quality Assessment)

       SQA目标

• 通过适当的监控系统及其开发过程来保证软件质量；  
• 确保软件及其开发过程与已定的标准和规程要求完全一致；  
• 确保能及时发现产品、过程和标准的任何不足并提醒管理者注意，以便及时弥补。

       SQA职责：审核组织的质量活动，当出现背离是，提醒管理者注意

• 对所有开发计划和质量计划的完整性进行评审；  
• 作为审查主持人，参与设计和代码的审查；  
• 对所有测试计划是否符合标准进行评审；  
• 对所有测试结果的显著样本进行评审，以确保是否按计划执行；  
• 定期审核SCM的执行情况，以确保是否符合标准；  
• 参与所有项目的各类阶段评审，如果没有达到要求，应对不符项和缺陷进行登记并跟踪解决情况。

7. 评审的概念

       又称技术评审或同行评审，是指由开发人员的技术同行在项目实施的各个阶段进行的有组织的软件浏览、文档与代码审读活动，验证工作是否符合预定的标准，其目的是协助软件开发人员在项目早期找出工作的错误。

       软件评审是项目早期软件质量保证的重要手段； 软件测试是项目后期的主要手段。

8. 评审的实施

• 确定参加评审的人员  
• 人员培训  
• 评审准备  
• 分发评审材料，评审员审读材料  
• 评审会议  
• 评审报告

9. 评审成功的关键

• 应为评审及改正评审发现的问题预留项目资源  
• 评审应以发现问题为重点  
• 保证评审的技术化  
• 制定检查单和标准  
• 限制会议人数，并且坚持事先准备  
• 对所有的评审者进行有意义的培训