290 likes | 556 Views
Identifying system improvements: Logicalisation. Information System Analysis COMM1B Unit 13. Identifying Potential System Improvements. Examining an existing system can lead to the identification of the potential for improved processing activity.
E N D
Identifying system improvements: Logicalisation Information System AnalysisCOMM1B Unit 13
Identifying Potential System Improvements Examining an existing system can lead to the identification of the potential for improved processing activity. This often results in: Construction of a modified model to support this change.
Identifying possible system improvements • Problems lead to requirements • (See Unit 14) • Requirements Catalogue • Operational and Strategic Objectives may bring about change • Covered in COMM1F • Business Process Re-engineering (BPR) • Process Improvement for Strategic Objectives (PISO) • Start with logicalisation of current system
System Modelling • Why model the current system? • Develop an understanding and feel for the information system • Systems adapt and evolve over a period of time • Often results in a system which does not fully reflect what the system was intended to do • The old system may need to be changed or even replaced to accommodate new business requirements
Current System Model • Current Physical Model • Describes how the present system is implemented • Current Logical Model • Reflects the policy behind the system • without the physical circumstances and constraints of the existing system • forces the analyst to think logically and abstractly • forms the basis for the specification of the required system
Stages of Systems Analysis and Design Investigate and analyse system CurrentPHYSICALSystem Model Perform Logicalisation CurrentLOGICALSystem Model Add New System Requirements, Consider Business System Options RequiredLOGICALSystem Model Add Implementation Details, Consider Technical System Options RequiredPHYSICALSystem Specification
Logicalisation • The beginning of the ‘transformation’ of the old system to the new system • Mainly involves reconstructing the set of levelled DFDs • Physical DFDs show • What is done, • Where and • How it is done, • Who does it • Logical DFDs only show • What is done • Refined entity model after normalisation
Simple Example of Physical level 1 DFD Party details 1 You M1 Diary Discuss party details and record interest Person details Party enquiry Party details M2 Phone directory Colleague Party invitation 2 You response Invite guest by telephone Tickets * 3 You M3 Address Book Produce and send out tickets to party M1 Diary
Logicalised level 1 DFD Party details D1 Party Data 1 Colleague Communicate and record party data Party/contact data contact details D2 Contact Data
Example • The following example of a student assessment system is used to illustrate the technique of logicalisation • taken directly from Lejk and Deeks, chapter 9
Steps in Logicalisation • Step 1- Rationalise Data Flows • Remove all reference to physical items eg. tickets, order form etc. • Replace with actual data being passed eg. order details
Physical Application form Student record Assignment and exam marks Stamped addressed envelope Pink top copy Logical Application details Student details Student marks Request for results Order details Rationalise Data Flows
Steps in Logicalisation • Step 2 - Rationalise Data Stores • An entity must be represented by one and only one data store • a logical data store may represent a logical grouping of entities • Remove any reference to a physical storage facility and prefix with D identifier • eg. Appointments Diary becomes Appointments • transient data stores should be removed (but may reappear in the required physical DFD, eg. for batch processing)
Guidelines for Data Stores • Logical data stores typically contain entities: • that are created at the same time • that are linked via relationships • whose attributes form part of the same major input/output data flows
Steps in Logicalisation • Step 3 - Rationalise bottom level processes • Remove all reference to location or responsibility, i.e. leave it blank • Remove processes which re-organise existing data e.g. sorting or collating data • Processes 4.1 and 4.2 are no longer needed • Where a process remains clerical or exists simply for physical reasons, remove it. Replace with an external entity, eg. Process 1 - preparation and marking of assessments by Subject Tutor • Subject Tutor becomes an external entity
Rationalise Bottom Level Processes • Remove processing that cannot be automated i.e. a process which requires subjective or expert decisions e.g. awarding a degree • Process 3, moderate and finalize results by Board of Examiners • reviews student results • takes account of mitigating evidence • arrives at a consensus decision • the “doers” of such processes become external entities of the system so Board of Examinersw (BOE) becomes an external entity
Rationalise Bottom Level Processes • If data is unaltered by a process replace it with a data flow • Remove any physical aspects of the process • e.g. add reservation in red becomes confirm reservation • Combine processes which perform the same function or duplicated processes • Combine related processes (often connected by direct data flows between them)
Guidelines for Processes • Split over-complex processes into simpler processes • Regroup “bottom level” processes • by function rather than location • Reconstruct the resultant top level DFD
Further Reading • Lejk and Deeks • An Introduction to Systems Analysis Techniques • Chapter 9 Logicalisation • Philip L Weaver • Practical SSADM version 4 Pitman Publishing • Chapter 3 p 112-115