System Analysis

System Life Cycle Definition

The sequence of actions carried out during the development of a new data processing application (information system).

System Life Cycle

1. Problem Definition

2. Feasibility Study

3. Requirements Elicitation

4. System Analysis

5. Systems Design

6. Implementation

7. Coding and Testing

8. Maintenance

9. Retirement

Problem Definition

Orgainzation would opt to upgrade or create a new system becuase current system may no longer be suitable for its purpose, technological developments and current system may be too inflexible or expensive to maintain

Feasibility Study (TELOS)

To understand the problem and determine as much as possible all the issues involved should the problem be tackled

Technical Feasibility

Investigate whether the technology exists to implement the proposed system, or whether it is a practical proposition

Economic Feasibility

Establish if proposed system is cost-effective - if benefits do not outweigh costs, it is not worth going ahead

Legal Feasibility

Determine if there is any conflict between the proposed system and legal requirements - e.g. the Data Protection Act

Operational Feasibility

Determines if the current work practices and procedures are adequately supported by the new system: how change affects the working life of workers

Schedule Feasibility

Looks at how long the system will take to develop, or whether it can be done in a desired time-frame

Requirements Elicitation

The aim is to interact with the customers and end-users in order to find out about the domain requirements, what services the system should provide as well as other constraints

Interviews

The analyst should be able to determine what information is gathered and the quality and depth of that information

Questionnaire

A document containing a number of standard questions that can be sent to many individuals

Observation

A method of gathering information and observing the people, events and objects

Inspection of Documents

This involves looking at the paperwork for the current system

Off-the-Shelf Product

The software is already built, the requirements would not be used to design or develop the system but rather to understand the capabilities that a product has and to compare different products

Purpose-Built Development

A software built from scratch that meets the requirements needed

Unified Modeling Language Diagrams (UML)

Privides several types of diagrams that, when used within a given methodology increase the ease of understanding an application under development

Class Diagrams

Gives an overview of a system by showing its classes and the relationships among them

Scenarios/Use-Cases

Illustrates a unit of functionality provided by the system, the main purpose is to help development trams visualize the functional requirements of a system including the relationships of the actors to essential processes

Data Flow Diagrams

Looks at how data flows through a system anc concerns things like where the data will come from and go to as well as where it will be stored

Level 0 Abstraction - Context Diagram

A basic overview of the whole system or process being analyzed or modeled

Level 1 Diagram

Should describe only the main functional areas of the system

System Design

About planning the project in detail so that system will meet user requirements

Project Planning

All about handling people; how many, where and when they are needed

System Requirement Specification

Document includes:

• Data captures methods for the system

• Data inouts/outputs to the system

• data processing within the system

• The file structure for data stirage

• The user interface and how information is accessed and indexed or sorted

• Operating system used

• Hardware to be used to run the new system

Data Dictionary

• Tables, fields, records and relationships

• Constants, variables and data structures

• validation that is required in the system

• Query structures

Testing Documentation

Once the user requirements documents and the system requirements specification have been written the analyst will know exactly what the system should be able to do

Prototyping

Captures the essential details to confirm that the design is likely to work

Modular System Structuring

A subset of procedural programming that enforces a logical structure on the program being written to make it more efficient and easier to understand and modify

Top Down Approach

Design starts at highest level - problem - and then progressively works down to the lowest level of detail

Buttom Up Approach

Design starts at individual modeules and procedures and builds up to the final system using these basic modules

Basic Flowcharts

A graphical representation of an algorithm, visually presenting the flow of data through an information processing systm, the operations performed within the system and their sequence

System Flowcharts

A way of displaying how data flows in a system and how decisions are made to control events

Pseudocode

An artificial and informal language that helps programmers develop algorithms

Jackson Structured Programming

A method for design and modelling in the small, it begins with considerations about what is known and develops a program design that becomes more complete as the model is put through continuous iterations

HIPO Diagram

Hierarchical Input Process Output diagram represents the hierarchy of modules in the software system

Decision Tables

A testing technique used to test system behaviour for different input combination

Prototyping

Represents some aspect of the full system for example a mock-up of the graphical user interface and provides an opportunity for the user to give feedback and suggestions

Evolutionary Prototyping

An initial prototype is presented to the user and they provide feedback and suggestions, these are developed by the developer who then presents a more refined prototype and the process is repeated

Throw-Away Prototyping

A small part of the system is developed and then given to the end user to try out and evaluate, the user provides feedback which can quickly be incorporated into the development of the main system, the prototype is then discarded, with the objective being to ensure that the system requirements are validated and that they are clearly understood

Prototyping Advantages

• Better quality system delivered

• Identify problems early on

• End user involvement

• Fulfill user requirements

• Cost savings

• Training

Prototyping Disadvantages

• Excessive development time

• User confusion

• Increased development time

• Too much focus on one part of the system

• Expense of prototyping

Coding

Once design stage is completed, the software developers can begin to write the code and actually develop the new system

Testing

Once the system has been developed it must be tested to ensure it is working as expected

Beta Testers

Their role is to check that the system does everyting exactly as specified in the system and user specification

Test Plan

A detailed document which a team of testers must follow which will set out every single test they are going to do on the system, what data they should enter and what result they should expect to obtain

Test Data

Any testing which cecks the validation routines should include:

• data that is within the normal range and will be accepted

• data that is on the extremen limits of the range but should be accepted

• data that should fail should be tested

Iteration

If an issue is found it may actually be a problem with the user requiement and so testing is repeated with modifications

Stages of Testing

Desk-Checking / Dry Run

Unit Testing

Integration Testing

Sytsem Testing

User Acceptance Testing

Desk-Checking / Dry Run

Programmer follows through code manually, using test data to check that an algorithm is correct

Unit / Module Testing

Testing of each individual subroutine or module

Integration Testing

Software testing in which individual software modules are combined as a group

System Testing

Testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements

User Acceptance Testing

Alpha testing in the case of bespoke software

Beta testing in the case of packaged product

Black Box / Functional Testing

Doesn’t explicitely use knowledge of the internal structure or code so the test engineer need no know of the internal working of the application (not adequete by itself)

White Box / Logical Testing

Depedns on the code logic and derives from the program structure rather than its function, the code is studied and tests are created to test each possible path at least once, testing by the programmer during program development is most effective

Types of Documentation

User Documentation

Technical Documentation

Operational Documentation

User Documentation

Provided to the user and gives an overview of how to use the system

Technical Documentation

Intended for technical maintenance of the system, egineers and software developers will refer to the technical documentation in order to make changes to the system after it has been installed

Operational Documentation

Documentation of procedures neccessary to run the system

Implementation Methods

Direct

Parallel

Phased

Pilot

Direct Method

The company switched off the old system and implements the new one

Parallel Method

The organisation runs both the old and new system in parallel for a time, once the new system is working properly and staff are ready they will change over completely

Phased Method

The old system is still active but parts of the new system are brought in, as new parts are brought in the system will change over to the new system

Pilot Method

The complete new system is installed and tested in a small number of departments or branches, they then use the system and report their feedback and any issues to the analyst, once it is working properly, the new system is implemented across the organisation

Staff Training

Staff needs to be shown how to use the new system and how to access help should they run into difficulties, they are also fiven a user manual

Evaluation

Looks at the overall project and considers how things went

Maintenance (CAPP)

Corrective Maintenance

Adaptive Maintenance

Perfective Maintenance

Predictive Maintenance

Corrective Maintenance

Problems are identified with the system after installation, a fault report is raised and the developers fix the problem

Adaptive Maintenance

Occurs as a result of external influences or strategic changes within the company (ex: VAT rate changed from 18 to 20)

Perfective Maintenance

Over time, the end user will often find tweaks or minor improvements which could improve the way the system works

Predicitve Maintenance

Uses data analysis tools and techniques to detect operational anomalies and potential defects in equipment and processes so that they can be addressed before failure occurs