【软件工程】各种概念-习题2

第一章：软件工程概论

软件工程概论

应用软件

为满足特定应用领域、不同应用问题之需求的专用软件

支撑软件

软件系统的中间层，支撑各种软件的开发运行与维护的软件

系统软件

最靠近计算机硬件的一层软件——控制和协调计算机及外部设备，支持应用软件开发与运行的软件

软件的四大特征——复杂性

软件的四大特征——不可见性

软件的四大特征——易变性

软件的四大特征——一致性

遗留系统

仍在使用的软件系统，可满足客户需求，但很难以“优雅的”方式对其进行演变以适应新需求或新环境。

软件危机

计算机软件开发和维护的过程中所遇到的一系列严重问题

软件神话

关于软件及其开发过程中的一些说法被人盲目相信

软件工程

是为了经济的获得能够在实际机器上高效运行的可靠软件而建立和使用的一系列工程化原则。

软件开发方法——结构化开发方法

软件开发方法——面向对象的开发方法

软件开发方法——面向服务的开发方法

软件开发环境

多个工具集成在一起，形成了软件工程的开发环境，支持软件开发的全过程。

软件质量

软件产品与需求一致的程度，由一系列质量特性来描述；

软件工程的核心思想

概念映射

问题空间的概念与解空间的模型化概念之间的映射

业务逻辑映射

问题空间的处理逻辑和解空间的处理逻辑之间的映射

产品

在各个抽象层次的产出物

过程

在各个抽象层次之间进行映射与转换

功能性需求

软件所实现的功能达到它的设计规范和满足用户需求的程度

完备性

软件能支持用户所需求的全部功能的能力

正确性

软件按照需求正确执行任务的能力

健壮性

异常情况下，软件能正常运行的能力

可靠性

在给定的时间和条件下，软件能正常维持其工作而不发生故障的能力

非功能性需求

系统完成所期望的工作的性能和质量

效率

软件实现其功能所需计算机资源的大小

可用性

用户使用软件的容易程度，用户容易使用和学习

可维护性

软件适应变化的能力，系统很容易被修改从而适应新的需求

可移植性

软件可以不经修改或稍加修改就能运行于不同软硬件环境的能力

清晰性

易读、易理解，可以提高团队开发效率，降低维护代价

安全性

在对合法用户提供服务的同时，阻止未授权用户的使用

兼容性

不同产品版本相互交换信息的能力

经济性

开发成本、开发时间和对市场的适应能力

商业质量

上市时间、成本/收益、目标市场、与老系统的集成、生命周期长短等。

最佳实践

是一个管理学概念，采用某种技术、方法、过程、活动或机制可以使生产管理时间的结果达到最优，并减少出错的可能性。

复用

分而治之

折中

演化

敏捷开发过程

软件过程模型

软件过程

是指软件生命周期所涉及的一系列相关过程，由软件项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关产品（计划、文档、模型、编码、测试、手册）组成。
软件过程不仅涉及工程开发，而且涉及工程支持和工程管理

敏捷过程与方法

软件项目管理

项目

为创建某种特定的产品或服务而住址或设计的临时的一次性的活动，通过执行一组活动，使用受约束的资源（资金、人、原料、能源、空间等）来满足预定义的目标

项目管理

有效的组织和管理各类资源（例如人），以使项目能够在预定的范围、质量、时间、成本等约束条件下顺利交付
软件项目特征：软件产品的不可见性：软件项目复杂和抽象；软件的高度不确定性：预定计划与实际情况存在较大偏差；软件过程的多变化性：不确定、不稳定；软件人员的高技能及其高流动性：风险；

软件项目管理的4p

人员、过程、产品、工具

一窝蜂模式

主治医师模式

首席程序员处理主要模块的设计与编写，其他成员从各种角度支持他的工作。

社区模式

很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量。

交响乐团模式

人多门类齐全，各司其职，各有专门场地，演奏期间严格遵守纪律。

爵士乐模式

演奏时没有谱子，没有现场指挥

功能团队模式

具备不同能力的同事平等协作，共同完成一个项目开发；在这个项目完成之后，这些人又和别的角色一起去完成下一个功能，他们之间没有管理和被管理的关系。

官僚模式

软件产品

是指向用户提供的计算机软件、信息系统或设备中的嵌入的软件或在提供计算机信息系统集成、应用服务等技术服务时提供的计算机软件。

产品结构分解（PBS）

通过分层的树型结构来定义和组织范围内的所有产出物，自顶向下，逐级细分

工作结构分解（WBS）

通过分层的树型结构来定义和组织工作任务之间的分解关系，自顶向下，逐级细分。

W5HH原则

项目管理过程

项目先后衔接的各个阶段

项目管理核心要素——功能性

项目管理核心要素——可信性

项目管理核心要素——易使用性

项目管理核心要素——可维护性

项目管理核心要素——可移植性

项目管理的主要任务

项目可行性分析与估算、项目进度安排、项目风险管理、项目质量管理、项目跟踪与控制

范围

描述了将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统的性能、约束条件、结构和可靠性，以及期望的时间、成本目标；

可行性分析——技术可行性

可行性分析——经济可行性

可行性分析——时间可行性

可行性分析——资源可行性

项目进度计划

确保合同工期和主要里程碑时间的前提下，对设计，采办和施工的各项作业进行时间和逻辑上的合理安排，以达到合理利用资源，降低费用支出和减少施工干扰的目的。

项目进度跟踪

项目进度表只是提供了一张进度路线图，在实际执行过程中需要对其进行跟踪和控制，以决定是否需要对进度计划进行调整。

软件演化与配置管理

软件演化

是指在软件生命周期内进行系统维护和系统更新的动态行为，修正和改善软件进入使用期后暴露出的问题，以适应需求的不断变化。

软件维护

为了修改软件缺陷或增加新的功能而对软件进行的变更

软件再工程

为了避免软件退化而对软件的一部分进行重新设计、编码和测试，提高软件的可维护性和可靠性。

软件维护类型——纠错性维护

修改软件中的缺陷或不足

软件维护类型——适应性维护

修改软件使其适应不同的操作系统，包括硬件变化、操作系统变化或其他支持软件的变化。

软件维护类型——完善性维护

增加或修改系统的功能，使其适应业务的变化

软件维护类型——预防性维护

为减少或避免以后可能需要前三类维护而提前对软件进行的修改工作

软件维护内容——程序维护

软件维护内容——数据维护

软件维护内容——硬件维护

软件配置

有在软件工程过程中所有信息项构成，他可以看作软件的具体形态（软件配置项）在某一时刻的瞬间影像

软件配置管理

协调软件开发从而使得混乱减到最小的技术称为软件配置管理。
配置管理能够系统的处理变更，从而使得软件系统可以随时保持其完整性，因而称为“变更控制”，可以用来评估提出的变更请求，跟踪变更，并保存系统在不同时间的状态。

软件配置管理目标——标识变更

软件配置管理目标——控制变更

软件配置管理目标——确保变更的正确实现

软件配置管理目标——向开发组织各个角色报告变更

软件配置项（SCI）

是软件生命周期内受管理和控制的基本单元，大到整个系统，小到某个硬件设备或软件模块

基线

已经通过正式评审和批准的软件规格说明或代码，它可以作为进一步开发的基础，并且只有通过正式的变更规程才能修改它。

配置管理数据库

用于保存和软件相关的所有配置项的信息以及配置项之关系的数据库

持续集成

敏捷开发的一项重要实践
让产品可以快速迭代，同时还能保证质量
核心措施：在产品集成之前，必须通过自动化测试，并且通过100%的测试用例
随时可运行；频繁发布，快速迭代、快速交付

git的基本思想

Git关心文件数据的整体是否发生变化，直接会将文件提交时的数据保存成快照，并不保存这些前后变化的差异数据，并且使用SHA-1加密算法保证数据的完整性。
把变化的文件作快照后，记录在一个微型的文件系统中。
每次提交更新时，它会遍历一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。
为提高性能，若文件没有变化，Git不会再次保存，而只对上次保存的快照作一链接。

软件编码与测试

代码评审分析和优化

代码评审

是被主流IT行业普遍认同的，提高代码质量的有效途径之一。

代码评审主要内容——设计

代码评审主要内容——功能性

代码评审主要内容——复杂度

代码评审主要内容——测试

代码评审主要内容——注释

代码评审主要内容——命名

代码评审主要内容——文档

代码复审

代码中是否存在“代码规范”的框架内正确地解决了问题

走查

由设计人员或变成人员组成一个走查小组，通过阅读一段文档或代码，并进行体委和讨论，从而发现可能存在的缺陷、遗漏和矛盾的地方。
类型：设计走查、代码走查

静态代码分析

在代码构建过程中帮助开发人员快速有效的定位代码缺陷。
主要技术：缺陷模式匹配、类型推断、模型检查、数据流分析。

性能分析

以收集程序运行时信息为手段研究程序行为的分析方法，是一种动态程序分析的方法。
目的：
决定程序那个部分应该被优化，从而提高程序的速度或内存使用效率。
两种方法：抽样、代码注入

软件测试

产品测试

是将产品原型或产品成品提供给消费者，由消费者根据自己的想法对产品属性进行评价，从中系统地获得消费者的意见和建议。

软件测试

使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
目的：帮助识别开发完成的计算机软件的正确度、完全度、质量。
原则：充分注意到测试中的聚集现象：28法则；对测试结果一定要有一个确认过程；制定严格的测试计划；注意回归测试的关联性；妥善保管一切测试过程文档。

测试用例

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
特征：最有可能抓住错误的；不是重复的多余的；一组相似测试用例中最有效的；既不能太简单，也不能太复杂；
设计原则：测试用例的代表性；测试用例的可判定性；测试结果的可再现性；

软件测试经典模型

传统瀑布模型，v模型，W模型，X模型，H模型

软件测试方法分类

单元测试、集成测试、确认测试、系统测试、验收测试

驱动模块

模拟被测模块的上一级模块，接收测试数据把这些数据传送给所测模块，最后再输出实际测试结果。

桩模块

模拟测试所测单元需调用的其他函数接口，模拟实现子函数的某些功能。

集成测试

在单元测试的基础上，将所有模块按照总体设计的要求组装成子系统或系统进行的测试。

确认测试

检查软件能否按照合同要求进行工作，即是否满足软件需求说明书中的确认标准。

系统测试

系统测试是将已经集成好的软件系统作为一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他元素结合在一起，在实际的运行环境下进行的一系列测试。

功能测试

是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据软件需求规格说明和测试需求列表，验证产品功能实现是否符合需求规格。

压力测试

是检查系统在资源超负荷的情况下的表现，特别是对系统的处理时间有什么影响。

安全性测试

安全性测试检查系统对非法侵入的防范能力

恢复测试

检测系统从软件或者硬件失败中恢复的能力，即采用各种人工干预方式使软件出错，而不能正常工作，从而检测系统的恢复能力。

GUI测试

检查用户界面实现与设计的符合情况，二是确认用户界面处理的正确性。

安装测试

系统验收后，需要在目标环境进行安装，保证应用软件能够被成功的安装。

验收测试

是以用户为主的测试，一般使用用户环境中的实际数据进行测试。
alpha测试：用户在开发环境下的测试;
beta测试：软件的多个用户在实际使用环境下的测试;

回归测试

验证系统的变更没有影像之前的功能，并且保证变更时正确的。

软件与架构设计

软件设计与架构概论

软件设计

为问题域的外部可见行为的规约增添实际计算机系统所需的细节，包括关于人机交互、任务管理和数据管理的细节。

良好设计的三个特征：目标、形态、内容
设计阶段是软件工程中形成质量的关键阶段。
软件设计的四方面内容：架构设计、数据设计、接口设计，过程设计
从工程管理的角度，软件设计包括：概要设计、详细设计。

架构的共性——构件

架构的共性——连接件

架构的共性——物理分布

架构的共性——约束

架构的共性——性能

软件架构

提供了一个结构、行为、属性的高级抽象。
整个系统的结构和规格说明变得原来越重要
关注的是如何将复杂的软件系统划分为模块、如何规范模块的构成和性能、以及如何将这些模块组织为完整的系统。
主要目标：建立一个一致的系统及其视图集，并表达为最终用户和设计者所需要的结构形式，支持用户和设计者的交流与理解。

外向目标

为满足用户需求，系统应当做什么；
需要分析当前需求、拓展或细化结构、澄清模糊性、提高一致性。

内向目标

如何使系统满足用户需求、需要建立哪些软件模块、软件模块的结构、模块之间的关系。
考虑各种可选方案，重复更新和明确设计目标，必要时做出妥协和折中。

构件

是具有某种功能可复用的软件结构单元，表示了系统中主要的计算元素和数据存储。
构件作为一个封装实体，只能通过接口与外部环境交互，表示了构件和外部环境的交互点，内部具体实现则被隐藏起来。

连接

构件间建立和维护行为关联与信息传递的途径。
需要两方面的支持：机制、协议
协议是连接的规约
影响连接实现复杂性的因素之一是“有无连接的返回信息和返回的时间”，可分为同步和异步。

连接件

表示构件之间交互并实现构件间的连接。
连接件事负责完成构件之间信息交换和行为联系的专用构件

软件架构的四大器

异步->分层<-缓存
分布式->分层

分层

是将功能进行有序的分组

负载均衡

将负载进行平衡、分摊到多个操作单元上进行执行，协同完成工作任务

Saas与云端软件部署

客户机/服务器

一个应用程序被分为两个逻辑上分离的部分。

BS结构

基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决，系统维护成本低；

客户端无任何业务逻辑；
良好的灵活性和可扩展性；

内外有别原则

企业内部通过局域网直接访问数据库服务器
企业外部通过Internet访问Web服务器/应用服务器

查改有别原则

不管用户处于企业内外什么位置，凡是对数据进行更新操作的，都需要使用CS结构；
如果只是执行一般的查询与浏览操作，则使用BS结构。

软件即服务（SaaS）

一种通过Internet提供软件的模式，用户不再购买软件，而改用向提供商租用基于web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商负责软件的可用性（软件维护、可扩展性、灾难恢复等）管理与支持；按需消费。

多租户技术

是一种软件架构技术，实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据隔离性。

MVC目标

将承担不同职责的软件实体之间清晰的分离开来，降低耦合。
让SaaS程序的和用户界面和业务逻辑功能实现模块化，以便使程序开发人员可以分别开发，单独修改各个部分而不影响其他部分。

MVC

是一种软件体系结构，它将应用程序的数据模型/业务逻辑/用户界面分别放在独立的构件中，从而对用户界面的修改不会对数据模型/业务逻辑造成很大影响。

模型

用于管理应用系统的行为和数据，并响应为获取其状态信息（通常来自视图）而发出的请求，还会响应更改状态的指令（通常来自控制器）；

视图

用于管理数据的显示

控制器

用于解释用户鼠标和键盘输入，以通知模型和视图进行响应的修改

框架

可实例化的部分完成的软件系统或子系统，它为一组系统或子系统定义了统一的体系结构，并提供了构造系统的基本构造块，还未实现具体功能定义了扩展点。

软件部署与实施

将系统设计方法与软件系统转换成实际运行系统的全过程。

基本架构风格

架构风格

也成为架构模式，换句话说就是架构方面的套路。也可以说是前人在架构方面总结出来的可以解决特定问题的方法。

软件方面的架构风格

三个层次：代码模式，设计模式，架构模式
调用返回风格，主程序-子过程风格，面向对象风格

代码模式

也可以说是代码编码时的套路，一些技巧，是最低层次的套路。只能影响某一方法或类中的一些细节。

设计模式

解决了一般性的设计问题，影响一个模块内部，是中等层次的重用策略

架构模式

最高层次的重用策略，实现定义好的一些字系统，层，指定他们的责任，并给出把它们组织在一起的法则和指南。

B/S结构

B/S成为真正意义上的瘦客户端，从而具备了很高的稳定性延展性和执行效率。
B/S将服务集中在一起进行管理，统一服务于客户端，从而具备了良好的容错能力和负载平衡能力。

需求分析

软件需求与需求获取

软件需求

以一种清晰、简洁、一致且无二义性的方法描述用户对目标系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。

业务需求

客户对于系统的高层次目标要求，定义了项目的远景和范畴。

用户需求

从用户角度描述的系统功能需求和非功能需求，通常只设计系统的外部行为而不设计内部特性。

功能需求

系统应该提供的功能或服务，通常设计用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节。

非功能需求

从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能的额外要求，如响应时间、数据精度、可靠性等。

约束条件

系统设计和实现时必须满足的限制条件，对其进行权衡和调整是相当困难的，甚至是不可能的。

业务规则

是指对业务定义和约束的描述，是对某系功能的可执行性或内部执行逻辑的一些限定条件。

外部接口需求

描述系统与其所处外部环境之间如何进行交互

好需求具备特征

完整性、正确性、可行性、必要性、划分优先级、可验证性、无二义性。

产生不合格需求原因

没有用户参与，模棱两可的需求、不必要的特性、过于精简的规格说明、忽略用户分类、不准确的计划。

需求工程

应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的过程。

需求工程的总体流程

需求获取

通过与用户的交流，对现有的系统的观察及对任务进行分析，从而开捕获和修订用户的需求。

需求分析

对收集到的需求进行提炼、分析和审查，为最终用户所看到的系统建立概念化的分析模型

需求规格说明

需求开发的结果
精确的、形式化的阐述一个软件系统必须提供的功能、非功能、所要考虑的限制条件等
作为用户和开发者之间的一个契约
是用户、分析人员和设计人员之间进行理解和交流的手段

需求验证

以需求规格说明为输入，通过评审、模拟或快速原型等途径，分析需求规格的正确性和可行性，发现存在的错误或缺陷并及时更改和补充。

需求管理

用户故事与用例建模

用户故事

从用户的角度来描述用户渴望得到的功能：角色（谁要使用这个功能）、目标/活动(需要完成什么样的功能)、商业价值（为什么需要这个功能，这个功能带来什么价值）

用例

表示系统所提供的服务或可执行的某种行为，站在用户角度定义软件系统的外部特征。

用户故事组成