Qualitative simulation predicts the set of possible behaviors...

ion and delegation: Agents can be made extensible and composable in ways that common iconic interface objects cannot. Because we can "communicate" with them, they can share our goals, rather than simply process our commands. They can show us how to do things and tell us what went wrong (Miller and Neches 1987). . Flexibility and opportunism: Because they can be instructed at the level of 16 BRADSHAW goals and strategies, agents can find ways to "work around" unforeseen problems and exploit new opportunities as they help solve problems. . Task orientation: Agents can be designed to take the context of the person's tasks and situation into account as they present information and take action. . Adaptivity: Agents can use learning algorithms to continually improve their behavior by noticing recurrent patterns of actions and events. Toward Agent-Enabled System Architectures In the future, assistant agents at the user interface and resource-managing agents behind the scenes will increas...

Modern society depends on computers for a number of critical tasks in which failure can have very high costs. As a consequence, high levels of dependability (reliability, safety, etc.) are required from such computers, including their software. Whenever a quantitative approach to risk is adopted, these requirements must be stated in quantitative terms, and a rigorous demonstration of their being attained is necessary. For software used in the most critical roles, such demonstrations are not usually supplied. The fact is that the dependability requirements often lie near the limit of the current state of the art, or beyond, in terms not only of the ability to satisfy them, but also, and more often, of the ability to demonstrate that they are satisfied in the individual operational products (validation). We discuss reasons why such demonstrations cannot usually be provided with the means available: reliability growth models, testing with stable reliability, structural dependability modelling, as well as more informal arguments based on good engineering practice. We state some rigorous arguments about the limits of what can be validated with each of such means. Combining evidence from these different sources would seem to raise the levels that can be validated; yet this improvement is not such as to solve the problem. It appears that engineering practice must take into account the fact that no solution exists, at present, for the validation of ultra-high dependability in systems relying on complex software.

Abstract not found

Ideally, a measure of the security of a system should capture quantitatively the intuitive notion of ‘the ability of the system to resist attack’. That is, it should be operational, reflecting the degree to which the system can be expected to remain free of security breaches under particular conditions of operation (including attack). Instead, current security levels at best merely reflect the extensiveness of safeguards introduced during the design and development of a system. Whilst we might expect a system developed to a higher level than another to exhibit ‘more secure behaviour ’ in operation, this cannot be guaranteed; more particularly, we cannot infer what the actual security behaviour will be from knowledge of such a level. In the paper we discuss similarities between reliability and security with the intention of working towards measures of ‘operational security ’ similar to those that we have for reliability of systems. Very informally, these measures could involve expressions such as the rate of occurrence of security breaches (cf rate of occurrence of failures in reliability), or the probability that a specified ‘mission ’ can be accomplished without a security breach (cf reliability function). This new approach is based on the analogy between system failure and security breach. A number of other analogies to support this view are introduced. We examine this duality critically, and have identified a number of important open questions that need to be answered before this quantitative approach can be taken further. The work described here is therefore somewhat tentative, and one of our major intentions is to invite discussion about the plausibility and feasibility of this new approach.

Authors with many theoretical and managerial perspectives argue that businesses commercializing technologically complex goods benefit when they collaborate closely with other businesses. Collaboration is viewed as a means for businesses to overcome competency limitations and to achieve the close configuration of components required for complex goods. We predict that collaborative relationships ofen assist businesses to produce complex goods, but that the relationships might also cause problems for the collaborating businesses. We find that firms using development-oriented and marketing-oriented collaborative relationships in the hospital sofhvare systems industry are less likely to shut down than businesses that follow independent approaches when the environment changes gradually, but businesses using collaborative relationships are sometimes susceptible to being acquired by other firms. Following a sudden environmental shock, businesses with collaborative relationships for activities central to the shock became more likely to shut down, while businesses with collaborative relationships for activities outside the focus of the shock became more likely to survive. The study critically evaluates and tests the widely stated but little-tested argument that interfirm collaboration is usually beneficial. The results address the issue of whether organizational choices affect comparative business performance. This paper investigates the survival of businesses that use collaborative relationships with other firms to commercialize complex goods. A growing literature has identified many benefits of interfirm collaboration. Several recent studies argue that businesses that collaborate closely with other organizations in order to develop and market complex goods will be more successful than businesses that operate independently (Jorde and

Motivated by the lack of availability demonstrated by current approaches to building servers for the Internet environment, we argue for a new approach to building highly-available systems that better reflects the realities of the modern server environment, namely that failures of hardware, software, and humans are inevitable. Our approach, denoted recovery-oriented computing (ROC), recognizes the inevitability of unanticipated failure and thus emphasizes recovery and repair rather than simple fault-tolerance. We define the properties that a ROC system must provide, and briefly consider how they might be achieved.

Increased automation in complex systems has led to changes in the human controller's role and to new types of technology-induced human error. Attempts to mitigate these errors have primarily involved giving more authority to the automation, enhancing operator training, or changing the interface. While these responses may be reasonable under many circumstances, an alternative is to redesign the automation in ways that do not reduce necessary or desirable functionality or to change functionality where the tradeoffs are judged to be acceptable. This paper describes an approach to detecting error-prone automation features early in the development process while significant changes can still be made to the conceptual design of the system. The information about such error-prone features can also be useful in the design of the operator interface, operational procedures, or operator training. Introduction Today's large, complex systems often incorporate both human and automated control and mon...

The majority of attacks made upon modern computers have been successful due to the exploitation of the same errors and weaknesses that have plagued computer systems for the last thirty years. Because the industry has not learned from these mistakes, new protocols and systems are not designed with the aspect of security in mind; and security that is present is typically added as an afterthought. What makes these systems so vulnerable is that the security design process is based upon assumptions that have been made in the past; assumptions which now have become obsolete or irrelevant. In addition, fundamental errors in the design and implementation of systems repeatedly occur, which lead to failures. This

Abstract not found