3 1.

2 Software Engineering Problem

The problem of Scale
A fundamental problem of software engineering is the problem of scale; development of a very
large system requires a very different set of methods compared to developing a small system. In
other words, the methods that are used for developing small systems generally do not scale up to
large systems.
An example will illustrate this point. Consider the problem of counting people in a room versus
taking a census of a country. Both are essentially counting problems. But the methods used for
counting people in a room (probably juts go row-wise or column-wise) will just not work when
taking a census. Different set of methods will have to be used for counting a census, and the
census problem will require considerably more management, organization, and validation, in
addition to counting.
Thought there is no universally acceptable definition of what is a small project and what is a
large project, one can use the definition used in the cost construction model (COCOMO) cost
model to get an idea of scale. According to this model, a project is small if its size in thousands
of delivered lines of code (KDLOC) is 2 KDLOC, intermediate if the size is 8 KLDOC, medium
if the size is 32 KDLOC, and large if the size is 128 KDLOC (or larger).
Cost, Schedule, and Quality
Like all engineering discipline, software engineering is driven almost by three major factors:
cost, schedule, and quality.
The cost of developing a system is the cost of the resources used for the system, which in the
case of software, are the manpower, hardware, software, and other support resources. Generally,
the manpower component is predominant, as software development is largely labor-intensive and
the cost of computing systems is now quite low. Hence, the cost is considered to be the total
number of person-months spent in the project.
Schedule is an important factor in many projects. Business trends are dictating that the time to
market of a product should be reduced; that is, the cycle time from concept to delivery should be
small. Any business with such a requirements will also require that the cycle time for building a
software needed by the business be small.
One of the major factors driving any production discipline is quality. IEEE defines Quality as
the degree to which a system, component, or process meets specified requirements, and customer
or user needs or expectations. We can view quality of a software as having three dimensions:
product operationdeals with quality factors such as correctness, reliability, efficiency and
usability.
product transitiondeals with quality factors like portability, reusability, and interoperability.
product revisiondeals with quality factors such as maintainability, flexibility, and testability.

The international standard on software product quality [55] suggests that software
quality comprises six main attributes, as shown in Figure 1.1.

Figure 1.1: Software quality attributes.

Reliability: the property that defines how well the software meets its requirements.
Efficiency a factor in all issues relating to the execution of software; it includes such
consideration as response time, memory requirements and throughput.
Usability the effort required to learn and operate the software properly, is an important property
that emphasizes the human aspect of the system.
Portability the effort required to transfer the software from one hardware configuration to
another.
Reusability the extent to which parts of the software can be reused in other related applications.
Interoperability the effort required to couple the system with other systems.
Maintainability the effort required to locate and fix errors in operating programs.
Flexibility the effort required to modify an operational program (perhaps to enhance its
functionality).
Testability the effort required to test to ensure that the systems or a module performs its intended
function.
The Problem of Consistency
Though high quality, low cost (or high productivity), and small cycle time are the primary
objectives of any project, for an organization there is another goal: consistency. An organization
involved in software development does not just want low cost and high quality for a project, but
it wants these consistently. In other words, a software development organization would like to
produce consistent quality with consistent productivity. Consistency of performance is an
important factor for any organization, it allows an organization to predict the outcome of a
project with reasonable accuracy, an to improve its processes to produce higher-quality products
and to improve its productivity.

SCALE AND CHANGE:

Most industrial-strength software systems tend to be large and complex, requiring tens
of thousands of lines of code. Sizes of some of the well-known software products are
given in Table 1.1. As can be expected, development of a large system requires a different
set of methods compared to developing a small system, as the methods that are used for
developing small systems often do not scale up to large systems. An example will
illustrate this point. Consider the problem of counting people in a room versus taking a
census of a country. Both are essentially counting problems. But the methods used for
counting people in a room will just not work when taking a census. A different set of
methods will have to be used for conducting a census, and the census problem will
require considerably more management, organization, and validation, in addition to
counting.
Table 1.1: Size in KLOC of some well-known products

Similarly, methods that one can use to develop programs of a few hundred lines cannot
be expected to work when software of a few hundred thousand lines needs to be
developed. A different set of methods must be used for developing large software.
Any software project involves the use of engineering and project management. In small
projects, informal methods for development and management can be used. However, for
large projects, both have to be much more rigorous, as illustrated in Figure 1.2. In other
words, to successfully execute a project, a proper method for engineering the system has
to be employed and the project has to be tightly managed to make sure that cost,
schedule, and quality are under control. Large scale is a key characteristic of the
problem domain and the solution approaches should employ tools and techniques that
have the ability to build large software systems. Change is another characteristic of the
problem domain which the approaches for development must handle. As the complete
set of requirements for the system is generally not known (often cannot be known at the
start of the project) or stated, as development proceeds and time passes, additional
requirements are identified, which need to be incorporated in the software
being developed. This need for changes requires that methods for development embrace
change and accommodate it efficiently. Change requests can be quite disruptive to a

project, and if not handled properly, can consume up to 30 to 40% of the development
cost [14].
As discussed above, software has to be changed even after it has been deployed. Though
traditionally changes in software during maintenance have been distinguished from
changes that occur while the development is taking place, these lines are blurring, as
fundamentally the changes in both of these scenarios are similarexisting source code
needs to be changed due to some changes in the requirements or due to some defects
that need to be removed.

Figure 1.2: The problem of scale.

Overall, as the world changes faster, software has to change faster, even while under
development. Changes in requirements are therefore a characteristic of the problem
domain. In todays world, approaches that cannot accept and accommodate change are
of little usethey can solve only those few problems that are change resistant.