工作这么多年，这些知识点，是不是丢得差不多了？
介绍
软件工程是研究软件开发技术和软件项目管理的一门工程学科，从工程化的角度来指导软件开发、测试和项目管理等活动。
软件工程的目标
以较少的投资获取高质量的软件
- 较低的开发成本
- 达到要求的软件功能
- 较好的软件性能
- 开发的软件易于移植
- 需要较低的维护费用
- 按时完成开发工作，及时交付使用
软件工程的七条基本原理
- 用分阶段的生命周期计划严格管理： 要有项目周期
- 坚持进行阶段评审： 质量保证工作不能等到编码结束后进行
- 实行严格的产品控制： 阻止需求变更
- 采纳现代程序设计技术： 提升效率减、少维护成本
- 结果应能清楚地审查： 明确开发小组责任和产品标准，使得标准能清楚地审查
- 开发小组的人员应少而精： 高素质开发人员的效率比低素质开发人员的效率高几倍到几十倍，开发工作中犯的错误也要少得多；人数越多，沟通成本越大
- 承认不断改进软件工程实践的必要性： 前六条是根据现有的经验总结和归纳，并不能保证赶上技术不断前进发展的步伐。新技术是保证产品质量和开发效率的基础。
软件开发方法
- 结构化方法
- 自顶向下、逐步求精，采用模块化技术、分而治之的方法，将系统按功能分解成若干模块；
- 模块内部由顺序、分支、循环三种基本控制结构组成；
- 子程序实现模块化
- 面向对象方法
客观世界由各种对象组成，每个对象都有各自内部状态和运动规律，不同对象之间相互作用和联系构成了各种各样的系统，构成了客观世界。
软件生存周期及模型
软件由三个时期构成，每个时期进一步划分为若干阶段。
软件定义时期
- 问题定义： 确定要解决的问题，写出关于问题性质、工程目标和工程规模的书面报告，并得到用户的确认
- 可行性研究： 从技术、经济、操作和法律等方面研究并论证软件系统的可行性
- 需求分析： 确定目标系统功能，对目标系统提出完整、准确、清晰、具体的要求，经用户确认系统需求后，写出需求规格说明书
软件开发时期
- 概要设计： 也称总体设计。确定目标系统怎么做，概括提出解决问题的办法。根据需求规格说明书建立系统的总体结构和模块间的关系，定义各个功能模块的接口，设计数据库或数据结构，规定设计约束，指定组装测试计划。
- 详细设计： 也称模块设计、物理设计。将概要细化，形成若干个可编程的模块，写详细设计说明书
- 编码与单元测试
- 综合测试： 包括组装测试和确认测试，组装测试又称集成测试，确认测试由用户根据需求规格说明书验收
软件运行与维护时期
为了使软件永久满足用户的需求
- 修正性维护： 解决bug
- 适应性维护： 适配新环境
- 完善性维护： 完成新需求
- 预防性维护： 为了给未来的改进提供更换的基础，改善可维护性
软件生存周期模型
也叫软件生命周期模型，描述软件开发过程中各种活动如何执行的模型。常见的分为： 瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型
| 模型 | 适用场景 | 缺点 |
|---|---|---|
| 瀑布模型 | 需求明确，用户稳定，用户需求参与度低，分析人员熟悉项目 | 周期长 |
| 原型模型 | 需求不明确，项目成员沟通能力差 | 原型开发成本高 |
| 喷泉模型 | 进度紧迫，各阶段并行 | 各阶段人员交叉，不利于项目管理 |
可行性研究
问题定义
系统分析员需协助客户一起完成“问题定义”工作，即软件定义。弄清楚用户的根本问题以及所需的资源和经费。明确“要解决的问题是什么”。
- 技术可行性： 对项目的功能、性能和限制条件进行分析，确定在现有资源下，技术风险有多大，项目是否能实现。
- 经济可行性： 进行开发成本估算以及了解取得效益的评估，确定项目是否值得投资开发。
- 操作可行性： 软件运行环境是否正常，组织内部是否可行，系统间是否兼容等。
- 法律可行性： 项目是否存在侵权问题。
系统流程图
系统流程图的基本符号：
可行性研究报告
从经济、技术、法律等多维度进行调查研究和分析比较，并对项目建成后的财务、经济效益及社会影响进行预测，从而提出该项目是否值得投资和如何进行建设的咨询意见，为项目决策提供依据的一种综合性分析方法。
- 引言： 写文档的目的，项目的名称、背景，文档的专门术语和参考资料
- 可行性研究前提： 说明开发的功能、性能和要求，达到的目标，各种限制条件，可行性研究方法和决定可行性的主要因素
- 对现有系统的分析： 与现有系统比较的优越性，对用户、设备、现有软件、开发流程、开发环境、运行环境和经费支出的影响，对技术可行性的评价
- 目标系统的经济可行性分析： 说明目标系统的各种支出、各种效益、收益投资比、投资回收周期
- 社会因素可行性分析： 说明法律因素对合同责任、侵犯专利权和侵犯版权等问题的分析，说明用户使用可行性是否满足用户行政管理、工作制度和人员素质的要求
- 其他可供选择方案： 逐一说明其他可供选择的方案，并说明未被推荐的理由
- 结论意见： 项目是否可开发，还需什么条件才能开发，项目目标有何变动等。
项目开发计划
对项目的费用、时间、进度、人员组织、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划，是项目管理人员对项目进行管理的依据，据此对项目的费用、进度和资源进行控制和管理。
- 项目概述： 说明软件的功能、性能；为完成项目应具备的条件；用户及合同承包者承担的工作、完成期限及其他限制条件；应交付的程序名称，所用的语言及存储形式；应交付的文档
- 实施计划： 说明任务的划分，各项任务的责任人；说明项目开发进度，按阶段应完成的任务，说明各任务的开始时间和完成时间；说明项目的预算，各阶段的费用支出预算
- 关键问题： 逐项列出能影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响
- 人员组织及分工： 说明开发该项目所需人员的类型、组成结构和数量
- 应交付成果： 说明需要完成的程序名称、所用的编程语言及存储程序的媒体形式。源码、可执行程序、数据库对象创建语句、数据库基础数据、配置文件、第三方模块、原型设计文件等；需移交用户的每种文档名称、内容要点及存储形式，如需求规格书、帮助手册等；列出将向用户或委托单位提供的各种服务，如培训、安装、维护和运行支持等
- 交付期限： 说明项目最后完工交付的日期。
需求分析
将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化为需求规格说明书的过程。
类型
- 功能需求
- 性能需求
- 环境需求
- 可靠性和可用性需求
- 出错处理需求
- 安全保密需求
- 用户界面需求
- 资源使用需求
- 成本消耗需求
- 开发进度需求
- 接口需求
- 约束
- 逆向需求
- 将来可能提出的要求
评审标准
- 正确性
- 清晰性
- 无二义性
- 一致性
- 必要性
- 完整性
- 可实现性
- 可验证性
- 可测性
分析过程
- 需求获取
- 需求分析建模
- 证实需求
- 编写需求规格说明书
- 需求评审
- 更正需求、完善模型、修改规格说明
- 输出需求规格说明书
建模步骤
- 获取当前系统的物理模型
将当前系统用系统流程图描述出来
- 抽象出当前系统的逻辑模型
将当前系统的系统流程用数据流图（DFD，Data Flow Diagram）描述出来
-
建立目标系统的逻辑模型
-
导出目标系统的物理模型
-
补充目标系统的逻辑模型
分析模型
以“数据字典”为核心，描述了软件使用的所有数据对象，围绕核心的是“实体关系图”，“数据流图”和“状态转换图”
ER图
实体关系图（Entity-Relationship Diagram），是一种数据模型，是以实体、关系（关联数）、属性三个概念概括数据的基本结构，从而描述静态数据结构的概念模型。
基本符号：
示例：
DFD
数据流图（Data Flow Diagram），描述数据在系统中流动和处理的过程，它只反映系统必须完成的逻辑功能，是一种功能模型。
基本符号：
- 矩形： 外部实体，与系统进行交互，但系统不对其进行加工和处理的实体
- 椭圆形： 加功，对数据进行的变换和处理
- 单实线箭头： 数据流，在数据加工之间或数据存储和数据加工之间进行流动的数据，用带数据流名称的箭头表示
- 双实线箭头： 数据存储，在系统中需要存储的数据（文件）
STD
状态转换图（Status Transition Daigram, STD），描述系统状态如何响应外部事件间进行转换的图表示方式。
输出
数据字典
对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述
需求规格说明书
需求规格说明书（SRS，Software Requirement Specification），在需求分析阶段完成的文档，是软件需求分析的最终结果。作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据。
组成部分
引言：
- 编写目的
- 项目范围
- 定义： 专门术语的定义和缩写词的原义
- 参考资料： 列出计划任务书、文档所引用资料、标准和规范等的作者、出自单位等资料来源
任务概述：
- 产品概述
- 用户特点
- 条件与限制
需求规定：
- 对功能的规定
- 对性能的规定
- 对输入输出的规定
- 数据管理的规定
- 其他专门要求：安全保密性、可使用性、可维护性、可移植性等
运行环境规定：
- 用户界面
- 设备
- 软件接口
- 故障处理
