电子科大860软工

SW定义
软件 = 程序（按事先设计的 功能 性能 执行的指令序列）、数据（合理的数据结构）、文档（与程序开发、维护、使用有关的图文材料）
软件的特征：1、是工程化的，不是制造的 2、是简单的拷贝 3、会多次修改 4、开发环境影响大5、开发进度不好评估 6、测试困难 7、不会磨损和老化 8、维护会产生新的问题
软件的双重作用（身份）：1、是一种产品 2、是开发其他产品的工具
软件的分类：系统、支撑、应用（软件）

SW危机
定义：在计算机软件 开发 和 维护 时遇到的一系列严重的问题
ex:超预算、超时间、效率低、质量差、不符合需求、难维护、无法交付
原因：1、客观：是复杂逻辑部件、软件的规模庞大
2、主观不正确的开发方法：忽视需求分析，认为软件开发 = 程序编写，忽视软件维护

为了消除软件危机，所以出现了： 软件工程

SW工程：
定义：1、运用系统化、科学化、定量的手段，来开发、运营、维护软件，即将工程应用到软件
2、对1中各方法的研究
目标：在给定的时间内，按需求开发出（易修改、高效、可靠、可维护、可重用等）的软件

SW三要素：工具、过程、方法

工具：为后两者提供自动或全自动的工具
过程：在各环节之间建立里程碑
方法：完成项目的技术手段
sw发展四个阶段：传统、搞对象、过程、够贱

生命周期：软件产品或系统从设计，分析，编码到投入使用最终淘汰的全过程

sw过程：软件过程定义了软件生产的一系列活动，这些活动贯穿于 软件生成 的整个过程
1、问题定义 2、技术开发 3、方案集成 4目标现状
三个流派：CMU-SEI的CMM-能力成熟度模型
ISO9000的质量标准体系
ISO/IEC 15504 信息技术软件过程评估

SW过程模型：
是SW开发的全部过程，活动和任务的结构框架，包括（软件开发模型、软件生存周期模型、软件工程泛型）

瀑布模型：本模型与软件生命周期一致，称为软件生命周期模型。规定了自上而下，相互衔接得次序，是一种使用广泛，以文档为驱动的模型
特点：1、各个阶段具有顺序性、依赖性。2、推迟实现的观点。3、每个阶段都要完成规定的文档，需要在阶段结束前完成文档的审查工作，以便提早发现问题
缺点：1、线性过程太理想化2、大量文档增加工作量 3、用户要等完整个过程才能看到成果 4、早期的错误要在最后阶段才发现
（适用于军工、医疗）

增量：
1)增量过程模型：非整体开发的模型，是进化式的进程。从部分需求出发，先建立一个不完善的系统，通过测试和反馈，对系统扩充和完善，直到用户满意
采用基于时间的线性序列（纵向），每个线性序列都会输出一个增量

每个增量可以采用瀑布模型（横向）
优点：1、由于增量开发，所以不用提供完整需求，有增量包出现，开发就可以继续 2、初期不用太大人力 3、有效管理技术风险
缺点：难以给出大小合适的增量

2)快速应用开发RAD：是瀑布模型的高速变体，通过 基于组件的构建方法 快速开发，可以短时间建立一个“全功能系统”
缺点：1、项目大了，要人很多 2、开发者和用户都要在需求方面实现承诺，否则会失败 3、以下系统不适合：不能模块化的、性能需求高的，技术风险高的

演化模型：先实现最核心重要的功能

1. 原型模型（自外向内的模型）：客户说个大概，不知道具体输入输出，开发者也不知道具体算法啥的，所以先给出一个原型
   缺点：1、会在 质量和原型间折衷 2、客户意识不到一些质量问题
   2）螺旋模型：结合了瀑布模型和原型模型（实质上相当于在瀑布模型的每个阶段开始前引入风险分析），强调 风险管理

四个象限的活动：制定计划、风险分析、实施工程、客户评估
优点：1、支持用户需求动态变化 2、原型可看作是 形式的需求规格说明（便于双方理解） 3、螺旋强调可扩充和可修改，原型的进化会贯穿整个生命周期
缺点：1、迭代次数过多会使成本变高 2、需要高水平的风险经验和专业知识

适用于需求不明确的大型软件开发

喷泉模型：以用户需求为动力，以对象为驱动的面向对象的模型
优点：各阶段的顺序没有明显的标志，开发者可以同步进行开发
缺点：由于各阶段是重叠的，所以需要大量开发人员，也有大量开发文档，不利于管理，文档审核难度加大

基于构建的模型：

步骤：1、需求分析 2、组件分析（不能完全满足要求的组件要改动） 3、系统设计（考虑到组件的重用） 4、开发集成（集成组件）
优点：1、成本得到降低
缺点：1、需求被折中 2、无法完全控制系统的演化 3、项目划分的好坏会直接影响项目结果

需求分析：
为何进行需求分析：
1、需求分析的错误和变更导致软件开发的失败占软件失败因素的三分之一以上。缺少用户输入：13、不完整的需求和规格说明书：12、需求和规格说明书的变更：12
2、希望对开发进行指导
3、4、用户和开发人员相互理解
5、测试部门有理可依

需求分析可以分成两块：需求确认（需求获取、需求提炼、需求描述、需求验证）、需求变更（需求变更）
需求分析的定义：确定系统必须具有的功能和性能，系统要求的运行环境，以一种清晰、简洁、一致、无二意的方式对一个待开发系统中各个有意义方面的陈列的集合

需求分析俩任务：建立分析模型、编写需求说明

需求的类型：功能性需求（系统应该做什么、或为其他系统或用户提供的服务）、非功能性需求（必须遵守的标准、外部界面的细节、实现的约束条件）
小测试：

需求提炼
采用多种形式描述需求、与客户澄清易混淆的问题，明确哪些需求是更为重要的
需求分析的模型分为：1、结构化分析模型（用系统工程的思想与工程化的方法、自顶向下、结构化、模块化地对系统进行分析与设计）2、面向对象分析模型
1、结构化分析模型：面向 数据流 进行需求分析的方法，适用于数据处理类软件的需求分析、换言之：运用抽象模型的概念，按照软件内部数据传递、数据变化、自顶向下的分解，找到满足功能要求的所有可实现软件。
2、面向对象分析模型：UML（统一了面向对象建模的基本概念、属于、图形符号）
用例图：参与者（系统以外的需要使用系统的人、系统、设备）、关联、用例（与参与者交互的动作序列的说明，对参与者使用用例的描述、是系统提供的外部可感知功能单元，只定义系统的行为）
用例图中的关系：关联、泛化、包含、扩展

需求建模的工具：

需求规格说明书：是对待开发系统的一个完整的描述，其中包含了 功能性描述 和 非功能性描述
需求分析工作完成的一个标志是：形成一份完整的、规范的需求规格说明书
作用：使用户和开发者双方对需求有一个共同的理解

需求验证的重要性：是十分重要的，若在后期开发或使用时才发现需求文档的不足，代价很高

对需求文档需要进行以下的检查：1、有效性检查（检查不同用户使用不同功能的有效性） 2、一致性检查（需求之间不应该冲突） 3、完备性检查（需求文档应包含所有的功能和约束） 4、可行性检查（保证现有技术可以实现）

下面介绍数据流图：

画分层DFD的原则：
父子图平衡
局部数据存储

下面介绍用例图

用例的几种关系：

将一些常规的动作放在一个基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中

举个例子：

需要记住

设计工程

设计的定义：软件或组织的 架构、构建、接口和其他特性 的定义过程以及过程的结果

是软件生命周期中的一个活动、是软件编码的基础、将软件需求分析转化为内部结构、是连接用户需求和软件技术的桥梁
好的设计：1、满足分析模型中的明确要求、用户的隐含要求 2、对编码、测试、维护人员是可理解的 3、提供软件的完整视图，从实现的角度解决数据、功能、行为等各个问题

软件设计分为：软件架构设计、软件详细设计
软件架构（概要）设计：描述软件的顶层设计和组织，划分不同的组件
软件详细设计：详细描述各组件来实现编码
注：软件设计主要为：D-design分解设计、FP-design系列模式设计

设计的过程与质量：
1、设计必须包含分析模型中包含的所有要求以及隐含要求
2、设计必须方便测试、编码人员的理解
3、设计需提供软件完整视图，从实现的角度解决 数据、行为、功能模型的问题

设计的相关概念：

抽：忽略具体信息，将不同事务看作相同事务
机制：参数化、规范化（数据抽象、过程抽象：具有明确和有限序列的指令序列）

体：软件的整体结构 和 这种结构为系统提供概念上完整的方式
体系结构可使用的模型：结构、框架、动态、过程、功能（模型）

射：在给定上下文环境中，一类共同问题的共同解决方式
可分为：实体、结构、行为（模式）
共23个模式

模：软件被划分为命名和功能独立的多个组件，通过这些组件的集成来满足需求

模块的设计标准：

性：定义和设计时，应保证内部信息不被不需要的模块访问
功：每个模块只负责特定的子功能，且从数据结构上来看，具有简单的接口

衡量标准：内聚性（模块的相对强度）、耦合性（模块间的相互依赖程度）
独立性强 = 高内聚低耦合

精：抽象确定过程和数据，精化确定底层的细节

重：不改变组件功能和行为的条件下，简化组件
包括：未使用的元素、较差的算法、不好的构建方式，不恰当的数据结构

界面设计的原则：1、允许用户操作控制 2、减少用户记忆负担 3、保持界面一致

1.3数据设计：
？
也称为构建高级抽象的数据模型
？
2.1面向过程的总体设计
结构化的总体设计方法：1、先研究、分析数据流图，从需求规格说明书中弄清楚数据流的加工 2、根据数据流图确定问题的类型，是变换流还是事务流。 3、由数据流图推导出系统初始结构图 4、改进初始结构图 5、修改补充数据字典

变换流，变换形处理数据步骤：获得数据、变换数据、给出数据

事务流，事务形处理数据：根据事务处理的特点和性质，选择分配给一个适当的处理单元
大型的项目一般采用变换形和事务形的混合

2.2 面向过程的组件设计
详细设计的工具、
流程图：

顺序结构、选择结构、循环结构

盒图：

PAD图（问题分析图）
决策表
顺序图（时序图）：

pdl

-------------------------------------------------------------------------------------------------------对象-------------------------

面向对象的设计强调定义 软件的对象 ，且这些对象相互协作来满足用户的需求
面向对象的分析和设计的界限是模糊的，从分析到对象设计是一个逐渐扩充模型的过程，分析结果经过细化可以直接生成设计结果，在设计中加强对分析的理解，从而进一步改善分析结果
分析和设计活动是一个反复迭代的过程
面向对象方法在概念和表示上的一致性，使得各个阶段很平滑

设计高质量的原则：
对接口进行设计、发现变化并封装他、先考虑聚合然后考虑继承

类内聚：一个类的属性应全部都是完成这个任务所必须的，其他所有无用的功能都应该被清除掉
弱耦合：若一个类的功能大量依赖于另一个类，则可理解性下降，还会增加测试、维护的难度

耦合方式：交互耦合（对象之间的耦合是通过发送消息来连接的）、继承耦合（一般类与特殊类之间的一种关系）

测试技术
软件质量：明确表示了是否符合 功能 和 性能 要求，明确记载开发标准、开发软件的期望的隐性特点
质量保证（sqa）：检测、评估一个工程的各个方面，最大限度提高一个工程的最低质量标准
测试的定义：1、在指定条件下，对系统或组件操作，观察或记录结果，对系统和组件的某些方面进行评估的过程。2、分析各项目，检测现有结果和应有结果之间的差异，并评估软件个项目的特征的过程。
软件缺陷：1、未实现产品说明书要求的功能 2、出现了产品说明书指明了不能出现的错误 3、实现了产品说明书未提到的功能 4、未实现未提到但应该实现的功能 5、软件不好用，运行慢

测试人员：尽早找出软件缺陷，确保缺陷被修复了
质量保证人员：创建和改进软件开发过程，并防止软件缺陷的发生

测试的基本原则：

测试用例：是测试输入，执行条件，预期结果的集合

主要的测试方法：白盒（考虑内部结构）、黑盒（功能测试）、灰盒

白盒：

注意：条件和分支是有区别的，分支是条件两头的路，条件是判断内部的条件

控制流图覆盖：将代码转变为控制流图CFG，并基于其进行测试的技术（属于白盒测试）

节点覆盖：对于图中语法可到达的节点，测试用例的测试路径至少存在一条可以到达改节点。（节点覆盖 = 语句覆盖）
边覆盖：对于可到达长度小于等于1的路径，测试用例所执行的路径至少有一条经历改路径（边覆盖包含节点覆盖）
基本路径测试：将覆盖的路径压缩到一定的限度内，使程序中的循环体只执行一次

黑盒测试特点：黑盒测试是不可能穷尽的！
等价划分类：1、完全不考虑内部结构，依照规格说明来设计用例 2、把所有可能的输入值分成若干份（划分等价类），从每一部分选择有代表性的 （选择测试用例）
每个等价类中的用例对于揭露程序中的错误都是等效的
等价类又分为 有效 和 无效

边界值分析：略

状态测试
软件状态通常是指软件所处的 条件 或者 模式

静态分析方法：不实际运行程序，主要通过检查和阅读代码等
作用：1、通过对代码的质量监控提高代码的可靠性
2、尽早通过对源代码的检查发现缺陷
3、对易产生错误的模块代码审核
挺有效的

测试的策略：
V模型：

单元测试：模块接口、局部数据结构、边界条件、独立路径、出错处理
条件：了解即可

集成测试又称为：子系统测试，组装测试，部件测试
集成测试又分为三种方法：自顶向下、自底向上、SMOKE

系统测试：6个
功能测试、性能测试（检擦系统是否满足规格说明书中的内容）、压力测试（在系统不发生故障的情况下，系统可以运行的极限）、恢复测试（系统发生故障恢复后是否正常运行（停电等））、安全性测试（检验在系统中已经存在的系统的安全性）、验收测试（用户为主，使用真实数据来设计测试用例）

a测试：用户在开发环境下去测试，模拟真实的使用

b测试：多名用户在实际使用的环境下测试，若有错误返还给开发者

测试何时结束

回归测试要背：

SW维护：
定义：由于软件出现问题或需要修改而对代码及相关文档进行修改，目的是对现有代码、文档修改的同时保持其完整性。
维护的类型：纠错、适应、完善、预防

维护过程模型：

软件再工程：
对现有软件进行审查和改造，对其重新构造，使之成为一种新的形式，包括对新形式的实现

软件逆向工程：1、分析目标系统，识别系统的构建及其交互关系，通过高层抽象或其他形式来展现目标系统的过程
2、需要考虑抽象的层次、完备性、工具与分析人员协同工作的程度、过程的方向性

项目管理
定义：计划、协调、度量、监控、控制、报告等 管理 在软件开发和维护中的具体应用、保证开发过程是系统的、有原则的、可量化的
四大要素：人员、产品（策划一个项目以前，应该建立产品的目标和范围，技术和管理应该被约束）、过程（软件开发的全面计划）、项目（理解成功项目的关键因素、掌握项目计划、监控和控制的一般方法）
软件度量的定义：一种量化衡量方法，使人们可以理解把我软件项目的生产小笼包或所需的劳动量

间接度量-功能点度量
功能点数从直接度量软件信息域和评估软件复杂性的经验量化关系中获得
先算未调整功能点总计数UFC
再计算功能点FP

cocomo示例

下例会了

程序设计小组的组织形式：
1、主程序员制小组 2、民制小组 3、层次式小组