• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

“轻”方法与满意质量:市场驱动的软件工程实践

发布: 2008-2-02 16:07 | 作者: 任菲  | 来源: 不详 | 查看: 20次 | 进入软件测试论坛讨论

领测软件测试网 随着信息技术的迅猛发展,今天的IT从业人员正处于这样一种进退两难的境地:一方面,根据以往的痛苦开发经历,他们知道如果采用杂凑的作坊模式来开发复杂的、高质量的信息系统具有太大的风险;另一方面,他们也同样知道,形式化的、戒律森严的软件工程方法(典型情况下是与ISO9000和SEI-CMM相关的)又常常是官僚主义和耗费时间的,不可能满足目前高度竞争的“Inte.net时代”环境下对于进度方面不断增长的挑战性要求。显然,如何使得企业在保证软件质量的前提下,同时又能够适应快速变化的市场需求,无疑是业内人士关注的焦点。为此,本文从市场驱动的IT开发特点分析入手,对目前国际上正日趋成熟的“轻”方法和满意质量的内涵和操作加以讨论,同时以快速应用开发为实例介绍了具体操作及注意事项,为读者进一步深入理解现代软件工程实践工作提供帮助。

     一、市场驱动的IT开发工作

  当今的IT企业正处于一种前所未有的竞争环境之中,无论是作为独立软件供应商还是增殖服务商,也无论是开发直接面向市场的软件产品如游戏、工具、多媒体等等,还是为用户定制软件如电子商务应用、MIS等等,市场竞争都无处不在,IT开发工作被迫在市场驱动的状态进行,具有以下典型特征:

  快速演变升级的基础技术,必须及时跟踪基础技术的革新并调整策略。

  持续的竞争,必须不断推陈出新来满足用户需求。

  时间就是金钱——需要在时间、质量、费用之间达成折衷。

  从业人员聪明且教育程度高,能够在一定范围内进行自我管理。

  以往流行于IT行业的设计—评审—构造模型已过时。IT业最新的技术和工具改变了以前项目运行所必须遵循的逻辑顺序。比如:现在一些工具允许“即时”创建屏幕,使得冗长的设计—评审—构造模型不再适用,而要求一种更难于计划的原型—审核—构造—再审核—再构造的过程。

  角色重叠:现代技术和工具使原来专门的设计、分析、编码人员之间严格的区分界限变的模糊。

  以往的IT开发人员相对于当前市场驱动下的开发人员而言,至少拥有以下优势:控制他们的应用开发技术。在传统的企业应用开发中,机器配置和其他系统元素在实现阶段就被指定。现在,这种优势不复存在,很少有哪个系统被实现为在专用机器上的孤立应用。相反,他们经常是企业用户机器上的另一种应用,必须与其他商业应用程序联合使用,这使得IT开发人员不得不为保持与CORBA、Internet、或数据库标准的变化相一致而疲于奔命。同时,持续的竞争、紧迫的进度和严格的预算让IT开发经理不得不经常根据销售人员或客户的要求而调整开发工作。

  显然,市场驱动的新环境给IT开发带来新的挑战,如果照搬套用以往的成功经验和开发模式并非明智之举,必须适应新形势的要求,重新思考和定位。

  二、“轻”方法浮出水面

  随着软件工业不断发展,各种各样的模型不断涌现或退出历史舞台。早期从不同角度提出的各种设计表示方法(常常以发明者的名字来命名)目前似乎已经聚合成为UML这种被广泛接受的标准,结构化设计方法也正在让位于面向对象设计等更受欢迎的方法学,这种变化在更高层次的全局性开发方法学方面同样进行着。

  传统意义上的软件方法学描述通常“能够”处理任何大小的项目,而实际上真正的困难就来自于如何对这些方法加以裁剪以适合较小的项目。针对这种理论与实际的脱节现象,国际上一些著名的软件工程专家提出所谓“重(heavy)”方法和“轻(light)” 方法之分,试图为快速发展的软件工业探寻更切合实际的解决方法。

  所谓“重”方法,就是指形式化的、戒律森严的软件工程方法学——不仅指这些方法所生成纸文档重量,还意指管理资源投入、QA评审的程度和开发人员被要求遵守的严格流程。相对的,诸如快速应用开发(Rapid Application Development,简记为RAD)和原型方法等则可以被称为“轻”方法——不仅是因为这些方法倾向于产生最小数量的纸文档,还因为其将管理资源投入最小化。不幸的是,1990年代的许多RAD项目在方法学上采取了过“轻”的处理以至于几乎不存在什么方法,这些项目常常退化为杂凑式作坊开发,实质上根本没有任何文档。 显然,需要在两种极端方法之间找到平衡点。

  轻方法代表了一种有意识的风险防护方法,依据不同风险在与开发相关的各种活动中投入相应时间、资金和资源。例如,进行多少需求分析工作才算是过多,拟或过少?针对一个几百个需求的开发项目而言,一个需求分析“轻”方法(requirements-light approach)可能是由将每一个需求通过一个简洁的句子加以文档化的行为所组成,一个需求分析“中”方法(requirements-medium approach)可能要求对每个需求通过一段描述性文本来文档化,而一个需求分析“重”方法(requirements-heavy approach)则可能要求详细的UML模型、数据元素定义和每个对象方法的形式化描述。

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 市场驱动 软件工程实践

61/6123456>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网