Information Technology Reference
In-Depth Information
of building software is such that at both the idea and the execution levels,
one needs to be creative.
In this topic we have drawn, primarily, from three areas: (1) systems
science, (2) software engineering, and (3) project management. As we are
building systems, some knowledge and understanding of systems science
concepts is essential for the designer and the architect as well as for the
manager and the customer. Software engineering is the application of
engineering principles to the design and production of software — its
relevance is more obvious, although its use is not as widespread as it
should be. Project (and general) management ideas are essential for any
delivery in project, product, or consulting businesses.
Certain problems recur across domains, times, and technologies. These
are small and large issues that often cause confusion in communications,
lack a satisfactory understanding or solution, and need some ground
definitions to make things work smoothly. In fact, over the years, these
problem areas have not changed very much. They continue to be esti-
mation, requirements, technology selection, build versus buy, change
control management, staffing, and some aspects of release management.
At a more fundamental level, software creation is very people intensive,
depends on a core set of individuals, is substantially manual, and is difficult
to specify with the engineering rigor seen in other industries. We have
touched on most of these long-standing problem areas, offering what we
hope are some practical guidelines to improve the situation for some of
these.
Many of the problems arise due to definitional issues. Two companies
rarely mean the same thing when they refer to the “design documents.”
Sometimes common terms such as “configuration” and “customization,”
or “migration” and “porting,” may not have acceptable definitions across
groups. This is not to say that efforts have not been made by the standards
committees to standardize definitions. However, the net situation is that
a lot of communication problems arise due to differing definitions and
consequent expectations. We have therefore spent some effort in probing
how certain terms are used or understood in the industry.
If there is one suggestion we would like to give designers and architects
in this conclusion chapter it would be to pay attention to non-software
domains. Good systems design draws on a large body of topics and
experience. There are problems that professionals encounter again and
again in different guises in areas far away from software, fields such as
aviation or medicine or civil engineering or the military. Many of these
problems — how to secure one's assets, communicate properly, specify
what one wants done, track changes, store records — have had good
practical solutions in these other domains. However, many designers do
