AN ANALVSIS OF INFORMATION SVSTEMS DESIGN METHODOLOGIES INFORMATICA 3/1988 UDK 681.3.:519.863 Krista Rizman Ivan Rozman Anton Zorman Tehniška fakulteta Maribor ABSTRACT To Improve development and use of information ajfstems methodologies, theae have to be dlscuased and studled from many aspects. We have anal/sed JSD, ISAC, SA-SD and the Warnier/Orr methodology. The contents of this paper is not a descriptlon of studled methodologies. It is the descriptlon of our flndlngs and the results of evaluatlng the practlcal value of the methodologies in relative terms by comparing them. We methodologies according to their life cycle representatlon shemes, learnabllity, their real time environment and automated toola by supported. Our maln point here lies in demonstrating that each of the four methodologies is relative powerful in some circumstances and for some system3. characterize the coverage, their behavior in the which they are INTRODUCTION The use of computers has spread to ali areas of labour and life and the way of use has changed. In the first period of use, computers were used only for calculation. Almost ali data processings vere numerical. The main point of use has moved from calculation to storing and searchlng data - Information. There has been a great progress of new approaches, methodologies and tools for developing of Information s/stems re3pectivly application by the last decade. The Information 3y3tem is a system with the follovfing tasks: creating, collecting, Processing and distributing informations. Information systems could be developed only if they in some way can improve some activitiea of Information process. The progress of computer technology, especialy the fall of prices, caused the mass use of computers. The development of applications has become a bottleneck. This is a reason why the languages of the fourth generation (application = functi onal languages: LISP, PROLOG, query languages...) and a great number of computer aided tools for system analysis and design have been produced. There are a great number of graphic tools and methodologies that can be used for analysing and design of Information sy3tems. The problem from this set of is to choose one methodologies, that will be the most efficient, easy for use and will give the best results. There are many questions: 'Which methodology to choose?', 'Vfhich is the beist?', ' Which is the most general?', 'What are advantages of each of them?' Which methodology to use? This is a difficult question because it depends on your needs, on the type, the extension and the complexity of Information systems you want to develope, on your experience, style of thinking and probably on your knowledge of principles of different methodologies. We restrlct our study on methodologies that are shovn in table 1, mainly because we think they are the most efficient and Hidespread used for developing Information systems. This paper presents the results of study the different methodologies with the purposo to answer some questions above. Table 1: In the following we give the methodologies covered in this report along Hith developers Methodology Full name of mnemonic methodology Developers SDM System Development G.F.Hlce, Methodology K.S.Turner SA-SD Structured Analy3iš De Marco and Structured Design Yourdon ISAC Information Systems Mats Work and Analy3is Lundeberg of Changes JSD Jackson System Development Michael Jackson Warnier/Orr-method VJarnier, Orr 40 It must be pointed out that our anal/sis draws on the referenced literature. This is important because methodologies are not finished products. They do not have precise characteristics. They are iraproved through time. Methodologies in a practical use can be adapted to chainging environmenta and circumatancea. On the other hand, the authors often emphaaize ascpects considered as most original, while aspects regarded as more usual are left out. Several points of view can be used to anal/se a methodology and ali of them must be considered in a complete analysis. 2 LIFE CYCLK COVERAGS By analy3ing the mentioned methodologies, we find out that they have much in common. They have a great diversity in form, in original principles and in name of each phase, but they agree with basic elementa that need to be defined. A lot of them cover almost ali phases of a life cycle(table 2). The life cycle is an important concept in discussing methodologies. Our view is that an efficient methodology must support a process of activtty that covers the entire life cycle. It doea little good to have a methodology for design if tharo is not a procedure for specifing requirement3 and funotions which are used for the design and the sy3tem that must be built. There are numeroua life cycle models in use and many of them separate analysis and functional specification activities./PORC83/ WQ merge both of them into one phase (analysi3) because the diacussed methodologies do not distinguish between these tMo ateps. For both phases almost ali of them (except the ISAC methodology) support the aame graphical diagrams and other tools and in both the uaers are most included. In this paper each methodology is presented through the description of the following life cycle steps: analysis, design, implementation, validatlon, evolution. 2.1 Analyaia Analy3l9 is the first step of any Information sy3tems development aotivity. The result of this step is besldes the requirementa definition also a functional specification - description of system functions and an ansHer to the question : 'What should the system do?'. Functional specifications are used during the design phase as a checkpoint against which to validate the design. The successful analysls includes Communications with the users. The analysi3 must be able to bound a problem and to identify those areaa where the Information sy3tem is useful and practical. A particularly effectlve method of analy3i3 ia raodeling. Models represent the problem and the real world in a formal form. Models used for analy3is are graphical diagrams, graphs and tables. Because of the complexlty of problems and 3y3tems, methodologies must support a problem decomposition nhich can be procedural or data flow or data abstraction. Ali diacussed methodologies are performed through an analysis of the data, elther data atructures or data flows! The data orientation is sensible because data are more stable than processes. SA-SD and ISAC analyse data floHS, but the VJarnier methodology analyses the data IMPLEMEN-! VALIDATION * TATION ! /. In property tables is documen- C/!tation of hoH the original requirejnent3 are fulflled. .1 System outputs are validated against )output requlrements. '^Z A Completed system can be ',CjA compared with original structured specifications. Transformation of speclfl- cation to implementation can be manual checked. repreaenta how detail is a particular phase covered EA - roethodology contains a special phase wlth the purpose to choose specific equipment and then to adapat the equipment independent solution to this choice c - codlng • - how the completed sy3tem is validated against the original requirement3 Table 2: Life cycle coverage 41 structures of the outputa. JSD analyse3 the entlt^/action structure of the real Horld. (Figure 3) niethodology /\ / \ / \ / \ / \ are performed through are performed through an analysis of data an analysis of data structures floHs JSD, Vfarnier SA-SD, ISAC Figure 3; A slmple dlvision of the Information sy3tems design methodologles Our view is that the data flow methodologles are more understandable than the methodologles which base on the data structure. A data flow diagram (DFD) is a better tool for understandlng and more perfect representation of any Information sy3tem than data structure diagrams. It represents both flovjs and actions. (Figure 5 3hows an example of DFD.) It is a netHork diagram that can be ea3y used for bounding the system. First of ali, wa draw the diagram with only one action and wlth input and output data floHs. They are then decomposed. We think that so the users and the arialysts can ea3ily, systematlcally and by degrees, with the help of DFD, make the requirement definitions and the functional specifications. The SA-SD methodology is very useful for working in a team because of the logical functional decomposltlon and well-known input and output data of any decomposed action. More complex and detailed analysing process can be done by ISAC. Besides the Information (message) flow3 we can also describe the real flows (persons and objects). The picture of current and future Information system is complete. ISAC is very strong in the early phases of the 3y3tem life cycle: the change analy3is, the actlvity analy3i3 and the Information analy3i3. The ISAC approach is exten3ive and comprehensive! In ISAC interest groups are studied thoroughly and described both with the problems they have. This is a part of the change analy3i3. The ISAC approach Is widespread used in the Scandinavlan countries. The weak point of ISAC is that the graphical notation for the Information analysl3 is redundant because ali Information contained in Information graphs (I-graphs) is derived from activity graphs (A- graphs) from the change or the activity analysis. ( Figure 6 show3 an example of A-graph!) The weak point is also that it is neces3ary to illustrate two identical Information sets in the same I-graph because of the hierarchlcal way of descrlption. Two sets are needed uhen one Information set is output set of a graph and at the same tirne is a precedent to other set in the same graph. I-graphs show Information sets and precedence relations among Information sets, but C-graphs (component relation graphs) describe the contents and the structure of the Information set. The methodology does not provide that the •same Information set will have only one C-graph. It depends on when the particular C-graph is created. We think that many of definitions and work of the Information. analyse could be overcome by use more powerful Information model such as extended entity-attribute diagram to replace both Information graphs and component graphs. Heakness of JBD is the first step of mathodology (enttty-actlon step), by which ne analyse data and actions of the real world. It seems to us that in this step the methodology does not provide such a graphical tool whlch can help the users and the analysts to edit, colect and represent specifications (especialy ali entitles). Graphical notations are useful in shoning the interrelationships between the system components, which enable ea3y Communications between the users and the analysts and so help both of them to build the complete Information system, JSD does not provide such a graphical tool. Jackson suggests a simple process to make a wide list of entitles and actions: nouns which appear in the users descrlption of the real world are Identifled as potential entitles, but verbs as possible actions. The users many tlmes forget to mention some parts of the reality because they do not have resource for sistematic descrlption of often very complex sistems. Unfortunately, the complete list of entitles and actions is reque3t and conditlon for success of entire development. JSD does not support graphical presentations of links between entitles of the entire system, from . Hhich can the users and the analy3ts quickly find out the mlssing entitles. The JSD methodology is little oposite to the other Information system3 development methodologles. They tend to more exact analy3is with purpose to build a better sy3tem wlth less prlce to meet the needs of its users and to reduce costs of correcting. The second tendency is reduoing of returning to previous steps. Of course, there is an iteration, but we ali want to reduce It as much as possible. Modem methodologles and computer aided tools include mechanlsm to reduce it to minimum. In the Warni«r m«thodolog7 the flrst step is to determlne whlch are required outputs. The answer is quite obvious Hhen the 3y3tem is not too big. Else we have to subdivlde the real 3ystem Into several smaller. Many tlmes the subdlvision will be done according to the organisation of the firm. Analyst may help formulating que3tions and so help to create a list of required outputs. The methodology does not provide any graphical tools to help in this first step. Ali the methodologles except JSD apply the hierarchlcal decomposltlon. Of course, levels of detall are related to complexlty and vagueness. The vagueness concerns the early phasas of life cycle, when the functional and the data system may be fuzzy and there is no clear idea how the ay3tem will Hork.- In this context a crude Information analysis is quite good alternative. The possibillty of the crude Information analy3ls is embedded in the ISAC methodology. We start to build ncH 3ystem with the crude Information analysls in the change analy3ls and then we end wlth the detailed analy3is in the Information analysis phase. The crude Information analysls is also supported by SA-SD, 'which enables simple executlon of the functional decomposltlon. Our vtew Is that the most detailed analysis Is provided by ISAC, then follow SA-SD, JSD and the Harnier methodology. 2.2 D«sign is the process of determining the architecture 42 of the system components, the algorithms to be used and the loglcal data structures. This phase is an answer to the question:'How will the systera perform the functions defined in the previous phase?' . An output of design activities can be used by the programmer to Implement the 3ystem. We must'emphasize that coupling and coheison are the simple judge of whether a design strategy produces good designa or bad designs. A developer nust' be able not to continue only forward to the next phase of the life cycle, but al so back to a previous phase. The need for this is the fact that work must be changed and any nece33ary corrections can be made. It is important to note that information lost at a particular phase is generally lost forever with a bad result on the sy3tern. For example, if a requirement are not documented, it will not appear in the functional specification and it will cause the failure of the system. Ali the methodologies except JSD are •very strong based on the levels of abstraction and on the hierarchical decomposition, where there is always the problem of wheter the model at the lower level satisfies the specification fixed at the upper levels. This problem can partly be dlspatch by detailed transformation rules from an upper level to a lower one and by automated tools. SA-SD supports two transformation rules; a transform analy3is and an analysi3 of activities for producing a structure diagram from data flow diagrams. We must teli that structured diagrams can not be made only by the transaction and the transform analysis but it require3 some judgement and common sense on the part of the designef. This strategy is considered in the Warnier methodology well but in ISAC only particular. ISAC makes levels of abstraction quite visible, but there is not a visible connections between the analysis phase and the design phase. Perhaps it is the reason in use of other method (Jackson Structured Programming) for the design. 2.3 Implementatlon is the production of executable code. Coding transforms algorithms into functions or procedures and logical data structures into phisical data structures. It must be pointed out that good coding cannot make up for poor analysis or design. Good coding cannot make bad information system3 good! This phase is an answer to the question: 'How can we run this sy3tem on machine available to us?' Th« ISAC and the JSD methodology enable design which is not confused with implementatlon, The delimitation betMeen design and implementatlon is in the ISAC and the JSD methodology very rigorous. Not before the latest phase we include the use of existing hardware and programming languages for realization developed 3ystem. This is an advantage of both methods, because the design system is more transferable and more portable. We can use it with little changes on different hardware ^ecause only the last phase must be changed. The choice of the hardware and the software needed and technical asspects of the implementatlon the Warnier mathodology and SA-SD do not solve. 2.4 Validation is the process of determining that a system correctly performs those functions described in the functional specifIcation. It is often a step performed as a part of each phase where we must verlfy that the phase correctly carries out the intent of the previous step. The validation of code raay be done either through testing or formal proof of correctnes. The methodology must aupport determination of system corroctneas through the life oycle. Methodologies usualy enable correspondence between the results of one stage of development and the previous stage. Table 2 shows how the whole systera can be validated against the original requirements. 2.5 Kvolution System3 go through many versions during their lifetimes. The development methodology can help in evolution phase by providing system doGumentation and, of course, a well structured software sy3tem that is easy modified by people making the sy3tem changes. The great eraphasis to a well structure of a program is given in the SA-SD methodology. The factors contrlbuting to interactions between 3ystem3 components (modules) and the coheison of individual system3 components are very well described. /Your79/ We tent to the greater coheison of individual modules in the system and the loMer coupling between modules. 3 IKTERMEDIATE WORK PRODUCTS By methodology we mean a number of coherent work steps including rules for type3 of documentation that are produced during these work steps. The documentation must be a natural part of work and not something that you do aftervjard! Table 4 show3 the steps of ali the four discussed methodologies and the products that are produced at each step! Figure5 5,6,7 and 8 show the viorking procedure of ali the four methodologies. Each working procedure is presented by the diagram, nhich is particularly signicifant for each of the four methodologies. We have already emhasized that graphical tools in ISAC seem to us redundant because the contents in I- graphs is the same as in A graphs. But the purpose of using both graphs is different. A- graphs give an overviev of the connections between the information system and its environment. I-graphs show the information contents in detail. ISAC enables adding details in a systematic way, but by help of the different graphs. We think that the data flow diagrams (SA-SD methodology) have an advantage, because it can be used for connections of the information system with the environment by sorces/sinks and for adding details by the functional decomposition and multilevel diagrams. For ali this ve have to use more graphical notations of the ISAC methodology. There is an assumption in ISAC that careful and detailed decomposition of the user activities wlll largely procedure the information requirements. From ISAC point of view work methods are more important than description tehnique3. We do not quite agree with this because we emphasize that description tehniques must be used as the basis for understanding the problem and for communication betHeen the users and team. 43 TABLE 4; Table shows steps of s/stem development of ali the four discussed methodologies ^nd the products that are produced at each step: ISAC: working procedure: different analy3is and design areas each of them is devided into more than 3 steps and substeps!) workproduct3 (documentation) 1. CHANGE ANALYSrS:analysis of problems and needs and the current state. We deftne and produce alternative changes and choose the best! A-dtagrams are used for hierarchical decomposition current activities. We can use also; problem groups tables, text pages, property tables, table of objectivea] 2. ACTIVITY ANALYSIS: we continue .with the decomposition of activities. We more detail define Information flows and Information subsystems! A-graphs (Figure 6), property tables 3. INFORMATION ANALYSIS; we analyse relationšhip between Information sets and the structure of Information sets. I-graphs:hierachical graphs of Information flows, textual description C-graphs 4. DATA SYSTEM DESIGN ! D-graphs !D and P strctures (JSP) 5. EQUIPHENT.ADAPTATION E- graphs JSD: working procedure work products (documentation) 1. ENTITY/ACTION STEP: We define entities and actions by help of user specifications (actions are verbs, entities are nouns). entity' action list 2. ENTITY STRUCTURE STEP structure hierarchical diagram (Figure 8) ' 3. INITIAL MODEL STEP: An entity is defined as a proces which is with data flow or State vector conected with entity of the real world or with other process in a model. Processes are detailed described with pseudocode. 4. FUNCTION STEP System Specification Diagram Jackson pseudokod System Specification Diagram 5. SYSTEM TIMING STEP 6. IMPLEMENTATION STEP-' note of temporal requirements System Implementation Diagram SA-SD: Morking procedure 1. ANALYSIS of sy3tem actions, Information flows, data bases ! Horkproducts (documentation) !data flow diagrams (DFD)-(Figure 5) !data diGtionary, decision tables, Ipsedocode 2. DESIGN : with help of transform analy3i3 and transaction analvsis we produce from data floM diagram hierarchical data structure! structure diagram psedocode WARNIER: Morking procedure ! workproduct3 (documentation) subdivision the big system into several! smaller, each of them have its own data! note of subsystems procesing system. ! the list of the required output and the description ali of them the organisation of ali the data needed to obtain the output, the design of a logical base. the definition of transactions needed to update the data. the definition of logical programs Warnier diagram (Figure 7) Warnier diagram Warnier diagram 44 transaction analvais transform analysis deciaion tables user ~~ requirements -«Janaly3is V ^-^ J data flow diagram structured languages 7 design \ \ 1-2 /- information -_^Sy3tem Figure 5: DFD of the SA-SD working procedure /perons with knowledge about the activities. • activity real set/ / Information set Figure 6: A- graph of the ISAC working procedure a I real flow message flow 45 the working procedure of the W/0 methodology r to subdivide the blg system Into several smaller to raake the list of the required output and the description of each of them \ to determine the corresponding data structure to determine logical structure to determine phiaical structure to definite the actions needed to update the data stored in the Processing 3ystem to determine the logical programs Figure 7: Warnier graph of the Warnier working procedure the work procedure of the JSD specifing the model of the real world determining and descrlpting entities and actions in the problem area: ENTITV/ACTION STEP • specifing the functions of the sy3teml determining functions of the models: FUNCTION STEP determining the implementation| of the system: IMPLEMENTATION STEP system timing of functions: SVSTEM TIMING STEP elaboration of entity structures: ENTITY STRUCTURE STEP composition of initial model: INITIAL MODEL STEP Figure 8: procedure Structure diagram of the JSD working ISAC is relatively complex due to several levels of abstraction and several graphlcal notations. It seems clear that understandability is reduced by the relative complexity of descriptions. In ali development phases of the Warnier methodology we can use only one graphical tool-Warnier diagram (Figure 7). We can descrlbe the data and structure process by only three basic components of stuctured programming {sequence, iteration and selection). 4 BEHAVIOR IN THE REAL TIME ENVIRONMENT Behavior of the methodology in the real-time environment is also very important because the Information system represents a set of coherent different or equal actions. We think that JSD is the most suitable of ali the four discussed niethodologies for applications from the real world with the important temporal extension. In the JSD System Timing Step adequate measures are taken to ensure a correct scheduling of system processes. For this purpose, synhronisation processes are defined. It is important to emhasize that JSD is intended for development not only for data Processing, but for other applications also. Temporal dimension of Information is not treated explicitly in ISAC, nor in the Harnier methodology. 5 LKARNABILITV The methodology must be ea3y to learn because even within single organisation, there will be quite a great number of people who have to use the methodology as a resource and it must help ali of them and not make a developer process more difficult. It is clear that the methodologies must be communicable to other persons not only to developers. Learnability depends on the complexity of the methodology , which is probably related with covering the software development life cycle and perhaps on the depth of the understanding of Information sy3tems provided by it. We establish that among the four discussing methodologies only ISAC is more complex, the others are relatively simple. We think that ISAC is less easy to learn. 46 6 AUTOMATED TOOLS It is clear that automated tools which offer series of understandable resources, brought near people, make posaible the supervision of a project and immediate repairing existing failures. Automated tools give up to date version to ali members of the team. A great number of automated tools and environments have been explicitlj' developed to support nearl/ ali studied methodologies. We do not know if such tools are coinmercialy available for ISAC methodology in a broad sense although in the ISAC group a prototype system called IA/2 was developed in the early seventies. Automated tools faciliate the work to designers and improve the productivity of both the individual developer and development team. Tools for computer-aided softwar provide these bepefits: Improved productivity and f development (They automate documentation, eleminate manual redrawing and allon quick changes higher q'uality software ( universal documentacion, standardisation. ) reduced maintenance (They changes and allow on-line access e engineering aster systems design and drawing and .) They produce promote proroote easy to design.) 7 CONCLUSION It is clear that any Information 3y3tems development methodology is better than no methodology! We think that there is no one Information 3ystems design methodology which is best for developing ali Information 3ystems. We have represented the main findings about the methodologies. It is clear that our analysis is in many respects preliminary, because of extreme complexity of the subject. In this section we describe importance of the methodologies from the practical point of view. description of entities of entire system and relationship between them. In the implementation step ve consider temporal performance of- each groups of actions. It is more powerful in the description of actions then entities. (See Figure 9.b and 9.c) We think that the V/^rnier methodplogy is suitable for developing complex data and action 3ystems because of use only one simple and efficient Warnier/Orr diagram. Our view is that SA-SD is very useful also for more complex data and actions sy3tems. SA-SD methodology enables 3imply description of data components in the data dictionary, A structure of actions are described by a structure language or decision tables. complexity of the data system high coraplexity of the actions on the data of the system high- + SA-SD + WARNIER + ISAC + JSD vagueness JSD SA-SD WARNIER ISAC low Figure 9.b high low 1 ISAC SA-SD Figure 9.c + JSD + WARNIER low Figure 9.a RKFERENCES We demonstrate methodologies is situations. We evolute methodologies dimensions: fuzziness that each of the relative powerful in f our some the applacability of the in very crude terms by use these of the information requirements complexity of the data system complexity of the actions on the data of the 3y3tem Our view is that the relative value of ISAC are the earlier phases. It is effactive and suitable for fuzzy information reguirements, but it is restricted to not too much complex system because of the restrictions caused by division information and data system into relatively small and simple sub-system3 without any flexible mechanism for integration. We conclude that the Warnier methodology is less powerful in the fuzziness aspect. Then follows JSD methodoIogy. SASD lies somewhere betueen JSD and ISAC which include a powerful special mechanism to manage fuzzines. (See Figure 9.a) JSD is not quite useful for very complex data systeras, but for systeras with many actions, which bring entity from one stage to other, because JSD methodology provide good description technique for showing temporal sequence of actions with three basic components of structured programming (iteration, 3equence, selection), but it does not provide good /CAHE86/ - J. R. Cameron: An overwiev of JSD, IEEE Software Engineering 1986/2. /DEMA78/ - Tom De Marco, Structured analysi3 and system specifioation, Prentice-Hall, NCH Yersey, 1978. /HIGG79/ - David A. Higgns, Program Design and Construction, Prentice-Hall, 1979. /INF083/ - Information Sy3tem3 design methodologies: A Feature • Analysis, Elsevier Science publishing company, Amsterdam, 1983. /JACK83/ - Jackson M. A.:Systera Development, Prentice-Hall, 1983. /LUND81/ - Mats Lundeberg, Goran Goldkuhl, Anders Nilsson: Information Sy3tems Development: A System Approach, Prentice-Hall, 1981. /PORC83/ - M. Porcella, P.Freeman, Ada Methodology Questionarie Summary, ACM Software Engineering Notes, Vol 8, Mol, Januar 1983. /THEI83/ - The Information Structures Subgroup of the Dutch Database Club:' Software Engeneering: Methods and Tehnique3, Wiley Interscience Publlcations International 1983. /YOUR79/ - Vourdon E., Constantine L., Structured design, Fundamentals of a Discipline of Computer Program and Design, Prentice-Hall, 1979.