Section 1: Systems life cycle and software development

Analysis
Operation &
Maintenance
Design
Implementation

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: 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
 List of activities
 Order in which they are to be done
 Total time required
PERT
 Module diagram
 Dependencies between modules

Input
What data or information will the system need?
Processing
What will the system do to the data?
How will information be stored and represented?
Output
What information should the system give its users?







Tape
Storag e
Disk
Storag e
Documen t
Documen ts
Process
Input/
Output
Manual
Input

Analysis: Pay System Example
Hours worked
Transaction
File
Calculate Pay
Master
File
(Inputs)
(Processing)
Updated
Master
File
Payslips (Outputs)

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.

 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).

 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

 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.

 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

 Constant review
 Performance evaluation
 Bug-fixing
 Feeds back into the Analysis stage to create a cycle
 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
 Permanent
 Complete set of records
 Transaction File
 Temporary
 Contains only those records that have been changed recently
 Used to update the master file

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
 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

 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