软件工程知识总结

时间：2024.4.21

一、关于软件工程

1.软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件学科。软件工程 = 技术+管理

2.软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一些列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

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

软件工程是目标，软件过程是步骤，方法和工具是辅助。

3.软件过程常用模型：瀑布模型、RUP、Scrum敏捷开发、ICONIX

4.瀑布模型：

优点：为项目提供了按阶段划分的检查点；当前一阶段完成后，只需关注后续阶段。缺点：各个阶段之间极少反馈；只有在项目生命周期的后期才能看到结果；通过过多的强制完成日期和里程碑来跟踪各个项目阶段；不适应用户需求变化

软件工程知识总结

二、敏捷开发

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

2.敏捷开发特点：适应性（非预设性）、面向人（非面向过程） “以人为核心”

3.敏捷宣言：

个人和互动高于流程和工具

工作软件高于理解文档

客户协作高于合同协商

变化响应高于计划遵循

4.Scrum活动：Sprint计划会议、每日例会、Sprint评审会议、Sprint回顾会议

三、项目提出阶段

项目的背景：

a. 找到项目的主要服务对象

客户：系统的购买者

用户：系统的使用者

b. 项目的目标－愿景:所向往的前景

愿景可以激励潜能，指导方向。

如何找到软件项目的愿景：

找到老大；找到老大购买系统的目的。老大就是要改善的组织中最有权力的干系人。来自于客户。

三部曲：

1.找软件项目的老大

2.得到老大对项目的期望（愿景）

3.描述出愿景的度量指标

c. 项目的商业价值

（通俗讲：商业模式是项目通过什么途径或方式来赚钱。）解决别人愿意花钱解决

的问题，就是商业价值。

d. 项目的服务对象细分－用户建模

用户建模原因：

*良好的用户建模，可以保证不同用户都能方便地访问其功能，使用产品后也更容易获得其特定的价值；

*找到哪些用户可能来使用产品或访问网站

*他们为解决哪些问题而来，为达到哪些目的而来

注意角色权限合理：不可过大或过小

头脑风暴：

PO（project owner）主持，借助团队进行，必须有必要的记录人员

用户建模四步：

1.列出尽可能多的用户；

2.识别关键用户（购买决策者、主要使用者）；

3. 分类、合并次要用户；

4.添加虚拟和极端用户。

虚拟用户：假想的用户角色的代表。（找一个人去代表一类人）

极端用户：很可能让你编写出原本可能遗漏的故事。

书友网：

--------------------------------------------------------------------------------------------------------------------------------- 借书者、图书拥有者、借书提供者、管理者、浏览者过客、寻觅知音者、没有书的人、有书比较多的人、监视者

关键用户：借书者和提供者

分类、合并：

借书者

自己没书去借书的人、自己有书有需要借书的人。

提供者

自己有书有需要借书的人、不需要借书只提供给别人书的人。

既不借书也不提供书

浏览者、寻觅书友知音的人

管理者

开发维护人员、平台信息管理人员

虚拟和极端用户：

虚拟用户：

1. 张三，软件学院学生，拥有软件工程专业图书10本，暂时自己没有阅读。资金

匮乏，希望能借到一些文学类的图籍。

2. 李四，大学教授，知识渊博，愿意同他人分享图书，拥有文学历史类图书若干，

想寻找一起读书的书友，共同交流心得。

极端用户

四、产品定义：编写产品功能列表

1.什么是产品功能列表：

产品backlog（代办事务）是Scrum的核心，是一切的起源

一个需求或特性组成的列表

按照重要性的级别进行了排序

包含客户想要的东西

用客户的术语加以描述（非专业性术语）

2.需求说明书：功能需求、性能需求（非功能性）等（有时候还包含不能实现的功能）。写成用户故事形式。

来自客户或者PO（对于自主研发的）。

3.产品功能列表：ID标示符、Name标题、Story故事、Priority重要初始估计等主要是PO编写、Team也有权利，最终由PO取舍

4. 用户故事和需求说明书的区别：用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来，是一种需求探索的方式。需求说明书是一个阶段的内容展示。三要素：角色（来源于用户建模）、功能、客户价值

寻找客户价值的关键点：寻找可卖点。

5.用户故事也是用来被卖掉的东西，看不到价值的就不是用户故事。避免技术性故事（避免专业性术语，尽量用业务性语言，让客户通俗易懂）作为一个…，可以…，以便…。

6.好故事的准则：

独立的；可讨论的；对用户或客户有价值；可估计的；小的；可测试的。

7.导致不可估计的3个原因：

缺少领域知识

缺少技术知识

故事太大了（史诗故事：复合故事（多个小故事组成）、复杂故事（本身不容易分解））故事（见PPT）：

用户能快速掌握系统：坏故事（不可测试）

用户可以修改简历上的地址：坏故事（不可估算）

用户可以增加、修改、删除多份简历：坏故事（史诗故事）

系统可以计算n元二次方程式分布的鞍点近似值：坏故事（没有注解，不满足可讨论性）运行时错误都用同样的方法记录：好故事

五、产品规划与设计的工作

1.产品规划和设计中最重要：迭代计划会、界面设计、数据库设计、系统设计

2.Scrum发布周期:每次迭代发布（移动互联网项目、自主性研发产品）

多次迭代发布（传统项目、大型项目）

3.产品规划通过什么形式进行：Sprint计划会议

4.Sprint会议之前工作：确保产品backlog的井然有序、团队成员和负责人、重要性评分

5.提取产品功能由产品功能列表中到迭代中的三个要素：迭代的周期时间、团队战斗力、计

算生产率

6.迭代计划会参与人员：Team、PO、Master；主持：PO

7.用户故事决定质量的三个变量：范围、重要性、估算

范围和重要性（PO决定），估算（团队决定）

将产品功能放到迭代中（PO决定）

8.产品质量：外部质量（系统用户可以感知）、内部质量（用户看不到的要素，对系统的可维护性有深远影响）

9.一般Sprint周期长度：推荐3个星期（15个工作日）

10.故事估算单位：故事点（理想化的人-天）

11.任务和故事区别：故事：可以交付的东西；任务：不可交付的东西

12.故事估算工具：计划纸牌；任务分解：使用故事索引卡

13.在Sprint中包含多少故事由团队决定（注意不是PO）

13.团队怎样决定把哪些故事放到 sprint 里面？

使用技术：本能反应（根据经验估算）、昨日天气（团队的历史）、生产率计算

14.怎样计算生产率：（上次人工、时间、投入故事点）

参考实际生产率：参考上一次迭代情况

得出投入程度

得出估算生产率

15.PO和Team要对“完成”有一致的定义

六、界面原型设计

1.产品设计：界面原型设计、界面设计、数据库设计、系统设计

2.Scrum开发：设计、编码、测试同时执行会导致bug粒度增大。

3.界面原型：使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反应到介质上。（让客户最早看到了软件的样子，以便提出更准确的需求）将需求转化为可视画面以及人与系统的交互。如果需求非常明确，界面原型设计可以去掉

4.画界面原型的工具：白纸铅笔、MS Office办公套件、Viso、PhotoShop、Axure

七、ICONIX过程

1.不适用与Scrum过程的场景：

团队规模相对比较大、项目规模相对比较大、客户参与度不高

2.ICONIX过程适合中小型开发

3.ICONIX过程核心思想：开源，节流

4.利润 = 需求-设计.

5.OOAD面向对象的分析和设计

6.ICONIX中的工具和方法：UML（统一建模语言）用例图、序列图、类图

7.确认愿景：所向往的前景。找老大

三部曲：

1.找软件项目的老大

2.得到老大对项目的期望（愿景）

3.描述出愿景的度量指标

8.软件项目愿景的价值：

回答“为什么开发这个系统”的问题

9.愿景必须指出度量指标。不是做具体的事，是改善组织的指标。

10.愿景的度量指标主要关注：价值 = 收入-支出。增加收入、节约支出

11.愿景写法：名称、老大、度量指标

八、业务建模

1、业务建模的目的：从组织的角度来定位系统的价值。（了解组织现状，在此基础上才能改善组织）

2、业务建模 = 组织建模

3、大量软件项目失败的根源：最终实现与用户需求不一致（语言文字的二义性，需求把握不准）

解决：用更科学的方法代替语言沟通。例如：UML

4、业务建模意义：

业务建模要求你我们把视角从系统转向组织，站在客户角度看问题，以清晰准确地“知彼”。

5、业务建模步骤：

（1）明确为谁服务（客户）。

（2）要改进组织是什么现状—有什么痛处和不足

（3）如何改进：新系统的价值就是解决客户痛处,改良客户不足，这是客户出钱的动力

6、业务建模就是把系统放在组织中来看

7、第一步：选定组织

选定的业务组织跟老大的职权范围有关。

结合系统愿景。

研究的组织是该网站的目标人群

九、了解组织现状

1.从外部看：组织是价值的集合，用业务用例图来建模。

2.从内部看：组织是系统的集合（人是一种智能系统），用业务序列图来建模

3.业务用例图帮助我们从高层次了解组织的业务构成。

4.业务执行者：组织之外，与其交互，享受其价值的人或组织。

（图形小人头）有斜线：业务用例；无斜线：系统用例

例如：银行业务执行者是去银行存取钱的人；餐馆的业务执行者是吃饭的顾客。（注意和系统执行者区分）

5.业务用例代表组织的本质价值，很难变化，改变的是业务用例的实现。

6.业务组织之内的是业务实体。

7.识别业务用例：两条路线：

从业务执行者开始；观察组织的内部活动

8.业务用例格式：业务执行者通过业务组织的某些工作，达到固定目的

撰写业务用例简述是非必须工作。适用于对陌生业务分析时，起到辅助记录和协助沟通的作用。

业务用例描述

招聘招聘公司在上班时间到xxx市人才交流中心，由工作人员协助完成招聘工作求职求职者在。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。完成求职工作

十、业务序列图

1.序列图以面向对象的思想来看业务流程（体现细节，表现责任和协作）

2.业务序列图详细描述业务执行者、业务工人、业务实体之间的交互，以完成某个业务用例的流程。组成部分：业务执行者、业务工人、业务实体、调用实体、业务消息、

3、业务工人：组织内部，负责流程中的某些工作人员。

4、业务实体：业务工人使用的“系统”（软硬件）；例如银行的数钞机、学校的校园卡系统。可以喝业务工人相互取代各自的职责。

5、业务工人、业务实体、业务执行者统称业务对象

6.业务序列图

消息指向是委托，不是数据流动；箭头后面的是工作者

只画领域相关的系统

最小单位是人或独立智能系统

把时间看做特殊的业务实体（闹钟自触发）

7.改进点：

信息自动流转；

封装复杂业务逻辑

职责转移

访问和操作业务对象

。。。。。。

十一、改进序列图

1、业务序列图的好处：提前模拟新系统的出现；提前评估新系统的可行性或提前进行准备工作，实现安全平稳的组织改进。

2、如何获取业务建模信息：

选定组织：老大和他的愿景

组织业务现状：业务专家的介绍

组织业务的改进：老大痛处和愿景；业务专家的抱怨；需求分析师的经验和智慧

3、业务建模结果复核目的

完善业务建模结果，寻找遗漏和错误点并修正如果问题明显则迭代回去做业务建模工作。关键干系人在信息和意见达成一致，并共同签字确认，作为下一阶段启动的标志。

4、业务建模结果复核方法：

形式、参会人、被审材料、过程、结论（所有参与者签字确认）、注意（后续工作老大不参与）

5、业务建模可以精简

6、度量指标：有度量性；关键字：提高、减少、增加、提供。。。

针对现状，不能混合将来的用例

十二、需求分析

1.需求分析目标：功能性需求（功能列表）和非功能性需求。需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。研究软件做什么。软件设计：软件怎么做。

包括：目的、术语表定义（由域建模定义）、范围和功能、其它定义

需求分析阶段要做的工作：域建模和系统用例建模

2.域建模：为项目创建一个术语表。确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域。使用工具：类图。域建模中不能有业务执行者（系统外的）。

意义（优良性）：图示化方式，清晰的表现出不同术语间的关系。

将通过不断修正完善逐步演化为最终的静态类图。

3.域建模步骤：

3.1仔细阅读需求文档，提取出名词和名词短语。

3.2排除列表中重复、相似的术语

3.3排除超出系统范围的术语

3.4画出第一版域模型图

3.5整理第一版域模型图，确定域模型之间关系：泛化关系（一般和特殊关系，类似于继承，空心箭头指向父亲）、关联关系（两个类之间存在着某种语义上的联系）

补充：

其它关系还有聚合关系（整体和部分，但是不是很强依赖，随时可以被替换）、组合关系（整体和部分，包含，强组合，部分不能去掉）、依赖关系（xxx用yyy做）

4.域建模重要原则

不要花费太多时间几个小时讨论即可

域模型 ≠ 数据模型

在用例分析之前进行

不要指望和最终类图完全匹配

踢出和见面相关的类

5.系统用例建模的意义（得到功能性需求）

系统需求分析的目的是把视角转向新系统，站在最终用户的角度看问题

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

系统用例建模和业务用例建模的区别：业务建模是站在客户角度分析组织价值；系统用例建模是站在用户角度分析系统价值

6.系统用例图：系统主执行者（主动调用用例的）、辅助执行者、系统用例、系统边界、用例关系。

主执行者和辅助执行者区别：主执行者享受服务；辅助执行者辅助系统完成价值，提供服务。（在改进的系统用例图上对业务工人和关系等画个圈，调用的是主执行者，被调用的是辅助执行者）

两种常见用例关系：

包含关系（若干个都有的用例提取出来之后，别的用例包含这个用例，虚线箭头指向被包含的（小的））

扩展关系（A用例执行之后，B用例再执行，则B是A的一个扩展用例，b不

一定执行。虚线箭头指向A）

7.系统用例建模步骤：

7.1绘制系统用例图：

确定系统边界》识别系统执行者》识别系统用例》确定用例间的关系

7.2编写系统用例描述（文字）

7.3更新域模型

十三、系统用例建模

1.系统边界：边界内的建设，边界外

2.系统执行者：系统之外，透过系统边界，与系统进行交互的任何事物，享受系统价值

3.系统用例：软件对外提供的价值。系统执行的一些列动作，这些动作生成执行者可观测的有价值的结果。站在系统执行者的角度，执行者通过系统达到某个目标。

在业务序列图中找到业务工人，指向业务工人（系统）的都是一个系统用例。 4.确定用例间的关系：泛化、包含、扩展。思想：重用

南海岸航海用品电子商务网

我们公司南海岸航海用品，30年以来一直用产品目录销售航海用品。我们的产品主要包括全球定位系统、钟、气象设备、导航及绘图设备、救生衣、地图和书。到目前为止，我们的网站仅有一个简单的网页，老板决定要与时俱进，开始在网上卖东西。但是不希望一开始就卖大件物品，而是先从卖书开始。因为有些物品价值超过1000美金，除非我们认为网站一切正常并且不会丢单，否则我们不愿意在这些贵重物品上冒任何风险。但如果我们发现客户喜欢在网上下单，而且网站做的不错，我们也会考虑在网上卖其他产品。

老板还说网站要在30天内上线，这样就有望在夏天提高销量。

十四、

1.系统建模时，先确定系统执行者，再确定系统用例

2.系统执行者必须与系统直接交互

3.时间也能是执行者。用“时间”执行者来标示预定的事件（定时任务）

4.用例名称必须是动宾短语。使用强动词和强名词（提交退货申请单），慎用弱动词和弱名词（提交退货）。

5.用例≠功能。用例是指实现价值。描述一个事物的三个出发点：结构、功能、价值

6.用例≠步骤。用例是执行者对系统的一个愿望。

7.从使用者的角度命名（例如数据表增加操作，则命名为：注册新用户）

8.所有用例都应能追溯到愿景目标，所有愿景目标都应有对应的用例实现，

9.大量用例应该进行用例分包。（分类方式：按执行者、按主题、按开发团队、按发布情况）

10.系统用例描述总体。每个用例必须有对应的用例描述。

11.用例描述的基本组成：

干系人利益（用户和客户都是）、

基本路径（凸显核心价值：请求、验证、改变、回应）；

格式：名词-动词-名词、

扩展路径（分支和意外）、

方法：从基本路径开头开始找分支和可能性；

书写要写清从哪个基本路径扩展而来；一句话说清

常见扩展点：系统验证失败、步骤失败、执行者的不同选择

注意：

描述不要涉及页面细节，要抽象和归纳

不要假想系统不能负责的事情

业务规则

12.用例是干系人利益的平衡点。

13.辅助执行者：系统请求xxx做某事

14.前置条件：开始用例前系统及其环境的状态。

形式：必须是系统能检测到

内容：不会伤害涉众（和系统相干的人和事）的利益。

15.后置条件：用例成功结束后系统应该具备的状态。

16.补充约束：字段列表。

使用自然语言（容易产生语言二义性）或者表达式（更严谨和科学）；简单描述

17.非功能性需求：系统可以把某项功能做到什么程度（人有我优）；功能性需求：系统可以做什么（人无我有）。

四项指标（RUPS）：

可靠性(系统在一定时间内、在一定条件下无故障地执行指定功能的能力)、

可用性(一个产品可以被特定的用户在特定的上下文中，有效、高效并且满意得达成特定目标的程度。

)

性能(系统实现预期功能的能力的特性)、

可支持性(系统在故障解决和系统升级方面的能力)

十五、

1.需求获取的方法：

研究文档

问卷调查（针对大规模人群）

访谈（纸笔记录）

观察（亲身体验）

研究竞争对手

2.需求分析结果复核

? 形式：面对面会议。

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

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

? 过程：需求分析师主持，介绍需求分析成果，所有参与者交流讨论，达成统一理解

和确认。

? 结论：所有参与者签字确认。（当然，也有可能是未达成共识，需要返工。） ? 注意：后续的工作基本不需要用户的参与了。

十六、健壮性分析

1.健壮性分析：验证步骤，可以省略。验证需求分析的成果是否正确。不纳入最终文档

用例分析强调站在用户角度看问题，而设计强调的是站在技术人员角度看问题，应该提供过度方式来衔接两种角度的转换。前提：用例及用例描述正确；域模型正确（优点：完成验证；过渡设计）

2、基本概念：边界类（名词）、实体类（名词）、控制器类（动词）

3.交互规则：执行者只可以和边界类通话；

边界类《=》控制器；

控制器《=》控制器；

控制器《=》实体类

4.EA健壮性分析图：（实体和线条都可以选中在下方工具栏修改颜色）

文字描述前加上数字前缀，表明顺序

文字描述：名词-动词-名词

5.健壮性分析后期：更新域模型

目的：验证需求、概要设计、更新域模型

6.健壮性分析可以不做：有丰富的类似项目经验；熟悉业务细节

十七、

1.关键设计解决的是功能性需求如何实现

2.三种设计：

UI设计：Axure

功能逻辑设计(业务逻辑)：文字描述、伪码、UML时序图、程序流程图

数据库设计：PowerDesigner

3.两种驱动模式：实体驱动（事件驱动）、责任驱动

4.面向对象思想：定义类、使用类

5.关键设计的方法：基于用例图、用例描述和健壮性图，采用序列图来描述参与者、边界、实体之间的交互

6.面向对象概念总结

对象与类，抽象（有选择地提取）

封装（隐藏复杂的细节，仅透露足以进行交互的底限信息）、继承、多肽

类之间的关系：

泛化（继承）、

关联、聚合、组合

依赖

静态关系：关联、聚合、组合。对象存活期间，与其对象之间的链接也会存在，因此这些链接可以跨操作使用

动态关系：对象存活于操作执行期间，无法跨操作使用。

类图组成：类和关系

类：名字、属性、方法

十八、关键设计

1.在序列图中箭头所指表示责任（执行）

箭头指出去表示调用

2.关键设计步骤：

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

基于用例描述和健壮性分析结果，画出每个用例的序列图

整理静态类图和序列图

关键设计复核，迭代更新类图（添加方法和类）

3.如何决定控制器分配给那个类：高内聚、低耦合原则（判断设计好坏的标准）

4.注意事项：

控制器的高内聚、低耦合原则

序列图中的分支、判断、循环、添加必要的引用

整理类图，添加方法，进一步确定类关系

不要将序列图画成流程图

5.关键设计复核方法：

形式：面对面会议

被审材料：用例图、用例描述、类图、序列图

过程：交流讨论、达成统一理解和确认

结论：所有参与者签字确认

注意：不需要甲方人员参加（技术性复核对话）

6.关键设计的使用价值：跨平台、外包

期末复习

软件工程

1.软件工程三要素：过程（之上是思想）、方法（面向对象）、工具（各种语言）

2.理解软件职业规划职业发展图

3.软件工程概念（以工程化的思想来进行软件开发的一门学科）。

工程化思想实施过程：研究、开发、设计、施工、生产、操作、管理

4.软件工程另外一种分类：技术、管理

5.软件过程概念：（完成一个事情需要完成的步骤，这个步骤是预先制定好的，科学有效的）常见的软件过程：瀑布过程、Scrum、ICONIX

软件生命周期：问题提出、可行性研究、需求分析、软件设计、软件开发、软件测试、软件维护（时间最长、资金最多）。

6.软件工程是目标，软件过程是步骤，方法和工具是辅助

Scrum过程

角色：PO、SM（鸡）、Team（猪）、用户

Scrum过程是一种迭代式增量软件开发过程，通常用于敏捷软件开发。