软件方法过程考试点整理

Lecture 00 

1、软件开发过程是什么？

<1>软件过程是从软件项目需求定义开始直至软件使用后被废弃为止，跨越整个软件生存期内的系统开发、运行和维护等全部活动及相关项的总和。

<2>....是按照软件工业化的标准定义的在软件开发中必须具有的一系列过程规范； 

<3>软件开发过程是定义软件中的软件需求、软件设计，软件编码、软件测试、软件部署的实现目标和规范化的管理方法论； 

<4>软件开发过程是保证软件工业化生产的法典；

<5>软件开发过程做的是：定义标准和为了达到标准的路； 

2、大多数软件项目失败的原因

不完整、不现实的项目需求；对需求的变更束手无策；

脆弱的架构；采用不成熟的技术；

测试的不充分性；拙劣的进度计划和评估；

缺乏资源；不具备项目管理方法；缺少管理层的支持

3、软件工程三个要素

    工具、方法、过程

4、软件方法与过程？相对于技术来说，重要吗？

5、软件开发过程的实现最重要的是：  

 人

Lecture 01 Agile

1、一个软件项目失败（A software project failed if……）

it is delivered late；

it runs over the budget；

it does not satisfy the customer’s needs；

it is of poor quality

2、Classical software development methods have not solved software crisis. 传统的软件开发方法没有能够解决软件危机

3、A software engineer’s job

Make a working plan.

Carry out it.(Do their work according to this pan)

Try his/her best to produce high-quality products.

4、3 key aspects 

  Quality products

Expected costs

On agreed schedule

5、Summary of PSP

(1)PSP is a framework designed to teach software engineers to do better work

(2)Estimate and plan –>track –>improve quality

(3)Quality methods take time to learn and practice, but it will help you in your engineering career

(4)Establish goals –>measure quality –>understand the process –>change and reuse process –>measure & analyze the results –>recycle improving

(5) Identify the tasks you do

6、Manifesto for Agile Software Development？敏捷软件开发宣言的主要内容是什么？（理解敏捷软件开发的原则）

(1)个体和交互胜过过程和工具；

(2)可以工作的软件胜过面面俱到的文档；

(3)客户合作胜过合同谈判；

(4)相应变化胜过遵循计划；

Lecture 02 XP

1、Values of Extreme Programming.（理解XP的价值观：内容、关系。）

(1)内容：

<1>沟通：问题往往是由于开发人员与设计人员、设计人员与客户之间的沟通不畅造成的。因此，项目相关人员之间进行充分、多渠道(最好面对面)的沟通;以人为本，重视客户的参与；在开发组间交换成员；召开版本发布会等。

<2>简单：应该尽量保持代码的简单，只要它能工作就可以实现一个复杂的系统。在系统可运转的前提下，做最简洁的工作，坚定地专注于最小化解决方案：在开发中不断优化设计，时刻保持代码简洁、无冗余。需求尽量的简单，设计尽量的简单，代码尽量的简单，文档尽量的简单；

<3>反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果符合用户的需要。强调各种形式的反馈:小交付、短迭代、测试先行等；更早和经常来自客户、团队和实际最终用户的具体反馈意见可以提供更多的机会来调整力量。反馈可以让您把握住正确的方向，少走弯路；尽快发布新版本；客户应该是小组的一员。

<4>勇气：这是最重要的核心价值。因为XP强调要“拥抱变化”，因此对于用户的反馈，提倡积极面对现实和修理问题的勇气，如放弃已有代码、改进系统设计等；勇敢的重构；所有人拥有代码；敢于极限（把好的方法做到极至）。

(2)联系：

<1>沟通支持勇气，因为它带来了高风险、高回报的试验的可能性。

<2>简单支持勇气，因为有了一个简单的系统，你可以比以前勇敢得多，你无意中将其破坏的可能性也大大减少。

<3>勇气支持简单，因为只有你有可能简化系统，你就会尝试。

<4>反馈支持勇气，因为如果你按下按钮就能够看到测试结果通过（或不通过，这时你可以将代码扔掉），那么即使对代码进行根本的改动你也会感觉安全得多。

2、Basic Principles of XP (5点) 基本原则

(1)Rapid feedback 快速反馈

指开发人员通过短的迭代周期，得到反馈信息，并迅速查验他们前面的工作是否满足客户要求。

(2)Assume simplicity 假定简单

指将系统开发中的每个问题以尽量简单的方法来解决。没有人能够准确预知未来的需求，因此设计只需要满足现阶段的需求即可。

(3)Incremental change递增改变

指用一系列的小改变来逐步解决一个问题。这一原则可用于计划、开发和设计等。

(4)Embracing change 拥抱变化

指在解决紧迫问题时，采取的一种包容的策略。程序员要明白客户的要求并不是固定的，因此功能的优先级和功能需求都是在变化的。

(5)Quality work优质产品

指工作和产品的质量是不容忽视的，不可以因为时间而放弃质量, 并做出让步。

3、XP的项目过程包括哪6个阶段？

(1)Exploration Phase 考察阶段（探索阶段）;

(2)Planning Phase 计划阶段;

(3) Iterations to Release Phase 多次反复到发布产品阶段;

(4) Productionizing Phase 生产化阶段;

(5) Maintenance Phase 维护阶段;

(6) Death Phase 死亡阶段;

4、Practices  （XP的最佳实践 能列举并说明5个以上）

5、XP中采用Pair Programming的优点有哪些？

(1)所有设计都是由两个人讨论决定的；

(2)系统的任何一个部分都至少有两个人熟悉，避免了由于人事更替造成的问题；

(3)减少了忽略编写测试用例的几率，因为结对者会互相提醒对方；

在编程过程中与不同的人结对可以进一步增强知识与经验的共享；

(4)所有代码都随时得到检验；

(5)两个程序员可以同时分别关注操作层面和理论层面，加强了程序的设计。

Lecture 03  Summary of XP

The Rules and Practices 

Planning Designing Coding Testing

Lecture 04  SCRUM  

1、What is Scrum?

(1)Developed for managing system development process.

用于管理系统开发过程。

(2)An empirical approach applying the idea of industrial process control theory to system development.

将工厂过程控制理论应用到系统开发上的一种经验方法。

(3)Reintroduces the ideas of flexibility, adaptability and productivity.

再次把灵活性，适应性和高产性引进到系统开发过程当中。

2、Process： 哪三个阶段？主要工作内容？

(1)计划和体系结构设计（确定性过程）

将Backlog（急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等）按优先级排序形成Backlog 列表，根据该表和风险评估制订产品交付基线。

建立系统体系结构（如为已有系统改进，则只作有限分析、调整），将Backlog项按高内聚低耦合的原则分解为一系列问题包(Packets,每个Packet是一组对象或构件的集合) ，依据同样原则相应划分若干个开发小组（SCRUM 小组）,分配各小组合适的Backlog项或问题包。建立开发运行环境。

(2) Sprint（经验性过程）

该过程由若干个迭代的冲刺(Sprint) 活动组成，直至风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1-6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个SCRUM小组并行开发且必须步调一致（在一个Sprint结束后，均须完成所分配的Backlog项并有可执行的产出）。

(3) 交付和巩固（确定性过程）

一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装，系统测试和回归测试（Regression），准备培训材料，完成最终文档。

3、Sprint：what is , 具体工作内容。

(1)向管理层、用户和产品拥有者介绍本次冲刺的结果；

(2)参与者对产品新增的部分进行评估并决定下一步的活动；

(3)可能会提出新的backlog条款(就有些新的功能要增加），甚至会改变系统的开发方向。

4、Daily Scrum meetings: What is, why daily& Can be replaced by emailed status reports?

(1) What is:

<1>Keep track of the progress of the Scrum Team continuously;

<2>Serve as planning meetings 也可作为计划会议

<3>Problems and other variable matters are discussed and controlled <4>Identify and remove deficiencies(不足)or impediments（障碍）

<5>Scrum Master conducts the meeting, Scrum Team, management participate in the meeting

(2)Why daily:

“One day at a time.”

——Fred Brooks, The Mythical Man-Month

(3)Can?

No！

Entire team sees the whole picture every day; 

Create peer pressure to do what you say you’ll do

5、Backlog: What is Product Backlog VS Sprint Backlog

(1)Product Backlog: 系统需求被分成一系列的子需求，叫产品backlog (2)Sprint Backlog: A list of Product Backlog items selected to be implemented in the next Sprint.

6、Scrum 价值观：5点

commitment承诺；

focus专注；

openness公开；

respect尊重；

courage勇气；

Lecture 05  Other Agile Method  

1、动态系统开发方法DSDM （基本观点 &基本原则）

(1)基本观点：任何事情都不可能一次性完满完成；

(2)基本准则：

<1>积极主动的用户参与；

<2>赋予DSDM项目组充分的决策权强调经常性的产品提交（注重结果而非过程）；

<3>以是否适合商业目标作为工作确认的首要衡量标准；

<4>迭代和增量式的开发方法；

<5>开发中所有的变化是可以追溯的；

<6>基于软件需求提出的开发计划作为宏观进度控制的基线；

<7>测试活动贯穿于软件开发周期的各个阶段；

<8>强调所有项目相关人员的合作。

2、水晶系列方法 Crystal（核心理念 & 原则 分别是什么?）

(1)核心理念：

软件开发可视为创造和交流相协调的过程。人是第一位的因素软件开发的首要目标是交付可用的软件，第二才是保持开发工作的可延续性。

(2)原则：

<1>减少中间制品的工作量（开发文档、进度计划）；

<2>项目组的惯例随项目具体情况调整；

<3>根据人数决定采用的方法；

<4>对可靠性要求越高，则采用越严格的过程纪律。

3、由Apache得出的关于开源开发方法的一些假设、结论

(1)假设：

<1>OSS developments will have a core of developers who control the code base. This core will be no larger than 10-15 people, and will create approximately 80% or more of the new functionality.

<2>For projects that are so large that 10-15 developers cannot write 80% of the code in a reasonable time frame, a strict code ownership policy will have to be adopted to separate the work of additional groups, creating, in effect, several related OSS projects.

(2)结论：

<1>Almost all new functionality is implemented and maintained by the core group.

<2>Participation of wider development community is more significant in defect repair.

<3>Only a few developers beyond the core group submit changes with any regularity.

只有很少的非几个核心成员经常上缴代码修改。

Lecture 06 -09 RUP

1、What is the Rational Unified Process(Rational统一过程)? 

(1)RUP（Rational Unified Process）是软件工程化过程；

(2)RUP提供了在开发机构中分派任务和责任的纪律化方法以及文档模版；

(3)RUP的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品；

(4)Rational Unified Process是Rational公司开发和维护的过程产品；

(5)Rational Unified Process是有效使用Unified Modeling Language（UML）的指南

2、Rational Unified Process的特点 （核心思想）

<1>迭代式开发

<2>强调核心工作

<3>流程基于角色的开发

<4>组织用例驱动

<5>以构架为中心

3、Effective Deployment of 6 Best Practices

<1> Develop software iteratively 迭代开发

<2>Manage requirements

<3>Use component-based architectures 基于组件的架构

<4>Visually model software

<5>Verify software quality

<6>Control changes to software

4、

Two Dimensions，四个阶段，core workflow&Phase工作流程与各阶段的关系，

5、RUP仅仅只是一系列方法?  有一系列工具等支持

6、

对该图的理解

7、RUP与XP—共性&差异

(1)共性：

<1>基础都是面向对象方法；

<2>都采用迭代，增量开发方式；

<3>都是基于风险驱动；

<4>都重视代码、文档的最小化和设计的简化；

<5>采用动态适应变化的演进式迭代周期；

<6>强调需求和测试管理；

<7>鼓励用户积极参与；

(2)差异：

<1>XP以代码为中心，编码和设计活动融为一体，弱化了架构的概念。RUP过程通常以架构为中学，细化阶段的主要目的就是构造出一个可运行的架构原型，作为将来添加需求功能的稳固基础。

<2>XP有一个非常关键的假设：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带来的风险、开销要小于需求变化使得事先充分设计失效的代价；反之，实施XP就是不明智的。

<3>XP不包括业务建模、部署、过程管理等概念。

<4>RUP更强调项目的可控性。

<5>可以将XP中的最佳实践纳入到RUP中。

<6>RUP经过裁减后适合各种规模的项目，XP只适用于小团队。

<7>XP实践依赖团队成员的强关系而RUP对团队成员的关系紧密程度要求弱一些。

Lecture 10 MSF

1、软件项目成功的障碍可能有哪些？IT如何克服障碍？IT的首要目标？

(1)成功的障碍：

<1>目标和职能分离

<2>业务和技术分离

<3>缺乏共同的语言和过程:目标不明确、没有范围变更管理

<4>无法以一个团队的方式进行沟通和运作

<5>过程管理不够灵活，难以适应项目的变化

(2)IT如何克服：

<1>理解业务的方向、目标和机会

<2>保证IT 目标支持业务目标

<3>保持与业务不断地交流与沟通

<4>形成主动的工作环境

<5>组织团队有效地工作

（3）IT的首要目标：

IT 的首要目标不是更多的技术而是将其主要力量、丰富的技术知识同人和过程结合起来，为整个组织服务。

2、成功项目的标准

<1>在规定的范围内（时间/资源）完成

<2>按照定义完成功能

<3>确认系统符合质量标准

<4>部署和管理平滑方便

<5>提高用户完成工作的效率

<6>客户满意

3、MSF的模型和准则是哪几个？

(1)模型：

<1>团队模型：MSF团队模型定义了小组同级成员的一些角色和职责。MSF 团队模型认为，任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。如果任何一个角色无法实现其目标，都将危及整个项目。因此，每个角色都被认为是同等重要的，重要的决定都要共同做出。

<2>过程模型：MSF过程模型描述了构建和部署 IT 解决方案的活动的高层顺序。它没有规定具体步骤，而是非常灵活，足以适应多种类型 IT 项目。这个新版 MSF 过程模型的一个创新之处在于，它涵盖了解决方案的整个周期，从立项到实地部署。这就有助于项目小组把精力放在客户的业务价值上，因为不到项目被部署和实际运作就不会有价值被实现。

(2)准则：

<1>项目管理准则：MSF 用一种分布式的小组方法来进行项目管理，它能够提高责任性，并允许大范围的可伸缩性，既适用于小的项目，也适用于非常巨大和复杂的项目。本白皮书描述这种分布式的方法，并解释了 MSF 小组模型里项目管理的角色。项目管理不是由项目经理一个人完成的。

<2>风险管理准则：风险管理是 Microsoft 解决方案框架的核心准则。MSF 认为变化以及所导致的不确定性是 IT 生命周期所固有的特点。MSF 风险管理准则主张使用一种预见性的方法来处理这种不确定性，持续地评估风险，并在生命周期的始终利用它们来影响决策。

<3>就绪管理准则：就绪管理是 MSF 中的核心准则。这一准则所采用的方法将用于对规划、构建和管理成功解决方案的知识、技能和能力进行管理。

4、

5、MSF微软过程基本原则：

制定计划时兼顾未来的不确定因素；

通过有效的风险管理减少不确定因素的影响；

经常生成过渡版本并进行快速测试来提高产品的稳定性及可预测性；

快速循环、递进的开发过程从产品特性和成本控制出发创造性地工作；

创建确定的进度表；

使用小型项目组并发完成工作，并设置多个同步点；

将大型项目分解成多个可管理的单元，以便更快地发布产品；

用产品的前景目标和概要说明指导项目开发工作：先基线后冻结；

避免产品走形：检查当前状态与原始说明文档对照；

使用原型验证概念，进行开发前的测试：技术可行性等，减少和规避风险；

零缺陷概念；

非责难式的里程碑评审会；

以改进工作为目的：内部、外部会议。

6、MSF 团队模型角色、主要工作内容、目标及相互关系。

7、MSF项目过程模型：阶段及其主要工作任务目标：

构思：

计划：

开发：

稳定：

部署：

8、MSF微软过程的特点

<1>使用迭代+渐进式提交的方式可以保持系统良好的可预见性，也可使客户对项目组实施能力更加信任

<2>迭代周期的选择一定是对一组业务用例的实现而不是其它。即每一个迭代周期都可以交付一个可以完成一定业务功能的系统

    <3>尽早实现困难的用例（如对服务水平要求高的用例）

<4>不要使一个迭代周期超过5周（1个月）

<5>不要试图在这个阶段就确定下来整个开发过程的详细进度（尤其是大型项目），比较好的做法是对第一个迭代周期的任务进行比较详细的划分（基于WBS），而对后面迭代周期的适当放宽。

9、

项目团队和外部环境的沟通

10、在项目中设立里程碑的好处有哪些？

<1>帮助同步工作成果；

<2>使项目团队外的人员也可以看到项目的进展情况和质量情况；

<3>可在项目进行中纠正偏差；

<4>着重于评审项目目标和交付成果；

<5>增加阶段性的审批环节，只有在审核通过后，才进入下一个阶段；

11、使用MSF 过程模型的优点

<1>促进项目成果的依次交付

<2>使解决方案与业务目标保持一致

<3>增加项目的可预见性和可见性

<4>提供一个从项目开发过渡到运营维护的阶段

12、按版本发布的好处

<1>在特定版本范围内管理项目的变更和不确定因素

<2>保证功能的持续增加和完善

<3>缩短交付时间

<4>为团队成员设立明确而可达到的目标

<5>着力解决项目问题

12、风险管理原则

<1>风险是每一个项目和过程必然具备的

<2>识别风险是一项正面的活动

<3>首先识别风险，然后管理风险

<4>风险评估是一项持续的活动

<5>强调主动规避风险

<6>不简单的以风险的数目来评估一个项目的价值

13、风险管理过程的六个阶段：

<1>识别：头脑风暴

<2>分析和分级：

<3>计划和调度：

<4>跟踪和报告：动态调整风险计划

<5>控制：

<6>学习：知识库

14、风险管理的最佳实践:

<1>风险管理是项目组全体人员的责任；

<2>不要有意无意的造成“惩罚问题发现者”的氛围；

<3>只关注一定数量的风险；

<4>风险管理列入正式的项目管理活动和计算工作量；

<5>使用知识库来提高风险管理的有效性；

Lecture 11 TDD

1、Nightly Test是软件开发中一个保证开发质量的最有效的方法，也是衡量软件质量和开发效率的最好的指标。有哪两个指标数值？

    测试用例的通过率、单元测试的覆盖率

2、测试优先的编程：Test-First Programming是什么？

(1)Test-First Programming首先是一种分析方法。

它迫使程序员仔细思考要做什么和不要做什么(而不是如何具体的实现)。特别是各种例外的情况，并用程序语言正式的写下来。这就好像在程序员的任务和程序员之间签订了一个清晰的正式合同。

(2)Test-First Programming是一种设计方法。

Unit Test测试的是程序 ，而不是一个想法。程序员必须清晰地定义程序的界面才能写出它的Unit Test。而这时程序员是不知道（也不需要知道）里面的具体逻辑是如何实现的。程序员只需要考虑Class的界面和功能(Responsibility)。

(3)Test-First Programming是一种质量控制方法( Quality Control )。

如何控制质量呢？如何知道我的程序是否运行呢？我会不会漏了什么？运行一下Unit Test。

(4)Test-First Programming是一种重构和优化的方法。

我们总希望自己的代码可以漂亮，运行的效率高，所以我们会不断地去改进。可是如何保证改进和优化后的质量呢？会不会越改越糟？

(5)Test-First Programming不是通常意义上的测试技术，它的目的也不是仅仅用来测试你的代码。

(6)Test-First Programming是一种面向对象的开发方法。

3、如何做Test Driven Design and Development？1、2、3、4

<1>首先确定你要做什么

<2>然后为这个功能（Method）写单元测试例子( Unit Test )

<3>写Production代码

<4>运行Unit Test

4、XP与TDD：XP采用了TDD

TDD是eXtremeProgramming中必须遵行的一个方法。

TDD是XP中Pair Programming的工作模式。

5、TDD中程序员和管理层

    对程序员来说，通过运行Unit Test和Functional Test，每天下班的时候都可以清楚地知道自己的代码是work的。

对管理层来说，通过Nightly Test的结果，每天一早都清楚地知道项目的质量和开发进度。

6、什么时候写Tests?

<1>如果你要写一个新的功能，请先写它的测试例子；

<2>如果你要在没有经过测试的代码上写新的功能，请先写目前代码的测试例子；

<3>如果你要Fix一个Bug，请先为这个Bug写一个测试例子；

<4>如果你要Refactor没有测试过的代码，请先写一个测试例子；

<5>如果你发现一个边缘例外值，请为它写一个测试例子；

Lecture 12 Refactoring

1、什么是Refactoring

    <1>Refactoring是对已经完成的代码进行改进的过程。在不对代码的外部行为进行改动的情况下，对代码内部的结构进行优化。

<2>Refactoring是严谨地对完成的代码进行清理,从而减少出错的一种方法。

<3>Refactoring的实质是对完成代码的设计进行改进。

<4>Refactoring是XP项目中每天的例行练习。

<5>Refactoring必须和Test-Driven Design and Development伴随进行。

2、为什么要Refactoring?( Refactoring的目的)

<1>改进软件的设计；

<2>提高代码质量，可维护性；

<3>Refactoring帮助尽早地发现错误（Defects）；

<4>Refactoring可以提高提高开发速度。

3、什么时候适合/不适合做Refactoring?

(1)适合的时候:

<1>在开始增加一个新的功能之前：为了增加一个新的功能，程序员需要首先读懂现有的代码；

<2>在修复一个错误的时候：为了修复一个Bug,程序员需要读懂现有的代码；

<3>在做Code Review的时候；

(2)不适合的时候：

    <1>代码太混乱：设计完全错误与其Refactor，不如重新开始；

<2>明天是DeadLine：永远不要做Last-Minute-Change。推迟Refactoring，但不可以忽略，即使进入Production的代码都正确的运行；

<3>Refactoring的工作量显著地影响Estimate。

4、Refactoring的流程：

读懂代码（包括测试例子代码）

Refactoring

运行所有的Unit Tests

5、“Bad Smells in Codes”：what is，examples（at least 3~5） 

6、XP中的Refactoring

在XP的日常工作中，Refactoring通常在每个Pair完成Task后做Code Review的时候进行。

Tips:

不要在刚完成代码后马上进行；

不要在电脑屏幕前进行；

Pair独自进行Review。

PSP与TSP：

软件工程师的任务？

PSP的process flow。

PSP部分

①了解PSP基本内容及特点；与软件开发过程的关系。

②了解和掌握如何使用PSP0；相关脚本、表格、模板及标准的作用。

③Process Mesurement过程度量。了解软件过程度量的内容、目标和意义；衡量软件规模的原因、标准及度量框架；了解规模度量方面的规模计数方法原则，编码标准的作用与意义。了解和掌握如何使用PSP0.1，理解PSP0.1过程及相关脚本、表格。

④Estimating with PROBE I规模估计。理解项目计划的意义和作用、规模估计的原因及原则；结合规模估计举例，了解和掌握基于代理的规模估计的方法。了解和掌握如何使用PSP1，理解PSP1过程、新增内容及相关脚本、表格。

⑤Estimating with PROBE II规模估计。了解规模估计的范围及精确性，阶段计划及产品计划的含义；由规模估计推断开发时间；了解和掌握如何使用PSP1.1，理解PSP1.1过程、新增内容及相关脚本、表格。

⑥Using PSP Data使用PSP数据。了解如何制定产品及阶段进度计划，如何进行项目跟踪；了解EV值及其应用。

⑦Software Quality软件质量。了解什么是软件质量及其经济效益；了解主要的缺陷排除方法；了解和掌握设计、代码复查以及质量度量方法；了解和掌握如何使用PSP2，理解PSP2过程、新增内容及相关脚本、表格。

⑧Software Design I软件设计。了解设计框架、质量与层次；理解和掌握设计表达及设计模板；了解和掌握如何使用PSP2.1，理解PSP2.1过程、新增内容及相关脚本、表格。

⑨Software Design II软件设计。了解UML与PSP、状态设计与验证。

⑩Design Verification设计验证。理解设计验证的原因；了解和掌握设计验证的方法。

TSP部分

①了解TSP基本内容及特点；与软件开发过程的关系。

②了解TSP团队构建过程及团队项目过程。

PSP  Project Plan Summary

1. 填入表头

2. Minute/LOC：

a) 开发前：利用累计开发效率（To date Min/LOC）登入计划Min/LOC；

b) 开发后：用实际的开发时间除以实际代码行数

3. LOC/Hour：

a) 开发前：利用利用60除以计划的“Minute/LOC”，得到计划的“LOC/Hour；

b) 开发后：用60除以实际的“Minute/LOC”，得到实际的“LOC/Hour

4. Defect/KLOC：缺陷密度

a) 开发前：利用最近的前一个程序的缺陷密度累计值，得到计划的“Defect/Hour；

b) 开发后：用1000×实际的缺陷总数/实际的新开发和修改的代码行数

1. 用类似的方法计算缺陷密度的累计值

5. Yield：过程效益

a) 开发前：利用最近的前一个程序的缺陷密度累计值，得到计划的“Defect/Hour；

b) 开发后：用1000×实际的缺陷总数/实际的新开发和修改的代码行数

1. 用类似的方法计算缺陷密度的累计值

6. A/FR：质检/过失比

a) (Code Review Time+Design Review Time)/(Compile Time +Test Time)

b) 开发前：利用最近的前一个程序的A/FR，得到计划的A/FR；如果是首次估计，则利用估计的时间计算

c) 开发后：用实际的时间数据计算实际值和累计值

7. LOC：程序规模

a) 开发前：估算新的和修改的规模、最大、最小规模（考试一般可能会给定）

b) 开发后：登入实际的时间数据计算实际值和累计值

8. Time in Phase：开发阶段时间

a) 开发前：利用估算的新开发与修改代码行数，乘以估算的开发效率“Minute/LOC”，得到计划的项目总开发时间及最大、最小时间；利用最近（上一个）程序项目总结表中各阶段累计时间百分比，计算出各阶段计划时间

b) 开发后：用实际的时间数据（时间记录日志）登入各阶段时间值；计算累计时间；计算累计百分比

9. Defects Injected：引入的缺陷

a) 开发前：利用计划估计的缺陷密度乘以计划的新开发和修改代码行数，然后除以1000；利用最近（上一个）程序项目总结表中各阶段累计引入缺陷百分比，计算出各阶段将引入的缺陷个数

b) 开发后：用实际的缺陷数据（缺陷记录日志）登入各阶段值；计算累计值及累计百分比

c) 缺陷引入率：使用累计缺陷值计算Def./Hour

10. Defects Removed：排除的缺陷

a) 开发前：利用缺陷排除的累计百分比的历史数据计算各个阶段计划排除的缺陷数；

b) 开发后：用实际的缺陷数据（缺陷记录日志）登入各阶段值；计算累计值及累计百分比

c) 缺陷排除率：使用累计缺陷值计算Def./Hour