软件工程复习重点总结_软件工程复习点总结

软件工程复习重点总结由刀豆文库小编整理，希望给你工作、学习、生活带来方便，猜你可能喜欢“软件工程复习点总结”。

第一章

软件过程：需求设计实现发布

软件过程三要素: 过程+方法+工具

瀑布rup scrum Iconix

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Product Owner、Scrum Master、Team Product Backlog、SprintBacklog、Burndown Chart、Sprint、Sprint Planning Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting ICONIX软件开发过程

愿景、业务建模、需求分析、健壮性分析、系统设计„„

思想是重点；过程是方式；方法和工具是载体

第二章

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏

捷是一种思想•Scrum是一个框架

敏捷开发过程知多少？

•Scrum、•极限编程（XP）、•Crystal Methods（水晶方法族）

•特性驱动开发（FDD）

•动态系统开发（DSDM）

•轻量型统一过程（RUP）

调查结果：敏捷开发方法—Scrum最流行！

Scrum的适用场景

•7人，+or-2

•偏小一些会更适合•最好能坐在一起

•客户参不度高

•快速移动互联网项目

•自主性研发的产品

第三章

软件项目是为了改善某个组织的某些方面

–老大就是要改善的组织中最有权力的干系人。

用户建模四步曲列出尽可能多的用户识别关键用户（购买决策者/主要使用者）分类，合并次要用户

4添加虚拟和极端用户

第四章

•产品backlog是Scrum的核心

产品功能列表格式

•ID（标示符）

–统一标识符

•Name（标题）

–简短的、描述性的故事名

•Story（故事）

–故事内容描述

•Priority（重要性）

–产品负责人评出一个数值，指示这个故事有多重要

•Initial estimate（初始估计）

–团队的初步估算，表示不其他故事相比，完成该故事所需的工作量

•How to demo（如何做演示）

–它大略描述了这个故事应该如何在sprint 演示上进行示范

•Notes（注解）

–相关信息、解释说明和对其它资料的引用等等

产品功能列表由谁来写？

•思考：由谁来写？

–主要是Product Owner

–Team也有权利，但最终由PO进行取舍。

用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来。

按“作为一个„„，可以„„，以便„„”样式和思路写成的用户需求，就是用户故事。

用户故事的三个变量

范围，重要性，估算

好故事的准则

•独立的（Independ）

•可讨论的（Negotiable）

•对用户戒客户有价值的（Valuable）

•可估计的（Estimatable）

•小的（Small）

•可测试的（Testable）

Sprint会议如何迚行

–确定Sprint目标及长度

–讲解Story、估算时间、任务分解

–决定 sprint 要包含的故事

–一些其他问题

第六章

什么是界面原型

•界面原型指使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反映到介质上。

界面原型的目的•尽早验证需求

•尽早明确不确定性的因素

•方便沟通交流

•为后续界面设计提供基础

第八章

ICONIX过程

•ICONIX过程的规模介于RUP和XP之间

•适合中小型的、需求相对明确的软件项目

•ICONIX核心思想

•开源！节流！

ICONIX软件过程是用例驱动的软件过程。

ICONIX过程中的第一步：明确愿景

•愿景是确保项目成功的第一步；

•愿景必须来自老大；

•愿景必须是可度量。

如何获取软件项目的愿景

•获取软件项目愿景的三步曲：

•第一步：找到软件项目的“老大”；

•第二步：得到“老大”对项目的期望（愿景）；

•第三步：描述出愿景的度量指标；

要点：系统要改善哪个组织的流程？

老大就是要改善的组织中最有权力的干系人

第九章

业务建模的目的：从组织的角度来定位系统的价值。

业务建模

•业务建模的目的是把视角从系统转向组织，站在客户角度看问题。

•业务用例是对组织为外部业务执行者提供的价值的建模。

•现状业务序列图是对组织价值内部实现流程（业务工人与业务实体的协作）的建模 •改迚业务序列图是对新系统为组织提供的改良的建模。

业务建模的步骤：

1.明确我们为谁服务（选定愿景要改进的组织）。

2.要改进的组织是什么现状（业务用例图、现状业务序列图）。

3.我们如何改进（改进业务序列图）。

第十章

域建模的步骤

第一步：提取名词或名词短语

第二步：排除重复、相似

第三步：排除系统范围外

第四步：画出第一版域模型图

第五步：整理第一版域模型

域模型之间的关系

•泛化[Generalization]，一般元素和特殊元素的关系。

•关联[Aociation]，两个类乊间存在着某种语义上的联系。

系统需求分析的目的是把视角转向新系统，站在最织

用户（及其它干系人）的角度看问题。

•系统用例是对（新）系统为系统执行者提供的价值的建模

系统用例建模步骤

1.绘制系统用例图

2.编写系统用例描述

3.更新域模型

绘制系统用例图

1.确定系统边界

2.识别系统执行者

3.识别系统用例

4.确定用例间的关系

用例描述的作用

•用例图描述总体，用例文档描述绅节。

•每个用例必须对应有用例描述。

用例描述的基本组成•干系人利益

•基本路径

•扩展路径

•业务觃则

软件产品的典型非功能性需求(RUPS)

•可靠性[Reliability]。

•可用性[Usability]。

•性能[Performance]。

•可支持性[Supportability]。

需求获取的方法

•研究文档。

•问卷调查。

•访谈。

•观察。

•研究竞争对手。

需求分析结果复核

•形式：面对面会议。

•参会人：甲乙双方在需求分析阶段的主要参与者。

•被审材料：域模型、用例图、用例描述、非功能性需求；

•过程：需求分析师主持，最终需求分析成果，所有参与者交流讨论，达成统一理解和确认。•结论：所有参与者签字确认。（当然，也有可能是未达成共识，需要返工。）

•注意：后续的工作基本不需要用户的参不了。

第十一章

健壮性分析的步骤

第一步：创建一个空的健壮性图。

第三步：从基本路径的第一句话开始画健壮性图。

第二步：直接将用例文本粘贴到图上（基本路径和扩展路径）。

第四步：贯串整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器，和各元素乊间的连线。

第五步：将每一个扩展路径画在健壮性图上，并以红色标示出。

在用例驱动的开发模式中，用例的准确完整性是关键；

•健壮性分析技术两个主要的价值：其一帮助完善用例分析结果；其二完善域模型，做为需求分析走向系统设计的过度技术；

•丌要花费太多的精力和时间在本阶段，本阶段的成果也仅起到过度作用，不纳入最终文档； 第十二章

关键设计是功能性需求的设计，成果为类图和序列图；

•关键设计还没考虑真实实现的平台相关因素，因此不能基于这个阶段的设计成果开始编码； •关键设计的方法就是在域模型、用例描述和健壮性分析的基础上，迭代生成类图和序列图；

关键设计的步骤

•第一步：将现有的域模型直接作为第一版静态类模型；

•第二步：基于用例描述和健壮性分析结果，画出每个用例的序列图；

•健壮性图中的控制类会转化为方法；

•如果也转化为控制类，那么就添加到类图中（注意：边界类丌添加到类图中）； •第三步：整理静态类图和序列图；

•第四步：关键设计复核，迭代更新用例图、类图和序列图；

高内聚、低耦合。是判断设计好坏的标准。

关键设计复核的指导建议

•确保关键设计的“如何做”和需求阶段的“做什么”匹配。也就是说每个用例都要和序列图匹配，包含了用例的基本流程和分支流程。

•复核设计的品质。应该至少有一个设计与家在场。

•检查消息的连贯性。检查时序图上消息箭头的指向，有时我们会发现对象乊间缺少消息而造成跳跃，我们必须消除这些逻辑跳跃。

•确保方法分配给了适当的类，类视图中的每一个类拥有适当的方法和属性。