The document discusses different systems development life cycles (SDLC) including the traditional SDLC model and alternatives like prototyping, Rapid Application Development (RAD), and Joint Application Development (JAD). The traditional SDLC model involves phases like requirements definition, feasibility study, systems analysis, systems design, implementation, and maintenance. However, it has some limitations that newer approaches aim to address, focusing more on user involvement, flexibility, and rapid iterations.

1. Chapter 2:
Systems Development
Life Cycle

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

3. Traditional Systems Development Life Cycle
(SDLC)
• 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

4. Traditional Systems Development Life Cycle
(SDLC)
• 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.

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

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

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

8. Business Problem Definition
Specify 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)

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

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

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

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

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

14. Systems Design
4. 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

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

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

17. Implementation
Implementation. 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.

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

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

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

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

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

23. Prototyping
A prototype is:
1. An original or model after which anything is
formed;
2. The first thing or being of its kind;

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

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

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

27. Rapid Application Development (RAD)

28. Rapid Application Development (RAD)
– • 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

29. Joint Application Design (JAD)
• Users, Managers and Analysts work together for
several days
• System requirements are reviewed
• Structured meetings

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

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

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