Systems Analysis and Development

Systems Development Methodologies

Useful terms

Top-down: A new system is built by breaking the main goals of a system into subsystems.

Bottom-up: A new system is built based on requirements for output or parts of an existing system.

Linear

A waterfall / cascade model, in which tasks are completed sequentially, one after the other.

Advantages: Better for large projects: easy to coordinate, documentation can be coordinated after each stage Disadvantages: Inflexible, slower than Iterative

Prototyping

NOTE: Prototyping is not technically a standalone Systems Development Methodology, but rather an approach which is incorporated in a number of Systems Development Methodologies.

Prototyping involves creating prototypes of the software, i.e. incomplete versions.

Advantages: Increases client involvement Disadvantages: Increases cost of development

Iterative

Iterative development involves a number of steps being repeated.

RAD usually refers to an iterative development methodology.

Advantages: Allows for backtracking - more flexible than Linear development; also usually faster than Linear development. Developers can get a system working quickly. Disadvantages: Worse for large projects. Can cause 'feature creep' i.e. unnecessary/unplanned features can be implemented at the request of the client; normally produces a lower documentation quality than Linear

Systems Development Life Cycle

Preliminary Analysis

Problem Definition

What are the boundaries of the problem? The problem statement should specify what actions must be taken to fix the problem.

Feasibility Study

Operational: Determines whether a project can actually be implemented. Considers topics such as legal and ethical issues, the timeline for the project etc.

Technical: Determines whether a system can actually be implemented. Involves an examination of the scalability, the reliability of hardware and software, and the resources that will be required to operate the system.

Economic: Determines expected benefits vs expected costs of the new system. Costs include training, hardware / software etc.

Schedule: Determines whether the deadline is achievable / reasonable.

Analysis

Data Gathering

Information about the current system is gathered.

Some methods that can be used:

• Interviews
• Surveys
• User / System documentation

Data Analysis

The data that has been collected is analysed and interpreted.

This is the role of the Systems Analyst, who uses the analysed data to develop a logical model of the current system.

The analyst focuses on each of the following aspects of the system:

Logical Operations: Describes what data and information is being used by the system / its flow through the system. Tools for describing logical operations include Context Diagrams, DFDs, Data Dictionaries.

Data Processing: Examines how the data is converted into useful information. Tools include decision tables / trees, IPO charts, and flowcharts.

Physical System: Looks at the relationship between physical components of the system. Tools used include structure charts, system flowcharts and hierarchy charts.

Logical Design

After the analysis is completed a logical design can be created for the new system.

A logical design is a description of what the new system will do.

Key criteria

Key criteria should be created covering hardware and software requirement, constraints on the development due to economic / other factors, security procedures etc.

Design

Physical Design

After the logical design and key criteria are completed a physical design must be created.

The physical design describes how the key criteria will be achieved.

The final physical design will include I/O specifications, program / data structure specifications, security specifications and a review of the physical design.

All hardware and software must be specified in detail.

Selecting Hardware: What Operating System should be used? What are the current staff / users familiar with? What kind of processing needs to be done? Who will the system be used by?

Specifying a Network: What type of network will be required? The layout of the network must be specified. Types of computers (laptop/desktop) must also be specified.

Software Requirements: What software is needed by the system? How much data must be handled? A choice between Commercial and Custom-Built software must be made.

Advantages of Commercial software: Reduced implementation time, less technical support required, usually more reliable; almost always a better choice if software exists that meets the requirements of the system

Advantages of Custom-Built software: Software can be integrated with the current technology, which may not be supported by commercial software. This is essentially the only choice if commercial software does not meet the requirements of the system.

Development

In the development phase, a project management plan must be formulated. A project manager should also be appointed.

Hardware and software are acquired during the Development phase.

Project Management involves two main areas, production and testing management and implementation management.

Timeline Scheduling

Timelines are used to keep track of all activities that must be completed and their durations.

CASE tools are used for this purpose (see below).

Development Methodologies

See the Systems Development Methodologies section above.

Testing

A test plan must be created that covers the effectiveness and efficiency of the system. Should cover all aspects of the system: hardware/software, I/O, processing, UI, etc.

There are three phases to testing:

Unit Testing: Test that each individual subsystem / unit of the system works.

System Testing: Test that the units work together correctly.

Volume Testing: Test the system using large quantities of data to ensure that it works with the expected workload.

System Review

The system must be reviewed after being developed and tested. The new system is checked against the key criteria before being handed over to the client.

Implementation

In this stage the new system is set up. The system is tested and users trained in this stage.

Conversion methods

There are four methods that can be used to implement the new system.

Direct Cut: The new system is started immediately and the old system stopped. Disadvantages include the fact that if the new system does not work as expected it could cause a lot of downtime.

Phased: The new system is implemented a stage at a time.

Pilot: The whole system is implemented but only used by a few staff, which is useful for testing it within the organisation

Parallel: Both systems are run simultaneously. If cost is not an issue this is the best method as the users of the new system can be trained while using the old system, and this does not cause the issues associated with Direct Cut.

Documentation

Different types of documentation are created. Some examples include a user guide, a user manual, a quick start guide, a procedures manual, a troubleshooting manual and a technical reference.

Evaluation and Maintenance

In this stage the new system is reviewed to ensure that it functions as intended and solves the problem it was originally intended to solve. This should take place after the system has settled down; the users should be comfortable with the new system by the time this takes place.

Evaluation

Evaluation criteria are created for the evaluation of goals of the system.

Factors involved in the evaluation criteria include the usability, efficiency, costs, required maintenance etc.

Qualitative evaluation: Involves asking users / managers / etc. of the system their opinions, suggested improvements they may have, any bugs they may have noticed etc.

Quantitative evaluation: Involves measuring and recording statistics about the system such as speed.

Some methods for measuring data include surveys/interviews, recording customer complaints and user comments, quality assurance testing, statistics, and staff reactions.

Maintenance

A regular maintenance schedule must be developed to ensure that there are no ongoing issues with the system; bugs can be fixed and enhancements provided.

Software upgrades can be described in any of the following ways:

Slipstream: A small upgrade to the software that should have minimal impact upon users.

Patch / Bugfix: A small change that corrects a bug.

Release: An improvement of the system, often with minor changes to the documentation being made and possibly retraining of staff.

Version: A large improvement to the current system is made.

Gathering Data

See the Analysis section above and the Evaluation heading under Evaluation and Maintenance, which list some data gathering techniques used in the Systems Development Life Cycle.

CASE Tools

CASE stands for Computer Aided Software Engineering.

Gantt charts and PERT (Program Evaluation Review Techniques) charts are used for this purpose.

Gantt charts

Takes the form of a timeline with a number of rows. Each row indicates a task that must be completed. An arrow from a task to another task indicates that the source task must be completed before the other task can be started. If a task has multiple ingoing arrows, all of the tasks it depends on must be completed before it can be started.

The columns represent time.

PERT charts

A graphical illustration representing the tasks within a project as a network diagram.

In the Western Australian ATAR course, each node represents a task that must be completed. Each arrow indicates a dependency. The time taken to complete a task is represented by the arrow; the arrow has a number on it representing the time taken.

(If multiple arrows go into the same node, they do not all have to be labeled; since the time taken to complete a task is always the same, the other arrows can be represented by dotted lines.)

Critical Path

The longest path through the PERT chart. (Also the rightmost point of the rightmost bar in the optimal Gantt chart.) Represents the total time that will be necessary to complete the project.

Slack time is the amount of time that a task's duration can be increased by without it impacting other tasks i.e. the critical path.

Context Diagrams

A context diagram represents the inputs and outputs of a system.

• The actual system is represented by a named circle. For example, for a system at a bookstore, the circle would be labelled "Bookstore System". The word "System" must be in the name.
• Only entities outside of the system are shown, and they are represented by rectangles. For example, if a customer were to be shown purchasing books from the bookstore, a rectangle would be created labelled "Customer". It is important to distinguish between entities that are inside and entities that are outside of the system; generally, if an entity is receiving data from the system or sending data to the system, it is external.
• Entities are shown to interact with the system through arrows representing the flow of information. For example, if a Customer were to send their personal details to the Bookstore System, an arrow would be created labelled customer_details. The label should be chosen such that it doesn't imply a specific form being used, e.g. paper; as a general rule, append details to the end.
• Data flows must of course have exactly one arrow.

Data Flow Diagrams

A DFD graphically models the data flows within a system.

A DFD shares the symbols for a Data flow and an External Entity with a Context Diagram: an arrow is used for indicating the flow of data and a rectangle to represent an external entity.

In addition, two other symbols exist. A Process is drawn as a circle, and is labelled with a number and a verb phrase. In a L0 DFD, the process is labelled with an increasing number. For example, a process to confirm a user login could be named 1.0 Confirm User. A Data Store is represented with two horizontal lines, one above and one below the label of the data store. The label should represent the type of data being stored, not the hardware being used.

Rules:

• Everything from the Context Diagram section still applies (except for the information about drawing a circle for a System, which is not represented in a DFD).
• Every process must have at least one inflow and one outflow. If a process has no inflows it is a miracle; if a process has no outflows it is a black hole.
• Entities and Data Stores cannot communicate directly; they must communicate through a process. (Entities cannot communicate with Entities and Data Stores cannot communicate with Data Stores either.)
• Data stores cannot transform data; only processes can transform data.
• Obviously data stores with no outputs are redundant; like process with no outflows they are also called 'black holes'.

Level 1 DFDs

A Level 1 DFD indicates the inner workings of a particular process.

In a Level 1 DFD, a few things change.

• External entities are not drawn; the data flows should still be shown, but they should come from and go to empty space. Data stores are still drawn.
• When labelling a process, instead of the first number being incremented, the second number is incremented. For example, if you were drawing a L1 DFD for the process 4.0 Purchase Book, the processes would be labelled 4.1 [something], 4.2 [something] and so on.