KEY ISSUES
IN
INFORMATION SYSTEMS
DEVELOPMENT
SPRING 2010
Andrew Basden
ki@basden.demon.co.uk
Phone: +44/0 1928 734 308
CONTENTS
1. INTRODUCTION
2. INFORMATION SYSTEMS DEVELOPMENT
3. KEY ISSUES IN ISD
4. ASPECTS
5. THE ISD PROJECT AS A WHOLE
6. ANTICIPATING USE
7. CREATING THE INFORMATION SYSTTEM
8. ACQUIRING KNOWLEDGE OF THE APPLICATION DOMAIN
9. CONCLUSION
10. KEY ISSUES IN ISD - SOME EXPERIENCE
11. ASPECTUAL ANALYSIS AND EXPRESSING ASPECTS
REFERENCES USED IN TEXT
SOME LITERATURE: BOOKS AND PAPERS
GLOSSARY AND ABBREVIATIONS
AGENDA
The module consists of 10-12 lectures, covering the following topics, but perhaps
not in this order:
1. Introduction of ISD as a practical process (e.g. Client Centred Methodology)
2. ISD as Multi-aspectual Human Activities
3. Aspects of the Overall ISD Project
4. Aspects of Anticipating Use
5. Aspects of Creating the IS
6. Aspects of IS Content: Knowledge Elicitation
7. Overview of Aspectual Analysis
8. Review of Module
9. Deadlines for handing in Written Work
NOTE:
{*** Pieces in curly brackets and/or with asterisks indicate work
that the student should do. They are advice rather than required
work, but if you want to pass and get good marks, then I advise
you to take notice of all these and do what they advise you to do.
If you have any problems when doing them, then email me at the
address above. ***}
1. INTRODUCTION
Welcome to the module (lecture series) called Key Issues in
Information Systems Development (KIISD).
KIISD is a Masters-level module that offers the student a broad
and rich understanding of the key, or main, issues that are important
in the development of information systems.
1.1 What is Information Systems Development (ISD)?
Information systems development (ISD) is the constructing of
information systems (IS) for human use, using information technology
(IT). ISD is the human activity when systems based on IT
(computers, etc.) are developed. This could be a small computer
program or Excel spreadsheet, or a web site, or a multimedia
presentation, a large suite of computer programs for a company, or
even a national or global system, such as for the British National
Health Service.
The activity of developing an IS is usually limited to a certain
period of time - a month for a website or years for a huge national
system - and is called a project. It is usually carried out by a team of
people.
This module does not teach ISD, nor any of the activities that
make it up, such as programming, system analysis, IS project
management, or knowledge elicitation. Rather, assuming you have
at least a basic knowledge of these activities, it examines the main,
or key', issues relevant to them so that you gain a good overall
understanding. This understanding will help you in practice.
The aim of the module is to give you 'wisdom' so that your real-
life ISD is significantly improved. The module aims to help the
student gain some understanding of the whole, broad phenomenon
that is ISD, so that they can place their existing knowledge within this
wider framework, and, beginning to appreciate that what they already
know is only part of much richer picture, they might become excited
about ISD as a whole.
1.2 What are 'Key Issues' in ISD?
Every ISD project is different. For example, in one project everyone
in the team is friendly and helpful, so they share information well,
but in another project the team members are competitive and hostile
to each other, so they don't share information. What works for one
project might not work for another: in the first project above,
informal methods of sharing might be appropriate while in the
second, formal methods are needed.
Nevertheless, there are some things that tend to give success in
most ISD projects - or to lead to failure. For example, most ISD is
to a limited budget, so keeping within budget is important. For
example, communication is important in most ISD projects. For
example, designing computer programs or web pages and expressing
that design in a language is important in most ISD projects. For
1
example, giving respect to your clients and acting ethically is
important. For example - so obvious that we tend to forget it - the
health of team members is important. And there are many more.
Recognising this diversity in ISD, gives us an two important
questions:
» Which issues are most important (or 'key') across all kinds of
ISD projects? (For example, one key issue in all ISD projects is
communication.)
» How do we make all these issues work in all the different
kinds of ISD projects we will come across? (For example, we
might need different kind of communication in small and large projects.)
The aim of this module is to help you understand what the key issues
are, and how to work them out in each project. We will find each
aspect of human activities to reveal key issues. Aim is to give you a
framework with which to work towards complete enough coverage of
all relevant issues in real-life ISD.
Link to Academic Literature:
Kautz et al. [2007] differentiated between contingent and
'persistent' problems. Though they did not identify as many as
we do in this module (they identified only 3), what they call
persistent problems we call 'key issues'.
1.3 Expectations of the Student
This module does not attempt to teach information systems
development from scratch. Rather, it assumes that you already know
something about ISD - be it programming, IS testing, systems
analysis, computer architectures, or management of ISD projects.
For example, you might have taken a course on computer ISD, or on
systems analysis, or on computer programming. Or you might have
gained experience of programming in industry or by programming
computers at home. Or you could have been employed as a systems
analyst or you could have managed IS projects in industry or
government. Even building a website is experience that would help
you make sense of this module.
If you have none of this experience, then you might find some
things do not make sense until you learn about them. I suggest you
make an effort immediately to read up on ISD. Try Wikipedia. Or
find books in the library.
1.4 Knowledge Based Systems and the Client Centred
Approach
It is recognised, however, that some students will not have much
experience of ISD activities. So we provide at the start a book that
describes some of the ISD activities in building knowledge based
systems: 'Client Centred', by Basden, Watson and Brandon.
Knowledge based systems (KBS) are information systems that
encapsulate some representation of human knowledge in order to
2
work well in their domain of application. An example is a legal
expert system, which can advise on how to write a will. To some
extent, most pieces of software may be seen as knowledge based
systems, because most encapsulate at least some human knowledge.
Example: a web site contains human knowledge, a SatNav contains
human knowledge of the country and how to navigate.
{*** Throughout the Module: The student is expected to read a
substantial part of the Client Centred book during the the module,
and then other parts of it thereafter. ***}
Each student receives one copy of the book for their own use,
and it is recommended that you take it away when you leave and refer
to during your professional life.
However, Client Centred is NOT the main part of the module. It
is only used as an example of real-life ISD. It is an example of a
methodology and approach influenced by 'everyday' issues found
when developing one kind of IS, namely KBS. Though it covers the
building of KBS, many of the issues apply to many or all kinds of IS,
especially those in which human knowledge is important, such as a
website.
{*** So, as you read Client Centred, ask yourself, "How might
this apply to the IS I am developing? How should I modify the
advice here?" ***}
1.5 We Take An 'Everyday' Approach to ISD
In this module we take an 'everyday' attitude to ISD. This means
that we try to recognise many key issues that are important in real-
life ISD, rather than only those discussed in university textbooks or
academic papers. Most textbooks on ISD cover some of the aspects
of some of the activities. In this module we try to be more
comprehensive, showing you a very wide range of 'key issues', which
you will encounter in real life.
We take an everyday attitude rather than (r.t.) theoretical
attitude.
With a theoretical attitude, we abstract certain aspects from the
complexity of life, and focus on those, developing either theories
about the way things are, or rules for how to do things. But these
usually act as a lens, which focuses on one thing and causes us to
ignore others. For example, the Waterfall Model of ISD focuses on
plans and deliverables, and ignores things like teamwork, morale,
responsibility, etc.
With an 'everyday' attitude, we are open to the wide diversity of
factors that are important in ISD, and try to take all of them into
account. That is the aim of this module: to ensure that all important
factors are included in the 'Key Issues in ISD'.
1.6 Diversity of ISD: Aspects
3
The main thing to learn from the module is what are called 'aspects'.
An aspect is a different way of looking at something (for example, a
building, for example a lecture, for example an ISD project).
Diversity: There are many ways of looking at things; so there are
many aspects.
In fact, in this module we consider all the aspects of everyday
human life to be important in ISD. At least potentially important.
Many ISD projects fail, and the reason for failure is that some
important aspects are ignored (overlooked). For example:
» Many early ISD projects focused on creating excellent software
('formative' aspect; see later), but overran deadlines (economic
aspect).
» Today, many ISD projects focus so much on deadlines and
profits (economic aspect) that team members are overworked and
treated badly (juridical aspect).
This is why we look at so many aspects. You will be introduced to
these aspects early on in the module. Students in the past have very
much liked the aspects. I hope and trust you will too.
4
2. SETTING THE SCENE OF
INFORMATION SYSTEMS DEVELOPMENT
2.1 Information system (IS)
An information system (IS) comprises
» not just the technical artefact
» but also its human context of use.
Examples:
A word processor is the artefact, but for effective use, the people who
use it must be trained.
A single-player computer game is the artefact, but to play well the
player must be trained; also, if the player is at school with homework
to do, they should not spend all their time playing the game.
A multi-player Internet game is the artefact, but to play well, each
player must not only keep to the rules, but will probably be a member
of a guild, and must organise their life so as to join in guild quests.
Examples of types of information system artefact:
» stand-alone computer programs
» spreadsheets
» knowledge based ('expert') systems
» databases
» multimedia presentations
» web sites
» multi-user Internet facilities (MMORPGs, socialnetworking, etc.)
» plug-in applications for these
» large systems that involve many of the above.
Each type has a different type of human context of use, different
types of requirements, and a different way of being developed.
2.2 Information Systems Development (ISD)
Information systems have to be developed. Usually an IS is
developed by a team of people cooperating in a project, and then
delivered to those who will make use of it - though development
carries on after that, improving the IS. Experience over the past four
decades or more has shown IS development (ISD) is not merely a task
of engineering a technical artefact, but is a complex process involving
many aspects: those of analysis, planning, communication,
maintaining good social relationships, resource management, among
others, and that the best ISD projects are ones that take seriously legal
and technical issues, morale and vision, and even the aesthetics of
programming.
» ISD looks to future possibility - many types thereof: see Aspects
below.
» ISD recognises and must be guided by responsibility. There are
many types of responsibility; each expresses a way of being good
or bad: see Aspects below.
5
» ISD is usefully managed by methodology - this is why many
methodologies have been devised. Over the years, many
methodologies have been developed to guide this process.
Over the years, many methodologies have been devised, giving
guidance to different activities that make up ISD. To understand
these activities we must understand the kinds of people involved in
ISD.
2.3 Human Beings in ISD
There are a number different human beings involved in ISD, and of
which IS developers must take full account if the ISD activity is to be
successful. We can group the many activities of ISD into four main
activities. In each of these activities a variety of people are involved.
Here are some of the people, with their activities:
» Systems analysts, users, clients: These people look forward to
try to anticipate the use of the IS: what they want the IS to do,
how the IS will be used, how it might used in unexpected ways,
and ethical issues of use. These people must consider all
stakeholders: those who might be affected when the
IS is used and those who affect its use.
» System designers, programmers, testers, documenters: These
people together create the IS. They usually do so in conjunction
with the systems analysts etc. so as to ensure what they create
will be useful and successful when in use. But they also need
information about the application domain, which comes from ...
» Knowledge engineers, domain analysts, domain experts: These
people together undertake knowledge acquisition (or knowledge
elicitation), in order to find out about the domain of application;
this knowledge determines the design, programming and testing.
» Project managers, client, funding bodies, project accountants,
lawyers, etc. These people manage the ISD project as a whole.
2.4 Applying This To Client Centred Approach
The Client Centred Methodology recommends a number of stages for
an ISD project. Each of the stages of Client Centred is characterized
by two things:
» focus on a necessary characteristic of the final technical artefact
» developing a relationship with a stakeholder (human context).
As you read through Client Centred, notice this in each stage:
Holistic picture:
» complete rich picture
» begin to develop all relationships
Skeleton system:
» system addresses the right problems: domain relevance
» relationship with experts
Demo systems:
6
» organisational fit
» relationship with client
Trustable system:
» complete, trustworthy knowledge
» relationship with domain
Usable system:
» usability
» relationship with committed users
Saleable system:
» attractiveness and ease of use
» relationship with potential users not yet committed
System in use:
» benefits
» all stakeholders
2.5 ISD as Human Activity in the World
ISD is undertaken:
» by humans (r.t. by logical/managerial processes) usually in a
team
» for humans (r.t. for economic return or technical excellence)
» in a diverse world (r.t. in isolation)
Three types of challenge:
» to ensure we consider all human issues in the ISD process
» to ensure we consider all stakeholders
» to ensure we consider all the diversity.
How to meet that challenge? (Remember that this could be for any
type of IS listed earlier, with their human context of use.)
» 'By humans': IS are not developed by computers or rules, but
by real human beings, who have emotions, friends, financial
constraints, preferences, ethical standards, and beliefs, all of
which influence their ISD activity. That is: human life is multi-
aspectual; so we use aspects to understand the real life of the IS
developers and what they need to take into account. Working on
an ISD project is governed by many types of norm (r.t. merely
economic, logical or managerial norms). Therefore there are
many types of responsibility and methodology should take these
all into account.
» 'For humans': The IS is designed for humans to use and benefit
from it. When in use, the IS is meaningful in many diverse ways
(, some of them unexpected and unforeseen during the ISD
project. There are also many roles the humans play in using and
relating to the IS; these are called stakeholders. We try to
understand the complexity by using aspects to differentiate the
ways in which the IS can be 'for humans'.
» 'In diverse world': The world in which the IS is situated is
meaningful in many different ways (r.t. only its formal purpose
in an organisation). Therefore there are many types of
7
possibility. So we use aspects to help us look at the different
possibilities.
The aim of this module is to help you appreciate and understand a
way to meet the challenge. As mentioned earlier, it does not teach
you ISD methodology but rather some of the 'key issues' of ISD.
2.6 Four Human Activities in ISD
In ISD there are at least four human activities intertwined with each
other in ISD:
» We engage in the project as a whole
» We anticipate future use of the IS
» We create the IS
» We acquire knowledge to encapsulate in the IS
These form four main activities that will be considered separately.
(Others can be found, but these are the main four.) For each, various
methodologies have been devised, for example:
» The ISD project as a whole: Prince, CMMI, SDLC
» Anticipating future use of the IS: SSM (Soft systems
methodology)
» Creating the IS: e.g. software development methods, Agile
SDMs
» Acquiring knowledge to encapsulate in the IS: e.g. MAKE
For each of the four activities, most or all the aspects are important,
but in different ways. So we will look at the aspects of each in some
detail. Each aspect reveals a 'key issue' of each activity.
Note that two of these activities (ISD project as a whole, and
creating the IS) have the character of doing, while the other two
(anticipating use and acquiring knowledge) have the character of
active knowing. With these two there is something to get to
anticipate or know, as well as something to do.
Each is a human activity, and so there is a diversity of aspects
that we need to take into account. With the 'doing' activities, we
need only consider one set of aspects each. With the 'knowing'
activities, we find two sets of aspects (aspects of the human process
of knowing, and aspects of what is known). So we have the
following sets of aspects:
» The ISD project as a whole:
- aspects of 'doing' the project
» Anticipating future use of the IS:
- aspects of the use which is anticipated, and
- aspects of 'doing' the anticipating of use of the IS
» Creating the IS
- aspects of 'doing' the creating the IS
» Acquiring knowledge of the domain to encapsulate in the IS as
content
- aspects of domain about which knowledge is acquired, and
- aspects of 'doing' the knowledge acquisition.
8
The central idea on which this teaching is built is that of aspects
of reality and multi-aspectual human functioning. We will look at
aspects and then apply them to understanding ISD. But what are
aspects? And what aspects are there? That is what we study in the
next chapter.
9
3. ASPECTS
We have mentioned aspects as a notion to help us deal with diversity
of key issues in ISD. But what are aspects? And what aspects are
there that we should take into account, practically? We will have to
use philosophy to consider this, but it should be reasonably easy to
understand, since the philosophy we use is what might be called a
philosophy of everyday life. It was first devised by the Dutch
thinker, Herman Dooyeweerd (1894-1977), and aspects were central
to his thinking.
3.1 What are aspects?
In everyday language, the word 'aspect' has several meanings. It can
be used for the facets of a jewel, or to different views of a building.
But the main use in everyday language is that aspects are different
ways in which a situation is meaningful or different ways of looking
at things. For example we might talk about the financial and legal
aspects of a business; we might talk about the biological,
psychological, social, financial, ethical and religious aspects of our
everyday lives.
To be more precise (as philosophers like to be) aspects are
spheres of meaning: aspects are ways in which things can be
meaningful. Aspects are ways in which human life can be worth
living. Aspects are also spheres of law: aspects provide different
ways in which things can be good or bad, beneficial or detrimental,
successful or failure. To give attention to aspects is to recognise the
diversity of everyday experience at work and home.
The philosopher who most seriously studied aspects was Herman
Dooyeweerd [Dooyeweerd, 1984/1955]. It was he who most clearly
recognised that aspects are spheres of law and of meaning of everyday
life. As spheres of meaning, aspects give us:
» lots of different ways in which things are meaningful and
important in ISD (example: budgetting and team relatonships are both
important), and hence ...
» different types of thing or event that we will encounter in ISD
projects (example: budgets, roles in team),
» different ways things can 'make sense' (rationality) and so
different ways in which we can discuss things during ISD
projects (example: makes sense to keep costs down, as well as maintain a
friendly attitude),
» and different types of property, which enable us to measure and
judge lots of different things going on in ISD projects (example:
flexibility of budget, quality of relationships).
As spheres of law, aspects give us:
» different ways in which we function or behave, especially as we
undertake human activity in ISD (example: we recycle material, we
welcome new members of team),
» different ways of being good and bad, which helps us guide ISD
projects (example: frugality is good, waste is bad; respect is good, disrespect
is bad),
10
» and different ways in which things might be possible in ISD
projects (example: we might have enough budget to get that extra software
that will help programmers; team members might end up in conflict, or else as
friends).
{*** Prepare For assessment: Throughout the module, be
always looking for many ways in which you can use aspects to
help you consider all those: what is meaningful and important,
types of thing, ways things make sense, types of property, ways
of being good and bad, and types of future possibility. By the
end of the module you will be expected to be able to cite all these
and give examples from a variety of aspects for each. ***}
Because of the many aspects of ISD, some of which are
mentioned above, this module makes reference to an important multi-
aspectual philosophy, that of the late Herman Dooyeweerd (1894-
1977). Dooyeweerd's philosophy is outlined on The Dooyeweerd
Pages, which the student who is interested might explore on
"http://www.dooy.info/" - though knowledge of Dooyeweerd's
philosophy as such is not expected to be learned during this module.
To say aspects are spheres of meaning is to say that each aspect
centres on some kind of kernel meaning (or central meaning), but is
surrounded by a lot more - sometimes it is called a constellation of
meaning. For example the kernel (or centre) of the psychological
aspect is feeling, sensing, responding - but around this are lots of
different kinds of feeling such as feeling of achievement, feeling of
beauty, feeling of justice or injustice, and so on.
Aspects are also spheres of law - which is to say: ways in which
life can be Good and Bad, beneficial or detrimental. For example, in
the biotic (biological) aspect, health is good, disease is bad, in the
social aspect, friendship and respect are good, enmity and disrespect
are bad, in the economic aspect, prosperity and carefulness are good,
poverty and waste are bad.
To repeat from above, as spheres of meaning, aspects give us:
» lots of different ways in which things are meaningful and
important in ISD, and hence ...
» different types of thing or event that we will encounter in ISD
projects,
» different ways things can 'make sense' (rationality) and so
different ways in which we can discuss things during ISD
projects,
» and different types of property, which enable us to measure and
judge lots of different things going on in ISD projects.
As spheres of law, aspects give us:
» different ways of functioning in ISD activity,
» different ways of being good and bad, which helps us guide ISD
projects,
» and different ways in which things might be possible in ISD
projects.
11
Each aspect is also a sphere of meaning - a way in which things
can be meaningful. As such, each aspect is the central core of a
scientific area or discipline.
3.2 What Aspects Are There?
Maslow's famous hierarchy of needs is a suite of aspects.
Checkland's '5 Es' (Efficiency, Effectiveness, Efficacy, Elegance,
Ethicality) form a suite of aspects. There are many more. Arguably
the best suite of aspects currently on offer comes from a Dutch
philosopher, Herman Dooyeweerd (1894-1977). His suite is more
compehensive than the others, is better thought out, and is grounded
in careful philosophical thought. So this is the one we will use in this
module to understand 'Key Issues in ISD'.
Dooyeweerd delineated fifteen aspects (or spheres of meaning
and law):
» quantitative - to do with amount, counting of things
» spatial - to do with space, spreading out in a continuous way
» kinematic - to do with movement
» physical - to do with energy, mass, forces, etc.
» biotic / organic - to do with life functions
» psychic / sensitive - to do with sensing, response, feeling,
emotion
» analytic - to do with distinction and clarity
» formative - to do with our ability to shape things, concepts,
organisations, etc., to do with achievement, goals, skills and
techniques; and to do with technology and history
» lingual - to do with symbolic signification: documentation,
programming, etc. and providing the basis for communication
» social - inter-personal relationships, roles in social institutions
and structures, and respect between people
» economic - to do with frugality, resources, and management of
these, including of course money and time
» aesthetic - to do with harmony (as in music), play, fun, interest,
enjoyment, art, etc.
» juridical - to do with 'what is due' to all, and legal rules and
enforcement
» ethical - to do with self-giving, generosity, going beyond what is
due
» faith / pistic - to do with beliefs, vision, commitment.
{*** To Learn and Prepare for Assessment: Please study and
get to know these aspects right from today, because they are all
important during the module. Each gives you a key issue in ISD.
Try to identify in which aspects you have experience in life.
Write down what you come across in a notebook or electronically
and then use all this in your individual assignment. ***}
Each of these is a sphere of meaning, and of law (good and bad).
They are taken from the suite of aspects by the Dutch philosophy,
Herman Dooyeweerd, and may be explored on:
12
{Link with Other Thinkers. Many other thinkers have recognised
this diversity and discussed aspects, though they usually called
them 'levels' (Newell, 1982), 'system levels' (Bunge, 1979),
'strata' (Hartmann, 1984). Dooyeweerd went deeper and also his
suite of aspects is much wider than theirs. That is why we use
Dooyeweerd's aspects here. For a comparison of Dooyeweerd's
aspects with these and others, see
"http://www.dooy.info/compare.asp.html".}
3.3 Why Bother With Aspects?
In one phrase: to understand complexity.
» Aspects, as spheres of meaning, give us a way of understanding
the complexity of things happening around us, and of our own
involvement in them.
» Aspects, as spheres of law, give us a way of understanding the
complexity of different ways in which life can be good or bad. It
can be good in one way, but bad in another - e.g. a business that
makes a profit (economic good) but demands employees sacrifice
their social lives (social and ethical bad).
This applies to ISD. ISD is one complex part of human life. The
key idea on which this module is based is that if we function well in
all the aspects, then ISD will go well, but if we function poorly in
any aspect, then ISD might go badly. The aspects, as spheres of
meaning, help us separate out what it is meaningful to focus on in
trying to achieve good ISD - aspects help us see the key issues in
ISD.
3.4 Understanding More About Aspects
The aspects are ways in which things can be meaningful (or
meaningless).
Example: Think of what this module might mean in your life.
» It might help you get a better job: that is the economic aspect.
» It might help you become a better programmer; that is the
formative aspect of achievement and skills.
» Some students have reported that it has helped them enjoy
programming more, and find programming fun and interesting;
that is the aesthetic aspect.
» The module might help you become clearer what you want to do
in life, or even what topic you might like to do for your
dissertation; these are the analytic aspect.
» A few students have found this module helps them believe in
themselves more; that is the faith aspect.
» And so on.
{*** Example: Think of what your mobile phone (or some other
possession) means to you - does it mean something socially, does
it mean fun, does it mean something lingually, does it mean
something formatively, and so on? Work that out for
yourselves. Discuss it with others in the class. ***}
13
The aspects are ways of functioning.
Example: Think about in which aspects you are functioning as you
read this:
» You are reading; that is lingual functioning. But you are also
functioning in most other aspects simultaneously ...
» You are breathing; that is biotic functioning.
» You are seeing the page; that is psychic (or sensory) functioning.
» You are differentiating what is important in what you see (e.g.
the words), from what is unimportant (e.g. creases in the paper);
that is analytic functioning.
» You are forming thoughts in your mind as you read; that is
formative functioning.
» You are aware that you have limited time; that is economic
functioning.
» You are trying to do justice to the text; that is juridical
functioning.
» You are currently committed to reading this, and to some extent
you believe or disbelieve what you read; that is faith functioning
(note: believing and disbelieving are both faith functioning, but
one is positive, one is negative).
Back to the early aspects ...
» There is just one book, and it has a number of pages; that is
quantitative functioning.
» The book is in front of you; that is spatial functioning.
» Your eyes are moving; that is kinematic functioning.
» And so on.
Example: Examine any activities you undertake, such as having
breakfast or making a phone call, and try to work out how you
functioning in each aspect. This is good practice for getting to know
the aspects, to help you in the assignments.
The aspects provide normative guidance: each aspect tells us a kind of
good and bad.
Example: Think of the following aspectual functioning and decide
whether they are good or bad:
» Lingual: telling truth or lying
» Social: respecting people or not
» Juridical: doing justice to people
» Formative: being industrious or lazy
» Lingual: explaining things or giving only part of the truth
» Economic: wasting resources or being careful with limited
resources
» Analytic: clarity of thinking
» Biotic: good health
» Ethical: being generous, or selfish
» Faith: disloyalty or commitment
» Juridical: injustice
{*** Discuss: Can a human activity be good in one aspect but
bad in another? Think about Robin Hood. ***}
14
In general, it is better if we function well in all aspects. This is
called the shalom principle.
{*** Look up: http://www.dooy.info/shalom.html ***}
3.5 Irreducibility, Dependency, Coherence
The aspects are irreducibly distinct from each other, such that the
meaning and laws of one aspect can never be explained in terms of
others without damaging it. This is called irreducibility or sphere
sovereignty.
But they also relate to each other, such that good functioning in one
aspect depends on good functioning in earlier aspects. This is called
foundational dependency.
For example:
» To function well socially, we usually need to communicate well,
i.e. function well lingually.
» To function well lingually, we need to construct our sentences
well, which is formative functioning.
» To construct our sentences well, we need to be clear about what
we want to say or write, which is analytic functioning.
» To do this, we need to see and/or hear, and our brains need to
function satisfactorily, which is psychic functioning.
» and so on.
Now we begin to use the aspects to help us identify and think about
key issues in information systems development. Each aspect tells us
of several different key issues.
There is also anticipatory dependency, which refers to the fact
that usually no aspectual functioning is done just for its own sake, but
is for the sake of others, especially those later than is. For example:
» We function lingually in order to function socially.
This gives a coherence to the aspects. It was crucial to
Dooyeweerd that the aspects are not just distinct categories, but that
all work together.
{*** If you want to find out more about this, read Chapter III of
Basden (2008), Philosophical Frameworks for Understanding
Information Systems, available in library. ***}
3.6 Applying Aspects as Key Issues in ISD
Each of the four main activities in ISD is multi-aspectual human
functioning. Each aspect applies in different ways in the four
activities. For example:
» lingual aspect of creating the IS:
writing the computer programs, websites and documentation;
» lingual aspect of anticipating use:
communicating with potential users and clients, reading
material they provide about human activity in the domain of
15
application (e.g. nurses), and communicating this to those
creating the IS;
» lingual aspect of knowledge acquisition:
communicating with domain experts, reading about the laws
and structures of the application domain (e.g. about anatomy
of human body and efficacy of drugs); creating diagrams and
tables to express the knowledge obtained; communicating
this to IS creators;
» lingual aspect of whole ISD project:
communication among all team members; project records.
You can see clearly that if any of these lingual aspects are done
badly, then the success of the project might be jeopardised. The same
goes for each aspect.
In short, each aspect of each activity points us to important
Key Issues in ISD. So we will now look at all aspects of each main
human activity of ISD.
16
4. THE ISD PROJECT AS A WHOLE
Here we consider the ISD project as a whole - from beginning to end.
The focus is on facilitating the whole project, keeping all the various
functionings together, keeping the team together, etc.
For Project management there are three levels of expertise:
» knowledge of stages and methodology to be used
» skill in applying that in practice, knowing what is important and
what corners can be cut when necessary
» wisdom: understanding of multi-aspectual nature of whole project
and links with other ISD activities
4.1 Extant Thought About Whole ISD Project
During the 1960s programmers programmed but with no method.
During the 1970s methods and methodologies were standardised,
usually as a sequence of steps to be carried out. This gave rise to
linear methodologies like the famous Waterfall Model [Royce,
1970]. But these proved inflexible, and often though the IS met the
specification, it did not suit user needs, and proved a disaster. The
main problem was that users, once they began to use the IS, found
their work patterns changing and needs changing. In the 1980s
iterative methodologies were devised, in which users are involved in
cycles of design, and what is needed to support work changes can be
incorporated into the design of the IS before it is handed over. One
such iterative methodology is Boehm's Spiral Model [1988]. Problem
of iterative methodologies was that they would wander over budget
and miss deadlines because it was easy for users to keep finding
things they wanted changed. The Client Centred approach tried to
overcome both sets of problems by taking a different approach, which
focused not on what to do at each step, but a series of necessary
characteristics of the eventual IS. In more detail:
» Linear methodologies see the project as a sequence of well-
defined steps, in which each step prepares a deliverable for the
next and then 'signs it off' as they hand it over. Typically the
steps are: User requirements analysis, then Specification, then
Design, then Programming and Testing, then Delivery.
Problem: it is usually difficult to draw up a specification so early,
because things change, and clients change their minds when they
try out the IS. Benefit of linear methodology: interfaces well
with plans of rest of organisation.
» Iterative methodologies see the project as cycles of development,
making it possible to respond to unforeseen circumstances or
requirements. Problem: difficult to control or plan, with projects
being late. Benefit: more responsive to what clients and users
really want.
Client Centred Methodology is a combination of the above. Read
'Client Centred' chapters A3 and B3 especially.
17
{*** Read Client Centred chapter B3, A3, A4 for more on that.
***}
Also, Boehm's approach burdens people down with
administration. Also, in practice, each ISD project has both iterative
and linear components. In reaction to these, in the 1990s, agile
methodologies emerged, such as Extreme Programming and
SCRUM.
Another approach to understanding and undertaking the ISD
project as a whole is taken by Hirschheim, Klein & Lyytinen [1995].
In §2.3 they set out seven 'generations' of ISD from the point of view
of the whole project, not so much in terms of mechanisms and
deliverables, but in terms of what is the important goal or vision for
ISD: what should 'drive' the whole project. They identify the
following: control, analysis, flexibility (iterative approaches),
participation, sense-making, workers' rights, and emancipation.
{*** Read §2.3 of Hirschheim, Klein & Lyytinen [1995], to gain
a view of what things people thought are important. ***}
4.2 Understanding Extant Approaches
What we teach on this module goes beyond both, but takes account of
both, and more. We can understand this by asking ourselves, "Which
aspects does each approach treat as particularly important?"
» Linear approaches: the juridical aspect, because they want to be
sure that what is handed down to next stage is appropriate, and
the economic aspect, in wanting to control deadlines and costs.
» Iterative approaches: the analytical aspect of getting a clear idea
of what users need and the pychic and social aspects of ensuring
users feel involved and there is a good relationship with users.
» Agile approaches: the formative aspect of achieving a good
design, and aesthetic aspect of ensuring team members enjoy
their work.
» Hirschheim, Klein & Lyytinen: the faith aspect, of what is of
ultimate importance in determining the kind of methodology
adopted.
In the approach we adopt here, we acknowledge all aspects and treat
all aspects as important. In fact, each of the above approaches does
involve all aspects, but tends to over-emphasise certain ones at the
expense of others. It is on the basis of aspects that we can criticise
them and make suggestions for improvements.
{*** The Group Assignment involves reading some approaches
and evaluating them from the point of view of aspects. ***}
4.2 Aspects of Carrying Out the ISD Project
18
Most methodologies focus on the analytic, formative, lingual and
economic aspects. Very few focus explicitly on the other aspects, but
they are important, for example, in the following ways (*you should
try to think of others*).
» quantitative -
» spatial -
» kinematic -
» physical -
» biotic - anyone ill?
» psychic - is everyone happy?
» analytic - clear objectives?
» formative - well-thought-out plans? control?
» lingual - good communications within team, with those outside?
good recording
» social - good relationships within team? good respect? good
structures of leadership? good relationships with those outside?
» economic - good management of budget, time, expertise?
» aesthetic - orchestrating the whole project (so that all people
and things play their part)
» juridical - the contract? do other stakeholders receive their due?
Client as centre of responsibility.
» ethical - attitude in team: generous, or self-centred? Sympathy
with users, who will have to change their ways of working.
» faith (faith, 'pistic') - vision of the project, morale, loyalty
The lecture will discuss these, with reference to the lecturer's
own ISD experience.
{*** Read More:
» 'Client Centred' chapters A3, B3 for linear v. iterative
» 'Client Centred' chapter A11 re. Project Organisation
» 'Client Centred' chapter A18 re. managing user expectations
» 'Philosophical Frameworks for Understanding Information
Systems' [Basden, 2008] Chapter VI §6.3.
***}
19
5. ANTICIPATING USE
Anticipating future use of the IS - we seek to understand how the IS
will be used, what the benefits and detrimental impact will be, etc. In
this, we seek to ascertain the user requirements or needs, but we also
do more: we anticipate how using the IS will affect those who use it
and other stakeholders - benefits and detrimental impact will be, etc.
For anticipating use there are three levels of expertise:
» knowledge of techniques for anticipating use
» skill of knowing what to look for and when something is missing
and how best to obtain it
» wisdom: understanding of the multi-aspectual nature of
anticipating use and how it links with other ISD activities.
5.1 Aspects of Use of the IS:
'Use' (human use of computers) is itself three multi-aspectual human
functionings:
» HCI (human-computer interaction)
» ERC (engaging with represented content)
» HLC (human living with computers)
In each, the user experiences the IS. The user functions in all the
aspects as they do so, but in a different way. As they do, it is hoped
that benefit and good will occur, rather than harm and evil - in that
lies the success of the IS. So, the challenge in anticipating use is to
find out how the IS will achieve benefit rather than harm. This
means considering all stakeholders. And as far as possible involving
all in the project. But beware of the 'democratic' approach in which
certain vocal interest groups dominate, so that other aspects are
overlooked.
Will using the IS ...
Does the methodology help ensure that the IS in use will ...
» quantitative -
» spatial -
» kinematic -
» physical -
» biotic -
» psychic -
» analytic - ... help users more clearly understand what is
important in their work or life?
» formative - ... help users achieve more effectively? or less? ...
make users more or less creative?
» lingual - ... help users communicate better or worse?
» social - ... help users be more or less sociable?
20
» economic - ... help users conserve or waste resources? (e.g.
time, people, power (climate change))
» aesthetic - ... be fun or boring? ... help users harmonise or
fragment their lives and work?
» juridical - ... ensure that all stakeholders receive their due, or
will the interests of any stakeholder be damaged? (esp. those
often forgotten)
» ethical - ... make users more selfish and self-centred, or more
generous and self-giving?
» faith ('pistic') - ... enhance or damage vision? ... enhance or
damage faithfulness?
To ensure that all such aspects of future use are fully considered
requires considerable skill and wisdom on behalf of those anticipating
use. This means that the human process of anticipating use itself
must function well in all aspects.
(*** Read More:
» 'Client Centred' chapter B2 to understand usage.
» 'Philosophical Frameworks for Understanding Information
Systems' [Basden, 2008] Chapter IV, about HCI, ERC, HLC,
§6.4
***}
5.2 Aspects of the Process of Anticipating Use
There are also aspects of the 'doing' of anticipating use. These are
aspects in which the IS developer functions in anticipating use, such
as interviewing users, pondering the future usage situation, or making
searches. For example:
» quantitative - how many people you interview to gain knowledge
of the domain, how many questions asked, etc.
» spatial -
» kinematic -
» physical -
» biotic - (obviously) do not visit people when ill
» psychic - the feelings of those whom we interview
» analytic - differentiating issues of usage, the important from
unimportant, and even different aspects of usage (see Aspects of
Use); clarifying the role the IS will play; identifying all
stakeholders; clarifying client requirements; differentiating
between benefits and detrimental impact
» formative - processing information about IS use, bringing it
together; planning how to approach clients, users, etc.
» lingual - reading, discussing information about IS use, searching
for the information; language and media used in discussing with
clients, users, etc.
» social - maintaining relationships of respect with those whom we
interview; knowing the structure of organisation, so as to know
whom to approach; recognising that clients, users etc. might not
have the same shared background knowledge as you do.
21
» economic - everyone whom we want to interview is very busy!
» aesthetic - maintaining humour and good style with people
» juridical - doing justice to interviewees; responsibility for
appropriately considering future use; seeking benefits rather than
detriment
» ethical - treating people generously, and not taking advantage of
them.
» faith, faith ('pistic') - belief in the IS, or lack of it.
{*** Read More:
» 'Client Centred' chapters A5-A10 for anticipating use at the start
of project.
» 'Client Centred' chapters A12, A13, A19, A20 for anticipating
use throughout the project.
» 'Client Centred' chapter A7 re Stakeholders
***}
22
6. CREATING THE INFORMATION SYSTTEM
Creating the IS refers to design and construction of
» the technical artefact
» the human context of use.
Creating the technical artefact (program, system, database, website,
etc.) involves technical design, programming, testing, documentation,
etc.
Creating the human context of use involves planning the human and
technical relationships, defining roles in relation to the IS,
establishing rules and procedures, training, perhaps even hiring new
people, etc.
There are three levels of experience.
For programming:
» knowledge of the computer language and how to write programs
that work
» skills: 'hygiene' in programming, good practice, understanding
e.g. where to use pointers and where to use arrays, and when to
test variables
» wisdom: awareness and understanding of multi-aspectual nature
of programming and links with other ISD activities
Examples of issues to consider (of creating the program (P:) or the
context of use (X:)) (and which a good methodology will help you
consider):
» quantitative -
» spatial -
» kinematic -
» physical -
» biotic -
» psychic -
» analytic -
P: concepts (variables) clear?
X: clear what difference the IS will make?
» formative -
P: structuring of data, design of algorithms; bug fixing and
getting it working!
X: planning its context
» lingual -
P: documentation.
X: training users.
» social -
P: relationship with other programmers (e.g. programmer-
teams).
X: organisational structures.
» economic -
P: program efficiency; UI screen area, etc.
X: resources required to use the IS properly.
» aesthetic -
P: style of UI; 'beauty' of the program.
23
X: Making use enjoyable; harmonising with its usage context.
» juridical -
P: doing justice to the information and knowledge (no short-
cuts!).
X: ensuring appropriate to context.
» ethical -
P: loving your program.
X: ?
» faith ('pistic') -
P: overall vision for the program.
X: preparing the users to know why this IS is good.
Note: There is an approach to programming called Aspect Oriented
Programming. This is not necessarily using Dooyeweerd's aspects.
But it does recognise that there are many different aspects that must
be taken into account.
{*** Read More:
» 'Philosophical Frameworks for Understanding Information
Systems' [Basden, 2008] Chapter VI §6.5.
Unfortunately, no chapters of 'Client Centred' discuss programming.
So you must select from the following books, which give material
about the real-life of computer programming, or choose your own.
» Knuth DE (1984). Literate Programming. The Computer
Jnl 27(2):97-111.
» Donald E. Knuth, 1992. 'Literate Programming'. Centre for
Study of Language and Information, Leland Stanford Junior
University, USA.
» Forman S Acton "REAL Computing Made Real: Preventing
Errors in Scientific and Engineering Calculations" Princeton
1996 (Reprinted 2005 by Dover)
» Hunt A. Thomas D (2000) The Pragmatic Programmer:
From Journeyman to Master. Addison-Wesley. Reading
Massachusetts.
» Steve McConnell "Code Complete" 2nd edn Microsoft Press
2004
» Robert Charles Metzger "Debugging by Thinking: A
Multidisciplinary approach" Elsevier/HP 2004
» Lisa Simone "If I Only Changed the Software, Why is the Phone
on Fire? : Embedded Debugging Methods Revealed" Elsevier
2007
» Subramaniam V, Hunt A (2006) Practices of an Agile
Developer: Working in the Real World. The Pragmatic
Bookshelf: Dallas, Texas.
» Oram & Wilson "Beautiful Code: Leading Programmers Explain
How they Think" O'Reilly 2007
» "Code Quality: The Open Source Perspective" Addison-Wesley
2006
***}
24
7. ACQUIRING KNOWLEDGE OF THE APPLICATION
DOMAIN
To create the IS (both parts) requires acquiring knowledge to
represent in the IS. This is knowledge about the domain of
application. Once the knowledge about the domain has been
acquired, it might be written into the program, stored in a database,
or encapsulated into rules and training. As mentioned earlier, both
the activity of acquiring knowledge and the knowledge of the domain
itself are multi-aspectual.
For knowledge elicitation there are three stages in becoming an
expert:
» knowledge of how to elicit knowledge e.g. techniques like
interview
» skill in how to obtain high quality knowledge; this is what is
taught in the Client Centred book.
» wisdom: understanding the multi-aspectual nature of the activity
and the multi-aspectual nature of the knowledge to be acquired,
and how they link with other ISD activities
7.1 Aspects of the Domain of Application
The domain of application itself is multi-aspectual. So the knowledge
we must acquire about it is most likely to be multi-aspectual. So we
must be very open to all aspects of the domain.
For example, a good computer game has a good representation of
every aspect, such that it is realistic therein. (In some aspects the
game deliberately goes against reality as we know it, but seldom goes
against the kernel meaningfulness and basic laws of the aspects. For
example dragons emit fire, but we still have the kernel aspectual
understanding that fire burns and kills.) Examples of question to ask
about computer game in each aspect:
» quantitative - Can character gain a feeling for amounts of things
easily?
» spatial - Can character orientate themselves?
» kinematic - How easily can character move around?
» physical - Are solid things solid? Does force push or hit things?
» biotic - Eating, drinking, resting, etc.?
» psychic - Does the character have realistic feelings? Can they
hear or see in the game?
» analytic - Can the character identify things they come across?
» formative - Does character or player have to make plans?
Construct objects?
» lingual - Can character or player make notes, or correspond with
others? Are there signs or notes to read?
» social - Does character operate alone or in group? Friends or
enemies?
» economic - Does character have to be careful to obtain and
conserve various resources?
» aesthetic - Is playing fun? Surprises?
25
» juridical - What are the laws within the game? What is due to
each type of character?
» ethical - If the character is generous or self-giving, does this
improve the game or its atmosphere?
» faith ('pistic') - What is the character about in the game? Is
loyalty and commitment rewarded? Is there realistic
representation of religion?
Likewise, a good mature database, knowledge management
facility or good website will exhibit nearly all aspects. We can
formulate similar questions to those above. We can also ask:
(a) Which aspects are most important in its content?
(b) Do all the other aspects in its content support these?
(c) Is any aspect ignored or overlooked?
{*** Exercise:
Find a good website, and look for all aspects in what it tells you
about. Ask yourself the above three questions. ***}
To obtain high quality knowledge in every relevant aspect of the
domain requires certain skills, attitude and wisdom. That is, the
process of acquiring knowledge is itself a multi-aspectual human
activity, in which every aspect is important.
Note:
There is a mistake in 'Client Centred'. It talks about
'knowledge-free' systems. I now believe there is no such thing as a
knowledge-free system, because all systems encapsulate at least
*some* knowledge. Even a simple calculator encapsulates knowledge
about numbers and arithmetic (the quantitative aspect). Even a word
processor encapsulates knowledge of the lingual aspect, such as that
paragraphs are separated by white space, that words within a
paragraph can be wrapped, and that all words used should be within
the vocabulary (spell checking).
7.2 Aspects of the Activity of Knowledge Acquisition
The activity of knowledge acquisition involves two sub-activities:
» knowledge elicitation (obtaining knowledge by speaking with
experts in the domain, or by reading appropriate literature, or in
various other ways)
» knowledge representation (programming, coding)
Traditionally they have been assumed to be two separate activities one
after the other, but experience has shown that the very act of
representing knowledge actually stimulates new insight and new
knowledge emerges. So it is better to see them as occurring together.
This combined process involves most or all of the aspects as
follows. Each aspect is a key issue of this activity. (Compare with
aspects of the activity of anticipating use, since both activities involve
interviewing people, but there are also important differences.)
26
» quantitative - how many people you interview to gain knowledge
of the domain, how many questions asked, etc.
» spatial -
» kinematic -
» physical -
» biotic - (obviously) do not visit people when ill
» psychic - the feelings of those whom we interview
» analytic - differentiating concepts and issues that are important in
the domain from those that are unimportant
» formative - searching for information about the domain;
processing information about the domain; linking bits of
knowledge to each other, and bringing it together into a
structured whole
» lingual - reading, discussing information about the domain;
modelling the domain; decide how to code the information
obtained
» social - maintaining relationships of respect and trust with those
whom we interview; involvement with professional organisations
with an interest in the domain (e.g. the Royal Institute of
Chartered Surveyors, in the domain of surveying); knowing who
are the experts; the social component of tacit knowledge
» economic - everyone whom we want to interview is very busy!
also costs of interviews etc.
» aesthetic - maintaining humour and good style with people;
seeing how the knowledge obtained coheres together, rather than
being fragmented; finding the domain interesting;
» juridical - doing justice to the domain, not taking shortcuts; doing
justice to those whom we interview
» ethical - loving the domain; treating people generously, and not
taking advantage of them.
» faith, faith ('pistic') - belief in the importance of the domain (or
otherwise).
Important: These are not the only manifestations of these
aspects. Rather, they are just illustrations of how each aspect is
important in the human activity of knowledge acquisition. As you
learn the craft of knowledge acquisition, you should try to build up
your own repertoire of issues in each aspect. To do this, use your
common sense, but use the list of aspects to ensure that you have not
overlooked anything important.
{*** Read More:
» 'Client Centred' chapters B7, A15
» 'Philosophical Frameworks for Understanding Information
Systems' [Basden, 2008] section §6.6
***}
27
8. CONCLUSION
What are the Key Issues of ISD? The answer we have suggested here
is that each aspect of each human activity of ISD is a Key Issue, or
rather that all the key issues can be discovered by considering each
aspect of each activity. So, potentially, there are 4 times 15 = 60
key issues.
ASPECT Whole Ant'pating Creating Knowledge
Project Use IS Acquisition
quantitative x x x x
spatial x x x x
kinematic x x x x
physical x x x x
biotic x x x x
psychic x x x x
analytic x x x x
formative x x x x
lingual x x x x
social x x x x
economic x x x x
aesthetic x x x x
juridical x x x x
ethical x x x x
faith 'pistic' x x x x
Sounds confusing? Well, the first few aspects rarely give key issues.
And we have separated the aspects into groups above, to help you
understand.
In the final lecture some of the following is likely to be discussed:
» How 'Client Centred' links with Dooyeweerd, esp. with asp anal,
the everyday approach and importance of human aspects in each
stage
» More about Dooyeweerd's philosophy and invite further study
» Each aspect of each human activity reveals one or more key
issues in ISD. e.g. social aspect of Whole Project is respect,
relationships, structure of team and roles of members.
» Summarise how module is relevant to all kinds: to IS people,
business people, programmers, electrical engineers
28
9. KEY ISSUES IN ISD - SOME EXPERIENCE
This section summarises some projects in which the Lecturer has been
involved, in his time outwith Academia (1973-1987). They are used
to provide material around which aspectual analysis of the four main
threads of ISD may be discussed.
9.1 Projects
- CLINICS: 1974-80, Health sector. Medical records system to
collect data from and of general practice, so as to be able to explore
the nature of quality of care; also to assist running and medical
activity of practice by delivering reports. Was in use.
- SCCES: 1981-5, Materials science in chemical industry. Expert
system to calculate risk of stress corrosion cracking in chemical plant
- a very unpredictable and dangerous problem. Was in use by its
developer.
- SYSLAG: 1982-4, Materials science in chemical industry. Expert
system to advise on type of insulation to use to lag diverse kinds of
pipes in chemical plants. Used by its developer and others.
- Wheat Counsellor: 1983-5, Plant protection division in chemical
industry. Expert system to advise farmers on fungicides to use on
winter wheat crops. Front-ended by a Viewdata-type system so
farmers could access it from a distance (pre-Internet); W.C. was
intended to be one of many systems available over Viewdata. Used
by ICI marketing and also began to be used by farmers, but the buggy
front-end was scrapped.
- Business Strategy: 1984-5, HQ of large chemical firm, plus all
divisions. Expert system to help managers assess and discuss the
'health' of business areas for which they are responsible. AB only
involved from a distance. Got into use throughout ICI plc and so
valuable as to be made Company Confidential.
- Elsie: 1986-7, Construction industry. Expert system to assist
Quantity Surveyors in giving advice in a lead-consultant (pre-
architect) role to clients who wished to consider building offices. In
particular, to help in setting budget. Got into widespread use in
surveying profession.
- INCA: 1993-5, Construction industry and academia. Expert system
to write construction contracts. Tried radically new approach, of
writing from first principles, rather than amending standard forms -
thus assisted research into this new approach. Only a demo system
produced. In addition, the system was testbed for new 'proximal user
interface' and Istar toolkit.
9.2 Overall ISD Project
- CLINICS: - I was programmer and system designer but helped to
keep medical stakeholders 'on board'
29
- SCCES: Client wanted to explore the potential of the technology
but also use it; engagement with client was crucial, exploring 'with
him', and also engaging a little in the inter-regional politics of ICI
plc.
- SYSLAG: Client developed his own, so my role was to give
helping hand.
- Wheat Counsellor: I was knowledge engineer and programmer. I
was a key liaison with software supplier (Savoir). I helped 'save' the
project (or rather stave off eventual collapse so it could get into use)
by agreeing to help program the Viewdata-Savoir interface.
- Business Strategy: Involved at a distance, advising project
champion on expert system technology.
- Elsie: Key role. Joined after project had been defined as chief
knowledge engineer and system builder. Many discussions with top
surveyors to not only elicit knowledge for the ES, but also about how
the system would be used. Also involved in plans for bringing the
system to position of financial sale.
- INCA: Research project leader. Discussions at strategic level of
what approach we should take and how to take it. Also joint-
developer of basic KR toolkit software.
9.3 Anticipating Use
- CLINICS: Users = doctors and other medics, practice
management, lead researcher into quality of care, and data input
personnel; Affecteds = patients. Always had these in mind. 'Bent
over backwards' to respond to people's requirements.
- SCCES: -
- SYSLAG: -
- Wheat Counsellor: Users: farmers, fungicide retail suppliers, ICI
plc marketing. Considered:
» what questions should be asked of farmers (what questions could
they be expected to answer)
» Wording: would they misunderstand?
» Proactive responsibility for inserting 'low input' possibility,
thereby hoping to contribute to change structure of industry
- Business Strategy: Working at strategic level, not operational. So
key issue: to stimulate users to think for themselves and to encourage
users to disbelieve the computer, and not treat computer as always
right. So a session would be punctuated by "Before I tell you my
conclusions about this issue, please tell me what you think" and
facility to explore why user disagrees with computer.
- Elsie: Users: quantity surveyors with clients. But intended
originally to be used by less-than-top experts; in fact used by top
experts to check and critique their own advice and check nothing had
30
been overlooked. Also changed way of working with client (two-
stage) and relationship with client. These were unanticipated effects.
Incorporation of knowledge-level features and 'trivial' features
that made it much more usable.
- INCA: Intended to enable different way of writing contracts.
Intended to reduce adversarial nature of construction industry and thus
change social structures. (Traditional way: amend standard forms of
contract, to yield a contract which satisfied neither party, so both
parties used contract as a way to find loopholes of which they could
take advantage.) Intended to stimulate discussion between surveyor
and client by asking questions that would cause them to clarify what
precisely they would agree on, so that contract would properly reflect
the genuine agreement between parties.
Here is a table that summarises the above. When we look more
closely we find two types aspects of anticipating use: aspects of the IS
developer's process of anticipating use, i.e. aspects of the developers'
human life, and aspects of the use itself, i.e. aspects of the users'
human life.
PROCESS OF ANTICIPATING USE USE THAT IS
ANTICIPATED
CLINICS:
Soc: good relshps Jur: what due to
patients
Eth: 'bent over backwards' Lng: data input
Wheat Counsellor:
Econ: farming business
Ps: future of farming
Ps: reputation of ICI
Lng: questions to be asked Ps: vision of
suppliers
Lng: Wording clear
Ps: belief to proactively
seek 'low-input' knowledge
Business Strategy in ICI:
Ps: vision for different Anl: stimulate
questions
role of computers Soc: enhance
relationships
Fv: planning strategy
Ps: vision where bz to
go
Elsie:
Ps: understanding what Elsie Ps: new role for QSs
trying to achieve Eco: managing Svyr
expertise
Soc: good relationships in team Soc: Svyr-client
relationship
31
Anl: clarify important issues Anl: clarify client
requirements
Lng: reporting ideas back to usersLng: recording
sessions
Fv: adding usability features Aes: style of working
Eth: .. incl. 'trivial' ones
INCA:
Ps: new way of writing contracts Ps: new way of using
contracts
Anl: understanding how contracts Jur: contracts as such
operate in real world Soc: relationship btw.
parties
Fv: ensuring good structure Lng/Soc: stimulate
discussion
of contract Anl: clarity where
agree, disagree
Eth: getting away from
each taking
advantage of other
(loopholes)
Aes: harmony in
construction industry
9.4 Creating the IS (Technical + Human)
- CLINICS: T: Around 40 programs (COBOL + assembler), a few
for data entry and storage and maintenance, but most for reporting
and queries. Punched cards. Lots of comments included in
programs. H: Forms to fill in. Procedures for data entry and
checking and maintenance. Procedures for regular reporting, and for
queries.
- SCCES: T:
» Savoir KBS toolkit.
» Developed intimate relationship of trust and respect with expert,
so that he was more than willing to divulge his key knowledge;
this knowledge, gleaned over 30+ years, was what made him a
world-expert in corrosion and thus gave him his standing, so I
had to treat it with utmost respect. Important social aspect.
» However, I was able and expected to question it. He liked this,
because it stimulated him and showed him gaps in his knowledge
- a true expert values finding gaps in his knowledge, so he can
fill them. The process of knowledge elicitation helps. Important
analytic aspect.
» Knowledge elicitation was based on seeking 'understanding'
underneath the experience. Important analytic and formative
aspect.
H: I had little role in this.
- SYSLAG: Little role, except to help expert (same as in SCCES) in
his own self-elicitation of knowledge and in how to use Savoir.
- Wheat Counsellor: T: Savoir for the ES. FORTRAN for the
interface. Used similar knowledge engineering strategy to SCCES.
32
But had to carefully manage asking the agronomists about low-input
farming options because they were not used to thinking that way
(pistic aspect).
H: -
- Business Strategy: Little role in this. Helped them explore
PROLOG language, and came to dislike it!
- Elsie: T: Key role.
» Savoir KBS toolkit - by now quite experienced.
» Pascal routines written - importance of 'elegance' in
programming or 'literate' programming, and appropriateness.
» Knowledge elicitation strategy as above, with 6 experts; testing
with another 6.
» Several demo systems, to keep users, experts on board.
» But also I realised early that there were two approaches among
the experts: speculative private developers and local authorities,
the latter had to 'make do' with poor ground and hence had
different expertise in e.g. foundations. Useful to have the two
extremes.
» Proactively designed for generality and flexibility. And to allow
users to override reasoning.
» Discovered how to use Savoir to max.
» Excellent comments in KBs and programs.
H:
» Integration of modules
» Extra module of the costs database
» User manuals
» Links with anticipating use.
- INCA: T:
» Programmed the KR toolkit Istar, which was used by knowledge
engineer to build the ES
» Used assembler and C.
» Key guiding principles:
» appropriateness of aspects of knowledge, so that a wide
range of knowledge types were directly available in intuitive
form
» Proximal UI, so KE's attention would not be interrupted by
UI as he was thinking about the knowledge
H: User manual and tutorial for Istar
9.5 Multi-Aspectual Content
- CLINICS: Mainly bio, psych, social
- SCCES: Mainly physical with some biotic
- SYSLAG: Mainly physical and formative, but with one notable
social
- Wheat Counsellor: Mainly biotic, economic
- Business Strategy: Mainly economic, pistic
33
- Elsie: Quantitative, spatial, kinematic, physical, biotic, psych,
analytic, formative, social, economic, aesthetic, juridical, but little
lingual, ethical, pistic
- INCA: Lingual, juridical, economic, ethical, pistic
34
10. ASPECTUAL ANALYSIS AND EXPRESSING
ASPECTS
This looks at types of aspectual analysis and ways of expressing the
results. There are several things we might wish to do:
» to understand something, in a rich, multi-aspectual way
» to critique something, showing what is good and not so good
» to make suggestions to improve something.
The 'something' might be a concrete situation or thing, or it might be
a general thing such as a set of guidelines or a theory. To do these,
there are several types of things we can express in terms of aspects.
» what is happening in each aspect in something
» benefits and detriment, good and evil
» the different kinds of attention we give to each aspect
» to ensure that all aspects are covered (checklist)
» to highlight a missing aspect
» to highlight aspects that are receiving too much attention
» to stimulate discussion about balance or imbalance in attention to
aspects
10.1 Aspectual Analysis
Analyse the thing, examining every aspect of it. Use the aspects to
guide your thinking about it. Analysis can proceed in three ways:
1. Go through each aspect in turn, from quantitative to pistic,
asking in what ways the thing expresses this aspect.
2. Go through each aspect in turn, in the reverse direction,
from pistic to quantitative, asking in what ways the thing
expresses this aspect.
3. Begin with the most obvious aspects, then proceed to ones
that these remind you of, and finally ask about any aspects
not yet covered.
However, in practice, one tends to cycle round and come back to
others. And even for 1 and 2 you might begin not with the terminal
aspects, but one of those near them, e.g. instead of the pistic, you
might begin with juridical or ethical.
Which to use, and when?
» 3 is probably the most useful. It is the best one to use when
interviewing others, since it begins where they are rather than
with an 'aspectual task'.
» 1 and 2 can be useful when you are observing as onlooker.
» 1 can be useful to give others, or even yourself, practice at
thinking about aspects, because it begins with 'easy' and
'simpler' aspects and proceeds to the richer ones. Also, since the
quantitative, spatial and kinematic aspects of something are
unlikely to be particularly important without reference to other
aspects, mistakes made in them do not matter much, so they are
the good ones to practice on and get yourself or others used to
thinking aspectually.
35
» But, if you are well-versed in aspectual analysis, 2 is better than
1 since it begins with the most meaningful aspects.
However, I think the most useful types of analysis I undertake
are not so structured as those. Rather, I find myself sensitive to
forgotten or non-obvious or overlooked aspects. For example, the
child's playground at Castle Park, Frodsham has a small wooded area
one side. Suppose we were to ask mothers why they like the
playground. They would probably mention safety, and the range of
equipment available. They might also say something general about
'nice surroundings'. But they probably would not mention the
wooded area s such. But my intuition tells me that the biotic aspect
of the trees is more important than we might expect. This would lead
me to ask a specific question to expose this aspect, such as "Suppose
that instead of trees there was a concrete wall; would you still come
so often?" A leading question, perhaps, but one designed to uncover
a specific aspect. I would not ask about the aspect as such, and might
not even think about it as an aspect, but I would simply be aware of
things that exhibited the overlooked aspect and ask about them.
10.2 Understanding
To understand a thing or situation aspectually, collect statements
about each aspect of the thing, and then look at the whole picture.
There are various ways of doing this.
10.2.1 Analysis of texts
This might involve an analysis of text. For example, Mitev [2001]
discussed the failure that was the early SNCF (the French national
railways) Socrate rail ticketing system:
"Technical malfunctions, political pressure, poor management, unions
and user resistance led to an inadequate and to some extent chaotic
implementation. Staff training was inadequate and did not prepare
salespeople to face tariff inconsistencies and ticketing problems. The
user interface was designed using the airlines logic and was not user-
friendly. The new ticket proved unacceptable to customers. Public
relations failed to prepare the public to such a dramatic change. The
inadequate database information on timetable and routes of trains,
inaccurate fare information, and unavailability of ticket exchange
capabilities caused major problems for the SNCF sales force and
customers alike. Impossible reservations on some trains, inappropriate
prices and wrong train connections led to large queues of irate
customers in all major stations. Booked tickets were for non-existent
trains whilst other trains ran empty, railway unions went on strike, and
passengers' associations sued SNCF."
Each phrase seems to be of a certain aspect, e.g. "sued SNCF" is
juridical. If we collect these, then we can distribute phrases among
the aspects as follows:
Table 1. Aspects of Socrate Use
36
A variant on this is to collect quotations from a variety of sources.
Analysis of texts might be what you are doing in your group
assignment.
BEWARE In aspectual analysis of texts it is not sufficient to just
operate lexically, i.e. letting a word trigger an aspect. Must think
semantically about how the word is used. Here are some examples of
errors found:
» 'play a role' was seen as aesthetic because of 'play'; it is not; it is
either social (if a social role) or formative (if to do with purpose
of something)
» 'relationship' was seen as social. It is only social if it refers to a
social relationship between human beings, e.g. a friendship. But
a relationship in data structures or between things (e.g. causality)
is not social, but is of another aspect. The word 'relationship'
often refers to other types of relationship, such as biological,
structural, historical; check whether 'relationship' really is social
or not.
» 'response' was seen as psychic. It is not necessarily psychic.
For example there can be a formative response or a social
response. Determine which kind of response it is.
» 'rules' was seen as juridical. But they might be social rules, or
rules in programs like 'if then'. Determine what kind of rules
they are. They are juridical only when the emphasis is on
ensuring due.
» 'extension' (spatial aspect) is sometimes mistakenly applied to
project deadlines and costs continuously extending - that is not
spatial but economic!
37
{*** Group Assignment might involve aspectual analysis of
passages from ISD books or papers. The following note is
important. ***}
Note, however, that analysing such sentences is not just a
straightforward translation of phrases into aspects. There are
sometimes four aspects involved:
» Original aspectual meaning of word. e.g. Growth refers to biotic
activity in living things.
» Analogical aspectual meaning. Each word or phrase might be
used with its original aspectual meaning or with analogical
meaning. For example 'growth' in its original sense is a biotic
activity of plants and living things; it is used analogically of
companies and organisations. This often confuses the analyst.
» Deduced aspectual meaning. There are aspects found in the
words, but also aspects that can be deduced from the sentence.
For example, from "booked tickets" we can deduce there was
some lingual activity of communication, but it is not the main
aspect.
» Illocutionary intention. This is the aspectual reason why the
sentence is written or spoken. Ask "Why are they telling me
this? What are they trying to achieve?" Often idioms have very
different illocutionary intention from the meaning of their words.
For example "Were you born in a tunnel?" is trying to achieve
"Please shut the door."
So, in fully analysing passages, seek to find if all four are there and
make clear which is which. Often this can be determined by looking
at the context before and after the passage.
10.2.2 Direct Analysis
An alternative to this is to analyse something directly, rather than
using texts. Maybe by observation or by interviewing. This too can
provide a number of facts about the thing in each aspect. For
example, an analysis of the Elsie expert system yielded:
Table 2. Aspects of Elsie
38
Such tables express the multi-aspectual functioning that is the thing.
10.2.3 Interwoven Multi-aspectual Functionings
But such aspectual analyses can be taken further. In the case of Elsie,
we might feel that some of the statements in each aspect are somehow
different from others. With a bit of reflection, we might separate
them out as follows. What this expresses is that there are several
multi-aspectual functionings intertwined (in this case HCI, ERC,
HLC: human-computer interaction, engagement with represented
content, human living with computers):
Table 3. Aspects of HCI, ERC and HLC in Elsie
39
10.2.4 Multi-aspectual Knowledge Elicitation (MAKE)
A rather different method, developed by Mike Winfield, involves
looking at concepts that are meaningful in various aspects and linking
them together. This can yield an aspect map such as follows:
40
Figure 1. Aspect map generated in Multi-Aspectual Knowledge Elicitation
The steps of the MAKE process may be seen as:
1. Introduction (e.g. explanation of kernel meanings of aspects,
and obtain statement of requirements)
2. Identify a few (e.g. a couple) important aspects.
3. Focus on one of these aspects and specify any laws, axioms,
data, definitions, and constraints that apply to the domain.
4. Identify as many concepts as possible that lie in this aspect.
(Note: May need to check the concepts at a later stage to
ensure they fall within the correct aspect.)
5. Apply Low Level Abstraction to each concept, which needs,
or is thought to need exploding.
6. Repeat steps 3-6 as necessary.
7. Use the aspectual template to identify any new aspects,
which may apply to the concepts specified (build bridges
between concepts and aspects), and return to step 3.
Low Level Abstraction was a concept that Winfield developed from
the 1991 edition of Clouser [2005] and refers to becoming aware of
the various aspectual properties of things yet without isolating them
from the things themselves.
10.3. Using the Aspects to Critique Something
So far we have sought to understand a thing. But to critique a thing,
41
we need to go further, and interpret it relative to some normative
standard.
» Informal or unstructured critique, such as when involved in a
discussion, and aware that certain aspects are being over-
emphasised while others are ignored.
» Structured critique, such as when contracted to provide
consultancy advice or write a report, or when undertaking
research.
10.3.1 Unstructured critique.
Keep a mental note of which aspects the discussion covers. Be aware
of which aspects are often overlooked, such as the latest aspects
(some of aesthetic to pistic). Be aware of which aspects are often
over-emphasised in western culture (economic, formative and
analytic) or in anti-western culture (biotic, psychic, social).
How to present this? Can gently suggest which aspects are over-
or under-emphasised, usually in terms of something meaningful in
those aspects rather than naming the aspect itself. Often by means of
a question, e.g. "Are we overlooking issues of justice here?"
10.3.2 Structured critique - Aspectual Balance.
Interpretation involves applying a normative standard. The aspects
provide two normative standards:
» balance: all the aspects should be given due consideration, none
over- or under-emphasised
» laws: each aspect is itself normative, defining what is good and
what is bad.
Very often, if we ignore an aspect, then we also transgress its laws,
so the two are intertwined.
Look at the lists of things in each aspect found during our
analysis. Is there a lot more in some aspects than in others? For
example, an analysis of Alexander's 'design patterns' shows:
Table 4. Aspectual spread of Alexander's patterns
42
Each number is a pattern that guides architects in designing a
building, and three main things are considered: construction of the
building, the building as something in which human life takes place,
and the town in which it is situated. Balance can be considered in
three parts:
» Notice the long lists against the physical and aesthetic aspects in
the Construction column, indicating that perhaps architects might
give too much emphasis to these matters. Then the social,
sensitive (psychic) and aesthetic aspects are emphasised when
Alexander considers buildings.
» Now look for aspects which are missing or with very short lists.
For example, ethical has a short or null list in all three columns.
And, surprisingly, lingual is also under-represented.
» Now ask: it is reasonable for these aspects to be under- or over-
represented? For example, we might expect that when
considering construction of a building the physical and formative
aspects would deserve more consideration. We find the physical
has a long list, but instead of the formative we have a long
aesthetic list. That architects tend to be over-concerned with
aesthetics explains the long aesthetic list, but why is Alexander so
43
little concerned with formative activity? Think: is it reasonable
for the lingual aspect to be so under-represented in all three
columns?
In this case we have analysed a set of guidelines, and then it is
usually best simply to look at aspectual balance. But when analysing
concrete situations, we can take aspectual norms into account.
10.3.3 Structured Critique - Aspectual Norms
Taking the normativity into account, and differentiating good from
bad, is often more useful when analysing concrete situations rather
than guidelines. Each aspect has norms. For example, according to
the juridical aspect, justice is good, injustice is bad. The norms of
the aspects are summarised in the following table.
Table 5. Dysfunction or evil in each aspect
An analysis of aspectual normativity of a situation would look at
the ways in which the situation exhibits either good or bad in each
aspect. Note that this helps us cope with things that exhibit both good
an bad characteristics, such as something that is beautiful and yet
unjust, or just and yet ugly.
A useful visual device that helps in such normative analysis is
known as the aspectual fir tree, in which the amount of positive and
negative functioning in each aspect is shown by the length of two
bars, negative to left, positive to right:
44
Figure 2. Fir tree of aspectual repercussions
This (totally fictitious tree) could represent the use of a
geographic information system. It shows major benefits in the spatial
aspect (obviously!), the analytical (helping us clarify where we are)
and the lingual (e.g. helping us communicate our position). But there
might be dis-benefits in the ethical aspect (e.g. making the user
selfish), pistic (e.g. user tends to focus too much on location and this
reduces their loyalty to others), the juridical (... and they overlook
the rights of others). Notice how in some aspects there are both
benefits and dis-benefits.
But, as a pseudo-numerical device, the aspect tree can give an
over-simplified picture if we are not careful. The following
guidelines should be noted:
» Never take the length of a bar as some kind of absolute value of
aspectual functioning, and never compare two bars of similar
length to conclude that functioning in one aspect is 'better' than
in another.
» But look at the overall patterns and groups. Often, as in Fig. 4-
3, the main positive functioning or benefit lies in the earlier
aspects, while the main negative functioning lies in the later ones.
This should give cause for concern because the impact in the
earlier aspects is likely to be more visible and to accrue in the
short-term while the detrimental impact in the later aspects might
become manifest only over the long term. This gives a false
impression of the 'success' of a computer project if evaluation is
undertaken too soon.
» Then look at the longer bars. Do they truly indicate major
repercussions or functionings, or do they indicate undue attention
to these aspects during analysis? Make a specific study of these
aspects, to determine which it is.
45
» Look likewise at the short or zero bars. Were these aspects
overlooked during analysis? Make a specific study to check, then
redraw the tree.
» Remember that everybody's understanding of the aspects is
variable -- by interviewees, authors and analysts -- even though
we all begin from an intuitive grasp of their meaning . So, any
further analysis undertaken should include appropriate checks.
In this way, the aspect tree device is not an end in itself so much as a
stimulant to focus further analysis, which could be carried out using
Winfield's MAKE method, described below.
It can sometimes be useful to separate out aspectual functioning
from aspectual repercussions, in two such fir trees side by side. For
example, for Mitev's description of the Socrate failure, we can make
a simple count of the number of times each aspect is referred to (as
expressed by the phrases in the quoted text), either as a functioning or
as a repercussion. We obtain the chart illustrated in Figure 4-4.
Figure 3. Aspectual view of Socrate failure
Even though only a single paragraph has been analysed -- and so
this picture will be grossly misleading -- several things become clear:
that this failure involved negative functioning in many aspects, not
just the technical (formative), that the aspects in which the significant
negative repercussions occur might not be those in which the negative
functioning occurs, and that the most serious repercussions (that
Mitev was interested in) were in the juridical aspect. That Mitev was
not aware of Dooyeweerd's aspects, but merely adopted a lifeworld
stance, is testimony to the power of this approach.
The aspect tree device may be used for both retrospective
analysis, as here, or prospective analysis, during design or prediction.
It may be a single tree, showing either functioning or repercussions or
46
both together, as in Fig. 4-3, or one in which functioning and
repercussions are separated, as in Fig. 4-4.
10.4 Making Proposals for Improvement
This follows critique. If we know what is wrong, then we can make
suggestions for how to correct that - without sacrificing that which is
already OK. We can make aspectual suggestions based either on
balance or on aspectual normativity.
If we detect imbalance, i.e. an ignored aspect, then the obvious
thing is to draw attention to that aspect, and make proposals for
giving it due consideration. There are at least three kinds of
suggestion we can make (with an example relating to the ethical
aspect):
» We can suggest the aspect as such, e.g. "Are we overlooking the
ethical aspect here?"
» We can suggest a property or functioning in the aspect, e.g.
"Will this lead to greater selfishness among users, or greater
generosity?"
» We can suggest things, e.g. "Would it be useful to create
guidelines that applaud generosity, and structures which reward
it?"
which is appropriate depends on the situation.
10.5 Example: Guidelines for User Interface
(Extract from 'Philosophical Frameworks for Understanding
Information Systems', Basden [2008], IGI Global.)
All aspects have normativity (even the deterministic ones). This
normativity offers a basis for establishing sound practical guidelines
for developing or evaluating UIs or whole computer systems. The
shalom principle of simultaneous realization of norms emphasises the
importance of attending to each aspect. While it is appropriate on
occasion to focus attention on one aspect (usually the qualifying) we
should always do so in a way that gives all the other aspects their due.
If we over-emphasise an aspect, and in the extreme absolutize it, we
begin to ignore other aspects, and the result is that the success or
fruitfulness of our activity is jeopardised. Thus, for example, a web
page that has superb graphics but is otherwise devoid of useful
content it will fall into disuse.
Web pages are user interfaces, and we can see the normativity of
many of the aspects recognised in the more mature published web
design guidelines. Table 6 shows the 'Research-Based Web Design
and Usability Guidelines' of the National Cancer Institute [2005] and
the main aspects of each guideline (aspects indicated by the first letter
of their name, from Q = Quantitative to P = Pistic). Many have two
aspects, sometimes because they cover two things (e.g. "set goals"
(formative) and "state goals" (lingual)) and sometimes because the
main idea is of two aspects (e.g. sharing is both lingual and ethical).
We do not differentiate between qualifying and founding aspects here,
but could do if a more precise analysis were needed.
47
Table 6. Aspects of Web Design Guidelines
We can use aspectual analysis as a basis for critique. The first
thing that strikes us is how many aspects are represented here. This
is, of course, what one would expect from a good, mature set of
guidelines such as the NCI guidelines are. Second, we might look for
imbalance among the aspects. The spatial and formative aspects
appear more often than most other aspects; we can ask ourselves
whether this is appropriate. Perhaps more significant are some gaps,
at least in this 2005 version, some of which are quite surprising:
» The pistic aspect of vision of who we are is completely absent,
yet one might expect some mention of the designers' vision for
the website. (It is possible that "Set goals" implies some pistic
vision for the site.)
» The ethical aspect of self-giving is present only in sharing design
ideas. Guidelines on how to give the reader more than is actually
due to them, and thus create a site that feels generous, would be
useful.
» The juridical aspect is almost absent, only represented
tangentially in the concept of providing 'useful' content. The
juridical aspect would be relevant in terms of giving both the
topic and the readers their due.
» Perhaps most surprising is the almost complete absence of the
social aspect -- the two inclusions are rather tangential. Since
48
websites are read by people from any and every cultural group,
with varying background knowledge, expectations and world
views, we might expect a whole set of guidelines on appropriate
use of cultural connotations, humour, idiom, and on respecting
cultural sensitivities.
» The kinematic aspect is almost entirely absent. Animation can be
used to show movement, but have the designers of these
guidelines overlooked this, treating animation as a mere sensitive
or aesthetic decoration?
This aspectual analysis of these guidelines is not meant primarily
as a criticism of the guidelines, which are excellent when compared
with many others that are available, but rather to show how aspectual
analysis can be useful as an evaluation tool, and how it might be used
to suggest future improvements.
All diagrams and tables copyright (c) Andrew Basden, 2007.
49
REFERENCES USED IN TEXT
Basden A. (2008) Philosophical Frameworks for Understanding
Information Systems. IGI Global Hershey, PA, USA. www.igi-
global.com). ISBN: 978-1-59904-036-3.
Boehm BW, (1988), "A Spiral Model of Software Development and
Enhancement", IEEE Computer, May 1988, pp.61-72.
Bunge M. [1979] Treatise on Basic Philosophy. Volume 4.
Ontology II: A World of Systems. Reidel, Dordrecht,
Netherlands.
Clouser R, (1991, 2005 2nd ed.), The Myth of Religious
Neutrality; An Essay on the Hidden Role of Religious Belief in
Theories, University of Notre Dame Press, Notre Dame,
Indiana, USA.
Dooyeweerd, H. (1984/1955). A new critique of theoretical thought
(Vols. 1-4). Jordan Station, Ontario, Canada: Paideia Press. (Original
work published 1953-1958)
Hartmann N (1952) The New Ways of Ontology Chicago
University Press.
Hirschhein R, Klein HK, Lyytinen K (1995). Information
Systems Development and Data Modelling: Conceptual and
Philosophical Foundations. Cambridge University Press.
Kautz E, K., Madsen, S., Nørberg, J. (2007). Persistent problems
and practices in information systems development. Information
Systems Journal, 17, 217-39.
Maslow, A. (1943). A theory of human motivation.
Psychological Review, 50, 370-396.
Mitev N N (2001) "The social construction of IS failure: symmetry,
the sociology of translation and politics" pp.17-34 in Adam A,
Howcroft D, Richardson H, Robinson B (eds) (Re-)Defining
Critical Research in Information Systems, University of
Salford, Salford, UK.
National Cancer Institute. (2005). Evidence-based guidelines on web
design and usability issues. Retrieved October 19, 2005, from
http://usability.gov/guidelines/
Newell A. (1982) "The knowledge level" Artificial
Intelligence 18:87-127.
Royce W W, (1970) "Managing the development of large software
systems: concepts and techniques", p.328-339 inProc. IEEE,
Wescon.
50
SOME LITERATURE: BOOKS AND PAPERS
The key reference work underpinning this module is
Basden, A. (2008) Philosophical Frameworks for Understanding
Information Systems, Herschey, PA, USA: IGI Global.
This book provides a broad understanding of information systems
as a whole - their use, development, nature and impact on
society. Chapter 6 is especially important in this module.
The remaining literature is typical of material which the student
should read and study, and is supplied merely as suggestions. The
student should be selective in what they read, and should supplement
this with other material of their own choosing.
Literature on Overall ISD Project
Basden A, Watson I D, Brandon P S, (1995), Client Centred:
an approach to developing knowledge based systems, Council
for the Central Laboratory of the Research Councils, U.K.
Floyd C, (1986), "A comparative evaluation of system development
methods", pp.19-54 in Olle T W, Sol H G, Verrijn-Stuart A A (eds),
Information System Design Methodologies: Improving the
Practice, Elsevier, North-Holland. :: need for Theory of
Application.
Johnson P, Johnson H, Wilson S, (1995), "Rapid prototyping of user
interfaces driven by task models", pp.209-245 in Carroll J M (ed.)
Scenario-Based Design; Envisioning Work and Technology in
System Development, Wiley. :: good quote re IS being
people+IT
Kumar K, Bjørn-Andersen N (1990) A cross-cultural comparison of
IS designer values. Comm ACM, 38(5):528-
38. ::p
Noyes J M, Starr A F, (1995), "Working with users in system
development: some methodological considerations", in
Integrating HCI in the Life Cycle: Colloq. BCS HCI
Group, 11 April 1995.
Literature on Anticipating Use
Basden A, Watson I D, Brandon P S, (1995), Client Centred:
an approach to developing knowledge based systems, Council
for the Central Laboratory of the Research Councils, U.K.
BSI (1992) "A framework for user requirements for Information
Technology", British Standards Institution, IST/21:3590.
Basden A, Wood-Harper AT (2006) "A philosophical discussion of
the Root Definition in Soft Systems Thinking: An enrichment of
CATWOE" Sys. Res. and Behavioral Sci.,
23:61-87.
51
Checkland P, (1981), Systems Thinking, Systems Practice,
Wiley, New York.
Mingers J. 1984. Subjectivism and Soft Systems Methodology - A
Critique. Journal of Applied Systems Analysis 11:85-103.
Probert, S.K. (1997) The metaphysical assumptions of the (main) soft
systems methodology advocates in Winder, R.L., Probert, S.K.,
Beeson, I.A. Philosophical Aspects of Information
Systems, Taylor and Francis.
Schregenberger J. 1982. The Development of Lancaster Soft Systems
Methodology: A Review and some Personal Remarks from a
Sympathetic Critic. J. Applied Systems Analysis
9:87-98.
Winograd T, (1995), "From programming environments to
environments for designing", Comm. ACM., v.38, n.6, pp.65-74.
Literature on Creating the IS / Programming
Knuth DE (1984). Literate Programming. The Computer
Jnl 27(2):97-111.
Pieterse V, Kourie DG, Boake A (2004). A case for contemporary
Literate Programming. Proc. SAICSIT, South African Institute
for Computer Science and Information Technology, p.2-9. ::
good review of different approaches to programming as human
activity.
Mantei M, (1981), "The effect of programming team structures on
programming tasks", Comm. ACM., v.24, n.3, pp.106-113.
Marques D, Dallemagne G, Klinker G, McDermott J, Tung D,
(1992), "Easy programming", IEEE Expert, June '92,
pp.16-29.
Weinberg Gerald M. (1999). "Egoless Programming," IEEE
Software 16(1):118-120.
Literature on Knowledge Elicitation and IS Content
Basden A, Watson I D, Brandon P S, (1995), Client Centred:
an approach to developing knowledge based systems, Council
for the Central Laboratory of the Research Councils, U.K. - some
chapters
Cooke N J, (1994), "Varieties of knowledge elicitation techniques",
Int. J. Human-Computer Studies, v.41, pp.801-849. :: KgAcq,
B+A,
Dieng R, Corby O, Lapalut S, (1995) "Acquisition and exploitation
of gradual knowledge" International Journal of Human-
Computer Studies 42(5):465-499.
52
Gaines B R, (1987), "An overview of knowledge acquisition and
transfer", Int. J. Man-Machine Studies, v.26, No.4, pp.453-472.
Hart A, (1986), "Knowledge acquisition for expert systems", Kogan
Page, London.
Kidd A L, (1987), "Knowledge Acquisition for Expert Systems: A
Practical Handbook", Plenum Press, New York.
Klinker G, Genetet S, McDermott J, (1988), "Knowledge acquisition
for evaluation systems", IJMMS, v.29, No.6, p.715.
Lefkowitz L S, Lesser V R, (1988), "Knowledge acquisition as
knowledge assimilation", IJMMS, v.29, No.2, p.215.
Lightfoot J M (1999) "Expert knowledge acquisition and the
unwilling expert: a knowledge engineering perspective" Expert
Systems 16(3):141-7. :: mv, rtf, social relshp
Ngwenyama O K, Klein H K, (1994), "An exploration of expertise of
knowledge workers: towards a definition of the universe of discourse
for knowledge acquisition", Info. Systems J., v.4, pp.129-140. :::
ABM, U+E, tacit, knowledge acquisition. Good.
Schweickert R, Burton A M, Taylor N K, Corlett E N, Shadbolt N
R, Hedgecock A P, (1987), "Comparing knowledge elicitation
techniques: a case study", Artificial Intelligence Review,
v.1, pp.245-53.
Shadbolt N, Burton M, (1989), "Knowledge elicitation", in Wilson J,
Corlett N, (eds.), Evaluation of Human Work: Practical
Ergonomics Methodology, Taylor Francis.
Shaw M L G, Gaines B R, (1987), "Techniques for knowledge
acquisition and transfer", Int. J. Man-Machine Studies, v.26, No.3,
pp.251-280.
Winfield M J, Basden A, Cresswell I, (1996), "Knowledge elicitation
using a multi-modal approach", World Futures, V.47,
pp.93 - 101.
Witten I H, MacDonald B A, (1988), "Using concept learning for
knowledge acquisition", IJMMS, v.29, No.2, p. 171.
53
GLOSSARY AND ABBREVIATIONS
This glossary is based on Basden [2008], with some extra entries.
Key found at end of each entry:
{D} In Dooyeweerdian thought
{E} In everyday use
{IS} In information systems and related disciplines
{P} In philosophy
{number} Optional chapter number, or part of chapter.
Amiga: An innovative multi-tasking, multi-media computer platform of the
1990s, which was particularly suited to home and games use; the platform
used by this author. {IS}
ANT: Actor Network Theory {IS}
Anticipation: An aspect refers forward to a later one. {D3}
Antinomy: A deep inconsistency or incoherency that cannot be overcome by
logic. {D2}
Archimedean point: a hypothetical vantage point from which an observer
can objectively perceive the subject of inquiry, with a view of totality.
(From Wikipedia article of the same name). {D}
Aspect: 1. {D} Synonymous with 'sphere of meaning-and-law'; this is a
central concept in Dooyeweerd's thought {§3.1} 2. {E} A general kind of
property that is to be distinguished from others.
Aspectual law: Cosmic law (q.v.) that enables and guides the functioning of
the whole cosmos. {D3}
Assumption: A belief that makes a proposition true or false (as opposed to
meaningful; see Presupposition). {P}
CATWOE: A simple checklist to help with problem solving as part of Soft
Systems Methodology; see §6.8. {IS6}
CCA: Client Centred Approach to ISD. {IS6}
CFR: Creation, Fall and Redemption ground-motive {D2}
Conflate: merge together; combine two into one in a way that is probably
inappropriate. {E}
Cosmic law: The transcending law-framework that enables the cosmos to be
and occur, but which can never be fully known. {D2}
Cosmic meaning: The transcending framework of spheres of meaning which
stamps the entire cosmos as Meaning. {D2}
Cosmic time: Dooyeweerd's notion of Time. {D}
Cosmonomic philosophy: A name for Dooyeweerd's positive philosophy.
{D2}
CR: Critical Realism. {P}
CST: Critical Systems Thinking. {IS6}
Dialectic: The opposing of one central idea to another in a way that is
deeper than logic and involves deep commitments; thought tends to swing
from one pole to the other. {P,D2}
DST: Disclosive Systems Thinking {IS6}
EISD: Emancipatory information systems design/development. {IS6}
Enkapsis: A relationship in which two 'wholes' are joined in a structural
relationship in which both are necessary. {§3.2.6.2}
Entity side: See Subject side {D}
ERC: Engagement with represented content {IS4}
Everyday attitude: An attitude of thinking or reflecting that is open to the
richness of everyday experience. (= 'lifeworld attitude', 'naïve attitude').
Contrasted with theoretical attitude. {P}
54
Everyday experience: Human experience of life in all its richness.
Contrasted with theoretical observation and analysis of a narrow focus. {P}
Extant: Existing, used of current thinking or ideas or discourse; still
relevant and applicable. {E}
FFU: Framework for understanding.
FMGM: Form-Matter ground-motive {D2}
Foundational dependency: Each aspect (q.v.) depends on earlier ones for its
positivisation (q.v.); example: social functioning cannot occur without
lingual functioning. {D3}
FPB: Fixed point binary number {IS7}
Functioning (in an aspect): Response to aspectual law (q.v.). Example: in
reading this you are functioning in the lingual aspect of understanding
symbols, and also the psychic aspect of vision. Can be either object- or
subject-functioning (q.v.). {D3}
Gegenstand: 1. {P} In immanence-philosophy, that which is valid and
objective in our experience. 2. {D3} Relationship in which we 'stand over
against' an object of our thought or action, rather than engage intimately
with it; in contrast to (1), this reduces validity.
GIS: Geographic information systems {IS}
Ground-motive: Deep presupposition about the nature of reality; it is a
"moving power or spirit at the very roots of man, who so captured works it
out with fear and trembling, and curiosity". {D2}
HCI: Human-computer interaction {IS4}
HLC: Human living with computers {IS4}
HST: Hard systems thinking {IS6}
HUC: Human use of computers, an area of research and practice. {IS4}
ICT: Information and communication technology.
Immanence-standpoint: A deep presupposition that the fundamental
Principle of all temporal reality that is may be found within temporal reality
itself. It usually leads to reductionism. Example; materialism. Clouser
[2005] explains it well. {D2}
Immanence-philosophy: Philosophy based on the immanence-standpoint
(q.v.) {D2}
Immanent critique: Criticism of a position or stream of thought in terms of
what it itself finds meaningful and important and seeks to achieve, usually
to expose presuppositions it makes to show they are contradictory. Used
especially by Habermas and Dooyeweerd. {P}
Internal structural principle: The internal structural principle is a cosmic
law which governs how a thing of a given type responds to the various
aspects; also called 'type law'. {D3}
IS: Information systems.
ISD: Information systems development: an area of research and practice.
{IS6}
IT: Information technology.
ITE: Information technology as ecology: an area of research and practice.
{IS8}
ITR: Information technology resources: an area of research and practice.
{IS7}
KIISD: Key Issues in Information Systems Development (the name of this
module) {IS}
KBS: Knowledge based systems (IS)
KM: Knowledge management. {IS}
Knowledge elicitation: Coming to distinguish and know what is relevant in
a domain of application for encapsulation in or as a computer system. {IS6}
Knowledge representation: Representing or expressing what is relevant in a
domain in a computer language. {IS6,7}
55
KR: knowledge representation.
KR formalism: A general kind of KR language; it embodies a theory or idea
of how knowledge can be represented. {IS7}
KR language: a formal language that is used to program computers; it can
be graphical as well as textual (for example box-and-arrows diagrammers).
{IS7,6}
Law: 1. {D} Aspectual law 2. {E} Legal requirement.
Law side: The law side comprises the framework within which all can exist
or happen. {D2}
Law-promise: = Law, emphasising repercussions. {D}
Lifeworld (= Life-world): The 'world' of everyday life as distinct from the
scientific 'worlds' of e.g. physics, psychology, social science. Synonym for
'everyday', 'naïve' and 'pre-theoretical'. {P1,3}
LOFFU: Lifeworld-oriented framework for understanding. {1}
LWV: Life-and-world-view.
Meaning: To Dooyeweerd, this is almost a synonym for reality: all created
reality *is* meaning; Meaning has the character of referring beyond. Four
uses of 'meaning'. {D2}
Meaning-and-law: The law side: the cosmic framework that enables the
Cosmos to be and occur. {D2}
Meaningful-functioning: Functioning in an aspect as either subject or object.
{D}
MMORPG: Massively-multiplayer online role-playing games: computer
game played over the Internet. {IS}
MST: Multimodal Systems Thinking {IS6}
MUDs: Multi-User Dungeon computer game played over Internet. {IS}
Naive: Simple (with negative connotation); contrast with 'naïve).
Naïve: An adjective used for experience or attitude; A synonym for
everyday, pre-theoretical, lifeworld; It does not have a negative connotation
(contrast 'naive'). {P}
NCI: National Cancer Institute.
NFGM: Nature-Freedom ground-motive. {D2}
NGGM: Nature-Grace ground-motive. {D2}
NoC: Nature of computers: an area of research and practice. {IS5}
Normativity: The branch of philosophy concerned with good and evil; also
the right versus wrong of a situation or thing. {P}
Noumenon: Something whose existence can be reasoned but not perceived.
{P}
Object: (multiple meanings) 1.: Thing 2. {D} Something affected or created
by something else's subject-functioning 3. {IS6,7} Representation of domain
meaning.
Object-oriented: An approach to programming {IS7}
Object-functioning: When something functions in an aspect as part of
something else's subject-functioning. {D2,3}
Ontic: Of, relating to, or having real being or existence. {P}
Ontology: 1. {P} A branch of philosophy concerned with studying ontic
issues 2. {IS7} (usually 'KR ontology') a statement in a KR language about
such ontic issues in a domain of meaning.
OO: Object-oriented.
Outwith: A Scottish word meaning the opposite of 'within', similar in
meaning to 'outside' but without the spatial connotations; usually used of a
conceptual field; e.g. "This problem is outwith my remit".
Phenomenon: anything perceived by the senses or how we are conscious of
something as distinct from the nature of the thing itself. {P}
Pistic: (Greek, 'pistis': faith) Usual name of fifteenth aspect in
Dooyeweerd's suite. {D3}
56
Positivisation: Law is positivised when some subject responds to it in time;
the Cosmos is positivisation of cosmic law. {D}
Presupposition: An assumption that makes a statement or belief meaningful,
rather than true; contrast Assumption (q.v.). {P}
Qualifying aspect: The aspect which expresses the main meaning of a thing
as that type of thing; Example: the qualifying aspect of a pen is the lingual.
{D3}
RDM: Relational Data Model {IS7}
Reduction(ism): The attitude or action of trying to explain one type of
meaning fully in terms of another, usually with connotations that this is
undue. {P}
Religion: "the innate impulse of human selfhood to direct itself toward the
true or toward a pretended absolute Origin of all temporal diversity of
meaning, which it finds focused concentrically in itself." [Dooyeweerd,
1984,I,p.57]. NOT to be confused with particular creeds or religious
practices. {D2}
Religious root: See §2.4.1. {D2}
Repercussion: Result of aspectual functioning. {D3}
Represented content: Meaning of a domain that is represented in a computer
{IS4}
Retrocipation: Referring back to earlier aspects {D3}
S-O: Subject-object relationship
S-S: Subject-subject relationship
SDM: System development method {IS6}
Shalom principle: If we function well in every aspect then things will go
well, but if we function poorly in any aspect, then our success will be
jeopardised. See §3.4.3. {D3}
SMP: Semi-manufactured product. {D}
Sphere of law, or meaning: Aspect (q.v.) {D}
SSM: Soft Systems Methodology {IS6}
SST: Soft systems thinking {IS6}, and Social Shaping of Technology {IS8}
ST: Structuration Theory (Giddens)
Subject: 1. {D} Agent that responds to and is subject to aspectual law 2.
{E} Topic.
Subject side: That which is subject to the law side (q.v.); synonym for the
cosmos as it actually exists and occurs, including the conceptual and social
worlds. The subject side, also called entity side or fact side, comprises all
that exists or occurs in the cosmos, as concrete reality, including concrete
meanings that are ascriptions we make, and includes all our experience,
past, present, future and potential. {D2}
Subject-functioning: When a thing (or person) actively responds to aspectual
law, as agent rather than as object. {D}
Subject-object relationship: See chapter 2 'Escaping Descartes and Kant'.
Dooyeweerd proposed a notion of subject and object which is radically
different from that inherited from Descartes. {P,D}
Transcendent critique (Not to be confused with transcendental critique,
q.v.): Criticising a position from the perspective and value-system of a
completely different position (e.g. criticising Marxism from Capitalist
perspective or vice versa.) Opposite of Immanent critique (q.v.). {P}
Transcendental critique (Not to be confused with transcendent critique,
q.v.): Critical analysis of a position immanently to expose the conditions
that are necessary for it to be possible. {P}
Two-thirds world: A better name for developing world or 'third world'.
{IS8}
Type law: see 'Internal structural principle' (q.v.) {D3}
UI: User interface {IS}
57
VR: Virtual reality {IS}
VSM: Viable Systems Model (Beer) {IS}
Weltanschauung: World-view {P}
World-view: (= World view) Set of assumptions, aspirations, etc. that
shape the way we see, understand and react to things. {P}
19 January 2009, 3 February 2009, 20 February 2009, 13 August 2009, 24
September 2009, 3 February 2010.
58