技术开发 频道

软件质量之路(1):软件质量框架

    软件质量框架的结构 

    上图表现了软件质量框架的结构。处于结构核心的是技术架构和管理架构。软件质量框架既不是方法学,也不是一个软件,更像是两者的结合体。技术架构和管理架构的融合体现了这一特性。软件质量框架并不关心单个开发人员的效率,它关注的是开发团队整体的效率。因此,管理架构在框架中的意义在于它定义了一套软件管理的方法,能够对开发人员及其他们的工作进行管理。从这一点来看,它的作用和软件工程方法学是一样的。但是,在现实中我们发现软件组织在迈向软件过程的途中往往因为现实的困难而止步不前。其中一个主要的原因是在引入方法学的过程中生产效率降低了,而引起组织成员对变革的怀疑和不满。

    所以,除了管理架构之外,软件质量框架还提供了一个技术架构,其目的是明确的定义如何应用组织中涉及的软件技术,以及管理软件技术的方法。技术架构是具体的代码,相比起方法学来说,它更加的具体,更容易为开发人员所理解。而技术架构存在的目的,一方面是进行技术积累,另一方面也是为管理架构服务。

    技术架构和管理架构的下一层是支撑框架。支撑框架包括代码、组件、文档,目的是为技术架构和管理架构提供底层的支持。

    处于结构最顶层的是业务架构。这个部分对于任何一个软件组织来说都是不同的,因为不同的软件组织的业务不同。业务架构的目的是对业务进行建模和抽象,提取出可重用的部分,以提高软件组织的生产率。本文中不涉及该部分的内容。

    软件质量框架的优秀实践

    一个开发团队要提高效率,就需要思考目前的管理活动中有哪些要素是可以改进的:如何把一些事务性的操作变得自动化,从而节约人力;如何找到更好的方法,让开发过程更为合理,更注重软件的质量;如何在团队中传播优秀的思想,让团队成员不断的学习和进取,自发的改进过程。这些美好的愿望几乎是所有方法论和各种认证的共同心声,但要完全做到可就太难了。在我们的文章中,提出了一些优秀的实践,优秀实践均是来源于软件开发界中的一些新思路和新理论,它们能够为以上愿望的达成起到正面的作用。在组织中引入用这些实践决不是一个容易的过程,但它们确实非常的有效。不论是在成本控制上,还是在质量的改进上。

    日创建:一个组织应当拥有一个有效的工作流程,这个工作流程能够指导软件开发的进行。这个流程应当是具体的、可操作的。随意的计划和从来不遵循的进度决不是一个有效的工作流程。日创建实践提出了一种对开发过程进行精细管理的方法,它是量化软件管理的基础。有了日创建,你会发现计划的制定和进度的监控是非常容易的一件事情。

    测试驱动开发:软件质量的根源来源于测试,测试做好了,软件质量就会好。这是毫无疑问的。问题的关键在于怎么做测试,才能保证测试的投入能够带来软件质量的有效提升。测试驱动开发正是为了解决这个问题而出现的。它不是一个完整的方法论,可以和任何一种开发流程进行融合。测试驱动开发不但能够改善测试效果,还能够改进软件的设计。

    建立核心框架:框架是一种具有高度重用性的软件,这个特性决定了它非常适合成为软件组织积累知识的一种有效手段。传统的知识积累的方法是文档,但是文档容易产生歧异,开发人员往往也不愿意去阅读和理解文档。框架提供的是一种综合的手段,包括文档、模型和代码。更容易理解,更重要的是,开发人员必须在日常的工作中使用框架,这使得他们对框架中的知识非常的熟悉,并根据工作的需要来改进框架。

    面向组件编程:有效的组织在于有效的分工。体力活动容易进行分工,脑力劳动则比较难,而软件开发似乎就更难了。所以,长久以来我们都习惯采用以功能块为单位的粗粒度划分方式。面向组件编程采用更加细密的划分方式,并以服务作为组件之间相互依赖的契约,不但定义了组件和组件之间的关系,也规定了组件开发者、组件使用者、组件测试者的权利和义务。从而能够进行软件开发工作的分配、管理、QA等工作。

    以上的几个优秀实践看起来似乎并没有多大的关系,他们的提出者也大都不同。但是有一点却是共同的,就是他们都能够对软件质量的改进起积极的作用。此外,他们为软件质量框架结构的实现提供了一个明确的实现方式。从软件结构的角度来看,日创建和测试驱动开发似乎偏向于管理架构,而建立核心框架和面向组件编程则偏向于技术架构。事实上,他们既包含了技术架构,也包含管理架构,彼此之间也有相互关联。例如,面向组件编程在合理划分组件之后,就需要一个有效的核心框架来集成组件,通过每个组件都需要采用测试驱动开发方法来保证质量,同时,日创建将会以组件为单位来进行每日的创建,从而为进度估算提供有效数据。

    随着软件设计技术的发展,新的实践将会出现,取代旧的实践。因此,以上的实践也会落伍,当可以肯定的是,以上的实践和具体的技术并没有直接的关系,更侧重于开发思想,因此他们的生命力会很长。而随着新技术的出现,他们更可能将新的技术融合如自身,呈现出一种崭新的形态。例如,未来的一种可能性是UML2.0和MDA技术的普及,以上的几个实践从以代码为核心转变为以设计为核心,而另一种可能性是随着以AspectJ为代表的AOP技术的普及和J2SE1.5中引入的元数据机制,面向组件编程将把Aspect作为组件的一种,而测试驱动开发也会加入测试Aspect的相关内容,在日创建中也会增加相应的处理AOP的步骤。

0
相关文章