find and solve ||
Please wait.....

Integrating human factors in the model

The role of human factors in models of the development process deserves greater attention because technological considerations alone do not provide a comprehensive, deep model for software processes. Human factors enter the picture in many ways. Thus, some software process models address the impact of personal competence and behavior on software development, such as discussed in Section 3.5.

Other models, such as the Capability Maturity Model (in Section 3.4), closely and formally address the team and organizational context in which a development process is embedded. However, no comprehensive models systemically address the development process from the viewpoint of the human actors engaged in and implementing the process and its artifacts. This book tries to fill this gap, at least partially, by broadly considering the impact on the development process of cognitive oc.-problem-solving factors, stakeholders' roles and concerns, and organizational marketplace forces.

This section brief overview of some of the human-centered issues that affect the software process For example cognitive phenomena affects how individuals (team members or stakeholders) think about a problem and its solution.

A cognitive perspective on development would address how the people involved perceive, understand, and solve problems. At the group level, social and psychological factors affect group behavior, such as how developers interact with one another as individuals or as a team, but group cognition affects the collective analysis of problems and group communication.

Human factors also have a role in the development process. The structure and artifacts of a software process affect how the process is enacted by developers and may, for example, affect their motivation. Most familiar is the role of human factors as understood in Human-Computer Interface (HCI) design, in which the concern is the human effects of the interface of a software product.

The HCI perspective considers the myriad cognitive and physiological factors that affect the successful design of an interactive interface. Regardless of whether one approaches the issue from a systems dynamics and managerial perspective (Abdel-Hamid & Madnick 1989) or cognitive or psychological and sociological perspective (Leveson 2000), the human element is important to appreciate.

Vennix (1999) describes some of the cognitive effects that affect the development process, including the role of selective perception; cognitive tendencies that incline one to oversimplify problems; the cognitive pre­ disposition not to learn from failures by inaccurately attributing them to external forces rather than to acts of one's own; and the existence of unsurfaced or unspoken multiple interpretations in group cognition.

The cognitive accessibility of system specifications has an ongoing impact on development. To simplify solving the kinds of problems that arise during development, specifications should reflect a correct understanding of human cognitive requirements.

Leveson (2000) adopts a cognitive engineering approach that defines cognitive-friendly specifications-called intent specifications. which are based on "psychological principles of how people use specifications to solve problems" Although they combine mathematical and nonmathematical characteristics, they are intended to be easily readable, understandable, and useable by developers.

In motivating the introduction of intent specifications, Leveson makes an interesting analogy between the role of control panels in an industrial plant and software specifications. Control panels serve as the interface between a computer operator and the plant's system. Similarly, "software requirements and design specifications are the interfaces between the system designers and builders or builders and maintainers."

These software specifications are intended to help the developers at different stages of development (building, testing, debugging, maintaining, etc.) "understand the system well enough to...find problems," just as the control panels are intended to help the plant operator understand the plant well enough to identify and solve plant problems.

System specifications should be designed to make it easy for the users of the specification to "extract and focus on the important information for the specific task at hand" (Leveson 2000) without forcing the users of the specification to adapt a particular, restricted mental model or problem­solving strategy. intent specifications are system specifications based on so­ called means-end abstractions which at each point in a hierarchical view of the system. the "information at one level acts as the goals (the end) with respect ta the model at the next lower level (the means)."

In this kind of hierarchy, the "current level specifies what, the level below how, and the level above why" (Leveson, 2000; see also Rasmussen, 1986). Intent specifications are intended to simplify the task of finding specific, needed information; tracing relations between different instances of system information; understanding the rationale for the system design, and allowing the user to shift attention to different levels of detail at each intent level.

These specifications can facilitate the kind of zooming-in behavior characteristic of expert problem solvers known to "spend a great deal of their time analyzing the functional structure of a problem at a high level of abstraction before _narrowing in on more concrete details" (Leveson 2000).

These higher, abstract states of the system are needed as a point of reference for understanding erroneous behavior of the system because higher-level states describe how the system should be functioning - issues relevant, for example, during debugging.

The intent specification can support a rational design philosophy with a smooth progression from system requirements to component requirements, and down to implementation

Visualization plays a key role in defining and understanding the artifacts produced during development. Larkin and Simon (1987) did seminal work on the relationship between visualization and cognition.

Effective visualizations are known to improve learning and understanding; however, the research on visualization has tended to focus on its use in data visualization. Dulac et al. (2002) describe cognitively based interactive methods for helping developers, domain experts, and other stakeholders navigate through complex, visually presented software system specifications. The techniques are illustrated for a highly complex flight management system whose formal specification was over 500 pages in length.

It is known that a variety of cognitively based cues can facilitate effective visual representations. For example, the use of simple so-called secondary perceptual cues such as indenting or layout conventions can facilitate readability or clarify syntactic and semantic information. It may also be useful to present the same information redundantly, using different representations, with each representation simplifying some cognitive tasks. Dulac et al. (2002) introduce a list of factors that characterize visualizations. These include:

• Scope (focus on structure or focus on the behavior of the system)

• Content (the entire model or the model with temporarily elided or hidden parts)

• Selection strategy (based on dependencies between model elements or by eliding model elements)

• Annotation support (optional domain information added)

• Flexibility (allow different kinds of search strategies)

• Static or dynamic (a snapshot in time or dynamic visualizations that illustrate behavior over time)

These characteristics can be used to categorize a particular visualization. This in turn can help a visualization designer create alternative visualizations of a process - suggesting, for example, the recoding of an artifact so that it focuses in one case on the structure of the system and, in another, on the behavior of the system.

The study by Dulac et al. presents several relevant and interesting visualizations, including question-based decision trees; inverse transition diagrams that display the impossible transitions in a system; and sliced diagrams that also allow selective dependency relations.

These researchers summarize several principles that can be used to evaluate and formulate visualization aids. For example, they emphasize the importance of minimizing the so-called semantic distance between "the model in the system specification and the mental model of the system in the mind of the users." This increases not only the readability and reviewability of specifications but also the acceptance and usability of formal specifications by stakeholders.

 The structure of requirements visualizations should match as closely as possible the structure of the problem. This is related to the notion of cognitive fit (Vessey & Conger 1991), which emphasizes the impact of a problem representation on how well problem tasks can be carried out. The visualizations should support the most difficult tasks performed by the users; therefore, this entails a task analysis of potential uses.

Visualizations highlight some dependencies and suppress others; if the hidden dependencies may be relevant, a visual way of surfacing their existence should be available. Overall or gestalt views are needed to clarify global structures and relations.

It should also be possible to adapt the representation of information to facilitate different kinds of reasoning, thus reflecting the cognitive principle that "the reasoning paradigm is distinct from the representation paradigm" (Dulac et al. 2002).

Alertness to different "roles" may provide significant help in simplifying representations. For example, in navigational control systems, the amount of relevant behavior that must be considered can be greatly reduced by using modes to partition the system into disjoint behaviors that are more manageable cognitively. For example, in a flight system, the partitioning modes could be landing mode versus cruising mode.

Redundant encodings, as mentioned previously, facilitate different kinds of information access. For example, consider the elementary case of a table about classes, times taught, and instructors.

Ordered by class, the table simplifies identifying the different instructors for a class; ordered by the instructor, it facilitates identifying at classes a given instructor is teaching. Finally, it is very useful to design visualizations to be able to show the impact of changes and the indirect side effects of changes.

The interface to a system is how people gain access to the system's functionality, so effective interface design can make all the difference in the success of a product. System design is not merely a question of implementing needed functionality; it is equally about effectively imple­menting user access to that functionality.

Ineffective user interaction may be the result of interface designs that impede users from developing simple, accurate mental models for the interaction. Cognitive psychology emphasizes the significance of cognitive models for explaining how people interact with systems; users develop mental models of system behavior and these guide their interaction with the system (Rushby 2001).Indeed, so­ called automation surprises occur when a cognitive mismatch is present between system behavior and the user's mental model of the system.

interestingly, although mental models of physical objects like buildings are kinematic three-dimensional visualizations, the format of mental models for logical systems is not clearly understood - for example, whether they are akin to state transition diagrams or to "goal-oriented representations, e.g., chains of actions for satisfying specific goals" (Rushby 2001). The mental models of users evolve as they gain greater familiarity with the system. Cognitive processes involved in this evolution include frequent and inferential simplification.

Frequential simplification refers to the process by which infrequently taken interactions are forgotten; inferential simplification refers to the process in which similar interactions are merged into prototypical rules where differences are blurred.

Behavioral approaches have also been applied to enhance software usability in the area of user interface design. Chase et al. (1994) apply a technique based on a User Action Notation (UAN) to describe the cooperative behavior manifested by a user and an interface during an interaction. The UAN descriptions can utilize scenarios, screen displays, and state transition diagrams to characterize the interaction.

The authors claim that developing a model or representation of the user behavior exhibited in an interface environment requires addressing the scope of interface activities, the content of the interface, and certain performance requirements.

In this case, scope refers to activities within the interface development process such as task analysis and design. Content refers to the interaction components being represented, including user definition; cognitive processes; interface state; screen pictures; temporal relations; feedback display; etc. Requirements refer to the qualities of the representation, including facility attributes such as readability and learnability, extensibility, and expressiveness.

The conclusions of an empirical analysis suggest that Chase and colleagues' method provides useful support for the interaction development process. This work is generalized and applied to development process artifacts in the previously cited work by Dulac et al. (2002).

Curtis, Krasner, and score (1988) defined a social-context model of a software development process based on five "environmental" layers that envelop a project. An initial admin layer comprises the familiar software process artifacts, constituencies, and the roles of the various players in the development process. An individual layer concerns the attitudes, opinions, and knowledge of the individuals involved in the project.

A team layer focuses on group dynamics. A company layer addresses organizational context such as political effects, organizational culture, structure, and power. Finally, the business milieu layer addresses the organization's broader business environment or context. The contention is that the impact of each layer is correlated to the size of the project.

McGrath (1997) applies the layered framework of Curtis et al. (1988) to understand various organizational effects that can (for example) hinder the success of a software project, such as resistance to the changes caused by a project. In terms of the company layer, for example, a project is by no means a neutral entity.

Thus, a project outcome may lead to a "redistribution of power sources" (McGrath 1997) in which winners and losers are found, the latter threatened with a real or perceived loss of resources or control. On the other hand, concerning the business milieu layer, factors from competitive threats to market opportunities affect the business case for the project, which in turn affects its resources, staffing, deadlines, priority, etc.

The McGrath model formalizes these factors and concerns using a rule­ based P g-like entity-relationship description that is intended to help predict likely sources of resistance to proposed changes. Formalisms are also given that characterize the effect of system dynamics factors such as deadlines and schedule pressures on productivity. This model is related to the system-dynamics, project management model of Abdel-Hamid and Madnick (1989) described in the previous section.

following the social context model described in Curtis et al. (1988), Curtis (1989) presents a rather cogent critique of the relationship between project stages and the behavior of individual developers.

He observes that regardless of whether the model is the Sequential Waterfall, Iterative Exploratory Prototyping, or the Spiral, these management abstractions, although providing a way of "ordering, monitoring, and accounting for what is happening in the project," do not explain the design behavior of individuals, which phenomenologically "is better characterized as oppor­tunistic." This opportunistic pattern of behavior is exactly what is to be expected from cognitive research on planning, which indicates that designers move back and forth across levels of abstraction ranging from application domain issues to detailed design and even coding issues."

These variations in the behavior of developers are not triggered by timeline events, such as crossing project stage boundaries, but are recognized when problems are identified, regardless of the level of abstraction

Thus, from a behavioral and cognitive view, the software tools that designers use should be designed to be compatible with how designers and developers behave, as opposed to managerial templates for how the process is supposed to work. The implication is that software tools should allow designers to "rapidly switch levels of abstraction in the artifact and support the opportunistic exploration of design concepts" (Curtis 1989).

This is similar to what is described in the recommendations by Leveson r 2000). In particular, problems related to the "thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication and coordination breakdown" must be analyzed in behavioral terms rather than in terms of software life-cycle artifacts.

The demands of domain knowledge affect the developers who may require considerable learning time and eff become adequately familiar with the application. domain - an expenditure that can be easily ignored in planning. The customer is similarly subject to the same learning requirements, which also perturb the process through specification changes and their impacts.

Collaboration among the designers entails extensive communication to ensure design issues are understood consistently by different individuals; tools that support this communication and coordination are at least as essential as tools that support the transformation of artifacts.

Other behavioral factors such as the_ competence and training of the developers are well known to be critical to successful development; they depend on processes outside the normal life-cycle purview, like recruiting and continual growth in technical competency. In other words, the development of people is an ongoing part of a continuous, nonterminating, global software process in an organization.

Related information

Sundar  Neupane

Sundar Neupane

I like working on projects with a team that cares about creating beautiful and usable interfaces.

If felt valuable to you, feel free to share it.


Report Response