产品线可变性的需求方法研究

软件产品线领域需求记录了不同软件产品的共性和可变性。在现有需求过程框架下,对产品线需求获取方法与需求分析方法进行了研究,完善了产品线需求可变性的管控机制。以原子需求为视点,提出了利用需求场景获取产品线领域需求的方法;通过原子需求构建的产品需求矩阵与用例需求矩阵,分析得出需求资源的可变性关系;通过可变性关系的形式化描述,建立产品线可变性用例模型。     

基于UML用例图的软件产品线需求建模方法

软件产品线方法是一种面向特定领域的、大规模、大粒度的软件复用技术。明确建模和描述软件产品线需求是软件产品线开发的关键问题之一。而传统的UML用例图等方法不足以完整描述产品线需求,特别是其变化性。通过分析软件产品线开发过程和软件产品线需求建模的特殊性,采用扩展UML用例图标签的方法,实现对软件产品线需求的明确描述。以网络图书销售软件产品线为例,进行具体说明。     

支持需求追踪的版本控制机制

版本控制是增强软件可维护性的重要方法,但目前常用的版本控制机制缺乏对需求的可追踪性支持。该文提出一种支持需求追踪的版本控制机制,能够有效追踪功能需求、功能设计、代码间的版本关联关系,确保开发人员可以正确获取所需程度的需求追踪信息,有利于软件产品的一致性维护。基于该机制,设计并实现了一个支持需求追踪的版本控制工具VCFQ,并对该工具实现中的一些关键技术进行了论述。     

基于模型对比和组合的软件产品线领域需求建模

软件产品线作为系统化的软件复用方式,可以提高软件的开发效率和质量.软件产品线变化性建模是软件产品线的关键技术,通过建立变化性模型以记录软件产品线成员产品的共性和变化性.目前的软件产品线变化性建模方法大都通过领域专家进行分析建立,这种方法过度依赖于领域专家的分析能力,在系统规模较小的情况下,变化性分析比较容易,但是如果系统规模变大,则系统的规模对于变化性分析的影响会越来越大.文中提出一种半自动的软件产品线领域需求建模方法,基于关注点分离的思路,利用特征模型表示软件产品线中系列产品的不同方面的特征信息,通过特征模型的对比和组合实现领域需求模型的构建.为有效地实现特征模型对比与组合,文中提出一种基于标记和结构的特征模型对比方法,同时,文中实现了基于约束的特征模型组合.基于公开的特征模型,文中对提出的方法进行了验证,实验结果表明,文中提出的领域需求建模方法能够在一定准确率的情况下有效地实现领域需求模型的构建.     

基于信息检索和本体的动态需求追踪方法

在对现有追踪方法的研究和分析的基础上,提出了一个新的基于信息检索和本体的动态需求追踪模型,由概率相似度计算公式和本体推理相互补充来建立需求追踪关系。通过对模型实现系统的验证,实验结果表明该模型是有效的,并且与常规概率模型相比,需求追踪的精度和效率都得到了一定的提高。     

多视点元模型间需求追踪性方法

以全面而统筹的眼光解决问题,则必须从局部分析不同的侧面,面向多视点的需求工程即为该理论的一个应用.多视点需求工程越来越受到重视,但是各视点间却缺少统一,这不仅不利于获取完整的系统需求,还导致需求变更困难等问题.为了解决以上问题,首先提出一个新的多视点建模过程框架,合理的建模框架有利于获取完整的系统需求.其次在多视点建模过程框架下建立追踪元模型,阐明系统需求在多视点元模型间的平稳过渡.最后结合需求追踪矩阵方法在追踪元模型间建立起追踪关系,进而通过计算变化追踪矩阵在需求变更时可以追踪到相关元素并进行更改,解决需求变更困难的问题.     

一种支持用例分析技术的需求元模型

为了体现在不同需求活动中需求的抽象层次,建立了一种支持用例分析技术的两层需求元模型.其中,用户层需求元模型定义需求获取活动输出的需求模型;软件层需求元模型定义需求分析活动输出的需求模型.同时,为表现不同层次需求模型之间的关系,建立了两层需求元模型之间的追踪和精化关系,提出并使用谓词逻辑描述了追踪和精化关系应满足的规则和...     

基于χChek的软件产品线多值模型检测方法

软件产品线保持产品个性化的同时提高了公共部分的复用。但软件产品线中包含的不确定信息,给产品带来了潜在风险。形式化验证技术逐步应用于软件产品线验证。但是传统的布尔逻辑模型不能很好地描述软件产品线的不确定性和不一致性。本文结合多值模型检测器χChek,通过基于动作的模型描述方法,对软件产品线进行描述,然后转换成为χChek规定的模型格式,同时提供多值逻辑描述。最后采用计算树逻辑描述产品线属性,使用χChek进行验证。     

面向过程的装备需求论证信息资源获取方法

为提高装备需求论证过程中信息资源服务的针对性与有效性,面向装备需求论证业务过程,提出一种信息资源获取方法。基于WBS方法,提出装备需求论证过程的活动组成及其元模型;通过构建活动-信息需求矩阵,提出装备需求论证信息资源的分类、内容及其描述要求;定义装备需求论证信息资源描述框架,提出信息资源实例的生成方法。采用该方法能够实现面向装备需求论证过程的信息资源按需服务能力。以作战任务需求分析活动的信息资源需求分析为例,验证了该方法的可用性和有效性。     

面向方面的软件产品线需求建模

为了将软件产品线的横切关注点在开发的早期阶段分离出来,完成系统分析向设计阶段的顺利过渡,提出了一种面向方面的软件产品线需求分析模型,并给出该模型需求分析的基本步骤.通过冷库管理系统的实例,给出了识别和描述功能需求、非功能需求和横切关注点的方法,利用UML类图完成方面和功能整合,在此基础上介绍了用关系矩阵和合并非功能需求集合的方法来描述非功能需求.实验结果表明,该方法能够有效简化软件产品线需求建模的复杂性.     

从领域需求到产品线体系结构的映射——一种面向特征的方法

领域需求之间的依赖关系对软件产品线的体系结构有很大的影响,在已有的面向特征的管理产品线需求依赖的方法中很少有研究从需求到产品线体系结构的映射.基于一种特征依赖的分类方法,提出了从领域需求到特征,以及从特征到产品线体系结构的映射规则.通过这些映射规则,一致的需求通过映射得到一致的产品线核心资产,从而减少产品线中核心资产的不一致性并增加产品线的复用程度.用金融领域的现货交易产品线作为实例说明这个方法的实用性.     

基于软件产品线的需求分析研究

软件产品线方法是一种面向特定领域的、大规模、大粒度的软件复用技术.在软件产品线的开发过程中,产品线需求分析是软件产品线开发的关键活动之一,软件产品线需求分析奠定了产品线构架的基础.通过分析软件产品线开发过程和软件产品线需求分析的特点,阐述了软件产品线需求分析方法以及软件产品线需求分析的实践风险.以领域分析和建模为切入点,对软件产品线的领域分析、需求建模和用例建模等关键方法和技术进行了重点的研究.     

基于构件和框架、面向方面的软件产品线开发方法CFB-AOD

本文提出了一种基于构件和框架、面向方面的软件产品线设计方法CFB-AOD(ComponentandFrameworkBased,AspectOrientedDesign)。CFB-AOD关注实际的软件开发过程,致力于在软件产品线的开发过程中融入构件技术、框架技术和面向方面技术,对软件开发特别是软件产品线开发有实际的指导意义。并以北航软件所白盒测试工具产品线QESat为例,介绍了CFB-AOD的实际运用。     

平板终端的输电线路地理信息及导航跟踪系统的应用

介绍基于Android OruxMAPS软件的输电线路地理信息及导航跟踪系统,重点阐述地理信息平台上的地图和线路设备参数文件、汽车巡视路径文件的制作方法。     

An approach to developing domain requirements as a core asset based on commonality and variability analysis in a product line

The methodologies of product line engineering emphasize proactive reuse to construct high-quality products more quickly that are less costly. Requirements engineering for software product families differs significantly from requirements engineering for single software products. The requirements for a product line are written for the group of systems as a whole, with requirements for individual systems specified by a delta or an increment to the generic set. Therefore, it is necessary to identify and explicitly denote the regions of commonality and points of variation at the requirements level. In this paper, we suggest a method of producing requirements that will be a core asset in the product line. We describe a process for developing domain requirements where commonality and variability in a domain are explicitly considered. A CASE environment, named DREAM, for managing commonality and variability analysis of domain requirements is also described. We also describe a case study for an e-travel system domain where we found that our approach to developing domain requirements based on commonality and variability analysis helped to produce domain requirements as a core asset for product lines.     

办公自动化软件产品线的研究与设计

软件产品线是一组具有可管理的公共特性的产品集合。选取网络办公自动化（OA）系统作为特定的研究领域,在分析此领域中产品的共性后,给出了OA系统软件产品线的实现方法。具体描述了OA系统产品线的需求工程,OA系统产品线核心资产的提取,并以科技项目管理系统为例说明了如何将核心资产应用到具体的产品开发中。     

Automating Test Case Selection in Model-Based Software Product Line Development

We address the problem of how to select test cases for products in a controlled model-based software product line development process. CVL, the common variability language, gives a framework for materialisation of product models from a given base model, variability model and resolution model. From such product models, software products can be derived. In practise, test case development for the product line often is independent from the product development. Therefore, the problem arises which test cases can be applied to which products. In particular, the question is whether a test case for one speci c product can be also used for a "similar" product. In this paper, we show how the expected outcome of a test case to a product in a model-based software product line development can be determined. That is, we give a procedure for assigning the outcome of a given test case on an arbitrary member of a software product line. We recall the relevant de nitions for software product line engineering, describe our approach, and demonstrate it with the example of a product line of super-automatic espresso machines.     

An organizational maturity model of software product line engineering

Software product line engineering is an inter-disciplinary concept. It spans the dimensions of business, architecture, process, and the organization. Some of the potential benefits of this approach include cost reduction, improvements in product quality and a decrease in product development time. The increasing popularity of software product line engineering in the software industry necessitates a process maturity evaluation methodology. Accordingly, this paper presents an organizational maturity model of software product line engineering for evaluating the maturity of organizational dimension. The model assumes that organizational theories, behavior, and management play a critical role in the institutionalization of software product line engineering within an organization. Assessment questionnaires and a rating methodology comprise the framework of this model. The objective and design of the questionnaires are to collect information about the software product line engineering process from the dual perspectives of organizational behavior and management. Furthermore, we conducted two case studies and reported the assessment results using the organizational maturity model presented in this paper.     

An architecture process maturity model of software product line engineering

Software architecture has been a key research area in the software engineering community due to its significant role in creating high-quality software. The trend of developing product lines rather than single products has made the software product line a viable option in the industry. Software product line architecture (SPLA) is regarded as one of the crucial components in the product lines, since all of the resulting products share this common architecture. The increased popularity of software product lines demands a process maturity evaluation methodology. Consequently, this paper presents an architecture process maturity model for software product line engineering to evaluate the current maturity of the product line architecture development process in an organization. Assessment questionnaires and a rating methodology comprise the framework of this model. The objective of the questionnaires is to collect information about the SPLA development process. Thus, in general this work contributes towards the establishment of a comprehensive and unified strategy for the process maturity evaluation of software product line engineering. Furthermore, we conducted two case studies and reported the assessment results, which show the maturity of the architecture development process in two organizations.