软件工程复习

#软件工程知识点总结
##第一章
软件工程学的存在价值：促进软件项目成功
1.软件危机定义※：软件在开发和维护过程中遇到的一系列严重问题。
2.软件危机包含两层含义：
如何开发软件。
如何维护数量不断膨胀的已有软件
3.软件危机的表现：
(1)软件开发的进度难以控制
(2)软件需求在开发初期不明确
(3)软件文档资料不完整、不合格
(4)软件的可维护性差
(5)软件价格昂贵
4.软件生存周期※：是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。
一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段
5.软件生存周期各个阶段主要任务：

• 计划阶段：确定总体目标和范围，研究可行性
• 分析阶段：分析用户需求，编写需求规格说明
• 设计阶段：决定软件怎么做，集中于软件体系结构、数据结构、用户界面和算法
• 实现阶段：编写程序代码
• 测试阶段：设计测试用例
• 运行和维护阶段：充分考虑软件的可维护性
  6.扩展ICONIX过程：
  愿景->业务建模->需求分析->健壮性分析->关键设计->最终设计->实现
  7.Scrum敏捷过程：
• 产品负责人建立条目化的产品待开发项，并进行优先级排序
• 在迭代计划会上，产品负责人讲解本迭代要开发的条目，估算下一个迭代
• 团队在迭代内完成所列需求，开每日“立”会
• 在迭代终点的迭代评审会上，团队展示开发成果

##第二章 -ICONIX

1.需求工程->需求开发、需求管理
2.※需求开发的方法：需求调查、需求分析（定义愿景、业务建模、用例分析）、需求定义
3.ICONIX过程特点※

• 尽早进入编码阶段，缩短分析设计周期的软件开发方法。
• 合理的简化统一过程(RUP)， 基于敏捷软件开发的思想。
• 与 RUP相比，是轻量级的过程。与敏捷相比，ICONIX提供充足的需求和设计文档，但不过度分析设计。
• ICONIX过程从把需求文档变成可运作的代码过程只需四步，使用四张UML图（用例图、序列图、类图、健壮性图）
  4.获取愿景的三步骤
• 找到软件项目的“老大”
• 得到“老大”对项目的期望
• 描述出愿景的度量指标

##第三章
1.※业务建模意义、三步骤
要求我们把视角从软件系统转向客户组织，站在客户角度看问题，以达到清晰准确地“诊断”，对症“开方”。
1. 明确我们为谁服务（选定愿景要改进的组织）。
2. 要改进的组织是什么现状（业务用例图、现状业务序列图）。
3. 我们如何改进（改进业务序列图）

2.学会组成部分（执行者、业 务用例）、会画图
3.序列图指向责任一方
4.改进业务序列图和现状业务序列图唯一判断标准就是里边有没有新系统（价值分别是暴露问题 和 新系统）

##第四章※ -需求分析
1、系统用例图的绘制，域模型的确立※（意义是什么：创建术语表；以图的方式可以清晰展示出不同术语间的关系；描述实体及其相互之间的关系；域模型图不断演变最终得到静态类图）
2、域建模的五个步骤※
1.仔细阅读需求文档，提取名词及名词短语
2.排除重复、相似的术语
3.排除超出系统范围或系统本身的术语
4.画出第一版域模型图
5.整理第一版域模型
3、系统用例建模的意义※：转换视角从业务组织转到新系统，站在最终用户及其它干系人角度看问题
4、业务用例和系统用例的区别 （区分：是否带斜杠，矩形框内是业务组织还是XX系统）
业务用例：业务执行者、业务工人、业务实体
系统用例：系统边界、系统用例、系统主执行者、系统辅执行者、用例关系、
5、用例之间的关系（不太重要）泛化、包含、扩展
6、怎么绘制系统用例图
7、系统用例的描述※（四个基本组成部分）

• 干系人利益

• 基本路径

• 扩展路径

• 业务规则

8、对RUPS的理解，某某系统想要提供不间断的服务体现了哪个性能（掌握这种程度）可靠性 可用性 性能 可支持性

##第五章 -健壮性分析
1.健壮性分析优点（了解）
• 用例的对象化图示，将用例和对象链接起来。
• 指出了参与用例场景的对象相互之间如何交互。
• 确保用例文本的正确性，从而提供了健康性检查。
• 确保用例考虑了所有必需的扩展路径，从而提供完整性和正确性检查。
• 让你能够(持续)发现对象。
• 缩小分析和设计的鸿沟，从而最终完成初步设计
2.三种元素以及他们之间的交互（只要不犯原则性错误就可 ）
- 边界类
- 实体类
- 控制器类
执行者只可以和边界对象对话 边界和和控制器 控制器和控制器 控制器和实体
3.健壮性图要会画！（基本路径和扩展路径）
##第六章 -关键设计
1.关键设计四个步骤※

• 将现有的域模型直接作为第一版静态类模型
• 基于用例描述和健壮性分析结果，画出每个用例的序列图
  健壮性图中的控制类会转化为方法
  如果也转化为控制类，那么就添加到类图中（一般边界类不添加到类图中）
• 整理静态类图和序列图
• 关键设计复核，迭代更新用例图、类图和序列图

2.画系统用例的序列图，重点是对控制器类的转换
3.复核不需要甲方的人参加！！！！！（从设计阶段开始，已经不需要甲方的人参加了）

##第七章 -详细设计
1.第一小节类似RUPS 可靠 可用 可支持 性能
2.详细设计的目标（任务）是什么
主要是通过需求分析的结果，设计出满足用户需求的软件系统产品 。
3.技术架构及相关考虑※

• 选择开发语言
• 网络拓扑及安全
• 体系结构
• 硬件支持环境
• 软件支持环境

##第八章 -敏捷开发
1.敏捷宣言的内容
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：
- 个体和交互 胜过 过程和工具
- 可以工作的软件 胜过 面面俱到的文档
- 客户合作 胜过 合同谈判
- 响应变化 胜过 遵循计划
虽然右项也具有价值，但我们认为左项具有更大的价值
2.对敏捷的误解（理解）

• 敏捷开发意味着可以不需要文档、设计和计划
• 敏捷只是一些优秀实践，或者是优秀实践的结合
• 敏捷只适用于小项目开发
• 敏捷只会对研发产生改变
• 管理者不需要亲自了解敏捷，只需要管理上支持就可以了
• 引入敏捷只需要按照既定的步骤去做就可以了
• 敏捷是CMM的替代品，是另一种流程
• 敏捷只注重特性的快速交付，在敏捷下架构不重要了
  3.敏捷开发三个层次：理念、优秀实践、具体应用

##第九章
1.Scrum的概念：Scrum是一个增量的、迭代的敏捷开发过程
2.迭代式开发的好处（用自己的话描述）
在早期迭代中实现有高技术风险的需求，有助于尽早暴露问题和消除风险
通过功能渐增的产品，持续获得顾客反馈，及时调整，最终产品更符合客户需要
小批量减少排队，能更灵活、快速的交付
平滑人力资源的使用，避免出现瓶颈
3.Scrum的流程（开发过程，用自己话描述），一些专有名词

• 项目整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个Sprint，每个Sprint的建议长度2到6周。
• 使用产品Backlog来管理项目的需求，产品Backlog是一个按照商业价值排序的需求列表，体现形式通常为用户故事（UserStory）。
• 团队从产品Backlog中挑选最有商业价值的需求，经过Sprint计划会议上的分析、讨论和估算得到任务列表，称为Sprint Backlog。
• 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量

4.核心角色就三个（掌握定义及职责）

• PO（Product Owner 产品负责人）
  定义：确保Team做正确的事
  职责：代表利益相关人、确定产品发布计划、定义产品需求和优先级、验收迭代结果
• Scrum Master(Scrum教练)
  定义：确保Team正确地做事
  职责：辅导团队正确应用敏捷开发、引导团队建立并遵守规则、保护团队不受打扰、推动解决遇到的障碍、激励团队
• Team(开发团队)
  定义：负责产品需求实现
  职责：找出最佳方案完成任务、演示工作成果、团队自我管理和改进

##第十章
1.敏捷工作件（列举几个敏捷工作件 并加以说明）最重要的是PB（由PO确定的，并且由他维护）
1.Sprint Goal 迭代的目标（冲刺目标）由PO确定，但同时要被整个团队接收
2.SB （重要），PBI的分解 由team拥有，在计划会上形成的
3.Blocks list 用的少 由敏捷教练负责写这个 ，遇到一些阻碍写这个 （基本没用）
4.increment 增量
5.任务看板
6.燃尽图：监控目标实现的进度
2.敏捷的四种会议（名字大概）
迭代计划会：充分参与、相互承诺、确定内部任务
每日站立会议：准时开始、高效会议、问题跟踪
迭代评审会议：展示“真实”的产品、收集反馈
迭代回顾会议：会议气氛、关注重点、会议结论要跟踪闭环
3.工程实践的技术：
1.用户故事：作为一个XXX客用，我需要XXX功能，能够带来XXX好处
2.结对编程
3.测试驱动开发（TDD）
4.持续集成（CI）
5.code review 理解好处
代码复查者(reviewer)能从他们的角度来发现问题并且提出更好的解决方案。
确保至少团队的另一个其他成员熟悉你的代码
能够鼓励开发者将工作进行的更彻底，因为他们知道代码将被其他的人阅读
公开reviewer和被复查者的想法和经验能够促进团队间的知识的分享
6.发布规则
##最后
1.XP（极限编程）的特点
简单、快速、低缺陷率、适应需求变化
2.XP（极限编程）价值观
沟通、反馈、勇气、尊重、简单