Nature Of a Software:-

Software is a set of instructions that tells a computer how to perform

a task. It is intangible, meaning that you cannot touch or see it, but
it is essential for the operation of computers and other electronic
devices. Software is also complex, as it can be made up of millions
of lines of code. Software development is the process of creating
software, and it can be a very challenging task.

Types of Software

There are two main types of software:

• System software: System software is software that provides

the basic functionality of a computer system. This includes the
operating system, which manages the hardware and software
resources of the computer, and device drivers, which allow the
computer to communicate with hardware devices.

• Application software: Application software is software that is

designed to perform a speci c task. This includes word
processing software, web browsers, and games.
fi
 Characteristics of Software

Software has several characteristics that make it unique from other

manufactured products:

• Intangibility: Software is intangible, meaning that you cannot

touch or see it. This makes it dif cult to measure and test, and
it can also make it dif cult to protect from theft or piracy.
• Complexity: Software can be very complex, as it can be made
up of millions of lines of code. This complexity can make it
dif cult to develop, maintain, and debug.
• Changeability: Software is constantly changing, as new
features are added and bugs are xed. This can make it
dif cult to keep up with the latest versions of software.
• Invisibility: Software is invisible, meaning that you cannot see
the code that makes it up. This can make it dif cult to
understand how software works and how to troubleshoot
problems.
fi
fi
fi
fi
fi
fi
 Examples of Software

Here are some examples of software:

• Operating systems: Windows, macOS, Linux

• Web browsers: Chrome, Firefox, Safari
• Word processing software: Microsoft Word, Google Docs,
LibreOf ce Writer
• Spreadsheets: Microsoft Excel, Google Sheets, LibreOf ce
Calc
• Presentation software: Microsoft PowerPoint, Google Slides,
LibreOf ce Impress
• Graphics editing software: Adobe Photoshop, GIMP, Inkscape
• Video editing software: Adobe Premiere Pro, Final Cut Pro,
DaVinci Resolve
• Audio editing software: Adobe Audition, Audacity, GarageBand
• Games: Minecraft, Grand Theft Auto V, Fortnite
Resources

Here are some resources that you may nd helpful:

• Software Engineering Body of Knowledge: https://

sebokwiki.org/
• Free Software Foundation: https://www.fsf.org/
• Open Source Initiative: https://opensource.org/
• Software Engineering Institute: https://www.sei.cmu.edu/
fi
fi
fi
fi
Unique Nature of Web-apps:
Webapps

Web applications, also known as web apps, are software

applications that are delivered over the internet through a web
browser. They are typically written in languages such as HTML,
CSS, and JavaScript, and they can be accessed from any device
with an internet connection.

Unique Nature of Webapps

Webapps have several unique characteristics that make them

different from traditional desktop applications. These characteristics
include:

Platform independence: Webapps can be accessed from any

device with an internet connection, regardless of the operating
system or hardware. This is because webapps are delivered
through a web browser, which is a standardized piece of software
that is pre-installed on most devices.

Ubiquity: Webapps are ubiquitous, meaning that they are available

anytime, anywhere. This is because webapps are stored on web
servers, which are computers that are connected to the internet. As
long as you have an internet connection, you can access any
webapp that you have permission to use.

Scalability: Webapps can be easily scaled to accommodate a large

number of users. This is because webapps are stateless, meaning
that they do not store user data on the client-side. User data is
stored on the server-side, and the server can be easily scaled by
adding more servers.

Low cost of development: Webapps are relatively inexpensive to

develop and maintain. This is because there is a large pool of
developers who are familiar with web development technologies,
and there are many open-source tools and frameworks that can be
used to develop webapps.

Ease of deployment: Webapps are easy to deploy and update.

This is because they do not require any installation on the client-
side. Webapps are simply deployed to a web server, and users can
access them immediately.

Examples of Webapps

There are many different types of webapps, but some of the most
popular examples include:

• Search engines: Google Search, Bing, Yahoo Search

• Social media: Facebook, Twitter, Instagram

• Email: Gmail, Outlook, Yahoo Mail

• E-commerce: Amazon, eBay, Alibaba

 • Online banking: Chase Bank, Bank of America, Wells Fargo

• Online productivity suites: Google Workspace, Microsoft Of ce

365, Zoho Workplace

Resources

Here are some resources that you may nd helpful:

• W3C: https://www.w3.org/: https://www.w3.org/

• MDN Web Docs: https://developer.mozilla.org/en-US/docs/
Web: https://developer.mozilla.org/en-US/docs/Web
• Web Application Security Consortium: https://www.wasc.org/:
https://www.wasc.org/
fi
fi
 Software Engineering :
Software engineering is the application of engineering principles to
the development of software. It is a broad eld that encompasses
everything from the initial conception of a software system to its
nal deployment and maintenance. Software engineers use a
variety of tools and techniques to develop software that is reliable,
ef cient, and maintainable.

Goals of Software Engineering

The primary goals of software engineering are to:

• Develop software that meets the needs of users.

• Develop software that is reliable and free of defects.
• Develop software that is ef cient and uses resources
effectively.
• Develop software that is maintainable and easy to modify.
• Develop software that is scalable and can grow with the
needs of the organization.
Phases of Software Engineering

The software engineering process is typically divided into the

following phases:

• Requirements gathering: This phase involves identifying the

needs of the users and stakeholders.
• Design: This phase involves creating a plan for how the
software will be developed.
• Implementation: This phase involves writing the code for the
software.
• Testing: This phase involves testing the software to ensure
that it meets the requirements and is free of defects.
fi
fi
fi
fi
 • Deployment: This phase involves releasing the software to
the users.
• Maintenance: This phase involves xing bugs and making
enhancements to the software.
Software Engineering Tools and Techniques

Software engineers use a variety of tools and techniques to develop

software. Some of the most common tools and techniques include:

• Programming languages: Programming languages are used

to write the code for software. Some of the most popular
programming languages include Java, Python, and C++.
• Software development methodologies: Software
development methodologies provide a framework for
developing software. Some of the most popular software
development methodologies include Agile, Waterfall, and
Scrum.
• Version control systems: Version control systems are used
to track changes to code. Some of the most popular version
control systems include Git and Subversion.
• Testing tools: Testing tools are used to test software for
defects. Some of the most popular testing tools include JUnit
and Selenium.
Examples of Software Engineering

Here are some examples of software engineering projects:

• Developing a new website for a company.

• Creating a mobile app for a new product.
• Building a new enterprise resource planning (ERP) system for
a company.
• Developing a new operating system.
fi
Resources

Here are some resources that you may nd helpful:

• Institute of Electrical and Electronics Engineers (IEEE)

Computer Society: https://www.computer.org/: https://
www.computer.org/
• Association for Computing Machinery (ACM): https://
www.acm.org/: https://www.acm.org/
• Software Engineering Institute (SEI) at Carnegie Mellon
University: https://www.sei.cmu.edu/: https://www.sei.cmu.edu/

Software Engineering Process:

The software engineering process is a set of steps that are used to
develop software. It is a framework that helps software engineers to
plan, design, develop, test, and deploy software. The software
engineering process can be divided into several phases, each of
which has a speci c set of goals and activities.

Phases of the Software Engineering Process

The software engineering process is typically divided into the

following phases:

• 1. Requirements Gathering:

◦ The goal of the requirements gathering phase is to

identify the needs of the users and stakeholders. This
phase involves interviewing users, studying existing
documentation, and analyzing business processes.
◦ Example: A team of software engineers is developing an
e-commerce website for a new clothing company. They
interview the company's CEO, marketing director, and
sales team to understand the company's goals and the
needs of its customers.
fi
fi
• 2. Design:

◦ The goal of the design phase is to create a plan for how

the software will be developed. This phase involves
creating detailed speci cations, designing the user
interface, and designing the system architecture.
◦ Example: The team of software engineers creates a
detailed speci cation that outlines the features of the e-
commerce website. They also design a user interface that
is easy to use and visually appealing.
• 3. Implementation:

◦ The goal of the implementation phase is to write the code

for the software. This phase involves writing code in the
chosen programming language, integrating with third-
party systems, and testing the code as it is written.
◦ Example: The team of software engineers writes the code
for the e-commerce website. They use Java as the
programming language and integrate with a payment
gateway and a shipping carrier.
• 4. Testing:

◦ The goal of the testing phase is to test the software to

ensure that it meets the requirements and is free of
defects. This phase involves unit testing, integration
testing, and system testing.
◦ Example: The team of software engineers tests the e-
commerce website using automated and manual testing
techniques. They identify and x several bugs before the
website is released to the public.
• 5. Deployment:

◦ The goal of the deployment phase is to release the

software to the users. This phase involves installing the
fi
fi
fi
 software on production servers, con guring the software,
and training the users.
◦ Example: The team of software engineers deploys the e-
commerce website to a production environment. They
con gure the website to work with the company's existing
systems and train the company's employees on how to
use the website.
• 6. Maintenance:

◦ The goal of the maintenance phase is to x bugs, make

enhancements, and keep the software up to date. This
phase involves monitoring the software for problems,
xing bugs that are reported, and making enhancements
to the software based on user feedback.
◦ Example: The team of software engineers monitors the e-
commerce website for problems and xes any bugs that
are reported. They also add new features to the website,
such as a wish list and a gift wrapping service.
Bene ts of Following the Software Engineering Process

Following the software engineering process can help to:

• Reduce the risk of project failure.

• Improve the quality of the software.
• Make the software more maintainable.
• Reduce the cost of developing software.
fi
fi
fi
fi
fi
fi
 Software Engineering Practice
Software engineering practices are a set of guidelines and
principles that are used to develop software in a consistent, reliable,
and ef cient manner. These practices are based on the knowledge
and experience of software engineers, and they are constantly
being re ned and improved as new technologies and techniques
emerge.

Bene ts of following software engineering practices

There are many bene ts to following software engineering

practices. These bene ts include:

• Improved software quality: Software engineering practices help

to ensure that software is well-designed, coded, and tested,
which helps to reduce the number of bugs and defects.
• Increased software development productivity: Software
engineering practices can help to improve the ef ciency of
software development by providing a framework for planning,
designing, and implementing software.
• Reduced software maintenance costs: Software engineering
practices can help to make software more maintainable, which
can reduce the cost of xing bugs and making changes to
software over time.
• Increased software reliability: Software engineering practices
can help to improve the reliability of software, which can make
it more resistant to failures and outages.
fi
fi
fi
fi
fi
fi
fi
Here are some examples of software engineering practices:

• Version control: Version control is a system for tracking

changes to code and other les. This practice helps to ensure
that changes to code are made in a consistent and controlled
manner, and it also makes it possible to revert to previous
versions of code if necessary.

• Code reviews: Code reviews are a process in which code is

reviewed by other software engineers to identify potential
problems. This practice helps to improve the quality of code by
catching bugs and other defects early on.

• Unit testing: Unit testing is a process of testing small units of

code to ensure that they work as expected. This practice helps
to identify and x bugs early on in the development process.

• Integration testing: Integration testing is a process of testing

how different units of code work together. This practice helps
to identify and x problems that arise when different parts of
the software interact.

• System testing: System testing is a process of testing the

entire software system to ensure that it meets all of the
requirements. This practice helps to identify and x problems
that may not have been caught by unit or integration testing.
fi
fi
fi
fi
Software Myths
Software myths are widely held misconceptions or beliefs about
software development that are often untrue or misleading. These
myths can lead to unrealistic expectations, awed project
management approaches, and ultimately, software project failures.

Common Software Myths:

Myth 1: Once the code is written, the project is nished.

• Reality: Software development is an iterative process that

involves continuous improvement and adaptation. Even after
the initial release, software requires maintenance, updates,
and bug xes to ensure its continued effectiveness and
security.
Myth 2: Adding more programmers will speed up the project.

• Reality: While adding more programmers can increase the

overall effort invested in a project, it doesn't necessarily
translate to faster completion. Software development involves
complex interactions and dependencies, and adding more
people without proper coordination can lead to communication
overhead, duplication of effort, and increased delays.
Myth 3: Detailed speci cations upfront will guarantee project
success.

• Reality: While speci cations provide a general outline of the

software's requirements, they are not set in stone. As the
development process unfolds, new insights, changing
requirements, and unforeseen challenges may arise,
necessitating adjustments to the initial speci cations.
fi
fi
fi
fl
fi
fi
Myth 4: Customers know exactly what they want.

• Reality: Customer needs and expectations often evolve

throughout the development process. Gathering feedback and
iterating based on user input is crucial to ensure the nal
product aligns with real-world needs and expectations.
Myth 5: Testing can catch all defects.

• Reality: No amount of testing can guarantee completely bug-

free software. Testing is an ongoing process that helps identify
and eliminate defects, but it's impossible to predict every
possible scenario or user interaction.
Myth 6: Agile development means no planning.

• Reality: While agile emphasizes exibility and adaptability, it

still involves planning and prioritization. Agile teams break
down large projects into smaller, manageable iterations,
allowing for continuous feedback and adjustments as the
project progresses.
Myth 7: Open-source software is less secure than proprietary
software.

• Reality: Open-source software often bene ts from the scrutiny

and contributions of a large community of developers, which
can lead to higher levels of security and transparency
compared to proprietary software that may have fewer eyes on
its codebase.
Myth 8: Documentation is a waste of time.

• Reality: Clear and comprehensive documentation is essential

for long-term maintenance, future enhancements, and
onboarding new developers. Well-documented code and
processes save time and effort in the long run.
fl
fi
fi
Myth 9: Software development is a linear process.

• Reality: Software development is an iterative and non-linear

process, with frequent feedback loops, adjustments, and
refactoring. Embracing this nonlinearity allows for continuous
improvement and adaptation to changing requirements.
Myth 10: The latest technology is always the best choice.

• Reality: Choosing the latest technology for the sake of novelty

may not always be the best approach. The most suitable
technology for a project depends on speci c requirements,
existing infrastructure, and the expertise of the development
team.
Resources

Here are some resources that you may nd helpful in learning more
about software myths:

• Software Engineering Myths: https://www.sitejabber.com/

reviews/datatrained.com

• 20 Common Software Myths Debunked: https://

easternpeak.com/blog/fact-or- ction-debunking-the-5-most-
popular-software-development-myths/

• Software Myths and Fallacies: https://cacm.acm.org/

magazines/2019/8/238333-dispelling-common-myths-about-
acm-awards-and-honors/fulltext?mobile=true?mobile=false

• Software Development Myths and Misconceptions: https://

www.geeksforgeeks.org/brief-description-about-software-
myths/

• 10 Common Software Development Myths: https://

sdacademy.dev/10-myths-about-software-development/
fi
fi
fi
Generic Process Model
The generic process model is a framework that describes the
general phases involved in developing software. It provides a high-
level overview of the process and can be adapted to t the speci c
needs of a particular project.

Phases of the Generic Process Model

1. Planning and Requirements Gathering:

◦ Goal: De ne the project's objectives, scope, and

limitations, and gather requirements from stakeholders.

◦ Example: A team of software engineers is developing a

new e-commerce website for a clothing company. They
interview the company's CEO, marketing director, and
sales team to understand the company's goals and the
needs of its customers.

2. Design:

◦ Goal: Create detailed speci cations, design the user

interface, and design the system architecture.

◦ Example: The team of software engineers creates a

detailed speci cation that outlines the features of the e-
commerce website. They also design a user interface that
is easy to use and visually appealing.

3. Implementation:

◦ Goal: Write the code for the software.

◦ Example: The team of software engineers writes the code

for the e-commerce website. They use Java as the
fi
fi
fi
fi
fi
 programming language and integrate with a payment
gateway and a shipping carrier.

4. Testing:

◦ Goal: Test the software to ensure that it meets the

requirements and is free of defects.

◦ Example: The team of software engineers tests the e-

commerce website using automated and manual testing
techniques. They identify and x several bugs before the
website is released to the public.

5. Deployment:

◦ Goal: Release the software to the users.

◦ Example: The team of software engineers deploys the e-

commerce website to a production environment. They
con gure the website to work with the company's existing
systems and train the company's employees on how to
use the website.

6. Maintenance:

◦ Goal: Fix bugs, make enhancements, and keep the

software up to date.

◦ Example: The team of software engineers monitors the e-

commerce website for problems and xes any bugs that
are reported. They also add new features to the website,
such as a wish list and a gift wrapping service.
fi
fi
fi
 Bene ts of the Generic Process Model

The generic process model provides several bene ts, including:

• Flexibility: It can be adapted to t the speci c needs of a

project, regardless of its size or complexity.

• Structure: It provides a structured approach to software

development, which can help to ensure that projects are
completed on time and within budget.

• Communication: It facilitates communication among

stakeholders, which can help to avoid misunderstandings and
ensure that everyone is on the same page.

Example of Generic Process Model in Action

Consider a project to develop a new mobile application for a food

delivery service. The generic process model would be applied as
follows:

Planning and Requirements Gathering:

• Identify the project's objectives, such as increasing customer

satisfaction and expanding market reach.

• Gather requirements from stakeholders, including customers,

restaurant owners, and delivery personnel.

Design:

• Create detailed speci cations for the app's features,

functionality, and user interface.
fi
fi
fi
fi
fi
 • Design a user-friendly interface that is easy to navigate and
visually appealing.

• Design the system architecture to handle the expected volume

of orders, user traf c, and data processing.

Implementation:

• Write the code for the app using a suitable programming

language and development tools.

• Integrate with third-party services such as payment gateways

and mapping APIs.

• Conduct unit testing to ensure individual components of the

app function as intended.

Testing:

• Perform rigorous testing to identify and x bugs before release.

• Conduct user acceptance testing to gather feedback from

potential users and re ne the app's usability.

• Perform performance testing to ensure the app can handle

peak usage scenarios.

Deployment:

• Deploy the app to app stores for iOS and Android devices.

• Provide clear instructions and support materials for users to

install and use the app effectively.
fi
fi
fi
Maintenance:

• Monitor the app's performance and user feedback to identify

areas for improvement.

• Address bugs and security vulnerabilities promptly to maintain

user trust and app stability.

• Introduce new features and enhancements based on user

feedback and market trends.

The generic process model provides a valuable framework for

managing software development projects of varying sizes and
complexities.
 1. Software Engineering Process Assessment:

This involves a continuous cycle of evaluating the software

development process, identifying areas for improvement, and
implementing changes to enhance overall e ciency and quality.

1.1 De ne Objectives:

• Clearly outline the goals and objectives of the assessment.

• Examples: Improve code quality, reduce defects, enhance

team collaboration.

1.2 Choose Assessment Model:

• Select a suitable assessment model or framework (e.g.,

CMMI, ISO/IEC 15504).

• Examples: Capability Maturity Model Integration (CMMI)

levels.

1.3 Identify Assessment Criteria:

• De ne criteria to evaluate processes, resources, and

outcomes.

• Examples: Code review practices, testing processes,

documentation standards.

1.4 Collect Data:

• Gather data on current processes, project performance, and

team dynamics.

• Examples: Metrics on code churn, defect density, and

response time to issues.

1.5 Analyze Data:

fi
fi
ffi
 • Use statistical analysis and qualitative methods to interpret
collected data.

• Examples: Root cause analysis of recurring defects,

identifying bottlenecks.

2. Software Engineering Process Improvement:

2.1 Set Improvement Goals:

• Based on assessment results, establish speci c, measurable

improvement goals.

• Examples: Reduce defect rate by 20%, increase test

coverage to 90%.

2.2 Develop Improvement Plan:

• Create a detailed plan outlining steps to achieve improvement

goals.

• Examples: Introduce automated testing, conduct regular code

reviews.

2.3 Implement Changes:

• Integrate improvements into the existing software

development process.
fi
 • Examples: Adopting agile methodologies, introducing DevOps
practices.

2.4 Monitor Progress:

• Continuously monitor key performance indicators (KPIs) to

track progress.

• Examples: Regularly review defect rates, conduct

retrospectives.

2.5 Review and Adjust:

• Regularly review the e ectiveness of implemented changes

and adjust as needed.

• Examples: Solicit feedback from the development team,

conduct periodic assessments.

3. Key Considerations:

3.1 Team Collaboration:

• Foster a culture of collaboration and communication within

the development team.

• Examples: Use collaborative tools, conduct regular team

meetings.

3.2 Continuous Learning:

• Encourage continuous learning and skill development among

team members.

• Examples: Provide training opportunities, encourage

knowledge sharing.

3.3 Automation:
ff
 • Leverage automation tools to streamline repetitive tasks and
reduce manual errors.

• Examples: Continuous Integration (CI), automated testing,

deployment pipelines.

4. Resources:

• Capability Maturity Model Integration (CMMI)

• ISO/IEC 15504 (SPICE)

Please note that while the examples provided are illustrative, the
speci c improvement strategies and tools would depend on the
unique context and requirements of the software development
environment. Continuous assessment and improvement are crucial
for adapting to changing technologies and delivering high-quality
software products.

SDLC - Waterfall Model

The Waterfall Model was the rst Process Model to be introduced.
It is also referred to as a linear-sequential life cycle model. It is
very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and
there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used
for software development.

The waterfall Model illustrates the software development process in

a linear sequential ow. This means that any phase in the
development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.
fi
fl
fi
Waterfall Model - Design
Waterfall approach was rst SDLC Model to be used widely in
Software Engineering to ensure success of the project. In "The
Waterfall" approach, the whole process of software development is
divided into separate phases. In this Waterfall model, typically, the
outcome of one phase acts as the input for the next phase
sequentially.

The following illustration is a representation of the di erent phases

of the Waterfall Model.

The sequential phases in Waterfall model are −

• Requirement Gathering and analysis − All possible

requirements of the system to be developed are captured in
this phase and documented in a requirement speci cation
document.
fi
fi
ff
 • System Design − The requirement speci cations from rst
phase are studied in this phase and the system design is
prepared. This system design helps in specifying hardware
and system requirements and helps in de ning the overall
system architecture.

• Implementation − With inputs from the system design, the

system is rst developed in small programs called units, which
are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.

• Integration and Testing − All the units developed in the

implementation phase are integrated into a system after
testing of each unit. Post integration the entire system is
tested for any faults and failures.

• Deployment of system − Once the functional and non-

functional testing is done; the product is deployed in the
customer environment or released into the market.

• Maintenance − There are some issues which come up in the

client environment. To x those issues, patches are released.
Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the
customer environment.

All these phases are cascaded to each other in which progress is

seen as owing steadily downwards (like a waterfall) through the
phases. The next phase is started only after the de ned set of
goals are achieved for previous phase and it is signed o , so the
name "Waterfall Model". In this model, phases do not overlap.

Waterfall Model - Application

Every software developed is di erent and requires a suitable SDLC
approach to be followed based on the internal and external factors.
Some situations where the use of Waterfall model is most
appropriate are −
fl
fi
fi
ff
fi
fi
fi
fi
ff
 • Requirements are very well documented, clear and xed.

• Product de nition is stable.

• Technology is understood and is not dynamic.

• There are no ambiguous requirements.

• Ample resources with required expertise are available to

support the product.

• The project is short.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for
departmentalization and control. A schedule can be set with
deadlines for each stage of development and a product can
proceed through the development process model phases one by
one.

Development moves from concept, through design,

implementation, testing, installation, troubleshooting, and ends up
at operation and maintenance. Each phase of development
proceeds in strict order.

Some of the major advantages of the Waterfall Model are as

follows −

• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase

has speci c deliverables and a review process.

• Phases are processed and completed one at a time.

• Works well for smaller projects where requirements are very

well understood.
fi
fi
fi
 • Clearly de ned stages.

• Well understood milestones.

• Easy to arrange tasks.

• Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow
much re ection or revision. Once an application is in the testing
stage, it is very di cult to go back and change something that was
not well-documented or thought upon in the concept stage.

The major disadvantages of the Waterfall Model are as follows −

• No working software is produced until late during the life

cycle.

• High amounts of risk and uncertainty.

• Not a good model for complex and object-oriented projects.

• Poor model for long and ongoing projects.

• Not suitable for the projects where requirements are at a

moderate to high risk of changing. So, risk and uncertainty is
high with this process model.

• It is di cult to measure progress within stages.

• Cannot accommodate changing requirements.

• Adjusting scope during the life cycle can end a project.

• Integration is done as a "big-bang. at the very end, which

doesn't allow identifying any technological or business
bottleneck or challenges early.
ffi
fl
fi
ffi
 SDLC - Iterative Model
In the Iterative model, iterative process starts with a simple
implementation of a small set of the software requirements and
iteratively enhances the evolving versions until the complete
system is implemented and ready to be deployed.

An iterative life cycle model does not attempt to start with a full
speci cation of requirements. Instead, development begins by
specifying and implementing just part of the software, which is then
reviewed to identify further requirements. This process is then
repeated, producing a new version of the software at the end of
each iteration of the model.

Iterative Model - Design

Iterative process starts with a simple implementation of a subset of
the software requirements and iteratively enhances the evolving
versions until the full system is implemented. At each iteration,
design modi cations are made and new functional capabilities are
added. The basic idea behind this method is to develop a system
through repeated cycles (iterative) and in smaller portions at a time
(incremental).

The following illustration is a representation of the Iterative and

Incremental model −
fi
fi
Iterative and Incremental development is a combination of both
iterative design or iterative method and incremental build model for
development. "During software development, more than one
iteration of the software development cycle may be in progress at
the same time." This process may be described as an "evolutionary
acquisition" or "incremental build" approach."

In this incremental model, the whole requirement is divided into

various builds. During each iteration, the development module
goes through the requirements, design, implementation and testing
phases. Each subsequent release of the module adds function to
the previous release. The process continues till the complete
system is ready as per the requirement.

The key to a successful use of an iterative software development

lifecycle is rigorous validation of requirements, and veri cation &
testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through
successive cycles, tests must be repeated and extended to verify
each version of the software.

Iterative Model - Application

Like other SDLC models, Iterative and incremental development
has some speci c applications in the software industry. This model
is most often used in the following scenarios −
fi
fi
 • Requirements of the complete system are clearly de ned and
understood.

• Major requirements must be de ned; however, some

functionalities or requested enhancements may evolve with
time.

• There is a time to the market constraint.

• A new technology is being used and is being learnt by the

development team while working on the project.

• Resources with needed skill sets are not available and are
planned to be used on contract basis for speci c iterations.

• There are some high-risk features and goals which may

change in the future.

Iterative Model - Pros and Cons

The advantage of this model is that there is a working model of the
system at a very early stage of development, which makes it easier
to nd functional or design aws. Finding issues at an early stage
of development enables to take corrective measures in a limited
budget.

The disadvantage with this SDLC model is that it is applicable only

to large and bulky software development projects. This is because
it is hard to break a small software system into further small
serviceable increments/modules.

The advantages of the Iterative and Incremental SDLC Model are

as follows −

• Some working functionality can be developed quickly and

early in the life cycle.

• Results are obtained early and periodically.

fi
fl
fi
fi
fi
 • Parallel development can be planned.

• Progress can be measured.

• Less costly to change the scope/requirements.

• Testing and debugging during smaller iteration is easy.

• Risks are identi ed and resolved during iteration; and each

iteration is an easily managed milestone.

• Easier to manage risk - High risk part is done rst.

• With every increment, operational product is delivered.

• Issues, challenges and risks identi ed from each increment

can be utilized/applied to the next increment.

• Risk analysis is better.

• It supports changing requirements.

• Initial Operating time is less.

• Better suited for large and mission-critical projects.

• During the life cycle, software is produced early which

facilitates customer evaluation and feedback.

The disadvantages of the Iterative and Incremental SDLC Model

are as follows −

• More resources may be required.

• Although cost of change is lesser, but it is not very suitable for

changing requirements.

• More management attention is required.

fi
fi
fi
 • System architecture or design issues may arise because not
all requirements are gathered in the beginning of the entire life
cycle.

• De ning increments may require de nition of the complete

system.

• Not suitable for smaller projects.

• Management complexity is more.

• End of project may not be known which is a risk.

• Highly skilled resources are required for risk analysis.

SDLC - Spiral Model

The spiral model combines the idea of iterative development with
the systematic, controlled aspects of the waterfall model. This
Spiral model is a combination of iterative development process
model and sequential linear development model i.e. the waterfall
model with a very high emphasis on risk analysis. It allows
incremental releases of the product or incremental re nement
through each iteration around the spiral.

Spiral Model - Design

The spiral model has four phases. A software project repeatedly
passes through these phases in iterations called Spirals.

Identi cation
This phase starts with gathering the business requirements in the
baseline spiral. In the subsequent spirals as the product matures,
identi cation of system requirements, subsystem requirements and
unit requirements are all done in this phase.
fi
fi
fi
fi
fi
This phase also includes understanding the system requirements
by continuous communication between the customer and the
system analyst. At the end of the spiral, the product is deployed in
the identi ed market.

Design
The Design phase starts with the conceptual design in the baseline
spiral and involves architectural design, logical design of modules,
physical product design and the nal design in the subsequent
spirals.

Construct or Build
The Construct phase refers to production of the actual software
product at every spiral. In the baseline spiral, when the product is
just thought of and the design is being developed a POC (Proof of
Concept) is developed in this phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements

and design details a working model of the software called build is
produced with a version number. These builds are sent to the
customer for feedback.

Evaluation and Risk Analysis

Risk Analysis includes identifying, estimating and monitoring the
technical feasibility and management risks, such as schedule
slippage and cost overrun. After testing the build, at the end of rst
iteration, the customer evaluates the software and provides
feedback.

The following illustration is a representation of the Spiral Model,

listing the activities in each phase.
fi
fi
fi
Based on the customer evaluation, the software development
process enters the next iteration and subsequently follows the
linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues
throughout the life of the software.

Spiral Model Application

The Spiral Model is widely used in the software industry as it is in
sync with the natural development process of any product, i.e.
learning with maturity which involves minimum risk for the
customer as well as the development rms.
fi
 The following pointers explain the typical uses of a Spiral Model −

• When there is a budget constraint and risk evaluation is

important.

• For medium to high-risk projects.

• Long-term project commitment because of potential changes

to economic priorities as the requirements change with time.

• Customer is not sure of their requirements which is usually the

case.

• Requirements are complex and need evaluation to get clarity.

• New product line which should be released in phases to get

enough customer feedback.

• Signi cant changes are expected in the product during the

development cycle.

Spiral Model - Pros and Cons

The advantage of spiral lifecycle model is that it allows elements of
the product to be added in, when they become available or known.
This assures that there is no con ict with previous requirements
and design.

This method is consistent with approaches that have multiple

software builds and releases which allows making an orderly
transition to a maintenance activity. Another positive aspect of this
method is that the spiral model forces an early user involvement in
the system development e ort.

On the other side, it takes a very strict management to complete

such products and there is a risk of running the spiral in an
inde nite loop. So, the discipline of change and the extent of taking
change requests is very important to develop and deploy the
product successfully.
fi
fi
ff
fl
The advantages of the Spiral SDLC Model are as follows −

• Changing requirements can be accommodated.

• Allows extensive use of prototypes.

• Requirements can be captured more accurately.

• Users see the system early.

• Development can be divided into smaller parts and the risky

parts can be developed earlier which helps in better risk
management.

The disadvantages of the Spiral SDLC Model are as follows −

• Management is more complex.

• End of the project may not be known early.

• Not suitable for small or low risk projects and could be

expensive for small projects.

• Process is complex

• Spiral may go on inde nitely.

• Large number of intermediate stages requires excessive

documentation.
fi
 SDLC - V-Model
The V-model is an SDLC model where execution of processes
happens in a sequential manner in a V-shape. It is also known as
Veri cation and Validation model.

The V-Model is an extension of the waterfall model and is based on

the association of a testing phase for each corresponding
development stage. This means that for every single phase in the
development cycle, there is a directly associated testing phase.
This is a highly-disciplined model and the next phase starts only
after completion of the previous phase.

V-Model - Design
Under the V-Model, the corresponding testing phase of the
development phase is planned in parallel. So, there are Veri cation
phases on one side of the ‘V’ and Validation phases on the other
side. The Coding Phase joins the two sides of the V-Model.

The following illustration depicts the di erent phases in a V-Model

of the SDLC.
fi
ff
fi
V-Model - Veri cation Phases
There are several Veri cation phases in the V-Model, each of these
are explained in detail below.

Business Requirement Analysis

This is the rst phase in the development cycle where the product
requirements are understood from the customer’s perspective. This
phase involves detailed communication with the customer to
understand his expectations and exact requirement. This is a very
important activity and needs to be managed well, as most of the
customers are not sure about what exactly they need. The
acceptance test design planning is done at this stage as
business requirements can be used as an input for acceptance
testing.
fi
fi
fi
System Design
Once you have the clear and detailed product requirements, it is
time to design the complete system. The system design will have
the understanding and detailing the complete hardware and
communication setup for the product under development. The
system test plan is developed based on the system design. Doing
this at an earlier stage leaves more time for the actual test
execution later.

Architectural Design
Architectural speci cations are understood and designed in this
phase. Usually more than one technical approach is proposed and
based on the technical and nancial feasibility the nal decision is
taken. The system design is broken down further into modules
taking up di erent functionality. This is also referred to as High
Level Design (HLD).

The data transfer and communication between the internal

modules and with the outside world (other systems) is clearly
understood and de ned in this stage. With this information,
integration tests can be designed and documented during this
stage.

Module Design
In this phase, the detailed internal design for all the system
modules is speci ed, referred to as Low Level Design (LLD). It is
important that the design is compatible with the other modules in
the system architecture and the other external systems. The unit
tests are an essential part of any development process and helps
eliminate the maximum faults and errors at a very early stage.
These unit tests can be designed at this stage based on the
internal module designs.

Coding Phase
ff
fi
fi
fi
fi
fi
 The actual coding of the system modules designed in the design
phase is taken up in the Coding phase. The best suitable
programming language is decided based on the system and
architectural requirements.

The coding is performed based on the coding guidelines and

standards. The code goes through numerous code reviews and is
optimized for best performance before the nal build is checked
into the repository.

Validation Phases
The di erent Validation Phases in a V-Model are explained in detail
below.

Unit Testing
Unit tests designed in the module design phase are executed on
the code during this validation phase. Unit testing is the testing at
code level and helps eliminate bugs at an early stage, though all
defects cannot be uncovered by unit testing.

Integration Testing
Integration testing is associated with the architectural design
phase. Integration tests are performed to test the coexistence and
communication of the internal modules within the system.

System Testing
System testing is directly associated with the system design
phase. System tests check the entire system functionality and the
communication of the system under development with external
systems. Most of the software and hardware compatibility issues
can be uncovered durqing this system test execution.
ff
fi
Acceptance Testing
Acceptance testing is associated with the business requirement
analysis phase and involves testing the product in user
environment. Acceptance tests uncover the compatibility issues
with the other systems available in the user environment. It also
discovers the non-functional issues such as load and performance
defects in the actual user environment.

V- Model ─ Application
V- Model application is almost the same as the waterfall model, as
both the models are of sequential type. Requirements have to be
very clear before the project starts, because it is usually expensive
to go back and make changes. This model is used in the medical
development eld, as it is strictly a disciplined domain.

The following pointers are some of the most suitable scenarios to

use the V-Model application.

• Requirements are well de ned, clearly documented and xed.

• Product de nition is stable.

• Technology is not dynamic and is well understood by the

project team.

• There are no ambiguous or unde ned requirements.

• The project is short.

V-Model - Pros and Cons

The advantage of the V-Model method is that it is very easy to
understand and apply. The simplicity of this model also makes it
easier to manage. The disadvantage is that the model is not exible
to changes and just in case there is a requirement change, which is
fi
fi
fi
fi
fi
fl
very common in today’s dynamic world, it becomes very expensive
to make the change.

The advantages of the V-Model method are as follows −

• This is a highly-disciplined model and Phases are completed

one at a time.

• Works well for smaller projects where requirements are very

well understood.

• Simple and easy to understand and use.

• Easy to manage due to the rigidity of the model. Each phase

has speci c deliverables and a review process.

The disadvantages of the V-Model method are as follows −

• High risk and uncertainty.

• Not a good model for complex and object-oriented projects.

• Poor model for long and ongoing projects.

• Not suitable for the projects where requirements are at a

moderate to high risk of changing.

• Once an application is in the testing stage, it is di cult to go

back and change a functionality.

• No working software is produced until late during the life

cycle.
fi
ffi