0% found this document useful (0 votes)
262 views7 pages

Chapter 7 - Ict

iGCSE 0417 Based on the 2023 syllabus using the 3rd Edition ICT Coursebook (David Waller, Victoria Wright, and Denise Taylor)

Uploaded by

nuka ad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
262 views7 pages

Chapter 7 - Ict

iGCSE 0417 Based on the 2023 syllabus using the 3rd Edition ICT Coursebook (David Waller, Victoria Wright, and Denise Taylor)

Uploaded by

nuka ad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Anouk Arias-Duval’s work

study guide : systems lifecycle


intro [7.1]
The series of stages worked through during the development of a new IT system
or the improvement of an old one are :
1. Analysis
2. Design
3. Testing and development
4. System implementation
5. Documentation
6. Evaluation

analysis of the current system [7.2]


Analysis : a detailed examination of something for a specific purpose, Ex. to see
how it works or to improve it.

Companies usually employ a systems analyst to study the system and find its faults and
how they can be fixed.

methods of researching an existing system


● Observation :
○ Analyst learns what happens by watching how users (employees) carry out
tasks.
○ They try to understand how things are done.
+ Gathers real-life details and is in-depth
- People won’t work naturally when being watched.
● Interviews : (ex. Talking to Ms. Muller to know what to include in the movie)
○ Ask users what does and doesn’t work in the system.
+ Talk to people who are actually using the system and not just getting info
from managers.
- Workers feel stressed due to feeling like they’re being interrogated.
● Questionnaires :
○ A set of questions with a choice of answers to carry out a survey.
+ A lot of info in a short amount of time
+ Users can answer truthfully due to anonymity and have time to consider
their answers
- Some may not take it seriously
- Persuasive questions
- Usually yes/no or multiple choice questions.
● Examination of existing documents :
○ Studying written or printed information about the organization.
+ Reveals a lot of technical info
- Documents may be hard to understand
- Never used on its own as all processes and procedures of the system may not
always be revealed.

This document may not be copied nor shared without my permission


Anouk Arias-Duval’s work

record and analyze information about the current system


Characteristics of the system will be identified :

➔ Data inputs and outputs (automatic or manual)


➔ How data is processed (processing all at once or one at a time)
➔ Problems with the system

Often the information about the current system will be displayed in a diagram.

system specification
At the end of the analysis stage, a systems requirement specification (srs) must be
written. It will be based on the user's needs. It will include things such as :

➔ Purpose of the system


➔ Data that needs to be input and output
➔ How data must be processed
➔ Performance indicators (Ex. how long it takes to write the script)

It will highlight both hardware and software needs.

design [7.3]
Design : the process of defining the elements of a system, including software, the
different interfaces, the data that goes through that software and the hardware
required.

The overall structure of the new system is specified without being developed.

The design should show :

➔ File/data structures
➔ Input formats
➔ Output formats
➔ Validation rules

file/data structures
File/data structures : the way in which the different data items will be
stored.

Data stored in records must be structured in a way that makes it easily


accessible and for relationships to be found between different items.

input formats
Input formats : how data is to be entered into the system and how it will be
interpreted.

Designs like on-screen forms let users enter and view the data.

output formats

This document may not be copied nor shared without my permission


Anouk Arias-Duval’s work

output formats : how the results of processing are to be presented to the


users.

validation rules
Validation rules : routines to check that the data entered by a user or
from a file meets the specified requirements.

They are needed to ensure that data entered by a user is valid (invalid data
causes issues in the system).

Validation won’t guarantee that the entered data is correct; it will only make
sure it is reasonable. Ex. numbers in a number field and text in a text
field.

Different validation routines are :

● Range check : ensures the data is between a minimum and maximum value.
○ Normal data : 6 in a 1-10 range
○ Abnormal data : 11 in a 1-10 range
○ Extreme data : 10 in a 1-10 range
● Character check : ensures that only certain characters are entered. Ex. F
or M
● Length check : ensures the number of characters entered are a certain
number, greater than a minimum number or less than a maximum number
● Type check : a validation rule to ensure that the correct data type has
been entered. Ex. in a numeric field, text won’t be accepted.
● Format check : ensures the characters entered are in a particular order or
pattern. Ex. MM/DD/YY.
● Presence check : ensures that data is entered and the field is not left
empty.

development and testing [7.4]


development
*insert from notebook*

testing
Testing : checking, using sample data, that all parts of the system function as
expected.

Testing is necessary because mistakes are always made when making a new system.

test strategies

Test strategy : a set of guidelines explaining how the testing will be carried
out.

This document may not be copied nor shared without my permission


Anouk Arias-Duval’s work

The different parts of the system are split up into modules and tested separately while
they are being made so that any problems can be easily fixed.

Within modules, there are smaller functions which are also tested as they are coded.

Final or terminal testing is carried out once the whole system has been developed,
ensuring all modules and functions work together and data flows easily without issues.

test plan and test design


Test plan : a detailed and structured plan of how testing should be carried
out.

It should contain tests for :


➔ File/data structures
➔ Input formats
➔ Output formats
➔ Validation routines

Test design : a detailed description of a particular task listing test data


expected results and actual results.

It should include details such as :

➔ What is being tested


➔ The test data that will be used
➔ Expected outcomes
➔ Actual outcomes
➔ Space for solutions to errors to be described

test data
Test data : what data will be used in each test.

live data
After the test data is used, real-life data used in the old system (live data)
will be used to test and can be done while the system is being used by
users.

(testing in terms of the movie will be for example watching it over and fixing
any editing mistakes)

system implementation [7.5]

Implementation : the act of starting to use a new system.

When implementing a new or an improved system, the following steps must be carried out :

● Hardware :

This document may not be copied nor shared without my permission


Anouk Arias-Duval’s work

○ Buy and install new hardware and business may need to temporarily shut
down.
● Data files :
○ The files of data must be loaded onto the new system from a storage device
after hardware is installed.
○ Data entry staff may need to be employed ($$$)
● Training :
○ Staff must learn how to use the new system.
○ May take a long time depending on how much the difference between the old
and the new system is.
○ A training tutor may be hired.
+ Employees may ask specific questions
- Staff won’t be working while training

○ Online lessons given to staff (intranet)


+ Done on employees’ own time
+ Firm runs as usual
- Staff may forget to train

Methods of implementing a new system are :

direct changeover
Old system is completely shut
down and the new one is set up.

+ Whole system fully tested beforehand


(less chance of errors)
+ Costs reduced as only one system
used
- If new system fails, old one must be
re-implemented
- May not have enough time to train
staff

phased implementation
One part of the system is changed but the rest of the system continues to
use the old methods.

+ Only introduces another part if the


previous one is successful
+ Outputs from old and new systems can
be compared to ensure success.
- could be expensive as two systems
must be upheld.

This document may not be copied nor shared without my permission


Anouk Arias-Duval’s work

pilot running
The new system is trialed in
just one part of the organization.

+ If the new system is bad, only one


department of the organization is
affected.
+ training one department at a time so
employees can train each other.
- takes a long time to implement into
each department.
- if the system fails, modification and training cause delays.

parallel running
It involves both the old and the
new system running at the same time.

+ old system is still there if the new


one fails.
+ employees trained gradually
- tasks are duplicated as data must be
input into both systems
- requires more employees, therefore
more costs ($).

documentation [7.6]
Documentation : official information about a system

Documentation should be produced while still in the developing stage.

There are two types of documentation :

This document may not be copied nor shared without my permission


Anouk Arias-Duval’s work

technical documentation
Technical documentation : documentation that includes details about the
structure of the system and details of the software and hardware needed by
programmers and technicians.

It will include :

➔ Limitations of the system


➔ How to install the system
➔ Program flowcharts/algorithms
➔ Program language and listing
➔ System flowcharts
➔ List of variables used
➔ File structures
➔ Hardware and software requirements
➔ Input/output formats
➔ Sample/test runs
➔ Validation routines

user documentation
User documentation : documentation meant for the people using the system;
it doesn’t contain technical information.

Some things it includes :

➔ The purpose of the system


➔ How to install/ run the system
➔ What to do in case of system errors
➔ Troubleshooting guide
➔ How to print and save data
➔ FAQ’s listing solutions to common user problems

evaluation [7.7]
At some point after the new system has been operating normally, it is
reviewed. This is what it is evaluated on :
➔ Evaluation against the original task requirements : the system is checked to see
whether it meets the full requirements of the SRS document.
➔ Limitations and improvements : all the limitations of the system are taken note of
and fixed.
➔ Efficiency : does the new system help users carry out their tasks successfully and
quickly?
➔ Ease of use : how easy it is to perform a task
➔ Appropriateness of situation : does it do too much, more than what the SRS
states?

This document may not be copied nor shared without my permission

You might also like