Nesma 主页 论坛 浆纱 浆纱 – 其他方法 自动功能点计数

已标记: 

观看中 15 帖子 - 1 通过 15 (的 19 总)
  • 作者
    帖子
  • #3236

    大家好,

    我不确定应该在哪个主题下发问, 所以我把它放在这里. 我认为函数点是将某种大小量度附加到一段代码的好方法, 但是要数他们真是麻烦. 我必须仔细研究所有I / O要求和数据结构,以获得合理的数量. 我发现一些可以自动计数的工具, 但是它们非常昂贵,我一直在寻找使用此类工具的经验. 该社区中是否有人具有自动FPA计数的经验?

    伊恩

    #3348
    彼得·贝伦
    参加者

    亲爱的先生,

    在回答你的问题: 我有自动FPA计数的经验.

    最后 5 年份, 我花了很多时间来开发用于自动FPA计数的工具. 该工具基于自然语言处理,可以阅读英语和荷兰语文本. 因此,如果您有功能设计之类的文档, 要求, 用例等, 该工具可以估算FPA数量. 它可以同时处理多个文档. 它还可以估计SAP设计文档(如Blue Prints等)的数量. 计数基于Nesma 2.2 版.

    如果您想了解更多信息, 给我发了一封电子邮件.

    问候

    彼得·贝伦
    荷兰
    pwhbellen@hotmail.com

    #3377
    弗兰克Vogelezang
    密钥管理员

    伊恩,

    基于 (联合会) FPA, 对象管理小组已发布了 自动化的FPA规范 在早期 2014. 我知道 CAST软件 有一个可以计算功能点的工具, 基于OMG规范. 这个工具很贵.

    我知道,在COSMIC社区中,有许多工作正在使计数过程自动化. 雷诺正在使用工作工具, 但这不适用于商业用途. 我知道Dutchsoft有一个用于SAP功能点计数的半自动化工具, 但这只能作为服务使用. 雷诺和荷兰软件的论文都在 2014 IWSM Mensura会议在鹿特丹. 这些文件可以从 2014.iwsm-mensura.org.

    #3380

    彼得,

    Nesma之间有什么区别 2.2 (似乎只有荷兰语) 和 2.1 版? 在Nesma和IFPUG之间?

    坦率,

    您是否有一些公开的关于COSMIC的参考资料? IWSM链接将我发送到IEEE站点,我必须在该站点上支付文件费用.

    #3388

    嗨伊恩,

    我来自CAST. 既然你提到过, 我不否认我们的软件有一定的价格标签 ;-).
    CAST能够自动计算APF的原因之一是R投入了1.2亿美元&D以便提供一种产品,该产品能够足够精确地确定我们复杂的多层应用程序的内部结构并提供准确的信息, 可重复的, 随着时间的流逝, 具有成本效益的AFP和EFP自动计数 (增强功能点).

    关于您在APF上的经验分享的问题, 在过去大约一年中,许多帐户和几家主要的系统集成商都大量采用了CAST AFP. 如果你给我发电子邮件, 我可能会指出您感兴趣的相关联系人. 仅在Nesma会员帐户列表的第一页, 我可以发现 2 具有在该主题上具有丰富经验的CAST COE的主要SI.

    问候
    杰拉德
    g.karsenti@castsoftware.com

    #3390
    弗兰克Vogelezang
    密钥管理员

    伊恩,

    如果你去 cosmic-sizing.org 您会发现一些有关该主题的论文,可以免费下载. 与CAST的投资相比,某些论文的投资很小 ;-). 您也可以将问题发布到 COSMIC用户组 在LinkedIN上. 我知道该小组中有许多参与自动化COSMIC开发的人.

    我也可以回答您给彼得的问题. NESMA 2.2 是英语的荷兰语版本 2.1 标准. 由于英文版本与ISO / IEC兼容 24570 标准中有一个额外的章节 1 与ISO的东西, 但除此之外,它们是相同的. 关于Nesma和IFPUG之间的差异,在 文章下载部分 该网站的解释差异.

    目前, ISO / IEC 24570 在下面 系统评价 和奈斯玛 计数实践委员会 已经发布了一份改进的维护清单. 接受这些改进后,这将导致计数指南的新版本. 我们将确保英语和荷兰语版本相同, 避免混乱.

    问候, 坦率

    #3429

    针对自动功能点计数软件供应商的问题: 您是否正在考虑将软件作为服务提供,例如按使用付费模式?

    也, 我还没有遇到过AFPC评估,该评估针对评估所基于的样本回答了以下所有问题:
    – 平均距离 (误差率) 自动计数从专家计数 (+分布偏斜的中位数比率)
    – 平均距离的标准偏差
    – 样本量 (ñ)
    – 样本数量的大小类别 (例如 100-500 FP, 500-1500 FP, 等等. — 如果样品混合, 按尺寸等级提供上述措施)
    – 计数类型 (如系统, 增强功能,… — 如果样品混合, 根据计数类型提供上述措施)
    – 系统类型相同 (嵌入式的, 商业, 互动, 批量,…)

    直到现在,我一直感觉缺少能够拨打电话的任何一个方面. 例如, 如果平均误差为 5%, 但是没有给出关于计数大小类的指示, 我无法判断该措施是否适合单个系统的数量. 物有所值, 它可能仅适用于大小超过 50,000 FP (大数定律). 您是否知道任何评估功能点软件的文章,并且足够详尽地涵盖所有这些方面?

    #3488

    你好,

    我写了几篇有关OMG标准的文章,以及SCA软件将AFP计入 质量博客.

    #3489
    弗兰克Vogelezang
    密钥管理员

    让·皮埃尔,

    这是一个有趣的博客文章. 我可以建议大家阅读. 为了便于讨论,我复制了您的一些观察结果:

    如我们所见, OMG标准的文档规定了使用自动功能点的要求, 以及它的局限性. 我认为最要记住的要点如下.

    周长
    该标准不“解决应用程序增强功能或维护功能的大小问题 (通常称为增强功能点) »,因此仅适用于新发展. 如果是这样的话, 它极大地限制了它的使用和兴趣.

    法新社和IFPUG
    AFP标准并不要求严格遵守手动计算功能点: «自动功能点计数可能与IFPUG认证功能点计数器产生的手动计数不同». 在我看来,这是第一要点: 自动化功能点不是IFPUG功能点. 这是另一种措施, 优点是可以通过工具自动计算, 因此比人工计数要省力, 但结果却不同.

    组态
    对AFP进行计数需要识别所有数据结构和交易并将其组装到功能组件中, 并决定内部还是外部, 以及在设置工具和配置分析时要考虑或不考虑的因素. 假设您有一些了解以下内容的人:

    • 中小企业或项目专家的申请.
    • 计数自动功能点以确定分析范围和要考虑的因素的过程.
    • 用于配置分析的工具及其参数, 验证假阳性并验证结果, 对应于前两点.
    • 如果我们想获得更客观的结果,则此配置阶段显然至关重要, 因此在衡量团队的生产力时要尽可能地可信.

    分析与验证
    使用工具对自动功能点进行计数时,假定该工具能够:

    • 分析任何种类的成分.
    • 确定这些组件之间的任何链接.
    • 将所有这些链接组装成尽可能少的假阳性交易.

    但是很少有代码分析工具具有能够在给定技术上识别和分析任何类型文件的解析器。, 更少地使用不同的技术. 工具可能能够识别批处理应用程序中平面文件上的“读取”或“写入”之类的操作, 识别Java框架的xml文件之间的不同类型的链接,并且无法分析HTML或Excel报告. 在我们的示例中,时间表应用程序的一个重要功能是在开具发票之前生成活动表以进行验证, 通常以不同的格式: 电子表格, PDF, 等等. 我知道没有代码分析工具可以管理此类文件.
    对于某些技术而言,要找到组件之间的所有链接可能很困难或不可能. 框架的使用 (弹簧, 冬眠, 等等) 使分析复杂化, 这意味着一项重要的工作,即要验证结果,以便尽可能避免出现假阳性, 然后检查已识别的交易以及每个交易的功能点计数.

    结论
    结论, 我认为自动化功能点是一种不同的措施, 与IFPUG顾问进行的人工估算相比,所产生的结果有所不同. 在理想情况下, 最好有这样的顾问来参与定义分析范围, 工具的设置, 结果验证. 这假设该工具能够识别所有组件, 他们之间的联系, 数据结构, 交易, 等等.

    即使在理想的情况下, 我认为手动估算和自动功能点之间的差异至少是 10% 至 20%, 经常在 40% 和 50%. 至少. 也可能是 200% 要么 300% 不同, 例如Cobol Batch应用程序 (许多平面文件), 集成软件 (企业资源计划) 具有不同的模块, 如果存在无法清楚识别交易的框架, 等等.

    你带来一些实际困难. 现在我能理解为什么CAST投入了1.2亿美元来使其正常运行.

    #3490

    给大家,

    很棒的讨论. 我们将重新考虑是否从自动计数开始. 我在Nesma文档中看到了一些快速的方法,可能会有用. 也许我会再问一些问题.

    致让·皮埃尔,

    很遗憾您的Qualiology网志文章的讨论已关闭, 所以我把我的观点放在这里. 您在博客中提出的,弗兰克未复制的异议之一是AFP无法进行增强功能. 我认为这是不公平的评论, 因为更改软件是一项活动. 您可以在变更文档中对其进行描述, 您可以将其想象在脑海中,然后更改代码. 法新社测量代码, 要么改变要么不改变. 更改不在代码中, 因此解析器将永远无法捕获它. 那不是法新社的缺点, 从技术上讲这是不可能的. 通过比较更改前后的计数,您也许可以捕获某些更改, 但是当对现有功能进行增强时,这将非常困难.

    您的博客中有几件事,我想对此发表评论. 由于我无法在质量学上做到这一点, 我可能会在另一篇文章中介绍.

    #3492

    伊恩,

    我博客上的评论已关闭 30 发布后的天数, 为了避免我不得不管理所有这些试图出售药片和各种产品的垃圾邮件发送者,这些东西与我的博客无关. 我刚刚重新打开它,以便您可以发表评论,任何人都可以参与讨论, 适度之后.

    我对您关于变更的观点不太了解. 弗兰克确实在上面提到了有关增强的部分 (看到 “周长”).
    是的, SCA工具可以分析更改, 根据不同分析之间的差异, 是否在现有代码中. 它可以 (还是应该) 说明添加了多少组件, 已删除, 改性, 如果修改, LOC等常规指标的变化, 抄送, … 还有法新社.

    如帖子中所述, 对于人们主要需要的AFP,这是必不可少的: 生产力估算. 如果您将应用程序的维护交给外包商, 您必须知道他添加了多少法新社, 已删除, 根据这些更改进行修改,以衡量他的生产率, 并与其他外包商或不同技术进行基准测试.
    新的外包商是否应对他必须维护的代码中已经存在的缺陷负责? 没有. 与法新社相同, 你算他改变了什么, 而不是您交付他的代码中的内容.

    大家都知道, 90% 编程活动正在维护中, 没有太多的新发展. 所以, OMG标准说AFP仅适用于新开发项目确实让我感到惊讶, 因为它严重降低了该措施对 90% 项目的.

    #3529

    让·皮埃尔,

    对不起,如果我不够清楚. 我会再尝试. 您写道,您对OMG声明感到惊讶.

    首先. OMG声明AFP不适用于增强功能. 这与说它仅适用于新开发项目并不完全相同. 我会尽力解释为什么.

    AFP工具可处理静态代码, 因此他们按原样测量代码的大小. 在维护之前或之后. 更改软件是您可以在更改文档中描述的活动, 但不在代码中. 代码已更改, 或不. 为了衡量维护项目的大小,您将需要两个静态代码实例, 一前一后, 然后分析差异. 我不确定这在技术上是否可行. 因此,我不会对OMG没有使这一奇迹发生这一事实做出否定的判断.

    #3536

    伊恩,

    我在博客上发布了对您评论的答案 http://qualilogy.com/en/do-developers-dream-of-automated-function-points-2/#comment-2312.
    不久:
    . 是, 您至少需要分析 2 版本并存储差异. 这是SCA工具通常执行的操作.
    . 这些工具通常可能仅对变更进行分析 (添加, 已删除, 改性) 组件, 但这不适用于AFP,因为您必须分析应用程序所有层上的每个事务和数据结构.
    . 如果SCA工具可以做到这一点, 为什么这个限制来自OMG规范? 这不是精确的.

    我很高兴知道为什么,因为我无法理解, 如果该标准仅限于新项目, 我想在公司开始对整个应用程序组合衡量AFP之前先了解一下, 谁的 90% 正在维护应用程序.

    #3571

    让·皮埃尔,

    谢谢您的回答. SCA工具是否可以存储差异, 比计数工具应该能够做到的相同. 也许杰拉德可以回答这个问题. 我无法想象他们没有将其视为 120 M $投资.

    #3578

    亲爱的大家,
    这是我对 (非常刺激) 讨论区.

    在5月 17, 在WETSOM 2015, 我对AFP进行了严格的评估. 您可以从
    http://conferences.computer.org/icse/2015/content/papers/7103a035.pdf#page=1.
    如果要求用户名和密码, 给我发送电子邮件,我将它们发送给您.

    关于增强的问题, 伊恩完全正确: AFP度量代码可以是维护的结果,也可以是新开发的结果. 然而, 在WETSOM上,Bill Curtis提到CISQ正在研究自动增强功能点规范 (也可以看看 http://it-cisq.org/cisq-to-start-work-on-automated-enhancement-function-point-specification/).

    最后, 有一些研究活动针对基于代码执行的功能点的自动测量. 这个想法是,通过查看执行跟踪,可以查看用户调用了哪些进程, 每个过程中使用了哪些数据, 以及用户和系统之间交换了哪些数据. 在实践中, 通过执行跟踪包含计算功能点所需的信息. 这些举措很有希望, 但是要测量的代码需要检测, 目前没有支持工具, 除了学术原型和概念证明.

观看中 15 帖子 - 1 通过 15 (的 19 总)
  • 您必须登录才能回复此主题.