【软件设计师-中级】#软件工程上

CMM和CMMI

1）初始级（Intial） 软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用 2）可重复级（Repeatable） 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。 3）已定义级（Defined） 管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。 4）已管理级（Managed） 制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。 5）优化级（Optimized） 加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

软件过程模型

瀑布模型适合以文档作为驱动，客户需求很明确情况下的开发，缺点是需求和设计错误往往后期才会发现。风险控制能力弱，项目常常延期，难以适应变化的需求。

增量模型强调每一个增量均发布一个可操作的产品，第一个增量往往是核心的产品，最高优先级的功能先交付。第一个版本交付时间少可减少用户需求的变更，同时因为增量表示的小系统风险不大。需要对用户的变更要求进行规划，不规划管理成本复杂性可能会超出组织能力。

原型模型适合用户需求不清，需求经常变化的情况，不复杂规模不大的情况下采用该方法比较好。快速低成本的构建一个原型，后续在原型基础上进行演化。

螺旋模型大规模团队进行项目开发，每一个循环都包含了风险控制，容易接受新需求并迭代。适用于庞大、复杂并且高风险的软件开发，但是需要开发人员有相当丰富的风险判断经验，迭代次数过多也容易出现延迟提交时间问题

喷泉模型是以用户需求为动力，以对象来驱动的模型，适合面向对象的开发方法。具有迭代性和无间歇性，活动之间没有明显的边界，允许交叉进行，可提高效率节省开发时间。但是由于开发过程重叠，需要更多的开发人员，不利于项目的管理

统一过程（UP）模型

1）起始阶段（Inception Phase） 起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型以及一个或多个原型（需要时）。 2）精化阶段（Elaboration Phase） 精化阶段在理解了最初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（包括非功能需求）、分析模型、软件体系结构描述、可执行的软件体系结构原型、初步的设计模型、修订的风险列表、项目计划（包括迭代计划、调整的工作流、里程碑和技术工作产品）以及初始用户手册。 3）构建阶段（Construction Phase） 构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、软件构件、集成的软件增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）。 4）移交阶段（Transition Phase） 移交阶段专注软件提交方面的工作，产生软件增量，产生的主要工作产品有提交的软件增量、综合用户反馈等

4各技术阶段由四个里程碑所终止

初始阶段：生命周期目标 精化阶段：生命周期架构 构建阶段：初始运作功能 移交阶段：产品发布

极限编程（XP）

XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。 4大价值观：沟通、简单性、反馈和勇气。 5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。 12个最佳实践：计划游戏（快速制定计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40个小时、现场客户和编码标准。

水晶法 认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要影响

并列争求法 使用迭代的方法，把每30天一次的迭代称为一个”冲刺“。

ASD自适应软件开发 有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，重做和做同样关键

敏捷统一过程AUP 采用在“大型上连续，在小型上迭代”的原理构建系统。采用经典UP阶段性活动

需求判断

判断需求属于哪一类的需求：如功能需求就是软件要会做什么；性能需求是多少时间内完成什么，响应时间；数据需求是数据的准确性和精度，数据的格式；可靠性需求是死机了最短恢复时间

系统设计

概要设计 设计软件的总体结构：将复杂系统划分为模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口。然后是数据结构和数据库设计，数据库概念设计、逻辑设计、物理设计，编写概要设计文档。

详细设计 对每个模块进行算法设计对算法进行描述，设计数据结构，对数据库进行物理设计，进行完后进行编写详细设计说明书。一系列的系统设计文件是详细设计的最终产出

软件测试

系统测试的测试目标来源于需求分析

黑白盒测试

常见黑盒测试有等价类划分、边界值分析、错误推测、因果图

等价类划分中，不好的测试用例一般是两个参数都是违规参数

边界值分析 ①如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 ②如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数据作为测试数据。 ③根据规格说明的每个输出条件使用上述两条原则。 ④如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

Macabe度量法只要数程序中的环路就可以了，当然也可以用公式：边数-节点数+2

白盒测试常见的方式是逻辑覆盖：语句覆盖<判定覆盖<条件覆盖<判定条件覆盖<路径覆盖，依据程序的内部逻辑进行测试

语句覆盖保证每条语句至少被执行一次，这意味着有条件分支的时候不能有跳过语句的情况 判定覆盖保证每个条件语句至少获得一个真值和假值，这意味着每个条件语句的出度都走过一次 条件覆盖保证每个条件语句中的每个布尔表达式中至少获得一个真值和假值 判定条件覆盖同时有判定覆盖和条件覆盖，是两种覆盖的组合 条件组合覆盖保证每个条件语句条件的各种可能值的组合至少出现一次，这意味着有条件语句中有几个布尔表达式就有2的几次方个组合 路径覆盖保证所有可能的路径都被覆盖，不漏掉每一个路径

测试用例的数量判断是选择题的重点

软件运维

可维护性三大指标：可理解性、可测试性、可修改性。软件文档是软件可维护性的决定性因素，必须在开发阶段就考虑保证软件有可维护性特点，在其他阶段提高可维护性。

软件代码修改时也要体现在文档的对应修改上，不然会出现重大问题

软件维护

正确性维护：改正系统开发阶段已经发生而系统测试阶段并未发现的错误。 适应性维护：应用软件为了适应技术信息变化或需求变化而进行修改 完善性维护：为扩充功能和改善性能进行修改，占维护阶段最大成分 预防性维护：提高软件的可靠性和可维护性，为了适应未来的变化进行改变

可靠性、可用性、可维护性是软件的质量属性，分别用MTTF/(1+MTTF)、MTBF/(1+MTBF)、MTTR/(1+MTTR)来表述这三种属性。全称分别为mean time to Faliure、mean time between Failure、mean time to Repair

软件开发图

甘特图作为任务管理地工具，可以清晰地描述任务开始和结束时间，但是无法清晰的获得每个任务之间的依赖关系

PERT图最早时刻表示在此时刻之前从该事件出发的任务不可能开始；最迟时刻表示从该事件出发的任务最杀必须在此时刻开始，否则整个工程就不能如期完成。每个任务还可以有个松弛时间(Slack Time),表示在不影响整个工期的前提下完成该任务有多少机动余地。最迟时间-最早时间=松弛时间

做题时累加路径上的数，当存在两个出度箭头指向同一节点，取最大的路径替换上去，计算出最早开始时刻。要计算最晚开始时刻的话需要先求出关键路径，然后从最后节点的最晚开始时刻往前推

项目活动图转换

软考中的项目活动图有些不会直接画出来，而是提供一个表格，需要自己按照表格内容进行活动图的绘制。 表格会给出活动编号，项目时间以及直接前驱，项目时间就是节点后面那个出度箭头上的数字