PRODUCT CUSTOMIZATION AND VERSION MANAGEMENT AN OVERVIEW

PRODUCT
CUSTOMIZATION AND VERSION MANAGEMENT AN OVERVIEW

In the Real World, web apps can
get complicated. A popular web site can get hundreds of thousands of hits per
hour. To handle this kind of volume, most big web sites create complex hardware
architectures in which the software and data is distributed across many
machines. This complexity can be handled through the non-functional parameters
of the system.

The most important and fore
fronted job for a web application solution is to provide the end user / clients
with a reliable, useful, and correct experience. In other words, the designed
solution must satisfy the functional requirements such as “select an item from
the menu” or “add item to the shopping cart”. Once we have made sure that the
system supports the use cases, we will most likely be faced with another set of
requirements—requirements for what happens behind the scenes, i.e. the
non-functional requirements.

Here we discuss some of the most
important non-functional requirement we are likely to face during the software
development cycle: Performance, Modularity, Flexibility,
Maintainability, and Extensibility

Performance: If our website is too slow, we will (obviously) lose users. So we need
to circumvent this situation which could help an individual user experience
faster response time so that system support a greater
number of simultaneous users (throughput).

A common architecture we are
probably quite familiar with is configuring the hardware in layers or “tiers”
of functionality. Adding more computers to a tier is known as horizontal
scaling, and is considered one of the best ways to increase throughput.

Modularity: In order for different pieces of our application to run on
different boxes at the same time, our software is going to have to be
modular... and modular in just the right ways.

Flexibility: We need to change our system without going through some big
development cycle. We might need to swap in the “limited time, special offer”
components for a big sale. We might find a bug in a new component and need to
swap in the older component temporarily. So, we need our system to be flexible.

Maintainability: Sometimes we might need to change database vendors, and update our
system quickly. We might get obscure bugs and need to track them down ASAP. The
admins might decide to restructure the company’s naming service, and we will
have to adjust—right now! We need our system to be maintainable.

Extensibility: The guys over in marketing might need a new feature to land that
big client. Our users might demand that we support a brand new feature that
their browsers have. So, our system had better be extensible!