ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

I. Notion of Human computer interface (HCI)

Until the 1980s almost all commercial computer systems were non-interactive. Computer operators would set-up
the machines to read in large volumes of data and the computer would then process each input and generate
appropriate output. There are still lots of these systems in place but the world is also now full of interactive
computer systems. These are systems that involve users in a direct way. In interactive systems the user and
computer exchange information frequently and dynamically. A good interactive system is one where:
• User can easily work out how to operate the system in an attempt to achieve his goals.
• User can easily evaluate the results of his action on the system.

1. Usefulness and Usability

What interactive systems do you use in your day-to-day life? Your first response might be to identify the Personal
Computer and all its applications. However, the term ‘interactive system’ can be applied to a much broader range
of devices, including mobile telephones, cash dispensing machines, the World Wide Web, car navigation
systems…
 Usefulness
For an interactive system to be useful it should be goal centered. A useful interactive system is one that empowers
users to achieve their goals. When you build an interactive system you should make sure you use a range of design
and evaluation methods to discover the goals and associated system functionality that will make your system
useful.
 Usability
A cork-screw is a tool for opening bottles sealed with a cork. They are useful tools. However if you are a left-
handed person most cork-screws are difficult to use. This is because they are designed for right-handed people.
So, for a left-handed person the cork-screw has low usability (despite being useful).
Usability is about building a system that takes account of the users' capabilities and limitations. A system that has
good usability is likely to have the following qualities:
• Flexible. Users should be able to interact with a system in ways that best suit their needs. The system should be
flexible enough to permit a range of preferences.
• Robust. A system is robust if a user is given the means to achieve their goals, to assess their progress and to
recover from any errors made.

2. Why is HCI important?

Unfortunately many analysts and programmers might think that ‘Interfaces are something we do at the end of
software development as we want to make the system look nice for the end user’. They cannot see the point in
spending time and money on seriously considering and involving the users in design; instead they consider they
know what is best for the user and can build effective interfaces without using extensive user-centred methods.
However experience has shown that badly designed interfaces can lead to serious implications. If you build poor
interfaces you might find:
• Your company loses money as its workforce is less productive than it could be
• The quality of life of the users who use your system is reduced
• Disastrous and possibly fatal errors happen in systems that are safety-critical
Productivity: There has been a lot of interest in the past into a phenomenon known as the productivity paradox.
A system may not achieve the expectations because it is difficult to use. User waste time with difficult systems,
become frustrated and slowed down and are thwarted from achieving their employer’s goals thus yielding a poor
productivity.
Quality of Life: Consider this declaration about an online booking Web site: ‘I booked a ticket to fly to Athens
for an Easter holiday using an online e-commerce site. I was impressed by the cheapness of the ticket and that I
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

could do all the booking without leaving my computer. As you can see it was easy for this user to interact with
the web site and get its ticket.
Safety-critical systems and disasters: Sometimes poor HCI design can lead to very serious implications. There
are many systems that are safety-critical. A safety-critical system must work under all conditions without failure
or error. Some examples are: Aeroplane control systems, nuclear power control systems or computer controlled
medical equipment.

3. Designing and Evaluating usefulness and Usability

 Design
Unfortunately, sometimes when an interactive system is built, designers fail to consider an essential aspect of the
system – the human users. For successful interactions, there has to be explicit and well thought out consideration
of this human factor – usability needs to be designed into the device or system.
To achieve this, as we will see later in the course, there are a range of models, techniques and tools that can be
used to construct the system. All of these methods attempt to center the design on the user group (this is why the
methods are collectively known as User-Centered Design or UCD).
Interactive system designers must understand their users. A design developed for one type of users might not be
the best for another group.
Standard cash machines (ATMs) are designed for ‘standard’ users with no physical or mental impairments.
Example: Imagine you are designing an ATM for 75 years old people.
• List out the possible physical and mental characteristics that these people might have and that are relevant to the
design of an ATM.
• How would you design an ATM to better suit Sue?

 Evaluation
A good designer will not simply trust that his skill and experience will always produce designs that are highly
effective. Evaluation is about testing to see if the interactive system has good usability and usefulness. There are
two types:
Formative evaluation: it is not good enough just to test your system once it is completely built.
Evaluations should be carried out all the way through the design and development cycle. The results of these
evaluations should be used to guide the design.
Summative evaluation: once a system has been built then an overall assessment of its usability is needed. These
tests should be done to validate aspects of the design (e.g., is the system as learnable as we specified?) and to test
the acceptance of the system by the end-users (i.e., do the users like the system, find it easy to use etc?).

II. Software Ergonomics

Ergonomics is a body of knowledge about human abilities, human limitations and other human characteristics
that are relevant to design. Software ergonomics is a subcategory of ergonomics that concerns the software
design, rather than the hardware design, of systems. Software ergonomics includes the determination of user
needs, interface design, user support and usability testing.

 User Needs
The determination of user needs is one of the most critical part of software system design. Often, managers and
data processing personnel decide what the system should provide to users, but systems developed in this manner
usually fail. If a system does not meet the needs of a user, the user typically will not use the system, or use it
ineffectively. Determining user needs requires interviewing samples of various potential user populations to
obtain information about what users need from the system in terms of data, accuracy, output characteristics,
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

response time, etc. User needs is determined at several levels with the lower levels interacting closely with
interface design. Typically, only the higher level is referred to as "user needs", while the lower levels are referred
to as "task analysis." The following steps are typical:
1. Identify and describe potential users of the software product or system.
2. Determine the needs of those users and develop usability objectives for those needs.
3. Utilize appropriate data collection methods to describe current related task requirements and performance.
4. Analyze tasks to determine component behaviors.
5. Design (and redesign) activities into effective and efficient task structures.
As noted above, the design of the task structures must take place in conjunction with the design of the interface
because the interface will often dictate how the task can be performed.

 Interface Design
Interface design is the design of the interface between the user and the system. For software ergonomics, interface
design mostly concerns the design of the interface between the computer software and the user. Interface design
includes the design of the dialog (by which the user is guided by the system), design of the inputs that can be
made by the user and responses (outputs) provided by the system. Aspects of good software design include:
Consistency: The most important aspect of user interfaces is consistency. For example buttons should be placed
in consistent places on all screens. Use the same wording in labels and messages. Use a consistent colour scheme.
Some points vital to the development of consistent user interfaces include:

 Setting standards and sticking to them. Set designs bases on industry standards and then develop extra
standard specific to your application.
 Explain the rules. Develop a simple set of rules that apply to your entire application, in this way you only
need to explain once
 Use interface elements correctly. Know when to use screen elements and how to use them correctly. Never
alter the operation of standard screen elements such as command buttons to perform unexpected functions.
 Use colour appropriately; colour should be used sparingly. Because colour is an individualistic preference
allow the user to choose colour settings, but for default colour schemes maintain sufficient contrast
between text and backgrounds.
 Alignment of data. Editing field should be left justified with their attached labels also left justified

Dialog types or appropriate messages to the user include:

 Command dialogs - in which sequences of instructions are provided by the user to the system which, when
processed, result in associated system actions.
 Menu dialogs - in which the dialog system visually presents one or more groups of options to the user, the
user chooses one or more options, and the computer executes the desired process denoted by the option(s).
 Dialog boxes and form-filling dialogs - in which the user fills-in, selects entries for, or modifies labeled
fields on a "form" or a dialog box presented by the system.
 Direct manipulation dialogs - in which the user directly acts on objects on the screen; e.g., by pointing at
them, moving them and/or changing their physical characteristics (or values) via the use of an input device.
 Question and Answer dialogs - in which the computer asks a question and the user enters a response.
Subsequent questions are influenced by the user' response.
Each of the different dialog types imposes particular considerations concerning input and output requirements
that must be taken into account during design.
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

Ease of use and acceptable response time in software: Good User interfaces are easy to use. Some vital points
to make software easy to use include:
 Screen elements that are logically connected should be grouped together. Similarly, unrelated items should
be separated.
 Navigation between screens should follow a natural flow of the task. Applications should be flexible and
should allow users to complete tasks in the order they require.
 Applications should support both novice and experienced users. Shortcut keys and advance functionality
should be available.
 Busy screens result in confusion for users. Easy to use screens will have white space on about 50% of the
screen.
 Icons are great if the meaning of the icon is immediately obvious; if the icon is somewhat obscure then
don't use it, use text instead.
 The time between user actions and system response must be as small as possible

 User Support
User support includes all of the user oriented materials, in addition to the user interface, that will support the user
in learning and using the system. Such materials include overviews, online help, performance aids,
documentation, tutorials and training. User support materials may be online or in paper form, but the trend is to
provide all user support online as part of the system software. Online support includes:
 Electronic Performance Support System (EPSS) - Online support that is so tightly integrated with the
system that it is part of the interface. Developing an EPSS requires a high level of cooperation between
the developers of the EPSS and the developers of the application. An EPSS would typically contain
several, interrelated pieces of more traditional performance support such as online help, online tutorials,
and wizards attached to a sophisticated, supportive user interface.
 On-line Help - Online text and graphics that is contextually linked to the application at the screen or field
level. Contains information about the system; its screens, fields, and commands; and gives instructions on
how to complete tasks using the system.
 On-line User Guide - Traditional user guide information delivered online.
 On-line Tutorial - An online, interactive tutorial that does not contain testing of student performance.
Online tutorials may be delivered by means of various media, e.g., CDs, downloaded from a server to the
user’s desktop computer, or via the Web.
 Computer Based Training (CBT) - Similar to an On-line Tutorial, but is typically more performance
oriented and includes testing and tracking of student performance.

 Usability Testing
One of the most important parts of a software system development project is testing the usability of the system.
Usability often gets confused with "usefulness” (whether a product helps the user achieve their goals) and "utility"
(whether the product has the functionality that the user needs to attain their goals). The most accepted definition
for usability is found in the ergonomics standard ISO 9241-11: usability is "a concept comprising the
effectiveness, efficiency and satisfaction with which specific users can achieve specified goals in a particular
environment."
Setting "usability objectives" is a critical first step in performing usability testing. Usability objectives are
typically developed on the basis of data collected during user needs analysis. These objectives must be stated in
measurable terms so that the results of usability testing can be used to clearly establish whether the system met
these objectives.
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

Usability testing includes the development of a test plan (specifying the usability objectives, test procedures and
reporting requirements), the development of test senarios, conducting the testing according to the plan, and
reporting test results.

III. Data organization and modeling

Data are actually stored as bits, or numbers and strings, but it is extremely difficult to work with the variety and
complexity of data at this level. It is helpful to view data at different levels of abstraction.
Schema: This is the term for a description of the data organization at some level. Each level has its own schema.
We will be concerned with three forms of schemas: internal or physical, conceptual or logical and external or
user view.
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

1. Internal Data Level

The physical schema of the internal level describes details of how data is stored: files, indices, etc. on the
random access disk system. It also typically describes the record layout of files and type of files (hash, b-tree,
flat). Early applications (1960's) only worked at this level - explicitly dealt with these internal details. E.g.,
minimizing physical distances between related data and organizing the data structures within the file (blocked
records, linked lists of blocks, etc.)
Problem:
 Routines are hardcoded to deal with physical representation.
 Changes to data structures are difficult to make.
 Application code becomes complex since it must deal with details.
 Rapid implementation of new features very difficult.

2. Conceptual Data Level

Also referred to as the Logical level when the conceptual level is implemented to a particular database
architecture. This hides storage details of the internal/physical level.
 The DBMS automatically maps data access between the logical to internal/physical schemas.
 Physical/internal schema can be changed without changing application: e.g. we may add or remove an
index
 DBMS must change mapping from conceptual to physical.
 Referred to as physical data independence.
The Entity-Relationship model is at this level

3. External Data Level

An external schema specifies a view of the data in terms of the conceptual level. It is tailored to the needs of a
particular category of users. Portions of stored data should not be seen by some users and begins to implement a
level of security and simplifies the view for these users.
In the relational model, the external schema also presents data as a set of relations.
Examples:
 Students should not see faculty salaries.
 Faculty should not see billing or payment data.
 Information that can be derived from stored data might be viewed as if it were stored in that manner.
 GPA not stored, calculated when needed.
Applications are written in terms of an external schema. The external view is computed when accessed. It is not
stored. Different external schemas can be provided to different categories of users. Translation from external level
to conceptual level is done automatically by DBMS at run time. The conceptual schema can be changed without
changing application.

4. Data Modeling
Schema: description of data at some level (e.g., tables, attributes, constraints, domains)
Model: tools and languages for describing:
 Conceptual/logical and external schema described by the data definition language (DDL)
 Integrity constraints, domains described by DDL
 Operations on data described by the data manipulation language (DML)
 Directives that influence the physical schema (affects performance, not semantics) are described by the
storage definition language (SDL)
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

5. Data Independence

Logical data independence

 Immunity of external models to changes in

the logical model
 Occurs at user interface level

Physical data independence

 Immunity of logical model to changes in

internal model
 Occurs at logical interface level

IV. Conception of file or database

The simplest way to think about data structure is defining each element of the data structure as follows:
 character: as a set of bytes (binary digits) to represent any letter, number or symbol,
 field or data element: as a set of characters to represent a characteristic of an entity (name, age, sex of a
person),
 record: as a set of fields to collect information about an entity (a student record, a bank account record),
 file or table: as a set of records to collect information about a group of entities of the same type (student
file or table, class roster table or file); and
 database: as a set of files or tables to collect information about groups of related entities (the human
resources data base will have employee, benefits, discounts, etc, tables.
The database implementation or deployment is the process of installation of database software, configuration and
customization, running, testing, integrating with applications, and training the users. Its different stages and
processes are:
• Defining the database project scope
○ Identifying the subdivision of organization
○ Defining about the functions which is utilized by the database
• Organizing Database project
○ Design team development
○ Formation of database administrators
• Selection of DBMS products
○ Preparing a formal proposal and requirements list
○ Choosing the vendor for DBMS
• Development of initial implementation plan and schedule
○ Identification of files needed to convert
○ Estimation of time requirement for conversion
○ Preparation of implementation schedule
• Database design
○ Identification of data requirement
○ Determining the structure of data and entire design specifications
○ Review and approval of design specifications
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

• Training about database project

○ Preparation of the training requirement
○ Training to use the data manipulation language
○ Training for database administrator to use data manipulation and control language
• Database testing
○ Coding of data manipulation and control language, schema, and subschema
○ Database generation
○ Testing and debugging
○ Review and approval
• Periodic review and performance review
○ Evaluating the goals, information, and functional requirements
○ Evaluating the success of the implementation

V. Coding
The coding is the process of transforming the design of a system into a computer language format. This coding
phase of software development is concerned with software translating design specification into the source code.
It is necessary to write source code & internal documentation so that conformance of the code to its specification
can be easily verified.
Coding is done by the coder or programmers who are independent people than the designer. The goal is not to
reduce the effort and cost of the coding phase, but to cut to the cost of a later stage. The cost of testing and
maintenance can be significantly reduced with efficient coding. Goals of coding include:
1. To translate the design of system into a computer language format: The coding is the process of
transforming the design of a system into a computer language format, which can be executed by a
computer and that perform tasks as specified by the design of operation during the design phase.
2. To reduce the cost of later phases: The cost of testing and maintenance can be significantly reduced
with efficient coding.
3. Making the program more readable: Program should be easy to read and understand. It increases code
understanding having readability and understandability as a clear objective of the coding activity can itself
help in producing more maintainable software.
For implementing our design into code, we require a high-level functional language. A programming language
should have the following characteristics:
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

Readability: A good high-level language will allow programs to be written in some methods that resemble a
quite-English description of the underlying functions. The coding may be done in an essentially self-documenting
way.
Portability: High-level languages, being virtually machine-independent, should be easy to develop portable
software.
Generality: Most high-level languages allow the writing of a vast collection of programs, thus relieving the
programmer of the need to develop into an expert in many diverse languages.
Brevity: Language should have the ability to implement the algorithm with less amount of code. Programs mean
in high-level languages are often significantly shorter than their low-level equivalents.
Error checking: A programmer is likely to make many errors in the development of a computer program. Many
high-level languages invoke a lot of bugs checking both at compile-time and run-time.
Cost: The ultimate cost of a programming language is a task of many of its characteristics.
Quick translation: It should permit quick translation.
Efficiency: It should authorize the creation of an efficient object code.
Modularity: It is desirable that programs can be developed in the language as several separately compiled
modules, with the appropriate structure for ensuring self-consistency among these modules.
Widely available: Language should be widely available, and it should be feasible to provide translators for all
the major machines and all the primary operating systems.

VI. Project Control

Project controls are processes for gathering and analyzing project data to keep costs and schedules on track. The
functions of project controls include initiating, planning, monitoring and controlling, communicating, and
closing out project costs and schedule. Ultimately, project controls are iterative processes for measuring project
status, forecasting likely outcomes based on those measurements, and then improving project performance if
those projected outcomes are unacceptable. Activities under the umbrella of project controls may include:
 Aligning projects with portfolio/organization goals and objectives
 Developing a work-breakdown structure (WBS)
 Collaborating on initial project schedules
 Developing a risk management plan
 Project budgeting and forecasting
 Monitoring project costs
 Feedback and reporting (documentation)
 Optimizing project strategies to enable better outcomes in the future
While a project may deal with many parameters, such as quality, scope, etc., the discipline of project controls
focuses on the cost and schedule factors, continuously monitoring for any risk to them.
Hierarchically, project controls nest under project management. A project controller could be reporting to a
project manager on a specific project or an entire portfolio of projects. Project controls are integral to successful
project management, as it alerts project stakeholders to potential trouble areas and allows them to course correct,
if needed.
For project controls to succeed, they cannot be applied in spurts or in a vacuum. Rather, project controls activities
must run through the complete project life cycle—from the initiation phase until closure—to monitor and control
the various factors that impact cost and schedule.
Interweaving project controls with the rest of project management provides timely insights that empower project
stakeholders to make the right decisions at the right time. The opposite of control is chaos, disorganization,
bedlam, which are plain anathema to successful project management.
 ID2L1 : FROM CONCEPTUAL TO LOGICAL LEVEL

Project controls are all-encompassing for project definition, planning, execution, and completion; assisting in the
entire lifecycle of your project. As we said before, the use of controls will vary according to individual project
demands, but project controls address, organize, and of course control.
VII. Process organization
A software process is the set of activities and associated outcome that produce a software product. Software
engineers mostly carry out these activities. There are four key process activities, which are common to all software
processes. These activities are:
1. Software specifications: The functionality of the software and constraints on its operation must be
defined.
2. Software development: The software to meet the requirement must be produced.
3. Software validation: The software must be validated to ensure that it does what the customer wants.
4. Software evolution: The software must evolve to meet changing client needs.
A software process model is a specified definition of a software process, which is presented from a particular
perspective. Models, by their nature, are a simplification, so a software process model is an abstraction of the
actual process, which is being described. Process models may contain activities, which are part of the software
process, software product, and the roles of people involved in software engineering. Some examples of the types
of software process models that may be produced are:
1. A workflow model: This shows the series of activities in the process along with their inputs, outputs and
dependencies. The activities in this model perform human actions.
2. A dataflow or activity model: This represents the process as a set of activities, each of which carries out
some data transformations. It shows how the input to the process, such as a specification is converted to
an output such as a design. The activities here may be at a lower level than activities in a workflow model.
They may perform transformations carried out by people or by computers.
3. A role/action model: This means the roles of the people involved in the software process and the activities
for which they are responsible.