软件设计基础：5. 系统开发基础

1.软件工程概述

1.1信息系统的基本生存周期

说到生命周期，很多开发人员并不清楚是什么，即使是从业多年的老工程师也不一定熟悉，可能只是有听过。它实际是是指软件从出生到死亡的整个过程，下面简单介绍以下生命周期：

• 系统规划：即可行性分析阶段，在这个阶段，确定系统的目标和范围，进行初步的需求分析和可行性研究。

• 系统分析：即需求分析阶段，在这个阶段，详细地了解和分析用户的需求，确定系统的具体功能和性能要求。

• 系统设计：系统设计包括概要设计和详细设计，在这个阶段，根据系统分析的结果，设计出系统的架构、模块、接口等，形成系统设计文档。

• 系统实现：即编码阶段，在这个阶段，根据系统设计文档，编写程序代码，进行简单测试。

• 系统测试：即测试阶段，在这个阶段，对整个系统进行测试，确保系统的功能和性能都满足设计要求。

• 系统部署：即实施阶段，在这个阶段，将系统安装到用户的环境中，进行系统的配置和调试。

• 系统维护：在这个阶段，对系统进行运行维护，包括故障排除、性能优化、功能升级等。

• 系统废弃：这个阶段是很多人无法想象和理解的，软件开发起来就是为了使用，废弃是为什么？如果有bug，修改就是了。如果功能不足，升级就是了，为什么有个废弃的说法？实际上，当系统无法满足新的需求，修修补补已经没办法满足需要的时候，或者有更好的替代系统时，会进行系统的废弃。在这个阶段，需要对系统进行数据迁移，然后关闭系统。

以上每个阶段都需要明确的目标，详细的计划，以及充分的资源和时间。

1.2软件过程改进

1.2.1CMM能力成熟度模型

通俗一点理解，就是你的软件的可维护性和可拓展性。软件开发之后，如果有拓展，拓展是否简单？代码维护是否便捷。成熟的软件稳定，拓展新的功能非常快，又安全，维护成本低。
百度百科的介绍如下：CMM（Capability Maturity Model，能力成熟度模型）是由美国卡内基梅隆大学的软件工程研究所（SEI）提出的一种评估和改进软件开发过程的模型。该模型将软件开发过程的成熟度划分为五个级别，每个级别都有一系列的过程区域，这些过程区域描述了达到该级别的必要条件。

五个级别分别是：

1. 初始级（Initial）：工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一旦离去，工作秩序面目全非。过程不可预测、控制较差，结果取决于个人努力。简单理解就是想到什么立刻动手去做，没有经过深思熟虑，这样的软件产品往往经常返工，开发效率低，且该开发人员不在岗则软件产品极难维护。
2. 可管理级（Managed）：管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有复现以前成功项目的环境和条件。过程已被明确并得到管理，但仍然依赖个人。这个层级开发有一定的管理，大致实现了需求分析-软件设计-软件开发的流程。据了解，大部分公司的能力成熟模型都停留在这一步。可管理级，即有一定的管理。但是这种管理还停留在初始阶段。
3. 已定义级（Defined）：过程已被明确、标准化，并在整个组织中得到应用。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。标准化！已定义级归纳说来就是标准化。这个是一种完全、专业化的管理。已定义级就是可管理级的深化，最大限度地管理，将效率推到最高，将各个环节专业化达到最高。
4. 量化管理级（Quantitatively Managed）：过程已被量化，能够进行详细的度量和控制。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，及时纠正。什么是量化？就是工作可以被衡量。开发大概要投入多少人/天可以被计算评估出来，软件是否合格有可以测量的标准等等。在已定义级的基础上，会用到各种专业的辅助软件和辅助模块，比如自动化测试，单元测试，CI/CD持续集成等等。这些辅助模块的使用，会更加便捷和精确地提升软件质量，使整个开发过程量化。
5. 优化级（Optimizing）：过程持续改进，根据量化反馈进行调整和适应。可通过采用新技术、新方法，集中精力改进过程。具备防缺陷、识别薄弱环节以及改进的手段。可取得过程有效性的统计数据，并可据此进行分析，从而得出最佳方法。这个阶段不是CMM地终极阶段，是一种软件没有bug去找bug的阶段。

CMM模型不仅可以用于评估一个组织的软件开发过程成熟度，还可以作为改进软件开发过程的指南。

1.2.2CMM连续式能力成熟度模型

这个了解一下就可以

• CL0（未完成的）：过程域未执行或未得到目标。
• CL1（已执行的）：可标识的输入工作产品转换乘可标识的输出工作产品。
• CL2（已管理的）：已管理的过程的制度化。
• CL3（已定义级的）：已定义的过程的制度化。
• CL4（定量管理的）：可定量管理的过程的制度化。
• CL5（优化的）：量化，即统计学手段改变和优化过程域。

2.软件开发方法

网络上有好几种说法，我这边归纳一下

• 结构化方法：三个特点，需求明确，自顶向下，逐步分解。它由结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法。基本原则是功能的分解与抽象。

• 面向数据结构方法：即Jackson方法。以数据结构为驱动，适合于小规模的项目。

• 原型化方法：比较适合于用户需求不清、业务理论不确定、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法是比较好的。通俗一点讲，摸石头过河。先开发一个雏形给客户使用，然后再由客户提出的需求再进行修改，直到客户满意为止。不用一开始就投入大量的资源。

• 面向对象开发方法：包括面向对象分析、面向对象设计和面向对象实现，采用统一建模语言（UML）。面向对象方法学的思想是面向对象，以对象为中心，把数据封装在对象内部成为对象的属性，把面向过程的函数转为对象的行为方法，把对象抽象成为类，用以描述和设计、开发软件系统。

• 面向服务开发方法：面向对象更高标准的抽象。

3.软件开发模型(⭐⭐⭐⭐⭐）

知识点考查形式：
1.给定情景描述或特点描述，指出对应的开发模型；
2.给出特点的开发模型，判断描述的正误；
3.对于统一过程，判断具体任务完成的阶段；
4.对于敏捷开发方法，判断描述正误和一些特点的归属。

• 瀑布模型：瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、运行与维护。瀑布模型的特点是容易理解，管理成本低，每个阶段都有对应的成果产物，各个阶段有明显的界限划分和顺序要求，一旦发生错误，整个项目推倒重新开始。
  适用于需求明确的项目，一般表述为需求明确、或二次开发，或者对于数据处理类型的项目

• V模型：如下图所示，V模型的左侧就是瀑布模型，V模型就是在瀑布模型的基础上，伴随相应的测试。V模型以文档作为驱动，适合于软件需求很明确的软件项目的模型
  

• 增量模型：融合了瀑布模型的基本成分和原型实现的迭代特征，将软件分成多个模块，一个一个模块加入，往往第一个模块就是核心模块。强调每一个增量均发布一个可操作的产品。

• 原型模型：如上文所诉的原型化方法，适用于需求不明确的情况，属于摸石头过河。

• 喷泉模型：以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。迭代、无间隙，会将软件开发划分为多个阶段，但各个阶段无明显界限，并且可以迭代交叉。

• RUP统一过程模型：其实就是UP（统一过程），是Rational公司开发的，完全兼容UP，但比UP更加完整、详细。特点是：用例驱动；以架构为中心；迭代和增量。简而言之就是：用例驱动：即功能驱动，以一个一个功能开发为主；架构为中心：做一个架构，要求有很强的拓展性；迭代和增量：利用架构的拓展性，实现功能的拓展和增量；
  构思阶段 ：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型。
  细化阶段 ：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示。
  构建阶段 ：将设计转化为实现，并进行集成和测试。
  移交阶段 ：将产品发布给用户进行测试评价，并收集用户的意见，之后再次进行迭代修改产品使之完善

• 螺旋模型：瀑布模型和演化模型的结合体，增加了风险分析。螺旋模型非常注重风险分析，通过反复的迭代来逐步完善软件。这种方法可以有效地管理风险，但可能会增加开发成本。属于面向对象开发模型，适合的项目: 复杂度高, 风险大, 规模庞大

• 敏捷开发：敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，适用于小团队和小项目，具有小步快跑的思想。常见的敏捷开发方法有极限编程法、水晶法、并列争球法和自适应软件开发方法。
  （1）极限编程是一种轻量级的开发方法，它提出了四大价值观：沟通、简单、反馈、勇气。五大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。十二个最佳实践：计划游戏、隐喻、小型发布、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户和编码标准。
  （2）水晶法强调经常交付，认为每一种不同的项目都需要一套不同的策略、约定和方法论。
  （3）并列争球法（Scrum）的核心是迭代、增量交付，按照30天进行迭代开发交付可实际运行的软件。包括Product Backlog 产品待办事项清单；（Refactoring 重构，不属于Scrum的步骤）；Sprint Backlog，Sprint待办事项清单；Sprint，冲刺迭代。
  （4）自适应软件开发的核心是三个非线性的，重迭的开发阶段：猜测、合作、学习。
  （5）A选项Product Backlog 产品待办事项清单；B选项Refactoring 重构，不属于Scrum的步骤；C选项Sprint Backlog，Sprint待办事项清单；D选项 Sprint，冲刺迭代。

1、掌握常见开发模型的特点，能够加以区分；
2、掌握统一过程的4个阶段的任务；
3、了解敏捷开发涉及到的原则。

4.需求分析

本知识点的考查方式主要有：给定需求描述判断其需求分类；给定概念描述判断正误；指出需求分析的任务、成果产物、工具。

【要点分析】

1、需求分析的任务是解决做什么的问题。

2、需求的分类：

（1）功能需求：考虑系统要做什么，在何时做，在何时以及如何修改或升级。

（2）非功能需求：考虑软件开发的技术性指标，例如存储容量限制、执行速度、响应时间及吞吐率等。

（3）设计约束：除了功能需求和非功能需求以外的需求，例如操作系统限制、开发语言限制等。

3、需求分析的工具有判定表、判定树、数据流图和数据字典。
外部实体：使用系统的人或者物或系统，试卷之类的都不是。
4、需求分析的产物有：需求规格说明书SRS。

【备知识点拨】

1、了解需求分析的任务、工具、产物等有哪些；

2、掌握需求分析的分类。

5.系统设计

本知识点的主要考查形式有：给出软件设计相关描述（概念、原则等）判断正误；或给出一些情景描述指出其内聚类型或耦合类型。

5.1概要设计与详细设计

• 概要设计和详细设计：抽象化、自顶向下、逐步求精、信息隐蔽、模块独立
• 软件设计的任务:解决怎么做的问题。软件设计包括体系结构设计、接口设计、数据设计和过程设计

结构设计：定义软件系统各主要部件之间的关系。
过程设计：系统结构部件转换成软件的过程描述。
接口设计（人机界面设计）：软件内部，软件和操作系统间以及软件和人之间如何通信。
数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。

5.2模块设计

5.2.1内聚性

• 功能聚合:模块内部各个部分全部属于一个整体，并执行同一功能，且各部分对实现该功能都必不可少

• 顺序聚合:模块内部的各个部分，前一部分处理动作的最后输出是后一部分处理动作的输入，顺序执行。

• 通信聚合:模块的各个组成部分所完成的动作都使用了同一个数据或产生同一输出数据。

• 过程聚合:模块内部各个组成部分所要完成的动作虽然没有关系，但必须按特定的次序执行。

• 时间聚合（瞬时聚合）:模块内部的各个组成部分所包含的处理动作必须在同一时间内执行。

• 逻辑聚合:模块内部的各个组成在逻辑上具有相似的处理动作，但功能用途上彼此无关。

• 偶然聚合:模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系。

5.2.2耦合性

• 非直接耦合:两个模块之间没有直接关系，它们的联系完全是通过主模块的控制和调用来实现的。

• 数据耦合:两个模块彼此间通过数据参数交换信息。

• 标记耦合:一组模块通过参数表传递记录信息，这个记录是某一个数据结构的子结构，而不是简单变量。

• 控制耦合:两个模块彼此间传递的信息中有控制信息。

• 外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息。

• 公共耦合:两个模块之间通过一个公共的数据区域传递信息。

• 内容耦合:一个模块需要涉及到另一个模块的内部信息。

5.2.3其他原则

• 保持模块的大小适中
• 尽可能减少调用的深度
• 多扇入、少扇出、单入口、单出口
• 模块的作用域应该在模块之内
• 功能应该是可以预测的

5.3人机界面设计

• 置于用户的控制之下
• 减少用户的记忆负担
• 保持界面的一致性

【备知识点拨】
1、掌握软件设计的阶段、任务和原则。
2、区分各种内聚类型、耦合类型。

6.软件测试(⭐⭐⭐⭐）

本知识点的考查形式主要有：给定一些描述判断正误；或对于一些具体测试方法判断分类；以及根据要求设计测试用例或判断测试用例的个数。

6.1常见的软件测试方法分类：

6.2常见的黑盒测试方法：

• 等价类划分：确定无效与有效等价类，设计用例尽可能多的覆盖有效类，设计用例只覆盖一个无效类。

• 边界值分析：处理边界情况时最容易出错，选取的测试数据应该恰好等于、稍小于或稍大于边界值。

6.3常见的白盒测试方法：

• 语句覆盖：语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次，即保证所有的代码语句都跑过一遍。

• 判定覆盖：判定覆盖又称为分支覆盖，它的含义是，不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。

• 条件覆盖：条件覆盖的含义是，不仅每个语句至少执行一次，而且使得判定表达式中的每个条件都取得各种可能的结果。【条件不一定包含判定，反之亦然】

• 判定/条件覆盖：同时满足判定覆盖和条件覆盖的逻辑覆盖。

• 路径覆盖：它的含义是，选取足够多的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每天环路路径至少经过一次），包含判定覆盖，但不包含条件覆盖

6.4各测试阶段的任务

• 验收测试：有效性测试、软件配置审查、验收测试。

• 系统测试：恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试。

• 集成测试：模块间的接口和通信。

• 单元测试：模块接口、局部数据结构、边界条件、独立的路径、错误处理。

• 回归测试（修改软件后进行的测试，防止引入新的错误）。

• 负载测试（对软件负载能力的测试）。

• 压力测试（对软件超负荷条件下运行情况的测试）。

6.5McCabe复杂度计算

• 概念：McCabe 度量法是由 Thomas McCabe 提出的一种基于程序控制流的复杂性度量方法。McCabe 复杂性度量又称为环路度量，它认为程序的复杂性在很大程度上取决于控制的复杂性，单一的顺序程序结构最为简单，循环和选择构成的环路越多，程序就越复杂。

• McCabe复杂度计算公式：V(G)=m-n+2p，V(G) 是有向图 G 中的环路数，m 是图 G 中弧的个数，n 是图 G 中的结点数，p 是图 G 中的强连通分量个数。。

• 对于伪代码可以先转换为程序流程图，对程序流程图可以最终转换为结点图处理，转换时注意将交点的地方标注为新的结点，以最终的结点图带入公式结算其McCabe复杂度。

• 三种计算方法
  （1）流图中的区域数等于环形复杂度。
  （2）流图G的环形复杂度 V(G) = E - N + 2，其中，E是流图中边的条数，N是结点数。
  （3）流图G的环形复杂度 V(G) = P + 1，其中，P是流图中判定结点的数目。

【备知识点拨】
1、掌握常见的测试方法分类；
2、掌握常见的黑盒测试方法和白盒测试方法。
3、了解软件测试相关的概念，以及一些常见的测试阶段的任务。

7.软件维护

本知识点的考查形式为给定情景描述判断其维护类型。

• 更正性维护：针对真实存在并已经发生的错误进行的维护行为。

• 预防性维护：针对真实存在但还未发生的错误进行的维护。

• 适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。

• 完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。

掌握不同维护类型的特点并加以区分。

8.软件文档

• 开发文档
• 产品文档
• 管理文档

9.软件质量保证