ISM 6121

1
ISM 6121

• Advanced Systems Analysis and Design
• A Review

2
Systems Analysis Is

• Structured Process
• Problem Identification
• What is the Problem?
• Proposed Solution
• What is the best fix?
• In the form of an IS
• What do you think of the use of Problem
  throughout the chapter?

3
Systems Design Is

• Design and Implementation
• How do we transform the solution into a working
  IS?
• Coding
• Implementation
• Maintenance

4
Back to SAD

• Uses a Formal set of Elements to
• Identify Problem
• Find the Solution
• Implement the Solution
• Views the problem from a Systems perspective

5
What is the Definition of a System?

• An inter-related set of components
• With an identifiable boundary
• Working together for some purpose

6
What are the Characteristics of a System?

• Components
• Inter-related components
• A Boundary
• A Purpose
• An Environment
• Interfaces
• Input
• Output
• Constraints

7
A General Depiction of a System
8
A Fast Food Restaurant as a System
9
Information System Depicted in a Data Flow Diagram
10
Formal Elements of SAD

• Methodology
• Tool
• Technique

11
Some Definitions

• Methodology - a body of methods , rules, and
  postulates employed by a discipline a
  particular procedure or set of
  procedures
• Methods a procedure or process for attaining an
  object a systematic procedure, technique, or
  mode of inquiry employed by or proper to a
  particular discipline or art.
• ISM 4113 Methodology
• SDLC

12
More Definitions

• Tools something (as an instrument or apparatus)
  used in performing an
  operation or necessary in the practice of a
  vocation or profession
• Ishikawa chart, PIECES framework
• DFDs, ERPs, decision trees
• CASE tools

13
Last One

• Techniques a body of technical methods (as in a
  craft or in scientific research) a method of
  accomplishing a desired aim
• Data Gathering, Requirements Determination,
  Project Planning, Feasibility Analysis

14
A Little Demo.

• http//www.foodtv.com/video/knifemince/0,5053,,00.
  html

15
SDLC
16
Preliminary Investigation

• Key Activities
• Problem definition
• Estimate problem scope
• Estimate project feasibility
• Estimate resource commitment
• Go/no go decision

• Primary Deliverables
• Preliminary feasibility report
• General problem statement

17
Analysis

• Key Activities
• Create logical models of current system
• Refine problem statement via detailed symptom
  analysis
• Determine requirements for new system

• Primary Deliverables
• DFD of current system
• ERD of current system
• Formal problem statement
• Formal requirements definition

18
Logical Design

• Key Activities
• Revise current system logical models to reflect
  proposed system changes
• Validate logical model of proposed system against
  requirements determination

• Primary Deliverables
• DFD of proposed system
• ERD of proposed system
• Final performance specifications

19
Physical Design

• Key Activities
• Determine hardware specifications
• Determine software specifications
• Conduct feasibility analysis and cost
  justification for new system
• Estimate implementation schedule
• Design data structures
• Prepare training guidelines
• Prepare preliminary testing procedures

• Primary Deliverables
• Detailed hardware specifications
• Detailed software specifications
• Final feasibility report
• Physical data structures and data dictionary
• Implementation schedule

20
Implementation

• Key Activities
• Acquire hardware and software
• Determine location requirements
• Install the new system
• Create test data and conduct initial system tests
• Train all end users
• Verify all end user and system documentation

• Primary Deliverables
• Final performance test metrics
• Fully trained end user community
• Fully installed system
• Fully converted data files

21
Tom DeMarco Structured Analysis

• What I Thought I Knew in 1975
• 1. Narrative specs are dumb nor inform
• These Victorian Novel specifications neither
  specify nor inform
• 2. Four-stage modeling
• A dataflow representation of a system is a model
  and the analysis life-cycle consists of building
  a sequence of these models showing four different
  stages
• 3. Dataflow is the essential view
• The point of view of the data as it passes
  through the system is the most useful
• 4. Top-down partitioning
• Top-down is good bottom-up is evil
• 5. Loose connection criterion
• The validity of any partitioning is a function of
  how thin the interfaces are
• 6. Defined process of analysis
• System analysis always has the same well-defined
  steps
• 7. Pseudo-coded minispecs
• The lowest level is defined in a formal way
• 8. Work at the users desk
• Analysts shouldnt hide in their own offices the
  real work of analysis is at the users desk
• 9. Philosophy of iteration
• You can never get it right on the first try
  success comes from numerous iterations, each one
  better than the last

22
Principle Revised Commentary (as of 2001)

• 1. Narrative specs are dumb
• Narrative specs are not the problem a suitably
  partitioned spec with narrative text used at the
  bottom level makes a fine statement of work
• 2. Four-stage modeling
• The four stages I proposed in 1975 were far too
  time consuming
• 3. Dataflow is the essential view
• Dataflow is one of the essential views, not the
  only one
• 4. Top-down partitioning
• Partitioning is essential in dealing with
  anything complex, but top-down partitioning is
  often far too difficult to achieve and not at all
  the great advantage it was touted to be
• 5. Loose connection criterion
• This is an important truth when youre attacking
  complexity by partitioning, the thinner the
  interface, the better the partitioning if the
  interfaces are still thick, go back and partition
  again, searching for the natural seams of the
  domain

23
Continued

• 6. Defined process of analysis
• Defined process is a holy grail that has never
  yet been found and probably never will be
• 7. Pseudo-coded minispecs
• Its useful to partition the whole and then
  specify the pieces, but pseudo-code was an awful
  mistake (puts analysts into coding mode when they
  should be busy analyzing)
• 8. Work at the users desk
• Analysts have a tendency to hide at their own
  desks, but much of the action is in the business
  area and they need to venture out to find it
• 9. Philosophy of iteration
• We never get it right the first time the best we
  can do is improve from one iteration to the next
  if we can continue to do this at each iteration,
  we can get arbitrarily close to a perfect product
• 10. The customer is king
• True, but partnership between customer and IT is
  now as important
• tightly merged amalgam of business and
  technological expertise.