1
2
3
4
5	Problem Identification/Objectives Identify the problems with the current system Objectives of the new system are the problems it will solve Objectives are not the same as Requirements
6	Why a new [reports] system? The current system may no longer be suitable for its purpose E.g. Growth of data – 1500 students not 600 Technological developments may have made the current system redundant or outdated E.g. Is writing reports on paper still the best way? The current system may be too inflexible or expensive to maintain E.g. Can staff time be used better
7	KGV Reporting System Problems Identified Time consuming More students =more time Error correction was very slow Contention for resource (Interim reports) Collating into order (for each students) Accuracy Spelling errors Inconsistent names Appearance Some handwritten, some type Environmental Concerns Errors At least two copies (single sided)
8	KGV Reporting System Objectives Reduce the time taken for staff to complete Reports Increase accuracy of reports (spelling errors, inconsistent names, poor grammar) Improve Appearance Reduce use of paper Ensure data is kept secure Ensure the system is reliable Ensure the system is easy to use (foolproof)
9	Opportunities/Threats Opportunities Make better use of the data Student Tracking Department Tracking Threats Reduced security Reliability Staff resistance
10	Feasibility study (TELOS) Technical feasibility does the technology exist to implement the proposed system, or is it a practical proposition? Economic feasibility is proposed system cost-effective – if benefits do not outweigh costs, it’s not worth going ahead. Legal feasibility Is there any conflict between the proposed system and legal requirements – e.g. the Data Protection Act? Operational feasibility are the current work practices and procedures adequate to support the new system? Schedule feasibility how long will the system take to develop, or can it be done in a desired time-frame?
11	Feasible or not? Many (real world) projects will get no further than the feasibility report If the system is feasible and the ‘end-user’ wishes to proceed – next job is to produce a detailed analysis of the current system
12	People Involved End User (an overloaded term – be careful!) Procurer (e.g. ESF) Responsibility for system specification (e.g. Mr McDouall) Teachers Tutors Office Staff Project Manager Systems Analyst Software Developer Software Tester User Support Technician Technical Support Technician Systems Administrator
13	Detailed Analysis Find out everything about the system required (by analysing in details the current system) What do we want to find out? How can we gather these details?
14	Analysis For each and every sub-system Data Data Capture Methods (hardware, validation/verification) Storage Files, fields, volume, hit rate Processing What happens, when (event or timed), where, by whom (human or computerised) Is it batch or interactive What stored data is used Information Produced Recipients, Structure, Format, Primary/Secondary Users Security System Recovery
15	Information Gathering Techniques Interviewing ‘end users’ at different levels from simple users to senior management Sending out questionnaires the questions have to be carefully constructed to elicit unambiguous answers Examining current business and systems documents and output may include current order documents, computer systems procedures and reports used by operations and senior management Observation of current procedures by spending time in various departments; a time and motion study can show where procedures could be more efficient, or to detect bottlenecks
16	Exercise Consider analysis of the KGV Reporting System: What documents might you want to see? Who would you want to interview? think of three questions Who might you want to send questionnaires to? think of some questions Which processes might you want to observe?
17	Tools to describe Current System ER diagrams File Structure Diagrams Dataflow charts (Level 0/Level 1) Current Input/Output documents
18	Requirements The most important part of any project is the establishment of Processing Requirements The processing requirements are the specification for the system to be built Requirements are not Objectives!
19	Examples of System Processing Requirements Must be able to print out statements for all customers at the end of each month Must be able to add details of a new member Must be able to update personal details of a member Must be able to produce a list of members with outstanding invoice payments Exercise: Write 6 more requirements for the Mail Order Company data processing system
20	Some tips for writing Requirements Concentrate on specifying what processing the system is required to do and not how it is going to be done (which is design) û ‘Must be a web form for entering change of address details’ is a design decision They must not be subjective û ‘Must be easy to use’ is an objective Must be precise – do not use the words data or information with out clear explanation ‘Must process data to produce information’ is hopeless
21	Overall System Design The first stage of design is to put together an overall system design outlining how the objectives will be reached Should include details of processing: How and when ‘good’ data will be captured How and when processing will take place What information will be produced and how/when it will reach it’s recipient What hardware and software will be required for the various aspects of the system For your projects it is essential that alternatives are discussed and chosen solutions justified
22	Overall System Design Exercise: Improving the Bulletin System Objectives Reduce the amount of time taken to produce the student bulletin Reduce the number of irrelevant notices to be given to a specific tutor group Reduce the number of errors in the bulletin Processing Requirements Must be able to produce a bulletin for distribution each day Must be possible to add details for a new bulletin entry Must be possible to delete a bulletin entry Must be possible to amend a bulletin entry
23	Current System Paper based collection of data Human transcription into Word Processor Printed and published to Web by saving as html to the school web site Exercise: Write an overall system design that will allow meet the processing requirements and achieve the stated objectives Word process up to 3 pages of A4 – include discussion of alternatives and justify all choices made
24	Software Requirements Once overall system design is complete – it will be clear what software will be required. There are three approaches to acquiring the necessary software: Bespoke Software Custom built software – developed in-house or commisioned from a software development company Customise Generic Software Use generic software like spreadsheets or databases – and tailor them (using forms/macros) to do the required job Purchase existing specialist ‘off-shelf’ software Could be a product already created that does the job (NB: We can use difference approaches for different ‘modules’)
25	Criteria for Comparing Bespoke, Generic and Off-Shelf Cost Development Maintenance Support/Training Tailoring to exact needs Lead-in time System glitches (bugs)
26	Design Look at detailed design – later (When we reach that stage of the project)
27	Implementation Implementation is the process of moving from the old system to the new system This will involve Purchasing/Installation of new hardware Creation/purchasing of the new software Modification of master file format [if required] Conversion from old to new system Training the users of the new system
28	Conversion Methods Direct Changeover Stop using the old system one day – use the new system the day after Parallel Changeover The old and new systems run side by side for a period of time (e.g. one month) Phased Conversion In a large system, it may be possible to bring in modules of the new system gradually (e.g. automated teacher collection – manual checking process or commence with just one year) Pilot Conversion Use the new system in a single branch/factory only to start with (Can mix top and bottom pairs – e.g. Phased Parallel)
29	Conversion Considerations
30	Conversion Considerations
31	Conversion Exercise Consider each of the following and suggest (with reasons) the most suitable method of conversion A public library introducing computerised lending and return of resources A large hospital introducing computerised system for keeping and maintaining patients records and appointments An Electronic component manufacturer introducing an integrated system for production control, stock control and order processing Introduction of electronic submission and payment of income tax bills Supermarket chain introducing a new EPOS system connecting shops to a central processing facility via a WAN A school introducing a new computerised reporting system A school introducing a new smart card based electronic registration system A bank introducing a new style of ATM A travel agent introducing web based information and sales
32	System maintenance Perfective maintenance Implies that while the system runs satisfactorily, there is still room for improvement E.g. Duplicate names or mismatching duplicate grades Adaptive maintenance All systems will need to adapt to changing needs within a company E.g. Movement from a five point to four point effort scale! Corrective maintenance Problems frequently surface after a system has been in use for a short time, however thoroughly it was tested E.g. Media Studies VCE and General Studies
33	Why do information systems fail? Information systems fail for many reasons at any stage of the systems life cycle. Analysis, Design, Programming, Testing, Conversion Factors in successful implementation User involvement, motivation and training Users are involved right from the start of a project Level of complexity and risk The larger the project, the greater the risk Proper management of system development A project that is not properly managed is likely to suffer from: Cost overruns; Delays in completion; Technical problems resulting in poor performance; Failure to achieve expected benefits. Management support New systems that have the backing of management are more likely to succeed
34	Tiptree
35	Evaluation Successful implementation What are the criteria for judging the success of a system? Here are some possible measures: ¨ High level of use Is the new system actually used? ¨ High level of user satisfaction Do users like the system? ¨ Accomplishment of original objectives Have they been satisfactorily achieved? ¨ Appropriate nature of use Do users really know how to use it? ¨ Institutionalisation of the system A successful system will be taken on board enthusiastically by users and used in new and changing ways, evolving to meet new demands
36	Waterfall Model
37	"Prototyping" Prototyping The waterfall model of the system life cycle doesn’t allow for modifications to the design. Benefits of prototyping ¨ Misunderstandings between software developers and users can be identified; ¨ Missing functions may be detected; ¨ Incomplete or inconsistent user requirements may be detected; ¨ A prototype version will be quickly available to demonstrate the feasibility to management; ¨ The prototype can sometimes be used for training before the final system is delivered.
38	Error recovery
39	System design WILL RETURN LATER The hardware platform which type of computer, network capabilities, input, storage and output devices The software programming language, package or database The outputs report layouts and screen designs The inputs documents, screen layouts, validation procedures The user interface how users will interact with the computer system ¨ The modular design of each program in the application ¨ The test plan and test data ¨ Conversion plan how the new system is to be implemented Documentation including systems and operations documentation. Later, a user manual will be produced
40	Design of Output Format
41	Output Design of reports
42
43	Picture