I would love to hear someone that actually works in a place that requires credentials like the PE comment on having a course based on this as a credential.
There are way too many software engineers with lofty ideas about how physical engineers can magically know all the answers to all the problems they could ever have.
I'm assuming you mean a single course? If so, this material would not be a standalone course. It would be baked into the entire bachelor's degree program. Some of the topics would maybe be more advanced or something that need to be demonstrated by being an EIT or writing the appropriate exams. For example, chapter 15 on engineering economics is a single class, but chapter 17 on mathematical foundations would cover at least 4 classes (discrete math, differential calculus, integral calculus, probability).
The US of A did have a software engineering principles and practices of engineering (PE) exam, but it's been discontinued, and I haven't managed to find an archived snapshot of the exam spec. I'm not American, but I think there is a common fundamentals of engineering (FE) exam [1] that has to be written to register as an EIT and then the PE [2] has to be written to be licensed and given the PE.
I'm not familiar with which American schools were ABET accredited in software engineering, but in Canada, several schools do have accredited software engineering majors. You can review the curriculum and see a fair amount of alignment to the SWEBOK topics. Again, some of these chapters could be split across multiple courses, but some chapters look more like a couple of weeks in one class.
For comparison, there is a 61 page industrial and systems engineering body of knowledge [3] available from the IISE (Institute of Industrial and Systems Engineers), which is really just a couple short paragraphs on each topic, a list of key areas within each, and a list of reference books. At a quick glance, all of the areas correspond to sections in the industrial FE [4] and the industrial PE [5].
> There are way too many software engineers with lofty ideas about how physical engineers can magically know all the answers to all the problems they could ever have.
I'm not an engineer. I did an associates in engineering technology in Canada, so I'm a "pretengineer" at best. As far as I know, engineers in Canada have a discipline and then areas of practice. For industrial, there are 9 different areas of practice, but people are generally licensed to practice in 1 to 3.
In my region, software is not even broken out into its own areas of practice. Software is an area within computer engineering. I think software is way too vast right now and the expectations are much too big. So, the traditional engineers have much more limited scope problems. But I could be limited by my perspective and lack of license.
In the US most engineers do not have the PE and many (might be most, but I couldn't find the numbers) do not take the FE exam.
In the States most people working on software have computer science degrees, not software engineering degrees.
In general there is not a huge amount of certification overhead for engineers in the US, despite what some people seem to think, and I'm quite happy that's the way it is.
I was mostly looking for perspectives on how requiring credentials like these impacted actual work and workplaces.
There are way too many software engineers with lofty ideas about how physical engineers can magically know all the answers to all the problems they could ever have.