Lecture 7 - System Design (Data Modelling) (1).pdf

|
BBT 2101: SYSTEMS ANALYSIS AND
DESIGN
Lecture 7: System Design (Architecture,
Program & User Interface)

|
Recap on Systems Analysis
1. Apply requirements analysis techniques
(business process automation, business
process improvement, or business process
reengineering).
2. Use requirements gathering techniques
(interview, JAD session, questionnaire,
document analysis, or observation).
3. Develop requirements definition.
4. Develop use cases.
5. Develop data flow diagrams.
6. Develop entity relationship model.
7. Normalize entity relationship model.
8/16/2021 Business Systems Analysis 2

|
BSA
Steps of the Systems Development Model
8/16/2021
Feasibility
study
Project
definition
Systems
analysis
Systems
design

|
Data Modelling
1. Select Design Strategy
2. Design Architecture
3. Select Hardware and Software
4. Develop Use Scenarios
5. Design User Interface
6. Develop Physical Data Flow Diagrams
7. Develop Program Structure Charts
8. Develop Program Specifications

|
The Design Phase
• Decides how the system will operate.
• This is the system specification that becomes a
collection of deliverables that is handed to the
programming team for implementation.
• At the end of the design phase, the feasibility
analysis and project plan are re-examined and
revised, and another decision is made by the
project sponsor and approval committee about
whether to terminate the project or continue.

|
Design Strategy: In-house Option
1. Develop a custom application in-house:
– Requires a dedicated effort with a variety of
skills - technical, interpersonal, functional,
project management, modeling
– The risks can be quite high with no
guarantee that the project will succeed

|
2. Buy a packaged system and (possibly)
customize it:
– Must accept the functionality that is
provided by the system and yet rarely does
it fit perfectly.
– Letting technology drive the business can
be a dangerous.
– The search for a software package should
be based on the detailed requirements
identified during analysis
Design Strategy: Buy Option

|
3. Rely on an external vendor, developer, or service
provider to build or provide the system:
– Outsourcing firms called application service
providers (ASPs) supply software applications
over wide area networks or the Internet.
Software as a Service (SaaS) is an extension of
the ASP model
– Developer MUST assess the requirements for the
project thoroughly — never outsource what you
don’t understand.
– Carefully choose a vendor, developer, or service
with a proven track record.
– Need for someone senior to manage the
outsourcing relationship
Design Strategy: External Vendor Option

|
• Describes the system’s hardware, software, and
network environment.
• A plan for how the information system components
will be distributed across multiple computers and
what hardware, operating system software, and
application software will be used on each
computer
• Derived from the nonfunctional requirements, e.g.
operational, performance, security, cultural, and
political requirements
Architectural Design

|
• Four software building blocks or
functions:
– Data storage - data entities documented in ERDs
– Data access logic - processing required to
access data, often meaning database queries in
Structured Query Language (SQL)
– Application logic - logic documented in the DFDs,
use cases, and functional requirements
– Presentation logic - display of information to the
user and the acceptance of the user’s commands
(the user interface)
Software System

|
8/16/2021 P Shabaya 11
Sample Data Base Schema

|
• Designing the programs that will perform the
system’s application logic
– Determine what programs will be written, create
instructions for the programmers about how the
code should be written, and identify how the
pieces of code will fit together to form a program
– Helps avoid programs that are inefficient, code
that does not work with other code and a system
that doesn’t do what it’s supposed to do
• Three steps: Convert logical DFDs into physical
DFDs, draw structure charts and write program
specifications
Program Design

|
8/16/2021 13
1. Convert Logical DFDs to Physical DFD
End
of
Analysis
Beginning
of
design
Business Systems Analysis

|
• Shows all the components of code that must be
included in a program at a high level, arranged in a
hierarchical format that implies sequence (in what
order components are invoked), selection (under
what condition a module is invoked), and iteration
(how often a component is repeated).
• Physical process models e.g. DFDs provide a good
starting point on what to include in structure charts
• The components are usually read from top to
bottom, left to right, and they are numbered by a
hierarchical numbering scheme i.e. additional
numbers for lower levels
2. Develop Structure Charts

|
Structure Chart Example

|
❑ A lower level module should not be required to perform
any function of the calling, higher level module. This
would be "improper subordination."
❑ Modules that perform input are referred to as afferent
while those that produce output are called efferent
❑ Coupling involves how closely modules are interrelated
– i.e. good structure chart design states that modules
should be loosely coupled.
❑ Data coupling occurs when modules pass parameters or
specific pieces of data to each other
❑ Bad coupling type is content coupling, whereby one
module actually refers to the inside of another module.
Structure Chart Rules

|
Business Systems Analysis 17
Figure 10-6
STRUCTURE CHART EXAMPLE II
8/16/2021

|
• Fan-in describes the number of control modules
that communicate with a subordinate; a module
with high fan-in has many different control
modules that call it. This is a very good situation
because high fan-in indicates that a module is
reused in many places on the structure chart
Fan-in of Structure Charts

|
• Fan-out is number of modules a single control
module has control over
• Developers want to avoid a large number of
subordinates associated with a single control.
Fan-out of Structure Charts

|
• Program specifications are written to
describe exactly what needs to be
included in each program module.
• The specifications include basic module
information e.g. a name, calculations that
need to be performed, and the target
programming language as well as special
instructions for the programmer and
pseudocode
Developing Program Specification

|
1. Program Information, such as the name of the module,
its purpose, the deadline, the programmer, and the
target programming language.
2. Events that trigger the functionality in the program. An
event is a thing that happens or takes place. Clicking
the mouse generates a mouse event; pressing a key
generates a keystroke event etc
3. Inputs and Outputs describe the inputs and outputs to
the program, which are identified by the data couples
and control couples found on the structure chart. Such
information ultimately will translate into variables and
data structures within the actual program.
4. Pseudocode is a detailed outline of the lines of code
that need to be written,
Parts of Program Specification

|
• Three primary hardware components:
– Client computers - the input–output devices
employed by the user (desktop or laptop computers
or handheld devices, smartphones, special-
purpose terminals)
– Servers - larger multi-user computers
– Networks - vary in speed from slow cell phones or
modem connections to medium-speed frame relay
networks, to fast broadband connections such as
cable modem, DSL, or T1 circuits, to high-speed
Ethernet, T3, or ATM circuits
Hardware System

|
n-Tiered
Client–
Server
Architecture
Two-Tiered Client–Server
Architecture
Three-Tiered
Client–Server
Architecture

|
User Interface Design
❑ Specify in detail how all users will interact with the
system
❑ Entails designs of user screens, dialogue boxes,
menus, mouse interactions, sound, video and specific
voice commands.
❑ NB: Should be well thought and considered throughout
the development process
❑ Specify in detail how the system will work with
all other systems inside and outside the
organisation
❑ Check for compatibility standards for current
systems and possible future systems both
internal and external
8/16/2021 24

|
25
Identifying System Interfaces
❑ System interfaces are broadly defined as inputs
or outputs with minimal or no human intervention
– Inputs from other systems (messages, EDI)
– Highly automated input devices such as
scanners
– Inputs that are from data in external
databases
– Outputs to external databases
– Outputs with minimal HCI
– Outputs to other systems
– Real-time connections (both input and output)
8/16/2021

|
26
Full Range of Inputs and Outputs
Figure 15-1
8/16/2021

|
27
Order Summary and Product Detail Forms
8/16/2021 Business Systems Analysis

|
Video Library Registration

|
Ole Sangale Road, Madaraka Estate. PO Box 59857-00200, Nairobi, Kenya
Tel +254 (0)20 606155, 606268, 606380 Fax +254 (0)20 607498
Mobile +254 (0)722 25 428, (0)733 618 135 Email info@strathmore.edu
www.strathmore.edu

Lecture 7 - System Design (Data Modelling) (1).pdf

More Related Content

Similar to Lecture 7 - System Design (Data Modelling) (1).pdf

Recently uploaded

Lecture 7 - System Design (Data Modelling) (1).pdf