软件工程知识点总结

1.软件的本质

1.1 软件是什么：

1. 软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述程序操作的文档

---

1.2 软件的特点

1. 软件是设计开发的，而不是传统意义上生产制造的
2. 软件不会“磨损”
3. 虽然整个工业向着基于构建的构造模式发展，然而大多数软件仍然是根据实际顾客的需求制定的

---

1.3 软件的失效曲线

1.4 硬件的失效曲线

1.5 软件的演化和遗留软件

1. 软件需要适应性调整，从而可以满足新的计算环境或者技术的需求
2. 软件必须升级以实现新的商业需求
3. 软件必须被扩展使之具有与更多系统和数据库的互操作能力
4. 软件架构必须进行改建以适应不断演化的计算环境

---

1.6 软件应用领域

1. 系统软件
2. 应用软件
3. 人工智能软件
4. web应用软件
5. 嵌入式软件
6. 产品线软件
7. 工程/科学软件
8. 移动应用软件

---

1.7 Web App 的特点

1. 数据驱动
2. 内容敏感性
3. 持续演化
4. 及时性
5. 安全性
6. 美观性

---

1.8 移动 App 的特性

1. 移动平台上专门设计的软件
2. 用户接口，用户接口利用移动平台所提供的独特交互机制
3. 移动平台中的持续储存能力
4. 基于Web资源的互操作性提供与app相关的大量信息的访问，并且具有本地处理能力
5. 移动app可以直接访问本地的硬件，并提供本地存储和处理能力
6. 移动web应用系统和移动app之间的界限越来越模糊
7. 移动web应用系统允许移动设备通过针对移动平台的优点和弱点专门设计浏览器获取基于web内容的访问

---

1.9 云计算

1. 云计算提供分布式数据处理和存储功能，他能使得任何用户在任何地点都能使用计算设备来共享广泛的计算资源
2. 计算设备位于云的外部，可以访问云内部的各种
3. 云计算的实现需要开发包含前端和后端服务的体系结构
4. 前端包括客户（用户）设备和应用软件（例如浏览器）用于访问后端
5. 后端包括服务器和相关的计算资源、数据存储系统（如数据库）、服务器驻留应用程序和管理服务器
6. 可以对云体系结构进行分段，提供不同级别的访问

---

1.10 软件产品线

1. 软件产品线是一系列软件密集型系统，可以共享一组公共的可管理的特性，这些特性可以满足特定市场或任务的特定需求
2. 软件产品线都使用相同的底层应用软件和数据体系结构来开发，并使用可在整个产品线中复用的软件构件来实现。
3. 软件设计线可以共享一组资源，包括需求、体系结构，设计模式，可重用构建、测试用例以及其他软件工程工作产品。
4. 软件产品线在对这些产品进行工程设计时，利用了产品线中所有产品的公共性。

---

1.11 软件危机的表现

1. 软件开发的工作量估计困难，开发进度难以控制，质量难以保证
2. 软件开发效率低
3. 软件质量无法得到保证
4. 软件开发成本过高
5. 软件维护困难，用户满意度不高

---

1.12 软件危机的原因

（一）软件本身的需求和特征

1. 软件规模大，复杂性高，性能不断增强
2. 软件是逻辑产品，完全认识其本质和特点极其苦难

---

（二）工程管理技术缺乏

1. 缺乏有效的、系统的开发、维护大型软件项目的技术手段和管理方法

---

（三）沟通和理解

1. 用户对软件需求的描述和软件开发人员对软件需求的了解往往存在差异，用户经常要求修改需求，开发人员很难适应

（四）人员和技术

1. 软件开发的技术人员和管理人员缺乏软件工程化的素质和要求，对工程化开发认识不足

---

2.软件工程

2.1 工程

工程是科学技术再某一领域的应用，通过这一领域应用，使自然界的物质和能源的特性能够通过各种结构，机器，产品，系统和过程，以时间最短和精而少的人力做出高效，可靠且对人类有用的东西。

---

2.2 系统工程

是一个跨多学科领域的工程，通常专注于如何设计和管理复杂的工程专案。

---

2.3 系统工程学

1. 通过人和计算机的配合，能充分发挥人的理解、分析、推理、评价、创造等能力的优势，又能利用计算机高速运行和追踪能力。以此来实验和剖析系统，从而获得丰富的信息，为选择最优或次优的系统方案提供有力的工具。
2. 系统工程学模型能容纳大量的变量；他是一种结构模型，通过他可以充分认识系统结构，并以此来把握系统的行为，而不只是依赖数据来研究系统行为。
3. 系统工程学是结构方法，功能方法和历史方法的统一。它有一套完善的解决复杂系统问题的工具和技巧。

---

2.4 软件工程历史

1968年北大西洋公约（NATO）召开的计算机科学会议

软件工程 = 软件的工程

---

2.5 软件开发需面对的几个事实

1. 确定软件方案之前，需要共同努力来理解问题
2. 设计已成关键活动
3. 软件应该具有高质量
4. 软件需具备可维护性

---

2.6 软件工程目标和原则

1. 目标 ：在给定成本、进度的前提条件下，开发出满足用户需求的高质量的软件产品 （高质量的含义： 有效性、可靠性、可适应性、可追踪性、移植性、可互操作性、可修改性）的软件产品。
2. 原则：在软件开发中为了达到软件开发目标而必须遵守的原则包括：抽象、模块化、信息隐藏、局部化、一致性、可验性证

---

2.7 软件工程的定义

1. 为了经济的获得可靠，在实际机器上高效运行的软件，而建立和使用的有使用价值的工程原则。
2. IEEE93：将系统的、规范的、可度量的方法应用于软件的开发、运行和维护的过程。

---

2.8 软件工程三要素

1. 软件工程采用层次化（分解）的方法，每个层次都包括 过程 方法 工具三个要素
   

过程贯穿软件开发的各个环节

过程和方法：管理者在软件工程过程中通过适当的方法对软件开发的质量、进度、成本进行评估管理和控制；

方法和工具：开发人员采用相应的方法和工具生成软件工程产品（模型、文档、数据、报告、表格等）

---

2.9 软件工程过程

---

2.10 过程的适应性调整相关问题

1. 活动、动作和任务的总体流程，以及相互依赖关系
2. 在每一个框架活动中，动作和任务细化的程度
3. 工作产品的定义和要求的程度
4. 质量保证活动的应用方式
5. 项目跟踪和控制活动应用的方式
6. 过程描述的详细程度和严谨程度
7. 客户和利益相关者对项目参与的程度
8. 软件团队所赋予的自主权
9. 队伍组织和角色的明确程度

---

2.11 软件工程实践

实践的精髓

1. 理解问题（沟通和分析）
2. 计划解决方案（建模和软件设计）
3. 实施计划（代码生成）
4. 检查结果的正确性（测试和质量保证）

---

理解问题

1. 谁将从问题的解决中获益？

   也就是说，谁将是利益相关者？

2. 有哪些是未知的？

   哪些数据、功能和特征是解决问题所必须的？

3. 问题可以划分吗？

   是否可以描述为更小，更容易理解的问题？

4. 问题可以图形化描述吗？

   可以建立分析模型吗？

---

计划解决方案

1. 以前见过类似的问题吗？

   潜在的解决方案中，是否可以识别一些模式？是否已经有软件实现了所需要的数据，功能和特征。

2. 类似问题是否解决过？

   如果是，解决方案所包含的元素是否可以复用？

3. 可以定义子问题吗？

   如果可以，子问题是否已有解决方案

4. 能用一种可以很快实现的方案来描述解决方案吗？

   能构建出设计模型吗？

---

实施计划

1. 解决方案和计划一致吗？

   源代码是否可以追溯到设计模型？

2. 解决方案的每个组成部分是否可以证明正确？

   设计和代码是否经过评审？或者采用更好的方式，算法是否经过正确性证明？

---

检查结果

1. 能够测试解决方案的每个部分?

   是否实现了合适的测试策略？

2. 解决方案是否产生了与所需数据、功能和特征一致的结果？

   是否按照项目利益相关者的需求进行了确认？

---

2.11 软件实践通用原则——HOOKER 的概括性原则

1. 存在价值
2. KISS(保持简洁)
3. 保持愿景
4. 关注使用者
5. 面向未来
6. 计划复用
7. 认真思考

---

2.12每个软件工程项目都来自业务需求

1. 对现有应用程序缺陷的修正
2. 改变遗留系统以适应新的业务环境
3. 扩展现有应用程序功能和特性
4. 或者开发某种新的产品，服务或系统

---

3. 软件过程结构和过程改进

3.1 通用软件过程模型

任务集定义了为了达到一个软件工程动作的目标所需要完成的工作

1. 要完成的任务列表
2. 待生产的产品列表
3. 待使用的质量保证技术列表（保证点、里程碑）

---

3.1 过程模式

（一） 过程模式（process pattern)

1. 描述了软件工程工作中遇到的过程相关问题

2. 明确了问题环境

3. 给出了针对该问题的一种或多种可证明的解决方案

4. 通俗地讲，过程模式提供了一个模板

   一种在软件过程背景下，统一描述解决问题的方法。包括模式名称和驱动力。

---

（二） 过程模式类型

1. 步骤模式（Stage patterns） 定义了与过程的活动框架相关的问题。
2. 任务模式（Task patterns） 定义了与软件工程动作或是工作任务相关，关系软件工程实践成败的问题。
3. 阶段模式（Phase patterns）定义了过程中发生的框架活动序列，即使这些活动流本质上是迭代的。

---

（三）过程模式模板

1. 启动条件
  	1. 组织或者团队的已有活动
  	2. 过程进入的状态
  	3. 已有的工程信息或者项目信息
2. 问题：要解决的具体问题
3. 解决方案：如何成功实现
	1. 初始状态如何改变
	2. 工程信息或者项目信息如何改变
4. 结果：
	1. 必须完成的相关活动任务
	2. 过程结束状态
	3. 产生的工程信息或者项目信息

---

(四)过程评估与改进

1. 用于过程改进的CMMI评估方法——
   1. 启动
   2. 诊断
   3. 建立
   4. 执行
   5. 学习
2. 用于组织内部改进的CMM评估方法，采用了SEI的CMM作为评估的依据，提供了一种诊断方法，用以分析软件开发机构相对成熟度。
3. SPICE——定义了软件过程评估的一些要求。该标准的目的是帮助软件开发组织建立客观的评价体系，以评估定义的软件体系的有效性
4. 软件ISO 9001:2000——这是一个通用标准，任何开发组织或个人如果希望提高所提供的产品系统或服务的整体质量，都可采用这个标准。因此该标准可以直接应用于软件组织和公司。

---

3.2 CMM 能力成熟度模型：

L1：初始级

L2：可重复级

L3：已定义级

L4：已管理级

L5：优化级

关键过程域

描述软件过程的属性，通过完成一组相互关联的活动，实现一组对建立过程至关重要的目标

1. 关键过程域是SEI标识的，帮助确定软件开发组织的软件过程能力，评估软件成熟度的基本单元
2. 关键过程域用具有固定结构和语句的框架标识
   1. 关键过程域的目标是指导和评估组织或组织的项目有效实践关键过程域的指南，是关键过程域应当完成的任务和进行关键实践的概括描述。

3.3 CMMI 能力成熟度模型：

CMM的成功导致许多领域也建立了相应的评估模型，但是导致了模型框架和术语等方面的矛盾和不一致

产生过程和主要参考模型

1998年正式启动，来自业界和政府部门和SEI/CMU 三个方面的170余人的支持，经过两年的工作发表了v1.0

主要参考模型：

软件学科的 SW-CMM

集成化开发和过程开发领域的IPD CMM V0.98

CMMI的集成原则

1. 阶段表示法

2. 连续式表示法

   软件学科的两种表示法均采用统一的24个域，它们在逻辑上是等价的
   
   

---

4 过程模型

4.1惯用过程模型

惯用过程模型力求达到软件开发的结构和秩序

这将产生一些问题

---

4.2 软件生存周期

传统上分为三个时期，7个阶段

1. 软件定义
   1. 问题定义
   2. 可行性分析
   3. 需求分析
2. 软件开发
   1. 系统设计
   2. 编码
   3. 测试
3. 软件运行
   1. 维护

---

4.3 传统瀑布模型

1. 软件开发过程与软件生命周期是一致的
2. 相邻二阶段之间存在因果关系
3. 需要对阶段性产品进行评审

---

（一）优点

1. 软件生命周期模型，使得软件开发可以在分析、设计、编码、测试、和维护的框架下进行
2. 软件开发过程具有系统性，可控性，克服了软件开发的随意性。

---

（二）缺点

1. 项目开始阶段用户很难精确的提出产品需求，由于技术进步，用户对系统深入的理解，修改需求十分普遍。
2. 项目开发晚期才能得到程序的运行版本，这时修改软件需求和修正开发中的错误的代价很大。
3. 采用线性模型组织项目开发经常发生开发小组人员“堵塞状态”。特别是项目开始和结束阶段。

---

4.4 软件开发的V模型

---

4.5 软件开发的新瀑布模型

1. 增加了项目策划
2. 将设计和编码测试分开
3. 进一步细化各个阶段
4. 软件生命周期由原来的三时期七阶段==》五时期十七阶段
5. 仍然保持原来的特点

---

4.6增量过程模型

增量：

小而可用的软件

---

特点

1. 在前面的增量的基础上开发后面的增量
2. 每个增量的开发可以用瀑布或者快速原型模型
3. 迭代的思路
   

---

4.7 演化模型： 原型模型

1. 原型模型支持软件需求开发，帮助用户和开发人员理解需求，是软件需求工程的关键
2. 如果开发的原型是可运行的，它的若干高质量的程序片段和开发工具可用于工作程序的开发
3. 原型的开发和评审是系统分析元和客户/用户共同参与的迭代过程，每个迭代循环都是线性过程
4. 第一个原型通常会不太好用，太大或太慢
5. 利益相关者无法意识到原型的临时性，不愿意抛弃，总是希望小修改后使用，软件开发管理层大多数情况下会妥协。
6. 软件工程师为了快，会使用折中手段，采用自己熟悉的语言，系统乃至低效的算法。
   

---

4.8 螺旋模型

Bohem在1988年提出

螺旋模型=瀑布模型（系统化）+原型（迭代）

螺旋模型适用于计算机软件整个生命周期

---

4.9 螺旋模型的使用

软件工程项目从螺旋中心开始启动，沿顺时针方向前进

1. 第一圈：产生产品规格说明
2. 第二圈：产生一个用于开发的原型
3. 第三圈：产生软件产品的初始版本
4. 第四圈：产生软件产品比较完善的新版本

---

4.10 螺旋模型的有优点

1. 符合人们认识现实世界和软件开发的客观规律
2. 支持软件整个生命周期
3. 保持瀑布模型的系统性，阶段性
4. 利用原型评估和降低开发风险
5. 开发者和用户共同参与软件开发，尽早发现软件中的错误
6. 不断推出和完善版本软件，有助于需求变化，获取用户需求，加强对需求的理解

---

4.11 演化模型：并行模型

表示一个软件工程活动的状态

所有活动并发存在，但是处于不同的状态

可以用于所有类型的软件开发

---

4.12 其他专用过程模型

1. 基于构建的并发模型——能够使软件复用
2. 形式化方法模型——注重需求的数学规格说明
3. 面向方法的软件开发模型——为定义、说明、构建和设计方面提供过程和方法
4. 统一过程模型——一种“用例驱动，以构架为中心的迭代和增量”软件过程和统一建模语言（UML）紧密结合
   

---

4.13 UP工作产物

1. 起始阶段：

   1. 版本文档
   2. 初始项目表
   3. 初始商业用例
   4. 初始风险评估
   5. 项目计划、阶段和迭代
   6. 商业模型
   7. 一个或多个原型

2. 细化阶段：

   1. 用力模型
   2. 补充需求（包含非功能性的分析模型和软件架构描述）
   3. 可执行的框架原型
   4. 初步设计模型
   5. 修正的风险清单
   6. 项目计划（包括迭代计划，适应性工作流，里程碑和技术性工作产物）
   7. 初步使用手册

3. 构建阶段

   1. 设计模型
   2. 软件构件
   3. 集成软件增量
   4. 测试计划和步骤
   5. 测试用例
   6. 支持文档
   7. 用户手册
   8. 安装手册
   9. 当前版本描述

4. 转换阶段

   1. 交付软件增量
   2. Beta测试报告
   3. 用户反馈报告
      

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YFKaE1p9-1637057983927)(C:\Users\asus\AppData\Roaming\Typora\typora-user-images\image-20211109124756741.png)]

---

4.14 RUP 软件生命周期

四个阶段 阶段的结束标志着重要的里程碑

1. 先启 - 定义整个项目的范围
2. 精化 - 制定项目计划、描述功能、建立体系架构框架
3. 构建 - 构造软件产品
4. 产品化 - 将软件产品移交到最终用户手中

---

4.15 迭代和阶段

迭代 是一个基于确定计划和评估标准并产生一个可执行发布版本（内部的或外部的）的独特活动序列。

1. 初启阶段
2. 精化阶段
3. 构建阶段
4. 移交阶段

---

4. 16 软件过程的定义

软件过程定义由 谁 在 什么时候 做 什么事情， 并且 如何 去达到一定的目标

---

4.17 统一过程的模型

用例模型：用例与用户之间关系（交互时）

分析模型：系统的行为初步分配给一组对象

设计模型：系统静态结构定义为子系统，类，接口，并定义由子系统、类和接口之间的协作所实现的用例

实现模型：构建（表现为源代码）和类到构件的映射

实施模型：计算机的物理节点和构件到这些节点的映射

测试模型：用于验证的测试用例

---

4.18个人软件过程 PSP

1. 策划
2. 高层设计
3. 高层设计评审
4. 开发
5. 后验

5 敏捷开发

5.1 敏捷开发宣言

5.2 什么是敏捷

1. 对变更的良好响应：有效且灵活的响应变化
2. 个人和他们之间的交流：利益相关者（经历，客户，最终用户）之间的有效沟通
3. 客户合作：将客户作为开发团队的一部分，不再分你我
4. 组织高度自主的项目团队（敏捷团队）：承认计划的局限性，项目计划灵活调整，过程设计是的团队与任务相适应，任务流水线化，提前指定计划，保留最重要的工作产品且力求整洁，增量交付。
5. 最重要的是：快速交付给用户可运行软件增量

敏捷是一种理念，是一种以人为本的哲学思想

---

5.3变更成本以及敏捷过程

工程变更的成本 每过一阶段变回变为上一阶段的x倍

一个良好设计的敏捷过程可以拉平成本曲线

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cIj0RXGj-1637057983932)(C:\Users\asus\AppData\Roaming\Typora\typora-user-images\image-20211109201119948.png)]

---

5.4敏捷过程

三个假设（不可预测性）：1）需求变更预测，以及客户优先级的变更预测的困难

​ 2）在构建验证之前很难估计应该设计到什么程度；

​ 3）从在制定计划的角度看，分析，设计，构建和测试不像 我们想象的那样难以预测

因此，我们应当遵守如下过程：

1. 由用户所需的应用场景驱动
2. 认识到计划时间很短
3. 使用增量式开发策略
4. 交付多个软件增量版本
5. 能做出适应性变更

---

5.5 敏捷原则

1. 我们最优先要做的是通过尽早，持续交付有价值的软件来使客户满意
2. 即使在开发的后期，也欢迎需求变更，敏捷过程利用便捷客户来创造竞争优势
3. 经常交付可运行软件，交付的间隔可以是从几个星期到几个月，交付的时间间隔越短越好
4. 在整个项目开发期间，业务人员必须天天一起工作
5. 围绕有积极性的个人构建项目，给他们提供所需要的环境和支持，并且信任他们可以完成任务
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交流，
7. 可运行软件是进度的首要度量标准
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应能长期保持稳定的开发速度
9. 不断地关注优秀的技能和好的设计会增强敏捷能力
10. 简单——使不必要做的工作最大化的艺术——是必要的
11. 最好的构架、需求和设计出自于自组织团队
12. 每隔一段时间，团队反省如何才能更有效的工作，并相应调整自己的行为

---

5.6 人的因素

1. 基本能力
2. 共同目标
3. 精诚合作
4. 决策能力
5. 模糊问题解决能力
6. 相互信任和尊重
7. 自组织

---

5.7 极限编程（XP）

是使用最广泛的编程

1. XP策划

2. XP设计

3. XP编程

4. XP测试

---

5.8 行业极限编程

IXP的管理具有更大的包容性，扩大了用户角色，升级了技术实践

1. 准备评估
2. 项目社区
3. 项目特许
4. 测试驱动管理
5. 回顾
6. 持续学习

---

5.9 Scrum基本特征

包括了一系列实践和预定义角色的过程骨架

基本特征：

1. 开发活动由工作单元完成

2. 测试和文档编制工作贯穿始终

3. 发生于一个过程模式中的工作任务称为一个冲刺，其来源于待定项中定义的需求

4. 例会时间很短，有时候甚至站立开会

5. 在规定时间内将演示软件交付给用户

---

5.10 Scrum 四大支柱

1. 迭代开发
2. 增量交付
3. 自组织团队
4. 高优先级的需求驱动

---

5.11 敏捷方法之极限编程和Scrum的区别

1. 迭代长度不同
2. 在迭代中是否允许修改
3. 在迭代中，User story 是否严格按照优先级别来实现
4. 软件的实施过程中 ，是否采用严格的工程方法，保证进度或者质量

---

5.12 动态系统开发方法(DSDM)

DSDM认为任何事都不能一次性圆满完成，应当以20%的时间完成80%的有用功能，以适应商业目的为准。

在很多方面类似于极限编程

九条基本原则：

1. 用户持续参与

2. 必须授予DSDM团队制定决策的权力

3. 注重产品的经常交付

4. 满足业务用途是接受交付品的主要依据

5. 迭代和增量式开发对于得到正确的业务解决方案是必不可少的

6. 开发过程中所有的变化可逆

7. 在高层次上制定需求的基线

8. 测试自始至终贯穿于开发周期之中

9. 所有项目涉众的通力合作是必不可少的
   

---

5.13 敏捷建模

提出一系列的敏捷建模原则

有目的的建模

使用多个模型

轻装上阵

内容重于表述形式

理解模型及工具

适应本地需要

---

5.14 敏捷统一过程（AUP）

每个AUP迭代执行以下活动

1. 建模
2. 实现
3. 测试
4. 部署
5. 配置以及项目管理
6. 环境管理

---

6 软件工程人员

6.1 软件工程师的特质：

1. 个人责任感
2. 对团队成员和利息相关者的需求有敏锐的意识
3. 对有缺陷的设计，用诚实且有建设性的方式指出错误
4. 抗压能力
5. 高度的公平感
6. 注重细节
7. 务实

---

6.2 软件工程的行为模式

---

6.3 跨界团队角色

1. 外联员 -代表团队和外部顾客谈判
2. 侦查员 -突破团队界限收集组织信息
3. 守护员 -保护团队产品
4. 安检员 -把控利益相关者和他人向团队传送的信息
5. 协调员 -注重横跨团队和组织内部的交流

---

6.4 高效团队的特征

1. 目标意识
2. 参与意识
3. 培养信任感
4. 鼓励进步意识
5. 团队技能的多样化

---

6.5 避免团队毒性

1. 混乱的工作环境会造成团队成员的精力浪费，失去对工作目标的关注
2. 由个人，商业或者技术原因造成的高度挫折会导致 团队成员的分裂
3. “支离破碎或协调不当”的软件过程模型或是定义错误的，选择不当的软件过程模型会成为工作中的阻碍。
4. 对软件团队中角色的模糊定义会造成团队缺乏责任感，遇到问题互相指责。
5. “持续且重复性的失败”会打击士气，使得团队成员缺乏自信。

---

6.6 影响团队结构的因素

1. 需解决问题的难度
2. 基于代码行或者功能点的结果程序的规模
3. 团队成员合作的时间
4. 问题可规模化的程度
5. 所建系统的质量和可靠性
6. 交付日期要求的严格程度
7. 项目所需的社会化

---

6.7 组织模式

1. 封闭模式：遵循传统的权力层级模式
2. 随机模式：团队松散，依靠团队个人自发性
3. 开放模式：尝试组成一种团队，既具有封闭模式的可控性，又具有随机模式的创新性
4. 同步模式：有赖于问题的自然区分，不需要很多交流就可以将成员组织起来共同解决问题。

---

6.8 敏捷团队

强调个人（团队成员）通过团队合作可以加倍的能力。这是团队成功的关键因素

人员胜过过程，政策胜过人员

敏捷团队都是自组织的，并且具有多种团队结构

1. 自适应结构
2. 运用constantine提出的随机，开放和同步模式。
3. 重要的自主性

计划被保持到最低程度，仅仅接受商业要求和组织标准的限制

---

6.9 极限编程团队的价值

1. 交流
2. 简单
3. 反馈
4. 勇气
5. 尊重

---

6.10 社交媒体的影响

博客- 用来与团队成员和客户分享技术信息

微博（如twitter） 允许对关注他们的人员发布实时信息

Targeted on-line 论坛 - 允许参与者发布问题或者观点，并且得到答复。

社交网络：在以分享技术信息为目的的软件开发人员之间建立起联系。

网址收藏夹：允许开发人员追踪和共享网络资源

---

6.11 软件工程中云的应用

优势：

1. 提供获取各种软件工程工作产品的方法
2. 消除对于设备依赖的限制，并且在各处都能运行
3. 提供新的分配方法和软件测试
4. 对于所有团队成员来说，都能获得其中某个成员开发出的软件工程信息

缺点：

1. 分散的云服务在软件团队的控制范围之外，因此存在可靠性和安全性风险，
2. 随着云提供的服务越来越多，其在协同性上的风险也越来越高。
3. 云服务强调的可用性和性能，常常会与安全性，保密性和可靠性相互冲突。

---

6.12 协作工具

1. 命名空间 使项目团队可以用加强安全性和保密性的方法存储工作产品
2. 进度表 可以协调项目事件
3. 模板 可以使团队成员在创造工作产品时保持一致的外观和结构
4. 度量支撑可以量化每个成员的贡献
5. 交流分析会跟踪整个团队的交流，并分离出模式，应用于需要解决的问题或难题
6. 工件收集 显示出工作产品的依赖性

---

6.13 团队决策的复杂原因

1. 问题的复杂性
2. 与决策相关的不确定性和风险
3. 工作相关的决策会对另外的项目目标产生意外的影响
4. 对问题的不同看法导致不同的结论
5. 对于GSD团队，协调，合作和沟通方面的挑战对决策具有深远的影响。

---

6.14 影响软件开发全球化（GSD）的因素

---

6.9 极限编程团队的价值

1. 交流
2. 简单
3. 反馈
4. 勇气
5. 尊重

---

6.10 社交媒体的影响

博客- 用来与团队成员和客户分享技术信息

微博（如twitter） 允许对关注他们的人员发布实时信息

Targeted on-line 论坛 - 允许参与者发布问题或者观点，并且得到答复。

社交网络：在以分享技术信息为目的的软件开发人员之间建立起联系。

网址收藏夹：允许开发人员追踪和共享网络资源

---

6.11 软件工程中云的应用

优势：

1. 提供获取各种软件工程工作产品的方法
2. 消除对于设备依赖的限制，并且在各处都能运行
3. 提供新的分配方法和软件测试
4. 对于所有团队成员来说，都能获得其中某个成员开发出的软件工程信息

缺点：

1. 分散的云服务在软件团队的控制范围之外，因此存在可靠性和安全性风险，
2. 随着云提供的服务越来越多，其在协同性上的风险也越来越高。
3. 云服务强调的可用性和性能，常常会与安全性，保密性和可靠性相互冲突。

---

6.12 协作工具

1. 命名空间 使项目团队可以用加强安全性和保密性的方法存储工作产品
2. 进度表 可以协调项目事件
3. 模板 可以使团队成员在创造工作产品时保持一致的外观和结构
4. 度量支撑可以量化每个成员的贡献
5. 交流分析会跟踪整个团队的交流，并分离出模式，应用于需要解决的问题或难题
6. 工件收集 显示出工作产品的依赖性

---

6.13 团队决策的复杂原因

1. 问题的复杂性
2. 与决策相关的不确定性和风险
3. 工作相关的决策会对另外的项目目标产生意外的影响
4. 对问题的不同看法导致不同的结论
5. 对于GSD团队，协调，合作和沟通方面的挑战对决策具有深远的影响。

---