7.1

DESIGN OVERVIEW:SELECTING DESIGN ALTERNATIVES

IMS9001 - Systems Analysis and Design

7.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 ...

7.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

7.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 organisation’s needs

remember .. alternative solutions should never be limited to computer solutions .. improved manual systems and sub-systems can be equally viable

7.5

Generating Alternatives:How 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

7.6

Generating Alternatives:Issues

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

7.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

7.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

7.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

7.10

Choosing off-the shelf software: Issues

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

7.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 vendor’s products

7.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

7.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

7.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

7.15

Implementation Issues

User training Disruptions in work procedures must

be addressed How long will implementation take? Social issues

7.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?

7.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

7.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?

7.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

7.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

vendor’s products Note: this phase is only carried out when some

or all of the system will not be developed in-house

7.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

7.22

Solicit proposals/quotes from vendors

Some organisations are committed to buying from a specific vendor .. so it’s 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

7.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

7.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 system’s data stores will be

centralised or distributed how data will be input? how outputs will be generated?

7.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

7.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

7.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

7.28

The Basics of Interface Design

Five Commandments: Support “Transportability of

Knowledge” Be Consistent Provide Feedback Use Drab Colours Make the User Boss

7.29

References

HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) Modern Systems Analysis and Design, (4th edition), Pearson Education Inc., Upper Saddle River, New Jersey, USA. Chapters 1, 5

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