软件开发概述

• 软件开发生命周期
  • 软件定义时刻：可行性研究和详细需求分析过程
  • 软件开发时期：设计与实现
  • 软件运行与维护：软件产品移交给用户使用
• 软件系统的文档
  • 用户文档：描述系统功能和使用方法
  • 系统文档：描述系统设计、实现和测试等
• 软件工程过程包括以下 4 方面活动
  • P Plan：软件规则说明
  • D Do：软件开发
  • C Check：软件确认
  • A Action：软件演进
• 软件系统工具
  • 软件开发工具
  • 软件维护工具
  • 软件管理和软件支持工具
• 软件设计四个活动
  • 数据设计
  • 架构（体系结构）设计
  • 人机界面（接口）设计
  • 过程设计

能力成熟模型

• 能力成熟度模型 CMM

• 能力成熟度模型集成 CMMI
  • 是若干过程模型的综合和改进，支持多个工程学科和领域
  • 两种表示方法
    • 阶段式，关注组织的成熟度
    • 连续式模型：关注每个过程域能力，一个组织对不同过程域可以达到不同的过程域能力等级

软件过程模型

• 瀑布模型 SDLC 将软件开发分为：可行性分析、需求分析、软件设计、编码、测试、运行维护
• 瀑布模型特点
  • 从上一项开发活动接受该项活动的工作对象作为输入
  • 实施该项活动应完成的工作内容
  • 该项活动的工作成果作为输出
  • 对该项活动的实施工作成果进行评审
• 螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与现行顺序（瀑布）模型中控制的和系统化的方面结合起来。软件开发是一系列增量发布
• 螺旋模型具有周期性重复的螺旋现状。每个周期分为四个阶段
  • 制订计划
  • 风险分析
  • 实施工程
  • 客户评估
• 螺旋模型强调了风险分析，适合庞大复杂的、高风险的系统
• V 模型特点
  • 单元测试针对编码过程
  • 集成测试针对详细设计
  • 系统测试针对概要设计
  • 验收测试
• V 模型适用于需求明确和需求变更不频繁的情形
• 原型化模型第一步就是创建一个快速原型，最终弄清楚当前系统的需求
• 原型应当具备的特点如下
  • 实际可行
  • 具有最终系统的基本特征
  • 构造方便、快速、造价低，特点在于原型法对用户的需求是动态响应的、逐步纳入的
• 增量模型：首先开发核心模块功能，优先级最高的服务先交付
• 增量模型特点
  • 不利于模块划分
  • 难点在于如何将需求划分为多个增量
  • 增量模型的每一次增量版本都是独立可交付的
• 喷泉模型：以用户需求为动力，以对象作为驱动，适用于面向对象
• 基于构件的开发模型 CBSD：使用预先包装的构件来构造应用系统。增强了复用性
• 形式化方法模型：建立在严格数学基础上
• 敏捷模型
  • 开发宣言：个体和交互胜过过程和工具，可以工作的软件胜过面面俱到的文档、客户合作胜过合作谈判、响应变化胜过遵循计划
  • 敏捷方法区别与其他方法的特点：适应性和面向人的
  • 核心思想
    • 适应性
    • 以人为本
    • 增量迭代式
• 主要敏捷方法
  • 极限编程 XP：交流、朴素、反馈和勇气。加强交流、从简单做起、寻求反馈、勇于实事求是
  • XP 是近螺旋式的方法，将复杂的开发过程分解为一个个相对简单的小周期。提倡测试现行
  • 水晶系列方法：以人为中心，每个都含有独特的角色、过程模式、工作产品和实践
  • 并列争球法 Scrum：把每段时间一次迭代称为一个冲刺 Sprint，并按需求优先级别实现产品
  • 特性驱动开发方法 FDD：迭代，软件开发三个要素：人、过程和技术；五个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建
• 统一过程模型 RUP，描述了如何有效利用商业、可靠的方法和部署软件，是一种重量级过程。为所有方面和层次的程序开发提供指导方针、模板以及事例支持
• RUP 开发生命周期是二维的软件开发模型，包含九个工作流
  • 业务建模
  • 需求
  • 分析与设计
  • 实现
  • 测试
  • 部署
  • 配置与变更管理
  • 项目管理
  • 环境
• RUP 将软件开发的生命周期划分为多个循环，每个循环依次由 4 个连续阶段组成：
  • 初始阶段：确定系统范围
  • 细化阶段：确定系统体系结构
  • 构造阶段：构造产品并继续演进需求
  • 移交阶段：提交给用户使用
• RUP 核心概念
  • 角色：Who 的问题
  • 活动：How 的问题
  • 制品：What 的问题
  • 工作流：When 的问题
• RUP 特点：
  • 用例驱动
  • 以体系结构为中心。多维结构多个视图描述，在典型的 4+1 视图模型中
    • 分析人员和测试人员：用例视图
    • 最终用户：逻辑视图
    • 程序员：实现视图
    • 系统集成人员：进程视图
    • 系统工程师：部署视图
  • 迭代与增量，分为多个迭代过程

逆向工程

• 软件复用是将已有软件的各种知识用于建立新的软件，以所建软件开发和维护的花费。早期为代码级复用，后来扩大到领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面
• 逆向工程：分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，是设计的恢复过程。四个级别：
  • 实现级
  • 结构级
  • 功能级
  • 领域级
  • 领域级别抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高
• 相关概念
  • 重构：在同一抽象级别上转换系统描述形式
  • 设计恢复：从已有程序中抽象出有关数据设计
  • 再工程：在逆向工程获得信息的基础上，修改或者重构已有系统、产生系统的一个新版本。是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程
  • 正向工程是使用该信息去改变或重构现有系统

软件需求

• 指的是用户对系统在功能、行为、性能、设计约束等方面的期望，指用户解决问题或者达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或者其他正式规定文档所需具有的条件或能力
• 分为需求开发和需求管理两大过程
  • 需求开发：需求获取、需求分析、需求定义（需求规格说明书）、需求验证。得到需求基线
  • 需求管理：变更控制、版本控制、需求跟踪、需求状态跟踪
• 需求分类
  • 业务需求：企业或客户对系统高层次的目标要求
  • 用户需求：用户的具体目标、或用户要求系统必须能完成的任务，描述用户能用系统来做什么
  • 系统需求：从系统的角度来说明软件的需求，包含
    • 功能需求：开发人员必须在系统中实现的软件功能
    • 非功能需求：系统必须具备的属性或品质
    • 设计约束：对系统的一些约束说明

需求获取

• 是确定和理解不同的项目干系人的需求和约束的过程
• 常见的需求获取法
  • 用户访谈
  • 问卷调查
  • 采样
  • 情节串联板
  • 联合需求计划
  • 需求记录技术

需求分析

• 把杂乱无章的用户要求和期望转化为用户需求
• 任务
  • 绘制系统上下文范围关系图
  • 创建用户界面原型
  • 分析需求的可行性
  • 确定需求的优先级
  • 为需求建立模型
  • 创建数据字典
  • 使用 QFD（质量功能部署）
• 结构化的需求分析
  • 结构化特点：自顶向下、逐步分解、面向数据
  • 三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（ER 图）和数据字典
  • 数据流图 DFD：基本元素：外部实体、加工、数据存储和数据流
    • 
    • 数据流：数据流的流向必须经过加工
    • 加工：常见的三种错误：有输入无输出，有输出无输入、输入不足以产生输出
    • 数据存储：用来存储数据
    • 外部实体：存在于软件系统之外的人员或组织
  • 数据字典 DD
    • 数字字典是为数据流图中的每个数据流、文件、加工，以及构成数据流或文件的数据项做出说明
    • 有以下四个类目：数据流、数据项、数据存储和基本加工
    • 加工逻辑称为小说明，描述方法有 结构化语言、判定表和判定树

需求定义

• 需求定义（软件需求规格说明书 SRS）是整个开发工作的基础
• 需求定义方法
  • 严格定义：结构化定义，建立在以下基本假设之上：所有需求都能被预先定义
  • 原型方法：迭代的循环型开发方式，提供了克服项目干系人之间存在的交流上的困难

需求验证

• 与用户一起确认需求无误。包含两个步骤
  • 需求评审：正式评审和非正式评审
  • 需求测试：设计概念测试用例
• 需求规格说明书就是需求基线

需求管理

• 
• 需求变更流程
• 需求变更和风险，带有风险的做法有
  • 无足够用户参与
  • 忽略用户分类
  • 用户需求不断增加
  • 模棱两可的需求
  • 不必要的特性
  • 过于精简的 SRS
  • 不准确的估算
• 变更产生的原因：外部环境变化、需求和设计做到不够完整、新技术的出现、公司机构重组造成业务流程的变更
• 变更控制委员会 CCB
• 需求跟踪：双向跟踪，要求实现需求不多不少
  • 正向跟踪表示用户原始需求是否都实现了
  • 反向跟踪表示软件实现是否都是用户要求的

流程处理设计

• 流程表示工具
  • 程序流程图 PFD：顺序、选择和循环结构
  • IPO 图，描述模块的输入、输出和数据加工
  • N-S 图：不适合复杂程序的设计
  • 问题分析图 PAD：支持结构化程序设计
• 业务流程重组 BPR：对业务流程进行根本性的再思考和彻底性的再设计。设计原则、系统规划和步骤如下
• 业务流程管理 BPM：以规范化的构造端到端的卓越业务流程为中心，提高组织业务绩效为目的
• BPM 和 BPR 最根本的不同在于不要求对所有的流程进行再造，而是根据了流程的具体清空，对流程进行规范化设计
• BPM 包含三个层面：规范流程、优化流程和再造流程

系统设计

• 主要目的：勾画出新系统的详细设计方法
• 设计方法：结构化设计方法、面向对象设计方法
• 主要内容：==概要设计、详细设计==
  • 概要设计基本任务：系统总体结构设计，形成软件的模块结构图，即系统结构图
  • 详细设计的基本任务：模块内详细算法设计、模块内数据结构设计、数据库物理设计、其他设计（代码、输入输出格式、用户界面）
• 基本原理：抽象化、自定而下逐步求精、信息屏蔽、模块独立（高内聚低耦合）
• 原则：模块大小适中、减少调用深度、多扇入少扇出、单入口单出口、模块作用域保持在模块内、功能可预测
• 系统设计基本原理：抽象、模块化、信息屏蔽、模块独立
• 衡量模块独立程度的标准有两个：耦合性和内聚性。==内聚程度从低到高==
  • 偶然内聚：无直接关系
  • 逻辑内聚：逻辑相似、参数决定
  • 时间内聚：同时执行
  • 过程内聚：指定的过程顺序
  • 通信内聚：相同数据结构、相同输入输出
  • 顺序内聚：顺序执行、输入为输出
  • 功能内聚：共同作用、缺一不可
• ==耦合程度从低到高==：
  • 无直接耦合：无直接关系
  • 数据耦合：传递数据值调用
  • 标记耦合：传递数据结构
  • 外部耦合：通过软件外部环境联合
  • 公共耦合：通过公共数据环境联合
  • 内容耦合：直接使用模块内部数据

人机界面设计

• 三大原则：置于用户控制之下、减少用户的记忆负担、保持界面的一致性

测试原则和方法

• 为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试
• 测试原则：
  • 尽早并不断地进行测试
  • 避免有原开发软件的人或小组承担
  • 设计测试方案时，不仅要确定输入数据，要根据系统功能确定预期的输出结果
  • 既包含有效的、合理的测试用例，也包含不合理的、失效的用例
  • 检验程序是否做了该做的事，且是否做了不该做的事
  • 严格按照测试计划进行
  • 妥善保存测试计划和测试用例
  • 测试用例可以重复使用或追加测试
• 测试方法：静态测试和动态测试
  • 静态测试：不在机器上进行，采用人工检测和计算机辅助静态分析的手段，以检查单的形式。对代码的静态测试，包括桌前检查、代码审查、代码走查
  • 动态测试：实际运行程序，包含黑盒测试法和白盒测试法
    • 黑盒：功能性测试
    • 白盒：结构性测试
• 测试阶段
  • 单元测试：模块测试，对象是可独立编译或者汇编的程序模块，测试依据是软件详细设计说明书
  • 集成测试：检查模块之间、以及模块和已集成的软件之间的接口关系。依据是软件概要设计文档
  • 确认测试：验证软件功能、性能和其他特性是否与用户需求一致。包含以下类型
    • Alpha 测试：用户在开发环境下
    • Beta测试：用户在实际使用环境
    • 验收测试：针对 SRS，在交付前以用户为主进行的测试
  • 系统测试：测试对象是完整的集成的计算机系统，依据是用户需求或开发合同
  • 配置项测试：测试对象是软件配置项，目的是检验软件配置项与 SRS 的一致性
  • 回归测试：测试软件变更后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性
• 测试策略
  • 自底向上：从最底层模块开始测试，需要编写驱动程序，较早验证了底层模块
  • 自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块，较早验证了系统的主要控制点和判断点
  • 三明治：二者都包括，缺点是测试工作量大

测试用例设计

• 黑盒测试用例，分为下面几类
  • 等价值划分：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类。设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类
  • 边界值划分：边界值一般以范围的两端值以及在此范围之外的与此范围间隔最小的两个值
  • 错误推测：凭经验
  • 因果图：由结果反推原因
• 白盒测试用例
  • 语句覆盖 SC：所有语句都要执行一遍，覆盖层次最低
  • 判定覆盖 DC：所有判断语句的条件的真假分支都要覆盖一次
  • 条件覆盖 CC：每一个独立条件都要执行一遍真和假
  • 条件判定组合覆盖 CDC：同时满足判定覆盖和条件覆盖
  • 路径覆盖：所有可行路径都覆盖了，覆盖层级最高

调试

• 调试找出错误的代码和原因
• 确定错误的准确位置，确定问题的原因并设法改正，改正后进行回归测试
• 方法：蛮力法、回溯法、原因排除法

软件度量

• 软件两种属性
  • 外部属性：面向管理者和用户的属性，可直接测量，一般是性能指标
  • 内部属性：软件产品本身的属性，如可靠性，只能间接测量
• ==McCabe 度量法==
  • 计算环路复杂度
  • 有向图中边数为 m，节点数为 n，则环路复杂度为 m - n + 2

系统转换

• 遗留系统：不能进行修改和演化以满足新的变化了的业务需求的信息系统，特点
  • 不能完全满足要求
  • 技术已经过时
  • 维护工作十分困难
  • 很难理解
• 遗留系统处理
  • 技术水平高业务价值高：改造
  • 技术水平高业务价值低：集成
  • 技术水平低业务价值高：继承
  • 技术水平低业务价值低：淘汰
• 系统转换是新系统开发完毕，投入运行，取代现有系统的过程。有以下三种转换的计划
  • 直接转换：现有系统被新系统直接取代
  • 并行转换：新系统和老系统并行工作一段时间
  • 分段转换：分期分批逐步转换，将大型系统分为多个子系统
• 数据转换与迁移：三种方法
  • 系统切换前通过工具迁移
  • 系统切换前采用手工录入
  • 系统切换后通过新系统生成

系统维护

• 可维护性：维护人员理解、改正、改动和改进这个软件的难易程度。评价指标
  • 易分析性
  • 易改变性
  • 稳定性
  • 易测试性
  • 维护性的依从性
• 包括硬件维护、软件维护和数据维护。软件维护类型：
  • 正确性维护
  • 适应性维护
  • 完善性维护
  • 预防性维护

净室软件工程 CSE

• 应用数学与统计学理论以经济的方式生产高质量软件的工程技术。通过严格的工程化的软件过程达到开发中零缺陷或接近零缺陷
• 要求在规约和设计中消除错误，然后以 净 的方式制作
• 在第一次正确地书写代码增量，在测试前验证正确性
• 提倡开发这不进行单元测试
• 理论基础：函数理论和抽样理论
• 应用技术手段
  • 统计过程控制下的增量式开发
  • 基于函数的规范与设计
  • 正确性验证。核心
  • 统计测试和软件验证
• 缺点
  • 太理论化，需要更多数学知识，正确性验证步骤困难耗时
  • 开发小组不进行传统的模块测试，不现实
  • 带有传统软件工程的一些弊端

基于构件的软件工程 CBSE

• 基于分布对象技术，通过可复用构件设计与构造软件系统的软件复用途径
• 购买而不是重新构造，从程序编写转移到基于已有的构件组装
• 构件具备以下特征
  • 可组装性
  • 可部署性
  • 文档化
  • 独立性
  • 标准化
• 包含的模型要素
  • 接口
  • 使用信息
  • 部署
• 构件模型提供了一组被构件使用的通用服务，包括
  • 平台服务，允许构件在分布式环境下通信和互操作
  • 支持服务，很多构件都需要的共性服务。通常通过中间件
• 包含 6 个主要活动
  • 系统需求概览
  • 识别候选构件
  • 根据发现的构件修改需求
  • 体系结构设计
  • 构件定制与适配
  • 组装构件创建系统
• 与传统软件开发的不同点
  • 早期需要完整的需求
  • 可利用构件来细化和修改需求
  • 会有进一步对构件搜索及设计精化活动
  • 开发是将已经找到的构件集成在一起的组装过程
• 构件组装是用胶水代码将构件组装成系统或另一个构件。包含三种方式
  • 顺序组装，按顺序调用已经存在的构件
  • 层次组装，一个构件直接调用另一个构件所提供的服务
  • 叠加组装，两个及以上构件放在一起创建新构件
• 构件组装的三种不兼容
  • 参数不兼容
  • 操作不兼容
  • 操作不完备