INTRODUCTION TO SOFTWARE:

 Software is a set of instructions used to get inputs and process them to produce the
desired output.
 It also includes a set of documents, such as the software manual, Source
Code, Executables, Design Documents, Operations, and System Manuals
and Installation and Implementation Manuals.

Software Engineering
A few important definitions given by several authors and institutions are as follows:

Definition:
Software Engineering is the application of a systematic, disciplined,
scientific approach to the development, operation and maintenance of
software.
OR
Software Engineering is a discipline whose aim is the production of
fault free software that satisfies the user’s needs and that is delivered on time
and within budget.

Goals of Software Engineering:

The primary goals of Software Engineering is
1. To improve the quality, reliability of software.
2. To increase productivity.
3. To increase the job satisfaction of software engineers, etc.

A program is a set of instructions written by a programmer to perform a

specific task on a computer. In contrast, a product is a complete software
solution developed through a series of stages, known as the software
development life cycle, to address a specific problem or need for an
enterprise. Programs are simpler and reside passively in memory, while
products are complex, actively produced, and distributed to users.
Understanding these differences helps clarify their distinct roles and
development processes in the tech industry.
PROGRAMS VERSUS SOFTWARE PRODUCTS
Programs
 A program is a combination of source code and object code.
 A program is a subset of software and it
becomes software only if documentation
and operating procedure manuals are
prepared.
 Program = Source Code + Object Code

Software Products
 A software product consists not only
of the program code but also of all the
 associated documents, such as the
requirements specification documents,
the design documents, the test
documents, and the operating
procedures, user manuals and
operational manuals, etc.
 Software = Program + Documentation + Operating Procedures

What is Program?
The use and need of computers is widespread in today's world. The
computer system is however incapable of working on its own and needs
certain instructions to do anything. These instructions are provided to the
computer system by a computer programmer. A collection of instructions
meant to perform a specific task, written by a computer programmer is
called a program.

What is Product?
Product is made only on the request of an enterprise. The team of
developers undertakes the making of the product (called project). A
software product is the finished project which was made after performing
the various software development life cycle stages. After the completion of
these stages the product comes into existence. It is then made in more
numbers, for distribution. The software product is made to solve a specific
problem.
Difference between Program and Product
Aspect Program Product

Program
contains a set of
Nature and instructions Product is the final manufacture and
Purpose designed to production of the project.
complete a
specific task.

It is a passive
entity as it It is an active entity as it is made again
Entity Type resides in the and again for the purpose of distribution
secondary to users.
memory.

Existence It exists at a A product can exist for a long period of

single place and time as long as it is tested for better
continues to performance and durability. A specific
 Aspect Program Product

exist until it is software product would stop existing if it

deleted. is destroyed or uninstalled.

It can be made It needs a lot of time to be made. There

Development in relatively are several stages (design,
Time shorter period of coding, testing, maintenance etc.) to
time. form a product.

It is handled by
Management the program It is handled by product managers.
managers.

It does not have

any resource
requirement, it
Resource It needs human, technology and time
only requires
Requirements resources to be functional.
memory space
for storing the
instructions.

The main focus

of the program
The main focus of a product is its
is whether it is
Focus capability to solve the problem that it
giving a specific
was made for.
desired output
or not.

There are no
concrete
In case of product, the firm guidelines
Guidelines guidelines in
are followed.
writing a
program.

It may or may It needs to worry about the cost and

Efficiency and not focus on efficiency as it would affect the
Cost efficiency and profitability of the enterprise launching
cost. the product.
 S. Programs Software Products
No.
1. Programs are developed by individuals A software product is usually developed by a group of
for their personal use. engineers working as a team.
2 Usually small in size Usually large in size
3 Single user Large number of users
4 Single developer Team of developers
5 Lack proper documentation Good documentation support
6 Adhoc development Systematic development
7 Lack of user interface Good user interface
8 Have limited functionality Exhibit more functionality

Need of Software Engineering




Software engineering is a technique through which we can develop or
create software for computer systems or any other electronic devices. It is
a systematic, scientific and disciplined approach to the development,
functioning, and maintenance of software.
Purpose of Software Engineering

 Handling Big Projects: A corporation must use a software

engineering methodology in order to handle large projects without any
issues.
 To manage the cost: Software engineering programmers plan
everything and reduce all those things that are not required.
 To decrease time: It will save a lot of time if you are developing
software using a software engineering technique.
 Reliable software: It is the company's responsibility to deliver software
products on schedule and to address any defects that may exist.
 Effectiveness: Effectiveness results from things being created in
accordance with the standards.
 Reduces complexity: Large challenges are broken down into smaller
ones and solved one at a time in software engineering. Individual
solutions are found for each of these issues.
 Productivity: Because it contains testing systems at every level,
proper care is done to maintain software productivity.
Why Software Engineering Is Needed
 Structured Development Approach
Software engineering provides a systematic and organized way to
design, develop, test, and maintain software, ensuring consistency and
quality.
 Managing Software Complexity
Modern software systems are large and complex. Software engineering
breaks problems into smaller, manageable parts, making development
easier and more reliable.
 Quality and Reliability Assurance
Through defined standards and testing practices, software engineering
ensures software is reliable, defect-free, and meets user requirements.
 Cost and Time Management
Proper planning and process control help reduce development costs,
avoid unnecessary work, and ensure timely delivery of software
projects.
 Use of Proven Methodologies
Frameworks such as Agile, Scrum, and Waterfall guide the
development process and improve productivity and coordination.
 Testing and Quality Assurance
Techniques like unit testing, integration testing, and acceptance testing
help detect and fix issues early in the development cycle.
 Project Management and Team Collaboration
Software engineering supports effective management of resources,
schedules, and budgets while enabling smooth collaboration among
team members.
 Maintainability and Evolution
Software engineering makes software easy to update, improve, and
adapt to changing user needs and technologies.
1.4 EMERGENCE OF SOFTWARE ENGINEERING

We have already pointed out that software engineering techniques have evolved over many
years in the past. This evolution is the result of a series of innovations and accumulation of
experience about writing good quality programs. Since these innovations and programming
experiences are too numerous, let us briefly examine only a few of these innovations and
programming experiences which have contributed to the development of the software
engineering discipline.

1.4.1 Early Computer Programming

Early commercial computers were very slow and too elementary as compared to today's standards.
Even simple processing tasks took considerable computation time on those computers. No wonder
that programs at that time were very small in size and lacked sophistication. Those programs were
usually written in assembly languages. Program lengths were typically limited to about a few
hundreds of lines of monolithic assembly code.

Every programmer developed his own individualistic style of writing programs according to
his intuition and used this style ad hoc while writing different programs. In simple words,
programmers wrote programs without formulating any proper solution strategy, plan, or
design. They would jump to the terminal and start coding immediately on hearing out the
problem. They then went on fixing any problems that they observed until they had a program
that worked reasonably well.

We have already designated this style of programming as the build and fix (or the
exploratory programming) style.

1.4.2 High-Level Language Programming

Computers became faster with the introduction of semiconductor technology in the early
1960s. Faster semiconductor transistors replaced the prevalent vacuum tube-based circuits in
a computer. With the availability of more powerful computers, it became possible to solve
larger and more complex problems.

At this time, high-level languages such as FORTRAN, ALGOL, and COBOL were
introduced. This considerably reduced the effort required to develop software and helped
programmers to write larger programs. Writing each high-level programming construct, in
effect, enables the programmer to write several machine instructions. Also, the machine
details (registers, flags, etc.) are abstracted from the programmer.

However, programmers were still using the exploratory style of software development.
Typical programs were limited to sizes of around a few thousands of lines of source code.

1.4.3 Control Flow-based Design

As the size and complexity of programs kept on increasing, the exploratory programming
style proved to be insufficient. Programmers found it increasingly difficult not only to write
cost-effective and correct programs, but also to understand and maintain programs written by
others. To cope up with this problem, experienced programmers advised other programmers
to pay particular attention to the design of a program's control flow structure.

The main objective was to make the control flow of programs easier to understand. This led
to the development of structured programming, which discouraged the use of GOTO
statements and promoted well-structured control constructs such as sequence, selection, and
iteration. Structured programming helped eliminate messy and unstructured programs. The
virtues of structured programming became widely accepted and the structured programming
concepts are being used even today. However, violations to the structured programming
feature are usually permitted in certain specific programming situations, such as exception
handling, etc.

Very soon several languages such as PASCAL, MODULA, C, etc., became available which
were specifically designed to support structured programming. These programming
languages facilitated writing modular programs and programs having good control structures.
Therefore, messy control structure was no longer a big problem. So, the focus shifted from
designing good control structures to designing good data structures for programs.

1.4.4 Data Structure-oriented Design

Computers became even more powerful with the advent of integrated circuits (ICs) in the
early seventies. These could now be used to solve more complex problems. Software
developers were tasked to develop larger and more complicated software, which often
required writing in excess of several tens of thousands of lines of source code. The control
flow-based program development techniques could not be used satisfactorily any more to
write those programs, and more effective program development techniques were needed.

It was soon discovered that while developing a program, it is much more important to pay
attention to the design of the important data structures of the program than to the design of its
control structure. Design techniques based on this principle are called data structure-
oriented design techniques.

1.4.6 Object-oriented Design

Data flow-oriented techniques evolved into object-oriented design (OOD) techniques in the
late seventies. Object-oriented design technique is an intuitively appealing approach, where
the natural objects (such as employees, payroll register, etc.) relevant to a problem are first
identified, and then the relationships among the objects such as composition, reference, and
inheritance are determined.

Each object essentially acts as a data hiding (also known as data abstraction) entity.
Object-oriented techniques have gained widespread acceptance because of their simplicity,
the scope for code and design reuse, promise of lower development time, lower development
cost, more robust code, and easier maintenance.
changes in software development practices
Introduction:

Over the past five decades, software development has evolved from an exploratory build-and-
fix approach to a systematic software engineering process. The introduction of life cycle
models, project management techniques, testing and quality assurance techniques, software
metrics, and CASE tools has helped software engineering grow as a disciplined engineering
field.

Notable Changes in Software Development Practices

1) Error prevention instead of Error correction:

Earlier practices focused on error correction after coding. Modern software engineering
emphasizes error prevention by detecting and fixing errors in the same phase in which they
are introduced, achieving phase containment of errors.

2) Coding is only One Activity:

Earlier, coding was considered the entire development process. Modern practices recognize
that requirement analysis, design, testing, and maintenance are equally important and often
require more effort than coding.

3) Emphasis on Requirements Specification:

Significant effort is now spent on preparing a clear and correct requirements specification
before development begins, reducing rework, cost, and customer dissatisfaction.

4) Separate Design Phase:

A distinct design phase now exists in which standard design techniques are used to produce
complete and consistent design models before coding.

5) Periodic Reviews:
Regular reviews are conducted in every phase to detect errors early and reduce development
cost, supporting phase containment.

6) Systematic Testing:
Software testing has become planned and systematic, with test cases designed from the
requirements stage, making testing an ongoing activity.

7) Improved Documentation:
Modern practices stress good quality documentation, improving software visibility,
maintenance, and fault diagnosis.

8) Project Planning and Metrics:

Projects are thoroughly planned using cost estimation, scheduling, resource management, and
software metrics to improve project control and quality assurance.
Conclusion:
Thus, software development has shifted from an ad-hoc, code-centric approach to a structured
and disciplined engineering process, resulting in better quality, maintainability, and
predictability of software systems.

The Software Development Life Cycle (SDLC) is a structured process used

to plan, design, develop, test, deploy, and maintain software. It ensures a
systematic workflow and helps align software development with business
goals and user requirements.
 Provides a clear and organized framework for managing development
phases
 Helps in early detection of defects, reducing overall cost and time
 Ensures high-quality software delivery that meets user expectations

Stages of the Software Development Life Cycle

The Software Development Life Cycle (SDLC) typically consists of six or
seven stages, depending on the development model used.

Stage 1: Planning & Feasibility Analysis

This stage determines whether the project is technically, financially, and

operationally feasible.
 Activities: Feasibility analysis, cost estimation, scheduling, resource
planning
 Output: Project Plan, Feasibility Report
 Key Roles: Project Managers, Senior Engineers, Stakeholders
Stage 2: Requirement Specification (SRS)

In this stage, detailed functional and non-functional requirements are

documented clearly and approved by stakeholders.
 Activities: Requirement gathering, validation, documentation
 Output: Software Requirement Specification (SRS)
 Key Roles: Business Analysts, Product Owners

Stage 3: System Design

In this stage, the approved requirements are transformed into a technical

blueprint for implementation.
 High-Level Design (HLD): Defines system architecture, technology
stack, database design, and major modules.
 Low-Level Design (LLD): Specifies component logic, APIs, data
structures, and workflows.
 Output: Design Document Specification (DDS)
 Stage-3

Stage 4: Development (Coding)

Developers build the software based on the approved design.

 Activities: Coding, code reviews, unit testing, version control
management
 Tools: IDEs, version control systems, debuggers
 Output: Source code, executable application
 Key Roles: Frontend, Backend, Full Stack Developers

Stage 5: Testing

Testing ensures the software meets requirements and is free from defects
before release.
Types of Testing include:
 Unit Testing: Verifies individual components
 Integration Testing: Ensures modules work together
 System Testing: Validates the complete system
 User Acceptance Testing (UAT): Confirms business requirements are
met
Output: Test cases, defect reports, and quality metrics.

Stage 6: Deployment

The tested software is released to users.

 Activities: Production setup, deployment, smoke testing
 Modern Approach: Continuous Integration and Continuous
Deployment (CI/CD) pipelines for faster and reliable releases
 Output: Live application
 Key Roles: DevOps Engineers, Release Managers

Stage 7: Maintenance

Post-deployment support ensures long-term usability.

 Activities: Bug fixes, performance tuning, updates, feature
enhancements
 Output: Patches, updates, new versions
 Key Roles: Support Engineers, Developers
 Software Development
Life Cycle (SDLC) Notes
 Life Cycle Model
  A life cycle model
(also called a process
model) is a descriptive
and diagrammatic
 representation of the
software life cycle.
  It maps activities
from the inception to
the retirement of the
software product.
  These models
organize and guide the
development activities
in different ways,
 ensuring a structured
approach to software
development.
 Need for a Software Life
Cycle Model
  Ensures a systematic
and disciplined
approach to software
development.
  Prevents chaos by
providing a clear
understanding among
team members of what
to
 do and when.
  Defines entry and
exit criteria for each
 phase, ensuring that a
phase starts only when
 the previous one is
completed.
  Helps project
managers monitor
progress efficiently.
 Common Software Life
Cycle Models
  Classical Waterfall
Model
  Iterative Waterfall
Model
  Prototyping Model
  Evolutionary Model
  Spiral Mode
 Software Development
 Life Cycle (SDLC) Notes
 Life Cycle Model
  A life cycle model
(also called a process
model) is a descriptive
and diagrammatic
 representation of the
software life cycle.
  It maps activities
from the inception to
the retirement of the
software product.
  These models
organize and guide the
development activities
in different ways,
 ensuring a structured
 approach to software
development.
 Need for a Software Life
Cycle Model
  Ensures a systematic
and disciplined
approach to software
development.
  Prevents chaos by
providing a clear
understanding among
team members of what
to
 do and when.
  Defines entry and
exit criteria for each
phase, ensuring that a
 phase starts only when
 the previous one is
completed.
  Helps project
managers monitor
progress efficiently.
 Common Software Life
Cycle Models
  Classical Waterfall
Model
  Iterative Waterfall
Model
  Prototyping Model
  Evolutionary Model
  Spiral Mode
 Software Development
Life Cycle (SDLC) Notes
 Life Cycle Model
  A life cycle model
(also called a process
model) is a descriptive
and diagrammatic
 representation of the
software life cycle.
  It maps activities
from the inception to
the retirement of the
software product.
  These models
organize and guide the
development activities
in different ways,
 ensuring a structured
approach to software
 development.
 Need for a Software Life
Cycle Model
  Ensures a systematic
and disciplined
approach to software
development.
  Prevents chaos by
providing a clear
understanding among
team members of what
to
 do and when.
  Defines entry and
exit criteria for each
phase, ensuring that a
phase starts only when
 the previous one is
completed.
  Helps project
managers monitor
progress efficiently.
 Common Software Life
Cycle Models
  Classical Waterfall
Model
  Iterative Waterfall
Model
  Prototyping Model
  Evolutionary Model
  Spiral Mode
 Software Development
Life Cycle (SDLC) Notes
 Life Cycle Model
  A life cycle model
(also called a process
model) is a descriptive
and diagrammatic
 representation of the
software life cycle.
  It maps activities
from the inception to
the retirement of the
software product.
  These models
organize and guide the
development activities
in different ways,
 ensuring a structured
approach to software
development.
 Need for a Software Life
Cycle Model
  Ensures a systematic
and disciplined
approach to software
development.
  Prevents chaos by
providing a clear
understanding among
team members of what
to
 do and when.
  Defines entry and
exit criteria for each
phase, ensuring that a
phase starts only when
 the previous one is
 completed.
  Helps project
managers monitor
progress efficiently.
 Common Software Life
Cycle Models
  Classical Waterfall
Model
  Iterative Waterfall
Model
  Prototyping Model
  Evolutionary Model
  Spiral Mode
Classical Waterfall Model
The classical Waterfall Model was the first Process Model. It is
also known as a linear-sequential life cycle model. It is very
simple to understand and use.
Classical waterfall model is the earliest, best known and most
commonly used methodology. It is a sequential lifecycle that is
simple to understand and use each phase has to be completed
finished before another start which means no overlapping is allowed.
Six Phases of Classical
Waterfall Model
The waterfall model is intuitively the most obvious way to develop
software. It divides the software life cycle into the six phases, as
shown in Figure 1.

1. Feasibility Study
The main aim of the feasibility study is to determine whether it
would be technically and financially feasible to develop the
product. The feasibility study activity involves analysis of the
problem and collection of all relevant information relating to the
product. The collected data is analyzed to arrive at the following:
 An abstract problem definition: Only the important
requirements of the customer are captured and the details of the
requirement are ignored.

 Formulation of the different strategies for solving the

problem: All the different ways in which the problem can be
solved are identified.

 Evaluation of the different solution strategies: Different

solution strategies are analyzed to examine their benefits and
shortcomings. This analysis usually requires making approximate
estimates of the resources required, cost of development, and
development time required for each of the alternative solutions.
2. Requirement Analysis and Specification
The aim of the requirements analysis and specification phase is
to understand the exact requirements of the customer and to
document them properly. This phase consists of two distinct
activities, namely requirements gathering and analysis, and
requirements specification as follows:
 Requirements Gathering and Analysis: The goal of the
requirements gathering activity is to collect all relevant
information from the customer regarding the product to be
developed. Once the requirements have been gathered, the
analysis activity is taken up. The goal of the requirement analysis
is to weed out the incompleteness and inconsistencies in these
requirements.

 Requirement Specification: The customer requirements

identified during the requirements gathering and analysis activity
are organized into a software requirement specification (SRS)
document. The important components of this document are
functional requirements, non-functional requirements, and the
goals of implementation.
3. Design
The goal of the design phase is to transform the requirements
specified in the SRS document into a structure that is suitable for
implementation in some programming language. In technical terms,
during the design phase, the software architecture is derived from
the SRS document. There are two design approaches being used at
present: traditional design approach and object-oriented
design approach.
4. Coding and Unit Testing
The purpose of coding and unit testing phase of software
development is to translate the software design into the source
code. The coding phase is also sometimes called
the implementation phase since the design is implemented into a
workable solution in this phase. Each component of design is
implemented as a program module. The end-product of this phase is
a set of program modules that been individually tested. After coding
is complete, each module is unit-tested to determine the correct
working of all individual modules.
5. Integration and System Testing
During this phase, the different modules are integrated in a planned
manner. The plan specifies the order in which modules are
combined to realize the full system. Integration of various modules
are normally carried out incrementally over a number of steps. After
each integration step, the partially integrated system is tested.
Finally, after all modules have been successfully integrated and
tested, system is carried out. The goal of system testing is to ensure
that the developed system conforms to its requirements laid out in
the SRS document.

Alpha testing: is the type of testing which is performed by the

developer’s.
Beta testing: is the type of testing which is performed by a real
users and friendly set of customers.
6. Maintenance
Maintenance involves monitoring and improving system
performance, enhancing system services, and upgrading to newer
versions. Maintenance of a typical software product requires much
more effort than the effort necessary to develop the product itself.
The past studies indicate that the relative effort of development of a
typical software product to its maintenance effort is roughly in 40:60
ratio.

Application of Waterfall
Model
 Limited amount of ambiguous or unconfirmed requirements.
 A software that needs well documented documentations.
 Use of mature technology and not dynamic.
 Management can provide enough resources and experts to pick
up the role at its phase.

Advantages of Waterfall
Model
 Classical waterfall model is easy to understand and simple to
use.
 In the waterfall model, only one phase is executed at a
time or phases cannot overlap.
 In this model, each phase is clearly defined.
 Waterfall model works best for a small project, where
requirements are clearly defined.
 It has clearly understood milestones.
 Each Process, actions and results are well documented.

Disadvantages
Idealistic Model:
It assumes that no errors occur during development, but in
real projects, errors can happen in every phase.
Changing Requirements:
It assumes all requirements are fixed at the beginning. In
reality, customers may change their requirements later, which
is difficult to accommodate.
Sequential Phases:
It assumes that each phase must be completed before the next
begins. In practice, phases may overlap. For example, testers
can start preparing test cases while the system is still being
designed.

What is Iterative Waterfall

Model?
In practice, it is not possible to strictly follow the classical waterfall
model for software development work. In this context, we can view
the iterative waterfall model as making necessary changes to the
classical waterfall model so that it becomes applicable to practical
software development projects.

The feedback paths allow for correction of the errors committed

during a phase, as and when these are detected in a later phase.

For example, if during a testing a design error is identified, then

the feedback path allows the design to be reworked and the
changes to be reflected in the design documents. However, observe
that there is no feedback path to the feasibility stage. This means
that the feasibility study errors cannot be corrected.
The iterative waterfall model is the most widely used software
development model evolved so far.

When to use Iterative

Waterfall Model
 The requirement of the defined and clearly understood.
 New technology is being learned by the development team.
 There are some high risk features and goals which might in the
future.

Application of Iterative
Waterfall Model
 Major requirements are defined but the minor details might
involve when time goes.
 New technologies are being used and there is a learning curve for
the programmers to learn.
 Resource are limited to do a huge project as if a small project
automates are in contact rather than permanent.
 Very high risk as a goal of the project might change from time to
time.

Advantages of Iterative
Waterfall Model
 Feedback Path: iterative waterfall allows the mechanism of error
connection because there is a feedback path from one phase to its
preceding phase which it lacks in the Waterfall Model.
 Simple: iterative waterfall model is simple to understand and
use. It is the most widely used software development model
evolved so far.
 Parallel development: can be done.

Disadvantage of Iterative
Waterfall Model
 More resource: may be required to implement the iterative
waterfall model.
 Difficult to include change requests: In the iterative waterfall
model, all the requirements must be clearly defined before
starting of the development phase but sometimes customer
requirement changes which is difficult to incorporate change
requests that are made after development phase starts.
 Not support Intermediate delivery: Project has to be fully
completed before it delivered to the customer.
 Risk handling: Project is prone to many types of risk but there is
no risk handling mechanism.
 Not suitable for a small project.

What is Prototype Model?

A prototype model is a toy/demo implementation of the actual
product or system. A prototype model usually exhibits limited
functional capabilities, low reliability, and inefficient performance as
compared to the actual software.

A prototype model is usually built using several shortcuts. The

shortcuts might involve using inaccurate, inefficient or dummy
functions. A prototype usually turns out to be a very crude version of
the actual system.
The prototyping model of software development is shown in Figure
3. As shown in Figure 3, the first phase is prototype development to
control various risks. This is followed by an iterative development
cycle.
 P
rototype Model of Software Development

In the prototype model, prototyping starts with initial

requirements gathering phase. Quick design is carried out and a
prototype is built. The developed prototype is submitted to the
customer for his assessment.
Based on the customer feedback, the requirements are refined and
the prototype is suitably modified. This cycle of obtaining customer
feedback and modifying the prototype continues until the customer
approves the prototype. Once the customer approves the prototype,
the actual system is developed using the iterative waterfall
approach.

Need for a Prototype Model in Software

Development
 To illustrate the input data formats, messages, reports, and
interactive dialogues to the customer.
 To gain a better understanding of the customer’s needs: how the
screen might look like, how the user interface would behave, and
how the system would produce the output?
 To examine the technical issues associated with product
development.
 It is not possible to get the perfect product in the first attempt.
Many engineers and researchers advocate that if you want to
develop a good product you must plan to throw away the first
version. The experience acquired in developing the prototype can
be used to develop the final product.

Advantages of Prototype
Model
 Demo working model: Customer get demo working model of
actual product which help them to give a better understanding
and attain a high level of satisfaction.
 New requirement: Based on the customer feedback, the
requirements are redefined and the prototype is suitably modified
till final approval.
 Missing functionality: can be easily established.
 Easy error detection: It saves time and cost in developing the
prototype and enhance the quality of the final product.
 Flexibility: in the development phase.

Disadvantages of Prototype
Model
 Time-consuming: As the prototype is being modified time to
time according to customer requirement which usually increases
the time of completion of the product.
 Complexity: Change in the requirement usually expand the
scope of the product beyond its original plan and thus increase
the complexity.
 Poor Documentation: Continous changing of requirement can
lead to poor documentation.
 Unpredictability of no of iteration: It is difficult to determine
the no of iteration required before the prototype is finally
accepted by the customer.
 Confusion: Customer can confuse between the actual product
and prototype.

What is Evolutionary Model?

Evolutionary model is also referred to as the successive
versions model and sometimes as the incremental model. In
Evolutionary model, the software requirement is first broken down
into several modules (or functional units) that can be incrementally
constructed and delivered (see Figure 5).
The development first develops the core modules of the system.
The core modules are those that do not need services from the
other modules. The initial product skeleton is refined into increasing
levels of capability by adding new functionalities in successive
versions. Each evolutionary model may be developed using an
iterative waterfall model of development.

Evolutionary Development of a Software Product

The evolutionary model is shown in Figure 6. Each successive

version/model of the product is a fully functioning software capable
of performing more work than the previous versions/model.
The evolutionary model is normally useful for very large products,
where it is easier to find modules for incremental implementation.
Evolutionary Model of Software Development

Often, evolutionary model is used when the customer prefers to

receive the product in increments so that he can start using the
different features as and when they are developed rather than
waiting all the time for the full product to be developed and
delivered.

Advantages of Evolutionary
Model
 Large project: Evolutionary model is normally useful for very
large products.

 User gets a chance to experiment with a partially developed

software much before the complete version of the system is
released.

 Evolutionary model helps to accurately elicit user

requirements during the delivery of different versions of the
software.

 The core modules get tested thoroughly, thereby reducing the

chances of errors in the core modules of the final products.

 Evolutionary model avoids the need to commit large

resources in one go for development of the system.

Disadvantages of
Evolutionary Model
 Difficult to divide the problem into several versions that
would be acceptable to the customer and which can be
incrementally implemented and delivered.

What is Spiral Model?

The spiral model is a software process model that couples the
iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model. Barry Boehm mentioned the
Spiral model in this paper (1986).
The spiral model is also known as meta-model since it
encompasses all other life cycle models.
The diagrammatic representation of this model appears like a spiral
with many loops, as shown in Figure 4. The exact number of loops in
the spiral model is not fixed.
Each loop of the spiral model represents a phase of the
software process.

For example, the innermost loop might be concerned with the

feasibility study. The next loop with requirements specification, the
next loop with design, and so on. Each phase in this model is split
into three to six tracks (or quadrants). Figure 4 depicts a spiral
model that contains four tracks.

Spiral
Model Quadrant (Phases)
The following activities are carried out during each phase of a spiral
model.

1. First Quadrant (Objective Setting)

– Identify the objectives of the phase.
– Examine the risks associated with these objectives.

2. Second Quadrant (Risk Assessment and Reduction)

– A detailed analysis is carried out for each identified project risk.
 – Steps are taken to reduce the risks.

3. Third Quadrant (Development and Validation)

– Develop and validate the next level of the product after
resolving the identified risks.

4. Fourth Quadrant (Review and Planning)

– Review the results achieved so far with the customer and plan
the next iteration.
– Progressively more complete version of the software gets built
with each iteration around the spiral.

When to use Spiral Model

 The spiral model is suitable for the development of technically
challenging software products that are prone to several kinds of
risks.
 When there is complexity in requirements and need frequent
evaluation.

Advantages of Spiral Model

 Suitable for large projects: It is suggested to use the spiral
model for large and complex projects.
 Rish handling capability: Project which is complex and large
are prone to unknown risk and error. So the spiral model is
suitable under these high-risk environments.
 New requirement: Based on the feedback, the requirements are
redefined.

Disadvantages of Spiral
Model
 Complex: It is one of the most complex SDLC models.
 Documentation: is more as it has many loop iteration.
 Expensive: It is not suitable for small projects.
 Management: is more complex.

Different life cycle model

SDLC Models or Software Development Life Cycle (SDLC) models are
frameworks that guide the development process of software applications
from initiation to deployment. Various SDLC models in software
engineering exist, each with its approach to the phases of development.
 he V-models in SDLC emerge as a compelling alternative, offering a
structured and systematic approach. This blog post aims to unravel the
intricacies of the V-models SDLC, shedding light on its principles,
advantages, and best practices.
The V-Models, also known as the Verification and Validation models, is an
extension of the traditional Waterfall models. It introduces a parallel testing
phase for each corresponding development stage, forming a V-shaped
diagram.

Key Principles of V-Model

 1. Parallel Development and Testing:
Development and testing are planned together. Each development phase has a
corresponding testing phase.
2. Verification and Validation:
Verification checks whether the product is built correctly, while validation checks whether
the right product is built.
3. Traceability:
Each development phase is directly linked with its corresponding testing phase, ensuring
proper documentation.
4. Early Defect Detection:
Testing starts early, helping to identify and fix defects quickly.

Advantages of V-Model

1. Clear Design and Planning:

Provides a structured approach with clearly defined tasks and stages.
2. Early Issue Identification:
Early testing helps find and fix problems before they become serious.
3. Traceability and Documentation:
Maintains a clear connection between requirements, development, and testing.
4. Predictability and Control:
The systematic process makes project progress easier to predict and manage.

5. Agile SDLC Models

Agile is not a specific methodology but rather a set of principles and values
outlined in the Agile Manifesto. The Agile Manifesto prioritizes individuals
and interactions, working solutions, customer collaboration, and responding
to change over rigid processes and documentation. Several Agile
methodologies, including Scrum, Kanban, and Extreme Programming (XP),
have been developed to implement these principles.
Key Principles of Agile SDLC – Short Notes
1. Iterative and Incremental Development:
Software is developed in small cycles, with each cycle producing a working part of the
software.
2. Customer Collaboration:
Customers regularly give feedback throughout the development process.
3. Adaptability to Change:
Agile easily accepts changes in requirements, even during development.
4. Cross-Functional Teams:
Team members with different skills work together to complete the project.

Advantages of Agile SDLC – Short Notes

1. Flexibility and Adaptability:

Quickly adapts to changing requirements.
2. Customer Satisfaction:
Continuous customer involvement ensures the product meets their needs.
3. Early and Predictable Delivery:
Working software is delivered regularly in small increments.
4. Improved Quality:
Continuous testing helps find and fix bugs early.

6. DevOps SDLC Models

DevOps, comprised of "development" and "operations," represents a
cultural and organizational shift in how software is developed, tested, and
deployed. It emphasizes collaboration and communication between
software developers and IT operations, promoting automation and
continuous delivery. DevOps is not just a set of practices; it is a cultural
mindset that seeks to improve collaboration and efficiency across the entire
software development lifecycle.
Key Principles of DevOps SDLC – Short Notes
1. Collaboration:
Development and operations teams work together closely to achieve common goals.
2. Automation:
Repetitive tasks like testing and deployment are automated to save time and reduce errors.
3. Continuous Integration and Delivery (CI/CD):
Code changes are regularly integrated, tested, and made ready for deployment.
4. Infrastructure as Code (IaC):
Infrastructure is managed using code and automation, making deployments consistent and
repeatable.

Advantages of DevOps SDLC – Short Notes

1. Increased Collaboration:
Improves communication and teamwork between development and operations teams.
2. Faster Time-to-Market:
Automation and continuous delivery help release software faster.
3. Improved Reliability:
Automated testing and deployment help detect and fix problems early.
4. Scalability and Flexibility:
Infrastructure and applications can be quickly scaled according to demand.

7. Rapid Application Development (RAD) SDLC

Models
Rapid Application Development is an iterative and incremental model that
prioritizes quick development and iteration cycles. It places a strong
emphasis on user feedback and involvement throughout the development
process. RAD aims to deliver functional prototypes rapidly, allowing
stakeholders to provide feedback and guide ongoing development.

Key Principles of RAD SDLC – Short Notes

1. Iterative Development:
The project is developed in small parts, with each iteration producing a working prototype.
2. User Involvement:
Users actively participate and provide feedback throughout development.
3. Prototyping:
Quick prototypes are created and improved based on user feedback.
4. Adaptability to Changes:
RAD allows requirements to be changed easily during development.

Advantages of RAD SDLC – Short Notes

1. Speed and Time-to-Market:

Quick development and prototyping help deliver software faster.
2. User Satisfaction:
Continuous user feedback helps create software that meets user needs.
3. Adaptability to Changes:
Changes and improvements can be added easily, even later in development.
4. Cost-Effective:
Fast development and fewer lengthy planning stages can reduce costs.

8. Incremental SDLC Models

The Incremental model is an iterative software development process where
the product is designed, implemented, and tested incrementally (a little
more is added each time) until the product is finished. Each iteration
represents a small part of the overall system and includes both new
features and enhancements to existing ones.

Key Principles of Incremental SDLC – Short Notes

1. Incremental Development:
The system is developed in small parts called increments.
2. Partial System Functionality:
Each increment provides a working part of the system, allowing early feedback.
3. Integration of Increments:
New increments are integrated with the existing system to gradually build the complete
system.
4. Parallel Development:
Different teams can work on different increments at the same time.

Advantages of Incremental SDLC – Short Notes

1. Early and Tangible Results:

Working parts of the system are available early.
2. Flexibility and Adaptability:
Changes can be easily added in each increment.
3. Risk Management:
Smaller increments make it easier to identify and fix problems early.
4. Faster Time-to-Market:
Parts of the software can be delivered quickly.

Comparison between various SDLC Models

Below is a table comparing several Software Development Life Cycle
(SDLC) models, including Waterfall, Iterative, Spiral, Agile, V-Models, and
 Incremental. Please note that this is a high-level comparison, and the
suitability of a particular model depends on the specific requirements and
nature of the project.

Increme
Aspect Waterfall Iterative Spiral Agile V-Models ntal

Development Sequenti
Iterative Iterative Iterative Iterative Iterative
Approach al

Divided
Planning, into
Planning, Planning, Planning,
Design, incremen
Risk Sprint, Design,
Coding, ts, each
Analysis, Review, Implementat
Linear Testing, with
Engineerin Retrospecti ion, Testing,
Evaluation Planning,
g, Testing ve (Iterative Deployment
(Repeated Impleme
(Cyclical) Cycles) (Parallel)
Iteratively) ntation,
Phases Testing

Flexibility Low High High High Moderate High

Risk Proactive
Proactive Continuou Continuous
Late manageme risk
risk s risk risk
mitigation nt aligned manage
manageme assessme assessment
, Limited with ment,
nt, nt, ,
adaptabili phases, Adaptabil
Adaptability Proactive Adaptability
Risk ty Moderate ity to
to changes mitigation to changes
Management adaptability changes

Time-to-
Longer Faster Variable Faster Moderate Faster
Market

User Continuo
Limited Continuous Periodic Continuous Periodic
Involvement us

Continuo
us
After Continuous Integrated After
Continuous througho
Impleme throughout throughout Implementat
and c ut
ntation iterations the spiral ion
incremen
Testing ts

Adaptability Low High High High Moderate High

 Increme
Aspect Waterfall Iterative Spiral Agile V-Models ntal

Linear
Easier to Adaptive
approach Cyclical Adaptive Traceability
manage, approach
, Limited approach, approach to helps
Adaptability to
Complexity adaptabili Risk-d changes manage c
to changes changes
Management ty

2.1. SOFTWARE REQUIREMENTS:

 The process of finding out, analyzing, documenting
and checking these services and constraints is called
Requirements engineering (RE).

Requirements Readers / Users

User Requirements • Client Managers
• System End-Users
• Client Engineers
• Contractor Managers
• System Architects
System • System End-Users
Requirements • Client Engineers
• System Architects
• Software Developers

Types of Software Requirements

User requirements mean the high-level abstract requirements, while system requirements
mean the detailed description of what the system should do.

1. User Requirements

User requirements are statements, in natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must operate.

2. System Requirements

System requirements are more detailed descriptions of the software system's functions,
services, and operational constraints. The system requirements document (sometimes called a
functional specification) should define exactly what is to be implemented. It may be part of
the contract between the system buyer and the software developers.
 Classification of Software System Requirements

Software system requirements are classified as functional requirements, non-functional

requirements, and domain requirements.

1. Functional Requirements

These are statements of the services the system should provide, how the system should react
to particular inputs, and how the system should behave in particular situations. In some cases,
functional requirements may also explicitly state what the system should not do.

2. Non-Functional Requirements

These are constraints on the services or functions offered by the system. They include timing
constraints, constraints on the development process, and standards. Non-functional
requirements often apply to the system as a whole.

3. Domain Requirements

These are requirements that come from the application domain of the system and reflect the
characteristics and constraints of that domain. They may be functional or non-functional
requirements.

Requirements Gathering


Requirements gathering is the process of collecting and understanding
what a software system should do by working closely with stakeholders. It
helps define features, expectations, and constraints so the final product
aligns with business goals and user needs.
 Clarifies project objectives and expectations.
 Identifies stakeholder and user requirements.
 Defines system scope and boundaries.
 Reduces misunderstandings and rework.
 Helps in accurate planning and estimation.
 Improves overall software quality.
Main Requirements Gathering Subprocesses
Requirements gathering is a critical phase in the software development
lifecycle, and it involves several subprocesses to ensure a comprehensive
understanding of the project's needs. The main sub-processes include:
Stakeholder Identification:

 Objective: Identify all stakeholders who will be affected by the system,

directly or indirectly.
 Process: Conduct interviews, surveys, or workshops to determine the
key individuals or groups involved.

Stakeholder Analysis:

 Objective: Understand the needs, expectations, and influence of each

stakeholder.
 Process: Analyze stakeholder inputs to prioritize requirements and
manage conflicting interests.
Problem Definition:
 Objective: Clearly define the problems or opportunities that the
software system aims to address.
 Process: Engage stakeholders in discussions to uncover and
articulate the core problems or opportunities.

Requirements Extraction:

 Objective: Gather detailed requirements by interacting with

stakeholders.
 Process: Employ techniques such as interviews, surveys,
observations, or brainstorming sessions to extract requirements.

Requirements Documentation:

 Objective: Document gathered requirements in a structured format.

 Process: Create requirements documents, use cases, user stories, or
prototypes to capture and communicate requirements effectively.

Validation and Verification:

 Objective: Ensure that gathered requirements are accurate, complete,

and consistent.
 Process: Conduct reviews, walkthroughs, or use validation tools to
verify that the requirements meet the defined criteria.
Processes of Requirements Gathering in Software
Development
There are 6 steps crucial for requirement gathering processes:

[Step 1]- Assigning roles:

 The first step is to identify and engage with all relevant stakeholders.
Stakeholders can include end-users, clients, project managers, subject
matter experts, and anyone else who has a vested interest in the
software project. Understanding their perspectives is essential for
capturing diverse requirements.
[Step 2]- Define Project Scope:
 Clearly define the scope of the project by outlining its objectives,
boundaries, and limitations. This step helps in establishing a common
understanding of what the software is expected to achieve and what
functionalities it should include.
[Step 3]- Conduct Stakeholder Interviews:
 Schedule interviews with key stakeholders to gather information about
their needs, preferences, and expectations. Through open-ended
questions and discussions, aim to uncover both explicit and implicit
requirements. These interviews provide valuable insights that
contribute to a more holistic understanding of the project.
[Step 4]- Document Requirements:
 Systematically document the gathered requirements. This
documentation can take various forms, such as user stories, use
cases, or formal specifications. Clearly articulate functional
requirements (what the system should do) and non-functional
requirements (qualities the system should have, such as performance
or security).
[Step 5]- Verify and Validate Requirements:
 Once the requirements are documented, it's crucial to verify and
validate them. Verification ensures that the requirements align with the
stakeholders' intentions, while validation ensures that the documented
requirements will meet the project's goals. This step often involves
feedback loops and discussions with stakeholders to refine and clarify
requirements.
[Step 6]- Prioritize Requirements:
 Prioritize the requirements based on their importance to the project
goals and constraints. This step helps in creating a roadmap for
development, guiding the team on which features to prioritize.
Prioritization is essential, especially when resources and time are
limited.
Requirement Gathering Techniques:
Effective requirement gathering is essential for the success of a software
development project. Various techniques are employed to collect,
analyze, and document requirements.

Here are some commonly used requirement gathering techniques:

1. Interviews – One-on-one or group discussions with stakeholders to
capture needs, expectations, and concerns.
2. Surveys & Questionnaires – Collect large-scale feedback from
diverse stakeholders, useful in big projects.
3. Workshops – Collaborative sessions to define requirements, resolve
conflicts, and generate ideas.
4. Observation – Watching end-users in their environment to identify
workflows, pain points, and hidden needs.
5. Prototyping – Building mockups or prototypes for early feedback and
refining requirements.
6. Use Cases & Scenarios – Describing system interactions in real
situations to identify functional needs.
7. Document Analysis – Reviewing existing manuals, reports, and forms
to extract process insights.

Benefits of Requirements Gathering – Short Notes

1. Cost Reduction:
Reduces costly changes and rework by clearly defining requirements.
2. Customer Satisfaction:
Ensures the software meets customer and stakeholder expectations.
 3. Improved Communication:
Reduces misunderstandings and improves communication among stakeholders.
4. Efficient Resource Utilization:
Helps properly allocate time, people, and technology.
5. Enhanced Quality:
Provides a strong foundation for testing and quality assurance.
6. Risk Management:
Identifies potential risks early and helps reduce them.
7. Accurate Planning:
Helps prepare realistic schedules, milestones, and deliverables.

Software Requirement Specification (SRS



The SRS document is reviewed by the testing person or a group of
persons by using any verification method (like peer reviews,
walkthroughs, inspections, etc.). We may use inspections due to their
effectiveness and capability to produce good results. We may conduct
reviews twice or even more often. Every review will improve the quality of
the document but may consume resources and increase the cost of
the software development.
A checklist is a popular verification tool that consists of a list of critical
information content that a deliverable should contain. A checklist may also
look for duplicate information, missing information, unclear information,
wrong information, etc. Checklists are used during reviewing and may
make reviews more structured and effective.

Elements of an SRS document checklist

A Software Requirement Specification (SRS) document is a vital
component of software development. It outlines the functional and non-
functional requirements of the software and serves as a reference for all
stakeholders involved in the project. However, creating a comprehensive
and accurate SRS document can be a daunting task. That's where an SRS
document checklist comes in handy.
Elements of an SRS document checklist
 Purpose and Scope: The purpose and scope section of an SRS
document should provide a high-level overview of the software, its
intended audience, and the problem it solves. This section should also
outline any constraints, assumptions, and dependencies that may affect
the software's development.
 Functional Requirements: Functional requirements describe what the
software should do. These requirements should be specific,
measurable, and testable. This section should include details about the
software's features, user interface, and data processing.
 Non-functional Requirements: Non-functional requirements describe
how the software should perform. These requirements should be
measurable and testable. This section should include details about the
software's performance, security, reliability, and usability.
 System Architecture: The system architecture section should describe
the high-level design of the software. This section should include details
about the software's components, interfaces, and data flow.
 Data Management: The data management section should describe how
the software will handle data. This section should include details about
the software's database, data storage, and data backup and recovery
processes.
 User Documentation: The user documentation section should describe
how users will interact with the software. This section should include
details about the software's user interface, user manuals, and help
documents.
 Testing Requirements
The testing requirements section should describe how the software will
 be tested. This section should include details about the software's test
cases, test environment, and test data.
 Acceptance Criteria: The acceptance criteria section should describe
how the software will be accepted by the stakeholders. This section
should include details about the software's acceptance tests, validation
criteria, and sign-off procedures.
 Project Timeline: The project timeline section should provide a timeline
for the software's development. This section should include details
about the software's milestones, deliverables, and deadlines.
 Stakeholder List: The stakeholder list section should identify all the
stakeholders involved in the project. This section should include details
about each stakeholder's role, responsibilities, and contact information.

SRS document checklist

Characteristics of a Good SRS – Short Notes

1. Correctness:
Every requirement should correctly represent the customer's needs and include necessary
safety and security requirements.
 2. Ambiguity:
Each requirement should have only one clear meaning. Avoid unclear or confusing words.
3. Completeness:
The SRS should contain all functional and non-functional requirements, including possible
errors and exceptional conditions.
4. Consistency:
Requirements should not conflict with each other. Names, terms, equations, and
abbreviations should be used consistently.
5. Verifiability:
Every requirement should be measurable and testable. Avoid vague terms like good,
excellent, usually, and well.
6. Traceability:
The source of every requirement should be identified so that it can be tracked during
development.
7. Feasibility:
Requirements should be technically and practically possible to implement with available
resources.

Advantages of SRS – Short Notes

1. Clarity: Clearly describes requirements and reduces confusion.
2. Consistency: Provides a structured and consistent requirements document.
3. Traceability: Links requirements with the final software product.
4. Validation: Helps check whether the software meets the requirements.

Disadvantages of SRS – Short Notes

1. Time-Consuming: Preparing an SRS can take a lot of time.
2. Limited Flexibility: Changes to the SRS can be difficult after creation.
3. Limited User Involvement: May not fully reflect user needs if users are not involved.
4. Misinterpretation: Some requirements may still be misunderstood, causing errors.