1.

Introduction
Many firms rely on software to gain a competitive advantage, and it is gradually becoming an es-
sential component of corporate operations, products, and services. The excellence of software
products is increasingly seen as an imperative factor in success of a company (Veenendaal &
McMullan, 1997). Furthermore, software product quality is critical for instance, in some sensit-
ive structures - such as real-time systems, control systems, and so on - poor quality can result in
monetary damage, mission failing, eternal harm, or even fatalities. The quality of a software
product is determined by features such as maintainability, simplicity of eliminating and locating
flaws or errors, sufficient documentation, and the use of appropriate design patterns and design
principles. It should be simple to add new functionalities to software. The criteria that character-
ize software quality are as follows:

 Accessibility and Usability: Software that is useful for people should also provide several
accessibility types of control for people with disabilities.
 Adaptability and Extensibility: The ability of software quality management to incorpor-
ate, update, or remove functionality during software development without causing harm
to the existing system is known as adaptability. Extensibility can be considered a subset
of adaptability since it refers to the ability to add features without degrading the system.
 Correctness and Functionality: The congruence of software for quality management sys-
tems with actual requirements and specifications is referred as functionality or correct-
ness. When talking about broken software, quality management and control of the devel-
opment process are not significant.
 Readability and Maintainability: Maintainability focuses on adjustments related to fault
fixes and modest capacity improvements. Appropriate interface definitions, documenta-
tion, and self-recording code can all be used to facilitate it. The higher maintainability is
possible when more accurate and useful documentation is conserved.
 Testability: Testability determines how the product framework is tested, as well as how it
functions. It includes automated diagnostics carried out by the quality system manage-
ment software as well as specified deliverables.
 Portability: The system should be capable to continue using the same crucial software un-
der different conditions.
  Interoperability: The main focus of interoperability requirements is creating connections
with several other software frameworks or other hardware firmware.

 Security: No access points should be left open in the development and application of an
effective security plan. This might include authorization and verification procedures, or-
ganized assault insurances, data encryption, etc. Every potential security flaw should be
taken into consideration since otherwise, someone might exploit and wreck the program.

The following explains few of the software quality models

1.1 McCall’s Software Quality Model

This methodology, which was first employed in 1977, helps to bridge the gap between
developers and consumers by emphasizing the variables that reflect both groups' points of view.
Product revision, product transition, and product operations are the three categories in this
approach.

Figure 1: McCall’s Software Quality Model (Alkhateeb, 2014)

1.2 Boehm’s software Quality Model

Using a predetermined set of traits and measurements, this model is used to analyse the quality
of software. Generally, there are three types of models. High level, intermediate, and low
level are other names for primary, intermediate, and primitive features. This approach
emphasizes robustness, portability, usability, efficiency, clarity, testability, and modifiability.
 Figure 2: Boehm`s Software Quality Model (Alkhateeb, 2014)

1.3 FURPS Software Quality Model

Functional requirement (F), which is determined by input and anticipated output, makes up the
majority of this model. Another one that focuses on usability, reliability, performance, and
supportability is URPS. 

Figure 3: FURPS Software Quality Model (Alkhateeb, 2014)

1.4 IEEE Software Quality Model
The IEEE defines software quality as the extent to which a system, system component, or
process satisfies customer or user wants or expectations or the extent to which a system, system
component, or process satisfies stated criteria.

Figure 4: IEEE Software Quality Model (Tiwari & Chakraborty, 2015)

1.5 ISO 9126 Software Quality Model

It served as an international benchmark for assessing software quality, however ISO/IEC
25010:2011 does not replace it.

Figure 5: ISO 9126 Software Quality Model (Al-Obthani & Ameen, 2017)
2. Literature Review
2.1 Software Extensibility
Extensibility is a metric for a technology's ability to add new components and functionalities to
its current framework. When add-ons and plugins may enhance the functionality of a software
program, for instance, such program is said to be extensible. Programming languages that are
extensible can specify new features and add additional capabilities to them (Techopedia, 2021). It
is the software system's capacity to support extensions that add new functionality and features
while having the least possible negative effects on the present system (Breivold, Crnkovic, &
Eriksson, 2007). The capacity of a piece of software to expand in terms of enactment and
capability and to rapidly and effectively add fresh features when they are required (or financed)
without having to redesign the core infrastructure is known as extensibility (Papke, Brock, &
Graybeal, 2000). Then, Papke and colleagues add that extensibility also requires modifiability
and expandability. They define expandability as the capacity to add new types of scientific
equipment, and modifiability as the capacity to add functionality. The capacity for development
teams to expand a system's functionality or its quality attributes in known, planned ways by
using extension points that have been integrated into its design is referred to as extensibility.
Exploring extensibility from the perspectives of the system owner who wants to provide such
mechanisms and the analyst who wants to confirm that the extensibility features built into the
architecture are sufficient for achieving the desired results with reasonable cost, schedule, and
personnel implications and without compromising other crucial system components.
According to the aforementioned definitions, extensibility is the capacity to quickly include new
features, functions, or capabilities. They also stress that this addition should be made using a
design strategy in which the existing system's core is not altered to accommodate the extensions
but rather, certain design elements—extension mechanisms or extension points—provide this as
an organic capability that significantly reduces the time, risk, and effort of extending the system.
Some well-known examples are browser add-ons and plugins for Chrome, Firefox, and Edge;
audio editing software plug-ins for music processing; and IDE plugins that comprehend the
syntax of certain programming languages (Kazman, Echeverría, & Ivers, 2022).

2.2 Importance of Extensibility in software system

Because software is a "changing entity" that is created and managed by people, resulting in
continuing changes made in software definition and implementation, gullibility is at the core of
all software. Software is frequently created and deployed separately by unconnected parties.
Since components from external suppliers are unlikely to fit into a certain deployment model off-
the-rack, taking third-party users other than the designer into mind, adaptable software
components are required. From a base system, which has a similar software architecture or
occasionally significant portions of capability and execution but may be outfitted with diverse
components that call for an extendable base system, several software systems and product lines
are generated (Zenger, 2004).
A significant problem is creating independently extendable software systems. Two persons can
independently create additions for the system using an independently extensible system, and the
two extensions can be integrated without undergoing a global integrity check (Babar & Gorton,
2010).

2.3 Extensibility Sub-attributes

The sub-attributes of extensibility are as following:
 Modularity: Because the system is separated into distinct modules, changes made to one
module have less of an effect on the other modules. This takes into account factors in-
cluding the design size of classes, direct class coupling, the figure of hierarchies, the de-
gree of efficient abstraction, and coherence midst methods in a class (Dayanandan &
Vivekanandan, 2016).
 Reusability: It refers to a element's or piece of code's ability to be applied to alternative
system or module of the identical software artefact. To create a new application in the fu-
ture, this system's structure or part of its components are recycled (Mari & Eila, 2003).
 Analyzability: Analyzability refers to the ability to examine or test a product in order to
identify flaws, problems, reasons for failure, or components that require modification. It
is used to evaluate a product's efficacy and efficiency and discover how it affects other
modules or parts (Challa, Paul, Dada, & Srivastava, 2011).
 Modifiability: To assess a system's modifiability is to ascertain how it may be altered or
updated successfully and efficiently without introducing any new flaws or adversely af-
fecting the performance of the present system. Additionally, this is a quick and inexpens-
ive approach to make modifications.
  Testability: The capacity to quickly and easily reveal flaws is referred to as testability. It
establishes how simple it will be to test for errors or defects and if the product can be
tested successfully or efficiently in order to meet testing requirements.

2.4 Effects of Extensibility in software design

2.4.1 Design Principles and benefits of using them
The goal of software design principles is to offer ways to efficiently manage the complexity of
the design process. Effective complexity management may decrease the potential for introducing
errors during design, as well as the amount of work required for it.

Figure 6: Software Design Principles (JavaTpoint, 2020)

The principles of Software Design are listed below:

2.4.1.1 Problem Partitioning
When dealing with a tiny issue, we may address it all at once. However, when dealing with a
major issue, we must break it into smaller issues so that each issue can be handled
independently. The objective of software design is to segment the issue into discrete, manageable
parts and easy to grasp.  
2.4.1.2 Abstraction
A tool called an abstraction assists a designer to think about a constituent at an abstract level
without worrying about the implementation's underlying specifics. Both existing elements and
newly built components can benefit from abstraction.
2.4.1.3 Modularity
Modularity refers to the partition of software into independent modules with unique names and
addresses that are later merged to provide fully working software. It is the sole characteristic that
makes a program manageable on an intellectual level. Due to the abundance of reference
variables, control routes, global variables, etc., single big programs are challenging to
comprehend and interpret.
2.4.1.4 Top Down and Bottom Up Strategy
Top-down Approach: In this method, the primary components are first identified, and they are
subsequently broken down into more specific sub-components.
Bottom-up Approach: It starts with the smallest details and works its way up the hierarchy. In the
case of an established system, this strategy is appropriate.
Benefits of implementing design principle are pointed below:
 It enables several or independent programmers to work on complex projects.
 It promotes the development of routines that are often used so they may be stored in a
library and utilized by other applications.
 It streamlines the process of overlaying a big program into primary storage.
 It offers more benchmarks to gauge development.
 It offers a foundation for comprehensive testing, making testing easier.
 It helps in developing readable and well-designed software.
2.4.2 Impact of Design Principle on Extensibility
Smaller issues can be resolved more quickly and successfully than larger ones. To solve such
types of problems separately, we must break them down into smaller, more manageable parts.
This has a significant influence on a software's ability to be extended because when a problem is
split into smaller parts, only the smaller portion of the issue can be examined and resolved rather
than the entire problem. This idea aids in shrinking the issue so that adding new functionality to
the software is simple (Tjiparuro, 2004).
Data abstraction helps to establish the fundamentals of object-oriented design methodology.
Because it conceals the implementation's complexity, if abstraction is used properly during
system design, it will be simpler to maintain. Open/close concept, which states that a class or
object is open for extension but closed for alteration, is one of the principles that promote
extensibility (Gibson & Lynch, 1990).
In order to prevent changes in one module from having a significant negative impact on another,
software should be designed to be separated into smaller, independent modules. Due to the
numerous business logic and complicated nature of a large single program, it is difficult to
comprehend and extend. However, if the software is broken into modules, it will be simpler to
extend as it will be simpler to discover the issue in a specific module rather than a full software
(Soldani, Zimmermann, & Brogi, 2019).
The program should be created such that it is simple to build and modify it in the future. It will
be simpler for the developer to manage the magnitude and intricacy of the software if the
structure design is put into practice. This design concept specifies how the code ought to be
written and how the individual lines of code would interlock to create a suite. The program is
highly maintainable and can easily add features due to the top down and bottom up methodology
(Saiedian & Urban, 1997).
2.4.3 Design Patterns and benefits of using them
Design patterns are a broad answer to the often occurring problem in software design. A design
pattern is described as a solution template that may be applied in many contexts. Design patterns
can be categorized as following:
2.4.3.1 Behavioral Design Pattern
The design patterns that deal with effective communication and task delegation amongst objects
are known as behavioral design patterns. Because the objects are loosely connected in these
design patterns, communication between them is facilitated. To avoid hard coding and reliance,
the module or code in this is loosely connected.
2.4.3.2 Creational Design Pattern
The design pattern used to build items is known as a creational design pattern. The initialization
function of a class uses several design principles to make some decisions. Hard coding is not a
good programming approach as the essence of an object should frequently alter depending on the
nature of the program. By constructing objects in a generic and flexible manner, the creational
design pattern aids in issue solving.
2.4.3.3 Structural Design Pattern
The composition and structure of the class are designed using the structural design pattern. And
can be used to specify the software's general architecture. Its major objective is to make the
classes involved more functional without altering their makeup. A straightforward definition of
the connections between the structures is helpful. The inheritance and composition processes
between the classes are the main emphasis of design pattern.

2.4.4 Impact of Design Patterns on Extensibility

Due to the loose coupling and independence of the components, behavioural design patterns aid
in the expansion of the software. As a result, it is simple to add new features or modules and
simple to extend or update the program without having an adverse influence on other parts of the
system (Peng, Ampatzoglou, & Bhowmik, 2019). Due to its open-ended nature, creational design
patterns help software be more extensible. It also promotes modularity and reusability since new
objects may be introduced without altering the way the software behaves (Nahar & Sakib, 2016).
By utilizing inheritance and composition, which aid in module abstraction and reuse, structural
design patterns serve to increase the extensibility of software. In order to make the primary
component less difficult and more adaptable, it might be helpful to better divide it into smaller
supporting components (Bieman, Jain, & Yang, 2001).

2.5 Selective Design Principles and Design Patterns that improve

Extensibility
In the section above, the effects of design principles and patterns are described. For a better
comprehension of how design principles and patterns affect extensibility. We'll take into account
the design tenets of Keep it simple, stupid (KISS) and Don't repeat yourself (DRY). Decorator
and adapter design patterns will be considered similarly for design patterns.
2.5.1 Don’t repeat yourself (DRY)
According to this design principle, the creator of a particular software product shouldn't strive to
reuse or repeatedly utilize a capability or piece of code. It promotes or discourages the repetition
of data or code. It advises that the logic and code be separated into manageable, reusable parts
and used as needed. It also advises against writing lengthy methods, to break them up into new
ones if necessary, and to try to reuse existing ones. This idea results in less code, which is
excellent since it will minimize time and effort and improve the software's capacity to be
extended.
2.5.2 Keep it simple, stupid (KISS)
According to KISS, the developer must preserve the answer to the delinquent they're aiming to
address straightforward and divide it into manageable pieces. It specifies that a method should
have between 50 and 60 lines and should only address a single tiny issue. Due to the logical split,
discovering the problem will be simpler. The program will be easier to extensive because of the
aspect of logic and method breakdown.
2.5.3 Decorator Pattern
A design technique called this one is used to dynamically add new obligations to an object. To
add functionality to an object at runtime, composition is used rather than inheritance. Wrapper is
another name for this design. Compared to static inheritance, it offers more flexibility. It also
facilitates adding functionality from target classes rather than having to code it all inside the
object, which makes development simpler. By applying the previously mentioned factors, such
as utilising composition relatively than inheritance, which will assist to minimize the intricacy
and the size of the code, this will boost the extensibility of the product.
2.5.4 Adapter pattern
This design pattern belongs to the structural category and is used to change a class's interface
into a different interface that the client would anticipate. It makes possible for two interfaces to
cooperate that would not have been able to due to interface incompatibility. Through reusability
and flexibility, it aids in enhancing the software's ability to be extensive and makes simple to add
additional functionality or features.

2.6 Techniques of Measuring Extensibility

For assessing extensibility, there are primarily 10 object-oriented measures. The impact of a
design pattern and a design principle may be evaluated using these measures. Below is a list of
them.
i. DIT: Depth of inheritance tree is abbreviated as DIT. To determine the depth of the inher-
itance, the DIT is utilized. Root class's DIT level is 0 and its range value is [0, +1).
ii. NOC: It stands for No of Children. It is measured by counting how many subclasses each
class has. The value of range is [0, +1).
iii. MPC: The quantity of send statements defined in the class determines the message
passing coupling, or MPC. The value of range is [0, +1).
iv. RFC: The total number of local methods and the number of methods called by the total
number of local methods in the class define the response for a class or RFC. The value of
range is [0, +1).
v. LCOM: The quantity of local methods in the class that don't communicate with one an-
other is what determines if there is a lack of cohesion of method, or LCOM. The value of
range is [0, +1).
vi. DAC: The quantity of abstract data types that are declared in a class determines data ab-
straction coupling, or DAC. The value of range is [0, +1).
vii. WMPC: The total cyclomatic complexity of all local methods in the class determines the
weighted method per class, or WMPC. The value of range is [0, +1).
viii. NOM: The quantity of local methods declared in a class determines the number of meth-
ods, or NOM. The value of range is [0, +1).
ix. SIZE1: The number of semicolons in the class determines the Line of Code. The value of
range is [0, +1).
x. SIZE2: The entire number of local methods in the class multiplied by the total number of
attributes results in the number of properties. The value of range is [0, +1). (Gautama,
Rochimah, & Akbar, 2019)
3. Conclusion
The capacity of a software-intensive system to add features, capabilities, and support for
important quality traits over time is known as extensibility, and this study defines it as such.
Based on an understanding of architectural mechanisms and their features, the study
is concentrated on assessing the unique obstacles of producing extensible systems and analysing
for extensibility. Software design patterns and design principles have a significant influence on
extensibility. Enhancing performance, and adding new features are all examples of extensibility.
It has been discovered that taking extensibility into account while building software will have a
significant influence on the product's final outcome. The reusability of the code will rise if design
patterns and design principles are applied appropriately. These guidelines and patterns are
centred on cutting down on the expense and duration of creating software or extending it. The
program should be simple to modify so that adding new features or functions will be simple. The
bug repairs should be carried out in a way that prevents the occurrence of further bugs or flaws.
1 References
Alkhateeb, J. (2014). cost qualty.
Al-Obthani, F., & Ameen, A. (2017). Toward Proposing SMART-Government Maturity Model:
Best Practices, International Standards, and Six-Sigma Approach.
Babar, M., & Gorton, I. (2010). Independently Extensible Contexts. Software Architecture: 4th
European Conference (p. 327). Copenhagen, Denmark: Springer.
Bieman, J. M., Jain, D., & Yang, H. J. (2001). OO Design Patterns, Design Structure, and
Program Changes: An Industrial Case Study . Florence, Italy: IEEE Comput. Soc IEEE
International Conference on Software Maintenance. ICSM 2001 .
Breivold, H. P., Crnkovic, I., & Eriksson, P. (2007). Evaluating Software Evolvability. 7th
Conference on Software Engineering Research and Practice (pp. 96–103). Sweden: IT
University of Göteborg.
Challa, J. S., Paul, A., Dada, Y., & Srivastava, D. P. (2011). Integrated Software Quality
Evaluation: A Fuzzy Multi-Criteria Approach. Journal of Information Processing
Systems, 7(3), 473-518.
Dayanandan, U., & Vivekanandan, K. (2016). An Empirical Evaluation model for Software
Architecture Maintainability for Object oriented Design. Pondicherry, India: ACM Press
the International Conference.
Gautama, I. M., Rochimah, S., & Akbar, R. J. (2019). Assessing the Impact of Enterprise
Software Design Patterns on Maintainability: A Case Study. Bali, Indonesia: st
International Conference on Cybernetics and Intelligent System (ICORIS).
Gibson, J. P., & Lynch, J. (1990). Applying formal object-oriented design principles to Smalltalk-
80. Information and Software Technology, 32(5), 12-24.
JavaTpoint. (2020). JavaTpoint. Retrieved from Software Design Principles: Javatpoint:
https://www.javatpoint.com/software-engineering-software-design-principles
Kazman, R., Echeverría, S., & Ivers, J. (2022). Extensibility. Carnegie Mellon University.
Mari, M., & Eila, N. (2003). The Impact of Maintainability on Component-based Software
Systems . Belek-Antalya, Turkey : Proceedings of the 29th EUROMICRO Conference.
Nahar, N., & Sakib, K. (2016). ACDPR: A Recommendation System for the Creational Design
Patterns Using Anti-patterns. Suita, Osaka, Japan: IEEE 2016 IEEE 23rd International
Conference on Software Analysis, Evolution, and Reengineering (SANER).
Papke, B., Brock, D., & Graybeal, J. (2000). Extensible and Flexible Software Architecture for
the SO-FIA Mission Controls and Communications System. SPIE 4014, Airborne Tele-
scope Systems. Society of Photo-optical Instrumentation Engineers.
Peng, X., Ampatzoglou, A., & Bhowmik, T. (2019). Behavioral Evolution of Design Patterns:
Understanding Software Reuse Through the Evolution of Pattern Behavior. Cincinnati,
OH, USA: (18th International Conference on Software and Systems Reuse.
Saiedian, H., & Urban, J. J. (1997). A case study to demonstrate the impact of quality design
principles when restructuring existing software. Software Quality Journal, 6(4).
Soldani, D. N., Zimmermann, O., & Brogi, A. (2019). Design principles, architectural smells and
refactorings for microservices: a multivocal review. SICS Software-Intensive Cyber-
Physical Systems.
Techopedia. (2021). Techopedia. Retrieved from Techopedia: Extensible:
https://www.techopedia.com/definition/7107/extensible
Tiwari, A., & Chakraborty, P. S. (2015). Software Component Quality Characteristics Model for
Component Based Software Engineering. 2015 IEEE International Conference on
Computational Intelligence and Communication Technology. CICT 2015.
Tjiparuro, Z. (2004). Review of maintainability design principles and their application to
conceptual design. ARCHIVE Proceedings of the Institution of Mechanical Engineers
Part E Journal of Process Mechanical Engineering , 105-113.
Veenendaal, E. V., & McMullan, J. (1997). Achieving Software Product Quality. Amsterdam, The
Netherlands: UTN Publishers.
Zenger, M. (2004). Programming Language Abstractions for Extensible Software Components.
Lausanne, Switzerland: Swiss Federal Institute of Technology.