SENG 520 Fall 2006

1
SENG 520 Fall 2006

• Lecture 7

2
The Analysis Process

• We have discussed life cycles
• We have discussed approaches to eliciting
  requirements
• We have discussed modeling tools
• Now that you have the data and you have a set of
  modeling tools, what kind of models should you
  build?

3
Our Goals for this Lecture

• Discuss the four major system models in the life
  cycle
• Understand why modeling the users current system
  can be dangerous
• Understand differences between essential and
  implementation models

4
Classical Modeling

• Discussed the basis of a model in a previous
  lecture
• Copy of a complex system
• A model should
• Be graphical, with appropriate supporting textual
  detail
• Allow the system to be viewed in a top-down,
  partitioned fashion
• Have minimal redundancy
• Help the reader predict the systems behavior
• Be transparent to the reader

5
Four System Models

• Develop four distinct models

Project
Develop Current Physical Model
Current physical model
Develop Current Logical Model
Current logical model
Develop New Logical Model
New logical model
Develop New Physical Model
New physical model
6
Current Physical Model

• Model of the system currently in use
• System model
• Manual or automated or mix
• Recognized by characteristics of the DFD
• Data stores often file cabinets or folders
• Process names may be names of people or
  organizational units
• Data flow is often physical

7
Current Logical Model

• The pure or essential requirements of the current
  system
• Implementation details are removed
• What the system would do if perfect technology
  was available
• Zero-cost, zero-space unlimited computing
  resources

8
New Logical Model

• The pure or essential requirements of the new
  system that the user wants
• Ideally same as the current logical model
• Contains the same functions and the same data
  easy generation
• May happen when user has all the functionality
  needed but did not like implementation
• Often new functionality is added
• Mostly same as current logical model
• Likely that there are some changes

9
New Physical Model

• Shows implementation constraints imposed by user
• Important to show automation boundary
• What is automated
• What is manual
• Becomes the user implementation model

10
Classical Problems

• Approach based on three major assumptions
• Analyst may not be very familiar with the domain
  (business area or application)
• Current physical model is an educational tool
• It will be a simply model with specifics from
  the current user environment
• User may be unwilling or unable to work with a
  new logical model at the beginning of a project
• User may not believe that the analyst can create
  a new logical model (see above)
• Users have problems looking at abstract views of
  their systems with no reference to the current
  physical system

11
Classical Problems (2)

• Assumptions continued
• The transformation of a current logical model
  into a new logical model does not require much
  wasted work
• Take the current logical model and add a few
  functions or new data
• Rest of the model stays more or less intact
• Assumptions correct in many projects
• However

12
Classical Problems (3)

• RiskA potentially large risk
• The process of developing a model of the current
  system may require so much time and effort that
  the user will become impatient and ultimately
  cancel the project
• Huh? I am documenting their system here
• Analysis often seen as not real work
• Why model something that we are going to replace
  anyways?

13
Classical Problems (4)

• So lets throw out some of the modeling tool
  guidelines that we discussed last time
• Complete DFDs, complete data dictionaries
• Well this class stinks
• No, documenting the current physical model does
  not need to be complete
• Analysts can get carried away modeling the
  current system
• In some cases start integrating current physical
  and new logical into one

14
Wasting Time

• Documenting everything in the current physical
  model is wasting time
• Generally as much as 75 of the physical model
  will be thrown away moving to the logical model
• Physical model is 3 to 4 time larger than the
  logical model
• Due to possible redundancy
• Due to error checking (VV) in physical system
  that may not be appropriate in the logical system
• Perfect system, implementation free

15
Solution?

• It can be a trap
• Be wary and make sure you do not get carried away
• OR
• Just do not model the current physical system
• Take the modeling tools and start modeling the
  new system, in this case, the new logical system
  or essential model

16
Solution? (2)

• However, be aware you may need to sometimes model
  the current physical system
• Discover what the essential processes really are
• Why would you need to do this?
• Show user you understand system/domain
• You feel unsure about the current system/domain
• Physical model education

17
Building Current Physical Model

• How?
• Remember previously, do not get into details
• Create an overview
• Get a high-level understanding
• What is high-level?
• One or two levels of DFD
• Perhaps an E-R diagram
• Process spec?
• Perhaps, a few critical processes
• Data Dictionary?
• Gather data in a physical form perhaps
• Do not write process specs for everything
• Do not create a complete data dictionary for the
  whole system

18
Transition to Logical

• Once you have the overview complete start the
  transition to the logical model
• Involves removing implementation details
• Look for essential flows that have been
  arbitrarily packaged together in the same medium
  and separate them
• Unrelated data combined in one form
• Physical or electronic

19
Transition to Logical (2)

• Look for aggregate or packaged flows that are
  sent to bubbles that do not need all of the data
  and separate

X
W X and Y
Y
Compute Temp
Compute Speed
Compute Temp
Temp
Compute Speed
Temp
Speed
Speed
20
Transition to Logical (3)

• Distinguish between essential work done by a
  process and the identification of the processor
  shown in the physical model
• Remember processes may have been people
• Divide into essential process not processors
• Eliminate processes whose only purpose is to
  transport data from one place to another within
  the system
• Also remove bubbles doing physical input or
  output between the system and the external
  environment
• Processes transform, not transport

21
Transition to Logical (4)

• Eliminate processes whose job is to verify data
  that are both produced inside the system and used
  inside the system
• Perfect technology, no need for checking inside
  data
• Still error check data coming from the outside
• Look for situations where essential stores have
  been packaged together into the same
  implementation store (disk file, tape files or
  paper files)
• Separate content of the store from the medium

22
Transition to Logical (5)

• Remove any data elements from stores if they are
  not used by any process
• Also remove any computed or derived data elements
  from stores
• These can be re-inserted later with the new
  physical model
• Remove any data stores that exist only as an
  implementation-dependent time delay between
  processes

23
Going right to the Logical Model

• Back to the problem with the classical approach
  building the physical model may be seen as a
  waste of time
• Jump right into the building the new logical
  model
• The Essential Model
• A model of what the system must do in order to
  satisfy the users requirements with as little as
  possible about implementation
• Assumes perfect technology again
• Ideally you have NO implementation information

24
Going right to the Logical Model (2)

• Goal is to avoid describing specific
  implementation of processes with the user
• Do not show the functions being carried out by
  humans or computer systems
• Either one is an arbitrary choice and may
  influence the final design
• The decision should be delayed until design has
  started
• Same holds for stores and flows, do not discuss
  medium or physical organization

25
Going right to the Logical Model (3)
Employee Travel Files
Employee Travel Database
Travel Voucher
Travel Voucher (web form)
Travel Clerk
Travel Website
Direct Deposit Auth
cash
26
Going right to the Logical Model (4)
Employee ID Travel information
Employee Information
Compute Travel Payment
Employee ID Travel Payment
27
Challenges with Essential Models

• Well really only one challenge besides just doing
  it keeping out the implementation detail
• Some common examples
• Arbitrary sequencing of activities in a dataflow
  model
• Only sequencing shown could be data based
• Can not compute area until length and width are
  computed

28
Challenges with Essential Models (2)

• Unnecessary files
• Perfect technology
• Should not need temporary data stores
• Unnecessary error-checking and validation inside
  of the system
• Redundant or derived data

29
Components of the Essential Model

• Two major components
• Environmental Model
• Defines the boundaries between the system and the
  rest of the world
• Context diagram, event list and purpose of the
  system
• Behavioral Model
• Describes the required behavior of the inside of
  the system needed to interact with the
  environment
• DFDs, ER diagrams, state-transition diagrams, etc.

30
Environmental Model

• One of the most difficult aspects is identifying
  what is in the system
• Every system is a part of another system
• Need to be able to define the context of the
  system you are creating
• Need to define the interfaces between your system
  and the rest of the universe the environment

31
Environmental Model (2)

• Information flowing over interfaces does not
  occur at random
• An outside event occurs that causes a response
  from the system
• In order to be able to define the environment
  then we also need a list of environmental events
  that cause a response in the system

32
Environmental Boundary

• The boundary between the system is generally
  arbitrary
• What kinds of things may define the boundary?

33
Environmental Boundary (2)

• Organizational
• Management defined
• Politically defined
• Perhaps just by accident
• Others?

34
Environmental Boundary (3)

• The user may have an idea about the boundary
• But a gray area may exist

Environment
Accounts Payable
Invoicing
Accounts Receivable System
Cash Flow
Orders
Inventory
Environment
35
Environmental Boundary (4)

• The analyst will have an opportunity to influence
  the boundary
• Choose too small and you may fail
• Identified the symptom of the problem you are
  trying to fix rather than the cause
• Choose too large and you may fail
• Too much complexity
• Invited political turmoil
• Not enough support to develop

36
Scoping Factors

• User goals
• New functionality
• Reliability
• Efficiency
• Better service
• Consider the system in a different way
• Improving braking performance may not be limited
  to only looking at brakes
• Consider other components in the car, the driver,
  the road surface, the weather
• Consider different viewpoints
• A store can be a profit center, or an employment
  center or a shopping center

37
Tools to Define the Environment

• Three basic tools
• Statement of Purpose
• Context Diagram
• Event List

38
Statement of Purpose

• A simple contextual statement of the purpose of
  the system
• High level
• Useful for top development and user management
• Example
• The purpose of the Blue Box Shopping system is to
  handle all of the details of a customers
  purchases as well as managing inventory within
  the stores and across the organization as a
  whole. Information about the state of the
  inventory and purchases made should be available
  to other systems such as marketing and accounting.

39
Statement of Purpose (2)

• Keep it simple
• One or two sentences
• Never more than a paragraph
• It is not comprehensive nor detailed
• May be useful to note the tangible benefits the
  new system will achieve
• System will reduce the amount of excess inventory
  in stock saving cost

40
Context Diagram

• A statement of purpose may leave some questions
• Is the Blue Box system responsible for reordering
  inventory?
• Is the Blue Box system responsible for managing
  employee payroll?
• Is the Blue Box system responsible for sending
  targeted promotional materials to customers?
• The goal of the context diagram is to try and
  answer those questions

41
Level 0

• Context diagram is a special case of a DFD
• One bubble representing the system
• Highlights
• The external entities that the system
  communicates with
• The data from the outside world
• The data sent to the outside world
• Data shared between the system and the entities
• The boundary

42
Event List

• Narrative list of the stimuli that occur in the
  outside world to which the system must respond
• Customer Places order (F)
• Inventory requested from Supplier (F)
• Marketing requests customer demographics (T)
• Inventory arrives at store (C)
• Events labeled as to type
• Flow data oriented
• Temporal
• Control

43
Event List (2)

• Flow oriented events occur when a piece of data
  arrives
• However not every dataflow is flow oriented

B
A
System
So there may not be a one-to-one correspondence
between the dataflows in the diagram and the
events on the list. Each dataflow is an event or
is required by the system to process an event.
Every dataflow may look flow oriented, but only A
may be and B and C are requests in response to A.
C
44
Event List (3)

• Temporal Events
• Triggered by the arrival of a point in time
• Create a report of all new inventory by 9AM
• Generate demographics report by the 5th of each
  month
• Not triggered by incoming dataflows
• Internal clock
• But may request data to perform a function

45
Event List (4)

• Control Event
• Special case of a temporal event
• Usually not present in a business system
• Present in a real-time system
• A temporal event that has no planned time
• Binary data flow usually seen as a control flow
  on the context diagram

46
Other Environment Tools

• The three items mentioned are usually sufficient
• However, two other items may be useful
• Initial data dictionary external stores and
  flows
• Useful on large systems with many flows
• Useful if interface is subject to change and/or
  negotiation
• ER diagram of external stores
• Better define relationships among stores

47
Mid-term

• All material up to and including this lecture
• Some short answer questions, some demonstration
  questions, some analysis questions
• The test will occur during normal class time, 6PM
  to 830PM on 10 Oct 2006
• The IVV Facility will be closed that evening, do
  not come to the Facility
• Test will be emailed to everyone approximately
  545 or so
• I will be logged into Breeze
• If you do not have the test look for me there and
  let me know
• If you have questions ask them to me there
• Email test back to me by 830PM
• I will accepted tests up until 835PM to try and
  account for any lag
• ANY QUESTIONS????