The empirical investigation of Perspective-Based Reading

We consider reading techniques a fundamental means of achieving high quality software. Due to the lack of research in this area, we are experimenting with the application and comparison of various reading techniques. This paper deals with our experiences with a family of reading techniques known as Perspective-Based Reading (PBR), and its application to requirements documents. The goal of PBR is to provide operational scenarios where members of a review team read a document from a particular perspective, e.g., tester, developer, user. Our assumption is that the combination of different perspectives provides better coverage of the document, i.e., uncovers a wider range of defects, than the same number of readers using their usual technique.To test the effectiveness of PBR, we conducted a controlled experiment with professional software developers from the National Aeronautics and Space Administration/Goddard Space Flight Center (NASA/GSFC) Software Engineering Laboratory (SEL). The subjects read two types of documents, one generic in nature and the other from the NASA domain, using two reading techniques, a PBR technique and their usual technique. The results from these experiments, as well as the experimental design, are presented and analyzed. Teams applying PBR are shown to achieve significantly better coverage of documents than teams that do not apply PBR.We thoroughly discuss the threats to validity so that external replications can benefit from the lessons learned and improve the experimental design if the constraints are different from those posed by subjects borrowed from a development organization.     

An internally replicated quasi-experimental comparison of checklistand perspective based reading of code documents

The basic premise of software inspections is that they detect and remove defects before they propagate to subsequent development phases where their detection and correction cost escalates. To exploit their full potential, software inspections must call for a close and strict examination of the inspected artifact. For this, reading techniques for defect detection may be helpful since these techniques tell inspection participants what to look for and, more importantly, how to scrutinize a software artifact in a systematic manner. Recent research efforts investigated the benefits of scenario-based reading techniques. A major finding has been that these techniques help inspection teams find more defects than existing state-of-the-practice approaches, such as, ad-hoc or checklist-based reading (CBR). We experimentally compare one scenario-based reading technique, namely, perspective-based reading (PBR), for defect detection in code documents with the more traditional CBR approach. The comparison was performed in a series of three studies, as a quasi experiment and two internal replications, with a total of 60 professional software developers at Bosch Telecom GmbH. Meta-analytic techniques were applied to analyze the data     

An experiment to assess the cost-benefits of code inspections inlarge scale software development

We conducted a long term experiment to compare the costs and benefits of several different software inspection methods. These methods were applied by professional developers to a commercial software product they were creating. Because the laboratory for this experiment was a live development effort, we took special care to minimize cost and risk to the project, while maximizing our ability to gather useful data. The article has several goals: (1) to describe the experiment's design and show how we used simulation techniques to optimize it; (2) to present our results and discuss their implications for both software practitioners and researchers; and (3) to discuss several new questions raised by our findings. For each inspection, we randomly assigned three independent variables: (1) the number of reviewers on each inspection team (1, 2, or 4); (2) the number of teams inspecting the code unit (1 or 2); and (3) the requirement that defects be repaired between the first and second team's inspections. The reviewers for each inspection were randomly selected without replacement from a pool of 11 experienced software developers. The dependent variables for each inspection included inspection interval (elapsed time), total effort, and the defect detection rate. Our results showed that these treatments did not significantly influence the defect detection effectiveness, but that certain combinations of changes dramatically increased the inspection interval     

Software component certification

Although the stringent requirements of some critical applications may require independent certification, the authors see software developer self-certification as a viable alternative in many other cases. They accept that using software certification laboratories (SCLs) may work well for certain software distribution models, but they cannot be applied to all types of software development. The approach has several drawbacks. For example, an SCL may work well for larger software houses that ship mass-marketed software applications to the public, but it is less satisfactory for smaller developers who make reusable components or safety-critical software or for developers who belong to the freeware community     

Identifying quality-requirement conflicts

Without a well-defined set of quality-attribute requirements, software projects are vulnerable to failure. The authors have developed QARCC, a knowledge-based tool that helps users, developers, and customers analyze requirements and identify conflicts among them     

软件的可靠性测试流程设计分析

软件可靠性测试是旨在保证用户可以正常运行软件,软件设计者需要在开发阶段对软件的可靠性水平进行评价,并验证产品软件达到开发者预定的可靠性要求的有效途径。从软件可靠性测试中暴露出来的,软件不同功能存在的不同程度的缺陷,开发者对其进行相应的纠错和排错措施后,可以令软件的可靠性产生不同程度的提高。     

Flexibility as a design driver [systems analysis]

Ambiguous requirements and those that emerge late in the design cycle often complicate development and throw off established schedules. The authors describe how reformulating information missing at the design stage into a flexibility requirement can turn the absent data into a design driver. Designers constantly run into issues that have yet to be understood through specification, system design, or standardization. Changes in evolving technologies and businesses often result in unstable system requirements. Reliable hardware or mechanical details might not be available until very late in the development process. Yet engineers must initiate software development even though some subsystem details have not yet been completely defined. Missing information and related flexibility requirements can lead to a design plagued by many well-known problems that affect performance, modularity, scalability, and clear separation of concerns. In some cases, developers must sacrifice rules of thumb to maintain planned development schedules. Providing flexibility for everything in the system isn't possible, so developers will always need to determine the static requirements and explicitly state where continued development and rapid modification require flexibility     

基于TextRank的软件变更任务搜索术语识别

在软件工程的演进或维护阶段,有很多软件变更要求需要软件开发人员处理,这些变更要求通常都使用自然语言文本进行编制,而且通常涉及一个或多个相关问题域.软件开发人员要将这些概念准确映射到软件项目中的相应源码位置,已进行所要求的变更.完成这样的映射需建立若干搜索术语项,并在项目中进行搜索.而研究表明,开发人员在为任务变更提出准确而合适的搜索条件时具有一些困难.因此本文提出了一种基于TextRank的软件变更任务搜索术语的识别方法,通过分析自然语言描述的任务来识别和提出软件变更的搜索术语项,以提高搜索的准确性、平均精度和召回率.     

Correlations between bugginess and time-based commit characteristics

Modern software is often developed over many years with hundreds of thousands of commits. Commit metadata is a rich source of time-based characteristics, including the commit’s time of day and the commit frequency and seniority of its author. The “bugginess” of a commit is also a critical property of that commit. In this paper, we investigate the correlation between a commit’s time-based characteristics and its “bugginess”; such results can be useful for software developers and software engineering researchers. For instance, developers or code reviewers might be well-advised to thoroughly verify commits that are more likely to be buggy. In this paper, we study the correlation between a commit’s bugginess and the time of day of the commit, the day of week of the commit, the commit frequency and seniority of the commit authors, and whether or not the developers have marked a commit as a “stable” commit. We survey three widely-used open source projects: the Linux kernel, PostgreSQL, and the Xorg server. Our main findings include: (1) commits between midnight and 4 AM (referred to as late-night commits) are significantly buggier and commits between 8 AM and noon are less buggy, implying that developers may want to double-check their own late-night commits; (2) daily-committing developers produce less-buggy commits, indicating that we may want to promote the practice of daily-committing developers reviewing other developers’ commits; (3) the bugginess of commits versus day-of-week varies for different software projects; and (4) stable commits are significantly less buggy than commits in general.     

Developing groupware for requirements negotiation: lessons learned

Defining requirements is a complex and difficult process, and defects in the process often lead to costly project failures. There is no complete and well-defined set of requirements waiting to be discovered in system development. Different stakeholders: users, customers, managers, domain experts, and developers, come to the project with diverse expectations and interests. Requirements emerge in a highly collaborative, interactive, and interdisciplinary negotiation process that involves heterogeneous stakeholders. At the University of Southern California's Center for Software Engineering, we have developed a series of groupware implementations for the WinWin requirements negotiation approach. The WinWin approach involves having a system's success-critical stakeholders participate in a negotiation process so they can converge on a mutually satisfactory or win-win set of requirements. The WinWin groupware system, which has evolved over four generations, enables and facilitates heterogeneous stakeholder participation and collaboration. Each generation reflects an increase in our understanding of what is needed for successful WinWin groupware operations and technology support. The authors present the major lessons they learned during WinWin's development     

Leveraging distributed software development

The Internet has been changing the way people collaborate on software development, offering certain advantages but also creating new requirements. Internet based collaboration does make a wider base of talent available, but the development cycles running at Internet speeds require maintaining higher levels of precision. From a project management perspective, communication is a key factor in Internet based development. Internet based collaboration requires effective team communication. The authors point out that when a development team isn't communicating well, it is nearly impossible to create and validate design solutions and manage the team's deliverables. So while Internet collaboration offers a number of advantages, the friction created by distributed (therefore delayed) communication typically increases the overhead associated with sharing project information. And the technology itself, including system interoperability and the synchronous or asynchronous collaboration tools, can create problems in a distributed development environment. As the complexities of distributed collaborative development environments increase, frameworks designed for such environments will become essential. The authors describe one such framework called SoftDock, and the new technologies it exploits. It lets developers analyze, design, and develop software from component models     

Pragmatic and Opportunistic Reuse in Innovative Start-up Companies

Reusing software components and services lets software vendors quickly develop innovative applications and products. According to current literature and experience reports, software development can't integrate functionality successfully without formal component and service selection and integration procedures. Here, the authors discuss two start-up companies that have each developed a product using a pragmatic approach to third-party functionality reuse and integration. Developing products and services pragmatically places requirements on the relationship between the software developer and the third-party functionality provider. The authors discuss the architectural impacts of decisions made during integration. These experiences show other software developers how to speed up product development with minimal risk.     

基于社区软件外包服务过程的质量评价方法

Outsourcing software development to the community developers is a promising model to help reduce software development cost and improve development efficiency. In this paper, we present a method to evaluate the quality of service in the managing such community-based software outsourcing process. In the community-based software outsourcing service, a customer (e.g., a software company) firstly releases the requirement and design specifications of a software system to the community, then the community helps to decompose the whole development tasks into a set of fine-grained tasks (including programming, designing test cases, testing, etc) and allocate them to community developers (programmers, testers, project managers, etc). These service providers work to fulfill the tasks and submit results to the community. In this service, quality is quite important and it is necessary to evaluate the quality of both final submitted software entities and various development activities, to ensure that all the initial requirements have been completely and correctly accomplished. In our quality evaluation method, there are three types of objects whose service quality need to be evaluated, i.e., products, behaviors and people. Specifically speaking, they are the deliverables (codes, testcases, test records) submitted by each service provider, the development process, and various community developers, respectively. For each type of the objects, we designed five dimensions of quality indicators, i.e. time and efficiency, price and cost, quality of service content, resources and conditions, reputation and risk. A set of refined quality indicators is designed for each of the five dimensions. Aiming at each quality indicator, we put forward the corresponding measurement method, i.e., quantitatively calculating the value of each quality indicator based on the original data automatically collected from the community platform and some subjective evaluation opinions from customers. Then, traditional AHP method is adopted to calculate the total quality of each service object (products, behavior and people) by accumulating all the quality indicators together. A prototype is developed to support above evaluation process and exhibit the results of quality evaluation. Results of the quality evaluation will help to: (1) monitor the execution of community-based software outsourcing service and to obtain up-to-date quality information; (2) find quality deficiencies timely and take remedial measures against them; (3) guide better selection of community developers ased on their historical quality records.     

Weaving together requirements and architectures

Software development organizations often choose between alternative starting points-requirements or architectures. This invariably results in a waterfall development process that produces artificially frozen requirements documents for use in the next step in the development life cycle. Alternatively, this process creates systems with constrained architectures that restrict users and handicap developers by resisting inevitable and desirable changes in requirements. The spiral life-cycle model addresses many drawbacks of a waterfall model by providing an incremental development process, in which developers repeatedly evaluate changing project risks to manage unstable requirements and funding. An even finer-grain spiral life cycle reflects both the realities and necessities of modern software development. Such a life cycle acknowledges the need to develop software architectures that are stable, yet adaptable, in the presence of changing requirements. The cornerstone of this process is that developers craft a system's requirements and its architecture concurrently, and interleave their development     

Applying formal specification in industry

Industrial software developers confront a bewildering array of software engineering techniques, each with its own promised benefits. The authors introduced formal methods into the specification and modeling activities of a security-critical system's development. They gauged the methods' effectiveness by comparing the results of the group that used them with those of the group that did not. They present their results in this paper     

Support for quality-based design and inspection

Before software developers can design quality into software, they must agree on the characteristics that denote software quality and the terms that will describe those characteristics. The author suggests an approach that defines quality terms, links them to software development and inspection, and provides for their consistent use by designers and inspectors     

Piloting XP on four mission-critical projects

According to proponents, extreme programming creates focused, efficient software development that heavily emphasizes customer involvement. As software developers for mission-critical two-way radio systems in Motorola's commercial, government, and industrial solutions sector, we'd been hearing a lot about XP's benefits. Software development teams constantly battle to increase productivity while maintaining or improving quality . Four Motorola teams piloted extreme programming to see if it would let them satisfy their customers' constantly changing requirements while improving productivity.     

Users’ involvement may help respect social and ethical values and improve software quality

Global informatization brings potential threats. It is possible to reduce them if software developers are aware of those threats and if customers insist on eliminating them. The survey described in the paper shows that future programmers are aware of numerous threats associated with global informatization. Many threats may be reduced by users’ involvement in the software process. Software developers should learn and develop cooperation with users, as emphasized in agile methodologies. It is a task for academic teachers to promote collaboration between software authors and users, to show how to organize it, and to convince programmers that it is valuable. Users’ involvement requires changes in the software life cycle and in the set of established processes. Such changes, in the form of additionally established processes and phases in the software development cycle, are identified in the paper. One recommended process is the software product assessment intended to elicit feedback from users. Users’ involvement may help to respect ethical and social values and to produce software adapted to user expectations.