• 软件过程与建模学习之：Cost Estimation

    文章目录


    在这里插入图片描述

    Formal

    • 决定 cost 的因素：
      在这里插入图片描述

    软件成本评估

    在这里插入图片描述

    成本评估过程中的挑战（challenges)

    在这里插入图片描述

    • 没有具体的科学
    • 中途的变化太多
    • 大多数评估方法都假设事情会按照预期进行，只是简单地增加一些余量来应对可能出现的问题

    可能的策略（possible solutions）

    （p

    • 等到项目后期再评估（几乎没啥用）
    • 通过过去的项目作为标准，大致评估
    • 将系统工作切分成小的部分，单独评估，容易些
    • 通过经验

    在这里插入图片描述

    可用的技术（Techniques）

    Expert judgement

    在这里插入图片描述

    • Delphi technique：首先让专家们单独评分，算出平均分之后，让每个专家按照这个分数调整自己给出的分数，再求平均，直到所有专家都停止 revise
    Analogy
    Parkinson’s Law
    Pricing to win

    在这里插入图片描述

    • analogy：根据之前的经验估算一个数值
    • parkinson‘s law：工作总是会占满所有可用时间，因此 cost 取决于当前的所有可用资源，例如你有 3 个人， 12 个月的时间，那么 cost = 36个person months
    • pricing to win：取决于客户出多少钱，出多少就是多少
    Algorithmic cost modelling （算法成本模型）

    在这里插入图片描述

    Size 的衡量方式

    在这里插入图片描述

    • 通过代码的行数来评估一个项目的大小
    • 通过 function 的数量来评估一个项目的大小
    代码行数
    • 逻辑上的代码行数：度量可执行“语句”的数量，但它们的特定定义与特定的计算机语言相关
    • 实际的代码行数：实际执行的代码行数
      在这里插入图片描述
      在这里插入图片描述
    *功能数量 （Funtion points）

    在这里插入图片描述
    在这里插入图片描述

    • function points 的计算可以在项目的早期进行评估，因为他只依赖于requirements
      在这里插入图片描述

    Agile

    Agile 中进行 estimation 的重要依据

    在这里插入图片描述

    • agile 的 effort 和 cost estimation 依靠于 story points 和 velocity
    • velocity 的定义就是：在一段时间之内，能够交付的产品数量（用story points衡量），代表了团队的生产力

    Agile estimation 流程

    在这里插入图片描述

    • 构建 user story
    • 为每个 user story 分配 story point；使用选定的技术(稍后讨论)，根据来自以前故事的故事点的数量估算每个故事的故事点数量。
    • 使用团队从以前的经验中获得的速度来估计项目的交付时间——在固定范围发布计划的情况下，开发一个burndown chart。
    • 在开发中，评估实际的 velocity
    • 使用这个真实的 velocity 去重新评估项目交付的时间

    Agile estimation guidelines （评估指导）

    在这里插入图片描述

    • 通过类比来确定这次的 user story 的分数分配情况
    • 将 story 划分成多个 task，对每个 task 评分，最终作为一个 story 的 评分
    • 使用正确的单位，不要讲 story point 划分太细。要使用几个固定的数值，例如只使用 1,2,4,8,12 或者斐波那契数列
    • 通过整个团队来给 user story 分配分数

    Agile 的 estimation techniques

    在这里插入图片描述

    Planning Poker

    在这里插入图片描述

    • customer 来读需求
    • 针对成员的自己的理解，团队成员首先进行提问，并最终通过一组预先固定的数值中的值给出自己的评价分数
    • 然后根据这些分数进行讨论
    • 最终重新评估，直到 获得一致的分数

    Bucket System

    在这里插入图片描述

    • 将所有的用户故事按照事先划分好的 bucket 进行分组
    • bucket 的分数指定也可以按照上面的标准（斐波那契数列）
      在这里插入图片描述
    • 先将桌面上的 story card 任意选一张放在分数标记为 8 的 bucket 中
    • 接下来的几张卡片每次随机抽取一张，讨论并达成一致意见，并相对于之前的卡片放置在一个桶中
    • 然后分配给每个人一些卡片，并根据个人判断将它们放在适当的桶中(分治法)。
    • 最后，团队审查了这些位置并达成共识

    Relative Mass Valuation

    在这里插入图片描述

    • 放一张大桌子，这样故事就可以很容易地相对移动。
    • 选择一个故事开始，团队估计他们是否认为它是相对的:大，中，小。
    • 大故事放在桌子的一端。中间是中型故事，另一端是小型故事
    • 继续执行步骤2和步骤3
    • 下一步是根据故事在桌子上的位置分配分数值。从最简单的值得分值的故事开始，称它为1 然后向上移动卡片列表，为每个故事分配1的值，直到你到达一个看起来至少比第一个故事难两倍的故事。这个故事得2分。

    Computing Velocity

    在这里插入图片描述

    • story points / day

    Estimated Delivery Time

    • 通过总的 story points 以及项目的速度，可以预估出项目完成的时间。
      在这里插入图片描述

    Estimation 总结

    在这里插入图片描述

    扩展重点内容（Function Points）

    SRS (Software Requirements Specification)

    • 一种指定对软件系统的期望的 文档;简称系统的要求
      在这里插入图片描述

    Function points 计算步骤

    在这里插入图片描述

    • 将这些需求进行分类

    • 估计每个类别或功能的复杂度值

    • 从复杂度计算总数

    • 估算价值调整因子

    • 计算总功能点计数

    • 下面是一个具体的需求文档：包含了 7 个主要功能需求
      在这里插入图片描述

    需求分类 (Categorize requirements)

    • 分成 数据功能 和 事务功能
      在这里插入图片描述
    Data functions

    在这里插入图片描述

    Internal logical file (ILF)
    • 数据是从外部输入进来的
    • 系统自身对这些数据进行处理和维护：关系型数据库，包含用户设置的文件
    External interface file (EIF)

    数据在外部维护，但是可能被内部系统进行调用：第三方服务器提供的数据，这些数据维护了当前系统状态

    Transactions Functions

    在这里插入图片描述
    在这里插入图片描述

    External Input (EI)
    • 从用户或另一个应用程序到系统的输入，用于控制系统的流程或提供数据。外部输入通常修改内部逻辑文件：由用户填充的数据字段、输入文件(例如编译器的程序源代码)。以及来自外部应用程序的文件提要。
    External outputs (EO)
    • 向用户提供有关系统状态的信息的输出 ：显示给用户的示例屏幕、错误消息和报告。其中的各个数据字段被分组为一个外部输出
    External Inqueries / Queries (EQ)
    • 输入不用于更新内部逻辑文件，而是用于查询内部逻辑文件并提供输出;直接检索输出，不包括派生数据 ：读取用户设置或从数据库表中读取记录的示例

    在这里插入图片描述
    在这里插入图片描述

    • 特别注意的是 R.4 这个 EIF 具有迷惑性，因为总体来说这个信息是当前系统发给一个 external 的系统，但是这个 external 的系统做的事情却是帮当前系统，因此属于 EIF.

    评估每个类别或功能的复杂度值 (Estimate a complexity value for each category or function)

    在这里插入图片描述

    • 复杂度分为简单、平均或复杂。
    • 通常是针对一个类别而不是针对每个需求
    • 一种常用的技术是基于数据元素类型(DETs)、记录元素类型(RETs)和文件类型引用(FTRs)
      • DETs: 系统中唯一的、用户可识别的、非重复的数据字段。比如在维护一个教育系统的时候，要维护学生的信息，这些学生的信息分为 Firstname, lastname, studentID 等，这些就属于数据元素类型
      • RETs： ILF或EIF中用户可识别的数据元素子组
      • **FTRs：**事务引用的文件(ILF或EIF文件)
    DETs, RETs, FTRs

    在这里插入图片描述

    • 在 Data function 的需求类型中，衡量的指标是：DETs 和 RETs
    • 在 Transaction function 的需求中，衡量的指标是：DETs 和 FTRs

    在这里插入图片描述

    • 从图中可以看出，当评估 EI, EO, EQ 等 transaction function 的时候，只用到了 DETs 和 FTRs 指标，而 ILF 和 EIF 等 data function 评价的时候只用到了 DETs 和 RTEs 指标

    从复杂度计算总估计值（Compute count total from Complexity）

    • 方法：使用 simple，average 和 complex 的数量，乘以他们各自占得权重，加权求和得到所有需求的总分数：
      在这里插入图片描述
      在这里插入图片描述
    • 因为本文的实例中，无论是数据功能还是事务功能的评价都是简单，所以在上图中的 average 和 complex 选项的值都被划去了。最后计算的分数是 29

    计算调整因子（Compute value adjustment factors）

    • 是基于14个特征计算的
    • 每个特征都有等级或0-5的范围;
    • 0不重要，5重要
      在这里插入图片描述

    计算最终的 function point

    • 将计数总数和值调整因子代入以下公式，以估计总计数
      在这里插入图片描述
      在这里插入图片描述

    Function points 优缺点

    优点

    在这里插入图片描述

    缺点

    在这里插入图片描述

  • 相关阅读:
    【C语言练习】C语言如何操作内存（重中之重！！！）
    隐藏的增长动力：中国工业的售后服务
    xilinx的原语的使用
    vue 样式加scoped不起作用 局部更改element-ui的默认样式
    linux同步之原子操作（二）
    935.骑士拨号器 - 力扣
    【内网渗透】记一次靶机实战
    php空合并运算符，三元运算符，PHP高级
    时间序列分析|异常值检测
    【配置环境】VS Code怎么使用JavaScript的Mocha测试框架和Chai断言库
  • 原文地址：https://blog.csdn.net/qq_42902997/article/details/126916527