1. 7.1 DESIGN OVERVIEW: SELECTING DESIGN ALTERNATIVES IMS9001 - Systems Analysis and Design

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

3. 7.3 Design (How?)  Define how the system will be implemented Select a design strategy and specify details Various Sources Design ideas/opinions Design Options System Requirements Specification Report IMPLEMENTATION ANALYSIS System Vendors Hardware/Software deals SystemOwners/ Users Selected Design Option Design in Progress Report Technical Design Report

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

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

6. 7.6 Generating Alternatives: Issues  Constraints  Outsourcing  Sources of software  Hardware and system software issues  Implementation issues  Organisational issues

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

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

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

10. 7.10 Choosing off-the shelf software: Issues  Cost  Functionality  Vendor Support  Viability of Vendor  Flexibility  Documentation  Response Time  Ease of Installation

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

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

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

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

15. 7.15 Implementation Issues  User training  Disruptions in work procedures must be addressed  How long will implementation take?  Social issues

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

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

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

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

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

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

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

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

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

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

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

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

28. 7.28 The Basics of Interface Design Five Commandments:  Support “Transportability of Knowledge”  Be Consistent  Provide Feedback  Use Drab Colours  Make the User Boss

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