A canonical theory of dynamic decision-making

Decision-making behavior is studied in many very different fields, from medicine and eco- nomics to psychology and neuroscience, with major contributions from mathematics and statistics, computer science, AI, and other technical disciplines. However the conceptual- ization of what decision-making is and methods for studying it vary greatly and this has resulted in fragmentation of the field. A theory that can accommodate various perspectives may facilitate interdisciplinary working. We present such a theory in which decision-making is articulated as a set of canonical functions that are sufficiently general to accommodate diverse viewpoints, yet sufficiently precise that they can be instantiated in different ways for specific theoretical or practical purposes. The canons cover the whole decision cycle, from the framing of a decision based on the goals, beliefs, and background knowledge of the decision-maker to the formulation of decision options, establishing preferences over them, and making commitments. Commitments can lead to the initiation of new decisions and any step in the cycle can incorporate reasoning about previous decisions and the rationales for them, and lead to revising or abandoning existing commitments. The theory situates decision-making with respect to other high-level cognitive capabilities like problem solving, planning, and collaborative decision-making. The canonical approach is assessed in three domains: cognitive and neuropsychology, artificial intelligence, and decision engineering

Dynamic Analysis can be Improved with Automatic Test Suite Refactoring

Context: Developers design test suites to automatically verify that software meets its expected behaviors. Many dynamic analysis techniques are performed on the exploitation of execution traces from test cases. However, in practice, there is only one trace that results from the execution of one manually-written test case. Objective: In this paper, we propose a new technique of test suite refactoring, called B-Refactoring. The idea behind B-Refactoring is to split a test case into small test fragments, which cover a simpler part of the control flow to provide better support for dynamic analysis. Method: For a given dynamic analysis technique, our test suite refactoring approach monitors the execution of test cases and identifies small test cases without loss of the test ability. We apply B-Refactoring to assist two existing analysis tasks: automatic repair of if-statements bugs and automatic analysis of exception contracts. Results: Experimental results show that test suite refactoring can effectively simplify the execution traces of the test suite. Three real-world bugs that could previously not be fixed with the original test suite are fixed after applying B-Refactoring; meanwhile, exception contracts are better verified via applying B-Refactoring to original test suites. Conclusions: We conclude that applying B-Refactoring can effectively improve the purity of test cases. Existing dynamic analysis tasks can be enhanced by test suite refactoring

Technology assessment of advanced automation for space missions

Six general classes of technology requirements derived during the mission definition phase of the study were identified as having maximum importance and urgency, including autonomous world model based information systems, learning and hypothesis formation, natural language and other man-machine communication, space manufacturing, teleoperators and robot systems, and computer science and technology

Case Management Program for the Frail Elderly, June 2005

The Case Management Program for the Frail Elderly (CMPFE) is a coordinated comprehensive system that strives to provide Iowa’s frail elderly clients with the opportunity to make their own choices regarding long-term care and to receive services in the home and community setting

Space biology initiative program definition review. Trade study 2: Prototype utilization in the development of space biology hardware

The objective was to define the factors which space flight hardware developers and planners should consider when determining: (1) the number of hardware units required to support program; (2) design level of the units; and (3) most efficient means of utilization of the units. The analysis considered technology risk, maintainability, reliability, and safety design requirements for achieving the delivery of highest quality flight hardware. Relative cost impacts of the utilization of prototyping were identified. The development of Space Biology Initiative research hardware will involve intertwined hardware/software activities. Experience has shown that software development can be an expensive portion of a system design program. While software prototyping could imply the development of a significantly different end item, an operational system prototype must be considered to be a combination of software and hardware. Hundreds of factors were identified that could be considered in determining the quantity and types of prototypes that should be constructed. In developing the decision models, these factors were combined and reduced by approximately ten-to-one in order to develop a manageable structure based on the major determining factors. The Baseline SBI hardware list of Appendix D was examined and reviewed in detail; however, from the facts available it was impossible to identify the exact types and quantities of prototypes required for each of these items. Although the factors that must be considered could be enumerated for each of these pieces of equipment, the exact status and state of development of the equipment is variable and uncertain at this time