Download
1 / 39
431 likes | 501 Views
Chapter 20. Process-Oriented Methodologies. Learning Objective. Deepen your understanding of system design philosophy/methodology Understand the roles of different methods and know where & when to apply them. Process-Oriented Methodologies. First proposed by Gane & Sarson (1979)
E N D
Chapter 20 Process-Oriented Methodologies
Learning Objective • Deepen your understanding of system design philosophy/methodology • Understand the roles of different methods and know where & when to apply them
Process-OrientedMethodologies • First proposed by Gane & Sarson (1979) • The main techniques used are • functional decomposition • data flow diagrams • decision trees • decision tables • structured language
Structured analysis, design, and implementation of IS (STRADIS) • Introduced by Gane and Sarson (1979) • Structured design is concerned with the selection and organization of program modules and interfaces that would solve predefined problem • but does not tackle with the problem definition for practical reasons • Original version did not set concrete steps, rather a set of techniques which the methodology utilizes
Initial study Detailed study Defining and designing alternative solutions Physical design overview DFD of existing system, estimates of time, costs and benefits, report to determine if proceed to next stage detailed investigation of existing system, current logical DFDs, statement of costs/benefits, impact on staff/procedures system objectives, new logical DFDs, alternative design options transform/transaction analysis, normalisation, physical file/DB design, design details of error handling, report and screen formats etc. STRADIS Lifecycle The methodology is based on the philosophy of top−down functional decomposition and relies on the use of Data Flow Diagrams
Initial study (2days-2weeks) • to ensure the systems are the most appropriate in the environment • criteria to select: monetary costs & benefits of each proposal • systems are to increase revenues, avoiding costs, or improve services • include: • data from managers & users, analysis of documentation, writing a proposal in light of strategic plans • overview of dataflow diagrams & its interfaces • initial estimation of time and costs • difference to traditional feasibility studies: no alternative approaches are reviewed, not as broad as a feasibility study • these are addressed later!
Detailed study • existing systems are examined in details • potential users are identified and interviewed • senior managers (has the money) • middle managers (has the power within target depts.) • end-users (has the “need”) • a data flow datagram of (current) system and a data dictionary (in details) are created • beyond system boundaries to see what they are and where they are • refining the costs and benefits of the system • investigating the assumptions on which the estimates are based on
Defining and designing alternative solutions (to the existing systems) • organizational objectives are converted to a set of system objectives • high-level objectives having an effect to an organization • system objectives should be clearly stated (specific and measurable) • analyzing these objectives produces a logical data flow diagram of the new system • analysts & designers work together to produce alternative implementation designs • low-budget, quick implementation • mid-budget, medium-term version • higher-budget, full implementation • each alternative includes • estimates of costs, benefits, timescales & hw & sw • the parts of DFD to be implemented • UI design • risk analysis • a board to decide which alternative to proceed
Physical Design • details of dataflow diagram • including error handing, exceptions, process logic, UI, etc. • database design • modular design from the DFD • all these are brought up to a level where a firm estimates of costs can done • implementation and testing time • system requirements • documentation and training • users time used in interacting with the system • maintaining the system
Detailed study • A definition of the user community for a new system, that is, the names and responsibilities of senior executives, the functions of affected departments, the relationships among affected departments, the descriptions of clerical jobs that will be affected, and the number of people in each clerical job, hiring rates, and natural attrition rates • A logical model of the current system, that is, an overall data flow diagram, the interfacing systems (if relevant), a detailed data flow diagram for each important process, the logic specification for each basic process at an appropriate level of detail, and the data definitions at an appropriate level of detail • A statement of increased revenue/avoidable cost/improved service that could be provided by an improved system, including the assumptions, the present and projected volumes of transactions and quantities of stored data, and the financial estimates of benefits where possible • An account of competitive/statutory pressures (if any) including the system cost and a firm cost/time budget for the next phase (defining a menu of possible alternatives)
STRADIS: Stage 3 report • A DFD of the current system • The limitations of the current system, including the cost and benefit estimates • The logical DFD of the new system For each of the identified alternatives, the design will include statements covering: • The parts of the DFD that would be implemented • The user interface (terminals, reports, query facilities, and so on) • The estimated costs and benefits • The outline implementation schedule • The risks involved
STRADIS: Physical design • The professional time and computer test time required to develop the identified modules • The computer system required • The peripherals and data communication costs • The professional time required to develop user documentation and train users • The time of the users who interact with the system • The professional time required to maintain and enhance the system during its lifetime
STRADIS - Summary • summary • phases clearly defined in analysis, with lesser interest in design, hardly anything on implementation • does not tackle with • implementation & testing plans • concurrent development of different parts of the system • ensuring user acceptance • ensuring the performance criteria is met • etc.
Yourdon Systems Method (YSM) (very similar to STRADIS, but uses event partitioning which is claimed to be neither top-down, nor bottom-up but ‘middle-out’) (Yourdon 1993)
YSM Features • Based around a set of models which abstract the main features of what is under examination and then present those features in a useable way • Enterprise Model • System Essential Model
Enterprise & System • An enterprise is an economic unit that is resourced and managed as a unit • A system is a collection of information and operations that are organized to meet a specific problem. • Enterprise is not a system. Has a longer life-span than a system. Within an enterprise, several systems may be developed, used and replaced.
Viewpoints of a System YSM takes 3 orthogonal viewpoints: • Function: what the system does. DFDs are used here. • Time: what happens and when (Use an Event List that shows what happens to which system must respond). • Information: what information is used by the system. (use ER models for this)
Upward and downward levelling of YSM DFD Event partitioning describes ‘events’ in the environment to which the system must respond. A ‘first cut’ data flow diagram is then levelled upwards if there are too many processes (functions) at that middle level, and the aggregate processes (functions) are used to represent a single process (function) in a higher level data flow diagram. Similarly downward levelling decomposes middle level processes (functions) where these are found not to be at their most primitive level.
Jackson systems development (JSD) • JSD does not start from a given specification, nor does it decompose the system into sequential processes. Instead, development begins by creating a specification for the system, building it up from parts which are themselves sequential processes
Jackson systems development (JSD) • “systems development is an extension of the program design task … the same techniques can be applied to both” (Jackson 1983) • system can be seen as a large program • significant impact on the practical programming • focuses on efficient and well-tested software • attempts to solve “hidden path problem” • i.e. the path from systems specifications to complete system is unclear and too long, and when validating the spec, it is too late and incomplete • addresses this through process scheduling and real-world modeling • particularly dynamic modeling (not static as the other methodologies) • JSD does not deal with • project selection, cost justification, requirements analysis, project management, UI, procedure design, or user participation
Jackson systems development (JSD) Modelling phase 1. Entity action step 2. Entity structure step Network phase 3. Initial model step 4. Function step 5. System timing step Implementation phase 6. Physical system specification step
Entity action step • modeling real world entities (supplier, customer, etc.) • modeling the behavior of an entity (rather than its attributes or relationships) • object has to • perform (or suffer) actions in a significant time ordering • exists in the real world (outside the system) • be able to instantiate (i.e. to have unique name) • action must • be taking place at a point of time (not over a period of time) • take place in real world (outside the system, not within the system) • action is regarded as atomic
JSD structure diagram – simultaneous operation of many accounts
Structured analysis • Structured analysis is a process-oriented approach. The technique is simple in concept: the analyst defines what the system should do before deciding how it should do it. New systems specifications evolve from a series of data flow diagrams and process/data narratives. The diagrams show the flow and storage of as well as the processes that respond to and change data.
Table 1: Methodology Phases Mapped to Conventional SE Activities and Phases Source: http://www.unisa.edu.au/seec/pubs/03papers/cropleyLWC2003final.pdf
References • Structured Analysis, Design and Implementation of Information Systems (STRADIS) (Gane and Sarson, 1979) • Yourdon Systems Method (YSM) (Yourdon, 1993) • Jackson Systems Development (JSD) (Jackson, 1975; 1983)
End of Chapter 20 Thank You for Your Attention
