1. Overview of Systems Design CSE1204 - Information Systems 1

2. 2 Systems Development Phases Analysis Design Implementation Review Maintenance Quality Documentation Ethics Project Management Analysts Role Initiation

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

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

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

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 system’s 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. 26 Structure Charts A system is easier to write and test if we divide it into MODULES MODULE: A named, bounded, set of statements to do a single task, having an identifier by which it can be referenced as a unit. GET VALID TRANSACTION Each of these modules is coded separately

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. 32 Human–Computer Interface Design INTERFACEINTERFACE INTERFACEINTERFACE Programs Database end user direct user The interface is the link between the users and the computer To many users the interface is the system

33. 33

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