软件需求分析作为过程实现

将软件需求分析作为过程提出,围绕需求分析的三个子过程：需求获取、需求规格说明书的制作、需求验证,探讨了在结构化系统分析法、原型法及面向对象系统分析法三种开发体系并存的开发环境中,如何实现软件需求分析作为过程的高效率和高质量从而顺应当前构造面向对象的软件工程环境的潮流。     

基于UML的软件形式化需求分析与验证

针对软件开发中传统的需求分析方法所存在的需求描述不完整、具有二义性和不一致性问题,提出一种形式化需求分析方法。介绍根据用户需求采用形式化方法获取软件需求说明书并设计软件的统一建模语言（UML）模型的过程,及对该UML模型进行形式化描述,采用形式化验证技术对形式化后的UML模型进行需求验证,以确保设计的UML模型的正确性。实验结果表明,形式化的需求分析方法克服了传统需求分析方法中存在的问题。     

需求分析与软件可靠性保证

通过对软件测试过程中产生的数据进行分析,对照软件设计过程中需求分析中的错误或缺陷,对有关可靠性指标进行反复度量,明确软件错误的分布以减少其对软件需求分析可靠性的影响,进而对相关的错误或缺陷进行控制。     

基于软件需求分析方法的机械产品需求建模研究

通过对软件与机械产品的需求进行比较,说明了将软件需求分析方法应用于机械产品的需求分析建模的可行性,同时通过对OOSE的用例图方法进行详细分析与扩展以实现这一目标。这种机械产品需求建模方法具有系统化、表达方式直观简洁、支持全生命周期后续各阶段等特点,并为全生命周期的产品模型集成打下良好的基础。     

DFD在软件需求分析中的应用

软件系统开发过程中,需求分析是软件生命周期中一个重要的环节,DFD图(数据流图)可以表示软件设计开发过程中的概念模型设计,是需求分析通用而直观的方法。文章以Web课件生成系统为例,阐述数据流图在软件需求分析中的具体应用,描述使用数据流图进行建模分析和开发的具体过程,分析数据流图与需求分析的关系。     

基于.net的网络办公自动化系统的设计与实现

通过对同类相关网络办公自动化0A系统进行调查和比较,针对各公司的日常办公状况,对企业内部网络办公自动化系统软件进行了全面细致的用户需求分析,明确所要开发的软件应具有的功能、性能与界面,并经过反复研究,确定办公自动化系统的设计必须达到的各方面需求。     

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

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

UML分析模型中功能点计算的探讨

功能点分析是从用户的角度去度量一个应用程序大小的一种方法,与代码行(LOC或KLOC)度量不同,它与程序设计语言无关,既可以用于传统的语言,也可用于非过程的语言,度量出来的结果可以在不同的开发方法之间进行比较,而且由于在项目的开发初期就可以利用需求分析模型进行功能点估算,因而功能点分析广受欢迎,并且得到广泛的应用。     

产品生产线方法导扬

一、前言目前,软件工程师开发系统仍然是比较独立的“一次开发一个”的过程。一个大型系统从最初的概念化,经过需求分析、设计、集成和测试到最终的配置,经常需要7到10年的时间,对大型软件的开发和再工程都需要大量的投资、很长的产品周期,并缺乏对质量的可预测性。为此,卡内基—梅隆大学(CMU)的软件工程研究所(SEI)提出了产品生产线这种开发方法。一个软件产品生产线是一组具有公共的系统需求集的软件系统,这些需求是针对一类特定的商业行为或任务的,或者可以说是一组共享公共的设计和标准(或构件)的产品族。产品生产线软件开发的特点是在开发过程中使用公共的软件资产,包括构     

基于CMM的EWPCA故障诊断可靠性的研究

软件度量是软件项目管理的关键技术,它是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程。利用度量可控制和改进软件过程,在介绍度量基本理论与相关知识的基础上重点分析了对软件过程的度量,并设计完成了软件过程度量系统,根据统计过程控制思想以及能力成熟度模型(CMM)的过程评估标准,把指数加权主元分析方法应用于故障诊断的可靠性进行分析,取得了良好的效果。     

Deriving complexity information from a formal communication protocol specification

Communication software systems have become very large and complex. Recognizing the complexity of such software systems is a key element in their development activities. Software metrics are useful quantitative indicators for assessing and predicting software quality attributes, like complexity. However, most of existing metrics are extracted from source programs at the implementation phase of the software life cycle. They cannot provide early feedback during the specification phase; and subsequently it is difficult and expensive to make changes to the system, if so indicated by the metrics. It is therefore important to be able to measure system complexity at the specification phase. However, most software specifications are written in natural languages from which metrics information is very hard to extract. In this paper, we describe how complexity information can be derived from a formal communication protocol specification written in Estelle so that it is possible to predict the complexity of its implementation and subsequently its development can be better managed. © 1998 John Wiley & Sons, Ltd.     

PSAMS: a communication protocol specification assessment and measurement system

An obstacle to the uses of software metrics and size models, which we have developed for measuring the complexity and maintainability of a communication protocol specified in Estelle and for estimating the size of its specification and implementation, is the time‐consuming effort in collecting the metrics. To address this problem, a software system called PSAMS (protocol specification assessment and measurement system) for automatically calculating the metrics and sizes of specification and implementation has been developed. This paper describes the design of PSAMS, which provides five functionalities for a communication protocol Estelle specification: exploring its specification, measuring its complexity, assessing its maintainability, estimating its specification size and estimating its implementation size. To demonstrate the usefulness of PSAMS, we have applied it to measure the complexity and maintainability of 10 communication protocol Estelle specifications; the measurement results and decision support information provided by each functionality are presented in this paper. With PSAMS, communication protocol designers and developers are able to assess the complexity of a communication protocol early in the specification stage and have information which helps them manage a communication software project better. Copyright © 2002 John Wiley & Sons, Ltd.     

Software metrics using a metasystem approach to software specification

This article investigates how software metrics can be defined as part of a metasystem approach to the development of software specifications environments. Environment transformation language (ETL) is used to define metric computations. In our approach, metrics applicable to a particular specification environment (e.g., a data flow diagram environment) are defined in conjunction with a formal definition of that environment as given in environment definition language (EDL). The goal is to support a metric-driven approach to software development by incorporating, with relative ease, the metric computation into the software specification environment. As representative examples, metrics for data flow diagrams, structure charts, and resource flow graphs are described and analyzed. We demonstrate how an analyst, interacting with the system, can use metrics to improve the quality of the deliverables.     

软件质量的度量问题

度量的目的是为软件产品提供量化的测量结果，以避免主观论断的差错。软件度量是软件维护的基础。本文对软件度量的定义、度量的过程、面向对象软件的度量、度量与维护的关系等进行了讨论。     

Simulation and comparison of Albrecht's function point andDeMarco's function bang metrics in a CASE environment

Software size estimates provide a basis for software cost estimation during software development. Hence, it is important to measure the system size reliably as early as possible. Two of the best known specification level metrics, Albrecht's function points (A.J. Albrecht, 1979) and DeMarco's function bang metrics (T. DeMarco, 1982) are compared by a simulation study in which automatically generated randomized dataflow diagrams (DFDs) were used as a statistical sample to automatically count function points and function bang in a built CASE environment. These value counts were correlated statistically using correlation coefficients and regression analysis. The simulation study permits sufficient variation in the base material to cover most types of system specifications. Moreover, it allows sufficient sampling sizes to make statistical analysis of data. The obtained results show that in certain cases there is a relatively good statistical correlation between these metrics     

RETRACTED ARTICLE: Correlation between Amount-of-Reuse Metrics and Other Software Measures with Respect to Programming Code in C++

In recent years, there have been several proposals for amount-of-reuse metrics. However, it is not clear if these metrics measure anything different from other software metrics that are often generally used. Besides, the relationship between these metrics is also unclear. Without a clear understanding, the true added value provided by these metrics remains unknown. In this paper, an analysis of the existing amount-of-reuse metrics is presented and a subset of these is selected, on the basis of their industrial applicability, for further investigation. These metrics are then applied to a collection of different software products to obtain an understanding of the level of correlation that exists between them and other well-known software metrics such as cyclomatic complexity, volume and lines of code. Our analysis suggests that the selected subset of amount-of-reuse metrics provides a relatively independent view of the analyzed code.     

Semantic metrics for software products

Like all engineering disciplines, software engineering relies on quantitative analysis to support rationalized decision making. Software engineering researchers and practitioners have traditionally relied on software metrics to quantify attributes of software products and processes. Whereas traditional software metrics are typically based on a syntactic analysis of software products, we introduce and discuss metrics that are based on a semantic analysis: our metrics do not reflect the form or structure of software products, but rather the properties of their function. At a time when software systems grow increasingly large and complex, the focus on diagnosing, identifying and removing every fault in the software product ought to relinquish the stage to a more measured, more balanced, and more realistic approach, which emphasizes failure avoidance, in addition to fault avoidance and fault removal. Semantic metrics are a good fit for this purpose, reflecting as they do a system’s ability to avoid failure rather than its proneness to being free of faults.     

Prediction of Run-Time Failures Using Static Product Quality Metrics

A study is presented in which it is determined whether software product metrics gathered statically from designs or source code may be helpful in predicting the number of run-time faults that will be encountered during execution. Metrics examined include intermodule metrics such as fan-in and fan-out, as well as intramodule metrics such as cyclomatic complexity and size. Our study indicates that it may be possible, with certain classes of software products, to predict the run-time behaviour using well-known static intermodule metrics.     

Automated measurement of models of requirements

On way to formalize system requirements is to express them using the object-oriented paradigm. In this case, the class model representing the structure of requirements is called a requirements metamodel, and requirements themselves are object-based models of natural language requirements. In this paper, we show that such object-oriented requirements are well suited to support a large class of requirements metrics. We define a requirements metamodel and use an automated measurement approach proposed in our previous work to specify requirements metrics. We show that it is possible to integrate 78 metrics from 11 different papers in the proposed framework. The software that computes the requirements metric values is fully generated from the specification of metrics.