软件设计师——软件工程

软件设计师备考笔记

上午题	下午题
计算机网络概述	数据流图设计（下午试题一）
程序设计语言基础知识	数据库设计（下午试题二）
标准化和知识产权	UML分析与设计（下午试题三）
数据库	面向对象程序设计与实现（下午试题六）
操作系统	算法设计与C语言实现（下午试题四）
结构化开发与方法
软件工程
网络与信息安全
数据结构
算法分析设计

1 软件工程概述

• 软件工程基本原理：用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清楚的审查、开发小组的人员应少而精、承认不断改进软件工程实践的必要性
• 软件工程的基本要素：方法、工具、过程
• 软件生存周期：可行性分析与项目开发计划、需求分析、概要设计（选择系统解决方案，规划子系统)、详细设计（设计子系统内部具体实现）、编码、测试、维护

2 软件过程

2.1 能力成熟度模型CMM

• 能力成熟度模型CMM：对软件组织化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高
  

2.2 能力成熟度模型CMMI

• 能力成熟度模型CMMI：将已有的几个CMM模型结合在一起，使之构造成为“集成模型”。支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率
• CMMI两种表示方法：
  • 阶段式模型：类似于CMM，它关注组织的成熟度，五个成熟度模型如下：
    
  • 连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级

2.3 统一过程UP

• 统一过程模型：是一种开发过程，特性如下：
  • 三大特点：用例和风险驱动、以架构为中心、迭代并且增量
  • 开发的四个阶段：
    • 起始（项目的初始活动，如确认需求和风险评估等）
    • 精化（需求分析和架构设计等)
    • 构建（系统的构建，产生实现模型等)
    • 移交（软件提交方面的工作，产生软件增量，进行β测试，交付系统等）
  • UP的每一次迭代都是一次完整的软件开发过程，包括整个软件开发生命周期，有五个核心工作流（需求、分析、设计、实现、测试)

3 软件过程模型

软件过程模型：即软件开发模型，是软件开发全部过程、活动和任务的结构框架

3.1 瀑布模型

• 瀑布模型(SDLC)：结构化方法中的模型，是结构化的开发，开发流程如同瀑布一般，一步一步的走下去，直到最后完成项目开发，只适用于需求明确或者二次开发(需求稳定)，当需求不明确时，最终开发的项目会错误，有很大的缺陷
  

3.2 V模型

• V模型：是瀑布模型的一个变体。特点是增加了很多轮测试，并且这些测试贯穿于软件开发的各个阶段，不像其他模型都是软件开发完再测试，很大程度上保证了项目的准确性。V模型开发和测试级别对应如图：
  

3.3 演化模型

3.3.1 原型模型

• 原型模型：即快速原型开发，与瀑布模型相反，原型针对的就是需求不明确的情况，首先快速构造一个功能模型，演示给用户看，并按用户要求及时修改，中间再通过不断的演示与用户沟通，最终设计出项目，就不会出现与用户要求不符合的情况，采用的是迭代的思想
  

3.3.2 螺旋模型

• 螺旋模型：是多种模型的混合，针对需求不明确的项目，与原型类似，但是增加了风险分析，这也是其最大的特点
• 四步：制定计划——风险分析——实施工程——用户评估
  

3.4 增量模型

• 增量模型：首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付
• 特点：但由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示
  

3.5 其他模型

• 喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性
• 基于构件的开发模型CBSD：利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件
  • 特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用,因此可以提高可靠性,节省时间和成本
• 形式化方法模型：建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明

3.6 软件开发方法

• 结构化方法：流程固定，针对需求明确的项目，自顶向下，逐层分解，面向数据流。将数据流映射为软件系统的模块结构，数据流类型包括变换流型和事务流型，不同类型的数据流有不同的映射方法。以瀑布模型为代表，一旦开发完成，将难以修改，不利于复用及后续版本的开发，现在被面向对象法给代替了
  • 结构化方法的设计：
    • 体系结构设计是宏观架构设计
    • 数据设计是数据流的设计
    • 接口设计关注模块间的连接设计
    • 过程设计是模块内的具体实现过程的数据结构和算法的设计
• Jackson方法：面向数据结构的开发方法，适合于小规模的项目
• 原型方法：适合于需求不明确的开发，以原型模型为代表
• 面向对象方法：强调复用性，构建全面合理的模型供不同项目使用，方便修改，节省开发时间和效率，增强复用性，以构件组装模型为代表

3.7 敏捷开发

• 针对中小型项目，主要是为了给程序员减负，去掉一些不必要的会议和文档。指代一组模型（极限编程、百适应并发、水晶方法……），这些模型都具有相同的原则和价值观，具体如下图(要求对该图眼熟，并掌握重要概念）
  
• 开发宣言：
  • 个体和交互胜过过程和工具
  • 可以工作的软件胜过面面俱到的文档
  • 客户合作胜过合同谈判
  • 响应变化胜过遵循计划
• 结对编程：一个程序员开发，另一个程序在一旁观察审查代码，能够有效的提高代码质量，在开发同时对代码进行初步审查，共同对代码负责
• 自适应开发：强调开发方法的适应性(Adaptive)。不像其他方法那样有很多具体的实践做法，它更侧重为软件的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性
• 水晶方法：每一个不同的项目都需要一套不同的策略、约定和方法论
• 特性驱动开发：是一套针对中小型软件开发项目的开发模式。是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目
• 极限编程XP：核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低
• 并列争球法SCRUM：是一种迭代的增量化过程，把每段时间(30天) 一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品多个自组织和自治的小组并行地递增实现产品

4 软件工具与软件开发环境

4.1 软件工具

• 软件开发工具：对于于软件开发过程的各种活动。包括需求分析工具、设计工具、编码与排错工具、测试工具
• 软件维护工具：辅助软件维护过程中活动的软件，辅助维护人员对软件代码及其文档进行各种维护活动。包括版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具
• 软件管理和软件支持工具：辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质量的完成。包括项目管理工具、配置管理工具、软件评价工具

4.2 软件开发环境

• 软件开发环境：指支持软件产品开发的软件系统，由软件工具集和环境集成机制构成。工具集用于支持软件开发的相关过程、活动和任务；环境集成机制为工具集成和软件开发、维护和管理提供统一的支持
• 开发支持环境（环境信息库，过程控制和消息服务，用户界面规范)
  

5 软件项目管理

有效的项目管理集中在4P上：人员、产品、过程、项目

5.1 软件项目估算

5.1.1 成本估算方法

• 自顶向下估算：又称类比估算法，确定一个总金额，再向下分摊到每一个功能点
• 自底向上估算：从底层功能点开始估算成本，向上累加
• 差别估算法：与以前项目比较，找出不同点重新估算，相同点则直接估算
• 专家估算：聘请专家以其经验对项目整体费用进行估算

5.1.2 COCOMO估算模型

• COCOMO模型：常见的软件规模估算方法。常用的代码行分析方法作为其中一种度量估计单位，以代码行数估算出每个程序员工作量，累加得软件成本
• 模型按其详细程度可以分为三级：
  • 基本COCOMO模型：是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量
  • 中间COCOMO模型：在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算
  • 详细COCOMO模型：包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响
• COCOMOⅡ模型：COCOMO的升级，也是以软件规模作为成本的主要因素，考虑多个成本驱动因子。该方法包括三个阶段性模型：
  • 应用组装模型（软件工程前期阶段使用）
  • 早期设计阶段模型（需求已经稳定并且基本的软件体系结构已经建立时使用）
  • 体系结构阶段模型（软件的构造过程中使用）

5.1.3 Putnam估算模型

• Putnam估算模型：一种动态多变量模型，假设在软件开发的整个生存周期中工作量有特定的分布

5.2 进度管理

• 基本原则：划分、相互依赖、时间分配、工作量确认、确定责任、明确输出结果、确定里程碑

• Gantt图：又称为横道图，横轴表示时间，纵轴表示活动，以时间顺序表示活动，能反应活动间的并行关系，但无法反应活动之间的依赖关系，因此也难以清晰的确定关键任务和关键路径
  

• PERT图：类似于前趋图，是有向图，反应活动之间的依赖关系，有向边上标注活动运行的时间，但无法反应活动之间的并行关系
  

• 关键路径重要概念：

  • 最早开始时间ES：取所有前驱活动最早完成时间EF的最大值
  • 最早完成时间EF：最早开始时间ES + 活动本身时间DU
  • 关键路径(项目总工期)：项目中耗时最长的一条线路
  • 最晚完成LF：取后续活动最晚开始时间的最小值
  • 最晚开始时间LS：最晚完成LF - 活动本身时间DU
  • 松弛时间：某活动的最晚开始时间 - 最早开始时间（或最晚完成时间 - 最早完成时间），也即该活动最多可以晚开始多少天

5.3 软件项目的组织

• 组织结构模式：项目型(项目经理绝对领导)、职能型（部门领导为主)、矩阵型(二者结合，既有项目经理也有部门领导，但权利分割不同)。
• 程序设计小组的组织方式：
  • 主程序员制小组：主程序员全权负责，后援工程师必要时能替代主程序员，适合大规模项目
  • 民主制小组：也即无主程序员小组，成员之间地位平等，任何决策都是全员参与投票，适合于项目规模小，开发人员少，采用新技术和确定性较小的项目
  • 层次式小组：两个层次，一名组长领导若干个高级程序员，每个高级程序员领导若干个程序员

5.4 软件配置管理

• 基线：软件开发过程中特定的点，是项目生存期各开发阶段末尾的特定点，又称为里程碑，反应阶段性成果
• 软件配置项：是软件工程中产生的信息项，是配置管理的基本单位
  • 软件开发过程中的所有文档、代码、工具都可作为配置项，主要包括六种类型：
    • 环境类（系统开发环境)
    • 定义类（需求分析与系统定义阶段)
    • 设计类（设计阶段）
    • 编码类（编码及单元测试阶段)
    • 测试类（系统测试完成后的工作）
    • 维护类（维护阶段）
    • 即产品组成部分的工作成果 + 项目管理和机构支撑过程域产生的文档
  • 版本控制：即软件配置项的版本控制，配置项有三个状态：草稿、正式、修改。如下：
    
• 版本命名规则：
  
• 变更控制：软件开发过程中的每一次修改都要纳入变更，以防止版本混乱，需要用到基线和配置数据库的概念。配置数据库分为下面三种：
  • 开发库。专供开发人员使用，其中的信息可能做频繁修改，对其控制相当宽松
  • 受控库。在生存期某一阶段工作结束时发布的阶段产品，这些是与软件开发工作相关的计算机可读信息和人工可读信息。软件配置管理正是对受控库中的各个软件项进行管理，受控库也称为软件配置库
  • 产品库。在开发的软件产品完成系统测试后，作为最终产品存入产品库，等待交付用户或现场安装

5.5 风险管理

• 软件风险两个特性：不确定性（可能发生也可能不发生)、损失（发生会产生恶性后果）
• 项目风险威胁到项目计划，如果项目风险发生，有可能拖延项目的进度和增加项目的成本。指预算、进度、人员、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素
• 技术风险威胁到要开发软件的质量和交付时间，如果技术风险发生，开发工作就变得很困难或者不可能，指设计、实现、接口、验证和维护等方面的潜在问题。此外，规格说明的歧义性、技术的不确定性、技术陈旧以及“前沿”技术也是技术风险因素
• 商业风险威胁到要开发软件的生存能力，包括下面五种：
  • 市场风险。开发了一个没有人真正需要的优良产品或系统
  • 策略风险。开发的产品不再符合公司的整体商业策略
  • 销售风险。开发了一个销售部门不知道如何去销售的产品
  • 管理风险。由于重点的转移或人员的变动而失去了高级管理层的支持预算风险。没有得到预算或人员的保证

5.5.1 风险管理的过程

• 风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表
• 风险预测：又称为风险估计，从两个方面预测风险，即风险可能发生的概率和风险发生产生的后果，因此有风险曝光度 = 风险发生的可能性 * 风险发生会带来的损失
• 风险评估：定义风险参照水准，将识别出来的风险评估分类
• 风险控制：辅助项目组建立处理风险的策略，包括风险避免、风险监控、RMMM计划（风险缓解、监控和管理计划）

6 软件质量管理

6.1 软件质量特性

• ISO/IEC9126软件质量模型：质量特性和子特性
  
• McCall质量模型
  • 三个方面，11个质量特性
  • 给出了三层框架模型：质量特性、评价标准、度量指标
    

6.2 软件质量保证

• 3个要点：
  • 软件必须满足用户需求，与用户需求不一致的软件无质量可言
  • 软件应遵循规定的一系列开发标准，不遵循这些准则的软件，其质量难以得到保证
  • 软件还应满足某些隐含的需求（如可理解性、可维护性，未明确写在用户需求中）
• 7个任务：
  • 应用技术方法（把软件质量设计到产品中而非事后保证)
  • 正式的技术评审
  • 测试软件
  • 标准的实施（遵循标准)
  • 控制变更
  • 度量（收集软件度量)
  • 记录保存和报告

6.3 软件容错技术

• 通常将质量理解为用户满意程度，为了使用户满意有两个必要条件：
  • 设计的规格说明书符合用户标准，称为设计质量
  • 程序按照设计规格说明书所规定的情况正确执行，称为程序质量
• 设计质量评审、程序质量评审
• 容错就是软件遇到错误的处理能力，实现容错的手段主要是冗余，包括下面四种冗余技术：
  • 结构冗余：
    • 静态（通过表决和比较，少数服从多数）
    • 动态（多重模块待机备份，故障时切换备份机）
    • 混合冠余（二者综合）
  • 信息冗余：为检错和纠错在数据中加上一段额外的信息，例如校验码原理
  • 时间冗余：遇到错误时重复执行，例如回滚，重复执行还有错，则转入错误处理逻辑
  • 冗余附加技术：冗余附加技术是指为实现结构、信息和时间冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等

7 软件度量

• 软件的两种属性：
  • 外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标
  • 内部属性指软件产品本身的的属性，如可靠性等，只能间接测量
• McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m - n + 2
  • 注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点