ICT Theory 0417

Grade 10 – Chapter 7
Mrs. Navy Hattar

1
The system Life cycle https://www.youtube.com/watch?v=4xCldpbDZ10
The reasons to upgrade a current system:
» The existing computer equipment is now obsolete (it cannot be repaired anymore).
» Changes to laws or taxes requiring radical overhaul of software.
» More suitable hardware is now available to improve efficiency and reliability.
» There is a need to expand the company.
A systems analyst needs to be brought in to oversee the whole upgrade process. Their first task
will be to analyse the existing (current) system, and then suggest a number of improvements that
can be made. All these improvements need to be costed and their advantages over the current
system need to be reported back to the company’s management team.
Once a new system is agreed and it has been fully
tested, it is then installed.
It then needs to be fully evaluated and any changes
made where necessary.
Therefore, a cycle of events take place until a fully-
working system is signed off and handed over to the
management team. This whole process is called the
systems life cycle.

2
 Stage 1: Analysis
7.1.1 Analyse the current system
There are four methods used to research the current
system. The four methods used are:
» observation
» questionnaires
» interviews
» examination of existing documents.

3
4
5
7.1.2 Record and analyse information about the
current system
Inputs, outputs, processing and current problems
The next stage in the process requires the analyst to find out:
» what input and output takes place
» what processing is done
» what problems exist with the current system
» user and information requirements for the new system.
One method the analyst can use is a data flow diagram (DFD).

6
User requirements:
The problem to solve is this:
computer system developers do not really understand how a business works: business managers do not
really know how computer systems could help them. The user requirements are designed to help with this
problem:
» User requirements are therefore written by the analyst for the business managers.
» They are written in natural language with very few technical details.
» Their purpose is to allow the customers to check that what the analyst proposes, following the
investigations, is exactly what they originally specified.
» The user requirements will also describe what the analyst thinks the customer does with their system.
Information requirements
» This is the information needed to support the business.
» The information requirements are made up of:
» what? (that is, the data)
» when? (that is, the timing).
A systems analyst turns the information and user requirements into a functional requirements
specification (that is, how the new system will be developed and implemented, including timescales).
The requirements are typically defined as a list of, for example:
» who the customers are and how they interface with the system
» who the vendors are (the sellers of the products), and how they interface with the system
» who the employees are and how they interface with the system.
7
 7.1.3 System specification
The DFD and other information gathering processes allow the analysis team to identify what hardware and
software is needed to run the new system.
Identify and justify hardware
» Identification and justification of which input devices are needed might be, for example:
– barcode readers (using barcode readers avoids the need to manually input data about goods, which is
more efficient, less error-prone and less expensive in the long run)
– scanners (these could be used if it is necessary to convert any existing paper documents into an
electronic format during the implementation stage)
– touch screens (this may be the best and most cost-effective way of gathering information from a business
customer, for example, and to ensure an employee does not miss any important data during a customer
conversation).
» Identification and justification of which output devices are needed; for example:
– 3D printer (if the company are manufacturing toys, for example, it is much more cost-effective to do a ‘one
off’ using a 3D printer than making a toy in the conventional way)
– very large 60” (152 cm) monitors (the company may be using CAD software and the need for very large,
expensive monitors, may be justifiable)
– speakers (the company may employ people with disabilities, so the need for verbal outputs from the
computer may be a necessary requirement).
8
 Identify and justify software
» Identification and justification of which software is required; for example:
– operating system (which operating system is the most appropriate to meet the company needs)
– applications software:
– off-the-shelf software, which would save a lot of development time and costs, but may require
compromises in how the company runs; off-theshelf software (such as Word or Excel) also has a huge
user-base in case of problems and a minimum of training will be required, because the software is well
known.
– bespoke software (written specifically for the company) – this will require considerable time and money to
develop, but will exactly meet the company’s requirements; it will also require considerable training in
using software unknown to the employees, and there will be no userbase to seek help.
» Storage requirements also need to be considered; for example:
– size of storage (how many bytes of storage are required for the systems to run now, and in the future)
– type of storage (which storage type is the most suitable for the company: hard disk drives, solid-state
drives or even magnetic tape drives) – the choice could depend on:
– data access and data write speeds
– number of read-write operations (there is still some doubt about the longevity of SSD if it has to endure
large numbers of read-write operations)
– type of access – can it be serial access to the data (all read in order) or does it need to be direct (no need
to read all the data in order)
– if huge amounts of storage are required and data access time is not that important, magnetic tape may
9
still be the best option.
 7.2 Design
Once the analysis of the existing system has taken place, and the systems analyst has a better idea of the
scale of the problem, then the next stage in the process is design.

10
 File structures and data structures
A file is made up of a number of records, and each record is broken up into fields. One of the fields must be
unique and will act as the primary key field – this is to allow each record to be uniquely identified.

When assigning a field length, it

is important to give a good
estimate of it so there will be no
waste of memory space in a
database.

» This file has 5 fields, 5 records.

Field names are( product_code, year_of_manufacture, product_decription, price_$, department)
» field length (what is the maximum number of characters that need to be stored)
Ex: Field 5: 1, Field 2: 4
» data types
Field 1 Alphanumeric, Field 2 Numeric Integer, Field 3 Text, Field 4 currency, Field 5 Text
» There is a code being used (in this example, the codes T, A and B are being used – coding saves
space in the file because only a single character is being used; this also speeds up entry and also
reduces errors)
» the primary key field here will be product_code because it is unique.
11
Data types

12
i. Alphanumeric
ii. Character
iii. Text
iv. Boolean
v. Alphanumeric
vi. Numeric Integer
vii. Numeric Currency
viii. Numeric Decimal
ix. Date and Time
x. Date and Time
13
 7.2.2 Validation routines
Validation is the process
where data entered into a
computer is checked to see
if it satisfies certain criteria.
It is an automatic check
carried out by the computer
as part of its programming.
Validation is not a check on
whether the data is correct
or accurate; it is only a
check to see if it is
reasonable.

For example, validation

criteria could be that only
positive numbers entered, or
eight characters must be
entered; any data failing
these criteria should be
rejected.
14
1-
A- Format Check, Length Check,
Presence Check.
B- ABCD11AA
C- 1234AB56

2-Name: Character Check

Date of Birth: Range Check
Telephone number: Length
Check
Order reference no.: Format
Check
Sex: Presence Check

Order reference no. is the

primary key.

15
7.2.3 Input formats (data capture forms)
Data capture forms are often used to input data into a computer. These forms ensure data is input into the
computer in the correct format.
They need to be designed very carefully to ensure that the format of the data matches.

Data capture forms will be either paper-based or electronic-based depending on the application.

Paper-based forms need to:

» have a heading to make the purpose of the form clear

» make it clear to the person filling in the form where they must place their answers
» make use of text boxes which will limit the amount of information collected
» make use of character boxes for data such as surnames, telephone numbers, and so on.
» make use of printed text boxes to allow for easy input of items such as date of birth
» make use of tick boxes to make choices easier (such as sex – male or female)
» make sure there is sufficient space to write answers
» make use of clear fonts and clear text colours to ensure the form is easy to read.

16
 Computer-based Forms
A computer-based data capture form is slightly different. These often have the following features:
» use of text boxes to capture key data clearly
» use of on-screen help when completing the form
» use of drop-down/combo boxes where there are limited choices
» use of radio buttons and tick boxes requiring a single click of a mouse to select
» automatic validation of data as it is entered
» control buttons (such as next form, clear entry, save, etc.)
» double entry boxes (with verification rules) to check correctness of key data (for example, when keying in
an email address).

17
Paper based Example
How to change it into Computer Based:
» registration number: same as paper-
based form
» make of car: make use of a drop-down
box as there are a limited number of
manufacturers
» model of car: same as paper-based
form
» date first registered: use of drop-down
boxes for day, month and year
» price: use boxes as shown but include a
validation check
» new or used: use of tick box or radio
button to indicate option
» other features: a back and forward
button (to complete details of all cars),
and a save button when the form is
complete for each car. 18
 7.2.4 Output formats – screen layouts and
report layouts
Screen outputs should be designed:
» to make sure the size of all the output fields is correct
» so that any instructions/descriptions are clear
» so that the full screen is utilised (avoiding large areas of ‘nothing’)
» so that colours and fonts (size and type) make the output clear.
Reports (from a database search) should clearly show all the fields
that were included in the search criteria. The output is usually in the
form of a table.

19
 7.3 Development and testing
7.3.1 Testing
The need for testing
Once the design stage is completed, it is then necessary to create the system and fully test it.

» The types of hardware have already been considered; how these are used to actually interface with the final
system now needs to be identified. For example, how the screens will be used to collect
the data and the way the output will be presented. If specialist hardware is needed (for example, for people with
disabilities) then it will be necessary to finalise how these devices are used with the system when it is
implemented.

20
Test Designs

21
 Test strategies
» Software is often developed in modular form. This method allows it to be broken down into smaller parts
(known as modules). Each module is developed separately by a programmer (or team of programmers).
» Each module needs to be tested separately to see if it functions correctly. Any problems resulting from
the testing require the module to be modified and then tested again.
» Once the development of each module is
completed, the whole system needs to be
tested as a whole (with all modules
functioning together).
Even though each module may work
satisfactorily, when they are all put together
there may be data clashes or incompatibility,
memory issues, etc.

22
 Test plan, test data and live data
The test plan should include:
» a list of all the tests to be performed
» what data is to be used in the testing
» what type of testing the data is designed to check (i.e. normal, abnormal or extreme)
» what live data should be used
» what the expected outcomes are from the testing
» do the actual outcomes match what is expected?

The example we will use is inputting a date into a database field. The entered data must take the format
dd/mm/yyyy and all data must be numeric.
» normal – this is data which is acceptable/valid and has an expected (known) outcome; for example, the
month can be any whole number in the range 1 to 12
day can be any whole number in the range 1 to 31
year can be any whole number in the range 0001 to 2022

23
» extreme – this is data at the limits of acceptability/validity; for example,
The month can be either of the two end values i.e. 1 or 12
The day can be either of the two end values i.e. 1 or 31
The year can be either of the two end values i.e. 0001 or 2022

» abnormal – this is data outside the limits of acceptability/validity and should be rejected or cause an error
message; for example, none of the following values are allowed as inputs for the month:
– any value less than 1 (for example, 0, −1, −15, etc.)
– any value greater than 12 (for example, 32, 45, etc.)
– letters or other non-numeric data (for example, July, etc.)
– non-integer values (for example, 3.5, 10.75, etc.).

none of the following values are allowed as inputs for the day:
– any value less than 1 (for example, 0, −1, −15, etc.)
– any value greater than 31 (for example, 32, 45, etc.)
– letters or other non-numeric data (for example, July, etc.)
– non-integer values (for example, 3.5, 10.75, etc.).

none of the following values are allowed as inputs for the year:
– any value less than 1 (for example, 0, −1, −15, etc.)
– letters or other non-numeric data (for example, July, etc.)
– non-integer values (for example, 3.5, 10.75, etc.).
24
Live Data: This is data with known outcomes.
Live data is entered into the new system and the results compared with those produced from the existing
system. If the two outcomes do not match, then further modifications to the system may be needed.

25
 Example of a test plan
The test plan is designed to test a module where temperatures are input which must be in the correct range
(21 °C to 50 °C). The input temperatures can be integer or real (decimal).

26
27
7.4 Implementation

28
 changeover is changing
7.4 Implementation over from the old system to
the new system. There are 4
methods and each one has
advantages and
disadvantages which need
to be weighed up before the
most appropriate method is
chosen for a particular
application.

29
7.5 Documentation
Once the new system is fully developed, a considerable amount of documentation needs to be produced
for:
1 people who may need to modify or develop the system further at some later stage
2 the end-user.

30
Technical documentation User documentation
Technical documentation is designed to help User documentation is designed to help users to
programmers to make improvements to the system or learn how to use the software or system. This can
repair/maintain the system. This can consist of: consist of:
» program listing/coding » how to load/install/run the software
» programming language used » how to save files
» program flowcharts/algorithms » how to do a search
» system flowcharts » how to sort data
» purpose of the system/program/software » how to print out
» limitations of the system » how to add, delete or amend records
» input formats » the purpose of the system/program/software package
» hardware requirements » limitations of the system
» software requirements » screen layouts (input format)
» minimum memory requirements » print layouts (output format)
» known ‘bugs’ in the system » hardware requirements
» list of variables used (and their meaning/description) » software requirements
» file structures » sample runs (with results and actual test data used)
» sample runs (with results and actual test data used) » error handling/meaning of errors
» output formats » troubleshooting guide/help lines/FAQs (frequently
» validation rules asked questions)
» meaning of error messages. » how to log in/log out
» tutorials
» error messages/meaning of error messages
31
» glossary of terms.
 7.6 Evaluation
Once a system is up and running it is necessary to do some evaluation and carry out any maintenance if necessary.

The following is a list of some of the things to be considered when evaluating how well the new system has worked:

» Compare the final solution with the original task requirements.

» Identify any limitations of the system.
» Identify any necessary improvements that need to be made.
» Evaluate the users’ responses to using the new system.
» Compare test results from the new system with results from the old system.
» Compare performance of the new system with performance of the old system.
» Observe users performing set tasks (compare old with new).
» Measure the time taken to complete tasks (compare old with new).
» Interview users to gather responses about how well the new system works.
» Give out questionnaires to gather responses about the ease of use of the new system.

Overall, is the new solution:

– more efficient? (this might mean ‘more efficient to use’ or ‘more efficient for the business’)
– easy to use?
– appropriate for the task it was designed for?
32
 Evaluation
Some results from the evaluation may lead to two things happening:
» update of hardware because:
– of feedback from end-users
– new hardware comes on the market, necessitating change
– changes within the company require new devices to be added or updated.

» update of software because:

– of feedback from end-users
– changes to the company structure or how the company works that may require modifications to the
software
– changes in legislation that may require modifications to the software.

33
Questions

34
Ad
Bc
Cb
Da
Ec
Fe
Gc
Hd
I a
J d

35
2) a-Data capture forms
Report Layouts
Validation routines
File structures.

B- Live Data: This is data with known

outcomes.
Live data is entered into the new
system and the results compared
with those produced from the existing
system. If the two outcomes do not
match, then further modifications to
the system may be needed.

C-
» program listing/coding
» programming language used
» program flowcharts/algorithms
» system flowcharts

36
3) a-
Text
Date and Time
Numeric/ Decimal
Numeric/ Decimal
Text/ Alphanumeric

B- Animal_passport_number
(you should write the field
names exactly as it is)

C- Format check to make sure

that the data entered
matches the criteria 3
numbers then slash then 4
numbers.

37
4)
User
Both
User
Technical
User
Technical
Both
Technical
User
Both

5) Analysis
Design
Development and Testing
Implementation
Documentation
Evaluation

38
6)
A- Direct Changeover
B- Pilot Implementation
C- Length Check
D- Design Stage
E- Modular Testing

7) To know the new solution is more

efficient, easy to use and appropriate for the
task it was designed for.
- update of hardware because:
– of feedback from end-users
– new hardware comes on the market,
necessitating change
– changes within the company require new
devices to be added or updated.
» update of software because:
– of feedback from end-users
– changes to the company structure or how
the company works that may require
modifications to the software
– changes in legislation that may require
modifications to the software.
39
8) a- Range check to make sure that the
number entered is in the correct range.
Character/ Type check to make sure that
numbers only are entered.

B- Normal – this is data which is

acceptable/valid and has an expected
(known) outcome.
Example: 50
Extreme – this is data at the limits of
acceptability/validity
Example 1 or 100
Abnormal – this is data outside the
limits of acceptability/validity and should
be rejected or cause an error message
Example 150

C- Normal , Extreme, Abnormal,

Extreme, Abnormal, Normal.

D- The same answer for Q2b

40
9)
A- The reasons to upgrade a
current system:
» The existing computer equipment
is now obsolete (it cannot be
repaired anymore).
» Changes to laws or taxes
requiring radical overhaul of
software.
» More suitable hardware is now
available to improve efficiency and
reliability.
» There is a need to expand the
company.

B- Slides 4, 5

C- Slide 29

41
1- Technical Documentation

2- Type Check

3- Live Data

4- Phased Implementation

5- Extreme Data

6- Abnormal Data

42