Skip to main content

Currently Skimming:

Part III The Future: Scenarios, Conclusions, and Recommendations, 9 Scenarios for the Future
Pages 275-295

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 275...
... Part III The Future: Scenarios, Conclusions, and Recommendations 
From page 277...
... Contemporary forms of simulation and virtual environments can support rapid prototyping, visualization, and human-in-the-loop testing. Human performance models and related analytic tools are often used, sometimes in conjunction with engineering models, to evaluate alternative designs early, eliminate impractical alternatives, and to narrow the choices and set parameter bounds on alternatives to be tested.
From page 278...
... , virtual environment technology, simulation, modeling and gaming technology, multimedia technology, and collaboration technology. Here we provide an overview of such a methodology in terms of four of the main HSI activity categories in Figure 2-3 and Table 2-1: 1.
From page 279...
... • A risk analysis identifying potential development risks.
From page 280...
... The interlinkage of descriptions should include the ability for any stakeholder to make annotations and recommendations, which can then be analyzed by the team when it is time to move from exploration to stakeholder commitment. Design Solutions As design is initiated and alternative function allocations between human and system considered, the representations described above will continue to be enriched and, in some cases transformed into more quantitative representations.
From page 281...
... These artifacts become the basis for visualization of the operational concepts and how they might play out. Evaluation Evaluation is ongoing throughout the development life cycle, with peaks at the incremental commitment milestones, as illustrated in Figure 2-3.
From page 282...
... This scenario for the future envisions it as the lead discipline in the system development life cycle. Current development practice tends to be dominated by the technical disciplines that are most salient for the particular system being built: software for informationprocessing-intensive systems, and various electrical, mechanical, and physical sciences for systems heavily dominated by electronics, structures, or sensors, respectively.
From page 283...
... This team is responsible for the aspects of system concept definition involving end-users, further defining requirements associated with the concept, communicating those requirements in appropriate shared representations to affiliated IPTs, such as software development or structural design, and working with those teams to develop specifications for aspects of the system affecting end-users, such as displays, operational processes, and communications. The HSI IPT would also have representation from individuals representing planning for operations support, such as manpower and personnel domains and training developers.
From page 284...
... Design methods are used to develop solutions, and evaluation approaches are applied to characterize performance. During each phase, the HSI IPT produces appropriate shared representations, such as display concepts and behavior 9-1 specifications, facility drawings, and process descriptions, to communicate design-relevant information to other specialties.
From page 285...
... Career ladders in both industry and government will be created to legitimize human-system integration and to emphasize HSI knowledgeability in promotion criteria. Workshops and continuing education programs for working professionals will emerge, including programs for making non-HSI people HSI knowledgeable.
From page 286...
... KNOWLEDGE-BASED PLANNING FOR HUMAN-SYSTEM INTEGRATION Many complex system development efforts begin with a core team of managers and systems engineers who may know that getting the HSI aspects right is important, but who have little knowledge of which HSI techniques work best in different situations, or of when such HSI techniques are no longer cost-effective. In helping such managers and systems engineers, another scenario for what may be achievable in the next 10 years with sustained investment in HSI support technology is the development, usage, and growth of a family of domain-specific tools for helping projects to assess their risks and to suggest what HSI skills, methods, and tools they would need to identify, analyze, prioritize, and mitigate HSI risks.
From page 287...
... • Recommended development timelines and staffing profiles. • Necessary levels of system acquisition, human-system integration, hardware engineering, software engineering, and C2 subject matter expert staffing required during the system life-cycle phases.
From page 288...
... While we have argued for the importance of these activities to successful design, we acknowledge that many of the current approaches for analysis of context of use can be time and labor intensive, require expertise to employ, and produce results that are not always packaged in a way that can readily be assimilated in the system development process. These factors combine to slow their adoption and limit their effectiveness.
From page 289...
... The first class of such services are the examples of combining list-based advertising entries from one system with map-based visualizations from a second system, using standardized address data representations as the common service-calling protocol, to provide interactive geographic summaries of opportunities that change dynamically with new textual entries to the original list.1 These quickly assembled services have been called "mashups" to emphasize that they have been constructed by bringing together two different data sets. These technology-centric developments have enabled new forms of shared usage and collaboration-at-a-distance, often on a massive scale, and often involving users who have no knowledge of one another other than through these new systems and forms of collaboration.
From page 290...
... A fifth class of such services involves the co-creation of knowledge resources by many users, with the expectation that the knowledge will be accessed by many more users -- a group-constructed encyclopedia, of which Wikipedia6 is the most well known of many instances. The pace of development using these new technologies is so swift that there are web sites dedicated to providing daily updates about the status of various Web 2.0 experiments, beta tests, and business propositions.7 Key characteristics of these developments are the reuse of technologies and services for new offerings, the diffuse and bottom-up nature of both the development effort, and the data accumulation through the contributions and negotiations of thousands of users.
From page 291...
... Systems Engineering for User Participation In 5 to 10 years, HSI professionals are still focused on identifying HSI needs, translating their findings into opportunities, developing prototypes, requirements, and ultimately designing solutions that respond to those needs. But the world has fundamentally changed and systems engineering and HSI professionals have anticipated these changes and are working in new ways.
From page 292...
... Another reason is that there are widgets embedded in the interfaces that enable users to build and create their own ways to track data based on what they think they really need. As individuals become recognized by their community for their contributions -- we can anticipate more and more participation in much the same way bloggers today do.
From page 293...
... Another change that can be anticipated is that HSI personnel become the experts in issue tracking and resolution as systems are now never finished -- but more dynamically evolving -- and in continuous beta mode. Their experience in requirements gathering and documentation has been successfully leveraged in this new role of keeper of the desired future state of the systems.
From page 294...
... allow users to make rapid changes that can provide new functionality to an obsolete technology so that it remains a worthwhile investment or a valuable part of defensive or offensive capability. In this chapter we have envisioned a future in which knowledge acquisition will no longer be a laborious manual process but will instead leverage the collective knowledge that naturally emerges as domain practitioners act in the world, reflecting on their own practices and on the ability of their tools to support their work, engage in collaborative knowledge sharing, and appropriate and adapt their software tools to accommodate dynamically changing needs.
From page 295...
... Finally, we want to make clear that our vision of a more automated means of collecting information on user goals, needs, and activities is not intended as a substitute for including users as explicit stakeholders and equal partners in the design endeavor. Effective design will continue to require active dialogue and discovery among a variety of stakeholders, including users, human factors specialists, systems engineers, and software developers.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.