Data Flow Diagram Insurance Agency by sir19231

VIEWS: 969 PAGES: 50

Data Flow Diagram Insurance Agency document sample

More Info
									     Topics Module 4
The Systems Development
        Process
               (Chapter 12)

   Introduction to Systems Development
   System Development Life Cycle
   System Investigation & Analysis


                                          1
   An Overview of
Systems Development




                      2
Figure 12.2: Typical Reasons to Initiate a
     Systems Development Project




                                             3
Fig 12.3
Participants in Systems
      Development
   Stakeholders
   Business Analysts
   Systems Analysts (/Designers)
   Programmers (Developers)
   Programmer/Analysts
   Users
   Project Managers
   Specialists
                                    5
Fig 12.1
Figure 12.4: The Steps of IS Planning




                                        7
       Developing a
    Competitive Advantage

   Creative analysis
    – New approaches to existing problems
   Critical analysis
    – Improve processes, relationships between
      elements of systems
    – Question assumptions
    – Identify & resolve conflicting objectives

                                                  8
       Establishing
        Objectives
for Systems Development
    Performance objectives
     –   Output quality or usefulness
     –   Output accuracy
     –   Quality/usefulness of format of output
     –   Speed of output generation
     –   System scalability/extensibility
     –   System risk

                                                  9
        Establishing
        Objectives for
    Systems Development
   Cost objectives
    –   Development costs
    –   Fixed investments
    –   Ongoing operating costs
    –   Uniqueness costs
         • Expensive and reusable
         vs. inexpensive but limited
         (scalability/extensibility)
                                       10
Systems Development
     Life Cycles




                  11
Figure 12.6: The Traditional Systems
   Development Life Cycle (SDLC)




                                       12
Fig 12.5
Table 12.2
                Prototyping
   An iterative approach to the systems
    development process

   Operational prototype: a functioning
    prototype that accesses real data files, edits
    input data, makes necessary computations
    and comparisons, and produces real output

   Nonoperational prototype: a mock-up, or
    model, that includes output and input
    specifications and formats              15
Fig 12.7
Fig 12.8
Table 12.3
     Rapid Application Development, Agile
Development, Joint Application Development, and
   Other Systems Development Approaches

         Rapid application development (RAD): a
          systems development approach that
          employs tools, techniques, and
          methodologies designed to speed
          application development

         RAD makes extensive use of the joint
          application development (JAD) process for
          data collection and requirements analysis19
Table 12.4
  Factors Affecting
Systems Development
      Success




                  21
Table 12.5: When to Use
Outsourcing for Systems
     Development




                          22
Table 12.5: When to Use
Outsourcing for Systems
Development (continued)




                          23
Figure 12.9: The degree of change
can greatly affect the probability of
       a project’s success




                                    24
    Project Management

   Project schedule
    – Details of activities, dates
   Project milestone
    – Date of completion of a major
      component/phase
   Project deadline
   Critical path
    – Activities that cannot be delayed without
      affecting the project as a whole
                                                  25
Fig 12.10
System Investigation




                       27
  Systems Investigation

A.K.A. Planning (may include
  “solutioning” and some requirements
  gathering)
PURPOSE: Identify potential problems and
  opportunities and consider them in light of
  the goals of the company.
 Problems to solve

 Opportunities provided

 Identify Costs, risks, other consequences   28
Figure 12.12: The Systems
   Investigation Team




                        29
Feasibility Analysis (p. 503)

Types of feasibility assessments:
 Technical feasibility

 Operational feasibility

 Schedule feasibility

 Economic feasibility

 Legal feasibility




                                    30
Fig 12.12
Systems Analysis




                   32
           Systems analysis
   Purpose is to gather data, understand
    the existing system(s), determine
    requirements, consider alternatives, and
    further investigate feasibility
   Data collection techniques include:
    – questionnaires — structured or
      unstructured
    – interviews— structured or unstructured
    – hands-on evaluation
    – direct observation
    – statistical sampling                     33
Figure 12.17: The Steps in Data
           Collection




                                  34
      Systems analysis
   Data analysis techniques include:
    – data modelling — entity-relationship
      diagram (ERD)
    – activity modelling — data flow diagram
      (DFD)
    – application flowcharts

    – CASE tools to start the project repository
      (project directory)
                                                   35
     Data flow diagrams (DFDs)
   Logical DFDs show how the data should
    flow, regardless of physical
    implementation.
   Physical DFDs show what the processes
    and data are, how those processes are
    implemented, and how the data are
    represented.

                                            36
                  Data flow
               Diagrams (DFDs)
   Four symbols on a DFD (logical or physical) are:
    – process — shown as a rounded rectangle with a
      label inside; represents the action that transforms
      data
    – data flow — a line with an arrow-head and a label
      along the line showing the flow of information
    – data store — a narrow open-ended rectangle with a
      label inside; represents a collection or repository of
      information, such as a file cabinet or database
    – external entity — a square box with a label inside;
      represents the source or destination of data
                                                           37
         Data flow
      Diagrams (DFDs)
   DFDs can be decomposed into different
    levels of detail for clarification.
   To supplement DFDs, a data dictionary
    is used to store information about each
    data flow, process, data store, and
    entity, so that a user or an analyst can
    find the meaning and other details of a
    particular element.


                                               38
Process Modeling and DFDs

 Process modeling is a technique for
 organizing and documenting the structure and
 flow of data through a system’s processes,
 and/or the logic, policies, and procedures to
 be implemented by a system’s processes.
 A data flow diagram (DFD) is a tool that
 depicts the flow of data through a system and
 the work or processing performed by that
 system.
                                                 39
Simple Data Flow Diagram




                           40
         Process Concepts
.
    A process is work performed on, or in
      response to, incoming data flows or
      conditions
    Symbol is an oval or a rounded
      rectangle

                   A
                Process



                                            41
                    Data Flows

   A data flow represents an input of data to a
    process, or the output of data from a
    process.




                                                   42
External Agents (Source or Sink)
                            External
    An external agent defines a person,      Agent

     organization unit, or other organization that
     lies outside of the scope of the project but
     that interacts with the system being studied.
     – External agents define the ―boundary‖ or scope
       of a system being modeled.
     – As scope changes, external agents can become
       processes, and vice versa.
     – Almost always one of the following:
        • Office, department, division inside the business but
          outside the system scope.
        • An external organization or agency.
                                                                 43
                         Data Stores

                        Data
                        Store


   A data store is an inventory of data.
    – Implemented as a file or database.
    – A data store is ―data at rest‖ compared to a data flow that
      is ―data in motion.‖




                                                               44
Illegal Data Flows




                     45
The Travel expense accounting system for a large insurance
company works as follows:

An employee fills out a travel expense form (TEF) and sends it
along to the accounting department with appropriate receipts. A
clerk in the accounting department checks the TEF and matches
up the receipts with the data on the form. If any receipts are
missing, a request for receipts is sent back to the employee.
Approved receipts are filed in the approved receipts file. The
approved TEF is sent to a data entry clerk who enters the data in
the computer file called Travel Expense File. Once a week, a
computer program is run which produces the travel expense
reimbursement cheques from data in the Travel Expense File.
The cheques are sent to the proper employee. Once a month,
another computer program is run which uses the Travel Expense
File to produce the travel expense report for top management.
       Systems analysis
     requirements analysis
   The requirements analysis task is
    undertaken to determine the needs of the
    users, stakeholders, and the organization,
    and to translate these into detailed
    systems requirements. Techniques
    include:
    –   asking directly
    –   critical success factors
    –   IS plan
    –   screen and report layouts                47
            Systems analysis
                 report
   The systems analysis report is the result
    of this phase and should include:
    – strengths and weaknesses of the existing
      system
    – user/stakeholder requirements —
      functional specifications
    – organizational requirements for the new
      system
    – a description of what the system should
      do to solve the problem
                                                 48
Fig 12.20
Questions (?)




                50

								
To top