Software Engineering Laboratory

Assignment-1: Formal documentation

DIFFERENT PHASES OF SOFTWARE

DEVELOPMENT LIFE CYCLE

Group - 11
K Ashrith (2021CSB066)
Souvik Dawn (2021CSB067)
Ranjan Kumar (2021CSB068)
Bezawada Hamsa Tejaswini (2021CSB069)
Prayas Mazumdar (2021CSB071)
Feasibility study
In software engineering, a feasibility study is an important step in the
initial planning and design phase of a proposed software project. The
primary goal of a feasibility study is to assess the practicality, viability,
and potential success of the proposed software solution. It involves a
comprehensive analysis of various aspects related to the project, thereby
helping stakeholders make decisions before investing time and
resources.

Why feasibility study?

The feasibility study is an essential phase of the software project
management process. After the feasibility study is completed, the
proposed project is either continued as, in fact, feasible or the proposed
project is abandoned. A conclusion is drawn as to whether, If it’s not
correct/feasible, develop it or reconsider/analyze the proposed project.

In addition to this feasibility study, it helps identify risk factors

associated with system development and deployment. Risk analysis also
plans limited business options and improves success rates by analyzing
various parameters associated with proposed project development.

Types of feasibility studies:

1. Technical Feasibility
Technical feasibility assesses if a project has the necessary technological
resources for success. This study not only examines current hardware
and software but also evaluates the skills of the development team. It
ensures that the chosen technology is easy to maintain and upgrade,
critical for the seamless progress of software projects. In essence,
technical feasibility acts as a project’s tech compass, confirming that the
technological foundation is sturdy enough to support the envisioned
development journey.

2. Operational Feasibility
Operational feasibility analyzes the level of service delivery according to
requirements and the ease of operating and maintaining the product
after deployment. Along with these other operational areas, it
determines the product’s usability, whether the software development
team’s decisions for the proposed solution are acceptable, and so on.
● Determine if the expected issue in the user request is a high
priority.
● Determine if the organization is satisfied with alternative
solutions proposed by the software development team.
● Determine if the solution proposed by the software development
team is acceptable.
● Analyze whether users are comfortable with new software.

3. Economic Feasibility
Project costs and benefits are analyzed in a profitability study. This
means that as part of this feasibility study, a detailed analysis of the costs
of the development project will be made. This includes all costs
necessary for the final development, such as hardware and software
resources required, design and development costs, operating costs, etc. It
is then analyzed whether the project is financially beneficial to the
organization.
● The costs incurred in software development generate long-term
benefits for an organization.
● Costs required to conduct a complete software study (e.g.,
requirements extraction and requirements analysis).
● Hardware, software, development team, and training costs.
4. Legal Feasibility

In a legal feasibility study, the project is analyzed from the view of

legality. This includes analysis of obstacles in the legal
implementation of the project, data protection or social media
laws, project certificates, licenses, copyrights, etc. Overall, a legal
feasibility study is a study to determine whether a proposed project
meets legal and ethical requirements.

5. Schedule Feasibility

A schedule feasibility study mainly analyzes the proposed project

deadlines/deadlines, including the time it will take the team to
complete the final project. This has a significant impact on the
organization as the project’s purpose may fail if it is not completed
on time.

EXAMPLE:

A UNIVERSITY SCIENCE BUILDING

In the preliminary analysis, school officials explored several
options, weighing the benefits and costs of expanding and updating
the science building. Some school officials had concerns about the
project, including the cost and possible community opposition. The
new science building would be much larger, and the community
board had earlier rejected similar proposals.

The feasibility study also explored the technological needs of the

new science facility, the benefits to the students, and the long-term
viability of the college.

Financial projections showed the cost and scope of the project and
how the school planned to raise the needed funds, which included
issuing a bond to investors and tapping into the
school's endowment. The projections also showed how the
expanded facility would allow more students to be enrolled in the
science programs, increasing revenue from tuition and fees.
 The feasibility study demonstrated that the project was viable,
paving the way to enacting the modernization and expansion plans
of the science building.

Feasibility Studies: Common Problems

• The scope of the report is ambiguous. Without a clear definition of the

range, this is the case It is unclear whether the project is feasible.
• The plan does not describe activities in sufficient detail to estimate
effort.
Persuasive.
• The project is too ambiguous. The report must describe how you will
act. Monitor progress and adjust scope as needed.

CONCLUSION:
A pre-feasibility study can save time and money when planning new
software projects because it helps plan them efficiently. This project
helps determine whether a new system is technically viable before
investing in its development. Therefore, it is crucial in software
engineering.

Resources:
https://ellow.io/define-feasibility-study-in-software-engineering/
https://www.shiksha.com/online-courses/articles/feasibility-study-in-s
oftware-engineering/#:~:text=In%20software%20engineering%2C%20t
he%20feasibility,before%20investing%20in%20its%20development.
https://www.investopedia.com/terms/f/feasibility-study.asp#toc-examp
les-of-a-feasibility-study

Requirement analysis

In the world of software engineering, the journey of creating impactful

software begins with a crucial step: requirement analysis.
Requirement analysis is all about understanding what software is
supposed to do and the constraints it must operate within.
This process involves identifying, documenting, and analyzing these
business requirements to ensure that they are clearly understood and
feasible.

This is important because getting this phase right means avoiding

costly mistakes later on. If the foundation is weak or misaligned,
everything built on it can crumble.
Benefits of requirements analysis
1. Clear Project Scope and Objectives
This clarity ensures that all stakeholders have a common understanding
of what the software will and will not do, which is crucial for custom
software tailored to specific needs.
2. Improved Stakeholder Satisfaction
By involving relevant stakeholders in the requirements-gathering
process, their needs and expectations are more accurately captured.
This leads to software that is more aligned with user requirements,
thereby increasing stakeholder satisfaction
3. Reduced Development Costs and Time
A thorough project planning phase and requirements analysis helps in
identifying potential issues early in the project, reducing the need for
costly changes and reworks later in the development process.
 4. Enhanced Quality of the Final Product
With a clear understanding of requirements, developers are better
equipped to build software that meets the desired quality standards. This
can result in fewer bugs and a more stable, efficient, and user-friendly
product.
5. Better Risk Management
Understanding the full spectrum of requirements helps in identifying
and mitigating potential risks early in the project lifecycle. This proactive
approach to risk management can save time and resources and
contribute to a smoother project execution.
6. Facilitates Prioritization
Requirements analysis enables the identification of critical features and
functions, allowing for effective prioritization. This ensures that the most
important aspects of the software are developed first, aligning with
business priorities and maximizing return on investment.
7. Improved Communication and Collaboration
The process fosters communication among developers, key stakeholders,
and users. This collaborative environment ensures that all parties are on
the same page throughout the development process, enhancing
teamwork and mutual understanding.
8. Enables Scalability and Flexibility
By understanding the current and future needs of users, the software can
be designed to be scalable and flexible. This ensures that it can evolve
with changing business needs and technological advancements.

Steps of requirements analysis process

Step 1: Stakeholder Identification

The first step in the requirements analysis process of a software

development project is stakeholder identification.
Simply put, this is the process of finding out who has a stake in the
success of the software being developed stakeholders are not just the
customers who commission the software, but a broader group.
They include the end users who will interact with the software on
a daily basis and who may have valuable insight into what features are
essential.
It’s important to identify all of these stakeholders early on, because each
can provide unique perspectives and requirements.
Step 2: Elicitation of Requirements

The second step in the requirements analysis process is requirements

elicitation.
This is where the team actively gathers detailed information about what
the software needs to do from the identified stakeholders. It’s like
gathering pieces of a puzzle from different sources to see the whole
picture.
The team uses a variety of methods to do this. Interviews are common,
where team members have one-on-one conversations with stakeholders
to understand their needs. Questionnaires can be sent out to quickly
gather information from a larger group. Workshops or group sessions
are also effective, especially when interactive discussions can lead to
deeper insights. Another method is user observation, where the team
observes how potential users interact with existing systems to identify
unspoken needs or problems.
This step is critical because it’s about gathering as much relevant
information as possible to ensure that the software is designed to meet
the real needs of its users.
Step 3: Documentation of Requirements
The third step in the requirements analysis process is requirements
documentation.
After gathering all the necessary information from stakeholders, it’s time
to put it all down on paper, or more likely, in a digital document.
The goal of this step is to create a clear, detailed record of what the
software needs to do and the constraints within which it must operate.
The team typically creates a document called a Software Requirement
Specification (SRS), which serves as a guide for everyone involved in the
project. This document includes everything from the specific features the
software must have, to the performance levels required, to the standards
it must meet.
It’s important to get this step right because the SRS acts as a reference
point throughout the software development life cycle. It helps
ensure that developers understand exactly what they need to build, and
it provides a way to measure progress and test the final product against
the original requirements. Simply put, this document is the blueprint for
the software project, outlining what needs to be built and how it should
work, and ensuring that everyone is on the same page.

Step 4: Analysis and Negotiation

The fourth step in the requirements analysis process is analysis and

negotiation.
This stage involves taking a closer look at the documented requirements
to make sure they are realistic and workable.The team examines each
requirement to understand its implications:

● How difficult will it be to implement?

● Does it conflict with any other requirements?
● Is it actually necessary for the software’s success?
This is a bit like solving a puzzle, making sure all the pieces fit together
in the right way.Negotiation comes into play when there are conflicting
requirements or limitations in resources like time or budget.

Sometimes, what the stakeholders want might not be feasible, or

different stakeholders might have different priorities. In such cases, the
team needs to discuss these issues with the stakeholders to reach a
common ground. This could mean adjusting some requirements,
removing others, or finding a middle path that satisfies the most critical
needs without overstretching resources.

The goal here is to finalize a set of requirements that is achievable

and aligns with the overall objectives of the project. It’s a
balancing act, ensuring that the software will fulfill its intended purpose
while staying within practical limits.

Step 5: Validation and Verification

The final step in the requirements analysis process, which combines both
validation and verification, is critical to ensuring that the project is on
the right track.
Validation is about confirming that the requirements actually
meet the needs of the stakeholders and the goals of the project.
It’s like asking, “Are we building the right thing?” Here, the team reviews
the requirements with the stakeholders to make sure they are in line with
their expectations and the goals of the project.
In addition to the validation aspect of the final step in the requirements
analysis process, there’s an important component known as the Proof of
Concept (PoC). A proof of concept is a small project or experiment
conducted to test whether a particular idea or aspect of the software is
technically feasible.
It allows the development team to explore whether the ambitious goals
can actually be achieved with current technology and within the
constraints of the project, such as time and budget.
Verification, on the other hand, is about making sure that
the requirements are documented correctly and consistently.
It’s like proofreading and quality checking the requirements document.
The team reviews the document to ensure that all requirements are clear,
unambiguous, and consistent.

Requirements analysis techniques

Data Flow Diagram (DFD)
A Data Flow Diagram is a graphical tool that helps visualize how
data moves through a system. It shows where the data comes from, how
it’s processed, and where it goes.
Think of it as a map that shows the journey of data, with various stops
and routes it takes along the way. This context diagram is useful for
understanding the system from a data perspective, making it easier to
identify what kind of data the system needs to handle and how it should
be processed.
Customer Journey Map
This technique involves creating a visual representation of the steps a
customer goes through when interacting with a software or service.
Customer journey mapping is like drawing a map of the customer’s
experience, from their initial contact with the software to the final
outcome. By mapping out these steps, the development team can
understand the user’s needs, experiences, and pain points at each stage.
This insight is valuable for designing software that provides a smooth
and satisfying user experience.
Business Motivation Model (BMM)
The Business Motivation Model is a framework used for
developing, communicating, and managing business plans in an
organized manner.
It helps in understanding the business side of the software by outlining
what the business wants to achieve (goals), why it wants to achieve it
(objectives), and how it plans to do so (strategies and tactics). This
model is essential for ensuring that the software aligns with the broader
business goals and strategies.
Gap Analysis
Gap analysis is a technique where the team compares the current
state of a system or particular process to the desired state and
identifies the ‘gaps’ or differences between them.
It’s like looking at where you are now and where you want to be, and
then figuring out what needs to be done to get there. This detailed
analysis helps in understanding what new features or changes need to be
incorporated into the software to meet the desired objectives.
User stories
User stories are a popular tool in requirements analysis, particularly in
Agile software development methodologies.
They offer a simple, yet effective way to capture user requirements
during business analysis. A user story typically consists of a
short, simple description of a software feature from the
perspective of the end user or customer. The structure of a user story is
straightforward, often following a basic template: “As a [type of user], I
want [an action] so that [a benefit/value].”
User stories are usually recorded on cards or digital tools and are often
accompanied by acceptance criteria, which define the conditions that
must be met for the story to be considered complete.
Design

Software

Design Part
Software design is a mechanism to transform user requirements into
some suitable form, which helps the programmer in software coding and
implementation. It deals with representing the client's requirement, as
described in SRS (Software Requirement Specification) document, into a
form, i.e., easily implementable using programming language.

The software design phase is the third step in SDLC (Software

Design Life Cycle), which moves the concentration from the problem
domain to the solution domain. In software design, we consider the
system to be a set of components or modules with clearly defined
behaviors & boundaries.

OBJECTIVES OF S/W DESIGN :

 1. Correctness: Software design should be correct as per
requirement.
2. Completeness: The design should have all components like data
structures, modules, and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in the
design.
6. Maintainability: The design should be so simple so that it can
be easily maintainable by other designers.

SOFTWARE DESIGN PROCESS:

● Wireframing - It helps determine the basic structure of

software like the navigation and features before adding
substantial design components like colors, graphics, and fonts. It
helps both the clients and the developers to understand how
things are going to be placed to make functional and
feature-loaded software.
● Data Flow Diagrams - These help in determining the
different levels of concept in a system by showing the complete
system requirement, detailed aims of the system, and also
details about the functioning of the software.
● Technical Design - It helps to carry out the system
functionality into code. It lists every technical aspect of the
 software design which acts as a guide while implementing the
features and functionalities. In addition, it provides a detailed
description of software requirements, software architecture, data
flow, and structures, considerable components, and more.
● User Interface - It comprises the parts with which the user
interacts with software, that help in making the interface
understandable, usable, and friendly. There are three types of
user interfaces namely the graphical user interface,
voice-controlled interfaces, and gesture-based interfaces.

Example:
Design the library classes/data structures from the data items in the
object model for the library problem. The data design and the
architectural phases have been combined in this example. The
concentration in this example is on the loan and checkout functionality,
with little regard for the other necessary tasks, such as administration,
cataloging, assigning overdue fines, retiring books, and patron
maintenance.
The domain entity ‘‘book’’ is probably not going to continue into the
design. It will be combined with ‘‘copy’’ into a class/data structure that
stores all the information about a copy. It will probably use the ISBN and
a copy number as the unique identifier. The patron information will be
stored in a second data structure. Each record is probably identified by
an unique patron ID number. The loan information may or may not be a
separate data structure. If borrowing information needs to be saved
beyond the return of the book, then it had better be a separate class/data
structure. Otherwise, the patron ID can be part of the copy class/data
structure along with the due date of the book.
Note in Fig. 9-2 that many data items have been added that are more in
the
implementation/solution space than in the problem/domain space. It
can be argued that ‘‘ISBN’’ is part of the problem space instead of the
solution space, but many library systems do not allow normal users to
search by ISBN.

Drive link to the book on SW from where it was taken .

Coding

SOFTWARE

CODING PART

The coding is the process of transforming the design of a system into a

computer language format. This coding phase of software development is
concerned with software translating design specification into the source
code. It is necessary to write source code & internal documentation so
that conformance of the code to its specification can be easily verified.
Coding is done by the coder or programmers who are independent
people than the designer. The goal is not to reduce the effort and cost of
the coding phase, but to cut to the cost of a later stage. The cost of testing
and maintenance can be significantly reduced with efficient coding.

Goals of Coding

1. To translate the design of system into a computer

language format: The coding is the process of transforming the
design of a system into a computer language format, which can be
executed by a computer and that perform tasks as specified by the
design of operation during the design phase.
2. To reduce the cost of later phases: The cost of testing and
maintenance can be significantly reduced with efficient coding.
3. Making the program more readable: Program should be easy
to read and understand. It increases code understanding having
 readability and understandability as a clear objective of the coding
activity can itself help in producing more maintainable software.

For implementing our design into code, we require a high-level

functional language. A programming language should have the following
characteristics:

Characteristics of Programming Language

Readability: A good high-level language will allow programs to be

written in some methods that resemble a quite-English description of the
underlying functions. The coding may be done in an essentially
self-documenting way.
Portability: High-level languages, being virtually
machine-independent, should be easy to develop portable software.
Generality: Most high-level languages allow the writing of a vast
collection of programs, thus relieving the programmer of the need to
develop into an expert in many diverse languages.
Brevity: Language should have the ability to implement the algorithm
with less amount of code. Programs mean in high-level languages are
often significantly shorter than their low-level equivalents.
Error checking: A programmer is likely to make many errors in the
development of a computer program. Many high-level languages invoke
a lot of bugs checking both at compile-time and run-time.
Cost: The ultimate cost of a programming language is a task of many of
its characteristics.
Quick translation: It should permit quick translation.
Efficiency: It should authorize the creation of an efficient object code.
Modularity: It is desirable that programs can be developed in the
language as several separately compiled modules, with the appropriate
structure for ensuring self-consistency among these modules.
Widely available: Language should be widely available, and it should
be feasible to provide translators for all the major machines and all the
primary operating systems.
A coding standard lists several rules to be followed during coding, such
as the way variables are to be named, the way the code is to be laid out,
error return conventions, etc.
Coding Standards
1. Indentation: Proper and consistent indentation is essential in
producing easy to read and maintainable programs.
Indentation should be used to:
o Emphasize the body of a control structure such as a loop or a
select statement.
o Emphasize the body of a conditional statement
o Emphasize a new scope block
2. Inline comments: Inline comments analyze the functioning of
the subroutine, or key aspects of the algorithm shall be frequently
used.
3. Rules for limiting the use of global: These rules file what
types of data can be declared global and what cannot.
4. Structured Programming: Structured (or Modular)
Programming methods shall be used. "GOTO" statements shall not
be used as they lead to "spaghetti" code, which is hard to read and
maintain, except as outlined line in the FORTRAN Standards and
Guidelines.
5. Naming conventions for global variables, local variables,
and constant identifiers: A possible naming convention can be
that global variable names always begin with a capital letter, local
 variable names are made of small letters, and constant names are
always capital letters.
6. Error return conventions and exception handling
system: Different functions in a program report the way error
conditions are handled should be standard within an organization.
For example, different tasks while encountering an error condition
should either return a 0 or 1 consistently.

Do’s and Don’ts in Coding

 Coding Guidelines
General coding guidelines provide the programmer with a set of the best
methods which can be used to make programs more comfortable to read
and maintain. Most of the examples use the C language syntax, but the
guidelines can be tested to all languages.
The following are some representative coding guidelines recommended
by many software development organizations
1. Line Length: It is considered a good practice to keep the length of
source code lines at or below 80 characters. Lines longer than this may
not be visible properly on some terminals and tools. Some printers will
truncate lines longer than 80 columns.

2. Spacing: The appropriate use of spaces within a line of code can

improve readability.

Example:

Bad: cost=price+(price*sales_tax)
fprintf(stdout ,"The total cost is %5.2f\n",cost);
Better: cost = price + ( price * sales_tax )
fprintf (stdout,"The total cost is %5.2f\n",cost);

3. The code should be well-documented: As a rule of thumb, there

must be at least one comment line on the average for every three-source
line.
4. The length of any function should not exceed 10 source
lines: A very lengthy function is generally very difficult to understand as
it possibly carries out many various functions. For the same reason,
lengthy functions are possible to have a disproportionately larger
number of bugs.

5. Do not use goto statements: Use of goto statements makes a

program unstructured and very tough to understand.

6. Inline Comments: Inline comments promote readability.

7. Error Messages: Error handling is an essential aspect of computer

programming. This does not only include adding the necessary logic to
test for and handle errors but also involves making error messages
meaningful.

Example :

Below is a simple example of a client-server login system using Python's

socket programming. This example demonstrates a basic login
mechanism where the client sends a username and password to the
server, and the server validates the credentials.

Client code :
Server code :
This code is properly documented and readable . Since it is a python
code it is indented .
 Example 2:

Below is a simple C program that demonstrates how to create a child

process using the fork() system call. The program creates a child
process, and both the parent and child processes print their respective
process IDs (PID) and a message.

The code is properly documented and indented .

#include <stdio.h>

#include <unistd.h> //Included for the fork() system call.

#include <sys/types.h>//Included for types like pid_t

#include <sys/wait.h>//Included for the wait() system call used by the

parent

int main() {

pid_t pid; // Declare a variable to store process IDs.

// Fork a child process

pid = fork();

if (pid < 0) {

// Fork failed

fprintf(stderr, "Fork failed\n");

return 1;

} else if (pid == 0) {

// Child process

printf("Child process - PID: %d\n", getpid()); // Print child's process

ID
 printf("Child's parent process PID: %d\n", getppid()); // Print
parent's process ID

printf("Child process exiting\n"); // Print exit message for the child

} else {

// Parent process

printf("Parent process - PID: %d\n", getpid()); // Print parent's

process ID

printf("Parent's child process PID: %d\n", pid); // Print child's

process ID

// Wait for the child process to complete

wait(NULL);

printf("Parent process exiting\n"); // Print exit message for the

parent

return 0;

Testing

1. Purpose and Focus:

The testing phase serves as a critical stage in the Software Development

Lifecycle, with its primary purpose being investigation and discovery.
Developers aim to ensure that the developed code and programming
align with the specified customer requirements. The focus is on
identifying any discrepancies, defects, or issues that might hinder the
software's functionality or adherence to requirements.
2. Test Planning:

Test planning is a meticulous process that precedes the actual testing

activities. It involves the development of a comprehensive test plan. This
plan serves as a roadmap, detailing various aspects such as testing types,
available resources, testing methodologies, designated testers, and
crucially, test scripts. Test scripts act as a set of instructions for testers,
providing a standardized approach to executing tests and maintaining
consistency throughout the testing process.

3. Types of Testing:
a. Unit Testing:

This testing type is focused on assessing specific units or

components of the software in isolation. The objective is to verify
if each unit functions as expected independently.

b. Integration Testing:

Integration testing involves combining individual units within a

program and testing them as a group. The main focus is on
identifying any interface defects that may arise between different
modules or functions when they interact.

c. System Testing:

In system testing, the entire application is evaluated as a whole.

This comprehensive testing ensures that the software not only
meets individual unit specifications but also functions cohesively
as a complete system, adhering to outlined requirements and
quality standards.
 d. Acceptance Testing:

Acceptance testing, or User Acceptance Testing (UAT), is the final

phase where the system is assessed to determine if it is ready for
release. This involves validating whether the software satisfies user
expectations and is suitable for deployment.

4. Blackbox Testing:

Blackbox testing is a methodology that focuses on assessing the

functionalities of the software without knowledge of its internal code
structure. The process involves carefully examining system
requirements, selecting valid and invalid inputs, determining expected
outputs, constructing relevant test cases, executing them, and then
comparing the actual outputs with the expected ones. If discrepancies
are found, defects are identified, fixed, and re-tested.

Techniques such as Equivalence Class Testing, Boundary Value Testing,

and Decision Table Testing are employed to ensure thorough coverage of
different scenarios and functionalities during blackbox testing.
5. Whitebox Testing:

Whitebox testing involves a more in-depth examination of the internal

structure, design, and coding of the software. Testers gain an
understanding of the source code, create specific test cases, and execute
them to verify the input-output flow within the system. This type
includes unit testing, often performed by programmers themselves, and
testing for memory leaks, which is crucial for applications with potential
performance issues.

Understanding and analyzing the source code, combined with creating

comprehensive test cases, form the core techniques of whitebox testing.
This approach allows for a detailed examination of the internal workings
of the software.

6. Advantages of Testing:

The testing phase offers several advantages in the software development

process. These include code optimization by discovering hidden errors,
 the automation of whitebox test cases for increased efficiency, thorough
testing with coverage of all possible code paths, and the ability to initiate
testing early in the SDLC, even before the graphical user interface (GUI)
is developed.

7. Conclusion:

The testing phase is identified as pivotal in ensuring that the software

meets specified requirements, functions as intended, and is free from
critical defects. The careful planning and execution of tests,
encompassing both blackbox and whitebox testing, significantly
contribute to the overall success of the software development process.
The ultimate goal is to deliver a high-quality software product that aligns
with customer expectations and provides a reliable solution for
end-users.

Resources:

https://www.betsol.com/blog/7-stages-of-sdlc-how-to-keep-developme
nt-teams-running/

https://www.knowledgehut.com/blog/software-testing/sdlc-in-software
-testing#the-six-phases-of-the-sdlc%C2%A0%C2%A0

Maintenance

Software maintenance is a continuous process that occurs throughout

the entire life cycle of the software system. Its primary goal is to modify
and update software application after delivery to correct errors and to
improve performance. Software is a model of the real world. When the
real world changes, the software require alteration wherever possible.

❑ Key Factors of Software Maintenance:

• Bug fixing.
• Setting up continuous monitoring.
• Upgrading the app to the newer version.
• Adding new features to the software.

Fig: Software Maintenance

❑ Types of Software Maintenance:

1. Corrective Maintenance: Corrective maintenance aims to
correct any remaining errors regardless of where they may cause
specifications, design, coding, testing, and documentation, etc.
2. Adaptive Maintenance: It contains modifying the software to
match changes in the ever-changing environment.
3. Preventive Maintenance: It is the process by which we prevent
our system from being obsolete.
4. Perfectible Maintenance: It defines improving processing
efficiency or performance or restricting the software to enhance
changeability. This may contain enhancement of existing system
functionality, improvement in computational efficiency, etc.