TRADITIONAL DESIGN METHOD

TRADITIONAL DESIGN METHOD
BY DR. SOLOMON EDIRIVERERE ESOMU
INTRODUCTION
In order to understand and assess a design method it is necessary to have an evaluation
guide or reference frame to compare it with. Consequently, in this paper we are going to
be discussing five criteria which I consider crucial for assessing Traditional Design
Methods (TDM’s) for Information System Design (ISD).
As a case study, I will be assessing the Information System work and Analysis Changes
(ISAC) traditional design method based on these five assessment criteria. I will also
discuss the strengths and weaknesses of this design method, as well as how the evaluation
of the method has changed my initial impression of traditional design methods.
Finally, I will be discussing the ISAC TDM for information system development in the
light of Critical Systems Heuristics (CHS): how ISAC propositions support and
contradict CSH, the shortcoming of ISAC, how to overcome these shortcomings, how my
understanding of TDM has changed as I studied it and how I intend applying CSH in the
future.
CRITERIA FOR ASSESSING TDM FOR INFORMATION SYSTEM DESIGN
The criteria I consider important for the assessment of a TDM are listed as follows:
1. User Involvement
2. Change/Process Analysis and Data Modelling
3. Test-running
4. Post Implementation Review and Maintenance
5. Interconnectivity between Design Stages
1. USER INVOLVEMENT OR PARTICIPATION
In designing an IS, the involvement of the user, which is often known as the expert-user,
cannot be overemphasized. This is because every design method ought to be user- or
client-oriented, as the IS is being created for the users. Getting the users involved will
help the analyst understand the business processes, needs, terms and relationship, which
are normally provided by the users. Not only does this provide the analyst with the
understanding of the business process and its requirements/needs but also from different
perspectives, provided by different users. This helps the analyst to model the business
process up-front of the IS implementation. Without such user participation, the analyst is
not able to create the data model, because the analyst cannot presume to know the user's
business. The analyst is simply recording the knowledge that the user-expert conveys
(Ahmed, 2009).
Some analysts may argue that its not just possible for the users to know, think of
everything or foresee all the needs of an IS from the beginning of the project or, if they
do, their wishes could be unrealistically stated. Stig Holmberg (2009) put it this way:
TDM’s do stress the importance of user involvement, and they do support it very well
(consider strict requirements of documenting user requirements) but only in the
beginning of the project. Newer methods promote user involvement throughout the whole
system development cycle, which is considered much better, from the obvious point that
more communication you have between customer (“problem-maker”, in a way) and

developer (“problem-solver”), it will be easier to find proper solution. To address this
problem, I would recommend that a TDM that does not involve the userS all round the
development life cycle of an IS should go beyond just getting them involved only at the
beginning stage of IS development to as far as through the whole system’s development,
deployment, operation and post-implementation life cycle. The whole design and
development should be participatory and all-involving, as it is in the third generation of
design method, with all stakeholders (users, analysts, designers, implementers, sponsors
etc) making inputs at each of the stages: design, implementation, operation and
evaluation.
Motivation for Choosing Criteria:
The very success or failure of an information system may be measured by the level of
satisfaction of its basic users in the organization.Besides being very important to get the
user involved in the IS development process to enable the analyst/modeller design and
model the business process, defined by the user, it is also very important and much more
beacause, the goal of every IS, in the first place, is to meet and satisfy the needs of its
users. This can only be achieved by finding out what these needs and requirements are
from the users; by having them make their inputs. No one else knows another’s problem
more than the one who has the problem.
2. CHANGE/PROCESS ANALYSIS AND DATA MODELLING
Information System (IS) is the interaction between processes and technology within an
organization or/and across organizational boundaries. Another criterion for assessing a
design method for the development of such an IS is whether that design method gives
room for the business processes analysis and data modeling. The aim of an IS is to solve
a business problem (process)—not just to solve it but in a better way (by use of
technology) than the existing solution does. This necessitates a change analysis: a process
of finding what the existing way of doing things (processes) was and looking for a better
way to get those same things (processes) done. There is need to formulate a problem
before it is solved. In solving the problem identified in the organization or with its
existing solution, a proper process analysis of the organizational activities is done and
documented. The way the IS is going to be developed (and/or the steps) before
embarking on the actual development is also done and documented. This is followed by a
graphical representation of the solution proposed to the problem, which is known as data
modeling - usually done by the analysis/modeller. A Traditional Design Method ought to
have this stage as part of its development life circle because, in the course of this stage,
many ways of solving the business problem as well as models will be arrived at; out of
which the best will be chosen. Fig. 1 shows the steps involved in this stage.
Fig. 1 Change/Process Analysis and Data Modelling
Motivation for Choosing Criteria
The reason I chose this as one of the criteria for assessing a design method is that, for a
quality IS to be developed, there must be an identification and understanding of the
business processes and problems involved in an organization, which the IS is met to
addresss. These processes and problems must be thoroughly analysed and modelled for
Review Existing
Business Process
Solution
Develop Better
Business Process
Solution from
Process Analysis
Model
Business
Process

easy development/impementation of the IS. In project management, there is need to test-
run a project and carry out the necessary tests to ensure they meet the requirements
before moving on to project acceptance and commissioning and, finally, handover to
users and operations personnel, who will use and maintain the system respectively.
Another reason I chose this as a criterion is that, there is need in the design of an IS, to
look out for the poossibility of developing an IS that solves a business problem in a better
way than the existing solution by choosing the best from the various alternatives put
forward.
3. TEST-RUNNING
Testing of proposed Information System is vital in the development life cycle of the
system. Before an IS can be deployed for full operation, there is need for the system to be
test-run to ensure that it meets all the requirements and needs spelt out in the
specification at design stage over a given period of time. This can be gone by feeding the
system with real-world input (data) and ensuring the required output (information) is
churned out. If, at the time of test-run, it is found out that all the requirements and needs
are not met, there is one shortcoming or the other in the IS, and so on, there is need to
improve on (redesign, adjust and add on) the system to ensure it meets the set goals and
objectives. The test-runing should involve the users such that they can make their
observations, comments and suggestions to ensure that the goals and objectives of the IS
are met as closely as possible. This will go a long way in ensuring users get maximum
satisfaction when the IS is eventually swung into full operation. Fig. 2 shows a simple
flowchat depicting the various steps and actions in the test-running stage of an IS over a
period of time.
Fig. 2 Flowchat for Test-Running Information System
Test-run
Information System
START
Does Test-
run meet
requirement
s?
Acceptance,
Commission and Full
Operation/Maintenance
STOP
Fix Problems,
Repair, and Make
Adjustment on
Information System
NO
YES

4. POST IMPLEMENTATION REVIEW AND MAINTENANCE
In business, from time to time, new opportunities come up, organizations diversify, new
business processes come up, new user and customer needs and requirements which were
not initially forseen also come to limelight. This brings about the need for a review of the
current IS, just as it is important to maintain it to ensure any problems (errors and bugs)
that might come up in the course of operation are fixed and that the IS is functioning to
full capacity in meeting the organizational needs. This review is continually and
constantly done to find out whether the operational IS is meeting the new business
processes, needs and requirements of its users and customers in the organization. Any
traditional design method that does not include this into the life cycle of an Information
System is incomplete. This is because, the ultimate aim of an IS is to solve the business
problems of the organization in the best possible way, in order to make the running of the
organization easy for its staff and ensure quality service delivery to its customers; which
eventually will culminate in increased productivity that will, in turn, yield high return on
investment or profitability.
Motivation for Choosing Criteria
There is always the need to review things from time to time, just as humans reflect from
time to time especially at the end of the year and make resolution.The development life
cycle must always involve a stage that focuses on the review of business processess and
problems and finding better ways to solve them.
5. INTERCONNECTIVITY BETWEEN DESIGN STAGES
In carrying out the stages in the development life cycle of an Information System, there
has to be an interconnection between one stage and the following stage in such a way that
the later continues from where the former left off. The SDLC represents a sequence of
stages in which the output of each stage becomes the input for the next. (Centre for
Technology in Government, 2005).
Motivation for Choosing Criteria:
Coherence between design phases is very important in the development of IS. Design of
IS will be easily realized if one phase is directly linked to the other. It gives an idea of
where to start from in the next stage or phase
RESULT OF ASSESSMENT ON AM-ISDM
From the discussion in the foregoing, I will now make a profile curve (Fig. 3) for the
ISAC method, based on the following percentage rating for each criterion or property on
the profile:
1. User Involvement: 30 %
2. Change/Process Assessment: 60 %
3. Test-running: 0 %
4. Post-Implementation Review/Maintenance: 0 %
5. Intercontection of Stages: 10 %

Fig. 3 Profile for ISAC TDM Using Five Assessment Criteria
The rating is a personal one which I arrived at from the study of the ISAC TDM.
INFORMATION SYSTEM WORKS AND ANALYSIS CHANGES (ISAC)
THEORETICAL BASIS
ISAC is a TDM developed in the 1970’s at the ADB department, (in Swedish;
“Administrative databehandling”), Stockholm University/Royal Institute of Technology.
ISAC was later renamed Information System work and Analysis of Changes. By the
ADB Department which was also changed to DSV. ISAC is a systematic user or client
oriented traditional information design method developed by Mats Lundeberg,
G.Goldkuhl and A. Nilsson at University of Stockholm, Sweden in 1979 inspired by the
famous Swedish professor, Börje Langefors.
ISAC worked in what was called “problem oriented systems development” or in
langeforsian terms “infologically oriented systemeering”. The methodology was created
for a much broader coverage of stages in the information systems development life cycle
than the requirements determination stage. ISAC methodology emphasized on user
orientation in its’ early stages of development.
It is a change driven approach made of linear and sequential steps that proceed from
change analysis, activity study, information analysis and culminate with implementation.
The analyst or stakeholders attempt to ask and answer certain questions at each phase that
ends up with the deliverables of that step. The phases are now listed below:
1. Change Analysis
2. Activity Study
3. Information Analysis
4. Implementation
User Involvement
Change/Process
Analysis
Test-running
Post
implementation
Review and
Maintenance
Interconnectivity
of Stages
0 20 40 60 80 100
%
ISAC Method
Profile

ASSESSMENT OF ISAC BASED ON THE FIVE CRITERIA
1. Change/Process Analysis and Data Modelling: It is a process-oriented approach
rather than technology-oriented. In other words, it focuses on the business
processes, events and activities of an organization and the possibility of making
changes to existing IS’s. In this respect, I think ISAC meets the Change/Process
analysis criterion, except that it does not emphasize Data Modelling as it is
process analysis.
2. User Involvement: ISAC is a design method that focuses on the problems and
needs of the organization and consequently sets out to find solution to these
problems by doing business processes analysis as in the Change Analysis phase
by emphasizing cooperation between the users, developer and sponsors. I think
ISAC is a method that incorporates the involvement of the users but does not
emphasize it enough to the extent of defining and specifying the role of the users
in realizing the IS.
3. Test-running: I think test-running IS as a part of the System Life Cycle (SLC) is
not included in the development life cycle proposed by ISAC.
4. Post Implementation Review and Maintenance: ISAC does not also include or
emphasize post implementation review and maintenance of IS’s. This is a very
important phase in the SLC.
5. Interconnectivity between Design Stages: There is little or no coherence or
interconnection between one stage and the next. The output of one stage is not the
input to the next stage.
STRENGTHS OF ISAC
1. Emphasizes change/process analysis
2. Analyzes problems and involves problems owners
3. Uses cause-effect analysis and eliminate solution-oriented problems to get to
underlying causes
4. Generate and evaluate change alternatives to choose the best alternative solution
5. Emphasizes cooperation between users, developers and sponsors
WEAKNESSES OF ISAC
1. Not iterative
2. Does not involve testing
3. No clear connection between design phases
4. Not adaptable or flexible
5. Does not emphasize post implementation review and maintenance
CHANGE OF SPONTANEOUS IMPRESSION GOT FROM EVALUATION OF
TDM ASSESSMENT METHOD
This study highlights the different traditional design methods (TDM’s) with different
stages or phases in the system life cycle that are inadequate for the development of an
information system. And as such, there is need to combine two or more traditional
methods that will complement one another to come about a better design method, e.g.
MoIST—Method of Incorporating Systems Thinking into Information Systems Design.

CRITICAL SYSTEMS HEURISTICS
Critical Systems Heuristics is a name applied by Ulrich to a set of 12 questions he
devised to encourage critical thinking about the value judgements that underlie planning
decisions (Ulrich, 1993; 1996).
EVIDENCE FROM ISAC DESIGN METHOD THAT SUPPORTS CRITICAL
SYSTEMS HEURISTICS CONCLUSIONS
The following can be extracted from ISAC design method as evidence that seems to
support part of the framework of boundary categories of CSH, which translates into a
checklist of twelve critical boundary questions:
1. In the change analysis phase of ISAC, the designers of the IS attempt to analyze
business processes, the existing IS for solving the organizational business
problems, and seek way by which it (existing IS) can be improved upon. This
keys in with the third boundary question in CSH’s sources of motivation
boundary category: What is (ought to be) the measure of improvement? That is,
how can (should) we determine that the consequences, taken together, constitute
an improvement?
2. Another requirement ISAC and CSH share in common is that of the purpose of an
IS. In ISAC, the purpose of an IS is to meet the business needs and requirements
of the users, customers as well as the sponsors. This answers the second question
in the sources of motivation boundary category: What is (ought to be) the
purpose? That is, what are (should be) the consequences?
3. Another thing they share in common is the system analysts, designers,
programmers and implementers etc: the professional stakeholders involved in the
development of an IS. This answers the first question in the sources of
knowledge boundary category of CSH: Who is (ought to be) considered a
professional? That is, who is (should be) involved as an expert, e.g. as a systems
designer, researcher, or consultant?
EVIDENCE FROM ISAC DESIGN METHOD THAT CONTRADICTS
CRITICAL SYSTEMS HEURISTICS CONCLUSIONS
ISAC does not take into consideration the people and environment that will be adversely
affected by the deployment of a particular IS as does CSH in the second of the sources of
legitimation boundary category questions: What secures (ought to secure) the
emancipation of those affected from the premises and promises of those involved? That
is, where does (should) legitimacy lie? CSH ensures changes made to systems are
ethically correct, not affecting anyone negatively. ISAC, on the other hand, is limited to
analyzing problems and solving them for the problem owners (a self-serving concern).
Put differently, ISAC does not consider the third reference system, referred to as context
of application (A) in CSH, which is one of the contexts that matter when assessing the
merits and defects of a claim; and defined thus as that part of the universe in which the
consequences of our actions or claims arise. Rather it adopts conventional systems
thinking, which takes the context of environment (E) into consideration because it
conditions the success of what we do, in spelling out the do’s in a system’s life cycle
(SLC). E embodies a strategic concern for the success of the systems designs or action
proposals, considering A embodies, an ethical concern for the consequences that a design
or proposal may impose upon third parties, including the natural environment.

MOST SEVERE SHORTCOMINGS OF ISAC TDM IN THE LIGHT OF CSH
ISAC does not seem to address the the following boundary questions that dwell on
legitimacy as in Ulrich ’s proposed sources of legitimacy boundary questions in CSH:
1. Emancipation (Victim: Who or what could fall victim or be negatively affected
by the system? This could be marginalized stakeholders, future generations, non-
human nature, or ideas associated with beliefs, values, morals, ideologies.
2. Witnesses: who is representing the interests of the system potential or actual
victims, particularly those interests that cannot speak for themselves? That is,
whose voices (should voice) the concerns of stakeholders, who are not involved
or cannot speak for themselves, including future generations and non-human
nature?
3. World view: What is the source of the tension between the standpoint of”
system” and the negative effects of the system? And how can that tension be
reconciled?
POSSIBLE WAYS OF OVERCOMING SHORTCOMINGS
To overcome the shortcoming of the self-serving objective, ISAC should adopt the third
reference system—context of application—among its steps/phases in the development
and deployment of IS’s. True, as some analysts may argue, practically Ulrich’s
propositions are difficult to achieve in the real world, as they are “built on philosophy”;
however to a large extent, considering the negative impact of an IS on third parties as
well as the environment at the design phase, will go a long way to reducing such impact,
as alternative and better ways will be found in deploying the IS. For instance, in
providing power for an IS, a generating plant (hardware) which emits toxic fume and
noise may be deployed when there is power failure; however, in going for an industrial
UPS or solar power, the immediate environment and neighbours (third parties) must have
been spared of toxic gas and noise pollution as well as the world at large (environment) in
reducing green-house gas emission, and ultimately, global warming
WAYS BY WHICH THIS STUDY CHANGED MY UNDERSTANDING OF TDM
1. I realized that there are many TDM’s for the development of IS’s, with each
having its advantage s and disadvantages in such a way that different TDM’s suit
different IS’s, as perceived (convenient and appropriate) by the users (analysts
and designers) of these methods.
2. No TDM has a fit-it-all solution for the development of IS’s. Rather, one design
method complements another, while at the same time serving as a base on which
new or modern design methods build, e.g. MoIST.
3. Finally, I came to know and understand the third reference system by which the
deployment of a system will be assessed against: context of application—in the
study of CSH. This I never knew before in previous studies, neither in my/the
design of IS’s. I also got to know the checklist of boundary questions (which are
twelve) for assessing claims.
WAYS IN WHICH CSH IN CAN BE APPLIED IN FUTURE WORK WITH
INFORMATION SYSTEM DESIGN
When designing IS, I will ensure I assess it using the twelve boundary questions in CSH,
especially as regards its purpose, benefits to the owners and the effects on third parties
and the environment, just as it is claimed that the use of CSH enables researchers to elicit
rich qualitative data that captured different world-views, values and boundary judgments

of social actors representing the different groups of stakeholders involved in or affected
by a policy (Luckett, 2006).
REFERENCES
http://www.systeminformatik.se/medwik/index.php?title=User_involvement
http://eprints.hud.ac.uk/352/1/NwakoPhdThesis.pdf
http://tarpit.rmc.ca/phillips/courses/583-2000/lectures/05-modeling-enterprises-and-
goals.ppt#265,8,ISAC
http://en.wikipedia.org/wiki/Information_Systems
http://www.systeminformatik.se/isd/keyUlrich.pdf
http://epubl.luth.se/1404-5508/2000/125/index.html
http://www.ingentaconnect.com/content/klu/spaa/2006/00000019/00000006/00009040
http://users.actrix.co.nz/bobwill/CSH.pdf

TRADITIONAL DESIGN METHOD

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to TRADITIONAL DESIGN METHOD

Similar to TRADITIONAL DESIGN METHOD (20)

TRADITIONAL DESIGN METHOD