软件工程相关

1.软件过程模型(重要)

1.1.瀑布模型

  1. 只适合需求明确的项目
  2. 严格串行化,很长时间才能看到结果。
  3. 严格区分阶段,每个阶段因果紧密相连,且要求每个阶段一次性解决该阶段的任务

1.2.原型模型(构造简易模型确定需求)

  1. 适合需求不明确的项目
  2. 分为原型开发阶段和目标软件开发阶段
  3. 原型开发阶段分为:需求分析,软件设计,程序设计

1.3.螺旋模型(原型+瀑布+风险分析)

  1. 增加了风险分析
  2. 把开发过程分为多个阶段,每个阶段都有评审+目标设定+风险分析+开发与有效性验证构成

1.4.统一过程

1.4.1.阶段

  1. 初始:确定系统范围,定义产品视图和业务模型
  2. 细化:设计系统架构,确定工作计划及资源需求
  3. 构造:开发剩余构件,并集成成产品测试
  4. 移交:制作产品发布版本

1.4.2.九个核心工作流

  1. 过程:业务建模,需求,分析与设计,实现,测试,部署
  2. 支持:配置与变更管理,项目管理,环境

1.4.3.核心

  1. 用例驱动
  2. 架构为中心
  3. 迭代和增量

1.5.敏捷方法(适合小型项目)

1.5.1.特点

  1. 增量迭代,小步快跑
  2. 适应性的而非预设性
  3. 以人为本
  4. 适合小型项目
  5. 价值观:沟通(面对面),简单(不过度设计),反馈,勇气

1.5.2.敏捷方法

  1. 极限编程XP:近螺旋开发方法。价值观(交流,朴素,反馈,勇气)
  2. 水晶方法:提倡机动性
  3. scrum:侧重于项目管理
  4. 特征驱动开发(FDD):开发三要素(人,过程,技术)。六种关键项目角色(项目经理,首席架构师,开发经理,主程序员,程序员,领域专家)
  5. 开放式源码:开发人员地域上分布广,不会集中办公

1.6.构建组装模型(易复用)

1.6.1.优缺点

  1. 优点:易扩展,易重用,降低成本,安排任务更灵活
  2. 缺点:构件设计需要经验丰富架构师,第三方构件质量难控制
  3. 服务是一种标准化程度更高的构件

1.6.2.基于构件的软件工程CBSE(购买而不是重新构造)

1.6.2.1.特征
  1. 可组装:所有外部交互通过公开接口进行
  2. 可部署:构件是二进制形式,作为一个独立实体在平台运行
  3. 文档化:用户根据文档判断是否满足需求
  4. 独立性:在无其他构件情况下组装
  5. 标准化:符合某种标准化的构件模型
1.6.2.2.模型要素
  1. 接口:构件通过构件接口来定义(操作名/参数/异常)
  2. 使用信息:构件元数据是构件本身相关的数据。构件是通用实体,在部署的时候,必须对构件进行配置适应系统
  3. 部署:有关包中内容信息+二进制构成信息
1.6.2.3.组装(借助胶水代码)
  1. 顺序组装:按顺序调用已经存在的构件
  2. 层次组装:A调用B,B调用C,一条调用链.接口兼容
  3. 叠加组装:多个构件形成新构件,对外提供新接口
1.6.2.4.组装出现不兼容
  1. 参数不兼容:操作名相同,但是参数个数或者类型不同
  2. 操作不兼容:操作名不同
  3. 操作不完备:提供接口是所需的子集,或者相反

1.7.V模型

  1. 测试贯穿始终,而不是像瀑布模型最后再有,避免最后出问题再整体改
  2. 从需求分析起,每个阶段都有对应的测试

2.逆向工程(设计的恢复过程)

  1. 实现级:抽象语法树,符号表,过程
  2. 结构级:程序分量之间的依赖关系,调用图,结构图,数据结构
  3. 功能级:程序段功能及程序段之间关系,数据和控制流模型
  4. 领域级:应用领域概念间关系。实体关系模型

3.净室软件工程(理想化软件开发)

3.1.概念

  1. 强调以合理的成本开发高质量软件
  2. 函数理论和抽样理论为其理论基础
  3. 不需要单元测试(保留传统的模块测试),进行正确性验证和统计质量控制

3.2.技术手段

  1. 控制迭代:统计过程控制下增量式开发
  2. 基于函数的规范和设计:行为视图(黑盒)- 有限状态机视图(状态盒)-过程视图(明盒)
  3. 正确性验证:净室工程的核心,使软件质量有了极大的提高
  4. 统计测试和软件验证:抽样

3.3.缺点

  1. 太理论化,正确性验证步骤比较难且耗时
  2. 不进行传统模块测试不现实
  3. 带有传统软件工程的弊端

4.需求工程

4.1.概念

  1. 需求开发+需求管理构成
  2. 需求开发:需求获取+需求分析+形成需求规格(SRS)+需求确认与验证(形成需求基线)
  3. 需求管理是对需求基线机型管理,包括变更控制,版本控制,需求跟踪,需求状态跟踪

4.2.需求获取

4.2.1.获取方法

  1. 用户面谈:1对1或3,有代表性用户,成本高,需要有领域知识支撑
  2. 需求专题讨论会(JRP):高度组织的群体会议,了解想法,消除分歧,成本高,
  3. 问卷调查:用户多,无法一一访谈,成本低
  4. 原型:解决早期需求不确定问题
  5. 头脑风暴:发散思维

4.2.2.需求分层

  1. 业务需求(整体全局)
  2. 用户需求(用户视角)
  3. 功能需求(计算机化):功能需求+性能需求+设计约束

4.2.3.项目管理维度(QFD)

  1. 基本需求(明示)
  2. 期望需求(隐含)
  3. 兴奋需求(多余)

4.3.需求分析

4.2.1.组成(数据字典是核心)

  1. 行为模型:状态转换图(状态+事件)
  2. 功能模型:数据流图(DFD):数据流+加工+数据存储+外部实体
  3. 数据模型:ER图(实体+联系)
  4. 数据字典:数据元素+数据结构+数据流+数据存储+加工逻辑+外部实体

4.2.2.ER图

  1. m:n

4.2.3.UML

  1. 静态图:类图,对象图,构件图,部署图(软硬件映射)
  2. 动态图:用例图(系统与外部参与者互动),顺序图(按时间顺序),通信图(协作图),活动图(并行行为),状态图(状态变迁)

4.3.需求定义(形成需求规格)

4.3.1.严格定义法

  1. 所有需求能够被预先定义
  2. 开发人员与用户之间能够准确而清晰的交流
  3. 图形/文字可以充分体现最终系统

4.3.2.原型法

  1. 并非所有需求都能在开发前被定义
  2. 项目参与者之间通常存在交流困难
  3. 需要实际可供用户参与的系统模型

4.4.需求变更管理过程

  1. 需求变更管理过程:问题分析和变更描述(识别出问题)- 变更分析和成本计算 - 变更实现
  2. 需求变更控制流程十大步骤:明确问题-书面申请-判断变更需求类别-评估变更影响-判断变更紧急级别-沟通确认-明确解决方案-审批管理(变更控制委员会)-执行变更-版本控制

5.系统设计

5.1.界面设计

  1. 置于用户控制之下
  2. 减少用户记忆负担
  3. 保持界面一致性

5.2.结构化设计

5.2.1.分类

  1. 概要设计(外部设计):确定每个模块的功能和调用关系,形成模块结构图
  2. 详细设计(内部设计):为每个具体任务选择适当的技术手段和处理方法

5.2.2.结构化设计原则

  1. 模块独立性原则(高内聚,低耦合)
  2. 保持模块大小适中
  3. 多扇入,少扇出
  4. 深度和宽度不宜过高

5.2.3.耦合(低-高)

  1. 非直接耦合
  2. 数据耦合(简单数据传递)
  3. 标记耦合(数据结构传递)
  4. 控制耦合(控制模块内部逻辑信息传递)
  5. 外部耦合:全局简单变量
  6. 公共耦合:公共数据环境
  7. 内容耦合:代码重叠

5.2.4.内聚(高-低)

  1. 功能内聚:完成单一功能,各部分协同工作
  2. 顺序内聚:必须顺序执行
  3. 通信内聚:处理元素集中在一个数据结构区域上
  4. 过程内聚:处理元素相关,必须按特定次序执行
  5. 时间内聚:必须同一时间间隔执行
  6. 逻辑内聚:逻辑上相关的任务
  7. 偶然内聚:没啥关系

5.2.5.面向对象设计原则

  1. 输入和输出
  2. 处理功能
  3. 内部数据
  4. 程序代码

5.2.6.类的分类

  1. 边界类(API接口、用户界面)
  2. 控制类(应用逻辑,业务逻辑,数据访问逻辑)
  3. 实体类(数据ER图)

5.2.7.面向对象设计原则

  1. 单一职责:目的单一的类
  2. 开放-封闭原则:扩展开放,修改封闭
  3. 李氏替换:子类可以替换父类
  4. 依赖倒置:针对接口编程而不是具体实现
  5. 接口隔离原则:多个专门接口比单一综合接口好
  6. 组合重用原则:尽量使用组合,而不是继承关系
  7. 迪米特原则:一个对象对其他对象尽可能了解少

6.软件测试

6.1.软件测试方法

  1. 动态测试:白盒测试(关注内部结构与逻辑),黑盒测试(关注输入输出)
  2. 静态测试:桌前检查,代码审查(静态分析),代码走查

6.2.动态测试

6.2.1.白盒测试(结构测试,单元测试阶段)

  1. 控制流测试:逻辑覆盖测试(语句覆盖最弱-路径测试覆盖最强)
  2. 程序变异测试(错误驱动)

6.2.2.黑盒测试(功能测试,集成,确认,系统测试阶段)

  1. 等价类划分
  2. 边界值分析
  3. 错误推测:测试人员的经验和直觉
  4. 判定表:多个逻辑条件取值的组合所构成的复杂情况下,分别要执行哪些不同操作
  5. 因果图:根据输入条件与输出结果之间的因果关系来设计测试用例

6.3.软件测试阶段

6.3.1.阶段

  1. 单元测试:依据详细设计,模块内
  2. 集成测试:依据概要设计,模块间
  3. 系统测试:依据需求文档,功能测试,性能测试,验收测试(确认测试,依据需求文档,用户参与),压力测试

6.3.2.其他测试

  1. AB测试:多版本同时使用(网页优化方法)
  2. Web测试:web系统测试与其他测试测试重点不同
  3. 链接测试:确实链接到该链接的页面,测试链接页面是否存在,确定没有鼓励页面
  4. 表单测试:验证服务器是否正确保存数据,测试提交操作的完整性

6.3.3.集成测试策略

  1. 一次性组装(风险高)
  2. 增量式组装(测试全面):自顶向下(桩模块mock),自底向上(驱动模块),混合式(都需要)

6.3.4.软件系统测试

  1. 功能测试
  2. 性能测试:负载测试,压力测试(测上限),强度测试(测下限),容量测试(并发测试)。可靠性测试
相关推荐
人才程序员1 天前
QML z轴(z-order)前后层级
c语言·前端·c++·qt·软件工程·用户界面·界面
Theodore_10221 天前
3 需求分析
java·开发语言·算法·java-ee·软件工程·需求分析·需求
做人求其滴2 天前
GDPU软件工程习题(挖空版)
软件工程
MrFlySand_飞沙2 天前
软件工程
软件工程
jokr_2 天前
【软件工程复习】
软件工程
云空2 天前
《软件工程文档攻略:解锁软件开发的“秘籍”》
软件工程
人才程序员2 天前
【无标题】
c语言·前端·c++·qt·软件工程·qml·界面
Aderversa2 天前
关于数据流图绘制和使用上的一些个人经验
软件工程
梁辰兴3 天前
UML 建模实验
软件工程·uml·建模
shinelord明4 天前
【再谈设计模式】外观模式~复杂系统交互的简化大师
开发语言·数据结构·设计模式·软件工程