Overview of Systems Design CSE1204 - Information Systems 1
Dec 21, 2015
Overview of Systems Design
CSE1204 - Information Systems 1
2
Systems Development Phases
Analysis
Design
Implementation
Review
Maintenance
Quality
Documentation
Ethics
Project Management
Analysts RoleInitiation
3
Design (How?)
• Define how the system will be implemented
Select a design strategy and specify
details
VariousSources
Design ideas/opinions
Design Options
System RequirementsSpecification
Report
IMPLEMENTATION
ANALYSIS
SystemVendors Hardware/
Softwaredeals
SystemOwners/Users
Selected Design Option
Design in ProgressReport
Technical DesignReport
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.
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
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
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
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?
Outsourcing The practice of turning over some or all of
an organisation’s 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
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
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
vendor’s products
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
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
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
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
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
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
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
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
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
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.
Acquiring hardware and software
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
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 system’s data stores will be
centralised or distributed• how data will be input?• how will outputs be generated?
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
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
MODULE: A named,bounded, set of statementsto do a single task, havingan identifier by which it canbe referenced as a unit.
GET VALIDTRANSACTION
Each of thesemodules iscodedseparately
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
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
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 penaltye.g. the tax file number is owned by the Commonwealth and its use as a primary key is forbidden by law
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
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
Human–Computer Interface Design
INTERFACE
INTERFACE
ProgramsProgramsDatabase
end userdirect user
The interface is the link between the users and the computer
To many users the interface is the system
33
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
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
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
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
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
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