Information Technology Reference
In-Depth Information
Concurrency issues may cause delays that affect the overall perfor-
mance of the system.
On the other hand, distributed systems are more difficult to assess in
entirety, and difficult to test once they are developed.
In software industry parlance, “complexity” refers to the difficulty of
the problem being solved by software. Most methods for determining
complexity are specification based and focus on the “size” aspect like
Function Point Analysis (FPA) and those based on Use Cases. Intuition
may be useful for determining software complexity based on the com-
plexity of the tasks required to create the software. The use of task
complexity and cost models is also encouraged. Software process literature
and commercial software management tools have suggested that such cost
models can be combined with historical data on development times to
predict the development times of future projects.
It has been proven that program size and complexity cannot be
determined
a priori
. Similarly, well understood is that the productivity of
intelligent developers, and hence development time, cannot be adequately
predicted. There are, however, vectors that can be used to judge the
relative complexity of a system that is being designed and developed.
They include:
Organization complexity
. This is based on the perceived maturity
of the business and the maturity of the processes being used.
Domain complexity
. Another good indicator is the “domain” in
which the system falls. Some domains are inherently complex, such
as those dealing with financial and economic markets, or sched-
uling and logistics. Software systems for such domains usually will
be complex.
Physical and geographical constraints
. While these may not be
evident, multi-site development, or development where physical
access to the customer organization is not available, makes the
system development complex. Software for aviation, or offshore
oil exploration, could be good examples of this category. These
days, offshore development adds its own kind of complexity.
Summary
Systems science is a vast field. This chapter touched only on a few thinkers
who are mostly talking about control systems — Ashby, Forrester, Church-
man, and Beer. Their ideas help if we subscribe to the viewpoint that
information systems are a form of control systems, controlling actions and
