The Spectrum of Considerations involved in Software Engineering

The process of Engineering Software is an activity very different from most other types of engineering. Unlike other established fields of engineering you do not have absolute principles and a standard process enforcing them to deliver a product. All you have are experience, guidelines, best practices and coding techniques which can be followed in building software (Note that you do have the theory of computation involving Automata, Language theory etc. but their realization are mostly local to parts of a system and not to the whole. Thus witness the existence of lots of software developers without knowledge of the above-mentioned theories but able to successfully implement features of software systems). This is because of the complexity involved in building software. Where does this complexity come from? It comes from us trying to model the complex real/conceptual world through layer upon layer of abstractions to be executed on a finite resource machine in finite time. During the process of development we have to traverse back and forth through these different layers of abstractions keeping one or more aspects and features of the required end system in mind. Trying to juggle all these parameters simultaneously is tremendously taxing on our minds (see for example The Humble Programmer). One way to simplify the problem is to separate out the incidental activities involved in programming the system from the essential problem being solved. That way the commonalities involved in the art of programming can be applied to problems across various domains (for example i have developed software systems for the color matching domain and the computer network domain among others). Indeed this is how the profession of "Software Programming" has evolved i.e. by concentrating only on the activity of programming. But programming itself is just one consideration in developing a system. What are the others? How can we systematize our approach to these? How do they relate to each other? What aspects do we need to concentrate on to deliver an elegant and efficient system? In the rest of this article we will endeavor to answer these and related questions.

There are two important viewpoints to doing software development that we need to keep in mind;

• Top Down View : A top down approach is absolutely essential to zoom in and focus on your goals. What does the system do? This is the problem domain. You need to break through everything inessential right to the heart of the requirements. The system boundaries can only be defined using this approach.
  
• Bottom Up View : All systems exist in a certain context. A bottom up approach is essential to understand this context and its limitations. This context is defined by computer architecture, programming languages, runtime systems etc. and forms the solution domain.
  

Following the above viewpoints we look at the system as follows;

• Problem Domain : This consists of the concepts and their inter-relationships which we are trying to model in a computer system. The key is to build a conceptual model of what the user wants. The terminology used should be that of the user. This is often referred to as "Domain Engineering" or "Requirements Analysis". The resulting conceptual model should be documented and communicated to the user (using one or more modeling tools/languages like UML etc.) Interaction with a domain expert who may or may not be the actual end user greatly aids in this activity. For example when i had to develop a software package for the Color Chemistry domain, i had access to a professor and a industrial expert who greatly helped me do "Domain Engineering".
  

--To be continued