Scribd
Upload
17 views

Section 1

Section 1 IGCSE CS

Uploaded by

priyanka.sharma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
17 views

Section 1

Section 1 IGCSE CS

Uploaded by

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

IB Computer Science

Section 1: Systems life cycle and software


development
The systems life cycle

Analysis

Operation &
Maintenance Design

Implementation
Stages
The guide gives these five as the stages of the software life cycle
 Analysis: Data collection, interviews, etc, user requirement,
feasibility report
 Design: Data structures, algorithms, files. Hardware
requirements. Data flow and object model.
 Implementation: Also called installation.
 Direct changeover
 Phased introduction
 Parallel running
 Operation: Detailed planning using GANTT and PERT charts
 Maintenance: Bug fixing
But I have also seen these on past exam papers
 Validation
 Documentation
Analysis: Data collection methods
Analysis: Requirements Specification

 Defining what the client wants


 Inputs: what data/information will
the system require
 Outputs: what information is
expected from the system
 Human resources requirements
 Schedule
 Critical success factors. Key objectives.
GANTT and PERT charts

GANTT PERT
 List of activities  Module diagram
 Order in which they are to  Dependencies between
be done modules
 Total time required
Analysis: IPO

Three stages of
programming:

Input Processing Output

What data What will the What


or system do to information
information the data? should the
will the How will system give
system information its users?
need? be stored and
represented?
Analysis: Feasibility Report
 Feasibility means “Can it be
done?”
 Brief description of the proposed
system
 Estimated costs
 Financial, technical, legal
responsibility
 Estimated completion date
Analysis: Systems Flowcharting

Tape
Storag Documen Input/
Documen
e t Output
ts

Disk
Manual
Storag Process
Input
e
Analysis: Pay System Example

Hours Master
worked
Transaction File (Inputs)
File

Calculate Pay (Processing)

Updated
Master Payslips (Outputs)
File
Analysis: Systems Flowchart
Past Paper Question
Analysis: Systems Flowchart
Past Paper Answer

Customer orders are collected on


paper, keyed in, and stored in a
customer orders file. A stock master
file is searched to determine
whether sufficient stock is available,
and a report produced.

The mark scheme awarded one


mark for each of the boxes, up to a
maximum of five boxes. In my
opinion you could have left out the
keyboard input, or you could have
specified the master file as tape
drive (sequential access storage),
and you would still get full marks.
Analysis: Review
 Why is data collection important? What are the methods of data
collection?
 What is a requirements specification? What does it contain and
what purpose does it serve?
 Outline the features of a feasibility report.
 Annotate the systems flowchart you created in the past paper
exercise. Try to think of another computerised process you could
model with a systems flowchart. Discuss with a colleague and
prepare the flowchart.

 Resources: Computer Science Java Enabled, IB Computing


website, Richard Jones’ site (Int. Sch. Toulouse).
Design Stage
 Forms (data capture)
 How the data will get in to the system
 Classes, Data structures and Input Files
 How the data will be represented and stored
 Algorithms
 How the data will be processed
 Hardware
 The components required
 Reports, Lists, Output Files
 What will the output of the system be?
 Systems Flowchart
 Showing the whole system
Other concepts
 Modularity: Breaking down the software to make it easier
to understand. Can be done in several ways. Classes,
input-related, output-related, processing-related.
 Prototyping: Quickly building a partially-functioning
version of the system with a view to getting constructive
feedback from the user to help clarify the requirements.
 CASE tools and IDEs: Computer Aided Software
Engineering and Integrated Development Environment.
Provide useful tools such as debugging, code-highlighting,
entity-relationship diagrams, automatic instance variable
encapsulation, etc.
Testing
Imagine you have a textbox that should only accept values
from 0-100.
 Normal data: Data that the system should expect, ie that is well
within the normal range. Eg 23, 56, 89, etc
 Extreme data: Data at the boundaries of what is acceptable, eg -
1, 0, 1, 99, 100, 101
 Abnormal data: Data that is outside the normal range of
expected data and which perhaps should produce an error, eg -34,
155.
 Also be familiar with tracing algorithms, debugging
 White-box testing: Testing done by the programmer, focusing on
an understanding of how the program should function
 Black-box testing: Testing done by the user, focusing on an
understanding of what the program should achieve, but not how it
should achieve it.
Implementation
 Parallel running:
 Keep the old system and the new system running at the same time. Adv: No
disruption to business because even if new system doesn’t work, old system is still
available. Disadv: Twice as much work required to keep both systems running.
 Phased introduction:
 Bring the new system in gradually, replacing the old system function by function.
Adv: Can be the best of both worlds between Parallell Running and Direct
Changeover. Disadv: Not often possible to replace a system bit by bit.
 Direct changeover (big bang):
 “Flicking the switch” between old system and new system. Adv: Avoids extra
overhead of having two systems running in parallel. Disadv: Disruption to the
business if the new system doesn’t work properly.

 Things to consider:
 Bugs in the new system
 Cost of running two systems in parallel
 Training new users
 Interruption to business
Operation and Maintenance
 Constant review
 Performance evaluation
 Bug-fixing
 Feeds back into the Analysis stage to create a cycle

Documentation
 Two types:
 System documentation: Intended for programmers so they can
maintain the system. Lists and descriptions of modules, classes,
variables, data structures, hardware requirements, etc.
 User documentation: Intended for users of the system so they can
operate it usefully. Illustrated instructions, how to install, how to
operate, etc.
Master File vs Transaction File
 Master File
 Permanent
 Complete set of records
 Transaction File
 Temporary
 Contains only those records that have been
changed recently
 Used to update the master file
Batch vs Online vs Real-Time
Batch Processing
 A large amount of input happens over time and then then whole set
of input is processed in one go
 Examples: Any monthly billing, eg internet billing (you access the
internet lots of times over the course of a month, then at the end of
the month your ISP totals your usage and gives you the bill)
Online Processing (also known as interactive processing)
 Input is processed (almost) immediately
 Example: Flight booking system. As soon as you book the seat it is
yours. Can you explain why flight bookings could not be processed in
batches?
Real-Time Processing
 Input is processed immediately and continuously
 There is generally no user
 Input comes from sensors
 Examples: Auto-pilot. Large volume of data harvested from multiple
sensors continuously. System reacts in real time.
Validation vs Verification
Validation
 A validation check just checks if input is possible, appropriate or
reasonable
 Keppler accidentally enters 81 for his age, instead of 18
 This is valid because he could be 81
 Validation check does not check if it's actually true
 Examples are range check (eg is aged entered between 0 and 100)
and type check (eg has the user entered a number rather than a
string)
Verification
 The process of checking if data is true, factually correct
 Two ways of doing it:
 Visual checking, ie proofreading
 Double-entry of data, ie inputting the whole data set again and checking if
both sets are the same
Social Effects of Computer Systems
 Positive
 More leisure time for people because computers do their work
 Online commerce reduces the need for travel
 Communication more immediate
 More accessibility for elderly or disabled people
 Computers can do dangerous/repetitive jobs
 Labour-saving devices eg washing machines, security systems, etc
 Negative
 Training required
 Purchase of a computer sometimes required (cost)
 Unemployment in areas where computers do work, eg factories
 Longer hours worked by people always contactable eg email, mobile
phone
 Some health issues, eg eye-strain, back problems, RSI (repetitive strain
injury)
SL P2 N 2009
SL P1 M 2009

You might also like