Page |1
Issues In The Design Of Large Software
Abstract
The purpose of this term paper is to give the
description of Issues in the design of large
software. Below I have discussed about its
brief introduction and main topics, then
about the main topic, its features etc and
References from where I get the material to
complete my term paper.
Keywords
Production , design model, intensive ,decision
intregration, architecture, documentation,
modularity
I. Introduction
Today, in high energy physics, software is
generally in a mess. That is to say, most
experimental groups, especially the new large
detector groups, are having a difficult time
developing and managing their software. As
each new large detector comes on line, the
management the software effort seems to be
getting more difficult. This seems to lead to a
conclusion that for Superconducting Super
Collider (SSC) we will have a major software
problem. Although not
explicitly stated, there seems to be many in our
community that believe the reason that software
will be a problem at the SSC is that “we need to
develop large (200-500K lines of FORTRAN)
complex code for the detector with 400
physicists at 50 institutions.”
We will first explore if the above reasoning is
fact or fiction. First of all, lets look at the size
and complexity of the code for a very large
detector. The size and complexity of the code
should scale with some aspects of the detector.
If we can find the scaling laws, we should be
able to estimate the size of the problem for an
SSC detector by extrapolation from our current
detectors. The size and complexity of the code
should scale, for example, with number of
different kinds of detector elements in the
detector. This is because each detector type will
need its own pattern recognition code and there
will be some code that links tracks between the
detector elements. For an SSC detector,
however, there is no reason that there are more
different kinds of detector elements than a large
Tevatron, LEP, or SLC detector. Therefore, this
scaling law would say that the software for an
SSC detector would not be more difficult.
Another scaling law is the size and complexity
of the code scales with the number of
boundaries in the detector.
This is because each
irregular boundary takes additional code to
calculate the position of the boundaries, cross
the boundary, and in general, makes for a lot of
exceptional case handling in the code. There is
no reason that an SSC detector should have
more boundaries than existing large detectors,
so the software problem for an SSC detector
should not be more complex because of this
scaling law. The size and complexity of the
code should scale with the track density due to
confusion a pattern recognition program must
try to resolve. However, these problems are in a
limited area of the detector code and the effect
is not very strong. Thus we would not expect a
great deal of size and complexity from this
effect alone.

II. Literature Survey
2.1 Why Writing Large Programs
Is Hard
• Customer’s needs are hard
discover and record
• Customer’s needs change with time
• The larger the system the more
potential interactions among
components
• Several people must cooperate
communication complexity among
people can grow.
2.2 Challenge In Large Projects
• Developing large/complex software
application is very challenging
1) Effort intensive
2) High cost
3) Long development time
4) Changing needs for users
5) High risk of failure, user acceptance,
performance, maintainability
6) Quite different from one-time programs
where author and user are same.
2.3 Reasons For Failure
a) Schedule slippage
b) Cost over-runs
c) Does not solve user’s problem
d) Poor quality of software
e) Poor maintainability
f) Ad hoc software development results in
such problems
Page |2
• No planning of development
work (e.g. no milestones
defined)
• Deliverables to user not
identified
to • Poor understanding of user
requirements
• No control or review
• Technical incompetence of
developers
• Poor understanding of cost and
effort by both developer and
user
III. Previous work
III.1 The Design Process Of Large
Software
The design process of large software is the task
of creating or generating design artefacts and
subsequently evaluating, refining, integrating,
and modifying these artefacts until the result
satisfies the requirements of the problem
definition. In essence, the design process is the
task of mapping problem requirements into
design solutions.
The design process should be guided by a
productive, economic, and controllable
methodology that will ensure a high quality
product.
The reasons why the design problem is
important are fairly obvious. Good design
decisions made early have a positive effect on
the quality of the ultimate product as well as
the efficiency of the development process. Poor
design decisions play havoc with the quality,
efficiency and cost of the development process
and the design products.

Fig 1(a)
Design is characterized by a necessity to deal
simultaneously with a large number of diverse
constraints that are highly intertwined. In
general the design problem is intractable.
However, we believe that the combination of
the restricted domain of VLIS development, the
simplicity of its algorithmic requirements, and
the knowledge accumulated from the
experience of building a large number of VLIS
provides good insights into the available
expertise, known solutions and alternatives.
Our intention is to exploit the natural structure
of the domain in ways that allow us to reduce
the complexity of the problem to manageable
levels. We cite several issues that help focus
some of the design process concerns.
3.1.1 The Paradigm Problem
The paradigm problem refers to the failure to
recognize and develop a manageable,
productive, economically feasible process
model for SE. Much attention has been focused
on the development of new software
engineering paradigms [3, 41 but no results
have proven completely satisfactory for VLIS
development. Any successful model must deal
with the interdependent facets of making design
decisions while recognizing the need for
adequate leverage and project management.
Bridging the Functional to Technical Gap: A
significant portion of the design process occurs
during the creative process of translating the
business problem description to a high level
systems design. Presently techniques at this
Page |3
level of the development process are not
adequately understood. The result is an
inability to adequately map problem
requirements to technical solutions. No good
language” has been developed in which the
requirements of the problem can be expressed
and ultimately transformed to technical
solutions.
Fig 1(b)
3.1.2 Design Evaluation problem
In order to make good design decisions, one
must have the ability to assess the validity of a
particular design decision or weigh the relative
merits of competing design alternatives. The
lack of evaluation ability leads to inadequacies
in assessing the impacts of a design decision on
all levels of the design process. Under the
umbrella title of evaluation we include testing,
validation, verification and, as a specific
instance, prototyping.
3.1.3 The Representation Problem
The representation problem is a fundamental
requirement for advancement in each of the
areas mentioned above. The issue is the ability
to express, manipulate and make inferences
about design objects and processes. In current
practice, major development takes place at very
low levels of design for at least two reasons.
First, current methods of software engineering
encourage designers to think in terms of low
 Page |4

level issues such as databases, data structures,
performance measures, screens, and interfaces
because low level representations are the only
mechanisms that provide feasibility measures
and evaluation feedback. As a result designers
move quickly to lower levels without
adequately investigating alternative early
design decisions. Second, the nature of the
business is that cost pressures often do not
allow for an adequate investigation of high
level design alternatives. As a result projects
designs are often inadequate and brittle.
of the code should not scale with the number of
channels; not to first order. Only the size of the
arrays should grow, not the size of the code.
The same could be said about the number of
tracks in the detector, except for the second
order effect that with a large number of tracks
one expects to have areas of higher track
density. Nor should the change in energy scale
of the particles in the detector have a strong
effect on the code. And certainly, the total
amount of iron in the detector doesn’t have
effect on the size and complexity of the code.

3.1.4 Large Scale Integration

IV. Methodology
The problem of large scale integration is
concerned with the understanding, use and 4.1 Various Issues In
exploitation of the functionalities, standards, Developing Large Software
protocols, and communication interfaces of a
Systems
Heterogeneous set of technologies in
developing large systems. Integration of
a) A single software developer may not be
component systems differing both in
able to do the job in the required
functionality and platform is important because
amount of Time, developers have to
systems within the commercial environment
work as a team
can no longer be treated as isolated entities. In
fact there is great disincentive to do so. The
b) The team members have to
large scale integration problem points out the
communicate and interact with each
need to understand the interrelationships of all
other
systems within a company.

c) Specification of a large software

Efforts need to be concentrated on large scale
product is more complicated than just
design at the enterprise, or companywide, level
saying “write a
before detail design and implementation of a
d) Program that sorts a set of integers”
particular component is undertaken.
Understanding the enterprise level connectivity
e) For a large software project one has to
and integration issues is extremely important
carefully think about the design of the
and will have tremendous impact upon the
software before starting to write code
design process.

f) A team of programmers have to write

So far, we have seen areas where an SSC
different parts of the code that will work
detector is not necessarily very different from
together
our present day detectors. However, there is
still a feeling shared by many that the large
g) How do we make sure that the software
physical size of an SSC detector is going to
does what it is supposed to do?
lead to a larger software code problem. For
example, an SSC detector will have many more
detector channels. But the size and complexity
 Page |5

h) What happens if we need to add a new c. NASA’s Mars Sojourner software

feature to the software deadlocked. Cause: Priority inversion.
Priority inversion occurs when a
process that has higher priority is
waiting for a process for a lower
priority to release a lock. However,
since the process holding the lock has
lower priority it does not get scheduled
and the system deadlocks.

4.3 Second Order Effects

Fig 1(c)
There are other effects that I would consider
4.2 Software Crisis second order effects. With each new detector,
for example, one frequently tries to push the
state of the art in detector resolution, or two
Large Software Systems Often: Do not provide
particle separations, or both. This will lead to
the desired functionality, Take too long to
more code and perhaps somewhat complex
build, Cost too much to build, Require too
code. However, since this code should be
much time, space, or other resources to
localized in the module that does pattern
run,cannot evolve to meet changing needs.
recognition for the sub detector; I consider it a
second order effect. Also the large number of
(i) For every 6 large software projects that
channels will require some form of database
become operational, 2 of them are
management system. for calibration and
cancelled
alignment constants. But again, if well planned
and modular, it should not lead to overall
(ii) On the average software development
impression of large and complex code.
projects overshoot their schedule by
half

(iii) 3 quarters of the large systems do not

provide required functionality

Examples:

a. Because of software related problems in

its automated baggage-handling system,
opening of Denver’s big, state-of-the
art, international airport was delayed
almost a year in 1993

b. NASA’s Mars Climate Orbiter was Fig 1(d)

lost in 1999 ,Cause: failed translation of 4.4 Causes Of Our Software Problems
English units to metric units
I do not profess to understand all the causes to
the software problem. Nevertheless, I am

willing to hazard some reasoned guesses.
Amongst these, I do not pretend to understand
the relative importance between them. Amongst
the large collaborations, in fact, their relative
importance may be very different.
• The first cause is that some people don’t
take software seriously enough, early
enough.
• The second is that some people take
software too seriously, too soon. Let’s
explore the first a bit. Some people are
too busy prototyping, building, testing,
and installing the hardware to be
“bothered” with software. They may
think that they can always fix the
software later. It is likely that some of
these people are the real experts on how
the detector works, thus the ones that
will ultimately write the code that
works. And yet, in the early stages of
building the detector, how much time
do these experts spend in monitoring or
controlling what software is being
written by others. And who are these
others? They are probably younger, less
experienced physicists who could very
well use some guidance from those who
have been through this kind of software
development before.
• This kind of situation can lead to large
important parts of the code being re-
written at the last minute perhaps, even
perhaps, after the first data has been
taken. Another cause is that some
people take software too seriously too
soon.
• It is as if people believe that decisions
can be made at this early stage of
software development that are really
going to last for five or more years.
Page |6
• Hardware people know they can not
make final decisions on design or
construction without making a
prototype first. But for software people,
the word “prototyping” isn’t used very
often. Frequently, when software is
taken too seriously
• There may be a lose of contact with
reality and the end-user for whom the
system is presumably designed.
• There may be also a lack of cost-
effectiveness analysis of the gadgets,
where the real costs of a gadget include
not only the writing the code to support
it, but also the integration, maintenance,
documenting and training of users.
• One problem with programmers, in
general, is that they seem to be rugged
individualist, and yet there is little
constraint on them.
V. Future Work
The question is, then, what do we need to do
and what tools to we need in order to keep our
software efforts from being such a mess?
I don’t pretend to know all the answers, but will
mention three possibilities below.
First, a large software effort needs a good
design. Good design comes with the proper
modularity, which may not be as simple as
division by detector type. Between the
modules, there should be well designed
interfaces,
A good design of a large project cannot be laid
down correctly from the start; a certain amount
of prototyping needs to be done. When a
software team knows it is building a prototype,

the whole attitude of approaching decisions
changes to the better.
That is, final decisions
are not being made, only decisions to test the
prototype. Second, the program has to have a
good architecture and a good set of tools. These
items are good if they are intuitive to use. The
sign of bad architecture and tools is when users
complain of poor documentation or too much
documentation.
The architecture and tools should not be overly
constraining or overly protective. It is better to
allow the user to make mistakes, provided he
can find them easy, than to have a protective
system which the user can’t figure out how to
use.
There should be some uniformity of style
across levels and not too many levels to learn.
By a level I mean,
Third, as in any large project one needs to have
progress and quality controls. Unlike hardware,
it is much harder to quantify progress or quality
with software. Although difficult, it is not
impossible to invent some measurement tools,
with which a software manager can judge the
rate of progress.
These tools may not be computer based. At the
very least, peer review of software modules
should be done systematically to judge progress
and quality.
VI. Conclusion
It is generally felt in our community, that with
each generation large detector, software is
becoming a bigger and bigger problem. If we
extrapolate this trend to the SSC era, software
would be a very big problem indeed. Many
people are inventing or using new tools to
attack the software problem, but some of these
tools are like aspirins, they alleviate some pain
but don’t cure the disease. We need to
Page |7
understand the real causes of our current
problems, before we can find the real solutions.
The intent of this paper is to discuss the
implications that the process of developing very
large software or very large information
systems (VLIS) has on the approach to the
software engineering problem. Although the
same SE problems are found in many domains,
they take on a unique set of constraints when
considered in the context of developing VLIS.
It is our position that possibilities for enhancing
the software development process are functions
of the domain in which one participates.
VII. Reference
[1] www.cs.ucsb.edu/~kemm/courses/cs172
/Intro.pdf
[2] Pamela Zave, “An Operational
Approach to Requirements
Specification for Embedded Systems,”
in New Paradigms for Software
Development, (ed. William W. Agresti),
IEEE Society, Los Angeles, Ca., 1986,
1.59 -178.
[3] Bill Curtis, Herb Krasner, Vincent
Shen, & Neil Iscoe, “On Building
Software Process Models Under the
Lamppost,” in the Proceedings of the
9th International Conference on
Software Engineering, Monterrey, CA.,
1987, 96-103.
[4] Barry W. Boehm, “A Spiral Model of
Software Development and
Enhancement,” IEEE Computer, May
1988,61- 72.
[5] Cordell Green, David Luckham, Robert
Balzer, Thomas Cheatham and Charles
Rich. ‘Report on a Knowledge-Based
Software,
Page |8