Page 131 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes only software design notation that can be called widespread is PDL, and what does that look
like.
This says that the collective subconscious of the software industry instinctively knows that
improvements in programming techniques and real world programming languages in particular
are overwhelmingly more important than anything else in the software business. It also says
that programmers are interested in design. When more expressive programming languages
become available, software developers will adopt them.

Also consider how the process of software development is changing. Once upon a time we had
the waterfall process. Now we talk of spiral development and rapid prototyping. While such
techniques are often justified with terms like “risk abatement” and “shortened product delivery
times”, they are really just excuses to start coding earlier in the life cycle. This is good. This
allows the build/test cycle to start validating and refining the design earlier.

Notes It also means that it is more likely that the software designers that developed the
top level design are still around to do the detailed design.

Engineering is more about how you do the process than it is about what the final product looks
like. We in the software business are close to being engineers, but we need a couple of perceptual
changes. Programming and the build/test cycle are central to the process of engineering software.
We need to manage them as such. The economics of the build/test cycle, plus the fact that a
software system can represent practically anything, makes it very unlikely that we will find any
general purpose methods for validating a software design. We can improve this process, but we
can not escape it.

One final point: the goal of any engineering design project is the production of some
documentation. Obviously, the actual design documents are the most important, but they are
not the only ones that must be produced. Someone is eventually expected to use the software. It
is also likely that the system will have to be modified and enhanced at a later time. This means
that auxiliary documentation is as important for a software project as it is for a hardware project.
Ignoring for now users manuals, installation guides, and other documents not directly associated
with the design process, there are still two important needs that must be solved with auxiliary
design documents.

The first use of auxiliary documentation is to capture important information from the problem
space that did not make it directly into the design. Software design involves inventing software
concepts to model concepts in a problem space. This process requires developing an understanding
of the problem space concepts. Usually this understanding will include information that does
not directly end up being modeled in the software space, but which nevertheless helped the
designer determine what the essential concepts were, and how best to model them. This
information should be captured somewhere in case the model needs to be changed at a later
time.
The second important need for auxiliary documentation is to document those aspects of the
design that are difficult to extract directly from the design itself. These can include both high
level and low level aspects. Many of these aspects are best depicted graphically. This makes
them hard to include as comments in the source code. This is not an argument for a graphical
software design notation instead of a programming language. This is no different from the need
for textual descriptions to accompany the graphical design documents of hardware disciplines.
Never forget that the source code determines what the actual design really is, not the auxiliary
documentation. Ideally, software tools would be available that post processed a source code
design and generated the auxiliary documentation. That may be too much to expect. The next

124 LOVELY PROFESSIONAL UNIVERSITY