软件工程知识点总结

最新推荐文章于 2024-04-25 13:48:59 发布
最新推荐文章于 2024-04-25 13:48:59 发布
阅读量5k 收藏 16
点赞数 4
文章标签： 团队开发 敏捷流程 极限编程 scrum
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_45999014/article/details/121362043
版权

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团队，协调，合作和沟通方面的挑战对决策具有深远的影响。
.pppppeanut
关注
  • 4
    点赞
  • 踩
  • 16
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
软件工程黑书考研一轮复习笔记.docx
06-23
软件工程黑书全书知识点详细汇总 考纲目录 第一章 基本概念 2 1、软件的概念和特点 2 2、软件危机的概念和产生的原因 3 3、软件工程的定义、三要素和发展过程 （重点，考过多次问答题） 4 第二章 过程模型 4 1、软件生命周期概念、软件过程概念、能力成熟度模型 CMM 概念 4 2、常见的软件过程模型：瀑布、增量、原型、螺旋、喷泉等，比较各自优缺点 5 1、瀑布模型(经典生命周期模型) 6 2、增量过程模型(增量模型+RAD模型) 6 3、演化过程模型（原型模型+螺旋模型） 7 4、喷泉模型（Water Fountain Model） 9 5、基于构件的模型（Component-baseed Development Model） 10 6、敏捷开发过程（Agile Development） 10 第三章 需求分析 11 1、需求分析的概念 12 2、需求分析的过程：需求确认与需求变更 12 3、需求确认的步骤：需求获取→需求提炼→需求描述→需求验证 13 4、需求分析三类建模：功能模型、数据模型、行为模型。面向过程 和面向对象的需分析过程中，三类模型各包含哪些内容？--------------- 15 5、 掌握数据流图和用例图作法。 31 第四章系统设计 32 1、系统设计分为概要设计和详细设计 32 2、设计相关的8个概念（抽象、体系结构、设计模式、模块化、信息隐藏、功能独立、细化、重构），着重考察体系结构、模块化、信息隐藏、功能独立。 33 3、系统设计从数据、体系结构、接口和组件四方面进行设计。面向过程和面向对象的系统设计，各自包含哪些设计内容？ 37 4、掌握流程图和顺序图作法 43 第五章 质量保证 48 1、质量保证的概念 48 2、测试策略 V 模型概念，测试与开发的各阶段对应关系。 48 3、单元测试的内容、集成测试的分类、系统测试的分类、验收测试的分类。 48 4、回归测试的概念 48 5、测试技术常见术语的概念：软件缺陷、验证和确认、测试与质量保证、质量与可靠性、调 试与测试、测试用例 48 6、白盒测试、黑盒测试、静态分析各有哪些方法？ 48 7、掌握逻辑覆盖与等价类划分测试方法。 48 第六章 软件维护 49 1、软件维护的基本概念 49 2、理解软件维护的四个基本类型：纠错性、适应性、完善性、预防性维护。哪种占比重最大？ 哪种最小？ 49 3、可维护性的决定因素 49 4、软件维护过程模型、软件再工程、逆向工程的概念 49 第七章 项目管理 49 1、项目管理四要素：人员、产品、项目、过程（概念） 49 2、软件度量有哪些方法：生产率估计（基于规模（KLOC）、基于功能点（FP））、工作量度 量（算法成本模型、COCOMO 模型）。掌握直接测量（基于规模）方法。 49 3、项目计划与风险管理的概念 49
软件工程知识点汇总
技术宇宙
12-08 7041
目录前言软件生存周期与软件过程软件生存周期传统的软件过程瀑布模型特点存在的问题快速原型模型原型开发的优越性原型模型的启示 前言 参考教程：《软件工程——原理、方法与应用》（第3版） 软件生存周期与软件过程 软件生存周期 典型的软件生存周期： 需求分析 → 软件分析 → 软件设计 → 编码（测试）→ 软件测试 →运行维护 传统的软件过程 瀑布模型 特点 线性开发模型 顺序性 依赖性 存在的问题 只有当分析员能够做出准确的需求分析时，才能得到预期的结果，但往往难以实现。 快速原型模型 原型开发的优越性
11、软件工程基知识
qq_44774198的博客
10-07 3820
软件工程是软件开发的指导思想，方法体系，所以这属于软件设计师需要掌握的核心内容。（1）软件工程知识：软件生存周期与软件生存周期模型、软件开发方法、软件开发项目管理、软件开发工具与软件开发环境。（2）系统分析基础知识：系统分析的主要步骤、机构化分析方法。（3）系统设计基础知识：概要设计与详细设计的基本任务、系统设计的基本原理、系统模块结构设计、结构化设计方法、面向数据结构的设计方法、系统详细设计。（4）系统实施基础知识：系统实施的基本内容、程序设计方法、程序设计的基本模块、系统测试、系统转换。
软件工程基础知识点汇总
weixin_46486131的博客
09-19 6084
第四章 软件工程基础4.1 软件工程基本概念4.1.1 软件定义与软件特点4.1.2 软件危机与软件工程4.1.3 软件过程与生命周期1.软件过程2. 软件开发生命周期（softeware life circle）4.1.4 软件工程的目标与原则1.软件工程的目标2.软件工程的原则4.1.5 软件开发工具与软件开发环境1.软件开发工具2.软件开发环境4.2 结构化分析方法4.2.1 需求分析与需求分析方法1.需求分析2.需求分析方法4.2.2 结构化分析方法1.关于结构化分析方法2.结构化分析的常用工具4.
大学软件工程总结
runfeel
07-09 4748
大学软件工程总结 2013年7月9日软件工程复习总结 前言 软件工程在我整个大学的课程里是选修课，学的是电子工业出版社的《软件工厂--方法与实践 第2版》 软件工程呢，我觉得是一门很需要实践的学科，光靠这样简单地靠老师讲或者看看书是学不到什么东西的。软件工程涉及到很多内容，其中软件项目管理也包括了。概念性东西很多，一些专业术语和名词在整个软件工程中也频繁地出现了。其中近些年比较火的...
软件工程知识点总结.doc
11-23
软件工程知识点总结.doc
2023年软件工程知识点总结.doc
10-26
2023年软件工程知识点总结.doc
02333-软件工程知识点总结
11-26
自考资料-软件工程知识点总结
西电李航软件工程知识点总结
07-12
西电软件工程专业操作系统知识点
大学期末复习软件工程知识点总结.docx
04-30
3. 软件工程原则： (1) 选取适宜的开发风范 (2) 采用合适的设计方法 (3) 提供高质量的工程支持 (4) 有效的软件工程管理 4. 软件工程： (1) NATO会议中的定义：指建立和使用一套合理的工作原则，以便获得经济的软件，...
软件工程基础知识点总结.doc
12-03
软件工程基础知识点总结.doc
软件工程知识点总结第一章至第九章
05-09
该资源以思维导图的形式总结软件工程第一章至第九章的知识点，该总结不仅包含课本知识也包含了一些练习题中知识点的补充。 章节目录： 第一章 软件工程 第二章 软件过程 第三章 项目可行性研究 第四章 软件需求分析...
软件工程知识点总结.pdf
10-01
软件工程知识点总结.pdf
1软件工程知识点总结.doc
07-02
第一章 1.... 软件工程是研究软件生产的一门学科。它采用工程的概念、原理、技术和方法来开发和 维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结 合起来，以达到经济
(精品word)软件工程知识点总结(良心出品必属精品).doc
11-24
(精品word)软件工程知识点总结(良心出品必属精品).doc
自考软件工程知识点总结PPT学习教案.pptx
10-05
自考软件工程知识点总结PPT学习教案.pptx
不定期会议对团队开发的影响（项目管理篇）
最新发布
qq_35374791的博客
04-25 250
不定期会议，即没有固定周期或事先规划的临时召集的会议，对于团队开发可能产生多种影响，既有积极的一面，也有潜在的挑战。以下是具体分析：
dsp软件工程师面试
09-14
DSP软件工程师面试主要包括技术知识的考察和项目经验的评估。在面试中，面试官通常会提问以下内容： 1. 个人介绍：面试官会要求你对自己进行简要的介绍，包括项目经验、使用的单片机型号、使用的编译软件等。 2. 单片机使用经验：面试官可能会询问你对单片机的使用经验，包括所用单片机的主频、位通讯协议等。 3. ARM结构和Linux使用经验：面试官可能会询问你是否接触过ARM结构和Linux，并询问你的使用经验。 4. 实时系统的使用经验：面试官可能会询问你是否使用过实时系统，并对你的经验进行评估。 5. PLC项目和编程方式：面试官可能会询问你在PLC项目方面的经验和使用的编程方式。 6. DSP的使用经验：面试官可能会询问你是否使用过DSP，并对你的经验进行评估。 除了以上技术方面的问题，面试官还可能询问你是否获得过相关奖项和参加过竞赛，以及你对Python和C相比的优点和电力电子技术的了解程度等。 在面试过程中，面试官可能会提供一些相关的共鸣点，以加强与你的交流。此外，他们也会向你介绍公司行业和目前的发展方向。 面试感受和总结是你对整个面试过程的总结和反思，你可以在这部分提到你的感受和对自己表现的评价。 总之，DSP软件工程师面试主要关注你的技术知识和项目经验，同时也会考察你的个人能力和适应能力。准备充分，回答问题清晰明了，展示出你的技能和潜力，将有助于你在面试中取得好的结果。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值