National Academies Press: OpenBook

Human-System Integration in the System Development Process: A New Look (2007)

Chapter: Part I Human-System Integration in the Context of System Development, 2 The System Development Process

« Previous: 1 Introduction
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

PART I
Human-System Integration in the Context of System Development

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

This page intentionally left blank.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

2
The System Development Process

The ultimate goal of system development is to deliver a system that satisfies the needs of its operational stakeholders—users, operators, administrators, maintainers, interoperators, and the public—within satisfactory levels of the resources of its development stakeholders—funders, acquirers, developers, suppliers, and others. From the perspective of human-system integration (HSI), satisfying operational stakeholders’ needs can be broadly construed to mean that a system is usable and dependable, permits few or no human errors, and leads to high productivity and adaptability. Developing and delivering systems that simultaneously satisfy all these stakeholders usually requires managing a complex set of risks, such as usage uncertainties, schedule uncertainties, supply issues, requirements changes, and uncertainties associated with technology maturity and technical design. Each of these areas poses a risk to the delivery of an acceptable operational system within the available budget and schedule. End-state operational system risks can be categorized as uncertainties in achieving a system mission, carrying out the work processes, operating within such constraints as cost or personnel, satisfying operational stakeholders, and achieving an acceptable operational return on investment.

This chapter summarizes the committee’s analysis of candidate models of system design, development, and evolution processes with respect to a set of study-derived principles critical to the success of human-intensive system development. It presents the results of synthesizing the contributions of these models along with key human factors processes into an incremental commitment model (ICM) that is used as a process framework for application of the study’s recommended processes, methods, and tools, as well as

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

for illustrating their successful application in three human-system design case studies (see Chapter 5).

PRINCIPLES FOR SUCCESSFUL SYSTEM DEVELOPMENT

The five principles critical to the success of human-intensive system development and evolution were evolved during the study and validated by analysis of the critical success factors of award-winning projects and application to the case studies in Chapter 5:

  1. Stakeholder satisficing. If a system development process presents an operational or development stakeholder with the prospect of an unsatisfactory outcome, the stakeholder will generally refuse to cooperate, resulting in an unsuccessful system. Stakeholder satisficing involves identifying the stakeholders critical to success and their value propositions; negotiating a mutually satisfactory set of system requirements, solutions, and plans; and managing proposed changes to preserve a mutually satisfactory outcome.

  2. Incremental growth of system definition and stakeholder commitment. This characteristic encompasses the necessity of incremental discovery of emergent human-system requirements and solutions via such discovery methods as prototyping, operational exercises, and the use of early system capabilities. Requirements and commitment cannot be monolithic or fully prespecifiable for complex, human-intensive systems; understanding, trust, definition, and commitment are achieved through a cyclic process.

  3. Iterative system definition and development. Incremental and evolutionary approaches lead to cyclic refinements of requirements, solutions, and development plans. Such iteration helps projects to learn early and efficiently about operational and performance requirements.

  4. Concurrent system definition and development. Initially, this includes concurrent engineering of requirements and solutions, as well as integrated product and process definition. In later increments, change-driven rework and rebaselining of next-increment requirements, solutions, and plans occur simultaneously with development of the current-system increment. This allows early fielding of core capabilities, continual adaptation to change, and timely growth of complex systems without waiting for every requirement and subsystem to be defined.

  5. Risk management—risk-driven activity levels and anchor point milestones. The level of detail of specific products and processes will depend on the level of risk associated with them. If the user interface is considered a high-risk area, for example, then more design activity will be devoted to this component to achieve stakeholder commitments at particular design anchor points. If, however, interactive graphic user interface (GUI) builder

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

capabilities make it low risk not to document evolving GUI requirements, much time-consuming effort can be saved by not creating and continually updating GUI requirements documents while evolving the GUI to meet user needs.

THE EVOLVING NATURE OF SYSTEM REQUIREMENTS

Traditionally, requirements have served as the basis for competitive selection of system suppliers and subsequent contracts between the acquirer and the selected supplier. As such, they are expected to be prespecificably complete, consistent, unambiguous, and testable. Frequently, progress payments and award fees are based on the degree to which these properties are satisfied.

However, particularly as systems depend more and more on being parts of a network-centric, collaboration-intensive system of systems, the traditional approach to system requirements has encountered increasing difficulties that these key ICM principles have been evolved to avoid. These difficulties include

  • Emergent requirements. The most appropriate user interfaces and collaboration modes for a human-intensive system are not specifiable in advance but emerge with system prototyping and usage. Forcing them to be prematurely and precisely specified generally leads to poor business or mission performance and expensive late rework and delays (Highsmith, 2000).

  • Rapid change. Specifying current-point-in-time snapshot requirements on a cost-competitive contract generally leads to a big design up front and a point-solution architecture that is hard to adapt to new developments. Each of the many subsequent changes then leads to considerable nonproductive work in redeveloping documents and software, as well as in renegotiating contracts (Beck, 1999).

  • Reusable components. Prematurely specifying requirements (e.g., hasty specification of a 1-second response time requirement when later prototyping shows that 4 seconds would be acceptable) that disqualify otherwise cost-effective reusable components often leads to overly expensive, late, and unsatisfactory systems (Boehm, 2000).

These key principles focus on (1) incremental and evolutionary acquisition of the most important and best-understood capabilities; (2) on concurrently engineering requirements and solutions; (3) on using prototypes, models, and simulations as ways of obtaining information to reduce the risk of specifying inappropriate requirements; and (4) on basing requirements on stakeholder negotiations once their implications are better understood.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

These principles work best when stakeholders adopt a different vocabulary for dealing with requirements. The primary dictionary definition of a requirement is “something required, i.e., claimed or asked for by right and authority.” It is much easier to make progress toward a mutually satisfactory negotiated solution if stakeholders use more negotiation-oriented terms such as “goals,” “objectives,” or “value propositions” rather than assuming that they are dealing with nonnegotiable “requirements.” And when tradeoffs among cost, schedule, performance, and capabilities are not well understood, it is better to specify prioritized capabilities and ranges of mutually satisfactory performance, rather than to insist on precise and unambiguous requirements. However, following Principle 5 above on the risk-driven level of product detail, it is important to converge on precise requirements when the risk of having them be imprecise is high. Some good examples are human-computer interaction protocols for safety-critical systems and interfaces among separately developed mission-critical subsystems.

PRINCIPLES-BASED COMPARISON OF ALTERNATIVE PROCESS MODELS

Our study included an analysis of candidate systems development process models with respect to the five critical principles for success. The candidate models include the waterfall, V, spiral, and concurrent engineering process models discussed in the first two chapters of the Handbook of Systems Engineering and Management (Sage and Rouse, 1999a, 1999b; Patterson, 1999), plus emerging candidates, such as agile methods (Beck, 1999; Highsmith, 2000), V-model updates (Federal Republic of Germany, 2004), and 2001 extensions of the spiral model (Boehm and Hansen, 2001).

Our analysis, summarized in Table 2-1, indicates that all of the models make useful contributions but exhibit shortfalls with respect to human factors considerations, particularly in explicit guidance for stakeholder satisficing. Pure-sequential implementations of the waterfall and V-models are not good matches for human-intensive systems. Although they are becoming less frequent, they are still often encountered due to the imposition of existing contracting clauses and standards. More recently, the V-Model XT has adopted more risk-driven and incremental approaches that encourage concurrent engineering (Federal Republic of Germany, 2004), but it takes some skill to build in stakeholder satisficing and to avoid overly heavyweight implementations and difficulties in coping with rapid change. Risk-driven evolutionary development is better at coping with rapid change, but it can have difficulties in optimizing around early increments with architectures that encounter later scalability problems. Concurrent engineering explicitly addresses incremental growth, concurrency, and iteration. Although com-

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

TABLE 2-1 Principles-Based Comparison of Alternative Process Models

Process Models

Principles

Stakeholder Satisficing

Incremental Growth

Concurrency

Iteration

Risk Management

Sequential waterfall, V

Assumed via initial requirements; no specifics

Sequential

No

No

Once at the beginning

Iterative, risk-driven waterfall, V

Assumed via initial requirements; no specifics

Risk-driven; missing specifics

Risky parts

Yes

Yes

Risk-driven evolutionary development

Revisited for each iteration

Risk-driven; missing specifics

Risky parts

Yes

Yes

Concurrent engineering

Implicit; no specifics

Yes; missing specifics

Yes

Yes

Implicit; no specifics

Agile

Fix shortfalls in next phase

Iterations

Yes

Yes

Some

Spiral process 2001

Driven by stakeholder commitment milestones

Risk-driven; missing specifics

Yes

Risk-driven

Yes

Incremental commitment

Stakeholder-driven; stronger human factors support

Risk-driven; more specifics

Yes

Yes

Yes

patible with stakeholder satisficing and risk management, it lacks much explicit guidance in addressing them.

Agile methods are even better at coping with rapid change, but they can have even more difficulties with scalability and with mission-critical or safety-critical systems, in which fixing shortfalls in the next increment is not acceptable. There is a wide variety of agile methods; some, such as lean and feature-driven development, are better at scalability and criticality than others. The version of spiral development in Boehm and Hansen (2001), with stakeholder satisficing and anchor point milestones, covers all of the principles, but it is unspecific about how risk considerations guide iteration and incremental growth. Our analysis of these models indicates primary shortfalls in support of human factors integration and unproven ability to scale up to the future process challenges involving emergent,

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

network-centric, massively collaborative systems of systems (Maier, 1998; Sage and Cuppan, 2001).

The committee undertook to integrate human factors considerations into the spiral 2005 process model (Boehm and Lane, 2006), a generalization of the win-win spiral model being used in the future combat systems system of systems (Boehm et al., 2004). The result is the incremental commitment model, discussed in the next section. Although, it is not the only model that could be used on future human-intensive systems of systems, it has served as a reasonably robust framework for explaining the study’s HSI concepts, and for evaluating these via the case studies presented in Chapter 5.

THE INCREMENTAL COMMITMENT MODEL

An overview of the ICM life-cycle process is shown in Figure 2-1. It identifies the concurrently engineered life-cycle phases; the stakeholder commitment review points and their use of feasibility rationales to assess the compatibility, feasibility, and risk associated with the concurrently engineering artifacts; and the major focus of each life-cycle phase. There are a number of alternatives at each commitment point: (1) the risks are

FIGURE 2-1 Overview of the incremental commitment life-cycle process.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

negligible and no further analysis and evaluation activities are needed to complete the next phase; (2) the risk is acceptable and work can proceed to the next phase; (3) the risk is addressable but requires backtracking; and (4) the risk is too great and the development process should be rescoped or halted. These risks are assessed by the system’s stakeholders, whose commitment will be based on whether the current level of system definition gives sufficient evidence that the system will satisfy their value propositions (see Box 2-1).

The incremental commitment model builds on the early verification and validation concepts of the V-model, the concurrency concepts of the concurrent engineering model, the lighter-weight concepts in the agile and lean models, the risk-driven concepts of the spiral model, the phases and anchor points in the rational unified process (RUP) (Royce, 1998; Kruchten, 1999; Boehm, 1996), and recent extensions of the spiral model to address systems of systems acquisition (Boehm and Lane, 2006). In comparison to the software-intensive RUP, the incremental commitment model also addresses hardware and human factors integration. It extends the RUP phases to cover the full system life cycle: an exploration phase precedes the RUP inception phase, which is refocused on valuation and investment analysis. The RUP elaboration phase is refocused on architecting; the RUP construction and transition phases are combined into development; and an additional operations phase combines operations, production, maintenance, and phase-out. An integration of the RUP and the incremental commitment model is being prepared for use in the open-source eclipse process frameworks.

In comparison to the sequential waterfall (Royce, 1970) and V-models (Federal Republic of Germany, 2004), the incremental commitment model explicitly emphasizes concurrent engineering of requirements and solutions, establishes explicit feasibility rationales as pass/fail milestone criteria; explicitly enables risk-driven avoidance of unnecessary documents, phases, and reviews; and provides explicit support for a stabilized current-increment development concurrently with a separate change processing and rebaselining activity to prepare for appropriate and stabilized development of the next increment. These aspects can be integrated into a waterfall or V-model, enabling projects required to use such models to cope more effectively with systems of the future.

The ICM commitment milestones correspond fairly closely with the Department of Defense (DoD) acquisition milestones as defined in DoD Instruction 5000.2 (U.S. Department of Defense, 2003a). For example, the ICM milestone commitment to proceed into development based on the validated life-cycle architecture package (an operations concept description, requirements description, architecture description, life-cycle plan, working prototypes or high-risk elements, and a feasibility rationale providing

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

BOX 2-1

Value-Based Systems and Software Engineering

In order for a system’s stakeholders to commit their personal material and financial resources to the next level of system elaboration, they must be convinced that the current level of system elaboration provides evidence that their value propositions will be satisfied by the system. This success condition is consistent with the theory W (win-win) approach to value-based systems and software engineering, which states that a project will be successful if and only if it makes winners of its success-critical stakeholders. If the project does not create a satisfactory value proposition for some success-critical stakeholders (a win-lose situation), they will refuse to participate or will counterattack, generally creating a lose-lose situation for all stakeholders.

The associated key value-based principles for creating a success-critical stakeholder win-win outcome are (1) to identify the success-critical stakeholders and their value propositions; (2) to identify, confront, and resolve conflicts among these value propositions; (3) to enable the stakeholders to negotiate a mutually satisfactory or win-win solution region or opportunity space; and (4) to monitor the evolution of the opportunity space and apply corrective or adaptive actions to keep the opportunity space viable or increase its value (Boehm and Jain, 2005).

The associated key value-based practices address these principles and also involve using alternative terminology to traditional project or system acquisition terminology: early-stage “goals, objectives, value propositions, or win conditions” rather than “requirements”; “solution space” rather than “solution”; “desired and acceptable levels of service” rather than “the required level of service”; “satisficing” rather than “optimizing”; and “success-critical stakeholder or partner” rather than “vendor, supplier, or worker.”

Key value-based practices for identifying the success-critical stakeholders and their value propositions include ethnographic techniques, plus a technique called results chains (Thorp, 1998) for identifying success-critical stakeholders. Other useful techniques include scenarios, prototypes, brainstorming, quality function deployment, business case analysis, and participatory design, plus asking “why?” for each “what” or “how” identified by a stakeholder.

Key value-based practices for identifying, confronting, and resolving conflicts among stakeholder value propositions include inventing options for mutual gain (Fisher and Ury, 1981), expectations management, business case analysis, and group-based techniques for prioritizing desired capabilities and for identifying desired and acceptable levels of service.

Key value-based practices for enabling stakeholders to negotiate a mutually satisfactory or win-win solution region or opportunity space include the conflict resolution techniques just described, plus negotiation techniques (Raiffa, 1982); risk-based techniques for determining how much of an activity, artifact, or level of service is enough, such as real options theory (Black and Scholes, 1973; Amram and Kulatilaka, 1999); and groupware support systems for negotiating stakeholder win-win requirements.

Key value-based practices for monitoring and keeping the opportunity space viable or increasing its value include market-watch and technology-watch techniques, incremental and evolutionary development, architecting to accommodate future change, adaptive control techniques, and business-value-oriented earned value management systems.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

evidence of their compatibility and feasibility) corresponds fairly closely with DoD’s Milestone B commitment to proceed into the development and demonstration phase.

VIEWS OF THE INCREMENTAL COMMITMENT MODEL

The following section provides multiple views of the incremental commitment model, including a process model generator view, a concurrent level of activity view, an anchor point milestone view, a spiral process view, and an incremental development view for incorporating rapid change and high assurance using agile and plan-driven teams. It concludes with a comparison of the incremental commitment model with other often-used process models.

Process Model Generator View

As shown by the four example paths through the incremental commitment model in Figure 2-2, the incremental commitment model is not a single monolithic one-size-fits-all process model. As with the spiral model, it is a risk-driven process model generator, but the incremental commitment model makes it easier to visualize how different risks create different processes.

In Example A in the figure, a simple business application based on an appropriately selected enterprise resource planning (ERP) package, there is no need for a valuation or architecting activity if there is no risk that the ERP package and its architecture will not cost-effectively support the application. Thus, one could go directly into the development phase, using an agile method, such as a scrum/extreme programming combination. There is no need for big design up front (BDUF) activities or artifacts because an appropriate architecture is already present in the ERP package. Nor is there a need for heavyweight waterfall or V-model specifications and document reviews. The fact that the risk at the end of the exploration phase is negligible implies that sufficient risk resolution of the ERP package’s human interface has been done.

Example B involves the upgrade of several incompatible legacy applications into a service-oriented web-based system. Here, one could use a sequential waterfall or V-model if the upgrade requirements are stable, and its risks are low. However, if for example the legacy applications’ user interfaces were incompatible with each other and with web-based operations, a concurrent risk-driven spiral, waterfall, or V-model that develops and exercises extensive user interface prototypes and generates a feasibility rationale (described below) would be preferable.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

FIGURE 2-2 Different risks create different ICM processes.

In Example C, the stakeholders may have found during the valuation phase that their original assumptions were optimistic about the stakeholders having a clear, shared vision and compatible goals with respect the proposed new system’s concept of operation and its operational roles and responsibilities. In such a case, it is better to go back and ensure stakeholder value proposition compatibility and feasibility before proceeding, as indicated by the arrow back into the valuation phase.

In Example D, it is discovered before entering the development phase that a superior product has already entered the marketplace, leaving the current product with a nonviable business case. Here, unless a viable business case can be made by adjusting the project’s scope, it is best to discontinue it. It is worth pointing out that it is not necessary to proceed to the next major milestone before terminating a clearly nonviable project, although stakeholder concurrence in termination is essential.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Concurrent Levels of Activity View

The concurrent levels of activity view shown in Figure 2-3 is an extension of a similar view of concurrently engineered software projects developed as part of the rational unified process (Kruchten, 1999). As with the RUP version, it should be emphasized that the magnitude and shape of the levels of effort will be risk-driven and likely to vary from project to project. In particular, they are likely to have mini-risk/opportunity-driven peaks and valleys, rather than the smooth curves shown for simplicity in the figure. The main intent of this view is to emphasize the necessary concurrency of the primary success-critical activity classes, shown as rows in Figure 2-3. Thus, in interpreting the exploration column, although system scoping is the primary objective of this phase, doing it well involves a consider-

FIGURE 2-3 ICM activity categories and level of effort.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

TABLE 2-2 Primary Focus of HSI Activity Classes and Methods

Activity Class

Examples of HSI Methods Described in This Volume

Systems Engineering

  1. Envisioning opportunities

  • Field observations and ethnography

  • Participatory analysis

  • Modeling

  • Change monitoring (technology, competition, marketplace, environment)

  1. System scoping

  • Organizational and environmental context analysis

  • Field observations and ethnography

  • Participatory analysis

  • Investment analysis

  • System boundary definition

  • Resource allocation

  • External environment characterization

  • Success-critical stakeholder identification

  1. Understanding needs

  • Organizational and environmental context analysis

  • Field observations and ethnography

  • Task analysis

  • Cognitive task analysis

  • Participatory analysis

  • Contextual inquiry

  • Event data analysis

  • Prototyping

  • Models and simulations

  • Usability evaluation methods

  • Success-critical stakeholder requirements

  • Competitive analysis

  • Market research

  • Future needs analysis

  1. Goals/objectives and requirements

  • Usability requirements methods

  • Scenarios

  • Personas

 

  1. Architecting solutions

  • Task analysis

  • Usability requirements methods

  • Work domain analysis

  • Workload assessment

  • Participatory design

  • Contextual design

  • Physical ergonomics

  • Situation awareness

  • Methods for mitigating fatigue

  • Prototyping

  • Models and simulations

  • Usability evaluation methods

  • Architecture frameworks

  • Commercial off the shelf/reuse evaluation

  • Legacy transformation analysis

  • Human-hardware-software allocation

  • Quality attribute analysis

  • Synthesis

  • Facility/vehicle architecting

  • Equipment design

  • Component evaluation and selection

  • Supplies/logistics planning

  • Construction/maintenance planning

  • Architectural style determinants

  • Component evaluation and selection

  • Physical/logical design

  • Evolvability design

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

Activity Class

Examples of HSI Methods Described in This Volume

Systems Engineering

  1. Life-cycle planning

  • Usability requirements methods (common industry format)

  • Risk analysis

  • Phased objectives (increments, legacy transformations)

  • Milestones and schedule

  • Roles and responsibility

  • Approach

  • Resources

  • Assumptions

  1. Evaluation

  • Usability requirements methods (common industry format)

  • Prototyping

  • Models and simulation

  • Risk analysis

  • Usability evaluation methods

  • Evidence of fitness to proceed

  • Feasibility (usability, functionality, safety)

  • Other quality attributes

  • Cost/schedule risk

  • Business case mission analysis

  • Stakeholder commitment

  • Simulations, models, benchmarks, analysis

  1. Negotiating commitments

  • Usability requirements methods (common industry format)

  • Risk analysis

  • Dependency/compatibility trade-off analysis

  • Expectation management, prioritization

  • Option preservation

  • Incrementing sequencing

  1. Development and evolution

  • Usability requirements methods (common industry format)

  • Models and simulation

  • Risk analysis

  • Usability evaluation methods

Material/operational solution analysis; make or buy analysis; acquisition planning; source selection; contracting/incentivization; human/hardware/software element development and integration; legacy transformation preparation; incremental installation

  1. Monitoring and control

  • Organizational and environmental context analysis

  • Risk analysis

Progress monitoring vs. plans; corrective action; adaptation of plans to change monitoring

  1. Operations and retirement

  • Organizational and environmental context analysis

Planned operations and retirement; OODA (observe, orient, decide, act) operations and retirement; adaptation of operations to change monitoring

  1. Organizational capability improvement

  • Organizational and environmental context analysis

Organizational goals and strategy definition; resource allocation; capability improvement activities

NOTE: HSI methods often span multiple activity classes.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

able amount of activity in understanding needs, envisioning opportunities, identifying and reconciling stakeholder goals and objectives, architecting solutions, life-cycle planning, evaluation of alternatives, and negotiation of stakeholder commitments. Many HSI best-practice tables confine each recommended practice to a single phase-activity cell. Experts treat these confinements as suggestions that need not be followed, but nonexpert decision makers often follow such confinements literally, seriously reducing their effectiveness.

Table 2-2 shows the primary methods and work products involved in each activity class. The second column of the table shows the primary HSI methods that are discussed in Part II. The third column shows the primary corresponding systems engineering methods. Appendix Table 3-1 in Chapter 3 is a more detailed presentation of activities, methods, and best practices contained in ISO/PAS 18152 (International Organization for Standardization, 2003).

The Development Commitment Anchor Point Milestone Review

Figure 2-3 suggests that a great deal of concurrent activity is planned to occur within and across the various ICM phases. This gives rise to two main questions. First, more specifically than in Figures 2-2 and 2-3, what are the main concurrent activities that are going on in each phase? Second, how are the many concurrent activities synchronized, stabilized, and assessed for risk at the end of each phase? Figure 2-4, an elaboration of Figure 2-2, provides the next-level answer for the first question.

The elaboration of the concurrent engineering and feasibility evaluation activities makes it clearer just what is being concurrently engineered and evaluated in each phase. For example, at the development commitment review (DCR), the stakeholders and specialty experts review the life-cycle architecture (LCA) package for the overall system and for each increment to assure themselves that it is worthwhile to commit their human, financial, and other resources to the next phase of system development.

During the architecting phase, the project prepares for the DCR by concurrently engineering the system’s operational aspects into a detailed operational concept and set of system requirements; the various commercial off the shelf, custom, and outsourced capabilities into a compatible build-to architecture; and the business case and resource constraints into a set of compatible plans, budgets, and schedules for each phase and for the overall system.

The next-level answer for the second question on synchronization, stabilization, and risk assessment is provided by the contents of the ICM architecture commitment review (ACR) and DCR anchor point milestone feasibility rationales referred to in Figure 2-4 and shown in Box 2-2. The

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

FIGURE 2-4 Elaboration of the ICM life-cycle process.

contents indicate that the project is responsible not only for producing a set of artifacts, but also for producing the evidence of their compatibility and feasibility. This evidence—from models, simulations, prototypes, benchmarks, analyses, etc.—is provided to experts and stakeholders in advance of the milestone review. Shortfalls in this evidence for compatibility and feasibility of the concurrently engineered artifacts should be identified by the system developer as potential project risks and addressed by risk-management plans. Any further shortfalls in the evidence or the risk management plans found by the reviewers should be communicated to

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

BOX 2-2

ICM Architecture Commitment Review and Development Commitment Review for the Anchor Point Milestone Feasibility Rationale Content

  • Evidence provided by the developer and validated by independent experts that if the system is built to the specified architecture, it will

    • Satisfy the requirements: capability, interfaces, level of service, and evolution

    • Support the operational concept

    • Be buildable within the budgets and schedules in the plan

    • Generate a viable return on investment

    • Generate satisfactory outcomes for all of the success-critical stakeholders

  • All major risks resolved or covered by risk-management plans

  • Serves as basis for stakeholders’ commitment to proceed

the developers in time for them to prepare responses to be presented at the DCR review meeting.

At the DCR milestone review meeting for the LCA package, the project then either provides adequate additional evidence of feasibility or additional risk-management plans to address the risks. The stakeholders then decide whether the risks are negligible, acceptable, high but addressable, or too high and unaddressable, and the project proceeds in the direction of the appropriate DCR risk arrow in Figure 2-4.

The Other ICM Milestone Reviews

The architecture commitment review criteria and procedures are similar but less elaborate than those in the DCR, as the degree of stakeholder resource commitment to support the architecting phase is considerably lower than for supporting the development phase. The ACR and DCR review procedures are adapted from the highly successful AT&T Architecture Review Board procedures described in Marenzano et al. (2005). For the ACR, only high-risk aspects of the operational concept, requirements, architecture, and plans are elaborated in detail. And it is sufficient to provide evidence that at least one combination of those artifacts satisfies the feasibility rationale criteria, in comparison to demonstrating this at the DCR for a particular choice of artifacts to be used for development.

The review criteria and procedures for the exploration commitment review (ECR) and the valuation commitment review (VCR) are even less elaborate than those for the ACR milestone, as the commitment levels for proceeding are considerably lower. But they will similarly have a risk-driven

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

level of detail and risk-driven stakeholder choice of review outcome. For the ECR, the focus is on a review of an exploration phase plan with the proposed scope, schedule, deliverables, and required resource commitment by a key subset of stakeholders. The plan content is risk-driven and could be put on a single page for a small and noncontroversial exploration phase. For the VCR, the risk-driven focus is similar; the content includes the exploration phase results and a valuation phase plan and a review by all of the stakeholders involved in the valuation phase.

The operations commitment review (OCR) is different, in that it addresses the often much higher operational risks of fielding an inadequate system. In general, stakeholders will experience an increase in commitment level by a factor of 2 to 10 in going through the sequence of ECR to DCR milestones, but the increase in going from DCR to OCR can be much higher. The OCR focuses on evidence of the adequacy of plans and preparations with respect to doctrine, organization, training, material, leadership, personnel, and facilities, along with plans, budgets, and schedules for production, fielding, and operations.

A nonscientific analogy may be useful. The series of ICM milestones has the advantage of reflecting other human life-cycle incremental commitment sequences, such as those of getting married and raising a family. The ECR might be considered similar to a nonexclusive commitment to go out on dates with a girlfriend or boyfriend. The VCR is similar to a more exclusive but informal commitment to “go steady,” and the ACR is similar to a more formal commitment to get engaged. The DCR is similar to an “until death do us part” commitment to get married: if one marries one’s life-cycle architecture package in haste, one may repent in leisure. The OCR is similar to having one’s first child: once the baby arrives, one’s lifestyle is changed by the need to maintain its health and well-being.

Another possibly relevant metaphor for the incremental commitment model is a poker game, such as Texas Hold’em. At each round of betting, each stakeholder looks at his or her own hole cards and the jointly visible community cards and decides whether it is worth adding further resources to the pot of resources on the table, in order to see further community cards and to win the pot based on having the best poker hand constructible from one’s own hole cards and the community cards. With the incremental commitment model, however, there will be negotiations designed to make win conditions for each success-critical stakeholder.

The Spiral View

A simplified spiral model view of the incremental commitment model appears in Figure 2-5. It avoids sources of misinterpretation in previous versions of the spiral model and concentrates on the five key spiral develop-

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

FIGURE 2-5 Simplified spiral view of the incremental commitment model.

ment principles. Stakeholder satisficing is necessary to pass the stakeholder commitment review points or anchor point milestones. Incremental growth in system understanding, cost, time, product, and process detail is shown by the spiral growth along the radial dimension. Concurrent engineering is shown by progress along the angular dimension. Iteration is shown by taking several spiral cycles both to define and develop the system. Risk management is captured by indicating that the activities’ and products’ levels of detail in the angular dimension are risk-driven, and by the risk-driven arrows pointing out from each of the anchor point commitment milestones.

These arrows show that the spiral model is not a sequential, unrollable process, but that it incorporates many paths through the diagram, including skipping a phase or backtracking to an early phase based on assessed risk. The fourth arrow pointing toward rescoping or halting in Figure 2-4

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

is omitted from Figure 2-5 for simplicity; it would be pointing down underneath the plane of the figure. Other aspects of the spiral model, such as the specific artifacts being concurrently engineered and the use of the feasibility rationale, are consistent with their use in Figure 2-4 and the other figures, in which they are easier to understand and harder to misinterpret than in a spiral diagram. Also for simplicity, the concurrent operation of increment N, development of increment N + 1, and architecting of increment N + 2 are not shown explicitly, although they are going on. This concurrency is explained in more detail in the next section.

Incremental Development for Accommodating Rapid Change and High Assurance

Many future systems and systems of systems will need to simultaneously achieve high assurance and adaptation to both foreseeable and unforeseeable rapid change, while meeting shorter market windows or new defense threats. Figure 2-6 shows an incremental view of the incremental commitment model for addressing such situations. It assumes that the organization has developed artifacts that have passed a development commitment review, including

  • a best-effort definition of the system’s envisioned overall capability;

FIGURE 2-6 Risk-driven ICM for accommodating rapid change and high assurance. Adapted from Boehm and Lane (2006).

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
  • an incremental sequence of prioritized capabilities culminating in the overall system capability; and

  • a feasibility rationale providing sufficient evidence for each increment and the overall system that the system architecture will support the increment’s specified capabilities; that each increment can be developed within its available budget and schedule; and that the series of increments create a satisfactory return on investment for the organization and mutually satisfactory outcomes for the success-critical stakeholders.

The solid lines in the figure represent artifact flows. For example, the baselined operational concept, requirements, architecture, and development plans for increment N enter the center box and guide the plan-driven development of increment N to be transitioned into operations and maintenance. This development is stabilized by accepting only changes that have been architecturally anticipated (or occasional exceptional showstoppers). The corresponding baselines for future increments enter the top box, in which an agile team addresses unforeseeable changes and unavoidable content deferrals from increment N into future increments. The agile team’s output is a rebaselined set of specifications and plans to be used in developing increment N + 1 and counterpart rebaselined specifications and plans for future increments to be updated during increment N + 1.

The dotted lines in Figure 2-6 represent cause-effect relationships. For example, the need to deliver high-assurance incremental capabilities on relatively short fixed schedules (to avoid delivery of obsolete capabilities in an era of increasingly rapid change) means that each increment needs to be kept as stable as possible. This is particularly the case for very large systems of systems with deep supplier hierarchies (often 6 to 12 levels), in which a high level of in-process change adaptation traffic can easily lead to the developers spending more time processing changes than doing development. In keeping with the use of the incremental commitment model as a risk-driven process model generator, the risks of destabilizing the development process make this portion of the project into a build-to-specification subset of the concurrent activities, in which the only changes accommodated are potential showstoppers or foreseeable changes that have been accommodated in the increment’s architecture. The need for high assurance of each increment also makes it cost-effective to invest in a team of appropriately skilled personnel to continuously verify and validate the increment as it is being developed, as shown in the lower box in Figure 2-6.

In order to avoid delays and shortfalls in getting increment N + 1 specifications and plans ready for development, the agile team is concurrently assessing the unforeseen change traffic and rebaselining the next increment’s LCA package and feasibility rationale, so that the stabilized build-to-specifications team will have all it needs to hit the ground running

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

TABLE 2-3 Number of Top-5 Projects Explicitly Using ICM Principles

Year

Concurrent Engineering

Risk-Driven

Evolutionary Growth

2002

4

3

3

2003

4

3

2

2004

2

2

4

2005

4

4

5

Total (of 20)

14

12

14

in rapidly developing the next increment. More detail on this process and its staffing and contracting implications is provided by Boehm (2006).

PROJECT EXPERIENCE WITH ICM PRINCIPLES

The incremental commitment model uses the critical success factor principles to extend several current spiral-related processes, such as the rational unified process, the win-win spiral process, and the lean development process, in ways that more explicitly integrate human-system integration into the system life-cycle process. A good source of successful projects that have applied the critical success factor principles is the annual series of top-5 software-intensive systems projects published in CrossTalk1 (2002-2005).

The top-5 quality software projects are chosen annually by panels of leading experts as role models of best practices and successful outcomes. Table 2-3 summarizes each year’s record with respect to usage of four of the five principles: concurrent engineering, risk-driven activities, and evolutionary and iterative system growth (most of the projects were not specific about stakeholder satisficing). Of the 20 top-5 projects in 2002 through 2005, 14 explicitly used concurrent engineering, 12 explicitly used risk-driven development, and 14 explicitly used evolutionary and iterative system growth, while additional projects gave indications of their partial use. Table 2-4 provides more specifics on the 20 projects.

Evidence of successful results of stakeholder satisficing can be found in the annual series of University of Southern California e-services projects using the win-win spiral model as described in (Boehm et al., 1998). Since 1998 over 50 user-intensive e-services applications have used the win-win

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

TABLE 2-4 Critical Success Factor (CSF) Aspects of Top Five Software Projects

Software Project

CSF Degree

Concurrent Requirements/Solution Development

Risk-Driven Activities

Evolutionary, Incremental Delivery

STARS Air Traffic Control

*

Yes

HCI, safety

For multiple sites

Minuteman III Messaging (HAC/RMPE)

*

Yes

Safety

Yes; block upgrades

FA-18 Upgrades

*

Not described

Yes

Yes; block upgrades

Census Digital Imaging (DCS2000)

**

Yes

Yes

No; fixed delivery date

FBCB2 Army Tactical C3I

**

Yes

Yes

Yes

Defense Civilian Pay (DCPS)

 

No; waterfall

Yes

For multiple organizations

Tactical Data Radio (EPLRS)

**

Yes

Yes

Yes

Joint Helmet-Mounted Cueing (JHMCS)

*

Yes; IPT-based

Not described

For multiple aircraft

Kwajalein Radar (KMAR)

*

Yes; IPT-based

Not described

For multiple radars

One SAF Simulation Test Bed (OTB)

**

Yes

Yes

Yes

Advanced Field Artillery (AFATDS)

 

Initially waterfall

Not described

Yes; block upgrades

Defense Medical Logistics (DMLSS)

 

Initially waterfall

Not described

Yes; block upgrades

F-18 HOL (H1E SCS)

 

Legacy requirements-driven

Yes; COTS, display

No

One SAF Objectives System (OOS)

**

Yes

Yes

Yes

Patriot Excalibur (PEX)

**

Yes; agile

Not described

Yes

Lightweight Handheld Fire Control

**

Yes

Yes

Yes

Marines Integrated Pay (MCTFS)

 

Initially waterfall

Not described

Yes; block upgrades

Near Imaging Field Towers (NIFTI)

**

Yes; RUP-based

Yes

Yes

Smart Cam Virtual Cockpit (SC3DF)

**

Yes

Yes

Yes

WARSIM Army Training

**

Yes

Yes

Yes

NOTE: COTS = commercial off the shelf; HCI = human-computer interaction; IPT = integrated project team; RUP = rational unified process. For CSF Degree: blank = “generally not used,” * = “generally used,” and ** = “strongly used.”

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

spiral model to achieve a 92-percent success rate of on-time delivery of stakeholder-satisfactory systems.

CONCLUSION

Future transformational, network-centric systems will have many usage uncertainties and emergent characteristics. Their hardware, software, and human factors will need to be concurrently engineered, risk-managed, and evolutionarily developed to converge on cost-effective system operations. They will need to be both highly dependable and rapidly adaptable to frequent changes.

This chapter has described the incremental commitment model, which builds on experience-based critical success factor principles (stakeholder satisficing, incremental definition, iterative evolutionary growth, concurrent engineering, risk management) as well as the strengths of existing V, concurrent engineering, spiral, agile, and lean process models, to provide a framework for concurrently engineering human factors into the systems engineering and systems development processes. The chapter provides capabilities for evaluating the feasibility of proposed HSI solutions and for integrating HSI feasibility evaluations into decisions on whether and how to proceed further into systems development and operations. The chapter also presents several complementary views showing how the principles are applied to perform risk-driven process tailoring and evolutionary growth of a systems definition and realization; to synchronize and stabilize concurrent engineering; and to enable simultaneous high-assurance development and rapid adaptation to change. The chapter analyzes the use of the critical success factor principles on the best-documented government software-intensive system acquisition success stories, the 2002-2005 CrossTalk top-5 projects, and shows that well over half of them explicitly applied these principles. The next three chapters will elaborate on how HSI practices fit into the ICM process and provide case studies of successful projects that have used the principles and practices.

The current path of least resistance for a government program manager is to follow a set of (existing) regulations, specifications, and standards that select, contract with, and reward developers for doing almost the exact opposite. Most of these legacy instruments emphasize sequential versus concurrent engineering; risk-insensitive versus risk-driven processes; early definition of poorly understood requirements versus better understanding of needs and opportunities; and slow, unscalable, contractual mechanisms for adapting to rapid change.

This chapter has provided a mapping of the ICM milestones to the current DoD 5000.2 acquisition milestones, showing that they can be quite compatible. It also shows how projects could be organized into stabilized

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×

build-to-specification increments that fit current legacy acquisition instruments, along with concurrent agile change-adaptation and verification and validation functions that need to use alternative contracting methods. Addressing changes of this nature will be important if organizations are to realize the large potential value offered by investments in HSI processes, methods, and tools.

Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 29
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 30
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 31
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 32
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 33
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 34
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 35
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 36
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 37
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 38
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 39
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 40
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 41
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 42
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 43
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 44
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 45
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 46
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 47
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 48
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 49
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 50
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 51
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 52
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 53
Suggested Citation:"Part I Human-System Integration in the Context of System Development, 2 The System Development Process." National Research Council. 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC: The National Academies Press. doi: 10.17226/11893.
×
Page 54
Next: 3 Human-System Integration and the System Development Process »
Human-System Integration in the System Development Process: A New Look Get This Book
×
Buy Hardback | $80.00 Buy Ebook | $64.99
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

In April 1991 BusinessWeek ran a cover story entitled, “I Can't Work This ?#!!@ Thing,” about the difficulties many people have with consumer products, such as cell phones and VCRs. More than 15 years later, the situation is much the same--but at a very different level of scale. The disconnect between people and technology has had society-wide consequences in the large-scale system accidents from major human error, such as those at Three Mile Island and in Chernobyl.

To prevent both the individually annoying and nationally significant consequences, human capabilities and needs must be considered early and throughout system design and development. One challenge for such consideration has been providing the background and data needed for the seamless integration of humans into the design process from various perspectives: human factors engineering, manpower, personnel, training, safety and health, and, in the military, habitability and survivability. This collection of development activities has come to be called human-system integration (HSI). Human-System Integration in the System Development Process reviews in detail more than 20 categories of HSI methods to provide invaluable guidance and information for system designers and developers.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    Switch between the Original Pages, where you can read the report as it appeared in print, and Text Pages for the web version, where you can highlight and search the text.

    « Back Next »
  6. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  7. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  8. ×

    View our suggested citation for this chapter.

    « Back Next »
  9. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!