Search

Feedback from software users, such as bug reports, is vital in the management of software projects. In GitHub, the feedback is typically expressed as new issues. Through filing issue reports, users may help identify and fix bugs, document software code, and enhance software quality via feature requests. In this paper, we aim at investigating some characteristics of issues to facilitate issue management and software management. We investigate the important degrees of behaviors that are related to issues in popular projects to assess the importance of issues in GitHub and analyze the effectiveness of issue labeling for issue handling. Then, we explore the patterns of issue commits over time in popular projects based on visual analysis and obtain the following results: we find that the behaviors that are related to issues play important roles in the GitHub. We also find that the time distribution of issue commits follows a three-period development model, which approximately corresponds to the project life cycle. These results may provide a new knowledge about issues that can help managers manage and allocate project resources more effectively and even reduce software failures.

Although traceability information is vital to many software engineering activities, agile development approaches rarely use it because of the extra effort required. In this industry case study, the authors report the results of applying their lightweight semiautomated method that integrates traceability into software architecture developed with an agile process like Scrum. [ABSTRACT FROM PUBLISHER]

Editor-in-chief Forrest Shull talks about the practical application of software analytics. [ABSTRACT FROM PUBLISHER]

Software's impact on various industries is the topic of 15 columns published in IEEE Software since 2010. This article describes how to quantify software's impact using metrics such as compound average growth rate and software mileage. [ABSTRACT FROM PUBLISHER]

A new generation of development environments takes a radical approach to communication and coordination by fusing social networking functionality with flexible, distributed version control. Through these transparent work environments, people, repositories, development activities, and their histories are immediately and easily visible to all users. Developers quickly acquire the skill to interpret this rich information to find useful resources, connect with people, solve technical problems, and enhance their learning opportunities. This article presents the results of a qualitative study of users of one such environment, GitHub. It describes how transparency helps developers on GitHub manage their projects, handle dependencies more effectively, reduce communication needs, and figure out what requires their attention. Although transparency is not a silver bullet, the approach shows great promise for enhancing collaboration and coordination. The Web extra at http://www.youtube.com/watch?v=LpGA2fmAHvM is a video of Joel Spolsky discussing the structure, software, technology, and culture of Stack Exchange. [ABSTRACT FROM PUBLISHER]

Oracle's Clive King and Chris Beal talk about hidden software on which we completely depend—the OS. Although OSs are highly reliable, no OS is perfect. So, when things go wrong in the OS running on modern systems, the needle-in-the-haystack analogy hardly begins to scratch the surface of the needed detective work. [ABSTRACT FROM PUBLISHER]

The primary sources of project risks and product problems are poor, missing, or changing requirements. Often, the underlying root cause is insufficient collaboration between business partners. This article provides insight into how to effectively collaborate in requirements engineering. We describe the Requirements Interchange Format (ReqIF) standard and technologies for seamless requirements development and management. I look forward to hearing from both readers and prospective column authors about this and the technologies and tools you want to know more about. [ABSTRACT FROM PUBLISHER]

Proponents of various processes and methods in the agile and lean communities have made many bold claims about usefulness, but those claims are rarely supported by empirical investigations. Data gathered from more than 12,000 work items collected over two years sheds light on Kanban versus Scrum.To acquire more knowledge about the performance of different agile or lean methods, scholars should conduct similar studies in different organizations in different application domains and with people of different cultures and competences. [ABSTRACT FROM PUBLISHER]

Although the discipline of software product management plays an important role in the development of successful products, each company adopts its practices in its own way. Regardless of variations, companies face common problems. This article identifies five problems that lean principles to software product management can help organizations avoid or solve. [ABSTRACT FROM PUBLISHER]

Lean practices use the principle of Little's law to improve the flow of value to the end user by eliminating sources of waste from a software development process. Little's law defines throughput as a ratio of work in process and cycle time. Increasing throughput (or productivity) requires continuously improving (that is, decreasing) cycle time while ensuring that the work-in-process limit doesn't exceed the capacity available to process the work. This article shares experiences regarding the role architecture plays in lean software management practices. Release plans that give as much emphasis to architecturally significant tasks as to feature-based high-priority functionality can achieve better outcomes by avoiding conditions that lead to wasted time and effort. The application of lean software development practices can improve with better practical guidance on how to manage architecture flow as well as feature flow. [ABSTRACT FROM PUBLISHER]

Owing to strong market growth for medical devices deployed in critical-care facilities, development organizations in medical engineering must continually look for opportunities to drive engineering efficiency and cost effectiveness. Furthermore, cycle time must decrease, the alignment of clinical workflow is breaking down departmental barriers, and an increased amount of product functionality is being realized in software. To help meet such challenges, adequate requirements engineering is necessary. Toward that end, Syngo (a business unit of the Imaging and Therapy division of Siemens) introduced Feature-Oriented Requirements Engineering (FORE) and developed a business case for using it in the context of a lean engineering program. FORE integrates with other engineering disciplines such as project management, software architecture, and test management. There was an error in the biographical information for Tobias Stenzel. Stenzel's biography should have indicated that he has an MS in industrial engineering and management from the University of Technology Karlsruhe, Germany. [ABSTRACT FROM PUBLISHER]

This study develops and empirically tests the idea that the impact of structural complexity on perfective maintenance of object-oriented software is significantly determined by the team strategy of programmers (independent or collaborative). We analyzed two key dimensions of software structure, coupling and cohesion, with respect to the maintenance effort and the perceived ease-of-maintenance by pairs of programmers. Hypotheses based on the distributed cognition and task interdependence theoretical frameworks were tested using data collected from a controlled lab experiment employing professional programmers. The results show a significant interaction effect between coupling, cohesion, and programmer team strategy on both maintenance effort and perceived ease-of-maintenance. Highly cohesive and low-coupled programs required lower maintenance effort and were perceived to be easier to maintain than the low-cohesive programs and high-coupled programs. Further, our results would predict that managers who strategically allocate maintenance tasks to either independent or collaborative programming teams depending on the structural complexity of software could lower their team's maintenance effort by as much as 70 percent over managers who use simple uniform resource allocation policies. These results highlight the importance of achieving congruence between team strategies employed by collaborating programmers and the structural complexity of software. [ABSTRACT FROM PUBLISHER]

Requirements engineering (RE) is a key discipline in software development and several methods are available to help assess and improve RE processes. However, these methods rely on prescriptive models of RE; they do not, like other disciplines within software engineering, draw directly on stakeholder perceptions and subjective judgments. Given this backdrop, we present an empirical study in RE process assessment. Our aim was to investigate how stakeholder perceptions and process prescriptions can be combined during assessments to effectively inform RE process improvement. We first describe existing methods for RE process assessment and the role played by stakeholder perceptions and subjective judgments in the software engineering and management literature. We then present a method that combines perceptions and prescriptions in RE assessments together with an industrial case study in which the method was applied and evaluated over a three-year period at TelSoft. The data suggest that the combined method led to a comprehensive and rich assessment and it helped TelSoft consider RE as an important and integral part of the broader engineering context. This, in turn, led to improvements that combined plan-driven and adaptive principles for RE. Overall, the combined method helped TelSoft move from Level 1 to Level 2 in RE maturity, and the employees perceived the resulting engineering practices to be improved. Based on these results, we suggest that software managers and researchers combine stakeholder perceptions and process prescriptions as one way to effectively balance the specificity, comparability, and accuracy of software process assessments. [ABSTRACT FROM AUTHOR]

Requirements management uses traceability information to maintain the consistency between requirements and between requirements and other software artifacts. Accordingly, the impact analysis technique depends on traceability information for an agile estimative of the implications of requirement changes. The need to be agile imposes specific demands on traceability that may bring difficulties for the management of requirements. This paper presents FIR (functionality-information-rule), an artifact that supports traceability by means of more specialized links, in order to accommodate such demands. A simple example illustrates the applicability of the FIR artifact and is used to discuss some of its benefits and challenges . [ABSTRACT FROM PUBLISHER]

A common question in practice is "what are the circumstances in which agile methodologies should be adopted for more effective software development?" For instance, is the agile method suited for the development of modern industrial automation software? Actually this is a hard problem to address, and the right answer can be determined only by the requirements and constraints of each individual project. The size of projects in the industrial automation arena varies from small-size software with limited specific functionality to large-scale software systems with comprehensive functionality and rigorous requirements. A number of agilists are seeking ways to expand the use of agile methodologies for efficient development of larger software-intensive projects and effective management of distributed development teams. However, for safety-critical industrial automation software development, caution should be exercised in employing agile methodologies, as the detailed analysis of each software elements is needed and the system may have intense interactions with other software and hardware systems. [ABSTRACT FROM PUBLISHER]

Small software firms find themselves in highly complex and turbulent environments that require dynamic capabilities to build, integrate, and reconfigure resources. While the literature describes a portfolio of dynamic capabilities that can help the small software firms in adaptation, there are no comprehensive approaches available. We use a sense-and-respond framework as a lens to study the dynamic capabilities in two software firms, Starter Inc. and Mature Inc. The framework integrated the activity- and firm-level capabilities related to input, process, and output of software development. The framework also revealed important variations in sense-and-respond practices as a reflection of differences in maturity between the two firms. We argue that the framework offered a comprehensive and useful approach to understand the dynamic capabilities in the two firms, and on that basis we suggest the principles for how managers can apply the framework to small software firms. [ABSTRACT FROM AUTHOR]

Web applications' functionality and user base have evolved along with the threat landscape. Although controls such as network firewalls are essential, they're wholly insufficient for providing overall Web application security. They provide security for underlying hosts and a means of communication, but do little to aid the application resist attack against its software implementation or design. Enterprises must therefore focus on the security of the Web application itself. But in doing so, questions immediately arise: "What could go wrong with my software? How vulnerable are my existing applications to the most common problems? What changes to my software development life cycle might affect these vulnerabilities?" The Open Web Application Security Project (OWASP; www.owa sp.org) Top Ten offers a starting point for figuring out what could go wrong. This installment of Building Security In presents metrics that can help quantify the impact that process changes in one life-cycle phase have on other phases. For the purposes of this short discussion, we've broken an applications life cycle into three main phases: design, deployment, and runtime. By organizing metrics according to life cycle in addition to OWASP type, insight from the derived quantitative results can potentially point to defective processes and even suggest strategies for improvement [ABSTRACT FROM PUBLISHER]

Historically, vendors have used their own methods for scoring software vulnerabilities, usually without detailing their criteria or processes. This creates a major problem for users, particularly those who manage disparate IT systems and applications. The Common Vulnerability Scoring System (CVSS) is a public initiative designed to address this issue by presenting a framework for assessing and quantifying the impact of software vulnerabilities. Organizations currently generating CVSS scores include Cisco, US National Institute of Standards and Technology (through the US National Vulnerability Database; NVD), Qualys, Oracle, and Tenable Network Security. CVSS offers the following benefits: 1) standardized vulnerability scores, 2) contextual scoring and 3) open framework. The goal is for CVSS to facilitate the generation of consistent scores that accurately represent the impact of vulnerabilities [ABSTRACT FROM PUBLISHER]

Domain-Specific Modeling is advancing with tools such as GME (Generic Modeling Environment) and MetaEdit+ among others. The key feature of these tools is that the modeling ontology is close to the problem so that solutions can be designed or developed in a specific domain, where the analyst or the developer is an expert. MOMENT is a model management platform that permits the definition of domain-specific models following an algebraic approach. In this paper, we present an architecture to integrate MOMENT into an industrial visual modeling environment so that their graphical capabilities can be used to visually define algebraic models. To achieve this goal, we identify the common elements of a visual modeling environment, as well as the associations between them and the formal elements of the MOMENT platform. These associations are stored in the same platform using it as a UML-like repository. An implementation for a specific modeling environment has been developed. This solution is presented by defining a graphical view (a graphical metaphor) for a specific algebraic metamodel through its interfaces. [ABSTRACT FROM PUBLISHER]

Experimental research in dependability has evolved over the past 30 years accompanied by dramatic changes in the computing industry. To understand the magnitude and nature of this evolution, this paper analyzes industrial trends, namely: 1) shifting error sources, 2) explosive complexity, and 3) global volume. Under each-of these trends, the paper explores research technologies that are applicable either to the finished product or artifact, and the processes that are used to produce products. The study gives a framework to not only reflect on the research of the past, but also project the needs of the future. [ABSTRACT FROM PUBLISHER]

This paper shows various applications of optical fiber sensors to absorption spectroscopy. Sensors for the monitoring of chromium in sewage water and for the colorimetry of gasoline samples are presented together with sensors for radiation dosimetry in radiotherapy and for lighting control in museum environments. In all these sensors, a combination of broadband and multi-band spectral measurements are collected using the same custom instrumentation unit consisting of LED light sources and an optical fiber microspectrometer. Extensions of the unit to implement other sensors making use of visible spectral range are discussed. The custom instrumentation implemented to address these sensors is their key unifying feature. It opens the possibility of addressing other sensors making use of absorption-based optrodes which present an analyte-modulated absorption spectrum in the visible spectral range [ABSTRACT FROM PUBLISHER]

Estimation of software size is a crucial activity among the tasks of software management. Work planning and subsequent estimations of the effort required are made based on the estimate of the size of the software product. Software size can be measured in several ways: Lines of code (LOC) is a common measure and is usually one of the independent variables in equations for estimating effort. There are several methods for estimating the final LOC count of a software system in the early stages. In this articIe, we report the results of the validation of the component-based method (initially proposed by Verner and Tate) for software sizing. This was done through the analysis of 46 projects involving more than 100,000 LOC of a fourth-generation language. We present several conclusions concerning the predictive capabilities of the method. We observed that the component-based method behaves reasonably, although not as well as expected for "global" methods such as Mark II function points for software size prediction. The main factor observed that affects the performance is the type of component. [ABSTRACT FROM AUTHOR]

The approach of the Year 2000 (Y2K) has called into question the condition of readiness of computer systems upon which organizations depend. Will these systems operate reliably after midnight, January 1, 2000, or will problems associated with date calculations cause failures that adversely affect users? This question has caused organizations to identify their critical systems, test these systems for Y2K problems, and take corrective action where necessary to ensure Y2K readiness. This paper examines various technical and management issues that Southwest Research Institute has dealt with in solving these problems [ABSTRACT FROM PUBLISHER]

Measures of project size are a prerequisite to successful quantitative management of software projects. One such measure that is gaining acceptance with commercial organizations is function points. This paper reports the results of an empirical research project into the consistency and limitations of function points as an a priori measure of system size compared to the traditional lines of code measure. The paper concludes that function points are a more consistent a priori mea- sure of system size. The results also indicate that the function point estimate of size is lower far analysts experienced both in software development and in function point estimation. [ABSTRACT FROM AUTHOR]

A good software project management theory should be simultaneously simple, general, and specific. To date, those objectives have been difficult to satisfy. This paper presents a candidate software management theory and shows that it satisfies those objectives reasonably well. Reflecting various alphabetical management theories (X, Y, Z), it is called the Theory W approach to software project management. [ABSTRACT FROM AUTHOR]

Understanding of software costs is important because of the overall magnitude of these costs (in 1985, roughly $70 billion per year in the U.S. and over $140 billion per year worldwide) and the fundamental impact software will have on our future quality of life. Section I of this paper discusses these issues. Section II, the main portion of the paper, discusses the two primary ways of understanding software costs. The "black-box" or influence-function approach provides useful experimental and observational in- sights oh the relative software productivity and quality leverage of various management, technical, environmental, and personnel options. The "glass-box" or cost distribution approach helps identify strategies for integrated software productivity and quality improvement programs, via such structures as the value chain and the software productivity opportunity tree. The individual strategies for improving software productivity identified in Section II are: • writing less code; • getting the best from people; • avoiding rework; • developing and using integrated project support environments. Section It provides overall surveys of early and recent progress along these and other lines identified by the opportunity tree. Better understanding of software costs leads to better methods of controlling software project costs, and vice versa. Section III discusses these issues. It points out that a good framework of techniques exists for controlling software budgets, schedules, and work completed, but that a great deal of further progress is needed to provide an overall set of planning and control techniques covering software product qualities and end-user system objectives. [ABSTRACT FROM AUTHOR]

The Cleanroom software development approach is in- tended to produce highly reliable software by integrating formal methods for specification and design, nonexecution-based program. development, and statistically based independent testing. In an empirical study, 15 three-person teams developed versions of the same software system (800-2300 source lines); ten teams applied Cleanroom, while five applied a more traditional approach. This analysis characterizes the effect of Cleanroom on the delivered product, the software development process, and the developers. The major results of this study are the following. 1) Most of the developers were able to apply the techniques of Cleanroom effectively (six of the ten Cleanroom teams delivered at least 91 percent of the required system functions). 2) The Cleanroom teams' products met system requirements more completely and had a higher percentage of successful operationally generated test cases. 3) The source code developed using Cleanroom had more comments and less dense control-flow complexity. 4) The more successful Cleanroom developers modified their use of the implementation language; they used more procedure calls and IF statements, used fewer CASE and WHILE statements, and had a lower frequency of variable reuse (average number of occurrences per variable). 5) All ten Cleanroom teams made all of their scheduled intermediate product deliveries, while only two of the five non-Cleanroom teams did. 6) Although 86 percent of the Cleanroom developers indicated that they missed the satisfaction of program execution to some extent, this had no relation to the product quality measures of implementation completeness and successful operational tests. 7) Eighty-one percent of the Cleanroom developers said that they would use the approach again. [ABSTRACT FROM AUTHOR]

A systems approach to analysis and control of software reliability is described which is intended to supplement conventional soft- ware reliability models which focus on program attributes under the control of the software professionals. The external view of software reliability is particularly appropriate at the two extreme phases of the life cycle: • during the concept development and project planning phases because during these very little is usually known about the internal at- tributes of the software • during the operations and maintenance (O&M) phase because very little can be done about the internal attributes of the software. A review of software reliability experience during the O&M phase is presented first. This is followed by the description of a basic failure model that supports a unified approach to software and hardware reliability and of the implications of that model for conventional software reliability approaches. Next the effect of management activities on reliability is investigated, and finally an outline of a combined hardware/ software reliability model suitable for the planning phase is presented. [ABSTRACT FROM AUTHOR]

In this experiment, seven software teams developed versions of the same small-size (2000-4000 source instruction) application soft- ware product. Four teams used the Specifying approach. Three teams used the Prototyping approach. The main results of the experiment were the following. 1) Prototyping yielded products with roughly equivalent performance, but with about 40 percent less code and 45 percent less effort. 2) The prototyped products rated somewhat lower on functionality and robustness, but higher on ease of use and ease of learning. 3) Specifying produced more coherent designs and software that was easier to integrate. The paper presents the experimental data supporting these and a number of additional conclusions. [ABSTRACT FROM AUTHOR]

Software Engineering Project Standards (SEPS) and their importance are presented in this paper by looking at standards in general, then progressively narrowing the view to software standards, to software engineering standards, and finally to SEPS. After defining SEPS, issues associated with the selection, support, and use of SEPS are examined and trends are discussed. A brief overview of existing software engineering standards is presented as the Appendix. [ABSTRACT FROM AUTHOR]

This paper summarizes the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation. [ABSTRACT FROM AUTHOR]

The Putnam model can be used to predict and manage software development projects. It is a management tool that takes, as input, easily obtained manpower data and produces cost and schedule estimates. This paper examines data from two real-time software projects and analyzes the applicability of the Putnam model. We propose a variation of the model which more reliably follows the staffing curve of real-time software applications. A critical analysis of the assumptions is presented and the parameters are reinterpreted so that they reflect the environment of embedded applications. Two projects are analyzed from actual data. It is shown how management decisions are reflected in the model. Even erratic and incomplete data can yield valuable conclusions. It is also shown that the model is appropriate to software developed with modem practices. We show how valuable management information can be obtained by laying out the data in a systematic manner. [ABSTRACT FROM AUTHOR]

-c_The theory of software science was developed by the late M. H. Halstead of Purdue University during the early 1970's. It was first presented in unified form in the monograph Elements of Software Science published by Elsevier North-Holland in 1977. Since it claimed to apply scientific methods to the very complex and important problem of software production, and since experimental evidence supplied by Halstead and others seemed to support the theory, it drew widespread attention from the computer science community. Some researchers have raised serious questions about the underlying theory of software science. At the same time, experimental evidence supporting some of the metrics continue to be presented. This paper is a critique of the theory as presented by Halstead and a review of experimental results concerning software science metrics published since 1977. [ABSTRACT FROM AUTHOR]

This paper reports the results of an experiment in applying large-scale software engineering procedures to small software projects. Two USC student teams developed a small, interactive application software product to the same specification; one using Fortran and one using Pascal. Several hypotheses were tested, and extensive experimental data collected. The major conclusions were as follows. • Large-project software engineering procedures can be cost-effectively tailored to small projects. • The choice of programming language is not the dominant factor in small application software product development. • Programming is not the dominant activity in small software product development. • The "deadline effect" holds on small software projects, and can be used to help manage software development. • Most of the code in a small application software product is devoted to "housekeeping." The paper presents the experimental data supporting these conclusions, and discusses their context and implications. [ABSTRACT FROM AUTHOR]

This paper describes project management methods used for controlling the life cycle of large-scale software systems deployed in multiple installations over a wide geographic area. A set of management milestones is offered along with requirements and techniques for establishing and maintaining control of the project. In particular, a quantitative measure of software quality is proposed based upon functional value, availability, and maintenance costs. Conclusions drawn are based on the study of several cases and are generally applicable to both commercial and military systems. [ABSTRACT FROM AUTHOR]

Software management is considered from the corporate headquarters viewpoint. This perspective encompasses all facets of management, but specifically dealt with are those that are brought to bear on software management obstacles and ways to cope with them are presented. Standardization is presented as the most effective management device available at the corporate level for enhancing the overall software posture. Corporate management actions available for favorably influencing the quality of software over its life cycle and research initiatives are described. [ABSTRACT FROM AUTHOR]

The importance of software in defense systems continues to intensify as new systems emerge in response to increasing threats and declining force levels. The need to manage this software as a critical component of defense systems over their life cycle is becoming widely recognized. A general awareness of this need as an institutional problem requiring special attention within the Office of the Secretary of Defense has been growing as software problems have reached top level defense management visibility with increasing regularity. Soft- ware costs are continuing to multiply in step with advancing weapons systems sophistication, and opportunities for cost avoidance now are leveraged against large dollar investments. These conditions characterize the computer industry at large, but very little overall focus has been visible to improve the software development process. Consequently, the Department of Defense (DoD) has undertaken a two part effort to accelerate both near-term and long-term improvements in software development for weapons system applications. These efforts, the establishment of software life cycle management policy and practices, and the vigorous development and application of new software technology are discussed in considerable depth. [ABSTRACT FROM AUTHOR]

Given society's increasing dependence on software-intensive systems, each business unit within an organization should examine its role in delivering and deploying secure systems. Software procurement is an early element of the process that organizations often leave out of the security equation until an incident occurs and sensitive materials, such as personally identifiable information from a customer database, are lost or misused. This article explores some useful concepts that help integrate security more firmly into the software-procurement process. In keeping with Basic Training's spirit, these concepts are merely food for thought - a conceptual framework for asking the right questions at the right time. For those involved with software or software procurement in an organization, it helps to start by asking potential vendors some simple questions about their software-development processes, education and training, and accountability [ABSTRACT FROM PUBLISHER]

In an historical overview of computer operations in scientific-technical environments from the second half of the 1950s to the mid-1960s, this article discusses the ways German universities and similar institutions initially used small computers. It reports on the emergence of high-level programming languages, the appearance and predominance of large batch-processing systems, and the arising efforts to reestablish a conversational mode of operations. [ABSTRACT FROM PUBLISHER]

The TR 440, a large-scale computer developed and manufactured by the German company AEG-Telefunken, was one of the first commercial time-sharing systems. This article focuses on the TR 440's software and software development between 1965 to 1974, describing the technical highlights and showing how the software development was managed, who was responsible for various parts, and how and why certain decisions were made. [ABSTRACT FROM PUBLISHER]