Overview of Systems Design

1
CSE1204 - Information Systems 1

• Overview of Systems Design

2
Systems Development Phases
Analysts Role
Initiation
Analysis
Design
Implementation
Quality
Documentation
Review
Ethics
Project Management
Maintenance
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
Design Phase - Purpose

• The main activities 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.

5
Task 1 Generating Alternative Design Solutions

• identify alternatives to fulfil the specified
  requirements
• assess the feasibility of these alternatives
• alternative solutions should not be limited to
  computer solutions improved manual systems and
  sub-systems can be equally viable

6
Define alternatives

• prioritise the business requirements from the
  systems analysis phase (mandatory to desired)
• propose different ways to meet the system
  requirements for various implementation
  environments
• hardware, system software, network platforms
• generally three alternatives
• 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

7
Issues to consider in generating alternatives

• Constraints
• available financial and human resources, required
  date, technical (hardware and software etc.),
  elements of the system that cannot change
• how firm are the constraints? Can they be
  violated in special circumstances?
• strategic importance of the system
• Sources of software
• in-house development, hardware manufacturers,
  application package producers, custom software
  producers

8
Issues to consider in generating alternatives

• Outsourcing
• Hardware and software issues
• is what we have sufficient? can we upgrade?
• Implementation issues
• what will the level of disruption be?
• how long will it take?
• Organisational issues
• overall cost and availability of funding
• will management support the alternative?
• will users accept the alternative?

9
Outsourcing

• The practice of turning over some or all of an
  organisations IS applications and/or IT
  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

10
Sources of software

• Hardware manufacturers
• mainly systems software and utilities
• Packaged software producers
• range from generic eg. Payroll, to very specific
  packages e.g. medical practice software packages
• Custom software producers
• when internal expertise or personnel not
  available
• In-house development
• When resources and staff available and the system
  must be built from scratch
• Hybrid solutions are common

11
Choosing off-the shelf software Process

• identify products which may suit the specified
  requirements
• Identify criteria for evaluating selecting
  products
• Solicit proposals from potential vendors (Request
  for Proposal)
• evaluate and rank vendor proposals
• select the best vendor proposal
• establish requirements for integrating the
  vendors products

12
Request for Proposals

• The primary purpose of a RFP is to communicate
  requirements and desired features to prospective
  suppliers
• The requirements fall into 2 categories
• business system requirements
• vendor requirements
• The requirements must be categorised from
  mandatory to desirable

13
Request for Proposal - Outline

• Introduction
• Background, Brief summary of needs, Explanation
  of RFP document, Call for action
• Standards and instructions
• Schedule of events leading to contract
• Ground rules that govern the selection decision
• Requirements and features
• Hardware, Software, Service
• Technical questionnaires
• Conclusion

14
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

15
Hardware and system software issues

• Advantages of using the existing platform
• lower costs
• familiarity with system
• easier to integrate with current systems
• no added cost with converting old systems to new
  platforms
• 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. from centralised
  to distributed processing

16
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
  system will be to an organisation
• Whitten et. al. (2001), p 365
• Feasibility needs to be assessed throughout the
  project

17
Assessing feasibility

• There are four main categories of feasibility
  tests
• Operational .. how well will it work? how do
  people feel about it?
• 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? Cost
  benefit analysis is necessary

18
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 users then choose the alternative that best
  meets their requirements taking into account the
  recommendation made by the system development
  project team

19
3. Acquire hardware and software

• Depending on the solution selected
• In-house development of custom software
• Purchase of commercial software package
• Custom software producers consultants
• Hardware and technology platforms

20
Acquiring hardware and software

• If in-house development
• Design the application architecture
• networks, process and data distribution
• Design the system database and files
• database, file specifications (volumes,
  records..)
• Design the system interfaces
• inputs, outputs, dialogue
• Package the design specifications to guide
  programmers during construction phase

21
Acquiring hardware and software

• If software is to be purchased or development is
  to be outsourced
• Once the proposals have been evaluated and the
  recommended vendor approved, a contract must be
  negotiated with the winning vendor legal and
  accounting advice is essential at this stage
• Specify schedule of delivery
• Installation must be planned
• Debriefing of proposals for losing vendors
  informs them of the weaknesses in their proposals
  and retains goodwill in the marketplace.

22
4. Design and integrate the new system

• design a user-friendly system that fulfils the
  system requirements identified in the
  requirements specification
• provide clear and complete technical design
  specifications to the programmers and technical
  staff who will construct and implement the system

23
Application architecure

• Need to design the system architecture - the
  processing, networks, and data
• 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 will outputs be generated?

24
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

25
Structured Design

• breaks complex systems down by partitioning the
  system into modules, then organising the modules
  into hierarchies suitable for computer
  implementation
• uses structure charts to communicate the design
• offers a set of strategies for developing a
  design solution from a well-defined statement of
  the problem
• offers a set of criteria for evaluating the
  quality of a given solution

26
Structure Charts

A system is easier to write and test if we divide
it into
MODULES
Each of these modules is coded separately
GET VALID
TRANSACTION
MODULE A named, bounded, set of statements to
do a single task, having an identifier by which
it can be referenced as a unit.
27
Design Features

• Design features that lead to systems that are
  easier to maintain and modify
• Small module size .. easier to write and test,
  and they are less likely to affected by change
• Modular independence (coupling) .. the less the
  inside of one module depends upon another, the
  easier it will be to test and maintain
• Modular strength (cohesion) .. measures the
  strength of association of elements within a
  module

28
Design computer files and/or databases

• Files and/or databases must be designed
• to maximise performance and flexibility
• to adapt to future requirements
• Database schema a map of the records and
  relationships to be implemented by the database
• Consider record sizes, record layouts, storage
  volume requirements, access requirements, data
  sharing, security, backup requirements

29
Internal controls

• Ensure controls are in place to restrict access
  to the data to those who need to know
• Include only the data that is necessary
• Use passwords and different levels of access for
  different user groups to limit access
• Identify a position of responsibility for
  ensuring privacy, allocating new passwords,
  checking logs for unauthorised access
• Data, programs, ideas and knowledge are all
  valuable assets to the owner unauthorised
  access, loss or corruption may cause significant
  loss or penalty
• e.g. the tax file number is owned by the
  Commonwealth and its use as a primary key is
  forbidden by law

30
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

31
Design computer outputs and inputs and on-line
interfaces

• the precise format and layout of all outputs must
  be specified may be on 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
• End-users and managers must be involved their
  requirements, opinions and feedback
• Prototyping is useful

32
HumanComputer Interface Design
The interface is the link between the users and
the computer
INTERFACE
Database
Programs
end user
direct user
To many users the interface is the system
33
(No Transcript)
34
Interface and dialogue design

• the process of defining the manner in which
  humans and computers exchange information
• analogous to a conversation between 2 people
• interface and dialogue design is critical for
  successful information systems
• to the user the interface is the system
• should provide a uniform structure for finding,
  viewing, and invoking different components of an
  information system

35
Inputs and outputs forms and reports

• form and report design are key ingredients for
  successful information systems - especially for
  users
• each input data flow to a process will be
  associated with a form
• each output data flow from a process will be
  associated with either a form or a report
• forms and reports can be paper-based or
  screen-based

36
Forms and reports

• A FORM is a business document containing some
  predefined data and also some areas for other
  data to be filled in
• typically based on one database record
• a turnaround document is produced as an output
  by a system and then returned with input data
• A REPORT is a business document that contains
  only predefined data a passive document for
  reading
• typically contains data from many
  different database records

37
Inputs and outputs

• Outputs present information to users
• Internal outputs
• Detailed reports, summary reports, exception
  reports
• External outputs
• E.g. invoices, statements, turnaround documents
• Input design involves
• How the data is initially captured, entered and
  processed
• The method and technology used to capture and
  enter the data
• Controls for accuracy of input data

38
Design guidelines

• Consistency - of operation
• efficiency - related to user task
• ease - output self explanatory
• format - consistent format between
  entry and display
• flexibility - must be convenient to user
• Usability typically refers to
• speed - efficient completion of task
• accuracy - output provides what is expected
• Satisfaction - output is liked

39
References

• WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C.
  (2001) 5th ed., Systems Analysis and Design
  Methods, Irwin/McGraw-HilI, New York, NY.
• Chapters 9, 10
• HOFFER, J.A., GEORGE, J.F. and VALACICH (1999)
  2nd ed., Modern Systems Analysis and Design,
  Benjamin/Cummings, Massachusetts.
• Chapter 11