Search

Active consumer participation is seen as an integral part of the emerging smart grid. Examples include demand-side management programs, incorporation of consumer-owned energy storage or renewable energy units, and active energy trading. However, despite the foreseen technological benefits of such consumer-centric grid features, to date, their widespread adoption in practice remains modest. To shed light on this challenge, this paper explores the potential of prospect theory, a Nobel-prize winning theory, as a decision-making framework that can help understand how risk and uncertainty can impact the decisions of smart grid consumers. After introducing the basic notions of prospect theory, several examples drawn from a number of smart grid applications are developed. These results show that a better understanding of the role of human decision making within the smart grid is paramount for optimizing its operation and expediting the deployment of its various technologies.

Advances in cognitive radio networks have primarily focused on the design of spectrally agile radios and novel spectrum sharing techniques that are founded on Expected Utility Theory (EUT). In this paper, we consider the development of novel spectrum sharing algorithms in such networks taking into account human psychological behavior of the end-users, which often deviates from EUT. Specifically, we consider the impact of end-user decision making on pricing and management of radio resources in a cognitive radio enabled network when there is uncertainty in the Quality of Service (QoS) guarantees offered by the Service Provider (SP). Using Prospect Theory (a Nobel-Prize-winning behavioral economic theory that captures human decision making and its deviation from EUT), we design data pricing and channel allocation algorithms for use in cognitive radio networks by formulating a game theoretic analysis of the interplay between the price offerings, bandwidth allocation by the SP and the service choices made by end-users. We show that, when the end-users under-weight the service guarantee, they tend to reject the offer which results in under-utilization of radio resources and revenue loss. We propose prospect pricing, a pricing mechanism that can make the system robust to decision making and improve radio resource management. We present analytical results as well as preliminary human subject studies with video QoS., To appear in IEEE TCCN

The capacity to reflect on past practice is important for continuous learning in software development. Reflection often takes place in cycles of experience followed by conscious application of learning from that experience, during which a software developer might explore comparisons, ponder alternatives, take diverse perspectives, and draw inferences, especially in new and/or complex situations. Such reflective practice has been shown in different disciplines to be an effective developmental practice for organizations, for teams, and for individuals. The guest editors of this special issue on reflection describe the concept in general and the selected articles in particular.

Lying is an understudied activity, especially in the software field. Yet lying is apparently quite common. In a 2006 survey of software practitioners, 86 percent of the respondents had encountered such lying. The most common occurrences were in estimation and status reporting, with those forms of lying happening on 50 percent of projects, some respondents saying even 100 percent. Respondents said that when lying happens, developers at the bottom level of the management hierarchy are most aware of the lying; they often know it's happening even when their management doesn't. Respondents also provided numerous suggestions on how to diminish or eliminate lying. However, many suggested that it's human nature to lie and that little can be done about it.

We've invited five renowned experts in software testing to give a brief answer to an admittedly broad question: does the practice of software testing effectively meet industry needs?

This is a closed-book quiz. Quick, now - what percentage of software projects fail? Let me hazard a guess as to your answer. Odds are, you said something like "70 percent." Am I right? Now, I want to analyze why you said whatever you said. A friend of mine, Nicholas Zvegintzov (the Chief Guru of software maintenance), likes to say that, if you track down the sources of the things we "know" in our field, you'll find that what we thought was a plethora of sources for that knowledge generally boils down to only a precious few. That raises the question "Where do we get our information on software failure rates?" I've seen software failure trumpeted from so many academic research papers that I had to quit counting (they tend to see a "software crisis" and then say that the research work they're describing will help eliminate it). However, if you closely examine the citations they use to support the claims of crisis, over and over again the citations boil down to one primary source, the Standish Chaos Reports. And, if you take matters one step further, the papers generally cite the 1994 report. I want to question the unquestionable status of that Standish report. That's because, you see, my own observations lead me to believe that something is terribly wrong with those Standish findings.

With the advantage of more than 25 years' hindsight, this twenty-first century author looks askance at the "crisis" in software practice and expresses deep concern for a crisis in software research. >

The authors describe an issue that they think is extremely important: the relationship between applications and solutions in the software engineering and information systems fields. In particular, they believe the fields desperately need a taxonomy of application domains, a taxonomy of solution approaches, and a mapping between the two. This article has a Web extra that offers an interview with one of the article's authors, Robert L. Glass, about the "dark side" of this topic.

Almost everyone agrees that there is a gender gap in computer science, where there are far too few females participating in the field. But does that gap occur in the whole of the field of computing? This sounding board explores the notion that the gap is unique to CS, and that any solution to the problem must occur within that field and not the broader field of computing.

Software standards. Now there's a subject that brooks no "loyal opposition," right? Standards are material provided by some software god, biblically significant, subject to no doubt? In recent years I've come to question all that.In 2006, my colleague Johann Rost wrote a guest Loyal Opposition column on the standard for requirements documents. He explained that at the conceptual level he understood the standard quite well, but at the implementation level he found it impossible to follow. I offered him sympathy, hosted his column here, and sort of forgot about it. Time passed. Another colleague, Barbara Kitchenham, was beginning to struggle with certain software standards. One standard gave "inappropriate advice for measuring software engineering processes." Another standard was "not suitable for measuring the design quality of a software product." Echoing Johann's concerns, Barbara commented that "experienced designers will be able to construct a number of different interpretations of the standard, implying that [it] is not a standard at all." Barbara pointed me at yet another critic of software standards, Magne Jorgensen. He noted that one standard for software quality "requires quality measurement and at the same time admits that there are no (universally) accepted quality measures".

The issue of research rigor versus relevance has been bandied about in the halls of computing for several decades now. This issue is about trying to ensure that research is not only rigorous, a goal we all support but also relevant to practice, a goal that at least practitioners support wholeheartedly. To address this issue, Michael Rosemann and Iris Vessey recently published an interesting proposal ("Toward Improving the Relevance of Information Systems Research to Practice: The Role of Applicability Checks," MIS Quarterly, Mar. 2008, pp. 1-22). This paper focuses on their proposal because computing and software people seldom read the IS literature and thus are likely unaware of it. The proposal is astonishingly simple yet potentially powerful.

This article looks at what happens when you combine the four goal-driven approaches to testing classification (requirements-driven, statistics-driven, and risk-driven) with the three phase-driven approaches (unit testing, integration testing, and system testing).

Work on test case classification published 16 years ago is still valid for software engineers.

Three anecdotes show how one member of a work team can decrease the whole team's productivity.

The software development process and the resulting product are so complex that no error-detecting approach will ever be able to produce error-free software. The test coverage analyzer was a wonderful tool for measuring how well-tested a piece of software. First, the software being tested is instrumented so that the tool would capture which of the software's logic segments had been executed. Then a suite of test cases are run against that software and learned which segments had been executed, and how many times. The Test Coverage Analyzer concept, in whatever form it takes today, is still important and useful. And so are all the other error- removal processes we've developed over the years. But it will take a pretty elaborate combination of testing approaches to even let us produce truly reliable software.

People might love to support underdogs, but they also love to kick them when they're down. And, at this point in time at least, software is the world's technological underdog!

Intuition might be a better decision-making approach for software engineering than you suppose.

Software development currently seems to take a "Roman" approach; that is, it focuses on the contributions of a group of programmers at an organization. Instead, it should take a "Greek" approach, focusing on the contributions of individual, self-motivated programmers. But don't let any unorganized Barbarian programmers near!

Persistent software errors-those which are not discovered until late in development, such as when the software becomes operational-are by far the most expensive kind of error. Via analysis of software problem reports, it is discovered that the predominant number of persistent errors in large-scale software efforts are errors of omitted logic..., that is, the code is not as complex as required by the problem to be solved. Peer design and code review, desk checking, and ultrarigorous testing may be the most helpful of the currently available technologies in attacking this problem. New and better methodologies are needed.

For microwave and millimeter-wave applications, there is increasing interest in using films rather than bulk ferrites. In some cases, such as magnetostatic wave devices, films provide definite performance advantages. In other cases, films may provide lower cost, smaller size, and enhanced compatibility with planar circuit designs such as monolithic microwave integrated circuits (MMIC). The author reviews some of the progress that has been made in development of single-crystal and polycrystalline ferrite films. He describes some of the ideas that are currently being considered for making these ferrites compatible with MMICs. The materials considered include garnets, spinels, and hexagonal ferrites. >

Modular decomposition offers a way to ascertain a software theft. Morevoer, the method is straightforward enough for a software-illiterate judge or jury to understand