一、软件工程概述
1、计算机软件
按照软件的应用领域，将计算机软件分为以下几类，包括系统软件、应用软件、工程科学软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件、开放计算、网络资源、开源软件。
2、软件工程基本原理
1983年 B.W.Boehm提出软件工程的7条基本原理，包括：
- 用分阶段的生命周期计划严格管理
- 坚持进行阶段评审
- 实现严格的产品管控
- 采用现代的程序设计技术
- 结果应能清楚的审查
- 开发小组的人员应少儿精
- 承认不断改进软件工程实践的必要性。
3、软件生存周期
- 可行性分析与项目开发计划。
- 需求分析
- 概要设计
- 详细设计
- 编码
- 测试
- 维护
二、软件过程模型
软件开发中遵循一系列可预测的步骤（即路线图），该路线图成为软件过程。过程是活动的集合，活动是任务的集合。
能力成熟度模型（CMM）
CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。CMM将软件过程改进分为5个成熟度级别。
能力成熟度模型（CMMI）
CMMI 提供了两种表示方法：阶段式模型和连续式模型。
软件过程模型
软件过程模型习惯上也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。
典型的软件过程有
瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件
的开发模型和形式化方法模型
等。
瀑布模型
将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型，包括需求
分析、设计、编码、测试、运行与维护。
优点：
容易理解、成本低、强调开发的阶段性早期计划及需求调查和产品测试。
缺点：
在瀑布模型中，需求或设计的错误往往只有到了项目后期才能被发现，对项目风险的控制能力较弱，导致项目通常是延期，开发费用超出预算。
增量模型：
其融合了瀑布模型的基本成分和原型实现的迭代特征。
优点：
可交付的第一个版本所需要的成本和时间很少，开发由增量表示的小系统所承担的风险不大，由于很快发布了第一个版本，因此可减少用户需求的变更。同时其具有瀑布模型所有的优点。
缺点：
若没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定，若需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发或重新发布。管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
演化模型：
原型模型：
原型模型开始于沟通，目的是定义软件的总体目标，标识需求，然后快速制定原型开发计划，确定原型的目标和范围，快速构建原型并交付用户使用，收集客户反馈意见，并在下一轮中对原型进行改进。
2.螺旋模型：
对于一个复杂的大项目，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入两种模型均忽略的风险分析，弥补了这两种模型的不足。
-
制定计划：
确定软件目标，选定实施方案，明确项目开发限制条件；
-
风险分析：
对所选方案分析，识别风险，消除风险；
-
实施工程：
实施软件开发，验证阶段性产品；
-
用户评估：
评价开发工作，提出修正建议，建立下一个周期的开发计划。
喷泉模型：
以用户需求为动力、以对象为驱动的模型。适用于面向对象的开发方法，他克服了瀑布模型不
支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。
基于构件的开发模型：
指利用预先包装的构件来构造应用系统，构件可以是组织内部开发的构件，也可以是商品化成
品（
COTS
）软件构件。一种基于构件的开发模型包括领域工程和应用系统工程组成。
形式化方法模型：
形式化方法是建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化
的数学规格说明。
统一过程（UP）模型
是一种“用例和风险驱动，以架构为中心，迭代并增量”的开发过程，由
UML
方法和工具支
持。
起始阶段：
专注项目的初创活动，主要工作产品有构想文档、初始用例模型、初始项目术语表、
初始业务用例、初始风险评估、项目计划、业务模型以及多个原型（需要时）；
精化阶段：
在于理解最初的领域范围之后进行需求分析和架构演进，主要工作产品有用例模型、
补充需求、分析模型、整体体系结构描述、可执行的软件体系结构原型、初步设计模型、修订的风
险列表、项目计划以及初始用户手册；
构建阶段：
关注系统的构建，产生实现模型，主要工作产品有设计模型、软件构件、集成软件
增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册等）；
移交阶段：
关注软件提交方面工作，产生软件增量，主要工作产品有提交的软件增量、β测试
报告和综合用户反馈。
敏捷方法
常用的方法：极限编程（
XP
）、水晶法（
Crystal
）、并列争求法（Scrum）、自适应软件开发（ASD
）、敏捷统一过程（
AUP
）。
三、软件项目需求分析
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的
调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转
化为完整的需求定义，从而确定系统必须做什么的过程。
软件需求
-
功能需求：考虑系统要做什么，什么时候做、如何修改或升级；
-
性能需求：考虑软件开发的技术性指标。如存储容量限制、执行速度、响应时间、吞吐量等；
-
用户或人的因素：考虑用户的类型；
-
环境需求：考虑软件应用的环境；
-
界面需求：考虑来自其他系统的输入，到其他系统的输出等；
-
文档需求：考虑需要哪些文档，文档针对哪些读者；
-
数据需求：考虑输入、输出格式，接收、发送数据的频率，数据的精准度、数据流量、数据保
-
持时间；
-
资源使用需求：考虑软件运行时所需要的资源；
-
安全保密需求：考虑是否需要对访问系统或系统信息加以控制；
-
可靠性要求：考虑系统的可靠性要求，系统是否必须检测和隔离错误，出错后重启系统所允许
-
的时间等；
-
软件成本消耗或开发进度需求：考虑开发是否有规定的时间表；
-
其他非功能性要求：如采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准等。
需求分析的原则
-
必须能表示和理解问题的信息域；
-
必须能定义软件将完成的任务；
-
必须能表示软件的行为；
-
必须划分描述数据、功能和行为的模型；
-
分析过程应该从要素信息移向细节信息。
四、软件项目系统设计
系统设计的主要内容包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设
计、数据存储设计、用户界面设计和安全控制设计等。
常用的设计方法有：面向数据流的结构化设计方法（SD）、面向对象的分析方法（
OOD
）。
概要设计
-
设计软件系统总体结构；
-
数据结构及数据库设计；
-
编写概要设计文档（概要设计说明书、数据库设计说明书、用户手册及修订测试计划）；
-
评审。
详细设计
-
对每个模块进行详细设计；
-
对模块内部的数据结构设计；
-
对数据库进行物理设计，即确定数据库的物理结构；
-
其他设计（代码设计、输入
/
输出设计、用户界面设计）；
-
编写详细设计说明书；
-
评审。
五、软件项目系统测试
是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符合系统说明
书的地方。这种测试可以发现系统分析和设计中的错误。
测试应遵循的基本原则：
-
应尽早并不断的进行测试；
-
测试工作应避免原先开发软件人员或小组参与；
-
设计测试方案时要确定输入数据，还要根据系统功能确定预期输出结果；
-
设计测试用例时要设计合理、有效的输入条件，还要包含不合理、失效的输入条件。人们
-
在测试时通常忽略了对异常、不合理、意想不到的情况进行测试，这可能就是隐患；
-
在测试时要检查程序是否做了该做、不该做的事，多余的工作会影响程序的效率；
-
严格按照测试计划进行测试；
-
妥善保存测试计划、测试用例；
-
要精心设计测试用例。
测试的过程包括：
-
制定测试计划；
-
编制测试大纲；
-
根据测试大纲设计和生产测试用例；
-
事实测试；
-
生成测试报告
传统软件的测试策略
1.
单元测试 也称模块测试，在模块编写完成且编译无误后进行。侧重于模块中的内部处理逻辑和数据结构。
2.
集成测试 集成测试通常有两种方法： 非增量集成：分别测试各个模块，再将这些模块组合起来进行整理测试； 增量集成：以小增量的方式逐步进行构造和测试。 常用的增量集成策略包括：自顶向下集成测试、自底向上集成测试、回归测试、冒烟测试等。
3.
确认测试 确认测试始于集成测试的结束，那时已测试完单个构件，软件已经组装成完整的软件包，且接口错误已被发现和改正。 确认过程的一个重要成分是配置评审，主要检查软件、文档、数据是否齐全、分类有序。
4.
系统测试
系统测试是将已经确认的软件、硬件、外设、网络等其他因素结合在一起，进行各种集成测试
和确认测试，主要有：恢复测试、安全性测试、压力测试、性能测试部署测试。
测试方法
静态测试：
指被测程序不在机器上运行，采用人工检测和计算机辅助静态分析的手段对程序进
行测试，包括人工检测、计算机辅助静态分析。
动态测试：
指通过运行程序发现错误，一般采用黑盒测试和白盒测试。
黑盒测试：
也称功能测试，在不考虑软件内部结构和特性的情况下，测试软件外部特性。
白盒测试：
也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过
程进行测试，检查是否满足设计的需要。
调试
目前常用的调试方法有：
-
试探法：
调试人员分析错误的症状，猜测问题所在的位置，一步步试探和分析问题所在。
该方法效率低，适用于结构比较简单的程序；
-
回溯法：
调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回追踪代码，
直到找出问题根源为止。该方法使用与小型程序；
-
对分查找法：
该方法主要用来缩小错误范围，直到把故障范围缩小到比较容易诊断为止；
-
归纳法：
从测试所暴露的问题出发，收集所有正确、不正确的数据，并分析它们之间关系，
提出假想的错误原因，用这些数据证明或反驳，从而查出错误所在；
-
演绎法：
根据测试结果，列出可能的错误原因，分析已有的数据，排除不可能和彼此矛盾
的原因，若有多个错误同时存在，要重新分析，提出新的假设，直到发现错误为止。
六、软件项目管理
项目管理涉及的范围
有效的软件项目管理集中在以下4点：人员、产品、过程、项目。
-
人员：参与项目的人员类型分为：项目管理人员；高级管理人员；开发人员；客户；最终
用户。
-
产品：开展项目计划之前，应先进行项目定义，即定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术、管理约束等。
-
过程：对于软件项目来说，强调的是对其进行过程控制，通常将项目分解为任务、子任务
等。
-
项目：
Reel
提出了包含如下
5
个常识的软件项目办法：明确目标及过程、保持动力、跟
踪进展、做出明智的决策、进行事后分析。
项目估算
常用的估算方法有3种
- 基于已经完成类似的项目进行估算。
- 基于分解技术进行估算
- 基于经验估算模型的估算
成本估算方法。常用的成本估算方法、自顶向下估算方法、自底向上估算方法、差别估算法、其他估算法。
进度管理
进度管理的基本原则
-
划分：
项目必须要被划分成若干可以管理的活动和任务。 -
相互依赖性：
划分后的各个活动之间的依赖关系必须是明确的，例如有些任务必须按顺序完成，有的任务可以并发进行，有的任务只能在其他活动完成之后才能开展，有的则可以独立进行。 -
时间分配：
必须为每个任务规定开始和结束时间。 -
工作量确认：
每个项目都有预定的人员参与，项目管理者必须在任何时间节点中所分配的人员数量不能超过项目团队的总人数。 -
确定责任：
为每个任务指定特定的团队成员进行负责。 -
明确输出结果：
即每个任务都要有一个明确的输出结果，例如一个可交付的工作产品。 -
确定里程碑：
每个任务或任务组都应该与一个项目里程碑相关联，当一个或多个工作产品经过质量评审并且得到认可时，标志着一个里程碑的完成。
进度安排
为了监控项目的进度计划和实际进展情况，表示各项任务之间进度的相互依赖关系，我们需要采用图示的方法。常用的方法有：甘特图、项目计划评审技术图。
软件质量管理
1.软件质量特性，软件质量模型由3个层次组成，第一层为质量特性，第二层为质量子特性，第三层为度量指标。
2.软件质量保证7个主要活动相关的各种任务。
- 应用技术方法。
- 进行正式的技术评审。
- 测试软件
- 便准的实施。
- 控制变更
- 度量
- 记录保存和报告
3.软件评审的内容
设计质量的评审包括：评审软件的规格说明书是否符合用户的要求；评审可靠性；评审保密措施实施情况；评审操作特性实施情况；评审性能；评审软件是否具有可修改性、可扩充性、可互换性和可移植性；评审软件可测试性；评审软件可复用性；
软件配置管理
（SCM）
用于整个软件工程过程，主要目标是识别变更、控制变更、确保变更正确实现、报告有关变更。
1.基线。 软件生命周期中各开发阶段的一个特定点，作用是将各阶段的工作划分更加正确。
2.软件配置项。
3.版本控制
4.变更控制
七、软件度量
软件度量用于对产品及开发产品的过程进行度量。软件产品、软件过程、资源都具有外部属性
和内部属性。
1.面向规模的度量
主要是通过对质量和生产率的测量进行规范化得到的，而这些量都是根据开发过的软件的规模
得到的。
2.面向功能的度量
它以功能测量数据为规范化值。应用最广泛的面向功能度量是功能点（FP）。功能点是根据 软件信息域的特性及复杂性来计算的。
3.
软件复杂性度量
指的是理解和处理软件的难易程度。软件复杂性度量的参数有很多，主要包括：
规模；
难度；
结构;智能度。