Systems Development

1
Systems Development
2
Learning Objectives

• To understand the stages in the traditional
  systems development life cycle
• To understand the problems associated with this
  traditional approach

3
Systems Development Life Cycle

• No common definition of the number of elements in
  the traditional systems development life cycle
  (SDLC)
• However all the definitions of the SDLC will
  include these elements

4
SDLC Elements

• Project Identification
• Feasibility Study
• Requirements Analysis
• Systems Analysis
• System Specification
• System Design
• Programming
• Testing
• System Implementation
• System Maintenance
• Post Installation Review

5
Project Identification

• Most new information system projects are brought
  about by the need for change.
• The need for change usually arises for one of two
  reasons
• Bad information systems design
• The existing information systems are not
  providing the information that users require
  leading to frustrated users, or the existing
  systems require a lot of maintenance to keep them
  running
• Environmental change
• Organisations have to change their systems to
  respond to changes in the environment
• E.g. the new millennium and the Euro

6
Feasibility Study

• Frequently there may be many projects identified
  as requiring new information systems
• The feasibility study seeks to evaluate all
  proposals in terms of
• Benefits
• Costs
• Technical feasibility
• Areas of the organisation affected by proposal
• Time scale for implementation
• Proposals relationship with existing systems
• Assessment of fulfilment of user needs

7
Requirements Analysis

• Start of the logical design phase which ends with
  the system specification
• Involves information gathering from users to find
  out their needs
• End user ownership of system is very important if
  new system is to be successful
• Nearly always achieved by looking at the existing
  system(s) and seeing the good and bad points of
  that
• Talking about the existing system(s) is a good
  way for analysts to get information from users
• Can be done with interviews.

8
Systems Analysis

• After the existing system has been investigated,
  it will be necessary to analyse it carefully to
  determine those parts that are suitable for
  computerisation, and to determine how new
  capabilities may be incorporated into the system
• Systems analysis is concerned with what is to be
  implemented, not the how
• Output is the system specification, so that the
  programmers know what to code

9
Systems Analysis Logical Model

• Techniques exist to develop a consistent logical
  model of the required future system
• This model will often contain
• Content of the data stored on files
• Content of the transactions which will update
  that data
• Contents of the output that will be produced from
  the data
• The logic of the processing carried out on the
  data

10
Systems Analysis Techniques

• Systems analysis techniques include
• Data Flow Diagrams
• Flow charts
• Decision trees
• Decision tables
• Data Dictionaries
• Entity-Relationship diagrams
• Relational Data Analysis (Normalisation)

11
System Specification

• This is the output of the systems analysis stage
• Specification to the programmers so that they can
  create the code to meet the needs
• Bit like the architects plans in building
• Often the systems analysts will help oversee the
  programming

12
Elements in a Systems Specification

• A good systems specification often includes
• General objectives of the system
• System interfaces to other systems, system inputs
  and outputs
• Hardware and operating system
• The logical model
• The test environment
• The documentation plan
• Security
• Performance

13
System Design

• This is the start of the physical design phase
• Concerned with HOW the system is to be
  implemented
• Describes how the system is to be implemented
  using the hardware and operating system
  recommended in the systems specification
• Also includes design of the user interfaces

14
Design Considerations

• Ease of construction
• Speed of construction
• Ease of maintenance
• Portability
• Resilience and Operational Reliability
• Ease of operation
• Response Time
• Security

15
Programming

• The procedures specified in the system
  description are converted into computer programs
  and tested using test data
• User Interface is also developed and tested by
  users
• Problems are either
• Technical, or
• Project Management
• Problems in programming tend to stem from poor
  systems design
• Problems in programming are one reason that there
  have been large sales of packaged software

16
Testing

• The aim of testing is to find faults in the code
  being written
• Debugging is concerned with pinpointing exactly
  where the fault occurs and then fixing the
  offending program statements
• Debugging is usually done by the programmers, but
  quite often testing is done by separate people
• Use test data to test how the program handles
  strange input and incorrect input
• Testing is never complete and errors will occur
  long after implementation

17
System Implementation

• Implementation marks the transfer of the system
  from specialist developers to the users
• It usually involves
• Training
• Procurement of systems and supplies
• File conversion
• Change over from old system
• Very important to get this stage right and often
  involves a lot of planning
• If the users dont like the new system then a lot
  of the hoped for benefits will be lost
• This is where change management skills are
  important

18
System Maintenance

• A good system should have low maintenance
• However there will nearly always be ongoing
  maintenance costs which must be budgeted for.
  These can include
• Annual software maintenance if software used
• Operating system software support
• Hardware maintenance support
• It would be foolhardy to not have support
  contracts if the systems are important to the day
  to day operations

19
Post Installation Review

• To maintain user confidence in the new system it
  is vital to deal with any problems that arise
  soon after implementation.
• However it is also useful to reflect on how well
  the system has lived up to its expectations.
• This can be useful for future implementations if
  troublesome areas are identified.
• Also useful to reflect on the cost benefit
  assumptions of the feasibility study.

20
Limitations of the SDLC Approach

• Useful in large systems where requirements are
  highly structured and well defined
• Also where there is a need for rigorous and
  formal requirements analysis, predefined
  specifications and tight controls over the
  systems-building process
• However
• costly
• time consuming
• inflexible

21
Alternatives to the SDLC Approach

• Prototyping
• Application Software Packages
• End-user development
• Outsourcing