软件工程自我总结

软件过程

  1. 软件描述->软件开发->软件有效性验证->软件进化
  2. 基本要素：方法、工具、过程

正式技术评审的目标：发现软件中的错误

模块类型

  1. 传入：下属模块数据传给上级模块
  2. 传出：上级模块数据传给下属模块
  3. 变换：上级模块的数据转换形式后再传回给上级模块
  4. 协调：对所有下属模块协调和管理

注意区分上级模块和下属模块

成熟度

CMM 5个：

  1. 初始：制度缺乏，无序
  2. 可重复：基本管理制度，可跟踪，可重复同类项目
  3. 已定义：文档化、标准化、可按需改进
  4. 已管理：详细度量标准，有定量的理解和控制
  5. 优化：持续改进

CMMI 6个：（0-5）

　　0.未完成：未执行

　　1.已执行：可标识的输入输出，关注于过程域的特定目标

　　2.已管理：过程制度化，监控，控制，评审

　　3.已定义：关注过程的组织和部署

　　4.量化：定量管理

　　5.优化：优化，持续得到改进

软件过程模型

  1. 瀑布：
    1. 优点：易理解，管理成本低　　
    2. 缺点：必须需求明确，不适合大型软件，风控弱，已延期和超出预算
  2. 增量：瀑布+原型，优先满足核心需求及功能，再在基本需求上不断优化、完善及补充，确定性比原型高
  3. 演化：（迭代，需求缺乏准确认知）
    1. 原型：(规模不大，不太复杂）
      1. 快速构造部分需求
      2. 水平：导航，主要用在界面上
      3. 垂直：主要用在算法上
      4. 抛弃式：解决需求不确定、不完整
      5. 演化式：增量式，易于升级和优化，适合Web
    2. 螺旋：（规模庞大，复杂，高风险）
      1. 瀑布+演化
      2. 制定计划+风险分析+实施工程+客户评估
  4. 喷泉：
    1. 迭代+无间隙（无明显界限）
    2. 不利于项目管理和审核
  5. UP模型（统一过程）
    1. 用例和风险驱动，架构为中心
    2. 迭代+增量
    3. 4个阶段：
      1. 起始（初始）：建立模型，确定边界
      2. 精华（细化）：分析问题，建立完善的架构
      3. 构建：开发剩余
      4. 移交：确保可用
    4. 5个工作流：需求、分析、设计、实现、测试

敏捷方法

  1. 极限编程：
    1. 轻量、高效、低风险、柔性、可预测、科学
    2. 4大价值观+5个原则+12个最佳实践+行为
      1. 4大价值观：沟通、简单、反馈、勇气
      2. 5个原则：快速反馈、简单假设、逐步修改、提倡更改、优质工作
      3. 12个最佳实践：计划游戏、小型发布、隐喻、简单设计、重构、结队编程、集体代码所有制、持续集成、每周40小时、现场客户、编码标准
  2. 水晶法：不同项目不同策略、约定和方法论
  3. 并列争球法：迭代+冲刺
  4. 自适应软件开发：猜测+合作+学习
  5. 开放式：虚拟团队，开发不在同一处
  6. FDD驱动：开发人员分类。指挥者+类程序员

需求分析->系统设计->系统测试->运行和维护

需求分析

  1. 获取
  2. 分析与协商：超纲、优先级、冲突
  3. 系统建模：结构化分析（SA）：数据流图(DFD)、数据字典(DD)，面向对象分析（OOA）
  4. 规约：分析任务的最终产物
    1. 引言
    2. 信息描述
    3. 功能描述
    4. 行为描述
    5. 检验标准
    6. 参考书目
    7. 附录
  5. 验证：
    1. 复查：正确性+完整性+清晰性
    2. 评审：目标一致、资料齐全、数据重组、主要功能在范围内、符合约束条件、技术风险、检验标准
  6. 管理：
    1. 建立跟踪：正向+逆向
    2. 确保用户需求

系统设计

  1. 设计方法：
    1. 结构化设计（SD）：
      1. 数据流图
      2. 数据字典
        1. 结构化语言
          1. 顺序结构
          2. 选择结构：IF-THEN-ELSE-ENDIF、CASE-OF-ENDCASE
          3. 重复结构：DO-WHILE-ENDDO、REPEAT-UNTIL
          4. 例子
        2. 判定表
    2. 面向对象设计（OOD）：UML图
      1. 原则：
        1. 单一责任：修改某个类的原因只有一个
        2. 开放-封闭：实体可扩展但不可修改
        3. 里氏替换：子类必须能够替换基类，任何基类对象可以出现的地方，子类对象一定可以出现
        4. 依赖倒置：细节依赖于抽象，但不能反过来
        5. 接口分离：不强迫客户依赖于不用的方法
        6. 共同重用：重用了包中的一个类，相当于重用了包中的所有类
        7. 共同封闭：一个变化对一个封闭的包产生影响，则对该包中的所有类产生影响，而对其他包不造成任何影响
        8. 迪米特原则：一个对象对其他对象有尽可能少的了解
  2. 概要设计：
    1. 总体结构
    2. 数据结构与数据库：概念->逻辑->物理
    3. 编写设计文档
    4. 评审
  3. 详细设计：
    1. 模块和算法
    2. 模块内数据结构
    3. 代码+输入输出格式+界面
    4. 详细设计说明书
    5. 评审　　　　　　

数据库设计过程

    1. 需求分析：数据+功能+性能
    2. 概念结构设计：ER图
    3. 逻辑结构设计：ER图转换成表
    4. 物理设计：存储结构+存取路径
    5. 实施：编程+测试+试运行
    6. 运行与维护：运行+日常维护

系统测试

原则：

  1. 尽早开始
  2. 避免开发或小组承担（单元测试除外）
  3. 不能穷举
  4. 重视群集
  5. 严格按计划，避免随意

对象：程序+文档+数据，不包括开发人员

过程：计划->大纲->用例+说明文档->实施->报告

策略：单元测试->集成测试->确认测试->系统测试

单元测试

  1. 模块接口
  2. 局部数据结构
  3. 模块内路劲
  4. 边界条件
  5. 错误处理

集成测试

把所有模块组装成一个系统测试

  1. 非渐增式：先单元，再完整
  2. 渐增式
    1. 自顶向下：先上层模块，再下层模块，需要桩模块，不需要驱动模块
    2. 自底向上：先下层模块，再上层模块，需要驱动模块，不需要桩模块
    3. 驱动模块：主程序，装模块：模拟需要调用的模块
  3. 回归测试：重新执行已测试过的子集，只包括主要程序功能
  4. 冒烟测试：暴露影响构建的错误　　　　

确认测试

  1. 进一步检查软件功能和性能
  2. Alphea测试(开发者场所)和Beta测试（用户场所）
  3. 退化测试是用来防止改动产生的新错误

系统测试

  1. 恢复
  2. 安全
  3. 压力
  4. 性能
  5. 部署

白盒测试

  1. 语句覆盖：每个语句至少执行1次
  2. 判定覆盖：每种结果（分支）至少1次
  3. 条件覆盖：每个条件至少一次（不同的条件可能出相同的分支结果）
  4. 判定/条件覆盖：同时满足判定覆盖和条件覆盖
  5. 路径覆盖：每条执行到的路径至少1次

使用判定表看出条件取值的组合

 

调试

    1. 测试之后，开发人员进行
    2. 方法：试探、回溯、对分查找、归纳、演绎

运行和维护(生命周期最长）

新旧转换

  1. 直接转换
  2. 并行准换
  3. 分段转换
  4. 运行新系统过程：初始->推广->控制->集成->管理

维护

  1. 指标：可理解、可测试、可修改
  2. 文档：用户文档、系统文档
  3. 类型：硬件、软件
  4. 内容：
    1. 软件：正确性、适应性、完善性(在使用或运行中添加的需求)、预防性
    2. 数据：安全性、完整性、并发性
    3. 代码
  5. 管理：提出修改->领导审查答复->领导分配任务->验收+登记
  6. 工具：
    1. 版本控制
    2. 文档分析
    3. 开发信息库
    4. 逆向工程
    5. 再工程

评价

  1. 立项：规划阶段
  2. 中期：实施过程中，里程碑式
  3. 结项：正式运行后
  4. 内容：
    1. 需求：目标
    2. 规格说明：所有分析和测量，表示软件部件
    3. 记录：执行计划时详细记载
    4. 报告：执行测量和分析的结果，能重复及重新评价

项目管理

范围（4P）

  1. 人员：项目管理、高级管理、开发、客户、用户
  2. 产品：环境、目标、功能+性能
  3. 过程
  4. 项目
  5. 输入：
    1. 项目章程
    2. 项目范围管理计划
    3. 组织过程资产
    4. 批准的变更申请

估算模型

COCOMO（静态）

  1. 基本：静态单变量，只有LOC（源代码行数）
  2. 中级：基本+产品、硬件、人员项目等因素
  3. 详细：中级+分析、设计各步骤的影响
  4. COCOMO II：对象点、功能点、代码行 

Putnam（动态）

进度

  1. 基本原则：划分、相互依赖、实践分配、工作量确认、确定责任、明确输出、里程碑
  2. 安排：Gantt图、Pert图
    1. Pert图不能描述并行关系
    2. Gant图不能描述依赖关系

组织

  1. 基本原则：尽早落实、减少交流接口、责权均衡
  2. 模式：项目划分、职能划分（专项组）、矩阵（项目+职能）

配置管理（SCM）

基线、配置项、版本控制、变更控制

配置项

  1. 产品组成部分的工作成果：需求文档、设计文档、源码、测试用例
  2. 项目管理和机构支撑过程产生的文档：工作计划、项目质量报告、项目跟踪报告

设备清单不属于配置项

 风险管理

  1. 识别：性能、成本、支持、进度
  2. 预测：建立标准->描述后果->估算影响->标注精度
  3. 评估：RE=P x C，P：发生概率，C：成本
  4. 控制：避免、监控、RMMM计划

软件质量

  1. 内部、外部、使用
  2. 满足规定或潜在用户需求的能力

 

工具

特征：

  1. 覆盖整个软件周期
  2. 为项目调度提供多种手段
  3. 估算模型进行估算
  4. 支持多项目和子项目管理
  5. 确定关键路径、松弛时间、超前实践、滞后时间
  6. 成语与任务间的通信辅助
  7. 资源平衡
  8. 跟踪资源使用
  9. 生成固定格式的报表和报告

不具备指导性作用　

补充

冗余附加技术：

  1. 备份程序的存储及调用（不是关键程序）
  2. 纠错检测及恢复
  3. 容错固化　　

环路复杂性（McCabe）

 

　　V(G)=E-N+2，E:边数，N:节点数

开发方法

  1. 原型法：需求不清晰+多变
  2. 结构化法：规模不大+不复杂+不多变
  3. Jackson法：以数据结构驱动+规模小

------------------------------------------------------------------------------------------

类

  1. 实体类：存储和管理系统的内部信息，可以有行为
  2. 边界类：描述外部参与者与系统之间的交互
  3. 控制类：具有事件流控制行为，控制一个用例中的时间顺序，比如身份验证

多态

参数多态：应用最广泛、最纯的多态

包含多态：同样的操作可用于一个类型及其子类型。（继承）

强制多态：编译程序通过语义操作，把操作对象的类型强型转换

过载多态：同一个名在不同上下文中有不同的类型

模块划分原则：

  1. 大小适中
  2. 扇入扇出合理
    1. 扇出大=复杂度高，扇入大=复用度高
    2. 顶层扇出大，中间删除较少，底层扇入大
    3. 一般扇入扇出系数在3或4，不超过7
  3. 深度宽度合理　　

完善模块不能改进设计质量

体系结构风格

  1. 仓库风格：
    1. 优点：多方法、可更改、可维护、可重用、支持容错和健壮
    2. 缺点：测试困难、选择太多、效率低、成本高、缺少并行支持
    3. 包括：数据库系统、黑板系统、超文本系统

数据仓库

  1. OLAP：针对联机数据访问与分析，通过多维的方式对数据进行分析、查询和报表

UML图

  1. 用例图：描述参与者必须要完成的任务，关系(扩展、包含、泛化)
    1. 扩展：<<extend>>，虚线箭头，基用例的扩展，存在一个扩展点，只有当扩展点被激活时，子用例才能执行
    2. 包含：<<include>>，虚线箭头，相同动作抽出来成独立的子用例，供基用例共享使用
    3. 泛化：<<generalize>>，实线空心箭头，继承关系，基用例可以被子用例替代
  2. 类图：类名、接口、属性、操作、关系(依赖，泛化，关联，实现）
    1. 依赖：独立事务变化会影响依赖事务，箭头虚线
    2. 关联：描述了一组链，描述了整体和部分间的关系，实线和0..1,0..*
    3. 泛化：子元素对象可替代父元素对象，共享父元素的结构和行为，空心箭头实线
    4. 实现：一个类元指定另一个类元保证执行的契约。接口构件，用例协作
  3. 对象图：对象:类型，某一时刻一组对象以及他们之间的关系
  4. 状态图：状态词（动名词）+动作
  5. 包图：文件夹
  6. 活动图：有开始有结束
  7. 构件图：接口+依赖
  8. 制品图：系统的物理结构，常与部署图一起使用
  9. 组合结构图：描述类的内部结构
  10. 部署图：立方体+<<artifact>>
  11. 交互图：
    1. 序列图：生命线+控制焦点（像川字）
    2. 通信图：路劲+顺序号
    3. 交互概览图：活动图+顺序图
    4. 计时图：任务对象的生命线，强调消息实际时间以及相对顺序

UML视图

5种视图：

  1. 逻辑视图：表示架构中类、子系统、包和用例的子集
  2. 进程视图：描述并发与同步
  3. 实现视图：基于代码的文件和构件进行建模
  4. 部署视图：表示软件到硬件的映射和分布结构
  5. 用例视图：最基本的需求分析模型

 

设计模式

  1. 创建型
    1. 抽像工厂：工厂和产品都是接口，客户使用这两接口
    2. 生成器：产品的各个部件的抽象接口
    3. 工厂方法：实现时重定义方法
    4. 原型：有个原型用来被克隆
    5. 单例：只有一个实例，全局访问
  2. 结构型
    1. 适配器：接口兼容
    2. 桥接：抽象和实现之间没有固定的绑定关系
    3. 组合：不同对象的行为都从组件类中获取，进行组合
    4. 装饰：给对象添加额外的职责
    5. 外观：为一组接口提供一致的界面（相当于用一个接口就能涵盖了其他所有接口）
    6. 享元：共享（公共变量文件）
    7. 代理：权限控制对象访问
  3. 行为型
    1. 责任链：不确定的多个对象处理一个请求
    2. 命令：将请求封装成一个参数化的对象
    3. 解释器：同一句话不同语言解释
    4. 迭代器：顺序访问聚合对象
    5. 中介者：封装多个对象的交互
    6. 备忘录：对象之外保存一个状态，便于恢复
    7. 观察者：一个对象的状态发生改变时，依赖于它的对象都得更新（静观其变，它变我就变）
    8. 状态：状态变行为则变
    9. 策略：封装算法
    10. 模板方法：一次性实现算法不变的部分
    11. 访问者：对象中还有更具体地对象（不同地访问者有不同的操作）

面向对象分析

认定对象->组织对象->描述对象间的相互作用->定义对象操作->定义对象内部信心　　　

posted @ 2021-10-14 23:28  注入灵魂  阅读(191)  评论(0)    收藏  举报