【学习中】软件工程



🗓 2020年01月01日     📁 文章归类: 学习中    

版权声明：本文作者是郭飞。转载随意，标明原文链接即可。
原文链接：https://www.guofei.site/2020/01/01/software_engineering.html


软件的定义：程序+文档

软件工程的目标：生成具有正确性、可用性、开销合宜的产品

  • 正确性：软件产品达到预期功能
  • 可用性：软件的基本结构、实现、文档为用户可用的程序
  • 开销合宜：软件的开发、运行的开销满足用户要求

软件工程活动：需求、设计、实现、确认、支持

  • 需求：系统模型、系统功能的精确、系统的描述
    • 需求验证：验证需求陈述和需求规约之间的一致性、完整性、可跟踪性
  • 设计
    • 总体设计：体系结构、子系统、模块、接口定义
    • 详细设计：每个模块的详细描述、数据结构说明、算法
  • 实现
  • 确认：贯穿于整个开发过程
    • 包括需求复审、设计复审、程序测试
  • 支持活动
    • 完善性维护、纠错性维护、适应性维护

软件生存周期：形成概念、历经开发、交付、修订、演化、淘汰

软件过程：过程是活动的集合，活动是任务的集合，任务是输入转换为输出的操作

关键过程分3类：

  1. 基本过程：与软件生产直接相关的活动集。又分为5个：
    • 获取过程：需方，定义客户要求，接受客户要求的产品
    • 供应过程：供方，
    • 开发过程：软件开发者（又包含13个活动）
    • 运行过程：系统操作者
    • 维护过程：维护者
  2. 支持过程：有关各方按其目标从事的一系列支持活动集。分为8个
    • 文档过程：为记录生存周期过程所产生的信息而定义的活动
    • 配置管理过程
    • 质量保证过程
    • 验证过程
    • 确认过程
    • 联合评审过程
    • 审计过程
    • 问题解决过程
  3. 组织过程：与软件生产组织有关的活动集
    • 管理过程
    • 基础设施过程
    • 改进过程
    • 人力资源过程
    • 资产管理过程
    • 复用程序管理过程
    • 领域软件工程过程

软件生存周期模型有哪些：

  1. 瀑布模型
  2. 增量模型
  3. 演化模型
  4. 喷泉模型

caption: 瀑布模型

瀑布模型：

  • 要点
    • 按照固定顺序，连续而连接若干阶段工作
    • 规定每个阶段的输入、输出
    • 基于逻辑：如果上一阶段的输出是正确的，这一阶段也是正确的，那么输出也是正确的：
    • 正向流动、反向流动（返工）
  • 优点
    • 做之前有需求阶段，鼓励做之前对“做什么”做规约
    • 编码前有设计阶段，鼓励编码前设计
    • 每个阶段结束时复审，允许获取方和用户参与
    • 前一步的产品是下一步的基线，，允许基线和配置早期接受控制
  • 缺点
    • 客户必须完整、正确、清晰表达需求
    • 缺乏灵活性，如果需求有偏差，最终差评就会不满足需求
    • 早期的基线、里程碑花费很多时间
    • 直到项目结束之前，都不能演示系统的能力，增加了项目的风险

caption: 增量模型

增量模型

  • 在第一个版本需求确定的情况下
  • 每个增量都是一个瀑布模型
  • 优点：
    • 作为瀑布模型的变体，有其所有优点
    • 第一个可交付版本的成本和时间很少
    • 开发增量的风险不大
    • 由于很快有第一个版本，因此可以减小客户需求变更
    • 允许增量投资
  • 缺点
    • 没有对用户变更做规划，初始增量可能带来后来的增量不稳的哥
    • 需求不能在早期完善，某些增量可能要重新开发、重新发布
    • 管理成本、复杂性可能超出组织能力

caption: 演化模型

演化模型

  • 针对实现不能完整定义需求的情况
  • 针对用户的核心需求，开发核心系统
  • 根据用户反馈，实施活动的迭代

喷泉模型

  • 特点：不断迭代、每个阶段无缝
  • 面向对象

软件需求

需求的基本性质（来自IEEE标准830-1998）

  1. 必要性（Necessary）
  2. 无歧义（Unambiguous）
  3. 可测的（testable），可以对它测试吗
  4. 可跟踪的（Traceable）。从一个开发阶段到另一个开发阶段，可以跟踪吗
  5. 可测量（Measurable）

需求的分类

  • 功能需求
    • 必须执行的功能
    • 是整个需求的主体
  • 性能需求
    • 例如：处理实现、并发度、可支持的用户数量…
  • 外部接口需求：交互的硬件、软件、数据库。也可能是格式、时间等
    • 系统接口：描述应用与系统如何交互
    • 用户接口：与用户之间如何交互。
    • 硬件接口：与硬件设备的交互，
    • 软件接口：与软件的交互
    • 通讯接口：与通讯设备/局域网等的交互
    • 内存约束
    • 操作
    • 地点
  • 设计约束
    • 例如，必须用C++编写。内存消耗不超过50%。必须用红色、14点字体显示警告
  • 质量属性
    • 可靠性：正常运行
    • 存活性：某一部分不能运行时，软件继续运行/支持关键功能的可能性
    • 可维护性
    • 用户友好性：学习使用它的容易程度
    • 安全性
    • 可移植性

需求的发现

  • 自悟。需求人员知识丰富、想象力丰富。
  • 交谈：直接询问用户
    • 需求人员有“正确提出问题”能力，回答人员有“揭示需求本意”的能力
    • 风险，交谈期间需求不断增长，超出项目成本/时间。“完美蠕行”（Creeping elegance）
  • 观察。观察用户执行现在的任务，观察他们如何操作。
  • 小组会。客户与开发人员联席会议
    • 主持人的能力至关重要。必须仔细选择小组成员
  • 提炼：复审技术文档
  • 综合运用

需求规约（SRS，Software Requirements Specification）

  • 性质：
    • 重要性和稳定性。是基本需求、可选的需求、期望的需求。
    • 可修改：修改某一部分需求，不会过多影响其它需求
    • 完整：没有被遗漏的需求
    • 一致：没有互斥的需求
  • 功能，需要考虑的问题：
    • 功能源
    • 功能共享的数据
    • 功能与外部界面的交互
    • 功能所使用的计算资源

需求规约的格式（IEEE 830-1998）

1. 引言
    1.1 目的
    1.2 范围
    1.3 定义、缩略语
    1.4 参考文献
    1.5 概述（项目范围）
2. 总体描述
    2.1 产品概述
    2.2 产品功能
    2.3 用户特性
    2.4 约束
    2.5 假设和依赖
3. 特定需求
附录
索引

其中的“3. 特定需求”是文档的技术核心，有一些模版：

  1. 根据系统运行模式
  2. 根据用户类
  3. 按对象
  4. 根据系统层
  5. 根据激发
  6. 按功能层次
  7. 根据用户类、功能、特征
  8. 其它

需求规约的作用

  • 软件开发组织和用户之间，事实上的技术合同
  • 对于项目大多数工作，一个管理控制点
  • 对于产品设计，一个正式、受控的起始点
  • 基于它，还产生两个文档：初始测试计划，用户系统操作描述

初始测试计划：对未来系统哪些功能和性能进行测试，以及达到何种要求

  • 作用：早期发现错误，改正的代价小很多

用户系统操作描述：一份初步的用户手册

  • 软件开发早期，使未来用户从使用角度检查
  • 书写这个文档，迫使从用户角度考虑软件系统
  • 不是设计文档
  • 不是进度文档，不是规划文档。不给出项目成本、交付进度、开发方法、质量保证、验收、安装等信息

结构化分析方法

结构化方法包括

  • 结构化分析方法
  • 结构化设计方法
  • 结构化程序设计方法

需求分析的目标：

  • 解决需求陈述中的歧义、不一致的问题
  • 作为开发人员和客户间技术契约的基础
  • 给出问题的形式化或半形式化的描述

工具：

  • DFD图
  • 数据字典
  • 加工小说明

caption: DFD图

caption: 数据字典

caption: 判定表盒判定树

需求分析的输出：XXX系统需求规格说明书

        XXX系统需求规格说明书
1. 引言
  1.1 编写目的
    说明编写本需求规格说明书的目的
  1.2 背景说明
    (1) 给出待开发的软件产品的名称；
    (2) 说明本项目的提出者、开发者及用户；
    (3) 说明该软件产品将做什么，如有必要，说明不做什么。
  1.3 术语定义
  1.4 参考文献
2. 概述
  2.1 功能概述
    叙述待开发软件产品将完成的主要功能。
  2.2 约束
    叙述对系统设计产生影响的限制条件，并对下一节中所述的某些特殊需求提供理由，如管理模式、硬件限制、安全等。
3. 数据流图与数据字典及加工说明
    3.1 数据流图
      3.1.1 数据流图
        (1) 画出该数据流图
        (2) 加工说明
        (3) 数据流说明
      3.1.2 数据流图2
    3.2 数据字典
      3.2.1 文件说明
      3.2.2 数据项说明
4. 接口
  4.1 用户接口
  4.2 硬件接口
  4.3 软件接口
5. 性能需求
  5.1 精度
    逐项说明对各项输入数据和输出数据达到的精度
  5.2 时间特征
    定量说明本软件的时间特征，如响应时l、咖吨更，处数据传输、转换时间、计算时间等。
  5.3 灵活性
    说明本软件所具有的灵活性，即当用户需求有某些变化时（如操作方式、运行环境、时间特征等），本软件的适应能力。
6. 属性
  6.1 可使用性
    规定某些需求，如检验点、恢复方式和重启动性，以确保软件可使用。
  6.2 保密性
    规定保护软件的要素
  6.3 可维护性
  6.4 可移植性
7．其他需求
  7.1 数据库
  7.2 操作
  7.3 故障及处理

结构化设计

参考资料

【北京大学】软件工程

课程笔记：（清华）《软件工程》 刘强老师

概述

持续进行的需求管理

行动 产出
需求获取 会议记录等
需求分析 分析模型
需求规格说明 需求规格说明书
需求验证 已确认的需求规格说明书

团队建设

  1. 进度管理
    • 每周一晚8:00召开小组讨论会，地点在xxx。主要内容是进展、心得、遇到的问题和风险
    • 每周三、五团队集中开发
    • 每次集中开发前矩形10分钟站立会议。报告开发进度、困难。
    • 周报（或需求管理系统）提交到系统
  2. 团队管理
    • 记分方式记录成员参与度，每次参加加1分。
    • 周会应当简洁，每人事先准备。轮流做会议纪要
  3. 团队建设
    • 鼓励写技术博客
    • 达到阶段目标时，请大家pizza party

敏捷开发

原因是互联网时代的特点决定的：

  1. 小bug可以容忍，但是时间很重要，早一天发布可能结果完全不同
  2. 客户需求是无法在一开始定下的，往往先有了软件，才有了需求
  3. 即使是已经做完的app，也要经常更新，否则也会失败

需求提取

5W2H

1:card

  • As a 【user】，I want 【function】，so that 【value】
  • As a 【role】，I want 【feature】，because 【reason】
  • As a 【role】，I can 【feature】
  • As a 【role】，I want 【feature】，so that 【reason】

2:conversation

您的支持将鼓励我继续创作！