一种稳定的倒A型软件开发模型

2016-02-13 05:58陈诗军王慧强林俊宇向平叶田雪锋
软件 2016年12期
关键词:A型定义中心

陈诗军,王慧强,陈 强,林俊宇,向平叶,田雪锋

(1. 中兴通讯股份有限公司 无线预研部,广东 深圳 518000 2. 哈尔滨工程大学计算机 科学与技术学院,黑龙江 哈尔滨 150001)

一种稳定的倒A型软件开发模型

陈诗军1,王慧强2,陈 强1,林俊宇2,向平叶1,田雪锋1

(1. 中兴通讯股份有限公司 无线预研部,广东 深圳 518000 2. 哈尔滨工程大学计算机 科学与技术学院,黑龙江 哈尔滨 150001)

针对传统的V型软件研发过程模型存在的不稳定性问题,本文从需求对产品质量和研发的关键作用出发对其进行改进,提出了以需求为中心的倒A型稳定的研发过程模式,并基于该模式建立研发需求体系及其关联的过程控制活动;同时进一步提出以可用性理论为依据建立质量属性需求体系,并分析了质量控制活动和策略。最后阐述了新研发模式的实践情况,并对其影响和应用前景进行了展望。

计算机软件;研发过程控制;需求;质量属性;可用性

0 引言

软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架,在软件开发过程中有着至关重要的作用。目前存在许多著名的产品开发模型,如瀑布模型、迭代模型、增量模型等等[1-3],如表1所示。

而目前在实际项目开发过程中,应用的最为广泛的还是迭代模型和作为瀑布模型的变种V型模型。迭代模型被认为其是最贴合实际的研发模型,实际上是一次输出没有达到目标要求,或者需要优化补充,或者产生故障(从某种意义上看,故障是没有满足需求的结果)。因此迭代模型和瀑布模型从本质上来说,是需求成熟度的一种表现形式,迭代次数越少,需求成熟度越高,而瀑布模型是需求度高度成熟的模型。从一定程度上讲,瀑布模型或V型模型是迭代次数为零的迭代模型,而软件开发的理想过程就是符合V型模型。

在研发过程中,需求具有其他因素无法取代的核心作用。但在现阶段软件研发过程中,需求却是最薄弱、最受到忽视的一个环节,或者无从做起。大多数产品是以设计为中心的研发模式,或者是以测试为中心的研发模式,这些模式共同的显著特点为需要首先完成产品的开发,然后根据测试和使用情况进行优化和修订。这些研发思维导致了较差的产品质量、成本和研发周期。

本文从V型研发模型的不足出发,提出以需求为中心的研发过程模式,建立了倒A型稳定的研发过程模型,提高质量过程的可操作性和有效性,为企业生产出高品质的产品和服务提供重要保障。

表1 现有产品开发模型分析对比

1 V型模型的不足

Paul Rook在1980年代提出了典型V型研发模型[5],并被各种软件开培训教科书收录作为典型案例,如下图2所示,其由总体设计、概要设计、详细设计、编码等组成v型的左半边;然后单元测试、集成测试、系统测试组成v型的右半边,每一个测试环节和左边有一定的对应关系。

从2图中可以清楚地看出这个模型从时间和层次关系上清楚地描述了研发过程和测试验证过程的对应关系。但存在一个重要的缺陷,即无法说明表示设计过程和测试过程之间的联系。在本文介绍的建立以需求为中心的研发模型中,给出一个相对v型模型更加稳定的模型。

图2 V型开发模型

2 以需求为中心的倒A型研发模型

需求在产品研发中充当着全局引导的重要作用,是产品质量之“源”。明确的需求,可以使计划具有实际意义,是研发工作有序化的前提,能够促进版本需求管理,使测试和设计相互独立和彼此验证成为可行。

3.1 以需求为中心的基本研发模型

如果把“把事情一次做好”作为研发的理念,则必须有一个明确的目标需求定义,这个明确的需求既是研发实现的约束,也是测试验收的标准[6]。基于这一思想,以需求为中心的研发过程的基本模型如图3所示。

图3 以需求为中心的研发过程的基本模型

在上图中,可以看到基本模型和以往模型有几个非常显著的不同:

1)稳定性。在v型模型的基础上,需求成为连接两个分支的关键,因此使这个研发模型具有稳定质量的结构。

2)需求代替设计成为整个研发的中心,需求成为设计过程和测试过程遵守的共同参照。在具体研发过程中,还可以把需求说明看成设计方案和测试用例的检查单,用来检查两个过程的对需求的满足情况。

3)研发和测试两个分支是相互独立的,这和以往的研发模型有着本质的区别。在以往的模型中,尽管设计和测试在时序上是两个阶段,但在逻辑上,测试实际上以设计的相关输出为依据,如设计文档、代码等等,实际上是以设计为中心研发模型。

3.2 倒A型研发模型

在绝大多数研发过程定义的v型研发模型中,分为系统设计、概要设计、模块设计、编码与调试,以及对应的系统测试、集成测试、单元测试等。在目前的较大规模软件公司中,这个研发过程在时序上基本能够得到保证,但这是一个不稳定的模型,在实践中往往弱化为以设计为中心或者以测试为中心的模式,在上面的章节也论述过这些模式存在的诸多问题。

在每一层如果要达到尽量少的迭代而产生的代价,也必须有明确的需求定义。这些不同层次的需求一方面从上向下层层分解,另一方面把同层次的研发和测试联系起来,形成完整的需求体系,使得研发质量控制成为围绕以需求为中心的稳定的倒A型体系结构。如下图4所示。

系统需求,来源于用户、运营商、设备制造商等干系人提出的需求。系统需求是总体设计和系统测试共同的标准。

子系统需求,来源于系统测试向子系统分解而来的需求,以及总体设计产生的一部分新的需求。子系统需求是子系统设计和子系统集成测试标准。

模块需求,来源于子系统需求分解来的需求,以及子系统设计新产生的一部分需求。模块需求是模块详细设计和单元测试的标准。

图4 倒A型研发模型

3.3 基于可用性理论的需求质量属性定义

就像产品要完成某些功能一样,软件功能(或者某种实体)是软件质量的基础,只有在确定的功能上谈质量才有意义。但在目前研发过程中,人们往往割裂功能和质量,这样的例子在很多研发项目中非常常见,如产品研发过分强调先把功能打通,然后根据测试结果进行优化。按照这种方法很难使得研发队伍秉承一次把产品质量做好的思想,人们往往会为这种方法付出巨大的代价。产品的架构受制于质量属性,如果前期产品研发质量属性没有重点考虑,后期将会涉及到架构级别的改动,这对产品来说,意味着大大提高成本和延长产品推出周期。

下面主要介绍如何在需求环节就对产品的质量属性进行分析和定义,约束产品开发,包括研发和测试,把产品的质量一次做好。

3.3.1 质量需求定义

在新的研发模型中,我们引入了质量需求的概念。这种考虑是基于“把事情一次做好”研发理念的延续。如果要达到有效的全程产品质量控制,必须从最早的阶段开始考虑质量,也就是必须从需求阶段就需要引入质量需求和控制。因此在需求说明中,必须要对产品质量的要求进行定义,这种质量方面的要求随着需求的分解和落实,一起分解到下一层进行实现。产品质量方面的要求实际上就是产品的质量属性。图5是质量需求模型的说明。

上述模型具有两个明显的特点:

1 功能(包括实体)和质量属性是相互关联在一起的;

2 在需求分解的时候,质量属性也和功能一样向下层进行分解。

图5 质量需求模型

3.3.2 基于可用性理论的需求质量属性定义方法

需求的质量属性定义有很多种,在实践中可以根据项目的实际情况采取合适的方式,只要满足上节基本模型描述的原理。在实际项目中往往采用可用性理论作为质量属性定义方式。

可用性定义反映了在完成用户功能需求同时,还要关注需求的满足程度的需要[7]。现在重新审视研发中的需求,实现任何需求都需要考量需求的满足程度才算完整,这种满足程度实际上就是需求的质量属性。需求质量属性从可用性三个方面为出发点进行分析:

1 有效性。任何需求本质上都有一个程度的概念,不同的需求的衡量标准可能不同;

2 效率。任何需求本质上都有一个效率的概念,反映在资源方面的代价;

3 满意度。其主要由两个方面来考量:

(1)满足了需求有效性和效率方面的要求,能够有效提高用户满意度,因此需要在有效性和效率方面尽可能地深入、全面地挖掘定义用户提出的或者潜在的需求质量属性;

(2)对有效性和效率之外的无效情况,也需要采取有效的、合适的措施,提高用户满意度,因此需要定义无效性处理策略。另外用户易用性方面,特别是操作、界面方面,也直接影响用户的满意度,也需要明确定义。

在研发的具体实践中,对需求质量属性定义采用了上述可用性概念,结合实践对可用性的三个方面作了进一步的定义和扩展,使得在项目中具有更高的可操作性,如表2所示:

表2 需求质量的可用性定义

3.4 研发过程中基本质量控制活动

以需求为中心的研发过程基本模型中定义了需求、设计和测试为研发的三个基本过程,并且需求是整个研发的中心。从基本模型可以确定新的研发模式的一些基本质量控制活动,下图6是实际的以需求为中心研发过程中的质量活动。

上述过程中特点:

图6 以需求为中心研发过程中的质量活动

1 需求说明:主要由项目人员安排组织进行需求先期分析,给出需求说明,具体实施可以以研发人员或者测试人员为主实施,研发和测试人员都参加评审。需求定义评审之后对需求的影响、复杂度等基本有了较准确地分析,这时候可以紧接着进行工作量估算、计划安排等。

2 设计方案:主要由设计人员完成,测试人员参加评审。

3 测试用例:主要由测试人员完成,研发人员参加评审。

4 测试报告:主要由测试人员完成,研发人员参加评审。

3.5 研发后期的质量控制和活动

产品研发后期,需求逐渐收敛、研发团队重点工作转为解决故障和对系统的优化两个方面。从产品来说, 无论是故障还是优化都带来质量成本,都是研发管理尽量减少和避免的。从另一方面,故障和优化又可以看成对产品新产生的外部需求。

因此后期的故障和优化从过程角度可以按照需求的研发过程进行,即包括故障(优化)解决方案、设计方案、测试用例等基本过程,并进行相应的评审等质量活动;同时故障和优化给产品带来质量成本,必须形成反向的闭环控制措施,用来进行过程数据测量、过程改进等。

图7 研发后期的质量控制

对故障和优化的反向分析包括以下几个方面:

· 问题在研发过程的哪个阶段引入的

· 问题引入对应哪个需求

· 解决问题花费的人力和时间是多少

4 以需求为中心研发过程实例

下面以一个比较典型的系统产品项目为例,说明一个具体项目中采用以需求为中心研发过程的情况。某大型3G CDMA基站系统项目,具有两组相同的项目组,分别采用V型开发模式和以需求为中心的研发模式进行开发对比。下面将以该系统3年的开发数据为例,从开发周期和版本变更通过率两个指标进行对比分析。

图8 开发周期对比

从图8可以看出,采用以需求为中心研发模式的团队总体研发时间明显小于采用V型开发模式的团队。采用V型开发模式的研发人员的研发时间占据了90%,其中几乎大部分时间都在软件调试或者问题攻关,且绝大多数的版本变更不受控制,没有文档,也没有经过评审,仅剩余10%的时间用于学习扩充团队自身。而采用以需求为中心的研发模式的研发人员能够使用60%的时间进行研发,40%的时间进行学习与讨论,节省了大量的时间与人力成本,为学习型团队打下基础。

图9 版本变更通过率与一次变更通过率对比

从图9可以看出,采用以需求为中心研发模式团队在时间上有着充分的质量保证的时间,使得产品能够有能力作分步实施,阶段提交使用,具有清晰的产品规划曲线,版本变更通过率高达100%,高于V型开发模型,其中一次变更通过率为75%远高于V型开发模型。通过对需求进行严格评审保证了需求的完备性和质量属性,从源头上明确了研发和测试的目标,大大减少了后期产生故障和优化任务的可能性,尤其是避免了原理性、系统级别的研发缺陷。另外明确的需求定义也为项目估算、计划等提供了可靠的基础,非常显著地提高了项目管理的科学性和有效性。

以需求为中心的研发过程明确了需求作为研发中心的地位,同时也建立了一整套过程控制规范,促进了设计过程和测试过程,从根本上解决了以设计为中心的一系列问题。

以需求为中心的研发过程中,在有效的前向控制的基础上,也可以有效地进行反向跟踪和改进。在具体实践中,对产品研发过程中产生的故障进行引入的需求以及研发环节进行分析。通过反向分析可以不断进行过程改进,完善需求规范、设计规范以及测试规范,形成一个闭环的研发质量控制系统。随着实践的深入、不断的积累,逐渐形成一个高质量的研发过程规范、高水平的研发队伍。

4 结束语

本文讨论了以需求为中心的研发过程模式,提出了一种倒A型稳定研发过程模型,并创新地提出了以可用性理论为基础的质量属性定义方法以及建立质量属性需求体系。传统V型研发模式只是在开始的时候对系统指标等做简单的描述,这种研发模式需求无法渗入到研发过程的每个环节,因此无法对整个研发过程产生约束作用,通常会表现出自身的不稳定性。新型研发模式通过需求定义、分解、验证约束,深入到每个研发环节,对整个研发组织、研发过程是一个系统性的改革,基于这种新型研发模式的稳定特征实现快速收敛输出产品,是过程管理理论方面重要的理论创新。最终,结合实践过程中过程文档侧面对传统V型研发模式和倒A型研发模式的两种研发过程作了一个形象的比较,则有完善需求文档的系统可以令人有信心地作出一个满意的产品,相反只有设计文档的系统则是一个很大未知数。

[1] Basem S. El-Haik, Adnan Shaout, Software design for six sigma: A roadmap for excellence, Weily Press, 2010.

[2] Evi Septiana Pane, Riyanarto Sarno. Capability Maturity Model Integration (CMMI) for Optimizing Object-Oriented Analysis and Design (OOAD), Procedia Computer Science, 2015(72): 40-48.

[3] Zhen He, Thong Ngee Goh. Enhancing the Future Impact of Six Sigma Management. Quality Technology & Quantitative Management, 2015, 12(1): 83-92.

[4] 张友生, 李雄. 软件开发模型研究综述, 计算机工程与应用, 2006, 03: 109-115.

[5] Paul Clements . Software Architecture in Practice.北京:清华大学出版社, 2003.

[6] Paul Clements. Evaluating Software Architectures.北京:清华大学出版社, 2003

[7] Kraig Finstad. The Usability Metric for User Experience. Interacting with Computers, 2010, 22(5): 323-327.

[8] Junji Zhi, Vahid Garousi-Yusifoğlu, Bo Sun. Cost, benefits and quality of software development documentation: A systematic mapping. Journal of Systems and Software, 2015, 99(1): 175-198.

Inverted A-Model for Stable Software Development

CHEN Shi-jun1, WANG Hui-qiang2, CHEN Qiang1, LIN Jun-yu2, XIANG Ye-ping1, TIAN Xue-feng1
(1. Wireless pre-research department , ZTE Corporation, Shenzhen 518000, China 2. College of Computer Science and Technology, Harbin Engineering University, Harbin 150001, China)

For the instability problem of the traditional V-model for software development, an improved A-model is proposed in this paper based on the key role of requirements for the quality of products and development. It is a stable development mode in a requirement-centered manner. On this basis, the requirement architecture and corresponding process control for the A-model is studied. Meanwhile, the theory of availability is treated as a foundation to build quality attribute requirement architecture, and the approaches and strategies of quality control is outlined too. Finally, the practices are demonstrated in the new development mode, and the application prospect of our model is forecasted.

Computer software; Development process control; Requirement; Quality attribute; Availability

TP393

: A

10.3969/j.issn.1003-6970.2016.12.002

国家科技重大专项(No.2011ZX03003-003-01);国家自然科学基金项目(No.61370212);中兴产学研合作项目(No.2015ZTE01-01-12)

陈诗军(1972-),男,硕士,高级工程师,研究领域为无线定位、MIMO、信道仿真、通信产品开发。

王慧强(1960-),男,博士,教授,研究领域为网络安全、未来网络、软件可信性、无线定位。

本文著录格式:陈诗军,王慧强,陈强,等. 一种稳定的倒A型软件开发模型一种稳定的倒A型软件开发模型[J].软件,2016,37(12):07-12

猜你喜欢
A型定义中心
剪掉和中心无关的
在打造“两个中心”中彰显统战担当作为
别让托养中心成“死亡中心”
DF100A型发射机马达电源板改进
A型肉毒素在注射面部皱纹中的应用及体会
A型肉毒毒素联合减张压迫法在面部整形切口的应用
AZA型号磨齿机工件主轴的改造
修辞学的重大定义
山的定义
教你正确用(十七)