软件工程期末总结

一、软件工程概述

1.软件工程三要素

1. 工具【系统】
   EA
   Axure RP
   墨刀
2. 方法【技能】
   业务建模分方法（组织用例图、业务序列图…UML）
   需求方法（系统用例识别和书写规约）
   项目管理方法
   配置管理方法
3. 开发过程【框架】
   关键是对核心活动的选取和定义，业务建模（分析业务过程中发现软件的价值）、需求（使开发人员和用户就“系统做什么”达成共识）、分析、设计（用来保证系统的功能和性能）、实施、发布

2.瀑布模型
需求分析、需求定义、概要设计、详细设计、实现、系统测试、验收测试、维护
3.RUP【统一软件过程】的中心思想是
用例驱动、架构为中心、迭代和增量
4.Scrum敏捷过程
由产品负责人建立产品功能列表，在迭代计划会上，产品负责人讲解迭代任务，团队在迭代内完成所列需求，每日都需要召开每日站立会议，完成迭代，在迭代终点召开迭代评审会展示开发成果
5.迭代与增量

• 增量：模块建造
• 迭代：反复求精

6.UML统一建模语言

1. 使用的目的：主要用于交流、有利于清晰、有利于精确
2. 用途：
   ①分析阶段：用例图、活动图
   ②观察对象交互：交互图
   ③设计阶段：类图
   ④观察对象所处状态不同时的行为差异：状态图
   ⑤配置阶段：部署图
3. 分类：
   ①静态图：
   类图【模型化系统的结构】、对象图【对象及对象间的相互关系】、组件图【模型化组件的组织和依赖】、部署图【模型化系统的硬件分布】
   ②动态图：时序图【模型化系统的行为】、协作图【模型化系统的行为】、状态图【模型化状态相关的方面】、活动图【模型化系统内的事件流】、用例图【模型化系统与外界的交互】

---

二、踏上ICONIX软件过程之路

7.需求工程

1. 需求开发的目的是通过调查与分析，获取用户需求并定义产品的需求。其中包括需求调查、需求分析、需求定义
2. 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。其中包括需求确认、需求跟踪、需求变更控制

8. 需求调查的手段
研究文档、访谈、现场观察、问卷、原型法
从需求调查到需求分析
老板：定义愿景
中层经理：业务建模
一线员工：用例分析
9.Iconix

1. 过程总览
2. 过程特点
   ①尽早进入编码阶段，索顿分析设计周期的软件开发方法
   ②合理的简化统一过程(RUP),基于敏捷软件开发的思想
   ③与RUP相比，是轻量级的过程。与敏捷相比，ICONIX提供充足的需求和设计文档，但不过度分析设计
   ICONIX过程从把需求文档变成可运作的代码只需要四步，使用四张UML图【用例图、序列图、类图、健壮性图】

10.获取愿景

1. 获取愿景的三部曲
   ①找到软件项目的“老大”
   ②得到“老大”对项目的期望（愿景）【愿景不是功能】
   ③描述出愿景的度量指标【买了这个系统对组织有什么好的用处】
2. EA构建愿景

---

三、业务建模，精准了解客户

11.业务建模

1. 意义：业务建模要求我们把视角从软件系统转向客户组织，站在客户角度看问题，以达到清晰准确地“诊断”，对症“开方”
   ①明确为谁服务-找准客户，切记不是在为自己做系统
   ②要改进的组织是什么现状-有什么痛处和不足
   ③如何改进-新系统的价值就是解决客户痛处、改良客户不足，这才是客户愿意掏腰包的动力
2. 步骤
   ①明确我们为谁服务（选定愿景要改进的组织）
   ②要改进的组织是什么现状（业务用例图、现状业务序列图）
   ③我们如何改进（改进业务序列图）

12.业务用例图
组成：
①业务执行者：在业务组织之外，预期交互，享受其价值的人或组织
②业务组织：业务组织为业务执行者提供的价值
③业务用例：【的撰写】业务执行者通过业务组织的某些工作，达到固定目的

13.业务序列图

1. 概念：业务序列图帮助我们从细节上了解组织的业务流程
2. 优势：序列图以面向对象的思想来看业务流程
3. 组成：业务执行者、业务工人、业务实体之前如何交互，已完成某个业务用例的实现流程。
4. 注意：
   ①消息的名字–代表责任和目的
   ②消息的方向–责任委托，不是数据流
   最小的单位是人或则独立智能系统

14.序列图中常用分支的画法

• 循环loop
• 条件分支Alt
• 可选分支Opt
  

15.改进的业务序列图【就是将人换做了要做的系统】

1. 步骤
   ①将新系统作为一个业务实体
   ②将其引入组织现有业务流程
   ③查看其可以改进的流程
   ④评估改进结果
2. 好处：
   通过改进业务序列，可以提前模拟出新系统的出现，将对组织线性的业务流程造成哪些影响，可以提前评估新系统的可行性或提前进行相应的准备工作，实现安全平稳的组织改进

16.业务复核方法-面对面会议
目的：完善业务建模成果，寻找是否有遗漏或错误的地方进行修正，如果问题明显，就需要迭代回去继续做业务建模工作
联系干系人在信息和意见上达成一致，并共同签字确认，作为下一阶段启动的标志。

---

四、需求分析，用例分析法

17.需求分析的主流方法

1. 原型法：按照用户的需求定义，快速的交付一版，用户试用、补充后再进行新版本的开发，反复进行，最后得到用户满意的版本
2. 用例法：是由软件需求分析到最终实现的第一步，以用户的角度分析用户如何使用一个系统，展示关联，最终实现。最常用来描述系统及子系统。

18.域模型

1. 意义：
   ①为项目创建一个术语表，确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域
   ②域模型比普通的项目术语表优良地方体现在：以图的方式清晰地显示出不同术语间的关系
   ③域模型图将通过不断修正完善逐步演化为最终的静态类图
2. 步骤
   ①仔细阅读需求文档，提取出名词和名词短语
   ②排除列表中重复、相似的术语
   ③排除超出系统范围的术语
   ④画出第一版域模型图
   ⑤整理第一版域模型
3. 关系
   ①泛化：一般元素和特殊元素的关系
   ②关联：两个类之间存在着某种语义上的联系
   
4. 高级话题：
   ①域模型的迭代
   
   ②域模型和数据模型的区别
   1)域模型：是分析模型是，是由系统分析员、用户认识现实业务的工具，描述业务实体及相互之间的关系，域模型在设计期间不用考虑数据存放问题，只考虑业务描述中涉及