1 / 14

IMS1805 Systems Analysis

Recap of the last three lectures on the importance of understanding analysis purposes, different types of models, and common issues in process, data, soft systems, and O-O modeling.

hugol
Download Presentation

IMS1805 Systems Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IMS1805Systems Analysis Topic 3: Doing analysis (cont)

  2. Recap of last three lectures • The importance of understanding the purpose of analysis • Some important purposes: • Organisational; • Technological; • Development team • The purposes behind various types of models (FDD/DFD/ERD/O-O/Soft systems)

  3. Agenda • Aim: To develop further your skills in using analytical techniques • To identify some of the main problem areas students have in applying these techniques

  4. 1. Issues in process modelling: (a) physical vs logical models • Physical actions versus information transformations • People/places/times vs logical information events • Note: Physical models are not ‘wrong’ – unless you are asked for a logical model! • Why bother with the distinction? The importance of “seeing” pure information elements, not physical objects • Examples from tute exercise

  5. Issues in process modelling: (b) actions and data flow elements • Relating physical actions to information processes • Understanding/interpreting actions as data flow elements other than processes • Seeing the overall picture: recognising the problems arising from poor process selection and re-thinking the process • Examples from tute exercise

  6. Issues in process modelling: (c) hierarchy and abstraction in processes • The concept of hierarchy of processes • Low-level vs high-level processes • Composite (multi-process) processes vs single processes • Implications for process names • Why bother with the distinction? The importance of “seeing” both top and bottom level processes • Examples from tute exercise

  7. Issues in process modelling: (d) naming data flow elements • ‘Bad’ names vs ‘good’ names • Processes = verb + name (what transformation occurs + what data is transformed) • High-level process names vs low-level process names • Names as a clue to how clearly you are thinking • Examples from tute exercise

  8. Issues in process modelling: (e) testing your process model • Putting the pieces together for an FDD: • Every element of the diagram is a process • Every low-level (child) process is a component of its associated higher-level (parent) process • Every high-level (parent) process is fully described by its associated lower-level (child) processes • Putting the pieces together for a DFD: • Every process must have data inputs and data(/info) outputs • Every data input/output must have a process at one end and either a process, data store or external agent at the other end • All inputs must be used by a process to create all its outputs • Processes ‘fit together’ in the same levels as in the FDD • Examples from tute exercise

  9. 2. Issues in data modelling: (a) choosing your entities • ‘Things’ which are involved in or part of the system vs ‘things’ about which the system needs to store information • The first test for any entity: what are its attributes? (ie what does this system need to store as information about it (and why)?) • Seeing an entity as a table in a database • Examples from tute exercise

  10. Issues in data modelling: (b) distinguishing attributes and entities • Features which are inherently part of something (attributes) vs features which are connected/related to it.(Perhaps a different entity or an attribute of a different entity?) • The first test for any attribute: does it have attributes as well? (ie does this system need to store as information about it?) If so, should it be an entity in its own right? • Seeing an attribute as a field (column) in a database record • Examples from tute exercise

  11. Issues in data modelling: (c) identifying relationships • What connections does the system need to be able to make between entities? • Seeing a relationship as the basis for setting rules for a database to enforce about its entities • Seeing a relationship as the basis on which queries can be built between database tables • Examples from tute exercise

  12. 3. Issues in soft systems modelling: (a) identifying stakeholder positions • Do all people involved in a system have attitudes towards it OR are people neutral users who simply supply/extract information? • Do people involved in a system have ‘rights’ which should be acknowledged and taken into account? • Is it sensible to ignore people’s attitudes/rights towards a system? • Examples from tute exercise

  13. 4. Issues in O-O modelling: (a) identifying objects • How easy is it for you to identify: • Actions? • Processes? • Entities? • How easy is it for you to identify objects? • How easy is it to create objects from composites of processes and entities? • Examples from tute exercise

  14. Administration • Assignment documents • New assignment deadline • No lecture on Monday, August 29th

More Related