Page 110 - DCAP405_SOFTWARE_ENGINEERING

Unit 7: Software Engineering Practice

Working out an automated solution to a problem is thus a learning experience for both software Notes
developers and their clients. Software developers are learning the domain that the clients work
in. They are also learning the values of the client: what form of data presentation is most useful
to the client, what kinds of data are crucial and require special protective measures.
The clients are learning to see the range of possible solutions that software technology can
provide. They are also learning to evaluate the possible solutions with regard to their effectiveness
in meeting the clients needs.

If the problem to be solved is complex then it is not reasonable to assume that the best solution
will be worked out in a short period of time. The clients do, however, want a timely solution. In
most cases, they are not willing to wait until the perfect solution is worked out. They want a
reasonable solution soon; perfection can come later. To develop a timely solution, software
developers need to know the requirements: how the software should behave. The principle of
anticipation of change recognizes the complexity of the learning process for both software
developers and their clients. Preliminary requirements need to be worked out early, but it
should be possible to make changes in the requirements as learning progresses.
Coupling is a major obstacle to change. If two components are strongly coupled then it is likely
that changing one will not work without changing the other.
Cohesiveness has a positive effect on ease of change.

Did u know? Is cohesive components are easier to reuse?
Yes, cohesive components are easier to reuse when requirements change. If a component
has several tasks rolled up into one package, it is likely that it will need to be split up when
changes are made.

Generality

The principle of generality is closely related to the principle of anticipation of change. It is
important in designing software that is free from unnatural restrictions and limitations. One
excellent example of an unnatural restriction or limitation is the use of two digit year numbers,
which has led to the “year 2000” problem: software that will garble record keeping at the turn of
the century. Although the two-digit limitation appeared reasonable at the time, good software
frequently survives beyond its expected lifetime.
For another example where the principle of generality applies, consider a customer who is
converting business practices into automated software. They are often trying to satisfy general
needs, but they understand and present their needs in terms of their current practices. As they
become more familiar with the possibilities of automated solutions, they begin seeing what
they need, rather than what they are currently doing to satisfy those needs. This distinction is
similar to the distinction in the principle of abstraction, but its effects are felt earlier in the
software development process.

Incremental Development

Fowler and Scott give a brief, but thoughtful, description of an incremental software development
process. In this process, you build the software in small increments; for example, adding one use
case at a time.
An incremental software development process simplifies verification. If you develop software
by adding small increments of functionality then, for verification, you only need to deal with

LOVELY PROFESSIONAL UNIVERSITY 103