文章目录
软件工程
-
软件工程：是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。
-
软件的生命周期：软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程。
-
软件过程模型/软件生命周期模型：为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束.
-
瀑布模型 (Waterfall Model) :因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。
-
原型模型 (Prototype Model) 又称快速原型：借鉴建筑师、工程师建造原型的经验，提出了原型模型。
-
原型模型主要有以下两个阶段：
- 原型开发阶段：软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。
- 目标软件开发阶段：在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统。
-
螺旋模型 (Spiral Model)：在快速原型的基础上扩展而成。也有人把螺旋模型归到快速原型，实际上，它是生命周期模型与原型模型的结合。都由4部分组成：
- 目标设定。
- 风险分析。
- 开发和有效性验证。
- 评审。
-
敏捷型方法："适应性" (adaptive) 而非"预设性" (predictive) 的。重型方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制订完成后拒绝变化，而敏捷型方法欢迎变化。
-
软件统一过程 (Rational Unified Process,RUP) 是 Rational软件公司创造的软件工程方法。RUP软件开发生命周期: 业务建模 (Business Modeling)、需求 (Requirements)、分析与设计 (Analysis & Dcsign)、实现 (Implementation)、测试 (Test)、部署 (Deployment)、配置与变更管理 (Configuration & Change Management)、项目管理 (Project Management)、环境 (Environment)
- RUP 的特点：RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程
- RUP采用"4+1"视图模型来描述软件系统的体系结构。
-
软件能力成熟度模型 (Capability Maturity Model for Software,CMM) 是一个概念模型，模型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。CMMI(Capability Maturity Model Integration for Software, 软件能力成熟度模型集成)是在 CMM 的基础上发展而来的。
- 1)Level 1 初始级：处于成熟度级别1级时，过程通常是随意且混乱的。这些组织的成功依赖于组织内人员的能力与英雄主义。成熟度1级的组织也常常能产出能用的产品与服务，但它们经常超出在计划中记录的预算与成本。
- 2)Level2已管理级：在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。
- 3)Level3已定义级：在这一等级，企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化，同时企业开始进行项目积累，企业资产的收集。
- 4)Level 4量化管理级： 在成熟度4级，组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别3级与4级的关键区别在于对过程性能的可预测。
- 5)Level 5优化级：在优化级水平上，企业的项目管理达到了最高的境界。成熟度级别5级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。处于成熟度5级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注。
需求工程
-
软件需求的内容：
- 用户解决问题或达到目标所需条件或权能 (Capability)。
- 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能
- 一种反映上面(1)或(2)所述条件或权能的文档说明:包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求、质量标准或者设计限制。
-
软件需求包括3个不同的层次：业务需求、用户需求和功能需求(也包括非功能需求):
- 业务需求 (business requirement) 反映了组织机构或客户对系统、产品高层次的目标要求
- 用户需求 (user requirement) 描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两种构成了用户原始需求文档的内容。
- 功能需求 (functional requirement) 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求.
-
需求工程的活动主要被划分为以下几个阶段
- (1)需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
- (2)需求分析：为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
- (3)形成需求规格(或称之为需求文档化):按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述规约作为后续软件系统开发的指南。
- (4)需求确认与验证：以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
- (5)需求管理：包括需求文档的追踪管理、变更控制、版本控制等管理性活动。
-
需求获取的基本步骤
- 1)开发高层的业务模型
- 2)定义项目范围和高层需求
- 3)识别用户角色和用户代表
- 4)获取具体的需求
- 5)确定目标系统的业务工作流
- 6)需求整理与总结
-
需求获取方法: 1)用户面谈 2)需求专题讨论会 3)问卷调查 4)现场观察 5)原型化方法 6)头脑风暴法
-
软件需求文档应该精确描述要交付的产品，这是一个基本的原则。为了使开发组织能够严格控制软件项目，应该确保以下事项：
● 仔细评估已建议的变更。
● 挑选合适的人选对变更做出判定。
● 变更应及时通知所有相关人员。
● 项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。
-
变更控制过程 :
- (1)问题分析和变更描述
- (2)变更分析和成本计算
- (3)变更实现 :变更控制过程并不是给变更设置障碍。相反地，它是一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更产生的负面影响降到最低。
- 常见的需求变更策略：
(1)所有需求变更必须遵循变更控制过程。
(2)对于未获得批准的变更，不应该做设计和实现工作。
(3)变更应该由项目变更控制委员会决定实现哪些变更。
(4)项目风险承担者应该能够了解变更的内容。
(5)绝不能从项目配置库中删除或者修改变更请求的原始文档。
(6)每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。
-
变更控制委员会 :变更控制委员会 (Change Control Board,CCB) 是项目所有者权益代表，负责裁定接受哪些变更。变更控制委员会可能包括如下方面的代表：(1)产品或计划管理部门。(2)项目管理部门。(3)开发部门。(4)测试或质量保证部门。(5)市场部或客户代表。(6)制作用户文档的部门。(7)技术支持部门。(8)帮助桌面或用户支持热线部门。(9)配置管理部门。
-
变更控制委员会 应该有一个总则，用于描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤。
- 制定决策 ，制定决策过程的描述应确认：
● 变更控制委员会必须到会的人数或做出有效决定必须出席的人数。
● 决策的方法(例如投票，一致通过或其他机制)。
● 变更控制委员会主席是否可以否决该集体的决定。 - 交流情况：一旦变更控制委员会做出决策，指派的人员应及时更新请求的状态。
- 重新协商约定：当项目接受了重要的需求变更时，为了适应变更情况要与管理部门和客户重新协商约定。协商的内容可能包括推迟交货时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行折中。
- 制定决策 ，制定决策过程的描述应确认：
-
需求跟踪: 包括编制每个需求同系统元素之间的联系文档，这些元素包括其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等，是要在整个项目的工件之间形成水平可追踪性。需求跟踪有两种方式 ：(1)正向跟踪 。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。(2)逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
系统分析与设计
-
系统分析阶段是应用系统思想和方法，把复杂的对象分解为简单的组成部分，找出这些部分的基本属性和彼此之间的关系的过程，其基本任务是系统分析师和用户在充分了解用户需求的基础上，把双方对新系统的理解表达为系统需求规格说明书
-
结构化分析 的步骤如下：
(1)分析业务情况，做出反映当前物理模型的数据流图 (Data Flow Diagram,DFD);
(2)推导出等价的逻辑模型的 DFD;
(3)设计新的逻辑系统，生成数据字典和基元描述；
(4)建立人机接口，提出可供选择的目标系统物理模型的 DFD;
(5)确定各种方案的成本和风险等级，据此对各种方案进行分析；
(6)选择一种方案；
(7)建立完整的需求规约。
-
结构化分析的常用手段 是：数据流图 (DFD) 和数据字典
-
数据流图DFD 方法由4种基本元素(模型对象)组成：数据流、处理/加工、数据存储和外部项。
-
数据字典 (Data Dictionary) 是一种用户可以访问的记录数据库和应用程序元数据的目录。
-
结构化设计(Structured Design,SD)：是一种面向数据流的设计方法，它以SRS和 SA阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构。分为概要设计和详细设计两个阶段。
-
概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系
-
详细设计的主要任务是为每个模块设计实现的细节。
-
在SD方法中，模块是实现功能的基本单位，它一般具有功能、逻辑和状态3个基本属性，其中功能是指该模块"做什么",逻辑是描述模块内部"怎么做",状态是该模块使用时的环境和条件
-
信息隐藏原则要求采用封装技术，将程序模块的实现细节(过程或数据)隐藏起来，对于不需要这些信息的其他模块来说是不能访问的，使模块接口尽量简单。
-
抽象原则要求抽取事物最基本的特性和行为，忽略非本质的细节，采用分层次抽象的方式可以控制软件开发过程的复杂性，有利于软件的可理解性和开发过程的管理。
-
模块化: 在 S D方法中，模块是实现功能的基本单位，它一般具有功能、逻辑和状态3个基本属性，其中功能是指该模块"做什么",逻辑是描述模块内部"怎么做",状态是该模块使用时的环境和条件。
-
耦合表示模块之间联系的程度：
-
内聚表示模块内部各代码成分之间联系的紧密程度，是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做目标单一的一件事情。
-
系统结构图 (Structure Chart,SC) 又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构
-
详细设计的主要任务是设计每个模块的实现算法、所需的局部数据结构 。
(1)分析并确定输入/输出数据的逻辑结构。
(2)找出输入数据结构和输出数据结构中有对应关系的数据单元。
(3)按一定的规则由输入、输出的数据结构导出程序结构。
(4)列出基本操作与条件，并把它们分配到程序结构图的适当位置。
(5)用伪码写出程序。
详细设计的表示工具有图形工具、表格工具和语言工具。
-
结构化程序设计的原则可表示为：程序=(算法)+(数据结构)。
-
数据库设计是指根据用户的需求，在某一具体的数据库管理系统上，设计数据库的结构和建立数据库的过程。
-
概念结构设计是对用户要求描述的现实世界(可能是一个工厂、商场、学校或企业等),通过对其中实体事物的分类、聚集和概括，建立抽象的概念数据模型。
-
E-R图提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。
面向对象方法
- 面向对象 (Object-Oriented,OO) 开发方法将面向对象的思想应用于软件开发过程中，指导开发活动，是建立在"对象"概念基础上的方法学
- 面向对象的分析方法 (Object-Oriented Analysis,OOA), 是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。
- 面向对象设计方法 (Object-Oriented Design,OOD) 是 OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。
- 实体类映射需求中的每个实体，是指实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。
- 控制类是用于控制用例工作的类，一般是由动宾结构的短语("动词+名词"或"名词+动词")转化来的名词，例如，用例"身份验证"可以对应于一个控制类"身份验证器",它提供了与身份验证相关的所有操作。
- 边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。
- 面向对象程序设计 (Object Oriented Programming,OOP) 是一种计算机编程架构。OOP 的基本特点有封装、继承和多态。
软件测试
- 软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
- 软件测试方法 的分类有很多种，以测试过程中程序执行状态 为依据可分为静态测试 (StaticTesting,ST) 和动态测试 (Dynamic Testing,DT) ; 以具体实现算法细节和系统内部结构的相关情况为根据可分黑盒测试 、白盒测试 和 灰盒测试 3类；从程序执行的方式来分类，可分为人工测试 (Manual Testing,MT) 和自动化测试 (Automatic Testing,AT)。
- (1)静态测试 。静态测试是被测程序不运行 ，只依靠分析或检查 源程序的语句、结构、过 程等来检查程序是否有错误。即通过对软件的需求规格说明书、设计说明书以及源程序做结构 分析和流程图分析，从而来找出错误。例如不匹配的参数，未定义的变量等。
- (2)动态测试 。动态测试与静态测试相对应，是通过运行被测试程序 ，对得到的运行结果 与预期的结果进行比较分析，同时分析运行效率和健壮性能等。这种方法可简单分为3个步骤： 构造测试实例、执行程序以及分析结果。
- (3)黑盒测试 。黑盒测试将被测程序看成是一个黑盒，工作人员在不考虑任何程序内部结构和特性的条件下 ，根据需求规格说明书设计测试实例，并检查程序的功能是否 能够按照规范说明准确无误的运行。其主要是对软件界面和软件功能进行测试。对于黑盒测试行为必须加以 量化才能够有效的保证软件的质量。
- (4)白盒测试 。白盒测试主要是借助程序内部的逻辑和相关信息 ，通过检测内部动作是否按照设计规格说明书的设定进行 ，检查每一条通路能否正常工作。白盒测试是从程序结构方面 出发对测试用例进行设计。主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正 常以及内部结构是否有效。常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等。根据测试用例的覆盖程度，分为语句覆盖、判定覆盖、分支覆盖和路径覆盖等。
- (5)灰盒测试 。灰盒测试介于黑盒与白盒测试之间。灰盒测试除了重视输出相对于输入的 正确性，也看重其内部的程序逻辑。但是，它不可能像白盒测试那样详细和完整。它只是简单 地靠一些象征性的现象或标志来判断其内部的运行情况，因此在内部结果出现错误，但输出结 果正确的情况下可以采取灰盒测试方法。因为在此情况下灰盒比白盒高效，比黑盒适用性广的 优势就凸显出来了。
- (6)自动化测试 。自动化测试就是软件测试的自动化，即在预先设定的条件下自动运行被测程序，并分析运行结果。总的来说，这种测试方法就是将以人驱动的测试行为转化为机器执 行的一种过程
- 软件测试 可以分为单元测试、集成测试和系统测试，系统测试中又包含了 多种不同的测试种类，例如功能测试、性能测试、验收测试、压力测试等。
净室软件工程
- 净室 (Cleaning Room) 软件工程 是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化 的软件过程达到开发中的零缺陷或接近零缺陷。
- 净室软件工程 (Cleanroom Software Engineering,CSE) 是一种在软件开发过程中强调在软件中建立正确性的需要的方法。
- 净室软件工程的理论基础 主要是函数理论 和抽样理论。
- 函数理论：一个函数定义了从定义域到值域的映射。
- 抽样理论：把软件的所有可能的使用情况看作总体，通过统计学手段对其进行抽样，并对样本进行测试，根据测试结果分析软件的性能和可靠性。
- 净室软件工程中应用的技术手段主要有以下4种：1.统计过程控制下的增量式开发 (Incremental Development )2.基于函数的规范与设计3.正确性验证4.统计测试 (Statistically Based Testing) 和软件认证
基于构建的软件工程
- 基于构件的软件工程 (Component-Based Software Engineering,CBSE) 是一种基于分布对
象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。基于构件的软件系统中的
构件可以是 COTS(Commercial-Off-The-Shelf) 构件，也可以是通过其他途径获得的构件(如
自行开发)。 - 用于CBSE 的构件应该具备以下特征：(1)可组装型(2)可部署性(3)文档化(4)独立性(5)标准化
- CBSE过程中的主要活动包括：(1)系统需求概览；(2)识别候选构件；(3)根据发现的构件修改需求；(4)体系结构设计；(5)构件定制与适配；(6)组装构件，创建系统。
软件项目管理
-
工作分解结构 (Work Breakdown Structure,WBS) 就是把一个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人 的日常活动中，直到分解不下去为止。即：项目→任务→工作→日常活动。
-
软件配置管理 (Software Configuration Management,SCM) 是一种标识、组织和控制修改 的技术。软件配置管理核心内容包括版本控制和变更控制。
- (1)版本控制 (Version Control)。 版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。
- (2)变更控制 (Change Control)。 变更控制的目的并不是控制变更的发生，而是对变更进
行管理，确保变更有序进行。
-
软件质量是 软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准以及所有专业开发的软件 都应具有的隐含特征的程度。
-
影响软件质量的因素 :产品运行、产品修改和产品转移
-
软件质量认证 ：质量认证用来检验整个企业的质量水平，注重软件企业的整体资质，全面考察软件企业的整体质量体系，检验该企业是否具有设计、开发和生产符合质量要求的软件的能力。目前国内软件企业主要采用的是ISO 9000 和能力成熟度模型 (Capability Maturity Model,CMM)。
-
软件项目风险管理 是软件项目管理的重要内容。在进行软件项目风险管理时，要辨识风险， 评估它们出现的概率及产生的影响，然后建立一个规划来管理风险。风险管理的主要目标是预防风险。风险管理活动 分成风险估计 (风险辨识、风险分析、风险排序)和风险控制(风险管理计划、风险处理、风险监督)两大阶段。