标签：知识点 复习 项目 --- 回顾总结 关键 软件 过程 质量

软件过程与管理知识回顾

两个大题：

1.关键路径 15

2.挣值分析 15

一、概论

1. 软件工程的三要素。（每一个的含义）

三要素是方法、工具、过程。

方法：是完成软件开发的各项任务的技术方法，为软件开发提供“如何做”的技术。

工具：为运用方法而提供的自动的或半自动的软件工程的支撑环境。

过程：是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤，如何将软件工程方法与软件工具相结合，合理、及时地进行软件开发。

2. 软件过程的定义。

软件过程是用于软件开发及维护的一系列活动、方法及实践。

3. 常见的软件过程分类（五大类）。常见的软件过程。

ISO/IEC 15504软件过程分类（5大类）：客户-供应商过程，工程过程，支持过程，管理过程，组织过程。

软件过程模型：瀑布、快速原型、增量、螺旋、形式化方法、基于组件的开发模型

二、软件质量管理

1. 软件质量的定义。

软件质量是软件产品满足明确或隐含需要能力的性能和特性的总体。

ISO是一个组织的英语简称。其全称是International Organization for Standardization，翻译成中文就是“国际化标准组织”。成立于1947年2月23日。ISO负责除电工、电子领域和军工、石油、船舶制造之外的很多重要领域的标准化活动。

IEC 是国际电工委员会标准（International Electro technical Commission)的简称,IEC负责有关电工、电子领域的国际标准化工作.

2. ISO/IEC 9126的结构、六个一级质量特性（名称）、一级特性对应的二级特性（选择题）。

1991年ISO/IEC 9126中，软件质量度量模型由三层组成：软件质量特性（即一级质量特性），软件质量子特性（二级质量特性），软件质量度量评价准则（使用单位自行规定）。

2001年ISO/IEC 9126中，软件质量度量模型由四部分组成：质量模型，外部质量度量，内部质量度量，使用质量度量。

六个一级质量特性：

~ 功能性：在指定条件下使用时，软件产品提供满足明确和隐含需求功能的能力；

~ 可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力(在规定的条件下，在规定的时间内，软件不引起系统失效的概率)；

~ 易用性：在指定条件下使用时，软件产品被理解、学习、使用及其吸引用户的能力；

~ 效率（有效性）：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力；

~ 可维护性：软件产品可被修改的能力，修改可能包括修正、改进或者适应环境、需求和功能规约的变化；

~ 可移植性：软件产品从一种环境迁移到另一种环境的能力。

 

 

4个使用质量特性：

~ 有效性：软件产品在指定使用环境下，使用户准确、完整地获得规定目标的能力；

~ 生产率：软件产品在指定使用环境下，使用户花费合适的与有效性相关的资源数量的能力；

~ 安全性：软件产品在指定使用环境下，获得可接受的损害人类、商务、软件、财产或环境风险级别的能力；

~ 满意度：软件产品在指定使用环境下，使用户满意的能力。

3. 朱兰质量管理三部曲（含义、怎么做）。

 

质量计划 (Quality Plan)：确定项目应达到的质量标准，以及如何满足质量标准的计划安排和方法。

质量保证(Quality Assurance, QA)：确保项目达到有关标准，而开展的有计划、有组织的工作活动。”Is it done right?”

质量控制(Quality Control, QC)：是确定项目结果与质量标准是否相符，并及时纠正产品缺陷的过程。”Is it right done?”

三、软件项目管理

1. 基本概念：项目；项目管理；项目管理的五大过程组；项目管理的十大知识领域。

软件：软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据

~ 项目：为完成某一独特的产品、服务或成果所做的一次性努力。

~ 项目管理(PM)：在项目活动中运用相关知识, 技能, 工具和技术满足项目的要求。

 

五大过程组：

~ 启动

~ 计划

~ 执行

~ 控制

~ 收尾

 

十大知识领域：

~ 项目集成管理

  Project Integration Management

~ 项目范围管理

  Project Scope Management

~ 项目时间管理

  Project Time Management

~ 项目成本管理

  Project Cost Management

~ 项目质量管理

    Project Quality Management

~ 项目人力资源管理

   Project Human Resource Management

~ 项目沟通管理

   Project Communications Management

~ 项目风险管理

   Project Risk Management

~ 项目采购管理

   Project Procurement Management

~ 项目利益相关者管理

   Project Stakeholder Management

 

2. 可行性分析：净现值的优点（不考计算题）。

净利润/回收期/投资回报率在一定程度上忽视了成本和现金流的时限/收益的大小/现金的时限利息和利率。

~ 净利润(Net Profit)

~ 回收期(Payback Period)

~ 投资回报率(Return On Investment, ROI) 平均年利润除以总投入

~ 净现值(Net Present Value, NPV)

~ 内部回报率(Internal Rate of Return, IRR)

~ 净现值是指特定方案未来现金流入量的现值和未来现金流出量的现值之间的差额。

 

优点：1.考虑了货币的时间价值（主要有限）增强了投资经济性的评价 2、考虑了投资风险，风险大则采用高折现率，风险小则采用低折现率。3、净现值对现金流量进行了合理折现

~ 给定贴现率r,计算公式为：

第t年的净现值（NPV） = 第t年的值/(1+r)^t

~ 1.0/(1+r)^t为第t年的贴现因子 (Discount Factor);

~ 使得净现值为0的贴现率称之为内部回报率。

 

 

3. 识别软件项目的活动：WBS（Work Breakdown Structure, WBS）。

活动：

~ 应该有明确的开始时间和结束时间

~ 活动需求的资源应该是可以预测的，并且这些资源在整个活动期间都是需要的

~ 活动的周期应该是可以预测的

~ 有些活动可能在开始之前需要先完成其它活动

 

• 任务分解结构（WBS）：是面向可交付成果的对项目任务的分组，它组织并定义了整个项目范围。它是一个分级的树型结构，是对项目由粗到细的分解过程。
• 叶子节点 和 中间节点都是什么？

            叶子节点（功能-子功能）：只有最底层的叶子节点构成了项目的活动集合。

            中间结点（功能）

 

4. 软件工作量估计方法：常见的软件工作量估计方法，记住名称，并理解每个方法。

3.1 专家判断

~ 对应用领域或开发环境有丰富知识的人，对执行一项任务所需的工作量做出估计

3.2 类比估计

根据实例特征，评价相似程度，利用相似的项目数据得到最终估算值。

需要有经验的领域，不能在早期规模不确定的时候使用，难以适应约束条件技术，人员等重大变化。

3.3 由底向上

3.4 自顶向下

3.5 Albrecht功能点

三种交易类型：外部输入类型、外部输出类型、外部查询系统

两种数据类型：内部逻辑文件类型、外部接口文件类型

3.6 Mark II 功能点

逻辑事务

适用于所有项目，尤其适用于MIS类项目. 简单。MarkII功能点标准操作简单只需进行简单的加权计算即可。但标准缺乏对基本元素的识别规则，例如对数据元素、逻辑事务仅采用举例的方式加以说明，实际操作过程中可能会出现歧义，度量结果的一致性不强。

3.7 COSMIC全功能点

~ 适用于实时系统或嵌入式系统的功能点方法

3.8 COCOMO II：参数化的生产率模型

RCPX  Product reliability and complexity (产品的可靠性和复杂度)

RUSE  Reuse required (需要的可用性)

PDIF   Platform difficulty (平台难度)

PERS   Personnel capability (人员的能力)

PREX   Personnel Experience (人员的经验)

FCIL     Facilities available (设施的可用性)

SCED  Schedule pressure (进度压力)

 

5. 软件项目的进度安排：甘特图、关键路径法（大题）、关键链法、PERT技术。（关键路径法必须全面理解掌握，只需要掌握活动节点，活动箭头不需掌握；后两种方法了解，能够了解计算步骤（选择题））

  (1) http://www.doc88.com/p-5763050345476.html

  (2) https://wenku.baidu.com/view/6368fe9e51e79b8968022620.html

  (3) http://www.cnitpm.com/pm/5933.html

关键路径--只有等项目中耗时最多最长的活动完成之后，项目才能结束。这条路径就是关键路径，组成关键路径的活动就是关键活动。

 

总缓冲期：LS - ES (LF - EF)，

分为空闲(free)缓冲期和干预(interfering)缓冲期

空闲缓冲期：一个活动最早的完成日期 — 后续活动最早的开始日期

干预缓冲期：总缓冲期 — 空闲缓冲期

都取正值

关键链（不考计算题，考定义步骤）与关键路径相比，它既考虑项目活动的紧前关系，又考虑资源冲突，构建网络图，得到最长路径——关键链；关键链决定了项目工期。

 

关键链法的步骤：

1紧前关系，得到的最长路径---关键路径    

2考虑紧前关系和资源冲突，得到关键链（关键链决定了项目工期）  

3加入项目缓冲和汇入缓冲；项目缓冲：放在关键链后面；汇入缓冲：放在非关键链与关键链的交汇处      

4砍掉所有项目的一半计算缓冲大小

 

在任务所需的平均时间上增加了一块"安全时间"（Safety Time，ST）

考虑到任务内在的不确定性，在关键链的末端附加整块的安全时间，也就是项目的缓冲时间（Project Buffer，PB）

关键链方法引入了非关键链缓冲时间（Feeding Buffer，FB）这一概念。

如图3所示，任务C、D、E组成了项目的关键链，而任务A、B为非关键任务。由于任务B是任务E的紧前任务，为了防止任务A和B可能发生的延迟导致任务E不能按时开始，因此需要在任务B之后安排一定的缓冲时间，或者说让任务A和B有一定的提前量。这样，就可以有效地防止非关键任务对关键链产生负面影响。与项目的缓冲时间类似，非关键链缓冲时间整合与压缩了所有非关键链任务的安全时间。

 

关键链方法还引入了资源缓冲（Resource Buffer，RB）的概念，以防止关键链任务因资源没有及时到位而发生延误。

 

 

甘特图又叫横道图，它是以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。

甘特图的优点：

　　图形化概要，通用技术，易于理解；

　　中小型项目一般不超过30项活动；

　　有专业软件支持，无须担心复杂计算和分析。

　　甘特图的局限：

　　甘特图事实上仅仅部分地反映了项目管理的三重约束（时间、成本和范围），因为它主要关注进程管理（时间）；

　　软件的不足。尽管能够通过项目管理软件描绘出项目活动的内在关系，但是如果关系过多，繁杂的线图必将增加甘特图的阅读难度；

• PERT技术（不考计算题，考定义步骤）：全称：工程评估评审技术。类似于关键路径法。考虑到了进度管理中的风险，将不确定性引入了进度管理中。对活动周期进行三次估计，不再是CPM关键路径中的确定值。

PERT的步骤：

1.估计每个活动的最有可能时间，乐观时间，悲观时间，计算活动的期望周期与标准偏差。

2.正向遍历得到期望达到事件的日期

3满足目标的可能性

 

6. 软件项目的资源管理：资源定义，资源分配直方图。

资源定义----资源是执行项目所需要的任何项和人。

资源分配直方图通过延迟某些活动的开始日期，来平衡化资源直方图。

资源直方图是用于管理资源的统计工具。它是一个定义资源分配计划的历史条形图。资源直方图帮助项目经理进行资源规划和质量管理。

资源直方图是堆叠的条形图，用于项目管理中的资源分配。它基本上是一个资源计划图，显示资源在一段时间内计划工作的时间量。它还可用于确定资源可用性。

 

       资源分类：

~ 劳动力 (labor)

~ 设备 (equipment)：计算机、办公设备等

~ 材料 (material)：打印纸、光盘等

~ 场地 (space)

~ 服务 (service)：网络、通信等

~ 时间 (time)：可以与其它资源相互弥补

~ 钱 (money)

 

7. 软件项目的风险管理：风险的定义，风险管理的框架，风险处理的方法。

~ 风险定义：一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。

~ 三要素：事件、事件发生的概率、事件的影响

~ 风险管理的框架---风险识别，风险分析与优先级排序，风险策划，风险监督

~ 风险优先级，风险影响 = (可能的危害)×(发生概率)

~ 风险处理的方法---接受风险，规避风险，降低风险，转移风险

~ 风险的分类--4大类：参与者，技术，结构，任务

 

~ 风险管理框架：

 

 

8. 软件项目的监督和控制：挣值分析。（大题）

 

(1)  https://wenku.baidu.com/view/7bcf90280066f5335a81211b.html

(2)  https://blog.csdn.net/pmpljp/article/details/19299077

挣值分析---0/100 OR 百分比

计划价值(已计划工作的预测成本)---Planned value --- PV-----200*5

挣值(已执行工作的预测成本)---Earned value ---EV-----200*3.5

实际成本(已执行工作的实际成本)--- Actual Cost ---AC----1000

进度偏差(已完成的工作值与计划的工作值的差)---Schedule Variance-- SV ---EV-PV---700-1000

成本偏差(已完成工作的预算成本和实际成本的偏差)---Cost Variance --CV --EV-AC---700-1000

进度性能指标(Schedule Performance Index, SPI): SPI = EV / PV---大于1及比预期好

成本性能指标(Cost Performance Index, CPI): CPI = EV / AC----大于1及比预期好

完成时间的估计值(按照当前进度项目的完成时间估计)---TEAC = SAC / SPI (Schedule At Completion, SAC, 项目的计划周期)--------10/0.7

项目的成本预算(按照当前的进度，项目的总支出的估计)--- EAC = BAC / CPI (Budget At Completion, BAC, 计划的项目预算)-----2000/0.7

出题另有：试画出项目的PV、AC、EV曲线，并分析项目的状态。各项任务完成的比例见表3。(完成百分比法分配挣值)

 

9. 软件项目的配置管理（定义）：配置管理的任务，配置项。

定义：软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则。它是控制软件系统演变的学科。

目标：

~ 标志变更

~ 控制变更

~ 确保变更正确实现

~ 向受变更影响的组织和个人报告变更

 

         任务：

    1.标识

    2.版本控制

    3.变更控制

    4.配置审核

    5.配置报告

~ 配置项：软件配置管理的对象，一个软件配置项是项目中一个特定的、可文档化的工作产品集。例如，程序，文档等

 

四、经典的软件过程管理

1. CMM/CMMI（逻辑思路，优缺点）

(1) CMM：出发点，体系结构，关键过程域，关键实践活动。

CMM是一种理念，是指导思想，不是过程不是技术不是方法。

CMM---能力成熟度模型

CMM出发点---改善现有软件开发过程，也可用于其他过程。

CMM体系结构:

~ CMM由5个成熟度级别组成

~ 每个成熟度级别（除级别1）包含了实现该级别的若干个关键过程域（KPA）

~ 每一个KPA进一步被分为称为公共特征的5个部分：执行约定、执行能力、执行活动、测量和分析、验证实施

~ 这些公共特征包括了关键实践（KP），即每一个KPA包括5类KP

~ 实现了这些KP后，就实现了关键过程域的目标

 

CMM由5个成熟度级别组成：

每个成熟度级别（除级别1）包含了实现该级别的若干个关键过程域（KPA）

关键过程域(Key Process Area)：一系列相互关联的操作活动，标识了达到某个成熟度级别时所必须满足的条件。

CMM共有18个KPA，每一级都有自己的KPA。KPA分为三大类：管理过程、组织过程和工程过程。

 

每一个KPA进一步被分为称为公共特征的5个部分：执行约定、执行能力、执行活动、测量和分析、验证实施

这些公共特征包括了关键实践（KP），即每一个KPA包括5类KP

 

实现了这些KP后，就实现了关键过程域的目标.

 

(2) CMMI与CMM的区别和联系，CMMI的两种表示方法（阶段式、连续式）。

区别和联系：
联系：CMMI即CMM集成，是系统工程和软件工程的集成成熟度模型，CMMI是在CMM基础上发展起来的，它继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果
区别：CMMI共有分属于4个类别的25个过程哉,覆盖了4个不同的领域;相对应的CMM共有18个过程域.
CMMI更适合于信息系统集成企业，，它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域
CMMI比CMM进一步强化了对需求的重视.在CMM中,关于需求只有需求管理这一个KPA。在CMMI中,3级有一个独立的KPA叫做需求开发,提出了对如何获取优秀的需求的要求和方法。

两种表示方法：
阶段式表示法 连续式表示法

阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个 成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。

而连续式表现方法则通过将CMMI 中过程域分为四大类： 过程管理 、 项目管理 、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。

2. PSP：结构，两种日志，评审比测试有效的原因，四个设计模板（对应哪个UML）。

PSP过程由一系列方法、表格、脚本等组成，用以指导软件开发人员计划、度量和管理他们的工作。

~ PSP成熟度模型

   PSP具有4个等级，7个台阶组成的成熟度框架 。4个等级分别为个体度量过程、个体计划过程、个体质量管理过程和个体循环过程。

 

日志---时间日志和缺陷日志

评审比测试有效的原因--在评审时发现的错误比测试是发现的多；成本低。缺陷发现的越早，修复的花费越低；且避免缺陷比发现和修复缺陷更有效。

~ 代码评审：一般来说，利用评审检查表已经足够了。

~ 设计评审：单纯利用评审检查表不够，需要利用验证方法，验证设计的逻辑不出错。

 

    验证方法：

~ 状态机验证

~ 符号化验证

~ 执行表验证

~ 正确性验证

==============================================

四个设计模板---a操作规格模板，b功能规格模板,c状态规格模板,d逻辑规格模板

LST逻辑规格模板（无）：用于描述系统中各有机组分（方法，项，算法等）的逻辑实现。

SST状态规格模板（UML:状态机图）：用于描述系统中所有可能发生的状态的集合，以及状态之间转换的条件，伴随的动作。。

FST功能规格模板（UML:类图）：描述了系统可以向用户提供对外部可见的行为说明书，以及与这些功能相关的系统行为，变量和内部关系（继承关系）。

OST操作规格模板（UML:用例图、时序图）。描述了系统与外界的交互。描述了用户与待设计系统的正常情况下和异常情况下的交互。

3.软件过程模型：瀑布、原型、增量、螺旋、形式化、组件的优缺点。看PPT

瀑布模型

特点：

开发阶段严格按照线性方式进行、阶段间有因果关系、每个阶段需评审确认、

允许反馈、强调文档

适合场所：需求易于完善定义的软件

缺点：

各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；开发过程中很难响应客户的变更要求；

早期的错误可能要等到开发后期的测试阶段才能发现，进而带来  严重的后果

快速原型模型

优点：

加强用户和软件人员之间的沟通，明确系统的需求

尽早得到系统可用性的反馈信息，及时修改以获得完整、正确需求

缺点：

用户会由于看到的原型系统不完善，而对产品产生怀疑

可能为了快速开发原型系统，而采用未经充分论证的技术（如操作系统平台、主要的算法）导致质量低下

增量模型

优点：

整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本；

将早期增量作为原型有助于明确后期增量的需求；

降低开发风险；

重要功能被首先交付，从而使其得到最多的测试

缺点：

需要软件具备开放式的体系结构，以便各个构件逐步进入

需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难，容易退化为边做边改方式，使软件过程的控制失去整体性

螺旋模型

优点：

风险驱动；关注软件的重用；关注早期错误的消除；将质量目标放在首位；将开发阶段与维护阶段结合在一起；

缺点：需要风险评估的经验；只适应内部大规模软件开发；

形式化方法模型

优点：

由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性

缺点：

开发人员需要具备一定技能并经过特殊训练；

形式化描述和转换是一项费时费力的工作,成本高，质量不一定高；

现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述；

基于组件的开发模型

优点：充分体现软件复用的思想、实现快速交付软件、利用开源组件与软件

缺点：商业组件的修改受到限制，影响系统的演化。

 

4.MSF：六个角色；过程模型中的五个阶段。

MSF即微软的解决方案。团队是微软作战最小的基本单元。Microsoft Solution Framework

 

项目场景中的6个角色：产品管理，程序管理，开发，测试，发布管理，用户体验。

5个阶段：构思阶段，计划阶段，开发阶段，稳定阶段，部署阶段。

 

5. RUP：九个 软件过程（6核心，3辅助），四个阶段，六大经验。

Rational Unified Process），统一软件开发过程,面对对象的软件工程的过程框架。

• 9个过程域：6个是核心3个是辅助：

6个核心过程流：商业建模，需求，分析和设计，实现，测试，部署。

3个辅助过程流：配置和变更管理，项目管理，环境。

• 4个阶段：初始，细化，构造，交付。(每个阶段做什么，做完的里程碑，中间产品是什么？)

	主要活动	里程碑	中间产品
起始（先启/初始）阶段	² 建立系统的业务模型 ² 捕获系统的基本需求 ² 确定系统的边界 ² 识别关键任务 ² 确定系统验收标准 ² 进行项目风险评估 ² 进行项目资源的估计与效益分析 ² 制定项目开发计划于重要里程碑	生命期目标	² 项目蓝图文档：系统的核心需求、关键特性与主要约束 ² 初始的用例模型（完成10%~ 20%） ² 初始的项目术语表 ² 业务用例模型，包括商业环境、验收标准和财政预测 ² 初始的风险评估 ² 一个可以显示阶段和迭代的项目计划 ² 一个或多个原型 ² 初始的架构文档
细化阶段（最关键的阶段）	² 细化构想，建立对大多数关键用例的确定理解 ² 分析问题域，建立坚实的架构 ² 细化机构并选择组件 ² 捕获80%的功能需求用例 ² 精化风险评估 ² 建立可执行的软件原型 ² 定义非功能需求 ² 制定过程迭代计划和迭代的评价标准	生命期构架	² 系统架构基线 ² UML静态模型、UML动态模型、UML用例模型 ² 修订的风险评估 ² 修订的用例 ² 修订的项目计划 ² 可执行的原型
构造阶段	² 资源管理、资源控制和过程优化 ² 完成组件开发并根据已定义的评价准则进行测试 ² 利用构想指定的准则对发布的产品进行评估	初始运作功能。 构造阶段的结束时项目开发的第三个重要的里程碑。这个阶段产生的版本通常被称为β版。	² 可运行的软件系统 ² UML模型 ² 测试用例 ² 用户手册 ² 发布描述
交付（转化、产品化）阶段	² 将软件系统部署到用户环境 ² 修复软件的缺陷 ² 编制用户手册和其他文档 ² 培训用户和维护人员 ² 提供用户咨询	产品发布	² 可运行的软件产品 ² 用户手册 ² 用户支持计划

 

六大经验---

迭代式开发，管理需求，基于组件的体系结构，可视化建模，验证软件质量，控制软件变更

 

五、敏捷软件开发

1. 敏捷宣言。

~ “注重个人及互动胜于过程和工具”

~ “注重可用的软件胜于详尽的文档”

~ “注重客户协作胜于合同谈判”

~ “注重响应变化胜于恪守计划”

q

q

q

2. 常见的敏捷软件过程，SCRUM和极限编程（含义思想，简单描述）。

 

 

---极限编程XP

是一种全新而快捷的软件开发方法。XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流。这可以帮助团队最大化地发挥他们的价值。------现场客户，计划游戏，系统隐喻，简单设计，代码集体所有，结对编程，测试驱动，小型发布，重构，持续集成，每周4小时工作制。

XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件

 

---并行争球法---Scrum---增量的迭代的开发过程

整个 开发周期包含若干个小的迭代周期，每个小的的迭代周期称为一个Sprint（2-4周）

 

---水晶法Crysta----每一个不同的项目都需要一套不同的策略、约定和方法论

 

 

 

~ 产品负责人 Product Owner：负责维护产品订单的人，代表利益相关者的利益。

~ Scrum主管 Scrum Master：为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。

~ 开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。

 

 

 

~ 计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。

~ 每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。

~ 评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。

~ 反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。

 

~ 产品订单(product backlog)是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。

~ 冲刺订单(sprint backlog)是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。

~ 燃尽图(burn down chart)是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。

 

 

~ XP是以开发符合客户需要的软件为目标而产生的一种方法论

~ XP是一种以实践为基础的软件工程过程和思想

~ XP认为代码质量的重要程度超出人们一般所认为的程度

~ XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件

 

极限编程准则：

~ 沟通

~ 简单

~ 反馈

~ 勇气

~ 尊重

~ 谦逊

 

补充

软件质量度量模型由三层组成：软件质量特性，软件质量子特性，软件质量度量评价准则

质量成本是为了达到产品或服务的质量而付出的所有努力的总成本，包括三部分：

    预防成本：为防止将缺陷引入软件而进行的预防工作所消耗的费用。

    评价成本：检查软件是否包含缺陷的工作所消耗的费用。

    失效成本：修复缺陷工作所消耗的成本。

缺陷跟踪：缺陷跟踪是指从缺陷被发现开始到被改正为止的整个跟踪流程。

 

参考：https://www.cnblogs.com/Amyheartxy/p/9143977.html

标签：知识点,复习,项目,---,回顾总结,关键,软件,过程,质量
来源： https://www.cnblogs.com/rainbow-1/p/16300728.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。