B107 Principles of Information Systems

B107 Principles of Information Systems

TOPIC 12

System Development Lifecycle

Objectives:

·  To obtain an overview of the System Development Life Cycle (SDLC).

·  To introduce System Development Methodologies.

·  To examine the phases of the SDLC in terms of the tasks that need to be undertaken, the deliverables and the outcomes.

·  To describe two approaches to the Design Phase and the relationship between them.

·  The classic, or traditional approach.

·  Prototyping

·  To describe the process of seeking proposals for components which are to be purchased and evaluating those proposals to select the best ‘deal’.

·  To compare various approaches to acquiring software.

References:

·  Stair & Reynolds, Chapters 12 and 13.

OVERVIEW

There are different approaches to the systems development process.

However, most developers follow a series of fairly strictly laid down stages composing a model of the systems development process. This is generally known as the Systems Development Life Cycle (SDLC).

·  Different authors use different numbers of phases and different names for them.

A system development methodology is a set of rules, procedures and standards that define how the SDLC is carried out.

·  There are many different ones – commercial and in-house

·  Generally each SDLC phase carried out according to a system development methodology has a set of 'deliverables' - reports etc to be delivered to the client or the project leader. They frequently become input to the next phase.

THE PROBLEM SOLVING MODEL

Stair’s SDLC:

Systems Investigation

Systems Investigation is where you gather enough data to understand the problem.

It is very important to involve all the stakeholders at this stage of the project (see Topic 11).

Includes a feasibility study

·  Economic feasibility - would the project be cost effective?

·  Technical feasibility - can technology needed be implemented and used in this environment?

·  Operational feasibility - can the solution be put into operation?

·  Schedule feasibility - can the project be done in time?

Systems Analysis

If there is an existing system it is analysed. This involves a number of data gathering techniques and activities, e.g.:

·  Interviewing users.

·  Examining the documents that are used to input data to the system or which are output from the system.

Once all the data has been gathered, the existing system is described in detail using narrative and models (eg data flow diagrams (DFDs) and entity relationship diagrams (ERDs)) – these are deliverables from this phase.

A set of possible alternative implementations is also produced. Each alternative is evaluated on the same criteria, frequently by scoring the alternatives on weighted criteria and one chosen – the alternative and evaluations are deliverables from this phase

Systems Design

The recommended solution is planned in detail. All 5 components of an IS must be designed

If are doing a traditional design – includes:

Logical design - what the system will do.

·  Process modelling – DFDs + algorithms and decision tables to capture logic required for processing

·  Data modelling – ERDs

·  Design of the computer-user interfaces – inputs, outputs, user navigation through system.

Physical design – technical specification

·  The implementation environment is finalised:

Ø  the hardware platform

Ø  the operating system

Ø  programming languages

Ø  the DBMS

·  Finalising database design - how the data will be implemented in the chosen DBMS.

·  Detailed program design

·  Distributed processing design - choices are made about the distribution of data and its processing.

Question

What does this DFD do?

Question

What does this algorithm do?

IF Quantity_In_Stock is less than Minimum_Order_Quantity THEN

generate new order

ELSE

do nothing

Question

What does this decision table do?

Condition/
Course of action / RULES
1 / 2 / 3 / 4 / 5 / 6
Employee type / F-T / C / F-T / C / F-T / C
Hours worked / <40 / <40 / 40 / 40 / >40 / >40
Pay base salary / X / X / X
Calc hourly wage / X / X / X
Calc. overtime / X
Produce absence report / X

F-T - Full-time C = Casual

Question

What does this ERD do?

May use prototyping instead of, or as part of, traditional design

A prototype is a working software model of a system, or part of the system.

Prototyping allows users to get a picture of what the system will be like and hence heps them clarify their requirements.

A prototype may be:

·  Thrown away once completed and the real system built from scratch, probably using different software development tools to those used for the prototype.

OR

·  Developed until it becomes the finished system. Prototyping is then the methodology used in both System Design and System Development.

Steps in developing a prototype:

Making decisions about acquiring system components (eg hardware and software) is also part of system design

There may be a number of components that need to be purchased in a project. Commercial software might be a viable alternative to writing custom software. Hardware components may also need to be purchased.

This should be done in a structured and objective way in order to get the most appropriate items and the best deal!

An request for proposal (RFP) is an invitation to selected vendors to make a proposal to sell you the components you need.

·  The RFP details the new system, the specifications of the components to be purchased, the timetable within which they must be installed and the budget.

Vendors respond with a proposal stating what they can supply, by when and how much it will cost.

All vendor proposals must be objectively compared and evaluated.

·  The most important factor is how closely what is offered conforms to what is needed.

·  Price is another important factor.

·  But so are quality, support that is offered and the timing of the sale.

·  Each factor should be given a score for importance. Proposals are scored and the proposal with the highest score should get the contract to supply.

System development and implementation

This stage may be called System Implementation (Stair) or System Development, or divided into two stages (Beekman).

System development tasks

Software - make or buy

There are three ways to obtain a new IS.

·  Buy a commercial package which needs little or no customisation.

·  Buy a commercial package and customise it.

·  Write the system from scratch.

Advantages and disadvantages of commercial software

Because commercial software is sold many times, this is the least expensive way to obtain a new system. Other advantages include:

·  ‘Try before you buy’.

·  Bugs probably found and corrected before you buy.

A major disadvantage is that the system is unlikely to be exactly what is needed. In this case, the organisation may need to change its practices to fit the system, which is not ideal.

·  When you buy off-the-shelf software, you do not own the software. You only get a license to use it.

Buying commercial software and customising

When buying large and expensive packages it is possible to buy a commercial system and have the vendor extensively customise it for you.

This has a number of advantages:

·  It will be less expensive because the shell of the system will be sold many times.

·  The system will be customised to suit the goals set for it. However, some compromises may still have to be made.

It is also possible to buy a package and arrange for the customisation to be done yourself.

·  Occasionally systems are sold which include the full code, so that a developer can customise it.

·  For less expensive systems, parameters are available in which the company can enter its own information, thus customising the system to some extent. These might include the ability to enter the company name, Chart of Accounts, printer specifications.

Ø  Accounting packages are frequently written in this way.

Custom written software

With this option the package does exactly what is needed to meet the original goals set for it. However, this is the most expensive option because the system is written for only one organisation.

There are also other disadvantages:

·  No ‘try before you buy’. A commitment to the project must be made at the end of the Systems Analysis stage of the SDLC. What is actually required may or may not actually be delivered.

·  Because the organisation is the only purchaser, any bugs in the system will impact on their work and data (ie won’t have been picked up elsewhere and fixed).

Custom writing of a system can be undertaken in-house or by external consultants.

Creating and testing the system

Creating the system may involve programming in a 3GL or developing with a modern 4GL or other visual development environment.

In a traditional SDLC, development is done from the specifications produced in the Design phase. Prototyping allows development to start earlier. Once part of the system has been created, it is necessary to start testing and debugging it.

Documenting the system

Documenting a whole system is a considerable task and one which is frequently neglected.

Need:

·  User documentation

·  Technical documentation - a total picture of the system and how it was developed. This includes all deliverables from previous stages of the SDLC and hard copy of all code, forms etc.

System implementation tasks

User preparation and training

Users must be trained in the use of the new system ahead of installation.

Indirect users and stakeholders may also need some training, e.g. in interpreting information output from the system.

Training must be continuous throughout the life of the system:

·  To remind people of what they have learned.

·  To train new users.

When the system is changed in the Maintenance Stage, training material must also be updated.

Site preparation

Before the new system can be installed, the place where it is to be located must be prepared.

Even for a small system, this can involve a large number of factors and requires a Site Preparation Plan.

May include: cabling, rearranging or acquiring furniture, additional power circuits

Data preparation

At least some of the data within the existing system will need to be input into the new system so that the transition can proceed smoothly.

This frequently involves converting the data from one format to another.

·  Manual data must be input to the computer.

·  Computerised data in one format may need to be converted to a different computer format.

Installation

Installation involves actually placing the computer hardware on site and making it operational.

It must be tested extensively to ensure that it works in this situation. The need for this is often overlooked. It is called Site Testing.

Once the new system software is installed, it must also go through thorough site testing. This involves looking at everything that could happen and trying to see that it doesn't. However, it also involves planning recovery strategies, just in case.

Conversion

This is the step where the old system is phased out and the new system begins to be used after which the new system will be fully operational.

There are four methods for converting from the old to the new system.

·  Direct conversion - use of the old system stops on a certain date and use of the new system begins.

·  Parallel start up - both the old and the new system are run in parallel until the users are satisfied that the new system is working correctly.

·  Phased-in approach - components of the new system are slowly phased in while components of the old are phased out.

·  Pilot approach - the new system is run for one group of users initially, usually on one site.

Acceptance

The SDLC includes a number of types of testing:

·  Testing programs as written.

·  Testing the whole system when it is complete.

·  Site testing the hardware and the new system.

User Acceptance Testing is the last set of tests to be carried out.

This is the responsibility of the users.

·  However, most users and non-professional stakeholders require professional assistance in planning this testing.

This testing evaluates whether the system actually does meet the goals that were originally set for it. Acceptance Testing is the basis for ‘Client Signoff’ when the client signs off the contract as complete.

Factors that help ensure successful systems development:

·  Clearly defined organizational goals

·  A sharp focus on, and clear understanding of, the most important business problems or opportunities (independent of systems concerns)

·  Clearly defined systems development objectives

·  Support of top-level managers

·  Involvement of users at all stages

·  Use of a proven systems development approach

·  Creating or aligning incremental system benefits with normal user work activities so as to provide incentive for effective system interaction

·  Managing change

·  A simple and straightforward design

·  Good training programs for all involved

Factors that contribute to the failure of systems development projects:

·  Solving the wrong problem

·  Poor problem definition and analysis

·  Poor communication

·  A project that is too ambitious

·  A lack of top management support

·  A lack of management and user involvement

·  Failure to use a standard systems development approach

·  Inadequate or improper system design

·  Poor testing and implementation

·  A lack of concern for maintenance

7