软件工程
软件与软件工程
程序并不就是软件，程序只是软件的一个组成部分，软件的定义由以下三个部分组成：
- 在运行中能提供所希望的功能和质量的指令集（即程序）
- 使程序能够正确运行的数据结构
- 描述程序研制过程、方法所使用的文档。
软件危机指的是软件开发和维护过程中遇到的一系列严重的问题。其表现形式有：
- 软件产品不符合用户的实际需求
- 软件产品的质量差
- 对软件开发的成本和进度的估计常常不准确
- 软件的可维护性差
- 软件价格昂贵
产生软件危机的原因
- 软件不同于硬件，它是计算机系统中的逻辑部件而非物理部件。在真正运行之前，很难检验程序的正确性
- 软件规模越来越大
- 开发人员和管理人员只重视开发，而轻视问题的定义，导致偏离用户需求
- 缺乏统一的软件质量管理规范
- 在软件的开发与维护关系问题上存在错误的理解
1993年美国《IEEE软件工程标准术语》对软件工程的定义为：把系统的、规范的、可量度的途径应用于软件开发、运行和维护过程。也就是把工程应用于软件。
其中“软件”的定义为：计算机程序、方法、规则、相关的文档资料以及在计算机上运行时所必须的数据。
美国著名软件工程专家 B.W.Boehm 在总结软件工程准则和信条的基础上，提出了软件工程的 7 条基本原则：
- 用分阶段的生存周期计划严格管理
- 坚持进行阶段评审
- 实行严格的产品控制
- 采用现代软件设计技术
- 结果应能清楚地审查
- 合理安排软件开发小组的人员
- 不断改进软件工程实践
一个软件从定义到开发、运行和维护，直到最终废弃，要经历一个较长的时期，通常把软件所经历的这个时期称为生命期。软件生命期可以分为三大阶段：
- 计划阶段
- 开发阶段
- 维护阶段
软件设计阶段主要解决软件要“做什么”的问题，也就是要确定软件的处理对象、软件的上下文环境、软件与外界的接口、软件的功能、软件的质量以及有关的约束和限制。该阶段产生的主要文档是需求规则说明书。
软件开发阶段主要解决软件“怎么做”的问题，包括软件架构的设计、概要设计、详细设计、数据结构设计、算法设计、编写程序和测试，最后得到可交付使用的软件。该阶段的文档有设计说明书，包括架构设计说明书、概要设计说明书和详细设计说明书。
软件维护阶段的任务就是为使软件适应外界环境的变化，进一步实现软件功能的扩充和质量的改善而修改软件。该阶段产生的文档有维护计划和维护报告。
软件开发模型是软件工程思想的具体化，是把软件开发实践中总结出来的软件开发方法和步骤实施于过程模型中，是跨越整个软件生存周期的关于系统开发、运行、维护所实施的全部工作和任务的结构框架。
软件过程
把软件开发活动的组织、规范和管理称为软件过程。软件过程分为可行性分析、需求分析、架构设计、概要设计、详细设计、编码、测试和运行维护等主要阶段。
可行性分析 阶段首先要对问题进行定义，说明市场前景和应用对象。这样才有开发项目的必要，这是创建并限制未来需求的重要一步。可行性分析包括经济、技术和法律可行性。
需求分析 阶段的基本任务是准确地回答“系统必须做什么”这个问题（而不是确定系统如何完成它的工作），也就是对目标系统提出完整、准确、清晰、具体的要求。
在 架构设计 阶段，要按一定的设计原则划分子系统和组件，确定它们之间的相互作用。在架构设计时，要使架构反映重要的需求，适应预期的变化，对系统期望的质量指标进行权衡。
概要设计 的目的是为软件架构中各个子系统和组件（模块）确定类与接口；详细设计的目的是为各个组件（模块）确定具体使用的算法和数据结构，并用各种选定的表达工具给出清晰的描述。
编码 阶段要保证开发人员在实际开发中终于架构所规定的结构，遵守组件之间交互的约定。
程序员对每一个模块编码之后先做单元测试，然后再进行集成（综合或组装）测试，系统测试，验收（确定）测试。其中单元测试的一部分已经在编码阶段就开始了。
在软件运行阶段对软件产品进行的修改就是维护，维护需要经历以下 4 个步骤：分析和理解程序，修改程序，重新验证程序 和 维护文档。
软件过程中的文档
没有文档的软件，不能称其为软件，更谈不上软件产品。软件文档的编写在软件开发工作中占有突出的地位和相当的工作量。
文档是软件开发人员、软件管理人员、维护人员以及用户之间的沟通平台，在他们之间起桥梁作用。
在软件开发过程中，软件文档涉及管理、开发、产品和质量保证等各方面。一般来说，至少应该产生 14 种文档：
- 可行性报告分析
- 项目开发计划
- 软件需求说明书
- 数据要求说明书
- 概要设计说明书
- 详细设计说明书
- 数据库设计说明书
- 用户手册
- 操作手册
- 模块开发卷宗
- 测试计划
- 测试分析报告
- 开发进度月报
- 项目开发总结报告
image.png
可行性研究报告
写作要求：
- 可行性研究的目的是用较小的代价在尽可能短的时间内确定“问题是否能够解决”
- 一般来说，可行性研究的成本只占预期工程成本的 5% ~ 10%
- 可行性研究由项目负责人或企业售前部门的相关人员撰写，企业或项目的架构设计人员也要参加
- 可行性研究报告的读者是投资者、客户、上级领导、设计师和需求分析师
- 可行性研究报告应说明软件产品的目标。目标就是这一软件系统为了“解决用户的哪些问题”。
- 可行性分析侧重对经济、技术和法律等方面是否可行做出判断，而经济可行性是项目立项前提，因此成本/绩效分析是关键。
- 常用的费用估计方法有两种：
- 代码行技术。
- 任务分解技术。
项目开发计划
- 编写项目开发计划的目的是用文件的形式，把开发过程中各项工作的参与人员、开发进度、所需经费预算、所需软硬件条件等作出的安排并记录下来，以便根据本计划检查项目的开发工作
- 项目的开发计划由项目负责人撰写，项目的架构设计人员也要参加；项目开发计划的读者是投资者、客户、上级领导、项目经理、设计师、需求分析师、开发人员、测试人员、质量保证人员和配置管理人员等。
- 项目计划就是把每个小组或每个人要完成的工作和时间清晰的语言描述出来，要有明确的陈述、可以衡量的结果、可以达成的目标，并且是合理和可跟踪的，使项目团队每一个成员都有明确的概念。
软件需求说明书
需求有三个层次：
- 业务需求
- 用户需求
- 软件需求
业务需求从总体上描述了为什么要开发系统（Why），组织希望达到什么目标，一般在可行性研究报告中反映。
用户需求描述了用户能使用系统来做什么（What），这个层次的需求非常重要，它是需求阶段的主要产物。用户需求主要具有以下特点：
- 零散。用户提出不同角度、不同层次、不同粒度的需求，而且常常以一句话的形式提出。
- 相互矛盾。由于不同用户处于企业/组织的不同层面，可能会出现盲人摸象的情况，导致需求的片面性。
因此，还需要对原始的用户需求进行分析和整理，从而得出更加精确的需求说明。用例是表达用户需求的一种有效途径。
软件需求是需求的主题，它是分析人员对用户需求的分析、提炼、整理，从而生成的课指导开发的、更精确的产物。
软件需求分为功能需求、质量需求、约束条件三种类型，其中，质量需求和约束条件也叫做非功能需求。
功能需求规定必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务续期。
质量需求不同于产品的功能描述，它从不同方面描述产品的各种特性。这些特性包括可用性、可移植性、性能、安全等。
约束条件限制了架构师设计和构建系统时的选择范围，约束条件一般有五种：
- 非技术因素决定了技术选型
- 预期的运行环境
- 预期的使用环境
- 社会限制
- 法律限制
image.png
软件架构文档
- 架构设计的重点在于根据系统的不同视角和对质量的要求，设计出系统的不同结构，通常最主要的结构是将系统分层并产生层次内的模块，阐明模块之间的关系。
- 架构设计的一个核心内容就是公共可复用组件的抽取和识别，包括功能组件和技术组件。
- 复用是架构价值体现的另一个关键点。
概要设计说明书
- 概要设计根据架构设计的内容对每个子系统或模块的设计进一步细化，概要设计的重点在于模块分解为对象并阐明对象之间的关系。
- 架构设计在系统级，而概要设计在子系统或模块系统。
- 概要设计对于核心的业务逻辑必须要设计清楚，说明实现的机制和方法。
- 概要设计要达到一个目的，就是不论是谁根据概要设计来做，最终实现出来的模块都不会走样，模块最终实现出来能基本满足对质量的要求，也能满足功能的要求。
- 概要设计要将软件需求分配给所划分的最小单元模块（类），确定模块与模块之间的关系。
详细设计说明书
- 详细设计是概要设计的下一步，其主要任务是根据概要设计提供的文档，确定每一个模块的算法，内部的数据结构。详细设计的重点在于将模块的对象分解为属性和方法，并阐述如何实现。
- 详细设计的目的是为软件结构图中的每一个模块或类结构图中的每一个方法确定使用的算法和数据结构，并用某种选定的表达工具给清晰的描述。
- 程序流程图又被称为程序框图，它是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言，比较直观和清晰地描述过程的控制流程。
数据库设计说明书
- 数据通常存放在数据库中，数据库设计是系统设计的重要环节，数据要求和数据结构最终都要和数据库的表结构对应起来
- 数据库设计人员进行数据库设计时，根据需求文档，创建与数据库相关的实体关系（E-R）图
- 一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束
- 对表结构进行规范化处理（第三范式）
测试概述
- 在程序员对模块的编码完成之后先做程序测试，在做单元测试，然后再进行集成（综合或组装）测试，系统测试，验收（确认）测试，其中单元测试的一部分在编码阶段就开始了。测试横跨开发与测试两个阶段。
- 测试的目标是为了发现程序中的错误而执行程序的过程。
- 测试的原则
- 测试之前要认定被测试软件有错，不要认为软件没有错
- 要预先确定被测试软件的测试结果
- 要尽量避免测试自己编写的代码
- 测试要兼顾合理输入与不合理输入数据
- 测试要以软件需求规格说明书为标准
- 要明确找到的新错与已找到的旧错成正比
- 测试是相对的，不能穷尽所有的测试，要根据人力物力安排测试，并选择好测试用例与测试方法
- 测试用例会反复使用，以重新验证纠错的程序是否有错
按照测试过程是否在实际应用环境中来分，测试技术分为
- 静态分析
- 动态测试
静态分析不执行被测软件，可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行找出软件错误。
动态测试是把程序作为一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出的值域之间的关系。
- 选取定义域中的有效值，或定义域外的无效值
- 对已选取值决定预期的结果
- 对已选值执行程序
- 观察程序行为，记录执行结果
- 将 ③ 的结果与 ② 的结果相比较，不符合则程序有错。
测试方法主要有 白盒法 和 黑合法。
白盒法是通过分析程序内部的逻辑与执行路线来设计测试用例并进行测试的方法，白盒法也称为逻辑驱动方法。
白盒测试法的前提是可以把程序看成一个透明（白色）的盒子，也就是完全了解程序的结构和处理过程。白盒测试又称为结构测试。
黑盒测试法是功能驱动法，把程序看成一个黑色（不透明）的盒子，仅根据数据的出入/输出来设计测试用例，而不管程序的内部结构和路径如何。黑盒测试也叫做功能测试。
测试的角色和职责
| 角色 | 职责 |
|---|---|
| 测试经理 | 指定测试计划 测试过程参与者 |
| 测试人员 | 编写测试用例 准备测试环境 执行测试计划 撰写测试结果 |
| 开发人员 | 单元测试 编写集成测试的实施类（包括驱动程序和测试桩），并对其进行单元测试 根据集成测试发现的缺陷提出变更申请 |
| SQA 代表 | 审查测试过程 |
| 客户 | 实施验收测试 验收产品 |
部属概述
部署过程是软件正式称为产品的重要一环，需要制定部属计划，经过评审确认可行，并通过光盘等媒介或通过网络发布出来，同时还要考虑授权认证机制，以维护相应的权益。
部属过程的角色和职责
| 角色 | 职责 |
|---|---|
| 项目经理 | 制定部属计划 验收过程参与者 |
| 开发者 | 编写安装手册 编写用户文档 打包软件 现场安装运行环境 |
| 培训者 | 编写培训资料 实施客户培训 |
| SQA代表 | 审查部属过程 |
| 客户 | 实施验收测试 验收产品 |
