<p>
</p>
<p>Yeah.</p>
<p>I’ve always thought of the “software engineering process” being more of a matter of negotiation and teamwork. I.e. whatever “process” there is, it’s developed inside a team so that it matches what the team is working on and what kinds of people the team employs (i.e. how do they want to think about “the process”, which is also relative to the particular software being developed). And everyone just signs to some model of development either because they have to or because they all agree on it. I wonder if “agile” has become such a big buzzword as a “software engineering principle”, because it really emphasizes the non-rigor of the “software engineering process” and suggests that developers adapt “the process” to the project’s needs and the team and its preferences, and keep updating “the process” during the project to match specific needs or problems that arise. I.e. “software engineering processes” can be very natural processes and not something that’s carved in stone.</p>
<p>The core computing science curriculum on the other hand is meant to be pure computing theory. I.e. the guts and bones of computing. The theory is not something that’s very negotiable as it’s just the “hard stuff” about how computing technically works, what’s its theoretical framework (mathematics) and how computing can be developed.</p>
<p>And yes, CS curricula do usually include a single or a few courses that go through the different methodologies that have been developed for developing software in teams and that are meant to serve as a guidelines for facilitating efficient teamwork. I think that’s enough about software engineering processes.</p>
<p>The world changes, the technologies change, new technologies and new practices come and go and some are better than the others, but the underlying theoretical framework of computing stays pretty much the same. Thus, study CS.</p>