软件工程知识点

1.软件工程学的存在价值：促进软件项目成功

2.软件工程三要素：工具，方法，开发过程

3.瀑布模型：需求分析–>需求定义–>概要定义–>详细设计–>实现–>系统测试–>验收测试–>维护

4.RUP的中心思想是：用例驱动，架构为中心，迭代和增量

5.RUP工作流程：
1）业务建模
2）需求
3）分析设计
4）实施
5）测试
6）部署
7）配置于变更管理
8）项目管理
9）环境

6.Scrum敏捷过程：
1）产品负责人建立条目化的产品待开发项,并进行优先级排序
2）在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代
3）团队在迭代内完成所列需求,每天都开每日立会以沟通进度和问题
4）在迭代终点的迭代评审会上,团队向产品负责人展示开发成果

7.ICONIX过程：愿景，业务建模，需求分析，健壮性分析，关键设计，最终设计，实现

8.增量：逐块建造
迭代：反复求精

9.UML静态图：
1）类图：模型化系统的结构
2）对象图：对象及对象间的相互关系
3）组件图：模型化组件的组织和依赖
4）部署图：模型化系统的硬件分布

10.UML动态图：
1）时序图：模型化系统的行为
2）协作图：模型化系统的行为
3）状态图：模型化状态相关的方面
4）活动图：模型化系统内的事件流
5）用例图：模型化系统与外界的交互

11.软件生命周期
1）问题的定义及规划
软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2）需求分析
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3）软件设计
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4）程序编码
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5）软件测试
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6）运行维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

12.ICONIX过程特点
1）尽早进入编码阶段，缩短分析设计周期的软件开发方法
2）合理的简化统一过程(RUP)，基于敏捷软件开发的思想
3）与 RUP相比，是轻量级的过程，与敏捷相比，ICONIX提供充足的需求和设计文档，但不过度分析设计
4）ICONIX过程从把需求文档变成可运作的代码过程只需四步，使用四类UML图，用例图，序列图，类图，健壮性图（非UML标准）

13.获取愿景的三步曲：
1）找到软件项目的老大
2）得到老大对项目的期望(愿景)
3）描述出愿景的度量指标

14.ICONIX过程中如何完成需求开发工作？
(1)需求调查：
1）调查方法：研究文档，访谈，问卷，原型法(具体看环境)
2）需求功能来自客户
3）不要自己臆想需求功能
(2)需求分析：如何做，整理调查结果，定义愿景，业务建模，用例分析
(3)需求定义：确定系统功能，需求规格说明书

15.像医生一样解决用户的痛：准确定位痛点，提出合理解决方案，设计开发软件系统，实施维护软件系统

16.业务建模的意义
1）明确为谁服务—找准客户及其愿景，切记不是在为自己做系统
2）要改进的组织是什么现状—有什么痛处和不足
3）如何改进—新系统的价值就是解决客户痛处，改良客户不足，这才是客户愿意掏腰包的动力
4）在业务建模和需求分析解读，忘掉自己技术专家的身份

17.业务工人：银行工作人员，医院医生
业务执行者：客户
业务实体：点钞机，校园卡系统

18.业务序列图的作用：
1）识别业务对象：业务执行者，业务工人，业务实体
2）确定业务对象间的职责，协作及交互顺序
3）通过序列图来了解现状，为业务的优化提供依据

19.主流分析方法之原型法
原型法是指在获取一组基本的需求后，快速地建立一个目标系统的最初版本，并把它交给用户试用,补充和修改,再进行新的版本开发，反复进行这个过程，直到得出系统的“精确解”，即用户满意为止的一种方法

20.主流分析方法之用例法
描述人们如何使用一个系统，用例视图显示谁是相关的用户，用户希望系统提供什么样的服务，以及用户需要为系统提供的服务

21.域建模步骤
1）仔细阅读需求文档，提取出名词和名词短语
2）排除列表中重复，相似的术语
3）排除超出系统范围的术语
4）画出第一版域模型图
5）整理第一版域模型

22.域建模的意义
1）为项目创建一个术语表，确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域
2）域建模比普通的项目术语表优良的地方体现在：以图的方式清晰地显示出不同术语间的关系(减少理解偏差)
3）域模型图将通过不断修正完善逐步演化为最终的静态类图

23.域模型之间的关系
泛化：一般元素和特殊元素的关系
关联：两个类之间存在着某种语义上的联系

24.系统用例建模的意义
1）系统需求分析的目的是把视角从业务组织转向新系统,站在最终用户及其它干系人的角度看问题
2）系统用例是对(新)系统为系统执行者提供的价值的建模

25.先发现执行者还是先发现用例？
1）执行者比用例明显
2）执行者的个数远比用例的个数少
3）找到一个执行者,就可以找到一堆用例
4）执行者是系统外部人物的代表，所以当然是要先找到执行者，才能够从执行者的角度去寻找用例

26.基本路径
1）客户最想看到的，最关心的路径—核心的核心
2）把基本路径单独分离，凸显用例的核心价值
3）与扩展路径相比，更为有序

27.基本路径的书写要求：
1）以主动语态，“名词-动词-名词”格式来书写，如:银行客户-输入-密码
2）主语只能是执行者或系统

28.扩展路径：系统要处理的意外和分支，与基本路径相比，更为无序

29.功能性需求：通俗讲就是系统可以做什么
非功能性需求：通俗讲就是系统可以把某项功能做到什么程度

30.软件产品的典型非功能性需求：
1）可靠性：系统在一定时间内，在一定条件下无故障地执行指定功能的能力
2）可用性：一个产品可以被特定的用户在特定的上下文中,有效,高效并且满意得达成特定目标的程度
3）性能：系统实现预期功能的能力的特性
4）可支持性：系统在故障解决和系统升级方面的能力

31.健壮性分析中的三种元素：
边界类：与用户交互的对象，系统和外部世界的界面，如窗口，对话框
实体类：是现实世界存在的实体对象，域模型中的类，它常对应于数据库表和文件，有些实体对象是“临时”对象(如搜索结果)当用例结束后将消失
控制器类：边界和实体间的“粘合剂”，将边界对象和实体对象关联起来，它包含了大部分应用逻辑，它们在用户和对象之间架起一座桥梁，控制对象中包含经常修改的业务规则和策略

32.健壮性分析的步骤
1）创建一个空的健壮性图
2）直接将用例文本粘贴到图上(基本路径和扩展路径)
3）从基本路径的第一句话开始画健壮性图
4）贯串整个用例基本路径，一次一个句子，画执行者，适当的边界对象和实体对象以及控制器，和各元素之间的连线
5）将每一个扩展路径画在健壮性图上，并以红色标示出。

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

34.高内聚、低耦合。是判断设计好坏的标准。
高内聚是指一个软件模块(类)是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。
低耦合是指一个软件模块与模块之间的接口，尽量的少而简单，如果某两个模块间的关系比较复杂的话，最好首先考虑进一步的模块划分，降低相互的依赖，这样有利于修改和组合。
目的：使得模块的“可重用性”、“移植性”大大增强

35.敏捷软件开发过程
1）PO和开发团队对产品业务目标形成共识
2）PO建立和维护产品需求列表(需求会不断新增和改变)，并进行优先级排序
3）PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发
4）开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成
5）开发团队每日站立会议，特性开发，持续集成，使开发进度真正透明
6）PO对每轮迭代(2－4周)交付的可工作软件进行现场验收和反馈
7）团队内部进行本轮冲刺的过程回顾,发现可改进的方面

36.敏捷软件开发核心—迭代增量开发

37.敏捷团队包括3个核心角色：PO(Product Owner)产品负责人，Scrum Master(Scrum教练)和Team(开发团队)
确保Team做正确的事 确保Team正确地做事 负责产品需求实现

38.迭代计划会议的好处
通过充分讨论，使团队成员对任务和完成标准理解一致
团队共同参与，促进团队成员更认真对待自己的承偌。

39.为什么使用UML语言
主要用于交流，有利于清晰，有利于精确

40.业务建模结果复核目的有两点，分别是什么？
一是完善业务建模成果，寻找是否有遗漏或错误的地方进行修正，如果问题明显，就需要迭代回去继续做业务建模工作，二是关键干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。

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

42.业务执行者是在业务组织之外，与其交互，享受其价值的人或组织

43.业务用例是业务组织为业务执行者提供的价值

44.业务序列图帮助我们从细节上了解组织的业务流程

45.业务序列图详细描述业务执行者,业务工人,业务实体之间如何交互,以完成某个业务用例的实现流程

46.我们如何改进业务序列图
了解业务组织现状的目的—发现流程中的改进点：
1）信息自动流转
2）封装复杂业务逻辑
3）职责转移
4）访问和操作业务对象

47.怎样区别主执行者和辅执行者？
主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来，场景：主执行者要执行用例，需要辅执行者的帮忙。

48.系统用例是执行者通过系统关联关系

49.用例的关系包含，扩展，泛化

50.需求是软件成功的基础。需求十分重要，并且贯穿整个软件开发的整个过程，需要引起足够的重视。

51.需求开发包括需求调查、需求分析、需求定义，其目的是通过调查与分析，获取用户需求并定义产品需求。

52.需求管理包括需求确认、需求跟踪、需求变更控制，其目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。