System Design:

1
IMS2805 - Systems Design and Implementation

• Lecture 2
• System Design
• Selecting Design Options

2
Design Phase - Purpose

• The main objectives of the design phase are
• to provide alternative design solutions
• to assist in the selection of a design solution
• to acquire the necessary hardware and software
• to design and integrate the various physical
  system components .. interfaces, security
  controls, files/databases, etc ...

3
Design (How?)

• Define how the system will be implemented

Various Sources
System Requirements Specification Report
ANALYSIS
Design ideas/opinions
Select a design strategy and specify details
Design Options
System Vendors
Hardware/Software deals
Selected Design Option
Design in Progress Report
Technical Design Report
SystemOwners/Users
IMPLEMENTATION
4
1. Generating Alternative Design Solutions

• using the prioritised business requirements from
  the Analysis phase
• propose creative alternatives to meet the
  requirements for different implementation
  environments
• hardware, system software, network platforms
• assess the feasibility of these alternatives to
  see which one best meets the organisations needs
• remember .. alternative solutions should never be
  limited to computer solutions .. improved manual
  systems and sub-systems can be equally viable

5
Generating AlternativesHow many?

• While it is possible to generate a large no. of
  alternatives 3 feasible alternatives is usual
• low end conservative in terms of effort, cost
  and technology
• high-end many extra features, functionality not
  cost primary focus
• mid-range a compromise of the above

6
Generating AlternativesIssues

• Constraints
• Outsourcing
• Sources of software
• Hardware and system software issues
• Implementation issues
• Organisational issues

7
Constraints

• date when system is required
• available financial and human resources
• elements of the current system that cannot change
• legal and contractual restrictions
• the strategic importance of the system to the
  client (may limit outsourcing)
• How firm are the constraints? .. can they be
  violated in special circumstances

8
Outsourcing

• The practice of turning over some or all of an
  organisation IS applications and/or operations to
  an outside firm.
• Why?
• May be cost-effective
• may be specialist in your business area
• to overcome operating problems
• running IS not part of core business
• need to be aware of the pros and cons

9
Sources of Software

• Hardware manufacturers
• mainly systems software
• Packaged software producers
• range from generic eg. MS Project to very narrow,
  niche packages
• Custom software producers
• when internal expertise or personnel not
  available
• In-house development
• Hybrid solutions are common

10
Choosing off-the shelf software Issues

• Cost
• Functionality
• Vendor Support
• Viability of Vendor
• Flexibility
• Documentation
• Response Time
• Ease of Installation

11
Choosing off-the shelf software Process

• identify products which may suit specified
  requirements
• solicit, evaluate and rank vendor proposals
• select the best vendor proposal
• establish requirements for integrating the
  vendors products

12
Choosing off-the shelf software Criteria

• Identify criteria by which to evaluate hardware
  and software
• cost, functionality,vendor support, vendor
  viability, quality of documentation, ease of
  learning, ease of use, ease of installation,
  response time, throughput, version?, ease of
  customisation, number of current installations,
  licensing arrangement, training, internal
  controls, database size limitation, maintenance
  contracts, customer references
• to help identify criteria you can use
• past experience, trade magazines and journals,
  information services, potential vendors .. bias

13
Hardware and System Software Issues 1

• Advantages of running a new system on the
  existing platform
• lower costs
• familiarity with system
• easier to integrate with current systems
• no added cost with converting old systems to new
  platforms

14
Hardware and System Software Issues 2

• Reasons for acquiring new hardware or system
  software
• some components of your new system may only run
  on the new platform
• opportunity to upgrade/expand current technology
• may allow for radical change eg. centralised to
  distributed processing

15
Implementation Issues

• User training
• Disruptions in work procedures must be addressed
• How long will implementation take?
• Social issues

16
Organisational Issues

• Overall cost and the availability of funding
• What will management support?
• Are there any political issues?
• Will users accept the new system?

17
Analyse feasibility of alternative solutions

• Once alternative solutions have been identified,
  they must be analysed for technical, schedule,
  operational, and economic feasibility
• Feasibility is the measure of how beneficial or
  practical the development of an information
  systems will be to an organisation Whitten,et.
  al.
• Feasibility must be assessed throughout the
  project

18
Assessing feasibility

• Categories of feasibility tests
• Operational .. does it solve the problems?,
  does it take advantage of the opportunities?,
  how well will it work?, how do people feel about
  it?
• Political .. Is it supported right through the
  organisation?
• Legal and Contractual
• Technical .. are the technical resources and
  expertise available?, is the technical solution
  practical?
• Schedule .. is the time-table reasonable?
• Economic .. how cost-effective is it?

19
2. Select a solution

• After alternatives that are infeasible are
  eliminated, the remaining alternatives are
  presented to the users in the form of a proposal.
  This proposal contains
• project plans and size estimates
• alternative solutions with associated feasibility
  analysis
• The user then chooses the alternative than best
  meets their requirements.. possibly based on the
  recommendation given by the system staff

20
3. Acquire hardware and software

• identify products which may suit specified
  requirements
• solicit, evaluate and rank vendor proposals
• select the best vendor proposal
• establish requirements for integrating the
  vendors products
• Note this phase is only carried out when some
  or all of the system will not be developed
  in-house

21
Research technical criteria and options

• Identify criteria by which to evaluate hardware
  and software
• quality of documentation, ease of learning, ease
  of use, response time, throughput, version?,
  number of current installations, licensing
  arrangement, training, internal controls,
  database size limitation, maintenance contracts,
  customer references
• to help identify criteria you can use
• past experience, trade magazines and journals,
  information services, potential vendors ..beware
  of bias

22
Solicit proposals/quotes from vendors

• Some organisations are committed to buying from a
  specific vendor .. so its simple .. just get a
  quote and terms
• If you are going to the marketplace you must
  prepare either a
• Request for Quotations (RFQ) .. if you have
  already decided on a product .. and just want
  information on
• price, vendor specific configuration, maintenance
  agreements, conditions regarding buyer changes
  and servicing
• Request for Proposal (RFP) .. if you are open to
  a variety of products

23
4. Design and integrate the new system

• design a user-friendly system that fulfils user
  requirements
• provide clear and complete technical design
  specifications to the programmers and technical
  staff

24
Analyse and distribute data and processes

• Need to decide on the system architecture - the
  processing, network and data issues
• whether the system will use centralised,
  decentralised or cooperative processes
• whether the systems data stores will be
  centralised or distributed
• how data will be input?
• how outputs will be generated?

25
Factor into design units

• Using the process and data models, the target
  system needs to be factored into design units
  which
• are easy to build
• are easy to test and prove
• are easy to maintain
• document as a natural by-product
• isolate the effect of a given problem
• apply principles of re-use
• facilitate a large degree of partitioning

26
Backup and Recovery

• A standard system of controls that should be
  built into all systems
• Principles
• data can be reconstructed in the event of loss or
  corruption
• application and system software can be reinstated
  in the event of loss or corruption
• Loss or corruption may be deliberate or
  accidental - controls are essentially the same

27
Design computer outputs and inputs and on-line
interfaces

• the precise format and layout of all outputs must
  be specified .. may be on blank paper,
  pre-printed forms or screens
• the data capture method for all inputs must be
  specified .. initial manual capture and/or direct
  entry into the computer system
• build easy-to-learn and easy-to-use dialogue
  around the input and output screens designed in
  earlier tasks

28
The Basics of Interface Design

• Five Commandments
• Support Transportability of Knowledge
• Be Consistent
• Provide Feedback
• Use Drab Colours
• Make the User Boss

29
References

• HOFFER, J.A., GEORGE, J.F. and VALACICH (2002)
  3rd ed., Modern Systems Analysis and Design,
  Prentice-Hall, New Jersey, Chap 11
• WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C.
  (2001) 5th ed., Systems Analysis and Design
  Methods, Irwin/McGraw-Hill, New York, NY.
  Chapter 10