系统软件开发基础知识

最近最火的是孩子考了多少分，能上那个好大学，出现了我的大学的我的梦。
他们的大学他们的梦，我是啥，我的软件我的梦。

下面了解到的基础知识做一个归纳，本人了解这方面的知识点可能很片面，或许也是你正在了解的或者不知道的。

软件基础包括哪些

软件基础知识展现如下：

• 软件有生命周期
• 软件需求
• 软件设计过程
• 软件审计
• 软件测试
• 软件安全
• 面向对象
• 系统建模
• 系统运维
• 软件变更
• 软件图
• 软件状态机
• 软件组件
• 软件计划
• 软件联网
• 系统实施
• 软件关系
• 软件核心
• 软件过程

软件有生命周期

信息系统的生命周期可以分为立项、开发、运维及消亡四个阶段。
立项阶段结束的里程碑是论证通过或通过评估的可行性研究报告。
广义开发阶段包括系统实施和验收，在系统建立之初就要考虑消亡因素。
立项阶段结束的里程碑是论证通过或通过评估的可行性研究报告。

信息系统项目的生命周期模型主要包括有瀑布模型、V 模型、喷泉模型、螺旋模型、统一过程，增量、迭代模型，其中选项D不属于信息系统项目的生命周期模型。

（1）瀑布模型
瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。瀑布模型中每项开发活动具有以下特点：
1）从上一项开发活动接受其成果作为本次活动的输入。
2）利用这一输入，实施本次活动应完成的工作内容
3）给出本次活动的工作成果，作为输出传给下一项开发活动。
4）对本次活动的实施工作成果进行评审。其缺点为过程基本不可迭代，需求在开始的不确定性，错误到最后才能发现，开发进程呈现阻塞状态。
（2）V 模型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
（3）原型化模型
原型化模型的第一步是建造一个快速原型，实现客户或未来的用
户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便
真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型
基础上开发出用户满意的产品，同时增量模型也是原型化开发方法。
模型要点为瀑布和原型模型相结合，强调版本升级。
（4）螺旋模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线
性顺序（瀑布）模型中控制的和系统化的方面结合起来，使得软件的
增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的
增量发布。
螺旋线代表随着时间推进的工作进展。开发过程具有周期性重复的螺旋线形状。4 个象限分别标志每个周期所划分的 4 个阶段：制订计划、风险分析、实施工程和客户评估。螺旋模型主要统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。
（5）迭代模型
迭代模型：体现认识事物的循环迭代性，强调开发活动之间的无间隙性，无明显的活动阶段划分，适用于面向对象的开发过程。
RUP（Rational Unified Process）软件统一过程是一种“过程方法”，它就是迭代模型的一种。
RUP 中的软件生命周期在时间上被分解为 4 个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构建阶段（Construction）和交付阶段（Transition）。这 4 个阶段的顺序执行就形成了一个周期。每个阶段结束于一个主要的里程碑（Major Milestones）。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。
信息系统不可避免地会遇到系统更新改造、功能扩展，甚至废弃重建等情况。对此，在信息系统建设的初期就应该注意系统消亡条件和时机，以及由此而花费的成本。

软件需求

软件需求是针对待解决问题的特性的描述。所定义的需求必须可以被验证。在资源有限时，可以通过权衡需求优先级。通过需求分析，可以检测和解决需求之间的冲突。发现系统的边界。并详细描述出系统需求。
软件设计是根据软件需求，产生一个软件内部结构的描述，并将其作为软件构造的基础。通过软件设计，描述出软件架构及相关组件之间的接口。然后，进一步详细地描述组件，以便能构造这些组件。通过软件设计得到要实现的各种不同模型，并确定最终方案。其可以划分为软件架构设计（也叫高层设计）和软件详细设计两个阶段。

软件需求包括功能需求、非功能需求、设计约束.
（1）功能需求
功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足。
（2）非功能需求
非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、可维护性、效率等）和其他非功能需求。

（3）设计约束
设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明，例如，必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下，必须采用什么样的软件开发工具等。

软件需求是针对解决问题的特性的描述，所定义的需求必须可以被验证。在资源有限时，可以通过优先级对需求进行权衡。通过需求分析，可以检测和解决需求之间的冲突，可以发现系统的边界和详细描述出系统需求。
通过需求分析，可以发现系统的边界
通过需求分析，可以详细描述出系统需求

软件需求的一个基本特征就是可验证性。需求可验证性的目标，就是尽可能发现存在的错误，以减少因为需求错误而带来的返工等问题。

• 软件设计过程
  软件设计过程定义了一个开放的接口。软件开发流程即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序等一系列操作。其中软件设计又分为概要设计与详细设计两个阶段

面向对象设计的基本任务，把面向对象分析模型转化为面向对象的设计模型（具体包括以下任务）设计人员必须完成以下任务：设计用例实现方案、设计技术支撑设施、设计用户界面、精化设计模型。

软件架构主要职责
（1）确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求

（2）系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向" 分解，还要对同一逻辑层分块，进行“横向”分解。这体现了软件架构师的功力

（3）技术选型
架构师通过对系统的一系列分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。例如：Web Server运行在Windows上还是Linux上？数据库采用MSSQL、Oracle还是MySQL？是否需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？架构师对产品和技术的选型只限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
（4）制定技术规格说明
架构师在项目开发过程中是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照他的架构意图去实现各项功能。架构师通过他制定的技术规格说明书（UML视图、Word文档、Visio文件）与开发者沟通，保证开发者可以从不同角度去观察、理解各自承担的子系 统或者模块。架构师还需要与项目经理、需求分析员，甚至与最终用户保持沟通。

需求规格说明书是做软件架构之前就需要存在的。在需求规格说明书的基础上做架构设计

考题考查的知识点为结构设计基础知识。考题考查的知识点为结构设计基础知识。

软件审计

本考题考查的知识点为技术评审基础知识，
评审与审计包括管理评审、技术评审、检查、走查、审计等。管理评审的目
的是监控进展，决定计划和进度的状态，或评价用于达到目标所用管理方法的有效性。技术评审的目的是评价软件产品，以确定其对使用意图的适合性，目标是识别规范说明和标准的差异，并向管理提供证据，以表明产品是否满足规范说明并遵从标准，而且可以控制变更。软件开发的技术评审是一种由软件工程师和其他人进行的软件质量保障活动。

软件审计是对过程的遵从性评价。软件审计的目的是提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立评价。审计是正式组织的活动，识别违例情况，并产生一个报告，采取更正性行动。软件质量保证是通过制订计划、实施和完成等活动保证项目生命周期中的软件产品和过程符合其规定的要求。软件过程管理是软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。不同的体系会有不同的划分，美国PMI将其划分为启动、规划、执行、监控、收尾五大过程组。软件过程管理即将软件的各过程组过程使用系统的方法管理起来。软件走查的目的是评价软件产品，走查也可以用于培训软件产品的听众，主要目标是：发
现异常、改进软件产品、考虑其他实现、评价是否遵从标准和规范说

软件测试

软件测试工作在需求阶段就应该开始

从是否关心软件内部结构和具体实现的角度划分白盒测试、黑盒测试、灰盒测试。白盒测试称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。关于白盒测试和黑盒测试，其分类方法就是测试人员是否需要知道代码实现，是否需要对实现的代码和逻辑结构进行测试，所以此题选A。选项B阐述的从是否执行程序的角度划分，有静态测试和动态测试。选项C阐述的从软件开发的过程按阶段划分，有单元测试、集成测试、确认测试、系统测试、验收测试。

软件测试时一个系列过程活动，软件测试是针对一个程序的行为，在有限测试用例集合上，动态验证是否达到预期的行为，需要选取适当的测试用例。测试不仅是检错预防措施是否有效的主要手段，而且是识别由于某种原因预防措施无效而产生错误的主要手段。

测试时为了评价和改进产品质量、识别产品的缺陷和问题而进行的活动。软件测试时针对一个程序的行为，在有限测试用例集合上，动态验证是否达到预期的行为。测试不再只是一种仅在编码阶段完成后才开始的活动。现在的软件测试被认为是一种应该包括在整个开发和维护过程中的活动，它本是实际产品构造的一个重要部分。软件测试伴随开发和维护过程，通常可以在概念上划分为单元测试、集成测试和系统测试三个阶段。

项目投入测试的时间应该是占用一定的比例，达到测试的目的和效果，不可以随意多一点少一点。

测试分为三个阶段：测试准备阶段，测试实现阶段、测试总结阶段。
（1）测试准备阶段
即完成测试计划、测试用例、测试数据准备、测试环境准备及部署测试。
（2）测试实现阶段
实际的测试过程，在此阶段中经历功能测试、集成测试、系统测试、回归测试。但功能测试、集成测试、系统测试根据测试时间及人力可能是并行进行的，也可能是迭代进行的
（3）测试总结阶段
对整个测试过程及测试问题进行总结提出改进建议。在我们现阶段测试中测试的分类为：功能测试、集成测试、系统测试、回归测试。功能测试主要以功能实现为基础。集成测试以业务数据流为基础进行测试。系统测试主要在不同平台或操作系统下进行的测试。回归测试主要针对以上问题进行测试。

黑盒测试又叫功能测试，它不涉及程序的内部逻辑。除了测试程序外，它还适用于对需要分析阶段的软件文档进行测试。测试的方法有黑盒测试、白盒测试、α测试和β测试。

bug处理流程：先发现bug，确认bug所属模块，填写测试报告。然后PM将bug分配给开发人员。开发人员判断，如果是自己负责的，就对问题进行处理，如果不是，就让PM重新分配。测试人员再对已经修改的bug做回归测试。

• 软件安全
  信息系统安全包含人为、管理和技术层面的威胁
• 面向对象
  面向对象设计的基本任务，把面向对象分析模型转化为面向对象的设计模型（具体包括以下任务）设计人员必须完成以下任务：设计用例实现方案、设计技术支撑设施、设计用户界面、精化设计模型。

面向对象的基本概念有对象、类、抽象、封装、继承、多态、接口、消息、组件、模式和复用等。
多态是一种方法，这种方法使得在多个类中可以定义同一个操作或属性名，并在每个类中可以有不同的实现。多态使得一个属性或变量在不同的时期可以表示不同类的对象。

继承表示类之间的层次关系，这种关系使得某类对象可以继承另外一类对象的特征（attributes）和操作（operations），继承又可分为单继承和多继承，单继承是子类只从一个父类继承，而多继承中的子类可以从多于一个的父类继承，Java是单继承的语言，而C++允许多继承。假设类B继承类A，即类B中的对象具有类A的一切特征（包括属性和操作）。类A称为基类或父类或超
类，类B称为类A的派生类或子类，类B在类A的基础上还可以有一些扩展

封装是将相关的概念组成一个单元，然后通过一个名称来引用它。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。对于银行账户而言，有取款和存款的行为特征，但实现细节对于客户而言并不可见，所以在进行 ATM 提款交易的过程中，我们并不知道交易如何进行，对应账户是如何保存状态的，这就体现了对象的封装。

软件复用是指将已有的软件及其有效成分用于构造新的软件或系统。组件技术是软件复用实现的关键。

聚合是关联关系的一种特例，它体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享，比如计算机与CPU、公司与员工的关系等。这种关系表现在代码层面，和关联关系是一致的，只能从语义级别来区分 UML中还有继承、实现、依赖、关联和组合等多种类间关系。

面向对象建模方法有很多种，也都在进一步的发展和完善中。OMT法是目前最为成熟和实用的方法之一。它从三个方面对系统进行建模，每个模型从一个侧面反映系统的特性，三个模型分别是：对象模型、动态模型和功能模型。
形象地说，功能模型定义“系统应该做什么”，动态模型定义“系统应该何时做”，对象模型定义“系统应该对谁做”。

对象是对客观事物的抽象，类是对对象的抽象。它们的关系是，对象是类的实例，类是对象的模板。类和对象，可以先声明类类型，再定义对象，也可以在声明类类型的同时定义对象

（1）对象
由数据及操作所构成的封装体，是系统中用来描述客观事物的一个封装是构成系统的一个基本单位。对象三要素：对象标识、对象状态、对象行为。
（2）类
是现实世界实体化的描述。类将实体的数据和函数封装在一起。类的数据也叫状态、属性或特征。它表示静态的一面。类的函数也叫功能、操作或服务，表现类的动态一面。
（3）类和对象的关系
对象是类的实例。一个类可以有多个对象，一个对象只能是一个类的实例。

多态是一种方法，这种方法使得在多个类中可以定义同一操作或属性，并在每个类中可以有不同的实现。多态性使得一个属性或变量在不同的时期可以表示不同类的对象。

多态（Polymorphism）按字面的意思就是“多种状态”。在面向对象语言中，接口的多种不同的实现方式即为多态。引用CharlieCalvert对多态的描述——多态性是允许你将父对象设置成为和一个或更多的他的子对象相等的技术，赋值之后，父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作。通俗地理解，多态就是同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。

系统建模

UML 是一个通用的可视化建模语言，它是面向对象分析和设计的一种标准化表示，UML 适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具，UML 并没有定义一种标准的开发过程，但它比较适用于迭代式的开发过程。UML不是一种可视化的程序设计语言，而是一种可视化的建模语言。UML 不是过程也不是方法，但允许每一种过程和方法使用它。UML 描述了系统的静态结构和动态行为，它将系统描述为一些独立的相互作用的对象，构成为外界提供一定功能的模型结构，静态结构定义了系统中重要对象的属性和服务，以及这些对象之间的相互关系，动态行为定义了对象的时间特性和对象为实现目标而相互进行通信的机制。

统一建模语言Unified Modeling Language（UML）用于对软件进行可视化描述、构造和建立软件系统的文档。UML适用于各种软件开发方法，软件生命周期的各个阶段，各种应用领域以及各种开发工具，是一种总结了以往建模技术的经验并吸收了当今优秀成果的标准建模方法。需要注意的是，UML 是一种可视化的建模语言，

面向对象建模方法有很多种，也都在进一步的发展和完善中。OMT法是目前最为成熟和实用的方法之一。它从三个方面对系统进行建模，每个模型从一个侧面反映系统的特性，三个模型分别是：对象模型、动态模型和功能模型。形象地说，功能模型定义“系统应该做什么”，动态模型定义“系统应该何时做”，对象模型定义“系统应该对谁做”

UML（统一建模语言）基本概念。
（1）依赖
描述了一个类的变化对依赖于它的类产生影响的情况。
（2）关联
描述了类的结构之间的关系。
（3）聚合
特殊关联关系，指明一个聚集（整体）和组成部分之间的关系。
（4）组合
语义更强的聚合，部分和整体具有相同的生命周期。
（5）包含
箭头指向的用例为被包含的用例，称为包含用例。箭头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整。
（6）扩展
箭头指向的用例为被扩展的用例，称为扩展用例。箭头出发的用例为基用例。
（7）泛化
泛化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般一方。常存在于父类与子类、父接口与子接口之间

统一建模语言基础知识。
（1）用例图（use case diagram）
展现一组用例、参与者（一种特殊的类）及它们之间的关系，它描述了系统与外部系统及用户之间的交互。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
（2）状态图（state diagram）
展现一个状态机，它由状态、转移、事件和活动组成。状态图展现了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
（3）顺序图（sequence diagram）
又称序列图。是一种交互（interaction diagram），交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
（4）类图（class diagram）
展现了一组类、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出了系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。

Unified Modeling Language（UML）又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。UML 规范用来描述建模的概念有，类（对象的）、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及转态。

信息系统项目的生命周期模型主要包括有瀑布模型、V 模型、喷泉模型、螺旋模型、统一过程，增量、迭代模型
（1）瀑布模型
瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。
瀑布模型中每项开发活动具有以下特点：
1）从上一项开发活动接受其成果作为本次活动的输入。
2）利用这一输入，实施本次活动应完成的工作内容。、
3）给出本次活动的工作成果，作为输出传给下一项开发活动。
4）对本次活动的实施工作成果进行评审。其缺点为过程基本不可迭代，需求在开始的不确定性，错误到最后才能发现，开发进程呈现阻塞状态。

（2）V 模型
V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
（3）原型化模型
原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品，同时增量模型也是原型化开发方法。
模型要点为瀑布和原型模型相结合，强调版本升级。
（4）螺旋模型
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来，使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。
螺旋线代表随着时间推进的工作进展。开发过程具有周期性重复的螺旋线形状。4 个象限分别标志每个周期所划分的 4 个阶段：制订计划、风险分析、实施工程和客户评估。螺旋模型主要统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。
（5）迭代模型
迭代模型：体现认识事物的循环迭代性，强调开发活动之间的无间隙性，无明显的活动阶段划分，适用于面向对象的开发过程。

RUP（Rational Unified Process）软件统一过程是一种“过程方法”，它就是迭代模型的一种。
RUP 中的软件生命周期在时间上被分解为 4 个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构建阶段（Construction）和交付阶段（Transition）。这 4 个阶段的顺序执行就形成了一个周期。每个阶段结束于一个主要的里程碑（Major Milestones）。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。

V模型示意图可知，需求分析阶段就可以开始编写验收测试计划，概要设计阶段就可以编写系统测试计划，详细设计阶段就可以编写集成测试计划，编码阶段就应编写单元测试计划。

UML 标准并没有定义一种标准的开发过程，但它比较适用于迭代式的开发过程，是为支持大部分现存的面向对象开发过程而设计的。
V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
（1）单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
（2）集成测试的主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其他程序部分之间的接口上可能存在的错误。
（3）系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行，例如在产品设置中是否能达到预期的高性能。
（4）验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计的主流。用例建模技术是从用户的角度描述系统功能需求的。在宏观上给出模型的总体轮廓。用例模型（Use case model）描述的是外部执行者（actor），如用户所理解的系统功能。它描述的是一个系统“做什么（What）”，而不是说明“怎么做（How）”,用例模型不关心系统设计。用例模型主要用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成共识。用例模型由若干个用例图构成，在UML中构成用例图的主要元素是用例和执行者及它们之间的联系。定义子系统接口参数、编写代码、改进系统的性能不属于分析阶段

用例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。也就是说，用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。顺序图是一种交互图，展现了一种交互，它由一组对象或参与者，以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图

系统运维

运维工作有软件开发的工作，运行维护的目的就是保证系统正常运用，所以保证系统的可用性和稳定性是运维工作的重要目的之一，。运维工程师要进行运维工作，当然需要定期进行巡检，运维工作量的结算不应以运维工程师的统计为依据，应该是实际系统本身或是系统变更为一定的依据，

运维管理平台使运维自动化、操作化，而并没有降低对运维人员
的技术要求

软件变更

变更管理的基本原则是首先建立项目基准、变更流程和变更控制委员会。
（1）基准管理
基准是变更的依据。在项目实施过程中，制定基准计划并经过评审后即建立初始基准，此后应针对每次批准的变更重新确定基准，选项A描述的内容是正确的。
（2）建立变更控制流程
建立或选用符合项目需要的变更管理流程后，所有变更都必须遵循这个流程进行控制。流程的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的共识和信息流转等元素有效地综合起来，按科学的顺序进行变更，选项C描述的内容是正确的。
（3）建立变更控制委员会
（4）完整体现变更的影响
（5）变更产生的相关文档应纳入配置管理中
可以使用手工或自动化工具进行配置管理，目前常用的配置管理工具有 Rational ClearCase、Perforce、CA CCC/Harvest、Merant PVCS、Microsoft VSS、CVS等，常用的开源免费的配置管理工具有SVN、GIT、CVS等

软件图

数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
数据流程图中有以下几种主要元素：
（1）数据流
数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成，如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。
（2）源点和终点（又称端点）是系统外的实体，称作外部项它们存在于环境之中，与系统有信息交流，从源点到系统的信息叫系统的输入。从系统到终点的信息称系统的输出。同—个端点可以是人或其他系统。在 DFD 中引入源点和终点是为了便于理解系统，所以不需要详细描述它们。它们可有编号，以“S”开头。
（3）对数据的加工（处理）
加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。
（4）数据存储
表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。
数据流图有四种基本图形符号：“→”箭头，表示数据流。〇：圆或椭圆，表示加工。=：双杠（带一边开口，一边闭合），表示数据存储。□：方框，表示数据的源点或终点。

考查的知识点为UML图。
（1）用例图（use case diagram）
展现一组用例、参与者（一种特殊的类）及它们之间的关系，它描述了系统与外部系统及用户之间的交互。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其他工作流起到指导作用。
（2）类图（class diagram）
展现了一组类、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出了系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。
（3）对象图（object diagram）展现了一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
（4）部署图（deployment diagram）
展现了对运行时的处理结点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个结点包含一个或多个部署图。

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的各种关系，包括泛化，包括。扩展等。
泛化和类中的泛化概念是一样的，子用例继承父用例的行为和含义，还可以增加或覆盖父用例的行为。子用例可以出现在任何父用例出现的位置（父和子均有具体的实例）。父用例是“订票”，其两个子用例分别是“电话订票”和“网上订票”。这两个用例都继承了父用例的行为，并添加了自己的行为。所

软件状态机

本考题考查的知识点为统一建一个状态机，它由状态、转移、事件和活动组成。状态图展现了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。

软件组件

组件是软件系统可替换的、物理的组成部分，它封装了实现体（实现某个职能）.并提供了一组接口的实现方法。可以认为组件是一个封装的代码模块或大粒度的运行对的模块，也可将组件理解为具有一定功能、能够独立工作或同其他组件组合起来协同工作的对象。

软件计划

软件联网

实时信息系统是系统需要及时响应外界事件的请求在规定的严格时间内完成事件的处理，要求的是实时。批处理信息系统是作业成批处理和多道程序运行，即在系统内同时存放并运行几道项目独立的程序，由系统成批处理。其重点是多任务批处理。管理信息系统是人利用计算机软硬件等办公设备进行信息的收集、整理、传输、存储等。联网信息系统关注的重点是通过互联网做到信息的传输与同步。联网信息系统是基于计算机网络，在各种操作系统上按照网络体系结构协议、标准开发的软件，包括网络管理、通信、安全、资源共享和各种网络应用。在联网信息系统下，网络中的多台计算机能相互连通和进行资源共享

系统实施

目实施阶段，是将设计阶段的成果在计算机或网络上具体实现，即将设计文本变成真实的可交付成果

软件关系

UML 中类与类，以及类与接口，接口与接口的关系有：泛化（generalization）、关联（association）、依赖（dependency）、实现（realization）四种。泛化（generalization）关系是指一个类（子类、子接口）继承另外一个类（称为父类、父接口）的功能，并可以增加它自己新功能的能力，继承是类与类或者接口与接口最常见的关系，在Java中通过关键字extends来表示。
UML的泛化关系基础知识。
（1）聚合关系（Aggregation）
表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。
（2）泛化关系（Generalization）
A是B和C的父类，B.C具有公共类（父类）A，说明A是B，C的一般化（概括，也称泛化）。迭代是重复反馈过程的活动，其目的通常是为了逼近所需目标或结果。每一次对过程的重复称为一次“迭代”，而每一次迭代得到的结果会作为下一次迭代的初始值。

类与类之间的关系通常有4种，即依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）、实现关系（Realization）。
（1）依赖关系（Dependency）
表示两个或多个模型元素之间语义上的连接关系，“绘图方式”虚线箭头，箭头指向被使用者。
（2）泛化关系（继承）（Generalization）
描述类的一般与具体之间的关系，描述的“is a kind of”的关系，“绘图方式”实线空心三角箭头，箭头指向父类。
（3）关联关系（Association）
表示一个事物的对象与另一个事物的对象之间的语义上连接，简单地理解为两个类或类与接口之间的强依赖关系。“绘图方式”实线箭头，双向箭头或无箭头。
（4）实现关系（Realization）
将一种模型关系与另一种模型关系连接起来，从而说明和其实现之间的关系，简单地理解为一个类或多个类实现一个接口，“绘图方式”封闭空箭头虚线，箭头指向接口。

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的各种关系，包括泛化，包括。扩展等。
泛化和类中的泛化概念是一样的，子用例继承父用例的行为和含义，还可以增加或覆盖父用例的行为。子用例可以出现在任何父用例出现的位置（父和子均有具体的实例）

软件SPI核心

软件过程改进帮助软件企业对其软件开发过程的改变进行计划、措施制定以及实施。软件过程改进的第一步从分析问题开始，找到问题所在后，提出改进措施。
软件过程改进（SPI）的五条核心原则分别是：注重问题、强调知识创新、鼓励参与、领导层的统一、计划不断改进。

软件过程

软件设计过程定义了一个开放的接口。软件开发流程即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序等一系列操作。其中软件设计又分为概要设计与详细设计两个阶段。
（1）概要设计
首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。
（2）详细设计
在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

根据近阶段测试情况，现把测试分为三个阶段：测试准备阶段，测试实现阶段、测试总结阶段。
（1）测试准备阶段
即完成测试计划、测试用例、测试数据准备、测试环境准备及部署测试。
（2）测试实现阶段
实际的测试过程，在此阶段中经历功能测试、集成测试、系统测试、回归测试。但功能测试、集成测试、系统测试根据测试时间及人力可能是并行进行的，也可能是迭代进行的。
（3）测试总结阶段
对整个测试过程及测试问题进行总结提出改进建议。
在我们现阶段测试中测试的分类为：功能测试、集成测试、系统测试、回归测试。功能测试主要以功能实现为基础。集成测试以业务数据流为基础进行测试。系统测试主要在不同平台或操作系统下进行的测试。回归测试主要针对以上问题进行测试。

软件度量包括3个维度，即项目度量、产品度量和过程度量。
（1）项目度量
是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等，辅助项目管理进行项目控制。
（2）软件产品度量
用于对软件产品进行评价，并在此基础之上推进产品设计、产品制造和产品服务优化。软件产品的度量实质上是软件质量的度量，而软件的质量度量与其质量的周期密切相关。
（3）过程度量
是对软件开发过程的各个方面进行度量，目的在于预测过程的未来性能，减少过程结果的偏差，对软件过程的行为进行目标管理，为过程控制、过程评价持续改善提供定量性基础。

软件工程管理集成了过程管理和项目管理，包括以下6个方面：
（1）启动和范围定义
进行启动软件工程项目的活动并作出决定。通过各种方法来有效
地确定软件需求，并从不同的角度评估项目的可行性。一旦可行性建
立后，余下的任务就是需求验证和变更流程的规范说明。
（2）软件项目计划
从管理的角度，进行为成功的软件工程做准备而要采取的活动。
使用迭代方式制订计划。要点在于评价并确定适当的软件生命周期过
程，并完成相关的工作。
（3）软件项目实施
软件工程过程中发生的各种软件工程管理活动。实施项目计划，
最重要的是遵循计划，并完成相关的工作。
（4）评审和评价
进行确认软件是否得到满足的验证活动。
（5）关闭
进行软件工程项目完成后的活动。在这一阶段，重新审查项目成
功的准则。一旦关闭成立，则进行归档、事后分析和过程改进活动。
（6）软件工程度量
在软件工程组织中有效地开发和实现度量的程序。

归纳

我的软件我的梦，是迷茫的。
软件基础主要还是描述高级语言，比图图，建模，关系； 而共有的生命周期、需求、审计、测试、运维、变更、状态机、计划、网络、过程改进。