1 / 25

Lecture 9: Structured Systems Development

Lecture 9: Structured Systems Development. MIS 160 Systems Development Life Cycle I. Structured Development. Based on the principles of: top-down decomposition process driven Structured programming Structured design Structured analysis. Systems Development Life Cycle Waterfall Model.

ide
Download Presentation

Lecture 9: Structured Systems Development

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. Lecture 9:Structured Systems Development MIS 160 Systems Development Life Cycle I Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  2. Structured Development • Based on the principles of: • top-down decomposition • process driven • Structured programming • Structured design • Structured analysis Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  3. Systems Development Life CycleWaterfall Model Project Identification and Selection Project Initiation and Planning Analysis Logical Design Physical Design Implementation Maintenance Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  4. Advantages of Structured Development • Been used successfully for over 20 years • Provides a clear framework that defines and divides important activities • Can be applied to both small and large projects • Division of labor is easier to facilitate Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  5. Limitations of Structured Development • Specification problems • assumes that development is a sequential process • Changing requirements • requirements specified at the beginning • assumption that requirements will not change • Conceptualization and visualization • document led methodology • volume of documentation can be huge • Inaccuracy • there is only downward trend Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  6. Approaches to Structured Development • Gane and Sarson • uses data flow diagrams • data dictionaries, process descriptions, file layouts • Yourdon and DeMarco • similar to Gane and Sarson • difference in the symbols that are used Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  7. Data Flow Diagrams • Process-oriented approach • examines inputs, outputs, and processes of a system • purpose is to show the flow of information through a system • 4 Sets of DFDs: • Physical DFDs of current system: show how the current system works • Logical DFDs of current system: show what the system currently does • Logical DFDs of proposed system: show what the new system must do • Physical DFDs of proposed system: show how the new system works Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  8. Structured Approach Sequence • Hierarchical Chart • Physical DFD current system (WHAT/HOW) • Logical DFD current system (WHAT only) • Logical DFD proposed system (revised WHAT) • Physical DFD proposed system (revised WHAT/HOW) Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  9. Hierarchical Chart • Terms: • parent,child,sibling • functional primitive • control module Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  10. Hierarchical Chart Main 1.0 2.0 3.0 4.0 5.0 4.1 4.2 Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  11. Data Flow Diagram (DFD) • Purpose: communication with user • Components: • external entities (sources, sinks) • processes (subprograms) • data stores (files) • data flows (forms) Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  12. Data Flow Diagram (DFD) Symbols Gane & Sarson Yourdon process data store source/sink data flow Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  13. Definitions • Process • The work or action performed on the data • Data store • data at rest • represents a physical location for a file (e.g., file folder, computer file) • Data flow • direction in which data moves • labeled with a name for data in motion Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  14. Definitions • Source/sink • origin (source) of the data • destination (sink) of the data • sometimes referred to as external entities (outside of the system) • Do not consider the following • interactions between sources and sinks • what source/ sink does with the information • design/redesign of source/sink • direct access of source/sink to stored data Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  15. A Simple Sample 1.0 Prescription Hospital Pharmacy System Tech Review Prescription 2.0 Patient Info Unfilled Order Info. Review Prescription Doctor D1 Patient File Unfilled Response Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  16. DFD Rules:Processes • No process can have only outputs. It is making data from nothing (a miracle). If an object has only outputs, it must be a source. • No process can have only inputs (a black hole). If an object has only inputs, then it must be a sink. • A process has a verb phrase label. Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  17. 1.0 1.0 DFD Rules: Processes Member Member information Recruit Members Black hole Member Membership Recruit Members Miracle Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  18. DFD Rules: Data Stores • Data cannot move directly from one data store to another data store. Data must be moved by a process. • Data cannot move directly from an outside source to a data store. Data must be moved by a process which receives data from the source and places the data into the data store. • Data cannot move directly to an outside sink from a data store. Data must be moved by a process. • A data store has a noun phrase label. Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  19. D1 D2 D2 D2 Memberships Memberships Memberships Members DFD Rules: Data Stores Member Renewal notice Membership Information Member Renewal notice Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  20. DFD Rules: Sources/Sinks • Data cannot move directly from a source to a sink. It must be moved by a process if the data are of any concern to our system. Otherwise, the data flow is not shown on the DFD. • A source/sink has a noun phrase label. Member Clerk Member information Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  21. Context Level Department Staff 0 Course Information Course Registration System Fees data Financial Office Course Offerings Course Information Student Enrollment Information Schedule Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  22. Level 0 1.0 Course offerings Course offering changes Maintain Course Offerings Department Staff Course offerings Course offering list D1 Course offerings Available courses Financial Office Fee payment history 2.0 Available course req. Available courses. Maintain Student Enrollment Student Course enrollment Course enrollment req. Schedule D2 Enrollments Student schedule Enrollment information 3.0 Report request Department Staff Create Reports Report Course information D1 Course offerings Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  23. Level 1: Process 3 3.1 Obtain Report Type Report request Report Type Department Staff Course information 3.2 D1 Course offerings Report Create Reports Enrollment information D2 Enrollments Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  24. Models and Modeling • Models are frequently used for documenting functional requirements • Created during analysis activity phase called ‘define system requirements’ • Focus on events and things • Models are used in both the traditional and object-oriented approach Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

  25. Models and Modeling • Analyst describes information system requirements using a collection of models • Complex systems require more than one type of model • Models represent some aspect of the current system/ system being built Sylnovie Merchant, Ph.D. MIS 160 Section 2 Spring 2004

More Related