A powerful method to learn a subject is to explore its associations with other subjects. This method has been used while teaching (and learning) the Software Engineering course of Metropolitan College of Boston University. A software application (Interactive Learning Platform - ILP) has been developed to facilitate this technique. It is hosted at AWS and readily available. It is understood that such platform could be a learning tool for a variety of subjects, that are beyond its current application of Software Engineering. It is also understood that other learning avenues, e.g. lectures and hands-on projects, could be quite effective.


The platform we built has the following key features. It enables a learner to decompose the subject into several logical parts. And then to ascertain the relationship between these parts. Suppose, you know some parts and do not know other parts. ILP assures no part is left untouched. A learner walks one-step-stone-at-a-time until the stable ground of the other side is reached.


Software Engineering implies a systematic process. It implies an ability to scale. There are several components to Software Engineering and each component relates to each other component. While building ILP, we focused on relationships among constituent parts.


To advance the whole subject of software engineering, it is not enough addressing one of its parts. To become a professional software engineer, it is not enough just to do the work in front of you. One has to grow into a somewhat rounded person and become aware of all related subjects.


We systematically explore the recursive dependency between components. As in orchestra with many instruments. It is not enough to have drums and forget about cellos. If a symphony requires cellos, then you bring cellos.


We do have a system to explore these topics. Here it is ! We methodically follow each topic, one at a time, from (1) to (55) and examine it from various angles. No angle is left unexplored. The topic and the angle are the same. We document ‘terminology’ for each topic. We learn about ‘tools’ for each topic. When we exhaust this table, the syllabus of the whole course is done-done.

The platform exemplifies the transition from terminology (when individual parts are independent) into taxonomy (with a strong correlation between components). Apparently, the dynamics of a taxonomy belongs to a real world scenario presenting a complexity challenge that needs to be conquered. In fact, after studying these interrelationships, the most common discovery is that the division into components is artificial and exists only in a mind of a learner. The prudent approach is to use the decomposition as an initial step, as a method to comprehend the unified system.


All text books on software engineering have a similar table of contents. We placed the same list of topics on both sides of the square. Then we matched each topic from the left with each other topic from the top.

Imagine we randomize all questions. We drop the whole idea of a systematic decomposition. Those of us, who are well familiar with the breadth and depth of the field, would still be able to respond all questions. No doubt ! Then, why do we need the systematic approach ? It is only for the sake of learners, for those who want to get to the other side.