The document discusses software development life cycles (SDLC). It describes the typical stages of an SDLC including feasibility study, requirements analysis, system design, development, testing, implementation, and maintenance. Several SDLC models are mentioned, including waterfall, spiral, iterative, prototyping, and RAD (rapid application development). The waterfall model is described as having distinct sequential stages with no overlap between phases. Prototyping and RAD methodologies are also explained in further detail.

1. Lecture tw0
Nana Kwabena Sarpong
(J-Prompt Professional Institute of Technology)
naksarpong@gmail.com

2. 

A software development life cycle is a set of
stages which indicates how we could develop
software. It usually shows either a descriptive
or prescriptive characterization of how
software is or should be developed.
Also called SDLC

3. 
SDLC is a process followed for a software
project, within a software organization. It
consists of a detailed plan describing how to
develop, maintain, replace and alter or
enhance specific software.

4. 
A typical Software Development life cycle
consists of the following stages:







Stage 1: Feasibility Study
Stage 2: Requirements Analysis
Stage 3: System Design
Stage 4: Development
Stage 5: Testing
Stage 6: Implementation
Stage 7: Maintenance

5. 


Ensure delivery of high quality systems
Provide strong management controls
Maximize productivity

6. 
There are various software development life
cycle models defined and designed which are
followed during software development process.
The are also called Software process Models






Water Fall Model *
Spiral Model
V Model
Iterative Model
Prototyping *
RAD(Rapid Application Development) *

7. 
The Waterfall Model was first Process Model
to be introduced. It is also referred to as a
linear-sequential life cycle model or classic
software life cycle or sequential model or
traditional waterfall process model .It is
very simple to understand and use. In a
waterfall model, each phase must be
completed before the next phase can beg in
and there is no overlapping in the phases

9. 
A feasibility study establishes whether or not
the project is to proceed. It may be that the
system is unnecessary, too expensive or too
risky. One approach to a feasibility study is to
perform cost-benefit analysis

10. 
All possible requirements of the system to be
developed are captured in this phase and
documented in a requirement specification
doc. the developer finds out what the user
(client or customer) wants the software to do
and records the requirements as clearly as
possible. The product of this stage is a
requirements specification.

11. 
The requirement specifications from first
phase are studied in this phase and system
design is prepared.

12. 
The detailed designs are converted into
instructions written in the programming
language. If system is large it is developed
into small programs or modules called units .
There may be a choice of programming
languages, from which one must be selected.
The product is the code

13. 
All units of the system coded are tested
separately for errors and failures (unit
testing). The overall system is also
tested(system testing).

14. 
Once all testing is done, the product is
deployed in the customer environment or
released into the market. At this phase the
system is put to use.

15. When the software is in use, sooner or later it
will almost certainly need fixing or enhancing.
Making these changes constitutes
maintenance. Software maintenance often
goes on for years after the software is first
constructed. The product of this activity is
the modified software


16. Organized approach with specific stages
Reflects common engineering practices
It is documentation driven, that is,
documentation is produced at every
stage
 Simple and easy to understand and use
 Clearly defined stages.
 Provides structure to inexperienced staff




17. 



Doesn’t cope well with changes required by
the client
Development teams might wait for each
other
The customer only sees a working version of
the product after it has been coded. This may
result in disaster if any undetected problems
are precipitated to this stage.
All requirements must be known upfront

18. 
Prototyping is the practice of building an
early version of a system which does not
necessarily reflect all the features of the final
system, but rather those which are of
interest.

19. In prototyping, the customer is presented at a
very early stage with a working version of the
system. (It may not be a complete system, but
it is at least part of the system and it works.) They
can check that it does what they want,
or specify modifications. The developer amends
the system and demonstrates it again
and again until it does what the customer wants.
Thus the main purpose of prototyping
is ensuring that the user’s needs are satisfied


20. 

Throwaway Prototyping
Evolutionary Prototyping

21. 

In throwaway prototyping the various
versions of the system are constructed and
then thrown away. (The final system is
implemented in some different way.)
A throwaway prototype implements only
those requirements that are poorly
understood. It is discarded after the desired
information is learned

22. 
Throwaway prototyping is sometimes called
rapid prototyping and as the name suggests,
a rapid prototype should cost very little and
take very little time to develop.

23. This type of prototyping is based on the idea
of developing an initial implementation,
exposing it to user comment and refining it
through repeated stages until an adequate
system has been developed


24. 
Evolutionary Prototyping has a very big
advantage over Throwaway Prototyping. The
advantage is in the fact that evolutionary
prototypes are functional systems. Although
they may not have all the features the users
have planned, they may be used on an
interim basis until the final system is
delivered.

25. ▪ Prototypes may be easily changed or even discarded.
▪ Prototyping may improve communication between and among developers
and customers
▪ Users may be more satisfied with systems developed using prototyping.
▪ A prototype may provide the proof of concept necessary to attract funding.
▪ A prototype may serve as a marketing tool.
▪ A prototype may serve as the basis for operational specifications.
▪ Early visibility of the prototype may help management assess progress.
▪ Exploratory prototyping allows productive work to proceed despite initial
uncertainties.
▪ Prototypes may demonstrate progress at an early stage of development.
▪ Prototypes may provide early training for future users of the system.
▪ Prototyping may prevent unpleasant surprises by calling attention to
incomplete or inconsistent requirements, or to missing functionality.

26. ▪ Prototyping may encourage an excess of change requests.
▪ Working prototypes may lead management and customers to believe
that the final product is almost ready for delivery.
▪ The excellent (or disappointing) performance characteristics of
prototypes may mislead the customer.
▪ Customers may not be prepared to provide the level or frequency of
feedback required for iterative prototyping.
▪ Customers may not be willing to participate in the iteration cycle
over the long haul
▪ Developers may have difficulty writing the back-end code needed to
support the slick front-end interface designed with the prototyping
tool.
▪ Due to time and market constraints, system specifications may be
frozen before the prototyping process has reached a definitive stage.
▪ During prototyping, the only "design specification" is the prototype
itself, which may allow uncontrolled change.
▪ Early prototypes may be of low fidelity, dismissed as toys.

27. 
RAD is a linear sequential software
development process model that emphasis
an extremely short development cycle using a
component based construction approach

Rapid Application Development as “an
approach to building computer systems
which combines Computer-Assisted Software
Engineering (CASE) tools and techniques

28. 




Business Modeling:
Data Modeling
Process Modeling
Application Generation
Testing and Turn over

29.  In this phase, define the flow of information

within the organization, so that it covers all the
functions. Questions like what information
drives the business process, what information
is generated, who generates it, where does
the information go, who process it and so on.
This helps in clearly understand the nature,
type ,source and process of information

30.  In this phase, convert the component of the
information flow into a set of data objects.
Each object is referred as an Entity that are
needed to support the business. The
attributes (character of each entity) are
identified and the relation between these
data objects (entities) is defined.

31. 
The data object defined in the data modeling
phase are transformed to achieve the
information flow necessary to implement a
business function. In addition adding
, deleting, modifying and retrieving the data
objects are included in process modeling.

32. 
In this phase, the generation of the application
and coding take place. Using fourth generation
programming languages or 4 GL tools is the
preferred choice for the software developers

33. 

Many of the programming components have
already been tested since RAD emphasis
reuse. This reduces overall testing time. But
new components must be tested and all
interfaces must be fully exercised
Resembles the final tasks in the SDLC
implementation phase, including data
conversion, testing, changeover to the new
system, and user training.

34. 
Due to emphasis on rapid development , it results
in the delivery of fully functional project in short
time period.

It encourages the development of program
component reusable.

Can obtain support from automated tools and
techniques.

35. 



It requires dedication and commitment on the part
of the developers as well as the client to meet
the deadline. If either party is indifferent in needs
of other, the project will run into serious problem.
Its application area is restricted to system that are
modular and reusable in nature.
It is not suitable for the applications that have a
high degree of technical risk.
It is not suitable for the large projects because
they require more manpower for creating
multiple RAD groups.