软件工程期末复习（超详细）

软件工程

• • 一：软件工程概述
  • 二.踏上ICONIX软件工程之路
  • 三:业务建模，精准了解你的客户
  • 四：需求分析，用例分析法
  • 五：需求与设计的桥梁：健壮性分析
  • 六：关键设计
  • 七：详细设计
  • 八：敏捷开发
  • 九：Scrum敏捷过程
  • 十一：敏捷工程实践

一：软件工程概述

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

软件的概念：
软件（software）：软件是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。
（1）能够完成预定功能和性能的可执行指令（program）
（2）使得程序能够适当地操作信息的数据结构（data）
（3）描述程序的操作和使用的文档（document）
软件危机：
软件危机定义：软件在开发和维护过程中遇到的一系列严重问题。
软件危机包含两层含义：
如何开发软件。
如何维护数量不断膨胀的已有软件。
软件工程（Software Engineering）:
是研究和应用功能如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上。
软件生存周期：
是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程。一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。

1. 计划阶段
   确定待开发系统的总体目标和范围。
   研究系统的可行性和可能的解决方案，对资源、成本及进度进行合理的估算。
2. 分析阶段
   分析、整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册。
3. 设计阶段（总体设计和详细设计）
   设计阶段的目标是决定软件怎么做。
   软件设计主要集中于软件体系结构、数据结构、用户界面和算法等方面。
4. 实现阶段（编码）
   实现阶段是将所设计的各个模块编写成计算机可接受的程序代码。
5. 测试阶段
   设计测试用例，对软件进行测试，发现错误，进行改正。
6. 运行和维护阶段
   应当在软件的设计和实现阶段充分考虑软件的可维护性。
   维护阶段需要测试是否正确实现了所要求的修改，并保证在产品的修改过程中，没有做其他无关的改动。
   维护常常是软件生命周期中最具挑战性的一个阶段，其费用是相当昂贵的。
   软件工程三要素：工具、方法、开发过程
   瀑布模型：
   问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试、运行与维护。
   特点：
   1.自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
   2.上一阶段的变换结果是下一阶段变换的输入，相邻两个阶段具有因果关系。
   问题：
   1.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
   2.开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，增加了风险。
   3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
   RUP统一软件过程（Rational Unified Process）
   RUP的中心思想是：用例驱动、架构为中心、迭代和增量。
   Scrum敏捷过程：

• 产品负责人建立条目话的产品待开发项，并进行优先级排序。
• 在迭代计划会上，产品负责人讲解本迭代要开发的条目，团队进行估算并放入下一个迭代。
• 团队在迭代内完成所列需求，每天都开每日“立”会以沟通进度和问题。
• 在迭代终点的迭代评审会上，团队向产品负责人展示开发成果。

二.踏上ICONIX软件工程之路

• 包含关系：使用包含用例来封装一组跨越多个用例的相似动作（行为片段），以便多个基用例复用
  

• 干系人利益

• 基本路径

• 扩展路径

• 业务规则

软件产品的典型非功能性需求：

• 可靠性
• 可用性
• 性能
• 可支持性

五：需求与设计的桥梁：健壮性分析

健壮性分析中的三种元素：

• 边界类：与用户交互的对象，系统和外部世界的界面，如窗口，对话框等等。
• 实体类：是现实世界存在的实体对象，域模型中的类，它常对应于数据库表和文件。
• 控制器类：边界和实体间的“粘合剂”，将边界对象和实体对象关联起来，它包含了大部分应用逻辑，在用户和对象之间架起一座桥梁。控制对象中包含经常修改的业务规则和策略。

健壮性分析中三种元素的交互规则：
执行者只可以和边界对象通话；
边界对象和控制器可以互相通话；
控制器可以和另一个控制器通话；
控制器和实体对象可以互相通话；

六：关键设计

关键设计主要意义：
就是要通过寻找对象之间的交互关系，进而进行方法（操作或行为）分配。

七：详细设计

技术架构及相关考虑：

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

八：敏捷开发

敏捷软件开发模式：

• 敏捷开发的核心思想是以用户的需求进化为核心，采用迭代、循序渐进的方法进行的软件开发。
• 由传统迭代式软件开发模式发展而来，强调产品价值、团队协作、客户参与、先期验证、简化流程、拥抱变化。
• 总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成。
  敏捷=理念+优秀实践+具体应用

1. 理念（敏捷核心思想）
2. 优秀实践（敏捷的经验积累）
3. 具体应用（能够结合自身灵活应用才是真正敏捷）

九：Scrum敏捷过程

• scrum是一个增量的、迭代的敏捷开发过程。
  Scrum敏捷开发过程：
• 项目整个开发周期包括若干个小的迭代周期，每个迭代周期成为一个Sprint,每个Sprint的建议长度2到6周。
• 使用产品Backlog来管理项目的需求，产品Backlog是一个按照商业价值排序的需求列表，体现形式通常为用户故事（UserStory）。
• 团队从产品Backlog中挑选最有商业价值的需求，经过Sprint计划会议上的分析、讨论和估算得到任务列表，成为Sprint Backlog。
• 在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
  敏捷团队
  敏捷团队包括3个核心角色：
  PO（Product Owner 产品负责人）、
  Scrum Master（Scrum教练）、
  Team（开发团队）
  scrum组成：
  三个角色：产品负责人、敏捷教练、团队
  四个会议：迭代计划会议、每日站会、迭代评审会议、迭代回顾会议
  三个产物：Product Backlog 、Sprint Backlog、
  燃尽图
  scrum特点：
• 适于在不确定性高的环境中开发复杂产品。
• 简洁但有效
• 项目信息对所有干系人高度透明
• 便于快速发现问题，促使团队和组织持续改进。

十一：敏捷工程实践

用户故事：
用户故事是一个用来确认用户和用户需求的简短描述。包含三个要素：角色、功能、价值
例：作为一个xxx客用，我需要xxx功能，能够带来xxx好处。
用户故事INVEST标准：

• 独立性（independent）：故事之间松耦合，具有独立性。不应该依赖于其他的用户故事。
• 可协商（Negotiable）：开始仅用于占位符，逐步细化。
• 有价值（Valuable）：用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写。
• 可估算（Estimatable）：设计、开发、测试团队可复算工作量和成本。（不可估算的原因：太大需要分解，或信息不全需要进一步探索）
• 短小（Small）：故事应该尽量的短小（如两周冲刺，故事一般是两天以内的）
• 可测试（Test）：有相应测试验收标准。
  结对编程：
  两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；
  操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；
  领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。
  测试驱动开发（Test-Driven Development）：
• TDD以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化；
  持续集成（Continuous Integration）：
• 持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成公国自动化构建完成。
  代码复查（Code Review）