1 / 114

Overview

Overview. What is system analysis and design? Tools and models Methodologies. Information Systems. What is a system? Why do systems fail? What is systems analysis and design? How do we do systems analysis?. What is a system?. A collection of parts that work together

melvyn
Télécharger la présentation

Overview

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. Overview • What is system analysis and design? • Tools and models • Methodologies

  2. Information Systems • What is a system? • Why do systems fail? • What is systems analysis and design? • How do we do systems analysis?

  3. What is a system? • A collection of parts • that work together • to achieve a goal/task

  4. What is an information system? • Parts? • Usually on of the parts is a computer • Task? • The difficulty is getting the parts to work together

  5. Complexity in Systems • IS are needed for large/complex tasks • Solve complexity by partitioning • More parts  More interaction • More interaction  Complexity

  6. Bad Systems • Fail to meet requirements • Poor performance • Poor reliability • Unusability

  7. Badly Produced Systems • Not to schedule • Not to budget • Runaway = 100% over budget or schedule

  8. Reasons for Failure • Complexity • Shifting requirements • Bad estimation • Bad management • New technology

  9. Need for Structure • Must tackle complexity • Structure partitioning of problem • Organised interaction of parts • Ensure you achieve the task

  10. System Development Life Cycle • An ordering of a set of system development activities/phases. • Can be either sequential (serial) or non-sequential (e.g. contingent). • Contains guidance on how to progress from one phase to the next

  11. Generic development phases: Initiation Development Implementation Operation & Maintenance

  12. Links between phases: Problem statement; “vision” scenario, requirements Initiation Executables, user documentation etc Development Changes in scope, schedule, etc. An operational IS Implementation Design or programming errors Operation & Maintenance Implementation glitches: e.g. missing requirements

  13. Standard System Life-cycle Problem Definition Feasibility Study System Analysis System Design Physical Design Implementation Maintenance

  14. System Development Life-Cycle • Stages  Milestones • Output/product/deliverable • Waterfall technique • Distilled experience

  15. Systems Analysis and Design • Central to the life-cycle • Analysis: defining the problem • From requirements to specification • Design: solving the problem • From specification to implementation

  16. Models • Representations • Simplify reality • Require training • Appropriate to problem

  17. Models in Analysis and Design • Focus ideas • Aid communication with user • Highlight omissions and errors • Blueprint for the system

  18. Good Models • Maintainable and disposable • CASE tools • Graphics v. Text • Understandable

  19. The Main Models • Entity relationship diagram • Data-flow diagram • Entity life-history

  20. Some Remarks • All three models represent the same system • There is no unique correct model • Need more than one attempt

  21. Case Studies • Replace requirements • Informal • Ambiguous • Realistic! (Nearly) • Estate Agent System in handbook

  22. Entity Relationship Diagrams • Centrality of data • DBA and DA • Represents structure of data • Shows relationships within data

  23. Focus in ER diagrams • Structured • Logical • Process independent • Minimal

  24. Components of ER Diagram • Entities with lists of attributes • Occurrences as set of values • Relationships • two directions - two sentences • degree • optionality

  25. Entity • Block of information • Represents a type of thing • Occurrences are instances of the entity Student

  26. Attributes • Belong to an entity • Simple item of data • Values are the data for an occurrence • Candidate keys and primary keys

  27. Entities as Tables

  28. Relationships • Show how entities affect each other • Two directions - two sentences

  29. Degree • Number of occurrences in relationship • Remember two directions • Three types: • one to one • one to many (or many to one) • many to many

  30. Resolving Many-to-manys • Hide information • Difficult to physical represent

  31. Resolving Many-to-manys

  32. Optionality • Optional - relationship MAY hold • Mandatory - relationship MUST hold • Two directions

  33. Components of ER Diagram • Entities with lists of attributes • Occurrences as set of values • Relationships • two directions - two sentences • degree • optionality

  34. Building ER Models • Based entirely on requirements • Process must be repeated several times • Alternative to normalisation

  35. Steps to ER modelling • Identify entities • List attributes • Identify relationships • Repeat several times

  36. Identify Entities • One or two obvious ones • Use nouns in case study • entity or attribute • Not the whole system!

  37. List Attributes • Again obvious ones for some entities • Use nouns in case study • complex attributes might be entities • Use imagination • for deliveries need addresses • for phone calls need phone numbers

  38. Identify Relationships • Consider each pair of entities • Begin drawing • Consider degree • Consider optionality • Resolve many-to-manys

  39. Repeat • Is there enough data to do the job? • Identify new entities and attributes • Fit them to existing model • Do it again!

  40. Representing Relationships • Each entity needs a primary key • Use a foreign key for many-to-one • The “many” entity has a foreign key attribute • One-to-ones are rare or incorrect!

  41. Validation • Is there any repetition of data or relationships? • Are all attributes and entities relevant? • Are all many-to-manys resolved? • Are the one-to-one relationships sensible?

  42. The Data-Dictionary • Description of ALL information on EVERY item of data • Precisely defines the diagrams • Adds new detail • Backbone uniting all diagrams

  43. ERD and Dictionary • Description of every entity • Lists of attributes & descriptions • Volumetrics • Description of relationships

  44. DD Notation • = consists of; + sequence • { } repetition; ( ) optional • [ ] selection between alternatives • | alternative separator • *….* comments

  45. Example DD entry • CustomerDetails = • Title + {initial} + Surname + Address + (CustomerPhone) • Title = [Mr|Mrs|Ms|Dr|Rev] • Address = [Number|Name] + Street + {District} + (PostCode)

  46. Data-flow Diagrams • Clarify requirements • Represent processes • Interaction between processes • Non-technical yet formal

  47. Focus in DF diagrams • Data input to the system • Data output from the system • Movement of data between processes • Storage of data within system • Top-down decomposition

  48. Customer Customer External Entities • Provides inputs, receives outputs • Different from Logical Data Structure • Represent types of things

  49. StockInventory Data-flows • Movement of data between processes • No change of data during flow • One end MUST attach to a process

  50. Processes • Main feature of DF diagrams • Change data • Appear as boxes:

More Related