Lack of Naturalness in Human-Computer Interactions

Lack of Naturalness in Human-Computer Interactions

DOI: 10.4018/978-1-5225-2987-3.ch002
OnDemand PDF Download:
List Price: $37.50


There is a problematic difference between interactions of a human with natural and computer environments. The negatives of this difference are particularly painful in the design of software intensive systems, the success of which is unpredictable and extremely low. The root reason for such state of affairs is a very high complexity with which the designers have deals. What we name as “Complexity” is a characteristic of estimations that is discovered in interactions of a human or humans with perceived essences. Therefore, for example, designers need means that will help them in interactions with environments of their activity during real-time work. This chapter tries to show that one of the possible directions of mastering the complexity is bound with the possibility for designers to create conditions of interactions that are similar to conditions of natural interactions. In this case, both types of interactions will be intertwined in coordination in search of simplifying an arisen complexity.
Chapter Preview

1. Problems Of Human-Computer Activity

1.1. Features of Designing the Software Intensive Systems

The development and continuous improvement of Socio-Cyber-Physical reality (SCP-Reality) are useful to understand how artificial evolutionary process that intertwines with the natural processes on Earth, including the processes of life. In this interlacement, artificial and natural processes influence each other so that this leads to important events {ei}, the estimations of which are useful for future.

Particularly, similar events correspond to situations of completing the work of designers on projects of software intensive system (SISs). The reality of indicated kind of designing and characteristics of its results have shown that exists a problem with achieving the predictable success in this kind of activity.

Before describing this problem, it needs to present this class of systems. Below, in the text, we will orient on the following definition “A software intensive system is a system where software represents a significant segment in any of the following points: system functionality, system cost, system development risk, development time” (Software Intensive systems, 2006).

In general, this definition admits that software intensive system may include social, physical and software components interacting with each other. Thus, we can assume that now and in the future, the software intensive systems (SIS) are and will be the main components of SCPRealty.

This book focuses on increasing the naturalness of HCI, the current state of which is most fully disclose the problems of designing the SISs. That is why, below, the text of the book will explicitly or implicitly concern this kind of systems. Furthermore, software systems we will qualify as a subclass of SISs, and this will allow us the use of the name “system” as for SISs so for software system when it is not principal.

More particularly, our choice of designing the SISs as a source of used artificial and natural processes and problems in their intertwining was caused by the following:

  • 1.

    Development of SISs requires the use of the rich experience of software engineering and the experience of different subject areas.

  • 2.

    The accumulated experience of designing includes a part that supports the continuous improvement of processes, workforces, and products.

  • 3.

    There is a richest statistics of the success and failures of the completed projects based on software.

  • 4.

    Numerous and varied developments of different SISs have also led to the creation of mature technologies, the workflows of which help to creatively solve the tasks of different types.

  • 5.

    In the life cycle processes, designers create and use varied forms of HCI that support personal and collaborative work of designers in the real-time.

Returning to the problems of achieving the success in designing the systems, it is useful to analyze the reports that regularly published by Standish Group (Reports, 2016). Each of these reports evaluates the definite set of completed projects regarding their successfulness. In the report, evaluated projects are distributed on three classes with the following characteristics: “success,” “failure,” and “challenged.”

The first report that was called “Chaos Report” was published in the 1994 year. In the name of this report, its adjective “chaos” reflected an extremely low degree of the success in designing the software systems because only 16% of projects have been estimated as successful. Other reports register similarly unacceptable results that presented in Figure 1.

Figure 1.

Retrospective of success estimations

In all records up to 2012, their developers used following criteria for the distribution of classes: all promised requirements (onTarget) within the planned time (onTime) for the allocated budget (onBudjet).

It should be noted, this set of criteria (called the Iron Triangle) is understood and used as a classical base for estimation of the management processes in developments of systems. Thus, marked reports of the Standish Group reflected the success only with the side of the project management.

In its use, the word “success” is understood as a multifaceted concept, and such its feature should find the appropriate reflection in the developing the systems for measuring their success. Therefore, for an adequate evaluation of the success of the certain system, stakeholders should use the characteristics of the life cycle of this system.

That is why, there are many publications, authors of which suggest other versions of criteria’ sets. It was caused by other versions of understanding and specifying the success and failure. For example, we mark following versions of specifications:

  • 1.

    In paper (Wasmun 1993) that was published before the 1994 year, its authors interpreted the success as a multidimensional construct, integrating: System quality (measuring the developed system), information quality (measuring the system's output), user satisfaction, system use, individual impact (effect on behavior)and organizational impact user (effect of organizational performance).

  • 2.

    In 2008, the authors of paper (El Emam and Koru, 2008) suggested a set of criteria, including three dimensions: Project management success (on-time, on-budget, sponsor satisfaction, steering group satisfaction, project team satisfaction, customer/user satisfaction, stakeholder satisfaction), technical success (customer/user satisfaction, stakeholder satisfaction, system implementation, met requirements, system quality, system use), and business success (business continuity, met business objectives, delivery benefits).

Also, some works, such as (Jørgensen and Moløkken, 2006) and (Glass 2005), criticized and evaluated the criteria used by Standish Group as not reflecting the reality of the system with software.

Given the criticism and improving the used approach, the Standish Group ”has redefined project success as onTime, onBudget with a satisfactory result, that integrates subordinated criteria on-target (% requirements) and satisfied (very high to very low), value (very high to very low) and on strategic corporate goal (precise to distant)” (Chaos, 2014)

Widening the set of criteria leads to the change of the distribution picture on the classes indicated in Figure 1. Into this picture, the Standish Group included orthogonal measures that correspond to value-based view on characteristics of analyzed projects. Moreover, in (Haze, 2015) they presented comparing of statistics from the success driven and value driven views. For instance, Table 1 shows the part of this comparing where the first line emphases the different approach to estimations of the success.

Table 1.
Comparing the orthogonal views on the success

Even part of this table reflects the diversity of assessments of the success from standpoints of the development process and use of completed projects. This diversity can lead to “failed successes” and “successful failures” that points out on the necessity of careful weighting the used criteria of the project evaluation. Nevertheless, until now, in the design of systems, regardless of the selected criteria, there is a problem of success.

Complete Chapter List

Search this Book: