ICT IGCSE.  Introducing or changing a system needs careful planning  Why?

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Lecture 3 Planning and Development Methodologies.
System Development Life Cycle (SDLC)
MIS (Management Information System)
Advanced Database Projects In Access © Hodder Education 2008 Access Projects – Problem Specification.
System Analysis (Part 1)
Systems Analysis and Design 9th Edition
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
Paper Title Your Name CMSC 838 Presentation. CMSC 838T – Presentation Motivation u Problem paper is trying to solve  Characteristics of problem  … u.
Fact-Finding Fact-Finding Overview
1 Lecture 6 The Systems Analyst (Role and activities) Systems Analysis & Design Academic Year 2008/9.
Sharif University of Technology Session # 4.  Contents  Systems Analysis and Design Sharif University of Technology MIS (Management Information System),
IT Job Roles Task 20. Software Engineer Job Description Software engineers are responsible for creating and maintaining software of various different.
Systems Life Cycle A summary of what needs to be done.
SYSTEM LIFE CYCLES. OBJECTIVES o Be able to describe the stages of development of a hardware/software system. o Know what the different stages of the.
Problem Solving Methodology
Introduction to Systems Analysis and Design Trisha Cummings.
VIRTUAL BUSINESS RETAILING
Foundation Degree IT Project Methodologies (for reference)
4.04 Understand marketing- research activities to show command of their nature and scope.
Approaches to Investigating a System “Who knows what’s happening now?”
Chapter 8: Systems analysis and design
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Information Technology
CIS 321—IS Analysis & Design Chapter 4: Analysis— Investigating System Requirements.
End HomeWelcome! The Software Development Process.
There are many occasions for fact-finding during the database system development lifecycle. fact-finding is particularly crucial to the early stages of.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
Level 1 Business Studies AS90837 Demonstrate an understanding of internal factors of a small business.
IT Job Roles & Responsibilities Shannon Ciriaco Unit 2:
Systems Analysis and Design
Systems Life Cycle. Know why it is necessary to evaluate a new system Understand the need to evaluate in terms of ease-of- use, appropriateness and efficiency.
Systems Development Lifecycle Analysis. Learning Objectives List the nine stages of the system life cycle Explain the system life cycle as an iterative.
SYSTEM ANALYSIS 3 rd AUGUSUT 2005 WEDNESDAY LOWER SIXTH COMPUTING LESSON Prepared by: T.Fina.
I Power Higher Computing Software Development The Software Development Process.
Different approaches an analysis might use when investigating a system including: – Questionnaires – Interviews – Document gathering and analysis.
Systems Life Cycle A2 Module Heathcote Ch.38.
 System Development Life Cycle System Development Life Cycle  SDLC Phases SDLC Phases Phase 1: Preliminary Investigation Phase 2: Feasibility Study.
Data flow & information requirements.  Establishing IPSO  Recording information about the existing system  Identifying the problems with the system.
IFS310: Module 3 1/25/2007 Fact Finding Techniques.
1 Chapter 4 Analyzing End-to-End Business Processes.
Topics Covered Phase 1: Preliminary investigation Phase 1: Preliminary investigation Phase 2: Feasibility Study Phase 2: Feasibility Study Phase 3: System.
The Systems Life Cycle AS Computing F451 AS Computing F451.
12/10/15.  It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management)
ANALYSIS PHASE Purpose of information systems in organisations Information systems exist in organisations to serve organisations. Therefore the aims.
The techniques involved in systems analysis Explanation of a feasibility study:Explanation of a feasibility study: –economic, –legal, –technical, –time.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
GCSE ICT Systems Analysis. Systems analysis Systems analysis is the application of analytical processes to the planning, design and implementation of.
Systems Development The Kingsway School. Systems Development This is carried out when a company is having a problem. They usually employ an ICT Consultant.
A BRIEF LOOK AT THE COMPONENTS THAT MAKE UP THE SYSTEM LIFE CYCLE.
Observing the Current System Benefits Can see how the system actually works in practice Can ask people to explain what they are doing – to gain a clear.
GCSE ICT 3 rd Edition The system life cycle 18 The system life cycle is a series of stages that are worked through during the development of a new information.
A brief look at the components that make up the system life cycle.
1 The System life cycle 16 The system life cycle is a series of stages that are worked through during the development of a new information system. A lot.
1 Systems Analysis & Design 7 th Edition Chapter 2.
ICT IGCSE Theory – Revision Presentation The Systems Life Cycle Chapter 7: The Systems Life Cycle Analysis 7.2 Design 7.3 Development.
Systems Analysis Lecture 5 Requirements Investigation and Analysis 1 BTEC HNC Systems Support Castle College 2007/8.
Unit F451 Computer Fundamentals Components of a Computer System Software Data: Its representation, structure and management in information.
Systems Development Lifecycle Analysis. Learning Objectives (Analysis) Analysis Describe different methods of researching a situation. State the need.
MANAGEMENT INFORMATION SYSTEM
Scope of Systems Requirements: Definition o f Requirements Not to define the full system Not to define the full system Describe or define the essential.
Principles of Information Systems Eighth Edition
TIM 58 Chapter 3: Requirements Determination
Systems Analysis and Design
SYSTEMS ANALYSIS Chapter-2.
Classical Waterfall Model
FEASIBILITY STUDY Feasibility study is a means to check whether the proposed system is correct or not. The results of this study arte used to make decision.
4.00 Understand promotion and intermediate uses of marketing-information Understand marketing-research activities to show command of their nature.
Chapter 13: Systems Analysis and Design
Systems Analysis and Design
Presentation transcript:

ICT IGCSE

 Introducing or changing a system needs careful planning  Why?

 Introducing or changing a system needs careful planning  Why?  So it works properly!  Analysis  Design  Implementation  Testing  Evaluation  Documentation

 First you investigate how the old system works and the problem(s) it is causing  Then you analyze it to see how you can solve these problems.  During the investigation, you would use a variety of techniques to find out about how the current system works in great detail:

 Carried out by a systems analyst  Purpose:  To see whether a new system can be designed  Whether it is feasible  Whether it can be implemented

 Describes how current system works  Identifies problems  Proposes solutions  HW & SW recommendations

 Questionnaires  Interviewing  Observing  Examine documents

 With large groups of people, a questionnaire is a quick and simple way to gather information.  However the information gathered is limited by the questions set by the systems analyst (people could have a lot of useful information in their heads, but if the questionnaire doesn’t ask the right questions, they will not be able to pass it on)  Also many people do not take the time to fill in questionnaires seriously.

 One questionnaire can be filled in by many people at the same time.  Better for busy people/don't have to prearrange appointments  BUT:  may not be able to read answers  options available (eg Yes/No may not allow accurate or full answers)  No scope for individual answers

 The systems analyst can interview key people within the system to find out how it works.  Interviews allow lots of very detailed information to be gathered, but they take a long time to do, so are not possible if large groups of people are involved.

 allow analyst to fully explore and ask individualized questions BUT time consuming.  Can change script to suit circumstances/more likely to get truthful responses  Appointments have to be prearranged

 This involves the systems analyst walking around the organisation or business, watching how things work with his/her own eyes.  Observation allows the systems analyst to gather first-hand, unbiased information.  The downside to observation is that often people won't work the way they normally do if they know they are being watched.

 see how the current system works and the processes involved, also note any obvious problems  Can gain broader overview of processes  BUT people work differently when they are being observed (the Hawthorne effect) – this could affect observation data.

 Most businesses and organisations use documents to record information, or to communicate information (forms get filled in and passed to other offices, etc.)  The systems analyst needs to collect examples of the documents used to get an understanding of the type and quantity of data that flows through the business or organisation.

 very time consuming but gives thorough overview and good opportunity to identify problems/limitations within the current system.  Can follow data flow more easily  informs input/output format design

What happens? Having collected as much information about the present system as possible, the systems analyst now looks though it all to understand how the system works, and to try and identify problems that need to be fixed.

 Every system has inputs and outputs and the systems analyst needs to identify the data input to the present system, and the data output.  This is because any new system that is designed will have to deal with similar inputs and outputs as the present system.

Identifying the inputs, outputs and processes helps the Systems Analyst really understand how a system works:  What goes in?  What happens inside?  What comes out?

 For example, the payroll system in a business might have the following inputs and outputs...

 Any new system that is created will need to take in the same input data (the number of hours worked by employees), and will have to produce the same three outputs.  For similar reasons, the systems analyst also has to understand how the present system works (the processes – who does what and when)

 Most large systems are actually made up of many sub-systems. We call these sub- systems processes.  Each process takes data from the inputs or from other processes, processes the data, and produces an output. The output is passed to other processes, and so on.  It is important to know exactly how the system works because some parts of the present system may work very well, and it would be a waste of time and effort to replace them.

 No system is perfect and it is the job of the systems analyst to try and identify where the problems in a system are.  If these problems can be fixed, the system will work more smoothly, be more efficient and, in the case of a business, be more profitable.

In the previous payroll example, the following problems might be identified The payroll often takes over three days to process, resulting in many employees being paid late 2. Timesheets sometimes get lost before being processed. This means that sometimes pay has to be estimated 3. The reports sent to management do not show enough information.

 Now the problems with present system are understood, the system analyst can begin to plan how the new system will fix those problems.  The systems analyst specifies a list of requirements for the new system (‘requirements’ simply means targets or aims).  This list is usually called the Requirements Specification.

1. Payroll processing should be completed within 24 hours 2. The recording of hours worked should use a system that means the data cannot be lost 3. Management reports should contain detailed information about pay for each department, overtime payments and average hours worked by each employee 4. Management reports should be electronic so that managers can analyse the data more easily Any new system that is designed must meet these requirements.

 The whole point of any system analysis is to end up with a better system than presently exists. The Requirements Specification is the document that lists all of the improvements that we hope the new system will bring.

HARDWARE  How many computers?  What type of network?  How many servers?  Any special input devices? (e.g. barcode readers)  Any special output devices? SOFTWARE  Is ready-made, off-the- shelf software available?  Is custom-written software required?

 Off-the-shelf software is software that is created for use by a large range of customers - it tends to be quite general-purpose.  Custom-written software is designed and written specifically for one customer.

 Cheaper  More reliable (because most problems will have been found by one of the many users)  Has lots of support and help available (because lots of other people are using it)

 Very expensive  Provides exactly what the customer needs (a ‘perfect fit’)  Only has one user, so little help is available