用例图是软件项目成本预估的好帮手

成本预估对于所有的项目来说都是至关重要的。没有成本预估,就不可能在项目前期控制成本与管控风险。为了让项目经理能够尽早组建团队、申请项目资金,并评估可能的风险,一个方式便是参考以往项目经验来估算项目成本。

成本最重要的“开发成本(时间)”部分就是由程序员参考生产力来评估所有系统功能完成的。尽管具体功能花费的时间是由程序员来估算,但是比”具体功能”影响更大的,比如,项目有多少功能?范围如何?则是由项目经理向客户确认的,而确认的结果就是用例文档和用例图。

相比用例,同样是描述参与者和系统的交互(也就是系统功能),用例图却有这样的优点:

  • 简单。相比几百行的文字和简单的图形,可想而知哪个更容易
  • checklist。图形容易放在一张纸上,这样有助于发现检查遗漏的需求;几十页的文字很难做到。

所以,在分析系统时使用用例图更不容易遗漏,更有帮助与沟通,也更能帮助到你。而我们说的成本预估刚好需要从系统的范围入手。

谁使用用例图?

用例图是一个非常有效的工具,各个参与方都可以从中获益:

  • 客户–可以更好的理解软件将完成什么,并能判断当前的方案是否满足他们大部分的需求。
  • 项目经理–项目经理可以使用用例图来保证各利益方达成共识。在项目预估时,用例图可以作为重要的沟通手段,确保所有人都很好的理解了方案设计的系统范围。
  • 程序员–通过用例图理解系统的功能和交互。

如果你有一只笔和一张纸,那么现在就可以开始了

怎样创建用例图?

创建用例图的工具非常多。一开始时建议使用白纸来绘制草图,一般我会快速地画出马上识别出来的用例图。这些用例一般颗粒比较粗,所以随后我会在另外一张白纸上画出比它颗粒更细的用例图。过程中,我通常使用比较粗的黑色水笔来绘制第一份用例图,因为较粗的线条会迫使我专注在重要的元素上,并忽略那些暂时不重要的细节。如果出现了错误,我选择直接放弃它,这完全不会影响其它的草图。但是被放弃的草图纸,你最好想办法再次利用他们,这是为了环保。

当草图完成的时候,我一般会邀请团队的技术主管做个简短的评审。评审时我会先在电脑上使用软件重新绘制草图。较之于在白纸上绘制草图,使用软件绘制有如下的好处:

1 重新组织用例图元素时,使用软件比手绘更快、更简单。

2 软件提供了绘制模板,使用手动拖放就可完成绘制过程。

3 数字用例图更容易和别人分享,并且能够在团队中保证用例图的一致性。

我使用UMLet作为绘制用例图绘制工具,你可以在官网http://www.umlet.com中下载到它它是开源代码轻量级UML建模工具,使用界面简单,能够让你快速建模,并能导出各种格式SVG,
JPG, PDF and LaTeX-friendly EPS。恰恰因为它的简单,让我在众多的软件中选择它。

UMLet还为绘制其它图形提供了模板,比如时序图、泳道图等

我认为UMLet是非常值得推荐的工具,但是,用例图本身是和工具无关的,他的目的是促进交流和探索新需求。这意味着你应该选择自己熟悉的工具。 

用例图的4个小技巧

1. 不要试图将用例图变漂亮

虽然我们应该尽量将用例图装饰得好看一点,但是不要把精力放在上面,而应该把精力集中在其要展示的系统上。

2. 及早反馈,经常反馈

不用担心你的用例图还没有展示所有的东西,而应该尽早地向利益相关者展示。用例图应该是协作式的、迭代式的过程,这个过程分为3个步骤:

  1. 从草图开始,以表达一些概念
  2. 从所有利益相关方收集反馈
  3. 逐步完善直到项目结束

3. 站在用户的角度

4. 在必要时使用注释

在你需要说明的地方加上注释,比如关于更细颗粒的用例在另外一页时,可以使用用例说明。

结论

用例图是帮助团队讨论系统、分析系统的绝佳工具,它非常适合在团队讨论、分析、展示、评审时使用。同时,它又非常地简单,一只笔、一张纸即可,当然你也可以使用软件。如果你在预估项目开发时间时使用它,我相信它会帮助到你的。

时间: 2024-08-03 04:37:24

用例图是软件项目成本预估的好帮手的相关文章

程序员软件项目预估的宝贵经验

我最近参加了一个关于软件预估的课程.对于这种本质上就是非精确的科学,我一向都非常谨慎,因为我深信预估可以创造价值.在这个历时两个小时的课程中,我发现了如何提醒大家进入预算而不必过度分析和思考的方法. 非常常见的例子 我们经常能听到项目经理和开发人员之间类似于这样的对话: PM:"你能不能给我一个开发某某功能所需要的预估时间?" 程序员:"一个月" PM:"一个月时间太长了,我们只有一周时间!" 程序员:"最好三周" PM:&q

一地鸡毛——软件项目中的人际困局

一地鸡毛--软件项目中的人际困局作者结合切身经历,展示了他之前所在团队软件项目延期的种种原因,而其中印象最深刻的是各种人事纷扰乃至于勾心斗角. 六年前,毕业未久的我在一家外企工作,我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周.这本身根本不是什么大事情,但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻. 公司 我的老东家是一家大型跨国电信设备开发商,曾具有辉煌的历史.我还记得在公司110周岁的生日庆典上,一位高管致辞说:"110年,这不是奇迹,是成绩",令人不胜欷歔.

CMM可重复级在特殊软件项目中的应用

引言 由 SEI 在 1991 年 8 月发布的软件能力成熟度模型( SW-CMM ),用来评估软件企业的 成熟度级别,使软件企业了解自己的优势和不足之处,从而持续地改进企业的软件开发过程,提高管理水 平,降低管理成本,保证软件开发效率和软件质量. 然而, CMM 是针对大型项目和企业制定的. 小项目和中小企业由于受到相应条件的限制,如组织结构.角色和关系.过程模式定义等,生搬硬套 CMM 框架只能给自己带来沉重的负担.可取的做法是把 CMM 作为一个参考,从 CMM 评估体系中汲取适合于自 身

2012年最可怕的软件项目事故汇总

数十亿美元就这样打了水漂--今年多个软件项目遭遇失利,此类事故已经引起管理者的高度重视. 诚然,很多企业在软件项目的推进过程中获得了成功,也将供应商所承诺的新特性与新功能顺利传递给终端用户:更低的运营成本.更简洁的管理流程以及各类足以取悦消费者的要素. 但遗憾的是,仍然有一些项目以失败告终:投入巨资的客户只能面对"断瓦残垣"而欲哭无泪,并被卷入危害事业进展.有损合作关系的漫长诉讼当中. 而从积极的角度来看,我们能够将这些过往的事故当作前车之鉴,无论是供应商还是项目客户都能够从中吸取经验

软件项目“免坑”指南

"谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日."这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的.就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去. 一.坑有多深? 当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑.造坑的项目,往往具有某些"臭味",以下是我的一些认识,这些"臭味"即是项目健康状态不佳的明显标志: ● 编码规范形同废纸,代码质量低下.每个项目都有编码规范,但真正严格

《Microsoft.NET企业级应用架构设计(第2版)》——2.2 软件项目的机制

2.2 软件项目的机制 如果你问:"什么导致项目失败?",你得到的最常见的回答可能会把失败归咎到与业务有关的问题,比如说,缺少需求,项目管理不到位,成本估算不正确,缺少沟通,甚至各个团队的人员相互不配合.你很难看到坏代码可能导致问题这种情况. 有鉴于此,我们认为未被发现的BBM可以严重损害软件项目,但未能处理的BBM却可以真的毁了它. 最终,个体以及个体之间的实际互动才能真的决定软件项目的成功或失败.但是,组织结构及其整体文化也会影响最终结果. 2.2.1 组织文化 Apple公司的组

浅谈软件项目的需求管理

软件项目区别于其它项目的最显著的特征是其不可见性,它不像硬件购销.建筑工程,都是实实在在可见的东西.而软件项目在系统交付之前很长一段时间,客户是无法感知自己想要的系统究竟是什么样子.因此,需求管理就显得十分重要,据相关统计数据分析,软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的. 需求管理作为软件项目管理的一个重要内容,贯穿项目实施的全生命周期.俗话说:万事开头难.需求作为软件开发的第一个环节,其重要性不言而喻.市面上关于需求管理的相关理论和书籍很多,但多数停留在

从拼死拼活开发软件项目到远程遥控管理

现在想想开发软件都有整整12年以上了人生最美好的时光都用在这个上了,在这期间有不少酸甜苦辣,有时候真不好意思说自己是35岁的老程序员了,有尝到过创业失败的滋味,有过人生的困难时期,多少遇到了很多贵人相助,日子就一天比一天好起来了.其实每天怀着感恩的心里,生活就一天比一天好,心态也会越来越健康了. AD: 交流很重要,沟通无极限 现在想想开发软件都有整整12年以上了人生最美好的时光都用在这个上了,在这期间有不少酸甜苦辣,有时候真不好意思说自己是35岁的老程序员了,有尝到过创业失败的滋味,有过人生的

软件项目需求管理复杂性分析

在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能 ,优化性能,提高用户友好性的要求.在软件项目管理过程中,项目经理经常面对用户的需求变更.如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加.质量下降及项目交付日期推后.这决定了项目组必须拥有需求管理策略. 一.需求管理复杂性分析 软件需求是整