system development life cycle

Chapter 2:

Systems Development Life Cycle

Traditional Systems Development Life Cycle (SDLC)

• These early systems were implemented primarily by computer programmers who neither were not necessarily good communicators nor understood the user’s requirements. Their main expertise lay in the technological aspects of the systems. Standard practices and techniques were not in general use leading to an ad hoc approach to each project.


• Problems associated with these developments were: • Difficulties in the communication of user needs to system developers

• Developments were frequently delivered late, over cost and did not meet the users needs


• Projects were viewed as short term solutions rather than long-term, well-planned implementation strategies for new applications.

• Changing the system was problematic and generally introduced new problems into the system. Therefore it appeared to take an inordinately long time to make relatively trivial changes.

2.2 Software Development Life Cycle

• It is the series of steps used to manage the phases of development for an information system. Phases are not necessarily sequential. Usually each phase/step has a specific outcome and deliverable.

Software Development Life Cycle

– There are six phases under this model. • Requirements Definition • Feasibility Study • System Analysis • System Design • Implementation • Review & Maintenance

Business Problem Definition

• 1. Business Problem Definition. (Sometimes known as Requirements Definition) is the job of identifying and describing what is required of the new information system i.e. it provides the terms of reference for the development process. Techniques used in this stage include interviews and questionnaires.

Business Problem DefinitionSpecify Terms of Reference - giving a brief outline of: -What areas the system is to cover -What will be included -What will NOT be included Propose a Feasibility Study, indicating: -How long it will it take to produce -Who will produce it -A deadline (i.e.: the date by which it is expected)

Feasibility Study

• 2. Feasibility Study is an investigation of alternative solutions to the business problem with a recommended solution chosen out of the alternatives. The technique of cost benefit analysis is used in this stage.

Feasibility Study

– The purpose is to decide whether the proposed system is feasible usually in terms of economics (since most things are now technically feasible). To give estimates of:

• Development costs • Development timescale • Running costs

Feasibility Study

– The methods used during phase are Observation; Interviews and Professional judgment. The deliverables at this stage are:

• Feasibility Report to sponsor • Project Plan • Costs and Benefits • The go-ahead or otherwise.

Systems Analysis

3. Systems Analysis is the detailed investigation and analysis of the requirements of a system to fulfill a given business problem. The techniques used in this stage include:

• Dataflow diagrams • Entity modeling

Systems Analysis

• The deliverables at this stage are: • Requirements Report • Revised Project Plan • Revised Costs and Benefits

Systems Design4. Systems Design is the process of constructing a design for a system to

fulfill a given business requirement. The techniques used in this stage include:

• Dataflow diagrams • Entity modeling

Systems Design

• The deliverables are: – System/software Specification – Database Definition – Training Manuals – Hardware Specifications (if relevant) – Revised Project Plan – Revised Costs and Benefits

Testing.Testing. There are 6 types of testing that are performed. a) Unit testing - testing of individual modules b) Link testing - testing of communications between modules c) System testing - testing of the system as a whole d) Volume testing - testing that the system can cope with the

anticipated volumes of data. e) User-acceptance testing - letting the users try the system. f) Regression testing - used during the maintenance phase to ensure

that changes do not corrupt other parts of the system.

ImplementationImplementation. Actually implementing the live system. There are four

methods of implementing a system a) Direct changeover - scrap the old system and start using the new

system immediately. b) Parallel running - running both the old system and the new system

until the new system has ‘proved itself’. c) Pilot - implementing the whole system in just a part of the

organization or part of the system in the whole organization. d) Phased implementation - implementing the system in stages. E.g. for

an integrated ledger package we might implement just the sales ledger first, then at a later date implement the purchase ledger and then later still the nominal ledger.

Post-implementation Review

• Post-implementation Review. After 6 months or 12 months the implementation and performance of the system is reviewed to determine how successful the exercise has been.

Maintenance.

• Maintenance. Enhancements, error corrections and minor changes are made to the system until we reach the point where the system becomes obsolete and then we start the whole systems lifecycle again with a new business problem definition.

Potential weakness of Traditional SDLC

– Although this approach represents a significant improvement over earlier more ad hoc approaches there are, at least potentially, some serious limitations to the SDLC. These criticisms can be summarized as follows:-

• Failure to meet the needs of management • Instability • Inflexibility • User dissatisfaction • Problems with documentation • Lack of control • Incomplete systems • Maintenance workload

Approaches to Systems Development (Alternatives to SDLC)

The traditional SDLC has been used, and is still being used, as the basis of development process models. There are a number of suggested general models (or development process paradigms). Other models which are used include:

• PROTOTYPING. • Rapid Application Development (RAD) • Joint Application Design • 4th Generation Techniques

Prototyping

Prototyping in systems development is the process of creating a 'cut-down' version, or part, of a system so that users can:

• Get an idea of what the system will offer; and • Provide feedback on whether the system is

what is required. Prototyping helps to identify misunderstandings

between 'users' and software developers; and may detect missing (i.e.: not yet specified) user requirements.

Prototyping

A prototype is: 1. An original or model after which anything is

formed; 2. The first thing or being of its kind;

Advantages of prototyping stage • Identification of misunderstandings between 'users' and software

developers; • Detection of missing user services • Identification of difficult-to-use or confusing user services • Requirements validation aid (discovering inconsistencies) • Early availability of a working (limited) system • May serve as basis for specification for a 'production quality' system

Possible 'dangers' of prototypes

• prototype may become basis of implementation (but lacks safety-critical features)

• May be used as basis for contract with s/w engineer (s) e.g.: 'build one like this' - no legal standing.

• non-functional requirements cannot be adequately expressed • omission of functions in prototype may mean prototype not used in

same way as fully operational system • AND may encourage inadequate problem analysis Prototyping is seen sometimes as representing 'unacceptably large

proportion of system development costs

Rapid Application Development (RAD)

A new (in 1997) development strategy called Rapid Applications Development (RAD) is already being used. RAD makes use of:

• Well organized and structured group meetings which must have representatives of the Client and Users (see the triangle diagram below). The user representatives must be authorized to make decisions;

• Small teams using Computer Aided Software Engineering tools (CASE). The team usually includes user representatives (or works with ready access to users.)

• Similar to waterfall but uses a very short development cycle than, for example, the traditional lifecycle process.


– • Uses component based construction and emphasis reuse and code generation

– • Use multiple teams on scaleable projects – • Requires heavy resources – • Require developers and customers who are heavily committed – • Performance can be a problem – • Difficult to use with new technology – • Utilizes prototyping to delay producing system design until after

user requirements are clear

Joint Application Design (JAD)

• Users, Managers and Analysts work together for several days

• System requirements are reviewed • Structured meetings

Consideration in choosing a Methodology

i. Nature of the project development – whether it is a software maintenance project or an embedded product development.

ii. Size of your organization, the project and the team.

iii. Structure of your team – whether it is in house or geographically distributed.

Cont…..

iv. Alignment with your organization’s stage of business and its business strategy – whether your organization is a startup with a new product launch or an established enterprise that is releasing a new product feature

v. The industry of your business, as different industries may have very different software development needs and objectives

Cont…..

vi. Culture of your organization – whether the teams are used to the collaborative work culture or not, as adopting some SDLC methodologies demands collaborative work culture

vii. Engineering capabilities of your developers. viii. Complexity of project.

system development life cycle

Education