Page 108 - DCAP405_SOFTWARE_ENGINEERING

Unit 7: Software Engineering Practice

some of our customers. In this case the project objectives/goals change quite drastically. Now Notes
the tool becomes a source of revenue, and the impact of it suddenly stopping working is
significantly less acceptable. Also as we hold focus groups, and gather feedback from customers
and potential customers there’s a pretty good chance the feature-set and complexity will have to
grow considerably from when we were using it only internally for planning a small handful of
events for one company.
In this fictional scenario we would expect the target on the SEMS to jump to the far right.
Depending on how we implemented the previous release we may be able to refactor and evolve
the existing codebase to introduce a more layered architecture, a robust set of automated tests,
introduce a proper ORM and IoC container, etc. More likely in this example the jump along the
SEMS would be so large we’d probably end up scrapping the current code and re-writing.
Although, if it was a slow phased roll-out to only a handful of customers, where we collected
feedback, made some tweaks, and then rolled out to a couple more customers, we may be able
to slowly refactor and evolve the code over time rather than tossing it out and starting from
scratch.

The key point we are trying to get across is not that you should be throwing out your code and
starting from scratch all the time. But rather that you should be aware of when and how the
context and objectives around a project changes and periodically reassess where the project
currently falls on the SEMS and whether that needs to be adjusted based on changing needs.

Notes There is also the idea of “spectrum decay”. Since our industry is rapidly evolving,
what we currently accept as mature software engineering practices (the right end of the
SEMS) probably won’t be the same 3 years from now. If you have a project that you were
to assess at somewhere around the 80% mark on the SEMS today, but don’t touch the code
for 3 years and come back and reassess its position, it will almost certainly have changed
since the right end of the SEMS will have moved farther out (maybe the project is now
only around 60% due to decay).

7.2 Core Principles

Separation of Concerns

Separation of concerns is recognition of the need for human beings to work within a limited
context. The human mind is limited to dealing with approximately seven units of data at a time.
A unit is something that a person has learned to deal with as a whole – a single abstraction or
concept. Although human capacity for forming abstractions appears to be unlimited, it takes
time and repetitive use for an abstraction to become a useful tool; that is, to serve as a unit.

When specifying the behavior of a data structure component, there are often two concerns that
need to be dealt with: Basic functionality and support for data integrity. A data structure component
is often easier to use if these two concerns are divided as much as possible into separate sets of
client functions. It is certainly helpful to clients if the client documentation treats the two concerns
separately. Further, implementation documentation and algorithm descriptions can profit from
separate treatment of basic algorithms and modifications for data integrity and exception
handling.

There is another reason for the importance of separation of concerns. Software engineers must
deal with complex values in attempting to optimize the quality of a product. From the study of
algorithmic complexity, we can learn an important lesson. There are often efficient algorithms

LOVELY PROFESSIONAL UNIVERSITY 101