SDLC(Software

Development Life
Cycle )

12 - 1
 Why Study SDLC?

• The software development life cycle

(SDLC) is a conceptual model used
in project management that describes
the stages involved in an information
system development project, from an
initial feasibility study through
maintenance of the completed
application. SDLC can apply to technical
and non-technical systems.

12 - 2
SDLC(Software development life cycle)

12 - 3
 Planning

• The planning phase will determine project goals

and establish a high-level plan for the intended
project. Planning is, by definition, a fundamental
and critical organizational phase. The three
primary activities involved in the planning phase
are as follows:
• Identification of the system for development
• Feasibility assessment
• Creation of project plan

12 - 4
 Feasibility Study

Definition:
• A preliminary study where the information
needs of prospective users and the
resource requirements, costs, benefits,
and feasibility of a proposed project are
determined

12 - 5
 Feasibility Categories

• Economic – whether expected cost

savings, increased revenue, increased
profits, reductions in required investment,
and other types of benefits will exceed the
costs of developing and operating a
proposed system

12 - 6
 Feasibility Categories

• Technical – determine if reliable hardware

and software capable of meeting the
needs of a proposed system can be
acquired or developed by the business in
the required time
• Is the project possible with current
technology?
• What technical risk is there?
• Availability of the technology:Is it available
locally?Can it be obtained?
12 - 7
• Behavioral Feasibility
• It evaluates and estimates the user
attitude or behavior towards the
development of new system.
• It helps in determining if the system
requires special effort to educate, retrain,
transfer, and changes in employee’s job
status on new ways of conducting
business.

12 - 8
• Operational – willingness and ability of the
management, employees, customers,
suppliers, and others to operate, use, and
support a proposed system

• Schedule-
• Time resources,
• Is it possible to build a solution in time to
be useful?
12 - 9
Feasibility

12 - 10
 Analysis

Definition:
• An in-depth study of end user information needs that produces
functional requirements that are used as the basis for the design of
a new information system
• The analysis phase answers the questions of who will use the
system,
• what the system will do, and
• where and when it will be used.
• The three primary activities involved in the analysis phase are as
follows:
• Gathering business requirement
• Creating process diagrams
• Performing a detailed analysis

12 - 11
 Design

Definition:
• Design activities that produce system
specifications satisfying the functional
requirements that were developed in the
systems analysis process

12 - 12
Design Categories

12 - 13
 Implementation or coding

• In this stage of SDLC the actual development starts and

the product is built.If the design is performed in a
detailed and organized manner, code generation can be
accomplished without much hassle.
• Developers must follow the coding guidelines defined by
their organization and programming tools like compilers,
interpreters, debuggers, etc. are used to generate the
code.
• Different high level programming languages such as C,
C++, Pascal, Java and PHP are used for coding. The
programming language is chosen with respect to the
type of software being developed.

12 - 14
 Testing

• Testing and debugging software

• Testing website performance

• Testing new hardware

• Review of prototypes of displays, reports

and other output

12 - 15
 Maintenance

Definition:
• Monitoring,
• evaluating, and
• modifying of operational business systems
to make desirable or necessary
improvements

• You tube video: https://youtu.be/i-

QyW8D3ei0
12 - 16
 SDLC - Waterfall Model

• The Waterfall Model was the first Process Model to be introduced.

It is also referred to as a linear-sequential life cycle model. It is
very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and
there is no overlapping in the phases.
• The Waterfall model is the earliest SDLC approach that was used
for software development.
• The waterfall Model illustrates the software development process in
a linear sequential flow. This means that any phase in the
development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

12 - 17
12 - 18
 PHASES IN WATERFALL MODEL
• The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible requirements of the system to
be developed are captured in this phase and documented in a requirement
specification document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system
is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done;
the product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To
fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
12 - 19
 Waterfall Model - Application

• Waterfall Model - Application

• Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use
of Waterfall model is most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.

12 - 20
 ADVANTAGES

• This model is simple and easy to understand

and use.
• It is easy to manage due to the rigidity of the
model – each phase has specific deliverables
and a review process.
• In this model phases are processed and
completed one at a time. Phases do not
overlap.
• Waterfall model works well for smaller projects
where requirements are clearly defined and very
well understood.
12 - 21
 DISADVANTAGES
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high
risk of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.

12 - 22
PROTOTYPE MODEL

12 - 23
• In this model, a prototype of the end
product is first developed, tested and
refined as per customer feedback
repeatedly till a final acceptable prototype
is achieved which forms the basis for
developing the final product.

12 - 24
 APPROACHES OF PROTOTYPING

• There are 2 approaches for this model:

• Rapid Throwaway Prototyping –
This technique offers a useful method of exploring ideas and
getting customer feedback for each of them. In this method, a
developed prototype need not necessarily be a part of the
ultimately accepted prototype. Customer feedback helps in
preventing unnecessary design faults and hence, the final
prototype developed is of a better quality.
• Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally
refined on the basis of customer feedback till it finally gets
accepted. In comparison to Rapid Throwaway Prototyping, it offers
a better approach which saves time as well as effort. This is
because developing a prototype from scratch for every iteration of
the process can sometimes be very frustrating for the developers.

12 - 25
 ADVANTAGES

• Advantages –
• The customers get to see the partial product early in the life cycle.
This ensures a greater level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope
for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort
and cost, besides enhancing the quality of the software.
• The developed prototype can be reused by the developer for more
complicated projects in the future.
• Flexibility in design.

12 - 26
 DISADVANTAGES

• Disadvantages –
• Costly w.r.t time as well as money.
• There may be too much variation in requirements each time the prototype is
evaluated by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for the developers to accommodate all the changes
demanded by the customer.
• There is uncertainty in determining the number of iterations that would be
required before the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the
actual product to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal
solutions.
• The customer might lose interest in the product if he/she is not satisfied with
the initial prototype.

12 - 27
 SDLC - RAD Model

• The RAD (Rapid Application Development) model is based on

prototyping and iterative development with no specific planning involved.
The process of writing the software itself involves the planning required for
developing the product.
• Rapid Application Development focuses on gathering customer
requirements through workshops or focus groups,
• early testing of the prototypes by the customer using iterative concept,
reuse of the existing prototypes (components),
• continuous integration and rapid delivery.
• SECTORS THAT BENEFITED MOST FROM RAPID APPLICATION DEVELOPMENT
SOFTWARE- Banking, Financial Services, and Insurance (BFSI), Automobile
Industry, Online Retail Industry

12 - 28
RAD Model Design

12 - 29
• Business Modelling
• The business model for the product under development is designed in terms of flow of information and the
distribution of information between various business channels. A complete business analysis is performed to find
the vital information for business, how it can be obtained, how and when is the information processed and what
are the factors driving successful flow of information.

• Data Modelling
• The information gathered in the Business Modelling phase is reviewed and analyzed to form sets of data objects
vital for the business. The attributes of all data sets is identified and defined. The relation between these data
objects are established and defined in detail in relevance to the business model.

• Process Modelling
• The data object sets defined in the Data Modelling phase are converted to establish the business information
flow needed to achieve specific business objectives as per the business model. The process model for any
changes or enhancements to the data object sets is defined in this phase. Process descriptions for adding,
deleting, retrieving or modifying a data object are given.

• Application Generation
• The actual system is built and coding is done by using automation tools to convert process and data models into
actual prototypes.

• Testing and Turnover

• The overall testing time is reduced in the RAD model as the prototypes are independently tested during every
iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested
with complete test coverage. Since most of the programming components have already been tested, it reduces
the risk of any major issues.

12 - 30
 RAD Model - Application

•RAD model can be applied successfully to the projects in which clear

modularization is possible. If the project cannot be broken into modules, RAD
may fail.
•The following pointers describe the typical scenarios where RAD can be used
−
•RAD should be used only when a system can be modularized to be delivered
in an incremental manner.
•It should be used if there is a high availability of designers for modeling.
•It should be used only if the budget permits use of automated code generating
tools.
•RAD SDLC model should be chosen only if domain experts are available with
relevant business knowledge.
•Should be used where the requirements change during the project and
working prototypes are to be presented to customer in small iterations of 2-3
months.

12 - 31
 RAD-ADVANTAGES

• Changing requirements can be accommodated.

• Progress can be measured.
• Iteration time can be short with use of powerful RAD tools.
• Productivity with fewer people in a short time.
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues

12 - 32
 RAD-DISADVANTAGES

• Risk of insufficient requirement analysis owing to too much

dependency on the prototype.
• Users may get confused in the prototypes and actual systems.
• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Developers may try to reuse the existing prototypes to build the
actual system, even when it is not technically feasible.
• The effort invested in building prototypes may be too much if it is
not monitored properly.

12 - 33
 JAD

• JAD (Joint Application Development) is a software development

approach which engages the client and/or the end users for
designing and developing the system.
• JAD (Joint Application Development) is a methodology that
involves the client or end user in the design and development of an
application, through a succession of collaborative workshops called
JAD sessions. Chuck Morris and Tony Crawford, both of IBM,
developed JAD in the late 1970s and began teaching the approach
through workshops in 1980.
• As compared to other primitive SDLC model, Joint Application
Development model leads to faster progression of the system
development which has better client approval.

12 - 34
Phases of JAD

12 - 35
 PHASES IN JAD
• Define Specific Objectives: The facilitator, in partnership with stakeholders, set all
the objectives as well as a list of items which is then distributed to other developers
and participants to understand and review. This objective contains elements like the
scope of this projected system, its potential outcome, technical specification
required, etc.
• Session Preparation: The facilitator is solely responsible for this preparation where
all relevant data is collected and sent to other members before time. For better
insight, research carried out to know about the system requirement better and gather
all the necessary information for development.
• Session Conduct: Here the facilitator is accountable to identify those issues which
have to be working out for making the system error-free. Here the facilitator will
serve as a participant but will not have a say regarding any information.
• Documentation: After the product is developed, the records and published
documents are put forward into the meeting so that the stakeholders and consumers
can approve it through the meeting.

12 - 36
 BENEFITS

1.Produce a design from the customer’s

perspective.
2.The teamwork between company and
client helps to remove all risks.
3.JAD helps to accelerate design and also to
enhance quality.
4.JAD cheers the team to push each other
which leads them to work faster and also
to deliver on time.

12 - 37
 Disadvantages

1.Sometimes opinions within the team

members may differ which make
difficult to align goals and maintain
focus.
2.Depending on the size of the project, JAD
may require a significant time
commitment.

12 - 38
 Agile Methodology

• The Agile methodology is a way to manage a project by breaking it

up into several phases.
• It involves constant collaboration with stakeholders and continuous
improvement at every stage.
• Once the work begins, teams cycle through a process of planning,
executing, and evaluating.
• Continuous collaboration is vital, both with team members and
project stakeholders. It’s a process for managing a project that
involves constant collaboration and working in iterations.
• Today, the word Agile can refer to these values and the
frameworks for implementing them, including Scrum, Kanban,
Extreme Programming (XP), and Adaptive Project Framework
(APF).

12 - 39
• The Agile methodology is a practice that encourages continuous
development and testing throughout the software development
lifecycle of a project.
• Unlike the Waterfall methodology, the Agile methodology allows for
parallel development and testing.
• Agile methodologies attempt to produce the proper product through
small cross-functional self-organizing teams that produce small
pieces of functionality on a regular basis, allowing for frequent
customer input and course correction as needed. In doing so, Agile
tries to address the issues that traditional "waterfall" methodologies
of delivering huge products over extended periods of time
encounter, such as client requirements changing frequently and
resulting in the delivery of incorrect products.

12 - 40
12 - 41
 Scrum Software Development
Methodology

• Scrum is a framework for projects. It falls under the agile

methodology and defines roles, procedures, tools, processes
to make sure to deliver an efficient and effective project well on
time through iterative development cycles.
• This methodology is basically followed where there is the
demand of high development process, high involvement of
stakeholders. Scrum methodology repeatedly monitors
software development while the project is being developed.
• Scrum Software Development Methodology has a major focus
on the responsibility, teamwork, and iterative progress towards
a well-defined business goal.

12 - 42
SCRUMPROCESS

12 - 43
 SCRUM MASTER
• Scrum Master ensures everyone follows the practices prescribed by
Scrum.
• A Scrum Master is a facilitator and Servant Leader who encourages and
demands self-organization from the development team.
• A Scrum Master enables close cooperation across all roles and functions,
addresses resource issue and disobedience of scrum practices.
• A Scrum Master protects the team from external and internal distractions.
• A Scrum Master removes impediments so the team can focus on the work
at hand and follow scrum practices.
• A Scrum Master is not typically a manager or lead, but he is an influential
leader and coach who does not do direct command and control.

12 - 44
 PRODUCT OWNER

• A Product Owner owns the Product backlog and writes user stories
and acceptance criteria.
• A Product Owner is responsible for prioritizing the Product Backlog
is prioritized and decides the release date and the content.
• A Product Owner accepts or rejects product backlog item.
• A Product Owner has the power to cancel the Sprint, if he thinks
the Sprint goal is redundant.
• A Product Owner is the one who is responsible for the Return on
Investment (ROI) of the product.

12 - 45
 DEVELOPMENT TEAM

• The Development Team builds the product that the Product Owner
indicates: the application or website, for example. The Team in
Scrum is “cross-functional”
• The Development Team includes all the expertise necessary to
deliver the potentially shippable product each Sprint
• The Development Team is self-organizing, with a very high degree
of autonomy and accountability.
• The Development Team decides how many items to build in a
Sprint, and how best to accomplish that goal.
• The Development Team is a cross functional, small and self-
organizing team which owns the collective responsibility of
developing, testing and releasing the Product increment.

12 - 46
 Scrum Events (Ceremonies)

•The Sprint
•A sprint is a time-boxed period during which specific work is completed and made ready for review. Sprints
are usually 2-4 weeks long but can be as short as one week.
•The Daily Stand-up
•The Daily Stand-up is a short communication meeting (no more than 15 minutes) in which each team
member quickly and transparently covers progress since the last stand-up, planned work before the next
meeting, and any impediments that may be blocking his or her progress.
•The Sprint Review
•The Sprint Review is the "show-and-tell" or demonstration event for the team to present the work
completed during the sprint. The Product Owner checks the work against pre-defined acceptance criteria
and either accepts or rejects the work. The stakeholders or clients give feedback to ensure that the
delivered increment met the business need.
•The Retrospective
•The Retrospective, or Retro, is the final team meeting in the Sprint to determine what went well, what didn't
go well, and how the team can improve in the next Sprint. Attended by the team and the ScrumMaster, the
Retrospective is an important opportunity for the team to focus on its overall performance and identify
strategies for continuous improvement on its processes.

12 - 47
 Scrum - Artifacts

• The following artifacts are defined in

Scrum Process Framework -
• Product Backlog
• Sprint Backlog
• Burn-Down Chart
• Increment

12 - 48
 SCRUM ARTIFACTS
• Product Backlog
• The Product Backlog is an ordered list of features that are needed as part of the end
product and it is the single source of requirements for any changes to be made to the
product.
• The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases.
Sprint Backlog
• The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan
for delivering the product Increment and realizing the Sprint Goal.
• Increment
• The Increment is the sum of all the Product Backlog items completed during a Sprint
combined with the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be a working product, which means it must be in a useable condition.

• Sprint Burn-Down Chart

• At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be
summed. The Team tracks this total work remaining for every Daily Scrum to project the
likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Team can manage its progress.
12 - 49
 SCRUM ARTIFACTS(CONTINUED)

Sprint Burn-Down Chart

At any point in time in a Sprint, the total work remaining in the Sprint Backlog
can be summed. The Team tracks this total work remaining for every Daily
Scrum to project the likelihood of achieving the Sprint Goal. By tracking the
remaining work throughout the Sprint, the Team can manage its progress .

12 - 50
 SCRUM-ADVANTAGES

• Transparent system pushes developers to

comply with their assignments and deliver
it on time
• Defined deadline at every step keep
developers motivated and empowered at
every step
• Feedback at every level of the project
ensures that quality project is delivered in
the end

12 - 51
SCRUM-ADVANTAGES (CONTINUED)

• Higher productivity
• Better-quality products
• Reduced time to market
• Improved stakeholder satisfaction
• Better team dynamics
• Happier employees

12 - 52
 SCRUM-DISADVANTAGES

• Difficult to plan, structure and organize a

project with no clear mission and vision
• Frequent changes in the project lead to a
delay in the delivery time of the project
• Utilizes more resources and stakeholder’s
involvement in every small detail change
and discussion

• https://youtu.be/2Vt7Ik8Ublw (scrum you

tube video)
12 - 53
• THANK YOU....

12 - 54