系统分析与设计 - 快速指南

---

---

系统分析与设计 - 概述

系统开发是一个系统化的过程，包括规划、分析、设计、部署和维护等阶段。在本教程中，我们将主要关注：

• 系统分析
• 系统设计

系统分析

这是一个收集和解释事实、识别问题并将系统分解成其组成部分的过程。

进行系统分析的目的是为了研究系统或其部分，以识别其目标。这是一种解决问题的技术，可以改进系统并确保系统的所有组件都能高效地工作以实现其目标。

分析指定了系统应该做什么。

系统设计

这是一个规划新的业务系统或替换现有系统，通过定义其组件或模块以满足特定需求的过程。在规划之前，您需要彻底了解旧系统，并确定如何最好地使用计算机以有效地运行。

系统设计侧重于如何实现系统目标。

系统分析与设计 (SAD) 主要关注：

• 系统
• 流程
• 技术

Explore our latest online courses and learn new skills at your own pace. Enroll and become a certified expert to boost your career.

什么是系统？

“系统”一词源于希腊语“Systema”，意思是任何一组组件为了实现某种共同目标而建立的有组织的关系。

系统是“根据计划将相互依赖的组件有序地组合在一起以实现特定目标”。

系统的约束

系统必须具有三个基本约束：

• 系统必须具有一定的结构和行为，这些结构和行为旨在实现预定义的目标。

• 系统组件之间必须存在互连性和相互依赖性。

• 组织的目标比其子系统的目标具有更高的优先级。

例如，交通管理系统、工资系统、自动图书馆系统、人力资源信息系统。

系统的属性

系统具有以下属性：

组织性

组织性意味着结构和秩序。它是组件的排列，有助于实现预定的目标。

交互性

它由组件彼此之间运行的方式定义。

例如，在一个组织中，采购部门必须与生产部门互动，工资部门与人事部门互动。

相互依赖性

相互依赖性意味着系统的组件如何相互依赖。为了正常运行，组件根据特定计划进行协调和链接。一个子系统的输出是另一个子系统所需输入。

集成性

集成性关注的是系统组件如何连接在一起。这意味着即使每个部分执行独特的函数，系统各部分也在系统内一起工作。

中心目标

系统的目标必须是中心的。它可能是真实的或陈述的。一个组织声明一个目标并运作以实现另一个目标的情况并不少见。

为了成功地设计和转换，用户必须尽早了解计算机应用程序的主要目标。

系统的要素

下图显示了系统的要素：

输出和输入

• 系统的首要目标是产生对用户有用的输出。

• 输入是进入系统进行处理的信息。

• 输出是处理的结果。

处理器

• 处理器是系统中将输入实际转换为输出的要素。

• 它是系统的操作组件。根据输出规范，处理器可以完全或部分地修改输入。

• 随着输出规范的变化，处理也会发生变化。在某些情况下，输入也会被修改以使处理器能够处理转换。

控制

• 控制元素引导系统。

• 它是控制输入、处理和输出活动模式的决策子系统。

• 计算机系统的行为由操作系统和软件控制。为了保持系统的平衡，输出规范决定了需要什么和多少输入。

反馈

• 反馈在动态系统中提供控制。

• 正反馈是常规性质的，它鼓励系统的性能。

• 负反馈是信息性质的，它为控制器提供行动信息。

环境

• 环境是组织运行的“超系统”。

• 它是影响系统的外部元素的来源。

• 它决定了系统必须如何运行。例如，组织环境中的供应商和竞争对手可能会提供影响业务实际绩效的约束。

边界和接口

• 系统应由其边界定义。边界是识别其组件、流程和与其他系统接口时的相互关系的限制。

• 了解给定系统的边界对于确定其与其他系统的接口性质以成功设计至关重要。

• 了解给定系统的边界对于确定其与其他系统的接口性质以成功设计至关重要。

系统的类型

系统可以分为以下类型：

物理系统或抽象系统

• 物理系统是有形的实体。我们可以触摸和感受它们。

• 物理系统可以是静态的，也可以是动态的。例如，桌子和椅子是计算机中心的物理部分，它们是静态的。程序化的计算机是一个动态系统，其中的程序、数据和应用程序可以根据用户的需求而改变。

• 抽象系统是非物理实体或概念，可能是真实系统的公式、表示或模型。

开放系统或封闭系统

• 开放系统必须与其环境交互。它接收来自系统外部的输入并向系统外部提供输出。例如，必须适应不断变化的环境条件的信息系统。

• 封闭系统不与其环境交互。它与环境影响隔离开来。在现实中，完全封闭的系统很少见。

自适应系统和非自适应系统

• 自适应系统以改进其性能和生存的方式响应环境变化。例如，人类、动物。

• 非自适应系统是不响应环境的系统。例如，机器。

永久系统或临时系统

• 永久系统持续很长时间。例如，商业政策。

• 临时系统是为特定时间创建的，之后它们会被拆除。例如，DJ系统是为一个节目设置的，节目结束后会拆除。

自然系统和人造系统

• 自然系统是由自然创造的。例如，太阳系，季节系统。

• 人造系统是人造系统。例如，火箭、水坝、火车。

确定性系统或概率性系统

• 确定性系统以可预测的方式运行，并且系统组件之间的交互是可以确定的。例如，两个氢分子和一个氧分子构成水。

• 概率性系统表现出不确定的行为。确切的输出是未知的。例如，天气预报，邮件递送。

社会系统、人机系统、机器系统

• 社会系统由人组成。例如，社交俱乐部，社团。

• 在人机系统中，人和机器都参与执行特定任务。例如，计算机编程。

• 机器系统是忽略人为干预的系统。所有任务都由机器执行。例如，自主机器人。

人造信息系统

• 它是一个相互连接的信息资源集，用于在直接管理控制 (DMC) 下管理特定组织的数据。

• 该系统包括硬件、软件、通信、数据和应用程序，用于根据组织的需求生成信息。

  人造信息系统分为三种类型：

• 正式信息系统 - 它基于信息以备忘录、指示等形式从管理层到下层管理层的流动。

• 非正式信息系统 - 这是以员工为基础的系统，用于解决日常工作相关问题。

• 计算机系统 - 此系统直接依赖于计算机来管理业务应用程序。例如，自动图书馆系统、铁路订票系统、银行系统等。

系统模型

示意图模型

• 示意图模型是一个二维图表，显示系统元素及其链接。

• 不同的箭头用于显示信息流、物质流和信息反馈。

流程系统模型

• 流程系统模型显示了将系统结合在一起的物质、能量和信息的规律流动。

• 例如，程序评估和审查技术 (PERT) 用于以模型形式抽象现实世界系统。

静态系统模型

• 它们表示一对关系，例如活动-时间或成本-数量。

• 例如，甘特图提供了活动-时间关系的静态图。

动态系统模型

• 商业组织是动态系统。动态模型近似于分析师处理的组织或应用程序类型。

• 它显示了系统的持续、不断变化的状态。它包括：

  • 进入系统的输入

  • 发生转换的处理器

  • 处理所需的程序

  • 处理后产生的输出。

信息类别

与管理级别和管理者决策相关的，有三类信息。

战略信息

• 此类信息由最高管理层用于制定未来几年的长期规划政策。例如，收入趋势、金融投资、人力资源和人口增长。

• 此类信息借助决策支持系统 (DSS) 获得。

管理信息

• 此类信息由中层管理人员用于短期和中期规划，以月为单位。例如，销售分析、现金流预测和年度财务报表。

• 它借助管理信息系统 (MIS) 获得。

运营信息

• 此类信息由低层管理人员用于日常和短期规划，以执行日常运营活动。例如，维护员工考勤记录、逾期采购订单和当前可用库存。

• 它借助数据处理系统 (DPS) 获得。

系统分析和系统设计之间的区别

引言

系统分析和系统设计是软件系统开发生命周期中的两个关键阶段。虽然它们经常被互换使用，但它们具有不同的目的，并涉及不同的方法。本文将深入探讨系统分析和系统设计之间的关键区别、它们在开发过程中的作用以及每个阶段使用的技术。

系统分析

系统分析是软件开发项目的初始阶段，在这个阶段，系统的需求被收集、分析和记录。它涉及理解问题领域、识别利益相关者以及定义系统的范围和目标。

系统分析中的关键活动

• 需求收集− 确定用户和利益相关者的需求和期望。

• 需求分析− 分析收集到的需求，以确保其一致性、可行性和完整性。

• 可行性研究− 评估拟议系统的技术、经济和运营可行性。

• 流程建模− 创建图表和模型来表示当前和拟议的业务流程。

• 数据建模− 定义系统中的数据实体、属性和关系。

系统分析中使用的技术

• 访谈− 通过面对面或在线访谈收集利益相关者的信息。

• 调查− 使用问卷从大量受访者那里收集数据。

• 观察− 观察当前系统运行情况，以了解其流程和工作流程。

• 文档分析− 检查现有的文档、报告和手册。

• 原型设计− 创建系统的简化模型或模型，以收集反馈并改进需求。

系统设计

系统设计是后续阶段，在这个阶段，系统的详细规范被制定。它涉及设计体系结构、组件、接口和数据结构，以实现分析阶段中定义的需求。

系统设计中的关键活动

• 体系结构设计− 确定系统的整体结构和组件。

• 组件设计− 设计各个组件及其交互。

• 接口设计− 指定组件之间以及与外部系统之间的接口。

• 数据设计− 设计数据库模式和数据结构。

• 详细设计− 为每个组件创建详细规范，包括算法和数据流。

系统设计中使用的技术

• 统一建模语言 (UML)− 一种标准化的建模语言，用于可视化、规范、构建和记录软件系统。

• 数据流图 (DFD)− 说明数据流经系统的图表。

• 实体关系图 (ERD)− 表示数据库中实体及其之间关系的图表。

• 决策树− 显示流程中可能的结果和决策的图表。

• 状态转换图− 表示系统可以处于的不同状态以及它们之间转换的图表。

系统分析和系统设计之间的关键区别

系统分析和系统设计之间的关系

系统分析和系统设计紧密相连。分析阶段的输出（需求文档）作为设计阶段的输入。设计规范必须与需求一致，以确保开发的系统满足用户和利益相关者的需求。

结论

系统分析和系统设计是软件系统开发中必不可少的阶段。虽然它们具有不同的作用和方法，但它们共同努力以确保最终产品满足所需的需求并为用户创造价值。通过有效地进行系统分析和设计，组织可以开发高质量、高效且用户友好的软件系统。

系统分析与设计 - 通信协议

本文涵盖了不同层次的通信、关键协议及其实际意义。

引言

有效的通信在现代网络系统中至关重要，因为它确保了不同设备、应用程序和服务之间无缝的交互。通信协议作为标准化的规则集，能够在这些系统中实现互操作性、可靠性和安全性。从早期的电报到现代的互联网通信，协议已经发展到满足不断增长的数据交换和复杂应用程序的需求。

本文探讨了通信的概念以及管理数据传输的各种类型的协议，重点关注这些协议在当今数字领域的意义。

通信概述

从技术角度来看，通信是指两个或多个系统之间的数据交换，无论是在本地还是通过网络。为了促进这种交换，必须遵守特定的规则，以确保发送方和接收方能够相互理解。这包括数据格式、传输方法和错误检查。

通信类型

同步与异步通信−

• 同步− 数据实时发送和接收（例如实时视频会议）。

• 异步− 数据可以独立发送和处理（例如电子邮件、消息）。

单播、广播和组播通信−

• 单播− 一对一通信（例如客户端-服务器请求）。

• 广播− 一对多通信（例如电视广播、以太网数据）。

• 组播− 一对选定多（例如，与选定参与者的视频会议）。

半双工和全双工通信−

• 半双工− 一次在一个方向上进行数据传输（例如对讲机）。

• 全双工− 同时传输和接收（例如电话）。

协议：通信的支柱

协议是一组规则，定义了如何在网络之间传输和接收数据。它规定了通信的各个方面，从数据的格式到确保其交付的机制。协议在各个层次上运行，每个层次都针对网络中的特定功能。

协议的重要性

• 标准化− 协议确保来自不同制造商和环境的设备可以通信。

• 可靠性− 协议包含错误检查和纠正机制。

• 互操作性− 它们允许具有不同架构的系统进行通信。

• 效率− 通过将数据组织成数据包或帧来有效地传输数据。

OSI 模型：分层方法

为了理解通信中使用的不同协议，我们需要探索开放系统互连 (OSI) 模型，它提供了一个分为七层的网络通信框架。

• 物理层− 处理数据的物理传输（例如电缆、交换机）。

• 数据链路层− 管理直接连接节点之间的数据传输（例如 MAC 地址、以太网）。

• 网络层− 处理跨网络的数据路由（例如 IP）。

• 传输层− 提供错误检查并保证数据交付（例如 TCP）。

• 会话层− 管理应用程序之间的会话（例如，建立和终止连接）。

• 表示层− 将数据转换为应用程序层所需格式（例如加密、压缩）。

• 应用层− 与最终用户应用程序交互（例如 HTTP、FTP）。

OSI 模型中的每一层都有自己的一套协议，每个协议都执行特定功能以促进通信。

常用协议及其功能

传输层协议

• TCP（传输控制协议）− TCP 是面向连接的，通过在发送方和接收方之间建立连接来确保数据可靠地传输。它使用错误检查机制并确保数据按顺序到达，这使其成为需要准确性的应用程序（例如 Web 浏览、电子邮件）的理想选择。

• UDP（用户数据报协议）− UDP 是无连接的，这使其比 TCP 更快。但是，它不能保证数据的交付，这使得它对于对时间敏感的应用程序（如流媒体）有用，在这些应用程序中，速度比完美的准确性更重要。

互联网层协议

• IP（互联网协议）− IP 负责寻址和路由数据包，以确保它们到达正确的目的地。它在网络层运行，并使用地址来识别发送方和接收方。

• IPv4 与 IPv6− IPv4 是使用最广泛的版本，具有 32 位地址方案。IPv6 是 IPv4 的继任者，使用 128 位地址来适应互联网上不断增长的设备数量。

应用层协议

• HTTP/HTTPS− HTTP（超文本传输协议）是万维网数据通信的基础。HTTPS 通过加密增加了一层安全性，这对于 Web 上的安全通信至关重要。

• FTP（文件传输协议）− 用于在计算机之间传输文件。虽然广泛使用，但它已被更安全的替代方案（如 SFTP 和 FTPS）所取代，这些替代方案包含加密。

• SMTP（简单邮件传输协议）− 促进电子邮件的发送。通常与 IMAP 或 POP 结合使用以从服务器检索电子邮件。

• DNS（域名系统）− 将人类可读的域名（例如 www.example.com）转换为计算机可以理解的 IP 地址。

无线协议

• Wi-Fi (IEEE 802.11)− 一套用于无线局域网 (WLAN) 的标准，使设备能够通过无线网络进行通信。

• 蓝牙− 用于设备之间的短距离通信，例如将无线耳机连接到手机。

安全协议：确保安全通信

随着网络威胁的增加，安全协议已成为维护数据完整性、机密性和身份验证不可或缺的一部分。多个协议协同工作以保护传输中的数据。

• SSL/TLS（安全套接字层/传输层安全）− 这些协议通过加密数据来保护网络（尤其是互联网）上的通信。由于存在漏洞，SSL已被TLS取代。

• IPsec（互联网协议安全）− 一套用于保护互联网协议 (IP) 通信的协议，通过对通信会话中的每个 IP 数据包进行身份验证和加密来实现。

• SSH（安全外壳）− 提供一种安全的方法，用于通过不安全的网络进行远程登录和其他安全网络服务。

通信协议的未来

随着技术的不断发展，对更快、更安全、更可靠的通信协议的需求也在不断增长。正在开发新的协议以适应新兴技术，包括物联网 (IoT)、5G 网络和量子计算。

• 5G 协议− 第五代移动网络承诺提供更快的传输速率、更低的延迟以及对物联网设备的更好支持，这需要新的协议，例如 5G-NR（新无线电）和 5GC（5G 核心网络）。

• 物联网通信协议− MQTT（消息队列遥测传输）和 CoAP（受限应用协议）等协议轻量级，非常适合物联网设备对低功耗和低带宽的要求。

• 量子通信协议− 随着量子计算的发展，研究人员正在探索利用量子纠缠和叠加来创建安全通信通道的新协议，这可能会彻底改变加密和网络安全。

结论

通信和协议构成了现代网络的基础，使设备和系统能够高效、可靠和安全地进行通信。随着技术的进步，管理数据交换的协议也在不断发展，以适应更高的速度、增强的安全性和处理更多设备的能力等新要求。未来充满了令人兴奋的前景，5G 和量子通信等进步将重新定义我们对通信协议的思考和使用方式。

系统设计中的水平和垂直扩展

引言

随着应用程序和系统规模和复杂性的增长，确保它们保持高效和响应迅速成为一个关键挑战。这导致了对可扩展性的讨论，即系统处理增加的负载的能力。可扩展性可以通过两种主要方法实现：水平扩展（横向扩展）和垂直扩展（纵向扩展）。这两种方法都有其独特的优势、挑战和最佳使用案例。在本文中，我们将详细探讨水平和垂直扩展的概念，讨论它们各自的架构、优点和局限性，以及如何为特定场景选择正确的扩展方法。

什么是扩展？

在深入探讨水平和垂直扩展的细节之前，了解扩展的含义至关重要。

扩展是指调整资源（例如计算能力、存储或网络功能）的过程，以确保应用程序能够处理不断增长的需求，而不会牺牲性能。随着系统规模的增长以及面临更多用户、更多事务或增加的数据吞吐量，扩展确保系统保持其效率，不会成为瓶颈。

扩展有两种基本方法：垂直扩展和水平扩展。

垂直扩展（纵向扩展）

垂直扩展，或纵向扩展，是指通过向单个机器或服务器添加更强大的资源来增强其容量。这些资源可能包括：

• 添加更多 CPU（中央处理器）。

• 增加 RAM（随机存取存储器）。

• 扩展存储容量（SSD/HDD）。

• 增加网络带宽容量。

从本质上讲，垂直扩展是通过升级其组件或将其替换为更强大的版本来使单台机器更强大。

垂直扩展

在垂直扩展中，应用程序继续在同一台物理机器上运行，但机器的功能得到了改进。例如，如果托管在服务器上的应用程序由于请求数量增加而变慢，垂直扩展可能包括将该服务器替换为更强大的服务器（例如，从 16 核处理器升级到 32 核处理器）。

架构保持不变——仍然只有一台机器或节点，尽管它功能更强大。

垂直扩展的优点

• 简单性− 垂直扩展通常很简单，因为它不需要对应用程序架构进行重大更改。您只需向现有服务器添加更多资源。

• 降低复杂性− 管理单个服务器降低了操作的复杂性，包括维护和监控。

• 一致性− 由于系统运行在一台机器上，因此更容易维护数据一致性，尤其是在涉及数据库的情况下，其中一致性保证至关重要。

• 适合单体应用程序− 单体应用程序紧密耦合，难以分解成更小的组件，它们可能受益于垂直扩展，因为整个应用程序运行在一台机器上。

垂直扩展的局限性

• 单点故障− 只有在一台机器处理整个应用程序的情况下，它就成为单点故障。如果服务器崩溃或面临硬件问题，整个系统可能会崩溃。

• 资源限制− 最终，物理服务器只能升级到一定程度。可以向单台机器添加的 CPU、RAM 或存储量是有限的。这个“上限”可能会限制长期可扩展性。

• 成本− 高端服务器和组件价格昂贵。将服务器升级到最先进的硬件选项可能会导致大量的预付成本。

• 升级期间的停机时间− 根据系统的情况，升级硬件（例如添加 RAM 或存储）可能需要关闭服务器，这会导致停机时间。在关键任务系统中，即使是短暂的停机时间也可能带来问题。

水平扩展（横向扩展）

水平扩展，或横向扩展，是指向系统添加更多机器或节点，有效地将负载分配到多个设备。它不是升级单台机器的性能，而是向集群添加更多机器来分担负载。

水平扩展架构

在水平扩展中，架构设计用于分布式系统，其中多台服务器（或节点）协同工作以处理增加的负载。

例如，一个访问量激增的网站可能会添加更多服务器来处理额外的请求。通常会使用负载均衡器将流量均匀地分配到这些服务器，确保没有任何一台机器过载。在分布式数据库系统中，水平扩展意味着将数据划分到多台机器（分片）以处理更多事务或更大的数据集。

水平扩展的优点

• 理论上没有限制− 水平扩展的最大优势之一是理论上可以添加无限多的服务器。随着需求的增长，您可以继续添加机器，从而提供无限的可扩展性。

• 容错性− 由于涉及多台机器，如果一个节点发生故障，系统可以使用剩余的节点继续运行。这种冗余提供了更高的容错性。

• 规模经济− 与投资一台高端机器相比，水平扩展允许使用许多低端机器。从长远来看，这可能更经济高效，尤其是在云环境中，资源可以动态分配。

• 更适合云和分布式应用程序− 水平扩展非常适合云原生和分布式系统，例如微服务架构，其中应用程序的不同部分可以在不同的服务器上独立运行。

水平扩展的局限性

• 复杂性增加− 管理多台服务器比管理一台服务器本身更复杂。它需要更复杂的工具来进行编排、监控和负载均衡。

• 数据一致性问题− 在分布式系统中，维护多个节点之间的数据一致性可能具有挑战性，尤其是在需要强一致性的应用程序中（例如金融应用程序）。

• 网络开销− 随着服务器数量的增加，节点之间的通信也会增加，这可能会导致网络延迟和开销。确保机器之间高效通信成为一个关键问题。

• 扩展整个堆栈− 对于某些工作负载，水平扩展可能需要将整个应用程序堆栈（例如数据库、缓存和处理系统）设计为水平分布，这可能需要大量的重构。

水平扩展与垂直扩展：比较

混合方法

在许多情况下，组织同时使用水平和垂直扩展。例如，他们可能首先使用垂直扩展来满足最初的需求，然后随着需求的增加转向水平扩展。在 AWS 或 Google Cloud 等云环境中，自动扩展功能允许公司根据负载无缝地在两者之间切换。

有些系统还采用混合架构，对某些组件（例如数据库）使用垂直扩展，而对其他组件（例如 Web 服务器）使用水平扩展。这种混合方法可以兼顾两者的优势，但代价是增加了架构的复杂性。

何时选择水平或垂直扩展

水平扩展和垂直扩展的选择取决于几个因素：

• 应用程序架构− 分布式系统或微服务自然适合水平扩展，而单体应用程序更容易垂直扩展。

• 预算− 在云中，水平扩展可能更经济高效，因为可以根据需要启动额外的实例。垂直扩展由于昂贵的硬件而可能导致高成本。

• 一致性要求− 需要严格数据一致性的应用程序（例如银行系统）可能更喜欢垂直扩展，因为数据管理更简单。

• 预期增长− 如果您的应用程序预计会快速增长，则水平扩展可能更合适，因为它提供了理论上无限的可扩展性。

结论

水平扩展和垂直扩展都是系统架构中的关键概念，各有其独特的优势和挑战。垂直扩展简单易行，但受限于硬件限制，而水平扩展提供了几乎无限的可扩展性，但代价是增加了复杂性。了解这些扩展方法的细微差别对于构建高效、可靠和可扩展的系统至关重要，尤其是在更多应用程序迁移到云原生架构时。

选择合适的扩展策略取决于应用程序的架构、预算和可扩展性需求等因素。在当今云驱动的环境中，结合水平和垂直扩展优势的混合方法可能提供最大的灵活性和成本效益。

系统设计中的容量估算

引言

容量估算是系统设计中至关重要的环节，它涉及预测处理预期工作负载所需资源的过程，例如服务器容量、存储、网络带宽和数据库性能。正确的估算可以防止系统瓶颈，降低运营成本，并确保流畅的用户体验。本文探讨了容量估算中涉及的基本概念、估算方法、工具和注意事项，尤其是在大型分布式系统中。

理解容量估算

定义和重要性：将容量估算解释为一种规划策略，以确保系统能够在不发生故障的情况下处理预期和峰值工作负载。

关键指标

• 吞吐量− 每秒事务数或每秒请求数。

• 延迟− 完成事务或请求所需的时间。

• 响应时间− 用户等待响应的总时间。

• 负载和并发性− 并发用户数或操作数。

• 利用率− 已使用容量的百分比。

• 业务影响− 概述过度配置的成本影响以及配置不足的风险。

容量估算中的基本概念

• 容量与性能− 区分容量（侧重于服务数量，例如处理的请求数）和性能（强调服务质量，例如响应时间）。

• 可扩展性− 讨论如何设计系统以水平扩展（添加更多实例）和垂直扩展（升级资源）。

• 系统瓶颈− 瓶颈类型（CPU、内存、I/O、网络）及其对容量的影响。

容量估算步骤

1. 定义需求− 确定预期工作负载、峰值流量和可用性需求。

2. 分析历史数据− 使用历史系统数据查找模式并识别趋势。

3. 系统建模−

   • 工作负载建模− 描述工作负载的类型和强度（例如，读密集型与写密集型操作）。

   • 资源消耗建模− 量化每个工作负载的资源使用情况（CPU、内存、磁盘I/O）。

   • 并发性和扩展因子− 包括并发性因素，并检查每个资源如何受到影响。

4. 进行负载测试− 执行压力和负载测试以验证模型并识别瓶颈。

5. 估算增长− 根据业务预期预测工作负载增长。

6. 配置资源− 计算项目容量所需的资源，并考虑峰值使用情况的裕度。

容量估算技术

分析技术

• 排队论− 用于预测不同负载条件下的性能。

• Little’s Law（利特尔定律）− 应用于稳态系统，用于估算到达率、吞吐量和响应时间之间的关系。

经验技术

• 负载测试− 模拟真实世界负载以确定最大处理容量。

• 仿真建模− 创建系统的虚拟模型以分析资源利用率和流量模式。

• 预测技术−

  • 机器学习模型− 利用历史数据和预测模型来预测容量。

  • 时间序列分析− 分析过去的工作负载模式以预测未来的需求趋势。

容量估算工具

负载测试工具

• Apache JMeter− 用于模拟网络负载和测试系统性能。

• Gatling− 一个用于 Web 应用程序的高性能负载测试工具。

监控和分析工具

• Prometheus & Grafana− 用于监控、警报和可视化实时指标。

• Datadog− 提供性能监控，并针对资源阈值提供实时警报。

容量规划和预测工具

• Amazon CloudWatch− 提供监控和自动扩展建议。

• Google Stackdriver− GCP 的监控和日志记录，具有基于资源的容量规划。

• 自定义解决方案− 构建自定义脚本和工具来收集、分析和预测特定于系统需求的数据。

容量估算中的挑战

• 需求不确定性− 需求变化和不可预测的峰值。

• 不断变化的系统架构− 基础设施或软件更改时的挑战。

• 分布式系统复杂性− 在跨区域或数据中心扩展分布式系统时的复杂性增加。

• 资源依赖性− 资源之间复杂的相互依赖关系可能导致瓶颈或扩展问题。

• 成本效益平衡− 在成本考虑与所需的性能水平之间取得平衡。

有效容量估算的最佳实践

• 定期进行容量审查− 根据不断变化的工作负载，定期审查和更新容量计划。

• 利用自动化− 实施用于负载测试、监控和扩展的自动化工具。

• 构建冗余− 设计具有故障转移和冗余的系统，以避免单点故障。

• 监控和警报− 为关键指标设置警报，以便及早发现瓶颈。

• 与利益相关者合作− 使容量计划与业务目标、预算限制和预期增长保持一致。

结论

容量估算是系统设计中主动采取的一步，它确保了成本、性能和用户满意度之间的平衡。通过理解核心概念、采用有效的估算技术和使用正确的工具，系统架构师可以预测容量需求并构建健壮、可扩展的系统。容量估算是一个持续进行的过程，如果做得正确，可以节省成本，提高性能并优化用户体验。

Web服务器和代理在系统设计中的作用

本文介绍了在准备系统设计和架构时 Web 服务器和代理的角色。

了解 Web 服务器

定义

Web 服务器是通过互联网向客户端提供 Web 内容的软件或硬件。

功能

• 处理 HTTP 请求和响应。

• 存储和提供静态内容（HTML、CSS、JavaScript）。

• 运行动态应用程序（例如，通过 CGI、PHP 或 Spring Boot 等框架）。

Web 服务器示例

• Apache Tomcat

• Apache Http Server

• Nginx

• Microsoft IIS

Web 服务器的核心职责

内容交付

• 响应对网页和资源的请求。

• 提供静态文件并呈现动态内容。

资源管理

• 管理连接和会话。

• 负载均衡以处理多个请求。

安全特性

• 通过 SSL/TLS 支持 HTTPS。

• 基本身份验证和访问控制。

了解代理

定义

代理服务器充当客户端和目标服务器之间的中间体。

代理类型

• 正向代理− 客户端用于访问互联网。

• 反向代理− 位于 Web 服务器前面，代表它们处理请求。

常见用例

• 缓存

• 过滤

• 内容交付

代理的角色

性能优化

• 缓存经常访问的内容以减少加载时间。

• 通过压缩内容来减少带宽使用。

安全增强

• 隐藏客户端 IP 地址以实现匿名性。

• 防止攻击（例如，DDoS – 分布式拒绝服务）。

访问控制

• 根据规则过滤流量（例如，组织中的内容过滤）。

• 执行公司关于 Web 访问的策略。

Web 服务器和代理之间的相互作用

它们如何协同工作

• 代理将请求转发到 Web 服务器并将响应转发回客户端。

• 涉及反向代理后面的多个 Web 服务器的负载均衡技术。

现实世界的例子

您可以讨论一个使用代理服务器来增强 Web 服务器的性能和安全的场景。

挑战和注意事项

Web 服务器挑战

• 处理高流量。

• 管理安全漏洞。

代理挑战

• 正确配置代理以获得最佳性能。

• 在匿名性和安全性与可用性之间取得平衡。

最佳实践

• 定期更新服务器和代理的安全补丁。

• 实施监控工具来跟踪性能和安全威胁。

Web 服务器的进步

Web 服务器正在经历重大的转变，这是对速度和可扩展性需求的驱动。微服务架构的兴起促使开发人员采用轻量级 Web 服务器，这些服务器可以有效地处理大量请求。诸如Docker和Kubernetes之类的技术促进了容器化，允许应用程序在隔离的环境中运行。这种方法提高了资源利用率并简化了部署。

此外，无服务器计算的集成正在彻底改变传统的 Web 服务器模型。像 AWS Lambda 和 Azure Functions 这样的平台使开发人员能够响应事件运行代码，而无需管理服务器基础设施。这不仅降低了运营开销，而且还允许根据需求自动扩展。

安全仍然是重中之重，TLS（传输层安全）和 HTTP/3 协议的进步增强了数据保护并减少了延迟。人工智能驱动的安全解决方案的采用也在增加，有助于实时识别和减轻威胁。

集群和负载均衡

集群和负载均衡简介

集群和负载均衡对于现代应用程序至关重要，以确保它们在各种负载下具有可扩展性、高可用性和良好的性能。以下解释了它们的重要性。

集群

• 高可用性− 集群确保如果一台服务器宕机，其他服务器可以接管，最大限度地减少停机时间并确保持续可用性。

• 可扩展性− 通过向集群添加更多节点，应用程序可以处理更多用户和更多数据，而不会降低性能。

• 容错性− 集群设计为即使在单个节点发生故障时也能继续运行，从而增强了应用程序的弹性。

• 资源管理− 将工作负载分配到多个节点，优化资源使用并防止任何单个节点成为瓶颈。

负载均衡

• 高效的资源利用率− 负载均衡将传入流量分配到多台服务器，确保没有任何一台服务器过载，从而优化资源利用率。

• 性能提升− 通过平衡负载，应用程序可以更快地响应用户请求，从而增强整体用户体验。

• 冗余− 负载均衡确保如果一台服务器发生故障，流量可以重定向到其他正在运行的服务器，从而提供冗余。

• 可扩展性− 可以轻松地通过向池中添加更多服务器来扩展，允许应用程序无缝地处理越来越多的流量。

集群的关键概念

集群类型

• 高可用性 (HA) 集群− 用于容错和最小化停机时间。

• 负载均衡集群− 将工作负载分配到多个节点。如果一个节点发生故障，请求将转移到下一个节点。

• 存储集群− 用于在分布式系统中管理数据。

• 集群解决方案示例− Kubernetes、Apache Kafka、Hadoop。

负载均衡的关键概念

目标− 避免任何单台服务器过载，减少响应时间并优化资源使用。

负载均衡器类型

• 硬件负载均衡器− 专用设备。

• 软件负载均衡器− 在商品硬件或虚拟实例上运行。

• DNS 负载均衡− 使用 DNS（域名系统）将请求路由到不同的服务器。

负载均衡算法和技术

• 轮询− 请求依次分配到服务器。

• 最少连接− 将流量定向到活动连接最少的服务器。

• 加权轮询和最少连接− 根据容量为服务器分配权重。

• IP 哈希− 根据客户端的 IP 地址路由请求。

• 随机− 将请求路由到随机服务器。

• 动态负载均衡− 根据当前服务器性能进行调整。

负载均衡的工具和技术

• Nginx− 一个流行的开源反向代理和负载均衡器。

• HAProxy− 一个快速可靠的用于基于 TCP 和 HTTP 的应用程序的负载均衡器。

• AWS 弹性负载均衡 (ELB)− 用于 AWS 资源（包括 EC2 和容器）的负载均衡。

• Azure 负载均衡器− 管理 Microsoft Azure 上应用程序的流量。

• Traefik− 一个用于微服务的现代负载均衡器，内置对 Kubernetes 的支持。

集群技术和架构

• Apache Kafka− 一个支持集群的分布式流处理平台。

• Kubernetes− 管理容器化应用程序并自动扩展。

• Apache Cassandra− 一个为集群和容错而设计的分布式NoSQL数据库。

• 活跃-活跃与活跃-被动集群− 在活跃-活跃架构中，集群中的所有节点（服务器）都同时积极处理请求。在活跃-被动架构中，任何时候只有一个节点（或主要节点集）积极处理请求，而其他节点处于待机状态。

为不同应用程序配置负载均衡器

• Web应用程序− 使用HTTP/HTTPS负载均衡。

• 数据库负载均衡− 平衡读写请求（例如，使用MySQL）。

• 微服务和API− 使用负载均衡配置API网关。

• 实时应用程序− 配置WebSocket负载均衡以实现低延迟。

监控和维护集群和负载均衡系统

监控的重要性− 保证正常运行时间、性能并检测问题。

监控工具

• Prometheus和Grafana− 指标收集和可视化。

• Datadog和New Relic− 云和本地环境的端到端监控。

• ELK Stack− 用于负载均衡器和集群事件的日志分析。

• 常见的维护任务− 更新配置、扩展/缩减、处理节点故障。

识别和解决常见的负载均衡和集群问题。

以下是负载均衡和集群中常见问题的概述，以及识别和解决这些问题的策略。这些问题通常与配置错误、容量限制和网络约束有关，有效地解决这些问题有助于保持高可用性和性能。

负载分配不均

症状− 一些服务器CPU或内存使用率很高，而其他服务器则未充分利用。

原因− 这可能是由于负载均衡算法配置不当（例如，如果服务器的处理能力不相等，轮询可能效果不佳）或在加权轮询或最少连接算法中权重设置不正确。

解决方案

调整负载均衡算法，使其与应用程序的需求相匹配。使用加权负载均衡方法来匹配服务器容量。

对于基于云的解决方案，请考虑使用自动扩展策略，以便在高负载条件下自动添加资源。

会话持久性（粘性会话）问题

粘性会话，也称为会话亲和性，是一种负载均衡技术，用于确保用户的请求在整个会话过程中始终定向到同一台服务器。

症状− 用户意外注销或在重定向到不同的服务器时丢失会话数据。

原因− 如果用户的请求被路由到不同的服务器，则负载均衡器可能未配置粘性会话，从而导致会话连续性丢失。

解决方案

在负载均衡器上启用会话持久性（粘性会话），以确保来自同一会话中给定客户端的请求被路由到同一台服务器。

对于更具可扩展性的解决方案，请实现分布式会话管理（例如，将会话数据存储在数据库或Redis等分布式缓存中），以避免依赖于单个服务器。

配置漂移

症状− 节点之间行为不一致，例如不同的软件版本或配置。

原因− 手动配置更改导致集群节点之间不匹配。

解决方案

使用Ansible、Puppet或Chef等配置管理工具，确保所有节点的配置一致。

实施基础设施即代码 (IaC) 实践，使用 Terraform 等工具来强制执行版本化和一致的配置状态。

DNS负载均衡中的DNS缓存问题

症状− 即使之后，客户端也会被定向到不健康的节点。

原因− 客户端或中间解析器中的DNS缓存可能会保留已停用或故障节点的IP映射。

解决方案

减少DNS记录的生存时间 (TTL)，以确保基于DNS的负载均衡器中更改的更快传播。

使用故障转移DNS记录，如果主节点不可访问，则将流量重定向到备用节点。

日志记录和监控挑战

症状− 缺乏对流量模式、负载不平衡或故障排除延迟的洞察。

原因− 负载均衡器和集群节点上的监控或日志记录不足。

解决方案

集成Prometheus、Grafana或Datadog等监控工具以获取实时指标。

使用集中式日志记录（例如，ELK Stack或Fluentd）来聚合来自不同节点的日志并提供统一访问。

设置警报系统，以通知管理员异常模式，例如突然的流量峰值、服务器故障或高延迟。

集群和负载均衡的未来

集群和负载均衡的趋势

• 边缘计算− 将集群部署到更靠近数据源的位置以降低延迟。

• 人工智能驱动的负载均衡− 使用机器学习来优化请求路由。

• 无服务器架构− 无服务器对传统负载均衡的影响。

• 潜在挑战− 管理分布式系统的复杂性增加，安全问题。

系统开发生命周期

有效的系统开发生命周期 (SDLC) 应产生满足客户期望、在时间和成本评估范围内完成并能有效地在当前和计划的信息技术基础设施中有效运行的高质量系统。

系统开发生命周期 (SDLC) 是一种概念模型，其中包括在整个生命周期中开发或更改系统的策略和程序。

SDLC 用于分析人员开发信息系统。SDLC 包括以下活动：

• 需求
• 设计
• 实现
• 测试
• 部署
• 运营
• 维护

SDLC 的阶段

系统开发生命周期是一种系统化的方法，它明确地将工作分解成实现新的或修改后的信息系统所需的阶段。

可行性研究或规划

• 定义现有系统的问题和范围。

• 概述新系统并确定其目标。

• 确认项目可行性并制定项目进度表。

• 在此阶段，还考虑系统的威胁、约束、集成和安全性。

• 在此阶段结束时，将创建整个项目的可行性报告。

分析和规范

• 收集、分析和验证信息。

• 定义新系统需求和原型。

• 评估替代方案并确定需求的优先级。

• 检查最终用户的需求并增强系统目标。

• 在此阶段结束时，将准备一份软件需求规格说明书 (SRS) 文档，其中指定系统的软件、硬件、功能和网络需求。

系统设计

• 包括应用程序、网络、数据库、用户界面和系统界面的设计。

• 将SRS文档转换为逻辑结构，其中包含可以编程语言实现的详细和完整的规范集。

• 制定应急计划、培训计划、维护计划和运营计划。

• 审查拟议的设计。确保最终设计必须满足SRS文档中规定的要求。

• 最后，准备一份设计文档，该文档将在后续阶段使用。

实施

• 通过编码将设计实现到源代码中。

• 将所有模块组合到训练环境中，以检测错误和缺陷。

• 测试计划将生成包含错误的测试报告，该测试计划包括测试相关的任务，例如测试用例生成、测试标准和测试资源分配。

• 将信息系统集成到其环境中并安装新系统。

维护/支持

• 包括系统安装后所需的所有活动，例如用户的电话支持或现场支持。

• 实施软件在一段时间内可能发生的更改，或在软件部署到客户位置后实施任何新要求。

• 它还包括处理残余错误并解决系统中即使在测试阶段后也可能存在的任何问题。

• 大型系统可能需要较长时间的维护和支持，而小型系统则只需要较短的时间。

系统分析和设计的生命周期

下图显示了分析和设计阶段系统完整的生命周期。

系统分析师的角色

系统分析师是一个彻底了解系统并通过提供适当的方向来指导系统开发项目的人。他是一位专家，拥有在每个阶段执行所需开发任务的技术和人际交往能力。

他努力使信息系统的目标与组织目标相匹配。

主要角色

• 通过各种事实调查技术定义和理解用户的需求。

• 通过获得用户共识来确定需求的优先级。

• 收集事实或信息并获取用户的意见。

• 进行分析和评估，以获得更用户友好的适当系统。

• 提出许多灵活的替代解决方案，选择最佳解决方案，并量化成本和效益。

• 绘制某些规范，这些规范易于用户和程序员以精确和详细的形式理解。

• 实施系统的逻辑设计，该设计必须是模块化的。

• 计划在系统使用一段时间后进行评估的周期性，并根据需要修改系统。

系统分析师的属性

下图显示了系统分析师应具备的属性：

人际交往能力

• 与用户和程序员互动。
• 促进团队合作并领导小型团队。
• 管理期望。
• 良好的理解、沟通、销售和教学能力。
• 能够自信地解决问题的激励者。

分析能力

• 系统研究和组织知识
• 问题识别、问题分析和问题解决
• 良好的常识
• 权衡取舍的能力
• 对学习新组织的好奇心

管理技能

• 理解用户的术语和实践。
• 资源和项目管理。
• 变更和风险管理。
• 透彻理解管理职能。

技术技能

• 掌握计算机和软件知识。
• 紧跟现代发展潮流。
• 了解系统设计工具。
• 掌握新技术的广度知识。

系统分析与设计 - 需求确定

引言

在系统分析和设计领域，需求确定是一个至关重要的阶段，它为成功的软件开发奠定了基础。它涉及收集、分析和记录利益相关者的需求和期望，以确保最终系统满足其预期目的。本文探讨了需求确定的重要性、其方法、挑战和最佳实践，为新手和经验丰富的实践者提供全面的概述。

需求确定的重要性

需求确定至关重要，原因如下：

• 明确目的——清晰定义的需求有助于利益相关者理解系统的目的和功能，减少歧义。

• 满足利益相关者——尽早参与利益相关者并准确捕捉他们的需求，从而提高对最终产品的满意度。

• 成本和时间效率——完善的需求文档最大限度地减少了后期开发阶段代价高昂的变更风险，从而提高了项目生命周期的效率。

• 风险管理——尽早识别潜在问题，使团队能够在风险升级之前制定策略来降低风险。

• 开发框架——需求作为系统设计、编码、测试和实施的指导，确保整个开发过程中的协调一致。

需求确定方法

在需求确定阶段可以采用多种方法，每种方法都有其优缺点：

访谈

访谈涉及与利益相关者直接讨论，以引出他们的需求和偏好。访谈可以是有结构的、半结构的或无结构的，允许灵活地收集信息。

优点

• 直接获取用户见解。

• 有机会进行后续提问和澄清。

缺点

• 耗时。

• 如果没有仔细管理，可能会出现有偏差的回应。

调查问卷

调查问卷允许从更大范围的利益相关者群体中收集数据。它们可用于收集定量数据，从而更容易分析趋势和共同需求。

优点

• 快速覆盖广泛受众。

• 可以提供统计数据。

缺点

• 信息深度有限。

• 潜在的回应率低。

研讨会和焦点小组

研讨会和焦点小组在协作环境中召集利益相关者讨论需求。这种方法鼓励互动，并可能产生创造性的解决方案。

优点

• 促进协作和讨论。

• 产生多样化的想法和观点。

缺点

• 主导性声音可能会掩盖较安静的参与者。

• 需要熟练的引导才能有效。

观察

观察包括在用户的自然环境中研究他们如何与现有系统交互。这种方法可以揭示隐藏的需求和工作流程。

优点

• 提供现实世界的背景。

• 可以发现用户可能无法表达的问题。

缺点

• 非常耗时。

• 观察者偏差可能会影响结果。

文档分析

审查现有文档（例如用户手册、系统规范和业务流程图）可以深入了解现有系统，并为新需求提供信息。

优点

• 利用现有知识。

• 识别现有系统的差距。

缺点

• 文档可能已过时或不完整。

• 需要专业知识才能有效地进行解读。

需求确定的挑战

尽管需求确定非常重要，但它也充满了挑战：

• 需求变更——随着项目的进展，利益相关者可能会改变他们的需求，使流程复杂化。

• 利益相关者冲突——不同的利益相关者可能具有冲突的需求或优先级，使得达成共识变得困难。

• 沟通障碍——由于术语、假设或不同视角而可能出现误解，导致需求不完整或不正确。

• 信息不完整——利益相关者可能无法完全理解他们的需求，导致需求存在差距。

• 时间限制——紧张的项目时间表可能会迫使团队匆忙完成需求确定阶段，从而增加出错的可能性。

有效需求确定的最佳实践

为了克服挑战并提高需求确定的有效性，请考虑以下最佳实践：

• 尽早并经常让利益相关者参与——从一开始就让用户和利益相关者参与，并在整个项目过程中保持持续沟通。

• 使用多种技术——采用多种方法来收集全面的见解并验证结果。

• 清晰地记录需求——使用清晰、简洁的语言和结构化格式（例如，用例、用户故事）来记录需求，以便于参考。

• 确定需求优先级——与利益相关者一起根据业务价值、可行性和紧迫性确定需求的优先级，确保首先满足关键需求。

• 定期进行审查——与利益相关者定期审查需求，并在必要时进行验证和调整，确保整个项目中的协调一致。

• 利用原型设计——使用原型或线框图来可视化需求并收集反馈，帮助利益相关者澄清他们的需求。

• 保持可追溯性——建立可追溯性矩阵，跟踪从初始收集到设计、开发和测试的需求，确保满足所有需求。

结论

需求确定是系统分析和设计过程中至关重要的一步。通过了解其重要性、采用适当的方法、应对挑战和遵循最佳实践，组织可以大大提高项目成功的可能性。有效执行的需求确定阶段不仅能够产生满足用户需求的系统，还能促进协作，降低风险，最终促进利益相关者的满意度和业务成功。

系统分析与设计 - 系统实施

引言

• 系统实施在项目管理和IT中的定义和意义。

• 弥合设计与运营之间差距的作用。

• 实施新系统关键步骤的概述。

实施规划

定义范围和目标

• 理解项目目标。

• 将实施与业务战略保持一致的重要性。

资源分配

• 确定资源（人力、技术和财务）。

• 资源规划和时间表管理。

风险评估

• 识别潜在的实施风险。

• 制定应急计划以降低风险。

选择正确的实施方法

大爆炸式方法

• 一次性用新系统替换旧系统。

• 立即过渡的优缺点。

分阶段实施

• 分阶段逐步部署。

• 控制范围和用户适应性的好处。

并行实施

• 同时运行旧系统和新系统。

• 验证和测试的优势。

试点实施

• 在有限的区域部署系统以评估性能。

• 在全面推广之前降低风险的好处。

为变革做准备

变更管理

• 建立开放的系统变更文化。

• 应对新系统抵制的策略。

培训计划

• 设计培训以确保用户熟练掌握。

• 持续学习和支持在成功实施中的作用。

沟通规划

• 在整个实施过程中让利益相关者知情。

• 清晰透明沟通的技术。

测试和质量保证

测试的重要性

• 测试类型（例如，单元测试、集成测试、用户验收测试）。

• 上线前确保可靠性和性能。

用户验收测试 (UAT)

• 用户在真实场景中验证的重要性。

• 收集反馈并改进系统。

质量控制措施

• 定义性能和用户满意度的基准。

• 实施反馈循环以持续改进。

系统上线和推广

最终准备

• 验证系统功能和安全性。

• 建立数据迁移和备份流程。

执行推广

• 遵循清晰的已记录上线策略。

• 监控性能并管理用户咨询。

实施后支持

• 帮助台和技术支持计划。

• 推广后快速响应问题的重要性。

评估和监控

评估系统性能

• 评估功能、速度和可靠性的指标。

• 收集定量和定性数据。

用户反馈和调整

• 收集用户反馈以衡量满意度。

• 根据实际用户的需求规划更新或修改。

维护和持续改进

• 建立维护计划以确保持续的可靠性。

• 找出系统改进的机会。

案例研究和最佳实践

成功实施的示例

• 简要案例研究，重点介绍各种方法（例如，分阶段、试点）。

经验教训

• 常见的挑战以及如何克服这些挑战。

• 无缝实施的最佳实践。

结论

系统实施关键步骤的回顾：

• 强调精心规划和执行的战略重要性。

• 关于灵活性和适应性在成功实施中的作用的最终思考。

系统分析与设计 - 系统规划

什么是需求确定？

需求是新系统的一个重要特征，可能包括数据的处理或捕获、控制业务活动、生成信息和支持管理。

需求确定包括研究现有系统并收集详细信息，以了解需求是什么，它是如何工作的，以及应该在哪里改进。

需求确定的主要活动

需求预测

• 它根据以往经验预测系统的特性，包括某些问题或特性以及新系统的需求。

• 它可以导致分析那些没有经验的分析师可能忽略的领域。但如果采取捷径并在调查中引入偏差，那么需求预测就可能是不完整的。

需求调查

• 它研究当前系统并记录其功能以进行进一步分析。

• 它是系统分析的核心，分析师使用事实调查技术、原型设计和计算机辅助工具来记录和描述系统功能。

需求规范

• 它包括确定需求规范的数据分析、新系统功能的描述以及指定将提供哪些信息需求。

• 它包括对事实数据的分析、基本需求的识别和需求满足策略的选择。

信息收集技术

事实调查技术的主要目标是确定组织的信息需求，分析师使用这些信息来准备用户能够理解的精确SRS。

理想的SRS文档应：

• 完整、明确且无专业术语。
• 指定操作、战术和战略信息需求。
• 解决用户和分析师之间可能存在的争议。
• 使用图形辅助工具，简化理解和设计。

有各种信息收集技术：

访谈

系统分析师通过访谈从个人或群体那里收集信息。分析师可以是正式的、法律的、玩政治的，或者是非正式的；因为访谈的成功取决于分析师作为访谈者的技能。

它可以通过两种方式完成：

• 非结构化访谈——系统分析师进行问答环节以获取系统的基本信息。

• 结构化访谈——它包含标准问题，用户需要以封闭式（客观）或开放式（描述性）格式回答。

访谈的优点

• 这种方法通常是收集定性信息的最佳来源。

• 这对那些书面表达能力不强或没有时间填写问卷的人来说非常有用。

• 信息可以立即轻松验证和交叉检查。

• 它可以处理复杂的问题。

• 通过征求意见，很容易发现关键问题。

• 它弥合了误解方面的差距，并最大限度地减少了未来问题。

问卷调查

分析师使用这种方法从大量人员那里收集关于系统各个问题的资料。

问卷调查有两种类型：

• **开放式问卷** - 它包含易于正确解释的问题。它们可以探讨问题，并引导到具体的答案方向。

• **封闭式问卷** - 当系统分析师有效地列出所有可能的、相互排斥的答案时，就会使用这类问题。

问卷调查的优点

• 它在调查不在同一地点的用户兴趣、态度、感受和信念方面非常有效。

• 在需要了解给定群体中多大比例的人赞成或反对拟议系统的特定功能的情况下，它非常有用。

• 在为系统项目制定任何具体方向之前，它有助于确定总体意见。

• 它更可靠，并能提供诚实回复的高度保密性。

• 它适用于收集事实信息和统计数据，可以通过电子邮件和邮寄发送。

记录、流程和表单的审查

审查现有的记录、流程和表单有助于深入了解系统，描述当前系统的功能、操作或活动。

优点

• 它帮助用户在向他人施加影响之前，自己了解一些关于组织或运营的知识。

• 由于程序手册和表格描述了现有系统的格式和功能，因此它有助于在短时间内记录当前的操作。

• 它可以清楚地了解组织中处理的交易，识别处理的输入并评估绩效。

• 它可以帮助分析师从必须支持的操作方面来理解系统。

• 它描述了问题、受影响的部分和拟议的解决方案。

观察

这是一种通过注意和观察人员、事件和对象来收集信息的方法。分析师访问组织以观察当前系统的运行情况并了解系统的需求。

优点

• 这是一种直接收集信息的方法。

• 在收集数据的真实性受到质疑，或者系统某些方面的复杂性妨碍最终用户清晰解释的情况下，它非常有用。

• 它产生更准确可靠的数据。

• 它能找出所有不完整和过时的文档方面。

联合应用程序开发 (JAD)

这是IBM开发的一项新技术，它将所有者、用户、分析师、设计师和构建者聚集在一起，利用有组织和密集的研讨会来定义和设计系统。经过JAD培训的分析师担任研讨会的促进者，他们拥有一些专业技能。

JAD的优点

• 它通过替代数月的传统访谈和后续会议来节省时间和成本。

• 它适用于支持联合解决问题的组织文化。

• 促进多个层级的员工之间的正式关系。

• 它可以带来创造性的设计开发。

• 它允许快速开发并提高信息系统的拥有权。

二次研究或背景阅读

这种方法广泛用于通过访问收集到的信息来收集信息。它包括营销人员从任何内部或外部来源使用的任何先前收集的信息。

优点

• 随着互联网的普及，它更容易访问。

• 它以低成本和时间提供有价值的信息。

• 它作为主要研究的先驱，并确定主要研究的重点。

• 研究人员可以使用它来判断研究是否值得，因为它提供了所用程序和收集过程中遇到的问题。

可行性研究

可行性研究可以被认为是初步调查，它帮助管理层决定是否应该对系统进行可行性研究。

• 它确定改进现有系统、开发新系统以及为系统进一步开发产生改进的估计的可能性。

• 它用于获取问题的概要，并确定是否存在可行或适当的解决方案。

• 可行性研究的主要目标是确定问题的范围，而不是解决问题。

• 可行性研究的输出是一个正式的系统建议书，作为决策文件，其中包括拟议系统的完整性质和范围。

可行性分析中涉及的步骤

执行可行性分析时，应遵循以下步骤：

• 组建项目团队并任命项目负责人。

• 开发系统流程图。

• 确定当前系统的缺陷并设定目标。

• 列举满足目标的替代方案或潜在候选系统。

• 确定每个替代方案的可行性，例如技术可行性、运营可行性等。

• 权衡每个候选系统的性能和成本效益。

• 对其他方案进行排名并选择最佳候选系统。

• 向管理层提交最终项目指令的系统建议书以供批准。

可行性类型

经济可行性

• 它使用成本/效益分析方法评估候选系统的有效性。

• 它以组织的收益和成本表示候选系统的净收益。

• 经济可行性分析 (EFS) 的主要目标是在投资资金投入提案之前，估计候选系统的经济需求。

• 它更倾向于能够通过最早和最高的资金回报以及开发候选系统所涉及的最低风险来最大化组织净值的替代方案。

技术可行性

• 它调查每个实施方案的技术可行性。

• 它分析并确定现有技术是否能够支持该解决方案。

• 分析师确定是否需要升级或添加当前技术资源以满足新的需求。

• 它确保候选系统提供适当的响应，以及它在多大程度上能够支持技术增强。

运营可行性

• 它确定系统在开发和实施后是否有效运行。

• 它确保管理层应支持拟议的系统，并且其运作在当前的组织环境中是可行的。

• 它分析用户是否会受到影响，以及他们是否接受可能影响系统效益的修改后的或新的业务方法。

• 它还确保候选系统的计算机资源和网络架构是可行的。

行为可行性

• 它评估和估计用户对新系统开发的态度或行为。

• 它有助于确定系统是否需要特别努力来教育、再培训、转移和改变员工在新的业务开展方式上的工作状态。

进度可行性

• 它确保项目应在给定的时间约束或进度内完成。

• 它还验证和确认项目截止日期是否合理。

结构化分析

分析师使用各种工具来理解和描述信息系统。其中一种方法是使用结构化分析。

什么是结构化分析？

结构化分析是一种开发方法，允许分析师以逻辑的方式理解系统及其活动。

这是一种系统的方法，它使用图形工具来分析和改进现有系统的目标，并开发新的系统规范，用户可以轻松理解。

它具有以下属性：

• 它是图形化的，指定了应用程序的表示。

• 它将流程分解，以便清晰地显示系统流程。

• 它是逻辑的而不是物理的，即系统的元素不依赖于供应商或硬件。

• 这是一种从高级概述到低级细节的方法。

结构化分析工具

在结构化分析中，各种工具和技术用于系统开发。它们是：

• 数据流程图
• 数据字典
• 决策树
• 决策表
• 结构化英语
• 伪代码

数据流程图 (DFD) 或气泡图

这是Larry Constantine开发的一种技术，用于以图形形式表达系统的需求。

• 它显示了系统各个功能之间的数据流，并指定了当前系统是如何实现的。

• 它是设计阶段的初始阶段，它将需求规范按功能分解到最低的细节级别。

• 其图形化性质使其成为用户和分析师或分析师和系统设计师之间良好的沟通工具。

• 它概述了系统处理哪些数据、执行哪些转换、存储哪些数据、产生哪些结果以及结果在哪里流动。

DFD的基本元素

DFD易于理解，在所需设计不明确且用户需要一种符号语言进行沟通时非常有效。但是，它需要大量的迭代才能获得最准确和完整的解决方案。

下表显示了设计DFD时使用的符号及其意义：

DFD类型

DFD有两种类型：物理DFD和逻辑DFD。下表列出了区分物理DFD和逻辑DFD的要点。

上下文图

上下文图通过一个DFD帮助理解整个系统，该DFD概述了系统。它从提及主要流程（细节很少）开始，然后采用自上而下的方法，给出流程的更多细节。

下面显示了餐饮管理的上下文图。

数据字典

数据字典是系统中数据元素的结构化存储库。它存储所有DFD数据元素的描述，即数据流、数据存储、数据存储中存储的数据以及流程的详细信息和定义。

数据字典可以改善分析师和用户之间的沟通。它在构建数据库中扮演着重要的角色。大多数数据库管理系统 (DBMS) 都将数据字典作为标准功能。例如，参考下表：

决策树

决策树是一种通过描述决策并避免沟通问题来定义复杂关系的方法。决策树是一个图表，它显示了水平树框架内的替代行动和条件。因此，它描述了首先、其次等等要考虑哪些条件。

决策树描述了每个条件及其允许的操作之间的关系。方形节点表示操作，圆形节点表示条件。它迫使分析师考虑决策的顺序，并确定必须做出的实际决策。

决策树的主要局限性在于，它的格式中缺乏信息来描述可以进行测试的其他条件组合。它是条件和操作之间关系的单一表示。

例如，参考下面的决策树：

决策表

决策表是一种以精确易懂的方式描述复杂逻辑关系的方法。

• 在结果操作取决于一个或多个独立条件组合发生的情况下，它非常有用。

• 它是一个矩阵，包含用于定义问题和操作的行或列。

决策表的组成部分

• 条件存根 - 它位于左上角象限，列出了所有要检查的条件。

• 动作存根 - 它位于左下象限，概述了为满足此类条件而执行的所有操作。

• 条件项 - 它位于右上角象限，提供了对条件存根象限中提出的问题的答案。

• 动作项 - 它位于右下象限，指示条件项象限中对条件的答案所产生的适当操作。

决策表中的条目由决策规则给出，这些规则定义了条件组合和行动过程之间的关系。在规则部分：

• Y 表示条件的存在。
• N 表示条件不满足。
• 动作前的空白 - 表示应忽略它。
• 动作前的 X（或勾号）表示应执行它。

例如，参考下表：

结构化英语

结构化英语源于结构化编程语言，它对过程的描述更加易懂和精确。它基于过程逻辑，使用旨在执行操作的构造和祈使句。

• 当必须考虑程序中的序列和循环，并且问题需要带决策的行动序列时，它最有效。

• 它没有严格的语法规则。它用顺序决策结构和迭代来表达所有逻辑。

例如，参见以下操作序列：

if customer pays advance 
   then 
      Give 5% Discount 
   else 
      if purchase amount >=10,000 
         then 
            if  the customer is a regular customer 
               then Give 5% Discount 
            else  No Discount
         end if 
      else No Discount  
   end if 
end if 

伪代码

伪代码不符合任何编程语言，并用简单的英语表达逻辑。

• 它可以在物理设计期间和之后指定物理编程逻辑，而无需实际编码。

• 它与结构化编程一起使用。

• 它取代了程序的流程图。

选择合适的工具的指导原则

使用以下指导原则来选择最适合您需求的工具：

• 在高级或低级分析中使用 DFD 来提供良好的系统文档。

• 使用数据字典来简化结构，以满足系统的需求。

• 如果存在许多循环且操作复杂，则使用结构化英语。

• 如果要检查大量条件且逻辑复杂，则使用决策表。

• 如果条件的顺序很重要，并且只有少量条件需要测试，则使用决策树。

系统分析与设计 - 系统设计

系统设计是弥合问题域和现有系统之间差距的阶段，以可管理的方式进行。此阶段侧重于解决方案域，即“如何实现？”

在此阶段，SRS 文档将转换为可实现的格式，并决定系统将如何运行。

在此阶段，系统开发的复杂活动将被划分为几个较小的子活动，这些子活动相互协调以实现系统开发的主要目标。

系统设计的输入

系统设计采用以下输入：

• 工作说明

• 需求确定计划

• 现状分析

• 拟议的系统需求，包括概念数据模型、修改后的 DFD 和元数据（关于数据的数据）。

系统设计的输出

系统设计给出以下输出：

• 拟议系统的基础设施和组织变化。

• 数据模式，通常是关系模式。

• 定义表/文件和列/数据项的元数据。

• 功能层次图或网页地图，以图形方式描述程序结构。

• 程序中每个模块的实际或伪代码。

• 拟议系统的原型。

系统设计的类型

逻辑设计

逻辑设计与系统的数据流、输入和输出的抽象表示有关。它描述了输入（来源）、输出（目的地）、数据库（数据存储）、过程（数据流），所有这些都以满足用户需求的格式呈现。

在准备系统的逻辑设计时，系统分析师会详细说明用户需求，这实际上决定了系统输入和输出的信息流以及所需的数据源。使用数据流图、E-R 图建模。

物理设计

物理设计与系统的实际输入和输出过程有关。它侧重于如何将数据输入系统、验证、处理和显示为输出。

它通过定义精确指定候选系统功能的设计规范来生成工作系统。它关注用户界面设计、流程设计和数据设计。

它包括以下步骤：

• 指定输入/输出媒体、设计数据库和指定备份程序。

• 计划系统实施。

• 制定测试和实施计划，并指定任何新的硬件和软件。

• 更新成本、效益、转换日期和系统限制。

架构设计

它也称为高级设计，侧重于系统架构的设计。它描述了系统的结构和行为。它定义了系统开发过程中各个模块的结构和关系。

详细设计

它遵循架构设计，并侧重于每个模块的开发。

概念数据建模

它是组织数据的表示，包括所有主要实体和关系。系统分析师为当前系统开发一个概念数据模型，该模型支持拟议系统的范围和需求。

概念数据建模的主要目标是尽可能多地捕获数据的含义。如今，大多数组织使用 E-R 模型进行概念数据建模，该模型使用特殊符号来尽可能多地表示关于数据的含义。

实体关系模型

这是一种用于数据库设计中的技术，有助于描述组织中各种实体之间的关系。

E-R 模型中使用的术语

• 实体 - 它指定应用程序中不同的现实世界项目。例如：供应商、项目、学生、课程、教师等。

• 关系 - 它们是实体之间有意义的依赖关系。例如，供应商供应商品，教师教授课程，则供应和课程是关系。

• 属性 - 它指定关系的属性。例如，供应商代码、学生姓名。E-R 模型中使用的符号及其含义：

下表显示了 E-R 模型中使用的符号及其意义：

两组数据之间可以存在三种关系：一对一、一对多和多对多。

文件组织

它描述了记录如何在文件中存储。

有四种文件组织方法：

• 串行 - 记录按时间顺序存储（按输入或发生的顺序）。示例 - 电话费记录、ATM 交易、电话队列。

• 顺序 - 记录按关键字段的顺序存储，该字段包含唯一标识记录的值。示例 - 电话簿。

• 直接（相对） - 每条记录都基于设备上的物理地址或位置进行存储。地址是根据记录关键字段中存储的值计算出来的。随机化例程或哈希算法进行转换。

• 索引 - 记录可以使用索引顺序和非顺序地进行处理。

比较

文件访问

可以使用顺序访问或随机访问访问文件。文件访问方法允许计算机程序读取或写入文件中的记录。

顺序访问

文件中的每条记录都从第一条记录开始处理，直到到达文件结尾 (EOF)。当需要在任何给定时间访问大量文件记录时，这种方法非常高效。存储在磁带上的数据（顺序访问）只能顺序访问。

直接（随机）访问

记录是通过知道它们在设备上的物理位置或地址来定位的，而不是它们相对于其他记录的位置。存储在 CD 设备上的数据（直接访问）可以顺序或随机访问。

组织系统中使用的文件类型

以下是组织系统中使用的文件类型：

• 主文件 - 包含系统当前信息。例如，客户文件、学生文件、电话簿。

• 表文件 - 是一种很少更改并以表格格式存储的主文件类型。例如，存储邮政编码。

• 事务文件 - 包含从业务活动生成的日常信息。用于更新或处理主文件。例如，员工的地址。

• 临时文件 - 系统在需要时创建和使用。

• 镜像文件 - 它们是其他文件的精确副本。有助于最大限度地减少原始文件无法使用时的停机风险。每次修改原始文件时，都必须修改它们。

• 日志文件 - 包含主记录和事务记录的副本，以便记录对主文件所做的任何更改。它有助于审计，并在系统发生故障时提供恢复机制。

• 存档文件 - 包含其他文件历史版本的备份文件。

文档控制

文档化是记录信息以供参考或操作目的的过程。它可以帮助需要它的用户、管理人员和 IT 员工。重要的是，准备好的文档必须定期更新，以便轻松追踪系统的进度。

如果系统在实施后运行不正常，则文档可以帮助管理员了解系统中的数据流，从而纠正缺陷并使系统正常运行。

程序员或系统分析师通常创建程序和系统文档。系统分析师通常负责准备文档以帮助用户学习系统。在大公司中，包括技术撰写人在内的技术支持团队可能会协助准备用户文档和培训材料。

优点

• 它可以减少系统停机时间，降低成本并加快维护任务。

• 它提供了对现有系统正式流程的清晰描述，并有助于了解输入数据类型以及如何生成输出。

• 它提供了一种在技术用户和非技术用户之间有效沟通系统信息的有效方法。

• 它有助于培训新用户，以便他们可以轻松理解系统流程。

• 它帮助用户解决诸如故障排除等问题，并帮助管理者做出更好的组织系统最终决策。

• 它为系统的内部或外部工作提供了更好的控制。

文档类型

在系统设计方面，主要有以下四种文档：

• 程序文档
• 系统文档
• 操作文档
• 用户文档

程序文档

• 它描述了所有程序模块的输入、输出和处理逻辑。

• 程序文档过程从系统分析阶段开始，并在实施过程中继续。

• 此文档指导程序员构建模块，这些模块由内部和外部注释以及易于理解和维护的描述良好地支持。

操作文档

操作文档包含处理和分发在线和打印输出所需的所有信息。操作文档应清晰、简洁，并尽可能在线提供。

它包含以下信息：

• 程序、系统分析师、程序员和系统标识。

• 打印输出的调度信息，例如报表、执行频率和截止日期。

• 输入文件及其来源、输出文件及其目标。

• 电子邮件和报表分发列表。

• 所需的特殊表格，包括在线表格。

• 操作员的错误和信息消息以及重新启动程序。

• 特殊说明，例如安全要求。

用户文档

它包括与系统交互的用户指南和信息。例如，用户手册、帮助指南和教程。用户文档对于培训用户和参考用途非常有价值。它必须清晰、易懂，并且所有级别的用户都可以轻松访问。

用户、系统所有者、分析师和程序员共同努力开发用户指南。

用户文档应包括：

• 清晰描述所有主要系统功能、能力和限制的系统概述。

• 源文档内容、准备、处理和样本的描述。

• 菜单和数据输入屏幕选项、内容和处理说明的概述。

• 定期生成或根据用户请求提供的报表的示例，包括样本。

• 安全和审计跟踪信息。

• 对特定输入、输出或处理要求的责任说明。

• 请求更改和报告问题的程序。

• 异常和错误情况的示例。

• 常见问题解答 (FAQ)。

• 如何获得帮助以及更新用户手册的程序说明。

系统文档

系统文档作为 IS 的技术规范以及如何实现 IS 的目标。用户、管理人员和 IS 所有者无需参考系统文档。在进行修改时，系统文档为理解 IS 的技术方面提供了基础。

• 它描述了 IS 中的每个程序以及整个 IS 本身。

• 它描述了系统的功能、实现方式、每个程序在整个 IS 中相对于执行顺序的目的、传递到程序和从程序传递的信息以及整体系统流程。

• 它包括数据字典条目、数据流图、对象模型、屏幕布局、源文档以及启动项目的系统请求。

• 大部分系统文档是在系统分析和系统设计阶段准备的。

• 在系统实施过程中，分析师必须检查系统文档以验证其完整性、准确性和最新性，包括在实施过程中所做的任何更改。

设计策略

自顶向下策略

自顶向下策略使用模块化方法来开发系统设计。之所以这样称呼它，是因为它从顶部或最高级别模块开始，然后移向最低级别模块。

在此技术中，将识别用于开发软件的最高级别模块或主模块。主模块根据每个模块执行的任务，细分为几个更小、更简单的子模块或段。然后，每个子模块进一步细分为下一级别（更低级别）的几个子模块。将每个模块细分为几个子模块的此过程将持续进行，直到识别出无法进一步细分的最低级别模块。

自底向上策略

自底向上策略遵循模块化方法来开发系统设计。之所以这样称呼它，是因为它从底部或最基本的级别模块开始，然后移向最高级别模块。

在此技术中，

• 将识别最基本或最低级别的模块。

• 然后，根据每个模块执行的功能将这些模块组合在一起，以形成下一级别（更高级别）的模块。

• 然后，将这些模块进一步组合以形成下一级别（更高级别）的模块。

• 将几个更简单的模块组合在一起以形成更高级别模块的此过程将持续进行，直到实现系统开发过程的主模块。

结构化设计

结构化设计是一种基于数据流的方法，有助于识别正在开发系统的输入和输出。结构化设计的目标是最大限度地降低程序的复杂性并提高其模块化程度。结构化设计还有助于描述系统的功能方面。

在结构化设计中，系统规范作为图形化表示软件开发中涉及的数据流和过程序列的基础，借助 DFD 来实现。为软件系统开发 DFD 后，下一步是开发结构图。

模块化

结构化设计将程序划分为小型独立模块。这些模块以自顶向下的方式组织，详细信息显示在底部。

因此，结构化设计使用称为模块化或分解的方法来最大限度地降低复杂性，并通过将问题细分为较小的部分来管理问题。

优点

• 首先测试关键接口。
• 它提供抽象。
• 它允许多个程序员同时工作。
• 它允许代码重用。
• 它提供控制并提高士气。
• 它使识别结构更容易。

结构图

结构图是设计模块化自顶向下系统的推荐工具，它定义了系统开发的各个模块以及各个模块之间的关系。它显示了系统模块及其相互之间的关系。

它由一个图表组成，该图表包含代表模块的矩形框、连接箭头或线。

• 控制模块 - 它是指导较低级别模块（称为下级模块）的较高级别模块。

• 库模块 - 它是一个可重用模块，可以从图表中的多个点调用。

我们有两种不同的方法来设计结构图：

• 变换中心结构图 - 当所有事务都遵循相同的路径时使用。

• 事务中心结构图 - 当所有事务不遵循相同的路径时使用。

使用结构流程图的目标

• 鼓励自顶向下设计。

• 支持模块的概念并识别合适的模块。

• 显示系统的规模和复杂性。

• 识别每个功能中易于识别的功能和模块的数量。

• 描述每个可识别功能是否为可管理的实体，或者是否应将其分解成更小的组件。

影响系统复杂性的因素

为了开发高质量的系统软件，必须开发良好的设计。因此，在开发系统设计时，主要关注的是软件设计质量。高质量的软件设计是指最大限度地减少软件开发中复杂性和成本支出的设计。

与系统开发相关的两个重要概念有助于确定系统的复杂性，它们是**耦合**和**内聚**。

耦合

耦合是衡量组件独立性的指标。它定义了系统开发中每个模块对其他模块的依赖程度。实际上，这意味着系统中模块之间的耦合越强，系统就越难实现和维护。

每个模块都应该与其他模块具有简单、清晰的接口，并且模块之间共享的数据元素数量应最小。

高耦合

这类系统具有程序单元之间的互连，这些单元相互依赖。对一个子系统的更改会对其他子系统产生重大影响。

低耦合

这类系统由独立或几乎独立的组件组成。一个子系统的更改不会影响任何其他子系统。

耦合度量

• **内容耦合** - 当一个组件实际修改另一个组件时，被修改的组件完全依赖于修改它的组件。

• **公共耦合** - 通过组织系统设计以便可以从公共数据存储区访问数据，从而在某种程度上降低耦合量。

• **控制耦合** - 当一个组件传递参数来控制另一个组件的活动时。

• **标记耦合** - 当使用数据结构将信息从一个组件传递到另一个组件时。

• **数据耦合** - 当仅传递数据时，组件通过这种耦合连接。

内聚

内聚是衡量其组件之间关系密切程度的指标。它定义了模块的组件相互依赖的程度。实际上，这意味着系统设计人员必须确保：

• 他们不会将基本流程分割成碎片化的模块。

• 他们不会将DFD中表示为流程的无关流程组合成毫无意义的模块。

最好的模块是功能内聚的模块。最差的模块是偶然内聚的模块。

最低程度的内聚

偶然内聚存在于其各部分彼此无关的组件中。

• **逻辑内聚** - 将多个逻辑相关的函数或数据元素放在同一个组件中。

• **时间内聚** - 当用于初始化系统或设置变量的组件按顺序执行多个函数时，但这些函数通过所涉及的时间相关联。

• **过程内聚** - 将函数组合在一个组件中只是为了确保此顺序。

• **顺序内聚** - 当一个组件的一部分的输出是其下一部分的输入时。

系统分析与设计 - 软件部署

引言

**软件部署**是将软件应用程序或更新发布和安装到目标环境（例如生产服务器、用户设备或云基础设施）的过程，以使其可供最终用户或客户使用。它包含多个阶段，包括准备、安装、配置、测试，有时还包括部署后支持。

在**软件开发生命周期 (SDLC) 中，部署**是将软件从开发阶段过渡到实时运行状态的关键阶段，为用户提供其价值。部署过程可能因项目的复杂性和组织对软件管理的方法（例如敏捷或DevOps实践）而异。

以下是其在SDLC中的重要性概述：

实现用户的价值

• **SDLC 的目标** - SDLC 中的每个阶段（例如计划、设计、开发和测试）都旨在构建满足用户需求的产品。但是，部署是这项工作实际实现并呈现给最终用户的阶段，使其成为所有先前阶段的最终结果。

• **对业务的影响** - 部署对于交付新功能、解决错误和应用改进至关重要，这直接影响客户满意度和业务价值。

确保生产环境的稳定性和可靠性

• **风险管理** - 受控部署允许组织管理与实时环境变化相关的风险。通过使用分阶段推出或蓝绿部署等方法，可以最大限度地减少问题，从而提高稳定性。

• **质量保证** - 尽管在部署之前完成了测试，但部署过程通常包括最终检查、特定于环境的配置和监控，以确保应用程序在生产环境中稳定。

支持持续集成和交付 (CI/CD)

• **敏捷性和响应能力** - 在现代 SDLC 实践中，特别是敏捷和 DevOps，部署与 CI/CD 管道紧密相连，其中代码更改会自动进行测试和部署。这允许频繁更新，帮助企业快速响应用户反馈和市场需求。

• **自动化优势** - 部署自动化最大限度地减少人为错误，提高一致性，并加快部署过程，符合 CI/CD 的目标。

增强安全性和合规性

• **安全补丁和更新** - 部署对于确保应用程序安全和最新至关重要。及时部署安全补丁可以防止漏洞被利用。

• **合规性** - 对于许多行业而言，合规性标准需要特定的部署实践和文档，这些对于实现法规遵从性至关重要。

优化资源利用和成本效率

• **高效利用资源** - 自动化和计划良好的部署管道有助于减少停机时间，释放资源用于其他开发和运营任务。

• **节省成本** - 部署优化（例如零停机策略或容器化）可以通过最大限度地减少中断和最大限度地提高生产环境中的资源效率来降低成本。

促进改进反馈

• **部署后监控** - 部署还为在真实环境中观察应用程序性能和收集用户反馈奠定了基础。此反馈循环对于持续改进和规划未来的开发周期至关重要。

• **问题识别** - 在测试环境中可能不明显的问题可能会在部署过程中出现，从而为改进软件和SDLC流程本身提供见解。

软件部署模型类型

• **本地部署** - 软件部署在组织基础设施内的传统模型。

• **云部署** - 使用 AWS、Azure、Google Cloud 等云提供商。

• **混合部署** - 本地和云解决方案的组合。

• **持续部署 (CD)** - 介绍 CI/CD 管道和自动化部署。

• **容器化部署** - 使用 Docker、Kubernetes 和其他容器化工具。

部署策略和方法

• **蓝绿部署** - 运行两个相同的环境以减少停机时间。

• **金丝雀发布** - 逐步向一部分用户推出更新。

• **滚动部署** - 逐步部署到系统的一部分以降低风险。

• **A/B 测试** - 部署不同的版本以衡量性能和用户响应。

• **特性开关** - 启用某些用户的特性而无需完全部署。

部署过程的关键组件

• **构建自动化** - 用于自动化构建的工具和实践（例如，Jenkins、GitLab CI）。

• **配置管理** - 管理软件环境（例如，Ansible、Chef）。

• **部署中的测试** - 测试类型（例如，冒烟测试、回归测试）。

• **发布管理** - 跟踪版本、文档和发行说明。

• **监控和日志记录** - 用于跟踪应用程序运行状况的工具和策略（例如，Prometheus、Grafana、ELK 堆栈（包括 Elasticsearch、Logstash、Kibana 和 Datadog））。

软件部署中的工具和技术

• **CI/CD 工具** - Jenkins、CircleCI、GitLab CI/CD 等。

• **配置管理工具** - Ansible、Puppet、Chef。

• **容器化工具** - Docker、Kubernetes、Helm。

• **云平台** - AWS、Azure、Google Cloud 用于部署自动化。

• **监控工具** - Grafana、Prometheus、ELK 堆栈用于可观察性。

• **版本控制系统** - Git、SVN 用于管理部署代码版本。

软件部署中的挑战

• **环境一致性** - 开发、测试和生产环境之间的差异。

• **回滚和故障** - 处理部署故障并确保系统稳定性。

• **安全问题** - 保护部署管道并管理敏感数据。

• **依赖项管理** - 处理版本冲突和库依赖项。

• **扩展和负载管理** - 将更新部署到可扩展系统中的挑战。

有效部署的最佳实践

• **自动化** - 自动化重复性部署任务的重要性。

• **测试** - 部署前的持续集成和测试。

• **文档** - 保持清晰、最新的部署文档。

• **监控** - 建立强大的监控和警报系统。

• **回滚计划** - 制定必要的快速回滚策略。

软件部署的未来

• **边缘计算和部署** - 将软件部署到靠近数据源的位置以减少延迟。

• **无服务器部署** - 使用 FaaS（函数即服务）和无服务器平台。

• **部署中的人工智能** - 用于部署优化的预测分析。

• **CI/CD 的发展** - 持续一切 (CI/CD/CT) 及其在部署中的作用。

结论

本质上，部署是软件实现其预期目的、向最终用户交付其好处并使企业能够从投资中获益的地方。流畅、可靠的部署过程对于将开发工作与用户期望保持一致、维持运营连续性以及支持软件产品的持续发展至关重要。

使用 Docker 的示例部署工作流

设置项目

为应用程序中的每个服务（例如，Web 应用程序、数据库）定义 Dockerfile。

如果要一起管理多个服务，请编写 Docker Compose 文件（例如，“docker-compose.yml”）。

Spring Boot 应用程序的示例 Dockerfile

# Start with an official Java runtime as the base image
FROM openjdk:17-jdk-alpine

# Set the working directory
WORKDIR /app

# Copy the application jar file into the image
COPY target/myapp.jar myapp.jar

# Expose the port the app will run on
EXPOSE 8080

# Run the application
ENTRYPOINT ["java", "-jar", "myapp.jar"]

构建 Docker 镜像

docker build -t myapp:latest .

正确标记镜像以管理注册表中的不同版本（例如，“myapp:v1.0”）。

在容器中运行本地测试

使用 Docker Compose 或单个 Docker 容器在隔离的环境中运行测试。

docker-compose up -d
docker-compose exec webapp ./run-tests.sh

确保所有服务都在运行并通过测试。

将镜像推送到 Docker 注册表

将 Docker 镜像推送到容器注册表（例如，Docker Hub、Amazon ECR 或私有注册表）以使其可供部署环境访问。

登录并推送镜像：

docker login -u username -p password
docker tag myapp:latest username/myapp:v1.0
docker push username/myapp:v1.0

部署到暂存环境

从注册表**拉取镜像**到暂存服务器：

docker pull username/myapp:v1.0

根据暂存环境设置使用 Docker Compose 或 Kubernetes 进行部署。

在暂存环境中运行任何其他集成或验收测试。

监控日志和指标

使用Docker命令检查日志和应用程序健康状况。

docker logs -f container_name

如果使用监控工具（例如，Grafana，Prometheus），请确认应用程序指标在可接受的阈值范围内。

批准并部署到生产环境

一旦测试在预发布环境中通过，就从注册中心拉取镜像并将其部署到生产环境。

运行Docker Compose或Kubernetes命令以启动生产环境中的服务。

docker pull username/myapp:v1.0
docker run -d -p 8080:8080 username/myapp:v1.0

实施回滚机制

确保已存储先前版本的镜像。如果出现问题，请重新部署最后一个稳定版本。

docker pull username/myapp:v0.9
docker run -d -p 8080:8080 username/myapp:v0.9

使用CI/CD管道自动化工作流程

设置一个CI/CD管道（例如，GitHub Actions，GitLab CI，Jenkins），该管道自动化此工作流程，包括构建、测试、推送和部署阶段。

CI/CD管道脚本示例（GitHub Actions）：

name: Docker CI/CD

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      
      - name: Build Docker image
        run: docker build -t username/myapp:${{ github.sha }} .
      
      - name: Log in to Docker Hub
        run: echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin

总结

此工作流程自动化了Docker化应用程序的构建、测试和部署阶段，提供了本地和远程测试、回滚策略以及自动化的CI/CD管道以简化流程。

功能性需求与非功能性需求

软件开发中需求的介绍

功能性需求

定义系统应该做什么。它们定义系统必须具备的特定行为、特性和功能，以满足用户的需求。这些需求通常表示为系统应执行的动作或任务。

示例

• 用户身份验证 - 系统必须允许用户使用用户名和密码登录。

• 数据处理 - 系统必须实时处理和验证用户输入。

• 报表 - 系统必须每月生成销售报表。

非功能性需求

定义系统应该如何执行。它们定义系统必须遵守的质量属性、性能标准和约束。这些需求侧重于可用性、可靠性、安全性、可扩展性等方面。

示例

• 性能 - 系统必须能够处理多达1000个并发用户，响应时间少于2秒。

• 安全 - 系统必须确保所有敏感信息的加密。

• 可用性 - 系统必须易于使用，并且残疾用户也可以访问。

功能性需求的类型

• 用户界面需求 - 与UI组件、布局和设计相关的需求（例如，搜索栏）。

• 业务需求 - 描述业务规则和策略（例如，系统应根据位置应用税率）。

• 数据管理需求 - 定义系统如何处理数据输入、存储和处理。

• 管理需求 - 系统管理的功能，例如用户角色管理或访问控制。

用例示例

描述一个示例功能需求以及它如何帮助实现业务目标。

非功能性需求的类型

性能需求

• 响应时间 - 系统对给定输入或请求做出反应所需的时间。

• 吞吐量 - 指系统在给定时间段内可以处理数据或完成任务的速率。

• 延迟 - 指用户操作与其对应的系统响应之间的时间延迟。

示例

响应时间 - 对于93%的用户，页面加载时间应小于2秒。

可扩展性需求

系统处理数据量、用户或事务增长能力。

示例 - 系统应支持多达10,000个并发用户。

安全需求

数据保护、加密和访问控制的需求。

示例 - 密码必须在存储之前进行哈希和加盐处理。

可用性需求

与系统易用性和可学习性相关的需求。

示例 - 所有核心功能都应在不超过三次点击的情况下即可访问。

可靠性和可用性需求

定义系统的预期正常运行时间和容错能力。

示例 - 系统应具有99.9%的正常运行时间。

可维护性和可移植性

易于维护、调试和迁移的需求。

示例 - 代码应遵循已记录的标准以确保可维护性。

法律和合规性需求

系统必须遵守的法规和标准（例如，GDPR——通用数据保护条例）。

示例 - 用户必须同意根据GDPR使用数据。

收集需求的技术

与利益相关者和用户访谈，以了解预期。

调查问卷，用于收集来自大量受众的反馈。

研讨会和头脑风暴会议，用于协作式需求收集。

观察和跟班学习，以了解现实世界中的用户交互。

文档分析，现有系统和策略。

原型设计和样机，用于可视化需求并收集反馈。

记录功能性和非功能性需求

需求文档

• 软件需求规格说明书（SRS）文档 - 用于详细捕获功能性和非功能性需求。

• 敏捷用户故事和验收标准 - 定义每个需求的“完成”状态。

使用图表

• 用例图 - 可视化功能性需求。

• 流程图和序列图 - 用于流程流和系统交互。

非功能性文档

• 质量属性场景 - 在场景中描述非功能性需求（例如，“在服务器发生故障的情况下，系统应在3分钟内恢复”）。

• 最佳实践 - 确保需求清晰、可测试且具有优先级。

管理功能性和非功能性需求的挑战

• 歧义和误解 - 模糊的需求会导致误解。使用清晰、具体的语言。需求变更：需求可能会频繁变更；使用敏捷方法来提高灵活性。

• 功能性和非功能性目标之间的冲突 - 可能需要权衡（例如，安全性和可用性）。

• 优先级问题 - 可能会忽略高优先级的非功能性需求（如安全性）。

• 利益相关者一致性 - 确保所有利益相关者都同意优先级和定义。

管理和验证需求的最佳实践

• 让利益相关者参与 - 定期征求利益相关者的反馈，以确保需求与期望相符。

• 优先级排序需求 - 根据对业务的重要性对功能性和非功能性需求进行排序。

非功能性需求的测试

负载测试，用于性能需求。

可用性测试，用于用户体验。

安全审计，用于安全性和合规性需求。

迭代审查和改进，定期检查需求的完整性和相关性。

使用自动化，使用JIRA、Confluence和Trello等工具实时跟踪需求，以确保可追溯性。

总结

对功能性和非功能性需求采取平衡的方法对于构建强大、以用户为中心的软件系统至关重要。本文重点介绍了这些需求的定义、类型以及收集、记录和验证这些需求的方法，确保软件项目既符合用户期望，又符合技术标准。

什么是数据流图？

数据流图介绍

DFD的定义

DFD可以解释为系统中数据流动的图形表示。

目的和重要性

• 用于可视化数据在系统中的移动和交互。

• 帮助开发人员、业务分析师和利益相关者在无需了解技术复杂性的情况下理解流程。

主要优势

• 简化复杂流程。

• 提高技术和非技术利益相关者之间沟通的清晰度。

DFD组件和符号

• 流程 - 用圆圈或圆角矩形表示。描述每个流程如何将输入转换为输出。

• 数据存储 - 用开放式矩形表示，象征着数据在系统中存储的位置。

• 数据流 - 箭头表示组件之间的数据移动，并标注正在传输的数据类型。

• 外部实体（源/宿） - 用正方形表示，表示与系统交互的外部系统或用户。

带简单用例的DFD示例

数据流图的类型和级别

• 上下文图（0级） - 高级DFD，将整个系统显示为单个流程以及外部实体。

• 1级DFD - 将主流程分解为子流程，包括数据流和存储。

• 2级及以上 - 进一步分解以获得更详细的视图，通常用于大型或复杂的系统。

创建数据流图 - 分步指南

• 步骤1 - 识别外部实体（谁/什么与系统交互）。

• 步骤2 - 定义主流程（主要系统功能）。

• 步骤3 - 绘制实体和流程之间的数据流。

• 步骤4 - 识别存储信息以进行处理的数据存储。

• 步骤5 - 根据需要将高级图表分解为较低级别，以细化并添加细节。

• 提示 - 使用一致的标签，尽可能避免交叉线，并确保所有组件都具有清晰的标签。

不同系统的DFD示例

• 示例1 - 在线零售系统：上下文图说明基本数据流（用户、支付网关、库存）。1级DFD，包含“下订单”、“处理付款”、“管理库存”等流程。

• 示例2 - 图书馆管理系统：上下文图显示图书馆工作人员、会员和数据库作为实体。1级DFD，包含“借书”、“还书”、“更新会员信息”等流程。

• 示例3 - 银行系统：上下文图说明客户、银行和ATM作为实体。1级DFD，包含“存款”、“取款”、“查询余额”等流程。

数据流图在不同行业的应用

• 医疗保健 - 可视化患者数据在不同部门（例如，入院、诊断、计费）中的流动。

• 电子商务 - 说明客户从浏览到结账和履行的旅程。

• 银行和金融 - 显示ATM、分支机构和在线平台之间用于交易和账户管理的数据流。

• 教育 - 描绘学生的生命周期，从注册到毕业，包括课程管理和记录保存。

• 案例研究示例 - 医院患者数据管理的示例用例图。

创建和使用数据流图的最佳实践

• 保持简单 - 避免过度复杂化；使用分层DFD级别以提高清晰度。

• 使用一致的符号和标签 - 标准化符号以提高可读性和清晰度。

• 避免线条重叠 - 通过清晰地排列组件来最大限度地减少视觉混乱。

• 与利益相关者进行验证 - 与用户和利益相关者确认以确保准确性。

• 迭代和改进 - 随着系统的发展而修改，尤其是在复杂的项目中。

• 示例提示 - 显示杂乱的DFD与组织良好的DFD，以突出最佳实践。

常见错误以及如何避免

• 未定义或含糊不清的标签 - 为所有数据流和流程使用清晰、描述性的标签。

• 高级DFD中细节过多 - 将更精细的细节保留在较低级别，以避免混乱。

• 缺少数据存储或数据流 - 确保包含所有所需的数据存储和移动。

• 外部实体放置不正确 - 将外部实体保留在系统的周边。

• 流程未连接 - 确保每个流程都有输入和输出数据流。

数据流图的高级概念和未来

扩展的DFD

使用DFD来说明基于事件或实时的数流。

DFD创建的自动化工具

Microsoft Visio、Lucidchart和在线DFD生成器。

自动化工具的好处

更快的更新、轻松共享和标准化。

将DFD与其他图表集成

将DFD与实体关系图(ERD)或用例图结合使用，以获得全面的视图。

DFD在敏捷环境中的未来

能够快速迭代、与用户故事集成并在复杂的系统设计中保持持续的相关性。

总结

本指南深入讲解了数据流图 (DFD) 的用途、结构以及创建和使用方面的最佳实践。DFD 在系统分析和设计中仍然具有价值，它提供了一种直接了解数据流和系统架构的方法。

数据流图 - 类型和组成部分

数据流图 (DFD) 的用途

数据流图 (DFD) 是一种图形表示，它说明了数据如何在系统内流动，突出了相互交互的流程、数据存储和外部实体。DFD 对于理解、设计和记录数据在系统中移动的方式至关重要。通过显示信息来自哪里、去向哪里以及沿途如何转换，DFD 帮助分析师、设计师和利益相关者清楚地了解系统的功能和结构，而无需深入了解复杂的技术细节。

关键概念和优势

关键概念

关键元素 - 数据流、流程、数据存储和外部实体。

使用 DFD 的优势

• 可视化的清晰性和简洁性。

• 有助于需求分析、设计阶段和故障排除。

数据流图的类型

数据流图 (DFD) 是分层图，用于可视化系统内信息流。它们分为不同的层次，每个层次都提供越来越多的细节。

0 级 DFD - 上下文图

0 级 DFD 也称为上下文图，代表系统的最高级别视图。

用途 - 它提供了系统的广泛概述，显示了与其交互的主要实体（或外部系统）以及主要的信息流。

组成部分

• 单个流程 - 通常表示为带有标签的单个圆圈或矩形，指示系统的整体用途（例如，“订单处理系统”）。

• 外部实体 - 表示与系统交互的实体的正方形，例如“客户”和“仓库”。

• 数据流 - 显示外部实体和系统之间主要数据流的箭头。

1 级 DFD - 主系统的分解

1 级 DFD 扩展了 0 级 DFD，将主系统流程分解为子流程。它显示了系统处理数据的更多细节。

用途 - 将主要流程分解为更小的子流程，显示系统内部的运作方式。

组成部分

多个流程 - 系统中的每个主要活动，例如“处理订单”、“管理库存”、“处理付款”和“履行订单”，都显示为一个单独的流程。

数据存储 - 由开放式矩形表示，数据存储（如“订单数据存储”或“库存数据存储”）显示数据在系统中存储的位置。

数据流 - 更具体的数据流指示在流程之间以及与数据存储和实体之间传递的数据。

示例 - 在订单处理系统中，1 级 DFD 将显示诸如“处理订单”、“检查库存”、“处理付款”和“发货订单”之类的流程，这些流程通过数据流连接。每个流程都将与数据存储和外部实体交互，显示比 0 级图更具体的交互。

2 级 DFD - 详细的流程分解

2 级 DFD 对 1 级 DFD 中的某个流程进行了更深入的探讨。它代表了更精细的细节级别。

用途 - 显示单个流程中的详细步骤，指示为完成系统功能的一部分而采取的精确操作。

组成部分

子流程 - 每个子流程都是 1 级流程中某个流程中更细化的步骤。例如，“检查库存”可能包括诸如“更新库存”和“检查库存可用性”之类的步骤。

其他数据存储 - 如有必要，可以包含特定于这些更精细步骤的其他数据存储。

数据流 - 详细的数据流显示选定的 1 级流程中信息的精确移动。

示例 - 对于订单处理系统中的“处理订单”流程，2 级 DFD 可能将其分解为诸如“验证订单”、“检查库存”、“授权付款”和“确认订单”之类的步骤。数据流将指定在每个步骤中检查、存储或修改的数据，从而清晰地显示工作流程。

每个 DFD 层次都提供了系统越来越详细的视图，从而更容易系统地理解和分析复杂的工作流程。

数据流图的组成部分

流程

• 将流程定义为系统内数据的转换。

• 用符号和示例进行说明，例如电子商务 DFD 中的“订单处理”。

数据存储

• 将数据存储定义为系统内保存数据的地方。

• 讨论命名约定和示例，例如“客户数据”或“库存”。使名称易于理解。

数据流

• 将数据流定义为数据在流程、数据存储和外部实体之间采取的路径。

• 用带标签的箭头进行说明，并强调数据流命名的清晰性。

外部实体

• 将外部实体定义为系统控制范围之外的数据源或目标。

DFD 流程编号

在数据流图 (DFD) 中，流程编号是一种结构化的方法，用于显示不同流程层次之间的层次关系。这种编号方法有助于使 DFD 更易于阅读和组织，允许查看者追踪流程的起源和系统内的连接。以下是跨 DFD 层次对流程进行编号的说明：

0 级 DFD（上下文图）

单个流程编号 - 由于 0 级提供了系统的较高层次概述，因此它表示为单个流程，没有任何子流程。此流程通常编号为“0”（例如，“订单处理系统 (0)”）。

用途 - “0”标签表示这是主系统，包含所有进一步的流程。

1 级 DFD

分解主流程 - 在 1 级中，主流程（流程 0）被分解为代表系统核心功能的子流程。

编号约定 - 1 级中的每个子流程都根据其在流程流中的位置编号为1、2、3 等。

例如，在订单处理系统中：

流程 1 - “处理订单”

流程 2 - “管理库存”

流程 3 - “处理付款”

流程 4 - “履行订单”

用途 - 此编号表示每个流程都是主系统内的主要功能。

2 级 DFD（及更高级别）

分解每个 1 级流程 - 在 2 级中，每个 1 级流程都进一步分解为更小的步骤或子流程。

编号约定 - 2 级子流程使用十进制表示法来指示它们是 1 级流程的一部分。

例如，分解“处理订单（流程 1）”：

流程 1.1 - “验证订单”

流程 1.2 - “检查库存”

流程 1.3 - “授权付款”

流程 1.4 - “确认订单”

如果另一个 1 级流程（例如“管理库存（流程 2）”）被分解：

流程 2.1 - “检查库存可用性”

流程 2.2 - “更新库存”

更高级别 - 如有需要，可以在 3 级 DFD 中进一步分解 2 级子流程，它将使用 1.1.1、1.1.2 等编号。

DFD 流程编号的优势

• 清晰度 - 编号帮助用户快速识别和追踪不同级别中的流程和子流程。

• 组织性 - 它显示了流程的层次结构，指示高层流程如何分解为更精细的任务。

• 轻松参考 - 每个流程都有一个唯一的标识符，可以轻松讨论和分析系统内的特定步骤。

开发系统的 DFD 模型

引言

本文提供了一份关于数据流图 (DFD) 的全面指南，重点介绍了开发过程、类型、优势和涉及的挑战。它涵盖了有助于创建高效 DFD 的实用技术、工具和最佳实践。本指南专为系统分析师、项目经理和学生而设计。

数据流图 (DFD) 是系统分析和设计中的一种流行方法，有助于可视化数据如何在系统内流动、其处理点和存储位置。通过定义和表示数据从源到目的地的流动，DFD 有助于理解复杂系统的功能。

DFD 的重要性

• 将复杂系统简化为可管理的部分。

• 提高对系统需求的理解。

• 有助于识别潜在的系统低效率或瓶颈。

使用数据流图的优势

DFD 为技术和非技术利益相关者都提供了许多好处：

• 增强沟通 - 为团队提供通用的可视化语言。

• 明确系统需求 - 识别输入、流程和输出。

• 高效的系统分析 - 促进识别冗余或瓶颈。

• 改进设计质量 - 为优化的数据库和系统设计奠定基础。

数据流图的开发过程

步骤 1：定义系统边界和范围

• 识别与系统交互的所有外部实体。

• 定义 DFD 范围之内和范围之外的内容。

步骤 2：识别核心流程

• 查明处理数据的流程。

• 考虑分解复杂的流程以提高清晰度。

步骤 3：识别数据存储

• 确定数据将在系统中存储的位置。

• 根据数据的管理方式对这些存储进行分类。

步骤 4：识别数据流

• 建立实体、流程和存储之间的数据流。

• 验证是否表示所有必要的输入和输出。

步骤 5：构建上下文图 (0 级 DFD)

• 创建最高级别的 DFD，显示单个流程和外部实体。

• 通过数据流连接实体和主流程。

步骤 6：开发详细级别 (1 级、2 级)

• 将上下文图中的主流程分解为子流程。

• 每个级别都添加细节，确保数据流和连接的准确性。

步骤 7：验证和审查

• 与利益相关者一起验证 DFD 以确保完整性。

• 根据反馈调整图表以解决任何差距。

创建数据流图的工具

• Lucidchart - 提供一系列 DFD 符号和协作功能。

• Microsoft Visio - 常用于组织中创建 DFD。

• Draw.io - 用于创建 DFD 和其他类型图表免费工具。

• SmartDraw - 提供模板和易于使用的 DFD 工具。

• Visual Paradigm - 支持所有级别的 DFD 和高级功能。

每个工具都提供支持特定需求的独特功能，例如协作、模板可用性和导出选项。

示例：电子商务订单处理系统 DFD

上下文图

电子商务系统包括客户和支付网关等外部实体，这些实体在一个名为“订单处理”的高级流程中表示。

0 级 DFD

订单管理 - 接收和处理订单。

库存系统 - 管理产品可用性。

支付处理 - 处理来自支付网关的付款。

客户数据库 - 存储客户信息和订单历史记录。

开发 DFD 的挑战

• 含糊不清的需求 - 不完整或不清楚的需求会导致 DFD 不准确。

• 复杂的系统 - 大型系统可能变得过于复杂，导致难以解释的 DFD。

• 需求变更 - DFD 需要随着需求变化而更新。

• 利益相关者意见不一致 - 对 DFD 的准确性或细节水平缺乏共识可能会延迟批准。

DFD 开发的最佳实践

• 保持简单 - 避免在较高 DFD 层次中出现不必要的复杂性。

• 让利益相关者参与进来 - 早期与所有相关方进行协作。

• 使用一致的命名 - 清晰地标记实体、流程和数据存储。

• 定期审查和改进− 通过迭代审查确保DFD的准确性。

• 限制图表层级− 限制细节深度以避免过度复杂。

结论

数据流图 (DFD) 是系统分析、设计和沟通的宝贵工具。它们能够更好地理解系统功能和数据移动，为技术和非技术利益相关者提供清晰的认识。通过适当的开发和最佳实践，DFD 有助于有效的设计、分析和持续的系统改进。

数据流图 - 平衡

数据流图和平衡介绍

什么是数据流图 (DFD)？

数据流图 (DFD) 以可视化的方式表示系统内的数据流，显示过程、数据存储、外部实体和数据流。DFD 是分层结构的−

• 上下文图− 将系统作为单个过程的高级概述。

• 0级DFD− 将单个过程分解成主要功能。

• 1级及以上− 将过程进一步分解成子过程。

什么是DFD中的平衡？

平衡是指在DFD的不同级别之间保持数据流的一致性。在将过程分解到较低级别时，进入或退出较高级别过程的所有数据流都应与该过程的较低级别DFD中的数据流匹配。

平衡是DFD中的一个基本概念，它确保图表不同级别的数据保持一致性和清晰性。

数据流图中平衡的重要性

平衡在DFD中起着至关重要的作用，因为它−

• 确保数据一致性− 防止不同级别之间的数据不匹配。

• 提高准确性− 维持系统分析中信息的完整性。

• 增强清晰度− 帮助利益相关者理解系统功能，避免混淆。

• 支持有效的系统设计− 协助开发人员和分析师保持设计的可靠性和易于解释性。

平衡不良的后果

• 数据不一致

• 对系统需求的误解

• 系统设计和实现中的错误增多

DFD平衡的原则

从一个DFD级别移动到另一个级别时，平衡需要遵循以下原则−

• 数据流的一致性− 较高级别上的每个输入或输出都必须在较低级别上反映。

• 数据流对齐− 数据流的名称和用途应在各个级别保持一致。

• 过程关联− 确保分解后的DFD中的过程与父过程在逻辑上对齐。

数据流图平衡的技术

技术1：使用级别平衡

分解过程时−

• 保持父DFD和子DFD之间的外部数据流相同。

• 例如，如果0级中的“销售处理”过程具有“客户订单”和“订单确认”的数据流，则1级必须直接或通过子过程反映这些流。

技术2：匹配数据存储

数据存储在各个级别必须一致。如果数据存储出现在较高级别的DFD中，则在与分解过程相关的较低级别中也应出现。

技术3：一致的数据流命名

在DFD的所有级别使用一致的命名约定，以减少歧义并提高清晰度。

示例：DFD中的平衡

考虑一个在线图书馆管理系统。

0 级 DFD

图书馆系统包括−

过程− 借书、还书、更新目录。

数据流− 借书请求、还书确认、目录更新

1级DFD（分解“借书”）

子过程− 验证会员资格、检查图书可用性、发放图书。

数据流− 借书请求、会员验证、图书发放确认。

为了平衡，0级中与“借书”相关的所有数据流都必须出现在1级图中。这包括−

1. 借书请求（从用户到系统）

2. 图书发放确认（从系统到用户）

解释

此处的平衡确保在0级进入或离开“借书”的任何数据流都保留在1级。这种一致性避免了数据在分解过程中“丢失”。

DFD平衡的工具

1. Lucidchart− 提供模板和工具来可视化分层DFD，具有支持多级平衡的功能。

2. Microsoft Visio− 一个创建结构化DFD的强大工具，具有内置的对齐和平衡流的支持。

3. SmartDraw− 提供易于使用的DFD模板，有助于创建平衡的图表。

4. Visual Paradigm− 提供自动检查平衡DFD的功能，帮助分析师避免不一致。

5. Draw.io− 一个免费工具，支持多个DFD级别，使初学者更容易实现平衡。

数据流图平衡中的挑战

1. 数据流不一致− 当数据流在DFD级别之间命名或描述不一致时，就会出现一个常见问题，导致错位。

2. 复杂的过程− 对于复杂的系统，在保持数据流一致性的同时分解过程可能很困难且耗时。

3. 范围蔓延− 随着系统的发展，新的需求可能会改变数据流，导致不平衡的图表需要重新评估。

4. 利益相关者误解− 对于不熟悉技术图表的利益相关者来说，平衡可能难以解释，导致对数据流一致性要求的混淆。

有效DFD平衡的最佳实践

1. 维护单一事实来源− 使用主数据流列表，并在DFD演变时更新它。

2. 迭代验证− 经常审查每个级别以确保数据流一致。

3. 标准化命名约定− 为每个数据流使用清晰、描述性的名称，使平衡更简单。

4. 限制级别− 避免过度分解，以防止DFD复杂性难以管理。

5. 利益相关者参与− 早期让利益相关者参与进来，以协调期望并确保系统流的准确表示。

结论

平衡是数据流图制图的关键组成部分，它确保了各个级别的数据流完整性和一致性。掌握平衡技术允许系统分析师和开发人员生成可靠且易于理解的DFD，这些DFD准确地反映了系统功能。遵守最佳实践并利用合适的工具可以简化平衡过程，帮助维护系统模型的清晰度和可靠性。

数据流图 - 分解

引言

数据流图 (DFD) 是系统分析和设计中必不可少的工具，使利益相关者能够可视化系统内信息流。在DFD的许多原则中，分解作为将复杂系统分解成可管理组件的关键概念脱颖而出。本文探讨了DFD中的分解，包括其重要性、技术和实际应用。

理解DFD中的分解

分解是将大型复杂系统分解成更小、更易于管理的组件的过程。在DFD中，这涉及到将高级过程逐步详细地分解成子过程，每个子过程都有其数据流和交互。

为什么要分解？

• 简化复杂系统的分析。

• 增强利益相关者的清晰度。

• 允许对系统特定部分进行详细的文档记录。

• 识别流程中的低效率、冗余或瓶颈。

DFD分解的级别

DFD中的分解遵循分层方法，从系统的最抽象表示开始，逐步深入到更精细的细节。

上下文图

上下文图表示最高的抽象级别。它将整个系统描绘成一个单一过程，并关注−

• 外部实体

• 系统与其环境之间主要的数据流

示例− 图书馆管理系统的上下文图可能会显示诸如借书和还书之类的过程，而无需详细说明这些任务是如何在内部管理的。

1级DFD

1级DFD将上下文图中的单个过程分解成主要子过程。它显示−

• 过程之间的内部数据流

• 与这些过程交互的数据存储

示例− 借书可能会分解成−

1. 检查用户凭据

2. 检索图书详细信息

3. 更新数据库

N级DFD

更高级别的DFD（2级、3级等）将过程进一步分解成更细粒度的任务。这种迭代细节化持续进行，直到每个过程都足够简单，可以直接实现。

分解DFD的步骤

分解需要系统步骤来确保准确性和一致性−

步骤1− 识别关键流程

从需要详细说明的高级过程（来自上下文图）开始。选择涉及多个任务或重要交互的过程。

步骤2− 定义子过程

对于每个高级过程，识别执行特定任务的子过程。确保子过程与系统目标一致。

步骤3− 映射数据流

详细说明数据如何在子过程、数据存储和外部实体之间移动。使用清晰一致的标签。

步骤4− 与利益相关者进行验证

与利益相关者一起审查分解后的图表，以确保完整性和准确性。这可以防止误解并收集反馈。

步骤5− 根据需要进行迭代

根据复杂性或利益相关者的需求进一步改进子过程。

DFD分解中的最佳实践

为了实现有效的分解，请考虑以下最佳实践−

坚持一致性

在各个级别保持一致的符号、标签和命名约定。

避免过度分解

过多的级别会使理解复杂化。当过程足够简单以供实现时停止。

关注功能

根据功能分解过程，而不是任意划分。

使用模块化设计

确保子过程尽可能独立运行。

记录每个级别

为每个DFD级别提供文档，解释其元素和关系。

常见挑战和解决方案

挑战1− 数据流重叠

解决方案− 清晰地定义过程的边界并确保正确的标签。

挑战2− 缺乏利益相关者的投入

解决方案− 让利益相关者参与审查和验证阶段。

挑战3− 范围蔓延

解决方案− 将分解限制在项目范围内。在一开始就定义清晰的边界。

挑战4− 过程的错误表示

解决方案− 与领域专家合作以准确地描绘过程。

分解在现实世界场景中的应用

分解广泛用于各个领域来设计和优化系统。一些例子包括−

软件开发

分解有助于将系统功能分解成模块，指导开发人员构建可扩展和可维护的软件。

业务流程再造

通过可视化工作流程，组织可以识别流程中的瓶颈、冗余或低效之处。

医疗系统

分解后的DFD有助于映射患者数据流，确保医疗记录的安全高效管理。

电子商务平台

电子商务系统使用分解来定义关键流程，例如订单管理、库存跟踪和支付处理。

结论

分解是数据流图不可或缺的方面，它使系统分析师和设计人员能够解开复杂性并创建高效的系统。通过系统地分解高级流程，分解可以促进清晰度，增强协作，并确保更好的系统设计。随着组织越来越依赖结构化的方法进行系统开发，掌握DFD分解对于分析师和利益相关者来说仍然是一项重要的技能。

系统设计 - 数据库

系统设计和数据库简介

系统设计是构建可扩展、高效和强大的软件解决方案的关键方面。系统设计的核心在于数据库，这是一个结构化的存储库，用于存储、组织和检索系统操作必不可少的数据。

数据库在系统设计中的作用不容忽视。它们确保数据一致性，支持并发操作，并构成业务逻辑的基础。本节将探讨基础概念，包括数据库在系统设计中的重要性及其用途概述。

数据库类型

数据库有多种形式，每种形式都适用于特定的用例。了解它们的类型对于为给定系统选择合适的数据库至关重要。

1. 关系数据库 (RDBMS)− 通过使用外键以关系格式存储数据。示例包括 MySQL、PostgreSQL 和 Oracle。这些数据库使用结构化查询语言 (SQL) 来管理预定义模式中的数据。

2. NoSQL 数据库− 非关系型数据库。包括文档存储（如 MongoDB）、键值存储（如 Redis）和列式数据库（如 Cassandra）。这些数据库针对灵活性和水平扩展进行了优化。

3. NewSQL 数据库− RDBMS 和 NoSQL 数据库的混合体，在保持 ACID（原子性、一致性、隔离性、持久性）一致性的同时提供可扩展性。示例：CockroachDB、VoltDB、Google Spanner。

4. 内存数据库− 将数据存储在 RAM 或磁盘中，例如 H2、Redis 和 Memcached，它们通过将数据存储在 RAM 中来优先考虑速度。

5. 图数据库− 它们使用具有节点、边和属性的图结构来表示和存储数据。示例包括 Neo4j 和 ArangoDB，适用于关系密集型数据，例如社交网络。

数据库系统设计的主要组成部分

数据库系统设计不仅仅是选择一种数据库类型。它包含几个组成部分：

• 模式设计− 数据结构的蓝图。

• 索引− 增强查询性能。

• 分片− 对数据库进行分区以实现可扩展性。

• 复制− 确保高可用性和容错性。

• 一致性模型−

  • 强一致性− 节点之间立即实现数据一致性。

  • 最终一致性− 在分布式系统中为了性能而优先考虑。

数据库规范化和模式设计

模式设计是系统效率的核心，它涉及将数据组织成表并定义关系。本节将探讨：

规范化− 通过将表分成更小的单元来消除数据冗余并提高一致性的过程。

反规范化− 规范化的反面，用于需要更快读取操作的系统。

最佳实践：

1. 了解数据访问模式。

2. 选择规范化和反规范化之间的正确平衡。

3. 使用 ER 图等工具设计模式。

现实场景和逐步的模式示例将说明这些概念。

数据库可扩展性和性能优化

现代系统需要高度可扩展和高性能的数据库。关键策略包括：

1. 垂直扩展− 为单个服务器添加更多资源。

2. 水平扩展− 将负载分布到多个服务器。

3. 缓存− 使用 Redis 或 Memcached 等工具来存储经常访问的数据。

4. 查询优化− 编写高效的查询并使用索引。

5. 负载均衡− 均匀地分配数据库查询。

系统设计中的 NoSQL 与 SQL

在系统设计中选择 NoSQL 和 SQL 至关重要。本节比较这两种范例：

SQL 数据库

优点− 数据完整性、ACID 一致性、强大的查询功能。

缺点− 对非结构化数据的灵活性有限。

NoSQL 数据库

优点− 可扩展性、无模式设计、针对大数据进行了优化。

缺点− 一致性保证较弱（例如，最终一致性）。

数据库系统设计中的挑战

设计数据库系统充满了挑战：

1. 处理高并发流量− 每秒管理数百万个查询。

2. 一致性与可用性− 高可用性是指设计为长时间连续运行而不会出现故障的系统。CAP 定理突出了权衡。该定理指出，分布式数据存储不可能同时提供以下三种保证：一致性、可用性和分区容错性。

3. 数据安全− 确保符合 GDPR（通用数据保护条例）等标准。

4. 备份和恢复− 实施故障转移策略。

数据库系统设计的未来趋势

数据库的未来正在受到技术进步的影响，例如：

1. AI 驱动的数据库− 利用机器学习进行查询优化。

2. 区块链数据库− 用于数据完整性的去中心化系统。

3. 边缘数据库− 针对物联网和边缘计算进行了优化。

结论

数据库是系统设计的基石。从模式规划到可扩展性，精心设计的数据库可确保系统能够随着需求的变化而发展和适应。通过理解本文中讨论的原则，开发人员和架构师可以构建既强大又可扩展的系统。

LLD 中身份验证和授权的区别

什么是身份验证？

身份验证是确认用户在计算机系统上声明身份的行为。与身份识别相反，身份验证是验证个人或事物身份的过程。必须验证个人身份，必须使用数字证书验证网站的有效性，必须对文物进行碳年代测定，并且产品或文件不得是伪造的。

确定声称的用户身份的过程称为身份验证。这是安全程序的第一阶段。在小于或等于以下时间完成身份验证过程：

• 密码− 最流行的身份验证因素是用户名和密码。当用户提供正确的信息时，系统将验证 ID 并授权访问。

• 一次性 PIN 码− 仅允许访问一个会话或事务。

• 身份验证应用程序− 生成安全代码，允许通过第三方访问。

• 生物识别识别− 要访问系统，用户必须提供指纹和眼部扫描。

在提供访问权限之前，系统可能需要正确验证多个因素。这种多因素身份验证 (MFA) 要求通常允许提供超出密码本身所能提供的额外保护。

什么是授权？

授权是为资源分配权限/特权的能力，它与一般的信息安全和特定的计算机安全、访问控制有关。“授权”在更正式的意义上是指创建访问策略的过程。在系统安全中，授权是指授予对指定资源或功能的访问权限的过程。该术语通常与访问控制和客户端权限互换使用。

权限可以允许某人从服务器下载特定文件，或向特定用户提供程序的管理员访问权限。

在安全环境中，始终需要认证才能获得授权。在组织管理员授予对请求资源的访问权限之前，用户必须首先确认其身份。

身份验证与授权

身份验证和授权是登录过程中的两个独立阶段。要正确实现 IAM 解决方案，必须了解两者之间的区别。

假设一个人在家人度假期间靠近一扇关着的门来照顾宠物。个人需要以下物品：

• 获得了钥匙类型的身份验证− 就像门锁系统只允许具有正确凭据的用户访问一样，它只向具有适当钥匙的用户提供访问。

• 以许可证形式进行授权− 一旦进入室内，个人就可以进入厨房并有权打开装有宠物食品的橱柜。个人可能没有权限进入卧室稍微休息一下。

在本例中，身份验证和授权一起使用。您有权进入宠物保姆的家（身份验证），这使您可以访问特定位置（授权）。

输入/输出和表单设计

输入设计

在信息系统中，输入是经过处理以产生输出的原始数据。在输入设计期间，开发人员必须考虑输入设备，例如 PC、MICR、OMR 等。

因此，系统输入的质量决定了系统输出的质量。设计良好的输入表单和屏幕具有以下属性：

• 它应该有效地服务于特定目的，例如存储、记录和检索信息。

• 它确保正确且准确地完成。

• 它应该易于填写且简单明了。

• 它应该关注用户的注意力、一致性和简洁性。

• 所有这些目标都是通过了解有关以下方面的基本设计原则来实现的：

  • 系统需要哪些输入？

  • 最终用户如何响应表单和屏幕的不同元素。

输入设计的目标

输入设计的目标是：

• 设计数据输入和输入过程

• 减少输入量

• 为数据捕获设计源文档或设计其他数据捕获方法

• 设计输入数据记录、数据输入屏幕、用户界面屏幕等。

• 使用验证检查并开发有效的输入控制。

数据输入方法

设计适当的数据输入方法对于防止在输入数据时出错非常重要。这些方法取决于数据是由客户在表单上手动输入然后由数据输入操作员输入，还是由用户直接在 PC 上输入。

系统应通过以下方式防止用户出错：

• 清晰的表单设计，留出足够的空间以便清晰地书写。
• 清晰的填写表单说明。
• 清晰的表单设计。
• 减少按键次数。
• 立即提供错误反馈。

一些流行的数据输入方法包括：

• 批处理输入方法（离线数据输入方法）
• 在线数据输入方法
• 计算机可读表单
• 交互式数据输入

输入完整性控制

输入完整性控制包括许多方法，可以消除最终用户常见的输入错误。它们还包括对各个字段值的检查；既包括格式，也包括所有输入的完整性。

使用事务日志创建数据输入和其他系统操作的审计跟踪，这提供了数据库中所有更改的记录，以便在发生任何故障时提供安全性和恢复手段。

输出设计

任何系统的输出设计都是最重要的任务。在输出设计过程中，开发人员需要确定所需的输出类型，并考虑必要的输出控制和原型报表布局。

输出设计的目标

输入设计的目标是：

• 开发能够满足预期目的并避免产生不需要的输出的输出设计。

• 开发满足最终用户需求的输出设计。

• 交付适当数量的输出。

• 以适当的格式形成输出，并将其定向到正确的人员。

• 使输出能够及时用于做出正确的决策。

现在让我们来看一下各种类型的输出：

外部输出

制造商为打印机创建和设计外部输出。外部输出使系统能够触发接收者采取行动，或向接收者确认行动。

一些外部输出被设计成周转输出，它们以表单的形式实现，并作为输入重新进入系统。

内部输出

内部输出存在于系统内部，由最终用户和管理人员使用。它们支持管理层的决策和报告。

管理信息系统产生三种类型的报告：

• 详细报告 - 它们包含几乎没有过滤或限制的当前信息，用于协助管理规划和控制。

• 汇总报告 - 它们包含趋势和潜在问题，这些问题经过分类和总结，专为不想查看详细信息的管理人员生成。

• 例外报告 - 它们包含例外情况，在向管理人员呈现信息之前，会根据某些条件或标准过滤数据。

输出完整性控制

输出完整性控制包括用于识别接收系统的路由代码，以及用于确认成功接收由网络协议处理的消息的验证消息。

打印或屏幕格式的报告应包括报告打印的日期/时间和数据。多页报告包含报告标题或描述以及页码。预印表格通常包含版本号和有效日期。

表单设计

表单和报表都是输入和输出设计的产物，是包含指定数据的业务文档。主要区别在于表单提供数据输入字段，而报表纯粹用于阅读。例如，订单表单、就业申请和信用申请等。

• 在表单设计过程中，设计人员应该了解：

  • 谁将使用它们

  • 它们将在哪里交付

  • 表单或报告的目的

• 在表单设计中，自动化设计工具增强了开发人员创建表单和报表原型并将其提交给最终用户进行评估的能力。

良好表单设计的目标

良好的表单设计对于确保以下方面至关重要：

• 通过提供正确的顺序、信息和清晰的标题来保持屏幕简洁。

• 通过使用适当的表单来满足预期目的。

• 确保准确填写表单。

• 通过使用图标、反向视频或闪烁光标等使表单更具吸引力。

• 方便导航。

表单类型

单页表单

• 这是一种手动或机器准备并在纸上打印的单份表单。对于原始副本的额外副本，碳纸被插入副本之间。

• 这是一种设计、打印和复制最简单且最便宜的表单，使用量较少。

套装/撕页式表单

• 这些是纸张，其中一次性碳纸插入单元集中，用于手写或机器使用。

• 碳纸可以是蓝色或黑色，标准等级中等强度。通常，蓝色碳纸最适合手写表单，而黑色碳纸最适合机器使用。

连续条/折叠式表单

• 这些是多个单元表单，以连续条的形式连接，每个表单对之间都有穿孔。

• 对于大批量使用，这是一种成本较低的方法。

无碳复写纸 (NCR)

• 它们使用无碳纸，这种纸张具有两种化学涂层（胶囊），一种在纸张正面，另一种在纸张背面。

• 施加压力时，这两个胶囊相互作用并产生图像。

测试和质量保证

需要在每个开发阶段检查软件系统预期的行为和进展方向，以避免工作重复、时间和成本超支，并确保在规定时间内完成系统。需要在每个开发阶段检查软件系统预期的行为和进展方向，以避免工作重复、时间和成本超支，并确保在规定时间内完成系统。

系统测试和质量保证有助于检查系统。它包括：

• 产品级质量（测试）
• 流程级质量。

让我们简要了解一下：

测试

测试是一个过程或活动，它根据指定的用戶需求检查软件的功能和正确性，以提高系统的质量和可靠性。它是系统开发中一种昂贵、耗时且关键的方法，需要对整个测试过程进行适当的规划。

成功的测试是能够发现错误的测试。它以明确的意图执行程序以查找错误，即使程序失败。这是一个评估系统的过程，旨在创建一个强大的系统，主要关注系统的薄弱环节或软件。

系统测试的特点

系统测试从模块级别开始，然后逐步集成整个软件系统。在测试系统时，会在不同的时间使用不同的测试技术。对于小型项目，由开发人员进行；对于大型项目，由独立的测试小组进行。

系统测试阶段

测试涉及以下阶段：

测试策略

这是一个声明，它提供有关用于测试系统的各个级别、方法、工具和技术的信息。它应该满足组织的所有需求。

测试计划

它提供了一个测试系统的计划，并验证被测系统是否满足所有设计和功能规范。测试计划提供以下信息：

• 每个测试阶段的目标
• 用于测试的方法和工具
• 每个测试活动所需的责任和时间
• 工具、设施和测试库的可用性
• 规划和执行测试所需的程序和标准
• 成功完成测试过程的因素

测试用例设计

• 为要测试的系统的每个模块确定多个测试用例。

• 每个测试用例都将指定如何测试特定需求或设计决策的实现，以及测试成功的标准。

• 测试用例以及测试计划作为系统规范文档的一部分或称为测试规范或测试描述的单独文档进行记录。

测试流程

它包含应遵循的步骤以执行每个测试用例。这些程序在称为测试过程规范的单独文档中指定。本文件还指定报告测试结果的任何特殊要求和格式。

测试结果文档

测试结果文件包含有关已执行的测试用例总数、错误数量和错误性质的简要信息。然后根据测试规范中的标准评估这些结果，以确定测试的总体结果。

测试类型

测试可以有多种类型，根据要发现的错误类型进行不同类型的测试：

单元测试

也称为程序测试，它是一种测试，其中分析师独立地测试或关注每个程序或模块。其目的是至少执行模块的每个语句一次。

• 在单元测试中，无法保证程序的准确性，并且难以详细测试各种输入组合。

• 与其他测试技术相比，它可以识别程序中的最大错误。

集成测试

在集成测试中，分析师测试多个模块一起工作的情况。它用于查找系统与其原始目标、当前规范和系统文档之间的差异。

• 在这里，分析师试图查找模块设计数据长度、类型和数据元素名称不同规范的区域。

• 它验证文件大小是否足够以及索引是否已正确构建。

功能测试

功能测试确定系统是否根据其规范和相关的标准文档正确运行。功能测试通常从系统的实现开始，这对于系统的成功至关重要。

功能测试分为两类：

• 正向功能测试 - 它涉及使用有效输入测试系统，以验证产生的输出是否正确。

• 反向功能测试 - 它涉及使用无效输入和不需要的操作条件测试软件。

系统测试规则

为了成功进行系统测试，您需要遵循以下规则：

• 测试应基于用户的需求。

• 在编写测试脚本之前，应彻底了解业务逻辑。

• 应尽快完成测试计划。

• 测试应由第三方进行。

• 它应该在静态软件上执行。

• 应针对有效和无效的输入条件进行测试。

• 应审查和检查测试以降低成本。

• 应在软件上进行静态和动态测试。

• 应记录测试用例和测试结果。

质量保证

这是对系统或软件产品及其文档的审查，以确保系统满足需求和规范。

• 质量保证的目的是通过根据规范持续交付产品来增强客户的信心。

• 软件质量保证 (SQA) 是一种技术，它包括软件专业人员应用的程序和工具，以确保软件满足其预期用途和性能的指定标准。

• SQA 的主要目标是向管理层提供软件项目及其开发产品的正确和准确的可视性。

• 它在系统开发的整个生命周期中审查和审核软件产品及其活动。

质量保证的目标

进行质量保证的目标如下：

• 监控软件开发过程和最终开发的软件。

• 确保软件项目是否正在实施管理层设定的标准和程序。

• 通知各个小组和个人有关 SQA 活动以及这些活动的结果。

• 确保软件中未解决的问题得到上级管理层的处理。

• 识别产品、流程或标准中的缺陷，并予以修复。

质量保证级别

为了认证软件产品，需要执行多个级别的质量保证和测试。

级别 1 - 代码走查

在此级别，检查离线软件是否存在任何违反官方编码规则的情况。通常，重点放在文档检查和代码注释级别。

级别 2 - 编译和链接

在此级别，检查软件是否可以在所有官方平台和操作系统上进行编译和链接。

级别 3 - 常规运行

在此级别，检查软件是否可以在各种条件下正常运行，例如特定数量的事件以及大小不同的事件规模等。

级别 4 - 性能测试

在此最终级别，检查软件的性能是否满足先前指定的性能级别。

系统实施和维护

实施是确保信息系统可运行的过程。它包括：

• 从零开始构建新系统
• 从现有系统构建新系统。

实施允许用户接管系统运行以进行使用和评估。这包括培训用户操作系统并规划顺利转换。

培训

系统中的人员必须详细了解他们的角色、如何使用系统以及系统能够或不能做什么。设计精良且技术精湛的系统的成功或失败可能取决于它们的操作和使用方式。

培训系统操作员

必须对系统操作员进行适当的培训，以便他们能够处理所有可能的运行，包括常规运行和非常规运行。应培训操作员识别常见的故障、如何识别它们以及出现故障时应采取的步骤。

培训包括创建故障排除列表，以识别可能出现的问题及其补救措施，以及在出现意外或异常问题时联系的个人姓名和电话号码。

培训还包括熟悉运行程序，这涉及逐步完成使用新系统所需的活动序列。

用户培训

• 最终用户培训是计算机信息系统开发的重要组成部分，必须向员工提供培训，使他们能够自行解决问题。

• 用户培训包括如何操作设备、对系统问题进行故障排除以及确定出现的问题是由设备还是软件引起的。

• 大多数用户培训都涉及系统本身的操作。必须设计培训课程，以帮助用户快速为组织动员。

培训指南

• 设定可衡量的目标
• 采用适当的培训方法
• 选择合适的培训场地
• 使用易于理解的培训材料

培训方法

讲师主导式培训

它涉及培训师和学员，他们必须同时见面，但不一定在同一地点。培训课程可以是一对一的，也可以是合作的。它分为两种类型：

虚拟教室

在这种培训中，培训师必须同时与学员见面，但不一定在同一地点。这里使用的主要工具包括：视频会议、基于文本的互联网中继聊天工具或虚拟现实软件包等。

普通教室

培训师必须同时在同一地点与学员见面。这里使用的主要工具包括黑板、投影仪、液晶投影仪等。

自定进度培训

它涉及培训师和学员，他们不需要在同一地点或同一时间见面。学员通过在方便时访问课程来学习技能。它分为两种类型：

多媒体培训

在这种培训中，课程以多媒体格式呈现，并存储在 CD-ROM 上。它最大限度地降低了在没有外部程序员帮助的情况下开发内部培训课程的成本。

基于网络的培训

在这种培训中，课程通常以超媒体格式呈现，并开发为支持互联网和内联网。它为最终用户提供即时培训，并允许组织定制培训需求。

转换

这是从旧系统迁移到新系统的一个过程。它提供了一种易于理解和结构化的途径，以改善管理层和项目团队之间的沟通。

转换计划

它包含对新系统实施和投入运行期间必须发生的所有活动的描述。它预料到可能出现的问题以及解决这些问题的方案。

它包括以下活动：

• 命名所有要转换的文件。
• 确定在转换期间开发新文件所需的数据要求。
• 列出所有所需的新文档和程序。
• 确定每个活动中使用的控制措施。
• 确定每个活动的负责人。
• 验证转换进度。

转换方法

有四种转换方法：

• 并行转换
• 直接切换转换
• 试点方法
• 分阶段实施方法

文件转换

这是将一种文件格式转换为另一种文件格式的过程。例如，可以将 WordPerfect 格式的文件转换为 Microsoft Word 格式。

为了成功转换，需要一个转换计划，其中包括：

• 了解目标系统和对现有系统的理解
• 团队合作
• 自动化方法、测试和并行操作
• 持续支持以纠正问题
• 更新系统/用户文档等

许多流行的应用程序都支持打开和保存相同类型的其他文件格式。例如，Microsoft Word 可以打开和保存许多其他文字处理格式的文件。

实施后评估审查 (PIER)

PIER 是一种用于评估项目结果并确定项目是否为流程、产品或服务带来预期效益的工具或标准方法。它使用户能够验证项目或系统是否在指定的时间段内和计划的成本内达到了预期的结果。

PIER 通过评估项目的开发和管理流程来确保项目达到了其目标。

PIER 的目标

进行 PIER 的目标如下：

• 确定项目相对于预计成本、效益和时间表的成功程度。

• 确定为项目增加额外价值的机会。

• 确定项目的优缺点，以便将来参考并采取适当的行动。

• 通过改进成本估算技术，对项目的未来提出建议。

审查过程应包括以下工作人员：

• 项目团队和管理层
• 用户人员
• 战略管理人员
• 外部用户

系统维护/增强

维护是指将某些东西恢复到其原始状态。增强是指添加、修改代码以支持用户规范的变化。系统维护使系统符合其原始要求，增强通过结合新要求来增加系统能力。

因此，维护更改现有系统，增强为现有系统添加功能，而开发则替换现有系统。它是系统开发的重要组成部分，包括纠正系统设计和实施中的错误、更新文档和测试数据的活动。

维护类型

系统维护可分为三种类型：

• 纠正性维护 - 使用户能够执行修复和纠正剩余问题。

• 适应性维护 - 使用户能够替换程序的功能。

• 完善性维护 - 使用户能够根据用户的需求和不断变化的需求修改或增强程序。

系统安全和审计

系统审计

这是一项调查，用于审查运行系统的性能。进行系统审计的目标如下：

• 比较实际性能和计划性能。

• 验证系统的既定目标在当前环境中是否仍然有效。

• 评估既定目标的实现情况。

• 确保基于计算机的财务和其他信息的可靠性。

• 确保处理过程中包含所有记录。

• 确保防止欺诈。

计算机系统使用情况审计

数据处理审计员审计计算机系统的使用情况以对其进行控制。审计员需要由计算机系统本身获得的控制数据。

系统审计员

审计员的角色始于系统开发的初始阶段，以便生成的系统是安全的。它描述了一种可以记录的系统利用率的概念，这有助于负载规划和决定硬件和软件规格。它表明了计算机系统的明智使用以及系统可能的滥用。

审计跟踪

审计跟踪或审计日志是一项安全记录，其中包含谁访问了计算机系统以及在给定时间段内执行了哪些操作。审计跟踪用于详细跟踪系统上数据的更改方式。

它提供了交易在其处理过程中所受各种控制技术的证据文件。审计跟踪并非独立存在。它们是作为追回丢失交易的会计的一部分进行的。

审计方法

审计可以通过两种不同的方式进行：

围绕计算机进行审计

• 获取样本输入并手动应用处理规则。
• 将输出与计算机输出进行比较。

通过计算机进行审计

• 建立审计跟踪，允许检查选定的中间结果。
• 控制总数提供中间检查。

审计注意事项

审计考虑使用叙述和模型来检查分析结果，以识别由于功能错位、流程或功能分割、数据流中断、数据缺失、冗余或不完整的处理以及未解决的自动化机会而导致的问题。

本阶段的活动如下：

• 识别当前环境问题
• 识别问题原因
• 识别替代方案
• 评估和可行性分析每个方案
• 选择和推荐最实用和合适的方案
• 项目成本估算和成本效益分析

安全

系统安全是指保护系统免受盗窃、未经授权的访问和修改以及意外或非故意损坏。在计算机系统中，安全涉及保护计算机系统的所有部分，包括数据、软件和硬件。系统安全包括系统隐私和系统完整性。

• 系统隐私涉及保护个人系统免受未经相关个人许可/知情的情况下访问和使用。

• 系统完整性关注系统中原始数据和处理数据的质量和可靠性。

控制措施

有多种控制措施，可以大致分为以下几类：

备份

• 根据时间紧迫性和大小，每天/每周定期备份数据库。

• 以较短的时间间隔进行增量备份。

• 备份副本保存在安全的远程位置，这对于灾难恢复尤其必要。

• 如果这是一个非常关键的系统并且在存储到磁盘之前不能容忍任何中断，则运行重复系统并镜像所有事务。

物理访问设施控制

• 物理锁和生物识别身份验证。例如，指纹
• 保安人员检查身份证或入场证。
• 识别所有读取或修改数据的人员，并在文件中记录。

使用逻辑或软件控制

• 密码系统。
• 加密敏感数据/程序。
• 培训员工进行数据维护/处理和安全。
• 连接到互联网时使用防病毒软件和防火墙保护。

风险分析

风险是失去有价值东西的可能性。风险分析始于通过识别系统的漏洞及其影响来规划安全系统。然后制定计划来管理风险并应对灾难。这样做是为了评估可能发生的灾难及其成本的概率。

风险分析是由具有不同背景的专家组成的团队工作，例如化学品、人为错误和工艺设备。

进行风险分析时，应遵循以下步骤：

• 识别计算机系统的所有组件。

• 识别每个组件面临的所有威胁和危害。

• 量化风险，即评估威胁成为现实时的损失。

风险分析——主要步骤

由于风险或威胁在不断变化，潜在损失也在不断变化，因此高级管理人员应定期进行风险管理。

风险管理是一个持续的过程，它包括以下步骤：

• 识别安全措施。

• 计算实施安全措施的成本。

• 将安全措施的成本与威胁的损失和概率进行比较。

• 选择和实施安全措施。

• 审查安全措施的实施情况。

面向对象方法

在面向对象的方法中，重点是将信息系统的结构和行为捕获到小型模块中，这些模块同时结合了数据和流程。面向对象设计 (OOD) 的主要目标是通过使其更易于使用来提高系统分析和设计的质量和生产力。

在分析阶段，OO 模型用于弥合问题和解决方案之间的差距。它在系统不断进行设计、适应和维护的情况下表现良好。它识别问题域中的对象，根据数据和行为对它们进行分类。

OO 模型具有以下好处：

• 它以低成本促进系统更改。

• 它促进组件的重用。

• 它简化了集成组件以配置大型系统的问题。

• 它简化了分布式系统的设计。

面向对象系统的元素

让我们了解一下 OO 系统的特征：

• 对象——对象是问题域中存在的东西，可以通过数据（属性）或行为来识别。所有有形实体（学生、病人）和一些无形实体（银行账户）都被建模为对象。

• 属性——它们描述有关对象的信息。

• 行为——它指定对象可以做什么。它定义对对象执行的操作。

• 类——类封装数据及其行为。具有相似含义和目的的对象组合在一起构成类。

• 方法——方法确定类的行为。它们只不过是对象可以执行的操作。

• 消息——消息是从一个对象到另一个对象的函数或过程调用。它们是发送到对象以触发方法的信息。本质上，消息是从一个对象到另一个对象的函数或过程调用。

面向对象系统的特性

面向对象系统具有以下几个优点：

封装

封装是信息隐藏的过程。它只是将过程和数据组合成一个单一实体。对象的データはシステムの他の部分からは隠され、クラスのサービスを通じてのみアクセスできます。これにより、オブジェクトによって使用されるメソッドの改善や修正が可能になり、システムの他の部分に影響を与えることなく行うことができます。

抽象化

这是一个选择必要的メソッドと属性を使用してオブジェクトを指定するプロセスです。ユーザーの視点からオブジェクトの本質的な特性に焦点を当てています。

关系

系统中的所有类都相互关联。对象不是孤立存在的，它们与其他对象之间存在关系。

对象关系有三种类型：

• 聚合——它表示整体与其部分之间的关系。

• 关联——在这种情况下，两个类以某种方式相关或连接，例如一个类与另一个类一起执行任务，或者一个类作用于另一个类。

• 泛化——子类基于父类。这表示两个类相似，但存在一些差异。

继承

继承是一个强大的特性，它允许通过继承现有类的属性和/或操作来从现有类创建子类。

多态性和动态绑定

多态性是采取多种不同形式的能力。它适用于对象和操作。多态对象是指其真实类型隐藏在超类或父类中的对象。

在多态操作中，不同类的对象可能以不同的方式执行操作。它允许我们仅通过了解对象的共同属性来操作不同类的对象。

结构化方法与面向对象方法

下表说明了面向对象方法与传统的结构化方法有何不同：

统一建模语言 (UML)

UML 是一种可视化语言，允许您对流程、软件和系统进行建模，以表达系统架构的设计。它是一种用于面向对象方式设计和记录系统的标准语言，允许技术架构师与开发人员进行沟通。

它被定义为由对象管理组创建和分发的规范集。UML 是可扩展的和可伸缩的。

UML 的目标是提供一套通用的面向对象术语和图表技术词汇，它足够丰富，可以对从分析到实现的任何系统开发项目进行建模。

UML 由以下部分组成：

• 图——它是流程、系统或其一部分的图形表示。

• 符号——它由在图表中协同工作的元素组成，例如连接器、符号、注释等。

类的 UML 符号示例

实例图-UML 符号

对对象执行的操作

对对象执行以下操作：

• 构造函数/析构函数——创建类的新的实例和删除类的现有实例。例如，添加新员工。

• 查询——访问状态而不更改值，没有副作用。例如，查找特定员工的地址。

• 更新——更改一个或多个属性的值并影响对象的状态。例如，更改员工的地址。

UML 的用途

UML 对以下目的非常有用：

• 模拟业务流程
• 描述系统架构
• 显示应用程序结构
• 捕获系统行为
• 模拟数据结构
• 构建系统的详细规范
• 草绘想法
• 生成程序代码

静态模型

静态模型显示系统的结构特征，描述其系统结构，并强调构成系统的部分。

• 它们用于定义类名、属性、方法、签名和包。

• 表示静态模型的 UML 图表包括类图、对象图和用例图。

动态模型

动态模型显示系统的行为特征，即系统如何响应外部事件。

• 动态模型识别所需的对象以及它们如何通过方法和消息协同工作。

• 它们用于设计系统的逻辑和行为。

• UML 图表表示动态模型包括序列图、通信图、状态图、活动图。

面向对象系统开发生命周期

它包括三个宏过程：

• 面向对象分析 (OOA)
• 面向对象设计 (OOD)
• 面向对象实现 (OOI)

面向对象系统开发活动

面向对象系统开发包括以下阶段：

• 面向对象分析
• 面向对象设计
• 原型设计
• 实施
• 增量测试

面向对象分析

本阶段关注确定系统需求，并为了理解系统需求而构建用例模型。用例是一个描述用户和计算机系统之间交互的场景。该模型代表用户的需求或用户对系统的看法。

它还包括识别构成应用程序的问题域中的类及其与其他类之间的关系。

面向对象设计

本阶段的目标是设计和细化在分析阶段识别的类、属性、方法和结构，以及用户界面和数据访问。本阶段还识别和定义支持需求实现的附加类或对象。

原型设计

原型设计能够帮助充分理解实现系统某些功能的难易程度。

它还可以让用户有机会评价设计的可用性和实用性。它可以进一步定义用例并使用例建模更容易。

实施

它使用基于组件的开发 (CBD) 或快速应用程序开发 (RAD)。

基于组件的开发 (CBD)

CBD 是一种工业化的软件开发过程方法，它使用各种各样的技术，例如 CASE 工具。应用程序开发从定制开发转向组装可互操作的预构建、预测试、可重用的软件组件。CBD 开发人员可以组装组件来构建完整的软件系统。

快速应用程序开发 (RAD)

RAD 是一套工具和技术，可用于比传统方法更快地构建应用程序。它并不取代 SDLC，而是对其进行补充，因为它更侧重于过程描述，并且可以与面向对象方法完美结合。

其任务是快速构建应用程序并通过 Visual Basic、PowerBuilder 等工具增量实现用户需求设计。

增量测试

软件开发及其所有活动（包括测试）都是一个迭代过程。因此，如果我们只在产品完全开发后才进行测试，这将是一件代价高昂的事情。在这里，增量测试就发挥了作用，产品在其开发的各个阶段都会进行测试。