信息产业培训网

为什么需要最佳实践[1]

http://www.miiceic.org.cn   2008-5-27 16:53:49   中程在线   浏览数:
关键字:

与许多古老的职业相比,人们从事软件开发的时间并不长。但就在这短短的几十年中,人们根据软件行业的经验,并从其他行业(如建筑业、制造业)借鉴,总结了不少&ldquo最佳实践&rdquo。特别是最近十年以来,这些最佳实践似乎分裂成为两大阵营:重型方法学和敏捷方法学。这两大阵营的拥护者都不少,并且领军人物都是德高望重。

  软件项目的目标

  在讨论这些最佳实践之前,先明确一下软件项目的目标,因为所有的最佳实践都是为实现项目目标服务的。Alistair Cockburn在他的著作《敏捷软件开发》中指出,软件项目的目标有两个,取得当前项目的成功并进行积累,为后续的项目做准备。

  关于第一个目标,一个比较麻烦的事情就是如何定义成功。一般来说,大家认为在预算范围和进度计划之内交付客户想要的产品,项目就算是成功的。但这样的理解似乎过于初级。Dewys Lasdon曾指出,&ldquo我们的工作不是用限定的费用及时地给客户他想要的东西,而是给他从未梦想过的东西当他得到的时候,他意识到这就是他一直想要的东西。&rdquo如果你结合iPod取得的成功来看,就能很好地理解这段话的含义了。

  关于第二个目标,主要有两层意思。第一层意思是&ldquo锻炼队伍&rdquo。在项目中,团队共同工作一段时间,进行了许多&ldquo战术配合&rdquo方面的练习,大家相互之间更有默契。对于个人来说,通过具体的开发实践,学习了不少新知识,也积累了经验。

  第二层意思是为后续项目提供积累。后续项目可能是运维项目,也可能是产品的下一个版本,或其他项目。不少项目开发工作对于后续项目有重要意义,如项目文档回归测试套件等。如果你曾接手过别人的项目,或者只是花时间读过别人的程序,就一定会对此深有感触。

  顺便提一下,项目的第二个目标不一定是次要目标。对于某些领航项目或概念验证项目来说,为后续项目提供经验积累就是项目的首要目标,也是项目成功的衡量标准之一。

  RUP

  根据IBM的官方说法,&ldquoRational Unified Process是一个灵活的软件开发流程平台。借助它可配置的构架,RUP 使你能够只选择和部署项目的每个阶段需要的流程构件。RUP 平台以业界公认的软件工程最佳经验为核心,它包含配置 RUP 以满足项目特定需求的工具。从这种意义上说,RUP 是一个软件开发方法框架,以及一个公认的、灵活的、实用的流程平台,用于成功的软件项目。&rdquo RUP提出了六项最佳实践:

  1. 迭代的开发软件

  2. 需求管理

  3. 使用基于构件的体系结构

  4. 可视化软件建模

  5. 验证软件质量

  6. 控制软件变更

  让我们来看看其中的需求管理。一项调查(James Martin An Information Systems Manifesto,Prentice Hall,1984)表明56%的缺陷其实是在软件需求阶段被引入的。而这其中的50%是由于需求文档编写有问题、不明确、不清晰、不正确导致的。剩下的50%是由于需求的遗漏导致的。更重要的是,许多需求缺陷直到很晚才被发现。而缺陷发现得越晚,修复缺陷所需的代价就越大。所以在传统软件工程方法中,非常重视需求工作,甚至称这部分工作为需求工程

  需求工程的主要出发点是减少需求中的缺陷,从而降低项目风险。Joel Spolsky 指出:“首先,没有编写规格说明是软件项目中你所承担的一个最大的、不必要的风险。”特别是在外包项目中,绝大多数客户都不会同意没有需求规格说明书的开发方式,因为这样做风险太大,实在不值得冒这个险。

  需求工程的另一项重要使命是发现机会,即发现创新的产品,为用户提供更多价值的机会。如果你草率对待需求工作,将丧失这种机会。例如,在我们进行业务流程分析时,应该适当关注企业流程再造,业务管理创新,实现更多客户价值的机会。只有这样,才能可能做出Dewys Lasdon所说的“客户从未梦想过的东西”。

  需求工程中的一个重要方面是管理需求的可追踪性,即从项目的总体目标追踪到业务用例,再追踪到实现用例和具体需求,最后追踪到实现和测试的能力。如果忽视了这个方面,项目的开发可能会偏离方向。

  我们在编写需求时,常常会用到一些文档模板,如需求规格说明书模板和用例模板。某些模板非常全面、细致,以至于某些部分我们初看上去甚至觉得可以忽略掉。但是当你打算忽略掉模板中的这些部分时,千万要小心,因为模板的主要作用之一就是降低遗漏需求的风险。

  有一次一名项目经理打算在开发团队中引入用例模板,查找了一些资料之后,写了一个草稿让我复查一下。我发现他的模板中没有用例的使用频度,问他时他说,觉得没有太大作用就裁掉了。于是我告诉他,用例使用的频度对系统的设计和实现有很大的影响,这属于系统的非功能需求,不能省略。

  如果你想进一步了解需求工程,推荐你读一下《掌握需求过程》这本书。

来源:
相关连接
最新评论
*以下网友发言不代表中程在线网站的观点和看法
    我要评论

    请您注意
    1、遵守中华人民共和国的各项有关法律规定
    2、承担一切因您的行为而导致的法律责任
    3、本网留言管理人员有权删除其管辖留言内容
    4、您在本网的留言本网有权在网站内转载和引用
    5、参与本留言即表明您已经阅读并接受上述条款
    我爱研发网中电华信阿里西西JAVA爱好者北京英才网全球大学查询网
    中国人的网站导航中国电脑论坛信息产业部新浪科技搜狐IT信息产业部电子教育与考试中心
    IT世界网软件项目交易网中国软件交易网国信培训网亚远景科技....[更多]
    关于我们 | 网站地图 | 周边住宿 | 行车路线 | 联系我们 | 网站律师 | 意见反馈 | 虚位以待 | 友情链接
    中程在线(北京)科技有限公司 版权所有
    总 部:北京市海淀区青东商务楼A座西四层
    企业培训部:010-52636110 52636106 就业培训部:010-68716925 68716926
    邮 件:training@miiceic.org.cn
    京ICP备06053134号
    Copyright © 2005-2008 Miiceic.org.cn All Rights Reserved