系统开发与运行
系统分析与设计
需求分析
需求工程
结构化分析与设计
测试基础知识
系统运行与维护
软件架构介绍
系统分析概述
系统分析是一种问题求解技术，它将一个系统分解成各个组成部分， 目的是研究各个部分如何工作、交互,以实现其系统目标。
目的和任务：
系统分析的主要任务是对现行系统进一步详细调查，将调查中所得到的文档资料集中,对组织内部整体管理状况和信息处理过程进行分析,为系统开发提供所需的资料,并提交系统方案说明书。
系统分析的主要步骤：
(1) 认识、理解当前的现实环境,获得当前系统的“物理模型”。
(2) 从当前系统的“物理模型”抽象出当前系统的“逻辑模型”。
(3) 对当前系统的“逻辑模型”进行分析和优化,建立目标系统的“逻辑模型”。
(4) 对目标系统的逻辑模型具体化（物理化），建立目标系统的物理模型。
系统开发的目的是将现有系统的物理模型转换为目标系统的物理模型。
系统设计
系统设计基本原理：
- 抽象（重点说明本质方面，忽略非本质方面）；
- 模块化（可组合、分解和更换的单元）；
- 信息隐蔽（将每个程序的成分隐蔽或封装在一个单一的设计模块中）；
- 模块独立（每个模块完成一个相对独立的特定子功能，且与其他模块之间的联系简单）。
模块的设计要求独立性高，就必须高内聚，低耦合，
- 内聚是指一个模块内部功能之间的相关性，
- 耦合是指多个模块之间的联系。
内聚⭐️⭐️⭐️
内聚程度从低到高如下表所示：
| 内聚分类 | 定义 | 记忆关键字 |
| 偶然内聚。 | 一个模块内的各处理元素之间没有任何联系 | 无直接关系。 |
| 逻辑内聚 | 模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能 | 逻辑相似、参数决定 |
| 时间内聚 | 把需要同时执行的动作组合在一起形成的模块。 | 同时执行 |
| 过程内聚 | 一个模块完成多个任务，这些任务必须按指定的过程执行 | 指定的过程顺序 |
| 通信内聚1 | 模块内的所有处理元素都在同一个数据结构上操作,或者各处理使用相同的输入数据或者产生相同的输出数据。 | 相同数据结构、相同输入输出 |
| 顺序内聚 | 一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入。 | 顺序执行、输入为输 出 |
| 功能内聚 | 最强的内聚，模块内的所有元素共同作用完成一个功能，缺一不可 | 共同作用、缺一不可 |
耦合⭐️⭐️⭐️
耦合程度从低到高如下表所示：
| 耦合分类 | 定义 | 记忆关键字 |
| 无直接耦合。 | 两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用,不传递任何信息。 | 无直接关系。 |
| 数据耦合。 | 两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递。 | 传递数据值调用。 |
| 标记耦合 | 两个模块之间传递的是数据结构。 | 传递数据结构 |
| 控制耦合 | 一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择的执行模块内的某一功能。 | 控制变量、选择执行某一功能。 |
| 外部耦合 | 模块间通过软件之外的环境联合(如1/0将模块耦合到特定的设备、格式、通信协议上）时。 | 软件外部环境 |
| 公共耦合。 | 通过一个公共数据环境相互作用的那些模块间的耦合。 | 公共数据结构 |
| 内容耦合。 | 当一个模块直接使用另一个模块的内部数据,或通过非正常入口转入另一个模块内部时。 | 模块内部关联 |
系统设计
在系统分析阶段，我们已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。进入设计阶段，要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型。
系统设计的主要目的
是为系统制定蓝图,在各种技术和实施方法中权衡利弊,精心设计，合理地使用各种资源，得出新系统的详细设计方案。
步骤：
概要设计和详细设计。
概要设计基本任务：
-
- 设计软件系统总体结构、
- 数据结构及数据库设计、
- 编写概要设计文档、评审。
详细设计的基本任务：
-
- 模块内详细算法设计、
- 模块内数据结构设计、
- 数据库的物理设计、
- 其他设计（代码、输入/输出格式、用户界面）、
- 编写详细设计说明书、
- 评审。
系统总体结构设计
系统结构设计原则：
-
- 分解-协调原则、
- 自顶向下原则、
- 信息隐蔽和抽象原则、
- 一致性原则、
- 明确性原则、
- 模块间高内聚低耦合、
- 模块的扇入系数和扇出系数合理、
- 模块规模适当。
子系统划分的原则：
-
- 子系统要具有相对独立性、
- 子系统之间数据的依赖性尽量小、
- 子系统划分的结果应使数据冗余较小、
- 子系统的设置应考虑今后管理发展的需要、
- 子系统的划分应便于系统分阶段实现、
- 子系统的划分应考虑到各类资源的充分利用。
例（2016年上半年）：
在设计软件的模块结构时， （31）不能改进设计质量。
A. 模块的作用范围应在其控制范围之内
B. 模块的大小适中
C. 避免或减少使用病态连接（从中部进入或访问一个模块）
D. 模块的功能越单纯越好
答案：
解析: ABC描述的都是常识,D描述的有问题,应该是模块的功能越单一越好,并非单纯。
WebApp分析与设计
WebApp是基于web的系统和应用。大多数WebApp采用敏捷开发过程模型进行开发。
WebApp的特性：
-
- 网络密集性（服务于不同客户全体的需求）、
- 并发性（大量用户同时访问）、
- 无法预知的负载量（用户数量）、
- 性能（响应时间过长导致用户流失）、
- 可用性（最好7*24*365可用）、
- 数据驱动（和用户的数据交互）。
WebApp五种需求模型：
1、内容模型：
给出由WebApp提供的全部系列内容，包括文字、图形、图像、音频和视频。包含结构元素,为WebApp的内容需求提供了一个重要的视图。这些结构元素包含内容对象和所有分析类,在用户与WebApp交互时生成并操作用户可见的实体。
内容的开发可能发生在WebApp实现之前、构建之中、或者投入运行以后（全过程）。
内容对象：
产品的文本描述、新闻文章、照片、视频等。
数据树：
由多项内容对象和数据项组成的任何内容都可以生成数据树，是内容设计的基础，定义一种层级关系，并提供一种审核内容的方法，以便在开始设计前发现遗漏和不一致内容。
2、交互模型：
描述了用户与WebApp采用了哪种交互方式。由一种或多种元素构成，包括用例、顺序图、状态图、用户界面原型等。
用例
是交互分析的主要工具，方便客户理解系统的功能。
顺序图
是交互分析中描述用户与系统进行交互的方式。用户按照已定顺序使用系统,完成相应的功能，如登录流程。
状态图
是交互分析中对系统进行动态的描述。如状态的变化。
用户界面原型
展现用户界面布局、内容、主要导航链接、实施的交互机制及用户WebApp的整体美观度。
3、功能模型:
许多WebApp提供大量的计算和操作功能,这些功能与内容直接相关（既能使用又能生成内容，如统计报表）。这些功能常常以用户的交互活动为主要目标。
功能模型
定义了将用于WebApp内容并描述其他处理功能的操作，这些处理功能不依赖于内容却是最终用户所必需的。
4、导航模型:
为WebApp定义所有导航策略。考虑了每一类用户如何从一个WebApp元素（如内容对象）导航到另一个元素。
5、配置模型:
描述WebApp所在的环境和基础设施。在必需考虑复杂配置体系结构的情况下，可以使用UML部署图。
WebApp设计
1、架构设计:
使用多层架构来构造,包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含WebApp的业务规则的内容或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。
MVC（模型-视图-控制器）结构是WebApp基础结构模型之一，将WebApp功能及信息内容分离。
2、构件设计
WebApp构件：
定义良好的聚合功能，为最终用户处理内容或提供计算或处理数据；义内容和功能的聚合包，提供最终用户所需要的功能。因此，WebApp构件设计通常包括内容设计元素和功能设计元素。
构件级内容设计：
关注内容对象，以及包装后展示给最终用户的方式，应该适合创 建的WebApp特性。
构件级功能设计：
将WebApp作为一系列构件加以交付,这些构件与信息体系结构并行开发，以确保一致性。
3、内容设计:
着重于内容对象的表现和导航的组织,通常采用线性结构、网格结重构、层次结构、网络结构四种结构及其组合。
4、导航设计:
定义导航路径,使用户可以访问WebApp的内容和功能。
软件需求
按需求内容分类：
- 业务需求：由客户提出的宏观的一个功能需求。
- 用户需求：设计员去调查需求中涉及到的每个用户的具体需求。
- 系统需求: 经过整合,形成最终的系统需求,包括功能、性能、设计约束三个方面的需求。
从客户角度分类：
- 基本需求：需求明确规定的功能。
- 期望需求：除了基本需求外，客户认为理所应当包含在内的其他功能。
- 兴奋需求：客户未要求的其他功能需求，会浪费项目开发时间和成本。
软件需求分类：
- 功能需求：软件必须完成的基本动作。
- 性能需求: 说明软件或人与软件交互的静态或动态数值需求，如系统响应速度、处理速度等。
- 设计约束：受其他标准硬件限制等方面的影响。
- 属性: 可用性、安全性、可维护性、可转移/转移性。
- 外部接口需求：用户接口、硬件接口、软件接口、通信接口。
需求工程
需求工程六个阶段
- 需求获取: 获取需求,方法有收集资料、联合讨论会JRP、用户访谈、书面调查、现场观摩、参加业务实践、阅读历史文档、抽样调查。
- 需求分析与协商：分析不同人提出的所有需求之间的关系并判断。
- 系统建模：建立系统的抽象模型。
- 需求规约：也即需求定义，目的是为了编写需求规约（即需求规格说明书），在双方之间达成一个共识。
- 需求验证: 需求开发阶段的复查手段,需求验证通过后,要请用户签字确认,作为验收标准之一，此时，这个需求规格说明书就是需求基线。
- 需求管理：对需求工程涉及的所有过程进行规划和控制。
需求管理
定义需求基线：
通过了评审的需求说明书就是需求基线，下次如果需要变更需求,就需要按照流程来一步步进行。
处理需求变更:
主要关心需求变更过程中的需求风险管理，带有风险的做法有：
-
- 无足够用户参与、
- 忽略了用户分类、
- 用户需求的不断增加、
- 模棱两可的需求、
- 不必要的特性、
- 过于精简的SRS、
- 不准确的估算。
需求跟踪：
双向跟踪,两个层次,正向跟踪表示用户原始需求是否都实现了,反向跟踪表示软件实现的是否都是用户要求的，不多不少。如下图所示：
例（2013年上半年）
“软件产品必须能够在3秒内对用户请求作出响应”属于
软件需求中的（18）
18.A.功能需求
B.非功能需求
c.设计约束
D.逻辑需求
答案：B
解析:3秒内相应用户需求，类似这种响应速度的都是性能需求，对应选项中非功能需求。
