系统开发和运行知识（上）：https://developer.aliyun.com/article/1529319
2.软件系统分析
2.1 基本概述
系统分析的目的是为项目团队提供对触发项目的问题和需求更全面的理解。系统分析阶段要求与系统用户一起工作以便清楚地定义购买或开发的新系统的业务需求和预期。
系统分析的主要任务是对现行系统进一步详细调查，将调查中所得到的文档资料集中，对组织内部整体管理状况和信息处理过程进行分析，为系统开发提供所需资料，并提交系统方案说明书。系统分析侧重于从业务全过程的角度进行分析，主要内容有业务和数据的流程是否通畅，是否合理；数据、业务过程和组织管理之间的关系；原系统管理模式改革和新系统管理方法的实现是否具有可行性等。
系统分析的主要阶段如下：
范围定义阶段。范围有哪些。
问题分析阶段。充分研究和理解问题域并全面分析其中存在的问题、机会和约束条件。
需求分析阶段。用户需要什么？
逻辑涉及阶段。绘制各种系统模型来记录需求。
决策分析阶段。分析那些候选方案并推荐一个将被设计、构造和实现的目标系统。
2.2 需求分析
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
软件需求是指用户解决问题或达到目标所需要的条件或能力，是系统要满足合同、标准、规范或其他正式规定文档所需具有的条件或者能力，以及反映这些条件或能力的文档说明。
软件需求的分类：
业务需求（整体全局）。反映企业或者客户对系统高层次的要求。
用户需求（用户视角）。描述了用户能够使用系统来做什么。
系统需求（计算机化）。从系统的角度来说明软件的需求。有功能需求、非功能需求和设计约束三方面的内容。
2.3 结构化分析
结构化分析(Structured Analysis, SA)方法是一种面向数据流的需求分析方法，适用于分析大型数据处理系统，是一种简单、实用的方法，现在已经得到广泛的使用。基本思想是自顶向下逐层分解，分解和抽象问题。
结构化分析主要输出功能模型（DFD，数据流图）、行为模型（STD）和数据模型（E-R）三种，数据字典用于描述说明这三种模型。
1）数据流图
数据流图（Data Flow Diagram,DFD），是一种最常用的结构化分析工具，从数据传递和加工的角度，用图形的方式刻画系统内数据的运行情况。
数据流图的基本成分：
外部实体。是指存在于软件系统之外的人员或组织，是不能用计算机处理的这一部分。
加工。也称数据处理，就是对数据进行某些操作或变换。
数据存储。存储数据，可访问的存储信息。
数据流。表示数据的流向，带有名字和流向的一些数据。
分层数据流图的画法：
画系统的输入和输出。系统加工部分，根据系统从哪些外部实体接收数据流，以及系统发送数据流到哪些外部实体，就可以画出系统的输入和输出图，这张图称为顶层图。
画系统的内部。把顶层图的加工系统分解成若干个加工，并用数据流将这些加工连接起来，使得顶层图中的输入数据经过若干个加工处理后变换成顶层图的输出数据流，这张图称为0层图。
画加工的内部。把每个加工看作一个小系统，该加工的输入输出数据流看成小系统的输入输出数据流。
对第2步分解出来的DFD子图中的每个加工，重复第3步的分解，知道图中尚未分解的加工都足够简单为止。
设计注意事项：
适当取名，避免空洞的名字。
加工输入、输出不应同名。
允许一个加工有多个数据流向另一个加工。
允许一个加工有两个相同的输出数据流向两个不同的加工。
一个存储首次出现时只与一个加工有关，则该存储作为加工的内部，而不必画出表现的是数据流而不是控制流。
保持父图和子图的平衡。父图中某加工的输入输出数据流必须与他的子图的输入输出数据流在数量和名字上相同。
保持数据守恒。一个加工所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据。
每个加工必须既有输入数据流，又有输出数据流。
整套数据流图中，每个数据存储必须既有读，又有写的数据流；但某一张子图中可以只有读或者写。
2）数据字典
数据字典，加工处理逻辑描述，包括如下内容：
- 数据元素（数据项）：包括数据项名，数据项含义说明、别名、数据类型、长度、取值范围、取值含义、与其他数据项的逻辑关系。
- 数据结构：数据结构它是用来描述数据元素之间的关系。
- 数据流：它是由一个或一组数据元素所组成的。
- 加工逻辑：数据流图中功能块的说明。结构化语言（有控制结构和运算）、判定表（逻辑条件少）和判定树（逻辑条件比较多）。
- 数据存储：数据流图中数据块的存储特性说明。
3.软件系统设计
3.1 结构化设计
1）系统设计基本原理
概要设计的基本任务是将系统分解为若干个子系统，建立整个系统的体系结构，若干子系统有设计软件系统总体结构、数据结构及数据库设计、编写概要设计文档、评审。
详细设计的基本任务是确定应该怎样具体地实现所要求的系统，对目标系统做出精准描述。输出结果是一系列的系统设计文件。
基本原理是自顶而下、逐步求精；抽象化；信息隐蔽；模块独立（高内聚、低耦合）。
基本原则：
- 保持模块的大小适中。
- 深度和宽度适中。
- 模块的扇入和扇出要合理。
- 模块的作用域应该在模块之内。
- 功能应该是可预测的。
2）模块独立
聚合是指模块内部各元素之间联系的紧密程度。内聚度越低，模块的独立性越差。聚合度由低到高如下：
偶然聚合：指一个模块内的各个处理元素之间没有任何联系。
逻辑聚合：指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。
时间聚合：把需要同时执行的动作组合在一起形成的模块为时间内聚模块。
通信聚合：指模块内所有处理元素都在同一个数据结构上操作，或者指各处理使用相 同的输入数据或者产生相同的输出数据。
顺序聚合：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入。
功能聚合：这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。
耦合是指模块之间联系的紧密程度。耦合性越高，则模块的独立性越差。模块间耦合的高低取决于模块间接又的复杂性、调用的方式及传递的信息。耦合度由低到高如下：
无直接耦合：指两个模块间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。因此，模块间耦合性最弱，模块独立性最高。
数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递。这种耦合程度较低，模块的独立性较高。
标记耦合：指两个模块之间传递的是数据结构。如高级语言中的数据组名、记录名、文件名等这些名字即为标记，其实传递的是这个数据结构的地址。
控制耦合：指一个模块调用另一个模块时，传递的是控制变量，被调模块通过该控制变量的值有选择地执行块内的某一功能。
公共耦合：指通过一个公共数据环境相互作用的那些模块之间的耦合。
内容耦合：这是程度最高的耦合。
3）信息流的类型
数据流类型包括变换流型和事务流型。
变换流。信息沿着输入通路进入系统，同时将信息的外部形式转换成内部表示，然后通过变换中心(也称主加工)处理，再沿着输出通路转换成外部形式离开系统。变换流型的 DFD 可以明显地分成输入、变换(主加工)和输出三大部分。
事务流。信息沿着输入通路到达一个事务中心，事务中心根据输入信息(即事务)的类型在若干个动作序列(称为活动流)中选择一个来执行，这种信息流称为事务流。
4）模块的类型
传出模块
传入模块
变换模块
协调模块
5）结构化设计常用工具
概要设计中有结构图（SC图）、层次图（H图）和HIPO图。
详细设计中有程序流程图（程序框图）、盒图（N-S图）、问题定义图（PAD图）、程序描述语言（PDL，伪代码）。
3.2 面向对象设计
面向对象分析方法(Object-Oriented Analysis,00A)的基本任务是运用00方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和责任，以及它们之间的关联，最终产生一个符合用户需求，并能直接反映问题域和系统功能的00A模型及其详细说明。
对象。基本的运行时的实体，它既包括数据(属性)，也包括作用于数据的操作(行为)。
消息。对象之间进行通信的一种构造。
类。一组对象共有的特性。类是在对象之上的抽象，对象是类的具体化，是类的实例(instance)。
继承。父类和子类之间共享数据和方法的机制。
多态。不同的对象收到同一消息可以产生完全不同的结果。
封装。把对象的属性封装。
动态绑定。一个把过程调用和响应调用所需要执行的代码加以结合的过程.
统一建模语言(Unified Modeling Language，UML)是面向对象软件的标准化建模语言，不是一种方法。UML由构造块、规则和公共机制三要素构成。
构造块。有事物、关系和图3中构造块。事物是对模型中最具有代表性的成分的抽象（结构事物、行为事物、分组事物、注释事物）；关系把事物结合在一起（依赖关系、关联关系、泛化关系、实现关系）；图聚集了相关的事物（类图、对象图、包图、组合结构图、构件图、部署图、制品图、用例图、交互图（顺序图、通信图、定时图、交互概览图）、状态图、活动图）。
规则。规则是支配构造块如何放置在一起的规定，包括给构造块命名；范围、可见性、完整性。
公共机制。公共机制是指达到特定目标的公共UML方法，主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制。
UML中4中关系：依赖、关联、泛化和实现，图形表示如下：
依赖是两个事物间的语义关系，其中一个事物(独立事物)发生变化会影响另一个事物(依赖事物)的语义。
关联是一种结构关系，它描述了一组链，链是对象之间的连接。聚集是一种特殊类型的关联，它描述了整体和部分间的结构关系。
泛化是一种特殊或一般关系，特殊元素(子元素)的对象可替代一般元素(父元素)的对象。
实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。在两种地方要用到实现关系：一种是在接又和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。
4.软件系统测试
1）基本概念
系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。
系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。规范化的测试过程如下：
制定测试计划。测试计划的内容主要有测试的内容、进度安排、测试所需的环境和条件、测试培训安排等。
编制测试大纲。测试大纲是测试的依据，它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。
根据测试大纲设计和生成测试用例，产生测试设计说明文档，其内容主要有被测项目、输入数据、测试过程和预期输出结果等。
实施测试。一系列的测试周期组成的，在每个测试周期中，测试人员和开发人员将依据预先编制好的测试大纲和准备好的测试用例，对被测软件或设备进行完整的测试。
生产测试报告。主要对测试进行概要说明，列出测试的结论，指出缺陷和错误。另外，给出一些建议，如可采用的修改方法，各项修改预计的工作量及修改的负责人员。
测试的基本原则：
应尽早并不断进行测试。
程序员应避免测试自己设计的程序。
既要选择有效、合理的数据，也要选择无效、不合理的数据。
修改后应进行回归测试。
尚未发现的错误数量与该程序已发现错误数成正比。
2）测试阶段
测试阶段分为单元测试、集成测试、确认测试和系统测试。
单元测试也称为模块测试，在模块编写完成且无编译错误后就可以进行。单元测试侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测试法。这类测试可以对多个模块同时进行。
集成测试就是把模块按系统设计说明书的要求组合起来进行测试。自顶向下集成、自底向上集成，即增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，并加快工程进度。
确认测试。分产品和项目的测试，确认测试的任务就是进一步检查软件的功能和性能是否与用户要求。内部确认测试、Alpha测试（开发环境上测试）、Beta测试（用户使用环境）、验收测试。只有通过Beta测试的项目才能交付给用户。
系统测试。将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种集成测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。内容有恢复测试，安全性测试，压力测试，性能测试，可靠性、可用性和可维护性测试，安装测试。
3）测试类型
动态测试是指通过运行程序发现错误。
黑盒测试法。也称功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。进行黑盒测试主要为了发现以下错误：
是否有错误的功能或遗漏的功能?
界面是否有误?输入是否正确接收?输出是否正确？
是否有数据结构或外部数据库访问错误？
性能是否能够接受？
是否有初始化或终止性错误?
常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图。
等价类划分。每一类的代表性数据在测试中的作用等价于这一类中的其他值。这样就可以用少量代表性的测试用例取得较好的测试效果。
边界值分析。输入的边界比中间更加容易发生错误，因此用边界值分析来补充等价类划分的测试用例设计技术。
错误推测。基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
因果图法。从自然语言描述的程序规格说明中找出因(输入条件)和果 (输出或程序状态 的改变)，通过因果图转换为判定表。
白盒测试法。也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要，原则如下：
程序模块中的所有独立路径至少执行一次。
在所有的逻辑判断中，取“真”和“假”的两种情况至少都能执行一次。
每个循环都应在边界条件和一般条件下各执行一次。
测试程序内部数据结构的有效性等。
常用的技术是逻辑覆盖、循环覆盖和基本路径测试：
逻辑覆盖。考察用测试数据运行被测程序时对程序逻辑的覆盖程度，主要有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、修正的条件判定覆盖、条件组合覆盖、路径覆盖。
循环覆盖。执行足够的测试用例，使得循环中的每个条件都得到验证。
基本路径测试。在程序控制流图的基础上，通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
灰盒测试法。既有黑盒测试也有白盒测试。
静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
桌前检查。开发或者测试人员自己检查自己的程序，再交给他人。
代码审查。通过会议，代码委员会进行检查。
代码走查。需要先提供测试样例，再通过会议，代码委员会进行检查。
5.软件系统运行和维护
软件维护是软件生命周期中的最后一个阶段，处于系统投入生产性运行以后的时期中，因此不属于系统开发过程。软件维护是在软件己经交付使用之后，为了改正错误或满足新的需求而修改软件的过程，即软件在交付使用后对软件所做的一切改动。
系统的可维护性的评价指标：可理解性、可测试性、可修改性。
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改。包括硬件维护、软件维护和数据维护。软件维护的内容有：
正确性维护。
适应性维护。
完整性维护。
预防性维护。
