27 September 1999 Crisis Management William L. Scherlis Carnegie Mellon University School of Computer Science

27 September 1999 NSF Software Workshop2 Crisis Management An Application Case Study –What is Crisis Management –Crisis Management technologies –Crisis Management challenges for software technology research 1. “Software Swat” 2. Composition on demand 3. Managing rapid change 4. Code-ification 5. Quality: analysis, assurance, validation 6. Human interface

27 September 1999 NSF Software Workshop3 Dimensions of Crisis Management (CM) Context Dimensions Distinct phases of activity –Planning –Preparedness/Mitigation –Response –Recovery Broad spectrum of players –FEMA –State, Local –NGOs –Business –Citizens Diversity of artifacts –Data inputs –Databases –Reports and documents –Applications –Communications channels Dimensions of Challenge Interdependent organizations –Federal/state/local, NGOs, utilities, private sector supplies, etc. –Thousands of organizations potentially involved –Wide variation in access to IT resources Organizational structure varies by phase –C 2 during response Situation awareness Decision support –Federation during planning Interoperation and metadata –Transactional during recovery People under stress –Human-systems interaction

27 September 1999 NSF Software Workshop4 CM Technologies Examples Reliable communications Information integration –Multi-source data analysis –Variable quality –Geographical info Modeling and simulation “Instant bureaucracy” Situation awareness Collaboration E-Commerce Supply chain creation –Inventory management “Forward deployment” –Business transactions Pre-certification Citizen single point-of-access –Information –Transactions Authentication and trust –Citizens, responders, suppliers, organizations –Reconfigurable authorization Information escrow

27 September 1999 NSF Software Workshop5 1. Software Swat Teams Key Software Research Issues Elements of a “Software Swat” capability –Rapid assembly of reliable teams, components, and tools The aggressive iterative process: –Requirements elicitation and analysis –Baseline technologies modeling –Contextual system design –Patterns of integration –Adaptation and assembly –Analysis, testing, and assurance Early deployment Continuous improvement and re-release –No new bugs –Rapid response to unanticipated needs –Rest on principles of predictability of evolvable processes Predictable outcomes Adjustment of features, quality, performance

27 September 1999 NSF Software Workshop6 2. Composition on demand Key Software Research Issues Composition: rapid system assembly and adaptation –Rapid integration of subsystems/components Overcome diverse kinds of incompatibilities with Software Architecture Use component attributes to enable predictable integration Seek compositionality: Predict properties of systems from properties of components. –Without compositionality, the entire system must be retested –Analyze/assure component properties just once. –Rapid information integration Reconcile/adapt similar data models Program understanding to capture/express data design –Provide information assurance despite rapid assembly Emply diverse techniques to adapt components for “safe” use –Sandbox, wrap, transform, etc.

27 September 1999 NSF Software Workshop7 3. Managing Rapid Change Key Software Research Issues Composition: rapid system assembly and adaptation –Enable geographically dispersed teams to collaborate Example: Oklahoma City rapid software integration Information sharing (and access control) Information awareness Coordination of effort (i.e., concurrency control) –Rapid adaptation of components and assemblies With predictable results: –Use analyses to predict the effects of change –Use specifications to avoid full re-analysis and testing –Use manipulations to facilitate functional change –Continuous improvement Rapid early deployment Iterate and update while in use (Also important for operational e-commerce sites) Improvements in components, integration, user interface, etc. –Assimilate new releases from component suppliers

27 September 1999 NSF Software Workshop8 4. Quality: Analysis, Assurance, Validation Key Software Research Issues Quality: Getting the important things right –Managing security-vs-responsiveness Now: High security usually means highly constrained functionality –Validation of integration Metadata about quality, sourcing, etc. Trace conclusions/results to sources and retain audit trail Compositionality The “good-enough” test –Units, Order-of -magnitude, Reasonableness –Models and simulations Develop explicit domain models to frame specifications and assurance Exploit code-ified domain models –Crisis management exercises The usual mode of operation for crisis responders Include the IT dimension –Augmented reality Modeling  Reality

27 September 1999 NSF Software Workshop9 5. Creating the Discipline Key Software Research Issues Code-ification of new domains –Capture using domain-specific language and domain-specific tools –Example domains FEMA business rules Information policy: privacy, access Response processes Situation awareness –Analysis Consequences of access changes Business rule interactions

27 September 1999 NSF Software Workshop10 6. Crisis Management User Interfaces Key Software Research Issues Human interface –Rapid creation of new human interfaces Responders Citizens Business –Collaboration CM teams –Software engineering teams Communities –Citizens Under stress Diverse information and transaction needs –Responders Under stress Diverse information and transaction needs

27 September 1999 NSF Software Workshop11 Crisis Management An Application Case Study –What is Crisis Management –Crisis Management technologies –Crisis Management challenges for software technology research 1. “Software Swat” 2. Composition on demand 3. Managing rapid change 4. Code-ification 5. Quality: Analysis, assurance, validation 6. Human interface –Success in Crisis Management depends increasingly on a solid foundation of software technologies