软件工程复习笔记

一、软件

什么是软件

软件 = 程序 + 数据结构 + 文档

软件的分类

• 应用软件
• 系统软件
• 支撑软件

软件需求

• 软件功能性需求(Functional Requirement)

能够完成的功能及在某些场景下可展现的外部可见行为或效果

• 软件质量方面的需求(Quality Requirement)

外部质量属性，外部可展现的，用户、客户等会非常关心，如运行性能、可靠性、易用性等
内部质量属性，隐藏在内部的，软件开发工程师会非常关心，如可扩展性、可维护性、可理解性

• 软件开发约束性需求(Constraint Requirement)

开发成本、交付进度、技术选型、遵循标准等方面提出的要求

类别	内涵	关注的利益相关方	示例
功能性需求	软件具有的功能、行为和服务	用户、客户、开发者群体、其他系统	- 分析和识别老人语音呼叫 - 分析异常状况
	内部质量需求	开发者群体	- 可维护性、可扩展性、可理解性、可重用性等
软件质量需求	外部质量需求	用户、客户、开发者群体、其他系统	- 界面操作要在1秒内响应 - 视频延迟不超过2秒
开发约束性需求	软件开发需满足的要求	客户、开发者群体、其他系统	- 要求在6个月内交付产品 - 软件运行在Android之上 - 采用Java语言来实现

开源软件和闭源软件

闭源软件

软件代码不对用户开放的一类软件，购买软件只提供可运行软件或服务，没有提供源代码
以许可证方式授权用户使用

缺点：无法掌握软件内部实现情况（如是否存在安全漏洞和恶意代码），也无法对软件进行修改和完善，极大影响了开发者的创新自由

开源软件

一种源代码可以自由获取和传播的计算机软件，其拥有者通过开源许可证赋予被许可人对软件进行使用、修改和传播

优点

• 源代码可自由传播
• 免费使用降低成本
• 激发创作者的热情
• 快速开发搭建系统

软件质量

软件质量是指软件满足给定需求的程度，它是软件的生命线

要求：

• 正确性
• 可靠性
• 健壮性
• 有效性
• 安全性
• 可维护性
• 可移植性
• 可重用性
• 可理解性
• 可信性
• 持续性
• 可用性
• 互操作性

保证方法

二、软件工程

概念

将系统化、规范化、可量化的方法应用于软件的开发、运行和维护的过程；以及上述方法的研究

原则

• 抽象与建模
• 模块化
• 软件重用
• 信息隐藏
• 关注点分离
• 分而治之
• 双向追踪原则
• 工具辅助

三、软件过程模型

定义了软件开发的具体活动以及活动间的逻辑关系

不同模型的特点

模型名称	指导思想	关注点	适合软件	管理难度
瀑布模型	提供系统性指导	与软件生命周期相一致	需求变动不大、较为明确、可预先定义的应用	易
原型模型	以原型为媒介指导用户的需求导出和评价	需求获取、导出和确认	理解需求难以表述清楚、不易导出和获取的应用	易
增量模型	快速交付和并行开发	软件详细设计、编码和测试的增量式完成	需求变动不大、较为明确、可预先定义的应用	易
迭代模型	多次迭代，每次仅针对部分明确软件需求	分多次迭代来开发软件，每次仅关注部分需求	需求变动大、难以一次性说清楚的应用	中等
螺旋模型	集成迭代模型和原型模型，引入风险分析	软件计划制定和实施，软件风险管理，基于原型的迭代式开发	开发风险大，需求难以确定的应用	难

四、敏捷开发

敏捷软件开发宣言

一种轻量级软件开发方法

相对于重量级的软件开发方法而言

主张软件开发要以代码为中心，快速、轻巧和主动应对需求变化，持续、及时交付可运行的软件系统

提供了一组思想和策略，指导快速响应用户需求的变化，快速交付可运行的软件制品

基本主张

较之于过程和工具，应更加重视人和交互的价值
较之于面面俱到文档，应更加重视可运行软件系统的价值
较之于合同谈判，应更加重视客户合作的价值
较之于遵循计划，应更加重视响应用户需求变化的价值

指导思想

Note

• 强化可运行的软件，弱化软件文档
• 以适应变化为目的，提升应变能力
• 以人为本，让方法等服务于人

敏捷准则

1. 通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

五、UML统一建模语言

视点	图（diagram）	说明
结构	包图（package diagram）	从包层面描述系统的静态结构
	类图（class diagram）	从类层面描述系统的静态结构
	对象图（object diagram）	从对象层面描述系统的静态结构
	构件图(component diagram)	描述系统中构件及其依赖关系
行为	状态图(statechart diagram )	描述状态的变迁
	活动图(activity diagram)	描述系统活动的实施
	通信图(communication diagram)	描述对象间的消息传递与协作
	顺序图(sequence diagram)	描述对象间的消息传递与协作
部署	部署图（deployment diagram）	描述系统中工件在物理运行环境中的部署情况
用例	用例图（use case diagram）	从外部用户角度描述系统功能

六、软件测试

程序是运行软件的载体，也是软件缺陷的载体

白盒测试

基于程序内部的执行流程来设计测试用例

黑盒测试

基于程序的外在功能和接口来设计测试用例