Process-Centered Software Engineering Environments, A Brief History and Future Challenges

Software engineering environments have a history of about two decades. Early environments provided support for small fragments of the software process (usually focusing on programming-in-the small). Then there was a trend towards support for more complete software processes (from early phases like requirements analysis and design down to testing and configuration management). Ten years ago the notion of process-centered software engineering environments initiated a new field in software engineering: software process research. The key idea is to use a model of a software process as input parameter for a software engineering environment. The environment is supposed to behave in accordance to the process model. Some aspects of this vision became true, others turned out to be of little practicability. In this article, we discuss the history of software engineering environments with a particular focus on process-centered software engineering environments (PCSEEs). We discuss the notion of distributed software processes (as one of the most substantial current trends in software process research) and we motivate the notion of a software process middleware which serves as basis of real-world software processes spread over various sites. In addition, we discuss some other trends in the software process research arena.     

Exploring the Belief Systems of Software Development Professionals

It is commonly accepted that an individual's beliefs and actions are based on his or her assessment and perceptions of the world. In order to determine what practices an individual is likely to follow at any given time, it is necessary to understand the individual's behavioral intention in a given circumstance. From an Information Technology perspective, a software development professional's belief systems are potentially the basis for the adoption and implementation of new and innovative work practices and processes. In this article, we explore the belief systems of software development professionals in order to understand the beliefs underlying intention and practice, and we seek answers about how they adopt or reject new and innovative software development processes and practices. The results point out a strong influence of past experiences, personality types, and repeated behavior on current software development processes and practices in industrial settings.     

Process-Based Software Engineering: Building the Infrastructures

A recent trend in software engineering is the shift from a focus on laboratory-oriented software engineering to a more industry-oriented view of software engineering processes. This complements preceding ideas about software engineering in terms of organization and process-orientation. From the domain coverage point of view, many of the existing software engineering approaches have mainly concentrated on the technical aspects of software development. Important areas of software engineering, such as the technical and organizational infrastructures, have been left untouched. As software systems increase in scales, issues of complexity and professional practices become involved. Software development as an academic or laboratory activity, has to engage with software development as a key industrialized process.This expanded domain of software engineering exposes the limitations of existing methodologies that often address only individual subdomains. There is, therefore, a demand for an overarching approach that provide a basis for theoretical and practical infrastructures capable of accommodating the whole range of modern software engineering practices and requirements. One approach is provided by Process-Based Software Engineering (PBSE); part of the more general trend towards a focus on process.This paper provides a review of process techniques for software engineering and a high-level perspective on PBSE. Typical approaches and techniques for the establishment, assessment, improvement and benchmarking of software engineering process systems are introduced in this paper, and many are developed further in other contributions to this volume.     

支持过程度量的软件过程建模方法的研究

文章提出应从过程建模的角度考虑对过程度量的支持问题,并提出一种支持过程度量的软件过程建模方法的框架.它包括面向目标的过程度量模型建模方法、支持过程度量的软件过程描述机制的选择和支持过程度量的软件过程建模算法.     

软件研制的过程质量管理

软件的质量保证措施主要有2个方面：软件研制过程的质量保证和软件产品的质量评估。本文认为软件研制过程的质量管理是软件质量保证的关键,归纳了现阶段国内软件研制中影响软件质量的主要因素,详细分析了这些因素对于软件质量、软件研制及维护成本的影响,论述了软件研制的过程管理与软件质量的关系,结合长期软件研制工作经验,总结了面向软件质量保证的软件研制过程管理措施的主要内容。     

支持软件过程可信评估的可信证据

近年来,软件可信一直是人们争论的焦点.一种比较共识的观点认为,软件可信是软件行为符合预期的程度.质量形成于过程,显然,建立质量信心的证据也散布于过程.软件开发过程中,主体、行为和各种保障手段则是建立软件可信的基本依据.基于证据的决策和管理是现代质量理论的核心,基于证据、数据驱动的软件工程都是试图从客观数据的角度去解决问题.在国家自然科学基金等计划的支持下,从过程保障的角度提出了软件过程可信度模型,其中,证据作为建立软件可信、支持可信评估的基础要素,是模型非常重要且基础的组成部分.主要研究该模型中的证据体系,遵循完整性、必要性、兼容性和可持续性这4项原则,基于过程管理的基本要素,通过调研以及与CMMI等软件过程参考模型的对接来提炼、定义和质证模型中的可信证据,使证据具备良好的公信力和可比性;同时,增加了部分目前其他模型都没有涉及的证据来刻画对软件过程的可信增强,从而建立了一个从可信实体、可信行为、可信制品这3个目标进行可信保障、并覆盖软件过程全生命周期的证据体系.该证据体系科学、客观并具有良好的公信力,结合可信度模型的其他部分,可以实现基于证据的、自底向上的软件过程可信评估,可供软件组织广泛采用.     

软件需求变更管理的系统动力学仿真建模

软件需求变更频繁发生,给软件项目造成了诸多威胁.能否对需求变更进行有效的控制管理,决定着软件的成败.使用系统动力学方法对软件需求变更管理过程进行仿真建模,可以动态地分析并预测需求变更产生的原因以及变更对软件项目造成的影响;对软件需求变更管理过程改进进行系统动力学仿真,亦可以辅助软件项目组织选择合适的过程改进策略.因此,基于系统动力学方法,参考了敏捷过程进行开源软件需求变更管理过程的建模和模型检测.以Spring Framework项目为研究案例,进行该项目3.2.x分支的软件需求变更管理过程的系统动力学仿真分析,并对需求变更管理进行过程改进仿真.通过对过程改进的仿真结果进行比对,说明各改进策略均降低了基线数据的软件缺陷率,提高了软件质量.根据软件项目的成本和进度要求,给出了过程改进建议.     

基于证据的软件过程可信度模型及评估方法

软件可信已经是一个迫在眉睫的重要问题,但对软件可信性的评估却一直没有一个系统并且客观的标准.一些研究工作从可信证据的采集渠道入手,譬如认为有第三方测试的证据,其可信级别就高一些,而若有用户的使用反馈则可信级别就更高.这些工作在可信的客观性方面做了很好的贡献.但我们知道可信其实是一个系统性的问题,而且质量形成于过程,其证据的充分必要程度,以及对必要开发过程的覆盖程度等非常关键.本文基于软件开发过程,从过程的实体、行为以及制品三个方面提取软件可信的证据,建立了由37个可信原则,182个过程可信证据和108个制品可信证据组成的软件过程可信度模型,并给出基于本模型证据的软件过程可信评估方法,试图从开发过程的可信来建立软件产品的可信的信心.     

基于EPMM的软件过程模型规范化研究

为了开发高质量的软件过程模型,有必要对软件过程模型的规范化进行研究。本文基于EPMM对过程的形式化定义,考虑到传统软件过程和软件演化过程的特点,给出过程第一范式(1PNF)、过程第二范式(2PNF)、过程第三范式(3PNF)和过程第四范式(4PNF)的定义,并给出它们的判定算法。本文建议:对于传统的软件过程模型,应设计到满足2PNF;而对于软件演化过程模型,应设计到满足3PNF。本文为建模高质量的软件过程模型提供了指南。     

基于风险管理的软件开发过程模型

所谓软件开发过程中的风险,指的是在软件的开发过程中,可能会遇到的关于进度和预算方面的问题,或者是这些问题对软件开发的影响。如果软件开发过程中的风险变为现实,就会增加项目成本、影响项目进度、打乱软件开发计划,甚至最终影响软件项目的实现。风险管理对于软件开发来讲,就是为了尽可能的降低风险发生概率。如果对软件开发中的风险管理...     

管理领域面向方面软件体系结构及软件过程

软件体系结构设计是构建大型管理领域系统的关键步骤，同时面向方面的软件开发已成为解决软件复杂性的有效方法。该文基于面向方面软件开发方法提出了管理领域系统建设的“4+1”关注点视图，针对“4+1”关注点视图提出了面向管理领域、基于服务实现的面向方面软件体系结构。基于该软件体系结构开发的管理业务支持平台及其支持下的软件开发过程可以缩短软件开发周期，改善软件一致性和可维护性，使软件具有更好的演化能力。     

基于CMM的软件过程改进实践

CMM是一种软件生产过程标准和软件企业成熟度评估标准,该标准侧重于软件开发过程的管理及工程能力的提高与评估。基于CMM理论在软件过程改进中的应用,针对软件开发过程中存在的问题,采用CMM2级项目级实践,实现4个关键过程域：需求管理、软件项目计划、软件项目跟踪和监督、软件质量保证,制定出符合项目需求和管理的规范与过程,将CMM理论应用于软件开发过程中,对项目各个环节的工作进行改进,取得良好的过程改进效果,并从中总结基于CMM模型进行过程改进的经验。     

复用技术在软件工程领域中的应用

软件重复创建造成的巨大浪费,一直未被人们充分重视.构建软件复用库,实现复用驱动的软件开发过程是提高软件开发效率和质量的有效途径,分析复用驱动的软件开发过程,探讨了在软件工程领域实现软件复用的技术方法和软件复用能力评估.     

一种有效的软件过程改善模型

有效地改善软件过程是解决我国软件企业存在的生产率和管理水平低、产品质量难以保证等问题的根本所在。考虑到我国企业特点,文章提出了一个软件过程改善模型,其目的是帮助企业持续地进行软件过程改善。该模型包括五个活动,文章对这些活动进行了详细介绍,同时给出了在进行这些活动时应注意的问题。     

面向重用的软件开发价值链

软件重用可有效地降低软件开发过程中的成本并提高开发资源的利用效率,本文在价值链的形式化概念与元模型的基础上,通过对面向重用的软件开发过程与传统开发过程的特征比较,对面向开发过程的软件开发价值链进行了定义,该价值链在重用已有软件资产的基础上将开发过程中的不同环节、角色和活动进行了系统的集成,通过建立软件开发过程价值增值矩阵和度量指标体系,对软件开发过程中的增值活动进行了定量化的分析,并证明了面向重用的软件开发过程具有更高的价值增值.     

Managing Problems for Global Software Production – Experience and Lessons

With the increase in size and complexity of current software projects, many large companies have established global software production lines over the world to develop and deliver software products with collaborative software development processes involving multiple teams located at different sites. Supporting global software production needs an effective software-engineering environment to meet the special requirements of the collaborative software development process, diverse management methods and engineering practice. WWW technology provides powerful means to set up an enterprise-oriented software engineering environment for global software production due to its advantages in networking, global access, internationalization, and communication. Although there are many articles addressing the methods and experience in building web-based applications systems and tools, very few papers discuss the real-world problems and solutions in the development and deployment of web-based software tools to support a collaborative software development process for global software production. This paper discusses the real world issues, and reports our experience and lessons in building and deploying a web-based problem information management system (PIMS) to support global software development processes at Fujitsu. It focuses on the real issues and needs of current collaborative development process involving multiple teams, and highlights the benefits and impact of the PIMS on global software production. Moreover, it discusses our technical solutions and trade-offs in the development of PIMS, and shares our experience and lessons. Furthermore, it introduces a new data-centered conceptual process model to support diverse collaborative processes for project and problem management in global software production. Finally, the paper shares our key successes and weaknesses, and reports our experience and lessons in the deployment of the system.     

Cost-Benefit Analysis of Software Quality Models

Software reliability is increasingly important in today's marketplace. When traditional software development processes fail to deliver the level of reliability demanded by customers, radical changes in software development processes may be needed. Business process reengineering (BPR) is the popular term for comprehensive redesign of business processes. This paper focuses on the business processes that produce commercial software, and illustrates the central role that models have in implementation of BPR. Software metrics and software-quality modeling technology enable reengineering of software development processes, moving from a static process model to a dynamic one that adapts to the expected quality of each module. We present a method for cost-benefit analysis of BPR of software development processes as a function of model accuracy. The paper defines costs, benefits, profit, and return on investment from both short-term and long-term perspectives. The long-term perspective explicitly accounts for software maintenance efforts. A case study of a very large legacy telecommunications system illustrates the method. The dependent variable of the software-quality model was whether a module will have faults discovered by customers. The independent variables were software product and process metrics. In an example, the costs and benefits of using the model are compared to using random selection of modules for reliability enhancement. Such a cost-benefit analysis clarifies the implications of following model recommendations.     

敏捷软件过程的研究与实践

结合XP、FDD等敏捷软件开发方法,提出了适用于中小型软件企业的敏捷软件开发方法——FXP,并成功地进行了实践。FXP以XP为框架,通过对重量级软件过程方法和敏捷软件过程实践的融合,既强调重量级软件过程方法整体协作的一致性,又结合了敏捷软件过程轻量级方法高效交流与分享的优点,通过把项目管理维度、软件工程维度、质量保证维度3个维度有效地融合在一个整体协作环境,解决了传统软件过程进度跟踪、需求跟踪、质量跟踪3个层面的断层。     

软件过程与管理方法综述

工程化软件开发需要对软件开发整个过程进行有效的组织和管理,由此产生了一系列软件开发组织和管理方法,其主要目的是形成一种载体,用以积累和传递关于软件开发的经验教训.然而,由于软件开发的一些天然特性（比如复杂性和不可见性）的存在,使得描述软件开发过程的软件开发与组织方法也天然地带着一定的抽象性.由此带来了很多概念上的误导和实践中的争论,影响了上述目的的达成.例如,对于究竟该如何选择和定义合适的软件开发过程以更好地满足某个特定项目的要求,目前仍然缺少可靠的手段.甚至有些面向工业界的调研报告表明：在实际软件项目开发中,过程改进（例如引入新的工具或者方法）的主要驱动力是佚闻.试图厘清软件组织与管理话题的若干核心概念,系统梳理软件组织和管理方法的特征,并且以软件发展的历史为主线,介绍软件组织与管理方法的历史沿革,整理出这种历史沿革背后的缘由.在此基础上,讨论和总结若干发现,以期为研究者和实践者提供参考.     

一种基于SPC的软件过程质量分析方法

一个项目的开发活动是很多软件过程的集合,不同软件过程之间关联性很强,成功地分析特定软件过程质量的关键是确保软件过程分析的独立性,剔除来自于其他过程的影响。传统Shewhart控制图基于统计假设检验理论,能够区分软件过程中的偶然因素和系统因素,但Shewhart控制图是全控图,无法区分过程之间的影响。为解决这种问题,定义软件过程的总质量和分质量,把系统因素细分为外部系统因素和内部系统因素,并总结软件过程质量诊断表,以使用控制图和选控图来帮助诊断导致软件过程质量异常的偏差源。