System design

SYSTEMS ANALYSIS AND DESIGN

Cutajar & Cutajar

SYSTEM ANALYSIS 2

INTRODUCTION

� System analysis and design covers the activities involved in developing a new system.

It is the process of analysing particular systems (scientific, business or control), to see if replacement (or upgrading) would yield a more useful, productive and profitable way of performing the businessoperations.

� System analysis and design involves System Analysts.System Analysts are deeply involved:-

� Analyse the data processing requirements of an organisation, in whole or in part;

� Decide what, in consequence, the computing system should do;

� Specify the tasks of the computing system in detail, so that the technical specialists (programmers) can do their work;

� Ensure that the developed computing system works efficiently.

SYSTEM ANALYSIS 3

WHAT IS A SYSTEM?

� A system is a collection of interrelated components that work together to achieve some objective

� Different components making up a system include:� Hardware

� Software

� Collection of data

� Work of a number of people.

� Different components making up the software component of a system include: � inputs

� processes

� stored data

� outputs

� human communication interface (HCI)

SYSTEM ANALYSIS 4

SYSTEM ELEMENTS

� A commercial or industrial enterprise can be defined in terms of system elements:

�Physicale.g. Buildings, raw materials, finished product;

�Procedurale.g. Order processing routines, credit checking procedures;

�Conceptuale.g. Statement of policy, material for products;

�Social e.g. Workers, departments.

SYSTEM ANALYSIS 5

SYSTEM ENVIRONMENT

� The system operates in an environment and relates to that environment, which itself includes various elements.

� Elements relating to the environment include:

�Physicale.g. transport routes;

�Procedurale.g. codes of practice, legal requirements;

�Conceptuale.g. monetary system, political ideologies;

�Sociale.g. trade unions, suppliers, customers.

SYSTEM ANALYSIS 6

SUB-SYSTEMS

� An enterprise can be divided into a number of SUBSYSTEMS defining the functional areas. These include:

�Those dealing with the environment: marketing and purchasing subsystems;

�Those dealing with transformation functions: the production subsystem;

�Those acting in a supportive role: accounting, personnel, and management services subsystems.

SYSTEM ANALYSIS 7

BUSINESS SUBSYSTEMS

� These subsystems are all interconnected. The diagram shown is a ‘simple’ model of business subsystems:

Customers

Marketing

Accounting

ManagementControl

ProductionPersonnel

Purchasing

Suppliers

GoodsOrdersPurchases

Staffingrequired

Payments

OrdersGoods

Deliveries

Deliveries

Schedules

Budgetsand plans

BudgetsFinancial analysis

Budgets

Manpoweranalysis

Payments

Invoices

Orders

� This diagram illustrates the INTERFACES within the business, and hence the type of difficulty that can arise in defining boundaries. Henceforth the difficulties of the system analyst to analyse, design, help implement and review.

SYSTEM ANALYSIS 8

OBJECTIVES OF COMPUTERISATION

� To reduce costs

� Take advantages of the facilities offered by computers

� To increase volume of business

� Better management of information

� Enable long-term forecasts

� Enable better planning.

SYSTEM ANALYSIS 9

TYPES OF DATA PROCESSING SYSTEMS

1. Systems where processing is done periodically (Batch Systems or File Processing Systems)� Large volume of data coming in at regular intervals but where

processing does not have to be done immediately.e.g. Payroll System, Gas billing system, …

2. Database systems (On-Line Systems)� An on-line system is one in which information is available to all

users at their own terminals, although they may not be able to update the information.

� Independent of any individual application

� Store of information to support other data processing systems.

� Remark: In many instances, the above types then use a data communication system to transmit data from one place to another.

SYSTEM ANALYSIS 10

TYPES OF DATA PROCESSING SYSTEMS (cont…)

3. Real time systems� The computer has to keep pace with some external operation,

processing the received data more or less instantaneously and producing results immediately.

a. Process control

e.g. oil refining process which is computer controlled

b. Information storage and retrieval

e.g. medical records system

Though shared data files, by nature of application, a single record is not accessed by more than one user at the same time

c. Transaction processing

e.g. online reservation system

By nature of application, the same record may be accessed by different users at the same time; hence need of data locking

SYSTEM ANALYSIS 11

THE SYSTEM LIFE CYCLE (SLC)

� The development and maintenance of a new software system involves a series of stages - the SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) or simply the SYSTEM LIFE CYCLE (SLC).

� The term ‘life-cycle’ indicates that the process of development and maintenance never ends.

� The development of a system may take from a few weeks to a few years.

� The SLC is a model which tries to maximize the chance of successful project development.

‘7 out of 10 IT projects “fail” in some respect’(OASIG study)

SYSTEM ANALYSIS 12

THE WATERFALL MODEL

� This SLC model consists of a number of stages

� The stages may be characterized and divided in different ways

Project Definition

System study and analysis

Feasibility Study

System Design

Implementation (Coding)

Testing & Integration

Control & Review

SYSTEM ANALYSIS 13

THE WATERFALL MODEL

� The waterfall model is a very rigid model – “a sequence of stages where the output of each stage becomes the input to the next”.

� In a rapidly changing environment and where up-to-date software systems are required, this model does not work

� The model assumes that all system requirements can be identified in advance - in practice, most often, this is not the case.

� This model assumes that users are only to be involved in order to specify system requirements

SYSTEM ANALYSIS 14

THE SPIRAL MODEL

� This method allows the development team to progressively complete a project by repeatedly going through the stages of analysis, design and implementation.

Analysis

Implementation

Design

Analysis

Implementation

Design

Analysis

Implementation

Design

SYSTEM ANALYSIS 15

THE INCREMENTAL-ITERATIVE MODEL

Analysis Design Implementation

Component A Component CComponent B

Analysis

Implementation

Design

Analysis

Implementation

Design

Analysis

Implementation

Design

SYSTEM ANALYSIS 16

THE INCREMENTAL-ITERATIVE MODEL

� The project is divided into subprojects and then the waterfall method is performed on each subproject. Instead of completing functionality of the entire application with each pass, the incremental-iterative method completes components.

� Each component does not necessarily become a deliverable that isusable by a client (though at milestones the components are joined together to create a usable product).

� This approach to project development promotes the development ofreusable code. It promotes the separation of functionality required into different components (e.g. GUI controls, data access …) and it helps clarify exact functionalities required.

SYSTEM ANALYSIS 17

THROW-AWAY PROTOTYPING

The objective is to understand the customer’s requirements and hence develop a better requirements definition for the system

� Mock-up

A ‘mock-up' of the proposed system is produced for demonstration purposes. Prototype has appearance of the final system but lacks any real processing or storage capabilities.

� Trial Prototyping

A simplified working model of proposed system serves for demonstration purposes and also provides an opportunity to try out ideas and investigate specific points of interest.

SYSTEM ANALYSIS 18

RAPID PROTOTYPING

�Also known as Evolutionary PrototypingThe objective is to work with the customer to explore their requirements and deliver the final system. The development starts with the parts of the system which are understood . The system evolves by adding new features as they are proposed by the customer.

� Rapid prototyping is particularly suitable for:

� For small scale systems which are required urgently and which have a limited life.

� When it is difficult to establish a detailed system specification. E.g. AI systems which attempt to emulate human capabilities.

SYSTEM ANALYSIS 19

RAPID PROTOTYPING

Evolutionary development:

Specification

development

validation

Initial version

Intermediateversions

Final version

Outline projectdescription

Concurrent activities

SYSTEM ANALYSIS 20

COMPARISON OF PROTOTYPING STRATEGIES

Remarks re prototyping:

� Throw-away methods aid work done in analysis and design by being incorporated into the development life-cycle

� Evolutionary methods provide short term gains – rapid results but, on long term can become costly, difficult to maintain and tend to be less reliable

SYSTEM ANALYSIS 21

PROJECT DEFINITION

� This initial stage of project development is an attempt to formulate project requirements in broad terms by identifying exact reasons for project selection.

� A steering committee is set up to monitor project progress

� Top management and all users are involved to gain their support and participation.

� Output: An assignment brief i.e. clear definition of problem and objectives

SYSTEM ANALYSIS 22

FEASIBILITY STUDY

� Preliminary survey to determine whether a project should proceed.

� The feasibility study should be conducted quickly and in broad terms but must be sufficiently detailed for management to draw proper conclusions.

� Feasibility study must include consideration of:� TECHNICAL aspects

� ECONOMICAL aspects (incl. COST-BENEFIT ANALYSIS)

� OPERATIONAL (incl. LEGAL) aspects

� SOCIAL aspects

� Hence the main aim at this stage is to rule out bad ideas Example: Proposed project technically possible but too expensive to implement.

SYSTEM ANALYSIS 23

FEASIBILITY REPORT

� The resultant feasibility report should include:

� Recommendations

� Options considered

� Economic justification for the choice (cost-benefit analysis)

� Resource implications on staff, premises, etc…

� Development plans and time-table for introduction

� If, on the basis of the feasibility report, the project is acceptable to the steering committee, a written go-ahead is given to proceed to next stage.

SYSTEM ANALYSIS 24

SYSTEM STUDY AND ANALYSIS – PART I

� This stage covers a review of the existing system leading to a design specification for a new system. (Can help develop ideas for new system) It is a detailed study of current practices, files, documents, working methods, etc.

� Tasks falling within this stage:

1. Define and identify the objectives of the current system

2. Establish sources and types of information

3. Decide on method and collection of data

a. Interviews,

b. Questionnaires,

c. Observation,

d. Documentation study

4. Record, store and retrieve information - collection of current system data.

SYSTEM ANALYSIS 25

SYSTEM STUDY AND ANALYSIS – PART II

5. Process, adapt and present information - Documenting the existing system (if any,) involves the use of charts and other techniques to help understanding and presentation

6. Analyze information (Who What Why When Where How)

a. Are current system objectives valid? And are they being met?

b. Identification of key activities and interrelationships within the current system

c. Identification of strengths and weaknesses of the current system

d. Opportunities and constraints of the current system

e. Establishing the resource use of the current system

SYSTEM ANALYSIS 26

SYSTEM STUDY AND ANALYSIS – PART III

7. Statement of requirements: This is the output report from the current stage of the system life cycle. Ideally, it should be prepared jointly by the users and analysts for management approval. The SOR should include:

a. criticisms of the existing system

b. the findings of the analysis stage and how the system can be improved

c. the objectives of the proposed system

d. a design specification including main interfaces with other systems

e. constraints and sample outputs

f. user responsibilities

g. an update of costs and development plan, and time-tables for introduction

SYSTEM ANALYSIS 27

SYSTEM DESIGN

� This stage is essentially a process of moving from a general outline to a detailed final product. System design leads to a SYSTEM SPECIFICATION that should:

� Provide a basis of agreement and a source of reference between management, users and analysts.

� Serve as a specification of software programs, dialogues and manual procedures within the system.

� The system specification should be presented to the steering committee for approval.

� Structure of system specification:

SYSTEM ANALYSIS 28

CODING STAGE

� Most time-consuming stage of system development life-cycle.

� Program development stage involves programming techniques.

� Modules coded are tested, during coding, according to the test plan designed earlier (during the design stage)

� This stage is complete when all code is written, documented and successfully compiled.

SYSTEM ANALYSIS 29

CODING

� Most time-consuming stage

� Requires a lot of effort (hence expensive)

� Choice of programming language is important

� Aids to save time and money� Use of higher level languages, visual languages …

� Facilitative IDEs (Integrated Development Environments)

� Code reuse - existing library subroutines or classes, existing modules, …

� other RAD (Rapid Application Development) tools such aso screen painting software,

o report generators,

o application generators …

SYSTEM ANALYSIS 30

SELECTION OF PROGRAMMING LANGUAGE

When a program needs to be written for a particular application, selection of the language may be based on:

�Which languages have special features most appropriate to the application area

�Whether the choice of a particular language would substantially reduce development time

�Whether the programmers have the time and/or expertise to master a new language

�Whether a suitable compiler exists for the hardware the system being developed is intended to use

SYSTEM ANALYSIS 31

PROGRAM ERRORS

� Program Errors : A program may have any or all of four types of errors:

� Syntax Errors: A statement in the program violates a rule of the language,

� Semantic Errors: Violating rules of language, semantic errors are concerned with the meaning of language statements (semantics).

� Logical Errors: The program runs to completion but gives wrong results or performs wrongly in some way.

� Runtime Errors: Program crashes during execution.

� The translator detects syntax and semantic errors but the translator does NOT detect Logical and Run-time errors. These require rigorous testing for detection and correction possibly with the aid of a debugger.

SYSTEM ANALYSIS 32

PROGRAM TESTING

� There are two ways of approaching testing :

�Functional Testing (Black box testing)

Based on typical, extreme and invalid data values that are representative of those covered by the specification.

�Logical Testing (White box testing)

Based on examining the internal structure of the program and selecting data which gives rise to the alternative cases of control flow.

� Remarks:� Functional testing is not adequate by itself.

� Logical testing by the programmer during program development is most effective.

SYSTEM ANALYSIS 33

TEST DATA AND TEST CASES

�Test data must include:

�Valid values,

�Invalid values

� limit values

�Select test cases such that:

�Every statement in the program is executed at least once.

�The effectiveness of all sections of code that detects invalid input is tested.

�The accuracy of all processing is verified.

�The program operates according to its original design specifications.

SYSTEM ANALYSIS 34

THE TESTING PROCESS

� Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules, which are composed of object classes (or procedures and functions – depending on the design (and language) paradigm adopted. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation.

� In general, the sequence of activities is:

COMPONENT TESTING INTEGRATION TESTING USER TESTING

SYSTEM ANALYSIS 35

TESTING STAGES

� As defects are discovered at any one stage, they require programmodifications to correct them and this may require other stages, in the testing process to be repeated. (regression testing)

Unittesting

Moduletesting

Sub-systemtesting

Systemtesting

Acceptancetesting

ComponentTesting

IntegrationTesting

UserTesting

SYSTEM ANALYSIS 36

UNIT AND MODULE TESTING

� Unit testing Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components.

� Module testing A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures and functions. A module encapsulates related components and so can be tested without other system modules.

SYSTEM ANALYSIS 37

SYSTEM TESTING

� Sub-system testing : This phase involves testing collections of modules which have been integrated into sub-systems. Sub-systems may be independently designed and implemented. The most common problems which arise in large software systems are sub-system interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces.

� System testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors which result from un-anticipated interactions between sub-systems and system components. It is also concerned with validating that the system meets its requirements.

SYSTEM ANALYSIS 38

ACCEPTANCE TESTING

� Acceptance testing the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data.

� Acceptance testing may reveal errors and omissions in the system requirements definition because the real data may ‘exercise’ the system in different ways from the test data. Acceptance testing may also reveal that the system facilities provided do not meet the exact users’ needs or the system performance is unacceptable.

� Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for a single client. The alpha testing process continues until the system developer and the client agrees that the delivered system is an acceptable implementation of the system requirements.

� When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the developers. After this feedback, the system is modified and either released for further beta testing or for general sale.

SYSTEM ANALYSIS 39

TEST PLANNING

� Careful test planning is needed to get the most out of testing and to control testing costs.� Test planning is concerned with setting out standards for the testing process.� The major components of a test plan are as follows:

� The testing process.A description of the major phases of the testing process. (maybe as described earlier)

� Requirements traceability.Users are most interested in the system meeting its requirements and testing should be planned so that all requirements are individually tested.

� Test Items.The products of the software process which are to be tested should be specified.

� Testing Schedule.An overall testing schedule and resource allocation for this schedule. This, obviously, is linked tothe more general project development schedule.

� Test recording procedures.It is not enough simply to run tests. The results of the tests must be systematically recorded. It must be possible to audit the testing process to check that it has been carried out correctly.

� Hardware and software requirements.This section should set out software tools required and estimated hardware utilisation.

� Constraints.Constraints affecting the testing process such as staff shortages should be anticipated in this section.

SYSTEM ANALYSIS 40

TESTING STRATEGIES

� A testing strategy outlines the general approach to the testing process. Different testing strategies may be adopted depending on the type of system to be tested and the development process used.

� Some types of testing strategies:

1. Top-down testing where testing starts with the most abstract components and works downwards.

2. Bottom-up testing where testing starts with the fundamental components and works upwards

3. Thread testing which is used for systems (usually real-time) with multiple processes where the processing of a transaction threads its way through these processes

4. Stress testing which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations.

5. Back-to-back testing which is used when versions of a system are available. The systems are tested together and their outputs compared.

SYSTEM ANALYSIS 41

IMPLEMENTATION : CROSS-OVER TECHNIQUES

� A complete replacement at one go usually taking place during a slack period.

� It is cheap, simple, clear-cut method but risky because there is no fallback position.

� Used when� Users have previous experience of computerisation

� The new system is not directly comparable with the old

� The time scale is tight

� Resources are limited e.g. no extra staff

� The system is small

Old System

New System

�Straight (Direct) Changeover

SYSTEM ANALYSIS 42

IMPLEMENTATION STAGE

� Project Management

The planning and scheduling of resources, staff, equipment, …

� Staff training and education

Without interrupting flow of work, good courses and manuals

� File conversion

Reformatting files for the new system

� Documentation check

Ensuring comprehensive and up-to-date systems

� Deciding on method of changeover

Switching over from the old system to the new system

� Handover

SYSTEM ANALYSIS 43

IMPLEMENTATION : CROSS-OVER TECHNIQUES

� Parallel Changeover

� Includes a period when the old and the new system run in parallel until everyone is satisfied that the new system is running successfully and then the old system is dropped.

� Expensive changeover – involves more work

� Difficult to make comparisons between the results obtained by both systems

� Less risky – standby facilities, useful cross check, gradual changeover.

Old System

New System

SYSTEM ANALYSIS 44

IMPLEMENTATION : CROSS-OVER TECHNIQUES

� Phased (Incremental) Changeover

� The changeover is in a number of stages rather than all at once.

� The division may be based on:� Location – say, one branch of a retail group each month

� Subsystem –say, sales order processing system, then payroll system, then accounting system, …

� Subfile – say, in a customer account file, names beginning A – F, then G-L, …

� Spreads the burden of the workload over time

� Presents an opportunity to learn from problems of a previous phase

� Takes longer than other changeover methods

� Difficult to control a system working in two modes

New SystemOld System

SYSTEM ANALYSIS 45

IMPLEMENTATION : CROSS-OVER TECHNIQUES

� Sometimes a part of the system which can be treated as an entity is upgraded. E.g. the stock control system of a single shop which forms part of a whole retail chain.

� The changeover of the entity is done using direct or parallel changeover.

�When the pilot implementation is satisfactory, the project to upgrade the whole system is undertaken.

Old

New

Old

New

Pilot

SYSTEM ANALYSIS 46

CONTROL AND REVIEW STAGE

� Control

� Setting and redefining standards against which performance can be compared.

� Measuring planned against actual performance

� Taking corrective action where necessary so that system meets its objectives

� Review

� At predefined intervals of time, system should be reviewed to give overall picture of progress made

� Findings help any subsequent system analysis

SYSTEM ANALYSIS 47

SYSTEM MAINTENANCE

�System maintenance implies another system life cycle.

�MAINTENANCE may be:

�Adaptive maintenance due to identified new requirements

�Corrective maintenance due to identified errors

�Perfective maintenance due to identified improvements to the existing set up.

�Aids to maintenance:�Modular design�Use of structured system development techniques�Readable Code�Good Documentation

17%

18%

65%

Corrective Adaptive Perfective

SYSTEM ANALYSIS 48

DOCUMENTATION

Documentation may be presented in different forms:

� Manuals

� Online help

Documentation types:

� User Manual

� Operations Manual

� Technical Manual

(program listing includes inline documentation)

SYSTEM ANALYSIS 49

USER MANUAL

Typical information:

� Overview of options available

� Guidance on the sequence of operations to follow

� Screen shots showing screen input forms

� Instructions on how to enter data

� Sample report layouts

� Error messages that may be displayed and what action to take

SYSTEM ANALYSIS 50

OPERATIONS MANUAL

The operations manual includes all the procedures necessary to run the system.

Typical information:

� System setup procedures, including details for each application of the files required and consumables requirements

� Security procedures

� Recovery procedures in the event of system failure

� A list of system messages that might appear on the operator’s console and what action to take

SYSTEM ANALYSIS 51

TECHNICAL MANUAL

Typical information included in the technical manual:

� Overall system plan

� Data organisation and flow

� Full annotated listing

� Details of test data and results

SYSTEM ANALYSIS 52

DECISION TABLES

� A DECISION TABLE is a tabular representation of expressing process (decision) logic.

� Decision tables are used to analyze problems.

� Conditions applying to the particular problem are identified; and the actions to be taken as a result of any combination of the conditions arising are set out.

ACTION ENTRIES

ACTIONS

CONDITION ENTRIES

(Outcome)

CONDITIONS

(Questions)

SYSTEM ANALYSIS 53

DECISION TABLES - EXAMPLE

Example: Discounts allowed on customers’ order are required to comply with the following policy:“Any order from a credit-worthy customer attracts a discount of 5% if the order amounts to €500 or more, and a discount of 3% if the order amounts to less than €500. Other circumstances must be referred to the supervisor for a decision.

XXRefer to supervisor

XAllow discount of 5%

XAllow discount of 3%

Actions

NYNYIs credit-worthy customer?

NNYYIs order €500 or more?

4321Conditions

Rules

SYSTEM ANALYSIS 54

DECISION TABLES - EXERCISE

Use a decision table to represent the following system logic:

A credit union pays interest to its depositors at the rate of 6% per year. A number of constraints to this policy are:

� Accounts of less than €100 are not paid interest.

� Accounts of less than €1,000 are paid the normal 6%,

� Accounts of €1,000 or more that have been with the union for more than one year get paid the normal 6%, plus a bonus of 1%.

SYSTEM ANALYSIS 55

MODULARITY

A module is a self-contained subprogram, which performs independently one specific task.

Advantages in using modules� Re-usability

� Easier to read, debug and maintain (update)

� Natural division of work

Remarks� Modules can be compiled separately

� Driver program is required to further test modules

PROCESSINGInput

ONE entry point

Output

ONE exit point

SYSTEM ANALYSIS 56

TOP-DOWN MODULAR APPROACH

� Problem is broken down into a number of components modules. Each component is progressively decomposed into smaller, more manageable components until each component (or module) can be easily comprehended.

Problem

Module A

Module A [1] … Module A [n]

Module B

Module B [1] … Module B [n]

Module A1 [1] … Module B1 [1] …

SYSTEM ANALYSIS 57

BOTTOM-UP MODULAR APPROACH

� Individual manageable modules are initially identified; progressively these are combined to form larger modules until the original problem is fully addressed.

� Method recommendable only in the case of experienced programmersand the existence of a library of previously developed modules

Module A[1] Module A[2] Module B[1] Module B[2]

Module A Module B

Original Problem

SYSTEM ANALYSIS 58

STRUCTURE CHARTS

� Structure charts are used to represent the high level modular design of a programming project.

� Consider the following structure chart for solving a teacher’s examination results processing problem:

Process Examination Results

Input Details Process Details Output Details

InputResults

Validate input

Determine Grade

Category

Determine Grade Counts

Print Individual Results

Print Statistical Summary

Print Error Listing

Exercise: Draw a structure chart to representing the issuing of reminder

letters for borrowers in a book library system

SYSTEM ANALYSIS 59

DATA FLOW DIAGRAMS

� Data Flow Diagrams (DFDs) provide a pictorial representation for recording:

o Where the data originates

o What processing is performed on it (data) and by whom

o Who uses the data

o What data is stored and where

o What output is produced and who receives it.

SYSTEM ANALYSIS 60

DFD SYMBOLS

Source/destination

Process

Data store

Data flow

An operation performed on the data.A process will use or alter the data in some wayE.g. sorting, using data to print a report.

A data source or destination which is extended to the system. E.g. people/departments who provide data or receive output

Data store denotes object where the data is stored. E.g. data file, transaction file, input document, report

The arrow represents the movement of data between entities, processes or data stores.Arrows should be clearly labelled to show what data is being transferred. Do not draw data flow directly between data stores and external entities - there should be a process box between them to show the operation performed

SYSTEM ANALYSIS 61

LEVELLED DFDs

� Since it is often impossible to represent a complete system in a single diagram, two or three levels of data flows may be used each showing progressively more detail.

� Consider the following example:

The payroll system of ABC LTD:-

At the end of each week, time sheets are collected and sent to the salaries department. Here, the payroll data is entered via a key-to-disk system, verified and validated, producing a new valid transaction file on disc and an error report. This file is used to update the employees master file , issue payslips and electronically transfer payment to employees’ bank accounts.

SYSTEM ANALYSIS 62

PAYROLL SYSTEM:- TOP-LEVEL DFD

Process Payroll

Time sheets

Payroll summary data

Cheque and payslip data

Employees

Employees

AccountsDepartment

Top level showing a single process:

SYSTEM ANALYSIS 63

PAYROLL SYSTEM :- SECOND LEVEL DFD

Employee number, hours worked, batch control total

Employee number, total pay, deductions… for all employees

Rate of pay, tax code…

Batch time

sheets

Time sheets Time sheet data and batch control totals

Verify and

validate

Valid weekly transaction file

Invalid data batch and control totals

Prepare payroll

Employee number, name, total pay, deductions…

Cheques and payslips

Employee number, hours worked

Print Payroll

Summary

Print and distribute cheques

and payslips

Employee number, total pay, deductions… for all employees

Employee

AccountsDepartment

Employee

Error Report

Employeefile Year-to-date pay…

validated data

SYSTEM ANALYSIS 64

STOCK CONTROL SYSTEM QUERY:- TOP-LEVEL DFD

� In relation to this query, the user provides the stock number and the system outputs the item’s description and quantity of item in stock.

� Top-level DFD to this query:

Stock ReportRequest

Stock Number

Stock description and

quantity in stock

Stock fileEnd User

Query request input

Unformatted query request output

SYSTEM ANALYSIS 65

STOCK CONTROL SYSTEM QUERY:-SECOND LEVEL DFD

Validation process Stock file

Description of stock report

Stored output formats

Stock number

Stock file processing

Select report output format

Stock Description

Valid Stock Data

User

SYSTEM ANALYSIS 66

DFD EXERCISE

� A student can register by mail for a college course by submitting a registration form with their name, ID number and the number of courses they wish to take. The system verifies that the course is not full and enrolls the student on each course for which a place is still free. The course file and student master files are updated and a confirmation letter is sent to the student to notify them of their acceptance or rejection for each requested course.

� Draw a DFD diagram illustrating how data flows through this student registration system.

Second level DFD Solution: Heathcote& Langfield, “‘A’ level Computing”, 5th ed. p.319

SYSTEM ANALYSIS 67

FLOW CHARTS

� A FLOWCHART is a graphical representation of the sequence of operations in a system or program.

� A SYSTEM FLOWCHART is used to show how data flows from source documents through the computer (system) to final output distribution – it gives a complete overview of a system. E.g. Sequential file processing diagram

� A PROGRAM FLOWCHART shows the sequence of instructions to achieve a particular task (algorithm).

SYSTEM ANALYSIS 68

FLOW CHARTS SYMBOLS

Printed output Communications links

Data preparation

Manual operation

Tape/sequential access medium

Sort processManualInput

Off-page connector

DiskDirect Access

storage

Start/end Process Input/Output DecisionPre-defined Process

Connector Flow

SYSTEM ANALYSIS 69

SYSTEM FLOWCHARTS

Update Process

MF

OldMF

NewMF

SEQUENTIAL FILE UPDATE PROCESS

Data validation

Display input data

Data Entry

Collection ofDocuments

ErrorReport

TransactionFileKEY-TO-DISK

INPUT SYSTEM

Example 1:

Example 2:

SYSTEM ANALYSIS 70

PROGRAM FLOWCHART

Y

Start

Read inputName,index,

Mark

IsMark = -1?

PrintIndex number

IsMark<40?

IsMark<70?

Print “FAIL” Print “PASS” Print “CREDIT”

Total CountT = F+P+C

Print F/T*100% P/T*100%C/T*100%

IncrementCredit countC=C+1

IncrementPass countP=P+1

IncrementFail countF=F+1

End

NY

N

N

Y

EXAMINATION RESULTS PROCESS

SYSTEM ANALYSIS 71

PROGRAM FLOWCHART (Another Example)

Start

Input N

F = 1M = 1

End

F = F * M

M = N ?

M = M + 1

Print F

COMPUTING FACTORIAL N (N!)

N! = 1*2*3* … *N

ExerciseDraw the flowchart for the algorithm which generates the first N terms of the fibonaccisequence where N is specified by the user.

Fibonacci Sequence 0 1 1 2 3 5 8 …

SYSTEM ANALYSIS 72

PSEUDOCODE

� PSEUDOCODE represents a way how we can express the sequence of instructions to achieve a particular task (algorithm) independently of any programming language.

� Pseudocode consists of English-like statements very close to the target programming language to be used for developing the software.

Examples:

SWAP TWO INTEGER VARIABLES

Assume swap integer variables X, YDeclare integer Temp

Temp = XX = YY = Temp

CHECK WHETHER AN INTEGER VARIABLE IS EVEN OR ODD

Assume Integer variable Xif (X modulo 2 == 0)output message “even”else output message “odd”

EXERCISE: Use pseudocode for expressing the algorithm which generates factorial n (n!)

SYSTEM ANALYSIS 73

ENTITY-EVENT MODELLING

� An ENTITY-EVENT MODEL is an abstract representation of how the entities of a system are effected by business events - business events trigger processes which in turn affect entities.

� An Entity-Event Model identifies business events and defines the effects which these events have on the system’s entities. It also defines the order in which these events take place.

� Entity-event modeling (similar to Jackson System Development techniques), is a technique used in relation to the SSADM standard.

SYSTEM ANALYSIS 74

ENTITY-EVENT MODEL

� An entity-event model consists of

� A set of entity life histories (ELH),

� A set of effect correspondence diagrams (ECD)

� An Entity Life History shows the sequence of effects which business events cause on a particular entity type.

� An Effect Correspondence Diagram shows the effects of business events from the event’s point of view – shows which entities are effected by a particular event.

SYSTEM ANALYSIS 75

ENTITY LIFE HISTORIES

A is a structural component which shows that effect B is followed by effect C

A

B C

SEQUENCE

A

B° C°

A is a structural component which shows that either effect B takes place or effect C but not both

SELECTION

A

B*

A is a structural component which shows that effect B takes place 0 or more times

ITERATION

PARALLELISM

A

B

D*

C

E*

A is a structural component which shows that either, both (in any order and any number of times), or neither of effects D and E may occur

� Entity life histories are drawn using the structured design (orprogramming) constructs of sequence, selection, iteration and parallelism

SYSTEM ANALYSIS 76

ELH EXAMPLE

BOOK

New Book Acquisition Book DiscardedLibrary Book Life

Book details changes

Book State°

Book available changes

Book details change* Book available change*

Book Borrowed° Book Returned°

The top node represents the entity, the next level nodes denote the organization of events, the next level nodes denote the individual events which change the entity, and the lowest level nodes denote the tasks which achieve the higher level nodes.

SYSTEM ANALYSIS 77

EFFECT CORRESPONDENCE DIAGRAMS

� Effect Correspondence Diagram are drawn in relation to ELH. All entities effected by an event are listed.

Book borrowed

Loan

Book

The event ‘book borrowed’ effects the LOAN and

BOOK entities

Place order

Order

Orderline

Set of orderlineoccurrences*

The event ‘place order’ effects several occurrences of the

ORDER entity

Booking

Booking

Provisional°

The event ‘booking’ can effect the booking entity in

different ways

Confirmed°

SYSTEM ANALYSIS 78

ELH – Another Example

� Draw the EHL diagram for the entity Borrower in the context of a book library system

BORROWER

New Membership End MembershipLibrary Member Life

Borrower detail changes

Borrower’s address°

Borrower detail change*

Borrower’s Tel.No.°

SYSTEM ANALYSIS 79

USE CASE DIAGRAMS

� The USE CASE diagram is used to give a high level view of the system, depicting who will use the system and what they will be able to do with it.

� There are four basic components to USE CASE diagrams:

actorUse case

relationshipupdate

inventory

administrator

system

Prepare report

administrator manager

updateinventory

View report

SYSTEM ANALYSIS 80

USE CASE DIAGRAMS : GENERALISATION

� GENERALIZATION is a technique used to indicate inheritance of an item. Generalization can be applied to both actors and use cases to indicate inheritance of functionality from parents.

The generalized actor plays a more specific role in the system

phone order sale

generalized actor generic actor walk-in sale

sales persontelephone operator

sale

phone order

SYSTEM ANALYSIS 81

USE CASE DIAGRAMS : RELATIONSHIPS

� INCLUDE and EXTEND are two ways of relating use cases which are highly related to each other.

� These relationships help you to identify where you can reuse functionality during system design.

updateinventory

loadinventory

saveinventory

<<include>>

<<include>>

verifycredit card

sale<<extend>>

The EXTEND relationship is used to identify when a use case can optionally be extended by functionality in another use case

SYSTEM ANALYSIS 82

CREATING USE CASE DIAGRAMS

� Steps to follow in creating USE CASE diagrams:

� identify the actors and use cases in the system

� Prioritize the use cases

� Detail each use case

� Structure the case model

� Prototype user interfaces

� Example:

A system is required to:� Allow teachers to record and update students’ results; and notify guardians if individual students’ results are not satisfactory

� Allow teachers, students and the administrator to view results recorded

� Enable the administrator to generate students’ reports

SYSTEM ANALYSIS 83

“STUDENTS’ RESULTS” USE CASE DIAGRAM

� Recording students’ results:

update grades

teacher

student

record grades

view grades

save grades notify guardian

<<include>>

<<include>><<extend>>

load grades<<include>>

administrator

generatereports

<<include>>

SYSTEM ANALYSIS 84

EXERCISE

� Create a use case diagram for the following business requirements of a point-of-sale (POS) system:� The system will allow the administrator to run inventory reports by loading inventory data from disk

� The administrator can update the inventory by loading and savingthe inventory data to and from a disk

� A sales clerk records walk-in sales

� A telephone operator is a special type of sales clerk who handles phone orders

� Any kind of sale must update the inventory

� A sale may need to verify a credit card if the purchase is a credit card purchase

� A sale may need to verify a check if the purchase is a check purchase.

SYSTEM ANALYSIS 85

SOLUTION

Updateinventory

administrator

telephone operator

run inventoryreports

phone-insale

save inventory

verify credit card

<<include>>

<<include>>

<<extend>>

load inventory

<<include>>

sales clerk

sale

<<include>>

walk-insale

verify check<<extend>>

SYSTEM ANALYSIS 86

CLASS DIAGRAMS

� A CLASS DIAGRAM consists of classes and their relationships to each other.

� The main components of a class are attributes and operations.

� Formal notation of a class:

ClassName

- attribute 1- attribute 2- attribute 3

+ operation 1 ()+ operation 2 ()+ operation 3 ()

Visibility:plus (+) signifies that the member is visible.minus (-) signifies that the member is private.hash (#) signifies that the member is visible only to classes of the same system – protected.

Remarks:•Depending on the detail you want to communicate, only the first compartment is a must. •Note the difference between a hidden compartment and an empty compartment

SYSTEM ANALYSIS 87

RELATIONSHIPS

� Two classes can relate to each other with a line and an association name:

Teacher Classteaches >

� Multiplicity allows us to indicate how many objects of one class relate to one object of another class.

Teacher Classteaches >

1 1..*

Exercise: Extend the above class diagram to include another class named “Student” where a given student may take from four to six classes at any one time and a class includes fifteen or thirty students.

SYSTEM ANALYSIS 88

INHERITANCE

� Inheritance is a way of allowing one class to gain the functionality of another class

Animal

Feline Bird

Vehicle Weapon

Tank

� Say, classes LION and TIGER, in turn, inherit the functionality of the class FELINE - inheritance hierarchies

� Classes can be derived from more than one superclass –multiple inheritance

SYSTEM ANALYSIS 89

POLYMORPHISM

� Polymorphism is the ability of two or more abstract classes to have the same interface but operate on their data differently because each has its own section of code.

Animal

NumberOfEyesNumberOfLegs

+Eat()+Sleep()

Feline

+Run()+Sleep()

Bird

+Fly()+Sleep()

Say, we use polymorphism to model the fact that each animal sleeps differently – felines sleep lying down while birds sleep standing up

SYSTEM ANALYSIS 90

EXERCISE

Create a Class Diagram using the following information:

� A student can be an undergraduate or a graduate student

� An undergraduate student can be a type of tutor

� A tutor tutors a student

� A teacher and a professor are two types of instructors

� A teacher assistant can assist a teacher and a professor, but a teacher can be assisted by only one assistant, while a professor can be assisted by up to five assistants

� A teacher assistant is a type of graduate student

SYSTEM ANALYSIS 91

SOLUTION

Tutor Instructor

Teacher

Student

Undergraduate Graduate

tutors>

Professor

Teacher Assistant

<assists assists>

0..1

1

0..5

1

SYSTEM ANALYSIS 92

SOME SDLC STANDARDS: UML & SSADM

� Both UML and SSADM are standards within the SDLC study field.

� Each has its own strengths and weaknesses

� A comprehensive overview SSADM

� A comprehensive UML tutorial (overview)

� A comparison of SSADM and UML