Human Computer Interface (HCI)

HCI refers to the way how humans interact with computer systems. It is the User Interface that hides all complexities and processes in the computer and back-end system programmings and give user an easy way to interact with computers. HCI is most of the time graphical but there are command prompt HCI as well such as in Linux and DOS systems. But we are here talking about graphical user interfaces.

Guidelines to consider when designing a human computer interface (HCI)

• End User - Always give prominent to the end user (user experience, education, knowledge, taste). Because the end user will be the final human who will use the system for a long time daily.
• Environment - this refers to many things from operating system to physical environment. You need to consider what kind of environment the end user will be working on with the system. It could be either office environment or factory environment and user could be using a keyboard or touch screens. User could be working standing or sitting.
• Standards and Practices - Always follow industry standards and common practices. Some times even there are no standards for some designs but always there will be common practices. Learn and follow them,
• Graphics and Colors - use adequate amount of graphics and colors only. Consistance throughout the system should be maintained.
• Navigation - always use easy to use and understand navigation system. Use common everyday wordings rather than technical wordings.
• Help - always include a help facility

Graphical User Interface (GUI)

GUI is a type of HCI that uses windows, icons, menus and pointers (WIMP) and desktop area to organize and manage works in a more realistic environment. Main advantages of GUI are;

1. Easy to understand
2. Easy to learn
3. No need to remember system commands
4. More interactive
5. GUI is the most user friendly HCI

Common GUI Elements

UML Diagrams

Unified Modeling Language is a graphical language used in system design. UML offers standard way to write system blue prints. UML can presents system's functions, processes, relationships and all other activities related such as database schemas (design), message flows, user interactions, etc.

UML is not an industry standard for writing system blue prints but is wide accepted and practices by system designers. It makes other stake holders to clearly understand the system and interact with each other. This is not a programming language but the start point for programmers to developed the system using UML diagrams.

UML diagram is a graphical presentation of set of elements, most often rendered as a connected graphs of vertices (things) and arches (relationships). There are many diagrams in UML and we are mainly talking about following diagrams.

Class Diagram: A class diagram shows a set of classes, interfaces, and collaborations and their relationships. An object diagram shows a set of objects and their relationships. A Use of Case Diagram shows a set of use cases and actors and their relationships.

Both sequence diagrams and collaboration diagrams are kind of interaction diagrams. A state-chart diagram shows states of objects, transitions, events and activities. State-chart diagram shows dynamics of a system. Activity diagram is a special kind of state-chart diagram that shows the flow from activity within a system.

Component diagram show the organization and dependencies among a set of components. deployment diagram shows the configuration of runtime processes of a system.

Even though there are lots of diagrams specified above, the real use of UML is more personal than standard. The real understanding on UML comes with the practice of real world system design.

an example UML diagram

The Object Oriented Concept

Object Oriented System Design is another concept in system design. We are talking about system analysis and design here so it is connected with programing in a later part. OOP is the latest trend in programing and when we design a system it is important to understand about object oriented concept. There are six basic things we need to understand clearly in order to proceed with the object oriented concept.

1. Objects
2. Classes
3. Messages
4. Encapsulation
5. Inheritance
6. Polymorphism

Now let’s discuss about these things one by one;

Objects (attributes / behaviors / methods)

An object is a representation of real world thing. For an example “A Car” is an object. Objects have attributes and behaviors. Behaviors are initiated by methods in programing language.  Attributes are unique characteristics which identify the object from other obejcts. In a car attributes are model, make, chassis number, engine number, vehicle number, etc. Also an object can have behaviors. Behaviors of a car can described as engine start, engine off, lights on, lights off, running, stooped, etc.

Classes (group of objects)

Class is a group of similar objects that shares same attributes and behaviors. In our car example we can define a class “Vehicle” with attributes of vehicle registration number, engine number, chassis number, make, model, etc. because every vehicle has these common attributes and behaviors such as engine start, engine stopped, lights on, lights off, etc.

In programing objects are created from classes. For an example “Car” object can be created from “vehicle” class.

Messages

Messages are instructions or information sent between objects. For an example a message “Start Engine” can be sent by an object called “Driver” in the class “Operators” to the object “Car” in “Vehicle” class. These instructions on how, when and where to send messages need to be define in programing.

Encapsulation

Encapsulation is the ability to hide internal working, data and behavior of an object. In OOP (Object Oriented Programing) objects are standalone things that they communicated with other objects using methods (getters and setters). For an example when we called a method in Car object named start_engine(), we do not worry about its internal functionality – we all care about is it’s status changes from stopped to start of the engine.

Inheritance

Inheritance is the mechanism of implementing classes with similar attributes and behaviors. There are two kinds of inheritance implementations called generalization and specialization. Also here we need to understand the concept of super class and sub class. Generalization is the process of creating super classes – super class is a class with more common characteristics. For an example generalization of “Parrot, Crow, and Chicken” is the creating of super class called “Birds”. Parrot is a sub class of birds with all its characteristics and having at least one attribute that is unique to parrot and it is called specialization of the class.

Aggregation

Aggregation is the process of building objects using other objects in similar classes. For an example the object “Car” is built using “Engine and Body” objects. Simply you need to understand that aggregation is composing of similar objects of different classes to create another object.

Dependency

This is the relationship between two objects / classes. If changes of one object affects the other is called there is a dependency relationship between two objects.  If changes in object A affect to the behavior of object B then the B is called the dependent object.

Association

Association described the relationship between two objects.

Polymorphism

Polymorphism is the way that the object orientation allows methods of same name to have predictable and meaningful results in related instances performing the operations differently to achieve similar results. For an example Play_Game() method will execute playing of different games such as play_cricket(), play_tennis(), play_soccer(), etc.

Techniques of soft system methodology

There are mainly three techniques used to represent soft systems. The first choice is using of rich pictures, then conceptual model and expanded conceptual model. Rich pictures use to capture much information as possible relating to the problem situation. Rich pictures can show boundaries, structures, information flows and communication channels. But mainly rich pictures used to illustrate human activities within the system. Rich picture is a simple use of actors and communications. There are no standard notation for rich pictures, but there are some commonly used notations such as cartoon characters, thinking bubble, eyeball, face expressions, etc.

The purpose of rich picture is to get a full view as possible of the factors involved in the problem situation. Especially elements related to environment of the problem. It may be used just by the system analyst or to discuss it with other managers as well. Some top level people may not impressed to see such cartoon characters or simplified drawings because they may expect something more attractive and complex while most of the top level managers will be impressed to discuss complex technical problems in a simplified drawings where none technical people also can understand.

In a rich picture we can root definitions as well. A root definition is individual view of a situation. It is always related to a character. For an example employees in a bank counter may see their main work as serving customers fast while the branch manager see his main role in the organization as maximizing the number of account holders. The marketing people of the bank may see their main role as to achieving sales targets. These are each actor’s root definitions in their own organizational environment. Now consider there is a significant level drop of saving accounts in the branch and the top management wants to find out the reason for the problem situation. In this case each actor in the counter, marketing and branch manager will give their own beliefs for the problem.

Root definitions expressed in short sentences rather using descriptive paragraphs. According to checkland, a root definition should follow CATWOE procedure.

C = customer

A = Actor

T = Transformation. Core activity of the system.

W = Weltanschauung (The underlying belief about the system)

O = Owner

E = Environment

When we apply this process to a customer support system:

Customer is the end user of the software. Actor is the IT support executive. Transformation or the core activity is to give support for the software system. The underlying belief about the system is that the system must be up and running always without errors. Owner of the system may be the IT manager. The environment is relative to the industry and standards. In this situation environment can be define as provide immediate customer support and resolve issue as soon as possible to keep the customer happy.

While the root definition is an important statement that managers can understand, but the most important thing is to eliciting the CATWOE elements from individuals. Compiling the root definition is the first stage in the system thinking strand and understanding human activity system.

Conceptual model

The root definitions represent an individual’s perspective of what the business system is trying to achieve. The next step is to propose an ideal model that is able to realize proposed perspectives. We built a conceptual model to understand what is happening in the real world situation. When drawing a conceptual model we first draw most broader view in then divide it into sub systems and analyze separately. The conceptual model has a very simple notation. A bubble to represent an activity and arrowhead line to link operations between activities. The conceptual model is known as first resolution model which gives high level activity descriptions and later divided in to second resolutions models or low level models.

Once the conceptual models and root definitions are completed, we compare it with the real world situations and propose possible solutions. This comparison could be done in many ways such as interviewing actors, documenting current activities and benchmarking, etc.

After the discrepancies have been identified, possible solutions are explored and their feasibility evaluated. These activities will have information needs, particularly for monitoring success. These are the first steps towards developing an information strategy / system for an organization.

SSM Framework

1. Problem Situation:

This is the situation before starting the studying the problem. At this stage the analyst will become a part of the problem to enable observation the system fully. In this stage analyst try to understand the key players in the organization / situation and how the current process works?

2. The problem situation expressed

In this situation the analyst express the problem situation / processes using rich pictures and any type of diagrams. There are know standard format for the diagrams, but it should be easy to understand the situation and explain it using diagrams. Generally data flow diagrams or object models are not sufficient to express the problems in soft system methodology.

3. Root Definitions

Roof definitions are different perspectives each participant / stakeholder look in to the problem situation. Each individual will have different views about the processes and problem situation. In this stage the analyst want to understand what is each stakeholders underlying belief about its purpose - basically asking "What" type of questions.

4. Conceptual Model

In conceptual model is to understand and provide conceptual answer to each root definition. Here describes "How to" type of descriptions for each root definition question. If one stakeholder has a particular perspective, then there must be a set of activities to be performed to meet the given perspective.

5. Comparison of conceptual model (step 4) with real world problem (step 2)

This is to compare the real world problem and conceptual model to identify similarities and differences. There are no standard way to do this comparison, and that is up to the analyst to decide based on his experience.

6. Identify feasible and desirable changes

In this stage, analyst identify and describe possible solutions for the problem situation. These can be organizational as well as environmental changes.

7. Recommendations

Provide recommendation on how to apply give solutions and improve the problem situation thereby. In this stage evaluating organizational capabilities and design ways to apply changes in the current system.

SSM (Soft System Methodology) is rather casual than formal. There are no hard rules to follow but the basic output is to eventually identify soft problems in to root causes then design solutions in formal methodologies.

Soft System Methodology (SSM) - Introduction

Problems that are complex and difficult to define clearly are known as soft problems. These problems are belongs to a large social environment. In this kind of situations we do not directly consider the problem itself but the nature of the problem. This kind of situation we try to understand what will be working and not and trying to understand opportunities to resolve intended problem situations.

For an example;

01. When we need to enter 200,000 customer orders throughout 1000 terminals in the country.
02. When customer complaints are increasing and customer retention is decreasing.

Above two situation, the first one is specific and we exactly know how to handle the situation or give solutions for the problem. But in the second one is unspecific, unclear and unable to define boundaries. It describes a problem with weak boundaries and unclear cause. In fact is is not describing a problem but symptoms. So, we need to understand what cause the symptoms and then only we can understand that are the problems and propose solutions.

The first problem is a hard problem and the second one is a soft problem.

Traditional system analysis is based on hard problems. These problems has clear boundaries and involved tangible factors such as staff, documents, procedures, equipments and structures. Therefore this can give a solution straight away.

But in the real business environment many problems are unclear and even hard problems becomes less relative to the cause of problems. Peter Checkland of Lancaster University developed soft system methodology (SSM) and recognized many problems occurred in an organization are affected by less tangible factors. Some of these includes culture, information interaction and attitude - that he defined as human activity system.  SSM's main purpose is to investigate, understand and identify problems in soft situations or in the human activity system. This is to address situations that cause problems rather than give a solution for the problem.

Soft System Methodology is based on system thinking. It views that problem domain in a holistic way rather than reductionist way. This means identify a system in components and their relationship to each other. Changes in one part will affect to the behaviour of other parts. Also in SSM problem domain itself is belongs to a larger system domain and changes in the problem domain will affect to the whole system as well.

Soft System Methodology is actually not a methodology because it doesn't define prescribe steps to be taken or set of rules to be follow. It suggests a framework with techniques to follow to understand the problem domain so deep study of the SSM can lead to understand hard problems causing the soft problem situation.