B107 Principles of Information Systems Topic 12

B107 Principles of Information Systems Topic 12

System Development Life Cycle

O/H 1

Objectives of this lecture:

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

·  To understand some of the ways that a system development project is initiated.

·  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, which is a more iterative approach with considerable user involvement.

·  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:

·  Beekman et al, Chapter 15 (not in the unit reader).

·  Stair & Reynolds, Chapters 12 and 13 (note that Chapter 13 is printed first in the Reader).

·  At end of lecture notes:

·  ‘Factors that help ensure successful systems development’

·  ‘Factors that contribute to the failure of systems development projects’

O/H 2/3

Introduction

·  This topic looks at the whole process of developing an IS from the time that it is first proposed to the point where it is installed and running.

·  The topic falls into four logical parts:

·  A general look at the System Development Life Cycle.

·  The Systems Investigation and Systems Analysis phases.

·  The Systems Design phase.

·  The Systems Implementation and Review and Maintenance phases.

Overview of the software development process

The System Development Life Cycle (SDLC)

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

·  The model is generally known as the Systems Development Life Cycle (SDLC).

·  See SDLC in Stair, Chapter 12, Figure 12.6, Page 469 in reading for this topic.

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

·  However, the SDLC usually has 5 - 9 phases.

·  These accord with Stair’s 5 phases but divide some phases into smaller sub-phases.

·  E.g. see Beekman, Page 427 - Stair’s Implementation and Maintenance phases are divided into two phases each making 7 phases.

·  Each phase usually concludes with checks to evaluate the successful conclusion of the phase.

·  Each phase has a set of 'deliverables' - reports etc to be delivered to the client or the project leader.

·  These are the concrete output of the phase.

·  They frequently become input to the next phase.

·  In the past the phases of the SDLC have been followed strictly and each phase, once completed is never revisited.

·  Topic 11 pointed out the real need to iterate between the phases.

·  This is indicated by arrows in Stair’s SDLC.

O/H 4/5

The SDLC and the problem solving model

·  Developing an IS is a specific form of problem.

·  Therefore, regardless of the phases used in the SDLC, the steps are similar to those of the problem solving model and the order in which they are carried out is also similar.

THE PROBLEM SOLVING MODEL

THE SYSTEMS DEVELOPMENT LIFE CYCLE

O/H 4/5 continued

·  Phase 1 in Stair's model is Systems Investigation

·  Here data is gathered to understand the problem.

·  As in Stage 1 of the problem solving model.

·  Phase 2 is Systems Analysis.

·  Existing systems are examined in detail, solution requirements are specified and alternative solutions are investigated for feasibility.

·  The phase ends with a recommendation for a solution to the problem.

·  Also Stage 2 of the problem solving model.

·  Phase 3 is Systems Design.

·  The recommended solution is planned in detail.

·  This stage doesn’t exist in the problem solving model, which assumes that the recommended solution can be implemented without further design.

·  Stair calls Phase 4 Systems Implementation. Other authors call it System Development.

·  This is the equivalent of Step 6 in the problem solving model.

·  It is the largest step in the SDLC, involving:

·  Buying, or writing the software.

·  Testing custom written software.

·  Acquiring any hardware that is needed.

·  Training the users.

·  Installing the hardware and software.

·  Phase 5 is Systems Maintenance and Review.

·  This is the equivalent of Step 7 in the problem solving model.

·  Here the solution is monitored and evaluated to see that it meets its original goals.

·  And this continues throughout the life of the system.

·  System maintenance may include changing the system in order to fix bugs, add new, value adding, features or amend functions to meet changing needs.

·  Even when decommissioned, the system is usually rewritten into a new system meeting the same needs.

O/H 6

Initiating a software development project

·  A software development project begins because somebody perceives that there is potential benefit from a new system.

·  Projects may be initiated for a number of reasons:

·  Problems with an existing system.

·  The desire to exploit new opportunities.

·  The need to deal with pressures, such as increasing competition or the fact that the organisation is growing or being taken over.

·  Changing user expectations about ISs.

·  Ideally, the new project will be part of the organisation's Strategic Plan (see Topic 9).

·  The Strategic Plan should map out directions for each of the functional areas of the organisation, such as directions to the IT area for IS projects.

·  These should then be part of the IS Plan.

·  The plans of the I.T. area are then in line with the wider goals of the organisation.

O/H 7

Success factors in systems development

·  Broadly, a successful software development project is 'On Time’, ‘On Budget’ and ‘On Specification'.

·  These success criteria are expanded into a list of factors which identify a quality software product.

·  Our industry does not have a good record in this regard.

·  Experience has helped to identify a number of factors which contribute to the success or failure of the systems development process

·  See list of success factors at end of lecture notes.

·  We have met some of these factors before, e.g.:

·  The need for a clear and agreed problem definition (see SSM in Topic 11). This should then lead to clearly defined objectives and goals for the new system.

·  The involvement of users will help to ensure a system which meets users' needs. This should include the quality of the training that users are offered.

·  It is important to seek the support of management who approve the resources for the project.

O/H 8

Factors contributing to failure in systems development

·  See list of factors which have been identified as contributing to the failure of systems development projects at end of lecture notes.

·  These are from Stair, Table 12.5, Page 476.

·  Stair also includes countermeasures against these factors.

·  We have also met some of these factors previously.

·  Solving the wrong problem and poor problem definition was a theme in Topic 11.

·  Poor communication was discussed in Topic 3.

O/H 9

System development methodologies

·  A methodology is the ways in which we work. For any project there should be a set of rules, procedures and standards which govern the approach that is taken to the SDLC.

·  Including the way that various models that are drawn and the software tools that are used.

·  The methodology also includes the way in which the phases of the SDLC are tackled.

·  There are many different methodologies.

·  Many companies/developers have their own.

·  There are also commercial products.

·  Which methodology is adopted may be less important that that some methodology be adopted.

·  This leads to consistency across the company and between software development projects.

·  However, using a popular methodology means that new employees and outside specialists and vendors always understand the methods being used.

·  And it can also be argued that popular methodologies have stood the test of time.

O/H 10

Systems Investigation and Analysis

Introduction

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

·  In the Systems Analysis phase existing systems are examined in detail and the requirements for the new system are specified. Alternative solutions to the problem can then be considered and a solution to the problem be recommended.

·  At the end of these two phases the organisation decides whether to undertake a particular project.

·  This is also the point at which the organisation decides whether the resources that will be needed are cost effective.

·  At this point there must be a set of goals and objectives for the system by which the completed system can be evaluated.

O/H 11

Systems investigation (SI)

·  The overall purpose of this phase is to clearly identify the problem or opportunity.

·  The deliverable of this phase is the SI Report which summarises the results of the SI in terms of a clear statement about the problem and a set of objectives and specific goals needed to overcome the problem or take advantage of the opportunity.

·  See Stair, Page 484 and Figure 12.12 for a TOC.

·  At the end of this phase the project team will have a very clear idea of where the project is going and a decision will be made as to whether the project should be subject to further investigation.

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

·  Many of these stakeholders will also be involved in the project in later phases e.g. users in the Design phase.

O/H 12

The Feasibility Study

·  The SI Report includes the Feasibility Study (see Stair, Page 482).

·  It investigates a number of aspects of the proposed project to ensure that it is able to be implemented .

·  Economic feasibility - would the project be cost effective?

·  A Cost/Benefit study calculates and compares the economic costs and benefits (see Stair, Page 527).

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

·  And can staff with the required knowledge be acquired?

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

·  What would be the impact of the solution on the business?

·  Would the solution be accepted by the users?

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

O/H 13

Systems Analysis (SA)

·  Phase Two of the SDLC is Systems Analysis.

·  It involves a number of tasks.

·  The first step is to analyse the system which most usually already exists to deal with the problem or take advantage of the opportunity.

·  However, occasionally there is no existing system of any kind.

·  This existing system is often a manual system and the opportunity exists to computerise it.

·  Investigating the existing system will involve 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.

·  Also for data collecting methods see Stair, Page 485 and Beekman, Page 433.

·  For sources of such data, see Stair, Figure 12.13.

·  Once all the data has been gathered, the existing system is described using narrative and models.

·  Models used are the same in the SA and Design phases. See section of topic on Design phase for details.

O/H 14

Deliverables from the Systems Analysis phase

·  As a result of this modelling, a full and documented picture of the existing system is available as a deliverable of the SA phase of the SDLC.

·  This picture will further clarify the requirements for the new system, which are also part of the deliverables of this phase.

·  A solution to a problem can be implemented in a number of ways. In systems development, two major implementations are a manual solution and a computerised one. However, a system can be computerised in a number of different ways.

·  A third deliverable of the SA phase is a set of narrative descriptions of the alternative implementations.

·  Each alternative is evaluated on the same criteria, frequently by scoring the alternatives on weighted criteria.

·  Stair calls this Point Evaluation - see Pages 517 - 518 of Chapter 13.

·  As a result of this evaluation, one of the alternatives will be chosen as the recommended solution.

O/H 15/16

System Design

Overview of the Design phase of the SDLC

·  At the end of the SA phase, a Proposal is put to the client. Using this the client decides whether to proceed with the proposed solution.

·  If so, a contract is signed between the project team and the client.

·  At this point the System Design phase of the SDLC begins.

·  The broad purpose of this phase is to develop the best possible system to overcome the shortcomings of the existing system and help the organisation meet its goals.

·  During this phase, the analyst plans the new system.

·  Design is both a technical and a creative process.

·  It uses technical methods and tools, particularly modelling tools.

·  It draws on the technical knowledge and experience of the designer.

·  Each project will have a different mix of technical aspects and creativity.

·  Easier and more routine projects will draw heavily on technical knowledge and experience.

·  Projects with new and poorly understood problems draw more heavily on creativity.

·  Systems Design involves all 5 components of an IS (see Topic 5).

·  We will look at two methodologies which can be used in the Design phase:

·  Using the traditional SDLC.

·  Using prototyping.