首页 | 官方网站   微博 | 高级检索  
相似文献
 共查询到20条相似文献,搜索用时 59 毫秒
1.
对非功能需求NFRs进行了描述,根据功能需求、NFRs与SA的关系,定义了基于NFRs的SA演化,使用构件组合运算和结构工作链对软件体系结构的非功能特性进行了评估,根据评估结果,给出了基于NFRs的SA演化模型。  相似文献   

2.
非功能需求跟踪   总被引:3,自引:0,他引:3  
文中介绍了面向过程的非功能需求跟踪方法的原理,在一个雷达系统的设计过程中进行了该方法的应用分析,并实现了相应的支持工具的原型。  相似文献   

3.
刘玲  桑楠  苏芮  黄小红 《计算机工程》2009,35(1):58-60,6
版本控制是增强软件可维护性的重要方法,但目前常用的版本控制机制缺乏对需求的可追踪性支持。该文提出一种支持需求追踪的版本控制机制,能够有效追踪功能需求、功能设计、代码间的版本关联关系,确保开发人员可以正确获取所需程度的需求追踪信息,有利于软件产品的一致性维护。基于该机制,设计并实现了一个支持需求追踪的版本控制工具VCFQ,并对该工具实现中的一些关键技术进行了论述。  相似文献   

4.
软件系统的非功能需求通常横切整个系统,采用面向对象的软件开发方法会导致代码缠结和分散.提出一种面向方面的非功能需求建模方法,通过扩展UML表达面向方面的概念,识别系统的功能需求和非功能需求,根据相应的需求得出系统的功能模型和非功能模型,然后将系统的非功能需求用方面实现,功能需求用组件实现,最后将组件和方面编织在一起形成最终的系统.这种方法降低了软件系统的开发难度,提高了系统的模块性、可重用性和可维护性.最后给出了应用实例.  相似文献   

5.
软件系统架构设计中,非功能需求不仅是架构师知识结构中的重要组成部分之一,也扮演了重要的角色,甚至会直接决定架构的组成。非功能需求主要分为质量属性与约束,且来自于多方。质量属性、约束和功能需求之间能相互作用,并最终在架构设计中体现。  相似文献   

6.
在构建非功能需求冲突管理元模型的基础上,给出相关建模元素的形式化描述,将需求冲突的语义定义作为检测依据。根据不同的需求冲突类型和程度,提出一种排除冲突和降低冲突的网络式软件非功能需求冲突消解方法。以旅游出行领域中计算行程费用服务的非功能需求为例,验证了该方法的有效性。  相似文献   

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

8.
针对Web软件非功能需求的复杂性, 基于ISO/IEC 9126模型以及Web软件属性图, 对基于ISO的Web软件非功能需求模型进行改进。由于已有的模型不具备明显的解释功能, 所以将Web软件所特有的非功能需求属性添加进原有模型对其进行改进, 将原有模型中的12个子属性扩充为18个子属性, 进而利用问卷调查确定原有模型与改进模型中各属性的评价值, 应用因子分析法计算出各属性的因子载荷与因子累计贡献率。结果表明, 改进后的模型能更好地解释Web软件的非功能需求。  相似文献   

9.
可信软件非功能需求的量化评估是可信软件研究的一个重要领域。依据构件中非功能需求之间的相互关系,结合设计结构矩阵及矩阵变换、运算的方法,提出了非功能需求贡献值的概念,建立了构件和非功能需求关系的相关阵列及具有统一标准和评判尺度的可信软件非功能需求度量模型,并结合该模型构建了一种用来判断软件非功能需求是否符合软件开发者和用户预期的评估决策方法。最后通过一个实例来说明本模型的合理性和有效性。  相似文献   

10.
11.
    
Maintenance is performed not only after a software product has been delivered to the client. On the contrary, the requirements frequently change during development, thereby necessitating reconstruction of the artifacts that have been developed to date. In this paper we present a process for software construction that recognizes maintenance as an essential aspect of the entire life cycle of the software product, considered from the very first steps of the initial development. The process may be used in conjunction with any software development or maintenance methodology. Our process consists of two components: a procedure that is uniformly applied at every step of the chosen methodology, whether development or maintenance; and a data structure, the propagation graph, which is updated at every step. When requirements change, the propagation graph is used to determine which artifacts of the software product are impacted by the change in requirements. From the viewpoint of changes in requirements, the process treats development as a special case of software maintenance. Copyright © 2000 John Wiley & Sons, Ltd.  相似文献   

12.
一种面向特征的软件产品线非功能需求建模方法   总被引:1,自引:0,他引:1  
分析传统非功能需求定义的不足,基于需求分析阶段的系统抽象—\"需求模型\"重新定义非功能需求,规范并简化功能需求与非功能需求之间的关系。扩展面向特征的软件产品线建模方法,在特征模型中显式地建模功能需求、非功能需求、非功能需求类型以及它们之间的相互关系,沿用传统特征模型中固有的变化性建模机制建模并管理非功能需求的变化性,显式地复用与非功能需求相关的建模知识和资产,为进一步研究定量评估产品线变体质量的新技术奠定基础。设计了一个基于多视图的特征建模方法,指导开发者在迭代的过程中建模非功能需求和功能需求,支持关注点分离和模型的复杂性管控。实现了工具原型并进行了实例验证。  相似文献   

13.
    
The nonfunctional requirements (NFR) are often captured only generically at a fairly high level, and they do not include the levels of detail necessary at this stage for the system engineers to allocate them as specific functionalities to be handled either by the software or the hardware, or a specific combination of the two. The European Cooperation for Space Standardization (ECSS) series of standards for the aerospace industry includes maintainability requirements as one of 16 types of NFR for embedded and real‐time software. A number of maintainability‐related concepts are dispersed throughout the ECSS, ISO 9126, and Institute of Electrical and Electronics Engineers standards to describe, at varying levels of detail, the various types of candidate maintainability requirements at the system, software, and hardware levels. This paper organizes these dispersed maintainability concepts into a standards‐based reference model of system maintainability requirements. The availability of this reference model can facilitate the early identification of the system maintainability‐NFR and their detailed allocation as specific maintainability functions to be handled by the specified allocation to hardware or software, or a specific combination of the two. In the absence of such a reference model, these NFR are typically handled in practice much later on in the software development life cycle, when at system testing time, users and developers find out that a number of maintainability requirements have been overlooked and additional effort has to be expended to implement them. The approach adopted in this research for the structure of this reference NFR model is based on the generic model of software functional requirements proposed in the COSMIC – ISO 19761 model, thereby allowing the functional size of such maintainability requirements allocated to software to be measured. Copyright © 2012 John Wiley & Sons, Ltd.  相似文献   

14.
张纯  张敬周 《计算机工程》2010,36(13):62-64
目前的架构设计决策隐含于最终架构制品中,导致了涉众交流困难、演化代价高、难以复用等问题。针对上述问题,通过分析架构设计决策的属性及决策制定过程,提出一种描述设计决策与其他外部元素之间关系的元模型,在此基础上设计一个结合编码化和人际化的管理策略的架构设计决策管理工具,实现对设计决策的显式编档、管理和复用。  相似文献   

15.
16.
    
Requirements volatility is a major issue in software development, causing problems such as higher defect density, project delays, and cost overruns. Software architecture that guides the overall vision of software product is one of the areas that is greatly affected by requirements volatility. Since critical architecture decisions are made based on the requirements at hand, changes in requirements can result significant changes in architecture. With the wide adoption of agile software development, software architectures are designed to accommodate possible future changes. However, the changes has to be carefully managed as unnecessary and excessive changes can bring negative consequences. An exploratory case study was conducted to study the impact of requirements volatility on software architecture. Fifteen semistructured, thematic interviews were conducted in a European software company. The research revealed poor communication, information distortion, and external dependencies as the main factors that cause requirement volatility and inadequate architecture documentation, inability to trace design rationale, and increased complexity as the main implications of requirements volatility on software architecture. Insights from software teams' awareness of the requirement volatility, factors contribute to it, and possible ways to mitigate its implications will be utilized to improve the management of requirement volatility during software architecting process.  相似文献   

17.
    
Nowadays, the demand for higher quality in software products causes the increased complexity of these products. These two aspects (quality and complexity) combined with productivity are key elements for improving the competitiveness between software companies and differentiating success from failure in the software industry. In this sense, software reuse, and requirements reuse in particular, has been widely recognized as an effective way to improve software quality and productivity. In this paper, we propose a model to reuse the software requirements in a Requirements Catalog. This research aims to define the guidelines to carry out the requirements reuse process through four principal activities: searching, selecting, adapting, and implementing. Also, the commercial tool Computer-Aided Requirements Engineering Rational RequisitePro was tailored to make feasible the implementation of the proposed model; in this sense, a tool plug-in was developed. Finally, a case study is presented to demonstrate the feasibility of the proposed model. Copyright © 2014 John Wiley & Sons, Ltd.  相似文献   

18.
    
Systems being developed today make extensive and complex use of advanced technology. Many, if not most, of these systems are being produced but are not used or useful on delivery because the wrong problem was solved. A major cause for this shortfall in system development is due to changes in the operational environment of the intended system while the development process is ongoing. Significant sections of the literature discuss the need to get stakeholders involved earlier in the development process to correct this problem. However, no one has developed a detailed framework that accomplishes this intent. This paper defines a method involving a four‐step sequence that validates the entire system design process early and continuously to ensure that the right problem is being solved. The method is called Continuous Early Validation (CEaVa). It is a method that increases the likelihood of producing the correct system. The method develops visibility of potential disconnects among stakeholders' needs, original written requirements, organizational policy, and derived requirements. The CEaVa method validates the external and internal consistency of the problem statement. Additionally, CEaVa facilitates consensus on trade offs and priorities, resolving the potential disconnects with decision analytical reasoning for trade‐off analysis. The CEaVa method improves the development process and ultimately the system itself by increasing the likelihood of building the right system within budget and schedule. © 2002 Wiley Periodicals, Inc. Syst Eng 5: 223–241, 2002  相似文献   

19.
Software architecture evaluation involves evaluating different architecture design alternatives against multiple quality-attributes. These attributes typically have intrinsic conflicts and must be considered simultaneously in order to reach a final design decision. AHP (Analytic Hierarchy Process), an important decision making technique, has been leveraged to resolve such conflicts. AHP can help provide an overall ranking of design alternatives. However it lacks the capability to explicitly identify the exact tradeoffs being made and the relative size of these tradeoffs. Moreover, the ranking produced can be sensitive such that the smallest change in intermediate priority weights can alter the final order of design alternatives. In this paper, we propose several in-depth analysis techniques applicable to AHP to identify critical tradeoffs and sensitive points in the decision process. We apply our method to an example of a real-world distributed architecture presented in the literature. The results are promising in that they make important decision consequences explicit in terms of key design tradeoffs and the architecture's capability to handle future quality attribute changes. These expose critical decisions which are otherwise too subtle to be detected in standard AHP results. Liming Zhu is a PHD candidate in the School of Computer Science and Engineering at University of New South Wales. He is also a member of the Empirical Software Engineering Group at National ICT Australia (NICTA). He obtained his BSc from Dalian University of Technology in China. After moving to Australia, he obtained his MSc in computer science from University of New South Wales. His principle research interests include software architecture evaluation and empirical software engineering. Aybüke Aurum is a senior lecturer at the School of Information Systems, Technology and Management, University of New South Wales. She received her BSc and MSc in geological engineering, and MEngSc and PhD in computer science. She also works as a visiting researcher in National ICT, Australia (NICTA). Dr. Aurum is one of the editors of “Managing Software Engineering Knowledge”, “Engineering and Managing Software Requirements” and “Value-Based Software Engineering” books. Her research interests include management of software development process, software inspection, requirements engineering, decision making and knowledge management in software development. She is on the editorial boards of Requirements Engineering Journal and Asian Academy Journal of Management. Ian Gorton is a Senior Researcher at National ICT Australia. Until Match 2004 he was Chief Architect in Information Sciences and Engineering at the US Department of Energy's Pacific Northwest National Laboratory. Previously he has worked at Microsoft and IBM, as well as in other research positions. His interests include software architectures, particularly those for large-scale, high-performance information systems that use commercial off-the-shelf (COTS) middleware technologies. He received a PhD in Computer Science from Sheffield Hallam University. Dr. Ross Jeffery is Professor of Software Engineering in the School of Computer Science and Engineering at UNSW and Program Leader in Empirical Software Engineering in National ICT Australia Ltd. (NICTA). His current research interests are in software engineering process and product modeling and improvement, electronic process guides and software knowledge management, software quality, software metrics, software technical and management reviews, and software resource modeling and estimation. His research has involved over fifty government and industry organizations over a period of 15 years and has been funded from industry, government and universities. He has co-authored four books and over one hundred and twenty research papers. He has served on the editorial board of the IEEE Transactions on Software Engineering, and the Wiley International Series in Information Systems and he is Associate Editor of the Journal of Empirical Software Engineering. He is a founding member of the International Software Engineering Research Network (ISERN). He was elected Fellow of the Australian Computer Society for his contribution to software engineering research.  相似文献   

20.
以决策为中心的软件体系结构设计方法   总被引:4,自引:0,他引:4       下载免费PDF全文
崔晓峰  孙艳春  梅宏 《软件学报》2010,21(6):1196-1207
提出针对体系结构层次设计的决策抽象和问题分解原则,以及基于该原则的一种以决策为中心的体系结构设计方法.该方法从决策的视角对体系结构进行建模,并通过一个从导出体系结构关键问题到对体系结构方案决策的过程完成设计,还在其中实现了候选体系结构方案的自动合成以及设计决策与理由的捕捉.这种以决策为中心的方法切合体系结构层次的特点,降低了体系结构设计的复杂性和设计决策与理由捕捉的代价.  相似文献   

设为首页 | 免责声明 | 关于勤云 | 加入收藏

Copyright©北京勤云科技发展有限公司    京ICP备09084417号

京公网安备 11010802026262号