安全代码开发：敏捷的牺牲者？

安全代码开发：敏捷的牺牲者？（5篇）

1.安全代码开发：敏捷的牺牲者？ 篇一

1 敏捷开发

敏捷开发是由15个科学家共同提出来的,其中包括来自思特沃克公司 ( Thought Works) 著名的软件大师马丁·福勒 ( Martin Fowler)[1]。敏捷开发即一种全新而快捷的软件开发模式,是把人放在第一位,以满足用户不同需求为导向的开发模式[2]。应用敏捷开发的方法,要求团队成员具有很强的主动性,满足了高内聚、松耦合的原则把项目分成了若干个小组。较少的文档准备和分组的新方式缩短了软件开发周期,开发过程中的多次迭代和测试提高了软件的质量[3]。

2 敏捷技术的重要性

从目前敏捷开发的研究现状中,我们可以看到在任何一个软件的开发过程中,任何的一种模式都不是能解决所有问题的万能钥匙,所以在软件开发过程中应全面考虑所有的问题,不管是开发方法、设计模式还是设计架构都是必须考虑的重要因素,而就目前敏捷开发的应用研究来看,敏捷开发的过程,对技术并没有明确的指导思想,这也正是多数项目在应用敏捷开发过程中失败的重要因素。

从根本来说,敏捷开发不仅是一个软件开发过程的方法论,准确地说它更是一种思想,但这种方法是建立在敏捷技术上的,敏捷技术为这一方法的实施提供了可行性,只有敏捷的技术才能支撑敏捷开发的实施[4]。真正的敏捷开发不只是管理层次的敏捷、项目参与人员的敏捷,架构的设计也应该是敏捷的,编程思想也应该是敏捷的,这才是实至名归的敏捷开发。在项目真正进行过程中,为了能更好地发挥敏捷开发的优势应做到管理与技术同步规范。管理与技术是不可分割的,二者相辅相成,技术的敏捷使得敏捷开发方法的实施具有一定可操作性,是敏捷开发方法的基石,如果没有相关技术的支持,敏捷开发是不能完全发挥效应的甚至是不可行的。只有做到管理与技术同步敏捷,在管理的过程中得到相应技术的支撑,敏捷开发方法才能发挥真正的敏捷,才是真正的敏捷思想。

2. 1 简单三层

敏捷开发方法要求在敏捷开发实施过程中,如何保证开发团队的每个开发人员能够独立地进行系统模块开发是敏捷开发能否成功的关键因素。而以往的传统开发技术,并没有将系统模块化,整个系统的耦合性较高,依赖性较强,使用传统的开发技术并不能实施敏捷开发方法,使得敏捷开发提倡的系统各模块之间并行开发成为空想。简单三层却为这一要求提供了可行性。

三层架构由底层至上层分为数据访问层 ( Data AccessLayer,DAL) ,业务逻辑层 ( Business Logic Layer,BLL) ,用户界面 ( User Interface,UI)[5]。简单三层将界面的呈现、业务逻辑的处理以及访问数据库很好的分离开来,因此在系统实现编码过程中不仅可以实现系统各模块的并行开发,而且不要求全能型的开发人员,只需精通其中一层即可参与到项目当中,在保证工作高效且代码质量的同时节约了开发成本[6]。在测试方面,三层也可同步进行,可以解决敏捷开发在测试环节中给项目带来的成本偏高问题,在支持敏捷开发实施的同时,又保证了整个系统的安全,降低了系统的复杂性,无形之中也提高了项目参与人员的积极性,使得敏捷开发能够顺利进行。

2.2 抽象工厂模式

敏捷开发提倡的是拥抱变化,要求在开发过程中进行多次的迭代,项目团队进行周期性的交流沟通,随时应对客户的需求变化,勇敢地面对变化,对于用户的反馈,程序员要有勇气对已经编写好的代码进行适当的修改[7]。敏捷开发里所说的勇于接受变化并不是简单的要求项目团队在客户提出新的要求时,就将之前的系统全部放弃,从头再来,这并不是真正意义上的敏捷开发。但是面对这样的需求敏捷开发只是单纯的提出了要求,并没有对此有进一步的说明和指导,而为了满足更换数据库的需求重新编译数据操作类就相当于项目从头开始,又不是最好的解决办法。如何在面对客户需求的时候,尽可能地减少代码的修改量,代码的复用性是一个关键因素。想要提高代码的复用性,就想到了设计模式,在当前的设计模式中,抽象工厂模式很好地解决了这一问题。

作为创建型模式的抽象工厂模式是23种设计模式中的一种,所谓创建型模式就是不需要自己实例化对象,而是由创建型模式来代替新操作[8]。抽象工厂模式指的是提供一个创建一系列相关或者相互依赖对象的接口,而不需要指定它具体的类[9]。该类设计模式是专门针对需求的变化来达到提高代码复用性目标的一种模式,它就相当于一个实实在在的工厂,只不过与我们现实生活中的工厂不同的是现实生活中的工厂是用来生产产品,但是这里的工厂是用来管理变化的。

使用抽象工厂模式将可变的进行封装,以接口的形式呈现,在三层中应用抽象工厂模式,在不需要修改以前代码的前提下轻松地解决了更换数据库类型这一需求,并且在系统开发完成之后甚至是使用过程中,都可轻松地更换数据库类型,有效地解决了由于需求变化导致开发周期延长,并且为系统的后期维护降低了成本。

2.3 ASP. Net MVC

客户的需求贯穿于整个项目中,虽然敏捷开发中采取先测试再编码的方式有效地应对了客户需求的变化,但是并不排除客户对测试满意,开发完成之后又提出了新要求的可能性存在。对于大多数客户来说需求的变化主要体现在系统功能和界面展示方面,针对这一可能性传统的敏捷开发并没有很好的解决办法,只能重新编写,重新测试,但是这一问题是周而复始的,这样的做法治标不治本。应对这一状况就应考虑到从技术方面入手。

在通常情况下,系统的页面开发都是用网页表格( Web Form) 进行,虽然网页表格 ( Web Form) 操作简单,可以直接拖控件对页面完成布局工作,但是它的页面展示与后台逻辑代码的耦合度较高,在遇到客户对页面布局要求变更的时候,不仅要进行页面布局的修改,还要将相应的页面逻辑进行修改,这无疑多做了很多没有必要的工作,这时ASP. Net MVC框架成了解决这一问题的第一选择。

ASP. Net MVC是微软在2009年对外公开发布的第一个开源的表示层框架[10]。ASP. Net MVC模式是一种表现模式,它可以将 表现层分 成模型 ( Model ) 、控制器( Controller) 和视图 ( View) 三个组件,有效地分离了页面展示与用户界面 ( UI) 逻辑代码,所以ASP. Net MVC是一个更加倾向于用户界面层 ( UI) 的表现层框架,是网页表格 ( Web Form) 的另一种选择[11]。在面对客户对页面展示需求变化的时候,只需更改相应页面的展示效果即可。

3 敏捷技术应用实例

3. 1 项目简介

本校的博士研究生招生工作在2013年之前均是通过工作人员手工的录入以及核对完成的,因此,本校博士招生工作存在效率低下,管理无序,数据安全性较差等诸多问题,实施办公自动化对于我校的博士招生工作具有重大意义。本项目将采用本文所提及的融合敏捷技术的敏捷开发方法对系统进行开发。

3.2 敏捷技术在开发中的具体应用与实现

根据上述分析,博士研究生招生系统的整体架构见下图。

从上图中我们可以看到,本系统结合了简单三层架构、抽象工厂设计模式和ASP. Net MVC框架三大技术,本系统使用2011年发布的ASP. Net MVC3. 0版本[12]。本论文主要从这三个技术的应用上进行详细论述,来论证敏捷技术对敏捷开发的重要性。

3. 2. 1 抽象工厂模式在数据访问层的应用

对于本系统的开发主要是针对学生各种信息的管理与操作,并且录取的学生信息数据库要与我校现有的各种学生工作系统进行衔接,而所用数据库并不相同,对现在已经使用的系统进行修改并不是一个好办法,只有针对目前着手开发的博士研究生招生系统进行完善,来迎合不同数据库的需求。解决这一需求的办法就是抽象工厂模式。本文以考生登录功能为例进行技术应用说明。

创建抽象工厂类,利用 . Net的反射机制获取数据访问层的程序集和命名空间的名称,通过数据访问接口层来创建user_ infor数据表的实体类,并采用缓存技术来提高系统性能,设置当前应用程序指定Cache Key的Cache值的核心代码如下:

由于数据访问层融合了抽象工厂设计模式的思想,所以业务逻辑层调用数据访问层是通过数据访问接口层创建相对应的数据工厂实例,并没有指定具体的数据操作类,因此,在面对更改数据库类型时,只需修改配置文件的程序集和命名空间的Value值即可,配置文件代码如下:

由此可见,应用了抽象工厂模式和反射机制加上配置文件的使用,在不需要修改系统代码的前提下轻松实现了异库移植操作,并且为本项目实施敏捷开发时适应了需求且缩短了开发周期。

3. 2. 2 ASP. Net MVC 框架的应用

在ASP. Net MVC中UI逻辑在Controller组件中进行编译,Controller负责将数据从Model取出传递给View[13]。在本系统里,ASP. Net MVC代替网页表格 ( Web Form)作为三层中的用户界面层 ( UI) ,所以在界面展示编译中,ASP. Net MVC框架中的控制器 ( Controller) 组件则负责与业务逻辑层进行对话,从业务逻辑层调用校验用户的方法来获取数据库中的考生登陆信息。判断登陆是否成功的部分代码如下:

前台的页面布局交由视图 ( View) 组件负责,由于它与控制器 ( Controller) 组件的低耦合性,视图 ( View)的页面展示只需单纯的Html标签即可实现,并且不需要将标签ID传到后台,实现了UI展示与UI逻辑的彻底分离。登录页面的视图 ( View) 核心代码如下所示:

从以上代码我们可以看出,视图 ( View) 页面都是由Html标签实现,所以在更换页面布局的时候就不需要考虑前台标签与后台逻辑的绑定问题,不需要修改用户界面 ( UI) 逻辑代码。

4 结 论

2.面向敏捷开发的软件测试技术 篇二

典型的传统测试包括V模型,W模型,H模型等,以V模型为例,如图1所示,测试发生在开发之后的一个阶段,测试过程与开发过程相对应。

测试的过程即为计划测试→设计测试→实现测试→执行测试,通过迭代实现整个测试流程,在测试过程中,传统测试要求流程规范,文档齐全,根据软件需求总结、测试所有的功能点,直到软件没有大的bug。在传统V模型测试过程中,需求、 功能、设计和编码的开发活动随时间而进行,而相应的测试活动即针对需求、功能、设计和编码的测试,开展的次序却正好相反,可以看到,底层代码设计最后被开发却最先被执行,反之, 软件设计过程中的需求是最早开发,相应的验收测试到最后进行。如此,往往需求阶段隐藏的错误会一直到最后验收测试时才被发现,导致整个软件开发测试过程需要推倒重来,极大影响软件生产效率。相较而言,由Evolutif公司提出的W模型更科学,可以看作是V模型的改进版,在软件开发的每个阶段都进行测试,能更早的发现软件问题,软件测试W模型如图2所示,但是W模型软件测试仍然需要与软件开发保持顺序关系, 只有在上一个阶段的开发任务完成之后才能进行下一个阶段的测试任务,无法支持敏捷开发这种需要高度迭代的软件开发模型。

2敏捷测试

2.1敏捷测试的定义

敏捷测试没有明确定义,不能简单理解为更快的测试或者使用更少的资源(时间,物力)来实现相同的测试任务,一般而言,敏捷测试伴随于敏捷开发,2001年2月,17位当时被称之为轻量级方法学家编写和签署敏捷宣言(Agile Manifesto, Beck et al.)正是标志着敏捷方法的开始,随后适应市场需求的敏捷开发越来越流行,随之而来,敏捷开发中的测试问题也被逐渐重视起来,如果只是将过去的传统测试方法生硬地应用于敏捷开发,由于敏捷开发的短周期,高迭代的特性,测试工作将几近无法正常进行,并且传统测试与开发保持的顺行关系将不能发挥测试应有的作用。敏捷测试就是改变传统测试方法,适应敏捷开发,对传统测试进行裁剪和增加而采用的新的测试流程,敏捷测试针对敏捷开发过程中迭代产生的新功能进行不断验证测试,同时对原有功能进行回归测试。如图3所示,在敏捷中, 需要尽早测试,强调要能够及时、持续地对软件的质量问题进行回归反馈。

2.2敏捷测试的特点

1)支持变化,因为敏捷开发的特点就是高度迭代,根据客户提出的新的需求不断将产品开发推向更正确的发展方向,在这个过程中就要求测试也能够不断对软件新的变化做出验证。

2)拥抱客户参与,客户代表作为团队中最了解业务的人将帮助开发团队快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务方面他们需要客户代表的帮助[3],同时测试团队积极与客户沟通,了解客户需求,在测试过程中有更好的针对性。

3)“一张纸测试”,敏捷测试以提高生产率为目标,强调快速迭代,高质量产出,因此传统测试过程中的严格文档要求在敏捷测试中不作要求,测试人员与开发人员、客户密切沟通,崇尚“一张纸”测试计划,对传统的测试流程进行裁剪,减少测试计划、测试用例设计等工作的比重,增加与产品设计人员、测试人员、客户的交流。

4)提倡自动化测试,敏捷测试中每次迭代后都需要对原有功能进行回归测试,对新增加的功能进行验证测试,鉴于敏捷开发的高迭代性特点,敏捷测试的工作量很大,这就要求敏捷测试积极拥抱自动化测试,尽量减少开发过程中高迭代部分回归测试部分的测试时间,重复部分测试应尽量用自动化测试实现。

在敏捷测试流程中,测试人员需要参与单元测试,关注持续迭代的新功能,针对这些功能进行足够的验收测试,原有功能的回归测试则更多地用自动化测试来实现。以后与敏捷方法中迭代周期短,测试人员尽早开始测试,包括及时对需求、开发设计的品神,更重要的是能够及时、持续的对软件品质进行反馈,简单地说,敏捷测试就是持续地对软件质量问题进行及时的反馈。从确认客户需求开始,测试就开始进行,测试用例的设计、测试计划、测试执行,测试贯穿软件开发的整个流程。

2.3测试自动化

在敏捷测试中,使用自动化测试是必不可少的内容,在敏捷开发中,会有新的功能在每次迭代中不断被开发出来,这些新的功能属于必须充分测试的部分,同时,为了保证迭代软件产品本身的质量,确保在增加软件新功能的时候没有对原有软件产品造成破坏,还需要对软件产品进行综合测试,迭代频率越高,所需消耗的测试资源越多,而测试资源中的测试时间、测试人力和物力都是有限的,不可能一直全面地测试到软件的所有方面,自动化测试是保证不断迭代后继续保持软件质量不可缺少的途径。在敏捷项目的早期阶段因为进度和方案的变更开展自动化测试通常是很困难的,但是到后期迭代时,前期的用户故事已经稳定下来,测试人员就可以在前期手动的基础实现自动化测试。

自动化测试为迭代的回归测试提供服务,提高了回归测试的效率和质量,节约了大量的时间,在敏捷测试模型中,它归于系统综合测试阶段,能有有效保证迭代版本的质量和稳定性。

2.4典型敏捷测试的流程

敏捷测试主要包括两个部分:确认测试和综合测试,典型敏捷测试的流程可以用图4来表示。

确认测试是对迭代出软件新的功能的有效性进行确认验证[4],测试人员根据迭代之前制定的需求和计划对新发布的软件增加的功能开发出充分的测试用例,对其高优先级输出的部分进行充分测试,及时纠正新发布软件的错误,保证迭代版本软件质量。确认测试要做到持续测试,一旦某块新代码完成就可以对该块新代码进行测试,以使测试效率最大化。

综合测试是对确认测试的补充,包含完整的功能测试,测试人员完成对软件的确认测试后对软件进行补充测试,完成迭代软件的综合测试,证明迭代软件的稳定性和正确性以使软件产品完善的进入下一迭代流程。

典型敏捷测试存在的不足在于,本次迭代周期包含前一次迭代测试的综合测试部分,第N次迭代的综合测试发生在第N+1个周期,主观性地认为前一次迭代测试的综合测试不会出现较大的软件问题,而敏捷开发的高迭代性要求不允许出现等待,因此敏捷开发团队不会等待第N次迭代软件综合测试完全结束后才进行下一周期(N+1)的开发,这就增加了开发风险,同时本周期迭代的软件产品在下一周期才得到测试,影响测试效果。

2.5敏捷增量测试模型

为了改进典型敏捷测试模型的缺点,使敏捷团队能够及时解决当前迭代周期的问题,可以将典型敏捷测试的测试过程扩充为三个部分:确认测试,验证测试以及集成测试。

在改进型敏捷测试过程中,确认测试和综合测试都放在当前的迭代周期内完成,减少软件开发风险,增加集成测试则可以使测试人员对之前迭代周期的软件产品进行小范围内的集成测试,替代原敏捷测试模型中的对前一迭代周期进行综合测试的部分,不同的是,这里的集成测试只需及时记录下测试接口错误以及其他的集成环境错误,并不被定义为当前迭代周期内的测试任务,只是适应敏捷开发的“等待性任务”,所以测试人员以当前迭代周期内的测试计划为主,当能开始本次迭代周期内的工作时,可以随时停止集成测试工作,并且对迭代周期内的集成测试不要求测试人员对发现的错误立刻响应,但是要求测试人员对错误信息作详细记录,便于提高集成测试环节的效率[5]。

3总结

本文就时下流行的敏捷开发模式探讨了传统测试在敏捷应用中的不足,系统介绍了敏捷测试的特点及流程,并提出增量敏捷测试模型和具体测试方法,经实践证明,与传统的测试模型相比,能更早的发现并清除软件bug,在保证了软件产品质量的同时很大程度提高了软件产品的生产效率。

摘要：近年来,随着信息技术的迅猛发展,快速变化的市场对软件产品的生命流程提出了更新更高的要求:一方面要求新的软件产品能尽快发布以抢占市场,另一方面要求软件产品能够快速变更来保持市场占有率,崇尚生产率的敏捷方法学应运而生,敏捷方法学强调以提高生产率为目标,推崇通过周期性的高度迭代来保证软件产品的能力和质量,得到越来越多的应用。

3.基于看板管理方法的敏捷软件开发 篇三

软件开发项目管理从最早的传统项目管理软件工程期到近年的迭代模型时期,最后到目前的敏捷软件开发时期。敏捷软件开发的成功五项因素分别如下。

(1)建立自组织团队。传统的管理方式具有命令和控制的特点,经理制定目标和计划,团队负责完成,发挥不出员工的创造力,影响了企业的效率。软件开发的敏捷开发要求员工自我管理,个人控制时间和目标,员工能参与流程和项目决策。

(2)用户故事在需求管理中的应用。软件开发企业最大的敌人不是用户,而是变化。瀑布模型难以适应目前软件市场需要,因此软件开发工作要取得用户的参与,顺应市场的变化。

(3)用户故事的度量,它能为产品投资收益提供估计结果,辅助产品决策。对故事点大小讨论时,能鼓励团队成员重复讨论,充分理解需求。故事点度量方式一致,提高统计团队工作效率。

(4)持续集成。它能提高项目构建自动化程度,将人力成本更多投放到开发任务。项目更有可见性,构建结果更加丰富,一目了然。团队对开发产品更有信息。

(5)掌握迭代,为员工提供稳定的生活节奏,保持一致的周期循环流程,沟通过程中控制时间。

(6)坚持反馈和改进,了解自身情况,改善团队效率。

精益生产的目标为提高质量和消除消费。看板原则要求生产降低库存量、降低生产周期、生产基于交叉培训和单元并对过程进行持续改善。如同超市进货一样,当货架上货物少于设定值,供货商会及时将其填满。将看板管理与敏捷软件开发结合起来,能够达到效率和质量的有效结合,软件产品周期频繁,能达到按天发布级别。

2 RCOM项目看板方法流程设计

增量迭代开发开发流程存在着三点问题。

(1)每个迭代的用户故事较多,产品经理和开发工程师认为很多功能没有价值,而项目经理认为需要跟踪的项目较多。

(2)对于为期四周的迭代观念不统一,部门不同,期望值不同,测试人员认为时间不充分,产品经理认为需要等待太长时间。

(3)部门之间缺乏协作,缺乏透明的项目进展和进度,太多时间花费在流程上。敏捷软件开发有三个典型流程,分别XP、Scrum及看板,经过比较,看板原则可以解决迭代用户故事较多的情况,对于规模小及优先级别高的用户故事能够迅速完成,并满足产品经理对产品的预期。

2.1基于看板管理的敏捷软件开发流程方案设计

看板一般应用于汽车生产等工业领域中,在敏捷软件开发中看板管理只是理论上行得

通,但是在实际上还缺乏经验。而且其受到产品特点、客户差异及企业文化的影响。其流程主要为,

(1)定义并可视化流程。

(2)限制WIP数量,流程可视化于物理板能够让项目透明,让团队对目前的任务充分明确。限制WIP数量则能让团队在思考时排除干扰,提高个体效率,项目工作不以来时间计划,而是取决团队能力。

(3)拉动式生产,每个团队成员只需要对自己环节加以关注,等待任务-完成工作-到下一环节等待区。这种方式推动了产品开发前进步伐。

2.2看板流程准备和实施

(1)是动员和人员培训,先获取领导层的理解和信任,再向所有员工培训敏捷开发和看板方法,最后,每个部门进行讨论。

(2)制定需求管理环节,产品经理提出产品需求,创建用户故事,技术团队估算用户故事工作量。通过需求分析,工程师能够获取信息,完成研发工作,产品经理全程辅助开发和测试,解答相关问题。

(3)开发流程改造,主要变化在对程序代码的管理方式进行改变,主要有主干和分支两种。

(4)测试流程改造,主要表现为两个方面,一方面提高系统自动化测试率来加快回归测试的进度,另一方面增加测试环境满足功能测试需求。

(5)项目管理流程的建立。

2.3看板流程的实施

当所有准备工作完成之后,看板方法第36增量迭代之后,可以正式实施。产品经理将用户故事进行排列再制成任务卡,贴在用户故事一列,完成需求分析会议。开发组建立功能分支进行开发,测试组应用功能测试环境对用户故事进行测试,直到产品发布。团队成员每天早上聚集看板附近,明确自己的任务,下班前,项目经理将每天的任务卡状态变化汇总。敏捷流程要求强调团队自组织和员工自我管理,但是不可忽视项目经理的作用,项目经理能够组织人员,梳理工作节奏,保证沟通流畅,促进项目进展。

3看板方法效果分析

在对用户故事完成效率统计,并对超时任务进行反思和改进之后,回顾看板流程管理经验,总结建立自组织团队时,应该考虑建立流程、理顺沟通方式、改善管理风格、制定度量标准四个方面问题。从看板流程团队角色视角分析,就项目经理来说,虽然团队沟通节奏加快,但是需要针对需求变更的灵活、用户故事的调整,适应变化和跟踪进度。就企业运营角度来看,看板流程比增量迭代开发,能实现商业价值,流程改造增加来了沟通,工作更透明、工程师时间自由,优势大于劣势,是一个成功的尝试。

摘要：随着互联网技术以及信息技术的发展,我国的软件市场逐渐庞大,企业为了在软件市场中取得一席之地,必须要促进软件生产的效率、降低软件缺陷和生产成本。本文立足于敏捷软件开发和精益开发方法,研究了看板方法在敏捷软件开发中的作用,得出看板方法敏捷实践可以培养团队、兼顾流程效率及团队成员的自我管理的需要,希望具有借鉴意义。

关键词：看板管理方法,敏捷软件,软件开发,精益生产

参考文献

[1]匡松,周启海,陈森玲等.敏捷软件开发的认识偏误与推广瓶颈浅析[J].计算机科学,2007,34(12):294-295,303.

[2]徐照兴,杨水华.敏捷软件开发过程中重构技术的研究[J].煤炭技术,2012,31(11):223-225.

[3]芮雄健,王忠民.基于敏捷软件开发方法的基金管理信息系统开发[J].计算机应用,2004,24(11):162-165.

[4]夏显鄂,梁洪峻.敏捷软件开发与计划驱动开发的概述比较[J].计算机工程与设计,2007,28(16):4035-4037,4062.

4.安全代码开发：敏捷的牺牲者？ 篇四

在国防信息化程度的不断提高的今天, 军事领域中的软件产品已经成为了和硬件产品比肩而立的重要存在, 军用软件的质量高低也成为了决定军事和武器系统质量的关键因素。随着武器装备系统中的软件规模迎来爆炸式增长, 只有对过程质量的全面控制, 才有可能最大程度的降低风险, 提高软件产品质量。我单位从2011年开始试推行GJB5000A软件研制过程管理, 到如今已实现了军用软件研制能力二级管理的全面覆盖, 期间为兼顾不同专业领域、不同项目类型、不同规模和军兵种的要求, 对体系进行了持续改进。改进焦点在执行GJB5000A标准的大框架下尽可能解决特异性问题上, 同时在开发方法及操作层面上鼓励项目组团队在现有质量体系策略要求下进行创新式探索。其中利用敏捷开发的方法与GJB5000A管理体系的融合就是一种有益思考。

二、GJB5000A质量管理体系结合敏捷方法在科研院所的适应性

2.1 GJB5000A在科研院所的落地实施

GJB5000A-2008《军用软件研制能力成熟度模型》作为框架模型, 体现了业内软件研制过程最佳实践集, 其采用分级表示的方法, 按预先确定的过程域来定义组织的改进路径, 同时规定了软件研制和维护活动中的主要软件管理过程和工程过程的实践。模型五个级别中共定义了22个过程域, 每个过程域由不同个数的专用目标和相同个数的共用目标组成, 每个目标又推荐了不同的实践。在GJB5000A的定义中, 目标是必需的部件, 实践是期望的部件, 我们用满足所有目标来确定过程域的实现, 用实践来指导过程改进和评估。换句话说, GJB5000A标准允许我们用规定的实践或可接受的替代实践来满足目标。所以科研院所要想真正实现标准落地就必须按照单位自身产品特点和用户要求将实践本地化。

在实现本地化过程中, 组织会按照大多数项目的模式定义标准过程, 但却无法确保所有过程适用于所有项目, 同时在执行自由度上也遇到了很大困扰, 强约束导致了项目缺乏灵活性, 而降低约束度则可能带来质量和进度的双重风险。此外, 即使组织开放了项目组利用替代实践实现目标, 但由于团队人员的经验不足, 也很难找到恰当的替代实践, 组织还必须承担面对评估时替代实践有效性的质疑, 所以在组织层面上定义多种开发方法供项目选择就显得尤为重要。

2.2敏捷开发方法在军用软件研制过程中的适用性

软件敏捷开发是一种相对于传统软件开发而言的轻型开发方法, 它改变了传统开发中以文档为驱动的开发模式, 以人为主要驱动核心, 目前常用的基本敏捷实践方法有很多, 如极限编程 (XP) 、Scrum方法、特征驱动开发 (FDD) 等, 每种方法的实践过程都有不同, 但基础都是基于增量和迭代的过程。软件敏捷开发有四大价值观:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。这些特点使得敏捷开发方法灵活、适用多变需求, 可快速交付, 但应用在军用软件研制过程中可能会带来以下问题:1、敏捷开发方法应用的是需求的快速迭代, 每一个迭代作为一个计划阶段, 很难对项目的整体目标有完整计划。2、敏捷开发方法更注重有效代码的快速交付, 而非文档, 这对有严格军标约束下的文档编制提出了更高的要求。3、敏捷开发最重要的开发方式是与客户一起开发, 因军用软件的需方往往是部队使用方, 面对面开发的形式较难实现。4、敏捷开发方法对开发人员的能力要求极高, 人员要不但要精通设计、编码、测试相关工作, 而且要能参与项目的需求分析和架构设计, 能对频繁变更的需求做出快速响应。

既然敏捷方法会带来以上问题, 我们为何还要考虑在军用软件承研单位引入敏捷开发过程呢?这是因为随着军用软件研制领域中引入的竞争机制, 出现了越来越多需要直接进行代码交付的PK项目, 如果再应用传统研发方式, 就失去了市场竞争优势。所以, 对于规模小、周期短、需求变动频繁、现场开发为主要形式且已经具备了较稳定的开发技术架构的项目而言, 敏捷开发方法既能让项目组在短时间内针对需求拿出有效代码, 而且在快速迭代中能总结大量有用的文档信息。只要我们可以偏重组建成员技术水平在同一层面上的成熟开发团队来承接这样的项目, 必然起到事半功倍的效果。

三、GJB5000A质量管理体系下的敏捷开发方法实施

3.1用敏捷开发方法定义过程

在组织级, GJB5000A三级过程域中的组织过程定义 (OPD) 可以帮助组织建立起自己的敏捷开发方法下的过程定义, 包括过程和过程元素的说明, 过程剪裁指南, 敏捷开发方法下的生命周期, 标准工作环境、组织测量库、组织资产库等。有了组织级定义, 项目组就可以按照集成项目管理 (IPM) 实现方法对组织标准过程进行剪裁, 形成项目的已定义过程 (P’DP) , 这个过程就可以直接指导项目的过程实施。从项目级的角度看, GJB5000A的过程管理关注的是项目做了什么, 而敏捷开发方法正是提供了该怎么做的具体开发方法, 敏捷开发方法中的活动经过合理替代和剪裁的实践方法以实现GJB5000A目标是完全可行的。

3.2敏捷开发方法实践

1. 实践方法的选择。

在敏捷开发的众多方法中, 我们选择了以Scrum为基本敏捷实践, 以持续集成 (CI) 和测试驱动开发 (TDD) 为扩展方法的敏捷开发架构。Scrum方法是敏捷开发中最典型的模型框架, 它把产品需求的实现分为若干个Sprint来完成, 每个Sprint完成后进行产品演示, 收集、细化直至实现用户需求, 整个过程为一个迭代式增量过程。持续集成提倡利用一个全自动的过程, 在一天中根据代码变化进行多次构建 (包括编译、发布和自动化测试) 来验证集成结果和发现集成错误。测试驱动开发技术 (TDD) 基本原理是在开发功能代码之前, 先编写单元测试用例代码是持续集成的验证手段。

2. 项目定义过程。

Scrum结合CI与TDD的过程可以简单描述为:一开始先由项目负责人确定一个Product Backlog (产品需求列表) , 而后召集项目团队召开Sprint计划会议对列表中的需求进行工作量预估和安排, 从中挑选出一个story作为本次迭代完成的目标, 形成Sprint Backlog (迭代需求列表) 分配给项目组成员, 每个成员接收到任务后将任务进一步细化, 在每日例会上汇报自己的完成情况和对下一步工作作出承诺, 同时在公示板上标注出自己的工作情况 (燃尽图法等方法) 。每个项目组成员对工作进行每日集成, 集成后利用测试驱动开发构建测试来快速评估集成结果, 如果发现问题马上修改, 再次集成测试, 反复循环, 直到一个迭代结束形成可用的代码。

3. 用GJB5000A过程管理敏捷开发方法下的研制。

从项目层面看, Scrum方法可以结合GJB5000A过程域中的需求开发, 项目策划、项目监控等, CI与TDD可以结合产品集成、配置管理等, 当敏捷开发的方法在GJB5000A的过程管理方法约束下, 可以得到更精确的控制和工作产品反馈。下表我们就给出了部分实践的实施方案。

四、总结

GJB5000A体系结合敏捷开发方法有别于传统研制方法中以文档为驱动的顺序研制过程, 它充分强调了消除冗余、减少返工、缩短周期, 提高效率的理念, 同时用过程记录的方法收集重要的项目信息, 可以在一轮迭代完成后一次输出成可用的文档和经过测试的可交付代码。于项目而言, 这种研制方式给项目提供了更多的灵活性选择。于组织而言, 因总装备部和军标的强制要求, 承研军用软件的单位必须要在GJB5000A及相关配套军标的要求下建立质量管理体系和规范项目研制过程。通过合理剪裁那些能提高产品质量、提高生产率的方法和模型后, 通过验证和确认方法形成组织标准过程, 必然能增强组织标准框架的适应性和实用性, 提升组织管理能力目标。

参考文献

[1]GJB5000A-2008军用软件研制能力成熟度模型[S].

[2]Mike Cohn.Scrum敏捷软件开发[M].北京:清华大学出版社, 2010.

[3]石柱.军用软件研制能力成熟度模型及其应用[M].北京:中国标准出版社, 2009.

5.安全代码开发：敏捷的牺牲者？ 篇五

关键词：敏捷化开发,装配设计,整体技术方案,项目管理,系统原型

0 引言

现代科技以日新月异的速度发展,新产品层出不穷,但产品的市场寿命大大缩短。顺应客户需求的变化,迅速做出反应,已经成为企业制胜的法宝。另一方面用户需求的多样化和个性化已逐渐成为世界的潮流,如何将新产品以最短的时间、最高的质量、最低的成本推向市场成为了市场竞争的焦点。据统计:产品设计直接影响产品的整个生命周期,整个生命周期约85%的费用由产品开发阶段所决定,而这一阶段本身所需费用则仅占总费用的5%[1];另一方面,在产品生产阶段,有1/3以上的人直接或间接从事与装配有关的活动,装配费用占整个生产成本的30～50%[2]。因此需要一种面向敏捷化开发的产品装配设计系统,为用户提供智能辅助支持,以便能快速响应市场变化和客户的多样化要求。

本文进行了敏捷化开发环境下产品装配系统的需求分析,建立了“以装配建模为中心,以系列化和可装配性为两个实现目标,以敏捷化为最终表现形式”的系统整体技术方案,有效地支持了产品的模块化设计、面向装配的设计和自顶向下的设计方法;构建了敏捷化开发环境下产品装配设计系统的体系结构和企业应用集成框架,有效地支持了并行工程的流程管理方式及虚拟企业的运作方式;最后基于上述思想开发了敏捷产品装配设计系统的原型,并实现了预定的初步功能。

1 系统的需求分析

敏捷化开发环境下产品装配设计系统不但是各装配设计模块协同运作完成产品装配模型、实现信息共享、互相评价的基础,同时也是体现并行设计理念,将传统设计方法中“设计-制造-再设计”的大循环分解为设计环节中的若干个小循环,在每一个微循环内进行“设计-评价-再设计”的基础[3]。总的来说,它的特点主要体现在以下几个方面:

(1)能支持自顶向下的设计方法。在敏捷化开发环境下,产品装配设计系统应能提供和人类专家设计思维相一致的设计方法,即在设计产品时,最初考虑的是产品应实现的功能,然后考虑实现这些功能的几何结构,最后才进行零件的详细设计。这种自顶向下的渐进设计方法不仅能将关键设计约束传递到后续设计阶段,同时也便于实现多个子系统的协同,实现并行设计。因此装配设计系统必须能支持自顶向下的设计方法。另外系统还必须满足用户的多样性要求以及可装配性要求,因此在设计过程中还应融入模块化设计和面向装配设计的理念。

(2)能够提供智能辅助规划分析工具。产品的装配设计是一个复杂动态模糊过程,设计过程中有许多NP难题,另一方面设计人员由于受个人经验知识以及其考虑问题的全面性和正确性等的限制,凭个人能力很难直接得到最优设计。因此装配设计系统必须提供智能辅助规划分析工具辅助设计人员进行各类规划分析,不仅可以提高设计效率,还能提高装配设计质量,降低装配设计成本。

(3)能支持分布、并行、协同工作方式,同时系统也要具有开放性、可重用性。由于产品异地协同设计和制造、敏捷制造技术、虚拟制造技术等先进的制造模式和技术已经逐渐成为制造工程界研究和应用的热点和重点,从长远来看,就要求系统能支持分布、并行、协同工作方式,使分布在不同地点、不同部门、不同专业背景的人员可以协同工作,交流和共享信息。另外,装配设计系统还必须考虑与其它应用系统的集成问题,这就要求系统要具有良好的开放性和重用性。

上述的几个特点分别从不同的侧面对敏捷化开发环境下产品装配设计系统提出了要求,“支持自顶向下的设计方法”从方法论上对装配设计系统提出要求,它是系统工作的主流程;“能提供智能辅助规划分析工具”是装配设计系统的目的,通过提供智能辅助工具,系统能够协助用户或技术人员更快更好地进行装配设计;“能支持分布、并行、协同工作方式,同时也要具有开放性、可重用性”一方面从系统的组织方式上对装配设计系统提出了要求,因为系统采用的是敏捷制造的组织方式(虚拟企业)和并行工程流程管理的思想进行产品设计;另一方面也对软件编制提出了要求,要求站在发展的角度看问题,设计标准高,理念先进。

2 系统的整体技术方案

敏捷化开发环境下产品装配设计的整体技术方案是以面向产品族的装配建模为中心,以系列化和可装配性为两个实现目标,以敏捷化为最终表现形式[4]。

(1)系列化这条线主要是通过需求分析形成设计需求表,确定产品的总功能并进行功能分解,进而进行产品的模块划分,寻求各功能单元的原理解答形成产品的初步设计方案,并以此为基础进行产品结构设计、详细设计和装配模型重建实现面向产品族的装配模型。在这一过程中产品的模块划分和装配建模是其中的两个重要关键技术,模块划分是实现系列化的前提和基础,它为产品系列化变型设计指引方向,装配建模则是系列化实现的具体过程和最终载体,它通过贯彻模块划分思想来实现产品的模块化设计(既可以有针对性地简化各模块之间的接口,又可以按划分的模块建立各子模块的参数化模型方便产品进行系列变型设计。)。

(2)可装配性这条线从产品设计方案的评价完成以后,始终与面向产品族的装配建模过程相呼应,在结构设计、详细设计阶段分别对产品的结构和零件进行可装配性分析,并在装配模型重建阶段进行产品的装配序列规划、优化、仿真及可装配性评估,以保证最终产品的可装配性。在这一过程中装配建模、装配序列规划、可装配性分析是其中的3个重要关键技术。装配建模既是实现可装配性的前提和基础,也是实现可装配性的最终载体,它为序列规划和可装配性分析提供基础规划和评价信息;序列规划和可装配性分析则是可装配性的具体实现过程和保障,它通过对装配模型进行规划、仿真和评估反馈设计不足和改进意见,促使装配模型始终向可装配方向发展。

(3)装配模型重建阶段是系列化和可装配性的最终实现阶段,在这一过程中装配模型中的约束关模型、参数化模型、层次结构模型因为模型重建而最终形成,可装配评价的结果也因模型重建而得到验证。

敏捷化开发环境下产品装配设计的整体技术方案如图1所示,它将模块化设计、面向装配的设计和自顶向下的设计方法融为一体,既支持产品从概念设计到详细设计的逐步求精过程,自动将设计意图和装配约束向下游传递,同时又将系列化和可装配性两个实现目标蕴藏其中,做到设计方法始终为设定目标服务;另一方面整体技术方案也体现了并行工程的流程管理思想,虽然系列化这条线率先开始,但并不是说可装配性这条线要等到前者完成之后才开始进行,二条线在完成的过程中有相当的并行和重叠(装配建模的同时,分阶段进行可装配性评估,实现设计-评价-再设计的微循环工作方式),相互配合、相互促进、相互补充,最终实现敏捷化产品开发。

3 基于项目管理监控的系统体系结构

根据系统的整体技术方案思想,现将敏捷化开发环境下产品装配设计系统的体系结构分为:界面层、控制层、应用层、数据层及支撑层5层(如图2)。系统体系结构支持分布、并行、协同工作方式,各层的功能如下:

(1)界面层:是用户与系统交互的接口,主要由输入界面和输出界面2部分组成。输入界面用于接受用户的输入(可以是文本、图形、超文本等形式),响应用户的鼠标与键盘事件。输出界面用于将应用层的处理结果以图形化方式或者对话交互形式反馈给用户。将界面层与应用层分离有利于系统的部署和在分布式网络中应用。

(2)控制层:是调度和监控系统协调有序运行的核心,主要包括设计过程监控和网络安全监控2部分。它以项目管理(Project Management,PM)的方式对装配设计工作(包括分布式网络中的协同工作)进行规划、管理和监控,使不同地点、不同部门、不同专业背景的人员可以协同进行设计信息的交流和共享,共同完成产品装配设计的流程。

(3)应用层:是敏捷化开发环境下产品装配设计系统的核心部分,主要分为系统应用和辅助工具2个方面,系统应用包括需求分析、功能分解、模块划分、方案设计、装配建模、装配序列规划、可装配性分析评价等应用技术,其中模块划分、装配建模、序列规划、可装配性分析是敏捷化装配设计系统的主要关键技术。辅助工具主要包括装配仿真工具、各类支持算法、参数化设计工具等等,其中装配仿真工具可对装配模型进行静态、动态以及运动干涉检验和仿真,发现设计过程中的不足之处,同时通过动态干涉检验还可以获取装配体在±X、±Y、±Z等方向的装配干涉矩阵以及装配体的接触联接矩阵等信息。

(4)数据层:用于存取、生成、维护和管理系统运行过程中的各种过程信息和结果信息,主要包括用户需求信息、功能单元信息、模块划分信息、装配语义信息、产品层次结构信息、装配模型信息、装配资源信息、装配过程信息、可装配性评价信息等等。其中装配模型信息是敏捷化开发环境下产品装配设计系统组织和实现的核心和关键信息。

(5)支撑层:调度分配系统的内存资源,支持系统的正常运行和网络应用,为敏捷化产品装配设计系统提供基本的网络通信和安全支持。

4 基于Web Services技术的企业应用集成框架

传统的企业应用集成技术是通过交流使应用双方的通信协义、消息格式、数据模型之间达成一致才能实施[5],但是在敏捷化开发环境下虚拟企业时而重建时而解散,集成用户群的变动很不确定,使得这种“一致”根本不可能实现。Web Services技术[6]是一种基于服务层的集成技术,采用面向对象的技术包装数据,通过简单对象访问协议(Simple Object Access Protocol,SOAP)实现基于Web的不同应用的访问,所构成的系统是一种松散耦合的体系结构,它完全屏蔽了不同软件平台之间的差异,从而为企业应用集成提供了一种全新的机制。为此采用Web Services技术进行企业间与企业外部的应用集成,对现有的应用系统将其进行Web Services包装(其实质是在原应用系统上绑定一个Web Services适配器,该适配器通过本地协议和现有应用系统交互,而在另一端通过SOAP协议与其他的应用系统交互),对于新的应用系统则采用Web Services技术实现。在每个Web Services服务中都封装了具体功能并提供对外的API (Application Program Interface)接口,服务之间通过API进行交互。图3是基于Web Services技术的企业应用集成框架。

基于Web Services的企业应用集成框架具有良好的可扩充性和较高的集成能力,组件复合程度高,可以灵活地实现系统定制。当有新的Web服务出现时,它只需要注册到UDDI服务注册中心即可,Web Services引擎会发现它并根据需要调用它;当有新的请求产生时,只需要在集成规则库中添加新的规则即可[7]。

5 系统原型实现

5.1 系统功能结构

根据系统的需求分析、系统的整体技术方案,从功能上将敏捷化开发环境下产品装配设计系统划分为模块划分、装配建模、序列规划、可装配性分析4个基本模块,如图4所示。

(1)模块划分

模块划分模块由客户需求分析、功能结构维护、相关矩阵建立、模块划分4个部份组成。客户需求分析通过对公司网站收集的客户原始需求进行分类合并形成设计需求,并确定各设计需求的权重;功能结构维护完成新产品功能的分解和老产品功能结构的修改等工作,最终将各功能单元之间流的关系以邻接矩阵的形式存入数据库内;相关矩阵建立完成2类模块划分问题的相关矩阵(功能模块相关矩阵和结构模块相关矩阵)的建立,主要过程是辅助设计人员通过人机交互方式输入打分值;前3部分:客户需求分析、功能结构维护、相关矩阵建立是为第4部分模块划分准备基础信息。

(2)装配建模

装配建模模块为装配设计系统的核心模块,它寄生于三维CAD软件(SolidWorks2005)内,为装配设计系统提供相应的建模环境和建模工具。装配建模模块主要包括方案布局设计、骨架模型建立、属性模型建立、装配模型重建、装配仿真工具、工程图辅助工具等6个部份。方案布局设计完成产品的初步方案设计,为骨架模型的建立提供参考信息,骨架模型的建立意味着各零件的部份装配特征及相应装配关系的确定,从而可以支持零件属性模型的建立,装配模型重建为利用三维CAD软件功能完成最终的装配体、层次结构及参数化设计模型。由于传统三维CAD软件的零件装配不是实体装配方式,零件可从其它零件中穿过,难以检测零件装配过程中的运动干涉情况。为了不受单一三维CAD软件的限制,系统外挂设计了专用的装配仿真工具,在零件详细设计完以后,利用各零件的STL格式文件进行实体装配仿真,包括静态、动态、运动干涉检验,为后续模块提供基础信息支持。工程图辅助工具为零件二维制图提供各种辅助工具,如公差查询、明细表生成、国标工程图符号库、零件各类管理信息输入、常用零件参数化设计功能等。装配建模的核心思想为自顶向下的设计方法。

(3)序列规划

序列规划模块由联系图维护、优先接触联接矩阵、稳定聚合性矩阵、序列规划4个组成。联系图维护为根据装配建模模块获得的接触联接矩阵生成联系图,同时标记各边的序号,生成边与零件序号的对应关系矩阵;优先接触联接矩阵为人机交互确定各接触联接边的优先满足(建立)顺序;稳定聚合性矩阵为装配体稳定性、聚合性影响两评价指标的量化准备初始数据;前3个部分是为装配序列规划准备基础数据,第4部分采用文[8]介绍的算法进行序列规划,筛选较优的可行边序列及其对应的零件序列为后续模块做准备。

(4)可装配性分析

可装配性分析模块为敏捷化开发环境下产品装配设计提供了一个产品可装配性分析、评价、反馈的环境,提供相应的可装配性评价工具和资源,并为上游功能模块提供可装配性分析评价结果及修改建议,以指导装配设计的改进。它包括设计方案可装配性评价、骨架模型可装配性评价、零件可装配性评价、装配过程可装配性评价4个部份。

5.2 系统集成实现

由于装配设计系统中存在大量的人机交互,对鼠标操作的实时反应要求相当高,因此将系统完全做成Web结构,采用通用的浏览器作为客户端,目前的技术水平和网络带宽难以支持。但是采用Web Services技术将一些通用功能抽取出来,在网上发布,不仅可以供本地用户使用,而且还可供合作伙伴使用,真正实现资源可重用、可扩展;同时也可使得原本孤立的系统能够方便地交流数据,达到普遍集成的目的。因此,系统主要采用的是C/S架构。为了方便收集客户需求和客户反馈意见,考虑到普通用户或潜在客户不可能通过Web Services反馈信息,系统也有一部分程序采用的是B/S架构,旨在方便大众用户或者潜在用户输入需求信息或反馈产品信息。

根据上述思想结合系统体系结构和企业应用集成框架,现将应用层(图2所示)拆分为两层,一层为共享Web Services服务层,另一层为基本应用功能层。基本应用功能层与以往的应用层一致,Web Services服务层为从应用层中抽取出来的数据库操作服务、模块划分算法服务、序列规划算法服务、基于熵的定权法服务、最小二乘法求解优良隶属度服务等,供本地客户端、本地其它应用系统、异地客户端、异地其它应用系统调用。图5为敏捷装配设计系统所提供的上述Web Services服务功能页面。

5.3 系统原型开发

系统采用Visual Studio.NET开发平台语言开发客户端,Web Services服务采用ASP.NET开发,后台数据库为SQL Server 2000,三维CAD软件为SolidWorks2005,仿真工具采用Visual C++与Open GL编制。图6为敏捷装配设计系统主界面及功能结构分解界面。

6 小结

本文进行了敏捷化开发环境下产品装配设计系统的需求分析,建立了敏捷产品装配设计系统的整体技术方案,在此基础上构建了基于项目管理的系统体系结构和基于Web Services技术的企业应用集成框架;最后基于上述思想进行了系统原型开发(包括功能结构、集成实现、原型开发),并展示了系统相关功能模块界面。

参考文献

[1]Molloy E,Yang H,Browne J.Feature-based modeling in des- ign for assembly[J].International Journal of Computer Inte- grated Manufacturing,1993,6(1-2):119-125.

[2]De Fazio TL,Edsall AC,Gustavson RE,et al.A prototype of feature based design for assembly[J].Journal of Mechnical Design,1993,15(4):723-734.

[3]岳建鹏，尹文生，吴俊军，等．并行环境下广义装配设计的集成框架[J]．计算机辅助设计与图形学学报，2001，22(4)：373-378．

[4]周开俊，李东波．敏捷化开发环境下产品装配设计系统研究[J]．计算机集成制造系统-CIMS，2007，13(3)：502-507．

[5]吴建斌，张浩然，张长江，周家庆．基于Web Services的企业应用集成平台模型[J]．计算机与现代化，2005，119(7)：107- 109．

[6]袁占亭，张秋余，扬洁．基于Web Services的企业应用集成解决方案研究[J]．计算机集成制造系统-CIMS，2004，10 (4)：394-398．

[7]任晓霞，张蓓，李笑难．面向Web Services的应用集成[J]．通信学报，2005，26(1)：267-270．