Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
SASD methodology from a practical point of view
problems and suggestions for improvement
F.A. Masoud,* M.U. Shaikh,* S.H. Mustafa*
"Dept. of Computer Science, Sultan Qaboos University, Oman
*Faculty of Engineering, LI. U., Kuala Lumpur, Malaysia
Abstract
The purpose of this paper was to describe the authors experience in using SASD methodology
as a system analysis and structured tool in the software development process. The comments
made and the suggestions provided for improvement were based on direct observation of
applying the methodology byfinal-yearstudents of computer science. The authors supervised
several team projects and attempted to pinpoint the strengths and weaknesses of the
methodology. Being machine and language independent and having well-defined symbols,
notations and tools, SASD seems to be a powerful methodology. However, the results of the
study indicate that there are many problems associated with using the methodology. These
problems are related to context diagrams, data flow diagrams, data dictionary, data analysis,
social and human aspects and user/management participation.
1 Introduction
Conventional methodologies of developing software systems need to be
reviewed and modified in the light of the increase in scale and complexity of
recent applications. Many researchers [3,8-11] have attempted to provide reviews
of the available methodologies and they produced a good indication of each
methodology's principle features and benefits.
Structured analysis and structured design (SASD) is one of those
methodologies which provides a framework for establishing a software design. It
has come to existence as a combination of two methods: structured analysis
(SA) developed by Gane & Sarson[6] and structured design (SD) developed by
Yourdon[15]. On one hand, SA covers the analysis of the old computerized
system and develops details of data-flow, data-structure, process logic etc.. The
end result is a set of statements or structured specifications showing what the
new system is supposed to do.
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
94
Software Quality Engineering
On the other hand, SD starts from the output of SA and produces as the
end product: the final structure chart and data dictionary. This is done by
partitioning and organizing the structured specifications into black boxes called
modules. A general overview of the methodology and its scope, aims,
objectives, and deliverables is given in [8].
SASD has been one of the most widely used information systems
development methodologies used in the United States since it was first
introduced and its basic ideas were first published by Stevens and his
colleagues[13]. It is mainly suitable for developing software systems for the
commercial and industrial environments, especially in organizations where an
old computer system is interfacing with manual systems.
In the academic arena, SASD has been adopted by many universities
around the world as the basis for a core course in the area of "systems analysis
and design". The present study reports the authors' experience in supervising
projects conducted by students using SASD as a basis for systems analysis and
design, and suggests some modification to the methodology.
As such, no specific research methodology was applied in carrying out
this study, the results and notes reported in this study were obtained through
direct observation of applying SASD for developing real-life prototype
systems. Most of the systems were carried out at Sultan Qaboos University in
Oman.
The authors have taught the SASD methodology to undergraduate
students majoring computer science at four different academic institutions
(including: Yarmouk University in Jordan, University of Kuwait, University of
Karachi in Pakistan, and Sultan Qaboos University in Oman) as part of a
one-semester 3-credit course in "systems analysis and design".
Students were expected as part of the course to do a group project to
solve a real life problem (such problems include, for example: inventory
control, traffic control, auto-teller machine, flight reservation, textbook
ordering and circulation, ... etc.) in the banking and commercial environments
using the SASD methodology.
During the application of SASD in various projects the authors were able
to observe carefully how the methodology could be used in different systems.
Efforts were made to analyze the features and tools of the methodology in
order to find the strong and weak points of the methodology and to evaluate
the claims made by the authors of the methodology.
2 Problems Encountered
During the practical use of the methodology it was observed that SASD is
different in many aspects from that mentioned in textbooks and other
literature. The SASD methodology directs 'what must be done and in what
order or way it must be done', but we observed that it is not always feasible in
the real world problems to follow such directions. Also, in many cases we
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
Software Quality Engineering
95
experienced that by following the methodology we could effectively break
down a complex problem into subsystem, but it was difficult to identify the
mechanism that could link these subsystems efficiently.
There is a need to have tools/techniques or methods to determine the
technical objectives of the system. The system developed by using SASD does
not give any information about the technical details which may be needed to
implement the system, e.g. technical specifications about the system, hardware
needed, and manpower requirements. Our eight years Experience of teaching
and applying the SASD methodology have revealed the following major
problems.
2.1 Context diagram
The context diagram tool of SASD does not describe the internal workings of
the system, so it is not possible to clearly show how and what the system has to
do. Further, there is no logical and physical concept as in data flow diagrams
since a context diagram does not show much on either how or what.
The scope of a context diagram is limited to the boundaries of the area
under study. A context diagram is useful only in giving a brief idea of the
system, but useless in showing exactly how the system works.
2.2 Data flow diagram (DFD)
The data flow diagram (DFD) tool is used in SASD for modeling
transformations. This tool is powerful, but our experience has shown that it is
associated with several problems:
a. A lot of information about the system is required in order to construct a
DFD, even at level-zero. A DFD cannot be started unless a thorough
knowledge of the entire system has been attained.
b.
Several trial and error efforts are necessary before the first DFD at zerolevel can be constructed. Sometimes, it is difficult to choose the starting
point, since this is not very well-defined
c. For large systems, it is very difficult to manage the DFD having too many
processes and too many levels. Such DFDs are very tedious and timeconsuming possibly giving rise to errors that can propagate from one level
to another. Any error that occurs in the beginning of the DFD will not be
detected until the whole data-flow diagram has been drawn. If a process
is missing it is very difficult for the analyst to detect it and he will have to
rely on the user management to point out the missing process(es). But in
most cases, the user may lack the time or the understanding to correctly
interpret the DFD. There is no way by which to verify that what is shown
in the DFD is correct.
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
96
Software Quality Engineering
d. Top-down decomposition of a DFD can only be useful when it is guaranteed
that the top level is fully understood and the object or problem to be
represented is fully and correctly illustrated by the top or higher level DFD.
The use of top-down decomposition approach to do analysis of the
problem by using DFD is not a successful approach, especially when the
analyst/designer does not have a clear idea of the complete result in mind
based on his own previous experience. It was found that the top-down
approach to describe the problem and analysis results by using DFD can
not be used effectively when developing a system for a new environment.
e. Data-flow diagrams are time independent models. They do not show the
time involved in implementing a process. This creates problems for project
management, scheduling and manpower. For example, if two or more
processes are in parallel we cannot decide at what time each process will
end. If one process is the descendant of two processes and those are in
parallel then there is a problem to execute the descendant process. If the
time for each process were known, then the time for parallel processing
could be calculated. There is no depiction of sequence or order of
processes.
2.3 Data analysis and data dictionary
There is no tool in SASD which can identify the form of data received from an
external entity or source. Also, it is not guaranteed if this data is complete and
will serve the purpose and satisfy the requirements of the system.
2.4 Structured chart
The structured chart does not show the working and internal structure of the
processes or modules, and does not show the relationship between data or
data-flows. Similar to other SASD tools, it is time and cost independent and
there is no error-checking technique associated with this tool.
The modules of a structured chart are arranged arbitrarily and any
process from a DFD can be chosen as the central transform depending on the
analysts' own perception. The structured chart is difficult to amend, verify,
maintain, and check for completeness and consistency.
2.5 Human and social aspects
Social and human aspects of the system and its environment have been
ignored. The reaction of the user and management of the organization that will
use the system can not be determined or evaluated. Strong and active
participation of users and management is lacking. Such participation creates
and boosts the confidence between the user and the software developers.
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
Software Quality Engineering
97
The methodology does not give any information/support about "how the
system, developed by using SASD, will behave and satisfy the requirements and
needs of the organization using it". It lacks to consider the political issues or
issues related to human behavior. During our experience in using SASD it was
observed, for example, that in some organizations the result of the
analyst/designer was heavily influenced by the choice of equipment already
made available by the management. It was very difficult to argue with the
management that the particular hardware available will not be suitable for the
environment and the system.
3 Suggested Improvements
This list of problems should not give the impression that the SASD
methodology has been poorly designed. It must be pointed out here that the
methodology provides the systems analyst with various tools and techniques to
utilize. It is machine and language independent and the notations, symbols, and
keywords used are easy to draw, unambiguous, and readable.
However, there is a great risk that an inexperienced analyst/designer
involved in complex problems may lead towards inefficient systems. The level
of experience required varies according to the size of the problem to be solved
and its environment. In general SASD was found to be easy to use. The
following paragraphs provide some suggestions for improving SASD.
3.1 Context diagram
The scope of the context diagram can be extended to show how the system
works. This is can be achieved by developing a context diagram showing all
sources and sinks in the system's environment and their interaction with the
system and incorporating events list. In this case the list of events taking place
in the system's environment are specified and the ways in which system must
respond to those events are modeled separately.
3.2 Data flow diagram (DFD)
We can incorporate the Boolean operators and & or to link data flows
when more than one data flow may be input or output from a process [14]. For
example, if we have to choose between two paths of a process we can add an
operator or and if two data flows are necessary for a process we can add and
operator as shown in Figure 1. The input of the process "check-order" needs
the credit information and order information whereas the output of the process
would be a cash-order or a good-credit-order.
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
Software Quality Engineering
cash-order
order
check
AND I order 1 OR
od-credit-order
credit-info
Figure 1: Graphical representation of DFD including or & and
operators
Further, time factor can be incorporated by extending the notion of data
flow to include time. Time continuous data flows, i.e. flows that exist at every
instant within a time interval, are useful for representing characteristics of the
physical environment, such as voltages and temperatures, and in representing
output signals by which they may be regulated. The line with a double
arrowhead is used to represent a time-continuous flow. Figure 2 shows the
DFD notion used to indicate time continuous flows.
voltai
regular level
Figure 2: DFD notation used to indicate time continuous flows
Moreover, systems may contain certain data flows which have no real
content but merely serve to modify the response of the system to incoming
data. These are termed control flows and are represented by a dotted line.
Figure 3 shows an example by which a control flow is represented by a dotted
line.
[enable/disable]
volta
.voltage/
regular level
Figure 3: DFD notation used to indicate control flows
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
Software Quality Engineering
99
The use of control flows therefore allows a rigorous interpretation of the
behavior of data transformation over time. A transformation that accepts only
control flows as inputs and generates only control flows as output is termed a
control transformation. The control transformation must keep track of which
control flows it has already received and use this transformation to help
generate its output, i.e. it must memorize the output control flow. The use of
control transformations is particularly common in interactive applications where
commands from the operator have to interpreted and dispatched to activate the
relevant procedure.
3.3 Data dictionary
A physical data dictionary for data elements which flow between processes,
between entities, and between processes and entities may be included. This
would also include descriptions of data elements that flow external to the data
stores. A logical data dictionary may also be included for each such data
element. All system names, whether they are names of entities, types, relations,
attributes or services, should be entered in the dictionary. Support software
should be available to create, maintain and interrogate the dictionary. This
software might be integrated with other tools so that dictionary creation is
partially automated.
The data model used in SASD uses the basic notation and concepts of the
entity-relationship (E-R) diagram [4] which is just a graphical abstraction on
the use of nouns and verbs in written sentences. However, it is suggested by
this paper to store all the data elements associated with entity set in the form of
a table. Each member of the entity set corresponds to a row in the table and
each attribute of the entities is represented by a column. Each relationship may
be represented by a column of one or the other entity sets it relates.
This corresponds exactly to the form in which entities are stored in a
relational database and therefore advantage can be taken of the powerful
features offered by modern commercial database management systems (e.g.
ORACLE [12]) for providing access to the data.
3.4 Structured chart
A small description can be added with each process so that it would not be
necessary to refer to the process specification called mini specification to see
what the process does. In this way relationships and hierarchies between
processes would be made clearer. Similar, input and output of each process can
be added with its description.
A time factor may be included as discussed in DFD.
That is, process
ordering/sequence may be introduced which can show which process will
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
100
Software Quality Engineering
follow another process. Likewise, a decision box may be included to see which
process is executed and when and why.
3.5 Social and human aspects
Social and administrative effect, human and social aspect and management/user
participation can be incorporated under human factors guidelines. Researchers
[1,5] have identified twelve areas where human factors extensions to software
systems development methodologies can be beneficial.
3.6 Other suggestions
(a) Some constraints similar to those used in PERT diagrams to represent a
time factor in SASD should be added. A diagram can be developed that
will keep track of the time taken for developing as well as the time taken
for running each process.
(b) Since there are no techniques provided by SASD which can help the
analyst/designer on how to solve a particular problem. It is difficult to
know how to attack different problems. If different techniques were
available for the development of different systems, this would solve a
number of problems and would save a lot of time and effort.
(c) Risk analysis is missing in SASD methodology, adding this facilities to it,
will make it a powerful paradigm This study suggests that a risk analysis
technique must be incorporated in the same way as used in spiral model
[2]4 Conclusion
In SASD, strategic and organizational issues related to software development
have been completely ignored. The methodology is not concerned at all with
determining the social and administrative effects which may happen during the
process of systems development due to people's issues and human activities.
There is no mechanism in SASD which can guide how to eliminate or reduce
possible resistance which may happen from users or a group of low level
management. Further there is no way to know about job satisfaction, possible
gain in efficiency, cost benefit, and "risk factors" that arise from the
development and the new system.
Like many other software development methodologies, at the time of
giving technical recommendations or system specifications the psychological
job design criteria are not considered at all in SASD. It does not have a
management procedures, review points and feedback loops. The methodology
also does not focus on achieving consensus and acceptability of the outcome to
different types of users, management, and others concerned
through
participation, coordination and mutual agreement gained through resolving
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
Software Quality Engineering
Ml
conflicts, if any. These conflicts usually arise at a later stage of software
development and particularly at implementation and transition phases of
software development. A possible solution to this problem can be to
supplement SASD with some techniques/tools/methods, similar to COMPACT
method [18] which supports SSADM (Structured Systems Analysis and Design
Method) [19] that has a similar problem.
Further, There is no check to find whether or not implementation is
effected by vested interests of the parties involved. A solution to this problem
may be to modify SASD on the same lines as LBMS methodology [7]. In that
approach they emphasized on the awareness of social and political issues
during the task of systems analysis. They did this apart from the technical
solution of the problem. Professor Mumfored [16,17] has also given a possible
solution in ETHICS (Effective Technical and Human Implementation of
Computer Systems), but her methodology is silent about how to solve technical
problems.
According to the experience we gained, we found that SASD was not a
general methodology. It has restricted applications and is best suited for
business and commercial systems. It is less efficient for real time systems and
for problems where strict time ordering is involved.
The suggestions listed in this paper provide a framework for improving
the methodology, while it is not possible sometimes to incorporate ideas that
would fit every system environment, technical issues could be improved and
complexity of tools could be reduced. The SASD methodology should be
reviewed in light of the new developments in object-oriented analysis and
design and parallel processing.
References
1. Catteral B I, 3 Approaches to the input of human factors in IT systems
Design. HUSAT, 11/12/89.
2. Boehm B W. A spiral model of software development and enhancement.
IEEE Computer, 21(5) 1988, pp.61-72,.
3. Cameron J.R., Campbell, A., & Ward, P.T.
development methods: example. Information and Software Technology,
33(6), 1991,pp.386-42.
4. Chen P.P., The entity-relationship model, toward a unified \new of data.
ACM Transactions on Database Systems, 1 (1) 1976, pp. 9-36.
5. Damodaran L. & Beck M., /Mffgmf/ng /mmm? ./before mf
f&f/gM %,f f/Wo/ogy. In Bullinger, H. J et al. (eds), Information Technology
for Organizational Systems. Amsterdam, North Holland, 1988.
Transactions on Information and Communications Technologies vol 14, © 1997 WIT Press, www.witpress.com, ISSN 1743-3517
102
Software Quality Engineering
6. Gane C E., Sarson T., Structured Systems Analysis. Englewood Cliffs (NJ),
Prentice Hall, 1979.
7. LBMS Jackson System Development. Method Manual. Chechester, John
Wiley, 1992.
8. Maddison R.N., Information system methodologies. London, Wiley
Heydeen, 1983.
9. Olemp A., Design approaches: a comparative study of information system
design and architectural design. The Computer Journal. 34 (3) 1991.
10. Olle T.W. et al., Information systems design methodologies, a comparative
review. Proceedings of the IFEP WG.8.1, 10-14 May 1982, The
Netherlands, North Holland, 1983.
11. Olle T.W. et al., InfojTiiation systems methodologies: a framework for
understanding. London, Addison-Wesley, 1991.
12. The ORACLE Relational Database Management System. Belmont (CA),
ORACLE Corp.
13. Stevens W P., Myers G. J., and Constantine L. L, Structured design. IBM
System Journal, 13(2) 1974, pp. 115-139.
14. Tse T.H. & Pong L Towards a formal foundation for DeMarco data flow
diagrams. 32(1) 1989.
15. Yourdon E. & Constantine L.C. Structured Design. 2nd ed. New York,
Yourdon Press, 1978.
16. Mumford. E., Participative systems design: structure and method, systems,
objectives, solutions. The Netherlands, North Holland, 1981.
17. Mumford. E , Designing Human Systems. Manchester, 1983.
18. CCTA, COMPv4Crm.9/nYC//w7mm?7/67/, v.1.1. Norwhich (UK), 1989.
19. CCTA, SSADMver. 4 reference manual Oxford: NCC Blackwell, 1990.