Software Development Life Cycle (SDLC) : 12/27/2021 Er. Roshan Kandel 1

Software Development Life
Cycle(SDLC)
12/27/2021 Er. Roshan Kandel 1

Introduction to SDLC
• SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) is a systematic
process for building software that ensures the quality and correctness of
the software built.
• SDLC process aims to produce high-quality software that meets
customer expectations.
• The system development should be complete in the pre-defined time
frame and cost.
• SDLC consists of a detailed plan which explains how to plan, build, and
maintain specific software.
• Every phase of the SDLC life cycle has its own process and deliverables
that feed into the next phase.
Why SDLC?
• It offers a basis for project planning, scheduling, and estimating
• Provides a framework for a standard set of activities and deliverables
• It is a mechanism for project tracking and control
• Increases visibility of project planning to all involved stakeholders of
the development process
• Increased and enhance development speed
• Improved client relations
• Helps you to decrease project risk and project management plan
overhead
Roles
• To effectively implement a software, t h r e e ( 3 ) k e y m e m b e r s s h o u l d a l w
ays involve in the projects whom take up more than 95% of the activit
i e s i n S D LC .
• Th ey t a k e u p d i f f e r e n t r o l e s i n e a c h s t a g e t o c r o s s c h e c k a n d m o n i t o r
e a c h o t h e r ’s w o r k t o e n s u r e e a c h d e c i s i o n m a d e i n t h e S D LC i s v a l i d
and necessary.

Project Manager
• Define project scope and goals
• Budget control
• Resource allocation
• Business documentations
• Coordinate high-level management aspects of project
• Rollout approval

Business Analyst / System Analyst
• Interact with end-user during implementation
• Business & System Documentations
• Evaluate business requirements
• Design system architecture, businessflow and userinterfaces
• Ensure business needs are properly analyzed and correctly impleme
nted in the solution
• Facilitate relationship between business and technical roles
• Q u a l i t y As s u r a n c e a n d C o n t r o l

Programmer / Solution Developer
• Interpret business requirements and translate them into a deployabl
esolution
• Te c h n i c a l s t u d y
• R e s o l v e Pr o d u c t d e f e c t s
• Pr e p a r e f u n c t i o n a l s p e c i f i c a t i o n s
• Pe r f o r m t e s t i n g i n a c c o r d a n c e w i t h a g r e e d s t r a t e g y

Phases of SDLC
• 1. Planning
• 2. Define requirements
• 3. Design & Prototyping
• 4. Software Development
• 5. Testing
• 6. Deployment
• 7. Operation & Maintenance

Assignment 1
• Explain each phase of SDLC

Process Flow

Process Flow
Linear process flow executes each of the five activities in sequence.
An iterative process flow repeats one or more of the activities before
proceeding to the next.
An evolutionary process flow executes the activities in a circular
manner. Each circuit leads to a more complete version of the
software.
A parallel process flow executes one or more activities in parallel
with other activities ( modeling for one aspect of the software in
parallel with construction of another aspect of the software.

Software Development Life
Cycle Models

The Waterfall
Modeling
Model Construction
Analysis,
●
design ●
Code, test
Deployment

The Waterfall Model cont.
• When requirements for a problems are well understood then this model is
used in which work flow from communication to deployment is linear
• This Model also called as the Classic life cycle or linear sequential
model.
• When to use ?
• Requirements are very well known, clear and fixed
• Product definition is stable
• Technology is understood
• There are no ambiguous (unclear) requirements
• Ample (sufficient) resources with required expertise are available freely
• The project is short
The Waterfall Model cont.
• Advantages
• Simple to implement and manage
• Drawbacks
• Unable to accommodate changes at later stages, that is required in most of
the cases.
• Working version is not available during development. Which can lead the
development with major mistakes.
• Deadlock can occur due to delay in any step.
• Not suitable for large projects.

The V-Model
A variation of waterfall model
depicts the relationship of quality
assurance actions to the actions
associated with communication,
modeling and early code
construction activates.
Team first moves down the left side

of the V to refine the problem
requirements. Once code is
generated, the team moves up the
right side of the V, performing a
series of tests that validate each of
the models created as the team
moved down the left side.
12/27/2021 Er. Roshan Kandel
18
Assignment 2
• Compare Water fall model and V model

Incremental Process Model

Incremental Process Model cont.
• The incremental model combines elements of linear and parallel process flows.
• This model applies linear sequence in a iterative manner.
• Initially core working product is delivered.
• Each linear sequence produces deliverable “increments” of the software.
• For example, word-processing software developed using the incremental model
• It might deliver basic file management, editing and document production functions in the
first increment
• more sophisticated editing in the second increment;
• spelling and grammar checking in the third increment; and
• advanced page layout capability in the fourth increment.

Incremental Process Model cont.
• When to Use ?
• When the requirements of the complete system are clearly defined and
understood but staffing is unavailable for a complete implementation by the
business deadline.
• Advantages
• Generates working software quickly and early during the software life cycle.
• It is easier to test and debug during a smaller iteration.
• Customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified and handled during
iteration.
Evolutionary Process Models
• When a set of core product or system requirements is well understood but
the details of product or system extensions have yet to be defined.
• In this situation there is a need of process model which specially designed
to accommodate product that evolve with time.
• Evolutionary Process Models are specially meant for that which produce
an increasingly more complete version of the software with each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are
• Prototyping Model
• Spiral Model

Prototyping model
• Prototyping model is appropriate when
• Customers have general objectives of software but do not have detailed
requirements for functions & features.
• Developers are not sure about efficiency of an algorithm & technical
feasibilities.
• It serves as a mechanism for identifying software requirements.
• Prototype can be serve as “the first system”.
• Both stakeholders and software engineers like prototyping model
• Users get feel for the actual system
• Developers get to build something immediately

Prototyping model cont.
Deployment & Communication
Feedback
Construction
of Prototype Quick Plan
Modeling Quick
Design

• It works as follow
• Communicate with stakeholders & define objective of Software
• Identify requirements & design quick plan
• Model a quick design (focuses on visible part of software)
• Construct Prototype & deploy
• Stakeholders evaluate this prototype and provides feedback
• Iteration occurs and prototype is tuned based on feedback
• Problem Areas
• Customer demand that “a few fixes” be applied to make the prototype a working
product, due to that software quality suffers as a result
• Developer often makes implementation in order to get a prototype working quickly;
without considering other factors in mind like OS, Programming language, etc.

• Advantages
• Users are actively involved in the development
• Since in this methodology a working model of the system is provided, the users
get a better understanding of the system being developed
• Errors can be detected much earlier

Prototyping - Types
• There are different types of software prototypes used in the industry.
Following are the major software prototyping types used widely:
• 1. Throwaway/Rapid Prototyping
• 2. Evolutionary Prototyping
• 3. Incremental Prototyping
• 4. Extreme Prototyping

Throwaway/Rapid Prototyping
• In this method, the prototype is developed rapidly based on the initial
requirements and given to the client for review.
• Once the client provides feedback, final requirements are updated and
work on the final product begins.
• As the name suggests, the developed prototype is discarded, and it will
not be part of the final product.

• Throwaway prototyping is also called rapid prototyping.
• This is because the throwaway prototype is developed only to
understand the specifications and time is not wasted in using the
systematic way to develop the prototype.
• Hence, the rapid prototype is developed fast and with a little cost.

Evolutionary Prototyping
• Evolutionary prototyping also called as breadboard prototyping is based
on building actual functional prototypes with minimal functionality in the
beginning.
• In this method, a prototype is made, and the client feedback is received.
• Based on the feedback, the prototype is refined until the client considers it
the final product.
• It follows an incremental development approach and saves time
compared to the rapid throwaway prototyping method as in evolutionary
prototyping old prototype is reworked rather than developing a new
prototype from scratch. It is also known as breadboard prototyping.

Incremental Prototyping
• In this type of prototype model, final product requirements are break
into smaller parts and each part is developed as a separate prototype.
• In the end, all the parts (prototypes) are merged which becomes a final
product.

Extreme Prototyping
• This type of prototyping model is mainly used for web applications. It
is divided into three phases-
• First basic prototype with static pages is created, it consists of HTML
pages.
• In the second phase, the screens are programmed and fully functional
using a simulated services layer.
• In the last phase, services are implemented.

The Spiral Model
Source: https://www.w3schools.in/sdlc-tutorial/spiral-model/
The Spiral Model cont.
• The Spiral model is an evolutionary process model that couples iterative nature of
prototyping with the controlled and systematic aspects of waterfall model
• It provides the potential for rapid development with a very high emphasis on risk
analysis.
• Software is developed in a series of evolutionary releases.
• Early iteration release might be prototype but later iterations provides more
complete version of software.
• It is divided into framework activities. Each activity represent one segment of the
spiral
• Each pass through the planning region results in adjustments to
• The project plan
• Cost & schedule based on feedback
Phases of Spiral Model
• A spiral model has 4 phases described below:
• Planning phase
• Risk analysis phase
• Engineering phase
• Evaluation phase.

1. Planning phase
• Requirements are gathered from the customers and the objectives are
identified, elaborated and analyzed at the start of every phase.
• Then alternative solutions possible for the phase are proposed in this
quadrant.
• It includes estimating the cost, schedule and resources for the
iteration.
• It also involves understanding the system requirements for continuous
communication between the system analyst and the customer

2. Risk analysis phase
• Identification of potential risk is done while risk mitigation strategy is
planned and finalized.
• A prototype is produced at the end of the risk analysis phase.
• If any risk is found during the risk analysis then alternate solutions
are suggested and implemented.

3. Engineering phase
• Actual development and testing if the software takes place in this
phase.
• At the end of the third quadrant, the next version of the software is
available.

4. Evaluation phase
• Customers evaluate the software and provide their feedback and
approval
• Also, includes identifying and monitoring risks such as schedule
slippage and cost overrun
• In the end, planning for the next phase is started.

• When to use Spiral Model?
• For development of large scale / high-risk projects.
• When costs and risk evaluation is important.
• Users are unsure of their needs.
• Requirements are complex.
• New product line.
• Significant (considerable) changes are expected.
• Advantages
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Strong approval and documentation control.
• Additional functionality can be added at a later date.
• Software is produced early in the Software Life Cycle.

• Disadvantages
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is highly dependent on the risk analysis phase.
• Doesn’t work well for smaller projects.

Rapid Application Development Model
Team - 1
Modeling
Construction
Integration
Communication Delivery
Team - 2 Feedback
Planning Modeling
Deployment
Construction
Team - 3
Modeling Component Reuse
Business Modeling Automatic Code
Data Modeling Generation
Construction
Process Modeling Testing

RAD Model Cont.
• It is also know as RAD Model
• It is a type of incremental model in which; components or functions are
developed in parallel.
• Rapid development is achieved by component based construction
• This can quickly give the customer something to see and use and to
provide feedback.
• Communication
• This phase is used to understand business problem.
• Planning
• Multiple software teams work in parallel on different systems/modules.
RAD Model Cont.
• Modeling
• Business Modeling: Information flow among the business.
• Ex. What kind of information drives (moves)?
• Who is going to generate information?
• From where information comes and goes?
• Data Modeling: Information refine into set of data objects that are needed to support business.
• Process Modeling: Data object transforms to information flow necessary to implement
business.
• Construction
• It highlighting the use of pre-existing software component.
• Deployment
• Deliver to customer basis on subsequent iteration.

RAD Model Cont.
• When to Use ?
• There is a need to create a system that can be modularized in 2-3 months of time.
• High availability of designers and budget for modeling along with the cost of
automated code generating tools.
• Resources with high business knowledge are available.
• Advantages
• Reduced development time.
• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.

RAD Model Cont.
• Drawback
• For large but scalable projects, RAD requires sufficient human resources.
• Projects fail if developers and customers are not committed in a much
shortened time-frame.
• Problematic if system can not be modularized.
• Not appropriate when technical risks are high (heavy use of new technology).

Component based Development
• Commercial off the shelf (COTS) software components are offered as product.
• COTS provides set of functionality with well defined interfaces that enables
component to be integrated into software.
• The component based development model incorporates many characteristics of
the spiral model.
• It is evolutionary in nature.
• Component based development model constructs applications from
prepackaged software components.
• Modeling and construction activities begin with the identification of
components.

Component based Development cont.
• Component based development incorporates the following steps
1. Available component-based products are researched & evaluated for software
development .
2. Component integration issues are considered
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Testing is conducted to insure proper functionality.
• Advantages
• It leads to software reuse.
• It reduces development cycle time.
• Reduction in project cost.
SDLC - Agile Model
• Agility is ability to move quickly and easily.
• Agile SDLC model is a combination of iterative and incremental
process models with focus on process adaptability and customer
satisfaction by rapid delivery of working software product.
• Agile Methods break the product into small incremental builds. These
builds are provided in iterations.
• Each iteration typically lasts from about one to three weeks.
• To accomplish incremental adaptation, an agile team requires
customer feedback (so that the appropriate adaptations can be made).

• Every iteration involves cross functional teams working simultaneously
on various areas like −
• Planning
• Requirements Analysis
• Design
• Coding
• Unit Testing and
• Acceptance Testing
• At the end of the iteration, a working product is displayed to the
customer and important stakeholders.
Agility Principles
• Highest priority is to satisfy the customer through early & continuous
delivery of software
• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Build projects around motivated individuals
• Emphasize face-to-face conversation
• Working software is the measure of progress
• Continuous attention to technical excellence and good design
When to use the Agile Model?
• When frequent changes are required.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with a software team all
the time.
• When project size is small.

Where agile methodology not work
Project plan & Unclear

Big Enterprises where
requirements are understanding of
team collaboration is
clear & unlikely to Agile Approach
tough
change among Teams
#3150711 (SE)  Unit 1 – Introduction to Software & Software

Prof. Pradyumansinh U. Jadeja 56
• The agile software development emphasizes on four core values.
• Individual and team interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile Vs Traditional SDLC Models
• Agile is based on the adaptive software development methods,
whereas the traditional SDLC models like the waterfall model is based
on a predictive approach. Predictive teams in the traditional SDLC
models usually work with detailed planning and have a complete
forecast of the exact tasks and features to be delivered in the next few
months or during the product life cycle.
• Predictive methods entirely depend on the requirement analysis and
planning done in the beginning of cycle. Any changes to be
incorporated go through a strict change control management and
prioritization.

• Agile uses an adaptive approach where there is no detailed planning
and there is clarity on future tasks only in respect of what features need
to be developed. There is feature driven development and the team
adapts to the changing product requirements dynamically. The product
is tested very frequently, through the release iterations, minimizing the
risk of any major failures in future.
• Customer Interaction is the backbone of this Agile methodology, and
open communication with minimum documentation are the typical
features of Agile development environment. The agile teams work in
close collaboration with each other and are most often located in the
same geographical location.
Assignment
• Agile Model – Pros, Cons & Application
• Prototyping Model - Pros, Cons & Application

Agile Process Models
Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Crystal
Agile Modelling (AM)

Dynamic Systems Development
Method(DSDM)
• Dynamic System Development Method is an approach to system
development, which, as the name suggests, develops the system
dynamically.
• The Dynamic System Development Method (DSDM) is dynamic as it is
a Rapid Application Development method that uses incremental
prototyping.
• DSDM is an iterative and incremental approach that emphasizes
continuous user/customer involvement.

• Its goal is to deliver projects on time and on budget while adjusting
for changing requirements along the way.
• DSDM is one of a number of Agile methods for developing software.
• This method is particularly useful for the systems to be developed in
short time span and where the requirements cannot be frozen at the
start of the application building.
• Any project usually has to balance the features and quality
requirements with the time and cost constraints of the organization.
• The traditional project management approach often fixes the features
and quality of the project product.

• In contrast, DSDM methodology fixes the cost, time and quality
requirements and instead prioritizes the product features.
• First, the most important features are developed to an acceptable quality.
These are referred to as the Minimal Usable Subset.
• If time and budget allow, less important features are added to the product.
• Lastly, the least important features are developed. The prioritization of
the features is done using the MoSCoW method, which splits them into
four groups: Must haves, Should haves, Could haves and Won't haves.
• The development process is broken down into fixed duration iterations,
called Timeboxes.

DSDM Principles
• There are eight DSDM principles:
• Focus on the business need: To successfully apply this principle to all
project decisions, the DSDM team should understand business priorities
and commit to deliver at least the Minimum Usable Subset. A valid
business case should be created before the project starts, and continuously
supported.
• Deliver on time: To make sure that the project is delivered on time, the
DSDM team is splitting the work into increments, prioritizing the project
requirements and protecting the deadlines. Long-term project goals are
delivered on time through the on-time delivery of each increment, or
Timebox.
• Collaborate: The DSDM teams improve the performance through successful
collaboration with the right stakeholders. To ensure effective work, each
team member should be empowered to make decisions within his areas of
expertise.
• Never compromise quality: The desired quality of the project products is
agreed on in the beginning of the project by defining the acceptance criteria.
Continuous testing, reviews and documentation are crucial for ensuring an
acceptable quality level.
• Build incrementally from firm foundations: Before significant resources are
dedicated to the project delivery, DSDM build a solid understanding of the
project requirements and proposed solution. After each project increment, or
Timebox, is delivered, the project priorities and viability are re-assessed.
• Develop iteratively: The development process is split into iterations, or
Timeboxes. A crucial part of every iteration is results demonstration and
business feedback. Such approach allows the DSDM team to adjust to the
changes in business needs.
• Communicate continuously and clearly : DSDM methodology encourages
informal communication. The communication needs of the project are fulfilled
by the daily stand-up meetings and workshops. Solution prototypes are shared
with the stakeholders as early as possible to benefit from the feedback.
• Demonstrate control: To make sure that the project remains in control of the
project manager, planning and progress tracking are crucial.

DSDM Phases
• Feasibility and Business Study
• Functional Model Iteration:
• Design and Build Iteration:
• Implementation

Feasibility and Business Study
• In this phase the problem is defined and the technical feasibility of the
desired application is verified. Apart from these routine tasks, it is also
checked whether the application is suitable for Rapid Application
Development (RAD) approach or not.
• Only if the RAD is found as a justified approach for the desired
system, the development continues.
• The overall business study of the desired system is done.
• The business requirements are specified at a high level and the
information requirements out of the system are identified.

• Once this is done, the basic architectural framework of the desired
system is prepared.
• The systems designed using Rapid Application Development (RAD)
should be highly maintainable, as they are based on the incremental
development process.
• The maintainability level of the system is also identified here so as to
set the standards for quality control activities throughout the
development process.

Functional Model Iteration
• The main focus in this phase is on building the prototype iteratively
and getting it reviewed from the users to bring out the requirements of
the desired system.
• The prototype is improved through demonstration to the user, taking
the feedback and incorporating the changes.
• This cycle is repeated generally twice or thrice until a part of
functional model is agreed upon.
• The end product of this phase is a functional model consisting of
analysis model and some software components containing the major
functionality.
Design and Build Iteration
• This phase stresses upon ensuring that the prototypes are satisfactorily
and properly engineered to suit their operational environment
• The software components designed during the functional modeling are
further refined till they achieve a satisfactory standard.
• The product of this phase is a tested system ready for implementation.
• There is no clear line between these two phases and there may be cases
where while some component has flown from the functional modeling to
the design and build modeling while the other component has not yet
been started.
• The two phases, as a result, may simultaneously continue.
Implementation
• Implementation is the last and final development stage in this
methodology.
• In this phase the users are trained and the system is actually put into
the operational environment.
• At the end of this phase, there are four possibilities, as depicted by
figure:
• Everything was delivered as per the user demand, so no further development
required.
• A new functional area was discovered, so return to business study phase and
repeat the whole process.

• A less essential part of the project was missed out due to time constraint and
so development returns to the functional model iteration.
• Some non-functional requirement was not satisfied, so development returns to
the design and build iterations phase.
• According to this approach, the time is taken as a constraint i.e. the
time is fixed, resources are fixed while the requirements are allowed to
change.

Phases to Rule Them

Assignment
• Pros & Cons of DSDM

Lifecycle Stage
• Planning
• Feasibility study,
• Analysis,
• Design,
• Implementation,
• Testing,
• Review or Analysis,
• Maintenance,

Feasibility Study
• The feasibility study is basically the test of the proposed system in the
light of its workability, meeting user’s requirements, effective use of
resources and of course, the cost effectiveness.
• Feasibility Study is essential to evaluate cost & benefits of the
proposed system.
• In the process of feasibility study, the cost and benefits are estimated
with greater accuracy to find the Return on Investment (ROI).
• The result is a feasibility report submitted to the management. This
may be accepted or accepted with modifications or rejected.

Needs of feasibility study
• 1. It determine the potential of the existing system .
• 2. It finds or determine all the problem of existing system.
• 3. To determine all the goals of the system.
• 4. It finds all possible solutions of the problem of existing system.(that
becomes proposed system).
• 5. It finds technology required to solve these problems.
• 6. It determines really which solution is easy for operational from the
point of view of customer or employees such that it requires very less
time with 100% accuracy

• 7. It determines what hardware and software is required to obtain
solution of each problem or proposed system.
• 8. It determines cost requirements of the complete proposed system in
terms of cost of hardware required, software required, designing new
system, implementation and training, proposed maintenance cost.

Four Types of feasibility
• Technical feasibility
Technical feasibility • Schedule feasibility
Schedule feasibility
 Is the project possible with current  Is it possible to build a solution in
Is technology?
the project possible with current Is time
it possible to build a solution in
to be useful?
technology? time to be useful?
What are the consequences of delay?
What technical risk is there? Any constraints on the schedule?
Availability of the technology: Can these constraints be met?
Is it available locally?
Can it be obtained?
Will it be compatible with other systems? • Operational
Operational feasibility
feasibility
• Economic

Economic feasibility
feasibility If the
 system
If the is isdeveloped,
system developed, will
will ititbe
 Is the project possible, given resource
Is constraints?
the project possible, given used?
be used?
resource constraints? Human and social issues…
What are the benefits? Potential labour objections?
Both tangible and intangible
Manager resistance?
Quantify them!
Organizational conflicts and policies?
What are the development and Social acceptability?
operational costs? legal aspects and government regulations?
Are the benefits worth the costs?

Technical Feasibility
• Is the proposed technology or solution practical?
• Do we currently possess the necessary technology?
• Do we possess the necessary technical expertise
• …and is the schedule reasonable for this team?
• Is relevant technology mature enough to be easily applied to our problem?
• What kinds of technology will we need?
• Some organizations like to use state-of-the-art technology
• …but most prefer to use mature and proven technology.
• A mature technology has a larger customer base for obtaining advice concerning problems and
improvements.
• Is the required technology available “in house”?
• If the technology is available:
• …does it have the capacity to handle the solution?
• If the technology is not available:
• …can it be acquired?

Economic Feasibility
• Can the bottom line be quantified yet?
• Very early in the project…
• a judgement of whether solving the problem is worthwhile.
• Once specific requirements and solutions have been identified…
• …the costs and benefits of each alternative can be calculated
• Cost-benefit analysis
• Purpose - answer questions such as:
• Is the project justified (I.e. will benefits outweigh costs)?
• What is the minimal cost to attain a certain system?
• How soon will the benefits accrue?
• Which alternative offers the best return on investment?
• Examples of things to consider:
• Hardware/software selection
• Selection among alternative financing arrangements (rent/lease/purchase)
• Difficulties
• benefits and costs can both be intangible, hidden and/or hard to estimate
• ranking multi-criteria alternatives

Benefits Costs
• Tangible Benefits • Development costs (OTO)
• Readily quantified as $ values • Development and purchasing costs:
• Examples: • Cost of development team
• • Consultant fees
increased sales
• • software used (buy or build)?
cost/error reductions
• • hardware (what to buy, buy/lease)?
increased throughput/efficiency
• facilities (site, communications, power,...)
• increased margin on sales
• more effective use of staff time • Installation and conversion costs:
• installing the system,
• Intangible benefits • training personnel,
• file conversion,....
• Difficult to quantify
• But maybe more important!
• business analysts help estimate $ values
• Operational costs (on-going)
• Examples: • System Maintenance:
• • hardware (repairs, lease, supplies,...),
increased flexibility of operation
• software (licenses and contracts),
• higher quality products/services
• facilities
• better customer relations
• improved staff morale • Personnel:
• For operation (data entry, backups,…)
• How will the benefits accrue? • For support (user support, hardware and software
maintenance, supplies,…)
• When - over what timescale? • On-going training costs
• Where in the organization?

ASSESSING ECONOMIC FEASIBILITY
• The purpose of assessing economic feasibility is to identify the
financial benefits and costs associated with the development project
• Economic feasibility is often referred to as cost–benefit analysis.
• During project initiation and planning, it will be impossible for you to
precisely define all benefits and costs related to a particular project.
• Yet it is important that you spend adequate time identifying and
quantifying these items or it will be impossible for you to conduct an
adequate economic analysis and make meaningful comparisons
between rival projects.

Determining Project Benefits
• An information system can provide many benefits to an organization.
• For example, a new or renovated information system can automate
monotonous jobs and reduce errors; provide innovative services to
customers and suppliers; and improve organizational efficiency,
speed, flexibility, and morale.
• In general, the benefits can be viewed as being both tangible and
intangible.
• Tangible benefits refer to items that can be measured in dollars and
with certainty. Examples of tangible benefits might include reduced
personnel expenses, lower transaction costs, or higher profit margins.
Most tangible benefits will fit within the following categories:
• Cost reduction and avoidance
• Error reduction
• Increased flexibility
• Increased speed of activity
• Improvement of management planning and control
• Opening new markets and increasing sales opportunities
Tangible benefit: A benefit derived from the creation of an information

system that can be measured in dollars and with certainty

• Intangible benefits refer to items that cannot be easily measured in dollars or
with certainty.
• Intangible benefits may have direct organizational benefits, such as the
improvement of employee morale, or they may have broader societal
implications, such as the reduction of waste creation or resource consumption.
• Potential tangible benefits may have to be considered intangible during
project initiation and planning because you may not be able to quantify them
in dollars or with certainty at this stage in the life cycle.
• During later stages, such intangibles can become tangible benefits as you
better understand the ramifications of the system you are designing.
• In this case, the BPP is updated and the business case revised to justify
continuation of the project to the next phase.

• Actual benefits will vary from system to system.
• After determining project benefits, project costs must be identified.
• Intangible benefit: A benefit derived from the creation of an

information system that cannot be easily measured in dollars or with
certainty
Determining Project Costs
• Similar to benefits, an information system can have both tangible and
intangible costs.
• Tangible costs refer to items that you can easily measure in dollars and
with certainty.
• From an IS development perspective, tangible costs include items such
as hardware costs, labor costs, and operational costs including
employee training and building renovations.
• Alternatively, intangible costs are items that you cannot easily measure
in terms of dollars or with certainty.
• Intangible costs can include loss of customer goodwill, employee
morale, or operational inefficiency.
• One goal of a cost–benefit analysis is to accurately determine the total
cost of ownership (TCO) for an investment.
• TCO is focused on understanding not only the total cost of acquisition
but also all costs associated with ongoing use and maintenance of a
system.
• Total cost of ownership (TCO): The cost of owning and operating a
system, including the total cost of acquisition, as well as all costs
associated with its ongoing use and maintenance.

• Consequently, besides tangible and intangible costs, you can
distinguish IS-related development costs as either one-time or
recurring.
• One-time costs refer to those associated with project initiation and
development and the start-up of the system.
• These costs typically encompass activities such as systems
development, new hardware and software purchases, user training,
site preparation, and data or system conversion.
• When conducting an economic cost–benefit analysis, a worksheet
should be created for capturing these expenses.
• Recurring costs refer to those costs resulting from the ongoing
evolution and use of the system.
• Examples of these costs typically include the following:
• Application software maintenance
• Incremental data storage expenses
• Incremental communications
• New software and hardware leases
• Supplies and other expenses (e.g., paper, forms, data center
personnel)
The Time Value of Money(TVM)
• Most techniques used to determine economic feasibility encompass the
concept of the time value of money (TVM), which reflects the notion that
money available today is worth more than the same amount tomorrow.
• As previously discussed, the development of an information system has
both one-time and recurring costs. Furthermore, benefits from systems
development will likely occur sometime in the future.
• Because many projects may be competing for the same investment
dollars and may have different useful life expectancies, all costs and
benefits must be viewed in relation to their present value when
comparing investment options.

Example of TVM
• A simple example will help in understanding the TVM. Suppose you
want to buy a used car from an acquaintance and she asks that you
make three payments of $1500 for three years, beginning next year, for
a total of $4500. If she would agree to a single lump-sum payment at
the time of sale (and if you had the money!), what amount do you think
she would agree to? Should the single payment be $4500? Should it be
more or less? To answer this question, we must consider the time value
of money. Most of us would gladly accept $4500 today rather than
three payments of $1500, because a dollar today (or $4500 for that
matter) is worth more than a dollar tomorrow or next year, given that
money can be invested.
Definitions of Terms
• Present value: current value of a future cash flow
• Discount rate: rate of return used to calculate the present value of
future cash flows
• Time value of money (TVM): comparing present cash outlays to future
expected returns

Net Present Value
PVn = present value of Y dollars n years from

now based on a discount rate of i.
NPV = sum of PVs across years.

Calculates time value of money.
Break-even analysis
• The objective of the break-even analysis is to discover at what point (if

ever) benefits equal costs (i.e., when breakeven occurs)
• To conduct this analysis, the NPV of the yearly cash flows are
determined.
• Here, the yearly cash flows are calculated by subtracting both the one-
time cost and the present values of the recurring costs from the present
value of the yearly benefits.
• The overall NPV of the cash flow reflects the total cash flows for all
preceding years.

Break-Even Analysis

Three Financial Measurements for Economic
Feasibility
• Net Present Value (NPV)
• Use discount rate to determine present value of cash
outlays and receipts
• Return on Investment (ROI)
• Ratio of cash receipts to cash outlays
• Break-Even Analysis (BEA)
• Amount of time required for cumulative cash flow to
equal initial and ongoing investment

Schedule Feasibility
• How long will it take to get the technical expertise?
• We may have the technology, but that doesn't mean we have the skills required to properly apply that
technology.
• May need to hire new people
• Or re-train existing systems staff
• Whether hiring or training, it will impact the schedule.
• Assess the schedule risk:
• Given our technical expertise, are the project deadlines reasonable?
• If there are specific deadlines, are they mandatory or desirable?
• If the deadlines are not mandatory, the analyst can propose several alternative schedules.
• What are the real constraints on project deadlines?
• If the project overruns, what are the consequences?
• Deliver a properly functioning information system two months late…
• …or deliver an error-prone, useless information system on time?
• Missed schedules are bad, but inadequate systems are worse!

Operational Feasibility
• How do end-users and managers feel about…
• …the problem you identified?
• …the alternative solutions you are exploring?
• You must evaluate:
• Not just whether a system can work…
• … but also whether a system will work.
• Any solution might meet with resistance:
• Does management support the project?
• How do the end users feel about their role in the new system?
• Which users or managers may resist (or not use) the system?
• People tend to resist change.
• Can this problem be overcome? If so, how?
• How will the working environment of the end users change?
• Can or will end users and management adapt to the change?

Software Requirement
Analysis and Specification

What is a requirement?
• The software requirements are description of features and functionalities
of the target system.
• Requirements convey the expectations of users from the software product.
• The requirements can be obvious or hidden, known or unknown, expected
or unexpected from client’s point of view.
• The process to gather the software requirements from client, analyze and
document them is known as requirement engineering.
• The goal of requirement engineering is to develop and maintain
sophisticated and descriptive ‘System Requirements Specification’
document.

Requirements analysis is hard
“The hardest single part What is Requirement Engineering?
“The seeds of major
of building a software
software disasters are Tasks and techniques that lead
system is deciding what
usually sown in the to an understanding of
to build. No part of the
first three months of requirements is called
work so cripples the
commencing the requirement engineering.
resulting system if done
software project.”
wrong.”
"Fred" Brooks Jr. is an American Capers Jones is an

computer architect, software engineer, American specialist in
and computer scientist, best known for software engineering
managing the development of IBM's
methodologies
System/360 family of computers
Requirements Analysis and Specification
• Many projects fail:
• because they start implementing the system:
• without determining whether they are building what
the customer really wants.

• It is important to learn:
• requirements analysis and specification techniques
thoroughly.

• Goals of requirements analysis and specification phase:
• fully understand the user requirements
• remove inconsistencies, anomalies, etc. from requirements
• document requirements properly in an SRS document

• Consists of two distinct activities:
• Requirements Gathering and Analysis
• Specification

• The person who undertakes requirements analysis and
specification:
• known as systems analyst:
• collects data pertaining to the product
• analyses collected data:
• to understand what exactly needs to be done.
• writes the Software Requirements Specification (SRS) document.

• Final output of this phase:
• Software Requirements Specification (SRS)
Document.
• The SRS document is reviewed by the customer.
• reviewed SRS document forms the basis of all future
development activities.

Requirements Analysis
• Requirements analysis consists of two main

activities:
• Requirements gathering
• Analysis of the gathered requirements

Requirements Analysis
• Analyst gathers requirements through:
• observation of existing systems,
• studying existing procedures,
• discussion with the customer and end-users,
• analysis of what needs to be done, etc.

Requirements Gathering
• If the project is to automate some existing procedures
• e.g., automating existing manual accounting activities,
• the task of the system analyst is a little easier
• analyst can immediately obtain:
• input and output formats
• accurate details of the operational procedures

Requirements Gathering (CONT.)
• In the absence of a working system,

• lot of imagination and creativity are required.
• Interacting with the customer to gather relevant
data:
• requires a lot of experience.

Requirements Gathering (CONT.)
• Some desirable attributes of a good system

analyst:
• Good interaction skills,
• imagination and creativity,
• experience.

Analysis of the Gathered Requirements
• After gathering all the requirements:
• analyze it:
• Clearly understand the user requirements,
• Detect inconsistencies, ambiguities, and incompleteness.
• Incompleteness and inconsistencies:
• resolved through further discussions with the end-users and the customers.

Inconsistent requirement
• Some part of the requirement:
• contradicts with some other part.
• Example:
• One customer says turn off heater and open water shower when
temperature > 100 C
• Another customer says turn off heater and turn ON cooler when temperature
> 100 C

Incomplete requirement
• Some requirements have been omitted:
• due to oversight.
• Example:
• The analyst has not recorded:
when temperature falls below 90 C
• heater should be turned ON
• water shower turned OFF.

Analysis of the Gathered Requirements (CONT.)
• Requirements analysis involves:
• obtaining a clear, in-depth understanding of the
product to be developed,
• remove all ambiguities and inconsistencies from the
initial customer perception of the problem.

• It is quite difficult to obtain:

• a clear, in-depth understanding of the problem:
• especially if there is no working model of the
problem.

• Experienced analysts take considerable time:
• to understand the exact requirements the customer
has in his mind.

• Experienced systems analysts know -
often as a result of painful experiences ---
• without a clear understanding of the problem, it is
impossible to develop a satisfactory system.

Analysis of the Gathered Requirements(CONT.)
• Several things about the project should be clearly understood
by the analyst:
• What is the problem?
• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What complexities might arise while solving the problem?

• It is quite difficult to obtain:

• a clear, in-depth understanding of the problem:
• especially if there is no working model of the
problem.

• After collecting all data regarding the system to be
developed,
• remove all inconsistencies and anomalies from the requirements,
• systematically organize requirements into a Software Requirements
Specification (SRS) document.

Software Requirements Specification
• Main aim of requirements specification:
• systematically organize the requirements arrived
during requirements analysis
• document requirements properly.

Software Requirements Specification
• The SRS document is useful in various contexts:
• statement of user needs
• contract document
• reference document
• definition for implementation

Software Requirements Specification: A
Contract Document
• Requirements document is a reference document.
• SRS document is a contract between the development team and the
customer.
• Once the SRS document is approved by the customer,
• any subsequent controversies are settled by referring the SRS document.

Software Requirements Specification: A
Contract Document
• Once customer agrees to the SRS document:
• development team starts to develop the product according to the
requirements recorded in the SRS document.
• The final product will be acceptable to the customer:
• as long as it satisfies all the requirements recorded in the SRS
document.

SRS Document (CONT.)
• The SRS document is known as black-box specification:

• the system is considered as a black box whose internal details are
not known.
• only its visible external (i.e. input/output) behavior is documented.
Input Data S Output Data

• SRS document concentrates on:

• what needs to be done
• carefully avoids the solution (“how to do”) aspects.
• The SRS document serves as a contract
• between development team and the customer.
• Should be carefully written

• The requirements at this stage:

• written using end-user terminology.
• If necessary:
• later a formal requirement specification may be
developed from it.

• SRS document, normally contains three

important parts:
• functional requirements,
• nonfunctional requirements,
• constraints on the system.

• It is desirable to consider every system:
• performing a set of functions {fi}.
• Each function fi considered as:
• transforming a set of input data to corresponding output data.
Input Data Output Data

fi

SRS (Software Requirements Specification)
Software Requirement Specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it.
SRS is also helping the clients to understand their own needs.
SRS Contains
A complete information description A detailed functional description
A representation of system behaviour
An indication of performance requirements and design constraints
Appropriate validation criteria

Other information suitable to requirements
Characteristics of a Good SRS
 SRS should be accurate, complete, efficient, and of high quality, so that it does not affect
the entire project plan.
 An SRS is said to be of high quality when the developer and user easily understand the
prepared document.
 Characteristics of a Good SRS:
Correct Unambiguou Complete

s
SRS is correct when all user SRS is unambiguous SRS is complete when the
requirements are stated in the when every stated requirements clearly define
requirements document. requirement has only what the software is
one interpretation. required to do.
Note that there is no specified
tool or procedure to assure the
correctness of SRS.

Characteristics of a Good SRS Cont.
Ranked for Importance/Stability Modifiable
All requirements are not equally important, hence The requirements of the user can
each requirement is identified to make differences change, hence requirements
among other requirements. document should be created in such
Stability implies the probability of changes in the a manner that those changes can be
requirement in future. modified easily.
Traceable Verifiable Consistent

SRS is traceable when the SRS is verifiable when the SRS is consistent when the
source of each requirement is specified requirements can be subsets of individual
clear and facilitates the verified with a cost-effective requirements defined do
reference of each process to check whether the not conflict with each
requirement in future. final software meets those other.
requirements.
Problems Without SRS
 Without developing the SRS document, the system would not be properly implemented
according to customer needs.
 Software developers would not know whether what they are developing is what exactly is
required by the customer.
 Without SRS, it will be very difficult for the maintenance engineers to understand the
functionality of the system.
 It will be very difficult for user document writers to write the users’ manuals properly
without understanding the SRS.

Standard Template for writing SRS
1. Introduction 3. System Features
1.1 Purpose 3.1 System Feature 1
1.2 Document Conventions 3.2 System Feature 2 (and so on)
1.3 Intended Audience and Reading 4. External Interface Requirements
Suggestions
4.1 User Interfaces
1.4 Project Scope
4.2 Hardware Interfaces
1.5 References
4.3 Software Interfaces
2. Overall Description 4.4 Communications Interfaces
2.1 Product Perspective
5. Other Nonfunctional Requirements
2.2 Product Features
5.1 Performance Requirements
2.3 User Classes and Characteristics
5.2 Safety Requirements
2.4 Operating Environment
5.3 Security Requirements
2.5 Design and Implementation Constraints
5.4 Software Quality Attributes
2.6 User Documentation
2.7 Assumptions and Dependencies 6. Other Requirements

Example: Functional Requirement
• F1: Search Book
• Input:
• an author’s name:
• Output:
• details of the author’s books and the locations of these books in the library.
Author Name Book Details

f1

Functional Requirements
• Functional requirements describe:
• A set of high-level requirements
• Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
• Each high-level requirement:
• might consist of a set of identifiable functions

Functional Requirements
• For each high-level requirement:
• every function is described in terms of
• input data set
• output data set
• processing required to obtain the output data set from
the input data set

Nonfunctional Requirements
• Characteristics of the system which can not be
expressed as functions:
• maintainability,
• portability,
• usability, etc.

Nonfunctional Requirements
• Nonfunctional requirements include:
• reliability issues,
• performance issues,
• human-computer interface issues,
• Interface with other external systems,
• security, maintainability, etc.

Constraints
• Constraints describe things that the system should or should not do.
• For example,
• standards compliance
• how fast the system can produce results
• so that it does not overload another system to which it
supplies data, etc.

Examples of constraints
• Hardware to be used,
• Operating system
• or DBMS to be used
• Capabilities of I/O devices
• Standards compliance
• Data representations
• by the interfaced system

Organization of the SRS Document
• Introduction.
• Functional Requirements
• Nonfunctional Requirements
• External interface requirements
• Performance requirements
• Constraints

Example Functional Requirements
• List all functional requirements
• with proper numbering.
• Req. 1:
• Once the user selects the “search” option,
• he is asked to enter the key words.
• The system should output details of all books
• whose title or author name matches any of the key words entered.
• Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number,
Catalog Number, Location in the Library.

Example Functional Requirements
• Req. 2:
• When the “renew” option is selected,
• the user is asked to enter his membership number and password.
• After password validation,
• the list of the books borrowed by him are displayed.
• The user can renew any of the books:
• by clicking in the corresponding renew box.

Req. 1:
• R.1.1:
• Input: “search” option,
• Output: user prompted to enter the key words.
• R1.2:
• Input: key words
• Output: Details of all books whose title or author name matches any of the
key words.
• Details include: Title, Author Name, Publisher name, Year of Publication, ISBN Number,
Catalog Number, Location in the Library.
• Processing: Search the book list for the keywords

Req. 2:
• R2.1:
• Input: “renew” option selected,
• Output: user prompted to enter his membership number and
password.
• R2.2:
• Input: membership number and password
• Output:
• list of the books borrowed by user are displayed. User prompted to enter
books to be renewed or
• user informed about bad password
• Processing: Password validation, search books issued to the user
from borrower list and display.

Req. 2:
• R2.3:
• Input: user choice for renewal of the books issued to him through mouse clicks
in the corresponding renew box.
• Output: Confirmation of the books renewed
• Processing: Renew the books selected by the in the borrower list.

Examples of Bad SRS Documents
• Unstructured Specifications:
• Narrative essay --- one of the worst types of specification document:
• Difficult to change,
• difficult to be precise,
• difficult to be unambiguous,
• scope for contradictions, etc.

• Noise:
• Presence of text containing information irrelevant to the problem.
• Silence:
• aspects important to proper solution of the problem are omitted.

• Overspecification:
• Addressing “how to” aspects
• For example, “Library member names should be stored in a sorted
descending order”
• Overspecification restricts the solution space for the designer.
• Contradictions:
• Contradictions might arise
• if the same thing described at several places in different ways.

• Ambiguity:
• Literary expressions
• Unquantifiable aspects, e.g. “good user interface”
• Forward References:
• References to aspects of problem
• defined only later on in the text.
• Wishful Thinking:
• Descriptions of aspects
• for which realistic solutions will be hard to find.

Functional requirements Non-functional requirements
Any requirement which specifies what the system Any requirement which specifies how the
Should do. system performs a certain function.
A functional requirement will describe a
A non-functional requirement will
particular behavior of function of the system
describe how a system should behave
when certain conditions are met, for example:
and what limits there are on its
“Send email when a new customer signs up” or
“Open a new account”.
functionality.
Typical functional requirements Typical non-functional requirements

Business Rules Administrative functions Historical Data Response time Availability Regulatory
Throughput Reliability Manageability
Transaction corrections, Legal or Regulatory
adjustments and cancellations Requirements Utilization Recoverability Environmental
External Reporting Requirements Authenticatio Static volumetric Maintainability Data Integrity
Interfaces n
Authorization levels Scalability Serviceability Usability
Audit Tracking Capacity Security Interoperabilit

y
Library Management System
Function Requirements Non-function Requirements
 Add Article: New entries must be entered in database  Safety Requirements: The database may get
 Update Article: Any changes in articles should be updated in crashed at any certain time due to virus or
case of update operating system failure. So, it is required to
 Delete Article: Wrong entry must be removed from system take the database backup.
 Inquiry Members: Inquiry all current enrolled members to view
 Security Requirements: We are going to
their details develop a secured database for the university.
There are different categories of users namely
 Inquiry Issuance: Inquiry all database articles
teaching staff, administrator, library staff
 Check out Article: To issue any article must be checked out ,students etc., Depending upon the category of
 Check In article: After receiving any article system will reenter user the access rights are decided.
article by Checking  Software Constraints: The development of the
 Inquiry waiting for approvals: Librarian will generates all newly system will be constrained by the availability of
application which is in waiting list required software such as database and
 Reserve Article: This use case is used to reserve any book with development tools. The availability of these
the name of librarian, it can be pledged tools will be governed by

Software Development Life Cycle (SDLC) : 12/27/2021 Er. Roshan Kandel 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Development Life Cycle (SDLC) : 12/27/2021 Er. Roshan Kandel 1

Uploaded by

Copyright:

Available Formats

Software Development Life

12/27/2021 Er. Roshan Kandel 1

12/27/2021 Er. Roshan Kandel 4

12/27/2021 Er. Roshan Kandel 5

12/27/2021 Er. Roshan Kandel 6

12/27/2021 Er. Roshan Kandel 7

12/27/2021 Er. Roshan Kandel 9

12/27/2021 Er. Roshan Kandel 11

12/27/2021 Er. Roshan Kandel 12

12/27/2021 Er. Roshan Kandel 13

12/27/2021 Er. Roshan Kandel 14

12/27/2021 Er. Roshan Kandel 15

12/27/2021 Er. Roshan Kandel 17

Team first moves down the left side

12/27/2021 Er. Roshan Kandel 19

12/27/2021 Er. Roshan Kandel 20

12/27/2021 Er. Roshan Kandel 21

12/27/2021 Er. Roshan Kandel 23

12/27/2021 Er. Roshan Kandel 24

12/27/2021 Er. Roshan Kandel 25

12/27/2021 Er. Roshan Kandel 27

12/27/2021 Er. Roshan Kandel 28

12/27/2021 Er. Roshan Kandel 29

12/27/2021 Er. Roshan Kandel 30

12/27/2021 Er. Roshan Kandel 31

12/27/2021 Er. Roshan Kandel 32

12/27/2021 Er. Roshan Kandel 33

12/27/2021 Er. Roshan Kandel 34

12/27/2021 Er. Roshan Kandel 37

12/27/2021 Er. Roshan Kandel 38

12/27/2021 Er. Roshan Kandel 39

12/27/2021 Er. Roshan Kandel 40

12/27/2021 Er. Roshan Kandel 41

12/27/2021 Er. Roshan Kandel 42

12/27/2021 Er. Roshan Kandel 43

12/27/2021 Er. Roshan Kandel 44

12/27/2021 Er. Roshan Kandel 46

12/27/2021 Er. Roshan Kandel 47

12/27/2021 Er. Roshan Kandel 48

12/27/2021 Er. Roshan Kandel 49

12/27/2021 Er. Roshan Kandel 51

12/27/2021 Er. Roshan Kandel 55

Project plan & Unclear

#3150711 (SE)  Unit 1 – Introduction to Software & Software

12/27/2021 Er. Roshan Kandel 57

12/27/2021 Er. Roshan Kandel 58

12/27/2021 Er. Roshan Kandel 60

Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM)

Feature Driven Development (FDD)

Agile Modelling (AM)

#3150711 (SE)  Unit 1 – Introduction to Software & Software

12/27/2021 Er. Roshan Kandel 62

12/27/2021 Er. Roshan Kandel 63

12/27/2021 Er. Roshan Kandel 64

12/27/2021 Er. Roshan Kandel 67

12/27/2021 Er. Roshan Kandel 68

12/27/2021 Er. Roshan Kandel 69

12/27/2021 Er. Roshan Kandel 70

12/27/2021 Er. Roshan Kandel 73

12/27/2021 Er. Roshan Kandel 74