软件质量保证需要系统性的方法论

发表于:2010-6-28 13:39

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:李云(51CTO博客)    来源:51Testing软件测试网采编

  接着系统工程(system engineering)部门根据用户的需要捕获需求。如何正确地捕获用户需求超出了本文的范畴。但是,当需求被捕获了以后,如何对需求进行管理就是方法论的范畴了。需求的管理是直接采用一个Word文档呢?还是采用专业的需求管理工具?比如,来自IBM的DOORS就是业内很有名的需求管理工具。需求管理不能简单地理解为在哪个地方存方需求描述这么简单,而是还得考虑开发团队和测试团队如何跟踪需求。通常需求是分层次的,比如按层次的高低可以分为系统层、子系统层、设备层和测试层,且各层次的需求是由不同的团队负责的。显然,每一个层次之间的需求是有关联的,低层次的需求来源于高层次,但将高层次的需求进行了细化。如何反映各层次之间的依赖关系就是需求管理很重要的内容。在需求管理方面,DOORS被大公司广泛采用。DOORS是采用语句描述的方式来阐述用户需求的,在UML被广泛采用的时代,如何将UML运用到需求管理中去也很有学问。在作者目前(2009年5月)所服务的公司中,就是采用 DOORS和Tau(来自IBM的UML工具)共同管理需求的。

  有了需求以后下一步就是设计(design)工作了。设计阶段最需要注意的是时间压力。设计不同于编码,是一个很抽象的创造性思维过程。其实,一旦设计做好了以后,编码和测试工作都相对省时。就作者的体会,开发最花费时间的部分就是设计阶段,设计阶段的时间如果不足,则容易造成编码和测试将耗费更多的时间,因为在设计阶段没有思考清楚而更易造成概念不清晰。当然,并不是说设计投入了更多的时间则设计质量就一定会更好,其中很重要的一个前提条件是项目组中是否存在具备高水平设计能力的人。如果没有这样的人,可能在设计阶段给再多的时间也于事无补。设计工作中,最重要的一个辅助工具是UML工具,当然,还有用于帮助思考所编写的原型代码。UML虽然因为其过于复杂受到部分人士的批评,但它却被很多行业广泛采用(不只运用于软件行业),它的衍生建模语言如 SysUML、BPMN等也正蓬勃发展。UML随着版本的不断演进,其表达能力也越来越强。功能强大的UML工具更多地来自商业公司,强大是指工具能很好的遵循UML规范。比如Visual Paradigm的UML工具就很不错,不论是可使用性、还是对规范的遵循都很突出。除了Visual Paradigm的UML工具,来自IBM的Rational Software Modler也是不错的选择。除了商业软件,开源的StarUML也被很多人采用,由于它不能很紧密地跟随规范的发展,所以在使用时有时会觉得它的表达能力存在局限。

  设计质量需要通过设计审查(design review)这一流程去保证。设计审查不同于代码审查(code review,后面将会谈到),设计审查的重点应在于把握概念,且相对抽象。而代码审查则侧重于检查编码质量,比如数据结构的合理性和更为精细的业务逻辑,以及运用项目积累的经验去检查编码中是否采用了积累的最佳实践或违背了所吸取的教训。在设计审查时,如果设计者不能通过讲解设计概念让与会者了解其设计意图,那很有可能表明设计质量并不高。在设计审查会上,重点不在于检查数据结构,而在于检查设计概念。如果设计概念清楚了,数据结构如何组织是顺其自然的事。在项目组中要真正做好设计审查,其重点在于项目组存在设计能力很好的工程师。如果不存在这样的人,则设计审查的效果将显著地下降。但无论如何成立一个设计审查小组是很有意义的,它可以成为大家讨论设计和共同进步的一个平台。设计离不开编写一定的设计文档,设计文档采用Word的形式也就足够了,当然如果能适当地运用UML进行设计表达就更好了。另外,设计文档应当随着工作的进展而不断地被修订,在文档中增加修订历史记录显得很有必要。一方面能让文档的读者知道文档中的各部分是由谁修订的,当需要求助时也有人可找;另一方面,修订历史的存在也显得我们做事更加的专业。

  在接下来的编码(code)活动有很多方面需要考虑方法问题。第一个需要考虑的是源代码如何管理,在软件行业这被称之为软件配置管理(software configuration management)。源代码版本控制工具应当是开发团队不可或缺的工具之一,没有有效的源代码管理工具,想要做到多人同时进行有效的编码活动是不可思义的。源代码版本管理工具可选择的范围较多,不论是商业软件还是开源软件。作者认为在大多数的软件项目中,使用开源的版本管理工具足以应付日常的开发工作,象Subversion、Git和CVS都可以用作项目源代码版本管理工具。版本管理除了选择工具之外,更需要在项目内制定好代码版本的命名规则,可以说代码版本的命名规则也牵涉到了最终对外发行软件的版本问题。一个好的版本命名规则即能让开发工作更加有序,也能让外部人士看出项目的开发工作是否专业。对外发行的软件版本如果没有很专业的命名规则,很难让别人相信开发工作是有序的。

32/3<123>
《2023软件测试行业现状调查报告》独家发布~

精彩评论

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号